標準建模語言UML及其支持環境(一)

編者按：

軟件工程領域在1995年至1997年取得了前所未有的進展,其成果超過軟件工程

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

就是統一建模語言(UML:lhifiedModelingLanguage)的出現。在世界范圍內，至少

在近10年內,UML將是面向對象技術領域內占主導地位的標準建模語言。采用

UML作為我國統一的建模語言是完全必要的:首先，過去數十種面向對象的建模語

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

次通過統一語義和符號表示，能夠穩定我國的面向對象技術市場,使項目根植于

一個成熟的標準建模語言從而可以大大拓寬所研制與開發的軟件系統的適用范

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

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

個部分：

一、標準建模語言UML的概念作者張莉周伯莊

二、標準建模語言UML的靜態建模機制作者葛科楊順祥

三、標準建模語言UML的動態建模機制作者王云葛科

四、標準建模語言HMI支持環境作者周伯生張莉

五、標準建模語言UML的應用實例作者楊順祥王云

我們將以連載的形式分7次對上述內容進行介紹。

一、標準建模語言UML概述

面向對象的分析與設計(OOA&D)方法的發展在80年代末至90年代中出現了一

個高潮,UML是這個高潮的產物。它不僅統一了Booch、Rumbaugh^0Jacobson

的表示方法,而且對其作了進一步的發展，并最終統一為大眾所接受的標準建模語

言。

L標準建模語言UML的出現

公認的面向對象建模語言出現于70年代中期。從1989年到1994年，其數量從不

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

產品，并在實踐中不斷完善。但是Q0方法的用戶并不了解不同建模語言的優缺

點及相互之間的差異，因而很難根據應用特點選擇合適的建模語言,于是爆發了一

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

OOSE和OMT-2等。

Booch是面向對象方法最早的倡導者之一，他提出了面向對象軟件工程的概念。

1991年他將以前面向Ada的工作擴展到整個面向對象設計領域。Booch1993

比較適合十系統的設計和構造。Rumbaugh等人提出了面向對象的建模技術

(OMT)方法，采用了面向對象的概念,并引入各種獨立于語言的表示符。這種方法

用對象模型、動態模型、功能模型和用例模型，共同完成對整個系統的建模，所定

義的概念和符號可用于軟件開發的分析、設計和實現的全過程，軟件開發人員不

必在開發過程的不同階段進行概念和符號的轉換。0MT-2特別適用于分析和描

述以數據為中心的信息系統。Jacobson于1994年提出了OOSE方法，其最大特點

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

精確描述需求的重要武器但用例貫穿于整個開發過程，包括對系統的測試和驗

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

即著名的OOA/OOD,它是最早的面向對象的分析和設計方法之一。該方法簡單、

易學,適合于面向對象技術的初學者使用，但由于該方法在處理能力方面的局限，

目前已很少使用。

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

別,因此很難找到一種比較適合其應用特點的語言;其次，眾多的建模語言實際上

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

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

缺點及總結面向對象技術應用實踐的基礎上，組織聯合設計小組，根據應用需求，

取其精華，去其糟粕，求同存異，統一建模語言。

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

Booch93和OMT-2統一起來，并于1995年10月發布了第一個公開版本,稱之為

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

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

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

命名為UML(UnifiedModelingLanguage)。1996年，一些機構將UML作為其商業

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

成員協會,以完善、加強和促進UML的定義工作。當時的成員有DECsHPJ-Logix.

Itellicorp^IBM、ICONComputingsMCISystemhouse、Mierosoft^Oracle、

RationalSoftwaresTl以及Unisys0這一機構對UML1.3(1997年1月)及UML

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

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

入了軟件工程領域的新思想、新方法和新技術。它的作用域不限于支持面向對象

的分析與設計，還支持從需求分析開始的軟件開發的全過程。

0

圖1UML的發展歷程

面向對象技術和UML的發展過程可用上圖來表示，標準建模語言的出現是其重要

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

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

面向對象技術市場的85%,成為可視化建模語言事實上的工業標準。1997年11月

17日QMG采納UML1.1作為基于面向對象技術的標準建模語言。UML代表了

面向對象方法的軟件開發技術的發展方向，具有巨大的市場前景，也具有重大的經

