三、软件体系结构风格

软件体系结构风格

一、概述

软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。
体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。

体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。根据项目的具体特点进行分析，再确定使用的风格。风格的使用几乎完全是特定的。

体系结构风格的关键四要素:

1. 一个词汇表
2. 定义一套配置规则
3. 定义一套语义解释原则
4. 定义对基于此风格的系统所进行的分析

经典的体系结构风格

1. 数据流风格:批处理序列;管道/过滤器。
2. 调用/返回风格: 主程序/子程序;面向对象风格;层次结构。
3. 独立构件风格:进程通讯;事件系统。
4. 虚拟机风格:解释器;基于规则的系统。
5. 仓库风格: 数据库系统;超文本系统;黑板
   系统。

二、经典的体系结构风格

管道/过滤器

典型例子:

1. 以UNIX，shelI编写的程序。
2. 传统的编译器一 个阶段的输出是另一个阶段的输入(词法分析、语法分析、语义分析、代码生成)

管道/过滤器风格的优点:

1. 使得软构件具有良好的隐蔽性和高内聚、低耦合的特点;
2. 允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成;
3. 支持软件重用。只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连
4. 系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来;旧的可以被改进的过滤器替换掉;
5. 允许对些如吞吐量、死锁等属性的分析;
   6.支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行。

管道过滤器的缺点

1. 通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换;
2. 不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重;
   3.因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。

数据抽象和面向对象组织

面向对象系统的优点

1. 因为对象对其它对象隐藏它的表示所以可以改一个对象的表示，而不影响其它的对象;
2. 设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。

面向对象系统的缺点

1. 为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象;
2. 必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那么，C对B的使用所造成的对A的影响可能是料想不到的。

基于事件的隐式调用风格

构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。

这种风格的构件是一些模块， 模块既可以是一些过程，又可以是一-些事件的集合。过程可以用通用的方式调用，也可以在系统事件中注册些 过程，当发生这些事件时，过程被调用。

这种风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。
这样不能假定构件的处理顺序甚至不知道哪些过程会被调用，因此许多隐式调用的系统也包含显式调用作为构件交互的补充形式

基于事件的隐式调用的优点

1. 为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。
2. 为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其它构件的接口。

基于事件的隐式调用的缺点

1. 构件放弃了对系统计算的控制。一个构件触发个事件时，不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被调用的顺序。
2. 数据交换的问题。有时数据可被一个事件传 递，但另些情况下， 基于事件的系统必须依靠一 个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题。

分层系统

其最广泛的应用是:分层通信协议

分层系统的优点

1. 支持基于抽象程度递增的系统设计，使设计者可以把一一个复杂系统按递增的步骤进行分解;
2. 支持功能增强，因为每层至多和相邻的上交互，因此功能的改变最多影响相邻的上下层;
   3.支持重用。只要提供的服务接口定义不变，同层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。

分层系统的缺点

1. 并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把-些低级或高级的功能综合起来.
2. 很难找到一个合适的、正确的层次抽象方法。

仓库系统及知识库风格

在仓库风格中，有两种不同的构件:
中央数据结构说明当前状态，独立构件在中央数据存贮上执行，仓库与外构件间的相互作用在系统中会有大的变化。

控制原则的选取产生两个主要的子类。若输入流中某类时间触发进程执行的选择，则仓库是传统型数据库;另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是黑板系统。

黑板系统的组成:

1. 知识源
2. 黑板数据结构
3. 控制
   知识源:包含独立的、与应用程序相关的知识，它们之间不直接进行通信，只通过黑板进行交互。黑板数据结构:与应用程序相关的解决问题的数据，知识源通过不断改变黑板数据来解决问题。

黑板系统的组成：

其传统应用:信号处理领域。如语言、模式识别

C2风格

通过连接件绑定在一起的按照-组规则运作的并行构网络。C2风格中的系统组织规则如下:

1. 系统中的构件和连接件都有一一个顶部和一个底部;
2. 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的;
3. 一个连接件可以和任意数目的其它构件和连接件连接;
4. 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

