7.1 软件架构概念

7.1.1 软件架构的定义

软件体系结构是指一个程序或计算系统软件的一个或多个结构，包括软件的构件、构件的外部可见属性以及它们之间的相互关系。软件构件可以是程序模块、面向对象的类、数据库和中间件等。软件体系结构设计主要关注软件构件的结构、属性和交互作用，旨在提高软件工程师分析设计的有效性，考虑可能的选择方案和降低与软件构造相关联的风险。建立体系结构层的方法旨在提供一种导出体系结构设计的系统化方法，而体系结构设计则是构建软件的初始蓝图。

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

需求分析阶段

在软件工程领域，需求分析和软件体系结构设计面临不同的对象，分别是问题空间和解空间。为了保持二者的可追踪性和可转换性，研究如何从需求模型构建软件体系结构模型，以及如何保证模型转换的可追踪性是非常重要的。

针对这两个问题的解决方案因采用的需求模型不同而异，其中，采用Use Case图描述需求的方法中，一般通过词法分析和经验规则来完成从Use Case图向软件体系结构模型(包括类图等)的转换，并通过表格或Use Case Map等方式维护可追踪性。

从软件复用的角度看，软件体系结构对需求工程具有自然性和必然性，已有系统的软件体系结构模型对新系统的需求工程有很好的借鉴作用。因此，在需求分析阶段研究软件体系结构有助于将其概念贯穿整个软件生命周期，从而保证软件开发过程的概念完整性，促进各阶段参与者的交流，并易于维护各阶段的可追踪性。

设计阶段

设计阶段是软件体系结构（SA）研究的关注点之一，主要包括SA模型的描述、设计与分析方法以及设计经验的总结与复用。SA模型的描述研究可以分为三个层次。

1. SA的基本概念，即SA模型由哪些元素组成以及它们之间的组织原则。传统的设计概念只包括构件和基本的模块互联机制，但现在连接子作为与构件同等级别的实体也被引入。近年来，一些学者还认为应该将Aspect等因素引入SA模型。

2. 体系结构描述语言（ADL），它是支持构件、连接子及其配置描述的语言。ADL对连接子的重视是与其他建模语言区分的一个重要特征。常见的ADL有UniCon、Rapide、Darwin、Wright、C2SADL、Acme、xADL、XYZ/ADL和ABC/ADL等。

3. SA模型的多视图表示，通过不同的视角描述系统的体系结构，并将这些视图组织起来形成整体的SA模型。多视图描述是近年来SA研究的重要方向之一，每个视图反映了不同人员关注的系统特定方面，体现了关注点分离的思想。

将体系结构描述语言和多视图相结合可以更好地描述系统的体系结构，便于理解和交流，并有利于一致性检测和系统质量评估。学术界提出了多种多视图方案，如4+1模型、Hofmesiter的4视图模型、CMU-SEI的Views and Beyond模型等。工业界也提出了一些标准，如IEEE标准1471-2000、开放分布式处理参考模型（RM-ODP）、统一建模语言（UML）和Zachman框架等。需要注意的是，现阶段的ADL大多没有显式地支持多视图，而且上述多视图并不仅限于设计阶段的模型描述。

实现阶段

在实现阶段，体系结构研究关注于将体系结构设计转换为具体实现的技术。这包括基于SA的项目组织结构、配置管理、测试技术等方面的研究。SA提供了系统的蓝图，开发团队应该与体系结构模型相对应，从而提高软件开发效率和质量。SA引入了能够扩充现有配置管理的能力，通过引入版本、Options等信息记录不同版本构件和连接子之间的演化，以组织配置管理的活动。为填补高层SA模型和底层实现之间的差距，可通过封装实现细节、模型转换、精化等方法缩小概念之间的差距，并通过构件组装方式实现系统，这通常需要底层中间件平台的支持。

构件组装阶段

