標(biāo)準(zhǔn)建模語言UML及其支持環(huán)境

標(biāo)準(zhǔn)建模語言UML及其支持環(huán)境(一)

編者按：

軟件工程領(lǐng)域在1995年至1997年取得了前所未有的進(jìn)展,其成果超過軟件工程

領(lǐng)域過去15年來的成就總和。其中最重要的、具有劃時(shí)代重大意義的成果之一

就是統(tǒng)一建模語言(UML:lhifiedModelingLanguage)的出現(xiàn)。在世界范圍內(nèi)，至少

在近10年內(nèi),UML將是面向?qū)ο蠹夹g(shù)領(lǐng)域內(nèi)占主導(dǎo)地位的標(biāo)準(zhǔn)建模語言。采用

UML作為我國統(tǒng)一的建模語言是完全必要的:首先，過去數(shù)十種面向?qū)ο蟮慕ＵZ

言都是相互獨(dú)立的，而UML可以消除些潛在的不必要的差異以免用戶混淆;其

次通過統(tǒng)一語義和符號(hào)表示，能夠穩(wěn)定我國的面向?qū)ο蠹夹g(shù)市場,使項(xiàng)目根植于

一個(gè)成熟的標(biāo)準(zhǔn)建模語言從而可以大大拓寬所研制與開發(fā)的軟件系統(tǒng)的適用范

圍，并大大提高其靈活程度。為使讀者對UML語言及其支持環(huán)境有更深入、細(xì)致

的了解我們特邀北京航空航天大學(xué)軟件工程研究所的專家撰文介紹，本文共分五

個(gè)部分：

一、標(biāo)準(zhǔn)建模語言UML的概念作者張莉周伯莊

二、標(biāo)準(zhǔn)建模語言UML的靜態(tài)建模機(jī)制作者葛科楊順祥

三、標(biāo)準(zhǔn)建模語言UML的動(dòng)態(tài)建模機(jī)制作者王云葛科

四、標(biāo)準(zhǔn)建模語言HMI支持環(huán)境作者周伯生張莉

五、標(biāo)準(zhǔn)建模語言UML的應(yīng)用實(shí)例作者楊順祥王云

我們將以連載的形式分7次對上述內(nèi)容進(jìn)行介紹。

一、標(biāo)準(zhǔn)建模語言UML概述

面向?qū)ο蟮姆治雠c設(shè)計(jì)(OOA&D)方法的發(fā)展在80年代末至90年代中出現(xiàn)了一

個(gè)高潮,UML是這個(gè)高潮的產(chǎn)物。它不僅統(tǒng)一了Booch、Rumbaugh^0Jacobson

的表示方法,而且對其作了進(jìn)一步的發(fā)展，并最終統(tǒng)一為大眾所接受的標(biāo)準(zhǔn)建模語

言。

L標(biāo)準(zhǔn)建模語言UML的出現(xiàn)

公認(rèn)的面向?qū)ο蠼ＵZ言出現(xiàn)于70年代中期。從1989年到1994年，其數(shù)量從不

到十種增加到了五十多種。在眾多的建模語言中，語言的創(chuàng)造者努力推崇自己的

產(chǎn)品，并在實(shí)踐中不斷完善。但是Q0方法的用戶并不了解不同建模語言的優(yōu)缺

點(diǎn)及相互之間的差異，因而很難根據(jù)應(yīng)用特點(diǎn)選擇合適的建模語言,于是爆發(fā)了一

場“方法大戰(zhàn)90年代中，一批新方法出現(xiàn)了，箕中最引人注目的是Booch1993.

OOSE和OMT-2等。

Booch是面向?qū)ο蠓椒ㄗ钤绲某珜?dǎo)者之一，他提出了面向?qū)ο筌浖こ痰母拍睢?/p>

1991年他將以前面向Ada的工作擴(kuò)展到整個(gè)面向?qū)ο笤O(shè)計(jì)領(lǐng)域。Booch1993

比較適合十系統(tǒng)的設(shè)計(jì)和構(gòu)造。Rumbaugh等人提出了面向?qū)ο蟮慕＜夹g(shù)

(OMT)方法，采用了面向?qū)ο蟮母拍?并引入各種獨(dú)立于語言的表示符。這種方法

用對象模型、動(dòng)態(tài)模型、功能模型和用例模型，共同完成對整個(gè)系統(tǒng)的建模，所定

義的概念和符號(hào)可用于軟件開發(fā)的分析、設(shè)計(jì)和實(shí)現(xiàn)的全過程，軟件開發(fā)人員不

必在開發(fā)過程的不同階段進(jìn)行概念和符號(hào)的轉(zhuǎn)換。0MT-2特別適用于分析和描

述以數(shù)據(jù)為中心的信息系統(tǒng)。Jacobson于1994年提出了OOSE方法，其最大特點(diǎn)

是面向用例(Use-Case),并在用例的描述中引入了外部角色的概念。用例的概念是

精確描述需求的重要武器但用例貫穿于整個(gè)開發(fā)過程，包括對系統(tǒng)的測試和驗(yàn)

證。OOSE比較適合支持商業(yè)工程和需求分析。此外，還有Coad/Yourdon方法，

即著名的OOA/OOD,它是最早的面向?qū)ο蟮姆治龊驮O(shè)計(jì)方法之一。該方法簡單、

易學(xué),適合于面向?qū)ο蠹夹g(shù)的初學(xué)者使用，但由于該方法在處理能力方面的局限，

目前已很少使用。

概括起來，首先，面對眾多的建模語言,用戶由于沒有能力區(qū)別不同語言之間的差

別,因此很難找到一種比較適合其應(yīng)用特點(diǎn)的語言;其次，眾多的建模語言實(shí)際上

各有千秋;第三，雖然不同的建模語言大多類同，但仍存在某些細(xì)微的差別，極大地

妨礙了用戶之間的交流。因此在客觀上，極有必要在精心比較不同的建模語言優(yōu)

缺點(diǎn)及總結(jié)面向?qū)ο蠹夹g(shù)應(yīng)用實(shí)踐的基礎(chǔ)上，組織聯(lián)合設(shè)計(jì)小組，根據(jù)應(yīng)用需求，

取其精華，去其糟粕，求同存異，統(tǒng)一建模語言。

1994年10月,GradyBooch和JimRumbaugh開始致力于這一工作。他們首先將

Booch93和OMT-2統(tǒng)一起來，并于1995年10月發(fā)布了第一個(gè)公開版本,稱之為

統(tǒng)一方法UM0.8(UnitiedMethod)。1995年秋,OOSE的創(chuàng)始人IvarJacobson加

盟到這一工作。經(jīng)過BoochxRumbaugh和Jacobson三人的共同努力，于1996

年6月和10月分別發(fā)布了兩個(gè)新的版本，即UML0.9和UML0.91,并將UM重新

命名為UML(UnifiedModelingLanguage)。1996年，一些機(jī)構(gòu)將UML作為其商業(yè)

策略已tl趨明顯。UML的開發(fā)者得到了來自公眾的正面反應(yīng),并倡議成立了UML

成員協(xié)會(huì),以完善、加強(qiáng)和促進(jìn)UML的定義工作。當(dāng)時(shí)的成員有DECsHPJ-Logix.

Itellicorp^IBM、ICONComputingsMCISystemhouse、Mierosoft^Oracle、

RationalSoftwaresTl以及Unisys0這一機(jī)構(gòu)對UML1.3(1997年1月)及UML

1.1(1997年11月17日)的定義和發(fā)布起了重要的促進(jìn)作用。

UML是一種定義良好、易于表達(dá)、功能強(qiáng)大且普遍適用的建模語言。它溶

入了軟件工程領(lǐng)域的新思想、新方法和新技術(shù)。它的作用域不限于支持面向?qū)ο?/p>

的分析與設(shè)計(jì)，還支持從需求分析開始的軟件開發(fā)的全過程。

0

圖1UML的發(fā)展歷程

面向?qū)ο蠹夹g(shù)和UML的發(fā)展過程可用上圖來表示，標(biāo)準(zhǔn)建模語言的出現(xiàn)是其重要

成果。在美國，截止1996年10月,UML獲得了工業(yè)界、科技界和應(yīng)用界的廣泛支

持，已有700多個(gè)公司表示支持采用UML作為建模語言。1996年底,UML已穩(wěn)占

面向?qū)ο蠹夹g(shù)市場的85%,成為可視化建模語言事實(shí)上的工業(yè)標(biāo)準(zhǔn)。1997年11月

