3UML概述教學(xué)講解課件

軟件需求分析與建模

-UML概述姓名：蘇錦鈿(

SuJD@)單位：計算機科學(xué)與工程學(xué)院時間：2023年6月4日1內(nèi)容UML歷史什么是UMLUML與軟件體系結(jié)構(gòu)UML構(gòu)成華南理工大學(xué)2軟件需求分析與建模1.UML歷史31.1UML產(chǎn)生與發(fā)展面向?qū)ο蟮姆治雠c設(shè)計(OOA＆D)方法的發(fā)展在80年代末至90年代中出現(xiàn)了一個高潮.UML是這個高潮的產(chǎn)物。它不僅統(tǒng)一了Booch、Rumbaugh和Jacobson的表示方法，而且對其作了進一步的發(fā)展，并最終統(tǒng)一為大眾所接受的標準建模語言。華南理工大學(xué)4軟件需求分析與建模70年代中期，公認的面向?qū)ο笤O(shè)計語言出現(xiàn)（SmallTalk）。從1989年到1994年，其數(shù)量從不到十種增加到了五十多種。Booch86,GOOD(通用面向?qū)ο蟮拈_發(fā)），HOOD(層次式面向?qū)ο蟮脑O(shè)計）、OOSD（面向?qū)ο蟮慕Y(jié)構(gòu)設(shè)計）等一批OOD（面向?qū)ο蟮脑O(shè)計或面向?qū)ο蟮拈_發(fā)的縮寫）截至1994年，公開發(fā)表并具有一定影響的OOA&D方法已達50多種。華南理工大學(xué)5軟件需求分析與建模Rational公司的G.Booch和J.Rumbaugh決定將他們各自的方法結(jié)合起來成為一種方法。1995年10月發(fā)布了第一個版本，稱作統(tǒng)一方法（UnifiedMethod0.8）OOSE的作者I.Jacobson也加入了公司，于是也加入了統(tǒng)一行動，發(fā)布了第二個版本UML0.9。鑒于統(tǒng)一行動的產(chǎn)物是一種建模語言，而不是一種建模方法，因此稱為統(tǒng)一建模語言華南理工大學(xué)6軟件需求分析與建模在此過程中，Rational公司發(fā)起成立了UML伙伴組織，開始時有12家參加，共同推出了UML1.0版，并在1997年1月提交給OMG把其他幾家分頭向OMG提交提案的公司納入進來，推出了UML1.1版，在1997年11月4日被OMG采納。然后成立任務(wù)組進行不斷的修訂，并產(chǎn)生了UML1.2、1.3和1.4版本。2000年起，就已經(jīng)開始著手開發(fā)UML2.0版本了，在2003年6月被OMG采納為最終采納規(guī)范?，F(xiàn)在主要為UML2.x。華南理工大學(xué)7軟件需求分析與建模Rational三劍客JimRumbaughGradyBoochIvarJacobson華南理工大學(xué)8軟件需求分析與建模2.什么是UML？9概述UML(統(tǒng)一建模語言)是為軟件系統(tǒng)的制品進行描述（specifying）、可視化（visualizing）、構(gòu)造（constructing）、文檔化（documenting）的一種語言。它同樣適用于商業(yè)模塊和其他非軟件系統(tǒng)。在大型和復(fù)雜系統(tǒng)的建模中，UML成功地描述一些優(yōu)秀的工程實施。華南理工大學(xué)10軟件需求分析與建模

UML是一種建模語言建模方法=建模語言

+建模過程。建模語言定義了用于表示設(shè)計的符號(通常是圖形符號)；建模過程描述進行設(shè)計所需要遵循的步驟。標準建模語言UML是一種建模語言，而不是一種方法，它統(tǒng)一了面向?qū)ο蠼５幕靖拍?、術(shù)語及其圖形符號，為人們建立了便于交流的共同語言。建模能力：建模方法+領(lǐng)域知識+實踐華南理工大學(xué)11軟件需求分析與建模

UML的主要特點UML統(tǒng)一了Booch，OMT和OOSE等方法中的基本概念：用例圖從OOSE來；類圖從OMT和Booch等方法來；實現(xiàn)圖(構(gòu)件圖和配置圖)從Booch的模塊圖和過程圖來。UML吸取了OO技術(shù)領(lǐng)域各流派的長處：狀態(tài)圖從Harel

而來；活動圖從工作流圖而來；合作圖從Booch的對象圖和Fusion的對象交互作用圖等而來；等等。在演變過程中UML提出了一些新的概念。華南理工大學(xué)12軟件需求分析與建模UML的基本概念[4]－UML的目標最重要目標：UML是所有建模人員可以使用的通用建模語言。它包含主流建模方法的概念，從而可以替代現(xiàn)有的軟件分析和設(shè)計方法，比如：OMT,Booch,OOSE等。UML不是完整的開發(fā)方法，它不包括逐步的開發(fā)流程，但它提供所有必要的概念，具備足夠的表達能力。UML的另一個目標是：能盡量簡潔地表達系統(tǒng)的模型。華南理工大學(xué)13軟件需求分析與建模1．易于使用，表達能力強，進行可視化建模；2．與具體的軟件開發(fā)過程無關(guān)，可應(yīng)用于任何軟件開發(fā)的過程；3．簡單、可擴展。擴展無需對核心概念進行修改；4．為面向?qū)ο蟮脑O(shè)計和開發(fā)過程中涌現(xiàn)出的高級概念（例如協(xié)作、框架、組件）提供支持；5．吸收當(dāng)代最好的軟件工程實踐經(jīng)驗；6．可升級，具有廣闊的適用性和可用性；7．有利于面向?qū)ο蠊ぞ叩氖袌龀砷L。UML的目標華南理工大學(xué)14軟件需求分析與建模UML語言包含三方面內(nèi)容：

