架構(gòu)師培訓(xùn)講義2-需求過程與分析的核心理論

1、第二章 需求過程與分析的核心理論架構(gòu)設(shè)計(jì)過程分為兩個(gè)階段：高層設(shè)計(jì)階段和詳細(xì)設(shè)計(jì)階段。高層設(shè)計(jì)階段的重點(diǎn)是軟件系統(tǒng)的體系結(jié)構(gòu)設(shè)計(jì)。詳細(xì)設(shè)計(jì)階段的重點(diǎn)是用戶界面設(shè)計(jì)、數(shù)據(jù)庫設(shè)計(jì)和模塊設(shè)計(jì)。而高層設(shè)計(jì)的信息，主要來自于需求分析。第一節(jié) 需求過程在軟件架構(gòu)中的重要作用作為一個(gè)架構(gòu)師，工作的主要舞臺是系統(tǒng)設(shè)計(jì)，但設(shè)計(jì)的輸入來自于需求工程，什么樣的需求思想，就有什么樣的架構(gòu)思維。這就是說，合理而且正確的需求分析過程，是架構(gòu)設(shè)計(jì)過程的一個(gè)有機(jī)的組成部分，所以，我們首先必須討論需求分析的領(lǐng)域建模的有關(guān)問題。需求開發(fā)與需求管理是相輔相成的兩類活動，它們共同構(gòu)成完整的需求工程。需求工程結(jié)構(gòu)圖如下所示：需求確認(rèn)需

2、求管理需求分析需求定義需求調(diào)查需求開發(fā)需求工程需求變更控制需求跟蹤需求開發(fā)和需求管理的流程下所示。需求分析需求變更控制需求跟蹤需求確認(rèn)需求管理過程域輸出輸出用戶需求說明書產(chǎn)品需求定義用戶需求調(diào)查產(chǎn)品需求規(guī)格說明書需求開發(fā)過程域其中，需求變更控制是指依據(jù)“變更申請審批更改重新確認(rèn)”的流程處理需求的變更，確保需求的變更不會失去控制而導(dǎo)致項(xiàng)目發(fā)生混亂。需求的類型：作為一個(gè)檢查表，需求可以按照FURPS+模型進(jìn)行分類的，每個(gè)字母含義如下：F：功能性（Functional）：特性、能力、安全性。U：可用性（Usability）：人性化因素，幫助，文檔。R：可靠性（Reliability）：故障周期，可恢

3、復(fù)性，可預(yù)測性。P：性能（Performance）：響應(yīng)時(shí)間，吞吐量，準(zhǔn)確性，有效性，資源利用率。S：可支持性（Supportability）：適應(yīng)性，可維護(hù)性，國際化，可配置性。+：輔助和次要的因素，比如：實(shí)現(xiàn)（Implentation）：資源限制，語言和工具，硬件等。接口（Interface）：與外部系統(tǒng)接口所加的約束。操作（Operations）：系統(tǒng)操作環(huán)境中的管理。包裝（Packaging）：授權(quán)（Legal）：許可證或其它方式。事實(shí)上，F(xiàn)URPS+模型并不是唯一的，但用它來作為需求范圍檢查表是很有效的，這可以降低考慮系統(tǒng)的時(shí)候遺漏某些因素的風(fēng)險(xiǎn)。還有一些分類方式和FURPS+模型類

4、似，比如ISO9126，它主要來自于美國軟件工程研究所(SEI)。第二節(jié) 面向過程的需求分析核心知識傳統(tǒng)的面向過程需求分析與面向?qū)ο蠓治鍪遣煌模瑐鹘y(tǒng)方法把系統(tǒng)看成一個(gè)過程的集合體，由人和機(jī)器共同完成一個(gè)任務(wù)，計(jì)算機(jī)與數(shù)據(jù)交互、讀出數(shù)據(jù)、進(jìn)行處理又把結(jié)果寫回到計(jì)算機(jī)里面去。在討論事件的時(shí)候，過程方法強(qiáng)調(diào)組件的過程模型。而對象方法把系統(tǒng)看成一個(gè)相互影響的對象集，對象重要的是具有行為（方法），行為發(fā)送消息請求另一個(gè)對象做事情，就本質(zhì)而言，對象方法不包括計(jì)算機(jī)過程和數(shù)據(jù)文件，而是對象執(zhí)行活動并記錄下數(shù)據(jù)，當(dāng)為系統(tǒng)響應(yīng)建模的時(shí)候，對象方法包括響應(yīng)模型、模型行為以及對象的交互。兩種方式的不同點(diǎn)如下圖：下

5、面我們先簡單討論一下面向過程分析的特點(diǎn)，一般來說，面向過程的分析必將導(dǎo)致面向過程的架構(gòu)（設(shè)計(jì)）。一、數(shù)據(jù)流程圖DFD1，DFD的符號面向過程的核心理念是數(shù)據(jù)流，所以它的模型主要是數(shù)據(jù)流程圖（DFD），它只用了5個(gè)符號。概念：外部實(shí)體：在系統(tǒng)邊界之外的個(gè)人和組織，它提供數(shù)據(jù)，或者接受數(shù)據(jù)輸出。過程：在DFD中的一個(gè)符號，它代表數(shù)據(jù)輸入轉(zhuǎn)換到數(shù)據(jù)輸出的算法或者程序。數(shù)據(jù)流：在DFD中的箭頭，它表示在過程、數(shù)據(jù)存儲和外部實(shí)體間的數(shù)據(jù)移動。數(shù)據(jù)存儲：保存數(shù)據(jù)的地方，將來一個(gè)或者多個(gè)過程來訪問這些數(shù)據(jù)。2，關(guān)聯(lián)圖系統(tǒng)內(nèi)部在單個(gè)過程符號中概括所有處理活動的DFD。下面是客戶支持系統(tǒng)的關(guān)聯(lián)圖簡單例子：注意，

6、箭頭表示數(shù)據(jù)的流向。二、事件劃分的系統(tǒng)模型（0層圖）DFD的細(xì)節(jié)稱作片段，片段的組合有多種方式，現(xiàn)代過程分析也是以事件為基礎(chǔ)，所以完全集可以組合到一個(gè)事件劃分系統(tǒng)模型或者稱為0層圖中去。其中，每個(gè)過程為一個(gè)事件的處理。三、分解過程如果一個(gè)DFD片斷包括更多的處理，可以把過程進(jìn)行分解，以便作更詳細(xì)的研究。四、評估DFD的質(zhì)量高質(zhì)量的DFD是可讀的、內(nèi)部一致的以及能準(zhǔn)確表示系統(tǒng)需求的。復(fù)雜性最小化：人們對復(fù)雜信息處理是有局限性的，當(dāng)太多的信息同時(shí)出現(xiàn)的時(shí)候，人們把這種現(xiàn)象稱作信息超量。在這樣的情況下，可以把信息劃分為小的相對獨(dú)立的子集，這樣便于單獨(dú)考察和理解信息，這也是建模最根本的目的。7

7、7;2原則：這個(gè)原則也稱之為Mille數(shù)，由心理學(xué)研究，一個(gè)人可同時(shí)記住或操縱的信息塊的數(shù)目大約在7到9之間，也就是一個(gè)模型的過程數(shù)不要超過7±2個(gè)。另外數(shù)據(jù)流進(jìn)、流出一個(gè)過程、數(shù)據(jù)存儲或者數(shù)據(jù)元素的個(gè)數(shù)不要超過7±2個(gè)。這不是強(qiáng)制原則，但可以給我們提供一個(gè)警告。接口最小化：這里的接口是指一個(gè)問題或者描述中的一部分與其它部分的連接。源于7±2原則，連接數(shù)應(yīng)該保持最小，如果超出了這個(gè)原則，可把一個(gè)過程分解為更多的過程，以使得分析簡單。數(shù)據(jù)流一致性：通過分析數(shù)據(jù)流的不一致，可以找到錯(cuò)誤。下面的例子使用了過程描述（面向過程英語）來描述內(nèi)部過程，流入的B、C沒有任何處理，

