第6章組織系統(tǒng)需求：用例描述和圖.ppt

1、第6章 組織系統(tǒng)需求：用例描述和圖,使用“用例”來(lái)表達(dá)系統(tǒng)的功能,需求的分類,功能性需求：系統(tǒng)應(yīng)當(dāng)具備的功能，即系統(tǒng)必須能夠做什么、完成哪些工作。 非功能性需求：系統(tǒng)精確度、性能、效率、成本、可維護(hù)性、安全性等系統(tǒng)行為之外的系統(tǒng)質(zhì)量需求。 用例建模：捕獲系統(tǒng)的功能性需求，幫助人們理解系統(tǒng)需求，而無(wú)需關(guān)注系統(tǒng)如何實(shí)現(xiàn),本章內(nèi)容,分辨信息系統(tǒng)的邊界 什么是用例 用例的概念、目的 識(shí)別參與者 識(shí)別用例 繪制用例圖 如何描述用例 用例分解，確定用例關(guān)系,6.1.1 用例的概念,用例創(chuàng)始人雅各布森Ivar Jacobson認(rèn)為： 用例（use case）是對(duì)于一組動(dòng)作序列的描述，系統(tǒng)執(zhí)行這些動(dòng)作會(huì)對(duì)特定

2、的參與者（actor）產(chǎn)生可觀測(cè)的、有價(jià)值的結(jié)果。 阿里斯代爾科克伯恩Alistair Cockburn： 強(qiáng)調(diào)用例是各種系統(tǒng)受益人（stakeholder）之間的一種行為契約（contract）。行為包括對(duì)象的活動(dòng)、動(dòng)作和對(duì)象之間的交互等。建立契約的目的是為了達(dá)成某種目標(biāo)，因此每一個(gè)用例實(shí)際上都應(yīng)代表一個(gè)用戶目標(biāo)，根據(jù)三個(gè)目標(biāo)層次（概要層、用戶目標(biāo)層、子功能層）將用例進(jìn)行分層，從而有效把握用例的粒度。,Use Case的定義,在一個(gè)workshop(專題討論會(huì))上，14位主要的OO專家對(duì)Use Case有14個(gè)定義。 定義1：use case是對(duì)一個(gè)活動(dòng)者(actor)使用系統(tǒng)的一項(xiàng)功能時(shí)所

3、進(jìn)行的交互過(guò)程的一個(gè)文字描述序列 (見2)。 定義2：The specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem, or class can perform by interacting with outside actors. (見3) 2 邵維忠，楊芙清，面向?qū)ο蟮南到y(tǒng)分析，p153 3 J. Rumbaugh, etc. The Unified Modeling Language Reference Manual,

4、p488,用例的意義,用例是對(duì)系統(tǒng)需求（主要是功能需求）的規(guī)范化的描述。 用例圖及用例的事件流描述集中體現(xiàn)了系統(tǒng)責(zé)任， 通過(guò)用例建立交互圖。交互圖就是用例的具體實(shí)現(xiàn)，即系統(tǒng)中的對(duì)象以及對(duì)象間協(xié)作是如何完成一個(gè)用例的全部過(guò)程。 用例驅(qū)動(dòng)的開發(fā)過(guò)程，從用例模型到分析模型和設(shè)計(jì)模型之間有一致性和可追蹤性。,用例是代表系統(tǒng)中各個(gè)相關(guān)人員之間就系統(tǒng)的行為所達(dá)成的契約。 例：在線銀行系統(tǒng)的一些可能的用例： 瀏覽帳戶余額 列出交易內(nèi)容 劃撥資金 支付帳款 登錄 退出系統(tǒng) 編輯配置文件 買進(jìn)證券 賣出證券,Use Case 驅(qū)動(dòng),use case對(duì)軟件開發(fā)的意義,use case說(shuō)明： Use case從使用

