標準建模語言UML概述

一、標準建模語言UML概述

面向對象的分析與設計(OOA&D)方法的發展在80年代末至90年代中出現了一個高潮,UML是這個高潮的產物。

它不僅統一了Booch、Rumbaugh和Jacobson的表示方法,而且對其作了進一步的發展,并最終統一為大眾所接受的標準建模語言。

1. 標準建模語言UML的出現公認的面向對象建模語言出現于70年代中期。從1989年到1994年,其數量從不到十種增加到了五十多種。

在眾多的建模語言中,語言的創造者努力推崇自己的產品,并在實踐中不斷完善。

但是,OO方法的用戶并不了解不同建模語言的優缺點及相互之間的差異,因而很難根據應用特點選擇合適的建模語言,于是爆發了一場"方法大戰"。

90年代中,一批新方法出現了,其中最引人注目的是Booch 1993、OOSE和OMT-2等。Booch是面向對象方法最早的倡導者之一,他提出了面向對象軟件工程的概念。

1991年,他將以前面向Ada的工作擴展到整個面向對象設計領域。Booch 1993比較適合于系統的設計和構造。Rumbaugh等人提出了面向對象的建模技術(OMT)方法,采用了面向對象的概念,并引入各種獨立于語言的表示符。

這種方法用對象模型、動態模型、功能模型和用例模型,共同完成對整個系統的建模,所定義的概念和符號可用于軟件開發的分析、設計和實現的全過程,軟件開發人員不必在開發過程的不同階段進行概念和符號的轉換。

OMT-2特別適用于分析和描述以數據為中心的信息系統。

Jacobson于1994年提出了OOSE方法,其最大特點是面向用例(Use-Case),并在用例的描述中引入了外部角色的概念。

用例的概念是精確描述需求的重要武器,但用例貫穿于整個開發過程,包括對系統的測試和驗證。OOSE比較適合支持商業工程和需求分析。

此外,還有Coad/Yourdon方法,即著名的OOA/OOD,它是最早的面向對象的分析和設計方法之一。

該方法簡單、易學,適合于面向對象技術的初學者使用,但由于該方法在處理能力方面的局限,目前已很少使用。概括起來,首先,面對眾多的建模語言,用戶由于沒有能力區別不同語言之間的差別,因此很難找到一種比較適合其應用特點的語言;其次,眾多的建模語言實際上各有千秋;

第三,雖然不同的建模語言大多類同,但仍存在某些細微的差別,極大地妨礙了用戶之間的交流。因此在客觀上,極有必要在精心比較不同的建模語言優缺點及總結面向對象技術應用實踐的基礎上,組織聯合設計小組,根據應用需求,取其精華,去其糟粕,求同存異,統一建模語言。

1994年10月,Grady Booch和Jim Rumbaugh開始致力于這一工作。他們首先將Booch93和OMT-2 統一起來,并于1995年10月發布了第一個公開版本,稱之為統一方法UM 0.8(Unitied Method)。

1995年秋,OOSE 的創始人Ivar Jacobson加盟到這一工作。

經過Booch、Rumbaugh和Jacobson三人的共同努力,于1996年6月和10月分別發布了兩個新的版本,即UML 0.9和UML 0.91,并將UM重新命名為UML(Unified Modeling Language)。

1996年,一些機構將UML作為其商業策略已日趨明顯。UML的開發者得到了來自公眾的正面反應,并倡議成立了UML成員協會,以完善、加強和促進UML的定義工作。當時的成員有DEC、HP、I-Logix、 Itellicorp、 IBM、ICON Computing、MCI Systemhouse、Microsoft、Oracle、Rational Software、TI以及Unisys。

這一機構對UML 1.0(1997年1月)及UML 1.1(1997年11月17日)的定義和發布起了重要的促進作用。UML是一種定義良好、易于表達、功能強大且普遍適用的建模語言。它溶入了軟件工程領域的新思想、新方法和新技術。

它的作用域不限于支持面向對象的分析與設計,還支持從需求分析開始的軟件開發的全過程。

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

在美國,截止1996年10月,UML獲得了工業界、科技界和應用界的廣泛支持,已有700多個公司表示支持采用UML作為建模語言。

1996年底,UML已穩占面向對象技術市場的85%,成為可視化建模語言事實上的工業標準。1997年11月17日,OMG采納UML

1.1作為基于面向對象技術的標準建模語言。UML代表了面向對象方法的軟件開發技術的發展方向,具有巨大的市場前景,也具有重大的經濟價值和國防價值。

2. 標準建模語言UML的內容首先,UML融合了Booch、OMT和OOSE方法中的基本概念,而且這些基本概念與其他面向對象技術中的基本概念大多相同,因而,UML必然成為這些方法以及其他方法的使用者樂于采用的一種簡單一致的建模語言;其次,UML不僅僅是上述方法的簡單匯合,而是在這些方法的基礎上廣泛征求意見,集眾家之長,幾經修改而完成的,UML擴展了現有方法的應用范圍;第三,UML是標準的建模語言,而不是標準的開發過程。

盡管UML的應用必然以系統的開發過程為背景,但由于不同的組織和不同的應用領域,需要采取不同的開發過程。作為一種建模語言,UML的定義包括UML語義和UML表示法兩個部分。