在S A设计模型下，可复用构件的组装能够在较高层次上实现系统，并提高系统实现效率。研究内容主要包括两个方面：一是支持可复用构件的互联，即实现S A设计模型中规约的连接子；二是在组装过程中检测和消除体系结构失配问题。

在设计阶段，可以通过ADL来支持连接子的实现，如UniCon和C2SADL等提供了多种连接子类型和生成连接子代码的机制。

中间件作为公共服务的提供者，遵循特定的构件标准，支持构件之间的互联。中间件具有跨平台交互的能力，且符合工业标准，如CORBA、J2EE、COM等，能够确保构件之间的通信完整性。中间件还提供强大的公共服务能力，有利于保证系统的质量属性。

体系结构失配问题是指待复用构件与最终系统的体系结构和环境假设不匹配而导致的冲突。检测并消除体系结构失配是解决失配问题的关键。失配问题主要包括构件引起的失配、连接子引起的失配和系统成分对全局体系结构的失配。需要通过适当的手段来检测和消除这些失配问题。

部署阶段

随着网络和分布式软件的发展，软件部署成为生命周期中一个独立的阶段。为了满足软件质量要求，部署需要考虑多方面信息，如构件互联性、硬件拓扑结构和资源占用等。SA提供高层的视图来描述软硬件模型，并分析部署方案的质量属性以选择合理的方案。当前，基于SA的软件部署研究更多集中在组织和展示部署阶段的SA以及评估分析部署方案等方面。部署方案分析往往停留在定性层面，需要部署人员参与。

后开发阶段

后开发阶段的S A研究主要关注软件部署安装后的维护、演化和复用，研究方向包括动态软件体系结构和体系结构恢复与重建。动态软件体系结构研究关注如何在设计阶段捕获体系结构的动态性，并指导软件系统在运行时刻实施变化，实现在线演化或自适应。体系结构恢复与重建研究则关注如何从已实现的系统中获取体系结构视图，在改善遗留系统的基础上进行升级、增强或移植。体系结构重建方法包括手工、工具支持的手工、查询语言以及其他技术如数据挖掘等。

7.1.3 软件架构的重要性

软件架构设计是一个非常重要的过程，它能够帮助我们降低成本、改进质量、按时和按需交付产品。软件架构设计可以满足系统的品质，使得不同的受益人达成一致的目标，支持计划编制过程，对系统开发提供指导性，有效地管理复杂性，为复用奠定基础，降低维护费用，支持冲突分析等等。因此，一个良好的软件架构设计过程是非常必要的，它需要体现出高质量、高可靠性、高效率等多个方面的要求。

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

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

基于体系结构的软件设计（ABSD）方法是一种由体系结构驱动的方法，通过组合商业、质量和功能需求来指导软件设计。使用ABSD方法，设计活动可以从项目的总体功能框架开始，而不需要等待需求的完全定义。设计活动与需求抽取和分析并行进行，特别适用于无法预先确定所有需求的情况。ABSD方法基于功能的分解、选择适当的体系结构风格以满足质量和商业需求，以及利用现有软件系统结构的软件模板。该方法是递归且迭代的，每个步骤都有清晰的定义，使得体系结构在设计过程中始终保持清晰，有助于降低随意性。

7.2.2 概念与术语

1. 设计元素
   ABSD方法是一种自顶向下、递归细化的软件设计方法。设计元素包括系统、概念子系统、软件模板和概念构件。系统被分解为若干概念子系统和一个或多个软件模板，在第二层，概念子系统又被分解为概念构件和一个或多个附加的软件模板。通过不断地细化，最终得到软件构件和类。
   
2. 视角与视图
   考虑体系结构时需要从不同的视角观察，这需要软件设计师的参与。不同的视角可以帮助我们判断架构的质量和系统的行为特性。常用的视角包括展示功能组织的静态视角和展示并发行为的动态视角。选择特定的视角或视图可以全面考虑体系结构设计。逻辑视图可以记录设计元素的功能和概念接口，通过定义设计元素的功能来确定其在系统中的角色，包括功能和性能等方面。
