软件架构之复用以及产品线、软件架构视图

9.9 构件及其复用

软件企业为了提高开发效率，越来越注重软件元素的复用（也称重用），因此，架构设计师在进行架构设计时，必须关注复用，例如，考虑丰富企业构件和充分使用已有的构件。

本节从构件角度研究如何使用软件复用技术，下一节重点讨论基于产品线的软件复用。 与复用技术密切相关的概念是构件（component，组件），业界对构件还没有公认的定义，如下为几种常见的定义。

定义 1：构件是指软件系统中可以明确辨识的构成成分。而可复用构件（reusable component）是指具有相对独立的功能和可复用价值的构件。

定义 2：构件是一个组装单元，它具有约定式规范的接口及明确的依赖环境。

定义 3：构件是软件系统中具有相对独立功能、可以明确辨识、接口由契约指定、和语境有明显依赖关系、可独立部署的可组装软件实体。

对构件更广义的理解是把所有种类的工作成品（例如，各类文档、方案、计划、测试案例、代码）都看成是可复用的构件。

9.9.1 商用构件标准规范

当前，主流的商用构件标准规范包括 OMG（Object Management Group，对象管理组织）的 CORBA、SUN 的 J2EE 和 Microsoft 的 DNA。

1．CORBA
CORBA（Common ObjectRequest Broker Architecture，公共对象请求代理架构）主要分为3 个层次：对象请求代理、公共对象服务和公共设施。最底层的对象请求代理（Object Request Broker，ORB），规定了分布对象的定义（接口）和语言映射，实现对象间的通信和互操作，是分布对象系统中的“软总线”；在 ORB 之上定义了很多公共服务，可以提供诸如并发服务、名字服务、事务（交易）服务、安全服务等各种各样的服务；最上层的公共设施则定义了构件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则。

CORBA CCM（CORBA ComponentModel，CORBA 构件模型）是 OMG 组织制定的一个用于开发和配置分布式应用的服务器端构件模型规范，它主要包括如下 3 项内容。

（1）抽象构件模型：用以描述服务器端构件结构及构件间互操作的结构。
（2）构件容器结构：用以提供通用的构件运行和管理环境，并支持对安全、事务、持久状态等系统服务的集成。
（3）构件的配置和打包规范：CCM 使用打包技术来管理构件的二进制、多语言版本的可执行代码和配置信息，并制定了构件包的具体内容和文档内容标准。

2.J2EE
在 J2EE 中，SUN 给出了完整的基于 Java 语言开发面向企业分布的应用规范，其中，在分布式互操作协议上，J2EE 同时支持 RMI（Remote Method Invocation，远程方法调用）和 IIOP（Internet Inter-ORB Protocol，互联网内部对象请求代理协议），而在服务器端分布式应用的构造形式，则包括了 Java Servlet、JSP、EJB 等多种形式，以支持不同的业务需求，而且 Java 应用程序具有跨平台的特性，使得 J2EE 技术在发布计算领域得到了快速发展。

其中，EJB 给出了系统的服务器端分布构件规范，这包括了构件、构件容器的接口规范，以及构件打包、构件配置等的标准规范内容。EJB 技术的推出，使得用 Java 基于构件方法开发服务器端分布式应用成为可能。从企业应用多层结构的角度，EJB 是业务逻辑层的中间件技术，与 JavaBeans 不同，它提供了事务处理的能力，自从三层结构提出以后，中间层，也就是业务逻辑层，是处理事务的核心，从数据存储层分离，取代了存储层的大部分地位。

从 Internet 技术应用的角度，EJB 和 Servlet，JSP 一起成为新一代应用服务器的技术标准，EJB 中的 Bean 可以分为会话 Bean 和实体 Bean，前者维护会话，后者处理事务，通常由Servlet 负责与客户端通信，访问 EJB，并把结果通过 JSP 产生页面传回客户端。

3．DNA 2000
Microsoft DNA 2000 是 Microsoft 在推出 Windows 2000 系列操作系统平台的基础上，在扩展了分布计算模型，以及改造 Back Office 系列服务器端分布计算产品后发布的新的分布计算架构和规范。在服务器端，DNA 2000 提供了 ASP、COM、Cluster 等的应用支持。

