为什么CASE工具没有成功?

首先,我认为图表在小而简单的时候提供了真正的价值。大型的、高度详细的图表通常会浪费大量的纸张、时间和硬盘空间等。对于足够小(并且足够简单)而有用的图表来说,铅笔和纸张非常适合。一个软件工具只有在你制作一个如此庞大和复杂的图表时才有帮助,而实际上它是毫无用处的。

当你认真研究它时,我很少看到CASE工具被用作“软件工程”的实际“辅助工具”。在我看到的大多数情况下,软件工程是完全独立完成的,CASE工具用于从已经编写的代码中逆向工程图。制作图表的人普遍认为这些图表毫无用处,于是把它们列入了向上级经理提交的“惊喜因素”报告中。他们希望从图表中得到的唯一“帮助”是,他们所做的工作的复杂性给管理层留下了深刻印象,希望增加资金(有些包括标准库部分的图表,纯粹是为了增加明显的复杂性)。

至于这些工具是如何在软件工程部分失败的,我不知道一个简单的答案——从我所看到的,我认为这更像是一个“千疮百孔的死亡”,而不是任何一个突出的问题。如果我真的要指出一个大问题,那就是我所看到的那些问题并没有真正考虑到模式。举个例子,我想要的是在更高的抽象层次上工作,这样我就可以指向一些功能,并处理类似“如果我将该功能的以下部分实现为decorator类,情况会如何?”是的,我可以用它们作为装饰器类绘制一个图,也可以不用它们绘制一个图,但是我没有一个非常快速、简单的方法来说“转换整个层次结构,将X、Y和Z移动到装饰器类中。”

将典型的CASE工具与电子表格进行对比。在电子表格中,我可以更改一个单元格,它将自动重新计算它对电子表格中依赖它的任何其他单元格的影响。相比之下,CASE工具似乎(至少对我来说)停留在网格控件的大致级别上,我可以在单元格中进行更改,但我仍然必须手动跟踪其他单元格依赖于该单元格的内容,以及要使用的公式,并手动计算和修改所有受影响的单元格。是的,如果我想打印出一张正确的值,可以在电脑上编辑它们,这样我的单元格里就不会有橡皮擦之类的标记 将 是一种进步,但只是一种进步 小的 改进,而不是那种把个人电脑从一些业余爱好者的玩具变成地球上基本上每一项业务的主食。

如果你查看维基百科条目: http://en.wikipedia.org/wiki/Computer-aided_software_engineering

此外,工具卖得太多也于事无补。有前途的管理不现实地提高了生产力。在它的任何一个领域,我都没有见过这么多的货架上的产品-产品用于一个项目,然后放弃,往往随着项目太多。

CASE的概念存在于Eclipse和许多其他MDE工具中。学习曲线陡峭和碎片化的问题一直没有得到解决。虽然工具的成本已经降低(在许多情况下是免费的),但培训、咨询和升级成本仍然存在。

在您花费大量精力在CASE工具上之前,先看看MDA、MDE、DSL甚至UML的领域。浏览OMG网站也是值得的。

在一天结束的时候,你应该把注意力放在你生产的东西上,而不是工具上。如果你能自动化一些任务,那就好了。构建另一个类似案例的工具是一个很好的智力练习,但商业成功的机会微乎其微。毕竟,IBM、Oracle和Computer Associates在工具方面只取得了零星的成功,他们仍在大力向企业客户推销这些工具。