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

第6章組織系統(tǒng)需求：用例描述和圖使用“用例”來表達(dá)系統(tǒng)的功能需求的分類功能性需求：系統(tǒng)應(yīng)當(dāng)具備的功能，即系統(tǒng)必須能夠做什么、完成哪些工作。非功能性需求：系統(tǒng)精確度、性能、效率、成本、可維護(hù)性、安全性等系統(tǒng)行為之外的系統(tǒng)質(zhì)量需求。用例建模：捕獲系統(tǒng)的功能性需求，幫助人們理解系統(tǒng)需求，而無需關(guān)注系統(tǒng)如何實(shí)現(xiàn)本章內(nèi)容分辨信息系統(tǒng)的邊界什么是用例用例的概念、目的識別參與者識別用例繪制用例圖如何描述用例用例分解，確定用例關(guān)系6.1.1用例的概念用例創(chuàng)始人雅各布森IvarJacobson認(rèn)為：用例（usecase）是對于一組動作序列的描述，系統(tǒng)執(zhí)行這些動作會對特定的參與者（actor）產(chǎn)生可觀測的、有價值的結(jié)果。阿里斯代爾·科克伯恩AlistairCockburn：強(qiáng)調(diào)用例是各種系統(tǒng)受益人（stakeholder）之間的一種行為契約（contract）。行為包括對象的活動、動作和對象之間的交互等。建立契約的目的是為了達(dá)成某種目標(biāo)，因此每一個用例實(shí)際上都應(yīng)代表一個用戶目標(biāo)，根據(jù)三個目標(biāo)層次（概要層、用戶目標(biāo)層、子功能層）將用例進(jìn)行分層，從而有效把握用例的粒度。UseCase的定義在一個workshop(專題討論會)上，14位主要的OO專家對UseCase有14個定義。定義1：usecase是對一個活動者(actor)使用系統(tǒng)的一項功能時所進(jìn)行的交互過程的一個文字描述序列(見[2])。定義2：Thespecificationofsequencesofactions,includingvariantsequencesanderrorsequences,thatasystem,subsystem,orclasscanperformbyinteractingwithoutsideactors.(見[3])[2]