17日QMG采納UML1.1作為基于面向?qū)ο蠹夹g(shù)的標(biāo)準(zhǔn)建模語言。UML代表了

面向?qū)ο蠓椒ǖ能浖_發(fā)技術(shù)的發(fā)展方向，具有巨大的市場前景，也具有重大的經(jīng)

濟(jì)價(jià)值和國防價(jià)值。

2.標(biāo)準(zhǔn)建模語言UML的內(nèi)容

首先,UML融合了Booch.OMT和OOSE方法中的基本概念，而且這些基本概

念與其他面向?qū)ο蠹夹g(shù)中的基本概念大多相同,因而,UML必然成為這些方法以及

其他方法的使用者樂于采用的一種簡單一致的建模語言;其次,UML不僅僅是上述

方法的簡單匯合，而是在這些方法的基礎(chǔ)上廣泛征求意見集眾家之長，幾經(jīng)修改

而完成的,UML擴(kuò)展了現(xiàn)有方法的應(yīng)用范圍;第三,UML是標(biāo)準(zhǔn)的建模語言,而不是

標(biāo)準(zhǔn)的開發(fā)過程。盡管UML的應(yīng)用必然以系統(tǒng)的開發(fā)過程為背景,但由于不同的

組織和不同的應(yīng)用領(lǐng)域,需要采取不同的開發(fā)過程。

作為一種建模語言,UML的定義包括UML語義和UML表示法兩個(gè)部分

O

⑴UML語義描述基于UML的精確元模型定義。元模型為UML的所有元素在

語法和語義上提供了簡單、一致、通用的定義性說明，使開發(fā)者能在語義上取得

一致,消除了因人而異的最佳表達(dá)方法所造成的影響。此外UML還支持對元模型

的擴(kuò)展定義。

⑵UML表示法定義UML符號(hào)的表示法，為開發(fā)者或升發(fā)工具使用這些圖形符

號(hào)和文本語法為系統(tǒng)建模提供了標(biāo)準(zhǔn)。這些圖形符號(hào)和文字所表達(dá)的是應(yīng)用級(jí)的

模型,在語義上它是UML元模型的實(shí)例。

標(biāo)準(zhǔn)建模語言UML的重要內(nèi)容可以由下列五類圖(共9種圖形)來定義：

?第一類是用例圖，從用戶角度描述系統(tǒng)功能，并指出各功能的操作者。

第二類是靜態(tài)圖(Staticdi為ram),包括類圖、對象圖和包圖。其中類圖描述系統(tǒng)

中類的靜態(tài)結(jié)構(gòu)。不僅定義系統(tǒng)中的類，表示類之間的聯(lián)系如關(guān)聯(lián)、依賴、聚合

等,也包括類的內(nèi)部結(jié)構(gòu)(類的屬性和操作)。類圖描述的是一種靜態(tài)關(guān)系，在系統(tǒng)的

整個(gè)生命周期都是有效的。對象圖是類圖的實(shí)例，幾乎使用與類圖完全相同的標(biāo)

識(shí)。他們的不同點(diǎn)在于對象圖顯示類的多個(gè)對象實(shí)例而不是實(shí)際的類。一個(gè)對

象圖是類圖的一個(gè)實(shí)例。由于對象存在生命周期，因此對象圖只能在系統(tǒng)某一時(shí)

間段存在。包由包或類組成表示包與包之間的關(guān)系。包圖用于描述系統(tǒng)的分層

結(jié)構(gòu)。

?第三類是行為圖(Behaviordiagram),描述系統(tǒng)的動(dòng)態(tài)模型和組成對象間的交互關(guān)

系。其中狀態(tài)圖描述類的對象所有可能的狀態(tài)以及事件發(fā)生時(shí)狀態(tài)的轉(zhuǎn)移條件。

通常，狀態(tài)圖是對類圖的補(bǔ)充。在實(shí)用上并不需要為所有的類畫狀態(tài)圖，僅為那些

有多個(gè)狀態(tài)其行為受外界環(huán)境的影響并且發(fā)生改變的類畫狀態(tài)圖。而活動(dòng)圖描述

滿足用例要求所要進(jìn)行的活動(dòng)以及活動(dòng)間的約束關(guān)系，有利于識(shí)別并行活動(dòng)。

?第四類是交互圖(Interactivediagram),描述對象間的交互關(guān)系。其中順序圖顯示

對象之間的動(dòng)態(tài)合作關(guān)系，它強(qiáng)調(diào)對象之間消息發(fā)送的順序，同時(shí)顯示對象之間的

交互;合作圖描述對象間的協(xié)作關(guān)系，合作圖跟順序圖相似,顯示對象間的動(dòng)態(tài)合

作關(guān)系。除顯示信息交換外,合作圖還顯示對象以及它們之間的關(guān)系。如果強(qiáng)調(diào)

時(shí)間和順序廁使用順序圖如果強(qiáng)調(diào)上下級(jí)關(guān)系廁選擇合作圖。這兩種圖合稱為

交互圖。

?第五類是實(shí)現(xiàn)圖(Implementationdiagram)。其中構(gòu)件圖描述代碼部件的物理結(jié)

構(gòu)及各部件之間的依賴關(guān)系。一個(gè)部件可能是一個(gè)資源代碼部件、一個(gè)二進(jìn)制部

件或一個(gè)可執(zhí)行部件。它包含邏輯類或?qū)崿F(xiàn)類的有關(guān)信息。部件圖有助于分析和

理解部件之間的相互影響程度。

配置圖定義系統(tǒng)中軟硬件的物理體系結(jié)構(gòu)。它可以顯示實(shí)際的計(jì)算機(jī)和設(shè)備(用

節(jié)點(diǎn)表示)以及它們之間的連接關(guān)系，也可顯示連接的類型及部件之間的依賴性。

在節(jié)點(diǎn)內(nèi)部，放置可執(zhí)行部件和對象以顯示節(jié)點(diǎn)跟可執(zhí)行軟件單元的對應(yīng)關(guān)系。

從應(yīng)用的角度看，當(dāng)采用面向?qū)ο蠹夹g(shù)設(shè)計(jì)系統(tǒng)時(shí)，首先是描述需求淇次根據(jù)需

求建立系統(tǒng)的靜態(tài)模型,以構(gòu)造系統(tǒng)的結(jié)構(gòu);第三步是描述系統(tǒng)的行為。其中在第

一步與第二步中所建立的模型都是靜態(tài)的，包括用例圖、類圖(包含包)、對象圖、

組件圖和配置圖等五個(gè)圖形，是標(biāo)準(zhǔn)建模語言UML的靜態(tài)建模機(jī)制。其中第三步

中所建立的模型或者可以執(zhí)行,或者表示執(zhí)行時(shí)的時(shí)序狀態(tài)或交互關(guān)系。它包括

狀態(tài)圖、活動(dòng)圖、順序圖和合作圖等四個(gè)圖形，是標(biāo)準(zhǔn)建模語言UML的動(dòng)態(tài)建模

機(jī)制。因此,標(biāo)準(zhǔn)建模語言UML的主要內(nèi)容也可以歸納為靜態(tài)建模機(jī)制和動(dòng)態(tài)建

模機(jī)制兩大類。

3.標(biāo)準(zhǔn)建模語言UML的主要特點(diǎn)

標(biāo)準(zhǔn)建模語言UML的主要特點(diǎn)可以歸結(jié)為三點(diǎn)：

⑴UML統(tǒng)一了Booch、OMT和OOSE等方法中的基本概念。

⑵UML還吸取了面向?qū)ο蠹夹g(shù)領(lǐng)域中其他流派的長處,其中也包括非00方法的

影響。UML符號(hào)表示考慮了各種方法的圖形表示,刪掉了大量易引起混亂的、多

余的和極少使用的符號(hào),也添加了一些新符號(hào),因此，在UML中匯入了面向?qū)ο箢I(lǐng)

域中很多人的思想。這些思想并不是UML的開發(fā)者們發(fā)明的，而是開發(fā)者們依據(jù)

最優(yōu)秀的0。方法和豐富的計(jì)算機(jī)科學(xué)實(shí)踐經(jīng)驗(yàn)綜合提煉而成的。

⑶UML在演變過程中還提出了一些新的概念。在UML標(biāo)準(zhǔn)中新加了模板

(Stereotypes)、職責(zé)(Responsibilities)、擴(kuò)展機(jī)制(Extensibilitymechanisms)、線

