为什么我们不能更有效地捕获软件设计？[关闭]

作为工程师，我们所有人都“设计”人工制品（建筑物，程序，电路，分子...）。那是一个活动（动词设计），产生某种结果（动词设计）。

我认为我们都同意，名词设计与工件本身是不同的实体。

软件业务（实际上，在任何需要增强生成的产品工件的业务中）的关键活动是了解“设计（名词）”。但是，作为一个社区，我们似乎在记录它方面完全失败了，这可以从人们重新发现有关其代码基础的事实的大量努力中得到证明。让某人向您展示他们的代码设计，然后看看您得到了什么。

我认为软件设计具有以下特点：

• 一个明确的规范，说明该软件应该做什么以及其性能如何
• 代码的显式版本（这部分很简单，每个人都拥有）
• 关于代码的每个部分如何用于实现规范的说明（例如，规范片段和代码片段之间的关系）
• 一个理由，为什么代码是事情是这样的（例如，为什么一个特定的选择，而不是另一个）

不是设计就是代码的特定视角。例如，[不特别说明] UML图不是设计。相反，它们是可以从代码派生的属性，或者可以说是希望从代码派生的属性。但是作为一般规则，您不能从UML派生代码。

为什么经过50多年的软件构建，为什么我们没有常规的方法来表达这一点？（请通过明确的示例与我自相矛盾！）

即使我们这样做，大多数社区似乎都非常关注于获取“代码”，以至于无论如何都会迷失于设计中。（恕我直言，直到设计成为工程的目的，从设计中提取出工件之后，我们才可以解决这个问题）。

您认为什么是记录设计的方式（就我所描述的而言）？明确引用论文会很好。为什么您认为特定的和一般的方法没有成功？我们该如何改变呢？

[我有自己的想法，这些使上面的项目符号观点更加充实，但是我对其他人的回答很感兴趣……而且很难实施我的方案[[也许这是真正的问题：-]]]

EDIT 2011/1/3：一个回答线程暗示“文档”（大概是文本的，尤其是非正式的）可能就足够了。我想我应该澄清一下，我不相信这一点。CASE工具从80年代开始出现，但是早期的工具大多只是捕获所绘制图形的像素。尽管这些工具在商业上取得了一定的成功，但实际上并没有太大帮助。一个关键的见解是，如果附加的“设计”工件无法正式解释，那么您将无法获得任何认真的工具帮助。我认为，同样的见解适用于任何长期有用的设计捕获形式：如果没有正式的结构，它将不会有任何实际用途。文本文档几乎无法通过此测试。

我认为有几个原因导致我们仍然不擅长此事。

1. 长期以来，人们虽然像房子一样使用软件，但是他们正在使用建筑过程和流程。“软件架构师”是所有程序员都想要的标题。在过去的十年中，软件架构师几乎破产了。瀑布式流程的想法是，首先让架构师说出软件的工作方式和外观，然后让人们绘制如何构造软件的图，最后让代码猴子按照规范来实现这些漂亮的工作流/ UML图。现在被广泛嘲笑。因此，事实上，整个行业都在走错路40年。

2. 我们使用的工具不断变化和完善。编程是一个逻辑难题，我们提出了更好的想法和技术来抽象该难题并使之易于理解。我们建模的方式必须以相同的速度发展，但它落后了。改进的技术可以抽象出编程难题，这也意味着我们可以增加复杂性。因此，我们做到了。编程始终处于程序员所能处理的复杂性的边缘。

3. 描述程序的方式是一种抽象。如果我们能提出一种抽象软件的好方法，那么我们也可以将该抽象直接添加到开发工具中，从而为编程添加另一个抽象/简化。这已经发生过很多次了。这种抽象的例子是函数，类和库。

4. 因此; 如果您拥有成功且准确的软件模型，则该模型将等同于该软件。哪一种方式使整个工作毫无意义，这又反过来证明了以上第1点：对软件进行建模比以前认为的要有用得多。相反，最好从代码中提取有关软件的数据。从代码的实际外观创建UML模型比创建UML模型并尝试实现该理论模型更具启发性。

您可能对审查软件可追溯性文献感兴趣。没有特别的顺序：

• CUBRANIC，D.，MURPHY，GC，SINGER，J。和BOOTH KELLOGG，S。Hipikat：用于软件开发的项目存储器。软件工程学报31，6（2005），446–65。
• TANG，A.，BABAR，MA，GORTON，I.和HAN，J.对建筑设计原理的使用和文献的调查。参加第五届IEEE / IFIP软件体系结构工作会议（2005年）。
• RAMESH，B.，POWERS，T.，STUBBS，C.和EDWARDS，M.实施需求可追溯性：一个案例研究。在国际需求工程学研讨会论文集（约克，1995年）中。
• HORNER，J。和ATWOOD，ME设计原理：原理和障碍。在第4届北欧人机交互会议：变化的角色（挪威，奥斯陆，2006年）中。
• CLELAND-HUANG，J.，SETTIMI，R.，ROMANOVA，E.，BERENBACH，B。和CLARK，S。自动跟踪的最佳实践。计算机40，6（2007年6月），27-35。
• ASUNCION，H.，FRANÇOIS，F。和TAYLOR，RN一个端到端的工业软件可追溯性工具。在欧洲软件工程师学会和ACM SIGSOFT国际软件工程基础（ESEC / FSE）第六次联席会议上进行的研究（杜布罗夫尼克，2007年）。

