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

1、第二章 需求過程與分析的核心理論架構(gòu)設(shè)計過程分為兩個階段：高層設(shè)計階段和詳細設(shè)計階段。高層設(shè)計階段的重點是軟件系統(tǒng)的體系結(jié)構(gòu)設(shè)計。詳細設(shè)計階段的重點是用戶界面設(shè)計、數(shù)據(jù)庫設(shè)計和模塊設(shè)計。而高層設(shè)計的信息，主要來自于需求分析。第一節(jié) 需求過程在軟件架構(gòu)中的重要作用作為一個架構(gòu)師，工作的主要舞臺是系統(tǒng)設(shè)計，但設(shè)計的輸入來自于需求工程，什么樣的需求思想，就有什么樣的架構(gòu)思維。這就是說，合理而且正確的需求分析過程，是架構(gòu)設(shè)計過程的一個有機的組成部分，所以，我們首先必須討論需求分析的領(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)致項目發(fā)生混亂。需求的類型：作為一個檢查表，需求可以按照FURPS+模型進行分類的，每個字母含義如下：F：功能性（Functional）：特性、能力、安全性。U：可用性（Usability）：人性化因素，幫助，文檔。R：可靠性（Reliability）：故障周期，可恢

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

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

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

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

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

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

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

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

11、的“訂單處理子系統(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)造一個或者多個系統(tǒng)或者子系統(tǒng)中所有事件相互關(guān)系的系統(tǒng)圖也是有意義的。在繪制系統(tǒng)圖的時候，必須平衡不同

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

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

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

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

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

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

18、用例不需要了解擴展用例的如何細節(jié)。例如，保存人員信息用例可以是刪除人員信息及新增和修改人員信息用例的擴展，它們之間存在著擴展關(guān)系。如果特定的條件發(fā)生，擴展用例的行為才能執(zhí)行。其圖形表示方法為在用例圖上用一條從基本用例指向擴展用例的虛箭線表示，并在線上標(biāo)注購造型：三、用例圖及其表達原則用例圖主要表現(xiàn)各個用例之間寬泛的關(guān)系，如下圖所示。在上面的圖中，計算機系統(tǒng)的參與者有兩種表示法，其中有些人喜歡用不同于人型的方框表示外部計算機系統(tǒng)參與者，稱作UML構(gòu)造型，這是用某種方式分類元素的方式夠造型的名稱被書名符號包住，這本來就是法文印刷中表示引用的符號。注意：主要參與者和用戶目標(biāo)和系統(tǒng)邊界有關(guān)有個問題，在

19、“處理銷售”用例中，為什么主要參與者是收銀員而不是顧客呢？這和系統(tǒng)邊界有關(guān)，我們定義的銷售系統(tǒng)邊界，服務(wù)目標(biāo)是收銀員。如果把系統(tǒng)邊界定義為企業(yè)交款服務(wù)，那顧客就是一個主要參與者了。我們也可以通過事件分析找出參與者。第四節(jié) 用例的事件流與用例文檔用例的事件流是對完成用例行為所需的事件的描述。事件流描述了系統(tǒng)應(yīng)該做什么，而不是怎么做?？梢酝ㄟ^一個清晰的，易被用戶理解的時間流來說明一個用例的行為。在事件流中包括用例何時開始和結(jié)束，用例何時和參與者交互，什么對象被交互以及該行為的基本流和可選流。一、用例的事件流的組成（1）用例事件流所應(yīng)該包含的內(nèi)容簡要說明：描述該使用案例的作用（可以不寫出）；前置條件

20、：開始使用該用例之前必須滿足的系統(tǒng)和環(huán)境的狀態(tài)和條件（必要條件而不是充分條件）主事件流：用例的正常流程（事件流是關(guān)注系統(tǒng)干什么，而不是怎么干），也稱為用例的路徑。其它（備選）事件流：用例的非正常流程，如錯誤流程后置條件：用例成功結(jié)束后系統(tǒng)應(yīng)該具備的狀態(tài)和條件（但不是每個用例都有后置條件）（2）主事件流（用例的路徑）可能包含有基本路徑、備選路徑、異常路徑、成功路徑和失敗路徑等幾個方面的內(nèi)容。二、描述用例的事件流的主要方式1，面向過程語言：每個用例只描述沒有大的分支的行為的單個線索，在事件流中要對事件流進行面向過程說明（主事件流和備選事件流）。2，UML的活動圖（系統(tǒng)活動圖-和用例活動圖）：使用活

