UML系統(tǒng)分析與設(shè)計(jì)教程(第2版) 課件全套 冀振燕 第1-15章 緒論、面向?qū)ο蠓治雠c設(shè)計(jì)方法 -嵌入式系統(tǒng)設(shè)計(jì)

UML系統(tǒng)分析與設(shè)計(jì)SystemAnalysis&Design第一章緒論統(tǒng)一建模語言UMLRational統(tǒng)一過程RUP工具UML系統(tǒng)分析與設(shè)計(jì)第2版2UML系統(tǒng)分析與設(shè)計(jì)第2版3UML的背景1989年到1994年，面向?qū)ο蠼ＵZ言從不到10種增加到了50多種。不同的建模語言具有不同的建模符號體系，妨礙了軟件設(shè)計(jì)人員、開發(fā)人員和用戶之間的交流。有必要建立一個(gè)標(biāo)準(zhǔn)的、統(tǒng)一的建模語言。統(tǒng)一建模語言UML的誕生結(jié)束了符號方面的“方法大戰(zhàn)”。UML統(tǒng)一了Booch方法、OMT方法、OOSE方法的符號體系，采納了其他面向?qū)ο蠓椒P(guān)于符號方面的許多好的概念。UML系統(tǒng)分析與設(shè)計(jì)第2版4UML的發(fā)展1989年到1994年，面向?qū)ο蠼ＵZ言從不到10種增加到了50多種。不同的建模語言具有不同的建模符號體系，妨礙了軟件設(shè)計(jì)人員、開發(fā)人員和用戶之間的交流。有必要建立一個(gè)標(biāo)準(zhǔn)的、統(tǒng)一的建模語言。統(tǒng)一建模語言UML的誕生結(jié)束了符號方面的“方法大戰(zhàn)”。UML統(tǒng)一了Booch方法、OMT方法、OOSE方法的符號體系，采納了其他面向?qū)ο蠓椒P(guān)于符號方面的許多好的概念。UML系統(tǒng)分析與設(shè)計(jì)第2版5UML的發(fā)展UML的建立開始于1994年10月。定義UML1.0時(shí)，DEC、HP、I-Logix、IntelliCorp、IBM、ICON計(jì)算（ICONComputing）、MCISystemhouse、Microsoft、Oracle、Rational、Texas儀器（TexasInstrumnets）、Unisys等公司都參與了該項(xiàng)工作。UML1.0定義完整、富于表達(dá)、功能強(qiáng)大，于1997年1月被提交給OMG（ObjectManagementGroup，對象管理組織），申請成為標(biāo)準(zhǔn)建模語言。2005年，UML2.0被OMG采納，UML2.0對UML1.x進(jìn)行了很多重大修改。UML系統(tǒng)分析與設(shè)計(jì)第2版6UML的內(nèi)容UML定義包括：UML語義描述了基于UML的精確元模型定義。UML表示法定義了UML符號的表示方法，為開發(fā)者或開發(fā)工具使用這些圖形符號和文本語法為系統(tǒng)建模提供了標(biāo)準(zhǔn)。UML主要特點(diǎn)UML統(tǒng)一了Booch、OMT、OOSE和其他面向?qū)ο蠓椒ǖ幕靖拍詈头枴ML系統(tǒng)分析與設(shè)計(jì)第2版7UML是一種建模語言，而不是一種方法。UML的功能為軟件系統(tǒng)的產(chǎn)物建立可視化模型。UML是一個(gè)標(biāo)準(zhǔn)的、被廣泛采用的建模語言，用UML建模有利于交流。UML為系統(tǒng)建立了圖形化的可視模型，使系統(tǒng)的結(jié)構(gòu)變得直觀，易于理解。UML為軟件系統(tǒng)建立模型不但有利于交流，還有利于對軟件的維護(hù)。規(guī)約軟件系統(tǒng)的產(chǎn)物。規(guī)約（Specifying）意味著建立的模型是準(zhǔn)確的、無歧義的、完整的。UML定義了在開發(fā)軟件系統(tǒng)過程中所做的所有重要的分析、設(shè)計(jì)和實(shí)現(xiàn)決策的規(guī)格說明。UML系統(tǒng)分析與設(shè)計(jì)第2版8UML的功能構(gòu)造軟件系統(tǒng)的產(chǎn)物。UML不是可視化的編程語言，但它的模型可以直接對應(yīng)到各種各樣的編程語言。前向工程:從UML模型生成編程語言代碼的過程。逆向工程:從代碼實(shí)現(xiàn)生成UML模型的過程。為軟件系統(tǒng)的產(chǎn)物建立文檔。UML可以為系統(tǒng)的體系結(jié)構(gòu)及其所有細(xì)節(jié)建立文檔。UML還可以為需求、測試、項(xiàng)目規(guī)劃活動(dòng)和軟件發(fā)布管理活動(dòng)建模UML系統(tǒng)分析與設(shè)計(jì)第2版9UML的組成元素結(jié)構(gòu)元素行為元素分組元素注釋元素UML系統(tǒng)分析與設(shè)計(jì)第2版10圖結(jié)構(gòu)建模圖類圖、對象圖、組件圖、組合結(jié)構(gòu)圖、包圖和部署圖行為建模圖用例圖、活動(dòng)圖、狀態(tài)機(jī)圖、順序圖、通信圖、定時(shí)圖和交互概覽圖關(guān)系依賴關(guān)系關(guān)聯(lián)關(guān)系類屬關(guān)系實(shí)現(xiàn)關(guān)系Rational統(tǒng)一過程RUPRUP的發(fā)展UML系統(tǒng)分析與設(shè)計(jì)第2版11Rational統(tǒng)一過程RUP什么是RUP？RUP是一個(gè)軟件工程化過程。它提供了在開發(fā)機(jī)構(gòu)中分派任務(wù)和責(zé)任的方法，它的目標(biāo)是在可預(yù)見的日程和預(yù)算前提下確保滿足最終用戶需求的高質(zhì)量軟件的產(chǎn)生。UML系統(tǒng)分析與設(shè)計(jì)第2版12Rational統(tǒng)一過程RUPRUP吸收的最佳工程實(shí)踐經(jīng)驗(yàn)：迭代地開發(fā)軟件需求管理使用基于組件的體系結(jié)構(gòu)可視化的軟件建模驗(yàn)證軟件質(zhì)量控制軟件的變化UML系統(tǒng)分析與設(shè)計(jì)第2版13RUPRUP過程可以用二維結(jié)構(gòu)（或兩個(gè)軸）來描述UML系統(tǒng)分析與設(shè)計(jì)第2版14RUP時(shí)間軸RUP將軟件生命周期劃分為四個(gè)連續(xù)的階段：初始階段（Inception）細(xì)化階段（Elaboration）構(gòu)造階段（Construction）交付階段（Transition）UML系統(tǒng)分析與設(shè)計(jì)第2版15工具市場上大量商業(yè)的或開源的UML計(jì)算機(jī)輔助軟件工程工具：RationalSoftwareModelerVisualParadigmforUMLProsaUMLVisioTogetherVisualUMLObjectDomainUMLMagicDrawUML等，UML系統(tǒng)分析與設(shè)計(jì)第2版16工具大部分CASE工具都給軟件開發(fā)者提供了一整套的可視化建模工具，包括系統(tǒng)建模、模型集成、軟件系統(tǒng)測試、軟件文檔的生成、從模型生成代碼的前向工程、從代碼生成模型的逆向工程、軟件開發(fā)的項(xiàng)目管理、團(tuán)隊(duì)開發(fā)管理等，為關(guān)于客戶＼服務(wù)器、分布式、實(shí)時(shí)系統(tǒng)環(huán)境等的真正的商業(yè)需求，提供了穩(wěn)健的、有效的解決方案。UML系統(tǒng)分析與設(shè)計(jì)第2版17小結(jié)UML是定義良好、易于表達(dá)、功能強(qiáng)大的語言不僅支持面向?qū)ο蟮姆治雠c設(shè)計(jì)，而且支持從需求分析開始的軟件開發(fā)的全過程。UML系統(tǒng)分析與設(shè)計(jì)第2版18UML系統(tǒng)分析與設(shè)計(jì)SystemAnalysis&Design