5、系統(tǒng)的角度描述系統(tǒng)中的信息，即站在系統(tǒng)外部察看系統(tǒng)功能，并不考慮系統(tǒng)內(nèi)部對(duì)該功能的具體實(shí)現(xiàn)方式。 使用use case可以促進(jìn)與用戶溝通，理解正確的需求，同時(shí)也可以用來(lái)劃分系統(tǒng)與外部實(shí)體的界限，是OO系統(tǒng)設(shè)計(jì)的起點(diǎn)，是類、對(duì)象、操作的來(lái)源。,用例的一些特點(diǎn)： （1）用例描述了用戶提出的一些可見的需求； （2）用例可大可??； （3）用例對(duì)應(yīng)一個(gè)具體的用戶目標(biāo)。 理論上我們可以把一個(gè)軟件系統(tǒng)的所有Use Case畫出來(lái)，但實(shí)際運(yùn)用時(shí)只需把重要的、交互過(guò)程復(fù)雜的那些畫出來(lái)。 需求有兩種基本形式：功能性和非功能性的。不是所有的需求都要用use case表示出來(lái)。 問(wèn)題：一個(gè)系統(tǒng)的需求包括哪些內(nèi)容？ 可

6、以參照需求大綱,用例建模的內(nèi)容,基于用例的需求獲取過(guò)程： 1. 獲取原始需求 2. 開發(fā)一個(gè)可以理解的需求 識(shí)別參與者 識(shí)別用例 構(gòu)建用例圖 3 詳細(xì)、完整地描述需求 書寫用例規(guī)格說(shuō)明 4 重構(gòu)用例模型 識(shí)別用例間的關(guān)系 對(duì)用例進(jìn)行組織和分包,1、識(shí)別參與者,參與者是系統(tǒng)之外與系統(tǒng)進(jìn)行交互的任何事物。 使用系統(tǒng)的個(gè)人 誰(shuí)負(fù)責(zé)提供、使用或刪除信息？ 誰(shuí)將使用某項(xiàng)功能？ 系統(tǒng)所連接的外部硬件。 例如，控制建筑物中溫度的通風(fēng)系統(tǒng)不斷地從傳感器獲取溫度信息，傳感器就是一個(gè)參與者。 與該系統(tǒng)進(jìn)行通信的其他信息系統(tǒng)。 例如為自動(dòng)柜員機(jī)系統(tǒng)建模時(shí)，中央銀行系統(tǒng)就是它的一個(gè)參與者。信用卡系統(tǒng)是銷售系統(tǒng)中的一個(gè)

7、參與者,區(qū)分參與者和外部實(shí)體,只有在執(zhí)行系統(tǒng)功能時(shí)與信息系統(tǒng)進(jìn)行實(shí)時(shí)交互的人員才能被當(dāng)作參與者 新生入學(xué)手工填寫個(gè)人信息，然后由教務(wù)人員統(tǒng)一將數(shù)據(jù)登記到學(xué)籍系統(tǒng)中，教務(wù)人員是參與者。 如果學(xué)生直接通過(guò)Web方式提交個(gè)人信息，則認(rèn)為學(xué)生是參與者。,區(qū)分主要參與者和次要參與者,主要參與者（primary actor）是從系統(tǒng)中直接獲得可度量?jī)r(jià)值的用戶。 次要參與者（secondary actor）的需求驅(qū)動(dòng)了用例所表示的行為或功能，在用例中起輔助支持作用 用例分析的重點(diǎn)是要找到主要參與者。 比如，在圖書館的借/還書用例中，首先要考慮誰(shuí)直接使用這一功能，誰(shuí)頻繁地和系統(tǒng)進(jìn)行交互？圖書管理人員是直接操作

8、者，他們的需求和變化對(duì)于用例的影響最大。因此，圖書管理員是主要參與者。,通過(guò)事件表獲得參與者：,參與者可以從“源”得到啟發(fā)，但“源” 表示數(shù)據(jù)最初的提供者，不一定對(duì)應(yīng)功能的執(zhí)行者。,參與者舉例,參與者的表示,在UML中，參與者使用小人符號(hào)：,圖書館 系統(tǒng),讀者,圖書管理員,RSA中的 建模符號(hào),參與者的泛化,在某些情況下，參與者的角色可以有共性，或者說(shuō)一般性，一種角色可以擁有另一種角色的全部行為。 比如在超市系統(tǒng)中，值班經(jīng)理完全可以充當(dāng)收銀員這一角色，此外，值班經(jīng)理還可以有退貨、更改事務(wù)等權(quán)利。,2、識(shí)別用例,用例就是功能性需求。 每個(gè)用例至少和一個(gè)參與者相關(guān)，用例名稱要體現(xiàn)參與者希望系統(tǒng)提供