21、動圖可以表示由內(nèi)部生成的動作驅(qū)動的事件流，活動圖能提醒您注意并展示并行的和同時發(fā)生的活動。這使得活動圖成為建立工作流模型、分析用例以及處理多線程應(yīng)用程序的得力工具。三、事件流描述文檔的基本要求1）首先寫出基本的路徑這是最主要的事情，因為它是用戶最關(guān)心或者最想看到的內(nèi)容。2）用例交互的四步曲1，參與者產(chǎn)生某個行為動作；2，然后系統(tǒng)對此動作進行響應(yīng)；3，響應(yīng)成功后再根據(jù)動作的要求進行狀態(tài)的改變；4，最后將改變后的結(jié)果再回饋給參與者。3）模板格式用例的模版可以有不同的形式，關(guān)鍵是要表達清楚：作者: _日期: _版本: _用例名: 用例類型用例ID:主要業(yè)務(wù)參與者:其它參與者:項目相關(guān)人員興趣:描述：

22、前置條件：后置條件：觸發(fā)條件:基本流程:擴展流程：結(jié)束:業(yè)務(wù)規(guī)則：實現(xiàn)約束和說明：假設(shè)：待解決問題:對于上述一些時間流，以及一些關(guān)鍵和重要的問題，需要對用例進行詳細設(shè)計，這是需要使用文檔而不是圖。四、用例文檔中幾個元素的解釋1）序言元素要把最重要的元素放在一開始。而把一些不重要的“標(biāo)題”材料放在末尾。用戶興趣列表：這個列表很重要也很實用。用例作為行為的契約，撲獲所有與滿足客戶興趣有關(guān)的行為。這就回答了一個問題，用例應(yīng)該包含什么？答：用例應(yīng)該包含滿足所有客戶感興趣的內(nèi)容，另外，在寫出用例所有部分之前，需要確定用戶及其興趣。例如，如果我們沒有列出“銷售人員提成”的興趣，在開始部分我們可能會漏掉這個

23、職責(zé)。以客戶興趣作為視點來觀察，會給我們提供一種徹底的、系統(tǒng)化的程序，用來發(fā)現(xiàn)和記錄所有必需的行為。例：項目相關(guān)人員的興趣：收銀員：希望能夠準(zhǔn)確快速的輸入，沒有支付錯誤。售貨員：希望自動更新銷售提成。等。2）前置條件和后置條件（成功后的保證）前置條件：規(guī)定了用例一個場景開始之前必須為“真”的條件。前置條件在用例中不會被檢驗，我們假定它已經(jīng)被滿足，通常前置條件是已經(jīng)成功完成的其它用例的一個場景。比如：“系統(tǒng)已經(jīng)被登錄”或“收銀員已經(jīng)被識別和授權(quán)”。但不要包括沒有價值的條件，比如“系統(tǒng)已經(jīng)被供電”。前置條件主要表達讀者應(yīng)該引起警惕的或者值得注意的那些假設(shè)。后置條件：后置條件也叫“成功后的保證”，表

24、達了用例成功結(jié)束以后必須為真的條件，這個“保證”應(yīng)該滿足所有客戶方的需要。這里所有的客戶方，指的是所有參與使用項目的人員。例：前置條件：收銀員已經(jīng)被識別和授權(quán)。后置條件：存儲銷售信息，準(zhǔn)確計算稅金，更新賬目和庫存，記錄提成，生成收據(jù)。3）基本流程我們可以把主要成功場景成做“基本流程”，它描述了能滿足客戶興趣的典型成功路徑。一般它不包括任何條件和分支，而把條件和分支放在“擴展”部分說明。場景記錄以下三種步驟：1）參與者之間的交互。2）一個驗證動作（通常由系統(tǒng)來完成）。3）由系統(tǒng)完成的狀態(tài)改變。例：注意表示重復(fù)的習(xí)慣用法主要成功場景：1顧客攜帶購買的商品到達POS機收費口2收銀員開始一次新的銷售3

25、收銀員輸入商品標(biāo)識4.重復(fù) 3 4 步，直到結(jié)束。53）擴展擴展又稱之為“替代流程”，它說明了所有其它的場景和分支。擴展往往比主要成功場景長而且復(fù)雜，這正是我們所希望的。在寫完整用例的時候，基本流程加上擴展能滿足幾乎所有客戶的興趣。擴展場景是從主要成功場景中分離出來的，所以標(biāo)記方式應(yīng)該相同，比如，第3步的一個擴展就被標(biāo)記為3a。擴展：3a.非法標(biāo)識 1系統(tǒng)指示錯誤并拒絕輸入。3b.多個具有相同類別的商品，不需要跟蹤每個商品的唯一身份1 收銀員可以輸入商品類別的表識和數(shù)量。3c.顧客要求從藝術(shù)如商品中減去一個商品 1收銀員輸入商品標(biāo)識并將其刪除。 2系統(tǒng)顯示更新后的累加值。.一個“擴展”有兩部分