1．UML基本圖素：它是構(gòu)成UML模型圖的基本元素。例如類、對象、包、接口、組件等。2．UML模型圖：它由UML基本圖素按照UML建模規(guī)則構(gòu)成。例如用例圖、類圖、對象圖、…等。3．UML建模規(guī)則：UML模型圖必須按特定的規(guī)則有機地組合而成,從而構(gòu)成一個有機的、完整的UML模型圖（well-formedUMLdiagram）。華南理工大學(xué)15軟件需求分析與建模3.UML支持軟件體系結(jié)構(gòu)建模163.1軟件體系結(jié)構(gòu)為了表達不同的軟件開發(fā)相關(guān)人員在軟件開發(fā)周期的不同時期看待軟件產(chǎn)品的不同側(cè)重面,需要對模型進行分層。UML根據(jù)軟件產(chǎn)品的體系結(jié)構(gòu)（architecture）對軟件進行分層華南理工大學(xué)17軟件需求分析與建模軟件體系結(jié)構(gòu)由一系列的決定組成，這些決定定義了如下內(nèi)容：軟件系統(tǒng)的組織；構(gòu)成軟件系統(tǒng)的結(jié)構(gòu)元素的結(jié)構(gòu)及它們之間的接口；結(jié)構(gòu)元素的行為及元素之間的協(xié)同（collaboration）結(jié)構(gòu)元素的不斷組合以構(gòu)成日漸完備的子系統(tǒng)的過程指導(dǎo)軟件建造過程的軟件構(gòu)筑風(fēng)格（architecturalstyle）靜態(tài)和動態(tài)元素之間的接口、協(xié)同、構(gòu)成（composition）。華南理工大學(xué)18軟件需求分析與建模軟件體系結(jié)構(gòu)不僅僅決定軟件的結(jié)構(gòu)和行為，而且還決定軟件的：用途功能性能應(yīng)變性(resilience)可重用性經(jīng)濟和技術(shù)方面的限制和折衷以及美學(xué)考慮（aestheticconcern）華南理工大學(xué)19軟件需求分析與建模3.2體系結(jié)構(gòu)的視圖UML將軟件的體系結(jié)構(gòu)分解為五個不同的側(cè)面，稱為4＋1視圖(view)。分別是：用例視圖（Usecaseview）設(shè)計視圖(designview)進程視圖（processview）實現(xiàn)視圖(implementationview)分布視圖(deploymentview)設(shè)計視圖和進程視圖又可被統(tǒng)一稱為邏輯視圖(logicalview)。華南理工大學(xué)20軟件需求分析與建模

