简介：为了构建更精确的模型，尽可能接近实际的相关业务，我们通常需要添加约束。为了显示怎样构建有用和精确的域模型，本文介绍了如何使用 IBM? Rational? Software Architect 以及 EMF 确认框架，以 UML 和 OCL 写成的域模型的确认过程。
软件建模在传统上成为产生图表的一个同义词。大多数的模型由一系列的序列和箭头组成。这样的模型所传递的信息，有一种趋势会不完整，不规范，不精确，有时甚至会不稳定。因此，软件建模的一个目标，就是创建一个精确且足够规范的模型。
精确域模型的需求
让我们拿系谱树形结构作为一个范例，从图 1 之中的图表开始。系谱树形视图的 UML 模型显示了一个 Person 是由名字和性别定义的，并且可以有或者没有小孩。而且，它显示了一个 Person 拥有两个小孩，小孩也是 Person。这意味着两个小孩可以有相同的性别，但是这在遗传上是不可能的。因此，该模型是不精确的。
图 1. 系谱树形模型
一个 UML 图，例如一个类图，通常不够精确来提供一个业务模型的所有相关元素。它可以通过多种政策来表达约束，但是其他的约束仍然不够清晰。如果我们需要为模型对象描述其他的约束，那么通常可以以一种自然语言来描述它们。该实践还显示了它导致了模糊性的产生。
您可以开发一个规范语言来避免这些模糊性。传统规范语言的劣势在于，它们是由拥有稳固数学知识的人员使用的，使用它来建模系统很困难。您可以开发 OCL（对象约束语言）来填补这个空白。这就是一种读起来和写起来都很轻松的规范语言。以 OCL 写成的表达式可以得到理解，并且不会在不同角色的人员之间产生差异，这些人员例如分析员，开发员。
为了创建一个精确且完整的模型，我们需要 UML 图表及 OCL 表达式。没有 OCL 表达式，那么模型就是严重未指定的。对于类和联系的代表来说，UML 图表仍然是不可或缺的，但是 OCL 表达式会参考尚不存在的模型元素，因为在 OCL 中尚没有方法去指定类与联系。当我们合并图表和约束时，才能够完整地指定模型。
至于如图 1 所示系谱树形视图中指定的模型，我们需要添加这些约束，来指定两个父类拥有不同的属性：
{ self.parents->asSequence()->at(1).sex <> self.parents->asSequence()->at(2).sex }
图 2. 带有 OCL 约束的系谱树形模型
而且，模型的规模和数量会得到极大的增加，使得公司不能完整发挥 MDA（模型驱动结构）的优势。系统由数以百计的模型组成，而模型又由数以千计的元素组成。使用 MD 技术能够获得较大的改进。但是，分析阶段确认模型仍然存在许多问题。有很多程序不能理解以 OCL 写成的约束。
就算代码生成过程之中能够转化代码的约束，在编码开始之前仍然应该确认模型及其约束。因此，分析阶段最终的错误可以尽早地检查到，而不用对开发规划造成什么大的影响。
模型确认的结果对分析阶段会产生一定的影响。
约束并不适合：
- 如果约束太强，那么许多实例并不满足约束的条件。在这些情况下，为方便大多数的实例可以放松约束。
- 如果约束太弱，会出现系统不想要出现的一些情况。在这种情况之下，约束并不具有较强的限制性。
我们的目标是构建更好的域模型。
模型不能适应选择的约束，在这种情况下应该编辑它。
- 一方面，它生成了特定模型的实例，并自动确认它们是否与已有的 OCL 约束兼容。
- 另一方面，可视化使得分析员能够更轻松地发现和校正域模型之中的模糊性或者不稳定性。
让我们考虑一下如图 3 所示的系谱树形模型的一个实例。
图 3. 系谱树形模型实例
我们可以看到两个父类拥有相同的属性，这在条件下是不可能的。
因此，我们拥有合并的 UML 与 OCL，来帮助分析员提高域模型的质量。OCL 表达式会得到评价，并且仍然不会得到注释（这就是今天 Rational Software Architect 的实例）。但是，分析员就是决定做出什么更改的人，并且由他来决定应该添加什么约束来构建更精确的模型。
实施
第一眼看上去时，会觉得上面提到的插件实施起来不可能，因为我们不能评价模型层次上的 OCL 约束。Rational Software Architect 中提供的 API 并不支持评价 OCL 约束。
我们所实施的方案就是执行以下的这些步骤：
- UML model > Ecore model（使用已有的 Rational Software Architect 向导）
- Ecore model > Generator model（使用已有的 Rational Software Architect 向导）
- Generator model > EMF code（使用已有的 Rational Software Architect 功能）
- 使用已有的 EMF 模型来评价 OCL 约束
图 4 演示了这个过程。
图 4. 进程
现在我们要从测试员的观点来解释进程。
域模型的范例
为了演示前面章节之中描述的进程，我们要使用库的域模型，如图 5 所示。
图 5. 库域模型
图 6 显示了进程开始时项目是什么样的。您可以看到在 LibraryExample 项目之中只有叫做 Analysis 的 UML 模型，它包含的类有：BookCopy，BookReference，Company，Contract，Loan，Penalty，Reservation 以及 User。
图 6. 原始的项目
如上所述，UML API 并不支持在模型层次上评价 OCL 表达式。在搜索一些之后，我们已经注意到 Eclipse Modeling Framework（EMF）API 支持 OCL 评价。现在，EMF 代码可以从 Ecore 模型生成。您可以在 Rational Software Architect 中作出转变，这样我们可以使用已有的向导来生成它，稍后也能够评价 OCL 限制因素。
从 LibraryExample 转化之后的 M2M 获得的 Ecore 模型如图 7 所示。
图 7. M2M 之后的 Ecore 模型
项目如图 8 所示，其中添加了 Project Explorer 视图。现在您可以看到有两个叫 Analysis 的模型：一个 UML 模型和一个 Ecore 模型。
图 8. 带有 Ecore 模型的 Rational Software Architect 项目
EMF 让我们生成了一个代码，您可以使用该代码来创建模型实例，我们可以使用它来完成生成操作。图 9 显示了包含生成代码的更新项目。
图 9. 带有生成源代码目录的项目
上面描述的两步应该由确认模型的人员手动完成。在完成之后，实例的生成和 OCL 表达式的评价就可以开始了。
生成实例
本文描述了完整的生成规则。
出于简便性的考虑，我们将会使用类图（entryDiagram），它包含了三类：User，Contract 与 Company。在这里的范例之中，我们将会假设库向相关公司雇佣的每一个人提供了信息。在这里的范例之中，雇员与库之间没有协议，但是与他所服务的公司有，所以，我们要添加以下的限制条件（同样见于图 10）：
{self.contract->notEmpty()xor self.company <> null}
图 10. 输入表
评价结果的 OCL 约束以及可视化
与约束相关的实例拥有 _OK 的后缀，而其他的实例拥有 _KO 后缀：
图 11. 生成的对象图
让我们进一步查看一下两个实例。
在图 12 之中，我们可以看到实例关注 User 类的限制性因素。确实，识别为 userT6D 的用户拥有 contractQYR 协议，而且他不是相关公司的雇员（与 Company 类型的实例没有联系）。
图 12. 关注约束的实例
相反，我们可以看到图 13 之中的实例并不关注约束，因为其中一个用户是公司（companyJ5U）的雇员，而且拥有库的订阅协议（contract61D）。
图 13. 不关注约束的实例
我们已经决定查看非关注的约束实例，这样我们可以检测到选择的约束是否够强。如果没有太多创建的约束，那么这一点就很明显。
可能的未来发展
因为我们必须要使用 Rational Software Architect UML 框架，它尚不支持 OCL 表达式的评价，所以 Ecore 模型的生成就变得特别重要了。在应用到大型模型时，这个过程可以产生较大的回报。
另一方面，它可以阻止我们进行较短的迭代，例如下面的进程：
Modeling > Model Validation > Model Modification > Model Validation > …
从这一方面，我们可以将进程开始的自动化当做可能的未来发展方向：
- M2M 转化 UML > Ecore 的自动化
- 从 Ecore 模型生成代码的自动化
图 14. 非自动化的进程
该自动化给用户带来了更多的简便性，因为他们不用手动地运行 RSA 提供的向导，以构建 M2M 转化并生成代码。
参考资料
学习
| 