26、組成：條件和處理，處理的步驟可以有多個。有時候擴展可能會非常復(fù)雜，這就需要用單個用例來完成擴展。下面看看怎么標(biāo)記擴展中的失?。?b.信用卡支付1.顧客輸入信用卡賬號2.系統(tǒng)向外部信用卡授權(quán)服務(wù)系統(tǒng)請求支付驗證2a系統(tǒng)檢測到和外部信用卡授權(quán)服務(wù)系統(tǒng)通信故障1. 系統(tǒng)向收銀員知識發(fā)生了錯誤2.收銀員向客戶請求更換支付方式3.如果想要描述一個可能在任何一步（至少是絕大多數(shù)步驟）都會發(fā)生的條件，那么應(yīng)該使用類似“*a”、“*b”這樣的標(biāo)記。*a.任何時刻，發(fā)生一下狀況，系統(tǒng)將會崩潰。1收銀員重啟系統(tǒng)，登錄，請求恢復(fù)上次狀態(tài)。2系統(tǒng)重建之前的狀態(tài)。4）特殊需求如果有一些與這個用例有關(guān)的非功能性需求（質(zhì)量

27、屬性或約束條件），那么應(yīng)該把他們記錄在一起。例：特殊需求在大型平板顯示器上觸摸屏界面，文本信息要能在一米之外看清。90%信用卡授權(quán)機構(gòu)的響應(yīng)，應(yīng)該能在30秒之內(nèi)收到。支持多種語言顯示。在步驟2和步驟6種可以插入新的業(yè)務(wù)規(guī)則。經(jīng)典的統(tǒng)一過程建議，第一次寫出用例的時候，把特殊需求和用例寫在一起。但現(xiàn)在更通用的做法是把所有非功能性需求放在“補充規(guī)范”中，這樣更容易進行內(nèi)容管理，也更容易讀，因為這些需求通常要求在進行系統(tǒng)整體架構(gòu)分析的時候通盤考慮。5）技術(shù)和數(shù)據(jù)的變化列表系統(tǒng)通常有一些技術(shù)上的變化是關(guān)于“應(yīng)該怎樣做”，而不是“應(yīng)該做什么”，需要在用例中把這些變化記錄下來。比如，數(shù)據(jù)表示方案可能會有不同

28、的變化，在列表中應(yīng)該記錄這種變化。技術(shù)和數(shù)據(jù)的變化列表：3a. 商品標(biāo)識可以用條碼掃描也可以用鍵盤輸入。3b. 商品表識可以采用UPC、EAN、JAN、SKU等不同的編碼方式。7a. 信用卡賬號信息可以使用讀卡器或鍵盤輸入。7b. 記錄在紙面收據(jù)上的信用卡支付簽名，但我們預(yù)測，兩年內(nèi)會有許多顧客希望使用數(shù)字簽名。五、示例：銷售系統(tǒng)這里為了把問題表達清楚，添加了一些項目。舉個例子。POS銷售系統(tǒng)作者: _日期: _版本: _用例名: Process Sale用例類型用例ID:TB-SALE2.00業(yè)務(wù)需求主要業(yè)務(wù)參與者:收銀員項目相關(guān)人員興趣:收銀員：希望能準(zhǔn)確、快速的輸入，而且沒有支付錯誤。l

29、售貨員：希望自動更新銷售提成。l顧客：希望購買過程能夠省力，并得到快速服務(wù)，希望得到購買證明，以便退貨。l公司：希望準(zhǔn)確的記錄交易，并滿足顧客要求，希望保證支付授權(quán)服務(wù)的信息被記錄，希望有一定的容錯性，即使某些服務(wù)不可用也能允許收款，希望能自動快速的更新賬目和庫存信息。l政府稅務(wù)機關(guān)：希望從每筆交易中抽取稅金。l支付授權(quán)服務(wù)：希望按照正確的格式和協(xié)議收到數(shù)字授權(quán)的請求，希望準(zhǔn)確計算給商店的應(yīng)付款。前置條件：收銀員已經(jīng)被識別和授權(quán)。后置條件：存儲銷售信息，準(zhǔn)確計算稅金，更新賬目和庫存，記錄提成，生成收據(jù)。觸發(fā)條件:當(dāng)客戶開始驗證購買的商品的時候，該用例被觸發(fā)。基本流程：1顧客攜帶購買的商品到達P

