大型應(yīng)用軟件設(shè)計報告

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

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

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

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

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

6、并記錄預(yù)約。這樣的事件路徑，如下所示，能夠以稍微結(jié)構(gòu)化的方式表示，以強 調(diào)用戶的動作和系統(tǒng)響應(yīng)之間的交互：記錄預(yù)約：基本事件路徑1. 接待員輸入要預(yù)約的日期；2. 系統(tǒng)顯示該日的預(yù)約；3. 有一張合適的餐臺可以使用；接待員輸入顧客的姓名和電話號碼、 預(yù)約的 時間、用餐人數(shù)和餐臺號；4. 系統(tǒng)記錄并顯示新的預(yù)約。如果在顧客要求的日期和時間沒有可用的餐臺，上面描述的基本事件路徑就 不能完成。在這種情況下會發(fā)生什么可以通過一個可選事件路徑描述，如下所示：記錄預(yù)約一一沒有可用的餐臺：可選事件路徑1接待員輸入要求預(yù)約的日期；2. 系統(tǒng)顯示該日的預(yù)約；3投有合適的餐臺可以使用，用例終止?？蛇x事件路徑描述的

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

8、面不是個好主意。 用例描述的重點是定 義系統(tǒng)和用戶之間交互的總體結(jié)構(gòu)，而包含用戶界面的細節(jié)會使之不清晰。并且, 用戶界面應(yīng)該被設(shè)計得協(xié)調(diào)一致并便于使用，而這只有合理地考慮了各式各樣的 用戶任務(wù)才能做到。如果用例描述不適當(dāng)?shù)刂付擞脩艚缑娴募毠?jié)， 可能會使用 戶界面設(shè)計者的工作更加困難，或者需要大量改寫用例描述。1.4組織用例模型一旦已經(jīng)記錄了一個預(yù)約，接下來必須要處理的重要事件是顧客到達餐館， 這由我們稱為“記錄到達”的用例描述。該用例的基本事件路徑如下：記錄到達：基本事件路徑1. 侍者領(lǐng)班輸入當(dāng)前日期；2. 系統(tǒng)顯示當(dāng)天的預(yù)約；3. 侍者領(lǐng)班確認(rèn)一個選定的預(yù)約已經(jīng)到達。4. 系統(tǒng)對此進行記錄

9、并更新顯示器，將顧客標(biāo)記為已到達。在這個用例中，如果系統(tǒng)記錄中沒有到達顧客的預(yù)約， 可能發(fā)生一個可選事 件路徑。在 這種情況下，如果有適當(dāng)?shù)牟团_是空閑的，則創(chuàng)建一個未經(jīng)預(yù)約的登記。記錄到達一一沒有提前預(yù)定：可選事件路徑1. 侍者領(lǐng)班輸入當(dāng)前日期；2. 系統(tǒng)顯示當(dāng)天的預(yù)約；3. 系統(tǒng)中沒有記錄該顧客的預(yù)約，所以侍者領(lǐng)班輸入預(yù)約時間、用餐人數(shù)和 餐臺號，創(chuàng)建一個未預(yù)約登記；4. 系統(tǒng)記錄并顯示新預(yù)約。比較這些事件路徑和為“記錄預(yù)約”用例所寫的事件路徑，顯示出在這兩個用例中存在著相當(dāng)數(shù)量的某些共享功能。 與其多次寫出相同的交互，一種更好的方法是在一個地方定義共享行為并在適當(dāng)?shù)牡胤揭盟ML定義的

10、用例圖表示法提供了一些可以這樣做的方法，能夠產(chǎn)生一個更簡單和結(jié)構(gòu)更好的用例模 型。1.4.1用例包含餐館經(jīng)理可能試圖計算一個特定的晚上要雇傭多少個侍者，那么，簡單地看看當(dāng)天的預(yù)約可能是估計餐館大約會有多繁忙的一個好辦法。應(yīng)該定義一個相應(yīng)于顯示給定一天的預(yù)約的任務(wù)的新用例。 這個用例能夠被餐館的任何工作人員執(zhí) 行，因而任何參與者都可以在下面對基本事件路徑的描述中被提及。顯示預(yù)約：基本事件路徑1. 用戶輸入一個日期；2. 系統(tǒng)顯示當(dāng)日的預(yù)約。這個新用例和已經(jīng)描述的用例之間的關(guān)系可以這樣來描繪：只要在執(zhí)行其他 用例之一時就包含“顯示預(yù)約”用例中的交互。這種關(guān)系需要在用例描述和用例圖中予以清晰化。在一

