上傳人：春***

認證信息

認證類型：個人認證

認證主體：凌**（實名認證）

IP屬地：廣東

IP屬地：廣東 上傳時間：2023-07-28 格式：PPT 頁數(shù)：103 大小：7.19MB 積分：30 舉報 版權(quán)申訴

軟件工程面向?qū)ο蠓治龅?頁，課件共103頁，創(chuàng)作于2023年2月《軟件工程》第6-10章面向?qū)ο蠓椒ǖ?頁，課件共103頁，創(chuàng)作于2023年2月可行性研究需求導(dǎo)出和分析軟件原型可行性報告系統(tǒng)模型系統(tǒng)描述和文檔編寫需求有效性驗證需求規(guī)格說明文檔相關(guān)概念回顧需求分析的核心：建模第3頁，課件共103頁，創(chuàng)作于2023年2月相關(guān)概念回顧建立軟件模型是分析活動的焦點。建立軟件模型是分析活動的關(guān)鍵。需求分析的核心在于建立分析模型。軟件工程中，軟件整個開發(fā)過程需要建模，軟件開發(fā)過程的各個階段也需要建模。不同的軟件開發(fā)方法，即軟件開發(fā)范型，最集中表現(xiàn)在它們模型的區(qū)別。所以，軟件開發(fā)過程的一系列模型的建立標(biāo)準(zhǔn)、描述形式、應(yīng)用規(guī)范等，是一種軟件開發(fā)方法（范型）最核心的研究內(nèi)容。第4頁，課件共103頁，創(chuàng)作于2023年2月相關(guān)概念回顧分析階段中常用的模型（邏輯模型）實體關(guān)系圖數(shù)據(jù)流圖、數(shù)據(jù)流定義、數(shù)據(jù)字典、結(jié)構(gòu)化英語、事件列表、狀態(tài)轉(zhuǎn)換圖、……用例圖、時序圖、協(xié)作圖、類圖、狀態(tài)圖、……Jackson實體結(jié)構(gòu)圖、SSD圖、Jackson進程模型、……層次方框圖、Warnier圖、IPO/HIPO、等第5頁，課件共103頁，創(chuàng)作于2023年2月相關(guān)概念回顧使用的方法不同，建立的模型也不相同。但是，一般必須建立以下幾類模型：數(shù)據(jù)模型、功能模型、行為模型靜態(tài)模型、動態(tài)模型所建立的模型必須是從抽象到精化的一個逐層分解在需求分析階段，創(chuàng)建的模型，要著重于描述系統(tǒng)要做什么，而不是如何去做（不應(yīng)涉及軟件實現(xiàn)細節(jié)）第6頁，課件共103頁，創(chuàng)作于2023年2月相關(guān)概念回顧DataModelBehavioralModelFunctionalModelAnalysismodelingandModel第7頁，課件共103頁，創(chuàng)作于2023年2月相關(guān)概念回顧常用的分析/建模方法面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法(SA)面向數(shù)據(jù)結(jié)構(gòu)的Jackson方法(JSD)面向數(shù)據(jù)結(jié)構(gòu)的結(jié)構(gòu)化數(shù)據(jù)系統(tǒng)開發(fā)方法(DSSD)面向?qū)ο蟮姆治龇椒?OOA)

建立動態(tài)模型的狀態(tài)遷移圖或Petri網(wǎng)等形式化方法面向構(gòu)件的其它E-R方法第8頁，課件共103頁，創(chuàng)作于2023年2月面向?qū)ο蠓椒ㄩ_發(fā)軟件通常建立的三種形式的模型

描述系統(tǒng)數(shù)據(jù)結(jié)構(gòu)的對象模型描述系統(tǒng)控制結(jié)構(gòu)的動態(tài)模型描述系統(tǒng)功能的功能模型

面向?qū)ο?的軟件開發(fā))方法第6-10章面向?qū)ο蠓椒ǖ?頁，課件共103頁，創(chuàng)作于2023年2月面向?qū)ο竽Ｐ蛯傩浴⒉僮?、協(xié)作者類／對象對象-關(guān)模型系模型對象-行為模型使用實例功能模型行為模型數(shù)據(jù)模型（靜態(tài)）（靜態(tài)）（動態(tài)）CRC索引卡片第10頁，課件共103頁，創(chuàng)作于2023年2月面向?qū)ο蠓椒ㄩ_發(fā)軟件通常建立的三種形式的模型

三種模型從三個不同但由密切相關(guān)的角度模擬目標(biāo)系統(tǒng)。 對象模型是最重要、最基本、最核心的。對模擬客觀世界實體的對象以及對象彼此之間的關(guān)系的映射，描述了系統(tǒng)的靜態(tài)結(jié)構(gòu)。面向?qū)ο?的軟件開發(fā))方法第6-10章面向?qū)ο蠓椒ǖ?1頁，課件共103頁，創(chuàng)作于2023年2月第六章面向?qū)ο蟮男枨蠓治雒嫦驅(qū)ο蟮男枨蠓治龇椒ǖ暮诵氖抢妹嫦驅(qū)ο蟮母拍詈头椒檐浖枨蠼ㄔ炷Ｐ?。它包含面向?qū)ο箫L(fēng)格的圖形語言機制以及用于指導(dǎo)需求分析的面向?qū)ο蠓椒▽W(xué)。面向?qū)ο蟮乃枷胱畛跗鹪从?960年代中期的仿真程序設(shè)計語言Simula67。1980年代初出現(xiàn)的Smalltalk語言及其程序設(shè)計環(huán)境對面向?qū)ο蠹夹g(shù)的推廣應(yīng)用起到了顯著的促進作用。第12頁，課件共103頁，創(chuàng)作于2023年2月第六章面向?qū)ο蟮男枨蠓治?990年代中后期誕生并迅速成熟的UML（統(tǒng)一建模語言，UnifiedModelingLanguage）是面向?qū)ο蠹夹g(shù)發(fā)展的一個重要里程碑。UML統(tǒng)一了面向?qū)ο蠼５幕靖拍?、術(shù)語和表示方法，不僅為面向?qū)ο蟮能浖_發(fā)過程提供了能力豐富的表達手段，而且也為軟件開發(fā)人員提供了互相交流、分享經(jīng)驗的共用語言。第13頁，課件共103頁，創(chuàng)作于2023年2月第六章面向?qū)ο蟮男枨蠓治鯫O方法。OMT/J、Rumbaugh；OOAD/PeterCoad&EdYourdon；OOSE/IvarJocobson（基于實例的）；VMT（VisualModelingTechnique）；UML（UnifiedModelingLanguage）/GradyBooch,JimRumbaugh,IvarJocobson(UML0.9,1996:9);OOTC(面向?qū)ο蠹夹g(shù)中心)/IBM，基于經(jīng)驗的OO。UML0.91,96.10,在使用中得到良好反映，于是倡議成立了UML協(xié)會。當(dāng)時的會員有DEC，HP，IBM，Microsoft，Oracle，RationalSoftware,TI,Unisys.1997.1發(fā)布了UML1.0，1997.11.17發(fā)布了UML1.1并被OMG接納為標(biāo)準(zhǔn)。據(jù)統(tǒng)計，在1996年底，UML已隱占OO技術(shù)市場的85%。第14頁，課件共103頁，創(chuàng)作于2023年2月面向?qū)ο蠓椒ㄩ_發(fā)軟件通常建立的三種形式的模型

