南郵普本《UML系統(tǒng)分析與設(shè)計》期末考試復(fù)習(xí)(2018版v2)

UML系統(tǒng)分析與設(shè)計班級A：B150411-12課堂授課：第1-9、11-15周周二第8-9節(jié)，教4－204第2、4、8、10、12、14周四第6-7節(jié)，教4－204課程實驗：第7、9、11、13周周四第8-9節(jié)

軟信實驗室（計算機學(xué)科樓）課程考試考核方式和成績評定平時成績：共占總評的30%。根據(jù)出勤和上課情況、作業(yè)、實驗等方面綜合打分。期末考試：占總評的70%。筆試、閉卷、中文。課程總成績=平時成績+期末考試成績。考試安排待定請關(guān)注教務(wù)處通知

考試:題型與分值客觀題：選擇題（10小題，每題2分）：20分填空題（5小題，每題2分）：10分判斷題（5小題，每題2分）：10分名詞解釋題（2小題，每題5分）：10分簡答題（3小題，每題6分）：18分解答題（2小題，每題10分）：20分主觀題綜合題：12分考試:范圍選擇題、填空題、判斷題見精簡PPT名詞解釋題（課本附錄A等）構(gòu)件圖關(guān)聯(lián)類構(gòu)造型限定符組合狀態(tài)重數(shù)考試:范圍簡答題見作業(yè)題型解答題見作業(yè)題型綜合題類似課程實驗UML系統(tǒng)分析與設(shè)計（精簡）班級A：B150411-12等第1講:統(tǒng)一建模語言概述1.1軟件建模為什么軟件建模？模型可以促進項目有關(guān)人員對系統(tǒng)的理解和交流模型有助于挑選出代價較小的解決方案模型可以縮短系統(tǒng)的開發(fā)周期怎樣軟件建模？1.抽象出系統(tǒng)的不同視圖2.用精確的表示法來建立模型3.在模型轉(zhuǎn)換為實現(xiàn)的過程中逐漸添加進相關(guān)細(xì)節(jié)成功建模的三要素表示法工具過程第1講:統(tǒng)一建模語言概述1.1軟件建模分析與設(shè)計模型描述現(xiàn)實世界應(yīng)用的結(jié)構(gòu)（分析階段)描述被提議軟件系統(tǒng)的結(jié)構(gòu)（設(shè)計階段）面向?qū)ο蠓椒ㄔ诜治雠c設(shè)計階段使用同樣的標(biāo)記法結(jié)構(gòu)化方法使用不同的分析與設(shè)計標(biāo)記法應(yīng)用系統(tǒng)UML主要構(gòu)成視圖(views)一個系統(tǒng)應(yīng)從不同的角度進行描述,從一個角度觀察到的系統(tǒng)稱為一個視圖（view）。視圖由多個圖（Diagrams）構(gòu)成，不是一個圖表（Graph）,而是在某一個抽象層上，對系統(tǒng)的抽象表示。要為系統(tǒng)建立一個完整的模型圖，需定義一定數(shù)量的視圖，每個視圖表示系統(tǒng)的一個特殊的方面。視圖把建模語言和系統(tǒng)開發(fā)時選擇的方法或過程連接起來。第1講:統(tǒng)一建模語言概述1.3

UML概念模型UML主要構(gòu)成視圖(views)第1講:統(tǒng)一建模語言概述1.3

UML概念模型設(shè)計視圖過程視圖實現(xiàn)視圖部署視圖用例視圖Use

caseView描述系統(tǒng)的外部特性、系統(tǒng)功能等。UML主要構(gòu)成視圖(views)第1講:統(tǒng)一建模語言概述1.3

UML概念模型設(shè)計視圖過程視圖實現(xiàn)視圖部署視圖用例視圖DesignView

描述系統(tǒng)設(shè)計特征，包括結(jié)構(gòu)模型視圖和行為模型視圖，前者描述系統(tǒng)的靜態(tài)結(jié)構(gòu)(類圖、對象圖)，后者描述系統(tǒng)的動態(tài)行為(交互圖、狀態(tài)圖、活動圖)。UML主要構(gòu)成視圖(views)第1講:統(tǒng)一建模語言概述1.3

UML概念模型設(shè)計視圖過程視圖實現(xiàn)視圖部署視圖用例視圖ProcessView表示系統(tǒng)內(nèi)部的控制機制。常用類圖描述過程結(jié)構(gòu)，用交互圖描述過程行為。UML主要構(gòu)成視圖(views)第1講:統(tǒng)一建模語言概述1.3

UML概念模型設(shè)計視圖過程視圖實現(xiàn)視圖部署視圖用例視圖DeploymentView配置視圖描述系統(tǒng)的物理配置特征。用配置圖表示。UML主要構(gòu)成視圖(views)第1講:統(tǒng)一建模語言概述1.3

UML概念模型設(shè)計視圖過程視圖實現(xiàn)視圖部署視圖用例視圖ImplementationView表示系統(tǒng)的實現(xiàn)特征，常用構(gòu)件圖表示。UML主要構(gòu)成模型元素(Modelelements)代表面向?qū)ο笾械念悾瑢ο?，關(guān)系和消息等概念構(gòu)成圖的最基本的常用的元素一個模型元素可以用于多個不同的圖中第1講:統(tǒng)一建模語言概述1.3

UML概念模型第2講:軟件開發(fā)過程2.1面向?qū)ο蟮能浖_發(fā)面向?qū)ο蟮能浖治霁@取用戶基本需求標(biāo)識類和對象定義類的結(jié)構(gòu)和層次表示類(對象)間的關(guān)系為對象行為建模第2講:軟件開發(fā)過程2.2

Rational統(tǒng)一過程RUP（RationalUnifiedProcess）二維開發(fā)模型在RUP中，軟件開發(fā)生命周期根據(jù)時間和RUP的核心工作流劃分為二維空間。第2講:軟件開發(fā)過程2.2

Rational統(tǒng)一過程RUP（RationalUnifiedProcess）二維開發(fā)模型在RUP中，工作流橫軸表示項目的時間維，是過程展開的生命周期特征，體現(xiàn)開發(fā)過程的動態(tài)結(jié)構(gòu)。第2講:軟件開發(fā)過程2.2

Rational統(tǒng)一過程RUP（RationalUnifiedProcess）9個核心工作流，分為6個核心過程工作流（CoreProcessWorkflows）和3個核心支持工作流（CoreSupportingWorkflows）。第2講:軟件開發(fā)過程2.2

Rational統(tǒng)一過程RUP（RationalUnifiedProcess）四個階段：軟件產(chǎn)品生命周期被分成單獨的開發(fā)周期：初始（先啟）、細(xì)化（精化）、構(gòu)造、發(fā)布（產(chǎn)品化）第2講:軟件開發(fā)過程2.2

Rational統(tǒng)一過程RUP（RationalUnifiedProcess）四個階段初始（先啟）：定義整個項目的范圍細(xì)化（精化）：制定項目計劃、描述功能、建立架構(gòu)框架構(gòu)造（構(gòu)建）：構(gòu)造軟件產(chǎn)品發(fā)布（產(chǎn)品化）：將軟件產(chǎn)品移交到最終用戶手中先啟精化構(gòu)建產(chǎn)品化時間第2講:軟件開發(fā)過程2.3

敏捷開發(fā)敏捷宣言人和交互重于過程和工具可以工作的軟件重于求全責(zé)備的文檔客戶合作重于合同談判隨時應(yīng)對變化重于循規(guī)蹈矩。團隊方法論工具第3講:用例圖3.0用例建模用例圖

用例圖是從用戶的角度來描述系統(tǒng)所實現(xiàn)的功能，它標(biāo)明了用例的參與者，同時確定了參與者和用例之間的關(guān)聯(lián)關(guān)系。在軟件的需求分析階段，往往采用用例圖來建立系統(tǒng)需求模型。第3講:用例圖3.0用例建模用例圖三種主要建模元素用例（UseCase）參與者（Actor）依賴、類屬和關(guān)聯(lián)關(guān)系用例圖可選元素注釋和約束包系統(tǒng)邊界框第3講:用例圖3.0用例建模用例圖元素之間的關(guān)系（relationship）關(guān)聯(lián)（association）包含（include）擴展（extend）泛化（generalization）第3講:用例圖3.1參與者具有某一種特定功能的角色，參與者是虛擬的概念，它可以是人，也可以是外部系統(tǒng)或設(shè)備等。參與用例的執(zhí)行過程通過向系統(tǒng)輸入或請求系統(tǒng)輸入某些事件來觸發(fā)系統(tǒng)的執(zhí)行由參與用例時所擔(dān)當(dāng)?shù)慕巧珌肀硎久總€參與者可以參與一個或多個用例參與者不是系統(tǒng)的一部分，它們處于系統(tǒng)的外部。