9、的功能。,用例的UML圖形表示,購(gòu)買商品,Rose中的符號(hào),購(gòu)買商品,區(qū)分用例和用例完成的步驟,不能混淆用例和用例所包含的步驟。 比如“借出圖書”功能要經(jīng)過(guò)驗(yàn)證讀者信息、檢查超出可借數(shù)量、保存借書記錄、修改圖書狀態(tài)等步驟 在系統(tǒng)中這些步驟通常不作為單獨(dú)的功能提供給參與者使用，它們只是一個(gè)用例所包含的事件流，或者是用例的子功能。 與結(jié)構(gòu)化分析中提到的事件概念相同。,區(qū)分業(yè)務(wù)用例和系統(tǒng)用例,當(dāng)針對(duì)整個(gè)業(yè)務(wù)領(lǐng)域建模時(shí)，需要使用業(yè)務(wù)用例 比如圖書館系統(tǒng)有一項(xiàng)重要工作就是“整理書架”，圖書都要放回到固定的位置上 信息系統(tǒng)作為整個(gè)業(yè)務(wù)系統(tǒng)的一部分，只負(fù)責(zé)實(shí)現(xiàn)系統(tǒng)的部分功能，即有信息處理的那部分功能。,客戶

10、提出申請(qǐng)要求貸款，申請(qǐng)中包括期限、金額、用途和本人基本情況。銀行收到申請(qǐng)后，置于“申請(qǐng)檔案”中，以申請(qǐng)?zhí)枠?biāo)識(shí)。 某公司內(nèi)部工作崗位的提供：不論何時(shí)，只要一有職位空缺，該地區(qū)的人力資源部領(lǐng)導(dǎo)就會(huì)通知該地區(qū)的所有員工并給其他地區(qū)的HR領(lǐng)導(dǎo)發(fā)送消息，邀請(qǐng)員工們提出申請(qǐng)。然后，其他地區(qū)HR領(lǐng)導(dǎo)將招聘信息貼在公告板上。所有對(duì)此感興趣的員工都可以將申請(qǐng)發(fā)送到職位空缺的地區(qū)的HR領(lǐng)導(dǎo)那里。,用例舉例1,用例舉例2,在門診掛號(hào)處只能掛當(dāng)天的號(hào)，掛出的號(hào)可以退。 病人拿到掛號(hào)單后，到相應(yīng)的科室進(jìn)行就診。醫(yī)生根據(jù)掛號(hào)的順序號(hào)，依次給病人看病開處方。 病人拿處方去收款處交費(fèi)，并拿到發(fā)票。 病人拿已經(jīng)收費(fèi)的處方去藥房

11、拿藥。 該系統(tǒng)潛在的參與者和用例有哪些？,圖書館系統(tǒng)的用例圖,進(jìn)行用例描述時(shí)，往往會(huì)有冗余的情況出現(xiàn)，比如多個(gè)用例會(huì)共享一些子功能。 擴(kuò)展和包含關(guān)系就是用例模型中消除冗余的一種手段。 基本用例是包含常規(guī)會(huì)發(fā)生的最基本功能的用例，它是具有普遍性的，對(duì)于任何執(zhí)行該功能的參與者來(lái)講都是適合的。,6.2 用例關(guān)系,用例關(guān)系,包含關(guān)系：經(jīng)過(guò)封裝后可以在各種不同的基本用例中復(fù)用的行為稱為包含用例。 擴(kuò)展關(guān)系：表達(dá)某些可選或只在特定條件下才執(zhí)行的系統(tǒng)行為的用例，它們是對(duì)基本用例的擴(kuò)展。稱為擴(kuò)展用例。 泛化關(guān)系：如果兩個(gè)或更多用例在行為、結(jié)構(gòu)和目的方面存在共性，可以使用泛化關(guān)系。父用例描述這些共有部分，子用例

