1、1,第3章 軟件需求的 用例建模方法,郵購系統(tǒng)的業(yè)務過程陳述（工作流）： 公司的目標是為公司的所有注冊會員提供高質(zhì)量的郵購服務。 任何個人或公司只要完成注冊表單并將其發(fā)送到客戶服務部 門，成為會員。 會員可以通過填寫訂購表單并將其發(fā)送給客服部門進行訂購。 客服部門驗證會員資格，將訂單轉(zhuǎn)給銷售部門。 庫存有貨，銷售部門處理訂單，并將發(fā)貨單存給庫存部門。 庫存無貨，銷售部門向供應商發(fā)送購貨單。 購買的貨物到后，入庫，庫存部門將貨物交給該會員，財務 部門將發(fā)票給會員。 財務部門收到供應商的物品及發(fā)票，驗證合格后，將貨款打 給供應商。,回顧:郵購的業(yè)務過程分析,2,客戶 客戶服務部 銷售部門 庫存部門

2、 財務部門,填寫訂 貨表單,有庫存,處理訂單,下訂單,填寫注 冊表單,注冊會員,訂貨,發(fā)送貨物,接受貨物,發(fā)送發(fā) 貨單,接受發(fā) 貨單,發(fā)出 貨款,無庫存,郵購公司業(yè)務活動圖,回顧:郵購的業(yè)務過程分析,下面要進行什么分析?,軟件需求?,3,4,回顧需求的活動 用例圖和用例的描述,重點,內(nèi)容,什么是用例? 用例圖包括哪些內(nèi)容? 用例的文字描述的步驟?,4,5,3.1 需求(requirement)與需求的活動,需求就是要獲得系統(tǒng)提供的所有服務,是“做什么”,軟件需求包括五個層次：,業(yè)務需求,用戶需求,功能和非功能需求,環(huán)境、約束的需求,接口的需求,需求分析階段的活動,產(chǎn)出物,會議紀要 討論紀要,分

3、析模型,需求規(guī)格 說明書,審核通過的 規(guī)格說明書,圖 3-1 需求分析階段的活動,需求管理,需求 獲取,需求分析 與建模,規(guī)格 說明,需求 驗證,6,用例的概念在1986年 由Ivar Jacobson正式 提出之后被廣泛接受， 迅速發(fā)展，已成為OO、 UML、RUP的標準規(guī) 范和方法。,3.2 軟件需求-用例建模技術,在結(jié)構化的軟件需求 “系統(tǒng)做什么?”的問題中,增 加三個詞“for each user”, 使問題變?yōu)椤跋到y(tǒng)應該為每 個用戶做什么? ”,系統(tǒng)對用 戶有什么價值。,7,用例方法的思想： 從用戶的角度看，他們所關心的是系統(tǒng)所能 提供的服務，用戶使用系統(tǒng)完成不同的任務。,通訊關聯(lián),

4、圖 3-2 系統(tǒng)透視,參與者,系統(tǒng)外部，并與 該系統(tǒng)發(fā)生交互 的人或其他系統(tǒng)。,系統(tǒng)基本 事件流。,用例,3.2.1 什么是用例,問:一個自動飲料售貨機的功能是什么?,答:通過自動飲料售貨機購買一聽飲料(買飲料)。,8,9,參 與 者,用 例,顧客,買飲料,收款員,收款,供應商,提供飲料,圖 3-3 自動飲料售貨機的用例圖,通信,用例：站在用戶角度定義軟件系統(tǒng)的外部特征(1),用例：是系統(tǒng)執(zhí)行的動作集合規(guī)格說明 (2),用例的特征：,特定的角色(particular actor)觸發(fā)某些行為 行為序列(sequences of actions) 系統(tǒng)執(zhí)行(system performs)提供的

5、服務 可觀測到的、有價值的結(jié)果(observable result of value)。,10,用例分析技術,用例圖顯示了系統(tǒng)的一組用例、用例的參與 者及二者之間關系的圖。,3.2.2 基本用例圖(use case diagram)的組成,學生,成績管理員,注冊員,圖 3-4 簡單大學用例圖,用例圖的組成 參與者(actor) 用例 系統(tǒng)邊界（隱藏） 參與者與用例的 通信關聯(lián) (communication association),1) 參與者 (actor),人與系統(tǒng)進行交互時能夠擔任的不同角色為 參與者(actor)。,11,參與者可以是人也可以是其他系統(tǒng)。 參與者是系統(tǒng)的真正用戶,但二者

