??xml version="1.0" encoding="utf-8" standalone="yes"?>
如果说程序是一个hQ那么类囑ְ是这个h的躯体。也是_(d)光有cdQ一个程序已l成型了Q看上去很像那么一回事了?/SPAN>UML在刻ȝ序的静态结构方面很成功Q但是在ȝE序的动态语义时很失败,至今没有一个好的解x案,或者说Q没有一个能让各斚w都接受的Ҏ(gu)。如?/SPAN>UML动态语义的问题解决了,那么MDA的目标就真的辑ֈ了,模型可以完全代替代码了?/SPAN>
目前?/SPAN>MDA工具Q号U模型代码同步的Q号UC码生成的Q号U?/SPAN>PIM/PSM转换的,大部分都只是和类图打交道|了。因为类囑֒代码之间的{换是如此自然Q以至于出现?/SPAN>Togetherq样的工P模型Q类图而已Q和代码是同步的?/SPAN>
cd是程序的w体Q动作语义才是程序的灵魂Q可?/SPAN>UML在刻ȝ序灵的事情上做得太不出色了。很多研I者仅仅把目光攑֜cd上,cdC码的生成几乎已经没有什么可以研I了Q还是抱住不放,在生成的代码中加入约束、加入设计模式、加入持久化存储{等。怒其不争、哀其无志。想到自׃是其中的一员,不由临表涕零?/SPAN>
cd隄问题ȝcd是非常容易学?fn)的Q因为它和面向对象编E是孪生兄弟Q如今的E序员哪有不懂面向对象的Q因此类囑֯于他们,如同奶瓶对于婴儿一般。下面从盘中翻Zq曾l自q的类图,怿大家一看便知:(x)
cd是一门易学难_技术,正如面向对象技术一P一百个E序员九(ji)十九(ji)个都说自己懂面向对象Q但是真正入门的可能不到十个Q真正精通的也许只有一个,q个往往不是中国人,唉~
自己重新学习(fn)UML的动机就来自于一ơ论文撰写过E中Q想查阅cd的元模型图,但是问遍同行Q翻遍网l,找不到合适的囑Ş或者描qͼ最后只能求救于OMG?/SPAN>UML规范。一查之下,大惊pQ原来很多东西原来都是懵應|懂,不甚了了。因此痛下决心,要弄懂类图中的疑炏V?/SPAN>
ȝcdQ我发现有如下是疑点所在:(x)
l Attribute?/SPAN>Property的关pd何?区别和共同点是什么?
l 完整的描qC个操作(OperationQ,需要多东西?
l cM间可以有关系Q?/SPAN>RelationshipQ,关系可以是关联(AssociationQ或者泛化(GeneralizationQ,q个你知道么Q?/SPAN>
l 兌有七U:(x)普通关联、递归兌、限定关联、或兌、有序关联、三元关联、聚合(聚合和组合)Q各自有什么含义?用法如何Q?/SPAN>
l 兌c(Association ClassQ的含义如何Q应用场景如何?
l cȝ实例化是对象Q关联的实例化是什么呢Q?/SPAN>
ȝZq些疑点要归功于中文UML书籍的模p和混ؕQ或者是译者的语焉不详。所以让我在复习(fn)时找Zq么多的疑点?/SPAN>
要查阅资料,解决疑难Qƈ举例说明Qv码需?/SPAN>3Q?/SPAN>4天的旉Q因此这随W就作ؓ(f)cd的引文先发了。也希望志同道合者和我一L(fng)I上面的问题?/SPAN>
UML是一l图C符L(fng)标准。所谓图C符P是一l定义好的图C,它们可以表达定义好的各种意思。用UMLq行软g建模Q就是用规定好的W号dQ这些图表达了开发h员脑中的软gpȝ。用UMLq行软g建模Q其隑ֺq不比我们小时候上的美术课更难。在术课上Q一个圆形加上四根线条表C太阻I一个三角Ş加上一个矩形表C房子;同理Q在UML的用例图中,一个椭圆表C用例,一个小C参与者。我q不认ؓ(f)它们之间有质的区别,惛_我对q种学生画图课恐惧了几q_(d)不由得感到羞愧?/SPAN>
用例图是UML的九(ji)个图中较为重要和常用的一U图。常常用于Y件开发的需求分析阶D,也能用于软g的系l测试阶Dc简单的来说Q用例图是描q系l的外部视图?/SPAN>
在开始设计一个Y件系l时Q更q义的情况下Q可以用来设计Q何系l)Q需要一U手D|发现pȝ的功能,用例图虽然是囄Q但是这些图C隐含了一U启发系l功能的手段。其实所有的UMLN只包含图C和标准Qƈ不包含方法,但是它们往往隐含了某U方法?/SPAN>UML和Y件开发方法的关系Q很cM于汉字和语文的关pR?/SPAN>
用例囑含了三种基本的概念:(x)用例、角色和pȝ。它们可以组合v来表辄l的外部视图。而且q种表达方式是如此直观和单?/FONT>
W一张用例图ȝ例图是一件很单的事情Q而且感觉q很舒适,因ؓ(f)用例囄z、直观。虽然用例图不能?/SPAN>HelloWorld一栯行,也不能生成代码,不过M张清晰的用例图还是很有成感的?/SPAN>
我用的工具?/SPAN>Eclipse+EclipseUML插gQ功能不?/SPAN>RoseQ但是是开源而且免费的(EclipseUML?/SPAN>free版也有企业版Q,而且效果也不错。第一张用例图如下Q?/SPAN>
可以看出图中有一个系l(保险商务pȝQ,两个角色Q客户和保险销售员Q以?qing)三个用例({订保险单、销售统计资料、客h据资料)Q另外还有四个连接线以及(qing)一个注释。如果在U怸或者合适的工具中,画这样一张用例大概只需要五分钟吧。不q仅仅画出来是没有意义的Q需要弄清楚其背后真正的含义才行?/FONT>
可以q样单的理解用例图中的一些概念,pȝQ?/SPAN>SystemQ指的是软gpȝQ它可以包含一些用例,q界定系l的边界Q边界之内的属于pȝ的功能和行ؓ(f)Q边界之外的则不是系l所兛_的内宏V系l规定了一个具有某些功能的黑盒子,在系l之外看到的仅仅是这个系l的功能Q而不能看到系l的内部l节。这一点也是用例图l常被用来做pȝ试的原因。当然这些测试一般是黑盒试?/SPAN>
角色Q?/SPAN>ActorQ是与系l中的用例交互的一些实体,在实际情况中Q角色可以是人,也可以是其他pȝ或者硬件设备。在ȝ例图的过E中Q角色往往是第一个被定的,因ؓ(f)pȝ或者用例在开始时是模p的Q但是参与系l的角色是最Ҏ(gu)明晰的。有了角色之后,Ҏ(gu)角色与系l的交互Q以?qing)角色要求的功能Q可以进一步确定系l和用例?/SPAN>
用例Q?/SPAN>Use caseQ指的是pȝ的功能,它是pȝ某个功能的所有执行动作的集合。在UML囄中它是一个椭圆,但是具体分析用例的时候需要给个用例的所有执行动作的步骤。例如上图中的“签订保险单”用例,可以分为几个步骤:(x)W一Q客户发Z险单hQ第二,pȝl出保险单样式表Q第三,用户填写保险单样式表Q第四,pȝ查用h交的保险单格式是否规范;W五Q如果不规范则返回第二步Q如果规范则l保险单销售员发出消息Q第六,保险单销售员填写保险单;W七Q保险单销售员填写好的保险单加入数据库,q将客户资料输入客户数据库。当Ӟ以上步骤仅仅是我惌的,我还从来没有见过什么“保险单”,q次q了一把瘾?/SPAN>
q接Q?/SPAN>AssocationQ是角色与用例的q接Q表达此角色可以初始化此用例?/SPAN>
注释Q?/SPAN>NoteQ可以添加到M地方Q对用例囄不同部分加以说明?/SPAN>
泛化、包含和扩展泛化Q?/SPAN>GeneralizationQ在面向对象的技术中无处不在Q它的另一个名字也许更名,是“扎쀝。下囄Z一个用泛化的用例图:(x)
由此可知Q在用例图中Q角色和用例都能够泛化。角色的泛化/l承很容易理解,因ؓ(f)角色本来是c(ClassQ,它是一U版型(stereotypeQؓ(f)Actor的类Q所以角色的l承直观而自然。但是用例的l承实际上分ZU情况,q不是简单的使用泛化Q而是使用扩展Q?/SPAN>extendedQ和包含Q?/SPAN>includeQ两U泛化的特例?/SPAN>
扩展用于子用例的动作步骤基本上和父用例的动作步骤相同Q只是增加了另外的一些步骤的情况下。包含用于子用例包含了所有父用例的动作,它将父用例作Z自己的一个大步骤Q子用例常常包含一个以上的父用例。如下图Q?/FONT>
关于用例囑֟本上也就是上面提到的q些内容了。当Ӟ用例图还常常和类图、活动图联合使用Q不q那些知识还是等其他知识完备了以后再说比较好?/FONT>
我ȝ的画用例囄步骤如下Q?/FONT>
l 定pȝQ拟出系l的名称Q这个不难,例如?sh)信计费pȝQ?/SPAN>
l 扑և所有与pȝ打交道的角色Q角色要q行一些精和整合;
l 站在角色的立场想象系l应该提供的功能Q将q些功能Lpȝ中的用例Q?/SPAN>
l 对于每个用例l出详细的动作步骤;
l 扑և用例图中角色、用例之间可能有的ѝ扩展或者是包含关系Q?/SPAN>
以我现在的理解能力,认ؓ(f)用例囑ֈ此ؓ(f)止了。当Ӟ我还可以惌Q用例图?x)用来启发类囄构徏Q例如用例图中的某些部分Q角色或者用例)?x)变成类图中的类或者接口。另外,可以惌用例图还可能?x)媄响活动图中的程?/FONT>
后记让我恐惧了好久的用例囑֜今天便土崩瓦解了Q心中却彷佛(jng)有一点茫Ӟ因ؓ(f)我记得自己无数次的对自己说“好忙啊Q这个技术肯定要花很多时_(d)q是以后再学吧”类似的话。当我用C的时候对C++q样说过Q然后是Java?/SPAN>CORBA?/SPAN>JSP?/SPAN>XML?/SPAN>MDA?/SPAN>XMI?/SPAN>UML…?/SPAN>
?/SPAN>blog不仅仅是一U爱好,Ҏ(gu)来说Q更是一U最好的学习(fn)Ҏ(gu)Q当我读学的时候,班主d常对我说“好记性不如烂W头”,我当时的理解是把事情用笔C来比用脑袋背下来更加持久Q脑袋是内存Q纸W是数据库?Q。但是,现在我理解到Q要学习(fn)某个东西Q最好的Ҏ(gu)是用自己的语a把它表达出来Q如果你能让别h理解q个技术,你自己当然已l精通了。在我写blog的过E中Q常怼(x)出现写到一半的时候猛焉(zhn)的情况Q这是因为当你在选择最佳的表达方式的时候,你自己头脑中一团ؕȝU烦都理清了的结果?/SPAN>
有朋友留a_(d)自己计算机本U毕业,在计机领域学习(fn)了八q_(d)竟然看不懂我?/SPAN>blog。这个我认ؓ(f)很正常,LU的时候,所有同学都可以在一赯论问题、实?fn);{到上研的时候,同学Ҏ(gu)说他的课题,我只能模p的听个大概Q因Z业方向已l分开了;现在d了,同学要拉着我说他的NQ我只能明白是哪个领域里面的问题Q往往对这个问题的描述都听不懂了。这是因为研I方向已l非常精l的原因。我自问我的方向已经很大众化了,如果研究囑փ压羃法的话Q那满篇都是数学公式了;如果研究微电(sh)子技术,那么满篇都是集成?sh)\图了?/SPAN>
UML?/SPAN>1997q诞生以来,受到无数厂商、组l、专家学者的q捧和拥护,短短几年旉Q便有一l天下之ѝ提起徏模语aQ舍UML其谁Q?/SPAN>
UML相关标准OMGl织作ؓ(f)影响力最大的面向对象技术的机构Q早早便?/SPAN>UML收入囊中Q力捧其为标准徏模语a?/SPAN>OMG?/SPAN>CORBA取得成功之后Q最大的着力点便是MDA架构Q?/SPAN>MDA架构的四大标?/SPAN>UML?/SPAN>MOF?/SPAN>XMI?/SPAN>CWM中,围绕着UML的技术便有三U:(x)UML本n自不必说Q版本已l到?/SPAN>2.0Q?/SPAN>MOF作ؓ(f)“徏模语a的语a”,g是?/SPAN>UML量n定做的,虽说MOF有能力创建出?/SPAN>UMLq齐驱的徏模语aQ但是似乎没有看到谁q么qԌ大家只是在努力的发展UML的“方a”,例如UML Profile for CORBAQ?/SPAN>UML Profile for EJB{等Q?/SPAN>XMI是“模型的标准存储交换格式”,Z解决不同的徏模工具创建的模型不能互用的问题,OMG创徏?/SPAN>XMI作ؓ(f)模型的存储交换标准。这样一来,UML工具更加可以大行光Q用不同的建模工具创徏?/SPAN>UML模型可以互相交流Q只要它们都ZXMI?/SPAN>
UML相关工具工具的多寡与优劣可以看出某个技术的受欢q程度,在徏模工具中Q不?/SPAN>100Q,大概也有90Q支持了UML语言。最出名?/SPAN>UML工具Rational RoseQ被IBM收购了;Eclipse下面?/SPAN>UML工具EclipseUML让开发它的小公司Omondo也出名了Q国内也有一?/SPAN>UML工具Q听说效果也不错Q就是楚凡科技?/SPAN>Trufun Plato 2005。至于其他国际上有点名气?/SPAN>UML工具Q更是不胜枚举,几乎有点软g实力的国Ӟ都有自己?/SPAN>UML工具?/SPAN>
当然Q?/SPAN>UML不仅仅出现在专用?/SPAN>UML工具中,它也频繁出现在最新的各种开发环境中。例如编E开发环?/SPAN>JBuilderQ具有将代码转换?/SPAN>UMLcd的功能;Together更q一步,直接实现了代码和cd的同步{换;Eclipse作ؓ(f)最优秀的开攑ּ开发^収ͼ拥有众多?/SPAN>UML相关插gQ除了前面提到的EclipseUMLQ比较有名的q有EMF?/SPAN>UML2?/SPAN>
UML?/SPAN>MDA出现之后Q在OMG的概念中Q成ZMDA的一个子集(虽然UML的名气远q大?/SPAN>MDAQ。因此众多的MDA工具中,几乎都少不了UML功能。我认ؓ(f)很多MDA工具是?/SPAN>UML工具直接改过来的?/SPAN>
UML使用现状照理说来Q如火如荼的标准和工具应该催生出如火如荼的应用才对,可是UML的用状况实在不如人意。无论是w边的还是网l上的朋友,在项目中使用UML的都是凤毛麟角,即便使用?/SPAN>UMLQ也是在很小的范围内Q完全没有发挥出1Q的功效。现在ȝ一下目前我所知道?/SPAN>UML使用现状Q?/SPAN>
l M码时Q用UML工具q行逆向工程Q可以清晰的观察代码l构Q方便理解代码?/SPAN>
l 写代码时Q由于开发^台可以自动生?/SPAN>UMLcdQ因此有时观?/SPAN>UMLcd得到比较清晰的代码结构。例?/SPAN>Together或?/SPAN>JBuilder{工兗当Ӟ如果没有自动生成?/SPAN>UML图,大部分h也不?x)寻扑օ他工具去生?/SPAN>UMLcd的?/SPAN>
l 撰写U技论文Ӟ使用UML来表辄l架构或者系l流E等?/SPAN>
l 部分?/SPAN>UML非常熟?zhn)的程序员Q在开始写代码Ӟ先画UMLcdQ然后利用工L(fng)成代码,最后对代码q行扩展?/SPAN>
从上面的使用现状可以看出Q很多h?/SPAN>UML当成一U可有可无的技术。即使用了UMLQ也只是围绕着UML中的cdQ其他的UMLN抛到一边去了。造成q种状况的原因,一斚w固然是因为国内的正规大型软g目比较?yu),软g工程技术v步很晚;另一斚w是由于国内不是架构师、系l分析员、Y件工E师、程序员、测试h员等{实质上都是E序员而已Q很多h是赶着鸭子上架成了架构师或者系l分析员的。这U状况下QY件工E的概念难以深入人心Q?/SPAN>UML更加成了一个国内项目的鸡肋?/SPAN>
看看国外的架构师?/SPAN>UML专家们,往往都是满脸大胡子,在计机领域中浸淫了3Q?/SPAN>40q_(d)而中国最古老的E序员,也只有十几年l验Q除d黑暗中摸索的几年Q有十年以上开发经验的E序员少之又。不l历几个大型目Q要使用软g工程技术是不可能的Q也是不能vC么效果的。因此,有h堂而皇之的撰文?/SPAN>UML的三大硬伤”,?/SPAN>UMLx得一无是处。高喊口h倒某东西是很Ҏ(gu)的,关键是打倒了UML何以取而代之?
E序员眼中的UML既然国内90Q以上的软g开发h员都是程序员Q那么程序员g?/SPAN>UML到底应该是什么样子的呢?我很期望有一本好书能够让E序员们快速的掌握自己所需?/SPAN>UML知识Q遗憄是目前还没有看到q样的一本书。无论是“三友”的UMLl典教材q是国内的一些?/SPAN>xx天精?/SPAN>UML”都不符合这L(fng)要求。没有一本是“有中国特色?/SPAN>UML教材――一本写l程序员?/SPAN>UML入门书”?/SPAN>
作ؓ(f)一个程序员Q我很了解其他同僚的心理Q如果拿C本书Q翻了一个小时还没有扑ֈ可以run?/SPAN>HelloWorldQ?/SPAN>90Q的Z(x)大叫一声“去nmd”,然后把书扔进废纸堆。不能怪我们急功q利Q在q个技术术语满天飞Q连底层q_都动荡不安的q代Q谁q有旉和兴看一些与自己无关的东西呢Q?/SPAN>
我很能想象一个程序员Q好不容易空出时间来看看最q很热的UML技术,当他拿到一?/SPAN>UML入门以后Q开始寻扑֯自己有用的东ѝ在开始的一个小Ӟ满篇都是需求分析,use caseQ甚至书的作者还在饶有兴的介绍use case有六U译法:(x)用例、用c用?/SPAN>…?/SPAN>对不P老子一癑ֹ都没做过需求分析了Q也不想知道q个狗屁?/SPAN>use case到底叫什么。于是开始后(zhn)在china-pub上又白花了这么多银子?/SPAN>
q有些书上信誓旦旦的说“学?/SPAN>UMLQ走遍天下都不怕”,如果你做需求分析,你可以用UML和客户交;如果你做pȝ分析员,你可以用UML设计pȝQ如果你做程序员Q你可以?/SPAN>UML生成E序Q如果你做测试员Q你可以ZUML设计试用例。而实际情冉|什么呢Q国内的客户有几个懂UMLQ懂UML的h差不多自己都可以把Y件写出来了,q需要请你做需求分析么Q别说客户了Q上ơ听同学说和北京某大U研所的工E师们交,无意中说起了UMLQ在场的竟然只有一个稍微了解,而且坚持认ؓ(f)那是一U画囑ַP那位仁兄其实也没错,Visio不就是一个画囑ַ具么Q?/SPAN>
虽然状况如此不堪Q但?/SPAN>UML实是一个很优秀的“交语a”、“代码生成工具”和“系l设计工具”。让我们擦干w上的献血Q掩埋战友的怽Q睁大迷蒙的双眼来看?/SPAN>UML对程序员的作用?/SPAN>UML有九(ji)U图Q作用各自不同,基本上涵盖了软g工程的各个方面,很多人就是不堪于忍受知识不的困惑与“侮辱”(很多E序员认ZU技术自q不懂是对自q侮iQ,从而放弃了整片UML林。他们怕的不是?/SPAN>UMLq棵?wi)上吊死Q而是怕在UML林里面q\。但是我惌Q知识学?fn)的q程是去芜存精Q找出对自己有用的东西,然后掌握之。对于程序员来说Q?/SPAN>UML的h(hun)值就体现在三个方面:(x)
一?/SPAN>UML是最好的交流语言Q无论是与其他程序员交流Q还是与领域专家、测试员或者用户交。原因只有一点,UML是标准的Q就像英语一P无论多么该死Q大家还是忙着把自q论文Ҏ(gu)英文的。当Ӟ在小的领域可能有更好的交方aQ但是在大而长q的交流中,使用标准的交语a是稳妥的?/SPAN>
二?/SPAN>UML是很好的代码生成工具Q其实代码生成功能ƈ不是?/SPAN>UML语言和规范提供的Q而是?/SPAN>UML工具提供的,而且不同?/SPAN>UML工具提供的代码生成功能还不尽相同。例?/SPAN>Rose提供单的代码框架生成Q?/SPAN>Eclipse插gEMF可以生成功能丰富Q提供了各种设计模式的代码包。无论如何,如果E序员可以从UML入手来写E序Q比直接敲代码要高那么一点点。从文档、版本控制、维护、测试等各方面来_(d)?/SPAN>UMLcd比直接写代码都要高那么一点点?/SPAN>
三?/SPAN>UML是很好的pȝ设计工具。对于程序员来说Q很用到“设计”这个词Q大部分时候我们都是在“编写”或者“实现”。但是勿庸置疑,E序员的许多工作中还是需要“设计”的。包和组件之间的依赖关系、复杂操作的程、对象之间的兌和状态、程序的部v{等Q都l常是程序员的工作。那么上面的四种情况可以?/SPAN>UML的组件图、序列图、对象图和部|图来设计。虽Ӟ不同的程序员有不同的设计Ҏ(gu)或者设计图例,不过Q?/SPAN>UML是标准的。不要忽视标准的力量Q标准的东西意味着在全世界范围内都有可能会(x)被看懂,不标准的东西可能Z你的办公室就没h能够清晰、准的理解了?/SPAN>