實現軟體質量屬性的戰術，這些戰術可以看做設計的基本“構建塊”，通過這些構建塊，就可以精心設計系統的軟體架構了。

    架構模式也稱為架構風格，它是適當地選取戰術的結果，這些固定的結果（模式）在高層抽象層次上具有普遍實用性和複用性。

    通過架構模式，架構設計師可以借鑑和複用他人的經驗，看看類似的問題別人是如何解決的。但不要把模式看成是一個硬性的解決方法，它只是一種解決問題的思路。Martin Fowler 曾說：“模式和業務構件的區別就在於模式會引發你的思考。”

    在本章的後續部分將進一步討論架構模式。

    1．演變交付生命週期

    業界已開發出各種軟體生命週期模型，其中把架構放在一個適當位置的模型中，典型的有演變交付生命週期模型，如圖 9-17 所示。

    在生命週期模型中，架構設計就是從初步的需求分析開始逐步進行迴圈迭代（圖 9-17 中的反向箭頭說明了這一點）。即：一方面在瞭解系統需求前，不能開始設計架構；另一方面，剛開始進行設計架構時並不需要等到全部需求都收集到。架構是由“架構驅動”因素“塑造”的，架構因素是指少數關鍵的、優先級別最高的業務目標質量需求。架構由少數關鍵需求決定並在迴圈迭代中處於基本穩定狀態，它作為演變的基礎設施。

    2．屬性驅動設計法

    上述模型強調先建立軟體架構，再把架構作為骨架，在骨架上迴圈迭代，逐步長出有血有肉的系統之軀。屬性驅動設計法（Attribute-Driven Design，ADD）就是一種定義軟體架構的方法，該方法將分解過程建立在軟體必須滿足的質量屬性之上。ADD  的輸入為：功能需求（一般表示為用例）、限制條件和質量需求（一組特定於系統的質量場景）。

    ADD 的步驟如下。

    （1）選擇要分解的模組。通常是整個系統，要求上述輸入都是可獲得的（限制條件、功能需求、質量需求）。從系統開始，然後分解為子系統，進一步將子系統分解為子模組。

    （2）根據如下步驟對模組進行求精：

• 從具體的質量場景和功能需求集合中選擇架構驅動因素。並不是同等看待所有需求，而是在滿足了最重要的需求的條件下，才滿足不太重要的需求，即針對架構需求有優先順序。

• 選擇滿足架構驅動因素的架構模式，根據前面的戰術建立（或選擇）模式。其目標是建立一個由模組型別組成的總體架構模式。

• 例項化模組並根據用例分配功能，使用多個檢視進行表示。

• 定義子模組的介面。

• 驗證用例和質量場景，並對其進行求精，使它們成為子模式的限制。

   （3）對需要進一步分解的每個模組重複上述步驟。

    3．按架構組織開發團隊

    在架構的模組分解結構的最初幾個層次相對穩定之後，就可以把這些模組分配給開發小組，其結果就是工作檢視。像軟體系統一樣，開發小組也應該努力做到鬆耦合、高內聚。即每個模組都構成自己的小領域（專門知識或專門技術），並與其他模組的介面清晰，這樣，不同的模組分到不同的開發小組中，就能減少各開發小組之間的溝通成本，而在各開發小組內部，由於是處理小領域的問題，容易建立起有效的溝通機制，如成員有這個小領域的背景知識（或培訓獲得）、共享決策資訊。

    同時，專案計劃在架構確定之後可以結合分工進一步明細化，特別要規劃好介面提供的時間點，保證專案開發的整體協調性。

    4．開發骨架系統

    演變交付生命週期模型中有兩個迴圈，第一個迴圈是通過迭代的方式開發出軟體架構，第二個迴圈是在架構的基礎上通過迭代的方式開發出交付的最終版本。開發骨架系統就是第二個迴圈的第一步。這一步就是以架構為指導，開發一個可執行的原型（骨架系統）。在骨架系統開發過程中要注意對介面進行充分協商，避免先開發的部分強制隨後部分滿足其不合理的介面要求。骨架系統完成後，就可以在其上進行增量開發，直到軟體開發完成。

    5．利用商用構件進行開發

    模式本來就是針對特定問題的解，因此，針對需求的特點，也可以選用相應的模式來設計架構，並利用對應於該模式的商用構件進行軟體開發。例如可以使用 J2EE/EJB 進行開發面向物件的分散式系統。