第3講:用例圖3.1參與者參與者間的關(guān)系在用例圖中，使用泛化關(guān)系來描述多個參與者之間的公共行為。參與者間的泛化關(guān)系第3講:用例圖3.2用例對系統(tǒng)、子系統(tǒng)或類與參與者交互動作序列的說明用例的執(zhí)行給參與者帶來可見的價值是對一組場景（腳本，scenarios)共同行為特征的抽象場景是用例的一次完整、具體的執(zhí)行過程；是在系統(tǒng)中按照某個順序執(zhí)行一系列相關(guān)動作，實現(xiàn)某種功能的操作集合多個用例組成系統(tǒng)，參與者以某種場景與系統(tǒng)交互，請求系統(tǒng)執(zhí)行用例，以獲得可見的價值用例與場景的關(guān)系，如同類與對象的關(guān)系用例表示符號：第3講:用例圖3.2用例：事件流事件流場景中系統(tǒng)行為的一個特定動作序列描述參與者執(zhí)行用例時，發(fā)生的所有可能交互腳本與用例的關(guān)系就象實例與類的關(guān)系，腳本是用例的一個實例。對一個用例的完整說明，包括：基本事件流(basiccourseofevents)：描述交互時的正常場景擴展事件流，即可選的或例外的事件流(alternativeandexceptionalcoursesofevents)：正常場景之外的情況第3講:用例圖3.2用例：關(guān)系1.參與者與用例之間的關(guān)聯(lián)（association）關(guān)系參與者到用例的單向箭頭只表示誰啟動用例，不考慮信息的雙向流動每個用例都由角色啟動，除了包含和擴展用例第3講:用例圖3.2用例：關(guān)系2.用例之間的泛化（generalization）關(guān)系原因：如果系統(tǒng)中的一個或幾個用例是某個一般用例的特殊化時，就需要使用用例的泛化關(guān)系。圖示：用例中的泛化關(guān)系用帶空心箭頭的實線來表示，箭頭的方向指向父用例說明：子用例表示父用例的特殊形式，子用例從父用例繼承行為和屬性，還可以添加自己的行為，或覆蓋、改變所繼承的行為。第3講:用例圖3.2用例：關(guān)系3.用例之間的包含（include）關(guān)系原因：（1）如果兩個以上用例有大量一致功能，可將這個功能分解到另一個用例中，其他用例可和這個用例建立包含關(guān)系。（2）一個用例功能太多，可用包含關(guān)系建模兩個小用例。第3講:用例圖3.2用例：關(guān)系3.用例之間的包含（include）關(guān)系包含關(guān)系把幾個用例的公共步驟分離成一個單獨的被包含用例。通常，把包含用例稱為客戶用例，被包含用例稱作提供者用例。第3講:用例圖3.2用例：關(guān)系3.用例之間的包含（include）關(guān)系圖示：帶構(gòu)造型《include》的虛線箭頭由基本用例指向被包含用例兩個以上的用例有共同功能，可分解到單獨用例，形成包含依賴執(zhí)行基本用例時，每次都必須調(diào)用被包含用例，被包含用例也可單獨執(zhí)行。注：一個用例功能過多需分解成小用例，構(gòu)成包含依賴。第3講:用例圖3.2用例：關(guān)系4.用例之間的擴展（extend）關(guān)系

擴展關(guān)系是把新行為插入到已有用例的方法基礎(chǔ)用例（被擴展用例）提供了一組擴展點，在這些新的擴展點中可以添加新的行為擴展用例提供了一組插入片段，這些片段能夠被插入到基礎(chǔ)用例的擴展點上第3講:用例圖3.2用例：關(guān)系4.用例之間的擴展（extend）關(guān)系基礎(chǔ)用例（被擴展用例）不必知道擴展用例的任何細(xì)節(jié)，它僅為其提供擴展點。基礎(chǔ)用例即使沒有擴展用例也是完整的，這點與包含關(guān)系有所不同。第3講:用例圖3.3用例圖系統(tǒng)功能模型圖，顯示系統(tǒng)與外部參與者交互作用圖中呈現(xiàn)參與者、用例，以及它們之間的關(guān)系對系統(tǒng)、子系統(tǒng)或類的行為進行可視化建模描述用戶的功能需求，強調(diào)誰在使用系統(tǒng)、系統(tǒng)可以完成哪些功能使用戶能夠理解如何使用圖中元素使開發(fā)者能夠?qū)崿F(xiàn)圖中元素注用例分析技術(shù)是一種公認(rèn)有效的用戶需求獲取、分析和描述技術(shù)第4講:類圖和對象圖

4.1

類和對象類（Class）的UML圖標(biāo)：屬性屬性（Attribute）是類的命名的性質(zhì)，屬性在類圖標(biāo)的屬性分隔框中用文字串說明。屬性有在類中唯一的屬性名或標(biāo)識符。冒號“:”后跟屬性值的數(shù)據(jù)類型。屬性名后跟的方括號中的內(nèi)容是可選項目。多重性（Multiplicity）用多值表達式表示，其值是該類的每個實例的屬性值的個數(shù)。多值表達式的格式為：integer，integer，…或低界..高界屬性可視性屬性名[多重性]：類型=初始值第4講:類圖和對象圖

4.1

類和對象類（Class）的UML圖標(biāo)：屬性—可視性可視性（Visibility）用以下可視性標(biāo)記表示：+（公共），#（保護），–（私用）可視性也可以用以下關(guān)鍵字表示：public（公共）、protected（保護）、private（私用）若可視性標(biāo)記為“+”或“public”，則為公共屬性，可以被外部對象訪問。若可視性標(biāo)記為“#”或“protected”，則為保護屬性，可以被本類或子類的對象訪問。若可視性標(biāo)記為“–”或“private”，則為私用屬性，不可以被外部對象訪問，只能為本類的對象使用?？梢曅钥梢匀笔?，表示該屬性不可視。第4講:類圖和對象圖

4.1

類和對象類的UML圖標(biāo)：操作（類的行為特征或動態(tài)特征）一個類可以有多個操作，也可以沒有一個操作；沒有一個操作的類常用于表達接口或數(shù)據(jù)表。操作用文字串說明，在類中有唯一的操作名或標(biāo)識符。參數(shù)列表是可選項目，即一個操作可以有參數(shù)，也可以沒有參數(shù)，由逗號分隔的操作的形式參數(shù)組成，其格式為：參數(shù)名：類型=缺省值，…返回列表由逗號分隔的操作的返回值類型表達式組成，其格式為：返回類型或返回名字=類型，…操作可視性操作名（參數(shù)列表）：返回列表（性質(zhì)）第4講:類圖和對象圖

4.1

類和對象類的UML圖標(biāo)：總結(jié)類（Class）具有相似結(jié)構(gòu)、行為和關(guān)系的一組對象的描述組成名稱：類的唯一標(biāo)識屬性：描述類的靜態(tài)特征操作：說明類所提供的服務(wù)職責(zé)：定義類的責(zé)任和義務(wù)約束：指明類滿足的規(guī)則符號第4講:類圖和對象圖

4.1

類和對象類的UML圖標(biāo)：總結(jié)屬性[可見性]屬性名[:類型][‘[’多重性[次序]‘]’][=初始值][{特性}]可見性：可訪問性多重性：屬性值個數(shù)格式次序：屬性值順序特性：屬性約束操作[可見性]操作名[(參數(shù)列表)][:返回類型][{特性}]第4講:類圖和對象圖

4.1