(1) UML語義　描述基于UML的精確元模型定義。元模型為UML的所有元素在語法和語義上提供了簡單、一致、通用的定義性說明,使開發者能在語義上取得一致,消除了因人而異的最佳表達方法所造成的影響。此外UML還支持對元模型的擴展定義。

(2) UML表示法　定義UML符號的表示法,為開發者或開發工具使用這些圖形符號和文本語法為系統建模提供了標準。這些圖形符號和文字所表達的是應用級的模型,在語義上它是UML元模型的實例。

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

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

·第二類是靜態圖(Static diagram),包括類圖、對象圖和包圖。其中類圖描述系統中類的靜態結構。

不僅定義系統中的類,表示類之間的聯系如關聯、依賴、聚合等,也包括類的內部結構(類的屬性和操作)。類圖描述的是一種靜態關系,在系統的整個生命周期都是有效的。對象圖是類圖的實例,幾乎使用與類圖完全相同的標識。他們的不同點在于對象圖顯示類的多個對象實例,而不是實際的類。

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

包由包或類組成,表示包與包之間的關系。包圖用于描述系統的分層結構。

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

其中狀態圖描述類的對象所有可能的狀態以及事件發生時狀態的轉移條件。通常,狀態圖是對類圖的補充。

在實用上并不需要為所有的類畫狀態圖,僅為那些有多個狀態其行為受外界環境的影響并且發生改變的類畫狀態圖。而活動圖描述滿足用例要求所要進行的活動以及活動間的約束關系,有利于識別并行活動。

·第四類是交互圖(Interactive diagram),描述對象間的交互關系。

其中順序圖顯示對象之間的動態合作關系,它強調對象之間消息發送的順序,同時顯示對象之間的交互;合作圖描述對象間的協作關系,合作圖跟順序圖相似,顯示對象間的動態合作關系。

除顯示信息交換外,合作圖還顯示對象以及它們之間的關系。如果強調時間和順序,則使用順序圖;如果強調上下級關系,則選擇合作圖。這兩種圖合稱為交互圖。

·第五類是實現圖( Implementation diagram )。

其中構件圖描述代碼部件的物理結構及各部件之間的依賴關系。

一個部件可能是一個資源代碼部件、一個二進制部件或一個可執行部件。它包含邏輯類或實現類的有關信息。部件圖有助于分析和理解部件之間的相互影響程度。

配置圖定義系統中軟硬件的物理體系結構。

它可以顯示實際的計算機和設備(用節點表示)以及它們之間的連接關系,也可顯示連接的類型及部件之間的依賴性。

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

從應用的角度看,當采用面向對象技術設計系統時,首先是描述需求;其次根據需求建立系統的靜態模型,以構造系統的結構;第三步是描述系統的行為。

其中在第一步與第二步中所建立的模型都是靜態的,包括用例圖、類圖(包含包)、對象圖、組件圖和配置圖等五個圖形,是標準建模語言UML的靜態建模機制。

其中第三步中所建立的模型或者可以執行,或者表示執行時的時序狀態或交互關系。它包括狀態圖、活動圖、順序圖和合作圖等四個圖形,是標準建模語言UML的動態建模機制。

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

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

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

(2) UML還吸取了面向對象技術領域中其他流派的長處,其中也包括非OO方法的影響。

UML符號表示考慮了各種方法的圖形表示,刪掉了大量易引起混亂的、多余的和極少使用的符號,也添加了一些新符號。因此,在UML中匯入了面向對象領域中很多人的思想。

這些思想并不是UML的開發者們發明的,而是開發者們依據最優秀的OO方法和豐富的計算機科學實踐經驗綜合提煉而成的。

(3) UML在演變過程中還提出了一些新的概念。在UML標準中新加了模板(Stereotypes)、職責(Responsibilities)、擴展機制(Extensibility mechanisms)、線程(Threads)、過程(Processes)、分布式(Distribution)、并發(Concurrency)、模式(Patterns)、合作(Collaborations)、活動圖(Activity diagram)等新概念,并清晰地區分類型(Type)、類(Class)和實例(Instance)、細化(Refinement)、接口(Interfaces)和組件(Components)等概念。

因此可以認為,UML是一種先進實用的標準建模語言,但其中某些概念尚待實踐來驗證,UML也必然存在一個進化過程。

4. 標準建模語言UML的應用領域UML的目標是以面向對象圖的方式來描述任何類型的系統,具有很寬的應用領域。其中最常用的是建立軟件系統的模型,但它同樣可以用于描述非軟件領域的系統,如機械系統、企業機構或業務過程,以及處理復雜數據的信息系統、具有實時要求的工業系統或工業過程等。

總之,UML是一個通用的標準建模語言,可以對任何具有靜態結構和動態行為的系統進行建模。此外,UML適用于系統開發過程中從需求規格描述到系統完成后測試的不同階段。在需求分析階段,可以用用例來捕獲用戶需求。

通過用例建模,描述對系統感興趣的外部角色及其對系統(用例)的功能要求。分析階段主要關心問題域中的主要概念(如抽象、類和對象等)和機制,需要識別這些類以及它們相互間的關系,并用UML類圖來描述。為實現用例,類之間需要協作,這可以用UML動態模型來描述。

