级别： 中级 Lee Ackerman, 高级产品经理, IBM
Michael Wahler, 研究员,
IBM
Scott Schneider, 高级软件工程师, IBM
2008 年 11 月 06 日 本文讨论了 IBM® Constraint Patterns and Consistency Analysis，这是 IBM® Rational® Software Architect 的一个扩展。该工具简化了基于模式的，一致性维护 UML 类模型的细化。它在模型的启发、简明规格说明、一致性分析，和类模型中约束的代码生成上为模型开发人员提供支持。这样，您就能够简化创建较精确的模型的方式，并通过被已被广泛实证的最佳实践和自动化方法利用对象约束语言（Object Constraint Language，OCL）和约束。
引言
当您将 UML 模型用作系统的蓝图，或转换的输入时 —— 举例来说，在模型驱动的体系结构（Model Driven Architecture，MDA）中 —— 成功的关键是在模型中提供适当的精确级别。向模型添加精确度的一种已证实的方法是通过使用约束和 OCL。然而，用文本约束细化类模型是耗费时间并且易于出错的任务。在最坏的情况下，由于矛盾的约束，约束规范可能非故意的不一致。
当您使用模型驱动的开发（Model Driven Development，MDD）方法进行软件开发时，您的成功一贯依赖于抽象的使用。同样，当您创建解决方案时，您可以指望使用许多模型。每个模型存在于特殊的抽象层次，在省去此时不重要的细节的同时，强调解决方案的特定方面。在一些情况下，您可以使用自动化在不同的抽象层次间转移。
一般，您将模型用于三个关键目的：
- 记录或编制设计
- 与其他人交流解决方案
- 生成其他工件
然而，您经常忽视（或不能）在模型中加入适当级别的精确度。同样，这限制了三个类别中的模型有效性。在编制设计的情况下，设计的价值局限于模型的精确程度。当您与其他人交流时，如果模型不够精确，那么就会有多种解释。最后，在由模型生成工件的情况下，模型中缺乏精确度将限制输出的细节和完全性，增加相关自动化的复杂性。
您可以通过模型约束的规范和集合来增加模型的精确度。模型约束是限制模型及其元素的约束，并进一步精化建模者的意图。这些约束用额外的语义强化层标来注模型，超出了只在基础 UML 中可表示的内容。
IBM 已经开发了一个新的 MDD 和基于模式的工程（PBE）过程，以及相关的工具，它简化并自动化了模型中约束的使用。这意味着您能够克服阻止建模者使用约束的障碍。该过程和工具降低了使用约束的技术要求，简化了约束的应用，并且采用以一致的方式应用约束的方法。用一致的方式应用约束意味着您拥有一组不包含任何矛盾约束的约束。
该过程的核心包含一个允许您在保存模型的一致性的同时用约束细化类模型的基于模式的方法。因为 MDD 的成功很强地依赖于工具支持，所以这组 IBM Rational Software Architect 插件使得用对象约束语言（Object Constraint Language，OCL）[1] 中的约束能够一致地保存 UML 类模型的精化。这些插件是被捆绑为 IBM Constraint Patterns and Consistency Analysis 的资产。本文将向您概述其特性和好处。另外，如果您有兴趣在 Rational Software Architect 中构建您自己的模式，那么这些模式和自动化将为您提供可能的想法。
IBM Constraint Patterns and Consistency Analysis 的概述
IBM Constraint Patterns and Consistency Analysis 工具支持您为类模型开发简洁且一致的约束规范。这将形成更精确的模型，导致：
该工具由四个能够让您得到这些结果的关键组件组成。这些组件利用来自 Rational Software Architect 的许多组件，以及底层的 Eclipse 平台。这些组件及支持的 Rational Software Architect 元素如图 1 所示。
图 1. IBM Constraint Patterns and Consistency Analysis 组件
约束启发
当开发软件时，在您构建解决方案的过程中，您经常使用模式 —— 在给定环境中，对已知问题的已证实的最佳实践解决方案。同样重要的是，记住会有反模式。反模式是 已知的最坏的模式 ，例如“通过公开地暴露实例变量来违反对象状态封装”。同样地，您在避免反模式的同时寻求利用模式。
一般，反模式自然地形成一个或多个应用于补救不合需求的情况的模式。要补救前面提到的反模式，您可以“隐藏暴露的实例变量，并且提供公开暴露的增变方法和访问方法，适用于访问对象状态”。
约束启发组件搜索类模型，寻找预定义的反模式的出现。这些反模式包含过于松散定义的模型元素，因而可能需要通过增加文本的约束来精化。
反模式的一个实例是关联端上面的多重性的无限边界（一般由星号表示）。但是，关联的多重性经常不是任意的，而依赖于属性值，这不能用图形建模语言，例如 UML 类模型来表示。
Constraint Elicitation 选项卡，如图 2 所示，显示了在表格中展示分析结果（一列检测到的反模式）的视图。
图 2. 检测到的反模式
每个结果由一个上下文（举例来说，匹配反模式的类）和一个问题描述组成。不是所有的结果都表示实际的问题，但是，您应该浏览列表，忽略不相关的结果，并且对实际问题作出反应。为此，每个分析结果都提供一个环境菜单，在此可以自动地用例子说明各自问题的模式解决方案，如下面的子部分所述。
约束模式的存储库
当您对解决方案建模时，对约束的使用没有应该的频繁。遗漏的原因各种各样，但可以包含以下内容：
-
认识：人们没有意识到约束，以及它们为模型增加的价值
-
时间：人们知道应该使用约束，但向模型中添加约束是耗费时间的
-
专家经验：即使有时间和意识，一些人也不会使用约束，因为他们缺乏正确使用约束的专家经验。这包含通常的约束（举例来说，不知道什么能形成好的约束），和缺乏了解如何在模型中实现约束。
为了处理这些问题，IBM Constraint Patterns and Consistency Analysis 提供了 约束模式 存储库，封装了简单快速地向模型添加约束所需的专家经验。约束模式 [7] 是 可以被例化并随后配置的，用于简洁地开发约束的预定义的约束表达式。它们是约束启发组件重要的补充，因为您可以将每个反模式与一组可以例化从而消除模型中的反模式的约束模式相结合。
图 3 提供了 IBM Constraint Patterns and Consistency Analysis 支持的模式概要。
图 3. 支持的模式
Rational Software Architect 向任意模式的框架提供了一个标准化的接口，包括从内部向开发人员提供和从外部向用户提供。IBM Constraint Patterns and Consistency Analysis 构建于此框架之上，并且添加了 Model-Driven Constraint Engineering
[7] 中介绍的组成的约束模式库。该库也是可扩展的，这使得能够在将来进一步添加约束模式。
此外，您的约束模式库包含每对模式之间的依赖。为此，您在可以用一致性维护的方式实例化模式的假设下存储每个模式。不论何时变更了模式实例的参数值，IBM Constraint Patterns and Consistency Analysis 都会估计是否该实例保护了模型的一致性。
一致性分析
扼要地说，本文已经讨论了找到模型中问题的组件，并且快速且简单地通过约束模式应用程序修复它们。但是，您还需要确保模型中的约束可以一致地应用。因此，IBM Constraint Patterns and Consistency Analysis 提供了一致性分析，警告已知的基于模式的约束规范中的不一致性。当约束互相矛盾时会出现不一致性。举例来说，约束 i>=0 和 i<0 互相矛盾，因为没有值能让属性 i 满足这两个约束。
 |