8、也沒有流出，被稱之為“黑洞”。下面的例子，流出的B、Y和內(nèi)部的X并沒有流入，被稱之為“奇跡”。面向過程的分析已經(jīng)有了一套完整而且成熟的方法，像決策表和決策樹等等，這里就不再討論了。五、案例：訂單處理子系統(tǒng)1、問題陳述：項(xiàng)目名稱：電源設(shè)備訂單處例子系統(tǒng)項(xiàng)目單位：TB公司電源設(shè)備銷售部最后修改日期：*年*月*日系統(tǒng)目標(biāo)1，客戶直接利用因特網(wǎng)購買電源設(shè)備，客戶選擇設(shè)備，設(shè)備分為普通不間斷電源、服務(wù)器專用不間斷電源和專業(yè)級不間斷電源加自主供電設(shè)備等。 2，客戶可以選擇標(biāo)準(zhǔn)配置，也可以在線建立自己的配置。3，可配置的構(gòu)件顯示在一個(gè)下拉列表中，對每一種配置，系統(tǒng)可以計(jì)算價(jià)格。系統(tǒng)要求1，發(fā)出訂單時(shí)，客戶需

9、要填上運(yùn)送和付款信息，系統(tǒng)可接受的付款方式為信用卡和支票，一旦訂單輸入，系統(tǒng)將向客戶發(fā)送一個(gè)確認(rèn)e-mail信息，并且附上訂單細(xì)節(jié)，在等待電源設(shè)備送到的時(shí)候，客戶可以在任何時(shí)候在線查到訂單狀態(tài)。2，后端訂單處理包括下面所需的步驟：由客戶服務(wù)系統(tǒng)提供這個(gè)客戶的等級以及根據(jù)等級和促銷策略計(jì)算出的相應(yīng)折扣方式，驗(yàn)證客戶的信任度和付款方式，向倉庫請求所訂購的配置，打印發(fā)票，并且請求倉庫將電源設(shè)備運(yùn)送給客戶。1，功能分解圖功能分解顯示了一個(gè)系統(tǒng)自頂向下的分解結(jié)構(gòu)，也為我們繪制數(shù)據(jù)流圖（DFD）的提綱。2，過程事件圖 現(xiàn)在我們的眼睛盯住具體的細(xì)節(jié)，為每個(gè)事件過程繪制一個(gè)事件圖，這實(shí)際上是一個(gè)事件的上下文流

10、圖。在研究事件圖的時(shí)候，往往需要了街所有的數(shù)據(jù)存儲。必要的時(shí)候，數(shù)據(jù)庫分析和設(shè)計(jì)可以提到前面先來完成，我們將在后面的章節(jié)來討論這個(gè)問題。要說明的是分析的時(shí)候并不需要數(shù)據(jù)庫的詳細(xì)設(shè)計(jì)，而只是把數(shù)據(jù)存儲用實(shí)體的方式從大的方面規(guī)范清楚，以此作為詳細(xì)設(shè)計(jì)的一個(gè)必要的輸入。大多數(shù)事件圖包括一個(gè)單一過程，并且需要說明以下內(nèi)容：1）輸入及輸入來源，來源被描述為外部代理。2）輸出及輸出目的地，目的地被描述為外部代理。3）必須讀取記錄的任何數(shù)據(jù)存儲都應(yīng)該被加入到事件圖中，事件流應(yīng)該加入命名。4）對數(shù)據(jù)的任何增、刪、改、查都應(yīng)該加入到事件流中，事件流應(yīng)該加入命名。事件圖的敏感性和簡單性，使它成為專家和用戶溝通的強(qiáng)

11、有力的工具，下面是一個(gè)簡單的外部事件圖。一個(gè)簡化的“訂單處理子系統(tǒng)”的過程事件圖如下。參與者事件（或者用例）觸發(fā)器響應(yīng)客戶選擇產(chǎn)品（由Web頁面驅(qū)動）產(chǎn)品查詢生成“目錄描述”客戶發(fā)出訂單新客戶訂單生成“客戶訂單確認(rèn)”，在數(shù)據(jù)庫中創(chuàng)建“客戶訂單”和“客戶訂購的產(chǎn)品”。客戶修改訂單客戶訂單修改請求生成“客戶訂單確認(rèn)”，修改數(shù)據(jù)庫中 “客戶訂單”和“客戶訂購的產(chǎn)品”。客戶取消訂單客戶訂單取消生成“客戶訂單確認(rèn)”，在數(shù)據(jù)庫中邏輯的刪除 “客戶訂單”和“客戶訂購的產(chǎn)品”。3，系統(tǒng)DFD圖事件圖并不是孤立存在的，它們集合在一起定義了系統(tǒng)和子系統(tǒng)，所以，構(gòu)造一個(gè)或者多個(gè)系統(tǒng)或者子系統(tǒng)中所有事件相互關(guān)系的系統(tǒng)

12、圖也是有意義的。在繪制系統(tǒng)圖的時(shí)候，必須平衡不同詳細(xì)程度的事件圖，以保證一致性和完整性，必要的時(shí)候可以擴(kuò)展為多個(gè)DFD。系統(tǒng)圖更多的是從宏觀的角度看為題，更多的考慮相互關(guān)系，這點(diǎn)很重要。4，基本圖系統(tǒng)圖中的某些重要的事件過程可以擴(kuò)展為一個(gè)基本的數(shù)據(jù)流圖，以揭示更多的細(xì)節(jié)，這對比較復(fù)雜的業(yè)務(wù)過程（比如訂單處理特別重要），有些事件比較簡單（比如報(bào)告生成），所以不需要進(jìn)一步擴(kuò)展。5，完整的規(guī)格說明上下文圖、系統(tǒng)圖、事件圖和基本圖的組合構(gòu)成了過程模型，一個(gè)工藝良好的完整過程模型可以在最終用戶和計(jì)算機(jī)軟件設(shè)計(jì)者以及程序人員之間有效的溝通需求，消除大部分系統(tǒng)設(shè)計(jì)、編程和實(shí)施階段出現(xiàn)的混淆。注意，完整的過程

13、模型并不僅僅是這些圖，更多的是文字說明，把圖形和文字結(jié)合起來，設(shè)計(jì)就會非常的清晰而且避免歧義，這非常重要。第三節(jié) 面向?qū)ο蟮男枨蠓治龊陀美诿嫦驅(qū)ο蟮男枨蠓治鲋?，對象、事件和響?yīng)成為分析的主體，分析的著力點(diǎn)轉(zhuǎn)向了交互。但是，還是有相應(yīng)的方法來描述功能，這就是用例，這也是需求分析的重要部分。一、用例及用例圖的基本概念用戶一定會有自己的目標(biāo)，并且希望計(jì)算機(jī)能夠幫助他們實(shí)現(xiàn)這些目標(biāo)。用例就是表達(dá)如何使用系統(tǒng)達(dá)到目標(biāo)的一組情節(jié)。用例的幾個(gè)概念參與者（actor）：具有行為能力的事務(wù)，可以是個(gè)人（由其扮演的角色來識別），計(jì)算機(jī)系統(tǒng)，或者組織。場景（scenario）：是參與者和被討論系統(tǒng)之間一系列特定的

