說明

如何畫架構視圖，如何寫出設計文檔
講課老師 – 李智慧

4+1 視圖模型

架構視圖有很多種，不同的人給不同的架構視圖。
架構師不能只用一種視圖解決所有問題。

軟件開發的本質是什麼？如何進行軟件架構設計？

備註：4+1架構模型，4+1架構視圖在工業上不常用，瞭解即可。

4+1 架構視圖

軟件架構 = {元素，形式，關係/約束}
單一的視圖無法完整的表達架構，因此需要具備完整的視圖集。

邏輯視圖（Logical View），設計的對象模型。
過程視圖（Process View），捕捉設計的併發和同步特徵。
物理視圖（Physical View），描述了軟件到硬件的映射，反映了部署特性。
開發視圖（Development View），描述了在開發環境中軟件的靜態組織結構。
場景視圖（Scenarios），描述用例場景。

邏輯視圖

相關方：客戶、用戶、開發組織管理者。
視角：系統的功能元素，以及它們接口，職責，交換。
主要元素：系統，子系統，功能模塊，子功能模塊，接口。
用途：開發組織劃分，成本/進度的評估。

開發視圖

相關者：開發相關人員，測試人員
視角：系統如何開發實現
主要元素：描述系統的層，分區，包，框架，系統通用服務，業務通用服務，類和接口，系統平臺和相關基礎框架。
用途：知道開發組織設計和開發實現。

物理視圖

相關者：系統集成商，系統運維人員。
視角：系統邏輯組件到物理節點的物理部署和節點之間的物理網絡配置。
主要元素：物理節點以及節點的通信。

過程視圖

相關者：性能優化，開發相關人員。
視角：系統運行時線程，進程的情況。
主要元素：系統進程，線程以及處理隊列等。

場景視圖

相關者：用戶，設計和開發人員。
視角：概括了架構上最重要的場景（最典型或者最優風險）及其非功能性需求，通過這些場景的實現，闡明瞭架構的廣度或衆多架構元素運行的方式。

軟件建模語言

如何使用UML進行軟件架構設計與建模？

重點：表達什麼樣的設計意圖？給什麼人看？

使用什麼UML圖，達成什麼樣的設計意圖？

在這裏插入代碼片

什麼是模型？

模型是一個系統的完整的抽象。人們對某個領域特定問題的求解及解決方案，對他們的理解和認識都蘊含在模型中。

通常，開發一個計算機系統是爲了解決某個領域特定問題，問題的求解過程，就是從領域問題倒計算機系統的映射。

在還沒工程師之前，架構師要有系統的抽象，對現實業務的抽象。
需要考慮有哪些模型，哪些模塊，哪些類，怎麼交互的？

領域問題：開發的時候，要理解業務。
概念模型：要有抽象能力，想象最終產品的樣子。
系統需求：前瞻性地抽象出系統需求。
解決方案：提前列出關鍵問題的解決方案。

爲什麼要建造模型？

建造傳統模型的目的

爲了證明某件事物能夠工作
前提：建造模型的成本遠遠低於建造實物的成本
☞ 造飛機
☞ 建高樓

建造軟件模型的目的

爲了與TA人溝通
爲了保存軟件設計的最終成果
前提：除非模型比代碼更能說明問題

何時、何處畫圖？

何時畫圖？

討論、交流時
最終設計文檔
☞ 只保留少量的、重要的圖
☞ 避免涉及過多內容和實現細節

何處畫圖？

白板
繪圖工具，如：StarUML、Gliffy Diagrams、Visio、Aastah
draw.io

UML 簡介

什麼是UML?

Unified Modeling Language, 或統一建模語言
以圖形方式描述軟件的概念

可用來描述：

某個問題領域
構思中的軟件設計
描述已經完成的軟件實現

UML圖的分類 - 靜態圖

靜態圖 - 通過描述類、對象和數據結構以及它們之間存在的關係，來描述軟件要素中不變的邏輯結構。

用例圖（Use Case Diagrams）
對象圖（Object Diagrams）
類圖（Class Diagrams）
組件圖（Component Diagrams）
包圖（Package Diagrams）
部署圖（Deployment Diagrams）

UML圖的分類 - 動態圖

動態圖 - 通過描述執行流程或者實體狀態變化的方式，來展示軟件實體在執行過程中的變化過程。