描述系統(tǒng)數(shù)據(jù)結(jié)構(gòu)的對象模型描述系統(tǒng)控制結(jié)構(gòu)的動態(tài)模型描述系統(tǒng)功能的功能模型

第六章面向?qū)ο蟮男枨蠓治龅?-10章面向?qū)ο蠓椒ǖ?5頁，課件共103頁，創(chuàng)作于2023年2月第六章面向?qū)ο蟮男枨蠓治鰧傩?、操作、協(xié)作者類／對象對象-關(guān)模型系模型對象-行為模型使用實例功能模型行為模型數(shù)據(jù)模型（靜態(tài)）（靜態(tài)）（動態(tài)）CRC索引卡片第16頁，課件共103頁，創(chuàng)作于2023年2月面向?qū)ο蠓椒ㄩ_發(fā)軟件通常建立的三種形式的模型

三種模型從三個不同但由密切相關(guān)的角度模擬目標(biāo)系統(tǒng)。 對象模型是最重要、最基本、最核心的。對模擬客觀世界實體的對象以及對象彼此之間的關(guān)系的映射，描述了系統(tǒng)的靜態(tài)結(jié)構(gòu)。面向?qū)ο?的軟件開發(fā))方法第6-10章面向?qū)ο蠓椒ǖ?7頁，課件共103頁，創(chuàng)作于2023年2月第六章面向?qū)ο蟮男枨蠓治雒嫦驅(qū)ο蟮母拍钆c思想UML概述基于UML的需求分析以“家庭保安系統(tǒng)”等為實例，介紹與需求分析相關(guān)的部分UML語言機制以及基于UML的面向?qū)ο蟮男枨蠓治龇椒ê瓦^程。第18頁，課件共103頁，創(chuàng)作于2023年2月現(xiàn)實世界OOAOODOOPSASDSP機器世界結(jié)構(gòu)化生命周期方法面向?qū)ο蠓椒嫦驅(qū)ο蠓椒ê兔嫦蜻^程方法的對比6.1面向?qū)ο蟮母拍钆c思想第19頁，課件共103頁，創(chuàng)作于2023年2月6.1面向?qū)ο蟮母拍钆c思想從事物的過程側(cè)面來描述事物的方法被稱之為面向過程的方法。該方法在認識現(xiàn)實事物的整個過程中是把事物內(nèi)部的處理過程作為核心來描述的。從事物的組成部件及每個部件的屬性、功能來認識事物。比如，汽車由發(fā)動機，底盤，變速箱等組成，發(fā)動機有排量，有沖程數(shù)等屬性，同時發(fā)動機還具有啟動，加大油門等操作。這就是將現(xiàn)實世界的事物的屬性和及其過程一并進行描述的方法，這種方法被稱為面向?qū)ο蟮姆椒?。從事物的屬性?cè)面來描述事物的方法就是面向數(shù)據(jù)的方法，該方法在認識事物的過程中始終把事物的屬性作為描述的核心。第20頁，課件共103頁，創(chuàng)作于2023年2月小結(jié)：面向?qū)ο蟮男枨蠓治龇椒ㄍㄟ^提供對象、對象間消息傳遞等語言機制，讓分析人員在解空間中直接模擬問題空間中的對象，從而消減運用其他分析方法帶來的語義斷層，為需求建?；顒犹峁┲庇^、自然的語言支持和方法學(xué)指導(dǎo)。面向?qū)ο螅綄ο螅悾^承＋聚集＋消息。6.1面向?qū)ο蟮母拍钆c思想第21頁，課件共103頁，創(chuàng)作于2023年2月ElementsoftheOOmodel面向?qū)ο竽Ｐ偷?2頁，課件共103頁，創(chuàng)作于2023年2月面向?qū)ο竽Ｐ蛯傩浴⒉僮?、協(xié)作者類／對象對象-關(guān)模型系模型對象-行為模型使用實例功能模型行為模型數(shù)據(jù)模型（靜態(tài)）（靜態(tài)）（動態(tài)）CRC索引卡片第23頁，課件共103頁，創(chuàng)作于2023年2月6.2UML概述

6.2.1UML的語言機制

UML主要以Booch方法、OMT方法[71]和OOSE方法為基礎(chǔ)，同時也吸收了其他面向?qū)ο蠼７椒ǖ膬?yōu)點，形成了一種概念清晰、表達能力豐富、適用范圍廣泛的面向?qū)ο蟮臉?biāo)準(zhǔn)建模語言。第24頁，課件共103頁，創(chuàng)作于2023年2月UML通過圖形化的表示機制從多個側(cè)面對系統(tǒng)的分析和設(shè)計模型進行刻畫，共有5類10種視圖如下所示：靜態(tài)模型動態(tài)模型邏輯模型類圖用例圖

對象圖順序圖包圖協(xié)作圖狀態(tài)圖活動圖物理模型構(gòu)件圖

