面向?qū)ο蠓治雠c設(shè)計(jì) 課件 第2章 統(tǒng)一建模語(yǔ)言概述

第2章統(tǒng)一建模語(yǔ)言概述學(xué)習(xí)目標(biāo)

理解和掌握統(tǒng)一建模語(yǔ)言的基本概念

理解和掌握UML模型的基本結(jié)構(gòu)

理解和掌握UML中的元素、關(guān)系、圖和通用機(jī)制的概念和表示法

理解和掌握對(duì)象約束語(yǔ)言概念的使用方法第1章面向?qū)ο箝_(kāi)發(fā)方法本章的主要內(nèi)容：面向?qū)ο蠓椒ǖ幕靖拍?，及其?nèi)涵與外延。軟件開(kāi)發(fā)方法的發(fā)展過(guò)程和典型的面向?qū)ο箝_(kāi)發(fā)方法。概括性地介紹面向?qū)ο蟮能浖_(kāi)發(fā)過(guò)程，如面向?qū)ο蠓治龊兔嫦驅(qū)ο笤O(shè)計(jì)等。第2章統(tǒng)一建模語(yǔ)言概述任何行業(yè)都有其特定的表示法，用來(lái)表示這個(gè)行業(yè)中的人們創(chuàng)造出的各種制品。在面向?qū)ο蠓椒ㄖ校藗兺ǔＪ褂媒y(tǒng)一建模語(yǔ)言作為標(biāo)準(zhǔn)的表示法，應(yīng)用統(tǒng)一建模語(yǔ)言建模貫穿了軟件開(kāi)發(fā)的全過(guò)程?？梢哉f(shuō)，面向?qū)ο蟮南到y(tǒng)分析與設(shè)計(jì)過(guò)程實(shí)質(zhì)上也就是應(yīng)用統(tǒng)一建模語(yǔ)言對(duì)軟件進(jìn)行建模的過(guò)程。第2章統(tǒng)一建模語(yǔ)言概述90年代中期，Booch、Rumhaugh和Jacobson等人將他們各自的研究成果融合，創(chuàng)建出第一個(gè)版本的統(tǒng)一建模語(yǔ)言（UML，UnifiedModelingLanguage）。1997年11月，OMG把UML宣布為標(biāo)準(zhǔn)的面向?qū)ο蠼ＵZ(yǔ)言。從此，OMG承擔(dān)了UML的組織管理和繼續(xù)開(kāi)發(fā)的責(zé)任。隨后的數(shù)年中，UML曾連續(xù)發(fā)布過(guò)多種不同的版本。目前的最新版本為UML2.5。本教材將主要使用UML2.0作為模型語(yǔ)言，并詳細(xì)介紹其使用方法。第2章統(tǒng)一建模語(yǔ)言概述對(duì)于軟件模型的構(gòu)建者和使用者來(lái)說(shuō)，他們當(dāng)然期望能夠以較高的保真度來(lái)建模要構(gòu)建的軟件系統(tǒng)，但任何一種語(yǔ)言都不可能僅在一張圖紙上就能繪制出一個(gè)復(fù)雜軟件系統(tǒng)的所有細(xì)節(jié)。本章將概要介紹統(tǒng)一建模語(yǔ)言的基本概念、結(jié)構(gòu)和主要構(gòu)成要件，具體的建模方法和建模細(xì)節(jié)將在后續(xù)章節(jié)中陸續(xù)介紹。2.1UML的基本概念2.1.1UML的定義建模是大型軟件項(xiàng)目中必不可少的組成部分，即使是對(duì)中小型項(xiàng)目也很有幫助。圖紙和其它各種計(jì)劃（如站點(diǎn)地圖、海拔高度和物理模型等）在摩天大樓的建造中起著十分重要的作用，模型在軟件開(kāi)發(fā)中也起著類似的作用。對(duì)于軟件項(xiàng)目來(lái)說(shuō)，軟件模型可以保證項(xiàng)目業(yè)務(wù)功能的正確和完整，并使最終用戶的需求得到滿足。不僅如此，軟件模型甚至還可以支持人們通常所要求的諸如軟件的可擴(kuò)展性、可靠性、安全性和可維護(hù)性等方面的質(zhì)量屬性。2.1UML的基本概念2.1.1UML的定義有調(diào)查表明，大型軟件項(xiàng)目有很大的失敗概率。事實(shí)上，大型軟件應(yīng)用程序更可能在預(yù)算和時(shí)間上無(wú)法滿足所有要求。運(yùn)作這樣的軟件項(xiàng)目時(shí)，人們當(dāng)然需要盡可能增加項(xiàng)目成功的幾率，而在大量的項(xiàng)目編碼工作開(kāi)始之前，建模是能夠可視化設(shè)計(jì)和檢查需求的惟一方法。2.1UML的基本概念2.1.1UML的定義對(duì)于統(tǒng)一建模語(yǔ)言，OMG規(guī)范給出了如下的定義。統(tǒng)一建模語(yǔ)言（UML）是一種用于說(shuō)明、構(gòu)造和記錄軟件密集型系統(tǒng)中人工制品（artifacts）的圖形語(yǔ)言。UML提供了一種編寫系統(tǒng)藍(lán)圖（blueprints）的標(biāo)準(zhǔn)方式，它既能描述軟件開(kāi)發(fā)過(guò)程中的業(yè)務(wù)流程、用例和系統(tǒng)功能等概念性的事物，也能夠描述像程序語(yǔ)句、數(shù)據(jù)庫(kù)模式和軟件組件等具體的事物。2.1UML的基本概念2.1.1UML的定義重要的是，OMG將UML定義成一種語(yǔ)言，而不是一種方法或一個(gè)過(guò)程。其主要用途是定義軟件系統(tǒng)、詳細(xì)描述系統(tǒng)中的工件以及記錄文檔和構(gòu)造軟件系統(tǒng)藍(lán)圖。而UML就是用于實(shí)現(xiàn)這些用途或書寫這個(gè)藍(lán)圖的建模語(yǔ)言。UML可以用多種方式支持不同的軟件開(kāi)發(fā)方法學(xué)（如Rational統(tǒng)一過(guò)程），但它本身并不指定具體的方法學(xué)或過(guò)程。2.1UML的基本概念2.1.1UML的定義UML為軟件開(kāi)發(fā)的不同領(lǐng)域或不同過(guò)程定義了不盡相同的符號(hào)和語(yǔ)義。以支持軟件開(kāi)發(fā)的不同領(lǐng)域的建模。這些領(lǐng)域模型包括：用例模型、交互模型、動(dòng)態(tài)模型、邏輯模型、構(gòu)件模型和物理部署模型等。2.1UML的基本概念2.1.1UML的定義1）用例模型（UseCaseModel）用例模型也稱為用戶交互模型，該模型描述了系統(tǒng)的參與者與系統(tǒng)之間的交互，當(dāng)然也描述里系統(tǒng)的邊界。這種模型也對(duì)應(yīng)了需求模型的某些方面。2）交互模型（InteractionModal）交互模型也稱為通訊模型，主要用于描述系統(tǒng)中的對(duì)象之間的交互，以及如何通過(guò)對(duì)象之間的交互以完成特定的系統(tǒng)工作或任務(wù)。2.1UML的基本概念2.1.1UML的定義3）動(dòng)態(tài)模型（DynamicModel）動(dòng)態(tài)模型的內(nèi)容則主要包括兩個(gè)方面，一方面，使用狀態(tài)圖描述系統(tǒng)對(duì)象在某個(gè)時(shí)間段內(nèi)的狀態(tài)及其變化；另一方面，使用活動(dòng)圖描述系統(tǒng)需要完成的工作流。4）邏輯模型（LogicalModel）邏輯模型也稱為類模型（ClassModel），主要用于描述構(gòu)成系統(tǒng)所需要的類以及這些類之間隔關(guān)系，這個(gè)模型描述的是系統(tǒng)的邏輯結(jié)構(gòu)。2.1UML的基本概念2.1.1UML的定義5）構(gòu)件模型（ComponentModel）構(gòu)件模型主要用于描述構(gòu)成系統(tǒng)所需要的軟件構(gòu)件及其相互關(guān)系，它所表示的是軟件系統(tǒng)的物理結(jié)構(gòu)。6）物理部署模型（DeploymentModel）部署模型用于描述系統(tǒng)的物理架構(gòu)（physicalarchitecture）和構(gòu)件在硬件架構(gòu)上的部署情況，它所表示的是整個(gè)系統(tǒng)的物理結(jié)構(gòu)。2.1.2UML的主要特點(diǎn)UML具有如下幾個(gè)方面的特點(diǎn)。1）提高抽象層次UML使開(kāi)發(fā)人員可以在更高的抽象層次上進(jìn)行工作，從而為他們提供幫助。一個(gè)模型可以通過(guò)隱藏或掩蓋細(xì)節(jié)、展現(xiàn)大圖、或者聚焦于原型的不同方面來(lái)實(shí)現(xiàn)這一點(diǎn)。使用UML，可以將應(yīng)用程序的詳細(xì)視圖縮小到它執(zhí)行的環(huán)境中，可視化到其它應(yīng)用程序的連接，或者進(jìn)一步擴(kuò)展到其它站點(diǎn)?；蛘呖梢允谷藗冴P(guān)注應(yīng)用程序的不同側(cè)面，如它自動(dòng)化的業(yè)務(wù)流程或業(yè)務(wù)規(guī)則視圖等。2.1.2UML的主要特點(diǎn)使用UML可以建模任何類型的應(yīng)用軟件，包括運(yùn)行在任何類型硬件及其組合上的、運(yùn)行在不同操作系統(tǒng)環(huán)境下的、使用不同程序設(shè)計(jì)語(yǔ)言實(shí)現(xiàn)的和運(yùn)行在各種網(wǎng)絡(luò)環(huán)境下的應(yīng)用軟件。UML的靈活性使您可以建模使用任何中間件的分布式應(yīng)用程序。由于UML是基本的面向?qū)ο蟮母拍罨A(chǔ)之上的模型語(yǔ)言，它當(dāng)然適用于面向?qū)ο蟮某绦蛟O(shè)計(jì)語(yǔ)言，如C++、Java以及C#等。但它也可以用來(lái)建模非面向?qū)ο蟮膽?yīng)用程序。如FORTRAN、VB或COBOL等。UML中的概要文件（profile，即針對(duì)特定目的而定制的UML子集）可以幫助你以自然的方式建模具有事務(wù)性、實(shí)時(shí)性和容錯(cuò)性系統(tǒng)。2.1.2UML的主要特點(diǎn)2）使用UML做其它有用的事情使用UML也可以做一些軟件建模以外的事情，如分析源代碼，將它反向轉(zhuǎn)換成一組UML類圖。又如，市場(chǎng)上的某些工具也可以運(yùn)行UML模型，這些工具可以分成模型分析器和代碼生成器兩類。模型分析器用于分析UML模型，以幫助用于確認(rèn)模型中不滿足性能需求的部分。代碼生成器的目標(biāo)則是從UML模型生成程序語(yǔ)言代碼，生成無(wú)錯(cuò)誤、運(yùn)行速度快并且可部署的應(yīng)用程序。例如，事務(wù)數(shù)據(jù)庫(kù)操作或其它常見(jiàn)的編程任務(wù)等。（OMG成員正在研究可執(zhí)行UML的規(guī)范）。2.1.2UML的主要特點(diǎn)3）UML和OMG的模型驅(qū)動(dòng)體系結(jié)構(gòu)憑借中間件的獨(dú)立性，UML形成了OMG的模型驅(qū)動(dòng)體系結(jié)構(gòu)包（MDA，ModelDrivenArchitecture）的基礎(chǔ)。這使得UML模型可以是平臺(tái)獨(dú)立（PIM，Platform-independent）的也可以是平臺(tái)相關(guān)的（PSM，Platform-specfic）的，MDA開(kāi)發(fā)過(guò)程支持兩種模型的使用。憑借中間件的獨(dú)立性，UML形成了OMG的模型驅(qū)動(dòng)體系結(jié)構(gòu)包（MDA，ModelDrivenArchitecture）的基礎(chǔ)。這使得UML模型可以是平臺(tái)獨(dú)立（PIM，Platform-independent）的也可以是平臺(tái)相關(guān)的（PSM，Platform-specfic）的，MDA開(kāi)發(fā)過(guò)程支持兩種模型的使用。2.1.2UML的主要特點(diǎn)3）UML和OMG的模型驅(qū)動(dòng)體系結(jié)構(gòu)標(biāo)準(zhǔn)情況下，每個(gè)MDA標(biāo)準(zhǔn)或應(yīng)用均是基于平臺(tái)獨(dú)立模型（PIM）的，這意味著其業(yè)務(wù)功能和行為可以非常精確但不包括技術(shù)方面。從平臺(tái)獨(dú)立模型（PIM），MDA開(kāi)發(fā)工具遵循OMG規(guī)范啟用映射來(lái)產(chǎn)生一個(gè)或多個(gè)平臺(tái)相關(guān)模型（PSM）。這個(gè)轉(zhuǎn)換步驟是高度自動(dòng)化的，在工具生成平臺(tái)相關(guān)模型（PSM）之前，開(kāi)發(fā)人員必須對(duì)基本的平臺(tái)獨(dú)立模型（PIM）進(jìn)行注釋，以生成一個(gè)更具體但仍與平臺(tái)無(wú)關(guān)的模型，其中包含所需語(yǔ)義的詳細(xì)信息，并指導(dǎo)工具不得不做出的選擇。由于特定類型的中間件平臺(tái)之間的相似性，例如對(duì)于基于組件的或基于消息的中間件平臺(tái)，這種指導(dǎo)可以被包含在平臺(tái)獨(dú)立的模型（PIM）中而不提供特定于平臺(tái)的特性。進(jìn)一步，開(kāi)發(fā)人員將不得不在一定程度上調(diào)整（fine-tune）產(chǎn)生的平臺(tái)相關(guān)模型（PSM），這樣的調(diào)整對(duì)與早期的MDA較多，但隨著工具和算法的進(jìn)步則變得越來(lái)越少了。2.1.2UML的主要特點(diǎn)3）UML和OMG的模型驅(qū)動(dòng)體系結(jié)構(gòu)平臺(tái)相關(guān)模型（PSM）雖然包含了與實(shí)現(xiàn)相關(guān)的信息，但UML模型并不能代替運(yùn)行代碼。在下一步中，工具可以從平臺(tái)相關(guān)模型（PSM）生成可運(yùn)行的代碼及其它必要的文件（包括必要的接口定義文件、配置文件、生成文件和其它類型的文件）。在給開(kāi)發(fā)人員一次手工調(diào)整代碼的機(jī)會(huì)之后，該工具可以執(zhí)行makefile生成和部署最終應(yīng)用。2.1.2UML的主要特點(diǎn)3）UML和OMG的模型驅(qū)動(dòng)體系結(jié)構(gòu)MDA應(yīng)用也是可以組合的，如果向開(kāi)發(fā)工具中引進(jìn)平臺(tái)獨(dú)立模型（PIM）、服務(wù)、或其它MDA應(yīng)用，則可以使用任何必要的接口和協(xié)議直接調(diào)用，即使跨平臺(tái)運(yùn)行。并且，MDA應(yīng)用程序的未來(lái)可以證明：當(dāng)一個(gè)新的產(chǎn)品上市時(shí)，OMG成員將生成并標(biāo)準(zhǔn)化它的映射，并且供應(yīng)商將升級(jí)其MDA工具以包含它。利用這些發(fā)展的優(yōu)勢(shì)，你將能夠產(chǎn)生對(duì)新平臺(tái)的跨平臺(tái)調(diào)用，甚至將現(xiàn)有的MDA應(yīng)用連接到這個(gè)新的平臺(tái)，從而自動(dòng)使用現(xiàn)有的資源。2.1.3如何使用UMLUML通常被作為軟件開(kāi)發(fā)過(guò)程的一個(gè)組成部分。在軟件開(kāi)發(fā)過(guò)程中，可以使用適當(dāng)?shù)腃ASE工具來(lái)定義目標(biāo)系統(tǒng)中的需求、交互和各種元素。下面，我們給出一個(gè)比較常見(jiàn)的開(kāi)發(fā)過(guò)程。1）建模系統(tǒng)的業(yè)務(wù)流程業(yè)務(wù)流程模型可用于定義業(yè)務(wù)系統(tǒng)中發(fā)生的高層次的業(yè)務(wù)活動(dòng)和流程，并為用例模型提供基礎(chǔ)。通常情況下，業(yè)務(wù)流程模型捕獲的內(nèi)容往往多于目標(biāo)軟件系統(tǒng)將要實(shí)現(xiàn)的內(nèi)容，例如業(yè)務(wù)流程模型中可能會(huì)包括人手工的處理或其它的處理等。業(yè)務(wù)建?？梢杂行У卮_定和控制系統(tǒng)的目標(biāo)和范圍，從而避免需求不足或過(guò)分的情況發(fā)生。2.1.3如何使用UML2）建立用例模型，并明確用例模型到業(yè)務(wù)模型之間的鏈接建立用例模型可以確切地定義系統(tǒng)應(yīng)提供的功能，還需要進(jìn)一步明確這些功能所實(shí)現(xiàn)的業(yè)務(wù)需求。當(dāng)添加一個(gè)用例時(shí)，都要?jiǎng)?chuàng)建一個(gè)從適當(dāng)?shù)臉I(yè)務(wù)流程到這個(gè)用例的可追溯的鏈接。這個(gè)鏈接可清楚地說(shuō)明新系統(tǒng)提供的功能滿足了業(yè)務(wù)流程模型中描述的哪一項(xiàng)業(yè)務(wù)需求。它還可以確保用例模型中的每一個(gè)用例都是符合明確的業(yè)務(wù)需求。2.1.3如何使用UML3）細(xì)化用例——包括每個(gè)用例的需求、約束、復(fù)雜度、注釋和場(chǎng)景用例細(xì)化準(zhǔn)確地描述了用例的作用、執(zhí)行方式以及執(zhí)行時(shí)需要遵守的約束。確保用例能夠滿足業(yè)務(wù)流程需求。包括定義每個(gè)用例的系統(tǒng)測(cè)試以及每個(gè)用例的合格標(biāo)準(zhǔn)。還包括定義一些用戶驗(yàn)收測(cè)試腳本，還要定義用戶將如何測(cè)試這個(gè)功能及其驗(yàn)收標(biāo)準(zhǔn)。2.1.3如何使用UML4）構(gòu)建系統(tǒng)的業(yè)務(wù)對(duì)象模型、順序圖、通訊圖和用戶界面等模型從業(yè)務(wù)流程模型的輸入和輸出以及用例的細(xì)節(jié)出發(fā)，開(kāi)始構(gòu)建系統(tǒng)的領(lǐng)域模型（即高層業(yè)務(wù)對(duì)象模型）、順序圖、通訊圖和用戶界面模型。這些模型描述了新系統(tǒng)中的構(gòu)成元素、這些元素交互的方式以及用戶執(zhí)行用例場(chǎng)景所使用的接口。2.1.3如何使用UML5）從領(lǐng)域模型、用戶界面模型和場(chǎng)景圖（Scenariosdiagram）創(chuàng)建系統(tǒng)的類模型類模型是系統(tǒng)中對(duì)象以及對(duì)象的行為和屬性的精確描述（specification）。建模時(shí)，可以使用繼承和聚合將模型中的類抽象為類（或?qū)ο螅┑膶哟谓Y(jié)構(gòu)，將場(chǎng)景圖中的消息映射到類中的操作。對(duì)于每個(gè)類，還可以定義單元測(cè)試和集成測(cè)試以測(cè)試類的功能以及類與其相關(guān)類和組件的之間的交互。2.1.3如何使用UML6）構(gòu)件模型建模隨著建模過(guò)程的繼續(xù)，類模型還有可能被分解成一些離散的包和組件。組件表示一個(gè)可部署的軟件塊，它收集一個(gè)或多個(gè)類的行為和數(shù)據(jù)，并向其服務(wù)的其它用戶公開(kāi)嚴(yán)格的接口。因此，建立組件模型可以定義類的邏輯包裝。還可以為每個(gè)組件定義集成測(cè)試可以確定組件的接口是否滿足規(guī)范或與其它軟件元素的關(guān)系了。2.1.3如何使用UML7）記錄額外需求與開(kāi)發(fā)過(guò)程同步，額外的系統(tǒng)需求也應(yīng)該被捕獲并記錄下來(lái)。例如，系統(tǒng)的非功能需求、性能要求、安全性要求、職責(zé)、發(fā)布計(jì)劃等。在模型中收集這些信息，并隨著模型的成熟而不斷更新。2.1.3如何使用UML8）建立部署模型部署模型定義了系統(tǒng)的物理體系結(jié)構(gòu)。這項(xiàng)工作可以提前開(kāi)始，捕捉物理部署的特點(diǎn)是硬件、操作系統(tǒng)、網(wǎng)絡(luò)功能、接口和支持軟件將構(gòu)成新的系統(tǒng)，它將部署和所使用的參數(shù)的可靠性、災(zāi)難恢復(fù)、備份與支持。隨著模型的開(kāi)發(fā)，物理架構(gòu)將被更新，以反映實(shí)際系統(tǒng)正在被提議。2.1.3如何使用UML9）將模型的離散部分分配給一個(gè)或多個(gè)開(kāi)發(fā)人員，以構(gòu)建整個(gè)系統(tǒng)在用例驅(qū)動(dòng)的開(kāi)發(fā)方法中，這意味著向開(kāi)發(fā)團(tuán)隊(duì)分配用例，讓他們構(gòu)建用于執(zhí)行該用例所需的邊界對(duì)象、業(yè)務(wù)邏輯對(duì)象、數(shù)據(jù)庫(kù)表和相關(guān)組件。當(dāng)每個(gè)用例被構(gòu)建完成之后，應(yīng)該伴隨完成的內(nèi)容應(yīng)包括構(gòu)成單元、集成測(cè)試和系統(tǒng)測(cè)試。組件驅(qū)動(dòng)的開(kāi)發(fā)可以得到的是分配給開(kāi)發(fā)團(tuán)隊(duì)的離散軟件組件。2.1.3如何使用UML10）跟蹤測(cè)試中出現(xiàn)的缺陷如系統(tǒng)測(cè)試缺陷所針對(duì)的模型元素通常是對(duì)應(yīng)的用例，單元測(cè)試缺陷針對(duì)的模型元素可能是類等。跟蹤相關(guān)模型元素的任何變更以便管理項(xiàng)目中可能出現(xiàn)的“范圍蠕變”。11）隨著工作進(jìn)展不斷更新和完善模型開(kāi)發(fā)過(guò)程中，不斷評(píng)估變更和模型改進(jìn)對(duì)后續(xù)工作的影響。使用迭代方法完成在離散塊中進(jìn)行的設(shè)計(jì)，總是評(píng)估當(dāng)前的構(gòu)建、下一步的需求和在開(kāi)發(fā)過(guò)程的任何發(fā)現(xiàn)。12）提交經(jīng)過(guò)測(cè)試的軟件，生成產(chǎn)品環(huán)境對(duì)于分階段交付的項(xiàng)目來(lái)說(shuō)，提交可能會(huì)多次進(jìn)行。2.1.3如何使用UML10）跟蹤測(cè)試中出現(xiàn)的缺陷如系統(tǒng)測(cè)試缺陷所針對(duì)的模型元素通常是對(duì)應(yīng)的用例，單元測(cè)試缺陷針對(duì)的模型元素可能是類等。跟蹤相關(guān)模型元素的任何變更以便管理項(xiàng)目中可能出現(xiàn)的“范圍蠕變”。11）隨著工作進(jìn)展不斷更新和完善模型開(kāi)發(fā)過(guò)程中，不斷評(píng)估變更和模型改進(jìn)對(duì)后續(xù)工作的影響。使用迭代方法完成在離散塊中進(jìn)行的設(shè)計(jì)，總是評(píng)估當(dāng)前的構(gòu)建、下一步的需求和在開(kāi)發(fā)過(guò)程的任何發(fā)現(xiàn)。2.1.3如何使用UML12）提交經(jīng)過(guò)測(cè)試的軟件，生成產(chǎn)品環(huán)境對(duì)于分階段交付的項(xiàng)目來(lái)說(shuō)，提交可能會(huì)多次進(jìn)行。上述過(guò)程只是一個(gè)概括性的過(guò)程，實(shí)際的開(kāi)發(fā)過(guò)程可能會(huì)有所不同，但這個(gè)描述僅僅說(shuō)明一個(gè)應(yīng)用UML開(kāi)發(fā)軟件的基本過(guò)程。2.2UML模型的基本結(jié)構(gòu)作為一種模型語(yǔ)言，UML主要由三種基本要素構(gòu)成，它們分別是UML基本構(gòu)造塊、構(gòu)造塊的組織規(guī)則和運(yùn)用于整個(gè)語(yǔ)言的公用機(jī)制。2.2.1UML基本構(gòu)造塊1.設(shè)施（Infrastructure）設(shè)施是對(duì)UML模型中最具有代表性的語(yǔ)法成分的抽象，UML定義了結(jié)構(gòu)、行為、分組和注釋（Note）等四種設(shè)施。結(jié)構(gòu)設(shè)施通常包括類（Class）、接口（Interface）、協(xié)作（Collaboration）、用例（UseCase）、主動(dòng)類（ActiveClass）、組件（Component）和結(jié)點(diǎn)（Node）等；行為設(shè)施則包括交互（Interaction）和狀態(tài)機(jī)（Statemachine）等分組設(shè)施用于對(duì)模型元素分組，UML主要是用包(package)來(lái)實(shí)現(xiàn)分組機(jī)制。注釋設(shè)施用于為模型提供一個(gè)基于文本的注釋（注解，Note）。2.2.1UML基本構(gòu)造塊2.關(guān)系（Relationship）這里的關(guān)系主要指模型中各種設(shè)施之間的關(guān)系，用于將設(shè)施結(jié)合在一起，以組成更高一層的設(shè)施。UML主要定義了四種關(guān)系依賴（dependency）關(guān)聯(lián)（association）泛化（generalization）實(shí)現(xiàn)（implementation）2.2.1UML基本構(gòu)造塊3.圖（Diagram）圖（Diagram）可以看成是模型中某些模型元素及其相互關(guān)系的圖形表示，每一張圖都是由以表示模型元素的圖形符號(hào)為結(jié)點(diǎn)，圖形元素之間的連接關(guān)系為邊構(gòu)成的圖。2.2.2構(gòu)造塊的組織規(guī)則一個(gè)完整的UML模型通常由一組模型元素組成的，模型中的所有元素通過(guò)視圖(View)和包（package）的形式構(gòu)成了一個(gè)具有層次結(jié)構(gòu)的元素集合。一個(gè)UML模型首先被分解成若干個(gè)視圖，每個(gè)視圖還可以分解成若干個(gè)包組成的嵌套結(jié)構(gòu)，這些包也可以進(jìn)一步分解成若干個(gè)包。每個(gè)包都可以由若干個(gè)模型元素構(gòu)成。2.2.2構(gòu)造塊的組織規(guī)則視圖(View)用于描述目標(biāo)系統(tǒng)在某一方面的特征，是在某種抽象層次或側(cè)面上對(duì)系統(tǒng)的抽象表示。每張圖（diagram）都需要存放在某個(gè)特定的包中。圖與視圖之間存在著某種對(duì)應(yīng)關(guān)系。某些圖一般只存放在特定的視圖中。模型元素(ModelElement)是對(duì)對(duì)象模型類、對(duì)象、消息和關(guān)系等概念模型語(yǔ)言描述，是構(gòu)成模型的基本要素。它既是構(gòu)成模型的實(shí)體要素，也是目標(biāo)系統(tǒng)中某個(gè)程序?qū)嶓w的模型表示。2.2.3通用機(jī)制通用機(jī)制(GeneralMechanism)用于表示模型元素相關(guān)的信息或附加信息，如元素規(guī)約（specifaction）、構(gòu)造型（stereotype）、修飾符(modifier)、約束（constraint）和注釋（Note）等。其中，UML提供的構(gòu)造型（stereotype）等擴(kuò)展機(jī)制，使UML語(yǔ)言能夠有效地適應(yīng)特殊的方法（或過(guò)程），或擴(kuò)充至一個(gè)組織或用戶。2.2.3通用機(jī)制通用機(jī)制(GeneralMechanism)用于表示模型元素相關(guān)的信息或附加信息，如元素規(guī)約（specifaction）、構(gòu)造型（stereotype）、修飾符(modifier)、約束（constraint）和注釋（Note）等。其中，UML提供的構(gòu)造型（stereotype）等擴(kuò)展機(jī)制，使UML語(yǔ)言能夠有效地適應(yīng)特殊的方法（或過(guò)程），或擴(kuò)充至一個(gè)組織或用戶。圖2-1UML模型的基本結(jié)構(gòu)2.2.4視圖為了簡(jiǎn)明、準(zhǔn)確、清晰地表達(dá)一個(gè)完整的軟件模型，UML定義了多種不同的模型或視圖，以便使建模人員可以從不同的視角對(duì)軟件進(jìn)行建模。為了描述軟件開(kāi)發(fā)過(guò)程中使用的各種領(lǐng)域模型，UML中定義了五種基本視圖來(lái)描述一個(gè)完整的軟件系統(tǒng)結(jié)構(gòu)。這些視圖包括用例視圖（UseCaseView）、邏輯視圖（LogicalView）、動(dòng)態(tài)視圖（DynamicView）、構(gòu)件視圖（ComponentView）和部署視圖（DeploymentView）等五種基本視圖。2.2.4視圖另外，UML還定義了業(yè)務(wù)過(guò)程模型（TheBusinessProcessModel）、需求模型（RequirementModel）和測(cè)試模型（TestingModel）等其它多種不同用途的軟件模型。其中，五種基本視圖具有重要的核心作用，它將其它各種視圖有機(jī)地連接到一起，共同構(gòu)成完整的軟件模型。圖中的五個(gè)視圖并不直接對(duì)應(yīng)于一個(gè)特定的軟件模型的邏輯結(jié)構(gòu)，也不直接對(duì)應(yīng)于軟件的物理結(jié)構(gòu)，其劃分的意義在于每個(gè)視圖對(duì)應(yīng)的是一種特定的研究系統(tǒng)的觀點(diǎn)。不同的視圖突出的是特定的人員所關(guān)注的系統(tǒng)的不同方面，通過(guò)合并所有五個(gè)視圖中得到的信息就可以形成系統(tǒng)的完整描述。當(dāng)然，對(duì)于某些特殊的領(lǐng)域或過(guò)程，可能只考慮某一個(gè)視圖或某幾個(gè)視圖中包含的信息可能就足夠了。2.2.4視圖1.用例視圖(Usecaseview)用例視圖主要用于定義系統(tǒng)的外部行為，是最終用戶、分析人員和測(cè)試人員所關(guān)心的視圖。用例視圖的主要內(nèi)容包括參與者、用例以及它們之間的關(guān)系。其具體內(nèi)容還可以包括從用例導(dǎo)出的類、為描述用例或場(chǎng)景所建立的活動(dòng)圖、通訊圖和狀態(tài)圖等?？傊?，用例視圖描述了系統(tǒng)的用戶需求，因此也約束了描述系統(tǒng)設(shè)計(jì)和構(gòu)造的所有其它視圖。因此，在用例驅(qū)動(dòng)的開(kāi)發(fā)方法中，用例視圖在UML占據(jù)了模型中最重要中心位置。2.2.4視圖2.邏輯視圖(Logicalview)邏輯視圖也稱為類視圖，主要用于描述構(gòu)成系統(tǒng)所需要的類或?qū)ο?，其具體內(nèi)容包括類、類所持有的數(shù)據(jù)、類的行為以及類之間交互的說(shuō)明組成。這個(gè)視圖中的信息是程序員特別關(guān)心的，如何實(shí)現(xiàn)系統(tǒng)功能所需要的細(xì)節(jié)都將在這個(gè)視圖中描述和展現(xiàn)。3.動(dòng)態(tài)視圖（DynamicView）動(dòng)態(tài)視圖合并了前面描述的動(dòng)態(tài)模型（DynamicModal）和交互模型(InteractionModal),用于描述系統(tǒng)中的過(guò)程或線程，重點(diǎn)關(guān)注系統(tǒng)的非功能性需求。行為視圖通常由順序圖、通訊圖、狀態(tài)圖和活動(dòng)圖等組成。2.2.4視圖4.構(gòu)件視圖（ComponentView）構(gòu)件視圖用于描述構(gòu)造系統(tǒng)的物理構(gòu)件。這些構(gòu)件不同于邏輯視圖中描述的邏輯構(gòu)件，這些構(gòu)件包括如可執(zhí)行文件、代碼庫(kù)和數(shù)據(jù)庫(kù)等內(nèi)容。這個(gè)視圖中包含的信息與配置管理和系統(tǒng)集成這類活動(dòng)有關(guān)。5.部署視圖(Deploymentview)描述系統(tǒng)的物理結(jié)構(gòu)以及構(gòu)件如何在系統(tǒng)運(yùn)行的實(shí)際環(huán)境中分布。這兩個(gè)視圖處理的是系統(tǒng)的非功能性需求，例如容錯(cuò)性和性能等問(wèn)題。動(dòng)態(tài)視圖和部署視圖在UML中相對(duì)地未充分開(kāi)發(fā)，尤其是與邏輯視圖相比。在邏輯視圖中包含了大量非正式地被當(dāng)作是與設(shè)計(jì)有關(guān)的符號(hào)。2.2.4視圖6.其它視圖除了上述五種視圖以外，UML2.0以后的版本還定義了其它一些可選的視圖。這些視圖源于不同的建模方法或開(kāi)發(fā)方法，當(dāng)使用不同的開(kāi)發(fā)方法，或?qū)ML用于某中特定的目的時(shí)，可選擇與之對(duì)應(yīng)的視圖模型。這些模型包括業(yè)務(wù)過(guò)程模型（TheBusinessProcessModel）、需求模型(RequirementsModel)、領(lǐng)域模型（DomainModel）、測(cè)試模型(TestModel)、和分析視圖(AnalysisView)等多種不同的視圖。2.3模型元素UML中定義的包含某種特定語(yǔ)義的元素都是模型元素。UML中定義了很多模型元素，用來(lái)表達(dá)對(duì)象模型框架中的各種概念。例如類、對(duì)象、屬性、操作和消息等模型元素。模型元素通常被作為圖的組成部分，任何一個(gè)圖都是有多個(gè)模型元素組成的。而且，同一個(gè)模型元素也可以出現(xiàn)在多個(gè)不同類型的圖中，當(dāng)然，模型元素是否可以出現(xiàn)以及用什么方式出現(xiàn)需要遵循一定的UML規(guī)則。由于模型元素的數(shù)量較多而且種類也比較復(fù)雜，所以有必要為其做進(jìn)一步的分類。UML將模型元素劃分為實(shí)體、交互、分組和注釋等四大類。2.3模型元素1．實(shí)體（entity）元素實(shí)體元素是指UML中用來(lái)描述上下文中具有明確建模意義的概念或者實(shí)體元素，這些元素將被映射成目標(biāo)系統(tǒng)中的實(shí)體對(duì)象。常見(jiàn)的實(shí)體元素通常包括類、接口、協(xié)作、用例、構(gòu)件和結(jié)點(diǎn)等六種元素。這些元素均屬于UML的靜態(tài)元素。2．交互（interaction）元素交互元素用于描述對(duì)象和對(duì)象之間的交互，對(duì)象間的交互通常指對(duì)象之間交換的消息。對(duì)象之間的消息可分成同步消息、異步消息和消息等模型元素。2.3模型元素3．組織（orgnzation）元素指UML中用于表示模型組織結(jié)構(gòu)的模型元素。UML模型中，最主要的組織元素就是指視圖和包等元素。就像前面介紹過(guò)的，視圖既是一種由建模工具軟件按照其特定標(biāo)準(zhǔn)預(yù)先定義的結(jié)構(gòu)機(jī)制，它們本身也是一種包，只不過(guò)普通用戶不能隨意改變。包則是一種用戶可隨意設(shè)定的一種元素分組機(jī)制。邏輯上，包可被視為是一組模型元素構(gòu)成的集合，并且包還可以包含其它的包。2.3模型元素4．注釋（comment）元素用于描述和標(biāo)注任何模型的模型元素，注釋元素里面的信息以文本方式描述，并且是面向人的。2.4關(guān)系在面向?qū)ο蟾拍羁蚣苤?，最值得關(guān)注關(guān)系可以分為的對(duì)象之間關(guān)系和類之間的關(guān)系兩大類。對(duì)象之間的關(guān)系包括依賴、鏈接、聚合和組合等四種關(guān)系，UML中使用類圖來(lái)描述對(duì)象之間的這些關(guān)系。類之間的關(guān)系則主要是指繼承關(guān)系。UML中定義的這些關(guān)系不僅用于描述對(duì)象和類之間的類，而且把這些關(guān)系推廣到各種模型元素之間，從而使這些關(guān)系具有廣泛的含義。圖2-11列出了UML中依賴、關(guān)聯(lián)、聚合、組合、繼承和實(shí)現(xiàn)等關(guān)系的符號(hào)表示。2.4.1依賴關(guān)系（dependent）UML中，依賴用來(lái)表示兩個(gè)模型元素（如類、用例等）之間存在的某種語(yǔ)義關(guān)系。對(duì)于兩個(gè)模型元素來(lái)說(shuō)，如果一個(gè)模型元素的改變將影響另一個(gè)模型元素，那么就說(shuō)，這兩個(gè)模型元素之間存在著某種依賴關(guān)系。例如：一個(gè)類使用另一個(gè)類的對(duì)象作為操作的參數(shù)，一個(gè)類使用另一個(gè)類的對(duì)象作為它的屬性，一個(gè)類的對(duì)象向另一個(gè)類的對(duì)象發(fā)送消息等，這樣的兩個(gè)類之間都存在著一定的依賴關(guān)系。2.4.1依賴關(guān)系（dependent）依賴關(guān)系一方面表示了對(duì)象之間的某種協(xié)作，這種協(xié)作顯然是構(gòu)建一個(gè)系統(tǒng)所不可缺少的；另一方面依賴也反映了系統(tǒng)元素之間的耦合，這又要求系統(tǒng)中的依賴關(guān)系也必須是可控的。UML使用帶有箭頭的虛線表示依賴。圖2-12給出了兩個(gè)類之間的依賴。圖中類A依賴類B，即類B內(nèi)容的改變將引起A中相應(yīng)內(nèi)容的改變。圖2-12依賴關(guān)系2.4.1依賴關(guān)系（dependent）依賴關(guān)系不僅存在于各個(gè)類之間，很多其它模型元素之間也存在著各種各樣的依賴關(guān)系，如構(gòu)件之間的依賴以及包的依賴等，不同的元素之間的依賴關(guān)系表示的含義是不同的。其它依賴關(guān)系將在后面章節(jié)中陸續(xù)介紹。2.4.2關(guān)聯(lián)關(guān)系（Assosiation）關(guān)聯(lián)關(guān)系是一種存在于模型元素之間的結(jié)構(gòu)性的關(guān)系，指的是一種模型元素和另一種模型元素之間的語(yǔ)義聯(lián)系。對(duì)于對(duì)象（或類）來(lái)說(shuō)，關(guān)聯(lián)意味著在一個(gè)對(duì)象（或類）內(nèi)部的任何地方均可以訪問(wèn)到與之相關(guān)聯(lián)的另一個(gè)對(duì)象（或類）的全部服務(wù)。關(guān)聯(lián)關(guān)系可以是單向也可以是雙向的，單向關(guān)聯(lián)表示對(duì)象之間的訪問(wèn)是單向的關(guān)聯(lián)，雙向關(guān)聯(lián)表示對(duì)象之間的關(guān)聯(lián)可以是雙向的關(guān)聯(lián)。與關(guān)聯(lián)相關(guān)的概念還有關(guān)聯(lián)的名字、角色、多重性、關(guān)聯(lián)限定符和關(guān)聯(lián)類等概念。這些細(xì)節(jié)將在類圖建模部分詳細(xì)介紹。2.4.2關(guān)聯(lián)關(guān)系（Assosiation）圖2-13給出了這單向關(guān)聯(lián)和雙相關(guān)聯(lián)的符號(hào)表示。

