Is UML practical?在大学里，我参加过许多面向设计和UML的课程，而且我认识到UML可以使软件项目受益，尤其是用例映射，但这真的很实用吗？ 我已经完成了一些合作工作条款，而且看来UML在行业中并未得到广泛使用。 在项目期间创建UML图值得吗？ 另外，我发现类图通常没有用，因为查看类的头文件只是更快。 具体来说，哪些图表最有用？ 编辑：我的经验仅限于10个以下的小型开发人员项目。 编辑：许多好的答案，虽然不是最冗长的，但我相信选择的一个是最平衡的。
这不仅关乎您在做什么。从现在开始六个月后需要加快代码编写速度的新员工呢？从现在开始从事该项目的每个人都离开现在的五年后呢？ 为以后加入该项目的任何人提供一些基本的最新文档非常有用。我不主张使用带有方法名称和参数的完整的UML图(很难维护)，但我确实认为系统中各组件之间的关系和基本行为的基本图非常宝贵。除非系统的设计发生重大变化，否则即使对实现进行了调整，该信息也不会发生太大变化。 我发现文档编制的关键是审核。没有人会在不睡着几页的情况下阅读50页完整的带有设计文档的UML图。另一方面，大多数人都希望获得5-10页的简单类图，其中包含有关如何实现的基本描述。系统放在一起。 我发现UML有用的另一种情况是，当高级开发人员负责设计组件，然后将设计交给初级开发人员实施时。
在足够复杂的系统中，有些地方认为某些
系统的有用图因适用性而异。
有许多企业向他们发誓，许多企业则完全拒绝他们，这是在浪费时间和精力。 最好不要全神贯注，以为您所从事的项目最适合自己，并选择适用且有意义的内容。 使用UML就像走路时双脚注视。它使您通常可以在不知不觉中完成有意识和明确的事情。初学者需要仔细考虑他们在做什么，但是专业的程序员已经知道他们在做什么。在大多数情况下，编写代码本身比编写代码更快，更有效，因为它们的编程直觉适合于任务。 唯一的例外是为什么您晚上没有火把就在树林里，天开始下雨了-那么您需要注视自己的脚以避免跌倒。有时候，您执行的任务比您的直觉所能处理的更加复杂，因此您需要放慢速度并明确说明程序的结构。然后，UML是可以使用的许多工具之一。其他包括伪代码，高级体系结构图和奇怪的隐喻。 通用的工作流程和DFD对复杂的流程非常有用。根据我的经验，所有其他图表(尤其是UML)无一例外地浪费了时间和精力。 我不得不不同意，UML到处都在使用-在设计IT项目的任何地方，UML通常都会存在。 现在，是否使用得好是另一回事。 正如Stu所说，从开发人员的角度来看，用例(以及用例描述)和活动图都是最有用的。 当试图显示关系以及对象属性(例如持久性)时，类图可能非常有用。当涉及到添加单个属性时，它们通常是过大的，特别是因为一旦编写代码，它们通常很快就会过时。 UML的最大问题之一是一旦生成代码就使它保持最新状态需要进行大量的工作，因为很少有工具可以从代码中重新构造UML，而且仍然很少能很好地完成它。 我将通过提及我在大型(类似于IBM)公司开发环境中没有经验来限定我的答案。 我对UML和Rational Unified Process的看法是，与其说要实际做，不如说要做什么。 (换句话说，这在很大程度上浪费时间)
仅在我看来，请扔掉。 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，他说"做足够的建模/架构/等"。随便使用您所需要的！ 从QA工程师的角度来看，UML图指出了逻辑和思想上的潜在缺陷。使我的工作更轻松:) 我认为UML很有用，因为我认为2.0规范使曾经明确的规范变得有些肿和麻烦。我确实同意时序图等的版本，因为它们填补了空白... 学习有效地使用UML需要一些实践。最重要的一点是要进行清晰的沟通，在需要时进行建模，并作为团队进行建模。白板是我发现的最好的工具。我还没有看到能够捕获实际白板实用程序的任何"数字白板软件"。 话虽如此，我确实喜欢以下UML工具： 紫罗兰色-如果再简单一点，那将是一张纸 Altova UModel-Java和C＃建模的好工具 MagicDraw-我最喜欢的商业建模工具 Poseidon-体面的工具，具有良好的性价比 尽管这种讨论长期以来一直没有进行，但是我想补充几个要点。 笨拙的代码是一回事。如果放任其流向下游，设计错误的确会变得肿而丑陋。但是，UML是自我验证的。我的意思是，它使您可以在数学上封闭且相互检查的多个维度中探索模型，从而实现了稳健的设计。 UML还有另一个重要方面：它直接与我们最强大的功能(可视化功能)"对话"。例如，如果已经以UML图的形式传达了ITIL V3(本质上很简单)，那么它可能已经发布在几十个A3折页上。取而代之的是，它以几个真正符合圣经的比例出版，催生了整个行业，惊人的成本和广泛的阳离子冲击。 UML图对于捕获和传达需求并确保系统满足这些需求很有用。它们可以迭代使用，并且可以在计划，设计，开发和测试的各个阶段使用。 来自主题：在开发过程中使用模型，网址为http://msdn.microsoft.com/zh-cn/library/dd409423%28VS.100%29.aspx
您可能还想阅读我对以下帖子的回复： 如何学习"良好的软件设计/架构"？在https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489 UML是有用的，的确是的！我使用它的主要用途是：
我只是不同意迈克尔所说的，他说对单个开发人员和/或一个简单的软件项目使用UML对他来说似乎太过分了。我已经在我的小型个人项目中使用了它，使用UML对它们进行文档记录后，七个月后我回到他们那里时，我节省了很多时间，并且完全忘记了我是如何构建和组合所有这些类的。 我对UML的问题之一是规范的可理解性。当我尝试真正理解特定图的语义时，我很快迷失在元模型和元元模型的迷宫中。 UML的卖点之一是它不比自然语言含糊。但是，如果两个或两个以上工程师对图的解释不同，则该图将无法达到目标。 另外，我尝试在几个UML论坛以及OMG本身的成员中询问有关超结构文档的特定问题，但收效甚微或没有收效。我认为UML社区还不够成熟，无法支持自己。 我相信，有一种方法可以利用Fowler在他的著作《 UML Distilled》中描述的Cockburn风格的UML鱼，风筝和海平面用例。我的想法是采用Cockburn用例作为代码可读性的辅助工具。 因此，我进行了一个实验，并在此处发布了带有标签" UML"或" FOWLER"的文章。对于c＃，这是一个简单的想法。找到一种方法将Cockburn用例嵌入到编程结构的名称空间中(例如，类和内部类的名称空间，或者通过使用名称空间进行枚举)。我相信这可能是一种可行且简单的技术，但仍然存在疑问，需要其他人进行验证。对于需要某种伪域特定语言的简单程序来说可能会很好，这些语言可以直接存在于c＃代码中而无需任何语言扩展。 如果您有兴趣，请查看该帖子。到这里。 我看到序列图和活动图使用得很频繁。我在与其他系统交互的"实时"和嵌入式系统上做了很多工作，顺序图对于可视化所有交互非常有用。 我喜欢做用例图，但是我没有遇到太多认为它们很有价值的人。 我经常想知道Rational Rose是否是从基于UML模型的设计中获得的各种应用程序的一个很好的例子。它肿胀，越野车，缓慢，丑陋，... 来自一个学生，我发现UML很少使用。具有讽刺意味的是，PROGAMERS尚未开发可自动生成您所说的必要内容的程序。在Visual Studio中设计一个功能非常简单，该功能可以提取数据片段，寻找定义和足够的产品答案，以便任何人不论其大小都可以理解它并理解程序。这也将使其保持最新状态，因为它将直接从代码中获取信息以产生信息。 我发现UML对于很小的项目并不是很有用，但是对于较大的项目却真的很合适。 本质上，使用什么并不重要，您只需要记住以下两点：
因此，UML就是这样：关于如何计划项目的标准。如果您雇用新员工，则更有可能知道任何现有标准-无论是UML，Flowchard，Nassi-Schneiderman，还是其他任何东西-而不是您现有的内部人员。 对一个开发人员和/或一个简单的软件项目使用UML对我来说似乎有些矫kill过正，但是当在更大的团队中工作时，我肯定会想要一些软件规划标准。 尽管它只是一种UML图，但只要您使用其字段和方法表示一个类，就会使用UML。 UML的问题在于创始人书太含糊。 UML只是一种语言，实际上不是一种方法。 对于我来说，我真的感到很烦人的是，开源项目缺少UML模式。以Wordpress之类的东西，您只有一个数据库架构，仅此而已。您必须在Codex api上四处徘徊，以尝试大致了解。 UML占有一席之地。随着项目规模的增长，它变得越来越重要。如果您有一个长期运行的项目，那么最好用UML记录所有内容。 对于拥有大量人员的大型项目，UML似乎非常有用。但是，我曾在小型团队中工作，这些团队之间的交流更好。 但是，使用UML风格的图表是很好的，尤其是在计划阶段。我倾向于在代码中思考，因此我很难编写大型规范。我更喜欢写下输入和输出，而让开发人员在中间进行设计。 我相信UML仅对于它使人们思考类之间的关系这一事实有用。这是开始考虑这种关系的良好起点，但绝对不是所有人的解决方案。 我相信，UML的使用取决于开发团队正在工作的情况。 UML通过两种方式有用：
通常，所有没有UML图表的项目都具有肤浅的分析，或者规模较小。 如果您位于linkedin组SYSTEMS ENGINEERS中，请参阅我的旧讨论。 在我的经验中： 对于正在开发新代码或试图理解现有代码的任何软件工程师来说，创建和传达有意义的代码图的能力是一项必备技能。 知道UML的详细信息(何时使用虚线或圆形端点)并不是必须的，但是仍然很高兴。 最后，UML仅由于RUP而存在。我们是否需要UML或其任何相关内容才能使用Java / .Net？实际的答案是他们有自己的文档(javadoc等)，这足以使我们完成工作！ UML No thanx。 正如junit是必不可少的一样，UML绝对有帮助。这一切都取决于您如何推销创意。您的程序将在没有UML的情况下工作，就像在没有单元测试的情况下一样。话虽如此，您应该在连接代码时创建do UML，即，当您更新UML图时，它会更新代码，或者在您更新代码时，它会自动生成UML。不要仅仅为了做到这一点而做。 UML在行业中占有一席之地。想象一下，您正在为Boing飞机或其他复杂系统构建软件。 UML和RUP将在这里提供很大的帮助。 不，不是。代码是最好的沟通方式。其他一切都适合那些进入错误行业并决定对其进行更改以适应他们的大脑的人们。 接口大大优于类图。用例图将用户需求融合到一种形式中，破坏它们并告诉您如何设计产品。数据流程图和ER图使创建数据库的过程复杂化。有时您可能想绘制图表来传达您的观点，但是除了其他人可以理解它们之外，没有任何理由它们必须是UML图或符合任何标准。 最后，这些都是大型，无用，官僚的"软件"公司的所有形式的文档，这些公司生产的XML糟糕的产品。也就是说，如果他们完成了记录。确实，大多数员工并不关心自己的工作，只是在等待上方的人死亡，以便获得升职。
UML只是人与人之间交流的方法之一。 |