配置圖6.2UML概述6.2.1UML語言機制第25頁，課件共103頁，創(chuàng)作于2023年2月6.2.1UML語言機制1、用例圖（UsecaseDiagram）：用于表示系統(tǒng)的功能，并指出各功能的操作者；2、靜態(tài)圖：包括類圖（ClassDiagram）、對象圖（ObjectDiagram）及包圖（PackageDiagram），表示系統(tǒng)的靜態(tài)結(jié)構(gòu)；3、行為圖：包括狀態(tài)圖（StateDiagram）及活動圖（ActivityDiagram），用于描述系統(tǒng)的動態(tài)行為和對象之間的交互關(guān)系；4、交互圖：包括順序圖（SequenceDiagram）和協(xié)作圖（CollaborationDiagram），用于描述系統(tǒng)對象之間的動態(tài)合作關(guān)系；5、實現(xiàn)圖：包括構(gòu)件圖（CompomentDiagram）和配置圖（DeploymentDiagram），用于描述系統(tǒng)的物理實現(xiàn)。6.2UML概述第26頁，課件共103頁，創(chuàng)作于2023年2月6.2.1UML語言機制UML通過圖形化的表示機制從多個側(cè)面刻畫系統(tǒng)的分析和設(shè)計模型。

UML共定義十種視圖，可分四類：

(1)用例圖（usecasediagram）從外部用戶的角度描述系統(tǒng)的功能，并指出功能的執(zhí)行者。6.2UML概述第27頁，課件共103頁，創(chuàng)作于2023年2月例:課程注冊管理系統(tǒng)的用例圖教務(wù)管理人員使用“課表維護”用例，設(shè)置或修改課程屬性（課程的時間、地點、上課老師等），增刪課程；學(xué)生使用“個人課程規(guī)劃”用例選課、修改自己的個人課表，收費管理系統(tǒng)根據(jù)每個學(xué)生的選課情況計算其應(yīng)繳費用；老師使用“選課學(xué)生花名冊查詢”用例獲取選定其所開課程的學(xué)生花名冊。6.2UML概述第28頁，課件共103頁，創(chuàng)作于2023年2月6.2.1UML的語言機制(2)靜態(tài)圖類圖(classdiagram)、類圖描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，類圖的結(jié)點表示系統(tǒng)中的類及其屬性和操作，類圖的邊表示類之間的聯(lián)系，包括繼承、關(guān)聯(lián)、依賴、聚合等。對象圖(objectdiagram)對象圖是類圖的一個實例。它描述在某種狀態(tài)下，或者在某一時間段系統(tǒng)中活躍的對象及其關(guān)系。在對象圖中，一個類可以擁有多個活躍的對象實例。6.2UML概述第29頁，課件共103頁，創(chuàng)作于2023年2月課程注冊管理系統(tǒng)的類圖圖6.2表示課程注冊管理系統(tǒng)包括：“教務(wù)管理人員”、“學(xué)生”、“老師”、“課程”、“課程設(shè)置”、“課程注冊表”、“課程注冊管理器”、“課程管理器”八個類。前三個類為一般化的“用戶”類的子類。一門“課程”可由一到多個“課程設(shè)置”構(gòu)成，例如，對于全校性的公共基礎(chǔ)課，由于選修的學(xué)生太多，必須安排不同的老師、不同的教室或者不同的時間段?！皩W(xué)生”、“老師”與“課程設(shè)置”之間，“課程注冊表”與“課程注冊管理器”之間，以及“課程注冊管理器”與“課程”之間存在著關(guān)聯(lián)關(guān)系。6.2UML概述第30頁，課件共103頁，創(chuàng)作于2023年2月課程注冊管理系統(tǒng)的類圖6.2UML概述第31頁，課件共103頁，創(chuàng)作于2023年2月6.2.1UML的語言機制(2)靜態(tài)圖包圖(packagediagram)包圖描述系統(tǒng)的分解，表示包(package)以及包之間的關(guān)系。包由子包及類組成。包之間的關(guān)系包括繼承、構(gòu)成與依賴關(guān)系。6.2UML概述第32頁，課件共103頁，創(chuàng)作于2023年2月6.2.1UML的語言機制(3)行為圖交互圖(interactivediagram)

狀態(tài)圖(statechartdiagram)

活動圖(activitydiagram)它們從不同的側(cè)面刻畫系統(tǒng)的動態(tài)行為。交互圖描述對象之間的消息傳遞。它又可分為順序圖(sequencediagram)與(協(xié))合作圖(collaborationdiagram)兩種形式。順序圖強調(diào)對象之間消息發(fā)送的時間序。合作圖更強調(diào)對象間的動態(tài)協(xié)作關(guān)系。合作圖也可通過消息序號來表示消息傳遞的時間序，只不過這種表示不如順序圖那樣直觀。6.2UML概述第33頁，課件共103頁，創(chuàng)作于2023年2月用UML順序圖表示“個人課程”用例中學(xué)生選課過程6.2UML概述第34頁，課件共103頁，創(chuàng)作于2023年2月用UML協(xié)作圖表示“個人課程”用例中學(xué)生選課過程6.2UML概述第35頁，課件共103頁，創(chuàng)作于2023年2月6.2.1UML的語言機制狀態(tài)圖描述類的對象的動態(tài)行為。它包含對象所有可能的狀態(tài)?；顒訄D描述系統(tǒng)為完成某項功能而執(zhí)行的操作序列，這些在每個狀態(tài)下能夠響應(yīng)的事件以及事件發(fā)生時的狀態(tài)遷移與響應(yīng)動作。操作序列可以并發(fā)和同步?；顒訄D中包含控制流和信息流?？刂屏鞅硎疽粋€操作完成后對其后續(xù)操作的觸發(fā)，信息流則刻畫操作之間的信息交換。6.2UML概述第36頁，課件共103頁，創(chuàng)作于2023年2月UML狀態(tài)圖示例“課程設(shè)置”對象的狀態(tài)圖表示，每個“課程設(shè)置”最多只能容納50個選課學(xué)生。6.2UML概述第37頁，課件共103頁，創(chuàng)作于2023年2月6.2.1UML的語言機制(4)實現(xiàn)圖(implementationdiagram)描述軟件系統(tǒng)的實現(xiàn)。構(gòu)件圖(componentdiagram)描述軟件實現(xiàn)系統(tǒng)中各組成部件以及它們之間的依賴關(guān)系。一個部件可能是一個資源描述文件、一個二進制文件或一個可執(zhí)行文件。構(gòu)件圖用于理解和分析軟件各部分之間的相互影響程度。6.2UML概述第38頁，課件共103頁，創(chuàng)作于2023年2月6.2.1UML的語言機制部署圖(deploymentdiagram)描述軟件系統(tǒng)運行環(huán)境的硬件及網(wǎng)絡(luò)的物理體系結(jié)構(gòu)。結(jié)點表示實際的計算機和設(shè)備，邊表示結(jié)點之間的物理連接關(guān)系,也可顯示連接的類型及結(jié)點之間的依賴性。在結(jié)點內(nèi)部，可以放置可執(zhí)行部件和對象以顯示結(jié)點與可執(zhí)行軟件單元之間的對應(yīng)關(guān)系。部署圖對于軟件安裝工程師有重要的參考價值。6.2UML概述第39頁，課件共103頁，創(chuàng)作于2023年2月6.2.1UML的語言機制6.2UML概述第40頁，課件共103頁，創(chuàng)作于2023年2月6.2.1UML的語言機制UML的基本模型元素

