【软件体系结构】软件体系结构的风格

软件体系结构风格的定义：

• 软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。

• 体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。

• 体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

1. 经典软件体系结构风格

1.1 管道与过滤器

每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。

这里的构件被称为过滤器，这种风格的连接件就像是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。

• 风格优点：

  1. 使得软构件具有良好的隐蔽性和高内聚、低耦合的特点。

  2. 允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成。

  3. 支持软件重用。只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来。

  4. 系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉。

  5. 允许对一些如吞吐量、死锁等属性的分析。

  6. 支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行。

• 风格缺点：

  1. 通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。

  2. 不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重。

  3. 因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。

1.2 数据抽象和面向对象组织

这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。

这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，因为它负责保持资源的完整性。

对象是通过函数和过程的调用来交互的。

• 风格优点：

  1. 因为对象对其它对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其它的对象。

  2. 设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。

• 风格缺点：

  1. 为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象。

  2. 必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。

例如，如果A使用了对象B，C也使用了对象B，那么，C对B的使用所造成的对A的影响可能是料想不到的。

1.3 基于事件的隐式调用

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

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

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

• 风格优点：

  1. 为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。

  2. 为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其它构件的接口。

• 风格缺点：

  1. 构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被 调用的顺序。

  2. 数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题。

  3. 既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。

1.4 分层系统

层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。

这种风格支持基于可增加抽象层的设计。允许将一个复杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件重用提供了强大的支持。

• 风格优点：

  1. 支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解。

  2. 支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层。

  3. 支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。

• 风格缺点：

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

  2. 很难找到一个合适的、正确的层次抽象方法。

1.5 仓库系统及知识库

在仓库风格中，有两种不同的构件：

1. 中央数据结构说明当前状态；

2. 独立构件在中央数据存贮上执行；

3. 仓库与外构件间的相互作用在系统中会有大的变化。

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

1.6 C2风格

系统中的构件和连接件都有一个顶部和一个底部；

构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；

一个连接件可以和任意数目的其它构件和连接件连接；

当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

• 风格特点：

  1. 系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起；

  2. 所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的；

  3. 构件相对独立，构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设。

2. 客户/服务器风格

产生背景：

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

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

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

C/S体系结构有三个主要组成部分：数据库服务器、客户应用程序和网络。

• 服务器负责有效地管理系统的资源，其任务集中于一下几项：

  1. 数据库安全性的要求；

  2. 数据库访问并发性的控制；

  3. 数据库前端的客户应用程序的全局数据完整性规则；

  4. 数据库的备份与恢复。

• 客户应用程序的主要任务：

  1. 提供用户与数据库交互的界面；

  2. 向数据库服务器提交用户请求并接收来自数据库服务器的信息；

  3. 利用客户应用程序对存在于客户端的数据执行应用逻辑要求。

• 风格优点：

  1. C/S 体系结构具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。

  2. 系统的客户应用程序和服务器构件分别运行在不同的计算机上，系统中每台服务器都可以适合各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小。

  3. 在C/S体系结构中，系统中的功能构件充分隔离，客户应用程序的开发集中于数据的显示和分析，而数据库服务器的开发则集中于数据的管理，不必在每一个新的应用程序中都要对一个DBMS进行编码。

将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用。

• 风格缺点：

  1. 开发成本较高；

  2. 客户端程序设计复杂；

  3. 信息内容和形式单一；

  4. 用户界面风格不一，使用繁杂，不利于推广使用；

  5. 软件移植困难；

  6. 软件维护和升级困难；

  7. 新技术不能轻易应用。

3. 三层C/S体系结构风格

两层C/S体系结构的局限性：

1. 两层C/S体系结构是单一服务器且以局域网为中心的,因此难以扩展至大型企业广域网或Internet。

2. 软、硬件的组合及集成能力有限。

3. 客户机的负荷太重,难以管理大量的客户机,系统的性能容易变坏。

4. 数据安全性不好。因为客户端程序可以直接访问数据库服务器,那么,在客户端计算机上的其他程序也可想办法访问数据库服务器,从而使数据库的安全性受到威胁。

三层C/S体系结构中，增加了一个应用服务器。将整个应用逻辑驻留在应用服务器上，只有表示层存在于客户机上，这种结构被称为瘦客户机。

3.1 各层的功能

表示层：

• 表示层是应用的用户接口部分，它担负着用户与应用间的对话功能。

• 它用于检查用户从键盘等输入的数据，显示应用输出的数据。

• 为使用户能直观地进行操作，一般要使用图形用户界面，操作简单，易学易用。

• 在变更用户界面时，只改写显示控制和数据检查程序，而不影响其他两层。检查的内容也只限于数据的形式和取值的范围，不包括有关业务本身的处理逻辑。

功能层：

• 功能层相当于应用的本体，它是将具体的业务处理逻辑编入程序。

例如，在制作订购合同时要计算合同金额，按照定好的格式配置数据、打印订购合同，而处理所需的数据则要从表示层或数据层取得。

• 表示层和功能层之间的数据交往要尽可能简捷。

例如用户检索数据时，要设法将有关检索要求的信息一次性地传送给功能层；而由功能层处理过的检索结果数据也一次性地传送给表示层。

• 通常，在功能层中包含确认用户对应用和数据库存取权限的功能以及记录系统处理日志的功能。功能层的程序多半是用可视化编程工具开发的，也有使用COBOL和C语言的。

数据层：

• 数据层就是数据库管理系统，负责管理对数据库数据的读写。

• 数据库管理系统必须能迅速执行大量数据的更新和检索。

• 现在的主流是关系型数据库管理系统(RDBMS)，因此一般从功能层传送到数据层的要求大都使用 SQL。

三层C/S的解决方案：

• 对这三层进行明确分割，并在逻辑上使其独立。原来的数据层作为数据库管理系统已经独立，所以，关键是要将表示层和功能层分离成各自独立的程序，并且还要使这两层间的接口简洁明了。

风格优点：

1. 允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，能提高系统和软件的可维护性和可扩展性。

