UML 圖使用心得

在軟體開發中，從需求工程到代碼工程，都離不開 uml 圖的繪制。今天簡要總結一下我以往使用 uml 圖的一些體會。

很多圖，都是由原始需求到代碼的一種轉換，隻是轉換的程度不一樣。在軟體開發過程中，不同的階段需要不同的 uml 圖，在選擇使用哪些圖時，我們必須了解該圖能表達一些什麼，即它的主要用途，以及它表達的優勢在哪裡：

用例圖

用于需求描述、範圍确定。

所含内容：參與角色集合、功能項集合、角色可用功能集合。

如果需要更詳細地說明需求，則應該在每一個用例中添加相應的用例規約說明。

魯棒圖

則是系統的初步設計。此圖雖然是行為視圖，但是比較偏靜态。

所含内容：角色、界面對象、控制器、事件、實體（資料存儲）。

我認為此圖的關注點在于表達控制器，它能讓我們更好地了解控制器所涉及到的實體以及設計控制器之前的調用關系。

控制器在 oea 中可以了解為 service，而在 ddd 中則可以了解為 domainservice。這些控件器承載了系統中最多的流程性業務邏輯，非常重要。但是在此圖中，隻能看到 service 及其涉及到的 entity，卻不能非常詳細地表達它們之間的互動規則。 

類圖

在需求分析階段，在 ddd 方法論中用于描述領域模型。

在設計階段，則是代碼靜态結構的設計圖。

在反向工程階段，用于精确描述目前軟體的靜态結構。

序列圖（或協作圖）

這兩個表等價，一般使用序列圖。強調對象間的互動關系，時間順序關系。

我一般把它用于反向工程，表達、了解目前的代碼。非常易用。

有時也用在需求分析階段，主要是為了表達時序。

活動圖（或流程圖）

具體描述一個控制流，展現控制流的細節。

狀态圖

關注某一事物狀态的變化。 

以下換一個角度，當在做一個全新的系統時，各階段繪制不同的圖：

需求分析階段： 

用用例圖描述整個系統的功能範圍。 

魯棒圖初步描述某個需求/業務流涉及到的多種對象：界面、控制器、實體。（主要是實體） 

如果某一個需求的流程比較複雜，則使用活動圖描述。

設計階段： 

使用類圖說明類之間的靜态結構關系。 

使用序列圖說明類之間的動态調用時序。 

使用活動圖描述某種算法。

反向工程： 

一般則使用類圖、序列圖來幫助了解現有系統。

一篇說 uml 圖的文章，裡面居然沒有一個 uml 圖，罪過。（主要是這些圖網上一搜一大把，而且貼進來太長了，總是影響整體把握這些圖的意義。）