面向?qū)ο蟮男枨蠓治龇椒ǖ暮诵氖抢妹嫦驅(qū)ο蟮母拍詈头椒檐浖枨蠼ㄔ炷Ｐ汀Ｋ嫦驅(qū)ο箫L(fēng)格的圖形語言機制和用于指導(dǎo)需求分析的面向?qū)ο蠓椒▽W(xué)。

　　面向?qū)ο蟮乃枷胱畛跗鹪从?20世紀(jì) 60年代中期的仿真程序設(shè)計語言Simula67。20世紀(jì)80年代初出現(xiàn)的Smalltalk 語言及其程序設(shè)計環(huán)境對面向?qū)ο蠹夹g(shù)的推廣應(yīng)用起到了顯著的促進(jìn)作用。20世紀(jì)90年代中后期誕生并迅速成熟的UML（Unified Modeling Language，統(tǒng)一建模語言）是面向?qū)ο蠹夹g(shù)發(fā)展的一個重要里程碑。UML 統(tǒng)一了面向?qū)ο蠼５幕靖拍睢⑿g(shù)語和表示方法，不僅為面向?qū)ο蟮能浖_發(fā)過程提供了豐富的表達(dá)手段，而且也為軟件開發(fā)人員提供了互相交流、分享經(jīng)驗的共用語言。

　　本章首先介紹面向?qū)ο蟮闹饕拍詈退枷搿Ｔ诟攀隽薝ML的全貌之后，以“家庭保安系統(tǒng)”為實例，介紹與需求分析相關(guān)的部分 UML語言機制以及基于UML的面向?qū)ο蟮男枨蠓治龇椒ê瓦^程。

第一節(jié)　面向?qū)ο蟮母拍钆c思想

　　一、面向?qū)ο蟮母拍?/p>

　　關(guān)于“面向?qū)ο蟆?#xff0c;有許多不同的看法。Coad和 Yourdon給出了一個定義：“面向?qū)ο?= 對象 + 類 + 繼承 + 消息通信”。如果一個軟件系統(tǒng)是使用這樣4個概念設(shè)計和實現(xiàn)的，則認(rèn)為這個軟件系統(tǒng)是面向?qū)ο蟮摹Ｒ粋€面向?qū)ο蟮某绦虻拿恳怀煞謶?yīng)是對象，計算是通過新的對象的建立和對象之間的消息通信來執(zhí)行的。

　　1.對象（object）

　　一般意義來講，對象是現(xiàn)實世界中存在的一個事物。可以是物理的，如一個家具或桌子 ，如圖 5-1-1所示，可以是概念上的 ，如一個開發(fā)項目。對象是構(gòu)成現(xiàn)實世界的一個獨立的單位，具有自己的靜態(tài)特征（用數(shù)據(jù)描述）和動態(tài)特征（行為或具有的功能）。例如：人的特征：姓名、性別、年齡等，行為：衣、食、住、行等。

?

圖 5-1-1　對象的定義

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

　　對象可以定義為系統(tǒng)中用來描述客觀事物的一個實體，它是構(gòu)成系統(tǒng)的一個基本單位，由一組屬性和一組對屬性進(jìn)行操作的服務(wù)組成。

　　屬性一般只能通過執(zhí)行對象的操作來改變。

　　操作又稱為方法或服務(wù)，在C ++中稱為成員函數(shù)，它描述了對象執(zhí)行的功能，若通過消息傳遞，還可以為其他對象使用。

　　而所謂的消息是一個對象與另一個對象的通信單元，是要求某個對象執(zhí)行類中定義的某個操作的規(guī)格說明。發(fā)送給一個對象的消息定義了一個操作名和一個參數(shù)表（可能是空的），并指定某一個對象。由一個對象接收的消息則調(diào)用消息中指定的操作，并將傳遞過來的實際參數(shù)與參數(shù)表中相應(yīng)的形式參數(shù)結(jié)合起來。接收對象對消息的處理可能會改變對象中的狀態(tài)，即改變接收對象的屬性，并發(fā)送一個消息給自己或另一個對象。可以認(rèn)為，這種消息的傳遞大致等價于過程性范型中的函數(shù)調(diào)用。

　　（2）對象的分類

　　·外部實體：與軟件系統(tǒng)交換信息的外部設(shè)備、相關(guān)子系統(tǒng)、操作員或用戶等。

　　·信息結(jié)構(gòu) ：問題信息域中的概念實體 ，如信號、報表、顯示信息等。

　　·需要記憶的事件：在系統(tǒng)運行過程中可能產(chǎn)生并需要系統(tǒng)記憶的事件，如單擊鼠標(biāo)左鍵、擊打鍵盤“?”鍵等。

　　·角色：與軟件系統(tǒng)交互的人員所扮演的角色，如經(jīng)理、部長、技術(shù)支持等。

　　·組織機構(gòu)：有關(guān)機構(gòu)，如單位、小組等。

　　·位置：作為系統(tǒng)環(huán)境或問題上下文的場所、位置，如客戶地址、收件人（機構(gòu)）地址等。

　　·操作規(guī)程：如操作菜單、某種數(shù)據(jù)輸入過程等。

　　在標(biāo)識對象時必需注意遵循“信息隱蔽”的原則：必需將對象的屬性隱藏在對象的內(nèi)部，使得從對象的外部看不到對象的信息是如何定義的，只能通過該對象界面上的操作來使用這些信息。對象的狀態(tài)通過給對象賦予具體的屬性值而得到。它只能通過該對象的操作來改變。

　　對象有兩個視圖，分別表現(xiàn)在分析設(shè)計和實現(xiàn)方面。從分析及設(shè)計方面來看 ，對象表示了一種概念 ，它們把有關(guān)的現(xiàn)實世界的實體模型化。從實現(xiàn)方面來看，一個對象表示了在應(yīng)用程序中出現(xiàn)的實體的實際數(shù)據(jù)結(jié)構(gòu)。之所以有兩個視圖，是為了把說明與實現(xiàn)分離，對數(shù)據(jù)結(jié)構(gòu)和相關(guān)操作的實現(xiàn)進(jìn)行封裝。

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

　　把具有相同特征和行為的對象歸在一起就形成了類。類成為某些對象的模板，抽象地描述了屬于該類的全部對象的屬性和操作。屬于某個類的對象叫做該類的實例。對象的狀態(tài)則包含在它的實例變量，即實例的屬性中。如圖 5-1-2所示。從“李杰”、“王輝”和“楊芳”等對象可得到類“學(xué)生”，而這些對象就稱為該類的實例。

