單元一

用軟件工程的思想開(kāi)發(fā)系統(tǒng)軟件工程與UML任務(wù)一：選擇適當(dāng)?shù)能浖^(guò)程模型任務(wù)二：用UML模型表達(dá)開(kāi)發(fā)過(guò)程目錄CONTENTS【知識(shí)目標(biāo)】理解軟件和軟件工程的概念理解軟件開(kāi)發(fā)生命周期理解UML在面向?qū)ο蟮能浖_(kāi)發(fā)過(guò)程中的作用掌握軟件過(guò)程模型運(yùn)用的原則【能力目標(biāo)】能根據(jù)需求選擇合適的軟件過(guò)程模型能讀懂軟件開(kāi)發(fā)文檔中簡(jiǎn)單的UML模型引例描述

“醫(yī)院預(yù)約掛號(hào)系統(tǒng)”是指利用電話、網(wǎng)站、自助終端、現(xiàn)場(chǎng)等渠道方便患者預(yù)約看病的系統(tǒng)。

醫(yī)院提供預(yù)約掛號(hào)系統(tǒng)對(duì)于方便群眾就醫(yī)、提高醫(yī)療服務(wù)水平具有重大意義。施行預(yù)約掛號(hào)服務(wù)后，患者可以方便地進(jìn)行就醫(yī)咨詢，提前安排就醫(yī)計(jì)劃，減少候診時(shí)間。同時(shí)也有利于醫(yī)院提升管理水平，提高工作效率和醫(yī)療質(zhì)量，在一定程度中降低醫(yī)療安全風(fēng)險(xiǎn)。任務(wù)一選擇適當(dāng)?shù)能浖^(guò)程模型01

任務(wù)陳述不同的軟件過(guò)程模型有著各自的適用范圍，合理選擇將有助于降低風(fēng)險(xiǎn)、降低開(kāi)發(fā)成本，提高軟件的成功率。根據(jù)“醫(yī)院預(yù)約掛號(hào)系統(tǒng)”的現(xiàn)有需求和開(kāi)發(fā)意圖，怎樣選擇適合的軟件過(guò)程模型。

知識(shí)準(zhǔn)備1.1軟件工程基本理論1.1.1軟件及其特點(diǎn)1.1.2軟件危機(jī)1.1.3軟件工程的定義1.1.4軟件工程的基本原理1.1.5軟件開(kāi)發(fā)生命周期1.1.6常見(jiàn)的軟件過(guò)程模型1.1.7軟件過(guò)程模型的應(yīng)用原則開(kāi)發(fā)出來(lái)的軟件往往與用戶的需求有偏差；往往在看到最終交付的產(chǎn)品時(shí)，用戶才真正明確自己的需求；在軟件開(kāi)發(fā)過(guò)程中，需求可能經(jīng)常在變，原因可能是用戶本身需求的變化，也可能是我們對(duì)需求的理解在發(fā)生變化，但結(jié)果是每次需求變化會(huì)帶來(lái)軟件系統(tǒng)的開(kāi)發(fā)延遲，甚至出現(xiàn)變更反復(fù)，被推倒了的內(nèi)容又要重新確立；在軟件沒(méi)有最終交付時(shí)，用戶如何了解開(kāi)發(fā)進(jìn)展情況；系統(tǒng)難以維護(hù)和擴(kuò)展，經(jīng)常重復(fù)開(kāi)發(fā)類(lèi)似的功能；項(xiàng)目經(jīng)常延期，實(shí)際成本往往遠(yuǎn)遠(yuǎn)高于估計(jì)成本；開(kāi)發(fā)團(tuán)隊(duì)內(nèi)部使用了不同的技術(shù)，在交流時(shí)常常有障礙；……軟件危機(jī)的影響軟件及其特點(diǎn)

軟件=程序+數(shù)據(jù)+文檔

軟件是計(jì)算機(jī)系統(tǒng)中與硬件相互依存的另一部分，與硬件合為一體完成系統(tǒng)功能軟件是腦力勞動(dòng)的產(chǎn)品，但它不同于追求個(gè)性化的藝術(shù)作品；軟件是產(chǎn)品，但它又不同于工業(yè)化生產(chǎn)得到的有形產(chǎn)品

軟件及其特點(diǎn)

軟件的特點(diǎn)描述抽象性軟件是一種邏輯實(shí)體而不是具體的物理實(shí)體，必須通過(guò)測(cè)試、分析、思考、判斷來(lái)了解它的功能、性能及其他特性可復(fù)制性軟件是通過(guò)人們的智力活動(dòng)，把知識(shí)與技術(shù)轉(zhuǎn)化成信息的一種產(chǎn)品，是在研制、開(kāi)發(fā)中被創(chuàng)造出來(lái)的。一旦某一軟件項(xiàng)目研制成功，以后就可以大量地復(fù)制同一內(nèi)容的副本，即其研制成本遠(yuǎn)遠(yuǎn)大于其生產(chǎn)成本不會(huì)磨損在軟件的運(yùn)行和使用期間，沒(méi)有硬件那樣的機(jī)械磨損、老化問(wèn)題，但軟件也會(huì)出現(xiàn)故障，軟件維護(hù)比硬件維護(hù)要復(fù)雜得多，與硬件的維修有著本質(zhì)的差別依賴性軟件的開(kāi)發(fā)和運(yùn)行經(jīng)常受到計(jì)算機(jī)系統(tǒng)的限制，對(duì)計(jì)算機(jī)系統(tǒng)有著不同程度的依賴。為了消除這種依賴，在軟件開(kāi)發(fā)中提出了軟件移植的問(wèn)題，并且把軟件的可移植性作為衡量軟件質(zhì)量的因素之一開(kāi)發(fā)效率低軟件的開(kāi)發(fā)尚未完全擺脫手工的方式，依然有大量重復(fù)性的勞動(dòng)開(kāi)發(fā)費(fèi)用高軟件的研制工作需要投入大量的、復(fù)雜的、高強(qiáng)度的腦力勞動(dòng)，需要較高的成本。軟件的開(kāi)發(fā)是一個(gè)復(fù)雜的過(guò)程，因而管理是軟件開(kāi)發(fā)過(guò)程中必不可少的內(nèi)容軟件及其特點(diǎn)

什么是軟件危機(jī)

在計(jì)算機(jī)軟件的開(kāi)發(fā)和維護(hù)過(guò)程中所遇到的一系列嚴(yán)重問(wèn)題。

軟件危機(jī)包含下述兩方面的問(wèn)題：如何開(kāi)發(fā)軟件，以滿足對(duì)軟件日益增長(zhǎng)的需求；如何維護(hù)數(shù)量不斷增加的已有軟件。

消除軟件危機(jī)的途徑

正確認(rèn)識(shí)軟件。

加強(qiáng)管理。使用軟件工具。

軟件危機(jī)軟件工程的定義軟件工程=管理+技術(shù)軟件工程的目標(biāo)軟件工程的定義

軟件工程的基本原理（1）用分階段的生命周期計(jì)劃嚴(yán)格管理。（2）堅(jiān)持進(jìn)行階段評(píng)審。（3）實(shí)行嚴(yán)格的產(chǎn)品控制。（4）采用現(xiàn)代程序設(shè)計(jì)技術(shù)。（5）結(jié)果應(yīng)能清楚地審查。（6）開(kāi)發(fā)小組的人員應(yīng)該少而精。（7）不斷改進(jìn)軟件工程實(shí)踐的經(jīng)驗(yàn)和技術(shù)。軟件工程的基本原理

如何蓋一棟大樓？軟件開(kāi)發(fā)生命周期軟件開(kāi)發(fā)生命周期可以劃分成計(jì)劃、設(shè)計(jì)、開(kāi)發(fā)和運(yùn)行維護(hù)4個(gè)時(shí)期1．問(wèn)題定義—“要解決的問(wèn)題是什么？”2．可行性論證及軟件計(jì)劃—“有行得通的解決辦法嗎？”3．需求分析——“系統(tǒng)必須做什么？”4．總體設(shè)計(jì)——“概括地說(shuō)，應(yīng)該怎樣做？”5．詳細(xì)設(shè)計(jì)——“具體怎樣做？”6．編碼和單元測(cè)試7．綜合測(cè)試8．運(yùn)行/維護(hù)軟件開(kāi)發(fā)生命周期1．建造-修補(bǔ)模型早前，軟件開(kāi)發(fā)人員在進(jìn)行軟件開(kāi)發(fā)時(shí)不使用規(guī)格說(shuō)明，或者不嘗試進(jìn)行設(shè)計(jì)；只是簡(jiǎn)單地建造了一個(gè)軟件產(chǎn)品，但為滿足客戶的要求，只能不斷地改寫(xiě)該軟件，這就是所謂的建造-修補(bǔ)模型。幾種常見(jiàn)的軟件過(guò)程模型2．瀑布模型核心思想是階段性的評(píng)審和驗(yàn)證，每一階段結(jié)束時(shí)都要給出完整的文檔。缺點(diǎn)是該模型缺乏靈活性，后一階段出現(xiàn)的問(wèn)題需要通過(guò)前一階段的重新確認(rèn)來(lái)解決。幾種常見(jiàn)的軟件過(guò)程模型3．原型模型快速設(shè)計(jì)軟件中對(duì)用戶可見(jiàn)部分的表示，構(gòu)造原型，由用戶評(píng)估，逐步調(diào)整原型，使之滿足用戶需要。其優(yōu)點(diǎn)是開(kāi)發(fā)者和用戶可以充分溝通，開(kāi)發(fā)過(guò)程也是學(xué)習(xí)過(guò)程，可以低風(fēng)險(xiǎn)開(kāi)發(fā)柔性較大的計(jì)算機(jī)系統(tǒng)。幾種常見(jiàn)的軟件過(guò)程模型4．螺旋模型把軟件開(kāi)發(fā)過(guò)程組成為一個(gè)逐步細(xì)化的螺旋周期，每經(jīng)歷一個(gè)周期，系統(tǒng)就得到進(jìn)一步的細(xì)化和完善；整個(gè)模型緊密?chē)@開(kāi)發(fā)中的風(fēng)險(xiǎn)分析，推動(dòng)軟件設(shè)計(jì)向深層擴(kuò)展和求精。該模型要求開(kāi)發(fā)人員與用戶能經(jīng)常直接進(jìn)行交流，通常用來(lái)指導(dǎo)內(nèi)部發(fā)行的大型軟件項(xiàng)目的開(kāi)發(fā)幾種常見(jiàn)的軟件過(guò)程模型5．增量模型一種漸近式的模型，它把軟件產(chǎn)品作為一系列的增量構(gòu)件來(lái)設(shè)計(jì)、編碼、集成和測(cè)試。第一個(gè)增量構(gòu)件往往實(shí)現(xiàn)軟件的基本需求，提供最核心的功能。幾種常見(jiàn)的軟件過(guò)程模型6．迭代模型迭代模型也是一種漸近式的模型。就對(duì)風(fēng)險(xiǎn)的消除上，增量和迭代模型都能夠很好地控制前期的風(fēng)險(xiǎn)，但迭代模型在這方面更有優(yōu)勢(shì)。迭代模型可以更多地從總體方面思考系統(tǒng)問(wèn)題，一開(kāi)始就給出相對(duì)完善的框架或原型，后期的每次迭代都是針對(duì)上次迭代的逐步精化。幾種常見(jiàn)的軟件過(guò)程模型7．噴泉模型認(rèn)為軟件生命周期的各個(gè)階段是相互重疊和多次反復(fù)的，就像水噴上去又可以落下來(lái)，水既可以落在中間，也可以落在最底部。整個(gè)開(kāi)發(fā)過(guò)程中都使用統(tǒng)一的概念“對(duì)象”進(jìn)行分析，使用統(tǒng)一的概念和符號(hào)表示分析設(shè)計(jì)過(guò)程，各階段間沒(méi)有明顯的邊界，即“無(wú)縫”銜接，因此各開(kāi)發(fā)步驟可以多次反復(fù)迭代，逐步深化。幾種常見(jiàn)的軟件過(guò)程模型8．MSF過(guò)程模型吸收了瀑布模型的里程碑和螺旋模型的反復(fù)迭代的思想。分為5個(gè)階段，每一階段結(jié)束時(shí)都有明確的交付成果。幾種常見(jiàn)的軟件過(guò)程模型（1）總體上說(shuō)，面向?qū)ο蟮某绦蛟O(shè)計(jì)采用的是噴泉模型，但局部可以結(jié)合其他模型。（2）在前期需求明確、資料完整的情況下盡量采用瀑布模型。（3）在用戶無(wú)信息系統(tǒng)使用經(jīng)驗(yàn)、需求分析人員技能不足的情況下要借助原型。（4）在不確定性因素很多、很多東西前面無(wú)法計(jì)劃的情況下盡量采用增量模型和螺旋模型。（5）在需求不穩(wěn)定的情況下盡量采用增量迭代模型。（6）在資金和成本無(wú)法一次到位的情況下可以采用增量模型，將產(chǎn)品分多個(gè)版本進(jìn)行發(fā)布。（7）增量、迭代和原型可以綜合使用，但每一次增量或迭代都必須有明確的交付內(nèi)容。