12、繼承父用例并特殊化。,基本用例可以控制包含用例，并依賴于（使用）包含用例所得到的結(jié)果。 包含用例是基本用例存在的必要條件 一個(gè)基本用例可以有多個(gè)包含用例，一個(gè)包含用例可以包含在若干基本用例中。包含關(guān)系可以嵌套，但超過(guò)三層的嵌套是難于理解的。,包含關(guān)系,擴(kuò)展用例是可選的，它是否執(zhí)行取決于在執(zhí)行基本用例時(shí)所發(fā)生的事件（存在擴(kuò)展點(diǎn)）。 擴(kuò)展用例的缺失不影響對(duì)基本用例的理解。,擴(kuò)展關(guān)系,用一個(gè)新的、通常也是抽象的用例來(lái)描述多個(gè)用例的共有部分(父用例)，子用例繼承父用例的所有結(jié)構(gòu)、行為和關(guān)系，并含有自己特殊的部分。 父用例通常是抽象的，如果兩個(gè)子用例都對(duì)同一父用例進(jìn)行特殊化，則兩個(gè)子用例是相互獨(dú)立而且完

13、整的，這一點(diǎn)與包含關(guān)系擴(kuò)展關(guān)系不同。,泛化關(guān)系（不推薦）,小結(jié)： actor，use case的關(guān)系(relationship)類型,說(shuō)明：可在use case間建立關(guān)聯(lián)，但意義不是很明確。,用例的粒度,通常用例圖粒度較大 通過(guò)分解和細(xì)化，可以使粒度更小 通過(guò)事件流描述： 尋找用例的共同點(diǎn) 尋找用例的擴(kuò)展點(diǎn) 切忌“畫蛇添足”！,常見問(wèn)題分析,1. Use case的粒度問(wèn)題，即對(duì)于一個(gè)系統(tǒng)的Use Case圖，所包含的用例數(shù)目問(wèn)題。 這是很多人爭(zhēng)論的重點(diǎn)。例如，Ivar Jacobson說(shuō)，對(duì)一個(gè)十人年的項(xiàng)目，他需要二十個(gè)用例。而在一個(gè)相同規(guī)模的項(xiàng)目中，Martin Fowler*則用了一百多

14、個(gè)用例。,*UML distilled一書的作者,2. 許多應(yīng)用中需要對(duì)系統(tǒng)訪問(wèn)進(jìn)行控制，應(yīng)該如何處理登錄問(wèn)題比較好？ 有四種處理登錄用例的方式: (1) 其它用例包含登錄; (2) 其它用例擴(kuò)展登錄; (3) 登錄獨(dú)立于其它用例; (4) 登錄包含其它用例。,(1) 其它用例包含登錄 用例說(shuō)明: 這種處理方式的特點(diǎn):,(2) 其它用例擴(kuò)展登錄 用例說(shuō)明: 這種處理方式的特點(diǎn):,(3) 登錄獨(dú)立于其它用例。 用例說(shuō)明: 這種處理方式的特點(diǎn):,登錄用例說(shuō)明: 1. 當(dāng)超級(jí)用戶啟動(dòng)應(yīng)用時(shí)用例開始 2. 系統(tǒng)提示超級(jí)用戶輸入用戶名和密碼 3. 超級(jí)用戶輸入用戶名和密碼 4. 系統(tǒng)驗(yàn)證其是否為有效超級(jí)

15、用戶 5. 用例結(jié)束 調(diào)入員工用例說(shuō)明: 前置條件: 一個(gè)有效超級(jí)用戶登錄了系統(tǒng),(4) 登錄包含其它用例 用例說(shuō)明: 存在的問(wèn)題:,3. 假設(shè)有這樣需求：學(xué)生檔案管理中，用戶經(jīng)常需要做三件事：增加一條學(xué)生記錄、修改一條學(xué)生記錄，刪除一條學(xué)生記錄。如果要畫出use case圖，以下2種方法哪種更合適？,方法1：再分成3個(gè)腳本，分別畫3個(gè)交互圖。腳本1 增加學(xué)生記錄； 腳本2 修改學(xué)生記錄；腳本3 刪除學(xué)生記錄。,方法2：每個(gè)use case畫一個(gè)交互圖。,8.4.4 合理組織用例,對(duì)用例進(jìn)行分包 讓用例圖能夠更為清晰地表現(xiàn)出系統(tǒng)的業(yè)務(wù)邏輯關(guān)系和層次 對(duì)系統(tǒng)進(jìn)行模塊的分割，這將影響到今后的開發(fā)和

