軟件概要設計（轉）

通常說來，需求分析屬於軟件定義方面 
而概要設計、詳細設計屬於軟件開發的階段 

按照傳統軟件工程的軟件過程,區別以下: 
1.需求分析--產生   軟件功能規格說明書,須要肯定用戶對軟件的需求,要做到明確、無歧義。不涉及具體實現方法。用戶能看得明白，開發人員也可據此進行下面的工做（概要設計） 
2.概要設計--產生   軟件概要設計說明書，說明系統模塊劃分、選擇的技術路線等，總體說明軟件的實現思路。而且須要指出關鍵技術難點等。 
3.詳細設計--產生   軟件詳細設計說明書，對概要設計的進一步細化，通常由各部分的擔當人員依據概要設計分別完成，而後在集成，是具體的實現細節。理論上要求能夠照此編碼

 

 

軟件概要設計作什麼，怎麼作

1、軟件設計通常流程： 
一、先前的軟件需求分析階段，已經搞清楚了 「要解決什麼問題」，並輸出了《軟件須要說明書》。這時一切都是理想。
二、如今進入概要設計階段，重點說清楚「整體實現方案」，肯定軟件系統的整體佈局，各個子模塊的功能和模塊間的關係，與外部系統的關係。有一些研究與論證性的內容。並輸出《軟件概要設計說明書》。這時一切都是概念。
三、最後進入詳細設計階段，重點說清楚「每一個模塊怎麼作」，是「程序」的藍圖，肯定每一個模塊採用的算法、數據結構、接口的實現、屬性、參數。並輸出《軟件詳細設計說明書》。這時一切都是實現。

2、《概要設計說明書》的通常結構: 
   一、總述：需求或目標（講一下事情的起源）、環境、侷限；
           ----主要交代背景與大環境。(非重點)
   二、整體設計：從全局的角度說一下 整體結構、功能、處理流程、有哪些模塊、模塊間的關係；
           ----使讀者有「全局」觀，爲下一步深刻各個模塊作好準備。
   三、外部接口：整體說明外部用戶、軟、硬件接口(可用資源)；(這個接口不是java的interface) 。
           ----使讀者瞭解能夠利用的外部資源。
   四、模塊設計：每一個模塊「作什麼」、簡要說明「怎麼作」（輸入、輸出、處理邏輯、與其它模塊或系統的接口），處在什麼邏輯位置、物理位置； (重點)
   五、數據結構：邏輯結構、物理結構（存儲在數據表中，仍是緩存中）；  
   六、容災設計：出錯信息、出錯處理； （可選）
   七、監控設計：運行模塊組合、控制、時間；（可選）
   八、用戶界面設計：（可選）
   九、安全設計：（可選）
   十、其它設計：（可選）
   十一、制定規範（附錄）： 設計原則,代碼規範、接口規約、命名規則。--是小組協同開發的基礎

3、模塊設計是重點，多說幾句： 
   能夠寫如下內容：
   一、模塊描述：說明哪些模塊實現了哪些功能；
   二、模塊層次結構：可使用某個視角的軟件框架圖來表達；
   三、模塊間的關係：模塊間依賴關係的描述，通訊機制描述；
   四、模塊的核心接口：說明模塊傳遞的信息、信息的結構；
   五、處理方式設計：說一些知足功能和性能的算法；

4、怎麼使用概要設計： 
   一、用來評價整體設計的可行性。
   二、用來檢查設計的模塊是否完整，保證每個功能都有對應的模塊來實現。
   三、用來評估開發工做量、指導開發計劃（在不寫詳細設計的狀況下）。

5、最後提醒: 
   一、概要設計階段過於重視業務流程是個誤區.
   二、概要設計階段過於重視細節實現是個誤區.

 

 