軟件過(guò)程模型的應(yīng)用原則方案一：采用瀑布模型開(kāi)發(fā)系統(tǒng)方案二：采用螺旋模型開(kāi)發(fā)系統(tǒng)

任務(wù)實(shí)施拓展訓(xùn)練一：“字處理軟件新版本開(kāi)發(fā)”的軟件過(guò)程模型拓展訓(xùn)練二：“學(xué)生成績(jī)管理系統(tǒng)”的軟件過(guò)程模型

拓展訓(xùn)練任務(wù)二用UML模型表達(dá)開(kāi)發(fā)過(guò)程02

任務(wù)陳述UML模型貫穿在整個(gè)軟件開(kāi)發(fā)的過(guò)程中，開(kāi)發(fā)人員獲取系統(tǒng)需求，進(jìn)行分析和設(shè)計(jì)，進(jìn)行溝通等的有效手段，UML在軟件工程提出的“軟件文檔化，文檔可視化”的過(guò)程中發(fā)揮著重要的作用。試閱讀ATM系統(tǒng)的建模過(guò)程，體驗(yàn)?zāi)Ｐ驮谲浖_(kāi)發(fā)過(guò)程中的作用，了解不同開(kāi)發(fā)階段的主要模型。

知識(shí)準(zhǔn)備1.2軟件工程與UML1.2.1面向?qū)ο蟮能浖こ?.2.2UML的概述研究如何通過(guò)分解和抽象，將復(fù)雜問(wèn)題轉(zhuǎn)化成一系列可以理解和實(shí)現(xiàn)的簡(jiǎn)單問(wèn)題。

面向?qū)ο蟮能浖こ堂嫦蜻^(guò)程的程序=算法+數(shù)據(jù)結(jié)構(gòu)。面向?qū)ο蟮某绦?對(duì)象+類(lèi)+繼承+消息通信。面向構(gòu)件的程序=構(gòu)件+架構(gòu)。形式化方法是建立在嚴(yán)格的數(shù)學(xué)基礎(chǔ)上，以邏輯推理為出發(fā)點(diǎn)，具有精確數(shù)學(xué)語(yǔ)義的開(kāi)發(fā)方法。面向?qū)ο蟮能浖こ淌裁词敲嫦驅(qū)ο蟮拈_(kāi)發(fā)方法

面向?qū)ο蟮拈_(kāi)發(fā)方法的特點(diǎn)是根據(jù)現(xiàn)實(shí)問(wèn)題直接抽象出對(duì)象，分析對(duì)象的行為和與行為相關(guān)的數(shù)據(jù)，對(duì)象間通過(guò)傳遞消息進(jìn)行通信，協(xié)作完成相應(yīng)的功能。它從問(wèn)題出發(fā)，模擬現(xiàn)實(shí)問(wèn)題建立系統(tǒng)模型，易于理解和實(shí)現(xiàn)。（1）反復(fù)迭代完善需求（2）反復(fù)迭代進(jìn)行邏輯設(shè)計(jì)（3）進(jìn)行物理設(shè)計(jì)面向?qū)ο蟮能浖こ堂嫦驅(qū)ο蟮能浖こ痰膬?yōu)勢(shì)

（1）概念的一致性

（2）文檔可視化

（3）迭代式開(kāi)發(fā)

（4）使用模式

（5）基于組件的架構(gòu)

（6）允許變更

面向?qū)ο蟮能浖こ淌裁词擒浖ＤＰ偷娜齻€(gè)特點(diǎn)是一種簡(jiǎn)化；通過(guò)不同的視角看問(wèn)題；使用通用的符號(hào)。軟件建模的實(shí)現(xiàn)過(guò)程面向?qū)ο蟮能浖C(jī)制什么是軟件建模統(tǒng)一建模語(yǔ)言（UnifiedModelingLanguage，UML）是一種通用的可視化面向?qū)ο蟮慕ＵZ(yǔ)言，適用于對(duì)任何面向?qū)ο蟮氖挛锏慕＃缑嫦驅(qū)ο蟮能浖！I(yè)務(wù)建模。

什么是UML最初的階段是專(zhuān)家的聯(lián)合行動(dòng)，由三位OO（面向?qū)ο螅┓椒▽W(xué)家將他們各自的方法結(jié)合在一起，形成UML0.9。第二階段是公司的聯(lián)合行動(dòng)，由十幾家公司組成的“UML伙伴組織”將各自的意見(jiàn)加入U(xiǎn)ML，形成UML1.0和1.1，并作為向OMG申請(qǐng)成為建模語(yǔ)言規(guī)范的提案。第三階段是在OMG控制下的修訂與改進(jìn)，OMG于1997年11月正式采納UML1.1作為建模語(yǔ)言規(guī)范。第四階段是作出重大修訂后于2003年推出UML2.0，UML得到了廣泛認(rèn)可和使用。

UML的歷史用例圖靜態(tài)圖類(lèi)圖（ClassDiagram）對(duì)象圖（ObjectDiagram）包圖（PackageDiagram）行為圖狀態(tài)圖（StatechartDiagram）活動(dòng)圖（ActivityDiagram）交互圖順序圖（SequenceDiagram）協(xié)作圖（CollaborationDiagram）實(shí)現(xiàn)圖組件圖（ComponentDiagram）部署圖（DeploymentDiagram）UML中的五類(lèi)圖UML建模機(jī)制UML建模的基本過(guò)程不同開(kāi)發(fā)階段的UML模型

UML建模的基本過(guò)程它是優(yōu)秀的文檔可視化工具，符號(hào)形象直觀。能體現(xiàn)文檔的連貫性（即需求→設(shè)計(jì)→實(shí)現(xiàn)的自然過(guò)渡，且能較靈活地應(yīng)對(duì)變更）。貫穿軟件開(kāi)發(fā)生命周期的各個(gè)階段。能清楚地表達(dá)設(shè)計(jì)模式。與最好的軟件工程實(shí)踐經(jīng)驗(yàn)集成。為面向?qū)ο蟮脑O(shè)計(jì)與開(kāi)發(fā)中涌現(xiàn)出的高級(jí)概念（如協(xié)作、框架、模式和組件）提供支持，強(qiáng)調(diào)在軟件開(kāi)發(fā)中對(duì)架構(gòu)、框架、模式和組件的重用。與具體的實(shí)現(xiàn)無(wú)關(guān)，可應(yīng)用于任何語(yǔ)言平臺(tái)和工具平臺(tái)。與具體的過(guò)程無(wú)關(guān)，可應(yīng)用于任何軟件開(kāi)發(fā)的過(guò)程?，F(xiàn)代軟件工程中的作用ATM系統(tǒng)的軟件建模過(guò)程概覽

任務(wù)實(shí)施拓展訓(xùn)練一：了解軟件工程的發(fā)展拓展訓(xùn)練二：了解UML的用途

拓展訓(xùn)練軟件不僅僅是程序，軟件=程序+數(shù)據(jù)+文檔。軟件工程是為了盡可能消除軟件危機(jī)的影響，克服軟件缺乏“可見(jiàn)性”的缺點(diǎn)，借鑒工業(yè)化生產(chǎn)的成功經(jīng)驗(yàn)，對(duì)軟件產(chǎn)品的生產(chǎn)過(guò)程加以嚴(yán)格管理和控制的一門(mén)學(xué)科。它的最終目的是實(shí)現(xiàn)軟件的工業(yè)化生產(chǎn)。傳統(tǒng)軟件工程將軟件開(kāi)發(fā)生命周期劃分為問(wèn)題定義、可行性分析、需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼、測(cè)試、運(yùn)行維護(hù)8個(gè)階段，每一階段都有具體的任務(wù)和交付成果。軟件過(guò)程模型指如何具體地組織銜接軟件開(kāi)發(fā)生命周期的各個(gè)階段。常用的有瀑布模型、原型模型、螺旋模型、增量模型和噴泉模型等。面向?qū)ο蟮某绦蛟O(shè)計(jì)方法根據(jù)現(xiàn)實(shí)問(wèn)題直接抽象出對(duì)象，分析對(duì)象的行為和與行為相關(guān)的數(shù)據(jù)，對(duì)象間通過(guò)傳遞消息進(jìn)行通信，從問(wèn)題出發(fā)，模擬現(xiàn)實(shí)問(wèn)題建立系統(tǒng)模型，易于理解和實(shí)現(xiàn)。在進(jìn)行面向?qū)ο蟮脑O(shè)計(jì)時(shí)，從需求分析到系統(tǒng)設(shè)計(jì)都是一個(gè)反復(fù)迭代的過(guò)程。統(tǒng)一建模語(yǔ)言（UML）是一種通用的可視化面向?qū)ο蟮慕ＵZ(yǔ)言，它使用通用的符號(hào)，通過(guò)反復(fù)迭代的建模機(jī)制分析需求、進(jìn)行系統(tǒng)的分析和設(shè)計(jì)。它貫穿于軟件工程全過(guò)程，在軟件開(kāi)發(fā)的不同階段、針對(duì)不同的任務(wù)，有不同的建模表現(xiàn)形式?，F(xiàn)代軟件工程的成功經(jīng)驗(yàn)，強(qiáng)調(diào)文檔的可視化，軟件的重用性，代表多方利益的人員之間無(wú)障礙的交流。在這些環(huán)節(jié)中，UML發(fā)揮著重要的作用。

本章小結(jié)學(xué)生成績(jī)管理系統(tǒng)的初始用例建模在任務(wù)一的拓展訓(xùn)練中，你已經(jīng)根據(jù)“學(xué)生成績(jī)管理系統(tǒng)”的需求描述選擇了相應(yīng)的軟件過(guò)程模型，現(xiàn)在，請(qǐng)進(jìn)一步分析該系統(tǒng)的功能，得出期初始用例模型。注意，現(xiàn)階段我們只需要分析系統(tǒng)最基礎(chǔ)最核心的功能即可。請(qǐng)注意保存原始資料和得到的模型，我們將在后繼任務(wù)中做進(jìn)一步的分析。

項(xiàng)目實(shí)訓(xùn)THANKYOU單元二

系統(tǒng)的功能需求建模軟件工程與UML任務(wù)一：初步建模系統(tǒng)的功能需求任務(wù)二：細(xì)化系統(tǒng)的功能需求目錄CONTENTS任務(wù)三：重構(gòu)系統(tǒng)的功能需求模型任務(wù)四：用例模型的分層分包處理【知識(shí)目標(biāo)】了解用例圖的主要組件理解用例間的包含、擴(kuò)展、泛化關(guān)系掌握用例建模的一般過(guò)程掌握軟件工具的使用【能力目標(biāo)】能準(zhǔn)確識(shí)別系統(tǒng)的參與者和用例能準(zhǔn)確識(shí)別系統(tǒng)的關(guān)系，建模初始用例模型能按照規(guī)范書(shū)寫(xiě)用例文檔能利用用例文檔及活動(dòng)圖建模系統(tǒng)的事件流引例描述

“某一書(shū)店為加快資金周轉(zhuǎn)，以便盡快更新書(shū)籍、吸引讀者，除日常賣(mài)書(shū)以外，還開(kāi)辟了借書(shū)業(yè)務(wù)。現(xiàn)需要開(kāi)發(fā)一個(gè)軟件，以管理會(huì)員和日常借書(shū)事務(wù)，即交納400、200或100元會(huì)費(fèi)即可成為金、銀、銅卡會(huì)員，可在一年有效期內(nèi)借書(shū)，并享受相應(yīng)購(gòu)書(shū)折扣。任務(wù)一

初步建模系統(tǒng)的功能需求01

任務(wù)陳述軟件開(kāi)發(fā)首先需解決的第一個(gè)問(wèn)題是用戶和開(kāi)發(fā)人員如何統(tǒng)一認(rèn)識(shí)，一方面，用戶對(duì)自己的專(zhuān)業(yè)領(lǐng)域很熟悉，對(duì)軟件需求的表述卻可能不夠準(zhǔn)確，對(duì)軟件能夠?qū)崿F(xiàn)的需求可能了解尚不全面，對(duì)希望軟件實(shí)現(xiàn)的需求可能尚不明確；另一方面，開(kāi)發(fā)人員在沒(méi)有完全了解用戶的專(zhuān)業(yè)領(lǐng)域時(shí)，對(duì)用戶表述的理解可能會(huì)有較大的偏差，對(duì)軟件可以實(shí)現(xiàn)的需求不能作出準(zhǔn)確判斷。用什么樣的模型去說(shuō)明軟件產(chǎn)品或軟件項(xiàng)目需要滿足的條件和限制，準(zhǔn)確界定軟件系統(tǒng)的邊界，并在開(kāi)發(fā)者和用戶間達(dá)成一致是該借書(shū)系統(tǒng)軟件本階段亟待解決的問(wèn)題。

