軟體工程之軟體設計方法－BY CKER(HTML版) )

軟體工程之軟體設計方法－BY CKER(HTML版)

THE DESIGN PROCESS
（軟體）設計方法

做好的程式員一如做人。多看多想或許他山之石可以攻玉，永遠不要成為代碼的奴隸。 CKER

原著：Larry Brinn                     翻譯: CKER

1. 簡介
2.（軟體）設計是什嗎？
3.（軟體）設計過程
4.（軟體）設計基礎
5.（軟體）設計方法論
6.（軟體）設計文檔
7.物件導向的（軟體）設計
8.結論

簡介
您是如何開始一個新工程的？是不是跳到電腦前，開啟您喜愛的RAD工具開始輸入代碼？有沒有想過程式會執行些什麼或者系統是如何操縱資料的？有沒有想過要記下些東西來協助提醒您或闡明您已經開發的代碼的邏輯實現？如果您對第一個問題答"不"，而其他問題答"是"的話，您可以跳過這篇文檔。否則的話，請好好讀讀這篇文章。您應該有個計劃、藍圖，並且在手邊有個對您的問題解決方案的簡明安排。"您必須知道您要去哪兒得到一切！"讓我們來看看開發一個能實現您所設計的功能的程式時，什麼最棘手。

（軟體）設計是什嗎？
E.S. Taylor給設計下的定義是:
"…the process of applying various techniques and principles for the purpose of defining a device, a process or a system in sufficient detail to permit its physical realization. "
"…應用各種各樣的技術和原理，並用它們足夠詳細的定義一個裝置、一個程式或系統的物理實現的過程。 "
對任意的工程產品或系統，開發階段絕對的第一步是確定將來所要構建的製造原型或實體表現的目標構思。這個步驟是由多方面的直覺與判斷力來共同決定的。這些方麵包括構建類似模型的經驗、一組引領模型發展的原則、一套啟動品質評價的標準、以及重複修改直至設計最後定型的過程本身。電腦軟體設計與其他工程學科相比還處在幼年時期，仍在不斷變化中，例如更新的方法、更好的演算法分析、以及理解力的顯著進化。軟體設計的方法論的出現也只有三十年多一點，仍然缺乏深度、適應性和定量性質，通常更多的與經典工程設計學科相聯絡。儘管如此，現今的軟體技術已經存在、設計品質的標準也可使用、設計符號亦可以應用。帶著這些意見，我們一起來看看什麼有助於程式員們找到他們的軟體涅盤(天堂的意思)。

（軟體）設計過程
軟體的設計是一個將需求轉變為軟體陳述（表達）的過程。這種陳述給我們一個對軟體的全域觀點。系統通過逐步求精使得設計陳述逐漸接近原始碼。這裡有兩個基本步驟；第一步是初步設計Preliminary design ，關注於如何將需求轉換成資料和軟體架構。第二步是詳細設計Detail design ，關注於將架構逐步求精細化為具體的資料結構和軟體的演算法表達。發生中的設計行為、資料、演算法和程式設計都需要由現代程式所需的介面設計這一清晰的行為來結合起來。介面設計Interface design 建立程式布局和人機互動機制。貫穿設計過程的品質由一系列的正式技術評定formal technical reviews 或設計排演design walkthroughs 來評價。良好的設計規範必須建立在對設計陳述（表達）的評估之上，以下是一些指導方針：
1. 設計應該展現階層使得軟體各部分之間的控制更明智。
2. 設計應當模組化；這就是說，軟體應在邏輯上分割為實現特定的功能和子功能的部分。
3. 設計應當由清晰且可分離的資料和過程表達來構成。
4. 設計應使得模組展現獨立的功能特性。
5. 設計應使得介面能降低模組之間及其與外部環境的串連複雜性。
6. 設計應源自於軟體需求分析期間獲得的資訊所定之可重複方法的使用。
要擁有良好的設計特徵不是靠碰運氣，而在設計過程中通過綜合運用基礎設計原理、系統方法論、徹底的評定回顧可以有助於良好的設計。軟體設計方法每天都在進化，作為已經經過測試和細化的方法，良好的設計應具有以下的四種特性，並在所有這些特性之間保持一致。
1. 將資訊領域的表達轉換為軟體設計的表達的機制。
2. 表示功能組件及其介面的符號。
3. 逐步求精和分割的試探。
4. 品質評估的指導方針。
開發軟體的時候，不管採用何種設計方法您必須能夠熟練運用一套關於資料、演算法和程式設計的基本原理。

