程序员眼中的UML

Java 相关 专栏收录该内容
105 篇文章 0 订阅
程序员眼中的UML
 

2010-06-11 作者:wxb_nudt 来源:wxb_nudt的blog

 

UML自1997年诞生以来,受到无数厂商、组织、专家学者的追捧和拥护,短短几年时间,便有一统天下之势。提起建模语言,舍UML其谁?

UML相关标准

OMG组织作为影响力最大的面向对象技术的机构,早早便将UML收入囊中,力捧其为标准建模语言。OMG在CORBA取得成功之后,最大的着力点便是MDA架构,而MDA架构的四大标准UML、MOF、XMI和CWM中,围绕着UML的技术便有三种:UML本身自不必说,版本已经到了2.0;MOF作为“建模语言的语言”,似乎就是为UML量身定做的,虽说MOF有能力创建出与UML并驾齐驱的建模语言,但是似乎没有看到谁这么干,大家只是在努力的发展UML的“方言”,例如UML Profile for CORBA,UML Profile for EJB等等;XMI是“模型的标准存储交换格式”,为了解决不同的建模工具创建的模型不能互用的问题,OMG创建了XMI作为模型的存储交换标准。这样一来,UML工具更加可以大行其道,使用不同的建模工具创建的UML模型可以互相交流,只要它们都基于XMI。

UML相关工具

工具的多寡与优劣可以看出某个技术的受欢迎程度,在建模工具中,不说100%,大概也有90%支持了UML语言。最出名的UML工具Rational Rose,被IBM收购了;Eclipse下面的UML工具EclipseUML让开发它的小公司Omondo也出名了;国内也有一个UML工具,听说效果也不错,就是楚凡科技的Trufun Plato 2005。至于其他国际上有点名气的UML工具,更是不胜枚举,几乎有点软件实力的国家,都有自己的UML工具。

当然,UML不仅仅出现在专用的UML工具中,它也频繁出现在最新的各种开发环境中。例如编程开发环境JBuilder,具有将代码转换为UML类图的功能;Together就更进一步,直接实现了代码和类图的同步转换;Eclipse作为最优秀的开放式开发平台,拥有众多的UML相关插件,除了前面提到的EclipseUML,比较有名的还有EMF和UML2。

UML在MDA出现之后,在OMG的概念中,成为了MDA的一个子集(虽然UML的名气远远大于MDA)。因此众多的MDA工具中,几乎都少不了UML功能。我认为很多MDA工具就是从UML工具直接改过来的。

UML使用现状

照理说来,如火如荼的标准和工具应该催生出如火如荼的应用才对,可是UML的使用状况实在不尽如人意。无论是身边的还是网络上的朋友,在项目中使用UML的都是凤毛麟角,即便使用了UML,也是在很小的范围内,完全没有发挥出1%的功效。现在总结一下目前我所知道的UML使用现状:

  • 读代码时,用UML工具进行逆向工程,可以清晰的观察代码结构,方便理解代码。
  • 写代码时,由于开发平台可以自动生成UML类图,因此有时观察UML类图得到比较清晰的代码结构。例如Together或者JBuilder等工具。当然,如果没有自动生成的UML图,大部分人也不会寻找其他工具去生成UML类图的。
  • 撰写科技论文时,使用UML来表达系统架构或者系统流程等。
  • 部分对UML非常熟悉的程序员,在开始写代码时,先画UML类图,然后利用工具生成代码,最后对代码进行扩展。

从上面的使用现状可以看出,很多人把UML当成一种可有可无的技术。即使使用了UML,也只是围绕着UML中的类图,其他的UML图都抛到一边去了。造成这种状况的原因,一方面固然是因为国内的正规大型软件项目比较少,软件工程技术起步很晚;另一方面是由于国内不管是架构师、系统分析员、软件工程师、程序员、测试人员等等实质上都是程序员而已,很多人是赶着鸭子上架成了架构师或者系统分析员的。这种状况下,软件工程的概念难以深入人心,UML更加成了一个国内项目的鸡肋。