知識(shí)準(zhǔn)備2.1用例圖概述2.1.1用例建模的目的2.1.2定義用例圖2.1.3用例圖的主要組件2.2識(shí)別參與者2.2.1捕獲需求2.2.2識(shí)別參與者2.3識(shí)別用例2.3.1識(shí)別用例的方法2.3.2用例的命名規(guī)則2.4用例間的關(guān)系2.4.1泛化關(guān)系2.4.2包含關(guān)系2.4.3擴(kuò)展關(guān)系用例建模的目的利用“系統(tǒng)”的觀點(diǎn)來(lái)分析問(wèn)題、解決問(wèn)題。使用計(jì)算機(jī)邏輯來(lái)模擬描述系統(tǒng)本身，包括系統(tǒng)的組成、關(guān)系、系統(tǒng)的各種可能狀態(tài)以及系統(tǒng)中可能產(chǎn)生的過(guò)程和過(guò)程引起的切換。可以利用一個(gè)容易理解的模型來(lái)描述用戶如何使用這個(gè)系統(tǒng)、系統(tǒng)和客戶以及系統(tǒng)和外部系統(tǒng)之間的交互過(guò)程，這個(gè)模型也就是通常我們所說(shuō)的使用UML設(shè)計(jì)新系統(tǒng)的起始點(diǎn)——用例圖。用例建模的目的定義用例圖用例圖是有關(guān)系統(tǒng)細(xì)節(jié)的最高形式。它能準(zhǔn)確地說(shuō)明客戶對(duì)他們要開(kāi)發(fā)的應(yīng)用程序期望有什么樣的功能用例圖是一種在系統(tǒng)完成后能使管理機(jī)構(gòu)、用戶和其他干系人了解其功能的極好方法。

登錄系統(tǒng)存款取款查詢余額修改密碼轉(zhuǎn)賬退出系統(tǒng)客戶定義用例圖用例圖的主要組件用例圖包含4個(gè)基本組件：參與者（Actor）、用例（UseCase）、關(guān)系、系統(tǒng)。（1）參與者。參與者是系統(tǒng)外部的一個(gè)實(shí)體，它以某種方式參與用例的執(zhí)行過(guò)程。（2）用例。用例代表系統(tǒng)的某項(xiàng)完整的功能，是動(dòng)作步驟的集合。系統(tǒng)的功能是通過(guò)參與者使用用例來(lái)實(shí)現(xiàn)的。

用例圖的主要組件用例圖的主要組件用例圖包含4個(gè)基本組件：參與者（Actor）、用例（UseCase）、關(guān)系、系統(tǒng)。（3）關(guān)系。除了用例和參與者之間的關(guān)聯(lián)關(guān)系以外，還可以定義參與者之間的泛化關(guān)系，用例之間有包含、擴(kuò)展和泛化關(guān)系。（4）系統(tǒng)。系統(tǒng)指一個(gè)軟件系統(tǒng)、一項(xiàng)業(yè)務(wù)、一個(gè)商務(wù)活動(dòng)、一臺(tái)機(jī)器等。(圖見(jiàn)書(shū))用例圖的主要組件捕獲需求收集需求的方式有訪談、問(wèn)卷調(diào)查、實(shí)地觀察、使用原型、特定群體調(diào)查、用戶指導(dǎo)等。需求的來(lái)源主要是人、各種現(xiàn)有成品（如報(bào)表、培訓(xùn)手冊(cè)、視頻記錄等）、現(xiàn)有的軟件系統(tǒng)或人工系統(tǒng)。通過(guò)各種形式記錄下收集到的需求信息，經(jīng)過(guò)整理，從中獲取有價(jià)值的信息來(lái)建立系統(tǒng)模型。識(shí)別參與者識(shí)別參與者的方法識(shí)別參與者的思路，可以從以下幾個(gè)方面來(lái)考慮：（1）誰(shuí)使用系統(tǒng)的主要功能？（2）誰(shuí)改變系統(tǒng)的數(shù)據(jù)？（3）誰(shuí)從系統(tǒng)獲取信息？（4）誰(shuí)需要系統(tǒng)的支持以完成日常工作任務(wù)？（5）誰(shuí)負(fù)責(zé)維護(hù)、管理并保持系統(tǒng)正常運(yùn)行？（6）系統(tǒng)需要處理哪些硬設(shè)備？（7）系統(tǒng)需要和哪些外部系統(tǒng)交互？（8）誰(shuí)對(duì)系統(tǒng)運(yùn)行產(chǎn)生的結(jié)果感興趣？（9）有無(wú)時(shí)間、氣溫等內(nèi)部或外部條件？識(shí)別參與者識(shí)別用例的方法在識(shí)別用例的過(guò)程中，可以從以下幾個(gè)方面來(lái)考慮：（1）特定參與者希望系統(tǒng)提供什么功能。（2）系統(tǒng)是否存儲(chǔ)和檢索信息，如果是，由哪個(gè)參與者觸發(fā)。（3）當(dāng)系統(tǒng)改變狀態(tài)時(shí)，是否通知參與者。（4）是否存在影響系統(tǒng)的外部事件。識(shí)別用例用例的命名規(guī)則用例名是一個(gè)字符串，用例是從用戶的角度來(lái)描繪系統(tǒng)的功能，因此命名的基本原則是：從參與者的角度出發(fā)進(jìn)行命名（如使用“登錄”而不用“身份驗(yàn)證”），使用動(dòng)詞加賓語(yǔ)的結(jié)構(gòu)，盡量使用行業(yè)術(shù)語(yǔ)（如使用“報(bào)銷(xiāo)”，而不用“交錢(qián)”）。系統(tǒng)中用例太多時(shí)需求要適當(dāng)分組（包），這時(shí)可以通過(guò)在用例名后面加上雙冒號(hào)和包名來(lái)表示該用例是屬于哪個(gè)包的。識(shí)別用例泛化關(guān)系用例與用例之間也存在著泛化關(guān)系，通常用于表示同一業(yè)務(wù)目的（父用例）的不同技術(shù)實(shí)現(xiàn)（各個(gè)子用例）。4.3.2用例的命名規(guī)則用例間的關(guān)系包含關(guān)系在包含關(guān)系中，基本用例吸收了被包含的用例的行為，如果沒(méi)有后者它將是不完整的。包含關(guān)系的劃分有兩個(gè)好處：一是被包含用例被抽取出來(lái)，基本用例得以簡(jiǎn)化；二是可以抽象出公共事件流，實(shí)現(xiàn)功能代碼的復(fù)用。用例間的關(guān)系擴(kuò)展關(guān)系如果在完成某個(gè)功能的時(shí)候有時(shí)會(huì)執(zhí)行另一個(gè)功能，則用擴(kuò)展關(guān)系來(lái)表示。擴(kuò)展關(guān)系表示為虛線箭頭加“<<extend>>”字樣，箭頭指向被擴(kuò)展的用例。教師在保存成績(jī)的時(shí)候，如果有學(xué)生成績(jī)不合格將打印補(bǔ)考通知單用例間的關(guān)系步驟一：確定系統(tǒng)邊界步驟二：識(shí)別參與者步驟三：識(shí)別用例步驟四：建立用例圖

任務(wù)實(shí)施拓展訓(xùn)練一：用例的泛化與特化拓展訓(xùn)練二：設(shè)計(jì)銷(xiāo)售網(wǎng)點(diǎn)的用例圖

拓展訓(xùn)練任務(wù)二

細(xì)化系統(tǒng)的功能需求02

任務(wù)陳述在上一個(gè)任務(wù)環(huán)節(jié)中，我們通過(guò)確定系統(tǒng)邊界、識(shí)別參與者、識(shí)別用例、建立出了書(shū)店借書(shū)系統(tǒng)的初始用例圖，初步描繪了系統(tǒng)的功能需求。但用例圖不足以表達(dá)更多的細(xì)節(jié)，在本任務(wù)環(huán)節(jié)中我們將通過(guò)用例文檔和活動(dòng)圖詳細(xì)描述書(shū)店借書(shū)系統(tǒng)每個(gè)用例以及參與者和用例之間的交互關(guān)系。

知識(shí)準(zhǔn)備2.5用例文檔與活動(dòng)圖2.5.1用例文檔2.5.2活動(dòng)圖用例模型不足以表達(dá)系統(tǒng)功能需求的全部信息，對(duì)于用例圖中的每個(gè)用例而言，還需要通過(guò)“用例文檔”進(jìn)行詳細(xì)地描述。用例描述，簡(jiǎn)要描述用例的主要作用。前置條件，即參與者啟動(dòng)這個(gè)用例之前必須完成的所有用例。后置條件，即執(zhí)行這個(gè)用例對(duì)系統(tǒng)所做的所有改變。部署約束，即描述訪問(wèn)這個(gè)用例的所有約束。事件流，即描述參與者在完成用例的過(guò)程中發(fā)生的一系列的交互行為，事件流有以下三種類(lèi)型。（1）基本事件流，通過(guò)描述一切都按部就班時(shí)情況來(lái)捕捉用例的目標(biāo)（2）可選事件流，即描述由參與者引起的變更（3）異常事件流，即描述由系統(tǒng)引起的變更

知識(shí)準(zhǔn)備用例文檔用例圖不足以表達(dá)更多的細(xì)節(jié)，對(duì)于系統(tǒng)中的每一個(gè)用例，還需要了解詳細(xì)的執(zhí)行情況，以便完整地理解創(chuàng)建系統(tǒng)時(shí)的設(shè)計(jì)任務(wù)。用例文檔為我們提供了一個(gè)很好的模板。用例編號(hào)：用例名：用例描述：參與者：前置條件：后置條件：事件路徑：擴(kuò)展點(diǎn)：補(bǔ)充說(shuō)明：用例文檔活動(dòng)圖用于描述系統(tǒng)、子系統(tǒng)、用例、程序模塊中的工作流，幫助理解系統(tǒng)高層活動(dòng)的執(zhí)行過(guò)程定義活動(dòng)圖活動(dòng)圖活動(dòng)圖的符號(hào)一個(gè)活動(dòng)圖必然有一個(gè)開(kāi)始狀態(tài)至少有一個(gè)結(jié)束狀態(tài)轉(zhuǎn)移用來(lái)表示活動(dòng)或狀態(tài)間的控制流有分支時(shí)要在分支路徑中注明分支條件分岔用來(lái)開(kāi)始并行處理聯(lián)結(jié)用于把并行處理轉(zhuǎn)換為單個(gè)處理活動(dòng)圖ATM機(jī)“登錄”用例的活動(dòng)圖活動(dòng)圖游泳道將活動(dòng)圖的活動(dòng)狀態(tài)分組，每一組表示負(fù)責(zé)那些活動(dòng)的業(yè)務(wù)組織，直接顯示動(dòng)作在哪一個(gè)業(yè)務(wù)組織中執(zhí)行每一個(gè)活動(dòng)都只能明確地屬于一個(gè)泳道定義活動(dòng)圖活動(dòng)圖（1）定義活動(dòng)圖范圍，確定開(kāi)始、結(jié)束狀態(tài)。（2）添加活動(dòng)，建模主路徑。（3）尋找分支和并行的情況，建模擴(kuò)展路徑。（4）根據(jù)需要?jiǎng)澐钟斡镜?。如何建?；顒?dòng)圖活動(dòng)圖活動(dòng)圖“餐館訂餐”系統(tǒng)的用例圖“記錄預(yù)約”用例的事件路徑如下：1．接待員輸入要預(yù)約的日期2．系統(tǒng)顯示該日的預(yù)約3．有一張合適的餐桌可以使用，接待員輸入顧客的姓名和電話號(hào)碼、預(yù)約的時(shí)間、用餐人數(shù)和餐桌號(hào)

3a沒(méi)有合適的餐桌可以使用

3a1用例終止4．系統(tǒng)記錄并顯示該預(yù)約

4a輸入的預(yù)約人數(shù)多于餐桌能容納的人數(shù)

4a1系統(tǒng)發(fā)出一個(gè)警告信息，詢問(wèn)用戶是否想要繼續(xù)預(yù)約

4a1a如果回答“否”，用例將不進(jìn)行預(yù)約而終止

4a1b如果回答“是”，預(yù)約將被輸入，并附有一個(gè)警告標(biāo)志實(shí)例——活動(dòng)圖在用例模型中的作用活動(dòng)圖建模主事件流活動(dòng)圖建模擴(kuò)展事件流活動(dòng)圖劃分游泳道后的活動(dòng)圖活動(dòng)圖步驟五：書(shū)寫(xiě)用例文檔對(duì)于書(shū)店借書(shū)系統(tǒng)的每個(gè)基本用例都需要書(shū)寫(xiě)用例文檔，這里僅以“借還書(shū)”用例為例，以作參考。

