UML是否实用？

Question

在大学里我有很多设计和UML导向的课程，我认识到UML可以用来使软件项目受益，特别是use-case映射，但它真的很实用吗？我已经完成了一些合作工作条款，看起来UML并没有在业界大量使用。是否值得在项目中创建UML图表的时间？另外，我发现类图通常没用，因为查看类的头文件会更快。具体哪些图表最有用？

编辑：我的经验仅限于10个以下的小型开发人员项目。

编辑：许多好的答案，虽然不是最详细的，但我相信所选的是最平衡的。

Answer 1

  

使用UML就像走路时看着你的脚。它通过无意识的方式做出有意识和明确的事情。初学者需要仔细考虑他们正在做什么，但专业程序员已经知道他们在做什么。大多数时候，编写代码本身比编写代码更快更有效，因为他们的编程直觉可以适应任务。

这不仅仅是关于你在做什么。从现在起六个月内出现并需要加快代码速度的新员工呢？从现在起五年后，当前正在进行该项目的每个人都不见了？

为以后加入项目的任何人提供一些基本的最新文档是非常有帮助的。我不提倡使用方法名称和参数（WAY太难维护）的完整的UML图表，但我认为系统中组件的基本图表及其关系和基本行为是非常宝贵的。除非系统设计发生剧烈变化，否则即使实施调整，这些信息也不会发生太大变化。

我发现文档的关键是审核。没有人会阅读50页完整的UML图表和设计文档，而不会在几页内入睡。另一方面，大多数人都希望得到5-10页的简单类图，其中包含一些基本描述如何系统放在一起。

我发现UML有用的另一种情况是，高级开发人员负责设计组件，然后将设计交给初级开发人员实施。

Answer 2

在一个足够复杂的系统中，有些地方认为某些UML很有用。

系统的有用图表因适用性而异。但最常用的是State Diagrams，Activity Diagrams和Sequence Diagram。

有许多企业向他们发誓，许多企业完全拒绝他们，完全浪费时间和精力。

最好不要过分考虑你最喜欢的项目，然后选择合适且有意义的东西。

Answer 3

使用UML就像走路时看着你的脚。它通过无意识的方式做出有意识和明确的事情。初学者需要仔细考虑他们正在做什么，但专业程序员已经知道他们在做什么。大多数时候，编写代码本身比编写代码更快更有效，因为他们的编程直觉可以适应任务。

唯一的例外是为什么你在没有火炬的情况下在夜间发现自己在树林里，并且它开始下雨 - 那么你需要看看你的脚以避免摔倒。有些时候你所承担的任务比你的直觉所能处理的更复杂，你需要放慢速度并明确说明程序的结构。然后，UML是您可以使用的众多工具之一。其他包括伪代码，高级架构图和奇怪的隐喻。

Answer 4

通用工作流程和DFD对于复杂流程非常有用。根据我的经验，所有其他图表（ESPECIALLY UML）都毫无例外地浪费了时间和精力。

Answer 5

我不得不反对，UML在所有地方都被使用 - 在设计IT项目的任何地方，UML通常会在那里。

现在是否正在使用井是另一回事。

正如Stu所说，从开发人员的角度来看，我发现两个用例（以及用例描述）和活动图是最有用的。

在尝试显示关系以及对象属性（如持久性）时，类图非常有用。当谈到添加单个属性或属性时，它们通常是矫枉过正的，特别是因为一旦编写代码，它们通常会很快过时。

UML最大的问题之一是在生成代码后需要保持最新的工作量，因为很少有工具可以从代码中重新设计UML，而且很少有人能做得很好。

Answer 6

我将通过提及我没有大型（类似IBM）企业开发环境的经验来证明我的答案。

我查看UML和Rational Unified Process的方式是，它更多地 TALKING 关于你要做什么，而不是实际做什么你要去做什么要做。

（换句话说，这主要是浪费时间）

