软考高级系统架构设计师-第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，开发可重用的构件。

11.5.4 DSSA的建立过程

DSSA的建立过程分为5个阶段：

（1）定义领域范围：领域中的应用要满足用户一系列的需求。

（2）定义领域特定的元素：建立领域的字典，归纳领域中的术语，识别出领域中相同和不相同的元素。

（3）定义领域特定的设计和实现需求的约束：识别领域中的约束，记录这些约束对领域的设计和实现会造成什么后果。

（4）定义领域模型和架构：产生一般的架构，并描述其构件说明。

（5）产生、搜集可复用的产品单元：为DSSA增加复用构件，使其可用于新的应用系统。

DSSA的建立过程是并发的、递归的、反复的和螺旋型的。

DSSA的三层次系统模型：

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

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

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