6、并不存在一對 一的對應。 參與者訪問系統(tǒng)是有級別的,可由系統(tǒng)功能而定。,確定參與者(actor),系統(tǒng)的主要客戶是誰?,系統(tǒng)從什么地方得到信息?,該系統(tǒng)與其他系統(tǒng)交互信息是什么?,在某一個預定時間，自動發(fā)生什么事情?,特殊的參與者：系統(tǒng)時鐘,利用該參與者觸發(fā)系統(tǒng)的一類定時操作。如定時檢測 系統(tǒng)、資源使用情況、定期生成統(tǒng)計報表等，這些操 作并不是由外部的人或系統(tǒng)觸發(fā)的。,從邏輯上，這一參與者應該被理解成是系統(tǒng)外部的， 由它來觸發(fā)系統(tǒng)所提供的用例對話。,12,13,在使用參與者為角色建模中是一種抽象， 不為具體的人、機構、系統(tǒng)建模。,注意,圖 3-6 對職位建模(不合理),張助教,輸入分數(shù),分發(fā)成

7、績單,劉老師,核對分數(shù),2) 確定用例,用例描述一個事件發(fā)生,產(chǎn)生動作步驟的集合。,14,(1) 基于參與者的方法 對每個參與者,識別出他們發(fā)起或參加 的執(zhí)行過程。,(2) 基于事件的方法 # 識別出系統(tǒng)必須響應的外部事件； # 把事件與參與者和用例聯(lián)系起來。,以編制好的需求規(guī)格說明文檔為基礎,例：ATM系統(tǒng)的用例,參與者：銀行客戶 用 例：銀行客戶使用自動提款機來進行銀行 帳戶的查詢、提款和轉(zhuǎn)帳交易,銀行客戶,取款,轉(zhuǎn)帳,存款,圖 3-7 ATM系統(tǒng)的用例圖,查詢,維護人員,維護系統(tǒng),周期性操作,后臺服務器,還有哪些用例?,還有哪些改進?,15,ATM系統(tǒng)的改進用例圖,查詢,存、取款,轉(zhuǎn)帳,

8、周期性任務,維護人員,維護系統(tǒng),圖 3-8 改進的ATM系統(tǒng)用例圖,系統(tǒng)時鐘,后臺服務器,銀行客戶,16,系統(tǒng)的啟動用例,幾乎所有的 系統(tǒng)都包含 一個系統(tǒng)啟 動用例。,17,出納員,購買商品,登錄,啟動,退還商品,管理用戶,其他,顧客,系統(tǒng)管理員,管理員,圖 3-9 POST系統(tǒng)部分用例圖,這個用例有什么問題?,18,顧客,3) 邊界的選擇,定義系統(tǒng)的邊界是為了識別出什么在系統(tǒng)之內(nèi), 什么在系統(tǒng)之外,進而識別出什么是系統(tǒng)的職責。,典型的系統(tǒng)邊界包括:硬件設備或硬件/軟件邊界,一個組織中的部門或整個組織。,3.2.3 用例圖上的其他關系,在基本的用例圖中，只需表述參與者和用例之間的 通訊關系。

9、此外，還可以描述： 參與者與參與者之間的泛化關系(generalization)。 用例和用例之間的泛化(generalization)關系， 包含(include)關系， 擴展(extend)關系。 利用這些關系來調(diào)整、優(yōu)化用例模型，抽取公共的 信息，便于復用和維護。,19,1) 參與者之間的關系,參與者之間的泛化(Generalization)關系,actor 2,actor 1,客戶,電話登 記客戶,上網(wǎng)登 記客戶,20,2) 用例之間的關系 (1) 泛化(generalization )關系,將它們的共性抽象成為父用例，其他的用例作為泛化 關系中的子用例。 子用例繼承了父用例所有的結(jié)構

