摘要
本文以實例的方式，展示瞭如何使用UML進行面向對象的分析與設計。本文將假設讀者對UML、面向對象等領域的基本內容已瞭然於胸，所以將不會過多闡述，而將重點放在應用過程上。本文的目的是通過一個完整的實例，展現基於UML的OOA&D過程 的一個簡化模式，幫助朋友們更好的認識UML在OOA&D中起的作用。
前言
經常聽到有朋友抱怨，說學了UML不知該怎麼用，或者畫了UML卻覺得沒什麼作用。其實，就UML本身來說，它只是一種交流工具，它作爲一種標準化交流符號，在OOA&D過程中開發人員間甚至開發人員與客戶之間傳遞信息。另外，UML也可以看做是OO思想的一種表現形式，可以說“OO是神，而UML是型”。所以，想用好UML，紮實的OO思想基礎是必不可少的。然而，在UML應用到開發過程中時，還是有一定的模式可以遵循的。（注意，是模式而不是教條，我下面給出的流程只是一個啓發式過程，而不是說一定要遵循這個流程。）下面，我們通過一個CMS系統的分析設計實例，看看如何將UML應用到實際的開發中。
1.從需求到業務用例圖
OOA&D的第一步，就是了解用戶需求，並將其轉換爲業務用例圖。我們的CMS系統需求非常簡單，大致課做如下描述：這個系統主要用來發布新聞，管理員只需要一個，登錄後可以在後臺發佈新聞。任何人可以瀏覽新聞，瀏覽者可以註冊成爲系統會員，註冊後可對新聞進行評論。管理員在後臺可以對新聞、評論、註冊會員進行管理，如修改、刪除等。
通過以上需求描述，我們畫出如下的業務用例圖：
![]()
這裏要注意三點：
1.業務用例是僅從系統業務角度關注的用例，而不是具體系統的用例。它描述的是“該實現什麼業務”，而不是“系統該提供什麼操作”。例如，在實際系統中，“登錄”肯定要作爲一個用例，但是這是軟件系統中的操作，而用戶所關注的業務是不包含“登錄”的。
2.業務用例僅包含客戶“感興趣”的內容。
3.業務用例所有的用例名應該讓客戶能看懂，如果某個用例的名字客戶看不懂什麼意思，它也許就不適合作爲業務用例。
2.從業務用例圖到活動圖
完成了業務用例圖後，我們要爲每一個業務用例繪製一幅活動圖。活動圖描述了這個業務用例中，用戶可能會進行的操作序列。活動圖有個很重要的使命：從業務用例分析出系統用例。例如，下面是“新聞管理”的活動圖：
![]()
可以看到，一個“新聞管理”這個業務用例，分解出N多系統操作。這裏要特別注意這些操作，其中很多“活動”都很可能是一個系統用例（當然，不是每個都是）。例如，由這個活動圖可以看出，系統中至少要包含以下備選系統用例：登錄、註銷登錄、查看新聞列表、修改新聞、刪除新聞。
這樣，將每個業務用例都繪製出相應的活動圖，再將其中的“活動”整合，就得出所有備選系統用例。
3.從活動圖到系統用例圖
找出所有的備選系統用例後，我們要對他們進行合併和篩選。合併就是將相同的用例合併成一個，篩選就是將不符合系統用例條件的備選用例去掉。
一個系統用例應該是實際使用系統的用戶所進行的一個操作，例如，“查看新聞列表”就不能算一個系統用例，因爲他只是某系統用例的一個序列項。
最終我們得出的系統用例圖如下：
![]()
4.從系統用例圖到用例規約
得出系統用例圖後，我們應該對每一個系統用例給出用例規約。關於用例規約，沒有一個通用的格式，大家可以按照習慣的格式進行編寫。對用例規約唯一的要求就是“清晰易懂”。
下面給出“登錄”這個系統用例的一個規約：
![]()
5.繪製業務領域類圖
完成了上面幾步，下面應該是繪製業務領域類圖了。所謂業務領域類圖要描述一下三點：
1.系統中有哪些實體。
2.這些實體能做什麼操作。
3.實體間的關係。
![]()
這裏要特別強調：這裏的實體不是Actor，而是Actor使用系統時使用的所調用的實體，是處在系統邊界之內的實體。例如，管理員就沒有作爲一個實體出現在這裏，因爲管理員處在系統邊界之外，它所有的工作都可以通過調用這三個類的方法完成。並且，這裏的“註冊會員”實體也不是剛纔用例圖中註冊會員這個Actor，而是作爲一個系統內的業務實體，供Actor們使用的。例如，其中的註冊功能是給註冊會員這個Actor使用，而移除則是給管理員這個Actor使用的。
理解以上這段話非常重要，我經常看到由於混淆了實體和Actor的關係而導致畫出的領域類圖不準確或職責分配不準確。
大家可能還注意到，我們這裏沒有給出每個實體的屬性。其實，在領域分析階段，實體的屬性並不重要，重要的是找出實體的操作。
6.繪製實現類圖
以上這幾步，就是分析的過程。而下面的步驟就是設計了。
設計沒有分析那麼好描述，因爲分析是“客戶面”，它只關心繫統本身的功能和業務，而不關心任何和計算機有關的東西。但是，設計和平臺、語言、開發模型等內容關係緊密，因而很難找出一個一致的過程。但是，一般在設計過程中實現類圖是要繪製的。
實現類圖和領域類圖不一樣，它描述的是真正系統的靜態結構，是和最後的代碼完全一致的。因此，它和平臺關係密切，必須準確給出系統中的實體類、控制類、界面類、接口等元素以及其中的關係。因此，實現類圖是很複雜的，而且是平臺技術有關的。所以，我在這裏不可能給出一個準確的實現類圖，不過爲了描述，我還是給出一個簡化了的實現類圖，當然，它是不準確的，而只是從形式上給出實現類圖的樣子。
我們假設這個系統建構於.NET 3.5平臺上，並且使用ASP.NET MVC作爲表示層，整體使用三層架構。那麼，用戶模塊體系的實現類圖大體是這樣子（不準確）：
![]()
7.繪製序列圖
有了靜態結構，我們還要給出動態結構，這樣，才能看清系統間的類是如何交互的，從而有效幫助程序員進行編碼工作。
![]()
上圖給出的是用戶登錄的序列圖。首先註冊會員作爲Actor，調用UserController的Login方法啓動序列，然後序列按圖示步驟執行。其中UserServices作爲業務組件，首先調用數據訪問組件的GetByName確定用戶是否存在，如果存在，再調用GetByNameAndPassword確定輸入密碼是否是此用戶的密碼。從而完成業務功能。
要注意，序列圖在實際中是很多的，幾乎每個類方法都配有相應的序列圖。
8.後面的步驟
在完成了上面的過程後，就可以進行編碼、調試、測試等工作了。但這些已經超出了本文討論的範圍。
總結
本文簡要給出了使用UML進行OOA&D的過程。當然，由於示例較小，而且本人水平有限，所以給出的相關內容可能不是很準確。而且軟件分析設計本來就不是一個固定模式的過程，隨着系統的不同整個過程會有變化。本文只是想起到一個拋磚引玉的作用，讓朋友們大致瞭解UML的使用流程。至於實際的分析設計，還需要深入的學習和實踐的積累。
本文以實例的方式，展示瞭如何使用UML進行面向對象的分析與設計。本文將假設讀者對UML、面向對象等領域的基本內容已瞭然於胸，所以將不會過多闡述，而將重點放在應用過程上。本文的目的是通過一個完整的實例，展現基於UML的OOA&D過程 的一個簡化模式，幫助朋友們更好的認識UML在OOA&D中起的作用。
前言
經常聽到有朋友抱怨，說學了UML不知該怎麼用，或者畫了UML卻覺得沒什麼作用。其實，就UML本身來說，它只是一種交流工具，它作爲一種標準化交流符號，在OOA&D過程中開發人員間甚至開發人員與客戶之間傳遞信息。另外，UML也可以看做是OO思想的一種表現形式，可以說“OO是神，而UML是型”。所以，想用好UML，紮實的OO思想基礎是必不可少的。然而，在UML應用到開發過程中時，還是有一定的模式可以遵循的。（注意，是模式而不是教條，我下面給出的流程只是一個啓發式過程，而不是說一定要遵循這個流程。）下面，我們通過一個CMS系統的分析設計實例，看看如何將UML應用到實際的開發中。
1.從需求到業務用例圖
OOA&D的第一步，就是了解用戶需求，並將其轉換爲業務用例圖。我們的CMS系統需求非常簡單，大致課做如下描述：這個系統主要用來發布新聞，管理員只需要一個，登錄後可以在後臺發佈新聞。任何人可以瀏覽新聞，瀏覽者可以註冊成爲系統會員，註冊後可對新聞進行評論。管理員在後臺可以對新聞、評論、註冊會員進行管理，如修改、刪除等。
通過以上需求描述，我們畫出如下的業務用例圖：
這裏要注意三點：1.業務用例是僅從系統業務角度關注的用例，而不是具體系統的用例。它描述的是“該實現什麼業務”，而不是“系統該提供什麼操作”。例如，在實際系統中，“登錄”肯定要作爲一個用例，但是這是軟件系統中的操作，而用戶所關注的業務是不包含“登錄”的。
2.業務用例僅包含客戶“感興趣”的內容。
3.業務用例所有的用例名應該讓客戶能看懂，如果某個用例的名字客戶看不懂什麼意思，它也許就不適合作爲業務用例。
2.從業務用例圖到活動圖
完成了業務用例圖後，我們要爲每一個業務用例繪製一幅活動圖。活動圖描述了這個業務用例中，用戶可能會進行的操作序列。活動圖有個很重要的使命：從業務用例分析出系統用例。例如，下面是“新聞管理”的活動圖：
可以看到，一個“新聞管理”這個業務用例，分解出N多系統操作。這裏要特別注意這些操作，其中很多“活動”都很可能是一個系統用例（當然，不是每個都是）。例如，由這個活動圖可以看出，系統中至少要包含以下備選系統用例：登錄、註銷登錄、查看新聞列表、修改新聞、刪除新聞。這樣，將每個業務用例都繪製出相應的活動圖，再將其中的“活動”整合，就得出所有備選系統用例。
3.從活動圖到系統用例圖
找出所有的備選系統用例後，我們要對他們進行合併和篩選。合併就是將相同的用例合併成一個，篩選就是將不符合系統用例條件的備選用例去掉。
一個系統用例應該是實際使用系統的用戶所進行的一個操作，例如，“查看新聞列表”就不能算一個系統用例，因爲他只是某系統用例的一個序列項。
最終我們得出的系統用例圖如下：
4.從系統用例圖到用例規約得出系統用例圖後，我們應該對每一個系統用例給出用例規約。關於用例規約，沒有一個通用的格式，大家可以按照習慣的格式進行編寫。對用例規約唯一的要求就是“清晰易懂”。
下面給出“登錄”這個系統用例的一個規約：
5.繪製業務領域類圖完成了上面幾步，下面應該是繪製業務領域類圖了。所謂業務領域類圖要描述一下三點：
1.系統中有哪些實體。
2.這些實體能做什麼操作。
3.實體間的關係。
這裏要特別強調：這裏的實體不是Actor，而是Actor使用系統時使用的所調用的實體，是處在系統邊界之內的實體。例如，管理員就沒有作爲一個實體出現在這裏，因爲管理員處在系統邊界之外，它所有的工作都可以通過調用這三個類的方法完成。並且，這裏的“註冊會員”實體也不是剛纔用例圖中註冊會員這個Actor，而是作爲一個系統內的業務實體，供Actor們使用的。例如，其中的註冊功能是給註冊會員這個Actor使用，而移除則是給管理員這個Actor使用的。理解以上這段話非常重要，我經常看到由於混淆了實體和Actor的關係而導致畫出的領域類圖不準確或職責分配不準確。
大家可能還注意到，我們這裏沒有給出每個實體的屬性。其實，在領域分析階段，實體的屬性並不重要，重要的是找出實體的操作。
6.繪製實現類圖
以上這幾步，就是分析的過程。而下面的步驟就是設計了。
設計沒有分析那麼好描述，因爲分析是“客戶面”，它只關心繫統本身的功能和業務，而不關心任何和計算機有關的東西。但是，設計和平臺、語言、開發模型等內容關係緊密，因而很難找出一個一致的過程。但是，一般在設計過程中實現類圖是要繪製的。
實現類圖和領域類圖不一樣，它描述的是真正系統的靜態結構，是和最後的代碼完全一致的。因此，它和平臺關係密切，必須準確給出系統中的實體類、控制類、界面類、接口等元素以及其中的關係。因此，實現類圖是很複雜的，而且是平臺技術有關的。所以，我在這裏不可能給出一個準確的實現類圖，不過爲了描述，我還是給出一個簡化了的實現類圖，當然，它是不準確的，而只是從形式上給出實現類圖的樣子。
我們假設這個系統建構於.NET 3.5平臺上，並且使用ASP.NET MVC作爲表示層，整體使用三層架構。那麼，用戶模塊體系的實現類圖大體是這樣子（不準確）：
7.繪製序列圖有了靜態結構，我們還要給出動態結構，這樣，才能看清系統間的類是如何交互的，從而有效幫助程序員進行編碼工作。
上圖給出的是用戶登錄的序列圖。首先註冊會員作爲Actor，調用UserController的Login方法啓動序列，然後序列按圖示步驟執行。其中UserServices作爲業務組件，首先調用數據訪問組件的GetByName確定用戶是否存在，如果存在，再調用GetByNameAndPassword確定輸入密碼是否是此用戶的密碼。從而完成業務功能。要注意，序列圖在實際中是很多的，幾乎每個類方法都配有相應的序列圖。
8.後面的步驟
在完成了上面的過程後，就可以進行編碼、調試、測試等工作了。但這些已經超出了本文討論的範圍。
總結
本文簡要給出了使用UML進行OOA&D的過程。當然，由於示例較小，而且本人水平有限，所以給出的相關內容可能不是很準確。而且軟件分析設計本來就不是一個固定模式的過程，隨着系統的不同整個過程會有變化。本文只是想起到一個拋磚引玉的作用，讓朋友們大致瞭解UML的使用流程。至於實際的分析設計，還需要深入的學習和實踐的積累。
