第7章系统架构设计基础知识-EW帮帮网

7.1软件架构概念

7.1.1软件架构的定义

一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件，构件的外部可见属性以及它们之间的相互关系。

体系结构并非可运行软件。确切地说，它是一种表达，使软件工程师能够：

(1)分析设计在满足所规定的需求方面的有效性；

(2)在设计变更相对容易的阶段，考虑体系结构可能的选择方案；

(3)降低与软件构造相关联的风险。

7.1.2软件架构设计与生命周期

1.需求分析阶段

需求分析阶段的SA研究还处于起步阶段。在本质上，需求分析和SA设计面临的是不同的对象：一个是问题空间；另一个是解空间。保持二者的可追踪性和可转换性，一直是软件工程领域追求的目标。从软件需求模型向SA模型的转换主要关注两个问题。

1. 如何根据需求模型构建SA模型。

2. 如何保证模型转换的可追踪性。

需求分析是分析问题，SA设计是解决问题。比如需求分析要达到0.1秒的响应级别，SA设计增加服务器集群，优化代码，提高效率等等。

在需求分析阶段研究SA意义：有助于将SA的概念贯穿于整个软件生命周期，从而保证了软件开发过程的概念完整性，有利于各阶段参与者的交流，也易于维护各阶段的可追踪性。

补充：

什么是需求模型？

是通过建模语言描述软件需求的模型。需求模型包括用例模型、(功能模型)和非功能模型两部分。

在需求模型中，需要对需求结构、软件功能、软件性能等内容进行建模。需求建模建立在业务模型的基础上，它又是软件其他模型的基础，如下图，描述了需求模型与其他软件模型之间的关系。

社么是SA模型？ software Architecture

比如E-R图、数据流图等等。

SA定义：Architecture=Components+Connectors+Topology+Constraints+Performance

(软件体系结构=构件+连接件+拓扑结构+约束+质量）

2.设计阶段

SA关注最早最多阶段，这一阶段研究主要包括SA模型描述、SA模型的设计与分析方法、对SA设计经验的总结与复用。

SA模型描述3个层次：

1).SA的基本概念

有哪些元素组成以及何种原则组织，传统的只有构件和胶水代码，现在的是胶水代码这部分升级为连接子同构件地位，构件和连接子的建模。

2).体系结构描述语言ADL

支持构件、连接子及其配置的描述语言就是如今所说的体系结构描述语言。如ADL，它对连接子的重视区分于其他描述语言。

3).SA模型的多视图表示：关注点分离思想

从不同的角度描述系统的体系结构从而得到多视图，把ADL和多视图结合起来更好理解，如典型的4+1视图(b编辑视图、进程视图、开发视图、物理视图，加上统一的场景)，Hofmesiter的4视图模型(概念视图、模块视图、执行视图和代码视图)、CMU-SEI的Views and Beyond模型(模块视图、构件和连接子视图、分配视图)等。

3.实现阶段

这一阶段除了关注高层次的系统设计、描述和验证，还关注基于SA的开发过程的支持，如组织结构、配置管理等，从SA向实现过度的途径，如将程序设计语言引入SA阶段、模型映射、构件组装、复用中间件平台等，基于SA的测试技术。

基于SA的开发过程的支持，如组织结构、配置管理等。

SA提供的蓝图较好的实现开发组织结构和管理过程，对于大型系统，参与人员多，需要提供配置管理手段。

从SA向实现过度的途径，如将程序设计语言引入SA阶段、模型映射、构件组装、复用中间件平台等。

为了填补SA模型和底层实现间鸿沟，通过封装实现细节、模型转换、精华等手段缩小概念间差距，典型方法如下：

SA模型中引入实现阶段的概念，比如引入程序设计语言。---便于理解。

通过模型转换技术，将高层SA模型逐步精化成能够支持实现的模型。

封装底层的实现细节，使之成为较大粒度构件，这样SA作用就是知道组装构件和连接子来完成系统。

4.构件组装阶段

SA模型指导下，可复用构件可在较高层次上实现系统，比如在架构阶段，提高实现效率。研究的内容2方面：

如何支持可复用构件的互联，即对SA设计模型中规约的连接子的实现支持。

①设计阶段对连接子的支持：很多ADL支持在实现阶段将连接子直接转为具体的代码。

