本節(jié)向大家向大家介紹一下UML面向?qū)ο蠓治雠c設(shè)計，主要分布個步驟向大家介紹，相信通過本節(jié)的介紹你對UML面向?qū)ο蠓治雠c設(shè)計一定會有明確的認(rèn)識。下面是詳細(xì)介紹。

UML面向?qū)ο蠓治雠c設(shè)計

前言

就UML本身來說，它只是一種交流工具，它作為一種標(biāo)準(zhǔn)化交流符號，在OOA&D過程中開發(fā)人員間甚至開發(fā)人員與客戶之間傳遞信息。另外，UML也可以看做是OO思想的一種表現(xiàn)形式，可以說“OO是神，而UML是型”。所以，想用好UML，扎實的OO思想基礎(chǔ)是必不可少的。然而，在UML應(yīng)用到開發(fā)過程中時，還是有一定的模式可以遵循的。下面，我們通過一個CMS系統(tǒng)的分析設(shè)計實例，看看如何將UML應(yīng)用到實際的開發(fā)中。

1.從需求到業(yè)務(wù)用例圖

OOA&D的***步，就是了解用戶需求，并將其轉(zhuǎn)換為業(yè)務(wù)用例圖。我們的CMS系統(tǒng)需求非常簡單，大致課做如下描述：這個系統(tǒng)主要用來發(fā)布新聞，管理員只需要一個，登錄后可以在后臺發(fā)布新聞。任何人可以瀏覽新聞，瀏覽者可以注冊成為系統(tǒng)會員，注冊后可對新聞進(jìn)行評論。管理員在后臺可以對新聞、評論、注冊會員進(jìn)行管理，如修改、刪除等。
通過以上需求描述，我們畫出如下的業(yè)務(wù)用例圖。

這里要注意三點：

1.業(yè)務(wù)用例是僅從系統(tǒng)業(yè)務(wù)角度關(guān)注的用例，而不是具體系統(tǒng)的用例。它描述的是“該實現(xiàn)什么業(yè)務(wù)”，而不是“系統(tǒng)該提供什么操作”。例如，在實際系統(tǒng)中，“登錄”肯定要作為一個用例，但是這是軟件系統(tǒng)中的操作，而用戶所關(guān)注的業(yè)務(wù)是不包含“登錄”的。
2.業(yè)務(wù)用例僅包含客戶“感興趣”的內(nèi)容。
3.業(yè)務(wù)用例所有的用例名應(yīng)該讓客戶能看懂，如果某個用例的名字客戶看不懂什么意思，它也許就不適合作為業(yè)務(wù)用例。

2.從業(yè)務(wù)用例圖到活動圖

UML面向?qū)ο蠓治雠c設(shè)計完成了業(yè)務(wù)用例圖后，我們要為每一個業(yè)務(wù)用例繪制一幅活動圖。活動圖描述了這個業(yè)務(wù)用例中，用戶可能會進(jìn)行的操作序列。活動圖有個很重要的使命：從業(yè)務(wù)用例分析出系統(tǒng)用例。例如，下面是“新聞管理”的活動圖：

可以看到，一個“新聞管理”這個業(yè)務(wù)用例，分解出N多系統(tǒng)操作。這里要特別注意這些操作，其中很多“活動”都很可能是一個系統(tǒng)用例（當(dāng)然，不是每個都是）。例如，由這個活動圖可以看出，系統(tǒng)中至少要包含以下備選系統(tǒng)用例：登錄、注銷登錄、查看新聞列表、修改新聞、刪除新聞。
這樣，將每個業(yè)務(wù)用例都繪制出相應(yīng)的活動圖，再將其中的“活動”整合，就得出所有備選系統(tǒng)用例。

3.從活動圖到系統(tǒng)用例圖

找出所有的備選系統(tǒng)用例后，我們要對他們進(jìn)行合并和篩選。合并就是將相同的用例合并成一個，篩選就是將不符合系統(tǒng)用例條件的備選用例去掉。
一個系統(tǒng)用例應(yīng)該是實際使用系統(tǒng)的用戶所進(jìn)行的一個操作，例如，“查看新聞列表”就不能算一個系統(tǒng)用例，因為他只是某系統(tǒng)用例的一個序列項。
最終我們得出的系統(tǒng)用例圖如下：

4.從系統(tǒng)用例圖到用例規(guī)約

UML面向?qū)ο蠓治雠c設(shè)計得出系統(tǒng)用例圖后，我們應(yīng)該對每一個系統(tǒng)用例給出用例規(guī)約。關(guān)于用例規(guī)約，沒有一個通用的格式，大家可以按照習(xí)慣的格式進(jìn)行編寫。對用例規(guī)約唯一的要求就是“清晰易懂”。/p>
下面給出“登錄”這個系統(tǒng)用例的一個規(guī)約。