協作圖（Collaboration Diagrams）
序列圖（Sequence Diagrams）
活動圖（Activity Diagrams）
狀態圖（State Diagrams）

通用模型元素

可以在圖中使用的概念統稱爲模型元素。模型元素在圖中用其相應的視圖元素（符號）表示，下圖給出了常用的元素符號：類、對象、結點、包和組件等。

模型元素和模型元素之間的連接關係也是模型元素，常見的關係有接口實現（Interface Realization）、繼承泛化（Generalization）、依賴（Dependency）、關聯（Association）、聚合（Aggregation）和組合（Composition）。這些關係的圖示符合如圖所示。

實現 Interface Realization：接口的實現。
繼承/泛化 Generalization：表示一般與特殊的關係，即“一般”元素是“特殊”關係的泛化。類上表示繼承的關係。
依賴 Dependency：表示一個元素以某種方式依賴於另一種元素。一般表示方法內的局部變量，或者參數。
關聯 Association：連接（connect）模型元素及鏈接（link）實例。一般表示類的屬性。
聚合 Aggregation：表示整體與部分的關係。整體的生命週期結束，部分不一定。
組合 Composition：表示整體與部分的強關係。整體與部分的生命週期一致。

弱關係：接口實現、依賴、聚合。
強關係：類繼承、關聯、組合。

用例建模

用例建模技術，用於描述系統的功能需求。在宏觀上給出模型的總體輪廓。通過對典型泳衣的分析，使開發者能夠有效地瞭解用戶的需求。

用例模型描述的是外部執行者（Actor）所理解的系統功能。它描述了待開發系統的功能需求。

它驅動了需求分析之後各階段的開發工作，不僅在開發過程中保證了系統所有功能的實現，而且被用於驗證和檢測所開發的系統，從而影響到開發工作的各個階段和 UML 的各個模型。

用例模型由若干個用例圖構成，用例圖中主要描述執行者和用例之間的關係。在 UML中，構成用例圖的主要元素是用例和執行者及其它們之間的聯繫。

創建用例模型的工作包括：定義系統、確定執行者和用例、描述用例、定義用例間的關係、確認模型。

執行者（Actor）

執行者是指用戶在系統中所扮演的角色。執行者在用例圖中是用類似人的圖形來表示，但執行者可以是人，也可以是一個外界系統。

注意：用例總是由執行者啓動的。

如何確定執行者：

誰使用系統的主要功能（主執行者）？
誰需要從系統獲得對日常工作的支持和服務？
需要誰維護管理系統的日常運行（副執行者）？
系統需要控制哪些硬件設備？
系統需要與其它哪些系統交互？
誰需要使用系統產生的結果（值）？

用例圖描述了系統的功能需求，它是從執行者的角度來理解系統，用於捕獲系統的需求，規劃和控制項目；描述了系統外部的執行者和系統提供的用例之間的某種聯繫。

圖中還要另外兩種類型的連接，即《使用》和《擴展》關係，是兩種不同形式的泛化關係。

《Use》表示一個用例使用另一個用例。
《Extend》通過向被擴展的用例添加動作來擴展用例。

例項目與資源管理系統的 Use case 圖

系統的主要功能是：項目管理，資源管理和系統管理。項目管理包括項目的增加、刪除、更新。資源管理包括對資源和技能的添加、刪除和更新。系統管理包括系統的啓動和關閉，數據的存儲和備份等功能。

分析確定系統的執行者（角色）
☞ 項目管理員、資源管理者、系統管理員、備份數據系統。
確定用例
☞ 項目管理，資源管理和系統管理。
對用例進行分解，畫出下層的 Use Case 圖
☞ 對上層的用例進行分解，並將執行者分配到各層次的 Use Case 圖中。

靜態建模

任何建模語言都以靜態建模機制爲基礎，標準建模語言 UML 也不例外。所謂靜態建模是指對象之間通過屬性互相聯繫，而這些關係不隨時間而轉移。

類和對象的建模，是 UML 建模的基礎。 UML 的靜態建模機制包括：

用例圖（Use Case Diagram）
類圖（Class Diagram）
對象圖（Object Diagram）
包圖（Package Diagram）
組件圖（Component Diagram）
部署圖（Deployment Diagram）

類與對象

面向對象的開發方法的基本任務是建立對象模型，是軟件系統開發的基礎。UML 中的類圖（Class Diagram）與對象圖（Object Diagram）表達了對象模型的靜態結構，能夠有效地建立專業領域的計算機系統對象模型。