②中间件的使用，中间件有特定标准，为构件互联提供支持，还提供了其他的服务，比如安全服务、明明服务等等

组装过程中，如何消除体系结构适配问题。

失配有三方面：构件引起的(如系统对构件基础设施、控制模型、数据模型的假设存在冲突)、连接子引起的（交互协议、连接子模型假设冲突）、系统成分引起的（整体和全局的冲突）。

5.部署阶段

随着网络与分布式软件的发展，软件部署从软件开发中独立出来，成为软件生命周期中独立阶段。(比如git上的自动化部署(提交代码后自动部署)。但是分布式软件要满足一定的质量属性要求的，比如性能、可靠性，因此部署需要考虑多方面信息，如软件构件的互联性、硬件拖布结构、硬件资源占用等等。

SA对部署的作用

提供高层体系结构视图来描述部署阶段的软硬件模型。

基于SA的模型可分析部署方案，择优。

6.后开发阶段

部署安装完成后，这一阶段主要围绕维护、演化、复用等方面进行。典型的方向：动态软件体系结构、体系结构恢复与冲击等。

1.动态软件体系结构

传统软件体系结构是静态的，但是有些软件具有动态性，他们的体系结构会在运行时发生变动。

SA在运行时发生变化的两类：

1).软件内部执行导致的SA改变，比如服务器端软件根据客户请求到达时创建新的构件来响应用户请求；自适应软件根据不同的配置采用不同的连接子来传输数据。

2).软件系统外部的请求对软件的重新配置。比如安全性的软件系统，这些系统修改或升级时候不停机。

基于以上情况，就产生了如何在设计阶段捕获SA的这种动态性，并进一步指导，从塞肉实现在线演化或自适应甚至是自主计算，这就是研究的内容，两部分：

1).体系结构设计阶段的支持

主要包括变化的描述、如何根据变化生成修改策略、描述

修改过程、在高抽象层次保证修改的可行性以及分析、推理修改所带来的影响等。

2).运行时刻基础设施的支持

主要包括系统体系结构的维护、保证体系结构修改在约束

范围内、提供系统的运行时刻信息、分析修改后的体系结构符合指定的属性、正确映射体系结

构构造元素的变化到实现模块、保证系统的重要子系统的连续执行并保持状态、分析和测试运

行系统等。

2.体系结构恢复与重建

当前系统的开发很少是从头开发的，都是参照既有系统的，升级、增强或移植，但是这些既有的系统开发较早没考虑SA，也少有文档资料，从这些系统中恢复或重构体系结构是有意义和必要的。

SA重建指从既有系统中获取体系结构的过程，输出物为一组SA视图，方法4种：

1).手工SA重建

2).工具支持手工重建。

3).通过查询语言来自动建立聚集：思路是通过逆向工程工具支持下分析代码，得到结构

4).其他技术，如数据挖掘等。

7.1.3软件架构的重要性

降低成本、改进质量、按时按需交付产品的关键因素。

1.架构设计能够满足系统的品质

2.架构设计使受益人达成一致的目标

3.架构设计能够支持计划编制过程

4.架构设计对系统开发的指导性

5.架构设计能够有效地管理复杂性

6.架构设计为复用奠定了基础

7.架构设计能够降低维护费用

8.架构设计能够支持冲突分析

7.2基于架构的软件开发方法

7.2.1体系结构的设计方法概述

基于体系结构的软件设计(Architecture-Based Software Design,ABSD)方法是由体系结构驱动的，即指由构成体系结构的商业、质量和功能需求的组合驱动的。

使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，即与需求抽取和分析并行甚至在它们之前。

ABSD的3个基础：

1.功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。

2. 通过选择体系结构风格来实现质量和商业需求。

3. 软件模板的使用，软件模板利用了一些软件系统的结构。

ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，体系结构总是清晰的，这有助于降低体系结构设计的随意性。

基于体系结构的的软件设计方法，根据体系结构来设计软件的方法。

7.2.2概念与术语

1.设计元素

ABSD是一个自顶向下，递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件的构件和类。

ABSD方法中使用的设计元素如图7-1所示。在最顶层，系统被分解为若干概念子系统和一个或若干个软件模板。在第2层，概念子系统又被分解成概念构件和一个或若干个附加软件模板。

2.视角与视图

