設計必須將系統定義得夠完整,才能清楚地實作。怎樣才算足夠,不同專案和不同公司各有不同的要求。
有時,設計就像畫素描一樣,只要勾勒出足以讓實作人員著手進行的樣子即可(叫做「以草稿撰寫程式」的方法)。詳細程度隨著實作人員的專業知識、設計的複雜性及設計可能曲解的風險而定。
有時,設計只推敲到可自動轉換為程式碼的程度即可。這通常會從標準的 UML 延伸,以表現語言及/或環境的特殊語意。
設計也可能形成階層,例如:
-
高階設計模型,勾勒整體系統的概觀
-
子系統規格模型,精確指定系統內主要子系統的必要介面和行為
-
子系統內部的詳細設計模型
開發案例應該定義「設計模型」在專案的特定流程中如何實現,以及模型如何/是否與其他模型和實作有關。細節則應該在專案特定準則中規定。
下列章節說明有關設計和實作的一些不同選項,並討論這些方法的優缺點。
一種常用的方法是先以非常抽象的程度來草擬設計的輪廓,然後直接撰寫程式碼。必須手動維護設計模型。
在這種方式中,我們將設計類別視為數個程式碼層次類別的抽象結果。建議您將每一個設計類別對映至一個「表頭」類別,此類別可以轉而使用多個 Helper 類別來執行其行為。您可以利用 Helper
類別來實作複合屬性,或建置您實作操作所需的資料結構。在設計中,您不必建立 Helper 類別的模型,只需要針對表頭類別所定義的主要屬性、關係及操作來建立模型。這種模型的用途是用來擷取可由實作人員完成的細節部份。
這種方式可延伸套用至其他設計模型元素。您可能有比程式碼層次介面更抽象的設計介面,諸如此類。
在雙向工程環境中,設計模型會演化成以視覺化表示法來呈現程式碼的詳細程度。程式碼及其視覺化表示法保持同步(透過工具支援)。
以下是雙向工程中呈現「設計模型」的一些選項。
高階設計模型和詳細設計模型
在這種方式中,維護兩層的設計模型。在雙向模型中,每一個高階設計元素是一或多個詳細元素的抽象表示法。例如,設計類別可能對映至一個「表頭」類別和多個 Helper
類別,如同稍早提及的「以草稿撰寫程式」方法一樣。從高階設計模型元素追蹤至雙向模型元素的能力,有助於保持兩種模型的一致性。
雖然有助於抽離較不重要的細節,但必須仔細衡量維持模型一致性所需投入的成本。
單一進化設計模型
在這種方式中,只有一個「設計模型」。設計元素的初稿會進化到可與程式碼同步的程度。圖解最初會參照草擬的設計類型,例如用來描述設計使用案例實現化的圖解,但最後會參照以特定語言為主的類別。必須適當地提出高階描述,例如:
-
系統邏輯結構的圖解。
-
子系統/元件規格。
-
設計型樣/機制。
這種模型很容易與實作方式保持一致。
相關的方法是按照主要子系統的規格來定義設計,再逐步修飾達到可編譯用戶端實作的程度。
子系統實現的詳細設計和此規格模型可以分開建模和維護。
關於子系統規格和實現及其採用時機的準則,請參閱工作成果準則:設計子系統。
|