第4章餐館訂餐系統(tǒng)的業(yè)務(wù)模型

1、軟件開發(fā)的早期階段輸入: 非形式化的規(guī)格說明活動: 創(chuàng)建用例模型（use case model） 創(chuàng)建領(lǐng)域模型（domain model） 創(chuàng)建詞匯表（ glossary）4.1 建立用例模型 4.1.1 非正式的需求 4.1.2 用例建模 4.1.3 描述用例（系統(tǒng)的用例編寫，基本的事件路徑） 4.1.4 組織用例模型（調(diào)整優(yōu)化用例圖） 4.1.5 完成用例模型（用例圖的第二次迭代）4.2 建立領(lǐng)域模型4.3 建立詞匯表4.1 建立用例模型 4.1.1 非正式的需求 4.1.2 用例建模 4.1.3 描述用例（系統(tǒng)的用例編寫，基本的事件路徑） 4.1.4 組織用例模型（調(diào)整優(yōu)化用例圖） 4.

2、1.5 完成用例模型（用例圖的第二次迭代）4.2 建立領(lǐng)域模型4.3 建立詞匯表4.1 建立用例模型 4.1.1 非正式的需求 4.1.2 用例建模 4.1.3 描述用例（系統(tǒng)的用例編寫，基本的事件路徑） 4.1.4 組織用例模型（調(diào)整優(yōu)化用例圖） 4.1.5 完成用例模型（用例圖的第二次迭代）4.2 建立領(lǐng)域模型4.3 建立詞匯表 采用手工預(yù)約單：預(yù)約的信息 姓名和電話號碼 就餐者人數(shù)調(diào)換餐桌取消預(yù)約作注釋未預(yù)約顧客（Walk-in） 就餐人數(shù)4.1 建立用例模型 4.1.1非正式的需求 4.1.2 用例建模 4.1.3 描述用例（系統(tǒng)的用例編寫，基本的事件路徑） 4.1.4 組織用例模型（

3、調(diào)整優(yōu)化用例圖） 4.1.5 完成用例模型（用例圖的第二次迭代）4.2 建立領(lǐng)域模型4.3 建立詞匯表第一次迭代應(yīng)該只交付足夠使系統(tǒng)提供某些確實有商業(yè)價值的核心功能。定義基本功能建立初始用例圖系統(tǒng)應(yīng)取代手工預(yù)約單l1.識別用例的步驟用例的步驟找出系統(tǒng)邊界和范圍識別參與者確定每個參與者所期望的系統(tǒng)行為找出用例l2.定義初始用例圖用例圖l考慮構(gòu)造系統(tǒng)時，你所需要做的第一件事情是確定系統(tǒng)的邊界在哪里，需要定義什么是系統(tǒng)的組成部分（系統(tǒng)的邊界內(nèi)）和什么是系統(tǒng)的外部（系統(tǒng)邊界外）。l系統(tǒng)邊界是定義由誰或什么（參與者）使用系統(tǒng)，系統(tǒng)能夠為哪些參與者提供什么特定利益（用例）。l系統(tǒng)邊界繪制為方框，標(biāo)有系統(tǒng)名

4、稱，參與者繪制在邊界外部，用例繪制在邊界內(nèi)部。 l誰或什么使用該系統(tǒng)？l誰對某個特定功能感興趣？l誰負(fù)責(zé)支持和維護(hù)系統(tǒng)？l系統(tǒng)有哪些外部資源？其它還有哪些系統(tǒng)將需要與該系統(tǒng)進(jìn)行交互？人與系統(tǒng)進(jìn)行交互時能夠擔(dān)任的不同角色 eg: 接待員Receptionist (makes bookings) 領(lǐng)班Head waiter (assigns tables etc)一個用戶在不同的時間可以扮演一個或多個角色顧客不是參與者建立一組用例，使系統(tǒng)的用戶能夠使用系統(tǒng)完成的不同的任務(wù)。餐館預(yù)約系統(tǒng)需完成的主要任務(wù):1 記錄一個新的預(yù)約信息2 取消一個預(yù)約信息3 記錄一位顧客的到來4 將一位顧客的餐桌從一張餐桌

