餐館系統(tǒng)的業(yè)務(wù)建模教學(xué)

1、第第4章章 餐館系統(tǒng)的餐館系統(tǒng)的業(yè)務(wù)建模業(yè)務(wù)建模4.1 非正式的需求 通過改進(jìn)為顧客預(yù)定和分配餐桌的過程，支持一家餐館的日常經(jīng)營 預(yù)約單中每一行對應(yīng)餐館中一張?zhí)囟ǖ牟妥?。預(yù)約是對特定的一個餐桌登記的，每個預(yù)約中記錄有“餐具”的數(shù)目，或者預(yù)期進(jìn)餐者的數(shù)目，這樣就能夠分配一個大小適當(dāng)?shù)牟妥馈?這家餐館在晚間供應(yīng)三次餐點(diǎn)，稱為“簡餐”、“正餐”和“夜點(diǎn)”時段?？梢灶A(yù)約跨多個時段的時間。 每個預(yù)約中要記錄聯(lián)系人的姓名和電話。 修改餐桌、電話取消預(yù)定、未預(yù)約的顧客處理4.1.1 對計(jì)算機(jī)化系統(tǒng)的需要 手工系統(tǒng)有很多問題：速度慢、預(yù)約單很快變亂、沒有備份系統(tǒng)、獲取管理數(shù)據(jù)不方便 新系統(tǒng)應(yīng)該和現(xiàn)有的預(yù)約單顯

2、示同樣的信息，并且有大致相同的格式，使餐館員工易于轉(zhuǎn)換到新系統(tǒng)。 記錄新的預(yù)約和修改已有預(yù)約之后應(yīng)該立即更新顯示，使餐館員工在工作時總能使用可獲得的最新信息 系統(tǒng)必須易于記錄餐館營業(yè)時發(fā)生的有意義的事情4.1.1 定義一次迭代 一個系統(tǒng)的第一次迭代應(yīng)該只交付足夠使系統(tǒng)提供某些確實(shí)有商業(yè)價值的核心功能 在隨后的迭代中再開發(fā)其他功能4.2 用例建模 用例視圖是UML中起著支配作用的視圖，描述的系統(tǒng)外部可見的行為 基于系統(tǒng)需求的用例視圖驅(qū)動和約束著后續(xù)的開發(fā) 用例視圖展示的是系統(tǒng)功能的結(jié)構(gòu)化視圖，視圖定義了參與者和參與者可以參與的用例 參與者模型化了用戶與系統(tǒng)進(jìn)行交互時可能充當(dāng)?shù)慕巧?用例描述了用戶

3、使用系統(tǒng)能夠完成一項(xiàng)特定的任務(wù) 用例視圖應(yīng)該包含一組定義了該系統(tǒng)完整功能的用例，或者至少定義了當(dāng)前迭代所規(guī)定功能的用例 用例視圖應(yīng)該是客戶、最終用戶、領(lǐng)域?qū)＜?、測試人員和任何其他涉及系統(tǒng)的人員，不需要詳細(xì)了解系統(tǒng)結(jié)構(gòu)和實(shí)現(xiàn)就容易理解的4.2.1 用例 一組用例是一個系統(tǒng)的用戶能夠使用系統(tǒng)完成的不同任務(wù) 可以通過考慮在系統(tǒng)實(shí)現(xiàn)后餐館員工能夠用它來做什么，簡單地草擬出這次迭代的一組初步的用例 這些用例所支持的主要任務(wù)： (1)記錄一個新的預(yù)約信息(“記錄預(yù)約”) (2)取消一個預(yù)約(“取消預(yù)約”) (3)記錄一位顧客的到來(“記錄到達(dá)”) (4)將一位顧客從一張餐桌移到另一張餐桌(“調(diào)換餐桌”)

