📢 本文由 gemini-2.5-flash 翻譯
系統設計的基本原理
抽象、模組化、資訊隱蔽、模組獨立
模組化
在軟體的體系結構中,模組是可組合、分解和更換的單元
模組化是指將一個待開發的軟體分解成若干個小而簡單的部分,即模組。每個模組可獨立地開發、測試,最後組裝成完整的程式。這是一種複雜問題「分而治之」的原則。模組化的目的是使程式的結構清晰,容易閱讀、理解、測試和修改
模組獨立
模組獨立是指每個模組完成一個相對獨立的特定子功能,並且與其他模組之間的聯繫簡單。衡量模組獨立程度的標準有兩個:耦合性與內聚性
耦合
耦合是模組之間的相對獨立性 (互相連接的緊密程度) 的度量。耦合取決於各個模組之間介面的複雜程度、呼叫模組的方式以及透過介面的資訊類型等。一般模組之間可能的耦合方式有 7 種類型

- 無直接耦合。指兩個模組之間沒有直接關係,它們分別從屬於不同模組的控制與呼叫,它們之間不傳遞任何資訊
- 資料耦合。指兩個模組之間有呼叫關係,傳遞的是簡單的資料值,相當於高階語言中的值傳遞
- 標記耦合。指兩個模組之間傳遞的是資料結構
- 控制耦合。指一個模組呼叫另一個模組,傳遞的是控制變數,被呼叫模組透過控制該控制變數的值有選擇地執行模組內部的某一功能
- 外部耦合。模組之間透過軟體之外的環境連結 (如 I/O 將模組耦合到特定的裝置、格式、通訊協定上) 時稱為外部耦合
- 共同耦合。指透過一個共同資料環境相互作用的那些模組間的耦合
- 內容耦合。當一個模組直接使用另一個模組的內部資料,或透過非正常入口轉入另一個模組內部時,這種模組之間的耦合稱為內容耦合
內聚
內聚是對一個模組內部各個元素彼此結合的緊密程度的度量。一個內聚程度高的模組 (在理想情況下) 應當只做一件事。一般模組的內聚性分為 7 種類型

- 偶然內聚 (巧合內聚) 。指一個模組內的各處理元素之間沒有任何聯繫
- 邏輯內聚。指模組內執行若干個邏輯上相似的功能,透過參數確定該模組完成哪一個功能
- 時間內聚。把需要同時執行的動作組合在一起形成的模組稱為時間內聚模組
- 程序內聚。指一個模組完成多個任務,這些任務必須按指定的程序執行
- 通訊內聚。指模組內的所有處理元素都在同一個資料結構上操作,或者各處理使用相同的輸入資料或者產生相同的輸出資料
- 順序內聚。指一個模組中的各個處理元素都密切相關於同一功能且必須順序執行,前一功能元素的輸出就是下一功能元素的輸入
- 功能內聚。這是最強的內聚,指模組內的所有元素共同作用完成一個功能,缺一不可
耦合性與內聚性是模組獨立性的兩個定性標準,在將軟體系統劃分模組時,應盡量做到高內聚、低耦合,提升模組的獨立性
系統結構設計原則
為確保整體結構設計順利完成,應遵循以下幾條原則
- 分解-協調原則。整個系統是一個整體,具有整體目的與功能,但這些目的與功能的實現又是由相互聯繫的各個組成部分共同工作的結果。解決複雜問題的一個很重要的原則就是將其分解成多個小問題分別處理,在處理過程中根據系統總體要求協調各部門的關係
- 由上而下的原則。首先抓住系統總體的功能目的,然後逐層分解,即先確定上層模組的功能,再確定下層模組的功能
- 資訊隱蔽、抽象的原則。上層模組只規定下層模組要做什麼和所屬模組之間的協調關係,但不規定如何做,以確保各模組的相對獨立性與內部結構的合理性,使得模組與模組之間層次分明,易於理解、實施和維護
- 一致性原則。要確保整個軟體設計過程中具有統一的規範、統一的標準和統一的文件模式等
- 明確性原則。每個模組必須功能明確、介面正確,消除多重功能和無用介面
- 模組之間的耦合盡可能小,模組的內聚度盡可能高
- 模組的扇入係數與扇出係數要合理。一個模組直接呼叫其他模組的個數稱為模組的扇出係數;反之,一個模組被其他模組呼叫時,直接呼叫它的模組個數稱為模組的扇入係數。模組的扇入、扇出係數必須適當。經驗表明,一個設計得好的系統的平均扇入、扇出係數通常是 3 或 4,一般不應超過 7,否則會導致錯誤機率的增大。但選單呼叫型模組的扇入與扇出係數可以大一些,共用模組的扇入係數可以大一些
- 模組的規模適當。過大的模組常常使系統分解得不充分,其內部可能包含了若干部分的功能,因此有必要進一步將原有的模組分解成若干功能盡可能單一的模組。但分解也必須適度,因為過小的模組有可能降低模組的獨立性,造成系統介面的複雜性
- 模組的作用範圍應該在其控制範圍之內
系統文件
資訊系統的文件是系統建置過程的「軌跡」,是系統維護人員的指南,是開發人員與使用者交流的工具。規範的文件意味著系統是按照工程化開發的,意味著資訊系統的品質有了形式上的保障。文件的欠缺、文件的隨意性與文件的不規範,極有可能導致原來的開發人員流動之後,系統無法維護、無法升級,變成一個沒有擴充性、沒有生命力的系統
對於文件在系統開發人員、專案管理人員、系統維護人員、系統評估人員以及使用者之間的各種作用總結如下
- 使用者與系統分析人員在系統規劃與系統分析階段透過文件進行溝通。這裡的文件主要包括可行性研究報告、總體規劃報告、系統開發合約與系統方案說明書
- 系統開發人員與專案管理人員透過文件在專案期內進行溝通。這裡的文件主要有系統開發計畫 (包括工作任務分解表、PERT 圖、甘特圖和預算分配表等) 、系統開發月報以及系統開發總結報告等專案管理文件
- 系統測試人員與系統開發人員透過文件進行溝通。系統測試人員可以根據系統方案說明書、系統開發合約、系統設計說明書和測試計畫等文件對系統開發人員所開發的系統進行測試。系統測試人員再將評估結果撰寫成系統測試報告
- 系統開發人員與使用者在系統運行期間進行溝通。使用者透過系統開發人員撰寫的文件運行系統。這裡的文件主要是使用者手冊與操作指南
- 系統開發人員與系統維護人員透過文件進行溝通。這裡的文件主要有系統設計說明書與系統開發總結報告
- 使用者與維修人員在運行維護期間進行溝通。使用者在使用資訊系統的過程中,將運行過程中的問題進行記載,形成系統運行報告與維護修改建議。系統維護人員根據維護修改建議以及系統開發人員留下的技術手冊等文件對系統進行維護與升級