軟件設(shè)計說明書

1、1概述 1.1系統(tǒng)簡述對系統(tǒng)要完成什么，所面向的用戶以及系統(tǒng) 運行的環(huán)境的簡短描述，這部分主要來源于 需求說明書的開始部分。1.2軟件設(shè)計目標這部分論述整個系統(tǒng)的設(shè)計目標，明確地說 明哪些功能是系統(tǒng)決定實現(xiàn)而哪些時不準 備實現(xiàn)的。同時，對于非功能性的需求例如 性能、可用性等，亦需提及。需求規(guī)格說明 書對于這部分的內(nèi)容來說是很重要的參考，看看其中明確了的功能性以及非功能性的 需求。這部分必須說清楚設(shè)計的全貌如何，務(wù)必使 讀者看后知道將實現(xiàn)的系統(tǒng)有什么特點和 功能。在隨后的文檔部分，將解釋設(shè)計是怎 么來實現(xiàn)這些的。1.3參考資料列出本文檔中所引用的參考資料。（至少要 引用需求規(guī)格說明書）1.4修訂

2、版本記錄列出本文檔修改的歷史紀錄。必須指明修改的內(nèi)容、日期以及修改人。2術(shù)語表對本文檔中所使用的各種術(shù)語進行說明。如 果一些術(shù)語在需求規(guī)格說明書中已經(jīng)說明 過了，此處不用再重復，可以指引讀者參考 需求說明。3用例此處要求系統(tǒng)用用例圖表述（UML），對每 個用例（正常處理的情況）要有中文敘述。4設(shè)計概述4.1簡述 這部分要求突出整個設(shè)計所采用的方法（是 面向?qū)ο笤O(shè)計還是結(jié)構(gòu)化設(shè)計）、系統(tǒng)的體 系結(jié)構(gòu)（例如客戶/服務(wù)器結(jié)構(gòu)）以及使用到 的相應技術(shù)和工具（例如OMT、Rose）4.2系統(tǒng)結(jié)構(gòu)設(shè)計這部分要求提供高層系統(tǒng)結(jié)構(gòu)的描述，使用 方框圖來顯示主要的組件及組件間的交互。 最好是把邏輯結(jié)構(gòu)同物理結(jié)構(gòu)

3、分離，對前者 進行描述。別忘了說明圖中用到的俗語和符 號。4.2.1頂層系統(tǒng)結(jié)構(gòu)4.2.2子系統(tǒng)1結(jié)構(gòu) 4.2.3子系統(tǒng)2結(jié)構(gòu)4.3系統(tǒng)界面各種提供給用戶的界面以及外部系統(tǒng)在此 處要予以說明。如果在需求規(guī)格說明書中已 經(jīng)對用戶界面有了敘述，此處不用再重復， 可以指引讀者參考需求說明。如果系統(tǒng)提供 了對其它系統(tǒng)的接口，比如說從其它軟件系 統(tǒng)導入/導出數(shù)據(jù)，必須在此說明。4.4約束和假定 描述系統(tǒng)設(shè)計中最主要的約束，這些是由客 戶強制要求并在需求說明書寫明的。說明系 統(tǒng)是如何來適應這些約束的。另外如果本系統(tǒng)跟其它外部系統(tǒng)交互或者 依賴其它外部系統(tǒng)提供一些功能輔助，那么 系統(tǒng)可能還受到其它的約束。這

4、種情況下， 要求清楚地描述與本系統(tǒng)有交互的軟件類 型（比如某某某數(shù)據(jù)庫軟件，某某某EMail 軟件）以及這樣導致的約束（比如只允許純 文本的Email）。實現(xiàn)的語言和平臺也會對系統(tǒng)有約束，同樣 在此予以說明。對于因選擇具體的設(shè)計實現(xiàn)而導致對系統(tǒng)的約束，簡要地描述你的想法思路，經(jīng)過怎 么樣的權(quán)衡，為什么要采取這樣的設(shè)計等5對象模型5.1系統(tǒng)對象模型提供整個系統(tǒng)的對象模型，如果模型過大， 按照可行的標準把它劃分成小塊，例如可以 把客戶端和服務(wù)器端的對象模型分開成兩 個圖表述。對象圖應該包含什么呢？ 在其中應該包含所有的系統(tǒng)對象。這些對象 都是從理解需求后得到的。要明確哪些應 該、哪些不應該被放進圖