C2风格的特点

1. 系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起;
2. 所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的;
3. 构件相对独立，构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设。

三、客户/服务器风格

产生背景：
在集中式计算技术时代广泛使用的是大型机小型机计算模型。它是通过一台物理上与宿主机相连接的非智能终端来实现宿主机上的应用程序。

20世纪80年代以后，集中式结构逐渐被以PC机为主的微机网络所取代。个人计算机和工作站的采用，永远改变了协作计算模型，从而导致了分散的个人计算模型的产生。

基本概念
C/S软件体系结构是基于资源不对等，且为实现共享而提出来的，是20世纪90年代成熟起来的技术，C/S体系结构定义了工作站如何与服务器相连，以实现数据和应用分布到多个处理机上。

C/S体系结构有三个主要组成部分:

• 数据库服务器
• 客户应用程序
• 网络

C/S软件体系结构示意图如下:

任务分配

1. 服务器- (后台)负责管理系统资源，任务如下:
   (1)数据库安全性的要求;
   (2)数据库访问并发性的控制;
   (3)数据库前端的客户应用程序的全局数据完整性规则;
   (4)数据库的备份与恢复。

2. 客户应用程序(前台)应完成的任务如下:
   (1)提供用户与数据库交互的界面;
   (2)向数据库服务器提交用户请求并接收来自数据库服务器的信息;
   (3)利用客户应用程序对存在于客户端的数据执行应用逻辑要求。

3. 网路通信软件应完成的任务 如下:
   完成数据库服务器与客户端应用程序之间的数据传输。

C/S软件体系结构的一般处理流程如下图:

C/S软件体系结构的优点

1. C/S 体系结构具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。
2. 系统的客户应用程序和服务器构件分别运行在不同的计算机上，系统中每台服务器都可以适合各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小。
3. 在C/S体系结构中，系统中的功能构件充分隔离，客户应用程序的开发集中于数据的显示和分析，而数据库服务器的开发则集中于数据的管理，不必在每一个新的应用程序中都要对一一个DBMS进行编码。将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用。

C/S软件体系结构的缺点

1. 开发成本较高一对客户端软硬件配置要求较高，随软件的升级，硬件成本更高。
2. 客户端程序设计复杂
3. 信息内容和形式单一一从DB得到的只是单纯的字符和数字。
4. 用户界面风格不一，使用繁杂，不利于推广使用
5. 软件移植困难一不同开发工具或平台开发的软件，互不兼容。
6. 软件维护和升级困难每个客户端的软件都需要维护，一个改则全都要改。
7. 新技术不能轻易应用软件平台和开发工具

四、三层客户/服务器风格

三层客户/服务器体系结构示意图

新增加了应用服务器，将整个应用逻辑驻留在
服务器上而只有表示层存在于客户机上

三层客户/服务器体系结构处理流程：

三层客户/服务器体系结构物理结构：

一般采用(1)或(2)(3)的客户机负荷太重，性能变差

三层客户/服务器风格优点

1. 允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，能提高系统和软件的可维护性和可扩展性。
2. 允许更灵活有效地选用相应的平台和硬件系统，可以具有良好的可升级性和开放性。
3. 应用的各层可以并行开发，各层可以选择各自最适合的开发语言。
4. 利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，为严格的安全管理奠定了坚实的基础。

三层客户/服务器风格缺点

1. 三层C/S结构各层间的通信效率若不高，即使分配给各层的硬件能力很强，其作为整体来说也达不到所要求的性能。
2. 设计时必须慎重考虑三层间的通信方法、通信频度及数据量。这和提高各层的独立性一样是三层C/ S结构的关键问题。

五、浏览器/服务器风格

浏览器/服务器风格的基本概念：

浏览器/服务器(B/S)风格就是上述三层应用结构的一种实现方式，其具体结构为:浏览器/Web服务器/数据库服务器。

