在大学里，我参加过许多设计和面向UML的课程，并且我认识到UML可以使软件项目受益，尤其是用例映射，但这真的很实用吗？我已经完成了一些合作工作条款，并且看来UML在行业中并未得到广泛使用。在项目期间创建UML图值得吗？另外，我发现类图通常没有用，因为查看类的头文件只是更快。具体来说，哪些图表最有用？
编辑：我的经验仅限于10个以下的小型开发人员项目。
编辑：许多好的答案，虽然不是最冗长的，但我相信选择的一个是最平衡的。
Answers:
使用UML就像走路时双脚注视。它使您通常可以在不知不觉中完成有意识和明确的事情。初学者需要仔细考虑他们在做什么，但是专业的程序员已经知道他们在做什么。在大多数情况下，编写代码本身比编写代码更快，更有效，因为它们的编程直觉适合于任务。
这不仅关乎您在做什么。从现在开始六个月后需要加快代码编写速度的新员工呢？从现在开始从事该项目的每个人都离开现在的五年后呢？
为以后加入该项目的任何人提供一些基本的最新文档非常有用。我不主张使用带有方法名称和参数的完整的UML图（很难维护），但是我确实认为系统中各组件之间的关系和基本行为的基本图非常宝贵。除非系统的设计发生重大变化，否则即使对实现进行了调整，该信息也不会发生太大变化。
我发现文档编制的关键是审核。没有人会在不睡着几页的情况下阅读50页完整的带有设计文档的UML图。另一方面，大多数人都希望获得5-10页的简单类图，其中包含有关如何实现的基本描述。系统放在一起。
我发现UML有用的另一种情况是，当高级开发人员负责设计组件，然后将设计交给初级开发人员实施时。
使用UML就像走路时双脚注视。它使您通常可以在不知不觉中完成有意识和明确的事情。初学者需要仔细考虑他们在做什么，但是专业的程序员已经知道他们在做什么。在大多数情况下，编写代码本身比编写代码更快，更有效，因为它们的编程直觉适合于任务。
唯一的例外是为什么您晚上没有火把就在树林里，天开始下雨了-那么您需要注视自己的脚以避免跌倒。有时候，您执行的任务比您的直觉所能处理的更为复杂，因此您需要放慢速度，并明确说明程序的结构。然后，UML是可以使用的许多工具之一。其他包括伪代码，高级体系结构图和奇怪的隐喻。
我将通过提及我在大型（类似于IBM）公司开发环境中没有经验来限定我的答案。
我认为UML和方式Rational Unified Process的是，它更TALKING你要去比实际做什么DOING你打算做什么。
（换句话说，这很大程度上是在浪费时间）
仅在我看来，请扔掉。UML是传达思想的绝佳工具，唯一的问题是存储和维护它时，因为实际上是在创建同一信息的两个副本，而这通常是它的作用所在。在第一轮实施之后，大多数UML应该从源代码生成，否则它将很快过时，或者需要很多时间（带有人工错误）来保持最新。
我在学校的最后两个学期共同教了一个高级开发项目课程。该项目旨在与本地非盈利组织作为付费客户一起在生产环境中使用。我们必须确定代码是否达到了预期的效果，并且学生正在捕获满足客户需求所需的所有数据。
上课时间很有限，我在教室以外的时间也很有限。因此，我们必须在每次课程会议上进行代码审查，但是有25名学生注册，个人审查时间非常短。我们在这些复习会中发现最有价值的工具是ERD，类图和序列图。ERD和类图仅在Visual Studio中完成，因此创建它们所需的时间对于学生而言是微不足道的。
这些图非常迅速地传达了很多信息。通过快速了解学生的设计，我们可以快速隔离他们代码中的问题区域，并在现场进行更详细的审查。
如果不使用图表，我们将不得不花时间逐一浏览学生的代码文件以查找问题。
我来这个话题有点晚了，我只会尝试澄清几个小问题。询问UML是否太有用了。从绘图/通讯工具的角度来看，大多数人似乎从典型/流行的UML回答了这个问题。注意：Martin Fowler和其他UML书籍作者认为UML最好仅用于通信。但是，UML还有许多其他用途。最重要的是，UML是一种建模语言，具有映射到逻辑概念的符号和图表。这是UML的一些用法：
鉴于上面的使用列表，Pascal的发布是不够的，因为它仅涉及图表的创建。如果以上任何一项是关键的成功因素或需要标准化解决方案的问题领域，则项目都可以从UML中受益。
讨论应从如何过分销毁UML或将其应用于小型项目展开，以讨论何时应使用UML或将真正改善产品/解决方案，即应何时使用UML。在某些情况下，一个开发人员的UML也可以感知，例如Pattern Application或Code Generation。
UML为我工作了多年。当我刚开始时，我读了Fowler的UML Distilled，他说“做足够的建模/架构/等”。只需使用您所需要的！
我认为UML很有用，因为我认为2.0规范使曾经明确的规范变得有些肿和麻烦。我确实同意时序图等的版本，因为它们填补了空白...
学习有效使用UML需要一些实践。最重要的一点是要进行清晰的沟通，在需要时进行建模，并作为团队进行建模。白板是我发现的最好的工具。我还没有看到任何能够捕获实际白板工具的“数字白板软件”。
话虽这么说，我确实喜欢以下UML工具：
紫罗兰色-如果再简单一点，那将是一张纸
Altova UModel-Java和C＃建模的好工具
MagicDraw-我最喜欢的商业建模工具
Poseidon-体面的工具，具有出色的性价比
UML图对于捕获和传达需求并确保系统满足这些需求很有用。它们可以迭代使用，并且可以在计划，设计，开发和测试的各个阶段使用。
来自主题：在开发过程中使用模型，网址为http://msdn.microsoft.com/zh-cn/library/dd409423%28VS.100%29.aspx
模型可以帮助您可视化系统所处的环境，阐明用户的需求，定义系统的体系结构，分析代码并确保代码满足要求。
您可能还想阅读我对以下帖子的回复：
如何学习“好的软件设计/架构”？在/programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489
尽管这种讨论长期以来一直没有进行，但是我想补充几个要点。
笨拙的代码是一回事。任其流向下游，设计失误会非常严重确实肿和丑陋。但是，UML是自我验证的。我的意思是，它允许您在数学上封闭且相互检查的多个维度中探索模型，从而实现了稳健的设计。
UML还有另一个重要方面：它直接与我们最强大的功能“可视化”对话。例如，如果已经以UML图的形式传达了ITIL V3（本质上很简单），那么它可能已经发布在几十个A3折页上。取而代之的是，它以真正符合圣经的比例出现在几个书卷中，催生了整个行业，惊人的成本和广泛的阳离子冲击。
UML是有用的，的确是的！我做的主要用途是：
我只是不同意Michael的看法，当他说对单个开发人员和/或简单的软件项目使用UML似乎对他来说太过分了。我已经在我的小型个人项目中使用了它，而使用UML对它们进行文档记录后，七个月后我回到他们那里却节省了很多时间，却完全忘记了我是如何构建和组合所有这些类的。
我相信，有一种方法可以利用Fowler在他的著作《 UML Distilled》中描述的Cockburn风格的UML鱼，风筝和海平面用例。我的想法是采用Cockburn用例作为代码可读性的辅助工具。
因此，我进行了一个实验，并在此处发布了带有标签“ UML”或“ FOWLER”的文章。对于c＃，这是一个简单的想法。找到一种方法将Cockburn用例嵌入到编程结构的名称空间中（例如，类和内部类名称空间，或通过使用名称空间进行枚举）。我相信这可能是一种可行且简单的技术，但仍然存在疑问，需要其他人来验证。对于需要某种伪域特定语言的简单程序来说可能会很好，这些语言可以直接存在于c＃代码中而无需任何语言扩展。
如果您有兴趣，请查看该帖子。去这里。
对于拥有大量人员的大型项目，UML似乎非常有用。但是，我曾在小型团队中工作，这些团队之间的交流更好。
不过，使用UML风格的图表是很好的，尤其是在计划阶段。我倾向于在代码中思考，因此我很难编写大型规范。我更喜欢写下输入和输出，而让开发人员在中间进行设计。
我相信UML仅对于使人们思考类之间的关系这一事实有用。这是开始考虑这种关系的良好起点，但绝对不是所有人的解决方案。
我相信，UML的使用取决于开发团队正在工作的情况。
最后，UML仅由于RUP而存在。我们是否需要UML或其任何相关内容才能使用Java / .Net？实际的答案是他们有自己的文档（javadoc等），这足以使我们完成工作！
UML没有thanx。