面向對象的需求分析方法

面向對象的需求分析方法

　　面向對象的需求分析方法的核心是利用面向對象的概念和方法爲軟件需求建造模型。它包含面向對象風格的圖形語言機制和用於指導需求分析的面向對象方法學。

　　面向對象的思想最初起源於 20世紀 60年代中期的仿真程序設計語言Simula67。20世紀80年代初出現的Smalltalk 語言及其程序設計環境對面向對象技術的推廣應用起到了顯著的促進做用。20世紀90年代中後期誕生並迅速成熟的UML（Unified Modeling Language，統一建模語言）是面向對象技術發展的一個重要里程碑。UML 統一了面向對象建模的基本概念、術語和表示方法，不只爲面向對象的軟件開發過程提供了豐富的表達手段，並且也爲軟件開發人員提供了互相交流、分享經驗的共用語言。

　　本章首先介紹面向對象的主要概念和思想。在概述了UML的全貌以後，以「家庭保安系統」爲實例，介紹與需求分析相關的部分 UML語言機制以及基於UML的面向對象的需求分析方法和過程。

第一節　面向對象的概念與思想

　　1、面向對象的概念

　　關於「面向對象」，有許多不一樣的見解。Coad和 Yourdon給出了一個定義：「面向對象 = 對象 + 類 + 繼承 + 消息通訊」。若是一個軟件系統是使用這樣4個概念設計和實現的，則認爲這個軟件系統是面向對象的。一個面向對象的程序的每一成分應是對象，計算是經過新的對象的創建和對象之間的消息通訊來執行的。

　　1.對象（object）

　　通常意義來說，對象是現實世界中存在的一個事物。能夠是物理的，如一個傢俱或桌子 ，如圖 5-1-1所示，能夠是概念上的 ，如一個開發項目。對象是構成現實世界的一個獨立的單位，具備本身的靜態特徵（用數據描述）和動態特徵（行爲或具備的功能）。例如：人的特徵：姓名、性別、年齡等，行爲：衣、食、住、行等。

 

圖 5-1-1　對象的定義

　　（1）對象、屬性、操做、消息定義

　　對象能夠定義爲系統中用來描述客觀事物的一個實體，它是構成系統的一個基本單位，由一組屬性和一組對屬性進行操做的服務組成。

　　屬性通常只能經過執行對象的操做來改變。

　　操做又稱爲方法或服務，在C ++中稱爲成員函數，它描述了對象執行的功能，若經過消息傳遞，還能夠爲其餘對象使用。

　　而所謂的消息是一個對象與另外一個對象的通訊單元，是要求某個對象執行類中定義的某個操做的規格說明。發送給一個對象的消息定義了一個操做名和一個參數表（多是空的），並指定某一個對象。由一個對象接收的消息則調用消息中指定的操做，並將傳遞過來的實際參數與參數表中相應的形式參數結合起來。接收對象對消息的處理可能會改變對象中的狀態，即改變接收對象的屬性，併發送一個消息給本身或另外一個對象。能夠認爲，這種消息的傳遞大體等價於過程性範型中的函數調用。

　　（2）對象的分類

　　·外部實體：與軟件系統交換信息的外部設備、相關子系統、操做員或用戶等。

　　·信息結構 ：問題信息域中的概念實體 ，如信號、報表、顯示信息等。

　　·須要記憶的事件：在系統運行過程當中可能產生並須要系統記憶的事件，如單擊鼠標左鍵、擊打鍵盤「?」鍵等。

　　·角色：與軟件系統交互的人員所扮演的角色，如經理、部長、技術支持等。

　　·組織機構：有關機構，如單位、小組等。

　　·位置：做爲系統環境或問題上下文的場所、位置，如客戶地址、收件人（機構）地址等。

　　·操做規程：如操做菜單、某種數據輸入過程等。

　　在標識對象時必需注意遵循「信息隱蔽」的原則：必需將對象的屬性隱藏在對象的內部，使得從對象的外部看不到對象的信息是如何定義的，只能經過該對象界面上的操做來使用這些信息。對象的狀態經過給對象賦予具體的屬性值而獲得。它只能經過該對象的操做來改變。

　　對象有兩個視圖，分別表如今分析設計和實現方面。從分析及設計方面來看 ，對象表示了一種概念 ，它們把有關的現實世界的實體模型化。從實現方面來看，一個對象表示了在應用程序中出現的實體的實際數據結構。之因此有兩個視圖，是爲了把說明與實現分離，對數據結構和相關操做的實現進行封裝。

　　2.類（class）和實例（instance）

　　把具備相同特徵和行爲的對象歸在一塊兒就造成了類。類成爲某些對象的模板，抽象地描述了屬於該類的所有對象的屬性和操做。屬於某個類的對象叫作該類的實例。對象的狀態則包含在它的實例變量，即實例的屬性中。如圖 5-1-2所示。從「李傑」、「王輝」和「楊芳」等對象可獲得類「學生」，而這些對象就稱爲該類的實例。

 

圖 5-1-2　對象、類與實例

　　類定義了各個實例所共有的結構，類的每個實例均可以使用類中定義的操做。實例的當前狀態是由實例所執行的操做定義的。

　　面向對象程序設計語言，如C++和 smalltalk都定義了一個new操做，可創建一個類的新實例。C++ 還引入了構造函數，用它在聲明一個對象時創建實例。此外，程序設計語言給出了不一樣的方法，來撤消（稱爲析構）實例，即當某些對象再也不使用時把它們刪去，把存儲釋放以備其餘對象使用。C++給出了一個操做delete，能夠釋放一個對象所用的空間。C++還容許每一個類定義本身的析構方法，在撤消一個對象時調用它。smalltalk 沒有提供一個機制來撤消對象，但能夠進行無用單元收集。

