基礎(chǔ)用例建模指南

1、用例建模指南級(jí)別： 初級(jí)傅純一, Rational中國(guó)區(qū)技術(shù)銷(xiāo)售經(jīng)理, IBM中國(guó)有限公司軟件部2004 年 11 月 01 日序言用例(Use Case)是一種描述系統(tǒng)需求的方法，使用用例的方法來(lái)描述系統(tǒng)需求的過(guò)程就是用例建模。用例方法最早是由Iva Jackboson博士提出的，后來(lái)被綜合到UML規(guī)范之中，成為一種標(biāo)準(zhǔn)化的需求表述體系。用例的使用在RUP中被推崇備至，整個(gè)RUP流程都被稱(chēng)作是"用例驅(qū)動(dòng)"(Use-Case Driven)的，各種類(lèi)型的開(kāi)發(fā)活動(dòng)包括項(xiàng)目管理、分析設(shè)計(jì)、測(cè)試、實(shí)現(xiàn)等都是以系統(tǒng)用例為主要輸入工件，用例模型奠定了整個(gè)系統(tǒng)軟件開(kāi)發(fā)的基礎(chǔ)。1. 什么

2、是用例？1.1 參與者和用例從用戶的角度來(lái)看，他們并不想了解系統(tǒng)的內(nèi)部結(jié)構(gòu)和設(shè)計(jì)，他們所關(guān)心的是系統(tǒng)所能提供的服務(wù)，也就是被開(kāi)發(fā)出來(lái)的系統(tǒng)將是如何被使用的，這就是用例方法的基本思想。用例模型主要由以下模型元素構(gòu)成：· 參與者(Actor) 參與者是指存在于被定義系統(tǒng)外部并與該系統(tǒng)發(fā)生交互的人或其他系統(tǒng)，他們代表的是系統(tǒng)的使用者或使用環(huán)境。 · 用例(Use Case) 用例用于表示系統(tǒng)所提供的服務(wù)，它定義了系統(tǒng)是如何被參與者所使用的，它描述的是參與者為了使用系統(tǒng)所提供的某一完整功能而與系統(tǒng)之間發(fā)生的一段對(duì)話。 · 通訊關(guān)聯(lián)(Communication Associ

3、ation) 通訊關(guān)聯(lián)用于表示參與者和用例之間的對(duì)應(yīng)關(guān)系，它表示參與者使用了系統(tǒng)中的哪些服務(wù)（用例），或者說(shuō)系統(tǒng)所提供的服務(wù)（用例）是被哪些參與者所使用的。 這三種模型元素在UML中的表述如下圖所示。以銀行自動(dòng)提款機(jī)(ATM)為例，它的主要功能可以由下面的用例圖來(lái)表示。ATM的主要使用者是銀行客戶，客戶主要使用自動(dòng)提款機(jī)來(lái)進(jìn)行銀行賬戶的查詢、提款和轉(zhuǎn)賬交易。通訊關(guān)聯(lián)表示的是參與者和用例之間的關(guān)系，箭頭表示在這一關(guān)系中哪一方是對(duì)話的主動(dòng)發(fā)起者，箭頭所指方是對(duì)話的被動(dòng)接受者；如果你不想強(qiáng)調(diào)對(duì)話中的主動(dòng)與被動(dòng)關(guān)系，可以使用不帶箭頭的關(guān)聯(lián)實(shí)線。在參與者和用例之間的信息流不是由通訊關(guān)聯(lián)來(lái)表示的，該信息流

4、是缺省存在的（用例本身描述的就是參與者和系統(tǒng)之間的對(duì)話），并且信息流向是雙向的，它與通訊關(guān)聯(lián)箭頭所指的方向毫無(wú)關(guān)系。1.2 用例的內(nèi)容用例圖使我們對(duì)系統(tǒng)的功能有了一個(gè)整體的認(rèn)知，我們可以知道有哪些參與者會(huì)與系統(tǒng)發(fā)生交互，每一個(gè)參與者需要系統(tǒng)為它提供什么樣的服務(wù)。用例描述的是參與者與系統(tǒng)之間的對(duì)話，但是這個(gè)對(duì)話的細(xì)節(jié)并沒(méi)有在用例圖中表述出來(lái)，針對(duì)每一個(gè)用例我們可以用事件流來(lái)描述這一對(duì)話的細(xì)節(jié)內(nèi)容。如在ATM系統(tǒng)中的"提款"用例可以用事件流表述如下：提款-基本事件流1. 用戶插入信用卡2. 輸入密碼3. 輸入提款金額4. 提取現(xiàn)金5. 退出系統(tǒng)，取回信用卡但是這只描述了提款用例

5、中最順利的一種情況，作為一個(gè)實(shí)用的系統(tǒng)，我們還必須考慮可能發(fā)生的各種其他情況，如信用卡無(wú)效、輸入密碼錯(cuò)、用戶賬號(hào)中的現(xiàn)金余額不夠等，所有這些可能發(fā)生的各種情況（包括正常的和異常的）被稱(chēng)之為用例的場(chǎng)景(Scenario)，場(chǎng)景也被稱(chēng)作是用例的實(shí)例(Instance)。在用例的各種場(chǎng)景中，最常見(jiàn)的場(chǎng)景是用基本流(Basic Flow)來(lái)描述的，其他的場(chǎng)景則是用備選流(Alternative Flow)來(lái)描述。對(duì)于ATM系統(tǒng)中的"提款"用例，我們可以得到如下一些備選流：提款-備選事件流備選流一：用戶可以在基本流中的任何一步選擇退出，轉(zhuǎn)至基本流步驟5。備選流二：在基本流步驟1中，用