邵維忠，楊芙清，面向?qū)ο蟮南到y(tǒng)分析，p153[3]J.Rumbaugh,etc.TheUnifiedModelingLanguageReferenceManual,p488用例的意義用例是對系統(tǒng)需求（主要是功能需求）的規(guī)范化的描述。用例圖及用例的事件流描述集中體現(xiàn)了系統(tǒng)責(zé)任，通過用例建立交互圖。交互圖就是用例的具體實(shí)現(xiàn)，即系統(tǒng)中的對象以及對象間協(xié)作是如何完成一個用例的全部過程。用例驅(qū)動的開發(fā)過程，從用例模型到分析模型和設(shè)計模型之間有一致性和可追蹤性。用例是代表系統(tǒng)中各個相關(guān)人員之間就系統(tǒng)的行為所達(dá)成的契約。例：在線銀行系統(tǒng)的一些可能的用例：瀏覽帳戶余額列出交易內(nèi)容劃撥資金支付帳款登錄退出系統(tǒng)編輯配置文件買進(jìn)證券賣出證券UseCase驅(qū)動usecase對軟件開發(fā)的意義實(shí)現(xiàn)測試分析設(shè)計UseCases把所有這些過程綁到一起usecase說明：Usecase從使用系統(tǒng)的角度描述系統(tǒng)中的信息，即站在系統(tǒng)外部察看系統(tǒng)功能，并不考慮系統(tǒng)內(nèi)部對該功能的具體實(shí)現(xiàn)方式。使用usecase可以促進(jìn)與用戶溝通，理解正確的需求，同時也可以用來劃分系統(tǒng)與外部實(shí)體的界限，是OO系統(tǒng)設(shè)計的起點(diǎn)，是類、對象、操作的來源。9用例的一些特點(diǎn)：（1）用例描述了用戶提出的一些可見的需求；（2）用例可大可小；（3）用例對應(yīng)一個具體的用戶目標(biāo)。理論上我們可以把一個軟件系統(tǒng)的所有UseCase畫出來，但實(shí)際運(yùn)用時只需把重要的、交互過程復(fù)雜的那些畫出來。需求有兩種基本形式：功能性和非功能性的。不是所有的需求都要用usecase表示出來。問題：一個系統(tǒng)的需求包括哪些內(nèi)容？可以參照需求大綱10用例建模的內(nèi)容基于用例的需求獲取過程：1.獲取原始需求2.開發(fā)一個可以理解的需求識別參與者識別用例構(gòu)建用例圖3詳細(xì)、完整地描述需求書寫用例規(guī)格說明4重構(gòu)用例模型識別用例間的關(guān)系對用例進(jìn)行組織和分包1、識別參與者參與者是系統(tǒng)之外與系統(tǒng)進(jìn)行交互的任何事物。使用系統(tǒng)的個人誰負(fù)責(zé)提供、使用或刪除信息？誰將使用某項功能？系統(tǒng)所連接的外部硬件。例如，控制建筑物中溫度的通風(fēng)系統(tǒng)不斷地從傳感器獲取溫度信息，傳感器就是一個參與者。與該系統(tǒng)進(jìn)行通信的其他信息系統(tǒng)。例如為自動柜員機(jī)系統(tǒng)建模時，中央銀行系統(tǒng)就是它的一個參與者。信用卡系統(tǒng)是銷售系統(tǒng)中的一個參與者區(qū)分參與者和外部實(shí)體只有在執(zhí)行系統(tǒng)功能時與信息系統(tǒng)進(jìn)行實(shí)時交互的人員才能被當(dāng)作參與者新生入學(xué)手工填寫個人信息，然后由教務(wù)人員統(tǒng)一將數(shù)據(jù)登記到學(xué)籍系統(tǒng)中，教務(wù)人員是參與者。如果學(xué)生直接通過Web方式提交個人信息，則認(rèn)為學(xué)生是參與者。區(qū)分主要參與者和次要參與者主要參與者（primaryactor）是從系統(tǒng)中直接獲得可度量價值的用戶。次要參與者（secondaryactor）的需求驅(qū)動了用例所表示的行為或功能，在用例中起輔助支持作用用例分析的重點(diǎn)是要找到主要參與者。比如，在圖書館的借/還書用例中，首先要考慮誰直接使用這一功能，誰頻繁地和系統(tǒng)進(jìn)行交互？圖書管理人員是直接操作者，他們的需求和變化對于用例的影響最大。因此，圖書管理員是主要參與者。事件觸發(fā)源操作輸出目標(biāo)讀者檢查庫存書目書目查詢請求讀者提供書目供檢索書籍列表讀者讀者借書借書單讀者登記借書記錄書借書記錄讀者通過事件表獲得參與者：參與者可以從“源”得到啟發(fā)，但“源”表示數(shù)據(jù)最初的提供者，不一定對應(yīng)功能的執(zhí)行者。參與者舉例參與者的表示在UML中，參與者使用小人符號：圖書館系統(tǒng)讀者圖書管理員RSA中的建模符號參與者的泛化在某些情況下，參與者的角色可以有共性，或者說一般性，一種角色可以擁有另一種角色的全部行為。比如在超市系統(tǒng)中，值班經(jīng)理完全可以充當(dāng)收銀員這一角色，此外，值班經(jīng)理還可以有退貨、更改事務(wù)等權(quán)利。2、識別用例用例就是功能性需求。每個用例至少和一個參與者相關(guān)，用例名稱要體現(xiàn)參與者希望系統(tǒng)提供的功能。用例的UML圖形表示購買商品Rose中的符號購買商品區(qū)分用例和用例完成的步驟不能混淆用例和用例所包含的步驟。比如“借出圖書”功能要經(jīng)過驗證讀者信息、檢查超出可借數(shù)量、保存借書記錄、修改圖書狀態(tài)等步驟在系統(tǒng)中這些步驟通常不作為單獨(dú)的功能提供給參與者使用，它們只是一個用例所包含的事件流，或者是用例的子功能。與結(jié)構(gòu)化分析中提到的事件概念相同。區(qū)分業(yè)務(wù)用例和系統(tǒng)用例當(dāng)針對整個業(yè)務(wù)領(lǐng)域建模時，需要使用業(yè)務(wù)用例比如圖書館系統(tǒng)有一項重要工作就是“整理書架”，圖書都要放回到固定的位置上信息系統(tǒng)作為整個業(yè)務(wù)系統(tǒng)的一部分，只負(fù)責(zé)實(shí)現(xiàn)系統(tǒng)的部分功能，即有信息處理的那部分功能?？蛻籼岢錾暾堃筚J款，申請中包括期限、金額、用途和本人基本情況。銀行收到申請后，置于“申請檔案”中，以申請?zhí)枠?biāo)識。某公司內(nèi)部工作崗位的提供：不論何時，只要一有職位空缺，該地區(qū)的人力資源部領(lǐng)導(dǎo)就會通知該地區(qū)的所有員工并給其他地區(qū)的HR領(lǐng)導(dǎo)發(fā)送消息，邀請員工們提出申請。然后，其他地區(qū)HR領(lǐng)導(dǎo)將招聘信息貼在公告板上。所有對此感興趣的員工都可以將申請發(fā)送到職位空缺的地區(qū)的HR領(lǐng)導(dǎo)那里。用例舉例1用例舉例2在門診掛號處只能掛當(dāng)天的號，掛出的號可以退。病人拿到掛號單后，到相應(yīng)的科室進(jìn)行就診。醫(yī)生根據(jù)掛號的順序號，依次給病人看病開處方。病人拿處方去收款處交費(fèi)，并拿到發(fā)票。病人拿已經(jīng)收費(fèi)的處方去藥房拿藥。該系統(tǒng)潛在的參與者和用例有哪些？圖書館系統(tǒng)的用例圖進(jìn)行用例描述時，往往會有冗余的情況出現(xiàn)，比如多個用例會共享一些子功能。擴(kuò)展和包含關(guān)系就是用例模型中消除冗余的一種手段。基本用例是包含常規(guī)會發(fā)生的最基本功能的用例，它是具有普遍性的，對于任何執(zhí)行該功能的參與者來講都是適合的。6.2用例關(guān)系用例關(guān)系包含關(guān)系：經(jīng)過封裝后可以在各種不同的基本用例中復(fù)用的行為稱為包含用例。擴(kuò)展關(guān)系：表達(dá)某些可選或只在特定條件下才執(zhí)行的系統(tǒng)行為的用例，它們是對基本用例的擴(kuò)展。稱為擴(kuò)展用例。泛化關(guān)系：如果兩個或更多用例在行為、結(jié)構(gòu)和目的方面存在共性，可以使用泛化關(guān)系。父用例描述這些共有部分，子用例繼承父用例并特殊化?；居美梢钥刂瓢美?，并依賴于（使用）包含用例所得到的結(jié)果。包含用例是基本用例存在的必要條件一個基本用例可以有多個包含用例，一個包含用例可以包含在若干基本用例中。包含關(guān)系可以嵌套，但超過三層的嵌套是難于理解的。取款修改口令身份識別<<include>><<include>>包含關(guān)系擴(kuò)展用例是可選的，它是否執(zhí)行取決于在執(zhí)行基本用例時所發(fā)生的事件（存在擴(kuò)展點(diǎn)）。擴(kuò)展用例的缺失不影響對基本用例的理解。打電話來電顯示三方通話<<extend>><<extend>>擴(kuò)展關(guān)系用一個新的、通常也是抽象的用例來描述多個用例的共有部分(父用例)，子用例繼承父用例的所有結(jié)構(gòu)、行為和關(guān)系，并含有自己特殊的部分。父用例通常是抽象的，如果兩個子用例都對同一父用例進(jìn)行特殊化，則兩個子用例是相互獨(dú)立而且完整的，這一點(diǎn)與包含關(guān)系擴(kuò)展關(guān)系不同。訂購網(wǎng)上訂購電話訂購泛化關(guān)系（不推薦）小結(jié)：actor，usecase的關(guān)系(relationship)類型說明：可在usecase間建立關(guān)聯(lián)，但意義不是很明確。association關(guān)聯(lián):actor和usecase之間的關(guān)系包含:usecase之間的關(guān)系includeextend擴(kuò)展:usecase之間的關(guān)系generalization泛化:actor之間或usecase之間的關(guān)系關(guān)系類型說明表示符號30用例的粒度通常用例圖粒度較大通過分解和細(xì)化，可以使粒度更小通過事件流描述：尋找用例的共同點(diǎn)尋找用例的擴(kuò)展點(diǎn)切忌“畫蛇添足”！常見問題分析1.Usecase的粒度問題，即對于一個系統(tǒng)的UseCase圖，所包含的用例數(shù)目問題。這是很多人爭論的重點(diǎn)。例如，IvarJacobson說，對一個十人年的項目，他需要二十個用例。而在一個相同規(guī)模的項目中，MartinFowler*則用了一百多個用例。*《UMLdistilled》一書的作者322.許多應(yīng)用中需要對系統(tǒng)訪問進(jìn)行控制，應(yīng)該如何處理登錄問題比較好？有四種處理登錄用例的方式:(1)其它用例包含登錄;(2)其它用例擴(kuò)展登錄;(3)登錄獨(dú)立于其它用例;(4)登錄包含其它用例。33(1)其它用例包含登錄用例說明:……這種處理方式的特點(diǎn):34(2)其它用例擴(kuò)展登錄用例說明:……這種處理方式的特點(diǎn):35(3)登錄獨(dú)立于其它用例。用例說明:……這種處理方式的特點(diǎn):36登錄用例說明:1.當(dāng)超級用戶啟動應(yīng)用時用例開始2.系統(tǒng)提示超級用戶輸入用戶名和密碼3.超級用戶輸入用戶名和密碼4.系統(tǒng)驗證其是否為有效超級用戶5.用例結(jié)束調(diào)入員工用例說明:前置條件:一個有效超級用戶登錄了系統(tǒng)37(4)登錄包含其它用例用例說明:……存在的問題:383.假設(shè)有這樣需求：學(xué)生檔案管理中，用戶經(jīng)常需要做三件事：增加一條學(xué)生記錄、修改一條學(xué)生記錄，刪除一條學(xué)生記錄。如果要畫出usecase圖，以下2種方法哪種更合適？方法1：再分成3個腳本，分別畫3個交互圖。腳本1增加學(xué)生記錄；腳本2修改學(xué)生記錄；腳本3刪除學(xué)生記錄。方法2：每個usecase畫一個交互圖。398.4.4合理組織用例對用例進(jìn)行分包讓用例圖能夠更為清晰地表現(xiàn)出系統(tǒng)的業(yè)務(wù)邏輯關(guān)系和層次對系統(tǒng)進(jìn)行模塊的分割，這將影響到今后的開發(fā)和系統(tǒng)的最終表現(xiàn)形式常見的分包方式按參與者分包，如讀者包、圖書管理員包按主題分包，如畢設(shè)的題目管理包、成績管理包按開發(fā)團(tuán)隊分包，A小組、B小組按發(fā)布情況分包，第1次迭代包…錯誤的用例圖舉例把步驟當(dāng)用例把系統(tǒng)活動當(dāng)用例錯誤的用例圖舉例Email客戶端（如：outlookexpress），A在北京發(fā)郵件給上海的B，系統(tǒng)提醒B你有“新郵件”，B收郵件用例是一個完整的交互用例之間沒有順序的關(guān)系課堂練習(xí)：用例建模完成“旅店預(yù)定系統(tǒng)”的系統(tǒng)用例圖，注意用例的命名和用例間的關(guān)系的使用。選擇一個體現(xiàn)系統(tǒng)核心業(yè)務(wù)功能的用例，完成用例規(guī)格說明?！奥玫觐A(yù)定系統(tǒng)”初步用戶需求某公司要開發(fā)一個旅店預(yù)定系統(tǒng)，該旅店可對外開放豪華雙人間、雙人間、三人間和單人間，房間費(fèi)用視情況按季節(jié)調(diào)整，但周一到周五半價（周末全價）折扣不變。對于外界請求，該系統(tǒng)應(yīng)能根據(jù)請求入住時間預(yù)定指定檔次的房間，記錄旅客姓名、地址、聯(lián)系電話、有效證件號、房間類型和預(yù)定天數(shù)，并計算出總費(fèi)用。預(yù)定的同時旅客按規(guī)定須提交10%定金。六個小時之內(nèi)旅店允許旅客取消預(yù)定，并退回所有定金，超過六個小時定金不退還。每周一系統(tǒng)自動打印一周預(yù)定情況清單。采用哪種費(fèi)用支付方式和何種類型操作界面尚不確定。問題用例圖1問題用例圖2問題用例圖31.不恰當(dāng)?shù)摹皶r間”參與者時間：參與者，一種習(xí)慣用法，用于激活那些系統(tǒng)定期的、自動執(zhí)行的用例“檢查是否可以退定金”的時候，時間僅僅是一個系統(tǒng)內(nèi)部的判斷條件，而不是參與者2.無效的參與者泛化參與者泛化：特殊參與者會繼承泛化參與者所有的要素！參與者的重要性在一識別用例，如果泛化沒有帶來任何用例，則這樣的方法沒有任何意義在系統(tǒng)中如果兩個參與者涉及相同的用例，則合并3.錯誤的用例關(guān)系依賴關(guān)系：include,extend都是依賴關(guān)系(dependency)的構(gòu)造型(stereotype)，帶箭頭的虛線表示擴(kuò)展關(guān)系：“extend”關(guān)系的方向，子用例對主用例的擴(kuò)展3.錯誤的用例關(guān)系用例的順序在活動圖中表現(xiàn)3.錯誤的用例關(guān)系4.“其他”用例？“其他”、“打印清單”用例和外圍沒有任何有意義交互，和其他用例也沒有任何關(guān)系，這樣的用例有意義嗎？“其他”用例又代表什么呢？想說明什么樣的功能需求？5.參與者和用例間的關(guān)系“打印報表”和“酒店管理員”之間的關(guān)聯(lián)是有意義的交互嗎？6.用例粒度太小用例規(guī)格描述常見錯誤用例描述中只有參與者動作，沒有系統(tǒng)動作。用例描述中沒有主參與者。描述中過多的用戶接口細(xì)節(jié)，如按鈕等界面元素的具體實(shí)現(xiàn)。描述過低的目標(biāo)級別。較為合理的用例圖8.4.2用例的描述用例圖是對系統(tǒng)中的用例的高度概括和直觀的表示，但沒有細(xì)節(jié)。一個用例就象一個故事，使用文字?jǐn)⑹鰧τ美M(jìn)行詳細(xì)描述。一個編寫良好的用例應(yīng)該具有很好的可讀性，沒有可讀性的用例則一點(diǎn)兒用也沒有。用例的描述可以有多種格式，從隨意的語言描述到定義嚴(yán)格的用例模板，可根據(jù)實(shí)際情況選擇。1、用例規(guī)格說明（模板）

