我正在设计一个新系统，并发现我正在努力解决我想要做的事情。一个症状是，每次我重新解决问题时，我都必须尝试在纸上绘制组件的关系。 （我不清楚这些组件究竟是什么或关系是什么 - 例如我设法删除了一个没有做任何事情的组件。）
UML是一种有用的前进方式吗？我曾经非常怀疑并尝试早期版本，其中生产版本花费太多钱。现在我看到Netbeans中有一个插件，除其他外有很好的模式选择（仅此一点可能会让它值得一试）。
我已经阅读了SO上的大多数顶级帖子，似乎没有一个非常明确的共识。我的背景是，这与研究有关，而不是为客户编码，因此主要目的不是记录最终产品，而是帮助我清醒（并可能编写一些简单的结构）。
如果任何答案支持UML，那么建议提高效率所需的时间以及使用频率将是有用的。 （作为参考，我每天都使用测试，记录器和调试器。）
SUPPLEMENTARY UML软件中是否有任何内容可以强制执行代码和图表之间的一致性（在任何级别）。我假设，当创建一个StrategyPattern时，它可以生成存根代码。但是，如果模式被破坏，UML工具会检测到这个吗？
答案 0 :(得分：9)
Martin Fowler是恕我直言：
听起来你大部分倾向于第一个，而第二个的顺序。选择一个并相应地设定你的期望肯定会有所帮助 - 你不能期望在3分钟内执行草图或产生可执行的蓝图。
它是否适合你取决于一系列的事情：
答案 1 :(得分：4)
UML不会让你的代码变得更好，但可以提高你对你正在做的事情的看法。
这不是关于UML是否对编写代码有用，而是关于 UML的真实目的，使您能够想象您想要做什么，系统是什么样的< / strong>即可。
你需要一个比喻，一个故事来传达你的工作。稍后加入该项目的开发人员将需要这样做以更好地理解您的代码，在查看详细信息时获得正确的上下文并最终不会破坏内容。
不要让自己被工具所欺骗。 UML本身不是一个解决方案，它只是一种形式化方法来解决一个常见问题：编写声音系统。
答案 2 :(得分：2)
如果你发现UML有用的额外信息 - 聚合/组合，关联的刻板印象等，那么就使用它而不是你当前使用的那些。
我没有找到适合早期设计的铅笔和纸张的工具;在纸上绘制UML草图仍在使用UML。
补充是否有任何UML软件可以强制执行代码和图表之间的一致性（在任何级别）。我假设，当创建一个StrategyPattern时，它可以生成存根代码。但是，如果模式被破坏，UML工具会检测到这个吗？
有许多不同的UML工具，有些具有不同程度的约束检查。通常这仅限于UML语法，但也有object constraint language可用于对UML模型进行断言，并且一些工具可以生成代码以在运行时测试这些断言。 （这里的东西有点模糊，因为我从来没有在一家愿意为这些工具买单的商店工作，因为它们不便宜，而且更常用于嵌入式系统，我的大部分工作都是技术计算。）因此，如果您购买了支持将OCL映射到代码生成的高端UML工具，请在工具中设置构造型以表示策略模式，然后生成包含这些断言的代码（如果它们是运行时）或将断言应用于模型中的结构（如果它们是元模型断言）。 （我不太确定这些工具是否允许你对元模型编写约束 - 即断言策略必须提供一个函数而不仅仅是断言前后条件，但是这样的断言也会被类型系统检查大多数语言，如果你把方法抽象为策略的超类型，无论如何）。如果您然后对代码进行反向工程并且它打破了约束，那么它将被工具标记。问题在于构成某些模式的示例在某种程度上取决于开发人员的意图，而不是可以对所创建的结构断言的任何内容。
答案 3 :(得分：1)
在我看来，你说的是UML，但实际上是在谈论UML的一些代码生成。这是两件截然不同的事情。
UML非常有用，因为它是一个事实上的标准，所以如果你绘制两个带有箭头的矩形，它们之间有一个三角形点。几乎每个开发人员都知道你在谈论继承。
UML工具是一个不同的故事：有些是便宜而有用的：例如纸，铅笔和橡皮擦。
用于从UML图生成代码的工具（或更精确的UML模型）有时很昂贵，而且（恕我直言）总是无用的。问题是，代码中有趣的部分需要所有细节，在图形模型中输入所有这些细节的速度非常慢。文本编辑器对于这种东西更有用。即使对于简单的东西，比如属性和引用，它也会强制极其严格地使用UML，这很痛苦。想象一下，每当你不使用完美的牛津英语时，一位英语老师会把你打断。
我认为有用的工具是允许您以自由方式绘制UML图表的工具（Enterprise Architect，Visio，Whiteboard）以及从代码中创建UML图表的工具。喜欢这个IDEA插件http://plugins.intellij.net/plugin/?id=3202 （这是由我的同事完成的，所以我有偏见）
答案 4 :(得分：0)
我可以看到两种使用UML的方法：正式捕获设计，并非正式地勾勒出设计的某些方面，以帮助设计过程。
前者对于拥有设计师团队的大型项目特别有用。它需要一些纪律和时间，但我认为更接近于在文本中捕获信息 - 模型确保一致性。如果完全完成，您甚至可以从模型生成代码。这个appraoch确实有效，但显然需要很多启动工作。
后者可以更加非正式。甚至可能仅仅为了一个开发人员的利益而捕获设计中棘手的部分，似乎也可以工作。我经常这样做。我发现用类图“玩”确实有助于澄清责任。而我只想记录类和属性，这样可以节省时间。一些提供UML作为实际代码中类的替代视图的工具非常好。
在一个合理的工具中绘制类图的阶段应该是几小时或几天的学习任务 - 假设熟悉Object概念。学习对象设计是一个完全不同的问题。
答案 5 :(得分：0)
使用铅笔和纸
答案 6 :(得分：0)
在我看来，UML对于在大型团队中的大型项目中工作非常有用。 通过使用UML，您可以通过“在编码之前思考”来创建一个非常好的架构。
稍后您可以考虑图表，如果您已按照自己的意愿完成所有工作。
尽管如此，知道你的项目实际有多大以便给你一个好的答案会很高兴吗？
答案 7 :(得分：0)
UML作为不同人之间的通用语言，以便所有人都能描述同一个域。
对于代码和算法设计，铅笔和纸张总是最好的方式，正如Omu所说。
答案 8 :(得分：0)
就个人而言，我认为你从错误的起点接近这个问题。你
[是]挣扎着结构 我想做的事。一个症状是......它不是 但在我的脑海里清楚地知道这些是什么 组件正是或者是什么的 关系是 - 例如我 设法删除了一个没有的 做任何事情。
如果您正在努力了解您的设计所做的系统应该做什么，或者它是如何工作的，那么这表明您已经开始或即将开始，没有明确的规范。这可能听起来很陈腐，但是如果你在开始编码之前没有解决这些误解，那么当系统构建并需要具有功能，流程，关系或交互时，你可能会为自己创造一团糟。添加或删除，因为它不能满足客户的需求。
首先清楚地描述您认为客户想要的内容。把它交给客户，此时他/她（可能）会做什么，或说一些不讨好的东西，并指出你错过的东西。或者没想到很重要。并且当他想要'a'，'b，'c'和'x'时，问为什么软件会'x'，'i'和'r'。
在这一点上，客户还要记住他不能没有的超级特征“M”。
规格可以节省您的时间和精力。甚至在铅笔和纸张UML或流程图之前。
只是为了支持我所说的一些内容：Painless Functional Specifications，作者Joel Spolsky。通读，这是令人信服的。
答案 9 :(得分：0)
就个人而言，由于已经提到的原因，我避开代码生成或往返（例如，编辑器对于细节更自然）。我发现更容易看到模型并编写代码。我使用它的唯一一次是使用ObjectDomain，我认为我使用它的一半原因是使用Jython，因为它们的代码生成基于编写扩展类来遍历模型并生成类。
如果您试图弄清楚代码库的结构，那么从代码生成模型很有用。这对于基于Java的项目通常很有用，因为UML非常适合具有内省的OO语言--C ++完全是一个不同的故事。 UML环境的质量在这里有所不同，但代码库本身也是如此。我知道C ++模板的表示是很少有建模环境正确的。我希望Java泛型会出现类似的问题。
我将UML用于几个不同的目的：
有趣的是，我为每一个使用不同的工具。我已经完成了许多建模者（粗略的时间顺序）：Objecteering，ObjectDomain，Visio，ArgoUML，Poseidon for UML和{{3 }}。我在大多数情况下使用Visio和MagicDraw。
当我处于设计阶段并思考系统架构或更详细的设计时，我使用UML作为正式工具，因此我使用了真正的建模器 - MagicDraw。我发现构建UML模型是捕捉我思想的好方法。在这里使用真实建模师的一个副作用是它迫使我思考方法和结构，而不仅仅是流动。当我正在努力使获得正确的设计时，我强迫自己在最正式的意义上使用UML。确保精确建模 - 例如：异步操作最好建模为信号和接收。我很长时间都在挣扎。 这里的关键是理解正式的UML以及我选择的建模工具如何代表每个概念。这可能是这个长期咆哮中最重要的一点。
当我使用UML作为临时通信工具，试图向同事描述某些内容时，最有效的工具实际上是白板和标记。我发现正式的UML在这里没用 - 只是基本的结构图和序列图的东西。令人惊讶的是，其中一些已通过拍照手机保存并邮寄以描述各种概念......如图所示。
在文档中嵌入UML图通常涉及Visio，尽管我从不使用官方的UML建模支持。请改用MagicDraw。 Visio的UML模型模式在很多方面被打破，实在是不值得花钱。但是，使用Pavel的模板，可以快速轻松地执行特殊的UML图表。这里的另一条建议是使用Pavel Hruby's stencil代替vector graphics format用于图片本身。像许多其他人一样，我的公司被Microsoft Office病毒感染，因此我几乎坚持使用Word来处理文档。在这种情况下，我使用raster format作为我选择的图像格式。如果您在DocBook环境中工作，请改用Enhanced Metafiles (*.emf)。