UML是否实用？
在大学里，我有很多devise和面向UML的课程，我认识到，UML可以用来使软件项目受益，特别是用例映射，但这是否真的很实用？ 我已经做了一些合作的工作条款，看来UML在业界并没有被大量使用。 在项目中创buildUML图表是否值得？ 另外，我发现类图通常是没有用的，因为查看类的头文件只是更快。 具体哪些图是最有用的？
编辑：我的经验是限制在10个开发人员项目小。
编辑：许多好的答案，虽然不是最详细的，我相信所select的是最平衡的。
在一个足够复杂的系统中，有一些UML被认为是有用的地方。
系统的有用图表因适用性而异。 但是最广泛使用的是状态图，活动图和序列图。
有许多企业是由他们发誓的，许多企业完全是在浪费时间和精力。
最好不要太过分，想想你最近的项目是什么，select合适的和合理的东西。
使用UML就像在走路时看着你的脚。 它是在意识和明确的东西，你通常可以无意识地做。 初学者需要仔细思考他们在做什么，但是一个专业的程序员已经知道他们在做什么。 大多数情况下，编写代码本身比编写代码更快，更有效，因为编程的直觉被调整到了任务上。
这不仅仅是你在做什么。 那么从现在开始的六个月内新来的雇员呢，还需要加快代码的速度呢？ 那么现在从事这个项目的所有人都离开了五年之后呢？
对于稍后join项目的任何人来说，有一些基本的最新文档是非常有帮助的。 我并不主张使用方法名和参数（WAY太难维护）的全面的UML图，但我认为系统中组件的基本关系图和基本行为是非常宝贵的。 除非系统devise剧烈变化，否则这个信息不应该改变很多，即使执行被调整了。
我发现文档的关键是适度的。 没有人会阅读50页的devise文档的完整的UML图，而没有睡着几页。另一方面，大多数人会喜欢得到5-10页的简单的类图，一些基本的描述如何系统放在一起。
另一个我发现UML很有用的例子是当一个高级开发人员负责devise一个组件时，然后把这个devise交给一个初级开发人员来实现。
使用UML就像在走路时看着你的脚。 它是在意识和明确的东西，你通常可以无意识地做。 初学者需要仔细思考他们在做什么，但是一个专业的程序员已经知道他们在做什么。 大多数情况下，编写代码本身比编写代码更快，更有效，因为编程的直觉被调整到了任务上。
例外是为什么你晚上在没有火炬的情况下在树林里发现自己，并开始下雨 – 那么你需要看你的脚，以避免摔倒。 有时候你所做的任务比你的直觉所能处理的要复杂得多，而且你需要放慢脚步，明确地表明你的程序结构。 那么UML是你可以使用的许多工具之一。 其他包括伪代码，高层架构图和奇怪的隐喻。
通用工作stream程和DFD对于复杂的stream程可能非常有用。 根据我的经验，所有其他的图表（特别是UML）无一例外都是时间和精力的痛苦浪费。
我不得不不同意，UML被广泛使用 – 任何一个IT项目正在devise的地方UML通常都会在那里。
现在是否使用得好是另一回事。
正如Stu所说，从开发人员的angular度来看，我发现用例（以及用例描述）和活动图都是最有用的。
当试图显示关系时，类图可能非常有用，以及对象属性（如持久性）。 当添加单个属性或属性时，通常都是过度的，尤其是一旦编写代码，它们往往会变得过时。
UML最大的问题之一就是一旦生成代码就需要保持最新的工作量，因为很less有能够从代码重新deviseUML的工具，而且很less有工具能够做到。
我将通过提及我没有大型（类似于IBM的）企业开发环境的经验来限定我的答案。
我认为UML和Rational统一过程的方式是更多地谈论你要做什么，而不是去做你将要做的事情。
（换句话说，这在很大程度上是浪费时间）
只扔在我的意见。 UML是交stream想法的好工具，唯一的问题是当你存储和维护它的时候，因为你实际上是在创build同一信息的两个副本，而这正是通常所吹的。 在第一轮实施之后，大部分的UML应该从源代码中生成，否则就会很快过时，或者需要很多时间（手动错误）才能保持最新。
我在学校的最后两个学期共同教了一个高级开发项目课程。 该项目的目的是在当地非营利组织的生产环境中用作付费客户。 我们必须确保代码符合我们的预期，并且学生能够获取所有必要的数据以满足客户的需求。
上课时间有限，我在课堂以外的时间也是如此。 因此，我们不得不在每个class级会议上进行代码审查，但有25名学生参加了单独的审查时间非常短。 我们在这些审查会议中发现的最有价值的工具是ERD，类图和顺序图。 ERD和类图只在Visual Studio中完成，所以创build它们所需的时间对于学生来说是微不足道的。
图表很快就传达了大量的信息。 通过快速浏览学生的devise，我们可以快速隔离代码中的问题区域，并在现场进行更详细的审查。
如果不使用图表，我们不得不花费时间通过学生的代码文件逐个查找问题。
我稍微晚一点来谈这个话题，只是想澄清一些小问题。 询问UML是否有用太宽泛。 大多数人似乎从典型/stream行的UML作为绘图/交stream工具的angular度来回答这个问题。 注意：Martin Fowler和其他UML书籍作者认为UML最适合用于通信。 但是，UML还有许多其他用途。 最重要的是，UML是一种build模语言，具有与逻辑概念相映射的符号和图表。 以下是UML的一些用法：
- 通讯
- 标准化devise/解决scheme文档
- DSL（域特定语言）定义
- 模型定义（UMLconfiguration文件）
- 模式/资产使用情况
- 代码生成
- 模型到模型的转换
考虑到上面的用途列表，Pascal的发布是不够的，因为它只能说明创build图表。 如果上述任何一项都是关键的成功因素，或者是需要标准化解决scheme的问题领域，则项目可以从UML中受益。
讨论应该从UML如何超过杀戮或者应用于小型项目扩展出来，讨论UML何时有意义或者是否会像使用UML一样改进产品/解决scheme。 在某些情况下，一个开发人员也可以使用UML，例如模式应用程序或代码生成。
UML已经为我工作了多年。 当我开始阅读福勒公司的UML Distilled时 ，他说“做足够的build模/架构/等等”。 只要使用你所需要的 ！
我认为UML是有用的，因为我认为2.0规范已经使一个明确的规范有点臃肿和繁琐。 我同意时间图的版本等，因为他们填补了空白…
学习如何使用UML需要一些练习。 最重要的一点是沟通清晰，需要时模式化，团队模式化。 白板是我find的最好的工具。 我还没有看到任何“数字白板软件”，已经设法捕捉实际白板的实用程序。
这就是说，我喜欢以下的UML工具：
-
紫罗兰 – 如果它更简单，它将是一张纸
-
Altova UModel – Java和C＃build模的好工具
-
MagicDraw – 我最喜欢的build模商业工具
-
波塞冬 – 体面的工具与良好的爆炸降压
- StarUML – 最好的开源build模工具
从质量保证工程师的angular度看，UML图表指出了逻辑和思想上的潜在缺陷。 让我的工作更轻松:)
UML图对于捕获和交stream需求以及确保系统满足这些需求非常有用。 它们可以在计划，devise，开发和testing的不同阶段迭代使用。
从主题： 在开发过程中使用模型 http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx
模型可以帮助您可视化系统工作的世界，阐明用户需求，定义系统架构，分析代码并确保代码满足要求。
您可能还想阅读我对以下post的回复：
如何学习“好的软件devise/架构”？ 在https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489
尽pipe这个讨论一直没有起作用，但我还是有一些重要的观点需要补充。
Buggy代码是一回事。 留下来漂stream，devise错误可能会变得非常臃肿和丑陋。 但是，UML是自我validation的。 我的意思是，在允许您在多个mathclosures和相互检查维度中探索您的模型，它会产生强大的devise。
UML还有另一个重要方面：它直接与我们最强大的可视化能力“直接对话”。 例如，如果以UML图的forms传达了ITIL V3（在心里很简单），它可能已经发布在几十个A3折页上。 相反，它出现了几个真正的圣经比例，产生了整个行业，惊人的成本和广泛的紧张的震惊。
我经常使用序列图和活动图。 我在与其他系统进行交互的“实时”和embedded式系统上做了大量的工作，顺序图对于可视化所有的交互是非常有帮助的。
我喜欢做用例图，但是我没有遇到太多认为他们有价值的人。
我经常想知道Rational Rose是否是从基于UML模型的devise中获得的应用程序的一个很好的例子。 它膨胀，越野车，缓慢，丑陋，…
我发现UML对于非常小的项目并不是很有用，但是真正适用于较大的项目。
从本质上讲，你使用什么并不重要，你只需要记住两点：
- 你想要某种架构规划
- 你想要确保团队中的每个人实际上都使用相同的技术进行项目规划
所以UML就是这样：一个关于如何规划你的项目的标准。 如果你聘用了新员工，就更有可能知道现有的标准 – 无论是UML，Flowchard还是Nassi-Schneiderman，而不是你内部的东西。
对单个开发人员和/或一个简单的软件项目使用UML似乎有点过分，但是当在一个更大的团队中工作时，我肯定会想要一些规划软件的标准。
UML是有用的，是的！ 我所做的主要用途是：
- 集体讨论一个软件的工作方式。 它很容易沟通你在想什么。
- logging一个系统的体系结构，它是模式和它的类的主要关系。 这有助于当有人进入你的团队，当你离开，并希望确保你的继任者会理解它，当你最终忘记了什么是小class的意思。
- logging您在所有系统上使用的任何架构模式，出于上述点的相同原因
我只是不同意Michael的观点，他说使用UML开发一个开发人员和/或一个简单的软件项目似乎对他来说过分了。 我把它用在我的小型个人项目上，使用UMLlogging下来，为我节省了大量的时间，七个月后我又回到了这些项目中，并完全忘记了我是如何build造和组装所有这些课程的。
我相信Fowler在他的书“UML Distilled”中描述的方式可能有一种方法可以利用Cockburn风格的UML鱼，风筝和海平面用例。 我的想法是使用Cockburn用例来帮助代码可读性。
所以我做了一个实验，这里有一个贴子“UML”或“FOWLER”。 这是一个简单的想法对于C＃。 find一种方法将Cockburn用例embedded到编程结构的命名空间中（比如类和内部类的命名空间，或者通过使用命名空间来实现枚举）。 我相信这可能是一个可行和简单的技术，但仍然有问题，需要其他人检查出来。 对于那些需要一种可以在c＃代码中正确存在而不需要任何语言扩展的伪域专用语言的简单程序来说，这可能是件好事。
如果你感兴趣，请查看post。 去这里
我对UML的一个问题是规范的可理解性。 当我试图真正理解特定图的语义时，我很快就迷失在元模型和元元模型的迷宫中。 UML的卖点之一就是它比自然语言更不明确。 但是，如果两个或更多的工程师对一个图表进行不同的解释，那么这个目标就失败了。
另外，我试过在几个UML论坛上询问有关超级结构文档的具体问题，并向OMG成员提出了很less或根本没有结果的问题。 我不认为UML社区还不够成熟以支持自己。
来自一个学生，我发现UML很less用。 我觉得讽刺的是，PROGAMERS还没有开发一个能自动生成你所说的东西是必须的程序。 在Visual Studio中devise一个function非常简单，这个function可以抽取数据，寻找定义和产品答案，以便任何人都可以查看它，无论大小，都能理解程序。 这也会使它保持最新，因为它会直接从代码中获取信息来生成信息。
尽pipeUML图只是一种UML图，但是只要您使用其字段和方法表示类，就可以使用UML。
UML的问题在于创始人的书太模糊了。
UML只是一种语言，它不是一个真正的方法。
至于我，我真的发现恼人的Opensource项目缺乏UML模式。 采取像WordPress的东西，你只是有一个数据库架构，没有别的。 你必须在Codex API上漫步，试图获得大局。
UML有它的地位。 随着项目规模的扩大，它变得越来越重要。 如果你有一个长期运行的项目，那么最好用UML来logging所有的东西。
UML对于大型团队的大型项目来说似乎很好。 不过我曾经在沟通较好的小团队工作过。
使用UML-esque图很好，特别是在规划阶段。 我倾向于在代码中思考，所以我觉得写大规格很难。 我更喜欢把input和输出写下来，让开发人员在中间进行devise。
在我的经验中：
创build和交stream有意义的代码图的能力是任何正在开发新代码或试图理解现有代码的软件工程师的必备技能。
了解UML的具体细节 – 何时使用虚线或圆圈端点 – 并不是那么必要，但仍然有好处。
我相信UML是有用的，因为它让人们思考他们的类之间的关系。 开始考虑这种关系是一个很好的起点，但绝对不是每个人的解决scheme。
我的看法是使用UML对开发团队工作的情况是主观的。
UML在两个方面是有用的：
-
技术方面：很多人（经理和一些function分析师）认为UML是一种奢侈function，因为代码是文档：在debugging和修复之后开始编码 。 UML图与代码和分析的同步迫使你很好地理解客户的要求;
-
pipe理方面：UMl图表是客户需求不准确的一面镜子：如果你的代码没有UML，也许你可以在经过大量的工作时间之后find需要的bug。 图表UML允许你find可能的争议点，并在编码之前解决=>帮助你的计划。
一般来说，没有UML图的所有项目都有浅显的分析或者规模较小。
如果你在LinkedIn的工程师组，看看我以前的讨论 。
最终UML只是因为RUP而存在。 我们是否需要UML或其相关的东西来使用Java / .Net？ 实际的答案是他们有自己的文件（javadoc等），这是足够的，让我们完成我们的工作！
UML不是。
UML绝对有帮助，就像junit是必不可less的。 这一切都取决于你如何销售这个想法。 你的程序将在没有UML的情况下工作，就像没有unit testing一样。 话虽如此，你应该创buildUML，因为它连接到你的代码，也就是当你更新UML图时，它会更新你的代码，或者当你更新你的代码时，它会自动生成UML。 不要只为了这样做而做。
UML只是人们沟通的一种方法。 白板更好。
UML在业界有其自己的地位。 想象一下，你正在为Boing飞机或其他复杂系统build立软件。 UML和RUP在这里是非常有帮助的。
