軟件工程課件：用例驅動

用例驅動8.1用例驅動開發(fā)概述8.2為什么使用用例8.3確定客戶需要什么8.4需求工作流8.5領域模型8.6業(yè)務模型8.7補充需求8.8初始需求8.9初始需求：考勤系統(tǒng)實例研究8.10繼續(xù)需求流：考勤系統(tǒng)實例研究8.11修訂需求：考勤系統(tǒng)實例研究8.12測試工作流：考勤系統(tǒng)實例研究8.13需求規(guī)格說明書8.14小結習題８

知識點

需求工作流，領域模型，業(yè)務模型，建模技術。

難點

如何將理論與實踐結合。

基于工作過程的教學任務

通過本章學習，了解為什么使用用例，學習用例驅動開發(fā)的基本概念；確定客戶需要什么，掌握需求工作流的基本過程；理解領域模型、業(yè)務模型對需求的作用，掌握相關的建模技術；以考勤系統(tǒng)為例，全面展示需求工作流的工作過程；了解考勤系統(tǒng)的測試工作流。

統(tǒng)一過程(UP)的核心思想是用例驅動、以構架為中心的迭代和增量開發(fā)。圖8-1描述了統(tǒng)一過程中的一系列工作流和模型。從機器解釋的角度看，實現(xiàn)模型是最形式化的，而用例模型的形式化成分最少。也就是說，部分實現(xiàn)模型可以通過編譯和連接成為可執(zhí)行代碼，而用例模型主要用自然語言來描述。

圖8-1統(tǒng)一過程從需求到測試的一系列工作流

用例常用于捕獲軟件系統(tǒng)(尤其是基于構件的系統(tǒng))的需求。用例不只是捕獲需求的工具，還能夠驅動整個開發(fā)過程。在尋找和確定類、子系統(tǒng)和接口時，在尋找并確定測試用例時，在規(guī)劃開發(fā)迭代和系統(tǒng)集成時，用例都將作為主要輸入。對每次迭代，用例驅動完成一整套工作流(從需求捕獲，經過分析、設計和實現(xiàn)，最后到測試)，并將這些不同的工作流集成在一起。

8.1用例驅動開發(fā)概述

在需求工作流中，開發(fā)者必須確定什么樣的軟件是客戶想要的。因此，需求捕獲有兩個目標：發(fā)現(xiàn)真正的需求，并以適合于用戶、客戶和開發(fā)人員的方式加以描述?！罢嬲男枨蟆笔侵冈趯崿F(xiàn)時可以給用戶帶來預期價值的需求，但是，很多客戶不知道他們需要什么．

“以適合于用戶、客戶和開發(fā)人員的方式”主要是指對需求的最后描述必須能夠讓用戶和客戶理解，但是，即便客戶真正了解他們需要什么，也有可能很難精確地把其想法傳達給開發(fā)者，因為大多數(shù)客戶的計算機知識不如開發(fā)團隊的成員。這也是需求工作流的難點之一。

系統(tǒng)通常有多種用戶，每種用戶都是一個參與者，參與者使用系統(tǒng)與用例進行交互，用例是系統(tǒng)向參與者提供某些有價值結果而執(zhí)行的動作序列，即某種功能，參與者和用例構成用例模型。

在分析和設計期間，用例模型經分析模型轉化為設計模型。簡單地說，分析模型和設計模型都是由類元(Classifier)和說明如何實現(xiàn)用例的集合組成的。類元是一種描述行為和結構特征的模型元素，它具有屬性和操作，可以用狀態(tài)圖描述，有的還可以實例化、參與協(xié)作等。類元的種類包括類、行為、構件、數(shù)據(jù)類型、接口、節(jié)點、信號、子系統(tǒng)以及用例。其中，類是最常見的類元。

分析模型也是一種模型，是需求的詳細規(guī)格說明，可作為設計模型的切入點。分析模型可能是暫時的，只存在于前幾次迭代中，然而，在某些情況下，尤其對于大型、復雜系統(tǒng)，分析模型會存在于系統(tǒng)的整個生命周期。這種情況下，分析模型的用例實現(xiàn)與設計模型中相應的用例實現(xiàn)之間存在一種無縫的跟蹤依賴關系，分析模型中每個元素都可以從實現(xiàn)它的設計模型元素中跟蹤到。

設計模型具有下面的特點：

設計模型是有層次的，也包括跨層次的關系，這些關系在UML中很常見：關聯(lián)、泛化和依賴等；

用例實現(xiàn)是協(xié)作的構造型，協(xié)作表示類元在做某件事情(如實現(xiàn)用例)時如何參與和扮演角色；

設計模型是實現(xiàn)的藍圖，設計模型的子系統(tǒng)和實現(xiàn)模型的構件之間存在直接的映射關系。

開發(fā)人員以用例模型為輸入來創(chuàng)建分析模型。用例模型中的每個用例都實現(xiàn)為分析模型中的用例實現(xiàn)，用例和用例實現(xiàn)的依賴性支持需求和分析之間的無縫可跟蹤性。通過對用例進行處理，開發(fā)人員可以確定參與實現(xiàn)用例的類，例如，“取款”用例可以通過分析“取款”類、“賬戶”類、“分配”類及其他無需在此標識的類來實現(xiàn)。開發(fā)人員將用例中定義的職責分配為類的職責，因此“賬戶”類包括諸如“從賬戶上提取一定數(shù)額的現(xiàn)金”的職責。這樣，就可以得到一個類的集合，合在一起就能實現(xiàn)用戶所需的用例。

開發(fā)人員設計類和用例實現(xiàn)，以便更充分地應用相關的產品和技術(如對象請求代理、圖形用戶界面、構造工具和數(shù)據(jù)庫管理系統(tǒng)等)來實現(xiàn)系統(tǒng)。根據(jù)子系統(tǒng)對設計類進行分組，并定義子系統(tǒng)間的接口。開發(fā)人員還要進一步建立實施模型，其中包括定義在計算節(jié)點上的系統(tǒng)的物理結構，以驗證用例能夠實現(xiàn)并能在節(jié)點上運行。

開發(fā)人員把設計好的類實現(xiàn)為實現(xiàn)模型中的構件(源代碼)集合，能夠產生(即編譯和連接)如DLL、JavaBeans和ActiveX等可執(zhí)行代碼，用例有助于開發(fā)人員確定實現(xiàn)和集成構件的次序。

在測試工作流期間，測試人員驗證系統(tǒng)確實能夠實現(xiàn)用例描述的功能并滿足系統(tǒng)需求。測試模型包含測試用例，測試用例是測試數(shù)據(jù)集，定義了輸入、運行條件和結果的集合。許多測試用例直接從用例得到。因此，在測試用例和相應的用例之間存在跟蹤依賴關系，這意味著測試人員將驗證系統(tǒng)能夠做用戶需要的事，即能夠執(zhí)行用例。

8.2為什么使用用例

在軟件開發(fā)中，很常見的問題是許多客戶不知道他們需要什么，進一步來講，即便客戶真正了解他們需要什么，也有可能很難精確地把這些想法傳達給開發(fā)者，因為大多數(shù)客戶的計算機知識不如開發(fā)團隊的成員。對開發(fā)人員來說，對軟件產品及其功能進行形象化描述已經很難了，對并不精通軟件工程的客戶來說則更加困難。

另外，客戶可能并不了解自己的企業(yè)正在做什么。例如，如果現(xiàn)有軟件系統(tǒng)響應時間過長的真正原因是數(shù)據(jù)庫設計得太差，那么客戶要求開發(fā)一個運行速度更快的軟件是毫無用處的，重新開發(fā)一個軟件產品，運行效果還是會和原來一樣慢，真正需要做的是在目前的軟件產品中重新組織和改善數(shù)據(jù)的存儲方式。又如，如果客戶經營的是虧損的零售連鎖店，那么客戶可能會要求一個財務管理信息系統(tǒng)來反映諸如銷售量、工資、應付賬目和應收賬目之類的項目，但是，如果虧損的真正原因是商品的損耗(或盜竊和雇員監(jiān)守自盜)，信息系統(tǒng)就幾乎毫無用武之處，而且，如果真是這樣的情況，需要的其實是一個庫存控制系統(tǒng)而不是一個財務管理信息系統(tǒng)。

因此，沒有專業(yè)的軟件開發(fā)團隊的協(xié)助，客戶很難了解到需要開發(fā)些什么。另一方面，除非能與客戶面對面交流，否則專業(yè)的軟件開發(fā)團隊也無法找出客戶究竟需要什么。

用例有益于軟件開發(fā)并被普遍采用有多種原因，下面是兩個主要原因。

為用戶提供捕獲功能需求的系統(tǒng)方法；

可驅動整個開發(fā)過程，大部分活動如分析、設計和測試都是從用例開始執(zhí)行的，設計和測試可根據(jù)用例進行規(guī)劃和協(xié)調。

8.2.1根據(jù)需求的價值捕獲用例

用例視圖實現(xiàn)了軟件工程的最終目標：客戶可以用創(chuàng)建的產品做有用的工作。

