概要設計寫法

1、概要設計怎么寫做軟件到定層次了，就要考慮到設計了，設計了很久，就是不系統，系統的設計需要一個 記錄，記錄就用文檔，那么對項目所有包括技術上的設計都記錄下來，我們就可以理解為軟 件的概要設計了。設計規(guī)范以做參考在需求明確、準備開始編碼之前，要做概要設計，而詳細設計可能大部分公司沒有做，有做 的也大部分是和編碼同步進行，或者在編碼之后。因此，對大部分的公司來說，概要設計文 檔是唯一的設計文檔，對后面的開發(fā)、測試、實施、維護工作起到關鍵性的影響。一、問題的提出概要設計寫什么？概要設計怎么做？如何判斷設計的模塊是完整的？為什么說設計階段過于重視業(yè)務流程是個誤區(qū)？以需求分析文檔還是以概要設計文檔來評估開

2、發(fā)工作量、指導開發(fā)計劃準確？結構化好還是面向對象好？以上問題的答案請在文章中找。二、概要設計的目的將軟件系統需求轉換為未來系統的設計；逐步開發(fā)強壯的系統構架；使設計適合于實施環(huán)境，為提高性能而進行設計；結構應該被分解為模塊和庫。三、概要設計的任務制定規(guī)范：代碼體系、接口規(guī)約、命名規(guī)則。這是項目小組今后共同作戰(zhàn)的基礎，有了 開發(fā)規(guī)范和程序模塊之間和項目成員彼此之間的接口規(guī)則、方式方法，大家就有了共同的工 作語言、共同的工作平臺，使整個軟件開發(fā)工作可以協調有序地進行?？傮w結構設計：功能（加工）一模塊：每個功能用那些模塊實現，保證每個功能都有相應的模塊來實現；模塊層次結構：某個角度的軟件框架視圖；模

3、塊間的調用關系：模塊間的接口的總體描述；模塊間的接口：傳遞的信息及其結構；處理方式設計：滿足功能和性能的算法用戶界面設計；數據結構設計：詳細的數據結構：表、索引、文件；算法相關邏輯數據結構及其操作；上述操作的程序模塊說明（在前臺？在后臺？用視圖？用過程？）接口控制表的數據結構和使用規(guī)則其他性能設計。四、概要設計寫什么結構化軟件設計說明書結構任務：目標、環(huán)境、需求、局限；總體設計：處理流程、總體結構與模塊、功能與模塊的關系；接口設計：總體說明外部用戶、軟、硬件接口；內部模塊間接口（注：接口 W系統界面）數據結構：邏輯結構、物理結構，與程序結構的關系；模塊設計：每個模塊“做什么”、簡要說明“怎么做

4、”（輸入、輸出、處理邏輯、與其它模塊的 接口，與其它系統或硬件的接口），處在什么邏輯位置、物理位置；運行設計：運行模塊組合、控制、時間；出錯設計：出錯信息、處錯處理；其他設計：保密、維護；OO軟件設計說明書結構1概述系統簡述、軟件設計目標、參考資料、修訂版本記錄這部分論述整個系統的設計目標，明確地說明哪些功能是系統決定實現而哪些不準備實現 的。同時，對于非功能性的需求例如性能、可用性等，亦需提及。需求規(guī)格說明書對于這部 分的內容來說是很重要的參考，看看其中明確了的功能性以及非功能性的需求。這部分必須說清楚設計的全貌如何，務必使讀者看后知道將實現的系統有什么特點和功能。在隨后的文檔部分，將解釋設