考虑体系结构时，要从不同的视角(Perspective)来观察对架构的描述，这需要软件设计师考虑体系结构的不同属性。如，展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性，因此，选择的特定视角或视图(如逻辑视图、进程视图、实现视图和配置视图)可以全方位的考虑体系结构设计。使用逻辑视图来记录设计元素的功能和概念接口，设计元素的功能定义了它本身在系统中的角色，这些角色包括功能、性能等。

3.用例和质量场景

用例已经成为推测系统在一个具体设置中的行为的重要技术，用例被用在很多不同的场合，用例是系统的一个给予用户一个结果值的功能点，用例用来捕获功能需求。

在使用用例捕获功能需求的同时，人们通过定义特定场景来捕获质量需求，并称这些场景为质量场景。这样一来，在一般的软件开发过程中，人们使用质量场景捕获变更、性能、可靠性和交互性，分别称之为变更场景、性能场景、可靠性场景和交互性场景。质量场景必须包括预期的和非预期的场景。

例如，一个预期的性能场景是估计每年用户数量增加10??影响，一个非预期的场景是估计每年用户数量增加100??影响。

非预期场景可能不会真正实现，但它们在决定设计的边界条件时很有用。

7.2.3基于体系结构的开发模型

传统的软件开发过程可从概念到实现若干阶段，按照传统的开发模型，软件体系结构的建立应在需求分析之后，概要设计之前。但它的缺点是效率不高，不能很好的支持软件重用等缺点。

ABSD模型把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化6个子体系结构实现过程。

7.2.4体系结构需求

体系结构开发模型第一阶段：体系结构需求获取。

体系结构需求受技术环境和体系结构设计师的经验影响。需求过程主要是获取用户需求，标识系统中所要用到的构件。

1.需求获取

来源：3个方面，系统的质量目标、系统的商业目标、系统开发人员的商业目标。

体系结构需求获取过程：主要是定义开发人员必须实现的软件功能，使得用户能完成他们的任务，满足业务上的功能需求；同时还得获得软件质量属性，满足一些非功能需求。

2.标识构件

为系统生成初始逻辑结构，包含大致的构件。

标识构件3步：

1).生成类图：这步可用工具，如 Rational Rose 2000。

2).对类分组：在类图基础上根据一些标准对它们分组可大大简化结构，使之更清晰。一般的，与其他类隔离的形成一个组，概括关联的类组成一个附加组，聚合或合成关联的类也形成一个附加组。

3).把类打包成构件：把上一步得到的类簇打包成构件，这些构件分组合并成更大的构件。

3.架构需求评审

组织一个由不同代表(如分析人员、客户、设计人员和测试人员)组成的小组，对体系结构需求及相关构件进行仔细地审查。审查的主要内容包括所获取的需求是否真实地反映了用户的要求，类的分组是否合理，构件合并是否合理等。必要时，可以在“需求获取一标识构件一需求评审”之间进行迭代。

7.2.5体系结构设计

体系结构开发模型第二阶段：体系结构设计。

体系结构需求用来激发和调整设计决策，不同的视图被用来表达与质量目标有关的信息。

体系结构设计是一个迭代过程。

1.提出软件体系结构模型

在建立体系结构初期，选择一个合适的体系结构风格是首要的，在这个风格基础上，开发人员通过体系结构模型，可以获得关于体系结构属性的理解。此时，虽然这个模型是理想化的，但是，该模型为将来的实现和演化过程建立了目标。

补充：什么是架构风格呢？

根据应用架构指南所说，架构风格指：一组原则。

你可以把它看成是一组为系统家族提供抽象框架的粗粒度模式。架构风格能改进分块，还能为频繁出现的问题提供解决方案，以此促进设计重用。

2.把已标识的构件映射到软件体系结构中

把在体系结构需求阶段已标识的构件映射到体系结构中，将产生一个中间结构，这个中间

结构只包含那些能明确适合体系结构模型的构件。

3.分析构件之间的相互作用

为了把所有已标识的构件集成到体系结构中，必须认真分析这些构件的相互作用和关系。

4.产生软件体系结构

一旦决定了关键构件之间的关系和相互作用，就可以在第2阶段得到的中间结构的基础上进行精化。

5.设计评审

一旦设计了软件体系结构，必须邀请独立于系统开发的外部人员对体系结构进行评审。

7.2.6体系结构文档化

体系结构开发模型第三阶段：体系结构文档化。