30、OS機收費口2收銀員開始一次新的銷售3收銀員輸入商品標(biāo)識4.重復(fù) 3 4 步，直到結(jié)束。5.10顧客攜帶商品和收據(jù)離開替代流程*a.任何時刻，發(fā)生以下狀況，系統(tǒng)將會崩潰。1收銀員重啟系統(tǒng)，登錄，請求恢復(fù)上次狀態(tài)。2系統(tǒng)重建之前的狀態(tài)。3a.非法標(biāo)識 1系統(tǒng)指示錯誤并拒絕輸入。3b.多個具有相同類別的商品，不需要跟蹤每個商品的唯一身份2收銀員可以輸入商品類別的標(biāo)識和數(shù)量。3-6a.顧客要求從已輸入商品中減去一個商品 1收銀員輸入商品標(biāo)識并將其刪除。 2系統(tǒng)顯示更新后的累加值。.7b.信用卡支付1.顧客輸入信用卡賬號2.系統(tǒng)向外部信用卡授權(quán)服務(wù)系統(tǒng)請求支付驗證2a系統(tǒng)檢測到和外部信用卡授權(quán)服務(wù)系統(tǒng)

31、通信故障2.系統(tǒng)向收銀員指示發(fā)生了錯誤2.收銀員向客戶請求更換支付方式結(jié)束:當(dāng)客戶完成支付，該用例結(jié)束。特殊需求：1，在大型平板顯示器上觸摸屏界面，文本信息要能在一米之外看清。2，90%信用卡授權(quán)機構(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、SKU等不同的編碼方式。7a. 信用卡賬號信息可以使用讀卡器或鍵盤輸入。7b. 記錄在紙面收據(jù)上的信用卡支付簽名，但我們預(yù)測，兩年內(nèi)會有許多顧客希望使用數(shù)字簽名。發(fā)生頻率：可能會持續(xù)發(fā)

32、生。待解決問題:1，什么是稅法的變化？2，研究遠程服務(wù)的恢復(fù)問題3，不同的業(yè)務(wù)需要什么樣的定制？4，收銀員是否必須在退出系統(tǒng)以后帶走他的現(xiàn)金抽屜？5，顧客是否可以直接使用讀卡器，而不需要收銀員代勞？這個例子雖然不完整，但是一個實際的例子，足以給我們提供一個真實的感受。在統(tǒng)一過程中提倡一種簡樸的書寫風(fēng)格，也就是不考慮用戶界面，而專注于他們的意圖，只對用戶意圖和系統(tǒng)職責(zé)這一級描述，這點很重要。六、案例：訂單處理子系統(tǒng)1、問題陳述：與過程分析相同。2、參與者通過如下分析，把問題條理化，發(fā)現(xiàn)參與者，注意，描述的時候不要使用隱語。比如：要e-mail給客戶；正確的：銷售人員要e-mail給客戶。1，客戶

33、使用公司的的Web頁面查看所選擇的電源設(shè)備標(biāo)配，同時顯示價格。2，客戶查看配置細節(jié)，可以更改配置，同時計算價格。3，客戶選擇訂購，也可以要求銷售人員在訂單真正發(fā)出之前和自己聯(lián)系，解釋有關(guān)細節(jié)。4，要發(fā)出訂單，客戶必須填寫表格，包括地址，付款細節(jié)（信用卡還是支票）等。5，客戶訂單送到系統(tǒng)之后， 系統(tǒng)由客戶服務(wù)系統(tǒng)取得該客戶的等級，以及由銷售策略決定的折扣。6，銷售人員發(fā)送電子請求到倉庫管理系統(tǒng)，并且附上配置細節(jié)。7，事務(wù)的細節(jié)（包括訂單號和客戶帳戶號），銷售人員要e-mail給客戶，使得客戶可以在線查詢訂單狀態(tài)。8，倉庫從銷售人員處獲取發(fā)票，并且向客戶運送電源設(shè)備。從中我們可以發(fā)現(xiàn)四個參與者：客

34、戶；銷售人員；倉庫管理系統(tǒng)；客戶服務(wù)系統(tǒng)。3、建立用例用例表示一個完整的給用戶傳值的功能單元，不與用例通信的參與者是沒有意義的，但用例可以只為泛化，而不與參與者通信。我們可以建立一個表來分析，把功能需求賦予參與者和用例。注意，有些潛在的業(yè)務(wù)功能可能不在應(yīng)用范圍只內(nèi)，它們不能被轉(zhuǎn)換為用例，比如倉庫裝配電源設(shè)備并且把它運送給客戶，這個任務(wù)已經(jīng)超出這個系統(tǒng)的業(yè)務(wù)范圍，不能作為用例。編號需求參與者用例1客戶使用電源部的Web頁面查看所選擇的電源設(shè)備標(biāo)配，同時顯示價格?？蛻麸@示標(biāo)準(zhǔn)電源配置2客戶查看配置細節(jié)，可以更改配置?？蛻魳?gòu)造電源配置3系統(tǒng)由客戶服務(wù)系統(tǒng)取得該客戶的等級，以及由銷售策略決定的折扣，同

