大型應(yīng)用軟件設(shè)計(jì)報(bào)告

1、組內(nèi)成員及任務(wù)描述學(xué)號(hào)姓名任務(wù)2012301500028李標(biāo)畫用例圖，活動(dòng)圖，類圖，序列圖，系統(tǒng)構(gòu)件圖，部分系統(tǒng)設(shè)計(jì)文檔的書寫2012301500017盧焱鑫整個(gè)系統(tǒng)的編碼實(shí)現(xiàn)，部分系統(tǒng)設(shè)計(jì)文檔的書寫2012301500008鄧永康系統(tǒng)需求分析，功能模塊設(shè)計(jì)，數(shù)據(jù)庫(kù)設(shè)計(jì)，部分系統(tǒng)設(shè)計(jì)文檔的書寫2012301500029童立成前臺(tái)測(cè)試，后臺(tái)測(cè)試，系統(tǒng)圖標(biāo)美工，部分系統(tǒng)設(shè)計(jì)文檔的書寫第一章 餐館系統(tǒng)的業(yè)務(wù)建模1.1非正式的需求目的：通過改進(jìn)為顧客預(yù)定和分配餐桌的過程，支持一家餐館的日常經(jīng)營(yíng)。原始手工系統(tǒng)速度慢，而且預(yù)約登記單很快會(huì)變得難以理解。這可能導(dǎo)致經(jīng)營(yíng)上的問題，例如，實(shí)際上有空餐桌而由于這個(gè)

2、預(yù)約單不是很明顯，會(huì)妨礙顧客進(jìn)行預(yù)約；沒有備份系統(tǒng)，如果一張預(yù)約單被損壞，那么餐桌就沒有那個(gè)晚上的預(yù)約記錄。由于這些以及其他原因，該餐館欲開發(fā)一個(gè)預(yù)約單的自動(dòng)化系統(tǒng)。該系統(tǒng)應(yīng)該和現(xiàn)有的預(yù)約單顯示同樣的信息，并且有大致相同的格式，使餐館員工易于轉(zhuǎn)換到新系統(tǒng)。當(dāng)記錄了新的預(yù)約時(shí)或?qū)σ延械念A(yù)約進(jìn)行修改時(shí)，應(yīng)該立即更新顯示，使餐館員工在工作時(shí)，總能獲得最新信息。系統(tǒng)必須易于記錄餐館營(yíng)業(yè)時(shí)發(fā)生的有意義的事情，例如顧客的到來。系統(tǒng)的操作應(yīng)當(dāng)盡可能直接操作屏幕上顯示的數(shù)據(jù)。例如，可以簡(jiǎn)單地將一個(gè)預(yù)約拖到屏幕上的一個(gè)適當(dāng)?shù)奈恢茫瑏砀淖兎峙涞牟妥馈?.2用例建模用例視圖應(yīng)該是客戶、最終用戶、領(lǐng)域?qū)＜?、測(cè)試人員和

3、任何其他的涉及系統(tǒng)的人員，不需要詳細(xì)了解系統(tǒng)結(jié)構(gòu)和實(shí)現(xiàn)就容易理解的。用例視圖不描述軟件系統(tǒng)的組織或結(jié)構(gòu)，它的作用是給設(shè)計(jì)者施加約束，設(shè)計(jì)者必須設(shè)計(jì)出一個(gè)能夠提供用例視圖中指定的功能的結(jié)構(gòu)。1.2.1用例可以通過考慮在系統(tǒng)實(shí)現(xiàn)后餐館員工能夠用它來做什么，簡(jiǎn)單地草擬出一組初步的用例。下面列出了這些用例所支持的主要任務(wù)： 1記錄一個(gè)新的預(yù)約信息（“記錄預(yù)約”）。2取消一個(gè)預(yù)約（“取消預(yù)約”）。3記錄一位顧客的到來（“記錄到達(dá)”）。 4將一位顧客從一張餐臺(tái)移到另一張餐臺(tái)（“調(diào)換餐臺(tái)”）。1.2.2參與者在餐館預(yù)約系統(tǒng)的案例中，所提出的用例可以分成兩組。第一組由與維護(hù)提前預(yù)約信息有關(guān)