6、戶插入無(wú)效信用卡，系統(tǒng)顯示錯(cuò)誤并退出信用卡，用例結(jié)束。備選流三：在基本流步驟中，用戶輸入錯(cuò)誤密碼，系統(tǒng)顯示錯(cuò)誤并提示用戶重新輸入密碼，重新回到基本流步驟2；三次輸入密碼錯(cuò)誤后，信用卡被系統(tǒng)沒(méi)收，用例結(jié)束。通過(guò)基本流與備選流的組合，就可以將用例所有可能發(fā)生的各種場(chǎng)景全部描述清楚。我們?cè)诿枋鲇美氖录鞯臅r(shí)候，就是要盡可能地將所有可能的場(chǎng)景都描述出來(lái)，以保證需求的完備性。1.3 用例方法的優(yōu)點(diǎn)用例方法完全是站在用戶的角度上（從系統(tǒng)的外部）來(lái)描述系統(tǒng)的功能的。在用例方法中，我們把被定義系統(tǒng)看作是一個(gè)黑箱，我們并不關(guān)心系統(tǒng)內(nèi)部是如何完成它所提供的功能的。用例方法首先描述了被定義系統(tǒng)有哪些外部使用者（抽

7、象成為Actor），這些使用者與被定義系統(tǒng)發(fā)生交互；針對(duì)每一參與者，用例方法又描述了系統(tǒng)為這些參與者提供了什么樣的服務(wù)（抽象成為Use Case），或者說(shuō)系統(tǒng)是如何被這些參與者使用的。所以從用例圖中，我們可以得到對(duì)于被定義系統(tǒng)的一個(gè)總體印象。與傳統(tǒng)的功能分解方式相比，用例方法完全是從外部來(lái)定義系統(tǒng)的功能，它把需求與設(shè)計(jì)完全分離開(kāi)來(lái)。在面向?qū)ο蟮姆治鲈O(shè)計(jì)方法中，用例模型主要用于表述系統(tǒng)的功能性需求，系統(tǒng)的設(shè)計(jì)主要由對(duì)象模型來(lái)記錄表述。另外，用例定義了系統(tǒng)功能的使用環(huán)境與上下文，每一個(gè)用例描述的是一個(gè)完整的系統(tǒng)服務(wù)。用例方法比傳統(tǒng)的SRS更易于被用戶所理解，它可以作為開(kāi)發(fā)人員和用戶之間針對(duì)系統(tǒng)需求

8、進(jìn)行溝通的一個(gè)有效手段。在RUP中，用例被作為整個(gè)軟件開(kāi)發(fā)流程的基礎(chǔ)，很多類(lèi)型的開(kāi)發(fā)活動(dòng)都把用例作為一個(gè)主要的輸入工件(Artifact)，如項(xiàng)目管理、分析設(shè)計(jì)、測(cè)試等。根據(jù)用例來(lái)對(duì)目標(biāo)系統(tǒng)進(jìn)行測(cè)試，可以根據(jù)用例中所描述的環(huán)境和上下文來(lái)完整地測(cè)試一個(gè)系統(tǒng)服務(wù)，可以根據(jù)用例的各個(gè)場(chǎng)景(Scenario)來(lái)設(shè)計(jì)測(cè)試用例，完全地測(cè)試用例的各種場(chǎng)景可以保證測(cè)試的完備性。2. 建立用例模型使用用例的方法來(lái)描述系統(tǒng)的功能需求的過(guò)程就是用例建模，用例模型主要包括以下兩部分內(nèi)容：· 用例圖(Use Case Diagram) 確定系統(tǒng)中所包含的參與者、用例和兩者之間的對(duì)應(yīng)關(guān)系，用例圖描述的是關(guān)于系統(tǒng)

9、功能的一個(gè)概述。 · 用例規(guī)約(Use Case Specification) 針對(duì)每一個(gè)用例都應(yīng)該有一個(gè)用例規(guī)約文檔與之相對(duì)應(yīng)，該文檔描述用例的細(xì)節(jié)內(nèi)容。 在用例建模的過(guò)程中，我們建議的步聚是先找出參與者，再根據(jù)參與者確定每個(gè)參與者相關(guān)的用例，最后再細(xì)化每一個(gè)用例的用例規(guī)約。2.1 尋找參與者所謂的參與者是指所有存在于系統(tǒng)外部并與系統(tǒng)進(jìn)行交互的人或其他系統(tǒng)。通俗地講，參與者就是我們所要定義系統(tǒng)的使用者。尋找參與者可以從以下問(wèn)題入手：· 系統(tǒng)開(kāi)發(fā)完成之后，有哪些人會(huì)使用這個(gè)系統(tǒng)？ · 系統(tǒng)需要從哪些人或其他系統(tǒng)中獲得數(shù)據(jù)？ · 系統(tǒng)會(huì)為哪些人或其他系統(tǒng)提