?

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

　　類定義了各個實例所共有的結(jié)構(gòu)，類的每一個實例都可以使用類中定義的操作。實例的當(dāng)前狀態(tài)是由實例所執(zhí)行的操作定義的。

　　面向?qū)ο蟪绦蛟O(shè)計語言，如C++和 smalltalk都定義了一個new操作，可建立一個類的新實例。C++ 還引入了構(gòu)造函數(shù)，用它在聲明一個對象時建立實例。此外，程序設(shè)計語言給出了不同的方法，來撤消（稱為析構(gòu)）實例，即當(dāng)某些對象不再使用時把它們刪去，把存儲釋放以備其他對象使用。C++給出了一個操作delete，可以釋放一個對象所用的空間。C++還允許每個類定義自己的析構(gòu)方法，在撤消一個對象時調(diào)用它。smalltalk 沒有提供一個機制來撤消對象，但可以進(jìn)行無用單元收集。

　　類常常可看做是一個抽象數(shù)據(jù)類型（ADT）的實現(xiàn) 。但更重要的是把類看做是表示某種概念的一個模型。事實上，類是單個的語義單元，它可以很自然地管理系統(tǒng)中的對象，匹配數(shù)據(jù)定義與操作。類加進(jìn)了操作，給通常的記錄賦予了語義，可提供各種級別的可訪問性。

　　3.繼承 （inheritance）

　　如果某幾個類之間具有共性的東西（信息結(jié)構(gòu)和行為），抽取出來放在一個一般類中，而將各個類的特有的東西放在特殊類中分別描述，則可建立起特殊類對一般類的繼承，如圖 5-1-3所示。各個特殊類可以從一般類中繼承共性，這樣避免了重復(fù)。

?

圖 5-1-3　特殊類對一般類的繼承關(guān)系

　　建立繼承結(jié)構(gòu)的好處：

　　·易編程、易理解 代碼短, 結(jié)構(gòu)清晰；

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

　　·易增加新類：只須描述不同部分。

　　4.多繼承

　　如果一個類需要用到多個既存類的特征，可以從多個類中繼承，稱為多繼承。例如退休教師是繼承退休者和教師這兩個類的某些特征或行為而得到的一個新類。

?

圖 5-1-4　多繼承

　　5.多態(tài)性和動態(tài)綁定

　　對象互相通信，即一個對象發(fā)消息給另一個對象，執(zhí)行某些行為或又發(fā)消息給另外的對象，從而執(zhí)行系統(tǒng)的功能。

　　發(fā)送消息的對象可能不知道另一個對象的類型是什么。如在 C程序中使用命令ClearInt （） 時要嚴(yán)格區(qū)分該命令適合一個整數(shù)，還是一個整數(shù)數(shù)組。但在C++情形，ClearInt （）對兩者都適用，它自己判斷對象是哪一個。

　　這就是多態(tài)性。它意味 著一個操作 在不同類中可以有不同的實現(xiàn)方式。如清零操作 ClearInt （ ） 針對消息對象是 int array 還是int，其實現(xiàn)是不同的。在一個面向?qū)ο蟮亩鄳B(tài)性語言中，可能代替一個特定類型的類型的集合就是它的子類集合。

　　例如，圖 5-1-5給出了 4個類的繼承層次。使用這個繼承結(jié)構(gòu)，發(fā)送給多邊形類的所有消息，它的所有子類都能夠響應(yīng)。又例如，想要在屏幕上畫一系列多邊形，多態(tài)性允許一個表的元素可以屬于一組指定的類型而不僅僅是一個類型，可以認(rèn)為這是一個類族。通過遍歷這個表，發(fā)送給各個表元素以draw消息，畫出所有的多邊形。

?

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

　　動態(tài)綁定把函數(shù)調(diào)用與目標(biāo)代碼塊的連接延遲到運行時進(jìn)行。這樣，只有發(fā)送消息時才與接收消息實例的一個操作綁定。它與多態(tài)性可以使我們建立的系統(tǒng)更靈活，易于擴充。做為動態(tài)綁定的例子，考慮在多邊形類中的方法contains ? （aPoint） 。這個操作可以在類層次的各層重新實現(xiàn)，以有效利用各個子類的特殊的特征。例如，假定一個矩形有某些邊與屏幕的邊平行，這時，檢查一個點是否包含在矩形內(nèi)，比檢查一個點是否在一個一般的四邊形內(nèi)的效率要高一些。

二、面向?qū)ο筌浖_發(fā)的分析模型

　　面向?qū)ο蠓治鲞^程分為論域分析和應(yīng)用分析。論域分析建立大致的系統(tǒng)實現(xiàn)環(huán)境，應(yīng)用分析則根據(jù)特定應(yīng)用的需求進(jìn)行論域分析。

　　1.OOA分析的基本原則和任務(wù)

　　為建立分析模型，要運用如下的5個基本原則 ：①建立信息域模型；②描述功能；③表達(dá)行為；④劃分功能 、數(shù)據(jù) 、行為模型，揭示更多的細(xì)節(jié)；⑤用早期的模型描述問題的實質(zhì)，用后期的模型給出實現(xiàn)的細(xì)節(jié)。這些原則形成OOA的基礎(chǔ)。

　　OOA的目的是定義所有與待解決問題相關(guān)的類（包括類的操作和屬性、類與類之間的關(guān)系以及它們表現(xiàn)出的行為）。為此，OOA需完成的任務(wù)是：

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

　　（2）必須標(biāo)識類（即定義其屬性和操作）；

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

　　（4）應(yīng)當(dāng)表達(dá)對象與對象之間的關(guān)系（即對象的連接）；

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

　　（6）反復(fù)地做任務(wù)①～⑤，直到模型建成。

　　2.OOA概述

　　目前已經(jīng)衍生許多種 OOA方法。每種方法都有各自的進(jìn)行產(chǎn)品或系統(tǒng)分析的過程，有一組可描述過程演進(jìn)的圖形標(biāo)識，以及能使得軟件工程師以一致的方式建立模型的符號體系。現(xiàn)在廣泛使用的OOA方法有以下幾種：

　　（1） Booch 方法：Booch 方法包含“ 微開發(fā)過程 ”和“宏開發(fā)過程”。微開發(fā)過程定義了一組任務(wù)，并在宏開發(fā)過程的每一步驟中反復(fù)使用它們，以維持演進(jìn)途徑。Booch OOA 宏開發(fā)過程的任務(wù)包括標(biāo)識類和對象、標(biāo)識類和對象的語義、定義類與對象間的關(guān)系，以及進(jìn)行一系列求精從而實現(xiàn)分析模型。