UseCaseSpecification用例名稱主要參與者/次要參與者簡要描述前置條件后置條件主事件流（主要成功場景/基本路徑）備選事件流（擴(kuò)展路徑/替代流程/異常事件流）特殊要求/非功能性需求發(fā)生頻率2、用例與事件流（FlowofActivities）用例描述的是一個系統(tǒng)做什么，可以通過用足夠清晰的、外部人員很容易理解的文字描述一個事件流，來說明一個用例的行為。事件流的描述包括：用例何時開始和結(jié)束用例何時與參與者交互參與者與系統(tǒng)之間有什么對象或信息被交換該行為的主事件流和備選事件流3、用例與場景（Scenarios）用例描述的是一組動作序列，在復(fù)雜的系統(tǒng)中，用例細(xì)節(jié)可能存在多種不同的情節(jié)，稱為變體。比如：購買商品的用例中收款可以是現(xiàn)金支付、信用卡支付或支票支付。針對每一種情況有不同的場景，一個場景就是一個具體的故事現(xiàn)場，重現(xiàn)一個參與者如何具體完成用例。主成功場景：故事的主線，用例通常得到成功執(zhí)行的典型場景。擴(kuò)展場景：失敗場景，或因為一些特別條件而出現(xiàn)行為分支的步驟（包括失敗和成功）4、用例的前置條件和后置條件前置條件（pre-condition）：表述在系統(tǒng)允許用例開始以前，系統(tǒng)應(yīng)確保為真的條件。這可為后續(xù)的編程人員提供幫助，從而確定在用例的實(shí)現(xiàn)代碼中哪些條件無須再次檢驗。如果前置條件不滿足，用例無法被啟動，比如“預(yù)定圖書”用例的前置條件是讀者已正確登錄到系統(tǒng)中。后置條件（guarantee）：或稱為成功保證。表述在用例結(jié)束時，系統(tǒng)將要保證的限定條件，一般都是在成功完成用例后成立。一旦用例被成功地執(zhí)行，可能會導(dǎo)致系統(tǒng)內(nèi)部某些狀態(tài)的改變，比如成功地“借出圖書”會使圖書狀態(tài)改變等。某些用例可能沒有前置條件或后置條件，比如“查詢書目”。用例的簡要描述用例名：購買商品參與者：出納員簡要描述：顧客帶著所要購買的商品來到收款處。收款員記錄下商品信息并收款。付款完成后，顧客帶著所購買的商品和收據(jù)離開。購買商品收款員對“取款”用例的非正式描述1）用戶插入ATM卡并輸入密碼2）用戶選擇取款并輸入取款數(shù)量3）系統(tǒng)吐出現(xiàn)金，并從賬號余額中扣除取款數(shù)對“取款”用例的完整描述主參與者：信用卡用戶目標(biāo)：用戶使用信用卡從ATM機(jī)獲取現(xiàn)金范圍：銀行ATM系統(tǒng)前置條件：用戶將信用卡插入ATM觸發(fā)事件：用戶希望從ATM機(jī)上取現(xiàn)金主事件流：1）用戶插入信用卡到ATM機(jī)2）ATM系統(tǒng)識別卡的ID和賬號，并用主銀行系統(tǒng)驗證其有效性3）用戶輸入密碼，ATM驗證其有效性4）用戶選擇取款，并輸入提取金額，該數(shù)額必須在50～2000之間，50的倍數(shù)5）ATM系統(tǒng)通知賬戶所在的主銀行系統(tǒng)，傳遞賬號和取款金額，并接受返回的確認(rèn)信息和賬戶余額6）ATM系統(tǒng)發(fā)放現(xiàn)金、卡，并打印收據(jù)7）ATM將事務(wù)記入日志對“取款”用例的完整描述（續(xù)）備選事件流：2a：該卡不能在此ATM機(jī)上使用3a：密碼不正確3b：用戶沒有及時輸入密碼4a：金額不是50的倍數(shù)，或不在指定范圍5a：主機(jī)死機(jī)或網(wǎng)絡(luò)癱瘓5b：賬戶余額不足發(fā)生頻率：一天1000次“借出圖書”的用例描述用例名稱借出圖書參與者圖書管理員（主要參與者），讀者（次要參與者）假設(shè)圖書館是開架借閱，讀者總是找到書后辦理借書手續(xù)，因此，借書不需要驗證庫存，而且每本書都是可識別的。前置條件圖書管理員已被識別和授權(quán)后置條件存儲借書記錄，更新庫存數(shù)量，所借圖書狀態(tài)為出借主事件流1．圖書管理員將讀者借書卡提供給系統(tǒng)；2．系統(tǒng)驗證讀者身份和借書條件；3．圖書管理員將讀者所借圖書輸入系統(tǒng)；4．系統(tǒng)記錄借書信息，并且修改圖書的狀態(tài)和此種書的可借數(shù)量；5．系統(tǒng)累加讀者的借書數(shù)量；6．重復(fù)3-5，直到圖書管理員確認(rèn)全部圖書登記完畢；7．系統(tǒng)打印借書清單，交易成功完成。備選事件流2a．非法讀者

