OCL和MDA
 

2008-12-25 来源:blogjava.net

 

闲聊:

我的BLOG又是一周没有更新了,倒不是因为懒,而是上周的大部分时间花在审阅两篇稿件上了。而尚未发表的稿件不能公开讨论,所以BLOG上面就空空如也了。这几天集中精力读《Object Constraint Language, The: Getting Your Models Ready for MDA, Second Edition》这本书,颇有心得。作者Jos Warmer是OCL的创始人,他对于这门语言的把握是最专业的,而且行文流畅,读原著如同读汉语一样,不由得大发感慨,“好书即是好老师”。全书一共十章,分为两大部分,第一部分User Manual包括前五章,主要讲述OCL的由来、概念、简单的使用和实现方法,以及与MDA的关系等;第二部分Reference Manual内容要深一些,讲述了OCL的一些高级使用方法。

这几天奋起疾“书”,以一天一章的速度看完了前五章,脑中彷佛有豁然开朗之感,尤其对于OCL和MDA的关系有了新的认识。

OCL和MDA的初感想

要谈OCL和MDA之间的关系,先要搞清楚它们各自的定义。OCL的定义上次已经说过了,再贴过来看看:UML图(例如类图)通常不够精细,无法提供与规范有关的所有相关部分。这其中就缺少描述模型中关于对象的附加约束。这些约束常常用自然语言描述。而实践表明,这样做经常造成歧义。为了写出无歧义的约束,已经开发出几种所谓的“形式语言”。传统上的形式语言,缺点是仅适合于有相当数学背景的人员,普通商务或系统建模者则难以使用。OCL即为填补这一空白而来。它是一种保留了易读易写特点的形式语言。它已在IBM的保险分部作为一种业务建模语言开发出来,根植于 Syntropy 方法。

而MDA的定义如下:MDA是OMG提出的一种新的软件开发方法,它定义了基于模型的开发过程,以及自动将模型映射到实现的方法。它提供了一种使用模型来指导系统的理解,设计,构造,开发,操作,维护和修改的方法。

直观的来说,MDA是OMG定义的一种软件开发方法,为了标准化这种开发方法,OMG定义一组规范来支持MDA,其中最重要的有:MOF,UML,XMI,CWM。目前MOF,UML和XMI的最新版本都是2.0(CWM不知道,本身就不熟悉它)。在UML2.0的规范中,用了一个单独的部分来专门定义OCL(OCL在UML的较早版本中已经定义,不过没有作为单独的部分来定义)。这说明,OCL和MDA的关系是:OCL是MDA众多标准中的UML标准中的一个子标准。

但是OCL在MDA中的重要性如何呢?

模型成熟度(Modeling Maturity Levels,MML)

在书中我首次见到了MML的概念,当然不一定是本书作者提出的,只不过是我以前孤陋寡闻罢了。MML指出了模型在你的软件开发过程中扮演了一个什么样的角色?并且指出了为了提高软件开发效率你应该采取什么样的措施。

下图画出了MML的六层示范图:

第零层:没有标准:模型存在于开发者的头脑中;

第一层:文本表达:用自然语言写下想法;

第二层:文本和图:用自然语言以及一些图来表达想法;

第三层:模型和图:用建模语言描述的图来表达模型,用自然语言加以辅助描述;

第四层:精确的模型:用一致而连贯的文本/图来精确的描述模型,它们都是没有歧义的,可以直接映射到编程语言;

第五层:只有模型:第五层的模型是对于系统的一个完备的、一致的、详细和精确的描述。它足以进行全部的代码生成工作,生成的代码不需要任何改动即可运行。总而言之一句话:“模型可运行”!

通过以上MML的描述我们可以了解,如果使用UML来描述模型,但是不使用OCL来描述模型中的约束,那么只能达到第三层。如果使用UML+OCL,那么模型就是精确的,MML可以达到第四层。如果模型可以达到MML5,那么是我睡着了。。。当然我们坚信MML5总有一天会达到,那时我们就可以像使用高级语言一样使用建模语言,而像不理今天的汇编一样不理明天的高级语言。也许有一种叫做MVM(Model Virtual Machine)的东西就像今天的JVM一样流行。