構造用例有利于確定用戶目標，用例是系統(tǒng)向用戶提供的增值功能。收集各類用戶的觀點，捕獲他們需要完成的工作以構建用例。相反，如果虛構出一組很好的系統(tǒng)功能，而沒有考慮各類用戶使用的用例，就很難斷定這些功能是否重要或合適，也就不知道，誰在進行工作？需要滿足什么業(yè)務？能夠對業(yè)務增加多少價值？

最好的用例為系統(tǒng)業(yè)務提供最大的價值。為業(yè)務提供負面價值或允許用戶做不該做的事情的用例不是真正的用例，這類用例指出了禁止使用系統(tǒng)的方法，稱為“不良用例”，例如，允許銀行儲戶將他人賬戶上的存款轉移到自己的賬戶上。為業(yè)務提供極少價值或無價值的用例，基本上不會用到，就是不必要的“無用用例”。

正如前述，只是簡單的詢問系統(tǒng)需要做什么并不能獲得正確的答案。那么，列出系統(tǒng)功能表呢？乍一看似乎有用，但對用戶需要來說并不必要。使用用例策略將“希望系統(tǒng)做什么？”的問題變成了“希望系統(tǒng)為每個用戶做什么？”，似乎只有很細微的差別，卻產生了差別很大的結果。

用例很直觀。用戶和客戶根本不懂復雜的符號，相反，簡單的詞匯(如自然語言)適用于大多數(shù)的場合，也易于閱讀用例描述并提出修改建議。

捕獲用例涉及到用戶、客戶和開發(fā)人員。用戶和客戶是需求專家，開發(fā)人員的作用是與用戶和客戶進行溝通，幫助他們表達其需求。

用例模型用來與用戶和客戶在“系統(tǒng)應該為每個用戶做什么”方面達成共識，用例模型是所有可能使用系統(tǒng)(用例)的方式的規(guī)格說明，可作為合同的一部分。

8.2.2用例驅動開發(fā)過程

用例驅動意味著從用例初始化開始項目的開發(fā)過程。開發(fā)人員閱讀用例說明，尋找適合于實現(xiàn)用例的類，因此用例有助于開發(fā)人員找出類。用例還有助于開發(fā)用戶界面，使用戶更易于執(zhí)行任務。隨后，用例實現(xiàn)要經過測試以證明類的實例能夠執(zhí)行用例。用例不僅啟動開發(fā)過程，而且將其結合為一個整體，如圖8-2所示。背景中橢圓表示用例如何將這些工作流連為一體。

圖8-2用例的開發(fā)過程

要確保捕獲正確的用例，以便得到用戶真正的需求。解決該問題最好的方法當然是在需求階段徹底做好，這往往很難達到，但是，演化的系統(tǒng)允許進一步確定用例是否符合實際的用戶需求。

用例有助于項目經理規(guī)劃、分配和監(jiān)控開發(fā)人員執(zhí)行的任務。項目經理可以標識、設計和測試用例為一個個的任務，可以估算這些任務所需要的工作量和時間。根據(jù)用例確定的任務有助于項目經理估計項目的規(guī)模和所需要的資源，并把這些任務分配給開發(fā)人員。

用例是保證所有模型具有可跟蹤性的重要機制。需求階段的用例可以進一步在分析和設計階段實現(xiàn)，還可以追尋到參與實現(xiàn)的所有類、構件(間接的)以及最后用來驗證用例的測試用例。可跟蹤性是管理項目的一個重要方面，當用例發(fā)生變化時，必須對相應的設計、類、構件和測試用例進行檢查以便更新，便于保持系統(tǒng)的完整性和需求變更的一致性。

用例有助于進行迭代開發(fā)。除了項目中第一次迭代之外，每次迭代都由用例驅動而經歷所有的工作流，即從需求、分析到設計和測試，進而得到一個增量結果。因此，每次開發(fā)的增量都是一個用例集合的具體實現(xiàn)。

用例有助于設計構架。在最初的幾次迭代中，選擇實現(xiàn)適當?shù)挠美?對構架關鍵的用例)，便可以用穩(wěn)定的構架來實現(xiàn)系統(tǒng)，該構架可用于開發(fā)周期后續(xù)的演化。

用例可作為編寫用戶手冊的起點。因為用例說明了各類用戶使用系統(tǒng)的方法，因此用例是說明用戶怎樣與系統(tǒng)進行交互的起點。

8.3確定客戶需要什么

下面簡單介紹一下如何通過工作流來執(zhí)行用例驅動。

1．用例模型表示功能需求

用例模型幫助客戶、用戶和開發(fā)人員在如何使用系統(tǒng)方面達成共識。大多數(shù)系統(tǒng)具有多種類型的用戶，每類用戶表示為一個參與者(Actor)，參與者使用用例(UseCase)與系統(tǒng)進行交互。系統(tǒng)所有的參與者和所有用例組成用例模型，一張用例圖描述部分用例模型，顯示帶有關聯(lián)關系(表示參與者和用例之間的交互)的用例和參與者的集合(如圖8-3所示)。圖8-3用例圖(表示一個參與者和三個用例之間的關聯(lián))

舉例：ATM系統(tǒng)的用例模型

參與者“儲戶”使用自動取款機系統(tǒng)從賬戶中取款，或存款到賬戶中，或在賬戶間轉賬?？梢杂蓤D8-3中的三個用例表示，三個用例與參與者之間的關聯(lián)表示了參與者與用例之間的關系。

2．參與者與系統(tǒng)交互

參與者不一定是人，還可以是與系統(tǒng)發(fā)生交互的其他系統(tǒng)或外部硬件。參與者在與系統(tǒng)交互時扮演相應的角色，一個用戶可以是一個或幾個參與者，在與系統(tǒng)交互時發(fā)揮其作用。幾個用戶可以作為一個用戶的不同實例而充當同一個參與者。

參與者執(zhí)行用例，向系統(tǒng)發(fā)送消息或從系統(tǒng)接收消息，與系統(tǒng)進行通信。當明確了參與者和用例應該做什么時，便可以劃分參與者的職責和系統(tǒng)的職責，以便限定系統(tǒng)的范圍。此時考慮哪些用戶將使用系統(tǒng)以及哪些系統(tǒng)會與系統(tǒng)發(fā)生交互，就可以找出并詳細說明參與者，每類用戶或交互系統(tǒng)都是參與者。

3．用例確定系統(tǒng)

用例是為了滿足用戶使用系統(tǒng)的需要，用例模型捕獲系統(tǒng)的所有功能性需求。下面是用例的精確定義。

用例規(guī)定一個動作序列(可以有多種實現(xiàn))，系統(tǒng)執(zhí)行這些動作，產生一個對特定參與者有價值的結果。

考慮用戶如何使用系統(tǒng)完成其工作，就可以找出用例。每個對用戶增值的系統(tǒng)使用方式就是一個候選用例，之后，對候選用例進行詳細說明、修改、劃分為更小的用例或結合為更完整的用例。當以客戶、用戶和開發(fā)人員都能理解的方式正確地捕獲了全部功能性需求時，便基本完成了用例模型。用例執(zhí)行的動作序列是一條完成該用例的具體路徑，可能存在多條路徑，而且很多路徑可能是相似的，都是用例規(guī)定的動作序列的不同實現(xiàn)。要想用例模型易于理解，應該將相似的實現(xiàn)路徑組成一個用例。

舉例：“取款”用例

執(zhí)行“取款”動作序列的一條路徑是非常簡單的，下面是簡單描述。

(1)儲戶表明自己的身份。

(2)儲戶選擇從哪個賬戶取款，并確定取款金額。

(3)系統(tǒng)從賬戶上扣減指定的金額，分發(fā)等額的貨幣給儲戶。

用例還可以說明非功能性需求，如性能、可用性、準確度和安全性等方面的需求。例如，下面的需求可以附加到“取款”用例上，儲戶從選擇取款數(shù)額到得到貨幣的響應時間應該小于30秒。

總之，所有的功能需求確定為用例，而非功能需求可以附加到用例上，用例模型以易于管理的方式來組織需求。

8.4需

求

工

作

流

需求工作流的第一步是理解問題域，即目標產品的應用環(huán)境，問題域可能是銀行、太空探索、裝備制造、生物工程等。開發(fā)團隊的成員對問題域理解到一定程度，就可以構造出業(yè)務模型，可以用UML圖來描述客戶的業(yè)務過程，業(yè)務模型確定客戶的初始需求是什么，接著，就可以采用迭代的方法進行需求開發(fā)。

根據(jù)對問題域的初步了解構造初始的業(yè)務模型，然后，擬訂客戶需求的初始集合，接著，根據(jù)已知的客戶需求，對問題域進行深層次的理解，就可以精化業(yè)務模型，并得到客戶需求，迭代一直持續(xù)到開發(fā)團隊對需求集感到滿意為止。

發(fā)現(xiàn)客戶需求的過程叫做需求獲取，擬訂初始需求集合，對其精化和擴展的過程叫做需求分析。圖8-4描述了需求捕獲工作流的動態(tài)行為。

圖8-4需求捕獲工作流的動態(tài)行為

