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