10、、行為和關系。,采購員,采購物料,采購 鋼材,采購辦 公用品,圖 3-13 用例的泛化關系,買票,購買 團體票,子用例,付費方式,支付 現(xiàn)金,支付 信用卡,購買 個人票,父用例,21,用例之間的關系： (2) 包含(include),包含關系是：基用例指向被包含用例。,語義：基用例會用到被包含用例，被包含用例的 事件流被插入到基用例的事件流中。,銀行客戶,查詢,取款,轉(zhuǎn)帳,卡片驗證,圖 3-14 用例的包含關系,基用例,被包含用例,基用例不能獨立存在,必須依賴于被包含用例。 被包含用例一定要執(zhí)行。,許多用例的公共 部分移到一個單 獨的被包含用例中。,22,例,包含關系的幾種可能性,圖 3-15

11、 包含關系的幾種可能性,1,2,3,4,23,用例之間的關系： (3) 擴展(extend),擴展關系是：擴展用例指向基用例(被擴展用例)。,一個用例中有許多替代 物或選擇時,使用擴展關 系,管理變更。,呼叫轉(zhuǎn)移,銀行客戶,打電話,呼叫等待,圖 3-16 用例的擴展關系,語義:基用例在某些特定情況下會用到擴展用例，擴 展用例的事件流將被插入到基用例的事件流中。,擴展用例 (可變部分),基用例 (不變部分),基用例能獨立存在,不依賴于它的擴展用例。 擴展用例可以不執(zhí)行。,24,例:用例之間的關系：擴展(extend),打電話,呼叫等待,呼叫轉(zhuǎn)移,實際上相當于第一個用例的“備選流”,25,擴展關系

12、的幾種可能性,圖 3-17 擴展關系的幾種可能性,1,2,3,4,26,27,登記 借書,查詢讀者,查詢讀書,參加考試,補考,創(chuàng)建新賬戶,啟動系統(tǒng),刪除賬戶,修改賬戶,登記借書,登記還書,驗證讀者,例,標出下面用例圖上的關系?,圖 3-18 有包含關系和擴展關系的用例圖1,27,28,提供客戶數(shù)據(jù),訂貨,訂貨項目,例:,查詢,存款,打印收據(jù),既是擴展用例也是被包含用例,查詢,存款,打印收據(jù),打印收據(jù),分開表示,訂貨,請求目錄,圖 3-18 有包含關系和擴展關系的用例圖2,28,29,例: 確定下面用例模型中的幾種關系,extend,泛化,include,通信關聯(lián),圖 3-19 用例模型中的幾種

13、關系,注冊 進大學,注冊 討論班,在大學生中 注冊家庭成員,在大學中注 冊國際學生,注冊員,學生,國際學生,練習：舉例說明用例的含包關系和擴展關系的區(qū)別。,基用例,3.2.4 用例的文字描述,用例 = 橢圓 + 名字？, NO！,用例規(guī)約,.,用例模型,參與者,用例,術語表,30,在業(yè)務需求陳述的基礎上: (1)建立初始的用例圖。 確定參與者 確定用例 建立參與者與用例的關聯(lián) (2)進行用例的文字描述 (3)細化用例 進一步標明用例間的包含、擴展、泛化關系 (4)對用例進行分組，用包圖表示。,3.2.5 如何建立用例模型,例1 郵購系統(tǒng),31,客戶通過填寫會員注冊表單并將發(fā)送給公司經(jīng)審批成為會

14、員。 會員在一年內(nèi)無活動,將會被刪除。 會員的個人信息改變后,應通知公司。 會員填寫銷售表單并發(fā)送給公司,會員可以訂購了。 客戶服務助理也可以通過電話方式處理訂單。 客戶服務助理檢查會員資格的有效性后可將訂購信息輸入 到系統(tǒng)。 庫存握制員負責對庫存量的監(jiān)管及訂貨。 若訂單有問題,會員電話聯(lián)系服務助理,并由助理追查銷售 訂單。 會員可在30天內(nèi)退還次品,并取回貨款。 系統(tǒng)執(zhí)行的每項任務都會記錄相關員工的名字和ID。,郵購系統(tǒng)用例級別的業(yè)務活動問題描述,32,(1)尋找參與者和用例-建立初始的用例圖,檢查訂單狀態(tài),下訂單,處理訂單,處理退貨,安排發(fā)貨,更新會員記錄,歸檔會員資料,注冊新會員,訂貨,