　　（2） Rumbaugh 方法：Rumbaugh 和他的同事提出的對象模型化技術(shù)（OMT）用于分析、系統(tǒng)設(shè)計和對象級設(shè)計 。分析活動建立三個模型：對象模型（描述對象、類、層次和關(guān)系），動態(tài)模型（描述對象和系統(tǒng)的行為），功能模型（類似于高層的DFD，描述穿越系統(tǒng)的信息流）。

　　（3） Coad和Yourdon 方法：Coad和Yourdong方法常常被認(rèn)為是最容易學(xué)習(xí)的OOA 方法。建模符號相當(dāng)簡單，而且開發(fā)分析模型的導(dǎo)引直接明了。其OOA過程概述如下：

　　·使用“要找什么”準(zhǔn)則標(biāo)識對象；

　　·定義對象之間的一般化∕特殊化結(jié)構(gòu)；

　　·定義對象之間的整體∕部分結(jié)構(gòu)；

　　·標(biāo)識主題（系統(tǒng)構(gòu)件的表示）；

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

　　·定義服務(wù)及對象之間的消息連接。

　　（4） Jacobson方法：也稱為OOSE（面向?qū)ο筌浖こ?#xff09;。Jacobson方法與其他方法的不同之處在于他特別強調(diào)使用實例（use case）——用以描述用戶與系統(tǒng)之間如何交互的場景。Jacobson方法概述如下：

　　·標(biāo)識系統(tǒng)的用戶和它們的整體責(zé)任；

　　·通過定義參與者及其職責(zé)、使用實例、對象和關(guān)系的初步視圖，建立需求模型；

　　·通過標(biāo)識界面對象、建立界面對象的結(jié)構(gòu)視圖、表示對象行為、分離出每個對象的子系統(tǒng)和模型，建立分析模型。

　　（5） Wirfs―Brock 方法：Wirfs―Brock 方法不明確區(qū)分分析和設(shè)計任務(wù) 。從評估客戶規(guī)格說明到設(shè)計完成 ，是一個連續(xù)的過程 。與Wirfs―Brock分析有關(guān)的任務(wù)概述如下：

　　·評估客戶規(guī)格說明；

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

　　·將類分組以表示超類；

　　·定義每一個類的職責(zé)；

　　·將職責(zé)賦予每個類；

　　·標(biāo)識類之間的關(guān)系；

　　·基于職責(zé)定義類之間的協(xié)作；

　　·建立類的層次表示；

　　·構(gòu)造系統(tǒng)的協(xié)作圖。

　　（6） 統(tǒng)一的OOA方法（UML） 。統(tǒng)一的建模語言（UML）已經(jīng)在企業(yè)中廣泛使用，它把Booch、Rumbaugh和Jacobson 等各自獨立的OOA和OOD方法中最優(yōu)秀的特色組合成一個統(tǒng)一的方法。UML 允許軟件工程師使用由一組語法的語義的實用的規(guī)則支配的符號來表示分析模型。

　　在UML中用5種不同的視圖來表示一個系統(tǒng)，這些視圖從不同的側(cè)面描述系統(tǒng)。每一個視圖由一組圖形來定義。這些視圖概述如下：

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

　　·結(jié)構(gòu)模型視圖 ：從系統(tǒng)內(nèi)部來看 數(shù)據(jù)和功能性 。即對 靜態(tài)結(jié)構(gòu)（類、對象和關(guān)系）模型化。

　　·行為模型視圖：這種視圖表示了系統(tǒng)動態(tài)和行為。它還描述了在用戶模型視圖和結(jié)構(gòu)模型視圖中所描述的各種結(jié)構(gòu)元素之間的交互和協(xié)作。

　　·實現(xiàn)模型視圖：將系統(tǒng)的結(jié)構(gòu)和行為表達(dá)成為易于轉(zhuǎn)換為實現(xiàn)的方式。

　　·環(huán)境模型視圖：表示系統(tǒng)實現(xiàn)環(huán)境的結(jié)構(gòu)和行為。

　　通常，UML 分析建模的注意力放在系統(tǒng)的用戶模型和結(jié)構(gòu)模型視圖，而UML設(shè)計建模則定位在行為模型、實現(xiàn)模型和環(huán)境模型。

第二節(jié)　UML概述

　　一、UML的語言機制

　　在UML 誕生之前，面向?qū)ο箢I(lǐng)域已經(jīng)涌現(xiàn)出了許多開發(fā)方法及相應(yīng)的表示機制，它們各有千秋 ，卻又有很多類似之處 ，往往讓使用者無所適從。UML在這樣的背景下應(yīng)運而生。它主要以BOOCH 方法、OMT方法（71）和OOSE方法為基礎(chǔ)，同時也吸收了其他面向?qū)ο蠼７椒ǖ膬?yōu)點，形成一種概念清晰、表達(dá)能力豐富、適用范圍廣泛的面向?qū)ο蟮臉?biāo)準(zhǔn)建模語言。

　　UML 通過圖形化的表示機制從多個側(cè)面對系統(tǒng)的分析和設(shè)計模型進(jìn)行刻畫。它共定義了10種視圖，并將其分為如下4類：

　　（1）用例圖（use case diagram） 。從外部用戶的角度描述系統(tǒng)的功能，并指出功能的執(zhí)行者。

　　（2）靜態(tài)圖。包括類圖（class diagram）、對象圖（object diagram） 和包圖（pack diagram）。類圖描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，類圖的節(jié)點表示系統(tǒng)中的類及其屬性和操作，類圖的邊表示類之間的聯(lián)系，包括繼承、關(guān)聯(lián)、依賴、聚合等。對象圖是類圖一個實例，它描述在某種狀態(tài)下或在某一時間段，系統(tǒng)中活躍的對象及其關(guān)系。在對象圖，一個類可以擁有多個活躍的對象實例。包圖描述系統(tǒng)的分解結(jié)構(gòu)，它表示包(package)以及包之間的關(guān)系。包由子包及類組成。包之間的關(guān)系包括繼承、構(gòu)成與依賴關(guān)系。