6.2UML概述第41頁，課件共103頁，創(chuàng)作于2023年2月6.2.1UML的語言機制本章的后續(xù)章節(jié)將結(jié)合需求分析過程介紹UML的用例圖、包圖、類圖和活動圖第十章將結(jié)合軟件設(shè)計過程介紹順序圖、協(xié)作圖、狀態(tài)圖和活動圖。6.2UML概述第42頁，課件共103頁，創(chuàng)作于2023年2月6.2.2基于UML的軟件開發(fā)過程雖然UML是獨立于軟件開發(fā)過程的，即，UML能夠在幾乎任何一種軟件開發(fā)過程中使用，但是，熟悉一種有代表性的面向?qū)ο蟮能浖_發(fā)過程，并知悉UML各語言要素在過程中不同階段的應(yīng)用，對于理解UML將大有裨益。圖6.6表示了一種迭代的漸進式軟件開發(fā)過程，它包含四個階段：初啟，細化，構(gòu)造和移交。6.2UML概述第43頁，課件共103頁，創(chuàng)作于2023年2月

面向?qū)ο蟮牡u進式軟件開發(fā)過程6.2.2基于UML的軟件開發(fā)過程6.2UML概述第44頁，課件共103頁，創(chuàng)作于2023年2月6.2.2基于UML的軟件開發(fā)過程1、初啟：確定項目的主要目標(biāo)和范圍，并進行初步的可行性分析和經(jīng)濟效益分析。2、細化：細化階段的開始標(biāo)志著項目的正式確立。軟件項目在此階段需要完成以下工作：（1）初步的需求分析。采用UML的用例描述目標(biāo)軟件系統(tǒng)所有比較重要、比較有風(fēng)險的用例，利用用例圖表示參與者與用例、以及用例和用例之間的關(guān)系。采用UML的類圖表示目標(biāo)軟件系統(tǒng)所基于的應(yīng)用領(lǐng)域中的概念與概念之間的關(guān)系。這些相互關(guān)聯(lián)的概念構(gòu)成領(lǐng)域模型。（2）初步的高層設(shè)計。根據(jù)用例、類在業(yè)務(wù)領(lǐng)域中的關(guān)系，或者根據(jù)業(yè)務(wù)領(lǐng)域中某種有意義的分類方法將整個軟件系統(tǒng)劃分為若干個包，利用UML的包圖刻化這些包及其包間關(guān)系。6.2UML概述第45頁，課件共103頁，創(chuàng)作于2023年2月2、細化：

