分析業務模型-類圖（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 小結與練習

 

3.1  面向過程與物件導向

本小節的內容涉及到編程方面的知識，如果你有相關經驗，請認真閱讀本小節，本小節目的是澄清開發人員的一些面向過程和物件導向的理解誤區。如果你沒有編程經驗或者對此不感興趣，可忽略本小節直接閱讀下一小節，忽略本小節並不影響你對後文的理解。
上世紀90年代初，當我讀高中的時候首次接觸電腦，並且學習了第一門程式設計語言Basic。當時不知道什麼是面向過程，也不知道何為物件導向，只知道不斷地學習Basic語言的演算法，感受編程的樂趣。當時學習的Basic語言，現在看來是很老土的面向過程的語言。
後來學習了C語言，不久後朋友告訴我應該學習C++，我問：C和C++有什麼不同？於是朋友告訴我：C是面向過程的語言，C++是物件導向的語言，C++比C最不同的地方就是C++有類（Class），C沒有……
這就是我對面向過程和物件導向的第一印象，後來又學習了一些物件導向的知識，似乎將很多東西變成類，類裡面有特性和操作，就是物件導向。然而工作後發現完全不是那麼回事，物件導向真的是只可意會難以言傳啊。下面說說我對面向過程和物件導向的理解，希望對你有協助。
很多年前的程式只有一行行的代碼，後來出現代碼難以組織、不好閱讀、重複代碼多等問題。於是“發明”了方法，將一段代碼放到方法裡面，實現一定的功能，供別的地方調用。方法的“發明”是編程史上的一大進步，其實方法就是一定程度上的封裝，只要調用者給出符合要求的輸入，方法就會返回合適的輸出，調用者完全不用理會方法的具體實現，而方法裡面又可以調用方法。隨著後來的發展，出現了結構化編程，將編程的藝術更推進一步。
無論是方法還是結構化編程，都是我們提高編程技術以更好地解決複雜的、高難度的問題的一種手段而已。但後來發現問題越來越複雜，結構化編程開始招架不住了，於是有人提出物件導向編程。物件導向編碼是一種基於類的編程方法，每一個類有特定的作用，類中有屬性和方法，一條條語句只存在於屬性或方法中。用物件導向的思路來求解問題，就是要設計出能解決問題的一個或多個類，通過類之間的相互操作和協作來解決問題。類是對代碼的進一步封裝，比方法對代碼的封裝要進一大步，類的出現要求我們編程的思想更進一步。

對於面向過程和物件導向編程存在這樣的一些誤區：
1) 物件導向比面向過程更進階，無需注重結構化編程和編程基本功。
前面提到的編碼發展史，簡單說就是以下幾個階段：
一行行的代碼
用方法組織起來的代碼
結構化代碼
物件導向的代碼（用類來組織的代碼）
看上去似乎後面的可以取代前面的，特別是到了物件導向編程階段，似乎人人都可以喊自己是物件導向的，真正能寫出好代碼的人並不多。其實編碼基本功相當重要，結構化編程也相當重要，如果這些基礎不行，物件導向只能喊喊而已。我在以前公司招聘程式員，編程基本功是必考的。
2) 物件導向編程就是將代碼放進一個個類而已。
我最開始對物件導向編程的看法基本上就是這樣，後來用VB編程還是未能真正體會物件導向編程，直到後來使用真正物件導向的語言C#以及學習了UML和設計模式，才開始真正體會。如何設計、提煉、規劃類，是很講技巧和功力的事情，物件導向一點都不容易。
3) 將業務概念直接轉變為類，賦予合適的屬性和操作，就可以解決問題。
需求階段的建模與設計階段的建模是很不一樣的，需求建模是對業務和需求的提煉，優秀的需求建模是設計建模的良好開始，但優秀的設計建模還需要考慮更多的設計上的事情，並不是簡單地將業務模型直接轉變化設計模型就可以解決問題的。