14、活動和交互，通常被稱之為“用例的實(shí)例”。通俗地講，場景實(shí)際上是在說故事。一般來說，一個(gè)用例就是描述參與者使用系統(tǒng)達(dá)成目標(biāo)的時(shí)候一組相關(guān)的成功場景和失敗場景的集合。用例分析的關(guān)鍵是專注于“怎樣才能使系統(tǒng)為用戶提供可觀測的數(shù)據(jù)，或幫助用戶實(shí)現(xiàn)它們的目標(biāo)”，而不是僅僅把系統(tǒng)需求用特性和功能的細(xì)目羅列出來。在需求分析中，我們必須專注于考慮系統(tǒng)怎么才能增加價(jià)值和實(shí)現(xiàn)目標(biāo)。用例的主要思想是：為功能需求寫出用例（而不是老式的為“系統(tǒng)會怎么做”的功能列表），在統(tǒng)一過程中用例是發(fā)現(xiàn)和定義需求的主要方法，是功能性行為。參與者的發(fā)現(xiàn):發(fā)現(xiàn)參與者對提供用例是非常有用的。因?yàn)槊鎸σ粋€(gè)大系統(tǒng),要列出用例清單常常是十分困難

15、。這時(shí)可先列出參與者清單,再對每個(gè)參與者列出它的用例,問題就會變得容易很多。 二、用例（UseCase）及其定義 1）用例：1用例是關(guān)于單個(gè)活動者在與系統(tǒng)對話中所執(zhí)行的處理行為的陳述序列（Jacobson）。它表達(dá)了系統(tǒng)的功能和所提供的服務(wù)，用例的圖示如下。2它描述了活動者給系統(tǒng)特定的刺激時(shí)系統(tǒng)的活動，是活動者通過系統(tǒng)完成一個(gè)過程時(shí)出現(xiàn)的一組事件，最終以實(shí)現(xiàn)一種功能。3通常，用例側(cè)重于功能，但不重點(diǎn)描述該功能的實(shí)現(xiàn)細(xì)節(jié)。4所有的用例必須始于參與者（Actor），而且有些用例也結(jié)束于參與者。2）用例的分類1業(yè)務(wù)用例（Business Use Case）指系統(tǒng)提供的業(yè)務(wù)功能與參與者的交互，表現(xiàn)問題

16、領(lǐng)域中各實(shí)體間的聯(lián)系和業(yè)務(wù)往來活動（如果某個(gè)用例的范圍包含了人以及由人組成的團(tuán)隊(duì)、部門、組織的活動，那么這個(gè)用例必然是業(yè)務(wù)用例）。2，系統(tǒng)用例（System Use Case）指參與者與系統(tǒng)的交互，它表現(xiàn)了系統(tǒng)的功能需求和動態(tài)行為（如果僅僅是一些軟件、硬件、機(jī)電設(shè)備或由它們組成的系統(tǒng)，并不涉及到人的業(yè)務(wù)活動，那么該用例是系統(tǒng)用例）。3）用例的聯(lián)系（橫向方面）1泛化關(guān)聯(lián)泛化關(guān)聯(lián)代表一般與特殊的關(guān)系，它充分體現(xiàn)了面向?qū)ο蟮睦^承性：子類具有父類的所有屬性，還可以擁有自己的屬性特點(diǎn)及行為。泛化關(guān)聯(lián)包括用例之間及活動著之間的關(guān)聯(lián)關(guān)系。例如，修改員工資料和修改開發(fā)部員工資料就是用例的泛化關(guān)聯(lián)。泛化關(guān)聯(lián)用空

17、心三角箭頭的實(shí)線表示：其方向從特殊指向一般。2，包含關(guān)聯(lián)（include）包含關(guān)聯(lián)指一個(gè)基本用例的行為包含了另一個(gè)用例的行為，這種關(guān)聯(lián)是一種依賴關(guān)系，被包含的用例不能獨(dú)立存在，只能作為包含它的用例的一部分。例如，一個(gè)信息維護(hù)的模塊，無論是錄入人員信息還是修改人員信息，都必須對當(dāng)前登錄者進(jìn)行驗(yàn)證，因而錄入及修改人員信息這/兩個(gè)用例都用到了對當(dāng)前用戶的權(quán)限驗(yàn)證的用例。其表示方法為用一條虛箭線從基本用例指向被包含的用例，并標(biāo)有構(gòu)造型<<include>>：3，擴(kuò)展關(guān)聯(lián)（extend）擴(kuò)展關(guān)聯(lián)的基本含義與泛化關(guān)聯(lián)類似，但是對于擴(kuò)展用例有更多的規(guī)則，即基本的用例必須聲明若干新的規(guī)

18、則-擴(kuò)展點(diǎn)（Extension Points），擴(kuò)展用例只能在這些擴(kuò)展點(diǎn)上增加新的行為并且基本用例不需要了解擴(kuò)展用例的如何細(xì)節(jié)。例如，保存人員信息用例可以是刪除人員信息及新增和修改人員信息用例的擴(kuò)展，它們之間存在著擴(kuò)展關(guān)系。如果特定的條件發(fā)生，擴(kuò)展用例的行為才能執(zhí)行。其圖形表示方法為在用例圖上用一條從基本用例指向擴(kuò)展用例的虛箭線表示，并在線上標(biāo)注購造型<<extend>>：三、用例圖及其表達(dá)原則用例圖主要表現(xiàn)各個(gè)用例之間寬泛的關(guān)系，如下圖所示。在上面的圖中，計(jì)算機(jī)系統(tǒng)的參與者有兩種表示法，其中有些人喜歡用不同于人型的方框表示外部計(jì)算機(jī)系統(tǒng)參與者，<<acto

19、r>>稱作UML構(gòu)造型，這是用某種方式分類元素的方式夠造型的名稱被書名符號包住，這本來就是法文印刷中表示引用的符號。注意：主要參與者和用戶目標(biāo)和系統(tǒng)邊界有關(guān)有個(gè)問題，在“處理銷售”用例中，為什么主要參與者是收銀員而不是顧客呢？這和系統(tǒng)邊界有關(guān)，我們定義的銷售系統(tǒng)邊界，服務(wù)目標(biāo)是收銀員。如果把系統(tǒng)邊界定義為企業(yè)交款服務(wù)，那顧客就是一個(gè)主要參與者了。我們也可以通過事件分析找出參與者。第四節(jié) 用例的事件流與用例文檔用例的事件流是對完成用例行為所需的事件的描述。事件流描述了系統(tǒng)應(yīng)該做什么，而不是怎么做。可以通過一個(gè)清晰的，易被用戶理解的時(shí)間流來說明一個(gè)用例的行為。在事件流中包括用例何時(shí)開始

20、和結(jié)束，用例何時(shí)和參與者交互，什么對象被交互以及該行為的基本流和可選流。一、用例的事件流的組成（1）用例事件流所應(yīng)該包含的內(nèi)容簡要說明：描述該使用案例的作用（可以不寫出）；前置條件：開始使用該用例之前必須滿足的系統(tǒng)和環(huán)境的狀態(tài)和條件（必要條件而不是充分條件）主事件流：用例的正常流程（事件流是關(guān)注系統(tǒng)干什么，而不是怎么干），也稱為用例的路徑。其它（備選）事件流：用例的非正常流程，如錯(cuò)誤流程后置條件：用例成功結(jié)束后系統(tǒng)應(yīng)該具備的狀態(tài)和條件（但不是每個(gè)用例都有后置條件）（2）主事件流（用例的路徑）可能包含有基本路徑、備選路徑、異常路徑、成功路徑和失敗路徑等幾個(gè)方面的內(nèi)容。二、描述用例的事件流的主要方