5、計是怎么來實現這些的。2術語表對本文檔中所使用的各種術語進行說明。如果一些術語在需求規(guī)格說明書中已經說明過了， 此處不用再重復，可以指引讀者參考需求說明。3用例此處要求系統用用例圖表述（UML），對每個用例（正常處理的情況）要有中文敘述。4設計概述4.1簡述這部分要求突出整個設計所采用的方法（是面向對象設計還是結構化設計）、系統的體系 結構（例如客戶/服務器結構）以及使用到的相應技術和工具（例如OMT、Rose）4.2系統結構設計這部分要求提供高層系統結構（頂層系統結構、各子系統結構）的描述，使用方框圖來顯 示主要的組件及組件間的交互。最好是把邏輯結構同物理結構分離，對前者進行描述。別忘 了說

6、明圖中用到的俗語和符號。4.3系統界面各種提供給用戶的界面以及外部系統在此處要予以說明。如果在需求規(guī)格說明書中已經對 用戶界面有了敘述，此處不用再重復，可以指引讀者參考需求說明。如果系統提供了對其它 系統的接口，比如說從其它軟件系統導入/導出數據，必須在此說明。4.4約束和假定描述系統設計中最主要的約束，這些是由客戶強制要求并在需求說明書寫明的。說明系統 是如何來適應這些約束的。另外如果本系統跟其它外部系統交互或者依賴其它外部系統提供一些功能輔助，那么系統 可能還受到其它的約束。這種情況下，要求清楚地描述與本系統有交互的軟件類型以及這樣 導致的約束。實現的語言和平臺也會對系統有約束，同樣在此予

7、以說明。對于因選擇具體的設計實現而導致對系統的約束，簡要地描述你的想法思路，經過怎么樣 的權衡，為什么要采取這樣的設計等等。5對象模型提供整個系統的對象模型，如果模型過大，按照可行的標準把它劃分成小塊，例如可以把 客戶端和服務器端的對象模型分開成兩個圖表述。在其中應該包含所有的系統對象。這些對 象都是從理解需求后得到的。要明確哪些應該、哪些不應該被放進圖中。所有對象之間的關 聯必須被確定并且必須指明聯系的基數。聚合和繼承關系必須清楚地確定下來。每個圖必須 附有簡單的說明。6對象描述在這個部分敘述每個對象的細節(jié)，它的屬性、它的方法。在這之前必須從邏輯上對對象進 行組織。你可能需要用結構圖把對象按

8、子系統劃分好。為每個對象做一個條目。在系統對象模型中簡要的描述它的用途、約束（如只能有一個實 例），列出它的屬性和方法。如果對象是存儲在持久的數據容器中，標明它是持久對象，否 則說明它是個臨時對象（transient object）。對每個對象的每個屬性詳細說明：名字、類型，如果屬性不是很直觀或者有約束（例如， 每個對象的該屬性必須有一個唯一的值或者值域是有限正整數等）。對每個對象的每個方法詳細說明：方法名，返回類型，返回值，參數，用途以及使用的算 法的簡要說明（如果不是特別簡單的話）。如果對變量或者返回值由什么假定的話， Pre-conditions和Post-conditions必須在此說

9、明。列出它或者被它調用的方法需要訪問或者 修改的屬性。最后，提供可以驗證實現方法的測試案例。7動態(tài)模型這部分的作用是描述系統如何響應各種事件。一般使用順序圖和狀態(tài)圖。確定不同的場景（Scenario）是第一步，不需要確定所有可能的場景，但是必須至少要覆 蓋典型的系統用例。不要自己去想當然地創(chuàng)造場景，通常的策略是描述那些客戶可以感受得 到的場景。7.1 場景（Scenarios）對每個場景做一則條目，包括以下內容：場景名：給它一個可以望文生義的名字場景描述：簡要敘述場景是干什么的以及發(fā)生的動作的順序。順序圖：描述各種事件及事件發(fā)生的相對時間順序。7.2狀態(tài)圖這部分的內容包括系統動態(tài)模型重要的部分