看看国外的架构师、UML专家们,往往都是满脸大胡子,在计算机领域中浸淫了3,40年;而中国最古老的程序员,也只有十几年经验,除去在黑暗中摸索的几年,有十年以上开发经验的程序员少之又少。不经历几个大型项目,要使用软件工程技术是不可能的,也是不能起到什么效果的。因此,有人堂而皇之的撰文“UML的三大硬伤”,将UML驳斥得一无是处。高喊口号打倒某东西是很容易的,关键是打倒了UML何以取而代之?

程序员眼中的UML

既然国内90%以上的软件开发人员都是程序员,那么程序员眼中的UML到底应该是什么样子的呢?我很期望有一本好书能够让程序员们快速的掌握自己所需的UML知识,遗憾的是目前还没有看到这样的一本书。无论是“三友”的UML经典教材还是国内的一些“xx天精通UML”都不符合这样的要求。没有一本是“有中国特色的UML教材――一本写给程序员的UML入门书”。

作为一个程序员,我很了解其他同僚的心理,如果拿到一本书,翻了一个小时还没有找到可以run的HelloWorld,90%的人会大叫一声“去nmd”,然后把书扔进废纸堆。不能怪我们急功近利,在这个技术术语满天飞,连底层平台都动荡不安的年代,谁还有时间和兴趣看一些与自己无关的东西呢?

我很能想象一个程序员,好不容易空出时间来看看最近很热的UML技术,当他拿到一本UML入门以后,开始寻找对自己有用的东西。在开始的一个小时,满篇都是需求分析,use case,甚至书的作者还在饶有兴趣的介绍use case有六种译法:用例、用况、用案……对不起,老子一百年都没做过需求分析了,也不想知道这个狗屁的use case到底叫什么。于是开始后悔在china-pub上又白花了这么多银子。

还有些书上信誓旦旦的说“学好UML,走遍天下都不怕”,如果你做需求分析,你可以用UML和客户交流;如果你做系统分析员,你可以用UML设计系统;如果你做程序员,你可以用UML生成程序;如果你做测试员,你可以基于UML设计测试用例。而实际情况是什么呢?国内的客户有几个懂UML?懂UML的人差不多自己都可以把软件写出来了,还需要请你做需求分析么?别说客户了,上次听同学说和北京某大科研所的工程师们交流,无意中说起了UML,在场的竟然只有一个稍微了解,而且坚持认为那是一种画图工具(那位仁兄其实也没错,Visio不就是一个画图工具么)。

虽然状况如此不堪,但是UML确实是一个很优秀的“交流语言”、“代码生成工具”和“系统设计工具”。让我们擦干身上的献血,掩埋战友的尸体,睁大迷蒙的双眼来看清UML对程序员的作用。UML有九种图,作用各自不同,基本上涵盖了软件工程的各个方面,很多人就是不堪于忍受知识不足的困惑与“侮辱”(很多程序员认为一种技术自己看不懂就是对自己的侮辱),从而放弃了整片UML森林。他们怕的不是在UML这棵树上吊死,而是怕在UML森林里面迷路。但是我想说,知识学习的过程就是去芜存精,找出对自己有用的东西,然后掌握之。对于程序员来说,UML的价值就体现在三个方面:

一、UML是最好的交流语言,无论是与其他程序员交流,还是与领域专家、测试员或者用户交流。原因只有一点,UML是标准的,就像英语一样,无论多么该死,大家还是忙着把自己的论文改成英文的。当然,在小的领域可能有更好的交流方言,但是在大而长远的交流中,使用标准的交流语言是稳妥的。

二、UML是很好的代码生成工具,其实代码生成功能并不是由UML语言和规范提供的,而是由UML工具提供的,而且不同的UML工具提供的代码生成功能还不尽相同。例如Rose提供简单的代码框架生成,而Eclipse插件EMF可以生成功能丰富,提供了各种设计模式的代码包。无论如何,如果程序员可以从UML入手来写程序,比直接敲代码要高级那么一点点。从文档、版本控制、维护、测试等各方面来说,画UML类图比直接写代码都要高那么一点点。

