为什么CASE工具没有成功？

Question

......或者他们为什么失败？

我打算建立一个可归类为CASE的概念证明，但我想避免以前做过的一些错误。

谢谢！

Answer 1

首先，我认为图表在小而简单时提供了真正的价值。大而高度详细的图表大多浪费了大量的纸张，时间，硬盘空间等。铅笔和纸张非常适用于足够小（并且足够简单）有用的图表。一个软件工具只有在你制作一个如此庞大和复杂的图表时才有用，它几乎可以保证无用。

其次，对于大多数CASE工具，绘制图表的最快方法是首先编写一些（可能是简化的，模型化的）代码，然后从代码中“反向工程”图表。直接绘制图表通常比编写代码慢。为了提供更多真正的价值，生成高级图表必须比编写等效代码简单得多。

当你开始讨论它时，我很少看到CASE工具用作“软件工程”的实际“辅助”。在我看到的大多数情况下，软件工程完全是分开完成的，CASE工具用于从已编写的代码中反向工程图。制作图表的人通常认为它们毫无用处，并将它们包含在报告给高级管理人员的“惊叹因素”中。他们希望从图表中获得的唯一“帮助”给管理层留下了深刻印象，因为他们正在做的事情很复杂，希望增加资金（有些包括标准库部分的图表，纯粹是为了增加明显的复杂性）。 / p>

至于软件工程部分的工具是如何失败的，我不知道一个简单的答案 - 从我所看到的，我会说它更像是“一千个刻痕的死亡”，比任何单一的，明显的问题。如果我确实必须指出一个大问题，那就是我所看到的那些问题并没有真正考虑到模式。举个例子，我想要的是在更高的抽象层次上工作，所以我可以指出一些功能，并且玩“如果我要将该功能的以下部分实现为装饰班？“是的，我可以将它们作为装饰器类绘制一个图表，一个没有，但我没有一个非常快速，简单的方法来说明“转换整个层次结构以将X，Y和Z移动到装饰器类中。” / p>

将典型的CASE工具与电子表格进行对比。在电子表格中，我可以更改一个单元格，它会自动重新计算这会影响依赖于它的电子表格中的任何其他内容。相比之下，CASE工具似乎（至少对我来说）大致停留在网格控件的水平，我可以在一个单元格中进行更改，但我仍然需要手动跟踪其他单元格依赖于哪一个，以及哪些公式为手动使用，计算和修改所有受影响的细胞。是的，如果我想要打印出一张正确的值，可以在计算机上编辑它们，这样我的单元格中就没有橡皮擦标记，这样会是一种改进 - 但是只有小的改进，而不是那种将个人电脑从玩具转变为几个业余爱好者的东西，而不是基本上是地球上每个企业的主要产品。

Answer 2

如果您查看维基百科条目：http://en.wikipedia.org/wiki/Computer-aided_software_engineering，那么您将看到20世纪90年代的“经典”工具。与许多这些工具合作后，我认为对商业化的关注使市场分散。通常，您不仅要为工具支付巨额费用，还需要为咨询，培训和运行时环境支付巨额费用。有了这么多工具，很难建立一个专门研究特定工具的称职的团队。

此外，这些工具被过度销售也无济于事。有前途的管理不切实际地提高了生产力。没有任何其他IT领域，我见过这么多货架 - 用于一个项目然后放弃的产品，通常也与项目一起放弃。

CASE的概念存在于Eclipse和许多其他MDE工具中。陡峭的学习曲线和碎片问题仍未解决。虽然工具的成本已降低（在许多情况下是免费的），但培训，咨询和提高成本仍然存在。

在为CASE工具花费大量精力之前，先看看MDA，MDE，DSL甚至UML领域。值得浏览OMG网站。

在一天结束时，您应该专注于您生产的产品而不是工具。如果你能够自动执行某些任务，那就很好。构建另一种类似CASE的工具是一项伟大的智力锻炼，但商业成功的机会很小。毕竟IBM，Oracle和Computer Associates只是在他们的工具上取得了零星的成功，他们仍在大力向企业客户推销它们。

Answer 3

90年代初，我与Knowldegeware合作。我对CASE消亡的简单回答是，一旦您打印了模型，它就会很旧。保持模型和代码同步变得不可能。第一个目标平台是MicroFocus COBOL，但随后出现的是Client-Server 94-95，其次是Internet 97-98，没有人真正想在这些新平台上使用CASE。