圖8-4中使用泳道可以很清晰地了解每類工作人員所執(zhí)行的活動，每個活動與執(zhí)行人員處在同一條泳道中。當工作人員執(zhí)行活動時，會創(chuàng)建或改變制品，將工作流描述為一個活動序列，一個活動產生的輸出可以作為下一個活動的輸入。圖中表明的只是一種邏輯流，在實際的生命周期中，并不需要按順序執(zhí)行各項活動，相反，可以按任意方式執(zhí)行，只要產生“等價的”最終結果即可。例如，可以從確定用例(“確定參與者與用例”活動)開始，然后設計用戶界面(“構造用戶界面原型”活動)，這時可能會發(fā)現(xiàn)需要增加新的用例(又跳回到“確定參與者與用例”活動，就打破了嚴格的順序)，依此類推。

一個活動可能會重復多次，每次重復可能只執(zhí)行該活動的一部分。例如，在重復“確定參與者與用例”活動時，新的結果可能只是確定一個補充的用例。因此，活動之間的路徑只是表明了活動的邏輯順序—將一個活動產生的結果用作另一個活動的輸入。

首先，系統(tǒng)分析員執(zhí)行“確定參與者與用例”活動來構造用例模型的最初版本。系統(tǒng)分析員要確保用例模型捕獲了需求，即特征表和領域模型或業(yè)務模型。然后，構架設計師確定對構架重要的用例，劃分用例的優(yōu)先級。接著，用例描述人員對所有確定了優(yōu)先級的用例進行描述。與此同時，用戶界面設計人員可根據(jù)用例設計合適的用戶界面。之后，系統(tǒng)分析員定義用例間的泛化關系，重新構造用例模型，使其易于理解。

經過第一次迭代得到了用例模型、用例和所有相關的用戶界面原型的最初版本，后續(xù)迭代構成了新版本，經過多次迭代，逐步細化和完善。

用例模型是在幾個開發(fā)增量的基礎上得到的，期間的迭代過程，或增加新的用例，或對已存在的用例規(guī)格說明增加細節(jié)。

圖8-5表明了需求捕獲工作流和得到的制品在不同階段及相應的迭代過程中呈現(xiàn)不同的形態(tài)。

圖8-5需求主要在初始和細化階段獲得

初始階段，分析人員確定了大部分用例，以限定系統(tǒng)和項目的范圍，并詳細說明主要用例(少于10%)；

細化階段，分析人員捕獲大多數(shù)剩余的需求，以便開發(fā)人員能夠估計所需的工作量。目標是捕獲大約80%的需求，并描述大部分用例；(注意，此時只能將需求的大約5%～10%實現(xiàn)為構架基線)；

構造階段，捕獲(并實現(xiàn))其余的需求；

移交階段，除非需求發(fā)生了改變，基本上不再捕獲需求。

8.5領域模型

要想獲取客戶需求，需求小組的成員必須對目標產品的應用領域十分熟悉，例如，如果不熟悉銀行業(yè)務和神經外科，就很難向銀行家和神經外科醫(yī)生提出有意義的問題，也就不能設計出對客戶有用的系統(tǒng)。因此，除非對產品使用的領域很有經驗，故需求分析小組成員最初的任務就是熟悉應用域。

解決問題的方法是構造一張術語表，羅列領域中使用的技術詞匯并給出相應的解釋。

(1)什么是領域模型？

領域模型能捕獲系統(tǒng)情境中最重要的對象類型，領域對象代表系統(tǒng)工作環(huán)境中存在的“事物”或發(fā)生的事件。

很多領域對象或類可以從需求規(guī)格說明中找到或通過訪談從領域專家那里得到，領域類有下面三種典型的形式。

業(yè)務對象，表示業(yè)務中可操作的東西，例如訂單、賬戶和合同等；

系統(tǒng)需要處理的現(xiàn)實世界的對象和概念，例如火箭、導彈及其彈道等；

將要發(fā)生或已經發(fā)生的事件，例如飛機抵達、飛機起飛和演出等。

UML的類圖向客戶、用戶、評審人員和其他開發(fā)人員闡明領域類，以及它們之間是如何彼此關聯(lián)的，可用于描述領域模型。

舉例：領域類（“訂單”、“賬單”、“訂單項”和“賬戶”）

系統(tǒng)可通過互聯(lián)網(wǎng)在買主和賣主之間發(fā)送訂單、賬單并支付費用。系統(tǒng)幫買主準備訂單，賣主對訂單估價并發(fā)送賬單，買主確認賬單并從買主的賬戶到賣主的賬戶轉賬以實現(xiàn)支付。

訂單是買主向賣主提出的購買商品的請求。每種商品都是訂單中一項，訂單具有訂單日期、交貨地址等屬性，如圖8-6中的類圖。賬單是賣主發(fā)給買主的對應貨物或服務訂單的支付請求。賬單具有數(shù)量、提交日期和最后支付日期等屬性，一份賬單可能是多張訂單的支付請求。

圖8-6領域模型中的類圖捕獲系統(tǒng)語境中最重要的概念

賬單的支付通過將買主賬戶上的存款轉到賣主賬戶上來實現(xiàn)。賬戶具有余額和所有者等屬性，所有者屬性標識擁有該賬戶的用戶。

(2)建立領域模型。

領域模型通常由領域分析員用UML或其他建模語言來描述，因此，要想建立一個高效的工作小組，還應該包括領域專家、以建模見長的其他人員等。

領域建模的目的是理解和描述在領域環(huán)境中最重要的類。規(guī)模適度的領域模型通常需要10～50個類，規(guī)模更大的領域可能需要更多的類。分析員為該領域選取的幾百個候選類將作為術語表中的定義保存下來，否則，領域模型會變得很大，需要花費大量的工作量，這是該階段不希望的。有時候，對于非常小的業(yè)務領域，就沒有必要為其建立對象模型，這時，只要一張術語表也就夠了。

術語表和領域模型有助于用戶、客戶、開發(fā)人員和其他項目相關人員使用統(tǒng)一的詞匯。

(3)領域模型的使用。

在確定用例和分析模型時要使用領域類和術語表，經常用于下面的場合。

描述用例和設計用戶界面時，有助于理解用例和交互；

分析期間，提取要開發(fā)的系統(tǒng)內部類。

實際上，還有更系統(tǒng)的方法來確定用例和發(fā)現(xiàn)系統(tǒng)內部類——建立業(yè)務模型。領域模型實際上是業(yè)務模型的特例，因此，業(yè)務模型是領域模型的更有效的替代方案。

8.6業(yè)務模型

業(yè)務模型是理解一個組織中業(yè)務過程的技術。業(yè)務模型(BusinessModel)對應用領域的業(yè)務過程進行描述，例如，銀行的業(yè)務過程包括存款、貸款以及投資等。如果系統(tǒng)與大多數(shù)人所關心的業(yè)務無關怎么辦呢？例如，開發(fā)心臟起搏器、防抱死剎車系統(tǒng)、相機控制器或電信系統(tǒng)時，應該怎么做呢？

在這些情況下，可能會圍繞著要開發(fā)的軟件系統(tǒng)建立系統(tǒng)模型，該系統(tǒng)(人體的一部分、汽車的一部分、相機、交換機)是嵌入式軟件系統(tǒng)類的“業(yè)務系統(tǒng)”，包含了高度概括的系統(tǒng)用例，目的是確定軟件用例和軟件所支持的相關業(yè)務實體，只需建立模型來理解系統(tǒng)環(huán)境就可以了。

業(yè)務模型提供對客戶業(yè)務的整體了解。只有了解業(yè)務過程，開發(fā)者才能建議客戶業(yè)務中的哪些部分可以計算機化。另外，如果要擴充已存在的軟件產品，那么開發(fā)者必須先從整體上理解現(xiàn)存的業(yè)務，才能決定如何擴充現(xiàn)存業(yè)務，現(xiàn)存產品的哪些部分需要修改，以及需要添加哪些新的部分。

UML模型的用例模型和對象模型支持業(yè)務建模。如用用例圖描述業(yè)務用例模型。

1．什么是業(yè)務模型

業(yè)務用例模型分別從業(yè)務過程、客戶對應的業(yè)務用例和業(yè)務參與者的角度來描述組織的業(yè)務過程。與軟件系統(tǒng)的用例模型相似，業(yè)務用例模型從使用的角度來表示系統(tǒng)(這里為業(yè)務)，并概括了它如何向其用戶(這里指客戶和合作伙伴)提供有價值的功能。

舉例：業(yè)務用例

Interbank是一個基于Internet的銀行業(yè)務系統(tǒng)。這里有Interbank的一個業(yè)務用例，涉及在買主和賣主之間發(fā)送訂單、賬單和支付費用—“銷售：從訂單到交貨”。在業(yè)務用例中，買主知道要買什么和從哪兒買。在以下序列中，Interbank在業(yè)務用例中扮演經紀人，將買主和賣主彼此聯(lián)系并為賬單支付提供下面的安全例程。

(1)買主訂購貨物或服務。

(2)賣主給買主開賬單。

(3)買主支付費用。

(4)賣主交付貨物或提供服務。

此情境中，買主和賣主是Interbank的業(yè)務參與者，使用Interbank所提供的業(yè)務用例。

一種業(yè)務一般提供多個業(yè)務用例，Interbank業(yè)務也不例外。下面是其中兩個用例，以獲得恰當?shù)那榫场?/p>

在“借貸處理：從申請到支付”業(yè)務用例中，儲戶向Interbank提交借貸申請，并從銀行收到貸款。這里，儲戶就代表銀行的普通客戶，買主和賣主是銀行更為具體的儲戶。