2. 允许更灵活有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性。

3. 应用的各层可以并行开发，可以选择各自最适合的开发语言。

4. 利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，为严格的安全管理奠定了坚实的基础。

风格缺陷：

1. 三层C/S结构各层间的通信效率若不高，即使分配给各层的硬件能力很强，其作为整体来说也达不到所要求的性能。

2. 设计时必须慎重考虑三层间的通信方法、通信频度及数据量。这和提高各层的独立性一样是三层C/S结构的关键问题。

4. 浏览/服务器风格

浏览器/服务器（B/S）风格就是三层应用结构的一种实现方式，其具体结构为：浏览器 → Web服务器 → 数据库服务器。

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

从某种程度上来说，B/S结构是一种全新的软件体系结构。

• 风格优点：

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

  2. B/S体系结构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。

• 风格缺点：

  1. B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。

  2. B/S体系结构的系统扩展能力差，安全性难以控制。

  3. 采用B/S体系结构的应用系统，在数据查询等响应速度上，要远远地低于C/S体系结构。

  4. B/S体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(OLTP)应用。

5. 公共对象请求代理体系结构

CORBA是由OMG制定的一个工业标准,其主要目标是提供一种机制,使得对象可以透明地发出请求和获得应答,从而建立一个异质的分布式应用环境。

5.1 CORBA技术规范

接口定义语言：

• CORBA利用IDL统一地描述服务器对象（向调用者提供服务的对象）的接口。

• IDL本身也是面向对象的。它虽然不是编程语言，但它为客户对象（发出服务请求的对象）提供了语言的独立性，因为客户对象只需了解服务器对象的IDL接口，不必知道其编程语言。

• IDL语言是CORBA规范中定义的一种中性语言，它用来描述对象的接口，而不涉及对象的具体实现。

• CORBA中定义了IDL语言到 C、C++、Small Talk和 Java 语言的映射。

接口池：

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

动态调用接口：

• CORBA的动态调用接口提供了一些标准函数以供客户对象动态创建请求、动态构造请求参数。

• 客户对象将动态调用接口与接口池配合使用可实现服务器对象接口的动态搜索、请求及参数的动态构造与动态发送。

• 当然，只要客户对象在编译之前能够确定服务器对象的IDL接口，CORBA也允许客户对象使用静态调用机制。显然，静态机制的灵活性虽不及动态机制，但执行效率却胜过动态机制。

对象适配器：

• 在CORBA中，对象适配器用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用ORB内部的某些功能。

• 这些功能包括服务器对象的登录与激活、客户请求的认证等。

CORBA结构体系：

风格特点：

1. 引入中间件作为事务代理，完成客户机向服务对象方提出的业务请求。

2. 实现客户与服务对象的完全分开，客户不需要了解服务对象的实现过程以及具体位置。

3. 提供软总线机制，使得在任何环境下、采用任何语言开发的软件只要符合接口规范的定义，均能够集成到分布式系统中。

4. CORBA规范软件系统采用面向对象的软件实现方法开发应用系统，实现对象内部细节的完整封装，保留对象方法的对外接口定义。

6. 正交软件体系结构

正交软件体系结构由组织层和线索的构件构成。

• 层是由一组具有相同抽象级别的构件构成。

• 线索是子系统的特例，它是由完成不同层次功能的构件组成（通过相互调用来关联），每一条线索完成整个系统中相对独立的一部分功能。

• 每一条线索的实现与其他线索的实现无关或关联很少，在同一层中的构件之间是不存在相互调用的。

如果线索是相互独立的，即不同线索中的构件之间没有相互调用，那么这个结构就是完全正交的。

结构特征：

1. 正交软件体系结构由完成不同功能的n（n > 1）个线索（子系统）组成；

2. 系统具有m（m > 1）个不同抽象级别的层；

3. 线索之间是相互独立的（正交的）；

4. 系统有一个公共驱动层（一般为最高层）和公共数据结构（一般为最低层）。

结构优点：

1. 结构清晰，易于理解。

   正交软件体系结构的形式有利于理解。由于线索功能相互独立，不进行互相调用，结构简单、清晰，构件在结构图中的位置已经说明它所实现的是哪一级抽象，担负的是什么功能。

2. 易修改，可维护性强。

   线索之间相互独立,对一个线索的修改不会影响其他线索。因此,当软件需求发生变化时,可以将新需求分解为独立的子需求,然后以线索和其中的构件为主要对象分别对各个子需求进行处理,这样软件修改就很容易实现。系统功能的增加或减少,只需相应的增删线索构件族,而不影响整个正交体系结构,因此能方便地实现结构调整。

3. 可移植性强，重用粒度大。

   正交结构可以为一个领域内的所有应用程序所共享,因此这些软件有着相同或类似的层次和线索,可以实现体系结构级的重用。

7. 基于层次消息总线的体系结构风格

层次消息总线(Hierarchy Message Bus，HMB)体系结构风格是北京大学杨芙清院士等提出的一种风格,该体系结构风格的提出基于以下的实际背景：

1. 随着计算机网络技术的发展，特别是分布式构件技术的日渐成熟和构件互操作标准的出现，如CORBA、DCOM、EJB等，加速了基于分布式构件的软件开发趋势。具有分布和并发特点的软件系统已成为一种广泛的应用需求。

2. 基于事件驱动的编程模式已在图形用户界面程序设计中获得广泛应用。在此之前的程序设计中，通常使用一个大的分支语句控制程序的转移，对不同的输人情况分别进行处理，程序结构不甚清晰。基于事件驱动的编程模式在对多个不同事件响应的情况下，系统自动调用相应的处理函数,程序具有清晰的结构。

3. 计算机硬件体系结构和总线的概念为软件体系结构的研究提供了很好的借鉴和启发，在统一的体系结构框架下(即总线和接口规范)，系统具有良好的扩展性和适应性。任何计算机厂商生产的配件，甚至是在设计体系结构时根本没有预料到的配件，只要遵循标准的接口规范，都可以方便地集成到系统中，对系统功能进行扩充，甚至是即插即用（即运行时刻的系统演化）。

