建模动力:UML2.0使模型驱动的开发更加容易
UML 规约的新版本将很快提交给OMG,新的改动希望能够简化模型驱动的开发。 Rational 公司新加坡分部的高级 软件工程 专家,Mark Hermeling认为:UML2.0根据工业界使用UML1.x的经验作了相应改进,目的就是为了帮助简化模型驱动的开发。 UML的目前版本是1.4,它
UML规约的新版本将很快提交给OMG,新的改动希望能够简化模型驱动的
开发。
Rational公司新加坡分部的高级
软件工程专家,Mark Hermeling认为:UML2.0根据工业界使用UML1.x的经验作了相应改进,目的就是为了帮助简化模型驱动的开发。
UML的目前版本是1.4,它提供了方便开发团队在分析设计、
需求管理等活动中进行交流的整套工具,以及一个软件开发生命周期模型。
有人将UML描述为交流的符号集,这意味着可以直接写在纸上或者画在白板上。但大多数用户还是选择使用工具,目前业界的领导是
Rational,它和其它的工具提供商一起提供各种UML产品。
1996年,UML刚诞生的时候,广受欢迎。在UML之前,建模方法非常多,这大大阻碍了基于模型的设计,而UML实现了建模语言一定程度上的统一。
进行
面向对象设计的时候,第一步就要对现实世界进行建模,UML正是为之定义的一套标准符号,它由三种面向对象的分析设计方法发展并整合而来:Grady Booch 描述对象及其相互关系的方法、James Rumbaugh的对象建模技术(OMT) 以及 Ivar Jacobson的方法,在Ivar Jacobson的方法中引入了
use case方法的使用。
经过多年的发展,在Rational 公司的Booch、Rumbaugh、Jacobson 三友以及其它专家的努力下,UML中还融入了很多其它的思想,现在,UML已经成为OMG认可的标准。
尽管UML只是帮助参与开发的所有人员对模型进行交流的一套符号系统。但Martin Fowler在其著作《UML Distilled》中指出,UML是由描述开发过程和有关模型的使用的方法论发展而来的。尽管目前没有被广泛接受的统一过程,UML的使用者使用的方法实际上都非常相似。UML规约中有关建模的概念是对象、类、关联、职责、活动、接口、use case、包、顺序、协作和状态。
在使用当前版本进行UML模型驱动的架构时,使用者发现还缺少一些支持,如
bug修复等,UML2.0中将增加这部分内容,它将成为适用于企业建模和数据建模的庞大而灵活的符号语言。在UML2.0中,将对语意部分进行增强,这一点可以帮助UML模型更好地生成代码,以得到更加实用的模型。在即将推出的版本中,还将包括增强的组件处理、对商业过程模型的支持,并更好地支持元数据交换。这些努力都是为了使UML作为一种胜过大多数文本语言的高层次的语言,能够生成代码和进行反工程,甚至直接生成某些可执行的UML模型。
目前,在各种工具之间进行模型交换时,只能保存非图形化的信息,而象绘制的各种图、尺寸、坐标这样的内容都会丢失。在UML2.0中,将提供保留图形信息的能力。
来自Rational公司的Hermeling认为,
工程师与开发人员将越来越多地看到对建模的
需求。他认为,对于一个较大的开发团队来说,需要有一个可视化的模型以保证所有人员都能理解总体的设计思路,建模的
需求是显而易见的。
利用业务过程建模,应用UML可以得到业务的可视化模型,其作用类似于建筑工程中的结构图。这个可视化模型可以使你在构造整个软件系统之前,就可以理解并预知设计的一些关键特性,判断设计是否可行。事实上,除了软件工程,在众多工程领域中,建模都是非常关键的规避风险的技术。
但是,在Fowler眼里,软件工程和其它工程是不同的。
首先,对建筑工程来说,工程师一般都有多年的经验并且对所用的各种工程符号了如指掌,而UML的设计可能在纸上画出来看着很好,真正
编程时却会发现很多问题。另外,在建筑工程上,关键设计都是可以经过数学分析进行验证的;而在UML设计中,类似的手段只有同行评审,虽然有一定作用,却并不能避免错误的发生。
另外,在成本比例方面,软件设计和其它领域的工程也是截然不同的。举修桥的例子来说吧,设计成本可能也就占全部成本的 10%,而在软件设计中,这个比率是50%。
UML最早是由Rational公司提出的,但已经被很多公司使用,这里面最重要的就是OMG。公众对UML的接受刺激了以模型为中心的开发,OMG提供了支持这种开发的一系列标准的框架
MDA(Model-Driven Architecture)。MDA的关键特点就是软件开发的重点和输出不再是程序,而是各种模型,开发人员的工作是不断拓展模型,只有到了最后阶段才会考虑将其实现。
OMG认为,利用MDA可以得到更好的“高层抽象”设计框架,更好地得到针对今天各种语言的“通用化”代码。和正在酝酿之中的基于X
MI的数据交换一样,基于MDA的数据交换方法将给开发商和用户双方带来好处。
XMI(XML Metadata Interchange)试图通过XML语言为
程序员和其它用户提供一种交换元数据信息的标准途径。XMI希望能够帮助使用各种语言和开发工具的UML开发人员自由地交换数据模型,另外,XML也可以用于数据仓库信息的交互;最重要的是,XMI制定了描述各种元数据定义的统一标准,并要求跨行业和跨操作环境的用户使用一致的方法读取数据。
今年6月,包含OMG MDA标准,促进模型交互的UML基础库修改版已经正式提交讨论。参与讨论的包括用户熟悉的很多开发商,包括I-Logix,
Oracle, Rational, Telelogic and Computer Associates等等。
UML2.0中还将包括对组件建模的改进。近几年来,随着J2EE和微软的
.NET技术的出现,组件技术得到很大发展。这方面,UML2.0中将考虑如下内容:如何更好地描述组件描述的语意以及构建
.NET和企业
JavaBeans的专门模块。
Jim Duggan ,artner公司的副总裁和研发总监,认为UML2.0中要处理的首要问题就是保证标准的扩展性,他认为现行的标准中扩展机制定义得不够,导致各开发商使用了不同的扩展方法。另外,还必须提供对组件开发、面向服务的框架以及
web services的支持。
有人提倡,UML的发展应该是向下兼容的,要保证过去基于UML1.x的用户和工具开发商所做的努力不会全部作废。UML2.0中应该提高精确度,可以选择加入少量的一些新特性,要避免导致“语言膨胀”的困境。而现在有一个不妙的苗头: UML将变得越来越大,而在最初,OMG声称的目标本来是简单化的。
Gartner公司的Duggan认为,“新的规约正在变得越来越复杂,变得非常大,难以管理、理解和实施。标准委员会曾经说过将要把物理模型和逻辑模型分开。但是,一旦规约复杂化了,要做到这一点就不大可能,而且规约本身也开始失去作用。”
Alistair Cockburn,Humans and Technology的顾问,在他的论文中表达了同样的意思。“在软件开发中把人也当成了非线性的、第一位的组件”,Cockburn认为那些重量级的开发方法中试图为一切建模,这是导致成功率不高的重要原因。他认为在软件开发中人是最重要的,在设计符号中把人当成一个组件,就是最大的失败之源。
其它公司,如Telelogic也在致力于利用UML2.0从图形化的用户模型中自动生成代码。Telelogic在新加坡和亚洲其它地区创建了开发中心,力图提供帮助从概念模型转化到组件的软件。Scott Raskin(如图),Telelogic公司亚太地区总裁,认为亚洲是这方面增长最快的地区。“UML允许组织从计划到
嵌入式系统实现的全部生命周期实现
自动化”但是,对于有些程序员而言,并不需要UML,他们完成的代码中通常都很难找到相似的地方,对他们来说,模型是多余的。
Gartner公司的Dugguan警告说,“要记住,UML只是一种符号,并不是什么方法论”。但事实上,几乎所有的面向对象分析与设计(OOAD)工具和业务模型都是使用的UML。Dugguan指出,根据Gartner公司的估计,在所有项目中,使用OO A&D方法论的大概有10%到12%,和过去使用CASE工具的峰值数值几乎相同。Dugguan认为这个数字还会继续增加到15%到20%。在数据建模领域,IDEF符号还在广泛使用,但UML也开始进入。
Dugguan认为,设计工具的总体使用率还是很低,在项目中使用设计驱动开发方式的大概有10%,通常是那些对
质量和持久性要求很高的项目。而数据建模工具在项目中使用的比率大概是35%,大多数情况下都是由DBA使用。
尽管UML可以和白板一起使用,但它还是复杂了些。Gartner公司认为有以下原因导致了UML的低使用率。首先,在小的短期项目和开发周期中根本不用设计,都是采取的快速开发和演进。Dugguan说,“根本不需要最佳实践,能用的实践就够了。”第二个原因是大多数遗留的程序都是面向过程的,不需要UML或者什么工具。但他又加了一句:“新的事件驱动和对象驱动的程序
开发技术可以从UML工具中受益,新的开发人员很多都学过这些符号,而且会用相关工具”。
事实上,UML正在将工具开发商们凝聚在一起,很多公司都参与了UML2.0的修改过程。除了Rational之外, Microsoft、Sun、IBM、
Oracle、
Borland、Telelogic等公司也都是UML协会的成员
原文转自:http://www.ltesting.net
|