10、供數(shù)據(jù)？ · 系統(tǒng)會(huì)與哪些其他系統(tǒng)相關(guān)聯(lián)？ · 系統(tǒng)是由誰(shuí)來(lái)維護(hù)和管理的？ 這些問(wèn)題有助于我們抽象出系統(tǒng)的參與者。對(duì)于ATM機(jī)的例子，回答這些問(wèn)題可以使我們找到更多的參與者：操作員負(fù)責(zé)維護(hù)和管理ATM機(jī)系統(tǒng)、ATM機(jī)也需要與后臺(tái)服務(wù)器進(jìn)行通訊以獲得有關(guān)用戶賬號(hào)的相關(guān)信息。 系統(tǒng)邊界決定了參與者參與者是由系統(tǒng)的邊界所決定的，如果我們所要定義的系統(tǒng)邊界僅限于ATM機(jī)本身，那么后臺(tái)服務(wù)器就是一個(gè)外部的系統(tǒng)，可以抽象為一個(gè)參與者。如果我們所要定義的系統(tǒng)邊界擴(kuò)大至整個(gè)銀行系統(tǒng)，ATM機(jī)和后臺(tái)服務(wù)器都是整個(gè)銀行系統(tǒng)的一部分，這時(shí)候后臺(tái)服務(wù)器就不再被抽象成為一個(gè)參與者。值得注意的是，用例

11、建模時(shí)不要將一些系統(tǒng)的組成結(jié)構(gòu)作為參與者來(lái)進(jìn)行抽象，如在ATM機(jī)系統(tǒng)中，打印機(jī)只是系統(tǒng)的一個(gè)組成部分，不應(yīng)將它抽象成一個(gè)獨(dú)立的參與者；在一個(gè)MIS管理系統(tǒng)中，數(shù)據(jù)庫(kù)系統(tǒng)往往只作為系統(tǒng)的一個(gè)組成部分，一般不將其單獨(dú)抽象成一個(gè)參與者。 特殊的參與者系統(tǒng)時(shí)鐘有時(shí)候我們需要在系統(tǒng)內(nèi)部定時(shí)地執(zhí)行一些操作，如檢測(cè)系統(tǒng)資源使用情況、定期地生成統(tǒng)計(jì)報(bào)表等等。從表面上看，這些操作并不是由外部的人或系統(tǒng)觸發(fā)的，應(yīng)該怎樣用用例方法來(lái)表述這一類(lèi)功能需求呢？對(duì)于這種情況，我們可以抽象出一個(gè)系統(tǒng)時(shí)鐘或定時(shí)器參與者，利用該參與者來(lái)觸發(fā)這一類(lèi)定時(shí)操作。從邏輯上，這一參與者應(yīng)該被理解成是系統(tǒng)外部的，由它來(lái)觸發(fā)系統(tǒng)所提供的用例對(duì)

12、話。2.2 確定用例找到參與者之后，我們就可以根據(jù)參與者來(lái)確定系統(tǒng)的用例，主要是看各參與者需要系統(tǒng)提供什么樣的服務(wù)，或者說(shuō)參與者是如何使用系統(tǒng)的。尋找用例可以從以下問(wèn)題入手（針對(duì)每一個(gè)參與者）：· 參與者為什么要使用該系統(tǒng)？ · 參與者是否會(huì)在系統(tǒng)中創(chuàng)建、修改、刪除、訪問(wèn)、存儲(chǔ)數(shù)據(jù)？如果是的話，參與者又是如何來(lái)完成這些操作的？ · 參與者是否會(huì)將外部的某些事件通知給該系統(tǒng)？ · 系統(tǒng)是否會(huì)將內(nèi)部的某些事件通知該參與者？ 綜合以上所述，ATM系統(tǒng)的用例圖可表示如下，在用例的抽取過(guò)程中，必須注意：用例必須是由某一個(gè)主角觸發(fā)而產(chǎn)生的活動(dòng)，即每個(gè)用例至少應(yīng)該涉及

13、一個(gè)主角。如果存在與主角不進(jìn)行交互的用例，就可以考慮將其并入其他用例；或者是檢查該用例相對(duì)應(yīng)的參與者是否被遺漏，如果是，則補(bǔ)上該參與者。反之，每個(gè)參與者也必須至少涉及到一個(gè)用例，如果發(fā)現(xiàn)有不與任何用例相關(guān)聯(lián)的參與者存在，就應(yīng)該考慮該參與者是如何與系統(tǒng)發(fā)生對(duì)話的，或者由參與者確定一個(gè)新的用例，或者該參與者是一個(gè)多余的模型元素，應(yīng)該將其刪除。可視化建模的主要目的之一就是要增強(qiáng)團(tuán)隊(duì)的溝通，用例模型必須是易于理解的。用例建模往往是一個(gè)團(tuán)隊(duì)開(kāi)發(fā)的過(guò)程，系統(tǒng)分析員在建模過(guò)程中必須注意參與者和用例的名稱(chēng)應(yīng)該符合一定的命名約定，這樣整個(gè)用例模型才能夠符合一定的風(fēng)格。如參與者的名稱(chēng)一般都是名詞，用例名稱(chēng)一般都是

14、動(dòng)賓詞組等。對(duì)于同一個(gè)系統(tǒng)，不同的人對(duì)于參與者和用例都可能有不同的抽象結(jié)果，因而得到不同的用例模型。我們需要在多個(gè)用例模型方案中選擇一種"最佳"（或"較佳"）的結(jié)果，一個(gè)好的用例模型應(yīng)該能夠容易被不同的涉眾所理解，并且不同的涉眾對(duì)于同一用例模型的理解應(yīng)該是一致的。2.3 描述用例規(guī)約應(yīng)該避免這樣一種誤解認(rèn)為由參與者和用例構(gòu)成的用例圖就是用例模型，用例圖只是在總體上大致描述了系統(tǒng)所能提供的各種服務(wù)，讓我們對(duì)于系統(tǒng)的功能有一個(gè)總體的認(rèn)識(shí)。除此之外，我們還需要描述每一個(gè)用例的詳細(xì)信息，這些信息包含在用例規(guī)約中，用例模型是由用例圖和每一個(gè)用例的詳細(xì)描述用例規(guī)約所