4、的用例組成。顧客將聯(lián)系餐館提前預(yù)約或取消提前預(yù)約，一般地，接待員將接到這些電話并更新預(yù)約系統(tǒng)中存儲(chǔ)的信息，因此，我們能夠確定一個(gè)與相應(yīng)用例關(guān)聯(lián)的參與者。在第二組中有許多任務(wù)需要在餐館營(yíng)業(yè)時(shí)執(zhí)行，包括記錄顧客的到來，以及為了適應(yīng)不可預(yù)料的經(jīng)營(yíng)需要將一行用餐者從一個(gè)餐臺(tái)移到另一個(gè)餐臺(tái)。這些工作譬如說可能是一個(gè)侍者領(lǐng)班的責(zé)任，因此我們能夠標(biāo)識(shí)另一個(gè)與這些用例關(guān)聯(lián)的參與者。1.2.3用例圖用例圖（use case diagram）以圖解的形式概括了系統(tǒng)中的不同參與者和用例，并顯示了哪些參與者能夠參與哪些用例。餐館預(yù)約系統(tǒng)的初始用例圖如圖所示：1.3描述用例用例描述了系統(tǒng)和它的用戶之

5、間在一定層次上的完整的交互。例如，一個(gè)打電話給餐館進(jìn)行預(yù)約的顧客，會(huì)和餐館的一位將在系統(tǒng)中記錄預(yù)約的店員講話。為此，該店員需要充當(dāng)一個(gè)接待員，即使這并不是他們正式職位的描述，并且以某種方式和系統(tǒng)交互。在這種情況下，該店員被認(rèn)為是接待員參與者的一個(gè)實(shí)例，發(fā)生在接待員和系統(tǒng)之間的交互是用例的一個(gè)實(shí)例。1.3.1事件路徑用例描述必須定義在執(zhí)行用例時(shí)用戶和系統(tǒng)之間可能的交互。例如，在“記錄預(yù)約”用例中，基本事件路徑將描述這樣的情況：一位顧客打電話進(jìn)行預(yù)約，在要求的日期和時(shí)間有一張合適的餐臺(tái)是空閑的，接待員輸入顧客的姓名和電話號(hào)碼并記錄預(yù)約。這樣的事件路徑，如下所示，能夠以稍微結(jié)構(gòu)化的方式表示，以強(qiáng)調(diào)用

6、戶的動(dòng)作和系統(tǒng)響應(yīng)之間的交互： 記錄預(yù)約：基本事件路徑 1. 接待員輸入要預(yù)約的日期； 2. 系統(tǒng)顯示該日的預(yù)約； 3. 有一張合適的餐臺(tái)可以使用；接待員輸入顧客的姓名和電話號(hào)碼、預(yù)約的時(shí)間、用餐人數(shù)和餐臺(tái)號(hào)； 4. 系統(tǒng)記錄并顯示新的預(yù)約。 如果在顧客要求的日期和時(shí)間沒有可用的餐臺(tái)，上面描述的基本事件路徑就不能完成。在這種情況下會(huì)發(fā)生什么可以通過一個(gè)可選事件路徑描述，如下所示： 記錄預(yù)約沒有可用的餐臺(tái)：可選事件路徑 1.接待員輸入要求預(yù)約的日期；2.系統(tǒng)顯示該日的預(yù)約； 3.沒有合適的餐臺(tái)可以

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

