快速指南

---

---

軟體架構與設計介紹

系統的架構描述了其主要元件、它們之間的關係（結構）以及它們如何相互互動。軟體架構和設計包括幾個促成因素，例如業務戰略、質量屬性、人員動態、設計和IT環境。

我們可以將軟體架構和設計分為兩個不同的階段：軟體架構和軟體設計。在架構階段，非功能性決策被制定並與功能性需求區分開來。在設計階段，實現功能性需求。

軟體架構

架構作為系統的藍圖。它提供了一種抽象來管理系統複雜性，並在元件之間建立通訊和協調機制。

• 它定義了一個結構化的解決方案，以滿足所有技術和操作要求，同時最佳化效能和安全性等常見質量屬性。

• 此外，它還涉及一組關於與軟體開發相關的組織的重要決策，這些決策中的每一個都可能對最終產品的質量、可維護性、效能和整體成功產生相當大的影響。這些決策包括：

  • 選擇系統由其組成的結構元素及其介面。

  • 如那些元素之間協作中指定的行為。

  • 將這些結構和行為元素組合成大型子系統。

  • 架構決策與業務目標一致。

  • 架構風格指導組織。

軟體設計

軟體設計提供了一個設計方案，描述系統的元素、它們如何組合以及如何協同工作以滿足系統需求。制定設計方案的目標如下：

• 協商系統需求，並與客戶、市場和管理人員設定期望。

• 在開發過程中充當藍圖。

• 指導實施任務，包括詳細設計、編碼、整合和測試。

它位於詳細設計、編碼、整合和測試之前，領域分析、需求分析和風險分析之後。

架構的目標

架構的主要目標是識別影響應用程式結構的需求。精心設計的架構降低了構建技術解決方案相關的業務風險，並在業務需求和技術需求之間架起橋樑。

其他一些目標如下：

• 展現系統的結構，但隱藏其實現細節。

• 實現所有用例和場景。

• 嘗試滿足各種利益相關者的需求。

• 處理功能和質量需求。

• 降低所有權目標並提高組織的市場地位。

• 提高系統提供的質量和功能。

• 增強對組織或系統的外部信心。

侷限性

軟體架構仍然是軟體工程中一個新興的學科。它具有以下侷限性：

• 缺乏表示架構的工具和標準化方法。

• 缺乏分析方法來預測架構是否會導致滿足需求的實現。

• 缺乏對架構設計對軟體開發重要性的認識。

• 缺乏對軟體架構師角色的理解以及利益相關者之間的溝通不暢。

• 缺乏對設計過程、設計經驗和設計評估的理解。

軟體架構師的角色

軟體架構師提供一個技術團隊可以為整個應用程式建立和設計的解決方案。軟體架構師應該在以下領域擁有專業知識：

設計專業知識

• 軟體設計的專家，包括各種方法和途徑，例如面向物件設計、事件驅動設計等。

• 領導開發團隊並協調開發工作以確保設計的完整性。

• 能夠審查設計提案並在它們之間進行權衡。

領域專業知識

• 正在開發的系統的專家，並計劃軟體的演進。

• 協助需求調查過程，確保完整性和一致性。

• 協調正在開發的系統的領域模型的定義。

技術專業知識

• 有助於系統實現的可用技術的專家。

• 協調程式語言、框架、平臺、資料庫等的選型。

方法論專業知識

• 可能在SDLC（軟體開發生命週期）期間採用的軟體開發方法論的專家。

• 選擇適合整個團隊的適當開發方法。

軟體架構師的隱性角色

• 促進團隊成員之間的技術工作，並加強團隊中的信任關係。

• 資訊專家，分享知識並擁有豐富的經驗。

• 保護團隊成員免受會分散他們的注意力並降低專案價值的外部影響。

架構師的交付成果

• 一套清晰、完整、一致且可實現的功能目標

• 系統的功能描述，至少包含兩層分解

• 系統的概念

• 以系統形式呈現的設計，至少包含兩層分解

• 關於時間安排、操作員屬性以及實施和操作計劃的概念

• 確保遵循功能分解並控制介面形式的文件或流程

質量屬性

質量是卓越的衡量標準，或是不存在缺陷或錯誤的狀態。質量屬性是與系統功能分離的系統屬性。

實施質量屬性使得更容易區分好的系統和壞的系統。屬性是影響執行時行為、系統設計和使用者體驗的整體因素。

它們可以分類為：

靜態質量屬性

反映系統的結構和組織，直接關係到架構、設計和原始碼。它們對終端使用者是不可見的，但會影響開發和維護成本，例如：模組化、可測試性、可維護性等。

動態質量屬性

反映系統在其執行期間的行為。它們直接關係到系統的架構、設計、原始碼、配置、部署引數、環境和平臺。

它們對終端使用者可見，並在執行時存在，例如吞吐量、健壯性、可擴充套件性等。

質量場景

質量場景指定如何防止故障變成失效。根據它們的屬性規範，它們可以分為六個部分：

• 來源 - 生成激勵的內部或外部實體，例如人員、硬體、軟體或物理基礎設施。

• 激勵 - 當到達系統時需要考慮的條件。

• 環境 - 激勵在某些條件下發生。

• 工件 - 整個系統或其某些部分，例如處理器、通訊通道、永續性儲存、程序等。

• 響應 - 激勵到達後採取的活動，例如檢測故障、從故障中恢復、停用事件源等。

• 響應度量 - 應該測量發生的響應，以便可以測試需求。

常見的質量屬性

下表列出了軟體架構必須具有的常見質量屬性：

關鍵原則

軟體架構被描述為系統的組織結構，其中系統代表一組實現已定義功能的元件。

架構風格

架構風格，也稱為架構模式，是一組塑造應用程式的原則。它根據結構組織模式定義了一系列系統的抽象框架。

架構風格負責：

• 提供元件和聯結器的詞彙表，以及如何組合它們的規則。

• 改進分割槽並允許透過提供常見問題的解決方案來重用設計。

• 描述配置元件集合（具有明確定義的介面、可重用和可替換的模組）和聯結器（模組之間的通訊連結）的特定方式。

為計算機系統構建的軟體表現出多種架構風格中的一種。每種風格都描述一個包含以下內容的系統類別：

• 一組元件型別，它們執行系統所需的功能。

• 一組聯結器（子程式呼叫、遠端過程呼叫、資料流和套接字），它們能夠在不同元件之間進行通訊、協調和協作。

• 語義約束，定義如何整合元件以形成系統。

• 元件的拓撲佈局，指示其執行時相互關係。

常見架構設計

下表列出了可以按其關鍵關注領域組織的架構風格：

架構型別

從企業的角度來看，有四種類型的架構，這些架構統稱為企業架構。

• 業務架構——定義企業的業務戰略、治理、組織和關鍵業務流程，並側重於業務流程的分析和設計。

• 應用（軟體）架構——作為單個應用程式系統、它們的互動以及它們與組織業務流程之間關係的藍圖。

• 資訊架構——定義邏輯和物理資料資產以及資料管理資源。

• 資訊科技 (IT) 架構——定義構成組織整體資訊系統的硬體和軟體構建塊。

架構設計過程

架構設計過程側重於將系統分解成不同的元件及其互動，以滿足功能性和非功能性需求。軟體架構設計的關鍵輸入包括：

• 分析任務產生的需求。

• 硬體架構（軟體架構師反過來又向系統架構師提供需求，系統架構師配置硬體架構）。

架構設計過程的結果或輸出是架構描述。基本的架構設計過程由以下步驟組成：

理解問題

• 這是最重要的一步，因為它會影響後續設計的質量。

• 如果沒有對問題的清晰理解，就不可能建立一個有效的解決方案。

• 許多軟體專案和產品被認為是失敗的，因為它們實際上並沒有解決有效的業務問題或具有可識別的投資回報率 (ROI)。

識別設計元素及其關係

• 在此階段，建立一個基線來定義系統的邊界和上下文。

• 基於功能需求將系統分解成其主要元件。可以使用設計結構矩陣 (DSM) 對分解進行建模，該矩陣顯示設計元素之間的依賴關係，而不指定元素的粒度。

• 在此步驟中，透過描述許多系統例項來完成架構的第一次驗證，此步驟稱為基於功能的架構設計。

評估架構設計

• 對每個質量屬性進行估計，因此為了收集定性措施或定量資料，需要對設計進行評估。

• 它涉及評估架構是否符合架構質量屬性要求。

• 如果所有估計的質量屬性都符合所需標準，則架構設計過程完成。

• 如果不是，則進入軟體架構設計的第三階段：架構轉換。如果觀察到的質量屬性不滿足其要求，則必須建立新的設計。

轉換架構設計

• 此步驟在評估架構設計後執行。必須更改架構設計，直到它完全滿足質量屬性要求。

• 它關注於選擇設計解決方案以改進質量屬性，同時保留領域功能。

• 透過應用設計運算子、風格或模式來轉換設計。對於轉換，採用現有設計並應用設計運算子，例如分解、複製、壓縮、抽象和資源共享。

• 再次評估設計，如有必要，重複相同的過程多次，甚至遞迴執行。

• 轉換（即質量屬性最佳化解決方案）通常會改進一個或一些質量屬性，同時也會對其他屬性產生負面影響。

關鍵架構原則

以下是設計架構時需要考慮的關鍵原則：

構建以適應變化而非構建以持久