（軟體）設計基礎
軟體設計方法論的這套基本原理已經經過了多年的進化。每種概念的影響程度不盡相同，但它們都經曆了時間的洗禮。基於這些基本原理設計者可以採用更多更成熟的設計方法。這些基本原理有助於設計者回答以下的問題：
1. 將軟體分割成獨立的組件時會採用何種標準？
2. 怎樣將軟體的原則性表示詳細分割成函數或資料結構？
3. 有沒有定義一個軟體設計的技術品質的統一標準？
M.A. Jackson曾經說過："對一個電腦程式員來說，分辨讓程式運行和讓程式正確 之間的差異是一個良好的開端。"為了 "使程式正確 "，基本設計原理提供了必須的架構。因此讓我們來對這些基本原理作個簡短的檢視。
抽象Abstraction 在最高層次上指的是使用待解決的問題領域內的術語描述的解決方案。相對較低層次的抽象則更多的面向程式語言，最低層的抽象則是解決方案的可直接實現的方式描述。軟體設計的每一個步驟都是對相應層次解決方案的抽象的逐步求精。
求精Refinement 又叫做逐步求精指的是通過程式細節連續細化來開發程式體系的策略。分步驟的對程式抽象進行分解直至成為程式設計語言的過程同時造就了程式的階層。在這一點上要對細節多做考慮，這也展示了求精實際上是個苦心經營的過程。
模組化Modularity 指的是軟體可被分割為分別命名並可定址的組件（也叫做模組），將模組綜合起來又可以滿足問題的需求的性質。"軟體的模組化是允許智能化管理程式的唯一屬性。"換句話說，當您將一個複雜問題分解為一些小問題時會更容易解決。需要重點解釋的是即使一個系統必須象"單片機"一樣來實現，它也可以採用模組化設計。
軟體體系（架構）Software Architecture 涉及到程式的兩個重要特性：1)模組的階層。2)資料結構。這源自於需求分析時將真實世界問題的含蓄定義與軟體解決方案的要素關聯起來的分割過程。當問題的每個部分通過一個或多個軟體要素得到解決後，與問題的定義和解決相一致軟體和資料結構的進化就開始了。這個過程代表了軟體的需求分析和設計之間的位置。
控制層級Control Hierarchy 也稱作程式結構，描述程式組件的組織並意味著控制層級。它並不描述軟體的程式方面，比如進程順序、決定的事件/命令、或工作迴圈。如下的層級圖表展示了模組之間的通訊流，並顯示哪些模組是重複的（右上方變黑的塊）。這個圖表描述了一個能夠讀檔案，計算每個記錄的值並書寫報表來顯示記錄的資訊和所完成的計算。

資料結構Data structure 描述了單個資料間的邏輯關係。資料結構規定了資料的組織、存取方法、關聯程度、和資訊的選擇處理。資料結構的組織和複雜性只受限於設計者的靈活性。唯一的限制就是經典資料結構的數量阻礙了更多的久經考驗的結構出現。
軟體程式Software Procedure 著重於處理每個模組的細節並必須提供一個精確的處理規範，包括事件順序、準確的判定點、重複操作、甚至資料結構。軟體的程式表現是分層的，處理方法應該包括其所有子模組的參考。
資訊隱藏Information Hiding 的法則建議由設計決定所刻劃的模組特性應該對其餘的模組不可見 。換句話說，模組應被設計和指定為包含在模組內部且其他模組不可訪問的內容對其他模組來說是無需的。隱藏意味著有效模組效能夠通過定義一套獨立的模組來實現，這些模組相互之間的通訊僅僅包括實現軟體功能的所必須的資訊。將使用資訊隱藏作為設計標準在測試或今後的維護期間需要修改系統時帶來了最大的好處。 