35、時計算價格。客戶客戶服務(wù)系統(tǒng)獲取銷售策略4客戶選擇訂購，也可以要求銷售人員在訂單真正發(fā)出之前和自己聯(lián)系，解釋有關(guān)細節(jié)。客戶銷售人員訂購配置了的電源設(shè)備請求與銷售人員聯(lián)系5要發(fā)出訂單，客戶必須填寫表格，包括地址，付款細節(jié)（信用卡還是支票）等?？蛻粲嗁徟渲昧说碾娫丛O(shè)備效驗和認(rèn)可客戶付款6銷售人員發(fā)送電子請求到倉庫管理系統(tǒng)，并且附上配置細節(jié)。銷售人員倉庫管理系統(tǒng)通知倉庫關(guān)于訂購信息7事務(wù)的細節(jié)（包括訂單號和客戶帳戶號），銷售人員要e-mail給客戶，使得客戶可以在線查詢訂單狀態(tài)。銷售人員客戶訂購配置了的電源設(shè)備更新訂購狀況8倉庫管理系統(tǒng)從銷售人員處獲取發(fā)票，并且向客戶運送電源設(shè)備倉庫管理系統(tǒng)銷售人員

36、打印發(fā)票可以建立如下用例：4、用例圖用例圖的作用是把用例賦給參與者，用例圖是系統(tǒng)行為模型的主要可視化技術(shù)。還可以建立用例之間的關(guān)系，比如圖中Extend表示“訂購配置了的計算機”可以被“客戶”擴展為“請求與銷售人員聯(lián)系”。而訂購配置了的電源設(shè)備包含了（include）獲取銷售策略的行為，這種依賴關(guān)系，表達了獲取銷售策略的用例不能獨立存在，只能作為包含它的訂購配置了的電源設(shè)備用例的一部分。5、編寫用例文檔用例必須用事件流文檔來描述，這個文檔表達了系統(tǒng)必須做什么和參與者什么時候激活用例。用例文檔大概10頁左右，需要完整的表達用例的過程。用例名: 訂購配置了的電源設(shè)備用例類型用例ID:業(yè)務(wù)用例主要業(yè)

37、務(wù)參與者:客戶描述：該用例允許客戶輸入一份購物訂單，該訂單包括提供運送和發(fā)票地址，以及關(guān)于付款的詳細情況。前置條件：客戶通過瀏覽器進入訂單輸入的Web頁面，該頁面顯示已配置電源設(shè)備及價格的詳細信息。當(dāng)客戶在訂單信息已經(jīng)顯示在屏幕上的時候，選擇“客戶”或者相似命名的功能鍵來確認(rèn)訂購所配置的電源設(shè)備的時候，該用例開始。后置條件：如果用例成功，購物訂單記錄進系統(tǒng)的數(shù)據(jù)庫，否則系統(tǒng)的狀態(tài)不變?；玖鞒?1系統(tǒng)請求客戶輸入購買細節(jié)，包括銷售人員的名字（如果知道的話）、運送信息（客戶的名字和地址）、發(fā)票細節(jié)（如果運送地址不同的話）、付款方法（信用卡和支票）以及任何其它注釋。2客戶選擇計算價格功能鍵來發(fā)送購

38、買細節(jié)，系統(tǒng)通過客戶服務(wù)系統(tǒng)獲取這個等級的客戶銷售策略，然后計算購買價格。3客戶選擇購買功能鍵來發(fā)送訂單給系統(tǒng)。4系統(tǒng)給購買訂單賦與一個唯一的訂單號碼和客戶賬號，系統(tǒng)將訂單信息存入數(shù)據(jù)庫。 5系統(tǒng)把訂單號和客戶號與所有訂單細節(jié)一起e-mail給客戶，作為接受訂單的確認(rèn)。擴展流程：2a，客戶對計算的價格有疑問，可以查閱客戶服務(wù)系統(tǒng)的相應(yīng)頁面，以查詢自己的客戶等級及當(dāng)前的銷售策略3a，客戶在提供所有要求錄入的信息之前，激活購買功能鍵，系統(tǒng)將顯示錯誤信息，它要求提供所漏掉的信息。3b，客戶選擇Reset（或其它相似命名）功能來恢復(fù)一個空白的購物表格，系統(tǒng)允許客戶重新輸入信息。七、用例的目標(biāo)1）基本業(yè)