第二章面向?qū)ο蠓治雠c設(shè)計(jì)方法OOA／OOD方法OMT方法Booch方法OOSE方法Fusion方法UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi20面向?qū)ο蠓治雠c設(shè)計(jì)方法20世紀(jì)90年代，一批新的面向?qū)ο蟮姆椒ǔ霈F(xiàn)了，其中最引人注目的是Booch方法、OOSE方法和OMT方法等GrandyBooch是面向?qū)ο蠓椒ㄗ钤绲某珜?dǎo)者之一，他提出了面向?qū)ο筌浖こ痰母拍頡umbaugh等人采用了面向?qū)ο蟮母拍?，引入各種獨(dú)立于語言的表示符，用對象模型、動(dòng)態(tài)模型和功能模型來共同完成對整個(gè)系統(tǒng)的建模UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi21OOA/OOD方法OOA/OOD（Object-OrientedAnalysis/Object-OrientedDesign，面向?qū)ο蠓治?面向?qū)ο笤O(shè)計(jì)）方法是由Coad和Yourdon于1991年提出來的。與傳統(tǒng)分析方法相比，OOA／OOD方法的優(yōu)勢：可以處理更有挑戰(zhàn)性的問題域。改善了分析人員與問題領(lǐng)域?qū)＜业慕涣?。通過分析、設(shè)計(jì)和編程增加內(nèi)部的一致性。顯式地表示類和對象間的共性?？梢越⒂袕椥缘囊?guī)范。OOA（面向?qū)ο蠓治觯?、OOD（面向?qū)ο箝_發(fā)）和OOP（面向?qū)ο缶幊蹋┑慕Y(jié)果可重用。為分析、設(shè)計(jì)和編程提供一致的基本表示。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi22OOA/OOD方法在分析階段建立的OOA模型由5層組成：主題層（ASubjectLayer） 類和對象層（AClass&ObjectLayer）結(jié)構(gòu)層（AStructureLayer）屬性層（AnAttributeLayer）服務(wù)層（AServiceLayer）OOD部分為上述五層添加了4個(gè)不同的組件：人機(jī)交互組件（HumanInteractionComponent）問題域組件（ProblemDomainComponent）任務(wù)管理組件（TaskManagementComponent）數(shù)據(jù)管理組件（DataManagementComponent）UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi23OOA/OOD方法OOD階段擴(kuò)充了OOA階段創(chuàng)建的5層，將OOA階段產(chǎn)生的結(jié)果在OOD階段放入組件中，如圖所示。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi24OOAOOA的過程如下：1．識別問題域中的類和對象在這個(gè)步驟中，分析人員通過對問題域深入地分析和理解，識別出組成系統(tǒng)核心的、相關(guān)的、穩(wěn)定的類和對象。識別類和對象的第1步是研究問題域，可以通過審視下列選項(xiàng)來發(fā)現(xiàn)可能的類和對象。?結(jié)構(gòu)。 ?其他系統(tǒng)。?設(shè)備。 ?被記住的事情或事件。?所扮演的角色。 ?操作的程序。?地點(diǎn)（物理位置）。 ?有組織的單元。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi25OOA2．確定結(jié)構(gòu)結(jié)構(gòu)可以分為兩種，即“一般－特殊”結(jié)構(gòu)（Gen-SpecStructures）和“整體－部分”結(jié)構(gòu)（Whole-PartStructures）。在找出“一般－特殊”結(jié)構(gòu)和“整體－部分”結(jié)構(gòu)后，就可以識別出多重結(jié)構(gòu)，因?yàn)槎嘀亟Y(jié)構(gòu)是“一般－特殊”結(jié)構(gòu)和“整體－部分”結(jié)構(gòu)的各種組合。識別出多重結(jié)構(gòu)后，將結(jié)構(gòu)添加到OOA圖中。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi26OOA3．確定主題在這個(gè)步驟中，將模型分解為更易管理和理解的主題域，可降低所產(chǎn)生模型的復(fù)雜性。4．定義屬性在識別出屬性后，就可以識別出對象間的實(shí)例連接（InstanceConnections）。首先對識別出的屬性和實(shí)例連接進(jìn)行檢查，然后規(guī)定其屬性，最后將屬性和實(shí)例連接添加到OOA圖中。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi27OOA5．定義服務(wù)在識別出服務(wù)后，可以識別出消息連接（MessageConnections），然后規(guī)定服務(wù)，并將服務(wù)和消息連接添加到OOA圖中。6．準(zhǔn)備文檔OOA部分的最后一步是整理OOA文檔。主要文檔包括：完整的OOA圖。類和對象的規(guī)格定義。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi28OODOOD的過程如下：1．設(shè)計(jì)問題域組件設(shè)計(jì)問題域組件的步驟如下：尋找可以被重用的、以前的設(shè)計(jì)和類。添加根類，并將特定于問題域的類分組。抽象出公共服務(wù)，建立并添加父類。改變問題域模型以改善性能。審查添加到OOA模型中的細(xì)節(jié)。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi29OOD2．設(shè)計(jì)人機(jī)交互組件設(shè)計(jì)人機(jī)交互組件需要使用原型開發(fā)。在完成原型開發(fā)后，通過原型來檢查人機(jī)交互組件是否滿足下述標(biāo)準(zhǔn)。人機(jī)交互作用的一致性。操作步驟的最少化。及時(shí)地給予用戶有意義的反饋。提供撤銷功能。不要依賴用戶的記憶力去記住某些東西。掌握軟件所花費(fèi)的學(xué)習(xí)時(shí)間盡量少。對用戶來說，軟件的樂趣和吸引力也是很重要的。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi30OOD3．設(shè)計(jì)任務(wù)管理組件首先，需要確定系統(tǒng)是否需要任務(wù)。如果不需要，就不必設(shè)計(jì)任務(wù)，因?yàn)槿蝿?wù)會(huì)增加系統(tǒng)的復(fù)雜性。任務(wù)可以分為以下4種：由事件觸發(fā)的事件驅(qū)動(dòng)任務(wù)（Event-DrivenTasks）。由特定的時(shí)間間隔觸發(fā)的時(shí)鐘驅(qū)動(dòng)任務(wù)（Clock-DrivenTasks）。優(yōu)先級任務(wù)（PriorityTasks）。關(guān)鍵任務(wù)（CriticalTasks）。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi31OOD4．設(shè)計(jì)數(shù)據(jù)管理組件首先，要確定數(shù)據(jù)管理的途徑，即采用平面文件（FlatFile）、關(guān)系型數(shù)據(jù)庫管理系統(tǒng)（RelationalDatabaseManagementSystem）還是面向?qū)ο髷?shù)據(jù)庫管理系統(tǒng)（Object-OrientedDatabaseManagementSystem）。其次，根據(jù)所選途徑，應(yīng)用一系列標(biāo)準(zhǔn)進(jìn)行評價(jià)并選擇可能的數(shù)據(jù)管理工具。最后，根據(jù)所選的途徑和工具設(shè)計(jì)數(shù)據(jù)管理組件，包括設(shè)計(jì)數(shù)據(jù)格式和相應(yīng)的方法。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi32OMT方法對象模型技術(shù)（ObjectModelingTechnique，OMT）是由Rumbaugh等提出的，是一種現(xiàn)今非常流行的面向?qū)ο箝_發(fā)技術(shù)。其目的是構(gòu)造一系列模型，并用這些模型不斷地對系統(tǒng)設(shè)計(jì)進(jìn)行細(xì)化，直到找到最后適合實(shí)現(xiàn)的模型。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi33OMT方法使用OMT方法的面向?qū)ο箝_發(fā)過程可分為5步，如圖所示。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi34（1）分析。分析問題域并進(jìn)行建模。（2）系統(tǒng)設(shè)計(jì)。設(shè)計(jì)系統(tǒng)的整體體系結(jié)構(gòu)。（3）對象設(shè)計(jì)。為了有效地實(shí)現(xiàn)系統(tǒng)，對對象結(jié)構(gòu)進(jìn)行細(xì)化，并為對象添加細(xì)節(jié)。（4）編碼。用目標(biāo)編程語言實(shí)現(xiàn)對象和類。（5）測試。驗(yàn)證系統(tǒng)是否正確。OMT方法—分析分析過程可分為下述5個(gè)步驟：1．編寫問題陳述（ProblemStatement）構(gòu)造分析模型是從為問題域編寫問題陳述開始的。2．建立對象模型（ObjectModel）建立對象模型的步驟如下：（1）識別出類和對象。（2）丟棄不必要和不正確的類。（3）準(zhǔn)備數(shù)據(jù)詞典。（4）識別出類之間的關(guān)聯(lián)關(guān)系。（5）丟棄不必要的和不正確的關(guān)聯(lián)。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi35OMT方法—分析建立對象模型的步驟如下：（接上頁）（6）抽象出類和對象的屬性。（7）丟棄不必要或不正確的屬性。（8）使用繼承關(guān)系來建立類之間的層次關(guān)系。（9）遍歷訪問路徑，找出不足。3．建立動(dòng)態(tài)模型（DynamicModel）動(dòng)態(tài)模型主要描述了隨著時(shí)間的變化而變化的對象及對象間的關(guān)系，動(dòng)態(tài)模型對于具有重要?jiǎng)討B(tài)行為的系統(tǒng)（例如，交互式系統(tǒng)和實(shí)時(shí)系統(tǒng)）尤其重要。動(dòng)態(tài)模型描述了系統(tǒng)的可能控制流，而對象模型描述了可能的信息流。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi36OMT方法—分析4．建立功能模型（FunctionalModel）功能模型完全由數(shù)據(jù)流圖和約束組成，而數(shù)據(jù)流圖由過程、數(shù)據(jù)流、參與者和數(shù)據(jù)存儲組成。其中，一個(gè)過程將輸入數(shù)據(jù)值轉(zhuǎn)變?yōu)檩敵鰯?shù)據(jù)值。5．細(xì)化對象模型、動(dòng)態(tài)模型和功能模型，并建立文檔當(dāng)分析完成后，要驗(yàn)證分析模型是否滿足系統(tǒng)最初的需求，這個(gè)活動(dòng)需要該問題領(lǐng)域的專家參與，以檢驗(yàn)產(chǎn)生的分析模型。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi37OMT方法—系統(tǒng)設(shè)計(jì)在系統(tǒng)設(shè)計(jì)階段，主要確定系統(tǒng)的高層次結(jié)構(gòu)。在系統(tǒng)設(shè)計(jì)階段，需要做出如下決策：1．將系統(tǒng)劃分為子系統(tǒng)對于每個(gè)子系統(tǒng)，都必須建立該子系統(tǒng)與其他子系統(tǒng)之間的定義良好的接口，接口的建立使得不同子系統(tǒng)的設(shè)計(jì)可以獨(dú)立進(jìn)行。如果必要，還可以不斷地將子系統(tǒng)進(jìn)一步分解為更小的子系統(tǒng)，直到將子系統(tǒng)分解為模塊。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi38OMT方法—系統(tǒng)設(shè)計(jì)2．識別并發(fā)首先要識別出系統(tǒng)固有的并發(fā)，可以通過分析狀態(tài)圖來完成這個(gè)任務(wù)。為了定義并發(fā)任務(wù)，需要檢查系統(tǒng)中不同的、可能的控制線程，并將這幾個(gè)控制線程合并為一個(gè)。3．將子系統(tǒng)和任務(wù)分配給處理器將子系統(tǒng)分配給處理器是從估計(jì)所需要的硬件資源開始的，同時(shí)設(shè)計(jì)者還必須決策哪個(gè)子系統(tǒng)由硬件實(shí)現(xiàn)，哪個(gè)子系統(tǒng)由軟件實(shí)現(xiàn)。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi39OMT方法—系統(tǒng)設(shè)計(jì)4．選擇實(shí)現(xiàn)數(shù)據(jù)存儲的策略在設(shè)計(jì)的這個(gè)階段，必須完成關(guān)于數(shù)據(jù)庫的決策，即決定是使用文件還是數(shù)據(jù)庫管理系統(tǒng)存儲數(shù)據(jù)。5．識別出全局資源，并確定控制訪問全局資源的機(jī)制必須明確定義對全局資源（如物理單元、邏輯名和共享數(shù)據(jù)等）的使用和訪問。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi40OMT方法—系統(tǒng)設(shè)計(jì)6．選擇實(shí)現(xiàn)軟件控制的方法用軟件實(shí)現(xiàn)控制又分為外部控制和內(nèi)部控制兩種。外部控制（ExternalControl）是系統(tǒng)中對象間的外部可見的事件流。內(nèi)部控制（InternalControl）是進(jìn)程內(nèi)的控制流，可以被看作是程序語言中的過程調(diào)用。7．考慮邊界條件描述各種邊界條件也是很重要的，包括如下內(nèi)容：?系統(tǒng)的初始化。