邏輯視圖實現(xiàn)視圖進程視圖部署視圖用例視圖動態(tài)行為設(shè)計詞匯、功能描述系統(tǒng)組裝、配置管理性能、穩(wěn)定性、吞吐率系統(tǒng)拓撲、分布、分發(fā)、安裝華南理工大學(xué)21軟件需求分析與建模每個視圖分別關(guān)注軟件開發(fā)的某一側(cè)面視圖由一種或多種模型圖(diagram)構(gòu)成模型圖描述了構(gòu)成相應(yīng)視圖的基本模型元素（element）及它們之間的相互關(guān)系。華南理工大學(xué)22軟件需求分析與建模3.3用例視圖（usecaseview）用例視圖用來支持軟件系統(tǒng)的需求分析，它定義系統(tǒng)的邊界，關(guān)注的是系統(tǒng)的外部功能的描述。它從系統(tǒng)的使用者的角度，描述系統(tǒng)的外部的靜態(tài)的功能動態(tài)行為系統(tǒng)的動態(tài)功能由UML以下模型圖描述：交互圖(interactiondiagram)，包括順序圖和協(xié)作圖。狀態(tài)圖(state-chartdiagram)活動圖(activitydiagram)華南理工大學(xué)23軟件需求分析與建模3.4邏輯視圖（LogicalView）邏輯視圖定義系統(tǒng)的實現(xiàn)邏輯,描述為實現(xiàn)用例圖描述的功能，在對軟件系統(tǒng)進行設(shè)計時,所產(chǎn)生的設(shè)計概念，設(shè)計概念又稱為軟件系統(tǒng)的設(shè)計詞匯(vocabulary)。邏輯視圖定義了:設(shè)計詞匯的邏輯結(jié)構(gòu)存在于它們之間的語義聯(lián)系設(shè)計詞匯包括系統(tǒng)的類/協(xié)同/接口及其關(guān)系華南理工大學(xué)24軟件需求分析與建模對邏輯視圖的描述在原則上與軟件系統(tǒng)的實現(xiàn)平臺無關(guān)。它相當(dāng)于電子產(chǎn)品生產(chǎn)中的電原理圖。邏輯視圖包含的模型圖有：類圖（classdiagrams）對象圖（objectdiagrams）交互圖（interactiondiagrams）狀態(tài)圖（state-chartdiagrams）活動圖（activitydiagrams）華南理工大學(xué)25軟件需求分析與建模3.5實現(xiàn)視圖（implementationview）當(dāng)系統(tǒng)的邏輯結(jié)構(gòu)在邏輯視圖里被定義之后，需要定義邏輯結(jié)構(gòu)的物理實現(xiàn)。這包括：設(shè)計元素對應(yīng)的源代碼文件各物理文件之間的關(guān)系、存放路徑，等等實現(xiàn)視圖就是定義這些內(nèi)容的地方，它當(dāng)于電子產(chǎn)品的印刷電路板的布線圖華南理工大學(xué)26軟件需求分析與建模實現(xiàn)視圖描述組成一個軟件系統(tǒng)的各個物理部件，這些部件以各種方式組合起來，（如：不同的源代碼經(jīng)過編譯，構(gòu)成一個可執(zhí)行系統(tǒng)；或者不同的軟件組件配置成為一個可執(zhí)行系統(tǒng)；以及不同的網(wǎng)頁文件，以特定的目錄結(jié)構(gòu)，組成一個網(wǎng)站，等等）構(gòu)成了一個可實際運行的系統(tǒng)。實現(xiàn)視圖包含的模型圖有:部件圖（Componentdiagram）交互圖（InteractionDiagram）狀態(tài)圖（state-chartdiagram）活動圖（activitydiagram）華南理工大學(xué)27軟件需求分析與建模3.6部署視圖（DeploymentView）軟件產(chǎn)品將運行在計算機硬件系統(tǒng)上,如果軟件產(chǎn)品是面向網(wǎng)絡(luò)的應(yīng)用系統(tǒng)，則有可能同時運行在多個計算機上。分布視圖用來描述軟件產(chǎn)品在計算機硬件系統(tǒng)和網(wǎng)絡(luò)上的安裝、分發(fā)（delivery）、分布（distribution）華南理工大學(xué)28軟件需求分析與建模在分布視圖中，系統(tǒng)的靜態(tài)特性用分布圖（deploymentdiagram）描述動態(tài)特性的描述用交互圖（interactiondiagram）狀態(tài)圖（state-chartdiagram）活動圖（activitydiagram）華南理工大學(xué)29軟件需求分析與建模4.UML構(gòu)成304.1UML基本構(gòu)成從軟件的體系結(jié)構(gòu)出發(fā)，UML把軟件模型分成了五個視圖，每個視圖由不同的模型圖構(gòu)成：模型圖實際上就是UML的基本成員之一作為UML的完整的概念模型，UML的構(gòu)成為：UML=UML成員+UML建模規(guī)則華南理工大學(xué)31軟件需求分析與建模UML建模規(guī)則：相當(dāng)于建模語言的語法UML成員（buildingblocksoftheUML）它是UML的基本組成部分UML成員可進一步劃分為UML基本模型元素（thingsinUML）關(guān)系（relationship）模型圖（diagram）UML成員=UML基本模型元素+關(guān)系+模型圖

華南理工大學(xué)32軟件需求分析與建模4.1.1UML基本模型元素UML成員=UML基本模型元素+關(guān)系+模型圖33

概述UML基本模型元素，類似于電子產(chǎn)品電原理圖里的集成電路符號，是模型圖上包含的基本符號基本模型元素可分為四類，它們是：結(jié)構(gòu)模型元素（structuralthings）行為模型元素（behavioralthings）分組模型元素（groupingthings）注解元素（annotationalthings）UML基本模型元素=結(jié)構(gòu)模型元素+行為模型元素+成組元素+注解元素

華南理工大學(xué)34軟件需求分析與建模

結(jié)構(gòu)模型元素結(jié)構(gòu)模型元素（基礎(chǔ)包）是UML模型里的名詞（noun），是模型的靜態(tài)組成部分，代表軟件系統(tǒng)的概念的,或物理的存在。例如：類（class）是最常用的一個結(jié)構(gòu)模型元素，代表一系列共享同樣的屬性（attributes），操作（operation），關(guān)系、語義的對象（object）。華南理工大學(xué)35軟件需求分析與建模結(jié)構(gòu)模型元素一共有七種，它們是：類接口（interface）協(xié)同用例（usecase）主動類（activeclass）組件（component）節(jié)點（node）在這些結(jié)構(gòu)元素中，最常用的包括類、用例、接口、組件等

華南理工大學(xué)36軟件需求分析與建模