摘要：   本文是在概要設計實踐和學習中的一些心得與學習筆記，但願與你們分享，若有不妥之處歡迎指正。   關鍵字：   概要設計，結構化，OOD 正文：   在需求明確、準備開始編碼以前，要作概要設計，而詳細設計可能大部分公司沒有作，有作的也大部分是和編碼同步進行，或者在編碼以後。所以，對大部分的公司來講，概要設計文檔是惟一的設計文檔，對後面的開發、測試、實施、維護工做起到關鍵性的影響。   1、問題的提出   概要設計寫什麼？概要設計怎麼作？   如何判斷設計的模塊是完整的？   爲何說設計階段過於重視業務流程是個誤區？   以需求分析文檔仍是以概要設計文檔來評估開發工做量、指導開發計劃準確？   結構化好仍是面向對象好？   以上問題的答案請在文章中找。   2、概要設計的目的   將軟件系統需求轉換爲將來系統的設計；   逐步開發強壯的系統構架；   使設計適合於實施環境，爲提升性能而進行設計；   結構應該被分解爲模塊和庫。   3、概要設計的任務    制定規範：代碼體系、接口規約、命名規則。這是項目小組從此共同做戰的基礎，有了開發規範和程序模塊之間和項目成員彼此之間的接口規則、方式方法，你們就有了共同的工做語言、共同的工做平臺，使整個軟件開發工做能夠協調有序地進行。   整體結構設計：   功能（加工）－>模塊：每一個功能用那些模塊實現，保證每一個功能都有相應的模塊來實現；   模塊層次結構：某個角度的軟件框架視圖；   模塊間的調用關係：模塊間的接口的整體描述；   模塊間的接口：傳遞的信息及其結構；   處理方式設計：知足功能和性能的算法   用戶界面設計；   數據結構設計：   詳細的數據結構：表、索引、文件；   算法相關邏輯數據結構及其操做；   上述操做的程序模塊說明（在前臺？在後臺？用視圖？用過程？······）   接口控制表的數據結構和使用規則   其餘性能設計。   4、概要設計寫什麼   結構化軟件設計說明書結構（因篇幅有限和過期嫌疑，在此不做過多解釋）   任務：目標、環境、需求、侷限；   整體設計：處理流程、整體結構與模塊、功能與模塊的關係；   接口設計：整體說明外部用戶、軟、硬件接口；內部模塊間接口（注：接口≈系統界面）   數據結構：邏輯結構、物理結構，與程序結構的關係；   模塊設計：每一個模塊「作什麼」、簡要說明「怎麼作」（輸入、輸出、處理邏輯、與其它模塊的接口，與其它系統或硬件的接口），處在什麼邏輯位置、物理位置；   運行設計：運行模塊組合、控制、時間；   出錯設計：出錯信息、處錯處理；   其餘設計：保密、維護；   OO軟件設計說明書結構   1 概述   系統簡述、軟件設計目標、參考資料、修訂版本記錄   這部分論述整個系統的設計目標，明確地說明哪些功能是系統決定實現而哪些時不許備實現的。同時，對於非功能性的需求例如性能、可用性等，亦需說起。需求規格說明書對於這部分的內容來講是很重要的參考，看看其中明確了的功能性以及非功能性的需求。 這部分必須說清楚設計的全貌如何，務必使讀者看後知道將實現的系統有什麼特色和功能。在隨後的文檔部分，將解釋設計是怎麼來實現這些的。   2 術語表   對本文檔中所使用的各類術語進行說明。若是一些術語在需求規格說明書中已經說明過了，此處不用再重複，能夠指引讀者參考需求說明。   3 用例   此處要求系統用用例圖表述（UML），對每一個用例（正常處理的狀況）要有中文敘述。   4 設計概述   4.1 簡述   這部分要求突出整個設計所採用的方法（是面向對象設計仍是結構化設計）、系統的體系結構（例如客戶/服務器結構）以及使用到的相應技術和工具（例如OMT、Rose）   4.2 系統結構設計   這部分要求提供高層系統結構（頂層系統結構、各子系統結構）的描述，使用方框圖來顯示主要的組件及組件間的交互。最好是把邏輯結構同物理結構分離，對前者進行描述。別忘了說明圖中用到的俗語和符號。   4.3 系統界面   各類提供給用戶的界面以及外部系統在此處要予以說明。若是在需求規格說明書中已經對用戶界面有了敘述，此處不用再重複，能夠指引讀者參考需求說明。若是系統提供了對其它系統的接口，好比說從其它軟件系統導入/導出數據，必須在此說明。   4.4 約束和假定   描述系統設計中最主要的約束，這些是由客戶強制要求並在需求說明書寫明的。說明系統是如何來適應這些約束的。   另外若是本系統跟其它外部系統交互或者依賴其它外部系統提供一些功能輔助，那麼系統可能還受到其它的約束。這種狀況下，要求清楚地描述與本系統有交互的軟件類型以及這樣致使的約束。   實現的語言和平臺也會對系統有約束，一樣在此予以說明。   對於因選擇具體的設計實現而致使對系統的約束，簡要地描述你的想法思路，通過怎麼樣的權衡，爲何要採起這樣的設計等等。   5 對象模型   提供整個系統的對象模型，若是模型過大，按照可行的標準把它劃分紅小塊，例如能夠把客戶端和服務器端的對象模型分開成兩個圖表述。在其中應該包含全部的系統對象。這些對象都是從理解需求後獲得的。要明確哪些應該、哪些不該該被放進圖中。全部對象之間的關聯必須被肯定而且必須指明聯繫的基數。聚合和繼承關係必須清楚地肯定下來。每一個圖必須附有簡單的說明。   6 對象描述   在這個部分敘述每一個對象的細節，它的屬性、它的方法。在這以前必須從邏輯上對對象進行組織。你可能須要用結構圖把對象按子系統劃分好。   爲每一個對象作一個條目。在系統對象模型中簡要的描述它的用途、約束（如只能有一個實例），列出它的屬性和方法。若是對象是存儲在持久的數據容器中，標明它是持久對象，不然說明它是個臨時對象（transient object）。   對每一個對象的每一個屬性詳細說明：名字、類型，若是屬性不是很直觀或者有約束（例如，每一個對象的該屬性必須有一個惟一的值或者值域是有限正整數等）。   對每一個對象的每一個方法詳細說明：方法名，返回類型，返回值，參數，用途以及使用的算法的簡要說明（若是不是特別簡單的話）。若是對變量或者返回值由什麼假定的話，Pre-conditions和Post-conditions必須在此說明。列出它或者被它調用的方法須要訪問或者修改的屬性。最後，提供能夠驗證明現方法的測試案例。   7 動態模型   這部分的做用是描述系統如何響應各類事件。通常使用順序圖和狀態圖。   肯定不一樣的場景（Scenario）是第一步，不須要肯定全部可能的場景，可是必須至少要覆蓋典型的系統用例。不要本身去想固然地創造場景，一般的策略是描述那些客戶能夠感覺獲得的場景。   7.1 場景（Scenarios）   對每一個場景作一則條目，包括如下內容：   場景名：給它一個能夠望文生義的名字   場景描述：簡要敘述場景是幹什麼的以及發生的動做的順序。   順序圖：描述各類事件及事件發生的相對時間順序。   7.2 狀態圖   這部分的內容包括系統動態模型重要的部分的狀態圖。可能你想爲每一個對象畫一個狀態圖，但事實上會致使太多不指望的細節信息，只須要肯定系統中一些重要的對象併爲之提供狀態圖便可。   8 非功能性需求   5、概要設計怎麼作   結構化軟件設計方法：   詳細閱讀需求規格說明書，理解系統建設目標、業務現狀、現有系統、客戶需求的各功能說明；   分析數據流圖，弄清數據流加工的過程；   根據數據流圖決定數據處理問題的類型（變換型、事務型、其餘型）；   經過以上分析，推導出系統的初始結構圖；   對初始結構圖進行改進完善：全部的加工都要能對應到相應模塊（模塊的完整性在於他們完成了需求中的全部加工），消除徹底類似或局部類似的重複功能（智者察同），理清模塊間的層次、控制關係，減小高扇出結構，隨着深度增大扇入，平衡模塊大小。   由對數據字典的修改補充完善，導出邏輯數據結構，導出每種數據結構上的操做，這些操做應當屬於某個模塊。   肯定系統包含哪些應用服務系統、客戶端、數據庫管理系統；   肯定每一個模塊放在哪一個應用服務器或客戶端的哪一個目錄、哪一個文件（庫），或是在數據庫內部創建的對象。   對每一個篩選後的模塊進行列表說明。   對邏輯數據結構進行列表說明。   根據結構化軟件設計說明書結構對其餘須要說明的問題進行補充說明，造成概要設計說明書。   OO軟件設計方法：   在OOA基礎上設計對象與類：在問題領域分析（業務建模和需求分析）以後，開始創建系統構架。   第一步是抽取創建領域的概念模型，在UML中表現爲創建對象類圖、活動圖和交互圖。對象類就是從對象中通過「察同」找出某組對象之間的共同特徵而造成類：   對象與類的屬性：數據結構；   對象與類的服務操做：操做的實現算法；   對象與類的各外部聯繫的實現結構；   設計策略：充分利用現有的類；   方法：繼承、複用、演化；   活動圖用於定義工做流，主要說明工做流的5W（Do What、Who Do、When Do、Where Do、Why Do）等問題，交互圖把人員和業務聯繫在一塊兒是爲了理解交互過程，發現業務工做流中相互交互的各類角色。   第二步是構建完善系統結構：對系統進行分解，將大系統分解爲若干子系統，子系統分解爲若干軟件組件，並說明子系統之間的靜態和動態接口，每一個子系統能夠由用例模型、分析模型、設計模型、測試模型表示。軟件系統結構的兩種方式：層次、塊狀   層次結構：系統、子系統、模塊、組件（同一層之間具備獨立性）；   塊狀結構：相互之間弱耦合   系統的組成部分：   問題論域：業務相關類和對象(OOA的重點)；   人機界面：窗口、菜單、按鈕、命令等等；   數據管理：數據管理方法、邏輯物理結構、操做對象類；   任務管理：任務協調和管理進程；   第三步是利用「4＋1」視圖描述系統架構：用例視圖及劇本；說明體系結構的設計視圖；以模塊形式組成包和層包含概要實現模型的實現視圖；說明進程與線程及其架構、分配和相互交互關係的過程視圖；說明系統在操做平臺上的物理節點和其上的任務分配的配置視圖。在RUP中還有可選的數據視圖。   第四步是性能優化（速度、資源、內存）、模型清晰化、簡單化（簡單就是享受）。   6、概要設計的原則   整體原則和方法：由粗到細的原則，互相結合的原則，定性分析和定量分析相結合的方法，分解和協調的方法和模型化方法。   要系統考慮系統的通常性、關聯性、總體性和層次性。   分解協調：目的是爲了創造更好的系統。系統分解是指將一個複雜的系統分解爲若干個子系統，系統協調一是系統內協調，即根據系統的總結構、總功能、總任務和總目標的要求，使各個子系統之間互相協調配合，在各個子系統局部優化基礎上，經過內部平衡的協調控制，實現系統的總體優化；   屏蔽抽象：從簡單的框架開始，隱含細節；   一致性：統一的規範、統一的標準、統一的文件模式；   每一個模塊應當有一個統一命名的容易理解的名字；   編碼：由外向內（界面－>核心）；   面向用戶：概要設計是對於按鈕按下後系統「怎麼作」的簡要說明；   模塊、組件的充分獨立性、封閉性；   同時考慮靜態結構與動態運行；   每一個邏輯對象都應當說明其所處物理對象（非一一對應）；   每一個物理對象都有合適的開發人員，而且利於分工與組裝。（詳細說明見本人另外一篇文章：系統構架設計應考慮的因素）；   確立每一個構架視圖的總體結構：視圖的詳細組織結構、元素的分組以及這些主要分組之間的接口；   軟件構架與使用的技術平臺密切相關，目前經常使用的平臺有J2EE、.NET、CORBA等等，所以具體的軟件構架人員應當具有使用這些平臺的軟件開發經驗；   經過需求功能與設計模塊之間的列表對應，檢查每一個需求功能是否都有相應的模塊來實現，保證需求功能的可追溯性和需求實現（模塊）的完整性，同時能夠檢查重複和沒必要要的模塊。   在需求調研分析過程當中對業務處理過程瞭解的完整性和準確性很是重要。調查瞭解清楚全部的業務流程才能設計出適合各流程業務節點用戶業務特色和習慣的軟件，使開發出來的軟件更受歡迎。固然在進行軟件概要設計時，要儘可能排除業務流程的制約，即把流程中的各項業務結點工做做爲獨立的對象，設計成獨立的模塊，充分考慮他們與其餘各類業務對象模塊的接口，在流程之間經過業務對象模塊的相互調用實現各類業務，這樣，在業務流程發生有限的變化時（每一個業務模塊自己的業務邏輯沒有變的狀況下），就可以比較方便地修改系統程序模塊間的調用關係而實現新的需求。若是這種調用關係被設計成存儲在配置庫的數據字典裏，則連程序代碼都不用修改，只需修改數據字典裏的模塊調用規則便可。   7、概要設計的重要輸出   編碼規範：信息形式、接口規約、命名規則；   物理模型：組件圖、配置圖；   不一樣角度的構架視圖：用例視圖、邏輯視圖、進程視圖、部署視圖、實施視圖、數據視圖（可選）；   系統整體佈局：哪些部分組成、各部分在物理上、邏輯上的相互關係；   兩個不可忽視的輸出：   與需求功能的關係：對於需求中的每個功能，用哪一層、哪一個模塊、哪一個類、哪一個對象來實現（一對多關係）；反過來，應當說明將要建立的系統每一層、每一個模塊、每一個對象、每個類「作什麼」，他們是爲了幫助實現哪些功能（一對多關係）。（需求的顆粒度在一開始每每是比較粗的，所以根據功能點對於總體項目規模的估計或獲得項目WBS其偏差範圍也是比較大的。更爲重要的緣由是，需求每每不是編碼工做分解的準確依據，由於一個需求的功能點可能對應多個代碼模塊，而多個需求的功能點也可能只對應一個或少數代碼模塊，同時還有軟件複用等因素要考慮，所以只有在概要設計完成之後才能準確地獲得詳細設計或編碼階段的二次WBS，並估計較爲準確的總體項目規模。）   邏輯與物理位置：每一個對象在邏輯上分別落在哪一層、哪一個模塊、哪一個類；在物理上每一個模塊、每一個對象、每個類放在哪一個應用服務器或客戶端的哪一個目錄、哪一個文件（庫），或者是創建在數據庫管理系統中的什麼東東（過程、函數、視圖、觸發器等等）。   8、結構化與面向對象方法特色比較   1. 從概念方面看，結構化軟件是功能的集合，經過模塊以及模塊和模塊之間的分層調用關係實現；面向對象軟件是事物的集合，經過對象以及對象和對象之間的通信聯繫實現；   2. 從構成方面看，結構化軟件＝過程＋數據，以過程爲中心；面向對象軟件＝（數據＋相應操做）的封裝，以數據爲中心；   3. 從運行控制方面看，結構化軟件採用順序處理方式，由過程驅動控制；面向對象軟件採用交互式、並行處理方式，由消息驅動控制；   4. 從開發方面看，結構化方法的工做重點是設計；面向對象方法的工做重點是分析；可是，在結構化方法中，分析階段和設計階段採用了不相吻合的表達方式，須要把在分析階段採用的具備網絡特徵的數據流圖轉換爲設計階段採用的具備分層特徵的結構圖，在面向對象方法中則不存在這一問題。   5. 從應用方面看，相對而言，結構化方法更加適合數據類型比較簡單的數值計算和數據統計管理軟件的開發；面向對象方法更加適合大型複雜的人機交互式軟件和數據統計管理軟件的開發；

 

 

 