?系統(tǒng)的結(jié)束。?系統(tǒng)的失敗。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi41OMT方法—系統(tǒng)設(shè)計(jì)8．建立折中的優(yōu)先級系統(tǒng)的所有目標(biāo)并不是都可以達(dá)到，所以要分析系統(tǒng)的所有目標(biāo)，然后進(jìn)行折中，為不同的目標(biāo)設(shè)置不同的優(yōu)先級。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi42OMT方法—對象設(shè)計(jì)在對象設(shè)計(jì)（ObjectDesign）階段，要對類、關(guān)聯(lián)、屬性和操作進(jìn)行充分、詳細(xì)的規(guī)定。對象設(shè)計(jì)的步驟如下：1．對象模型可以從其他模型獲取操作對于獲得對象模型的操作，必須結(jié)合3個(gè)模型，為功能模型中的每個(gè)過程和動(dòng)態(tài)模型中的每個(gè)事件定義操作。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi43OMT方法—對象設(shè)計(jì)2．設(shè)計(jì)算法實(shí)現(xiàn)操作步驟如下：（1）選擇使實(shí)現(xiàn)操作的代價(jià)最小的算法。（2）選擇適合該算法的數(shù)據(jù)結(jié)構(gòu)。（3）如果必要，定義新的內(nèi)部類和操作。（4）將沒有明確與某個(gè)類相關(guān)的操作分配給正確的類。3．優(yōu)化訪問數(shù)據(jù)的路徑UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi44OMT方法—對象設(shè)計(jì)4．控制的實(shí)現(xiàn)使用系統(tǒng)設(shè)計(jì)階段選擇的策略實(shí)現(xiàn)狀態(tài)圖。5．調(diào)整類結(jié)構(gòu)，并增加繼承6．設(shè)計(jì)關(guān)聯(lián)的實(shí)現(xiàn)首先要分析怎樣使用關(guān)聯(lián)，然后確定關(guān)聯(lián)的實(shí)現(xiàn)策略。7．確定對象屬性的準(zhǔn)確表達(dá)8．用模塊封裝類和關(guān)聯(lián)UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi45OMT方法—實(shí)現(xiàn)實(shí)現(xiàn)（Implementation）是將設(shè)計(jì)模型轉(zhuǎn)變?yōu)榇a的過程。由于較困難的決策都已在設(shè)計(jì)階段完成，所以將設(shè)計(jì)模型轉(zhuǎn)變?yōu)榇a的實(shí)現(xiàn)是直接的、簡單的。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi46OMT方法—測試測試（Testing）用來驗(yàn)證系統(tǒng)是否被正確實(shí)現(xiàn)。在分析和設(shè)計(jì)階段也部分涉及實(shí)現(xiàn)和測試活動(dòng)，也就是說，分析、設(shè)計(jì)、實(shí)現(xiàn)和測試在增量式的開發(fā)中是交錯(cuò)進(jìn)行的活動(dòng)。測試可能會(huì)在不同的層次上進(jìn)行，例如，可以有單元測試、集成測試和系統(tǒng)測試。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi47OMT方法—模型OMT方法通過3個(gè)模型——對象模型、動(dòng)態(tài)模型和功能模型來可視化地定義一個(gè)系統(tǒng)。1．對象模型（ObjectModel）對象模型描述了系統(tǒng)的靜態(tài)結(jié)構(gòu)，還描述了系統(tǒng)中的類以及類間的關(guān)系、類的屬性和操作。2．動(dòng)態(tài)模型（DynamicModel）動(dòng)態(tài)模型描述了系統(tǒng)的主要行為，它主要描述了問題域中發(fā)生了什么、什么時(shí)候發(fā)生的以及有什么結(jié)果。3．功能模型（FunctionalModel）功能模型描述了如何實(shí)現(xiàn)系統(tǒng)功能。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi48Booch方法UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi49Booch方法是最早被承認(rèn)的面向?qū)ο笤O(shè)計(jì)方法之一。提出了面向?qū)ο箝_發(fā)的4個(gè)模型描述邏輯結(jié)構(gòu)的邏輯模型（LogicalModel）描述物理結(jié)構(gòu)的物理模型（PhysicalModel）描述靜態(tài)語義的靜態(tài)模型（StaticModel）描述動(dòng)態(tài)語義的動(dòng)態(tài)模型（DynamicModel）Booch方法Booch方法區(qū)分了系統(tǒng)的邏輯結(jié)構(gòu)和物理結(jié)構(gòu)，不但描述了靜態(tài)語義，還描述了動(dòng)態(tài)語義。Booch方法的開發(fā)過程是一個(gè)迭代的、漸進(jìn)式的系統(tǒng)開發(fā)過程。Booch方法的面向?qū)ο箝_發(fā)過程可以分為宏過程（MacroProcess）和微過程（MicroProcess）。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi50Booch方法宏過程充當(dāng)微過程的控制框架，它代表了整個(gè)開發(fā)隊(duì)伍幾個(gè)月或幾個(gè)星期所進(jìn)行的活動(dòng)。宏過程包含如下5個(gè)活動(dòng)：1．概念化（Conceptualization）概念化的目的是試圖建立系統(tǒng)的核心需求。概念化是個(gè)非常有創(chuàng)造性的過程，所以沒有嚴(yán)格的開發(fā)規(guī)則。原型是概念化的主要產(chǎn)品。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi51Booch方法2．分析（Analysis）分析的目的是通過識別出構(gòu)成問題域詞匯表的類和對象來為系統(tǒng)建立模型，它強(qiáng)調(diào)系統(tǒng)的行為。3．設(shè)計(jì)（Design）設(shè)計(jì)的目的是建立系統(tǒng)的體系結(jié)構(gòu)。設(shè)計(jì)可以被分為體系結(jié)構(gòu)規(guī)劃、戰(zhàn)術(shù)設(shè)計(jì)和版本規(guī)劃。體系結(jié)構(gòu)規(guī)劃的目的是在生命周期的早期創(chuàng)建一個(gè)特定于域的應(yīng)用程序框架，這個(gè)框架可以被不斷地細(xì)化，它包括設(shè)計(jì)整個(gè)系統(tǒng)的層次和劃分。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi52Booch方法4．進(jìn)化（Evolution）進(jìn)化由微過程的應(yīng)用和變化管理組成。微過程的應(yīng)用是從對下一個(gè)版本的需求分析開始的，然后設(shè)計(jì)系統(tǒng)體系結(jié)構(gòu)，實(shí)現(xiàn)類和對象。進(jìn)化的主要產(chǎn)品是一系列的軟件可執(zhí)行版本，這些版本是對體系結(jié)構(gòu)第一個(gè)版本的不斷細(xì)化而產(chǎn)生的。5．維護(hù)（Maintenance）維護(hù)階段的目的是管理軟件的交付使用，這個(gè)階段是進(jìn)化階段的繼續(xù)。在這個(gè)階段，需要進(jìn)行系統(tǒng)的本地化以及消除錯(cuò)誤等工作。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi53Booch方法微過程由4個(gè)重要的、無時(shí)間順序的活動(dòng)組成，它故意模糊了傳統(tǒng)的分析與設(shè)計(jì)方法中的階段，過程是由時(shí)機(jī)來控制的。1．在給定的抽象層次上識別出類和對象這一步要對問題域和系統(tǒng)需求進(jìn)行分析以識別出類和對象，這依賴于適當(dāng)?shù)男枨蠓治??？梢酝ㄟ^面向?qū)ο蠓治?、行為分析、用例分析等分析方法來識別類和對象。這個(gè)步驟產(chǎn)生了候選類和對象的數(shù)據(jù)詞典，以及描述對象行為的文檔。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi54Booch方法2．識別出這些類和對象的語義這一步的目的是為從前一階段中識別出的每個(gè)抽象設(shè)立狀態(tài)和行為。在這個(gè)階段要執(zhí)行3個(gè)動(dòng)作，即編制故事板（Storyboarding）、孤立類設(shè)計(jì)（IsolatedClassDesign）和模式抽取（PatternScavenging）。3．識別出類間和對象間的關(guān)系識別出類間和對象間關(guān)系的目的是確定每個(gè)抽象的邊界，并識別出協(xié)作的類和對象。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi55Booch方法4．實(shí)現(xiàn)類和對象在分析階段，實(shí)現(xiàn)類和對象的目的是細(xì)化已存在的抽象，并在下一個(gè)抽象層次上找出新的類和對象。通過上述步驟，設(shè)計(jì)者可以得到如下產(chǎn)物。類圖（ClassDiagram）。對象圖（ObjectDiagram）。狀態(tài)躍遷圖（StateTransitionDiagram）。交互作用圖（InteractionDiagram）。模塊圖（ModuleDiagram）。進(jìn)程圖（ProcessDiagram）。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi56OOSE方法OOSE方法是由Jacobson于1994年提出的，它組合了3種已經(jīng)被使用了很長時(shí)間的技術(shù)。OOSE方法是所謂的用例驅(qū)動(dòng)的方法（UseCaseDrivenApproach），在這個(gè)方法中，用例模型充當(dāng)可以導(dǎo)出所有其他模型的中心模型。OOSE方法的一個(gè)很大貢獻(xiàn)是引入了用例的概念。OOSE過程可以分為3個(gè)階段：分析階段構(gòu)造階段測試階段UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi57OOSE方法—分析階段在分析階段產(chǎn)生兩種模型，即需求模型（RequirementsModel）和分析模型（AnalysisModel）。需求模型從用戶的角度描述了系統(tǒng)的所有功能需求，以及系統(tǒng)被最終用戶使用的方式。需求模型為系統(tǒng)確定了邊界，定義了功能。需求模型由下述3個(gè)部分組成。1．用例模型2．問題域?qū)ο竽Ｐ停≒roblemDomainObjectModel）問題域?qū)ο竽Ｐ兔枋隽讼到y(tǒng)的邏輯視圖。3．接口描述（InterfaceDescriptions）UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi58OOSE方法—構(gòu)造階段構(gòu)造階段可以分為兩步，即設(shè)計(jì)（Design）和實(shí)現(xiàn)（Implementation）。1．設(shè)計(jì)在這個(gè)階段，設(shè)計(jì)模型細(xì)化分析模型，使模型適合于實(shí)現(xiàn)環(huán)境。設(shè)計(jì)模型由交互作用圖（InteractionDiagram）和狀態(tài)躍遷圖（StateTransitionGraphs）組成。2．實(shí)現(xiàn)在這一階段，用編程語言實(shí)現(xiàn)每個(gè)對象。通常，使用者不必等到整個(gè)設(shè)計(jì)模型都完成后再進(jìn)行系統(tǒng)實(shí)現(xiàn)，可以在設(shè)計(jì)模型部分完成的情況下就開始實(shí)現(xiàn)系統(tǒng)。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi59OOSE方法—測試階段測試用來驗(yàn)證開發(fā)完成的軟件系統(tǒng)是否滿足要求。測試有自己的生命周期，一般是從測試計(jì)劃開始，以測試報(bào)告結(jié)束。測試的步驟如下：1．測試計(jì)劃制定測試計(jì)劃是為了使測試活動(dòng)的規(guī)劃變得容易，并為測試提供參考2．測試規(guī)范測試規(guī)范確定要進(jìn)行哪種測試以及測試?yán)印?．測試報(bào)告根據(jù)測試規(guī)范進(jìn)行測試，如果測試通過就不用再進(jìn)行更多的測試；如果測試失敗，則對失敗原因進(jìn)行分析。在測試階段，先進(jìn)行單元測試，再進(jìn)行系統(tǒng)測試。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi60Fusion方法Fusion方法受到了下面的方法或技術(shù)影響：OMTFusion方法中的對象模型與OMT方法中的對象模型非常相似。Fusion方法中的操作模型類似于OMT方法中的功能模型。形式方法形式方法中的前置條件和后置條件被用來形式地描述系統(tǒng)的行為。Booch方法Booch方法中對象圖的可視性信息影響了Fusion方法中的可視圖。CRC擴(kuò)充了通信信息的CRC影響了Fusion方法中的對象交互作用圖。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi61Fusion方法Fusion方法是以構(gòu)造各種適當(dāng)?shù)哪Ｐ蜑榛A(chǔ)的，并由分析階段、設(shè)計(jì)階段和實(shí)現(xiàn)階段3個(gè)階段組成。1．分析階段分析階段會(huì)產(chǎn)生描述系統(tǒng)體系結(jié)構(gòu)的模型。分析階段的過程如下。1．建立對象模型（ObjectModel）2．確定系統(tǒng)的接口3．建立接口模型4．檢查分析模型UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi62Fusion方法2.設(shè)計(jì)階段要將在分析階段產(chǎn)生的抽象的定義轉(zhuǎn)化為軟件結(jié)構(gòu)。設(shè)計(jì)階段所進(jìn)行的過程如下。1．建立對象交互作用圖（ObjectInteractionGraphs）2．建立可視圖（VisibilityGraphs）3．建立類的描述（ClassDescriptions）4．建立繼承圖（InheritanceGraphs）5．更新類的描述UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi63Fusion方法3.實(shí)現(xiàn)階段應(yīng)根據(jù)設(shè)計(jì)模型進(jìn)行實(shí)現(xiàn)。實(shí)現(xiàn)階段的過程如下。1．編碼（Coding）編碼意味著用編程語言來實(shí)現(xiàn)設(shè)計(jì)階段所建立的模型，它與3個(gè)因素有關(guān)，即系統(tǒng)生命周期、類描述和數(shù)據(jù)詞典。2．性能在整個(gè)開發(fā)過程中都需要考慮系統(tǒng)的性能，這一點(diǎn)是很重要的，如要優(yōu)化經(jīng)常使用的代碼等。3．檢查檢查軟件中存在的不足，并對軟件進(jìn)行測試。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi64小結(jié)面向?qū)ο蠓椒ǚN類繁多，且各有優(yōu)勢。本章對5種較為重要的面向?qū)ο蠓治雠c設(shè)計(jì)方法，包括OOA/OOD方法、OMT方法、Booch方法、OOSE方法和Fusion方法，逐一進(jìn)行了詳細(xì)介紹。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi65UML系統(tǒng)分析與設(shè)計(jì)SystemAnalysis&Design

