先決條件（二）結構設計

文章目錄

• 結構設計先決條件
• • 典型的結構要素
  • • 程式的組織形式
    • 變動政策
    • 購買而不是建造的決定
    • 主要的資料結構
    • 關鍵算法
    • 主要對象
    • 通用對象
    • 錯誤處理
    • 堅固性
    • • over-engineering（裕度設計）
      • assertions（斷言）
      • fault tolerance（容錯性）
    • 性能
    • 通用的結構設計品質準則
  • 檢查表

結構設計先決條件

軟體結構設計是較進階意義上的軟體設計，它是支援詳細設計的架構。結構也被稱為“系統結構”、“設計”、“高水準設計”或者“頂層設計”。一般說來，結構體系往往在一個被稱為“結構定義”或者“頂層設計”的單一檔案中進行描述。

典型的結構要素

有許多要素是一個好的系統結構所共有的。

程式的組織形式

小結構的程式組織起來非常簡單，但是對于一個由幾十個子產品組成的軟體系統，就困難多了。一個子產品是一個能完成某一進階功能的子程式的組合，例如，對輸出結果進行格式化，解釋指令，從檔案中讀取資料等。在要求定義中列出的每一項功能，都應該有至少一個子產品覆寫這項功能。如果一項功能由兩個或更多的子產品覆寫，那麼它們之間應該是互補的而不是互相沖突。

每一個子產品作什麼應該明确定義。一個子產品應該隻完成一項任務而且圓滿完成。對于與它相作用的其它子產品情況，你知道得越少越好。通過盡可能地降低子產品之間的了解程度，就可能把設計資訊都集中在一個子產品中。

每個子產品之間的交界面也應該明确定義。結構設計應該規定可以直接調用哪些子產品，哪些子產品它不能調用。同時，結構設計也應該定義子產品傳送和從其它子產品接收的資料。

變動政策

建立一個軟體系統，對于程式員和使用者來說，都是一個逐漸學習的過程，是以在這個過程中作出變動是不可避免的。變動産生的原因可能是由于反複無常的資料結構，也可能是由于檔案格式和系統功能改變，新的性能等而引起的。這些變動有時是為了增加新的能力以便強化功能，也有時是版本增加而引起的。是以結構設計所面臨的主要挑戰便是增強系統的靈活性，以便容納這類變動。

結構設計中應該說明用于延緩變動的政策。比如，結構設計中可能規定應使用表驅動技術而不是手工編碼技術。它還可能規定表所使用的檔案應該儲存在一個外部檔案中，而不是編碼在程式中，這樣，可以不必重新編譯就可以對程式作出調整。

購買而不是建造的決定

建立一個軟體的最徹底的辦法并不是建立——而是去購買一個軟體，你可以購買資料庫管理系統、螢幕生成程式、報告生成程式和圖形環境。

主要的資料結構

結構設計中應該給出相應的資料結構。

最後，應該遵循資料守恒定律：每一個進入的資料都應該出去，或者與其它資料一道出去，如果它不出去，那他就沒有必要進來。

關鍵算法

如果結構設計依賴于某一特定算法，那它應該描述或指出這一算法。同主要資料結構一樣，結構設計中也應該指出考慮過的算法方案，并指出選中最終方案的原因。

主要對象

在面向對象的系統中，結構中應指出要實作的主要對象，它應該規定每一個對象的責任并指出每個對象之間是如何互相作用的。其中應包括對于排序層次、狀态轉換和對象一緻性的描述。

結構中還應該指出考慮的其它對象，以及選擇這種組織形式的原因。

通用對象

有一些軟體通用的功能需要在結構設計中展現，如：使用者界面、輸入輸出、記憶體管理、字元串存儲

錯誤處理

需要提醒使用者發現了錯誤、系統需要積極地預防錯誤（如合法性驗證）、程式如何應對錯誤（對于錯誤的處理方式如抛出）、應建立一套錯誤體系、在系統中在哪一層處理錯誤

堅固性

堅固性是指在發現錯誤後，一個系統繼續運作的能力。在結構設計中需要從幾個方面表述堅固性。

over-engineering（裕度設計）

在軟體鍊條中，其強度不是由最薄弱的一環決定的，而是由所有薄弱環節的乘積決定的。

清楚地表述所要求的裕度級是非常重要的，這是因為程式員出于職業素養，會不自覺地在程式中留出裕度。

assertions（斷言）

結構中還應該規定斷言的使用程度。斷言是指一段放在代碼中，當代碼運作時可以使其自檢的可執行語句。

fault tolerance（容錯性）

性能

性能包括速度和記憶體使用。

通用的結構設計品質準則

結構中作出每一個決定的動機都要闡明清楚。要當心“我們過去一直是這麼幹的”的理由。

好的軟體結構往往是機器和語言互相獨立。減少對實作環境的依賴性。

檢查表

一個好的結構設計應該闡明所有問題。

• 軟體的總體組織形式是否清晰明了？包括對于結構設計的總體評論與描述。
• 子產品定義是否清楚？包括它們的功能及其與其它子產品的接口。
• 要求定義中所提出的所有功能，是否有恰當數量的子產品覆寫？
• 結構設計是否考慮了可能的更改？
• 是否包括了必要的購買？
• 是否闡明了如何改進重新啟用的代碼來滿足現在的結構設計要求？
• 是否描述并驗證了所有主要的資料結構？
• 主要資料結構是否隐含在存取子程式中？
• 規定資料庫組織形式和其它内容了嗎？
• 是否說明并驗證所有關鍵算法？
• 是否說明驗證所有主要目标？
• 說明處理使用者輸入的政策了嗎？
• 說明并驗證處理輸入／輸出的政策了嗎？
• 是否定義了使用者界面的關鍵方面？
• 使用者界面是否進行了子產品化，以使對它所作的改動不會影響程式其它部分
• 是否描述并驗證了記憶體使用估算和記憶體管理？
• 是否對每一子產品給出了存儲空間和速度限制？
• 是否說明了字元串處理政策？是否提供了對字元串占用空間的估計？
• 所提供的錯誤處理政策是不是一緻的？
• 是否對錯誤資訊進行了成套化管理以提供一個整潔的使用者界面？
• 是否指定了堅固性級别？
• 有沒有哪一部分結構設計被過分定義或缺少定義了？它是否明确說明了；
• 是否明确提出了系統目标？
• 整個結構在概念上是否是一緻的？
• 機器和使用實作的語言是否頂層設計依賴？
• 給出做出每個重要決定的動機了嗎？
• 你作為系統實作者的程式員，對結構設計滿意嗎？