15、組成的。RUP中提供了用例規(guī)約的模板，每一個(gè)用例的用例規(guī)約都應(yīng)該包含以下內(nèi)容：· 簡(jiǎn)要說(shuō)明 (Brief Description) 簡(jiǎn)要介紹該用例的作用和目的。 · 事件流 (Flow of Event) 包括基本流和備選流，事件流應(yīng)該表示出所有的場(chǎng)景。 · 用例場(chǎng)景 (Use-Case Scenario) 包括成功場(chǎng)景和失敗場(chǎng)景，場(chǎng)景主要是由基本流和備選流組合而成的。 · 特殊需求 (Special Requirement) 描述與該用例相關(guān)的非功能性需求（包括性能、可靠性、可用性和可擴(kuò)展性等）和設(shè)計(jì)約束（所使用的操作系統(tǒng)、開(kāi)發(fā)工具等）。 ·

16、 前置條件 (Pre-Condition) 執(zhí)行用例之前系統(tǒng)必須所處的狀態(tài)。 · 后置條件 (Post-Condition) 用例執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)。 用例規(guī)約基本上是用文本方式來(lái)表述的，為了更加清晰地描述事件流，也可以選擇使用狀態(tài)圖、活動(dòng)圖或序列圖來(lái)輔助說(shuō)明。只要有助于表達(dá)的簡(jiǎn)潔明了，就可以在用例中任意粘貼用戶界面和流程的圖形化顯示方式，或是其他圖形。如活動(dòng)圖有助于描述復(fù)雜的決策流程，狀態(tài)轉(zhuǎn)移圖有助于描述與狀態(tài)相關(guān)的系統(tǒng)行為，序列圖適合于描述基于時(shí)間順序的消息傳遞。 基本流基本流描述的是該用例最正常的一種場(chǎng)景，在基本流中系統(tǒng)執(zhí)行一系列活動(dòng)步驟來(lái)響應(yīng)參與者提出的服務(wù)請(qǐng)求

17、。我們建議用以下格式來(lái)描述基本流：1) 每一個(gè)步驟都需要用數(shù)字編號(hào)以清楚地標(biāo)明步驟的先后順序。2) 用一句簡(jiǎn)短的標(biāo)題來(lái)概括每一步驟的主要內(nèi)容，這樣閱讀者可以通過(guò)瀏覽標(biāo)題來(lái)快速地了解用例的主要步驟。在用例建模的早期，我們也只需要描述到事件流步驟標(biāo)題這一層，以免過(guò)早地陷入到用例描述的細(xì)節(jié)中去。3) 當(dāng)整個(gè)用例模型基本穩(wěn)定之后，我們?cè)籴槍?duì)每一步驟詳細(xì)描述參與者和系統(tǒng)之間所發(fā)生的交互。建議采用雙向(roundtrip)描述法來(lái)保證描述的完整性，即每一步驟都需要從正反兩個(gè)方面來(lái)描述:(1)參與者向系統(tǒng)提交了什么信息；(2)對(duì)此系統(tǒng)有什么樣的響應(yīng)。具體例子請(qǐng)參見(jiàn)附錄。在描述參與者和系統(tǒng)之間的信息交換時(shí)，需

18、指出來(lái)回傳遞的具體信息。例如，只表述參與者輸入了客戶信息就不夠明確，最好明確地說(shuō)參與者輸入了客戶姓名和地址。通?？梢岳迷~匯表讓用例的復(fù)雜性保持在可控范圍內(nèi)，可以在詞匯表中定義客戶信息等內(nèi)容，使用例不至于陷入過(guò)多的細(xì)節(jié)。 備選流備選流負(fù)責(zé)描述用例執(zhí)行過(guò)程中異常的或偶爾發(fā)生的一些情況，備選流和基本流的組合應(yīng)該能夠覆蓋該用例所有可能發(fā)生的場(chǎng)景。在描述備選流時(shí)，應(yīng)該包括以下幾個(gè)要素：1) 起點(diǎn)：該備選流從事件流的哪一步開(kāi)始；2) 條件：在什么條件下會(huì)觸發(fā)該備選流；3) 動(dòng)作：系統(tǒng)在該備選流下會(huì)采取哪些動(dòng)作；4) 恢復(fù)：該備選流結(jié)束之后，該用例應(yīng)如何繼續(xù)執(zhí)行。備選流的描述格式可以與基本流的格式一致，也