概要設計與詳細設計的區別

概要設計就是設計軟件的結構，包括組成模塊，模塊的層次結構，模塊的調用關係，每一個模塊的功能等等。同時，還要設計該項目的應用系統的整體數據結構和數據庫結構，即應用系統要存儲什麼數據，這些數據是什麼樣的結構，它們之間有什麼關係。 
詳細設計階段就是爲每一個模塊完成的功能進行具體的描述，要把功能描述轉變爲精確的、結構化的過程描述。

概要設計階段一般獲得軟件結構圖 
詳細設計階段經常使用的描述方式有：流程圖、N-S圖、PAD圖、僞代碼等

概要設計和詳細設計

在軟件設計中，你們常常問到的一個問題是：概要設計應該怎樣一個概要法，詳細設計應該怎樣一個詳細法？ 
這個問題在公司內部常常有人問。如今陳述一下。 
咱們公司的研發流程是瀑布型的，這個模型中的分析、設計階段是基於經典的結構化方法。 

結構化設計方法的基本思路是：按照問題域，將軟件逐級細化，分解爲沒必要再分解的的模塊，每一個模塊完成必定的功能，爲一個或多個父模塊服務（即接受調用），也接受一個或多個子模塊的服務（即調用子模塊）。模塊的概念，和編程語言中的子程序或函數是對應的。

這樣一來，設計能夠明顯地劃分紅兩個階段： 