8、而終止； 6. 如果回答“是”，預(yù)約將被輸入，并附有一個(gè)警告標(biāo)志。1.3.2用戶界面原型一般而言，在用例描述中詳述用戶界面不是個(gè)好主意。用例描述的重點(diǎn)是定義系統(tǒng)和用戶之間交互的總體結(jié)構(gòu)，而包含用戶界面的細(xì)節(jié)會(huì)使之不清晰。并且，用戶界面應(yīng)該被設(shè)計(jì)得協(xié)調(diào)一致并便于使用，而這只有合理地考慮了各式各樣的用戶任務(wù)才能做到。如果用例描述不適當(dāng)?shù)刂付擞脩艚缑娴募?xì)節(jié)，可能會(huì)使用戶界面設(shè)計(jì)者的工作更加困難，或者需要大量改寫用例描述。1.4組織用例模型一旦已經(jīng)記錄了一個(gè)預(yù)約，接下來必須要處理的重要事件是顧客到達(dá)餐館，這由我們稱為“記錄到達(dá)”的用例描述。該用例的基本事件路徑如下： 記

9、錄到達(dá)：基本事件路徑 1. 侍者領(lǐng)班輸入當(dāng)前日期； 2. 系統(tǒng)顯示當(dāng)天的預(yù)約； 3. 侍者領(lǐng)班確認(rèn)一個(gè)選定的預(yù)約已經(jīng)到達(dá)。 4. 系統(tǒng)對(duì)此進(jìn)行記錄并更新顯示器，將顧客標(biāo)記為已到達(dá)。  在這個(gè)用例中，如果系統(tǒng)記錄中沒有到達(dá)顧客的預(yù)約，可能發(fā)生一個(gè)可選事件路徑。在這種情況下，如果有適當(dāng)?shù)牟团_(tái)是空閑的，則創(chuàng)建一個(gè)未經(jīng)預(yù)約的登記。 記錄到達(dá)沒有提前預(yù)定：可選事件路徑 1. 侍者領(lǐng)班輸入當(dāng)前日期； 2. 系統(tǒng)顯示當(dāng)天的預(yù)約； 3. 系統(tǒng)

10、中沒有記錄該顧客的預(yù)約，所以侍者領(lǐng)班輸入預(yù)約時(shí)間、用餐人數(shù)和餐臺(tái)號(hào)，創(chuàng)建一個(gè)未預(yù)約登記；  4. 系統(tǒng)記錄并顯示新預(yù)約。 比較這些事件路徑和為“記錄預(yù)約”用例所寫的事件路徑，顯示出在這兩個(gè)用例中存在著相當(dāng)數(shù)量的某些共享功能。與其多次寫出相同的交互，一種更好的方法是在一個(gè)地方定義共享行為并在適當(dāng)?shù)牡胤揭盟?。UML定義的用例圖表示法提供了一些可以這樣做的方法，能夠產(chǎn)生一個(gè)更簡(jiǎn)單和結(jié)構(gòu)更好的用例模型。1.4.1用例包含餐館經(jīng)理可能試圖計(jì)算一個(gè)特定的晚上要雇傭多少個(gè)侍者，那么，簡(jiǎn)單地看看當(dāng)天的預(yù)約可能是估計(jì)餐館大約會(huì)有多繁忙的一個(gè)好辦法。應(yīng)該定義一個(gè)相應(yīng)于顯示

11、給定一天的預(yù)約的任務(wù)的新用例。這個(gè)用例能夠被餐館的任何工作人員執(zhí)行，因而任何參與者都可以在下面對(duì)基本事件路徑的描述中被提及。顯示預(yù)約：基本事件路徑 1. 用戶輸入一個(gè)日期； 2. 系統(tǒng)顯示當(dāng)日的預(yù)約。 這個(gè)新用例和已經(jīng)描述的用例之間的關(guān)系可以這樣來描繪：只要在執(zhí)行其他用例之一時(shí)就包含“顯示預(yù)約”用例中的交互。 這種關(guān)系需要在用例描述和用例圖中予以清晰化。在一個(gè)用例描述中，如下面版本的“記錄預(yù)約”用例的基本事件路徑描述的，包含其他的用例可以非形式地說明。 記錄預(yù)約：基本事件路徑（修改） 1. 接待員執(zhí)行“顯