5、中。所有對象之間的關(guān)聯(lián)必須被確定并且必須 指明聯(lián)系的基數(shù)（一對一、一對多還是多對 多，0.1, *，1.*）。聚合和繼承關(guān)系必須 清楚地確定下來。每個圖必須附有簡單的說 明?？赡芙?jīng)過多次反復之后才能得到系統(tǒng)的正 確的對象模型。6對象描述 在這個部分敘述每個對象的細節(jié)，它的屬 性、它的方法。在這之前必須從邏輯上對對 象進行組織。你可能需要用結(jié)構(gòu)圖把對象按 子系統(tǒng)劃分好。為每個對象做一個條目。在系統(tǒng)對象模型中 簡要的描述它的用途、約束（如只能有一個 實例），列出它的屬性和方法。如果對象是 存儲在持久的數(shù)據(jù)容器中，標明它是持久對 象，否則說明它是個臨時對象（transientobject）0對每個對

6、象的每個屬性詳細說明：名字、類 型，如果屬性不是很直觀或者有約束（例如， 每個對象的該屬性必須有一個唯一的值或 者值域是有限正整數(shù)等）。對每個對象的每個方法詳細說明：方法名， 返回類型，返回值，參數(shù)，用途以及使用的 算法的簡要說明（如果不是特別簡單的話）。 如果對變量或者返回值由什么假定的話， Pre-conditions 和 Post-conditions 必須在此 說明。列出它或者被它調(diào)用的方法需要訪問 或者修改的屬性。最后，提供可以驗證實現(xiàn) 方法的測試案例。6.1子系統(tǒng)1中的對象6.1.1對象：對象1用途：約束：持久性：6.1.1.1屬性描述:屬性：屬性1類型：描述：約束：屬性：屬性26

7、.1.1.2方法描述:1.方法：方法1返回類型參數(shù)：返回值：Pre-Condition：Post-Condition：讀取/修改的屬性:調(diào)用的方法： 處理邏輯：測試例：用什么參數(shù)調(diào)用該方法，期望的輸 出是什么7動態(tài)模型這部分的作用是描述系統(tǒng)如何響應各種事 件。例如，可以建立系統(tǒng)的行為模型。一般 使用順序圖和狀態(tài)圖。確定不同的場景(Scenario)是第一步，不 需要確定所有可能的場景，但是必須至少要 覆蓋典型的系統(tǒng)用例。不要自己去想當然地 創(chuàng)造場景，通常的策略是描述那些客戶可以 感受得到的場景。7.1 場景(Scenarios)對每個場景做一則條目，包括以下內(nèi)容： 場景名：給它一個可以望文生義的名字 場景描述：簡要敘述場景是干什么的以及發(fā) 生的動作的順序。順序圖：描述各種事件及事件發(fā)生的相對時 間順序。7.1.1場景：場景1描述：動作1動作27.2狀態(tài)圖這部分的內(nèi)容包括系統(tǒng)動態(tài)模型重要的部 分的狀態(tài)圖?？赡苣阆霝槊總€對象畫一個狀 態(tài)圖，但事實上會導致太多不期望的細節(jié)信 息，只需要確定系統(tǒng)中一些重要的對象并為 之提供狀態(tài)圖即可。7.2.1狀態(tài)圖1：非功能性需求 在這個部分，必須說明如何處理需求文檔中 指定的非功能性需求。盡可能客觀地評估系