概要（結構）設計階段：把軟件按照必定的原則分解爲模塊層次，賦予每一個模塊必定的任務，並肯定模塊間調用關係和接口。 
詳細設計階段：依據概要設計階段的分解，設計每一個模塊內的算法、流程等。

概要設計階段：

在這個階段，設計者會大體考慮並照顧模塊的內部實現，但不過多糾纏於此。主要集中於劃分模塊、分配任務、定義調用關係。模塊間的接口與傳參在這個階段要定得 十分細緻明確，應編寫嚴謹的數據字典，避免後續設計產生不解或誤解。概要設計通常不是一次就能作到位，而是反覆地進行結構調整。典型的調整是合併功能重複的模塊，或者進一步分解出能夠複用的模塊。在概要設計階段，應最大限度地提取能夠重用的模塊，創建合理的結構體系，節省後續環節的工做量。 

概要設計文檔最重要的部分是分層數據流圖、結構圖、數據字典以及相應的文字說明等。以概要設計文檔爲依據，各個模塊的詳細設計就能夠並行展開了。

詳細設計階段:

在這個階段，各個模塊能夠分給不一樣的人去並行設計。在詳細設計階段，設計者的工做對象是一個模塊，根據概要設計賦予的局部任務和對外接口，設計並表達出模塊的算法、流程、狀態轉換等內容。這裏要注意，若是發現有結構調整（如分解出子模塊等）的必要，必須返回到概要設計階段，將調整反應到概要設計文檔中，而不 能就地解決，不打招呼。詳細設計文檔最重要的部分是模塊的流程圖、狀態圖、局部變量及相應的文字說明等。一個模塊一篇詳細設計文檔。

概要設計文檔至關於機械設計中的裝配圖，而詳細設計文檔至關於機械設計中的零件圖。文檔的編排、裝訂方式也能夠參考機械圖紙的方法。 
咱們公司對模塊的認識和傳統定義有所不一樣，認爲是較大的軟件功能單元才能夠稱做模塊。這種認識使你們對概要設計和詳細設計的分工產生了混亂的理解，下降了文檔的可用性，應該予以糾正。 
概要設計中較頂層的部分即是所謂的方案。方案文檔的做用是在宏觀的角度上保持設計的合理性。

有的項目採用面向對象的分析、設計方法。可能在概要設計、詳細設計的分工上疑問更多。其實，面向對象的分析、設計方法並無強調結構化方法那樣的階段性，所以通常不引入概要、詳細設計的概念。若是按照公司的文檔體系，非要有這種分工的話，能夠將包的劃分、類及對象間的關係、類的對外屬性、方法及協做設計看作 概要設計；類屬性、方法的內部實現看作詳細設計。

1.需求分析--產生軟件功能規格說明書,須要肯定用戶對軟件的需求,要做到明確、無歧義。不涉及具體實現方法。用戶能看得明白，開發人員也可據此進行下面的工做（概要設計）。 
2.概要設計--產生軟件概要設計說明書，說明系統模塊劃分、選擇的技術路線等，總體說明軟件的實現思路。而且須要指出關鍵技術難點等。 
3.詳細設計--產生軟件詳細設計說明書，對概要設計的進一步細化，通常由各部分的擔當人員依據概要設計分別完成，而後在集成，是具體的實現細節。理論上要求能夠照此編碼。

概要設計和詳細設計的區別與聯繫

軟件設計採用自頂向下、逐次功能展開的設計方法，首先完成整體設計，而後完成各有機組成部分的設計。

根據工做性質和內容的不一樣，軟件設計分爲概要設計和詳細設計。概要設計實現軟件的整體設計、模塊劃分、用戶界面設計、數據庫設計等等；詳細設計則根據概要設計所作的模塊劃分，實現各模塊的算法設計，實現用戶界面設計、數據結構設計的細化，等等。

概要設計是詳細設計的基礎，必須在詳細設計以前完成，概要設計經複查確認後才能夠開始詳細設計。概要設計，必須完成概要設計文檔，包括系統的整體設計文檔、以及各個模塊的概要設計文檔。每一個模塊的設計文檔都應該獨立成冊。

詳細設計必須遵循概要設計來進行。詳細設計方案的更改，不得影響到概要設計方案；若是須要更改概要設計，必須通過項目經理的贊成。詳細設計，應該完成詳細設計文檔，主要是模塊的詳細設計方案說明。和概要設計同樣，每一個模塊的詳細設計文檔都應該獨立成冊。

概要設計裏面的數據庫設計應該重點在描述數據關係上，說明數據的前因後果，在這裏應該結合咱們的一下結果數據，說明這些結果數據的源點，咱們這樣設計的目的和緣由。詳細設計裏的數據庫設計就應該是一份完善的數據結構文檔，就是一個包括類型、命名、精度、字段說明、表說明等內容的數據字典。

概要設計裏的功能應該是重點在功能描述，對需求的解釋和整合，總體劃分功能模塊，並對各功能模塊進行詳細的圖文描述，應該讓讀者大體瞭解系統做完後大致的結構和操做模式。詳細設計則是重點在描述系統的實現方式，各模塊詳細說明實現功能所需的類及具體的方法函數，包括涉及到的sql語句等。

 

概要設計，詳細設計之間的關係是什麼？

Q:
個人見解：
概要設計只說明系統有多少個模塊，各模塊之間的接口和個模塊自己的功能
詳細設計說明某個具體模塊如何實現，粒度應該比程序略高一些

可是問題來了，各個模塊之間是有層次關係的，也有前後邏輯關係。這就說明，在概要設計中，還必須考慮模塊的實現細節，不然，你怎麼知道這個模塊下面要劃分子模塊？你怎麼知道各子模塊的調用順序？
這就說明，概要設計和詳細設計是重疊進行的，而軟件工程書上說的確是順序進行的，不知道是否是個人理解有問題。

舉個例子，例如排序程序，若是設計2個模塊：
一個主模塊用於排序子模塊用於交換2個變量，主模塊調用子模塊，可是子模塊是怎麼設計出來的呢？確定是你先想到了用冒泡等排序方式的時候須要交換數據，這已經考慮了主模塊足夠多的細節，彷佛屬於"詳細設計"了，可是目前進行的是概要設計，這就產生了我所說的重疊的狀況。

A:

看看上面的帖子，有意思的居多。

上面也有朋友說到用建築的例子來比喻。

軟件的概要設計，主要是創建軟件系統的總體架構，也就是咱們在蓋房子時候，須要先將房子的整個架子構建起來。

軟件的詳細設計，主要是將軟件系統的各個部分的具體設計方法、邏輯、功能採用文字方式進行表述。這樣在實現過程當中，Coding人員原則上嚴格按此進行代碼實現便可。

這樣的一個最爲簡單的例證：咱們能夠將代碼交付第三方來作。驗證與跟蹤採起設計來。

我看上面還有一個朋友說：快速作代碼。這個自己沒有值得批評之處。但只要想一下，你寫的代碼沒有任何設計思想、文檔留下的狀況，一旦你離開，如何維護？從新設計嗎？仍是花費幾倍人力去研究你寫的幾千/萬，甚至幾十萬行代碼？若是是這樣的，你沒錯，關鍵是大家老闆太對了，錢算什麼。

