一、用例圖

用例圖的基本概念

用例圖描述一組用例、參與者及它們之間的關系，它以用戶為中心，關注用戶對系統的使用需求和期望。

1. 參與者：我們所理解的client

2. 用例：是系統中一個完整的功能單元，每個用例對應系統的一項特定功能。例如，“新增書籍信息”、“查詢書籍信息”、"登記外借信息"等都是用例，每個用例都代表系統為用戶提供的一個完整功能。

?

1. 用例模型建立的系統化流程

建立用例模型是一個系統化的過程，需要按照特定的步驟進行，確保模型的完整性和準確性。

第一步：識別參與者

1. 用戶：是使用系統功能的人，如普通使用者、管理員等。在識別用戶參與者時，需要考慮不同角色的用戶，他們可能有不同的權限和需求。例如，在圖書管理系統中，除了圖書管理員，還可能有普通讀者、系統管理員等不同角色的用戶。

2. 組織是以集體形式與系統交互的機構，例如企業、學校等。當系統需要與外部組織進行交互時，這些組織也可以作為參與者。例如，圖書管理系統可能需要與出版社系統進行數據交換。

3. 外部系統：是與本系統進行數據交互或功能協作的其他系統。在現代軟件系統中，系統間的集成越來越重要，識別外部系統參與者有助于理解系統的邊界和接口需求。

4. 時間也可作為參與者，例如系統在特定時間觸發某些自動任務，像定時備份、定時統計等。此外，傳感參數（如溫度、濕度、速度）也可能作為特殊參與者，當系統根據這些參數變化觸發相應功能時，它們就扮演了參與者角色。

?

第二步：合并需求獲得用例

將收集到的各種需求進行梳理、整合，從中提煉出系統的功能單元，即確定用例。

這個過程需要從用戶的需求描述中提取出具體的功能點，然后將相關的功能點合并成一個完整的用例。例如，從用戶對系統操作的需求中，確定"查詢信息"、"修改數據"等用例。每個用例應該代表一個完整的、對用戶有價值的功能。

?

第三步：細化用例描述

對每個用例進行詳細說明，包括用例的前置條件、后置條件、基本事件流、擴展事件流等。

• 前置條件：描述了用例執行前系統必須滿足的條件，例如"用戶登錄"用例的前置條件可能是"用戶已注冊"。

• 后置條件：描述了用例執行后系統應該達到的狀態，例如"新增書籍信息"用例的后置條件可能是"書籍信息已保存到數據庫"。

• 基本事件流：描述了用例的正常執行流程，例如"查詢信息"用例的基本事件流包括：用戶輸入查詢條件、系統驗證輸入、系統執行查詢、系統返回結果。

• 擴展事件流：描述了異常情況的處理，例如查詢條件無效、數據庫連接失敗等情況的處理。
  ?

第四步：調整用例模型（可選步驟）

分析用例之間的關系，根據分析結果對用例模型進行調整優化，確保模型的合理性和準確性。

這個步驟包括分析包含關系（一個用例包含另一個用例的功能）、擴展關系（一個用例在特定條件下擴展另一個用例功能）、泛化關系（用例之間的繼承關系）等。

?

2. 用例之間的關系類型

?

二、類圖與對象圖

概念

類圖的關鍵元素

• 類名、方法名、屬性名：類名標識類的名稱；方法名是類中定義的操作；屬性名是類所具有的特征。例如，“書籍”類有書號、書名等屬性，以及新增、修改等方法9。
• 多重度：表示關聯關系中對象的數量關系。例如，“書籍列表”與“書籍”之間是一對多（1對0…*）關系10。
• 關系：類與類之間存在多種關系，如繼承關系（如“非計算機類書籍”“計算機類書籍”繼承自“書籍”）和關聯關系（如“書籍”與“借閱記錄”相關聯）。

多重度（Multiplicity）是在類圖等建模工具中用于表示關聯關系中對象數量對應關系的概念 ，圖中幾種常見多重度含義如下：

• “1” 表示一對一關系。
• “0…*” 代表一對零個或多個的關系。例如在“班級 -學生”關系中，一個班級可以沒有學生（新組建未招生的班級 ），也可以有多個學生 。
• “1…*” 表示一對一個或多個的關系 。比如“訂單 - 商品”關系中，一個訂單至少會包含一種商品，也可能包含多種商品 。
• “*” 表示一個集合中的一個對象對應另一個集合中的多個對象 。例如在“老師 - 學生”關系中，一位老師通常會對應多個學生 。

?

類之間的關系

語義相關性：語義強度越強相關性越強。