三、UML是很好的系统设计工具。对于程序员来说,很少用到“设计”这个词,大部分时候我们都是在“编写”或者“实现”。但是勿庸置疑,程序员的许多工作中还是需要“设计”的。包和组件之间的依赖关系、复杂操作的流程、对象之间的关联和状态、程序的部署等等,都经常是程序员的工作。那么上面的四种情况可以用UML的组件图、序列图、对象图和部署图来设计。虽然,不同的程序员有不同的设计方法或者设计图例,不过,UML是标准的。不要忽视标准的力量,标准的东西意味着在全世界范围内都有可能会被看懂,不标准的东西可能出了你的办公室就没人能够清晰、准确的理解了。

后记

Blog好久没有更新,因为最近一直忙于一些俗物,于是想写点清高的东西。但是写完之后再看,好像也不怎么清高,反而更俗了。

前段时间写论文时,需要用到UML2.0的类图元模型,在UML2.0的规范中寻觅了好久,发现类图元模型已经被拆分到三个包里面了,因为UML2.0的规范实在是太大太繁琐了。于是有感于UML之博大精深,说好听是博大精深,难听点就是乱七八糟。不过OMG历来如此,当初的CORBA如果更简约一点,也许J2EE根本就没有立足之地。

感慨之后就是想把UML中对自己有用的部分整理出来,在整理之前免不了到处翻资料,这篇文档就是翻资料的一些感触了。希望能够将UML的有用部分都整理出来,形成一个系列的文档。

克服用例图的恐惧

在实际工作中,大部分程序员很少接触到需求分析,即使有需求分析,也是草草了事,没有用正规的方式来表达,所以一般程序员使用用例图的机会是不多的。但是却又常常在各种媒体上看见用例图,于是对一种常常出现,自己又不太熟悉的技术,会产生恐惧。如果说对MDA或者CORBA这样的技术产生恐惧还是值得的话,对用例图产生恐惧是非常不值的。因为MDA和CORBA这样的技术也许要花上半年的时间才能够初步了解,而克服用例图恐惧症,则只要不到一天的时间。

用例图初感

UML是一组图示符号的标准。所谓图示符号,就是一组定义好的图示,它们可以表达定义好的各种意思。用UML进行软件建模,就是用规定好的符号画图,这些图表达了开发人员脑中的软件系统。用UML进行软件建模,其难度并不比我们小时候上的美术课更难。在美术课上,一个圆形加上四根线条表示太阳,一个三角形加上一个矩形表示房子;同理,在UML的用例图中,一个椭圆表示用例,一个小人表示参与者。我并不认为它们之间有质的区别,想到我对这种小学生画图课恐惧了几年,不由得感到羞愧。

用例图是UML的九个图中较为重要和常用的一种图。常常用于软件开发的需求分析阶段,也能用于软件的系统测试阶段。简单的来说,用例图是描述系统的外部视图。

在开始设计一个软件系统时(更广义的情况下,可以用来设计任何系统),需要一种手段来发现系统的功能,用例图虽然是图示,但是这些图示隐含了一种启发系统功能的手段。其实所有的UML图都只包含图示和标准,并不包含方法,但是它们往往隐含了某种方法。UML和软件开发方法的关系,很类似于汉字和语文的关系。

用例图包含了三种基本的概念:用例、角色和系统。它们可以组合起来表达系统的外部视图。而且这种表达方式是如此直观和简单。

第一张用例图

画用例图是一件很简单的事情,而且感觉还很舒适,因为用例图简洁、直观。虽然用例图不能像HelloWorld一样运行,也不能生成代码,不过画一张清晰的用例图还是很有成就感的。

我使用的工具是Eclipse+EclipseUML插件,功能不如Rose,但是是开源而且免费的(EclipseUML有free版也有企业版),而且效果也不错。第一张用例图如下:

第一张用例图.jpg

可以看出图中有一个系统(保险商务系统),两个角色(客户和保险销售员)以及三个用例(签订保险单、销售统计资料、客户数据资料),另外还有四个连接线以及一个注释。如果在纸上或者合适的工具中,画这样一张用例大概只需要五分钟吧。不过仅仅画出来是没有意义的,需要弄清楚其背后真正的含义才行。

理解用例图