　　（3）行為圖。包括交互圖（interactive diagram）、狀態(tài)圖（statechar diagram） 與活動圖（activity diagram），它們從不同的側(cè)面刻畫系統(tǒng)的動態(tài)行為。交互圖描述描述對象之間的消息傳遞，它又可分為順序圖（sequence diagram）與 合作圖（collaboration diagram）兩種形式。順序圖強調(diào)對象之間消息發(fā)送的時間序。合作圖更強調(diào)對象間的動態(tài)協(xié)作關(guān)系。合作圖也可通過消息序號之間消息發(fā)送的時間序。只不過這種表示不如順序圖那樣直觀 。狀態(tài)圖描述類的對象的動態(tài)行為 ，它包含對象所有可能的狀態(tài)、在每個狀態(tài)下能夠響應(yīng)的事件以及事件發(fā)生時的狀態(tài)遷移與響應(yīng)動作。活動圖描述系統(tǒng)為完成某項功能而執(zhí)行的操作序例，這些操作序列可以并發(fā)和同步。活動圖中包含控制和信息流。控制流表示一個操作完成后對其后操作的觸發(fā)，信息流則刻畫操作之間的信息交換。

　　（4）實現(xiàn)圖（implementatin diagram）。包括構(gòu)件圖（component diagram）與 部署圖（deploymetn diagram），它們描述軟件實現(xiàn)系統(tǒng)的組成和分布狀況。構(gòu)件圖描述軟件實現(xiàn)系統(tǒng)中各組成部件以及它們之間的信賴關(guān)系。一個部件可能是一個資源描述文件、一個二進(jìn)制文件或一個可執(zhí)行文件。構(gòu)件圖主要用于理解和分析軟件各部分之間的相互影響程度。部署圖描述作為軟件系統(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)系。部署圖對于軟件安裝工程師有著重要的參考價值。

　　例如，圖5-2-1表示某大學(xué)的課程注冊管理系統(tǒng)包含3個用例：“課表維護”、“個人課程規(guī)劃”和“選課學(xué)生花名冊查詢”。教務(wù)管理人員使用“課表維護”用例設(shè)置或修改課程屬性（課程的時間、地點、上課老師等）和增刪課程；學(xué)生使用“個人課程規(guī)劃”用例選課和修改自己的個人課表，收費管理系統(tǒng)根據(jù)每個學(xué)生的選課情況計算其應(yīng)繳費用；老師使用“選課學(xué)生花名冊查詢”用例獲取選定其所開課程的學(xué)生花名冊。

圖 5-2-1　課程注冊管理系統(tǒng)的用例圖

　　圖 5-2-2表示前述的課程注冊管理系統(tǒng)包含“教務(wù)管理人員”、“學(xué)生”、“老師”、“課程”、“課程設(shè)置”、“課程注冊表”、“課程注冊管理器”和“課程管理器”8個類。前3個類為一般化的“用戶”類的子類。一門“課程”可由一到多個“課程設(shè)置”構(gòu)成，例如，對于全校性的公共基礎(chǔ)課，由于選修的學(xué)生太多，必須安排不同的老師、不同的教室和不同的時間段。“學(xué)生” 、“老師”與“課程設(shè)置”之間 ，“課程注冊表”與“課程注冊管理器”之間以及“課程注冊管理器”與“課程”之間存在著關(guān)聯(lián)關(guān)系。

圖 5-2-2　課程注冊管理系統(tǒng)的類圖

　　圖5-2-3通過UML順序圖刻畫了“個人課程規(guī)劃”用例中學(xué)生選課功能的實現(xiàn)過程。

圖 5-2-3　用UML順序圖表示“個人課程規(guī)劃”用例中的學(xué)生選課過程

　　圖 5-2-4用UML協(xié)作圖刻畫學(xué)生選課過程，該圖與圖 5-2-3等價。

圖 5-2-4　用UML協(xié)作圖表示“個人課程規(guī)劃”用例中的學(xué)生選課過程

　　圖 5-2-5“課程設(shè)置”對象的狀態(tài)圖。它表示每個“課程設(shè)置”最多只能容納50個選課學(xué)生。

圖 5-2-5　UML狀態(tài)圖示例

　　本章的后繼章節(jié)結(jié)合需求分析過程更具體地介紹UML的用例圖、包圖、類圖和活動圖，第八章將結(jié)合軟件設(shè)計過程詳細(xì)介紹順序圖、協(xié)作圖、狀態(tài)圖和活動圖。對其他UML 圖形機制感興趣的讀者，以及希望進(jìn)一步深入了解UML 及其軟件開發(fā)方法的讀者。

　　二、基于UML的軟件開發(fā)過程

　　雖然UML是獨立于軟件開發(fā)過程的，即UML能夠在幾乎任何一種軟件開發(fā)過程中使用，但是熟悉一種有代表性的面向?qū)ο蟮能浖_發(fā)過程，并知悉UML 各語言要素在過程中不同階段的應(yīng)用，對于理解UML將大有裨益。

　　圖 5-2-6表示一種迭代的漸進(jìn)式軟件開發(fā)過程，它包含4個階段：初啟、細(xì)化、構(gòu)造和移交。

圖 5-2-6　面向?qū)ο蟮牡u進(jìn)式軟件開發(fā)過程

　　1.初啟

　　在初啟階段，軟件項目的發(fā)起人確定項目的主要目標(biāo)和范圍，并進(jìn)行初步的可行性分析和經(jīng)濟效益分析。

　　2.細(xì)化

　　細(xì)化階段的開始標(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)域模型。領(lǐng)域模型一方面可以幫助軟件項目組理解業(yè)務(wù)背景，與業(yè)務(wù)專家進(jìn)行有效溝通；另一方面，隨著軟件開發(fā)階段的不斷推進(jìn)，領(lǐng)域模型將成為軟件結(jié)構(gòu)的主要基礎(chǔ)。如果領(lǐng)域中含有明顯的流程處理成分，可以考慮利用 UML的活動圖來刻畫領(lǐng)域中的工作流，并標(biāo)識業(yè)務(wù)流程中的并發(fā)、同步等特征。

　　（2）初步的高層設(shè)計 。如果目標(biāo)軟件系統(tǒng)的規(guī)模比較龐大，那么經(jīng)初步需求分析獲得的用例和類將會非常多。此時，可以考慮根據(jù)用例、類在業(yè)務(wù)領(lǐng)域中的關(guān)系，或者根據(jù)業(yè)務(wù)領(lǐng)域中某種有意義的分類方法將整個軟件系統(tǒng)劃分為若干包，利用UML的包圖刻畫這些包及其間的關(guān)系。這樣，用例、用例圖、類、類圖將依據(jù)包的劃分方法分屬于不同的包，從而得到整個目標(biāo)軟件系統(tǒng)的高層結(jié)構(gòu)。