B/S体系结构主要是利用不断成熟的WWW浏览器技术，结合浏览器的多种脚本
语言，用通用浏览器就实现了原来需要复杂的专用软件才能实现的强大功能，
并节约了开发成本。从某种程度上来说，B/ S结构是一种全新的软件体系结构。

B/S模式的体系结构：

B/S结构中，应用程序以网页形式存放于Web服务器上，用户只需在客户端浏览器中输入相应网址，调用Web服务器上的应用程序，对DB数据进行处理，将结果在浏览器上显示给用户。

B/S体系结构的优点

1. 基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。
2. B/S体系结构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。

B/ S体系结构的缺点：

1. B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
2. B/S体 系结构的系统扩展能力差，安全性难以控制。
3. 采用B/S体 系结构的应用系统，在数据查询等响应速度上，要远远地低于C/S体系结构。
4. B/S体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(OLTP)。

六、公共对象请求代理体系结构

对象管理结构：

1991年OMG提出了以对象请求代理(ORB)
为中心的对象管理结构，如下图所示:

上图中:
通用服务:实现一些通用功能

• 对象服务:实现基本的对象创建和管理
• 对象请求代理:是关键的通信机制，处理对象间的消息分布
• 针对ORB, 0MG进一步提出了CORBA技术规范，详细如下。

CORBA技术规范包括的内容:

1. 接口定义语言(IDL)
2. z接口池(IR)
3. 动态调用接口(DII)
4. 对象适配器(0A)

CORBA技术规范:

1. 接口定义语言(IDL)
   IDL语言是CORBA规范中定义的一种中性语言，它用来描述对象的接口，而不涉及对象的真体实现。
   在CORBA中定义了IDL语言到C、C++、和Java语言的映射。

2. 接口池(IR)
   CORBA的接口池包括了分布计算环境中所有可用的服务器对象的接口表示。它使动态搜索可用服务的接口、动态构造请求及参数成为可能。

3. 动态调用接口(DII )
   CORBA的动态调用接口提供了一些标准函数以供客户对象动态创建请求、动态构造请求参数。客户对象将动态调用接口与接口池配合使用可实现服务对象接口的动态搜索、请求及参数的动态构造与动
   态发送。当然，只要客户对象在编译之前能够确定服务器对象的IDL接口，CORBA也允许客户对象使用静态调用机制。显然，静态机制的灵活性虽不及动态机制，但执行效率却胜过动态机制。

4. 对象适配器(0A)
   在CORBA中，对象适配器用于屏蔽ORB内核的实现细节为服务器对象的实现者提供抽象接口，以便他们使用ORB内部的某些功能。这些功能包括服务器对象的登录与激活、客户请求的认证等

CORBA定义了一种面向对象的软件构件构造方法，使不同应用可以共享由此构造的软件构件。
CORBA的平台无关性实现对象的跨平台引用CORBA的语言无关性开发人员可以相互利用其他人员的成果、技能。

CORBA体系结构的组成:

CORBA的设计词汇表=[构件: :=客户机系统/服务器系统/其它构件;连接件::=请求/服务]
其中客户机系统包括:

• 构件(客户机应用程序、客户桩、上下文对象、接口仓库)
• 连接件(桩类型激发API、动态激发API)

服务器系统包括:

• 构件(服务器应用程序方法库、服务器框架、对象请求代理)
• 连接件(对象适配器)

CORBA体系结构模式图:

工作过程:
客户机应用程序用桩类型激发API或动态激发AP向服务器发出请求，服务器端接受方法调用请求，设置需要的上下文状态，激发服务器框架中的方法调度器，引导输出参数，并完成激发。此时客户机系统是独立于服务器系统的。

特点:

1. 引入中间件作为事务代理，完成客户机向服务对象方提出的业务请求。(是最突出的特点)
2. 实现客户与服务对象的完全分开，客户不需要了解服务对象的实现过程以及具体位置。
3. 提供软总线机制，使得在任何环境下、采用任何语言开发的软件只要符合接口规范的定义，均能够集成到分布式系统中。
4. CORBA规范软 件系统采用面向对象的软件实现方法开发应用系统，实现对象内部细节的完整封装，保留对象方法的对外接口定义。