可以这样简单的理解用例图中的一些概念,系统(System)指的是软件系统,它可以包含一些用例,并界定系统的边界,边界之内的属于系统的功能和行为,边界之外的则不是系统所关心的内容。系统规定了一个具有某些功能的黑盒子,在系统之外看到的仅仅是这个系统的功能,而不能看到系统的内部细节。这一点也是用例图经常被用来做系统测试的原因。当然这些测试一般是黑盒测试。

角色(Actor)是与系统中的用例交互的一些实体,在实际情况中,角色可以是人,也可以是其他系统或者硬件设备。在画用例图的过程中,角色往往是第一个被确定的,因为系统或者用例在开始时是模糊的,但是参与系统的角色是最容易明晰的。有了角色之后,根据角色与系统的交互,以及角色要求的功能,可以进一步确定系统和用例。

用例(Use case)指的是系统的功能,它是系统某个功能的所有执行动作的集合。在UML图示中它是一个椭圆,但是具体分析用例的时候需要给出这个用例的所有执行动作的步骤。例如上图中的“签订保险单”用例,就可以分为几个步骤:第一,客户发出保险单请求;第二,系统给出保险单样式表;第三,用户填写保险单样式表;第四,系统检查用户提交的保险单格式是否规范;第五,如果不规范则返回第二步,如果规范则给保险单销售员发出消息;第六,保险单销售员填写保险单;第七,保险单销售员将填写好的保险单加入数据库,并将客户资料输入客户数据库。当然,以上步骤仅仅是我想象的,我还从来没有见过什么“保险单”,这次过了一把瘾。

连接(Assocation)是角色与用例的连接,表达此角色可以初始化此用例。 

注释(Note)可以添加到任何地方,对用例图的不同部分加以说明。

泛化、包含和扩展

泛化(Generalization)在面向对象的技术中无处不在,它的另一个名字也许更为著名,就是“继承”。下图给出了一个使用泛化的用例图:

继承关系用例图.jpg

由此可知,在用例图中,角色和用例都能够泛化。角色的泛化/继承很容易理解,因为角色本来就是类(Class),它是一种版型(stereotype)为Actor的类,所以角色的继承直观而自然。但是用例的继承实际上分为两种情况,并不是简单的使用泛化,而是使用扩展(extended)和包含(include)两种泛化的特例。

扩展用于子用例的动作步骤基本上和父用例的动作步骤相同,只是增加了另外的一些步骤的情况下。包含用于子用例包含了所有父用例的动作,它将父用例作为了自己的一个大步骤,子用例常常包含一个以上的父用例。如下图:

用例的扩展和包含.jpg

小结

关于用例图基本上也就是上面提到的这些内容了。当然,用例图还常常和类图、活动图联合使用,不过那些知识还是等其他知识完备了以后再说比较好。

我总结的画用例图的步骤如下:

  • 确定系统,拟出系统的名称,这个不难,例如电信计费系统;
  • 找出所有与系统打交道的角色,角色要进行一些精简和整合;
  • 站在角色的立场想象系统应该提供的功能,将这些功能画成系统中的用例;
  • 对于每个用例给出详细的动作步骤;
  • 找出用例图中角色、用例之间可能有的继承、扩展或者是包含关系;

以我现在的理解能力,认为用例图到此为止了。当然,我还可以想象,用例图会用来启发类图的构建,例如用例图中的某些部分(角色或者用例)会变成类图中的类或者接口。另外,可以想象用例图还可能会影响活动图中的流程。

后记

让我恐惧了好久的用例图在今天便土崩瓦解了,心中却彷佛有一点茫然,因为我记得自己无数次的对自己说“好忙啊,这个技术肯定要花很多时间,还是以后再学吧”类似的话。当我用C的时候对C++这样说过,然后是Java、CORBA、JSP、XML、MDA、XMI、UML……

写blog不仅仅是一种爱好,对我来说,更是一种最好的学习方法,当我读小学的时候,班主任常常对我说“好记性不如烂笔头”,我当时的理解是把事情用笔记下来比用脑袋背下来更加持久(脑袋是内存?纸笔是数据库?)。但是,现在我理解到,要学习某个东西,最好的方法是用自己的语言把它表达出来,如果你能让别人理解这个技术,你自己当然已经精通了。在我写blog的过程中,常常会出现写到一半的时候猛然领悟的情况,这是因为当你在选择最佳的表达方式的时候,将你自己头脑中一团乱麻的线索都理清了的结果。

