摘要：類圖（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

轉載于:https://www.cnblogs.com/umlonline/archive/2011/10/18/2215850.html

總結

以上是生活随笔為你收集整理的分析业务模型-类图（Class Diagram）（上）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。