七、正交体系结构风格

概念
正交软件体系结构由组织层和线索的构件构成。层是由一组具有相同抽象级别的构件构成。线索是子系统的特例，它是由完成不同层次功能的构件组成(通过相互调用来关联)，每一条线索完成整个系统中相对独立的一部分功能。每一条线索的实现与其他线索的实现无关或关联很少，在同一层中的构件之间是不存在相互调用的。如果线索是相互独立的，即不同线索中的构件之间没有相互调用，那么这个结构就是完全正交的。

框架：

特征

1. 正交软件体系结构由完成不同功能的n (n > 1)个线索(子系统)组成;
2. 系统具有m (m > 1)个不同抽象级别的层;
3. 线索之间是相互独立的(正交的) ;
4. 系统有一个公共驱动层般为最高层)和公共数据结构(般为最低层)。

优点

• 结构清晰，易于理解。由于线索功能相互独立，不进行互相调用，结构简单、清晰，构件在结构图中的位置已经说明它所实现的是哪一级抽象，担负的是什么功能。
• 易修改，可维护性强。由于线索之间是相互独立的，所以对一个线索的修改不会影响到其他线索。系统功能的增加或减少，只需相应的增删线索构件族，而不影响整个正交体系结构，因此能方便地实现结构调整。
• 可移植性强，重用粒度大。因为正交结构可以为一个领域内的所有应用程序所共享，这些软件有着相同或类似的层次和线索，可以实现体系结构级的重用。

八、基于层次消息总线的体系结构风格

基于层次消息总线的体系结构风格概述：
层次消息总线(HMB) 体系结构是由北大杨英清院士等人提出的，其示意图如下:

它支持构件的分布和并发。构件间通过消息总线进行通信。

在上图中:
构件:构件根据需要发出消息，由消息总线把该消息分派到系统中对此消息感兴趣的构件，构件接收到消息后，根据自身状态进行响应，通过消息总线返回处理结果。消息总线:负责消息的分派、传递和过滤，以及处理结果的返回。整个结构是分层次的树状结构，其叶子结点又叫原子构件(不可再包含子构件)。

1. HMB风格的构件模型

它包括:

• 接口
  接口部分:一个构件有多个不同接口，每个接口定义了一组输入和输出消息。构件通过接口定义了同外界的信息传递和承担的系统责任。

• 静态结构
  结构部分:复合构件的内部结构定义。

• 动态行为
  行为部分:用带输出的有限状态自动机来刻画构件的行为，当构件接收到外来的消息后，根据当前所处状态对消息进行相应，并可能导致状态的变迁。

2. 构件接口
   它代表了构件同环境的全部交互内容，也是唯的交互途径。

• HMB风格的构件接口是一种基于消息的互联接口，可以较好地支持体系结构设计。构件之间通过消息进行通讯，接口定义了构件发出和接收的消息集合。

构件发出的消息:通知系统中其它构件某个事件的发生或请求其它构件的服务。
构件接收的消息:对系统中某个事件的响应或提供其他构件所需的服务。

• 当某个事件发生后，系统或构件发出相应的消息，消息总线负责把该消息传递到此消息感兴趣的构件。
• 按照响应方式的不同，消息可分为同步消息和异步消息。

同步消息:消息的发送者必须等待消息处理结果返回才可继续运行。如:过程调用
异步消息:不必等待。如:信号、时钟、异步过程

3. 消息总线的结构图
   

• 消息登记:
  构件需要向消息总线登记当前响应的消息集合，响应者只对消息的类型感兴趣，不关心是谁发的消息。
• 消息过滤:
  对特定的消息进行过滤和阻塞。特定消息是指同一消息在不同构件中使用了不同名字，或不同消息使用了相同名字;它们会造成构件集成时消息冲突或不匹配。