在“轉賬、取款和存款”業(yè)務用例中，儲戶在賬戶間轉賬、從某個賬戶提款和向其中某個賬戶存款。該業(yè)務用例還允許儲戶設置自動轉賬等。

業(yè)務對象模型是業(yè)務的內部模型，描述了如何由工作人員使用業(yè)務實體和工作單元來實現(xiàn)業(yè)務用例。業(yè)務實體如賬單等類似的事物，在業(yè)務用例中工作人員可以創(chuàng)建、訪問、檢查、處理或使用它。工作單元是一個實體的集合，對最終用戶來說是一個可認知的整體。業(yè)務用例的實現(xiàn)可以用交互圖和活動圖來表示。

業(yè)務實體和工作單元用于表示同一類型的領域類概念，如訂單、訂單項、賬單和賬戶，因此，可以繪制一張類似于圖8-6的業(yè)務實體圖。之后，用其他圖描述工作人員、它們之間的交互以及如何使用業(yè)務實體和工作單元，如圖8-7所示。

圖8-7“銷售：從訂單到交貨”業(yè)務用例

工作人員、業(yè)務實體和工作單元可能會參與多個業(yè)務用例的實現(xiàn)。例如，“賬戶”類很可能參與所有下面的三個業(yè)務用例。

在“借貸處理：從申請到支付”的用例中，借貸得到的貸款將轉入到某個賬戶上；

在“轉賬、取款和存款”用例中，從賬戶中取款或將錢存人賬戶，或在兩個賬戶間轉賬；

在“銷售：從訂單到交貨”用例中，將款額從買主的賬戶轉賬到賣主的賬戶。

舉例：“銷售：從訂單到交貨”業(yè)務用例

在“銷售：從訂單到交貨”業(yè)務用例中，工作人員執(zhí)行如圖8-7所示的步驟。

(1)買主通過與賣主接觸訂購貨物或服務。

(2)賣主通過“支付處理者”向買主發(fā)送賬單。

(3)賣主向買主交付貨物或提供服務。

(4)買主通過“支付處理者”付款，即將款額從買主的賬戶轉移到賣主的賬戶。

輔助實現(xiàn)第2步和第4步的支付處理者是銀行職員，該任務可以由信息系統(tǒng)自動完成。

買主和賣主使用“支付處理者”能為買主和賣主提供價值?！爸Ц短幚碚摺蓖ㄟ^給買主發(fā)賬單并跟蹤未付款賬單來為賣主提供增值服務，同時，“支付處理者”簡化支付過程并提供更好的賬單支付信息和可用性，為買主提供增值服務。

2．如何建立業(yè)務模型

建模人員應分以下兩步來建立業(yè)務模型。

(1)應該建立一個業(yè)務用例模型，用于確定業(yè)務的參與者和參與者使用的業(yè)務用例，以使開發(fā)者更好地理解業(yè)務對參與者提供的價值。

(2)應該建立一個業(yè)務對象模型，其中包括工作人員、業(yè)務實體和工作單元，三者結合在一起共同實現(xiàn)業(yè)務用例。業(yè)務規(guī)則與不同的對象相關聯(lián)，目標是盡可能高效地建立實現(xiàn)業(yè)務用例的工作人員、業(yè)務實體和工作單元。

業(yè)務建模和領域建模在某些方面非常相像。實際上，可以將領域建模看作是業(yè)務建模的一個簡單變體，只關注領域類或工作人員要處理的業(yè)務實體。因此，領域類和業(yè)務實體是非常相像的概念。

但是，業(yè)務建模和領域建模之間還是存在一些差異，這些差異體現(xiàn)在業(yè)務建模方面。

領域類來源于領域專家的知識，也可能來源于相似系統(tǒng)的有關知識(如其他的領域類和需求規(guī)格說明等)。另一方面，業(yè)務實體以業(yè)務的客戶為起點，然后確定業(yè)務用例，并最終確定這些業(yè)務實體，每個實體必須在業(yè)務用例中使用才能激發(fā)。這兩種方法通常會得到不同的類、關聯(lián)、屬性和操作的集合，領域建模方法中的類可以跟蹤到領域專家的經驗，業(yè)務建模方法中的每個模型元素可以跟蹤到客戶的需要。

領域類具有屬性，但通常沒有或僅有較少的操作。業(yè)務實體則不同，業(yè)務建模方法不僅要確定實體，還要確定參與實現(xiàn)業(yè)務用例(或使用業(yè)務實體)的所有工作人員。此外，要確定這些工作人員是如何通過每個實體提供的操作來使用實體的，這些實體所提供的操作都來源于客戶并可以跟蹤到客戶。

在業(yè)務建模中確定的工作人員，將作為導出的信息系統(tǒng)的第一批參與者和用例集合的起點。這就允許在信息系統(tǒng)中經由工作人員和業(yè)務用例來跟蹤用例，并返回到業(yè)務的客戶。此外，每個用例均可跟蹤到實現(xiàn)該系統(tǒng)的構件。因此，將業(yè)務建模和統(tǒng)一過程的軟件工程方法結合起來，允許經過業(yè)務過程、工作人員和用例一直到軟件代碼來跟蹤客戶的需要。但是，如果只使用領域模型，在領域模型和系統(tǒng)用例之間沒有明顯的跟蹤路線。

3．根據(jù)業(yè)務模型確定用例

分析人員將業(yè)務模型作為輸入，應用系統(tǒng)技術來建立初步的用例模型。

首先，分析人員把每個使用信息系統(tǒng)的工作人員和業(yè)務參與者(即每個客戶)確定為一個參與者(Actor)。

舉例：買主參與者

買主應用“結賬與支付系統(tǒng)”來訂購貨物或服務并支付賬單。因此，買主既是客戶也是參與者，因為他通過“訂購貨物或服務”用例和“支付賬單”用例來使用系統(tǒng)去訂購和付賬。

每個使用信息系統(tǒng)的工作人員和業(yè)務參與者都需要系統(tǒng)的支持。對每個工作人員，只要知道他所參與的業(yè)務用例實現(xiàn)，就能確定系統(tǒng)應該支持什么，就可以了解工作人員在每個用例實現(xiàn)中充當?shù)慕巧?/p>

確定了所有工作人員或業(yè)務參與者所充當?shù)慕巧?，便可以為信息系統(tǒng)的參與者確定用例。業(yè)務中的每個工作人員和業(yè)務參與者對應于信息系統(tǒng)的一個參與者，對每個工作人員或業(yè)務參與者角色，需要有一個對應的用例，以便使用系統(tǒng)完成工作。

因此，確定初步的用例集合最簡單的方法是為每個工作人員和業(yè)務參與者創(chuàng)建用例。對每個業(yè)務用例，存在一個針對工作人員和業(yè)務參與者的用例。接著，分析人員可以對初步用例進行細化和調整。

分析人員還必須決定有多少工作人員或業(yè)務參與者的任務應該由信息系統(tǒng)自動完成，并重新整理用例以便更好地適應參與者的需要。注意，不是所有任務都可以自動完成。

舉例：根據(jù)業(yè)務模型確定用例

在前面的例子中，假定一個初步的用例“購買貨物或服務”，當買主在業(yè)務用例“銷售：從訂單到交貨”中充當業(yè)務參與者時，該用例支持參與者“買主”。經過進一步分析表明，最好是將用例“購買貨物或服務”實現(xiàn)為幾個不同的用例，如“訂購貨物或服務”和“支付賬單”。將這個初步用例分為幾個較小用例的原因是：買主不希望以不間斷的動作序列執(zhí)行“購買貨物或服務”用例；希望等到交付貨物或提供服務之后再支付賬單。因此，將支付序列表示為一個單獨的用例“支付賬單”，并于交付貨物之后再執(zhí)行這個用例。

4．獲取業(yè)務模型信息的技術

需求小組成員需要和客戶交流和溝通，了解客戶的業(yè)務需求，直到獲取客戶和目標軟件產品未來用戶的所有相關信息為止。

通常，訪談有兩種基本類型：結構化的和非結構化的。在結構化訪談中，會提出一些特定的、預先計劃好的問題，一般是封閉式的，需要得到特定的答案。在非結構化訪談中，訪談可能從1～2個封閉式問題開始，后續(xù)的問題根據(jù)受訪談對象的回答而提出，后續(xù)問題可能在實質上是開放式的，以便給訪談提供更廣泛的信息。

訪談過于非結構化也不好，例如，對客戶說，“請談談你的業(yè)務”，就不太可能得出很多相關的信息。因此，問題應該以既能鼓勵受訪談者給出范圍廣泛的回答，但又總是在訪談者所需的特定信息的范圍內。

進行一次好的訪談并不容易。首先，訪談者必須熟悉應用域。其次，若訪談者已經決定遵循客戶的需求，那么進行訪談是沒有太大作用的。無論訪談者知道些什么，每次進行訪談都必須認真聆聽受訪談者所說的內容，同時，要克制任何與客戶及要開發(fā)產品的潛在需求相關的固有成見。

訪談結束后，訪談者必須準備一份訪談的書面報告，最好將報告的副本發(fā)放給每一位受訪談者，這樣，可能會澄清某些有誤解的陳述或添加一些忽視的信息。

