轉自：http://blog.chinaunix.net/uid-26847614-id-3159126.html
3.體系結構文檔模板
3.1引言部分
這部分引入此體系架構和相關的人員。記錄架構文檔的創建和修改時間。細節部分如下：
（1）架構的名字，是架構總覽還是具體的參考手冊
（2）設計團隊和架構文檔的作者信息，以及要想哪些相關人員反饋問題
（3）創建和修改歷史
（4）受衆和文檔目的
（5）一些可選性的觀點
（6）記錄與其它軟件開發相關文檔的關聯，如需求說明、架構說明、設計說明、內部參考說明等等。
（7）可選的觀點，包括觀點描述和模型
（8）如果此架構文檔與某個項目關聯可羅列項目名、發佈日期、項目團隊以及產品團隊等（可選）
3.2系統目的
此部分主要說明系統的目的和它要結局的問題，這部分是一個概覽性的說明，不需要關心內部結構實現，且不能滿足需求說明的功能要記錄。
（1）系統運行環境和它解決的問題
（2）系統提供哪些服務以及具有何總特徵，主要是包含哪些接口
（3）非功能性的需求，主要是被其他系統需求包含的部分
3.2.1 系統上下文
（1）描述系統運行環境和解決的問題。主要描述關鍵實體的角色以及實體與系統的交互而非系統本身。
（2）描述系統和運行環境的邊界。主要可以使用如下三種模型：
用例圖、類圖、數據流圖
3.2.2 系統接口部分
依據系統的任務描述接口，根據抽象度不同有所不同。其實是一種 use case的表達。
3.2.3 非功能性需求
主要描述功能之外的、但是和系統相關的。可以包含三個部分：
（1）質量。包括服務的質量（性能、產量、可用性、安全性）和系統開發的質量（可維護性、可移植性、支持性）。通常這裏只是概述含義和措施，而將細節留給系統需求文檔和架構需求文檔。
（2）系統運行環境的約束。如系統運行相關的環境、服務質量相關。這裏的約束指的是架構需求說明中約束的一個摘要。
（3）協議。描述瞭解決特定需求的方法（可能在質量和約束中提到過）。比如電子商務的易用性，可以通過增加購物手推車來完成、開發中的約束可以通過購買來完成。
3.3 structure部分
主要依照邏輯組件和接口溝通來描述靜態結構。組件具有一定的抽象級別，可以對應一個類或一組類主要指邏輯組件。可以分爲三個部分overview、每個組件的描述、所有組件接口的描述。
3.3.1 概覽部分
一個structure有一個或多個框架圖表和註釋組成。描述了框架結構。
（1）圖表。主要通過類圖和接口來進行表示。
（2）註釋。描述了框架基本原理、框架風格和樣式、指定框架約束，可能其他可選的架構（可選）
基本原理：爲何選擇此種拓撲結構和框架風格？與商業對象的關聯，解釋框架是如何滿足框架需求文檔和約束的（3.2.3）？還包含3.4.1的部分；
框架約束：是管理組件行爲和交互的重要規則，他們和體系結構的風格選擇緊密相關；
可選框架：給出這些框架的概念說明，並指明沒有選擇此種架構的原因；
框架風格：層：高級和低級的抽象組件被分成很多層。
管道和過濾器：數據被封裝在過濾器中，通過連接在過濾器間的管道傳輸；
經紀人：由經紀人連接客戶和服務；
數據和操作分離：分別放在model和interface中。
基於通信的事件：
3.3.2組件部分
（1）Component：名字、版本號、包含對組件設計文檔和實現文檔的參考；
（2）組件的功能和提供的接口；
（3）Collaborators：列出相關聯的組件；
（4）NOTE:多樣性：有多少組件實例存在於系統中？實例創建和銷燬是動態的嗎？什麼條件下創建和 銷 毀；
併發性：組件包含的數據是否需要同步讀取和寫入，
持續性：組件和它的數據需要一直存在系統的整個生命週期嗎？
參數化：描述了組件的可變性。
（5）Issues爭論點，系統還有哪些實現策略，以及對其它組件的影響。隨着系統的深入，此部分會放空。
3.3.3接口部分
（1）Interface：名字和版本號，接口可以理解爲一系列操作的組合；
（2）Description：根據接口的功能描述接口的目的；
（3）Services：對系統來說是services,對組件是一系列操作。
（4）Protocol：services和operator的一些限制。複雜協議狀態機要使用
3.4動態行爲
系統行爲可以用use case或系統操作來模型化。use case包括一個或多個外部actors和系統爲了完成特定目標的多個步驟和交互。系統操作包括一個輸入作爲觸發事件，
Scenarios Specification主要從外部觀點對系統操作和用例的細節說明，定義了框架如何動作來響應外部的觸發動作，；
mechanisms提供了Scenarios沒有覆蓋到的系統內部的行爲模型，描述了組件如何協作來產生場景定義的行爲。
3.4.1Scenarios
（1）Scenarios Specification主要從外部觀點看actors和system的交互
（2）Component Interaction Model：從內部組件之間的交互來描述
3.4.2 Mechanisms
主要是對前面未涉及的部分的補充。比如關於非功能性需求的組件和約束等有爭議的問題
3.5其它視圖
3.5.1進程視圖
主要是將邏輯視圖映射爲進程相關。可以用類圖和對象圖來表示。
3.5.2開發視圖
邏輯視圖中組件到目錄的映射
3.5.3部屬視圖
3.6概念框架
3.7結論
4.結論和感謝
5.參考文獻