例解基于UML的面向對象分析與設計

2008-11-0811:16byEricZhang(T2噬菌體),8762visits,網(wǎng)摘,收藏,編輯摘要

本文以實例的方式，展示了如何使用UML進行面向對象的分析與設計。本文將假設讀者對UML、面向對象等領域的基本內容已了然于胸，所以將不會過多闡述，而將重點放在應用過程上。本文的目的是通過一個完整的實例，展現(xiàn)基于UML的OOA&D過程的一個簡化模式，幫助朋友們更好的認識UML在OOA&D中起的作用。前言

經(jīng)常聽到有朋友抱怨，說學了UML不知該怎么用，或者畫了UML卻覺得沒什么作用。其實，就UML本身來說，它只是一種交流工具，它作為一種標準化交流符號，在OOA&D過程中開發(fā)人員間甚至開發(fā)人員與客戶之間傳遞信息。另外，UML也可以看做是OO思想的一種表現(xiàn)形式，可以說“OO是神，而UML是型”。所以，想用好UML，扎實的OO思想基礎是必不可少的。然而，在UML應用到開發(fā)過程中時，還是有一定的模式可以遵循的。（注意，是模式而不是教條，我下面給出的流程只是一個啟發(fā)式過程，而不是說一定要遵循這個流程。）下面，我們通過一個CMS系統(tǒng)的分析設計實例，看看如何將UML應用到實際的開發(fā)中。從需求到業(yè)務用例圖

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

通過以上需求描述，我們畫出如下的業(yè)務用例圖：

這里要注意三點：

1.業(yè)務用例是僅從系統(tǒng)業(yè)務角度關注的用例，而不是具體系統(tǒng)的用例。它描述的是“該實現(xiàn)什么業(yè)務”，而不是“系統(tǒng)該提供什么操作”。例如，在實際系統(tǒng)中，“登錄”肯定要作為一個用例，但是這是軟件系統(tǒng)中的操作，而用戶所關注的業(yè)務是不包含“登錄”的。

2.業(yè)務用例僅包含客戶“感興趣”的內容。

3.業(yè)務用例所有的用例名應該讓客戶能看懂，如果某個用例的名字客戶看不懂什么意思，它也許就不適合作為業(yè)務用例。從業(yè)務用例圖到活動圖

完成了業(yè)務用例圖后，我們要為每一個業(yè)務用例繪制一幅活動圖?；顒訄D描述了這個業(yè)務用例中，用戶可能會進行的操作序列。活動圖有個很重要的使命：從業(yè)務用例分析出系統(tǒng)用例。例如，下面是“新聞管理”的活動圖：

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

這樣，將每個業(yè)務用例都繪制出相應的活動圖，再將其中的“活動”整合，就得出所有備選系統(tǒng)用例。從活動圖到系統(tǒng)用例圖

找出所有的備選系統(tǒng)用例后，我們要對他們進行合并和篩選。合并就是將相同的用例合并成一個，篩選就是將不符合系統(tǒng)用例條件的備選用例去掉。

一個系統(tǒng)用例應該是實際使用系統(tǒng)的用戶所進行的一個操作，例如，“查看新聞列表”就不能算一個系統(tǒng)用例，因為他只是某系統(tǒng)用例的一個序列項。

最終我們得出的系統(tǒng)用例圖如下：

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

得出系統(tǒng)用例圖后，我們應該對每一個系統(tǒng)用例給出用例規(guī)約。關于用例規(guī)約，沒有一個通用的格式，大家可以按照習慣的格式進行編寫。對用例規(guī)約唯一的要求就是“清晰易懂”。

下面給出“登錄”這個系統(tǒng)用例的一個規(guī)約：

業(yè)務領域類圖

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

1.系統(tǒng)中有哪些實體。

2.這些實體能做什么操作。

3.實體間的關系。

這里要特別強調：這里的實體不是Actor，而是Actor使用系統(tǒng)時使用的所調用的實體，是處在系統(tǒng)邊界之內的實體。例如，管理員就沒有作為一個實體出現(xiàn)在這里，因為管理員處在系統(tǒng)邊界之外，它所有的工作都可以通過調用這三個類的方法完成。并且，這里的“注冊會員”實體也不是剛才用例圖中注冊會員這個Actor，而是作為一個系統(tǒng)內的業(yè)務實體，供Actor們使用的。例如，其中的注冊功能是給注冊會員這個Actor使用，而移除則是給管理員這個Actor使用的。

理解以上這段話非常重要，我經(jīng)?？吹接捎诨煜藢嶓w和Actor的關系而導致畫出的領域類圖不準確或職責分配不準確。