在分析階段,只對問題域的對象(現實世界的概念)建模,而不考慮定義軟件系統中技術細節的類(如處理用戶接口、數據庫、通訊和并行性等問題的類)。這些技術細節將在設計階段引入,因此設計階段為構造階段提供更詳細的規格說明。

編程(構造)是一個獨立的階段,其任務是用面向對象編程語言將來自設計階段的類轉換成實際的代碼。在用UML建立分析和設計模型時,應盡量避免考慮把模型轉換成某種特定的編程語言。

因為在早期階段,模型僅僅是理解和分析系統結構的工具,過早考慮編碼問題十分不利于建立簡單正確的模型。

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

不同的測試小組使用不同的UML圖作為測試依據:單元測試使用類圖和類規格說明;集成測試使用部件圖和合作圖;系統測試使用用例圖來驗證系統的行為;驗收測試由用戶進行,以驗證系統測試的結果是否滿足在分析階段確定的需求。

總之,標準建模語言UML適用于以面向對象技術來描述任何類型的系統,而且適用于系統開發的不同階段,從需求規格描述直至系統完成后的測試和維護。

　

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

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

UML的靜態建模 機制包括用例圖(Use case diagram)、類圖(Class diagram)、對象圖(Object diagram )、包(Package)、構件圖(Component diagram)和配置圖(Deployment diagram)。

1. 用例圖

(1) 用例模型(Use case model) 長期以來,在面向對象開發和傳統的軟件開發中,人們根據典型的使用情景來了解需 求。

但是,這些使用情景是非正式的,雖然經常使用,卻難以建立正式文擋。用例模型由I var Jacobson在開發AXE系統中首先使用,并加入由他所倡導的OOSE和Objectory方法中。

用例方法引起了面向對象領域的極大關注。自1994年Ivar Jacobson的著作出版后,面向 對象領域已廣泛接納了用例這一概念,并認為它是第二代面向對象技術的標志。

用例模型描述的是外部執行者(Actor)所理解的系統功能。用例模型用于需求分析階 段,它的建立是系統開發者和用戶反復討論的結果,表明了開發者和用戶對需求規格達成 的共識。

首先,它描述了待開發系統的功能需求;

其次,它將系統看作黑盒,從外部執行者 的角度來理解系統;

第三,它驅動了需求分析之后各階段的開發工作,不僅在開發過程中保 證了系統所有功能的實現,而且被用于驗證和檢測所開發的系統,從而影響到開發工作的 各個階段和 UML 的各個模型。

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

(2) 用例(use case) 從本質上講,一個用例是用戶與計算機之間的一次典型交互作用。

以字處理軟件為例 ,"將某些正文置為黑體"和"創建一個索引"便是兩個典型的用例。在UML中,用例被定義成 系統執行的一系列動作,動作執行的結果能被指定執行者察覺到。        

在UML中,用例表示為一個橢圓。

圖1顯示了一個金融貿易系統的用例圖。其中,"風險 分析","交易估價","進行交易","設置邊界","超越邊界的交易","評價貿易","更新帳目 "等都是用例的實例。

概括地說,用例有以下特點:

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

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

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

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

圖1中有四個 執行者:貿易經理、營銷人員、售貨員和記帳系統。在某些組織中很可能有許多營銷人員 ,但就該系統而言,他們均起著同一種作用,扮演著相同的角色,所以用一個執行者表示。

一個用戶也可以扮演多種角色(執行者)。例如,一個高級營銷人員既可以是貿易經理,也 可以是普通的營銷人員;一個營銷人員也可以是售貨員。在處理執行者時,應考慮其作用 ,而不是人或工作名稱,這一點是很重要的。

圖1中,不帶箭頭的線段將執行者與用例連接到一起,表示兩者之間交換信息,稱之為 通信聯系。執行者觸發用例,并與用例進行信息交換。單個執行者可與多個用例聯系;反 過來,一個用例可與多個執行者聯系。對同一個用例而言,不同執行者有著不同的作用:他 們可以從用例中取值,也可以參與到用例中。

需要注意的是,盡管執行者在用例圖中是用類似人的圖形來表示的,但執行者未必是 人。例如,執行者也可以是一個外界系統,該外界系統可能需要從當前系統中獲取信息,與 當前系統有進行交互。在圖1中,我們可以看到,記帳系統是一個外界系統,它需要更新帳 目。

通過實踐,我們發現執行者對提供用例是非常有用的。面對一個大系統,要列出用例 清單常常是十分困難。這時可先列出執行者清單,再對每個執行者列出它的用例,問題就 會變得容易很多。

(4) 使用和擴展(Use and Extend) 圖1中除了包含執行者與用例之間的連接外,還有另外兩種類型的連接,用以表示用例 之間的使用和擴展關系。使用和擴展是兩種不同形式的繼承關系。 當一個用例與另一個用例相似,但所做的動作多一些,就可以用到擴展關系。

例如圖 1中,基本的用例是"進行交易"。 交易中可能一切都進行得很順利,但也可能存在擾亂順 利進行交易的因素。

其中之一便是超出某些邊界值的情況。例如,貿易組織會對某個特定 客戶規定最大貿易量,這時不能執行給定用例提供的常規動作,而要做些改動。我們可在 "進行交易"用例中做改動。但是,這將把該用例與一大堆特殊的判斷和邏輯混雜在一起, 使正常的流程晦澀不堪。

