分析業務模型-類圖（Class Diagram）（下）

摘要：類圖（Class Diagram）可能是用得最多的一種UML圖。類圖的基本文法並不複雜，你可能最多學習兩三天就可以掌握，然而要真正做到活用類圖則可能需要幾年的功力。類圖是鍛煉物件導向分析（OOA：Object-Oriented Analysis）和物件導向設計（OOD：Object-Oriented Design）思想的重要的工具，是業務結構建模的重要工具。本章將會有大量的實戰練習，你的OOA思想將會接受極大的考驗和提升。

本文全長1萬6千多字，並且有幾十張插圖，由於篇幅過長特分為上、下兩篇發出。
本文來自新書《活用UML——需求分析高手》的第3章。

作者：張傳波
www.umlonline.org

大綱：

上篇：
3.1 面向過程與物件導向
3.2 類圖的基礎知識
3.3 類之間的關係
3.4 演練類之間的關係

下篇：
3.5 類的“遞迴”關係與“三角”關係
3.6 考試管理系統——類圖綜合訓練
3.7 關於對象圖
3.8 小結與練習

 

如果你還沒有閱讀上篇，請先閱讀！

上篇連結：http://www.cnblogs.com/umlonline/archive/2011/10/17/2215850.html

 

3.5 類的“遞迴”關係與“三角”關係

 

這個小節是類圖的進階知識，有一點難度，但這些知識在需求分析工作中非常實用。

“遞迴”關係

我在以前公司面試過的人數可能有數百人，如果面試者說他懂類圖，那麼我幾乎100%會問這個問題：Windows作業系統中有檔案夾與檔案，請你用類圖表達出檔案夾與檔案的關係。
經過前面的學習，你已經具備了能畫出這個圖的基本知識了，請你不要看後面的參考答案，先自己嘗試完成這個題目。
很多面試者很快就會畫出這樣的圖：

圖 1.30  檔案夾與檔案關係1

我會接著問這些問題：
1)檔案夾裡面也可以有檔案夾啊，這個怎樣表示出來？
2)裡面的檔案夾裡面也可能有檔案夾，咋辦？
很多面試者傻眼了，只有很少數人可以畫出來。
其實畫不出來也不用灰心，我剛學習類圖時，也被這個題目一下子難倒了，後來看到參考答案後恍然大悟，同時對類圖產生一種莫名的敬仰！

圖 1.31  檔案夾與檔案關係2

檔案夾裡面有檔案夾，裡面的檔案夾裡面有可能有檔案夾，這可能是無窮無盡的“遞迴”啊！而這個內含項目關聯性可以自己指向自己，可以“自包含”，這個無窮“遞迴”的問題就解決了，實在太完美了！
無論是弱包含還是強包含，都可以“自包含”。除了“自包含”可以形成“遞迴”，其實直線關係同樣是可以指向自己的，這個叫“自關聯”，這樣也形成了“遞迴”關係。請看：

圖 1.32  自關聯

這種“遞迴”結構，一旦展開就會形成一棵樹型的結構。需求分析時如果發現樹型的業務結構，你可以考慮使用“自包含”或者“自關聯”來分析。
其實“自包含”、“自關聯”的說法是不嚴謹的，只是方便記憶和理解，實際上具體的一個檔案夾是不會包含自己的。這裡我們需要進一步理解類圖中的每一個類所代表的意義，一個類並不是指具體的一個業務對象，一個類泛指屬於這個類的任意一個業務對象。這裡的解釋可能還不夠清楚，你可以暫且放下，在對象圖的小節我們再具體說這個問題。

“三角”關係

前面有個練習，要求你畫出公司與僱員的關係，現在要求你分別列出公司和僱員至少3個關鍵屬性。
待你列出關鍵屬性後，請你思考這些問題：
1)薪金是僱員的關鍵屬性嗎？合約期、職位呢？
2)公司與僱員，這兩者的關係在法律上是如何確立的？
你一定會想到，公司與僱員要簽署勞動合約，而勞動合約上會有薪金、合約期、職位這些重要的內容，那麼薪金、合約期、職位還算是僱員的屬性嗎？公司、僱員、勞動合約這三者是怎樣的關係？

圖 1.33  公司、僱員、勞動合約的關係1

在表示公司與僱員的關係的直線上，拉出一條虛線，虛線另外一端串連勞動合約類，這樣的類叫做關聯類別（Association Class），關聯類別是對兩個類的關係的進一步約束。
最開始你可能會認為薪金、職位、合約期這些似乎應該是僱員的屬性，但現在你應該認識到，這些三個關鍵內容應該體現在公司與僱員的關係上，這些內容應該體現在勞動合約上。再進一步思考，僱員的薪金、職位、合約期是會變化的，你可能會跟同一個公司簽署多份勞動合約，也可能簽署一份勞動合約後又有多次合約變更。

