目錄

一、什么是面向?qū)ο蠓椒?/p>

二、為什么要使用面向?qū)ο蠓椒?/p>

三、什么是建模

四、為什么要建模

五、UML明明是圖形，為什么說是語言？

六、UML有什么用？

七、UML圖為什么要分為結(jié)構(gòu)圖和行為圖?

八、UML結(jié)構(gòu)圖(Structure Diagram)

1.類圖(Class Diagram)

2.對(duì)象圖(Object Diagram)

3.構(gòu)件圖(Component Diagram)

4.部署圖(Deployment Diagram)

九、UML行為圖(Behavior Diagram)

1.活動(dòng)圖(Activity Diagram)

2.狀態(tài)機(jī)圖(State Machine Diagram)

3.順序圖(Sequence Diagram)

4.通信圖(Communication Diagram)

5.用例圖(Use Case Diagram)

十、各種UML圖實(shí)際應(yīng)用情況

十一、UML學(xué)習(xí)難點(diǎn)

十二、常用UML建模工具簡介

1.Rational Rose

2.VISIO

3.StarUML

一、什么是面向?qū)ο蠓椒?/h1>

面向?qū)ο蠓椒ㄊ且环N把面向?qū)ο蟮乃枷霊?yīng)用于軟件開發(fā)過程中，指導(dǎo)開發(fā)活動(dòng)的系統(tǒng)方法，簡稱OO方法，它是建立在對(duì)象概念（對(duì)象、類和繼承）基礎(chǔ)上的方法。自八十年代中期起，人們注重于面向?qū)ο蠓治龊驮O(shè)計(jì)的研究，逐步形成了面向?qū)ο蠓椒▽W(xué)。典型的方法有P.Coad和E.Yourdon的面向?qū)ο蠓治觯∣OA）和面向?qū)ο笤O(shè)計(jì)（OOD），G.Booch的面向?qū)ο箝_發(fā)方法，J.Rumbaugh等人提出的對(duì)象建模技術(shù)（OMT），Jacobson的面向?qū)ο筌浖こ蹋∣OSE）等。九十年代中期，由G.Booch，J.Rumbaugh，Jacobson等人發(fā)起，在Booch方法、OMT方法和OOSE 方法的基礎(chǔ)上推出了統(tǒng)一的建模語言（UML），1997年被國際對(duì)象管理組織（OMG）確定作為標(biāo)準(zhǔn)的建模語言。

二、為什么要使用面向?qū)ο蠓椒?/h1>

面向?qū)ο蠓椒ǖ某霈F(xiàn)很快受到計(jì)算機(jī)軟件界的青睞，并成為九十年代的主流開發(fā)方法，可以從下列幾個(gè)方面來分析其原因：

1.從認(rèn)知學(xué)的角度來看，面向?qū)ο蟮姆椒ǚ先藗儗?duì)客觀世界的認(rèn)識(shí)規(guī)律。很長一段時(shí)間里，我們分析、設(shè)計(jì)、實(shí)現(xiàn)一個(gè)軟件系統(tǒng)的過程與我們認(rèn)識(shí)一個(gè)系統(tǒng)的過程存在著差異。比如用結(jié)構(gòu)化分析和設(shè)計(jì)方法、信息工程方法。面向?qū)ο蟮姆治龊驮O(shè)計(jì)采用同樣的圖形表示形式，分析、設(shè)計(jì)和實(shí)現(xiàn)都以對(duì)象為基礎(chǔ)，因此面向?qū)ο箝_發(fā)的各階段之間具有很好的無縫連接。當(dāng)用戶的需求有所改變時(shí)，由于客觀世界中的實(shí)體是不變的，實(shí)體之間的聯(lián)系也是基本不變的，因此面向?qū)ο蟮目傮w結(jié)構(gòu)也相對(duì)比較穩(wěn)定，所引起的變化大多集中在對(duì)象的屬性與操作及對(duì)象之間的消息通信上?？傊?，面向?qū)ο蟮姆椒ǚ先藗儗?duì)客觀世界的認(rèn)識(shí)規(guī)律，所開發(fā)的系統(tǒng)相對(duì)比較穩(wěn)定。