　　（3）部分的詳細(xì)設(shè)計 。對于系統(tǒng)中某些重要的或者比較高的用例，可以采用交互圖進(jìn)一步探討其內(nèi)部實現(xiàn)過程 。同樣 ，對于系統(tǒng)中的關(guān)鍵類，也可以詳細(xì)研究其屬性和操作，并在UML 類圖中加以表現(xiàn)。因此，這里倡導(dǎo)的軟件開發(fā)過程并不在時間軸上嚴(yán)格劃分分析與設(shè)計、總體設(shè)計與詳細(xì)設(shè)計，而是根據(jù)軟件元素（用例、類等）的重要性和風(fēng)險程度確立優(yōu)先細(xì)化原則，建議軟件項目組優(yōu)先考慮重要的、比較有風(fēng)險的用例和類，不能將風(fēng)險的識別和解決延遲到細(xì)化階段之后。

　　（4）部分的原型構(gòu)造。在許多情形下 ，針對某些復(fù)雜的用例構(gòu)造可實際運行的耐用消費品型是降低技術(shù)風(fēng)險、讓用戶幫助軟件項目組確認(rèn)用戶需求的最有效的方法 。為了構(gòu)造原型 ，需要針對用例生成詳盡的交互圖，對所有相關(guān)類給出明確的屬性和操作定義。

　　綜上所述，在細(xì)化階段可能需要使用的UML 語言機制包括：描述用戶需求的用例用用例圖、表示領(lǐng)域概念模型的類圖、表示業(yè)務(wù)流程處理的活動圖、表示系統(tǒng)高層結(jié)構(gòu)的包圖和表示用例內(nèi)部實現(xiàn)過程的交互圖等。

　　細(xì)化階段的結(jié)束條件是，所有主要的用戶需求已通過用例和用例圖得以描述；所有重要的風(fēng)險已被標(biāo)識，并對風(fēng)險應(yīng)對措施了如指掌；能夠比較精確地估算實現(xiàn)每一用例的時間。

　　3.構(gòu)造

　　在構(gòu)造階段，開發(fā)人員通過一系列的迭代完成對所有用例的軟件實現(xiàn)工作，在每次迭代中實現(xiàn)一部分用例。以迭代方式實現(xiàn)所有用例的好處在于，用戶可以及早參與對已實現(xiàn)用例的實際評價，并提出改進(jìn)意見。這樣可有效降低大型軟件系統(tǒng)的開發(fā)風(fēng)險。

　　在實際開始構(gòu)造軟件系統(tǒng)之前，有必要預(yù)先制定迭代計劃。計劃的制定需遵循如下兩項原則：

　　（1）用戶變?yōu)闃I(yè)務(wù)價值較大的用例應(yīng)優(yōu)先安排；

　　（2）開發(fā)人員評估后認(rèn)為開發(fā)風(fēng)險較高的用例應(yīng)優(yōu)先安排。

　　在迭代計劃中，要確定迭代次數(shù)、每次迭代所需時間以及每次迭代中應(yīng)完成（或部分完成）的用例。

　　每次迭代過程由針對用例的分析、設(shè)計、編碼、測試和集成 5個子階段構(gòu)成。在集成之后，用戶可以對用例的實現(xiàn)效果進(jìn)行評價，并提出修改意見。這些修改意見可以在本次迭代過程中立即實現(xiàn)，也可以在下次迭代中再予以考慮。

　　構(gòu)造過程中，需要使用UML 的交互圖來設(shè)計用例的實現(xiàn)方法。為了與設(shè)計得出的交互圖協(xié)調(diào)一致，需要修改或精化在細(xì)化階段繪制的作為領(lǐng)域模型的類圖，增加一些為軟件實現(xiàn)所必需的類、類的屬性或方法。

　　如果一個類有復(fù)雜的生命周期行為，或者類的對象在生命周期內(nèi)需要對各種外部事件的刺激作出反應(yīng)，應(yīng)考慮用 UNL狀態(tài)圖來表述類的對象的行為。

　　UML的活動圖可以在構(gòu)造階段用來表示復(fù)雜的算法過程和有多個對象參與的業(yè)務(wù)處理過程。活動圖尤其適用于表示過程中的并發(fā)和同步。

　　在構(gòu)造階段的每次迭代過程中，可以對細(xì)化階段繪出的懈圖進(jìn)行修改或精化，以便包圖切實反映目標(biāo)軟件系統(tǒng)最頂層的結(jié)構(gòu)劃分狀況。

　　綜上所核對，在構(gòu)造階段可能需要使用的UML語言機制包括：

　　用例及用例圖。它們是開發(fā)人員在構(gòu)造階段進(jìn)行分析和設(shè)計的基礎(chǔ)。

　　類圖。在領(lǐng)域概念模型的基礎(chǔ)上引進(jìn)為軟件實現(xiàn)所必需的類、屬性和方法。

　　交互圖。表示針對用例設(shè)計的軟件實現(xiàn)方法。

　　狀態(tài)圖。表示類的對象的狀態(tài)—事件—響應(yīng)行為。

　　活動圖。表示復(fù)雜的算法過程，尤其是過程中的并發(fā)和同步。

　　包圖。表示目標(biāo)軟件系統(tǒng)的頂層結(jié)構(gòu)。

　　構(gòu)件圖。

　　部署圖。

　　4.移交

　　在移交階段，開發(fā)人員將構(gòu)造階段獲得的軟件系統(tǒng)在用戶實際工作環(huán)境（或接近實際的模擬環(huán)境）中試運行，根據(jù)用戶的修改意見進(jìn)行少量調(diào)整。

第三節(jié)　基于UML的需求分析

　　在初步的業(yè)務(wù)需求描述已經(jīng)形成的前提下 ，基于UML的需求分析大致可分為以下步驟：

　　（1）利用用例及用例圖表示需求 。從業(yè)務(wù)需求描述出發(fā)獲取執(zhí)行者和場景；對場景進(jìn)行匯總、分類、抽象；形成用例；確定執(zhí)行者與用例、用例與用例圖之間的關(guān)系，生成用例圖。

　　（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)系，生成類圖。

　　上述兩個步驟并沒有時序關(guān)系，它們可以并行展開，如圖5-3-1所示。

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

　　本節(jié)將依次介紹上述步驟中涉及的UML語言機制，并結(jié)合“家庭保安系統(tǒng)”實例說明每步驟中基于UML的需求分析方法。

　　一、開發(fā)場景

