2011年軟考系統(tǒng)架構(gòu)設(shè)計(jì)師學(xué)習(xí)筆記第六章
6.1 UML 建模與架構(gòu)文檔化
方法種類的膨脹，極大地妨礙了用戶的使用和交流。
UML通過統(tǒng)一的表示法，使不同知識(shí)背景的 領(lǐng)域?qū)＜?、系統(tǒng)分析、開發(fā)人員、用戶 可以方便地交流。
6.1.1 UML 體系結(jié)構(gòu)演變
UML 是用 元模型 描述的，元模型是 4層元模型體系結(jié)構(gòu)模式中的一層，其他層次分別是 元-元模型、模型層、用戶對(duì)象曾。其中元模型層由 元-元模型層 導(dǎo)出。
元模型的體系結(jié)構(gòu)模式 可以用來定義 復(fù)雜模型 所要求的 精確定義，這種復(fù)雜模型通常需要被 可靠地 保存、共享、操作 以及在工具之間進(jìn)行交換。它的特點(diǎn)如下：
1、在每一層都遞歸地定義語(yǔ)義結(jié)構(gòu)。
2、可用來定義 重量級(jí)和輕量級(jí) 擴(kuò)展機(jī)制。
3、在體系結(jié)構(gòu)上 將其他體系結(jié)構(gòu)的標(biāo)準(zhǔn)統(tǒng)一起來。
UML 元模型又被分解為三個(gè)邏輯子包：基礎(chǔ)包、行為元素包、模型管理包。
6.2 UML 基礎(chǔ)
UML 通過 圖形化的表示機(jī)制 從多個(gè)側(cè)面 對(duì)系統(tǒng)的分析和設(shè)計(jì)模型進(jìn)行刻畫。
10種視圖，四類：
1、用例圖
2、靜態(tài)圖，包括 類圖、對(duì)象圖、包圖。
類圖的邊表示類之間的聯(lián)系，包括 繼承、關(guān)聯(lián)、依賴、聚合 等。
對(duì)象圖描述在某種狀態(tài)下或某一時(shí)間段，系統(tǒng)中 活躍的對(duì)象及其關(guān)系。
包由 子包、類 組成。
3、行為圖，包括 交互圖、狀態(tài)圖、活動(dòng)圖，他們從不同的側(cè)面刻畫系統(tǒng)的動(dòng)態(tài)行為。
交互圖分為 順序圖、合作圖。順序圖強(qiáng)調(diào) 對(duì)象之間 消息發(fā)送的時(shí)序。合作圖更強(qiáng)調(diào)對(duì)象間 的動(dòng)態(tài)協(xié)作關(guān)系。
狀態(tài)圖 描述 對(duì)象的動(dòng)態(tài)行為。
活動(dòng)圖 描述 操作序列，這些操作序列 可以并發(fā)、同步，包含控制流、信息流。
4、實(shí)現(xiàn)圖，包括 構(gòu)件圖、部署圖。描述組成和分布情況。
部署圖 節(jié)點(diǎn)表示實(shí)際的計(jì)算機(jī)和設(shè)備，邊表示節(jié)點(diǎn)之間的物理連接，也可以顯示連接的類型及節(jié)點(diǎn)之間的依賴性。
6.2.1 用例和用例圖
用例圖 也翻譯為 用況、用按 等，在 UML 中，用例用一個(gè)橢圓表示，往往用 動(dòng)賓結(jié)構(gòu) 或 主謂結(jié)構(gòu) 命名。
可選的 動(dòng)作序列 和 會(huì)出現(xiàn)異常的動(dòng)作序列。
用例是代表系統(tǒng)中 各種相關(guān)人員之間 就系統(tǒng)的行為所達(dá)成的契約。
需求階段 用例是 分析人員與客戶溝通的工具 項(xiàng)目規(guī)模估算的依據(jù);
設(shè)計(jì)階段 用例是 系統(tǒng)功能設(shè)計(jì)的主要輸入;
實(shí)現(xiàn)階段 用例是 檢測(cè)類型為正確性的文檔。
本質(zhì)上，用力分析 是一種功能分解 的技術(shù)。
1、參與者角色，參與者實(shí)際上并不是系統(tǒng)的一部分。
2、用例間的關(guān)系，泛化、包含、擴(kuò)展 等。
包含是比較特殊的依賴關(guān)系。
擴(kuò)展，基本用例必須聲明 若干“擴(kuò)展點(diǎn)”，而這些擴(kuò)展用例只能在這些擴(kuò)展點(diǎn)上增加新的行為和含義。
3、用例圖
建模人員可以在途中給某些圖符加上填充色，在語(yǔ)義上，使用填充顏色和不使用填充顏色的模型是 一樣的。
6.2.2 交互圖
描述對(duì)象之間 對(duì)象與參與者之間 動(dòng)態(tài)協(xié)作關(guān)系 協(xié)作過程中行為次序。
通常描述用例的行為，顯示該用例中所涉及的對(duì)象 對(duì)象之間的消息傳遞。
順序圖、協(xié)作圖 之間可以互相轉(zhuǎn)化，一個(gè)用例需要多個(gè)順序圖或協(xié)作圖。
交互圖可以幫助分析人員 對(duì)照檢查 每個(gè)用例中所描述的 用戶需求，提醒分析人員去補(bǔ)充遺漏的類或方法。
水平方向?yàn)閷?duì)象維，一般 主要參與者放在最左邊，次要參與者放在最右邊。
垂直方向?yàn)闀r(shí)間維。
6.2.3 類圖和對(duì)象圖
一般而言，類的名字是 名詞。
類之間的關(guān)系 有 關(guān)聯(lián)、聚集、組合、泛化、依賴 等。
1、關(guān)聯(lián)，鏈 是關(guān)聯(lián)的實(shí)例，關(guān)聯(lián)表示 類與類之間的關(guān)系，鏈表示 對(duì)象與對(duì)象之間的關(guān)系。
關(guān)聯(lián)用 實(shí)線表示，角色還具有多重性。
關(guān)聯(lián)類 描述關(guān)聯(lián)的 屬性、操作、以及其他信息。
關(guān)聯(lián)類 通過一條虛線與關(guān)聯(lián)連接。
自返關(guān)聯(lián) 又稱 遞歸關(guān)聯(lián)，同一個(gè)類的兩個(gè)對(duì)象間的關(guān)系。兩個(gè)關(guān)聯(lián)端，每個(gè)關(guān)聯(lián)端的角色不同。
2、聚集和組合
聚集 是一種特殊形式的 關(guān)聯(lián)，類之間整體與部分的關(guān)系。
組合 整體與部分具有同樣的生存期，是一種特殊形式的聚集。
3、泛化關(guān)系，一般和特殊元素之間的關(guān)系，就是平常所說的繼承關(guān)系。
6.2.4 狀態(tài)圖和活動(dòng)圖
1、狀態(tài)圖
描述 對(duì)象 生存期間的 動(dòng)態(tài)行為，所經(jīng)歷的狀態(tài)序列，引起狀態(tài)轉(zhuǎn)移的 事件、動(dòng)作。
是 UML 動(dòng)態(tài)行為建模的 5個(gè)圖之一，用 狀態(tài)機(jī) 對(duì)一個(gè)對(duì)象的生命周期建模，狀態(tài)圖 用于顯示狀態(tài)機(jī)，重點(diǎn)在于 狀態(tài)之間的控制流。
除了 初態(tài)和終態(tài)，還有 Idle 和 Running 兩個(gè)狀態(tài)，keyPress、finished、shutDown 是事件。
2、活動(dòng)圖
是 UML 動(dòng)態(tài)行為建模的 5個(gè)圖之一，描述系統(tǒng)的 工作流程 和 并發(fā)行為。狀態(tài)圖的特殊形式，一個(gè)活動(dòng)結(jié)束后將立即進(jìn)入下一個(gè)活動(dòng)。
基本概念：活動(dòng)、泳道、分支、分叉、匯合、對(duì)象流。
1.活動(dòng)，注意區(qū)分 動(dòng)作狀態(tài) 和 活動(dòng)狀態(tài)，
動(dòng)作狀態(tài)是原子的，沒有內(nèi)部轉(zhuǎn)移，沒有內(nèi)部活動(dòng)，所占用的時(shí)間可以忽略，目的是執(zhí)行進(jìn)入動(dòng)作，然后轉(zhuǎn)向另一個(gè)狀態(tài)。
活動(dòng)狀態(tài)是可分解的，工作完成需要一定的時(shí)間。
2.泳道，是活動(dòng)圖中區(qū)域劃分，每個(gè)泳道代表一個(gè)責(zé)任區(qū)，知道和類并不是一一對(duì)應(yīng)的關(guān)系。
3.分支，同一個(gè)觸發(fā)事件，可以根據(jù)不同的警戒條件轉(zhuǎn)向不同的活動(dòng)，每個(gè)可能的轉(zhuǎn)移是一個(gè)分支。
4.分叉和匯合，如果要表示 系統(tǒng)或?qū)ο笾械牟l(fā)行為，使用分叉fork 和 匯合join，匯合正好與分叉相反。
5.對(duì)象流，活動(dòng)圖中可以出現(xiàn)對(duì)象，對(duì)象可用作為活動(dòng)的輸入輸出?；顒?dòng)圖中的對(duì)象流表示活動(dòng)和對(duì)象之間的關(guān)系。
6.2.5 構(gòu)件圖
構(gòu)件是系統(tǒng)中 遵從一組接口 且提供其實(shí)現(xiàn)的 物理的、可替換 的部分。
構(gòu)件圖 顯示一組構(gòu)件 以及它們 之間的相互關(guān)系，包括 編譯、連接、執(zhí)行時(shí) 構(gòu)建之間的依賴關(guān)系。
構(gòu)件就是一個(gè)實(shí)際文件，以下幾種類型：
1、部署構(gòu)建
2、工作產(chǎn)品構(gòu)件
3、執(zhí)行構(gòu)件
構(gòu)件圖可以對(duì)以下幾個(gè)方面建模：
1、對(duì)源代碼文件之間的相互關(guān)系建模。
2、對(duì)可執(zhí)行文件之間的相互關(guān)系建模。
6.2.6 部署圖
部署圖 也稱 配置圖、實(shí)施圖，顯示系統(tǒng)中計(jì)算節(jié)點(diǎn)的 拓?fù)浣Y(jié)構(gòu)、通信路徑、節(jié)點(diǎn)上運(yùn)行的軟構(gòu)件等。
一個(gè)系統(tǒng)模型只有一個(gè)部署圖，常用語(yǔ)幫助理解分布式系統(tǒng)。
部署圖 由 體系結(jié)構(gòu)設(shè)計(jì)師、網(wǎng)絡(luò)工程師、系統(tǒng)工程師 等 描述。
6.3 基于 UML 的軟件開發(fā)過程
6.3.1 開發(fā)過程概述
UML 是獨(dú)立于軟件開發(fā)過程的，能夠在幾乎任何一種軟件開發(fā)過程中使用。迭代的漸進(jìn)式軟件開發(fā)過程包含四個(gè)階段：初啟、細(xì)化、構(gòu)件、部署。
1、初啟
項(xiàng)目的發(fā)起人 確定項(xiàng)目的 主要目標(biāo) 和 范圍，初步的可行性分析 和 經(jīng)濟(jì)效益分析。
2、細(xì)化
細(xì)化階段的開始 標(biāo)志著 項(xiàng)目的正式確立。
1.初步的需求分析，比較重要、比較有風(fēng)險(xiǎn)的用例。
2.初步的高層設(shè)計(jì)，用例、用例圖、類、類圖 將 依據(jù) 包 的劃分方法 分屬于 不同包。
3.部分的詳細(xì)設(shè)計(jì)，根據(jù)軟件元素 的重要性和風(fēng)險(xiǎn)程度 確立優(yōu)先細(xì)化原則，不能將風(fēng)險(xiǎn)的識(shí)別和解決延遲到細(xì)化階段后。
4.部分的原型構(gòu)造。
3、構(gòu)建
構(gòu)造階段，每次迭代中實(shí)現(xiàn)一部分用例，用戶可以及早參與對(duì)已實(shí)現(xiàn)用例的實(shí)際評(píng)價(jià)。
原則：
1.用戶認(rèn)為業(yè)務(wù)價(jià)值較大的用例 應(yīng) 優(yōu)先安排。
2.開發(fā)人員評(píng)估后 認(rèn)為 開發(fā)風(fēng)險(xiǎn)較高的用例 優(yōu)先 安排。
迭代計(jì)劃中，要確定迭代次數(shù)、每次迭代所需時(shí)間 以及 每次迭代中應(yīng)完成的用例。
6.3.2 基于 UML 的需求分析
1、生成用例
如果多個(gè)用戶扮演同一角色，這些用戶將由單一執(zhí)行者表示。如果一個(gè)用戶扮演多種角色，則需要多個(gè)執(zhí)行者來表示同一用戶。
用例主要來源于分析人員對(duì) 場(chǎng)景的 分類和抽象，即將相似的場(chǎng)景進(jìn)行歸類，使一個(gè)用例可以通過實(shí)例化和參數(shù)調(diào)節(jié)而涵蓋多個(gè)場(chǎng)景。
2、用活動(dòng)圖表示用例
3、生成用例圖
執(zhí)行者與用例之間的關(guān)系有兩種：觸發(fā)執(zhí)行、信息交換。
執(zhí)行者指向用例 表示 觸發(fā)執(zhí)行 和/或 信息交換，用例指向執(zhí)行者 表示用例將生成的信息傳遞給執(zhí)行者。
4、建立頂層架構(gòu)
頂層架構(gòu)便于開發(fā)人員 聚焦于系統(tǒng)的不同部分。
模型——視圖——控制器(Model、View、Controller，MVC)模式。
模型 維護(hù)并保存數(shù)據(jù)，視圖 呈現(xiàn)數(shù)據(jù)，控制器將動(dòng)作映射為處理功能并實(shí)際調(diào)用。
MVC 模式特別適合于分布式應(yīng)用軟件，尤其是web應(yīng)用系統(tǒng)。
分層模式 降低軟件系統(tǒng)的 耦合度。
確立頂層架構(gòu)的過程中需綜合考慮以下因素：
包的數(shù)量，架構(gòu)過早地陷入細(xì)節(jié)，返工的可能性很大，也不合理地限制了后續(xù)分析和設(shè)計(jì)活動(dòng)的自由空間。
包之間的耦合度。
將不穩(wěn)引起的軟件元素分類聚集于少數(shù)幾個(gè)包中，以提高軟件系統(tǒng)的可維護(hù)性。
可選功能 和 必須實(shí)現(xiàn)的功能 置于 不同的包。
根據(jù)開發(fā)人員 專長(zhǎng) 劃分，使每個(gè)包都能分配給最合適的開發(fā)人員，有利于并行開發(fā)。
6.3.3 面向?qū)ο蟮脑O(shè)計(jì)方法
1、設(shè)計(jì)用例實(shí)現(xiàn)方案
1.提取邊界類，實(shí)現(xiàn)類和控制類。
邊界類用于描述 系統(tǒng)與外部環(huán)境之間的交互。
a.界面控制。
b.外部接口。
c.環(huán)境隔離。使目標(biāo)軟件系統(tǒng)的 其余部分 盡可能地 獨(dú)立于環(huán)境軟件。
邊界類，《boundary》。
實(shí)體類“內(nèi)向收斂”特征，僅提供 讀/寫 信息的必要操作 作接口，并不涉及業(yè)務(wù)邏輯處理，《entity》。
控制類，《control》。
邊界類的作用范圍可以超越單個(gè)用例。
2.構(gòu)造交互圖
交互圖作為用力的精確實(shí)現(xiàn)方案。
事件流中的事件 直接對(duì)應(yīng)交互圖中的消息，事件間的先后關(guān)系體現(xiàn)為 交互圖中的時(shí)序，對(duì)消息的響應(yīng) 則構(gòu)成消息接收者的職責(zé)，這種職責(zé)被確立為 類的方法。
不應(yīng)該出現(xiàn) 穿越控制類 生命線 的消息。
為 易于理解，應(yīng)該用分離的 UML 交互圖 分別表示 事件流和每個(gè)備選事件流。
原則上，每個(gè)類都應(yīng)該有一個(gè)操作來響應(yīng)交互圖中指向其對(duì)象的那條消息。
2、設(shè)計(jì)技術(shù)支撐方案
當(dāng)用戶需求發(fā)生變化時(shí)，技術(shù)支撐方案應(yīng)具有良好的穩(wěn)定性。
技術(shù)支撐方案應(yīng)該位于層次結(jié)構(gòu)中的較低層次。
一方面取決于 需求，另一方面取決于 對(duì)軟件技術(shù)手段把我和選取。
3、設(shè)計(jì)用戶界面
1.熟悉用戶 并對(duì) 用戶分類，以便盡量照顧到所有用戶的合理要求，并優(yōu)先滿足某些特權(quán)用戶。
2.按用戶類別 分析用戶的 工作流與習(xí)慣，從每類中選取一個(gè)用戶代表，建立調(diào)查表，判斷用戶對(duì)操作界面的需求和喜好。
3.首先應(yīng)考慮命令的順序，一般常用命令居先，與用戶工作習(xí)慣保持一致;其次，根據(jù)外部服務(wù)之間的聚合關(guān)系組織相應(yīng)的命令;然后充分考慮人類記憶的局限性，最好組織為一顆兩層多叉樹;提供操作的快捷方式。
5.利用快速原型演示，改進(jìn)界面設(shè)計(jì)。并評(píng)判系統(tǒng)是否 齊全、方便、好用。
4、精化設(shè)計(jì)模型
對(duì)模型進(jìn)行改進(jìn)的活動(dòng)可以分為 精化 和 合并 兩種。一般先從精化開始。設(shè)計(jì)優(yōu)秀的粗粒度組件應(yīng)該只是完成一項(xiàng)功能，這一點(diǎn)是它與子系統(tǒng)的主要區(qū)分。
粗粒度組件的范圍過于廣泛，難以發(fā)揮重用價(jià)值，粗粒度組件擁有持久化的行為，擁有業(yè)務(wù)邏輯，需要表示層的支持。
將需求分成幾個(gè)功能組，基本上就可以得到相應(yīng)的粗粒度組件了。
過小的范圍，將會(huì)造成粗粒度組件不容易使用，用戶需要理解不同的粗粒度組件之間的復(fù)雜關(guān)系。
如果可能，在粗粒度組件之間定義單項(xiàng)關(guān)聯(lián)可以有效的減少組件之間的耦合。
盡可能簡(jiǎn)化組件之間的關(guān)系。
我們需要從軟件的目標(biāo)領(lǐng)域中 識(shí)別出關(guān)鍵性的實(shí)體，或者說領(lǐng)域中的名詞。然后決定它們應(yīng)該歸屬于那些粗粒度組件。
兩個(gè)組件之間存在重復(fù)的要素，可以從中抽取共性的部分，形成新的組件。
6.4 系統(tǒng)架構(gòu)文檔化
6.4.1 模型概述
以精心選擇的形式 將若干結(jié)構(gòu)元素進(jìn)行裝配。
軟件架構(gòu) = { 元素，形式，關(guān)系/約束 }
邏輯視圖(logical view)對(duì)象模型。
過程視圖(process view)并發(fā)和同步特征。
物理視圖(physical view)分布式。
開發(fā)視圖(development view)靜態(tài)組織結(jié)構(gòu)。
Rational 4.1 視圖模型。
每個(gè)視圖上均獨(dú)立地應(yīng)用 Perry&Wolf 軟件架構(gòu)公式。
對(duì)每種視圖選用特定的 架構(gòu)風(fēng)格(architectural style)。
6.4.2 邏輯結(jié)構(gòu)
邏輯架構(gòu)主要支持功能性需求，系統(tǒng)分解為一系列的關(guān)鍵抽象，(大多數(shù))來自于問題域，表現(xiàn)為對(duì)象或?qū)ο箢惖男问健?/p>
抽象、封裝、繼承。
對(duì)于數(shù)據(jù)驅(qū)動(dòng)程度高的應(yīng)用程序，可以使用其他形式的邏輯視圖，如 E-R圖 代替面向?qū)ο蟮姆椒ā?/p>
1、邏輯視圖的風(fēng)格
采用面向?qū)ο蟮娘L(fēng)格，試圖在整個(gè)系統(tǒng)中 保持 單一的、一致的 對(duì)象模型。
6.4.3 進(jìn)程架構(gòu)
進(jìn)程架構(gòu)考慮一些非功能性的需求，并發(fā)性、分布性、系統(tǒng)完整性、容錯(cuò)性，以及邏輯視圖的主要抽象如何與進(jìn)程結(jié)構(gòu)相配合在一起。
進(jìn)程是 構(gòu)成可執(zhí)行單元任務(wù)的分組。
區(qū)分主要次要任務(wù)：主要任務(wù)是 可以唯一處理的架構(gòu)元素;次要任務(wù)是 由于實(shí)施原因而引入的局部附加任務(wù)。
6.4.4 開發(fā)架構(gòu)
開發(fā)架構(gòu)關(guān)注軟件開發(fā)環(huán)境下實(shí)際模塊的組織。
開發(fā)架構(gòu)用模塊和子系統(tǒng)圖來表達(dá)，顯示了“輸出”和“輸入”關(guān)系。
考慮因素：開發(fā)難度、軟件管理、重用性、通用性、由工具集、語(yǔ)言 所帶來的限制。
開發(fā)視圖 是建立產(chǎn)品線的 基礎(chǔ)。
推薦使用分層(layered)的風(fēng)格，每層具有良好定義的職責(zé)。某層子系統(tǒng)依賴同一層或低一層的子系統(tǒng)，最大程度地減少了具有復(fù)雜模塊依賴關(guān)系的 網(wǎng)絡(luò)的開發(fā)量。
6.4.5 物理架構(gòu)
物理架構(gòu)主要關(guān)注系統(tǒng)非功能性的需求，可用性、可靠性(容錯(cuò)性)，性能(吞吐量)、可伸縮性。
軟件至節(jié)點(diǎn)的映射需要高度的靈活性 及 對(duì)源代碼產(chǎn)生最小的影響。
6.4.6 場(chǎng)景
4種視圖的元素通過數(shù)量比較少的一組重要場(chǎng)景(更常見的是用例)進(jìn)行無縫協(xié)同工作，我們?yōu)閳?chǎng)景描述相應(yīng)的腳本(對(duì)象之間和過程之間的交互序列)。
在某種意義上 場(chǎng)景是最重要的 需求抽象。
4+1 的 +1 起到了兩個(gè)作用：
作為一項(xiàng)驅(qū)動(dòng)因素 來發(fā)現(xiàn)架構(gòu)設(shè)計(jì)過程中的 架構(gòu)元素。
作為架構(gòu)原型測(cè)試的出發(fā)點(diǎn)。
場(chǎng)景表示法與組件邏輯視圖非常相似，但它使用過程視圖的連接符來表示對(duì)象之間的交互。
6.4.7 迭代過程
在進(jìn)行文檔化時(shí)，提倡一種更具有迭代性質(zhì)的方法——架構(gòu)先被原型化、測(cè)試、估量、分析，然后在一系列的迭代過程中被細(xì)化。
除了減少 風(fēng)險(xiǎn)之外，還有其他優(yōu)點(diǎn)：團(tuán)隊(duì)合作、培訓(xùn)、加深對(duì)架構(gòu)的理解、深入程序和工具 等。使 需求被細(xì)化、成熟化。
系統(tǒng)大多數(shù)關(guān)鍵的功能以場(chǎng)景的形式被捕獲，關(guān)鍵意味著：最重要的功能、系統(tǒng)存在的理由、使用頻率最高的功能、必須減輕的一些重要技術(shù)風(fēng)險(xiǎn)。
【編輯推薦】