圖2-13關(guān)聯(lián)的圖形符號(hào)表示2.4.3組合與聚合

（CompositionandAggregation）

關(guān)聯(lián)關(guān)系中，如果在兩個(gè)關(guān)聯(lián)對(duì)象之間，還具有整體與部分之間的關(guān)系時(shí)，即一個(gè)對(duì)象是另一個(gè)對(duì)象的組成部分時(shí)，則稱這種關(guān)系為聚合(aggregation)關(guān)系。

如果整體對(duì)象與部分對(duì)象還具有相同的生存期，則把這個(gè)聚合關(guān)系稱為組合(composition)關(guān)系。圖2-14對(duì)象之間的組合與聚合2.4.3組合與聚合

（CompositionandAggregation）例如，圖2-14給出了對(duì)象之間的組合和聚合關(guān)系的例子。聚合一般代表邏輯上的包含，當(dāng)然包括物理上的包含，而組合則代表了物理意義上的包含。如圖2-14a表示了飛機(jī)與機(jī)翼、機(jī)身、引擎和起落架等各種對(duì)象之間的組合關(guān)系。而圖2-14b表示了股票持有人與其持有的股票之間的關(guān)系則是一種聚合關(guān)系。圖2-14對(duì)象之間的組合與聚合2.4.4繼承（Inherit）繼承關(guān)系（Inherit）也稱為泛化或特化關(guān)系，是模型元素之間的一種強(qiáng)耦合的關(guān)系。對(duì)于兩個(gè)類來(lái)說(shuō)，如果一個(gè)類擁有另一個(gè)類的所有屬性和方法，同時(shí)前者還可以擁有自己特殊的屬性和方法，并且還可以修改或重新定義后者的方法。則稱這兩個(gè)類之間存在泛化關(guān)系。稱前者為派生類或子類，后者為基類或父類。繼承的表示非常簡(jiǎn)單，UML使用一個(gè)帶有三角形箭頭的實(shí)線表示。如圖2-15表示了一個(gè)帶有繼承關(guān)系的類圖，圖中A是超類或父類，也稱為基類，B是子類也成為派生類。2.4.4繼承（Inherit）圖2-15表示繼承關(guān)系的類圖實(shí)例特殊地，如果把繼承關(guān)系中的父類替換成一個(gè)接口時(shí)，子類則被稱為接口的一個(gè)實(shí)現(xiàn)。此時(shí)，二者之間的關(guān)系則稱為實(shí)現(xiàn)關(guān)系。實(shí)現(xiàn)的圖形符號(hào)一般使用帶有三角形箭頭的虛線表示，如圖2-11所示。UML為接口提供了帶有構(gòu)造型的類圖和帶有直線的小圓圈兩種圖形表示，如圖2-4中給出了名為IUnkown的接口的兩種圖形表示，前者隱藏接口中定義的操作，后者則包含了接口中的操作列表，二者的語(yǔ)義是相同的，只不過(guò)在某種上下文中前者更加簡(jiǎn)潔。2.4.5關(guān)于上述各種關(guān)系的討論在依賴、關(guān)聯(lián)、聚合、組合以及泛化等五種關(guān)系中，密切程度最高的關(guān)系是繼承關(guān)系，最弱的則是依賴關(guān)系。把這些關(guān)系按照耦合度從低到高排列，得到的順序就是：依賴、關(guān)聯(lián)、聚合、組合、繼承。如果進(jìn)一步考慮類與接口之間的實(shí)現(xiàn)，實(shí)現(xiàn)關(guān)系將是一種比繼承耦合度更高的關(guān)系。但由于接口僅僅描述了一組沒(méi)有實(shí)現(xiàn)的操作，或者說(shuō)接口并不會(huì)被映射成目標(biāo)系統(tǒng)中的實(shí)際模塊。所以討論接口與實(shí)現(xiàn)之間的耦合問(wèn)題將是毫無(wú)意義的。但從實(shí)現(xiàn)卻可以派生出一種新的、類之間的關(guān)系被稱為接口依賴的關(guān)系。接口依賴關(guān)系顯然是所有這些關(guān)系中耦合度最弱的一種關(guān)系2.5圖UML模型中，圖(diagram)是一種更為重要的模型元素，圖可以看成是以一組模型元素為結(jié)點(diǎn)，元素之間的連接關(guān)系為邊構(gòu)成的圖。UML用圖形的方式表示圖。圖可以用來(lái)表達(dá)軟件系統(tǒng)或其片段在某一方面的特征，如通常表示系統(tǒng)的靜態(tài)結(jié)構(gòu)和動(dòng)態(tài)行為。每種圖都有其特定的構(gòu)造規(guī)則和語(yǔ)義信息，這些規(guī)則規(guī)定了圖的構(gòu)造規(guī)則和方法，其語(yǔ)義也決定了這些圖的使用范圍、適用規(guī)則和使用方法。2.5圖UML定義了九種圖，我們稱為基本的UML圖。序號(hào)圖所屬視圖1用例圖(Usecasediagram)用例視圖(Usecaseview)2對(duì)象圖(Objectdiagram)用例和邏輯視圖(UsecaseandLogicalView)3順序圖(Sequencediagram)用例和邏輯視圖(UsecaseandLogicalView)4通訊圖(Communicationdiagram)用例和邏輯視圖(UsecaseandLogicalView)5類圖(Classdiagram)邏輯視圖(LogicalView)6狀態(tài)圖(Statechartdiagram)設(shè)計(jì)和行為視圖(Designandprocessview)7活動(dòng)圖(Activitydiagram)設(shè)計(jì)和行為視圖(Designandprocessview)8構(gòu)件圖(Componentdiagram)構(gòu)件視圖(lmplementationview)9部署圖(Deploymentdiagram)部署視圖(Deploymentview)表2-1UML定義的九種圖2.5.1用例圖(Usecasediagram)用例圖是一種由參與者、用例以及它們之間的連接關(guān)系組成的圖。一個(gè)用例用于表示系統(tǒng)所具有的某一個(gè)功能或?qū)ν馓峁┑囊环N服務(wù)。每個(gè)用例都可以分解成一個(gè)或一組動(dòng)作序列，這些動(dòng)作序列描述了參與者與系統(tǒng)之間的交互，也表示了系統(tǒng)對(duì)這些交互的反應(yīng)和行為。從用戶的角度來(lái)看，一個(gè)用例完成了對(duì)其具有某種價(jià)值的工作，也代表了系統(tǒng)應(yīng)具有的某項(xiàng)功能。完整的用例模型則表達(dá)了系統(tǒng)應(yīng)具有的所有功能。用例圖一般是從參與者使用系統(tǒng)的角度來(lái)描述系統(tǒng)中的信息，即在系統(tǒng)外部查看系統(tǒng)應(yīng)該具有的功能，并不描述這些功能的內(nèi)部實(shí)現(xiàn)。2.5.1用例圖(Usecasediagram)一張用例圖可以包括于整個(gè)系統(tǒng)的用例，也可以僅包含系統(tǒng)的部分用例，如某個(gè)子系統(tǒng)的用例，甚至也可以僅僅單個(gè)用例。另外，用例不僅用于描述期望的系統(tǒng)行為，還可以作為開(kāi)發(fā)過(guò)程中設(shè)計(jì)測(cè)試用例的基礎(chǔ)。圖2-17給出了一個(gè)用例圖的示例，圖中列出了若干個(gè)參與者、用例、參與者與用例之間的關(guān)聯(lián)以及用例之間的包含或擴(kuò)充關(guān)系等。2.5.1用例圖(Usecasediagram)圖2-17用例圖的示例2.5.2類圖(Classdiagram)類圖是由若干個(gè)類以及這些類之間的關(guān)系組成的圖。通常用于描述系統(tǒng)或系統(tǒng)的某個(gè)局部的靜態(tài)結(jié)構(gòu)，也稱為軟件的結(jié)構(gòu)模型。類圖通常屬于UML模型的結(jié)構(gòu)視圖，也是UML中最重要的模型，是系統(tǒng)建模所必須完成的最重要的工作結(jié)果。如圖2-18給出了某銷售系統(tǒng)的實(shí)體類類圖，包含了這個(gè)系統(tǒng)中的各種實(shí)體類，如賬戶(Account)、商品(StockItem)、訂單(Order)、訂單明細(xì)(Lineitem）、事務(wù)(Transaction)、購(gòu)物車(ShoppingBasket)和等多個(gè)類，以及這些類之間的關(guān)聯(lián)關(guān)系。2.5.2類圖(Classdiagram)圖2-18類圖實(shí)例2.5.2類圖(Classdiagram)這張類圖清晰地描述了這樣一個(gè)系統(tǒng)中包含的主要實(shí)體，例如，賬戶表示該系統(tǒng)的全體用戶構(gòu)成的集合；商品代表了該系統(tǒng)銷售的商品目錄集合；訂單描述了的該系統(tǒng)的銷售記錄；訂單明細(xì)表示了每張訂單的商品銷售記錄；事務(wù)代表了用戶與系統(tǒng)之間的一次交易；購(gòu)物車是一個(gè)與用戶相關(guān)聯(lián)的實(shí)體，用于存儲(chǔ)用戶選擇的那些商品。這張類圖不僅描述了銷售系統(tǒng)的相關(guān)概念，對(duì)這樣的類圖的進(jìn)一步細(xì)化還可以得到這個(gè)銷售系統(tǒng)的實(shí)體結(jié)構(gòu)模型和數(shù)據(jù)模型，并可以以此為依據(jù)構(gòu)建整個(gè)系統(tǒng)。2.5.2類圖(Classdiagram)一個(gè)典型的系統(tǒng)模型中通常需要建模多張類圖。一個(gè)類圖不一定要包含系統(tǒng)中所有的類，通常僅用于建模系統(tǒng)的某個(gè)局部。一個(gè)類也可以出現(xiàn)在多個(gè)不同的類圖中。2.5.3對(duì)象圖(Objectdiagram)對(duì)象圖可以看成是類圖的實(shí)例，用來(lái)描述系統(tǒng)在某個(gè)特定時(shí)刻某些對(duì)象之間的關(guān)系。創(chuàng)建對(duì)象圖時(shí)，并不需要描述系統(tǒng)中的每一個(gè)對(duì)象。事實(shí)上，絕大多數(shù)系統(tǒng)中都會(huì)包含大量的對(duì)象，描述所有對(duì)象以及它們之間的關(guān)系一般并不現(xiàn)實(shí)。因此，建模人員可以選取所感興趣的對(duì)象及其之間的關(guān)系來(lái)描述。2.5.3對(duì)象圖(Objectdiagram)圖2-19對(duì)象圖實(shí)例圖2-19給出了一個(gè)對(duì)象圖的例子，圖中包含了一個(gè)賬戶對(duì)象、一個(gè)訂單對(duì)象、兩個(gè)訂單明細(xì)以及對(duì)應(yīng)的商品對(duì)象?？梢钥闯觯瑘D中的對(duì)象可以被別看成是圖2-18中的各個(gè)類的實(shí)例。圖中的連線（鏈接）就是圖2-18中的各類關(guān)聯(lián)的實(shí)例。2.5.4順序圖(Sequencediagram)順序圖和通訊圖被統(tǒng)稱為交互圖。其中，順序圖用來(lái)描述對(duì)象之間消息發(fā)送的先后次序，闡明對(duì)象之間的交互過(guò)程以及在系統(tǒng)執(zhí)行過(guò)程中的某一具體時(shí)刻將會(huì)發(fā)生什么事件。如圖2-20中的順序圖描述了圖書管理系統(tǒng)中借書用例的主要場(chǎng)景。2.5.4順序圖(Sequencediagram)圖2-20借書用例的順序圖實(shí)例2.5.4順序圖(Sequencediagram)順序圖是一種強(qiáng)調(diào)時(shí)間順序的交互圖，其中對(duì)象沿橫軸排列，消息沿縱軸按時(shí)間順序排列。順序圖中的對(duì)象生命線是一條垂直的虛線，它表示一個(gè)對(duì)象在一段時(shí)間內(nèi)存在。順序圖中的大多數(shù)對(duì)象都存在于整個(gè)交互過(guò)程中，因此這些對(duì)象全部排列在圖的頂部，它們的生命線從圖的頂部畫到圖的底部。每個(gè)對(duì)象的正下方有一個(gè)矩形條，它與對(duì)象的生命線相重疊，它表示該對(duì)象的控制焦點(diǎn)。順序圖中的消息通常不帶有序號(hào)，由于這種圖上的消息已經(jīng)在縱軸上按時(shí)間順序排序，因此順序圖中消息的序號(hào)通常都被省略掉了。2.5.5通訊圖

(Communicationdiagram)通訊圖(Communicationdiagram)是一種描述對(duì)象之間的鏈接關(guān)系和收發(fā)消息的圖，它強(qiáng)調(diào)的是收發(fā)消息的對(duì)象的組織結(jié)構(gòu)。通訊圖和順序圖是語(yǔ)義等價(jià)的，它們可以互相轉(zhuǎn)換，它們統(tǒng)為稱交互圖。在大多數(shù)情況下，通訊圖主要用來(lái)對(duì)單調(diào)的、順序的控制流建模，但也可以用來(lái)對(duì)包含迭代、分支和并發(fā)在內(nèi)的復(fù)雜控制流進(jìn)行建模。2.5.5通訊圖

(Communicationdiagram)一般情況下，建模人員可以創(chuàng)建多張交互圖，它們可以是用例、用例的場(chǎng)景、用例的可選流或擴(kuò)充流等。建模人員可以使用包來(lái)組織這些通訊圖，并給每張圖命名一個(gè)合適的名字，以便與其它圖相區(qū)別開(kāi)。圖2-21給出了一個(gè)典型的通訊圖，容易看出它與圖2-20所示的順序圖是語(yǔ)義等價(jià)的。2.5.5通訊圖

(Communicationdiagram)圖2-21通訊圖舉例2.5.6狀態(tài)圖

(Statechartdiagram)狀態(tài)圖(Statechartdiagram)是一種由狀態(tài)、變遷、事件和動(dòng)作組成的狀態(tài)機(jī)模型。狀態(tài)圖描述的是一個(gè)對(duì)象在其生存期或某個(gè)生存期片段中的狀態(tài)以及狀態(tài)變遷的控制流，主要用于對(duì)系統(tǒng)的動(dòng)態(tài)特性建模。在大多數(shù)情況下，它主要用來(lái)對(duì)反應(yīng)型對(duì)象的行為進(jìn)行建模。在UML中，狀態(tài)圖可用來(lái)對(duì)一個(gè)對(duì)象按事件發(fā)生的順序所觸發(fā)的行為進(jìn)行建模。2.5.6狀態(tài)圖

(Statechartdiagram)例如，圖2-22中就包含了為用戶界面對(duì)象定義的多個(gè)狀態(tài)，其中包括了一個(gè)初始態(tài)、兩個(gè)終止態(tài)，以及輸入用戶名和輸入驗(yàn)證碼等多個(gè)狀態(tài)。其中初始態(tài)和終止態(tài)是偽狀態(tài)，分別表示狀態(tài)圖表示的過(guò)程開(kāi)始之前和之后的狀態(tài)。輸入用戶名狀態(tài)和輸入驗(yàn)證碼狀態(tài)是用戶界面對(duì)象的兩個(gè)不同的工作狀態(tài)，每個(gè)狀態(tài)的內(nèi)部，還包含了必要的狀態(tài)屬性和相關(guān)動(dòng)作，如入口動(dòng)作、出口動(dòng)作和動(dòng)作等。在所有狀態(tài)之間，還定義了若干個(gè)狀態(tài)變遷，每個(gè)變遷都定義了觸發(fā)變遷的事件、守衛(wèi)條件和變遷時(shí)需要完成的動(dòng)作。2.5.6狀態(tài)圖

(Statechartdiagram)圖2-22登錄用戶界面的狀態(tài)機(jī)模型2.5.6狀態(tài)圖

(Statechartdiagram)一般而言，狀態(tài)圖是對(duì)類所描述的模型元素的補(bǔ)充說(shuō)明，它描述了這個(gè)類的對(duì)象可能具有的狀態(tài)、引起狀態(tài)變化的事件以及狀態(tài)變遷時(shí)需要完成的動(dòng)作。2.5.7活動(dòng)圖(Activitydiagram)與狀態(tài)圖不同的是，活動(dòng)圖通常描述的是多個(gè)對(duì)象共同參與的一項(xiàng)活動(dòng)。圖2-23給出了一個(gè)描述用戶登錄過(guò)程的活動(dòng)圖，它與圖2-22中的狀態(tài)圖一樣均討論了登錄問(wèn)題，但二者的建模角度和描述方式卻均不相同。狀態(tài)圖可視為對(duì)系統(tǒng)中某個(gè)特定對(duì)象（如登錄用戶界面）的動(dòng)態(tài)行為的設(shè)計(jì)，而活動(dòng)圖描述的這是一個(gè)過(guò)程（如登錄過(guò)程）中的參與角色和職責(zé)分配這樣的問(wèn)題。二者即相互聯(lián)系，又相互區(qū)別。2.5.7活動(dòng)圖(Activitydiagram)圖2-23用戶登錄過(guò)程的活動(dòng)圖2.5.8構(gòu)件圖(Componentdiagram)構(gòu)件圖(Componentdiagram)用于描述系統(tǒng)的構(gòu)件組織和構(gòu)件之間的各種依賴關(guān)系，主要用于建模系統(tǒng)的靜態(tài)構(gòu)件視圖。構(gòu)件圖中也可以包括包或子系統(tǒng)，它們都用于將模型元素組織成較大的組塊。構(gòu)件可以是任何一個(gè)以可執(zhí)行程序文件、庫(kù)文件、數(shù)據(jù)庫(kù)表、數(shù)據(jù)文件和文檔等形式表示的系統(tǒng)構(gòu)成成分。構(gòu)件通常具有可更換性和可執(zhí)行性，它實(shí)現(xiàn)特定的功能，符合一套接口標(biāo)準(zhǔn)并實(shí)現(xiàn)一組接口。2.5.8構(gòu)件圖(Componentdiagram)圖2-24構(gòu)件圖的例子2.5.8構(gòu)件圖(Componentdiagram)圖2-24給出了一個(gè)構(gòu)件圖的例子，圖中列出了Firewall、LANSQLServer、MSExchangeServer、OrdersDatabase和BookStoreOrderApplication等五個(gè)構(gòu)件。還列出了它們之間存在的聚合、關(guān)聯(lián)和依賴關(guān)系。2.5.9部署圖(Deploymentdiagram)部署圖用來(lái)描述系統(tǒng)具有處理能力的結(jié)點(diǎn)以及構(gòu)件在這些結(jié)點(diǎn)上的配置。部署圖主要用于對(duì)系統(tǒng)的環(huán)境模型視圖建模。換句話來(lái)說(shuō)，部署圖主要用于描述系統(tǒng)硬件的拓?fù)浣Y(jié)構(gòu)。一般情況下，每個(gè)模型中通常只需要繪制一張構(gòu)件圖。例如，圖2-25給出了一個(gè)圖書管理系統(tǒng)的部署圖。圖中的結(jié)點(diǎn)描述了圖書管理系統(tǒng)需要的各種處理機(jī)或設(shè)備，它們分別是數(shù)據(jù)庫(kù)服務(wù)器(DatabaseServer)、應(yīng)用服務(wù)器(ApplicationServer)、讀者終端(ReaderTerminal)、圖書借閱終端(BookBorrowingTerminal)、信息查詢終端(InformationinquiryTerminal)和信息采集終端(InformationCollectionTreminal)等處理機(jī)。。2.5.9部署圖(Deploymentdiagram)圖中還包括了條碼掃描器(Barcodescaner)、讀卡器(CardReader)和條碼打印機(jī)(Barcodeprinter)等多種不同的設(shè)備。2.5.9部署圖(Deploymentdiagram)圖2-25圖書管理系統(tǒng)的部署圖2.5.9部署圖(Deploymentdiagram)圖2-25給出的部署圖，清楚地描述了這個(gè)圖書管理系統(tǒng)的物理結(jié)構(gòu)。2.5.10其它除了上述9種基本的UML圖之外，UML2.0及其后續(xù)版本還定義了多種不同的UML圖，它們包括復(fù)合結(jié)構(gòu)圖(CompositeStructuresdiagram)、交互概覽圖(InteractionOverviewDiagrams)和時(shí)序圖(TimingDiagrams)等。2.6通用機(jī)制UML提供了一些通用機(jī)制，為模型中的模型元素添加必要的附加信息。常用的UML通用機(jī)制包括：1）模型元素規(guī)約（Specification）2）修飾符（Decoration）3）擴(kuò)展機(jī)制（ExtensionMechanism）2.6.1規(guī)約（Specification）對(duì)于任何一個(gè)UML模型元素，UML都定義了一個(gè)元素規(guī)約（Specification）特性，該特性為模型元素給出了一個(gè)描述性的文字說(shuō)明，這個(gè)說(shuō)明一般不出現(xiàn)在模型元素的圖形表示當(dāng)中。事實(shí)上，UML的圖形表示可直觀地描述系統(tǒng)，而元素規(guī)約則可以用來(lái)描述其更多的建模細(xì)節(jié)。例如，類的圖形符號(hào)表示中包括了類名、操作、屬性以及類關(guān)系等方面的信息。如果需要描述類概念以及類定義等方面的信息，則可能將這些信息保存在類的規(guī)約之中。2.6.2修飾符（Decorator）UML中，除了是用圖形符號(hào)表示特定的模型元素之外，還是用各種修飾符表示模型元素的具體細(xì)節(jié)。例如圖2-26中給出的CAnimateImage類的圖形符號(hào)中，就使用了一些修飾符。例如，類圖中使用斜體的類名表示抽象類；+、-和#等符號(hào)表示屬性和操作的可見(jiàn)性；斜體的操作名表示抽象方法；帶下劃線的屬性名或方法名表示類作用域等。類圖中的修飾符既可以修飾類，如抽象類和具體類。也可以用于修飾屬性和方法等，如屬性和方法的可見(jiàn)性和作用域等。2.6.2修飾符（Decorator）圖2-26某圖像瀏覽器程序中的CAnimateImage類2.6.3擴(kuò)展機(jī)制