DNA 2000 融合了当今最先进的分布计算理论和思想，例如，事务处理、可伸缩性、异步消息队列、集群等内容。DNA 可以开发基于 Microsoft 平台的服务器构件应用，其中，如数据库事务服务、异步通信服务和安全服务等，都由底层的分布对象系统提供。

Microsoft 的 DCOM/COM/COM+技术，在 DNA 2000 分布计算结构基础上，展现了一个全新的分布构件应用模型。首先，DCOM/COM/COM+的构件仍然采用普通的 COM（Component Object Model，构件对象模型）模型。COM 最初作为 Microsoft 桌面系统的构件技术，主要为本地的 OLE（Object Linking and Embedding，对象连接与嵌入）应用服务，但是随着 Microsoft 服务器操作系统 Windows NT 和 DCOM（Distributed Component Object
Model，分布式构件对象模型）的发布，COM 通过底层的远程支持使得构件技术延伸到了分布应用领域。DCOM/COM/COM+更将其扩充为面向服务器端分布应用的业务逻辑中间件。

通过 COM+的相关服务设施，如负载均衡、内存数据库、对象池、构件管理与配置等，DCOM/COM/COM+将 COM、DCOM、MTS（Microsoft Transaction Server，微软事物处理服务器）的功能有机地统一在一起，形成了一个概念、功能强的构件应用架构。

通过购买商用构件（平台）并遵循其开发标准来进行应用开发，是提高应用软件开发效率的常见选择

9.9.2 应用系统簇与构件系统

除专门开发构件的企业外，开发应用系统的企业也会发展自己的构件应用体系：通常是随着企业的不断成熟，逐步从已开发的应用系统中整理出来一些构件，反过来，将这些构件复用到优化与整合已有应用系统中或复用于开发新的应用系统。

一个应用系统中的复用率毕竟有限，通常在应用系统簇中进行软件构件复用。当要开发若干相关的应用系统时，可以先按复用的要求，界定这一组应用系统的共同“特性”，根据这些共同特性，建立模型，并按照复用的要求，将模型分解成恰当规模和结构的构件，对这些构件进行设计、实现、打包、编写文档，形成方便使用的可复用构件。这批可复用构件将用于支持该应用簇的各个应用系统的开发工作。这里的构件特指一个封装的代码模块或大粒度的运行模块。

软件企业将相关的构件有机地组织在一起，形成构件系统（较构件库层次更高），实施复用的软件企业通常拥有多个构件系统，有的是购置的，有的是自己开发的。应用系统和构件系统都是系统产品（而不是工作产品）。它们都可以采用模型和结构的类型定义出来。一般情况下，构件系统只在开发单位内部使用，而应用系统提供给外部客户，与应用系统相比，构件系统具有通用性，可复用性，这就要求构件系统的开发过程应当实施更为严格的工程规范。

一个构件系统是能提供一系列可复用特性的系统产品。构件系统中的构件应当是高内聚、低耦合的，但构件之间应有若干种关系；可以发送消息给其他构件；可以与其他构件联合，支持协同工作。构件系统应当是易于理解和易于使用的，对构件应当是仔细地进行建模、实现、制作文档、测试等，便于以后的有效维护和改进。通常为支持构件的复用，应开发与构件系统相配的工具箱。
应用系统可以向构件系统输入构件（构件的需求源于应用系统或应用系统中的模块），反过来，构件系统向应用系统输出构件。这就是构件系统如何获得构件和如何提供构件的方式。

9.9.3 基于复用开发的组织结构

基于复用的开发组织与传统的开发组织结构不同，它需要有一部分用于开发可复用资产的资源，这部分资源应同具体应用系统的开发资源分开，以确保不被占用。

