建立方案架構

若要建立良好的架構，有一項很重要的工作，那就是調查替代的架構性策略。 平台的選擇、使用的技術和程式碼重複使用情形的不同，會讓替代的策略有不同的優點。 首先，您需要設計每項策略並建立概念證明，以進一步調查每項策略的成本和優點。 接著根據產品和品質需求來評估策略，進而選擇一個最終要用來實作產品的策略。 最後，就必須考慮到安全性和效能問題，來對整個產品做架構性改良。

本主題內容

• 建立替代的架構分割設計

• 設計系統架構部署

• 建立概念證明

• 評估替代項目

• 選取架構

• 開發效能模型

建立替代的架構分割設計

這個階段會分析問題，並考慮不同的方法。 您需要選出一組代表重要的業務與技術挑戰的需求。 檢查這些挑戰的特性 (例如與舊版系統的整合)，並根據目前的需求、程式碼的重複使用性以及維護成本，來預測未來的需求。

建立應用程式圖表

請以領域模型和需求為基礎，建立能代表系統核心邏輯項目的應用程式圖表。 這個圖表稍後會再分割成數個較小的系統圖表。 您屆時會考慮並評估替代的分割配置。

應用程式圖表的其中一種表示方式就是統一模組化語言 (UML) 使用案例圖表。 這類圖表可以顯示主要的子系統和其相依性。 此外，您還可以在每個子系統中加上使用案例，來顯示每個使用者情節是由哪個子系統管理。

建立評估準則

判斷要使用哪項準則來識別可代表重大架構性挑戰的需求和情節。 請閱讀現有企業架構文件來找出準則。 回顧新的應用程式所必須滿足的任何業務需求、技術需求和企業標準。 擷取其他已知很重要的架構性準則，例如與舊版系統的整合、程式碼的重複使用性、重複使用現有供應商的程式庫和平台，以及控制維護成本。 擷取其他能夠代表實作技術方案時之風險和成本的準則。

選出一組候選需求

根據評估準則，評估每項服務品質需求和產品需求。 如果有某項需求代表某種架構性挑戰，請將該需求視為建立模型時可以考慮的候選項。 例如，如新產品必須支援舊版客戶資料庫這樣的需求，便符合與舊版系統整合的準則。 這樣的需求便是建立整合運作模型時可以考慮的候選項。

選取一組候選情節

請根據評估準則來評估每個情節。 如果有某項情節代表某種架構性挑戰，請將它視為建立模型時可以考慮的候選項。 例如，如由使用者下載用戶端更新這樣的情節，便符合與維護成本有關的準則。 這樣的情節便是建立最佳的用戶端更新處理模型時可以考慮的候選項。

精縮候選群組

回顧候選的情節和需求。 移除會重複代表相同評估準則，或是可由其他情節和需求更貼切代表的情節和需求。 將候選群組精簡為一個能夠代表新應用程式之主要架構性挑戰、風險和成本的核心群組。 在設計技術方案的架構時，請保留最能夠代表評估準則、能夠呈現最多的風險以及能夠呈現最多潛在成本的情節和需求。 請保留能夠涵蓋應用程式最全面或最主要部分的情節和需求。

建立分割準則

將這些需求當做動機，來分析既有架構性模式 (例如外觀或模型檢視控制器)，並且識別可能可以實作的候選項。 透過動機來識別候選模式，並且考慮如何在這些模式設計與結合程度、一致性、擴充性、適應性及靈活性之間獲得平衡。 選出一組要實作的候選項，以做為一組要評估的替代項目。

設計系統架構和部署

系統架構定義了應用程式圖表中所識別之各項目的分組和組態。 建立系統圖表的目的，是為了要擷取每種可能之架構方法的系統架構。 部署圖表則會顯示以相依性和核心功能為基礎的部署步驟。 基礎架構設計人員會建立邏輯 DataCenter 圖表，其中描述應用程式會部署於的 DataCenter 的邏輯結構。 您需要將部署圖表和邏輯 DataCenter 圖表互相對照，來確保可以部署系統。