7.1 构件模型

7.2 构件接口

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

• 当某个事件发生后，系统或构件发出相应的消息，消息总线负责把该消息传递到此消息感兴趣的构件。

• 按照响应方式的不同，消息可分为同步消息和异步消息。

• 消息是关于某个事件发生的信息，上述接口定义中的消息分为以下两类。

  1. 构件发出的消息：通知系统中其他构件某个事件的发生或请求其他构件的服务。

  2. 构件接收的消息：对系统中某个事件的响应或提供其他构件所需的服务。接口中的每个消息定义了构件的一个端口,具有互补端口的构件可以通过消息总线进行通信。互补端口指的是除了消息进出构件的方向不同之外,消息名称、消息带有的参数和返回结果的类型完全相同的两个端口。

7.3 消息总线

HMB风格的消息总线是系统的连接件。

构件向消息总线登记感兴趣的消息，形成构件消息响应登记表。消息总线根据接收到的消息类型和“构件 - 消息”响应登记表的信息，定位并传递该消息给相应的响应者，并负责返回处理结果。

必要时，消息总线还对特定的消息进行过滤和阻塞。

消息登记：

• 在基于消息的系统中，构件需要向消息总线登记当前响应的消息集合。

• 消息响应者只对消息类型感兴趣，通常并不关心是谁发出的消息。

• 在HMB风格的系统中，对挂接在同一消息总线上的构件而言，消息是一种共享的资源，构件-消息响应登记表记录了该总线上所有构件和消息的响应关系。

• 类似于程序设计中的“间接地址调用”，避免了将构件之间的连接“硬编码”到构件的实例中，使得构件之间保持了灵活的连接关系，便于系统的演化。

构件接口中的接收消息集合意味着构件具有响应这些消息类型的潜力。

默认情况下，构件对其接口中定义的所有接收消息都可以进行响应。但在某些特殊的情况下，例如,当一个构件在部分功能上存在缺陷时，就难以对其接口中定义的某些消息进行正确的响应，这时应阻塞那些不希望接收到的消息。

这就是需要显式进行消息登记的原因,以便消息响应者更灵活地发挥自身的潜力。

消息分派和传递：

• 消息总线负责消息在构件之间的传递，根据构件-消息响应登记表把消息分派到对此消息感兴趣的构件，并负责处理结果的返回。

• 在消息广播的情况下，可以有多个构件同时响应一个消息，也可以没有构件对该消息进行响应。在后一种情况下，该消息就丢失了，消息总线可以对系统的这种异常情况发出警告，或通知消息的发送构件进行相应的处理。

• 实际上，构件-消息响应登记表定义了消息的发送构件和接收构件之间的一个二元关系，以此作为消息分派的依据。

• 消息总线是一个逻辑上的整体，在物理上可以跨越多个机器,因此挂接在总线上的构件也就可以分布在不同的机器上，并发运行。

• 由于系统中的构件不是直接交互，而是通过消息总线进行通信，因此实现了构件位置的透明性。

• 根据当前各个机器的负载情况和效率方面的考虑，构件可以在不同的物理位置上透明地迁移，而不影响系统中的其他构件。

消息过滤：

• 消息总线对消息过滤提供了转换和阻塞两种方式。

• 消息过滤的原因主要在于不同来源的构件事先并不知道各自的接口，因此可能同一消息在不同的构件中使用了不同的名字，或不同的消息使用了相同的名字。

• 前面提到，对挂接在同一消息总线上的构件而言，消息是一种共享的资源，这样就会造成构件集成时消息的冲突和不匹配。

• 消息转换是针对构件实例而言的，即所有构件实例发出和接收的消息类型都经过消息总线的过滤,这里采取简单换名的方法，其目标是保证每种类型的消息名字在其所处的局部总线范围内是唯一的。

• 由简单的换名机制解决不了的构件集成的不匹配问题，如参数类型不一致等，可以才去更为复杂的包装器技术对构件进行封装。

7.4 构件静态结构

• HMB风格支持系统自顶向下的层次化分解，复合构件是由比较简单的子构件组装而成的，子构件通过复合构件内部的消息总线连接，各个层次的消息总线在逻辑功能上是一致的，负责相应构件或系统范围内消息的登记、分派，传递和过滤。

• 如果子构件仍然比较复杂可以进一步分解。

• 整个系统也可以作为一个构件，集成到更大的系统中因为各个层次的构件以及整个系统采取了统一的方式进行刻画，所以定义一个系统的同时也就定义了一组“系统”，每个构件都可看作一个独立的子系统。

7.5 构件动态行为

• 构件的行为就由外来消息的类型唯一确定，即一个消息和构件的某个操作之间存在着固定的对应关系。

• 对于这类构件，可以认为构件只有一个状态，或者在每次对消息响应之前，构件处于初始状态。

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

7.6 运行时刻的系统演化

HMB风格方便地支持运行时刻的系统演化,主要体现在动态增加或删除构件、动态改变构件响应的消息类型和消息过滤3个方面。

• 动态增加或删除构件 在HMB风格的系统中，构件接口中定义的输入和输出消息刻画了一个构件承担的系统责任和对外部环境的要求。

• 构件之间通过消息总线进行通信，彼此并不知道对方的存在。

• 因此，只要保持接口不变，构件就可以方便地替换。

• 一个构件加入系统中的方法很简单，只需要向系统登记其所感兴趣的消息即可。

• 但删除一个构件可能会引起系统中对于某些消息没有构件响应的异常情况，这时可以采取两种措施:

  1. 阻塞那些没有构件响应的消息。

  2. 首先使系统中的其他构件或增加新的构件对该消息进行响应，然后再删除相应的构件。

• 系统中可能增删改构件的情况包括以下几种：

  1. 当系统功能需要扩充时，往系统中增加新的构件。

  2. 当对系统功能进行裁减，或当系统中的某个构件出现问题时，需要删除系统中的某个构件。

  3. 用带有增强功能或修正了错误的构件新版本代替原有的旧版本。