21、式1，面向過程語言：每個(gè)用例只描述沒有大的分支的行為的單個(gè)線索，在事件流中要對事件流進(jìn)行面向過程說明（主事件流和備選事件流）。2，UML的活動圖（系統(tǒng)活動圖-和用例活動圖）：使用活動圖可以表示由內(nèi)部生成的動作驅(qū)動的事件流，活動圖能提醒您注意并展示并行的和同時(shí)發(fā)生的活動。這使得活動圖成為建立工作流模型、分析用例以及處理多線程應(yīng)用程序的得力工具。三、事件流描述文檔的基本要求1）首先寫出基本的路徑這是最主要的事情，因?yàn)樗怯脩糇铌P(guān)心或者最想看到的內(nèi)容。2）用例交互的四步曲1，參與者產(chǎn)生某個(gè)行為動作；2，然后系統(tǒng)對此動作進(jìn)行響應(yīng)；3，響應(yīng)成功后再根據(jù)動作的要求進(jìn)行狀態(tài)的改變；4，最后將改變后的結(jié)果再回

22、饋給參與者。3）模板格式用例的模版可以有不同的形式，關(guān)鍵是要表達(dá)清楚：作者: _日期: _版本: _用例名: 用例類型用例ID:主要業(yè)務(wù)參與者:其它參與者:項(xiàng)目相關(guān)人員興趣:描述：前置條件：后置條件：觸發(fā)條件:基本流程:擴(kuò)展流程：結(jié)束:業(yè)務(wù)規(guī)則：實(shí)現(xiàn)約束和說明：假設(shè)：待解決問題:對于上述一些時(shí)間流，以及一些關(guān)鍵和重要的問題，需要對用例進(jìn)行詳細(xì)設(shè)計(jì)，這是需要使用文檔而不是圖。四、用例文檔中幾個(gè)元素的解釋1）序言元素要把最重要的元素放在一開始。而把一些不重要的“標(biāo)題”材料放在末尾。用戶興趣列表：這個(gè)列表很重要也很實(shí)用。用例作為行為的契約，撲獲所有與滿足客戶興趣有關(guān)的行為。這就回答了一個(gè)問題，用例應(yīng)

23、該包含什么？答：用例應(yīng)該包含滿足所有客戶感興趣的內(nèi)容，另外，在寫出用例所有部分之前，需要確定用戶及其興趣。例如，如果我們沒有列出“銷售人員提成”的興趣，在開始部分我們可能會漏掉這個(gè)職責(zé)。以客戶興趣作為視點(diǎn)來觀察，會給我們提供一種徹底的、系統(tǒng)化的程序，用來發(fā)現(xiàn)和記錄所有必需的行為。例：項(xiàng)目相關(guān)人員的興趣：收銀員：希望能夠準(zhǔn)確快速的輸入，沒有支付錯(cuò)誤。售貨員：希望自動更新銷售提成。等。2）前置條件和后置條件（成功后的保證）前置條件：規(guī)定了用例一個(gè)場景開始之前必須為“真”的條件。前置條件在用例中不會被檢驗(yàn)，我們假定它已經(jīng)被滿足，通常前置條件是已經(jīng)成功完成的其它用例的一個(gè)場景。比如：“系統(tǒng)已經(jīng)被登錄”

24、或“收銀員已經(jīng)被識別和授權(quán)”。但不要包括沒有價(jià)值的條件，比如“系統(tǒng)已經(jīng)被供電”。前置條件主要表達(dá)讀者應(yīng)該引起警惕的或者值得注意的那些假設(shè)。后置條件：后置條件也叫“成功后的保證”，表達(dá)了用例成功結(jié)束以后必須為真的條件，這個(gè)“保證”應(yīng)該滿足所有客戶方的需要。這里所有的客戶方，指的是所有參與使用項(xiàng)目的人員。例：前置條件：收銀員已經(jīng)被識別和授權(quán)。后置條件：存儲銷售信息，準(zhǔn)確計(jì)算稅金，更新賬目和庫存，記錄提成，生成收據(jù)。3）基本流程我們可以把主要成功場景成做“基本流程”，它描述了能滿足客戶興趣的典型成功路徑。一般它不包括任何條件和分支，而把條件和分支放在“擴(kuò)展”部分說明。場景記錄以下三種步驟：1）參與者

25、之間的交互。2）一個(gè)驗(yàn)證動作（通常由系統(tǒng)來完成）。3）由系統(tǒng)完成的狀態(tài)改變。例：注意表示重復(fù)的習(xí)慣用法主要成功場景：1顧客攜帶購買的商品到達(dá)POS機(jī)收費(fèi)口2收銀員開始一次新的銷售3收銀員輸入商品標(biāo)識4.重復(fù) 3 4 步，直到結(jié)束。53）擴(kuò)展擴(kuò)展又稱之為“替代流程”，它說明了所有其它的場景和分支。擴(kuò)展往往比主要成功場景長而且復(fù)雜，這正是我們所希望的。在寫完整用例的時(shí)候，基本流程加上擴(kuò)展能滿足幾乎所有客戶的興趣。擴(kuò)展場景是從主要成功場景中分離出來的，所以標(biāo)記方式應(yīng)該相同，比如，第3步的一個(gè)擴(kuò)展就被標(biāo)記為3a。擴(kuò)展：3a.非法標(biāo)識 1系統(tǒng)指示錯(cuò)誤并拒絕輸入。3b.多個(gè)具有相同類別的商品，不需要跟蹤每

26、個(gè)商品的唯一身份1 收銀員可以輸入商品類別的表識和數(shù)量。3c.顧客要求從藝術(shù)如商品中減去一個(gè)商品 1收銀員輸入商品標(biāo)識并將其刪除。 2系統(tǒng)顯示更新后的累加值。.一個(gè)“擴(kuò)展”有兩部分組成：條件和處理，處理的步驟可以有多個(gè)。有時(shí)候擴(kuò)展可能會非常復(fù)雜，這就需要用單個(gè)用例來完成擴(kuò)展。下面看看怎么標(biāo)記擴(kuò)展中的失?。?b.信用卡支付1.顧客輸入信用卡賬號2.系統(tǒng)向外部信用卡授權(quán)服務(wù)系統(tǒng)請求支付驗(yàn)證2a系統(tǒng)檢測到和外部信用卡授權(quán)服務(wù)系統(tǒng)通信故障1. 系統(tǒng)向收銀員知識發(fā)生了錯(cuò)誤2.收銀員向客戶請求更換支付方式3.如果想要描述一個(gè)可能在任何一步（至少是絕大多數(shù)步驟）都會發(fā)生的條件，那么應(yīng)該使用類似“*a”、“*

27、b”這樣的標(biāo)記。*a.任何時(shí)刻，發(fā)生一下狀況，系統(tǒng)將會崩潰。1收銀員重啟系統(tǒng)，登錄，請求恢復(fù)上次狀態(tài)。2系統(tǒng)重建之前的狀態(tài)。4）特殊需求如果有一些與這個(gè)用例有關(guān)的非功能性需求（質(zhì)量屬性或約束條件），那么應(yīng)該把他們記錄在一起。例：特殊需求在大型平板顯示器上觸摸屏界面，文本信息要能在一米之外看清。90%信用卡授權(quán)機(jī)構(gòu)的響應(yīng)，應(yīng)該能在30秒之內(nèi)收到。支持多種語言顯示。在步驟2和步驟6種可以插入新的業(yè)務(wù)規(guī)則。經(jīng)典的統(tǒng)一過程建議，第一次寫出用例的時(shí)候，把特殊需求和用例寫在一起。但現(xiàn)在更通用的做法是把所有非功能性需求放在“補(bǔ)充規(guī)范”中，這樣更容易進(jìn)行內(nèi)容管理，也更容易讀，因?yàn)檫@些需求通常要求在進(jìn)行系統(tǒng)整體

