正確認識使用UML類圖

正確認識使用UML類圖

前言

在OOA與OOD大行其道的今天，UML在系統分析與設計中獲得了普遍的採用。而在UML的9種圖中，UML類圖是最重要也是使用最廣泛的圖之一。可是，在與一些朋友，特別是初學者的聊天當中，我發現不少朋友對UML類圖的做用及使用方法存在必定的誤解和困惑。因而我寫下這篇文章，但願本文能在必定程度上幫助這些朋友更好的認識和使用UML類圖。固然，因爲我對UML的認識並不很深入，因此在文章中有錯誤和疏漏之處，懇請你們批評指正。

AvsD

要想正確認識與使用UML類圖，咱們首先要正確認識兩個概念——「A」和「D」。

A是Analyse的縮寫，即咱們所說的「分析」；而D是Design的縮寫，即「設計」。通常來講，一個系統在編碼前，都要通過分析與設計兩個步驟。而對這兩個概念認識的模糊不清，正是致使不少朋友沒法正確使用UML類圖的緣由。

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

不少朋友有個錯誤的認識，認爲軟件開發工做必定要由懂計算機的人完成，不懂計算機的人怎麼能進行軟件開發呢？固然，對於設計和編碼等工做，固然是這樣，可是惟有「分析」這一工做，能夠由徹底不懂計算機的人來進行，甚至從某種程度上說，不懂計算機的人更適合作軟件分析師的工做。由於想要把分析作好，必定要僅與業務相關，而拋開具體技術。一個滿腦子計算機技術的程序員去作分析時，很容易想到編碼、實現、平臺、數據庫設計等具體細節，這種思惟形式偏偏成爲作好分析的最大障礙。此爲誤解一：只有懂計算機技術的人才能作系統分析師。我如今所在的研究所（北京航空航天大學計算機學院軟件工程研究所）曾經接過一個日本項目，當時日方那邊派來一個系統分析師對計算機就徹底是外行，而是一個領域專家，可是他很好的完成了系統分析的工做。

另一個誤解就是UML圖，特別是UML類圖，就是給開發人員用的。不少人以爲UML是計算機業內專業語言，不懂計算機的怎麼能用它呢？用了作什麼呢？可是不少不懂計算機的系統分析師在進行分析工做時，也在使用UML圖，而UML類圖就是其中一種。通常狀況下，分析師在進行分析時，確實會繪製一套UML類圖。可是，它所畫的UML類圖不論是從視角仍是做用，與設計師所作的UML類圖是不一樣的，具體將在下面介紹。此爲誤解二：只有計算機人士才使用UML圖。

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

這裏能夠看到，設計與分析不一樣，它必須由計算機方面的人來完成，由於它和具體技術是息息相關的。並且，設計師在進行設計時，也會繪製一套UML類圖。

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






領域UML類圖vs實現UML類圖

上文提到，在軟件分析與設計過程當中，會由兩種角色產生兩套UML類圖。通常狀況下，分析師繪製的UML類圖叫作「領域UML類圖」，而設計師繪製的UML類圖叫作「實現UML類圖」。這裏要聲明，這兩個名詞是個人習慣性叫法，並非你們都認同的通用叫法。下面，我對這兩種UML類圖給出個人定義：

領域UML類圖：產生於分析階段，由系統分析師繪製，主要做用是描述業務實體的靜態結構，包括業務實體、各個業務實體所具備的業務屬性及業務操做、業務實體之間具備的關係。

雖然這個UML類圖也叫「UML類圖」，可是說實話，它和編程中的「類」實在是沒啥關係，由於最後的系統中可能根本沒有類和它們對應，並且不少最後系統中的類如控制類和界面類這套UML類圖中也沒有。也就是說這套圖和具體技術無關，也不是畫給程序員看的，它只是表達業務領域中的一個靜態結構。下面給個例子：




這是一個選課系統的簡單領域分析UML類圖。能夠看到，主要實體有教師、學生、課程和開課安排。每一個實體標註了其在業務上具備的屬性和方法。並且圖中還標明瞭實體間的關係。

可是，最終系統中可能沒有一個學生類和其對應。由於最終系統中有哪些類、各個類有什麼屬性、方法依賴於所選擇的平臺和架構。例如，若是使用了Struts2，則會存在不少Action類，而使用了ASP.NETMVC，則會有不少Controller類等，因此，領域UML類圖只於業務有關，和具體實現及編碼等計算機技術無關。

實現UML類圖：

實現UML類圖：產生於設計階段，由系統設計師繪製，其做用是描述系統的架構結構、指導程序員編碼。它包括系統中全部有必要指明的實體類、控制類、界面類及與具體平臺有關的全部技術性信息。

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

總結

最後，咱們總結一下本文的要點：

1.軟件分析與設計是編碼前的兩個階段，其中分析僅與業務有關，而與技術無關。設計以分析爲基礎，主要與具體技術有關。

2.分析階段由分析師繪製領域UML類圖，設計階段由設計師繪製實現UML類圖。

3.領域UML類圖表示系統的靜態領域結構，其中的類不與最終程序中的類對應；設計UML類圖表示系統的技術架構，是程序員的編碼依據，其中的類與系統中的類對應。

4.領域UML類圖中類的屬性與操做僅關注與業務相關的部分，實現UML類圖中的屬性與操做要包括最終須要實現的所有方法與操做。