第11章統(tǒng)一建模語(yǔ)言(UML)11.1概述11.2UML概念模型11.3UML的靜態(tài)建模機(jī)制11.4UML的動(dòng)態(tài)建模機(jī)制11.5UML面向?qū)崿F(xiàn)機(jī)制11.6UML建模工具11.7UML建模實(shí)例11.8實(shí)戰(zhàn)訓(xùn)練 11.1概述

11.1.1什么是UML

UML是UnifiedModelingLanguage(統(tǒng)一建模語(yǔ)言)的簡(jiǎn)稱，是基于OMG(ObjectManagementGroup)進(jìn)行標(biāo)準(zhǔn)化、軟件成果的式樣化和圖形化的一種語(yǔ)言。Booch在其經(jīng)典的一書《TheUnifiedModelingLanguageUserGuide》中對(duì)UML進(jìn)行過(guò)詳細(xì)的定義：

UML是對(duì)軟件密集型系統(tǒng)中的制品進(jìn)行可視化、詳細(xì)化、構(gòu)造和文檔化的語(yǔ)言。其中的制品是指在軟件開發(fā)過(guò)程中的各個(gè)階段所產(chǎn)生的各種各樣的成果物，例如模型、原代碼、測(cè)試用例等。

UML代表著面向?qū)ο蠹夹g(shù)的軟件開發(fā)方法的發(fā)展方向，在國(guó)際上越來(lái)越受到重視，現(xiàn)已成為國(guó)際軟件行業(yè)建模語(yǔ)言的標(biāo)準(zhǔn)，目前已經(jīng)占有面向?qū)ο蠹夹g(shù)市場(chǎng)的90%以上。

11.1.2UML的發(fā)展史

20世紀(jì)80年代中期至90年代初期面向?qū)ο蠹夹g(shù)逐漸被普及和廣泛應(yīng)用，伴隨著面向?qū)ο蠹夹g(shù)的迅猛發(fā)展，也相繼出現(xiàn)了各種各樣的方法論，例如1988年RebeccaWirfsBrock提出的職責(zé)驅(qū)動(dòng)(RCR)卡片法、1991年P(guān)eterCoad提出的OOA/OOD方法、1991年GradyBooch提出的Booch方法等。由于方法論的不同，對(duì)同一個(gè)問題的描述表示法也有所不同，這樣就在軟件行業(yè)中的系統(tǒng)開發(fā)者之間產(chǎn)生了很大的混亂。

1994年10月，由GradyBooch和JimRumbaugh首先將Booch和OMT統(tǒng)一起來(lái)，并于1995年發(fā)布了稱為統(tǒng)一方法的UM0.8版(UnifiedMethod)，1996年6月發(fā)布了統(tǒng)一建模語(yǔ)言UML0.9版(UnifiedModelingLanguage)，2002年11月出現(xiàn)了UML1.4版，此后每隔幾年就會(huì)進(jìn)行版本更新，現(xiàn)在已經(jīng)發(fā)布了最新的UML2.0版。圖11.1UML的發(fā)展歷史11.1.3UML的特點(diǎn)

UML具有以下特點(diǎn)：

(1)面向?qū)ο?。UML支持面向?qū)ο蠹夹g(shù)的主要概念，提供了一批基本的模型元素的表示圖形和方法，能簡(jiǎn)潔明了地表達(dá)面向?qū)ο蟮母鞣N概念。

(2)可視化，表示能力強(qiáng)。通過(guò)UML的模型圖能清晰地表示系統(tǒng)的邏輯模型和實(shí)現(xiàn)模型?？捎糜诟鞣N復(fù)雜系統(tǒng)的建模。

(3)獨(dú)立于過(guò)程。UML是系統(tǒng)建模語(yǔ)言，獨(dú)立于開發(fā)過(guò)程。

(4)獨(dú)立于程序設(shè)計(jì)語(yǔ)言。用UML建立的軟件系統(tǒng)模型可以用Java、VC++、Smalltalk等任何一種面向?qū)ο蟮某绦蛟O(shè)計(jì)語(yǔ)言來(lái)實(shí)現(xiàn)。

(5)易于掌握使用。UML圖形結(jié)構(gòu)清晰，建模簡(jiǎn)潔明了，容易掌握使用。11.1.4UML的應(yīng)用領(lǐng)域

UML的目標(biāo)是以面向?qū)ο髨D的方式來(lái)描述任何類型的系統(tǒng)，具有很寬的應(yīng)用領(lǐng)域。其中最常用的是建立軟件系統(tǒng)的模型，但它同樣也可以用于描述非軟件領(lǐng)域的系統(tǒng)，如機(jī)械系統(tǒng)、企業(yè)機(jī)構(gòu)或業(yè)務(wù)過(guò)程，以及處理復(fù)雜數(shù)據(jù)的信息系統(tǒng)、具有實(shí)時(shí)要求的工業(yè)系統(tǒng)或工業(yè)過(guò)程等。總之，UML是一個(gè)通用的標(biāo)準(zhǔn)建模語(yǔ)言，可以對(duì)任何具有靜態(tài)結(jié)構(gòu)和動(dòng)態(tài)行為的系統(tǒng)進(jìn)行建模。11.1.4UML的應(yīng)用領(lǐng)域

UML的目標(biāo)是以面向?qū)ο髨D的方式來(lái)描述任何類型的系統(tǒng)，具有很寬的應(yīng)用領(lǐng)域。其中最常用的是建立軟件系統(tǒng)的模型，但它同樣也可以用于描述非軟件領(lǐng)域的系統(tǒng)，如機(jī)械系統(tǒng)、企業(yè)機(jī)構(gòu)或業(yè)務(wù)過(guò)程，以及處理復(fù)雜數(shù)據(jù)的信息系統(tǒng)、具有實(shí)時(shí)要求的工業(yè)系統(tǒng)或工業(yè)過(guò)程等?？傊琔ML是一個(gè)通用的標(biāo)準(zhǔn)建模語(yǔ)言，可以對(duì)任何具有靜態(tài)結(jié)構(gòu)和動(dòng)態(tài)行為的系統(tǒng)進(jìn)行建模。

UML適用于系統(tǒng)開發(fā)過(guò)程中從需求規(guī)格描述到系統(tǒng)完成后測(cè)試的不同階段。

(1)在需求分析階段，可以用用例來(lái)捕獲用戶需求。通過(guò)用例建模，可描述對(duì)系統(tǒng)感興趣的外部角色及其對(duì)系統(tǒng)(用例)的功能要求。

(2)在分析階段，主要關(guān)心問題域中的主要概念(如抽象、類和對(duì)象等)和機(jī)制，需要識(shí)別這些類以及它們相互間的關(guān)系，并用UML類圖來(lái)描述。為實(shí)現(xiàn)用例，類之間需要相互協(xié)作，可以用UML動(dòng)態(tài)模型來(lái)描述。在分析階段，只對(duì)問題域的對(duì)象(現(xiàn)實(shí)世界的概念)建模，而不考慮定義軟件系統(tǒng)中技術(shù)細(xì)節(jié)的類(如處理用戶接口、數(shù)據(jù)庫(kù)、通信和并行性等問題的類)。這些技術(shù)細(xì)節(jié)將在設(shè)計(jì)階段被引入。