15、接收貨物,發(fā)送貨物,庫存控制員,客戶服務助理,訂單處理員,為什么沒有客戶、公司？,33,(2) 描述用例-處理訂單的用例描述,34,(2) 描述用例-處理訂單的用例描述,35,(3) 進一步細化用例圖,檢查訂單狀態(tài),下訂單,處理訂單,處理退貨,安排發(fā)貨,更新會員記錄,歸檔會員資料,注冊新會員,訂貨,接收貨物,發(fā)送貨物,庫存控制員,客戶服 務助理,訂單處理員,搜索會員記錄,include,include,處理再訂購,36,(4) 用包封裝用例,檢查訂單狀態(tài),下訂單,處理訂單,處理退貨,安排發(fā)貨,更新會員記錄,歸檔會員資料,注冊新會員,訂貨,接收貨物,發(fā)送貨物,庫存控制員,客戶服 務助理,訂單處理

16、員,搜索會員記錄,include,include,會員,訂單處理,庫存控制,處理再訂購,37,例2 餐館預約系統(tǒng),(1) 記錄預約信息 (2) 取消預約 (3) 記錄顧客到來 (4) 調(diào)換餐桌 參與者: 招待員、領班,Record booking,Cancel booking,Record arrival,Table transfer,Receptionist,Head Waiter,記錄預約的用例: 一位顧客打電話進行定餐預約要求的日期和時間 及人數(shù)確定有合適的餐桌位置后,招待員輸入顧客性名 和電話并記錄預約。,餐館系統(tǒng)用例,38,記錄預約事件流: (1)招待員輸入要預定的日期; (2)系統(tǒng)

17、顯示該日的預約; (3)有合適的餐桌可用,招待員輸入顧客性名和電話、 時間; (4)系統(tǒng)記錄并顯示該預約。,記錄預約,沒有可用的餐桌:可選的事件流: (1)招待員輸入要求的預約的日期; (2)系統(tǒng)顯示該日的預約; (3)沒有合適的餐桌可用,用例結(jié)束。,39,記錄預約, 餐桌過小:例外的事件流: (1)招待員輸入要預定的日期; (2)系統(tǒng)顯示該日的預約; (3)招待員輸入顧客性名和電話,預約時間,用餐人數(shù)和 餐桌號; (4)用餐人數(shù)多于餐桌能容納的人數(shù),系統(tǒng)顯示警告并詢 問用戶是否繼續(xù)預約; (5)回答“否”,用例終止; (6)回答“是”,預約被輸入,并附有告警標志。,40,注意幾點:,(1)事

18、件流記錄用戶輸入到系統(tǒng)的信息,是用例的基本 部分,不是信息如何獲得的。不包含上下文的交互, 如招待員問顧客多少人。包含上下文信息,會使系 統(tǒng)的描述復雜,用例的復用性差。,(2)可選的事件流表示是允許中斷基本事件流,可能會 有另外的功能,如可能將顧客的請求輸入到一個等 待名單中。,(4)記住,招待員的職責就是是否能夠進行預約。,(3) 例外的事件流,產(chǎn)生誤解或發(fā)生了錯誤。,41,記錄到達(Record arrival)用例事件流: (1)侍者領班輸入當前日期; (2)系統(tǒng)顯示當天的預約; (3)侍者領班確定一個選定的預約己經(jīng)到達; (4)系統(tǒng)記錄并更新顯示顧客己到達。,記錄到達,無提前預定:可選

19、事件流 (1)侍者領班輸入當前日期; (2)系統(tǒng)顯示當天的預約; (3)系統(tǒng)未記錄該顧客的預約,侍者領班輸入預約時間、 用餐人數(shù)和餐桌號,創(chuàng)建一個未預約登記; (4)系統(tǒng)記錄并顯示新預約。,該可選事件流和記錄預約用例事件流存在共享功能, 應當有個顯示預約,可用下面用例包含關系描述:,42,顯示預約基本事件流:,Record booking,Receptionist,用例包含,Display booking,(1) 用戶輸入一個日期; (2) 系統(tǒng)顯示當日的預約;,記錄預約事件流(修改): (1)招待員執(zhí)行“顯示預約”用例; (2)招待員輸入顧客性名和電話,預約時間,用餐人數(shù)和餐桌; (3)系統(tǒng)