16、系統(tǒng)的最終表現(xiàn)形式 常見的分包方式 按參與者分包，如讀者包、圖書管理員包 按主題分包，如畢設(shè)的題目管理包、成績(jī)管理包 按開發(fā)團(tuán)隊(duì)分包，A小組、B小組 按發(fā)布情況分包，第1次迭代包,錯(cuò)誤的用例圖舉例,把步驟當(dāng)用例 把系統(tǒng)活動(dòng)當(dāng)用例,錯(cuò)誤的用例圖舉例,Email客戶端（如：outlook express），A在北京發(fā)郵件給上海的B，系統(tǒng)提醒B你有“新郵件”，B收郵件,用例是一個(gè)完整的交互 用例之間沒(méi)有順序的關(guān)系,課堂練習(xí)：用例建模,完成“旅店預(yù)定系統(tǒng)”的系統(tǒng)用例圖，注意用例的命名和用例間的關(guān)系的使用。 選擇一個(gè)體現(xiàn)系統(tǒng)核心業(yè)務(wù)功能的用例，完成用例規(guī)格說(shuō)明。,“旅店預(yù)定系統(tǒng)”初步用戶需求,某公司要開

17、發(fā)一個(gè)旅店預(yù)定系統(tǒng)，該旅店可對(duì)外開放豪華雙人間、雙人間、三人間和單人間，房間費(fèi)用視情況按季節(jié)調(diào)整，但周一到周五半價(jià)（周末全價(jià)）折扣不變。對(duì)于外界請(qǐng)求，該系統(tǒng)應(yīng)能根據(jù)請(qǐng)求入住時(shí)間預(yù)定指定檔次的房間，記錄旅客姓名、地址、聯(lián)系電話、有效證件號(hào)、房間類型和預(yù)定天數(shù)，并計(jì)算出總費(fèi)用。預(yù)定的同時(shí)旅客按規(guī)定須提交10%定金。六個(gè)小時(shí)之內(nèi)旅店允許旅客取消預(yù)定，并退回所有定金，超過(guò)六個(gè)小時(shí)定金不退還。每周一系統(tǒng)自動(dòng)打印一周預(yù)定情況清單。采用哪種費(fèi)用支付方式和何種類型操作界面尚不確定。,問(wèn)題用例圖1,問(wèn)題用例圖2,問(wèn)題用例圖3,1. 不恰當(dāng)?shù)摹皶r(shí)間”參與者,時(shí)間：參與者，一種習(xí)慣用法，用于激活那些系統(tǒng)定期的、自動(dòng)

18、執(zhí)行的用例 “檢查是否可以退定金”的時(shí)候，時(shí)間僅僅是一個(gè)系統(tǒng)內(nèi)部的判斷條件，而不是參與者,2. 無(wú)效的參與者泛化,參與者泛化：特殊參與者會(huì)繼承泛化參與者所有的要素！ 參與者的重要性在一識(shí)別用例，如果泛化沒(méi)有帶來(lái)任何用例，則這樣的方法沒(méi)有任何意義 在系統(tǒng)中如果兩個(gè)參與者涉及相同的用例，則合并,3. 錯(cuò)誤的用例關(guān)系,依賴關(guān)系：include, extend都是依賴關(guān)系(dependency)的構(gòu)造型(stereotype)，帶箭頭的虛線表示 擴(kuò)展關(guān)系：“extend”關(guān)系的方向，子用例對(duì)主用例的擴(kuò)展,3. 錯(cuò)誤的用例關(guān)系,用例的順序在活動(dòng)圖中表現(xiàn),3. 錯(cuò)誤的用例關(guān)系,4. “其他”用例？,“其他

