軟考高級系統架構設計師-第11章系統架構設計

【本章學習建議】

根據考試大綱，本章不僅考查系統架構設計師單選題，預計考12分左右，而且案例分析和論文寫作也是必考，對應第二版教材第7章，屬于重點學習的章節。

軟考高級系統架構設計師VIP課程https://edu.csdn.net/course/detail/40283

11.1 軟件架構概念

11.1.1 軟件架構的定義

軟件架構（Software Architecture，SA）：一個程序和計算系統軟件體系結構是指系統的一個或者多個結構。結構中包括軟件的構件，構件的外部可見屬性以及它們之間的相互關系。（從需求分析到軟件設計之間的過渡過程）

架構并非可運行軟件。確切地說，它是一種表達，使軟件工程師能夠：

（1）分析設計在滿足所規定的需求方面的有效性；

（2）在設計變更相對容易的階段，考慮體系結構可能的選擇方案；

（3）降低與軟件構造相關聯的風險。

軟件架構設計包括提出架構模型，產生架構設計和進行設計評審等活動，是一個迭代的過程。

架構設計主要關注軟件構件的結構、屬性和交互作用，并通過多種視圖全面描述特定系統的架構。

軟件架構是項目干系人進行交流的手段，明確了對系統實現的約束條件，決定了開發和維護組織的組織結構，制約著系統的質量屬性。研究軟件架構的根本目的是解決好軟件的復用、質量和維護問題。

軟件架構是可傳遞和可復用的模型，通過研究軟件架構可能預測軟件的質量。

11.1.2 軟件架構設計與生命周期

1. 需求分析階段

需求分析和SA設計面臨的是不同的對象：一個是問題空間；另一個是解空間。從軟件需求模型向SA模型的轉換主要關注兩個問題：如何根據需求模型構建SA模型。如何保證模型轉換的可追蹤性。

2. 設計階段

設計階段是SA研究關注的最早和最多的階段，這一階段的SA研究主要包括：SA模型的描述、SA模型的設計與分析方法，以及對SA設計經驗的總結與復用等。有關SA模型描述的研究分為3個層次：SA的基本概念（構件和連接子）、體系結構描述語言ADL、SA模型的多視圖表示。

SA模型的多視圖表示從不同的視角描述特定系統的體系結構，從而得到多個視圖，并將這些視圖組織起來以描述整體的SA模型。多視圖體現了關注點分離SOC的思想。典型的多視圖的方案包括4+1模型（邏輯視圖、進程視圖、開發視圖、物理視圖，加上統一的場景）。Philippe Kruchten在1995年提出了一個“4+1”的視圖模型。“4+1”視圖模型從5個不同的視角包括邏輯視圖、進程視圖、開發視圖、物理視圖和統一的場景來描述軟件架構。每一個視圖只關心系統的一個側面，5個視圖結合在一起才能反映系統的軟件架構的全部內容。

軟件架構設計的4+1視圖：

邏輯視圖：也稱設計視圖，主要描述系統的功能需求。

進程視圖：也稱過程視圖，主要關注一些非功能性的需求，例如系統的性能和可用性。進程視圖強調并發性、分布性、系統集成性和容錯能力，以及邏輯視圖中的主要抽象的進程結構。

開發視圖：也稱實現視圖，側重于軟件模塊的組織和管理。

物理視圖：主要描述如何把軟件映射到硬件上，通常要考慮到解決系統拓撲結構、系統安裝、通信等問題。

統一的場景：可以看作是那些重要系統活動的抽象，它使4個視圖有機地聯系起來，從某種意義上說，場景是最重要的需求抽象。在開發架構時，它可以幫助設計者找到架構的構件以及它們之間的作用關系。邏輯視圖和開發視圖描述系統的靜態結構，而進程視圖和物理視圖描述系統的動態結構。對于不同的軟件系統來說，側重的角度也有所不同。例如，對于管理信息系統來說，比較側重于從邏輯視圖和開發視圖來描述系統，而對于實時控制系統來說，則比較注重于從進程視圖和物理視圖來描述系統。

