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