20、記錄并顯示新預約。,餐館系統(tǒng)用例,43,在記錄到達可選事件流中, 若系統(tǒng)未記錄一個顧客的 預約,侍者領班將創(chuàng)建一 個未預約登記。 這樣記錄到達用例和 記錄未預約顧客之間是有關系的。什么關系?,Record walk-in,Record arrival,Head Walk-in,extend,用例擴展,記錄未預約顧客:事件流 (1)侍者領班執(zhí)行“顯示預約“用例; (2)侍者領班輸入時間,人數(shù),餐桌號; (3)系統(tǒng)記錄并顯示新預約;,44,取消預約事件流: (1)招待員選擇要求的預約; (2)招待員取消該預約; (3)系統(tǒng)詢問接待員確認取消; (4)招待員回答“是”,系統(tǒng)記錄取消并更新顯示。,調(diào)換

21、餐桌事件流: (1)侍者領班選擇需要的預約; (2)侍者領班改變該預約的餐桌分配; (3)系統(tǒng)記錄改變并更新顯示。,45,Record booking,Display booking,Record arrival,Receptionist,staff,Head Waiter,整理后的用例圖:,Record walk-in,Cancel booking,Table transfer,確定參與者,確定用例,對用例進行基本事件流描述, 擴充用例事件流,畫出完整用例圖。,46,47,在圖書管理系統(tǒng)中，要為每個借閱者建立一個賬號， 并給借閱者發(fā)放借閱卡（借閱卡可以提供借閱卡號、借 閱者名），賬戶中存儲借

22、閱者的個人信息，借閱信息以 及預定信息。,例3 圖書管理系統(tǒng)的用例分析,描述如下：,持有借閱卡的借閱者可以 借閱書刊、 返還書刊、 查閱書刊信息、 預定書刊并取消預定，,但這些操作都是通過圖書管理員進行的，即借閱者 不直接與系統(tǒng)交互，而是圖書管理員充當借閱者的代理 與系統(tǒng)交互。,47,48,在借閱書刊時，需要輸入: 所借閱的書刊名、書刊的ISBN/ISSN號、借閱者的圖書 卡號和借閱者名，完成后提交所填表格，系統(tǒng)驗證借閱者 是否有效（在系統(tǒng)中存在賬號）。,若有效，借閱請求被接受，系統(tǒng)查詢數(shù)據(jù)庫系統(tǒng)，看借閱者所借閱的書刊是否存在，若存在，則借閱者可以借出書刊，建立并在系統(tǒng)中存儲借閱紀錄。,借閱者

23、還書后，刪除關于還書刊的借閱紀錄。 如果借閱者所借的書刊已被借出，借閱者還可預訂該書 刊，一旦借閱者預定的書刊可以獲得，就將書刊直接寄 給借閱人。 為了簡化系統(tǒng)，預定書刊獲得時就不通知借閱者了。 不考慮書刊的最長借閱期限，假設借閱者可以無限 期地保存所借閱的書刊。,48,49,對圖書館圖書管理系統(tǒng)的描述進行分析獲得如下 功能性需求： (1) 圖書管理員可以創(chuàng)建新的借閱者賬號； (2) 借閱者持有借閱卡（借閱者名和借閱卡號）； (3) 圖書管理員作為借閱者的代理借書； (4) 圖書管理員作為借閱者的代理預訂書刊； (5) 圖書管理員作為借閱者的代理取消預訂； (6) 圖書管理員作為借閱者的代理還

24、書； (7) 圖書管理員可以修改借閱者的賬戶信息； (8) 圖書管理員可以刪除已經(jīng)存在的借閱者賬戶； (9) 圖書管理員可以添加新的書刊種類； (10)圖書管理員可以修改書刊種類信息； (11)圖書管理員可以刪除系統(tǒng)中的書刊種類； (12)圖書管理員可以在系統(tǒng)中添加書刊的信息 （注意區(qū)分“書刊種類”和“書刊”）； (13)圖書管理員可以編輯書刊信息； (14)圖書管理員可以刪除書刊信息。,49,圖書管理員 登錄 管理讀者信息 管理圖書信息 登記借書 登記還書 登記預訂 登記取消預訂,借閱者： 登錄 預訂圖書 取消預訂 借閱圖書 還書 查詢?yōu)g覽圖書信息,例：一個圖書館管理系統(tǒng)，有哪些參與者和用例

