按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
原本看起来困难的事情一下子就被Web Service和CORBA联手解决了。这正是一个非常
好的Web Service应用范例。
那么在2002年，Web Service在信息业界应用的情形到底是如何呢？到底有没有信息
系统在使用SOAP和Web Service技术呢？其实，我们从各种开发工具都支持Web Service
的应用来看，一定是有人已经在使用Web Service了，否则没有必要几乎所有的开发
工具都争先恐后地加入对于SOAP和Web Service的支持。
下图是2002年信息界对于使用Web Service的最后调查结果，从数字中我们可以看到，
没有使用Web Service的比率是43。2％，但是超过50％的调查显示Web Service已经
或多或少的被应用在信息系统之中了。而这些统计数据也代表了Web Service被实际
应用的证明。
另外一份对于Web Service应用的调查结果如下页所显示。我们可以看到在2003年中
Web Service将有更大的使用比率，可见Web Service的应用将会快速地提升。
如果我们把两份统计结果以趋势图同时呈现的话，会发现Web Service应用的成长比
率几乎不会输给一般的开发工具或是程序语言的成长比率。
在2003年Web Service除了将愈来愈普及之外，新的Web Service规格也将慢慢完善并
且开始被软件厂商实现。除此之外，也开始有信息厂商对Web Service的缺点加以改
善推出变形的解决方案。不过千变万变，不变的是在现在信息多元化的时代正显示了
我们的确需要Web Service代表的穿透力和整合力。
许多人当初说Web Service是不实际的技术，从目前的各种迹象和统计数字来看这些
人似乎是错了。Web Service的简单化不代表无用，其缓慢也不代表不可用。我们只
需要在适当的地方使用适当的技术，Web Service就是一个很好的例子。毕竟当初Don
Box在定义SOAP时最原始的想法本就是〃简单（Simple）〃，不是吗？
面向对象技术的平民化
〃你们是用什么方法来开发系统的？〃，〃你们使用UML吗？你们在使用面向对象方式开
发应用系统时使用所有的UML图形吗？〃，〃你们遵循RUP来发展软件吗？〃，这些问题
是我在和一些信息界的朋友聊天时经常询问的问题，因为我也非常想了解UML/RUP和
Modeling在业界使用的情形。
UML和Modeling的需求在三位OO大师多年的提倡并且成立Rational公司开始大卖Rose
后，照理说UML和Modeling在信息业界应该是被广泛地使用，不是吗？但是情形似乎
并不是如此。
在我知道的许多案例中，许多公司或是信息机构在购买了Rose之后，要么被供奉起来
成为一种先进/时髦的象征，不然就是被使用来作为画图的工具。即使是真地使用UML
和Modeling的公司也大都只是使用Rose画画Use Case、Class Diagram和Object
Diagram，再继续深入得几乎没有。为什么会如此呢？UML已经被证明是非常好的理论、
开发方式和沟通语言，Rose也推出了这么多年，为什么UML的普及率仍然非常低呢？为
什么许多购买了Rose的公司和机构也没有完全使用Rose的功能呢？这其中一定有一些
问题存在。但是，这是什么问题呢？
就我个人的经验来说，在许多的项目开发之中大概都只有使用到Use Case、Class
Diagram和Object Diagram，最多画画Sequence Diagram，接着就是结合组件模型、
开发工具和数据库开始进入开发的阶段，比较注重CBD的开发模型，鲜少使用到其他
的UML图形，因此可以说是偏向结合UML和Extreme Programming，以项目时程为最重
要的依归，并不强调完全遵照UML和RUP。因此，我也非常想要和其他的朋友交流，了
解其他人使用UML/RUP的情形，或者其他人是如何使用OO技术开发项目的。
我个人也是从事信息工作的一员。虽然没有什么显著的贡献，但是我对于UML和Rose
始终有一份怀疑。当然，这份怀疑并不是指UML和Rose没有用，相反，UML的确对于软
件工程有着卓越的贡献。不过我认为UML和Rose之中的许多东西过于繁琐，要实际应
用在项目发展之上，除非项目没有时程和资源的限制，就像Rumbaugh自己在GE时从事
的实验计划，拥有许多的资源和宽阔的时程，否则，怎么可能有时间和资源把所有的
UML图形都画出来呢？至少就我个人的项目生涯来说是从来都不可能的，因为在我个
人的信念中项目开发最重要的准则是〃On…Time Delivery Of A Working And Decent
System〃，不是UML，不是RUP，更不是任何其他时髦软件技术。
另外，我一直认为Rose实在算不上好的软件，每一次我使用Rose就有种回到Windows
3。1时代的感觉。此外，Rose在绘制UML图形上始终有一些小问题，从版本1开始到现
在都没有改善。因此我也曾经开玩笑地说，〃Rose是全世界一流的OO分析师配合三流
的程序员开发出采的产品〃。因此我个人对于UML/RUP一直有着一份怀疑，只是人微言
轻，不敢轻易表示对于UML/RUP的质疑。
不过，在Extreme Programming对于UML/RUP开发模式提出类似的质疑和逐渐分庭抗礼
之后，我也在Internet/Intranet上看到愈来愈多对于UML/RUP的批评以及许多人公开
讨论使用UML/RUP失败的原因和检讨。此后，我总算如释重负，因为这些都证明了不
单是我个人有疑问，许多人都有相同或是类似的问题。我认为这些批评和质疑对于
UML/RUP是一件好事，因为这可以让软件界再次审视UML/RUP不足之处，找出问题的所
在并且加以改善，才能够让UML/RUP持续地对软件界和软件工程做出贡献。正由于
Extreme Programming对于UML/RUP的挑战，反而可以让我们更清楚地了解什么方法才
是最适合的。我个人认为，对于小/中的系统或是项目而言，简易的UML和Extreme
Programming是比较适当的，而对于大型的企业应用系统（Enterprise Application
System）而言，UML和RUP被证明是有效的。
一直到2003年初听了TogetherSoft的首席科学家（Chief Scientist）Todd Olsen的演
讲后，才正式确定了我的想法没有错。连Todd Olsen都认为UML/RUP太过于学术化，
对于学术的研究没有问题，但是在实际的应用中则稍显繁杂。开发人员应该在开发工
具的辅助下进行适当的修整以找出最〃适当〃的方式来进行项目或是系统、工具的开发。
连Todd Olsen这种经验丰富、软件开发实力又惊人的大师级人物都这么说，我也就放
下心来了。看来属于实战型的开发人员，依照武侠书的讲法，应该掌握的是〃最具杀
人威力的剑法，而不是华丽的招式〃。当时我在聆听了Todd Olsen大胆的说法之后不
禁大呼过瘾，隐藏在心中多年的质疑终于一挥而去。
虽然过于拘泥于UML/RUP的开发模型不算是好的方式（或许这对于学术研究是正确的），
但是也没有人完全否认UML/RUP对于软件开发的贡献。事实上UML是很重要的，因为它
可以让开发人员使用同一种语言沟通，也可以很有效地使用Use Case让企业人员和开
发人员沟通。但是为什么在Rational推广Rose这么多年来普及的成效仍然有限呢？我
个人认为有如下的原因：
■ 价格昂贵，难以普及
■ 只锁定金字塔顶端的开发人员
■ 过于强调完整的UML/RUP开发模式
■ 没有和开发工具整合在一起，以打入一般的开发人员群体
由于Rose采取高价的策略，因此虽然为Rational赚进了大把的钞票，但是也让UML/RUP
和Rose的普及率难以大幅地扩展。想想10年前的Client/Server技术也是在
PowerBuilder、Gupta等采取高价措施而难以快速普及，一直要到VB和Delphi等大众化
开发工具提供了Client/Server功能之后，才让Client/Server快速为大多数的软件人
员视Client/Server技术为理所当然的基本技巧。在PowerBuilder/Gupta错失了占据
Client/Server的庞大市场之后，再也无法成为Client/Server的领导厂商。
同样地，如果Rational一直为Rose采取高价，只锁定高阶开发人员市场的策略，那么
Rose很可能会在其他的竞争对手推出更好的UML产品之后快速流失市场，事实上这正
是Rational在2002年面临的困境，因为Rose不但遭受许多UML小厂商的竞争，更被其
最大的竞争对手TogetherSoft打得难以招架，要不是Rational还有3位OO大师的名号
在力撑，Rose早就被TogetherJ或是TogetherSoft的Control Center打得落花流水了。
从最近4年TogetherSoft可怕的成长速度可以看出来，Rational早已被TogetherSoft
逼得寝食难安了。
在Borland并购了TogetherSoft之后，Rational将面对更为艰难的状况。一旦Borland
成功地在其的开发工具中整合TogetherSoft的产品，那么将可能会像当初的Client/
Server技术一样，可通过提供更平易近人的UML工具而快速让UML为大多数的开发人员
接受而使用。再加上如果Borland以合理的价格提供UML和开发工具，那么将可以让UML
打入金字塔中/低阶的开发市场，快速鲸吞Rose的市场。到时Rose在UML/Modeling产
品本身不如TogetherSoft之下，再加上Borland开发工具的强力支援，Rational的大
势不妙。因此这是为什么当Borland宣布并购TogetherSoft之后受伤最深的公司就是
Rational，而Rational也立刻声明中断和Borland的合作的原因。最后在Rational眼
看后势欠佳，再加上IBM提出动人的并购条件之后便立刻接受了IBM的提议。
根据2002年的信息调查显示，大多数的开发人员已经视Modeling工具为相当重要的工
具。
而且目前使用Modeling工具的开发人员也相对地满意于Modeling工具提供的功能。因
此，如果Modeling工具能够再和开发工具紧密地结合，那么Modeling未来的发展将更
为快速。
目前在所有和开发相关的工具中，Modeling和设计工具已经占据了相当重要的地位。
根据2002年调查的结果显示，设计和Modeling工具已经分别占据了所有开发相关工具
的第2和第8名，而且还呈现持续上升的状态。
由此可见，开发人员已经愈来愈重视设计和Modeling工具。在Borland并购TogetherSoft
之后，我认为Borland会以较为合理的价格提供整合Modeling和开发工具的软件包，
快速把UML技术打入一般开发人员的市场，并且将会正式触发使用UML和Modeling功能
成为开发人员的核心基本技巧，就像数年前Client/Server技术对于开发人员一样。
因此，我们可以发现下面图形呈现的还是去年以前开发人员拥有的技术状况。开发人
员的核心技术只需要拥有程序语言、数据结构和Algorithm即可。
但是从2003年开始，一旦Borland或是IBM推出整合Modeling工具和开发工具的新一代
软件之后，面向对象、Modeling和Design Pattern等技术将被压缩