任務(wù)實(shí)施拓展訓(xùn)練一：設(shè)計(jì)“自動(dòng)售貨機(jī)”的活動(dòng)圖拓展訓(xùn)練二：設(shè)計(jì)“約談客戶”用例的活動(dòng)圖拓展訓(xùn)練三：建?！叭】睢庇美幕顒?dòng)圖拓展訓(xùn)練四：書(shū)寫(xiě)“書(shū)店借書(shū)系統(tǒng)”的用例文檔拓展訓(xùn)練五：建?！皶?shū)店借書(shū)系統(tǒng)”中“借還書(shū)”用例的活動(dòng)圖

拓展訓(xùn)練任務(wù)三重構(gòu)系統(tǒng)的功能需求模型03

任務(wù)陳述在上一個(gè)任務(wù)環(huán)節(jié)中，我們通過(guò)用例文檔和活動(dòng)圖詳細(xì)描述書(shū)店借書(shū)系統(tǒng)每個(gè)用例以及參與者和用例之間的交互關(guān)系。在整個(gè)用例模型的建立過(guò)程中，開(kāi)發(fā)者和客戶可以達(dá)成對(duì)系統(tǒng)的初步共識(shí)。但用例建模的過(guò)程本身就是一個(gè)反復(fù)迭代和逐步精化的過(guò)程，所以在進(jìn)一步的開(kāi)發(fā)中，還必須對(duì)用例進(jìn)行評(píng)估、對(duì)用例模型進(jìn)行不斷的修改與完善。在本任務(wù)環(huán)節(jié)中，請(qǐng)根據(jù)之前書(shū)寫(xiě)的書(shū)店借書(shū)系統(tǒng)的用例文檔和活動(dòng)圖重構(gòu)系統(tǒng)用例模型，精化完善用例模型。

知識(shí)準(zhǔn)備2.6重構(gòu)系統(tǒng)的用例模型2.6.1重構(gòu)系統(tǒng)用例模型的方法一般從以下幾個(gè)方面來(lái)判斷、評(píng)估用例的合理性：

如果你對(duì)以下問(wèn)題都回答“是”的話，那么這個(gè)用例就是合理的；否則，這個(gè)用例需要拆分為幾個(gè)小的用例。這個(gè)用例是否能夠帶來(lái)一個(gè)獨(dú)立的好處？是否可以用簡(jiǎn)潔的文字來(lái)描述這個(gè)好處？參與者是否能夠僅通過(guò)一次會(huì)話就完成這個(gè)用例？能否想象在一個(gè)連貫的測(cè)試計(jì)劃中，這個(gè)用例將是一個(gè)測(cè)試用例？重構(gòu)系統(tǒng)用例模型的方法如果你對(duì)以下問(wèn)題都回答“是”的話，那么這個(gè)用例就是有效的和獨(dú)立的；否則，這個(gè)用例實(shí)際上可能是其他用例的一個(gè)部分。參與者是否得到了明確的信息或者以某種可度量的方式改變系統(tǒng)？執(zhí)行這個(gè)用例之后，參與者是否可以在確定的時(shí)間內(nèi)停止使用這個(gè)系統(tǒng)？重構(gòu)系統(tǒng)用例模型的方法最終“訂餐預(yù)約系統(tǒng)”的用例圖重構(gòu)系統(tǒng)用例模型的方法步驟六：通過(guò)關(guān)系整理用例

任務(wù)實(shí)施拓展訓(xùn)練：精化完善“書(shū)店借書(shū)系統(tǒng)”的用例文檔

精化完善“書(shū)店借書(shū)系統(tǒng)”中的“登錄”、“注冊(cè)會(huì)員”、“注銷(xiāo)會(huì)員”等幾個(gè)用例的用例文檔，以資練習(xí)。

拓展訓(xùn)練任務(wù)四用例模型的分層分包處理04

任務(wù)陳述Windows操作系統(tǒng)自帶的“畫(huà)圖”軟件是我們熟悉的一個(gè)應(yīng)用程序。它的參與者就是系統(tǒng)的“用戶”，但用例的識(shí)別卻沒(méi)有我們想象的那么簡(jiǎn)單，請(qǐng)根據(jù)用例圖的分包原則，利用用例圖的子圖表達(dá)“畫(huà)圖”軟件各個(gè)角度的細(xì)節(jié)，完成用例建模。

知識(shí)準(zhǔn)備2.7整理用例模型的層次2.7.1建立用例模型的步驟2.7.2用例模型的分包原則

整個(gè)用例模型的創(chuàng)建過(guò)程是一個(gè)迭代的過(guò)程，我們將用例模型的一般步驟總結(jié)如下：（1）確定系統(tǒng)邊界。（2）識(shí)別參與者。（3）識(shí)別用例。（4）區(qū)分用例的優(yōu)先次序。（5）書(shū)寫(xiě)用例文檔。（6）通過(guò)關(guān)系整理用例（確定泛化、包含、擴(kuò)展關(guān)系）。建立用例模型的步驟當(dāng)模型組件較多時(shí)，可以利用包進(jìn)行分組；也可以通過(guò)子圖表達(dá)各個(gè)角度的細(xì)節(jié)，將模型理出層次。其步驟為：頂層用例圖用零級(jí)用例表示。對(duì)零級(jí)用例進(jìn)行細(xì)化，該層為一級(jí)用例。對(duì)每個(gè)一級(jí)用例進(jìn)行細(xì)化，并以此往下類(lèi)推。用例模型的分包原則“畫(huà)圖”軟件整個(gè)用例建模的過(guò)程步驟一：確定系統(tǒng)邊界步驟二：識(shí)別參與者步驟三：識(shí)別用例步驟四：區(qū)分用例的優(yōu)先次序步驟五：書(shū)寫(xiě)用例文檔步驟六：通過(guò)關(guān)系整理用例。

任務(wù)實(shí)施拓展訓(xùn)練：閱讀文檔，利用分包原則重構(gòu)用例模型收銀用例的用例文檔（略）

拓展訓(xùn)練用例模型是分析功能需求的一個(gè)有力工具。它由用例圖和每個(gè)用例的文檔組成。用例圖可以可視化地表達(dá)出用例功能，使需求分析員與用戶之間的交流更加容易。在用例圖中，用例的表示符號(hào)是一個(gè)橢圓，參與者的圖符是一個(gè)直立人形，參與者與用例之間用關(guān)聯(lián)線連接，通常用例都位于表示系統(tǒng)邊界的矩形框之中。用例之間存在各種關(guān)系：包含關(guān)系用帶關(guān)鍵字<<include>>的帶箭頭的虛線表示；擴(kuò)展關(guān)系用帶關(guān)鍵字<<extend>>的虛線箭頭線表示；還有一種泛化關(guān)系，表示一個(gè)用例繼承了另一個(gè)用例的屬性和行為。分析過(guò)程開(kāi)始于和客戶交談，產(chǎn)生系統(tǒng)高層用例圖。用例圖在分析過(guò)程中起著很重要的作用，它能反映系統(tǒng)基本的功能需求。但要?jiǎng)?chuàng)建完整的用例模型，還要對(duì)每個(gè)高層用例進(jìn)行細(xì)化，建立用例文檔。對(duì)于復(fù)雜的系統(tǒng)可以先畫(huà)出表達(dá)系統(tǒng)整體功能的頂層用例模型，再畫(huà)出各個(gè)功能的用例模型子圖。用例模型是后期設(shè)計(jì)和開(kāi)發(fā)的基礎(chǔ)。

本章小結(jié)完成“學(xué)生成績(jī)管理系統(tǒng)”的用例模型在上個(gè)單元中，你已經(jīng)根據(jù)“學(xué)生成績(jī)管理系統(tǒng)”的需求得出初始用例模型，現(xiàn)在請(qǐng)進(jìn)一步分析該系統(tǒng)的功能，完成整個(gè)“學(xué)生成績(jī)管理系統(tǒng)”的用例模型。注意，現(xiàn)階段我們只需要分析系統(tǒng)最基礎(chǔ)最核心的功能即可。請(qǐng)注意保存原始資料和得到的模型，我們將在后繼任務(wù)中作進(jìn)一步的分析。

項(xiàng)目實(shí)訓(xùn)THANKYOU單元三

系統(tǒng)的靜態(tài)建模軟件工程與UML任務(wù)一：類(lèi)的設(shè)計(jì)任務(wù)二：表示類(lèi)之間的關(guān)系目錄CONTENTS任務(wù)三：表示對(duì)象間的關(guān)系任務(wù)四：表示模塊間的關(guān)系【知識(shí)目標(biāo)】掌握類(lèi)圖的標(biāo)記符組件，如何建模類(lèi)，如何建模類(lèi)圖理解如何表現(xiàn)類(lèi)的特性、職責(zé)和約束，類(lèi)之間的關(guān)系了解如何建模對(duì)象圖、包圖【能力目標(biāo)】能根據(jù)具體問(wèn)題，建模類(lèi)圖模型，表達(dá)類(lèi)的設(shè)計(jì)思想能根據(jù)具體問(wèn)題，建模對(duì)象模型，表達(dá)對(duì)象間的關(guān)系能根據(jù)具體問(wèn)題，建模包圖模型，表達(dá)模塊間的關(guān)系引例描述

在本單元的學(xué)習(xí)中主要完成四個(gè)任務(wù)，“任務(wù)一”主要是根據(jù)上個(gè)單元“書(shū)店借書(shū)系統(tǒng)”里分析出的用例模型來(lái)尋找“書(shū)店借書(shū)系統(tǒng)”里的實(shí)體對(duì)象，“任務(wù)二”主要是通過(guò)分析“飲料自動(dòng)售貨機(jī)系統(tǒng)”來(lái)建模系統(tǒng)類(lèi)圖，“任務(wù)三”是根據(jù)Flight類(lèi)和Plane類(lèi)的類(lèi)圖畫(huà)出其對(duì)象圖，任務(wù)四是根據(jù)描述畫(huà)出對(duì)應(yīng)包圖。本單元的各類(lèi)圖形主要用于系統(tǒng)的靜態(tài)建模。任務(wù)一

類(lèi)的設(shè)計(jì)（用模型進(jìn)行單個(gè)類(lèi)的設(shè)計(jì)）01

任務(wù)陳述在上一個(gè)任務(wù)環(huán)節(jié)中，我們通過(guò)用例圖、用例文檔及活動(dòng)圖詳細(xì)描述書(shū)店借書(shū)系統(tǒng)每個(gè)用例以及參與者和用例之間的交互關(guān)系。在整個(gè)用例模型的建立過(guò)程中，開(kāi)發(fā)者和客戶可以達(dá)成對(duì)系統(tǒng)的初步共識(shí)。在本任務(wù)環(huán)節(jié)中，請(qǐng)根據(jù)之前書(shū)寫(xiě)的書(shū)店借書(shū)系統(tǒng)的用例模型，尋找出書(shū)店借書(shū)系統(tǒng)的實(shí)體類(lèi)。

知識(shí)準(zhǔn)備靜態(tài)模型包括類(lèi)圖、對(duì)象圖、包圖、組件圖和部署圖。其中類(lèi)圖描述系統(tǒng)中類(lèi)的靜態(tài)結(jié)構(gòu)，它不僅定義系統(tǒng)中的類(lèi)，表示類(lèi)之間的關(guān)系（如關(guān)聯(lián)、依賴、聚集等），也表達(dá)類(lèi)的內(nèi)部結(jié)構(gòu)（即類(lèi)的屬性和操作）。類(lèi)圖描述的這種靜態(tài)關(guān)系涉及軟件系統(tǒng)開(kāi)發(fā)的整個(gè)生命周期。對(duì)象圖是類(lèi)圖的實(shí)例，符號(hào)與類(lèi)圖非常相似，可以認(rèn)為對(duì)象圖是類(lèi)圖在程序執(zhí)行的某個(gè)過(guò)程中一瞬間的快照。包圖由包或類(lèi)組成（有時(shí)也包括組件），表示包與包之間的關(guān)系。包圖可以用于描述系統(tǒng)的分層結(jié)構(gòu)。組件圖和部署圖涉及程序的物理實(shí)現(xiàn)。