11、個用例描述中，如下面版本的“記錄預(yù)約”用例的基本事件路徑描述的，包含其他的用例可以非形式 地說明。記錄預(yù)約：基本事件路徑(修改)1. 接待員執(zhí)行“顯示預(yù)約”用例；2. 接待員輸入顧客姓名和電話號碼、預(yù)定的時間、用餐人數(shù)以及預(yù)留的餐 臺；3. 系統(tǒng)記錄和顯示新預(yù)約。一個用例和它所包含的其他用例之間的關(guān)系在用例圖中用一個連接兩個用 例的虛線箭頭表示，稱為依賴性(dependency),用一個指定所描述關(guān)系的類型 的構(gòu)造型(stereotype)標(biāo)記。下圖表示了“記錄預(yù)約”和“顯示預(yù)約”之間的 “包含(in elude)”依賴性。1.4.2參與者泛化參與者之間泛化的含意是，特化的參與者可以參與和更一

12、般的參與者關(guān)聯(lián)的 所有用例。下圖描述了一個新參與者，它表示餐館所有員工可以共享的能力，因而稱為 “員工(staff)”。已有的參與者通過泛化(generalization)與新參與者相關(guān)，表 示它們被看作是“員工”的特殊情況，定義了只能由一個員工子集共享的附加的 特性。AstaffHead WeilerOip4ay Bockiing1.4.3用例擴展“記錄到達”用例的可選事件路徑規(guī)定，如果系統(tǒng)沒有記錄一個顧客的預(yù)約， 侍者領(lǐng)班將通過創(chuàng)建一個未預(yù)約登記來表示他們在餐館用餐的事實。但是，將記錄未預(yù)約登記表示為單獨一個用例可能更好一些，因為未預(yù)約登記將會為那些從 不提前進行預(yù)約的顧客創(chuàng)建，而且該用例

13、可能需要獨立于“記錄到達”用例執(zhí)行?！坝涗浳搭A(yù)約顧客”用例的基本事件路徑將會被某個沒有預(yù)約就來用餐人觸 發(fā)。它的結(jié)構(gòu)非常類似于“記錄預(yù)約”用例，只是在記錄的細節(jié)上不同。基本事 件路徑可以如下描述：記錄未預(yù)約顧客：基本事件路徑1. 侍者領(lǐng)班執(zhí)行“顯示預(yù)約”用例；2. 侍者領(lǐng)班輸入時間、用餐人數(shù)和分配給顧客的餐臺；3. 系統(tǒng)記錄并顯示新預(yù)約。“記錄到達”用例的可選事件路徑和這個新用例的描述之間有相當(dāng)多的重 疊?！坝涗浳搭A(yù)約顧客”用例只是在“記錄到達”的某些情況下被執(zhí)行，也就是 對該顧客沒有記錄的預(yù)約、有一個適當(dāng)?shù)牟团_空閑著、并且顧客還想在餐館用餐 時才被執(zhí)行。“記錄到達”用例可以被“記錄未預(yù)約顧客

14、”用例擴展，來描述這種情形。 這在用例模型中可以通過一個標(biāo)記為 exte nds的構(gòu)造型的依賴性表示，如圖 所示：Receptionist1.5完成用例模型取消預(yù)約的基本事件路徑可以如下指定：取消預(yù)約:基本事件路徑1接待員選擇要求的預(yù)約；2接待員取消該預(yù)約；3系統(tǒng)詢問接待員確認(rèn)取消；4接待員回答“是”，系統(tǒng)記錄取消并更新顯示。“調(diào)換餐臺”用例的基本事件路徑也可以獨立于用戶界面的細節(jié)進行定義如 下：調(diào)換餐臺:基本事件路徑1. 侍者領(lǐng)班選擇需要的預(yù)約；2. 侍者領(lǐng)班改變該預(yù)約的餐臺分配；3. 系統(tǒng)記錄改變并更新顯示。這個用例可以通過一個菜單選項調(diào)用，由用戶在一個對話框中填寫新的餐臺 號，或者通過將

15、預(yù)約矩形拖到它的新位置完成調(diào)換餐臺。完整的用例圖如圖所示：5.1肖發(fā)紋i.inclu-19mdud?inclucte.-iF會濟卜普臨intliudeislot!：艸曲皿A扁時恆詢實!6彗 dXlfTlIR、*即浪號Siring = adiTufi瑪:String h泗陽第二章餐館系統(tǒng)的分析2.1分析的目的以用例描述的形式陳述的需求是定義系統(tǒng)外部行為非常有價值的工具，但是它們對系統(tǒng)的內(nèi)部結(jié)構(gòu)，或如何提出一組交互的對象來支持所要求的功能并沒有 給出任何指導(dǎo)。因此，可以把分析的任務(wù)描述為是構(gòu)造一個模型，來說明這些交 互的對象如何能夠交付用例中規(guī)定的行為。2.2對象設(shè)計為了產(chǎn)生實化一個用例的交互圖，