　　類經常可看作是一個抽象數據類型（ADT）的實現 。但更重要的是把類看作是表示某種概念的一個模型。事實上，類是單個的語義單元，它能夠很天然地管理系統中的對象，匹配數據定義與操做。類加進了操做，給一般的記錄賦予了語義，可提供各類級別的可訪問性。

　　3.繼承 （inheritance）

　　若是某幾個類之間具備共性的東西（信息結構和行爲），抽取出來放在一個通常類中，而將各個類的特有的東西放在特殊類中分別描述，則可創建起特殊類對通常類的繼承，如圖 5-1-3所示。各個特殊類能夠從通常類中繼承共性，這樣避免了重複。

 

圖 5-1-3　特殊類對通常類的繼承關係

　　創建繼承結構的好處：

　　·易編程、易理解 代碼短, 結構清晰；

　　·易修改：共同部分只要在一處修改便可；

　　·易增長新類：只須描述不一樣部分。

　　4.多繼承

　　若是一個類須要用到多個既存類的特徵，能夠從多個類中繼承，稱爲多繼承。例如退休教師是繼承退休者和教師這兩個類的某些特徵或行爲而獲得的一個新類。

 

圖 5-1-4　多繼承

　　5.多態性和動態綁定

　　對象互相通訊，即一個對象發消息給另外一個對象，執行某些行爲或又發消息給另外的對象，從而執行系統的功能。

　　發送消息的對象可能不知道另外一個對象的類型是什麼。如在 C程序中使用命令ClearInt （） 時要嚴格區分該命令適合一個整數，仍是一個整數數組。但在C++情形，ClearInt （）對二者都適用，它本身判斷對象是哪個。

　　這就是多態性。它意味 着一個操做 在不一樣類中能夠有不一樣的實現方式。如清零操做 ClearInt （ ） 針對消息對象是 int array 仍是int，其實現是不一樣的。在一個面向對象的多態性語言中，可能代替一個特定類型的類型的集合就是它的子類集合。

　　例如，圖 5-1-5給出了 4個類的繼承層次。使用這個繼承結構，發送給多邊形類的全部消息，它的全部子類都可以響應。又例如，想要在屏幕上畫一系列多邊形，多態性容許一個表的元素能夠屬於一組指定的類型而不只僅是一個類型，能夠認爲這是一個類族。經過遍歷這個表，發送給各個表元素以draw消息，畫出全部的多邊形。

 

圖 5-1-5　4個類的繼承層次

　　動態綁定把函數調用與目標代碼塊的鏈接延遲到運行時進行。這樣，只有發送消息時才與接收消息實例的一個操做綁定。它與多態性可使咱們創建的系統更靈活，易於擴充。作爲動態綁定的例子，考慮在多邊形類中的方法contains ? （aPoint） 。這個操做能夠在類層次的各層從新實現，以有效利用各個子類的特殊的特徵。例如，假定一個矩形有某些邊與屏幕的邊平行，這時，檢查一個點是否包含在矩形內，比檢查一個點是否在一個通常的四邊形內的效率要高一些。

2、面向對象軟件開發的分析模型

　　面向對象分析過程分爲論域分析和應用分析。論域分析創建大體的系統實現環境，應用分析則根據特定應用的需求進行論域分析。

　　1.OOA分析的基本原則和任務

　　爲創建分析模型，要運用以下的5個基本原則 ：①創建信息域模型；②描述功能；③表達行爲；④劃分功能 、數據 、行爲模型，揭示更多的細節；⑤用早期的模型描述問題的實質，用後期的模型給出實現的細節。這些原則造成OOA的基礎。

　　OOA的目的是定義全部與待解決問題相關的類（包括類的操做和屬性、類與類之間的關係以及它們表現出的行爲）。爲此，OOA需完成的任務是：

　　（1）軟件工程師和用戶必須充分溝通，以瞭解基本的用戶需求；

　　（2）必須標識類（即定義其屬性和操做）；

　　（3）必須定義類的層次；

　　（4）應當表達對象與對象之間的關係（即對象的鏈接）；

　　（5）必須模型化對象的行爲；

　　（6）反覆地作任務①～⑤，直到模型建成。

　　2.OOA概述

　　目前已經衍生許多種 OOA方法。每種方法都有各自的進行產品或系統分析的過程，有一組可描述過程演進的圖形標識，以及能使得軟件工程師以一致的方式創建模型的符號體系。如今普遍使用的OOA方法有如下幾種：

　　（1） Booch 方法：Booch 方法包含「 微開發過程 」和「宏開發過程」。微開發過程定義了一組任務，並在宏開發過程的每一步驟中反覆使用它們，以維持演進途徑。Booch OOA 宏開發過程的任務包括標識類和對象、標識類和對象的語義、定義類與對象間的關係，以及進行一系列求精從而實現分析模型。

　　（2） Rumbaugh 方法：Rumbaugh 和他的同事提出的對象模型化技術（OMT）用於分析、系統設計和對象級設計 。分析活動創建三個模型：對象模型（描述對象、類、層次和關係），動態模型（描述對象和系統的行爲），功能模型（相似於高層的DFD，描述穿越系統的信息流）。

　　（3） Coad和Yourdon 方法：Coad和Yourdong方法經常被認爲是最容易學習的OOA 方法。建模符號至關簡單，並且開發分析模型的導引直接明瞭。其OOA過程概述以下：

　　·使用「要找什麼」準則標識對象；

　　·定義對象之間的通常化∕特殊化結構；

　　·定義對象之間的總體∕部分結構；

　　·標識主題（系統構件的表示）；

　　·定義屬性及對象之間的實例鏈接；

　　·定義服務及對象之間的消息鏈接。

　　（4） Jacobson方法：也稱爲OOSE（面向對象軟件工程）。Jacobson方法與其餘方法的不一樣之處在於他特別強調使用實例（use case）——用以描述用戶與系統之間如何交互的場景。Jacobson方法概述以下：