濟價值和國防價值。

2.標準建模語言UML的內容

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

念與其他面向對象技術中的基本概念大多相同,因而,UML必然成為這些方法以及

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

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

而完成的,UML擴展了現有方法的應用范圍;第三,UML是標準的建模語言,而不是

標準的開發過程。盡管UML的應用必然以系統的開發過程為背景,但由于不同的

組織和不同的應用領域,需要采取不同的開發過程。

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

O

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

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

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

的擴展定義。

⑵UML表示法定義UML符號的表示法，為開發者或升發工具使用這些圖形符

號和文本語法為系統建模提供了標準。這些圖形符號和文字所表達的是應用級的

模型,在語義上它是UML元模型的實例。

標準建模語言UML的重要內容可以由下列五類圖(共9種圖形)來定義：

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

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

中類的靜態結構。不僅定義系統中的類，表示類之間的聯系如關聯、依賴、聚合

等,也包括類的內部結構(類的屬性和操作)。類圖描述的是一種靜態關系，在系統的

整個生命周期都是有效的。對象圖是類圖的實例，幾乎使用與類圖完全相同的標

識。他們的不同點在于對象圖顯示類的多個對象實例而不是實際的類。一個對

象圖是類圖的一個實例。由于對象存在生命周期，因此對象圖只能在系統某一時

間段存在。包由包或類組成表示包與包之間的關系。包圖用于描述系統的分層

結構。

?第三類是行為圖(Behaviordiagram),描述系統的動態模型和組成對象間的交互關

系。其中狀態圖描述類的對象所有可能的狀態以及事件發生時狀態的轉移條件。

通常，狀態圖是對類圖的補充。在實用上并不需要為所有的類畫狀態圖，僅為那些

有多個狀態其行為受外界環境的影響并且發生改變的類畫狀態圖。而活動圖描述

滿足用例要求所要進行的活動以及活動間的約束關系，有利于識別并行活動。

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

對象之間的動態合作關系，它強調對象之間消息發送的順序，同時顯示對象之間的

交互;合作圖描述對象間的協作關系，合作圖跟順序圖相似,顯示對象間的動態合

作關系。除顯示信息交換外,合作圖還顯示對象以及它們之間的關系。如果強調

時間和順序廁使用順序圖如果強調上下級關系廁選擇合作圖。這兩種圖合稱為

交互圖。

?第五類是實現圖(Implementationdiagram)。其中構件圖描述代碼部件的物理結

構及各部件之間的依賴關系。一個部件可能是一個資源代碼部件、一個二進制部

件或一個可執行部件。它包含邏輯類或實現類的有關信息。部件圖有助于分析和

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

配置圖定義系統中軟硬件的物理體系結構。它可以顯示實際的計算機和設備(用

節點表示)以及它們之間的連接關系，也可顯示連接的類型及部件之間的依賴性。

在節點內部，放置可執行部件和對象以顯示節點跟可執行軟件單元的對應關系。

從應用的角度看，當采用面向對象技術設計系統時，首先是描述需求淇次根據需

求建立系統的靜態模型,以構造系統的結構;第三步是描述系統的行為。其中在第

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

組件圖和配置圖等五個圖形，是標準建模語言UML的靜態建模機制。其中第三步

中所建立的模型或者可以執行,或者表示執行時的時序狀態或交互關系。它包括

狀態圖、活動圖、順序圖和合作圖等四個圖形，是標準建模語言UML的動態建模

機制。因此,標準建模語言UML的主要內容也可以歸納為靜態建模機制和動態建

模機制兩大類。

3.標準建模語言UML的主要特點

標準建模語言UML的主要特點可以歸結為三點：

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

⑵UML還吸取了面向對象技術領域中其他流派的長處,其中也包括非00方法的

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

余的和極少使用的符號,也添加了一些新符號,因此，在UML中匯入了面向對象領

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

最優秀的0。方法和豐富的計算機科學實踐經驗綜合提煉而成的。

⑶UML在演變過程中還提出了一些新的概念。在UML標準中新加了模板

(Stereotypes)、職責(Responsibilities)、擴展機制(Extensibilitymechanisms)、線

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

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

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