本書不會具體介紹如何物件導向地編程，而是如何物件導向地進行需求分析，我們將會借鑒物件導向編程的思想用於需求分析工作中。有開發經驗的人士從事需求分析工作時，受面向過程和物件導向編程的思維習慣影響，容易處於“技術實現”的角度來分析問題。這需要一個轉變過程，我強烈建議你先忘掉自己的開發經曆。本書接下來的內容，將會通過一個又一個的具體案例和練習，讓你體會物件導向分析需求的方法。當完成這個轉變時，你會發現編程思想和分析需求的思想有共通之處但又不太一樣，你在編程時養成的嚴謹、全面、深入的分析方法會讓你在需求分析工作中受益不淺。

 

3.2 類圖的基礎知識

 

類圖有什麼用？

某項目客戶提供的原始需求文檔中，有下面這樣的一段話，請你仔細閱讀，看看能不能將你搞暈？
“本項目是在一期的基礎上增加對電纜、通訊工程的管理和施工詳細資料的記錄和統計，使整個系統更好的管理各工程項目從中標開始到竣工驗收的全部過程和資料和分析施工過程的資料。 本系統將一條或一個標段的架空電力線路工程定為一個單位工程，即系統中的一個工程項目；每個單位工程分為若干個分部工程；每個分部工程分為若干個分項工程；每個分項工程中又分為若干相同單元工程。”

這段話中帶底線的文字，可能是本系統的一些關鍵業務概念。

如果你還沒有暈的話，請回答下面的問題：
1) 你能用一句話描述這個系統是做什麼的嗎？
2) 這段話有什麼業務概念？每個業務概念是什麼意思？
3) 這些業務概念之間是怎樣的關係？

上面那段文字充斥了大量的術語、概念（帶底線的字），如果你不是專業人士，恐怕難以讀懂上述文字。項目初期，我們往往對業務一無所知，我們最急迫需要解決的問題就是理清楚這些業務概念以及它們的關係。
每個軟體系統都會涉及到很多人、業務概念和物品等，這些東西之間可能會有很多關係，發生很多事情。類圖能協助我們識別出這些人、業務概念、物品和事情等，並理清它們的關係。

什麼是類？

你大概瞭解了類圖的用途了吧？我們暫時不去深究那段讓人頭暈的業務描述，我們先看看什麼是類？
需求中提到的各種業務概念、人物等，經過抽象後我們都可以視之為類。為了更好地體驗什麼是類，請看下面這個練習。

練習：如果對本書的讀者進行分類，你會如何分類呢？

強烈建議你先思考寫下答案後才繼續往下看。

男人、女人？
人無非就是男人和女人兩種，所以本書的讀者不是男人就是女人。這樣分類合適嗎？
男人和女人在看這本書的時候，會有什麼差異嗎？將書的讀者分為男人和女人，有什麼好處？
如果不分為男人和女人，分為老人與年輕人，這樣合適嗎？

學生、在職人員？
學生和在職人士讀本書的時候應該是有所差異的，畢竟兩者的基礎不太一樣。如果你是本書的作者，你覺得本書的目標讀者是誰呢？編寫本書時，你會更照顧學生還是在職人士呢？我們對讀者進行分類，並不是為了分類而分類，而是希望通過對讀者這個群體進行分析，寫出一本內容更精彩銷量更好的書。

將某類東西歸納為一起，可以稱為一個類。類有很多種提煉角度，我們需要根據系統的目標、業務的情境等，選取合適的角度對事物進行歸納。
什麼是類圖？

只有一個類的類圖，可能就是最簡單的類圖了，請看：

圖 3.1  只有一個類的類圖

一個類就是一個矩形的方框，最上面是類的名字，中間是屬性（Attribute），最下面是操作（Operation）。表示一個類時，可只顯示類名，也可以只顯示類名和屬性，或者是類名和操作。
我們看看這個屬性：+屬性1:int。
前面的“+”號表示這個屬性是public類型的，實際上在需求分析時，不需要管屬性是public還是private，全部畫成public就可以了。
冒號後面的int，表示屬性的類型是int型（整數型），往往在需求分析初始階段，可不必識別屬性的類型。
至於操作，用類圖進行業務建模時，一般不需要標識出來。