有朋友留言说,自己计算机本科毕业,在计算机领域学习了八年,竟然看不懂我的blog。这个我认为很正常,读本科的时候,所有同学都可以在一起讨论问题、实习;等到上研的时候,同学对我说他的课题,我只能模糊的听个大概,因为专业方向已经分开了;现在读博了,同学要拉着我说他的课题,我只能明白是哪个领域里面的问题,往往对这个问题的描述都听不懂了。这是因为研究方向已经非常精细的原因。我自问我的方向已经很大众化了,如果研究图像压缩算法的话,那满篇都是数学公式了;如果研究微电子技术,那么满篇都是集成电路图了。

还有一点,如果我感兴趣的技术在网上已经能够找到很好的资源,那么我不会动笔去写blog了,我会把资料下载到硬盘就好了。例如XML技术,我的blog中只有两篇,第一篇是“XML的本质讨论”,总结出了别人看不到的XML本质,提出了一些新观点;第二篇是“XSL:转换从哪里开始”。其实XML技术浅显易懂,我也有很多感想和心得,不过其中只有XSL在网上不能找到很好的总结资料,因此我写了那一篇。这也是我坚持原创和创新的一点反映吧。对于那种狂贴别人资料的blog,我是不以为然的。我只喜欢原创或者第一手翻译资料的blog。

类图,就是比你高一点

UML的成功80%是因为类图,提到UML的时候有90%的人想到了类图,应用UML的时候100%应用了类图。如果类图和源代码走到一起,肯定是要代码抗钉耙的,因为论武功和智慧,类图都高了那么一点点。

乱谈类图

如果说程序是一个人,那么类图就是这个人的躯体。也就是说,光有类图,一个程序已经成型了,看上去很像那么一回事了。UML在刻画程序的静态结构方面很成功,但是在刻画程序的动态语义时很失败,至今没有一个好的解决方案,或者说,没有一个能让各方面都接受的方案。如果UML动态语义的问题解决了,那么MDA的目标就真的达到了,模型可以完全代替代码了。

目前的MDA工具,号称模型代码同步的,号称代码生成的,号称PIM/PSM转换的,大部分都只是和类图打交道罢了。因为类图和代码之间的转换是如此自然,以至于出现了Together这样的工具,模型(类图而已)和代码是同步的。

类图是程序的躯体,动作语义才是程序的灵魂,可惜UML在刻画程序灵魂的事情上做得太不出色了。很多研究者仅仅把目光放在类图上,类图到代码的生成几乎已经没有什么可以研究了,还是抱住不放,在生成的代码中加入约束、加入设计模式、加入持久化存储等等。怒其不争、哀其无志。想到自己也是其中的一员,不由临表涕零。

类图难点问题总结

类图是非常容易学习的,因为它和面向对象编程是孪生兄弟,如今的程序员哪有不懂面向对象的,因此类图对于他们,就如同奶瓶对于婴儿一般。下面从硬盘中翻出一幅曾经自己画的类图,相信大家一看便知:

类图是一门易学难精的技术,正如面向对象技术一样,一百个程序员九十九个都说自己懂面向对象,但是真正入门的可能不到十个,真正精通的也许只有一个,这个人还往往不是中国人,唉~

自己重新学习UML的动机就来自于一次论文撰写过程中,想查阅类图的元模型图,但是问遍同行,翻遍网络,找不到合适的图形或者描述,最后只能求救于OMG的UML规范。一查之下,大惊失色,原来很多东西原来都是懵懵懂懂,不甚了了。因此痛下决心,要弄懂类图中的疑点。

翻看类图,我发现有如下是疑点所在:

  • Attribute和Property的关系如何?区别和共同点是什么?
  • 完整的描述一个操作(Operation),需要多少东西?
  • 类之间可以有关系(Relationship),关系可以是关联(Association)或者泛化(Generalization),这个你知道么?
  • 关联有七种:普通关联、递归关联、限定关联、或关联、有序关联、三元关联、聚合(聚合和组合),各自有什么含义?用法如何?
  • 关联类(Association Class)的含义如何?应用场景如何?
  • 类的实例化是对象,关联的实例化是什么呢?

