一般 UML 書籍對 “關聯類別(assocation class)” 的定義及說明如下：

• An association class connection is a UML construct that allows an association connector to have attributes and operations (features).

「UML Distilled」一書提及：關聯類別(assocation class)允許你在關聯上面增加屬性、操作和其它(類別)特性。

書中所舉參考範例如下圖：

圖一　關聯類別 — 摘錄自 "UML Distilled 3rd edition"

文中說明為：從圖一，我們可以看見 Person(個人)可能會參加很多會議。我們必須保有這個人對這些會議的出席情況：藉由新增一個 attentiveness(出席意願)屬性到關聯上，我們可以達到這個目的。

說真的，我對以上對於關聯類別(assocation class) 的定義及說明並不盡滿意！

閱讀全文 »

套件(Package) 圖:

• 群組(Grouping)分類的邏輯單位。
• “Package 圖”內可以包含基本元素(element)，最普遍的即是 “Class”、”Component”，以及 “Sub-Package”。
• “Package 圖” 被用來界定系統範圍的 “內” 與 “外”，是非常有效的工具。
• 每一個 Package 均表達一個 ”命名空間(namespace)”。在 Package 內的 “Class” 均必須有一個 “唯一(unique)” 的名字。例如，Java ”Date” 物件的命名為 “com.sun.java.utils.Date”。

（縮略圖，點擊圖片鏈接看原圖）

溝通(Communication) 圖:

• 與 “Sequence 圖” 性質是相近的，均是表達物件之間的互動。
• 在 UML 1.X 的規格稱之為 “Collaboration Diagram”。
• 與 “Sequence 圖” 較不一樣的是，”Communication 圖” 焦點是關注在 ”並行(parallel)” 的訊息傳遞，而非物件的生命期(Lifeline)。

（縮略圖，點擊圖片鏈接看原圖）

循序(Sequence) 圖:

• 循序(Sequence)圖描述的是一組物件，互動協同合作，以完成源頭(可能是 Actor)所交付的 “Task”。
• 基本上(非強制規範)，一個 Use Case 會有一到多張的循序圖來表達為了履行該 Use Case 的目的，物件之間的互動及訊息(Message)傳遞。每一張循序圖都是一個 “劇本(Scenario)” – 用來捕捉紀錄單一劇本的行為(Behavior)。
• “Keep in mind”！物件是“活的”，有”生命的”。想像就是一組演員正在照一齣劇本(Scenario)共同演出一場戲。
• 畫循序圖要懂得“封裝”不必要的細節。例如，可能就沒有必要在每一張循序圖表達與 ADO.NET 或 JDBC 溝通的內部細節。
• “Use Case”、”Class”、”Sequence” Diagram 俗稱 “UML 三劍客”。中小型專案中，利用三劍客來塑模已是綽綽有餘了。

（縮略圖，點擊圖片鏈接看原圖）

（縮略圖，點擊圖片鏈接看原圖）

（縮略圖，點擊圖片鏈接看原圖）

類別(Class) 圖:

• Class 圖是系統建構的“基石(Building Block)”，表達系統內部的主要結構。是UML 圖中最重要、最必要的。
• Class 圖描述了類別的型態，以及類別之間的靜態關連(static relationship)，同時也表達了類別的屬性(property or attribute)以及操作(operation)。
• 如何找出Class 是系統分析最大的挑戰。基本上，Class 圖與ER(Entity-Relationship) 圖的本質是一致的，均源自於問題領域(ProblemDomain)上的概念(Concept)。
• 如何找Class 有一些“樣式(Patterns)”，其中，以Peter Coad 的“Transaction Pattern”可以有效找出各領域中以“交易” 為主的概念。

物件(Object) 圖:

• 是一個快照(Snapshot)，在某個特定的時間點，依據“Class 圖” 的結構，以範例來
  說明物件在實體系統內(儲存於記憶體)的關係。
• 當不容易看懂“Class 圖” 的結構，可以利用“Object 圖” 以實例來觀察物件的關
  係，輔助“Class 圖” 的解讀。

（縮略圖，點擊圖片鏈接看原圖）

（縮略圖，點擊圖片鏈接看原圖）