類和對象類的UML圖標(biāo)：接口類、抽象類、模板類接口：一組操作的集合，只有操作的聲明而沒有實現(xiàn)標(biāo)準(zhǔn)圖形、變體圖形，沒有屬性不要求實現(xiàn)類和接口類概念本質(zhì)上是一致的，僅是實現(xiàn)了接口類定義者的契約抽象類：不能被實例化的類，一般至少包含一個抽象操作類名、抽象操作名均為斜體模版類：一種參數(shù)化的類，在編譯時把模版參數(shù)綁定到不同的數(shù)據(jù)類型，從而產(chǎn)生不同的類；模版化的類具有相同行為，但數(shù)據(jù)類型不同。(標(biāo)準(zhǔn)圖形)(變體圖形)接口抽象類模版參數(shù)模版類第4講:類圖和對象圖

4.1

類和對象類的UML圖標(biāo)：分析類邊界類（boundary）邊界類處理系統(tǒng)環(huán)境與系統(tǒng)內(nèi)部之間的通信，邊界類為用戶或另一個系統(tǒng)（即參與者）提供了接口，例如窗體、對話框、報表、與外部設(shè)備或系統(tǒng)交互的類等邊界類可以通過用例確定，因為參與者必須通過邊界類參與用例邊界類的UML符號表示：第4講:類圖和對象圖

4.1

類和對象類的UML圖標(biāo)：分析類實體類（entity）實體類是模擬必須被存儲的信息和其關(guān)聯(lián)行為的類。保存永久信息，最終可能映射數(shù)據(jù)庫中的表和字段實體類的UML符號表示：第4講:類圖和對象圖

4.1

類和對象類的UML圖標(biāo)：分析類控制類（control）控制類是用來為特定于一個或多個用例的控制行為建模的類。一個用例有一個控制類，協(xié)調(diào)其他類工作和控制總體邏輯流程例如：命令處理程序第4講:類圖和對象圖

4.1

類和對象對象（Object）的UML圖標(biāo)對象是唯一的，可以標(biāo)識的；每個對象都是不同的，即使它具有相同的屬性。對象的UML圖標(biāo)用實線矩形框表示，含有若干分隔框。對象名分隔框中包含一個對象的名字，對象名的格式為：

對象名:類名對象名分隔框中的狀態(tài)列表，表示該對象的并發(fā)狀態(tài)。對象的屬性分隔框含有該對象的屬性值。對象圖標(biāo)不含有操作框。第4講:類圖和對象圖

4.2關(guān)系類之間的關(guān)系關(guān)聯(lián)（association）泛化（generalization）實現(xiàn)（realization）依賴（dependence）聚合組合第4講:類圖和對象圖

4.2關(guān)系關(guān)聯(lián)（association）關(guān)聯(lián)用一條把類連接在一起的實線表示，一個關(guān)聯(lián)至少有兩個關(guān)聯(lián)端，每個關(guān)聯(lián)端連接到一個類，關(guān)聯(lián)端是有序的。關(guān)聯(lián)線旁可以標(biāo)出關(guān)聯(lián)的名字，線旁的小實心三角箭頭表示關(guān)聯(lián)的方向，從源類指向目標(biāo)類，箭頭起關(guān)聯(lián)的導(dǎo)航作用。

第4講:類圖和對象圖

4.2關(guān)系關(guān)聯(lián)（association）關(guān)聯(lián)可以是單向的或雙向的，如果該關(guān)聯(lián)是雙向的，就不必標(biāo)出方向箭頭。在關(guān)聯(lián)端可有多重性標(biāo)記，規(guī)定該類中有多少個對象參與該關(guān)聯(lián)。在關(guān)聯(lián)的類圖標(biāo)旁可以標(biāo)出類的角色名（Role），角色表示被關(guān)聯(lián)的類參與關(guān)聯(lián)的特定的行為。

第4講:類圖和對象圖

4.2關(guān)系關(guān)聯(lián)（association）帶有限定符的關(guān)聯(lián)稱為限定關(guān)聯(lián)（QualifiedAssociation）。限定符的值確定如何劃分和標(biāo)識該關(guān)聯(lián)的目標(biāo)類的對象。源類的一個帶有限定符值的對象，唯一地選擇目標(biāo)類的一個劃分。目標(biāo)類的每一個對象只能是某一個劃分的成員。第4講:類圖和對象圖

4.2關(guān)系關(guān)聯(lián)（association）關(guān)聯(lián)本身也有特性，通過關(guān)聯(lián)類（AssociationClass）可以進一步描述關(guān)聯(lián)的屬性、操作，以及其他信息。第4講:類圖和對象圖

4.2關(guān)系關(guān)聯(lián)（association）總結(jié)雙向關(guān)聯(lián)單向關(guān)聯(lián)聚合關(guān)聯(lián)弱的整體與部分關(guān)系組合關(guān)聯(lián)強的整體與部分關(guān)系關(guān)聯(lián)類自反關(guān)聯(lián)限定關(guān)聯(lián)派生關(guān)聯(lián)第4講:類圖和對象圖

4.2關(guān)系關(guān)聯(lián)（association）：聚合（Aggregation）表示事物的部分/整體關(guān)系的較弱的情況。聚合也稱為“has-a”聯(lián)系。在關(guān)聯(lián)線端加一個小空心菱形表示聚合，菱形連接代表整體事物的類，稱之為聚合類，另一個關(guān)聯(lián)端連接代表部分事物的類。例：圓和多邊形是圖形格式的兩個聚合類第4講:類圖和對象圖

4.2關(guān)系關(guān)聯(lián)（association）：組合（Composition）表示事物的部分/整體關(guān)系的較強的情況。組合也稱為“contains-a”聯(lián)系。在關(guān)聯(lián)線端加一個小實心菱形表示組合，菱形連接代表整體事物的類，稱之為組合類，另一個關(guān)聯(lián)端連接代表部分事物的類。例：圓由點組成，“圓”是組合類，“點”是成分類；多邊形也是由點組成的，是一個組合類。第4講:類圖和對象圖

4.2關(guān)系關(guān)聯(lián)（association）：關(guān)聯(lián)類（Associationclass）既是關(guān)聯(lián)又是類，有屬于關(guān)聯(lián)類的屬性兩個類之間具有多對多的關(guān)系，并且有些屬性不屬于關(guān)聯(lián)兩端任何一個類第4講:類圖和對象圖

4.2關(guān)系泛化（generalization）一般元素與特殊元素的關(guān)系目的子類繼承、共享父類的屬性和操作可以使子類的實例用于任何父類被 聲明使用的地方，實現(xiàn)多態(tài)繼承父類的公共(public)和保 護（protected）特性被 子類繼承父類派生出的子類表面相同，行為不同第4講:類圖和對象圖

4.2關(guān)系泛化（generalization）：多態(tài)每個子類的實現(xiàn)方法各不相 同，但外界的調(diào)用是一樣的例如：

Shape*myShape; Line*myLine myLine=newLine; myShape=myLine；

myShape.draw();第4講:類圖和對象圖

4.2關(guān)系實現(xiàn)（realization）一個元素完成另外一個元素的操作功能例如：接口類及其實現(xiàn)接口沒有屬性，方法只聲明不實現(xiàn)，由實現(xiàn)類具體定義方法的實現(xiàn)部分第4講:類圖和對象圖

4.2關(guān)系對象之間的關(guān)系鏈接（link）

意味著導(dǎo)航，代表一個對象對另一對象的引用第4講:類圖和對象圖

4.3類圖最廣泛的一種UML模型，描述系統(tǒng)的結(jié)構(gòu)表述類、協(xié)作、接口及其關(guān)系類圖元素類、接口、協(xié)作、關(guān)系、注釋、約束等關(guān)系連接類、協(xié)作與接口注釋對類和接口進行說明約束對類和接口進行約束第4講:類圖和對象圖

