某企業為了便捷職工就餐，為飯店開發了一個訂餐系統（COS:),企業職工可通過企業內聯網使用該系統。
企業的任何職工都可以查看菜單和明日特惠。
系統的客戶是注冊到系統的職工大學外賣小程序，可以訂餐（假如未登陸，需先登入)、注冊薪水支付、預約規律的訂餐，在特殊情況下可以覆蓋預訂。
飯店職工是特殊客戶，可以進行備餐、生成付費懇求和懇求送餐，其中對于注冊薪水支付的客人生成付費懇求并發獻給薪資系統。
菜單管理員是飯店特定職工，可以管理菜單。
送餐員可以復印送餐說明，記錄送餐信息（如送餐時間）以及記錄收費（對于沒有注冊薪資支付的客人，由送餐員繳納現金雜記錄）。
客戶訂餐過程如下：
客戶懇求查看菜單；系統顯示菜單和明日特惠；客戶選菜；系統顯示訂單和價錢；客戶確認訂單；系統顯示可送餐時間；客戶指定送餐時間、地點和支付方法；系統確認接受訂單，之后發送E-mail給客人以確認訂餐，同時發送相關訂餐信息通知給飯店職工。
系統采用面向對象方式開發，使用UML進行建模。系統的頂樓用例圖和一次訂餐的活動圖定稿分別如右圖（a)和（b)所示。
【問題1】
按照說明中的描述，給出圖(a)中A1和A2所對應的參與者。
【問題2】
按照說明中的描述，給出圖(a)中缺乏的四個用例及其所對應的參與者。
【問題3】
按照說明中的描述,給出圖(b)中（1)?（4)處對應的活動名稱或圖形符號。
【問題4】
強調圖（a)中職工和客戶之間是哪些關系，并解釋該關系的內涵。
答案：
【問題1】
A1：薪資系統
A2：菜單管理員
【問題2】
用例名參與者
查看當天特惠
職工
注冊薪水支付
客戶和薪資系統
生成付費懇求
飯店職工和薪資系統
管理菜單
菜單管理員
【問題3】
（1）
（2）登陸
（3）
（4）
【問題4】
泛化關系（通常/特殊關系、繼承關系）。泛化關系描述了一個參與者可以完成另一個參與者同樣的任務，并可以補充額外的角色功能。
解析：
【問題1】
辨識參與者時，考查和系統交互的人員和外部系統。本題中大學外賣小程序，與系統交互的人員包括職工、注冊到系統的職工(客戶)、餐廳職工、菜單管理員、送餐員以及薪資系統。
由“菜單管理員是飯店特定職工”以及圖中A2和圖中餐館職工之間的“是一種”關系可知，A2為菜單管理員;圖中還缺乏描述中與薪資系統的交互，由“……并發獻給薪資系統”可知，A1為薪資系統。
【問題2】
考查用例及其和參與者之間的關系時，通過判定哪一個特定參與者發起或則觸發了與系統的什么交互，來辨識用例并完善和參與者之間的關聯。
本題中，由“任何職工都可以查看菜單和明日特惠”可知，圖中缺乏用例查看明日特惠，對應參與者是職工；由“系統的客戶是……，注冊薪資支付、……"可知，圖中缺乏用例注冊薪資支付，對應參與者是客戶和薪資系統；由“餐廳職工是……，可以進行備餐、生成付費懇求……發送給薪水系統”可知，圖中缺乏用例“生成付費懇求”，對應的參與者是飯店職工和薪資系統；由“菜單管理員是飯店特定職工，可以管理菜單”可知，圖中缺乏用例管理菜單，對應的參與者是菜單管理員。
須要注意的是，在注冊薪資支付所對應的參與者中，盡管沒有明晰說明要和薪資系統交互，并且由“對于注冊薪水支付的客人生成付費懇求并發獻給薪資系統”可知，薪水支付是由薪資系統控制，所以注冊也須要和薪資系統交互。
【問題3】
在客戶訂餐過程的描述中，在“顧客選菜”之前，圖中缺乏符號和活動。由說明中客戶“可以訂餐(假如未登入，需先登入)”可以判定，在系統“顯示菜單和明日特惠"然后"客人選菜”之前，須要判定(判斷符號)當前用戶身分是否為客人，倘若不是，需先登入；由“……發送E-mail給客人以確認訂餐，同時發送相關訂餐信息通知給飯店職工”可知，發送E-mail和通知飯店職工為并行活動，須要在前后有同步條(或橫向)。
【問題4】
參與者之間的關系表示子類型是一種父類型，即泛化關系。其中父類型一般是一個具象泛化的參與者,可以完成子類型可完成的共同行為，每位具體的子類型承繼它，可以完成父類型參與者同樣的任務，并可以補充額外的角色功能。
免責聲明：部分文章信息來源于網絡以及網友投稿，本站只負責對文章進行整理、排版、編輯，出于傳遞更多信息之目的，并不意味著贊同其觀點或證實其內容的真實性，如本站文章和轉稿涉及版權等問題，請作者在及時聯系本站，我們會盡快為您處理。
