......或者他们为什么失败？
我将建立一个可归类为CASE的概念证明，但我想避免以前做过的一些错误。
谢谢！
首先，我认为图表在小而简单时提供了真正的价值。大而高度详细的图表大多浪费了大量的纸张，时间，硬盘空间等。铅笔和纸张非常适用于足够小（并且足够简单）有用的图表。一个软件工具只有在你生成一个如此庞大和复杂的图表时才有用，它实际上保证是无用的。
其次，对于大多数CASE工具，绘制图表的最快方法是首先编写一些（可能是简化的，模型化的）代码，然后从代码中“反向工程”图表。直接绘制图表通常比编写代码慢。为了提供更多真正的价值，生成高级图表必须比编写等效代码简单得多。
当你深入了解它时，我很少看到CASE工具被用作“软件工程”的实际“辅助”。在我看到的大多数情况下，软件工程完全是分开完成的，CASE工具用于从已编写的代码中反向工程图。制作图表的人通常认为它们毫无用处，并将它们包含在报告给高级管理人员的“惊叹因素”中。他们希望从图表中获得的唯一“帮助”给管理层留下了深刻印象，他们正在做的事情很复杂，希望增加资金（有些包括标准库的部分图表，纯粹是为了增加明显的复杂性）。
至于工具如何在软件工程部分失败，我不知道一个简单的答案 - 从我所看到的，我会说它更像是“一千个刻痕的死亡”，而不是任何一个，明显的问题。如果我确实必须指出一个大问题，那就是我所看到的那些问题并没有真正考虑到模式。举个例子，我想要的是在更高的抽象层次上工作，所以我可以指出一些功能，并且玩“如果我要将该功能的以下部分实现为装饰班？“是的，我可以将它们作为装饰器类绘制一个图表，一个没有，但我没有一个非常快速，简单的方法来说明“将整个层次结构转换为将X，Y和Z移动到装饰器类中”。
将典型的CASE工具与电子表格进行对比。在电子表格中，我可以更改一个单元格，它会自动重新计算这会影响依赖于它的电子表格中的任何其他内容。相比之下，CASE工具似乎（至少对我来说）大致停留在网格控件的水平，我可以在一个单元格中进行更改，但我仍然需要手动跟踪其他单元格依赖于哪一个，以及哪些公式为手动使用，计算和修改所有受影响的细胞。是的，如果我想要打印出一张正确的值，能够在计算机上编辑它们，这样我在单元格中就没有橡皮擦标记，这样会有所改进 - 但只是一个小的改进，而不是将个人计算机从玩具转变为少数几个业余爱好者，成为地球上每个企业的主要产品。
如果你看一下维基百科条目：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只是在他们的工具上取得了零星的成功，他们仍在大力向企业客户推销它们。
我在90年代初期与Knowldegeware合作过。我对CASE消亡的简单回答是，一旦你打印出模型，它就会变老。保持模型和代码同步变得不可能。第一个目标平台是MicroFocus COBOL，然后是Client-Server 94-95，然后是因特网97-98，没有人真的想在这些新平台上使用CASE。