UML与白板

当我们进行设计/白板会议时，我试图生成正确的UML，但我对结构良好的UML的尝试总是退化为UML外观，但对那些在房间里的人来说是可以理解的，并且有一点解释。但这对完美的工程师来说足够好吗？您是否总是在白板会话中生成结构良好的UML？你有什么建议给那些可能认为它不那么重要的开发人员，以免他在设计模式书中看到它，而不知道wtf正在进行

我在设计过程中从不使用UML。它总是自由形式的。然后，根据项目的不同，在创建“最终”规范文档时，我们将返回并将其转换为更加结构化的UML设计，我们开发人员将从中编写代码。根据我的经验，关注正确的形式往往会妨碍设计会议，特别是当房间里有一半或更多的人不知道任何图表的含义时。

嗯，我真的认为你不需要严格的UML

只要每个人都理解这个设计并承认它是可以的。我更喜欢一种敏捷的方法，能够在运行中对项目进行原型化/测试，并且能够更改“非严格”的规范，而不是让一切从零开始就决定下来，不可触及

---

在现实世界中，即使使用最精心规划的UML规范，您也会感到惊讶。您可以看到，关于软件工程有很多争论，我们是否需要它，事实上它取决于您正在开发的系统类型。系统的需求越模糊，就越需要SE工具和技术

UML帮助客户机了解内部系统。这是您拥有用例图的时候。确实有些人不明白，但是特别解释用例图是非常容易的。然后是类图，它可以帮助您掌握需要设计的第一个主要类和包。其他UML图则没有那么重要

以下是一个简单的网站，可帮助您在线几秒钟内创建类digram和用例digram：

---

我从来没有在没有使用这两个图的情况下完成过中/大型项目

为什么它总是退化？这是因为一些参与者缺乏理解或UML经验吗？如果你的UML知识比他们的多；我会坚持这条路线，目标是生成好的UML，将每一次设计会议都视为指导知识较少的人的机会。白板让你有机会无情地重构设计，使用它。我很幸运让另一个人理解类图之外的任何东西……我发现使用UML作为指导方针有助于避免架构中的“大惊喜”，即使是在小组件和子系统上。。。然而，我也是原型和微调的爱好者，所以我做了很多代码到类图的逆向工程，然后将它们作为规范的一部分发布。。。。