　　·標識系統的用戶和它們的總體責任；

　　·經過定義參與者及其職責、使用實例、對象和關係的初步視圖，創建需求模型；

　　·經過標識界面對象、創建界面對象的結構視圖、表示對象行爲、分離出每一個對象的子系統和模型，創建分析模型。

　　（5） Wirfs―Brock 方法：Wirfs―Brock 方法不明確區分分析和設計任務 。從評估客戶規格說明到設計完成 ，是一個連續的過程 。與Wirfs―Brock分析有關的任務概述以下：

　　·評估客戶規格說明；

　　·使用語法分析從規格說明中提取候選類；

　　·將類分組以表示超類；

　　·定義每個類的職責；

　　·將職責賦予每一個類；

　　·標識類之間的關係；

　　·基於職責定義類之間的協做；

　　·創建類的層次表示；

　　·構造系統的協做圖。

　　（6） 統一的OOA方法（UML） 。統一的建模語言（UML）已經在企業中普遍使用，它把Booch、Rumbaugh和Jacobson 等各自獨立的OOA和OOD方法中最優秀的特點組合成一個統一的方法。UML 容許軟件工程師使用由一組語法的語義的實用的規則支配的符號來表示分析模型。

　　在UML中用5種不一樣的視圖來表示一個系統，這些視圖從不一樣的側面描述系統。每個視圖由一組圖形來定義。這些視圖概述以下：

　　·用戶模型視圖：這個視圖從用戶（ 在UML中叫作參與者）角度來表示系統。它用使用實例（use case）來創建模型，並用它來描述來自終端用戶方面的可用的場景。

　　·結構模型視圖 ：從系統內部來看 數據和功能性 。即對 靜態結構（類、對象和關係）模型化。

　　·行爲模型視圖：這種視圖表示了系統動態和行爲。它還描述了在用戶模型視圖和結構模型視圖中所描述的各類結構元素之間的交互和協做。

　　·實現模型視圖：將系統的結構和行爲表達成爲易於轉換爲實現的方式。

　　·環境模型視圖：表示系統實現環境的結構和行爲。

　　一般，UML 分析建模的注意力放在系統的用戶模型和結構模型視圖，而UML設計建模則定位在行爲模型、實現模型和環境模型。

第二節　UML概述

　　1、UML的語言機制

　　在UML 誕生以前，面向對象領域已經涌現出了許多開發方法及相應的表示機制，它們各有千秋 ，卻又有不少相似之處 ，每每讓使用者無所適從。UML在這樣的背景下應運而生。它主要以BOOCH 方法、OMT方法（71）和OOSE方法爲基礎，同時也吸取了其餘面向對象建模方法的優勢，造成一種概念清晰、表達能力豐富、適用範圍普遍的面向對象的標準建模語言。

　　UML 經過圖形化的表示機制從多個側面對系統的分析和設計模型進行刻畫。它共定義了10種視圖，並將其分爲以下4類：

　　（1）用例圖（use case diagram） 。從外部用戶的角度描述系統的功能，並指出功能的執行者。

　　（2）靜態圖。包括類圖（class diagram）、對象圖（object diagram） 和包圖（pack diagram）。類圖描述系統的靜態結構，類圖的節點表示系統中的類及其屬性和操做，類圖的邊表示類之間的聯繫，包括繼承、關聯、依賴、聚合等。對象圖是類圖一個實例，它描述在某種狀態下或在某一時間段，系統中活躍的對象及其關係。在對象圖，一個類能夠擁有多個活躍的對象實例。包圖描述系統的分解結構，它表示包(package)以及包之間的關係。包由子包及類組成。包之間的關係包括繼承、構成與依賴關係。

　　（3）行爲圖。包括交互圖（interactive diagram）、狀態圖（statechar diagram） 與活動圖（activity diagram），它們從不一樣的側面刻畫系統的動態行爲。交互圖描述描述對象之間的消息傳遞，它又可分爲順序圖（sequence diagram）與 合做圖（collaboration diagram）兩種形式。順序圖強調對象之間消息發送的時間序。合做圖更強調對象間的動態協做關係。合做圖也可經過消息序號之間消息發送的時間序。只不過這種表示不如順序圖那樣直觀 。狀態圖描述類的對象的動態行爲 ，它包含對象全部可能的狀態、在每一個狀態下可以響應的事件以及事件發生時的狀態遷移與響應動做。活動圖描述系統爲完成某項功能而執行的操做序例，這些操做序列能夠併發和同步。活動圖中包含控制和信息流。控制流表示一個操做完成後對其後操做的觸發，信息流則刻畫操做之間的信息交換。

　　（4）實現圖（implementatin diagram）。包括構件圖（component diagram）與 部署圖（deploymetn diagram），它們描述軟件實現系統的組成和分佈情況。構件圖描述軟件實現系統中各組成部件以及它們之間的信賴關係。一個部件多是一個資源描述文件、一個二進制文件或一個可執行文件。構件圖主要用於理解和分析軟件各部分之間的相互影響程度。部署圖描述做爲軟件系統運行環境的硬件及網絡的物理體系結構，其節點表示實際的計算機和設備，邊表示節點之間物理鏈接關係，也可顯示鏈接的類型及節點之間的依賴性。在節點內部，能夠放置可執行部件和對象以顯示節點與可執行軟件單元之間的對應關係。部署圖對於軟件安裝工程師有着重要的參考價值。

　　例如，圖5-2-1表示某大學的課程註冊管理系統包含3個用例：「課表維護」、「我的課程規劃」和「選課學生花名冊查詢」。教務管理人員使用「課表維護」用例設置或修改課程屬性（課程的時間、地點、上課老師等）和增刪課程；學生使用「我的課程規劃」用例選課和修改本身的我的課表，收費管理系統根據每一個學生的選課狀況計算其應繳費用；老師使用「選課學生花名冊查詢」用例獲取選定其所開課程的學生花名冊。