5、移到另一張餐桌（“調(diào)換餐桌”）以圖解的形式概括系統(tǒng)中的不同參與者和用例，并顯示哪些參與者能夠參與哪些用例。4.1 建立用例模型 4.1.1非正式的需求 4.1.2 用例建模 4.1.3 描述用例（系統(tǒng)的用例編寫，基本的事件路徑） 4.1.4 組織用例模型（調(diào)整優(yōu)化用例圖） 4.1.5 完成用例模型（用例圖的第二次迭代）4.2 建立領(lǐng)域模型4.3 建立詞匯表用例描述模板，見上章用例描述沒有統(tǒng)一的標(biāo)準(zhǔn)模板，可采用與項目一致的格式。從實用上，應(yīng)更重視編寫完整的和可理解的事件路徑事件路徑，而不是按指定的模板填寫每個部分。正常交互的情況下的路徑不中斷。 記錄預(yù)約1 接待員輸入要預(yù)約的日期2 系統(tǒng)顯示該日

6、的預(yù)約3 有一張合適的餐桌可以使用：接待員輸入顧客的姓名、電話、預(yù)約的時間、用餐人數(shù)和餐桌號4 系統(tǒng)記錄并顯示新預(yù)約。記錄預(yù)約沒有可用的餐桌:1 接待員輸入要求的預(yù)約日期；2 系統(tǒng)顯示該日的預(yù)約；3 沒有合適的餐桌可以使用，用例終止記錄預(yù)約餐桌過小1 接待員輸入要求的預(yù)約日期；2 系統(tǒng)顯示該日的預(yù)約；3 接待員輸入顧客的姓名電話預(yù)約時間，用餐人數(shù)和餐桌號4 用餐人數(shù)多于餐桌容納的人數(shù)，系統(tǒng)詢問是否繼續(xù)預(yù)約5 如果回答 “否”, 用例將不進(jìn)行預(yù)約而終止6 如果回答“是”, 預(yù)約將被輸入，并附有一個警告標(biāo)志。When writing use cases, it is useful to have

7、a rough idea of the planned user interface4.1 建立用例模型 4.1.1非正式的需求 4.1.2 用例建模 4.1.3 描述用例（系統(tǒng)的用例編寫，基本的事件路徑） 4.1.4 組織用例模型（調(diào)整優(yōu)化用例圖） 4.1.5 完成用例模型（用例圖的第二次迭代）4.2 建立領(lǐng)域模型4.3 建立詞匯表記錄到達(dá)：基本事件路徑（）領(lǐng)班輸入當(dāng)前日期 （）系統(tǒng)顯示當(dāng)天的預(yù)約（）領(lǐng)班確認(rèn)一個選定的預(yù)約已經(jīng)到達(dá)（）系統(tǒng)對此進(jìn)行記錄并更新顯示器，將顧客標(biāo)記為已經(jīng)到達(dá)。記錄到達(dá)沒有提前預(yù)訂：可選事件路徑（）領(lǐng)班輸入當(dāng)前日期（）系統(tǒng)顯示當(dāng)天的預(yù)約（）系統(tǒng)中沒有記錄該顧客的預(yù)約，

8、領(lǐng)班輸入預(yù)約時間、人數(shù)和餐桌號，創(chuàng)建一個未預(yù)約登記；（）系統(tǒng)記錄并顯示新預(yù)約。以上兩個用例存在共享功能把共享部分分離出來組成一個新用例顯示預(yù)約（Display Bookings）:1 用戶輸入一個日期2 系統(tǒng)顯示當(dāng)日的預(yù)約更改“記錄預(yù)約記錄預(yù)約”用例，可以這樣寫:1 接待員執(zhí)行 顯示預(yù)約用例2 接待員輸入3 系統(tǒng)記錄和顯示新預(yù)約一個用例和它所包含的其他用例之間的關(guān)系，在用例圖中用一個連接兩個用例的虛線箭頭表示，稱為依賴依賴。 一般參與者和特殊參與者之間的泛化關(guān)系。 參與者泛化把兩個或多個參與者的公共行為分離出來成為父參與者。接待員和領(lǐng)班都可以執(zhí)行“顯示預(yù)約”的用例；描述一個新參與者員工（sta

9、ff）表達(dá)泛化；接待員和領(lǐng)班被看作“員工”的特殊情況。Use case extension is shown with a dependencyl僅在簡化模型并使模型易于理解時才使用高級特征。l用例最好是簡單的。必須對于利益相關(guān)人和建模者都是可訪問的。l通常利益相關(guān)人僅需要一點(diǎn)培訓(xùn)和指導(dǎo)就能夠容易地理解參與者和用例。l利益相關(guān)人發(fā)現(xiàn)掌握參與者泛化更加困難。l太多include使得理解用例模型更加困難。l利益相關(guān)人對entend的理解相當(dāng)困難。l很多建模者令人吃驚地錯誤理解extend的語義。應(yīng)該避免使用用例泛化，除非使用抽象父用例。4.1 建立用例模型 4.1.1非正式的需求 4.1.2 用例