第三章UML的關(guān)系依賴關(guān)系類屬關(guān)系關(guān)聯(lián)關(guān)系實(shí)現(xiàn)關(guān)系UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi67依賴關(guān)系如果一個(gè)模型元素的變化會(huì)影響另一個(gè)模型元素（這種影響不必是可逆的），那么就說在這兩個(gè)模型元素之間存在依賴關(guān)系。依賴關(guān)系的UML符號表示是帶箭頭的虛線，指向被依賴的模型元素。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi68依賴關(guān)系UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi69依賴關(guān)系UML定義了許多可以應(yīng)用于依賴關(guān)系的衍型用于類圖中類和對象之間依賴關(guān)系的衍型：（1）<<bind>>。這個(gè)衍型規(guī)定了源元素如何用給定的實(shí)際參數(shù)實(shí)例化目標(biāo)模板。（2）<<derive>>。這個(gè)衍型規(guī)定了源元素可以從目標(biāo)元素導(dǎo)出。（3）<<friend>>。這個(gè)衍型規(guī)定了源元素對于目標(biāo)元素有特殊的可見性。（4）<<instanceOf>>。這個(gè)衍型規(guī)定了源對象是目標(biāo)分類器的實(shí)例。（5）<<instantiate>>。這個(gè)衍型規(guī)定源元素創(chuàng)建了目標(biāo)元素的實(shí)例。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi70依賴關(guān)系（6）<<powertype>>。這個(gè)衍型規(guī)定了目標(biāo)元素是源元素的強(qiáng)類型。（7）<<refine>>。這個(gè)衍型規(guī)定了源元素是比目標(biāo)元素更細(xì)化的抽象。例如，在分析階段遇到一個(gè)類Bank，那么在設(shè)計(jì)階段時(shí)，將該類細(xì)化成更具體的類Bank。（8）<<use>>。這個(gè)衍型規(guī)定了源元素的語義是依賴目標(biāo)元素公共部分的語義的。下面2個(gè)衍型可以用于包間的依賴關(guān)系（1）<<access>>。這個(gè)衍型規(guī)定了源包有權(quán)引用目標(biāo)包中的元素。（2）<<import>>。這個(gè)衍型規(guī)定了一種訪問，這種訪問規(guī)定目標(biāo)包的公共元素如何進(jìn)入源包的命名空間，就好像在源包中聲明了這部分元素一樣。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi71依賴關(guān)系下面2個(gè)衍型可以用于用例之間的依賴關(guān)系（1）<<extend>>。這個(gè)衍型規(guī)定目標(biāo)用例擴(kuò)充了源用例的行為。（2）<<include>>。這個(gè)衍型規(guī)定源用例包含了另一個(gè)用例的行為。下面3個(gè)衍型可以用于為對象間的交互作用建模（1）<<become>>。這個(gè)衍型規(guī)定了目標(biāo)對象和源對象是同一個(gè)對象，但目標(biāo)對象出現(xiàn)在更晚的時(shí)間點(diǎn)，可能有不同的值、狀態(tài)和角色。（2）<<call>>。這個(gè)衍型規(guī)定源操作調(diào)用了目標(biāo)操作。（3）<<copy>>。這個(gè)衍型規(guī)定了目標(biāo)對象是源對象的一個(gè)準(zhǔn)確、獨(dú)立的拷貝。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi72依賴關(guān)系下面這個(gè)衍型可以應(yīng)用于狀態(tài)機(jī)的上下文中<<send>>。這個(gè)衍型規(guī)定了源操作給目標(biāo)發(fā)送一個(gè)事件。當(dāng)模擬操作發(fā)送給定事件到目標(biāo)對象時(shí)，可以使用<<send>>。另外還有一個(gè)有用的衍型<<trace>>。這個(gè)衍型規(guī)定目標(biāo)元素是源元素的祖先。當(dāng)模擬不同模型中元素間的關(guān)系時(shí)，可以使用<<trace>>。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi73類屬關(guān)系類屬（Generalization）關(guān)系描述了一般事物與該事物的特殊種類之間的關(guān)系，也即父元素與子元素之間的關(guān)系。在UML中，類屬關(guān)系用帶空心箭頭的實(shí)線表示，箭頭指向父元素。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi74類屬關(guān)系UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi75類屬關(guān)系一個(gè)類可以有零個(gè)到多個(gè)父類。其中，沒有父類但有一個(gè)或多個(gè)子類的類被稱為根類或基類，沒有子類的類被稱為葉類。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi76關(guān)聯(lián)關(guān)系關(guān)聯(lián)關(guān)系表示兩個(gè)類之間存在某種語義上的聯(lián)系。它是一種結(jié)構(gòu)關(guān)系，規(guī)定了一種事物的對象可以與另一種事物的對象相連。關(guān)聯(lián)關(guān)系的UML符號是一條實(shí)線。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi77關(guān)聯(lián)關(guān)系角色（Role）與階元（Multiplicity）關(guān)聯(lián)兩頭的類都以某種角色參與關(guān)聯(lián)。階元表示有多少個(gè)對象參與該關(guān)聯(lián)。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi78關(guān)聯(lián)關(guān)系導(dǎo)航（Navigation）關(guān)聯(lián)關(guān)系是可導(dǎo)航的意味著給定一端的一個(gè)對象，可以容易、直接地到達(dá)另一端的對象，因?yàn)樵磳ο笸ǔ：袑δ繕?biāo)對象的引用。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi79關(guān)聯(lián)關(guān)系可見性（Visibility）在UML中，通過對角色名附加可見性符號，可以為關(guān)聯(lián)端規(guī)定3種可見性：公共可見性、私有可見性和保護(hù)可見性。如果不標(biāo)注可見性，則角色的缺省可見性就是公共的。公共可見性表示對象可以被關(guān)聯(lián)外的對象訪問；私有可見性說明對象不能被關(guān)聯(lián)外的任何對象訪問；保護(hù)可見性說明對象只能被關(guān)聯(lián)另一端的對象及其子對象所訪問，而不能被該關(guān)聯(lián)外的其他任何對象所訪問。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi80關(guān)聯(lián)關(guān)系限定符（Qualifier）

