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

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

2、用例從用戶的角度來看，他們并不想了解系統(tǒng)的內(nèi)部結(jié)構(gòu)和設(shè)計(jì)，他們所關(guān)心的是系統(tǒng)所能提供的服務(wù)，也就是被開發(fā)出來的系統(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ā)生的一段對話。 通訊關(guān)聯(lián)(Communication Association) 通訊關(guān)聯(lián)用于表示參與者和用例之間的對應(yīng)關(guān)系，它表示

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

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

5、效、輸入密碼錯(cuò)、用戶賬號中的現(xiàn)金余額不夠等，所有這些可能發(fā)生的各種情況（包括正常的和異常的）被稱之為用例的場景(Scenario)，場景也被稱作是用例的實(shí)例(Instance)。在用例的各種場景中，最常見的場景是用基本流(Basic Flow)來描述的，其他的場景則是用備選流(Alternative Flow)來描述。對于ATM系統(tǒng)中的提款用例，我們可以得到如下一些備選流：提款-備選事件流備選流一：用戶可以在基本流中的任何一步選擇退出，轉(zhuǎn)至基本流步驟5。備選流二：在基本流步驟1中，用戶插入無效信用卡，系統(tǒng)顯示錯(cuò)誤并退出信用卡，用例結(jié)束。備選流三：在基本流步驟中，用戶輸入錯(cuò)誤密碼，系統(tǒng)顯示錯(cuò)誤并

6、提示用戶重新輸入密碼，重新回到基本流步驟2；三次輸入密碼錯(cuò)誤后，信用卡被系統(tǒng)沒收，用例結(jié)束。通過基本流與備選流的組合，就可以將用例所有可能發(fā)生的各種場景全部描述清楚。我們在描述用例的事件流的時(shí)候，就是要盡可能地將所有可能的場景都描述出來，以保證需求的完備性。1.3 用例方法的優(yōu)點(diǎn)用例方法完全是站在用戶的角度上（從系統(tǒng)的外部）來描述系統(tǒng)的功能的。在用例方法中，我們把被定義系統(tǒng)看作是一個(gè)黑箱，我們并不關(guān)心系統(tǒng)內(nèi)部是如何完成它所提供的功能的。用例方法首先描述了被定義系統(tǒng)有哪些外部使用者（抽象成為Actor），這些使用者與被定義系統(tǒng)發(fā)生交互；針對每一參與者，用例方法又描述了系統(tǒng)為這些參與者提供了什么樣

7、的服務(wù)（抽象成為Use Case），或者說系統(tǒng)是如何被這些參與者使用的。所以從用例圖中，我們可以得到對于被定義系統(tǒng)的一個(gè)總體印象。與傳統(tǒng)的功能分解方式相比，用例方法完全是從外部來定義系統(tǒng)的功能，它把需求與設(shè)計(jì)完全分離開來。在面向?qū)ο蟮姆治鲈O(shè)計(jì)方法中，用例模型主要用于表述系統(tǒng)的功能性需求，系統(tǒng)的設(shè)計(jì)主要由對象模型來記錄表述。另外，用例定義了系統(tǒng)功能的使用環(huán)境與上下文，每一個(gè)用例描述的是一個(gè)完整的系統(tǒng)服務(wù)。用例方法比傳統(tǒng)的SRS更易于被用戶所理解，它可以作為開發(fā)人員和用戶之間針對系統(tǒng)需求進(jìn)行溝通的一個(gè)有效手段。在RUP中，用例被作為整個(gè)軟件開發(fā)流程的基礎(chǔ)，很多類型的開發(fā)活動(dòng)都把用例作為一個(gè)主要的輸