可判定性
注意：分析只能回答“是”或“不知道”的原因是模式的语义是根据 OCL 定义的，这是不可判定语言。这意味着它违抗了自动的且完全的一致性分析。
在不能显示一致性的情况下，您可以导出模型并且使用外部的工具，例如 USE [4] 或 HOL-OCL [3] 来证明或反驳一致性，如 [2] 所述。或者，您可以手工检查不能显示一致性的约束是否一致。然而，这需要 OCL 专家经验（参考 [2]）。
|
|
分析使用了模式存储库中存储的一致性假设。对于每个模式，分析检查假设是否有效。在第一种情况下，约束规范是一致的，在第二种情况下，不能对一致性给出结论。
代码生成
Rational Software Architect 包含支持开发及执行模型转换的转换框架。IBM Constraint Patterns and Consistency Analysis 构建于此框架之上，并且提供将模式实例转换为形式语言的语句的模型转换。
到目前为止，您已经依据 Model-Driven Constraint Engineering
[7] 实现了到 OCL 的转换。然而，可以很容易地用到规范语言，例如 Alloy、Eiffel，或 Java™ Modeling Language（JML）的转换扩展 IBM Constraint Patterns and Consistency Analysis。
使用 IBM Constraint Patterns and Consistency Analysis
在高层次上，当使用 IBM Constraint Patterns and Consistency Analysis 时，您会看到如图 4 所描绘的工作流。
图 4. 启发、规范、分析，和生成
当使用 Rational Software Architect 中的工具时，您将与以下视图中的组件交互，如图 5、6，和 7 中所示。
图 5. Pattern Explorer
图 6. Constraint Elicitation 视图
图 7. Diagram Editor（Model Explorer）
点击查看放大的图像
所包含的一个实例模式是 NoCyclicDependency。该模式用于禁止模型元素之间的循环依赖（举例来说，不存在从对象到其本身的连接）。
图 8 显示了带有 IBM Constraint Patterns and Consistency Analysis 插件的 Rational Software Architect 屏幕快照。最大的视图包含一个小的类模型，以及 NoCyclicDependency 模式的实例。在此视图中，可以通过拖拽控制 模型 并且参数化模式实例。下面，Constraint Elicitation 视图 显示了约束启发组件的结果。如说明，在此视图中可以利用每项的环境菜单实例化约束模式。
图 8. IBM Constraint Patterns and Consistency Analysis 原型的屏幕快照
点击查看放大的图像
窗口的底部包含两个视图。第一个，一致性分析的结果显示在 Rational Software Architect 的 Problems 视图中的左下角。第二个视图是前面提到的 Pattern Explorer，它显示了带有描述的可用模式，并提供了拖拽实例化机制。
下面是使用 IBM Constraint Patterns and Consistency Analysis 的典型场景。
考虑以下简单的类图，如图 9 所示。快速地看一眼图可能让建模者认为他们已经成功地对 Managers 和 Employees 之间的关系建模了。然而，如模型目前所表示的，Manager 可能会为自己工作。有经验的建模者可能会快速地找到这个问题，但其他人可能直到代码生成之后才注意到。
图 9. Employee 和 Manager 关系图
如果您会写 OCL，那么您可以向模型添加注明，详细说明经理不能管理自己的事实，如图 10 所示。
图 10. 属性不允许循环依赖
现在您已经增加了另一层次的所需的专家经验。除了定位反模式，并了解如何修复解决方案，您还需要知道如何用 OCL 详述解决方案。
与此相反，通过利用 IBM Constraint Patterns and Consistency Analysis，您可以大大简化此场景，如下所示：
- 使用 Constraint Elicitation 识别模型中的反模式。在这种情况下，工具提示您在模型中拥有循环依赖，如图 11 所示。
图 11. 反模式列表
点击查看放大的图像
- 使用其中一个已知的补救模式来修复该问题，如图 12 所示。
图 12. NoCyclicDependency 模型元素
- 使用一致性分析特性来确保您已经在模型中一致地使用了约束（这在此简单的实例中是过多的，但在此加入是为了完全性）。
- 用 OCL 生成必要的约束，如图 13 所示。
图 13. 不允许循环依赖
- 和 IBM Constraint Patterns and Consistency Analysis 一起安装的 cheat sheet 指导您（作为开发人员）完整的过程。您可以通过选择 Help > Cheat Sheets 来显示步骤说明书。
- 在 Other 分类中，您可以找到标签为 Refine class models with constraint patterns 的步骤说明书，如图 14 所示。单击 OK。
图 14. 选择要打开的步骤说明书
- 包含步骤说明书的新视图打开了，如图 15 所示。步骤说明书指导您逐步地通过整个过程。如果您需要关于使用步骤说明书的帮助，请查阅 Rational Software Architect 文档。
图 15. 用约束模式步骤说明书精化类模型
总结及未来工作
本文已经介绍了 Rational Software Architect 的扩展，IBM Constraint Patterns and Consistency Analysis，它涉及了利用约束模式进行一致的模型精化。通过利用此工具，您能够令您的模型更精确，这将形成更好的设计，更清楚的交流，以及更好的代码生成。此外，您能够在降低创建更精确的模型所需的技能需求的同时完成这些结果。
该工具通过实现附加的模型转换，并在代码生成过程中利用转换来与其他规范语言（代替 OCL）兼容。
参考资料 学习
获得产品和技术
讨论
作者简介 | | | Lee Ackerman 是 IBM Rational Learning Services 和 Solutions 团队的高级产品经理。他专注于创建能够让 Rational 模型驱动开发工具的用户成功创建 J2EE 和 SOA 解决方案的智能资本资产。 |
| | | Michael Wahler 是 IBM Zurich Research Laboratory 中 Business Integration Technologies 组的博士生。2003 年，他在德国 Technical University of Munich 获得了文凭，并在 2008 年 1 月，在瑞士的苏黎世的 Swiss Federal Institute of Technology 提交了计算机科学的 Ph.D. 论文。
Michael 的研究着重于开发可靠软件的工程方法，特别涉及模型驱动的软件开发。它目前致力于数据建模领域，为此他正在开发简洁的一致性维护类模型的细化的模式方法。 |
| 
| | Scott E. Schneider 居住并且工作在北卡罗来纳的 Research Triangle Park 附近，在 IBM Rational 中领导模式工具开发，专攻操作模型的模式的规范和自动化。Scott 在 Georgia Institute of Technology 获得电子工程学士学位，专业为数字信号处理和计算机科学。Scott 是 International Journal of Patterns 的副编辑和专栏作家，并且经常在技术会议上演讲，例如 EclipseCon、EclipseWorld，和 IBM Rational Software Development Conference。 |
对本文的评价
| 