绝大多数的体系结构都是抽象的，由一些概念上的构件组成。例如，层的概念在任何程序设计语言中都不存在。因此，要让系统分析员和程序员去实现体系结构，还必须将体系结构进行文档化。

文档是在系统演化的每一个阶段，系统设计与开发人员的通信媒介，是为验证体系结构设计和提炼或修改这些设计(必要时)所执行预先分析的基础。

体系结构文档化过程的主要输出结果是两个文档：体系结构规格说明和测试体系结构需求的质量设计说明书。

7.2.7体系结构复审

体系结构开发模型第四阶段：体系结构复审。

体系结构设计、文档化和复审是一个迭代过程。从这个方面来说，在一个主版本的软件体系结构分析之后，要安排一次由外部人员(用户代表和领域专家)参加的复审。

复审的方式：

鉴于体系结构文档标准化以及风险识别的现实情况，通常人们根据架构设计，搭建一个可运行的最小化系统用于评估和测试体系架构是否满足需要。是否存在可识别的技术和协作风险。

复审的目的：

标识潜在的风险，及早发现体系结构设计中的缺陷和错误，包括体系结构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等。

7.2.8体系结构实现

体系结构开发模型第五阶段：体系结构实现。

所谓“实现”就是要用实体来显示出一个软件体系结构，即要符合体系结构所描述的结构性设计决策，分割成规定的构件，按规定方式互相交互。

实现过程以复审后的文档化体系结构为基础。体系结构说明书已定义系统中构件间关系，从构件库取符合接口约束条件的构件或开发，然后组装成系统。

测试：单个构件功能和组装后整体功能和性能。

7.2.9体系结构的演化

体系结构开发模型第六阶段：体系结构演化。

构件开发中，用户需求变动，以及系统移植到别的平台等等都会引起需求变动，这就要修改体系结构适应变化。

体系结构演化六步：

1.需求变化归类

首先必须对用户需求的变化进行归类，使变化的需求与已有构件对应。对找不到对应构件标记后续好开发。

2.制订体系结构演化计划

在改变原有结构之前，开发组织必须制订一个周密的体系结构演化计划，作为后续演化开发工作的指南。

3.修改、增加或删除构件

在演化计划的基础上，开发人员可根据在第1步得到的需求变动的归类情况，决定是否修改或删除存在的构件、增加新构件。最后，对修改和增加的构件进行功能性测试。

4.更新构件的相互作用

随着构件的增加、删除和修改，构件之间的控制流必须得到更新。

5.构件组装与测试

通过组装支持工具把这些构件的实现体组装起来，完成整个软件系统的连接与合成，形成新的体系结构。然后对组装后的系统整体功能和性能进行测试。

6.技术评审

对以上步骤进行确认，进行技术评审。评审组装后的体系结构是否反映需求变动、符合用

户需求。如果不符合，则需要在第2到第6步之间进行迭代。

在原来系统上所做的所有修改必须集成到原来的体系结构中，完成一次演化过程。

7.3软件架构风格

软件体系结构设计的一个核心目标是重复的体系结构模式，即达到体系结构级的软件重用。也就是说，在不同的软件系统中，使用同一体系结构。基于这个目标，主要任务是研究和实践软件体系结构风格和类型问题。

风格是体系结构的升华，体系结构是可以运用到很多领域和软件中，跨行业的运用虽然也可以用，但是还是缺少整个行业的体系结构标准，体系风格就是某个行业某个领域的标准。

例如：生产企业的MES系统实现的体系结构，运用到航空航天领域，大部分体系结构的内容是用不了的，那我们就把航空航天领域主流的全部系统(系统家族)拿出来研究一遍，形成航空航天领域的一个体系结构标准，只要是航空航天领域开发系统的体系结构都会参考这个标准，这就是这个领域的架构风格。

7.3.1软件架构风格概述

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

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

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

对软件体系结构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。例如，如果某人把系统描述为“客户/服务器”模式，则不必给出设计细节，人们立刻就会明白系统是如何组织和工作的。

7.3.2数据流体系结构风格

面向数据流，按照一定的顺序从前向后执行程序。

1.批处理

特征：每个步骤都是独立的程序，每一步必须在前一步结束后才能开始，并且数据必须是完整的，以整体的方式传输。它的基本构件是独立的程序，连接件是某种类型的媒介，连接件定义了数据流图，表达了拓扑结构。