限定符是屬性或?qū)傩粤斜?，這些屬性的值用來劃分與某個(gè)對象通過關(guān)聯(lián)關(guān)系連接的對象集。限定符是這個(gè)關(guān)聯(lián)的屬性。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi81關(guān)聯(lián)關(guān)系接口說明符（InterfaceSpecifier）是用來規(guī)定類或組件服務(wù)的操作集的說明符。每個(gè)類可以實(shí)現(xiàn)多個(gè)接口，但是，在與目標(biāo)類關(guān)聯(lián)的上下文中，源類可能只選擇展示部分接口。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi82關(guān)聯(lián)關(guān)系聚合關(guān)系是一種特殊的關(guān)聯(lián)關(guān)系。聚合表示類之間的關(guān)系是整體與部分的關(guān)系，它代表了“has-a”（擁有）關(guān)系，也即作為整體的對象擁有作為部分的對象。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi83聚合關(guān)系的UML符號聚合關(guān)系關(guān)聯(lián)關(guān)系組合關(guān)系是聚合關(guān)系的變種，它加入了一些重要的語義。在組合關(guān)系中，整體與部分之間具有很強(qiáng)的所有關(guān)系和一致的生命周期。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi84組合關(guān)系的UML符號組合關(guān)系實(shí)現(xiàn)關(guān)系實(shí)現(xiàn)關(guān)系是分類器之間的語義關(guān)系，一個(gè)分類器規(guī)定協(xié)議，另一個(gè)分類器保證實(shí)現(xiàn)這個(gè)協(xié)議。大多數(shù)情況下，實(shí)現(xiàn)關(guān)系被用來規(guī)定接口和實(shí)現(xiàn)接口的類或組件之間的關(guān)系。實(shí)現(xiàn)關(guān)系的UML符號表示用帶有空心箭頭的虛線表示UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi85實(shí)現(xiàn)關(guān)系UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi86小結(jié)本章描述了這4種關(guān)系的語義、符號表示、衍型和應(yīng)用，其中在關(guān)聯(lián)關(guān)系部分，還介紹了如何使用關(guān)聯(lián)關(guān)系的角色、階元、導(dǎo)航、可見性、限定符、接口說明符，此外還介紹了聚合關(guān)系和組合關(guān)系的語義、符號表示和應(yīng)用，并對聚合關(guān)系和組合關(guān)系進(jìn)行了比較。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi87UML系統(tǒng)分析與設(shè)計(jì)SystemAnalysis&Design第四章UML的符號1、注釋2、參與者3、用例4、協(xié)作5、類6、對象7、消息8、接口9、包10、組件11、狀態(tài)12、躍遷13、判定14、同步條15、活動(dòng)16、節(jié)點(diǎn)17、UML的擴(kuò)充機(jī)制UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi89UML的符號UML的最大貢獻(xiàn)就是提供了一個(gè)標(biāo)準(zhǔn)的、統(tǒng)一的建模符號體系，結(jié)束了由不同符號體系的應(yīng)用所帶來的混亂。UML符號體系是可視化的，可為系統(tǒng)建立圖形化的可視模型，使系統(tǒng)的結(jié)構(gòu)變得直觀，易于理解。UML符號具有定義良好的語義，不會(huì)引起歧義。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi90注釋注釋是用來對元素或元素集合進(jìn)行注解或約束時(shí)所用的圖形符號。注釋的UML符號表示是右上角帶有折角的矩形。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi91參與者參與者代表與系統(tǒng)交互的人、硬件設(shè)備、或另一個(gè)系統(tǒng)。參與者并不是軟件系統(tǒng)的組成部分，參與者只存在于系統(tǒng)的外部。