考慮應用程式如何隨著時間的推移而發生變化以應對新的需求和挑戰，並構建靈活性以支援這一點。

降低風險並進行建模以進行分析

使用設計工具、視覺化工具、建模系統（例如 UML）來捕獲需求和設計決策。還可以分析其影響。不要將模型形式化到抑制輕鬆迭代和調整設計的程度。

使用模型和視覺化作為溝通和協作工具

有效溝通設計、決策和對設計的持續更改對於良好的架構至關重要。使用模型、檢視和其他架構視覺化來有效地與所有利益相關者溝通和共享設計。這能夠快速溝通設計變更。

識別和理解關鍵的工程決策以及最常出錯的領域。投資於第一次就把關鍵決策做好，使設計更靈活，不太可能被更改破壞。

使用增量和迭代方法

從基線架構開始，然後透過迭代測試來改進架構，從而發展候選架構。在多個迭代中逐步向設計新增細節以獲得宏觀或正確的畫面，然後關注細節。

關鍵設計原則

以下是設計原則，用於最大限度地降低成本、維護需求以及最大限度地提高架構的可擴充套件性和可用性：

關注點分離

將系統的元件劃分為特定功能，以便元件功能之間沒有重疊。這將提供高內聚性和低耦合性。這種方法避免了系統元件之間的相互依賴，這有助於輕鬆維護系統。

單一責任原則

系統的每個模組都應該只有一個特定的責任，這有助於使用者清楚地理解系統。它還有助於將元件與其他元件整合。

最少知識原則

任何元件或物件都不應該瞭解其他元件的內部細節。這種方法避免了相互依賴並有助於可維護性。

儘量減少前期大型設計

如果應用程式的需求不明確，則儘量減少前期大型設計。如果有可能修改需求，則避免為整個系統進行大型設計。

不要重複功能

不要重複功能指定元件的功能不應重複，因此應僅在一個元件中實現一段程式碼。應用程式中功能的重複可能會使實施更改變得困難，降低清晰度並引入潛在的不一致性。

在重用功能時，優先選擇組合而不是繼承

繼承會在子類和父類之間建立依賴關係，因此它會阻止自由使用子類。相反，組合提供了高度的自由度並減少了繼承層次結構。

識別元件並將它們分組到邏輯層中

識別系統中滿足需求所需的元件和關注領域。然後將這些相關的元件分組到邏輯層中，這將幫助使用者在高級別上理解系統的結構。避免在同一層中混合不同型別關注點的元件。

定義層之間的通訊協議

瞭解元件如何相互通訊，這需要完全瞭解部署方案和生產環境。

定義層的數 據格式

各個元件將透過資料格式相互互動。不要混合資料格式，以便應用程式易於實現、擴充套件和維護。嘗試為一層保持相同的資料格式，以便各個元件在與彼此通訊時不需要編碼/解碼資料。它減少了處理開銷。

系統服務元件應該是抽象的

與安全、通訊或系統服務（如日誌記錄、分析和配置）相關的程式碼應在單獨的元件中進行抽象。不要將此程式碼與業務邏輯混合，因為它易於擴充套件設計並維護它。

設計異常和異常處理機制

提前定義異常有助於元件以優雅的方式管理錯誤或意外情況。異常管理將在整個系統中保持一致。

命名約定

應提前定義命名約定。它們提供了一個一致的模型，幫助使用者輕鬆理解系統。團隊成員更容易驗證其他人編寫的程式碼，從而提高可維護性。

架構模型

軟體架構涉及使用分解和組合以及架構風格和質量屬性的軟體系統抽象的高階結構。軟體架構設計必須符合系統的主要功能和效能要求，並滿足非功能性要求，例如可靠性、可擴充套件性、可移植性和可用性。

軟體架構必須描述其元件組、它們的連線、它們之間的互動以及所有元件的部署配置。

軟體架構可以用多種方式定義：

• UML（統一建模語言）——UML是軟體建模和設計中使用的一種面向物件解決方案。

• 架構檢視模型（4+1 檢視模型）——架構檢視模型表示軟體應用程式的功能和非功能需求。

• ADL（體系結構描述語言）− ADL 以形式化和語義化的方式定義軟體體系結構。

UML

UML 代表統一建模語言 (Unified Modeling Language)。它是一種圖形化語言，用於建立軟體藍圖。UML 由物件管理組織 (OMG) 建立。UML 1.0 規範草案於 1997 年 1 月提交給 OMG。它作為軟體需求分析和設計文件的標準，是開發軟體的基礎。

UML 可以被描述為一種通用的視覺化建模語言，用於視覺化、規範、構建和記錄軟體系統。雖然 UML 通常用於建模軟體系統，但它並不侷限於此。它也用於建模非軟體系統，例如製造單元中的流程。

其元素就像可以以不同方式關聯的元件，從而構成完整的 UML 圖片，稱為圖。因此，理解不同的圖以在現實系統中應用這些知識非常重要。我們有兩大類圖，它們進一步細分為子類別，即結構圖和行為圖。

結構圖

結構圖表示系統的靜態方面。這些靜態方面表示構成主要結構並因此穩定的圖表部分。

這些靜態部分由類、介面、物件、元件和節點表示。結構圖可以細分為如下幾類：

• 類圖
• 物件圖
• 元件圖
• 部署圖
• 包圖
• 組合結構圖

下表簡要描述了這些圖：

行為圖

行為圖基本上捕獲系統的動態方面。動態方面基本上是系統的變化/移動部分。UML 具有以下型別的行為圖：

• 用例圖
• 序列圖
• 通訊圖
• 狀態圖
• 活動圖
• 互動概覽圖
• 時間序列圖

下表簡要描述了這些圖：

架構檢視模型

模型是對軟體架構的完整、基本和簡化的描述，它由來自特定視角或視點的多個檢視組成。

檢視是從相關的一組關注點的角度對整個系統的表示。它用於從不同利益相關者的角度描述系統，例如終端使用者、開發人員、專案經理和測試人員。

4+1 檢視模型

4+1 檢視模型由 Philippe Kruchten 設計，用於基於使用多個併發檢視來描述軟體密集型系統的體系結構。它是一個多檢視模型，它解決了系統的不同功能和關注點。它標準化了軟體設計文件，並使所有利益相關者都易於理解設計。

這是一種用於研究和記錄軟體體系結構設計體系結構驗證方法，涵蓋了所有利益相關者的所有軟體體系結構方面。它提供了四個基本檢視：

• 邏輯檢視或概念檢視− 它描述了設計的物件模型。

• 程序檢視− 它描述了系統的活動，捕獲了設計的併發和同步方面。

• 物理檢視− 它描述了軟體到硬體的對映，並反映了其分散式方面。

• 開發檢視− 它描述了軟體在其開發環境中的靜態組織或結構。

透過新增另一個稱為場景檢視或用例檢視的檢視，可以擴充套件此檢視模型，以面向軟體系統的終端使用者或客戶。它與其他四個檢視一致，並用於說明充當“加一”檢視 (4+1) 檢視模型的體系結構。下圖使用五個併發檢視 (4+1) 模型描述了軟體體系結構。

為什麼稱為 4+1 而不是 5？

用例檢視具有特殊意義，因為它詳細說明了系統的頂級需求，而其他檢視則詳細說明了如何實現這些需求。當其他四個檢視都完成後，它實際上是冗餘的。但是，沒有它，其他所有檢視都是不可能的。下圖和表格詳細顯示了 4+1 檢視：

體系結構描述語言 (ADL)

ADL 是一種提供定義軟體體系結構的語法和語義的語言。它是一種符號規範，提供用於建模軟體系統的概念體系結構的功能，區別於系統的實現。

ADL 必須支援體系結構元件、其連線、介面和配置，這些是體系結構描述的構建塊。它是一種用於體系結構描述的表達形式，並提供分解元件、組合元件和定義元件介面的能力。

體系結構描述語言是一種形式化規範語言，它描述了軟體特性，例如程序、執行緒、資料和子程式，以及硬體元件，例如處理器、裝置、匯流排和記憶體。

很難對 ADL 和程式語言或建模語言進行分類或區分。但是，要將一種語言分類為 ADL，需要滿足以下要求：

• 它應該適合向所有相關方傳達體系結構。

• 它應該適合體系結構建立、改進和驗證的任務。

• 它應該為進一步實現提供基礎，因此它必須能夠向 ADL 規範新增資訊，以便能夠從 ADL 推匯出最終系統規範。

• 它應該能夠表示大多數常見的體系結構樣式。

• 它應該支援分析能力或提供快速生成原型實現。

面向物件正規化

面向物件 (OO) 正規化是從一種新的程式設計方法的初始概念中形成的，而對設計和分析方法的興趣則出現得較晚。OO 分析和設計正規化是廣泛採用 OO 程式語言的邏輯結果。

• 第一種面向物件的語言是Simula（真實系統的模擬），它由挪威計算中心的研究人員於 1960 年開發。

• 1970 年，Alan Kay 和他在施樂帕洛阿爾託研究中心 (Xerox PARC) 的研究小組建立了一臺名為Dynabook 的個人電腦，以及第一種純面向物件程式語言 (OOPL) - Smalltalk，用於為 Dynabook 程式設計。

• 在 20 世紀 80 年代，Grady Booch 發表了一篇題為面向物件設計的論文，該論文主要介紹了 Ada 程式語言的設計。在隨後的版本中，他將自己的想法擴充套件到完整的面向物件設計方法。

