UML建模 - 在某些时候它是否在实践中成为伏都教科学？

Question

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

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

本学期我正在进入更深入的UML课程，即领域分析，需求分析，软件设计与软件工程等。

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

Answer 1

开始伏都教。绘图软件设计一直都是这样。这是一种在图片中显示您想要用人类语言设计的内容的方式。如果它足够精确以生成代码，我们将继续这样做并完全免除编码步骤。

UML唯一为旧方式带来新功能的是它是一个标准。即便如此，还有很多不同类型的“标准”图表，在将其称为标准时，我不得不嗤之以鼻。

然而，除了最微不足道的任务外，设计本身的活动非常重要。问题是，在编写了大量错误或不确定的代码之后，您是否要花一些时间预先设计系统，或者是否要在运行中进行。如果你想快速和/或好地完成任务，你可以预先做一些设计。

这不仅适用于编写BTW软件。它是任何复杂创意活动的固有部分。我的岳父，一位退休的英语老师，在他去度假时给孩子们写了一张长长的明信片，实际上是为他的明信片写了大纲。大多数大师画家和雕塑家首先制作测试图纸。

Answer 2

没有

各种形式的文档只能作为一种交流手段。文档的文档是完全浪费时间。

编写UML只有在附带文档解释（在单词中）您想要什么，为什么以及如何解释时，它才有用且富有成效。只有这样UML才能帮助说明你想在文档中说些什么。

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

Answer 3

你开始使用建模，这是一件很棒的事情，特别是在计算机科学方面 - 你一直在建模。请记住，UML是软件系统建模符号的标准，仅此而已（例如，它不是分析或设计方法），也不是更少（例如，它不是开发人员通过绘制废话看起来高效的方式）。

你走在正确的轨道上，始终牢记实际有用的东西并给你一些价值。这与你的问题并不完全相关，但起诉案例不是用例图，还有更多，有书面形式，可能会帮助你完成你在下一门课程中所描述的内容。

至于你的顾虑，建模是从不重要的细节中抽象出来的，因此可能会出现一些含糊之处。关键是它们对于建模而言应该不重要。例如，如果要显示类的所有属性，如果要显示设计结构，则无关紧要。使用一些模式。如果它们是包含getter和setter（Java），属性（C＃）的私有字段或使用元编程（Ruby）生成的对象方法，您也可以使用公共属性而不关心自己。对于使用用例捕获的场景也是如此 - 当然你不能（也不应该尝试）使用UML捕获备用分支，但是你可以在用例描述中描述条件，足以避免歧义而不必先开发系统和之后发现它是错误的。

至于伏都教的问题 - 问题是UML很大，很多开发人员都不知道如何正确使用它，而且经常造成比价值更多的混乱。不要因为对UML的普遍不尊重而感到困惑，问题出在工具供应商，委员会和懒惰的开发人员身上...... UML中的许多概念背后都是众所周知的正式模型，由学术科学工作支持，例如：状态图来自Harel statecharts（http://linkinghub.elsevier.com/retrieve/pii/0167642387900359）。所以我认为它原则上没有那么多伏都教，它只是超卖了不支持标准的工具，而且标准试图将所有东西组合在一起（它是一种统一的语言......），但这种情况会慢慢改善。

我对你的建议是尝试学习什么是重要的 - 那些形式主义，分析和设计方法，实际尝试它们并自己决定什么是有用的。如果没有其他原因，学习UML是因为它是分析和设计的语言，虽然很大，但它仍然比它的~50个前辈组合好:)。

Answer 4

根据我的经验：不是。

我从未遇到过非常有用的序列图。当记录的过程变得过于复杂时，序列图不再有用，因为您很难跟踪所有行。但要理解一个简单的过程，我不需要序列图。当用作设计工具时，您将浪费大量时间来调整图表，诅咒MS Visio或您使用的任何内容。

然而，当在白板上讨论某些内容时，该符号对于小快照非常有用。但这适用于任何符号样式; UML已经很成熟，增加了你被正确理解的机会。

类图在设计和后验文档中都很有用。但恕我直言，你不应该对他们太迂腐。

Answer 5

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