軟件工程

SoftwareEngineering

國防科技大學計算機學院2004.07齊治昌教授，譚慶平教授，寧洪教授，董威博士2022/12/91國防科技大學計算機學院

軟件工程

Softwar第六章面向對象的需求分析面向對象的需求分析方法的核心是利用面向對象的概念和方法為軟件需求建造模型。它包含面向對象風格的圖形語言機制以及用于指導需求分析的面向對象方法學。面向對象的思想最初起源于1960年代中期的仿真程序設計語言Simula67。1980年代初出現的Smalltalk語言及其程序設計環境對面向對象技術的推廣應用起到了顯著的促進作用。1990年代中后期誕生并迅速成熟的UML（統一建模語言，UnifiedModelingLanguage）是面向對象技術發展的一個重要里程碑。UML統一了面向對象建模的基本概念、術語和表示方法，不僅為面向對象的軟件開發過程提供了能力豐富的表達手段，而且也為軟件開發人員提供了互相交流、分享經驗的共用語言。2022/12/92國防科技大學計算機學院第六章面向對象的需求分析面向對象的需求分析方法的核心是面向對象的需求分析面向對象的概念與思想UML概述基于UML的需求分析以“家庭保安系統”為實例，介紹與需求分析相關的部分UML語言機制以及基于UML的面向對象的需求分析方法和過程。第六章面向對象的需求分析2022/12/93國防科技大學計算機學院面向對象的需求分析面向對象的概念與思想第六章面向對象的6.1面向對象的概念與思想客觀世界中的應用問題都是由實體及其相互關系構成的。可以將客觀世界中與應用問題有關的實體及其屬性抽象為問題空間中的對象。為應用問題尋求軟件解，是借助于計算機語言對其提供的實體施加某些動作，以動作的結果給出問題的解。匯編語言提供的實體是寄存器、存儲單元；過程式程序設計語言提供的實體是變元、數組、記錄、文件等。這些實體構成解空間中的對象。問題空間中對象的行為是豐富多彩的，而軟件解空間中對象的行為卻是單調刻板的。例如，存儲單元只能作存取操作，文件只能作讀、寫和定位操作。只有借助于相當復雜的方法操縱解空間中的對象才能得到問題的軟件解。這就是所謂的“語義斷層”。第六章面向對象的需求分析2022/12/94國防科技大學計算機學院6.1面向對象的概念與思想客觀世界中的應用問題都是由實體面向對象的概念與思想面向對象(Object-Oriented,簡稱OO)的需求分析方法通過提供對象、對象間消息傳遞等語言機制讓分析人員在解空間中直接模擬問題空間中的對象及其行為，從而削減了語義斷層，為需求建模活動提供了直觀、自然的語言支持和方法學指導。6.1面向對象的概念與思想2022/12/95國防科技大學計算機學院面向對象的概念與思想面向對象(Object-Oriente面向對象的概念與思想為了在解空間模擬現實問題并與人類的思維習慣相一致，OO方法學包容了以下核心概念：(1)對象對象是現實世界中個體或事物的抽象表示，是其屬性和相關操作的封裝。屬性表示對象的性質，屬性值規定了對象所有可能的狀態。對象的操作是指該對象可以展現的外部服務。例如，大型客機可視為對象，它具有位置、速度、顏色、容量等屬性，對于該對象可施行起飛、降落、加速、維修等操作，這些操作將或多或少地改變飛機的屬性值(狀態)。6.1面向對象的概念與思想2022/12/96國防科技大學計算機學院面向對象的概念與思想為了在解空間模擬現面向對象的概念與思想（2）類。類表示某些對象在屬性和操作方面的共同特征。例如，直升飛機、大型客機、轟炸機可歸為飛行器類。共同屬性有：位置、速度和顏色等。共同操作有：起飛、降落、加速和維修等。6.1面向對象的概念與思想2022/12/97國防科技大學計算機學院面向對象的概念與思想（2）類。6.1面向對象的概念與思面向對象的概念與思想(3)繼承類之間的繼承關系是現實世界中遺傳關系的模擬，它表示類之間的內在聯系以及對屬性和操作的共享，即，子類可以沿用父類(被繼承類)的某些特征。子類也可以具有自己獨有的屬性和操作。例如，飛行器、汽車和輪船可歸于交通工具類，飛行器類可以繼承交通工具類的某些屬性和操作。6.1面向對象的概念與思想2022/12/98國防科技大學計算機學院面向對象的概念與思想(3)繼承6.1面向對象的概念面向對象的概念與思想(4)聚集現實世界普遍存在部分—整體關系。例如，飛機可由發動機、機身、機械控制系統、電子控制系統等構成。部分—整體關系在OO方法學中表示為類之間的聚集關系。在聚集關系下，部分類的對象是整體類對象的一個組成部分。6.1面向對象的概念與思想2022/12/99國防科技大學計算機學院面向對象的概念與思想(4)聚集6.1面向對象的概念與思面向對象的概念與思想（5）消息消息傳遞是對象與其外部世界相互關聯的唯一途徑。對象可以向其它對象發送消息以請求服務，也可以響應其它對象傳來的消息，完成自身固有的某些操作，從而服務于其它對象。例如，直升飛機可以響應輪船的海難急救信號，起飛，加速，飛赴出事地點并實施救援作業。因為對象的操作主要用來響應外來消息并為其它對象提供服務，所以它們也被稱作“外部服務”。面向對象=對象+類+繼承+聚集+消息。6.1面向對象的概念與思想2022/12/910國防科技大學計算機學院面向對象的概念與思想（5）消息6.1面向對象的6.2UML概述6.2.1UML的語言機制UML主要以Booch方法、OMT方法[71]和OOSE方法為基礎，同時也吸收了其他面向對象建模方法的優點，形成了一種概念清晰、表達能力豐富、適用范圍廣泛的面向對象的標準建模語言。第六章面向對象的需求分析2022/12/911國防科技大學計算機學院6.2UML概述6.2.1UML的語言機制第六章面向對UML的語言機制UML通過圖形化的表示機制從多個側面刻畫系統的分析和設計模型。

UML共定義十種視圖，可分四類：(1)用例圖（usecasediagram）從外部用戶的角度描述系統的功能，并指出功能的執行者。6.2UML概述2022/12/912國防科技大學計算機學院UML的語言機制UML通過圖形化的表示機制從多個側面刻畫系統UML的語言機制

(2)靜態圖類圖(classdiagram)、類圖描述系統的靜態結構，類圖的結點表示系統中的類及其屬性和操作，類圖的邊表示類之間的聯系，包括繼承、關聯、依賴、聚合等。對象圖(objectdiagram)對象圖是類圖的一個實例。它描述在某種狀態下，或者在某一時間段系統中活躍的對象及其關系。在對象圖中，一個類可以擁有多個活躍的對象實例。包圖(packagediagram)包圖描述系統的分解，表示包(package)以及包之間的關系。包由子包及類組成。包之間的關系包括繼承、構成與依賴關系。6.2UML概述2022/12/913國防科技大學計算機學院UML的語言機制(2)靜態圖6.2UML概述2UML的語言機制(3)行為圖交互圖(interactivediagram)狀態圖(statechartdiagram)活動圖(activitydiagram)它們從不同的側面刻畫系統的動態行為。交互圖描述對象之間的消息傳遞。它又可分為順序圖(sequencediagram)與合作圖(collaborationdiagram)兩種形式。順序圖強調對象之間消息發送的時間序。合作圖更強調對象間的動態協作關系。合作圖也可通過消息序號來表示消息傳遞的時間序，只不過這種表示不如順序圖那樣直觀。6.2UML概述2022/12/914國防科技大學計算機學院UML的語言機制(3)行為圖6.2UML概述2022/12UML的語言機制狀態圖描述類的對象的動態行為。它包含對象所有可能的狀態、活動圖描述系統為完成某項功能而執行的操作序列，這些在每個狀態下能夠響應的事件以及事件發生時的狀態遷移與響應動作。操作序列可以并發和同步。活動圖中包含控制流和信息流。控制流表示一個操作完成后對其后續操作的觸發，信息流則刻畫操作之間的信息交換。6.2UML概述2022/12/915國防科技大學計算機學院UML的語言機制狀態圖描述類的對象的動態行為。6.2UML概UML的語言機制(4)實現圖(implementationdiagram)描述軟件系統的實現。構件圖(componentdiagram)描述軟件實現系統中各組成部件以及它們之間的依賴關系。一個部件可能是一個資源描述文件、一個二進制文件或一個可執行文件。構件圖用于理解和分析軟件各部分之間的相互影響程度。

6.2UML概述2022/12/916國防科技大學計算機學院UML的語言機制(4)實現圖(implementatioUML的語言機制部署圖(deploymentdiagram)描述軟件系統運行環境的硬件及網絡的物理體系結構。結點表示實際的計算機和設備，邊表示結點之間的物理連接關系,也可顯示連接的類型及結點之間的依賴性。在結點內部，可以放置可執行部件和對象以顯示結點與可執行軟件單元之間的對應關系。部署圖對于軟件安裝工程師有重要的參考價值。6.2UML概述2022/12/917國防科技大學計算機學院UML的語言機制部署圖(deploymentdiagram例:課程注冊管理系統的用例圖課表維護、個人課程規劃和選課學生花名冊查詢。教務管理人員使用“課表維護”用例，設置或修改課程屬性（課程的時間、地點、上課老師等），增刪課程；學生使用“個人課程規劃”用例選課、修改自己的個人課表，收費管理系統根據每個學生的選課情況計算其應繳費用；老師使用“選課學生花名冊查詢”用例獲取選定其所開課程的學生花名冊。6.2UML概述2022/12/918國防科技大學計算機學院例:課程注冊管理系統的用例圖課表維護、個人課程規劃和選課學課程注冊管理系統的用例圖圖6.2表示課程注冊管理系統包括：“教務管理人員”、“學生”、“老師”、“課程”、“課程設置”、“課程注冊表”、“課程注冊管理器”、“課程管理器”八個類。前三個類為一般化的“用戶”類的子類。一門“課程”可由一到多個“課程設置”構成，例如，對于全校性的公共基礎課，由于選修的學生太多，必須安排不同的老師、不同的教室或者不同的時間段。“學生”、“老師”與“課程設置”之間，“課程注冊表”與“課程注冊管理器”之間，以及“課程注冊管理器”與“課程”之間存在著關聯關系。6.2UML概述2022/12/919國防科技大學計算機學院課程注冊管理系統的用例圖圖6.2表示課程注冊管理系統包括：6課程注冊管理系統的類圖6.2UML概述2022/12/920國防科技大學計算機學院課程注冊管理系統的類圖6.2UML概述2022/12/720用UML順序圖表示“個人課程規劃”

用例中的學生選課過程6.2UML概述2022/12/921國防科技大學計算機學院用UML順序圖表示“個人課程規劃”

用例中的學生選課過程6.用UML協作圖表示“個人課程規劃”

用例中的學生選課過程

6.2UML概述2022/12/922國防科技大學計算機學院用UML協作圖表示“個人課程規劃”

用例中的學生選課過程

6

UML狀態圖示例

“課程設置”對象的狀態圖表示，每個“課程設置”最多只能容納50個選課學生。6.2UML概述2022/12/923國防科技大學計算機學院UML狀態圖示例“課程設置”對象的狀態圖表示，每個“課UML的語言機制本章的后續章節將結合需求分析過程介紹UML的用例圖、包圖、類圖和活動圖第十章將結合軟件設計過程介紹順序圖、協作圖、狀態圖和活動圖。6.2UML概述2022/12/924國防科技大學計算機學院UML的語言機制本章的后續章節將結合需求分析過程介紹UML的6.2.2基于UML的軟件開發過程雖然UML是獨立于軟件開發過程的，即，UML能夠在幾乎任何一種軟件開發過程中使用，但是，熟悉一種有代表性的面向對象的軟件開發過程，并知悉UML各語言要素在過程中不同階段的應用，對于理解UML將大有裨益。圖6.6表示了一種迭代的漸進式軟件開發過程，它包含四個階段：初啟，細化，構造和移交。6.2UML概述2022/12/925國防科技大學計算機學院6.2.2基于UML的軟件開發過程雖然UML是獨立于軟件開

面向對象的迭代、漸進式軟件開發過程6.2UML概述2022/12/926國防科技大學計算機學院面向對象的迭代、漸進式軟件開發過程6.2UML概述20221初啟在初啟階段，軟件項目的發起人確定項目的主要目標和范圍，并進行初步的可行性分析和經濟效益分析。

6.2UML概述2022/12/927國防科技大學計算機學院1初啟6.2UML概述2022/12/727國防科技大學計2細化細化階段的開始標志著項目的正式確立。軟件項目組在此階段需要完成以下工作：

（1）初步的需求分析。采用UML的用例描述目標軟件系統所有比較重要、比較有風險的用例，利用用例圖表示參與者與用例、以及用例與用例之間的關系。采用UML的類圖表示目標軟件系統所基于的應用領域中的概念及概念之間的關系。這些相互關聯的概念構成領域模型。領域模型一方面可以幫助軟件項目組理解業務背景，與業務專家進行有效溝通；另一方面，隨著軟件開發階段的不斷推進，領域模型將成為軟件結構的主要基礎。如果領域中含有明顯的流程處理成分，可以考慮利用UML的活動圖來刻畫領域中的工作流，并標識業務流程中的并發、同步等特征。

6.2UML概述2022/12/928國防科技大學計算機學院2細化細化階段的開始標志著項目的正式確立細化

（2）初步的高層設計。如果目標軟件系統的規模比較龐大，那么，經初步需求分析獲得的用例、類將會非常多。此時，可以考慮根據用例、類在業務領域中的關系，或者根據業務領域中某種有意義的分類方法將整個軟件系統劃分為若干個包，利用UML的包圖刻畫這些包及其關系。如此，用例、用例圖、類、類圖將依據包的劃分方法分屬于不同的包，從而給出整個目標軟件系統的高層結構。6.2UML概述2022/12/929國防科技大學計算機學院細化

（2）初步的高層設計。如果目標軟件系統的規模比細化（3）部分的詳細設計。對于系統中某些重要的、或者風險比較高的用例，可以采用交互圖進一步探討其內部實現過程。同樣，對于系統中的關鍵類，也可以詳細研究其屬性和操作，并在UML類圖中加以表現。因此，這里倡導的軟件開發過程并不在時間軸上嚴格分劃分析與設計、總體設計與詳細設計，而是根據軟件元素（用例、類等）的重要性和風險程度確立優先細化原則，建議軟件項目組優先考慮重要的、比較有風險的用例和類，不能將風險的識別和解決延遲到細化階段之后。6.2UML概述2022/12/930國防科技大學計算機學院細化（3）部分的詳細設計。對于系統中某些重要的、(4)部分的原型構造。在許多情形下，針對某些復雜的用例構造可實際運行的原型是解決技術風險、讓用戶幫助軟件項目組確認用戶需求的最有效方法。為了構造原型，需要針對用例生成詳盡的交互圖，對所有相關類給出明確的屬性和操作定義。在細化階段可能需要使用的UML語言機制包括：描述用戶需求的用例及用例圖，表示領域概念模型的類圖，表示業務流程處理的活動圖，表示系統高層結構的包圖，表示用例內部實現過程的交互圖等。細化階段的結束條件是，所有主要的用戶需求已通過用例和用例圖得以描述；所有重要的風險已被標識，并對風險應對措施了如指掌；能夠比較精確地估算實現每一用例的時間。細化6.2UML概述2022/12/931國防科技大學計算機學院(4)部分的原型構造。在許多情形下，針對某些復雜的用例構3構造在構造階段，開發人員通過一系列的迭代完成對所有用例的軟件實現工作，在每次迭代中實現一部分用例。以迭代方式實現所有用例的好處在于，用戶可以及早參與對已實現用例的實際評價，提出改進意見，降低大型軟件系統的開發風險。6.2UML概述2022/12/932國防科技大學計算機學院3構造在構造階段，開發人員通過一系列的迭代完成對所有用例的構造在實際開始構造軟件系統之前，有必要預先制定迭代計劃。計劃的制定需遵循兩項原則：（1）用戶認為業務價值較大的用例應優先安排。（2）開發人員評估后認為開發風險較高的用例應優先安排。在迭代計劃中，要確定迭代次數、每次迭代所需時間，以及每次迭代中應完成（或部分完成）的用例。每次迭代過程由針對用例的分析、設計、編碼、測試、集成共5個子階段構成。在集成之后，用戶可以對用例的實現效果進行評價，提出修改意見。這些修改意見可以在本次迭代過程中立即實現，也可以在下次迭代中再予考慮。6.2UML概述2022/12/933國防科技大學計算機學院構造在實際開始構造軟件系統之前，有必要預先制定迭代計劃。計劃構造構造過程中，需要使用UML的交互圖來設計用例的實現方法。為了與設計得出的交互圖協調一致，需要修改或精化在細化階段繪制的作為領域模型的類圖，增加一些為軟件實現所必需的類、類的屬性或方法。如果一個類有復雜的生命周期行為，或者類的對象在生命周期內需要對各種外部事件的刺激作出反應，應考慮用UML狀態圖來表述類的對象的行為。UML的活動圖可以在構造階段用來表示復雜的算法過程和有多個對象參與的業務處理過程。活動圖尤其適用于表示過程中的并發和同步。在構造階段的每次迭代過程中，可以對細化階段繪出的包圖進行修改或精化，以便包圖切實反映目標軟件系統最頂層的結構劃分狀況。6.2UML概述2022/12/934國防科技大學計算機學院構造構造過程中，需要使用UML的交互圖來設計用例的實現方法。構造階段可能使用的UML語言機制（1）用例及用例圖。它們是開發人員在構造階段進行分析和設計的基礎。（2）類圖。在領域概念模型的基礎上引進為軟件實現所必需的類、屬性和方法。（3）交互圖：表示針對用例設計的軟件實現方法。（4）狀態圖：表示類的對象的狀態—事件—響應行為。（5）活動圖：表示復雜的算法過程，尤其是過程中的并發和同步。（6）包圖：表示目標軟件系統的頂層結構。（7）構件圖。（8）部署圖。6.2UML概述2022/12/935國防科技大學計算機學院構造階段可能使用的UML語言機制（1）用例及用例圖。它們是開4移交在移交階段，開發人員對構造階段獲得的軟件系統在用戶實際工作環境（或接近實際的模擬環境）中試運行，根據用戶的修改意見進行少量調整。

6.2UML概述2022/12/936國防科技大學計算機學院4移交在移交階段，開發人員對構造階段獲6.3基于UML的需求分析初步業務需求描述形成后，基于UML的需求分析分為以下步驟：（1）利用用例及用例圖表示需求：從業務需求描述出發獲取執行者和場景；對場景進行匯總、分類、抽象，形成用例；確定執行者與用例、用例與用例圖之間的關系，生成用例圖。

（2）利用包圖及類圖表示目標軟件系統的總體框架結構：根據領域知識、業務需求和工作經驗，設計目標軟件系統的頂層架構；從業務需求描述中提取“關鍵概念”，形成領域概念模型；從概念模型和用例出發，研究系統中主要的類之間的關系，生成類圖。第六章面向對象的需求分析2022/12/937國防科技大學計算機學院6.3基于UML的需求分析初步業務需求描述形成需求分析過程6.3基于UML的需求分析2022/12/938國防科技大學計算機學院需求分析過程6.3基于UML的需求分析2022/12/7386.3.1開發場景場景從單個執行者的角度觀察目標軟件系統的功能和外部行為。這種功能通過系統與用戶之間的交互表征。場景是用戶與系統進行交互的一組具體的動作。場景是用例的實例，而用例是某類場景的共同抽象。對場景的完整描述包含場景名稱、執行者實例、前置條件、事件流和后置條件。如，“家庭保安系統”的初步需求描述，具有系統配置、開機、關機、門窗監測、煙霧監測、復位等場景。6.3基于UML的需求分析2022/12/939國防科技大學計算機學院6.3.1開發場景場景從單個執行者的角度觀察目標軟件監測場景的描述場景名稱：門窗監測。參與執行者實例：警報器，報警電話，顯示器，門窗監視器。前置條件：系統已開機。事件流：

（1）門窗監視器發現門或窗戶發生異動，向軟件系統報告異常事件。（2）軟件系統啟動警報器并撥報警電話號碼。

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

（4）系統在控制面板的顯示器上顯示報警時間及當前狀態（報警：門窗異動）。后置條件：系統處于“報警”狀態。6.3基于UML的需求分析2022/12/940國防科技大學計算機學院監測場景的描述場景名稱：門窗監測。6.3基于UML的需求分析場景的分類(1)

實際場景對實際的業務處理流程或其優化流程的描述，是用戶需求的重要組成部分。(2)設想場景分析人員對目標軟件系統投入應用后經改進或優化的業務流程的描述。這種場景是紙面原型，幫助分析人員挖掘潛在的用戶需求。(3)評價場景確認需求或提出改進建議為主要目的的業務流程描述。評價場景可以在用例生成后對用例進行實例化而形成，以便用戶對用例進行評價或改進。(4)培訓場景：面向開發人員及用戶解釋系統的功能和外部行為的業務流程描述。6.3基于UML的需求分析2022/12/941國防科技大學計算機學院場景的分類(1)實際場景6.3基于UML的需求分析2022場景的獲取確定執行者和場景的關鍵在于理解業務領域和初步需求描述文檔。下列問題的回答可幫助分析人員獲取場景：（1）目標軟件系統有哪些執行者？（2）執行者希望系統執行的任務有哪些？（3）執行者希望獲得哪些信息？這些信息由誰生成？由誰修改？（4）執行者需要通知系統哪些事件？系統響應這些事件時會表現出哪些外部行為？（5）系統將通告執行者哪些事件？場景將促成開發人員和用戶對于業務處理流程和目標軟件系統的功能范圍的共同理解。在場景確定之后，通過對場景的匯總、分類歸并、抽象即可形成用例。6.3基于UML的需求分析2022/12/942國防科技大學計算機學院場景的獲取確定執行者和場景的關鍵在于理6.3.2生成用例從外部用戶的視角看，一個用例是執行者(actor)與目標軟件系統之間一次典型的交互作用。從軟件系統內部的視角出發，一個用例代表著系統執行的一系列動作，動作執行的結果能夠被外部的執行者所察覺。執行者指外部用戶或外部實體在系統中扮演的角色。如果多個用戶在使用目標軟件系統時扮演同一角色，這些用戶用單一執行者表示。如果一個用戶扮演多種角色，則需要用多個執行者來表示同一用戶。6.3基于UML的需求分析2022/12/943國防科技大學計算機學院6.3.2生成用例從外部用戶的視角看，一個用例是執行者(a生成用例對用例的完整描述包括用例名稱、參與執行者、前置條件、一個主事件流、0到多個輔事件流、后置條件。主事件流表示正常情況下執行者與系統之間的信息交互及動作序列，輔事件流則表示特殊情況或異常情況下的信息交互及動作序列。顯式地分隔主、輔事件流是為了使分析人員首先聚焦于正常的業務處理流程，同時也便于用例的讀者理解業務需求。6.3基于UML的需求分析2022/12/944國防科技大學計算機學院生成用例對用例的完整描述包括用例名稱、參與執行者、前置條件、生成用例用例源于分析人員對場景的分類和抽象，對相似場景進行歸并，使得一個用例可以通過實例化、參數調節而涵蓋多個場景。例如，“家庭保安系統”中的“開機”、“關機”、“復位”三個場景可以歸并為“命令處理”用例，三個場景之間的差異通過用戶命令區分。門窗監測、煙霧監測兩個場景可歸并為統一的“傳感器監測”用例。熟悉業務領域的分析師，可以略過場景，直接從業務需求描述中獲取用例。在家庭保安系統中，執行者有“用戶”、“傳感器”、“警報器”、“報警電話”、“顯示器”，用例有“系統配置”、“命令響應”和“傳感器監測”。6.3基于UML的需求分析2022/12/945國防科技大學計算機學院生成用例用例源于分析人員對場景的分類和抽象，對相似場景“傳感器監測”用例的描述用例名稱：傳感器監測參與執行者：各類傳感器，警報器，報警電話，顯示器前置條件：系統已開機。主事件流：

（1）傳感器向目標軟件系統上報其監測數據，系統判斷監測數據正常。

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

（3）報警電話接通后，軟件系統播出語音，報告異常事件發生的時間、地點和事件的性質。

（4）系統在控制面板的顯示器上顯示報警時間及當前狀態（報警）。6.3基于UML的需求分析2022/12/946國防科技大學計算機學院“傳感器監測”用例的描述用例名稱：傳感器監測6.3基于UML“傳感器監測”用例的描述輔事件流：

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

（2）如果重撥次數達到系統預設的最大次數，電話仍無人接聽，則跳過主事件流的步驟（3），轉入步驟（4）。后置條件：如果已發現異常的監測數據，系統處于“報警”狀態；否則系統處于正常的“監測”狀態。6.3基于UML的需求分析2022/12/947國防科技大學計算機學院“傳感器監測”用例的描述輔事件流：6.3基于UML的需求分析6.3.3用活動圖表示用例用例的描述既可采用自然語言，也可采用活動圖，活動圖表示法更為精確、直觀。下面介紹活動圖的語法機制，然后結合實例說明如何用活動圖表示用例。6.3基于UML的需求分析2022/12/948國防科技大學計算機學院6.3.3用活動圖表示用例用例的描述既可采用自然語言，也可1UML活動圖用例的事件流或者操作均可表示為一系列的活動，每個活動在活動圖中被表示為一個結點。結點之間的有向邊表示順序執行的活動。在結點間的連接邊上可以附加條件表達式，表示在有向連接邊的源結點執行完成后，如果條件成立，則開始執行有向連接邊的目標結點所表示的活動；如果條件不成立，則目標結點的活動不執行。菱形在活動圖中表示條件判斷，條件表達式一般出現在以菱形為源結點的有向邊上。活動圖可以表示過程的并發。活動圖的同步條(水平或者垂直粗線)可以將一條有向連接邊分叉為多個并發執行的分支進程，或將多個有向連接邊上的進程同步合并為一個進程。6.3基于UML的需求分析2022/12/949國防科技大學計算機學院1UML活動圖用例的事件流或者操作均可表示為一系列的活動，UML活動圖泳道為了描述活動的責任對象，活動圖引進了“泳道”的概念。泳道是由垂直長線分割出來的矩形區域，在泳道上方的對象負責該矩形區域內的所有活動。如，在圖6.8中，類“Customer”的對象負責“插入銀行卡”、“輸入密碼”、“選擇功能”、“輸入金額”四項活動，其余活動由類“ATMsystem”的對象負責。6.3基于UML的需求分析2022/12/950國防科技大學計算機學院UML活動圖泳道6.3基于UML的需求分析2022/12/7典型的活動圖6.3基于UML的需求分析2022/12/951國防科技大學計算機學院典型的活動圖6.3基于UML的需求分析2022/12/7512用例的活動圖表示

傳感器監測用例活動圖6.3基于UML的需求分析2022/12/952國防科技大學計算機學院2用例的活動圖表示6.3基于UML的需求分析2022/126.3.4生成用例圖執行者與用例之間的關系觸發執行信息交換觸發執行與信息交換如，在“家庭保安系統”中，執行者“用戶”在觸發用例“命令響應”的同時，還要向用例傳送命令信息。在UML用例圖中，從執行者指向用例的邊表示觸發執行和/或信息交換，從用例指向執行者的邊則表示用例將生成的信息傳遞給執行者。6.3基于UML的需求分析2022/12/953國防科技大學計算機學院6.3.4生成用例圖執行者與用例之間的關系6.3基于UMLUML用例與用例之間的關系（1）使用（use）關系，如果多個用例都有一個公共的動作序列，為避免重復并使模型簡潔，可以將公共動作序列抽取出來，構成新的獨立用例。原來的多個用例與新的用例之間通過使用關系連接。如，“家庭保安系統”中，“系統配置”和“命令響應”兩個用例都使用公共的“密碼驗證”子用例。（2）擴展（extend）關系。如果一個用例的動作序列完全包含另一個用例的動作序列，且前者含有后者所不具備的一些特殊情況下的處理動作，則稱前者擴展后者。例如，圖6.10中的“傳感器監測”用例僅包含正常的處理流程，而“報警電話未接通”用例除正常流程外還增加了“重復撥號”以及“重撥次數達到最大次數仍無人接聽”這兩種異常處理動作。6.3基于UML的需求分析2022/12/954國防科技大學計算機學院UML用例與用例之間的關系（1）使用（use）關系，如果多個“家庭保安系統”的用例圖6.3基于UML的需求分析2022/12/955國防科技大學計算機學院“家庭保安系統”的用例圖6.3基于UML的需求分析2022/6.3.5建立頂層架構頂層架構的主要目的是為后續的分析和設計活動建立一種結構和分劃，以便開發人員在不同的開發階段，以及同一開發階段的不同開發人員，能夠聚焦于系統的不同部分。頂層架構是分析和設計階段的成果。隨著開發過程的推進，框架中的內容不斷豐富、翔實，最終演進為完整的面向對象軟件結構。6.3基于UML的需求分析2022/12/956國防科技大學計算機學院6.3.5建立頂層架構頂層架構的主要目的是為后續的分析和設1UML包圖UML包圖是表示頂層架構的機制。下面首先介紹包圖的語法機制，然后探討建立頂層架構的方法與原則。包是UML支持對類分組的一種機制。可以從某種視角，將某些關聯密切的類劃為一個包，而不同包的兩個類的關聯應比較松散。對于大型軟件系統，包的劃分是實現“分而治之”的重要技術手段。6.3基于UML的需求分析2022/12/957國防科技大學計算機學院1UML包圖UML包圖是表示頂層架構的機制。下面首先介紹包UML包圖包的依賴和構成關系如果對類A的修改將導致類B的改變，則稱B依賴于A。如果兩個包中存在具有依賴關系的兩個類，則稱這兩個包之間存在依賴關系。包的構成關系包可以嵌套，包可包含類，也可包含子包。為了表示軟件架構，還需要在包之間引進“連接器”邊，連接器表示包之間的信息傳遞、事件發送、軟件調用等關系。連接器分為單向和雙向（即無向）。6.3基于UML的需求分析2022/12/958國防科技大學計算機學院UML包圖包的依賴和構成關系6.3基于UML的需求分析202包圖示例“領域”包由“訂單”和“客戶”兩個子包構成，“訂單”包依賴于“客戶”包。數據庫接口類僅定義抽象數據訪問，數據操作。Oracle接口包和DB2接口包基于具體的數據庫管理系統實現通用接口定義的抽象接口函數。6.3基于UML的需求分析2022/12/959國防科技大學計算機學院包圖示例“領域”包由“訂單”和“客戶”兩個子包構成，“訂單”2軟件頂層架構的設計方法結合實際需求，選取架構模式，再進行局部調整。主要架構模式流程處理模式客戶/服務器模式、模型—視圖—控制器模式分層模式6.3基于UML的需求分析2022/12/960國防科技大學計算機學院2軟件頂層架構的設計方法6.3基于UML的需求分析2022軟件頂層架構的設計（1）流程處理模式。流程處理系統以算法和數據結構為中心，其系統功能由一系列的處理步驟構成，相鄰處理步驟用數據流通管道連接。流程處理模式適用于批處理方式的軟件系統，不適合交互式系統。6.3基于UML的需求分析2022/12/961國防科技大學計算機學院軟件頂層架構的設計（1）流程處理模式。6.3基于UML的需求流程處理模式流程處理模式具有三個處理步驟。步驟都使用公共的系統服務（例如數據庫訪問服務），命令處理和命令處理的進度、結果都通過用戶界面。6.3基于UML的需求分析2022/12/962國防科技大學計算機學院流程處理模式流程處理模式具有三個處理步驟。6.3基于UML的客戶/服務器模式（2）客戶/服務器模式。客戶端負責用戶輸入和處理結果的呈現，服務端負責后臺業務處理。6.3基于UML的需求分析2022/12/963國防科技大學計算機學院客戶/服務器模式（2）客戶/服務器模式。6.3基于UML的需模型—視圖—控制器（MVC）模式（3）模型—視圖—控制器模式軟件系統由模型、視圖和控制器三部分組成。模型負責維護并保存具有持久性的業務數據，實現業務處理功能，并將業務數據的變化情況及時通知視圖。視圖負責呈現模型中包含的業務數據，響應模型變化通知，更新呈現形式，向控制器傳遞用戶的界面動作。控制器負責將用戶的界面動作映射為模型中的業務處理功能并實際調用之，然后根據模型返回的業務處理結果選擇新的視圖。MVC模式特別適合于分布式應用軟件，尤其是Web應用系統6.3基于UML的需求分析2022/12/964國防科技大學計算機學院模型—視圖—控制器（MVC）模式（3）模型—視圖—控制器模式分層模式（4）分層模式將整個軟件系統分為若干層次，最頂層直接面向用戶提供軟件系統的操作界面，其余各層為緊鄰其上的層次提供服務。分層模式可以有效降低軟件系統的耦合度，應用普遍。6.3基于UML的需求分析2022/12/965國防科技大學計算機學院分層模式（4）分層模式6.3基于UML的需求分析2022/1分層模式層次劃分的主要原則易變化的部分，如用戶界面、與業務邏輯緊密相關的部件，置于高層穩定部分，如公共的技術服務部件，置于低層；每層都盡量訪問緊鄰的下層，避免越級訪問，尤其要避免逆向訪問即，上層模塊為下層模塊提供服務；將目標軟件系統的外部接口置入較低層次，系統其余部分對外部系統的訪問或操作通過這些外部接口提供的服務來完成。6.3基于UML的需求分析2022/12/966國防科技大學計算機學院分層模式層次劃分的主要原則6.3基于UML的需求分析2022軟件架構在全面了解軟件架構樣式的前提下，對于具體的應用需求而言，影響頂層架構選取的主要因素在于分析人員的經驗以及他們對每種架構樣式與當前軟件項目之間匹配程度的判斷。大型軟件的頂層架構往往需要使用多種架構樣式。如，整個目標軟件系統采用分層結構，在系統的不同層次內再分別使用適宜的其他類型的架構模式。6.3基于UML的需求分析2022/12/967國防科技大學計算機學院軟件架構在全面了解軟件架構樣式的前提下，對于具體的應用需求而確立軟件架構（1）架構中包的數量包中軟件元素過多，應對包進一步細分；如果過少，則說明架構過早地陷入細節。（2）架構中包之間的耦合度包的依賴關系、連接關系應盡量簡單、松散，如，在分層結構中，通常要求某一層的軟件元素只與同層及下一層的元素存在依賴關系。（3）軟件元素的穩定性抽取不穩定的軟件元素的相對穩定部分，將不穩定的軟件元素分類聚集在少數幾個包中，以提高軟件系統的可維護性。6.3基于UML的需求分析2022/12/968國防科技大學計算機學院確立軟件架構（1）架構中包的數量6.3基于UML的需求分析2確立軟件架構（4）軟件元素的分類將軟件可選功能和必須實現功能的軟件元素分別置于架構的不同包或子包中。（5）作為軟件系統運行環境的物理網絡拓樸根據軟件元素在分布環境中的布局，劃分頂層架構的包，使包的消息傳遞與物理節點的通信相協調，頂層架構定義的通信關系支持后續的分析和設計活動。6.3基于UML的需求分析2022/12/969國防科技大學計算機學院確立軟件架構（4）軟件元素的分類6.3基于UML的需求分析2確立軟件架構（6）軟件元素的安全、保密級別。根據安全訪問的權限劃分頂層架構中的包或者子包。（7）開發團隊的技術專長。根據開發人員在問題和技術領域的專長劃分頂層架構，使得每個包的開發都能充分發揮開發人員和團隊的技術專長（8）調整軟件架構，支持并行開發。6.3基于UML的需求分析2022/12/970國防科技大學計算機學院確立軟件架構（6）軟件元素的安全、保密級別。6.3基于UML6.3.6建立領域概念模型在用戶需求和相關的業務領域中，有一些全局性的概念對于理解需求至關重要。因此，有必要抽取這些概念，研究這些概念之間的關系。UML類圖是表示領域概念模型的機制。下面首先介紹類圖的語法機制，然后探討建立領域概念模型的方法。6.3基于UML的需求分析2022/12/971國防科技大學計算機學院6.3.6建立領域概念模型在用戶需求和相關的業務領域中，有1UML類圖在UML中，用類表示概念，用類圖表示領域概念模型。在需求分析的早期，不需要一次性列舉類的所有屬性和方法。剛開始可以僅標識類名，以后隨著分析、設計的不斷推進而逐步完善屬性列表和方法列表。6.3基于UML的需求分析2022/12/972國防科技大學計算機學院1UML類圖在UML中，用類表示概念，用類圖表示領域UML類圖UML的類包含三個部分：類的名稱屬性列表方法列表表示圖元如圖所示。UML類之間的關系主要有繼承、聚集、關聯和依賴。繼承關系表示子類重用父類的屬性和操作，子類的對象也是父類的對象，有時也稱父類是子類的泛化（generalization）。6.3基于UML的需求分析2022/12/973國防科技大學計算機學院UML類圖UML的類包含三個部分：6.3基于UML的需求分析UML類圖在課程管理系統中，“教務管理人員”、“學生”和“老師”都是泛化的“用戶”類的子類，它們繼承來自“用戶”類的用戶姓名、標識碼、密碼等屬性，以及用戶注冊、密碼驗證、退出系統等操作，見圖6.2。類之間的聚集關系是現實世界部分—整體關系的模擬。6.3基于UML的需求分析2022/12/974國防科技大學計算機學院UML類圖在課程管理系統中，“教務管理人員”、“學生”和“老聚集和構成關系的表示圖元UML將聚集關系分為普通聚集關系:一個部件對象可同時參與多個整體對象。構成關系:限定一個部件對象在任意時刻只能參與一個整體類的對象，部件類對象與整體類對象共存亡。6.3基于UML的需求分析2022/12/975國防科技大學計算機學院聚集和構成關系的表示圖元UML將聚集關系分為6.3基于UML關聯關系關聯關系表示兩個類的對象之間存在著用于消息傳遞的穩定通道。如，在課程注冊管理系統中，“學生”類、“老師”類與“課程設置”類之間存在關聯關系，因為“課程設置”與選課學生和授課老師有關，學生和老師都需要查詢課程設置的有關信息。兩個類的對象之間往往存在著數量對應關系，這種關系是業務規則的具體表現。因此，當分析和設計推進到一定階段之后，應該在聚集、構成和關聯關系的表示邊上明確標示。如，圖6.2表示每個“課程設置”對象應不少于10個、不多于50個選課學生。每個學生在一個學期中選課的課程不少于4門、不多于8門。6.3基于UML的需求分析2022/12/976國防科技大學計算機學院關聯關系關聯關系6.3基于UML的需求分析2022/12/7依賴關系依賴關系依賴類B的對象需要向被依賴類A的對象傳遞消息；被依賴類A可作為依賴類B操作的形參類型。依賴關系表示臨時性的消息傳遞通道，操作完成通道消失；關聯關系及強化形態表示消息傳遞通道在整個對象的生命周期中穩定存在。6.3基于UML的需求分析2022/12/977國防科技大學計算機學院依賴關系依賴關系6.3基于UML的需求分析2022/12/7依賴關系如，在圖6.11中，“訂單”包中的類僅依賴于“數據庫接口”包中的類（接口），并不需要在它們之間建立關聯關系，因為，對數據庫的訪問和操作僅在訂單處理類的函數體中的局部進行。依賴關系是關聯關系的弱化，它表示被依賴的類的變化會影響到依賴類。依賴的強化是關聯，關聯的強化是聚合，聚合的強化是構成。6.3基于UML的需求分析2022/12/978國防科技大學計算機學院依賴關系如，在圖6.11中，“訂單”包中的類僅依賴于“數據庫2建立領域概念模型為建立UML類圖表示的領域概念模型，首先要標識關鍵概念。關鍵概念（1）業務需求描述、用例說明；（2）業務領域中的相關規范、標準、術語定義；（3）反映業務領域知識的既往經驗。“家庭保安系統”的領域概念模型如圖6.18所示。6.3基于UML的需求分析2022/12/979國防科技大學計算機學院2建立領域概念模型為建立UML類圖表示的領“家庭保安系統”的領域概念模型6.3基于UML的需求分析2022/12/980國防科技大學計算機學院“家庭保安系統”的領域概念模型6.3基于UML的需求分析20家庭保安系統”的領域概念模型圖6.18中新引入了“用戶命令處理器”、“系統配置管理器”、“監測器”、“異常事件”和“日志管理器”五個新類。“用戶命令處理器”接收來自用戶的操作命令，并將命令處理結果反饋至顯示面板。“系統配置管理器”保存系統的配置信息，協助“用戶命令處理器”完成用戶對系統配置信息修改，還要負責向系統中的其他類提供配置信息的查詢服務。6.3基于UML的需求分析2022/12/981國防科技大學計算機學院家庭保安系統”的領域概念模型圖6.18中新引入了“用戶命令處家庭保安系統”的領域概念模型“監測器”負責接收傳感器的數據，根據系統配置信息判別異常狀況，在異常發生時生成“異常事件”對象、觸發警報器并拔報警電話。“日志管理器”向系統中的其他類提供日志的記錄和查詢服務，日志信息應包括用戶命令及處理結果、配置更改的歷史記錄，異常狀況的歷史記錄等。6.3基于UML的需求分析2022/12/982國防科技大學計算機學院家庭保安系統”的領域概念模型“監測器”6.3基于UML的需求小結本章介紹了面向對象的基本概念，概述了UML的語言機制和基于UML的軟件開發過程。基于UML的需求分析方法和過程是本章的重點，主要步驟是：(1)從業務需求描述出發標識用例，生成表示用例內容的活動圖(可選)，生成表示用例之間、用例與執行者之間關系的用例圖。(2)根據領域知識、業務需求描述和既往經驗，建立以包圖表示的目標軟件系統的頂層架構，形成以類圖表示的領域概念模型。第六章面向對象的需求分析2022/12/983國防科技大學計算機學院小結本章介紹了面向對象的基本概念，概述了U謝謝2022/12/984國防科技大學計算機學院謝謝2022/12/784國防科技大學計算機學院2022/12/985國防科技大學計算機學院2022/12/785國防科技大學計算機學院

軟件工程

SoftwareEngineering

國防科技大學計算機學院2004.07齊治昌教授，譚慶平教授，寧洪教授，董威博士2022/12/986國防科技大學計算機學院

軟件工程

Softwar第六章面向對象的需求分析面向對象的需求分析方法的核心是利用面向對象的概念和方法為軟件需求建造模型。它包含面向對象風格的圖形語言機制以及用于指導需求分析的面向對象方法學。面向對象的思想最初起源于1960年代中期的仿真程序設計語言Simula67。1980年代初出現的Smalltalk語言及其程序設計環境對面向對象技術的推廣應用起到了顯著的促進作用。1990年代中后期誕生并迅速成熟的UML（統一建模語言，UnifiedModelingLanguage）是面向對象技術發展的一個重要里程碑。UML統一了面向對象建模的基本概念、術語和表示方法，不僅為面向對象的軟件開發過程提供了能力豐富的表達手段，而且也為軟件開發人員提供了互相交流、分享經驗的共用語言。2022/12/987國防科技大學計算機學院第六章面向對象的需求分析面向對象的需求分析方法的核心是面向對象的需求分析面向對象的概念與思想UML概述基于UML的需求分析以“家庭保安系統”為實例，介紹與需求分析相關的部分UML語言機制以及基于UML的面向對象的需求分析方法和過程。第六章面向對象的需求分析2022/12/988國防科技大學計算機學院面向對象的需求分析面向對象的概念與思想第六章面向對象的6.1面向對象的概念與思想客觀世界中的應用問題都是由實體及其相互關系構成的。可以將客觀世界中與應用問題有關的實體及其屬性抽象為問題空間中的對象。為應用問題尋求軟件解，是借助于計算機語言對其提供的實體施加某些動作，以動作的結果給出問題的解。匯編語言提供的實體是寄存器、存儲單元；過程式程序設計語言提供的實體是變元、數組、記錄、文件等。這些實體構成解空間中的對象。問題空間中對象的行為是豐富多彩的，而軟件解空間中對象的行為卻是單調刻板的。例如，存儲單元只能作存取操作，文件只能作讀、寫和定位操作。只有借助于相當復雜的方法操縱解空間中的對象才能得到問題的軟件解。這就是所謂的“語義斷層”。第六章面向對象的需求分析2022/12/989國防科技大學計算機學院6.1面向對象的概念與思想客觀世界中的應用問題都是由實體面向對象的概念與思想面向對象(Object-Oriented,簡稱OO)的需求分析方法通過提供對象、對象間消息傳遞等語言機制讓分析人員在解空間中直接模擬問題空間中的對象及其行為，從而削減了語義斷層，為需求建模活動提供了直觀、自然的語言支持和方法學指導。6.1面向對象的概念與思想2022/12/990國防科技大學計算機學院面向對象的概念與思想面向對象(Object-Oriente面向對象的概念與思想為了在解空間模擬現實問題并與人類的思維習慣相一致，OO方法學包容了以下核心概念：(1)對象對象是現實世界中個體或事物的抽象表示，是其屬性和相關操作的封裝。屬性表示對象的性質，屬性值規定了對象所有可能的狀態。對象的操作是指該對象可以展現的外部服務。例如，大型客機可視為對象，它具有位置、速度、顏色、容量等屬性，對于該對象可施行起飛、降落、加速、維修等操作，這些操作將或多或少地改變飛機的屬性值(狀態)。6.1面向對象的概念與思想2022/12/991國防科技大學計算機學院面向對象的概念與思想為了在解空間模擬現面向對象的概念與思想（2）類。類表示某些對象在屬性和操作方面的共同特征。例如，直升飛機、大型客機、轟炸機可歸為飛行器類。共同屬性有：位置、速度和顏色等。共同操作有：起飛、降落、加速和維修等。6.1面向對象的概念與思想2022/12/992國防科技大學計算機學院面向對象的概念與思想（2）類。6.1面向對象的概念與思面向對象的概念與思想(3)繼承類之間的繼承關系是現實世界中遺傳關系的模擬，它表示類之間的內在聯系以及對屬性和操作的共享，即，子類可以沿用父類(被繼承類)的某些特征。子類也可以具有自己獨有的屬性和操作。例如，飛行器、汽車和輪船可歸于交通工具類，飛行器類可以繼承交通工具類的某些屬性和操作。6.1面向對象的概念與思想2022/12/993國防科技大學計算機學院面向對象的概念與思想(3)繼承6.1面向對象的概念面向對象的概念與思想(4)聚集現實世界普遍存在部分—整體關系。例如，飛機可由發動機、機身、機械控制系統、電子控制系統等構成。部分—整體關系在OO方法學中表示為類之間的聚集關系。在聚集關系下，部分類的對象是整體類對象的一個組成部分。6.1面向對象的概念與思想2022/12/994國防科技大學計算機學院面向對象的概念與思想(4)聚集6.1面向對象的概念與思面向對象的概念與思想（5）消息消息傳遞是對象與其外部世界相互關聯的唯一途徑。對象可以向其它對象發送消息以請求服務，也可以響應其它對象傳來的消息，完成自身固有的某些操作，從而服務于其它對象。例如，直升飛機可以響應輪船的海難急救信號，起飛，加速，飛赴出事地點并實施救援作業。因為對象的操作主要用來響應外來消息并為其它對象提供服務，所以它們也被稱作“外部服務”。面向對象=對象+類+繼承+聚集+消息。6.1面向對象的概念與思想2022/12/995國防科技大學計算機學院面向對象的概念與思想（5）消息6.1面向對象的6.2UML概述6.2.1UML的語言機制UML主要以Booch方法、OMT方法[71]和OOSE方法為基礎，同時也吸收了其他面向對象建模方法的優點，形成了一種概念清晰、表達能力豐富、適用范圍廣泛的面向對象的標準建模語言。第六章面向對象的需求分析2022/12/996國防科技大學計算機學院6.2UML概述6.2.1UML的語言機制第六章面向對UML的語言機制UML通過圖形化的表示機制從多個側面刻畫系統的分析和設計模型。

UML共定義十種視圖，可分四類：(1)用例圖（usecasediagram）從外部用戶的角度描述系統的功能，并指出功能的執行者。6.2UML概述2022/12/997國防科技大學計算機學院UML的語言機制UML通過圖形化的表示機制從多個側面刻畫系統UML的語言機制

(2)靜態圖類圖(classdiagram)、類圖描述系統的靜態結構，類圖的結點表示系統中的類及其屬性和操作，類圖的邊表示類之間的聯系，包括繼承、關聯、依賴、聚合等。對象圖(objectdiagram)對象圖是類圖的一個實例。它描述在某種狀態下，或者在某一時間段系統中活躍的對象及其關系。在對象圖中，一個類可以擁有多個活躍的對象實例。包圖(packagediagram)包圖描述系統的分解，表示包(package)以及包之間的關系。包由子包及類組成。包之間的關系包括繼承、構成與依賴關系。6.2UML概述2022/12/998國防科技大學計算機學院UML的語言機制(2)靜態圖6.2UML概述2UML的語言機制(3)行為圖交互圖(interactivediagram)狀態圖(statechartdiagram)活動圖(activitydiagram)它們從不同的側面刻畫系統的動態行為。交互圖描述對象之間的消息傳遞。它又可分為順序圖(sequencediagram)與合作圖(collaborationdiagram)兩種形式。順序圖強調對象之間消息發送的時間序。合作圖更強調對象間的動態協作關系。合作圖也可通過消息序號來表示消息傳遞的時間序，只不過這種表示不如順序圖那樣直觀。6.2UML概述2022/12/999國防科技大學計算機學院UML的語言機制(3)行為圖6.2UML概述2022/12UML的語言機制狀態圖描述類的對象的動態行為。它包含對象所有可能的狀態、活動圖描述系統為完成某項功能而執行的操作序列，這些在每個狀態下能夠響應的事件以及事件發生時的狀態遷移與響應動作。操作序列可以并發和同步。活動圖中包含控制流和信息流。控制流表示一個操作完成后對其后續操作的觸發，信息流則刻畫操作之間的信息交換。6.2UML概述2022/12/9100國防科技大學計算機學院UML的語言機制狀態圖描述類的對象的動態行為。6.2UML概UML的語言機制(4)實現圖(implementationdiagram)描述軟件系統的實現。構件圖(componentdiagram)描述軟件實現系統中各組成部件以及它們之間的依賴關系。一個部件可能是一個資源描述文件、一個二進制文件或一個可執行文件。構件圖用于理解和分析軟件各部分之間的相互影響程度。

6.2UML概述2022/12/9101國防科技大學計算機學院UML的語言機制(4)實現圖(implementatioUML的語言機制部署圖(deploymentdiagram)描述軟件系統運行環境的硬件及網絡的物理體系結構。結點表示實際的計算機和設備，邊表示結點之間的物理連接關系,也可顯示連接的類型及結點之間的依賴性。在結點內部，可以放置可執行部件和對象以顯示結點與可執行軟件單元之間的對應關系。部署圖對于軟件安裝工程師有重要的參考價值。6.2UML概述2022/12/9102國防科技大學計算機學院UML的語言機制部署圖(deploymentdiagram例:課程注冊管理系統的用例圖課表維護、個人課程規劃和選課學生花名冊查詢。教務管理人員使用“課表維護”用例，設置或修改課程屬性（課程的時間、地點、上課老師等），增刪課程；學生使用“個人課程規劃”用例選課、修改自己的個人課表，收費管理系統根據每個學生的選課情況計算其應繳費用；老師使用“選課學生花名冊查詢”用例獲取選定其所開課程的學生花名冊。6.2UML概述2022/12/9103國防科技大學計算機學院例:課程注冊管理系統的用例圖課表維護、個人課程規劃和選課學課程注冊管理系統的用例圖圖6.2表示課程注冊管理系統包括：“教務管理人員”、“學生”、“老師”、“課程”、“課程設置”、“課程注冊表”、“課程注冊管理器”、“課程管理器”八個類。前三個類為一般化的“用戶”類的子類。一門“課程”可由一到多個“課程設置”構成，例如，對于全校性的公共基礎課，由于選修的學生太多，必須安排不同的老師、不同的教室或者不同的時間段。“學生”、“老師”與“課程設置”之間，“課程注冊表”與“課程注冊管理器”之間，以及“課程注冊管理器”與“課程”之間存在著關聯關系。6.2UML概述2022/12/9104國防科技大學計算機學院課程注冊管理系統的用例圖圖6.2表示課程注冊管理系統包括：6課程注冊管理系統的類圖6.2UML概述2022/12/9105國防科技大學計算機學院課程注冊管理系統的類圖6.2UML概述2022/12/720用UML順序圖表示“個人課程規劃”

用例中的學生選課過程6.2UML概述2022/12/9106國防科技大學計算機學院用UML順序圖表示“個人課程規劃”

用例中的學生選課過程6.用UML協作圖表示“個人課程規劃”

用例中的學生選課過程

6.2UML概述2022/12/9107國防科技大學計算機學院用UML協作圖表示“個人課程規劃”

用例中的學生選課過程

6

UML狀態圖示例

“課程設置”對象的狀態圖表示，每個“課程設置”最多只能容納50個選課學生。6.2UML概述2022/12/9108國防科技大學計算機學院UML狀態圖示例“課程設置”對象的狀態圖表示，每個“課UML的語言機制本章的后續章節將結合需求分析過程介紹UML的用例圖、包圖、類圖和活動圖第十章將結合軟件設計過程介紹順序圖、協作圖、狀態圖和活動圖。6.2UML概述2022/12/9109國防科技大學計算機學院UML的語言機制本章的后續章節將結合需求分析過程介紹UML的6.2.2基于UML的軟件開發過程雖然UML是獨立于軟件開發過程的，即，UML能夠在幾乎任何一種軟件開發過程中使用，但是，熟悉一種有代表性的面向對象的軟件開發過程，并知悉UML各語言要素在過程中不同階段的應用，對于理解UML將大有裨益。圖6.6表示了一種迭代的漸進式軟件開發過程，它包含四個階段：初啟，細化，構造和移交。6.2UML概述2022/12/9110國防科技大學計算機學院6.2.2基于UML的軟件開發過程雖然UML是獨立于軟件開

面向對象的迭代、漸進式軟件開發過程6.2UML概述2022/12/9111國防科技大學計算機學院面向對象的迭代、漸進式軟件開發過程6.2UML概述20221初啟在初啟階段，軟件項目的發起人確定項目的主要目標和范圍，并進行初步的可行性分析和經濟效益分析。

6.2UML概述2022/12/9112國防科技大學計算機學院1初啟6.2UML概述2022/12/727國防科技大學計2細化細化階段的開始標志著項目的正式確立。軟件項目組在此階段需要完成以下工作：

（1）初步的需求分析。采用UML的用例描述目標軟件系統所有比較重要、比較有風險的用例，利用用例圖表示參與者與用例、以及用例與用例之間的關系。采用UML的類圖表示目標軟件系統所基于的應用領域中的概念及概念之間的關系。這些相互關聯的概念構成領域模型。領域模型一方面可以幫助軟件項目組理解業務背景，與業務專家進行有效溝通；另一方面，隨著軟件開發階段的不斷推進，領域模型將成為軟件結構的主要基礎。如果領域中含有明顯的流程處理成分，可以考慮利用UML的活動圖來刻畫領域中的工作流，并標識業務流程中的并發、同步等特征。

6.2UML概述2022/12/9113國防科技大學計算機學院2細化細化階段的開始標志著項目的正式確立細化

（2）初步的高層設計。如果目標軟件系統的規模比較龐大，那么，經初步需求分析獲得的用例、類將會非常多。此時，可以考慮根據用例、類在業務領域中的關系，或者根據業務領域中某種有意義的分類方法將整個軟件系統劃分為若干個包，利用UML的包圖刻畫這些包及其關系。如此，用例、用例圖、類、類圖將依據包的劃分方法分屬于不同的包，從而給出整個目標軟件系統的高層結構。6.2UML概述2022/12/9114國防科技大學計算機學院細化

（2）初步的高層設計。如果目標軟件系統的規模比細化（3）部分的詳細設計。對于系統中某些重要的、或者風險比較高的用例，可以采用交互圖進一步探討其內部實現過程。同樣，對于系統中的關鍵類，也可以詳細研究其屬性和操作，并在UML類圖中加以表現。因此，這里倡導的軟件開發過程并不在時間軸上嚴格分劃分析與設計、總體設計與詳細設計，而是根據軟件元素（用例、類等）的重要性和風險程度確立優先細化原則，建議軟件項目組優先考慮重要的、比較有風險的用例和類，不能將風險的識別和解決延遲到細化階段之后。6.2UML概述2022/12/9115國防科技大學計算機學院細化（3）部分的詳細設計。對于系統中某些重要的、(4)部分的原型構造。在許多情形下，針對某些復雜的用例構造可實際運行的原型是解決技術風險、讓用戶幫助軟件項目組確認用戶需求的最有效方法。為了構造原型，需要針對用例生成詳盡的交互圖，對所有相關類給出明確的屬性和操作定義。在細化階段可能需要使用的UML語言機制包括：描述用戶需求的用例及用例圖，表示領域概念模型的類圖，表示業務流程處理的活動圖，表示系統高層結構的包圖，表示用例內部實現過程的交互圖等。細化階段的結束條件是，所有主要的用戶需求已通過用例和用例圖得以描述；所有重要的風險已被標識，并對風險應對措施了如指掌；能夠比較精確地估算實現每一用例的時間。細化6.2UML概述2022/12/9116國防科技大學計算機學院(4)部分的原型構造。在許多情形下，針對某些復雜的用例構3構造在構造階段，開發人員通過一系列的迭代完成對所有用例的軟件實現工作，在每次迭代中實現一部分用例。以迭代方式實現所有用例的好處在于，用戶可以及早參與對已實現用例的實際評價