圖 5-2-1　課程註冊管理系統的用例圖

　　圖 5-2-2表示前述的課程註冊管理系統包含「教務管理人員」、「學生」、「老師」、「課程」、「課程設置」、「課程註冊表」、「課程註冊管理器」和「課程管理器」8個類。前3個類爲通常化的「用戶」類的子類。一門「課程」可由一到多個「課程設置」構成，例如，對於全校性的公共基礎課，因爲選修的學生太多，必須安排不一樣的老師、不一樣的教室和不一樣的時間段。「學生」 、「老師」與「課程設置」之間 ，「課程註冊表」與「課程註冊管理器」之間以及「課程註冊管理器」與「課程」之間存在着關聯關係。

圖 5-2-2　課程註冊管理系統的類圖

　　圖5-2-3經過UML順序圖刻畫了「我的課程規劃」用例中學生選課功能的實現過程。

圖 5-2-3　用UML順序圖表示「我的課程規劃」用例中的學生選課過程

　　圖 5-2-4用UML協做圖刻畫學生選課過程，該圖與圖 5-2-3等價。

圖 5-2-4　用UML協做圖表示「我的課程規劃」用例中的學生選課過程

　　圖 5-2-5「課程設置」對象的狀態圖。它表示每一個「課程設置」最多隻能容納50個選課學生。

圖 5-2-5　UML狀態圖示例

　　本章的後繼章節結合需求分析過程更具體地介紹UML的用例圖、包圖、類圖和活動圖，第八章將結合軟件設計過程詳細介紹順序圖、協做圖、狀態圖和活動圖。對其餘UML 圖形機制感興趣的讀者，以及但願進一步深刻了解UML 及其軟件開發方法的讀者。

　　2、基於UML的軟件開發過程

　　雖然UML是獨立於軟件開發過程的，即UML可以在幾乎任何一種軟件開發過程當中使用，可是熟悉一種有表明性的面向對象的軟件開發過程，並知悉UML 各語言要素在過程當中不一樣階段的應用，對於理解UML將大有裨益。

　　圖 5-2-6表示一種迭代的漸進式軟件開發過程，它包含4個階段：初啓、細化、構造和移交。

圖 5-2-6　面向對象的迭代、漸進式軟件開發過程

　　1.初啓

　　在初啓階段，軟件項目的發起人肯定項目的主要目標和範圍，並進行初步的可行性分析和經濟效益分析。

　　2.細化

　　細化階段的開始標誌着項目的正式確立。軟件項目組在此階段須要完成如下工做：

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

　　（2）初步的高層設計 。若是目標軟件系統的規模比較龐大，那麼經初步需求分析得到的用例和類將會很是多。此時，能夠考慮根據用例、類在業務領域中的關係，或者根據業務領域中某種有意義的分類方法將整個軟件系統劃分爲若干包，利用UML的包圖刻畫這些包及其間的關係。這樣，用例、用例圖、類、類圖將依據包的劃分方法分屬於不一樣的包，從而獲得整個目標軟件系統的高層結構。

　　（3）部分的詳細設計 。對於系統中某些重要的或者比較高的用例，能夠採用交互圖進一步探討其內部實現過程 。一樣 ，對於系統中的關鍵類，也能夠詳細研究其屬性和操做，並在UML 類圖中加以表現。所以，這裏倡導的軟件開發過程並不在時間軸上嚴格劃分分析與設計、整體設計與詳細設計，而是根據軟件元素（用例、類等）的重要性和風險程度確立優先細化原則，建議軟件項目組優先考慮重要的、比較有風險的用例和類，不能將風險的識別和解決延遲到細化階段以後。

　　（4）部分的原型構造。在許多情形下 ，針對某些複雜的用例構造可實際運行的耐用消費品型是下降技術風險、讓用戶幫助軟件項目組確認用戶需求的最有效的方法 。爲了構造原型 ，須要針對用例生成詳盡的交互圖，對全部相關類給出明確的屬性和操做定義。

　　綜上所述，在細化階段可能須要使用的UML 語言機制包括：描述用戶需求的用例用用例圖、表示領域概念模型的類圖、表示業務流程處理的活動圖、表示系統高層結構的包圖和表示用例內部實現過程的交互圖等。

　　細化階段的結束條件是，全部主要的用戶需求已經過用例和用例圖得以描述；全部重要的風險已被標識，並對風險應對措施瞭如指掌；可以比較精確地估算實現每一用例的時間。

　　3.構造

　　在構造階段，開發人員經過一系列的迭代完成對全部用例的軟件實現工做，在每次迭代中實現一部分用例。以迭代方式實現全部用例的好處在於，用戶能夠及早參與對已實現用例的實際評價，並提出改進意見。這樣可有效下降大型軟件系統的開發風險。

　　在實際開始構造軟件系統以前，有必要預先制定迭代計劃。計劃的制定需遵循以下兩項原則：

　　（1）用戶變爲業務價值較大的用例應優先安排；

　　（2）開發人員評估後認爲開發風險較高的用例應優先安排。

　　在迭代計劃中，要肯定迭代次數、每次迭代所需時間以及每次迭代中應完成（或部分完成）的用例。

　　每次迭代過程由針對用例的分析、設計、編碼、測試和集成 5個子階段構成。在集成以後，用戶能夠對用例的實現效果進行評價，並提出修改意見。這些修改意見能夠在本次迭代過程當中當即實現，也能夠在下次迭代中再予以考慮。

　　構造過程當中，須要使用UML 的交互圖來設計用例的實現方法。爲了與設計得出的交互圖協調一致，須要修改或精化在細化階段繪製的做爲領域模型的類圖，增長一些爲軟件實現所必需的類、類的屬性或方法。

