我上周与同事就建筑（真实建筑，如设计建筑）进行了对话。在我们的演讲中，我们发现建筑蓝图为建筑师，土木工程师和承包商提供了构建某些东西所需的所有细节。它让我们俩都在考虑软件工程的状态，并且没有普遍采用的方法来描述软件的设计。
我们有UML，但我发现如果没有图表过于复杂，通常很难传达足够的细节。是否有使用复杂的UML图设计的大型软件的好例子？
然后，有一大堆软件蓝图甚至有用吗？毕竟重构和重建软件比重建摩天大楼要便宜得多。建筑蓝图对于软件设计来说是错误的类比吗？你能想到更好的比喻吗？
答案 0 :(得分：6)
我认为您无法将软件架构与真实架构进行比较。当你建造房屋时，你必须提前计划好所有事情，而且你也可以 提前计划好所有事情。
最近我读到，软件工程更像园艺，而不是真正的架构。我认为这种比较更接近现实：你不知道什么会有效，什么不会成功;你必须重做那些理论上看起来很好但事实证明是不切实际的事情，你可以在你的花园/软件变得更加完善时不断改进你的计划。
总结：软件蓝图不应该与构建房屋的蓝图具有相同的详细程度，因为通常情况下，您发现您根本无法坚持原始计划。
答案 1 :(得分：2)
我认为设计软件比蓝图更接近Mad-Libs
答案 2 :(得分：2)
建筑蓝图几乎是实际房屋的精确表示。它们通常不是符合房屋应该外观的模型的抽象，它们代表房屋将如何。
与UML / Flowcharts / Rational Rose /月度方法论相比，这些是模型。它们抽象出实现细节，并且推测给定模型（Say，OO）是软件的应用方式，而在 reality 中，软件总是打破那些抽象，因为模型不是一个好的表现。
从某种意义上说，这涉及到解释力和可计算性的问题：房屋蓝图是一个固定的表达，具有固定的表达式和固定的输入;而软件蓝图必须考虑可变输入，甚至可能是无限长度。允许插件或其他“计算”搭售的软件现在具有嵌入其中的图灵机操作员，这导致主机具有不可预测性。因此，软件 vis-a-vis 房屋的输入空间在数学上更大，这意味着代表性技术必须相应地在计算上更强大。这就是UML et al。落空的地方 - 它们与真实软件并不是同态的。
答案 3 :(得分：1)
Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools中提出的一个论点是UML是不够的。即使增加了限制，仍然不清楚。除其他外，它没有充分表达作者的意图，即可以可靠地生成好的代码。
答案 4 :(得分：1)
UML很好，但是大致绘制的白板图的照片在实践中同样好或更好（在时间/成本意义上）
所以更像是在攻击之前在沙子中制定策略，在大多数情况下这种态度似乎更好。
除了一半的时间，UML被一些有很多想象力并且没有投入实际实施的人所吸引。
答案 5 :(得分：1)
对于像DoD和FAA武器和传感器系统这样的大型，计算密集，寿命长，安全关键的软件系统，蓝图对于长期成功至关重要。 （嗯，这是一个满口的:)）没有这些庞然大物，维护者，甚至原始开发人员的一套蓝图，当他们试图找到/修复错误或添加主要功能时，将遇到困扰和挫折。没有蓝图，纳入变化，甚至是小变革，都将成为一种高风险的游戏，失败可能意味着下游的生命损失。
话虽如此，UML和它的后代SysML（现在）是城里唯一的游戏。建模和抽象是对抗模糊性和复杂性的重要工具，它们在未来将变得更加重要。他们越早被想要成长的人所接受，就越好。
Thanx倾听。
答案 6 :(得分：1)
我刚刚完成了一个成功的C＃/ Sql Server项目，我使用UML图来充实应用程序设计。该UML图避免了对应用程序的设计和不执行操作的任何误解。列出了所有类关系以及类删除规则（复合，聚合，无）。除了一些易于理解的状态图和一些OCL（对象约束语言）之外，与利益相关者讨论应用程序应该如何工作也是一件轻而易举的事。 UML和OCL抽象出了我能够避免的大量普通和低级编程。 UML和OCL非常简单，用户可以理解幕后发生的事情。当我的用户询问如何计算时，我只是将它们引用到UML和OCL。什么可以更容易？所以，是的，恕我直言UML非常适合制作软件蓝图。关于采用域驱动开发，有一些话要说。
答案 7 :(得分：0)
Text + Diagrams的组合通常是解释您的架构如何工作的最佳方式。 Rational Rose只能让你到目前为止。
答案 8 :(得分：0)
我认为任何比喻都只会延伸到目前为止。您将获得将编程的某些方面与建筑房屋相比较的价值，以及将不同方面与园艺/下棋/阅读字典进行比较，同时站在您的头上......
我认为在构建时更容易指定特定项目需要什么级别的详细信息，因为有一些普遍接受的实践，已经存在一段时间，用于管理建筑项目。
也许在50年的时间里，如果每个人都采用一种方法论，我们的行业就会发生类似的事情。
答案 9 :(得分：0)
根据我的经验，uml是垃圾。
通过使用TDD可以获得更多，更多的乐趣......通过跳入和编写测试用例并查看对象如何交互。
UML设计很糟糕。我是一名程序员，而不是数据录入类型的人。
在TDD之前，我使用随机纸张勾勒出基本实体和关系，然后直接跳到编码中。
我认为这些工具并不常用，而且它们的受欢迎程度正在下降。
答案 10 :(得分：0)
我会说UML是有限的。是的，您可以表示基本关系，但是当您考虑交互和约束时（即使使用OCL），您仍然没有得到多少
答案 11 :(得分：0)
如果您想为软件团队“提供他们构建某些东西所需的所有细节”，那么请将您的精力投入到需求分析中并创建一个固定的功能规范。这将包含客户想要的每个功能的描述。如果这些描述包含UML图表那么一切都很好 - 在很多情况下，UML是比英语/法语/德语/描述软件更好的语言 - 但是不要为了它而创建UML图表。 Joel on Software有一系列关于如何编写功能规范的专题文章，值得一读 - 从这里开始：http://www.joelonsoftware.com/articles/fog0000000036.html。