參與者的UML符號表示是如圖所示的“小人”，并可在符號下標(biāo)出參與者名。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi92用例用例規(guī)定了系統(tǒng)或部分系統(tǒng)的行為，它描述了系統(tǒng)所執(zhí)行的動(dòng)作序列集，并為執(zhí)行者產(chǎn)生一個(gè)可供觀察的結(jié)果。用例的UML符號是橢圓，并可在橢圓下標(biāo)出用例名。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi93協(xié)作協(xié)作命名了彼此合作完成某個(gè)行為的類、接口和其他元素的群體。協(xié)作可以用來定義用例和操作的實(shí)現(xiàn)，為系統(tǒng)體系結(jié)構(gòu)上的重要機(jī)制建模。協(xié)作的UML符號是虛線橢圓，每個(gè)協(xié)作都有一個(gè)名字以與其他協(xié)作相區(qū)分。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi94類類是分享同樣的屬性、操作、關(guān)系和語義的對象的集合。類是現(xiàn)實(shí)世界中的事物的抽象，當(dāng)這些事物存在于真實(shí)世界中時(shí)，它們是類的實(shí)例，并被稱為對象。類可以實(shí)現(xiàn)一個(gè)或多個(gè)接口。類的UML符號是劃分成3個(gè)格子的長方形。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi95類邊界類邊界類處理系統(tǒng)環(huán)境與系統(tǒng)內(nèi)部之間的通信，邊界類為用戶或另一個(gè)系統(tǒng)（即參與者）提供了接口。邊界類的UML符號表示UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi96類實(shí)體類實(shí)體類是模擬必須被存儲的信息和其關(guān)聯(lián)行為的類。實(shí)體類的UML符號表示。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi97類控制類控制類是用來為特定于一個(gè)或多個(gè)用例的控制行為建模的類。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi98類參數(shù)類參數(shù)類又被稱為模板類（TemplateClasses），模板類定義了類族。模板不能直接使用，要首先實(shí)例化模板類，實(shí)例化包括將這些形式模板參數(shù)綁定到實(shí)際的參數(shù)。參數(shù)類的UML符號是在類的UML符號表示的右上角加一個(gè)虛線框，在這個(gè)虛線框中列出模板參數(shù)。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi99對象對象代表了類的一個(gè)特定實(shí)例。對象具有身份（Identity）和屬性值（AttributeValues）。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi100消息消息是對象間的通信，它傳遞了要執(zhí)行動(dòng)作的信息，它能觸發(fā)事件。消息的UML符號表示是帶箭頭的實(shí)線。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi101接口接口是用來定義類或組件服務(wù)的操作的集合。與類不同，接口沒有定義任何結(jié)構(gòu)，也沒有定義任何實(shí)現(xiàn)。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi102接口像類一樣，接口可以參與類屬關(guān)系、關(guān)聯(lián)關(guān)系和依賴關(guān)系，另外，接口還可以參與實(shí)現(xiàn)關(guān)系。實(shí)現(xiàn)接口的類或組件必須實(shí)現(xiàn)接口中定義的所有操作。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi103包包是一個(gè)用來將模型單元分組的通用機(jī)制。包可以用在任何一個(gè)UML圖中，但一般多用于用例圖和類圖，它就象文件夾一樣，可以將模型元素分組隱藏，從而簡化UML圖，使得UML圖更易理解。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi104包可見性如同類屬性和操作的可見性是可控制的一樣，包中元素的可見性也是可控制的。包中的元素在缺省情況下是公共的（public），也就是說，對于引入含有該元素的包中的任何元素都是可見的。引入與輸出（ImportingandExporting）引入可以使一個(gè)包中的元素單向地訪問另一個(gè)包中的元素。在UML中，引入關(guān)系用點(diǎn)綴著衍型<<import>>的依賴關(guān)系來表示。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi105包類屬關(guān)系（Generalization）包間的類屬關(guān)系與類間的類屬關(guān)系非常類似。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi106組件包（ComponentPackage）。組件包代表了邏輯上相關(guān)的組件簇或系統(tǒng)的重要部分。組件包的作用類似于類圖中邏輯包的作用。組件包用來劃分系統(tǒng)的物理模型。組件組件代表了一個(gè)接口定義良好的軟件模塊。組件是系統(tǒng)的一個(gè)物理的、可替代的部分，它遵循接口定義，并為接口提供了實(shí)現(xiàn)。組件的特點(diǎn)如下：組件是物理的。組件是可替代的。組件是系統(tǒng)的一部分。組件可以被多個(gè)系統(tǒng)重用。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi107組件與類組件與類的區(qū)別：類代表了邏輯的抽象，而組件是物理的、可以存在于現(xiàn)實(shí)世界中的。也就是說，組件可以在節(jié)點(diǎn)上存在，而類不能。組件代表了其他邏輯單元的物理封裝，與類的抽象存在于不同的層次上。類本身有屬性和操作，但是，組件的操作通常只能通過接口來訪問。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi108組件與接口接口是操作的集合，定義了類或組件的服務(wù)。接口通常被用作粘合劑將組件連接在一起。被一個(gè)組件實(shí)現(xiàn)的接口被稱為該組件的輸出接口（ExportInterface），也就是說，組件將該接口作為服務(wù)窗口向其他組件開放。一個(gè)組件可以有多個(gè)輸出接口。被一個(gè)組件使用的接口被稱做該組件的引入接口（ImportInterface）。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi109組件組件的二進(jìn)制可替代性基于組件的系統(tǒng)是通過組裝二進(jìn)制的、可替換的組件建立起來的，可以通過使用新組件替換舊組件來發(fā)展系統(tǒng)，而不需要重新編譯整個(gè)系統(tǒng)。衍型UML的所有擴(kuò)充機(jī)制都可以用于組件。通常，可以用標(biāo)記值來擴(kuò)充組件的屬性（例如，規(guī)定組件的版本信息），用衍型規(guī)定組件的新種類。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi110組件UML定義了5個(gè)可以應(yīng)用于組件的標(biāo)準(zhǔn)衍型。（1）可執(zhí)行的（executable）。該衍型定義了可以在節(jié)點(diǎn)上執(zhí)行的組件。（2）庫（library）。該衍型定義了靜態(tài)或動(dòng)態(tài)的對象庫。（3）表（table）。該衍型定義了代表數(shù)據(jù)庫表的組件。（4）文件（file）。該衍型定義了代表含有源代碼或數(shù)據(jù)的文件的組件。（5）文檔（document）。該衍型定義了表示文檔的組件。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi111狀態(tài)狀態(tài)機(jī)（StateMachine）描述了對象在生命周期中響應(yīng)事件所經(jīng)歷的狀態(tài)的序列以及對象對這些事件的響應(yīng)。狀態(tài)機(jī)由狀態(tài)、躍遷、事件、活動(dòng)、動(dòng)作等組成。狀態(tài)描述對象在生命周期中的一種條件或狀況，在這種狀況下，對象滿足某個(gè)條件，或執(zhí)行某個(gè)動(dòng)作、或等待某個(gè)事件。一個(gè)狀態(tài)在一個(gè)有限的時(shí)間段內(nèi)存在。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi112狀態(tài)狀態(tài)由以下6部分組成：1.名字（Name）名字可以用來區(qū)分不同的狀態(tài)。狀態(tài)也可以是匿名的。2.入口／出口動(dòng)作（Entry/ExitActions）入口動(dòng)作在進(jìn)入狀態(tài)時(shí)執(zhí)行；出口動(dòng)作在退出狀態(tài)時(shí)執(zhí)行。

3.內(nèi)部躍遷（InternalTransitions）內(nèi)部躍遷是沒有引起狀態(tài)變化的躍遷。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi113圖4.30狀態(tài)狀態(tài)4.子狀態(tài)（Substate）子狀態(tài)是被嵌套的狀態(tài)。子狀態(tài)包括不相交子狀態(tài)（DisjointSubstates）和并發(fā)子狀態(tài)（ConcurrentSubstates）。不相交子狀態(tài)也被稱為順序子狀態(tài)（SequentialSubstates）。不含有子結(jié)構(gòu)的狀態(tài)被稱為簡單狀態(tài)（SimpleState），含有子結(jié)構(gòu)的狀態(tài)被稱為組合狀態(tài)（CompositeState）。并發(fā)子狀態(tài)是指并發(fā)進(jìn)行的子狀態(tài)。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi114狀態(tài)UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi115順序子狀態(tài)狀態(tài)UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi116并發(fā)子狀態(tài)狀態(tài)5.延遲事件（DeferredEvents）延遲事件是指不處理那些當(dāng)前發(fā)生的狀態(tài)，而將事件推遲到不再被推遲的另外一個(gè)狀態(tài)中才處理，此時(shí)延遲事件發(fā)生并可能觸發(fā)躍遷，就好像這些事件剛發(fā)生一樣。延遲事件的實(shí)現(xiàn)需要存在一個(gè)內(nèi)部的事件隊(duì)列。6.初始狀態(tài)（InitialState）和最終狀態(tài)（FinalState）初始狀態(tài)和最終狀態(tài)是兩種特殊的狀態(tài)。初始狀態(tài)表示狀態(tài)機(jī)的執(zhí)行開始，最終狀態(tài)表示狀態(tài)機(jī)的執(zhí)行結(jié)束。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi117躍遷躍遷是兩個(gè)狀態(tài)間的一種關(guān)系，它表示對象在第一個(gè)狀態(tài)將執(zhí)行某些動(dòng)作，當(dāng)規(guī)定的事件發(fā)生或滿足規(guī)定的條件時(shí)，對象進(jìn)入第二個(gè)狀態(tài)。躍遷表示了從活動(dòng)（或動(dòng)作）到活動(dòng)（或動(dòng)作）的控制流的傳遞。躍遷由以下部分組成：源狀態(tài)與目標(biāo)狀態(tài)觸發(fā)事件護(hù)衛(wèi)條件動(dòng)作UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi118判定判定（Decision）代表了活動(dòng)圖或狀態(tài)機(jī)圖上的一個(gè)特殊位置，在這個(gè)位置上工作流將根據(jù)護(hù)衛(wèi)條件進(jìn)行分支。判定節(jié)點(diǎn)的UML符號是一個(gè)空心菱形。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi119同步條同步條（SynchronizationBars）用來定義活動(dòng)圖中的分叉（Fork）和聯(lián)結(jié)（Join）。同步條的UML符號表示用粗的水平或豎直條表示。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi120活動(dòng)活動(dòng)是在狀態(tài)機(jī)中進(jìn)行的一個(gè)非原子的執(zhí)行，它由一系列的動(dòng)作組成?；顒?dòng)的UML符號表示：UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi121節(jié)點(diǎn)節(jié)點(diǎn)是運(yùn)行時(shí)存在的物理單元，它代表了具有內(nèi)存以及處理能力的計(jì)算資源。節(jié)點(diǎn)與組件之間有許多重要的不同之處：組件參加系統(tǒng)的運(yùn)行；節(jié)點(diǎn)是運(yùn)行組件的硬件。組件代表了其他邏輯組件的物理封裝；節(jié)點(diǎn)代表了組件的物理分布。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi122UML的擴(kuò)充機(jī)制UML是可擴(kuò)充的，UML的擴(kuò)充機(jī)制允許用戶以可控制的方式擴(kuò)充語言。UML的擴(kuò)充機(jī)制包括3種：衍型（Stereotypes）衍型擴(kuò)充了UML的詞匯表，使用戶可以從已存在的模型元素派生出新模型元素，這些元素是為特定的問題域定制的。衍型提供了擴(kuò)充基本模型元素以創(chuàng)建新元素的能力。衍型的概念使得UML雖然有最小的符號集，但是可以隨時(shí)擴(kuò)充以滿足需要。衍型名字被放在“<<”和“>>”之間，且被放在模型元素的名字上面。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi123UML的擴(kuò)充機(jī)制UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi124衍型UML的擴(kuò)充機(jī)制標(biāo)記值（TaggedValues）標(biāo)記值擴(kuò)充了UML模型元素的屬性，使用戶可以在模型元素的規(guī)格說明中添加新的信息。標(biāo)記值可以用放在“{}”中的字符串表示，這個(gè)字符串由標(biāo)記名、分隔符“=”以及標(biāo)記值組成。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi125UML的擴(kuò)充機(jī)制約束（Constraints）約束擴(kuò)充了UML模型元素的語義，使用戶可以添加新規(guī)則或修改已存在的規(guī)則。在UML中，可以用約束（Constraint）表示規(guī)則。約束是放在“{}”中的一個(gè)表達(dá)式，表示一個(gè)永真的邏輯陳述。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi126小結(jié)UML提供了一個(gè)標(biāo)準(zhǔn)的、統(tǒng)一的建模符號體系。UML符號體系是可視的，應(yīng)用UML可為系統(tǒng)建立圖形化的可視模型，使系統(tǒng)的結(jié)構(gòu)變得直觀且易于理解。因此，用UML建模有利于交流。本章對各種UML符號的語義、符號、應(yīng)用逐一進(jìn)行了介紹，最后還介紹了UML符號體系的3種擴(kuò)充機(jī)制，即衍型、標(biāo)記值、約束。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi127UML系統(tǒng)分析與設(shè)計(jì)SystemAnalysis&Design