要識別出能表徵兩個類別關係的關聯類別，難度是有點高的，有這樣的一些實踐建議供你參考：
1)如果覺得兩個類有關係，則先拉上一條直線再說。
2)如果覺得兩個類有關係，但怎樣畫都覺得這個關係不太合適，那麼可以思考是不是漏了一個關聯類別了。
3)分別列出這兩個類的關鍵屬性，思考這些屬性的屬性值是不是由該類本身就可以確定了。例如：如果我們最開始將薪金作為員工的屬性，那麼你可以思考薪金的具體數字，是不是員工自己本身可以確定的？你會發現薪金其實是由公司和員工商定後確定的，並不是員工自己本身可以決定。
4)通過對屬性的思考，可能會發現這個屬性應該是屬於另外一個類的，思考這個類是不是能表徵原來兩個類別關係的關聯類別。

關聯類別這樣複雜的東西，客戶是不太可能直接告訴你的，你需要在需求分析中發現和提煉出關聯類別，這對需求的理解以及項目後期的設計工作將會有很大的協助。
將薪金、職位、合約期這些資訊直接當成是僱員的屬性也不是不可以的，這跟我們做系統的目標很有關係。如果我們只是做很簡單的員工資訊管理，可能就沒有必要將合約提煉出來。如果我們要做一個人事管理系統，甚至要產品化，這樣就需要我們將業務模型分析得更加透徹。

回到前面的“公司的組織架構”練習，如果我們要做一個通用的公司管理系統，我們希望能盡量適應不同的公司情況，那麼例子中所做的對公司組織架構的提煉是很必要的，如果我們能看清楚公司部門架構的本質，那麼就能盡量多的適應不同的情況。
我實踐建議是：在需求分析階段應盡量對業務分析得透徹一點，這樣後期工作將會更加主動。業務需求模型最終變成設計模型時，我們可以把握設計的“度”的，可以做出彈性很高的設計，也可以做一個比較“老土”的設計。
公司、僱員、勞動合約的關係，其實還可以畫成下面這樣：

圖 1.34  公司、僱員、勞動合約的關係2

這個圖可能最體現它們的“三角”關係了，關聯類別也可以表達成這樣的方式。但我在實際工作還是以關聯類別的方式來表達，我覺得關聯類別的表達方式更加貼切和專業一點。
在具體的需求分析工作時，如果你發現三個類形成了類似該圖的“三角”關係，你可以思考其中一個類是不是可能是關聯類別，但要注意並不是凡是出現了“三角”關係就一定會有關聯類別。

怎麼樣？本節的難度已經更上一城樓了！
類圖的最大魅力在於協助你發掘和提煉業務模型，其他的非UML圖可能是做不到的。當然真正要做好發掘和提煉，還是需要你的深厚功力了！

下小節，你將要完成一個綜合練習，應用你所學習到的全部類圖知識。

 

3.6 考試管理系統——類圖綜合訓練

 

做這綜合練習有以下幾個目的：
1)讓你鞏固所學到的類圖知識。
2)演練用類圖分析需求的基本步驟。
3)學習一些提煉類的新知識。

本練習我們將會演練類圖分析需求的基本步驟：
1)識別出類。
2)識別出類的主要屬性。
3)描繪出類之間的關係。
4)對各類進行分析、抽象、整理。

本綜合訓練的題目如下：
某學校打算做一套考試管理系統，當前情況如下：
1)講師會講很多門課，大部分的課程需要安排一次考試，有些就不需要。
2)考試題目由講師出。
3)學生需要參加很多考試，每門考試都有成績。

請你思考：
1)考試是一個類嗎？如果是，考試這個類代表怎樣的意思？
2)分析出與考試直接相關的類都有哪些？
3)考試類與其他類是怎樣的關係？