25、？,用例,識別并描述參與者,50,圖書館管理系統(tǒng)用例圖,普通讀者,登錄,查詢?yōu)g覽,預訂圖書,圖書管理員,管理讀者,取消預訂,管理圖書信息,登記借書,登記還書,登記預訂,登記取消預訂,借書,還書,51,用例描述：登記借書,1. 描述： 本用例允許圖書管理員登記普通讀者的借書記錄 2 事件流： 2.1 常規(guī)流程 當讀者希望借書、圖書管理員準備登記有關的 借書記錄時，本用例開始執(zhí)行。 (1) 系統(tǒng)要求管理員輸入讀者的注冊號和所借圖書號； (2) 圖書管理員輸入信息后，系統(tǒng)產(chǎn)生一個唯一的借 書記錄號； (3) 系統(tǒng)顯示新生成的借書記錄； (4) 圖書管理員確認后，系統(tǒng)增加一個新的借書記錄。,52,用例

26、描述：登記借書,2.2 備選流程 (1) 讀者沒有注冊 在主流程中，如果系統(tǒng)沒有讀者的注冊信息， 系統(tǒng)將顯示錯誤信息，用例結(jié)束。 (2) 所借圖書不存在 在主流程中，如果所借圖書已被借出或者系 統(tǒng)中無該圖書，系統(tǒng)將顯示錯誤信息，用例結(jié)束。 3 前提條件：用例開始前，圖書管理員必須在系統(tǒng)登錄成功。 4 后置條件：如果用例執(zhí)行成功，該讀者的借書記錄被更新， 否則，系統(tǒng)狀態(tài)不變。,53,例4 大學選課系統(tǒng)-注冊討論班,大學選課系統(tǒng)與學生有著緊密的聯(lián)系，具有注冊交費、 選課、成績查詢等功能。為了簡化本次系統(tǒng)分析,只考慮 學生注冊討論班的功能，該問題描述如下：,問題描述,學生想要注冊某門討論班，于是向注

27、冊員提交其姓 名和學生編號； 注冊員驗證該學生是否有資格注冊這門討論班； 注冊員驗證后，提供討論班列表，并驗證是否適合學 生的課程安排； 注冊員統(tǒng)計費用并通知學生； 在學生確認后，注冊員將該學生注冊到討論班，并將 費用加入學生帳單； 注冊員向?qū)W生提供注冊成功的確認信息。,54,根據(jù)以上問題描述，該簡化系統(tǒng)具有如下功能：,學生搜索、注冊討論班； 驗證注冊資格； 顯示討論班及相關信息； 提供成績單； 結(jié)算并顯示帳單； 注冊成功； 關閉注冊；,55,(1) 注冊討論班； (2) 退出討論班； (3) 參加討論班； (4) 完成討論班； (5) 通知學生計 劃改變；,識別用例,有如下用例：,(6) 分

28、發(fā)成績單； (7) 輸出收費計劃表； (8) 輸入成績； (9) 指導討論班； (10)生成教學進度。,識別參與者（角色）,學生： 在系統(tǒng)中申請注冊討論班的人； 注冊員:完成驗證注冊信息的人或外部系統(tǒng)； 教授： 指導或協(xié)助討論班和管理學生成績。,56,學生注冊系統(tǒng)用例圖,學生,注冊討論班,登錄,生成教學計劃,教授,注冊員,財務系統(tǒng),維護學生信息,關閉注冊,課程目 錄系統(tǒng),指導討論班,提交成績,退出討論班,完成討論班,維護教授信息,收費計劃表,通知學生 計劃改變,用例圖：,57,58,注冊討論班用例的文字描述,名稱：注冊討論班。 描述：把現(xiàn)有的有資格的某一學生注冊到某個討論班。 前提條件：學生已

29、在大學注冊。 后置條件：若學生具有注冊資格，并且該討論班仍有 空位，則學生注冊到該討論班 。,(1) 學生想要注冊某個討論班 (2) 學生向注冊員提交其姓名和學生編號,活 動 的 基 本 過 程,(3) 注冊員根據(jù)業(yè)務規(guī)則“BR129確定是否有資格注 冊”確定該學生是否有資格在這所學校注冊了這 門討論班,(5) 注冊員根據(jù)業(yè)務規(guī)則“BR130驗證學生是否有資 格注冊討論班”，驗證學生是否有資格注冊該課。,(4) 學生從可供選擇的討論班列表中，選出希望注 冊的討論班,59,(6) 注冊員根據(jù)業(yè)務規(guī)則“BR143驗證學生討論班課 程安排”，驗證這個討論班是否適合該學生現(xiàn) 有的課程安排,活 動 的