12、示預(yù)約”用例； 2. 接待員輸入顧客姓名和電話號(hào)碼、預(yù)定的時(shí)間、用餐人數(shù)以及預(yù)留的餐臺(tái)； 3. 系統(tǒng)記錄和顯示新預(yù)約。 一個(gè)用例和它所包含的其他用例之間的關(guān)系在用例圖中用一個(gè)連接兩個(gè)用例的虛線箭頭表示，稱為依賴性（dependency）, 用一個(gè)指定所描述關(guān)系的類型的構(gòu)造型（stereotype）標(biāo)記。下圖表示了“記錄預(yù)約”和“顯示預(yù)約”之間的“包含（include）”依賴性。1.4.2參與者泛化參與者之間泛化的含意是，特化的參與者可以參與和更一般的參與者關(guān)聯(lián)的所有用例。下圖描述了一個(gè)新參與者，它表示餐館所有員工可以共享的能力，因而稱

13、為“員工（staff）”。已有的參與者通過泛化（generalization）與新參與者相關(guān)，表示它們被看作是“員工”的特殊情況，定義了只能由一個(gè)員工子集共享的附加的特性。1.4.3用例擴(kuò)展“記錄到達(dá)”用例的可選事件路徑規(guī)定，如果系統(tǒng)沒有記錄一個(gè)顧客的預(yù)約，侍者領(lǐng)班將通過創(chuàng)建一個(gè)未預(yù)約登記來表示他們?cè)诓宛^用餐的事實(shí)。但是，將記錄未預(yù)約登記表示為單獨(dú)一個(gè)用例可能更好一些，因?yàn)槲搭A(yù)約登記將會(huì)為那些從不提前進(jìn)行預(yù)約的顧客創(chuàng)建，而且該用例可能需要獨(dú)立于“記錄到達(dá)”用例執(zhí)行。 “記錄未預(yù)約顧客”用例的基本事件路徑將會(huì)被某個(gè)沒有預(yù)約就來用餐人觸發(fā)。它的結(jié)構(gòu)非常類似于“記錄預(yù)約”用例，只是在記錄的

14、細(xì)節(jié)上不同?；臼录窂娇梢匀缦旅枋觯?#160;記錄未預(yù)約顧客:基本事件路徑 1. 侍者領(lǐng)班執(zhí)行“顯示預(yù)約”用例； 2. 侍者領(lǐng)班輸入時(shí)間、用餐人數(shù)和分配給顧客的餐臺(tái)；3. 系統(tǒng)記錄并顯示新預(yù)約?！坝涗浀竭_(dá)”用例的可選事件路徑和這個(gè)新用例的描述之間有相當(dāng)多的重疊?！坝涗浳搭A(yù)約顧客”用例只是在“記錄到達(dá)”的某些情況下被執(zhí)行，也就是對(duì)該顧客沒有記錄的預(yù)約、有一個(gè)適當(dāng)?shù)牟团_(tái)空閑著、并且顧客還想在餐館用餐時(shí)才被執(zhí)行?！坝涗浀竭_(dá)”用例可以被“記錄未預(yù)約顧客”用例擴(kuò)展，來描述這種情形。這在用例模型中可以通過一個(gè)標(biāo)記為extends的構(gòu)造型的依賴性表示，如

15、圖所示：1.5完成用例模型取消預(yù)約的基本事件路徑可以如下指定：  取消預(yù)約:基本事件路徑 1.接待員選擇要求的預(yù)約；2.接待員取消該預(yù)約；3.系統(tǒng)詢問接待員確認(rèn)取消； 4.接待員回答“是”，系統(tǒng)記錄取消并更新顯示?！罢{(diào)換餐臺(tái)”用例的基本事件路徑也可以獨(dú)立于用戶界面的細(xì)節(jié)進(jìn)行定義如下： 調(diào)換餐臺(tái):基本事件路徑 1. 侍者領(lǐng)班選擇需要的預(yù)約； 2. 侍者領(lǐng)班改變?cè)擃A(yù)約的餐臺(tái)分配； 3. 系統(tǒng)記錄改變并更新顯示。這個(gè)用例可以通過一個(gè)菜單選項(xiàng)調(diào)用，由用戶在一個(gè)對(duì)話框中填寫新的餐臺(tái)號(hào)，或者通過將預(yù)約矩形拖

