架構技術
迭代和增量方法
這是一種迭代和增量的方法，包括五個主要步驟，有助於生成候選解決方案。此候選解決方案可以透過重複這些步驟進一步完善，最終建立一個最適合我們應用程式的架構設計。在流程結束時，我們可以審查並向所有相關方傳達我們的架構。
這只是一個可能的方法。還有許多其他更正式的方法來定義、審查和傳達您的架構。
識別架構目標
識別形成架構和設計過程的架構目標。完美且明確的目標強調架構，解決設計中的正確問題，並有助於確定當前階段何時完成以及何時準備進入下一階段。
此步驟包括以下活動：
- 在開始時識別您的架構目標。
- 識別我們架構的消費者。
- 識別約束條件。
架構活動的示例包括構建原型以獲取有關 Web 應用程式訂單處理 UI 的反饋、構建客戶訂單跟蹤應用程式以及設計應用程式的身份驗證和授權架構以執行安全審查。
關鍵場景
此步驟強調設計中最重要的事情。場景是對使用者與系統互動的廣泛而全面的描述。
關鍵場景被認為是應用程式成功最重要的場景。它有助於做出有關架構的決策。目標是在使用者、業務和系統目標之間取得平衡。例如，使用者身份驗證是一個關鍵場景，因為它們是質量屬性（安全性）與重要功能（使用者如何登入您的系統）的交集。
應用程式概述
構建應用程式的概述，這使得架構更易於理解，將其與現實世界的約束和決策聯絡起來。它包括以下活動：
識別應用程式型別
識別應用程式型別，無論是移動應用程式、富客戶端、富網際網路應用程式、服務、Web 應用程式還是這些型別的某種組合。
識別部署約束
選擇合適的部署拓撲並解決應用程式和目標基礎架構之間的衝突。
識別重要的架構設計風格
識別重要的架構設計風格，例如客戶端/伺服器、分層、訊息匯流排、領域驅動設計等，以改進分割槽並透過提供針對經常出現的問題的解決方案來促進設計重用。應用程式通常會使用多種風格的組合。
識別相關技術
透過考慮我們正在開發的應用程式型別、我們首選的應用程式部署拓撲和架構風格來識別相關技術。技術的選擇還將受組織策略、基礎設施限制、資源技能等因素的指導。
關鍵問題或關鍵熱點
在設計應用程式時，熱點是錯誤最常發生的地方。根據質量屬性和跨領域問題識別關鍵問題。潛在問題包括新技術的出現和關鍵業務需求。
質量屬性是架構的整體特徵，會影響執行時行為、系統設計和使用者體驗。跨領域問題是我們設計中的特徵，可能適用於所有層、元件和層級。
這些也是最常發生高影響設計錯誤的領域。跨領域問題的示例包括身份驗證和授權、通訊、配置管理、異常管理和驗證等。
候選解決方案
在定義關鍵熱點後，構建初始基線架構或第一個高階設計，然後開始填充詳細資訊以生成候選架構。
候選架構包括應用程式型別、部署架構、架構風格、技術選擇、質量屬性和跨領域問題。如果候選架構有所改進，它可以成為建立和測試新候選架構的基線。
在迭代遵循迴圈並改進設計之前，根據已經定義的關鍵場景和需求驗證候選解決方案設計。
我們可以使用架構尖峰來發現設計的特定區域或驗證新概念。架構尖峰是一種設計原型，它確定特定設計路徑的可行性，降低風險並快速確定不同方法的可行性。針對關鍵場景和熱點測試架構尖峰。
架構審查
架構審查是最重要的任務，以便降低錯誤成本並儘早發現和修復架構問題。這是一種完善且經濟高效的方法，可以降低專案成本和專案失敗的可能性。
在主要專案里程碑以及響應其他重大架構更改時，頻繁審查架構。
架構審查的主要目標是確定基線和候選架構的可行性，從而驗證架構的正確性。
將功能需求和質量屬性與提出的技術解決方案聯絡起來。它還有助於識別問題並認識到改進的領域
基於場景的評估是審查架構設計的主要方法，它側重於從業務角度來看最重要的場景，以及對架構影響最大的場景。以下是常見的審查方法：
軟體架構分析方法 (SAAM)
它最初是為評估可修改性而設計的，但後來擴充套件到根據質量屬性審查架構。
架構權衡分析方法 (ATAM)
它是 SAAM 的一個完善和改進版本，它根據質量屬性需求審查架構決策，以及它們在多大程度上滿足特定的質量目標。
主動設計審查 (ADR)
它最適合不完整或正在進行的架構，它更側重於一次處理一組問題或架構的各個部分，而不是執行一般審查。
中間設計的主動審查 (ARID)
它結合了審查正在進行的架構的 ADR 方面以及對一組問題的關注，以及 ATAM 和 SAAM 方法中側重於質量屬性的基於場景的審查。
成本效益分析方法 (CBAM)
它側重於分析架構決策的成本、收益和時間安排影響。
架構級可修改性分析 (ALMA)
它估計業務資訊系統 (BIS) 架構的可修改性。
系列架構評估方法 (FAAM)
它估計資訊系統系列架構的互操作性和可擴充套件性。
傳達架構設計
完成架構設計後，我們必須將設計傳達給其他利益相關者，包括開發團隊、系統管理員、操作員、業務所有者和其他相關方。
以下有幾種眾所周知的向他人描述架構的方法：
4 + 1 模型
此方法使用完整架構的五個檢視。其中，四個檢視（**邏輯檢視**、**過程檢視**、**物理檢視**和**開發檢視**）從不同的角度描述了架構。第五個檢視顯示了軟體的場景和用例。它允許利益相關者檢視與他們特別相關的架構功能。
架構描述語言 (ADL)
此方法用於在系統實施之前描述軟體架構。它解決了以下問題：行為、協議和聯結器。
ADL 的主要優點是，我們可以在正式開始使用設計之前分析架構的完整性、一致性、模糊性和效能。
敏捷建模
此方法遵循“內容比表示更重要”的概念。它確保建立的模型簡單易懂、足夠準確、詳細且一致。
敏捷模型文件針對特定客戶，並滿足該客戶的工作需求。文件的簡單性確保利益相關者積極參與工件的建模。
IEEE 1471
IEEE 1471 是正式稱為 ANSI/IEEE 1471-2000 的標準的簡稱，“軟體密集型系統架構描述的推薦實踐”。IEEE 1471 增強了架構描述的內容，特別是賦予上下文、檢視和視點的特定含義。
統一建模語言 (UML)
此方法表示系統模型的三個檢視。**功能需求檢視**（從使用者角度來看系統的功能需求，包括用例）；**靜態結構檢視**（物件、屬性、關係和操作，包括類圖）；以及**動態行為檢視**（物件之間的協作以及物件內部狀態的變化，包括序列、活動和狀態圖）。