第五章視與圖視UML的圖UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi129視軟件系統(tǒng)的體系結(jié)構(gòu)可以用5個(gè)視來描述，每個(gè)視都側(cè)重描述系統(tǒng)的一個(gè)方面。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi130視1.用例視（UseCaseView）系統(tǒng)的用例視通過用例描述了最終用戶、分析人員和測試人員可以看到的系統(tǒng)行為。2.設(shè)計(jì)視（DesignView）系統(tǒng)的設(shè)計(jì)視包括類、接口、和協(xié)作，這些類、接口和協(xié)作組成了問題域詞匯表和解決方案，支持系統(tǒng)的功能需求，也即系統(tǒng)應(yīng)該提供給最終用戶的服務(wù)。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi131視3.互動(dòng)視（InteractionView）系統(tǒng)的互動(dòng)視描述了系統(tǒng)不同部分之間的控制流，包括可能的并發(fā)和同步機(jī)制。它體現(xiàn)了系統(tǒng)的性能、可擴(kuò)展性、和總處理能力。4.實(shí)現(xiàn)視（ImplementationView）系統(tǒng)的實(shí)現(xiàn)視包括了用于組裝和發(fā)布物理軟件系統(tǒng)所需的各種產(chǎn)物，主要描述了軟件系統(tǒng)版本的配置管理。實(shí)現(xiàn)視的靜態(tài)方面由組件圖捕捉；動(dòng)態(tài)方面由互動(dòng)圖、狀態(tài)機(jī)圖和活動(dòng)圖捕捉。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi132視5.部署視（DeploymentView）部署視包括了構(gòu)成用于運(yùn)行軟件系統(tǒng)的系統(tǒng)硬件拓?fù)涞墓?jié)點(diǎn)，它主要描述了物理系統(tǒng)組成部分的分布、交付和安裝。部署視的靜態(tài)方面由部署圖捕捉；動(dòng)態(tài)方面由互動(dòng)圖、狀態(tài)機(jī)圖和活動(dòng)圖捕捉。這5個(gè)視是彼此相關(guān)、交互作用的，運(yùn)用這5個(gè)視，可對軟件系統(tǒng)進(jìn)行全方位的描述。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi133UML的圖統(tǒng)一建模語言UML是用來對軟件系統(tǒng)的產(chǎn)物進(jìn)行可視化、規(guī)范定義、構(gòu)造并為之建立文檔的建模語言。UML的13種圖如下：（1）類圖（ClassDiagram）（2）對象圖（ObjectDiagram）（3）組件圖（ComponentDiagram）（4）組合結(jié)構(gòu)圖（CompositeStructureDiagram）（5）用例圖（UseCaseDiagram）（6）順序圖（SequenceDiagram）UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi134UML的圖（7）通信圖（CommunicationDiagram）（8）狀態(tài)機(jī)圖（StateMachineDiagram）（9）活動(dòng)圖（ActivityDiagram）（10）部署圖（DeploymentDiagram）（11）包圖（PackageDiagrams）（12）定時(shí)圖（TimingDiagram）（13）交互概覽圖（InteractionOverviewDiagram）UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi135UML的圖上述用于描述系統(tǒng)動(dòng)態(tài)行為的4個(gè)圖，即狀態(tài)機(jī)圖、順序圖、通信圖和活動(dòng)圖，均可用于為系統(tǒng)的動(dòng)態(tài)行為建模，但它們的側(cè)重點(diǎn)不同，應(yīng)用的目的也不同。組件圖和部署圖都可以用來描述系統(tǒng)實(shí)現(xiàn)時(shí)的一些特性，包括源代碼的靜態(tài)結(jié)構(gòu)和運(yùn)行時(shí)刻的實(shí)現(xiàn)結(jié)構(gòu)。組件圖說明代碼本身的結(jié)構(gòu)，部署圖說明系統(tǒng)運(yùn)行時(shí)刻的結(jié)構(gòu)。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi136小結(jié)本章簡單介紹了軟件系統(tǒng)體系結(jié)構(gòu)的5個(gè)視，即用例視、設(shè)計(jì)視、互動(dòng)視、實(shí)現(xiàn)視和部署視，以及為系統(tǒng)建模的13種圖，包括類圖、對象圖、組件圖、組合結(jié)構(gòu)圖、用例圖、順序圖、通信圖、狀態(tài)機(jī)圖、活動(dòng)圖、部署圖、包圖、定時(shí)圖和交互概覽圖，并概括地說明了各種圖的功能和應(yīng)用，描述了視與圖的關(guān)系，從而指導(dǎo)讀者應(yīng)該如何使用圖為系統(tǒng)的5個(gè)視的靜態(tài)方面和動(dòng)態(tài)方面建模。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi137UML系統(tǒng)分析與設(shè)計(jì)SystemAnalysis&Design第六章用例圖用例圖參與者用例用例圖的應(yīng)用UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi139UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi140用例圖用例模型描述的是系統(tǒng)外部的參與者所理解的系統(tǒng)功能。用例模型用于需求分析階段，它的建立是系統(tǒng)開發(fā)者和最終用戶反復(fù)討論的結(jié)果，也是開發(fā)者和用戶對需求規(guī)格定義達(dá)成的共識。用例圖用例模型描述了待開發(fā)系統(tǒng)的功能需求將系統(tǒng)看作黑盒，從外部參與者的角度來理解系統(tǒng)驅(qū)動(dòng)了需求分析之后各階段的開發(fā)工作，用例不僅在開發(fā)過程中保證了系統(tǒng)所有功能的實(shí)現(xiàn)，還被用于驗(yàn)證和檢測所開發(fā)的系統(tǒng)是否滿足系統(tǒng)需求，從而影響到開發(fā)工作的各個(gè)階段和UML的各個(gè)模型。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi141UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi142用例圖用例圖的3種建模元素用例(Use

Case)參與者(Actor)依賴關(guān)系、類屬關(guān)系和關(guān)聯(lián)關(guān)系。用例圖描述了用例、參與者以及它們之間的關(guān)系。用例圖UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi143UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi144用例圖參與者和用例之間存在的關(guān)聯(lián)關(guān)系通常被稱為通信關(guān)聯(lián)，因?yàn)樗碇鴧⑴c者和用例之間的通信。這個(gè)關(guān)聯(lián)可以是雙向?qū)Ш剑◤膮⑴c者到用例，并從用例到參與者），也可以是單向?qū)Ш剑◤膮⑴c者到用例，或從用例到參與者）。導(dǎo)航的方向表明了是參與者發(fā)起了和用例的通信，還是用例發(fā)起了和參與者的通信。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi145用例圖在UML中用來實(shí)現(xiàn)用例的元素是協(xié)作（Collaboration），協(xié)作是實(shí)現(xiàn)用例行為的類和其他元素的總稱。如圖所示，可以用協(xié)作“Dealwithbill”（處理賬單）來實(shí)現(xiàn)用例“Payforbill”（付賬單）。通常，每個(gè)給定的用例都會(huì)由一個(gè)相應(yīng)的協(xié)作來實(shí)現(xiàn)，所以大多數(shù)情況下不必顯式地為這種關(guān)系建模。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi146參與者參與者（Actor）代表了與系統(tǒng)接口的事物或人，它是具有某一種特定功能的角色。因此，參與者是虛擬的概念，它可以是人，也可以是外部系統(tǒng)或設(shè)備。同一個(gè)人可能對應(yīng)著多個(gè)參與者，因?yàn)橐粋€(gè)人可能扮演了多個(gè)角色。參與者不是系統(tǒng)的一部分，它們處于系統(tǒng)的外部。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi147參與者如何識別參與者？可以通過回答一系列問題●誰是系統(tǒng)的主要用戶？ ●誰從系統(tǒng)獲得信息？●誰向系統(tǒng)提供信息？ ●誰從系統(tǒng)刪除信息？●誰支持、維護(hù)系統(tǒng)？ ●誰管理系統(tǒng)？●系統(tǒng)需要與其他哪些系統(tǒng)交互（包含其他計(jì)算機(jī)系統(tǒng)和其他應(yīng)用程序）？●系統(tǒng)需要操縱哪些硬件？ ●在預(yù)設(shè)的時(shí)間內(nèi)，有事情自動(dòng)發(fā)生嗎？●系統(tǒng)從哪里獲得信息？ ●誰對系統(tǒng)的特定需求感興趣？●幾個(gè)人在扮演同樣的角色嗎？ ●一個(gè)人扮演幾個(gè)不同的角色嗎？●系統(tǒng)使用外部資源嗎？ ●系統(tǒng)要用在什么地方？UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi148參與者識別參與者需要注意：參與者代表角色。當(dāng)建立用例模型時(shí)，參與者是用來模擬角色的，而不是用來模擬物理的、現(xiàn)實(shí)世界的人、組織或系統(tǒng)本身。角色不是對職位進(jìn)行建模。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi149參與者UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi150用例用例（UseCase）是對系統(tǒng)行為的動(dòng)態(tài)描述可以增進(jìn)系統(tǒng)設(shè)計(jì)人員、開發(fā)人員與用戶的溝通，正確地理解系統(tǒng)需求；還可以劃分系統(tǒng)與外部實(shí)體的界限。用例是系統(tǒng)設(shè)計(jì)的起點(diǎn)，是類、對象、操作的來源，可以通過邏輯視圖的設(shè)計(jì)，獲得軟件的靜態(tài)結(jié)構(gòu)。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi151用例如何識別用例？可以通過以下問題幫助識別：●每個(gè)參與者的任務(wù)是什么？●有參與者要?jiǎng)?chuàng)建、存儲、改變、刪除或讀取系統(tǒng)中的信息嗎？●什么用例會(huì)創(chuàng)建、存儲、改變、刪除或讀取這個(gè)信息？●參與者需要通知系統(tǒng)外部的突然變化嗎？●需要通知參與者系統(tǒng)中正在發(fā)生的事情嗎？●什么用例將支持和維護(hù)系統(tǒng)？●所有的功能需求都能被用例實(shí)現(xiàn)嗎？UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi152用例在描述用例事件流時(shí)，每個(gè)軟件項(xiàng)目都應(yīng)使用一個(gè)標(biāo)準(zhǔn)模板。下面給出一個(gè)目前應(yīng)用最廣泛的模板。