大家可能還注意到，我們這里沒有給出每個實體的屬性。其實，在領域分析階段，實體的屬性并不重要，重要的是找出實體的操作。

實現(xiàn)類圖

以上這幾步，就是分析的過程。而下面的步驟就是設計了。

設計沒有分析那么好描述，因為分析是“客戶面”，它只關心系統(tǒng)本身的功能和業(yè)務，而不關心任何和計算機有關的東西。但是，設計和平臺、語言、開發(fā)模型等內容關系緊密，因而很難找出一個一致的過程。但是，一般在設計過程中實現(xiàn)類圖是要繪制的。

實現(xiàn)類圖和領域類圖不一樣，它描述的是真正系統(tǒng)的靜態(tài)結構，是和最后的代碼完全一致的。因此，它和平臺關系密切，必須準確給出系統(tǒng)中的實體類、控制類、界面類、接口等元素以及其中的關系。因此，實現(xiàn)類圖是很復雜的，而且是平臺技術有關的。所以，我在這里不可能給出一個準確的實現(xiàn)類圖，不過為了描述，我還是給出一個簡化了的實現(xiàn)類圖，當然，它是不準確的，而只是從形式上給出實現(xiàn)類圖的樣子。

我們假設這個系統(tǒng)建構于.NET3.5平臺上，并且使用ASP.NETMVC作為表示層，整體使用三層架構。那么，用戶模塊體系的實現(xiàn)類圖大體是這樣子（不準確）：

序列圖

有了靜態(tài)結構，我們還要給出動態(tài)結構，這樣，才能看清系統(tǒng)間的類是如何交互的，從而有效幫助程序員進行編碼工作。

上圖給出的是用戶登錄的序列圖。首先注冊會員作為Actor，調用UserController的Login方法啟動序列，然后序列按圖示步驟執(zhí)行。其中UserServices作為業(yè)務組件，首先調用數(shù)據(jù)訪問組件的GetByName確定用戶是否存在，如果存在，再調用GetByNameAndPassword確定輸入密碼是否是此用戶的密碼。從而完成業(yè)務功能。

要注意，序列圖在實際中是很多的，幾乎每個類方法都配有相應的序列圖。最后的步驟

在完成了上面的過程后，就可以進行編碼、調試、測試等工作了。但這些已經(jīng)超出了本文討論的范圍。總結

本文簡要給出了使用UML進行OOA&D的過程。當然，由于示例較小，而且本人水平有限，所以給出的相關內容可能不是很準確。而且軟件分析設計本來就不是一個固定模式的過程，隨著系統(tǒng)的不同整個過程會有變化。本文只是想起到一個拋磚引玉的作用，讓朋友們大致了解UML的使用流程。至于實際的分析設計，還需要深入的學習和實踐的積累。2008-10-2612:04byEricZhang(T2噬菌體),3733visits,網(wǎng)摘,收藏,編輯摘要

本文通過對一個“學生選課系統(tǒng)”示例的簡要分析與設計，說明UML圖之一類圖的兩種作用及存在形式，以期借此澄清有些朋友可能對類圖存在的誤解與困惑。

前言

在OOA與OOD大行其道的今天，UML在系統(tǒng)分析與設計中得到了廣泛的采用。而在UML的9種圖中，類圖是最重要也是使用最普遍的圖之一。但是，在與一些朋友，特別是初學者的聊天當中，我發(fā)現(xiàn)很多朋友對類圖的作用及使用方法存在一定的誤解和困惑。于是我寫下這篇文章，希望本文能在一定程度上幫助這些朋友更好的認識和使用類圖。當然，由于我對UML的認識并不很深刻，所以在文章中有錯誤和疏漏之處，懇請大家批評指正。

AvsD

要想正確認識與使用類圖，我們首先要正確認識兩個概念——“A”和“D”。

A是Analyse的縮寫，即我們所說的“分析”；而D是Design的縮寫，即“設計”。一般來說，一個系統(tǒng)在編碼前，都要經(jīng)過分析與設計兩個步驟。而對這兩個概念認識的模糊不清，正是導致很多朋友無法正確使用類圖的原因。

分析，我對其的解釋是：根據(jù)用戶的需求，做出一系列與業(yè)務領域相關而和計算機技術無關的整理與識別。