一個類圖通常不止有一個類，有多個類時，我們還需要表達出類之間的關係，後面我們將介紹類之間的關係。

如何識別類？

用類圖擷取需求的大致步驟如下：
1) 識別出類。
2) 識別出類的主要屬性。
3) 描繪出類之間的關係。
4) 對各類進行分析、抽象、整理。
我們通過下面這個練習來體驗一下步驟1、2。

練習：你需要做一個培訓管理系統，請你用類圖識別出課室中有什麼人？這些人有什麼關鍵屬性？

強烈建議你先獨立完成才繼續閱讀下文。
課室中有以下兩類人：

圖 3.2  學生與講師1
說明：該圖是類圖的簡單畫法，只表達了類名。

這兩個類有這樣的關鍵屬性：

圖 3.3  學生與講師2
說明：上面的類圖同時表達了類名和類的屬性。屬性沒有標記public還是private，也沒有被標記屬性的類型。業務建模時類圖的屬性可以看成全部是公開的，也不必標記屬性的類型。

這個練習的情境是：你需要做一個培訓管理系統，所以你識別出類以及他們的屬性的時候，務必從這個角度出發。如果你得到的類是男人和女人，那就可能沒有什麼意義了。

如果你識別出來的屬性是身高、體重，這些屬性無論是屬於學生還是老師，對於培訓管理系統來說，可能是沒有什麼價值的。思考你識別出來的類的屬性，能協助你判斷這個類是否合適。每一個類應該具備能表徵它核心特點的關鍵屬性，而一般的無特別意義的屬性，可不必標記進去。
類圖的基本文法是很簡單的，但要體會什麼是類，準確識別出類就不是那麼簡單了。實際工作中，我們需要將需求調研中瞭解到的所有業務對象、人物等列出來，畫出他們的關係，反覆推敲，逐步才能得到合適的業務模型。下面我們將開始學習類之間的關係。

 

3.3 類之間的關係

 

表達類之間關係時，類只需要畫出名字就可以了，屬性和方法可以省略顯示。

“直線”關係

A、B兩個類，它們之間有關係，但又不能確定是怎樣的關係，我們可以這樣畫：

圖 3.4  “直線”關係

這個“直線”關係其實就是關聯（Association）關係，“關聯”是UML中文術語的標準說法，但為了能讓大家更容易理解和記憶，我會使用一些“老土”的說法。
做軟體需求分析時，如果覺得兩個業務概念之間有聯絡，但暫時不能確定具體是怎樣的，那麼就先畫一條線將兩者連起來再說。隨著你對業務的理解，這條線條會進一步具體化，你可以為這條線添加更多的元素。

圖 3.5  一對一關聯性

這個圖C、D兩個類有一條直線相連，但在直線兩端各有一個數字1，表示一個C對應一個D。

圖 3.6  一對多關聯性

這個圖表示一個E對應0到多個F，*號的意思就是表示0到多個。

圖 3.7  一對零到三個關係

這個圖表示一個G對應0到3個M，“0..3”表示0到3個，“1..4”表示1到4個，“x..y”表示x到y個（x，y表示任意自然數，而且x < y），注意有兩個點（“..”）而不是一個點（“.”）。

圖 3.8  角色關係

這個圖表示I和J之間有關係，在這個關係中I的身份是上司，J的身份是下屬。我們可以線上條的兩端標記在這個關係中，兩者分別是處在怎樣的角色。
你可能會留意到，為什麼“上司”、“下屬”前面有一個“+”號？“+”號表示這個角色的類型是public的，“-”號表示private，這些符號在軟體設計時才需要用到，我們做軟體需求分析時，不需要理會這些符號，全部畫成“+”號就可以了。
這條直線如果變成帶箭頭的，又是表示怎樣的意思呢？請看：

圖 3.9  “導航”關係