8、入工件(Artifact)，如項(xiàng)目管理、分析設(shè)計(jì)、測試等。根據(jù)用例來對目標(biāo)系統(tǒng)進(jìn)行測試，可以根據(jù)用例中所描述的環(huán)境和上下文來完整地測試一個(gè)系統(tǒng)服務(wù)，可以根據(jù)用例的各個(gè)場景(Scenario)來設(shè)計(jì)測試用例，完全地測試用例的各種場景可以保證測試的完備性。2. 建立用例模型使用用例的方法來描述系統(tǒng)的功能需求的過程就是用例建模，用例模型主要包括以下兩部分內(nèi)容： 用例圖(Use Case Diagram) 確定系統(tǒng)中所包含的參與者、用例和兩者之間的對應(yīng)關(guān)系，用例圖描述的是關(guān)于系統(tǒng)功能的一個(gè)概述。 用例規(guī)約(Use Case Specification) 針對每一個(gè)用例都應(yīng)該有一個(gè)用例規(guī)約文檔與之相對應(yīng)

9、，該文檔描述用例的細(xì)節(jié)內(nèi)容。 在用例建模的過程中，我們建議的步聚是先找出參與者，再根據(jù)參與者確定每個(gè)參與者相關(guān)的用例，最后再細(xì)化每一個(gè)用例的用例規(guī)約。2.1 尋找參與者所謂的參與者是指所有存在于系統(tǒng)外部并與系統(tǒng)進(jìn)行交互的人或其他系統(tǒng)。通俗地講，參與者就是我們所要定義系統(tǒng)的使用者。尋找參與者可以從以下問題入手： 系統(tǒng)開發(fā)完成之后，有哪些人會使用這個(gè)系統(tǒng)？ 系統(tǒng)需要從哪些人或其他系統(tǒng)中獲得數(shù)據(jù)？ 系統(tǒng)會為哪些人或其他系統(tǒng)提供數(shù)據(jù)？ 系統(tǒng)會與哪些其他系統(tǒng)相關(guān)聯(lián)？ 系統(tǒng)是由誰來維護(hù)和管理的？ 這些問題有助于我們抽象出系統(tǒng)的參與者。對于ATM機(jī)的例子，回答這些問題可以使我們找到更多的參與者：操作員負(fù)責(zé)維

10、護(hù)和管理ATM機(jī)系統(tǒng)、ATM機(jī)也需要與后臺服務(wù)器進(jìn)行通訊以獲得有關(guān)用戶賬號的相關(guān)信息。2.1.1 系統(tǒng)邊界決定了參與者 參與者是由系統(tǒng)的邊界所決定的，如果我們所要定義的系統(tǒng)邊界僅限于ATM機(jī)本身，那么后臺服務(wù)器就是一個(gè)外部的系統(tǒng)，可以抽象為一個(gè)參與者。如果我們所要定義的系統(tǒng)邊界擴(kuò)大至整個(gè)銀行系統(tǒng)，ATM機(jī)和后臺服務(wù)器都是整個(gè)銀行系統(tǒng)的一部分，這時(shí)候后臺服務(wù)器就不再被抽象成為一個(gè)參與者。值得注意的是，用例建模時(shí)不要將一些系統(tǒng)的組成結(jié)構(gòu)作為參與者來進(jìn)行抽象，如在ATM機(jī)系統(tǒng)中，打印機(jī)只是系統(tǒng)的一個(gè)組成部分，不應(yīng)將它抽象成一個(gè)獨(dú)立的參與者；在一個(gè)MIS管理系統(tǒng)中，數(shù)據(jù)庫系統(tǒng)往往只作為系統(tǒng)的一個(gè)組成部