• 构件消息响应登记表:
  构件向消息总线登记感兴趣的消息，得到此表，消息总线定位并发送该消息给相应的响应者，并负责返回结果。

4. 构件静态结构
   系统/复合构件的静态结构示意图如下:
   

5. 构件动态行为

• 构件的行为就由外来消息的类型唯一确定即一个消息和构件的某个操作之间存在着固定的对应关系。对于这类构件可以认为构件只有一个状态，或者在每次对消息响应之前，构件处于初始状态

• 更通常的情况是，构件的行为同时受外来消息类型和自身当前所处状态的影响。

6. 运行时刻的系统演化

主要体现在下面3个方面:

(1)动态增加或删除构件
当系统功能扩充时、系统功能裁减时和新版本代替旧版本时，都要进行此操作。

接口中定义的输入、输出刻画了它的责任，构件彼此不知道对方的存在，因此只要保持接口不变，构件可方便的替换。

增加一个构件时，只需向系统登记其感兴趣的消息即可。

删除时可能会出现某些消息没有构件响应的异常情况。
解决方法:
①阻止这些消息
②先让其它构件增加对该消息的响应，然后再删除。

(2)动态改变构件响应的消息类型
此时应通过消息总线对发生的改变进行重新登记。

(3)消息过滤
解决某些构件集成时的不匹配问题。

九、异构结构风格

为什么要使用异构结构？

• 不同的结构有不同的处理能力的强项和弱点，一个系统的体系结构应该根据实际需要进行选择，以解决实际问题。
• 关于软件包、框架、通信以及其他一些体系结构上的问题，目前存在多种标准。即使在某段时间内某一种标准 占统治地位，但变动最终是绝对的。
• 实际工作中，我们总会遇到一些遗留下来的代码，它们仍有效用，但是却与新系统有某种程度上的不协调。然而在许多场合，将技术与经济综合进行考虑时，总是决定不再重写它们。
• 即使在某-单位中，规定了共享共同的软件包或相互关系的一些标准，仍会存在解释或表示习惯上的不同。

C/S与B/ S混合软件体系结构有2种模型:

1. 内外有别
   

2. 查改有别
   

凡执行维护和修改数据的操作，
就使用C/S结构，若只执行-般查询和浏览操作的，则使用B/S结构。

优点:体现了B/S与C/S的共同优点。
缺点:外部用户可直接访问数据库服务器，故企业数据易暴露，安全性差。

变电综合信息管理系统(TSMIS) 软件体系结构图如下:

十、互连系统构成的系统结构风格

互连系统构成的系统(SIS)

系统由若干个不同部分组成，每部分作为单独的系统独立开发。整个系统通过-组互连系统实现，互连系统之间相互通信。

其中有一个系统是体现整体性能的，称为上级系统。其余系统代表整体的一部分，称为从属系统。

基于SASIS的软件过程
互连系统构成的系统的软件体系结构(SASIS)

一旦上级系统经历过至少一次迭代，而从属系统的接口相对稳定，则从属系统软件过程即可开始。上级系统和从属系统可以使用相同的软件过程进行开发。

其软件过程如下图:

1. 系统分解
   (1)根据系统的规模进行分解，将问题分解成小问题。
   (2)若系统可以由若干个物理上独立的系统组成，则可分解为由互连系统构成的系统。

分解时，可以分解为2级，也可分解成多级，但要适度分解。过度分解会导致资源管理困难，项目难以协调。

2. 用例建模
   为每个系统(上级、从属)建立一个用例模型，上级系统的高级用例可以分解到子系统上，每个“分块”将成为从属系统模型中的一个用例。

3. 分析和设计
   是极其重要的，为了获得一个健壮的系统体系结构。

过程包括:标识构件、选择体系结构风格、映射构件、分析构件相互作用和产生体系结构。

4. 实现
   上级系统只执行一 些原型设计工作， 而从属系统主要完成构件的开发和测试工作。