4.4對象圖表示對象和對象之間鏈接關(guān)系的圖,類圖的實例表示對象和對象之間鏈接關(guān)系的圖表達了系統(tǒng)數(shù)據(jù)在給定時刻的一個“快照”，代表系統(tǒng)的一個局部狀態(tài)全部對象的鏈接圖，表達了系統(tǒng)的對象模型，對象模型是軟件開發(fā)OO方法學(xué)的核心。第5講:活動圖5.1活動圖的基本要素活動（Activity）：指示要完成某項工作的動作或表示工作流的步驟現(xiàn)實世界中的一項工作，如寫文章、修機器等（或者）執(zhí)行某個軟件的例行程序，如運行類中的操作等?；顒訄D的基本要素狀態(tài)轉(zhuǎn)移、動作流分支分叉、匯合泳道對象流...第5講:活動圖5.1活動圖的基本要素：狀態(tài)（State）狀態(tài)（State）：在對象的生命周期中滿足某些條件、執(zhí)行某些活動或等待某些事件時的一個條件或狀況使用帶圓端的方框表示動作狀態(tài)活動圖中最小單位的構(gòu)造塊，表示原子動作三個特性：原子性、不可中斷性、瞬時性活動狀態(tài)可被分解成其他子活動或動作狀態(tài)，能夠被中斷，占有有限的時間可理解為一個組合，其控制流由其他活動狀態(tài)或動作狀態(tài)組成。第5講:活動圖5.1活動圖的基本要素：狀態(tài)（State）狀態(tài)（State）：在對象的生命周期中滿足某些條件、執(zhí)行某些活動或等待某些事件時的一個條件或狀況使用帶圓端的方框表示特殊狀態(tài)起始狀態(tài)(startstate)：表示一個工作流程的開始，用實心圓點來表示。終止?fàn)顟B(tài)(endstate)：表示一個活動圖的最后和終結(jié)狀態(tài)，用實心圓點外加一個小圓圈來表示第5講:活動圖5.1活動圖的基本要素：動作狀態(tài)（ActionState）動作狀態(tài)（ActionState）：用于為實體的原子動作或算法的執(zhí)行步驟建立模型可以有入轉(zhuǎn)移，入轉(zhuǎn)移可以是動作流或?qū)ο罅?。至少有一條出轉(zhuǎn)移，它不是基于外部事件的，而是隱含表示內(nèi)部動作的完成。不能有入口動作和出口動作，也不能有內(nèi)部轉(zhuǎn)移。必須指定在單條泳道內(nèi)，表明負(fù)責(zé)該泳道的對象運行該動作狀態(tài)中的動作。在一張活動圖中，一個動作狀態(tài)允許多處出現(xiàn)，實際上這表示同一個動作的不同狀態(tài)。動作狀態(tài)必須延遲所有的無關(guān)事件。所謂無關(guān)事件是指不出現(xiàn)在動作狀態(tài)的出轉(zhuǎn)移中的事件。第5講:活動圖5.1活動圖的基本要素：轉(zhuǎn)移（transition）轉(zhuǎn)移（transition）：兩個狀態(tài)間的一種關(guān)系表示對象將在當(dāng)前狀態(tài)中執(zhí)行動作，并在某個特定事件發(fā)生或某個特定的條件滿足時進入后繼狀態(tài)。用一條簡單的實箭線表示一個轉(zhuǎn)移：第5講:活動圖5.1活動圖的基本要素：動作流（ActionFlow）動作流（ActionFlow）是一個實體的不同動作狀態(tài)之間的轉(zhuǎn)移，說明狀態(tài)之間的控制流。一個無條件的動作流代表無觸發(fā)轉(zhuǎn)移或完成轉(zhuǎn)移，對它不附加監(jiān)護條件，在一個動作狀態(tài)的動作完成后自動發(fā)生動作狀態(tài)的轉(zhuǎn)移，激活下一個動作狀態(tài)。在表示一個有條件的動作流的實箭線上需要標(biāo)出“[監(jiān)護條件]/動作”（動作部分可以缺省）。方括號中的保安條件是一個布爾表達式，當(dāng)其值為真時，執(zhí)行斜杠“/”后面的動作，發(fā)生動作狀態(tài)的轉(zhuǎn)移，進入下一個動作狀態(tài)。第5講:活動圖5.1活動圖的基本要素：分支（Branch）分支（Branch）：描述基于某個條件的可選擇路徑一個分支可以有一個進入轉(zhuǎn)移和兩個或多個輸出轉(zhuǎn)移。在每條輸出轉(zhuǎn)移上都有監(jiān)護條件表達式保護，當(dāng)且僅當(dāng)監(jiān)護條件表達式為真時，該輸出路徑才有效。在所有輸出轉(zhuǎn)移中，其監(jiān)護條件不能重疊，而且它們應(yīng)該覆蓋所有的可能性。分支在圖形表示上用菱形表示動作流可以有多條件的分支決策情況，分支決策可以是鏈?zhǔn)降暮头擎準(zhǔn)降牡?講:活動圖5.1活動圖的基本要素：分叉（fork）和匯合（join）分叉（fork）和匯合（join）在UML中使用分叉和匯合表示并行發(fā)生的事件流分叉表示把一個單獨的控制流分成兩個或多個并發(fā)的控制流。一個分叉可以有一個進入轉(zhuǎn)移和兩個或多個輸出轉(zhuǎn)移，每一個轉(zhuǎn)移表示一個獨立的控制流。匯合表示兩個或多個并發(fā)控制流的同步發(fā)生，一個匯合可以有兩個或多個進入轉(zhuǎn)移和一個輸出轉(zhuǎn)移。分叉和匯合應(yīng)該是平衡的分叉和匯合在圖形上都使用同步條來表示，同步條通常用一條粗的水平線（同步桿，Synchronizationbar）表示：第5講:活動圖5.1活動圖的基本要素：分叉（fork）和匯合（join）分叉（fork）和匯合（join）“分叉”同步桿有一條入轉(zhuǎn)移箭線和兩條或多條出轉(zhuǎn)移箭線，每一條表示一個獨立的控制流?！胺植妗北硎井?dāng)入轉(zhuǎn)移被觸發(fā)時，所有與出轉(zhuǎn)移對應(yīng)的活動就并行進行?！皡R合”同步桿有兩條或多條入轉(zhuǎn)移箭線和一條出轉(zhuǎn)移箭線，每一條表示一個獨立的控制流。在“匯合”之前的所有與入轉(zhuǎn)移對應(yīng)的活動一直是并行進行的。在“匯合”點這些并發(fā)的控制流實現(xiàn)同步，即只有當(dāng)所有的入轉(zhuǎn)移全部完成其活動后才發(fā)生一個出轉(zhuǎn)移。第5講:活動圖5.1活動圖的基本要素：泳道（swimlane）泳道（swimlane）將一個活動圖中的活動狀態(tài)進行分組，每一組表示一個特定的類、人或部門，他們負(fù)責(zé)完成組內(nèi)的活動。描述每個活動是由哪個對象負(fù)責(zé)完成每個組被稱為一個泳道，用一條垂直實線與鄰居分開每個活動都明確屬于一個泳道，不可以跨越泳道，而轉(zhuǎn)移則可以跨越泳道第5講:活動圖5.1活動圖的基本要素：對象流（objectstream）對象流（objectstream）包括依賴關(guān)系和對象的應(yīng)用被稱為對象流。對象流是動作和對象間的關(guān)聯(lián)對象流可用于對下列關(guān)系建模：動作狀態(tài)對對象的使用動作狀態(tài)對對象的影響在UML中，使用矩形表示對象，對象和動作之間使用帶箭頭的虛線連接，帶箭頭的虛線表示對象流第6講:交互圖（InteractionDiagram）6.1

順序圖描述了對象之間傳送消息的時間順序，用來表示用例中的行為順序。當(dāng)執(zhí)行一個用例行為時，順序圖中的每條消息對應(yīng)了一個類操作或狀態(tài)機中引起轉(zhuǎn)換的觸發(fā)事件。序列圖包含了4個標(biāo)記符號，分別是：對象類角色（ClassRole）生命線（Lifeline）消息（Message）激活（Activation）第6講:交互圖（InteractionDiagram）6.1

順序圖描述了對象之間傳送消息的時間順序，用來表示用例中的行為順序。順序圖包含了4個標(biāo)記符號，分別是：對象類角色（ClassRole）：矩形，符號與對象圖相同生命線（Lifeline）：虛線，表示對象生存期消息（Message）：箭頭線，表示對象間消息通信激活（Activation）：矩形條，表示對象正在執(zhí)行一些活動第6講:交互圖（InteractionDiagram）6.1