11、分，一般不將其單獨(dú)抽象成一個(gè)參與者。2.1.2 特殊的參與者系統(tǒng)時(shí)鐘 有時(shí)候我們需要在系統(tǒng)內(nèi)部定時(shí)地執(zhí)行一些操作，如檢測系統(tǒng)資源使用情況、定期地生成統(tǒng)計(jì)報(bào)表等等。從表面上看，這些操作并不是由外部的人或系統(tǒng)觸發(fā)的，應(yīng)該怎樣用用例方法來表述這一類功能需求呢？對于這種情況，我們可以抽象出一個(gè)系統(tǒng)時(shí)鐘或定時(shí)器參與者，利用該參與者來觸發(fā)這一類定時(shí)操作。從邏輯上，這一參與者應(yīng)該被理解成是系統(tǒng)外部的，由它來觸發(fā)系統(tǒng)所提供的用例對話。2.2 確定用例找到參與者之后，我們就可以根據(jù)參與者來確定系統(tǒng)的用例，主要是看各參與者需要系統(tǒng)提供什么樣的服務(wù)，或者說參與者是如何使用系統(tǒng)的。尋找用例可以從以下問題入手（針對每一

12、個(gè)參與者）： 參與者為什么要使用該系統(tǒng)？ 參與者是否會在系統(tǒng)中創(chuàng)建、修改、刪除、訪問、存儲數(shù)據(jù)？如果是的話，參與者又是如何來完成這些操作的？ 參與者是否會將外部的某些事件通知給該系統(tǒng)？ 系統(tǒng)是否會將內(nèi)部的某些事件通知該參與者？ 綜合以上所述，ATM系統(tǒng)的用例圖可表示如下，在用例的抽取過程中，必須注意：用例必須是由某一個(gè)主角觸發(fā)而產(chǎn)生的活動(dòng)，即每個(gè)用例至少應(yīng)該涉及一個(gè)主角。如果存在與主角不進(jìn)行交互的用例，就可以考慮將其并入其他用例；或者是檢查該用例相對應(yīng)的參與者是否被遺漏，如果是，則補(bǔ)上該參與者。反之，每個(gè)參與者也必須至少涉及到一個(gè)用例，如果發(fā)現(xiàn)有不與任何用例相關(guān)聯(lián)的參與者存在，就應(yīng)該考慮該參與

13、者是如何與系統(tǒng)發(fā)生對話的，或者由參與者確定一個(gè)新的用例，或者該參與者是一個(gè)多余的模型元素，應(yīng)該將其刪除。可視化建模的主要目的之一就是要增強(qiáng)團(tuán)隊(duì)的溝通，用例模型必須是易于理解的。用例建模往往是一個(gè)團(tuán)隊(duì)開發(fā)的過程，系統(tǒng)分析員在建模過程中必須注意參與者和用例的名稱應(yīng)該符合一定的命名約定，這樣整個(gè)用例模型才能夠符合一定的風(fēng)格。如參與者的名稱一般都是名詞，用例名稱一般都是動(dòng)賓詞組等。對于同一個(gè)系統(tǒng)，不同的人對于參與者和用例都可能有不同的抽象結(jié)果，因而得到不同的用例模型。我們需要在多個(gè)用例模型方案中選擇一種最佳（或較佳）的結(jié)果，一個(gè)好的用例模型應(yīng)該能夠容易被不同的涉眾所理解，并且不同的涉眾對于同一用例模型

14、的理解應(yīng)該是一致的。2.3 描述用例規(guī)約應(yīng)該避免這樣一種誤解認(rèn)為由參與者和用例構(gòu)成的用例圖就是用例模型，用例圖只是在總體上大致描述了系統(tǒng)所能提供的各種服務(wù)，讓我們對于系統(tǒng)的功能有一個(gè)總體的認(rèn)識。除此之外，我們還需要描述每一個(gè)用例的詳細(xì)信息，這些信息包含在用例規(guī)約中，用例模型是由用例圖和每一個(gè)用例的詳細(xì)描述用例規(guī)約所組成的。RUP中提供了用例規(guī)約的模板，每一個(gè)用例的用例規(guī)約都應(yīng)該包含以下內(nèi)容： 簡要說明 (Brief Description) 簡要介紹該用例的作用和目的。 事件流 (Flow of Event) 包括基本流和備選流，事件流應(yīng)該表示出所有的場景。 用例場景 (Use-Case Sc

15、enario) 包括成功場景和失敗場景，場景主要是由基本流和備選流組合而成的。 特殊需求 (Special Requirement) 描述與該用例相關(guān)的非功能性需求（包括性能、可靠性、可用性和可擴(kuò)展性等）和設(shè)計(jì)約束（所使用的操作系統(tǒng)、開發(fā)工具等）。 前置條件 (Pre-Condition) 執(zhí)行用例之前系統(tǒng)必須所處的狀態(tài)。 后置條件 (Post-Condition) 用例執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)。 用例規(guī)約基本上是用文本方式來表述的，為了更加清晰地描述事件流，也可以選擇使用狀態(tài)圖、活動(dòng)圖或序列圖來輔助說明。只要有助于表達(dá)的簡潔明了，就可以在用例中任意粘貼用戶界面和流程的圖形化顯示方式，

