軟件工程課件：用例驅(qū)動

用例驅(qū)動8.1用例驅(qū)動開發(fā)概述8.2為什么使用用例8.3確定客戶需要什么8.4需求工作流8.5領(lǐng)域模型8.6業(yè)務(wù)模型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小結(jié)習(xí)題８

知識點

需求工作流，領(lǐng)域模型，業(yè)務(wù)模型，建模技術(shù)。

難點

如何將理論與實踐結(jié)合。

基于工作過程的教學(xué)任務(wù)

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

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

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

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

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

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

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

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

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

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

設(shè)計模型具有下面的特點：

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

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

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

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

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

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

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

8.2為什么使用用例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

用例是保證所有模型具有可跟蹤性的重要機制。需求階段的用例可以進一步在分析和設(shè)計階段實現(xiàn)，還可以追尋到參與實現(xiàn)的所有類、構(gòu)件(間接的)以及最后用來驗證用例的測試用例?？筛櫺允枪芾眄椖康囊粋€重要方面，當用例發(fā)生變化時，必須對相應(yīng)的設(shè)計、類、構(gòu)件和測試用例進行檢查以便更新，便于保持系統(tǒng)的完整性和需求變更的一致性。

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

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

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

8.3確定客戶需要什么

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

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

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

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

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

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

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

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

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

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

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

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

舉例：“取款”用例

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

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

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

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

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

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

8.4需

求

工

作

流

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

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

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

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

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

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

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

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

用例模型是在幾個開發(fā)增量的基礎(chǔ)上得到的，期間的迭代過程，或增加新的用例，或?qū)σ汛嬖诘挠美?guī)格說明增加細節(jié)。

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

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

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

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

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

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

8.5領(lǐng)域模型

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

解決問題的方法是構(gòu)造一張術(shù)語表，羅列領(lǐng)域中使用的技術(shù)詞匯并給出相應(yīng)的解釋。

(1)什么是領(lǐng)域模型？

領(lǐng)域模型能捕獲系統(tǒng)情境中最重要的對象類型，領(lǐng)域?qū)ο蟠硐到y(tǒng)工作環(huán)境中存在的“事物”或發(fā)生的事件。

很多領(lǐng)域?qū)ο蠡蝾惪梢詮男枨笠?guī)格說明中找到或通過訪談從領(lǐng)域?qū)＜夷抢锏玫剑I(lǐng)域類有下面三種典型的形式。

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

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

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

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

舉例：領(lǐng)域類（“訂單”、“賬單”、“訂單項”和“賬戶”）

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

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

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

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

(2)建立領(lǐng)域模型。

領(lǐng)域模型通常由領(lǐng)域分析員用UML或其他建模語言來描述，因此，要想建立一個高效的工作小組，還應(yīng)該包括領(lǐng)域?qū)＜?、以建模見長的其他人員等。

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

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

(3)領(lǐng)域模型的使用。

在確定用例和分析模型時要使用領(lǐng)域類和術(shù)語表，經(jīng)常用于下面的場合。

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

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

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

8.6業(yè)務(wù)模型

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

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

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

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

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

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

舉例：業(yè)務(wù)用例

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

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

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

(3)買主支付費用。

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

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

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

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

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

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

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

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

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

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

在“轉(zhuǎn)賬、取款和存款”用例中，從賬戶中取款或?qū)㈠X存人賬戶，或在兩個賬戶間轉(zhuǎn)賬；

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

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

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

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

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

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

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

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

買主和賣主使用“支付處理者”能為買主和賣主提供價值。“支付處理者”通過給買主發(fā)賬單并跟蹤未付款賬單來為賣主提供增值服務(wù)，同時，“支付處理者”簡化支付過程并提供更好的賬單支付信息和可用性，為買主提供增值服務(wù)。

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

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

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

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

業(yè)務(wù)建模和領(lǐng)域建模在某些方面非常相像。實際上，可以將領(lǐng)域建?？醋魇菢I(yè)務(wù)建模的一個簡單變體，只關(guān)注領(lǐng)域類或工作人員要處理的業(yè)務(wù)實體。因此，領(lǐng)域類和業(yè)務(wù)實體是非常相像的概念。

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

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

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

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

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

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

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

