models - 为什么 CASE 工具没有成功？

Question

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

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

谢谢！

Answer 1

首先，我认为图表在小而简单时提供真正的价值。大型、高度详细的图表通常会浪费大量纸张、时间、硬盘空间等。铅笔和纸对于足够小（且足够简单）有用的图表来说效果很好。软件工具仅在您制作的图表如此庞大和复杂以至于几乎可以保证毫无用处时才有帮助。

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

当您深入了解它时，无论如何，我很少看到 CASE 工具被用作“软件工程”的实际“辅助工具”。在我见过的大多数情况下，软件工程是完全独立完成的，并且 CASE 工具用于从已经编写的代码中对图表进行逆向工程。制作图表的人通常认为它们毫无用处，并将它们包含在上级经理的报告中，以获得“令人惊叹的因素”。他们希望从图表中获得的唯一“帮助”是让管理层对他们正在做的事情的复杂性留下深刻印象，以期增加资金（有些包括标准库部分的图表，纯粹是为了增加明显的复杂性）。

至于这些工具是如何在软件工程部分失败的，我不知道一个简单的答案——据我所见，我会说这更像是“千刀万剐”，而不是任何一个，突出的问题。如果我必须指出一个大问题，那就是我看过的那些并没有真正考虑到模式。举个例子，我想要在更高的抽象层次上工作，这样我就可以指向一些功能，并玩弄诸如“如果我要实现该功能的以下部分，事情会是什么样子装饰师课程？” 是的，我可以用它们作为装饰器类绘制一个图，而没有它们，但我没有一种非常快速、简单的方法来说“将整个层次结构转换为将 X、Y 和 Z 移动到装饰器类。

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

Answer 2

如果您查看 Wikipedia 条目：http ://en.wikipedia.org/wiki/Computer-aided_software_engineering ，您将看到 1990 年代的“经典”工具。在使用过许多这些工具后，我建议将重点放在商业化上，从而分散了市场。通常，您不仅要为工具支付巨额费用，还要为咨询、培训和运行时环境支付巨额费用。提供如此多的工具，很难建立一个专门研究给定工具的称职团队。

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

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

在您在 CASE 工具上花费大量精力之前，请先了解一下 MDA、MDE、DSL 甚至 UML 领域。它也值得浏览 OMG 网站。

归根结底，您应该专注于您生产的产品，而不是工具。如果您能够自动执行某些任务，那就太好了。构建另一个类似 CASE 的工具是一项很棒的智力练习，但商业成功的机会很小。毕竟，IBM、甲骨文和 Computer Associates 在他们的工具上只取得了零星的成功，他们仍在大力向企业客户推销这些工具。

Answer 3

早在 90 年代初，我就与 Knowldegeware 合作过。我对 CASE 消亡的简单回答是，一旦你打印了模型，它就已经过时了。保持模型和代码同步变得不可能。第一个目标平台是 MicroFocus COBOL，然后是客户端-服务器 94-95，其次是互联网 97-98，没有人真正想在这些新平台上使用 CASE。