領域模型設計類圖 vs 實現模型設計類圖

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

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

A vs D
      要想正確認識與使用類圖,我們首先要正確認識兩個概念——“A”和“D”。
      A是Analyse的縮寫,即我們所說的“分析”;而D是Design的縮寫,即“設計”。一般來說,一個系統在編碼前,都要經過分析與設計兩個步驟。而對這兩個概念認識的模糊不清,正是導致很多朋友無法正確使用類圖的原因。
      分析,我對其的解釋是:根據用戶的需求,做出一系列與業務領域相關而和計算機技術無關的整理與識別。
      
很多朋友有個錯誤的認識,認爲軟件開發工作一定要由懂計算機的人完成,不懂計算機的人怎麼能進行軟件開發呢?當然,對於設計和編碼等工作,當然是這樣,但是唯有“分析”這一工作,可以由完全不懂計算機的人來進行,甚至從某種程度上說,不懂計算機的人更適合做軟件分析師的工作。因爲想要把分析做好,一定要僅與業務相關,而拋開具體技術。一個滿腦子計算機技術的程序員去做分析時,很容易想到編碼、實現、平臺、數據庫設計等具體細節,這種思維形式恰恰成爲做好分析的最大障礙。此爲誤解一:只有懂計算機技術的人才能做系統分析師。我現在所在的研究所(北京航空航天大學計算機學院軟件工程研究所)曾經接過一個日本項目,當時日方那邊派來一個系統分析師對計算機就完全是外行,而是一個領域專家,但是他很好的完成了系統分析的工作。
      另外一個誤解就是UML圖,特別是類圖,就是給開發人員用的。很多人覺得UML是計算機業內專業語言,不懂計算機的怎麼能用它呢?用了做什麼呢?但是很多不懂計算機的系統分析師在進行分析工作時,也在使用UML圖,而類圖就是其中一種。一般情況下,分析師在進行分析時,確實會繪製一套類圖。但是,它所畫的類圖不管是從視角還是作用,與設計師所做的類圖是不同的,具體將在下面介紹。此爲誤解二:只有計算機人士才使用UML圖。
      分析說完了,下面說設計。與分析不同,我對設計的解釋是:根據分析材料與技術平臺,確定軟件系統的架構結構、編碼方式及一切與具體技術有關的宏觀問題。
      這裏可以看到,設計與分析不同,它必須由計算機方面的人來完成,因爲它和具體技術是息息相關的。而且,設計師在進行設計時,也會繪製一套類圖。
      到這裏,我們明確了,原來軟件在分析與設計兩個階段各自會繪製一套類圖,而且是由分析師和設計師兩個不同的角色繪製的。那麼這兩套類圖有什麼異同呢?下面將解釋這個問題。

領域類圖 vs 實現類圖
      上文提到,在軟件分析與設計過程中,會由兩種角色產生兩套類圖。一般情況下,分析師繪製的類圖叫做“領域類圖”,而設計師繪製的類圖叫做“實現類圖”。這裏要聲明,這兩個名詞是我的習慣性叫法,並不是大家都認同的通用叫法。下面,我對這兩種類圖給出我的定義:
      領域類圖:產生於分析階段,由系統分析師繪製,主要作用是描述業務實體的靜態結構,包括業務實體、各個業務實體所具有的業務屬性及業務操作、業務實體之間具有的關係。
      雖然這個類圖也叫“類圖”,但是說實話,它和編程中的“類”實在是沒啥關係,因爲最後的系統中可能根本沒有類和它們對應,而且很多最後系統中的類如控制類和界面類這套類圖中也沒有。也就是說這套圖和具體技術無關,也不是畫給程序員看的,它只是表達業務領域中的一個靜態結構。下面給個例子:

      這是一個選課系統的簡單領域分析類圖。可以看到,主要實體有教師、學生、課程和開課安排。每個實體標註了其在業務上具有的屬性和方法。而且圖中還標明瞭實體間的關係。
      但是,最終系統中可能沒有一個學生類和其對應。因爲最終系統中有哪些類、各個類有什麼屬性、方法依賴於所選擇的平臺和架構。例如,如果使用了Struts2,則會存在很多Action類,而使用了ASP.NET MVC,則會有很多Controller類等,所以,領域類圖只於業務有關,和具體實現及編碼等計算機技術無關。
      下面該說說實現類圖了:
      實現類圖:產生於設計階段,由系統設計師繪製,其作用是描述系統的架構結構、指導程序員編碼。它包括系統中所有有必要指明的實體類、控制類、界面類及與具體平臺有關的所有技術性信息。
      就像上面的領域類圖,如果你把它交給程序員編碼,我想程序員會瘋掉,因爲它沒有提供任何編碼的依據。假如我們使用的是.NET平臺分層架構,並使用ASP.NET MVC,則設計師應該在實現類圖中繪製出所有的實體類、數據訪問類、業務邏輯類和界面類,界面類又分爲視圖類、控制器類等等,還要表示出IoC和Aop等信息,並明確指出各個類的屬性、方法,不能有遺漏,因爲最終程序員實現程序的依據就是實現類圖。

總結
      最後,我們總結一下本文的要點:
      1.軟件分析與設計是編碼前的兩個階段,其中分析僅與業務有關,而與技術無關。設計以分析爲基礎,主要與具體技術有關。
      2.分析階段由分析師繪製領域類圖,設計階段由設計師繪製實現類圖。
      3.領域類圖表示系統的靜態領域結構,其中的類不與最終程序中的類對應;設計類圖表示系統的技術架構,是程序員的編碼依據,其中的類與系統中的類對應。
      4.領域類圖中類的屬性與操作僅關注與業務相關的部分,實現類圖中的屬性與操作要包括最終需要實現的全部方法與操作。

希望本文對您能有所幫助!


轉自:http://www.cnblogs.com/leoo2sk/archive/2008/10/26/1319773.html

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章