程(Threads)、過程(Processes)、分布式(Distribution)、并發(fā)(Concurrency)、模式

(Patterns)s合作(Collaborations)、活動(dòng)圖(Activitydiagr3m)等新概念，并清晰地區(qū)

分類型(Type)、類(Class)和實(shí)例(Instance)、細(xì)化(Refinement)、接口(Interfaces)

和組件(Components)等概念。

因此可以認(rèn)為,UML是一種先進(jìn)實(shí)用的標(biāo)準(zhǔn)建模語言,但其中某些概念尚待實(shí)踐來

驗(yàn)證,UML也必然存在一個(gè)進(jìn)化過程(未完待續(xù))。

Home

標(biāo)準(zhǔn)建模語言UML及其支持環(huán)境(二)

北京航空航天大學(xué)軟件工程研究所

(接上期)

4.標(biāo)準(zhǔn)建模語言UML的應(yīng)用領(lǐng)域

UML的目標(biāo)是以面向?qū)ο髨D的方式來描述任何類型的系統(tǒng)，具有很寬的應(yīng)用領(lǐng)

域。其中最常用的是建立軟件系統(tǒng)的模型，但它同樣可以用于描述非軟件領(lǐng)域的

系統(tǒng),如機(jī)械系統(tǒng)、企業(yè)機(jī)構(gòu)或業(yè)務(wù)過程以及處理復(fù)雜數(shù)據(jù)的信息系統(tǒng)、具有實(shí)

時(shí)要求的工業(yè)系統(tǒng)或工業(yè)過程等。總之,UML是一個(gè)通用的標(biāo)準(zhǔn)建模語言，可以對

任何具有靜態(tài)結(jié)構(gòu)和動(dòng)態(tài)行為的系統(tǒng)進(jìn)行建模。此外,UML適用于系統(tǒng)開發(fā)過程

中從需求規(guī)格描述到系統(tǒng)完成后測

試的不同階段。在需求分析階段，可以用用例來捕獲用戶需求。通過用例建模，描

述對系統(tǒng)感興趣的外部角色及其對系統(tǒng)(用例)的功能要求。分析階段主要關(guān)心問

題域中的主要概念(如抽象、類和對象等)和機(jī)制，需要識(shí)別這些類以及它們相互間

的關(guān)系，并用UML類圖來描述。為實(shí)現(xiàn)用例，類之間需要協(xié)作這可以用UML動(dòng)態(tài)

模型來描述。在分析階段，只對問題域的對象(現(xiàn)實(shí)世界的概念)建模,而不考慮定義

軟件系統(tǒng)中技術(shù)細(xì)節(jié)的類(如處理用戶接口、數(shù)據(jù)庫、通訊和并行性等問題的類)。

這些技術(shù)細(xì)節(jié)將在設(shè)計(jì)階段引入，因此設(shè)計(jì)階段為構(gòu)造階段提供更詳細(xì)的規(guī)格說

明。

編程(構(gòu)造)是一個(gè)獨(dú)立的階段,其任務(wù)是用面向?qū)ο缶幊陶Z言將來自設(shè)計(jì)階段的

類轉(zhuǎn)換成實(shí)際的代碼。在用UML建立分析和設(shè)計(jì)模型時(shí)，應(yīng)盡量避免考慮把模型

轉(zhuǎn)換成某種特定的編程語言。因?yàn)樵谠缙陔A段，模型僅僅是理解和分析系統(tǒng)結(jié)構(gòu)

的工具，過早考慮編碼問題十分不利于建立簡單正確的模型。

UML模型還可作為測試階段的依據(jù)。系統(tǒng)通常需要經(jīng)過單元測試、集成測試、

系統(tǒng)測試和驗(yàn)收測試。不同的測試小組使用不同的UML圖作為測試依據(jù):單元測

試使用類圖和類規(guī)格說明;集成測試使用部件圖和合作圖;系統(tǒng)測試使用用例圖來

驗(yàn)證系統(tǒng)的行為;驗(yàn)收測試由用戶進(jìn)行，以驗(yàn)證系統(tǒng)測試的結(jié)果是否滿足在分析階

段確定的需求。

總之,標(biāo)準(zhǔn)建模語言UML適用于以面向?qū)ο蠹夹g(shù)來描述任何類型的系統(tǒng),而且適

用于系統(tǒng)開發(fā)的不同階段從需求規(guī)格描述直至系統(tǒng)完成后的測試和維護(hù)。

二、標(biāo)準(zhǔn)建模語言UML的靜態(tài)建模機(jī)制

任何建模語言都以靜態(tài)建模機(jī)制為基礎(chǔ),標(biāo)準(zhǔn)建模語言UML也不例外。UML

的靜態(tài)建模機(jī)制包括用例圖(Usecasediagram)、類圖(Classdiagram)、對象圖

包、構(gòu)件圖和配置圖

(Objectdiagram)s(Package)(Componentdiagram)

(Deploymentdiagram)。

1.用例圖

(1)用例模型(Usecasemodel)

長期以來，在面向?qū)ο箝_發(fā)和傳統(tǒng)的軟件開發(fā)中，人們根據(jù)典型的使用情景來了解

需求。但是，這些使用情景是非正式的，雖然經(jīng)常使用，卻難以建立正式文擋。用例

模型由IvarJacobson在開發(fā)AXE系統(tǒng)中首先使用,并加入由他所倡導(dǎo)的OOSE和

Objectory方法中。用例方法引起了面向?qū)ο箢I(lǐng)域的極大關(guān)注。自1994年Ivar

Jacobson的著作出版后，面向?qū)ο箢I(lǐng)域已廣泛接納了用例這一概念,并認(rèn)為它是第

二代面向?qū)ο蠹夹g(shù)的標(biāo)志。

用例模型描述的是外部執(zhí)行者(Actor)所理解的系統(tǒng)功能。用例模型用于需求分析

階段，它的建立是系統(tǒng)開發(fā)者和用戶反復(fù)討論的結(jié)果，表用了開發(fā)者和用戶對需求

規(guī)格達(dá)成的共識(shí)。首先，它描述了待開發(fā)系統(tǒng)的功能需求其次,它將系統(tǒng)看作黑盒,

從外部執(zhí)行者的角度來理解系統(tǒng);第三，它驅(qū)動(dòng)了需求分圻之后各階段的開發(fā)工作,

不僅在開發(fā)過程中保證了系統(tǒng)所有功能的實(shí)現(xiàn)，而且被用于驗(yàn)證和檢測所開發(fā)的

系統(tǒng),從而影響到開發(fā)工作的各個(gè)階段和UML的各個(gè)模型。在UML中,一個(gè)用例

模型由若干個(gè)用例圖描述,用例圖主要元素是用例和執(zhí)行者。

(2)用例(usecase)

從本質(zhì)上講，一個(gè)用例是用戶與計(jì)算機(jī)之間的一次典型交互作用。以字處理軟件

為例，”將某些正文置為黑體‘和”創(chuàng)建一個(gè)索弓I”便是兩個(gè)典型的用例。在UML中,

用例被定義成系統(tǒng)執(zhí)行的一系列動(dòng)作,動(dòng)作執(zhí)行的結(jié)果能被指定執(zhí)行者察覺到。

0

圖1用例圖

在UML中,用例表示為一個(gè)橢圓°圖1顯示了一個(gè)金融貿(mào)易系統(tǒng)的用例圖。

其中，”風(fēng)險(xiǎn)分析:交易估價(jià)”「進(jìn)行交易7設(shè)置邊界”「超越邊界的交易評價(jià)貿(mào)易

;更新帳目”等都是用例的實(shí)例。概括地說，用例有以下特點(diǎn)：

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

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

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

(3)執(zhí)行者(Actor)

執(zhí)行者是指用戶在系統(tǒng)中所扮演的角色。其圖形化的表示是一個(gè)小人。圖1中有

四個(gè)執(zhí)行者:貿(mào)易經(jīng)理、營銷人員、售貨員和記帳系統(tǒng)。在某些組織中很可能有

許多營銷人員，但就該系統(tǒng)而言，他們均起著同一種作用，扮演著相同的角色所以

用一個(gè)執(zhí)行者表示。一個(gè)用戶也可以扮演多種角色(執(zhí)行者)。例如,一個(gè)高級(jí)營銷

人員既可以是貿(mào)易經(jīng)理,也可以是普通的營銷人員;一個(gè)營銷人員也可以是售貨