8.7補充需求

補充需求是指無法與任何特定的用例相關聯(lián)的非功能性需求，這樣的需求可能會影響到幾個用例或根本不影響任何用例。性能、接口和物理設計需求以及構架、設計和實現(xiàn)等約束是非功能性需求的實例，補充需求可以捕獲為傳統(tǒng)的需求規(guī)格說明中陳述的需求，然后，連同用例模型一起用于分析和設計。

接口需求詳細描述了系統(tǒng)與其交互的外部項目之間的接口，其中包括對數(shù)據(jù)格式和時間限制的約束或其他與交互有關的因素。

物理設計需求詳細描述了系統(tǒng)必須具有的物理特性，如其材料、形狀、大小和重量等。該類需求可以用來代表硬件需求，如所需的物理網(wǎng)絡配置等。

舉例：硬件平臺需求

服務器、PCServer

客戶機、PC機

設計約束是對系統(tǒng)設計進行限制，如可擴展性和可維護性約束，或有關重用遺留系統(tǒng)或其中的主要部分的約束等。

實現(xiàn)約束是對系統(tǒng)的編碼或構造進行說明或限制。例如，所使用的標準、實現(xiàn)指南、編程語言、數(shù)據(jù)庫完整性策略、資源范圍和操作環(huán)境等。

舉例：文件格式約束

“結賬與支付系統(tǒng)”的1.2版將支持長文件名。

舉例：軟件平臺約束

系統(tǒng)軟件

客戶機操作系統(tǒng)：WindowsXP或Windows7/8

服務器操作系統(tǒng)：Windows2003或Linux

瀏覽器軟件：Firefox16.0或MicrosoftInternetExplorer8.0

此外，經常還有一些其他需求，如：法律方面的需求和規(guī)章制度方面的需求等。

舉例：其他需求

安全性：傳輸必須是安全的，意味著只有經授權的人才能訪問信息。被授權的人只能是擁有賬戶的儲戶和系統(tǒng)管理員等參與者。

可用性：“結賬與支付系統(tǒng)”每個月的停機時間必須小于l小時。

易用性：90%的買主學會（通過使用說明書）提交簡單訂單和支付簡單賬單的時間不能超過10分鐘。簡單訂單只有一個條目；簡單賬單是對簡單訂單進行支付的賬單。

8.8初始需求

要確定客戶的需求，首先基于初始業(yè)務模型擬訂初始需求，然后，與客戶進一步討論，精化對應用域的理解和業(yè)務模型，同時對需求進行精化。

需求是動態(tài)的，也就是說，不僅需求本身會多變，開發(fā)團隊、客戶和未來用戶對于需求的態(tài)度也是多變的。例如，某項特定需求最初可能是可選的，經過進一步分析，該項需求可能非常重要，但是，經過與客戶討論后，該項需求被舍棄了。要處理這些變化，最好的辦法是維護一張需求表，再加上已經得到團隊成員一致同意并經客戶認可的需求用例。

面向對象范型是迭代的，因此，術語表、業(yè)務模型或需求可能要隨時進行調整。

功能需求在需求工作流和分析工作流期間進行處理，而一些非功能需求需要等到設計工作流才能處理。原因在于，要想處理某些非功能需求，需要詳細了解目標產品的具體情況，這一般要在需求工作流和分析工作流結束之后才能得到。但是，只要有可能，非功能需求也應該在需求工作流和分析工作流期間進行處理。

確定參與者和用例是捕獲需求最重要的活動，通過該活動，可以了解誰(參與者)與系統(tǒng)進行交互、從系統(tǒng)預期得到哪些功能(用例)，從而確定系統(tǒng)范圍。如圖8-8所示，該活動由系統(tǒng)分析員負責，但系統(tǒng)分析員不可能獨立完成該工作，需要從客戶、用戶以及其他分析員參加的建模專題討論會中獲得相關信息。

圖8-8用于確定參與者和用例的輸入及其結果

捕獲需求主要包括下面四個步驟。

確定參與者。

確定用例。

簡要描述每個用例。

從整體上描述用例模型(這里，還應該準備一張術語表)。

這些步驟不需要按照特定的順序，經常并發(fā)執(zhí)行。例如，一旦確定了新的參與者或用例，就可以對用例圖進行更新。得到的用例模型應該進行簡明扼要地描述，圖8-9就是用例圖的說明(經過多次迭代來完善和重構)，關聯(lián)上的角色“發(fā)起人”表明哪個參與者啟動用例。

圖8-9支持業(yè)務用例“銷售：從訂單到交貨”的“結賬與支付系統(tǒng)”中的用例

有了應用領域知識并對初步的業(yè)務模型熟悉后，團隊成員就可以進行深入的訪談，建立初步的用例模型。

8.9初始需求:考勤系統(tǒng)實例研究

8.9.1聆聽

一個系統(tǒng)是由其提供的價值來確定的，所以，該階段的目標就是從客戶的角度來認識系統(tǒng)。下面描述了與客戶之間的(有點理想化的)對話：開發(fā)者、負責考勤的業(yè)務經理以及一個使用該系統(tǒng)的雇員，其目的是描述系統(tǒng)的功能和用途。當然，在現(xiàn)實世界中，這樣通常會是一個5人、10人、甚至20人的會議，每個人都有不同的需求和視角，為了達成對系統(tǒng)的共識就可能需要用好幾個星期來召開好幾次會議。

舉例：考勤系統(tǒng)的初次會議記錄

開發(fā)者：誰會使用考勤系統(tǒng)？

客

戶：所有用它來記錄可記賬以及不可記賬工時的雇

員。

開發(fā)者：在什么地方？這里、家里還是使用客戶端？在防火墻之后？

客

戶：在辦公室里，有時候也可以在家里，但肯定是通過防火墻后的客戶端來訪問。

開發(fā)者：很好，這很有用。那么，現(xiàn)在是怎么考勤的呢？

客

戶：每半個月用一個Excel表格來記錄。每個雇員將表格填好，然后用電子郵件發(fā)給我。表格格式標準：縱向是收費項目代碼，橫向是日期。雇員可以在每個條目上填寫說明。

開發(fā)者：那么，從什么地方得到收費項目代碼呢？

客

戶：有一張單獨的表格記錄有效的收費項目代碼，按客戶和活動來進行組織。

開發(fā)者：這么說，每個收費項目代碼都有一個名稱、客戶和項目？

客

戶：對，而且，還有一個類型，可記賬和不可記賬的判斷。

開發(fā)者：你認為會需要一種更復雜的層次結構嗎？

客

戶：什么意思？

開發(fā)者：換句話說，現(xiàn)在，你有客戶、項目和活動等信息，那么是不是還要一些子項目或者子活動的信息呢？

客

戶：不，我想不用。

開發(fā)者：誰來管理收費項目代碼？

客

戶：嗯，必要的時候我(業(yè)務經理)可以添加這類代碼，而且，每個經理會告訴下屬應該填寫什么。

開發(fā)者：你能想到一些特殊情況嗎？例如，雇員可能提前填寫表格或其他類似的事情嗎？

客

戶：噢，我明白你的意思。雇員不會這么做。如果有人在休假或住院，就由我來替他填寫表單。

開發(fā)者：這些數(shù)據(jù)收集起來后要用來做什么?

客

戶：每個月，我會將數(shù)據(jù)導入到支付系統(tǒng)中，用來產生賬單。

開發(fā)者：該系統(tǒng)是否應該自動選擇數(shù)據(jù)范圍和所有的雇

員？

客

戶：如果可能的話，可以由我來選擇要導出的數(shù)據(jù)范圍、客戶和雇員。

開發(fā)者：那么，支付系統(tǒng)有標準的數(shù)據(jù)格式嗎？

客

戶：是的，是基于XML的。

開發(fā)者：好的，我會詳細研究這個格式的。

開發(fā)者：謝謝，占用了你的時間。我想還會繼續(xù)合作……我們下周二再碰次頭，好嗎？

客

戶：好的。

在對話中，客戶和開發(fā)者共同發(fā)掘和精化客戶對系統(tǒng)的需求。注意，開發(fā)者首先提出問題，其次傾聽答案，然后要么總結要么問一個澄清的問題。在多數(shù)情況下，客戶并不確切地知道他們需要什么，當然更不可能會明白軟件開發(fā)所需要的細節(jié)。所以，開發(fā)者或需求分析員要把握這種討論并確保收集到必需的信息。

根據(jù)對話，開發(fā)人員就可以從高層的用例圖開始編寫真正的系統(tǒng)需求分析文檔。構建用例圖需要：確定參與者、確定用例、確定參與者和用例之間的關系。

8.9.2確定參與者

確定參與者的任務依賴于起點。認真研究原始記錄，區(qū)分不同的用戶群，選出候選的參與者。當存在業(yè)務模型時，確定參與者很簡單。系統(tǒng)分析員可以為業(yè)務中的每個工作人員建議一個參與者，也可以為每個使用信息系統(tǒng)的業(yè)務參與者(即每個業(yè)務的客戶)建議一個參與者。否則，不管有沒有領域模型，系統(tǒng)分析員都要與客戶一起來確定用戶，并設法將他們組織成不同類別的參與者。在這兩種情況下，需要將表示外部系統(tǒng)的參與者與用于系統(tǒng)維護和操作的參與者確定下來。