2.管道-过滤器

当数据源源不断地产生，系统就需要对这些数据进行若干处理(分析、计算、转换等)。现有的解决方案是把系统分解为几个序贯的处理步骤，这些步骤之间通过数据流连接，一个步骤的输出是另一个步骤的输入。每个处理步骤由一个过滤器(Filter)实现，处理步骤之间的数据传输由管道(Pipe)负责。每个处理步骤(过滤器)都有一组输入和输出，过滤器从管道中读取输入的数据流，经过内部处理，然后产生输出数据流并写入管道中。因此，管道-过滤器风格(见图)的基本构件是过滤器，连接件是数据流传输管道，将一个过滤器的输出传到另一过滤器的输入。

◆早期编译器就是采用的这种架构，要一步一步处理的，均可考虑此架构风格。

◆二者区别在于批处理前后构件不一定有关联，并且数据是作为整体传递，即必须前一个执行完才能执行下一个。管道-过滤器是前一个输出作为后一个输入，前面执行到部分可以开始下一个的执行，数据不需要整体传输。

7.3.3调用/返回体系结构风格

构件之间存在互相调用的关系，一般是显式的调用，代表的风格有主程序/子程序、面向对象、层次结构。

1.主程序/子程序风格

单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。过程调用作为交互机制，充当连接件的角色。调用关系具有层次性，其语义逻辑表现为子程序的正确性取决于它调用的子程序的正确性。

2.面向对象体系结构风格

这种风格建立在数据抽象和面向对象的基础上，构件是对象，对象是抽象数据类型的实例。连接件即使对象间交互的方式，对象是通过函数和过程的调用来交互的。

3.层次型体系结构风格

构件组成一个层次结构，连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。修改某一层，最多影响其相邻的两层(通常只能影响上层)。

◆层次结构优点：
1、支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列的实现。
2、不同的层次处于不同的抽象级别，越靠近底层，抽象级别越高。
3、由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件复用提供了强大的支持。
◆缺点：
1、并不是每个系统都可以很容易的划分为分层的模式。
2、很难找到一个合适的、正确的层次抽象方法。

4.客户端/服务器体系结构风格

两层C/S--->三层C/S

两层C/S：数据库服务器、客户应用程序和网络。胖客户机，瘦服务器”。

三层C/S结构：功能层是应用的主体，实现具体的业务处理逻辑；数据层是数据库管理系统。瘦客户机。

7.3.4以数据为中心的体系结构风格

以前这个叫仓库风格/(数据共享风格)，以数据为中心，所有的操作都是围绕建立的数据中心进行的，代表的风格有数据库系统、超文本系统、黑板系统。

1.仓库体系结构风格

仓库(Repository)是存储和维护数据的中心场所。在仓库风格(见图7-13)中，有两种不同的构件；中央仓库数据结构说明当前数据的状态以及一组对中央数据进行操作的独立构件，仓库与独立构件间的相互作用在系统中会有大的变化。这种风格的连接件即为仓库与独立构件之间的交互。

构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。是一种非线性的网状信息组织方法，它以节点为基本单位，链作为节点之间的联想式关联。通常应用在互联网领域。

2.黑板体系结构风格

黑板系统是一种问题求解模型，是组织推理步骤、控制状态数据和问题求解之领域知识的概念框架。适合解决非结构化的问题，能在求解过程中运用多种不同知识源，使得问题的表达、组织和求解变得比较容易。

求解过程：

将问题的解空间组织成一个或多个应用相关的分级结构。分级结构的每一层信息由一个唯一的词汇来描述，它代表了问题的部分解。

领域相关的知识被分成独立的知识模块，它将某一层次中的信息转换成同层或相邻层的信息。各种应用通过不同知识表达方法、推理框架和控制机制的组合来实现。

影响黑板系统设计的最大因素是应用问题本身的特性，但是支撑应用程序的黑板体系结构有许多相似的特征和构件。

包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯—媒介；知识源响应是通过黑板状态的变化来控制的。

黑板系统通常应用在对于解决问题没有确定性算法的软件中(信号处理、问题规划和编译器优化等)。黑板系统的传统应用是信号处理领域，如语音识别和模式识别。另一应用是松耦合代理数据共享存取。

3.数据库系统