16、必須在一組對象之間分配所需要的數(shù)據(jù)和 處理，那么這些對象就可以進行交互以支持用例規(guī)定的功能。面向?qū)ο蟪绦蛟O(shè)計的啟示是軟件對象反映的是在現(xiàn)實世界或應(yīng)用領(lǐng)域中找 出的對象。面向?qū)ο笙到y(tǒng)中的數(shù)據(jù)并不是保存在一個單獨的中央數(shù)據(jù)存儲中，而是分布在系統(tǒng)的所有對象中。這可以用責(zé)任的術(shù)語來描述說每個對象負(fù)責(zé)管理系統(tǒng)中數(shù) 據(jù)的一個子集。一個對象負(fù)責(zé)的數(shù)據(jù)不僅包括它的屬性值，還包括它所維護的與 系統(tǒng)中其他對象的鏈接。對象負(fù)有的另一類責(zé)任是支持某些處理，這些處理最終在它的類所實現(xiàn)的方 法中定義。由對象進行的處理典型地包括，在該對象可用的數(shù)據(jù)上實行某些計算， 或者通過給其他對象發(fā)送消息協(xié)同進行一個較大的操作以及用它們

17、返回的數(shù)據(jù) 做些事情。對象設(shè)計的一個基本原則是，在進行用例實化時，設(shè)計者應(yīng)該定義具有功能 上內(nèi)聚的責(zé)任集的對象和類。本章剩余的部分將舉例說明這條原則的應(yīng)用。2.3軟件架構(gòu)定義良好的對象應(yīng)該有一組內(nèi)聚的責(zé)任。例如，在餐館預(yù)約系統(tǒng)的情況中， 可能會提出建議，顧客對象應(yīng)該負(fù)責(zé)任何與顧客有關(guān)的事宜，從在屏幕上顯示顧客信息，維護顧客的姓名和電話號碼使之可以使用， 到將這些數(shù)據(jù)存儲到一個關(guān) 系數(shù)據(jù)庫中。責(zé)任應(yīng)該交給不同的類，由一個模型(model)類來負(fù)責(zé)維護數(shù)據(jù)，而由一 個視圖(view)類負(fù)責(zé)顯示數(shù)據(jù)。在系統(tǒng)運行時對象之間傳遞的消息數(shù)目會增加。 例如，無論何時要更新顯示，視圖類在顯示之前都必須從模型類

18、獲取對象最近的 狀態(tài)。這種在模型和視圖之間進行區(qū)分的原則可以應(yīng)用于系統(tǒng)級，導(dǎo)致識別架構(gòu)中兩個分離的層次。維護系統(tǒng)狀態(tài)和實現(xiàn)應(yīng)用業(yè)務(wù)邏輯的類置于應(yīng)用層(application layer)，而與用戶界面有關(guān)的類放在表示層( presentation layer)。2.4用例序列圖2.4.1接待預(yù)約序列圖預(yù)約記錄畀直1嵐是、密馮、權(quán)限?2賬號、孫碼*權(quán)限合法性.3提示輸只己祓的信息丿乳預(yù)約信息檢查6存在此預(yù)約i可接待丁4預(yù)約信息輸入242臨時預(yù)約序列圖暢約記錄U 2：喘號.Sfi IRPR-03：提示臨時輩約記錄4臨時記錄新人5臨時記錄合理性唸育T訓(xùn)約貳巾開；忒新記親2.4.3調(diào)換餐桌序列圖錄界面

19、1、巒口1砥號、裁瑪、投餛臺譙也一調(diào)斶戢功、刑咸師 d244預(yù)約餐桌序列圖1觀弓、蕙碼輸入A:預(yù)盟J秫入r張旳rtt*祗頑記錄3- f?云珮人施的I2葉號、豈碼檢苣 rII2.4.5注冊序列圖O八登入畀函登厭畀面十輔入賬號、密理:r-?驗證恥號 更咼禽3較B新音求5驗證機健dal0Reseivatton io-:he 電 table muti nflt 仙自lapRsierrat onGuslcmerarrMllme11 1吒r gmeMakehonaiJijmbsrsetAirb 咼 ITiniE0第三章餐館系統(tǒng)的設(shè)計3.1接受用戶數(shù)據(jù)預(yù)約系統(tǒng)對象是一個應(yīng)用層的對象，所以實際上消息并不會直接