在挑選候選參與者時有兩個標準。首先，至少確定一個用戶來扮演候選參與者，這有助于獲得相關的參與者而避免只是想象中的參與者。其次，不同參與者扮演的角色之間的重疊應該最少，不應該兩個或多個參與者實際上擔當相同的角色。如果出現(xiàn)了這種情況，應設法將這些角色合并，或設法確定一個更一般化的參與者來充當重疊參與者的公共角色，新的參與者可以使用泛化關系進行特化。系統(tǒng)分析員為參與者命名，并簡要描述每個參與者的角色以及參與者使用系統(tǒng)做什么。

舉例：對話摘錄

開發(fā)者：誰會使用考勤系統(tǒng)？

客

戶：所有用它來記錄可記賬以及不可記賬工時的雇員。每個雇員將表格填好，然后用電子郵件發(fā)給我。

開發(fā)者：誰來管理收費項目代碼？

客

戶：嗯，必要的時候我(業(yè)務經理)可以添加這類代碼，而且，每個經理會告訴下屬應該填寫什么。

開發(fā)者：這些數(shù)據(jù)收集起來后要用來做什么?

客

戶：每個月，我會將數(shù)據(jù)導入到支付系統(tǒng)中，用來產生賬單。

這樣，就得到候選的參與者：雇員、業(yè)務經理、經理、支付系統(tǒng)。

有了候選參與者，需要進一步精化。精化參與者是一個交互的過程。在多數(shù)情況下，用戶都清楚自己在機構中的地位。如果開發(fā)人員采用用戶的術語表，那么接下來的會議會方便很多。而且，開發(fā)人員還需要仔細調查是否不同類型的人會用不同的方式來使用該系統(tǒng)。記住，參與者是由使用系統(tǒng)的方式決定的，而不是由他們的工作頭銜或在組織結構中的地位決定的。

第一個參與者看起來很清楚，雇員利用系統(tǒng)來記錄時間。下一個，業(yè)務經理，看起來很重要，只代表機構中的一個具體的人。如果這個人去休假了或隨著機構的變化，他需要將工作移交給他人，這種情況該怎么處理呢？通過與業(yè)務經理進一步交流，就可以發(fā)現(xiàn)“管理員”用戶是符合這個角色的。

那么，要確定“經理”是否是一個獨立的參與者，就需要安排一次面對面的交流。他們在考勤過程中會承擔一個角色，因為雇員需要知道應該在哪一個項目上記賬。但是，在當前的需求下，經理并不需要利用該系統(tǒng)來進行這種處理。經過討論，征得客戶同意，決定誰有權利來填寫收費項目代碼不是經理的需求。所以，經理不是一個參與者。

最后，作為與考勤系統(tǒng)交互的外部系統(tǒng)，支付系統(tǒng)也是一個參與者。

這樣，參與者就剩下兩個：雇員和管理員。當然，還有一個支付系統(tǒng)。

舉例：“雇員”、“管理員”和“支付系統(tǒng)”參與者

“雇員”：使用考勤系統(tǒng)來記錄可記賬以及不可記賬工時的員工。

“管理員”：管理考勤系統(tǒng)的員工，可以設置收費項目代碼，向支付系統(tǒng)導入數(shù)據(jù)。

“支付系統(tǒng)”：從考勤系統(tǒng)收集數(shù)據(jù)，產生賬單。

得到參與者集合，并對每個參與者進行簡要說明。此時，這些參與者便可以作為確定用例的起點。

8.9.3確定用例

當起點是業(yè)務模型時，可以按照“根據(jù)業(yè)務模型確定用例”中討論的方法來確定參與者和用例，為參與業(yè)務用例實現(xiàn)和使用信息系統(tǒng)的每個工作人員所充當?shù)慕巧O計用例。系統(tǒng)分析員逐個檢查參與者，為每個參與者設計候選用例。例如，可以通過訪談和故事板來了解需要用例做些什么。參與者通常需要用例支持其工作，可以創(chuàng)建、修改、跟蹤、刪除或研究業(yè)務用例中的業(yè)務對象(如“雇員”和“收費代碼”)。參與者可能要將某些外部事件或其他類似的方法告知系統(tǒng)，或反之，即參與者可能需要系統(tǒng)告知自己某些已經發(fā)生的事件(例如賬單)?？赡苓€需要有附加的參與者來執(zhí)行系統(tǒng)啟動、終止或維護等工作。

為每個用例選擇一個恰當、含義鮮明的名字。通常采用“動賓結構”來命名，應該反映參與者和系統(tǒng)之間的交互。例如：“記錄工時”和“設置收費代碼”等用例。

有時很難確定用例的范圍。用戶與系統(tǒng)交互可以在一個用例中確定，也可以在參與者引用的幾個用例中確定。在決定候選用例是否應該作為一個單獨的用例時，必須考慮用例是否完整，或是否總是作為另一個用例的延續(xù)。注意，這里有兩個關鍵，有價值的結果和具體參與者，表示了確定用例的兩個原則。

有價值的結果。每個可以成功執(zhí)行的用例都應該對其參與者提供某些價值，使參與者實現(xiàn)預定目標。有時候，參與者愿意為獲得價值而付出代價，一個用例實例(如打電話)可能涉及多個參與者。此時，“有價值的結果”應該針對最初的參與者，也避免確定太小的用例。

舉例：“支付賬單”用例的范圍

“結賬與支付系統(tǒng)”提供了“支付賬單”用例，買主使用該用例來確定已經訂購或收到的貨物賬單的支付日期。然后，“支付賬單”用例會在預定日期完成支付。

“支付賬單”用例包括確定支付日期和完成支付。如果將該用例分為兩部分，一部分是確定支付日期，另一部分是完成支付。其中“確定支付日期”不會增值，只有支付了賬單，才會獲得增加的價值。

具體的參與者。向真正的用戶提供有價值的用例，可以使用例不會變得太大。

尋找用例首先從原始記錄中識別候選用例，然后考慮需要哪些用例來支持這些已有的用例。有的候選用例可能不適合作為單獨的用例，最好作為其他用例的一部分。

存在這樣的用例：它們決定了系統(tǒng)的特性。在原始記錄中，關注下面的對話。

舉例：尋找主用例對話摘錄

開發(fā)者：誰會使用考勤系統(tǒng)？

客

戶：所有用它來記錄可記賬以及不可記賬工時的雇

員。

客

戶：每半個月用一個Excel表格來記錄。每個雇員將表格填好，然后用電子郵件發(fā)給我。表格格式：縱向是收費項目代碼，橫向是日期。雇員可以在每個條目上填寫說明。

開發(fā)者：誰來管理收費項目代碼？

客

戶：嗯，必要的時候我(業(yè)務經理)可以添加這類代碼，而且，每個經理總會告訴其下屬應該填寫什么。

開發(fā)者：這些數(shù)據(jù)收集起來后要用來做什么?

客

戶：每個月，我會將數(shù)據(jù)導入到支付系統(tǒng)中，用來產生賬單。

開發(fā)者：該系統(tǒng)是否應該自動選擇數(shù)據(jù)范圍和所有的雇員？

客

戶：如果可能的話，可以由我來選擇要導出的數(shù)據(jù)范圍、客戶和雇員。

開發(fā)者：那么，支付系統(tǒng)有標準的數(shù)據(jù)格式嗎？

客

戶：是的，是基于XML的。

開發(fā)者：好的，我會詳細研究這個格式的。

第一個摘錄產生了“記錄工時”用例，第二個產生了“填寫工時說明”用例，第三個產生了“設置收費代碼”用例，最后一個產生“導出工時記錄”用例。

對話中沒有提到支撐用例，可以通過交流進一步了解“系統(tǒng)在完成某個用例時需要什么”來得到?？紤]“記錄工時”用例，在雇員記錄其工時時，需要收費項目代碼列表和雇員列表。收費項目代碼列表，已經通過“設置收費代碼”用例產生，但是，雇員是怎么來的卻還沒有交代清楚，所以，“設置雇員”用例是必需的。其他的用例，“填寫工時說明”和“導出工時記錄”是由“記錄工時”用例支持的。

這樣，候選用例就有：設置雇員、設置收費代碼、記錄工時、填寫工時說明、導出工時記錄。

“設置雇員”用例只有一個用途，即管理員在系統(tǒng)中添加一個雇員信息作為系統(tǒng)的客戶。所以，“雇員”用例符合“集中”準則。顯然，管理員從新員工的經理那邊得到請求，然后，將員工信息添加到系統(tǒng)中。之后，系統(tǒng)有了明顯的變化：獲得一個新的最終用戶。所以，“設置雇員”符合“獨立提供價值”的原則。

“設置收費代碼”用例也只有一個用途，那就是讓管理員添加收費項目代碼到系統(tǒng)中。顯然，管理員從項目經理那邊得到請求，然后，將收費項目代碼添加到系統(tǒng)中。之后，系統(tǒng)發(fā)生了明顯的變化：得到一個新的代碼，最終用戶就可以使用該代碼。所以，“設置收費代碼”用例也符合準則。