這個圖表示由A可找到B，箭頭表示方向，由A可“導航”到B。
寫代碼時，如果A類有一個成員變數儲存的是類B的引用，也就是說由類A可以找到類B，那麼可以畫成圖3.9的樣子。這是從軟體設計的角度來解釋這個箭頭的意義，如果是軟體需求分析，這個箭頭是怎樣的意思呢？下面是一個執行個體：

圖 3.10  請假單與請假者的關係

請假單上會列明是誰請的假，所以我們由請假單可以找到請假者。進行業務分析時，往往會發現由業務概念A可找到B，這時可以使用帶箭頭的線條。
直線關係是最常見的關係，最簡單的直線關係就是兩個類之間畫條線就可以了。我們也可以進一步細化這條直線關係：在這條直線的兩端，可以標記上數字和名稱，數字表示是幾對幾的關係，名稱則表示在這個關係中，直線兩端的兩個類分別是怎樣的一個角色，而這條直線也可以變成帶箭頭的直線。直線、幾對幾的關係、角色、箭頭可以搭配使用，只要能準確反應出業務關係就可以了。
直線關係只是一種老土的說法，UML中文術語標準是關聯（Association）關係。另外要說明的是，有時候因為類太多，為了讓類圖更容易閱讀，需要將“直線”畫成“折線”，如：

圖 3.11  “折線”關係

“包含”關係

一個部門有多個員工，用類圖可以這樣表示：

圖 3.12  “包含”關係

這裡有兩種標記法，一種是空心菱形，一種是實心菱形。兩種菱形表示包含的強烈程度不同，空心菱形是“弱”包含，實心菱形則是“強”包含。你可以這樣記憶：空心菱形是空心的，顯得虛弱一點，這是“弱”包含；實心菱形是實心的，顯得更加強壯，這是“強”包含。
“弱”包含表示如果部門沒有了，員工也可以繼續存在；“強”包含表示如果部門沒有了，員工也不再存在。關於這兩者的另外一個重要區別是：如果是“弱”內含項目關聯性，兒子可以有多個父親（當然只有一個父親也是可以的）；如果是“強”內含項目關聯性，則兒子只能有一個父親。
做軟體需求分析時，我往往會將所有的內含項目關聯性畫成“弱包含”，如果後面發現某些關係可以表示為“強包含”時，我才轉為實心菱形。
請留意包含的方向，誰包含誰，剛學習的朋友很容易把方向畫反了。
在員工這邊的“*”號表示零到多名的意思，如果是“1..100” 則表示1到100名；而部門這邊沒有具體的數字，則表示是“1”，則一名員工只能屬於一個部門。如果一名員工同屬於多個部門，那應該怎樣畫呢？

圖 3.13  部門與員工的多對多關係

部門這邊的“*”表示一名員工可同屬於多個部門，請注意，在“強包含”關係中，一名員工只能屬於一個部門。
“弱包含”、“強包含”的說法只是一種方便大家記憶和理解的老土說法而已，空心菱形的UML中文術語標準說法是彙總（Aggregation），實心菱形是組合（Composition）。以前看UML資料遇到彙總和組合兩個詞都會讓我頭暈一番，因為那些解釋說得太複雜了，就算是現在我遇到這兩個詞也需要稍微停頓一下來想一想。剛學習內含項目關聯性的朋友，建議你只需要記住“弱包含”“強包含”的說法就可以了。

“繼承”關係

我以前的公司有一個每日培訓的制度，由公司內部員工做講師，分享知識和經驗。員工可以做學生，也可以上台做老師，下面是學生和老師的類圖：

圖 3.14  學生和老師

請思考，學生和講師有什麼共性呢？
學生和講師不都是員工嗎，凡是員工都有這樣的屬性了：

圖 3.15  員工

說明：此圖只列了三個員工的屬性，僅作示意。
員工、學生、講師可以表示為以下的關係：

圖 3.16  員工、學生、老師關係