順序圖激活順序圖可以描述對象的激活（Activation）和去激活（Deactivation）。激活表示該對象被占用以完成某個任務(wù)去激活指的是對象處于空閑狀態(tài)，在等待消息。為了表示對象是激活的，可以將對象的生命線拓寬成為矩形。第6講:交互圖（InteractionDiagram）6.2

協(xié)作圖（UML2中的通信圖）描述對象之間的消息交互，強調(diào)對象在交互中承擔(dān)角色語義上與順序圖是完全等價的，可以相互轉(zhuǎn)換協(xié)作圖的組成元素對象類角色消息鏈接第6講:交互圖（InteractionDiagram）6.2

協(xié)作圖（UML2中的通信圖）作用描述、強調(diào)交互發(fā)生時，每個對象承擔(dān)的職責(zé)顯示對象相互協(xié)作時充當(dāng)?shù)慕巧珡娬{(diào)交互的時間和序列，選擇順序圖建模強調(diào)交互的上下文相關(guān)，選擇協(xié)作圖建模闡明對象之間交互的角色，以實現(xiàn)特定用例或用例中特定部分的行為，便于確定類的職責(zé)和接口第7講:狀態(tài)機圖7.1狀態(tài)機狀態(tài)機被定義為一個行為狀態(tài)機表示一個模型元素在其生命期間的情況：從該模型元素的開始狀態(tài)起，響應(yīng)事件，執(zhí)行某些動作，引起轉(zhuǎn)移到新狀態(tài)，又在新狀態(tài)下響應(yīng)事件，執(zhí)行動作，引起轉(zhuǎn)移到另一個狀態(tài)，如此繼續(xù)，直到終結(jié)狀態(tài)。UNIX進程的狀態(tài)和轉(zhuǎn)移狀態(tài)機概念編譯技術(shù):用有限狀態(tài)機描述詞法分析過程操作系統(tǒng):進程調(diào)度、緩沖區(qū)調(diào)度等采用狀態(tài)機描述UML:對系統(tǒng)的動態(tài)特征建模第7講:狀態(tài)機圖7.1狀態(tài)機狀態(tài)機組成狀態(tài)（State）：一個模型元素在生存期的一種狀況，如滿足某些條件，進行某些活動，或等待某些事件的出現(xiàn)等。一個狀態(tài)在一個有限的時間段內(nèi)存在。轉(zhuǎn)移（Transition）：一個模型元素的不同狀態(tài)之間的聯(lián)系。在事件的觸發(fā)下，一個狀態(tài)可以轉(zhuǎn)移到另一個狀態(tài)。事件（Event）：一個有意義的出現(xiàn)（Occurrence）的說明。該出現(xiàn)在某個時間和空間點發(fā)生，并且立即觸發(fā)一個狀態(tài)的轉(zhuǎn)移。活動（Activity）：在狀態(tài)機中進行的一個非原子的執(zhí)行，它由一系列的動作組成。動作（Action）：一個可執(zhí)行的原子計算，它導(dǎo)致狀態(tài)的變更或返回一個值。第7講:狀態(tài)機圖7.2狀態(tài)機圖狀態(tài)機圖的圖形元素

1．狀態(tài)狀態(tài)用一個帶圓角的矩形框表示，框內(nèi)標(biāo)有狀態(tài)的名稱和其他一些信息狀態(tài)圖標(biāo)可以進一步劃分成3個分隔框：名稱框、內(nèi)部轉(zhuǎn)移框和嵌套狀態(tài)機圖框在名稱框中標(biāo)出狀態(tài)的名稱在內(nèi)部轉(zhuǎn)移框中規(guī)定動作或活動簡單狀態(tài)：嵌套狀態(tài)機圖分隔框可缺省組合狀態(tài)（CompositeState）：包含有子狀態(tài)，在嵌套狀態(tài)機圖的分隔框內(nèi)放置被嵌套的子狀態(tài)機圖。狀態(tài)的圖形表示

第7講:狀態(tài)機圖7.2狀態(tài)機圖狀態(tài)機圖的圖形元素

2．轉(zhuǎn)移轉(zhuǎn)移用實箭線表示，箭尾連接出發(fā)狀態(tài)，即源狀態(tài)，箭頭連接到達狀態(tài)，即目標(biāo)狀態(tài)。在箭線上可以標(biāo)示與該轉(zhuǎn)移有關(guān)的選項：事件、監(jiān)護條件（GuardCondition）和動作。當(dāng)處于源狀態(tài)的對象接收到一個事件，并且監(jiān)護條件得到滿足（如果有監(jiān)護條件的話）時，則執(zhí)行相應(yīng)的動作，并從源狀態(tài)轉(zhuǎn)移到目標(biāo)狀態(tài)。如果在轉(zhuǎn)移箭線上不標(biāo)示觸發(fā)轉(zhuǎn)移的事件時，則從源狀態(tài)轉(zhuǎn)移到目標(biāo)狀態(tài)是自動進行的。第7講:狀態(tài)機圖7.2狀態(tài)機圖狀態(tài)機圖的圖形元素3．初始狀態(tài)（InitialState）模型元素的初始狀況，代表一個狀態(tài)機圖的起始點，是一個偽狀態(tài)（PseudoState）用一個實心的圓表示4．終結(jié)狀態(tài)（FinalState）

模型元素的最后的狀態(tài)，代表一個狀態(tài)機圖的終止點，是一個偽狀態(tài)。用一個圓中套一個小實心圓表示。第7講:狀態(tài)機圖7.2狀態(tài)機圖狀態(tài)機圖的圖形元素5．判定（Decision）在狀態(tài)機圖中的一個特定的位置，工作流（Workflow）在此按監(jiān)護條件的取值而發(fā)生分支。用空心小菱形表示。一般，判定只有一個入轉(zhuǎn)移和兩個出轉(zhuǎn)移，監(jiān)護條件為布爾表達式。根據(jù)監(jiān)護條件表達式的值為“真”或“假”，觸發(fā)不同的分支轉(zhuǎn)移。判定也可以是有一個入轉(zhuǎn)移和多個出轉(zhuǎn)移。第7講:狀態(tài)機圖7.2狀態(tài)機圖狀態(tài)機圖的圖形元素6．同步（Synchronization）同步可視化地定義了并發(fā)工作流的分叉（Fork）與匯合（Join）。分叉是一個源狀態(tài)分為兩個或兩個以上的目標(biāo)狀態(tài)，匯合是兩個以上的源狀態(tài)連接為一個目標(biāo)狀態(tài)。在分叉與匯合之間的工作流是并行執(zhí)行的。同步在狀態(tài)機圖中用一條粗短實線表示，稱為同步桿第7講:狀態(tài)機圖7.3狀態(tài)組合狀態(tài)一個不含內(nèi)嵌套狀態(tài)的狀態(tài)，稱為簡單狀態(tài)。如果一個狀態(tài)內(nèi)嵌套了若干個狀態(tài)，則稱該狀態(tài)為超狀態(tài)（Superstate）或組合狀態(tài)（CompositeState），其中被嵌套的狀態(tài)稱為子狀態(tài)（Substate）。子狀態(tài)本身仍然可以是一個組合狀態(tài)。超狀態(tài)中的每一個被嵌套的狀態(tài)機圖所表示的子狀態(tài)機，都對應(yīng)于該超狀態(tài)內(nèi)的正在進行的一個活動。子狀態(tài)機圖的所在區(qū)域必有自己的初始狀態(tài)和終結(jié)狀態(tài)。對組合狀態(tài)的一個入轉(zhuǎn)移代表對其子區(qū)域內(nèi)的初始狀態(tài)的入轉(zhuǎn)移；對子區(qū)域內(nèi)的終結(jié)狀態(tài)的轉(zhuǎn)移代表包含它的組合狀態(tài)的相應(yīng)活動的完成。注意，動作（Action）與活動（Activity）的含義是不同的。第7講:狀態(tài)機圖7.3狀態(tài)歷史狀態(tài)在一個組合狀態(tài)中所包含的一個由順序子狀態(tài)構(gòu)成的子狀態(tài)機中，必定有一個子初始狀態(tài)。每次進入該組合狀態(tài)，被嵌套的子狀態(tài)機從它的子初始狀態(tài)開始運作（除非直接轉(zhuǎn)移到特定的子狀態(tài)）。有的情況下，當(dāng)離開一個組合狀態(tài)后，又重新進入該組合狀態(tài)，但是不希望從它的子初始狀態(tài)開始運作，而是直接進入到上次離開該組合狀態(tài)時的最后一個子狀態(tài)。歷史狀態(tài)（HistoryState）代表上次離開組合狀態(tài)時的最后一個活動子狀態(tài)。每當(dāng)轉(zhuǎn)移到組合狀態(tài)中的歷史狀態(tài)時，對象便恢復(fù)上次離開該組合狀態(tài)時的最后一個活動子狀態(tài)，并執(zhí)行入口動作。第7講:狀態(tài)機圖7.3狀態(tài)歷史狀態(tài)歷史狀態(tài)用一個含有字母“H”的小圓圈表示。歷史狀態(tài)只是一個偽狀態(tài)（PseudoState）的圖形標(biāo)記，只能作為一個組合狀態(tài)中的子狀態(tài)，不能在頂層狀態(tài)機圖中使用。歷史狀態(tài)可以有任意個從外部狀態(tài)來的入轉(zhuǎn)移，至多有一個無標(biāo)簽的出轉(zhuǎn)移，它進入到一個子狀態(tài)機。一個影碟機對象工作的部分狀態(tài)機圖第7講:狀態(tài)機圖7.6狀態(tài)機圖的應(yīng)用7.6.2CD播放器小結(jié)第8講:物理圖（PhysicalDiagram）8.0

導(dǎo)引UML提供了兩種物理表示圖形：構(gòu)件圖和部署圖。構(gòu)件圖表示系統(tǒng)中的不同物理構(gòu)件及其關(guān)系。表達的是系統(tǒng)代碼本身的結(jié)構(gòu)。部署圖由節(jié)點構(gòu)成，節(jié)點代表系統(tǒng)的硬件，構(gòu)件在節(jié)點上駐留并執(zhí)行。表示系統(tǒng)的軟件構(gòu)件與硬件之間的關(guān)系。表達的是運行系統(tǒng)的結(jié)構(gòu)。構(gòu)件圖和部署圖用于建立系統(tǒng)的實現(xiàn)模型。第8講:物理圖（PhysicalDiagram）8.1

構(gòu)件圖（ComponentDiagram）1、構(gòu)件的定義系統(tǒng)的物理的可替換的單位，它把系統(tǒng)的實現(xiàn)打包，并提供一組接口的實現(xiàn)（Realization）。代表系統(tǒng)的一個物理實現(xiàn)塊，代表邏輯模型元素如類、接口、協(xié)同等的物理打包。本身遵從和提供一組接口的實現(xiàn)，它們代表了由駐留在構(gòu)件內(nèi)部的模型元素所實現(xiàn)的服務(wù)。用于對系統(tǒng)配置節(jié)點上的物理事物建立模型。構(gòu)件的類型系統(tǒng)的配置構(gòu)件，如COM+構(gòu)件、JavaBeans等。軟件開發(fā)過程中的產(chǎn)物，如軟件代碼（源碼、二進制碼和可執(zhí)行碼）等。第8講:物理圖（PhysicalDiagram）8.1

構(gòu)件圖2、構(gòu)件的表示法圖標(biāo)是一個大矩形的左邊嵌二個小矩形。必須有名字在構(gòu)件名之后或之下，可以用括在花括號中的文字（即標(biāo)記值）說明構(gòu)件的性質(zhì)，如“{version=2.0}”等。第8講:物理圖（PhysicalDiagram）8.1構(gòu)件圖8、構(gòu)件的依賴關(guān)系依賴關(guān)系圖publicclassA{ ……}publicclassBextendsA{ ……}publicclassA{ publicvoidanOperation(BtheB){ ……}}第8講:物理圖（PhysicalDiagram）8.1構(gòu)件圖8、構(gòu)件的依賴關(guān)系依賴關(guān)系圖publicclassA{ privateBaLink; ……}}第8講:物理圖（PhysicalDiagram）8.1構(gòu)件圖9、構(gòu)件圖：定義構(gòu)件圖由構(gòu)件、接口和構(gòu)件之間的關(guān)系構(gòu)成，其中的構(gòu)件可以是源碼、二進制碼或可執(zhí)行程序。表示系統(tǒng)中的不同物理部件及其關(guān)系，它表達的是系統(tǒng)代碼本身的結(jié)構(gòu)。只有型（Type）的形式，沒有實例形式。為了顯示構(gòu)件的實例需要使用部署圖。用于下列事物建立模型：系統(tǒng)的源代碼、系統(tǒng)的發(fā)布版本、物理數(shù)據(jù)庫、自適應(yīng)系統(tǒng)等。建立業(yè)務(wù)模型，此時的構(gòu)件是業(yè)務(wù)的過程和文檔。建立開發(fā)期間的軟件產(chǎn)物的依賴關(guān)系，用于系統(tǒng)開發(fā)的管理。第8講:物理圖（PhysicalDiagram）8.2