（ExtensionMechanism）所謂UML擴(kuò)展機(jī)制是指在使用現(xiàn)有模型元素的基礎(chǔ)上，使用某種方式定義具有某種特定含義的模型元素的機(jī)制，從而建立具有某種新的語(yǔ)義的模型。UML擴(kuò)展機(jī)制包括構(gòu)造型和標(biāo)記值等兩種方式。構(gòu)造型的作用是對(duì)UML模型元素所表示的概念的擴(kuò)展，主要用于根據(jù)已有的模型元素創(chuàng)建新類型的模型元素。UML為不同的模型元素預(yù)定義了不同的構(gòu)造型，稱為預(yù)定義的構(gòu)造型，例如為類指定的構(gòu)造型?interface?表示接口，為用例間的關(guān)系指定的構(gòu)造型?include?和?extend?表示用例間的包含和擴(kuò)充關(guān)系等。UML通過(guò)這些構(gòu)造型定義了多種不同的模型元素。2.6.3擴(kuò)展機(jī)制

（ExtensionMechanism）另外，UML還可以允許用戶定義自己的構(gòu)造型，這將使得用戶可以按自己的方式定義模型元素或?qū)ML應(yīng)用擴(kuò)展到其它領(lǐng)域。標(biāo)記值也是對(duì)UML模型元素特性的一種擴(kuò)展，增加標(biāo)記值是指在模型元素規(guī)約創(chuàng)建新的信息。其具體形式是為模型元素增加一個(gè)屬性名和相應(yīng)的屬性值，以增加模型元素的表現(xiàn)力。與構(gòu)造型類似，標(biāo)記值也分為預(yù)定義的標(biāo)記值和自定義的標(biāo)記值。如類的預(yù)定義標(biāo)記包括：位置、文檔、持久性、語(yǔ)義和職責(zé)等。2.6.2修飾符（Decorator）圖2-26某圖像瀏覽器程序中的CAnimateImage類例如：圖中的{Version=1.0}為類增加了一個(gè)的自定義的標(biāo)記值，其含義是說(shuō)明了這個(gè)類的版本。2.6.3擴(kuò)展機(jī)制