• 在 20 世紀 90 年代，Coad 將行為思想融入到面向物件方法中。

其他重要的創新包括James Rum Baugh 的物件建模技術 (OMT) 和Ivar Jacobson 的面向物件軟體工程 (OOSE)。

OO 正規化的介紹

OO 正規化是開發任何軟體的重要方法。大多數體系結構樣式或模式（例如管道和過濾器、資料儲存庫和基於元件的）都可以使用此正規化來實現。

面向物件系統的基本概念和術語：

物件

物件是面向物件環境中的一個現實世界元素，可能具有物理或概念上的存在。每個物件都有：

• 標識，它將物件與系統中的其他物件區分開來。

• 狀態，它決定物件的特性以及物件持有的屬性值。

• 行為，它表示物件根據其狀態變化執行的外部可見活動。

可以根據應用程式的需要對物件進行建模。物件可能具有物理存在，例如客戶、汽車等；或者具有無形的概念存在，例如專案、流程等。

類

類表示具有相同特徵屬性並表現出共同行為的物件集合。它提供了物件的藍圖或描述，這些物件可以從中建立。建立物件作為類的成員稱為例項化。因此，物件是類的例項。

類的組成部分是：

• 要從類例項化的物件的屬性集。通常，類的不同物件在屬性值上存在一些差異。屬性通常稱為類資料。

• 一組描述類物件行為的操作。操作也稱為函式或方法。

示例

讓我們考慮一個簡單的類 Circle，它表示二維空間中的幾何圖形圓。這個類的屬性可以識別如下：

• x-coord，表示中心的 x 座標
• y-coord，表示中心的 y 座標
• a，表示圓的半徑

它的一些操作可以定義如下：

• findArea()，計算面積的方法
• findCircumference()，計算周長的的方法
• scale()，增加或減少半徑的方法

封裝

封裝是將屬性和方法繫結到類中的過程。透過封裝，可以隱藏類的內部細節，防止外部直接訪問。它允許僅透過類提供的介面從外部訪問類的元素。

多型性

多型性最初是一個希臘詞，意思是能夠採取多種形式。在面向物件正規化中，多型性意味著根據操作所作用的例項的不同，以不同的方式使用操作。多型性允許具有不同內部結構的物件具有公共外部介面。多型性在實現繼承時特別有效。

示例

讓我們考慮兩個類 Circle 和 Square，每個類都有一個方法 findArea()。雖然這兩個類中方法的名稱和用途相同，但內部實現，即計算面積的過程，對於每個類都是不同的。當 Circle 類的物件呼叫其 findArea() 方法時，該操作會找到圓的面積，而不會與 Square 類的 findArea() 方法發生衝突。

關係

為了描述一個系統，必須提供系統的動態（行為）和靜態（邏輯）規範。動態規範描述了物件之間的關係，例如訊息傳遞。靜態規範描述了類之間的關係，例如聚合、關聯和繼承。

訊息傳遞

任何應用程式都需要許多物件以和諧的方式互動。系統中的物件可以透過訊息傳遞相互通訊。假設一個系統有兩個物件：obj1 和 obj2。如果 obj1 想要 obj2 執行其方法之一，則 obj1 向 obj2 傳送訊息。

組合或聚合

聚合或組合是類之間的一種關係，透過這種關係，一個類可以由其他類的物件的任意組合構成。它允許物件直接放置在其他類的主體中。聚合被稱為“部分-整體”或“has-a”關係，能夠從整體導航到其各個部分。聚合物件是由一個或多個其他物件組成的物件。

關聯

關聯是一組具有共同結構和共同行為的連結。關聯描述了一個或多個類的物件之間的關係。連結可以定義為關聯的例項。關聯的度表示連線中涉及的類的數量。度可以是一元、二元或三元。

• 一元關係連線同一類的物件。
• 二元關係連線兩個類的物件。
• 三元關係連線三個或更多類的物件。

繼承

這是一種機制，允許透過擴充套件和改進現有類的功能來建立新的類。現有的類稱為基類/父類/超類，新的類稱為派生類/子類/子類。

子類可以繼承或派生超類（es）的屬性和方法，前提是超類允許這樣做。此外，子類可以新增自己的屬性和方法，並可以修改任何超類方法。繼承定義了“is-a”關係。

示例

從哺乳動物類，可以派生許多類，例如人類、貓、狗、牛等。人類、貓、狗和牛都具有哺乳動物的獨特特徵。此外，每一個都有其自身的特殊特徵。可以說，牛“是-一種”哺乳動物。

面向物件分析

在軟體開發的面向物件分析階段，確定系統需求，識別類，並確認類之間的關係。面向物件分析的目的是理解應用程式領域和系統的特定需求。此階段的結果是需求規範以及對系統邏輯結構和可行性的初步分析。

三種與面向物件分析結合使用的分析技術是物件建模、動態建模和功能建模。

物件建模

物件建模以物件的形式開發軟體系統的靜態結構。它識別物件、物件可以分組到的類以及物件之間的關係。它還識別表徵每個類的主要屬性和操作。

物件建模的過程可以視覺化為以下步驟：

• 識別物件並分組到類中
• 識別類之間的關係
• 建立使用者物件模型圖
• 定義使用者物件屬性
• 定義應該對類執行的操作

動態建模

分析完系統的靜態行為後，需要檢查其相對於時間和外部變化的行為。這就是動態建模的目的。

動態建模可以定義為“描述單個物件如何響應事件的一種方法，這些事件可以是其他物件觸發的內部事件，也可以是外部世界觸發的外部事件”。

動態建模的過程可以視覺化為以下步驟：

• 識別每個物件的狀態
• 識別事件並分析動作的適用性
• 構建動態模型圖，包括狀態轉換圖
• 用物件屬性表達每個狀態
• 驗證繪製的狀態轉換圖

功能建模

功能建模是面向物件分析的最終組成部分。功能模型顯示在物件內執行的過程以及資料在方法之間移動時的變化方式。它指定物件建模的操作的含義和動態建模的動作。功能模型對應於傳統結構化分析的資料流圖。

功能建模的過程可以視覺化為以下步驟：

• 識別所有輸入和輸出
• 構建顯示功能依賴關係的資料流圖
• 說明每個功能的目的
• 識別約束
• 指定最佳化標準

面向物件設計

在分析階段之後，使用面向物件設計 (OOD) 將概念模型進一步發展成面向物件模型。在 OOD 中，分析模型中的技術無關概念被對映到實現類，識別約束，並設計介面，從而產生解決方案域的模型。面向物件設計的主要目標是開發系統的結構體系結構。

面向物件設計的階段可以識別為：

• 定義系統的上下文
• 設計系統體系結構
• 識別系統中的物件
• 構建設計模型
• 指定物件介面

面向物件設計可以分為兩個階段：概念設計和詳細設計。

概念設計

在此階段，識別構建系統所需的所有類。此外，將特定職責分配給每個類。類圖用於闡明類之間的關係，互動圖用於顯示事件流。它也稱為**高層設計**。

詳細設計

在此階段，根據它們的互動圖，將屬性和操作分配給每個類。開發狀態機圖以描述設計的更多細節。它也稱為**低層設計**。

設計原則

以下是主要的設計原則：

解耦原則

很難維護一組高度相互依賴的類組成的系統，因為在一個類中的修改可能會導致其他類的級聯更新。在面向物件設計中，可以透過引入新類或繼承來消除緊密耦合。

確保內聚性

內聚類執行一組密切相關的功能。缺乏內聚性意味著——一個類執行不相關的功能，儘管它不會影響整個系統的執行。它使整個軟體結構難以管理、擴充套件、維護和更改。

開閉原則

根據此原則，系統應該能夠擴充套件以滿足新的需求。系統擴充套件的結果不應修改系統的現有實現和程式碼。此外，必須遵循開閉原則中的以下準則：

• 對於每個具體類，必須維護單獨的介面和實現。

• 在多執行緒環境中，保持屬性私有。

• 儘量減少使用全域性變數和類變數。

資料流架構

在資料流體系結構中，整個軟體系統被視為對連續輸入資料塊或集合的一系列轉換，其中資料和操作彼此獨立。在這種方法中，資料進入系統，然後一次一個模組地流經模組，直到它們被分配到某個最終目的地（輸出或資料儲存）。

元件或模組之間的連線可以實現為 I/O 流、I/O 緩衝區、管道或其他型別的連線。資料可以在具有迴圈的圖拓撲中流動，在沒有迴圈的線性結構中流動，或者在樹型結構中流動。

這種方法的主要目標是實現可重用性和可修改性。它適用於涉及對有序定義的輸入和輸出（如編譯器和業務資料處理應用程式）進行一系列明確定義的獨立資料轉換或計算的應用程式。模組之間有三種類型的執行序列：

• 批處理順序
• 管道和過濾器或非順序流水線模式
• 過程控制

批處理順序

批處理順序是經典的資料處理模型，其中資料轉換子系統只有在其之前的子系統完全完成之後才能啟動其程序：

• 資料流將一批資料作為一個整體從一個子系統傳輸到另一個子系統。

• 模組之間的通訊是透過可以被後續子系統刪除的臨時中間檔案進行的。

• 它適用於資料批次處理的應用程式，每個子系統讀取相關的輸入檔案並寫入輸出檔案。

