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