oo軟體設計說明書結構

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