4、一個用例描述了系統(tǒng)能夠?yàn)橐粋€特定的用戶做些什么，描述的是一個自包含的任務(wù)4.2.2 參與者 一個用例描述了系統(tǒng)及其用戶之間的一類交互 系統(tǒng)通常有不同種類的用戶，他們能夠執(zhí)行系統(tǒng)功能的不同子集 人與系統(tǒng)在進(jìn)行交互時能夠擔(dān)任的不同角色稱為參與者 餐館預(yù)約系統(tǒng)中用例可以分為兩組： (1)維護(hù)提前預(yù)約信息有關(guān)的用例 (2)需要在餐觀營業(yè)時執(zhí)行的任務(wù) 參與者和用戶之間不存在一對一的對應(yīng)4.2.3 用例圖 以圖解的形式概括了系統(tǒng)中不同參與者和用例，并顯示了哪些參與者能夠參與哪些用例 參與者用一個像人一樣的圖標(biāo)表示 用例用包含有用例名字的橢圓表示 UML允許在用例圖中包含更多的結(jié)構(gòu)，來定義用例之間以及參與者

5、之間的各種關(guān)系 在實(shí)踐中不值得花費(fèi)很多時間細(xì)化用例圖，額外的關(guān)系對后面的開發(fā)起不到很大作用Record bookingCancel bookingRecord arrivalTable transferReceptionistHead Waiter初始用例圖4.3 描述用例 用例描述了系統(tǒng)和它的用戶之間在一定層次上的完整的交互 在用例的不同實(shí)例中將發(fā)生什么樣的細(xì)節(jié)，會在很多方面有所不同 一個用例實(shí)例中可能會出現(xiàn)差錯，將不能達(dá)到原來的目的 一個用例的完整描述必須指明，在用例所有可能的實(shí)例中可能發(fā)生什么 用例描述可能包含大量信息，需要某種系統(tǒng)的方法來記錄這些信息 UML沒有定義一種描述用例的標(biāo)準(zhǔn)形

6、式 許多開發(fā)人員定義了用例描述的模板4.3.1 事件路徑 用例描述必須定義在執(zhí)行用例時用戶和系統(tǒng)之間可能的交互 基本事件路徑：用例的主要目標(biāo)可以沒有任何問題并且不中斷地到達(dá) 可選的事件路徑：一些可選的功能會被調(diào)用 例外的事件路徑：發(fā)生錯誤時的處理 記錄預(yù)約：基本事件路徑 (1)接待員輸入要預(yù)約的日期； (2)系統(tǒng)顯示該日的預(yù)約； (3)有一張合適的餐桌可以使用：接待員輸入顧客的姓名和電話號碼、預(yù)約的時間、用餐人數(shù)和餐桌號； (4)系統(tǒng)記錄并顯示該預(yù)約。 事件路徑要記錄的重要事情是用戶輸入到系統(tǒng)的信息，而不是該信息是如何獲得的。 包含上下文的交互會降低用例的可復(fù)用性 記錄預(yù)約沒有可用的餐桌：可選

7、事件路徑 (1)接待員輸入要求預(yù)約的日期 (2)系統(tǒng)顯示該日的預(yù)約 (3)沒有合適的餐桌可以使用，用來終止 可選事件路徑描述的情況，可以作為營業(yè)的一個正常部分出現(xiàn)，它們并沒有指出產(chǎn)生了誤解，或者發(fā)生了錯誤 因?yàn)橐粋€錯誤和用戶的疏忽而不可能完成基本事件路徑，這些情況將由例外事件路徑描述 記錄預(yù)約餐桌過?。豪馐录窂?(1)接待員輸入要求預(yù)約的日期 (2)系統(tǒng)顯示該日的預(yù)約 (3)接待員輸入顧客的姓名和電話號碼、預(yù)約的時間、用餐人數(shù)和餐桌號 (4) 輸入的預(yù)約用餐人數(shù)多于餐桌能容納的人數(shù)，于是系統(tǒng)發(fā)出一個警告信息詢問用戶是否想要繼續(xù)預(yù)約 (5)如果回答“否”，用例將不進(jìn)行預(yù)約而終止 (6)如果回