16、或是其他圖形。如活動(dòng)圖有助于描述復(fù)雜的決策流程，狀態(tài)轉(zhuǎn)移圖有助于描述與狀態(tài)相關(guān)的系統(tǒng)行為，序列圖適合于描述基于時(shí)間順序的消息傳遞。2.3.1 基本流 基本流描述的是該用例最正常的一種場景，在基本流中系統(tǒng)執(zhí)行一系列活動(dòng)步驟來響應(yīng)參與者提出的服務(wù)請求。我們建議用以下格式來描述基本流：1) 每一個(gè)步驟都需要用數(shù)字編號以清楚地標(biāo)明步驟的先后順序。2) 用一句簡短的標(biāo)題來概括每一步驟的主要內(nèi)容，這樣閱讀者可以通過瀏覽標(biāo)題來快速地了解用例的主要步驟。在用例建模的早期，我們也只需要描述到事件流步驟標(biāo)題這一層，以免過早地陷入到用例描述的細(xì)節(jié)中去。3) 當(dāng)整個(gè)用例模型基本穩(wěn)定之后，我們再針對每一步驟詳細(xì)描述參與

17、者和系統(tǒng)之間所發(fā)生的交互。建議采用雙向(roundtrip)描述法來保證描述的完整性，即每一步驟都需要從正反兩個(gè)方面來描述:(1)參與者向系統(tǒng)提交了什么信息；(2)對此系統(tǒng)有什么樣的響應(yīng)。具體例子請參見附錄。在描述參與者和系統(tǒng)之間的信息交換時(shí)，需指出來回傳遞的具體信息。例如，只表述參與者輸入了客戶信息就不夠明確，最好明確地說參與者輸入了客戶姓名和地址。通常可以利用詞匯表讓用例的復(fù)雜性保持在可控范圍內(nèi)，可以在詞匯表中定義客戶信息等內(nèi)容，使用例不至于陷入過多的細(xì)節(jié)。2.3.2 備選流 備選流負(fù)責(zé)描述用例執(zhí)行過程中異常的或偶爾發(fā)生的一些情況，備選流和基本流的組合應(yīng)該能夠覆蓋該用例所有可能發(fā)生的場景。

18、在描述備選流時(shí)，應(yīng)該包括以下幾個(gè)要素：1) 起點(diǎn)：該備選流從事件流的哪一步開始；2) 條件：在什么條件下會觸發(fā)該備選流；3) 動(dòng)作：系統(tǒng)在該備選流下會采取哪些動(dòng)作；4) 恢復(fù)：該備選流結(jié)束之后，該用例應(yīng)如何繼續(xù)執(zhí)行。備選流的描述格式可以與基本流的格式一致，也需要編號并以標(biāo)題概述其內(nèi)容，編號前可以加以字母前綴A(Alternative)以示與基本流步驟相區(qū)別。2.3.3 用例場景 用例在實(shí)際執(zhí)行的時(shí)候會有很多的不同情況發(fā)生，稱之為用例場景；也可以說場景是用例的實(shí)例，我們在描述用例的時(shí)候要覆蓋所有的用例場景，否則就有可能導(dǎo)致需求的遺漏。在用例規(guī)約中，場景的描述可以由基本流和備選流的組合來表示。場景

