Alex.W编译

    OMG的OCL（对象约束语言）被视为精确化模型的基础，形式化模型约束的突破口，MDA技术乃至下一代软件开发技术的基石，已经得到了越来越多的关注。本系列教程将由浅入深向读者呈现OCL的全貌。

UML之痛

       建模，特别是软件建模，过去曾经被视为一个生产图纸的过程。绝大多数模型是由许多方框箭头图和一些附随的文本所组成，这样的模型所传达的信息是不够完整的，非正式的和不够精确的，甚至有些时候自相矛盾。模型中的许多缺陷都是由于所使用的图形表达能力有限而造成的。仅仅只有一个图的时候并不能表达一些条件陈述，而它本应该是一个完整的规约的一部分。例如，在图一所示的UML模型中，类Flight和类Person之间的关联表示一次航班的乘客是确定的一组人，这个一对多的关联在Person端是多重关系（0..*），这意味着乘客的数目是无限的。但是实际上，乘客的数目不可能超过执行这个航班的飞机上座位的数目。然而，在图上我们无法表达这个约束。
     
此主题相关图片如下：

图1 一个航班顾客模型

在这个例子中，正确的指定多重性的方法是向图中添加如下的OCL约束：

 

context Flight

inv: passengers->size() <= plane.numberOfSeats

 

使用OCL这样基于数学的、精确的语言写的表达式为图形表达的系统（业务的或者软件的）模型提供了许多额外的利处，例如，这种表达是不会被不同的角色（比如分析员和程序员）理解为不同的意思，它们是明确的，并且使得模型更为精确和详细。这些表达式也可以被自动化工具所检查，以保证它们是正确的，并且与模型中的其它元素一致，代码生成变得更加有效。
      然而，单纯使用表达式这种表达方式描述的模型常常是难于理解的。例如，尽管源代码可以被认为是软件最终的模型，但是大多数人在第一次和系统打交道的时候更希望看到一个图形化的模型，线框箭头图的好处其含义可以很容易理解。
      对于软件开发者来说，结合使用UML和OCL使得两方面相得益彰。大量的不同的图形和OCL表达式可以被结合起来表示模型。注意对于一个完整的模型，图和OCL表达式都是不可缺少的。没有OCL表达式，模型可能会不够完善；没有UML图，OCL表达式可能引用不存在的元素模型——因为OCL中没有一种机制来表示类和关联。我们只有结合图和约束，才能完整地表达一个模型。

 

OCL带来的额外价值

 

    你依然怀疑OCL为UML带来的好处么？图2显示了另外一个例子，它包含三个类：Person、House和Mortgage，以及它们之间的关联。任何人看到这个模型都会毫无疑问地设想肯定要有许多规则被应用到这个模型中，比如：

• 一个人能抵押的只能是他（她）自己的房子，而不可能是他邻居或者朋友的。

• 抵押的开始日期必须在结束日期之前。

• 每个人的社会安全号码必须是不同的。

• 只有在一个人的收入充足的情况下才允许新的抵押。

• 只有在房子的估价足够的情况下才允许将它作为新的抵押。

这个图并没有显示这些信息，也没有什么方法可以显示这些信息。如果这些规则没有被文档化，不同的人可能会有不同的假设，这样将会导致不正确的理解和系统实现。即使只是像上面一样把这些规则用自然语言描述出来也是不够的，在精确性方面，自然语言是相当模糊的，很容易被解释成不同的意思，误解和错误的系统实现的问题依然存在。
    只有通过OCL表达式来扩展这个系统，这些“抵押系统”的特有规则才能够完整地精确地描述出来。OCL是清晰的，因此这些规则不可能被误解。这些规则可以使用OCL描述如下：

 

context Mortgage

inv: security.owner = borrower

context Mortgage

inv: startDate < endDate

context Person

inv: Person::allInstances()->isUnique(socSecNr)

context Person::getMortgage(sum : Money, security : House)

pre: self.mortgages.monthlyPayment->sum() <= self.salary * 0.30

context Person::getMortgage(sum : Money, security : House)

pre: security.value >= security.mortgages.principal->sum()

 

本质上，在模型中包含这些以OCL表达式表示的规则有许多原因。就像前面所指出的，当人们阅读这个模型的时候不会引起误解，错误也因此可以在开发过程的前期就被发现，这时候修复一个错误的代价是相对低廉的，而且，实现系统的程序员也可以很清楚地理解建立这个模型的分析员的本意
      当模型不是被人来阅读而是作为自动化系统地输入地时候，OCL的使用变得更加重要了。我们可以使用工具来生成模拟和测试、来做一致性检查、来使用MDA变换产生其它语言的继承模型，来生成代码等等。如果可能的话，大多数人很乐意把这种类型的工作留给计算机。

此主题相关图片如下：

图2 一个抵押关系模型

 

然而，只有模型本身包含了所有需要的信息，自动化这种工作才有可能。一个计算机化的工具不可能理解自然语言描述的规则。OCL写成的规则包含了自动化的MDA工具所需要的必要信息。通过这种方法，系统实现比起手工来做要快速和高效得多，而且可以保证UML/OCL模型与生成的工作产品之间的一致性。由此，软件开发过程的成熟度级别得到了一个整体的提升。

 

后 记：

这一小节是来自Klasse Objecten的一篇译文，正当笔者在为如何深入浅出地介绍OCL存在的意义的时候，偶然发现前人已经做了如此优秀的工作，借花献佛也未尝不是一件好事。笔者原创的后续文章将深入OCL语法、解析、代码生成的方方面面。欢迎访问我们的MDA专题论坛（forum.mdachina.net）共同探讨。