(3)在設(shè)計(jì)階段，將為構(gòu)造階段提供更詳細(xì)的規(guī)格說(shuō)明。編程(構(gòu)造)是一個(gè)獨(dú)立的階段，其任務(wù)是用面向?qū)ο缶幊陶Z(yǔ)言將來(lái)自設(shè)計(jì)階段的類轉(zhuǎn)換成實(shí)際的代碼。

UML模型還可作為測(cè)試階段的依據(jù)。系統(tǒng)通常需要經(jīng)過(guò)單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試和驗(yàn)收測(cè)試。不同的測(cè)試小組使用不同的UML圖作為測(cè)試依據(jù)。具體情況是：

(1)單元測(cè)試使用類圖和類規(guī)格說(shuō)明。

(2)集成測(cè)試使用部件圖、合作圖。

(3)系統(tǒng)測(cè)試使用用例圖來(lái)驗(yàn)證系統(tǒng)的行為。

(4)驗(yàn)收測(cè)試由用戶進(jìn)行，以驗(yàn)證系統(tǒng)測(cè)試的結(jié)果是否滿足在分析階段確定的需求。11.1.5基于UML的設(shè)計(jì)過(guò)程

運(yùn)用UML進(jìn)行面向?qū)ο蟮南到y(tǒng)分析設(shè)計(jì)，其過(guò)程通常由以下三個(gè)部分組成：

(1)識(shí)別系統(tǒng)的用例和角色。首先對(duì)項(xiàng)目進(jìn)行需求調(diào)研，依據(jù)項(xiàng)目的業(yè)務(wù)流程圖和數(shù)據(jù)流程圖以及項(xiàng)目中涉及的各級(jí)操作人員，通過(guò)分析，識(shí)別出系統(tǒng)中的所有用例和角色；接著分析系統(tǒng)中各角色和用例間的聯(lián)系，再使用UML建模工具畫出系統(tǒng)的用例圖，同時(shí)，勾畫系統(tǒng)的概念層模型，借助UML建模工具描述概念層的類圖和活動(dòng)圖。

(2)進(jìn)行系統(tǒng)分析，并抽取類。系統(tǒng)分析的任務(wù)是找出系統(tǒng)的所有需求并加以描述，同時(shí)建立特定域模型。建立域模型有助于開發(fā)人員考察用例，從中抽取出類，并描述類之間的關(guān)系。

(3)系統(tǒng)設(shè)計(jì)，并設(shè)計(jì)類及其行為。

設(shè)計(jì)階段由結(jié)構(gòu)設(shè)計(jì)和詳細(xì)設(shè)計(jì)組成。

(1)結(jié)構(gòu)設(shè)計(jì)是高層設(shè)計(jì)，其任務(wù)是定義包(子系統(tǒng))，包括包間的依賴關(guān)系和主要通信機(jī)制。包有利于描述系統(tǒng)的邏輯組成部分以及各部分之間的依賴關(guān)系。

(2)詳細(xì)設(shè)計(jì)就是要細(xì)化包的內(nèi)容，清晰描述所有的類，同時(shí)使用UML的動(dòng)態(tài)模型描述在特定環(huán)境下這些類的實(shí)例的行為。 11.2UML概念模型

11.2.1UML的構(gòu)成

UML主要由三類元素構(gòu)成：基本構(gòu)造塊(BasicBuildingBlock)、規(guī)則(Rule)和公共機(jī)

制(CommonMechanism)。11.2.2UML的基本構(gòu)造塊

UML的基本構(gòu)造塊包括三種類型：事物(Thing)、關(guān)系(Relationship)和圖(Diagram)。

事物又分為四種類型：

(1)結(jié)構(gòu)事物(StructuralThing)。UML中的結(jié)構(gòu)事物包括類(Class)、接口(Interface)、協(xié)作(Collaboration)、用例(UseCase)、主動(dòng)類(ActiveClass)、構(gòu)件(Component)和結(jié)點(diǎn)(Node)。

(2)行為事物(BehavioralThing)。UML中的行為事物包括交互(Interaction)和狀態(tài)機(jī)(StateMachine)。

(3)分組事物(GroupingThing)。UML中的分組事物是包(Package)。

(4)注釋事物(AnnotationalThing)。UML中的注釋事物是注解(Note)。關(guān)系有四種類型：

(1)依賴(Dpendency)。若一個(gè)對(duì)象A發(fā)生變化，可能會(huì)引起另一個(gè)對(duì)象B的變化，則稱對(duì)象B依賴于對(duì)象A。

(2)關(guān)聯(lián)(Association)。關(guān)聯(lián)表示一種對(duì)象和另一種對(duì)象有聯(lián)系，是一種結(jié)構(gòu)化關(guān)系。

(3)泛化(Generation)。泛化表示對(duì)象的一般類和特殊類之間的關(guān)系，相當(dāng)于C++中的繼承關(guān)系。

(4)實(shí)現(xiàn)(Realization)。實(shí)現(xiàn)表示一種模型元素A(如類)與另一種模型元素B(如接口)連接起來(lái)，其中模型B只是行為的說(shuō)明，而真正的實(shí)現(xiàn)則由模型A來(lái)完成。

UML有四種視圖和九種圖：

(1)用例視圖(UseCaseDiagram)。用例視圖從用戶角度描述系統(tǒng)功能，并指出各功能的操作者。

(2)靜態(tài)視圖(StaticDiagram)。靜態(tài)視圖包括類圖、對(duì)象圖和包圖。

(3)動(dòng)態(tài)視圖(DynamicDiagram)。動(dòng)態(tài)視圖描述系統(tǒng)的動(dòng)態(tài)模型和組成對(duì)象間的交互關(guān)系，包括狀態(tài)圖、活動(dòng)圖、時(shí)序圖和協(xié)作圖。

(4)實(shí)現(xiàn)圖(ImplementationDiagram)。實(shí)現(xiàn)圖包括組件圖和配置圖。在UML中建模主要分為靜態(tài)建模和動(dòng)態(tài)建模兩類。

靜態(tài)建模主要是對(duì)客觀事物靜態(tài)結(jié)構(gòu)的一種抽象，它所反映的是目標(biāo)系統(tǒng)的靜態(tài)數(shù)據(jù)。UML提供了豐富的靜態(tài)建模機(jī)制，包括用例圖、類圖、對(duì)象圖、包圖等，其中尤以用例圖和類圖最為重要。

動(dòng)態(tài)建模則強(qiáng)調(diào)的是系統(tǒng)的行為，它所建立的模型或者可以執(zhí)行，或者表示執(zhí)行時(shí)的時(shí)序狀態(tài)或交互關(guān)系。動(dòng)態(tài)建模包括協(xié)作圖、時(shí)序圖、活動(dòng)圖、狀態(tài)圖等四個(gè)圖形，是標(biāo)準(zhǔn)建模語(yǔ)言UML的動(dòng)態(tài)建模機(jī)制。11.2.3UML的規(guī)則

像其他語(yǔ)言一樣，UML是有一套規(guī)則的，這些規(guī)則描述了一個(gè)結(jié)構(gòu)良好的模型看起來(lái)應(yīng)該像什么。一個(gè)結(jié)構(gòu)良好的模型應(yīng)該在語(yǔ)義上是前后一致的，并且與所有的相關(guān)模型協(xié)調(diào)一致。