建立系統模型

架構設計人員和開發專案經理會依據應用程式圖表來建立系統圖表。 透過系統圖表，您可以藉由將應用程式圖表上的各個項目進行組合，設計出以部署單位呈現的可重複使用應用程式系統。 您也可以設計內含其他系統的更大、更複雜系統，以便在分散式系統情節中使用，並用這些系統代表應用程式的細節摘要。 每次建立的新圖表檔都應該簽入至版本控制。

您可以用下列方式在 Visual Studio 中呈現系統圖表：

• 使用案例圖表： 主要的使用者情節以使用者案例代表，而系統的主要元件則會顯示為子系統。 每個使用案例都可以放入負責處理的子系統中。 如需詳細資訊，請參閱 UML 使用案例圖表：方針。

• UML 元件圖表： 這些圖表可讓您顯示元件之間的通訊管道，以及相依性。 您也可能需要建立類別圖表，用這些圖表描述元件看得見的介面類型，而且您可以建立順序圖表來顯示其互動。 如需詳細資訊，請參閱 UML 元件圖表：方針、UML 類別圖表：方針和 UML 順序圖表：方針。

• 圖層圖表： 圖層圖表描述應用程式的區塊結構。 該圖表只會顯示元件和元件彼此之間的相依性。 這個圖表帶來一項優點，就是寫好程式碼之後，您可以根據這個圖表驗證程式碼和相依性。 如需詳細資訊，請參閱圖層圖表：方針。

對於每個子系統，您可以建立套件來更加詳細地描述子系統的類型和行為。 如需詳細資訊，請參閱定義套件和命名空間。

建立概念證明

建立架構性概念證明，將可減輕專案的重大風險。 專案中的風險若能越早解決，就越能在還很容易修改架構的基本部分時，做出重大的策略性和架構性決策。 越早建立概念證明，越可以降低整體的專案風險和未知數。 專案的風險越低，未知數越少，後續反覆項目中所做的規劃和預估就能越準確。 概念證明可以做為在問題解決之後就可捨棄掉的臨時概念證明，也可以建立做為核心架構的基礎。

檢查風險

了解讓您識別風險和架構性決策的要素。 檢查相關的情節和服務品質需求。 檢查是否有任何目標環境隱含風險。

規劃方法

決定需要的概念證明形式。 請使用應用程式和系統圖表協助您進行規劃。 只解決由風險所識別的架構性問題。 找出最簡單的解決方案。

建立和執行概念證明

建立概念證明。 您可以依據應用程式圖表來實作概念證明。 維持將焦點放在有待解決的問題。 將概念證明部署至與邏輯 DataCenter 圖表相符的實體環境中。 這個實體環境應盡量符合邏輯 DataCenter 圖表的設定。 針對高風險的問題測試概念證明。

評估替代項目

輕量型架構替代項目分析法 (Lightweight Architecture Alternative Analysis Method，簡稱 LAAAM) 可協助您在眾多不同的架構性策略當中，選擇一個適當的策略來建立應用程式。 LAAAM 通常需要花一天的時間來完成。 先從建立公用程式樹狀結構開始，這個樹狀結構以需求為基礎，描述應用程式重要的品質和功能性驅動因子。 每個驅動因子都是以情節的形式撰寫，而情節是一段包含情境、刺激和反應的陳述。 使用評量矩陣來評估每個策略能夠解決每個情節的程度。

建立公用程式樹狀結構

檢查服務品質需求和產品需求，以判斷應用程式在品質和功能方面的重要驅動因子。 建構公用程式樹狀結構，以表示應用程式整體品質。 樹狀結構中的根節點會標示為 Utility， 後續節點則通常會以標準品質詞彙標示，如可修改性、可用性和安全性。 樹狀結構應該代表品質的階層本質，並提供優先順序化的基礎。 樹狀結構中的每個層級都是品質的進一步細分。 最後，這些品質會變成情節。

建構評量矩陣