（3）部分的詳細設(shè)計。對于系統(tǒng)中某些重要的或者風(fēng)險比較高的用例，可以采用交互圖進一步探討其內(nèi)部實現(xiàn)過程。同樣，對于系統(tǒng)中的關(guān)鍵類，也可以詳細研究其屬性和操作，并在UML類圖中加以表現(xiàn)。(4)部分的原型構(gòu)造。綜上所述，在細化階段可能需要使用的UML語言機制包括：描述用戶需求的用例及用例圖、表示領(lǐng)域概念模型的類圖、表示業(yè)務(wù)流程處理的活動圖、表示系統(tǒng)高層結(jié)構(gòu)的包圖和表示用例內(nèi)部實現(xiàn)過程的交互圖等。細化階段的結(jié)束條件是，所有主要的用戶需求已通過用例和用例圖得以描述；所有重要的風(fēng)險已被標(biāo)識，并對風(fēng)險應(yīng)對措施了如指掌；能夠比較精確地估算實現(xiàn)每一用例的時間。6.2.2基于UML的軟件開發(fā)過程6.2UML概述第46頁，課件共103頁，創(chuàng)作于2023年2月3、構(gòu)造：在構(gòu)造階段，開發(fā)人員通過一系列的迭代完成對所有用例的軟件實現(xiàn)工作，在每次迭代中實現(xiàn)一部分用例。以迭代方式實現(xiàn)所有用例的好處在于，用戶可以及早參與對已實現(xiàn)用例的實際評價，并提出改進意見。這樣可有效降低大型軟件系統(tǒng)的開發(fā)風(fēng)險。在實際開始構(gòu)造軟件系統(tǒng)之前，有必要預(yù)先制定迭代計劃。計劃的制定應(yīng)遵循如下兩項原則：（1）用戶認為業(yè)務(wù)價值較大的用例應(yīng)優(yōu)先安排；（2）開發(fā)人員評估后認為開發(fā)風(fēng)險較高的用例應(yīng)優(yōu)先安排。6.2.2基于UML的軟件開發(fā)過程6.2UML概述第47頁，課件共103頁，創(chuàng)作于2023年2月在迭代計劃中，要確定迭代次數(shù)、每次迭代所需時間及每次迭代中應(yīng)完成（或部分完成）的用例。每次迭代過程由針對用例的分析、設(shè)計、編碼、測試和集成5個子階段構(gòu)成。在集成之后，用戶可以對用例的實現(xiàn)效果進行評價，并提出修改意見。這些修改意見可以在本次迭代過程中立即實現(xiàn)，也可以在下次迭代中再予以考慮。構(gòu)造過程中，需要使用UML的交互圖來設(shè)計用例的實現(xiàn)方法。為了與設(shè)計得出的交互圖協(xié)調(diào)一致，需要修改或精化在細化階段繪制的作為領(lǐng)域模型的類圖，增加一些為軟件實現(xiàn)所必需的類、類的屬性或方法。6.2.2基于UML的軟件開發(fā)過程6.2UML概述第48頁，課件共103頁，創(chuàng)作于2023年2月如果一個類有復(fù)雜的生命周期行為，或者類的對象在生命周期內(nèi)需要對各種外部事件的刺激作出反應(yīng)，應(yīng)考慮用UML的狀態(tài)圖來表述類的對象的行為。UML的活動圖可以在構(gòu)造階段用來表示復(fù)雜的算法過程和有多個對象參與的業(yè)務(wù)外理過程?；顒訄D尤其適用于表示過程中的并發(fā)和同步。在構(gòu)造階段的每次迭代過程中，可以對細化階段繪出的包圖進行修改或精化，以便包圖切實反映目標(biāo)軟件系統(tǒng)最頂層的結(jié)構(gòu)劃分狀況。6.2.2基于UML的軟件開發(fā)過程6.2UML概述第49頁，課件共103頁，創(chuàng)作于2023年2月6.2.2基于UML的軟件開發(fā)過程構(gòu)造階段可能使用的UML語言機制（1）用例及用例圖。它們是開發(fā)人員在構(gòu)造階段進行分析和設(shè)計的基礎(chǔ)。（2）類圖。在領(lǐng)域概念模型的基礎(chǔ)上引進為軟件實現(xiàn)所必需的類、屬性和方法。（3）交互圖：表示針對用例設(shè)計的軟件實現(xiàn)方法。（4）狀態(tài)圖：表示類的對象的狀態(tài)—事件—響應(yīng)行為。（5）活動圖：表示復(fù)雜的算法過程，尤其是過程中的并發(fā)和同步。（6）包圖：表示目標(biāo)軟件系統(tǒng)的頂層結(jié)構(gòu)。（7）構(gòu)件圖。（8）部署圖。6.2UML概述第50頁，課件共103頁，創(chuàng)作于2023年2月4、移交在移交階段，開發(fā)人員將構(gòu)造階段獲得的軟件系統(tǒng)在用戶實際工作環(huán)境（或接近實際的模擬環(huán)境）中試運行，根據(jù)用戶的修改意見進行少量修改。6.2.2基于UML的軟件開發(fā)過程6.2UML概述第51頁，課件共103頁，創(chuàng)作于2023年2月6.3基于UML的需求分析基于UML的需求分析步驟：（1）利用用例及用例圖表示需求。（2）利用包圖及類圖表示目標(biāo)軟件系統(tǒng)的總體框架結(jié)構(gòu)。第6章面向?qū)ο蟮男枨蠓治龅?2頁，課件共103頁，創(chuàng)作于2023年2月6.3基于UML的需求分析初步業(yè)務(wù)需求描述形成后，基于UML的需求分析分為以下步驟：（1）利用用例及用例圖表示需求：從業(yè)務(wù)需求描述出發(fā)獲取執(zhí)行者和場景；對場景進行匯總、分類、抽象，形成用例；確定執(zhí)行者與用例、用例與用例圖之間的關(guān)系，生成用例圖。（2）利用包圖及類圖表示目標(biāo)軟件系統(tǒng)的總體框架結(jié)構(gòu)：第53頁，課件共103頁，創(chuàng)作于2023年2月6.3基于UML的需求分析（1）利用用例及用例圖表示需求（2）利用包圖及類圖表示目標(biāo)軟件系統(tǒng)的總體框架結(jié)構(gòu)：根據(jù)領(lǐng)域知識、業(yè)務(wù)需求和工作經(jīng)驗，設(shè)計目標(biāo)軟件系統(tǒng)的頂層架構(gòu)；從業(yè)務(wù)需求描述中提取“關(guān)鍵概念”，形成領(lǐng)域概念模型；從概念模型和用例出發(fā)，研究系統(tǒng)中主要的類之間的關(guān)系，生成類圖。第54頁，課件共103頁，創(chuàng)作于2023年2月6.3基于UML的需求分析6.3基于UML的需求分析第55頁，課件共103頁，創(chuàng)作于2023年2月6.3基于UML的需求分析6.3.1開發(fā)場景

場景：是指從單個執(zhí)行者的角度觀察目標(biāo)軟件系統(tǒng)的功能和行為。這種功能通過系統(tǒng)與用戶之間的交互來表征。因此也可以說，場景是用戶與系統(tǒng)之間進行交互的一組具體的動作。場景是用例的實例，而用例是某類場景的共同抽象。場景描述：場景名稱、執(zhí)行者實例、前置條件、事件流和后置條件。第56頁，課件共103頁，創(chuàng)作于2023年2月6.3.1開發(fā)場景根據(jù)“家庭保安系統(tǒng)”的初步需求描述，具有那些場景？系統(tǒng)配置開機關(guān)機門窗監(jiān)測煙霧監(jiān)測復(fù)位6.3基于UML的需求分析第57頁，課件共103頁，創(chuàng)作于2023年2月6.3.1開發(fā)場景:監(jiān)測場景的描述場景名稱：門窗監(jiān)測。參與執(zhí)行者實例：警報器，報警電話，顯示器，門窗監(jiān)視器。前置條件：系統(tǒng)已開機。事件流：

（1）門窗監(jiān)視器發(fā)現(xiàn)門或窗戶發(fā)生異動，向軟件系統(tǒng)報告異常事件。（2）軟件系統(tǒng)啟動警報器并撥報警電話號碼。

（3）報警電話接通后，軟件系統(tǒng)播出語音，報告異常事件發(fā)生的時間、地點和事件的性質(zhì)（門窗異動）。

