賈琳師哥的的這篇文章寫得非常好啊，向他學習！！！！
二、概要設計
完成了用例圖，並用結合用例圖完善了一下需求分析說明書，忘記是第幾次修訂需求分析說明書。有了用例圖，很自然就進入了概要設計階段。我認爲這一階段就是結合包圖解決系統的基本架構。在這裏採用了三層架構（符合高內聚，低耦合的思想），並結合了一些設計模式。
下面看我的包圖：
可以看到，這個包圖，是從最經典的三層UI-BLL-DAL加入設計模式演化而來。
之所以採用抽象工廠模式是考慮到更換數據庫的方便。
而應用外觀模式，是爲了解決UI層和BLL層耦合性過高的問題，UI層不必知道BLL層的存在，Facade（外觀）知道BLL層的哪些類負責處理哪些請求，它將UI的請求代理給適當的BLL層的類。使外部調用更方便。
三、抽象各層的類
當我們確定了整個系統的架構，接下來要做的就是細化，這是一個從宏觀到微觀的過程。
1、抽象實體類
我認爲，第一步要做的就是抽象實體層的類（Entity），因爲信息系統是對數據的操作和處理，首先必須要有數據，這個時候，我們要返回需求，瞭解用戶的數據要求，以此爲依據進行數據庫設計，數據庫設計參見我的文章：
還有一篇轉載《數據庫設計經驗談》
數據庫設計好了，我們要根據數據庫中的表抽象實體類，在機房收費系統中，實體類基本上是跟表一一對應的，一個表映射出一個實體類，表的字段即爲實體類的屬性。
實體層並不屬於三層中的任何一層，它是獨立出來的一層，可以把他看做自定義變量的組合，供三層使用。
下面看看我抽象出的實體類：
見圖：
從圖中，看到有一個EN_PublicField類，這個類並不是由數據表映射而來，它是一個裝載公共變量的類，在系統中，儘量不要在類之外建立變量.有全局用的東西,我們可以建一個實體類,把該全局變量作爲它的屬性。所以,實體類的數量可能多餘表的數量.
2、數據訪問層
搞定了實體層，再來看看數據訪問層（DAL），這一層的主要任務是直接操作數據庫，完成對數據的增刪改查等。這裏我們仍然根據數據表來抽象DAL層的類，基本上也是一個表對應一個類，這樣當我們增加新的表，直接增加新的DAL層類就可以，很好地符合了“開閉原則”。
另外，因爲DAL層的類是直接對數據庫進行操作的類，所以這個類裏封轉大都有四種方法：增刪改查。但根據實際情況會有不同的參數，不同的返回值。
這裏加了一層接口，利用反射和抽象工廠，以防更換數據庫。見下面的部分截圖。
接口：
注：我們看到有一個接口叫ITime，這個接口是用來獲取服務器時間，所以DAL層類的數量也可能多餘表的數量。
DAL實現IDAL接口
抽象工廠模式+反射+配置文件
3、封裝業務邏輯，構成BLL層的類
完成了數據訪問層，我們算是打好了地基了，下面我們再看用例圖，基本上一個用例封裝了一個功能。BLL層的類，我們可以根據功能來分，把與該功能相關的操作集成到一個BLL層的類裏，這裏我們要把握好粒度，平衡就好。
儘量做到符合單一職責原則，一個類完成一個功能，即不要在BLL層出現類之間互相調用的情況，雖然可以減少代碼量，但會增加系統的複雜性，造成模塊與模塊之間的強耦合。
舉個例子：“結賬”的時候我們需要查詢充值記錄表，“查詢充值記錄”的時候我們也需要查詢充值記錄表，我們應該在BLL層的結賬類裏設置查詢方法，在查詢充值記錄類裏也應設置查詢方法。
如果情況比較特殊，需要交叉調用，例如一個操作需要不斷的重複（超過三次），我們一般將它提取出來，供外部調用。這時候，我們應該把調用上移，即，不要在BLL類中調用BLL層類的方法，而是在BLL層的上一層，我們這裏用到了外觀模式，所以在BLL的上一層即Facade層（見上面的包圖）完成對兩個類的方法的調用。
舉個例子："上機"需要檢查卡號是否存在,"下機"也需要檢查卡號是否存在，"充值"，"退卡","註冊卡"都需要檢查。這時候我們可以把檢查卡號這個操作提取出來。當我們調用的時候，不是在BLL層中直接調用，而是把它提升到Facade層來調用，即，調用上機之前，先調用"檢查卡是否存在"。
下面看看我的BLL層
在BLL層用到了策略模式：
4、降低UI和BLL的耦合，採用外觀模式，加入外觀（Facade）類
BLL層中有很多，很小的類，這就給UI層的調用帶來了困難，外觀類這一層爲UI層提供了一個簡單的接口，大大降低了UI層和BLL層的耦合度，也可以看做是一次粒度上的粗化。
見圖：
5、界面層（UI）
界面層的類，就是我們的窗體類，有多少個窗體，UI層就有多少個類。
見圖：
三、設計模式
上面提到的設計模式有：抽象工廠模式，外觀模式，策略模式。在BLL層考慮使用模板方法模式。在UI層，將使用觀察者模式，實現狀態欄的動態變化。如果使用外部報表控件，很可能用到適配器模式。