學生、講師都“繼承”了員工，他們具備員工的屬性，同時也有自己特有的屬性。另外一種說法是：學生、講師是員工的一種。
“繼承”的基本畫法如下：

圖 3.17  “繼承”關係

這表示A繼承了B，A具備B的特點，同時也有自己特有的特點，注意不要搞錯繼承方向。
“繼承”同樣是一種老土的說法，UML中文術語標準是泛化（Generalization），該圖可這樣讀：A泛化為B。泛化這個詞比較難理解，你可以理解為抽象、提煉等。
在實際的軟體需求分析工作中，我們往往有兩種認識事物的角度，我們以員工、學生、老師的關係為例子來說明。
角度一：在培訓現場，我們看到的是學生和老師，後來你發現，原來老師是內部員工來的！於是你可以從學生和老師這兩個類出發，發現學生和老師其實都是員工！
角度二：作為這個公司的領導，希望公司形成一種學習和進步的風氣，促進公司的進步，於是領導希望員工之間能互相分享知識和經驗。從這個角度看來，領導先想到的是員工，然後再進一步發現員工可以當學生也可以當老師。
在泛化關係中，以圖1.17為例，我們有可能先發現A，然後匯出B，這時可以說由A泛化為B；也有可能是先發現B，然後匯出A，這時可以說A繼承B。泛化（繼承）是我們進行業務提煉的重要手段，後面我們將有更多的具體例子和練習。

依賴關係

如果一個煙鬼嗜煙如命，沒有煙不能生活，用類圖可以這樣表示：

圖 3.18  煙鬼與香煙的關係

這個虛線箭頭就是依賴（Dependency）關係，這虛線箭頭與導航關係的實線箭頭很相似，注意不要搞混了，兩者表示的意思是完全不一樣的。
如果說類A依賴於類B，類圖表示如下：

圖 3.19  依賴關係

所謂的依賴關係，依賴的程度是相當而言的，不一定是A沒有B就不能“生存”了。在具體的商務邏輯中，對於某個事情，A需要B來協助才能完成，這樣也是一種依賴。

這個小節內容非常多，你可能有點消化不良了。上面介紹的內容其實在需求分析工作中是經常需要用到的，而其中最常用的是直線關係。
下面開始你將會通過一個個的練習來協助你理解和鞏固這些知識，強烈建議你看完題目後先獨立思考完成，然後再繼續看參考答案。

 

3.4 演練類之間的關係

練習1、2、3是簡單的小練習，而練習4的難度會有所增加。這些練習不僅僅是讓你鞏固上小節學習的知識，中間還會穿插一些前面還沒有介紹的基礎知識，而且會讓你體驗什麼是物件導向分析，領悟用類圖分析需求的要訣。你準備好接受挑戰沒有？

練習1：你和你另外一半的關係

你結婚了嗎？如果你已婚，那麼請你用類圖描繪你和你的另外一半的關係？
如果你是單身的，你有男朋友或女朋友嗎？有的話，請你用類圖畫出你們兩人的關係？
如果你還沒有另外一半，而你又已經到了適合戀愛的年齡，那請你虛擬一位你的意中人，用類圖畫出你和你的虛擬意中人的關係。
如果你還沒有到戀愛或結婚年齡，那麼你不需要完成這個練習，直接看後面的參考答案。
如果你是已婚人士，那麼你們的關係應該是：

圖 1.20  你和你的另外一半關係1

如果你是男生，你在這個關係中的角色就是老公，如果你是女生你就是老婆。一個老公只能對應一個老婆，你應該不會畫出1對多吧？
這個圖也可以畫成這樣：

圖 1.21  你和你的另外一半關係2

這個圖在直線上面的“夫妻關係”表示這個關係的名稱，你可以為關聯關係命名，但這不是必須的，在需求分析工作中也很少有這種需要。
如果你未婚，但你同時有多個男朋友或者女朋友，那麼你們的關係可以這樣表示：

圖 1.22  你和你的另外一半關係3