（4）系統(tǒng)在控制面板的顯示器上顯示報警時間及當(dāng)前狀態(tài)（報警：門窗異動）。后置條件：系統(tǒng)處于“報警”狀態(tài)。6.3基于UML的需求分析第58頁，課件共103頁，創(chuàng)作于2023年2月6.3.1開發(fā)場景:場景的分類(1)實際場景對實際的業(yè)務(wù)處理流程或其優(yōu)化流程的描述，是用戶需求的重要組成部分。(2)設(shè)想場景分析人員對目標(biāo)軟件系統(tǒng)投入應(yīng)用后經(jīng)改進或優(yōu)化的業(yè)務(wù)流程的描述。幫助分析人員挖掘潛在的用戶需求。(3)評價場景確認需求或提出改進建議為主要目的的業(yè)務(wù)流程描述。評價場景可以在用例生成后對用例進行實例化而形成，以便用戶對用例進行評價或改進。(4)培訓(xùn)場景面向開發(fā)人員及用戶解釋系統(tǒng)的功能和外部行為的業(yè)務(wù)流程描述。6.3基于UML的需求分析第59頁，課件共103頁，創(chuàng)作于2023年2月6.3.1開發(fā)場景:場景的獲取確定執(zhí)行者和場景關(guān)鍵在于理解業(yè)務(wù)領(lǐng)域和初步需求描述文檔。下列問題可幫助分析人員獲取場景：（1）目標(biāo)軟件系統(tǒng)有哪些執(zhí)行者？（2）執(zhí)行者希望系統(tǒng)執(zhí)行的任務(wù)有哪些？（3）執(zhí)行者希望獲得哪些信息？這些信息由誰生成？由誰修改？（4）執(zhí)行者需要通知系統(tǒng)哪些事件？系統(tǒng)響應(yīng)這些事件時會表現(xiàn)出哪些外部行為？（5）系統(tǒng)將通告執(zhí)行者哪些事件？場景將促成開發(fā)人員和用戶對于業(yè)務(wù)處理流程和目標(biāo)軟件系統(tǒng)的功能范圍的共同理解。場景確定之后，通過對場景的匯總、分類歸并、抽象即可形成用例。6.3基于UML的需求分析第60頁，課件共103頁，創(chuàng)作于2023年2月6.3.2生成用例執(zhí)行者：是指外部用戶或外部實體在系統(tǒng)中扮演的角色。用例：從外部用戶的視角看，一個用例是執(zhí)行者與目標(biāo)軟件系統(tǒng)之間的一次典型的交互作用。從軟件系統(tǒng)內(nèi)部的視角出發(fā)，一個用例代表系統(tǒng)執(zhí)行的一系列動作，動作執(zhí)行的結(jié)果能夠被外部的執(zhí)行者所觀察。用例描述：用例名稱、參與執(zhí)行者、前置條件、一個主事件流、零到多個輔助事件流和后置條件。6.3基于UML的需求分析第61頁，課件共103頁，創(chuàng)作于2023年2月6.3.2生成用例執(zhí)行者指外部用戶或外部實體在系統(tǒng)中扮演的角色。如果多個用戶在使用目標(biāo)軟件系統(tǒng)時扮演同一角色，這些用戶用單一執(zhí)行者表示。如果一個用戶扮演多種角色，則需要用多個執(zhí)行者來表示同一用戶。6.3基于UML的需求分析第62頁，課件共103頁，創(chuàng)作于2023年2月6.3.2生成用例對用例的完整描述包括用例名稱、參與執(zhí)行者、前置條件、一個主事件流、0到多個輔事件流、后置條件、獲利的執(zhí)行者。主事件流表示正常情況下執(zhí)行者與系統(tǒng)之間的信息交互及動作序列，輔事件流則表示特殊情況或異常情況下的信息交互及動作序列。顯式地分隔主、輔事件流是為了使分析人員首先聚焦于正常的業(yè)務(wù)處理流程，同時也便于用例的讀者理解業(yè)務(wù)需求。6.3基于UML的需求分析第63頁，課件共103頁，創(chuàng)作于2023年2月6.3.2生成用例用例源于分析人員對場景的分類和抽象，對相似場景進行歸并，使得一個用例可以通過實例化、參數(shù)調(diào)節(jié)而涵蓋多個場景?！凹彝ケ０蚕到y(tǒng)”中的“開機”、“關(guān)機”、“復(fù)位”三個場景可以歸并為“命令處理”用例，三個場景之間的差異通過用戶命令區(qū)分。門窗監(jiān)測、煙霧監(jiān)測兩個場景可歸并為統(tǒng)一的“傳感器監(jiān)測”用例。熟悉業(yè)務(wù)領(lǐng)域的分析師，可以略過場景，直接從業(yè)務(wù)需求描述中獲取用例。6.3基于UML的需求分析第64頁，課件共103頁，創(chuàng)作于2023年2月6.3.2生成用例在家庭保安系統(tǒng)中，執(zhí)行者有：“用戶”“傳感器”“警報器”“報警電話”“顯示器”用例有：“系統(tǒng)配置”“命令響應(yīng)”“傳感器監(jiān)測”6.3基于UML的需求分析第65頁，課件共103頁，創(chuàng)作于2023年2月“傳感器監(jiān)測”用例的描述用例名稱：傳感器監(jiān)測參與執(zhí)行者：各類傳感器，警報器，報警電話，顯示器前置條件：系統(tǒng)已開機。主事件流：

（1）傳感器向目標(biāo)軟件系統(tǒng)上報其監(jiān)測數(shù)據(jù)，系統(tǒng)判斷監(jiān)測數(shù)據(jù)正常。

（2）如果不正常，系統(tǒng)啟動警報器，撥報警電話號碼。

（3）報警電話接通后，軟件系統(tǒng)播出語音，報告異常事件發(fā)生的時間、地點和事件的性質(zhì)。

（4）系統(tǒng)在控制面板的顯示器上顯示報警時間及當(dāng)前狀態(tài)（報警）。6.3基于UML的需求分析第66頁，課件共103頁，創(chuàng)作于2023年2月“傳感器監(jiān)測”用例的描述輔事件流：

（1）如果報警電話無人接聽，則按照重撥延遲反復(fù)撥號，直至電話接通，再轉(zhuǎn)入主事件流的步驟（3）。

