对象约束语言简称OCL

对象约束语言简称OCL(Object Constraint Language)，它是一种用于施加在指定的模型元素上约束的语言。

OCL表达式以附加在模型元素上的条件和限制来表现对该对象的约束，其中包括附加在模型元素上的不变量或约束的表达式，附加在操作和方法上的前置条件和后置条件等。

对象约束语言概述
对象约束语言是一种形式化语言，它主要用于表示UML模型中施加于模型上的约束。

OCL具有如下特点：
1、OCL是一种精确的，无二义性的语言
2、OCL是一种规范说明性语言，所有有关实现的问题都不能用OCL来表达
3、OCL是一种纯表达式语言，它是具有没有任何副作用的申明性语言。

4、OCL是一种类型化语言，即OCL中的每一个表达式都是具有类型的。

5、OCL不是一种程序设计语言，不能用OCL编写程序逻辑和控制流程。

标准OCL类型
OCL预定义的标准类型定义了一组基本类型和集合类型。

OCL的基本类型有"Boolean"、"Integer"、"Real"、"String"等。

集合类型包括"Collection"、"Set"、"Bag"、"Sequence"等。

这些标准型是OCL表达式的组成部分。

OCL标准型的层次结构如下：
OCL表达式
OCL表达式对于一个OCL类型求值。

OCL表达式有以下特点：
1、OCL表达式可以附加在模型元素上，模型元素的所有实例都应该满足表达式的条件。

2、OCL表达式可以附加在操作上。

3、OCL表达式可以指定附加在模型元素上的监护条件。

4、OCL表达式的计算顺序是从左到右。

5、OCL表达式既可以使用基本类型又可以使用集合类型。

用OCL表达对象性质约束
OCL表达式可以附加在模型元素或模型元素的属性和操作上表达一个约束
条件。

精确域模型的需求
让我们拿系谱树形结构作为一个范例，从图 1 之中的图表开始。

系谱树形视图的UML 模型显示了一个Person 是由名字和性别定义的，并且可以有或者没有小孩。

而且，它显示了一个Person 拥有两个小孩，小孩也是Person。

这意味着两个小孩可以有相同的性别，但是这在遗传上是不可能的。

因此，该模型是不精确的。

图 1. 系谱树形模型
图 2. 带有OCL 约束的系谱树形模型
而且，模型的规模和数量会得到极大的增加，使得公司不能完整发挥MDA（模型驱动结构）的优势。

系统由数以百计的模型组成，而模型又由数以千计的元素组成。

使用MD 技术能够获得较大的改进。

但是，分析阶段确认模型仍然存在许多问题。

有很多程序不能理解以OCL 写成的约束。

就算代码生成过程之中能够转化代码的约束，在编码开始之前仍然应该确认模型及其约束。

因此，分析阶段最终的错误可以尽早地检查到，而不用对开发规划造成什么大的影响。

模型确认的结果对分析阶段会产生一定的影响。

约束并不适合：
∙如果约束太强，那么许多实例并不满足约束的条件。

在这些情况下，为方便大多数的实例可以放松约束。

∙如果约束太弱，会出现系统不想要出现的一些情况。

在这种情况之下，约束并不具有较强的限制性。

我们的目标是构建更好的域模型。

模型不能适应选择的约束，在这种情况下应该编辑它。

∙一方面，它生成了特定模型的实例，并自动确认它们是否与已有的OCL 约束兼容。

∙另一方面，可视化使得分析员能够更轻松地发现和校正域模型之中的模糊性或者不稳定性。

让我们考虑一下如图 3 所示的系谱树形模型的一个实例。

图 3. 系谱树形模型实例
我们可以看到两个父类拥有相同的属性，这在条件下是不可能的。

因此，我们拥有合并的UML 与OCL，来帮助分析员提高域模型的质量。

OCL 表达式会得到评价，并且仍然不会得到注释（这就是今天Rational Software Architect 的实例）。

但是，分析员就是决定做出什么更改的人，并且由他来决定应该添加什么约束来构建更精确的模型。

回页首实施
第一眼看上去时，会觉得上面提到的插件实施起来不可能，因为我们不能评价模型层次上的OCL 约束。

Rational Software Architect 中提供的API 并不支持评价OCL 约束。

我们所实施的方案就是执行以下的这些步骤：
1. UML model > Ecore model（使用已有的Rational Software
Architect 向导）
2. Ecore model > Generator model（使用已有的Rational Software
Architect 向导）
3. Generator model > EMF code（使用已有的Rational Software
Architect 功能）
4. 使用已有的EMF 模型来评价OCL 约束
图4 演示了这个过程。

图 4. 进程
现在我们要从测试员的观点来解释进程。

域模型的范例
为了演示前面章节之中描述的进程，我们要使用库的域模型，如图 5 所示。

图 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. 带有生成源代码目录的项目
图10. 输入表
评价结果的OCL 约束以及可视化
与约束相关的实例拥有_OK的后缀，而其他的实例拥有_KO后缀：图11. 生成的对象图
让我们进一步查看一下两个实例。

在图12 之中，我们可以看到实例关注User 类的限制性因素。

确实，识别为userT6D 的用户拥有contractQYR 协议，而且他不是相关公司的雇员（与Company 类型的实例没有联系）。

图12. 关注约束的实例
图12 的大图
相反，我们可以看到图13 之中的实例并不关注约束，因为其中一个用户是公司（companyJ5U）的雇员，而且拥有库的订阅协议（contract61D）。

图13. 不关注约束的实例
图13 的大图
我们已经决定查看非关注的约束实例，这样我们可以检测到选择的约束是否够强。

如果没有太多创建的约束，那么这一点就很明显。

回页首可能的未来发展
因为我们必须要使用Rational Software Architect UML 框架，它尚不支持OCL 表达式的评价，所以Ecore 模型的生成就变得特别重要了。

在应用到大型模型时，这个过程可以产生较大的回报。

另一方面，它可以阻止我们进行较短的迭代，例如下面的进程：
Modeling > Model Validation > Model Modification > Model Validation > …
从这一方面，我们可以将进程开始的自动化当做可能的未来发展方向：
∙M2M 转化UML > Ecore 的自动化
∙从Ecore 模型生成代码的自动化
图14. 非自动化的进程
该自动化给用户带来了更多的简便性，因为他们不用手动地运行RSA 提供的向导，以构建M2M 转化并生成代码。