Answer 7

只在我看来扔掉了。 UML是一个很好的交流思想工具，唯一的问题是当你存储和维护它时，因为你实际上是创建了两个相同信息的副本，这就是它通常会被打击的地方。 在第一轮实施之后，大部分UML应该从源代码生成，否则它将很快过时或需要大量时间（手动错误）以保持最新。

Answer 8

我在学校的最后两个学期共同教授了一个高级开发项目课程。该项目旨在用于当地非营利组织作为付费客户的生产环境。我们必须确保代码符合我们的预期，并且学生们正在捕获满足客户需求所需的所有数据。

课堂时间有限，我在教室外的时间也是如此。因此，我们不得不在每次课堂会议上进行代码审查，但有25名学生注册个人审核时间非常短。我们在这些审查会议中发现最有价值的工具是ERD，类图和序列图。 ERD和类图仅在Visual Studio中完成，因此创建它们所需的时间对于学生来说是微不足道的。

图表很快传达了大量信息。通过快速浏览学生的设计，我们可以快速隔离代码中的问题区域，并在现场进行更详细的审查。

如果不使用图表，我们将不得不花时间通过学生的代码文件逐一查找问题。

Answer 9

我迟到了这个话题，并试着澄清一些小问题。询问UML是否有用太广泛了。大多数人似乎从典型/流行的UML中回答了问题，作为绘图/交流工具的视角。注意：Martin Fowler和其他UML书籍作者认为UML最适合仅用于通信。但是，UML还有许多其他用途。最重要的是，UML是一种建模语言，其符号和图表映射到逻辑概念。以下是UML的一些用法：

• 通信
• 标准化设计/解决方案文档
• DSL（域特定语言）定义
• 模型定义（UML配置文件）
• 模式/资产使用
• 代码生成
• 模型到模型转换

鉴于上面的使用列表，Pascal的发布是不够的，因为它只涉及图表创建。如果上述任何一项成为关键的成功因素，或者是需要标准化解决方案的问题领域，项目可以从UML中受益。

讨论应该从UML如何过度使用或应用于小型项目以讨论何时UML有意义或将实际改进产品/解决方案扩展出来，因为应该使用UML。在某些情况下，一个开发人员的UML也可以感知，例如模式应用程序或代码生成。

Answer 10

UML多年来一直为我工作。当我开始时，我读了福勒的UML Distilled，他说“做足够的建模/建筑等等”。只需使用您需要的！

Answer 11

从QA工程师的角度来看，UML图表指出了逻辑和思想的潜在缺陷。让我的工作更轻松：）

Answer 12

UML图对于捕获和传达需求以及确保系统满足这些要求非常有用。它们可以在规划，设计，开发和测试的各个阶段中反复使用。

来自主题：在http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

中使用开发过程中的模型

  

模型可以帮助您可视化系统运行的世界，阐明用户的需求，定义   系统架构，分析代码，并确保您的代码符合要求。

您可能还想阅读我对以下帖子的回复：

如何学习“良好的软件设计/架构”？，https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Answer 13

我认为UML是有用的想法我认为2.0规范已经使曾经的一个明确的规范有些臃肿和繁琐。我同意时序图等版本，因为它们填补了空白......

学习如何有效地使用UML需要一些练习。最重要的一点是清晰地沟通，在需要时建模并以团队形式建模。白板是我发现的最好的工具。我还没有看到任何“数字白板软件”能够捕获实际白板的效用。

话虽如此，我确实喜欢以下UML工具：

1. 紫罗兰 - 如果它更简单就会是一张纸

2. Altova UModel - 适用于Java和C＃建模的好工具

3. MagicDraw - 我最喜欢的建模商业工具

4. Poseidon - 体面美味的体面工具

5. StarUML - 最佳开源建模工具

Answer 14

虽然这个讨论长期以来一直处于非活动状态，但我有几点 - 我的想法很重要 - 要添加。