UML有用于描述如下事物的語(yǔ)義規(guī)則：

(1)命名：為事物、關(guān)系和圖起名。

(2)范圍：給一個(gè)名稱以特定含義的語(yǔ)境。

(3)可見性：讓其他人使用或看見名稱。

(4)完整性：使事物正確、一致地相互聯(lián)系。

(5)執(zhí)行：運(yùn)行或模擬動(dòng)態(tài)模型的含義。

UML的規(guī)則鼓勵(lì)(不是強(qiáng)迫)專注于最重要的分析、設(shè)計(jì)和實(shí)現(xiàn)問題，這些問題將促使模型隨時(shí)間的推移而具有良好的結(jié)構(gòu)。11.2.4UML的公共機(jī)制

UML有四種貫穿整個(gè)語(yǔ)言并且被一致應(yīng)用的公共機(jī)制：

(1)規(guī)格說(shuō)明。規(guī)格說(shuō)明提供了一個(gè)語(yǔ)義底板，它包含了一個(gè)系統(tǒng)的各模型的所有部分，各部分相互聯(lián)系，并保持一致性。因此，UML的圖只不過(guò)是對(duì)底板的簡(jiǎn)單視覺投影，每一個(gè)圖展現(xiàn)了系統(tǒng)的一個(gè)特定方面。

(2)修飾。UML表示法中的每一個(gè)元素都有一個(gè)基本符號(hào)，可以把各種修飾細(xì)節(jié)加到這個(gè)符號(hào)上。

(3)通用劃分。在對(duì)面向?qū)ο笙到y(tǒng)建模時(shí)至少有兩種劃分方法：一種是對(duì)類和對(duì)象的劃分；一種是接口和實(shí)現(xiàn)的分離。

(4)擴(kuò)展機(jī)制。擴(kuò)展機(jī)制包括構(gòu)造型、標(biāo)記值和約束。構(gòu)造型擴(kuò)展了UML的詞匯，它允許創(chuàng)造新的構(gòu)造塊，這個(gè)新構(gòu)造塊既可從現(xiàn)有的構(gòu)造塊派生，又專門針對(duì)要解決的問題；標(biāo)記值擴(kuò)展了UML構(gòu)造塊的特性，允許創(chuàng)建詳述元素的新信息；約束擴(kuò)展了UML構(gòu)造塊的語(yǔ)義，它允許增加新的規(guī)則或修改現(xiàn)有的規(guī)則。

11.3UML的靜態(tài)建模機(jī)制

11.3.1用例圖

無(wú)論在面向?qū)ο箝_發(fā)中還是在傳統(tǒng)的軟件開發(fā)中，人們總是根據(jù)典型的使用情景來(lái)了解用戶需求。這些使用情景是非正式的，難以建立正式文擋。在UML中可以通過(guò)用例圖(UseCaseDiagram)來(lái)構(gòu)造目標(biāo)系統(tǒng)的用例模型，它通過(guò)用例來(lái)捕獲用戶需求，通過(guò)用例建模來(lái)描述對(duì)系統(tǒng)感興趣的外部角色及其對(duì)系統(tǒng)(用例)的功能要求。它從系統(tǒng)外部觀察系統(tǒng)，而不涉及技術(shù)上如何做這些事。

1．用例模型

用例模型(UseCaseModel)描述的是外部執(zhí)行者(Actor)所理解的系統(tǒng)功能。用例模型用于需求分析階段，它的建立是系統(tǒng)開發(fā)者和用戶反復(fù)討論的結(jié)果，表明了開發(fā)者和用戶對(duì)需求規(guī)格達(dá)成的共識(shí)。首先，它描述了待開發(fā)系統(tǒng)的功能需求；其次，它將系統(tǒng)看做黑盒，從外部執(zhí)行者的角度來(lái)理解系統(tǒng)；第三，它驅(qū)動(dòng)了需求分析之后各階段的開發(fā)工作，不僅在開發(fā)過(guò)程中保證了系統(tǒng)所有功能的實(shí)現(xiàn)，而且用于驗(yàn)證和檢測(cè)所開發(fā)的系統(tǒng)，從而影響到開發(fā)工作的各個(gè)階段和UML的各個(gè)模型。在UML中，一個(gè)用例模型由若干個(gè)用例圖描述，用例圖的主要元素是用例和執(zhí)行者。

2．用例

從本質(zhì)上講，一個(gè)用例(UseCase)是用戶與計(jì)算機(jī)之間的一次典型交互過(guò)程。在UML中，用例被定義成系統(tǒng)執(zhí)行的一系列動(dòng)作，動(dòng)作執(zhí)行的結(jié)果能被指定執(zhí)行者察覺到。

在UML中，用例表示為一個(gè)橢圓。概括地說(shuō)，用例具有以下特點(diǎn)：

●用例捕獲某些用戶可見的需求，實(shí)現(xiàn)一個(gè)具體的用戶目標(biāo)。

●用例由執(zhí)行者激活，并給執(zhí)行者提供確切的值。

●用例可大可小，但它必須是對(duì)一個(gè)具體的用戶目標(biāo)實(shí)現(xiàn)的完整描述。

3．執(zhí)行者

執(zhí)行者(Actor)是指用戶在系統(tǒng)中所扮演的角色，其圖形化的表示是一個(gè)小人。圖11.2中有兩個(gè)執(zhí)行者：學(xué)生和管理員。在系統(tǒng)中有許多學(xué)生，但他們均起著同一種作用，扮演著相同的角色，所以用一個(gè)執(zhí)行者表示。一個(gè)用戶也可以扮演多種角色(執(zhí)行者)，例如一個(gè)老師還可以是管理員。在處理執(zhí)行者時(shí)，應(yīng)考慮其作用，而不是人或工作名稱，這一點(diǎn)是很重要的。圖11.2學(xué)生成績(jī)管理系統(tǒng)用例圖不帶箭頭的線段將執(zhí)行者與用例連接到一起，表示兩者之間交換信息，稱之為通信聯(lián)系。執(zhí)行者觸發(fā)用例，并與用例進(jìn)行信息交換。單個(gè)執(zhí)行者可與多個(gè)用例聯(lián)系；反過(guò)來(lái)，一個(gè)用例也可與多個(gè)執(zhí)行者聯(lián)系。對(duì)同一個(gè)用例而言，不同執(zhí)行者起著不同的作用：他們可以從用例中取值，也可以參與到用例中。

需要注意的是，盡管執(zhí)行者在用例圖中是用類似于人的圖形來(lái)表示的，但執(zhí)行者未必是人。例如，執(zhí)行者也可以是一個(gè)外界系統(tǒng)，該外界系統(tǒng)可能需要從當(dāng)前系統(tǒng)中獲取信息而與當(dāng)前系統(tǒng)進(jìn)行交互。

通過(guò)實(shí)踐，我們發(fā)現(xiàn)執(zhí)行者對(duì)提供用例是非常有用的。面對(duì)一個(gè)大系統(tǒng)，要列出用例清單常常十分困難。這時(shí)可先列出執(zhí)行者清單，再對(duì)每個(gè)執(zhí)行者列出它的用例，這樣問題就會(huì)變得容易很多。圖11.3用例圖

4．使用和擴(kuò)展