（2）如果重撥次數(shù)達到系統(tǒng)預(yù)設(shè)的最大次數(shù)，電話仍無人接聽，則跳過主事件流的步驟（3），轉(zhuǎn)入步驟（4）。后置條件：如果已發(fā)現(xiàn)異常的監(jiān)測數(shù)據(jù)，系統(tǒng)處于“報警”狀態(tài)；否則系統(tǒng)處于正常的“監(jiān)測”狀態(tài)。6.3基于UML的需求分析第67頁，課件共103頁，創(chuàng)作于2023年2月6.3.3用活動圖表示用例活動圖主要用于系統(tǒng)分析，它描述系統(tǒng)的行為，顯示系統(tǒng)中動作之間的轉(zhuǎn)移。活動圖一般從開始節(jié)點開始，經(jīng)過若干動作后，最后到達結(jié)束節(jié)點?；顒訄D是簡化的狀態(tài)圖，它重點說明了活動間所經(jīng)過的操作和過程?；顒訄D（Activity）只有一個動作（Action），活動的轉(zhuǎn)移有一個相應(yīng)的觸發(fā)事件?；顒訄D可用來描述用例、包和類的行為，它把活動描述成正在執(zhí)行的操作，活動代表了一個完整的動作，即它代表一個類或用例內(nèi)部的行為?；顒訄D不區(qū)分狀態(tài)、活動和事件，它是一個從活動到活動的簡單描述，其中，同步線用粗橫線表示，用于表示活動之間的同步。6.3基于UML的需求分析第68頁，課件共103頁，創(chuàng)作于2023年2月同步線6.3.3用活動圖表示用例考生考試的活動圖6.3基于UML的需求分析第69頁，課件共103頁，創(chuàng)作于2023年2月1UML活動圖用例的事件流或者操作均可表示為一系列的活動，每個活動在活動圖中被表示為一個結(jié)點。結(jié)點之間的有向邊表示順序執(zhí)行的活動。在結(jié)點間的連接邊上可以附加條件表達式，表示在有向連接邊的源結(jié)點執(zhí)行完成后，如果條件成立，則開始執(zhí)行有向連接邊的目標(biāo)結(jié)點所表示的活動；如果條件不成立，則目標(biāo)結(jié)點的活動不執(zhí)行。菱形在活動圖中表示條件判斷，條件表達式一般出現(xiàn)在以菱形為源結(jié)點的有向邊上?；顒訄D可以表示過程的并發(fā)?；顒訄D的同步條(水平或者垂直粗線)可以將一條有向連接邊分叉為多個并發(fā)執(zhí)行的分支進程，或?qū)⒍鄠€有向連接邊上的進程同步合并為一個進程。6.3.3用活動圖表示用例第70頁，課件共103頁，創(chuàng)作于2023年2月1UML活動圖泳道為了描述活動的責(zé)任對象，活動圖引進了“泳道”的概念。泳道是由垂直長線分割出來的矩形區(qū)域，在泳道上方的對象負責(zé)該矩形區(qū)域內(nèi)的所有活動。如，在圖6.8中，類“Customer”的對象負責(zé)“插入銀行卡”、“輸入密碼”、“選擇功能”、“輸入金額”四項活動，其余活動由類“ATMsystem”的對象負責(zé)。6.3.3用活動圖表示用例第71頁，課件共103頁，創(chuàng)作于2023年2月典型的活動圖6.3基于UML的需求分析第72頁，課件共103頁，創(chuàng)作于2023年2月2用例的活動圖表示6.3.3用活動圖表示用例第73頁，課件共103頁，創(chuàng)作于2023年2月6.3.4生成用例圖執(zhí)行者和用例之間的關(guān)系：觸發(fā)執(zhí)行和信息交換。（可能同時兼具這兩種關(guān)系）從執(zhí)行者指向用例的邊表示觸發(fā)執(zhí)行/信息交換；而從用例指向執(zhí)行者的邊表示用例將其生成的信息傳遞給執(zhí)行者。UML的用例和用例之間的關(guān)系：使用關(guān)系和擴展關(guān)系。使用關(guān)系：如果有一個公共的動作序列存在于多個用例中，為避免重復(fù)，并使需求模型更簡潔，可以將公共動作序列抽出來構(gòu)成新的獨立用例。這樣，原來的多個用例與新的用例之間便通過使用關(guān)系來連接。擴展關(guān)系：如果一個用例的動作序列完全包含另一個用例的動作序列，且前者含有后者所不具備的一些特殊情況下的處理動作，則稱前者擴展后者。6.3基于UML的需求分析第74頁，課件共103頁，創(chuàng)作于2023年2月6.3.4生成用例圖學(xué)生考試用例6.3基于UML的需求分析第75頁，課件共103頁，創(chuàng)作于2023年2月6.3.4生成用例圖執(zhí)行者與用例之間的關(guān)系觸發(fā)執(zhí)行信息交換觸發(fā)執(zhí)行與信息交換如，在“家庭保安系統(tǒng)”中，執(zhí)行者“用戶”在觸發(fā)用例“命令響應(yīng)”的同時，還要向用例傳送命令信息。在UML用例圖中，從執(zhí)行者指向用例的邊表示觸發(fā)執(zhí)行和/或信息交換，從用例指向執(zhí)行者的邊則表示用例將生成的信息傳遞給執(zhí)行者。6.3