3. 實現階段

最初SA研究往往只關注較高層次的系統設計、描述和驗證。為了有效實現SA設計向實現的轉換，實現階段的體系結構研究表現在以下幾個方面。

（1）研究基于SA的開發過程支持，如項目組織結構、配置管理等。

（2）尋求從SA向實現過渡的途徑，如將程序設計語言元素引入SA階段、模型映射、構件組裝、復用中間件平臺等。

（3）研究基于SA的測試技術。

4. 構件組裝階段

在SA設計模型的指導下，可復用構件的組裝可以在較高層次上實現系統，并能夠提高系統實現的效率。在構件組裝的過程中，SA設計模型起到了系統藍圖的作用。研究內容包括如下兩個方面。

（1）如何支持可復用構件的互聯，即對SA設計模型中規約的連接子的實現提供支持。

（2）在組裝過程中，如何檢測并消除體系結構失配問題。

在構件組裝階段的失配問題主要包括：由構件引起的失配、由連接子引起的失配、由于系統成分對全局體系結構的假設存在沖突引起的失配等。

5. 部署階段

SA對軟件部署作用如下：

（1）提供高層的體系結構視圖來描述部署階段的軟硬件模型。

（2）基于SA模型可以分析部署方案的質量屬性，從而選擇合理的部署方案。

6. 后開發階段

后開發階段是指軟件部署安裝之后的階段。這一階段的SA研究主要圍繞維護、演化、復用等方面來進行。典型的研究方向包括動態軟件體系結構、體系結構恢復與重建等。

（1）動態軟件體系結構。現實中的軟件具有動態性，體系結構會在運行時發生改變。運行時變化包括兩類：軟件內部執行所導致的體系結構改變；軟件系統外部的請求對軟件進行的重配置。動態軟件體系結構包括兩個部分的研究：體系結構設計階段的支持、運行時刻基礎設施的支持。

（2）體系結構恢復與重建。對于現有系統在開發時候沒有考慮SA的情況，從這些系統中恢復或重構體系結構。從已有的系統中獲取體系結構的重建方法分為4類：手工體系結構重建、工具支持的手工重建、通過查詢語言來自動建立聚集、使用其他技術（如數據挖掘等）。

構件（補充）

構件是面向軟件體系架構的可復用軟件模塊。構件（Component）是可復用的軟件組成成份，可被用來構造其他軟件。它可以是被封裝的對象類、功能模塊、軟件框架（Framework）、中間件等。

構件是一個獨立可交付的功能單元，外界通過接口訪問其提供的服務。

構件由一組通常需要同時部署的原子構件組成。一個原子構件是一個模塊和一組資源。原子構件是部署、版本控制和替換的基本單位。原子構件通常成組地部署，但是它也能夠被單獨部署。

構件和原子構件之間的區別在于，大多數原子構件永遠都不會被單獨部署，盡管它們可以被單獨部署。相反，大多數原子構件都屬于一個構件家族，一次部署往往涉及整個家族。

模塊：是不帶單獨資源的原子構件，是一組類和可能的非面向對象的結構體，比如過程或者函數。

構件的特性：

（1）獨立部署單元，具有原子性，是不可拆分的；

（2）作為第三方的組裝單元；

（3）沒有外部的可見狀態。

一個構件可以包含多個類元素，但是一個類元素只能屬于一個構件。將一個類拆分進行部署通常沒什么意義。

對象的特性：

（1）一個實例單元，具有唯一的標志。

（2）可能具有狀態，此狀態外部可見。

（3）封裝了自己的狀態和行為。

構件接口：

接口標準化是對接口中消息的格式、模式和協議的標準化。它不是要將接口格式化為參數化操作的集合，而是關注輸入輸出的消息的標準化，它強調當機器在網絡中互連時，標準的消息模式、格式、協議的重要性。

面向構件的編程（COP）：

關注于如何支持建立面向構件的解決方案。面向構件的編程需要下列基本的支持：

--多態性（可替代性）；