19、需要編號(hào)并以標(biāo)題概述其內(nèi)容，編號(hào)前可以加以字母前綴A(Alternative)以示與基本流步驟相區(qū)別。 用例場(chǎng)景用例在實(shí)際執(zhí)行的時(shí)候會(huì)有很多的不同情況發(fā)生，稱(chēng)之為用例場(chǎng)景；也可以說(shuō)場(chǎng)景是用例的實(shí)例，我們?cè)诿枋鲇美臅r(shí)候要覆蓋所有的用例場(chǎng)景，否則就有可能導(dǎo)致需求的遺漏。在用例規(guī)約中，場(chǎng)景的描述可以由基本流和備選流的組合來(lái)表示。場(chǎng)景既可以幫助我們防止需求的遺漏，同時(shí)也可以對(duì)后續(xù)的開(kāi)發(fā)工作起到很大的幫助：開(kāi)發(fā)人員必須實(shí)現(xiàn)所有的場(chǎng)景、測(cè)試人員可以根據(jù)用例場(chǎng)景來(lái)設(shè)計(jì)測(cè)試用例。 特殊需求特殊需求通常是非功能性需求，它為一個(gè)用例所專(zhuān)有，但不適合在用例的事件流文本中進(jìn)行說(shuō)明。特殊需求的例子包括法律或法規(guī)方面的

20、需求、應(yīng)用程序標(biāo)準(zhǔn)和所構(gòu)建系統(tǒng)的質(zhì)量屬性（包括可用性、可靠性、性能或支持性需求等）。此外，其他一些設(shè)計(jì)約束，如操作系統(tǒng)及環(huán)境、兼容性需求等，也可以在此節(jié)中記錄。需要注意的是，這里記錄的是專(zhuān)屬于該用例的特殊需求；對(duì)于一些全局的非功能性需求和設(shè)計(jì)約束，它們并不是該用例所專(zhuān)有的，應(yīng)把它們記錄在補(bǔ)充規(guī)約中。 前置和后置條件前置條件是執(zhí)行用例之前必須存在的系統(tǒng)狀態(tài)，后置條件是用例執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)。2.4 檢查用例模型用例模型完成之后，可以對(duì)用例模型進(jìn)行檢查，看看是否有遺漏或錯(cuò)誤之處。主要可以從以下幾個(gè)方面來(lái)進(jìn)行檢查：· 功能需求的完備性 現(xiàn)有的用例模型是否完整地描述了系統(tǒng)功能，

21、這也是我們判斷用例建模工作是否結(jié)束的標(biāo)志。如果發(fā)現(xiàn)還有系統(tǒng)功能沒(méi)有被記錄在現(xiàn)有的用例模型中，那么我們就需要抽象一些新的用例來(lái)記錄這些需求，或是將他們歸納在一些現(xiàn)有的用例之中。 · 模型是否易于理解 用例模型最大的優(yōu)點(diǎn)就在于它應(yīng)該易于被不同的涉眾所理解，因而用例建模最主要的指導(dǎo)原則就是它的可理解性。用例的粒度、個(gè)數(shù)以及模型元素之間的關(guān)系復(fù)雜程度都應(yīng)該由該指導(dǎo)原則決定。 · 是否存在不一致性 系統(tǒng)的用例模型是由多個(gè)系統(tǒng)分析員協(xié)同完成的，模型本身也是由多個(gè)工件所組成的，所以我們要特別注意不同工件之前是否存在前后矛盾或沖突的地方，避免在模型內(nèi)部產(chǎn)生不一致性。不一致性會(huì)直接影響到需求

22、定義的準(zhǔn)確性。 · 避免二義性語(yǔ)義 好的需求定義應(yīng)該是無(wú)二義性的，即不同的人對(duì)于同一需求的理解應(yīng)該是一致的。在用例規(guī)約的描述中，應(yīng)該避免定義含義模糊的需求，即無(wú)二義性。 3. 系統(tǒng)需求RUP中根據(jù)FURPS+模型將系統(tǒng)需求分為以下幾類(lèi)：· 功能(Functionality) · 可用性(Usability) · 可靠性(Reliability) · 性能(Performance) · 可支持性(Supportability) · 設(shè)計(jì)約束等 除了第一項(xiàng)功能性需求之外的其他需求都?xì)w之為非功能性需求。3.1 需求工件集用例模型主

23、要用于描述系統(tǒng)的功能性需求，對(duì)于其他的非功能性需要用其他文檔來(lái)記錄。RUP中定義了如下的需求工件集合。· 用例模型：記錄功能性需求 o 用例圖：描述參與者和用例之間的關(guān)系 o 用例規(guī)約：描述每一個(gè)用例的細(xì)節(jié)信息 · 補(bǔ)充規(guī)約：記錄一些全局性的功能需求、非功能性需求和設(shè)計(jì)約束等 · 詞匯表：記錄一些系統(tǒng)需求相關(guān)的術(shù)語(yǔ) 在實(shí)際應(yīng)用中，除了這些工件之外，我們還可以根據(jù)實(shí)際需求靈活選用其他形式的文檔來(lái)補(bǔ)充說(shuō)明需求。并不是所有的系統(tǒng)需求都適合用用例模型來(lái)描述的，如編譯器，我們很難用用例方法來(lái)表述它所處理的語(yǔ)言的方法規(guī)則，在這種情況下，采用傳統(tǒng)的BNF范式來(lái)表述更加合適一些。

24、在電信軟件行業(yè)中，很多電信標(biāo)準(zhǔn)都是采用SDL語(yǔ)言來(lái)描述的，我們也不必用UML來(lái)改寫(xiě)這些標(biāo)準(zhǔn)（UML對(duì)SDL存在著這樣的兼容性），只需將SDL形式的電信標(biāo)準(zhǔn)作為需求工件之一，在其他工件中對(duì)其加以引用就可以了?？傊f(wàn)萬(wàn)不可拘泥于用例建模的形式，應(yīng)靈活運(yùn)用各種方式的長(zhǎng)處。3.2 補(bǔ)充規(guī)約補(bǔ)充規(guī)約記錄那些在用例模型中不易表述的系統(tǒng)需求，主要包括以下內(nèi)容。· 功能性 功能性需求主要在用例模型中刻畫(huà)，但是也有部分需求不適合在用例中表述。有些功能性需求是全局性的，適用于所有的用例，如出錯(cuò)處理、I18N支持等，我們不需要在所有的用例中描述這些功能性需求，只需要在補(bǔ)充規(guī)約中統(tǒng)一描述就可以了。

