旅店管理系統中的類的概述 (轉)[@more@]

（本以為這一片的標題會改為“旅店管理中的的概述”，但是發現Allen Holub也是用class作為設計時的名稱，於是保留的原來的標題）

在上一篇中提到了Allen Holub對於物件以及OO的定義是這片開發文件進入了漫長的預備路程，但是我在Allen Holub 的這篇“Building user interfaces for -oriented systems”很快的就讀到這關於一個例項的設計。就是Allen Holub對於ATM的OO分析：

Allen Holub 提到，OO設計的第一步是簡潔闡述我們要解決問題的主要部分。也許（或者肯定）這就是我在第二章“旅店管理系統問題的定義”提到的內容問題定義。但是現在看來我們的定義並不是足夠的好，現在做如下更改：

首先我覺得這個系統不能僅用一個主要問題來描述而應該分為七個：預訂房間，租用房間，結算，解除預定，候補預訂和查詢處理。而這七個問題也就是在前文提到的7個用例（很多人認為我在前一節中的用例闡述得很不夠，我自己也是這樣認為，於是我花了些時間讀了Alistair Cockburn的“Patterns for Effective Use Cases” 和“Writing Effective Use Cases” （extract）的英文原文，我認為的確有必要認真書寫用例文件。但是Alistair Cockburn也提到，在一些較小的系統中也可以簡化用例的書寫過程，同時使用書寫用例的目的在於使系統的再開發和維護更簡便，使開發過程中的其他人員--非用例撰寫人員更容易瞭解系統所要解決的問題。因此我決定不再重新寫用例這一節，而是在這裡簡單的重新勾勒一下。）。現在我在這裡重新描述這7個問題：
1、預定房間：一個顧客打電話或以其他方式告訴旅店服務人員需要預訂房間以及預定資訊（標準，入住時間和天數應該包括入住人姓名等），旅店服務人員根據顧客提供的預定資訊從房間資訊中查詢是否存在符合條件房間，並告訴顧客是否預定成功，如果存在，記錄預定資訊。
2、租用房間：顧客告訴旅店服務人員要求租用房間並提供租用資訊（比預定資訊要多），旅店服務人員根據顧客提供的房間息從客房資訊中查詢是否存在符合條件房間，並告訴顧客時候可以租用房間，記錄租用資訊。
3、延長租用房間：應該也是租用房間（暫定）。
4、結算：顧客提出結算，旅店服務人員根據租用資訊得到租用費用，顧客交款，服務人員實現結算。
5、解除預定：顧客告訴旅店服務人員自己的預定情況（姓名等），服務人員找出預訂，實現解除預定。
6、候補預定：預訂房間條件並且房間已經出租或預定，如果在於租用時間之前出現房屋空閒，在自動實現預定（在固定時間檢查這一狀態）。
7、查詢房間出租情況：管理人員根據查詢條件對租用資訊進行查詢（應該是租用資訊的部分或全部），找出租用資訊。

從以上問題描述中我歸納出了以下類以及他們的功能。

1、房間資訊：管理客房資訊，供旅店服務人員查詢。
2、預定資訊：管理顧客姓名，房間種類，租用時間等資訊。提供給旅店服務人員使用，實現預定房間。
3、租用資訊：管理顧客姓名（需要更資訊的內容），房間種類，租用時間等資訊。提供給旅店服務人員使用。
4、旅店服務人員：根據顧客要求（預定資訊，租用資訊）進行查詢，預訂、候補預定、租用房間,解除預定，結賬。
5、管理人員：查詢預定及租用資訊。
6、查詢資訊：提供給管理人員使用。

其中旅店服務人員和管理人員應該屬於客戶端的類，而其他則屬於端的類。（其中預定資訊，租用資訊以及查詢資訊應該以介面的形式存在）

以下使用上面歸納出來的類（其中的房間資訊等都是根據我們以上定義的類例項化的物件）來對我們要解決的問題進行模擬：
1、預定房間：旅店服務人員向客房資訊發出是否存在符合條件的客房的請求，客房資訊回答yes或者no,如果答案是yes則輸入顧客提供的預定資訊，如果不存在通知客戶，不存在上述房間，是否候補預定。如果顧客要求候補預定則進行候補預定（與預訂房間基本相同，在輸入資訊時標明候補）。
2、租用房間：旅店服務人員向客房資訊發出是否存在符合條件的客房的請求，客房資訊回答yes或者no,如果答案是yes則錄入顧客提供的租用資訊，如果答案是no則租用失敗。
3、延期：同租用。
4、結算：旅店服務員根據顧客提供的資訊（顧客姓名，房間號碼等）找出租用資訊，根據租用資訊中得出租用費用，收取費用，解除房間租用狀態。
5、解除預定：旅店服務人員根據顧客提供的資訊（顧客姓名等）找出預定資訊，解除預定狀態。
6、候補預定：（見預訂房間）。
7、查詢房間出租情況：管理人員根據查詢資訊進行查詢。

其中有以下應該注意：系統應該在每天的固定時間進行資訊自動，有如下內容：
1、自動查詢是否存在過期的預定資訊，如果存在則自動解除預定。
2、自動查詢是否存在過期的租用資訊，如果存在，通知旅店服務人員，由旅店服務人員（現實世界中的）通知顧客，實現結算或延期。
3、自動查詢是否存在候補預定的房間可以轉變成預定的，如果存在則通知旅店服務人員，由旅店服務人員（現實世界中的）通知顧客，如果顧客同意預定，則進行預訂房間。

以上類似乎解決了旅店管理系統中我們提到的問題，但是其中仍經不起仔細的推敲，比如：在查詢房間出租情況中管理人員是對什麼進行查詢的，如果是對租用資訊或者是預定資訊，則這兩種資訊應該是資訊集合，而不是一個單個的資訊，而租用房間和預訂房間的問題中這兩種資訊應該是單個的資訊。所以我對自己做出的上述的類的定義並不滿意，相信大家存在更多的疑惑，希望能夠得到更多人的指正。

待續

旅店管理系統中的類的概述 (轉)

相關文章