面向對象的需求分析方法

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

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

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

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

　　一、面向對象的概念

　　關于“面向對象”，有許多不同的看法。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） 。這個操作可以在類層次的各層重新實現，以有效利用各個子類的特殊的特征。例如，假定一個矩形有某些邊與屏幕的邊平行，這時，檢查一個點是否包含在矩形內，比檢查一個點是否在一個一般的四邊形內的效率要高一些。

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

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

　　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概述

　　一、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 及其軟件開發方法的讀者。

　　二、基于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）指定每一傳感器的種類和編號；

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

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

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

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

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

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

　　場景名稱：門窗監測。

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

　　前置條件：系統已開機。

　　事件流：

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

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

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

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

　　后置條件：系統處于“報警”狀態。

　　根據場景作用的不同，可以將其劃分為以下類型：

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

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

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

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

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

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

　　（2） 執行者希望系統執行哪些任務？

　　（3） 執行者希望獲得哪些信息？這些信息由誰生成？由誰修改？

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

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

　　總之，確定執行者和場景的關鍵在于理解業務領域和初步需求描述文檔。場景將促成開發人員和用戶對業務處理流程和目標軟件系統的功能范圍的共同理解。在場景確定之后，通過對場景的匯總、分類歸并和抽象即可形成用例。

　　二、生成用例

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

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

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

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

　　用例名稱：傳感器監測。

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

　　前置條件：系統已開機。

　　主事件流：

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

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

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

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

　　輔事件流：

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

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

　　后置條件 ：如果已發現異常監測數據 ，系統處于“報警“狀態；否則，系統處于正常的監測狀態。

　　三、用活動圖表示用例

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

　　1.UML活動圖

　　用例的事件流或操作均表示為一系列的活動，每個活動在活動圖中被表示為一個節點。節點之間的有向邊表示活動的執行順序。在節點間的連接邊上可以附加條件表達式，以表示在有向邊的源節點執行完成后，如果條件成立 ，則開始執行有向邊的目標節點所表示的活動 ；如果條件不成立，則目標節點的活動不被執行。條件表達式一般出現在以菱形為源節點的有向邊上。菱形在活動圖中屬特殊節點，用來表示條件判斷。例如，在圖 5-3-2中，“密碼驗證”活動的有向邊上。如果“（密碼正確）”，則開始“開始選擇功能”活動；否則，回到“輸入密碼“活動。

?

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

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

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

　　2.用例的活動圖表示

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

?

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

　　四、生成用例圖

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

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

　　UML的用例與用例之間存在如下兩種關系：

　　（1） 使用（use）關系 。如果有一個公共的動作序列存在于多個用例中，為避免重復，并使需求模型更簡潔，可以將公共動作序列抽出來構成新的獨立用例。這樣，原來的多個用例與新的用例之間便通過使用關系來連接。例如，在“家庭保安系統”中“系統配置”和“命令響應”兩個用例使用公共的“密碼驗證”子用例。

　　（2） 擴展（extend）關系。如果一個用例的動作序列完全包含另一個用例的動作序列，且前者含有后者所不具備的一些特殊情況下的處理動作，則稱前者擴展后者。例如，圖 5-3-4的“傳感器監測”用例僅包含正常的處理流程，而“報警電話未接通”用例除正常流程處還增加了“重復撥號”以及“重撥次數達到最大次數仍無人接聽”這兩種異常處理動作。

?

圖 5-3-4　“家庭保安系統”的用例圖

　　五、建立頂層架構

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

　　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）開發團隊的技術專長。 根據開發人員在問題領域和軟件技術領域不同的專長劃分頂層架構中的包，使每個包都能分配給最適合的開發人員進行后續的分析、設計、編碼和測試等，從而有利于并行開發。

　　六、建立領域概念模型

　　在用戶需求和相關的業務領域中，往往有一些全局性的概念對于理解需求至關重要。因此 ，有必要抽取這些概念 ，并研究這些概念之間的關系。

　　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個新類。其中，“用戶命令處理器”負責接收來自用戶的操作命令，并將命令處理結果反饋至顯示面板；“系統配置管理器”保存系統的配置信息，協助“用戶命令處理器”完成用戶對系統配置信息的修改，還要負責向系統中的其他類提供配置信息的查詢服務；“監測器”負責接收傳感器的數據，根據系統配置信息判別異常狀況，在異常發生時生成“ 異常事件 ”對象，觸發警報器并撥報警電話；“日志管理器”向系統中的其他類提供日志的記錄和查詢服務，日志信息應包括用戶命令及處理結果、配置更改的歷史記錄和異常善的歷史記錄等。

?

轉載于:https://www.cnblogs.com/ziizz/p/6026381.html

總結

以上是生活随笔為你收集整理的面向对象的需求分析方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。