总结出了这些疑点要归功于中文UML书籍的模糊和混乱,或者是翻译者的语焉不详。所以让我在复习时找出了这么多的疑点。

要查阅资料,解决疑难,并举例说明,起码需要3,4天的时间,因此这篇随笔就作为类图的引文先发了。也希望志同道合者和我一起研究上面的问题。

后记

周末了,想偷懒了,结果适得其反,刚刚完成这篇blog就停电了,后面的几百字全没了。这一点告诉我们,持久化存储是多么重要啊~

类图释疑之一,Attribute和Property之区别

上一篇中提出了很多问题,其中最令人费解的可能就是Attribute和Property之区别了吧。我在网络上寻找良久也没有发现好的解释,反而发现了很多混乱的解释和用法。因此,依靠OMG网站上的UML规范以及自己的理解,整理出了这篇文章。

UML中的Attribute和Property之区别

在很多人的脑海中,Attribute就是类的属性,Property呢?好像也是类的属性?因此有很多人不加区别的统一称为类的属性,尤其是在写中文文章的时候。这种心理是典型的鸵鸟心态,眼不见为净。其实稍微用脚想一下就知道,事实肯定不是这样的,UML中既然发明了这两个术语,显然不是用来冗余的。它们之间肯定有着千丝万缕的联系与区别。

各种各样的面向对象语言、各种组件技术、模板技术、Web Service技术,其中大部分涉及到了“属性”这个概念,而其英文术语则常常是Attribute、Property或者Field。很多人一概称之为“属性”,有的地方确实可以不加区分,但有的地方却是差之毫厘、谬以千里。我对于这些纷纷扰扰的技术和术语也很苦恼,但是我们至少可以通过UML中的这两个术语的解释找到一个可以参考的标准。无论如何,UML是面向对象技术的集大成者和事实上的标准。

UML1.4中的Attribute和Property

造成Attribute和Property理解混乱的罪魁祸首有一半是OMG自己,因为在UML1.4以前的规范中,Property并没有当作一个标准的术语出场,而是叫做Element Properties。其定义如下[1]:

Many kinds of elements have detailed properties that do not have a visual notation. In addition, users can define new element properties using the tagged value mechanism. A string may be used to display properties attached to a model element. This includes properties represented by attributes in the metamodel as well as both predefined and user-defined tagged values.

许多模型元素含有详细的特性(properties),它们并没有可视化的符号。另外,用户可以使用标记值(tagged value)机制定义新的模型元素特性。一个字符串可以被用来显示附着在模型元素上面的特性。它包括在元模型中用来表示特性(properties)的属性(attribute)以及预定义和用户自定义的标记值。

从上面的定义可以看出,OMG的本意是将Property作为表示模型元素特性的统一术语。模型元素是UML所有建模元素的顶层父类和原子成分,Class也是一种模型元素。因此Property是用来修饰一部分模型元素的,而不仅仅是用来修饰Class的。另外一层含义是,Property包含了Attribure和tagged value,它的概念范围应该比Attribute要大。

再来看看Attribute在UML1.4规范中的定义[2]:

An attribute is a named slot within a classifier that describes a range of values that instances of the classifier may hold. In the metamodel, an Attribute is a named piece of the declared state of a Classifier, particularly the range of values that Instances of the Classifier may hold.

一个属性(attribute)是类元(classifier)中的一个命名的槽(named slot),它用来描述此类元的实例可能拥有的取值范围。在元模型中,一个属性是一个类元的可命名的声明状态,尤其表示了这个类元的实例可能拥有的取值范围。

由此可知,Attribute是与Classifier相关联的术语,它比Property的影响范围要小。Class是Classifier的子类,因此Attribute也可以表示Class的属性。从上面的定义还可以看出,Attribute可以是Classifier的实例的命名的槽。对于Class来说,其实例就是Object,Object的槽就是对象的属性值槽。因此,Attribute是可以作为对象的属性的。而Property似乎没有这一层的含义。按MOF(元对象设施,OMG的另一个规范,后面会有详细解释)的模型层次划分,Attribute涉及的模型层从M2到M0,而Property似乎只是M2层的概念。