“記錄工時”用例看起來不是很集中，雇員可以用它來瀏覽、更新和增加新的工時條目。而且，這些活動看起來不能獨自提供價值。盡管“記錄工時”有不同的子活動，但是它有一個不同的價值。當一個用例太大，而它的子用例又太小的時候，保留這個大用例還是比較明智的?！坝涗浌r”用例本身也是有價值的，它是整個系統(tǒng)的目標。

“填寫工時說明”用例顯然符合集中的原則，有非常具體的用處。但是，它違反了“獨立提供價值”的原則?！疤顚懝r說明”是“記錄工時”的一部分。所以，“填寫工時說明”用例就應該刪除，只作為“記錄工時”用例的一個細節(jié)即可。

顯然，“導出工時記錄”用例有一個嚴格定義的、有價值的目標，允許管理員導出系統(tǒng)數(shù)據(jù)。

在檢查整個用例模型的一致性之前，要先檢查每個用例。經過評估，用例集變?yōu)椋涸O置雇員、設置收費代碼、記錄工時、導出工時記錄。

最初確定的參與者和用例，在用例模型穩(wěn)定之前通常需要進行多次重構和評估。

系統(tǒng)的用例和構架是通過迭代逐步開發(fā)的。一旦得到了構架，后面捕獲的新用例一定要適合該構架。不適合構架的用例應該加以修改以便更好地融入構架，或改進構架以便易于補充新的用例。例如，最初確定用例時，頭腦中可能已經有了如何與具體用戶交互的構想，一旦確定了圖形用戶界面(GUI)框架，可能需要修改相應的用例，通常類似的適應性修改很小。

8.9.4簡要說明用例

分析員在確定用例時，有時會用一段話來說明每個用例，有時只記下用例的名字。之后，用幾句話來進行簡要的描述，概括用例的動作。然后，逐步說明用例與參與者交互時需要完成什么任務。

舉例：“支付賬單”用例的初始描述

簡要說明：“買主”使用“支付賬單”用例來確定賬單支付時間。而后，“支付賬單”用例在預定日期實現(xiàn)支付。

初始的逐步描述：

在對用例進行初始化之前，“買主”已經收到了賬單(由“買主賬單”用例發(fā)送)，而且已經收到了訂購的貨物或服務。

(1)買主檢查要支付的賬單并核對是否與原始訂單一致。

(2)買主確定通過銀行支付賬單的時間。

(3)在預定的支付日期，系統(tǒng)檢查買主的賬戶里是否有足夠的存款，如果有足夠的存款，就完成該事務。

現(xiàn)在，已經簡單介紹了參與者和用例。但不能孤立地描述和理解每個用例，還需要從整體上來把握，需要說明用例和參與者如何彼此相關以及如何組成用例模型。

8.9.5描述用例模型

可以用圖和文字從整體上解釋用例模型，尤其是說明用例如何彼此相關以及用例如何與參與者相關。對圖中應該包括哪些內容沒有嚴格的規(guī)定，因此，選擇能明確說明系統(tǒng)的圖。例如，可以畫圖來表示參與業(yè)務的若干用例(如圖8-10所示)，或表明參與者所執(zhí)行的若干用例。

每個參與者都參與一個或多個用例，每個用例都由一個或多個參與者觸發(fā)，創(chuàng)建高層用例圖就需要描述用例和參與者之間的這種關系，從參與者指向用例的箭頭表明參與者參與的用例。

分別考慮每個參與者。從與客戶的對話得知，“雇員”參與者不能觸發(fā)“設置雇員”、“設置收費代碼”或“導出工時記錄”用例。當然，在正常的情況下，“雇員”參與者必須觸發(fā)“記錄工時”用例。

顯然，“管理員”參與者觸發(fā)“設置雇員”、“設置收費代碼”以及“導出工時記錄”用例。充當“管理員”參與者角色的人幾乎肯定是組織的一個雇員，因此，也必須記錄自己的工時，在執(zhí)行“記錄工時”任務時，扮演雇員的角色，當且僅當記錄其他雇員的工時時，才有必要以“管理員”的身份來執(zhí)行。再研究一下會議記錄就可以發(fā)現(xiàn)這也是一個需求，因為管理員用戶需要為生病或請假的雇員登記工時。

圖8-10描述了參與者與用例之間的關系，是第一份用例圖草稿。

圖8-10考勤系統(tǒng)的第一次迭代用例圖

在同時描述幾個用例時為確保一致性，可建立術語表，這些術語可能來自領域模型或業(yè)務模型中的類。

對用例模型進行綜合說明，從整體上解釋用例模型，描述參與者與用例如何交互，并描述用例之間如何關聯(lián)。

舉例：用例模型綜合說明

“結賬與支付系統(tǒng)”(如圖8-9所示)中用例模型的綜合說明大致如下。

買主使用“定購貨物或服務”用例查看訂單條目和價格，匯總并提交訂單。可能當時或稍后，貨物或服務會連同賬單一起提交給買主。

買主啟動“支付賬單”用例，確認收到的賬單并確定支付時間。在預定的支付日期，“支付賬單”用例自動將存款從買主的賬戶轉到賣主的賬戶上。另外，如果出現(xiàn)透支，“支付賬單”用例將由“支付透支費”用例進行。

那么，賣主如何使用系統(tǒng)呢？

賣主可能會使用“確認訂單”用例查看、建議更改和確認收到的訂單。確認后的訂單將與訂購的貨物或服務一起發(fā)送出去。

當貨物或服務送達時，賣主通過“買主賬單”用例給買主開賬單。在開賬單時，賣主可能需要使用折扣率，還可能將幾個賬單合并為一個賬單。

如果買主到期沒有支付，賣主會得到通知并使用“發(fā)送提醒通知單”用例。系統(tǒng)也可以自動發(fā)送提醒通知單，這里，選擇另一種解決方案，即賣主先檢查一遍提醒通知單之后再發(fā)送出去，以避免給客戶帶來麻煩。

這時，系統(tǒng)分析員需要和客戶一起確認該模型的準確性和正確性。客戶必須認同所有的參與者和用例，在這次會議上，客戶必須執(zhí)行一個有價值的、理性的檢查，指出任何遺漏的特性。好的用例模型是需求的一個良好的切入點，客戶應該很容易理解。

這些用例是否已經捕獲所有必需的功能性需求；

每個用例的動作序列是否正確、完整且易于理解；

是否已經確定了一些價值很小或根本沒有價值的用例。果真如此，應該重新考慮這些用例。

8.10繼續(xù)需求流:考勤系統(tǒng)實例研究

用例圖為整個系統(tǒng)提供一個高層視圖。但是，對設計來說，所提供的信息是遠遠不夠的。對每個用例，還需要確定用戶是如何使用系統(tǒng)的。有了初步的用例模型，開發(fā)團隊的成員就可以進行更深入的訪談工作，進一步了解業(yè)務和應用域，對用例模型做深入的研究和詳細的描述。

8.10.1區(qū)分用例的優(yōu)先級

區(qū)分用例優(yōu)先級為迭代服務，決定哪些用例在早期的迭代中進行開發(fā)(即分析、設計、實現(xiàn)等)，哪些用例可以在后面的迭代中開發(fā)(如圖8-11所示)。

圖8-11區(qū)分用例優(yōu)先級的輸入及結果

用例模型的構架視圖包括描述某些重要和關鍵功能的用例，或涉及某些必須在軟件生命周期中盡早實現(xiàn)的重要需求的用例，描述對構架重要的用例，可作為計劃迭代時的輸入。

8.10.2詳細描述用例

細化用例是為了詳細描述其事件流，包括用例如何開始、結束以及如何與參與者交互(如圖8-12所示)。

以用例模型和相關的用例圖為起點，用例描述人員就可以詳細描述用例，將用例的逐步描述細化為精確的動作序列。

圖8-12詳細描述用例的輸入及結果

1．構造用例說明

用例定義了用例實例可能進入的狀態(tài)以及在這些狀態(tài)間的轉移(如圖8-13所示)，每個轉移都是由事件(如消息)觸發(fā)的用例實例執(zhí)行的動作序列。

圖8-13所示的狀態(tài)轉移圖可能非常復雜，必須盡可能簡單而精確地描述狀態(tài)轉移(動作序列)?？梢赃x擇一條從初態(tài)(最左面的圓角矩形)到終態(tài)(最右面的圓角矩形)的、中間狀態(tài)(后面的圓角矩形)、完整的基本路徑(圖8-13中帶箭頭的直線)，并在說明中對該路徑加以描述，而后將其他路徑(帶箭頭的曲線)描述為基本路徑的備選路徑，每條路徑單獨描述。

有時候備選路徑很小，可以直接插入基本路徑的描述中。記住，說明應該精確、易讀，無論選擇什么技術，都要描述所有的備選路徑，不然就不算確定了用例。圖8-13用例有一個初態(tài)、中間狀態(tài)、終態(tài)和狀態(tài)間的轉移。

出現(xiàn)基本路徑的備選、偏離或異常路徑有很多原因。

參與者可能選擇不同的路徑來完成用例。例如，在執(zhí)行“支付賬單”用例時，參與者可能決定支付或拒付賬單；

若用例涉及多個參與者，其中一個參與者的動作可能會影響其他參與者的動作路徑；

系統(tǒng)可能檢測到來自參與者的錯誤輸入；

有些系統(tǒng)資源可能出現(xiàn)故障，導致系統(tǒng)無法正常工作。