　　場景是指從單個執(zhí)行者的角度觀察目標(biāo)軟件系統(tǒng)的功能和外部行為。這種功能通過系統(tǒng)與用戶之間的交互來表征。因此也可以說，場景是用戶與系統(tǒng)之間進(jìn)行交互的一組具體的動作。相對于用例（見第五章第二節(jié)）而言，場景是用例的實例，而用例是某類場景的共同抽象。

　　對場景的完整描述應(yīng)包含場景名稱、執(zhí)行者實例，前置條件、事件流和后置條件。

　　例如，“家庭保安系統(tǒng)”的初步需求描述：“家庭保安系統(tǒng)”的軟件允許用戶在安裝時進(jìn)行系統(tǒng)配置，實施對傳感器的監(jiān)控并通過控制面板與用戶進(jìn)行信息交互。

　　配置操作包括：

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

　　（2）設(shè)置開、關(guān)機密碼；

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

　　（4）指定報警延遲和電話重?fù)苎舆t時間（以秒為單位）；

　　當(dāng)軟件系統(tǒng)收到傳感器發(fā)出的數(shù)據(jù)后，判別是否出現(xiàn)異常事件。如果是，則在指定的延遲時間內(nèi)撥報警電話號碼，撥號操作將按照重?fù)苎舆t反復(fù)進(jìn)行，直至電話接通。然后軟件系統(tǒng)負(fù)責(zé)報告時間、地點和異常事件的性質(zhì)。

　　開機后，軟件系統(tǒng)負(fù)責(zé)顯示當(dāng)前工作狀態(tài)，接收并處理用戶指令。

　　根據(jù)以上描述，該系統(tǒng)具有“系統(tǒng)配置” 、“開機” 、“關(guān)機”、“門窗監(jiān)測”、“煙霧監(jiān)測”和“復(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)。

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

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

　　（2）設(shè)想場景。 分析人員對目標(biāo)軟件系統(tǒng)投入應(yīng)用后經(jīng)改進(jìn)或優(yōu)化的業(yè)務(wù)流程的描述。這種場景可視為一種紙面原型，主要用于幫助分析人員挖掘潛在的用戶需求。

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

　　（4）培訓(xùn)場景。 面向開發(fā)人員及用戶解釋系統(tǒng)的功能和外部行為的業(yè)務(wù)流程描述。

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

　　（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í)行者哪些事件？

　　總之，確定執(zhí)行者和場景的關(guān)鍵在于理解業(yè)務(wù)領(lǐng)域和初步需求描述文檔。場景將促成開發(fā)人員和用戶對業(yè)務(wù)處理流程和目標(biāo)軟件系統(tǒng)的功能范圍的共同理解。在場景確定之后，通過對場景的匯總、分類歸并和抽象即可形成用例。

　　二、生成用例

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

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

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

　　在“家庭保安系統(tǒng)”中，執(zhí)行者有“用戶”、“傳感器”、“報警電話”和“顯示器” ，用例有“系統(tǒng)配置” 、“命令響應(yīng)”和“傳感器監(jiān)測”。下面以“傳感器監(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)（報警）。

　　輔事件流：

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

　　（2）如果重?fù)艽螖?shù)達(dá)到系統(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)。

　　三、用活動圖表示用例

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

　　1.UML活動圖

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

?

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

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

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

　　2.用例的活動圖表示

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

?

圖 5-3-3　“傳感器監(jiān)測”用例的活動圖表示

　　四、生成用例圖

　　執(zhí)行者與用例之間的關(guān)系有兩例種：觸發(fā)執(zhí)行與信息交換。執(zhí)行者與用例之間可能兼具這兩種關(guān)系，例如，“ 在家庭保安系統(tǒng) ”中，執(zhí)行者“用戶”在觸發(fā)用例“命令響應(yīng)”的同時，還要向用例傳送命令信息。

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

　　UML的用例與用例之間存在如下兩種關(guān)系：

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

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

?

圖 5-3-4　“家庭保安系統(tǒng)”的用例圖

　　五、建立頂層架構(gòu)

　　頂層架構(gòu)的 主要目的是為后續(xù)的分析 和設(shè)計活動建立一種結(jié)構(gòu)和分劃 ，以便開發(fā)人員在不同的開發(fā)階段 ，以及同一開發(fā)階段的不同開發(fā)人員，能夠聚焦于系統(tǒng)的不同部分。頂層架構(gòu)是分析和設(shè)計的階段成果的承載體。隨著開發(fā)過程的推進(jìn)，框架中的內(nèi)容不斷豐富、翔實，最終演進(jìn)為完整的面向?qū)ο筌浖Y(jié)構(gòu)。

　　UML 包圖是表示頂層架構(gòu)的適當(dāng)機制，因此，下面首先介紹包圖的語法機制，然后探討建立頂層架構(gòu)的方法與原則。

　　1.UML包圖

　　包是UML 對類進(jìn)行分組的一種機制。可以從某種視角將具有比較密切的關(guān)聯(lián)的一些類劃分為一個包，分屬于不同包的兩個類之間的關(guān)聯(lián)則比較松散。由此可見，對于大型軟件系統(tǒng)而言，包的劃分是實現(xiàn)“分而治之”的重要技術(shù)手段。

　　包之間存在兩種關(guān)系：依賴和構(gòu)成。如果對類A的修改將導(dǎo)致類B的改變，則稱B依賴于A。如果兩個包中存在具有依賴關(guān)系的兩個類，則認(rèn)為這兩個類分屬的包之間存在依賴關(guān)系。例如，圖 5-3-5中的“訂單”包依賴于“ 客戶 ”包。包的構(gòu)成關(guān)系是指包是可以嵌套的，即包中不僅可包含類，還可以包含子包。在圖 5-3-5中，“領(lǐng)域”包由“訂單”和“客戶”兩個子包構(gòu)成。圖 5-3-5中，“數(shù)據(jù)庫接口”類僅定義抽象的數(shù)據(jù)訪問、數(shù)據(jù)操作的接口函數(shù)，而“Oracle接口” 包和“DB2接口”包則基于具體的數(shù)據(jù)庫管理系統(tǒng)逐一實現(xiàn)了通用接口中定義的抽象接口函數(shù)。

?

圖 5-3-5　包圖示例

　　為了表示軟件架構(gòu)，還需要在包之間引進(jìn)一種稱為“連接器”的邊。連接器用來表示包之間的信息傳遞、事件發(fā)送和軟件調(diào)用等關(guān)系，且有單向和雙向（即無向）之分。

　　2.軟件頂層架構(gòu)的設(shè)計