• 动态改变构件响应的消息类型 构件可以动态地改变对外提供的服务(即接收的消息类型),这时应通过消息总线对发生的改变进行重新登记。

• 消息过滤

  利用消息过滤机制，可以解决某些构件集成的不匹配问题。

  消息过滤通过阻塞构件对某些消息的响应，提供了另一种动态改变构件对消息进行响应的方式。

8. 异构结构风格

• 不同的结构有不同的处理能力的强项和弱点，一个系统的体系结构应该根据实际需要进行选择，以解决实际问题。

• 关于软件包、框架、通信以及其他一些体系结构上的问题，目前存在多种标准。即使在某段时间内某一种标准占统治地位，但变动最终是绝对的。

• 实际工作中，我们总会遇到一些遗留下来的代码，它们仍有效用，但是却与新系统有某种程度上的不协调。然而在许多场合，将技术与经济综合进行考虑时，总是决定不再重写它们。

• 即使在某一单位中，规定了共享共同的软件包或相互关系的一些标准，仍会存在解释或表示习惯上的不同。

8.1 “内外有别”模型

• 在C/S与B/S混合软件体系结构的“内外有别”模型中，企业内部用户通过局域网直接访问数据库服务器，软件系统采用C/S体系结构;

• 企业外部用户通过Internet访问Web服务器，通过Web服务器再访问数据库服务器，软件系统采用B/S体系结构。

模型优点：

• 外部用户不直接访问数据库服务器，能保证企业数据库的相对安全；

• 企业内部用户的交互性较强，数据查询和修改的响应速度较快。

模型缺点：

• 企业外部用户修改和维护数据时，速度较慢，较烦琐，数据的动态交互性不强。

8.2 “查改有别”模型

• 在C/S与B/S混合软件体系结构的“查改有别”模型中，不管用户是通过什么方式(局域网或Internet)连接到系统；

• 凡是须执行维护和修改数据操作的，均使用C/S体系结构如果只是执行一般的查询和浏览操作，则使用B/S体系结构。

• “查改有别”模型体现了B/S体系结构和C/S体系结构的共同优点。

• 但由于外部用户能直接通过Internet连接到数据库服务器，企业数据容易暴露给外部用户，给数据安全造成了一定的威胁。

在这两个模型中，只注明(外部用户)通过Internet连接到服务器，但并没有解释具体的连接方式，这种连接方式取决于系统建设的成本和企业规模等因素。

9. 互连系统构成的系统及其体系结构

9.1 互连系统构成的系统

• SIS是指系统可以分成若干不同的部分,每个部分作为单独的系统独立开发。

• 整个系统通过一组互连系统实现,而互连系统之间相互通信,行系统的职责。

• 其中一个系统体现整体性能,称为上级系统(superordinate system)；其余系统代表整体的一个部分,称为从属系统(subordinate system)。

• 从上级系统的角度来看，从属系统是子系统，上级系统独立于其从属系统，每个从属系统仅仅是上级系统模型中所指定内容的一个实现，并不属于上缓系统功能约束的一部分。

• 并不是每一个SIS系统都只能分解为三级结构，需要根据系统的规模进行分解，可以只分解为两级结构。

• 如果要开发的系统规模很大，可能需要进一步划分从属系统，形成多级结构的SIS系统。

• 从属系统可以自成一个软件系统，脱离上级系统而运行，有其自己的软件生命周期。在生命周期内的所有活动中都可以单独管理，可以使用不同的开发流程来开发各个从属系统，常用的系统开发过程也可应用于SIS系统，可以将上级系统与从属系统的实现分离通过把从属系统插入由互连系统构成的其他系统，就很容易使用从属系统来实现其上级系统。

• 在SIS系统中，要注意各从属系统之间的独立性，在上级系统的设计模型中，每个从属系统实现一个子系统。子系统依赖于彼此的接口，但相互之间是相对独立的。

• 因此，当某从属系统的需求发生变化时，不必开发新版本的上级系统，只需要对该从属系统内部构件进行变更，不会影响其他从属系统。只有在主要功能变更时才要求开发上级系统的新版本。

9.2 基于SASIS的软件过程

系统分解：

• 开发基于SASIS的系统时，需要做的工作是确定如何将一个上级系统的功能分布在几个从属系统之间，每个从属系统负责一个明确定义的功能子集。也就是说，主要目标是定义这些从属系统间的接口。实现上述主要目标之后，其余工作就可以根据“分而治之”的原则，由每个从属系统独立完成。

• 一般根据系统的规模和复杂性来决定。如果系统具有相当(并没有一个固定的标准)的规模和复杂性，则可以把问题分成许多小问题，这样更容易理解。另外，如果所要处理的系统可由若干物理上独立的系统组成(例如处理遗留系统)，则也可分解为由互连系统构成的系统。

• 对一个系统进行分解时，既可分成两级结构，也可分成多级结构。

• 分解要做到适度分解，体系结构设计师需要有丰富的实践经验。过度的分解会导致资源管理困难，项目难以协调。而且，不适度地使用物理上分离的系统或者物理上分离的团队，会在很大程度上扼杀任何形式的软件重用。

• 为了降低风险，做到适度分解，需要成立一个体系结构设计师小组，负责监督整个开发工作。体系结构设计师小组应该重点关注以下问题：

  1. 适当关注从属系统之间的重用和经验共享。

  2. 对开发什么工件(构件或文档)从属系统工件与上级系统工件之间有什么关系有清晰的理解。

  3. 定义一个有效的变更管理策略，并得到所有团队的遵守。

用例建模：

• 开发人员应该为每个系统(包括上级系统和从属系统)在SIS系统中建立一个用例模型，上级系统的高级用例通常可以分解到(所有或部分)子系统上，每个“分块”将成为从属系统模型中的一个用例。

分析和设计：

• 分析和设计的目的是获得一个健壮的系统体系结构,这对SIS系统来说极其重要。

• SIS中的每个系统,包括上级系统和从属系统，都应该定义自己的体系结构，选择相应的体系结构风格。