20、發(fā)送到這個 對象，所以必須有某個表示層的對象，它的責(zé)任是接收用戶的輸入并轉(zhuǎn)發(fā)給控制 對象。表示層的這個接收用戶輸入的對象可以很合理地描述為一個邊界對象。它表示呈現(xiàn)給一個特定參與者的用戶界面。就預(yù)約系統(tǒng)來說，我們假定所有用戶使用 相同的用戶界面，因此將這個類命名為“ StaffU”。為了執(zhí)行“顯示預(yù)約”用例，用戶首先要選擇一個適當(dāng)?shù)牟藛芜x項。這引起一個對話框的出現(xiàn)，在對話框中，用戶輸入需要的日期，然后單擊“0K”按鈕將請求提交給系統(tǒng)。3.2產(chǎn)生輸出“StaffUl”類具有兩個不同的角色：作為邊界類，它接收來自用戶的消息并 將消息轉(zhuǎn)發(fā)給控制器類；除此之外，它還充當(dāng)著視圖類的角色，將應(yīng)用數(shù)據(jù)或模 型

21、呈現(xiàn)給用戶，即顯示系統(tǒng)的輸出。對輸出機制的要求是，只要應(yīng)用數(shù)據(jù)的狀態(tài)改變了，屏幕上對該數(shù)據(jù)的表示 就要更新，使用戶所看到的和系統(tǒng)狀態(tài)是一致的。 解決辦法是：只要應(yīng)用有什么 變化時，由應(yīng)用類來通知視圖類，那么對視圖的更新只是在需要時才發(fā)生。3.3持久數(shù)據(jù)存儲預(yù)約需要跨會話存儲，這個系統(tǒng)的核心問題是捕獲和記錄預(yù)約信息。除此之外，還有預(yù)約鏈接的餐桌和顧客對象也需要持久保存。Tableoidnu mberplacesCustomeroidn amephon eNumberWalkInoidcoversdatetimetable idReservatio noidcoversdatetimetable

22、idcustomer id為了跟蹤類的實例，同時為了確保不創(chuàng)建重復(fù)的實例，需要在模型中表示出 數(shù)據(jù)庫模式中引入的明確的對象標(biāo)識符。為每個持久類定義一個表示持久對象的 子類，這個子類新增加一個屬性來保存明確的對象標(biāo)識符。下圖說明了持久性的這種實現(xiàn)的結(jié)構(gòu)，該圖顯示了對特定的“ Table類定 義的兩個新類。3.4詳細的類設(shè)計系統(tǒng)類的特征的完整清單以及全部的參數(shù)和類型信息，如下圖所示:Book in gSystem-date : Date+addObserver(o : Book in gObserver)+ca ncel()+getBook in gs() : Set (Book ing)+get

23、Date() : Date+makeReservation(d : Date,in : Time,tno : Integer,name : String,phone : String) +makeWalkl n(d : Date,in : Time, tno : In teger)+no tifyObservers()+recordArrival()+selectBook in g(d : Date, tno : In teger)+setDate(d : Date)+tra nsfer(d : Date, tno : In teger)這個類的基本責(zé)任是維護當(dāng)前預(yù)約的集合，即用戶能夠在屏幕上

24、看到的預(yù) 約，并且該類支持的操作主要是對這個集合的操作，或是對集合中各個預(yù)約的操作。這些預(yù)約自身不是作為這個類的一個屬性建模，而是以預(yù)約系統(tǒng)類和預(yù)約類 之間的一個關(guān)聯(lián)建模。3.5動態(tài)行為建模一個完整的設(shè)計應(yīng)該指定系統(tǒng)中類的結(jié)構(gòu)和行為這兩個方面。類圖定義預(yù)約 系統(tǒng)保存的數(shù)據(jù)以及數(shù)據(jù)項彼此相關(guān)的方式， 并因此給出了系統(tǒng)靜態(tài)結(jié)構(gòu)相當(dāng)全 面的描述。關(guān)于對象的行為的一些信息則由實化用例所定義并顯示在順序圖中， 其中顯示了特定交互所涉及的對象和消息。3.5.1消息的順序：消息發(fā)送給對象的順序?qū)⒁蕾囉趯ο蟮沫h(huán)境。例如，發(fā)送給預(yù)約系統(tǒng)的消息 最終依賴系統(tǒng)用戶所采取的行為，而不是依賴系統(tǒng)中執(zhí)行的任何處理。3.5