知識(shí)準(zhǔn)備3.1類(lèi)的表示3.1.1類(lèi)圖概述3.1.2類(lèi)的基本組件類(lèi)圖是用來(lái)顯示系統(tǒng)中的類(lèi)、接口以及它們之間的靜態(tài)結(jié)構(gòu)和關(guān)系的一種靜態(tài)模型，它用于描述系統(tǒng)的結(jié)構(gòu)。類(lèi)圖的建模貫穿系統(tǒng)的分析和設(shè)計(jì)階段的始終，通常從商務(wù)伙伴能夠理解的用例開(kāi)始建模，最終往往成為只有開(kāi)發(fā)小組能夠完全理解的類(lèi)。建模類(lèi)圖也是一個(gè)反復(fù)迭代的過(guò)程。類(lèi)圖包含兩個(gè)元素：類(lèi)、關(guān)系。類(lèi)圖概述當(dāng)對(duì)系統(tǒng)的靜態(tài)模型建模時(shí)，通常以下面的3種方式之一使用類(lèi)圖：

對(duì)系統(tǒng)的靜態(tài)對(duì)象建模。如書(shū)店借書(shū)系統(tǒng)的Book類(lèi)、學(xué)生管理系統(tǒng)的Student類(lèi)等。對(duì)簡(jiǎn)單的協(xié)作建模。協(xié)作是一些共同行為的類(lèi)、接口和其他元素的群體。如數(shù)據(jù)庫(kù)連接類(lèi)、用戶驗(yàn)證類(lèi)、過(guò)濾字符串類(lèi)等。對(duì)邏輯數(shù)據(jù)庫(kù)模式建模。在很多領(lǐng)域中，都需要在關(guān)系數(shù)據(jù)庫(kù)或面向?qū)ο髷?shù)據(jù)庫(kù)中存儲(chǔ)永久信息，系統(tǒng)分析者可以用類(lèi)圖對(duì)這些需要永久化的實(shí)體建模。類(lèi)圖概述類(lèi)圖的基本組件類(lèi)類(lèi)圖的基本組件

類(lèi)命名時(shí)應(yīng)該遵守以下幾條準(zhǔn)則：使用標(biāo)準(zhǔn)術(shù)語(yǔ)。使用具有確切含義的名詞。必要時(shí)用名詞短語(yǔ)作名字。對(duì)于類(lèi)圖中的類(lèi)而言，它的類(lèi)名、屬性、操作也有一定的書(shū)寫(xiě)規(guī)范。類(lèi)名：正體字說(shuō)明類(lèi)是可被實(shí)例化的，斜體字說(shuō)明類(lèi)為抽象類(lèi)。屬性：按照“可見(jiàn)性屬性名[:類(lèi)型][=初始值]”的書(shū)寫(xiě)順序。操作：按照“可見(jiàn)性方法名稱([參數(shù)列表])[:返回類(lèi)型]”的書(shū)寫(xiě)順序。類(lèi)圖的基本組件類(lèi)的表示方法類(lèi)圖的基本組件隱藏屬性部分或操作部分，或者兩者都隱藏類(lèi)圖的基本組件通過(guò)在屬性名稱和數(shù)據(jù)類(lèi)型之后添加等號(hào)來(lái)為屬性指定默認(rèn)值

在UML中，可以通過(guò)[]符號(hào)表示類(lèi)的某些屬性的多重性

類(lèi)圖的基本組件類(lèi)圖中還可以指明另一種類(lèi)的信息。在操作部分下面的區(qū)域，可以用來(lái)說(shuō)明類(lèi)的職責(zé)，也就是類(lèi)的屬性和操作能完成什么任務(wù)

類(lèi)圖的基本組件使用一個(gè)用花括號(hào)括起來(lái)的自由文本，括號(hào)中的文本指定了該類(lèi)所要滿足的一個(gè)或多個(gè)約束

類(lèi)圖的基本組件使用注釋為類(lèi)的屬性或操作添加更詳細(xì)的說(shuō)明類(lèi)圖的基本組件UML中的類(lèi)可以作為面向?qū)ο笳Z(yǔ)言中的類(lèi)publicclassTaxCalculator{

privatelong

taxRate;

privateint

salary

;

publicTaxCalculator(longtaxRate){this.taxRate=taxRate;}

publiclongcountTax(){returntaxRate*salary;

}

publicintgetSalary(){returnsalary;

}

publicvoidsetSalary(intsalary)

{this.salary=salary;

}}類(lèi)圖的基本組件接口在UML中，接口是用一個(gè)帶有名稱的小圓圈表示的，并且通過(guò)一條實(shí)線與它的模型元素相連。當(dāng)一個(gè)接口是在某個(gè)特定的類(lèi)中實(shí)現(xiàn)時(shí)，使用該接口的類(lèi)通過(guò)一個(gè)依賴關(guān)系（一條帶箭頭的虛線）與該接口的小圓圈相連接。

類(lèi)圖的基本組件接口對(duì)應(yīng)的Java代碼映射

interfaceCallback{voidcallback(intparam);}classClientimplementsCallback{publicvoidcallback(intp){……}publicvoidnonIfaceMeth(){……}}classTestIface{publicstaticvoidmain(Stringargs[]){Callbackc=newClient();c.callback(42);}}類(lèi)圖的基本組件分析“書(shū)店借書(shū)系統(tǒng)”的實(shí)體對(duì)象

任務(wù)實(shí)施用例實(shí)體對(duì)象注銷(xiāo)會(huì)員會(huì)員查詢會(huì)員會(huì)員信息修改會(huì)員信息會(huì)員信息會(huì)員注銷(xiāo)會(huì)員登錄管理員帳戶信息借還書(shū)書(shū)、借書(shū)卡、借書(shū)信息補(bǔ)收押金借書(shū)信息即將超期提醒會(huì)員卡退還押金借書(shū)信息打印借書(shū)單借書(shū)信息借書(shū)單會(huì)員、會(huì)員信息是一個(gè)概念，統(tǒng)一為會(huì)員對(duì)象。會(huì)員卡和借書(shū)卡也為同一概念，統(tǒng)一為借書(shū)卡對(duì)象。初始實(shí)體類(lèi)如圖

任務(wù)實(shí)施拓展訓(xùn)練一：用圖表示“學(xué)生成績(jī)管理系統(tǒng)”中的學(xué)生、教師、成績(jī)類(lèi)拓展訓(xùn)練二：用圖表示電視機(jī)類(lèi)

拓展訓(xùn)練任務(wù)二表示類(lèi)之間的關(guān)系02

任務(wù)陳述

某“飲料自動(dòng)售貨機(jī)系統(tǒng)”具有“設(shè)置”、“銷(xiāo)售”、“取消”三個(gè)主要功能，請(qǐng)根據(jù)以下功能描述建模系統(tǒng)類(lèi)圖。設(shè)置。一個(gè)飲料自動(dòng)售貨機(jī)可以放置五種不同或部分相同的飲料，可由廠商根據(jù)銷(xiāo)售狀況自動(dòng)調(diào)配，并可隨時(shí)重新設(shè)置售價(jià)，但售貨機(jī)最多僅能放置50罐飲料，其按鈕設(shè)計(jì)在各種飲料樣本的下方，若經(jīng)金額計(jì)算器累計(jì)金額足夠，則選擇鍵燈會(huì)亮；若某一種飲料已銷(xiāo)售完畢，則售完燈會(huì)亮。銷(xiāo)售。顧客將硬幣投入售貨機(jī)，經(jīng)累加金額足額的飲料選擇鍵燈亮，等顧客按鍵選擇。顧客按鍵后飲料由取物簍掉出，并自動(dòng)結(jié)算及找錢(qián)。取消。顧客可在按下選擇鍵前任何一個(gè)時(shí)刻，拉動(dòng)退幣桿取消交易收回硬幣。

知識(shí)準(zhǔn)備3.2類(lèi)圖3.2.1類(lèi)關(guān)系的含義及表示方法3.2.2關(guān)聯(lián)關(guān)系的重?cái)?shù)與代碼的映射3.2.3如何建模類(lèi)圖關(guān)系泛化關(guān)系：一個(gè)類(lèi)（子類(lèi)）繼承另外的一個(gè)類(lèi)（超類(lèi)）的同一功能，并增加它自己的新功能。泛化關(guān)系就是用來(lái)表示類(lèi)與類(lèi)、接口與接口之間的繼承關(guān)系的。關(guān)系中的實(shí)線空心封閉箭頭由子類(lèi)指向父類(lèi)關(guān)系關(guān)系實(shí)現(xiàn)關(guān)系：實(shí)現(xiàn)關(guān)系指定兩個(gè)實(shí)體之間的一個(gè)合同。換言之，一個(gè)實(shí)體定義一個(gè)合同，而另一個(gè)實(shí)體保證履行該合同。關(guān)系中的箭頭由實(shí)現(xiàn)接口的類(lèi)指向被實(shí)現(xiàn)的接口。在Java中，實(shí)現(xiàn)關(guān)系可以直接用接口，implements關(guān)鍵字表示。在有些程序語(yǔ)言中不支持接口，但支持類(lèi)之間的多重繼承。在UML中，可以使用泛化關(guān)系表示。關(guān)系關(guān)系依賴關(guān)系：依賴是類(lèi)與類(lèi)之間的連接，并且依賴總是單向的。實(shí)體之間的“依賴”關(guān)系暗示一個(gè)實(shí)體的值發(fā)生變化后可能影響依賴于它的其他實(shí)例。在面向?qū)ο蟮南到y(tǒng)中，作為方法的一個(gè)部分，一個(gè)對(duì)象可能創(chuàng)建另一個(gè)對(duì)象，讓它執(zhí)行一定的功能。也可以一個(gè)對(duì)象還可能在一個(gè)方法中創(chuàng)建另一個(gè)對(duì)象，對(duì)它進(jìn)行配置，然后將它作為方法的返回值傳給方法的調(diào)用者。關(guān)系關(guān)系關(guān)聯(lián)關(guān)系：在對(duì)系統(tǒng)建模時(shí)，特定的對(duì)象間將會(huì)彼此關(guān)聯(lián)，我們稱這種關(guān)系為關(guān)聯(lián)關(guān)系，它反映了對(duì)象之間相互依賴、相互作用的關(guā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)自身關(guān)聯(lián)關(guān)聯(lián)類(lèi)

關(guān)系關(guān)聯(lián)關(guān)系雙向關(guān)聯(lián)關(guān)聯(lián)總是被假定是雙向的。這意味著，兩個(gè)類(lèi)彼此知道它們間的聯(lián)系。一個(gè)雙向關(guān)聯(lián)用兩個(gè)類(lèi)間的實(shí)線表示。在線的任一端，可以放置角色名和多重值

關(guān)系關(guān)聯(lián)關(guān)系單向關(guān)聯(lián)雖然兩個(gè)類(lèi)是相關(guān)的，但是只有一個(gè)類(lèi)知道這種聯(lián)系的存在。一個(gè)單向的關(guān)聯(lián)表示為一條帶有指向已知類(lèi)的開(kāi)放箭頭的實(shí)線。單向關(guān)聯(lián)只包含已知類(lèi)的角色名和多重值描述關(guān)系關(guān)聯(lián)關(guān)系聚集關(guān)聯(lián)聚集是關(guān)聯(lián)的一種形式，代表兩個(gè)類(lèi)之間的整體/局部關(guān)系。

關(guān)系關(guān)聯(lián)關(guān)系組成關(guān)聯(lián)組成關(guān)聯(lián)表明一個(gè)對(duì)象是被一個(gè)更大的整體所擁有。這個(gè)被包含的對(duì)象可能不能參與更多的組成關(guān)聯(lián)，并且不能獨(dú)立于這個(gè)整體而存在。在整體創(chuàng)建的時(shí)候創(chuàng)建這個(gè)部分，并在整體銷(xiāo)毀的時(shí)候銷(xiāo)毀。在UML中，組成的表示是在關(guān)聯(lián)線上靠近“整體”類(lèi)的一端加上一個(gè)實(shí)心的菱形。關(guān)系關(guān)聯(lián)關(guān)系自身關(guān)聯(lián)類(lèi)也可以使用自身關(guān)聯(lián)與它本身相關(guān)聯(lián)。當(dāng)一個(gè)類(lèi)關(guān)聯(lián)到它本身時(shí)，并不意味著類(lèi)的實(shí)例與它本身相關(guān)，而是類(lèi)的一個(gè)實(shí)例與類(lèi)的另一個(gè)實(shí)例相關(guān)。關(guān)系關(guān)聯(lián)關(guān)系關(guān)聯(lián)類(lèi)Person類(lèi)和Company類(lèi)之間關(guān)聯(lián)時(shí)產(chǎn)生了稱為Contract的關(guān)聯(lián)類(lèi)。這意味著當(dāng)Person類(lèi)的一個(gè)實(shí)例關(guān)聯(lián)到Company類(lèi)的一個(gè)實(shí)例時(shí)，將會(huì)產(chǎn)生Contract類(lèi)的一個(gè)實(shí)例。關(guān)系關(guān)聯(lián)關(guān)系的不同重?cái)?shù)與代碼的映射（1）單向關(guān)聯(lián)（0..1）（2）單向關(guān)聯(lián)（1..1）（3）單向關(guān)聯(lián)（1..*）（4）雙向關(guān)聯(lián)（1，0..1）