關系類型	定義及示例	圖示
依賴關系	定義：若一個事物發生變化會影響另一個事物，二者存在依賴關系。是一種較弱的關系，體現一個類使用另一個類的對象作為局部變量、方法參數等情況。 示例：類A的方法中使用了類B的對象作為參數，此時類A依賴類B。	用帶箭頭的虛線表示，箭頭指向被依賴的類
關聯關系	定義：描述對象之間的連接，是一種結構化關系，表明類之間存在某種語義聯系。 示例：“學生-課程”關系中，學生和課程之間存在關聯。	用實線表示
聚合關系	定義：整體與部分的關系，且整體與部分生命周期不同，部分可以脫離整體獨立存在。 示例：“汽車-輪胎”，輪胎可單獨存在，即便汽車報廢，輪胎可能還能使用。	用帶空心菱形的實線表示，菱形指向整體類
組合關系	定義：整體與部分的關系，但整體與部分生命周期相同，部分不能脫離整體單獨存在。 示例：“人和心臟”，心臟不能脫離人體單獨存活。	用帶實心菱形的實線表示，菱形指向整體類
實現關系	定義：用于描述接口與類之間的關系，類實現接口中定義的操作。 示例：類A實現接口B，類A需實現接口B中定義的所有抽象方法。	用帶箭頭的虛線表示，箭頭指向接口
泛化（繼承）關系	定義：表示特殊與一般的關系，子類繼承父類的屬性和方法，同時可添加自己特有的屬性和方法。 示例：“貓”類繼承“動物”類，“貓”類擁有“動物”類的基本屬性和方法，還可定義自己特有的行為。	用帶空心三角形的實線表示，三角形指向父類

?

三、順序圖與通信圖的交互建模

1. 順序圖

順序圖的基本概念與組成部分

順序圖是一種交互圖，它強調對象之間消息發送的順序，同時顯示對象之間的交互關系，為理解系統的動態行為提供了直觀的視角。

1. 對象（參與者）：是順序圖中的主要參與者，用矩形表示，代表參與交互的實體。 在ATM交易系統中，對象包括CardReader（讀卡器）、ATM（自動取款機）、CustomerConsole（客戶控制臺）、Session（會話）和Transaction（交易）等。這些對象通過生命線連接，形成交互的基礎。

2. 生命線：是對象存在的時間軸，用虛線表示，從對象向下延伸。 生命線表示對象在交互過程中的存在時間，當對象被創建時生命線開始，當對象被銷毀時生命線結束。
   在ATM系統中，Session和Transaction對象都有明確的創建和銷毀過程，體現了對象的生命周期管理。

3. 激活條：是生命線上的（縱向）矩形框，表示對象正在執行操作的時間段。 當對象接收到消息并開始處理時，激活條開始；當處理完成時，激活條結束。
   激活條清楚地展示了對象的活躍狀態，幫助理解對象在交互過程中的參與程度。

?

順序圖中的消息類型

1. 同步消息：是最常用的消息類型，用實心箭頭表示，表示發送者等待接收者的響應。這種同步機制確保了交互的順序性和可靠性。

2. 異步消息：用空心箭頭表示，表示發送者不等待接收者的響應。異步消息適用于不需要立即響應的場景。

3. 返回消息用虛線箭頭表示，表示從同步調用返回的結果。

4. 參與者銷毀消息用生命線底部的"X"標記表示，表示對象的銷毀。當Session和Transaction對象完成其使命后，它們的生命線以"X"結束，表示對象的生命周期結束。

?

順序圖中的組合片段

組合片段是順序圖中的重要控制結構，用于表示復雜的交互邏輯，包括循環、條件分支和可選執行等。

1. 循環片段（Loop）：用于表示重復執行的交互序列。
   在ATM交易流程中，當客戶希望繼續執行交易時，系統會重復執行交易相關的操作。循環片段用矩形框包圍，并標注循環條件"while customer wants to perform transaction"，清楚地表達了重復執行的條件。

2. 條件分支片段（Alt）：用于表示基于條件的不同執行路徑。
   在ATM密碼輸入流程中，系統根據密碼是否正確選擇不同的處理路徑。如果密碼不正確且未超過兩次輸入，系統會要求重新輸入；如果密碼輸入超過兩次，系統會吞卡；如果密碼正確，系統會顯示菜單。

3. 可選片段（Opt）：用于表示條件滿足時才執行的交互序列。

?

2. 通信圖

通信圖強調對象之間的鏈接關系，展示消息的收發順序。例如，在訂單處理系統中，訂單與訂單項之間的交互可以通過通信圖表示。

