技术开发 频道

对象模型遭遇滑铁卢,模型驱动异军突起



【IT168 技术文档】

长期以来,面向对象模型一直不移余力地鼓吹可以使开发团队更快速地获得更高质量的软件,以及更好的代码复用。但不幸的是,传统的面向对象解决方案,如统一建模语言(UML),在实际应用中却没有履行自己的承诺,这是因为这些技术并没有在现今的环境中表现得更另人信服,而那些经常宣传的激动人心的结果也并不时常发生,发生这种情况的原因也许是计划不如变化快吧。
本文将揭示关于传统面向模型技术的一些缺陷,并向读者展示如何使用模型驱动构架(MDA)来提供更完美的解决方案,并向面向对象模型发起挑战。

一、当前的软件建模所面临的挑战
    开发可定制的软件和应用程序对于企业来说总是非常必要的。对于小型或中型企业在没有使用这些繁琐的开发模式就可以非常快速地建立可定制的应用程序,但对于大型企业却不能做到这一点。为一个跨国企业开发复杂的应用,就象是建立一个几百层的大厦,如果没有设计蓝图、经过严格训练的建筑工人、高效的工具,以及其他非常重要的条件,这个建筑物的地基将很快坍塌。
    在20世纪90年代,面向对象分析和设计(OOA&D)的概念为了向复杂的企业应用程序发起挑战,形成了一个银弹解决方案。在实践中,OOA&D是一项为了设计解决方案而分析系统需求的对象模型技术的使用。OOA&D方法学使用了多种UML图表来描述需求、设计、实现、测试和发布。很朋企业在这段时间内成功地应用了OOA&D技术。
    但不幸的是,对象模型的最初所具有的效用已经由于很多原因而褪色,这主要是因为技术以一个非常危险的步调在变化。使用传统的对象模型技术所制定的方案很快就会被废弃。这此动态的需求主要由以下因素形成,尤其是对于企业层的的开发团队更是如此:

1. 商业模型的变化更频繁和快速 — 这些变化通常由企业合并、获得、投资以及其他的商业模型所导致。变化在现今的企业中将是永恒不变的,但是复杂、多层的应用程序构架并不象商业模型那样容易变化 — 这就意味着整个开发团队要从头做志。并没有一个完美的构架设计来支持长期的维护,而重新对原有的系统进行翻新可能要比开发它更费时间。

2. 遭遇生产力瓶颈 — 一但软件需求和开发周期被确定,构架师一般就会按着传统的方式进行工作。他们会开很多应用开发会议(JAD),来讨论高层的设计和概念分析,并对开发处理和开发周期上进行决策。在这时,设计开始失去了它们的价值。取而代之的是开发人员直接去实现它们,开发团队因此失去了时间上的概念,并且冒着用户需求随时变化的危险仍然沿用构架师在白板上建立的用例图、序列图以及类图进行设计和实现。
 
    也许这种模式在过去的十几年间已经足够用了,但对要对更高生产效率的今天的开发任务恐怕有点捉襟见肘。最终,一个团队必须停止画他们的设计图,而开始写代码。
0
相关文章