關(guān)聯(lián)關(guān)系的不同重?cái)?shù)與代碼的映射關(guān)聯(lián)關(guān)系的不同重?cái)?shù)與代碼的映射（1）單向關(guān)聯(lián)（0..1）publicclassAccount{ privateDebitCardtheCard; publicDebitCardgetCard(){returntheCard;} publicvoidsetCard(DebitCardcard){theCard=card;} publicvoidremoveCard(){theCard=null;}}

關(guān)聯(lián)關(guān)系的不同重?cái)?shù)與代碼的映射關(guān)聯(lián)關(guān)系的不同重?cái)?shù)與代碼的映射（2）單向關(guān)聯(lián)（1..1）publicclassAccount{ privateGuarantortheGuarantor; publicAccount(Guarantorg) { if(g==null){}; theGuarantor=g; }

publicGuarantorgetGuarantor(){returntheGuarantor;}}關(guān)聯(lián)關(guān)系的不同重?cái)?shù)與代碼的映射關(guān)聯(lián)關(guān)系的不同重?cái)?shù)與代碼的映射（3）單向關(guān)聯(lián)（1..*）publicclassManager{ privateVectortheAccounts; publicvoidaddAccount(Accountacc){theAccount.addElement(acc);} publicvoidremoveAccount(Accountacc){theAccount.removeElement(acc);}}關(guān)聯(lián)關(guān)系的不同重?cái)?shù)與代碼的映射關(guān)聯(lián)關(guān)系的不同重?cái)?shù)與代碼的映射（4）雙向關(guān)聯(lián)（1，0..1）publicclassAccount{ privateDebitCardtheCard; publicDebitCardgetCard(){returntheCard;} publicvoidaddCard(){theCard=newDebitCard(this);}}publicclassDebitCard{ privateAccounttheAccount; DebitCard(Accounta){theAccount=a;} publicAccountgetAccunt(){returntheAccount}}關(guān)聯(lián)關(guān)系的不同重?cái)?shù)與代碼的映射1．建立類(lèi)圖的一般步驟（1）研究分析問(wèn)題領(lǐng)域。（2）發(fā)現(xiàn)對(duì)象與類(lèi)，明確它們的含義和責(zé)任，確定屬性。（3）發(fā)現(xiàn)類(lèi)之間的關(guān)系。把類(lèi)之間的關(guān)系用關(guān)聯(lián)、泛化、聚集、組合、依賴等關(guān)系表達(dá)出來(lái)。（4）設(shè)計(jì)類(lèi)與關(guān)系。調(diào)整和細(xì)化已得到的類(lèi)和類(lèi)之間的關(guān)系，解決諸如命名沖突、功能重復(fù)等問(wèn)題。（5）繪制類(lèi)圖并編制相應(yīng)的說(shuō)明。

如何建模類(lèi)圖2.如何發(fā)現(xiàn)類(lèi)以及它們之間的關(guān)系對(duì)所獲得的信息，采用“名詞-動(dòng)詞”分析法非常有效。（1）找出以上來(lái)源中的名詞或名詞短語(yǔ)，作為候選類(lèi)（2）對(duì)候選類(lèi)進(jìn)行篩選，去掉冗余的、和系統(tǒng)無(wú)關(guān)的、以及非獨(dú)立的類(lèi)（3）以動(dòng)詞為線索確定類(lèi)之間的關(guān)系

如何建模類(lèi)圖步驟一：找出對(duì)象及其關(guān)聯(lián)步驟二：賦予類(lèi)及關(guān)聯(lián)的屬性數(shù)據(jù)步驟三：組織類(lèi)的結(jié)構(gòu)

任務(wù)實(shí)施拓展訓(xùn)練一：書(shū)寫(xiě)關(guān)聯(lián)關(guān)系的代碼映射拓展訓(xùn)練二：用類(lèi)圖描述郵件及其組件之間的關(guān)系拓展訓(xùn)練三：根據(jù)以下描述設(shè)計(jì)類(lèi)圖拓展訓(xùn)練四：根據(jù)下面的Java代碼畫(huà)出類(lèi)圖。拓展訓(xùn)練五：根據(jù)以下訂單業(yè)務(wù)流程畫(huà)出類(lèi)圖

拓展訓(xùn)練任務(wù)三表示對(duì)象間的關(guān)系03

任務(wù)陳述Flight類(lèi)和Plane類(lèi)之間是一個(gè)雙向關(guān)聯(lián)的類(lèi)圖，其類(lèi)模型如圖所示：請(qǐng)根據(jù)其類(lèi)圖模型，描述一架NX0337客機(jī)的兩次飛行情況，并用對(duì)象圖將其表述出來(lái)。

知識(shí)準(zhǔn)備3.3對(duì)象圖3.3.1對(duì)象圖的概念3.3.2對(duì)象圖和類(lèi)圖的區(qū)別3.3.3如何建模對(duì)象圖對(duì)象圖的概念對(duì)象圖描述的是參與交互的各個(gè)對(duì)象在交互過(guò)程中某一時(shí)刻的狀態(tài)。對(duì)象圖可以被看做是類(lèi)圖在某一時(shí)刻的實(shí)例。

對(duì)象圖的概念對(duì)象圖和類(lèi)圖的區(qū)別類(lèi)圖：類(lèi)具有3個(gè)分欄（類(lèi)名、屬性及操作）；在類(lèi)的類(lèi)名分欄中只有類(lèi)名；類(lèi)的屬性分欄定義了所有屬性的特征；類(lèi)中列出了操作；類(lèi)使用關(guān)聯(lián)連接，關(guān)聯(lián)使用名稱、角色、多重性以及約束等特征定義。對(duì)象圖：對(duì)象只有兩個(gè)分欄（名稱、屬性）；對(duì)象的名稱形式為“對(duì)象名:類(lèi)名”；匿名對(duì)象的名稱形式為“:類(lèi)名”；對(duì)象只定義了屬性的當(dāng)前值；對(duì)象圖中不包含操作；對(duì)象使用鏈連接，鏈擁有名稱、角色，但是沒(méi)有多重性。

對(duì)象圖和類(lèi)圖的區(qū)別對(duì)象圖建模步驟如下：識(shí)別將要使用的建模機(jī)制。識(shí)別參與協(xié)作的類(lèi)、接口和其他元素，同時(shí)識(shí)別這些事物之間的關(guān)系。考慮貫穿這個(gè)機(jī)制的腳本，凍結(jié)某一時(shí)刻的腳本，并匯報(bào)每個(gè)參與這個(gè)機(jī)制的對(duì)象。按照需要顯露出每個(gè)這樣的對(duì)象的狀態(tài)和屬性值，以便理解腳本。顯露出這些對(duì)象之間的鏈，以描述對(duì)象之間關(guān)聯(lián)的實(shí)例。如何建模對(duì)象圖建模對(duì)象圖主要有以下兩點(diǎn)作用：論證類(lèi)模型的設(shè)計(jì)：當(dāng)設(shè)計(jì)了類(lèi)模型時(shí)，你可以通過(guò)對(duì)象圖來(lái)模擬出一個(gè)運(yùn)行時(shí)的狀態(tài)，這樣就可以研究在運(yùn)行時(shí)設(shè)計(jì)的合理性。同時(shí)也可以作為開(kāi)發(fā)人員討論的一個(gè)基礎(chǔ)。分析和說(shuō)明源代碼：由于類(lèi)圖只是展示了程序的靜態(tài)類(lèi)結(jié)構(gòu)，因此通過(guò)類(lèi)圖看懂代碼的意圖是很困難的。因此在分析源代碼時(shí)，可以通過(guò)對(duì)象圖來(lái)細(xì)化分析。而對(duì)于開(kāi)發(fā)人員，對(duì)于邏輯較復(fù)雜的類(lèi)交互時(shí)，可以考慮畫(huà)出一些對(duì)象圖來(lái)做補(bǔ)充說(shuō)明。如何建模對(duì)象圖一架NX0337客機(jī)的兩次飛行情況如圖所示：

任務(wù)實(shí)施拓展訓(xùn)練：閱讀對(duì)象圖并說(shuō)明其含義且繪制出與其相應(yīng)的類(lèi)圖。

拓展訓(xùn)練任務(wù)四表示模塊間的關(guān)系04

任務(wù)陳述某系統(tǒng)工作流程如下：

1）通過(guò)Internet連接到股票信息服務(wù)器，獲取實(shí)時(shí)的股票信息，并存入數(shù)據(jù)庫(kù)中。2）根據(jù)用戶的輸入和選擇，從數(shù)據(jù)庫(kù)中獲取相應(yīng)的信息，展現(xiàn)在屏幕中。3）在數(shù)據(jù)的展現(xiàn)過(guò)程中，將需要繪制大量的圖表。請(qǐng)根據(jù)描述對(duì)功能模塊進(jìn)行分包，并畫(huà)出其對(duì)應(yīng)的包圖。

知識(shí)準(zhǔn)備3.4包圖3.4.1包圖的概念3.4.2包圖建模

包圖是維護(hù)和控制系統(tǒng)總體結(jié)構(gòu)的重要建模工具。當(dāng)對(duì)復(fù)雜系統(tǒng)進(jìn)行處理時(shí)，需要處理大量的接口、類(lèi)、節(jié)點(diǎn)等，這時(shí)有必要將這些元素進(jìn)行分組，即將語(yǔ)義相近的元素加入同一個(gè)包中，以方便理解和處理系統(tǒng)模型。包的作用是：1）對(duì)語(yǔ)義上相關(guān)的元素進(jìn)行分組；2）定義模型中的“語(yǔ)義邊界”；3）提供配置管理單元；4）在設(shè)計(jì)時(shí)，提供并行工作的單元；5）提供封裝的命名空間，其中所有名稱必須惟一包圖的概念

在UML中，包的符號(hào)類(lèi)似于一個(gè)文件夾

包之間存在兩種關(guān)系：訪問(wèn)依賴（用于在一個(gè)包中引用另一個(gè)包輸出的元素）、泛化關(guān)系（用于說(shuō)明包的家族）。包圖的概念一般遵循以下原則：（1）一般將一個(gè)框架的所有類(lèi)放置在相同的包中；將相同繼承層次的類(lèi)放在相同的包中；彼此間有聚集或組成關(guān)系的類(lèi)通常放在相同的包中；彼此合作頻繁的類(lèi)、信息能夠通過(guò)UML順序圖和UML合作圖反映出來(lái)的類(lèi)，通常放在相同的包中。（2）確定包與包之間的依賴關(guān)系或泛化關(guān)系。包圖建模步驟一：根據(jù)功能模塊組織包步驟二：確定包與包之間的依賴關(guān)系

任務(wù)實(shí)施拓展訓(xùn)練：閱讀包圖并說(shuō)明其含義

拓展訓(xùn)練類(lèi)圖是用來(lái)顯示系統(tǒng)中的類(lèi)、接口以及它們之間的靜態(tài)結(jié)構(gòu)和關(guān)系的，是一種靜態(tài)模型類(lèi)型，用于描述系統(tǒng)的靜態(tài)結(jié)構(gòu)。一般來(lái)說(shuō)，類(lèi)圖包含兩個(gè)元素：類(lèi)、關(guān)系。類(lèi)是類(lèi)圖的主要組成部分，一般包含3個(gè)組成部分：類(lèi)名、屬性、操作。類(lèi)之間存在著多種關(guān)系，常見(jiàn)的關(guān)系有：依賴關(guān)系、實(shí)現(xiàn)關(guān)系、表示類(lèi)之間一般和特殊關(guān)系的泛化關(guān)系，以及表示對(duì)象之間結(jié)構(gòu)關(guān)系的關(guān)聯(lián)關(guān)系。常見(jiàn)的有6種關(guān)聯(lián)關(guān)系：雙向關(guān)聯(lián)、單向關(guān)聯(lián)、聚集關(guān)聯(lián)、組成關(guān)聯(lián)、自身關(guān)聯(lián)、關(guān)聯(lián)類(lèi)。創(chuàng)建類(lèi)圖需要反復(fù)進(jìn)行兩個(gè)操作：確定類(lèi)及其關(guān)聯(lián)、確定屬性和操作。對(duì)象圖描述的是參與交互的各個(gè)對(duì)象在交互過(guò)程中某一時(shí)刻的狀態(tài)。對(duì)象圖可以被看做是類(lèi)圖在某一時(shí)刻的實(shí)例。包的設(shè)計(jì)使得你能夠把諸如用例或類(lèi)等模型組件分組。包設(shè)計(jì)的一般原則是把一個(gè)框架中的所有類(lèi)放置在相同的包中；一般把相同繼承層次的類(lèi)放在相同的包中；彼此間有聚集或組成關(guān)系的類(lèi)通常放在相同的包中；彼此合作頻繁的類(lèi)、信息能夠通過(guò)UML順序圖和UML合作圖反映出來(lái)的類(lèi)，通常放在相同的包中。