本系統圍繞考試開展，我們首先要確定考試是怎樣的一個類，考試類代表考試試卷嗎？還是代表考試這個事情？這是考試管理系統，不是考試試卷管理系統（當然試卷也需要在本系統中管理），需要對考試這個事情進行管理，所以考試類代表的是考試這個事情。
將需求分析中遇到的人、物、概念識別為類，這是比較容易做到的，而對於事情，例如考試，我們就不一定能將其識別為類。因為普遍認為，類代表的是一些靜態東西，而事情是動態，不適合用類來表示。這並不是絕對的，由系統的目標出發，有時候我們需要將某些事情、動作等動態內容，識別為類。當我們做某某管理系統，而某某是指某個事情時，其實最終系統是通過管理該事情的記錄來實現對該事情的管理。例如：考試管理系統，其實最終系統管理的是考試記錄；請假管理系統，其實系統最終管理的是請假記錄。為了能讓這些事情能被管理，將這些事情識別為類是很必要的。

考試類的意義基本確定了，它的屬性有考試時間、地點等內容，現在要思考與考試直接相關的類有哪一些呢？ 課程、試卷、講師、成績、學生這些合適嗎？
請你先列出與考試直接相關的類，並嘗試畫出它們與考試的關係，然後才繼續往下看。
請注意只需要找出與考試直接相關的類就可以了，不需要找間接相關的，另外只需要畫出其他類與考試的關係就可以了，至於其他類之間的關係暫不用考慮。

圖 1.35  考試類與其他類的關係

說明：此圖並沒有畫出課程、講師、學生之間的關係，此圖重點表達的是其他類與考試類的關係。

此圖表達了這樣的情況：
1)每個課程要麼安排一次考試，要麼沒有考試，而每個考試只對應一門課程。
2)一名講師作為出題者對應零到多次考試，而每一次考試必有對應的一位出題的老師。
3)一名學生需要參加零到多次的考試，而每個考試有一到多個學生參加。
至於成績和試卷，要重點說明一下。

作為一名學生，他參加一門考試就會得到一個成績，他參加多門考試就得到多門成績，於是就可以計算出該名學生的平均分、最高分、分數排名等，這些內容可以列為學生的屬性。
作為考試來說，一次考試有很多學生參加，這樣這門考試就會產生很多個成績，根據這些成績，我們可以算出這次考試的平均分、最高分、優秀率、合格率等等，注意平均分、最高分這些也可以叫做這次考試的成績，這些內容可以列為考試的屬性。
學生的分數排名、考試的優秀率這些東西如果列為屬性，這些屬性可以成為“匯出屬性”，意思就是通過其他基礎資料算出來的屬性。需求分析時，我們要重點識別基礎屬性，基礎屬性是指“原生”的屬性，不根據其他東西計算出來，而是直接得到的。

圖3.35中所定義的成績類是指一名學生參加一次考試所得到的成績，這個成績是原生的，通過這個成績，系統可以從考試的角度或者從學生的角度匯出很多其他統計資料。
理解了成績這個類，應該就比較容易理解試卷這個類了。一次考試對應一名出題老師，老師為這次考試設計了一份題目，這份題目就是試卷。

上述只是參考答案，這個題目並沒有標準答案，識別出怎樣的類以及畫出類之間的關係，從不同的角度就會有不同的結果，關鍵還是要從系統的目標出發，做出合適的分析。如果你的答案與參加答案很不一致，不代表你畫得不好，只要你能有條理地解釋這些類和它們的關係，就是合適的！

通過這個綜合訓練的過程（而不是結果），總結以下幾點實踐建議供你參考：
1)從系統的目標出發來思考問題。
2)用類圖分析需求的基本步驟：識別類、識別屬性、畫出關係、整理和提煉，只是大致的參考步驟，並不是絕對的。
3)識別類的關鍵屬性，能讓我們思考類是否合適，嘗試畫出類的關係也會讓我們再次思考這些類是否合適。
4)多讀圖，從兩個方向來讀兩個類的關係，能協助你發現更多問題。
5)只需要表達出的類直接關係就可以了。例如：A和B有關係，B和C有關係，這樣其實A和C也是有關係的，它們有間接關係，間接關係不需要直接畫出來，只需要畫出所有的直接關係，我們可以通過類圖的關係網路看到類之間的間接關係。
6)不要試圖用一個類圖表達所有的內容。考試系統這個題目其實已經簡化不少了，實際系統的類圖可能有幾十個甚至上百個類，要規劃好用多個類圖來表達不同的內容，每個類圖有不同的表達重點。
7)注意識別“原生”的內容，並且根據這些“原生”內容能匯出什麼“匯出內容”，不要將“匯出內容”當成“原生內容”的。
8)識別關聯類別是痛點也是關鍵點，分離出關聯類別會讓我們更加看清楚事務的本質。
9)沒所謂絕對正確的答案，關鍵是要有自己的合理分析，逐步求精、持續最佳化你的想法。
10)多練習、多討論，逐步增強你的物件導向分析素養。

 