除了執(zhí)行者與用例之間的連接外，還有另外兩種類型的連接，用以表示用例之間的使用和擴(kuò)展關(guān)系。使用和擴(kuò)展(UseandExtend)是兩種不同形式的繼承關(guān)系。

當(dāng)一個(gè)用例與另一個(gè)用例相似，但所做的動(dòng)作多一些時(shí)，就可以用到擴(kuò)展關(guān)系。

當(dāng)一個(gè)用例使用另一個(gè)用例時(shí)，這兩個(gè)用例之間就構(gòu)成了使用關(guān)系。一般來(lái)說(shuō)，如果在若干個(gè)用例中有某些相同的動(dòng)

作，則可以把這些相同的動(dòng)作提取出來(lái)單獨(dú)構(gòu)成一個(gè)用例(稱為抽象用例)。例如，圖11.3中學(xué)位課程的學(xué)習(xí)包括課程設(shè)計(jì)，因此二者構(gòu)成了使用關(guān)系；學(xué)位課程的學(xué)習(xí)比專業(yè)課程的學(xué)習(xí)有更多的要求，因此二者構(gòu)成了擴(kuò)展關(guān)系。

請(qǐng)注意擴(kuò)展與使用之間的相似點(diǎn)和不同點(diǎn)。它們都意味著從幾個(gè)用例中抽取那些公共的行為并放入一個(gè)單獨(dú)用例中，而這個(gè)用例被其他幾個(gè)用例使用或擴(kuò)展，但使用和擴(kuò)展的目的是不同的。

5．用例模型的獲取

幾乎在任何情況下都會(huì)使用用例。用例用來(lái)獲取需求、規(guī)劃和控制項(xiàng)目。用例的獲取是需求分析階段的主要任務(wù)之一，而且是首先要做的工作。大部分用例將在項(xiàng)目的需求分析階段產(chǎn)生。隨著工作的深入，更多的用例會(huì)被發(fā)現(xiàn)，這些用例都應(yīng)及時(shí)增添到已有的用例集中。用例集中的每個(gè)用例都是一個(gè)潛在的需求。

(1)獲取執(zhí)行者。獲取用例首先要找出系統(tǒng)的執(zhí)行者?？梢酝ㄟ^(guò)用戶回答一些問題的答案來(lái)識(shí)別執(zhí)行者。以下問題可供參考：

●誰(shuí)使用系統(tǒng)的主要功能(主要使用者)？

●誰(shuí)需要系統(tǒng)支持他們的日常工作？

●誰(shuí)來(lái)維護(hù)、管理，以使系統(tǒng)正常工作(輔助使用者)？

●系統(tǒng)需要操縱哪些硬件？

●系統(tǒng)需要與其他哪些系統(tǒng)(包含其他計(jì)算機(jī)系統(tǒng)和其他應(yīng)用程序)交互？

●對(duì)系統(tǒng)產(chǎn)生的結(jié)果感興趣的人或事物是什么？

(2)獲取用例。一旦獲取了執(zhí)行者，就可以對(duì)每個(gè)執(zhí)行者提出問題以獲取用例。以下問題可供參考：

●執(zhí)行者要求系統(tǒng)提供哪些功能(執(zhí)行者需要做什么)？

●執(zhí)行者需要讀、產(chǎn)生、刪除、修改或存儲(chǔ)的信息有哪些類型？

●必須提醒執(zhí)行者的系統(tǒng)事件有哪些？執(zhí)行者必須提醒系統(tǒng)的事件有哪些？怎樣把這些事件表示成用例中的功能？為了完整地描述用例，還需要知道執(zhí)行者的某些典型功能能否被系統(tǒng)自動(dòng)實(shí)現(xiàn)。還有一些不針對(duì)具體執(zhí)行者的問題(即針對(duì)整個(gè)系統(tǒng)的問題)：

●系統(tǒng)需要何種輸入、輸出？輸入從何處來(lái)？輸出到何處？

●當(dāng)前運(yùn)行系統(tǒng)(也許是一些手工操作而不是計(jì)算機(jī)系統(tǒng))的主要問題是什么？

需要注意的是，最后兩個(gè)問題并不是指沒有執(zhí)行者也可以有用例，只是獲取用例時(shí)尚不知道執(zhí)行者是什么。實(shí)際上一個(gè)用例必須至少與一個(gè)執(zhí)行者關(guān)聯(lián)。還需要注意：不同的設(shè)計(jì)者對(duì)用例的利用程度也不同。例如，IvarJacobson說(shuō)，對(duì)一個(gè)10人·年的項(xiàng)目，他需要20個(gè)用例。而在一個(gè)相同規(guī)模的項(xiàng)目中，MartinFowler則用了一百多個(gè)用例。我們認(rèn)為：任何合適的用例都可使用，確定用例的過(guò)程是對(duì)獲取的用例進(jìn)行提煉和歸納的過(guò)程。11.3.2類圖

類圖(ClassDiagram)專門用于捕獲系統(tǒng)的詞匯表。

(1)類。類是具有相同屬性、操作、關(guān)系的對(duì)象集合的總稱。通常在UML中類被畫成

矩形。

(2)類圖。類圖用來(lái)描述類和類之間的靜態(tài)關(guān)系，在系統(tǒng)的整個(gè)生命周期都是有效的。與數(shù)據(jù)模型不同，類圖不僅顯示了信息的結(jié)構(gòu)，同時(shí)還描述了系統(tǒng)的行為。類圖是定義其他圖的基礎(chǔ)。在類圖的基礎(chǔ)上，狀態(tài)圖、協(xié)作圖等進(jìn)一步描述了系統(tǒng)其他方面的特性。

(3)名稱。每個(gè)類都必須有一個(gè)名字，用來(lái)與其他的類區(qū)分。類名是一個(gè)字符串，稱為簡(jiǎn)單名字。

(4)屬性。屬性是指類的命名的特性，常常代表一類取值。類可以有任意多個(gè)屬性，也可以沒有屬性?？梢灾粚懮蠈傩悦Q，也可以在屬性名稱后跟上類型甚至缺省取值。根據(jù)圖的詳細(xì)程度，每條屬性可以包括屬性的可見性、屬性名稱、類型、缺省值和約束特性。UML規(guī)定類的屬性的語(yǔ)法為：

可見性屬性名稱：類型=缺省值{約束特性}

常用的可見性有Public、Private和Protected三種，在UML中分別表示為“+”、“-”和“#”。類型表示該屬性的種類，它可以是基本數(shù)據(jù)類型，例如整數(shù)、實(shí)數(shù)、布爾型等，也可以是用戶自定義的類型，一般由所涉及的程序設(shè)計(jì)語(yǔ)言確定。約束特性則是用戶對(duì)該屬性性質(zhì)的一個(gè)約束說(shuō)明。例如，“{只讀}”說(shuō)明該屬性是只讀屬性。

(5)操作。操作是類的任意一個(gè)實(shí)例對(duì)象都可以調(diào)用的，并可能影響該對(duì)象行為的實(shí)現(xiàn)。操作可省略。操作用于修改、檢索類的屬性或執(zhí)行某些動(dòng)作。它們被約束在類的內(nèi)部，只能作用到該類的對(duì)象上。UML規(guī)定操作的語(yǔ)法為：