（ExtensionMechanism）例如：圖2-26中的類CAnimateImage中標(biāo)注的{Version=1.0}就為這個(gè)類增加了一個(gè)的自定義的標(biāo)記值，其含義是說(shuō)明了這個(gè)類的版本。2.6.4約束（Constraint）約束（Constraint）也是UML的一種公共機(jī)制，用于表示模型元素應(yīng)該滿足的某個(gè)特定條件。建模時(shí)，用戶可以使用約束表示軟件需要滿足的業(yè)務(wù)規(guī)則。UML中，約束的描述方式很隨意，常見(jiàn)的方式可以是用自然語(yǔ)言編寫的短語(yǔ)或句子，也可以使用對(duì)象約束語(yǔ)言編寫的OCL表達(dá)式。也可以是其它任何能夠接受的形式。在UML圖中，約束使用帶花括號(hào)的文本的方式加以描述。如圖2-26中的{version=1.0}就是附加在類CAnimateImage上的一個(gè)約束。2.7對(duì)象約束語(yǔ)言簡(jiǎn)介對(duì)象約束語(yǔ)言（ObjectConstraintLanguage,OCL）是UML中專門用于編寫約束和業(yè)務(wù)規(guī)則的一種形式語(yǔ)言。1995年，IBM公司的JosWarmer和SteveCookdailing帶領(lǐng)的一個(gè)小組開(kāi)發(fā)了對(duì)象約束語(yǔ)言，并將其作為業(yè)務(wù)建模項(xiàng)目的一部分，它后來(lái)成為IBM提交給對(duì)象標(biāo)準(zhǔn)化組織（OMG）的統(tǒng)一建模語(yǔ)言的一個(gè)部分，并將其視為定義模型中約束的推薦語(yǔ)言，并成為UML版本1.1規(guī)范的一部分開(kāi)始被正式采用。2.7.1對(duì)象約束語(yǔ)言的特點(diǎn)OCL是一種簡(jiǎn)單、規(guī)范的描述性語(yǔ)言，它具有如下主要特點(diǎn)：1規(guī)范性O(shè)CL是一種即簡(jiǎn)單又規(guī)范的語(yǔ)言。這使得OCL即易于理解和使用，又能夠更容易地為UML模型編寫出含義明確且不容易引起誤解的規(guī)則和約束。規(guī)范性是指這種語(yǔ)言具有嚴(yán)格的語(yǔ)法，同時(shí)也具有嚴(yán)格的使用規(guī)則。使用這種語(yǔ)言時(shí)，模型工具通常提供了嚴(yán)格的語(yǔ)法檢查機(jī)制。2描述性O(shè)CL是一種說(shuō)明性的描述語(yǔ)言，對(duì)模型描述的結(jié)構(gòu)或功能沒(méi)有任何副作用。使用OCL語(yǔ)句不會(huì)實(shí)質(zhì)性地改變模型中的任何東西（如對(duì)象屬性和方法）。2.7.1對(duì)象約束語(yǔ)言的特點(diǎn)3非過(guò)程性通常，人們并不使用OCL表達(dá)式描述模型中的過(guò)程（或活動(dòng)）。例如，違反了某個(gè)特定規(guī)則時(shí)應(yīng)執(zhí)行的動(dòng)作，這樣的活動(dòng)仍然UML模型元素（如活動(dòng)圖中的動(dòng)作等）描述。4強(qiáng)類型OCL是一種嚴(yán)格的強(qiáng)類型的語(yǔ)言，所有運(yùn)算符都要求其操作數(shù)必須符合指定的類型要求，同時(shí)每個(gè)操作也都只能適用于于特定的操作數(shù)類型。這使得使用這種語(yǔ)言可以嚴(yán)格、無(wú)二義性地描述建立的UML模型。這些特性使得這種語(yǔ)言既便于使用，又有助于建立概念清晰、結(jié)構(gòu)嚴(yán)謹(jǐn)、表達(dá)明確，無(wú)二義性的軟件模型。盡管UML不強(qiáng)制使用OCL，但理解和掌握這種語(yǔ)言的使用方法，仍然是很有意義。2.7.2OCL的主要用途OCL最主要的用途就是為UML模型中的各種模型元素指定需要的規(guī)則和約束，而這些規(guī)則或約束則可以大致劃分為以下幾種情形。1類不變量類不變量（Invariantsforclasses）是指對(duì)一個(gè)類的任何實(shí)例在任何情況下必須成立的條件。它指定了一個(gè)類的所有對(duì)象都必須遵守或滿足的條件。2構(gòu)造型的類型不變量類型不變量（Typeinvariantsforstereotypes）是一個(gè)與類型有關(guān)的不變量。在定義一個(gè)構(gòu)造型時(shí)，可以用它指定一個(gè)適用于該構(gòu)造型的所有類必須滿足的條件。2.7.2OCL的主要用途3操作的前置條件和后置條件前置條件（Pre-conditions）或后置條件（Post-conditions）是一種約束，它指定了執(zhí)行一個(gè)類操作之前或者之后需要滿足的條件。在OCL表達(dá)式中，可以用分別?precondition?和?postcondition?構(gòu)造型表示。4警戒條件警戒條件（Guards）用于指定是否執(zhí)行某個(gè)特定的活動(dòng)（或處理），或者當(dāng)存在多種替代方案時(shí)如何選擇某一個(gè)方案的條件。2.7.2OCL的主要用途5模型中的導(dǎo)航規(guī)則導(dǎo)航規(guī)則（Navigationalrules）是指OCL表達(dá)式中，如何通過(guò)上下文訪問(wèn)與上下文相關(guān)聯(lián)的對(duì)象的規(guī)則，則使得OCL表達(dá)式可以用來(lái)描述上下文中的關(guān)聯(lián)有關(guān)的規(guī)則和約束。6派生規(guī)則或約束派生規(guī)則（Derivationrules）指定的是如何通過(guò)其它值計(jì)算一個(gè)特定的值的規(guī)則。2.7.3OCL類型與操作OCL數(shù)據(jù)類型分為預(yù)定義的基本類型、集合類型和用戶自定義數(shù)據(jù)類型三種情況。1基本數(shù)據(jù)類型OCL基本數(shù)據(jù)類型包括整數(shù)（integer）、布爾(boolean)、實(shí)數(shù)(real)和字符串（string）等數(shù)據(jù)類型，這些類型獨(dú)立于任何對(duì)象模型，也是對(duì)象約束語(yǔ)言的基本組成部分。使用于任何UML模型。OCL的基本類型、相關(guān)操作符及取值的例子如表2-2所示。2.7.3OCL類型與操作數(shù)據(jù)類型運(yùn)算符及結(jié)果類型取值相關(guān)運(yùn)算符結(jié)果類型