构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态；另一类是多个独立处理单元，处理单元对数据元素进行操作。

现代编译器的集成开发环境一般采用数据仓库(即以数据为中心的架构风格)架构风格进行开发，其中心数据就是程序的语法树。

7.3.5虚拟机体系结构风格

虚拟机体系结构风格的基本思想是人为构建一个运行环境，在这个环境之上，可以解析与运行自定义的一些语言，这样来增加架构的灵活性。虚拟机体系结构风格主要包括解释器风格和规则系统风格。

自定义了一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配，代表的风格有解释器、基于规则的系统。

1.解释器体系结构风格

组成：一个解释引擎、一个存储区、两个数据结构

一个解释器通常包括完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一个

记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行进度的数据结构。

具有解释器风格(见图7-15)的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用。解释器通常被用来建立一种虚拟机以弥合程序语义与硬件语义之间的差异。

其缺点：是执行效率较低。典型的例子是专家系统。

2.规则系统体系结构风格

基于规则的系统(见图7-16)包括规则集、规则解释器、规则/数据选择器及工作内存。

—般用在人工智能领域和DSS中。

7.3.6独立构件体系结构风格

构件之间是互相独立的，不存在显式的调用关系，而是通过某个事件触发、异步的方式来执行，代表的风格有进程通信、事件驱动系统(隐式调用)。

主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便；缺点是构件放弃了对系统计算的控制。

1.进程通信体系结构风格

构件是独立的进程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程(方法)调用等。

2.事件系统体系结构风格

构件不直接调用一个过程，而是触发或广播—个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。

7.4软件架构复用

7.4.1软件架构复用的定义及分类

软件产品线：一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产基础开发出来的。即围绕核心资产库进行管理、复用、集成新的系统。

核心资产库：包括软件架构即其可裁剪的元素，更广泛地，它还包括设计方案及其文档、手册、项目管理的记录、测试计划和用例

复用核心资产(特别是软件架构)：更进一步采用产品线将会惊人地提高生产效率、降低成本和缩短上市时间。

软件复用：指系统化的软件开发过程，开发一组基本的软件构造模块，以覆盖不同的需求/体系结构之间的相似性，从而提高系统开发的效率、质量和性能。是一种系统化的软件开发过程，通过识别、开发、分类、获取和修改软件实体，以便在不同的软件开发过程中重复的使用它们。

软件复用分类：

软件架构复用的类型包括机会复用和系统复用。机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用。系统复用是指在开发之前，就要进行规划，以决定哪些需要复用。

7.4.2软件架构复用的原因

降本增效、提高生产力、提高质量和互操作性，维护也简单。

7.4.3软件架构复用的对象及形式

软件产品线的本质：在生产产品家族时，以一种规范的、策略性的方法复用资产。

可复用资产范围广，主要几个方面：

(1)需求。

(2)架构设计。

(3)元素。不只是代码复用，捕获并复用可取之处。

(4)建模与分析。

各类分析方法(如性能分析)及各类方案模型(如容错方案、负载均衡方案)都可以在产品中得到复用。

(5)测试。测试资源：测试用例、测试数据、测试工具，甚至测试计划、过程、沟通渠道、环境都可以得到复用。

(6)项目规划。

利用经验对项目的成本、预算、进度及开发小组的安排等进行预测，即不必每次都建立工作分解结构。

(7)过程、方法和工具。

有了产品线这面旗帜，企业就可以建立产品线级的工作流程、规范、标准、方法和工具环境，供产品线中所有产品复用。如编码标准就是一例。

(8)人员。

(9)样本系统。

将已部署(投产)的产品作为高质量的演示原型和工程设计原型。

(10)缺陷消除。

7.4.4软件架构复用的基本过程

复用的基本过程主要包括3个阶段：首先构造/获取可复用的软件资产，其次管理这些资产，最后针对特定的需求，从这些资产中选择可复用的部分，以开发满足需求的应用系统。

1.复用的前提：获取可复用的软件资产

首先需要构造恰当的、可复用的资产，并且这些资产必须是可靠的、可被广泛使用的、易于理解和修改的。

2.管理可复用资产

该阶段最重要的是：构件库(Component Library),由于对可复用构件进行存储和管理，它是支持软件复用的必要设施。构件库中必须有足量的可复用构件才有意义。构件库应提供的主要功能包括构件的存储、管理、检索以及库的浏览与维护等，以及支持使用者有效地、准确地发现所需的可复用构件。

