对象约束语言简称OCL.docx

对象约束语言简称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. 系谱树形模型一个 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 约束。我们所实施的方案就是执行以下的这些步骤：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. 带有生成源代码目录的项目上面描述的两步应该由确认模型的人员手动完成。在完成之后，实例的生成和 OCL 表达式的评价就可以开始了。生成实例本文描述了完整的生成规则。出于简便性的考虑，我们将会使用类图（entryDiagram），它包含了三类：User，Contract 与 Company。在这里的范例之中，我们将会假设库向相关公司雇佣的每一个人提供了信息。在这里的范例之中，雇员与库之间没有协议，但是与他所服务的公司有，所以，我们要添加以下的限制条件（同样见于图 10）：self.contract-notEmpty()xor pany null图 10. 输入表评价结果的 OCL 约束以及可视化与约束相关的实例拥有_OK的后缀，而其他的实例拥有_KO后缀：图 11. 生成的对象图让我们进一步查看一下两个实例。在图 12 之中，我们可以看到实例关注 User 类的限制性因素。确实，识别为 userT6D 的用户拥有 contractQYR 协议，而且他不是相关公司的雇员（与 Company 类型的实例没有联系）。图 12. 关注约束的实例图 12 的大图相反，我们可以看到图 13 之中的实例并不关注约束，因为其中一个用户是公司（companyJ5U）的雇员，而且拥有库的订阅协议（contract61D）。图 13. 不关注约束的实例图 13 的大图我们已经决定查看非关注的约束实例，这样我们可以检测到选择的约束是否够强。如果没有太多创建的约束，那么这一点就很明显。回页首可能的未来发展因为我们必须要使用 Rational Software Architect UML 框架，它尚不支持 OCL 表达式的评价，所以 Ecore 模型的生成就变得特别重要了。在应用到大型模型时，这个过程可以产生较大的回报。另一方面，它可以阻止我们进行较短的迭代，例