UML实用吗？[关闭]
https://stackoverflow.com/questions/18803
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian解决方案
在一个足够复杂的系统中，有些地方某些 UML 被认为是有用的。
系统的有用图表因适用性而异。但最广泛使用的是状态图、活动图和序列图。
有许多企业对它们发誓，但也有许多企业断然拒绝它们，认为它们完全是浪费时间和精力。
最好不要太过分，思考什么最适合您正在进行的项目，并选择适用且有意义的内容。
其他提示
使用 UML 就像走路时看着你的脚一样。它使你通常可以无意识地做的事情变得有意识和明确。初学者需要仔细思考他们在做什么，但专业程序员已经知道他们在做什么。大多数时候，编写代码本身比编写代码更快、更有效，因为他们的编程直觉适合任务。
但这不仅仅与你正在做的事情有关。那么六个月后进来并需要跟上代码速度的新员工呢？五年后，当目前参与该项目的所有人都离开时会怎样？
为后来加入该项目的任何人提供一些基本的最新文档是非常有帮助的。我不提倡使用方法名称和参数的完整 UML 图（太难维护），但我确实认为系统中组件的基本图及其关系和基本行为是非常宝贵的。除非系统的设计发生巨大变化，否则即使调整实现，这些信息也不应该发生太大变化。
我发现文档的关键是适度。没有人会在阅读 50 页完整的带有设计文档的 UML 图时，读几页就睡着了。另一方面，大多数人希望获得 5 到 10 页的简单类图，其中包含系统如何组合的一些基本描述。
我发现 UML 有用的另一种情况是高级开发人员负责设计组件，然后将设计交给初级开发人员来实现。
使用 UML 就像走路时看着你的脚一样。它使你通常可以无意识地做的事情变得有意识和明确。初学者需要仔细思考他们在做什么，但专业程序员已经知道他们在做什么。大多数时候，编写代码本身比编写代码更快、更有效，因为他们的编程直觉适合任务。
例外的是，为什么你发现自己晚上在树林里没有手电筒，而且天开始下雨了——那么你需要注意自己的脚，以免摔倒。有时，您所承担的任务比您的直觉更复杂，您需要放慢速度并明确地说明程序的结构。那么 UML 就是您可以使用的众多工具之一。其他包括伪代码、高级架构图和奇怪的隐喻。
通用工作流程和 DFD 对于复杂流程非常有用。根据我的经验，所有其他图表（特别是 UML）无一例外都是对时间和精力的痛苦浪费。
我不得不不同意，UML 无处不在——设计 IT 项目的任何地方通常都会有 UML。
现在是否正在使用 出色地 又是另一回事了。
正如 Stu 所说，我发现从开发人员的角度来看，用例（以及用例描述）和活动图都是最有帮助的。
当尝试显示关系以及对象属性（例如持久性）时，类图非常有用。当涉及到添加单个属性或属性时，它们通常是矫枉过正的，特别是因为一旦编写了代码，它们往往很快就会过时。
UML 的最大问题之一是一旦生成代码就需要大量的工作来使其保持最新，因为很少有工具可以从代码重新设计 UML，而且做得很好的工具也很少。
我将通过提及我没有大型（类似 IBM）企业开发环境的经验来限定我的答案。
我看待 UML 的方式和 合理的统一过程 是它更多 说 关于你要做什么而不是实际做 正在做 你要做什么。
（换句话说，这很大程度上是浪费时间）
仅在我看来扔掉。UML 是交流思想的一个很好的工具，唯一的问题是当你存储和维护它时，因为你本质上是创建相同信息的两个副本，而这通常是它失败的地方。在第一轮实现之后，大部分 UML 应该从源代码生成，否则它将很快过时或需要大量时间（带有手动错误）来保持最新状态。
我在学校的最后两个学期共同教授了高级发展项目课程。该项目旨在在生产环境中使用，当地非营利组织作为付费客户。我们必须确保代码符合我们的预期，并且学生正在捕获满足客户需求所需的所有数据。
上课时间有限，课外时间也有限。因此，我们必须在每次班会上进行代码审查，但由于注册了 25 名学生，个人审查时间非常短。我们发现在这些审查会议中最有价值的工具是 ERD、类图和序列图。ERD 和类图仅在 Visual Studio 中完成，因此创建它们所需的时间对于学生来说微不足道。
这些图表非常快速地传达了大量信息。通过快速概览学生的设计，我们可以快速隔离他们代码中的问题区域，并当场进行更详细的审查。
如果不使用图表，我们就必须花时间去一一检查学生的代码文件来寻找问题。
我来这个话题有点晚了，只是尝试澄清几个小问题。询问 UML 是否有用，因为太广泛了。大多数人似乎从典型/流行的 UML 作为绘图/通信工具的角度来回答这个问题。笔记：Martin Fowler 和其他 UML 书籍作者认为 UML 最好仅用于通信。然而，UML 还有许多其他用途。最重要的是，UML 是一种建模语言，具有映射到逻辑概念的符号和图表。以下是 UML 的一些用途：
- 沟通
- 标准化设计/解决方案文档
- DSL（领域特定语言）定义
- 模型定义（UML 配置文件）
- 模式/资产使用
- 代码生成
- 模型到模型的转换
鉴于上面的使用列表，Pascal 的发布是不够的，因为它仅涉及图表创建。如果上述任何一个因素是关键的成功因素或者是需要标准化解决方案的问题领域，那么项目就可以从 UML 中受益。
讨论应该从 UML 如何过度杀伤或应用于小型项目展开讨论，讨论 UML 何时有意义或将真正改进产品/解决方案，因为此时应该使用 UML。在某些情况下，一名开发人员也可以感知 UML，例如模式应用程序或代码生成。
UML 已经为我工作了很多年。当我开始的时候，我读了福勒的书 UML 蒸馏 他说“做足够的建模/架构/等等”。只需使用你所用的 需要!
从 QA 工程师的角度来看，UML 图指出了逻辑和思维中的潜在缺陷。让我的工作更轻松:)
我认为 UML 很有用，我认为 2.0 规范使曾经明确的规范变得有些臃肿和麻烦。我确实同意时序图等的版本，因为它们填补了空白......
学习有效地使用 UML 需要一些练习。最重要的一点是清晰地沟通、在需要时进行建模以及作为一个团队进行建模。白板是我发现的最好的工具。我还没有看到任何“数字白板软件”能够实现实际白板的实用性。
话虽这么说，我确实喜欢以下 UML 工具：
紫罗兰 - 如果更简单的话那就是一张纸
Altova UModel - Java 和 C# 建模的好工具
MagicDraw - 我最喜欢的商业建模工具
Poseidon - 物有所值的好工具
- StarUML - 最好的开源建模工具
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
尽管这个讨论长期以来一直不活跃，但我认为有一些重要的观点需要补充。
有缺陷的代码是一回事。如果任其向下游漂流，可能会出现设计错误 非常 确实又臃肿又丑陋。然而，UML 是自我验证的。我的意思是，通过允许您在多个数学封闭且相互检查的维度中探索模型，它可以产生稳健的设计。
UML 还有另一个重要方面：它直接与我们最强的能力“对话”，即可视化能力。例如，如果 ITIL V3（本质上足够简单）以 UML 图的形式进行传达，那么它可能会在几十张 A3 折页上发布。相反，它以几本真正符合圣经的巨著问世，催生了整个行业，带来了惊人的成本和广泛的紧张性冲击。
我发现序列图和活动图使用得相当频繁。我做了很多与其他系统交互的“实时”和嵌入式系统的工作，序列图对于可视化所有交互非常有帮助。
我喜欢绘制用例图，但我还没有遇到太多认为用例图有价值的人。
我经常想知道 Rational Rose 是否是从基于 UML 模型的设计中获得的应用程序类型的一个很好的例子。它臃肿、有缺陷、缓慢、丑陋……
我发现 UML 对于非常小的项目来说并不是很有用，但非常适合较大的项目。
本质上，你使用什么并不重要，你只需要记住两件事：
- 你想要某种架构规划
- 您希望确保团队中的每个人实际上都使用相同的技术进行项目规划
所以 UML 就是：关于如何规划项目的标准。如果你雇用新人，他们更有可能知道任何现有的标准 - 无论是 UML、Flowchard、Nassi-Schneiderman 等等 - 而不是你现有的内部标准。
对单个开发人员和/或简单的软件项目使用 UML 对我来说似乎有些过分，但是当在更大的团队中工作时，我肯定需要一些规划软件的标准。
UML 很有用，确实如此！我对它的主要用途是：
- 集思广益，讨论软件的工作方式。它可以轻松传达您的想法。
- 记录系统的体系结构、模式及其类的主要关系。当有人进入你的团队时，当你离开并希望确保你的继任者能够理解它时，以及当你最终忘记这个小课程到底是用来做什么时，它都会有所帮助。
- 出于与上面点相同的原因，记录您在所有系统上使用的任何架构模式
我只是不同意 迈克尔 当他这么说时 对于单个开发人员和/或简单的软件项目使用 UML 似乎有些过头了 给他。我已经在我的小型个人项目中使用了它，并且使用 UML 记录它们为我节省了很多时间，当我七个月后回到它们时，我完全忘记了我是如何构建和组合所有这些类的。
我相信可能有一种方法可以利用福勒在他的书《 UML蒸馏》中描述的Cockburn风格的UML鱼，风筝和海平面用例。我的想法是使用Cockburn用例来帮助代码可读性。
因此，我进行了一个实验，这里有一个帖子，上面有标签“ UML”或“ Fowler”。对于C＃来说，这是一个简单的想法。找到一种方法将 Cockburn 用例嵌入到编程构造的命名空间中（例如类和内部类命名空间或使用枚举命名空间）。我相信这可能是一种可行且简单的技术，但仍然存在疑问，需要其他人进行检查。对于需要一种伪域特定语言的简单程序来说，它可能很有用，这种语言可以存在于 C# 代码中，而无需任何语言扩展。
如果您有兴趣，请查看该帖子。去 这里.
我在使用 UML 时遇到的问题之一是规范的可理解性。当我尝试真正理解特定图表的语义时，我很快就会迷失在元模型和元元模型的迷宫中。UML 的卖点之一是它比自然语言更明确。然而，如果两个或更多工程师对图表的解释不同，那么它就无法达到目标。
另外，我尝试在几个 UML 论坛上以及向 OMG 本身的成员询问有关上层结构文档的具体问题，但收效甚微或根本没有。我认为 UML 社区还不够成熟，无法支持自身。
作为一名学生，我发现 UML 没什么用处。我觉得很讽刺的是，程序员还没有开发出一个程序来自动生成你所说的必要的东西。在 Visual Studio 中设计一个功能将非常简单，该功能可以提取数据片段、寻找定义并提供足够的答案，以便任何人（无论大小）都可以查看它并理解该程序。这也将使其保持最新，因为它将直接从代码中获取信息来生成信息。
当您用其字段和方法表示一个类时，就会使用 UML，尽管它只是一种 UML 图。
UML 的问题在于创始人的书太模糊了。
UML只是一种语言，它并不是真正的方法。
对于我来说，我真的很恼火开源项目缺少 UML 模式。以 Wordpress 为例，您只有一个数据库架构，没有其他任何东西。您必须浏览 Codex api 才能了解全局。
UML 有其一席之地。随着项目规模的扩大，它变得越来越重要。如果您有一个长期运行的项目，那么最好用 UML 记录所有内容。
UML 似乎适合由大型团队组成的大型项目。然而，我曾在沟通更好的小团队中工作过。
不过，使用 UML 式的图表很好，尤其是在规划阶段。我倾向于用代码来思考，所以我发现编写大规格很困难。我更喜欢写下输入和输出，然后让开发人员设计中间的部分。
在我的经验中：
对于任何正在开发新代码或尝试理解现有代码的软件工程师来说，创建和传达有意义的代码图的能力是一项必备技能。
了解 UML 的细节（何时使用虚线或圆端点）虽然不是很有必要，但仍然很好。
我相信 UML 很有用，因为它让人们思考类之间的关系。这是开始思考此类关系的一个很好的起点，但它绝对不是适合每个人的解决方案。
我相信 UML 的使用取决于开发团队的工作情况。
UML 有两个用途：
技术方面：很多人（经理和一些功能分析师）认为 UML 是一个奢侈的功能，因为 代码是文档：在调试和修复之后开始编码. 。UML图与代码和分析的同步迫使你很好地理解客户的需求；
管理端：UMl 图反映了不准确的客户需求：如果您在没有 UML 的情况下进行编码，也许经过大量工作后您会发现 require 中的错误。UML 图表允许您在编码之前找到可能的争议点并解决 => 帮助您进行规划。
一般来说，没有UML图的项目都是分析肤浅或者规模较小的。
如果您在 linkedin 群组中 系统工程师, ， 看 我以前的讨论.
最终 UML 的存在只是因为 RUP。我们需要 UML 或任何相关的东西才能使用 Java/.Net 吗？实际的答案是他们有自己的文档（javadoc 等），这足以让我们完成工作！
UML 不，谢谢。
UML 绝对有帮助，就像 junit 必不可少一样。这完全取决于你如何推销这个想法。您的程序无需 UML 即可运行，就像无需单元测试即可运行一样。话虽如此，您应该创建 UML，因为它连接到您的代码，即当您更新 UML 图时，它会更新您的代码，或者当您更新代码时，它会自动生成 UML。不要只是为了做而做。
UML 无疑在业界占有一席之地。想象一下您正在为波音飞机或其他一些复杂系统构建软件。UML 和 RUP 在这里会有很大的帮助。
UML只是人们内部交流的方法之一。白板比较好。