28、架構(gòu)分析的時(shí)候通盤考慮。5）技術(shù)和數(shù)據(jù)的變化列表系統(tǒng)通常有一些技術(shù)上的變化是關(guān)于“應(yīng)該怎樣做”，而不是“應(yīng)該做什么”，需要在用例中把這些變化記錄下來。比如，數(shù)據(jù)表示方案可能會有不同的變化，在列表中應(yīng)該記錄這種變化。技術(shù)和數(shù)據(jù)的變化列表：3a. 商品標(biāo)識可以用條碼掃描也可以用鍵盤輸入。3b. 商品表識可以采用UPC、EAN、JAN、SKU等不同的編碼方式。7a. 信用卡賬號信息可以使用讀卡器或鍵盤輸入。7b. 記錄在紙面收據(jù)上的信用卡支付簽名，但我們預(yù)測，兩年內(nèi)會有許多顧客希望使用數(shù)字簽名。五、示例：銷售系統(tǒng)這里為了把問題表達(dá)清楚，添加了一些項(xiàng)目。舉個(gè)例子。POS銷售系統(tǒng)作者: _日期: _版本

29、: _用例名: Process Sale用例類型用例ID:TB-SALE2.00業(yè)務(wù)需求主要業(yè)務(wù)參與者:收銀員項(xiàng)目相關(guān)人員興趣:收銀員：希望能準(zhǔn)確、快速的輸入，而且沒有支付錯(cuò)誤。l售貨員：希望自動更新銷售提成。l顧客：希望購買過程能夠省力，并得到快速服務(wù)，希望得到購買證明，以便退貨。l公司：希望準(zhǔn)確的記錄交易，并滿足顧客要求，希望保證支付授權(quán)服務(wù)的信息被記錄，希望有一定的容錯(cuò)性，即使某些服務(wù)不可用也能允許收款，希望能自動快速的更新賬目和庫存信息。l政府稅務(wù)機(jī)關(guān)：希望從每筆交易中抽取稅金。l支付授權(quán)服務(wù)：希望按照正確的格式和協(xié)議收到數(shù)字授權(quán)的請求，希望準(zhǔn)確計(jì)算給商店的應(yīng)付款。前置條件：收銀員已經(jīng)

30、被識別和授權(quán)。后置條件：存儲銷售信息，準(zhǔn)確計(jì)算稅金，更新賬目和庫存，記錄提成，生成收據(jù)。觸發(fā)條件:當(dāng)客戶開始驗(yàn)證購買的商品的時(shí)候，該用例被觸發(fā)?；玖鞒蹋?顧客攜帶購買的商品到達(dá)POS機(jī)收費(fèi)口2收銀員開始一次新的銷售3收銀員輸入商品標(biāo)識4.重復(fù) 3 4 步，直到結(jié)束。5.10顧客攜帶商品和收據(jù)離開替代流程*a.任何時(shí)刻，發(fā)生以下狀況，系統(tǒng)將會崩潰。1收銀員重啟系統(tǒng)，登錄，請求恢復(fù)上次狀態(tài)。2系統(tǒng)重建之前的狀態(tài)。3a.非法標(biāo)識 1系統(tǒng)指示錯(cuò)誤并拒絕輸入。3b.多個(gè)具有相同類別的商品，不需要跟蹤每個(gè)商品的唯一身份2收銀員可以輸入商品類別的標(biāo)識和數(shù)量。3-6a.顧客要求從已輸入商品中減去一個(gè)商品 1

31、收銀員輸入商品標(biāo)識并將其刪除。 2系統(tǒng)顯示更新后的累加值。.7b.信用卡支付1.顧客輸入信用卡賬號2.系統(tǒng)向外部信用卡授權(quán)服務(wù)系統(tǒng)請求支付驗(yàn)證2a系統(tǒng)檢測到和外部信用卡授權(quán)服務(wù)系統(tǒng)通信故障2.系統(tǒng)向收銀員指示發(fā)生了錯(cuò)誤2.收銀員向客戶請求更換支付方式結(jié)束:當(dāng)客戶完成支付，該用例結(jié)束。特殊需求：1，在大型平板顯示器上觸摸屏界面，文本信息要能在一米之外看清。2，90%信用卡授權(quán)機(jī)構(gòu)的響應(yīng)，應(yīng)該能在30秒之內(nèi)收到。3，支持多種語言顯示。4，在步驟2和步驟6種可以插入新的業(yè)務(wù)規(guī)則。技術(shù)和數(shù)據(jù)的變化列表：3a. 商品標(biāo)識可以用條碼掃描也可以用鍵盤輸入。3b. 商品標(biāo)識可以采用UPC、EAN、JAN、SK

32、U等不同的編碼方式。7a. 信用卡賬號信息可以使用讀卡器或鍵盤輸入。7b. 記錄在紙面收據(jù)上的信用卡支付簽名，但我們預(yù)測，兩年內(nèi)會有許多顧客希望使用數(shù)字簽名。發(fā)生頻率：可能會持續(xù)發(fā)生。待解決問題:1，什么是稅法的變化？2，研究遠(yuǎn)程服務(wù)的恢復(fù)問題3，不同的業(yè)務(wù)需要什么樣的定制？4，收銀員是否必須在退出系統(tǒng)以后帶走他的現(xiàn)金抽屜？5，顧客是否可以直接使用讀卡器，而不需要收銀員代勞？這個(gè)例子雖然不完整，但是一個(gè)實(shí)際的例子，足以給我們提供一個(gè)真實(shí)的感受。在統(tǒng)一過程中提倡一種簡樸的書寫風(fēng)格，也就是不考慮用戶界面，而專注于他們的意圖，只對用戶意圖和系統(tǒng)職責(zé)這一級描述，這點(diǎn)很重要。六、案例：訂單處理子系統(tǒng)1、

33、問題陳述：與過程分析相同。2、參與者通過如下分析，把問題條理化，發(fā)現(xiàn)參與者，注意，描述的時(shí)候不要使用隱語。比如：要e-mail給客戶；正確的：銷售人員要e-mail給客戶。1，客戶使用公司的的Web頁面查看所選擇的電源設(shè)備標(biāo)配，同時(shí)顯示價(jià)格。2，客戶查看配置細(xì)節(jié)，可以更改配置，同時(shí)計(jì)算價(jià)格。3，客戶選擇訂購，也可以要求銷售人員在訂單真正發(fā)出之前和自己聯(lián)系，解釋有關(guān)細(xì)節(jié)。4，要發(fā)出訂單，客戶必須填寫表格，包括地址，付款細(xì)節(jié)（信用卡還是支票）等。5，客戶訂單送到系統(tǒng)之后， 系統(tǒng)由客戶服務(wù)系統(tǒng)取得該客戶的等級，以及由銷售策略決定的折扣。6，銷售人員發(fā)送電子請求到倉庫管理系統(tǒng)，并且附上配置細(xì)節(jié)。7，事

34、務(wù)的細(xì)節(jié)（包括訂單號和客戶帳戶號），銷售人員要e-mail給客戶，使得客戶可以在線查詢訂單狀態(tài)。8，倉庫從銷售人員處獲取發(fā)票，并且向客戶運(yùn)送電源設(shè)備。從中我們可以發(fā)現(xiàn)四個(gè)參與者：客戶；銷售人員；倉庫管理系統(tǒng)；客戶服務(wù)系統(tǒng)。3、建立用例用例表示一個(gè)完整的給用戶傳值的功能單元，不與用例通信的參與者是沒有意義的，但用例可以只為泛化，而不與參與者通信。我們可以建立一個(gè)表來分析，把功能需求賦予參與者和用例。注意，有些潛在的業(yè)務(wù)功能可能不在應(yīng)用范圍只內(nèi)，它們不能被轉(zhuǎn)換為用例，比如倉庫裝配電源設(shè)備并且把它運(yùn)送給客戶，這個(gè)任務(wù)已經(jīng)超出這個(gè)系統(tǒng)的業(yè)務(wù)范圍，不能作為用例。編號需求參與者用例1客戶使用電源部的Web

