软件产品架构深度剖析与解析

产品线及系统演化

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

1 复用与产品线

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

创建一个成功的产品线取决于软件工程、技术管理和组织管理等多个方面的协调，这里只对软件架构方面进行讨论。

基于产品间共性的“软件”产品线代表了软件工程中一个创新的、不断发展的概念。软件产品线的本质是在生产产品家族时，以一种规范的、策略性的方法复用资产。可复用的资产非常广，包括以下几点。

• 需求：许多需求与早期开发的系统相同或部分相同，如网上银行交易与银行柜面交易。
• 架构设计：原系统在架构设计方面花费了大量的时间与精力，系统成功验证了架构的合理性，如果新产品能复用已有的架构，将会取得很好的效益。
• 元素：元素复用不只是简单的代码复用，它旨在捕获并复用设计中的可取之处，避免（不要重复）设计失败的地方。
• 建模与分析：各类分析方法（如性能分析）及各类方案模型（如容错方案、负载均衡方案）都可以在产品中得到复用。
• 测试：采用产品线可积累大量的测试资源，即在考虑测试时不是以项目为单位，而是以产品线为单位，这样，整个测试环境都可以得到复用，如测试用例、测试数据、测试工具，甚至测试计划、过程、沟通渠道都可以得到复用。
• 项目规划：利用经验对项目的成本、预算、进度及开发小组的安排等进行预测，即不必每次都建立工作分解结构。
• 过程、方法和工具：有了产品线这面旗帜，企业就可以建立产品线级的工作流程、规范、标准、方法和工具环境，供产品线中所有产品复用。如编码标准就是一例。
• 人员：以产品线来培训的人员，适应于整个系列的各个产品的开发。
• 样本系统：将已部署（投产）的产品作为高质量的演示原型和工程设计原型。
• 缺陷消除：产品线开发中积累的缺陷消除活动，可使新系统受益，特别是整个产品家族中的性能、可靠性等问题的一次性解决，能取得很高的回报。同时也使得开发人员和客户心中有“底”。

2 基于产品线的架构

软件产品线架构是针对一系列产品而设计的通用架构，并在此基础上，进一步将系列产品共用的模块事先实现，供直接重用；将架构用框架的形式予以实现，供定制使用。这就是通常所说的“平台”。

产品线架构较之单个产品架构，有如下三点特别之处：

1）产品线架构必须考虑一系列明确许可的变化；

2）产品线架构一定要文档化；

3）产品线架构必须提供“产品创建者指南”（开发指南），描述架构的实例化过程。

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

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

2）支持变化点：对变化的支持可以有多种形式，举例如下。

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

3）对产品线架构的适宜性进行评估。

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

3  产品线的开发模型

开发（确定）产品线的方法有两种模型：

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

2）“反应性”模型：企业根据以前的产品构建产品家族，并随着新产品的开发，扩展架构和设计方案，它的核心资产库是根据“已经证明”为共有、而非“预先计划”为共有的元素构建的。通常是自下而上地采用产品线方法。

一旦确定了产品线，就进入其演变阶段，它是产品线不断向前的发展过程。

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）领域模型是团队交流的基础，因为它规定了重要的领域词汇表，并且这些词汇的定义是严格的、大家共同认可的。

5  架构及系统演化

架构虽然为系统的变化提供了一定的自由度，但是系统的较大变化必然导致架构的改变。架构（系统）演化是指向既定的方向、可控地改变。架构（系统）演化可以形成产品线，反过来，架构（系统）可以在规划的产品线中进行演化。

架构（系统）演化过程包含 7 个步骤，如图 9-22 所示。

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

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

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

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

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

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

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

免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删