本章小結(jié)學(xué)生成績(jī)管理系統(tǒng)的初始類(lèi)圖在上個(gè)單元中，你已經(jīng)根據(jù)“學(xué)生成績(jī)管理系統(tǒng)”的需求得出“學(xué)生成績(jī)管理系統(tǒng)”的用例模型。在本單元中，請(qǐng)根據(jù)你所描述的用例模型畫(huà)出其初始類(lèi)圖。注意，現(xiàn)階段我們只需要分析系統(tǒng)最基礎(chǔ)最核心的功能即可。請(qǐng)注意保存原始資料和得到的模型，我們將在后繼任務(wù)中作進(jìn)一步的分析。

項(xiàng)目實(shí)訓(xùn)THANKYOU單元四

系統(tǒng)的動(dòng)態(tài)建模軟件工程與UML任務(wù)一：建模對(duì)象間的交互過(guò)程任務(wù)二：建模對(duì)象間的交互及關(guān)聯(lián)關(guān)系目錄CONTENTS任務(wù)三：建模單個(gè)對(duì)象的狀態(tài)轉(zhuǎn)移過(guò)程【知識(shí)目標(biāo)】理解動(dòng)態(tài)建模在軟件開(kāi)發(fā)中的作用，動(dòng)態(tài)模型與靜態(tài)模型的關(guān)系掌握動(dòng)態(tài)建模的方法【能力目標(biāo)】能使用適當(dāng)?shù)膭?dòng)態(tài)模型，建模對(duì)象間的交互能準(zhǔn)確識(shí)別對(duì)象的不同狀態(tài)，建模對(duì)象的狀態(tài)轉(zhuǎn)移過(guò)程引例描述

在初步完成了“書(shū)店借書(shū)系統(tǒng)”的靜態(tài)建模以后，我們需要了解系統(tǒng)的執(zhí)行過(guò)程。例如，某個(gè)功能的具體流程；完成某個(gè)特定功能時(shí)，對(duì)象間的交互過(guò)程；某些特定對(duì)象的狀態(tài)轉(zhuǎn)移過(guò)程等。

在“書(shū)店借書(shū)系統(tǒng)”，我們最為關(guān)心的是“借還書(shū)”流程，“借還書(shū)”過(guò)程中對(duì)象間的交互；“書(shū)”對(duì)象的狀態(tài)描述等。任務(wù)一

建模對(duì)象間的交互過(guò)程01

任務(wù)陳述根據(jù)“書(shū)店借書(shū)系統(tǒng)”的“借還書(shū)”用例文檔中的事件路徑，建?！敖柽€書(shū)”流程的活動(dòng)圖；針對(duì)“系統(tǒng)分析階段”的類(lèi)圖，建模“借還書(shū)”的交互過(guò)程；針對(duì)“系統(tǒng)設(shè)計(jì)”階段的類(lèi)圖，建?！敖柽€書(shū)”的交互過(guò)程。

知識(shí)準(zhǔn)備UML的動(dòng)態(tài)模型包括活動(dòng)圖、順序圖、協(xié)作圖和狀態(tài)圖四種。順序圖和協(xié)作圖用于建模系統(tǒng)的交互過(guò)程，其中，順序圖著重體現(xiàn)對(duì)象間消息傳遞的時(shí)間順序，協(xié)作圖著重體現(xiàn)對(duì)象間的靜態(tài)關(guān)聯(lián)關(guān)系；狀態(tài)圖用于建模某一特定對(duì)象所有可能的狀態(tài)及狀態(tài)間的轉(zhuǎn)移，是對(duì)類(lèi)圖的補(bǔ)充；活動(dòng)圖主要用于描述用例內(nèi)部的工作流程。

知識(shí)準(zhǔn)備4.1順序圖4.1.1定義順序圖4.1.2關(guān)于消息4.1.3對(duì)象的創(chuàng)建和銷(xiāo)毀4.1.4順序圖的主要用途軟件系統(tǒng)中的任務(wù)是通過(guò)對(duì)象之間的合作來(lái)完成的，這種合作稱為交互。交互模型可以用來(lái)描述軟件系統(tǒng)中的類(lèi)、接口、組件、節(jié)點(diǎn)的實(shí)例的動(dòng)態(tài)行為。交互模型包括順序圖和協(xié)作圖。順序圖用來(lái)建模對(duì)象間的交互，強(qiáng)調(diào)按時(shí)間順序展開(kāi)的信息的傳遞。它與活動(dòng)圖的相似之處是可以表示流程，但順序圖能進(jìn)一步地將活動(dòng)分配給對(duì)象。一個(gè)順序圖只顯示一個(gè)控制流。定義順序圖ATM機(jī)“登錄成功”的順序圖定義順序圖1．消息的類(lèi)型（1）同步消息（Synchronous）：表示該消息完成之前，同一個(gè)對(duì)象不能再發(fā)送下一條消息。（2）返回消息（Return）：表示控制流返回到調(diào)用的活動(dòng)對(duì)象。（3）異步消息（Asychronous）：表示不必等待來(lái)自該消息的響應(yīng)，同一個(gè)對(duì)象即可發(fā)出下一條消息。（4）簡(jiǎn)單消息（Flat）：表示不區(qū)分同步或異步。關(guān)于消息2．消息的傳入和傳出 消息傳入某個(gè)對(duì)象，表示該對(duì)象是消息的承擔(dān)者；消息由某個(gè)對(duì)象傳出，表示該對(duì)象是消息的發(fā)起者、調(diào)用者關(guān)于消息消息的傳入和傳出關(guān)于消息消息的傳入和傳出關(guān)于消息有4條消息傳入“訂單”對(duì)象，說(shuō)明“訂單”類(lèi)有以下方法：訂單.結(jié)賬()訂單.合計(jì)總價(jià)錢(qián)()訂單.付款()訂單.校驗(yàn)信用卡()在“訂單”對(duì)象執(zhí)行“結(jié)賬”方法的過(guò)程中傳出了5條消息，說(shuō)明這個(gè)方法體中作了5處方法調(diào)用：訂單.結(jié)賬(){

…

訂單項(xiàng).計(jì)算價(jià)錢(qián)();

訂單項(xiàng).計(jì)算稅金();

訂單項(xiàng).尋找最近的供應(yīng)商();

訂單項(xiàng).計(jì)算稅金();

… (訂單).合計(jì)總價(jià)錢(qián)();

}將create消息發(fā)送給對(duì)象實(shí)例，從而即時(shí)創(chuàng)建對(duì)象，對(duì)象創(chuàng)建之后才具有生命線。destroys消息用于銷(xiāo)毀對(duì)象，給需要銷(xiāo)毀的對(duì)象發(fā)送這個(gè)消息，同時(shí)在該對(duì)象的生命線上放一個(gè)“×”符號(hào)，表示對(duì)象的生命終止。對(duì)象的創(chuàng)建和銷(xiāo)毀教師試圖修改學(xué)生的成績(jī)，但該學(xué)生的成績(jī)信息在系統(tǒng)中不存在對(duì)象的創(chuàng)建和銷(xiāo)毀順序圖的主要用途之一是表示用例中的行為順序在系統(tǒng)開(kāi)發(fā)的早期階段，順序圖可以應(yīng)用在高層場(chǎng)景的表達(dá)上；后續(xù)階段，則可以確切地表示對(duì)象間的消息傳遞過(guò)程。順序圖的主要用途“書(shū)店借書(shū)系統(tǒng)”需求分析階段的“借還書(shū)”流程

任務(wù)實(shí)施“書(shū)店借書(shū)系統(tǒng)”系統(tǒng)分析階段的“借還書(shū)”過(guò)程

任務(wù)實(shí)施拓展訓(xùn)練一

“網(wǎng)上報(bào)銷(xiāo)系統(tǒng)”“報(bào)銷(xiāo)成功”的順序圖拓展訓(xùn)練二：建模某用戶在ATM機(jī)上成功取款的的順序圖

拓展訓(xùn)練任務(wù)二

建模對(duì)象間的交互及關(guān)聯(lián)關(guān)系02

任務(wù)陳述上一節(jié)中，我們對(duì)“書(shū)店借書(shū)系統(tǒng)”建模了“借還書(shū)”的交互過(guò)程，分析了這一過(guò)程中參與的對(duì)象，以前它們之間按照時(shí)間順序展開(kāi)的消息的傳遞。這里，我們想進(jìn)一步明確對(duì)象間的關(guān)聯(lián)關(guān)系，并將對(duì)象間的關(guān)聯(lián)映射到類(lèi)圖中，從而得到更完善的類(lèi)模型。

知識(shí)準(zhǔn)備4.2協(xié)作圖4.2.1定義協(xié)作圖4.2.2協(xié)作圖與順序圖的聯(lián)系和區(qū)別4.2.3協(xié)作圖、順序圖與代碼的映射協(xié)作圖可以看做是對(duì)象圖和順序圖的結(jié)合，它能表達(dá)對(duì)象間的交互過(guò)程及對(duì)象間的關(guān)聯(lián)關(guān)系教師修改學(xué)生成績(jī)的協(xié)作圖定義協(xié)作圖協(xié)作圖和順序圖是一對(duì)孿生兄弟，它們都能表示對(duì)象間的交互過(guò)程。但是它們的側(cè)重點(diǎn)不同順序圖清楚地表示了交互作用中的時(shí)間順序，但沒(méi)有明確表示對(duì)象間的關(guān)系協(xié)作圖清楚地表示了對(duì)象間的關(guān)聯(lián)關(guān)系，但時(shí)間順序必須從順序號(hào)獲得協(xié)作圖與順序圖的聯(lián)系和區(qū)別建模系統(tǒng)的交互過(guò)程時(shí)，往往需要首先設(shè)計(jì)類(lèi)，然后在具體的交互過(guò)程中，各個(gè)對(duì)象的職責(zé)得到進(jìn)一步的明確。這個(gè)過(guò)程表現(xiàn)為類(lèi)圖和順序圖或協(xié)作圖的反復(fù)迭代：首先完成的類(lèi)圖的結(jié)構(gòu)性設(shè)計(jì)；然后針對(duì)具體的各個(gè)流程，進(jìn)行交互圖的建模，將交互過(guò)程中的各個(gè)行為分配到具體的對(duì)象；最后，這些對(duì)象的職責(zé)映射到類(lèi)中，從而類(lèi)圖得到完善。協(xié)作圖、順序圖與代碼的映射以某訂購(gòu)系統(tǒng)為例，現(xiàn)已有4個(gè)類(lèi)：客戶、訂單、訂單行、零件目錄，分別畫(huà)出下列工作流的順序圖。

（1）創(chuàng)建訂單行?？蛻魧?duì)象向訂單發(fā)送一個(gè)消息說(shuō)明要訂購(gòu)的零件和數(shù)量，創(chuàng)建一個(gè)新的訂單行對(duì)象，訂單行對(duì)象向零件目錄對(duì)象獲得零件價(jià)格。

（2）刪除訂單行?？蛻魧?duì)象向訂單發(fā)送一個(gè)消息說(shuō)明要?jiǎng)h除的訂單行對(duì)象，訂單行對(duì)象被刪除。協(xié)作圖、順序圖與代碼的映射協(xié)作圖、順序圖與代碼的映射分析得到系統(tǒng)的類(lèi)模型，如圖某訂購(gòu)系統(tǒng)的分析類(lèi)圖協(xié)作圖、順序圖與代碼的映射根據(jù)上面那個(gè)類(lèi)圖，進(jìn)行創(chuàng)建訂單行和刪除訂單行的動(dòng)態(tài)建模，如圖。創(chuàng)建訂單行的順序圖（分析模型）協(xié)作圖、順序圖與代碼的映射刪除訂單行的順序圖（分析模型）協(xié)作圖、順序圖與代碼的映射根據(jù)分析，得到相應(yīng)的設(shè)計(jì)類(lèi)。如圖所示。某訂購(gòu)系統(tǒng)的設(shè)計(jì)類(lèi)圖協(xié)作圖、順序圖與代碼的映射根據(jù)設(shè)計(jì)類(lèi)圖，進(jìn)行創(chuàng)建訂單行和刪除訂單行的動(dòng)態(tài)建模。進(jìn)而得到完善的設(shè)計(jì)類(lèi)圖。創(chuàng)建訂單行的順序圖（設(shè)計(jì)模型）協(xié)作圖、順序圖與代碼的映射根據(jù)設(shè)計(jì)類(lèi)圖，進(jìn)行創(chuàng)建訂單行和刪除訂單行的動(dòng)態(tài)建模。進(jìn)而得到完善的設(shè)計(jì)類(lèi)圖。刪除訂單行的順序圖（設(shè)計(jì)模型）完善后的設(shè)計(jì)類(lèi)圖建模對(duì)象間的交互及關(guān)聯(lián)關(guān)系