員。在處理執(zhí)行者時(shí)，應(yīng)考慮其作用而不是人或工作名稱,這一點(diǎn)是很重要的。

圖1中，不帶箭頭的線段將執(zhí)行者與用例連接到一起，表示兩者之間交換信息，稱之

為通信聯(lián)系。執(zhí)行者觸發(fā)用例，并與用例進(jìn)行信息交換。單個(gè)執(zhí)行者可與多個(gè)用

例聯(lián)系;反過來一個(gè)用例可與多個(gè)執(zhí)行者聯(lián)系。對同一個(gè)用例而言,不同執(zhí)行者有

著不同的作用:他們可以從用例中取值，也可以參與到用例中。

需要注意的是執(zhí)行者在用例圖中是用類似人的圖形來表示，盡管執(zhí)行的，但執(zhí)

行者未必是人。例如，執(zhí)行者也可以是一個(gè)外界系統(tǒng),該外界系統(tǒng)可能需要從當(dāng)前

系統(tǒng)中獲取信息與當(dāng)前系統(tǒng)有進(jìn)行交互。在圖1中,我們可以看到，記帳系統(tǒng)是一

個(gè)外界系統(tǒng)，它需要更新帳目。

通過實(shí)踐，我們發(fā)現(xiàn)執(zhí)行者對提供用例是非常有用的。面對一個(gè)大系統(tǒng)，要列出用

例清單常常是十分困難。這時(shí)可先列出執(zhí)行者清單,再對每個(gè)執(zhí)行者列出它的用

例問題就會(huì)變得容易很多。

(4)使用和擴(kuò)展(UseandExtend)

圖1中除了包含執(zhí)行者與用例之間的連接外,還有另外兩種類型的連接用以表示

用例之間的使用和擴(kuò)展關(guān)系。使用和擴(kuò)展是兩種不同形式的繼承關(guān)系。當(dāng)一個(gè)用

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

本的用例是“進(jìn)行交易交易中可能一切都進(jìn)行得很順利,但也可能存在擾亂順

利進(jìn)行交易的因素。其中之一便是超出某些邊界值的情況。例如,貿(mào)易組織會(huì)對

某個(gè)特定客戶規(guī)定最大貿(mào)易量，這時(shí)不能執(zhí)行給定用例提供的常規(guī)動(dòng)作，而要做些

改動(dòng)。我們可在“進(jìn)行交易’用例中做改動(dòng)。但是，這將把該用例與一大堆特殊的判

斷和邏輯混雜在一起，使正常的流程晦澀不堪。圖1中將常規(guī)的動(dòng)作放在”進(jìn)行交

易'用例中，而將非常規(guī)的動(dòng)作放置于”超越邊界的交易”用例中，這便是擴(kuò)展關(guān)系

的實(shí)質(zhì)。當(dāng)有一大塊相似的動(dòng)作存在于幾個(gè)用例，又不想重復(fù)描述該動(dòng)作時(shí)，就可

以用到使用關(guān)系。例如，現(xiàn)實(shí)中風(fēng)險(xiǎn)分析和交易估價(jià)都需要評價(jià)貿(mào)易，為此可單獨(dú)

定義一個(gè)用例，即“評價(jià)貿(mào)易'，而“風(fēng)險(xiǎn)分析’和“交易估價(jià)’用例將使用它。

請注意擴(kuò)展與使用之間的相似點(diǎn)和不同點(diǎn)。它們兩個(gè)都意味著從幾個(gè)用例中抽取

那些公共的行為并放入一個(gè)單獨(dú)用例中，而這個(gè)用例被其他幾個(gè)用例使用或擴(kuò)

展。但使用和擴(kuò)展的目的是不同的。

(5)用例模型的獲取

幾乎在任何情況下都會(huì)使用用例。用例用來獲取需求，規(guī)劃和控制項(xiàng)目。用例的

獲取是需求分析階段的主要任務(wù)之一，而且是首先要做的工作。大部分用例將在

項(xiàng)目的需求分析階段產(chǎn)生，并且隨著工作的深入會(huì)發(fā)現(xiàn)更多的用例，這些都應(yīng)及時(shí)

增添到已有的用例集中。用例集中的每個(gè)用例都是一個(gè)潛在的需求。

a.獲取執(zhí)行者

獲取用例首先要找出系統(tǒng)的執(zhí)行者。可以通過用戶回答一些問題的答案來識(shí)別執(zhí)

行者。以下問題可供參考：

?誰使用系統(tǒng)的主要功能(主要使用者)。

?誰需要系統(tǒng)支持他們的曰常工作C

?誰來維護(hù)、管理使系統(tǒng)正常工作(輔助使用者)。

?系統(tǒng)需要操縱哪些硬件。

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

?對系統(tǒng)產(chǎn)生的結(jié)果感興趣的人或事物。

b.獲取用例

一旦獲取了執(zhí)行者，就可以對每個(gè)執(zhí)行者提出問題以獲取用例。

以下問題可供參考：

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

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

?必須提醒執(zhí)行者的系統(tǒng)事件有哪些?或者執(zhí)行者必須提醒系統(tǒng)的事件有哪些?怎

樣把這些事件表示成用例中的功能？

?為了完整地描述用例，還需要知道執(zhí)行者的某些典型功能能否被系統(tǒng)自動(dòng)實(shí)現(xiàn)？

還有一些不針對具體執(zhí)行者問題（即針對整個(gè)系統(tǒng)的問題）：

?系統(tǒng)需要何種輸入輸出?輸入從何處來?輸出到何處？

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

需要注意，最后兩個(gè)問題并不是指沒有執(zhí)行者也可以有用例,只是獲取用例時(shí)尚不

知道執(zhí)行者是什么。一個(gè)用例必須至少與一個(gè)執(zhí)行者關(guān)聯(lián)。還需要注意:不同的

設(shè)計(jì)者對用例的利用程度也不同。例如JvarJacobson說對一個(gè)十人年的項(xiàng)目，他

需要二十個(gè)用例。而在一個(gè)相同規(guī)模的項(xiàng)目中,MartinFowler則用了一百多個(gè)用

例。我們認(rèn)為:任何合適的用例都可使用確定用例的過程是對獲取的用例進(jìn)行提

煉和歸納的過程，對一個(gè)十人年的項(xiàng)目來說二十個(gè)用例似乎太少，一百多個(gè)用例

則嫌太多，需要保持一者間的相對均衡。（未完待續(xù)）

Home

標(biāo)準(zhǔn)建模語言UML及其支持環(huán)境（三）

北京航空航天大學(xué)軟件工程研究所

（接上期）

前兩期所述主要內(nèi)容如下：

一、標(biāo)準(zhǔn)建模語言UML概述

二、標(biāo)準(zhǔn)建模語言UML的靜態(tài)建模機(jī)制

1.用例圖

2.類圖、對象圖和包

數(shù)千年以前，人類就已經(jīng)開始采用分類的方法有效地簡化復(fù)雜問題幫助人們了解

客觀世界。在面向?qū)ο蠼＜夹g(shù)中，我們使用同樣的方法將客觀世界的實(shí)體映射

為對象，并歸納成一個(gè)個(gè)類。類（Class）、對象（Object）和它們之間的關(guān)聯(lián)是面向?qū)?/p>

象技術(shù)中最基本的元素。對于一個(gè)想要描述的系統(tǒng),其類模型和對象模型揭示了

系統(tǒng)的結(jié)構(gòu)。在UML中,類和對象模型分別由類圖和對象圖表示。類圖技術(shù)是

00方法的核心。圖1顯示了一個(gè)金融保險(xiǎn)系統(tǒng)的類圖。

0

(1)類圖

類圖(ClassDiagram)描述類和類之間的靜態(tài)關(guān)系。與數(shù)據(jù)模型不同,它不僅顯示了

信息的結(jié)構(gòu),同時(shí)還描述了系統(tǒng)的行為。類圖是定義其它圖的基礎(chǔ)。在類圖的基

礎(chǔ)上，狀態(tài)圖、合作圖等進(jìn)一步描述了系統(tǒng)其他方面的特性。

(2)類和對象

對象(Object)與我們對客觀世界的理解相關(guān)。我們通常用對象描述客觀世界中某

個(gè)具體的實(shí)體。所謂類(Class)是對一類具有相同特征的對象的描述。而對象是類

的實(shí)例(Instance)。建立類模型時(shí)，我們應(yīng)盡量與應(yīng)用領(lǐng)域的概念保持一致以使模