16、到它的新位置完成調(diào)換餐臺(tái)。完整的用例圖如圖所示：第二章 餐館系統(tǒng)的分析2.1分析的目的以用例描述的形式陳述的需求是定義系統(tǒng)外部行為非常有價(jià)值的工具，但是它們對(duì)系統(tǒng)的內(nèi)部結(jié)構(gòu)，或如何提出一組交互的對(duì)象來支持所要求的功能并沒有給出任何指導(dǎo)。因此，可以把分析的任務(wù)描述為是構(gòu)造一個(gè)模型，來說明這些交互的對(duì)象如何能夠交付用例中規(guī)定的行為。2.2對(duì)象設(shè)計(jì)為了產(chǎn)生實(shí)化一個(gè)用例的交互圖，必須在一組對(duì)象之間分配所需要的數(shù)據(jù)和處理，那么這些對(duì)象就可以進(jìn)行交互以支持用例規(guī)定的功能。面向?qū)ο蟪绦蛟O(shè)計(jì)的啟示是軟件對(duì)象反映的是在現(xiàn)實(shí)世界或應(yīng)用領(lǐng)域中找出的對(duì)象。面向?qū)ο笙到y(tǒng)中的數(shù)據(jù)并不是保存在一個(gè)單獨(dú)的中央數(shù)據(jù)存儲(chǔ)中，而是

17、分布在系統(tǒng)的所有對(duì)象中。這可以用責(zé)任的術(shù)語來描述說每個(gè)對(duì)象負(fù)責(zé)管理系統(tǒng)中數(shù)據(jù)的一個(gè)子集。一個(gè)對(duì)象負(fù)責(zé)的數(shù)據(jù)不僅包括它的屬性值，還包括它所維護(hù)的與系統(tǒng)中其他對(duì)象的鏈接。對(duì)象負(fù)有的另一類責(zé)任是支持某些處理，這些處理最終在它的類所實(shí)現(xiàn)的方法中定義。由對(duì)象進(jìn)行的處理典型地包括，在該對(duì)象可用的數(shù)據(jù)上實(shí)行某些計(jì)算，或者通過給其他對(duì)象發(fā)送消息協(xié)同進(jìn)行一個(gè)較大的操作以及用它們返回的數(shù)據(jù)做些事情。對(duì)象設(shè)計(jì)的一個(gè)基本原則是，在進(jìn)行用例實(shí)化時(shí)，設(shè)計(jì)者應(yīng)該定義具有功能上內(nèi)聚的責(zé)任集的對(duì)象和類。本章剩余的部分將舉例說明這條原則的應(yīng)用。2.3軟件架構(gòu)定義良好的對(duì)象應(yīng)該有一組內(nèi)聚的責(zé)任。例如，在餐館預(yù)約系統(tǒng)的情況中，可能會(huì)