　　建立軟件系統(tǒng)頂層架構(gòu)的基本方法是，結(jié)合實際需求，從既往的架構(gòu)設(shè)計經(jīng)驗?zāi)Ｐ椭羞x取適當(dāng)者，再進(jìn)行微調(diào)或局部改造。目前有如下幾種主要的架構(gòu)模式：

　　（1）流程處理模式 。流程處理系統(tǒng)以算法和數(shù)據(jù)引進(jìn)中心，其系統(tǒng)功能由一系列的處理步驟構(gòu)成，相鄰的處理步驟之間以數(shù)據(jù)流通管道相互連接。

　　圖5-3-6表示具有3處理步驟的流程處理模式。這些處理步驟都使用公共的系統(tǒng)服務(wù)（例如數(shù)據(jù)庫訪問服務(wù)），處理命令來自用戶界面，處理的進(jìn)度和結(jié)果也通過用戶界面呈現(xiàn)。

?

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

　　流程處理模式僅適合于采用批處理方式的軟件系統(tǒng)，不適合于交互式系統(tǒng)。

　　（2）客戶／服務(wù)器模式。如圖5-3-7所示，客戶端負(fù)責(zé)用戶輸入和處理結(jié)果的呈現(xiàn)，服務(wù)器端則負(fù)責(zé)后臺的業(yè)務(wù)邏輯處理。

?

圖 5-3-7　客戶／服務(wù)器模式

　　（3）模型—視圖—控制器（MVC）模式。如圖 5-3-8所示，該模式將整個軟件系統(tǒng)劃分為模型，視圖和控制器 3個部分。模型負(fù)責(zé)維護并保存具有持久性的業(yè)務(wù)數(shù)據(jù)，實現(xiàn)業(yè)務(wù)處理功能，并將業(yè)務(wù)數(shù)據(jù)的變化情況及時通知視圖；視圖負(fù)責(zé)呈現(xiàn)模型的業(yè)務(wù)數(shù)據(jù)，響應(yīng)模型變化通知，更新呈現(xiàn)形式，并向控制器傳遞用戶的界面動作；控制器負(fù)責(zé)將用戶的界面動作映射為模型中業(yè)務(wù)處理功能并實際調(diào)用之，然后根據(jù)模型返回的業(yè)務(wù)處理結(jié)果選擇新的視圖。MVC模式特別適合于分布應(yīng)用軟件，尤其是Web應(yīng)用系統(tǒng)。

?

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

　　（4）分層模式。如圖5-3-9所示，分層模式將整個軟件系統(tǒng)分為若干層次，最頂層直接面向用戶提供軟件系統(tǒng)的操作界面，其余各層為緊鄰其上的層次提供服務(wù)。層次劃時分的主要原則是：較易變化的軟件部分（例如用戶界面、與業(yè)務(wù)邏輯緊密相關(guān)的部件）置于較高層次，較穩(wěn)定的軟件部分（例如公共的技術(shù)服務(wù)部件）則位于較低層次；每一層次盡量只訪問其緊鄰下層提供的服務(wù)，避免越級訪問，尤其要避免逆向訪問（上層模塊為下層模塊提供服務(wù)）；在許多情況下，可以將目標(biāo)軟件系統(tǒng)的外部接口置入較低層次，目標(biāo)軟件系統(tǒng)其余部分對外部系統(tǒng)的訪問或操作均通過這些外部接口所提供的公共服務(wù)來完成。分層模式可以有效地降低軟件系統(tǒng)的耦合度，因此其應(yīng)用十分普遍。

?

圖 5-3-9　分層模式

　　在全面了解軟件架構(gòu)樣式的前提下，對于具體的應(yīng)用需求而言，影響頂層架構(gòu)選取的主要因素在于分析人員的經(jīng)驗以及他們對每種架構(gòu)樣式與當(dāng)前軟件項目之間匹配程度的判斷。事實上，大型軟件的頂層架構(gòu)往往需要復(fù)合使用多種架構(gòu)樣式。例如，整個目標(biāo)軟件系統(tǒng)采用分層結(jié)構(gòu)，在系統(tǒng)的不同層次內(nèi)再分別使用適宜的其他種類的架構(gòu)模式。

　　在確立頂層架構(gòu)的過程中，需綜合考慮以下因素：

　　（1）架構(gòu)中包的數(shù)量。 原則上，如果每個包中包含的軟件元素（例如類）的數(shù)量過多，應(yīng)考慮將其進(jìn)一步細(xì)分；如果過少，則說明架構(gòu)過早地陷入了細(xì)節(jié)，架構(gòu)劃分返工的可能性較大，同時也不合理地限制了后續(xù)分析和設(shè)計活動的自由空間。

　　（2）架構(gòu)中包之間的耦合度。 包之間的依賴關(guān)系和連接關(guān)系應(yīng)盡量簡單、稀疏，例如，在分層結(jié)構(gòu)中，通常要求某一層中的軟件元素只與同層及相鄰下一層的元素之間存在依賴關(guān)系。

　　（3）軟件元素的穩(wěn)定性。 要盡量抽取不穩(wěn)定的軟件元素之中相對穩(wěn)定的部分將不穩(wěn)定的軟件元素分類聚集于少數(shù)幾個包中，以提高軟件系統(tǒng)的可維護性。

　　（4）軟件元素的必然性。 可以將可選功能和必須實現(xiàn)的功能分置于架構(gòu)中不同的包或子包之中。

　　（5）作為軟件系統(tǒng)運行環(huán)境的物理網(wǎng)絡(luò)拓樸。 根據(jù)軟件元素在分布環(huán)境的部署情況區(qū)分頂層架構(gòu)中的包，可以使包之間的消息傳遞與物理節(jié)點之間的通信相吻合，使后續(xù)的分析和設(shè)計活動受益于頂層架構(gòu)中明確定義的通信關(guān)系。

　　（6）軟件元素的安全、保密級別。 根據(jù)安全訪問的權(quán)限劃分頂層架構(gòu)中的包或者子包。

　　（7）開發(fā)團隊的技術(shù)專長。 根據(jù)開發(fā)人員在問題領(lǐng)域和軟件技術(shù)領(lǐng)域不同的專長劃分頂層架構(gòu)中的包，使每個包都能分配給最適合的開發(fā)人員進(jìn)行后續(xù)的分析、設(shè)計、編碼和測試等，從而有利于并行開發(fā)。

　　六、建立領(lǐng)域概念模型