3. 用例和质量场景
   用例是在具体设置中推测系统行为的重要技术，用例被广泛应用于不同的场景中，用于捕获功能需求。同时，人们通过定义特定场景来捕获质量需求，并称之为质量场景。在软件开发过程中，质量场景用于捕获变更、性能、可靠性和交互性等方面的需求，分别被称为变更场景、性能场景、可靠性场景和交互性场景。质量场景包括预期和非预期的场景。例如，预期的性能场景可以是预估每年用户数量增加10%的影响，而非预期的场景可以是预估每年用户数量增加100%的影响。虽然非预期场景可能不会真正发生，但它们在确定设计边界条件时非常有用。

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

传统的软件开发过程包括问题定义、需求分析、软件设计、软件实现和软件测试等阶段。在传统模型中，软件体系结构的建立通常位于需求分析和概要设计之间。

然而，传统软件开发模型存在一些问题，如开发效率低下和不利于软件重用等。为了解决这些问题，提出了ABSD（Architectural-Based Software Development）模型。ABSD模型将基于体系结构的软件开发过程划分为六个子过程：体系结构需求、设计、文档化、复审、实现和演化。

ABSD模型的六个子过程依次进行，每个子过程都有其特定的任务和目标。通过采用ABSD模型，可以更好地支持软件开发过程中的体系结构需求和设计，并提高开发效率。

7.2.4 体系结构需求

体系结构开发模型，该模型将软件开发过程划分为六个子过程，包括体系结构需求、设计、文档化、复审、实现和演化。

• 在体系结构需求过程中，需求获取是主要任务，需求一般来自系统的质量目标、商业目标和开发人员的商业目标。

• 在标识构件过程中，需要生成类图、对类进行分组，并把类打包成构件。
  

• 在架构需求评审过程中，需要组织小组进行仔细的审查，以确保需求真实反映用户要求，类的分组和构件合并合理。迭代可能在“需求获取一标识构件一需求评审”之间进行。

7.2.5 体系结构设计

体系结构需求用于激发和调整设计决策，并通过不同的视图表达与质量目标相关的信息。体系结构设计是一个迭代过程，如果要开发的系统可以从已有系统中导出大部分，则可以利用已有系统的设计过程。

1. 在建立软件体系结构的初期，选择合适的体系结构风格至关重要。通过体系结构模型，开发人员可以理解体系结构属性，为将来的实现和演化过程建立目标。
2. 将在体系结构需求阶段已标识的构件映射到体系结构中，形成一个中间结构，其中只包含符合体系结构模型的构件。
3. 对构件之间的相互作用进行认真分析，以便将所有已标识的构件集成到体系结构中。
4. 一旦确定了关键构件之间的关系和相互作用，就可以在中间结构的基础上产生精化的软件体系结构。
5. 设计完成后，需要邀请独立于系统开发的外部人员对软件体系结构进行评审。

7.2.6 体系结构文档化

体系结构的文档化是必要的，因为绝大多数体系结构都是抽象的，并由一些概念构件组成。这些概念在程序设计语言中并不存在，因此需要文档化来帮助系统分析员和程序员实现体系结构。

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

体系结构规格说明是对体系结构进行详细描述的文档，用于验证体系结构设计并为进一步的分析提供基础。

测试体系结构需求的质量设计说明书则是生成需求模型构件的精确形式化描述，作为用户和开发者之间的约定。

在软件开发项目中，体系结构文档的要求与其他文档相似。文档的完整性和质量是体系结构成功的关键因素。文档应该从使用者的角度编写，并分发给所有与系统相关的开发人员，同时需要确保开发者手上的文档是最新的。

7.2.7 体系结构复审

