几年前，我们店里的每个人都疯狂地使用UML 。现在每个人似乎已经冷静下来了。
如果在软件项目中仍然广泛使用UML，我很好奇。
如果是这样，这种用法仅限于白板吗？你用它来做文件吗？您是否使用工具从中生成代码？
答案 0 :(得分：23)
我更喜欢敏捷采用UML（例如白板草图）而不是UML的瀑布改编（例如，在Visio中绘制的精细图表的过多文档）。
UML对于向其他人解释设计仍然很有用。例如。复合设计模式很容易用简单的类图解释（也就是说，在你完成那些有趣的类比之后）。
一些手绘的类和序列图可以方便地在面对一个新的或旧的项目时快速启动，这个项目遍布各处且没有足够的文档。
我的团队也成功使用类图生成数据库模式。也许有更好的方法，但这是另一个问题。
答案 1 :(得分：10)
我一直使用UML（或UML ispired）图形作为支持文档。这些文件提供了时间片，例如“这是我们用户的原始概念”。保持文档最新是很困难的，只有在我们需要更改我们的定义时才会这样做。然后我们又拍了一张快照。 UML不是设计，而是设计过程的一部分。
我使用了一些使用UML但只生成初始存根的代码生成工具。通常一旦代码生成，它就会从图中单独发展。
UML的一个问题是，在许多情况下，争论爆发了关于正确的UML语法/风格，而不是集中在绘图是否帮助客户，分析师或开发人员理解这个概念。我知道语法在代码生成时很重要，但我发现UML最适合理解一个概念。
答案 2 :(得分：9)
有关该主题的更多回复，请参阅SO: Is UML practical?。似乎UML对于传达概念和系统仍然有用。人们似乎将它用作描述，而不是定义。如果将UML与实现本身分开，则会遇到阻碍两者保持同步的问题。
答案 3 :(得分：8)
我使用UML进行初始设计，并在与其他开发人员交谈时帮助讨论。但是，除了初始设计之外，尝试使UML保持最新所花费的时间并不值得付出努力。
答案 4 :(得分：4)
我已经看到生成的UML用于帮助新员工处理一个非常复杂的系统。由于UML是从代码自动生成的，所以它始终是最新的，有些人发现它很有帮助。
答案 5 :(得分：4)
UML死了，死了，死了：Is UML Really Dead, Or Only Cataleptic?
白板/文档是可以的。从中生成代码？谁需要那个以及为了什么？
答案 6 :(得分：3)
我实际上使用UML帮助我想象并思考问题。为此，序列图，活动图和对象图非常有用。
当您尝试与软件层进行通信时，组件图很有用。
部署图对于确定打包和部署以及节点间通信路径非常有用。
类图我觉得最不实用，因为大多数IDE都可以很容易地为你提供竣工的类层次结构。
答案 7 :(得分：2)
我在与其他开发人员的讨论中使用UML。我经常认为自己通过图片向其他人传递信息更为成功，所以当与团队的其他成员进行头脑风暴时，我会在白板上绘制一个类图或活动图。其他成员可以绘制和修改它，一旦我们都知道我们在谈论什么，我们倾向于使用它。我们没有直接从它生成代码（部分因为我们的工具很糟糕），但另一方面，如果我们这样做，我们可能会感到更加受限制。自白板以来，这些设计改变了很多......
答案 8 :(得分：1)
如果你使用敏捷，你应该使用UML。
建模很重要。如果编写代码当然更有趣，但是你浪费了很多时间，并且不知道你是否正在考虑客户的要求。您可以通过模型了解要求解决的问题，加快开发时间，并将有用的产品发送给客户。
为价格过高的Monster电缆节省镀金。
答案 9 :(得分：1)
我们仍然使用UML。和其他人一样，我发现他们非常有助于沟通。人们在有视觉辅助工具时进行沟通会更容易（输入PowerPoint的受欢迎程度）。在项目的初始阶段尤其如此，其中firebird84解释的场景发生了很多。一旦项目开发人员开始编码，UML的艰辛之处就是维护图表。
我们不会生成代码，但我还没有亲自与那些使用过UML的人交谈过。
答案 10 :(得分：1)
我每天都使用类图来讨论模型，包括对象和模式。这确实会让DBA失效，直到你指出你可以通过将所有箭头滑动到行的另一端来从类图中派生出一个ERD ......箭头仍然指向同一个方向。在那里，现在它描绘了一个FK。
两种类型的图表之间存在大量不同的结构和语义细节，但箭头转换似乎清除了心理障碍。
答案 11 :(得分：1)
Together / J是一个很好的参考点，因为没有努力生成UML，它就在你的Java代码旁边。有趣的是看看我是否在“免费”时使用了UML。
我觉得它有用吗？说实话，我发现它作为一个额外的视觉保证和交叉检查是有用的，我所做的设计 正在形成，并作为一个视觉编目工具。我没有考虑基于图表的特定逻辑或模式。好吧，也许有时候我做了。
物有所值吗？这让我对这个过程感觉良好。其他人看起来令人印象深刻考虑到我正在进行的事情的清单，它刮了一会儿。它让我更多地考虑整洁和简洁，每个对象占据屏幕空间的东西。这让我觉得我真的需要这个属性还是可以让它更整洁？它确实偶尔帮助我“用UML思考”。
有了额外的经验，我现在会使用Together / J吗？我现在可以花时间从头开始构建UML吗？
当我看到我实际为项目做的事情时，它包括编写UI设计，数据库模式和通信协议，考虑用例和内存使用，带宽使用和安全性。事实上，除了面向对象/ UML之外，几乎所有事情都可以考虑。而且我不使用Together / J.
为什么会这样？
因为我现在已经将我的学习内容化为UML。我现在专注于实现设计的速度，空间和时间效率。我的设计受到UML原则的高度约束，因此值得学习所有这些东西，但我不会使用实际的纸质UML图表或者再用UML思考。
刚刚假设UML;给定的。或者说它对设计的影响是。
我现在在屏幕上看到的是纯粹的代码和数据。我也有成就感。 ： - ）
答案 12 :(得分：1)
取决于您正在绘制的内容的受众和目的（假设您使用UML作为可视化建模语言而不是其不常见的更抽象形式）。
如果您正在与其他工程师沟通控制序列或类层次结构，那么UML图是理想的。
向客户或高级技术经理传达宏应用程序架构，你可能会找到powerpoint，无论你多么吝啬，更有效
请参阅Documenting Software Architectures，了解UML中一些常见的架构视图图表中的弱点。
另一个提示 - 使用文本工具，如优秀的PlantUml - 这是一个非常简单的DSL学习，然后你可以专注于意义而不是强迫Visio绘制直线或挥动巨大的过度工程CASE工具。检查PlantUml模型以获取源代码控制，并设置CI作业以自动构建和发布SVG或PNG。
答案 13 :(得分：0)
我将它用于用例图表。但其他并不多。
答案 14 :(得分：0)
我们仅在项目开始时使用UML类图表进行一些划分，而且在向其他开发人员解释我们自己的代码时也是如此。但这只是一个问题，而不是记录我们的软件。
在我看来，很多人都在谈论UML（人，杂志），但并不是很多人真正使用它。
答案 15 :(得分：0)
我也使用UML进行初始设计。在执行reqs阶段和用例（以UML和文本形式）之后，基本系统被布置为组件图，以识别单个组件，接口以及子系统。
答案 16 :(得分：0)
我已经决定喜欢Fowler在他的书“UML Distilled”中所描述的Cockburn风格的用例。我非常喜欢它们，因此我设计了一种实验方法将它们直接嵌入到C＃命名空间中。
通过这样做，我可以免费使用用例的英语语言内容对业务或UI逻辑进行编码，而无需编写任何类型的域特定语言。最直接的好处是我提高了代码的可读性（以一种非常新的和深奥的方式）。它仍然是一种实验方法。但是，我认为它可能有用。
Here是我在尝试寻找其他方法时所发布的问题的链接。
答案 17 :(得分：0)
我认为传统的UML已经死了。我的意思是静态UML，它花费几个月的需求建模和模型的代码生成。 在开始编码之前，我们不能等待超过一周，因为我们必须更快，更快地交付项目。如果您建模然后生成代码，生成的代码通常非常糟糕，您需要修复它。几年前，我花了更多的时间来修复脏UML生成的代码而不是写一个干净的新代码。
我认为MDD（例如模型驱动的开发）已经死了但不是UML图形表示法。我仍然每天都使用它，它的效果非常好。当我得到新的要求时，我立即将其建模为类图。我首先反转我现有的项目，然后创建新元素并将其与现有代码合并。在我现有项目中创建需求的骨架不超过2个小时。我喜欢使用类图创建我的骨架，因为它为您提供了更高级别的抽象和代码。真的很酷。 我使用Omondo EclipseUML，我是为这个工具而制作的，对其他供应商感到遗憾，但这个工具改变了我的生活。我每天两次将我的项目与离岸团队合并，并重新创建新的图表。这不是自动的，因为我更愿意在接受提交之前检查代码。我检查了编译和对象方法，只有UML可以让我了解已经完成的工作，添加胶水的方式和位置以支持新的要求。 我很高兴，因为我不再使用脏MDD代码生成，但可以专注于UML符号和质量代码。
答案 18 :(得分：0)
我觉得ULM对我没用，这会伤害我的创造力。如果客户需要，我只将UML生成为文档。但我不会用它来模拟类。 架构是一个不断发展的过程，我一遍又一遍地思考，不仅在办公室，我到处都有新的想法。 我不断重构以接近最佳，首先考虑代码。希望你明白我的意思。