“1..*”表示1到多個，不要因為你能1對多個男朋友（或女朋友）就很開心，這是一種很不好的關係，強烈建議你將1對多的關係變為1對1，而且說不定有朝一日你會被別人1對多。
如果你還沒有另外一半，你可以畫成這樣：

圖 1.23  你和你的另外一半關係3

你的另外一半是作為“虛擬情人”存在的。
如果你很愛你的另外一半，你依賴於你的另外一半，沒有她（他）你簡直不能活，她（他）是你的生存必需品，你可以畫成這樣：

圖 1.24  你和你的另外一半關係4

你可以跟你的另外一半畫畫這個圖，跟她（他）解釋一下是什麼意思，你的另外一半一定開心死了。
用類圖表達你和你的另外一半的關係，並沒有固定的標準答案，你畫出來的可能跟上述的參考答案不一樣，只要你的邏輯正確，這個圖也就是合適的。

下面介紹讀圖檢查法，能協助你檢查類圖畫得是否合適。
你可以分別從左至右、從右至左來讀圖，看看有沒有不合理的地方。以圖1.22為例，從左至右讀：1個你對應1個到多個你的另外一半。從右至左讀：1個你的另外一半對應1個你，而不要讀成：多個你的另外一半對應1個你。注意由“多”的一邊往另外一邊讀時，仍然是1個什麼對應多少個什麼，無論你從哪邊開始讀起，都是以“1個……”開頭。

練習2：公司與僱員的關係

前面學習了部門與員工的關係，公司與僱員是怎樣的關係呢？請用類圖畫出來。

圖 1.25  公司與僱員的關係

這個圖表示公司“包含”多名員工，而公司這邊也有一個“*”號，這表示一名僱員可受雇於多個公司。事實上很多公司是禁止員工同時受雇於另外一個公司或者是兼職的，這樣公司這邊就不能畫“*”號。
這裡的包含是弱包含，能不能畫成強包含呢？公司如果不存在了，僱員還存在嗎？一個公司沒有了，這個公司應該就不會有任何僱員，但不代表原來的僱員都消失了，他們還是存在的。這個問題就比較糾結了，到底是弱包含還是強包含，每個人的標準可能不一樣，我不建議在弱包含還是強包含上過於糾結，我做需求分析時絕大部分情況只會用弱包含，強包含只會在很明顯的情況下才用。

練習3：香蕉、蘋果、梨子的關係

你吃過香蕉、蘋果和梨子嗎？這三個東西有怎樣的關係？請用類圖畫出來。
你可能覺得這個練習有點“無厘頭”，這三種水果能有怎樣的關係？它們無非都是可以吃的羅！

圖 1.26  香蕉、蘋果、梨子的關係

此圖表示香蕉、蘋果、梨子都是水果的一種，這就是這三者的關係。用專業一點的說法就是香蕉、蘋果、梨子泛化為水果。和前面提到的老師、學生泛化為員工不一樣，員工是確實存在的，而水果只是一種泛稱，沒有一樣東西的名字直接叫水果的，我們見到的水果都是具體的一種水果。泛化以後的類，有可能是一種經過“抽象”後的東西，這個東西是看不到摸不著的，是我們腦袋裡面提煉出來的一種概念。
香蕉、蘋果、梨子泛化為水果，水果可以再泛化為食物，食物又可以進一步泛化。有沒有必要不斷泛化呢？泛化到怎樣的程度才是合適的呢？一般來說，如果有A、B、C等兩個或者以上的業務概念，我們發現它們有一些共同的特徵，則可以考慮將它們泛化為另外一個東西， 這樣能協助我們發現食物的本質；但如果只有一個A時，就沒有必要對A再進行泛化，例如：香蕉、蘋果、梨子已經泛化為水果了，而水果則沒有必要泛化為食物。當然這隻是一般準則，具體要泛化到怎樣的層次要看具體的業務分析需要，要靠你自己來把握。

練習4：公司的組織架構