任務(wù)實(shí)施“借還書(shū)成功”的過(guò)程中各個(gè)業(yè)務(wù)對(duì)象間的交互用協(xié)作圖如圖所示邏輯設(shè)計(jì)階段“借還書(shū)成功”的協(xié)作圖建模對(duì)象間的交互及關(guān)聯(lián)關(guān)系

任務(wù)實(shí)施邏輯設(shè)計(jì)階段“借還書(shū)成功”的類(lèi)圖完善后的類(lèi)模型如圖所示拓展訓(xùn)練一：銀行“轉(zhuǎn)賬”過(guò)程的建模拓展訓(xùn)練二：某訂購(gòu)系統(tǒng)的交互過(guò)程建模

拓展訓(xùn)練任務(wù)三建模單個(gè)對(duì)象的狀態(tài)轉(zhuǎn)移過(guò)程03

任務(wù)陳述在“圖書(shū)館管理系統(tǒng)”中，不光需要保存同樣一種書(shū)的共同信息（書(shū)名、ISBN號(hào)等），還需要區(qū)別每一本不同的書(shū)，因?yàn)檫@些相同的書(shū)通常會(huì)被不同的讀者借走。我們可以看到，圖書(shū)館的書(shū)通常都貼了專(zhuān)用的“條碼”，這就是圖書(shū)館每一本藏書(shū)的唯一標(biāo)識(shí)。因此，在“圖書(shū)館管理系統(tǒng)”需要有兩個(gè)類(lèi)來(lái)分別存儲(chǔ)上述信息。一般地，設(shè)計(jì)一個(gè)Book類(lèi)，對(duì)應(yīng)每一本具體的書(shū)；設(shè)計(jì)一個(gè)BookInfo類(lèi)，對(duì)應(yīng)每一個(gè)ISBN號(hào)（即存儲(chǔ)相同書(shū)的共同信息）。在處理借書(shū)和還書(shū)的過(guò)程中，對(duì)BookInfo類(lèi)通常都是只讀的，但需要修改Book類(lèi)的狀態(tài)信息，以標(biāo)識(shí)出當(dāng)前書(shū)是處于外借還是在架狀態(tài)。這樣做的好處，一方面可以方便系統(tǒng)進(jìn)行統(tǒng)計(jì)、查詢、預(yù)定等處理；另一方面可以根據(jù)書(shū)當(dāng)前的狀態(tài)，確定對(duì)它允許進(jìn)行哪些操作。試對(duì)“圖書(shū)館管理系統(tǒng)”中的“Book”對(duì)象進(jìn)行建模，描述其所有可能的狀態(tài)以及狀態(tài)間的轉(zhuǎn)移過(guò)程。

知識(shí)準(zhǔn)備4.3狀態(tài)圖4.3.1定義狀態(tài)圖4.3.2狀態(tài)圖的建模過(guò)程4.3.3狀態(tài)圖與代碼的映射4.3.4狀態(tài)圖實(shí)例當(dāng)前處于Locked狀態(tài)，若發(fā)生coin事件，則變遷到Unlocked狀態(tài)，調(diào)用Unlock方法。當(dāng)前處于Unlocked狀態(tài)，若發(fā)生pass事件，則變遷到Locked狀態(tài)，調(diào)用Lock方法。當(dāng)前處于Unlocked狀態(tài)，若發(fā)生coin事件，則變遷到Unlocked狀態(tài)，調(diào)用Thankyou方法。當(dāng)前處于Locked狀態(tài)，若發(fā)生pass事件，則繼續(xù)停留在Locked狀態(tài)，調(diào)用Alarm方法。地鐵十字轉(zhuǎn)門(mén)的狀態(tài)圖定義狀態(tài)圖狀態(tài)圖的基本符號(hào)定義狀態(tài)圖狀態(tài)圖的建模過(guò)程

狀態(tài)圖通常作為對(duì)類(lèi)圖的補(bǔ)充，完善類(lèi)中依賴于狀態(tài)的各種行為。然而，在使用上并不需要為所有的類(lèi)畫(huà)狀態(tài)圖，而僅需要針對(duì)那些有多個(gè)狀態(tài)，及行為會(huì)受狀態(tài)取值影響而發(fā)生改變的類(lèi)畫(huà)狀態(tài)圖。

狀態(tài)圖中需要著重表示以下信息：（1）對(duì)象當(dāng)前的狀態(tài)；（2）發(fā)生了某種事件才會(huì)引起狀態(tài)間的轉(zhuǎn)移；（3）由一個(gè)狀態(tài)轉(zhuǎn)到另一個(gè)狀態(tài)的實(shí)現(xiàn)過(guò)程（通常通過(guò)方法調(diào)用實(shí)現(xiàn)）。狀態(tài)圖的建模過(guò)程狀態(tài)圖的建模過(guò)程通常如下：（1）識(shí)別出對(duì)象所有可能的狀態(tài)；（2）識(shí)別引起對(duì)象轉(zhuǎn)移的所有觸發(fā)因素（事件或條件）；（3）表示狀態(tài)轉(zhuǎn)移的實(shí)現(xiàn)過(guò)程（方法或行為）；（4）完善類(lèi)模型。在完成了上述步驟以后，還需要把狀態(tài)圖映射到類(lèi)，從而完善類(lèi)中相關(guān)的屬性和操作。另外，在建模狀態(tài)圖的過(guò)程中可以進(jìn)行必要的分組，即將具有共性的簡(jiǎn)單狀態(tài)置于合成狀態(tài)中，讓他們成為子狀態(tài)，從而對(duì)狀態(tài)模型進(jìn)行簡(jiǎn)化。將不同狀態(tài)作為常數(shù)枚舉，把當(dāng)前狀態(tài)存儲(chǔ)在適當(dāng)?shù)臄?shù)據(jù)成員中。依賴于狀態(tài)的操作可以用開(kāi)關(guān)語(yǔ)句對(duì)每個(gè)狀態(tài)分別設(shè)一個(gè)case實(shí)現(xiàn)。每個(gè)case表示來(lái)自特定狀態(tài)，用相應(yīng)的消息表示轉(zhuǎn)換。需求用專(zhuān)門(mén)的數(shù)據(jù)成員存儲(chǔ)對(duì)象的歷史狀態(tài)。狀態(tài)圖映射成代碼

示例：一觸摸式臺(tái)燈，對(duì)于“按下觸摸開(kāi)關(guān)”這一事件，會(huì)產(chǎn)生多種不同的效果，具體哪種效果取決于燈當(dāng)前的狀態(tài)。狀態(tài)圖映射成代碼

觸摸式臺(tái)燈觸摸式臺(tái)燈的狀態(tài)圖根據(jù)狀態(tài)模型，觸摸式臺(tái)燈的代碼如下：狀態(tài)圖映射成代碼

publicclassLamp{ privatefinalintShut=0; privatefinalintSoftLight=1; privatefinalintHardLight=2; intstate=Shut; ButtonlamButton; publicvoidinit() { add(lampButton); lampButton.addActionListener(this); }

publicvoidturnOnOff(ActionEvente) { switch(state){ caseShut: state=SoftLight; break; caseSoftLight: state=HardLight; break; caseHardLight: state=Shut; break; } }}銀行賬戶對(duì)象的狀態(tài)圖對(duì)應(yīng)的代碼參見(jiàn)教材狀態(tài)圖實(shí)例建?！皥D書(shū)館管理系統(tǒng)”中“Book”對(duì)象的狀態(tài)轉(zhuǎn)移過(guò)程（1）分析狀態(tài)轉(zhuǎn)移過(guò)程

“圖書(shū)館管理系統(tǒng)”中的“Book”對(duì)象有“外借”（Lending）和“在架”（OnShelf）兩個(gè)簡(jiǎn)單狀態(tài)；當(dāng)處于“在架”狀態(tài)時(shí)，如果發(fā)生borrow事件，將引起狀態(tài)轉(zhuǎn)移到“外借”；當(dāng)處于“外借”狀態(tài)時(shí)，如果發(fā)生return事件，將引起狀態(tài)轉(zhuǎn)移到“在架”；初始時(shí)，“Book”對(duì)象處于“在架”狀態(tài)；任何時(shí)候如果發(fā)生了destory事件，“Book”對(duì)象將轉(zhuǎn)移到destoryed狀態(tài)，此后再不會(huì)發(fā)生狀態(tài)轉(zhuǎn)移，因此該狀態(tài)為結(jié)束狀態(tài)。（2）狀態(tài)建模

任務(wù)實(shí)施拓展訓(xùn)練一：建立“用戶使用手機(jī)撥打電話”過(guò)程的狀態(tài)模型。拓展訓(xùn)練二：建立“某媒體播放器”的狀態(tài)模型。拓展訓(xùn)練三：建立“電梯”的狀態(tài)模型。

拓展訓(xùn)練統(tǒng)一建模語(yǔ)言UML由各種不同的、彼此關(guān)聯(lián)的圖組成，共同描述系統(tǒng)的靜態(tài)結(jié)構(gòu)和動(dòng)態(tài)行為。采用面向?qū)ο蟮倪M(jìn)行軟件開(kāi)發(fā)時(shí)，通常首先是描述需求；其次根據(jù)需求建立系統(tǒng)的靜態(tài)模型（用例圖），和表示系統(tǒng)工作流的動(dòng)態(tài)模型（活動(dòng)圖、順序圖等）；第三步是根據(jù)需求模型構(gòu)造系統(tǒng)結(jié)構(gòu)的靜態(tài)模型（類(lèi)圖、包圖、組件圖、部署圖等），并描述系統(tǒng)的行為（順序圖、協(xié)作圖、狀態(tài)圖等）。一個(gè)完整的模型必然描述系統(tǒng)的靜態(tài)和動(dòng)態(tài)兩個(gè)方面。靜態(tài)模型重在描繪系統(tǒng)的組成結(jié)構(gòu)，動(dòng)態(tài)模型描述系統(tǒng)的行為，即所建立的靜態(tài)模型是否能夠執(zhí)行以及執(zhí)行時(shí)的時(shí)序狀態(tài)、交互關(guān)系等。UML提供了四種動(dòng)態(tài)模型：交互圖（順序圖和協(xié)作圖）、狀態(tài)圖、活動(dòng)圖。其中，狀態(tài)圖用來(lái)描述某一特定對(duì)象所有可能的狀態(tài)及狀態(tài)間的轉(zhuǎn)移，是對(duì)類(lèi)圖的補(bǔ)充；順序圖用來(lái)描述對(duì)象間動(dòng)態(tài)交互關(guān)系，著重體現(xiàn)對(duì)象間消息傳遞的時(shí)間順序；協(xié)作圖用來(lái)描述相互協(xié)作的作對(duì)象的交互關(guān)系和關(guān)聯(lián)關(guān)系，著重體現(xiàn)對(duì)象間的靜態(tài)關(guān)聯(lián)關(guān)系；活動(dòng)圖主要用于描述用例內(nèi)部的工作流程。靜態(tài)建模和動(dòng)態(tài)建模是緊密聯(lián)系在一起的兩個(gè)建模過(guò)程，它們互相補(bǔ)充，相互利用，這種互補(bǔ)對(duì)保證系統(tǒng)完整性有著重要意義。

本章小結(jié)學(xué)生成績(jī)管理系統(tǒng)的動(dòng)態(tài)建模試對(duì)“學(xué)生成績(jī)管理系統(tǒng)”的主要用例進(jìn)行動(dòng)態(tài)建模。1.“登錄”用例（1）登錄成功的順序圖；（2）驗(yàn)證碼不正確，登錄失敗的順序圖；（3）密碼錯(cuò)誤，登錄失敗的順序圖；2.學(xué)生“查詢成績(jī)”用例（1）“學(xué)生成功查詢成績(jī)”的順序圖（2）“學(xué)生查詢成績(jī)，該成績(jī)還沒(méi)有打分”的順序圖3.教師“打分”用例（1）“教師成功打分并提交成績(jī)“的順序圖；（2）“教師選擇打分，該課程還沒(méi)有開(kāi)放打分權(quán)限”的順序圖；4.管理員“開(kāi)放打分權(quán)限”用例，“管理員成功開(kāi)放打分權(quán)限”的順序圖。5.繪制“教師權(quán)限”的狀態(tài)圖。6.將上述動(dòng)態(tài)建模映射到類(lèi)模型。

項(xiàng)目實(shí)訓(xùn)THANKYOU單元五系統(tǒng)的實(shí)現(xiàn)方式建模軟件工程與UML任務(wù)一：建模系統(tǒng)的軟件構(gòu)成任務(wù)二：建模系統(tǒng)的硬件部署目錄CONTENTS【知識(shí)目標(biāo)】了解為什么建模實(shí)現(xiàn)方式圖了解組件圖、部署圖的主要組件掌握如何建