和組件(Components)等概念。

因此可以認為,UML是一種先進實用的標準建模語言,但其中某些概念尚待實踐來

驗證,UML也必然存在一個進化過程(未完待續)。

Home

標準建模語言UML及其支持環境(二)

北京航空航天大學軟件工程研究所

(接上期)

4.標準建模語言UML的應用領域

UML的目標是以面向對象圖的方式來描述任何類型的系統，具有很寬的應用領

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

系統,如機械系統、企業機構或業務過程以及處理復雜數據的信息系統、具有實

時要求的工業系統或工業過程等。總之,UML是一個通用的標準建模語言，可以對

任何具有靜態結構和動態行為的系統進行建模。此外,UML適用于系統開發過程

中從需求規格描述到系統完成后測

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

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

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

的關系，并用UML類圖來描述。為實現用例，類之間需要協作這可以用UML動態

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

軟件系統中技術細節的類(如處理用戶接口、數據庫、通訊和并行性等問題的類)。

這些技術細節將在設計階段引入，因此設計階段為構造階段提供更詳細的規格說

明。

編程(構造)是一個獨立的階段,其任務是用面向對象編程語言將來自設計階段的

類轉換成實際的代碼。在用UML建立分析和設計模型時，應盡量避免考慮把模型

轉換成某種特定的編程語言。因為在早期階段，模型僅僅是理解和分析系統結構

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

UML模型還可作為測試階段的依據。系統通常需要經過單元測試、集成測試、

系統測試和驗收測試。不同的測試小組使用不同的UML圖作為測試依據:單元測

試使用類圖和類規格說明;集成測試使用部件圖和合作圖;系統測試使用用例圖來

驗證系統的行為;驗收測試由用戶進行，以驗證系統測試的結果是否滿足在分析階

段確定的需求。

總之,標準建模語言UML適用于以面向對象技術來描述任何類型的系統,而且適

用于系統開發的不同階段從需求規格描述直至系統完成后的測試和維護。

二、標準建模語言UML的靜態建模機制

任何建模語言都以靜態建模機制為基礎,標準建模語言UML也不例外。UML

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

包、構件圖和配置圖

(Objectdiagram)s(Package)(Componentdiagram)

(Deploymentdiagram)。

1.用例圖

(1)用例模型(Usecasemodel)

長期以來，在面向對象開發和傳統的軟件開發中，人們根據典型的使用情景來了解

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

模型由IvarJacobson在開發AXE系統中首先使用,并加入由他所倡導的OOSE和

Objectory方法中。用例方法引起了面向對象領域的極大關注。自1994年Ivar

Jacobson的著作出版后，面向對象領域已廣泛接納了用例這一概念,并認為它是第

二代面向對象技術的標志。

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

階段，它的建立是系統開發者和用戶反復討論的結果，表用了開發者和用戶對需求

規格達成的共識。首先，它描述了待開發系統的功能需求其次,它將系統看作黑盒,

從外部執行者的角度來理解系統;第三，它驅動了需求分圻之后各階段的開發工作,

不僅在開發過程中保證了系統所有功能的實現，而且被用于驗證和檢測所開發的

系統,從而影響到開發工作的各個階段和UML的各個模型。在UML中,一個用例

模型由若干個用例圖描述,用例圖主要元素是用例和執行者。

(2)用例(usecase)

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

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

用例被定義成系統執行的一系列動作,動作執行的結果能被指定執行者察覺到。

0

圖1用例圖

在UML中,用例表示為一個橢圓°圖1顯示了一個金融貿易系統的用例圖。

其中，”風險分析:交易估價”「進行交易7設置邊界”「超越邊界的交易評價貿易

;更新帳目”等都是用例的實例。概括地說，用例有以下特點：

?用例捕獲某些用戶可見的需求,實現一個具體的用戶目標。

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

?用例可大可小，但它必須是對一個具體的用戶目標實現的完整描述。

(3)執行者(Actor)

執行者是指用戶在系統中所扮演的角色。其圖形化的表示是一個小人。圖1中有

四個執行者:貿易經理、營銷人員、售貨員和記帳系統。在某些組織中很可能有

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

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