请注意，这只是冰山一角，我确定我已经遗漏了一些关键文件。

另外，我自己在Arcum上所做的工作是程序员向IDE表达横切设计习惯用法的一种方式。一旦表达出来，程序员就可以转换其源代码以使用替代实现：

• Macneil Shonle，William G. Griswold和Sorin Lerner。重构之外：横切设计习惯用法的模块化维护框架。在欧洲软件工程大会第六次联席会议和ACM SIGSOFT软件工程基础研讨会上的论文集（ESEC-FSE '07； 2007年9月3日至7日）。175-184。

顺便说一句，Arcum也与您的DMS工作有关。

在我的humbe观点中，UML对程序而言是计划，对建筑物而言。单独的计划并不是计划之外的设计，您需要为此提供材料规格（使用的代码工具），建筑物的一般视图（整个软件的一些示意图，包括GUI设计），建筑物如何在周围环境中种植（有关软件如何与他人交互/植入OS的清晰方案），软件如何适应气候和土壤（与硬件交互），……许多设计书籍都试图对其进行定义，但与此同时在科学很多事情上，每个科学家都有自己的定义。

现在，我也不同意您的意见，即您不能从UML派生代码。如果您有提及的其他信息，则可以。但是真正的代码不再是设计，​​而是工件。您也不能从计划中提取真实的石头和混凝土，但是您需要计划将真实的石头和混凝土放置在正确的形式和正确的位置。

有鉴于此，我发现下面的文章很有趣（当我在寻找图形软件时，我是在不同的背景下遇到的，但是……）。用图形方法描述设计对我来说很有意义，尽管-再说一次-这在我看来只是设计的一部分。有趣的是，这种方法为理解和重构设计（而不是重构软件）提供了一个框架，如以下论文所述：

• 韦默林格和菲亚迪罗

• Tsantalis等

还有很多其他方法可以描述设计（的一部分），例如结构化设计（HIPO图表）或集成程序设计，设计模式，...

但是，只要没有制定行业标准，就不可能采用“常规”的方式来表达这一点。即使超过50年。老实说，如果您的公司找到表达设计的好方法，您是否会与世界分享？

根据我个人的经验，我认为我们很好地掌握了软件的设计。对于我们在平台上实现的每个功能，我们都有一个需求和设计文档数据库。我想我的情况也许很独特。这是一些需要考虑的事情。

我们团队中的每个人都具有工程学学位...主要是EE或CE。工程学将设计作为课程的一部分。

我认为有很多来自CS背景的所谓软件工程师。软件设计不是大多数CS程序的组成部分。我并不是说所有CS专业的学生都不擅长设计，但我敢打赌，大多数人没有接受过正规的教育。我认为很多人都认为，如果您可以编程就可以设计软件，那是不对的。鉴于许多程序员没有工程背景，因此许多软件项目没有一支擅长捕获设计的团队也就不足为奇了。

我看到两个问题。

首先是保持代码和文档同步是很困难的。如果它们是分开的，它们将有所不同，并且文档将变得无用。程序员尝试使用工具来使它们保持同步（例如CASE-tools），但是这些工具介于程序员和他们的代码之间，造成的伤害大于好处。领域驱动设计的关键见解之一（Evans，2004年）是，好的设计确实很难，因此，要想从中获得一些收益，您必须：

• 选择程序的最小区域，即良好的设计将带来巨大的收益，即所谓的核心领域
• 努力工作，以一种所有团队成员一直使用的通用语言的形式来获得良好的设计
• 尽可能使设计成为代码的一部分

设计方法的另一个大问题是我们的设计方法不够数学。渗漏的抽象无法从中得出可靠的结论，严格应用逻辑和清晰真理的世界被称为数学，程序员通常会回避。

我们拥有的一些数学工具（例如形式方法）非常笨拙。

Map-reduce是编程中数学的一个很好的例子。核心思想是：当您进行关联的二进制操作时，可以非常轻松地分配其执行。二进制运算是具有两个参数的函数，关联性表示（a + b）+ c = a +（b + c）

a1 + a2 + ... + a99 + b1 + b2 + ... + b99 + c1 + c2 + ... + c99是

（a1 + a2 + ... + a99）+（b1 + b2 + ... + b99）+（c1 + c2 + ... + c99）其中As，Bs和Cs可以简单地添加到不同的位置，收集结果并立即总结。

Map-reduce是一个非常简单的想法。可以在一张纸上描述。如果您可以假设读者对关联性的概念有牢固的掌握，那么请放到很小的纸上。现在，尝试在不使用术语“关联性”或间接引用术语的情况下向某人解释map-reduce。我赌你。

没有数学抽象的软件设计就像试图做架构而又不用费心学习几何。

也许Haskell可以逐步解决此问题。对我来说，使用范畴论中的概念来描述程序似乎很有希望。类别理论是如此抽象，以至于数学家都很少使用它，但是显然，类别超出了人们的认识，似乎足够抽象，可以描述软件的结构。我们会找出答案的。慢慢来