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