行為模型元素行為模型元素（behavioralthings）（行為元素包）是UML模型的動態(tài)組成部分，它是模型的動詞，代表軟件系統(tǒng)在空間和時間上的行為行為模型元素包括兩類:交互（interaction）狀態(tài)機（statemachine）行為模型元素=交互+狀態(tài)機華南理工大學(xué)37軟件需求分析與建模交互是系統(tǒng)內(nèi)一系列的對象之間互相交換消息的行為。消息代表軟件系統(tǒng)內(nèi)兩個對象中一個對象向另一個對象發(fā)出的執(zhí)行某種操作的請求。交互描述了一系列的對象為完成某一項任務(wù)而聯(lián)合采取的一系列的行動，其中包括這些行動在時間上的順序，以及為執(zhí)行這些動作序列，對象之間所發(fā)生的語義上的聯(lián)系。所以，消息是描述交互的一個重要手段。在模型圖上，消息被表示為一個箭頭華南理工大學(xué)38軟件需求分析與建模狀態(tài)機:狀態(tài)機是描述一個對象的動態(tài)特性的有效手段它描述的是對象在其生命周期內(nèi)，在響應(yīng)外界的事件的過程中，自身的狀態(tài)的變化過程。狀態(tài)機包括：對象狀態(tài)事件由事件引起的狀態(tài)之間的變遷以及變遷發(fā)生的同時對象所執(zhí)行的動作華南理工大學(xué)39軟件需求分析與建模

成組模型元素分治的原則:在為復(fù)雜的軟件系統(tǒng)建模的時候，將大的問題分解為多個子問題分別描述和解決。UML提供了支持分治原則的語言成份，成組模型元素(groupingthings)（模型管理包）成組模型元素只有一類，即模型包（package）。華南理工大學(xué)40軟件需求分析與建模模型包一個通用的手段,用來組織多種語言成份，其中可包含：結(jié)構(gòu)模型元素行為模型元素成組模型元素自身都可以置于模型包中。模型包是純概念性的，只存在于軟件系統(tǒng)的開發(fā)階段華南理工大學(xué)41軟件需求分析與建模

注解模型元素注解大量存在于機械圖和電子線路圖中，被用來標示產(chǎn)品的工藝要求，等等UML中，也存在著相似的語言成分，這就是：注解元素（annotationthings）注解元素只有一種，即標注（note）標注用來描述施加于一個或多個模型元素的限制，或?qū)δＰ驮氐恼Z義加以說明標注的圖形表示：一個折了角的長方形在長方形中寫標注的內(nèi)容。標注的內(nèi)容可以是形式的文本,或非形式的文本也可以是圖形。華南理工大學(xué)42軟件需求分析與建模4.1.2關(guān)系UML成員=UML基本模型元素+關(guān)系+模型圖43結(jié)構(gòu)模型元素是UML模型的靜態(tài)組成部分，靜態(tài)組成部分不是孤立存在的，它們被組合在一起互相協(xié)作以完成某項任務(wù)。因此，結(jié)構(gòu)模型元素之間存在著某種語義上的聯(lián)系。在UML中，這種聯(lián)系是關(guān)系（relationship）UML中共有4種關(guān)系，它們是：關(guān)聯(lián)關(guān)系（association）依賴關(guān)系(dependency)泛化關(guān)系(generalization)

實現(xiàn)關(guān)系(realization)華南理工大學(xué)44軟件需求分析與建模4.1.3模型圖UML成員=UML基本模型元素+關(guān)系+模型圖45

概述UML基本模型元素及其關(guān)系必須通過某種載體表示，這種載體就是模型圖（diagram）在UML中，模型圖是一組UML基本模型元素的圖形表示，它通常由一組節(jié)點（UML基本模型元素）,及節(jié)點之間的連線（關(guān)系）組成軟件系統(tǒng)體系結(jié)構(gòu)的5個視圖的內(nèi)容,就是用模型圖來表達的

一般地說，一個UML基本模型元素既可以出現(xiàn)在所有的模型圖中，又可以出現(xiàn)在某些模型圖中，甚至可以不在任何一個模型圖上出現(xiàn)華南理工大學(xué)46軟件需求分析與建模9種UML模型圖。它們是:類圖對象圖用例圖序列圖協(xié)同圖狀態(tài)圖活動圖組件圖分布圖華南理工大學(xué)47軟件需求分析與建模

靜態(tài)結(jié)構(gòu)模型圖下面四種模型圖主要用來描述靜態(tài)結(jié)構(gòu)：（1）類圖包含類、接口、協(xié)同及其關(guān)系，它用來描述邏輯視圖的靜態(tài)屬性（2）對象圖包含對象及其關(guān)系，它用來表示類圖的類的對象在系統(tǒng)運行過程中某一時刻的狀態(tài)，對象也是軟件系統(tǒng)的邏輯視圖的一個組成部分。華南理工大學(xué)48軟件需求分析與建模（3）組件圖描述系統(tǒng)的物理實現(xiàn)，包括構(gòu)成軟件系統(tǒng)的各部件（運行文件）的組織和關(guān)系，類圖里的類在實現(xiàn)時最終會映射到組件圖的某個組件。一個組件可以實現(xiàn)多個類。組件圖是軟件系統(tǒng)實現(xiàn)視圖的組成部分。（4）分布圖描述系統(tǒng)的組件在運行時在運行節(jié)點上的分布，一個節(jié)點可包含一個或多個組件。分布圖是軟件系統(tǒng)分布視圖的組成部分。華南理工大學(xué)49軟件需求分析與建模