25、.2依賴歷史的行為：某些消息具有在不同時間從一個對象引起不同響應(yīng)的特性。 例如，在記錄一 個到達餐館時，這個預(yù)約的到達時間應(yīng)該相應(yīng)地設(shè)置。然而，如果隨后同樣的消 息再次發(fā)送給相同的對象，將不會改變對象的狀態(tài)，因為一個預(yù)定到達多次沒有 意義。讓對象負(fù)責(zé)檢查在它的當(dāng)前狀態(tài)沒有意義的消息。 由于一個消息的效果可以 依賴于先前已經(jīng)發(fā)送給它的消息，這意味著對象必須以某種方式知道它們的歷 史，或者知道它們已經(jīng)接收的消息。3.5.3指定行為：對象行為有兩個方面在交互圖中沒有捕獲， 但是這需要作為系統(tǒng)設(shè)計的一部 分明確說明。1.對象預(yù)期接收什么消息序列。2.對象如何響應(yīng)消息，尤其是這個響應(yīng)如何依賴于對象的歷史

26、， 即它已經(jīng)接 收的消息。3.6預(yù)約系統(tǒng)的狀態(tài)圖預(yù)約系統(tǒng)類顯示出的最重要的依賴狀態(tài)的行為與預(yù)約的選擇有關(guān)。某些消 息，如“recordArrival”，只能在已經(jīng)選擇了一個預(yù)約的條件下被切合實際地處理。 這種情況的基本動態(tài)在下圖中定義。在任一給定的時間，對象總是處于它可能的狀態(tài)之一。當(dāng)它接收到一個消息 對應(yīng)于從它當(dāng)前狀態(tài)出發(fā)的轉(zhuǎn)換上的事件時， 該轉(zhuǎn)移被激發(fā)，而對象進入轉(zhuǎn)換另 一端的狀態(tài)。例如，假定當(dāng)前沒有選擇的預(yù)約，預(yù)約系統(tǒng)處于上圖左部所示的“ NotSelected”狀態(tài)。如果現(xiàn)在發(fā)生顧客到達的交互，預(yù)約系統(tǒng)會先收到一個“ selectBooki n消息，這將引起標(biāo)記該消息名字的轉(zhuǎn)換被激發(fā)，

27、而預(yù)約系統(tǒng)對 象將遷移到“ Selected被選中狀態(tài)。然后，接收到“ recordArrival”消息，標(biāo) 記為“ recordArrival”的轉(zhuǎn)換激發(fā)。但是，這使預(yù)約系統(tǒng)還處于接收消息之前的 狀態(tài)，換句話說，在這個消息被處理之后，對象仍然處于被選中狀態(tài)。只有在預(yù) 約處于被選中狀態(tài)時才有意義的其他消息是“transfer”和“ cance”。“transfer”和“ recordArrival”的行為方式相同，但是“ can cel”的結(jié)果略有不同。一旦取消 了一個預(yù)約，它將從顯示中消除并被刪除，所以不會再存在一個選中的預(yù)約。因此，在狀態(tài)圖中，標(biāo)記著“ cancel”的轉(zhuǎn)換必須將系統(tǒng)移回到

28、“ NotSelected”狀 態(tài)，如圖所示。廠1NiotSeltcted |3.6.1非確定性下圖說明了收到“ selectBooking”消息的所有可能結(jié)果。假定如果在屏幕上 一個空位置單擊鼠標(biāo)，任何已選擇的預(yù)約仍處于選定。3.6.2監(jiān)護條件在被建模的系統(tǒng)中真正存在非確定性的情況下，像 3.6.1那樣的狀態(tài)圖是完 全適合的。在預(yù)約系統(tǒng)的情況中，它完全依賴于和“ selectBooki ng”消息一起傳 遞的參數(shù)。通過為相關(guān)轉(zhuǎn)換增加監(jiān)護條件(guard condition),在狀態(tài)圖中可以表明這些 事實。圖362說明了如何指定監(jiān)護條件以解決圖 361中的不明確性。関 * ilEookn gr

29、K booMn 哥m I BMliing3.6.3動作下圖所示的是帶有動作的狀態(tài)圖，以強調(diào)新預(yù)約將被選擇的情況seteclBo（生眄na MKir-gcKotSe e t*dcdBolmgbQicirig Foimd| f select new baotang jSc aknj no % rzT 血 teded j 13s;ctfio*infr.?Qn3 hiLfic ，詔電M new Sj東ng3.7預(yù)定的狀態(tài)圖預(yù)定類提供了用狀態(tài)圖概括一個類的對象的行為的另一個例子。 預(yù)定的確顯 示出了依賴于狀態(tài)的行為：一旦已經(jīng)記錄了到來者，就不可能取消預(yù)約，或者再 次記錄到達。總結(jié)這個行為的狀態(tài)圖如圖所示。setTa&lflslTatr-ttiArrwAdTirraseiArwai