一种较平衡的组织结构如图 9-21 所示，它有三类职能部门：一是构件系统开发部门，它开发可复用资产；二是应用系统项目开发部（多个），它复用资产；三是支持部门，这个部门是可选的，它进一步隔离上述两主体部门，虽然牺牲了一些效率，但保证了构件的规范性。它的主要职责是对构件开发部门所提供的可复用资产进行确认、对构件库进行分类编目、向开发应用系统的工程师们发通告和分发可复用资产、提供必要的文档、从复用者处收集反馈信息和缺陷报告。可以这样理解：构件系统开发部门开发的构件系统由支持部门向应用开发部门推广，即支持部门是企业内的推广部。外部购买的商用构件也由支持部门维护与管理。

这三个平行部门之上有一个高层经理（复用经理），他关注总目标，协调相互关系。

一方面，构件开发者应当尽量接近应用开发者，以使其开发出的构件能尽量符合实际需要；另一方面，构件开发者与应用开发者分属两个并列的部门，使构件开发者能摆脱应用项目的日常压力，保证可复用资产的开发和持续改进。复用经理应当在构件开发和应用项目开发利益之间进行权衡，保证长期目标不受近期项目压力的影响。

9.10 产品线及系统演化

软件企业追求长远的发展，通常采用产品线模型及系统演化策略，它实质上是用架构技术构建产品线，并在此基础上借助复用技术持续演化，不断地推出新产品，满足市场追求产品升级换代的需求。

9.10.1 复用与产品线

软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的。即围绕核心资产库进行管理、复用、集成新的系统。核心资产库包括软件架构及其可剪裁的元素，更广泛地，它还包括设计方案及其文档、用户手册、项目管理的历史记录（如预算和进度）、软件测试计划和测试用例。复用核心资产（特别是软件架构），更进一步采用产品线将会惊人地提高生产效率、降低生产成本和缩短上市时间。

创建一个成功的产品线取决于软件工程、技术管理和组织管理等多个方面的协调，这里只对软件架构方面进行讨论。
基于产品间共性的“软件”产品线代表了软件工程中一个创新的、不断发展的概念。软件产品线的本质是在生产产品家族时，以一种规范的、策略性的方法复用资产。可复用的资产非常广，包括以下几点。

• 需求：许多需求与早期开发的系统相同或部分相同，如网上银行交易与银行柜面交易。

• 架构设计：原系统在架构设计方面花费了大量的时间与精力，系统成功验证了架构的合理性，如果新产品能复用已有的架构，将会取得很好的效益。
  元素：元素复用不只是简单的代码复用，它旨在捕获并复用设计中的可取之处，避免（不要重复）设计失败的地方。

• 建模与分析：各类分析方法（如性能分析）及各类方案模型（如容错方案、负载均衡方案）都可以在产品中得到复用。
  测试：采用产品线可积累大量的测试资源，即在考虑测试时不是以项目为单位，而是以产品线为单位，这样，整个测试环境都可以得到复用，如测试用例、测试数据、测试工具，甚至测试计划、过程、沟通渠道都可以得到复用。

• 项目规划：利用经验对项目的成本、预算、进度及开发小组的安排等进行预测，即不必每次都建立工作分解结构。过程、方法和工具：有了产品线这面旗帜，企业就可以建立产品线级的工作流程、规范、标准、方法和工具环境，供产品线中所有产品复用。如编码标准就是一例。

• 人员：以产品线来培训的人员，适应于整个系列的各个产品的开发。

• 样本系统：将已部署（投产）的产品作为高质量的演示原型和工程设计原型。

• 缺陷消除：产品线开发中积累的缺陷消除活动，可使新系统受益，特别是整个产品家族中的性能、可靠性等问题的一次性解决，能取得很高的回报。同时也使得开发人员和客户心中有“底”。

9.10.2 基于产品线的架构

软件产品线架构是针对一系列产品而设计的通用架构，并在此基础上，进一步将系列产品共用的模块事先实现，供直接重用；将架构用框架的形式予以实现，供定制使用。这就是通常所说的“平台”。
产品线架构较之单个产品架构，有如下三点特别之处：
（1）产品线架构必须考虑一系列明确许可的变化；
（2）产品线架构一定要文档化；
（3）产品线架构必须提供“产品创建者指南”（开发指南），描述架构的实例化过程。