35、頁面查看所選擇的電源設(shè)備標(biāo)配，同時(shí)顯示價(jià)格?？蛻麸@示標(biāo)準(zhǔn)電源配置2客戶查看配置細(xì)節(jié)，可以更改配置。客戶構(gòu)造電源配置3系統(tǒng)由客戶服務(wù)系統(tǒng)取得該客戶的等級，以及由銷售策略決定的折扣，同時(shí)計(jì)算價(jià)格?？蛻艨蛻舴?wù)系統(tǒng)獲取銷售策略4客戶選擇訂購，也可以要求銷售人員在訂單真正發(fā)出之前和自己聯(lián)系，解釋有關(guān)細(xì)節(jié)?？蛻翡N售人員訂購配置了的電源設(shè)備請求與銷售人員聯(lián)系5要發(fā)出訂單，客戶必須填寫表格，包括地址，付款細(xì)節(jié)（信用卡還是支票）等?？蛻粲嗁徟渲昧说碾娫丛O(shè)備效驗(yàn)和認(rèn)可客戶付款6銷售人員發(fā)送電子請求到倉庫管理系統(tǒng)，并且附上配置細(xì)節(jié)。銷售人員倉庫管理系統(tǒng)通知倉庫關(guān)于訂購信息7事務(wù)的細(xì)節(jié)（包括訂單號和客戶帳戶號），銷

36、售人員要e-mail給客戶，使得客戶可以在線查詢訂單狀態(tài)。銷售人員客戶訂購配置了的電源設(shè)備更新訂購狀況8倉庫管理系統(tǒng)從銷售人員處獲取發(fā)票，并且向客戶運(yùn)送電源設(shè)備倉庫管理系統(tǒng)銷售人員打印發(fā)票可以建立如下用例：4、用例圖用例圖的作用是把用例賦給參與者，用例圖是系統(tǒng)行為模型的主要可視化技術(shù)。還可以建立用例之間的關(guān)系，比如圖中Extend表示“訂購配置了的計(jì)算機(jī)”可以被“客戶”擴(kuò)展為“請求與銷售人員聯(lián)系”。而訂購配置了的電源設(shè)備包含了（include）獲取銷售策略的行為，這種依賴關(guān)系，表達(dá)了獲取銷售策略的用例不能獨(dú)立存在，只能作為包含它的訂購配置了的電源設(shè)備用例的一部分。5、編寫用例文檔用例必須用事件

37、流文檔來描述，這個(gè)文檔表達(dá)了系統(tǒng)必須做什么和參與者什么時(shí)候激活用例。用例文檔大概10頁左右，需要完整的表達(dá)用例的過程。用例名: 訂購配置了的電源設(shè)備用例類型用例ID:業(yè)務(wù)用例主要業(yè)務(wù)參與者:客戶描述：該用例允許客戶輸入一份購物訂單，該訂單包括提供運(yùn)送和發(fā)票地址，以及關(guān)于付款的詳細(xì)情況。前置條件：客戶通過瀏覽器進(jìn)入訂單輸入的Web頁面，該頁面顯示已配置電源設(shè)備及價(jià)格的詳細(xì)信息。當(dāng)客戶在訂單信息已經(jīng)顯示在屏幕上的時(shí)候，選擇“客戶”或者相似命名的功能鍵來確認(rèn)訂購所配置的電源設(shè)備的時(shí)候，該用例開始。后置條件：如果用例成功，購物訂單記錄進(jìn)系統(tǒng)的數(shù)據(jù)庫，否則系統(tǒng)的狀態(tài)不變。基本流程:1系統(tǒng)請求客戶輸入購買

38、細(xì)節(jié)，包括銷售人員的名字（如果知道的話）、運(yùn)送信息（客戶的名字和地址）、發(fā)票細(xì)節(jié)（如果運(yùn)送地址不同的話）、付款方法（信用卡和支票）以及任何其它注釋。2客戶選擇計(jì)算價(jià)格功能鍵來發(fā)送購買細(xì)節(jié)，系統(tǒng)通過客戶服務(wù)系統(tǒng)獲取這個(gè)等級的客戶銷售策略，然后計(jì)算購買價(jià)格。3客戶選擇購買功能鍵來發(fā)送訂單給系統(tǒng)。4系統(tǒng)給購買訂單賦與一個(gè)唯一的訂單號碼和客戶賬號，系統(tǒng)將訂單信息存入數(shù)據(jù)庫。 5系統(tǒng)把訂單號和客戶號與所有訂單細(xì)節(jié)一起e-mail給客戶，作為接受訂單的確認(rèn)。擴(kuò)展流程：2a，客戶對計(jì)算的價(jià)格有疑問，可以查閱客戶服務(wù)系統(tǒng)的相應(yīng)頁面，以查詢自己的客戶等級及當(dāng)前的銷售策略3a，客戶在提供所有要求錄入的信息之前，激

39、活購買功能鍵，系統(tǒng)將顯示錯(cuò)誤信息，它要求提供所漏掉的信息。3b，客戶選擇Reset（或其它相似命名）功能來恢復(fù)一個(gè)空白的購物表格，系統(tǒng)允許客戶重新輸入信息。七、用例的目標(biāo)1）基本業(yè)務(wù)過程的用例基本業(yè)務(wù)過程（EBP）是這樣定義的：由一個(gè)人在某個(gè)時(shí)間某個(gè)地點(diǎn)執(zhí)行一項(xiàng)任務(wù)，這項(xiàng)任務(wù)是對某一業(yè)務(wù)事件的反應(yīng)，而且可以增加可度量的業(yè)務(wù)價(jià)值，并且能夠保持?jǐn)?shù)據(jù)狀態(tài)的一致。其實(shí)這個(gè)定義過于教條，業(yè)務(wù)只能由一個(gè)人完成？兩個(gè)人就不行？所以對原則的理解不應(yīng)該教條主義的處理問題，用例強(qiáng)調(diào)了能夠增加可見的和可度量的業(yè)務(wù)價(jià)值，而且能夠使系統(tǒng)和數(shù)據(jù)處于穩(wěn)定和一致的狀態(tài)中。其實(shí)我們使用EBP原則的時(shí)候，主要是在對應(yīng)用進(jìn)行分析的

40、時(shí)候來尋找主要用例。2）用例和目標(biāo)參與者都有自己的目標(biāo)（或需要），因此，一個(gè)EBP級別上的用例，通常被稱之為一個(gè)用戶目標(biāo)級別上的用例。因此，處理問題的過程應(yīng)該是：首先找出用戶的目標(biāo)，然后為每個(gè)目標(biāo)定義一個(gè)用例。3）用EBP指導(dǎo)原則的實(shí)例作為一個(gè)系統(tǒng)分析師，在需求分析會上可以這樣了提出問題：系統(tǒng)分析師：在使用POS系統(tǒng)的時(shí)候，你的目標(biāo)是什么？收銀員：快速登錄還有收款系統(tǒng)分析師：你認(rèn)為登錄更高級別上的目標(biāo)什么？收銀員：我要向系統(tǒng)證明身份，這樣才能允許我使用系統(tǒng)系統(tǒng)分析師：比這更高的目標(biāo)呢？收銀員：防止盜竊、數(shù)據(jù)崩潰，不顯示不宜公開的企業(yè)信息。我們分析一下這段對話?！胺乐贡I竊、數(shù)據(jù)崩潰，不顯示不宜公