動態(tài)特性模型圖描述軟件系統(tǒng)的動態(tài)特性的,使用用例圖序列圖協(xié)作圖狀態(tài)圖活動圖華南理工大學(xué)50軟件需求分析與建模（1）用例圖描述系統(tǒng)的邊界，和其上的動態(tài)行為，圖中包括：用例（usecase），系統(tǒng)作用者（actor）及其之間的(關(guān)聯(lián))關(guān)系。用例圖是用例視圖的重要組成部分。（2）序列圖和協(xié)作圖用來描述一組對象之間的動態(tài)交互。以用來描述系統(tǒng)的動態(tài)特性、外部的動態(tài)特性、內(nèi)部的動態(tài)特性。華南理工大學(xué)51軟件需求分析與建模（3）狀態(tài)圖和活動圖用于描述對象的動態(tài)特性。狀態(tài)圖強調(diào)對象對外部事件的響應(yīng)及相應(yīng)的狀態(tài)變遷活動圖描述對象之間控制流的轉(zhuǎn)換和同步機制。華南理工大學(xué)52軟件需求分析與建模4.1.4UML建模原則UML=UML成員+UML建模規(guī)則53UML的模型圖不是UML語言成份（UML成員）的簡單堆砌，它必須按特定的規(guī)則有機地組合而成，從而構(gòu)成一個完備的UML模型圖。完備的UML模型圖（well-formedUMLdiagram）必須在語義上是一致的，并且和一切和它相關(guān)的模型和諧地組合在一起。華南理工大學(xué)54軟件需求分析與建模UML建模規(guī)則包括:名字：任何一個UML成員都必須包含一個名字作用域：UML成員所定義的內(nèi)容起作用的上下文環(huán)境可見性：UML成員能被其它成員引用的方式完整性：UML成員之間互相聯(lián)接的合法性和一致性。運行屬性（execution）：UML成員在運行時的特性。華南理工大學(xué)55軟件需求分析與建模完備的UML模型必須對以上的內(nèi)容給出完整的解釋,

當(dāng)用于軟件系統(tǒng)的建造時，UML模型是必須是完備的,

但是當(dāng)模型在不同的視圖中出現(xiàn)時,

出于不同的交流側(cè)重點,其表達可以是不完備的華南理工大學(xué)56軟件需求分析與建模4.2公共機制574.2.1概述在模型圖上對UML成員進行描繪時，存在著共同的描繪方式，它們稱為：UML公共機制（UMLcommonmechanism）使用這些公共機制，使得建模的過程易于掌握，模型易于被理解公共機制可被分解為四個方面的內(nèi)容：規(guī)格說明(Specification)通用劃分(CommonDivision)修飾(Adornment)擴展機制(Extensibility)華南理工大學(xué)58軟件需求分析與建模4.2.2規(guī)格說明體現(xiàn)了UML規(guī)則的省略性原則。模型圖省略某些對突出重點不重要的內(nèi)容但是軟件模型必須是完備的，以便于軟件系統(tǒng)的建造，意味著此模型必須具備足夠的詳細信息以供軟件建造之用，這些構(gòu)成一個完備模型的詳細信息就是模型的規(guī)格說明（specification）華南理工大學(xué)59軟件需求分析與建模華南理工大學(xué)60軟件需求分析與建模所有UML模型元素都包含規(guī)格說明在模型圖上被省略的內(nèi)容并不代表它也不存在于模型之中，模型的完整的或完備的信息是被保存在模型的規(guī)格說明中的，而通常一個完備的模型全部內(nèi)容是通過多個模型圖表達出來的華南理工大學(xué)61軟件需求分析與建模4.2.3通用劃分在面向?qū)ο蟮脑O(shè)計中，有許多事物可以劃分為抽象的描繪（class）和具體的實例UML提供了事物的這種兩分法（dichotomy）表達幾乎每種UML成員都有這種類/對象的兩分法劃分，通常對象和類使用同樣的圖符，在對象的名字下面加下劃線以示區(qū)別。華南理工大學(xué)62軟件需求分析與建模4.2.4修飾和擴展機制UML提供一系列的圖形化的標準建模元素，可用于描述軟件系統(tǒng)的大多數(shù)側(cè)面的特性但也有可能在某些情形下，由于應(yīng)用領(lǐng)域特殊性，標準的UML建模元素,無法完整而準確地描述軟件系統(tǒng)的分析和設(shè)計,

這時，需要對UML的標準建模元素進行擴充,

以提高模型的表達能力UML的修飾和擴展機制就是為這個目的而設(shè)置的

華南理工大學(xué)63軟件需求分析與建模