--模塊封裝性（高層次信息的隱藏）；

--后期的綁定和裝載（部署獨立性）；

--安全性（類型和模塊安全性）。

構件技術就是利用某種編程手段，將一些人們所關心的，但又不便于讓最終用戶去直接操作的細節進行了封裝，同時對各種業務邏輯規則進行了實現，用于處理用戶的內部操作細節。目前，國際上常用的構件標準主要有三大流派：

·EJB（Enterprise Java Bean）規范由Sun公司制定，有三種類型的EJB，分別是會話Bean（Session Bean）、實體Bean（Entity Bean）和消息驅動Bean（Message-driven Bean）。EJB實現應用中關鍵的業務邏輯，創建基于構件的企業級應用程序。

·COM、DCOM、COM+：組件對象模型，COM是微軟公司的。DCOM是COM的進一步擴展，具有位置獨立性和語言無關性。COM+并不是COM的新版本，是COM的新發展或是更高層次的應用。

·COBRA標準，是由OMG制定的一種面向對象分布式應用程序體系規范。主要分為三個層次：對象請求代理、公共對象服務和公共設施。最底層是對象請求代理ORB，規定了分布對象的定義（接口）和語言映射，實現對象間的通訊和互操作，是分布對象系統中的“軟總線”；在ORB之上定義了很多公共對象服務，可以提供諸如并發服務、名字服務、事務(交易)服務、安全服務等各種各樣的服務；最上層的公共設施則定義了組件框架，提供可直接為業務對象使用的服務，規定業務對象有效協作所需的協定規則。

11.2 基于架構的軟件開發方法

11.2.1 概述

基于架構的軟件設計（Architecture-Based Software Design，ABSD）方法是由架構驅動，即由構成架構的商業、質量和功能需求的組合驅動架構設計。它強調采用視角和視圖來描述軟件架構，采用用例和質量屬性場景來描述需求。進一步來說，用例描述的是功能需求，質量屬性場景描述的是質量需求(或側重于非功能需求)。

使用ABSD方法，設計活動可以從項目總體功能框架明確就開始，這意味著需求獲取和分析還沒有完成，就開始了軟件設計。

ABSD方法有三個基礎。第一個基礎是功能的分解，使用已有的基于模塊的內聚和耦合技術；第二個基礎是通過選擇架構風格來實現質量和商業需求；第三個基礎是軟件模板的使用，軟件模板利用了一些軟件系統的結構。

ABSD方法是遞歸的，且迭代的每一個步驟都是清晰定義的。因此，不管設計是否完成，架構總是清晰的，有助于降低架構設計的隨意性。

11.2.2 概念和術語

1. 設計元素

ABSD方法是一個自頂向下，遞歸細化的方法，軟件系統的體系結構通過該方法得到細化，直到能產生軟件構件和類。

ABSD方法中使用的設計元素如下圖所示。在最頂層，系統被分解為若干概念子系統和一個或若干個軟件模板。在第2層，概念子系統又被分解成概念構件和一個或若干個附加軟件模板。

2. 視角與視圖

考慮體系結構時，要從不同的視角（Perspective）來觀察對架構的描述，這需要軟件設計師考慮體系結構的不同屬性。例如，展示功能組織的靜態視角能判斷質量特性，展示并發行為的動態視角能判斷系統行為特性，因此，選擇的特定視角或視圖（如邏輯視圖、進程視圖、實現視圖和配置視圖）可以全方位的考慮體系結構設計。使用邏輯視圖來記錄設計元素的功能和概念接口，設計元素的功能定義了它本身在系統中的角色，這些角色包括功能、性能等。

3. 用例和質量場景

用例己經成為推測系統在一個具體設置中的行為的重要技術，用例被用在很多不同的場合，用例是系統的一個給予用戶一個結果值的功能點，用例用來捕獲功能需求。

在使用用例捕獲功能需求的同時，人們通過定義特定場景來捕獲質量需求，并稱這些場景為質量場景。

11.2.3 基于架構的開發模型