10、的狀態(tài)圖?？赡苣阆霝槊總€對象畫一個狀態(tài)圖， 但事實上會導致太多不期望的細節(jié)信息，只需要確定系統中一些重要的對象并為之提供狀態(tài) 圖即可。8非功能性需求五、概要設計怎么做結構化軟件設計方法：詳細閱讀需求規(guī)格說明書，理解系統建設目標、業(yè)務現狀、現有系統、客戶需求的各功能 說明；分析數據流圖，弄清數據流加工的過程；根據數據流圖決定數據處理問題的類型（變換型、事務型、其他型）；通過以上分析，推導出系統的初始結構圖；對初始結構圖進行改進完善：所有的加工都要能對應到相應模塊（模塊的完整性在于他們 完成了需求中的所有加工），消除完全相似或局部相似的重復功能（智者察同），理清模塊 間的層次、控制關系，減少高扇出

11、結構，隨著深度增大扇入，平衡模塊大小。由對數據字典的修改補充完善，導出邏輯數據結構，導出每種數據結構上的操作，這些操 作應當屬于某個模塊。確定系統包含哪些應用服務系統、客戶端、數據庫管理系統；確定每個模塊放在哪個應用服務器或客戶端的哪個目錄、哪個文件（庫），或是在數據庫 內部建立的對象。對每個篩選后的模塊進行列表說明。對邏輯數據結構進行列表說明。根據結構化軟件設計說明書結構對其他需要說明的問題進行補充說明，形成概要設計說明 書。OO軟件設計方法：在OOA基礎上設計對象與類：在問題領域分析（業(yè)務建模和需求分析）之后，開始建立 系統構架。第一步是抽取建立領域的概念模型，在UML中表現為建立對象類圖

12、、活動圖和交互圖。 對象類就是從對象中經過“察同”找出某組對象之間的共同特征而形成類：對象與類的屬性：數據結構；對象與類的服務操作：操作的實現算法；對象與類的各外部聯系的實現結構；設計策略：充分利用現有的類；方法：繼承、復用、演化；活動圖用于定義工作流，主要說明工作流的5W（Do What、Who Do、When Do、WhereDo、Why Do）等問題，交互圖把人員和業(yè)務聯系在一起是為了理解交互過程，發(fā)現業(yè)務工 作流中相互交互的各種角色。第二步是構建完善系統結構：對系統進行分解，將大系統分解為若干子系統，子系統分解 為若干軟件組件，并說明子系統之間的靜態(tài)和動態(tài)接口，每個子系統可以由用例模型

13、、分析 模型、設計模型、測試模型表示。軟件系統結構的兩種方式：層次、塊狀層次結構：系統、子系統、模塊、組件（同一層之間具有獨立性）；塊狀結構：相互之間弱耦合系統的組成部分：問題論域：業(yè)務相關類和對象（OOA的重點）；人機界面：窗口、菜單、按鈕、命令等等；數據管理：數據管理方法、邏輯物理結構、操作對象類；任務管理：任務協調和管理進程；第三步是利用“4+1”視圖描述系統架構：用例視圖及劇本；說明體系結構的設計視圖；以 模塊形式組成包和層包含概要實現模型的實現視圖；說明進程與線程及其架構、分配和相互 交互關系的過程視圖；說明系統在操作平臺上的物理節(jié)點和其上的任務分配的配置視圖。在 RUP中還有可選的

14、數據視圖。第四步是性能優(yōu)化（速度、資源、內存）、模型清晰化、簡單化（簡單就是享受）。六、概要設計的原則總體原則和方法：由粗到細的原則，互相結合的原則，定性分析和定量分析相結合的方法， 分解和協調的方法和模型化方法。要系統考慮系統的一般性、關聯性、整體性和層次性。分解協調：目的是為了創(chuàng)造更好的系統。系統分解是指將一個復雜的系統分解為若干個子 系統，系統協調一是系統內協調，即根據系統的總結構、總功能、總任務和總目標的要求， 使各個子系統之間互相協調配合，在各個子系統局部優(yōu)化基礎上，通過內部平衡的協調控制， 實現系統的整體優(yōu)化；屏蔽抽象：從簡單的框架開始，隱含細節(jié)；一致性：統一的規(guī)范、統一的標準、統