基于UML的需求分析第76頁，課件共103頁，創(chuàng)作于2023年2月UML用例與用例之間的關(guān)系使用（use）關(guān)系如果多個用例都有一個公共的動作序列，為避免重復(fù)并使模型簡潔，可以將公共動作序列抽取出來，構(gòu)成新的獨立用例。原來的多個用例與新的用例之間通過使用關(guān)系連接。如，“家庭保安系統(tǒng)”中，“系統(tǒng)配置”和“命令響應(yīng)”兩個用例都使用公共的“密碼驗證”子用例。6.3.4生成用例圖第77頁，課件共103頁，創(chuàng)作于2023年2月UML用例與用例之間的關(guān)系擴展（extend）關(guān)系如果一個用例的動作序列完全包含另一個用例的動作序列，且前者含有后者所不具備的一些特殊情況下的處理動作，則稱前者擴展后者。例如，圖6.10中的“傳感器監(jiān)測”用例僅包含正常的處理流程，而“報警電話未接通”用例除正常流程外還增加了“重復(fù)撥號”以及“重撥次數(shù)達到最大次數(shù)仍無人接聽”這兩種異常處理動作。6.3.4生成用例圖第78頁，課件共103頁，創(chuàng)作于2023年2月“家庭保安系統(tǒng)”的用例圖6.3.4生成用例圖第79頁，課件共103頁，創(chuàng)作于2023年2月“家庭保安系統(tǒng)”的用例圖6.3.4生成用例圖第80頁，課件共103頁，創(chuàng)作于2023年2月6.3.5建立頂層架構(gòu)頂層架構(gòu)的主要目的是為后續(xù)的分析和設(shè)計活動建立一種結(jié)構(gòu)和分劃，以便開發(fā)人員在不同的開發(fā)階段，以及同一開發(fā)階段的不同開發(fā)人員，能夠聚焦于系統(tǒng)的不同部分。頂層架構(gòu)是分析和設(shè)計階段的成果。隨著開發(fā)過程的推進，框架中的內(nèi)容不斷豐富、翔實，最終演進為完整的面向?qū)ο筌浖Y(jié)構(gòu)。6.3基于UML的需求分析第81頁，課件共103頁，創(chuàng)作于2023年2月6.3.5建立頂層架構(gòu)軟件構(gòu)架UML：指系統(tǒng)的組織結(jié)構(gòu)，它可以遞歸解構(gòu)為通過接口交互的部件、連接部件的關(guān)系以及組裝部件的一些限制條件，通過接口交互的部件有類、構(gòu)件和子系統(tǒng)。IEEE：系統(tǒng)在其環(huán)境中的最高層概念6.3基于UML的需求分析第82頁，課件共103頁，創(chuàng)作于2023年2月1UML包圖UML包圖是表示頂層架構(gòu)的機制。包是UML支持對類分組的一種機制?？梢詮哪撤N視角，將某些關(guān)聯(lián)密切的類劃為一個包，而不同包的兩個類的關(guān)聯(lián)應(yīng)比較松散。對于大型軟件系統(tǒng)，包的劃分是實現(xiàn)“分而治之”的重要技術(shù)手段。6.3.5建立頂層架構(gòu)第83頁，課件共103頁，創(chuàng)作于2023年2月1UML包圖UML包圖：對類進行分組的一種機制。包間的兩種關(guān)系：依賴和構(gòu)成。依賴關(guān)系：如果對類A的修改將導(dǎo)致類B的改變，則稱B依賴于A。構(gòu)成關(guān)系：是指包可以嵌套，即包中不僅可包含類，還可以包含子包。6.3.5建立頂層架構(gòu)第84頁，課件共103頁，創(chuàng)作于2023年2月1UML包圖考試系統(tǒng)包圖6.3.5建立頂層架構(gòu)第85頁，課件共103頁，創(chuàng)作于2023年2月6.3.6建立領(lǐng)域概念模型在用戶需求和相關(guān)的業(yè)務(wù)領(lǐng)域中，有一些全局性的概念對于理解需求至關(guān)重要。因此，有必要抽取這些概念，研究這些概念之間的關(guān)系。UML類圖是表示領(lǐng)域概念模型的機制。6.3基于UML的需求分析第86頁，課件共103頁，創(chuàng)作于2023年2月6.3.6建立領(lǐng)域概念模型UML類圖：類表示概念，用類圖表示領(lǐng)域概念模型。類圖圖元：類的名稱、屬性列表、方法列表。類間關(guān)系：繼承、聚集、關(guān)聯(lián)和依賴。繼承關(guān)系：表示子類重用父類的屬性和操作，子類的對象也是父類的對象，有時也稱父類是子類的泛化。子類繼承了父類的所有屬性和操作，但每個子類又有自己的特殊屬性，也就是說父類所具有的屬性和操作，子類肯定有，父類能夠完成的工作子類肯定能完成，反之不然。6.3基于UML的需求分析第87頁，課件共103頁，創(chuàng)作于2023年2月例如在下圖所示的泛化關(guān)系中，“題庫”類是比“選擇題”類、“判斷題”類和“程序設(shè)計題”類更普遍的概念，相反“選擇題”類是比“題庫”類更特殊的概念。這樣“題庫”是一個父類，“選擇題”、“判斷題”和“程序設(shè)計題”是這個父類的子類。父類的“題號”、“試題類型”、“試題屬性”全部被子類繼承，但每個子類又都有自己的特殊屬性，比如判斷題類的屬性“標(biāo)準(zhǔn)答案”，而父類沒有。6.3.6建立領(lǐng)域概念模型6.3基于UML的需求分析第88頁，課件共103頁，創(chuàng)作于2023年2月6.3.6建立領(lǐng)域概念模型繼承關(guān)系/泛化關(guān)系6.3基于UML的需求分析第89頁，課件共103頁，創(chuàng)作于2023年2月小結(jié)本章介紹了面向?qū)ο蟮幕靖拍?，概述了UML的語言機制和基于UML的軟件開發(fā)過程?；赨ML的需求分析方法和過程是本章的重點，主要步驟是：(1)從業(yè)務(wù)需求描述出發(fā)標(biāo)識用例，生成表示用例內(nèi)容的活動圖(可選)，生成表示用例之間、用例與執(zhí)行者之間關(guān)系的用例圖。(2)根據(jù)領(lǐng)域知識、業(yè)務(wù)需求描述和既往經(jīng)驗，建立以包圖表示的目標(biāo)軟件系統(tǒng)的頂層架構(gòu)，形成以類圖表示的領(lǐng)域概念模型。第6章面向?qū)ο蟮男枨蠓治龅?0頁，課件共103頁，創(chuàng)作于2023年2月面向?qū)ο?的軟件開發(fā))方法一、Thephilosophyofsoftwaredevelopment1.傳統(tǒng)方法學(xué)：功能觀（面向功能的）2.OO方法學(xué)：對象觀（面向?qū)ο蟮模┒?、OO方法學(xué)的其它特征和優(yōu)點三、面向?qū)ο蟮能浖_發(fā)1.面向?qū)ο蟮姆椒?.學(xué)習(xí)和應(yīng)用的難點第6-10章面向?qū)ο蠓椒ǖ?1頁，課件共103頁，創(chuàng)作于2023年2月面向?qū)ο蠓椒ㄩ_發(fā)軟件通常建立的三種形式的模型

描述系統(tǒng)數(shù)據(jù)結(jié)構(gòu)的對象模型描述系統(tǒng)控制結(jié)構(gòu)的動態(tài)模型描述系統(tǒng)功能的功能模型

面向?qū)ο?的軟件開發(fā))方法第6-10章面向?qū)ο蠓椒ǖ?2頁，課件共103頁，創(chuàng)作于2023年2月屬性、操作、協(xié)作者類／對象對象-關(guān)模型系模型對象-行為模型使用實例功能模型行為模型數(shù)據(jù)模型（靜態(tài)）（靜態(tài)）（動態(tài)）CRC索引卡片面向?qū)ο?的軟件開發(fā))方法第6-10章面向?qū)ο蠓椒ǖ?3頁，課件共103頁，創(chuàng)作于2023年2月面向?qū)ο蠓椒ㄩ_發(fā)軟件通常建立的三種形式的模型

三種模型從三個不同但由密切相關(guān)的角度模擬目標(biāo)系統(tǒng)。

對象模型是最重要、最基本、最核心的。