圖1中將常規的動作放在"進行交易"用例中,而將非常規的動作 放置于"超越邊界的交易" 用例中,這便是擴展關系的實質。 當有一大塊相似的動作存在于幾個用例,又不想重復描述該動作時,就可以用到使用 關系。

例如,現實中風險分析和交易估價都需要評價貿易,為此可單獨定義一個用例,即" 評價貿易",而"風險分析"和"交易估價"用例將使用它。 請注意擴展與使用之間的相似點和不同點。它們兩個都意味著從幾個用例中抽取那 些公共的行為并放入一個單獨用例中,而這個用例被其他幾個用例使用或擴展。

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

(5) 用例模型的獲取 幾乎在任何情況下都會使用用例。用例用來獲取需求,規劃和控制項目。

用例的獲取 是需求分析階段的主要任務之一,而且是首先要做的工作。大部分用例將在項目的需求分 析階段產生,并且隨著工作的深入會發現更多的用例,這些都應及時增添到已有的用例集 中。

用例集中的每個用例都是一個潛在的需求。

a. 獲取執行者 獲取用例首先要找出系統的執行者?？梢酝ㄟ^用戶回答一些問題的答案來識別執行 者。

以下問題可供參考:

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

·誰需要系統支持他們的日常工作。

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

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

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

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

b. 獲取用例 一旦獲取了執行者,就可以對每個執行者提出問題以獲取用例。以下問題可供參考:

·執行者要求系統提供哪些功能(執行者需要做什么)?

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

·必須提醒執行者的系統事件有哪些?或者執行者必須提醒系統的事件有哪些?怎樣 把這些事件表示成用例中的功能?

·為了完整地描述用例,還需要知道執行者的某些典型功能能否被系統自動實現? 還有一些不針對具體執行者問題(即針對整個系統的問題):

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

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

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

一個用例必須至少與一個執行者關聯。還需要注意:不同的設計者對用 例的利用程度也不同。例如,Ivar Jacobson說,對一個十人年的項目,他需要二十個用例 。

而在一個相同規模的項目中,Martin Fowler則用了一百多個用例。我們認為:任何合適 的用例都可使用,確定用例的過程是對獲取的用例進行提煉和歸納的過程,對一個十人年 的項目來說,二十個用例似乎太少,一百多個用例則嫌太多,需要保持二者間的相對均衡。

2. 類圖、對象圖和包 數千年以前,人類就已經開始采用分類的方法有效地簡化復雜問題,幫助人們了解客 觀世界。

在面向對象建模技術中,我們使用同樣的方法將客觀世界的實體映射為對象,并 歸納成一個個類。類(Class)、對象(Object)和它們之間的關聯是面向對象技術中最基本 的元素。

對于一個想要描述的系統,其類模型和對象模型揭示了系統的結構。在UML中,類 和對象模型分別由類圖和對象圖表示。

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

          

(1) 類圖 類圖(Class Diagram)描述類和類之間的靜態關系。與數據模型不同,它不僅顯示了 信息的結構,同時還描述了系統的行為。類圖是定義其它圖的基礎。

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

(2) 類和對象 對象(Object)與我們對客觀世界的理解相關。我們通常用對象描述客觀世界中某個 具體的實體。

所謂類(Class)是對一類具有相同特征的對象的描述。而對象是類的實例( Instance)。建立類模型時,我們應盡量與應用領域的概念保持一致,以使模型更符合客觀 事實,易修改、易理解和易交流。

類描述一類對象的屬性(Attribute)和行為(Behavior)。在UML中,類的可視化表示為 一個劃分成三個格子的長方形(下面兩個格子可省略)。

圖1中,"客戶"就是一個典型的類 。 類的獲取和命名　最頂部的格子包含類的名字。

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

類的獲取是一個依 賴于人的創造力的過程,必須與領域專家合作,對研究領域仔細地分析,抽象出領域中的概 念,定義其含義及相互關系,分析出系統類,并用領域中的術語為類命名。一般而言,類的 名字是名詞。 類的屬性　中間的格子包含類的屬性,用以描述該類對象的共同特點。

該項可省略。

圖1中"客戶"類有"客戶名"、"地址"等特性。屬性的選取應考慮以下因素: *原則上來說,類的屬性應能描述并區分每個特定的對象;

*只有系統感興趣的特征才包含在類的屬性中; *系統建模的目的也會影響到屬性的選取。 根據圖的詳細程度,每條屬性可以包括屬性的可見性、屬性名稱、類型、缺省值和約 束特性。

UML規定類的屬性的語法為: 可見性　屬性名 :　類型 = 缺省值　{約束特性} 圖1"客戶"類中,"客戶名"屬性描述為"- 客戶名 : 字符串 = 缺省客戶名"。

可見性 "-"表示它是私有數據成員,其屬性名為"客戶名",類型為"字符串"類型,缺省值為"缺省客 戶名",此處沒有約束特性。

不同屬性具有不同可見性。常用的可見性有Public、Private和Protected三種,在U ML中分別表示為"+"、"-"和"#"。

類型表示該屬性的種類。它可以是基本數據類型,例如整數、實數、布爾型等,也可 以是用戶自定義的類型。一般它由所涉及的程序設計語言確定。