（軟體）設計方法論
讓我們來遍曆設計過程中用以促成模組化設計的四個地區：模組Modular、資料Data、體系Architectural 和程式Procedural 設計。
模組設計Modular design 減低了複雜性、便於修改、且使得支援系統不同部分的並行開發實現起來更容易。模組類型提供的操作特性通過結合時間曆史、啟用機制、和控制模式來表現。在程式結構內部，模組可以被分類為：
1. 順序sequential模組，由應用程式引用和執行，但不能從表觀上中斷。
2. 增量incremental模組，可被應用程式先行中斷，而後再從中斷點重新開始。
3. 並行parallel模組，在多處理器環境下可以與其他模組同時執行。
單獨的模組更容易開發，因為功能可以被劃分出來，而介面只是用來確保功能的獨立。功能的獨立性可以使用兩個定性的標準來衡量：凝聚性cohesion －衡量模組的功能強度的相關性，和耦合性coupling －衡量模組間的相互依賴的相關性。
資料設計Data design 首先並且有些人也堅信，是最重要的設計行為。資料結構的影響和程式上的複雜性導致資料設計對軟體品質有著深遠的影響。這種品質由以下的原理來實施：
1. 適用於功能和行為分析的系統分析原理同樣應該適用於資料。
2. 所有的資料結構，以及各自所完成的操作都應該被確定。
3. 建立資料詞典並用來詳細說明資料和程式的設計。
4. 底層的資料設計決定應該延遲至設計過程的後期。
5. 資料結構的陳述（具體說明）應該只被那些直接使用包含在此結構內的資料的模組所知道。
6. 有用的資料結構和操作庫可以在適當的時候使用。
7. 軟體設計和程式設計語言應該支援抽象資料類型的規範和實現。
體系設計Architectural Design 的主要目標是開發模組化的程式結構並表達出模組間的控制相關性。另外，體系設計融合了程式結構與資料結構，以及使得資料得以在程式中流動的介面定義。這種方法鼓勵設計者關注系統的整體設計而不是系統中單獨的組件。選用不同的方法會採用不同的途徑來接近體系的原點，但所有這些方法都應該認識到具有軟體全域觀念的重要性。
程式設計Procedural Design 在資料、程式結構、和陳述詳細演算法的說明都已使用類似英語的自然語言來呈現後，再確定程式設計。使用自然語言來陳述的原因是當開發小組的絕大多數成員使用自然語言來交流的話，那麼小組外的一個新手在不經學習的情況下會更容易理解這些說明。這裡有個問題：程式設計必須毫無歧義的來詳細說明程式，但我們都知道不含糊的自然語言也就不自然了。

（軟體）設計文檔
在任何系統中，開發文檔都是有價值的東西。現在已經有許多不同的經過發展的文檔計劃可供您在建立系統時候進行選擇。其中相當不錯的一種模型就是所謂的設計規範（譯者註：此處原有的超連結已經失效，所以無法得到其原始的模板。但CKER還有一套被稱作的APM的文件範本似乎不錯。以後也許會翻給大家來看看……^_^）。 當您察看此文檔的大綱的時候,請注意各層級的詳細內容。第一部分展示了源自於系統說明和其他定義文檔的設計成果的總體範圍。第二部分展示的是涉及支援文檔的詳細說明。第三部分的內容又稱作設計描述，在初步設計階段完成。第四、五部分的內容將初步設計階段的內容發展至詳細設計階段。第六部分展示了確保以下兩條原則的交叉參考矩陣：
1. 用軟體設計滿足所有的需求。
2. 指出實現特定需求的關鍵模組。
第七部分在開發測試程式（步驟）的第一步對系統的功能性和正確性進行測試是必要的。如果在開發設計規範的同時已經並行開發了詳細的測試程式規範的話，本部分可以刪除。第八部分詳細說明了將系統打包傳送至使用者網站的考慮和要求。在文檔剩下的第九、十部分中包括了演算法描述、選擇程式、列表資料、流程圖、虛擬碼、資料流程圖、以及所有在設計規範開發時所用到的相關資訊都可以放在此處。