　　若是一個類有複雜的生命週期行爲，或者類的對象在生命週期內須要對各類外部事件的刺激做出反應，應考慮用 UNL狀態圖來表述類的對象的行爲。

　　UML的活動圖能夠在構造階段用來表示複雜的算法過程和有多個對象參與的業務處理過程。活動圖尤爲適用於表示過程當中的併發和同步。

　　在構造階段的每次迭代過程當中，能夠對細化階段繪出的懈圖進行修改或精化，以便包圖切實反映目標軟件系統最頂層的結構劃分情況。

　　綜上所覈對，在構造階段可能須要使用的UML語言機制包括：

　　用例及用例圖。它們是開發人員在構造階段進行分析和設計的基礎。

　　類圖。在領域概念模型的基礎上引進爲軟件實現所必需的類、屬性和方法。

　　交互圖。表示針對用例設計的軟件實現方法。

　　狀態圖。表示類的對象的狀態—事件—響應行爲。

　　活動圖。表示複雜的算法過程，尤爲是過程當中的併發和同步。

　　包圖。表示目標軟件系統的頂層結構。

　　構件圖。

　　部署圖。

　　4.移交

　　在移交階段，開發人員將構造階段得到的軟件系統在用戶實際工做環境（或接近實際的模擬環境）中試運行，根據用戶的修改意見進行少許調整。

第三節　基於UML的需求分析

　　在初步的業務需求描述已經造成的前提下 ，基於UML的需求分析大體可分爲如下步驟：

　　（1）利用用例及用例圖表示需求 。從業務需求描述出發獲取執行者和場景；對場景進行彙總、分類、抽象；造成用例；肯定執行者與用例、用例與用例圖之間的關係，生成用例圖。

　　（2）利用包圖及類圖表示目標軟件系統的整體框架結構 。根據領域知識、業務需求描述和既往經驗設計目標軟件系統的頂層架構；從業務需求描述中提取「關鍵概念」 ，造成領域概念模型 ；從概念模型和用例出發，研究系統中主要的類之間的關係，生成類圖。

　　上述兩個步驟並無時序關係，它們能夠並行展開，如圖5-3-1所示。

圖 5-3-1　需求分析過程

　　本節將依次介紹上述步驟中涉及的UML語言機制，並結合「家庭保安系統」實例說明每步驟中基於UML的需求分析方法。

　　1、開發場景

　　場景是指從單個執行者的角度觀察目標軟件系統的功能和外部行爲。這種功能經過系統與用戶之間的交互來表徵。所以也能夠說，場景是用戶與系統之間進行交互的一組具體的動做。相對於用例（見第五章第二節）而言，場景是用例的實例，而用例是某類場景的共同抽象。

　　對場景的完整描述應包含場景名稱、執行者實例，前置條件、事件流和後置條件。

　　例如，「家庭保安系統」的初步需求描述：「家庭保安系統」的軟件容許用戶在安裝時進行系統配置，實施對傳感器的監控並經過控制面板與用戶進行信息交互。

　　配置操做包括：

　　（1）指定每一傳感器的種類和編號；

　　（2）設置開、關機密碼；

　　（3）指定報警電話電碼；

　　（4）指定報警延遲和電話重撥延遲時間（以秒爲單位）；

　　當軟件系統收到傳感器發出的數據後，判別是否出現異常事件。若是是，則在指定的延遲時間內撥報警電話號碼，撥號操做將按照重撥延遲反覆進行，直至電話接通。而後軟件系統負責報告時間、地點和異常事件的性質。

　　開機後，軟件系統負責顯示當前工做狀態，接收並處理用戶指令。

　　根據以上描述，該系統具備「系統配置」 、「開機」 、「關機」、「門窗監測」、「煙霧監測」和「復位」等場景。其中，門窗監測場景的具體描述以下：

　　場景名稱：門窗監測。

　　參與執行者實例：警報器、報警電話、顯示器和門窗監視器。

　　前置條件：系統已開機。

　　事件流：

　　（1） 門窗監視器發現門或窗戶發生異動，向軟件系統報告異常事件。

　　（2） 軟件系統啓動警報器並撥報警電話號碼。

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

　　（4） 系統在控制面板的顯示器上顯示報警時間及當前狀態（報警：門窗異動）。

　　後置條件：系統處於「報警」狀態。

　　根據場景做用的不一樣，能夠將其劃分爲如下類型：

　　（1）實際場景。 對實際的業務處理流程或其優化流程的描述。實際場景是用戶需求的重要組成部分。

　　（2）設想場景。 分析人員對目標軟件系統投入應用後經改進或優化的業務流程的描述。這種場景可視爲一種紙面原型，主要用於幫助分析人員挖掘潛在的用戶需求。

　　（3）評價場景。 以確認需求或提出改進建議爲主要目的的業務流程描述。評價場景能夠在用例生成後用例進行實例化而造成，以便用戶對用例進行評價或改進。

　　（4）培訓場景。 面向開發人員及用戶解釋系統的功能和外部行爲的業務流程描述。

　　對如下問題的回答有助於分析人員獲取場景：

　　（1） 目標軟件系統有哪些執行者？

　　（2） 執行者但願系統執行哪些任務？

　　（3） 執行者但願得到哪些信息？這些信息由誰生成？由誰修改？

　　（4） 執行者須要通知系統哪些事件？系統響應這些事件時會表現出哪些外部行爲？

　　（5） 系統將通告執行者哪些事件？

　　總之，肯定執行者和場景的關鍵在於理解業務領域和初步需求描述文檔。場景將促成開發人員和用戶對業務處理流程和目標軟件系統的功能範圍的共同理解。在場景肯定以後，經過對場景的彙總、分類歸併和抽象便可造成用例。

　　2、生成用例