3.7 關於對象圖

 

寫過代碼的朋友比較容易理解什麼是對象，類（class）的執行個體（instance）就是對象（object）。第1章大話UML曾講解過對象圖，我們再來複習一下。
這是Person類：

圖 1.36  Person類

下面這句代碼將Person類執行個體化為person對象：
Person person = new Person（）;
用對象圖表示為：

圖 1.37  person對象

一個公司包含多個員工，用類圖這樣表示：

圖 1.38  公司和員工的關係

此圖的公司和員工並沒有指具體是哪個公司或者哪個員工，如果某公司A有甲、乙、丙三位員工，用對象圖則可以這樣表示：

圖 1.39  公司A與員工甲、乙、丙的關係

“A:公司”表示對象A是公司這個類的執行個體；如果是“:公司”，則表示這是公司這個類的執行個體，但沒有給出這個執行個體的具體名稱。
類是某一類東西的抽象或者叫統稱，而對象則是具體的一個東西，A公司如果有1000名員工，那麼就需要畫一千個“包含”才能表示出A公司與所有員工的關係。對象與對象之間如果有關係，那肯定是一對一的關係，因為兩者都是具體的東西，不可能存在第二個。比方說張三和李四是好朋友，他們的關係就是一對一的好朋友關係，因為不可能再有另外一個張三或者李四，但如果我們將張三和李四抽象為人時，一個人可以與很多人交朋友，這樣就可以建立多對多的朋友關係。
需求分析時，其實我們接觸到的是一個個具體的東西，如：見到一個個具體的人，接觸到一份份具體的業務資料等等，這些具體的東西其實就是對象。而我們分析需求不能就事論事，我們需要將這些對象提煉為類，這樣的分析才更具有代表性。我們軟體系統並不是用來解決具體某次事件中的一個問題，而是希望能解決某一類問題。
在我的工作經曆看來，需求分析工作中很少需要用到對象圖。我基本不會使用對象圖，而直接使用類圖，在少數需要使用對象圖時，我甚至會直接用類圖代替，這樣做也並沒有不妥而且也容易理解和解決問題。

前面有一個練習，讓你用類圖畫出你和你的另外一半的關係，其實準確地說你和你的另外一半已經是很具體的一個人了，應該用對象圖來表達，但我覺得將其“混淆”為類圖也沒有什麼不妥，而且更簡單易懂。
前面“類的遞迴關係”小節提到“自包含”“自引用”的問題，“自”的意思並不是指對象自己本身，而是指其他的屬於同一個類的執行個體。

對象圖就簡單介紹到這裡，如果你對類圖還不是很熟悉的話，建議你對象圖瞭解到這樣的程度就可以了。

 

3.8 小結與練習

 

類圖是最常用的UML圖，是用來訓練你OOA思想的最好武器。類圖的文法不算很難，要看懂類圖難度不大，但要用好類圖就相當不容易了。
本章一開始，專門對開發人員進行了“洗腦”，端正你對面向過程和物件導向的認識。如果你不是開發人員，那麼這個“洗腦”就可以免了。
接下來你學習了一大堆類圖的基本文法，並做了很多練習，你還記得下面列出來的內容嗎？

表 3.1 類圖基本文法

你還學習了類圖的“遞迴”關係與“三角”關係。

圖 3.40  “遞迴”關係樣本

圖 3.41  “三角”關係樣本

一個個的練習除了讓你鞏固學到的類圖知識，更重要的是通過具體的執行個體讓你體會用類圖分析問題的思路和方法。
類圖分析需求的基本步驟：
1)識別出類。
2)識別出類的主要屬性。
3)描繪出類之間的關係。
4)對各類進行分析、抽象、整理。

類執行個體化後就是對象，表達這些對象及對象關係的圖，就是對象圖。需求分析中很少需要使用對象圖。
多思考、多練習、多討論、多總結，不斷鍛煉和提升你的物件導向分析能力吧！

練習

1.一輛小車有4個輪子，請用類圖表示出來。
2.一輛貨車也有4個輪子，但貨車的前輪和後輪不太一樣，用類圖如何表示？
3.請用類圖表示項目組的人員組成。 提示：請思考項目組包含怎樣的角色？項目組架構是樹形架構還是網路架構？
4.你要設計一個論壇，請用類圖表達出分區、版塊、子版塊、文章等論壇常見元素的關係。
5.請在你做過或者正在做的項目中挑選一個，用類圖來分析該項目的需求或者部分需求。

 

作者：張傳波
www.umlonline.org

 

---全文到此結束---