• 分析设计的过程又可分为标识构件、选择体系结构风格、映射构件、分析构件相互作用和产生体系结构等5个子过程,

• 对于上级系统，选择体系结构风格时应考虑上级系统的关键用例或场景(scenario)、SIS的分级结构以及如何处理从属系统之间的重用和重用内容等问题。

• 对于从属系统，选择体系结构风格时应考虑从属系统在SIS系统内的角色、从属系统的关键用例或场景、从系统如何履行在SIS系统的分级结构中为它定义的职责、如何重用等问题。

• 在决定SIS系统的体系结构时,还要综合考虑以下两个问题：

  1. 软件重用。要明确哪些构件是两个以上从属系统公有的,需要建立哪些机制来允许从属系统互相通信。

  2. 所有从属系统都能使用的构件及其实现。所有从属系统都应该使用通用的通信、错误报告、容错管理机制,提供统一的人机界面。

实现：

• 在从属系统的软件过程中,实现过程主要完成构件的开发和测试工作。在上级系统的软件过程中,不必经过实现过程,而只执行一些原型设计工作,研究系统特定方面的技术。

测试：

• 测试指的是,组装不同从属系统时的集成测试,并测试每个上级用例是否根据其规约通过互连系统协作获得执行。

演化和维护：

• 在SIS系统中，各从属系统之间相对独立。

• 在上级系统的设计模型中，每个从属系统实现一个子系统。

• 子系统依赖于彼此的接口，因此，当某从属系统的需求发生变化时，不必开发新版本的上级系统，只需要对该从属系统内部构件进行变更，不会影响其他从属系统。

• 只有在主要功能变更时才要求开发上级系统的新版本。

9.3 应用范围

1. 分布式系统。

2. 很大或者很复杂的系统。

3. 综合几个业务领域的系统。

4. 重用其他系统的系统。

5. 系统的分布式开发。

10. 特定领域软件体系结构

10.1 DSSA的定义

• Hayes Roth： DSSA就是专用于一类特定类型的任务（领域）的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合。

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

DSSA的必备特征：

1. 一个严格定义的问题域和/或解决域。

2. 具有普遍性,使其可以用于领域中某个特定应用的开发。

3. 对整个领域的合适程度的抽象。

4. 具备该领域固定的、典型的在开发过程中可重用元素。

从功能角度理解DSSA：

• 垂直域：定义了一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件体系结构。

• 水平域：定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统族的特定部分功能，无法为系统提供完整的通用体系结构。

10.2 DSSA的基本活动

1. 领域分析。

   这个阶段的主要目标是获得领域模型(domain model)。

2. 领域设计。

   这个阶段的目标是获得DSSA。

3. 领域实现。

   这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。

10.3 参与DSSA的人员

• 领域专家、领域分析人员、领域设计人员、领域实现人员等。

10.4 DSSA的建立过程

1. 定义领域范围。

   本阶段的重点是确定什么在感兴趣的领域中以及本过程到何时结束。这个阶段的一个主要输出是领域中的应用需要满足一系列用户的需求。

2. 定义领域特定的元素。

   本阶段的目标是编译领域字典和领域术语的同义词词典在领域工程过程的前一个阶段产生的高层块图将被增加更多的细节，特别是识别领域中应用间的共同性和差异性。

3. 定义领域特定的设计和实现需求约束。本阶段的目标是描述解空间中有差别的特性。不仅要识别出约束,并且要记录约束对设计和实现决定造成的后果，还要记录对处理这些问题时产生的所有问题的讨论。

4. 定义领域模型和体系结构。

   本阶段的目标是产生一般的体系结构，并说明构成它们的模块或构件的语法和语义。

5. 产生、搜集可重用的产品单元。

   本阶段的目标是为DSSA增加构件使得它可以被用来产生问题域中的新应用。

DSSA的建立过程是并发的、递归的和反复进行的。该过程的目的是将用户的需要映射为基于实现约束集合的软件需求，这些需求定义了DSSA。

10.5 DSSA结构的好处

1. 相对于过去的开发方法，系统开发、维护的工作量大幅度减少，整个应用系统的构件重用程序相当大。

2. 便于系统开发的组织管理。

   在大型系统开发过程中，最突出的问题是人员的组织问题。

   采用了DSSA之后，开发中涉及核心技术的人员从15人左右下降到5人左右，其他的人力进人外围产品化的工作，如产品包装、市场销售、工具的开发、客户化服务等。而过去这方面内容在技术部门是被忽视的，而在应用软件工程中，它们也占重要的位置。

1. 系统有较好的环境适应性。

   构件的升级引发应用系统的升级，并在构件库中合理地控制粒度，使系统的总体结构设计与算法和模块化设计同等重要，并灵活地保证新、老应用系统的共存。

10.6 DSSA与体系结构风格的比较

• 在软件体系结构的发展过程中,由于研究者的出发点不同,出现了两个互相直交的方法和学科分支：以问题域为出发点的DSSA和以解决域为出发点的软件体系结构风格。两者侧重点不同，它们在软件开发中具有不同的应用特点。

• DSSA只对某一个领域进行设计专家知识的提取、存储和组织，但可以同时使用多种体系结构风格；而在某个体系结构风格中进行体系结构设计专家知识的组织时，可以将提取的公共结构和设计方法扩展到多个应用领域。

• DSSA的特定领域参考体系结构通常选用一个或多个适合所研究领域的体系结构风格，并设计一个该领域专用的体系结构分析设计工具。但该方法提取的专家知识只能用于一个较小的范围，即所在领域中。

• 不同参考体系结构之间的基础和概念有较少的共同点所以为一个领域开发DSSA及其工具在另一个领域中是不适应的或不可重用的，而工具的开发成本是相当高的。

• 体系结构风格的定义和该风格应用的领域是直交的，提取的设计知识比用DSSA提取的设计专家知识的应用范围要广。一般的、可调整的系统基础可以避免涉及特定的领域背景，所以建立一个特定风格的体系结构设计环境的成本比建立一个DSSA参考体系结构和工具库的成本要低得很多。因为对特定领域内的专家知识和经验的忽略，使其在一个具体的应用开发中所起的作用并不比DSSA大。