　　從外部用戶的視角看 ，一個用例是執行者（actor）與目標軟件系統之間的一次典型的交互做用。從軟件系統內部的視角出發，一個用例表明系統執行的一系列動做，動做執行的結果可以被外部的執行者所察覺。執行者是指外部用戶或外部實體在系統中扮演的角色。若是多個用戶在使用目標軟件系統時扮演同一角色，這些用戶將由單一執行者表示。反之，若是一個用戶扮演多種角色，則須要用多個執行者來表示同一用戶。

　　對用例的完整描述包括用例名稱、參與執行者、前置條件、一個主事件流、零到多個輔事件流和後置條件。主事件流表示正常狀況下執行者與系統之間的信息交互及動做序列，輔事件流則表示特殊狀況或異常狀況下的信息交互及動做序列。顯式地分隔主、輔事件流是爲了使分析人員首先彙集於正常的業務處理流程，同時也便於用例的讀者理解業務需求。

　　用例主要來源於分析人員對場景的分類和抽象，即將類似的場景進行歸併 ，使一個用例能夠經過實例化和參數調節而涵蓋多個場景 。例如，「家庭保安系統「中的「開機」、「關機」、「復位」 3個場景能夠歸併爲「命令處理」，3 個場景之間的差別經過用戶命令種類的不一樣而體現。相似地，「門窗監測」、「煙霧監測」兩個場景也可歸併爲統一的「傳感器監測」用例 。其實 ，對於熟悉業務領域的分析師而言，也能夠略過場景，直接從業務需求描述中獲取用例。

　　在「家庭保安系統」中，執行者有「用戶」、「傳感器」、「報警電話」和「顯示器」 ，用例有「系統配置」 、「命令響應」和「傳感器監測」。下面以「傳感器監測」爲例說明用例的通常描述格式：

　　用例名稱：傳感器監測。

　　參與執行者：各種傳感器、警報器、報警電話和顯示器。

　　前置條件：系統已開機。

　　主事件流：

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

　　（2）若是不正常，系統啓動警報器，撥報警電話號碼。

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

　　（4）系統在控制面板的顯示器上顯示報警時間及當前狀態（報警）。

　　輔事件流：

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

　　（2）若是重撥次數達到系統預設的最大次數 ，電話仍無人接聽，則跳過主事件流的步驟（3），轉入步驟（4）。

　　後置條件 ：若是已發現異常監測數據 ，系統處於「報警「狀態；不然，系統處於正常的監測狀態。

　　3、用活動圖表示用例

　　用例的描述既可採用天然語言，也可採用活動圖。後一種表示法更爲精確和直觀。下面首先介紹活動圖的語法機制，而後結合實例說明如何用活動圖表示用例。

　　1.UML活動圖

　　用例的事件流或操做均表示爲一系列的活動，每一個活動在活動圖中被表示爲一個節點。節點之間的有向邊表示活動的執行順序。在節點間的鏈接邊上能夠附加條件表達式，以表示在有向邊的源節點執行完成後，若是條件成立 ，則開始執行有向邊的目標節點所表示的活動 ；若是條件不成立，則目標節點的活動不被執行。條件表達式通常出如今以菱形爲源節點的有向邊上。菱形在活動圖中屬特殊節點，用來表示條件判斷。例如，在圖 5-3-2中，「密碼驗證」活動的有向邊上。若是「（密碼正確）」，則開始「開始選擇功能」活動；不然，回到「輸入密碼「活動。

 

圖 5-3-2　典型的活動圖

　　活動圖還能夠表示處理過程的併發。活動圖的同步條（水平或垂直粗線）能夠將一條有向邊分叉爲多個併發執行的分支進程，或將多個有向邊上的進程同步合併爲一個進程。例如，在圖 5-3-2中，當用戶選擇取款操做，輸入取款金額，且系統驗證其要求的金額小於等於餘額以後，系統分叉爲兩個併發進程：點鈔、出鈔和扣減餘額、打印交易信息。此後，再合併爲一個進程，進行「選擇功能」活動。

　　爲了描述活動的責任對象，活動圖引進了「泳道」的概念。泳道是由垂直長線分割出來的矩形區域，在泳道上方的對象負責該矩形區域內的全部活動。例如，在圖 5-3-2中，類「 Customer 」的對象負責「插入銀行卡」、「輸入密碼」 、「選擇功能」和「輸入金額」 4 項活動，其他活動由類「ATMsystem」的對象負責。

　　2.用例的活動圖表示

　　針對前面所述的「傳感器監測」用例，其活動圖表示如圖5-3-3所示。

 

圖 5-3-3　「傳感器監測」用例的活動圖表示

　　4、生成用例圖

　　執行者與用例之間的關係有兩例種：觸發執行與信息交換。執行者與用例之間可能兼具這兩種關係，例如，「 在家庭保安系統 」中，執行者「用戶」在觸發用例「命令響應」的同時，還要向用例傳送命令信息。

　　在 UML用例圖中，從執行者指向用例的邊表示觸發執行和／或信息交換，從用例指向執行者的邊則表示用例將其生成的信息傳遞給執行者。

　　UML的用例與用例之間存在以下兩種關係：

　　（1） 使用（use）關係 。若是有一個公共的動做序列存在於多個用例中，爲避免重複，並使需求模型更簡潔，能夠將公共動做序列抽出來構成新的獨立用例。這樣，原來的多個用例與新的用例之間便經過使用關係來鏈接。例如，在「家庭保安系統」中「系統配置」和「命令響應」兩個用例使用公共的「密碼驗證」子用例。

　　（2） 擴展（extend）關係。若是一個用例的動做序列徹底包含另外一個用例的動做序列，且前者含有後者所不具有的一些特殊狀況下的處理動做，則稱前者擴展後者。例如，圖 5-3-4的「傳感器監測」用例僅包含正常的處理流程，而「報警電話未接通」用例除正常流程處還增長了「重複撥號」以及「重撥次數達到最大次數仍無人接聽」這兩種異常處理動做。

 