標注標注是UML修飾機制的一個重要組成部分當(dāng)用UML的各種建模元素為軟件系統(tǒng)建模時，將遇到關(guān)于這些建模元素的復(fù)雜的語法、語義、原理、約束、注釋等，這些內(nèi)容對表達問題的某一方面很重要，但又無法通過標準建模元素被完整地表達這時，可以使用標注對這些建模元素進行附加說明。華南理工大學(xué)64軟件需求分析與建模例如：在使用序列圖來描述一組對象間的交互時，其中的消息的語義、語法無法在消息的名字字串內(nèi)完整地表達，可以用標注的方法進行直觀的說明。對于類、模型包、部件等，也可能遇到類似的情形，因此也可以用標注的方法進行補充說明標注的手段不是軟件建模獨有的，在其它工業(yè)建模領(lǐng)域，標注也是大量存在的例如，在電子線路圖上，可以通過標注對電路的電氣特性進行說明。華南理工大學(xué)65軟件需求分析與建模標注（Note)的定義：在UML中,標注被定義為UML的一個圖形表示，它用來描述對一個或一組UML建模元素的約束或注釋標注可以作用于任何UML建模元素（如：類、對象、關(guān)系、消息等），用于對此建模元素的各方面的特性作補充說明、表示設(shè)計分析過程中產(chǎn)生的假設(shè)和決定等標注的內(nèi)容對被標注的建模元素沒有任何語義上的影響，它只起到增強模型的可讀性的作用華南理工大學(xué)66軟件需求分析與建模UML對標注的內(nèi)容不作任何限制，它可以是普通的文本，也可以是形式化的描述如果工具支持的話，標注還可以包含網(wǎng)絡(luò)鏈接。標注的內(nèi)容不宜過長。如果有很長的內(nèi)容需要通過標注表達的話，可以把內(nèi)容存放在一個分開的文件內(nèi)，在標注內(nèi)則放置對此內(nèi)容的引用標注的圖形化表示在UML里，標注被圖形化為一個折角矩形矩形的內(nèi)部放置標注的內(nèi)容，標注和被標注的建模元素之間用虛線連接一個標注可以為多個建模元素作標注華南理工大學(xué)67軟件需求分析與建模位圖顯示:工作原理見doublebuffering.docCBmpViewerView(frombmpviewer)CBmpDblBuffering(frombmpviewer)1+m_pCBmpDblBuf1+m_pCBmpDblBuf0..110..11CBmpViewerDoc(frombmpviewer)CBmpViewerData(frombmpviewer)+m_pCBmpViewerData1111位圖文件,格式參見:http:\\這個類用于維護圖象的當(dāng)前狀態(tài)簡單文字對文件的引用網(wǎng)絡(luò)連接華南理工大學(xué)68軟件需求分析與建模

擴展機制UML擴展機制的三個組成部分：（1）構(gòu)造型(Stereotype)（2）標記值(taggedvalue)（3）約束(constraint)華南理工大學(xué)69軟件需求分析與建模（1）擴展機制：構(gòu)造型UML已經(jīng)提供了標準的建模元素用于軟件系統(tǒng)的建模在對軟件系統(tǒng)進行分析和設(shè)計時，可以用這些建模元素對軟件系統(tǒng)的動態(tài)行為和靜態(tài)結(jié)構(gòu)進行建模。但在各種不同的應(yīng)用領(lǐng)域，往往有可能出現(xiàn)用現(xiàn)有的建模元素?zé)o法充分表達所需內(nèi)容的情況，這時需要在現(xiàn)有的建模元素的基礎(chǔ)上進行擴充，產(chǎn)生對特定建模問題特有的建模元素，這種建模元素就是構(gòu)造型

華南理工大學(xué)70軟件需求分析與建模構(gòu)造型(stereotype)的定義在UML中,構(gòu)造型(stereotype)被定義為是對UML詞匯（建模元素）的擴充，用來描述和已有的UML建模元素類似，但又對特定的問題領(lǐng)域有特殊意義的建模元素。華南理工大學(xué)71軟件需求分析與建模當(dāng)在UML模型現(xiàn)有的標準建模元素的基礎(chǔ)上創(chuàng)建其構(gòu)造型時，此構(gòu)造型就變成了一個新的UML建模元素，這個新的建模元素除了和最初的建模元素類似之外，它可以有自己的：新的構(gòu)成（用標記值表示）新的語義（可用約束表示）自己的標識符（文本的和圖形化的）華南理工大學(xué)72軟件需求分析與建模構(gòu)造型的圖形表示，構(gòu)造型的標識可以采取兩種形式：記名的構(gòu)造型（namedstereotype）構(gòu)造型的圖標形式(stereotypedelementasicon)記名構(gòu)造型是在UML模型中構(gòu)造型最簡單的表達形式，它保留了原建模元素的圖形化表示，而用構(gòu)造型名來修飾原建模元素的名字，即在原建模元素的圖形表示的名字的上方，放置用雙尖括號（<<>>）括起來的構(gòu)造型名。華南理工大學(xué)73軟件需求分析與建模構(gòu)造型還可以使用自己的圖標，用來代替原來的建模元素的圖形化表示，這就是構(gòu)造型標識的圖標形式。圖標形式CBmpViewerView(frombmpviewer)CBmpViewerView(frombmpviewer)<<boundary>>具名構(gòu)造型華南理工大學(xué)74軟件需求分析與建模(2)擴展機制：標記值任何一個UML標準建模元素都有其基本構(gòu)成例如，對于類而言，它的三個基本構(gòu)成是：名字、屬性、操作。在特定的情形下，將有必要在建模元素的基本構(gòu)成之外再增加一些構(gòu)成,

此構(gòu)成就是標記值(taggedvalue)。例如：可以在類上在增加一個名為version的標記值，用來表明詞類的定義對某一特定的軟件版本有效。華南理工大學(xué)75軟件需求分析與建模標記值的定義在UML中，標記值被定義為是對UML建模元素的構(gòu)成(property)的擴充，用于為此建模元素增加新的規(guī)格說明。標記值和類的屬性不同，屬性定義的是被建模的事物的構(gòu)成，而標記值定義的是建模元素本身的構(gòu)成，就這個角度而言，標記值可以看作是UML的元數(shù)據(jù)。華南理工大學(xué)76軟件需求分析與建模標記值必須是具名的，此名字應(yīng)有合法的取值，如果把類的屬性看作標記值的話，此標記值的名字就是“屬性(attribute)”,