• 這種體系結構的典型應用程式包括業務資料處理，例如銀行和公用事業計費。

優點

• 提供對子系統的更簡單的劃分。

• 每個子系統都可以是一個獨立的程式，處理輸入資料併產生輸出資料。

缺點

• 提供高延遲和低吞吐量。

• 不提供併發和互動式介面。

• 需要外部控制才能實現。

管道過濾器架構

這種方法強調透過連續元件對資料進行增量轉換。在這種方法中，資料流由資料驅動，整個系統分解為資料來源、過濾器、管道和資料接收器元件。

模組之間的連線是資料流，這是一個先進先出的緩衝區，可以是位元組流、字元流或任何其他型別的流。這種架構的主要特點是其併發和增量執行。

過濾器

過濾器是獨立的資料流轉換器或流轉換器。它轉換輸入資料流的資料，對其進行處理，並將轉換後的資料流寫入管道，以便下一個過濾器進行處理。它以增量模式工作，一旦資料透過連線的管道到達，它就開始工作。過濾器有兩種型別：**主動過濾器**和**被動過濾器**。

主動過濾器

主動過濾器允許連線的管道拉入資料並推送轉換後的資料。它與被動管道一起操作，被動管道提供用於拉取和推送的讀/寫機制。此模式用於 UNIX 管道和過濾器機制。

被動過濾器

被動過濾器允許連線的管道推送資料並拉出資料。它與主動管道一起操作，主動管道從過濾器拉取資料並將資料推送到下一個過濾器。它必須提供讀/寫機制。

優點

• 為大量資料處理提供併發和高吞吐量。

• 提供可重用性和簡化系統維護。

• 提供可修改性和過濾器之間的低耦合。

• 透過提供任何兩個由管道連線的過濾器之間的清晰劃分來簡化。

• 透過支援順序和並行執行來提供靈活性。

缺點

• 不適合動態互動。

• 需要低公分母來傳輸ASCII格式的資料。

• 過濾器之間資料轉換的開銷。

• 沒有提供過濾器合作互動解決問題的方法。

• 難以動態配置此架構。

管道

管道是無狀態的，它們承載存在於兩個過濾器之間的二進位制或字元流。它可以將資料流從一個過濾器移動到另一個過濾器。管道使用少量上下文資訊，並且在例項化之間不保留狀態資訊。

過程控制架構

這是一種資料流架構，其中資料既不是批次順序也不是流水線流。資料流來自一組變數，這些變數控制程序的執行。它將整個系統分解成子系統或模組並連線它們。

子系統型別

過程控制架構將具有一個用於更改過程控制變數的**處理單元**和一個用於計算更改量的**控制器單元**。

控制器單元必須包含以下元素：

• **被控變數** - 被控變數為底層系統提供值，應由感測器測量。例如，巡航控制系統中的速度。

• **輸入變數** - 測量過程的輸入。例如，溫度控制系統中迴風溫度

• **操縱變數** - 操縱變數值由控制器調整或更改。

• **過程定義** - 它包括操縱某些過程變數的機制。

• **感測器** - 獲取與控制相關的過程變數的值，可以用作反饋參考來重新計算操縱變數。

• **設定點** - 這是被控變數的期望值。

• **控制演算法** - 用於決定如何操縱過程變數。

應用領域

過程控制架構適用於以下領域：

• 嵌入式系統軟體設計，系統由過程控制變數資料操縱。

• 目標是將過程輸出的指定屬性保持在給定參考值上的應用程式。

• 適用於汽車巡航控制和建築溫度控制系統。

• 即時系統軟體，用於控制汽車防抱死制動系統、核電站等。

資料中心架構

在以資料為中心的架構中，資料被集中儲存，並被其他經常修改資料的元件頻繁訪問。這種風格的主要目的是實現資料的完整性。以資料為中心的架構由透過共享資料儲存庫進行通訊的不同元件組成。這些元件訪問共享資料結構，並且相對獨立，因為它們只通過資料儲存進行互動。

以資料為中心的架構最著名的例子是資料庫架構，其中使用資料定義協議建立公共資料庫模式——例如，關係資料庫管理系統 (RDBMS) 中的一組相關的表，包含欄位和資料型別。

以資料為中心的架構的另一個例子是 Web 架構，它具有公共資料模式（即 Web 的元結構）並遵循超媒體資料模型，並且程序透過使用共享的基於 Web 的資料服務進行通訊。

元件型別

元件有兩種型別：

• **中心資料**結構或資料儲存或資料儲存庫，負責提供永久性資料儲存。它代表當前狀態。

• **資料訪問器**或一系列獨立的元件，它們對中心資料儲存進行操作，執行計算，並可能將結果放回。

資料訪問器之間的互動或通訊僅透過資料儲存進行。資料是客戶端之間唯一的一種通訊方式。控制流將架構分為兩類：

• 儲存庫架構風格
• 黑板架構風格

儲存庫架構風格

在儲存庫架構風格中，資料儲存是被動的，而資料儲存的客戶端（軟體元件或代理）是主動的，它們控制邏輯流。參與的元件檢查資料儲存以查詢更改。

• 客戶端向系統傳送請求以執行操作（例如插入資料）。

• 計算過程是獨立的，並由傳入請求觸發。

• 如果事務輸入流中的事務型別觸發要執行的過程的選擇，則它是傳統的資料庫或儲存庫架構，或被動儲存庫。

• 這種方法廣泛應用於 DBMS、圖書館資訊系統、CORBA 中的介面儲存庫、編譯器和 CASE（計算機輔助軟體工程）環境。

優點

• 提供資料完整性、備份和還原功能。

• 提供可擴充套件性和代理的可重用性，因為它們之間沒有直接通訊。

• 減少了軟體元件之間瞬態資料的開銷。

缺點

• 它更容易發生故障，並且可能發生資料複製或重複。

• 資料儲存的資料結構及其代理之間存在高度依賴性。

• 資料結構的變化會極大地影響客戶端。

• 資料的演變是困難和昂貴的。

• 在網路上移動分散式資料的成本。

黑板架構風格

在黑板架構風格中，資料儲存是主動的，而其客戶端是被動的。因此，邏輯流由資料儲存中的當前資料狀態決定。它有一個黑板元件，充當中心資料儲存庫，並且不同的計算元素構建並作用於內部表示。

• 儲存在黑板中的許多元件獨立地作用於公共資料結構。

• 在這種風格中，元件只通過黑板進行互動。只要資料儲存發生變化，資料儲存就會向客戶端發出警報。

• 解決方案的當前狀態儲存在黑板中，處理由黑板的狀態觸發。

• 當資料發生變化時，系統會向客戶端傳送稱為**觸發器**和資料的通知。

• 這種方法存在於某些 AI 應用程式和複雜應用程式中，例如語音識別、影像識別、安全系統和業務資源管理系統等。

• 如果中心資料結構的當前狀態是選擇要執行過程的主要觸發器，則儲存庫可以是黑板，並且此共享資料來源是一個主動代理。

• 與傳統資料庫系統的一個主要區別在於，黑板架構中計算元素的呼叫是由黑板的當前狀態觸發的，而不是由外部輸入觸發的。

黑板模型的組成部分

黑板模型通常包含三個主要部分：

知識源 (KS)

知識源，也稱為**偵聽器**或**訂閱者**，是不同且獨立的單元。它們解決問題的部分並聚合部分結果。知識源之間的互動唯一地透過黑板進行。

黑板資料結構

問題解決狀態資料被組織成一個依賴於應用程式的層次結構。知識源對黑板進行更改，這些更改逐漸導致問題的解決。

控制

控制管理任務並檢查工作狀態。

優點

• 提供可擴充套件性，可以輕鬆新增或更新知識源。

• 提供併發性，允許所有知識源並行工作，因為它們彼此獨立。

• 支援假設的實驗。

• 支援知識源代理的可重用性。

缺點

• 黑板的結構變化可能會對其所有代理產生重大影響，因為黑板和知識源之間存在緊密依賴關係。

• 很難決定何時終止推理，因為只期望得到近似解。

• 多個代理同步的問題。

• 系統設計和測試中的主要挑戰。

層次式架構

層次架構將整個系統視為層次結構，其中軟體系統在層次結構中不同級別分解成邏輯模組或子系統。這種方法通常用於設計系統軟體，例如網路協議和作業系統。

在系統軟體層次結構設計中，低階子系統為其相鄰的上級子系統提供服務，上級子系統呼叫低階子系統中的方法。較低層提供更具體的函式，例如 I/O 服務、事務、排程、安全服務等。中間層提供更多與領域相關的函式，例如業務邏輯和核心處理服務。並且，上層以使用者介面的形式提供更抽象的功能，例如 GUI、shell 程式設計工具等。

它也用於組織類庫，例如名稱空間層次結構中的 .NET 類庫。所有設計型別都可以實現這種層次架構，並且經常與其他架構風格結合使用。

層次架構風格分為：

• 主-子程式
• 主-從
• 虛擬機器

主-子程式

這種風格的目標是重用模組並自由開發單個模組或子程式。在這種風格中，軟體系統透過使用自頂向下的細化根據系統的所需功能劃分為子程式。

這些細化垂直進行，直到分解的模組足夠簡單，以至於具有其獨有的獨立責任。功能可以被上層中的多個呼叫者重用和共享。