傳統的軟件開發過程是問題定義，需求分析，軟件設計，實現，測試。ABSD把整個軟件過程分成六個部分，架構需求，架構設計，架構文檔化，架構復審，架構實現和架構演化六個步驟。

（1）架構需求：重在掌握標識構件的三步，如下圖。架構需求一般來自3個方面，分別是系統的質量目標、系統的商業目標和系統開發人員的商業目標。

（2）架構設計：將需求階段的標識構件映射成構件，進行分析，如下圖。

（3）架構文檔化：主要產出兩種文檔，即架構規格說明和測試架構需求的質量設計說明書。文檔是至關重要的，是所有人員通信的手段，關系開發的成敗。

（4）架構復審：由外部人員（獨立于開發組織之外的人，如用戶代表和領域專家等）參加的復審，復審架構能否滿足需求、質量需求是否在設計中得到體現、構件的劃分是否合理等。若復審不過，則返回架構設計階段重新進行架構設計、文檔化和復審。

（5）架構實現：用實體來顯示出架構。實現構件，構件組裝成系統，如下圖。

（6）架構演化：對架構進行改變，按需求增刪構件，使架構可復用，如下圖。

11.2.4 體系結構的演化

體系結構演化是使用系統演化步驟去修改應用，以滿足新的需求。主要包括以下6個步驟。

1.需求變化歸類

首先必須對用戶需求的變化進行歸類，使變化的需求與已有構件對應。對找不到對應構件的變動，也要做好標記，在后續工作中，將創建新的構件，以對應這部分變化的需求。

????2.制訂體系結構演化計劃

????在改變原有結構之前，開發組織必須制訂一個周密的體系結構演化計劃，作為后續演化開發工作的指南。

3.修改、增加或刪除構件

在演化計劃的基礎上，開發人員可根據在第1步得到的需求變動的歸類情況，決定是否修改或刪除存在的構件、增加新構件。最后，對修改和增加的構件進行功能性測試。

4.更新構件的相互作用

隨著構件的增加、刪除和修改，構件之間的控制流必須得到更新。

5.構件組裝與測試

通過組裝支持工具把這些構件的實現體組裝起來，完成整個軟件系統的連接與合成，形成新的體系結構。然后對組裝后的系統整體功能和性能進行測試。

????6.技術評審

對以上步驟進行確認，進行技術評審。評審組裝后的體系結構是否反映需求變動、符合用戶需求。如果不符合，則需要在第2到第6步之間進行迭代。

在原來系統上所做的所有修改必須集成到原來的體系結構中，完成一次演化過程。

11.3 軟件架構風格

11.3.1 軟件架構風格概述

軟件架構風格是描述某一特定應用領域中系統組織方式的慣用模式。架構風格定義一個系統家族，即一個體系結構定義、一個詞匯表和一組約束。詞匯表中包含一些構件和連接件類型，而這組約束指出系統是如何將這些構件和連接件組合起來的。

架構風格反映了領域中眾多系統所共有的結構和語義特性，并指導如何將各個模塊和子系統有效地組織成一個完整的系統。對軟件架構風格的研究和實踐促進對設計的重用，一些經過實踐證實的解決方案也可以可靠地用于解決新的問題。

架構風格定義了用于描述系統的術語表和一組指導構建系統的規則。

軟件架構設計的一個核心目標問題是能否達到架構級的軟件復用。

11.3.2 數據流體系結構風格

數據流體系結構風格，面向數據流，按照一定的順序從前向后執行程序，主要包括批處理風格和管道-過濾器風格。

1. 批處理體系結構風格

構件為一系列固定順序的計算單元，構件之間只通過數據傳遞交互。每個處理步驟是一個獨立的程序，每一步必須在其前一步結束后才能開始，數據必須是完整的，以整體的方式傳遞。構件是獨立的應用程序，連接件是某種類型的媒介。

2. 管道-過濾器體系結構風格