而類的屬性定義的集合，就是“屬性”這個標記值的取值。華南理工大學(xué)77軟件需求分析與建模標記值的圖形表示在UML里，標記值被圖形化地表達為一個字符串，此字符串用花括弧括({})起來，被放置到原建模元素的名字的下方標記值的字符串由標記值的名字、取值、及分隔符組成。名字位于字符串的起始，取值位于字符串的尾部，它們之間用等號分隔。在不引起混淆的情況下，標記值的名字可以省略。華南理工大學(xué)78軟件需求分析與建模標記名被省略trans{serverOnle}<<DLL>>Server{processors=3}完整的標記值華南理工大學(xué)79軟件需求分析與建模(3)擴展機制：約束和標記值對UML建模元素的構(gòu)成進行擴充類似，UML提供了對UML建模元素的語義進行擴充的機制，這機制被稱為約束。約束的定義：在UML里，約束用來擴充UML建模元素的語義，以便增加新的規(guī)則或修改已有的規(guī)則華南理工大學(xué)80軟件需求分析與建模在UML里，每一個建模元素都有明確的語義，語義規(guī)定了用建模元素為軟件系統(tǒng)建模的規(guī)則。如果在建模時，有些特定的規(guī)則不包含在現(xiàn)有的UML語義內(nèi)，可以用約束對建模元素的現(xiàn)有建模規(guī)則進行擴充。約束為對應(yīng)的建模元素規(guī)定了一個條件，對于一個完備的模型而言，此建模對象必須使該條件被滿足。華南理工大學(xué)81軟件需求分析與建模約束的圖形化表示在UML里，約束被圖形化為一個文本串，此文本串被括在一對花括號內(nèi)，并被放置在被約束的建模元素附近例如，通常，關(guān)聯(lián)關(guān)系只表示兩個類之間的語義連接，而在圖中，需要表示用繼承關(guān)系實現(xiàn)的多個鼠標工具的切換。華南理工大學(xué)82軟件需求分析與建模{or}約束:任何時刻只和一個導(dǎo)出類相關(guān)CToolPan(frombmpviewer)CToolZoom(from圖7.8繼承關(guān)系)CToolBase(frombmpviewer)CMainFrame(frombmpviewer)+m_pCToolBase+m_pCToolBase+m_pCToolBase{or}鼠標工具切換機制這時，任何時刻，指向它們的基類的指針只和一個導(dǎo)出類相關(guān)連，為了表達這種情形，這些關(guān)聯(lián)關(guān)系加以約束({or})，以表示任意時刻，類CmainFrame的關(guān)聯(lián)角色m_pCToolBase

或者和CtoolZoom關(guān)聯(lián)，或者和CtoolPan關(guān)聯(lián)。華南理工大學(xué)83軟件需求分析與建模

如果約束應(yīng)用于一種具有相應(yīng)視圖元素的模型元素，它可以出現(xiàn)在它所約束元素視圖元素的旁邊。通常一個約束由一對花括號括起來（{constraint}），花括號中為約束內(nèi)容（如下圖所示）。如果一條約束涉及同一種類的多個元素，則要用虛線把所有受約束的元素框起來，并把該約束顯示在旁邊（如或約束）。PolygonPoint14..*

{ordered}約束關(guān)系圖0..*1..*{ordered}保險合同個人計本學(xué)生軟件工程

{or}管理信息系統(tǒng)華南理工大學(xué)84軟件需求分析與建模對泛化的約束的兩種表示方法約束可分為：對泛化的約束、關(guān)聯(lián)的約束

對泛化的約束應(yīng)用于泛化的約束，顯示在大括號里，若有多個約束，用逗號隔開。如果沒有共享，則用一條虛線通過所有繼承線，并在虛線的旁邊顯示約束，如下圖所示：{constraint2,constraint3}ClassAClassBClassCClassD{constraint1,constraint2}ClassAClassCClassBClassD{constraint1}華南理工大學(xué)85軟件需求分析與建模 對泛化有以下常用的約束：

1、完全（complete）:說明泛化中所有子元素都已在模型中說明，不允許再增加其它子元素。

2、互斥（disjoint）:父類對象不能有多于一個型的子對象。

3、不完全（incomplete）:說明不是泛化中所有子元素都已說明，允許再增加其它子元素。

4、重疊（overlapping）:給定父類對象可有多于一個型的子對象，表示重載。華南理工大學(xué)86軟件需求分析與建模帳號人單位{xor}對象類的xor關(guān)聯(lián) 對關(guān)聯(lián)有以下常用的約束：

1、隱式（implicit）:該關(guān)聯(lián)只是概念性的，在對模型進行精化時不再用。

2、有序（ordered）:具有多重性的關(guān)聯(lián)一端的對象是有序的。

3、可變（changeable）:關(guān)聯(lián)對象之間的鏈(Link)是可變的（添加、修改、刪除）。

4、只增（addonly）:可在任意時刻增加新的鏈接。