可見性操作名(參數(shù)表)：返回類型{約束特性}

(6)約束。在UML中，可以用約束來(lái)表示規(guī)則。約束是放在“{}”中的一個(gè)表達(dá)式，表示一個(gè)永真的邏輯陳述。

(7)組織屬性和方法。在畫類圖的時(shí)候沒有必要將全部的屬性和操作都畫出來(lái)。實(shí)際上，在大部分情況下我們也不可能在一個(gè)圖中將類的屬性和操作都畫出來(lái)，只將感興趣的屬性和操作畫出來(lái)就可以了?？梢杂谩啊北硎具€有屬性或操作沒有畫出來(lái)。使用類圖進(jìn)行建模的幾個(gè)建議是：

(1)不要試圖使用所有的符號(hào)。在UML中，有些符號(hào)僅用于特殊的場(chǎng)合和方法中，只有當(dāng)需要時(shí)才去使用。

(2)根據(jù)項(xiàng)目開發(fā)的不同階段，用正確的觀點(diǎn)來(lái)畫類圖。如果處于分析階段，應(yīng)畫概念層類圖；當(dāng)開始著手軟件設(shè)計(jì)時(shí)，應(yīng)畫說(shuō)明層類圖；當(dāng)考察某個(gè)特定的實(shí)現(xiàn)技術(shù)時(shí)，則應(yīng)畫實(shí)現(xiàn)層類圖。

(3)不要為每個(gè)事物都畫一個(gè)模型，而應(yīng)該把精力放在關(guān)鍵的領(lǐng)域。最好只畫幾張較為關(guān)鍵的圖，經(jīng)常使用并不斷修改。

(4)使用類圖的最大危險(xiǎn)是過(guò)早地陷入實(shí)現(xiàn)細(xì)節(jié)。為了避免這一危險(xiǎn)，應(yīng)該將重點(diǎn)放在概念層和說(shuō)明層。11.3.3對(duì)象圖

對(duì)象圖(ObjectDiagram)用于捕獲實(shí)例和連接。UML中的對(duì)象圖與類圖具有相同的表示形式。對(duì)象圖可以看做是類圖的一個(gè)實(shí)例。對(duì)象是類的實(shí)例。對(duì)象之間的鏈?zhǔn)穷愔g的關(guān)聯(lián)的實(shí)例。鏈的圖形表示與關(guān)聯(lián)相似。對(duì)象與類的圖形表示相似，即為劃分成兩個(gè)格子的長(zhǎng)方形。下面的格子可省略，上面的格子顯示對(duì)象名和類。

對(duì)象名格式為

對(duì)象名:類名

類名和對(duì)象名下面有下劃線；下面的格子記錄對(duì)象的屬性以及值的列表，其格式為

屬性:類型=值

類型可以省略。對(duì)象圖常用于表示復(fù)雜的類圖的一個(gè)實(shí)例。11.3.4包圖

隨著系統(tǒng)的逐漸變化，理解和修改這個(gè)系統(tǒng)也就變得更加困難，最好的方法是將復(fù)雜問題分解為多個(gè)簡(jiǎn)單的問題。包(Package)是一種組合機(jī)制，把許多類集合成一個(gè)更高層次的單位，形成一個(gè)高內(nèi)聚、低耦合的類的集合。

不僅僅是類可以運(yùn)用包的機(jī)制，任何模型元素都可以運(yùn)用包的機(jī)制(比如用例)。如果沒有任何啟發(fā)性原則來(lái)指導(dǎo)類的分組，分組方法就會(huì)很隨意。在UML中，最有用和強(qiáng)調(diào)最多的原則就是依賴性。通常，包圖所顯示的是類的包以及這些包之間的依賴關(guān)系。嚴(yán)格地說(shuō)，這里所講的包和依賴關(guān)系都是類圖中的元素，因此包圖僅僅是另一種形式的類圖。包的圖示類似于書簽卡片的形狀，由兩個(gè)長(zhǎng)方形組成。小長(zhǎng)方形(標(biāo)簽)位于大長(zhǎng)方形的左上角。如果包的內(nèi)容(比如類)沒被圖示出來(lái)，則包的名字可以寫在大長(zhǎng)方形內(nèi)，否則包的名字寫在小長(zhǎng)方形內(nèi)，如圖11.4所示。圖11.4包的圖示如果兩個(gè)包中的任意兩個(gè)類之間存在依賴關(guān)系，則這兩個(gè)包之間也就存在依賴關(guān)系。包的依賴具有一個(gè)重要的特性，即不傳遞性。例如，若包C依賴于包B，包B依賴于包A，則包C不依賴于包A，因?yàn)榘麬中的類的改變只直接影響到包B中的相應(yīng)類，只要包B中被包C引用的類的接口不發(fā)生變化，包C就不會(huì)因包A的變化而受到影響。

層次結(jié)構(gòu)的這種非傳遞特性正是人們經(jīng)常采用層次結(jié)構(gòu)的原因之一。顯然，如果依賴關(guān)系具有傳遞性，則當(dāng)?shù)讓影恍薷暮?，其可能波及的范圍?huì)非常之大，從而使修改的范圍變得難以控制。減小包與外界接口的一種方法是將包中與外界有聯(lián)系的操作都抽取出來(lái)，組成一個(gè)小子集，對(duì)外只提供這個(gè)小子集。包的可見性限定了包中某些類只對(duì)本包中的類可見；同時(shí)，在包中可加入一些額外的公有類來(lái)表示包的公有行為。

包的概念本身對(duì)于減少依賴關(guān)系并沒有必然的幫助。但是，利用這種機(jī)制有助于更方便地發(fā)現(xiàn)在何處存在依賴，從而有助于通過(guò)適當(dāng)?shù)姆纸M、打包等手段來(lái)減少依賴關(guān)系。此外，包還是保持系統(tǒng)整體結(jié)構(gòu)簡(jiǎn)明、清晰的重要工具。對(duì)于一個(gè)已經(jīng)存在的系統(tǒng)，通過(guò)查看包中的類就可以推斷出包之間的依賴關(guān)系。包圖是一個(gè)很有用的工具，特別是對(duì)于改進(jìn)系統(tǒng)的結(jié)構(gòu)非常有幫助。改進(jìn)系統(tǒng)結(jié)構(gòu)的基本步聚是：先將類劃分成一些包并分析包的依賴關(guān)系，然后減少這些依賴關(guān)系。

11.4UML的動(dòng)態(tài)建模機(jī)制

11.4.1協(xié)作圖

協(xié)作圖(CollaborationDiagram)是動(dòng)態(tài)視圖的另一種表現(xiàn)形式，它強(qiáng)調(diào)參加交互的各對(duì)象的組織。協(xié)作圖只對(duì)相互間有交互作用的對(duì)象和這些對(duì)象間的關(guān)系建模，而忽略了其他對(duì)象和關(guān)聯(lián)。

協(xié)作圖可以被視為對(duì)象圖的擴(kuò)展，但它除了顯示對(duì)象間的關(guān)聯(lián)外，還顯示對(duì)象間的消息傳遞。

協(xié)作圖包含以下三個(gè)元素：