19、既可以幫助我們防止需求的遺漏，同時(shí)也可以對后續(xù)的開發(fā)工作起到很大的幫助：開發(fā)人員必須實(shí)現(xiàn)所有的場景、測試人員可以根據(jù)用例場景來設(shè)計(jì)測試用例。2.3.4 特殊需求 特殊需求通常是非功能性需求，它為一個(gè)用例所專有，但不適合在用例的事件流文本中進(jìn)行說明。特殊需求的例子包括法律或法規(guī)方面的需求、應(yīng)用程序標(biāo)準(zhǔn)和所構(gòu)建系統(tǒng)的質(zhì)量屬性（包括可用性、可靠性、性能或支持性需求等）。此外，其他一些設(shè)計(jì)約束，如操作系統(tǒng)及環(huán)境、兼容性需求等，也可以在此節(jié)中記錄。需要注意的是，這里記錄的是專屬于該用例的特殊需求；對于一些全局的非功能性需求和設(shè)計(jì)約束，它們并不是該用例所專有的，應(yīng)把它們記錄在補(bǔ)充規(guī)約中。2.3.5 前置和

20、后置條件 前置條件是執(zhí)行用例之前必須存在的系統(tǒng)狀態(tài)，后置條件是用例執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)。2.4 檢查用例模型用例模型完成之后，可以對用例模型進(jìn)行檢查，看看是否有遺漏或錯(cuò)誤之處。主要可以從以下幾個(gè)方面來進(jìn)行檢查： 功能需求的完備性 現(xiàn)有的用例模型是否完整地描述了系統(tǒng)功能，這也是我們判斷用例建模工作是否結(jié)束的標(biāo)志。如果發(fā)現(xiàn)還有系統(tǒng)功能沒有被記錄在現(xiàn)有的用例模型中，那么我們就需要抽象一些新的用例來記錄這些需求，或是將他們歸納在一些現(xiàn)有的用例之中。 模型是否易于理解 用例模型最大的優(yōu)點(diǎn)就在于它應(yīng)該易于被不同的涉眾所理解，因而用例建模最主要的指導(dǎo)原則就是它的可理解性。用例的粒度、個(gè)數(shù)以及模型

21、元素之間的關(guān)系復(fù)雜程度都應(yīng)該由該指導(dǎo)原則決定。 是否存在不一致性 系統(tǒng)的用例模型是由多個(gè)系統(tǒng)分析員協(xié)同完成的，模型本身也是由多個(gè)工件所組成的，所以我們要特別注意不同工件之前是否存在前后矛盾或沖突的地方，避免在模型內(nèi)部產(chǎn)生不一致性。不一致性會直接影響到需求定義的準(zhǔn)確性。 避免二義性語義 好的需求定義應(yīng)該是無二義性的，即不同的人對于同一需求的理解應(yīng)該是一致的。在用例規(guī)約的描述中，應(yīng)該避免定義含義模糊的需求，即無二義性。 3. 系統(tǒng)需求RUP中根據(jù)FURPS+模型將系統(tǒng)需求分為以下幾類： 功能(Functionality) 可用性(Usability) 可靠性(Reliability) 性能(Per

22、formance) 可支持性(Supportability) 設(shè)計(jì)約束等 除了第一項(xiàng)功能性需求之外的其他需求都?xì)w之為非功能性需求。3.1 需求工件集用例模型主要用于描述系統(tǒng)的功能性需求，對于其他的非功能性需要用其他文檔來記錄。RUP中定義了如下的需求工件集合。 用例模型：記錄功能性需求 o 用例圖：描述參與者和用例之間的關(guān)系 o 用例規(guī)約：描述每一個(gè)用例的細(xì)節(jié)信息 補(bǔ)充規(guī)約：記錄一些全局性的功能需求、非功能性需求和設(shè)計(jì)約束等 詞匯表：記錄一些系統(tǒng)需求相關(guān)的術(shù)語 在實(shí)際應(yīng)用中，除了這些工件之外，我們還可以根據(jù)實(shí)際需求靈活選用其他形式的文檔來補(bǔ)充說明需求。并不是所有的系統(tǒng)需求都適合用用例模型來描述

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