資料作為引數傳遞給子程式有兩種方法：

• **按值傳遞** - 子程式只使用過去的資料，但不能修改它。

• **按引用傳遞** - 子程式使用並更改引數引用的資料的值。

優點

• 易於根據層次細化分解系統。

• 可用於面向物件設計中的子系統。

缺點

• 容易受到攻擊，因為它包含全域性共享資料。

• 緊密耦合可能會導致更多變化的連鎖反應。

主-從

這種方法應用了“分而治之”的原則，並支援錯誤計算和計算精度。它是主子程式架構的修改，它提供了系統的可靠性和容錯能力。

在此架構中，從屬節點為主節點提供重複的服務，主節點透過某種選擇策略在從屬節點中選擇特定結果。從屬節點可以透過不同的演算法和方法執行相同的函式任務，或者執行完全不同的功能。它包括平行計算，其中所有從屬節點都可以並行執行。

主從模式的實現遵循五個步驟：

• 指定如何將任務的計算劃分為一組相等的子任務，並確定處理子任務所需的子服務。

• 指定如何藉助於處理單個子任務獲得的結果來計算整個服務的最終結果。

• 為步驟1中標識的子服務定義一個介面。它將由從屬節點實現，並由主節點用於委託處理單個子任務。

• 根據上一步中制定的規範實現從屬元件。

• 根據步驟1到3中制定的規範實現主節點。

應用

• 適用於軟體可靠性至關重要的應用。

• 廣泛應用於並行和分散式計算領域。

優點

• 計算速度更快，易於擴充套件。

• 提供魯棒性，因為從屬節點可以被複制。

• 可以以不同的方式實現從屬節點，以最大限度地減少語義錯誤。

缺點

• 通訊開銷。

• 並非所有問題都可以劃分。

• 難以實現且存在可移植性問題。

虛擬機器架構

虛擬機器架構模擬某些功能，這些功能並非其所執行的硬體和/或軟體所固有的。虛擬機器建立在現有系統之上，並提供虛擬抽象、一組屬性和操作。

在虛擬機器架構中，主節點使用來自從屬節點的“相同”子服務，並執行諸如分割工作、呼叫從屬節點和組合結果等功能。它允許開發人員模擬和測試尚未構建的平臺，以及模擬在真實系統上測試起來過於複雜、昂貴或危險的“災難”模式。

在大多數情況下，虛擬機器將程式語言或應用程式環境與執行平臺分離。主要目標是提供**可移植性**。透過虛擬機器解釋特定模組可以理解為：

• 解釋引擎從正在解釋的模組中選擇一條指令。

• 根據指令，引擎更新虛擬機器的內部狀態，並重覆上述過程。

下圖顯示了單臺物理機上標準虛擬機器基礎架構的架構。

**管理程式**，也稱為**虛擬機器監視器**，執行在主機作業系統上，併為每個客戶作業系統分配匹配的資源。當客戶機進行系統呼叫時，管理程式會攔截並將其轉換為主機作業系統支援的相應系統呼叫。管理程式控制每個虛擬機器對CPU、記憶體、永續性儲存、I/O裝置和網路的訪問。

應用

虛擬機器架構適用於以下領域：

• 如果不存在直接解決方案，則適用於透過模擬或轉換來解決問題。

• 示例應用程式包括微程式直譯器、XML處理、指令碼命令語言執行、基於規則的系統執行、Smalltalk和Java直譯器型別程式語言。

• 虛擬機器的常見示例包括直譯器、基於規則的系統、語法外殼和命令語言處理器。

優點

• 可移植性和機器平臺無關性。

• 軟體開發的簡易性。

• 透過中斷和查詢程式的能力提供靈活性。

• 災難工作模型的模擬。

• 在執行時引入修改。

缺點

• 由於直譯器的性質，直譯器的執行速度較慢。

• 由於執行中涉及的額外計算，存在效能成本。

分層樣式

在這種方法中，系統被分解成層次結構中多個更高和更低的層，並且每一層在系統中都有其唯一的職責。

• 每一層由一組相關的類組成，這些類封裝在包中、部署的元件中，或者作為方法庫或標頭檔案的形式的一組子例程。

• 每一層都為其上層的提供服務，並作為其下層的客戶端，即對i+1層的請求透過i層的介面呼叫i層提供的服務。如果任務完成，響應可能會返回到i+1層；否則，i層會持續呼叫下面i-1層的服務。

應用

分層樣式適用於以下領域：

• 涉及可以分層組織的不同類別的服務的應用程式。

• 任何可以分解為特定於應用程式和特定於平臺的部分的應用程式。

• 在核心服務、關鍵服務和使用者介面服務等之間有明確區分的應用程式。

優點

• 基於增量抽象級別的設計。

• 提供增強獨立性，因為對一層功能的更改最多會影響另外兩層。

• 標準介面及其實現的分離。

• 透過使用基於元件的技術實現，這使得系統更容易允許即插即用新元件。

• 每一層都可以作為一個獨立部署的抽象機，支援可移植性。

• 易於根據自頂向下細化方式的任務定義來分解系統

• 同一層的不同實現（具有相同的介面）可以互換使用

缺點

• 許多應用程式或系統不容易以分層方式構建。

• 較低的執行時效能，因為客戶端的請求或對客戶端的響應必須經過多個層。

• 每一層的資料編組和緩衝也存在效能開銷問題。

• 開啟層間通訊可能會導致死鎖，“橋接”可能會導致緊密耦合。

• 異常和錯誤處理是分層體系結構中的一個問題，因為一層中的故障必須向上傳播到所有呼叫層

互動式架構

面向互動的架構的主要目標是將使用者的互動與資料抽象和業務資料處理分離。面向互動的軟體架構將系統分解為三個主要部分：

• **資料模組** - 資料模組提供資料抽象和所有業務邏輯。

• **控制模組** - 控制模組標識控制流和系統配置操作。

• **視圖表示模組** - 視圖表示模組負責資料輸出的視覺或音訊表示，它還提供使用者輸入的介面。

面向互動的架構有兩種主要樣式：**模型-檢視-控制器** (MVC) 和**表示-抽象-控制** (PAC)。MVC 和 PAC 都提出三元件分解，並用於互動式應用程式，例如具有多個對話和使用者互動的 Web 應用程式。它們在控制流和組織方面有所不同。PAC 是基於代理的分層架構，但 MVC 沒有清晰的分層結構。

模型-檢視-控制器 (MVC)

MVC 將給定的軟體應用程式分解為三個相互關聯的部分，這些部分有助於將資訊的內部表示與向用戶呈現或從使用者接受的資訊分離。

模型

模型是 MVC 的核心元件，直接管理應用程式的資料、邏輯和約束。它由資料元件組成，這些元件維護原始應用程式資料和應用程式邏輯介面。

• 它是一個獨立的使用者介面，捕獲應用程式問題領域的特性。

• 它是應用程式核心結構的特定於領域的軟體模擬或實現。

• 當其狀態發生變化時，它會向其關聯的檢視發出通知以生成更新的輸出，並向控制器發出通知以更改可用命令集。

檢視

檢視可以用於以圖形形式（例如圖表或圖表）表示資訊的任何輸出。它由表示元件組成，這些元件提供資料的視覺表示

• 檢視向其模型請求資訊並生成對使用者的輸出表示。

• 同一資訊的多個檢視是可能的，例如管理人員的條形圖和會計人員的表格檢視。

控制器

控制器接受輸入並將其轉換為模型或檢視的命令。它由輸入處理元件組成，這些元件透過修改模型來處理來自使用者的輸入。

• 它充當關聯模型和檢視與輸入裝置之間的介面。

• 它可以向模型傳送命令以更新模型的狀態，並向其關聯的檢視傳送命令以更改檢視對模型的表示。

MVC - I

這是 MVC 架構的一個簡單版本，其中系統分為兩個子系統：

• **控制器-檢視** - 控制器-檢視充當輸入/輸出介面並進行處理。

• **模型** - 模型提供所有資料和領域服務。

MVC-I 架構

模型模組會通知控制器-檢視模組任何資料更改，以便相應地更改任何圖形資料顯示。控制器也會根據這些更改採取適當的行動。

控制器-檢視和模型之間的連線可以設計成訂閱-通知模式（如上圖所示），其中控制器-檢視訂閱模型，模型會通知控制器-檢視任何更改。

MVC - II

MVC-II 是 MVC-I 架構的增強版本，其中檢視模組和控制器模組是分開的。模型模組像在 MVC-I 中一樣發揮積極作用，提供資料庫支援的所有核心功能和資料。

檢視模組呈現資料，而控制器模組接受輸入請求，驗證輸入資料，啟動模型、檢視、它們的連線，並排程任務。

MVC-II 架構

MVC 應用

MVC 應用程式對於需要為單個數據模型提供多個檢視的互動式應用程式非常有效，並且易於插入新的或更改介面檢視。

MVC 應用程式適用於模組之間有明確劃分的情況，以便可以將不同的專業人員分配到此類應用程式的不同方面同時工作。

優點

• 有許多可用的 MVC 供應商框架工具包。

• 多個檢視與相同的資料模型同步。

• 易於插入新的或替換介面檢視。

• 用於應用程式開發，其中圖形專家專業人員、程式設計專業人員和資料庫開發專業人員在一個設計的專案團隊中工作。

缺點