产品线的软件架构应将不变的方面提出来（正因为有不变，才产生了产品线），同时，识别允许的变化，并提供实现它们的机制。通常应考虑三个方面。

（1）确定变化点：确定变化是一项需要持续进行的活动，可以在开发过程的任何时间确定变化。

（2）支持变化点：对变化的支持可以有多种形式，举例如下。
包含或省略元素：如条件编译。包含不同数量的复制元素：如通过添加更多的服务器产生高容量的变体。具有相同的接口但具有不同的行为或质量特性的元素版本的选择：如静态库和动态链接库的使用。在面向对象的系统中，通过特化或泛化特定的类实现变化。通过参数配置来实现变化。

（3）对产品线架构的适宜性进行评估。
评估的内容：必须把评估的重点放在变化点上，以确保它（变化点）提供了足够的灵活性，从而能覆盖产品线的预期范围；它们支持快速构建产品。
评估的时间：应该对用于构建产品线中的一个或多个产品的架构的实例或变体进行评估。产品架构评估的结果通常能提供有用的反馈，推动架构的改进。当提议开发的一个新产品不在最初的产品线的范围内时，则可以重新对产品线架构进行评估，看如何使其容纳新的产品或是否有必要产生一个新的产品线。

9.10.3 产品线的开发模型

开发（确定）产品线的方法有两种模型：
（1）“前瞻性”产品线：利用在应用领域的经验、对市场和技术发展趋势的了解及商业判断力等进行产品线设计，它反映了企业的战略决策。通常是自上而下地采用产品线方法。

（2）“反应性”模型：企业根据以前的产品构建产品家族，并随着新产品的开发，扩展架构和设计方案，它的核心资产库是根据“已经证明”为共有、而非“预先计划”为共有的元素构建的。通常是自下而上地采用产品线方法。一旦确定了产品线，就进入其演变阶段，它是产品线不断向前的发展过程。

9.10.4 特定领域软件架构

架构的本质在于其抽象性。它包括两个方面的抽象：业务抽象和技术抽象。其中业务抽象面向特定的应用领域。特定领域软件架构（Domain Specific Software Architecture，DSSA）可以看做开发产品线的一个方法（或理论），它的目标就是支持在一个特定领域中有多个应用的生成。DSSA 的
必备特征有：

（1）一个严格定义的问题域或解决域；
（2）具有普遍性，使其可以用于领域中某个特定应用的开发；
（3）对整个领域的合适程度的抽象；
（4）具备该领域固定的、典型的在开发过程中的可复用元素。

从功能覆盖的范围角度理解 DSSA 中领域的含义有两种方法：
（1）垂直域。定义了一个特定的系统族，导出在该领域中可作为系统的可行解决方案的一个通用软件架构。

（2）水平域。定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统（族）的特定部分功能。 DSSA 的活动阶段如下。

（1）领域分析：主要目标是获得领域模型。即通过分析领域中系统的需求（领域需求），确定哪些需求是被领域中的系统广泛共享的，从而建立领域模型。

（2）领域设计：这个阶段的目标是获得 DSSA，它是一个能够适应领域多个系统的需求的一个高层次的设计。由于领域模型中的领域需求具有一定的变化性，DSSA 也要相应地具有变化性，它可以通过表示多选一的、可选的解决方案等来做到这一点。

（3）领域实现：主要目标是依据领域模型和 DSSA 开发与组织可复用信息。这些复用信息可以是从现有系统中提取得到的，也可能通过新的开发得到。这个阶段可以看作复用基础设施的实现阶段。

在上述工作中，获得领域模型是基础也是关键，领域建模专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。通常领域模型可用 UML 的类图和状态图表示。

对于中等复杂度的项目，应该在系统的领域模型中找到大约 50 到100 个类。
领域模型的主要作用如下：