体系结构设计、文档化和复审是一个迭代过程。在完成主版本的软件体系结构分析后，需要安排一次由外部人员（例如用户代表和领域专家）参与的复审。

为了标准化体系结构文档并识别风险，通常会根据架构设计构建一个可运行的最小化系统，用于评估和测试体系结构是否满足需求，并识别可识别的技术和协作风险。

复审的目的是识别潜在的风险，并及早发现体系结构设计中的缺陷和错误。这包括判断体系结构是否满足需求，是否体现了质量需求，层次是否清晰，构件的划分是否合理，文档表达是否明确，以及构件的设计是否满足功能和性能要求等方面。通过复审，可以发现并解决这些问题，确保体系结构的质量和有效性。

7.2.8 体系结构实现

体系结构的实现过程可以总结如下：

1. 根据体系结构说明书：开发团队以体系结构说明书为基础，了解系统中的构件和它们之间的关系。体系结构说明书中包含了对构件的责任和接口约束的定义。

2. 寻找或开发构件：根据体系结构说明书中的接口约束，开发团队可以从构件库中选择符合要求的构件，或者根据需要开发新的构件。每个构件都必须满足体系结构中对其他构件的责任。

3. 组装构件：通过使用支持工具，将选取或开发的构件组装起来，按照体系结构设计提供的结构进行连接和合成。这样，整个软件系统的实现体就形成了。

4. 进行测试：对实现的软件系统进行测试，包括对单个构件的功能性测试以及对组装后的应用的整体功能和性能测试。测试的目的是验证系统是否满足预期的功能和性能要求。

体系结构的实现过程是根据体系结构设计决策将设计转化为实际的软件系统。每个构件的实现者在工作中可能无法直接看到整个系统，而是根据体系结构说明书中的约束来完成构件的开发和组装。

通过正确实施体系结构的实现过程，可以确保系统按照设计要求进行开发，构件之间的交互和责任得到合理的实现。同时，测试阶段也能够验证系统的功能和性能是否符合预期。

7.2.9 体系结构的演化

体系结构演化过程可以总结为以下6个步骤：

1. 需求变化归类：将用户需求的变化进行分类，与已有构件进行对应。对于找不到对应构件的变化，需要创建新的构件以满足需求变化。

2. 制订体系结构演化计划：在修改原有结构之前，制定详细的体系结构演化计划，作为后续开发工作的指导。

3. 修改、增加或删除构件：根据需求变化的分类情况，在演化计划的基础上决定是否修改、增加或删除现有构件。对修改和增加的构件进行功能性测试。

4. 更新构件的相互作用：随着构件的增加、删除和修改，需要更新构件之间的控制流关系。

5. 构件组装与测试：使用支持工具将构件组装起来，按照新的体系结构连接和合成整个软件系统。对组装后的系统进行整体功能和性能测试。

6. 技术评审：对以上步骤进行确认，并进行技术评审。评审组装后的体系结构是否反映了需求变化，并符合用户需求。如果不符合，需要在第2到第6步之间进行迭代。

在整个体系结构演化过程中，所有对原系统的修改都必须集成到原有的体系结构中，完成一次演化过程。这样可以确保系统能够适应新的需求变化。

7.3 软件架构风格

7.3.1 软件架构风格概述

软件体系结构风格是指描述特定应用领域中系统组织方式的常用模式。它定义了一个系统家族，即一组共享词汇表和约束集合的体系结构。这个词汇表包含了一些构件和连接件类型，而约束集合则说明了如何将这些构件和连接件组合起来。软件体系结构风格反映了在特定领域中众多系统所共有的结构和语义特性，并指导了如何有效地组织各个模块和子系统来构建一个完整的系统。

对软件体系结构风格的研究和实践有助于设计的重用，一些经过实践验证的解决方案可以可靠地用于解决新问题。举个例子，如果一个系统被描述为"客户/服务器"模式，那么人们就会立即理解系统是如何组织和工作的，而不需要详细说明设计细节。

