3 設計模型
3.1 映射分析類到設計類
設計類是指設計層面的類,映射分析類到設計類的過程實際上就是細化分析類的屬性、方法,使類達到可以進行物件導向編程的程度。在分析類的屬性和職責的表示方式可以比較隨意、不強調規範,在設計類中就需要按照UML的文法進行表示。在從分析類到設計類的映射過程並不一定是分析類的一個屬性對應設計類的一個屬性,分析類的一個職責對應設計類的一個方法。類的屬性和方法應該按照UML中的格式表示。
類的屬性格式為:
〔可見度〕屬性名稱〔:類型〕〔‘〔‘多重性〔次序〕’〕’〕〔=初始值〕〔{特性}〕
類的操作格式為:
〔可見度〕操作名〔(參數列表)〕〔:傳回型別〕〔{特性}〕
圖9是一個由分析類Project映射而來的設計類。
圖9 設計類Project
3.2 整理設計類
在最終的類圖上並不是所有的類都是由分析類映射而來的,系統中的絕大部分類都是由分析類映射而來的。在完成映射之後,還需要對已有的類根據設計原則進行最佳化。物件導向主要的設計原則有:開放-封閉原則(OCP)、Liskov替換原則(LSP)、依賴倒置原則(DIP)、介面分離原則(ISP)等。
1. 開放-封閉原則(OCP)
開放-封閉原則描述為“對於擴充是開放的,對於更改是封閉的”。對於擴充是開放的,這意味著模組的行為是可以擴充的。當應用的需求改變時,可以對模組進行擴充,使其具有滿足改變的新行為。也就是說,我們可以改變模組的功能。“對於更改是封閉的”對模組行為進行擴充時,不必改動模組的原始碼或者二進位代碼。
2. Liskov替換原則(LSP)
若對每個類型S的對象O1,都存在一個類型T的對象O2,使得在所有針對T編寫的程式P中,用O1替換O2後,程式P行為功能不變,則S是T的子類型。
3. 依賴倒置原則(DIP)
高層模組不應該依賴於低層模組。二者都應該依賴於抽象。抽象不應該依賴於細節。細節應該依賴於抽象。
4. 介面隔離原則(ISP)
不要強迫客戶依賴於它們不用的方法。
遵循以上原則,可以使我們的軟體更具靈活性,強壯性。但靈活是需要付出代價的,由多態帶來的效能損失就是最明顯的一個問題。所以我們需要權衡,需要做出選擇,在靈活與效能之間做出選擇。
依據一些物件導向設計原則對現在的類進行整理是一種最基本的形式。有一些已經遵守了物件導向設計原則的技術在設計中經常使用,比如設計模式。設計模式是已經得到很好證明的巧妙、優良、通用物件導向系統的解決方案。當我們在設計中應用設計模式時,為了設計上的考慮將會引入新的類加入到我們的設計中。
使用設計模式具有以下好處:首先,使用設計模式可以更準確地描述問題和它們的解決方案;其次,使用設計模式可以具有一致性,即如果對一些已知的問題我們有一類標準的解決方案,那麼在遇到相同問題時,我們能夠採取一致的方法,這就使代碼更容易理解;再次,在遇到問題時,無需每次都從底層做起,而是可以從標準解決方案入手,並對它改編,使之適應特殊問題的需要。這樣就節省了時間,並且提高了開發的品質和效率。
我們根據系統的架構將設計類進行了整理,在展示層主要是表單類,他們的基類是TForm,所有表單類太多,所以沒有把他們一一列出,僅僅列出幾個自訂的展示層的基類,10所示。
圖10 展示層中的類
圖11商務邏輯層中的實體類
圖12 商務邏輯層中的邊界類圖
3.3 更新用例實現
當完成了類的設計後,需要根據類的設計更新在分析階段的用例實現。主要工作是更新互動圖,使用類的方法更新互動圖中的內容。圖13~圖15是在類的設計完成之後更新“選擇建設項目”這個用例的用例實現中的順序圖。
圖13 “選擇建設項目”基本流的順序圖
圖14 “選擇建設項目”可選流1的順序圖
圖15 “選擇建設項目”可選流2的順序圖
3.4 類細節設計
在上面對類設計的步驟中,設計了類的屬性、方法。有些情況下設計到這個層次就可以了。由開發人員在程式編寫過程中設計類中方法的具體實現。我個人的意見是如果條件允許在設計階段盡量對類的重要方法進行設計。下面將以一個具體的類來說明類圖中的詳細設計。在該軟體中有一個類叫做Tevaluate,它的類圖16所示
圖16 Tevaluate類圖
詳細設計可以很好地指導開發人員進行開發。另外,如果概要設計和詳細設計一氣呵成,設計中的問題會相對較少。詳細設計可以採用自然語言、流程圖、虛擬碼等多種方式實現。17使用虛擬碼對Tevaluate的方法PartEvaluate進行的詳細設計。
圖17 類的詳細設計
圖 18 PartEvaluate的活動圖表
可以使用活動圖表描述類圖中一些比較複雜的類的實現。18所示,它描述的就是類Tevaluate中的方法PartEvaluate的實現,根據類的詳細設計和活動圖表很容易就能夠瞭解設計者的意圖,開發人員很快就能夠將其實現。
未完待續......