（1）领域模型为需求定义了领域知识和领域词汇，这较之单一的项目需求更有较好的大局观；
（2）软件界面的设计往往和领域模型关系密切；
（3）领域模型的合理性将严重影响软件系统的可扩展性；
（4）在分层架构的指导下，领域模型精化后即成为业务层的骨架；
（5）领域模型也是其数据模型的基础；
（6）领域模型是团队交流的基础，因为它规定了重要的领域词汇表，并且这些词汇的定义是严格的、大家共同认可的。

9.10.5 架构及系统演化

架构虽然为系统的变化提供了一定的自由度，但是系统的较大变化必然导致架构的改变。

架构（系统）演化是指向既定的方向、可控地改变。架构（系统）演化可以形成产品线，反过来，架构（系统）可以在规划的产品线中进行演化。 架构（系统）演化过程包含 7 个步骤，如图 9-22 所示。

（1）需求变动归类。首先，必须对用户需求的变化进行归类，使变化的需求与已有构件对应。对找不到对应构件的变动，也要做好标记，在后续工作中，将创建新的构件，以对应这部分变化的需求。

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

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

（4）更新构件的相互作用。随着构件的增加、删除和修改，构件之间的控制流必须得到更新。

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

（6）技术评审。对以上步骤进行确认，进行技术评审。评审组装后的架构是否反映需求变动，符合用户需求。如果不符合，则需要在第（2）到第（6）步之间进行迭代。

（7）产生演化后的架构。在原来系统上所作的所有修改必须集成到原来的架构中，完成一次演化过程。

9.11 软件架构视图

9.10 节从软件架构本身的特点出发讨论了架构建模及与特定应用领域密切相关的架构风格。本节将从对架构编档的角度对软件架构视图及其风格进行讨论。

9.11.1 软件视图的分类

现代软件系统非常复杂，通常在某个具体的时间内只需将注意力集中在某几个结构上（就像看病时，医生只是将注意力集中在某方面的人体结构上，骨科医生与心血管科医生关心不同的结构），结构是元素本身的集合，而视图则是捕获和表达结构（文档描述），虽然它们有区别，但在实际使用时则不严格区分，即从系统体系的角度说是结构，从文档角度说是视图，因此，本节将不再区分结构和视图术语。

软件架构是一种无法以简单的一维方式进行说明的复杂实体，从不同侧面的描述就是视图。架构的优势也在于使用视图：每个视图强调系统的某一个方面，同时忽视系统的其他方面，以便有助于处理或理解当前问题，描述完整的系统架构必须具备完整的视图集，“4+1”方法就是一类完备视图集。

软件视图通常分为三种类型：
（1）模块视图类型：为系统的主要模块实现单元编档。
（2）构件和连接件视图类型：为系统的构件和连接件执行单元编档。
（3）分配视图类型：为软件的开发和执行环境之间的关系编档。每一视图类型中，又有一些常用的形态，可以把这些形态归纳成架构风格（简称风格），
大量的架构风格供架构设计师选用，例如客户机/服务器是一种常见的架构风格，它是构件和连接件视图类型中的一员。架构风格是对元素和关系类型的特化，它还包括如何使用这些元素和关系类型的一组限制条件。架构结构/视图分类如表 9-10 所示。下面各小节中再分别对这三种类型及其风格从元素、关系及特征方面做进一步总结。

9.11.2 模块视图类型及其风格
模块将遵循某种方式将软件系统分解成可管理的功能单元。架构模块视图是通过文档来枚举系统的主要实现单元或模块，及这些单元之间的关系。

任务完整的架构文档必须包含有模块视图，它为源代码提供蓝图。该类型如表 9-11 所示。

下面对模块视图的四种风格进行总结。
（1）分解风格能展示向模块分配责任的方式。该风格总结如表 9-12 所示。

（2）使用风格能展示模块相互依赖的方式。该风格总结如表 9-13 所示

（3）分层风格能将系统分割成一组虚拟机，通过“允许使用”关系相互关联，分层风格能帮助实现可移植性和可修改性。该风格总结如表 9-14 所示。

（4）泛化风格能展示一个模块如何成为另一个模块的泛化或特化，从而使模块之间产生关联。它广泛应用于面向对象的系统，能展示继承性，并能用来使用模块之间的共性。该风格总结如表 9-15 所示。