越野车代码是一回事。离开下游，设计错误确实会变得非常强烈臃肿和丑陋。但是，UML是自我验证的。我的意思是，在允许您以多个，数学上封闭和相互检查的维度探索模型时，它会产生强大的设计。

UML还有另一个重要方面：它直接与我们最强大的能力“可视化”进行“对话”。例如，ITIL V3（内容很简单）已经以UML图的形式进行了通信，它可能已经在几十个A3折页上发布了。相反，它出现在几个真正圣经比例的书中，催生了整个行业，惊人的成本和广泛的紧张性冲击。

Answer 15

只要您使用字段和方法表示类，就会使用UML，尽管它只是一种UML图。

UML的问题在于创始人的书太模糊了。

UML只是一种语言，它不是一种真正的方法。

至于我，我真的觉得烦恼是Opensource Projects缺乏UML架构。像Wordpress这样的东西，你只需要一个数据库模式，没有别的。你必须在codex api周围闲逛，试着全面了解。

Answer 16

来自学生，我发现UML几乎没用。我觉得具有讽刺意味的是，PROGAMERS还没有开发出能够自动生成你所说的必要内容的程序。在Visual Studio中设计一个功能非常简单，它可以提取数据，寻找定义和产品答案，以便任何人都能看到它，无论大小，并理解程序。这也会使它保持最新，因为它会直接从代码中获取信息来生成信息。

Answer 17

UML非常有用，确实如此！我用它做的主要用途是：

• 集思广益，了解软件应该如何运作。它可以很容易地传达您的想法。
• 记录系统的体系结构，它的模式和类的主要关系。当有人进入你的团队，当你离开并希望确保你的继任者能够理解它，以及当你最终忘记那个小课程的意义时，它会有所帮助。
• 记录您在所有系统上使用的任何架构模式，原因与上面的点相同

我只是不同意Michael，当他说使用UML为一个开发人员和/或一个简单的软件项目时，他似乎有点过分。我已经在我的小型个人项目中使用它了，并且使用UML记录它们使我节省了很多时间，当我七个月后回到它们并且完全忘记了我是如何构建和组合所有这些类的。

Answer 18

我发现UML对于非常小的项目并不是真的有用，但真的适合大型项目。

基本上，你使用什么并不重要，你只需记住两件事：

• 您想要某种架构规划
• 您希望确保团队中的每个人实际上都使用相同的技术进行项目规划

所以UML就是这样：关于如何规划项目的标准。如果你雇用新人，那么更有可能知道任何现有的标准 - 无论是UML，Flowchard，Nassi-Schneiderman，还是其他任何东西 - 而不是你现有的内部资源。

对一个开发人员和/或一个简单的软件项目使用UML对我来说似乎有些过分，但是当我在一个更大的团队中工作时，我肯定需要一些标准来规划软件。

Answer 19

我看到频繁使用的序列图和活动图。我使用与其他系统交互的“实时”和嵌入式系统做了大量工作，序列图对于可视化所有交互非常有用。

我喜欢做用例图，但我没有见过太多认为有价值的人。

我经常想知道Rational Rose是否是从基于UML模型的设计中获得的各种应用程序的一个很好的例子。它臃肿，马车，慢，丑，...

Answer 20

我相信可能有一种方法可以利用Cockow风格的UML鱼，风筝和海平面使用案例，如Fowler在他的书“UML Distilled”中所描述的那样。我的想法是使用Cockburn用例作为代码可读性的辅助。

所以我做了一个实验，这里有一篇关于标签“UML”或“FOWLER”的帖子。对于c＃来说这是一个简单的想法。找到一种方法将Cockburn用例嵌入到编程构造的名称空间中（例如类和内部类名称空间，或者通过使用枚举的名称空间）。我相信这可能是一种可行且简单的技术，但仍有疑问，需要其他人来检查。对于需要一种伪域特定语言的简单程序来说，这可能是好的，这种语言可以直接存在于c＃代码中而没有任何语言扩展。