這是一張通信圖，屬于交互圖的一種，重點展示對象之間消息的收發關系 ，以下是對圖中內容的解讀：

• 對象：圖中存在:aOrder:Order（訂單）、:OrderItem（訂單項）、dispatchForm:Form（調度表單）、:DeliverOrder（交付訂單）、:Product（產品）等對象 。對象名前的冒號表示實例對象，“:”前是對象名，“:”后是類名 。
• 消息：消息用帶有編號和名稱的箭頭表示，編號用于標識消息順序，名稱表示消息操作 。例如：
  • “1: dispatch()” 是aOrder:Order對象發送的調度消息 。
  • “1.1: getPeddleryId()” 是aOrder:Order對象向:OrderItem對象發送的獲取貨號消息，“*[for each orderItem]” 表示針對每個訂單項循環執行 。
  • 消息有實線箭頭（表示正常消息傳遞）和虛線箭頭（表示返回消息）之分 ，如“1.2: PeddleryId” 是:OrderItem對象返回給aOrder:Order對象的貨號消息 。
• 條件和循環：“[PeddleryId Not Exist]” 是條件判斷，當貨號不存在時，執行“1.3: create(PeddleryId)” 創建貨號的操作 。“*[for each orderItem]” 表示循環操作，針對每個訂單項執行相關消息交互 。

?

四、狀態圖與活動圖的動態行為建模

1. 狀態圖

狀態圖是對類描述的補充，用于展現此類對象所具有的可能狀態，以及某些事件發生時其狀態轉移情況。通過狀態圖，我們可以清楚地理解對象在其生命周期中的行為變化。

狀態圖的基本概念

1. 狀態：是對象在某個時刻的特定條件或情況，用圓角矩形表示。
   在熱水器的例子中，“Off”（關閉）和"On"（開啟）是兩個主要狀態，分別表示熱水器的不同工作狀態。

2. 初始狀態：用實心圓表示，表示對象生命周期的開始點。從初始狀態出發的箭頭指向對象的第一個狀態，例如熱水器從初始狀態進入"Off"狀態。

3. 終止狀態：用實心圓外包圍一個圓圈表示，表示對象生命周期的結束或不可逆的條件。在熱水器例子中，"燒壞"狀態就是終止狀態，表示熱水器損壞后無法繼續工作。

?

狀態轉換的組成要素

狀態轉換是狀態圖的核心要素，它描述了對象從一個狀態到另一個狀態的變化過程，包含觸發事件、監護條件和動作三個重要組成部分。

1. 觸發事件：是引起狀態轉換的外部刺激或內部條件變化。在熱水器例子中，“turnOn”（開啟）和"水開了"（水沸騰）都是觸發事件。觸發事件可以是用戶操作、系統事件或時間條件等。

2. 監護條件：是用方括號表示的布爾表達式，決定轉換是否能夠發生。
   當熱水器處于"Off"狀態時，如果觸發"turnOn"事件，系統會檢查監護條件"[有水]“（有水）或”[沒水]"（沒水）。只有當監護條件為真時，轉換才會發生。

3. 動作：是用斜杠"/“表示的操作，在狀態轉換發生時執行。當熱水器從"Off"狀態轉換到"On"狀態時，會執行”/燒水"（燒水）動作，開始加熱過程。

?

2. 活動圖

活動圖是一種特殊的狀態圖，它描述一個操作中要進行的各項活動的執行流程，同時，也常被用來描述一個用例的處理流程或者某種交互流程。

活動圖的基本概念

活動圖將進程或其他計算結構展示為計算內部一步步的控制流和數據流，它強調對象間的控制流程，是描述業務流程和工作流的重要工具。

1. 活動：是活動圖中的基本元素，用圓角矩形表示，代表一個具體的操作。
   在在線訂單處理流程中，“用戶下訂單”、“生成送貨單”、"用戶選擇支付方式"等都是具體的活動。每個活動都代表一個可執行的工作單元。

2. 初始節點：用實心圓表示，表示活動的開始點。

3. 終止節點：用實心圓外包圍一個圓圈表示，表示活動的結束點。

?

活動圖的控制流元素

活動圖通過多種控制流元素來描述復雜的業務流程，包括分支、合并、分叉和匯合等。

1. 決策節點：用菱形表示，用于表示條件分支。

2. 分叉節點：用粗橫線表示，用于表示并行活動的開始。
   當用戶下訂單后，系統會同時執行"生成送貨單"和"用戶選擇支付方式"兩個并行活動。分叉節點允許多個活動同時進行，提高了流程的執行效率。