• 不適用於面向代理的應用程式，例如互動式移動和機器人應用程式。

• 基於相同資料模型的多個控制器和檢視對會導致任何資料模型更改都代價高昂。

• 在某些情況下，檢視和控制器之間的劃分並不清晰。

表現-抽象-控制 (PAC)

在PAC中，系統被組織成許多協作代理（三元組）的層次結構。它是在MVC的基礎上發展而來的，以支援除了互動式需求之外的多個代理的應用需求。

每個代理具有三個元件：

• 表現元件 - 格式化資料的視覺和音訊表現。

• 抽象元件 - 檢索和處理資料。

• 控制組件 - 處理諸如控制流和兩個元件之間通訊的任務。

PAC架構與MVC類似，表現模組類似於MVC的檢視模組。抽象模組類似於MVC的模型模組，控制模組類似於MVC的控制器模組，但它們在控制流和組織方面有所不同。

在每個代理中，抽象元件和表現元件之間沒有直接連線。每個代理中的控制組件負責與其他代理的通訊。

下圖顯示了PAC設計中單個代理的框圖。（此處應插入圖片）

具有多個代理的PAC

在由多個代理組成的PAC中，頂級代理提供核心資料和業務邏輯。底層代理定義詳細的特定資料和表現。中間層代理充當底層代理的協調器。

• 每個代理都有其自身指定的特定任務。

• 對於某些中間層代理，不需要互動式表現，因此它們沒有表現元件。

• 所有代理都需要控制組件，所有代理都透過它相互通訊。

下圖顯示了參與PAC的多個代理。（此處應插入圖片）

應用

• 對於可以以分層方式分解成許多協作代理的互動式系統有效。

• 當代理之間的耦合預期較鬆散時有效，以便對一個代理的更改不會影響其他代理。

• 對於分散式系統有效，其中所有代理都遠端分佈，並且每個代理都具有其自身的功能、資料和互動介面。

• 適用於具有豐富的GUI元件的應用程式，其中每個元件都保留其自身當前資料和互動介面，並且需要與其他元件通訊。

優點

• 支援多工和多檢視

• 支援代理的可重用性和可擴充套件性

• 易於插入新代理或更改現有代理

• 支援併發，其中多個代理可以在不同的執行緒、不同的裝置或不同的計算機上並行執行

缺點

• 由於表現和抽象之間的控制橋樑以及代理之間控制的通訊而導致的開銷。

• 由於代理之間耦合鬆散且高度獨立，因此難以確定正確的代理數量。

• 每個代理中控制對錶現和抽象的完全分離會產生開發複雜性，因為代理之間的通訊僅發生在代理的控制之間。

分散式架構

在分散式架構中，元件在不同的平臺上呈現，並且多個元件可以透過通訊網路相互協作以實現特定的目標或目的。

• 在這種架構中，資訊處理不僅限於單臺機器，而是分佈在多臺獨立計算機上。

• 客戶端-伺服器架構可以作為分散式系統的示例，它構成了多層架構的基礎；替代方案是經紀人架構，例如CORBA和麵向服務的架構(SOA)。

• 有幾個技術框架支援分散式架構，包括.NET、J2EE、CORBA、.NET Web服務、AXIS Java Web服務和Globus Grid服務。

• 中介軟體是適當地支援分散式應用程式的開發和執行的基礎設施。它在應用程式和網路之間提供緩衝。

• 它位於系統的中間，管理或支援分散式系統的不同元件。例如事務處理監控器、資料轉換器和通訊控制器等。

作為分散式系統基礎設施的中介軟體

分散式架構的基礎是其透明性、可靠性和可用性。

下表列出了分散式系統中不同形式的透明性：

優點

• 資源共享 - 共享硬體和軟體資源。

• 開放性 - 使用不同供應商的硬體和軟體的靈活性。

• 併發性 - 併發處理以提高效能。

• 可擴充套件性 - 透過新增新資源來增加吞吐量。

• 容錯性 - 發生故障後繼續執行的能力。

缺點

• 複雜性 - 比集中式系統更復雜。

• 安全性 - 更容易受到外部攻擊。

• 可管理性 - 需要更多系統管理工作。

• 不可預測性 - 響應不可預測，取決於系統組織和網路負載。

集中式系統與分散式系統

客戶端-伺服器架構

客戶端-伺服器架構是最常見的分散式系統架構，它將系統分解成兩個主要的子系統或邏輯程序：

• 客戶端 - 這是第一個向第二個程序（即伺服器）發出請求的程序。

• 伺服器 - 這是第二個程序，它接收請求，執行請求並向客戶端傳送回覆。

在此架構中，應用程式被建模為由伺服器提供的一組服務和使用這些服務的一組客戶端。伺服器不需要了解客戶端，但客戶端必須知道伺服器的身份，並且處理器到程序的對映不一定是1:1。

基於客戶端的功能，客戶端-伺服器架構可以分為兩種模型：

瘦客戶端模型

在瘦客戶端模型中，所有應用程式處理和資料管理都由伺服器承擔。客戶端只需負責執行演示軟體。

• 當遺留系統遷移到客戶端伺服器架構時使用，其中遺留系統本身充當伺服器，並在客戶端上實現圖形介面。

• 一個主要缺點是它給伺服器和網路帶來了沉重的處理負載。

厚/胖客戶端模型

在厚客戶端模型中，伺服器僅負責資料管理。客戶端上的軟體實現應用程式邏輯和與系統使用者的互動。

• 最適合新的C/S系統，其中客戶端系統的能力是預先知道的。

• 比瘦客戶端模型更復雜，尤其是在管理方面。必須在所有客戶端上安裝新版本的應用程式。

優點

• 責任分離，例如使用者介面呈現和業務邏輯處理。

• 伺服器元件的可重用性和併發潛力

• 簡化了分散式應用程式的設計和開發

• 它使將現有應用程式遷移或整合到分散式環境中變得容易。

• 當大量客戶端訪問高效能伺服器時，它也能有效地利用資源。

缺點

• 缺乏處理需求變化的異構基礎設施。

• 安全問題。

• 伺服器可用性和可靠性有限。

• 可測試性和可擴充套件性有限。

• 胖客戶端同時擁有表現和業務邏輯。

多層架構（n層架構）

多層架構是一種客戶端-伺服器架構，其中諸如表現、應用程式處理和資料管理之類的功能在物理上是分開的。透過將應用程式分成幾層，開發人員可以選擇更改或新增特定層，而不是重新設計整個應用程式。它提供了一個模型，開發人員可以使用它來建立靈活且可重用的應用程式。

多層架構最常見的用途是三層架構。三層架構通常由表現層、應用程式層和資料儲存層組成，並且可以在單獨的處理器上執行。

表現層

表現層是應用程式的頂層，使用者可以直接訪問，例如網頁或作業系統GUI（圖形使用者介面）。此層的首要功能是將任務和結果轉換為使用者可以理解的內容。它與其他層通訊，以便將結果放置到瀏覽器/客戶端層和網路中的所有其他層。

應用層（業務邏輯、邏輯層或中間層）

應用層協調應用程式，處理命令，做出邏輯決策，評估和執行計算。它透過執行詳細的處理來控制應用程式的功能。它還移動和處理兩個周圍層之間的資料。

資料層

在此層中，資訊從資料庫或檔案系統中儲存和檢索。然後將資訊傳遞迴進行處理，然後再傳遞迴使用者。它包括資料永續性機制（資料庫伺服器、檔案共享等），併為應用程式層提供API（應用程式程式設計介面），該介面提供管理儲存資料的方法。

優點

• 比瘦客戶端方法效能更好，比厚客戶端方法更易於管理。

• 增強了可重用性和可擴充套件性 - 隨著需求的增加，可以新增額外的伺服器。

• 提供多執行緒支援，並減少網路流量。

• 提供可維護性和靈活性

缺點

• 由於缺乏測試工具，可測試性不令人滿意。

• 伺服器可靠性和可用性更為關鍵。

代理架構風格

代理架構樣式是一種在分散式計算中使用的中介軟體架構，用於協調和啟用已註冊伺服器和客戶端之間的通訊。在此，物件通訊透過稱為物件請求代理（軟體匯流排）的中介軟體系統進行。

• 客戶端和伺服器不會直接相互互動。客戶端和伺服器與其代理有直接連線，該代理與中介代理通訊。

• 伺服器透過向代理註冊和釋出其介面來提供服務，客戶端可以透過查詢靜態或動態地向代理請求服務。

• CORBA（公共物件請求代理體系結構）是代理架構的一個很好的實現示例。

代理架構樣式的元件

代理架構樣式的元件透過以下標題討論：

代理（Broker）

代理負責協調通訊，例如轉發和排程結果和異常。它可以是面向呼叫的服務，也可以是面向文件或訊息的代理，客戶端向其傳送訊息。

• 它負責代理服務請求，定位合適的伺服器，傳輸請求並將響應傳送回客戶端。

• 它保留伺服器的註冊資訊，包括其功能和服務以及位置資訊。

• 它為客戶端提供請求API、伺服器提供響應API、註冊或登出伺服器元件API、傳輸訊息API和查詢伺服器API。

存根（Stub）

存根在靜態編譯時生成，然後部署到客戶端，用作客戶端的代理。客戶端代理充當客戶端和代理之間的中介，並在它們和客戶端之間提供額外的透明性；遠端物件看起來像本地物件。