圖 5-3-4　「家庭保安系統」的用例圖

　　5、創建頂層架構

　　頂層架構的 主要目的是爲後續的分析 和設計活動創建一種結構和分劃 ，以便開發人員在不一樣的開發階段 ，以及同一開發階段的不一樣開發人員，可以聚焦於系統的不一樣部分。頂層架構是分析和設計的階段成果的承載體。隨着開發過程的推動，框架中的內容不斷豐富、翔實，最終演進爲完整的面向對象軟件結構。

　　UML 包圖是表示頂層架構的適當機制，所以，下面首先介紹包圖的語法機制，而後探討創建頂層架構的方法與原則。

　　1.UML包圖

　　包是UML 對類進行分組的一種機制。能夠從某種視角將具備比較密切的關聯的一些類劃分爲一個包，分屬於不一樣包的兩個類之間的關聯則比較鬆散。因而可知，對於大型軟件系統而言，包的劃分是實現「分而治之」的重要技術手段。

　　包之間存在兩種關係：依賴和構成。若是對類A的修改將致使類B的改變，則稱B依賴於A。若是兩個包中存在具備依賴關係的兩個類，則認爲這兩個類分屬的包之間存在依賴關係。例如，圖 5-3-5中的「訂單」包依賴於「 客戶 」包。包的構成關係是指包是能夠嵌套的，即包中不只可包含類，還能夠包含子包。在圖 5-3-5中，「領域」包由「訂單」和「客戶」兩個子包構成。圖 5-3-5中，「數據庫接口」類僅定義抽象的數據訪問、數據操做的接口函數，而「Oracle接口」 包和「DB2接口」包則基於具體的數據庫管理系統逐一實現了通用接口中定義的抽象接口函數。

 

圖 5-3-5　包圖示例

　　爲了表示軟件架構，還須要在包之間引進一種稱爲「鏈接器」的邊。鏈接器用來表示包之間的信息傳遞、事件發送和軟件調用等關係，且有單向和雙向（即無向）之分。

　　2.軟件頂層架構的設計

　　創建軟件系統頂層架構的基本方法是，結合實際需求，從既往的架構設計經驗模型中選取適當者，再進行微調或局部改造。目前有以下幾種主要的架構模式：

　　（1）流程處理模式 。流程處理系統以算法和數據引進中心，其系統功能由一系列的處理步驟構成，相鄰的處理步驟之間以數據流通管道相互鏈接。

　　圖5-3-6表示具備3處理步驟的流程處理模式。這些處理步驟都使用公共的系統服務（例如數據庫訪問服務），處理命令來自用戶界面，處理的進度和結果也經過用戶界面呈現。

 

圖 5-3-6　流程處理模式

　　流程處理模式僅適合於採用批處理方式的軟件系統，不適合於交互式系統。

　　（2）客戶／服務器模式。如圖5-3-7所示，客戶端負責用戶輸入和處理結果的呈現，服務器端則負責後臺的業務邏輯處理。

 

圖 5-3-7　客戶／服務器模式

　　（3）模型—視圖—控制器（MVC）模式。如圖 5-3-8所示，該模式將整個軟件系統劃分爲模型，視圖和控制器 3個部分。模型負責維護並保存具備持久性的業務數據，實現業務處理功能，並將業務數據的變化狀況及時通知視圖；視圖負責呈現模型的業務數據，響應模型變化通知，更新呈現形式，並向控制器傳遞用戶的界面動做；控制器負責將用戶的界面動做映射爲模型中業務處理功能並實際調用之，而後根據模型返回的業務處理結果選擇新的視圖。MVC模式特別適合於分佈應用軟件，尤爲是Web應用系統。

 

圖 5-3-8　模型－視圖－控制器模式　

　　（4）分層模式。如圖5-3-9所示，分層模式將整個軟件系統分爲若干層次，最頂層直接面向用戶提供軟件系統的操做界面，其他各層爲緊鄰其上的層次提供服務。層次劃時分的主要原則是：較易變化的軟件部分（例如用戶界面、與業務邏輯緊密相關的部件）置於較高層次，較穩定的軟件部分（例如公共的技術服務部件）則位於較低層次；每一層次儘可能只訪問其緊鄰下層提供的服務，避免越級訪問，尤爲要避免逆向訪問（上層模塊爲下層模塊提供服務）；在許多狀況下，能夠將目標軟件系統的外部接口置入較低層次，目標軟件系統其他部分對外部系統的訪問或操做均經過這些外部接口所提供的公共服務來完成。分層模式能夠有效地下降軟件系統的耦合度，所以其應用十分廣泛。

 

圖 5-3-9　分層模式

　　在全面瞭解軟件架構樣式的前提下，對於具體的應用需求而言，影響頂層架構選取的主要因素在於分析人員的經驗以及他們對每種架構樣式與當前軟件項目之間匹配程度的判斷。事實上，大型軟件的頂層架構每每須要複合使用多種架構樣式。例如，整個目標軟件系統採用分層結構，在系統的不一樣層次內再分別使用適宜的其餘種類的架構模式。

　　在確立頂層架構的過程當中，需綜合考慮如下因素：

　　（1）架構中包的數量。 原則上，若是每一個包中包含的軟件元素（例如類）的數量過多，應考慮將其進一步細分；若是過少，則說明架構過早地陷入了細節，架構劃分返工的可能性較大，同時也不合理地限制了後續分析和設計活動的自由空間。

　　（2）架構中包之間的耦合度。 包之間的依賴關係和鏈接關係應儘可能簡單、稀疏，例如，在分層結構中，一般要求某一層中的軟件元素只與同層及相鄰下一層的元素之間存在依賴關係。