39、務(wù)過程的用例基本業(yè)務(wù)過程（EBP）是這樣定義的：由一個人在某個時間某個地點執(zhí)行一項任務(wù)，這項任務(wù)是對某一業(yè)務(wù)事件的反應(yīng)，而且可以增加可度量的業(yè)務(wù)價值，并且能夠保持?jǐn)?shù)據(jù)狀態(tài)的一致。其實這個定義過于教條，業(yè)務(wù)只能由一個人完成？兩個人就不行？所以對原則的理解不應(yīng)該教條主義的處理問題，用例強調(diào)了能夠增加可見的和可度量的業(yè)務(wù)價值，而且能夠使系統(tǒng)和數(shù)據(jù)處于穩(wěn)定和一致的狀態(tài)中。其實我們使用EBP原則的時候，主要是在對應(yīng)用進行分析的時候來尋找主要用例。2）用例和目標(biāo)參與者都有自己的目標(biāo)（或需要），因此，一個EBP級別上的用例，通常被稱之為一個用戶目標(biāo)級別上的用例。因此，處理問題的過程應(yīng)該是：首先找出用戶的目標(biāo)

40、，然后為每個目標(biāo)定義一個用例。3）用EBP指導(dǎo)原則的實例作為一個系統(tǒng)分析師，在需求分析會上可以這樣了提出問題：系統(tǒng)分析師：在使用POS系統(tǒng)的時候，你的目標(biāo)是什么？收銀員：快速登錄還有收款系統(tǒng)分析師：你認(rèn)為登錄更高級別上的目標(biāo)什么？收銀員：我要向系統(tǒng)證明身份，這樣才能允許我使用系統(tǒng)系統(tǒng)分析師：比這更高的目標(biāo)呢？收銀員：防止盜竊、數(shù)據(jù)崩潰，不顯示不宜公開的企業(yè)信息。我們分析一下這段對話?！胺乐贡I竊、數(shù)據(jù)崩潰，不顯示不宜公開的企業(yè)信息”實際上比起用戶目標(biāo)要高，可以認(rèn)為是企業(yè)目標(biāo)，所以在此不做考慮?！拔乙蛳到y(tǒng)證明身份，這樣才能允許我使用系統(tǒng)”看起來接近于用戶目標(biāo)，但它不是EBP級別上的行為，因為它不

41、會增加可見的或者可以度量的業(yè)務(wù)價值，它是為期它目標(biāo)服務(wù)的。而“完成一次銷售”是符合EBP原則的更高一級目標(biāo)。第五節(jié) 非功能性需求的識別僅僅寫出用例還是不夠的，還需要識別其它種類的需求，這些將被包含在補充規(guī)范中。例如：簡介功能性日志和錯誤處理安全性人性因素可靠性 可恢復(fù)性性能適應(yīng)性可配置性實現(xiàn)約束 比如開發(fā)的領(lǐng)導(dǎo)層堅持要使用Java開發(fā)。采購的組件免費開放源碼的組件接口值得注意的硬件和接口觸摸屏條碼掃描儀數(shù)據(jù)打印機信用卡讀卡器簽名讀取器（第一版中不支持）術(shù)語表術(shù)語定義和相關(guān)信息商品銷售的產(chǎn)品或服務(wù)支付授權(quán)一外部的支付授權(quán)服務(wù)提供驗證，保證銷售者得到支付支付授權(quán)請求以電子方式發(fā)送到支付授權(quán)系統(tǒng)的一

42、組元素，通常是字符串，這些元素包括：商場ID，顧客賬號，數(shù)據(jù)和時戳術(shù)語表也可以作為數(shù)據(jù)字典使用。第六節(jié) 合理的應(yīng)用活動分析一、為什么要應(yīng)用活動建模上面用文字表示用例事件流，可以很細膩的表達一些用例的過程，但是，當(dāng)用例的事件流比較復(fù)雜的時候，單純用文字表達難以清楚的表示相互之間的關(guān)系，特別是一些并發(fā)關(guān)系，這時，可以借用活動圖來表示，活動圖更善于表達流程和并發(fā)關(guān)系。活動圖表示了計算的步驟，每一步都是一個關(guān)于干什么事的狀態(tài)。因為這個原因，執(zhí)行步驟被稱之為活動狀態(tài)。這個圖表示了哪步應(yīng)該按次序執(zhí)行，哪步可以并行進行，從一個活動狀態(tài)到另一個活動狀態(tài)的轉(zhuǎn)換，稱之為“轉(zhuǎn)換”。如果用例文檔完成了，活動狀態(tài)可以從

