上周我与一位同事就建筑（真正的建筑，如设计建筑）进行了交谈。在我们的谈话中，建筑蓝图为建筑师、土木工程师和承包商提供了建造某物所需的所有细节。它让我们俩都思考了软件工程的现状，并且没有普遍采用的方法来描述软件的设计。
我们有 UML，但我发现通常很难在不过于复杂的图表的情况下传达足够的细节。是否有使用精心设计的 UML 图设计的大型软件的好例子？
话又说回来，拥有大量的软件蓝图有用吗？毕竟重构和重建软件比重建摩天大楼要便宜得多。架构蓝图是软件设计的错误类比吗？你能想到更好的类比吗？
问问题
1603 次
12 回答
6
我认为您无法将软件架构与真实架构进行比较。当你建造房子时，你必须提前计划好所有的事情，更重要的是你还可以提前计划几乎所有的事情。
最近我读到软件工程更类似于园艺而不是真正的建筑。我认为这种比较更接近现实：你不知道什么会成功，什么不会；您必须修改理论上看起来不错但被证明不切实际的事情，并且您可以在您的花园/软件变得更加完整的同时不断改进您的计划。
总而言之：软件蓝图的详细程度不应与建造房屋的蓝图相同，因为您经常会发现您根本无法坚持最初的计划。
于 2009-04-22T12:10:37.230 回答
2
我会说设计软件比蓝图更接近 Mad-Libs
于 2009-04-22T12:19:31.670 回答
2
建筑蓝图是实际房屋的近乎精确的表示。它们通常不是符合房屋外观模型的抽象，它们是房屋外观的代表。
与 UML/流程图/Rational Rose/每月方法论进行对比——这些都是模型。他们抽象出实现细节，并假设给定的模型（比如，OO）是软件应该是的样子，而实际上，软件总是打破这些抽象，因为模型不是一个好的表示。
从某种意义上说，这与解释力和可计算性有关：房屋蓝图是具有固定表达和固定输入的固定表示；而软件蓝图必须考虑可变输入，甚至可能是无限长度。允许插件或其他“计算”连接的软件现在具有相当于嵌入其中的图灵机操作员，这导致了许多不可预测性。因此，软件相对于房屋的输入空间在数学上更大，这意味着表示技术必须相应地在计算上更强大。这就是 UML等人的地方。跌倒 - 它们与真实软件不是同态的。
于 2009-04-22T12:57:26.290 回答
1
在Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools中提出的论点之一是 UML 是不够的。即使添加了约束，仍然不清楚。除此之外，它并没有充分表达作者的意图，以至于可以可靠地生成好的代码。
于 2009-04-22T12:20:28.983 回答
1
UML 很好，但粗略绘制的白板图照片在实践中同样好或更好（在时间/成本方面）
所以这更像是在发动攻击之前在沙地上制定策略，这种态度在大多数情况下似乎更有效。
除了一半的时间 UML 是由一些有很多想象力的人绘制的，并且在实际实施中没有投资。
于 2009-04-22T12:21:51.027 回答
1
对于大型、计算密集、寿命长、对安全至关重要的软件系统，如 DoD 和 FAA 武器和传感器系统，蓝图对于长期成功至关重要。（呸，真是拗口 :)）如果没有为这些庞然大物制定一套蓝图，维护者，甚至是最初的开发者，当他们试图定位/修复错误或添加主要功能时，都会感到痛苦和沮丧。如果没有蓝图，整合变化，即使是很小的变化，都将成为一场高风险的游戏，失败可能意味着下游的生命损失。
话虽如此，UML 和它的后代 SysML，是（现在）城里唯一的游戏。建模和抽象是对抗模糊性和复杂性的重要工具，它们在未来将变得更加重要。他们越早被想要成长的人所接受，越好。
感谢聆听。
于 2009-04-22T13:03:07.540 回答
1
我刚刚完成了一个成功的 C#/Sql Server 项目，我使用 UML 图充实了应用程序设计。该 UML 图避免了对应用程序设计做什么和不做什么的任何误解。所有的类关系以及类删除规则（复合、聚合、无）都被详细说明。除了几个易于理解的状态图和一些 OCL（对象约束语言）之外，与利益相关者讨论应用程序应该如何工作是一件轻而易举的事。UML 和 OCL 抽象出大量我能够避免的平凡和低级编程。UML 和 OCL 非常简单，用户可以理解幕后发生的事情。当我的用户询问计算是如何得出的时，我只是将他们引向 UML 和 OCL。还有什么比这更容易的？所以，是的，恕我直言 UML 非常适合制作软件蓝图。关于采用领域驱动开发有一些话要说。
于 2009-10-09T23:55:31.947 回答
0
文本+图表的组合通常是解释您的架构如何工作的最佳方式。Rational Rose 只能让你走这么远。
于 2009-04-22T12:23:25.827 回答
0
我认为任何比喻都只会延伸到此为止。将编程的某些方面与建造房屋进行比较，以及将不同方面与园艺/下棋/读字典进行比较，您将获得价值……
我认为在建筑中指定特定项目所需的详细程度更容易，因为管理建筑项目已经存在一段时间的普遍接受的做法。
也许在 50 年后，如果每个人都确定一种方法论，我们的行业也会发生类似的事情。
于 2009-04-22T12:42:58.760 回答
0
以我的经验，uml 是垃圾。
您可以通过使用 TDD 获得更多，并获得 10000 倍的乐趣……通过参与并编写测试用例并查看对象如何交互。
UML 设计简直糟透了。我是编码员，不是数据输入类型的人。
在 TDD 之前，我用随机的纸片勾勒出基本的实体和关系，然后直接开始编码。
我没有看到这些工具被普遍使用，而且它们的受欢迎程度正在下降。
于 2009-04-22T13:07:08.857 回答
0
我会说UML是有限的。是的，您可以表示基本的关系，但是当您考虑交互和约束（即使使用 OCL）时，您仍然没有得到太多
于 2009-04-22T13:34:48.137 回答
0
如果您想为软件团队提供“他们构建某些东西所需的所有细节”，那么就将您的精力投入到需求分析中并创建一个明确的功能规范。这将包含客户想要的每个功能的描述。如果这些描述包括 UML 图，那么一切都很好——在许多情况下，UML 是一种比英语/法语/德语/任何用于描述软件的语言更好的语言——但不要为了它而挂在创建 UML 图上。Joel on Software 有一系列关于如何编写功能规范的专题文章，它们非常值得一读 - 从这里开始：http: //www.joelonsoftware.com/articles/fog0000000036.html。
于 2009-04-22T23:07:28.057 回答