部署圖（DeploymentDiagram）1、節(jié)點的定義存在于運行期間的系統(tǒng)的物理元素代表計算機資源，通常為處理器（Processor）或其他硬件設(shè)備，系統(tǒng)的構(gòu)件可以配置在節(jié)點上。圖標(biāo)為一個三維立方體圖形，如下圖所示。第8講:物理圖（PhysicalDiagram）8.2部署圖1、節(jié)點的定義存在于運行期間的系統(tǒng)的物理元素節(jié)點必須有名字，可以是一個簡單名，或用路徑名。與類一樣，節(jié)點可以用標(biāo)記值說明名字的性質(zhì)。與類一樣，節(jié)點可以區(qū)分為型和實例，型代表計算資源的不同類型，實例代表特定的具體的計算機資源。對象和構(gòu)件實例可以駐留在節(jié)點實例上，而且可以從一個節(jié)點向另一個節(jié)點遷移。節(jié)點執(zhí)行構(gòu)件，構(gòu)件是被節(jié)點執(zhí)行的事物。一個節(jié)點可以與其它的節(jié)點、構(gòu)件、對象有關(guān)聯(lián)。節(jié)點和類、協(xié)同、構(gòu)件等模型元素一樣可以組織成包。第8講:物理圖（PhysicalDiagram）8.2部署圖2、節(jié)點的關(guān)系節(jié)點與節(jié)點通過物理連接（Connection）發(fā)生關(guān)系物理連接如以太網(wǎng)絡(luò)、共享總線等，從硬件方面保證了系統(tǒng)的節(jié)點協(xié)同運行。節(jié)點與節(jié)點、節(jié)點與構(gòu)件之間存在著多種類型的關(guān)系。第8講:物理圖（PhysicalDiagram）8.2部署圖2、節(jié)點的關(guān)系（1）通信關(guān)系（關(guān)聯(lián)）通信關(guān)系是節(jié)點之間的一種關(guān)聯(lián)，是節(jié)點之間的通信路徑或連接的模型。通信關(guān)系的表示法是用一條實關(guān)聯(lián)線連接兩個節(jié)點。在實關(guān)聯(lián)線上可以加構(gòu)造型以表達節(jié)點間的通信路徑或連接的性質(zhì)。通信關(guān)系表示法示例

第8講:物理圖（PhysicalDiagram）8.2部署圖2、節(jié)點的關(guān)系（2）成為關(guān)系成為關(guān)系是構(gòu)件與構(gòu)件、構(gòu)件與對象、對象與對象之間的依賴關(guān)系。成為關(guān)系不是節(jié)點之間的關(guān)系，但是它是構(gòu)件或?qū)ο笤诠?jié)點之間的遷移的模型。成為關(guān)系說明源對象（或構(gòu)件）和目標(biāo)對象（或構(gòu)件）是在不同時間點的同一個對象（或構(gòu)件），而且它們的狀態(tài)和角色不同。成為關(guān)系可以用標(biāo)記值“{time=…}”說明其時間性質(zhì)，即構(gòu)件或?qū)ο笤谑裁磿r間發(fā)生遷移活動。第8講:物理圖（PhysicalDiagram）8.2部署圖2、節(jié)點的關(guān)系（2）成為關(guān)系表示法是用一條虛箭線從一個節(jié)點中的構(gòu)件指向另一個節(jié)點中的構(gòu)件或從一個節(jié)點中的對象指向另一個節(jié)點中的對象，并可在虛箭線上加有構(gòu)造型<<becomes>>。成為關(guān)系表示法示例