　　（3）軟件元素的穩定性。 要儘可能抽取不穩定的軟件元素之中相對穩定的部分將不穩定的軟件元素分類彙集於少數幾個包中，以提升軟件系統的可維護性。

　　（4）軟件元素的必然性。 能夠將可選功能和必須實現的功能分置於架構中不一樣的包或子包之中。

　　（5）做爲軟件系統運行環境的物理網絡拓樸。 根據軟件元素在分佈環境的部署狀況區分頂層架構中的包，可使包之間的消息傳遞與物理節點之間的通訊相吻合，使後續的分析和設計活動受益於頂層架構中明肯定義的通訊關係。

　　（6）軟件元素的安全、保密級別。 根據安全訪問的權限劃分頂層架構中的包或者子包。

　　（7）開發團隊的技術專長。 根據開發人員在問題領域和軟件技術領域不一樣的專長劃分頂層架構中的包，使每一個包都能分配給最適合的開發人員進行後續的分析、設計、編碼和測試等，從而有利於並行開發。

　　6、創建領域概念模型

　　在用戶需求和相關的業務領域中，每每有一些全局性的概念對於理解需求相當重要。所以 ，有必要抽取這些概念 ，並研究這些概念之間的關係。

　　1．UML類圖

　　在UML中，用類表示概念，用類圖表示領域概念模型。

 

圖 5-3-10　類的表示圖元

　　UML的類包含3個部分：類的名稱、屬性列表和方法列表，其表示圖元如圖5-3-10所示。在需求分析的早期不須要一次性列舉類的全部屬性和方法。剛開始能夠僅標識類名，之後隨着分析、設計的不斷推動而逐步完善屬性列表和方法列表。

　　在UML中，類之間的關係的主要有繼承、彙集、關聯和依賴。

　　繼承關係表示子類重用父類的屬性的操做，子類的對象也是父類的對象，有時也稱父類是子類的泛化（generalization）。

　　例如，在課程管理系統中，「教務管理人員」、「學生」和「老師」都是泛化的「用戶」類的子類，它們繼承來自「用戶」類的用戶姓名、標識碼、密碼等屬性以及用戶註冊、密碼驗證、退出系統等操做。

　　類之間的彙集關係是對現實世界中部分—總體關係的直接模擬。 UML將彙集關係進一步細分爲普通匯集和構成關係兩種。在普通匯集關係中，一個部件類對象可同時參與多個總體類對象，構成關係則限定一個部件類對象在任意時刻只能參與一個總體類對象，部件類對象與總體類對象共存亡。普通匯集和構成關係的表示圖元如圖5-3-11所示。

圖 5-3-11　普通匯集和構成關係的表示圖元

　　在概念上，關聯關係表示兩個類之間的相關性。從軟件設計和實現的角度看，關聯關係表示在兩個類的對象之間存在着一種用於消息傳遞的穩定通道。例如，在課程註冊管理系統中，「學生」類、「老師」類與「課程設置」類之間存在關聯關係，由於「課程設置」確定與選課學生和授課老師有關，學生和教師他都須要查詢課程設置中有關信息，如上課時間、地點和選課學生清單等。

　　參與彙集、構成和關聯關係的兩個類的對象之間每每存在着數量對應關係，這種關係是業務規則的具體表現。所以，當分析和設計推動到必定階段以後，應該將這種數量對應關係在這三種關係的表示邊上明確地標示出來。例如，圖 5-3-2表示對於每一個「課程設置」對象，選課學生應很多於10個，很少於50個。每一個學生在一個學期中所選的課程應很多於 4門、很少於8門。

　　依賴關係是關聯關係的弱化 ，表示被依賴的 類的變化會影響到依賴類。依賴關係的原由有：依賴類的對象須要向被依賴害的對象傳遞消息；被依賴類做爲依賴類的操做的形參類型。前一種狀況不只能夠且依賴關係實現，也能夠用關聯關係及強化形式（聚合和構成）來實現。這兩種實現方法的區別在於，依賴關係僅表示一種臨時性的消息傳遞通道，一旦依賴類對象的操做完成，該通道當即消失；關聯關係及其強化形式則表示消息傳遞通道在整個對象的生命週期中穩定存在。例如，在圖 5-3-5中，「訂單」包中的類僅依賴於「數據庫接口」包中的類（接口），並不須要在它們之間創建關聯關係，由於對數據庫的訪問和操做僅在訂單處理類的函數中局部進行。

　　綜上所述，關聯是依賴的強化，聚合是關聯的強化，構成是聚合的強化。

　　2.領域概念模型的創建

　　爲創建以UML 類圖表示的領域概念模型，必須首先標識關鍵概念。關鍵概念的來源包括：

　　業務需求描述和用例說明；

　　業務領域中的相關規範、標準和術語定義；

　　反映業務領域知識的既往經驗；

　　例如，「家庭保安系統」的領域概念模型如圖5-3-12所示。

圖 5-3-12　「家庭保安系統」的領域概念模型

　　圖5-3-12中新引入了「用戶命令處理器」、「系統配置管理器」、監測器「異常事件」 和 「日誌管理器」 5個新類。其中，「用戶命令處理器」負責接收來自用戶的操做命令，並將命令處理結果反饋至顯示面板；「系統配置管理器」保存系統的配置信息，協助「用戶命令處理器」完成用戶對系統配置信息的修改，還要負責向系統中的其餘類提供配置信息的查詢服務；「監測器」負責接收傳感器的數據，根據系統配置信息判別異常情況，在異常發生時生成「 異常事件 」對象，觸發警報器並撥報警電話；「日誌管理器」向系統中的其餘類提供日誌的記錄和查詢服務，日誌信息應包括用戶命令及處理結果、配置更改的歷史記錄和異常善的歷史記錄等。