43、主要的和附加的流中間發(fā)現(xiàn)。但是用例描述和活動模型之間存在著一些重要的區(qū)別，用例描述是從外部參與者的角度出發(fā)來編寫的，而活動模型則采用內(nèi)部系統(tǒng)的觀點?；顒訄D也可以在用例編寫以前，在一個高的抽象層次來理解業(yè)務(wù)進程?；顒尤绻顒咏Ｊ菫榱吮磉_可視化用例中活動的次序，則活動狀態(tài)可以根據(jù)用例文檔來建立，這時，活動應(yīng)該從系統(tǒng)的角度，而不是參與者的角度來命名?；顒訄D形也可以表達活動狀態(tài)和活動行為?；顒雍托袨榈膮^(qū)別在于其時間跨度，活動是要花時間來完成的，而行為則可看成快照，被認(rèn)為是不花時間的。活動視圖（Activity Diagram）主要用于對計算流程和工作流程建模，它很類似于面向過程建模中的流程圖。使用活

44、動圖可以表示由內(nèi)部生成的動作驅(qū)動的事件流，活動圖能提醒您注意并展示并行的和同時發(fā)生的活動。比較適合建立工作流模型。下面是一個訂單處理的活動圖。 泳道：將模型中的活動按照職責(zé)組織起來通常很有用。例如，可以將一個商業(yè)組織處理的所有活動組織起來。這種分配可以通過將活動組織成用線分開的不同區(qū)域來表示。由于它們的外觀的緣故，這些區(qū)域被稱作泳道。 下圖表示了一個銷售過程的活動。 活動圖并沒有表示出計算處理過程中的全部細節(jié)內(nèi)容。它只是表示了活動進行的流程但沒表示出執(zhí)行活動的對象?；顒訄D是設(shè)計工作的起點。為了完成設(shè)計，每個活動必須擴展細分成一個或多個操作，每個操作被指定到具體類。這種分配的結(jié)果引出了用于實現(xiàn)活

45、動圖的設(shè)計工作。二、案例：訂單處理子系統(tǒng)1，發(fā)現(xiàn)活動針對上面已經(jīng)建立了用例的關(guān)于電源設(shè)備采購的例子，我們從系統(tǒng)用例的描述，來找出活動，注意，活動是站在設(shè)備的角度來描述的。編號用例描述活動狀態(tài)1當(dāng)客戶在訂單信息已經(jīng)顯示在屏幕上的時候，選擇“客戶”或者相似命名的功能鍵來確認(rèn)訂購所配置的電源設(shè)備的時候，該用例開始。顯示當(dāng)前配置；獲得客戶請求2系統(tǒng)請求客戶輸入購買細節(jié)，包括銷售人員的名字（如果知道的話）、運送信息（客戶的名字和地址）、發(fā)票細節(jié)（如果運送地址不同的話）、付款方法（信用卡和支票）以及任何其它注釋。顯示購買窗體3系統(tǒng)由銷售服務(wù)系統(tǒng)取得客戶的等級以及當(dāng)前銷售策略，計算客戶購買的實際價格。顯示購

46、買價格4客戶選擇Purchase（購買，或者相似命名的）功能鍵來發(fā)送訂單給TB公司。獲得購買詳細資料5系統(tǒng)給購買訂單賦與一個唯一的訂單號碼和客戶賬號，系統(tǒng)將訂單信息存入數(shù)據(jù)庫。存儲訂單6系統(tǒng)把訂單號和客戶號與所有訂單細節(jié)一起e-mail給客戶，作為接受訂單的確認(rèn)。Email訂單資料7客戶在提供所有要求錄入的信息之前，激活Purchase（或者相似命名的）功能鍵，系統(tǒng)將顯示錯誤信息，它要求提供所漏掉的信息。獲得購買詳細資料顯示購買窗體8客戶選擇Reset（或其它相似命名）功能來恢復(fù)一個空白的購物表格，系統(tǒng)允許客戶重新輸入信息。顯示購買窗體把標(biāo)識的活動畫出來。2，活動圖把活動用轉(zhuǎn)換連線連接起來，就

47、成為活動圖。“顯示當(dāng)前配置”是初始活動狀態(tài)，在這個活動上有一個遞歸轉(zhuǎn)換的表達，描述在進行下一個活動以前，這個活動一直在反復(fù)執(zhí)行。這個方式強調(diào)了這是活動而不是行為。當(dāng)活動轉(zhuǎn)換為“顯示購買窗體”的時候，timeout將終止這個活動模型的執(zhí)行，或者“獲得購買詳細資料”的活動被激活。如果購買資料不完全，系統(tǒng)又回到“顯示購買窗體”，否則進入“存儲訂單”。并且接著進入“Email訂單資料”，然后活動結(jié)束。一般來說，只有“退出”活動狀態(tài)被顯示出來，一般活動內(nèi)部的分支，可以推斷出來。有時候重要的分支可以使用分支，并附上監(jiān)護條件。三、客戶服務(wù)子系統(tǒng)用例分析下面，我們來研究一下另外一個重要的子系統(tǒng)，客戶服務(wù)子系統(tǒng)