很多朋友有個錯誤的認識，認為軟件開發(fā)工作一定要由懂計算機的人完成，不懂計算機的人怎么能進行軟件開發(fā)呢？當然，對于設計和編碼等工作，當然是這樣，但是唯有“分析”這一工作，可以由完全不懂計算機的人來進行，甚至從某種程度上說，不懂計算機的人更適合做軟件分析師的工作。因為想要把分析做好，一定要僅與業(yè)務相關，而拋開具體技術。一個滿腦子計算機技術的程序員去做分析時，很容易想到編碼、實現(xiàn)、平臺、數(shù)據(jù)庫設計等具體細節(jié)，這種思維形式恰恰成為做好分析的最大障礙。此為誤解一：只有懂計算機技術的人才能做系統(tǒng)分析師。我現(xiàn)在所在的研究所（北京航空航天大學計算機學院軟件工程研究所）曾經(jīng)接過一個日本項目，當時日方那邊派來一個系統(tǒng)分析師對計算機就完全是外行，而是一個領域專家，但是他很好的完成了系統(tǒng)分析的工作。

另外一個誤解就是UML圖，特別是類圖，就是給開發(fā)人員用的。很多人覺得UML是計算機業(yè)內專業(yè)語言，不懂計算機的怎么能用它呢？用了做什么呢？但是很多不懂計算機的系統(tǒng)分析師在進行分析工作時，也在使用UML圖，而類圖就是其中一種。一般情況下，分析師在進行分析時，確實會繪制一套類圖。但是，它所畫的類圖不管是從視角還是作用，與設計師所做的類圖是不同的，具體將在下面介紹。此為誤解二：只有計算機人士才使用UML圖。

分析說完了，下面說設計。與分析不同，我對設計的解釋是：根據(jù)分析材料與技術平臺，確定軟件系統(tǒng)的架構結構、編碼方式及一切與具體技術有關的宏觀問題。

這里可以看到，設計與分析不同，它必須由計算機方面的人來完成，因為它和具體技術是息息相關的。而且，設計師在進行設計時，也會繪制一套類圖。

到這里，我們明確了，原來軟件在分析與設計兩個階段各自會繪制一套類圖，而且是由分析師和設計師兩個不同的角色繪制的。那么這兩套類圖有什么異同呢？下面將解釋這個問題。

領域類圖vs實現(xiàn)類圖

上文提到，在軟件分析與設計過程中，會由兩種角色產(chǎn)生兩套類圖。一般情況下，分析師繪制的類圖叫做“領域類圖”，而設計師繪制的類圖叫做“實現(xiàn)類圖”。這里要聲明，這兩個名詞是我的習慣性叫法，并不是大家都認同的通用叫法。下面，我對這兩種類圖給出我的定義：

領域類圖：產(chǎn)生于分析階段，由系統(tǒng)分析師繪制，主要作用是描述業(yè)務實體的靜態(tài)結構，包括業(yè)務實體、各個業(yè)務實體所具有的業(yè)務屬性及業(yè)務操作、業(yè)務實體之間具有的關系。

雖然這個類圖也叫“類圖”，但是說實話，它和編程中的“類”實在是沒啥關系，因為最后的系統(tǒng)中可能根本沒有類和它們對應，而且很多最后系統(tǒng)中的類如控制類和界面類這套類圖中也沒有。也就是說這套圖和具體技術無關，也不是畫給程序員看的，它只是表達業(yè)務領域中的一個靜態(tài)結構。下面給個例子：

這是一個選課系統(tǒng)的簡單領域分析類圖?？梢钥吹?，主要實體有教師、學生、課程和開課安排。每個實體標注了其在業(yè)務上具有的屬性和方法。而且圖中還標明了實體間的關系。

但是，最終系統(tǒng)中可能沒有一個學生類和其對應。因為最終系統(tǒng)中有哪些類、各個類有什么屬性、方法依賴于所選擇的平臺和架構。例如，如果使用了Struts2，則會存在很多Action類，而使用了ASP.NETMVC，則會有很多Controller類等，所以，領域類圖只于業(yè)務有關，和具體實現(xiàn)及編碼等計算機技術無關。

下面該說說實現(xiàn)類圖了：

實現(xiàn)類圖：產(chǎn)生于設計階段，由系統(tǒng)設計師繪制，其作用是描述系統(tǒng)的架構結構、指導程序員編碼。它包括系統(tǒng)中所有有必要指明的實體類、控制類、界面類及與具體平臺有關的所有技術性信息。

就像上面的領域類圖，如果你把它交給程序員編碼，我想程序員會瘋掉，因為它沒有提供任何編碼的依據(jù)。假如我們使用的是.NET平臺分層架構，并使用ASP.NETMVC，則設計師應該在實現(xiàn)類圖中繪制出所有的實體類、數(shù)據(jù)訪問類、業(yè)務邏輯類和界面類，界面類又分為視圖類、控制器類等等，還要表示出IoC和Aop等信息，并明確指出各個類的屬性、方法，不能有遺漏，因為最終程序員實現(xiàn)程序的依據(jù)