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

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

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

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

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

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

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

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

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

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

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

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

13、模型并不僅僅是這些圖，更多的是文字說明，把圖形和文字結合起來，設計就會非常的清晰而且避免歧義，這非常重要。第三節 面向對象的需求分析和用例在面向對象的需求分析中，對象、事件和響應成為分析的主體，分析的著力點轉向了交互。但是，還是有相應的方法來描述功能，這就是用例，這也是需求分析的重要部分。一、用例及用例圖的基本概念用戶一定會有自己的目標，并且希望計算機能夠幫助他們實現這些目標。用例就是表達如何使用系統達到目標的一組情節。用例的幾個概念參與者（actor）：具有行為能力的事務，可以是個人（由其扮演的角色來識別），計算機系統，或者組織。場景（scenario）：是參與者和被討論系統之間一系列特定的

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

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

16、領域中各實體間的聯系和業務往來活動（如果某個用例的范圍包含了人以及由人組成的團隊、部門、組織的活動，那么這個用例必然是業務用例）。2，系統用例（System Use Case）指參與者與系統的交互，它表現了系統的功能需求和動態行為（如果僅僅是一些軟件、硬件、機電設備或由它們組成的系統，并不涉及到人的業務活動，那么該用例是系統用例）。3）用例的聯系（橫向方面）1泛化關聯泛化關聯代表一般與特殊的關系，它充分體現了面向對象的繼承性：子類具有父類的所有屬性，還可以擁有自己的屬性特點及行為。泛化關聯包括用例之間及活動著之間的關聯關系。例如，修改員工資料和修改開發部員工資料就是用例的泛化關聯。泛化關聯用空

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

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

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

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

21、式1，面向過程語言：每個用例只描述沒有大的分支的行為的單個線索，在事件流中要對事件流進行面向過程說明（主事件流和備選事件流）。2，UML的活動圖（系統活動圖-和用例活動圖）：使用活動圖可以表示由內部生成的動作驅動的事件流，活動圖能提醒您注意并展示并行的和同時發生的活動。這使得活動圖成為建立工作流模型、分析用例以及處理多線程應用程序的得力工具。三、事件流描述文檔的基本要求1）首先寫出基本的路徑這是最主要的事情，因為它是用戶最關心或者最想看到的內容。2）用例交互的四步曲1，參與者產生某個行為動作；2，然后系統對此動作進行響應；3，響應成功后再根據動作的要求進行狀態的改變；4，最后將改變后的結果再回

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

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

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

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

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

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

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

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

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

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

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

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

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

35、頁面查看所選擇的電源設備標配，同時顯示價格。客戶顯示標準電源配置2客戶查看配置細節，可以更改配置。客戶構造電源配置3系統由客戶服務系統取得該客戶的等級，以及由銷售策略決定的折扣，同時計算價格。客戶客戶服務系統獲取銷售策略4客戶選擇訂購，也可以要求銷售人員在訂單真正發出之前和自己聯系，解釋有關細節。客戶銷售人員訂購配置了的電源設備請求與銷售人員聯系5要發出訂單，客戶必須填寫表格，包括地址，付款細節（信用卡還是支票）等。客戶訂購配置了的電源設備效驗和認可客戶付款6銷售人員發送電子請求到倉庫管理系統，并且附上配置細節。銷售人員倉庫管理系統通知倉庫關于訂購信息7事務的細節（包括訂單號和客戶帳戶號），銷

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

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

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

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

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

41、開的企業信息”實際上比起用戶目標要高，可以認為是企業目標，所以在此不做考慮。“我要向系統證明身份，這樣才能允許我使用系統”看起來接近于用戶目標，但它不是EBP級別上的行為，因為它不會增加可見的或者可以度量的業務價值，它是為期它目標服務的。而“完成一次銷售”是符合EBP原則的更高一級目標。第五節 非功能性需求的識別僅僅寫出用例還是不夠的，還需要識別其它種類的需求，這些將被包含在補充規范中。例如：簡介功能性日志和錯誤處理安全性人性因素可靠性 可恢復性性能適應性可配置性實現約束 比如開發的領導層堅持要使用Java開發。采購的組件免費開放源碼的組件接口值得注意的硬件和接口觸摸屏條碼掃描儀數據打印機信用

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

43、。因為這個原因，執行步驟被稱之為活動狀態。這個圖表示了哪步應該按次序執行，哪步可以并行進行，從一個活動狀態到另一個活動狀態的轉換，稱之為“轉換”。如果用例文檔完成了，活動狀態可以從主要的和附加的流中間發現。但是用例描述和活動模型之間存在著一些重要的區別，用例描述是從外部參與者的角度出發來編寫的，而活動模型則采用內部系統的觀點。活動圖也可以在用例編寫以前，在一個高的抽象層次來理解業務進程。活動如果活動建模是為了表達可視化用例中活動的次序，則活動狀態可以根據用例文檔來建立，這時，活動應該從系統的角度，而不是參與者的角度來命名。活動圖形也可以表達活動狀態和活動行為。活動和行為的區別在于其時間跨度，活

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

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

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

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

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

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

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

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

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