30、基 本 過 程,(7) 注冊員根據(jù)討論班目錄中公布的費用，使用的 學生費用和使用的稅，計算出這門課的收費， 應用業(yè)務規(guī)則“BR180計算學生費用”和“BR45 計算課程稅”,(12) 注冊員根據(jù)業(yè)務規(guī)則“BR100學生討論班記帳”， 把相應費用加到學生帳單中,(8) 注冊員通知學生相關費用 (9) 注冊員確認學生表示愿意注冊該討論班,(10) 學生表示愿意注冊該討論班 (11) 注冊員把學生注冊到該討論班,(13) 注冊員向?qū)W生提供已經(jīng)注冊成功的確認 (14) 學生得到確認信息時,用例結(jié)束。,60,A.1 注冊員確定學生沒有資格注冊討論班。 A.2 注冊員通知學生，他沒有資格注冊。 A.3 用

31、例結(jié)束(不能繼續(xù)執(zhí)行了)。,候選過程A：學生沒有資格注冊討論班,B.1 注冊員確定學生沒有資格注冊該討論班。 B.2 注冊員通知學生，他不具備注冊這一討論班所 需要的必備條件。 B.3 注冊員通知學生，他需要具備的必備條件。 B.4 用例從活動基本過程中的步驟4繼續(xù)執(zhí)行。,候選過程B：學生不具備注冊這一討論班所需要的必備條件,C.1 學生查看討論班列表，但沒有找到他想要注冊的。 C.2 用例結(jié)束。,候選過程C：學生決定不注冊討論班(有討論班可供選擇),例5 購買商品用例舉例,用例: 購買商品 參與者: 顧客、出納員 類型: 主要/次要/供選擇 基本的/真實的 描述: 顧客帶著所購實的商品來到收

32、款處, 出納員記錄下商品信息并收款,付款完成后, 顧客帶著所購實的商品離開。,61,購買商品,從基本用例出發(fā),快速獲得對 系統(tǒng)整個過程的理解。,顧客,擴展用例(expanded use case),用例: 用現(xiàn)金購買商品 參與者:顧客(發(fā)起者)、出納員 目的: 記錄銷售過程和支付過程 類型: 主要的和基本的 描述:,62,顧客帶著所購實的商品來到收款處, 出納員記錄下商品信息并收現(xiàn)款, 付款完成后, 顧客帶著所購實的商品離開。,典型的事件發(fā)生過程,(1)一個顧客帶著所購買的商品到達一個銷售點終端, 用例開始。,63,(5)計算和顯示該顧客的商品價值總額。 (6)出納員將商品價值總額報告給顧客。

33、,(2)出納員錄入每項商品的商品號。若出現(xiàn)多個不同的 商品,出納員還要錄入該商品的數(shù)量。,(3)確定商品價格,并將商品信息輸入到正在運行的銷 售事務處理系統(tǒng),顯示當前的商品信息和商品價格。,(4)輸入完商品信息后,出納員向POST發(fā)出提示,提示 商品信息錄入完畢。,(參與者動作),(參與者動作),(參與者動作),(系統(tǒng)響應),(系統(tǒng)響應),(參與者動作),(7) 出納員接收顧客的付款-顧客的付款可能高于商品 總額。,(8) 出納員錄入顧客所付的現(xiàn)款總額。,64,可供選擇的過程,(1) 輸入的商品號無效,系統(tǒng)顯示出錯信息。,(2) 顧客沒有足夠的現(xiàn)金來購買所選的商品,取消本次 交易。,(9) 顯