每個過濾器（處理步驟）都有一組輸入和輸出，過濾器從管道（數據傳輸）中讀取輸入的數據流，經過內部處理，產生輸出數據流并寫入管道中。前一個過濾器的輸出作為后一個過濾器的輸入，前后數據流關聯。構件就是過濾器，連接件就是管道。早期編譯器就是采用的這種架構，要一步一步處理的，均可考慮此架構風格。

二者區別在于批處理前后構件不一定有關聯，并且是作為整體傳遞，即必須前一個執行完才能執行下一個。管道-過濾器是前一個輸出作為后一個輸入，前面執行到部分可以開始下一個的執行。

典型實例：傳統編譯器、網絡報文處理。

11.3.3 調用/返回體系結構風格

調用/返回風格是指在系統中采用了調用與返回機制。其主要思想是將一個復雜的大系統分解為若干子系統，以便降低復雜度，并且增加可修改性。構件之間存在互相調用的關系，一般是顯式的調用，主要包括主程序/子程序風格、面向對象風格、層次型風格、客戶端/服務器風格以及瀏覽器/服務器體系結構風格。

1. 主程序/子程序風格

采用單線程控制，把問題劃分為若干個處理步驟，構件即為主程序和子程序，子程序通常可合成為模塊。過程調用作為交互機制，充當連接件的角色。

2. 面向對象體系結構風格

構件是對象，或者說是抽象數據類型的實例，連接件是對象間交互的方式。對象是通過函數和過程的調用來交互的。

3. 層次型體系結構風格

構件組成一個層次結構，連接件通過決定層間如何交互的協議來定義。每一層為上層提供服務，并作為下層的客戶，只對與自己相鄰的層可見。修改某一層，最多影響其相鄰的兩層（通常只能影響上層）。

·層次型結構優點：

（1）支持基于可增加抽象層的設計，允許將一個復雜問題分解成一個增量步驟序列的實現。

（2）不同的層次處于不同的抽象級別，越靠近底層，抽象級別越高。

（3）每一層最多只影響兩層，為軟件復用提供了強大的支持。

·層次型結構缺點：

（1）并不是每個系統都可以很容易地劃分為分層的模式。

（2）很難找到一個合適的、正確的層次抽象方法。

4. 客戶端/服務器體系結構風格

C/S（客戶端/服務器）軟件體系結構是基于資源不對等，且為實現共享而提出的。兩層C/S體系結構有3個主要組成部分：數據庫服務器、客戶應用程序和網絡。服務器（后臺）負責數據管理，客戶機（前臺）完成與用戶的交互任務，稱為“胖客戶機，瘦服務器”。

與兩層C/S結構相比，三層C/S結構增加了一個應用服務器。整個應用邏輯駐留在應用服務器上，只有表示層存在于客戶機上，故稱為“瘦客戶機”。應用功能分為表示層、功能層和數據層三層。表示層是應用的用戶接口部分，通常使用圖形用戶界面；功能層是應用的主體，實現具體的業務處理邏輯；數據層是數據庫管理系統。以上三層邏輯上獨立。表示層在客戶機上，功能層在應用服務器上，數據層在數據庫服務器上。

5. 瀏覽器/服務器體系結構風格

B/S架構是三層C/S架構的變種，將客戶端變為用戶客戶端上的瀏覽器，將應用服務器變為網絡上的WEB服務器，又稱為零客戶端架構。其三層結構為：瀏覽器、Web服務器和數據庫服務器。雖然不用開發客戶端，但有很多缺點：

·對動態頁面的支持能力較弱，沒有集成有效的數據庫處理功能；

·安全性難以控制；

·在數據查詢等響應速度上，要遠遠低于C/S架構；

·數據提交一般以頁面為單位，數據的動態交互性不強，不利于OLTP應用。

11.3.4 以數據為中心的體系結構風格

以數據為中心的體系結構以數據為中心，所有的操作都是圍繞建立的數據中心進行的，主要包括倉庫體系結構風格和黑板體系結構風格。

1. 倉庫體系結構風格