軟件設計說明書

 

通常說來，需求分析屬於軟件定義方面 
而概要設計、詳細設計屬於軟件開發的階段 

按照傳統軟件工程的軟件過程,區別以下: 
1.需求分析--產生   軟件功能規格說明書,須要肯定用戶對軟件的需求,要做到明確、無歧義。不涉及具體實現方法。用戶能看得明白，開發人員也可據此進行下面的工做（概要設計） 
2.概要設計--產生   軟件概要設計說明書，說明系統模塊劃分、選擇的技術路線等，總體說明軟件的實現思路。而且須要指出關鍵技術難點等。 
3.詳細設計--產生   軟件詳細設計說明書，對概要設計的進一步細化，通常由各部分的擔當人員依據概要設計分別完成，而後在集成，是具體的實現細節。理論上要求能夠照此編碼

 

 

軟件概要設計作什麼，怎麼作

1、軟件設計通常流程： 
一、先前的軟件需求分析階段，已經搞清楚了 「要解決什麼問題」，並輸出了《軟件須要說明書》。這時一切都是理想。
二、如今進入概要設計階段，重點說清楚「整體實現方案」，肯定軟件系統的整體佈局，各個子模塊的功能和模塊間的關係，與外部系統的關係。有一些研究與論證性的內容。並輸出《軟件概要設計說明書》。這時一切都是概念。
三、最後進入詳細設計階段，重點說清楚「每一個模塊怎麼作」，是「程序」的藍圖，肯定每一個模塊採用的算法、數據結構、接口的實現、屬性、參數。並輸出《軟件詳細設計說明書》。這時一切都是實現。

2、《概要設計說明書》的通常結構: 
   一、總述：需求或目標（講一下事情的起源）、環境、侷限；
           ----主要交代背景與大環境。(非重點)
   二、整體設計：從全局的角度說一下 整體結構、功能、處理流程、有哪些模塊、模塊間的關係；
           ----使讀者有「全局」觀，爲下一步深刻各個模塊作好準備。
   三、外部接口：整體說明外部用戶、軟、硬件接口(可用資源)；(這個接口不是java的interface) 。
           ----使讀者瞭解能夠利用的外部資源。
   四、模塊設計：每一個模塊「作什麼」、簡要說明「怎麼作」（輸入、輸出、處理邏輯、與其它模塊或系統的接口），處在什麼邏輯位置、物理位置； (重點)
   五、數據結構：邏輯結構、物理結構（存儲在數據表中，仍是緩存中）；  
   六、容災設計：出錯信息、出錯處理； （可選）
   七、監控設計：運行模塊組合、控制、時間；（可選）
   八、用戶界面設計：（可選）
   九、安全設計：（可選）
   十、其它設計：（可選）
   十一、制定規範（附錄）： 設計原則,代碼規範、接口規約、命名規則。--是小組協同開發的基礎

3、模塊設計是重點，多說幾句： 
   能夠寫如下內容：
   一、模塊描述：說明哪些模塊實現了哪些功能；
   二、模塊層次結構：可使用某個視角的軟件框架圖來表達；
   三、模塊間的關係：模塊間依賴關係的描述，通訊機制描述；
   四、模塊的核心接口：說明模塊傳遞的信息、信息的結構；
   五、處理方式設計：說一些知足功能和性能的算法；

4、怎麼使用概要設計： 
   一、用來評價整體設計的可行性。
   二、用來檢查設計的模塊是否完整，保證每個功能都有對應的模塊來實現。
   三、用來評估開發工做量、指導開發計劃（在不寫詳細設計的狀況下）。

5、最後提醒: 
   一、概要設計階段過於重視業務流程是個誤區.
   二、概要設計階段過於重視細節實現是個誤區.

 

 