总之，软件体系结构风格对于系统设计具有重要意义，它能提高系统的可维护性、可扩展性和可重用性，并促进了设计的效率和沟通的便利。

7.3.2 数据流体系结构风格

数据流体系结构是一种与传统的冯·诺依曼体系结构或控制流体系结构不同的计算机体系结构。它没有程序计数器，指令的执行顺序是不确定的，取决于指令输入参数的可用性。数据流体系结构主要包括批处理风格和管道-过滤器风格。

1. 批处理体系结构风格中，系统由多个独立的应用程序组成，每个程序代表一个处理步骤。每个步骤必须在前一步完成后才能开始，并且数据以整体的方式传递。连接件定义了数据流图，表示系统的拓扑结构。
   

2. 管道-过滤器体系结构风格适用于需要对连续产生的数据进行多个处理步骤的情况。系统被分解为多个序贯的处理步骤，通过数据流连接起来。每个处理步骤由一个过滤器实现，数据传输由管道负责。过滤器从管道中读取输入数据流，进行处理后产生输出数据流，并写入管道中。
   

总的来说，数据流体系结构是一种用于组织系统的体系结构风格，它可以提高系统的并行性和灵活性，适用于处理大量数据的场景。

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

1. 主程序/子程序风格：

• 采用单线程控制，将问题划分为若干处理步骤，构件包括主程序和子程序。
• 子程序通常组成模块，通过过程调用进行交互，形成调用关系。
• 调用关系具有层次性，子程序的正确性取决于它调用的子程序的正确性。

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

• 建立在数据抽象和面向对象的基础上，使用抽象数据类型或对象作为构件。
• 数据的表示和操作封装在抽象数据类型或对象中。
• 通过消息传递进行交互，对象之间通过发送消息来触发操作。

3. 层次型体系结构风格：

• 构建一个层次结构，每一层为上层提供服务，作为下层的客户。
• 内部层接口对相邻层可见，拓扑约束限制了层间交互。
• 支持软件重用，每层可以用不同的方法实现，只要给相邻层提供相同的接口。

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

• 基于资源不对等，实现共享的需求。
• 由数据库服务器、客户应用程序和网络组成。
• 两层C/S体系结构中，服务器负责数据管理，客户机完成与用户的交互。
• 三层C/S体系结构增加了应用服务器，将应用逻辑驻留在服务器上，客户机只负责表示层。

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

1. 仓库体系结构风格：

• 中央仓库是存储和维护数据的中心。
• 独立构件通过与中央仓库的交互来对数据进行操作。
• 仓库与独立构件之间的相互作用在系统中会有很大的变化。

2. 黑板体系结构风格：

• 适用于解决复杂的非结构化问题。
• 综合运用多种不同的知识源来求解问题。
• 黑板系统将问题的解空间组织成一个或多个应用相关的分级结构。
• 领域相关的知识被分成独立的模块，将信息转换到同层或相邻层。
• 应用通过不同的知识表达方法、推理框架和控制机制的组合来实现。

仓库体系结构适用于需要集中存储和管理数据的系统，而黑板体系结构适用于需要综合多种知识源进行问题求解的系统。每种体系结构都有其特定的应用场景和优势，可以根据具体需求选择合适的体系结构风格来设计系统。

7.3.5 虚拟机体系结构风格

虚拟机体系结构风格的基本思想是构建一个运行环境，以增加架构的灵活性。虚拟机体系结构风格主要包括解释器风格和规则系统风格。

1. 解释器体系结构风格：

• 解释器包括解释引擎、存储区、工作状态记录和执行进度记录等组件。
• 软件中的虚拟机可以模拟硬件执行过程和关键应用。
• 解释器用于建立虚拟机，弥合程序语义与硬件语义之间的差异。
• 缺点是执行效率较低。典型的例子是专家系统。

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

• 基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存等组件。
  