48、的用例分析。1，發(fā)現(xiàn)參與者客戶服務(wù)子系統(tǒng)主要實現(xiàn)客戶分級管理策略，而且可以靈活的處理促銷策略，從項目影響范圍的研究中，我們可以發(fā)現(xiàn)參與者。參與者詞匯表參與者描述基本客戶已經(jīng)有穩(wěn)定業(yè)務(wù)往來的公司。潛在客戶預(yù)計可能有業(yè)務(wù)往來的公司。曾經(jīng)客戶過去有業(yè)務(wù)往來，但是最近6個月內(nèi)沒有購買設(shè)備，但仍然保持良好的身份記錄。市場部響應(yīng)創(chuàng)建折扣和訂閱程序，并為公司進行銷售的組織部門?？蛻舴?wù)部按照合同為客戶提供聯(lián)系服務(wù)的組織部門。財務(wù)部門處理客戶付款和收費，以及維護客戶賬戶信息的組織部門。時間觸發(fā)時序事件的參與者。倉庫管理子系統(tǒng)存儲和維護TB公司產(chǎn)品庫存，并且處理顧客發(fā)貨和退貨的實體。網(wǎng)上銷售子系統(tǒng)實現(xiàn)基于Web

49、的電源產(chǎn)品銷售。2，確定業(yè)務(wù)需求用例與已經(jīng)建立的網(wǎng)上訂購項目相比，這個新系統(tǒng)的最大特點，是把市場行為作為系統(tǒng)的重要功能，所以功能上和以前的系統(tǒng)有諸多不同。首先我們需要記錄項目的初始范圍，也就是定義一個系統(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)需要有什么響應(yīng)，這些相應(yīng)就是系統(tǒng)的凈輸出。4，確定外部數(shù)據(jù)存儲，以實體的形式表達，數(shù)據(jù)庫和文件一般是屬于外部的。注意：系統(tǒng)上下文并不是越復(fù)雜越好，而是要把握系統(tǒng)功能的重點，細節(jié)問題可以在后面

50、的詳細分析中解決。下面是這個項目子系統(tǒng)的上下文。在這個系統(tǒng)中定義邊界的時候，可以考慮把網(wǎng)上銷售子系統(tǒng)暫時排除在外，也就是把網(wǎng)上銷售子系統(tǒng)定義成外部接受者。我們可以建立一些用例并定義它的詞匯。編號用例名稱用例描述預(yù)期的參與者和角色1提交訂閱訂單描述一個潛在客戶通過訂閱加入本系統(tǒng)，這個潛在客戶至少答應(yīng)在兩年內(nèi)購買一定數(shù)量的本公司設(shè)備。潛在客戶2提交訂閱更新訂單描述一個過去的客戶通過訂閱加入本系統(tǒng)，這個客戶過去是本公司的基本客戶，盡管6個月內(nèi)這個活動一度中斷，但現(xiàn)在準(zhǔn)備恢復(fù)商業(yè)活動。曾經(jīng)客戶3提交客戶資料修改描述一個基本客戶修改他的個人資料，包括公司地址、e-mail、密碼和基本購買配置方式?；究?/p>

51、戶4處理訂單和客戶資料描述一個客戶通過網(wǎng)上銷售子系統(tǒng)提交一個TB公司產(chǎn)品訂單，以及有關(guān)的客戶資料，等待客戶服務(wù)子系統(tǒng)返回相關(guān)的折扣信息。網(wǎng)上銷售子系統(tǒng)市場部5查詢購買歷史描述一個基本客戶查閱他三年內(nèi)的購買歷史?；究蛻?建立新客戶訂閱程序描述市場部建立一個新的客戶訂閱計劃（在什么情況下可以得到更大的優(yōu)惠）來吸引新的客戶。市場部7提交訂閱程序修改描述市場部為基本客戶修改訂閱計劃，比如優(yōu)惠期的延長等等。市場部8提交曾經(jīng)客戶重新訂閱程序描述市場部建立一個重新訂閱計劃，比如曾經(jīng)客戶可以更短的時間內(nèi)享受到優(yōu)惠，以吸引回曾經(jīng)客戶。市場部9提交新促銷描述市場部建立一個新的促銷計劃，以吸引不同的客戶來購買。需

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