三. 软件架构设计
3.1 概述
a 定义
软件或计算机系统的软件架构是该系统的一个（ 或多个） 结构， 而结构由软件元素、 元
素的外部可见属性及它们之间的关系组成。
软件系统架构是关于软件系统的结构、 行为和属性 的高级抽象。 指定了软件系统的组
织结构和拓扑结构。
b 架构的模型
4+1 视图模型:
逻辑视图 ： 主要支持系统的功能需求， 即系统提供给最终用户的服务。
开发视图 ： 也称为模块(实现)视图， 主要侧重于软件模块的组织和管理。
进程视图 ： 侧重于系统的运行特性， 主要关注一些非功能性的需求， 例如系统的性
能和可用性。
物理视图 ： 主要考虑如何把软件映射到硬件上， 它通常要考虑到解决系统拓扑结构、
系统安装、 通信等问题。
场景 ： 可以看作是那些重要系统活动的抽象， 它使四个视图有机地联系起来， 从某
种意义上说， 场景是最重要的需求抽象。
逻辑视图和开发视图描述系统的静态结构， 而进程视图和物理视图描述系统的动态
结构。
3.2 软件质量属性
可用性
可修改性 (可维护性/可扩展性/结构重构/可移植性)
性能
安全性
可测试性、 易用性、 功能性、 互操作性、 健壮性
(1) 性能 是指系统的响应能力， 即要经过多长时间才能对某个事件做出响应， 或者在某
段时间内系统所能处理事件的个数。
(2) 可用性 是系统能够正常运行的时间比例。 (通过用两次故障之间的时间长度或出现
故障时系统能够恢复的速度来表示)
(3) 可靠性是指软件系统在应用或错误面前， 在意外或错误使用的情况下维持软件系统
功能特性的基本能力。
(4) 健壮性是指在处理或环境中， 系统能够承受压力或变更的能力。
(5) 安全 性是指系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒
绝服务的能力。
(6) 可修改性 是指能够快速地以较高的性能价格比对系统进行变更的能力。
(7) 可变性是指体系结构经扩充或变更成为新体系结构的能力。
(8) 易用性是衡量用户使用一个软件产品完成指定任务的难易程度。
(9) 可测试性是指软件发现故障并隔离、 定位其故障的能力特性， 以及在一定的时间和
成本前提下， 进行测试设计、 测试执行的能力。
(10) 功能性是系统所能完成所期望工作的能力。
(11) 互操作性是指系统与外界或系统与系统之间的相互作用能力。
3.2.1 ISO 质量属性
一、 功能性：
1、 适合性： 软件是否提供了相应的功能
2、 准确性： 软件提供的功能是否正确（用户需要的）
3、 互操作性： 产品与产品之间交互数据的能力,例如 word 对其他文档的支持能力
4、 保密安全性： 允许经过授权的用户和系统能够正常的访问相应的数据和信息， 禁止
未授权的用户访问
5、 功能性的依从性： 国际/国家/行业/企业 标准规范一致性
二、 可靠性(度)：
产品在规定的条件下和规定的时间内完成规定功能的能力(概率)。
子特性速记： 成容一一
1、 成熟性： 软件产品为避免软件内部的错误扩散而导至系统失效的能力（ 主要是对内
错误的隔离） ,exception 等的处理；
2、 容错性： 软件防止外部接口错误扩散而导致系统失效的能力（ 主要是对外错误的隔
离）；
3、 易恢复性： 系统失效后， 重新恢复原有的功能和性能的能力；
4、 可靠性的依从性。
四、 效率性：
在规定台条件下， 相对于所用资源的数量， 软件产品可提供适当性能的能力
1、 时间特性： 平均事务响应时间， 吞吐率， TPS（ 每秒事务数） . 软件处理特定的业
务请求所需要的响应时间。
2、 资源利用性： CPU 内存 磁盘 IO 网络带宽 队列 共享内存. 软件处理特定的业务请
求所消耗的系统资源。
3、 效率依从性
五、 软件维护性：
"四规"， 在规定条件下， 规定的时间内， 使用规定的工具或方法修复规
定功能的能力
1、 易分析性： 分析定位问题的难易程度
2、 易改变性： 软件产品使指定的修改可以被实现的能力
3、 稳定性： 防止意外修改导致程序失效
4、 易测试性： 使已修改软件能被确认的能力
5、 维护性的依从性
六、 软件可移植性：
从一种环境迁移到另一种环境的能力
1、 适应性： 适应不同平台
2、 易安装性： 被安装的能力
3、 共存性： 软件产品在公共环境中与其它软件分享公共资源共存的软件。
4、 易替换性: 软件产品在同样的环境下， 替代另一个相同用途的软件产品的能力。
5、 可移植性的依从性：
3.2.2 优化方法
提高可用性: Ping/Echo; 命令/响应机制、 心跳机制、 异常处理机制、 冗余机制
提高性能: 队列调度; 引入并发、 维持数据或计算的多个副本、 增加可用资源、 控制采
样频度、 限制执行时间、 固定优先级调度
提高安全性: 检测攻击、 抵御攻击、 从攻击中恢复、 身份认证、 限制访问、 维护完整性;
入侵检测; 追踪审计
提高可修改性: 运行时注册(即插即用); 接口-实现分离; 信息隐藏（ 封装）
提高可测试性: 记录-回放
3.3 软件架构风格
软件架构风格是描述特定软件系统组织方式的惯用模式 。 组织方式描述了系统的组成构
件和这些构件的组织方式； 惯用模式则反映众多系统共有的结构和语义特性。
架构风格定义了一个系统家族， 即一个架构定义一个词汇表和一组约束 。 词汇表中包含
一些构件和连接件类型， 而这组约束指出系统是如何将这些构件和连接件组合起来的。
架构风格反映了领域中众多系统所共有的结构和语义特性 ， 并指导如何将各个模块和子
系统有效地组织成一个完整的系统。
a 数据流风格
批处理序列: 强调数据作为一个整体
管道和过滤器:每个构件都有一组输入和输出,构件读输入的数据流， 经过内部处理， 然
后产生输出数据流. (构件-->过滤器;连接件-->管道)
b 调用/返回风格
主程序/子程序: 计算构件作为子程序协作工作,由一个主程序顺序地调用这些子程序,
构件通过共享存储区交换数据. 曾经作为结构化开发方法的主要选择， 具有结构清晰， 维护
方便的特点， 缺点是主子程序划分缺乏标准， 较难实现不同设计人员间设计的子程序复用。
面向对象风格： 面向对象在类的层次实现高度内聚， 整个系统通过不同类的组合调用实
现不同功能， 便于类的复用， 只是面向对象是一个通用风格， 类的划分不同设计人员设计结
果有很大不同， 对实际架构设计指导意义不大。
层次结构风格： 分层结构将整个系统按照抽象层次不同分为多层， 每个层次的程序只需
要负责与相邻的上下两层打交道， 简化了系统中调用关系复杂度。 允许每层用不同的方法实
现， 为软件重用提供了强大的支持。
- 二层 C/S
- 三层 C/S: 表示层/功能层/数据层. B/S 为其一种特例
- MVC: 模型(model)－视图(view)－控制器(controller)
- MVP: 将视图 V 和模型 M 解耦
c 独立构件风格
进程通讯： 进程通讯架构将系统建设成一个个独立构件， 构件间采用命名的消息传递来
实现沟通与协作。
事件系统子风格： 事件驱动架构风格与进程通讯风格类似， 也是将系统分各个为独立的
构件， 不同的是不同构件间通讯不采用命名的消息， 而是采用隐式调用的方式， 先将一个个
构件的过程注册到某个事件中， 当这个事件发生时， 所有注册到该事件的过程自动被触发执
行。 这类风格的好处是独立构件间耦合度进一步降低， 方便构件修改及替换， 缺点是触发事
件放弃了对被触发执行程序组的控制。
d 虚拟机风格
解释器: 具有运行时系统行为(自)定义与改变能力. 如专家系统
基于规则的系统
e 仓库风格
数据库系统: 构件主要有两大类,一个是中央共享数据源 ,保存当前系统的数据状态,另
一个是多个独立处理元素,处理元素对数据元素进行操作。 中央数据库管理系统通过自身机
制如数据排它锁， 共享锁等， 实现数据高速访问， 数据一致性， 数据完整性。 同时各独立数
据处理单元之间互相不受约束。 (如编译器， 传统编译器采用批处理架构， 现代编译器采用
数据共享架构风格。 分析树是共享数据。 )
超文本系统： 主要应用于静态网页。
黑板风格: 由一个作为全局共享数据的黑板， 一个控制单元和多个知识源组成， 主要应
用与专家问题解决系统。 通过专家知识和反馈逐步得到正确结果. (如语音识别)
其它风格:
消息总线/面向服务架构
补充
过程控制 : 工业中的过程控制是指以温度、 压力、 流量、 液位和成分等工艺参数作为被
控变量的自动控制。 过程控制也称实时控制， 是计算机及时的采集检测数据， 按最佳值迅速
地对控制对象进行自动控制和自动调节， 如数控机床和生产流水线的控制等。
C2: 通过连接件绑定在一起按照一组规则运作的并行构件.
3.4 分层 C/S 架构
二层 C/S 架构缺点
- 二层 C/S 结构为单一服务器且以局域网为中心， 所以难以扩展至大型企业广域网或
Internet； (使用范围)
-
软、 硬件的组合及集成能力有限； (扩展性)
-
服务器的负荷太重， 难以管理大量的客户机， 系统的性能容易变坏； (性能)
-
数据安全性不好。 因为客户端程序可以直接访问数据库服务器， 那么， 在客户端计
算机上的其他程序也可想办法访问数据库服务器， 从而使数据库的安全性受到威胁。 (安全)
（1） 开发成本较高。 C/S 架构对客户端软硬件配置要求较高， 尤其是软件的不断升级，
对硬件要求不断提高， 增加了整个系统的成本， 且客户端变得越来越臃肿。
（2） 客户端程序设计复杂。 采用 C/S 架构进行软件开发， 大部分工作量放在客户端的
程序设计上， 客户端显得十分庞大。
（3） 信息内容和形式单一， 因为传统应用一般为事务处理， 界面基本遵循数据库的字
段解释， 开发之初就已确定， 用户获得的只是单纯的字符和数字， 既枯燥又死板。
（4） 用户界面风格不一， 使用繁杂， 不利于推广使用。
（5） 软件移植困难。 采用不同开发工具或平台开发的软件， 一般互不兼容， 不能或很
难移植到其它平台上运行。
（6） 软件维护和升级困难。 采用 C/S 架构的软件要升级， 开发人员必须到现场为客户
机升级， 每个客户机上的软件都需维护。 对软件的一个小小改动， 每一个客户端都必须更新。
（7） 新技术不能轻易应用。 因为一个软件平台及开发工具一旦选定， 不可能轻易更改。
三层 C/S 架构
1 表现层（Web 层）
负责接收客户端请求， 向客户端响应结果， 通常客户端使用 http 协议请求 web， web
层需要接收 http 请求， 完成 http 响应。
表现层包括展示层和控制层： 控制层负责接收请求， 展示层负责结果的展示。
表现层依赖业务层， 接收到客户端请求一般会调用业务层进行业务处理， 并将处理结
果响应给客户端。
表现层的设计一般都使用 MVC 模型。 MVC 是表现层的设计模型， 和其他层没有关系。
2 业务层 （Service 层）
它负责业务逻辑处理， 和我们开发项目的需求息息相关。 web 层依赖业务层， 但是业务
层不依赖 Web 层。
业务层在业务处理时可能会依赖持久层， 如果要对数据持久化需要保证事务一致性。
(事务应该放到业务层来控制）
3 持久层 （dao 层）
负责数据持久化， 包括数据层即数据库和数据访问层， 数据库是对数据进行持久化的
载体， 数据访问层是业务层和持久层交互的接口； 业务层需要通过数据访问层将数据
持久化到数据库中。
持久层就是和数据库交互， 对数据库表进行增删改査的。
优点:
（1） 允许合理地划分三层结构的功能， 使之在逻辑上保持相对独立性， 从而使整个系
统的逻辑结构更为清晰， 能提高系统和软件的可维护性和可扩展性。 (逻辑独立清晰, 可维
护性/可扩展性)
（2） 允许更灵活有效地选用相应的平台和硬件系统， 使之在处理负荷能力上与处理特
性上分别适应于结构清晰的三层； 并且这些平台和各个组成部分可以具有良好的可升级性和
开放性。 (可升级性/开放性)
（3） 三层 C/S 架构中， 应用的各层可以并行开发， 各层也可以选择各自最适合的开发
语言。 使之能并行地而且是高效地进行开发， 达到较高的性能价格比； 对每一层的处理逻辑
的开发和维护也会更容易些。 (开发维护成本/速度/技术门槛)
（4） 允许充分利用功能层有效地隔离开表示层与数据层， 未授权的用户难以绕过功能
层而利用数据库工具或黑客手段去非法地访问数据层， 这就为严格的安全管理奠定了坚实的
基础； 整个系统的管理层次也更加合理和可控制。 (安全)
B/S 架构
优点:
- 用户在使用系统时， 仅仅需要一个浏览器就可运行全部的模块， 真正达到了"零客
户端" 的功能， 很容易在运行时自动升级。 (客户端)
-
基于 B/S 架构的软件， 系统安装、 修改和维护全在服务器端解决。 (服务端)
-
B/S 架构还提供了异种机、 异种网、 异种应用服务的联机、 联网、 统一服务的最现实
的开放性基础。 (开放性)
缺点:
（1） B/S 架构缺乏对动态页面的支持能力， 没有集成有效的数据库处理功能。
（2） B/S 架构的系统扩展能力差， 安全性难以控制。
（3） 采用 B/S 架构的应用系统， 在数据查询等响应速度上， 要远远地低于 C/S 架构。 (性
能)
（ 4） B/S 架构的数据提交一般以页面为单位， 数据的动态交互性不强， 不利于 OLTP 应
用.
3.5 面向服务的架构 SOA
概念: 面向服务的架构 SOA 是一个组件模型, 它将应用程序的不同功能单元(称为服务)
通过这些服务之间定义良好的接口和契约联系起来。 接口采用中立的方式进行定义， 它独立
于实现服务的硬件平台、 操作系统和编程语言。 这使得构建在各种各样的系统中的服务可以
以一种统一和通用的方式进行交互。
基于 XML
主要有两种实现方式: web service 和 ESB
实现方法: Web Service / 服务注册表 / 企业服务总线 ESB
6 个 服务类型:
- 连接服务
连接服务又称连通服务， 是面向服务架构的骨干， 在完成服务的接入， 服务间的通信和
交互基础上， 还提供安全性、 可靠性、 高性能的服务能力保障。 连接服务的一个典型实现就
是企业服务总线(Enterprise Service Bus， ESB)。
- 协作服务
协作服务通常由通信代理和 Web 服务代理两部分组成。 通信代理与连通服务中的通信代
理实现内部有效的数据通信， Web 服务代理与外部的公共注册中心交互， 注册本平台对外开
放的 Web 服务以及查找所需要访问的外部 Web 服务。 协作服务既可以实现组织之间(如供应
链的合作伙伴之间)的交互通信， 也可以实现组织内部(如跨地域的分支机构之间， 并有防火
墙进行保护的情况)之间的交互通信。
- 业务服务
业务服务指为新建服务提供的特定运行支持环境。 新建服务包括单个服务以及合成服
务， 不包括流程化的服务。 合成服务一般由应用编码实现， 它可以调用其他的服务(包括：
单个服务、 合成服务和流程化的服务)。 业务服务与连通服务相联接， 其中的新建服务与其
他服务的通信和交互通过连通服务来实现。 业务服务的运行信息由运行管理服务保存， 业务
服务也接受并执行运行管理服务的管理和控制命令。
- 业务流程服务
流程服务是业务流程的运行环境， 提供流程驱动、 服务调用、 事务管理等功能。 流程
服务是为业务流程的运行提供的一组标准服务。 业务流程是一组服务的集合， 可以按照特定
的顺序并使用一组特定的规则进行调用。 业务流程可以由不同粒度的服务组成， 其本身也可视为服务。
- 交互服务
交互服务实现人与服务之间的交互功能。 人可以是服务的消费者， 也可以是服务的提供
者。 人不能直接消费服务， 也不能直接提供服务， 需要通过相应的程序实现代理操作(即人
通过操作程序实现与服务的交互)。 交互服务就是需要提供一组完整的功能， 以实现人与服
务的交互， 并能够方便地进行交互。 人员需要请求服务时， 向连通服务发送消息请求， 由连
通服务查找服务， 并将请求消息传递给服务提供者。
- 信息服务
信息服务特指为上层应用系统、 同层的其他服务等提供数据访问及资源访问服务。 其目
标是使应用系统能够统一、 透明、 高效地访问和操纵位于网络环境中的各种分布、 异构的数
据资源， 为实现全局数据访问、 加快应用开发、 增强网络应用和方便系统管理提供支持。
3.4.1 WEB SERVICE
由服务请求者、 服务提供者、 服务注册中心三个角色构成, 支持服务发布、 查找和绑定。
关键技术: UDDI / WSDL / SOAP / REST /XML
UDDI (universal description,discovery,intergration)统一描述、 发现和集成： 用于
Web 服务注册和服务查找；
WSDL (web service description language)web 服务描述语言： 用于描述 Web 服务的
接口和操作功能；
SOAP (simple object access protocol)简单对象访问协议： 为建立 Web 服务和服务请
求之间的通信提供支持；
BPEL (business process execution language) 企业过程执行语言： 用来将分散的、 功
能单一的 web 服务组织成一个复杂的有机应用.
REST (representational state transfer)表述性状态转移： REST 是一种使用 HTTP、 XML
技术进行基于 web 通信的技术， 它将网络中所有的事物抽象为资源， 每个资源对应唯一的统
一资源标识符 URI。 客户端通过 URI 获取资源的表述， 并通过获得资源的表述使得其状态发
生改变。 REST 将资源/资源的表述/获取资源的动作三者进行分离。
3.4.2 企业服务总线 ESB
概念： ESB（ enterprise service bus） 是传统中间件技术与 XML、 web 服务等技术结合
的产物, 主要支持异构系统集成。 ESB 基于内容的路由和过滤， 具备复杂数据的传输能力，
并可以提供一系列标准接口。
功能： 速记---监消三传服安
- 监控与管理
- 消息路由
- 消息增强
- 消息格式转换
- 传输协议转换
- 服务位置透明性
- 安全性
3.4.3 微服务
概念: 微服务是一种新型的软件架构, 把一个大型的单体应用程序和服务拆分为多个
支持的微服务.
内容: 一个微服务需要包含完整的业务功能,开放一种或多种接口为其他服务使用,并
可能包含一个自己私有的数据库.
优势:
（1） 技术异构性
在微服务架构中， 每个服务都是一个相对独立的个体， 每个服务都可以选择适合于自身
的技术来实现。 可以混合使用多种编程语言、 开发框架以及数据存储技术.
（2） 扩展
单块系统中， 我们要做扩展， 往往是整体进行扩展。 而在微服务架构中， 可以针对单个
服务进行扩展。
（3） 简化部署
简单的服务更容易部署, 每个服务的部署都是独立的, 单个服务出问题不会导致整个
系统的故障.
（4） 与组织结构相匹配
为服务强调模块化的结构, 可以将架构与组织结构相匹配， 避免出现过大的代码库， 从
而获得理想的团队大小及生产力。
（5） 可组合性
在微服务架构中， 系统会开放很多接口供外部使用。 当情况发生改变时， 可以使用不同
的方式构建应用 (而整体化应用程序只能提供一个非常粗粒度的接口供外部使用)。
挑战:
（1） 分布式系统的复杂度
分布式系统的编程难度更大, 服务间的通信都是通过网络远程调用, 因此性能和可靠
性都会受影响.
(2) 最终一致性
强一致性较难实现, 开发人员需要处理最终一致性的问题.
(3) 运维成本
每个服务都需要独立的配置、 部署、 监控、 日志收集等， 因此运维成本较高。
(4) DevOps 与组织结构
微服务不仅表现出一种架构模型， 同样也表现出一种组织模型----全功能团队。 这种新
型的组织模型意味着开发人员和运维的角色发生了变化， 开发者将承担起服务整个生命周期
的责任， 包括部署和监控， 而运维也越来越多地表现出一种顾问式的角色， 尽早考虑服务如
何部署。
3.5 架构设计
- 演变交付生命周期
- 属性驱动设计法
- 按架构组织开发团队
- 开发骨架系统
- 利用商用构件进行开发
3.6 软件架构文档化
- 视图编档
- 视图概述
- 元素目录
- 上下文图
- 可变性指南
- 架构背景
- 术语表
- 其他信息
- 跨视图文档
- 使用 UML
3.7 软件架构评估
3.7.1 关键步骤
风险点: 架构设计中潜在的、 存在问题的架构决策所带来的隐患。（业务逻辑不明确的
地方）
非风险点 ： 非隐患
敏感点: 为了实现某种特定的质量属性， 一个或多个构件所具有的特征；
权衡点 : 影响多个质量属性的特征， 是多个质量属性的敏感点（如对两个质量属性特征
产生相反的影响， 一个好一个坏）
3.7.2 评估方法
- 基于调查问卷或检查表的方式
- 基于度量的方式
- 基于场景的方式
a 架构权衡分析法 ATAM(architecture tradeoff analysis method)
包括 场景和需求收集、 架构视图和场景实现、 属性模型构造和分析、 属性模型折中
b 软件架构评估 SAAM(software architecture analysis method)
主要输入: 问题描述/需求说明/架构描述
分析过程: 场景开发/架构描述/单个场景评估/场景交互/总体评估
先评估单个, 再评估多个相互作用
c 成本效益分析法 CBAM(cost benefit analysis method)
3.8 构件复用
构件概念： 软件构件是软件系统中具有一定意义的、 相对独立的可重用单元。 与对象相
比， 构件可以基于对象实现， 也可以不作为对象实现。 构件需要在容器中管理并获取容器提
供的服务； 客户程序可以在运行状态下利用接口动态确定构件所支持的功能并调用。
面向构件的编程需要下列基本的支持： 多态性（可替代性）、 模块封装性（高层次信息
的隐藏）、 后期的绑定和装载（部署独立性）、 安全性（类型和模块安全性）。
构件组装成软件系统的过程可以分为 3 个层次: 定制/集成/拓展
3.8.1 商用构件标准规范
CORBA
三个层次
对象请求代理(ORB): 最底层, 规定了分布对象的定义（接口） 和语言映射， 实现对象
间的通信和互操作， 是分布对象系统中的"软总线" .
公共对象服务: 提供诸如并发服务、 名字服务、 事务（交易） 服务、 安全服务等各种各
样的服务.
公共设施: 最上层, 定义了构件框架， 提供可直接为业务对象使用的服务， 规定业务对
象有效协作所需的协定规则.
四种构件
实体（Entity） 构件需要长期持久化并主要用于事务性行为， 由容器管理其持久化。
加工（Process） 构件同样需要容器管理其持久化， 但没有客户端可访问的主键。
会话（Session） 构件不需要容器管理其持久化， 其状态信息必须由构件自己管理。 负
责完成服务端和客户端的交互。
服务（Service） 构件是无状态的。
EJB/J2EE
支持的 5 种构件模型： Applet、 Servlet、 JSP、 EJB、 Application Client。
其中,EJB 中的 BEAN 分三种:
- session bean 会话 bean: 负责维护一个短暂的会话；
- entity bean 实体 bean:负责维护一行稳固持久的数据；
- message-driven bean 消息驱动 bean:异步接受消息。
无状态的 bean 没有成员变量， 用单例模式 ； 有状态的 bean 有成员变量， 非线程安全，
适合用 prototype 原型模式。
微软的 COM/DCOM/COM+
3.8.2 应用系统簇与构件系统
3.8.3 基于复用开发的组织结构
3.9 产品线及系统演化
概念: 软件产品线是指一组软件密集型系统， 它们共享一个公共的、 可管理的特性集，
满足某个特定市场或任务的具体需要， 是以规定的方式用公共的核心资产集成开发出来的。
包含的技术: 软件架构/领域工程/DSSA
可复用的资产: ///
3.9.1 特定领域软件架构(DSSA)
概念:
以一个特定问题领域为对象， 形成由领域参考模型、 参考需求、 参考架构等组成的开发基础架构， 其目标是支持一个特定领域中多个应用的生成。
活动阶段:
（1） 领域分析： 主要目标是获得领域模型 。 即通过分析领域中系统的需求（领域需求），
确定哪些需求是被领域中的系统广泛共享的， 从而建立领域模型。
（2） 领域设计： 这个阶段的目标是获得 DSSA ， 它是一个能够适应领域多个系统的需求
的一个高层次的设计。 由于领域模型中的领域需求具有一定的变化性， DSSA 也要相应地具
有变化性， 它可以通过表示多选一的、 可选的解决方案等来做到这一点。
（3） 领域实现： 主要目标是依据领域模型和 DSSA 开发与组织可复用信息 。 这些复用
信息可以是从现有系统中提取得到的， 也可能通过新的开发得到。 这个阶段可以看作复用基
础设施的实现阶段。
参与人员
领域专家: 主要任务包括提供关于领域中系统的需求规约和实现的知识 ， 帮助组织规范
的一致的领域字典， 帮助选择样本系统作为领域工程的依据， 复审领域模型、 DSSA 等领域
工程产品.
领域分析人员: 主要任务包括控制整个领域分析过程， 进行知识获取， 将获取的知识组
织到领域模型中， 根据现有系统、 标准规范等验证领域模型的准确性和一致性，维护领域模
型。
领域设计人员: 主要任务包括控制整个软件设计过程， 根据领域模型和现有的系统开发
出 DSSA， 对 DSSA 的准确性和一致性进行验证， 建立领域模型和 DSSA 之间的联系.
领域实现人员: 主要任务包括根据领域模型和 DSSA， 或者从头开发可重用构件或 者利
用再工程的技术从现有系统中提取可重用构件， 对可重用构件进行验证， 建立 DSSA 与可重
用构件间的联系.
DSSA 系统模型
3.9.2 过程模型
双生命周期模型
SEI 模型
三生命周期模型
3.9.2 组织结构
3.9.3 建立方式
3.10 软件架构视图