41、開的企業(yè)信息”實(shí)際上比起用戶目標(biāo)要高，可以認(rèn)為是企業(yè)目標(biāo)，所以在此不做考慮?！拔乙蛳到y(tǒng)證明身份，這樣才能允許我使用系統(tǒng)”看起來接近于用戶目標(biāo)，但它不是EBP級別上的行為，因?yàn)樗粫黾涌梢姷幕蛘呖梢远攘康臉I(yè)務(wù)價(jià)值，它是為期它目標(biāo)服務(wù)的。而“完成一次銷售”是符合EBP原則的更高一級目標(biāo)。第五節(jié) 非功能性需求的識別僅僅寫出用例還是不夠的，還需要識別其它種類的需求，這些將被包含在補(bǔ)充規(guī)范中。例如：簡介功能性日志和錯(cuò)誤處理安全性人性因素可靠性 可恢復(fù)性性能適應(yīng)性可配置性實(shí)現(xiàn)約束 比如開發(fā)的領(lǐng)導(dǎo)層堅(jiān)持要使用Java開發(fā)。采購的組件免費(fèi)開放源碼的組件接口值得注意的硬件和接口觸摸屏條碼掃描儀數(shù)據(jù)打印機(jī)信用

42、卡讀卡器簽名讀取器（第一版中不支持）術(shù)語表術(shù)語定義和相關(guān)信息商品銷售的產(chǎn)品或服務(wù)支付授權(quán)一外部的支付授權(quán)服務(wù)提供驗(yàn)證，保證銷售者得到支付支付授權(quán)請求以電子方式發(fā)送到支付授權(quán)系統(tǒng)的一組元素，通常是字符串，這些元素包括：商場ID，顧客賬號，數(shù)據(jù)和時(shí)戳術(shù)語表也可以作為數(shù)據(jù)字典使用。第六節(jié) 合理的應(yīng)用活動分析一、為什么要應(yīng)用活動建模上面用文字表示用例事件流，可以很細(xì)膩的表達(dá)一些用例的過程，但是，當(dāng)用例的事件流比較復(fù)雜的時(shí)候，單純用文字表達(dá)難以清楚的表示相互之間的關(guān)系，特別是一些并發(fā)關(guān)系，這時(shí)，可以借用活動圖來表示，活動圖更善于表達(dá)流程和并發(fā)關(guān)系?；顒訄D表示了計(jì)算的步驟，每一步都是一個(gè)關(guān)于干什么事的狀態(tài)

43、。因?yàn)檫@個(gè)原因，執(zhí)行步驟被稱之為活動狀態(tài)。這個(gè)圖表示了哪步應(yīng)該按次序執(zhí)行，哪步可以并行進(jìn)行，從一個(gè)活動狀態(tài)到另一個(gè)活動狀態(tài)的轉(zhuǎn)換，稱之為“轉(zhuǎn)換”。如果用例文檔完成了，活動狀態(tài)可以從主要的和附加的流中間發(fā)現(xiàn)。但是用例描述和活動模型之間存在著一些重要的區(qū)別，用例描述是從外部參與者的角度出發(fā)來編寫的，而活動模型則采用內(nèi)部系統(tǒng)的觀點(diǎn)?；顒訄D也可以在用例編寫以前，在一個(gè)高的抽象層次來理解業(yè)務(wù)進(jìn)程。活動如果活動建模是為了表達(dá)可視化用例中活動的次序，則活動狀態(tài)可以根據(jù)用例文檔來建立，這時(shí)，活動應(yīng)該從系統(tǒng)的角度，而不是參與者的角度來命名?；顒訄D形也可以表達(dá)活動狀態(tài)和活動行為?；顒雍托袨榈膮^(qū)別在于其時(shí)間跨度，活

44、動是要花時(shí)間來完成的，而行為則可看成快照，被認(rèn)為是不花時(shí)間的。活動視圖（Activity Diagram）主要用于對計(jì)算流程和工作流程建模，它很類似于面向過程建模中的流程圖。使用活動圖可以表示由內(nèi)部生成的動作驅(qū)動的事件流，活動圖能提醒您注意并展示并行的和同時(shí)發(fā)生的活動。比較適合建立工作流模型。下面是一個(gè)訂單處理的活動圖。 泳道：將模型中的活動按照職責(zé)組織起來通常很有用。例如，可以將一個(gè)商業(yè)組織處理的所有活動組織起來。這種分配可以通過將活動組織成用線分開的不同區(qū)域來表示。由于它們的外觀的緣故，這些區(qū)域被稱作泳道。 下圖表示了一個(gè)銷售過程的活動。 活動圖并沒有表示出計(jì)算處理過程中的全部細(xì)節(jié)內(nèi)容。它

45、只是表示了活動進(jìn)行的流程但沒表示出執(zhí)行活動的對象?；顒訄D是設(shè)計(jì)工作的起點(diǎn)。為了完成設(shè)計(jì)，每個(gè)活動必須擴(kuò)展細(xì)分成一個(gè)或多個(gè)操作，每個(gè)操作被指定到具體類。這種分配的結(jié)果引出了用于實(shí)現(xiàn)活動圖的設(shè)計(jì)工作。二、案例：訂單處理子系統(tǒng)1，發(fā)現(xiàn)活動針對上面已經(jīng)建立了用例的關(guān)于電源設(shè)備采購的例子，我們從系統(tǒng)用例的描述，來找出活動，注意，活動是站在設(shè)備的角度來描述的。編號用例描述活動狀態(tài)1當(dāng)客戶在訂單信息已經(jīng)顯示在屏幕上的時(shí)候，選擇“客戶”或者相似命名的功能鍵來確認(rèn)訂購所配置的電源設(shè)備的時(shí)候，該用例開始。顯示當(dāng)前配置；獲得客戶請求2系統(tǒng)請求客戶輸入購買細(xì)節(jié)，包括銷售人員的名字（如果知道的話）、運(yùn)送信息（客戶的名字

46、和地址）、發(fā)票細(xì)節(jié)（如果運(yùn)送地址不同的話）、付款方法（信用卡和支票）以及任何其它注釋。顯示購買窗體3系統(tǒng)由銷售服務(wù)系統(tǒng)取得客戶的等級以及當(dāng)前銷售策略，計(jì)算客戶購買的實(shí)際價(jià)格。顯示購買價(jià)格4客戶選擇Purchase（購買，或者相似命名的）功能鍵來發(fā)送訂單給TB公司。獲得購買詳細(xì)資料5系統(tǒng)給購買訂單賦與一個(gè)唯一的訂單號碼和客戶賬號，系統(tǒng)將訂單信息存入數(shù)據(jù)庫。存儲訂單6系統(tǒng)把訂單號和客戶號與所有訂單細(xì)節(jié)一起e-mail給客戶，作為接受訂單的確認(rèn)。Email訂單資料7客戶在提供所有要求錄入的信息之前，激活Purchase（或者相似命名的）功能鍵，系統(tǒng)將顯示錯(cuò)誤信息，它要求提供所漏掉的信息。獲得購買詳細(xì)

47、資料顯示購買窗體8客戶選擇Reset（或其它相似命名）功能來恢復(fù)一個(gè)空白的購物表格，系統(tǒng)允許客戶重新輸入信息。顯示購買窗體把標(biāo)識的活動畫出來。2，活動圖把活動用轉(zhuǎn)換連線連接起來，就成為活動圖?！帮@示當(dāng)前配置”是初始活動狀態(tài)，在這個(gè)活動上有一個(gè)遞歸轉(zhuǎn)換的表達(dá)，描述在進(jìn)行下一個(gè)活動以前，這個(gè)活動一直在反復(fù)執(zhí)行。這個(gè)方式強(qiáng)調(diào)了這是活動而不是行為。當(dāng)活動轉(zhuǎn)換為“顯示購買窗體”的時(shí)候，timeout將終止這個(gè)活動模型的執(zhí)行，或者“獲得購買詳細(xì)資料”的活動被激活。如果購買資料不完全，系統(tǒng)又回到“顯示購買窗體”，否則進(jìn)入“存儲訂單”。并且接著進(jìn)入“Email訂單資料”，然后活動結(jié)束。一般來說，只有“退出”活