34、示出應找還給顧客的款額。,(12)顧客帶著所購買的商品離開。,(10)出納員收好現(xiàn)金并取出要找還給顧客的現(xiàn)金,將現(xiàn)金 及打印的付款收據(jù)交給顧客。,(11)記錄這次交易。,(動作),(響應),(動作),(響應),(動作),(動作),用例可以有判定點。在購買商品用例中, 顧客的付款方式可以選擇:,現(xiàn)金支付 信用卡支付 支票支付 可分別闡述事件發(fā)生的過程,65,現(xiàn)金支付(Pay by Cash) 的事件發(fā)生過程,(1)顧客用現(xiàn)金支付商品, 支付的金額可能大于 商品的價值,66,可供選擇的過程: (1)顧客沒有足夠的現(xiàn)金,可能取消交易或用另一種方式支付 (4)出納員無零錢找,請管理員幫忙或顧客重新支付

35、,(3)顯示找給顧客的余額,2)系統(tǒng)響應,(4)出納員收好顧客所支 付的現(xiàn)金數(shù),取出應 找回給顧客的余額, 并交給顧客,(2)出納員記錄顧客所支 余付的現(xiàn)金數(shù),1) 參與者的動作,信用卡支付(Pay by Credit)的事件發(fā)生過程,(1)顧客提供他的 信用卡信息,67,可供選擇的過程: (3)信用卡支付請求被拒絕,要求顧客采用其他支付方式,(2)產(chǎn)生一個信用卡支付請求并將 其發(fā)送到外部信用卡授權機構 (CAS),(3)信用卡授權機構 授權這次支付,1)參與者的,2)系統(tǒng)響應,(4)接收來自CAS的信用卡批準信息 (5)發(fā)送信用卡支付信息和批準應 答信息到應收款系統(tǒng) (6)顯示授權成功信息,

36、支票支付(Pay by Check)的事件發(fā)生過程,(1)顧客填寫支票、簽名并 出示標識自己的證件。,68,可供選擇的過程:,1)參與者的動作 2)系統(tǒng)響應,(3)產(chǎn)生一個支票支付請求， 并將其發(fā)送到外部支票 授權請求服務機構。,(2)出納員記錄這些標識信 息并發(fā)出一個支票支付。,(4)支票授權機構授權了這 次支付。,(4)支票支付請求被拒絕,要求顧客采用其他支付方式。,(5)接收來自授權機構的信 用卡批準應答信息。,(6)顯示授權成功信息。,還有哪些情況沒考慮?(規(guī)定和假設),沒有庫存管理。 商店是個獨立的商店,不是連鎖店。,69,系統(tǒng)中不記錄顧客購物習慣信息。 對裝現(xiàn)金的抽屜無控制。,手工

37、錄入商品的UPC,無條形碼讀碼機。 不記稅。,商品不打折。 出納員不一定非要登錄進入系統(tǒng),無訪問控制。,商店的名稱、地址、交易時間和日期打印在收據(jù)上。 出納員的ID和POST的ID不打印在收據(jù)上。 己完成的購物交易記錄在一個歷史日志當中。,例6 計算機管理信息系統(tǒng)用例,用戶管理：管理員和一般用戶，權限管理。,計算機基本信息管理：錄入、修改、刪除、 測覽、查詢等。,計算機購置管理：購置申請、審批等。,計算機調(diào)撥管理：調(diào)撥申請、審批等。,計算機報廢管理：報廢申請、審批等。,信息查詢管理：品牌、型號一、產(chǎn)地等。,70,71,計算機管理信息系統(tǒng)用例圖,研究窒,系統(tǒng)管理員,此例的extend能否用inc

38、lude替換?,72,登錄 管理,信息查 詢管理,查詢購置 申請信息,添加購置 申請信息,基本信 息管理,經(jīng)理,include,計算機購置管理用例圖,購置申 請管理,刪除購置 申請信息,修改購置 申請信息,購置申 請審批,extend,include,include,include,include,include,include,extend,研究窒,73,登錄 管理,信息查 詢管理,查詢調(diào)撥 申請信息,添加調(diào)撥 申請信息,計算機基 本信息管理,經(jīng)理,include,計算機調(diào)撥管理用例圖,調(diào)撥申 請管理,刪除調(diào)撥 申請信息,修改調(diào)撥 申請信息,調(diào)撥申 請審批,extend,include,include,include,include,include,include,extend,研究窒,74,登錄 管理,信息查 詢管理,查詢報廢 申請信息,添加報廢 申請信息,計算機基 本信息管理,經(jīng)理,includ