人員既可以是貿易經理,也可以是普通的營銷人員;一個營銷人員也可以是售貨

員。在處理執行者時，應考慮其作用而不是人或工作名稱,這一點是很重要的。

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

為通信聯系。執行者觸發用例，并與用例進行信息交換。單個執行者可與多個用

例聯系;反過來一個用例可與多個執行者聯系。對同一個用例而言,不同執行者有

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

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

行者未必是人。例如，執行者也可以是一個外界系統,該外界系統可能需要從當前

系統中獲取信息與當前系統有進行交互。在圖1中,我們可以看到，記帳系統是一

個外界系統，它需要更新帳目。

通過實踐，我們發現執行者對提供用例是非常有用的。面對一個大系統，要列出用

例清單常常是十分困難。這時可先列出執行者清單,再對每個執行者列出它的用

例問題就會變得容易很多。

(4)使用和擴展(UseandExtend)

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

用例之間的使用和擴展關系。使用和擴展是兩種不同形式的繼承關系。當一個用

例與另一個用例相似，但所做的動作多一些，就可以用到擴展關系。例如圖1中，基

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

利進行交易的因素。其中之一便是超出某些邊界值的情況。例如,貿易組織會對

某個特定客戶規定最大貿易量，這時不能執行給定用例提供的常規動作，而要做些

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

斷和邏輯混雜在一起，使正常的流程晦澀不堪。圖1中將常規的動作放在”進行交

易'用例中，而將非常規的動作放置于”超越邊界的交易”用例中，這便是擴展關系

的實質。當有一大塊相似的動作存在于幾個用例，又不想重復描述該動作時，就可

以用到使用關系。例如，現實中風險分析和交易估價都需要評價貿易，為此可單獨

定義一個用例，即“評價貿易'，而“風險分析’和“交易估價’用例將使用它。

請注意擴展與使用之間的相似點和不同點。它們兩個都意味著從幾個用例中抽取

那些公共的行為并放入一個單獨用例中，而這個用例被其他幾個用例使用或擴

展。但使用和擴展的目的是不同的。

(5)用例模型的獲取

幾乎在任何情況下都會使用用例。用例用來獲取需求，規劃和控制項目。用例的

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

項目的需求分析階段產生，并且隨著工作的深入會發現更多的用例，這些都應及時

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

a.獲取執行者

獲取用例首先要找出系統的執行者。可以通過用戶回答一些問題的答案來識別執

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

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

?誰需要系統支持他們的曰常工作C

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

?系統需要操縱哪些硬件。

?系統需要與哪些其它系統交互，包含其它計算機系統和其它應用程序。

?對系統產生的結果感興趣的人或事物。

b.獲取用例

一旦獲取了執行者，就可以對每個執行者提出問題以獲取用例。

以下問題可供參考：

?執行者要求系統提供哪些功能（執行者需要做什么）？

?執行者需要讀、產生、刪除、修改或存儲的信息有哪些類型。

?必須提醒執行者的系統事件有哪些?或者執行者必須提醒系統的事件有哪些?怎

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

?為了完整地描述用例，還需要知道執行者的某些典型功能能否被系統自動實現？

還有一些不針對具體執行者問題（即針對整個系統的問題）：

?系統需要何種輸入輸出?輸入從何處來?輸出到何處？

?當前運行系統（也許是一些手工操作而不是計算機系統）的主要問題？

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

知道執行者是什么。一個用例必須至少與一個執行者關聯。還需要注意:不同的

設計者對用例的利用程度也不同。例如JvarJacobson說對一個十人年的項目，他

需要二十個用例。而在一個相同規模的項目中,MartinFowler則用了一百多個用

例。我們認為:任何合適的用例都可使用確定用例的過程是對獲取的用例進行提

煉和歸納的過程，對一個十人年的項目來說二十個用例似乎太少，一百多個用例

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

Home

標準建模語言UML及其支持環境（三）

北京航空航天大學軟件工程研究所

（接上期）

前兩期所述主要內容如下：

一、標準建模語言UML概述

二、標準建模語言UML的靜態建模機制

1.用例圖

2.類圖、對象圖和包

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

客觀世界。在面向對象建模技術中，我們使用同樣的方法將客觀世界的實體映射