2.面向?qū)ο蠓椒ㄩ_發(fā)的軟件系統(tǒng)易于維護(hù)，其體系結(jié)構(gòu)易于理解、擴(kuò)充和修改。面向?qū)ο蠓椒ㄩ_發(fā)的軟件系統(tǒng)由對(duì)象類組成，對(duì)象的封裝性很好地體現(xiàn)了抽象和信息隱蔽的特征。對(duì)象以屬性及操作作為接口（界面），使用者只可通過接口訪問對(duì)象（請(qǐng)求其服務(wù)），對(duì)象的具體實(shí)現(xiàn)細(xì)節(jié)對(duì)外是不可見的。這些特征使得軟件系統(tǒng)的體系結(jié)構(gòu)是模塊化的，這種體系結(jié)構(gòu)易于理解、擴(kuò)充和修改。當(dāng)對(duì)象的接口確定以后，實(shí)現(xiàn)細(xì)節(jié)的修改不會(huì)影響其它對(duì)象，易于維護(hù)。同時(shí)也便于分配給不同的開發(fā)人員去實(shí)現(xiàn)，依據(jù)規(guī)定的接口能方便地組裝成系統(tǒng)。

3.面向?qū)ο蠓椒ㄖ械睦^承機(jī)制有力支持軟件的復(fù)用。在同一應(yīng)用領(lǐng)域的不同應(yīng)用系統(tǒng)中，往往會(huì)涉及到許多相同或相似的實(shí)體，這些實(shí)體在不同的應(yīng)用系統(tǒng)中存在許多相同的屬性和操作，也存在一些不同的應(yīng)用系統(tǒng)所特有的屬性和操作。在開發(fā)一個(gè)新的軟件系統(tǒng)時(shí)，可復(fù)用已有系統(tǒng)中的某些類，通過繼承和補(bǔ)充形成新系統(tǒng)的類。在同一個(gè)應(yīng)用系統(tǒng)中，某些類之間也存在一些公共的屬性和操作，也含有它們各自私有的屬性和操作。這也可以通過繼承來復(fù)用公共的屬性和操作。

三、什么是建模

作曲家會(huì)將其腦袋中的旋律譜成樂曲，建筑師會(huì)將其設(shè)計(jì)的建筑物畫成藍(lán)圖，這些樂曲、藍(lán)圖就是模型(Model)，而建構(gòu)這些模型的過程就稱為建模(Modeling)。軟件開發(fā)如同音樂譜曲及建筑設(shè)計(jì)，其過程中也必須將需求、分析、設(shè)計(jì)、實(shí)現(xiàn)、布署等各項(xiàng)工作流程的構(gòu)想與結(jié)果予以呈現(xiàn)，這就是軟件系統(tǒng)的建模。

四、為什么要建模

建立大廈和建立狗窩的區(qū)別是建設(shè)狗窩不需要設(shè)計(jì)，要生產(chǎn)合格的軟件就要有一套關(guān)于體系結(jié)構(gòu)、過程和工具的規(guī)范。

五、UML明明是圖形，為什么說是語言？

語言是包括文字和圖形的!其實(shí)有很多內(nèi)容文字是無法表達(dá)的，你見過建筑設(shè)計(jì)圖紙嗎?里面有很多圖形，光用文字能表達(dá)清楚建筑設(shè)計(jì)嗎?在建筑界，有一套標(biāo)準(zhǔn)來描述設(shè)計(jì)，同樣的道理，在軟件開發(fā)界，我們也需要一套標(biāo)準(zhǔn)來幫助我們做好軟件開發(fā)的工作。UML就是其中的一種標(biāo)準(zhǔn)，注意這可不是唯一標(biāo)準(zhǔn)，只是UML是大家比較推崇的一種標(biāo)準(zhǔn)而已，說不定以后有一個(gè)更好的標(biāo)準(zhǔn)可能會(huì)取代它呢!UML并不是強(qiáng)制性標(biāo)準(zhǔn)，沒有法律規(guī)定你在軟件開發(fā)中一定要用UML，不能用其它的，我們的目標(biāo)是善用包括UML在內(nèi)的各種標(biāo)準(zhǔn)，來提高我們軟件開發(fā)的水平。