代理隱藏協議級別的IPC（程序間通訊），並執行引數值的封送和伺服器結果的解封送。

骨架（Skeleton）

骨架由服務介面編譯生成，然後部署到伺服器端，用作伺服器的代理。伺服器端代理封裝低階系統特定網路功能，並提供高階 API 來協調伺服器和代理之間的通訊。

它接收請求，解包請求，解組方法引數，呼叫合適的服務，並在將結果傳送回客戶端之前進行封送。

橋接器（Bridge）

橋接器可以連線基於不同通訊協議的兩個不同的網路。它協調不同的代理，包括 DCOM、.NET 遠端和 Java CORBA 代理。

橋接器是可選元件，當兩個代理互操作時，它隱藏實現細節，並以一種格式接收請求和引數，並將它們轉換為另一種格式。

CORBA 中的代理實現

CORBA 是物件請求代理的國際標準——一種中介軟體，用於管理由 OMG（物件管理組）定義的分散式物件之間的通訊。

面向服務的架構 (SOA)

服務是業務功能的一個元件，它定義明確、自包含、獨立、已釋出，並且可以透過標準程式設計介面使用。服務之間的連線由通用且通用的面向訊息的協議（例如 SOAP Web 服務協議）進行，該協議可以在服務之間鬆散地傳遞請求和響應。

面向服務的架構是一種客戶端/伺服器設計，它支援業務驅動的 IT 方法，其中應用程式由軟體服務和軟體服務使用者（也稱為客戶端或服務請求者）組成。

SOA 的特性

面向服務的架構提供以下特性：

• **分散式部署** - 將企業資料和業務邏輯作為鬆散耦合、可發現、結構化、基於標準、粗粒度、無狀態的功能單元（稱為服務）公開。

• **可組合性** - 從現有服務組裝新流程，這些服務透過定義明確、已釋出且符合標準的介面以所需的粒度公開。

• **互操作性** - 無論底層協議或實現技術如何，都能在網路上共享功能並重用共享服務。

• **可重用性** - 選擇服務提供商並訪問公開為服務的現有資源。

SOA 操作

下圖說明了 SOA 如何運作：

優點

• 服務導向的鬆散耦合為企業提供了極大的靈活性，可以利用所有可用的服務資源，而無需考慮平臺和技術限制。

• 由於無狀態服務特性，每個服務元件都獨立於其他服務。

• 只要公開的介面不變，服務的實現就不會影響服務的應用。

• 客戶端或任何服務都可以訪問其他服務，而不管它們的平臺、技術、供應商或語言實現如何。

• 資產和服務的可重用性，因為服務的客戶端只需要知道其公共介面，服務組合。

• 基於 SOA 的業務應用程式開發在時間和成本方面效率更高。

• 增強可擴充套件性並提供系統之間的標準連線。

• 高效有效地使用“業務服務”。

• 整合變得更容易，並且內在互操作性得到改善。

• 為開發人員抽象複雜性，並將業務流程更貼近終端使用者。

基於元件的架構

元件化架構側重於將設計分解成表示定義明確的通訊介面的獨立功能或邏輯元件，這些介面包含方法、事件和屬性。它提供更高層次的抽象，並將問題分解成子問題，每個子問題都與元件分割槽相關聯。

元件化架構的主要目標是確保**元件的可重用性**。元件將軟體元素的功能和行為封裝到可重用且可獨立部署的二進位制單元中。有許多標準的元件框架，例如 COM/DCOM、JavaBean、EJB、CORBA、.NET、Web 服務和網格服務。這些技術廣泛用於本地桌面 GUI 應用程式設計，例如圖形 JavaBean 元件、MS ActiveX 元件和 COM 元件，只需簡單的拖放操作即可重用。

與傳統的面向物件方法相比，面向元件的軟體設計具有許多優點，例如：

• 透過重用現有元件縮短上市時間和開發成本。

• 透過重用現有元件提高可靠性。

什麼是元件？

元件是一組模組化、可移植、可替換和可重用的定義明確的功能，它封裝其實現並將其匯出為更高級別的介面。

元件是一個軟體物件，旨在與其他元件互動，封裝某些功能或一組功能。它具有明顯定義的介面，並符合架構內所有元件共有的推薦行為。

軟體元件可以定義為具有合同指定的介面和顯式上下文依賴項的組合單元。也就是說，軟體元件可以獨立部署，並受第三方的組合。

元件的檢視

元件可以具有三種不同的檢視：面向物件的檢視、傳統檢視和與流程相關的檢視。

面向物件的檢視

元件被視為一組一個或多個協作類。解釋每個問題領域類（分析）和基礎結構類（設計），以識別適用於其實現的所有屬性和操作。它還涉及定義允許類進行通訊和協作的介面。

傳統檢視

它被視為程式的功能元素或模組，該模組集成了處理邏輯、實現處理邏輯所需的內部資料結構以及允許呼叫元件並將資料傳遞給它的介面。

與流程相關的檢視

在這個檢視中，系統不是從頭開始建立每個元件，而是從庫中維護的現有元件構建。在制定軟體架構時，從庫中選擇元件並用於填充架構。

• 使用者介面 (UI) 元件包括網格、按鈕（稱為控制元件）和實用程式元件，它們公開在其他元件中使用的特定功能子集。

• 其他常見的元件型別是那些資源密集型、不經常訪問且必須使用即時 (JIT) 方法啟用的元件。

• 許多元件是不可見的，它們分佈在企業業務應用程式和網際網路 Web 應用程式中，例如 Enterprise JavaBean (EJB)、.NET 元件和 CORBA 元件。

元件的特性

• **可重用性** - 元件通常設計為在不同情況下在不同的應用程式中重用。但是，某些元件可能設計用於特定任務。

• **可替換性** - 元件可以自由地用其他類似元件替換。

• **非上下文特定** - 元件設計為可在不同的環境和上下文中執行。

• **可擴充套件性** - 可以從現有元件擴充套件元件以提供新行為。

• **封裝性** - 元件描述介面，允許呼叫者使用其功能，並且不公開內部流程或任何內部變數或狀態的細節。

• **獨立性** - 元件設計為對其他元件的依賴性最小。

基於元件的設計原則

可以使用一些中間表示（例如圖形、表格或文字）來表示元件級設計，該表示可以轉換為原始碼。資料結構、介面和演算法的設計應符合完善的指南，以幫助我們避免引入錯誤。

• 軟體系統分解成可重用、內聚和封裝的元件單元。

• 每個元件都有自己的介面，該介面指定所需的埠和提供的埠；每個元件都隱藏其詳細的實現。

• 應該擴充套件元件而無需對元件的現有部分進行內部程式碼或設計修改。

• 依賴於抽象元件不依賴於其他具體元件，這增加了擴充套件的難度。

• 聯結器連線元件，指定和管理元件之間的互動。互動型別由元件的介面指定。

• 元件互動可以採用方法呼叫、非同步呼叫、廣播、訊息驅動互動、資料流通訊和其他協議特定互動的形式。

• 對於伺服器類，應建立專門的介面來服務主要類別的客戶端。只有與特定類別客戶端相關的操作才應在介面中指定。

• 元件可以擴充套件到其他元件，並且仍然提供自己的擴充套件點。這是基於外掛的架構的概念。這允許外掛提供另一個外掛 API。

元件級設計指南

建立元件的命名約定，這些約定指定為架構模型的一部分，然後在元件級模型中進行細化或詳細說明。

• 從問題域獲取架構元件名稱，並確保它們對檢視架構模型的所有利益相關者都有意義。

• 提取可以獨立存在且與其他實體沒有任何關聯依賴關係的業務流程實體。

• 識別並發現這些獨立實體作為新元件。

• 使用反映其特定於實現的含義的基礎結構元件名稱。

• 將任何依賴項從左到右建模，並將繼承從頂部（基類）到底部（派生類）建模。

• 將任何元件依賴項建模為介面，而不是將其表示為直接的元件到元件依賴項。

進行元件級設計

識別分析模型和架構模型中定義的問題域中對應的所有設計類。

• 識別所有對應於基礎設施域的設計類。

• 描述所有未作為可重用元件獲取的設計類，並指定訊息詳細資訊。

• 為每個元件識別合適的介面，並詳細說明實現這些介面所需的屬性、資料型別和資料結構。

• 透過虛擬碼或UML活動圖詳細描述每個操作中的處理流程。

• 描述永續性資料來源（資料庫和檔案），並識別管理它們所需的類。

• 開發和詳細說明類或元件的行為表示。這可以透過詳細說明為分析模型建立的UML狀態圖，並檢查與設計類相關的所有用例來完成。

• 詳細說明部署圖以提供額外的實現細節。

• 使用類例項並指定特定的硬體和作業系統環境，演示系統中關鍵包或元件類的位置。

• 最終決策可以使用既定的設計原則和指南做出。經驗豐富的設計人員會在確定最終設計模型之前考慮所有（或大多數）替代設計方案。

優點

• 易於部署 - 隨著新相容版本的可用，更容易替換現有版本，而不會影響其他元件或整個系統。

• 降低成本 - 使用第三方元件允許您分攤開發和維護成本。

• 易於開發 - 元件實現眾所周知的介面以提供定義的功能，允許開發而不會影響系統的其他部分。

• 可重用 - 可重用元件的使用意味著它們可以用於在多個應用程式或系統中分攤開發和維護成本。