約束特性則是用戶對該屬性性質一個約束的說明。例如"{只讀}"說明該屬性是只讀 屬性。 類的操作(Operation)　該項可省略。操作用于修改、檢索類的屬性或執行某些動作 。

操作通常也被稱為功能,但是它們被約束在類的內部,只能作用到該類的對象上。操作 名、返回類型和參數表組成操作界面。

UML規定操作的語法為: 可見性 操作名 (參數表) : 返回類型 {約束特性} 在圖1中,"客戶"類中有"取客戶地址"操作,其中" +"表示該操作是公有操作,調用時 需要參數"客戶名",參數類型為字符串,返回類型也為字符串。 類圖描述了類和類之間的靜態關系。定義了類之后,就可以定義類之間的各種關系了 。

(3) 關聯關系 關聯(Association)表示兩個類之間存在某種語義上的聯系。例如,一個人為一家公 司工作,一家公司有許多辦公室。我們就認為人和公司、公司和辦公室之間存在某種語義 上的聯系。在分析設計的類圖模型中,則在對應人類和公司類、公司類和辦公室類之間建 立關聯關系。

在圖1中最上部存在一個"屬于"/"簽定"關聯:每個"保險單"屬于一個"客戶",而"客戶 "可以簽定多個"保險單"。除了這個關聯外,圖1中還有另外兩個關聯,分別表示每個"保險 單"包含若干個"保險單上的項目",而每個"保險單上的項目"涉及單一的"保險類別"。 關聯的方向　關聯可以有方向,表示該關聯單方向被使用。關聯上加上箭頭表示方向 ,在UML中稱為導航(Navigability)。我們將只在一個方向上存在導航表示的關聯,稱作單 向關聯 ( Uni-directional Association ),在兩個方向上都有導航表示的關聯,稱作雙 向關聯 ( Bi-directional Association )。

圖1中,"保險單"到"保險單上的項目"是單向 關聯。UML規定,不帶箭頭的關聯可以意味著未知、未確定或者該關聯是雙向關聯三種選 擇,因此,在圖中應明確使用其中的一種選擇。 關聯的命名　既然關聯可以是雙向的,最復雜的命名方法是每個方向上給出一個名字 ,這樣的關聯有兩個名字,可以用小黑三角表示名字的方向(見圖1中最上部的"屬于"/"簽 定"關聯)。為關聯命名有幾種方法,其原則是該命名是否有助于理解該模型。 角色　關聯兩頭的類以某種角色參與關聯。

例如圖2中,"公司"以"雇主"的角色,"人 "以"雇員"的角色參與的"工作合同"關聯。"雇主"和"雇員"稱為角色名。如果在關聯上沒 有標出角色名,則隱含地用類的名稱作為角色名。角色還具有多重性(Multiplicity),表 示可以有多少個對象參與該關聯。在圖2中,雇主(公司)可以雇傭(簽工作合同)多個雇員 ,表示為"*"; 雇員只能與一家雇主簽定工作合同,表示為"1"。

多重性表示參與對象的數 目的上下界限制。"*"代表0～∞,即一個客戶可以沒有保險單,也可以有任意多的保險單 。

"1"是1..1的簡寫,即任何一個保險單僅來自于一個客戶,可以用一個單個數字表示,也 可以用范圍或者是數字和范圍不連續的組合表示。     關聯類　一個關聯可能要記錄一些信息,可以引入一個關聯類來記錄。

圖3是在圖2的 基礎上引入了關聯類。

關聯類通過一根虛線與關聯連接。

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

聚集和組成　聚集(Aggregation)是一種特殊形式的關聯。聚集表示類之間的關系是 整體與部分的關系。一輛轎車包含四個車輪、一個方向盤、一個發動機和一個底盤,這是 聚集的一個例子。在需求分析中,"包含"、"組成"、"分為……部分"等經常設計成聚集關 系。聚集可以進一步劃分成共享聚集(Shared Aggregation)和組成。

例如,課題組包含許 多成員,但是每個成員又可以是另一個課題組的成員,即部分可以參加多個整體,我們稱之 為共享聚集。

另一種情況是整體擁有各部分,部分與整體共存,如整體不存在了,部分也會 隨之消失,這稱為組成(Composition)。例如,我們打開一個視窗口,它就由標題、外框和 顯示區所組成。一旦消亡則各部分同時消失。在UML中,聚集表示為空心菱形,組成表示為 實心菱形。

需要注意的是,一些面向對象大師對聚集的定義并不一樣。大家應注意其他面向對象 方法與UML中所定義的聚集的差別。

(4) 繼承關系 人們將具有共同特性的元素抽象成類別,并通過增加其內涵而進一步分類。

例如,動 物可分為飛鳥和走獸,人可分為男人和女人。在面向對象方法中將前者稱為一般元素、基 類元素或父元素,將后者稱為特殊元素或子元素。繼承(Generalization)定義了一般元素 和特殊元素之間的分類關系。在UML中,繼承表示為一頭為空心三角形的連線。如圖1中, 將客戶進一步分類成個體客戶和團體客戶,使用的就是繼承關系。 在UML定義中對繼承有三個要求:

*特殊元素應與一般元素完全一致,一般元素所具有的關聯、屬性和操作,特殊元素也 都隱含性地具有; *特殊元素還應包含額外信息;

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