OCL用在了MDA的哪些方面?

从上一节可知,OCL是MDA的必要条件,但远远不是充分条件。但不可否认的是,OCL被广泛用于MDA的各个方面。下面的两张图可以说明一部分问题:

第一张图是MDA的一个典型的开发流程,建立PIM,描述转换定义,利用转换工具将PIM转换为PSM。第二张图是OCL在MDA典型开发流程中的使用。其中三个方面使用了OCL:第一是model的创建使用了OCL来描述模型中的约束;第二是模型转换的定义可以使用OCL来描述;第三是建模语言可以使用OCL来创建。

其中让人迷惑的是第一和第三有什么区别呢?用OCL来约束模型和用OCL来创建建模语言有什么区别?区别在于它们所属元层次的不同,也就是MOF中所描述的模型层次不同。这不是绕口令!其实我刚刚接触MDA的时候也认为模型、元模型、元元模型好像绕口令一样,但这些概念在接触中慢慢清晰起来。用OCL来约束模型是处于M1层,其模型是指对系统的描述,例如对一个信用卡管理系统的UML模型。而用OCL来建立建模语言是处于M2层,这时OCL是用来描述UML的元模型中存在的约束,因为元模型等于模型的语言,也就是用OCL来创建建模语言(可能叫用OCL来定义建模语言中的约束更好)。下面是一个UML元模型中使用OCL的例子:

context Interface

inv: features->select(f |f.oclIsKindOf( Attribute ) )->isEmpty()

这个OCL表达式说明,接口Interface中不能有属性存在。如果UML的元模型中缺少OCL的描述,那么此元模型就不是一个“精确”的元模型,那么UML也就不是一个精确的建模语言了。那么MDA就离我们而去了!

OCL,约束自己,约束父亲

由上可知,虽然OCL号称“对象”约束语言,其实它可以对MOF的模型层次中的任一层次进行约束,从而表达出精确的模型(四层模型中任一层的模型)。

OCL可以约束M2层的模型,例如UML的元模型,而OCL的元模型也处于M2层,那么OCL是否可以约束自己的元模型呢?答案是肯定的。

上图是OCL的元模型简化图,其中也用OCL对一些地方进行了描述:

context LoopExpression

inv: source.oclIsKindOf( Collection )

inv: iteratorVariable.type= source.oclAsType(Collection).elementType

上面的约束表达了LoopExpression中source的类型必须是Collection,而迭代子iterator的类型必须是source这个Collection中的元素的类型。由此可见,OCL的元模型也需要OCL来约束,否则这个元模型就是不“精确”的,可以说,OCL在某种程度上自定义了自己。

从M0(对象),M1(模型)到M2(元模型)都可以用OCL来描述,那么M3层呢?定义UML和OCL元模型的元模型MOF,是否需要用OCL来约束。答案是肯定的! 随便举一个例子:

[1] The multiplicity of Association::memberEnd is limited to 2 rather than 2..* (i.e. n-ary Associations are not supported).

context Association inv: memberEnd->size() = 2

[2] The type of Operation::raisedException is limited to be Class rather than Type.

context Operation inv: raisedException.oclIsType(Class)

约束1说明Association的memberEnd的数量必须是2,也就是说Association只能有两个memberEnd;约束2说明Operation抛出的异常类型必须是Class。以上摘自MOF2.0规范。这说明MOF作为OCL的定义者,父亲,同时也被OCL这个儿子约束着。

后记

OCL是MDA中不可缺少的一环,MDA即使离开了UML还有可能使用其他的建模语言来执行,但是离开了约束各层模型的OCL恐怕就处处漏风了。OCL以后很可能会作为一个单独的规范从UML中分离出来。因为它不仅仅是一个“对象”约束语言,更是一个MDA约束语言,渗透在MDA的各个方面。文中还提到了OCL可以定义模型转换,但是由于模型转换的规范QVT还没有最后确定,所以这个部分只是试探,而不是唯一标准。而目前的OCL如果要定义转换,还必须做一些扩充,所以这里没有介绍。

OCL和MDA,目前我的理解也仅限于此,希望看完整本书后,能够有进一步的理解。


火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。
资源网站: UML软件工程组织