18、提出建議，顧客對(duì)象應(yīng)該負(fù)責(zé)任何與顧客有關(guān)的事宜，從在屏幕上顯示顧客信息，維護(hù)顧客的姓名和電話號(hào)碼使之可以使用，到將這些數(shù)據(jù)存儲(chǔ)到一個(gè)關(guān)系數(shù)據(jù)庫(kù)中。責(zé)任應(yīng)該交給不同的類，由一個(gè)模型（model）類來負(fù)責(zé)維護(hù)數(shù)據(jù)，而由一個(gè)視圖（view）類負(fù)責(zé)顯示數(shù)據(jù)。在系統(tǒng)運(yùn)行時(shí)對(duì)象之間傳遞的消息數(shù)目會(huì)增加。例如，無論何時(shí)要更新顯示，視圖類在顯示之前都必須從模型類獲取對(duì)象最近的狀態(tài)。這種在模型和視圖之間進(jìn)行區(qū)分的原則可以應(yīng)用于系統(tǒng)級(jí)，導(dǎo)致識(shí)別架構(gòu)中兩個(gè)分離的層次。維護(hù)系統(tǒng)狀態(tài)和實(shí)現(xiàn)應(yīng)用業(yè)務(wù)邏輯的類置于應(yīng)用層（application layer），而與用戶界面有關(guān)的類放在表示層（presentation

19、 layer）。2.4用例序列圖2.4.1接待預(yù)約序列圖2.4.2臨時(shí)預(yù)約序列圖2.4.3調(diào)換餐桌序列圖2.4.4預(yù)約餐桌序列圖2.4.5注冊(cè)序列圖2.5完成分析模型下圖顯示了系統(tǒng)的類圖，包括來源于進(jìn)行用例實(shí)化的過程中的信息和決策。這個(gè)類圖也包括來自領(lǐng)域模型的信息，例如顧客、餐臺(tái)和預(yù)約類之間的關(guān)系以及不能重復(fù)預(yù)約的約束等。第三章 餐館系統(tǒng)的設(shè)計(jì)3.1接受用戶數(shù)據(jù)預(yù)約系統(tǒng)對(duì)象是一個(gè)應(yīng)用層的對(duì)象，所以實(shí)際上消息并不會(huì)直接發(fā)送到這個(gè)對(duì)象，所以必須有某個(gè)表示層的對(duì)象，它的責(zé)任是接收用戶的輸入并轉(zhuǎn)發(fā)給控制對(duì)象。表示層的這個(gè)接收用戶輸入的對(duì)象可以很合理地描述為一個(gè)邊界對(duì)象。它表示呈現(xiàn)給一個(gè)特定參

20、與者的用戶界面。就預(yù)約系統(tǒng)來說，我們假定所有用戶使用相同的用戶界面，因此將這個(gè)類命名為“StaffUI”。為了執(zhí)行“顯示預(yù)約”用例，用戶首先要選擇一個(gè)適當(dāng)?shù)牟藛芜x項(xiàng)。這引起一個(gè)對(duì)話框的出現(xiàn)，在對(duì)話框中，用戶輸入需要的日期，然后單擊“OK”按鈕將請(qǐng)求提交給系統(tǒng)。3.2產(chǎn)生輸出“StaffUI”類具有兩個(gè)不同的角色：作為邊界類，它接收來自用戶的消息并將消息轉(zhuǎn)發(fā)給控制器類；除此之外，它還充當(dāng)著視圖類的角色，將應(yīng)用數(shù)據(jù)或模型呈現(xiàn)給用戶，即顯示系統(tǒng)的輸出。對(duì)輸出機(jī)制的要求是，只要應(yīng)用數(shù)據(jù)的狀態(tài)改變了，屏幕上對(duì)該數(shù)據(jù)的表示就要更新，使用戶所看到的和系統(tǒng)狀態(tài)是一致的。解決辦法是：只要應(yīng)用有什么變化時(shí)，由應(yīng)用

21、類來通知視圖類，那么對(duì)視圖的更新只是在需要時(shí)才發(fā)生。3.3持久數(shù)據(jù)存儲(chǔ)預(yù)約需要跨會(huì)話存儲(chǔ)，這個(gè)系統(tǒng)的核心問題是捕獲和記錄預(yù)約信息。除此之外，還有預(yù)約鏈接的餐桌和顧客對(duì)象也需要持久保存。TableoidnumberplacesCustomeroidnamephoneNumberWalkInoid coversdatetimetable_idReservationoidcoversdatetimetable_idcustomer_id為了跟蹤類的實(shí)例，同時(shí)為了確保不創(chuàng)建重復(fù)的實(shí)例，需要在模型中表示出數(shù)據(jù)庫(kù)模式中引入的明確的對(duì)象標(biāo)識(shí)符。為每個(gè)持久類定義一個(gè)表示持久對(duì)象的子類，這個(gè)子類新增加一個(gè)屬性來