　　在用戶需求和相關(guān)的業(yè)務(wù)領(lǐng)域中，往往有一些全局性的概念對于理解需求至關(guān)重要。因此 ，有必要抽取這些概念 ，并研究這些概念之間的關(guān)系。

　　1．UML類圖

　　在UML中，用類表示概念，用類圖表示領(lǐng)域概念模型。

?

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

　　UML的類包含3個部分：類的名稱、屬性列表和方法列表，其表示圖元如圖5-3-10所示。在需求分析的早期不需要一次性列舉類的所有屬性和方法。剛開始可以僅標(biāo)識類名，以后隨著分析、設(shè)計的不斷推進(jìn)而逐步完善屬性列表和方法列表。

　　在UML中，類之間的關(guān)系的主要有繼承、聚集、關(guān)聯(lián)和依賴。

　　繼承關(guān)系表示子類重用父類的屬性的操作，子類的對象也是父類的對象，有時也稱父類是子類的泛化（generalization）。

　　例如，在課程管理系統(tǒng)中，“教務(wù)管理人員”、“學(xué)生”和“老師”都是泛化的“用戶”類的子類，它們繼承來自“用戶”類的用戶姓名、標(biāo)識碼、密碼等屬性以及用戶注冊、密碼驗證、退出系統(tǒng)等操作。

　　類之間的聚集關(guān)系是對現(xiàn)實世界中部分—整體關(guān)系的直接模擬。 UML將聚集關(guān)系進(jìn)一步細(xì)分為普通聚集和構(gòu)成關(guān)系兩種。在普通聚集關(guān)系中，一個部件類對象可同時參與多個整體類對象，構(gòu)成關(guān)系則限定一個部件類對象在任意時刻只能參與一個整體類對象，部件類對象與整體類對象共存亡。普通聚集和構(gòu)成關(guān)系的表示圖元如圖5-3-11所示。

圖 5-3-11　普通聚集和構(gòu)成關(guān)系的表示圖元

　　在概念上，關(guān)聯(lián)關(guān)系表示兩個類之間的相關(guān)性。從軟件設(shè)計和實現(xiàn)的角度看，關(guān)聯(lián)關(guān)系表示在兩個類的對象之間存在著一種用于消息傳遞的穩(wěn)定通道。例如，在課程注冊管理系統(tǒng)中，“學(xué)生”類、“老師”類與“課程設(shè)置”類之間存在關(guān)聯(lián)關(guān)系，因為“課程設(shè)置”肯定與選課學(xué)生和授課老師有關(guān)，學(xué)生和教師他都需要查詢課程設(shè)置中有關(guān)信息，如上課時間、地點和選課學(xué)生清單等。

　　參與聚集、構(gòu)成和關(guān)聯(lián)關(guān)系的兩個類的對象之間往往存在著數(shù)量對應(yīng)關(guān)系，這種關(guān)系是業(yè)務(wù)規(guī)則的具體表現(xiàn)。因此，當(dāng)分析和設(shè)計推進(jìn)到一定階段之后，應(yīng)該將這種數(shù)量對應(yīng)關(guān)系在這三種關(guān)系的表示邊上明確地標(biāo)示出來。例如，圖 5-3-2表示對于每個“課程設(shè)置”對象，選課學(xué)生應(yīng)不少于10個，不多于50個。每個學(xué)生在一個學(xué)期中所選的課程應(yīng)不少于 4門、不多于8門。

　　依賴關(guān)系是關(guān)聯(lián)關(guān)系的弱化 ，表示被依賴的 類的變化會影響到依賴類。依賴關(guān)系的起因有：依賴類的對象需要向被依賴害的對象傳遞消息；被依賴類作為依賴類的操作的形參類型。前一種情況不僅可以且依賴關(guān)系實現(xiàn)，也可以用關(guān)聯(lián)關(guān)系及強化形式（聚合和構(gòu)成）來實現(xiàn)。這兩種實現(xiàn)方法的區(qū)別在于，依賴關(guān)系僅表示一種臨時性的消息傳遞通道，一旦依賴類對象的操作完成，該通道立即消失；關(guān)聯(lián)關(guān)系及其強化形式則表示消息傳遞通道在整個對象的生命周期中穩(wěn)定存在。例如，在圖 5-3-5中，“訂單”包中的類僅依賴于“數(shù)據(jù)庫接口”包中的類（接口），并不需要在它們之間建立關(guān)聯(lián)關(guān)系，因為對數(shù)據(jù)庫的訪問和操作僅在訂單處理類的函數(shù)中局部進(jìn)行。

　　綜上所述，關(guān)聯(lián)是依賴的強化，聚合是關(guān)聯(lián)的強化，構(gòu)成是聚合的強化。

　　2.領(lǐng)域概念模型的建立

　　為建立以UML 類圖表示的領(lǐng)域概念模型，必須首先標(biāo)識關(guān)鍵概念。關(guān)鍵概念的來源包括：

　　業(yè)務(wù)需求描述和用例說明；

　　業(yè)務(wù)領(lǐng)域中的相關(guān)規(guī)范、標(biāo)準(zhǔn)和術(shù)語定義；

　　反映業(yè)務(wù)領(lǐng)域知識的既往經(jīng)驗；

　　例如，“家庭保安系統(tǒng)”的領(lǐng)域概念模型如圖5-3-12所示。

圖 5-3-12　“家庭保安系統(tǒng)”的領(lǐng)域概念模型

　　圖5-3-12中新引入了“用戶命令處理器”、“系統(tǒng)配置管理器”、監(jiān)測器“異常事件” 和 “日志管理器” 5個新類。其中，“用戶命令處理器”負(fù)責(zé)接收來自用戶的操作命令，并將命令處理結(jié)果反饋至顯示面板；“系統(tǒng)配置管理器”保存系統(tǒng)的配置信息，協(xié)助“用戶命令處理器”完成用戶對系統(tǒng)配置信息的修改，還要負(fù)責(zé)向系統(tǒng)中的其他類提供配置信息的查詢服務(wù)；“監(jiān)測器”負(fù)責(zé)接收傳感器的數(shù)據(jù)，根據(jù)系統(tǒng)配置信息判別異常狀況，在異常發(fā)生時生成“ 異常事件 ”對象，觸發(fā)警報器并撥報警電話；“日志管理器”向系統(tǒng)中的其他類提供日志的記錄和查詢服務(wù)，日志信息應(yīng)包括用戶命令及處理結(jié)果、配置更改的歷史記錄和異常善的歷史記錄等。

?

轉(zhuǎn)載于:https://www.cnblogs.com/ziizz/p/6026381.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。