倉庫（Repository）是存儲和維護數據的中心場所。倉庫架構風格由中央數據結構（說明當前數據狀態）和一組獨立構件（對中央數據進行操作）組成。連接件是倉庫與獨立構件之間的交互。

2. 黑板體系結構風格

包括知識源、黑板和控制三部分。知識源包括若干獨立計算的不同單元，提供解決問題的知識。知識源響應黑板的變化，修改黑板；黑板是一個全局數據庫，包含問題域解空間的全部狀態，是知識源相互作用的唯一媒介；知識源響應是通過黑板狀態的變化來控制的。黑板架構風格適用于解決復雜的非結構化的問題，能在求解過程中綜合運用多種不同知識源，使得問題的表達、組織和求解變得比較容易，如信號處理、問題規劃和編譯器優化等。

11.3.5 虛擬機體系結構風格

虛擬機體系結構風格的基本思想是人為構建一個運行環境，在這個環境之上，可以解析與運行自定義的一些語言，這樣來增加架構的靈活性。自定義了一套規則供使用者使用，使用者基于這個規則來開發構件，能夠跨平臺適配，主要包括解釋器風格和規則系統風格。

1. 解釋器體系結構風格

通常包括一個完成解釋工作的解釋引擎、一個包含將被解釋的代碼的存儲區、一個記錄解釋引擎當前工作狀態的數據結構，以及一個記錄源代碼被解釋執行的進度的數據結構。具有解釋器風格的軟件中含有一個虛擬機，可以仿真硬件的執行過程和一些關鍵應用，缺點是執行效率低。典型的例子是專家系統。

2. 規則系統體系結構風格

基于規則的系統包括規則集、規則解釋器、規則/數據選擇器及工作內存，一般用在人工智能領域和決策支持系統DSS中。

11.3.6 獨立構件體系結構風格

獨立構件體系結構風格主要強調構件之間是互相獨立的，不存在顯式的調用關系，而是通過某個事件觸發、異步的方式來執行，以降低耦合度，提升靈活性。主要包括進程通信和事件系統風格（隱式調用）。

1. 進程通信體系結構風格

構件是獨立的進程，連接件是消息傳遞。構件通常是命名過程，消息傳遞的方式可以是點對點、異步或同步方式，以及遠程過程（方法）調用等。

2. 事件系統體系結構風格

基于事件的隱式調用風格。構件不直接調用一個過程，而是觸發或廣播一個或多個事件。構件中的過程在一個或多個事件中注冊，當某個事件被觸發時，系統自動調用在這個事件中注冊的所有過程，這樣，一個事件的觸發就導致了另一個模塊中的過程調用。這種風格中的構件是匿名的過程，它們之間交互的連接件往往是以過程之間的隱式調用來實現的。

主要優點是為軟件復用提供了強大的支持，為構件的維護和演化帶來了方便；缺點是構件放棄了對系統計算的控制。

C2體系結構風格（補充）

C2體系結構風格可以概括為，通過連接件綁定在一起按照一組規則運作的并行構件網絡。C2風格中的系統組織規則如下：

（1）系統中的構件和連接件都有一個頂部和一個底部；

（2）構件的頂部應連接到某連接件的底部，構件的底部則應連接到某連接件的頂部，而構件與構件之間的直接連接是不允許的；

（3）一個連接件可以和任意數目的其他構件和連接件連接；

（4）當兩個連接件進行直接連接時，必須由其中一個的底部到另一個的頂部。

11.4 軟件架構復用

1. 軟件架構復用的定義及分類

軟件架構復用是系統化的軟件開發過程：開發一組基本的軟件構件模塊，以覆蓋不同的需求/體系結構之間的相似性，提高系統開發的效率、質量和性能。

軟件架構復用的類型包括機會復用和系統復用。機會復用是指開發過程中，只要發現有可復用的資產，就對其進行復用。系統復用是指在開發之前，就要進行規劃，以決定哪些需要復用。

2. 軟件架構復用的原因

減少開發工作、減少開發時間、降低開發成本、提高生產力、提高產品質量，更好的互操作性，使產品維護變得更加簡單。