型更符合客觀事實(shí)易修改、易理解和易交流。

類描述一類對象的屬性(Attribute)和行為(Behavior)。在UML中，類的可視化表示

為一個(gè)劃分成三個(gè)格子的長方形(下面兩個(gè)格子可省略)。圖1中，“客戶”就是一個(gè)

典型的類。

類的獲取和命名最頂部的格子包含類的名字。類的命名應(yīng)盡量用應(yīng)用領(lǐng)域

中的術(shù)語應(yīng)明確、無歧義以利于開發(fā)人員與用戶之間的相互理解和交流。類的

獲取是一個(gè)依賴于人的創(chuàng)造力的過程，必須與領(lǐng)域?qū)＜液献?對研究領(lǐng)域仔細(xì)地分

析械象出領(lǐng)域中的概念，定義其含義及相互關(guān)系,分析出系統(tǒng)類，并用領(lǐng)域中的術(shù)

語為類命名。一般而言，類的名字是名詞。

類的屬性中間的格子包含類的屬性用以描述該類對象的共同特點(diǎn)。該項(xiàng)可省

略。圖1中”客戶“類有”客戶名“、“地址'等特性。屬性的選取應(yīng)考慮以下因素：

*原則上來說，類的屬性應(yīng)能描述并區(qū)分每個(gè)特定的對象；

*只有系統(tǒng)感興趣的特征才包含在類的屬性中；

*系統(tǒng)建模的目的也會(huì)影響到屬性的選取。

根據(jù)圖的詳細(xì)程度,每條屬性可以包括屬性的可見性、屬性名稱、類型、缺省值

和約束特性。UML規(guī)定類的屬性的語法為：

可見性屬性名：類型二缺省值｛約束特性｝

圖1“客戶”類中「客戶名”屬性描述為客戶名：字符串=缺省客戶名”。可見

性“，表示它是私有數(shù)據(jù)成員，其屬性名為”客戶名“，類型為"字符串”類型，缺省值為

“缺省客戶名”，此處沒有約束特性。

不同屬性具有不同可見性。常用的可見性有Public、Prvate和Protected三種，

在UML中分別表示為”和

類型表示該屬性的種類。七可以是基本數(shù)據(jù)類型，例如整數(shù)、實(shí)數(shù)、布爾型等，也

可以是用戶自定義的類型。一般它由所涉及的程序設(shè)計(jì)語言確定。

約束特性則是用戶對該屬性性質(zhì)一個(gè)約束的說明°例如”｛只讀｝“說明該屬性是只

讀屬性。

類的操作(Operation)該項(xiàng)可省略。操作用于修改、檢索類的屬性或執(zhí)行某些動(dòng)

作。操作通常也被稱為功能,但是它們被約束在類的內(nèi)部，只能作用到該類的對象

±o操作名、返回類型和參數(shù)表組成操作界面。UML規(guī)定操作的語法為：

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

在圖1中，“客戶”類中有“取客戶地址'操作，其中表示該操作是公有操作,調(diào)用時(shí)

需要參數(shù)‘客戶名"，參數(shù)類型為字符串,返回類型也為字符串。

類圖描述了類和類之間的靜態(tài)關(guān)系。定義了類之后就可以定義類之間的各種關(guān)

系了。

⑶關(guān)聯(lián)關(guān)系

關(guān)聯(lián)(Association)表示兩個(gè)類之間存在某種語義上的聯(lián)系。例如，一個(gè)人為一家公

司工作，一家公司有許多辦公室。我們就認(rèn)為人和公司、公司和辦公室之間存在

某種語義上的聯(lián)系。在分析設(shè)計(jì)的類圖模型中，則在對應(yīng)人類和公司類、公司類

和辦公室類之間建立關(guān)聯(lián)關(guān)系。

在圖1中最上部存在一個(gè)‘屬于”/“簽定”關(guān)聯(lián):每個(gè)”保險(xiǎn)單“屬于一個(gè)“客戶“，而‘客

戶“可以簽定多個(gè)“保險(xiǎn)單”，除了這個(gè)關(guān)聯(lián)外，圖1中還有另外兩個(gè)關(guān)聯(lián)，分別表示

每個(gè)“保險(xiǎn)單”包含若干個(gè)“，呆險(xiǎn)單上的項(xiàng)目”，而每個(gè)“保險(xiǎn)單上的項(xiàng)目”涉及單一的

“保險(xiǎn)類別”。

關(guān)聯(lián)的方向關(guān)聯(lián)可以有方向,表示該關(guān)聯(lián)單方向被使用。關(guān)聯(lián)上加上箭頭

表示方向，在UML中稱為導(dǎo)航(Navigability)。我們將只在一個(gè)方向上存在導(dǎo)航表

示的關(guān)聯(lián),稱作單向關(guān)聯(lián)(Uni-directionalAssociation)，在兩個(gè)方向上都有導(dǎo)航表

示的關(guān)聯(lián),稱作雙向關(guān)聯(lián)(Bi-directionalAssociation)。圖1中，“保險(xiǎn)單“到“保險(xiǎn)單

上的項(xiàng)目“是單向關(guān)聯(lián)。UML規(guī)定,不帶箭頭的關(guān)聯(lián)可以意味著未知、未確定或者

該關(guān)聯(lián)是雙向關(guān)聯(lián)三種選擇，因此，在圖中應(yīng)明確使用其中的一種選擇。

關(guān)聯(lián)的命名既然關(guān)聯(lián)可以是雙向的最復(fù)雜的命名方法是每個(gè)方向上給出一個(gè)

名字，這樣的關(guān)聯(lián)有兩個(gè)名字，可以用小黑三角表示名字的方向(見圖1中最上部的

，，屬十/簽定，，關(guān)聯(lián)）。為關(guān)萩命名有幾種方法,其原則是該命名是否有助十理解該

模型。

角色關(guān)聯(lián)兩頭的類以某種角色參與關(guān)聯(lián)。例如圖2中，”公司“以“雇主”的角

包“人”以“雇員”的角色參與的“工作合同“關(guān)聯(lián)?！肮椭鳌昂汀肮蛦T"稱為角色名。如果

在關(guān)聯(lián)上沒有標(biāo)出角色名廁隱含地用類的名稱作為角色名。角色還具有多重性

（Multiplicity）,表示可以有多少個(gè)對象參與該關(guān)聯(lián)。在圖2中，雇主（公司）可以雇傭

（簽工作合同）多個(gè)雇員,表示為”*“；雇員只能與一家雇主簽定工作合同，表示為

"l"o多重性表示參與對象的數(shù)目的上下界限制°”*”代表。?8,即一個(gè)客戶可以

沒有保險(xiǎn)單,也可以有任意多的保險(xiǎn)單?！?“是1..1的簡寫，即任何一個(gè)保險(xiǎn)單僅來

自于一個(gè)客戶，可以用一個(gè)單個(gè)數(shù)字表示，也可以用范圍或者是數(shù)字和范圍不連續(xù)

的組合表示。

0

關(guān)聯(lián)類一個(gè)關(guān)聯(lián)可能要記錄一些信息，可以引入一個(gè)關(guān)聯(lián)類來記錄。圖3

是在圖2的基礎(chǔ)上引入了關(guān)聯(lián)類。關(guān)聯(lián)類通過一根虛線與關(guān)聯(lián)連接。圖4是實(shí)現(xiàn)

上述目標(biāo)的另外一種方法就是使雇用關(guān)系成為一個(gè)正式的類。

0

0

聚集和組成聚集(Aggregation)是一種特殊形式鈍關(guān)聯(lián)。聚集表示類之間的

關(guān)系是整體與部分的關(guān)系。一輛轎車包含四個(gè)車輪、一個(gè)方向盤、一個(gè)發(fā)動(dòng)機(jī)和

一個(gè)底盤，這是聚集的一個(gè)例子。在需求分析中，“包含”、“組成“、”分為……部分”

等經(jīng)常設(shè)計(jì)成聚集關(guān)系。聚集可以進(jìn)一步劃分成共享聚集(SharedAggregation)

和組成。例如,課題組包含許多成員，但是每個(gè)成員又可以是另一個(gè)課題組的成員,

即部分可以參加多個(gè)整體我們稱之為共享聚集。另一種情況是整體擁有各部分,

部分與整體共存如整體不存在了，部分也會(huì)隨之消失，這稱為組成(Composition)。

例如，我們打開一個(gè)視窗口,它就由標(biāo)題、外框和顯示區(qū)所組成。一旦消亡則各部

分同時(shí)消失。在UML中,聚集表示為空心菱形，組成表示為實(shí)心菱形。需要注意的

是，一些面向?qū)ο蟠髱煂奂亩x并不一樣。大家應(yīng)注意其他面向?qū)ο蠓椒ㄅc