(5) 依賴關系 有兩個元素X、Y,如果修改元素X的定義可能會引起對另一個元素Y的定義的修改,則 稱元素Y依賴(Dependency)于元素X。在類中,依賴由各種原因引起,如:一個類向另一個類 發消息;一個類是另一個類的數據成員;一個類是另一個類的某個操作參數。如果一個類 的界面改變,它發出的任何消息可能不再合法。

(6) 類圖的抽象層次和細化(Refinement)關系 需要注意的是,雖然在軟件開發的不同階段都使用類圖,但這些類圖表示了不同層次 的抽象。在需求分析階段,類圖是研究領域的概念;在設計階段,類圖描述類與類之間的接 口;而在實現階段,類圖描述軟件系統中類的實現。按照Steve Cook和John Dianiels的觀 點,類圖分為三個層次。需要說明的是,這個觀點同樣也適合于其他任何模型,只是在類圖 中顯得更為突出。

概念層　概念層(Conceptual)類圖描述應用領域中的概念。實現它們的類可以從這 些概念中得出,但兩者并沒有直接的映射關系。

事實上,一個概念模型應獨立于實現它的 軟件和程序設計語言。 說明層　說明層(Specification)類圖描述軟件的接口部分,而不是軟件的實現部分 。

面向對象開發方法非常重視區別接口與實現之間的差異,但在實際應用中卻常常忽略這 一差異。這主要是因為OO語言中類的概念將接口與實現合在了一起。大多數方法由于受 到語言的影響,也仿效了這一做法?，F在這種情況正在發生變化?？梢杂靡粋€類型(Type )描述一個接口,這個接口可能因為實現環境、運行特性或者用戶的不同而具有多種實現 。

實現層　只有在實現層(Implementation)才真正有類的概念,并且揭示軟件的實現部 分。這可能是大多數人最常用的類圖,但在很多時候,說明層的類圖更易于開發者之間的 相互理解和交流。 理解以上層次對于畫類圖和讀懂類圖都是至關重要的。但是由于各層次之間沒有一 個清晰的界限,所以大多數建模者在畫圖時沒能對其加以區分。畫圖時,要從一個清晰的 層次觀念出發;而讀圖時,則要弄清它是根據哪種層次觀念來繪制的。要正確地理解類圖 ,首先應正確地理解上述三種層次。雖然將類圖分成三個層次的觀點并不是UML的組成部 分,但是它們對于建?；蛘咴u價模型非常有用。

盡管迄今為止人們似乎更強調實現層類圖 ,但這三個層次都可應用于UML,而且實際上另外兩個層次的類圖更有用。 下面介紹細化概念。細化是UML中的術語,表示對事物更詳細一層的描述。

兩個元素 A、B描述同一件事物,它們的區別是抽象層次不同,若元素B是在元素A的基礎上的更詳細 的描述,則稱元素B細化了元素A,或稱元素A細化成元素B。細化的圖形表示為由元素B指向 元素A的、一頭為空心三角的虛線(千萬不要把方向顛倒了!)。細化主要用于模型之間的 合作,表示開發各階段不同層次抽象模型的相關性,常用于跟蹤模型的演變。

(7) 約束 在UML中,可以用約束(Constraint)表示規則。約束是放在括號"{ }"中的一個表達式 ,表示一個永真的邏輯陳述。在程序設計語言中,約束可以由斷言(Assertion)來實現。

(8) 對象圖、對象和鏈 UML中對象圖與類圖具有相同的表示形式。對象圖可以看作是類圖的一個實例。對象 是類的實例;對象之間的鏈(Link)是類之間的關聯的實例。對象與類的圖形表示相似,均 為劃分成兩個格子的長方形(下面的格子可省略)。上面的格子是對象名,對象名下有下劃 線;下面的格子記錄屬性值。鏈的圖形表示與關聯相似。對象圖常用于表示復雜的類圖的 一個實例。

(9) 包 一個最古老的軟件方法問題是:怎樣將大系統拆分成小系統。解決這個問題的一個思 路是將許多類集合成一個更高層次的單位,形成一個高內聚、低耦合的類的集合。這個思 路被松散地應用到許多對象技術中。UML中這種分組機制叫包(Package)(見圖5)。       

不僅是類,任何模型元素都運用包的機制。如果沒有任何啟發性原則來指導類的分組 ,分組方法就是任意的。

在UML中,最有用的和強調最多的啟發性原則就是依賴。包圖主要 顯示類的包以及這些包之間的依賴關系。有時還顯示包和包之間的繼承關系和組成關系 。

包的內容　在圖5中,"系統內部"包由"保險單"包和"客戶"包組成。這里稱"保險單" 包和"客戶"包為"系統內部"包的內容。當不需要顯示包的內容時,包的名字放入主方框內 ,否則包的名字放入左上角的小方框中,而將內容放入主方框內。包的內容可以是類的列 表,也可以是另一個包圖,還可以是一個類圖。

包的依賴和繼承　圖5中"保險單填寫界面"包依賴于"保險單"包;整個"系統內部"包 依賴于"數據庫界面"包。

可以使用繼承中通用和特例的概念來說明通用包和專用包之間 的關系。例如,專用包必須符合通用包的界面,與類繼承關系類似。通過"數據庫界面"包 ,"系統內部"包既能夠使用Oracle的界面也可使用Sybase的界面。通用包可標記為 {abs tract},表示該包只是定義了一個界面,具體實現則由專用包來完成。