3. 匯合節點：用粗橫線表示，用于表示并行活動的結束。
   在訂單處理流程中，當"生成送貨單"和"收款"兩個并行活動都完成后，流程會在匯合節點處合并，然后繼續執行"供應商送貨"活動。

4. 轉換：用箭頭表示，用于連接各個活動節點，表示控制流的轉移。轉換上可以標注監護條件，如"[Yes]“和”[No]"，用于表示條件分支的不同路徑。

?

泳道

泳道（Swimlane）是活動圖中的一個重要概念，它將活動圖劃分為不同的區域，每個區域代表一個特定的參與者、部門或系統組件的職責。

在在線訂單處理流程圖中，清晰地劃分了"客戶"、"系統"和"供應商"三個泳道，這使得每個參與者負責的活動一目了然，極大地增強了流程的可讀性和職責的明確性。通過泳道，我們可以直觀地看到不同角色之間的協作和交互，從而更好地理解整個業務流程的協作模式。

?

3. 定時圖

定時圖（也叫計時圖）是一種交互圖，用于展示交互過程中的真實時間信息，具體描述對象狀態變化的時間點以及維持特定狀態的時間段。

定時圖的基本概念

定時圖是UML中專門用于描述時間相關行為的圖，它通過二維坐標系統清晰地展示對象在時間維度上的狀態變化，是分析實時系統和時間敏感系統的重要工具。

1. 時間軸：是定時圖的橫軸，表示時間的流逝。在"標準洗"定時圖中，時間軸從0到75，展示了整個洗衣過程的完整時間線。

2. 狀態軸：是定時圖的縱軸，表示對象可能處于的不同狀態。在洗衣機的例子中，狀態軸從上到下依次為：浸泡、洗滌、脫水、漂洗，這些狀態代表了洗衣機在洗衣過程中的不同工作模式。

3. 狀態變化曲線：是定時圖的核心元素，用階梯狀的折線表示對象狀態的變化過程。水平線段表示對象在某個狀態的持續時間，垂直線段表示狀態的瞬間改變。

?

定時圖的建模價值

定時圖在系統建模中具有獨特的價值，特別是在需要精確控制時間行為的系統中：

1. 實時系統設計，定時圖幫助設計師理解系統的時間約束和性能要求，確保系統能夠滿足實時性要求。在工業控制系統中，定時圖可以指導控制算法的設計，確保各個控制步驟在正確的時間點執行。

2. 性能分析，定時圖為系統性能分析提供了直觀的工具，通過觀察狀態持續時間的分布，分析師可以識別性能瓶頸和優化機會。

3. 系統驗證，定時圖可以作為系統驗證的參考標準，通過比較實際系統的行為與預期行為，驗證系統是否按照設計要求正確運行。

4. 用戶界面設計，定時圖幫助界面設計師理解用戶操作的時序要求，優化界面的響應時間和用戶體驗。

?

五、構件圖與部署圖的系統架構建模

1. 構件圖

構件圖

構件圖是UML中用于描述系統物理結構的重要工具，它展示了系統的各個構件以及它們之間的依賴關系，是大型系統構建和管理的重要基礎。

1. 構件：是構件圖中的基本元素，用帶有兩個小矩形的矩形表示，代表系統中可替換的物理部分。在"機房收費系統"的例子中，機房收費系統.exe是主執行文件構件，機房收費系統源代碼是源代碼構件，而報表、選項卡、窗體、表格等是功能構件。

2. 接口：定義了構件對外提供的服務規范，描述了構件如何與外部環境交互。構件通過接口暴露其功能，其他構件通過接口使用這些功能。

3. 依賴關系：用虛線箭頭表示，描述構件之間的使用關系。

?
構件圖的實際應用示例：機房收費系統

1. 核心應用構件：包括主執行文件機房收費系統.exe和源代碼機房收費系統源代碼。主執行文件是整個系統的入口點，而源代碼構件包含了系統的核心邏輯和業務規則。

2. 功能構件：包括報表、選項卡、窗體、表格等，這些構件分別負責不同的功能模塊。報表構件負責生成各種統計報表，選項卡構件提供標簽頁界面，窗體構件處理用戶界面，表格構件負責數據展示。

3. 外部依賴庫：包括gregn50.dll、tabctl32.dll、msconmct2.ocx、mshflexgd.dll等。這些外部庫為系統提供了特定的功能支持，如報表生成、標簽控制、ActiveX控件和表格顯示等。