25、83; 可用性 記錄所有可用性相關(guān)的需求，如系統(tǒng)的使用者所需要的培訓(xùn)時(shí)間、是否應(yīng)符合一些常見(jiàn)的可用性標(biāo)準(zhǔn)如Windows界面風(fēng)格等。 · 可靠性 定義系統(tǒng)可靠性相關(guān)的各種指標(biāo)，包括： o 可用性：指出可用時(shí)間百分比(xx.xx%)，系統(tǒng)處于使用、維護(hù)、降級(jí)模式等操作的小時(shí)數(shù)； o 平均故障間隔時(shí)間(MTBF)：通常表示為小時(shí)數(shù)，但也可表示為天數(shù)、月數(shù)或年數(shù)； o 平均修復(fù)時(shí)間(MTTR)：系統(tǒng)在發(fā)生故障后可以暫停運(yùn)行的時(shí)間； o 精確度：指出系統(tǒng)輸出要求具備的精密度（分辨率）和精確度（按照某一已知的標(biāo)準(zhǔn)）； o 最高錯(cuò)誤或缺陷率：通常表示為bugs/KLOC（每千行代碼的錯(cuò)誤數(shù)目）或

26、bugs/function-point（每個(gè)功能點(diǎn)的錯(cuò)誤數(shù)目）。 · 性能 記錄系統(tǒng)性能相關(guān)的各種指標(biāo)，包括： o 對(duì)事務(wù)的響應(yīng)時(shí)間（平均、最長(zhǎng)）； o 吞吐量（例如每秒處理的事務(wù)數(shù)）； o 容量（例如系統(tǒng)可以容納的客戶或事務(wù)數(shù)）； o 降級(jí)模式（當(dāng)系統(tǒng)以某種形式降級(jí)時(shí)可接受的運(yùn)行模式）； o 資源利用情況：內(nèi)存、磁盤(pán)、通信等。 · 可支持性 定義所有與系統(tǒng)的可支持性或可維護(hù)性相關(guān)的需求，其中包括編碼標(biāo)準(zhǔn)、命名約定、類(lèi)庫(kù)、如何來(lái)對(duì)系統(tǒng)進(jìn)行維護(hù)操作和相應(yīng)的維護(hù)實(shí)用工具等。 · 設(shè)計(jì)約束 設(shè)計(jì)約束代表已經(jīng)批準(zhǔn)并必須遵循的設(shè)計(jì)決定，其中包括軟件開(kāi)發(fā)流程、開(kāi)發(fā)工具、系統(tǒng)構(gòu)

27、架、編程語(yǔ)言、第三方構(gòu)件類(lèi)庫(kù)、運(yùn)行平臺(tái)和數(shù)據(jù)庫(kù)系統(tǒng)等等。 3.3 詞匯表詞匯表主要用于定義項(xiàng)目特定的術(shù)語(yǔ)，它有助于開(kāi)發(fā)人員對(duì)項(xiàng)目中所用的術(shù)語(yǔ)有統(tǒng)一的理解和使用，它也是后續(xù)階段中進(jìn)行對(duì)象抽象的基礎(chǔ)。4. 調(diào)整用例模型在一般的用例圖中，我們只表述參與者和用例之間的關(guān)系，即它們之間的通訊關(guān)聯(lián)。除此之外，我們還可以描述參與者與參與者之間的泛化(generalization)、用例和用例之間的包含(include)、擴(kuò)展(extend)和泛化(generalization)關(guān)系。我們利用這些關(guān)系來(lái)調(diào)整已有的用例模型，把一些公共的信息抽取出來(lái)重用，使得用例模型更易于維護(hù)。但是在應(yīng)用中要小心選用這些關(guān)系，一

28、般來(lái)說(shuō)這些關(guān)系都會(huì)增加用例和關(guān)系的個(gè)數(shù)，從而增加用例模型的復(fù)雜度。而且一般都是在用例模型完成之后才對(duì)用例模型進(jìn)行調(diào)整，所以在用例建模的初期不必要急于抽象用例之間的關(guān)系。4.1 參與者之間的關(guān)系參與者之間可以有泛化(Generalization)關(guān)系（或稱(chēng)為"繼承"關(guān)系）。例如在需求分析中常見(jiàn)的權(quán)限控制問(wèn)題（如下圖所示），一般的用戶只可以使用一些常規(guī)的操作，而管理員除了常規(guī)操作之外還需要進(jìn)行一些系統(tǒng)管理工作，操作員既可以進(jìn)行常規(guī)操作又可以進(jìn)行一些配置操作。在這個(gè)例子中我們會(huì)發(fā)現(xiàn)管理員和操作員都是一種特殊的用戶，他們擁有普通用戶所擁有的全部權(quán)限，此外他們還有自己獨(dú)有的權(quán)限。這里