UML中所定義的聚集的差別。

⑷繼承關(guān)系

人們將具有共同特性的元素抽象成類別,并通過增加其內(nèi)涵而進(jìn)一步分類。例如,

動(dòng)物可分為飛鳥和走獸，人可分為男人和女人。在面向?qū)ο蠓椒ㄖ袑⑶罢叻Q為一

般元素、基類元素或父元素，將后者稱為特殊元素或子元素。繼承(Generalization)

定義了一般元素和特殊元素之間的分類關(guān)系。在UML中，繼承表示為一頭為空心

三角形的連線。

如圖1中,將客戶進(jìn)一步分類成個(gè)體客戶和團(tuán)體客戶，使用的就是繼承關(guān)系。

在UML定義中對繼承有三個(gè)要求：

*特殊元素應(yīng)與一般元素完全一致，一般元素所具有的關(guān)聯(lián)、屬性和操作，特殊元素

也都隱含性地具有；

*特殊元素還應(yīng)包含額外信息；

*允許使用一般元素實(shí)例的地方，也應(yīng)能使用特殊元素。

(5)依賴關(guān)系

有兩個(gè)元素X、丫,如果修改元素X的定義可能會(huì)引起對另一個(gè)元素Y的定義的修

改，則稱元素Y依賴(Deperdency)于元素X。在類中，依賴由各種原因引起，如:一個(gè)

類向另一個(gè)類發(fā)消息;一個(gè)類是另一個(gè)類的數(shù)據(jù)成員;一個(gè)類是另一個(gè)類的某個(gè)操

作參數(shù)。如果一個(gè)類的界面改變,它發(fā)出的任何消息可能不再合法。

(6)類圖的抽象層次和細(xì)化(Refinement)關(guān)系

需要注意的是，雖然在軟件開發(fā)的不同階段都使用類圖，但這些類圖表示了不同層

次的抽象。在需求分析階段，類圖是研究領(lǐng)域的概念;在設(shè)計(jì)階段，類圖描述類與類

之間的接口;而在實(shí)現(xiàn)階段，類圖描述軟件系統(tǒng)中類的實(shí)現(xiàn)。按照SteveCook和

JohnDianiels的觀點(diǎn)，類圖分為三個(gè)層次。需要說明的是，這個(gè)觀點(diǎn)同樣也適合于

其他任何模型，只是在類圖中顯得更為突出。

概念層概念層(Conceptual)類圖描述應(yīng)用領(lǐng)域中的概念。實(shí)現(xiàn)它們的類可以從

這些概念中得出，但兩者并沒有直接的映射關(guān)系。事實(shí)上，一個(gè)概念模型應(yīng)獨(dú)立于

實(shí)現(xiàn)它的軟件和程序設(shè)計(jì)語言。

說明層說明層(Specification)類圖描述軟件的接口部分而不是軟件的實(shí)現(xiàn)部

分。面向?qū)ο箝_發(fā)方法非常重視區(qū)別接口與實(shí)現(xiàn)之間的差異，但在實(shí)際應(yīng)用中卻

常常忽略這一差異。這主要是因?yàn)?0語言中類的概念將接口與實(shí)現(xiàn)合在了一

起。大多數(shù)方法由于受到語言的影響也仿效了這一做汰?，F(xiàn)在這種情況正在發(fā)

生變化?？梢杂靡粋€(gè)類型(Type)描述一個(gè)接口，這個(gè)接口可能因?yàn)閷?shí)現(xiàn)環(huán)境、運(yùn)

行特性或者用戶的不同而具有多種實(shí)現(xiàn)。

實(shí)現(xiàn)層只有在實(shí)現(xiàn)層(Implementation)才真正有類的概念,并且揭示軟件的實(shí)現(xiàn)

部分。這可能是大多數(shù)人最常用的類圖，但在很多時(shí)候說明層的類圖更易于開發(fā)

者之間的相互理解和交流。

理解以上層次對于畫類圖和讀懂類圖都是至關(guān)重要的。但是由于各層次之間沒有

一個(gè)清晰的界限所以大多數(shù)建模者在畫圖時(shí)沒能對其加以區(qū)分。畫圖時(shí)，要從一

個(gè)清晰的層次觀念出發(fā);而讀圖時(shí)，則要弄清它是根據(jù)哪種層次觀念來繪制的。要

正確地理解類圖,首先應(yīng)正確地理解上述三種層次。雖然將類圖分成三個(gè)層次的

觀點(diǎn)并不是UML的組成部分，但是它們對于建模或者評價(jià)模型非常有用。盡管迄

今為止人們似乎更強(qiáng)調(diào)實(shí)現(xiàn)層類圖，但這三個(gè)層次都可應(yīng)用于UML,而且實(shí)際上另

外兩個(gè)層次的類圖更有用。

下面介紹細(xì)化概念。細(xì)化是UML中的術(shù)語，表示對事物更詳細(xì)一層的描述。兩個(gè)

元素A、B描述同一件事物,它們的區(qū)別是抽象層次不同若元素B是在元素A的

基礎(chǔ)上的更詳細(xì)的描述，則稱元素B細(xì)化了元素A,或稱元素A細(xì)化成元素B。細(xì)

化的圖形表示為由元素B指向元素A的、一頭為空心三角的虛線(千萬不要把方

向顛倒了!)。細(xì)化主要用于模型之間的合作，表示開發(fā)各階段不同層次抽象模型的

相關(guān)性，常用于跟蹤模型的演變。

⑺約束

在UML中，可以用約束(Constraint)表示規(guī)則。約束是放在括號(hào)“0”中的一個(gè)表達(dá)式,

表示一個(gè)永真的邏輯陳述。在程序設(shè)計(jì)語言中，約束可以由斷言(Assertion)來實(shí)

現(xiàn)。

(8)對象圖、對象和鏈

UML中對象圖與類圖具有相同的表示形式。對象圖可以看作是類圖的一個(gè)實(shí)例。

對象是類的實(shí)例;對象之間的鏈(Link)是類之間的關(guān)聯(lián)的實(shí)例。對象與類的圖形表

示相似，均為劃分成兩個(gè)格子的長方形(下面的格子可省略)。上面的格子是對象名,

對象名下有下劃線;下面的格子記錄屬性值。鏈的圖形表示與關(guān)聯(lián)相似。對象圖

常用于表示復(fù)雜的類圖的一個(gè)實(shí)例。

(9)包

一個(gè)最古老的軟件方法問題是:怎樣將大系統(tǒng)拆分成小系統(tǒng)。解決這個(gè)問題的一

個(gè)思路是將許多類集合成一個(gè)更高層次的單位，形成一個(gè)高內(nèi)聚、低耦合的類的

集合。這個(gè)思路被松散地應(yīng)用到許多對象技術(shù)中。UML中這種分組機(jī)制叫包

(Package)(見圖5)。

0

不僅是類，任何模型元素都運(yùn)用包的機(jī)制。如果沒有任何啟發(fā)性原則來指導(dǎo)

類的分組,分組方法就是任意的。在UML中，最有用的和強(qiáng)調(diào)最多的啟發(fā)性原則就

是依賴。包圖主要顯示類的包以及這些包之間的依賴關(guān)系。有時(shí)還顯示包和包之

間的繼承關(guān)系和組成關(guān)系.

包的內(nèi)容在圖5中：系統(tǒng)內(nèi)部“包由“保險(xiǎn)單“包和“客戶”包組成。這里稱“保險(xiǎn)單

“包和”客戶“包為”系統(tǒng)內(nèi)部”包的內(nèi)容。當(dāng)不需要顯示包的內(nèi)容時(shí)，包的名字放入主

方框內(nèi)，否則包的名字放入左上角的小方框中，而將內(nèi)容放入主方框內(nèi)。包的內(nèi)容

可以是類的列表，也可以是另一個(gè)包圖,還可以是一個(gè)類圖。

包的依賴和繼承圖5中，保險(xiǎn)單填寫界面”包依賴于“保險(xiǎn)單“包;整個(gè)“系統(tǒng)內(nèi)部”

