《UML面向物件建模與設計》第7章 互動模型
雖然寫這個部落格主要目的是為了給我自己做一個思路記憶錄，但是如果你恰好點了進來，那麼先對你說一聲歡迎。我並不是什麼大觸，只是一個菜菜的學生，如果您發現了什麼錯誤或者您對於某些地方有更好的意見，非常歡迎您的斧正！
目錄
✔ 類模型描述系統中的物件及其關係，狀態模型描述物件的生存期，互動模型
7.1用例模型
7.1.1參與者
✔參與者（actor）：系統的直接外部使用者——直接與系統通訊的一個物件或一組物件，但並不是系統的一部分。
▶每個參與者都表示以某種方式對系統起作用的那些物件。
▶參與者可以是人、裝置和其它系統——任何與系統直接互動的事物。
▶例如：客戶和維修技師 是 自動售貨機 的不同參與者。
▶如果物件的行為有不同側面的話，它就可以被繫結到多個參與者上。（例如，某個人既可以是自動收穫機的客戶，也可以是維修技師）
▶參與者有一個明確的用途。相反，物件和類經常是許多不同用途兼而有之的。（比如參與者可以是學生、老師，他們有自己不同的用途，但是當他們都身為參與者的時候，他們的用途都是購買）
▶參與者直接與系統相連——間接相連的物件不是參與者，不應該被包含而作為系統模型的一部分。與間接相連的物件的任何互動都必須通過參與者。（比如排程維修的排程員就不是參與者）
7.1.2用例
✔用例（use case）：系統通過與參與者的互動可以提供的一段連貫的功能。
▶每個用例都會涉及一個或多個參與者以及系統本身。（比如：用例“購買一瓶飲料”涉及客戶參與者）
▶用例涉及系統和其參與者之間的訊息序列。（比如用例“購買一瓶飲料”的時候，要先交錢才能得到飲料）
▶錯誤條件也是用例的一部分。（例如選擇一瓶已經賣完的飲料，就要顯示警告資訊）
▶用例把一部分系統功能相關的所有行為組合在一起。這包括普通主線行為
▶在完整的模型中，用例分割系統的功能。
7.1.3用例圖
| ▶系統包括一組用例和一組參與者。 ▶每個用例表示系統提供的一段功能。 ▶用例集合以某種細節層次顯示了系統完整的功能。 ▶參與者集合表示系統服務的完整的物件集合。 |
 |
7.1.4用例模型的準則
✔ 用例標誌系統的功能，並根據使用者的觀點組織這些功能。
✔ 構建用例模型的指南：
▶確定系統邊界。
▶確保關注參與者。
♦每個參與者都應該有單一的、一致的目的。
♦如果某個現實世界的物件體現了多種目的，就要分別用單個參與者來捕獲它們。
♦參與者要根據系統來定義，而不是作為自主的概念來定義。
▶每個用例必須給使用者提供價值。
▶關聯用例和參與者。
♦每個用例都至少要有一個參與者，每個參與者會參與至少一項用例。
♦用例可能會包括幾個參與者，一個參與者也會參與多個用例。
▶用例是非形式化的。
▶用例可以結構化。
7.2順序模型
✔ 順序模型詳細描述用例的主題。分為場景和順序圖。
✔ 順序圖具有更加結構化的形式。
7.2.1場景
✔ 場景（scenario）：系統在某個特定的執行期內所發生的一系列事件，例如用例。
▶場景可以顯示為一列文字語句。
▶場景包含物件之間的訊息以及物件所執行的活動。
▶文字格式便於編寫，但它無法清晰地顯示每條訊息的傳送者和接收者。
7.2.2順序圖
✔ 順序圖（sequence diagram）：顯示了互動的參與者以及參與者之間的訊息順序。也顯示了系統為了執行全部或部分用例而與其參與者的互動。
▶每個參與者以及系統都用一條垂直的生命線（lifeline）表示。
▶圖中只顯示訊息的順序，而不是它們的準確時序。
▶每個用例需要一張或多張順序圖來描述其行為。
▶我們應該為用例系統內部的每種異常條件繪製一張順序圖。
7.2.3順序模型的準則
①至少為每個用例編寫一種場景。場景中的步驟應該是邏輯命令，問不是單次的按鈕點選。
②把場景抽象成順序圖。順序圖清晰地顯示了每個參與者的貢獻。
③劃分複雜的互動。把大型互動劃分成各個組成的任務，併為每一項任務繪製一張順序圖。
④為每種錯誤條件繪製一張順序圖。顯示系統對於錯誤條件的響應。
7.3活動模型
✔活動圖（activity diagram）：顯示了組成複雜過程的步驟序列，例如演算法或工作流。
▶與順序圖類似，活動圖可以顯示控制流，但專注於操作而不是物件。
▶活動圖在設計演算法和工作的早期階段最為有用。
7.3.1活動
✔ 活動圖的各個步驟都是操作。
✔ 活動圖的目標：顯示覆雜過程內部的各個步驟以及它們之間的順序約束。
✔ 活動可以分解成更細的活動。
7.3.5可執行活動圖
✔ 活動令牌（activity token）：可以放在某個活動符號上，表示它正在執行。
7.3.6活動模型的準則
✔ 不要誤用活動圖。
✔ 讓圖保持平衡。圖中的活動應該具有一致的細節層次。
✔ 注意分支和條件。
✔ 注意併發活動。
✔ 考慮使用可執行的活動圖。可執行的活動圖可以幫助開發者更好地理解系統。