29、我們可進(jìn)一步把普通用戶和管理員、操作員之間的關(guān)系抽象成泛化(Generalization)關(guān)系，管理員和操作員可以繼承普通用戶的全部特性（包括權(quán)限），他們又可以有自己獨(dú)有的特性（如操作、權(quán)限等）。這樣可以顯著減速少用例圖中通訊關(guān)聯(lián)的個(gè)數(shù)，簡(jiǎn)化用例模型，使之更易于理解。4.2 用例之間的關(guān)系用例描述的是系統(tǒng)外部可見(jiàn)的行為，是系統(tǒng)為某一個(gè)或幾個(gè)參與者提供的一段完整的服務(wù)。從原則上來(lái)講，用例之間都是并列的，它們之間并不存在著包含從屬關(guān)系。但是從保證用例模型的可維護(hù)性和一致性角度來(lái)看，我們可以在用例之間抽象出包含(include)、擴(kuò)展(extend)和泛化(generalization)這幾種關(guān)系。

30、這幾種關(guān)系都是從現(xiàn)有的用例中抽取出公共的那部分信息，然后通過(guò)不同的方法來(lái)重用這部公共信息，以減少模型維護(hù)的工作量。 包含(include)包含關(guān)系是通過(guò)在關(guān)聯(lián)關(guān)系上應(yīng)用<<include>>構(gòu)造型來(lái)表示的，如下圖所示。它所表示的語(yǔ)義是指基礎(chǔ)用例(Base)會(huì)用到被包含用例(Inclusion)，具體地講，就是將被包含用例的事件流插入到基礎(chǔ)用例的事件流中。包含關(guān)系是UML1.3中的表述，在UML1.1中，同等語(yǔ)義的關(guān)系被表述為使用(uses)，如下圖。在ATM機(jī)中，如果查詢、取現(xiàn)、轉(zhuǎn)賬這三個(gè)用例都需要打印一個(gè)回執(zhí)給客戶，我們就可以把打印回執(zhí)這一部分內(nèi)容提取出來(lái)，抽象成為一

31、個(gè)單獨(dú)的用例"打印回執(zhí)"，而原有的查詢、取現(xiàn)、轉(zhuǎn)賬三個(gè)例都會(huì)包含這個(gè)用例。每當(dāng)以后要對(duì)打印回執(zhí)部分的需求進(jìn)行修改時(shí)，就只需要改動(dòng)一個(gè)用例，而不用在每一個(gè)用例都作相應(yīng)修改，這樣就提高了用例模型的可維護(hù)性。在基礎(chǔ)用例的事件流中，我們只需要引用被包含用例即可。查詢-基本事件流1. 用戶插入信用卡2. 輸入密碼3. 選擇查詢4. 查看賬號(hào)余額5. 包含用例"打印回執(zhí)"6. 退出系統(tǒng)，取回信用卡在這個(gè)例子中，多個(gè)用例需要用到同一段行為，我們可以把這段共同的行為單獨(dú)抽象成為一個(gè)用例，然后讓其他的用例來(lái)包含這一用例。從而避免在多個(gè)用例中重復(fù)性地描述同一段行為，也可以防