很客观的说,UML1.4中对于这两个术语并没有很清晰的定义,但是其区别还是显而易见的。Attribute应该是UML1.4中的宠儿,而Property连一个单独的术语都没有捞到。谁也没想到在UML2.0中风云突变,Attribute从类图中消失了,而Property堂而皇之入主中原。

UML2.0抛弃Attribute了么?

当我看到UML2.0的类图元模型的那一刹那,第一个感觉就是“Attribute哪儿去了?”下面是UML2.0中的Core::Basic包中的类图元模型[3]:

从图中可以清晰的看到,Class仅仅聚合了两个元素:Property和Operation。而Attribute却从类图元模型中消失了。

先看看此元模型中Property的定义[4]:

A property is a typed element that represents an attribute of a class.

一个特性(property)是一个有类型的元素(typed element),它代表了一个类中的一个属性(Attribute)。

哇,这个定义是不是在搞笑?各位别急,别忘记了UML2.0中的类图元模型可不止一个,它的类图元模型是由三个分散的部分组成的。除了上面提到的Core::Basic::Class Diagram之外,还有Core::Constructs::Class Diagram和Class Diagram from Kernel Package。下面再来看看Core::Constructs::Class Diagram[5]:

可以看出这个图与上面的不同之处是加入了Classifier和Association,Class、Property和Operation三巨头还在。这个图对于Property的定义几乎可以解开我心中的疑惑了:

A property is a structural feature of a classifier that characterizes instances of the classifier. Constructs::Property merges the definition of Basic::Property with Constructs::StructuralFeature.

When a property is owned by a class it represents an attribute. In this case it relates an instance of the class to a value or set of values of the type of the attribute.

When a property is owned by an association it represents a non-navigable end of the association. In this case the type of the property is the type of the end of the association.

Property represents a declared state of one or more instances in terms of a named relationship to a value or values. When a property is an attribute of a classifier, the value or values are related to the instance of the classifier by being held in slots of the instance. When a property is an association end, the value or values are related to the instance or instances at the other end(s) of the association (see semantics of Association).

一个property是一个类元(classifier)的结构化特征,它用来刻画这个类元的实例。Constructs包中的Property(Constructs::Property)结合了Basic::Property和Constructs::StructuralFeature的定义。

当一个property被一个class拥有时它代表一个attribute。在这种情况下,它将一个class的实例联系到一个具体值或者一组值,这些值的类型符合attribute的类型。

当一个property被一个连接(association)拥有时它代表一个非导向的连接端。在这种情况下这个property的类型就是这个association的连接端的类型。

Property表达了一个或者一些实例的声明状态,它使用了一个命名的关系将实例连接到一个值或者一组值。当一个property是一个classifier中的attribute的时候,它通过将值储存在这个classifier的实例的槽(slot)中来给一个实例赋值。当一个property是一个关联端(association end)的时候,它的值被关联到association另一个关联端的实例。

从上面的定义中可以看出,Property同时代表了Attribute和Association end,如果它的owningAssociation不为空,则表明它属于一个Association,这时它代表了一个关联端;如果它的owningAssociation为空,则表明它不属于一个Association,这时它代表了类的一个Attribute。同时,Property继承了UML1.4中的定义,它可以用来表示标记值(Tagged Value)。

那么Attribute呢?UML2.0彻底抛弃它了么?不是的,它的定义依然存在[6]:

A structural feature of a classifier that characterizes instances of the classifier. An attribute relates an instance of a classifier to a value or values through a named relationship.

一个类元的结构特征,它能够刻画这个类元的实例。一个Attribute通过一个命名的关系将一个类元的实例联系到一个或者一组具体值。

比起UML1.4中的定义,这个定义要简洁多了,Attribute这里仅仅指一个类元的结构特征,可以将类元的实例联系到一个或者一组具体值。而没有提到实例的槽(slot)等等。我猜想,这是因为UML2.0中已经把Attribute作为Property的一个子集了,所以关于实例的槽(slot)等等的具体赋值方法,都归结到Property的定义中解释了。