5. 测试
   组装不同的从属系统时的集成测试，每个上级系统是否通过互连系统获得执行。

6. 演化和维护
   当从属系统需求变化时，不必开发新上级系统，只需对其内部变更，不影响其它从属系统。

SASIS的应用范围：

1. 分布式系统
2. 很大或很复杂的系统
3. 综合几个业务领域的系统
4. 重用其它系统的系统
5. 系统的分布式开发

十一、特定领域软件体系结构

特定领域软件体系结构（DSSA）的定义

对DSSA研究的角度和关心的问题不同，
对DSSA的定义不同:

• Hayes- Roth对DSSA的定义如下:“DSSA就是专用于一-类特定类型的任务(领域)的、在整个领
  域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合”

• Tracz的定义为:“DSSA就 是一个特定的问题领域中支持组应用的领域模型、参考需求、参考体系结构等组成的开发基础，其目标就是支持在一一个特定领域中多个应用的生成”

DSSA必须具备的特征:
(1)一个严格定义的问题域/解决域
(2)具备普遍性
(3)对整个领域的合适程度的抽象
(4)具备该领域固定的、典型的在开发过程中可重用元素

从功能覆盖范围角度DSSA有下面2种理解:

• 垂直域:定义了一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软 件体系结构。
• 水平域:定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统族的特定部分功能，无法为系统提供完整的通用体系结构。

DSSA的基本活动
实施DSSA的过程中包含的3个基本活动:

1. 领域分析
2. 领域设计
3. 领域实现

此过程是一个反复的、逐步求精的过程

1. 领域分析

目标是:获得领域模型。

领域模型:描述领域中系统之间的共同需求的，把它称为领域需求。要确定哪些需求是被领域中的系统广泛共享的，从而建立领域模型。

领域分析机制图如下所示:

2. 领域设计
   目标是:获得DSSA。

它不是单个系统的表示，而是能够适应领域中多个系统需求的一个高层次的设计。
3. 领域实现
目标是:依据领域模型和DSSA开发，组织可重用信息。

这个阶段可以看做是重用基础设施的实现阶段。

DSSA的建立过程
DSSA的建立过程分5个阶段，
每个阶段包括: 一组需要回答的问题、一组需要的输入、一组将产生的输出

验证标准：
(1)定义领域范围:确定什么在感兴趣的领域中以及本过程到何时结束。
(2)定义领域特定的元素:编译领域字典和领域术语的同义词词典。识别领域中应用间的共同性和差异性;
(3)定义领域特定的设计和实现需求约束:描述解空间中有差别的特性。不仅要识别出约束，并且要记录约束对设计和实现决定造成的后果，还要记录对处理这些问题时产生的所有问题的讨论;
(4)定义领域模型和体系结构:产生- -般的体系结构，并说明构成它们的模块或构件的语法和语义;
(5)产生、搜集可重用的产品单元:为DSSA增加构件使得它可以被用来产生问题域中的新应用。

该建立过程是并发的递归的和反复的

DSSA的三层次系统模型

DSSA的建立人员要求对特定领域(包括问题域和解决域)必须精通，他们要找到合适的抽象方式，来实现DSSA的通用性和可重用性。

DSSA和体系结构风格的比较
因为研究的出发点不同，下面从5个方面进行比较:

1. DSSA以问题域为出发点，体系结构风格以解决域为出发点。
2. DSSA只对某 一个领域进行设计专家知识的提取、存储和组织，但可以同时使用多种体系结构风格;而在某个体系结构风格中进行体系结构设计专家知识的组织时，可以将提取的公共结构和设计方法扩展到多个应用领域。
3. DSSA通常选用一个或多个适合所研究领域的体系结构风格，并设计一个该领域专用的体系结构分析设计工具。
4. 体系结构风格的定义和该风格应用的领域是直交的，提取的设计知识比用DSSA提取的设计专家知识的应用范围要广
5. DSSA和体系结构风格是互为补充的两种技术。