19、”、“打印清單”用例和外圍沒(méi)有任何有意義交互，和其他用例也沒(méi)有任何關(guān)系，這樣的用例有意義嗎？ “其他”用例又代表什么呢？想說(shuō)明什么樣的功能需求？,5.參與者和用例間的關(guān)系,“打印報(bào)表”和“酒店管理員”之間的關(guān)聯(lián)是有意義的交互嗎？,6. 用例粒度太小,用例規(guī)格描述常見錯(cuò)誤,用例描述中只有參與者動(dòng)作，沒(méi)有系統(tǒng)動(dòng)作。 用例描述中沒(méi)有主參與者。 描述中過(guò)多的用戶接口細(xì)節(jié)，如按鈕等界面元素的具體實(shí)現(xiàn)。 描述過(guò)低的目標(biāo)級(jí)別。,較為合理的用例圖,8.4.2 用例的描述,用例圖是對(duì)系統(tǒng)中的用例的高度概括和直觀的表示，但沒(méi)有細(xì)節(jié)。 一個(gè)用例就象一個(gè)故事，使用文字?jǐn)⑹鰧?duì)用例進(jìn)行詳細(xì)描述。 一個(gè)編寫良好的用例應(yīng)該具

20、有很好的可讀性，沒(méi)有可讀性的用例則一點(diǎn)兒用也沒(méi)有。 用例的描述可以有多種格式，從隨意的語(yǔ)言描述到定義嚴(yán)格的用例模板，可根據(jù)實(shí)際情況選擇。,1、用例規(guī)格說(shuō)明（模板）Use Case Specification,用例名稱 主要參與者/次要參與者 簡(jiǎn)要描述 前置條件 后置條件 主事件流（主要成功場(chǎng)景/基本路徑） 備選事件流（擴(kuò)展路徑/替代流程/異常事件流） 特殊要求/非功能性需求 發(fā)生頻率,2、用例與事件流（Flow of Activities）,用例描述的是一個(gè)系統(tǒng)做什么，可以通過(guò)用足夠清晰的、外部人員很容易理解的文字描述一個(gè)事件流，來(lái)說(shuō)明一個(gè)用例的行為。 事件流的描述包括： 用例何時(shí)開始和結(jié)束

21、用例何時(shí)與參與者交互 參與者與系統(tǒng)之間有什么對(duì)象或信息被交換 該行為的主事件流和備選事件流,3、用例與場(chǎng)景（Scenarios）,用例描述的是一組動(dòng)作序列，在復(fù)雜的系統(tǒng)中，用例細(xì)節(jié)可能存在多種不同的情節(jié)，稱為變體。 比如：購(gòu)買商品的用例中收款可以是現(xiàn)金支付、信用卡支付或支票支付。針對(duì)每一種情況有不同的場(chǎng)景，一個(gè)場(chǎng)景就是一個(gè)具體的故事現(xiàn)場(chǎng)，重現(xiàn)一個(gè)參與者如何具體完成用例。 主成功場(chǎng)景：故事的主線，用例通常得到成功執(zhí)行的典型場(chǎng)景。 擴(kuò)展場(chǎng)景：失敗場(chǎng)景，或因?yàn)橐恍┨貏e條件而出現(xiàn)行為分支的步驟（包括失敗和成功）,4、用例的前置條件和后置條件,前置條件（pre-condition）：表述在系統(tǒng)允許用例開

22、始以前，系統(tǒng)應(yīng)確保為真的條件。這可為后續(xù)的編程人員提供幫助，從而確定在用例的實(shí)現(xiàn)代碼中哪些條件無(wú)須再次檢驗(yàn)。 如果前置條件不滿足，用例無(wú)法被啟動(dòng)，比如“預(yù)定圖書”用例的前置條件是讀者已正確登錄到系統(tǒng)中。 后置條件（guarantee）：或稱為成功保證。表述在用例結(jié)束時(shí)，系統(tǒng)將要保證的限定條件，一般都是在成功完成用例后成立。 一旦用例被成功地執(zhí)行，可能會(huì)導(dǎo)致系統(tǒng)內(nèi)部某些狀態(tài)的改變，比如成功地“借出圖書”會(huì)使圖書狀態(tài)改變等。 某些用例可能沒(méi)有前置條件或后置條件，比如“查詢書目” 。,用例的簡(jiǎn)要描述,用例名：購(gòu)買商品 參與者：出納員 簡(jiǎn)要描述：顧客帶著所要購(gòu)買的商品來(lái)到收款處。收款員記錄下商品信息并