Booleanand,or,not,xor,=,<>,impliesBooleantrue,falseifb1then<e1>else<e2>Typeofe1ore2Integer

=,<>,<,>,<=,>=Boolean1,-5,2,34,26524,...+,-,*Integer/Realmod,div,abs,max,minIntegerReal=,<>,<,>,<=,>=Boolean0.5,3.14,...+,-,*,/Booleanround,floorIntegerStringSubstring,concatString'Tobeornottobe...'toLower,toUpperStrings1=s2Boolean表2-2OCL基本類型及其運(yùn)算符2.7.3OCL類型與操作2集合類型（Collection）OCL定義了Set、Bag、和Sequence等三種具體的集合類型，它們都是抽象集合類型（Collection）的子類型，Collection類型包含了對(duì)所有集合都通用的操作。圖2-27描述了OCL集合類型之間的關(guān)系。圖2-27OCL集合類型2.7.3OCL類型與操作其中，Collection是抽象的集合類型，用于定義所有集合類型的公共屬性和公共操作。Bag是無(wú)序集合類型，可以包含重復(fù)元素。Set類型表示一個(gè)無(wú)序集合，但其元素不允許重復(fù)。Sequence則表示一個(gè)即有序，又可以包含重復(fù)元素的集合。類型操作及其結(jié)果類型說(shuō)明操作操作結(jié)果類型CollectionsizeInteger集合中的元素個(gè)數(shù)count(Object)IntegerObject類型的元素個(gè)數(shù)includes(Object)Boolean是否包含對(duì)象Object.includesAll(ObjColl)Boolean判斷當(dāng)前是否包含指定集合isEmptyBoolean判斷當(dāng)前集合是否空notEmptyBoolean判斷當(dāng)前集合是否非空sum()IntegerorReal計(jì)算集合中所有元素的和=Boolean判斷兩個(gè)集合是否相等union(Collection)Collection返回當(dāng)前集合與指定集合的并including(Object)Collection返回當(dāng)前集合與指定元素合并得到的集合excluding(Object)Collection返回移除指定元素后得到的集合intersection(Collection)Collection返回當(dāng)前集合與指定集合的交iterate(InitExpr;Expr)Expr遍歷當(dāng)前集合并執(zhí)行指定的操作select(Expr)Collection返回當(dāng)前集合中滿足指定條件的元素集合reject(Expr)Collection返回當(dāng)前集合中不滿足指定條件的元素集collect(Expr)Collection返回當(dāng)前集合中指定類型的元素集合exists(Expr)Boolean判斷當(dāng)前集合是否含有滿足指定條件元素forAll(Expr)Boolean判斷當(dāng)前集合所有元素是否滿足指定條件BagasSet()Set返回由Bag類型集合轉(zhuǎn)換的Set類型集合asSequence()Sequence返回由Bag類型集合轉(zhuǎn)換的Sequence集合Sets1-s2Set返回S1與S2的差集symmetricDifference(s2)Set返回S1與S2的對(duì)稱差集asBag()Bag返回由Set類型集合轉(zhuǎn)換的Bag類型集合asSequence()Sequence返回由Set類型集合轉(zhuǎn)換的Sequence集合SequencefirstTypeinCollection返回當(dāng)前序列中第一個(gè)元素lastTypeinCollection返回當(dāng)前序列中最后一個(gè)元素at(Integer)TypeinCollection返回當(dāng)前序列中指定位置的元素append(Type)Sequence返回在當(dāng)前序列追加了指定元素的序列prepend(Type)Sequence返回在當(dāng)前序列起始位置添加指定元素的序列asBag()Bag將Sequence類型對(duì)象轉(zhuǎn)換成Bag類型對(duì)象asSet()Set將Sequence類型對(duì)象轉(zhuǎn)換成Set類型對(duì)象表2-3集合類型及其操作2.7.3OCL類型與操作需要注意的是，抽象集合類型（Collection）的操作對(duì)其所有子類型都是適用的；同時(shí)，沒(méi)有哪個(gè)操作可以更改集合的內(nèi)容；如Append操作雖然返回一個(gè)添加了某個(gè)元素的新集合，但它并不更改原有集合的內(nèi)容。一般情況下，可以將UML類圖中的關(guān)聯(lián)視為Set類型的集合，有序關(guān)聯(lián)可以被當(dāng)作是一個(gè)Sequence類型的集合。2.7.3OCL類型與操作3用戶定義的類型用戶在UML模型中定義的任何一種類型（如用戶定義的類等）均可以看成是OCL的用戶定義類型。UML模型中定義的大多數(shù)類型或符號(hào)均出現(xiàn)OCL表達(dá)式中，它們或者作為OCL類型，或者作為OCL變量。2.7.4OCL表達(dá)式對(duì)象約束語(yǔ)言的主要使用方式就是編寫OCL表達(dá)式（OCLExpressions），并使用它們描述UML模型元素所需要的規(guī)則和約束。OCL表達(dá)式可以看成是一個(gè)由運(yùn)算符和操作數(shù)組成的表達(dá)式，每個(gè)表達(dá)式均具有一個(gè)類型并返回一個(gè)結(jié)果。需要注意的是，為了明確OCL表達(dá)式與UML模型元素之間的關(guān)系，每個(gè)OCL表達(dá)式都必須具有明確的上下文（Context）。在OCL表達(dá)式中，上下文可以看成是對(duì)模型中，某個(gè)特定的UML模型元素的一個(gè)引用，通過(guò)這個(gè)引用可以為模型元素定義期望的規(guī)則或約束。2.7.4OCL表達(dá)式上下文可以是UML模型中的任何類、屬性、方法以及類之間的關(guān)聯(lián)等。上下文為表達(dá)式指明了表達(dá)式希望約束或描述的目標(biāo)。沒(méi)有明確上下文的表達(dá)式將毫無(wú)用處。圖2-28給出了一張類圖，圖中包含了兩個(gè)類及其關(guān)聯(lián)關(guān)系。后面介紹的部分例子中將會(huì)以這張圖中的內(nèi)容為上下文定義需要表示的業(yè)務(wù)規(guī)則。2.7.4OCL表達(dá)式上下文可以是UML模型中的任何類、屬性、方法以及類之間的關(guān)聯(lián)等。上下文為表達(dá)式指明了表達(dá)式希望約束或描述的目標(biāo)。沒(méi)有明確上下文的表達(dá)式將毫無(wú)用處。圖2-28給出了一張類圖，圖中包含了兩個(gè)類及其關(guān)聯(lián)關(guān)系。后面介紹的部分例子中將會(huì)以這張圖中的內(nèi)容為上下文定義需要表示的業(yè)務(wù)規(guī)則。2.7.4OCL表達(dá)式圖2-28給出了一張類圖，圖中包含了兩個(gè)類及其關(guān)聯(lián)關(guān)系。后面介紹的部分例子中將會(huì)以這張圖中的內(nèi)容為上下文定義需要表示的業(yè)務(wù)規(guī)則。圖2-28類圖實(shí)例2.7.4OCL表達(dá)式OCL表達(dá)式通常可以分成不變量、操作約束、初始或派生規(guī)則以及導(dǎo)航等多種形式。1.不變量（Invariant）不變量表達(dá)式通常以模型中某個(gè)特定的類為上下文，描述這個(gè)類的所有實(shí)例應(yīng)該滿足的約束條件。2.7.4OCL表達(dá)式例如：對(duì)于圖中的Company類，定義“員工數(shù)大于50”這樣的約束時(shí)，可以使用如下的OCL表達(dá)式表示。contextCompanyinv:Company.numberOfEmployees>50圖2-28類圖實(shí)例2.7.4OCL表達(dá)式例如：對(duì)于圖中的Company類，定義“員工數(shù)大于50”這樣的約束時(shí)，可以使用如下的OCL表達(dá)式表示。contextCompanyinv:numberOfEmployees>50圖2-28類圖實(shí)例2.7.4OCL表達(dá)式第一行中context是一個(gè)OCL關(guān)鍵字，表示其后面的類名Company是整個(gè)表達(dá)式的上下文。其含義是表達(dá)式的作用范圍是Company類的所有實(shí)例。符號(hào)inv是一個(gè)關(guān)鍵字，表示該表達(dá)式是一個(gè)不變量表達(dá)式。第二行定義了一個(gè)用布爾表達(dá)式（numberOfEmployees>50）表示上下文需要滿足的條件，其中numberOfEmployees被隱含地解釋成Company類的屬性。兩行語(yǔ)句組成了一個(gè)完整的OCL表達(dá)式，它表達(dá)的語(yǔ)義是：“Company類的numberOfEmployees屬性值必須大于>50”或“公司員工數(shù)＞50”。這個(gè)表達(dá)式為Company類定義了一個(gè)約束。2.7.4OCL表達(dá)式下面列出了三個(gè)使用了不同表示法的等價(jià)表達(dá)式：1）使用了self關(guān)鍵字contextCompanyinv:self.numberOfEmployees>50self關(guān)鍵字表示上下文（Company類）的一個(gè)實(shí)例，其作用是明確了numberOfEmployees是Company類的屬性。2）使用實(shí)例變量作為上下文contextc:Companyinv:c.numberOfEmployees>50使用Company類的實(shí)例變量c作為上下文，c被視為Company類的一個(gè)實(shí)例，表達(dá)式明確了numberOfEmployees是實(shí)例變量c的屬性。3）使用表達(dá)式名字contextc:CompanyinvenoughEmployees:c.numberOfEmployees>50將enoughEmployees定義為OCL表達(dá)式的名字，這使得可以在其它地方使用這個(gè)名字引用這個(gè)約束。2.7.4OCL表達(dá)式2.操作約束（OperationConstraint）OCL表達(dá)式可以定義模型中與類操作有關(guān)的約束，操作約束可以分為操作的前置條件、后置條件和操作體約束。前置條件和后置條件表示了作在執(zhí)行前或執(zhí)行后必須滿足的條件。因此，這兩種約束實(shí)際上也是一種不變量約束。前置條件通常是對(duì)其輸入?yún)?shù)的約束。后置條件則主要是對(duì)操作輸出的結(jié)果的約束。定義前置條件或后置條件的方法就是使用pre和post關(guān)鍵字表示前置條件和后置條件。另外，關(guān)鍵字result表示操作的返回結(jié)果。2.7.4OCL表達(dá)式2.操作約束（OperationConstraint）定義操作約束的語(yǔ)法格式定義如下：contextTypename::operationName（）:Typepre:--post:--例如，為Person類的InCome操作定義前置和后置條件。contextPerson::InCome():Personpre:self.isUnemployed=falsepost:result>15002.7.4OCL表達(dá)式2.操作約束（OperationConstraint）操作體約束使用body作為表達(dá)式條件的前綴。一般情況下，表示一個(gè)查詢操作的結(jié)果。表達(dá)式的類型必須與操作的結(jié)果類型相一致。與前置條件和后置條件一樣，可以在表達(dá)式中使用操作參數(shù)。前置條件、后置條件和操作體表達(dá)式可以是混合在一個(gè)操作上下文中。2.7.4OCL表達(dá)式3.初始和派生規(guī)則（InitialandDerivedValues）OCL表達(dá)式可以通過(guò)初始和派生規(guī)則為屬性或關(guān)聯(lián)角色指定初始值和派生值。OCL定義了init和derive兩個(gè)關(guān)鍵字來(lái)定義初始和派生規(guī)則；定義初始和派生規(guī)則的語(yǔ)法規(guī)則的語(yǔ)法形式如下：contextTypename::attributeName:Typeinit:--someexpressionrepresentingtheinitialvalue2.7.4OCL表達(dá)式3.初始和派生規(guī)則（InitialandDerivedValues）OCL表達(dá)式可以通過(guò)初始和派生規(guī)則為屬性或關(guān)聯(lián)角色指定初始值和派生值。OCL定義了init和derive兩個(gè)關(guān)鍵字來(lái)定義初始和派生規(guī)則；定義初始和派生規(guī)則的語(yǔ)法規(guī)則的語(yǔ)法形式如下：contextTypename::assocRoleName:Typederive:--someexpressionrepresentingt