結構問題包括總體組織結構和全域性控制結構；通訊、同步和資料訪問的協議；設計元素的功能分配；物理分佈；設計元素的組成；定標與效能；備選設計的選擇 這是我的看法，請採納。

在需求明確、準備開始編碼之前，要做概要設計，而詳細設計可能大部分公司沒有做，有做的也大部分是和編碼同步進行，或者在編碼之後。因此，對大部分的公司來說，概要設計文件是唯一的設計文件，對後面的開發、測試、實施、維護工作起到關鍵性的影響。

一、問題的提出

概要設計寫什麼？概要設計怎麼做？

如何判斷設計的模組是完整的？

為什麼說設計階段過於重視業務流程是個誤區？

以需求分析文件還是以概要設計文件來評估開發工作量、指導開發計劃準確？

結構化好還是面向物件好？

以上問題的答案請在文章中找。

二、概要設計的目的

將軟體系統需求轉換為未來系統的設計；

逐步開發強壯的系統構架；

使設計適合於實施環境，為提高效能而進行設計；

結構應該被分解為模組和庫。

三、概要設計的任務

制定規範：程式碼體系、介面規約、命名規則。這是專案小組今後共同作戰的基礎，有了開發規範和程式模組之間和專案成員彼此之間的介面規則、方式方法，大家就有了共同的工作語言、共同的工作平臺，使整個軟體開發工作可以協調有序地進行。

總體結構設計：

功能（加工）－>模組：每個功能用那些模組實現，保證每個功能都有相應的模組來實現；

模組層次結構：某個角度的軟體框架檢視；

模組間的呼叫關係：模組間的介面的總體描述；

模組間的介面：傳遞的資訊及其結構；

處理方式設計：滿足功能和效能的演算法

使用者介面設計；

資料結構設計：

詳細的資料結構：表、索引、檔案；

演算法相關邏輯資料結構及其操作；

上述操作的程式模組說明（在前臺？在後臺？用檢視？用過程？······）

介面控制表的資料結構和使用規則

其他效能設計。

四、概要設計寫什麼

結構化軟體設計說明書結構（因篇幅有限和過時嫌疑，在此不作過多解釋）

任務：目標、環境、需求、侷限；

總體設計：處理流程、總體結構與模組、功能與模組的關係；

介面設計：總體說明外部使用者、軟、硬體介面；內部模組間介面（注：介面≈系統介面）

資料結構：邏輯結構、物理結構，與程式結構的關係；

模組設計：每個模組“做什麼”、簡要說明“怎麼做”（輸入、輸出、處理邏輯、與其它模組的介面，與其它系統或硬體的介面），處在什麼邏輯位置、物理位置；

執行設計：執行模組組合、控制、時間；

出錯設計：出錯資訊、處錯處理；

其他設計：保密、維護；

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 非功能性需求

五、概要設計怎麼做

結構化軟體設計方法：

詳細閱讀需求規格說明書，理解系統建設目標、業務現狀、現有系統、客戶需求的各功能說明；

分析資料流圖，弄清資料流加工的過程；

根據資料流圖決定資料處理問題的型別（變換型、事務型、其他型）；

透過以上分析，推匯出系統的初始結構圖；

對初始結構圖進行改進完善：所有的加工都要能對應到相應模組（模組的完整性在於他們完成了需求中的所有加工），消除完全相似或區域性相似的重複功能（智者察同），理清模組間的層次、控制關係，減少高扇出結構，隨著深度增大扇入，平衡模組大小。

由對資料字典的修改補充完善，匯出邏輯資料結構，匯出每種資料結構上的操作，這些操作應當屬於某個模組。

確定系統包含哪些應用服務系統、客戶端、資料庫管理系統；

確定每個模組放在哪個應用伺服器或客戶端的哪個目錄、哪個檔案（庫），或是在資料庫內部建立的物件。

對每個篩選後的模組進行列表說明。

對邏輯資料結構進行列表說明。

根據結構化軟體設計說明書結構對其他需要說明的問題進行補充說明，形成概要設計說明書。

OO軟體設計方法：

在OOA基礎上設計物件與類：在問題領域分析（業務建模和需求分析）之後，開始建立系統構架。

第一步是抽取建立領域的概念模型，在UML中表現為建立物件類圖、活動圖和互動圖。物件類就是從物件中經過“察同”找出某組物件之間的共同特徵而形成類：

物件與類的屬性：資料結構；

物件與類的服務操作：操作的實現演算法；

物件與類的各外部聯絡的實現結構；

設計策略：充分利用現有的類；

方法：繼承、複用、演化；

活動圖用於定義工作流，主要說明工作流的5W（Do What、Who Do、When Do、Where Do、Why Do）等問題，互動圖把人員和業務聯絡在一起是為了理解互動過程，發現業務工作流中相互互動的各種角色。

第二步是構建完善系統結構：對系統進行分解，將大系統分解為若干子系統，子系統分解為若干軟體元件，並說明子系統之間的靜態和動態介面，每個子系統可以由用例模型、分析模型、設計模型、測試模型表示。軟體系統結構的兩種方式：層次、塊狀

層次結構：系統、子系統、模組、元件（同一層之間具有獨立性）；

塊狀結構：相互之間弱耦合

系統的組成部分：

問題論域：業務相關類和物件(OOA的重點)；

資料管理：資料管理方法、邏輯物理結構、操作物件類；

任務管理：任務協調和管理程序；