摘要：   本文是在概要設計實踐和學習中的一些心得與學習筆記，但願與你們分享，若有不妥之處歡迎指正。   關鍵字：   概要設計，結構化，OOD 正文：   在需求明確、準備開始編碼以前，要作概要設計，而詳細設計可能大部分公司沒有作，有作的也大部分是和編碼同步進行，或者在編碼以後。所以，對大部分的公司來講，概要設計文檔是惟一的設計文檔，對後面的開發、測試、實施、維護工做起到關鍵性的影響。   1、問題的提出   概要設計寫什麼？概要設計怎麼作？   如何判斷設計的模塊是完整的？   爲何說設計階段過於重視業務流程是個誤區？   以需求分析文檔仍是以概要設計文檔來評估開發工做量、指導開發計劃準確？   結構化好仍是面向對象好？   以上問題的答案請在文章中找。   2、概要設計的目的   將軟件系統需求轉換爲將來系統的設計；   逐步開發強壯的系統構架；   使設計適合於實施環境，爲提升性能而進行設計；   結構應該被分解爲模塊和庫。   3、概要設計的任務    制定規範：代碼體系、接口規約、命名規則。這是項目小組從此共同做戰的基礎，有了開發規範和程序模塊之間和項目成員彼此之間的接口規則、方式方法，你們就有了共同的工做語言、共同的工做平臺，使整個軟件開發工做能夠協調有序地進行。   整體結構設計：   功能（加工）－>模塊：每一個功能用那些模塊實現，保證每一個功能都有相應的模塊來實現；   模塊層次結構：某個角度的軟件框架視圖；   模塊間的調用關係：模塊間的接口的整體描述；   模塊間的接口：傳遞的信息及其結構；   處理方式設計：知足功能和性能的算法   用戶界面設計；   數據結構設計：   詳細的數據結構：表、索引、文件；   算法相關邏輯數據結構及其操做；   上述操做的程序模塊說明（在前臺？在後臺？用視圖？用過程？······）   接口控制表的數據結構和使用規則   其餘性能設計。   4、概要設計寫什麼   結構化軟件設計說明書結構（因篇幅有限和過期嫌疑，在此不做過多解釋）   任務：目標、環境、需求、侷限；   整體設計：處理流程、整體結構與模塊、功能與模塊的關係；   接口設計：整體說明外部用戶、軟、硬件接口；內部模塊間接口（注：接口≈系統界面）   數據結構：邏輯結構、物理結構，與程序結構的關係；   模塊設計：每一個模塊「作什麼」、簡要說明「怎麼作」（輸入、輸出、處理邏輯、與其它模塊的接口，與其它系統或硬件的接口），處在什麼邏輯位置、物理位置；   運行設計：運行模塊組合、控制、時間；   出錯設計：出錯信息、處錯處理；   其餘設計：保密、維護；   OO軟件設計說明書結構   1 概述   系統簡述、軟件設計目標、參考資料、修訂版本記錄   這部分論述整個系統的設計目標，明確地說明哪些功能是系統決定實現而哪些時不許備實現的。同時，對於非功能性的需求例如性能、可用性等，亦需說起。需求規格說明書對於這部分的內容來講是很重要的參考，看看其中明確了的功能性以及非功能性的需求。 這部分必須說清楚設計的全貌如何，務必使讀者看後知道將實現的系統有什麼特色和功能。在隨後的文檔部分，將解釋設計是怎麼來實現這些的。   2 術語表   對本文檔中所使用的各類術語進行說明。若是一些術語在需求規格說明書中已經說明過了，此處不用再重複，能夠指引讀者參考需求說明。   3 用例   此處要求系統用用例圖表述（UML），對每一個用例（正常處理的狀況）要有中文敘述。   4 設計概述   4.1 簡述   這部分要求突出整個設計所採用的方法（是面向對象設計仍是結構化設計）、系統的體系結構（例如客戶/服務器結構）以及使用到的相應技術和工具（例如OMT、Rose）   4.2 系統結構設計   這部分要求提供高層系統結構（頂層系統結構、各子系統結構）的描述，使用方框圖來顯示主要的組件及組件間的交互。最好是把邏輯結構同物理結構分離，對前者進行描述。別忘了說明圖中用到的俗語和符號。   4.3 系統界面   各類提供給用戶的界面以及外部系統在此處要予以說明。若是在需求規格說明書中已經對用戶界面有了敘述，此處不用再重複，能夠指引讀者參考需求說明。若是系統提供了對其它系統的接口，好比說從其它軟件系統導入/導出數據，必須在此說明。   4.4 約束和假定   描述系統設計中最主要的約束，這些是由客戶強制要求並在需求說明書寫明的。說明系統是如何來適應這些約束的。   另外若是本系統跟其它外部系統交互或者依賴其它外部系統提供一些功能輔助，那麼系統可能還受到其它的約束。這種狀況下，要求清楚地描述與本系統有交互的軟件類型以及這樣致使的約束。   實現的語言和平臺也會對系統有約束，一樣在此予以說明。   對於因選擇具體的設計實現而致使對系統的約束，簡要地描述你的想法思路，通過怎麼樣的權衡，爲何要採起這樣的設計等等。   5 對象模型   提供整個系統的對象模型，若是模型過大，按照可行的標準把它劃分紅小塊，例如能夠把客戶端和服務器端的對象模型分開成兩個圖表述。在其中應該包含全部的系統對象。這些對象都是從理解需求後獲得的。要明確哪些應該、哪些不該該被放進圖中。全部對象之間的關聯必須被肯定而且必須指明聯繫的基數。聚合和繼承關係必須清楚地肯定下來。每一個圖必須附有簡單的說明。   6 對象描述   在這個部分敘述每一個對象的細節，它的屬性、它的方法。在這以前必須從邏輯上對對象進行組織。你可能須要用結構圖把對象按子系統劃分好。   爲每一個對象作一個條目。在系統對象模型中簡要的描述它的用途、約束（如只能有一個實例），列出它的屬性和方法。若是對象是存儲在持久的數據容器中，標明它是持久對象，不然說明它是個臨時對象（transient object）。   對每一個對象的每一個屬性詳細說明：名字、類型，若是屬性不是很直觀或者有約束（例如，每一個對象的該屬性必須有一個惟一的值或者值域是有限正整數等）。   對每一個對象的每一個方法詳細說明：方法名，返回類型，返回值，參數，用途以及使用的算法的簡要說明（若是不是特別簡單的話）。若是對變量或者返回值由什麼假定的話，Pre-conditions和Post-conditions必須在此說明。列出它或者被它調用的方法須要訪問或者修改的屬性。最後，提供能夠驗證明現方法的測試案例。   7 動態模型   這部分的做用是描述系統如何響應各類事件。通常使用順序圖和狀態圖。   肯定不一樣的場景（Scenario）是第一步，不須要肯定全部可能的場景，可是必須至少要覆蓋典型的系統用例。不要本身去想固然地創造場景，一般的策略是描述那些客戶能夠感覺獲得的場景。   7.1 場景（Scenarios）   對每一個場景作一則條目，包括如下內容：   場景名：給它一個能夠望文生義的名字   場景描述：簡要敘述場景是幹什麼的以及發生的動做的順序。   順序圖：描述各類事件及事件發生的相對時間順序。   7.2 狀態圖   這部分的內容包括系統動態模型重要的部分的狀態圖。可能你想爲每一個對象畫一個狀態圖，但事實上會致使太多不指望的細節信息，只須要肯定系統中一些重要的對象併爲之提供狀態圖便可。   8 非功能性需求   5、概要設計怎麼作   結構化軟件設計方法：   詳細閱讀需求規格說明書，理解系統建設目標、業務現狀、現有系統、客戶需求的各功能說明；   分析數據流圖，弄清數據流加工的過程；   根據數據流圖決定數據處理問題的類型（變換型、事務型、其餘型）；   經過以上分析，推導出系統的初始結構圖；   對初始結構圖進行改進完善：全部的加工都要能對應到相應模塊（模塊的完整性在於他們完成了需求中的全部加工），消除徹底類似或局部類似的重複功能（智者察同），理清模塊間的層次、控制關係，減小高扇出結構，隨着深度增大扇入，平衡模塊大小。   由對數據字典的修改補充完善，導出邏輯數據結構，導出每種數據結構上的操做，這些操做應當屬於某個模塊。   肯定系統包含哪些應用服務系統、客戶端、數據庫管理系統；   肯定每一個模塊放在哪一個應用服務器或客戶端的哪一個目錄、哪一個文件（庫），或是在數據庫內部創建的對象。   對每一個篩選後的模塊進行列表說明。   對邏輯數據結構進行列表說明。   根據結構化軟件設計說明書結構對其餘須要說明的問題進行補充說明，造成概要設計說明書。   OO軟件設計方法：   在OOA基礎上設計對象與類：在問題領域分析（業務建模和需求分析）以後，開始創建系統構架。   第一步是抽取創建領域的概念模型，在UML中表現爲創建對象類圖、活動圖和交互圖。對象類就是從對象中通過「察同」找出某組對象之間的共同特徵而造成類：   對象與類的屬性：數據結構；   對象與類的服務操做：操做的實現算法；   對象與類的各外部聯繫的實現結構；   設計策略：充分利用現有的類；   方法：繼承、複用、演化；   活動圖用於定義工做流，主要說明工做流的5W（Do What、Who Do、When Do、Where Do、Why Do）等問題，交互圖把人員和業務聯繫在一塊兒是爲了理解交互過程，發現業務工做流中相互交互的各類角色。   第二步是構建完善系統結構：對系統進行分解，將大系統分解爲若干子系統，子系統分解爲若干軟件組件，並說明子系統之間的靜態和動態接口，每一個子系統能夠由用例模型、分析模型、設計模型、測試模型表示。軟件系統結構的兩種方式：層次、塊狀   層次結構：系統、子系統、模塊、組件（同一層之間具備獨立性）；   塊狀結構：相互之間弱耦合   系統的組成部分：   問題論域：業務相關類和對象(OOA的重點)；   人機界面：窗口、菜單、按鈕、命令等等；   數據管理：數據管理方法、邏輯物理結構、操做對象類；   任務管理：任務協調和管理進程；   第三步是利用「4＋1」視圖描述系統架構：用例視圖及劇本；說明體系結構的設計視圖；以模塊形式組成包和層包含概要實現模型的實現視圖；說明進程與線程及其架構、分配和相互交互關係的過程視圖；說明系統在操做平臺上的物理節點和其上的任務分配的配置視圖。在RUP中還有可選的數據視圖。   第四步是性能優化（速度、資源、內存）、模型清晰化、簡單化（簡單就是享受）。   6、概要設計的原則   整體原則和方法：由粗到細的原則，互相結合的原則，定性分析和定量分析相結合的方法，分解和協調的方法和模型化方法。   要系統考慮系統的通常性、關聯性、總體性和層次性。   分解協調：目的是爲了創造更好的系統。系統分解是指將一個複雜的系統分解爲若干個子系統，系統協調一是系統內協調，即根據系統的總結構、總功能、總任務和總目標的要求，使各個子系統之間互相協調配合，在各個子系統局部優化基礎上，經過內部平衡的協調控制，實現系統的總體優化；   屏蔽抽象：從簡單的框架開始，隱含細節；   一致性：統一的規範、統一的標準、統一的文件模式；   每一個模塊應當有一個統一命名的容易理解的名字；   編碼：由外向內（界面－>核心）；   面向用戶：概要設計是對於按鈕按下後系統「怎麼作」的簡要說明；   模塊、組件的充分獨立性、封閉性；   同時考慮靜態結構與動態運行；   每一個邏輯對象都應當說明其所處物理對象（非一一對應）；   每一個物理對象都有合適的開發人員，而且利於分工與組裝。（詳細說明見本人另外一篇文章：系統構架設計應考慮的因素）；   確立每一個構架視圖的總體結構：視圖的詳細組織結構、元素的分組以及這些主要分組之間的接口；   軟件構架與使用的技術平臺密切相關，目前經常使用的平臺有J2EE、.NET、CORBA等等，所以具體的軟件構架人員應當具有使用這些平臺的軟件開發經驗；   經過需求功能與設計模塊之間的列表對應，檢查每一個需求功能是否都有相應的模塊來實現，保證需求功能的可追溯性和需求實現（模塊）的完整性，同時能夠檢查重複和沒必要要的模塊。   在需求調研分析過程當中對業務處理過程瞭解的完整性和準確性很是重要。調查瞭解清楚全部的業務流程才能設計出適合各流程業務節點用戶業務特色和習慣的軟件，使開發出來的軟件更受歡迎。固然在進行軟件概要設計時，要儘可能排除業務流程的制約，即把流程中的各項業務結點工做做爲獨立的對象，設計成獨立的模塊，充分考慮他們與其餘各類業務對象模塊的接口，在流程之間經過業務對象模塊的相互調用實現各類業務，這樣，在業務流程發生有限的變化時（每一個業務模塊自己的業務邏輯沒有變的狀況下），就可以比較方便地修改系統程序模塊間的調用關係而實現新的需求。若是這種調用關係被設計成存儲在配置庫的數據字典裏，則連程序代碼都不用修改，只需修改數據字典裏的模塊調用規則便可。   7、概要設計的重要輸出   編碼規範：信息形式、接口規約、命名規則；   物理模型：組件圖、配置圖；   不一樣角度的構架視圖：用例視圖、邏輯視圖、進程視圖、部署視圖、實施視圖、數據視圖（可選）；   系統整體佈局：哪些部分組成、各部分在物理上、邏輯上的相互關係；   兩個不可忽視的輸出：   與需求功能的關係：對於需求中的每個功能，用哪一層、哪一個模塊、哪一個類、哪一個對象來實現（一對多關係）；反過來，應當說明將要建立的系統每一層、每一個模塊、每一個對象、每個類「作什麼」，他們是爲了幫助實現哪些功能（一對多關係）。（需求的顆粒度在一開始每每是比較粗的，所以根據功能點對於總體項目規模的估計或獲得項目WBS其偏差範圍也是比較大的。更爲重要的緣由是，需求每每不是編碼工做分解的準確依據，由於一個需求的功能點可能對應多個代碼模塊，而多個需求的功能點也可能只對應一個或少數代碼模塊，同時還有軟件複用等因素要考慮，所以只有在概要設計完成之後才能準確地獲得詳細設計或編碼階段的二次WBS，並估計較爲準確的總體項目規模。）   邏輯與物理位置：每一個對象在邏輯上分別落在哪一層、哪一個模塊、哪一個類；在物理上每一個模塊、每一個對象、每個類放在哪一個應用服務器或客戶端的哪一個目錄、哪一個文件（庫），或者是創建在數據庫管理系統中的什麼東東（過程、函數、視圖、觸發器等等）。   8、結構化與面向對象方法特色比較   1. 從概念方面看，結構化軟件是功能的集合，經過模塊以及模塊和模塊之間的分層調用關係實現；面向對象軟件是事物的集合，經過對象以及對象和對象之間的通信聯繫實現；   2. 從構成方面看，結構化軟件＝過程＋數據，以過程爲中心；面向對象軟件＝（數據＋相應操做）的封裝，以數據爲中心；   3. 從運行控制方面看，結構化軟件採用順序處理方式，由過程驅動控制；面向對象軟件採用交互式、並行處理方式，由消息驅動控制；   4. 從開發方面看，結構化方法的工做重點是設計；面向對象方法的工做重點是分析；可是，在結構化方法中，分析階段和設計階段採用了不相吻合的表達方式，須要把在分析階段採用的具備網絡特徵的數據流圖轉換爲設計階段採用的具備分層特徵的結構圖，在面向對象方法中則不存在這一問題。   5. 從應用方面看，相對而言，結構化方法更加適合數據類型比較簡單的數值計算和數據統計管理軟件的開發；面向對象方法更加適合大型複雜的人機交互式軟件和數據統計管理軟件的開發；

 

 

 

