UML類圖作用和使用方法

本篇內容主要講解“UML類圖作用和使用方法”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“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類圖中的屬性與操作要包括最終需要實現的全部方法與操作。

到此，相信大家對“UML類圖作用和使用方法”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！