軟件工程的第二篇文章，依然還是跟需求相關的內容，依然也全部都是重點。而且這一部分的內容會更偏技術一些。在需求采集分析結束之后，形成了 SRS ，接下來就是再將需求轉化成開發人員的需求，也就是技術語言描述的需求。在這里，我們會使用 UML 這種圖形語言進行系統的描述，同時 UML 也是面向對象的，因此，緊接著我們就可以進行面向對象的分析，從而為系統架構的搭建做好準備。
UML 是一種定義良好、易于表達、功能強大且普遍適用的建模語言，它的作用不僅限于支持 OOA 和 OOD ，還支持從需求分析開始的軟件開發的全過程。從總體上看，UML 包括構造塊、規則和公共機制三個部分。其中在構造塊中，包括事物（thing）、關系（relationship）、和圖（diagram）。
主要就是對現實世界的抽象，也稱為建模元素，包括結構事物、行為事物、分組事物和注釋事物。其實事物就是我們要操作的對象，包括類、接口、協作、用例、活動、構件、節點等，也包括交互和狀態機。（了解即可）
UML 用關系把事物結合在一起，主要有下列四種關系：
1）依賴（dependency）：一個事物發生變化會影響另一個事物的語義。
2）關聯（association）：描述一對對象之間的連接結構關系，也是語義上的聯系。
3）泛化（generalization）：描述特殊元素的對象可以替換一般元素的對象。其實就是 繼承 的一種反關系。之前我們就說過，子類繼承父類，父類泛化子類。
4）實現（realization）：類之間的語義關系，一個類指定了由另一個類保證執行的契約。一般我們會說子類實現了父類的抽象方法，或者說類實現了接口方法。
UML 主要的表現形式就是各種各樣的圖，從圖的動靜表示來看，可以分為 動態 和 靜態 兩種類型的圖。
類圖：給出了系統的靜態設計視圖。在系統建模中，最常見的就是類圖，主要是描述一組類、接口、協作和它們之間的關系。
對象圖：給出系統的靜態設計視圖或靜態進程視圖。對象圖就是不顯示方法屬性的類圖。
包圖：描述由模型本身分解而成的組織單元，以及它們之間的依賴關系，比如類圖更細。
組合結構圖：描述結構化類的內部結構，用于畫出結構化類的內部內容。
構件圖：描述一個封閉的類和它的接口、端口，以及由內嵌的構件和連接件構成的內部結構。用于表示系統的靜態設計實現視圖。
部署圖：描述對運行時的處理節點及在其中的構件配置。在下圖中，大框內部并在左側帶兩個小長方形的就是 構件圖 ，整個一起就是 部署圖 。
制品圖：描述計算機中一個系統的物理結構。
用例圖：描述一組用例、參與者與它們之間的關系。給出系統的靜態用例視圖，描述需求。用例圖最明顯的特征是里面一定有小人，然后用例都是橢圓形的。
順序圖/序列圖：是一種交互圖，展現了一種交互，由一組對象或參與者以及它們之間可能發送的消息構成，是強調消息的時間次序的交互圖，也可以叫時序圖。順序圖肯定有消息從左向右傳遞的過程，有很多圖也會有消息從右向左返回的過程。微信、支付寶的支付接入文檔中都有這個時序圖的展現。
通信圖/協作圖：也是一種交互圖，強調收發消息的對象或參與者的結構組織。它與時序圖的區別就是沒有順序的概念，而是一種對象之間的組織結構。
定時圖：一種交互圖，強調消息跨越不同對象或參與者的實際時間，而不僅僅只是關心消息的相對順序。
狀態圖：描述一個狀態機，它由狀態、轉移、事件和活動組成，給出了對象的視圖，強調事件導致的對象行為，這非常有助于對反應式的系統建模。在狀態圖中，我們會看到當前的狀態、以后的狀態，以及觸發的條件。
活動圖：將進程或其他計算結構展示為計算內部一步步的控制流和數據流，專注于系統的動態視圖?；顒訄D其實非常類似于 產品經理 或者我們在進行業務分析時畫的的 流程圖 。
交互概覽圖：是活動圖和順序圖的混合物。
以上 14 種 UML 相關的圖，我們給出了圖示的都是重點要關注的，要能夠看到類似的圖就知道它是什么圖。其它的只需要了解它是屬于靜態還是動態圖就好了。
UML 對系統架構的定義是系統的組織結構，包括系統分解的組成部分，以及它們的關聯性、交互機制和指導原則等提供系統設計的信息。具體來說，就是指以下 5 個系統視圖：
1）邏輯視圖，即類、子系統、包和用例實現的子集。
2）進程視圖：它是邏輯視圖的一次執行實例，描述了并發與同步結構。
3）實現視圖：對組成基于系統的物理代碼的文件和構件進行建模。
4）部署視圖：把構件部署到一組物理節點上，表示軟件到硬件的映射和分布結構。
5）用例視圖：最基本的需求分析模型。
OOA，面向對象分析，它的基本任務是運用 OO 方法，對問題域進行分析和理解，正確認識其中的事物及它們之間的關系，找出描述問題域和系統功能所需的類和對象，定義它們的屬性和職責，以及它們之間的各種聯系。核心工作也是兩個，建立系統使用的 用例模型 和 分析模型 。
用例方法是一種動態的需求合成技術，先獲取需求，記錄下來，然后從這些零散的要求和期望中進行整理與提煉，從而建立用例模型。用例模型以 用例圖 為主要表現形式。它包括四個階段：識別參與者、合并需求獲得用例、細化用例描述、調整用例模型。其中前三個階段是必需的，但是第四個階段有一個很重要的概念，就是用例之間的關系，它包括以下三種關系。
包含關系（include）。當可以從兩個或兩個以上的用例中提取公共行為時，應該使用包含關系。
擴展關系（extend）。如果一個用例明顯地混合了兩種或兩種以上的不同場景，即根據情況可能發生多種分支，則可以將這個用例分為一個基本用例和一個或多個擴展用例。
泛化關系。當多個用例共同擁有一種類似的結構和行為的時候，可以將它們的共性抽象成為父用例，其他的用例作為泛化關系中的子用例。
泛化關系我們在后面的分析模型中還會看到，在用例圖中展示泛化關系的情況還是比較少的，如果需要展示的話，連接線和我們下面看到的類圖中的泛化關系的連接線是一致的。
分析模型通過靜態的方式描述系統的基本軟件結構，展現類和對象如何組成系統，以及它們如何保持通信，實現系統行為。分析模型以 類圖 為主要表現形式。建立分析模型的過程包括：定義概念類、確定類之間的關系、為類添加職責、建立交互圖等，其中可以將前三個步驟統稱為 CRC（類、責任、協作） 建模。在這里，確定類之間的關系是分析模型中的重點內容，類之間的關系包括以下六種。
注意到上述六個圖示的連接線是不同的，這個也是要關注的內容，除了定義之外，要能看圖就知道當前的類圖表示的是哪種關系。
今天的內容，如果沒猜錯的話，應該是整個系列的文章教程中圖片最多的，而且也是記憶量最大的。UML 14 個圖的概念含義，其中重點的幾個圖形；用例圖的關系的含義及圖形表示；類圖的六種關系的含義及連接線的表示。這三大塊的內容，說實話，即使你在大學的時候學過軟件工程，如果上班以后沒有接觸過的話，那估計用不了兩三年也能忘得差不多了。在文章開頭也說過，這一篇也是整篇都是重點內容，是需要我們深入學習理解并記憶的。
關于 UML 相關的內容可以通過下方參考鏈接中的內容繼續去深入地學習。就像之前網絡中的 TCP/IP 之類的知識點一樣，UML 以及 面向對象分析 隨隨便便都是可以寫一本書的，而我們學習的內容，其實都只是皮毛，或者說是它們最淺顯的核心知識點而已。沒別的，硬記下來吧，而且這部分知識對各位不管是做開發的小伙伴，還是期望和開發人員溝通的好基友們，都是非常有用的。
參考資料：
UML實踐詳細經典教程----用例圖、順序圖、狀態圖、類圖、包圖、協作圖：http://www.uml.org.cn/oobject/201609092.asp
UML圖中類之間的關系:依賴,泛化,關聯,聚合,組合,實現：http://www.uml.org.cn/oobject/201409232.asp
UML用例圖之泛化(generalization)、擴展(extend)和包含(include)關系：http://www.uml.org.cn/oobject/201104211.asp
《信息系統項目管理師教程》
《某機構培訓資料》