4. 依賴關系鏈：清晰地展示了系統的構建層次：主執行文件依賴于源代碼，源代碼依賴于各個功能構件，功能構件依賴于相應的外部庫。這種層次化的依賴關系確保了系統的模塊化和可維護性。

?

包圖：系統組織的邏輯視圖

包圖通過將相關的模型元素組織在一起，為大型系統的建模提供了有效的組織方式，提高了模型的可理解性和可維護性。

1. 包：是包圖中的基本元素，用帶標簽的文件夾圖標表示，代表一個邏輯分組單元。在"機房收費系統"構件圖中，整個系統被組織在一個大的圓角矩形內，這實際上就是一個概念上的包，將相關的構件組織在一起。

2. 包的層次結構：允許包內包含其他包，形成層次化的組織結構。這種層次結構使得大型系統的模型組織更加清晰，便于管理和理解。

3. 包的依賴關系：用虛線箭頭表示，描述包之間的使用關系。包之間的依賴關系反映了系統不同模塊之間的耦合程度。

在"機房收費系統"的例子中，整個系統被組織在一個概念包內，這個包包含了所有相關的構件：

1. 系統包：將機房收費系統的所有構件組織在一起，包括主執行文件、源代碼、功能構件等。這種組織方式使得系統的邊界和范圍更加清晰。

2. 功能分組：通過包的組織，可以將相關的功能構件分組管理。例如，可以將所有UI相關的構件（窗體、選項卡、表格）組織在一個UI包中，將業務邏輯相關的構件組織在業務包中。

3. 依賴管理：包圖幫助識別和管理系統內外的依賴關系。通過包的組織，可以清楚地看到哪些構件屬于系統內部，哪些是外部依賴。

?

包圖的設計原則

設計包圖時需要遵循一些基本原則，以確保模型的有效組織：

1. 內聚性包內的元素應該具有高度的內聚性，即包內的元素應該緊密相關，共同完成特定的功能。

2. 耦合性包之間的耦合應該盡可能低，減少包之間的依賴關系，提高系統的模塊化程度。

3. 層次性包的層次結構應該清晰合理，避免過深的嵌套或過淺的組織，保持適當的抽象層次。

4. 命名規范包的命名應該清晰明確，能夠準確反映包的內容和職責。

?

2. 部署圖

部署圖是UML中用于描述系統物理部署架構的重要工具，它展示了系統的硬件節點、軟件構件以及它們之間的部署關系，是系統架構設計的重要組成部分。

部署圖的基本概念

1. 節點：是部署圖中的基本元素，用矩形框表示，代表運行時的處理單元，如服務器、客戶端、數據庫服務器等。
   在房地產交易系統的例子中，“Bank Server”、"Real Estate Server"和"a PC"都是節點，分別代表銀行服務器、房地產服務器和客戶端個人電腦。

2. 構件：是部署在節點上的軟件單元，用帶有兩個小矩形的矩形表示。
   在銀行服務器節點中，Mortgage Application（抵押貸款應用）和CustomerDB（客戶數據庫）都是構件，分別負責業務邏輯和數據存儲。

3. 接口：定義了構件對外提供的服務規范，用圓形符號表示。
   IMortgageApplication和IListing都是接口，分別定義了抵押貸款應用和列表應用的服務規范。

4. 連接：表示節點之間的物理連接，用實線表示，通常標注連接協議。在房地產交易系統中，客戶端PC與銀行服務器和房地產服務器之間都通過TCP/IP協議連接。

?
部署圖的實際應用示例：房地產交易系統

1. 銀行服務器節點包含兩個核心構件：Mortgage Application（抵押貸款應用）和CustomerDB（客戶數據庫）。抵押貸款應用通過IMortgageApplication接口對外提供服務，同時依賴于客戶數據庫來存儲和檢索客戶信息。這種設計確保了業務邏輯與數據存儲的分離，提高了系統的可維護性。

2. 房地產服務器節點包含Listing（列表應用）和MultipleListings（多重列表存儲）兩個構件。列表應用通過IListing接口對外提供服務，依賴于多重列表存儲來管理房地產信息。這種架構支持房地產信息的集中管理和高效檢索。

3. 客戶端PC節點包含BuyerInterface（買家界面）構件，該構件通過依賴關系連接到銀行服務器的IMortgageApplication接口和房地產服務器的IListing接口。這種設計使得買家可以通過統一的界面訪問抵押貸款服務和房地產列表服務。

4. 網絡連接通過TCP/IP協議將客戶端PC與兩個服務器節點連接起來，形成了完整的分布式系統架構。這種網絡拓撲確保了系統的可擴展性和可靠性。