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

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

    概要設計就是設計軟體的結構，包括組成子產品，子產品的層次結構，子產品的調用關系，每個子產品的功能等等。同時，還要設計該項目的應用系統的總體資料結構和資料庫結構，即應用系統要存儲什麼資料，這些資料是什麼樣的結構，它們之間有什麼關系。 

    詳細設計階段就是為每個子產品完成的功能進行具體的描述，要把功能描述轉變為精确的、結構化的過程描述。

    概要設計階段通常得到軟體結構圖 

    詳細設計階段常用的描述方式有：流程圖、N-S圖、PAD圖、僞代碼等

概要設計和詳細設計

    在軟體設計中，大家經常問到的一個問題是：概要設計應該怎樣一個概要法，詳細設計應該怎樣一個詳細法？ 

這個問題在公司内部經常有人問。現在陳述一下。 

    我們公司的研發流程是瀑布型的，這個模型中的分析、設計階段是基于經典的結構化方法。 

    結構化設計方法的基本思路是：按照問題域，将軟體逐級細化，分解為不必再分解的的子產品，每個子產品完成一定的功能，為一個或多個父子產品服務（即接受調用），也接受一個或多個子子產品的服務（即調用子子產品）。子產品的概念，和程式設計語言中的子程式或函數是對應的。

    這樣一來，設計可以明顯地劃分成兩個階段： 

    概要（結構）設計階段：把軟體按照一定的原則分解為子產品層次，賦予每個子產品一定的任務，并确定子產品間調用關系和接口。 

    詳細設計階段：依據概要設計階段的分解，設計每個子產品内的算法、流程等。

概要設計階段：

    在這個階段，設計者會大緻考慮并照顧子產品的内部實作，但不過多糾纏于此。主要集中于劃分子產品、配置設定任務、定義調用關系。子產品間的接口與傳參在這個階段要定得 十分細緻明确，應編寫嚴謹的資料字典，避免後續設計産生不解或誤解。概要設計一般不是一次就能做到位，而是反複地進行結構調整。典型的調整是合并功能重複的子產品，或者進一步分解出可以複用的子產品。在概要設計階段，應最大限度地提取可以重用的子產品，建立合理的結構體系，節省後續環節的工作量。 

    概要設計文檔最重要的部分是分層資料流圖、結構圖、資料字典以及相應的文字說明等。以概要設計文檔為依據，各個子產品的詳細設計就可以并行展開了。

詳細設計階段:

    在這個階段，各個子產品可以分給不同的人去并行設計。在詳細設計階段，設計者的工作對象是一個子產品，根據概要設計賦予的局部任務和對外接口，設計并表達出子產品的算法、流程、狀态轉換等内容。這裡要注意，如果發現有結構調整（如分解出子子產品等）的必要，必須傳回到概要設計階段，将調整反應到概要設計文檔中，而不 能就地解決，不打招呼。詳細設計文檔最重要的部分是子產品的流程圖、狀态圖、局部變量及相應的文字說明等。一個子產品一篇詳細設計文檔。

    概要設計文檔相當于機械設計中的裝配圖，而詳細設計文檔相當于機械設計中的零件圖。文檔的編排、裝訂方式也可以參考機械圖紙的方法。 

    我們公司對子產品的認識和傳統定義有所不同，認為是較大的軟體功能單元才可以稱作子產品。這種認識使大家對概要設計和詳細設計的分工産生了混亂的了解，降低了文檔的可用性，應該予以糾正。

    概要設計中較頂層的部分便是所謂的方案。方案文檔的作用是在宏觀的角度上保持設計的合理性。

    有的項目采用面向對象的分析、設計方法。可能在概要設計、詳細設計的分工上疑問更多。其實，面向對象的分析、設計方法并沒有強調結構化方法那樣的階段性，是以一般不引入概要、詳細設計的概念。如果按照公司的文檔體系，非要有這種分工的話，可以将包的劃分、類及對象間的關系、類的對外屬性、方法及協作設計看做 概要設計；類屬性、方法的内部實作看做詳細設計。

   1.需求分析--産生軟體功能規格說明書,需要确定使用者對軟體的需求,要作到明确、無歧義。不涉及具體實作方法。使用者能看得明白，開發人員也可據此進行下面的工作（概要設計）。 

   2.概要設計--産生軟體概要設計說明書，說明系統子產品劃分、選擇的技術路線等，整體說明軟體的實作思路。并且需要指出關鍵技術難點等。   

   3.詳細設計--産生軟體詳細設計說明書，對概要設計的進一步細化，一般由各部分的擔當人員依據概要設計分别完成，然後在內建，是具體的實作細節。理論上要求可以照此編碼。

概要設計和詳細設計的差別與聯系

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

    根據工作性質和内容的不同，軟體設計分為概要設計和詳細設計。概要設計實作軟體的總體設計、子產品劃分、使用者界面設計、資料庫設計等等；詳細設計則根據概要設計所做的子產品劃分，實作各子產品的算法設計，實作使用者界面設計、資料結構設計的細化，等等。

    概要設計是詳細設計的基礎，必須在詳細設計之前完成，概要設計經複查确認後才可以開始詳細設計。概要設計，必須完成概要設計文檔，包括系統的總體設計文檔、以及各個子產品的概要設計文檔。每個子產品的設計文檔都應該獨立成冊。

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

   概要設計裡面的資料庫設計應該重點在描述資料關系上，說明資料的來龍去脈，在這裡應該結合我們的一下結果資料，說明這些結果資料的源點，我們這樣設計的目的和原因。詳細設計裡的資料庫設計就應該是一份完善的資料結構文檔，就是一個包括類型、命名、精度、字段說明、表說明等内容的資料字典。

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

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

Q:

我的看法：

    概要設計隻說明系統有多少個子產品，各子產品之間的接口和個子產品本身的功能

    詳細設計說明某個具體子產品如何實作，粒度應該比程式略高一些

    但是問題來了，各個子產品之間是有層次關系的，也有先後邏輯關系。這就說明，在概要設計中，還必須考慮子產品的實作細節，否則，你怎麼知道這個子產品下面要劃分子子產品？你怎麼知道各子子產品的調用順序？

    這就說明，概要設計和詳細設計是重疊進行的，而軟體工程書上說的确是順序進行的，不知道是不是我的了解有問題。

舉個例子，例如排序程式，如果設計2個子產品：

一個主子產品用于排序子子產品用于交換2個變量，主子產品調用子子產品，但是子子產品是怎麼設計出來的呢？肯定是你先想到了用冒泡等排序方式的時候需要交換資料，這已經考慮了主子產品足夠多的細節，似乎屬于"詳細設計"了，但是目前進行的是概要設計，這就産生了我所說的重疊的情況。

A:

看看上面的文章，有意思的居多。

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

軟體的概要設計，主要是建立軟體系統的整體架構，也就是我們在蓋房子時候，需要先将房子的整個架子建構起來。

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

這樣的一個最為簡單的例證：我們可以将代碼傳遞第三方來做。驗證與跟蹤采取設計來。

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

另外的一個問題是：中國人如此聰明，但中國為什麼沒有出現巨型軟體産品呢？個人英雄主義依然很嚴重，老闆的短視利益行為大行其道。