• 技術複雜性的修改 - 元件透過使用元件容器及其服務來修改複雜性。

• 可靠性 - 由於每個元件的可靠性都透過重用提高了整個系統的可靠性，因此整體系統可靠性提高了。

• 系統維護和演進 - 易於更改和更新實現，而不會影響系統的其餘部分。

• 獨立性 - 元件的獨立性和靈活的連線性。不同小組並行獨立開發元件。提高軟體開發和未來軟體開發的效率。

使用者介面

從使用者的角度來看，使用者介面是軟體系統的第一印象。因此，任何軟體系統都必須滿足使用者的需求。UI主要執行兩個功能：

• 接收使用者的輸入

• 顯示輸出

使用者介面在任何軟體系統中都起著至關重要的作用。它可能是軟體系統唯一可見的方面，因為：

• 使用者將首先看到軟體系統外部使用者介面的架構，而不考慮其內部架構。

• 良好的使用者介面必須吸引使用者使用軟體系統，避免錯誤。它應該幫助使用者輕鬆理解軟體系統，而不會提供誤導性資訊。糟糕的UI可能會導致市場失敗，無法與競爭對手的軟體系統競爭。

• UI具有其語法和語義。語法包括文字、圖示、按鈕等元件型別，而可用性總結了UI的語義。UI的質量由其外觀和感覺（語法）及其可用性（語義）來表徵。

• 使用者介面主要有兩種：a) 文字式 b) 圖形式。

• 不同領域的軟體可能需要不同風格的使用者介面，例如，計算器只需要很小的區域來顯示數字，但需要很大的區域來顯示命令，網頁需要表單、連結、選項卡等。

圖形使用者介面

圖形使用者介面是當今最常見的使用者介面型別。它非常使用者友好，因為它使用了圖片、圖形和圖示——這就是它被稱為“圖形”的原因。

它也被稱為WIMP介面，因為它使用了：

• Windows（視窗） - 螢幕上顯示常用應用程式執行的矩形區域。

• Icons（圖示） - 用於表示軟體應用程式或硬體裝置的圖片或符號。

• Menus（選單） - 使用者可以選擇所需內容的選項列表。

• Pointers（指標） - 當用戶移動滑鼠時，在螢幕上移動的符號（如箭頭）。它幫助使用者選擇物件。

使用者介面設計

它從任務分析開始，瞭解使用者的首要任務和問題域。它應該根據使用者的術語和使用者的任務出發點來設計，而不是程式設計師的。

• 為了執行使用者介面分析，實踐者需要學習和理解四個要素：

  • 將透過介面與系統互動的使用者

  • 終端使用者必須執行以完成其工作的任務

  • 作為介面一部分呈現的內容

  • 將執行這些任務的工作環境

• 正確或良好的UI設計基於使用者的功能和限制，而不是機器。在設計UI時，瞭解使用者工作和環境的性質也至關重要。

• 然後可以將要執行的任務進行劃分，根據對每種功能和限制的瞭解，將任務分配給使用者或機器。使用者介面的設計通常分為四個不同的級別：

  • 概念級別 - 它描述了考慮使用者對系統的看法和對它們可能採取的操作的基本實體。

  • 語義級別 - 它描述了系統執行的功能，即系統功能需求的描述，但不涉及使用者如何呼叫這些功能。

  • 語法級別 - 它描述了呼叫所描述的功能所需的輸入和輸出序列。

  • 詞法級別 - 它確定輸入和輸出實際上是如何從原始硬體操作中形成的。

• 使用者介面設計是一個迭代過程，其中每次迭代都解釋和完善在前面步驟中開發的資訊。使用者介面設計的通用步驟

• 定義使用者介面物件和操作。

• 定義將導致使用者介面狀態發生變化的事件（使用者操作）。

• 指示使用者如何透過介面提供的資訊來解釋系統狀態。

• 描述每個介面狀態的實際外觀。

使用者介面開發流程

它遵循如下所示的螺旋過程：

介面分析

它專注於將與系統互動的使用者、任務、內容和工作環境。定義實現系統功能所需的人機任務。

介面設計

它定義了一組介面物件、操作及其螢幕表示，使使用者能夠以滿足為系統定義的每個可用性目標的方式執行所有定義的任務。

介面構建

它從原型開始，使使用場景能夠得到評估，並繼續使用開發工具來完成構建。

介面驗證

它側重於介面正確實現每個使用者任務的能力、適應所有任務變化、實現所有通用使用者需求以及介面易於使用和易於學習的程度。

使用者介面模型

當分析和設計使用者介面時，使用以下四個模型：

使用者配置檔案模型

• 由使用者或軟體工程師建立，它根據年齡、性別、身體能力、教育程度、動機、目標和個性來建立系統的終端使用者的配置檔案。

• 考慮使用者的語法和語義知識，並將使用者分類為新手、知識型間歇使用者和知識型常用使用者。

設計模型

• 由軟體工程師建立，它包含軟體的資料、架構、介面和過程表示。

• 源自需求的分析模型，並由需求規範中的資訊控制，這有助於定義系統的使用者。

實現模型

• 由負責介面外觀和感覺的軟體實現者建立，並結合所有支援資訊（書籍、影片、幫助檔案），描述系統的語法和語義。

• 作為設計模型的翻譯，並試圖與使用者的思維模型相符，以便使用者對軟體感到滿意並有效地使用它。

使用者的思維模型

• 使用者與應用程式互動時建立的。它包含使用者腦海中對系統的印象。

• 通常稱為使用者的系統感知，其描述的正確性取決於使用者的個人資料以及對應用程式領域中軟體的整體熟悉程度。

使用者介面設計注意事項

以使用者為中心

使用者介面必須是以使用者為中心的產物，它讓使用者參與產品的整個開發生命週期。使用者介面原型應該提供給使用者，並且應該將使用者的反饋整合到最終產品中。

簡單直觀

UI 提供簡單性和直觀性，以便無需說明即可快速有效地使用。GUI 比文字式 UI 更好，因為 GUI 包含選單、視窗和按鈕，只需使用滑鼠即可操作。

讓使用者掌控

不要強迫使用者完成預定義的序列。給他們選擇——取消或儲存並返回他們離開的地方。在整個介面中使用使用者可以理解的術語，而不是系統或開發人員術語。

向用戶提供一些指示，表明已執行操作，方法是向他們顯示操作的結果，或確認操作已成功完成。

透明性

UI 必須是透明的，幫助使用者感覺他們直接接觸計算機並直接操作他們正在處理的物件。透過為使用者提供工作物件而不是系統物件，可以使介面透明。例如，使用者應該理解他們的系統密碼必須至少為 6 個字元，而不是密碼必須佔用多少位元組的儲存空間。

採用漸進式資訊披露

始終方便訪問常用功能和常用操作。隱藏不太常用的功能和操作，並允許使用者對其進行導航。不要試圖將所有資訊都放在一個主視窗中。將非關鍵資訊放在輔助視窗中。

一致性

UI在產品內部和產品之間保持一致性，保持互動結果一致，UI命令和選單應具有相同的格式，命令標點應相似，引數應以相同的方式傳遞給所有命令。UI不應具有可能令使用者感到意外的行為，並且應包含允許使用者從錯誤中恢復的機制。

整合

軟體系統應與其他應用程式（例如MS記事本和MS-Office）平滑整合。它可以直接使用剪貼簿命令執行資料交換。

面向元件

UI設計必須模組化幷包含面向元件的架構，以便UI的設計與軟體系統主體的設計具有相同的要求。模組可以輕鬆修改和替換，而不會影響系統的其他部分。

可定製

整個軟體系統的架構包含外掛模組，允許許多不同的人獨立擴充套件軟體。它允許單個使用者從各種可用表單中進行選擇，以滿足個人喜好和需求。

減少使用者的記憶負擔

不要強迫使用者記住並重復計算機應該為他們做的事情。例如，填寫線上表格時，系統應記住客戶姓名、地址和電話號碼，一旦使用者輸入這些資訊，或一旦開啟客戶記錄。

使用者介面透過向用戶提供可供識別的專案來支援長期記憶檢索，而不是要求使用者回憶資訊。

分離

UI必須透過其實現與系統的邏輯分離，以提高可重用性和可維護性。

架構技術

迭代和增量方法

這是一種迭代和增量方法，包含五個主要步驟，有助於生成候選解決方案。可以透過重複這些步驟來進一步完善此候選解決方案，並最終建立最適合我們應用程式的架構設計。在流程結束時，我們可以審查並向所有利益相關者傳達我們的架構。

這只是其中一種可能的方法。還有許多其他更正式的方法來定義、審查和傳達您的架構。

確定架構目標

確定構成架構和設計過程的架構目標。完美且明確的目標強調架構，解決設計中的正確問題，並有助於確定當前階段何時完成以及何時準備進入下一階段。

此步驟包括以下活動：

• 在開始時確定您的架構目標。
• 確定我們架構的使用者。
• 確定約束條件。

架構活動的示例包括：構建原型以獲取有關 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)

這種方法表示系統模型的三個檢視。**功能需求檢視**（從使用者的角度來看系統的功能需求，包括用例）；**靜態結構檢視**（物件、屬性、關係和操作，包括類圖）；以及**動態行為檢視**（物件之間的協作和物件內部狀態的變化，包括序列、活動和狀態圖）。