• DSSA和体系结构风格是互为补充的两种技术。在大型软件开发项目中基于领域的设计专家知识和以风格为中心的体系结构设计专家知识都扮演着重要的角色。

11. 补充

• 选择一个熟悉的大型软件系统，分析其体系结构中用到的风格，以及表现出的特点。(为什么要采用这种风格？采用这种风格带来哪些优势？具有哪些不足？)

  选择一个熟悉的大型软件系统进行分析，我们以“谷歌的搜索引擎”为例。谷歌搜索引擎是一个高度复杂且广泛使用的软件系统，其体系结构的设计对于其性能和可扩展性至关重要。

  体系结构风格：

  谷歌搜索引擎的体系结构主要采用了分布式系统和微服务架构的风格。

  分布式系统：

  分布式系统是指将计算任务或数据分散到多个计算机节点上，通过网络进行通信和协调，共同完成任务的计算机系统。谷歌搜索引擎通过分布式系统，将搜索请求分发到多个服务器进行处理，从而提高了系统的处理能力和响应速度。

  微服务架构：

  微服务架构是一种将应用程序构建为一组小型、自治的服务的方法，每个服务都运行在其独立的进程中，服务之间通过轻量级通信机制（通常是HTTP API）进行通信。谷歌搜索引擎通过微服务架构，将搜索功能拆分为多个独立的服务，如索引服务、查询服务、排名服务等，每个服务都可以独立开发、部署和扩展。

  特点分析：

  为什么要采用这种风格？

  1. 可扩展性：分布式系统和微服务架构使得谷歌搜索引擎能够轻松应对不断增长的用户需求和数据量。通过添加更多的服务器或服务实例，系统可以水平扩展，提高处理能力。

  2. 高可用性：通过将服务拆分为多个独立的部分，即使某个部分出现故障，其他部分仍然可以正常工作，从而提高了系统的整体可用性。

  3. 灵活性：微服务架构使得每个服务都可以独立开发、测试和部署，这提高了开发效率，并允许团队更快地响应市场变化。

  采用这种风格带来的优势？

  1. 性能提升：分布式系统和微服务架构使得谷歌搜索引擎能够并行处理大量的搜索请求，从而提高了系统的响应速度和吞吐量。

  2. 故障隔离：通过将服务拆分为多个独立的部分，系统能够更好地隔离故障，防止单个服务的故障影响到整个系统。

  3. 技术多样性：微服务架构允许团队使用不同的技术栈来构建不同的服务，这提高了系统的灵活性和可扩展性。

  具有的不足：

  1. 复杂性增加：分布式系统和微服务架构增加了系统的复杂性，需要更多的管理和监控工具来确保系统的正常运行。

  2. 通信开销：服务之间的通信需要消耗网络带宽和计算资源，这可能会增加系统的延迟和成本。

  3. 一致性挑战：在微服务架构中，保持数据和服务之间的一致性是一个挑战，需要采用适当的一致性协议和分布式事务管理策略。

  综上所述，谷歌搜索引擎通过采用分布式系统和微服务架构的风格，实现了高性能、高可用性和灵活性。然而，这种风格也带来了一定的复杂性和通信开销。在实际应用中，需要根据具体需求和场景来选择合适的体系结构风格，并采取相应的措施来应对其不足。