第8講:物理圖（PhysicalDiagram）8.2部署圖3、部署圖的定義由節(jié)點與節(jié)點之間的關(guān)系構(gòu)成，包括構(gòu)件之間、節(jié)點與構(gòu)件之間、構(gòu)件與構(gòu)件之間的關(guān)系。表示分布式系統(tǒng)的軟件構(gòu)件與硬件之間的關(guān)系，它表達的是運行系統(tǒng)的結(jié)構(gòu)。主要用于對在網(wǎng)絡(luò)環(huán)境運行的分布式系統(tǒng)建立系統(tǒng)物理模型，或者對嵌入式系統(tǒng)建模?？梢杂糜诮I(yè)務(wù)模型，此時的“運行系統(tǒng)”就是業(yè)務(wù)的組織機構(gòu)和資源（人力、設(shè)備等）。第9講:模型管理圖9.1包：語義和表示包（Package）是一種對模型元素進行成組組織的通用機制。包用于定義一個名字空間（Namespace）或容器（Container），它本身是UML的一種模型元素。對包中的元素作為一個整體對待，并且控制它們的可視性和存取。包的圖標(biāo)是一個大矩形（內(nèi)容框）的左上角帶一個小矩形（名字框）名字可是一個簡單名或路徑名。在包名之后或之下，可用括在花括號中的文字（約束）說明包的性質(zhì)，如“{abstract}”、“{version}”等第9講:模型管理圖9.2包的聯(lián)系：依賴與輸入依賴包與包之間的聯(lián)系主要有兩種：依賴和泛化。依賴：兩個包所含模型元素之間存在著一個或多個依賴

對于由類組成的包，如果在兩個包的任何類之間存在著任何一種依賴，則這兩個包之間存在著依賴。包的依賴聯(lián)系同樣是用一條虛箭線表示，虛箭線從依賴包（源）指向獨立包（目標(biāo)）。包的依賴聯(lián)系沒有傳遞性。第9講:模型管理圖9.2包的聯(lián)系：依賴與輸入依賴包與包之間的聯(lián)系主要有兩種：依賴和泛化。包的依賴聯(lián)系可以加上許多構(gòu)造型規(guī)定它的語義，其中最常見的一種依賴是輸入依賴。輸入依賴（ImportDependency）是包與包之間的一種存?。ˋccess）依賴關(guān)系。輸入（Importing）是指允許一個包中的元素存取另一個包中的元素。輸入依賴是單向的，沒有傳遞性。包的公共部分，即其可視性為“公共”的模型元素，稱為包的輸出（Export）。包的輸出只對另一個與它有輸入依賴的包才是可視的、可存取的。注意：存取依賴聯(lián)系的另一個構(gòu)造型<<Access>>，與<<Import>>的含義略有差別。第9講:模型管理圖9.2包的聯(lián)系：合并包與包之間的聯(lián)系主要有兩種：依賴和泛化。包之間的合并聯(lián)系是一種依賴關(guān)系，用一條帶有構(gòu)造型<<Merge>>的虛箭線表示，從接受合并包（ReceivingPackage）指向被合并包（MergedPackage）。允許被合并包的內(nèi)容與接受合并包的內(nèi)容合并：即（在概念上而非物理上）把被合并包中的全部元素合并加入到接受合并包中被合并包與接受合并包中的那些具有相同名稱的元素則合并成一個唯一的元素，它擁有兩者的特征。當(dāng)定義在不同的包中的模型元素具有相同的名稱并且表達相同的概念時，就需要使用包合并聯(lián)系。第9講:模型管理圖9.2包的聯(lián)系：泛化包與包之間的聯(lián)系主要有兩種：依賴（尤其是輸入依賴）和泛化。泛化：特殊性包必須遵循一般性包的接口一般性包可加上一個性質(zhì)說明“{abstract}”，表明它只不過是定義了一個接口，該接口可以由多個特殊包實現(xiàn)。與類的繼承相同，特殊包從一般包繼承其所含的公共類，并且可重載和添加自己的類。特殊包可代替一般包，用在一般包使用的任何地方。第9講:模型管理圖9.3包圖包圖由包和包之間的聯(lián)系構(gòu)成。包圖的圖形節(jié)點是包，節(jié)點之間用弧（依賴或泛化）連接。包圖是維護和控制系統(tǒng)總體結(jié)構(gòu)的重要建模工具。包在很多方面與類相似，但是在建立系統(tǒng)模型時特別要注意區(qū)別包與類。類是問題領(lǐng)域或解決方案中的事物的抽象，包是把這些事物組織成模型的一種機制。包可以沒有標(biāo)識，因為它沒有實例，在運行系統(tǒng)中不可見；類必須有標(biāo)識，它有實例，類的實例（對象）是運行系統(tǒng)的組成元素。一個簡單的約束約束是布爾斷言（Booleanassertions）非形式寫出的約束應(yīng)當(dāng)用花括號“{}”括起來放在所描述的模型元素的內(nèi)部或緊靠所描述元素的地方也可放在注解的圖標(biāo)內(nèi)，用虛線連接到所描述的模型元素第10講:約束（Constraint）第10講:約束（Constraint）10.2對象約束語言對象約束語言（ObjectConstraintLanguage，OCL）用于表示UML模型中施加于模型元素上的約束。OCL是一種純表達式語言，它用表達式表示約束。OCL的表達式確保沒有副作用，對一個OCL表達式進行求值將返回一個值，它在系統(tǒng)模型中不改變。OCL是一種規(guī)格說明語言（SpecificationLanguage）。所有有關(guān)實現(xiàn)的問題都不能用OCL表達。OCL不是一種程序設(shè)計語言，不能用OCL編寫程序，不能用OCL編寫程序邏輯和控制流程。每個OCL約束有一個上下文將OCL表達式和被約束的模型元素連接在一起。約束能夠表示在圖上或者寫在一個獨立的文本文檔中附加到該模型。在被約束元素中在一個附加的注解（note）中第10講:約束（Constraint）10.3

約束的上下文（Context）人事系統(tǒng)第10講:約束（Constraint）10.4

導(dǎo)航表達式從上下文對象開始，我們沿著鏈接到達其他對象通過一個關(guān)聯(lián)進行導(dǎo)航，需要使用：關(guān)聯(lián)端的角色名（therolenameatthefarendoftheassociation）或者關(guān)聯(lián)端的類名（thenameoftheclassatthefarend）導(dǎo)航過程需要遍歷這個對象網(wǎng)的一部分，所以稱表示這些對象的表達是為導(dǎo)航表達式圓點標(biāo)識進行分隔第10講:約束（Constraint）10.4

導(dǎo)航表達式類不變量（ClassInvariants）類不變量是類的性質(zhì)，是指對該類的所有實例，在所有時間，該不變量為真?！癮naccount’sbalancemustbeinagivenrange”contextSavingsAccountinv: balance>0andbalance<25000第10講:約束（Constraint）10.7構(gòu)造型的約束前置條件（Preconditions）特別為操作而使用的約束前置條件（Preconditions