包依賴于“數(shù)據(jù)庫界面”包八可以使用繼承中通用和特例的概念來說明通用包和專

用包之間的關(guān)系。例如，專用包必須符合通用包的界面,與類繼承關(guān)系類似。通過“

數(shù)據(jù)庫界面“包，“系統(tǒng)內(nèi)部”包既能夠使用Oracle的界面也可使用Sybase的界面。

通用包可標(biāo)記為{abstract},表示該包只是定義了一個(gè)界面,具體實(shí)現(xiàn)則由專用包

來完成。

(10)其他模型元素和表示機(jī)制

類圖中用到的模型元素和表示機(jī)制較為豐富，由于篇幅的限制，這里不能一一介

紹。主要還有以下模型符號(hào)和概念:類別模板(Stereotype)、界面(Interface)、參數(shù)

化類(ParameterizedClass)也稱模板類(Template)、限定關(guān)聯(lián)(Qualified

Association)s多維關(guān)聯(lián)(N-aryAssociation)、多維鏈(N-aryLink)、派生(Derived)、

類型(Type)和注釋(Note)等。

(11)使用類圖的幾個(gè)建議

類圖幾乎是所有00方法的支柱。采用標(biāo)準(zhǔn)建模語言UML進(jìn)行建模時(shí),必須對

UML類圖引入的各種要素有清晰的理解。以下對使用類圖進(jìn)行建模提出幾點(diǎn)建

議：

*不要試圖使用所有的符號(hào)。從簡單的開始，例如，類、關(guān)聯(lián)、屬性和繼承等概念。

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

上根據(jù)項(xiàng)目開發(fā)的不同階段，用正確的觀點(diǎn)來畫類圖。如果處于分析階段，應(yīng)畫概念

層類圖;當(dāng)開始著手軟件設(shè)計(jì)時(shí)，應(yīng)畫說明層類圖;當(dāng)考察某個(gè)特定的實(shí)現(xiàn)技術(shù)時(shí)，

則應(yīng)畫實(shí)現(xiàn)層類圖。

*不要為每個(gè)事物都畫一個(gè)模型應(yīng)該把精力放在關(guān)鍵的領(lǐng)域。最好只畫幾張較為

關(guān)鍵的圖,經(jīng)常使用并不斷更新修改。使用類圖的最大危險(xiǎn)是過早地陷入實(shí)現(xiàn)細(xì)

節(jié)。為了避免這一危險(xiǎn),應(yīng)該將重點(diǎn)放在概念層和說明層。如果已經(jīng)遇到了一些

麻煩可以從以下幾個(gè)方面來反思你的模型。

*模型是否真實(shí)地反映了研究領(lǐng)域的實(shí)際。

*模型和模型中的元素是否有清楚的目的和職責(zé)(在面向?qū)ο蠓椒ㄖ?，系統(tǒng)功能最

終是分配到每個(gè)類的操作上實(shí)現(xiàn)的，這個(gè)機(jī)制叫職責(zé)分配)。

*模型和模型元素的大小是否適中。過于復(fù)雜的模型和模型元素是很難生存的，應(yīng)

將其分解成幾個(gè)相互合作的部分。

(12)術(shù)語比較

下表列出了最常用的四種UML術(shù)語，并與其他方法學(xué)中相對應(yīng)的術(shù)語進(jìn)行比較,

以幫助讀者了解UML與其他建模語言的異同。(未完待續(xù))

0

Home

標(biāo)準(zhǔn)建模語言UML及其支持環(huán)境(四)

北京航空航天大學(xué)軟件工程研究所

(接上期)

前三期所述主要內(nèi)容如下：

一、標(biāo)準(zhǔn)建模語言UML概述

二、標(biāo)準(zhǔn)建模語言UML的靜態(tài)建模機(jī)制

1.用例圖

2.類圖、對象圖和包

0

3.構(gòu)件圖和配置圖

構(gòu)件圖(Componentdiagram)和配置圖(Deploymentdiagram)顯示系統(tǒng)實(shí)現(xiàn)時(shí)的

一些特性,包括源代碼的靜態(tài)結(jié)構(gòu)和運(yùn)行時(shí)刻的實(shí)現(xiàn)結(jié)構(gòu)。構(gòu)件圖顯示代碼本身

的結(jié)構(gòu)，配置圖顯示系統(tǒng)運(yùn)行時(shí)刻的結(jié)構(gòu)。

(1)構(gòu)件圖構(gòu)件圖顯示軟件構(gòu)件之間的依賴關(guān)系。一般來說，軟件構(gòu)件就是一個(gè)

實(shí)際文件,可以是源代碼文件、二進(jìn)制代碼文件和可執(zhí)行文件等?？梢杂脕盹@示

編譯、鏈接或執(zhí)行時(shí)構(gòu)件之間的依賴關(guān)系。

(2)配置圖配置圖描述系統(tǒng)硬件的物理拓?fù)浣Y(jié)構(gòu)以及在此結(jié)構(gòu)上執(zhí)行的軟件。

配置圖可以顯示計(jì)算結(jié)點(diǎn)的拓?fù)浣Y(jié)構(gòu)和通信路徑、結(jié)點(diǎn)上運(yùn)行的軟件構(gòu)件、軟件

構(gòu)件包含的邏輯單元(對象、類)等。配置圖常常用于幫助理解分布式系統(tǒng)。

(3)結(jié)點(diǎn)和連接結(jié)點(diǎn)(Node)代表一個(gè)物理設(shè)備以及其上運(yùn)行的軟件系統(tǒng),如一

臺(tái)Unix主機(jī)、一個(gè)PC終端、一臺(tái)打印機(jī)、一個(gè)傳感器等。如圖1所示「客戶端

PC"和“保險(xiǎn)后臺(tái)服務(wù)器“就是兩個(gè)結(jié)點(diǎn)。結(jié)點(diǎn)表示為一個(gè)立方體，結(jié)點(diǎn)名放在左上

角。

結(jié)點(diǎn)之間的連線表示系統(tǒng)之間進(jìn)行交互的通信路徑，在UML中被稱為連接

(Connection)o通信類型則放在連接旁邊的“《》”之間，表示所用的通信協(xié)議或網(wǎng)

絡(luò)類型。

(4)構(gòu)件和界面在配置圖中，構(gòu)件代表可執(zhí)行的物理代碼模塊，如一個(gè)可執(zhí)行程

序。邏輯上它可以與類圖中的包或類對應(yīng)。因此，配置圖中顯示運(yùn)行時(shí)各個(gè)包或

類在結(jié)點(diǎn)中的分布情況。如在圖1中,“保險(xiǎn)后臺(tái)服務(wù)器”結(jié)點(diǎn)中包含“保險(xiǎn)系統(tǒng)“、

“保險(xiǎn)對象數(shù)據(jù)庫”和“保險(xiǎn)系統(tǒng)配置”3個(gè)構(gòu)件。在面向?qū)ο蠓椒ㄖ?類和構(gòu)件等元

素并不是所有的屬性和操作都對外可見。它們對外提供了可見操作和屬性，稱之

為類和構(gòu)件的界面。界面可以表示為一頭是小園圈的直線。圖1中,“保險(xiǎn)系統(tǒng)”

構(gòu)件提供了一個(gè)“配置”界面。配置圖中還顯示了構(gòu)件之間的依賴關(guān)系「保險(xiǎn)系統(tǒng)

配置''構(gòu)件依賴于這個(gè)“配置”界面。

(5)對象(Object)一個(gè)面向?qū)ο筌浖到y(tǒng)中可以運(yùn)行很多對象。由于構(gòu)件可以看

作與包或類對應(yīng)的物理代碼模塊，因此，構(gòu)件中應(yīng)包含一些運(yùn)行的對象。配置圖中

的對象與對象圖中的對象表示法一樣。圖1中，"保險(xiǎn)系統(tǒng)配置”構(gòu)件包含”配置保

險(xiǎn)政策"和''配置用戶”兩個(gè)對象。

標(biāo)準(zhǔn)建模語言UML的靜態(tài)建模機(jī)制是采用UML進(jìn)行建模的基礎(chǔ)。我們認(rèn)為，熟

練掌握基本概念、區(qū)分不同抽象層次以及在實(shí)踐中靈活運(yùn)用是三條最值得注意

的基本原則。

三、標(biāo)準(zhǔn)建模語言UML的動(dòng)態(tài)建模機(jī)制

1.消息