32、止該段行為在多個(gè)用例中的描述出現(xiàn)不一致性。當(dāng)需要修改這段公共的需求時(shí)，我們也只需要修改一個(gè)用例，避免同時(shí)修改多個(gè)用例而產(chǎn)生的不一致性和重復(fù)性工作。有時(shí)當(dāng)某一個(gè)用例的事件流過(guò)于復(fù)雜時(shí)，為了簡(jiǎn)化用例的描述，我們也可以把某一段事件流抽象成為一個(gè)被包含的用例。這種情況類(lèi)似于在過(guò)程設(shè)計(jì)語(yǔ)言中，將程序的某一段算法封裝成一個(gè)子過(guò)程，然后再?gòu)闹鞒绦蛑姓{(diào)用這一子過(guò)程。 擴(kuò)展(extend)擴(kuò)展（extend）關(guān)系如下圖所示，基礎(chǔ)用例(Base)中定義有一至多個(gè)已命名的擴(kuò)展點(diǎn)，擴(kuò)展關(guān)系是指將擴(kuò)展用例(Extension)的事件流在一定的條件下按照相應(yīng)的擴(kuò)展點(diǎn)插入到基礎(chǔ)用例(Base)中。對(duì)于包含關(guān)系而言，子用例中

33、的事件流是一定插入到基礎(chǔ)用例中去的，并且插入點(diǎn)只有一個(gè)。而擴(kuò)展關(guān)系可以根據(jù)一定的條件來(lái)決定是否將擴(kuò)展用例的事件流插入基礎(chǔ)用例事件流，并且插入點(diǎn)可以有多個(gè)。例如對(duì)于電話業(yè)務(wù)，可以在基本通話(Call)業(yè)務(wù)上擴(kuò)展出一些增值業(yè)務(wù)如：呼叫等待(Call Waiting)和呼叫轉(zhuǎn)移(Call Transfer)。我們可以用擴(kuò)展關(guān)系將這些業(yè)務(wù)的用例模型描述如下。在這個(gè)例子中，呼叫等待和呼叫轉(zhuǎn)移都是對(duì)基本通話用例的擴(kuò)展，但是這兩個(gè)用例只有在一定的條件下（如應(yīng)答方正忙或應(yīng)答方無(wú)應(yīng)答）才會(huì)將被擴(kuò)展用例的事件流嵌入基本通話用例的擴(kuò)展點(diǎn)，并重用基本通話用例中的事件流。值得注意的是擴(kuò)展用例的事件流往往可以也可抽象為基

34、礎(chǔ)用例的備選流，如上例中的呼叫等待和呼叫轉(zhuǎn)移都可以作為基本通話用例的備選流而存在。但是基本通話用例已經(jīng)是一個(gè)很復(fù)雜的用例了，選用擴(kuò)展關(guān)系將增值業(yè)務(wù)抽象成為單獨(dú)的用例可以避免基礎(chǔ)用例過(guò)于復(fù)雜，并且把一些可選的操作獨(dú)立封裝在另外的用例中。 泛化(generalization)當(dāng)多個(gè)用例共同擁有一種類(lèi)似的結(jié)構(gòu)和行為的時(shí)候，我們可以將它們的共性抽象成為父用例，其他的用例作為泛化關(guān)系中的子用例。在用例的泛化關(guān)系中，子用例是父用例的一種特殊形式，子用例繼承了父用例所有的結(jié)構(gòu)、行為和關(guān)系。在實(shí)際應(yīng)用中很少使用泛化關(guān)系，子用例中的特殊行為都可以作為父用例中的備選流存在。以下是一個(gè)用例泛化關(guān)系的例子，執(zhí)行交易是

35、一種交易抽象，執(zhí)行房產(chǎn)交易和執(zhí)行證券交易都是一種特殊的交易形式。用例泛化關(guān)系中的事件流示例如下：4.3 調(diào)整用例模型用例模型建成之后，我們可以對(duì)用例模型進(jìn)行檢視，看是否可以進(jìn)一步簡(jiǎn)化用例模型、提高重用程度、增加模型的可維護(hù)性。主要可以從以下檢查點(diǎn)(checkpoints)入手:· 用例之間是否相互獨(dú)立？如果兩個(gè)用例總是以同樣的順序被激活，可能需要將它們合并為一個(gè)用例。 · 多個(gè)用例之間是否有非常相似的行為或事件流？如果有，可以考慮將它們合并為一個(gè)用例。 · 用例事件流的一部分是否已被構(gòu)建為另一個(gè)用例？如果是，可以讓該用例包含(include)另一用例。 ·

36、; 是否應(yīng)該將一個(gè)用例的事件流插入另一個(gè)用例的事件流中？如果是，利用與另一個(gè)用例的擴(kuò)展關(guān)系(extend)來(lái)建立此模型。 5. 管理用例模型復(fù)雜度一般小型的系統(tǒng)，其用例模型中包含的參與者和用例不會(huì)太多，一個(gè)用例圖就可以容納所有的參與者，所有的參與者和用例也可以并存于同一個(gè)層次結(jié)構(gòu)中。對(duì)于較復(fù)雜的大中型系統(tǒng)，用例模型中的參與者和用例會(huì)大大增加，我們需要一些方法來(lái)有效地管理由于規(guī)模上升而造成的復(fù)雜度。5.1 用例包包(Package)是UML中最常用的管理模型復(fù)雜度的機(jī)制，包也是UML中語(yǔ)義最簡(jiǎn)單的一種模型元素，它就是一種容器，在包中可以容納其他任意的模型元素（包括其他的包）。在用例模型中，我們可

37、以用構(gòu)造型(Stereotype)<<use case>>來(lái)擴(kuò)展標(biāo)準(zhǔn)UML包的語(yǔ)義，這種新的包叫做用例包(Use Case Package)，用于分類(lèi)管理用例模型中的模型元素。我們可以根據(jù)參與者和用例的特性來(lái)對(duì)它們進(jìn)行分類(lèi)，分別置于不同的用例包管理之下。例如對(duì)于一個(gè)大型的企業(yè)管理信息系統(tǒng)，我們可以根據(jù)參與者和用例的內(nèi)容將它們分別歸于人力資源、財(cái)務(wù)、采購(gòu)、銷(xiāo)售、客戶服務(wù)這些用例包之下。這樣我們將整個(gè)用例模型劃分成為兩個(gè)層次，在第一層次我們看到的是系統(tǒng)功能總共分為五部分，在第二層次我們可以分別看到每一用例包內(nèi)部的參與者和用例。一個(gè)用例模型需要有多少個(gè)用例包取決你想怎么樣來(lái)管

38、理用例模型的復(fù)雜度（包括參與者和用例的個(gè)數(shù)，以及它們之間的相互關(guān)系）。UML中的包其實(shí)就類(lèi)似于文件系統(tǒng)中的目錄，文件數(shù)量少的時(shí)候不需要額外的目錄，文件數(shù)量一多就需要有多個(gè)目錄來(lái)分類(lèi)管理，同樣一組文件不同的人會(huì)創(chuàng)建不同的目錄結(jié)構(gòu)來(lái)進(jìn)行管理，關(guān)鍵是要保證在目錄結(jié)構(gòu)下每一個(gè)文件都要易于訪問(wèn)。同樣的道理存在于用例建模之中，如何創(chuàng)建用例包以及用例包的個(gè)數(shù)取決于不同的系統(tǒng)和系統(tǒng)分析員，但要保證整個(gè)用例模型易于理解。5.2 用例的粒度我的系統(tǒng)需要有多少個(gè)用例？這是很多人在用例建模時(shí)會(huì)產(chǎn)生的疑惑。描述同一個(gè)系統(tǒng)，不同的人會(huì)產(chǎn)生不同的用例模型。例如對(duì)于各種系統(tǒng)中常見(jiàn)的"維護(hù)用戶"用例，它里面包含了添