使用案例圖(Use Case)
1994年由Jacobson發明出來
由使用者角度，以高層次俯瞰並捕捉系統的需求
內部觀點 : 系統做什麼(What)外部觀點 : 參與者與系統怎麼互動(How)
- 界定系統的分界，且不要把太細的細節畫出來
- 界定出系統外與系統內
類別圖(Class)
類別圖的產生是由領域模型轉換來
不是你寫完程式才反向將類別圖畫出來
類別圖是可以幫助人們了解這系統中有哪些物件
這些物件個別有什麼屬性與操作
物件與物件之間又有什麼關係
物件圖(Object)
就像我們寫程式，撰寫類別後
會實例化創造出物件來
所以物件圖也被稱為實例圖(Instance)
通常物件圖的建立並不是必需的，不太常用
- 藉由實際物件，可以幫助我們找尋新的類別
- 檢驗類別圖的準確度
循序圖(Sequence)
唯有循序圖才能表達系統運作時，物件與物件之間的互動行為
並以時間為主軸，可以知道訊息是如何在物件間傳遞與處理程序的
溝通圖(Communication)
在UML1.X版中叫合作圖
UML2.0版改叫溝通圖
主要是描述物件間的互動行為
其實我覺得可以想成是循序圖的另一種表達方式
而且很多工具也支援將循序圖轉為溝通圖
或反向溝通圖轉成循序圖
狀態圖(State)
以上為利用狀態圖描述學生一天的狀態
了解物件、子系統、系統等
在生命週期中，所有可能的狀態
以及造成狀態轉換的事件
且不同狀態下會如何活動
通常狀態圖都是為了”一個物件類別”而畫
以了解這類別存活時的行為
活動圖(Activity)
其實可以把它看作流程圖
通常可以補足使用案例無法表達的部分
透過活動圖可以看出不同參與者會經歷的作業活動
作業活動中轉換和條件
特別是還可以描述具平行處理的情境
元件圖(Component)
元件，其本質其實就是物件
但最大的不同點在於物件強調的是 “個體(Instance)” 的特徵及外在行為而元件強調的是 “介面(Interface)” 的溝通
用模組化的方式去表達軟體的架構
以及模組與模組之間的相依關係
部署圖(Deployment)
通常都是畫完元件圖後，才畫部署圖
說明系統中應用到的軟硬體
如 : 處理器、處理元件是如何配置
甚至畫出硬體或網路基礎建設的拓樸
套件圖(Package)
上圖表達出套件與套件之間的關係
也可以描述套件與其他群組元素的組成關係
時序圖(Timing)
基本上用不太到
主要專注表達即時(Real-time)的環境上
並且用時間尺規表達物件在不同時間點上的狀態變化
互動概念圖(Interaction Overview)
可以看做就是活動圖的變形
偶爾會用，因為適合用在分析和設計階段
通常以活動圖為主要還說明活動與控制流程
更細部的活動就已互動圖(包含循序圖、時序圖、溝通圖)來表達
複合結構圖(Composite Structure)
也是個很少用的圖
也跟前面的元件圖、實例圖很像
只是著重以類別的角度還表達實例間如何運作
或物件如何達成目標
輪廓圖(Profile)
也是一個不常用的圖，又稱剖面圖
當你的code跟圖會有關係時
用到MDA時
你就可能會用到