3. 軟件架構復用的對象及形式

可復用的資產包括：需求、架構設計、元素、建模與分析、測試、項目規劃、過程方法和工具、人員、樣本系統、缺陷消除。

一般形式的復用包括：函數的復用、庫的復用、面向對象開發中的類、接口和包的復用。

4. 軟件架構復用的基本過程

（1）構造/獲取可復用的軟件資產（復用的前提）。首先需要構造恰當的、可復用的資產，并且這些資產必須是可靠的、可被廣泛使用的、易于理解和修改的。

（2）管理可復用資產。該階段最重要的是：構件庫（Component Library），其對可復用構件進行存儲和管理，是支持軟件復用的必要設施。構件庫應提供的主要功能包括構件的存儲、管理、檢索以及庫的瀏覽與維護等，以及支持使用者有效地、準確地發現所需的可復用構件。

（3）使用可復用資產。在最后階段，通過獲取需求，檢索復用資產庫，獲取可復用資產，并定制這些可復用資產：修改、擴展、配置等，最后將它們組裝與集成，形成最終系統。

11.5 特定領域軟件體系結構

11.5.1 DSSA的定義

DSSA（Domain Specific Software Architecture，DSSA）就是在一個特定應用領域中為一組應用提供組織結構參考的標準軟件體系結構，即用于某一類特定領域的標準軟件構件的集合。

DSSA就是一個特定的問題領域中支持一組應用的領域模型、參考需求、參考架構等組成的開發基礎，其目標就是支持在一個特定領域中多個應用的生成。

從功能覆蓋的范圍的角度有兩種理解DSSA中領域的含義的方式。

（1）垂直域：定義了一個特定的系統族，包含整個系統族內的多個系統，結果是在該領域中可作為系統的可行解決方案的一個通用軟件體系結構。即在一個特定領域中的通用軟件架構。

（2）水平域：定義了在多個系統和多個系統族中功能區城的共有部分。在子系統級上涵蓋多個系統族的特定部分功能。（如購物和教育都有收費系統，收費系統即是水平域）。

11.5.2 DSSA的基本活動

1. 領域分析

這個階段的主要目標是獲得領域模型（領域需求）。識別信息源，即整個領域工程過程中信息的來源，可能的信息源包括現存系統、技術文獻、問題域和系統開發的專家、用戶調查和市場分析、領域演化的歷史記錄等，在此基礎上就可以分析領域中系統的需求，確定哪些需求是領域中的系統廣泛共享的，從而建立領域模型。

2. 領域設計

這個階段的主要目標是獲得DSSA。DSSA描述在領域模型中表示的需求的解決方案，它不是單個系統的表示，而是能夠適應領域中多個系統的需求的一個高層次的設計。建立了領域模型之后，就可以派生出滿足這些被建模的領域需求DSSA。

3. 領域實現

這個階段的主要目標是依據領域模型和DSSA開發和組織可重用信息。這些可重用信息可能是從現有系統中提取得到，也可能需要通過新的開發得到。

11.5.3 參與DSSA的人員

參與DSSA的人員可以劃分為4種角色：

（1）領域專家：包括該領域中系統的有經驗的用戶、從事該領域中系統的需求分析、設計、實現以及項目管理的有經驗的軟件工程師等。主要任務包括提供關于領域中系統的需求規約和實現的知識，幫助組織規范的、一致的領域字典，幫助選擇樣本系統作為領域工程的依據，復審領域模型、DSSA等領域工程產品等。

（2）領域分析人員：由具有知識工程背景的有經驗的系統分析員來擔任。主要任務包括控制整個領域分析過程，進行知識獲取，將獲取的知識組織到領域模型中。

（3）領域設計人員：由有經驗的軟件設計人員來擔任。主要任務包括根據領域模型和現有系統開發出DSSA，并對DSSA的準確性和一致性進行驗證。

（4）領域實現人員：由有經驗的程序設計人員來擔任。主要任務包括根據領域模型和DSSA，開發可重用的構件。