這個練習開始有點複雜了，請你用類圖描述你所在公司的組織架構。如果你們公司比較龐大，你不是很瞭解整個公司的組織架構，那麼請你選擇你熟悉的部分用類圖來描述它的組織架構。如果你是學生，那麼請你描述你所在大學、學院或學系的組織架構。
我們可以用組織架構圖來描繪組織架構，為什麼要用類圖來表達呢？組織架構圖畫起來很方便，用類圖的畫反而覺得有點彆扭，用類圖來表達組織架構，是不是應該有更大的好處呢？請你帶著這些問題來完成這個練習。
某公司只是一個中小型的公司，該公司由一個一個的部門組成，用類圖表達其組織架構可能是這樣的：

圖 1.27  公司的組織架構1

該公司有一個行政人事部、一個研發部、一個服務部、一個銷售部、一個財務部。這個圖似乎公司有多少個部門，就多畫一個包含就搞定了，這樣畫似乎一點都顯示不出類圖的優勢。
下面這種畫法又如何呢？

圖 1.28  公司的組織架構2

注意圖中抽象部門這四個字是斜體字，這表明這個類是抽象類別（Abstract Class），抽象類別表示這個類是提煉出來的一種概念，是不具體存在的，具體存在的是繼承抽象部門的各個具體的部門。
前面提到的香蕉、蘋果、梨子泛化為水果，水果其實也是一種抽象的概念，前面那個圖的水果可以畫成抽象類別。
這個組織架構圖已經一定程度地揭示了公司組織架構的本質，一個公司無非就是由一個個部門組成的，只是每個公司具體的部門可能不一樣而已。這樣的表達效果，用普通的組織架構圖是表達不出來的，而類圖就可以發揮抽象和提煉的優勢。
下面這個圖將更進一步揭示公司組織架構的本質：

圖 1.29  公司的組織架構3

公司由一個個的部門組成，但要構成一個完整的公司，這些部門應該分為三類：
市場類部門：負責公司形象推廣、產品營銷方面的部門。
生產類部門：直接生產公司產品的部門。
支援類部門：不直接生產公司產品，但是支援產品生產或支撐公司運作必不可少的部門。
在這個圖中，市場類部門有策劃部、銷售部，生產類部門有研發部、實施部、IT部，支援類部門有：IT部、品質部、財務部、行政人事部，其中IT部既是生產類部門，也是支援類部門。

下面對其中一些具體部門進行解釋：
實施部是負責將軟體系統安裝到客戶現場，保障系統上線啟動並執行部門。
IT部主要負責兩方面的職能，一方面要保障公司內部的辦公軟硬體環境，另一方面會承接一些外部的網路工程，為公司直接盈利。第一方面的工作是屬於支援類方面的工作，而第二方面的工作則是生產類的工作。
品質部負責測試及過程保障的工作，這個部門是支援研發部和實施部工作的，故也屬於支援類的部門。
將部門分為市場類、生產類和支援類，只是其中一種的抽象方法，每個人可能會有不同的標準，遇到不同情況可能會有不同的抽象辦法。以上這個僅是一個例子，你千萬不要將其當成一個固定的標準。

總體來說，上述三個用類圖表示的公司組織架構，所針對的公司都不是大型的公司，大型的公司可能會有分公司、子公司、事業部等等不同的劃分辦法，組織架構異常複雜，想用類圖準確地表達出來並且能揭示其本質相當不容易。希望通過上述三個例子，能讓你初步體會用類圖提煉業務的優勢。

上面四個練習，基本覆蓋了你在前面小節學習到的類之間關係的知識。在我的經驗看來，直線（關聯）關係、內含項目關聯性是最常用的，泛化（繼承）關係用得也比較多，而依賴關係用得不是很多。而從使用的難度來說，泛化（繼承）關係是最考驗人的了，很考驗你發掘事物本質的能力。

類圖是不是很有意思呢？下面小節將會更加有意思，但同時難度也會進一步增大，喜歡挑戰的你一定是不會退縮的了！

 

作者：張傳波
www.umlonline.org/school/

 

---上篇到此結束，請看下篇---

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