虚拟机体系结构风格通过解释器和规则系统来实现灵活的架构设计。解释器体系结构适用于需要模拟硬件执行过程或处理程序语义的系统，而规则系统体系结构适用于基于规则的系统。每种体系结构都有其特定的优势和应用场景，可以根据需求选择适合的体系结构风格来设计系统。

7.3.6 独立构件体系结构风格

独立构件风格强调系统中的每个构件相对独立，通过进程通信或事件系统来实现构件之间的交互。这样可以降低耦合度，提高系统的灵活性和可扩展性。

1. 进程通信体系结构风格中，构件是独立的进程，它们之间通过消息传递进行通信。可以使用点到点、异步或同步方式以及远程过程调用等方法进行消息传递。

2. 事件系统体系结构风格基于事件的隐式调用思想，构件之间不直接调用过程，而是通过触发或广播事件来实现交互。其他构件中的过程可以在事件中注册，当事件被触发时，系统会自动调用注册的过程。这种风格的特点是触发者无法确定哪些构件会被事件影响，因此不能假定构件的处理顺序，也不知道哪些过程会被调用。
   

独立构件风格的应用广泛，例如在编程环境中用于集成各种工具，在数据库管理系统中用于确保数据的一致性约束，在用户界面系统中用于管理数据，以及在编辑器中支持语法检查等。它可以提供灵活的构件组合和交互方式，使系统更加可靠和可扩展。

7.4 软件架构复用

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

软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，以满足特定市场或任务的需求。它们通过规定的方式使用共享的核心资产进行集成开发。核心资产库包括软件架构、设计方案、文档、用户手册、项目管理记录、软件测试计划和测试用例等。

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

软件架构复用包括机会复用和系统复用。机会复用是在开发过程中发现可复用资产后进行复用。系统复用是在开发之前进行规划，确定需要复用的内容。

通过软件产品线和软件复用，可以显著提高生产效率、降低成本和缩短上市时间。同时，它还可以促进软件开发过程的标准化和规范化，提高软件的质量和可维护性。

7.4.2 软件架构复用的原因

软件架构复用可以减少开发工作、减少开发时间以及降低开发成本，提高生产力。不仅如此，它还可以提高产品质量使其具有更好的互操作性。同时，软件架构复用会使产品维护变得更加简单。

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

软件产品线是一种基于产品间共性和复用的软件工程概念。它通过规范化和策略性的复用资产，包括需求、架构设计、元素、建模与分析、测试、项目规划、过程方法工具、人员、样本系统和缺陷消除等，来提高生产效率、降低成本、缩短上市时间，并促进软件开发过程的标准化和规范化。复用的形式包括函数、库、类、接口和包等，并且复用的趋势是从小粒度向大粒度的方向发展。

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

1. 获取可复用的软件资产：构造可靠、易于理解和修改的可复用资产，包括需求、架构设计、元素、建模与分析、测试等方面的资产。
2. 管理可复用资产：建立构件库(Component Library)，存储和管理可复用构件。构件库应提供构件的存储、管理、检索等功能，以便使用者能够快速准确地找到所需的可复用构件。关键问题包括构件的分类和构件的检索。
3. 使用可复用资产：根据需求，从可复用资产库中检索出需要的资产，并进行定制、修改、扩展、配置等操作，最终将它们组装和集成成最终的系统。

通过软件复用，可以提高开发效率、降低成本，促进软件开发过程的标准化和规范化。在复用的过程中，需要注意资产的可靠性和可复用性，以及构件库的有效管理和使用。

7.5 特定领域软件体系结构

7.5.1 DSSA的定义

DSSA是指在一个特定领域中为一组应用提供标准软件体系结构的参考模型，包括领域模型、参考需求、参考体系结构等组成的开发基础。DSSA必备的特征包括严格定义的问题域和问题解域、具有普遍性、对整个领域的构件组织模型的恰当抽象、具备该领域固定的、典型的在开发过程中可重用元素。DSSA可从垂直域和水平域两种方式来理解领域的含义。在使用DSSA时需要根据具体情况对领域进行划分，以便得到一个一致的解决方案。