概要設計與詳細設計的區別

概要設計就是設計軟件的結構，包括組成模塊，模塊的層次結構，模塊的調用關係，每一個模塊的功能等等。同時，還要設計該項目的應用系統的整體數據結構和數據庫結構，即應用系統要存儲什麼數據，這些數據是什麼樣的結構，它們之間有什麼關係。 
詳細設計階段就是爲每一個模塊完成的功能進行具體的描述，要把功能描述轉變爲精確的、結構化的過程描述。

概要設計階段一般獲得軟件結構圖 
詳細設計階段經常使用的描述方式有：流程圖、N-S圖、PAD圖、僞代碼等

概要設計和詳細設計

在軟件設計中，你們常常問到的一個問題是：概要設計應該怎樣一個概要法，詳細設計應該怎樣一個詳細法？ 
這個問題在公司內部常常有人問。如今陳述一下。 
咱們公司的研發流程是瀑布型的，這個模型中的分析、設計階段是基於經典的結構化方法。 

結構化設計方法的基本思路是：按照問題域，將軟件逐級細化，分解爲沒必要再分解的的模塊，每一個模塊完成必定的功能，爲一個或多個父模塊服務（即接受調用），也接受一個或多個子模塊的服務（即調用子模塊）。模塊的概念，和編程語言中的子程序或函數是對應的。

這樣一來，設計能夠明顯地劃分紅兩個階段： 