22、保存明確的對(duì)象標(biāo)識(shí)符。下圖說明了持久性的這種實(shí)現(xiàn)的結(jié)構(gòu)，該圖顯示了對(duì)特定的“Table”類定義的兩個(gè)新類。3.4詳細(xì)的類設(shè)計(jì)系統(tǒng)類的特征的完整清單以及全部的參數(shù)和類型信息，如下圖所示：BookingSystem-date : Date+addObserver(o : BookingObserver)+cancel()+getBookings() : Set (Booking)+getDate() : Date+makeReservation(d : Date,in : Time,tno : Integer,name : String,phone : String)+makeWalkIn(d :

23、 Date,in : Time, tno : Integer)+notifyObservers()+recordArrival()+selectBooking(d : Date, tno : Integer)+setDate(d : Date)+transfer(d : Date, tno : Integer)這個(gè)類的基本責(zé)任是維護(hù)當(dāng)前預(yù)約的集合，即用戶能夠在屏幕上看到的預(yù)約，并且該類支持的操作主要是對(duì)這個(gè)集合的操作，或是對(duì)集合中各個(gè)預(yù)約的操作。這些預(yù)約自身不是作為這個(gè)類的一個(gè)屬性建模，而是以預(yù)約系統(tǒng)類和預(yù)約類之間的一個(gè)關(guān)聯(lián)建模。3.5動(dòng)態(tài)行為建模一個(gè)完整的設(shè)計(jì)應(yīng)該指定系統(tǒng)中類的結(jié)構(gòu)和行為這兩

24、個(gè)方面。類圖定義預(yù)約系統(tǒng)保存的數(shù)據(jù)以及數(shù)據(jù)項(xiàng)彼此相關(guān)的方式，并因此給出了系統(tǒng)靜態(tài)結(jié)構(gòu)相當(dāng)全面的描述。關(guān)于對(duì)象的行為的一些信息則由實(shí)化用例所定義并顯示在順序圖中，其中顯示了特定交互所涉及的對(duì)象和消息。3.5.1消息的順序：消息發(fā)送給對(duì)象的順序?qū)⒁蕾囉趯?duì)象的環(huán)境。例如，發(fā)送給預(yù)約系統(tǒng)的消息最終依賴系統(tǒng)用戶所采取的行為，而不是依賴系統(tǒng)中執(zhí)行的任何處理。3.5.2依賴歷史的行為：某些消息具有在不同時(shí)間從一個(gè)對(duì)象引起不同響應(yīng)的特性。例如，在記錄一個(gè)到達(dá)餐館時(shí)，這個(gè)預(yù)約的到達(dá)時(shí)間應(yīng)該相應(yīng)地設(shè)置。然而，如果隨后同樣的消息再次發(fā)送給相同的對(duì)象，將不會(huì)改變對(duì)象的狀態(tài)，因?yàn)橐粋€(gè)預(yù)定到達(dá)多次沒有意義。讓對(duì)象負(fù)責(zé)檢查