• 查阅相关资料，尝试从面向服务的体系结构(SOA)的实现技术的角度出发，深人分析 CORBA、DCOM 以及基于UDDI的 Web Service等分布式计算技术，在此基础上，对这些技术做比较和归纳，涉及CORBA、DCOM 和基于UDDI的Web Service 之间的互操作的方案。

  从面向服务的体系结构（SOA）的实现技术角度出发，CORBA、DCOM以及基于UDDI的Web Service等分布式计算技术各有其特点和优势。以下是对这些技术的深入分析、比较、归纳以及它们之间互操作方案的探讨。

  一、技术深入分析

  1. CORBA

     • 定义与背景：CORBA（Common Object Request Broker Architecture）是对象管理组织（OMG）提出的一种中间件解决方案，旨在实现不同软硬件产品之间的互操作。

     • 核心特性：CORBA定义了接口定义语言（IDL）和应用编程接口（API），使对象可以按照特定的对象请求代理（ORB）方式进行交互。它实现了客户端与服务器的完全分离，提供了软件总线机制，并实现了对象内部细节的完整封装。

     • 应用场景：CORBA适用于需要高度集成的企业级应用，特别是在不同语言、不同平台之间的对象互操作方面表现出色。

  2. DCOM

     • 定义与背景：DCOM（Distributed Component Object Model）是微软的分布式组件对象模型，扩展了COM（Component Object Model）以实现更高级别的分布性和可伸缩性。

     • 核心特性：DCOM允许软件组件在不同的物理位置和不同网络架构上进行交互，为跨网络的组件集成提供了标准的方式。它建立在COM技术之上，提供了远程过程调用（RPC）的机制。

     • 应用场景：DCOM在需要高度集成的业务应用中尤为适用，如金融、医疗和供应链管理等行业中，系统间的数据交换频繁，利用DCOM通信能够保证数据的一致性与实时性。

  3. 基于UDDI的Web Service

     • 定义与背景：Web Service是一种网络间跨平台、跨语言的分布式系统间通信的标准。UDDI（Universal Description, Discovery and Integration）是一种目录服务，用于对Web services进行注册和搜索。

     • 核心特性：Web Service使用XML来描述所有数据，具有通用、可交互的优势。它使用HTTP协议来传输数据，具有跨平台、跨网络的特点。UDDI规范解决了Web Service互相发现的问题，使得Web Service的应用变得更加方便和灵活。

     • 应用场景：当需要在不同的网络和平台之间搭建开放的分布式应用系统时，Web Service是最好的选择。它广泛应用于金融行业、电子商务、政府和公共服务领域以及医疗健康领域等。

  二、技术比较与归纳

  1. 通信机制

     • CORBA：基于ORB进行对象请求和响应，支持复杂的对象交互。

     • DCOM：基于RPC机制，允许软件组件在不同的物理位置和不同网络架构上进行交互。

     • Web Service：使用HTTP协议传输数据，通过SOAP、WSDL和UDDI等标准实现服务的发布、发现和集成。

  2. 跨平台与跨语言能力

     • CORBA：支持多种语言和平台，但实现复杂度较高。

     • DCOM：主要适用于Windows平台，对跨平台支持有限。

     • Web Service：具有极强的跨平台和跨语言能力，支持多种语言和平台之间的互操作。

  3. 应用场景

     • CORBA：适用于企业级应用，特别是需要高度集成的场景。

     • DCOM：适用于Windows平台上的分布式应用，特别是在需要频繁数据交换的场景中。

     • Web Service：广泛应用于不同网络和平台之间的开放分布式应用系统。

  三、互操作方案

  1. CORBA与Web Service互操作

     • 可以通过网关或路由器实现CORBA与Web Service之间的互操作。这种网关或路由器可以解析和转换CORBA和Web Service之间的消息格式和数据结构，从而实现两者之间的通信。

     • 另一种方案是使用中间件技术，如ESB（Enterprise Service Bus），来集成和协调CORBA和Web Service之间的交互。

  2. DCOM与Web Service互操作

     • 由于DCOM主要适用于Windows平台，而Web Service具有跨平台能力，因此两者之间的互操作可能需要通过特定的适配器或代理来实现。

     • 一种可能的方案是在Windows平台上开发一个DCOM到Web Service的适配器，该适配器可以接收DCOM请求并将其转换为Web Service请求，然后将请求发送到远程的Web Service提供者。

  3. 复杂数据类型传递

     • 在实现CORBA、DCOM与Web Service之间的互操作时，复杂数据类型的传递是一个重要问题。可以通过定义通用的数据格式或协议来解决这个问题，如使用XML或JSON等标准数据格式来描述复杂数据结构。

     • 另外，还可以开发专门的数据适配器或转换器来处理和转换不同系统之间的复杂数据类型。

  综上所述，CORBA、DCOM以及基于UDDI的Web Service等分布式计算技术各有其特点和优势。在实现SOA时，可以根据具体的应用场景和需求选择合适的技术。同时，通过开发适配器、网关或中间件等技术手段，可以实现这些技术之间的互操作，从而构建更加灵活、可扩展和可维护的分布式应用系统。

• 不同的体系结构风格具有各自的特点、优劣和用途。试对管道-过滤器风格、事件驱动风格、分层系统、C2风格和基于消息总线的风格进行分析比较。

  以下是对管道-过滤器风格、事件驱动风格、分层系统、C2风格和基于消息总线的风格的分析比较：

  一、管道-过滤器风格

  特点：

  • 各个构件（过滤器）有固定的输入和输出，数据流经管道从一个过滤器传递到另一个过滤器。

  • 每个过滤器独立地执行特定的转换或处理功能。

  优劣：

  • 优点：

    • 构件具有良好的隐蔽性和高内聚、低耦合的特点。

    • 支持软件重用，只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来。

    • 系统维护和增强性能简单，可以添加或替换过滤器。

    • 支持并行执行，每个过滤器可以作为一个单独的任务完成。

  • 缺点：

    • 通常导致进程成为批处理的结构，不适合处理交互的应用。

    • 在数据传输上没有通用的标准，增加了编写过滤器的复杂性，并可能导致系统性能下降。

  用途：

  • 适用于数据处理和转换流程较为清晰、固定的系统，如编译系统、图像处理系统等。

  二、事件驱动风格

  特点：

  • 系统组件通过发送和接收事件消息来进行通信。

  • 事件是系统中发生的重要状态变化或动作的通知。

  优劣：

  • 优点：

    • 组件之间松耦合交互，新加入的消费者可以订阅已有事件，无需修改原有系统。

    • 系统能够实时或近实时地对业务事件做出反应。

    • 提供审计与监控功能，事件流提供了系统的完整操作日志。

  • 缺点：

    • 需要确保事件的一致性、处理顺序和数据同步问题。

    • 过度依赖事件可能导致复杂性增加。

  用途：

  • 适用于构建高度可扩展、响应迅速且具有弹性的分布式系统，如微服务架构、实时数据流处理、物联网（IoT）系统等。

  三、分层系统

  特点：

  • 系统被划分为多个层次，每一层为上层提供服务，并作为下层客户。

  • 层次之间通过接口进行通信，每一层只能与相邻层进行交互。

  优劣：

  • 优点：

    • 支持基于抽象程度递增的系统设计。

    • 支持功能增强和重用。

    • 层次结构清晰，易于理解和维护。

  • 缺点：

    • 不是每个系统都可以很容易地划分为分层的模式。

    • 找到合适的层次抽象方法可能具有挑战性。

  用途：

  • 适用于需要明确划分不同功能层次的系统，如Web应用的三层架构（表示层、业务逻辑层、数据访问层）。

  四、C2风格

  特点：

  • 由连接件绑定的按一定规则运行的并行构件网络。

  • 构件之间不能直接连接，只能通过连接件的异步通信机制进行交互。

  优劣：

  • 优点：

    • 松耦合，上层构件对下层构件不感知，方便更新或替换下层构件。

    • 可重用，只要符合请求及响应标准，就可重用构件。

  • 缺点：

    • 若业务处理涉及多个构件层次，在系统执行过程中将存在性能损耗。

  用途：

  • 适用于需要高内聚、松耦合设计的系统，如分布式系统、实时系统等。

  五、基于消息总线的风格

  特点：

  • 系统通过消息总线进行异步通讯，实现了系统解耦。

  • 消息总线支持不同系统、应用程序之间的通信。

  优劣：

  • 优点：

    • 提高了系统的可扩展性和可维护性。

    • 异步数据处理，避免影响主流程的性能。

    • 组件之间通过消息进行通信，降低了系统间的依赖。

  • 缺点：

    • 可能带来复杂度和性能损耗的问题。

    • 需要设计合理的消息格式和通信协议。

  用途：

  • 适用于需要异步通信、解耦和可扩展性的系统，如微服务架构、分布式事件驱动系统等。

  六、总结比较

  体系结构风格	特点	优点	缺点	用途
  管道-过滤器	构件有固定的输入和输出，数据流经管道传递	隐蔽性好、高内聚低耦合、支持软件重用、支持并行执行	批处理结构、不适合交互应用、数据传输无通用标准	数据处理和转换流程清晰的系统
  事件驱动	通过发送和接收事件消息进行通信	松耦合交互、实时响应、审计与监控	需要确保事件一致性、处理顺序和数据同步	高度可扩展、响应迅速的分布式系统
  分层系统	系统划分为多个层次，层次之间通过接口通信	支持抽象设计、功能增强和重用、层次结构清晰	不是所有系统都适合分层、找到合适的抽象方法具有挑战性	需要明确划分不同功能层次的系统
  C2风格	由连接件绑定的并行构件网络，构件通过异步通信机制交互	松耦合、可重用	涉及多个构件层次时存在性能损耗	需要高内聚、松耦合设计的系统
  基于消息总线的风格	通过消息总线进行异步通讯，实现系统解耦	可扩展性、可维护性好、异步数据处理	可能带来复杂度和性能损耗	需要异步通信、解耦和可扩展性的系统

  综上所述，不同的体系结构风格各有其特点和适用场景。在选择时，需要根据系统的具体需求和目标来权衡各种风格的优缺点。