如果您有兴趣，请查看帖子。转到here。

Answer 21

我对UML的一个问题是规范的可理解性。当我试图真正理解特定图表的语义时，我很快迷失在元模型和元元模型的迷宫中。 UML的一个卖点是它比自然语言更不模糊。但是，如果两个或更多工程师以不同的方式解释图表，那么它就会失败。

另外，我尝试在几个UML论坛上向OMG本身的成员询问有关超结构文档的具体问题，但结果很少甚至没有。我认为UML社区还不够成熟，不能支持自己。

Answer 22

UML有它的位置。随着项目规模的扩大，它变得越来越重要。如果你有一个长期运行的项目，那么最好用UML记录所有内容。

Answer 23

UML似乎适用于拥有大量人员的大型项目。不过，我曾在通信较好的小团队中工作过。

使用UML-esque图表虽然很好，尤其是在规划阶段。我倾向于在代码中思考，所以我发现很难写大规格。我更喜欢写下输入'和输出'，让开发人员在中间设计位。

Answer 24

UML在两个方面很有用：

• 技术方面：很多人（经理和一些功能分析师）认为UML是一种奢侈功能，因为代码是文档：在调试和修复之后开始编码 。 UML图与代码和分析的同步迫使您很好地理解客户的请求;

• 管理方面：UMl图表是客户需求不准确的一面镜子：如果您没有使用UML进行编码，也许您可​​以在经过大量工作后找到需要的错误。图表UML允许您找到可能的争议点，并在编码之前解决=＆gt;帮助您进行规划。

一般来说，没有UML图的所有项目都有表面分析，或者尺寸很短。

如果您在linkedin组系统工程师中，请参阅my old discussion。

Answer 25

我相信UML只是因为它让人们思考他们的类之间的关系。这是一个很好的起点，开始考虑这种关系，但它绝对不是每个人的解决方案。

我的信念是，UML的使用对于开发团队工作的情况是主观的。

Answer 26

根据我的经验：

创建和传达有意义的代码图的能力是任何正在开发新代码或尝试理解现有代码的软件工程师的必备技能。

了解UML的具体细节 - 何时使用虚线或圆形端点 - 并不是必要的，但仍然很好。

Answer 27

最后，UML仅因RUP而存在。我们是否需要使用UML或其任何相关内容来使用Java / .Net？实际的答案是他们有自己的文件（javadoc等），这足以让我们完成工作！

UML no thanx。

Answer 28

UML绝对有用，因为junit是必不可少的。这一切都取决于你如何出售这个想法。您的程序将在没有UML的情况下工作，就像没有单元测试一样。话虽如此，你应该创建do UML，因为它连接到你的代码，即当你更新UML图时它会更新你的代码，或者当你更新代码时它会自动生成UML。不要只是为了做到这一点。

Answer 29

UML绝对在业界占有一席之地。想象一下，您正在为Boing飞机或其他复杂系统构建软件。 UML和RUP在这里会有很大的帮助。

Answer 30

UML只是人们之间沟通的方法之一。 白板更好。

Answer 31

不，不是。代码是最好的沟通方式。其他一切都是针对那些进入错误行业的人，并决定改变它以适应他们的大脑。

接口远远优于类图。用例图将用户需求混合到一个破坏它们的表单中，并告诉您如何设计产品。数据流图和ER图使创建数据库的过程复杂化。有时您可能想绘制图表来表达您的观点，但没有理由他们必须是UML图表或符合除了其他人可以理解的标准之外的任何标准。

最后，这些都是大型，无用，官僚“软件”公司的所有形式的文档，这些公司使用XML制作可怕的产品。也就是说，如果他们完成了记录。实际上，大多数员工并不关心他们的工作，只是等待他们上面的人死去，以便他们能够获得晋升。