針對公用程式樹狀結構中的每個分葉，各撰寫一個情節。 情節為包含情境、刺激和回應的陳述形式 (例如「在標準作業下，要在 100 毫秒內執行資料庫交易」)。

建立試算表或表格做為評量矩陣，然後在每一列各輸入一個情節， 並在每一欄各輸入一個架構性策略。 在策略和情節的交集處，輸入 1 到 4 的評比。

評比時應將下列因素納入考量：

• 開發成本：這個方案實作起來會很容易還是很困難？ 對其他領域有什麼影響？

• 操作成本：在執行階段，這個方案會輕易發揮作用，還是會降低可用性、操作效能等等？

• 風險：這個方案是否一定能完美解決情節，還是說有其他未知的成本？ 這個方案是否會降低小組未來用更好的方式來解決需求的能力？

如果策略已有建立的概念證明，請使用該概念證明中的資訊來協助您判斷要用的數值。

在表格底部，加總各情節的值。 這些數據將成為以後討論要使用哪項替代架構的基礎。

將完成的評量矩陣上載至專案入口網站。

選取架構

建立評量矩陣後，接著便會舉行審查會議來決定要在下一個反覆項目中使用的架構。 決策所參考的依據有評量矩陣以及建立概念證明時所發現的資訊。 選出架構之後，即會以參考方案的形式簽入架構的相關圖表，並且會建立一份理由文件來說明此次選擇這個架構的原因。

準備進行審查

架構設計人員和開發專案經理會識別適當的審查者來審查所提議的架構，並且將架構文件分送給每位參與者。

審查系統架構和部署架構

在審查會議上，系統圖表、部署報告和邏輯 DataCenter 圖表都會經過審查， 目的在於選擇要在下一個反覆項目中實作的架構。

會議上會考慮每個架構的評量矩陣排名來評估每個架構的合適性， 並同時考慮從概念證明發現的任何資訊，例如實作不同的架構所牽涉到的成本或複雜度。 如果邏輯 DataCenter 圖表代表無法修改的現有 DataCenter，則不需加以審查。 如果 DataCenter 正在建立中，請審查圖表以納入部署考量。 選取要使用的架構。 根據情節檢閱架構性概念，以驗證方案是否符合客戶需要且是否完整。

建立參考方案

建立說明會議決策的理由文件， 並將該文件上載至專案入口網站。 針對所選出的架構，簽入任何應用程式圖表、系統圖表或邏輯 DataCenter 圖表，做為在下一個反覆項目實作功能時的參考方案。 將已針對下一個反覆項目選出哪項架構的決策，傳達給整合小組和任何相依小組。

開發效能模型

效能模型可用來識別和解決應用程式中潛在的效能問題。 效能模型是從服務品質需求發展而來，而服務品質需求會再細分為各項開發工作。 每項開發工作都會獲派實作的效能預算。

識別已連結至效能服務品質需求的情節。 將開發工作對應至情節。 依據服務品質需求清單，判斷應用程式的工作負載。 使用工作負載估計值和服務品質需求清單，識別每個重要情節的效能目標。 這些目標包括回應時間、輸送量和資源使用率等等。 識別已編入預算來達成效能目標的效能相關資源。 執行時間和網路頻寬即為效能相關資源的一些範例。 決定每項資源的允許配置上限。

將已編入預算的資源分散給每個情節的處理步驟。 若不確定如何配置預算，請盡您所能做最好的猜測，或將資源平分給各個步驟。 在驗證期間，預算會進行重新調整。 在適當的開發工作上附加或撰寫配置。

尋找有可能會危及達成效能目標的預算配置。 考慮採用一些有助於達成效能目標的變通方式，例如設計替代項目和部署替代項目。 必要時重新評估服務品質需求。

識別不符合預算配置的情節。 測量情節的效能。 如果程式碼尚未寫好，則在初期反覆項目中使用原型。 使用在驗證期間取得的資料，視需要重複執行預算編列、評估和驗證步驟。

開發威脅模型

如需詳細資訊，請參閱 Microsoft 網站上的下列網頁：安全性開發人員中心 (英文)。