(1)對(duì)象(Object)。協(xié)作圖中的對(duì)象與時(shí)序圖中的概念是一樣的，但是在協(xié)作圖中，無(wú)法表示對(duì)象的創(chuàng)建和撤銷，所以對(duì)于對(duì)象在圖中的位置沒有限制。在協(xié)作圖中用矩形表示對(duì)象，內(nèi)部是對(duì)象的名字。

(2)鏈(Link)。協(xié)作圖中的鏈和對(duì)象圖中的鏈所用的符號(hào)是一樣的，即一條連接兩個(gè)類角色的實(shí)線。

(3)消息(Message)。協(xié)作圖中的消息類型與時(shí)序圖中的相同，但是為了說(shuō)明交互過(guò)程中消息的時(shí)間順序，可以在消息上添加順序號(hào)，也可以添加箭頭表示接收消息的對(duì)象。UML中的協(xié)作圖如圖11.5所示。圖11.5協(xié)作圖11.4.2時(shí)序圖

時(shí)序圖(SequenceDiagram)描述了對(duì)象之間傳遞消息的時(shí)間順序，用來(lái)表示用例中的行為順序，是強(qiáng)調(diào)消息時(shí)間順序的交互圖。

時(shí)序圖包含以下四種元素：

(1)對(duì)象(Object)。對(duì)象代表時(shí)序圖中的對(duì)象在交互中扮演的角色。將對(duì)象置于時(shí)序圖的頂部意味著在交互開始時(shí)對(duì)象就已經(jīng)存在了。如果對(duì)象的位置不在頂部，那么表示對(duì)象是在交互的過(guò)程中被創(chuàng)建的。

(2)生命線(Lifeline)。生命線代表時(shí)序圖中的對(duì)象在一段時(shí)期內(nèi)的存在。每個(gè)對(duì)象底部都有一條垂直的虛線，用于表示該對(duì)象的生命線。

(3)激活(Activation)。激活代表時(shí)序圖中的對(duì)象執(zhí)行一次操作的時(shí)期。每條生命線上的窄條矩形表示活動(dòng)期。

(4)消息(Message)。消息用于表示對(duì)象之間交換信息的類。

UML中的時(shí)序圖如圖11.6所示。圖11.6時(shí)序圖11.4.3活動(dòng)圖

活動(dòng)圖(ActivityDiagram)是一種描述系統(tǒng)行為的圖，它用于展現(xiàn)參與行為的類所進(jìn)行的各種活動(dòng)的順序關(guān)系，類似于程序流程圖。

活動(dòng)圖包括如下七種元素：

(1)動(dòng)作狀態(tài)(ActionState)。對(duì)象的動(dòng)作狀態(tài)是活動(dòng)圖的最小單位的構(gòu)成塊，表示原子動(dòng)作。動(dòng)作狀態(tài)使用平滑的圓角矩形表示，動(dòng)作狀態(tài)所表示的動(dòng)作寫在圓角矩形內(nèi)部。

(2)活動(dòng)狀態(tài)(ActivityState)。對(duì)象的活動(dòng)狀態(tài)可以被理解成一個(gè)組合，它的控制流由其他活動(dòng)狀態(tài)或動(dòng)作狀態(tài)組成?；顒?dòng)狀態(tài)的表示圖標(biāo)也是平滑的圓角矩形，并可以在圖標(biāo)中給出入口動(dòng)作和出口動(dòng)作等信息。

(3)動(dòng)作流(ActionFlow)。所有動(dòng)作狀態(tài)之間的轉(zhuǎn)換流都稱為動(dòng)作流。與狀態(tài)圖的轉(zhuǎn)換相同，活動(dòng)圖的轉(zhuǎn)換也用帶箭頭的直線表示，箭頭的方向指向轉(zhuǎn)入的方向。

(4)分支(Branch)與合并(Merge)。分支與合并描述了對(duì)象在不同的判斷結(jié)果下所執(zhí)行的不同動(dòng)作。在活動(dòng)圖中分支與合并用小空心菱形表示。

(5)分叉(Fork)與匯合(Join)。分叉用于將動(dòng)作流分成兩個(gè)或者多個(gè)并發(fā)運(yùn)行的分支；而匯合則用于同步這些并發(fā)分支，以達(dá)到共同完成一項(xiàng)事務(wù)的目的。分叉和匯合都使用加粗的水平線段表示。

(6)泳道(Swimlane)。泳道將活動(dòng)圖中的活動(dòng)劃分為若干組，并把每一組指定給負(fù)責(zé)這組活動(dòng)的業(yè)務(wù)組織，即對(duì)象。泳道區(qū)分了負(fù)責(zé)活動(dòng)的對(duì)象，明確地表示了哪些活動(dòng)是由哪些對(duì)象進(jìn)行的。每個(gè)活動(dòng)只能明確地屬于一個(gè)泳道。泳道用垂直實(shí)線繪出，垂直線分隔的區(qū)域就是泳道。

(7)對(duì)象流(ObjectFlow)。對(duì)象流表示動(dòng)作狀態(tài)或者活動(dòng)狀態(tài)與對(duì)象之間的依賴關(guān)系，即表示動(dòng)作使用對(duì)象或者動(dòng)作對(duì)對(duì)象的影響。對(duì)象流用帶有箭頭的虛線表示。如果箭頭從動(dòng)作狀態(tài)出發(fā)指向?qū)ο?，則表示動(dòng)作對(duì)對(duì)象施加了一定的影響。如果箭頭從對(duì)象指向動(dòng)作狀態(tài)，則表示該動(dòng)作使用對(duì)象流所指向的對(duì)象。

活動(dòng)圖與狀態(tài)圖的區(qū)別是活動(dòng)圖著重表現(xiàn)從一個(gè)活動(dòng)到另一個(gè)活動(dòng)的控制流，是內(nèi)部處理驅(qū)動(dòng)的流程；狀態(tài)圖著重描述從一個(gè)狀態(tài)到另一個(gè)狀態(tài)的流程，主要有外部事件的參與。UML中的活動(dòng)圖如圖11.7所示。圖11.7活動(dòng)圖11.4.4狀態(tài)圖

狀態(tài)機(jī)(StateDiagram)是展示狀態(tài)與狀態(tài)轉(zhuǎn)換的圖，它包含了一個(gè)類的對(duì)象在其生命期間所有狀態(tài)的序列以及對(duì)象對(duì)接收到的事件所產(chǎn)生的反應(yīng)，利用狀態(tài)機(jī)可以精確地描述對(duì)象的行為。

一個(gè)狀態(tài)圖就是一個(gè)狀態(tài)機(jī)，它表現(xiàn)為從一個(gè)狀態(tài)到另一個(gè)狀態(tài)的控制流。狀態(tài)圖可由表示狀態(tài)的結(jié)點(diǎn)和表示狀態(tài)之間轉(zhuǎn)換的帶箭頭的直線組成。圖11.8狀態(tài)圖狀態(tài)圖包括如下一些元素：

(1)狀態(tài)(State)。

(2)轉(zhuǎn)換(Transition)。

(3)初始狀態(tài)(StartState)。

(4)終結(jié)狀態(tài)(EndState)。

(5)判定(Decision)。

UML中的狀態(tài)圖如圖11.8所示。 11.5UML面向?qū)崿F(xiàn)機(jī)制

11.5.1組件圖