48、動狀態(tài)被顯示出來，一般活動內(nèi)部的分支，可以推斷出來。有時(shí)候重要的分支可以使用分支，并附上監(jiān)護(hù)條件。三、客戶服務(wù)子系統(tǒng)用例分析下面，我們來研究一下另外一個(gè)重要的子系統(tǒng)，客戶服務(wù)子系統(tǒng)的用例分析。1，發(fā)現(xiàn)參與者客戶服務(wù)子系統(tǒng)主要實(shí)現(xiàn)客戶分級管理策略，而且可以靈活的處理促銷策略，從項(xiàng)目影響范圍的研究中，我們可以發(fā)現(xiàn)參與者。參與者詞匯表參與者描述基本客戶已經(jīng)有穩(wěn)定業(yè)務(wù)往來的公司。潛在客戶預(yù)計(jì)可能有業(yè)務(wù)往來的公司。曾經(jīng)客戶過去有業(yè)務(wù)往來，但是最近6個(gè)月內(nèi)沒有購買設(shè)備，但仍然保持良好的身份記錄。市場部響應(yīng)創(chuàng)建折扣和訂閱程序，并為公司進(jìn)行銷售的組織部門?？蛻舴?wù)部按照合同為客戶提供聯(lián)系服務(wù)的組織部門。財(cái)務(wù)部

49、門處理客戶付款和收費(fèi)，以及維護(hù)客戶賬戶信息的組織部門。時(shí)間觸發(fā)時(shí)序事件的參與者。倉庫管理子系統(tǒng)存儲和維護(hù)TB公司產(chǎn)品庫存，并且處理顧客發(fā)貨和退貨的實(shí)體。網(wǎng)上銷售子系統(tǒng)實(shí)現(xiàn)基于Web的電源產(chǎn)品銷售。2，確定業(yè)務(wù)需求用例與已經(jīng)建立的網(wǎng)上訂購項(xiàng)目相比，這個(gè)新系統(tǒng)的最大特點(diǎn)，是把市場行為作為系統(tǒng)的重要功能，所以功能上和以前的系統(tǒng)有諸多不同。首先我們需要記錄項(xiàng)目的初始范圍，也就是定義一個(gè)系統(tǒng)應(yīng)該準(zhǔn)備支持的業(yè)務(wù)方向，這就是所謂系統(tǒng)上下文數(shù)據(jù)流圖，其方法是：1，區(qū)分內(nèi)部和外部，忽略內(nèi)部工作，專注于外部功能。2，詢問最終用戶系統(tǒng)需要響應(yīng)什么業(yè)務(wù)事務(wù)，這些業(yè)務(wù)事務(wù)就是系統(tǒng)的凈輸入。3，詢問最終用于系統(tǒng)需要有什么

50、響應(yīng)，這些相應(yīng)就是系統(tǒng)的凈輸出。4，確定外部數(shù)據(jù)存儲，以實(shí)體的形式表達(dá)，數(shù)據(jù)庫和文件一般是屬于外部的。注意：系統(tǒng)上下文并不是越復(fù)雜越好，而是要把握系統(tǒng)功能的重點(diǎn)，細(xì)節(jié)問題可以在后面的詳細(xì)分析中解決。下面是這個(gè)項(xiàng)目子系統(tǒng)的上下文。在這個(gè)系統(tǒng)中定義邊界的時(shí)候，可以考慮把網(wǎng)上銷售子系統(tǒng)暫時(shí)排除在外，也就是把網(wǎng)上銷售子系統(tǒng)定義成外部接受者。我們可以建立一些用例并定義它的詞匯。編號用例名稱用例描述預(yù)期的參與者和角色1提交訂閱訂單描述一個(gè)潛在客戶通過訂閱加入本系統(tǒng)，這個(gè)潛在客戶至少答應(yīng)在兩年內(nèi)購買一定數(shù)量的本公司設(shè)備。潛在客戶2提交訂閱更新訂單描述一個(gè)過去的客戶通過訂閱加入本系統(tǒng)，這個(gè)客戶過去是本公司的基

51、本客戶，盡管6個(gè)月內(nèi)這個(gè)活動一度中斷，但現(xiàn)在準(zhǔn)備恢復(fù)商業(yè)活動。曾經(jīng)客戶3提交客戶資料修改描述一個(gè)基本客戶修改他的個(gè)人資料，包括公司地址、e-mail、密碼和基本購買配置方式。基本客戶4處理訂單和客戶資料描述一個(gè)客戶通過網(wǎng)上銷售子系統(tǒng)提交一個(gè)TB公司產(chǎn)品訂單，以及有關(guān)的客戶資料，等待客戶服務(wù)子系統(tǒng)返回相關(guān)的折扣信息。網(wǎng)上銷售子系統(tǒng)市場部5查詢購買歷史描述一個(gè)基本客戶查閱他三年內(nèi)的購買歷史?；究蛻?建立新客戶訂閱程序描述市場部建立一個(gè)新的客戶訂閱計(jì)劃（在什么情況下可以得到更大的優(yōu)惠）來吸引新的客戶。市場部7提交訂閱程序修改描述市場部為基本客戶修改訂閱計(jì)劃，比如優(yōu)惠期的延長等等。市場部8提交曾經(jīng)客

52、戶重新訂閱程序描述市場部建立一個(gè)重新訂閱計(jì)劃，比如曾經(jīng)客戶可以更短的時(shí)間內(nèi)享受到優(yōu)惠，以吸引回曾經(jīng)客戶。市場部9提交新促銷描述市場部建立一個(gè)新的促銷計(jì)劃，以吸引不同的客戶來購買。需要注意，促銷計(jì)劃一般有專門的名稱，以表明在某種情況下可以以特殊的價(jià)格來購買。這些促銷產(chǎn)品可以集成到一個(gè)特殊的目錄中在網(wǎng)上公布，并且通過e-mail發(fā)送給基本客戶。市場部10修改促銷描述市場部修改促銷條件。市場部11每日生成默認(rèn)合同報(bào)告描述每天生成一個(gè)報(bào)告，列出還沒有達(dá)到“優(yōu)惠級基本客戶”購買量的基本客戶，這些客戶購買量以30天、60天、120天過期三個(gè)級別排序。時(shí)間（發(fā)起）客戶服務(wù)部（外部接收者）注：參與者沒有標(biāo)注的為主要業(yè)務(wù)參與者，表達(dá)他收到了某些可度量的價(jià)值。這樣就可以畫出系統(tǒng)的用例圖。注意這個(gè)圖中，并沒有致力于包含和依賴關(guān)系的研究，這是因?yàn)閳D形比較復(fù)雜的時(shí)候，有些事情單獨(dú)考慮更有利，比如我們會在后面單獨(dú)考慮依賴關(guān)系，并且以此生成開發(fā)策略。3，撰寫用例文檔為了更清楚的表達(dá)用例的事件流，需要寫出用例文檔，這里只列出了“處理訂單和客戶資料”用例的文檔。電源客戶服務(wù)系統(tǒng)作者: _日期:_版本:_用例名: 處理訂單和客戶資料用例類型用例ID:TB-ES2.00業(yè)務(wù)需求主要業(yè)務(wù)參與者:網(wǎng)上設(shè)備銷售子系統(tǒng)其它參與者:基本客戶，曾經(jīng)客戶，潛在客戶銷售部（外部接收者）財(cái)務(wù)部（外部接收者）