7.5.2 DSSA的基本活动

DSSA的实施过程包括三个基本的阶段：领域分析、领域设计和领域实现。

1. 领域分析阶段：

• 定义领域的边界，明确分析的对象。
• 识别信息源，包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析等。
• 分析领域中系统的需求，确定领域模型，并建立领域模型描述系统之间的共同需求。
• 选择样本系统进行需求地考察，显示领域需求的变化范围。

2. 领域设计阶段：

• 获得DSSA（Domain-Specific Software Architecture），它是满足领域模型中需求的高层次设计解决方案。
• DSSA不是单个系统的表示，而是适应领域中多个系统需求的设计。
• DSSA具有变化性，可以通过多选一、可选的解决方案等方式来满足不同系统的需求。

3. 领域实现阶段：

• 根据领域模型和DSSA，开发和组织可重用信息。
• 可重用信息可以从现有系统中提取，也可以通过新的开发获得。
• 可重用信息依据领域模型和DSSA进行组织，支持系统化的软件重用。
• 这个阶段也可以看作是重用基础设施的实现阶段。

需要注意的是，以上过程是循环迭代的，每个阶段可能会返回到之前的步骤进行修改和完善，然后再继续当前阶段的活动。这样逐渐求精，不断改进和优化领域工程的结果。

7.5.3 参与DSSA的人员

DSSA参与人员可划分为4种角色：领域专家、领域分析人员、领域设计人员和领域实现人员。

1. 领域专家：提供关于领域系统需求和实现的知识，帮助规范领域字典，选择样本系统作为领域工程依据，复审领域模型和DSSA等产品。需要熟悉系统设计、实现、硬件限制和未来用户需求。

2. 领域分析人员：具备知识工程背景，控制整个领域分析过程，获取知识并组织到领域模型中，验证领域模型准确性和一致性，维护领域模型。需要熟悉软件重用、领域分析方法，具备领域经验、抽象能力和良好的交互合作能力。

3. 领域设计人员：有经验的软件设计人员，控制整个软件设计过程，根据领域模型和现有系统开发DSSA，验证DSSA准确性和一致性，建立领域模型与DSSA的联系。需要熟悉软件重用、领域设计方法，具备领域经验和与领域专家交互的能力。

4. 领域实现人员：有经验的程序设计人员，根据领域模型和DSSA开发可重用构件，或利用再工程技术从现有系统中提取可重用构件，验证可重用构件，并建立DSSA与可重用构件的联系。需要熟悉软件重用、领域实现和软件再工程技术，具备领域经验和程序设计能力。

7.5.4 DSSA的建立过程

DSSA的创建和使用过程需要根据所应用到的领域来进行调整。通常情况下，需要使用所应用领域的开发工具和方法来建立DSSA模型。DSSA的建立过程分为五个阶段：

1. 定义领域范围：确定感兴趣的领域以及本过程的结束条件，输出领域中应用需求。

2. 定义领域特定的元素：编译领域字典和术语的同义词词典，添加更多细节，识别应用间的共同性和差异性。

3. 定义领域特定的设计和实现需求约束：描述解空间中的特性，记录约束对设计和实现的影响，并记录讨论的问题。

4. 定义领域模型和体系结构：产生一般的体系结构，并说明构成模块或构件的语法和语义。

5. 产生、搜集可重用的产品单元：为DSSA增加构件，使其可以用于生成新应用。

DSSA的建立过程是并发、递归和反复进行的，目的是将用户需求映射为基于实现限制的软件需求。之前的领域工程和领域分析过程没有区分系统功能需求和实现限制，统称为“需求”。DSSA的系统模型通常包括三个层次。