為對象，并歸納成一個個類。類（Class）、對象（Object）和它們之間的關聯是面向對

象技術中最基本的元素。對于一個想要描述的系統,其類模型和對象模型揭示了

系統的結構。在UML中,類和對象模型分別由類圖和對象圖表示。類圖技術是

00方法的核心。圖1顯示了一個金融保險系統的類圖。

0

(1)類圖

類圖(ClassDiagram)描述類和類之間的靜態關系。與數據模型不同,它不僅顯示了

信息的結構,同時還描述了系統的行為。類圖是定義其它圖的基礎。在類圖的基

礎上，狀態圖、合作圖等進一步描述了系統其他方面的特性。

(2)類和對象

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

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

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

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

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

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

典型的類。

類的獲取和命名最頂部的格子包含類的名字。類的命名應盡量用應用領域

中的術語應明確、無歧義以利于開發人員與用戶之間的相互理解和交流。類的

獲取是一個依賴于人的創造力的過程，必須與領域專家合作,對研究領域仔細地分

析械象出領域中的概念，定義其含義及相互關系,分析出系統類，并用領域中的術

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

類的屬性中間的格子包含類的屬性用以描述該類對象的共同特點。該項可省

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

*原則上來說，類的屬性應能描述并區分每個特定的對象；

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

*系統建模的目的也會影響到屬性的選取。

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

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

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

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

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

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

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

在UML中分別表示為”和

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

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

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

讀屬性。

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

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

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

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

在圖1中，“客戶”類中有“取客戶地址'操作，其中表示該操作是公有操作,調用時

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

類圖描述了類和類之間的靜態關系。定義了類之后就可以定義類之間的各種關

系了。

⑶關聯關系

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

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

某種語義上的聯系。在分析設計的類圖模型中，則在對應人類和公司類、公司類

和辦公室類之間建立關聯關系。

在圖1中最上部存在一個‘屬于”/“簽定”關聯:每個”保險單“屬于一個“客戶“，而‘客

戶“可以簽定多個“保險單”，除了這個關聯外，圖1中還有另外兩個關聯，分別表示

每個“保險單”包含若干個“，呆險單上的項目”，而每個“保險單上的項目”涉及單一的

“保險類別”。

關聯的方向關聯可以有方向,表示該關聯單方向被使用。關聯上加上箭頭

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

示的關聯,稱作單向關聯(Uni-directionalAssociation)，在兩個方向上都有導航表

示的關聯,稱作雙向關聯(Bi-directionalAssociation)。圖1中，“保險單“到“保險單

上的項目“是單向關聯。UML規定,不帶箭頭的關聯可以意味著未知、未確定或者

該關聯是雙向關聯三種選擇，因此，在圖中應明確使用其中的一種選擇。

關聯的命名既然關聯可以是雙向的最復雜的命名方法是每個方向上給出一個