所選的基本路徑應是“正?！甭窂?，即用戶認為最有可能遵循的、能夠給參與者帶來最顯著價值的路徑?；韭窂揭话悴话ㄓ上到y(tǒng)加以處理的異常和特殊路徑。

2．細節(jié)描述模板——編寫用例文檔

該階段需要考慮已知的部署約束。例如，如果最終用戶是通過防火墻或便攜設備訪問系統(tǒng)，就需要為每個受影響的用例捕捉需求。但是，技術選擇決定又不在這個階段進行，所以，在該階段為部署約束而考慮解決具體的方案還為時過早。另一個常犯的錯誤是從界面設計上來考慮用例，這也是很不準確的，因為有些界面可能會支持好幾個用例，而有些用例在最終設計的時候可能又要用到好幾個界面。

在設計事件流的時候，開發(fā)者或需求分析員要扮演最終用戶的角色并考慮一系列問題：流程是如何開始的？系統(tǒng)需要從參與者中獲取什么信息？系統(tǒng)將如何響應？流程如何結束？這些答案可以通過一系列的系統(tǒng)輸入和系統(tǒng)響應來獲得。事件流就像一個不帶任何界面設計細節(jié)或響應格式的測試計劃。某些情況下，開發(fā)者可以通過與最終用戶的交互來理解每個用例的需求。

經常有這樣的想法，在同客戶召開了第一次會議之后就應該對系統(tǒng)有一個很清晰的認識。事實上，開發(fā)用例細節(jié)是個乏味而又充滿啟發(fā)意義的工作。在開發(fā)每個事件流并試圖描述前置條件和部署約束時，會發(fā)現(xiàn)一些相關的問題和懸而未決的事務，這些都可以列為需求文檔的一部分，并在第一次評審整個需求模型時去解決。

每個用例描述都使用相同的模板。雖然不同的項目用例模板也不一樣，但應該像下面描述的樣子。

用例名稱：動詞短語，描述用例目的的簡短動詞短語。

描述：簡要的段落，介紹用例目的，強調用例為參與者提供的價值。如果無法在一個簡短的段落中描述，那么用例可能不夠集中。

前置條件：簡短的段落，描述在哪些用例成功執(zhí)行之后，才會觸發(fā)該用例，描述其中的依賴關系。

部署約束：簡短的段落，描述如何使用系統(tǒng)來完成用例。例如，某個特定的用例是由“雇員”參與者觸發(fā)的，而該參與者是位于保護雇員客戶端的防火墻之后。那么，忽略這類約束就會導致嚴重的后果，因此必須盡快獲得這些信息。

正常事件流：交互動作的有序序列，描述所有的系統(tǒng)輸入以及系統(tǒng)響應，組成了該用例的正常流程。正常事件流表明事件按計劃進行時的交互動作，揭示了用例的目的。

可選事件流：交互動作的有序序列，描述組成該用例的一個可選流程的所有系統(tǒng)輸入及其響應。可選事件流顯示系統(tǒng)是如何對用戶的誤操作做出響應，例如，輸入一個無效的數(shù)據(jù)或按不正常的順序來執(zhí)行一個流程。需要編寫每個可選事件流。

異常或錯誤事件流：交互動作的有序序列，描述組成該用例的一個異常流程的所有系統(tǒng)輸入及其響應。異常流程捕捉系統(tǒng)對錯誤的響應，例如，無法獲取系統(tǒng)內部的或外部的資源。需要編寫每個異常事件流。

活動圖：在圖中顯示事件流的所有流程，能夠完整地描述事件流，為度量用例的復雜度提供方法。

非功能性需求：用一兩個簡短的段落來介紹用例成功執(zhí)行的判斷準則，該準則不適合在事件流中描述。例如，系統(tǒng)對用例的響應可能必須限制在3秒鐘以內；或者，在遍歷某個用例的事件流時，鼠標點擊次數(shù)的上限是7次。

說明(可選)：確定不符合上面類別的其他事務，其中可能包括對系統(tǒng)功能的限制。

未解決的問題(可選)：需要進一步詢問相關人員的問題列表。

舉例：“記錄工時”的用例文檔示例

用例名稱

記錄工時(RecordTime)

描述

雇員使用“記錄工時”用例來登記工時。管理員

使用該用例為任何雇員登記工時。

前置條件

無

部署約束

用戶可以從客戶端或雇員的家中訪問“記錄工時”用例，如果是從客戶端訪問，要考慮到防火墻。

正常事件流

雇員記錄工時。

(1)雇員查看當前時間段之前輸入的數(shù)據(jù)。

(2)雇員從已有的支付號碼中選擇一個，這些收費項目代碼是按客戶和項目組織的。

(3)雇員從當前的時間段選擇一個日期。

(4)雇員輸入以正整數(shù)表示的工時。

(5)在視圖中顯示數(shù)據(jù)，在以后的視圖中都可以看到該數(shù)據(jù)。

可選事件流

雇員修改工時。

(1)雇員查看當前時間段之前輸入的數(shù)據(jù)。

(2)雇員選擇一個已有的條目。

(3)雇員修改工時。

(4)在視圖中更新信息，在以后的視圖中都可以看到。

可選事件流

管理員為雇員登記工時。

(1)管理員查看按名稱排序的雇員列表。

(2)管理員選擇一個雇員，查看當前時間段之前輸入的數(shù)據(jù)。

(3)管理員從已有的收費項目代碼中選擇一個，這些收費項目代碼是按客戶和項目組織的。

(4)管理員從當前的時間段選擇一個日期。

(5)管理員輸入以正整數(shù)表示的工時。

(6)在視圖中顯示數(shù)據(jù)，在以后的視圖中都可以看到該數(shù)據(jù)。

異常事件流

由于系統(tǒng)或通信錯誤，系統(tǒng)無法對考勤卡進行更新。

(1)雇員查看當前時間段之前輸入的數(shù)據(jù)。

(2)雇員從已有的收費項目代碼中選擇—個，這些收費項目代碼是按客戶和項目組織的。

(3)雇員從當前的時間段選擇一個日期。

(4)雇員輸入以正整數(shù)表示的工時。由于系統(tǒng)或通信錯誤，系統(tǒng)無法完成這次操作。

(5)系統(tǒng)將錯誤及其詳細信息通知管理員，撤銷所有的改動，視圖回到前一個狀態(tài)。

(6)如果可能，在日志中記錄該錯誤。

活動圖

如圖8-14所示。

非功能性需求

無

未解決的問題

(1)雇員是否可以在以前的考勤卡上輸入和更改時間？

(2)雇員是否可以在以后的考勤卡上輸入和更改時間，例如，在休假之前？

圖8-14“記錄工時”用例的活動圖

舉例：“導出工時記錄”的用例文檔示例

用例名稱

導出工時記錄(ExportTimeEntries)

描述

管理員使用“導出工時記錄”將特定的考勤卡數(shù)據(jù)保存到格式化文件中。

前置條件

無

部署約束

無

正常事件流

管理員導出數(shù)據(jù)。

(1)管理員選擇一段日期。

(2)管理員選擇部分或所有的客戶。

(3)管理員選擇部分或所有的雇員。

(4)管理員選擇目標文件。

(5)數(shù)據(jù)以XML格式導出到文件中，過程結束后通知管理員。

異常事件流

由于系統(tǒng)錯誤，無法導出數(shù)據(jù)。

(1)管理員選擇一段日期。

(2)管理員選擇部分或所有的客戶。

(3)管理員選擇部分或所有的雇員。

(4)管理員選擇目標文件。

(5)系統(tǒng)無法導出數(shù)據(jù)，管理員得到有關錯誤的通知。

(6)如果可能，在日志中記錄該錯誤。

活動圖

如圖8-15所示。

圖8-15“導出工時記錄”用例的活動圖

非功能性需求

無

未解決的問題

(1)選擇數(shù)據(jù)的判斷準則是否足夠？

(2)選擇數(shù)據(jù)的判斷準則是否過于復雜？

(3)是否有其他的導出格式？

因為用例需要得到開發(fā)人員、客戶及用戶的理解，所以，應該像例子所示的那樣，用簡明的語言來描述用例。

在分析和設計階段，用例屬性可以作為啟發(fā)，用以確定類和屬性，例如，從用例的賬單屬性可以導出稱為“支付賬單”的設計類——在分析和設計期間，還應該考慮用于多個用例的對象，但在用例模型中則無需考慮。相反，應該禁止用例實例間的交互和訪問彼此屬性的實例以保持用例模型簡單。

如果系統(tǒng)需要與其他系統(tǒng)進行交互，就必須詳細說明。這項工作必須在細化階段的早期迭代中完成，因為系統(tǒng)間通信的實現(xiàn)常常會對構架產生影響。

當認為用例說明已經是易于理解的、正確的、完整的和一致的時候，用例說明就完成了。在需求捕獲末期舉行的評審會上，分析人員、用戶和客戶一起對用例說明進行評價，只有客戶和用戶才能驗證用例是否正確。

8.10.3構造用戶界面原型

構造用戶界面原型能夠幫助更好地理解用例，獲取需求(如圖8-16所示)。

設計用戶界面，可以使用戶有效地執(zhí)行用例。首先，從用例入