25、在它的當(dāng)前狀態(tài)沒有意義的消息。由于一個(gè)消息的效果可以依賴于先前已經(jīng)發(fā)送給它的消息，這意味著對(duì)象必須以某種方式知道它們的歷史，或者知道它們已經(jīng)接收的消息。3.5.3指定行為：對(duì)象行為有兩個(gè)方面在交互圖中沒有捕獲，但是這需要作為系統(tǒng)設(shè)計(jì)的一部分明確說明。 1. 對(duì)象預(yù)期接收什么消息序列。 2. 對(duì)象如何響應(yīng)消息，尤其是這個(gè)響應(yīng)如何依賴于對(duì)象的歷史，即它已經(jīng)接收的消息。3.6預(yù)約系統(tǒng)的狀態(tài)圖預(yù)約系統(tǒng)類顯示出的最重要的依賴狀態(tài)的行為與預(yù)約的選擇有關(guān)。某些消息，如“recordArrival”，只能在已經(jīng)選擇了一個(gè)預(yù)約的條件下被切合實(shí)際地處理。這種情況的基本動(dòng)態(tài)在

26、下圖中定義。在任一給定的時(shí)間，對(duì)象總是處于它可能的狀態(tài)之一。當(dāng)它接收到一個(gè)消息對(duì)應(yīng)于從它當(dāng)前狀態(tài)出發(fā)的轉(zhuǎn)換上的事件時(shí)，該轉(zhuǎn)移被激發(fā)，而對(duì)象進(jìn)入轉(zhuǎn)換另一端的狀態(tài)。例如，假定當(dāng)前沒有選擇的預(yù)約，預(yù)約系統(tǒng)處于上圖左部所示的“NotSelected”狀態(tài)。如果現(xiàn)在發(fā)生顧客到達(dá)的交互，預(yù)約系統(tǒng)會(huì)先收到一個(gè)“selectBooking”消息，這將引起標(biāo)記該消息名字的轉(zhuǎn)換被激發(fā)，而預(yù)約系統(tǒng)對(duì)象將遷移到“Selected” 被選中狀態(tài)。然后，接收到“recordArrival”消息，標(biāo)記為“recordArrival”的轉(zhuǎn)換激發(fā)。但是，這使預(yù)約系統(tǒng)還處于接收消息之前的狀態(tài)，換句話說，在這個(gè)消息被處理之后，對(duì)象

27、仍然處于被選中狀態(tài)。只有在預(yù)約處于被選中狀態(tài)時(shí)才有意義的其他消息是“transfer”和“cancel”。“transfer”和“recordArrival”的行為方式相同，但是“cancel”的結(jié)果略有不同。一旦取消了一個(gè)預(yù)約，它將從顯示中消除并被刪除，所以不會(huì)再存在一個(gè)選中的預(yù)約。因此，在狀態(tài)圖中，標(biāo)記著“cancel”的轉(zhuǎn)換必須將系統(tǒng)移回到“NotSelected”狀態(tài)，如圖所示。3.6.1非確定性下圖說明了收到“selectBooking”消息的所有可能結(jié)果。假定如果在屏幕上一個(gè)空位置單擊鼠標(biāo)，任何已選擇的預(yù)約仍處于選定。3.6.2監(jiān)護(hù)條件在被建模的系統(tǒng)中真正存在非確定性的情況下，像3.6.1那樣的狀態(tài)圖是完全適合的。在預(yù)約系統(tǒng)的情況中，它完全依賴于和“selectBooking”消息一起傳遞的參數(shù)。通過為相關(guān)轉(zhuǎn)換增加監(jiān)護(hù)條件（guard condition），在狀態(tài)圖中可以表明這些事實(shí)。圖3.6.2說明了如何指定監(jiān)護(hù)條件以解決圖3.6.1中的不明確性。3.6.3動(dòng)作下圖所示的是帶有動(dòng)作的狀態(tài)圖，以強(qiáng)調(diào)新預(yù)約將被選擇的情況。3.7預(yù)定的狀態(tài)圖預(yù)定類提供了用狀態(tài)圖概括一個(gè)類的對(duì)象的行為的另一個(gè)例子。預(yù)定的確顯示出了依賴于狀態(tài)的行為：一旦已經(jīng)記錄了到來者，就不可能取消預(yù)約，或者再次記錄到達(dá)?？偨Y(jié)這個(gè)行為的狀態(tài)圖如圖所示。這