名字，這樣的關聯有兩個名字，可以用小黑三角表示名字的方向(見圖1中最上部的

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

模型。

角色關聯兩頭的類以某種角色參與關聯。例如圖2中，”公司“以“雇主”的角

包“人”以“雇員”的角色參與的“工作合同“關聯。“雇主“和“雇員"稱為角色名。如果

在關聯上沒有標出角色名廁隱含地用類的名稱作為角色名。角色還具有多重性

（Multiplicity）,表示可以有多少個對象參與該關聯。在圖2中，雇主（公司）可以雇傭

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

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

沒有保險單,也可以有任意多的保險單。”1“是1..1的簡寫，即任何一個保險單僅來

自于一個客戶，可以用一個單個數字表示，也可以用范圍或者是數字和范圍不連續

的組合表示。

0

關聯類一個關聯可能要記錄一些信息，可以引入一個關聯類來記錄。圖3

是在圖2的基礎上引入了關聯類。關聯類通過一根虛線與關聯連接。圖4是實現

上述目標的另外一種方法就是使雇用關系成為一個正式的類。

0

0

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

關系是整體與部分的關系。一輛轎車包含四個車輪、一個方向盤、一個發動機和

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

等經常設計成聚集關系。聚集可以進一步劃分成共享聚集(SharedAggregation)

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

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

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

例如，我們打開一個視窗口,它就由標題、外框和顯示區所組成。一旦消亡則各部

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

是，一些面向對象大師對聚集的定義并不一樣。大家應注意其他面向對象方法與

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

⑷繼承關系

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

動物可分為飛鳥和走獸，人可分為男人和女人。在面向對象方法中將前者稱為一

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

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

三角形的連線。

如圖1中,將客戶進一步分類成個體客戶和團體客戶，使用的就是繼承關系。

在UML定義中對繼承有三個要求：

*特殊元素應與一般元素完全一致，一般元素所具有的關聯、屬性和操作，特殊元素

也都隱含性地具有；

*特殊元素還應包含額外信息；

*允許使用一般元素實例的地方，也應能使用特殊元素。

(5)依賴關系

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

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

類向另一個類發消息;一個類是另一個類的數據成員;一個類是另一個類的某個操

作參數。如果一個類的界面改變,它發出的任何消息可能不再合法。

(6)類圖的抽象層次和細化(Refinement)關系

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

次的抽象。在需求分析階段，類圖是研究領域的概念;在設計階段，類圖描述類與類

之間的接口;而在實現階段，類圖描述軟件系統中類的實現。按照SteveCook和

JohnDianiels的觀點，類圖分為三個層次。需要說明的是，這個觀點同樣也適合于

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

概念層概念層(Conceptual)類圖描述應用領域中的概念。實現它們的類可以從

這些概念中得出，但兩者并沒有直接的映射關系。事實上，一個概念模型應獨立于

實現它的軟件和程序設計語言。

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

分。面向對象開發方法非常重視區別接口與實現之間的差異，但在實際應用中卻

常常忽略這一差異。這主要是因為00語言中類的概念將接口與實現合在了一

起。大多數方法由于受到語言的影響也仿效了這一做汰。現在這種情況正在發

生變化。可以用一個類型(Type)描述一個接口，這個接口可能因為實現環境、運

行特性或者用戶的不同而具有多種實現。

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

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

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

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

一個清晰的界限所以大多數建模者在畫圖時沒能對其加以區分。畫圖時，要從一

個清晰的層次觀念出發;而讀圖時，則要弄清它是根據哪種層次觀念來繪制的。要

正確地理解類圖,首先應正確地理解上述三種層次。雖然將類圖分成三個層次的

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

今為止人們似乎更強調實現層類圖，但這三個層次都可應用于UML,而且實際上另

外兩個層次的類圖更有用。

下面介紹細化概念。細化是UML中的術語，表示對事物更詳細一層的描述。兩個

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

基礎上的更詳細的描述，則稱元素B細化了元素A,或稱元素A細化成元素B。細

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

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

相關性，常用于跟蹤模型的演變。

⑺約束

在UML中，可以用約束(Constraint)表示規則。約束是放在括號“0”中的一個表達式,

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

現。

(8)對象圖、對象和鏈

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

對象是類的實例;對象之間的鏈(Link)是類之間的關聯的實例。對象與類的圖形表

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

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

常用于表示復雜的類圖的一個實例。

(9)包

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

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

集合。這個思路被松散地應用到許多對象技術中。UML中這種分組機制叫包

(Package)(見圖5)。

0

不僅是類，任何模型元素都運用包的機制。如果沒有任何啟發性原則來指導

類的分組,分組方法就是任意的。在UML中，最有用的和強調最多的啟發性原則就

是依賴。包圖主要顯示類的包以及這些包之間的依賴關系。有時還顯示包和包之

間的繼承關系和組成關系.

包的內容在圖5中：系統內部“包由“保險單“包和“客戶”包組成。這里稱“保險單

“包和”客戶“包為”系統內部”包的內容。當不需要顯示包的內容時，包的名字放入主

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

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

包的依賴和繼承圖5中，保險單填寫界面”包依賴于“保險單“包;整個“系統內部”

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

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

數據庫界面“包，“系統內部”包既能夠使用Oracle的界面也可使用Sybase的界面。

通用包可標記為{abstract},表示該包只是定義了一個界面,具體實現則由專用包

來完成。

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

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

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

化類(ParameterizedClass)也稱模板類(Template)、限定關聯(Qualified

Association)s多維關聯(N-aryAssociation)、多維鏈(N-aryLink)、派生(Derived)、

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

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

類圖幾乎是所有00方法的支柱。采用標準建模語言UML進行建模時,必須對

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

議：

*不要試圖使用所有的符號。從簡單的開始，例如，類、關聯、屬性和繼承等概念。

在UML中，有些符號僅用于特殊的場合和方法中，只有當需要時才去使用。

上根據項目開發的不同階段，用正確的觀點來畫類圖。如果處于分析階段，應畫概念

層類圖;當開始著手軟件設計時，應畫說明層類圖;當考察某個特定的實現技術時，

則應畫實現層類圖。

*不要為每個事物都畫一個模型應該把精力放在關鍵的領域。最好只畫幾張較為

關鍵的圖,經常使用并不斷更新修改。使用類圖的最大危險是過早地陷入實現細

節。為了避免這一危險,應該將重點放在概念層和說明層。如果已經遇到了一些

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

*模型是否真實地反映了研究領域的實際。

*模型和模型中的元素是否有清楚的目的和職責(在面向對象方法中，系統功能最

終是分配到每個類的操作上實現的，這個機制叫職責分配)。

*模型和模型元素的大小是否適中。過于復雜的模型和模型元素是很難生存的，應

將其分解成幾個相互合作的部分。

(12)術語比較

下表列出了最常用的四種UML術語，并與其他方法學中相對應的術語進行比較,

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

0

Home

標準建模語言UML及其支持環境(四)

北京航空航天大學軟件工程研究所

(接上期)

前三期所述主要內容如下：

一、標準建模語言UML概述

二、標準建模語言UML的靜態建模機制

1.用例圖

2.類圖、對象圖和包

0

3.構件圖和配置圖

構件圖(Componentdiagram)和配置圖(Deploymentdiagram)顯示系統實現時的

一些特性,包括源代碼的靜態結構和運行時刻的實現結構。構件圖顯示代碼本身

的結構，配置圖顯示系統運行時刻的結構。

(1)構件圖構件圖顯示軟件構件之間的依賴關系。一般來說，軟件構件就是一個

實際文件,可以是源代碼文件、二進制代碼文件和可執行文件等。可以用來顯示

編譯、鏈接或執行時構件之間的依賴關系。

(2)配置圖配置圖描述系統硬件的物理拓撲結構以及在此結構上執行的軟件。

配置圖可以顯示計算結點的拓撲結構和通信路徑、結點上運行的軟件構件、軟件

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

(3)結點和連接結點(Node)代表一個物理設備以及其上運行的軟件系統,如一

臺Unix主機、一個PC終端、一臺打印機、一個傳感器等。如圖1所示「客戶端

PC"和“保險后臺服務器“就是兩個結點。結點表示為一個立方體，結點名放在左上

角。

結點之間的連線表示系統之間進行交互的通信路徑，在UML中被稱為連接

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

絡類型。

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

序。邏輯上它可以與類圖中的包或類對應。因此，配置圖中顯示運行時各個包或

類在結點中的分布情況。如在圖1中,“保險后臺服務器”結點中包含“保險系統“、

“保險對象數據庫”和“保險系統配置”3個構件。在面向對象方法中,類和構件等元

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

為類和構件的界面。界面可以表示為一頭是小園圈的直線。圖1中,“保險系統”

構件提供了一個“配置”界面。配置圖中還顯示了構件之間的依賴關系「保險系統

配置''構件依賴于這個“配置”界面。

(5)對象(Object)一個面向對象軟件系統中可以運行很多對象。由于構件可以看

作與包或類對應的物理代碼模塊，因此，構件中應包含一些運行的對象。配置圖中

的對象與對象圖中的對象表示法一樣。圖1中，"保險系統配置”構件包含”配置保

險政策"和''配置用戶”兩個對象。

標準建模語言UML的靜態建模機制是采用UML進行建模的基礎。我們認為，熟

練掌握基本概念、區分不同抽象層次以及在實踐中靈活運用是三條最值得注意

的基本原則。

三、標準建模語言UML的動態建模機制

1.消息

在面向對象技術中，對象間的交互是通過對象間消息的傳遞來完成的。在UML的

四個動態模型中均用到消息這個概念。通常,當一個對象調用另一個對象中的操

作時，即完成了一次消息傳遞。當操作執行后，控制便返回到調用者。對象通過相

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

身的狀態。

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

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

0

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

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

傳遞，而不考慮通信的細節。

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

同步消息。調用者發出消息后必須等待消息返回，只有當處理消息的操作執行完

畢后,調用者才可繼續執行自己的操作。

異步消息(AsynchroncusMessage)表示異步控制流。當調用者發出消息后

不用等待消息的返回即可繼續執行自己的操作。異步消息主要用于描述實時系統

中的并發行為。

2.狀態圖

狀態圖(StateDiagram)用來描述一個特定對象的所有可能狀態及其引起狀態轉

移的事件。大多數面向對象技術都用狀態圖表示單個對象在其生命周期中的行

為。一個狀態圖包括一系列的狀態以及狀態之間的轉移。

(1)狀態所有對象都具有狀態，狀態是對象執行了一系列活動的結果。當某個事

件發生后對象的狀態將發生變化。狀態圖中定義的狀態有:初態、終態、中間狀

態、復合狀態。其中，初態是狀態圖的起始點,而終態則是狀態圖的終點。一個狀

態圖只能有一個初態，而終態則可以有多個。

中間狀態包括兩個區域:名字域和內部轉移域，如圖3所示。圖中內部轉移域

是可選的，其中所列的動作將在對象處于該狀態時執行，且該動作的執行并不改變

對象的狀態。

0

一個狀態可以進一步地細化為多個子狀態，我們將可以進一步細化的狀態稱

作復合狀態。子狀態之間有”或關系‘和”與關系'兩種關系。或關系（如圖4）說明

在某一時刻僅可到達一個子狀態。例如，一個處于行駛狀態的汽車，在“行駛”這個

復合狀態中有向前和向后兩個不同的子狀態，在某一時刻汽車要么向前，要么向

后。與關系（如圖5）說明復合狀態中在某一時刻可同時到達多個子狀態（稱為并

發子狀態）。具有并發子狀態的狀態圖稱為并發狀態圖。

0

0

（2）轉移狀態圖中狀態之間帶箭頭的連線被稱為轉移。狀態的變遷通常是

由事件觸發的，此時應在轉移上標出觸發轉移的事件表達式。如果轉移上未標明

事件,則表示在源狀態的內部活動執行完畢后自動觸發轉移。

3.順序圖

順序圖（SequenceDiagram）用來描述對象之間動態的交互關系若重體現對象間

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

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

垂直虛線是對象的生命線用于表示在某段時間內對象是存在的。對象間的通信

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

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

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

收到消息時,接收對象立即開始執行活動，即對象被激活了。通過在對象生命線上

顯示一個細長矩形框來表示激活。

消息可以用消息名及參數來標識。消息也可帶有順序號但較少使用。消息還可

帶有條件表達式，表示分支或決定是否發送消息。如果用于表示分支，則每個分支

是相互排斥的，即在某一時刻僅可發送分支中的一個消息。

在順序圖的左邊可以有說明信息,用于說明消息發送的時刻、描述動作的執行情

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

可以定義兩個消息間的時間限制。

一個對象可以通過發送消息來創建另一個對象,當一個對象被刪除或自我刪除時,

該對象用》標識。

另外，在很多算法中,遞歸是一種很重要的技術。當一個操作直接或間接調用自身

時，即發生了遞歸。產生遞歸的消息總是同步消息，返回消息應是一個簡單消息。

4.合作圖

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

系。雖然順序圖和合作圖都用來描述對象間的交互關系但側重點不一樣。順序

圖著重體現交互的時間順序，合作圖則著重體現交互對象間的靜態鏈接關系。

合作圖中對象的外觀與順序圖中的一樣。如果一個對象在消息的交互中被創建，

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

對象名稱之后標以｛destroy｝。對象間的鏈接關系類似于類圖中的聯系(但無多重性

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

來表達對象間的消息傳遞。

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

nk)、聚集關系的鏈接(AggregationLink)、限定關系的鏈接(QualifiedLink)以及導

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

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

(