舉例：買主參與者

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

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

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

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

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

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

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

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

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

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

訪談過于非結(jié)構(gòu)化也不好，例如，對客戶說，“請談?wù)勀愕臉I(yè)務(wù)”，就不太可能得出很多相關(guān)的信息。因此，問題應(yīng)該以既能鼓勵受訪談?wù)呓o出范圍廣泛的回答，但又總是在訪談?wù)咚璧奶囟ㄐ畔⒌姆秶鷥?nèi)。

進行一次好的訪談并不容易。首先，訪談?wù)弑仨毷煜?yīng)用域。其次，若訪談?wù)咭呀?jīng)決定遵循客戶的需求，那么進行訪談是沒有太大作用的。無論訪談?wù)咧佬┦裁?，每次進行訪談都必須認真聆聽受訪談?wù)咚f的內(nèi)容，同時，要克制任何與客戶及要開發(fā)產(chǎn)品的潛在需求相關(guān)的固有成見。

訪談結(jié)束后，訪談?wù)弑仨殰蕚湟环菰L談的書面報告，最好將報告的副本發(fā)放給每一位受訪談?wù)撸@樣，可能會澄清某些有誤解的陳述或添加一些忽視的信息。

8.7補充需求

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

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

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

舉例：硬件平臺需求

服務(wù)器、PCServer

客戶機、PC機

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

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

舉例：文件格式約束

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

舉例：軟件平臺約束

系統(tǒng)軟件

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

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

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

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

舉例：其他需求

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

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

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

8.8初始需求

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

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

面向?qū)ο蠓缎褪堑模虼?，術(shù)語表、業(yè)務(wù)模型或需求可能要隨時進行調(diào)整。

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

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

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

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

確定參與者。

確定用例。

簡要描述每個用例。

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

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

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

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

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

8.9.1聆聽

一個系統(tǒng)是由其提供的價值來確定的，所以，該階段的目標就是從客戶的角度來認識系統(tǒng)。下面描述了與客戶之間的(有點理想化的)對話：開發(fā)者、負責(zé)考勤的業(yè)務(wù)經(jīng)理以及一個使用該系統(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ù)雜的層次結(jié)構(gòu)嗎？

客

戶：什么意思？

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

客

戶：不，我想不用。

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

客

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

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

客

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

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

客

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

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

員？

客

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

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

客

戶：是的，是基于XML的。

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

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

客

戶：好的。

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

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

8.9.2確定參與者

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

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

舉例：對話摘錄

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

客

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

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

客

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

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

客

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

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

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

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

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

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

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

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

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

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

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

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

8.9.3確定用例

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

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

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

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

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

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

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

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

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

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

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

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

客

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

員。

客

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

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

客

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

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

客

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

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

客

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

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

客

戶：是的，是基于XML的。

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

第一個摘錄產(chǎn)生了“記錄工時”用例，第二個產(chǎn)生了“填寫工時說明”用例，第三個產(chǎn)生了“設(shè)置收費代碼”用例，最后一個產(chǎn)生“導(dǎo)出工時記錄”用例。

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

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

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

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

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

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

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

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

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

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

8.9.4簡要說明用例

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

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

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

初始的逐步描述：

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

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

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

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

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

8.9.5描述用例模型

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

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

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

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

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

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

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

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

舉例：用例模型綜合說明

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

買主使用“定購貨物或服務(wù)”用例查看訂單條目和價格，匯總并提交訂單?？赡墚敃r或稍后，貨物或服務(wù)會連同賬單一起提交給買主。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.10.2詳細描述用例

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

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

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

1．構(gòu)造用例說明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

用例名稱

記錄工時(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“記錄工時”用例的活動圖

舉例：“導(dǎo)出工時記錄”的用例文檔示例

用例名稱

導(dǎo)出工時記錄(ExportTimeEntries)

描述

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

前置條件

無

部署約束

無

正常事件流

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

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

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

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

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

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

異常事件流

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

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

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

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

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

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

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

活動圖

如圖8-15所示。

圖8-15“導(dǎo)出工時記錄”用例的活動圖

非功能性需求

無

未解決的問題

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

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

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

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

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

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

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

8.10.3構(gòu)造用戶界面原型

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

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