（備注：UML全稱是Unified Modeling Language，UML由1.0版發(fā)展到1.1、1.2、…，到現(xiàn)在的2.0、2.x。）

六、UML有什么用？

UML不限于支持面向?qū)ο蟮姆治雠c設(shè)計(jì)，還支持從需求分析開始的軟件開發(fā)的全過程。

七、UML圖為什么要分為結(jié)構(gòu)圖和行為圖?

1.顧名思義，結(jié)構(gòu)圖描述的是某種結(jié)構(gòu)，這種結(jié)構(gòu)在某段時(shí)間內(nèi)應(yīng)該是穩(wěn)定的，“靜態(tài)”的；而行為圖描述的是某種行為，是“動(dòng)態(tài)”的。

2.分析系統(tǒng)需求時(shí)，我們會(huì)面對(duì)很多業(yè)務(wù)概念，它們之間會(huì)有某些關(guān)系，這些內(nèi)容可以看成是“靜態(tài)”的，我們可以利用UML的結(jié)構(gòu)圖來分析。同時(shí)，業(yè)務(wù)會(huì)涉及大量的流程、過程等，這些內(nèi)容是“動(dòng)態(tài)”的，我們可以用行為圖來分析。

3.在我們軟件設(shè)計(jì)時(shí)，我們需要考慮需要哪些類、哪些構(gòu)件、系統(tǒng)最后怎樣部署等，這些內(nèi)容可以看成是“靜態(tài)”的，我們可以利用UML的結(jié)構(gòu)圖來設(shè)計(jì)。同時(shí)，我們也需要考慮軟件如何和用戶交互，類、構(gòu)件、模塊之間如何聯(lián)系等“動(dòng)態(tài)”內(nèi)容，我們可以利用行為圖來設(shè)計(jì)。

八、UML結(jié)構(gòu)圖(Structure Diagram)

1.類圖(Class Diagram)

請(qǐng)看下面這個(gè)類圖：

圖1.1某模具系統(tǒng)類圖

此圖截取自某模具管理系統(tǒng)的業(yè)務(wù)概念分析圖，圖中一個(gè)一個(gè)的矩形就是類，這些類之間有各種線條連接，這些線條表示類之間的關(guān)系。類圖是分析業(yè)務(wù)概念的首選，類圖可能是使用率最高的UML圖。

再看下面這個(gè)Person類圖，這是設(shè)計(jì)時(shí)用到的一個(gè)圖：

圖1.2 Person類圖

該P(yáng)erson類有以下屬性(Attribute)：Name(姓名),Sex(性別),Department(部門)等，有以下操作(Operation)：Work(工作)等。類有屬性和操作，但用類圖分析業(yè)務(wù)模型時(shí)，往往不需要使用操作，如圖1.1中的類就只有屬性。

Attribute有特性、特征等譯法，Operation也稱作方法，但本書遵循UML中文術(shù)語標(biāo)準(zhǔn)，即Attribute為屬性，Operation為操作。

2.對(duì)象圖(Object Diagram)

一般情況下只有在軟件開發(fā)中才會(huì)使用到對(duì)象圖，下面的內(nèi)容以開發(fā)的角度來說明對(duì)象圖。

圖1.2中的Person類，用代碼實(shí)例化如下：

Person person = new Person();

……

類(Class)實(shí)例化后就是對(duì)象(Object)，對(duì)象person是類Person的實(shí)例，上述代碼可以用對(duì)象圖表示如下：

圖 1.3 Person類的對(duì)象圖

對(duì)象圖和類圖的樣子很相似，對(duì)象是類的實(shí)例化，“person : Person”表示對(duì)象person是類Person的實(shí)例。對(duì)象圖往往只在需要描述復(fù)雜算法時(shí)才會(huì)使用，畫出來的對(duì)象圖往往不會(huì)只有一個(gè)對(duì)象，該圖只畫了一個(gè)對(duì)象，其目的是盡量簡化以便讀者的理解什么是對(duì)象圖。

