1. 程式人生 > >先決條件(二)結構設計

先決條件(二)結構設計

文章目錄

結構設計先決條件

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

典型的結構要素

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

程式的組織形式

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

每一個模組作什麼應該明確定義。一個模組應該只完成一項任務而且圓滿完成。對於與它相作用的其它模組情況,你知道得越少越好。通過儘可能地降低模組之間的瞭解程度,就可能把設計資訊都集中在一個模組中。
每個模組之間的交介面也應該明確定義。結構設計應該規定可以直接呼叫哪些模組,哪些模組它不能呼叫。同時,結構設計也應該定義模組傳送和從其它模組接收的資料。

變動策略

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

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

購買而不是建造的決定

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

主要的資料結構

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

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

關鍵演算法

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

主要物件

在面向物件的系統中,結構中應指出要實現的主要物件,它應該規定每一個物件的責任並指出每個物件之間是如何相互作用的。其中應包括對於排序層次、狀態轉換和物件一致性的描述。
結構中還應該指出考慮的其它物件,以及選擇這種組織形式的原因。

通用物件

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

錯誤處理

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

堅固性

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

over-engineering(裕度設計)

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

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

assertions(斷言)

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

fault tolerance(容錯性)

效能

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

通用的結構設計質量準則

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

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

檢查表

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

  • 軟體的總體組織形式是否清晰明瞭?包括對於結構設計的總體評論與描述。
  • 模組定義是否清楚?包括它們的功能及其與其它模組的介面。
  • 要求定義中所提出的所有功能,是否有恰當數量的模組覆蓋?
  • 結構設計是否考慮了可能的更改?
  • 是否包括了必要的購買?
  • 是否闡明瞭如何改進重新啟用的程式碼來滿足現在的結構設計要求?
  • 是否描述並驗證了所有主要的資料結構?
  • 主要資料結構是否隱含在存取子程式中?
  • 規定資料庫組織形式和其它內容了嗎?
  • 是否說明並驗證所有關鍵演算法?
  • 是否說明驗證所有主要目標?
  • 說明處理使用者輸入的策略了嗎?
  • 說明並驗證處理輸入/輸出的策略了嗎?
  • 是否定義了使用者介面的關鍵方面?
  • 使用者介面是否進行了模組化,以使對它所作的改動不會影響程式其它部分
  • 是否描述並驗證了記憶體使用估算和記憶體管理?
  • 是否對每一模組給出了儲存空間和速度限制?
  • 是否說明了字串處理策略?是否提供了對字串佔用空間的估計?
  • 所提供的錯誤處理策略是不是一致的?
  • 是否對錯誤資訊進行了成套化管理以提供一個整潔的使用者介面?
  • 是否指定了堅固性級別?
  • 有沒有哪一部分結構設計被過分定義或缺少定義了?它是否明確說明了;
  • 是否明確提出了系統目標?
  • 整個結構在概念上是否是一致的?
  • 機器和使用實現的語言是否頂層設計依賴?
  • 給出做出每個重要決定的動機了嗎?
  • 你作為系統實現者的程式設計師,對結構設計滿意嗎?