在这个过程中，存在两个关键问题：一是构件分类，构件分类是指将数量众多的构件按照某种特定方式组织起来；二是构件检索，构件检索是指给定几个查询需求，能够快速准确地找到相关构件。

3.使用可复用资产

在最后阶段，通过获取需求，检索复用资产库，获取可复用资产，并定制这些可复用资产：

修改、扩展、配置等，最后将它们组装与集成，形成最终系统。

7.5.1特定领域软件体系结构

早在20世纪70年代就有人提出程序族、应用族的概念，特定领域软件体系结构的主要目

的是在一组相关的应用中共享软件体系结构。

7.5.1DSSA的定义

简单地说，DSSA(Domain Specific Software Architecture)就是在一个特定应用领域中为一

组应用提供组织结构参考的标准软件体系结构

DSSA特征：

一个严格定义的问题域和问题解域。
具有普遍性，使其可以用于领域中某个特定应用的开发。
对整个领域的构件组织模型的恰当抽象。
具备该领域固定的、典型的在开发过程中可重用元素。

一般的DSSA的定义并没有对领域的确定和划分给出明确说明。从功能覆盖的范围的角度

有两种理解DSSA中领域的含义的方式。

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

(2)水平域：定义了在多个系统和多个系统族中功能区城的共有部分。在子系统级上涵盖多个系统族的特定部分功能。----教育和购物都有收费系统，收费系统就是水平域。

在垂直域上定义的DSSA只能应用于一个成熟的、稳定的领域，但这个条件比较难以满足。

若将领域分割成较小的范围，则相对更容易，也容易得到一个一致的解决方案。

补充：

DSSA(Domain Specific Software Architecture)与软件体系结构风格的比较

DSSA与软件体系结构风格是从不同角度出发研究问题的两种结果，前者从问题域出发，后者从解决域出发。
DSSA只对某个领域进行专家知识的提取、存储、组织，但可以同时使用多种软件体系结构风格；而在某个软件体系结构风格中进行专家知识组织时，可以将提取的公共结构和设计方法扩展到多个应用领域。
DSSA通常选用一个或多个适合所研究的领域的体系结构风格，并设计一个该领域专用的体系结构分析设计工具。但该方法提取的专家知识只能应用于一个较小的范围－－所在领域。一个领域的
DSSA及其工具在另一个领域中是不适应的，或不可以重用的。
体系结构风格避免设计到特定的应用领域或背景，所提取的知识比DSSA提取的知识应用范围要广。但在一个特定领域中，正是由于体系结构风格对领域知识、领域背景的忽略，使其在一个具体领域的开发中的作用并不比DSSA要大。
DSSA与体系结构风格是互为补充的两种技术。

7.5.2DSSA的基本活动

领域分析：

这个阶段的主要目标是获得领域模型(领域需求)。识别信息源，即整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。

领域设计：

这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求DSSA。

领域实现：

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

7.5.3参与DSSA的人员

参与DSSA的四种角色人员

领域专家：

包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、DSSA等领域工程产品，等等。

领域分析人员：

由具有知识工程背景的有经验的系统分析员来担任。控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中。

领域设计人员：

由有经验的软件设计人员来担任。根据领域模型和现有系统开发出DSSA,并对DSSA的准确性和一致性进行验证。

领域实现人员：

由有经验的程序设计人员来担任。根据领域模型和DSSA,开发构件。

7.5.4DSSA的建立过程

定义领域范围：

领域中的应用要满足用户一系列的需求。

定义领域特定的元素：

建立领域的字典，归纳领域中的术语，识别出领域中相同和不相同的元素。

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

识别领域中的所有约束，这些约束对领域的设计和实现会造成什么后果。

定义领域模型和架构：

产生一般的架构，并描述其构件说明。产生、搜集可复用的产品单元：为DSSA增加复用构件，使可用于新的系统。

以上过程是并发的、递归的、反复的、螺旋型的。

三层次模型

领域开发环境：领域架构师决定核心架构，产出参考结构、参考需求、架构、领域模型、开发工具。

领域特定的应用开发环境：应用工程师根据具体环境来将核心架构实例化。

应用执行环境：操作员实现实例化后的架构。

第7章 系统架构设计基础知识