(10) 其他模型元素和表示機制 類圖中用到的模型元素和表示機制較為豐富,由于篇幅的限制,這里不能一一介紹。

主要還有以下模型符號和概念:類別模板(Stereotype)、界面(Interface)、參數化類(P arameterized Class)也稱模板類(Template)、限定關聯(Qualified Association)、多 維關聯(N-ary Association)、多維鏈(N-ary Link)、派生(Derived)、類型(Type)和注 釋(Note)等。

(11) 使用類圖的幾個建議 類圖幾乎是所有OO方法的支柱。采用標準建模語言UML進行建模時,必須對UML類圖引 入的各種要素有清晰的理解。以下對使用類圖進行建模提出幾點建議:

*不要試圖使用所有的符號。從簡單的開始,例如,類、關聯、屬性和繼承等概念。在 UML中,有些符號僅用于特殊的場合和方法中,只有當需要時才去使用。

*根據項目開發的不同階段,用正確的觀點來畫類圖。如果處于分析階段,應畫概念層 類圖;當開始著手軟件設計時,應畫說明層類圖;當考察某個特定的實現技術時,則應畫實 現層類圖。

*不要為每個事物都畫一個模型,應該把精力放在關鍵的領域。最好只畫幾張較為關 鍵的圖,經常使用并不斷更新修改。 使用類圖的最大危險是過早地陷入實現細節。為了避免這一危險,應該將重點放在概 念層和說明層。如果已經遇到了一些麻煩,可以從以下幾個方面來反思你的模型。

*模型是否真實地反映了研究領域的實際。 *模型和模型中的元素是否有清楚的目的和職責(在面向對象方法中,系統功能最終是 分配到每個類的操作上實現的,這個機制叫職責分配)。

*模型和模型元素的大小是否適中。過于復雜的模型和模型元素是很難生存的,應將 其分解成幾個相互合作的部分。

(12) 術語比較 下表列出了最常用的四種UML術語,并與其他方法學中相對應的術語進行比較,以幫助 讀者了解UML與其他建模語言的異同。   

           

　

　

　

　

　

　

　

　

　

　

3. 構件圖和配置圖 構件圖(Component diagram)和配置圖(Deployment diagram)顯示系統實現時的一些 特性,包括源代碼的靜態結構和運行時刻的實現結構。構件圖顯示代碼本身的結構,配置 圖顯示系統運行時刻的結構。

(1) 構件圖 構件圖顯示軟件構件之間的依賴關系。一般來說,軟件構件就是一個實 際文件,可以是源代碼文件、二進制代碼文件和可執行文件等?？梢杂脕盹@示編譯、鏈接 或執行時構件之間的依賴關系。

(2) 配置圖 配置圖描述系統硬件的物理拓撲結構以及在此結構上執行的軟件。配置 圖可以顯示計算結點的拓撲結構和通信路徑、結點上運行的軟件構件、軟件構件包含的 邏輯單元(對象、類)等。配置圖常常用于幫助理解分布式系統。

(3) 結點和連接　結點(Node)代表一個物理設備以及其上運行的軟件系統,如一臺U nix主機、一個PC終端、一臺打印機、一個傳感器等。如圖1所示,"客戶端PC"和"保險后 臺服務器"就是兩個結點。結點表示為一個立方體,結點名放在左上角。 結點之間的連線表示系統之間進行交互的通信路徑,在UML中被稱為連接(Connectio n)。通信類型則放在連接旁邊的"《》"之間,表示所用的通信協議或網絡類型。

(4) 構件和界面　在配置圖中,構件代表可執行的物理代碼模塊,如一個可執行程序 。邏輯上它可以與類圖中的包或類對應。因此,配置圖中顯示運行時各個包或類在結點中 的分布情況。如在圖1中,"保險后臺服務器" 結點中包含"保險系統"、"保險對象數據庫 "和"保險系統配置"3個構件。 在面向對象方法中,類和構件等元素并不是所有的屬性和操作都對外可見。

它們對外 提供了可見操作和屬性,稱之為類和構件的界面。界面可以表示為一頭是小園圈的直線。

圖1中,"保險系統"構件提供了一個"配置"界面。配置圖中還顯示了構件之間的依賴關系 ,"保險系統配置"構件依賴于這個"配置"界面。

(5) 對象(Object)　一個面向對象軟件系統中可以運行很多對象。由于構件可以看 作與包或類對應的物理代碼模塊,因此,構件中應包含一些運行的對象。配置圖中的對象 與對象圖中的對象表示法一樣。

圖1中,"保險系統配置"構件包含"配置保險政策"和"配置 用戶"兩個對象。

標準建模語言UML的靜態建模機制是采用UML進行建模的基礎。我們認為,熟練掌握基 本概念、區分不同抽象層次以及在實踐中靈活運用,是三條最值得注意的基本原則。

　

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

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

在UML的四個 動態模型中均用到消息這個概念。通常,當一個對象調用另一個對象中的操作時,即完成 了一次消息傳遞。

當操作執行后,控制便返回到調用者。

對象通過相互間的通信(消息傳 遞)進行合作,并在其生命周期中根據通信的結果不斷改變自身的狀態。

　

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

                        

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