組件圖描述了軟件的各種組件和它們之間的依賴關(guān)系。每一個(gè)組件圖只描述系統(tǒng)實(shí)現(xiàn)中的某一方面，是系統(tǒng)的代碼物理模塊。當(dāng)系統(tǒng)中的所有組件結(jié)合起來(lái)后，就可以完整地表示整個(gè)系統(tǒng)的實(shí)現(xiàn)視圖。

組件圖中通常包含三個(gè)元素：組件(Component)、接口(Interface)和依賴關(guān)系(Dependency)。

UML中的組件圖如圖11.9所示。圖11.9組件圖

(1)組件。組件是定義了良好接口的物理實(shí)現(xiàn)單元，是系統(tǒng)中可替換的物理部件。組件可以是源代碼組件、二進(jìn)制組件或一個(gè)可執(zhí)行的組件。在UML中，組件用一個(gè)左側(cè)帶有兩個(gè)突出小矩形的矩形來(lái)表示。

(2)接口。接口是一個(gè)類提供給另一個(gè)類的一組操作。組件可以通過(guò)其他組件的接口來(lái)使用那些組件中定義的一些操作。組件的接口分為兩種：

①導(dǎo)入接口(importinterface)：提供給訪問操作的組件使用。

②導(dǎo)出接口(exportinterface)：由提供操作的組件提供。

接口和組件之間的關(guān)系分為兩種：

①實(shí)現(xiàn)關(guān)系(Realization)：接口和組件之間用實(shí)線連接。

②依賴關(guān)系(Dependency)：接口和組件之間用虛線箭頭連接。

(3)依賴關(guān)系。依賴關(guān)系表示組件圖中各組件之間存在的關(guān)系類型。

UML的組件圖中依賴關(guān)系的表示方法與類圖中依賴關(guān)系的表示方法相同，都用一個(gè)由客戶指向提供者的虛線箭頭表示。組件圖的依賴關(guān)系如圖11.10所示。圖11.10組件圖的依賴關(guān)系11.5.2配置圖

配置圖描述了運(yùn)行軟件的系統(tǒng)中硬件和軟件的物理結(jié)構(gòu)。

配置圖中包含兩個(gè)元素：結(jié)點(diǎn)(node)和關(guān)聯(lián)關(guān)系(association)。

配置圖可以顯示結(jié)點(diǎn)以及結(jié)點(diǎn)之間的必要連接，也可以顯示這些連接的類型，還可以顯示組件和組件之間的依賴關(guān)系，但是每個(gè)組件必須存在于某些結(jié)點(diǎn)上。UML中的配置圖如圖11.11所示。圖11.11配置圖

(1)結(jié)點(diǎn)表示在運(yùn)行時(shí)代表計(jì)算資源的物理元素。結(jié)點(diǎn)通常擁有一些內(nèi)存，并具有處理能力(例如處理器、設(shè)備)，在UML中用一個(gè)立方體來(lái)表示。

(2)關(guān)聯(lián)關(guān)系表示各結(jié)點(diǎn)之間的通信路徑，在UML中用一條實(shí)線來(lái)表示。 11.6UML建模工具

11.6.1RationalRose

RationalRose是由美國(guó)Rational公司開發(fā)的一種面向?qū)ο蟮慕y(tǒng)一建模語(yǔ)言的可視化建模工具。利用該工具可以建立用UML描述的軟件系統(tǒng)模型，而且可以自動(dòng)生成和維護(hù)

C++、Java、VB和Oracle等語(yǔ)言和系統(tǒng)的代碼。RationalRose包括了統(tǒng)一建模語(yǔ)言(UML)、面向?qū)ο蟮能浖こ?OOSE)以及對(duì)象建模技術(shù)(OMT)。其中，統(tǒng)一建模語(yǔ)言是由UML業(yè)內(nèi)的三位創(chuàng)始人、面向?qū)ο箢I(lǐng)域的大師級(jí)人物——Booch、Rumbaugh和Jacobson通過(guò)對(duì)早期面向?qū)ο蠹夹g(shù)的研究而創(chuàng)建的，而這三位大師都曾經(jīng)在Rational公司擔(dān)任首席工程師。2002年，Rational軟件公司被IBM公司收購(gòu)，現(xiàn)已成為IBM的第五大品牌。

RationalRose在建模方面具有如下一些特性：

(1)保證模型和代碼的高度一致，實(shí)現(xiàn)真正意義上的雙向工程。

(2)支持多種語(yǔ)言，例如C++、VB、VC++、Java、PB等。

(3)為團(tuán)隊(duì)開發(fā)提供了強(qiáng)有力的支持，提供了SCM軟件配置管理功能。

(4)支持模型的Internet發(fā)布，提供了基于HTML版本的發(fā)布功能。

(5)生成使用簡(jiǎn)單且定制靈活的文檔。

(6)支持常用關(guān)系型數(shù)據(jù)庫(kù)的無(wú)縫連接建模。11.6.2MicrosoftOfficeVisio

MicrosoftOfficeVisio是微軟公司開發(fā)的產(chǎn)品。它能夠很好地幫助IT和商務(wù)專業(yè)人員輕松地可視化、分析和交流復(fù)雜信息。它能夠?qū)㈦y以理解的復(fù)雜文本和表格轉(zhuǎn)換為一目了然的Visio圖表。該軟件通過(guò)創(chuàng)建與數(shù)據(jù)相關(guān)的Visio圖表(而不使用靜態(tài)圖片)來(lái)顯示數(shù)據(jù)，這些圖表易于刷新，并能夠顯著提高生產(chǎn)率。

目前OfficeVisio2007有兩種獨(dú)立版本：OfficeVisioProfessional2007和OfficeVisioStandard2007。OfficeVisioStandard2007與OfficeVisioProfessional2007的基本功能相同，但前者包含的功能和模板是后者的子集。OfficeVisioProfessional2007提供了數(shù)據(jù)連接性和可視化功能等高級(jí)功能，而OfficeVisioStandard2007并沒有這些功能?！癠ML模型圖模板”是MicrosoftOfficeVisio中提供的一個(gè)輕量級(jí)的建模工具之一，它能夠?yàn)閯?chuàng)建復(fù)雜軟件系統(tǒng)的面向?qū)ο蟮哪Ｐ?建模系統(tǒng)的一種抽象表示，它從特定的視角并在某一抽象級(jí)別上指定建模系統(tǒng))提供全面的支持。該模板包括下列工具、形狀和功能：

(1)“UML模型資源管理器”，它提供模型的樹視圖(顯示于UML導(dǎo)航器窗口中的一種層次結(jié)構(gòu)，其中的每個(gè)UML元素或視圖(圖表)都用圖標(biāo)表示。UML模板自動(dòng)創(chuàng)建模型的樹視圖)和在視圖間進(jìn)行瀏覽的手段。

(2)預(yù)定義的智能形狀，這些形狀表示UML標(biāo)注中的元素并支持UML圖類型的創(chuàng)建。通過(guò)對(duì)這些形狀進(jìn)行編程，使其行為方式同UML語(yǔ)義相符。

(3)易于訪問“UML屬性”對(duì)話框，可通過(guò)這些對(duì)話框?qū)⒚Q、特性、操作和其他屬性添加到UML元素。

