軟體架構文件化  

    記錄軟體架構的活動就是架構編檔過程，也就是架構的文件化。它包含兩個方面：一是過程，編檔過程能促使架構設計師進一步思考，使得架構更加完善；二是結果，描述架構的文件將作為架構開發的成果，供專案關係人使用。

    1．架構文件的使用者

    架構文件的使用者是架構的專案關係人。編寫技術文件（尤其是軟體架構文件）最基本的原則之一是要從讀者的角度來編寫，易於編寫但很難閱讀的文件是不受歡迎的。

   架構的主要用途是充當專案關係人之間進行交流的工具，文件則促進了這種交流—— 架構專案關係人希望從架構文件中獲得自己所關心的架構資訊，如：系統實現人員希望文件提供關於開發活動的不能違反的限制及可利用的自由；測試人員和整合人員希望能從文件中得到必須組合在一起的各部分，並以此得到一個正確的測試黑箱；專案經理希望根據所確定的工作任務組建開發小組，規劃和分配專案資源。

    2．合理的編檔規則編寫架構文件和編寫其他文件一樣，必須遵守一些基本規則，這裡將任何軟體編檔（包括軟體架構編檔）的規則歸納為 7 條：

    （1）從讀者的角度編寫文件。

    （2）避免出現不必要的重複。

    （3）避免歧義。

    （4）使用標準結構。

    （5）記錄基本原理。

    （6）使文件保持更新，但更新頻率不要過高。

    （7）針對目標的適宜性對文件進行評審。

     3．檢視編檔 

    檢視是最重要的軟體架構編檔概念，本書將在 9.11 節中專門討論架構的檢視。檢視的概念為架構設計師提供了進行軟體架構編檔的基本原則。架構文件化就是將相關檢視編成文件，並補充多個檢視的關聯關係。

    檢視編檔的組織結構（內容及編排次序、大綱）雖然目前還沒有工業標準模板，研究者（Bachmann 等人）提出的文件組織結構包含 7 個部分，如圖 9-18 所示。

    （1）檢視概述：對系統進行概括性的描述，包含檢視的主要元素和元素間的關係（但並不包含所有元素和元素間的關

系，如：與錯誤處理相關的內容可以放在支援文件中）。主要表示可用多個形式：圖形、表格、文字，通常用圖形形式，使用UML 語言來描述。

    （2）元素目錄：對主要表示中所描述的元素及其關係進行詳細描述，包括：元素及其 屬性、關係及其屬性、元素介面、元素行為。

   這部分是文件的主要組成部分，其中要注意：

• —對元素及其協同工作的行為進行編檔，如用UML 的順序圖和狀態圖描述行為；

• —對介面進行編檔，圖9-19 說明了這部分的內容。

    （3）上下文圖：用圖形展示系統如何與其環境相關。

    （4）可變性指南：描述架構的可變化點，如在軟體產品線中，產品線架構通過變化，適用於多個系統，因此，文件中應包含這些變化點，如各系統要做出選擇的選項、做出選擇的時間。

    （5）架構背景：為架構的合理性提供足夠的、令人信服的論據。包括：基本原理、分析結果及設計中所反映的假定。

    （6）術語表：對文件中每個術語進行簡要說明。

    （7）其他資訊：描述不屬於架構方面的必要資訊，如管理資訊（創作者、配置控制資料及變更歷史）。 

    4．跨檢視文件

    軟體架構由多個檢視文件來反映，按前面所述的要求完成每個檢視的文件後，需要對這些文件進行一個整體的“打包”工作，這就是跨檢視文件。它包括如下內容：

    （1）文件有哪些內容，它們是如何組織的：檢視目錄（含哪些檢視）；檢視模板（即前面描述的檢視文件，企業可以通過規範化來定義統一的、公共的檢視模板）。

    （2）架構概述：它描述系統的目的、檢視之間的關聯、元素表及索引、專案詞彙。

    （3）為什麼架構是這樣的（基本原理）：跨檢視基本原理解釋了整體架構實際上是其需求的一個解決方案。即解釋了做出決策的原因、方案的限制、改變決策時的影響及意義。

    5．使用 UML

    UML已經成為對軟體架構進行文件化的事實上的標準表示法。在檢視文件的組織結構中，UML 主要用於表示元素或元素組的行為。

    6．軟體架構重構

    前面已論述了架構編檔，即在架構設計時完成編檔工作。但是還有另外一種情況：系統已經存在，但不知其架構，即架構沒有通過文件很好地保留下來（文件的缺失/失效）。如何維護這樣的系統並管理其演變？其關鍵就是要找到軟體架構，軟體架構重構就是研究解決這一問題的方法，它是反向工程之一。

    架構重構需要工具的支援，但任何一個工具或工具集對架構重構都是不夠的。因為：

• 工具往往是面向特定語言的；

• 資料提取工具經常返回不完整的或錯誤的結果，因此，應在多個工具提供的結果間進行補充、驗證和判斷；

• 重構的目的（文件的用途）不同，決定了需要提取什麼資料，這反過來影響了工具的選擇。以此為原則，就是架構重構的工作臺方法，如 SEI 開發的 Dali。

     軟體架構重構由以下活動組成，這些活動以迭代方式進行，如圖 9-20 所示。

    （1）資訊提取（View Extraction）。可以使用各種工具進行資訊提取，如解析器、語法分析器等；可以利用 build 和 makefile 檔案中關於模組的依賴關係；可以從原始碼、編譯時製品和設計製品中提取靜態資訊；可以使用分析工具提取動態資訊。

    （2）資料庫構造（Database Construction）：將提取的資訊轉化為標準的形式，並置於資料庫中。

    （3）檢視融合（View Fusion）：將資料庫中的資訊組合在一起，生成該架構的一個內聚的檢視。

    （4）重構（Reconstruction）：構建資料抽象和各種表示以生成架構表示，主要由兩個活動組成：視覺化和互動、模式定義和識別。最後生成需要的架構文件（Documentation）。

    上述過程中，架構是由重構人員通過對系統做出一組假定來獲得，為了最有效地生成這些假定並對其進行驗證，必須讓熟悉系統的人蔘與此項工作，包括過去參與系統開發的人員或現在正在對其進行維護的人員。