中科永聯高級技術培訓中心（www.itisedu.com）
一. 標準建模語言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開始致力於這一工作。他們首先將Booch 93和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代表了面向對象方法的軟體開發技術的發展方向，具有巨大的市場前景，也具有重大的經濟價值和國防價值。
二. 標準建模語言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的主要內容也可以歸納為靜態建模機制和動態建模機制兩大類。
UML的組成三. 標準建模語言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也必然存在一個進化過程。
四. 標準建模語言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中有四個 執行者:貿易經理、行銷人員、售貨員和記帳系統。在某些組織中很可能有許多行銷人員 ,但就該系統而言,他們均起著同一種作FONT>
一個用戶也可以扮演多種角色(執行者)。例如,一個高級行銷人員既可以是貿易經理,也 可以是普通的行銷人員;一個行銷人員也可以是售貨員。在處理執行者時,應考慮其作用 ,而不是人或工作名稱,這一點是很重要的。
圖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)定義了?承表示為一頭為空心三角形的連線。如圖1中, 將客戶進一步分類成個體客戶和團體客戶,使用的就是繼承關係。 在UML定義中對繼承有三個要求:
*特殊元素應與一般元素完全一致,一般元素所具有的關聯、屬性和操作,特殊元素也 都隱含性地具有; *特殊元素還應包含額外信息;
*允許使用一般元素實例的地方,也應能使用特殊元素。
(5) 依賴關係 有兩個元素X、Y,如果修改元素X的定義可能會引起對另一個元素Y的定義的修改,則 稱元素Y依賴(Dependency)於元素X。在類中,依賴由各種原因引起,如:一個類向另一個類 發訊息;一個類是另一個類的數據成員;一個類是另一個類的某個操作參數。如果一個類 的界面改變,它發出的任何訊息可能不再合法。
(6) 類圖的抽象層次和細化(Refinement)關係 需要注意的是,雖然在軟體開發的不同階段都使用類圖,但這些類圖表示了不同層次 的抽象。在需求分析階段,類圖是研究領域的概念;在設計階段,類圖描述類與類之間的接 口;而在實現階段,類圖描述軟體系統中類的實現。按照Steve Cook和John Dianiels的觀 點,類圖分為三個層次。需要說明的是,這個觀點同樣也適合於其他任何模型,只是在類圖 中顯得更為突出。
概念層 概念層(Conceptual)類圖描述套用領域中的概念。實現它們的類可以從這 些概念中得出,但兩者並沒有直接的映射關係。
事實上,一個概念模型應獨立於實現它的 軟體和程式設計語言。 說明層 說明層(Specification)類圖描述軟體的接口部分,而不是軟體的實現部分 。
面向對象開發方法非常重視區別接口與實現之間的差異,但在實際套用中卻常常忽略這 一差異。這主要是因為OO語言中類的概念將接口與實現合在了一起。大多數方法由於受 到語言的影響,也仿效了這一做法。現在這種情況正在發生變化。可以用一個類型(Type )描述一個接口,這個接口可能因為實現環境、運行特性或者用戶的不同而具有多種實現 。
實現層 只有在實現層(Implementation)才真正有類的概念,並且揭示軟體的實現部 分。這可能是大多數人最常用的類圖,但在很多時候,說明層的類圖更易於開發者之間的 相互理解和交流。 理解以上層次對於畫類圖和讀懂類圖都是至關重要的。但是由於各層次之間沒有一 個清晰的界限,所以大多數建模者在畫圖時沒能對其加以區分。畫圖時,要從一個清晰的 層次觀念出發;而讀圖時,則要弄清它是根據哪種層次觀念來繪製的。要正確地理解類圖 ,首先應正確地理解上述三種層次。雖然將類圖分成三個層次的觀點並不是UML的組成部 分,但是它們對於建模或者評價模型非常有用。
儘管迄今為止人們似乎更強調實現層類圖 ,但這三個層次都可套用於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) 訊息流 在合作圖的連結線上,可以用帶有訊息串的訊息來描述對象間的互動。 訊息的箭頭指明訊息的流動方向。
訊息串說明要傳送的訊息、訊息的參數、訊息的返回 值以及訊息的序列號等信息。