屬性（Attribute）：屬性用來描述類的特徵，表示需要處理的數據。

屬性的定義： visibility attribute-name :type = initial-value {property-string}
可見性屬性名：類型=缺省值{約束特性}

其中：可見性（visibility）表示該屬性對類外的元素是否可見。
分爲：

public (+) 公有的。
private (-) 私有的。
protected (#) 受保護的。
默認 (未聲明)

操作

對數據的具體處理方法的描述則放在操作部分，操作說明了該類能做些什麼工作。操作通常爲函數，它是類的一個組成部分，只能作用於該類的對象說。

操作定義：
visibility operating-name(parameter-list): return-type {property-string}
可見性操作名(參數表)；返回類型{約束特性}

一個使用 Visio 繪製的類圖

包圖

一個最古老的軟件方法問題是：怎樣講大系統拆分成小系統。解決該問題的思路之一是將許多類集合成一個更高層次的單位，形成一個高內聚、低耦合的類的集合。UML 中這種分組機制叫包(Package)。引入包是爲了降低系統的複雜性。

動態建模

動態模型主要描述系統的動態行爲和控制結構。動態行爲包括系統中對象生存期內可能的狀態以及事件發生時狀態的轉移，對象之間動態合作關係，顯示對象之間的交互過程以及交互順序，同時描述了滿足用例要求所進行的活動以及活動間的約束關係。

在動態模型中，對象間的交互是通過對象間消息的傳遞來完成的。對象通過相互間的通信（消息傳遞）進行合作，並在其生命週期中根據通信的結果不斷改變自身的狀態。

動態模型

動態模型主要描述系統的動態行爲和控制結構。

包括四類圖：狀態圖、活動圖、時序圖、合作圖。

狀態圖（State Diagram）：狀態圖用來描述對象，子系統，系統的生命週期。
活動圖（Activity Diagram）：着重描述操作視線中完成的工作以及用例實例或對象中的活動，活動圖是狀態圖的一個變種。
時序圖（Sequence Diagram）：是一種交互圖，主要描述對象之間的動態合作關係以及合作過程中的行爲次序，常用來描述一個用例的行爲。
合作圖（Collaboration Diagram）：用於描述相互合作的對象間的交互關係。

UML 中的消息

簡單消息（Simple）：表示控制流，描述控制如何從一個對象傳遞到另一個對象，但不描述通信的細節。
同步消息（Synchronous）：是一種嵌套的控制流，用操作調用實現。操作的執行者要到消息響應操作執行完並會送一個簡單的消息後，再繼續執行。注意：方法間的調用都是同步消息，異步處理是方法內的處理機制。
異步消息（Asynchronous）：是一種異步的控制流，消息的發送者在消息發送後就繼續執行，不等待消息的處理。

時序圖

時序圖（Sequence Diagram）用來描述對象之間動態的交互行爲，着重體現對象間消息傳遞的時間順序。

時序圖存在兩個軸

水平軸表示一組對象
垂直軸表示時間

時序圖中的對象用一個帶有垂直虛線的矩形框表示，並標有對象名和類名。垂直虛線是對象的生命線，用於表示在某段時間內對象是存在的。

對象間的通信通過再對象的生命線之間消息來表示，消息的箭頭類型指明消息的類型。

順序圖的形式

有兩種使用順序圖的方式：一般格式和實例格式。

實例格式詳細描述一次可能的交互。沒有任何條件和分支或循環，它僅僅顯示選定情節（場景）的交互。

而一般格式則描述所有的情節。因此，包括了分支，條件和循環。

活動圖

活動圖（Activity Diagram）的應用非常廣泛，它既可用來描述操作（類的方法）的行爲，也可以描述用例和對象內部的工作過程，並可用於表示並行過程。

活動圖描述了系統中各種活動的執行的順序。刻畫一個方法中所要進行的各項活動的執行流程。

活動圖中一個活動結束後將進入下一個活動（在狀態圖中狀態的變遷可能需要事件的觸發）。

活動圖的模型元素

構成活動圖的模型元素有：活動件、轉移、對象、信號、泳道等。

活動：

是構成活動圖的核心元素，是具有內部動作的狀態，由隱含的事件觸發活動的轉移。
活動的解釋依賴於作圖的目的和抽象層次，在概念層描述中，活動表示要完成的一些任務；在說明層和實現層，活動表示類中的方法。
活動用圓角框表示，標註活動名。
模型元素有：活動、轉移、對象、信號、泳道等。

活動還有其它的圖標符號：初始狀態、終止狀態、判斷、同步線。

轉移

轉移描述活動之間的關係，描述由於隱含事件引起的活動變遷，即轉移可以連接各活動及特殊活動（初始狀態、終止狀態、判斷、同步線）。
轉移用帶箭頭的直線表示，可標註執行該轉移的條件，無標註表示順序執行。

泳道

泳道進一步描述完成活動的對象，並聚合一組活動。活動圖是另一種描述交互的方式，描述採取何種動作，做什麼（對象狀態轉移），何時發生（動作序列），以及在何處發生（泳道）。
泳道也是一種分組機制。

對象流

活動圖中可以出現對象，對象作爲活動的輸入/輸出，用虛箭頭表示。

控制圖符

活動圖中可發送和接收信號，發送符號對應於與轉移聯繫在一起的發送斷句。接收符號也同轉移聯繫在一起。

狀態圖

狀態圖（State Diagram）用來描述一個特定對象的所有可能的狀態及其引起狀態轉移的事件。一個狀態圖包括一系列的狀態以及狀態之間的轉移。

狀態
所有對象都具有狀態，狀態是對象執行了一系列活動的結果。當某個事件發生後，對象的狀態將發生變化。狀態圖中定義的狀態有：

初態 - 狀態圖的起始點，一個狀態圖只能有一個初態。
終態 - 是狀態圖的終點，而終態則可以有多個。
中間狀態 - 可包括三個區域：名字域、狀態變量與活動域。
複合狀態 - 可以進一步細化的狀態稱作複合狀態。

合作圖(不常用，相當於沒有時間順序的時序圖)

合作圖（Collaboration Diagram），也稱爲協作圖，用於描述相互合作的對象間的交互關係和鏈接（Link）關係。雖然時序圖和合作圖都用來描述對象間的交互關係，但側重點不一樣。時序圖着重體現交互的時間順序，合作圖則着重體現交互對象間的靜態鏈接關係

實現模型

實現模型描述了系統實現時的一些特性，又稱爲物理體系結構建模。包括源代碼的靜態結構和運行時刻的實現結構。

實現模型包括：

組件圖（Component Diagram）顯示代碼本身的邏輯結構，它描述系統中存在的軟件構件以及它們之間的依賴關係。
部署圖（Deployment Diagram）描述了系統中硬件和軟件的物理配置情況和系統體系結構。顯示系統運行時刻的結構，部署圖中的簡單節點是指實際的物理設備以及在該接點上運行構件或對象。部署圖還描述節點之間的鏈接以及通信類型。

組件圖

組件（Component）：系統中遵從一組接口且提供其實現的物理的、可替換的部分。對系統的物理方面建模時，它是一個重要的構造塊。

組件可以看作包與類對應的物理代碼模塊，邏輯上與包，類對應，實際上是一個文件，可以有下列幾種類型的構件：

源代碼構件
二進制構件
可執行構件

組件之間的依賴關係是指結構之間在編譯，連接或執行時的依賴關係。用虛線箭頭表示組件圖符：

部署圖

部署圖用來描述系統硬件的物理拓撲結構以及在此機構上執行的軟件，即系統運行時刻的結構。部署圖可以顯示計算機結點的拓撲結構和通信路徑，結點上執行的組件，特別對於分佈式系統，部署圖可以清楚的描述系統中硬件設備的配置，通信以及在各硬件設備上各種軟構建和對象的配置。因此，部署圖是描述任何基於計算機的應用系統的物理配置或邏輯配置的有力工具，部署圖的元素有結點和連接。

部署圖的結點代表某種計算機，通常是某種硬件。同時結點還包括在其上運行的軟組件，軟件組件代表可執行的物理代碼模塊。如一個可執行程序。結點的圖符是一個立方體。

保險系統的部署圖
部署圖個結點之間進行交互的通信路徑稱爲連接，連接表示系統中的結點存在着聯繫，用結點之間的連線表示連接，在連接的連線上標註通信類型。

極客大學架構師訓練營 聽課總結 - 架構視圖，設計文檔 -- 第二課

說明