摘要：
本文是在概要設計實(shí)踐和學(xué)習中的一些心得與學(xué)習筆記，希望與大家分享，如有不妥之處歡迎指正。
關(guān)鍵字：
概要設計，結構化，OOD
正文：
在需求明確、準備開(kāi)始編碼之前，要做概要設計，而詳細設計可能大部分公司沒(méi)有做，有做的也大部分是和編碼同步進(jìn)行，或者在編碼之后。因此，對大部分的公司來(lái)說(shuō)，概要設計文檔是唯一的設計文檔，對后面的開(kāi)發(fā)、測試、實(shí)施、維護工作起到關(guān)鍵性的影響。
一、問(wèn)題的提出
概要設計寫(xiě)什么？概要設計怎么做？
如何判斷設計的模塊是完整的？
為什么說(shuō)設計階段過(guò)于重視業(yè)務(wù)流程是個(gè)誤區？
以需求分析文檔還是以概要設計文檔來(lái)評估開(kāi)發(fā)工作量、指導開(kāi)發(fā)計劃準確？
結構化好還是面向對象好？
以上問(wèn)題的答案請在文章中找。
二、概要設計的目的
將軟件系統需求轉換為未來(lái)系統的設計；
逐步開(kāi)發(fā)強壯的系統構架；
使設計適合于實(shí)施環(huán)境，為提高性能而進(jìn)行設計；
結構應該被分解為模塊和庫。
三、概要設計的任務(wù)
制定規范：代碼體系、接口規約、命名規則。這是項目小組今后共同作戰的基礎，有了開(kāi)發(fā)規范和程序模塊之間和項目成員彼此之間的接口規則、方式方法，大家就有了共同的工作語(yǔ)言、共同的工作平臺，使整個(gè)軟件開(kāi)發(fā)工作可以協(xié)調有序地進(jìn)行。
總體結構設計：
功能（加工）－>模塊：每個(gè)功能用那些模塊實(shí)現，保證每個(gè)功能都有相應的模塊來(lái)實(shí)現；
模塊層次結構：某個(gè)角度的軟件框架視圖；
模塊間的調用關(guān)系：模塊間的接口的總體描述；
模塊間的接口：傳遞的信息及其結構；
處理方式設計：滿(mǎn)足功能和性能的算法
用戶(hù)界面設計；
數據結構設計：
詳細的數據結構：表、索引、文件；
算法相關(guān)邏輯數據結構及其操作；
上述操作的程序模塊說(shuō)明（在前臺？在后臺？用視圖？用過(guò)程？······）
接口控制表的數據結構和使用規則
其他性能設計。
四、概要設計寫(xiě)什么
結構化軟件設計說(shuō)明書(shū)結構（因篇幅有限和過(guò)時(shí)嫌疑，在此不作過(guò)多解釋?zhuān)?br> 任務(wù)：目標、環(huán)境、需求、局限；
總體設計：處理流程、總體結構與模塊、功能與模塊的關(guān)系；
接口設計：總體說(shuō)明外部用戶(hù)、軟、硬件接口；內部模塊間接口（注：接口≈系統界面）
數據結構：邏輯結構、物理結構，與程序結構的關(guān)系；
模塊設計：每個(gè)模塊“做什么”、簡(jiǎn)要說(shuō)明“怎么做”（輸入、輸出、處理邏輯、與其它模塊的接口，與其它系統或硬件的接口），處在什么邏輯位置、物理位置；
運行設計：運行模塊組合、控制、時(shí)間；
出錯設計：出錯信息、處錯處理；
其他設計：保密、維護；
OO軟件設計說(shuō)明書(shū)結構
1 概述
系統簡(jiǎn)述、軟件設計目標、參考資料、修訂版本記錄
這部分論述整個(gè)系統的設計目標，明確地說(shuō)明哪些功能是系統決定實(shí)現而哪些時(shí)不準備實(shí)現的。同時(shí)，對于非功能性的需求例如性能、可用性等，亦需提及。需求規格說(shuō)明書(shū)對于這部分的內容來(lái)說(shuō)是很重要的參考，看看其中明確了的功能性以及非功能性的需求。
這部分必須說(shuō)清楚設計的全貌如何，務(wù)必使讀者看后知道將實(shí)現的系統有什么特點(diǎn)和功能。在隨后的文檔部分，將解釋設計是怎么來(lái)實(shí)現這些的。
2 術(shù)語(yǔ)表
對本文檔中所使用的各種術(shù)語(yǔ)進(jìn)行說(shuō)明。如果一些術(shù)語(yǔ)在需求規格說(shuō)明書(shū)中已經(jīng)說(shuō)明過(guò)了，此處不用再重復，可以指引讀者參考需求說(shuō)明。
3 用例
此處要求系統用用例圖表述（UML），對每個(gè)用例（正常處理的情況）要有中文敘述。
4 設計概述
4.1 簡(jiǎn)述
這部分要求突出整個(gè)設計所采用的方法（是面向對象設計還是結構化設計）、系統的體系結構（例如客戶(hù)/服務(wù)器結構）以及使用到的相應技術(shù)和工具（例如OMT、Rose）
4.2 系統結構設計
這部分要求提供高層系統結構（頂層系統結構、各子系統結構）的描述，使用方框圖來(lái)顯示主要的組件及組件間的交互。最好是把邏輯結構同物理結構分離，對前者進(jìn)行描述。別忘了說(shuō)明圖中用到的俗語(yǔ)和符號。
4.3 系統界面
各種提供給用戶(hù)的界面以及外部系統在此處要予以說(shuō)明。如果在需求規格說(shuō)明書(shū)中已經(jīng)對用戶(hù)界面有了敘述，此處不用再重復，可以指引讀者參考需求說(shuō)明。如果系統提供了對其它系統的接口，比如說(shuō)從其它軟件系統導入/導出數據，必須在此說(shuō)明。
4.4 約束和假定
描述系統設計中最主要的約束，這些是由客戶(hù)強制要求并在需求說(shuō)明書(shū)寫(xiě)明的。說(shuō)明系統是如何來(lái)適應這些約束的。
另外如果本系統跟其它外部系統交互或者依賴(lài)其它外部系統提供一些功能輔助，那么系統可能還受到其它的約束。這種情況下，要求清楚地描述與本系統有交互的軟件類(lèi)型以及這樣導致的約束。
實(shí)現的語(yǔ)言和平臺也會(huì )對系統有約束，同樣在此予以說(shuō)明。
對于因選擇具體的設計實(shí)現而導致對系統的約束，簡(jiǎn)要地描述你的想法思路，經(jīng)過(guò)怎么樣的權衡，為什么要采取這樣的設計等等。
5 對象模型
提供整個(gè)系統的對象模型，如果模型過(guò)大，按照可行的標準把它劃分成小塊，例如可以把客戶(hù)端和服務(wù)器端的對象模型分開(kāi)成兩個(gè)圖表述。在其中應該包含所有的系統對象。這些對象都是從理解需求后得到的。要明確哪些應該、哪些不應該被放進(jìn)圖中。所有對象之間的關(guān)聯(lián)必須被確定并且必須指明聯(lián)系的基數。聚合和繼承關(guān)系必須清楚地確定下來(lái)。每個(gè)圖必須附有簡(jiǎn)單的說(shuō)明。
6 對象描述
在這個(gè)部分敘述每個(gè)對象的細節，它的屬性、它的方法。在這之前必須從邏輯上對對象進(jìn)行組織。你可能需要用結構圖把對象按子系統劃分好。
為每個(gè)對象做一個(gè)條目。在系統對象模型中簡(jiǎn)要的描述它的用途、約束（如只能有一個(gè)實(shí)例），列出它的屬性和方法。如果對象是存儲在持久的數據容器中，標明它是持久對象，否則說(shuō)明它是個(gè)臨時(shí)對象（transient object）。
對每個(gè)對象的每個(gè)屬性詳細說(shuō)明：名字、類(lèi)型，如果屬性不是很直觀(guān)或者有約束（例如，每個(gè)對象的該屬性必須有一個(gè)唯一的值或者值域是有限正整數等）。
對每個(gè)對象的每個(gè)方法詳細說(shuō)明：方法名，返回類(lèi)型，返回值，參數，用途以及使用的算法的簡(jiǎn)要說(shuō)明（如果不是特別簡(jiǎn)單的話(huà)）。如果對變量或者返回值由什么假定的話(huà)，Pre-conditions和Post-conditions必須在此說(shuō)明。列出它或者被它調用的方法需要訪(fǎng)問(wèn)或者修改的屬性。最后，提供可以驗證實(shí)現方法的測試案例。
7 動(dòng)態(tài)模型
這部分的作用是描述系統如何響應各種事件。一般使用順序圖和狀態(tài)圖。
確定不同的場(chǎng)景（Scenario）是第一步，不需要確定所有可能的場(chǎng)景，但是必須至少要覆蓋典型的系統用例。不要自己去想當然地創(chuàng )造場(chǎng)景，通常的策略是描述那些客戶(hù)可以感受得到的場(chǎng)景。
7.1 場(chǎng)景（Scenarios）
對每個(gè)場(chǎng)景做一則條目，包括以下內容：
場(chǎng)景名：給它一個(gè)可以望文生義的名字
場(chǎng)景描述：簡(jiǎn)要敘述場(chǎng)景是干什么的以及發(fā)生的動(dòng)作的順序。
順序圖：描述各種事件及事件發(fā)生的相對時(shí)間順序。
7.2 狀態(tài)圖
這部分的內容包括系統動(dòng)態(tài)模型重要的部分的狀態(tài)圖?？赡苣阆霝槊總€(gè)對象畫(huà)一個(gè)狀態(tài)圖，但事實(shí)上會(huì )導致太多不期望的細節信息，只需要確定系統中一些重要的對象并為之提供狀態(tài)圖即可。
8 非功能性需求
五、概要設計怎么做
結構化軟件設計方法：
詳細閱讀需求規格說(shuō)明書(shū)，理解系統建設目標、業(yè)務(wù)現狀、現有系統、客戶(hù)需求的各功能說(shuō)明；
分析數據流圖，弄清數據流加工的過(guò)程；
根據數據流圖決定數據處理問(wèn)題的類(lèi)型（變換型、事務(wù)型、其他型）；
通過(guò)以上分析，推導出系統的初始結構圖；
對初始結構圖進(jìn)行改進(jìn)完善：所有的加工都要能對應到相應模塊（模塊的完整性在于他們完成了需求中的所有加工），消除完全相似或局部相似的重復功能（智者察同），理清模塊間的層次、控制關(guān)系，減少高扇出結構，隨著(zhù)深度增大扇入，平衡模塊大小。
由對數據字典的修改補充完善，導出邏輯數據結構，導出每種數據結構上的操作，這些操作應當屬于某個(gè)模塊。
確定系統包含哪些應用服務(wù)系統、客戶(hù)端、數據庫管理系統；
確定每個(gè)模塊放在哪個(gè)應用服務(wù)器或客戶(hù)端的哪個(gè)目錄、哪個(gè)文件（庫），或是在數據庫內部建立的對象。
對每個(gè)篩選后的模塊進(jìn)行列表說(shuō)明。
對邏輯數據結構進(jìn)行列表說(shuō)明。
根據結構化軟件設計說(shuō)明書(shū)結構對其他需要說(shuō)明的問(wèn)題進(jìn)行補充說(shuō)明，形成概要設計說(shuō)明書(shū)。
OO軟件設計方法：
在OOA基礎上設計對象與類(lèi)：在問(wèn)題領(lǐng)域分析（業(yè)務(wù)建模和需求分析）之后，開(kāi)始建立系統構架。
第一步是抽取建立領(lǐng)域的概念模型，在UML中表現為建立對象類(lèi)圖、活動(dòng)圖和交互圖。對象類(lèi)就是從對象中經(jīng)過(guò)“察同”找出某組對象之間的共同特征而形成類(lèi)：
對象與類(lèi)的屬性：數據結構；
對象與類(lèi)的服務(wù)操作：操作的實(shí)現算法；
對象與類(lèi)的各外部聯(lián)系的實(shí)現結構；
設計策略：充分利用現有的類(lèi)；
方法：繼承、復用、演化；
活動(dòng)圖用于定義工作流，主要說(shuō)明工作流的5W（Do What、Who Do、When Do、Where Do、Why Do）等問(wèn)題，交互圖把人員和業(yè)務(wù)聯(lián)系在一起是為了理解交互過(guò)程，發(fā)現業(yè)務(wù)工作流中相互交互的各種角色。
第二步是構建完善系統結構：對系統進(jìn)行分解，將大系統分解為若干子系統，子系統分解為若干軟件組件，并說(shuō)明子系統之間的靜態(tài)和動(dòng)態(tài)接口，每個(gè)子系統可以由用例模型、分析模型、設計模型、測試模型表示。軟件系統結構的兩種方式：層次、塊狀
層次結構：系統、子系統、模塊、組件（同一層之間具有獨立性）；
塊狀結構：相互之間弱耦合
系統的組成部分：
問(wèn)題論域：業(yè)務(wù)相關(guān)類(lèi)和對象(OOA的重點(diǎn))；
人機界面：窗口、菜單、按鈕、命令等等；
數據管理：數據管理方法、邏輯物理結構、操作對象類(lèi)；
任務(wù)管理：任務(wù)協(xié)調和管理進(jìn)程；
第三步是利用“4＋1”視圖描述系統架構：用例視圖及劇本；說(shuō)明體系結構的設計視圖；以模塊形式組成包和層包含概要實(shí)現模型的實(shí)現視圖；說(shuō)明進(jìn)程與線(xiàn)程及其架構、分配和相互交互關(guān)系的過(guò)程視圖；說(shuō)明系統在操作平臺上的物理節點(diǎn)和其上的任務(wù)分配的配置視圖。在RUP中還有可選的數據視圖。
第四步是性能優(yōu)化（速度、資源、內存）、模型清晰化、簡(jiǎn)單化（簡(jiǎn)單就是享受）。
六、概要設計的原則
總體原則和方法：由粗到細的原則，互相結合的原則，定性分析和定量分析相結合的方法，分解和協(xié)調的方法和模型化方法。
要系統考慮系統的一般性、關(guān)聯(lián)性、整體性和層次性。
分解協(xié)調：目的是為了創(chuàng )造更好的系統。系統分解是指將一個(gè)復雜的系統分解為若干個(gè)子系統，系統協(xié)調一是系統內協(xié)調，即根據系統的總結構、總功能、總任務(wù)和總目標的要求，使各個(gè)子系統之間互相協(xié)調配合，在各個(gè)子系統局部?jì)?yōu)化基礎上，通過(guò)內部平衡的協(xié)調控制，實(shí)現系統的整體優(yōu)化；
屏蔽抽象：從簡(jiǎn)單的框架開(kāi)始，隱含細節；
一致性：統一的規范、統一的標準、統一的文件模式；
每個(gè)模塊應當有一個(gè)統一命名的容易理解的名字；
編碼：由外向內（界面－>核心）；
面向用戶(hù)：概要設計是對于按鈕按下后系統“怎么做”的簡(jiǎn)要說(shuō)明；
模塊、組件的充分獨立性、封閉性；
同時(shí)考慮靜態(tài)結構與動(dòng)態(tài)運行；
每個(gè)邏輯對象都應當說(shuō)明其所處物理對象（非一一對應）；
每個(gè)物理對象都有合適的開(kāi)發(fā)人員，并且利于分工與組裝。（詳細說(shuō)明見(jiàn)本人另一篇文章：系統構架設計應考慮的因素）；
確立每個(gè)構架視圖的整體結構：視圖的詳細組織結構、元素的分組以及這些主要分組之間的接口；
軟件構架與使用的技術(shù)平臺密切相關(guān)，目前常用的平臺有J2EE、.NET、CORBA等等，因此具體的軟件構架人員應當具備使用這些平臺的軟件開(kāi)發(fā)經(jīng)驗；
通過(guò)需求功能與設計模塊之間的列表對應，檢查每個(gè)需求功能是否都有相應的模塊來(lái)實(shí)現，保證需求功能的可追溯性和需求實(shí)現（模塊）的完整性，同時(shí)可以檢查重復和不必要的模塊。
在需求調研分析過(guò)程中對業(yè)務(wù)處理過(guò)程了解的完整性和準確性非常重要。調查了解清楚所有的業(yè)務(wù)流程才能設計出適合各流程業(yè)務(wù)節點(diǎn)用戶(hù)業(yè)務(wù)特點(diǎn)和習慣的軟件，使開(kāi)發(fā)出來(lái)的軟件更受歡迎。當然在進(jìn)行軟件概要設計時(shí)，要盡量排除業(yè)務(wù)流程的制約，即把流程中的各項業(yè)務(wù)結點(diǎn)工作作為獨立的對象，設計成獨立的模塊，充分考慮他們與其他各種業(yè)務(wù)對象模塊的接口，在流程之間通過(guò)業(yè)務(wù)對象模塊的相互調用實(shí)現各種業(yè)務(wù)，這樣，在業(yè)務(wù)流程發(fā)生有限的變化時(shí)（每個(gè)業(yè)務(wù)模塊本身的業(yè)務(wù)邏輯沒(méi)有變的情況下），就能夠比較方便地修改系統程序模塊間的調用關(guān)系而實(shí)現新的需求。如果這種調用關(guān)系被設計成存儲在配置庫的數據字典里，則連程序代碼都不用修改，只需修改數據字典里的模塊調用規則即可。
七、概要設計的重要輸出
編碼規范：信息形式、接口規約、命名規則；
物理模型：組件圖、配置圖；
不同角度的構架視圖：用例視圖、邏輯視圖、進(jìn)程視圖、部署視圖、實(shí)施視圖、數據視圖（可選）；
系統總體布局：哪些部分組成、各部分在物理上、邏輯上的相互關(guān)系；
兩個(gè)不可忽視的輸出：
與需求功能的關(guān)系：對于需求中的每一個(gè)功能，用哪一層、哪個(gè)模塊、哪個(gè)類(lèi)、哪個(gè)對象來(lái)實(shí)現（一對多關(guān)系）；反過(guò)來(lái)，應當說(shuō)明將要創(chuàng )建的系統每一層、每個(gè)模塊、每個(gè)對象、每一個(gè)類(lèi)“做什么”，他們是為了幫助實(shí)現哪些功能（一對多關(guān)系）。（需求的顆粒度在一開(kāi)始往往是比較粗的，因此根據功能點(diǎn)對于整體項目規模的估計或得到項目WBS其誤差范圍也是比較大的。更為重要的原因是，需求往往不是編碼工作分解的準確依據，因為一個(gè)需求的功能點(diǎn)可能對應多個(gè)代碼模塊，而多個(gè)需求的功能點(diǎn)也可能只對應一個(gè)或少數代碼模塊，同時(shí)還有軟件復用等因素要考慮，因此只有在概要設計完成以后才能準確地得到詳細設計或編碼階段的二次WBS，并估計較為準確的整體項目規模。）
邏輯與物理位置：每個(gè)對象在邏輯上分別落在哪一層、哪個(gè)模塊、哪個(gè)類(lèi)；在物理上每個(gè)模塊、每個(gè)對象、每一個(gè)類(lèi)放在哪個(gè)應用服務(wù)器或客戶(hù)端的哪個(gè)目錄、哪個(gè)文件（庫），或者是建立在數據庫管理系統中的什么東東（過(guò)程、函數、視圖、觸發(fā)器等等）。
八、結構化與面向對象方法特點(diǎn)比較
1. 從概念方面看，結構化軟件是功能的集合，通過(guò)模塊以及模塊和模塊之間的分層調用關(guān)系實(shí)現；面向對象軟件是事物的集合，通過(guò)對象以及對象和對象之間的通訊聯(lián)系實(shí)現；
2. 從構成方面看，結構化軟件＝過(guò)程＋數據，以過(guò)程為中心；面向對象軟件＝（數據＋相應操作）的封裝，以數據為中心；
3. 從運行控制方面看，結構化軟件采用順序處理方式，由過(guò)程驅動(dòng)控制；面向對象軟件采用交互式、并行處理方式，由消息驅動(dòng)控制；
4. 從開(kāi)發(fā)方面看，結構化方法的工作重點(diǎn)是設計；面向對象方法的工作重點(diǎn)是分析；但是，在結構化方法中，分析階段和設計階段采用了不相吻合的表達方式，需要把在分析階段采用的具有網(wǎng)絡(luò )特征的數據流圖轉換為設計階段采用的具有分層特征的結構圖，在面向對象方法中則不存在這一問(wèn)題。
5. 從應用方面看，相對而言，結構化方法更加適合數據類(lèi)型比較簡(jiǎn)單的數值計算和數據統計管理軟件的開(kāi)發(fā)；面向對象方法更加適合大型復雜的人機交互式軟件和數據統計管理軟件的開(kāi)發(fā)；
參考文獻：
《實(shí)用軟件工程》第二版，鄭人杰、殷人昆、陶永雷等著(zhù)
《微軟項目：求生法則》Steve McConnell著(zhù)，余孟學(xué)譯
《軟件工程：實(shí)踐者的研究方法》（第5版）Roger S.Pressman著(zhù)
《軟件構架實(shí)踐》SEI軟件工程譯叢，林·巴斯著(zhù)
《RUP2000》電子版；
《UML與系統分析設計》張龍祥著(zhù)；
《面向對象的分析與設計》楊正甫著(zhù)；
本文作者郵箱：luls@dragonsoft.com.cn或lulsnet@21cn.com
歡迎指正。
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