5、凍結(jié)（frozen）:凍結(jié)已創(chuàng)建的對象，不能再添加、刪除和修改它的鏈接。

6、xor:“或約束”，某時刻只有一個當(dāng)前的關(guān)聯(lián)實例。

關(guān)聯(lián)的約束華南理工大學(xué)87軟件需求分析與建模(4)標準擴展UML的擴展機制應(yīng)有節(jié)制地使用，避免產(chǎn)生過多的“方言”而影響UML交流功能的發(fā)揮。為此，UML提供了一些標準的擴展元素，稱為標準擴展（standardelements）標準擴展可適用于大多數(shù)軟件系統(tǒng)的建模，因此在建模時，通常應(yīng)優(yōu)先使用這些標準的擴展元素，其次再考慮設(shè)計自己的擴展元素華南理工大學(xué)88軟件需求分析與建模（4）標準擴展：文檔文檔(documentation)是一個標記值，可以用于所有的UML建模元素。其取值可以是對此建模元素的注釋、描述或解釋在一些工具里，此標記值不通過標準的標記值的圖形表達法顯示，而是在其用戶界面上用一個標準窗口來顯示。華南理工大學(xué)89軟件需求分析與建模標記值：文檔

某些工具（RationalRose）將文檔作為建模對象的規(guī)格說明窗口的一部分華南理工大學(xué)90軟件需求分析與建模（4）標準擴展：標準構(gòu)造型UML是一個通用的建模語言，它的建模對象不僅僅局限于軟件系統(tǒng)在用UML進行軟件系統(tǒng)的分析設(shè)計時，需要對這些建模元素的語義進行強化，這如同在人類的自然語言在不同的專業(yè)領(lǐng)域有不同的專業(yè)術(shù)語一樣。華南理工大學(xué)91軟件需求分析與建模1)、系統(tǒng)作用者系統(tǒng)作用者（actor）是在進行軟件系統(tǒng)的用例分析時必須用到的概念系統(tǒng)作用者是類的構(gòu)造型，代表位于系統(tǒng)之外，但又和系統(tǒng)相關(guān)聯(lián)的對象系統(tǒng)作用者的圖形表示UML用一個人形圖符表示系統(tǒng)作用者可以用系統(tǒng)作用者代表軟件系統(tǒng)的使用者位于系統(tǒng)之外的軟件系統(tǒng)、硬件系統(tǒng)華南理工大學(xué)92軟件需求分析與建模2)、控制類／邊界類／實體UML對軟件系統(tǒng)的分析和設(shè)計是從軟件的體系結(jié)構(gòu)出發(fā)的。在對軟件體系結(jié)構(gòu)的四個視圖（用例視圖、邏輯視圖、部件視圖、分布視圖）進行分析和設(shè)計時，需要對UML進行語義的強化。這時可以使用：控制類邊界類實體類它們是對這種強化的標準概括，它們都是類的構(gòu)造型。華南理工大學(xué)93軟件需求分析與建模控制類（controlclass）控制類代表一類控制或啟動交互的對象。它的行為通常都是針對于一個特定的用例，它的對象一般只存在于此用例的協(xié)同中。例如在窗口操作系統(tǒng)中，對話框內(nèi)的控制鈕就可以用控制類來建模。其它的諸如操作系統(tǒng)命令窗口，設(shè)備控制器等也是控制類的建模對象控制類的圖形化表示：在UML里，控制類被圖形化表示為一個帶有箭頭的圓圈。華南理工大學(xué)94軟件需求分析與建模邊界類（boundaryclass）邊界類的定義：邊界類代表處于系統(tǒng)邊界上，不但和系統(tǒng)內(nèi)部對象交互，而且又和系統(tǒng)外部的系統(tǒng)作用者交互的一類對象。例如：軟件系統(tǒng)的通用外部設(shè)備如打印機、顯示器、鍵盤及其驅(qū)動軟件等，可以用邊界對象建模。邊界類的圖形化表示邊界類被圖形化描述為帶有T形連接的圓圈。華南理工大學(xué)95軟件需求分析與建模實體類(entityclass)：實體類是一類被動的對象，它本身不會啟動交互，可以參加多個用例的交互，并且存活于任何單獨的交互之外。通常，軟件系系統(tǒng)中的文件、數(shù)據(jù)庫等，可以用實體類建模。實體類圖形化表示實體類被圖形化描述為和一條短直線在底部相切的圓圈。華南理工大學(xué)96軟件需求分析與建模邊界類User(fromActors)ZoomIn

Buttom(fromUserInterfaceDesign)顯示(from圖3.2)位圖文件(from圖3.2)控制類實體類系統(tǒng)作用者華南理工大學(xué)97軟件需求分析與建模注意事項在使用UML的標注和擴充機制進行建模時，應(yīng)注意的一條重要原則是：UML建模的目的是交流，因此，可以充分利用標注的強化模型的可讀性的功能，通過標注對建模元素的語義進行直觀的解釋和說明標注內(nèi)可以包含任內(nèi)容，甚至可以以包含圖形，如果標注內(nèi)容較長，則可把內(nèi)容存放在一個分開的文件內(nèi)，在標注上指明此文件的位置。華南理工大學(xué)98軟件需求分析與建模UML2.0的變化OMG于2000年9月頒布了UML2.0的建議征集書（