另外一点值得注意的是,Attribute的定义来自于术语表,而没有在元模型图中出现。而Property出现在元模型图中,并且都做了详细而具体的解释。这一点可以看出,UML强化Property,弱化Attribute的决心。

Attribute和Property的总结

这一节对Attribute和Property作一个小结,基于目前最新的UML2.0规范:

  • 总体上来说,Attribute是Property的子集,Property会在适当的时机表现为Attribute;
  • Property出现在类图的元模型中,代表了Class的所有结构化特征;Attribute没有出现在元模型中,它仅仅在Class的概念中存在,没有相应的语法了;
  • Property有详细的定义和约束,而Attribute没有详细的定义,因此也不能用OCL写出其约束。
  • Property和Attribute都是M2层的概念。在M1层,它们的实例是具体类的属性;在M0层,它们的实例的实例是具体对象的槽中存储的值。

上面多次提到了MOF的四层模型,这应该是属于MDA范畴中的概念,下面这一小节给出一个例子,希望能够说明Attribute和Property及其实例在不同的模型层中扮演的角色。

元模型图、模型图、对象图

MOF的四层模型分别是:元元模型层(M3)、元模型层(M2)、模型层(M1)、运行时(M0)。其中元元模型层包含了定义建模语言所需的元素;元模型层定义了一种建模语言的结构和语法;模型层定义了一个具体的系统的模型;运行时包含了一个模型的对象在运行时的状态等。

本文涉及到的有M2、M1和M0层,下面给出一个例子,首先是M2层,它可以定义一个建模语言的结构和语法,例如:

这是一个简要的元模型图,它表示Class由Property和Operation组成,这张图符合UML2.0的概念,但是我们也可以这样画:

这样一来,Class包含三种元素:Attribute、AssociationEnd和Operation,这样我们就创建了一个新的元模型,也可以说创建了一个小的新建模语言。虽然它不符合UML2.0规范。

M1层模型就是我们通常简称的“模型”,它是系统的标准化表示,一般用建模语言来表示一个软件系统,例如下面的汽车和人的系统:

其中Car类表示汽车的模型,它有两个属性price和type,另外还有一个关联端owner(表示车主),这些都是Property的实例。Person类也有两个属性age和name,还有一个关联端car。可以看出,M1层模型中的元素都是M2层模型元素的实例,例如:

Car和Person是Class的实例;price、type、age、name以及car、owner都是Property的实例;run()和drive()都是Operation的实例。

所谓“建模”实际上就是利用M2层定义的元模型作为建模语言来定义M1层的模型。

再来看看M0层,汽车和人系统的运行时对象图如下:

因为不态熟悉对象图,所以其中可能有疏漏,不过其意义是一目了然的。其中具体的对象属性就是Property的实例的实例了。例如type=medium,medium是M1层模型中type的实例值,type是M2层中Property的实例值。

后记

总算将这一篇写完了,在群里面和阿飞仔细讨论了好久,真的是非常辛苦,但是我觉得弄清楚了Attribute和Property的区别是非常有意义的。它们所涉及的范围很广,可谓知十而闻一。这篇似乎不能够叫“程序员眼中的UML了”,因为涉及了好多MDA的知识,而且离代码很远。不过我尽量写得清楚通俗一点,文中出现的术语都作了解释,希望能够让大家看懂。

文中的术语翻译来自于《UML参考手册》[7],因为UML很多术语的翻译不统一,因此我用了这本很著名的UML书的译法。同时注明了英文原文。

参考文献

1. UML1.4-01-09-67文档 289页

2. UML1.4-01-09-67文档 80页

3. UML 2.0 Infrastructure Final Adopted Specifcation03-09-15文档109页

4. UML 2.0 Infrastructure Final Adopted Specifcation03-09-15文档111页

5. UML 2.0 Infrastructure Final Adopted Specifcation03-09-15文档123页

6. UML 2.0 Infrastructure Final Adopted Specifcation03-09-15文档17页

7. UML参考手册

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值