UML建模——它在实践中是否成为巫毒科学？

我正在寻找对建模的见解。我有一门关于设计模式、基本类图、序列图和用例的入门课程

在我的编程中，我发现类图作为组织工具是非常宝贵的。到目前为止，用例还相当有用

本学期我将学习更深入的UML课程，即领域分析、需求分析、软件设计与软件工程等

---

当我们开始尝试精确处理场景中的模糊性和不断变化的需求时，有一种特定的感觉，即这开始变得更加巫毒科学或不具体。UML过去的基本类图和用例图在大多数应用程序中是否在生产力方面实际有用

不在MHO中。就我而言，这完全是多余的。

它起源于伏都教。绘制软件设计图一直都是这样。这是一种用人类语言在图片中展示你想对设计说些什么的方式。如果它足够精确，可以从中生成代码，我们将继续这样做，完全不需要编码步骤

UML给旧方法带来的唯一新东西是它是一个标准。即使如此，有这么多不同类型的“标准”图，当我称之为标准时，我不得不窃笑一下

然而，除了最琐碎的任务外，设计活动本身对所有任务都极其重要。问题是，在编写了大量错误或不必要的代码之后，您是打算花一些时间提前设计您的系统，还是打算动态地进行设计。如果你想把事情做得快和/或好，你可以先做一些设计

顺便说一句，这不仅仅适用于编写软件。它是任何复杂创造性活动的固有部分。我的岳父是一位退休的英语教师，他在度假时给孩子们写了一些很长的明信片，实际上他为明信片留言写了提纲。大多数大师级画家和雕塑家都会先绘制测试图

所有种类和形式的文件，只作为一种交流手段有用。为了文档而编写文档完全是浪费时间

只有当UML附带了一个文档来解释您想要的是什么、为什么以及如何使用时，编写UML才是有用和高效的。只有这样，UML才能帮助说明您试图在文档中说什么

---

软件团队仅仅为了绘制正方形而产生无穷无尽的UML，这是在浪费时间。

根据我的经验：不太可能

我从未见过真正有用的序列图。当记录的过程变得太复杂时，序列图就不再有用了，因为您很难跟踪所有的行。但要理解一个简单的过程，我不需要序列图。当用作设计工具时，您将浪费大量时间调整图表、咒骂MS Visio或您使用的任何东西

然而，当在白板上讨论某件事时，这个符号对于小快照很有用。但这对任何符号样式都是有效的；UML只是建立得很好，增加了正确理解的机会

---

类图在设计和后期文档中都很有用。但是我认为你不应该对他们太迂腐。

你从建模开始，这是一件很棒的事情，尤其是在计算机科学领域——你一直在建模。请记住，UML是软件系统建模符号的标准，仅此而已（例如，它不是一种分析或设计方法论），也仅此而已（例如，对于开发人员来说，它不是一种通过胡说八道来提高效率的方法）

你走在正确的道路上，始终牢记什么是真正有用的，并给你一些价值。这与你的问题并不完全相关，但sue案例不是用例图，还有更多，它们都是书面形式的，可能会帮助你在下一门课程中描述的内容

至于您所关心的问题，建模是从不重要的细节中抽象出来的，因此可能会出现一些歧义。关键是，它们对于建模来说应该不重要。例如，如果要显示设计的结构（例如，使用某种模式），则是否包含类的所有属性并不重要。如果公共属性是带有getter和setter（Java）、properties（C#）的私有字段或使用元编程（Ruby）生成的对象方法，那么您也可以使用公共属性而不必担心自己。使用用例捕获的场景也是如此——当然，您不能（也不应该尝试）使用UML捕获替代分支，但您可以在用例描述中描述条件，以避免歧义，而不必首先开发系统，然后发现它是错误的

至于巫毒的东西——问题是UML很大，所以很多开发人员不知道如何正确使用它，并且经常造成比价值更混乱的局面。不要被对UML的普遍不尊重所迷惑，问题在于工具供应商、委员会和懒惰的开发人员。。。UML中许多概念的背后是由学术科学工作支持的著名形式化模型，例如，状态图来自Harel状态图(http://linkinghub.elsevier.com/retrieve/pii/0167642387900359). 因此，我的观点是，原则上它并没有巫毒教那么多，只是因为工具不支持该标准，而且该标准试图将所有东西结合在一起（它是一种统一的语言…），但这会慢慢改进

我给你们的建议是，努力学习什么是重要的——那些形式主义、分析和设计方法，实际地尝试它们，然后自己决定什么是有用的。如果没有其他原因，请学习UML，因为它是用于分析和设计的语言，尽管它很大，但仍然很有用