物件導向的（軟體）設計
到目前為止我們所詳細說明的一切都是如今在IT領域被廣泛使用的設計方法論的基石。物件導向的設計（OOD）通過模組化資訊及其加工方法而不單單是加工方法來讓資料對象和加工操作得以互相串連。這個過程依賴於三個極其重要的設計概念：抽象、資訊隱藏、和模組化。所有的設計方法都力爭展現這些特性；但只有OOD的機制才能使設計者能夠無需增加複雜性或加以折衷就獲得所有三種特性。在OOD中，我們有objects（對象）, operations（操作） ,和 messages（訊息） 。Objects（對象 ）,又稱作類，可以是人、機器、命令、檔案、汽車、房子，等等。operations（操作） ,包含了私人的資料結構和用於變換資料結構的加工方法。messages（訊息） 用於啟用叫用作業控制和對象的程式構造。這就是說對象的共用部分是其的介面而訊息在介面之間移動並指定希望使用對象的何種操作，但並不知道操作是怎樣具體實現的。對象在收到訊息之後決定如何來執行訊息。現在讓我們來看看在物件導向的系統中的某些工具是如何使用的：
1. 虛擬碼 － 接近電腦程式設計語言的指令，但使用的是近似英語的語言而不是真正的程式設計語言以便於查看程式邏輯。下面是一個加工檔案中的記錄的範例:
Start (開始)
Initialize program (初始化程式)
Read a record (讀一個記錄)
Process record (加工記錄)
Move record to print area (將記錄移至列印區)
Write a line (寫一行)
End job (結束任務)
Stop run. (停止運行)
2. 原型 － 在開發軟體包的第一個版本或模型，或者電腦硬體準備好作生產前測試時的步驟。通常可以使用您所喜愛的RAD工具來建立。
3. TOE圖表 － (Task 任務, Object 對象, Event 事件 圖表)用來展示需要完成的任務或工作、執行工作的對象、以及完成此過程的事件或動作。請看下面將兩個數相加的TOE圖表：
任務 對象 事件
啟動程式 Main Form OnStartup
輸入第一個數 EdtFirstNumber User types in
輸入第二個數 EdtSecondNumber User types in
求和 EdtResult OnClick
程式退出 BtnExit OnClick
正如您在上例中所見，這正確說明了要執行什麼、誰來執行、以及什麼時候來執行。

結論
正如一開始所說的"您必須知道您要去哪兒得到一切"，並且遵循特定的路徑或方法可以給您所需的信心來實現您試圖開發的系統。有很多方法可以遵循，在這裡只想說幾句話：您應該採用能被小組和您自己都能接受的方式。您所選擇的方式應該讓所有您計劃中可能使用的人感覺簡單明了和易於理解。試試在您的頭腦中記住後面這個縮寫的意義：KISS (Keep It Short and Simple)<讓您的代碼保持短小簡單>。

設計時的參考良書:
"Software Engineering, A practitioner's approach 3rd edition", by Roger S. Pressman.
"Object-Oriented Design", by Peter Coad and Edward Yourdon

著作權說明：
國內的網站上，似乎有許多關於C++Builder的內容，但多以軟體、組件為主。論壇也大都不太令人滿意，很空虛的感覺。書籍又都昂貴，內容卻有搶錢之嫌。對銀子不足的初學者、自學者關愛不夠，因而想盡自己的綿薄之力。文中的所有資料都是從國外網站上收集而來。因為E文不方便，所以翻成中文。由於E文和電腦都不是非常好，文中的錯誤在所難免。若大家覺得有用的話，我計劃不斷搜集翻譯一些有用的東西。您可以隨意複製、分發、下載此文檔。未經本人同意，您不可以截取、改動本文片斷，或用本文謀取任何形式的利益。
有任何意見和建議請寫信： cker@sina.com