在需求分析工作中基本上不需要使用對(duì)象圖，從嚴(yán)謹(jǐn)?shù)慕嵌葋砜茨承┣闆r下應(yīng)該使用對(duì)象圖，但我往往還是會(huì)用類圖來處理，這樣更加簡便而且容易理解。

3.構(gòu)件圖(Component Diagram)

構(gòu)件圖也叫組件圖，兩個(gè)名字均符合UML中文術(shù)語標(biāo)準(zhǔn)。

一輛汽車由輪子、發(fā)動(dòng)機(jī)等物理部件組成，一個(gè)軟件往往也是由很多“物理部件”(如：組件、重用構(gòu)件等)組成的，構(gòu)件圖就是用來描述軟件內(nèi)部物理組成的一種圖。下圖是某權(quán)限構(gòu)件設(shè)計(jì)圖：

圖 1.4 某權(quán)限構(gòu)件設(shè)計(jì)圖

圖1.4右上方有這樣標(biāo)志 的矩形表示一個(gè)構(gòu)件，構(gòu)件可以再包含構(gòu)件。

軟件需求分析工作中，需要用到構(gòu)件圖的情況不是很多，以下情況除外：

• 待開發(fā)的系統(tǒng)需要與第三方的系統(tǒng)、原有系統(tǒng)、某些老系統(tǒng)等交互，這時(shí)可用構(gòu)件圖描述交互要求。
• 客戶對(duì)軟件設(shè)計(jì)有某些特殊要求，這時(shí)可用構(gòu)件圖來描述要求。

構(gòu)件圖有時(shí)不會(huì)單獨(dú)使用，還會(huì)和部署圖一起結(jié)合使用。

4.部署圖(Deployment Diagram)

部署圖是用來描述系統(tǒng)如何部署、本系統(tǒng)與其他系統(tǒng)是怎樣的關(guān)系的一種圖，如下圖：

圖 1.5 某24小時(shí)便利店的管理系統(tǒng)部署圖

圖中一個(gè)個(gè)立體的矩形是部署圖的“節(jié)點(diǎn)”，一個(gè)節(jié)點(diǎn)表示一個(gè)物理的設(shè)備，節(jié)點(diǎn)之間的線條表示節(jié)點(diǎn)間的物理連接關(guān)系。

大部分客戶都會(huì)具備一定的IT基礎(chǔ)環(huán)境(如具備局域網(wǎng)、一些服務(wù)器、某些軟件平臺(tái)等)，軟件系統(tǒng)需要基于當(dāng)前的IT基礎(chǔ)環(huán)境來規(guī)劃，這時(shí)我們可以使用部署圖來做這個(gè)規(guī)劃。

分析系統(tǒng)的需求，不能忽略系統(tǒng)架構(gòu)、部署、IT架構(gòu)等方面的要求，我們要基于客戶當(dāng)前的IT基礎(chǔ)環(huán)境，做一個(gè)最符合客戶利益的規(guī)劃。

九、UML行為圖(Behavior Diagram)

1.活動(dòng)圖(Activity Diagram)

我們將起床到出門上班這個(gè)過程畫成活動(dòng)圖，可能是這樣的：

圖 1.7 起床到出門上班的活動(dòng)圖

活動(dòng)圖中的一個(gè)圓邊框框表示一個(gè)“活動(dòng)”，多個(gè)活動(dòng)之間的帶箭頭線條表示活動(dòng)的先后順序，該圖只是表達(dá)了一個(gè)順序流程，活動(dòng)圖還可以表達(dá)分支結(jié)構(gòu)。如果你以前曾學(xué)過流程圖的話，你會(huì)發(fā)現(xiàn)活動(dòng)圖和流程圖很相似。活動(dòng)圖可能是三種能表示流程的UML圖中最接近我們思維習(xí)慣的一種，下面來學(xué)習(xí)另外兩種能表達(dá)流程的圖。

2.狀態(tài)機(jī)圖(State Machine Diagram)

狀態(tài)機(jī)圖又叫狀態(tài)圖，狀態(tài)機(jī)圖從某個(gè)物品的狀態(tài)是如何變化的角度來展示流程，下圖某請(qǐng)假條審批流程：