10、建模 4.1.3 描述用例（系統(tǒng)的用例編寫，基本的事件路徑） 4.1.4 組織用例模型（調(diào)整優(yōu)化用例圖） 4.1.5 完成用例模型（用例圖的第二次迭代）4.2 建立領(lǐng)域模型4.3 建立詞匯表4.1 建立用例模型 4.1.1非正式的需求 4.1.2 用例建模 4.1.3 描述用例（系統(tǒng)的用例編寫，基本的事件路徑） 4.1.4 組織用例模型（調(diào)整優(yōu)化用例圖） 4.1.5 完成用例模型（用例圖的第二次迭代）4.2 建立領(lǐng)域模型4.3 建立詞匯表在第四章中，UML表示法建立對象模型（學(xué)習(xí)建立類圖的畫法和問題表達(dá)）本節(jié)的核心思想：定義領(lǐng)域模型，提供建模的方法或建模觀點(diǎn)。領(lǐng)域模型是OO分析中最重要的和經(jīng)典

11、的模型領(lǐng)域模型（Domain Model），也稱為概念模型、領(lǐng)域?qū)ο竽Ｐ?，我們在對項目進(jìn)行分析的時候，往往會創(chuàng)建相應(yīng)的領(lǐng)域模型。l尋找業(yè)務(wù)領(lǐng)域中的名詞，建立類圖和對象圖。l領(lǐng)域模型包括：概念、關(guān)聯(lián)、屬性1.概念：概念類：表示在現(xiàn)實世界環(huán)境中具有意義的實體或概念。領(lǐng)域模型：是對業(yè)務(wù)術(shù)語進(jìn)行描述業(yè)務(wù)術(shù)語進(jìn)行描述，產(chǎn)生現(xiàn)實世界概念類的一種表示。通常，采用類圖表示，以顯示最重要的業(yè)務(wù)概念和他們之間的關(guān)系。2.領(lǐng)域模型組成：l概念類l概念類之間的關(guān)系l概念類的屬性（暫不包含操作，在以后考慮）為什么需要領(lǐng)域模型？l理解關(guān)鍵概念和詞匯l為進(jìn)入設(shè)計階段得到一些啟示l現(xiàn)實世界與軟件實現(xiàn)之間的過渡包括以下四步：概

12、念類的識別在領(lǐng)域模型中描述這些概念類建立類關(guān)聯(lián)關(guān)系添加必要的屬性包括以下四步：概念類的識別在領(lǐng)域模型中描述這些概念類建立類關(guān)聯(lián)關(guān)系添加必要的屬性1.概念類的識別識別策略：使用概念類分類列表識別名詞短語策略1：概念類的分類列表（部分）l物理或具體對象l事物的實際、描述和規(guī)范l位置l交易l交易項目人的角色l組織l事件策略2：根據(jù)名詞短語識別找出概念類即：識別有關(guān)用例文本描述中的名詞和名詞短語，將它們作為候選的概念類或?qū)傩?。記錄預(yù)約1 接待員輸入要預(yù)約預(yù)約的日期2 系統(tǒng)系統(tǒng)顯示該日的預(yù)約3 有一張合適的餐桌餐桌可以使用：接待員輸入顧客顧客的姓名姓名、電話電話、預(yù)約的時間時間、用餐人數(shù)用餐人數(shù)和餐桌號

13、餐桌號4 系統(tǒng)記錄并顯示新預(yù)約。包括以下四步：概念類的識別在領(lǐng)域模型中描述這些概念類建立類關(guān)聯(lián)關(guān)系添加必要的屬性建立候選概念類：顧客、預(yù)定顧客和預(yù)定建模：CustomerReservationnamephoneNumber1*Make建立候選概念類：顧客、預(yù)定CustomerReservationnamephoneNumber1*MakecoversdateTimeplacesCustomerReservationnamephoneNumber1*Makecoversdatetimetableplaces*1Reservation for the sameTable must not overlapWalkIncoversdatetime1*BookingcoversdatetimetableplacesWalkInReservationCustomernamephoneNumber*1MakeReservation for the sameTable must not overlap*14.1 建立用例模型 4.1.1非正式的需求 4.1.2 用例建模 4.1.3 描述用例（系統(tǒng)的用例編寫，基本的事件路徑） 4.1.4 組織用例模型（調(diào)整優(yōu)化用例圖） 4.1.5 完成