在面向?qū)ο蠹夹g(shù)中，對象間的交互是通過對象間消息的傳遞來完成的。在UML的

四個(gè)動(dòng)態(tài)模型中均用到消息這個(gè)概念。通常,當(dāng)一個(gè)對象調(diào)用另一個(gè)對象中的操

作時(shí)，即完成了一次消息傳遞。當(dāng)操作執(zhí)行后，控制便返回到調(diào)用者。對象通過相

互間的通信(消息傳遞)進(jìn)行合作拼在其生命周期中根據(jù)通信的結(jié)果不斷改變自

身的狀態(tài)。

在UML中,消息的圖形表示是用帶有箭頭的線段將消息的發(fā)送者和接收者聯(lián)系起

來,箭頭的類型表示消息的類型，如圖2所示。

0

UML定義的消息類型有三種:

簡單消息(SimpleMessage)表示簡單的控制流。用于描述控制如何在對象間進(jìn)行

傳遞，而不考慮通信的細(xì)節(jié)。

同步消息(SynchronousMessage)表示嵌套的控制流。噪作的調(diào)用是一種典型的

同步消息。調(diào)用者發(fā)出消息后必須等待消息返回，只有當(dāng)處理消息的操作執(zhí)行完

畢后,調(diào)用者才可繼續(xù)執(zhí)行自己的操作。

異步消息(AsynchroncusMessage)表示異步控制流。當(dāng)調(diào)用者發(fā)出消息后

不用等待消息的返回即可繼續(xù)執(zhí)行自己的操作。異步消息主要用于描述實(shí)時(shí)系統(tǒng)

中的并發(fā)行為。

2.狀態(tài)圖

狀態(tài)圖(StateDiagram)用來描述一個(gè)特定對象的所有可能狀態(tài)及其引起狀態(tài)轉(zhuǎn)

移的事件。大多數(shù)面向?qū)ο蠹夹g(shù)都用狀態(tài)圖表示單個(gè)對象在其生命周期中的行

為。一個(gè)狀態(tài)圖包括一系列的狀態(tài)以及狀態(tài)之間的轉(zhuǎn)移。

(1)狀態(tài)所有對象都具有狀態(tài)，狀態(tài)是對象執(zhí)行了一系列活動(dòng)的結(jié)果。當(dāng)某個(gè)事

件發(fā)生后對象的狀態(tài)將發(fā)生變化。狀態(tài)圖中定義的狀態(tài)有:初態(tài)、終態(tài)、中間狀

態(tài)、復(fù)合狀態(tài)。其中，初態(tài)是狀態(tài)圖的起始點(diǎn),而終態(tài)則是狀態(tài)圖的終點(diǎn)。一個(gè)狀

態(tài)圖只能有一個(gè)初態(tài)，而終態(tài)則可以有多個(gè)。

中間狀態(tài)包括兩個(gè)區(qū)域:名字域和內(nèi)部轉(zhuǎn)移域，如圖3所示。圖中內(nèi)部轉(zhuǎn)移域

是可選的，其中所列的動(dòng)作將在對象處于該狀態(tài)時(shí)執(zhí)行，且該動(dòng)作的執(zhí)行并不改變

對象的狀態(tài)。

0

一個(gè)狀態(tài)可以進(jìn)一步地細(xì)化為多個(gè)子狀態(tài)，我們將可以進(jìn)一步細(xì)化的狀態(tài)稱

作復(fù)合狀態(tài)。子狀態(tài)之間有”或關(guān)系‘和”與關(guān)系'兩種關(guān)系?；蜿P(guān)系（如圖4）說明

在某一時(shí)刻僅可到達(dá)一個(gè)子狀態(tài)。例如，一個(gè)處于行駛狀態(tài)的汽車，在“行駛”這個(gè)

復(fù)合狀態(tài)中有向前和向后兩個(gè)不同的子狀態(tài)，在某一時(shí)刻汽車要么向前，要么向

后。與關(guān)系（如圖5）說明復(fù)合狀態(tài)中在某一時(shí)刻可同時(shí)到達(dá)多個(gè)子狀態(tài)（稱為并

發(fā)子狀態(tài)）。具有并發(fā)子狀態(tài)的狀態(tài)圖稱為并發(fā)狀態(tài)圖。

0

0

（2）轉(zhuǎn)移狀態(tài)圖中狀態(tài)之間帶箭頭的連線被稱為轉(zhuǎn)移。狀態(tài)的變遷通常是

由事件觸發(fā)的，此時(shí)應(yīng)在轉(zhuǎn)移上標(biāo)出觸發(fā)轉(zhuǎn)移的事件表達(dá)式。如果轉(zhuǎn)移上未標(biāo)明

事件,則表示在源狀態(tài)的內(nèi)部活動(dòng)執(zhí)行完畢后自動(dòng)觸發(fā)轉(zhuǎn)移。

3.順序圖

順序圖（SequenceDiagram）用來描述對象之間動(dòng)態(tài)的交互關(guān)系若重體現(xiàn)對象間

消息傳遞的時(shí)間順序。順序圖存在兩個(gè)軸:水平軸表示不同的對象垂直軸表示時(shí)

間。順序圖中的對象用一個(gè)帶有垂直虛線的矩形框表示并標(biāo)有對象名和類名。

垂直虛線是對象的生命線用于表示在某段時(shí)間內(nèi)對象是存在的。對象間的通信

通過在對象的生命線間畫消息來表示。消息的箭頭指明消息的類型。

順序圖中的消息可以是信號(hào)(Signal)、操作調(diào)用或類似于C++中的

RPC(RemoteProcedureCalls)和Java中的RMI(RemoteMethodlnvocation)o當(dāng)

收到消息時(shí),接收對象立即開始執(zhí)行活動(dòng)，即對象被激活了。通過在對象生命線上

顯示一個(gè)細(xì)長矩形框來表示激活。

消息可以用消息名及參數(shù)來標(biāo)識(shí)。消息也可帶有順序號(hào)但較少使用。消息還可

帶有條件表達(dá)式，表示分支或決定是否發(fā)送消息。如果用于表示分支，則每個(gè)分支

是相互排斥的，即在某一時(shí)刻僅可發(fā)送分支中的一個(gè)消息。

在順序圖的左邊可以有說明信息,用于說明消息發(fā)送的時(shí)刻、描述動(dòng)作的執(zhí)行情

況以及約束信息等。一個(gè)典型的例子就是用于說明一個(gè)消息是重復(fù)發(fā)送的。另外,

可以定義兩個(gè)消息間的時(shí)間限制。

一個(gè)對象可以通過發(fā)送消息來創(chuàng)建另一個(gè)對象,當(dāng)一個(gè)對象被刪除或自我刪除時(shí),

該對象用》標(biāo)識(shí)。

另外，在很多算法中,遞歸是一種很重要的技術(shù)。當(dāng)一個(gè)操作直接或間接調(diào)用自身

時(shí)，即發(fā)生了遞歸。產(chǎn)生遞歸的消息總是同步消息，返回消息應(yīng)是一個(gè)簡單消息。

4.合作圖

合作圖(CollaborationDiagram)用于描述相互合作的對象間的交互關(guān)系和鏈接關(guān)

系。雖然順序圖和合作圖都用來描述對象間的交互關(guān)系但側(cè)重點(diǎn)不一樣。順序

圖著重體現(xiàn)交互的時(shí)間順序，合作圖則著重體現(xiàn)交互對象間的靜態(tài)鏈接關(guān)系。

合作圖中對象的外觀與順序圖中的一樣。如果一個(gè)對象在消息的交互中被創(chuàng)建，

則可在對象名稱之后標(biāo)以｛new｝。類似地，如果一個(gè)對象在交互期間被刪除，則可在

對象名稱之后標(biāo)以｛destroy｝。對象間的鏈接關(guān)系類似于類圖中的聯(lián)系(但無多重性

標(biāo)志)。通過在對象間的鏈接上標(biāo)志帶有消息串的消息(簡單、異步或同步消息)

來表達(dá)對象間的消息傳遞。

(1)鏈接鏈接用于表示對象間的各種關(guān)系,包括組成關(guān)系的鏈接(CompositionLi

nk)、聚集關(guān)系的鏈接(AggregationLink)、限定關(guān)系的鏈接(QualifiedLink)以及導(dǎo)

航鏈接(NavigationLink)。各種鏈接關(guān)系與類圖中的定義相同，在鏈接的端點(diǎn)位置

可以顯示對象的角色名和模板信息。

(