15、一的文件模式；每個模塊應當有一個統一命名的容易理解的名字；編碼：由外向內（界面一 核心）；面向用戶：概要設計是對于按鈕按下后系統怎么做”的簡要說明；模塊、組件的充分獨立性、封閉性；同時考慮靜態(tài)結構與動態(tài)運行；每個邏輯對象都應當說明其所處物理對象（非一一對應）；每個物理對象都有合適的開發(fā)人員，并且利于分工與組裝。（詳細說明見本人另一篇文章： 系統構架設計應考慮的因素）；確立每個構架視圖的整體結構：視圖的詳細組織結構、元素的分組以及這些主要分組之間 的接口；軟件構架與使用的技術平臺密切相關，目前常用的平臺有J2EE、.NET、CORBA等等， 因此具體的軟件構架人員應當具備使用這些平臺的軟件開發(fā)經

16、驗；通過需求功能與設計模塊之間的列表對應，檢查每個需求功能是否都有相應的模塊來實現， 保證需求功能的可追溯性和需求實現（模塊）的完整性，同時可以檢查重復和不必要的模塊。在需求調研分析過程中對業(yè)務處理過程了解的完整性和準確性非常重要。調查了解清楚所 有的業(yè)務流程才能設計出適合各流程業(yè)務節(jié)點用戶業(yè)務特點和習慣的軟件，使開發(fā)出來的軟 件更受歡迎。當然在進行軟件概要設計時，要盡量排除業(yè)務流程的制約，即把流程中的各項 業(yè)務結點工作作為獨立的對象，設計成獨立的模塊，充分考慮他們與其他各種業(yè)務對象模塊 的接口，在流程之間通過業(yè)務對象模塊的相互調用實現各種業(yè)務，這樣，在業(yè)務流程發(fā)生有 限的變化時（每個業(yè)務模塊

17、本身的業(yè)務邏輯沒有變的情況下），就能夠比較方便地修改系統 程序模塊間的調用關系而實現新的需求。如果這種調用關系被設計成存儲在配置庫的數據字 典里，則連程序代碼都不用修改，只需修改數據字典里的模塊調用規(guī)則即可。七、概要設計的重要輸出編碼規(guī)范：信息形式、接口規(guī)約、命名規(guī)則；物理模型：組件圖、配置圖；不同角度的構架視圖：用例視圖、邏輯視圖、進程視圖、部署視圖、實施視圖、數據視圖 （可選）；系統總體布局：哪些部分組成、各部分在物理上、邏輯上的相互關系；兩個不可忽視的輸出：與需求功能的關系：對于需求中的每一個功能，用哪一層、哪個模塊、哪個類、哪個對象 來實現（一對多關系）；反過來，應當說明將要創(chuàng)建的系統

18、每一層、每個模塊、每個對象、 每一個類“做什么二他們是為了幫助實現哪些功能（一對多關系）。（需求的顆粒度在一開 始往往是比較粗的，因此根據功能點對于整體項目規(guī)模的估計或得到項目WBS其誤差范圍 也是比較大的。更為重要的原因是，需求往往不是編碼工作分解的準確依據，因為一個需求 的功能點可能對應多個代碼模塊，而多個需求的功能點也可能只對應一個或少數代碼模塊， 同時還有軟件復用等因素要考慮，因此只有在概要設計完成以后才能準確地得到詳細設計或 編碼階段的二次WBS，并估計較為準確的整體項目規(guī)模。）邏輯與物理位置：每個對象在邏輯上分別落在哪一層、哪個模塊、哪個類；在物理上每個 模塊、每個對象、每一個類放在哪個應用服務器或客戶端的哪個目錄、哪個文件（庫），或 者是建立在數據庫管理系統中的什么東東（過程、函數、視圖、觸發(fā)器等