• 试说明特定领域软件体系结构包括哪些基本活动,应该如何选择参与人员及其创建过程。

  特定领域软件体系结构（DSSA）的基本活动、参与人员选择及其创建过程如下：

  一、DSSA的基本活动

  DSSA是一个反复的、逐渐求精的过程，主要分为三个阶段：领域分析、领域设计和领域实现。

  1. 领域分析

     • 主要目标：获得领域模型。领域模型描述领域中系统之间的共同需求，即领域需求。

     • 准备性活动：定义领域的边界，明确分析的对象；识别信息源，包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等。

     • 分析内容：分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的。

  2. 领域设计

     • 主要目标：获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。

     • 主要任务：依据领域模型和DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。

  3. 领域实现

     • 主要目标：获得领域实现模型。领域实现模型是对DSSA的具体实现，描述了DSSA中可重用元素的具体实现方式。

     • 主要任务：根据领域模型和DSSA，或者从头开发可重用构件，或者利用再工程的技术从现有系统中提取可重用构件，对可重用构件进行验证，建立DSSA与可重用构件间的联系。

  二、参与DSSA的人员选择

  参与DSSA的基本人员可划分为四种：领域专家、领域设计人员、领域实现人员、领域分析师。

  1. 领域专家

     • 人员构成：有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。

     • 主要任务：提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、DSSA等领域工程产品等。

     • 知识背景：熟悉该领域中系统的软件设计和实现、硬件限制、未来的用户需求及技术走向等。

  2. 领域分析人员

     • 人员构成：由具有知识背景的有经验的系统分析人员来担任。

     • 主要任务：控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中，根据现有系统、标准规范等验证领域模型的准确性和一致性，维护领域模型。

     • 知识背景：熟悉软件重用和领域分析方法；熟悉进行知识获取和知识表示所需的技术、语言和工具；具有一定的该领域的经验，以便于分析领域中的问题及与领域专家进行交互；具有较高的进行抽象、关联和类比的能力；具有较高的与他人交互和合作的能力。

  3. 领域设计人员

     • 人员构成：由有经验的软件设计人员来担任。

     • 主要任务：控制整个软件设计过程，根据领域模型和现有的系统开发出DSSA，对DSSA的准确性和一致性进行验证，建立领域模型和DSSA之间的联系。

     • 知识背景：熟悉软件重用和设计领域的方法；熟悉软件设计方法；有一定的该领域的经验，以便于分析领域中的问题及与领域专家进行交互。

  4. 领域实现人员

     • 人员构成：由有经验的程序设计人员来担任。

     • 主要任务：根据领域模型和DSSA，或者从头开发可重用构件，或者利用再工程的技术从现有系统中提取可重用构件，对可重用构件进行验证，建立DSSA与可重用构件之间的联系。

     • 知识背景：熟悉软件重用、领域实现及软件再工程技术；熟悉程序设计；具有一定的该领域的经验。

  三、DSSA的创建过程

  DSSA的建立过程是并发的（Concurrent）、递归的（Recursive）、反复的（Iterative）过程，目的是将用户的需求映射为基于实现限制集合的软件需求。DSSA的创建过程可以分为五个阶段，每个阶段可以进一步划分为一些步骤或子阶段。每个阶段包括一组需要回答的问题、一组需要的输入、一组将产生的输出和验证标准。以下是五个阶段的具体内容：

  1. 定义领域范围

     • 主要输出：领域中的应用需要满足一系列用户的需求。

     • 本阶段重点：确定什么在感兴趣的领域中以及本过程到何时结束。

  2. 定义领域特定的元素

     • 目标：编译领域字典和领域术语的同义词词典。

     • 详细程度：在领域工程过程的前一个阶段产生的高层框架将别增加更多的细节，特别是识别领域中应用间的共同性和差异性。

  3. 定义领域特定的设计和实现需求约束

     • 目标：描述解空间中有差异的特性。

  4. 定义领域模型和体系结构

     • 目标：产生一般的体系结构，并说明构成它们的模块或构件的语法和语义。

  5. 产生、搜集可重用的产品单元

     • 目标：为DSSA增加构件，使它可以被用来产生问题域中的新应用。

  综上，特定领域软件体系结构的构建是一个复杂而精细的过程，需要明确各阶段的目标和任务，选择合适的参与人员，并遵循科学的创建过程来确保体系的准确性和有效性。