簡單消息(Simple Message) 表示簡單的控制流。用于描述控制如何在對象間進行傳 遞,而不考慮通信的細節。

同步消息(Synchronous Message) 表示嵌套的控制流。

操作的調用是一種典型的同 步消息。

調用者發出消息后必須等待消息返回,只有當處理消息的操作執行完畢后,調用 者才可繼續執行自己的操作。

異步消息(Asynchronous Message) 表示異步控制流。

當調用者發出消息后不用等待 消息的返回即可繼續執行自己的操作。

異步消息主要用于描述實時系統中的并發行為。

 

2. 狀態圖 狀態圖(State Diagram)用來描述一個特定對象的所有可能狀態及其引起狀態轉移的 事件。大多數面向對象技術都用狀態圖表示單個對象在其生命周期中的行為。一個狀態 圖包括一系列的狀態以及狀態之間的轉移。

(1) 狀態　所有對象都具有狀態,狀態是對象執行了一系列活動的結果。當某個事件 發生后,對象的狀態將發生變化。

狀態圖中定義的狀態有:初態、終態、中間狀態、復合 狀態。其中,初態是狀態圖的起始點,而終態則是狀態圖的終點。一個狀態圖只能有一個 初態,而終態則可以有多個。

中間狀態包括兩個區域:名字域和內部轉移域,如圖3所示。圖中內部轉移域是可選的 ,其中所列的動作將在對象處于該狀態時執行,且該動作的執行并不改變對象的狀態。                 

一個狀態可以進一步地細化為多個子狀態,我們將可以進一步細化的狀態稱作復合狀 態。子狀態之間有"或關系"和"與關系"兩種關系。

或關系(如 圖4)說明在某一時刻僅可 到達一個子狀態。

例如,一個處于行駛狀態的汽車,在"行駛"這個復合狀態中有向前和向 后兩個不同的子狀態,在某一時刻汽車要么向前,要么向后。與關系( 如圖5)說明復合狀 態中在某一時刻可同時到達多個子狀態(稱為并發子狀態)。具有并發子狀態的狀態圖稱 為并發狀態圖。

                    

(2) 轉移　狀態圖中狀態之間帶箭頭的連線被稱為轉移。狀態的變遷通常是由事件 觸發的,此時應在轉移上標出觸發轉移的事件表達式。如果轉移上未標明事件,則表示在 源狀態的內部活動執行完畢后自動觸發轉移。

3. 順序圖 順序圖(Sequence Diagram)用來描述對象之間動態的交互關系,著重體現對象間消息 傳遞的時間順序。

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

順序圖 中的對象用一個帶有垂直虛線的矩形框表示,并標有對象名和類名。垂直虛線是對象的生 命線,用于表示在某段時間內對象是存在的。對象間的通信通過在對象的生命線間畫消息 來表示。消息的箭頭指明消息的類型。

順序圖中的消息可以是信號(Signal)、操作調用或類似于C++中的RPC(RemoteProce dure Calls)和Java中的RMI(Remote Method Invocation)。當收到消息時,接收對象立即 開始執行活動,即對象被激活了。

通過在對象生命線上顯示一個細長矩形框來表示激活。 消息可以用消息名及參數來標識。

消息也可帶有順序號,但較少使用。消息還可帶有 條件表達式,表示分支或決定是否發送消息。如果用于表示分支,則每個分支是相互排斥 的,即在某一時刻僅可發送分支中的一個消息。

在順序圖的左邊可以有說明信息,用于說明消息發送的時刻、描述動作的執行情況以 及約束信息等。一個典型的例子就是用于說明一個消息是重復發送的。

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

一個對象可以通過發送消息來創建另一個對象,當一個對象被刪除或自我刪除時,該 對象用"X"標識。

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

產生遞歸的消息總是同步消息,返回消息應是一個簡單消息。

4. 合作圖 合作圖(Collaboration Diagram)用于描述相互合作的對象間的交互關系和鏈接關系 。

雖然順序圖和合作圖都用來描述對象間的交互關系,但側重點不一樣。順序圖著重體現 交互的時間順序,合作圖則著重體現交互對象間的靜態鏈接關系。

合作圖中對象的外觀與順序圖中的一樣。如果一個對象在消息的交互中被創建,則可 在對象名稱之后標以{new}。

類似地,如果一個對象在交互期間被刪除,則可在對象名稱之 后標以{destroy}。對象間的鏈接關系類似于類圖中的聯系(但無多重性標志)。通過在對 象間的鏈接上標志帶有消息串的消息(簡單、異步或同步消息)來表達對象間的消息傳遞 。

(1) 鏈接　鏈接用于表示對象間的各種關系,包括組成關系的鏈接(Composition Li nk)、聚集關系的鏈接(Aggregation Link)、限定關系的鏈接(Qualified Link)以及導航 鏈接(Navigation Link)。

各種鏈接關系與類圖中的定義相同,在鏈接的端點位置可以顯 示對象的角色名和模板信息。

(2) 消息流　在合作圖的鏈接線上,可以用帶有消息串的消息來描述對象間的交互。 消息的箭頭指明消息的流動方向。

消息串說明要發送的消息、消息的參數、消息的返回 值以及消息的序列號等信息。

　

 完

　

 

原文轉自：http://www.anti-gravitydesign.com