8、答“是”，預(yù)約將被輸入，并附有一個警告標(biāo)志 不同類型的事件路徑之間區(qū)分是非正式的，它可以使用例的總體描述組織得更容易理解 不值得花過多時間去決定一個特定的情況是可選的還是例外的，更重要的是一定要確認(rèn)給出了必須行為的詳細(xì)描述4.3.2 用戶界面原型 在用例描述中詳述用戶界面不是個好主意 用例描述的重點(diǎn)是定義系統(tǒng)和用戶之間交互的總體結(jié)構(gòu)，而包含用戶界面的細(xì)節(jié)會使之不清晰 對用戶界面像什么樣子有一個大概的看法，可能會有助于理解用例描述Booking Date: 10 Feb 2004Booking System 18 :30 19 :30 20 :30 21 :30 22 :30 23 :30 24

9、12345預(yù)約系統(tǒng)主屏幕的一個原型Ms Blue 0121 7648 4495Covers: 3Mr White 0865 364795Covers: 2Covers: 4Covers: 2Mr Black 020 8453 7646Walk-in4.4組織用例模型 記錄到達(dá)：基本事件路徑 (1)侍者領(lǐng)班輸入當(dāng)前日期 (2)系統(tǒng)顯示當(dāng)天的預(yù)約 (3)侍者領(lǐng)班確認(rèn)一個選定的預(yù)約已經(jīng)到達(dá) (4)系統(tǒng)對此進(jìn)行記錄并更新顯示器，將顧客標(biāo)記為已到達(dá) 記錄到達(dá)沒有提前預(yù)定：可選事件路徑 (1)侍者領(lǐng)班輸入當(dāng)前日期 (2)系統(tǒng)顯示當(dāng)天的預(yù)約 (3)系統(tǒng)中沒有記錄該顧客的預(yù)約，所以侍者領(lǐng)班輸入預(yù)約時間、用餐人

10、數(shù)和餐桌號，創(chuàng)建一個未預(yù)約的登記 (4)系統(tǒng)記錄并顯示新預(yù)約4.4.1 用例包含 顯示預(yù)約：基本事件路徑 (1)用戶輸入一個日期 (2)系統(tǒng)顯示當(dāng)日的預(yù)約 記錄預(yù)約：基本事件路徑(修改) (1)接待員執(zhí)行“顯示預(yù)約”用例 (2)接待員輸入顧客姓名和電話號碼、預(yù)定的時間、用餐人數(shù)以及預(yù)留的餐桌 (3)系統(tǒng)記錄和顯示新預(yù)約Record bookingDisplay bookingReceptionist用例包含4.4.2 參與者泛化 參與者之間泛化的含義是，特化的參與者可以參與和更一般的參與者關(guān)聯(lián)的所有用例 可以指派給特化的參與者更多的責(zé)任Display bookingRecord booking

11、Record arrivalReceptionistStaffHead Waiter參與者泛化4.4.3 用例擴(kuò)展 記錄未預(yù)約顧客：基本事件路徑 (1)侍者領(lǐng)班執(zhí)行“顯示預(yù)約”用例 (2)侍者領(lǐng)班輸入時間、用餐人數(shù)和分配給顧客的餐桌 (3)系統(tǒng)記錄并顯示新預(yù)約 包含依賴性對這種情況并不適合，因?yàn)樵凇坝涗浳搭A(yù)約顧客”中指定的交互不是在每次執(zhí)行“記錄到達(dá)”時都執(zhí)行“記錄未預(yù)約顧客”用例只是在 “記錄到達(dá)”的某些情況下被執(zhí)行Record walk-inRecord arrivalReceptionist用例擴(kuò)展4.5 完成用例模型 取消預(yù)定：基本事件路徑 (1)接待員選擇要求的預(yù)約 (2)接待員取消

12、該預(yù)約 (3)系統(tǒng)詢問接待員確認(rèn)取消 (4)接待員回答“是”，系統(tǒng)記錄取消并更新顯示 這個事件路徑?jīng)]有清楚地詳細(xì)說明用戶如何完成這些任務(wù)，這為系統(tǒng)能提供多種方式完成該任務(wù)留下的不受限制的可能性 調(diào)換餐桌：基本事件路徑 (1)侍者領(lǐng)班選擇需要的預(yù)約 (2)侍者領(lǐng)班改變該預(yù)約的餐桌分配 (3)系統(tǒng)記錄改變并更新顯示 可選和例外事件路徑可以從餐館的經(jīng)營規(guī)則得到：和取消一樣，應(yīng)該不可能將一個過期的預(yù)約調(diào)換到新餐桌，也應(yīng)該不可能將一個預(yù)約移到已占用的餐桌4.5.1 一個用例模型何時完成 用例分析是一項(xiàng)非正式的技術(shù)，在一定時間之后再花時間尋求對模型的改進(jìn)時會降低回報 這對包含關(guān)系和擴(kuò)展關(guān)系尤其適用：這些關(guān)