X.用例XX（用例名）的事件流 X.1前置條件（Pre-Conditions） X.2后置條件（Post-Conditions） X.3擴(kuò)充點(diǎn)（ExtensionPoints） X.4事件流 X.4.1基流（BasicFlow） X.4.2分支流（Subflows）（可選） X.4.3替代流（AlternativeFlows）UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi153用例用例與腳本一個(gè)用例描述了一個(gè)序列集，而序列集中的每一個(gè)序列描述了一個(gè)流，這個(gè)流代表了用例的一個(gè)變種，每一個(gè)這樣的序列就被稱為一個(gè)腳本或場景（Scenario）。腳本是系統(tǒng)行為的一個(gè)特定動(dòng)作序列。腳本與用例的關(guān)系就像實(shí)例與類的關(guān)系，即腳本是用例的一個(gè)實(shí)例。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi154用例用例間的關(guān)系類屬關(guān)系用例間的類屬關(guān)系如同類間的類屬關(guān)系。也就是說，子用例繼承父用例的行為和含義，它也可以添加新行為或覆蓋父用例的行為。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi155用例用例間的關(guān)系包含關(guān)系多個(gè)用例可能具有一些相同的功能，通常將這些共享的功能放在一個(gè)單獨(dú)的用例中，在這個(gè)新用例和其他需要使用其功能的用例之間創(chuàng)建包含（Include）關(guān)系。用例間的包含關(guān)系表示在基用例的指定位置，基用例顯式地包含另一個(gè)用例的行為。被包含的用例是不能獨(dú)立存在的，只是作為包含它的更大用例的一部分。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi156用例用例間的關(guān)系（接上頁）包含關(guān)系在UML中，Include關(guān)系可以用衍型為<<include>>的依賴關(guān)系表示。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi157用例用例間的關(guān)系擴(kuò)充關(guān)系擴(kuò)充關(guān)系用來說明可選的、只在特定條件下運(yùn)行的行為。根據(jù)參與者的選擇，具有擴(kuò)充關(guān)系的用例可以運(yùn)行幾個(gè)不同的流。用例間的擴(kuò)充關(guān)系表示基用例在指定的擴(kuò)充點(diǎn)隱式地包含另一個(gè)用例的行為。擴(kuò)充關(guān)系被用來描述特定的用例部分，該用例部分被用戶視為可選的系統(tǒng)行為，這樣就將可選行為與義務(wù)行為區(qū)分開來。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi158用例用例間的關(guān)系（接上頁）擴(kuò)充關(guān)系擴(kuò)充關(guān)系用衍型為<<extend>>的依賴關(guān)系表示。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi159用例圖的應(yīng)用用例圖可以用來為系統(tǒng)的靜態(tài)用例視建模。靜態(tài)用例視體現(xiàn)系統(tǒng)的行為，即系統(tǒng)提供的外部可見的服務(wù)。用例圖可以被用來完成以下功能：為系統(tǒng)的上下文建模。為系統(tǒng)的需求建模。用例圖的應(yīng)用UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi160用例圖的應(yīng)用

為系統(tǒng)的上下文建模。如上頁圖所示，用例圖描述了一個(gè)公司管理系統(tǒng)的上下文，這個(gè)圖強(qiáng)調(diào)了系統(tǒng)周圍的參與者。為系統(tǒng)的需求建模。如上頁圖所示，用例圖可視化地描述了公司管理系統(tǒng)的功能需求，為最終用戶、領(lǐng)域?qū)＜液烷_發(fā)人員之間的交流提供了途徑。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi161小結(jié)用例模型用于需求分析階段，它描述了待開發(fā)系統(tǒng)的功能需求，并驅(qū)動(dòng)了需求分析之后各階段的開發(fā)工作。用例圖（UseCaseDiagram）是UML中用來對系統(tǒng)的動(dòng)態(tài)方面進(jìn)行建模的7種圖之一。用例圖描述了用例、參與者以及它們之間的關(guān)系。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi162小結(jié)本章介紹了用例圖的語義和功能，描述了如何識別參與者、用例，如何使用事件流描述用例；還介紹了用例和腳本的關(guān)系，舉例說明了用例間的類屬關(guān)系、包含關(guān)系和擴(kuò)充關(guān)系的語義、功能和應(yīng)用；最后舉例說明了如何使用用例圖為系統(tǒng)的上下文以及系統(tǒng)的需求建模。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi163UML系統(tǒng)分析與設(shè)計(jì)SystemAnalysis&Design第七章類圖、對象圖和包圖類圖對象圖包圖UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi165類圖類圖是面向?qū)ο笙到y(tǒng)建模最常用的圖，類圖描述了類、接口、協(xié)作以及它們之間的關(guān)系。類圖用來為系統(tǒng)的靜態(tài)設(shè)計(jì)視建模。類圖的組成部分包括：類。接口。協(xié)作。依賴、類屬、實(shí)現(xiàn)或關(guān)聯(lián)關(guān)系。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi166類圖UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi167類圖按照SteveCook和JohnDianiels的觀點(diǎn)，類圖分為3個(gè)層次，即概念層、說明層、實(shí)現(xiàn)層。1．概念層概念層（Conceptual）類圖描述了問題域中的概念。類可以從問題域的概念中得出，但兩者并沒有直接的映射關(guān)系。2．說明層說明層（Specification）類圖描述了軟件的接口部分，而沒有描述軟件的實(shí)現(xiàn)部分。UML系統(tǒng)分析與設(shè)計(jì)第2版ZhenyanJi168類圖3．實(shí)現(xiàn)