(4)動(dòng)態(tài)語(yǔ)義錯(cuò)誤檢查，用于標(biāo)識(shí)和診斷錯(cuò)誤，例如缺少數(shù)據(jù)或錯(cuò)誤地使用了UML表示法。

(5)對(duì)用MicrosoftVisualC++6.0或MicrosoftVisualBasic6.0創(chuàng)建的項(xiàng)目進(jìn)行反向工程，以生成UML靜態(tài)結(jié)構(gòu)模型。

(6)對(duì)用MicrosoftVisualStudio.NET創(chuàng)建的項(xiàng)目進(jìn)行反向工程并生成UML靜態(tài)結(jié)構(gòu)模型。

(7)根據(jù)UML模型中的類定義將代碼框架生成到C++、VisualC#或MicrosoftVisualBasic中。

(8)標(biāo)識(shí)特定語(yǔ)言錯(cuò)誤的代碼檢查實(shí)用程序，該實(shí)用程序可以避免代碼被指定的目標(biāo)語(yǔ)言(為生成代碼而指定)編譯。

(9)創(chuàng)建用于UML靜態(tài)結(jié)構(gòu)、活動(dòng)、狀態(tài)圖、組件和配置圖的報(bào)告。

當(dāng)前市場(chǎng)上基于UML可視化建模的工具很多，例如RationalRose、MicrosoftVisio、OracleDesigner，還有PlayCase、CABPWin、CAERWin、SybasePowerDesigner等。 11.7UML建模實(shí)例

建模實(shí)例：ATM(自動(dòng)柜員機(jī))系統(tǒng)。

1．系統(tǒng)用例圖

對(duì)于銀行的客戶來(lái)說(shuō)，他們可以通過(guò)ATM機(jī)啟動(dòng)幾個(gè)用例：存款、取款、查閱結(jié)余、付款、轉(zhuǎn)賬和改變PIN(密碼)，如圖11.12所示。銀行官員也可以啟動(dòng)改變PIN這個(gè)用例。參與者可能是一個(gè)系統(tǒng)，這里的信用系統(tǒng)就是一個(gè)參與者，因?yàn)樗窃贏TM系統(tǒng)之外的。箭頭從用例到參與者表示用例產(chǎn)生了一些參與者要使用的信息。這里，付款用例向信用系統(tǒng)提供信用卡付款信息。圖11.12系統(tǒng)用例圖

2．“客戶插入卡”的活動(dòng)圖

客戶插入信用卡之后，可以看到ATM系統(tǒng)運(yùn)行了三個(gè)并發(fā)的活動(dòng)：驗(yàn)證卡、驗(yàn)證PIN

(密碼)和驗(yàn)證余額。這三個(gè)驗(yàn)證都結(jié)束之后，ATM系統(tǒng)根據(jù)這三個(gè)驗(yàn)證的結(jié)果來(lái)執(zhí)行下

一步的活動(dòng)。如果卡正常、密碼正確且通過(guò)余額驗(yàn)證，則ATM系統(tǒng)接下來(lái)會(huì)詢問客戶有哪

些要求，也就是要執(zhí)行什么操作。如果驗(yàn)證卡、驗(yàn)證PIN(密碼)和驗(yàn)證余額這三個(gè)驗(yàn)證有任何一個(gè)通不過(guò)的話，ATM系統(tǒng)就把相應(yīng)的出錯(cuò)信息在ATM屏幕上顯示給客戶，如圖11.13所示。圖11.13“客戶插入卡”的活動(dòng)圖

3．取款用例的類圖

如圖11.14所示，取款用例的類圖顯示了取款這個(gè)用例中各個(gè)類之間的關(guān)系。有四個(gè)類：讀卡機(jī)、賬目、ATM屏幕和取錢機(jī)。類圖中的每個(gè)類都是用方框表示的，分成三個(gè)部分：第一部分是類名；第二部分是類包含的屬性，如賬目類包含了三個(gè)屬性，即賬號(hào)、PIN(密碼)和結(jié)余；第三部分包含類的方法(方法是類提供的一些功能)，例如賬目類包含了四個(gè)方法，即打開、取錢、扣錢和驗(yàn)錢數(shù)。圖11.14取款用例的類圖

4．交互圖

(1)某客戶Joe取20美元的序列圖如圖11.15所示。序列圖顯示了用例中的功能流程。這里我們對(duì)取款這個(gè)用例進(jìn)行分析。它有很多可能的程序，如想取錢而沒錢，想取錢而PIN錯(cuò)等，正常的情況是取到了錢。圖11.15某客戶Joe取20美元的序列圖序列圖的頂部一般先放置的是取款這個(gè)用例涉及的參與者，然后放置系統(tǒng)完成取款用例所需的對(duì)象，每個(gè)箭頭表示參與者和對(duì)象或?qū)ο笾g為了完成特定功能而要傳遞的消息。

(2)某客戶Joe取20美元的協(xié)作圖如圖11.16所示。協(xié)作圖顯示的信息和序列圖是相同的，只是顯示的方式不同而已。序列圖顯示的是對(duì)象和參與者隨時(shí)間變化的交互，而協(xié)作圖則不參照時(shí)間來(lái)顯示對(duì)象與參與者的交互。

例如，從圖11.16中我們可以看到，讀卡機(jī)和賬目?jī)蓚€(gè)對(duì)象之間的交互：讀卡機(jī)指示賬目打開，賬目讓讀卡機(jī)退卡。直接相互通信的對(duì)象之間有一條直線，例如ATM屏幕和讀卡機(jī)直接相互通信，則其間畫一條直線。沒有畫直線的對(duì)象之間不直接通信。圖11.16某客戶Joe取20美元的協(xié)作圖

5．賬目類的狀態(tài)圖

銀行賬目可能有幾種不同的狀態(tài)，可以打開、關(guān)閉或透支。賬目在不同狀態(tài)下的功能是不同的，賬目可以從一種狀態(tài)轉(zhuǎn)變到另一種狀態(tài)。例如，賬目打開而客戶請(qǐng)求關(guān)閉賬目時(shí)，賬目轉(zhuǎn)入關(guān)閉狀態(tài)?？蛻粽?qǐng)求是事件，事件導(dǎo)致賬目從一個(gè)狀態(tài)過(guò)渡到另一個(gè)狀態(tài)，如圖11.17所示。圖11.17賬目類的狀態(tài)圖如果賬目打開而客戶要取錢，則賬目可能轉(zhuǎn)入透支狀態(tài)。這發(fā)生在賬目結(jié)余小于0時(shí)，圖11.17中顯示為[結(jié)余小于0]。方括號(hào)中的條件稱為保證條件，用于控制狀態(tài)的過(guò)渡能不能發(fā)生。

對(duì)象處在特定狀態(tài)時(shí)可能會(huì)發(fā)生某種事件，例如賬目透支時(shí)要通知客戶。 11.8實(shí)戰(zhàn)訓(xùn)練

1．目的

UML作為軟件工程中的建模語(yǔ)言，代表了面向?qū)ο蠓椒ǖ能浖_發(fā)技術(shù)的發(fā)展方向。本實(shí)戰(zhàn)訓(xùn)練通過(guò)對(duì)“圖書管理系統(tǒng)”從系統(tǒng)需求分析到系統(tǒng)配置與實(shí)現(xiàn)的全過(guò)程建模，使讀者能夠較深入