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