9.11.3 C&C 视图类型及其风格

C&C 视图能定义由具有某种运行时存在的元素模型，这些元素包括进程、对象、客户机、服务器及数据存储器等。此外，它还包含作为元素的交互路径，如通信链路和协议、信息流及共享存储器访问。通常，可利用复杂的基础结构（如中间件框架、分布式通信信道和进程调度）来执行这些交互操作。该类型总结如表 9-16 所示。


C&C 视图风格是 C&C 视图类型的特化，C&C 视图风格为数不少，下面对 C&C 视图的几种风格进行总结。
（1）管道和过滤器风格中的交互模式表现出数据流连续变换的特征。数据抵达过滤器并经过转换后由管理传送给下一个过滤器。该风格总结如表 9-17 所示。

（2）共享数据风格通过保留持久数据来支配交互模式，持久数据由多个数据存取器和至少一个储存库保留。该风格总结如表 9-18 所示

（3）发布-订阅风格用于向一组未知接受者发送事件和消息。可在不修改生产者的情况下添加新的接受者（订阅者）。在发布-订阅风格中，构件通过事件发布进行交互。构件可订阅一组事件。该风格总结如表 9-19 所示。

（4）客户机-服务器风格能展示构件通过请求其他构件的服务进行交互的过程，将功能划分成客户机和服务器后即可基于运行时准则把它们单独分配给各个级。该风格总结如表9-20 所示。

（5）对等连接系统能通过构件之间的直接交换支持服务交换。它是一种调用/返回风格。该风格总结如表 9-21 所示。

（6）通信-进程风格的特征表现在通过各种连接件机制并发执行构件的交互，如通过同步、消息传递、数据交换、启动和停止等进行交互。该风格总结如表 9-22 所示。

9.11.4 分配视图类型及其风格

硬件、文件系统和团队结构都会与软件架构进行交互，将软件架构映射到其环境的一般形式称为“分配视图类型”。该类型总结如表 9-23 所示。

分配视图类型的三种常见风格为：
部置风格：能描述构件和连接件对硬件的映射，硬件是软件执行的场所。
实现风格：能描述模块对包含它们的文件系统的映射。
工作任务风格：能描述模块对承担模块开发任务的人员、团队或小组的映射。

（1）部置风格体现为 C&C 风格（如通信-进程风格）的元素被分配到执行平台。该风格总结如表 9-24 所示。

（2）实现风格能将模块视图类型中的模块映射到开发基础结构。实现一个模块总会产生许多独立文件，必须对这些文件进行组织，以免失去对系统的控制及系统的完整性。通常利用配置管理技术进行文件管理。该风格总结如表 9-25 所示。

（3）软件项目的时间和预算估计取决于工作分解结构（WBS），而工作分解结构则取决于软件架构。工作任务风格将软件架构映射到由人组成的团队之中，实现这一项目管理的目的。该风格总结如表 9-26 所示。

工作任务风格与模块分解风格关系密切，它能将模块分解风格用作其分配映射的基础。

这种风格能通过添加与开发工具、测试工具和配置管理系统等对应的模块分解进行扩展。工作任务风格还通常与其他风格联合使用，例如，团队工作任务可以是模块分解风格中的模块，可以是分层图中的层，也可以是多进程系统中的任务或进程。

9.11.5 各视图类型间的映射关系

为了完整地描述一个架构，必须使用多个视图，这些视图必须遵守一定的映射关系。

（1）模块视图类型中的视图通常会映射到构件和连接件视图类型中的视图。模块实现单元将映射到运行时构件。

（2）系统的构件和连接件视图和模块视图之间的关系可能会非常复杂。同样的代码模块可由 C&C 视图的许多元素执行。反之，C&C 视图的单一构件可执行由许多模块定义的代码。同样，C&C 构件可能会拥有许多与环境进行交互的点，每个交互点由同一模块接口定义。

（3）分配视图类型是为有效地实现软件架构的辅助性视图，它将其他视图类型中的软件元素映射到软件环境中，即反映其他视图与软件环境之间的关系。