为什么我们不能更有效地捕获软件设计？[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 作为工程师，我们所有人都“设计”人工制品（建筑物，程序，电路，分子...）。那是一个活动（动词设计），产生某种结果（动词设计）。 我认为我们都同意，名词设计与工件本身是不同的实体。 软件业务（实际上，在任何需要增强生成的产品工件的业务中）的关键活动是了解“设计（名词）”。但是，作为一个社区，我们似乎在记录它方面完全失败了，这可以从人们重新发现有关其代码基础的事实的大量努力中得到证明。让某人向您展示他们的代码设计，然后看看您得到了什么。 我认为软件设计具有以下特点： 一个明确的规范，说明该软件应该做什么以及其性能如何 代码的显式版本（这部分很简单，每个人都拥有） 关于代码的每个部分如何用于实现规范的说明（例如，规范片段和代码片段之间的关系） 一个理由，为什么代码是事情是这样的（例如，为什么一个特定的选择，而不是另一个） 不是设计就是代码的特定视角。例如，[不特别说明] UML图不是设计。相反，它们是可以从代码派生的属性，或者可以说是希望从代码派生的属性。但是作为一般规则，您不能从UML派生代码。 为什么经过50多年的软件构建，为什么我们没有常规的方法来表达这一点？（请通过明确的示例与我自相矛盾！） 即使我们这样做，大多数社区似乎都非常关注于获取“代码”，以至于无论如何都会迷失于设计中。（恕我直言，直到设计成为工程的目的，从设计中提取出工件之后，我们才可以解决这个问题）。 您认为什么是记录设计的方式（就我所描述的而言）？明确引用论文会很好。为什么您认为特定的和一般的方法没有成功？我们该如何改变呢？ [我有自己的想法，这些使上面的项目符号观点更加充实，但是我对其他人的回答很感兴趣……而且很难实施我的方案[[也许这是真正的问题：-]]] EDIT 2011/1/3：一个回答线程暗示“文档”（大概是文本的，尤其是非正式的）可能就足够了。我想我应该澄清一下，我不相信这一点。CASE工具从80年代开始出现，但是早期的工具大多只是捕获所绘制图形的像素。尽管这些工具在商业上取得了一定的成功，但实际上并没有太大帮助。一个关键的见解是，如果附加的“设计”工件无法正式解释，那么您将无法获得任何认真的工具帮助。我认为，同样的见解适用于任何长期有用的设计捕获形式：如果没有正式的结构，它将不会有任何实际用途。文本文档几乎无法通过此测试。