23、收款。付款完成后，顧客帶著所購(gòu)買的商品和收據(jù)離開。,購(gòu)買商品,收款員,對(duì)“取款”用例的非正式描述,1）用戶插入ATM卡并輸入密碼 2）用戶選擇取款并輸入取款數(shù)量 3）系統(tǒng)吐出現(xiàn)金，并從賬號(hào)余額中扣除取款數(shù),對(duì)“取款”用例的完整描述,主參與者：信用卡用戶 目標(biāo)： 用戶使用信用卡從ATM機(jī)獲取現(xiàn)金 范圍：銀行ATM系統(tǒng) 前置條件： 用戶將信用卡插入ATM 觸發(fā)事件： 用戶希望從ATM機(jī)上取現(xiàn)金 主事件流： 1）用戶插入信用卡到ATM機(jī) 2）ATM系統(tǒng)識(shí)別卡的ID和賬號(hào)，并用主銀行系統(tǒng)驗(yàn)證其有效性 3）用戶輸入密碼，ATM驗(yàn)證其有效性 4）用戶選擇取款，并輸入提取金額，該數(shù)額必須在502000之間，

24、50的倍數(shù) 5）ATM系統(tǒng)通知賬戶所在的主銀行系統(tǒng)，傳遞賬號(hào)和取款金額，并接受返回的確認(rèn)信息和賬戶余額 6）ATM系統(tǒng)發(fā)放現(xiàn)金、卡，并打印收據(jù) 7）ATM將事務(wù)記入日志,對(duì)“取款”用例的完整描述（續(xù)）,備選事件流： 2a：該卡不能在此ATM機(jī)上使用 3a：密碼不正確 3b：用戶沒(méi)有及時(shí)輸入密碼 4a：金額不是50的倍數(shù)，或不在指定范圍 5a：主機(jī)死機(jī)或網(wǎng)絡(luò)癱瘓 5b：賬戶余額不足 發(fā)生頻率： 一天1000次,“借出圖書”的用例描述,5、用例描述的雙列格式,每個(gè)用例可繪制系統(tǒng)級(jí)順序圖,純文本的用例描述直觀性較差 使用UML中的順序圖可以圖形化地表現(xiàn)出參與者和系統(tǒng)之間的交互,較為合理的用例規(guī)格說(shuō)明

25、1,用例名稱：預(yù)定房間 涉及的參與者：酒店前臺(tái) 描述：酒店前臺(tái)人員根據(jù)旅客的入住請(qǐng)求，預(yù)定某個(gè)時(shí)間指定檔次的房間，預(yù)定的同時(shí)旅客按規(guī)定須提交10%定金。 前置條件：前臺(tái)工作人員必須已經(jīng)登錄到這個(gè)系統(tǒng) 后置條件：預(yù)定信息正確的記錄到系統(tǒng)中 正常事件流： 1) 前臺(tái)人員向系統(tǒng)提供需要預(yù)定房間的類型、時(shí)間和預(yù)定天數(shù)。 2) 系統(tǒng)確認(rèn)有相應(yīng)檔次的空閑房間，并計(jì)算出總費(fèi)用和定金。 3) 前臺(tái)人員向系統(tǒng)提供旅客信息（姓名、地址、聯(lián)系電話、證件號(hào)等）。 4) 系統(tǒng)記錄旅客信息。 5) 前臺(tái)人員確認(rèn)已經(jīng)交納定金。 6) 系統(tǒng)記錄房間已經(jīng)預(yù)定，工作完成。 備選事件流： 2a.沒(méi)有指定類型的空閑房間,可以轉(zhuǎn)到第一步或者取消預(yù)定，用例結(jié)束 5a.顧客沒(méi)有交納定金，前臺(tái)工作人員取消預(yù)定，用例結(jié)束。,較為合理的用例規(guī)格說(shuō)明2,n用例名稱：取消預(yù)訂 n主要參與者：酒店前臺(tái) n描述：酒店前臺(tái)利用該用例來(lái)取消顧客的預(yù)定，如果在指定時(shí)間內(nèi)，則取消時(shí)需要返還顧客定金 n前置條件：用戶必須已經(jīng)預(yù)訂了某個(gè)房間 n后置條件：系統(tǒng)將取消預(yù)定的房間恢復(fù)為空閑，并且定金已返還給顧客 n