圖 1.8 請(qǐng)假處理流程

整個(gè)請(qǐng)假審批流程是圍繞“請(qǐng)假條”這個(gè)物體進(jìn)行的，隨著不同的審批階段，請(qǐng)假條具備不同的狀態(tài)。我們分析業(yè)務(wù)流程時(shí)會(huì)發(fā)現(xiàn)很多流程其實(shí)是圍繞某個(gè)物品進(jìn)行的，這時(shí)可考慮使用狀態(tài)機(jī)圖。

3.順序圖(Sequence Diagram)

你去餐廳吃飯，向服務(wù)員點(diǎn)餐到服務(wù)員送菜上來，這個(gè)過程用順序圖可表示如下：

圖 1.9 點(diǎn)菜的順序圖

該圖有三個(gè)“小人”，每個(gè)“小人”下面的文字說明(如：顧客)表示其代表的角色。角色與角色之間有一些線條鏈接，表示角色之間是如何交互的。該圖表示的意思是：顧客向服務(wù)員點(diǎn)菜后，服務(wù)員將點(diǎn)菜信息傳遞給廚師，然后廚師做菜，最后再由服務(wù)員送菜給你。

點(diǎn)菜過程涉及幾個(gè)環(huán)節(jié)，每個(gè)環(huán)節(jié)均由不同的角色來負(fù)責(zé)，如果遇到類似的情況，你可以考慮使用順序圖來分析。用順序圖來分析的好處是能清晰表達(dá)整個(gè)過程所參與的角色，角色與角色之間的關(guān)系，各角色是如何被卷入這個(gè)過程當(dāng)中的。

4.通信圖(Communication Diagram)

UML1.1時(shí)，該圖英文名為Collaboration Diagram;UML2.x時(shí)，英文名為Communication Diagram。將英文名字直接翻譯，原來的英文名字可譯為協(xié)作圖，而新的英文名字譯為通信圖。

通信圖是順序圖的另外一種畫法，點(diǎn)菜的順序圖，如果用通信圖來畫可表示如下：

圖 1.10 點(diǎn)菜的通信圖

三個(gè)“小人”分表表示三種角色：顧客、服務(wù)員、廚師;角色之間有直線聯(lián)系表示他們之間有關(guān)系;帶序號(hào)的文字和箭頭，表示角色之間傳遞的信息。

順序圖更強(qiáng)調(diào)先后順序，通信圖更強(qiáng)調(diào)相互之間的關(guān)系。我覺得順序圖實(shí)用性更好一點(diǎn)，比通信圖能表達(dá)更多的信息，更容易讀懂，在需求分析工作中我基本不會(huì)使用通信圖。

5.用例圖(Use Case Diagram)

下圖是用例圖的示意圖：

圖 1.11 用例圖

用例圖表達(dá)的是什么角色通過軟件系統(tǒng)能做什么事情，我們可以使用用例圖系統(tǒng)地表達(dá)軟件系統(tǒng)的絕大部分需求。

十、各種UML圖實(shí)際應(yīng)用情況

十一、UML學(xué)習(xí)難點(diǎn)

學(xué)UML之難，不在于學(xué)習(xí)語法，關(guān)鍵是要改變思維習(xí)慣。UML是一種新的工具，但同時(shí)也是代表了一種新的先進(jìn)的思考方法，如果不能掌握這樣的方法，只能學(xué)到了UML的形，而沒有掌握其神髓。

要用好UML，你需要在平時(shí)多多培養(yǎng)下面的能力：

1.書面表達(dá)能力。

2.歸納總結(jié)能力。

3.“面向?qū)ο蟆钡乃季S能力和抽象能力。

平時(shí)你可以利用各種機(jī)會(huì)來提升第1和第2種能力，如多寫寫項(xiàng)目文檔、寫寫日記或博客等，多思考和總結(jié)平時(shí)自己的工作得失等。

只要你有進(jìn)步之心，多練習(xí)、多實(shí)踐、多思考、多總結(jié)，一定會(huì)取得長足進(jìn)步!

十二、常用UML建模工具簡介

1.Rational Rose