13、系通常與從用例產(chǎn)生的設(shè)計(jì)的結(jié)構(gòu)特性并不相當(dāng)，所以缺少一個可能的依賴的后果并不嚴(yán)重Record bookingCancel bookingDisplay bookingsReceptionistRecord arrivalRecord walk-inStaffTable transferHead Waiter完成的用例圖4.6 領(lǐng)域建模 領(lǐng)域模型：顯示最重要的業(yè)務(wù)概念和它們之間的關(guān)系的類圖 領(lǐng)域模型用關(guān)聯(lián)和泛化顯示了這些概念之間的關(guān)系。領(lǐng)域模型通常不包含操作 有時很難決定是應(yīng)該將一個特殊的信息作為一個類還是作為一個屬性包含在領(lǐng)域模型中規(guī)定關(guān)聯(lián)的重?cái)?shù)，每個預(yù)定是由一個顧客進(jìn)行的，這個人的姓名和電話

14、由系統(tǒng)記錄，但是每個顧客可以進(jìn)行多個預(yù)定CustomerReservationMakes1*namephoneNumber顧客和預(yù)定建模CustomerReservationMakes1*namephoneNumbercoversdatetimeTableplaces1* Reservations for the same table must not overlap.包含預(yù)定特性的領(lǐng)域模型CustomerMakes1*coversReservationWalk-inBookingdatetimeplacesTable*1 Bookings for the same table must no

15、t phoneNumber包含未預(yù)約的領(lǐng)域模型4.6.1 領(lǐng)域模型的正確性 要證明一個模型的正確性或者即使是一個模型優(yōu)于另一個模型，要更困難一些 建立領(lǐng)域模型的目的是確定一組對象，他們能夠以有效地支持整個系統(tǒng)必須交付的功能的方式進(jìn)行交互。因此，要評價領(lǐng)域模型中可供選擇的方式，可以從實(shí)現(xiàn)這一點(diǎn)的程度來進(jìn)行 而且不能通過孤立地檢查領(lǐng)域模型而簡單地評定，還必須通過觀察領(lǐng)域模型中類的實(shí)例之間的交互實(shí)際上是如何支持需要的功能，考慮模型實(shí)際上表達(dá)了什么4.7 術(shù)語表 預(yù)約(Booking)：分配一張餐桌給一行用餐者進(jìn)餐 用餐人數(shù)(Covers)：預(yù)定將來用餐的人數(shù) 顧客(Custo

16、mer)：進(jìn)行預(yù)定的人 用餐者(Diner)：在餐館用餐的人 位子(Places)：在一張?zhí)囟ú妥滥軌蚓妥挠貌驼呷藬?shù) 預(yù)定(Reservation)：提前預(yù)約一個特定時間的餐桌 未預(yù)約(Walk-in)：沒有提前進(jìn)行的預(yù)約4.8 本章小結(jié) 在業(yè)務(wù)建?；顒咏Y(jié)束時，系統(tǒng)文檔包含一個用例模型、對各個用例的文字描述、一個關(guān)鍵術(shù)語的術(shù)語表以及一個領(lǐng)域模型 用例圖描述了參與者和用例以及他們之間的各種關(guān)系 用例表示了一類用戶可以利用系統(tǒng)完成的典型任務(wù) 參與者表示了用戶在與系統(tǒng)交互時可以充當(dāng)?shù)慕巧⑴c者和用例的關(guān)聯(lián)，表示以給定角色工作的用戶能夠執(zhí)行哪些任務(wù)。參與者可以通過泛化相關(guān)，以明確地表示它們共享的能力 一個用例可以包含另一個用例：意思是被包含用例規(guī)定的交互構(gòu)成