1．系統(tǒng)提示讀者身份錯誤，用例結(jié)束2b．讀者借書數(shù)已達(dá)限額

1．系統(tǒng)提示讀者已達(dá)結(jié)束限額，用例結(jié)束2c．讀者有過期未還書籍

1．系統(tǒng)提示讀者應(yīng)歸還的書籍列表和到期日，用例結(jié)束5a．讀者借書數(shù)已達(dá)限額

1．系統(tǒng)提示，并要求結(jié)束輸入

2．圖書管理員確認(rèn)借書完成5b．讀者有該書的預(yù)定記錄

1.刪除該書的預(yù)定信息5、用例描述的雙列格式用例名稱歸還圖書參與者圖書管理員（主要參與者），讀者（次要參與者）假設(shè)因為每本書是可識別的，所以還書不需要驗證讀者前置條件圖書管理員已被識別和授權(quán)后置條件修改借書記錄，更新庫存數(shù)量，修改圖書狀態(tài)為可借主事件流1．圖書管理員將圖書提供給系統(tǒng)；5．圖書管理員重復(fù)步驟1，直到退出2．系統(tǒng)根據(jù)借書記錄驗證圖書信息；3．系統(tǒng)提供借閱該書的讀者信息；4．系統(tǒng)修改借書記錄，更新該書的圖書狀態(tài)及此種書的可借數(shù)量；每個用例可繪制系統(tǒng)級順序圖純文本的用例描述直觀性較差使用UML中的順序圖可以圖形化地表現(xiàn)出參與者和系統(tǒng)之間的交互較為合理的用例規(guī)格說明1用例名稱：預(yù)定房間涉及的參與者：酒店前臺描述：酒店前臺人員根據(jù)旅客的入住請求，預(yù)定某個時間指定檔次的房間，預(yù)定的同時旅客按規(guī)定須提交10%定金。前置條件：前臺工作人員必須已經(jīng)登錄到這個系統(tǒng)后置條件：預(yù)定信息正確的記錄到系統(tǒng)中正常事件流：1)前臺人員向系統(tǒng)提供需要預(yù)定房間的類型、時間和預(yù)定天數(shù)。2)系統(tǒng)確認(rèn)有相應(yīng)檔次的空閑房間，并計算出總費(fèi)用和定金。3)前臺人員向系統(tǒng)提供旅客信息（姓名、地址、聯(lián)系電話、證件號等）。4)系統(tǒng)記錄旅客信息。5)前臺人員確認(rèn)已經(jīng)交納定金。6)系統(tǒng)記錄房間已經(jīng)預(yù)定，工作完成。備選事件流：2a.沒有指定類型的空閑房間,可以轉(zhuǎn)到