Rational Rose是Rational公司出品的一種面向?qū)ο蟮?span id="y7vnrjj" class="candidate-entity-word" data-gid="2352939">統(tǒng)一建模語言的可視化建模工具。用于可視化建模和公司級(jí)水平軟件應(yīng)用的組件構(gòu)造。
Rational Rose 是一個(gè)完全的、具有能滿足所有建模環(huán)境（Web開發(fā)，數(shù)據(jù)建模，Visual Studio和 C ）靈活性需求的一套解決方案。Rose 允許開發(fā)人員、項(xiàng)目經(jīng)理、系統(tǒng)工程師和分析人員在軟件開發(fā)周期內(nèi)將需求和系統(tǒng)的體系架構(gòu)轉(zhuǎn)換成代碼，消除浪費(fèi)的消耗，對(duì)需求和系統(tǒng)的體系架構(gòu)進(jìn)行可視化，理解和精練。通過在軟件開發(fā)周期內(nèi)使用同一種建模工具可以確保更快更好的創(chuàng)建滿足客戶需求的可擴(kuò)展的、靈活的并且可靠的應(yīng)用系統(tǒng)。
在面向?qū)ο髴?yīng)用程序開發(fā)領(lǐng)域，Rational Rose是影響其發(fā)展的一個(gè)重要因素。Rational Rose自推出以來就受到了業(yè)界的矚目，并一直引領(lǐng)著可視化建模工具的發(fā)展。越來越多的軟件公司和開發(fā)團(tuán)隊(duì)開始或者已經(jīng)采用Rational Rose，用于大型項(xiàng)目開發(fā)的分析、建模與設(shè)計(jì)等方面。
Rose2002功能上可以完成UML的9種標(biāo)準(zhǔn)建模，即靜態(tài)建模（用例圖、類圖、對(duì)象圖、組件圖、配置圖）和動(dòng)態(tài)建模（合作圖、序列圖、狀態(tài)轉(zhuǎn)移圖、活動(dòng)圖），為了使靜態(tài)建?？梢灾苯幼饔糜诖a，Rose提供了類設(shè)計(jì)到多種程序語言代碼自動(dòng)產(chǎn)生的插件。同時(shí)，作為一款優(yōu)秀的分析和設(shè)計(jì)工具，常用UML建模工具Rose具有強(qiáng)大的正向和逆向工程能力。正向工程這里指的是由設(shè)計(jì)產(chǎn)生代碼，逆向工程指由代碼歸納出設(shè)計(jì)。通過逆向工程Rose可以對(duì)歷史系統(tǒng)作出分析，然后進(jìn)行改進(jìn)，再通過正向工程產(chǎn)生新系統(tǒng)的代碼，這樣的設(shè)計(jì)方式我們稱之為再工程。

2.VISIO

VISIO原來僅僅是一種畫圖工具，能夠用來描述各種圖形（從電路圖到房屋結(jié)構(gòu)圖），也是到VISIO 2000才開始引進(jìn)軟件分析設(shè)計(jì)功能到代碼生成的全部功能，它可以說是目前最能夠用圖形方式來表達(dá)各種商業(yè)圖形用途的工具（對(duì)軟件開發(fā)中的UML支持僅僅是其中很少的一部分）。它跟微軟的office產(chǎn)品的能夠很好兼容。能夠把圖形直接復(fù)制或者內(nèi)嵌到WORD的文檔中。但是對(duì)于代碼的生成更多是支持微軟的產(chǎn)品如VB，VC ，C#，MS SQL Server 等（這也是微軟的傳統(tǒng)），所以它可以說用于圖形語義的描述比較方便，但是用于軟件開發(fā)過程的迭代開發(fā)則有點(diǎn)牽強(qiáng)。

3.StarUML

StarUML(簡稱SU)，是一種創(chuàng)建UML類圖，是一種生成類圖和其他類型的統(tǒng)一建模語言(UML)圖表的工具。StarUML是一個(gè)開源項(xiàng)目之一發(fā)展快、靈活、可擴(kuò)展性強(qiáng)。唯一不足之處，在反向工程時(shí)，只能生成類圖，不能生成類之間的關(guān)系。