）表示的是在一個操作調(diào)用前必須為真的事情“youcanonlywithdrawanamountlessthanthebalanceinanaccount”contextSavingsAccount::withdraw(amt:Real)pre:amt<balance第10講:約束（Constraint）10.7構(gòu)造型的約束后置條件（Postconditions）后置條件（Postconditions）指明操作的結(jié)果，通過比較該操作執(zhí)行前和執(zhí)行后的屬性值表示?！皐ithdrawtheamountgiventoit”contextSavingsAccount::withdraw(amt:Real)post:balance=balance@pre-amt‘balance@pre’denotesthebalancebeforetheoperationexecuted第10講:約束（Constraint）10.7構(gòu)造型的約束第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：類的實現(xiàn)類第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：類的實現(xiàn)泛化第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：類的實現(xiàn)類的重數(shù)第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：類的實現(xiàn)關(guān)聯(lián)的實現(xiàn)：單向（初步）第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：類的實現(xiàn)關(guān)聯(lián)的實現(xiàn)：單向（改進）第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：類的實現(xiàn)關(guān)聯(lián)的實現(xiàn)：單向第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：類的實現(xiàn)關(guān)聯(lián)的實現(xiàn)：單向（可選關(guān)聯(lián)）第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：類的實現(xiàn)關(guān)聯(lián)的實現(xiàn)：雙向（引用完整性）第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：類的實現(xiàn)關(guān)聯(lián)的實現(xiàn)：雙向（兩個類同時維護關(guān)聯(lián)）第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：類的實現(xiàn)關(guān)聯(lián)的實現(xiàn)：雙向（一個類維護關(guān)聯(lián)）第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：類的實現(xiàn)關(guān)聯(lián)的實現(xiàn)：限定關(guān)聯(lián)第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：類的實現(xiàn)關(guān)聯(lián)的實現(xiàn)：關(guān)聯(lián)類第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：類的實現(xiàn)約束的實現(xiàn)第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：類的實現(xiàn)操作的實現(xiàn)第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：逆向工程（源代碼產(chǎn)生UML文檔）第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：逆向工程（源代碼產(chǎn)生UML文檔）第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：逆向工程（源代碼產(chǎn)生UML文檔）第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：逆向工程（源代碼產(chǎn)生UML文檔）第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：實現(xiàn)原則開-閉原則1988年，BertrandMeyer提出了開閉原則“軟件實體應(yīng)當(dāng)對擴展開放，對修改關(guān)閉”軟件系統(tǒng)中包含的各種組件，例如模塊（Modules）、類（Classes）以及功能（Functions）等等，應(yīng)該在不修改現(xiàn)有代碼的基礎(chǔ)上，引入新功能?！伴_”，是指對于組件功能的擴展是開放的，是允許對其進行功能擴展的；“閉”，是指對于原有代碼的修改是封閉的，即不應(yīng)該修改原有的代碼。第11講:統(tǒng)一建模語言應(yīng)用11.4

實現(xiàn)模型：實現(xiàn)原則無具體超類避免維護具體的超類Liskov替換原則Liskov于1987年提出了一個關(guān)于繼承的原則“繼承必須確保超類所擁有的性質(zhì)在子類中仍然成立?！币簿褪钦f，當(dāng)一個子類的實例應(yīng)該能夠替換任何其超類的實例時，它們之間才具有is-A關(guān)系。交互決定結(jié)構(gòu)根據(jù)對象之間的交互確定設(shè)計中的對象所屬的類之間的結(jié)構(gòu)關(guān)系UML系統(tǒng)分析與設(shè)計（習(xí)題）班級A：B150417班級B：B150411-12等作業(yè)11.3Asthetextmakesclear,thatitisimportanttodistinguishthefollowingtwothings:? TheuseofUMLnotationstodescribeasoftwaresystem;? TheuseofUMLnotationstosupportadevelopmentprocess.ItcouldbearguedthatbecauseUML,alongwithsimilarnotationsandlanguages,hasevolvedtosupportdevelopment,itsnotationscannotbeunderstoodwithoutreferencetotheiruseinthedevelopmentprocess.ItcanthereforehelpinlearningUMLtoconnectthevariousnotationswiththeirtypicaluses.Ontheotherhand,themeaningofthevariousdiagramsinnowaydependsontheiruseinoneoranotherprocess.Diagramsdocumentcertainpropertiesofasoftwaresystem,nottheprocessbywhichitwasdeveloped.作業(yè)11.3Asmanydifferentprocessesareusedfordevelopingsoftware,itisimportanttohaveanunderstandingofUMLnotationsthatisindependentoftheirapplicationinthedevelopmentprocess.Itismoreplausiblethattheroleofadesignprocessistoassistdesignerstoproducedesignsthatareinsomesense"well-structured".Theanalogywithprogramminglanguagesmighthelptomakethisclear.Simplyknowingthesyntaxofalanguagedoesnotmeanthatprogrammerswillautomaticallywriteelegant,maintainableandefficientprograms.Definitionofthesepropertiesisnotpartofthelanguageitself;itismoreaquestionoflearninghowthelanguageisbestapplied.MuchthesamegoesforadesignlanguagelikeUML,andoneroleforadesignprocessistoensurethatthedesignswhichareproducedhavetherequiredhigh-levelproperties.作業(yè)24.2作業(yè)24.2ThisdiagramisnotquiteequivalenttoFigure4.7.BothdiagramsspecifythesamecapabilitiesfortheReceptionistandHeadWaiteractors,butinadditionFigure4.7definesanactorStaffwhoonlyhastheabilitytodisplaybookings.Nosuchactorisdefinedinthediagramabove,thoughaStaffactorcouldeasilybeaddedifrequired.Becausethisisasimplediagram,thereisnotmuchdifferenceincomplexitybetweenthetwoversions.Inmorecomplicateddiagrams,however,theuseofactorgeneralizationcansignificantlyreducethenumberofassociationsthathavetobeshown,thussimplifyingthediagram.Theuseof"superactors"alsomakesiteasiertoseewhenusecasescanbeperformedbyavarietyofactors.作業(yè)32.2（中文課本第28頁）作業(yè)32.2（a）解答作業(yè)32.2（中文課本第28頁）作業(yè)32.2（b）解答作業(yè)32.2（中文課本第28頁）作業(yè)32.2（c）解答作業(yè)42.5（中文課本第30頁）作業(yè)42.5（a）解答作業(yè)42.5（b）解答Althoughitisplausibletoassumethattheorderofmessagesinthisdiagramischeckpoint;read;read;read;transcribe,thisassumptionisbasedentirelyonourknowledgeofthereal-worldsituationbeingmodelled.Onewayofspecifyingtheorderofmessageswouldbetonumberthem.WaysofspecifyingthesequencingofmessagesmoreformallyarediscussedinChapter9.Afurtherambiguityinthisdiagramisthatitisnotentirelyclearwhetherasingletranscribemessageissentafterallthedatahasbeenreadfromthesensors,orifeachreadisfollowedbyacorrespondingtranscribe.作業(yè)42.5（c）解答Aclassdiagramconsistentwiththeobjectdiagramgivenaboveisshownbelow.AnabstractSensorclassisintroducedsothatthethreelinksfromthemonitoringstationtotheindividualsensorobjectscanbemodelledbyoneassociation.作業(yè)58.2（中文課本第138頁）作業(yè)58.2（中文課本第138頁）作業(yè)58.2（a）解答作業(yè)58.2（b）解答作業(yè)58.2（c）解答作業(yè)58.2（d）解答作業(yè)58.2（e）解答作業(yè)68.3（中文課本第138頁）作業(yè)68.3解答(a)Valid.(b)Invalid,becauseaccordingtotheclassdiagrameveryinstanceofCmustbelinkedtopreciselyoneinstanceofclassD.So`standalone'instancesofCarenotpermitted.(c)Invalid,becausetheinstanceofclassDislinkedtotwoinstancesofclassC,contrarytotheclassdiagramwhichspecifiesthatitshouldbelinkedtoatmostoneinstanceofC.(d)Invalid,becausetheinstanceofclassCislinkedtotwoinstancesofclassD,contrarytotheclassdiagramwhichspecifiesthatitshouldbelinkedtoexactlyoneinstanceofD.(e)Invalid,becausethereisnoassociationintheclassdiagramforthelinkbetweenthetwoinstancesofclassDtobeaninstanceof.(f)Valid.InstancesofclassDareoptionallylinkedtoinstancesofclassC,sothereisnoproblemwitha`standalone'instanceofD.作業(yè)78.5（中文課本第138頁）作業(yè)78.5解答作業(yè)88.9（中文課本第140頁）作業(yè)88.9解答IftheabstractdrawoperationwasomittedfromtheShapeclass,itwouldbeimpossibletoinvokethe`draw'operationonashapewithoutknowingwhatsubclassitbelongedto.Inotherwords,codesuchasthefollowingwouldnotwork:Shapes=newRectangle();s.draw();作業(yè)88.9解答Itwouldbenecessarytocasttheobjecttoitsspecificsubclassfirst:Shapes=newRectangle();((Rectangle)s).draw();Thiswouldfrustrateamajorbenefitofusinggeneralization,namelyt