24、、I18N支持等，我們不需要在所有的用例中描述這些功能性需求，只需要在補(bǔ)充規(guī)約中統(tǒng)一描述就可以了。 可用性 記錄所有可用性相關(guān)的需求，如系統(tǒng)的使用者所需要的培訓(xùn)時(shí)間、是否應(yīng)符合一些常見的可用性標(biāo)準(zhǔn)如Windows界面風(fēng)格等。 可靠性 定義系統(tǒng)可靠性相關(guān)的各種指標(biāo)，包括： o 可用性：指出可用時(shí)間百分比(xx.xx%)，系統(tǒng)處于使用、維護(hù)、降級模式等操作的小時(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)）；

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

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

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

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

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

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

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

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

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

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

35、nd)來建立此模型。 5. 管理用例模型復(fù)雜度一般小型的系統(tǒng)，其用例模型中包含的參與者和用例不會太多，一個(gè)用例圖就可以容納所有的參與者，所有的參與者和用例也可以并存于同一個(gè)層次結(jié)構(gòu)中。對于較復(fù)雜的大中型系統(tǒng)，用例模型中的參與者和用例會大大增加，我們需要一些方法來有效地管理由于規(guī)模上升而造成的復(fù)雜度。5.1 用例包包(Package)是UML中最常用的管理模型復(fù)雜度的機(jī)制，包也是UML中語義最簡單的一種模型元素，它就是一種容器，在包中可以容納其他任意的模型元素（包括其他的包）。在用例模型中，我們可以用構(gòu)造型(Stereotype)來擴(kuò)展標(biāo)準(zhǔn)UML包的語義，這種新的包叫做用例包(Use Case

36、Package)，用于分類管理用例模型中的模型元素。我們可以根據(jù)參與者和用例的特性來對它們進(jìn)行分類，分別置于不同的用例包管理之下。例如對于一個(gè)大型的企業(yè)管理信息系統(tǒng)，我們可以根據(jù)參與者和用例的內(nèi)容將它們分別歸于人力資源、財(cái)務(wù)、采購、銷售、客戶服務(wù)這些用例包之下。這樣我們將整個(gè)用例模型劃分成為兩個(gè)層次，在第一層次我們看到的是系統(tǒng)功能總共分為五部分，在第二層次我們可以分別看到每一用例包內(nèi)部的參與者和用例。一個(gè)用例模型需要有多少個(gè)用例包取決你想怎么樣來管理用例模型的復(fù)雜度（包括參與者和用例的個(gè)數(shù)，以及它們之間的相互關(guān)系）。UML中的包其實(shí)就類似于文件系統(tǒng)中的目錄，文件數(shù)量少的時(shí)候不需要額外的目錄，文件數(shù)量一多就需要有多個(gè)目錄來分類管理，同樣一組文件不同的人會創(chuàng)建不同的目錄結(jié)構(gòu)來進(jìn)行管理，關(guān)鍵是要保證在目錄結(jié)構(gòu)下每一個(gè)文件都要易于訪問。同樣的道理存在于用例建模之中，如何創(chuàng)建用例包以及用例包的個(gè)數(shù)取決于不同的系統(tǒng)和系統(tǒng)分析員，但要保證整個(gè)用例模型易于理解。5.2 用例的粒度我的系統(tǒng)需要有多少個(gè)用例？這是很多人在用例建模時(shí)會產(chǎn)生的疑惑。描述同一個(gè)系統(tǒng)，不同的人會產(chǎn)生不同的用例模型。例如對于各種系統(tǒng)中常見的維護(hù)用戶用例，它里面包含了添加用戶、修改用戶信息、刪