5.繪制業(yè)務(wù)領(lǐng)域類圖

完成了上面幾步，下面應(yīng)該是繪制業(yè)務(wù)領(lǐng)域類圖了。所謂業(yè)務(wù)領(lǐng)域類圖要描述一下三點：

1.系統(tǒng)中有哪些實體。
2.這些實體能做什么操作。
3.實體間的關(guān)系。

這里要特別強(qiáng)調(diào)：這里的實體不是Actor，而是Actor使用系統(tǒng)時使用的所調(diào)用的實體，是處在系統(tǒng)邊界之內(nèi)的實體。例如，管理員就沒有作為一個實體出現(xiàn)在這里，因為管理員處在系統(tǒng)邊界之外，它所有的工作都可以通過調(diào)用這三個類的方法完成。并且，這里的“注冊會員”實體也不是剛才用例圖中注冊會員這個Actor，而是作為一個系統(tǒng)內(nèi)的業(yè)務(wù)實體，供Actor們使用的。例如，其中的注冊功能是給注冊會員這個Actor使用，而移除則是給管理員這個Actor使用的。
理解以上這段話非常重要，我經(jīng)?？吹接捎诨煜藢嶓w和Actor的關(guān)系而導(dǎo)致畫出的領(lǐng)域類圖不準(zhǔn)確或職責(zé)分配不準(zhǔn)確。
大家可能還注意到，我們這里沒有給出每個實體的屬性。其實，在領(lǐng)域分析階段，實體的屬性并不重要，重要的是找出實體的操作。

6.繪制實現(xiàn)類圖

以上這幾步，就是分析的過程。而下面的步驟就是UML面向?qū)ο蠓治雠c設(shè)計中的設(shè)計了。
設(shè)計沒有分析那么好描述，因為分析是“客戶面”，它只關(guān)心系統(tǒng)本身的功能和業(yè)務(wù)，而不關(guān)心任何和計算機(jī)有關(guān)的東西。但是，設(shè)計和平臺、語言、開發(fā)模型等內(nèi)容關(guān)系緊密，因而很難找出一個一致的過程。但是，一般在設(shè)計過程中實現(xiàn)類圖是要繪制的。

實現(xiàn)類圖和領(lǐng)域類圖不一樣，它描述的是真正系統(tǒng)的靜態(tài)結(jié)構(gòu)，是和***的代碼完全一致的。因此，它和平臺關(guān)系密切，必須準(zhǔn)確給出系統(tǒng)中的實體類、控制類、界面類、接口等元素以及其中的關(guān)系。因此，實現(xiàn)類圖是很復(fù)雜的，而且是平臺技術(shù)有關(guān)的。所以，我在這里不可能給出一個準(zhǔn)確的實現(xiàn)類圖，不過為了描述，我還是給出一個簡化了的實現(xiàn)類圖，當(dāng)然，它是不準(zhǔn)確的，而只是從形式上給出實現(xiàn)類圖的樣子。
我們假設(shè)這個系統(tǒng)建構(gòu)于.NET3.5平臺上，并且使用ASP.NETMVC作為表示層，整體使用三層架構(gòu)。那么，用戶模塊體系的實現(xiàn)類圖大體是這樣子（不準(zhǔn)確）：

7.繪制序列圖

有了靜態(tài)結(jié)構(gòu)，我們還要給出動態(tài)結(jié)構(gòu)，這樣，才能看清系統(tǒng)間的類是如何交互的，從而有效幫助程序員進(jìn)行編碼工作。
要注意，序列圖在實際中是很多的，幾乎每個類方法都配有相應(yīng)的序列圖。

8.后面的步驟

UML面向?qū)ο蠓治雠c設(shè)計，在完成了上面的過程后，就可以進(jìn)行編碼、調(diào)試、測試等工作了。但這些已經(jīng)超出了本文討論的范圍。

總結(jié)

本文簡要給出了使用UML進(jìn)行OOA&D的過程。當(dāng)然，由于示例較小，而且本人水平有限，所以給出的相關(guān)內(nèi)容可能不是很準(zhǔn)確。而且軟件分析設(shè)計本來就不是一個固定模式的過程，隨著系統(tǒng)的不同整個過程會有變化。本文只是想起到一個拋磚引玉的作用，讓朋友們大致了解UML的使用流程。至于實際的分析設(shè)計，還需要深入的學(xué)習(xí)和實踐的積累。

【編輯推薦】

1. 用UML構(gòu)件進(jìn)行面向構(gòu)件分析與設(shè)計
2. UML動態(tài)建模機(jī)制專家解析
3. 技術(shù)分享 UML面向?qū)ο蠓治黾捌浒ǖ膱D、建模步驟
4. 解析UML面向?qū)ο蠓治雠c建模中交互圖
5. 體驗免費UML建模工具