概要（結構）設計階段：把軟件按照必定的原則分解爲模塊層次，賦予每一個模塊必定的任務，並肯定模塊間調用關係和接口。 
詳細設計階段：依據概要設計階段的分解，設計每一個模塊內的算法、流程等。

概要設計階段：

在這個階段，設計者會大體考慮並照顧模塊的內部實現，但不過多糾纏於此。主要集中於劃分模塊、分配任務、定義調用關係。模塊間的接口與傳參在這個階段要定得 十分細緻明確，應編寫嚴謹的數據字典，避免後續設計產生不解或誤解。概要設計通常不是一次就能作到位，而是反覆地進行結構調整。典型的調整是合併功能重複的模塊，或者進一步分解出能夠複用的模塊。在概要設計階段，應最大限度地提取能夠重用的模塊，創建合理的結構體系，節省後續環節的工做量。 

概要設計文檔最重要的部分是分層數據流圖、結構圖、數據字典以及相應的文字說明等。以概要設計文檔爲依據，各個模塊的詳細設計就能夠並行展開了。

詳細設計階段:

在這個階段，各個模塊能夠分給不一樣的人去並行設計。在詳細設計階段，設計者的工做對象是一個模塊，根據概要設計賦予的局部任務和對外接口，設計並表達出模塊的算法、流程、狀態轉換等內容。這裏要注意，若是發現有結構調整（如分解出子模塊等）的必要，必須返回到概要設計階段，將調整反應到概要設計文檔中，而不 能就地解決，不打招呼。詳細設計文檔最重要的部分是模塊的流程圖、狀態圖、局部變量及相應的文字說明等。一個模塊一篇詳細設計文檔。

概要設計文檔至關於機械設計中的裝配圖，而詳細設計文檔至關於機械設計中的零件圖。文檔的編排、裝訂方式也能夠參考機械圖紙的方法。 
咱們公司對模塊的認識和傳統定義有所不一樣，認爲是較大的軟件功能單元才能夠稱做模塊。這種認識使你們對概要設計和詳細設計的分工產生了混亂的理解，下降了文檔的可用性，應該予以糾正。 
概要設計中較頂層的部分即是所謂的方案。方案文檔的做用是在宏觀的角度上保持設計的合理性。

有的項目採用面向對象的分析、設計方法。可能在概要設計、詳細設計的分工上疑問更多。其實，面向對象的分析、設計方法並無強調結構化方法那樣的階段性，所以通常不引入概要、詳細設計的概念。若是按照公司的文檔體系，非要有這種分工的話，能夠將包的劃分、類及對象間的關係、類的對外屬性、方法及協做設計看作 概要設計；類屬性、方法的內部實現看作詳細設計。

1.需求分析--產生軟件功能規格說明書,須要肯定用戶對軟件的需求,要做到明確、無歧義。不涉及具體實現方法。用戶能看得明白，開發人員也可據此進行下面的工做（概要設計）。 
2.概要設計--產生軟件概要設計說明書，說明系統模塊劃分、選擇的技術路線等，總體說明軟件的實現思路。而且須要指出關鍵技術難點等。 
3.詳細設計--產生軟件詳細設計說明書，對概要設計的進一步細化，通常由各部分的擔當人員依據概要設計分別完成，而後在集成，是具體的實現細節。理論上要求能夠照此編碼。

概要設計和詳細設計的區別與聯繫

軟件設計採用自頂向下、逐次功能展開的設計方法，首先完成整體設計，而後完成各有機組成部分的設計。

根據工做性質和內容的不一樣，軟件設計分爲概要設計和詳細設計。概要設計實現軟件的整體設計、模塊劃分、用戶界面設計、數據庫設計等等；詳細設計則根據概要設計所作的模塊劃分，實現各模塊的算法設計，實現用戶界面設計、數據結構設計的細化，等等。

概要設計是詳細設計的基礎，必須在詳細設計以前完成，概要設計經複查確認後才能夠開始詳細設計。概要設計，必須完成概要設計文檔，包括系統的整體設計文檔、以及各個模塊的概要設計文檔。每一個模塊的設計文檔都應該獨立成冊。

詳細設計必須遵循概要設計來進行。詳細設計方案的更改，不得影響到概要設計方案；若是須要更改概要設計，必須通過項目經理的贊成。詳細設計，應該完成詳細設計文檔，主要是模塊的詳細設計方案說明。和概要設計同樣，每一個模塊的詳細設計文檔都應該獨立成冊。

概要設計裏面的數據庫設計應該重點在描述數據關係上，說明數據的前因後果，在這裏應該結合咱們的一下結果數據，說明這些結果數據的源點，咱們這樣設計的目的和緣由。詳細設計裏的數據庫設計就應該是一份完善的數據結構文檔，就是一個包括類型、命名、精度、字段說明、表說明等內容的數據字典。

概要設計裏的功能應該是重點在功能描述，對需求的解釋和整合，總體劃分功能模塊，並對各功能模塊進行詳細的圖文描述，應該讓讀者大體瞭解系統做完後大致的結構和操做模式。詳細設計則是重點在描述系統的實現方式，各模塊詳細說明實現功能所需的類及具體的方法函數，包括涉及到的sql語句等。

 

概要設計，詳細設計之間的關係是什麼？

Q:
個人見解：
概要設計只說明系統有多少個模塊，各模塊之間的接口和個模塊自己的功能
詳細設計說明某個具體模塊如何實現，粒度應該比程序略高一些

可是問題來了，各個模塊之間是有層次關係的，也有前後邏輯關係。這就說明，在概要設計中，還必須考慮模塊的實現細節，不然，你怎麼知道這個模塊下面要劃分子模塊？你怎麼知道各子模塊的調用順序？
這就說明，概要設計和詳細設計是重疊進行的，而軟件工程書上說的確是順序進行的，不知道是否是個人理解有問題。

舉個例子，例如排序程序，若是設計2個模塊：
一個主模塊用於排序子模塊用於交換2個變量，主模塊調用子模塊，可是子模塊是怎麼設計出來的呢？確定是你先想到了用冒泡等排序方式的時候須要交換數據，這已經考慮了主模塊足夠多的細節，彷佛屬於"詳細設計"了，可是目前進行的是概要設計，這就產生了我所說的重疊的狀況。

A:

看看上面的帖子，有意思的居多。

上面也有朋友說到用建築的例子來比喻。

軟件的概要設計，主要是創建軟件系統的總體架構，也就是咱們在蓋房子時候，須要先將房子的整個架子構建起來。

軟件的詳細設計，主要是將軟件系統的各個部分的具體設計方法、邏輯、功能採用文字方式進行表述。這樣在實現過程當中，Coding人員原則上嚴格按此進行代碼實現便可。

這樣的一個最爲簡單的例證：咱們能夠將代碼交付第三方來作。驗證與跟蹤採起設計來。

我看上面還有一個朋友說：快速作代碼。這個自己沒有值得批評之處。但只要想一下，你寫的代碼沒有任何設計思想、文檔留下的狀況，一旦你離開，如何維護？從新設計嗎？仍是花費幾倍人力去研究你寫的幾千/萬，甚至幾十萬行代碼？若是是這樣的，你沒錯，關鍵是大家老闆太對了，錢算什麼