你还使用UML吗？ 怎么样？ 做什么的？
几年前，我们店里的每个人都对UML很疯狂 。 现在每个人似乎都冷清了。
如果在软件项目中仍然广泛使用UML，我很好奇。
如果是这样，这个用法是否仅限于白板？ 你使用它的文件？ 你使用工具从它生成的代码？
有关：
UML是否实用？
我更喜欢敏捷地采用UML（例如白板草图）来适应UML的瀑布 （例如，在Visio中绘制精细图表的过多文档）。
UML对于向其他人解释devise仍然有用。 例如，复合devise模式很容易用简单的类图来解释（也就是说，在完成这些有趣的类比之后）。
一些手工绘制的课程和顺序图很方便，可以在遇到一个遍布各处的新课程或旧课题的时候快速入门，而且没有足够的文档资料。
我的团队也成功地使用类图生成数据库模式。 也许有更好的办法，但这是另一个问题。
我一直使用UML（或UML ispired）graphics作为支持文档。 这些文件提供了一个时间片，例如“这是我们最初的用户概念”。 保持文件是最新的是很难的，只有当我们需要改变我们的定义。 然后我们又有一个快照。 UML不是devise，而是devise过程的一部分。
我使用了一些使用UML的代码生成工具，但仅用于生成初始存根。 通常一旦生成代码，就会从图中分离出来。
UML的一个问题是，在许多情况下，关于适当的UML语法/风格的争论爆发了，而不是集中在绘图是否帮助客户，分析师或开发人员理解这个概念。 我知道语法在代码生成时很重要，但是我发现UML最好用来理解一个概念。
参见SO：UML是否实用？ 对这个话题有更多的回应。 看起来UML对交stream概念和系统仍然有用。 人们似乎用它来描述，而不是一个定义。 如果你将UML从实现本身分离出来，你将会遇到麻烦，使两者保持同步。
我使用UML进行初始devise，并在与其他开发人员交谈时帮助进行讨论。 但是，除了最初的devise之外，试图保持UML更新的时间是不值得的。
我已经看到生成的UML用来帮助新员工处理一个非常复杂和复杂的系统。 由于UML是从代码自动生成的，所以它始终是最新的，有些人认为它是有帮助的。
UML已经死了，已经死了，死了： UML真的死了，还是只有感染？
白板/文档可以。 从它生成代码？ 谁需要这个和为了什么？
我实际上使用UML来帮助我形象化和思考问题。 为此，序列图，活动图和对象图非常有用。
当您尝试传达软件层时，组件图很好。
部署图对于确定打包和部署以及节点间通信path非常有用。
类图我觉得最没有用，因为大多数IDE可以很容易地给你构build的类层次结构。
我使用UML与其他开发人员进行讨论。 我常常想，我通过图片将信息传递给其他人更加成功，因此，在与其他人进行头脑风暴时，我会在白板上绘制class级图或活动图。 其他成员可以绘制和修改它，一旦我们都知道我们在说什么，我们往往只是滚动它。 我们没有直接从它生成代码（部分原因是我们的工具很糟糕），但另一方面，如果我们做了，我们可能会感到更加紧张。 自白板以来，这些devise改变了很多。
如果你使用敏捷，你应该使用UML。
build模很重要。 如果你写代码当然更有趣，但是你浪费时间，不知道你是否正在考虑客户的要求。 您可以通过build模来了解您要求解决的问题，并加快开发时间，并向您的客户提供有用的产品。
节省过高的怪物电缆镀金。
我们仍然使用UML。 和其他人一样，我发现他们极大地帮助沟通。 当他们有视觉帮助时，人们更容易沟通（inputPowerPoint的受欢迎程度）。 在一个像firebird84这样的场景解释发生了很多的项目的最初阶段尤其如此。 一旦项目的开发人员开始编码，UML的艰辛的一面就是维护图表。
虽然我们不生成代码，但我还没有亲自与使用过UML的人说话。
我每天都使用类图来讨论模型，对象和模式。 这实际上引发了DBA的closures，直到你指出你可以通过将所有的箭头滑到行的另一端来从类图派生ERD …箭头仍指向同一个方向。 在那里，现在它描绘了一个FK。
这两种图表之间有很多不同的结构和语义细节，但箭头转换似乎清除了心理障碍。
J / J是一个很好的参考点，因为没有任何努力来生成UML，它只是在你的Java代码旁边。 有趣的看看，如果我在使用UML的时候是“免费”的话。
我觉得它有用吗？ 说实话，我发现它作为一个额外的视觉保证是有用的，并交叉检查我所做的devise正在形成，并作为一个视觉编目工具。 我没有想到基于图表的具体逻辑或模式。 好吧，也许有时候我做了。
这值钱吗？ 这让我感觉良好。 它看起来让人印象深刻。 它想了解我正在做的事情的清单，想了一会儿。 这让我更多地思考整洁和朴素，一切占据屏风的东西。 这让我问，我真的需要这个属性，还是我可以做到整洁？ 它偶尔帮助我“用UML思考”。
有了更多的经验，我现在可以使用Together / J吗？ 现在我会花时间从头开始构buildUML吗？
那么当我看看我实际上为一个项目做了什么，它包括编写UIdevise，数据库模式和通信协议，考虑用例和内存使用，带宽使用和安全性。 事实上，几乎所有可能的考虑，除了面向对象/ UML。 而且我不使用Together / J。
为什么是这样？
这是因为我现在已经从UML内化了我的学习。 我现在专注于实现devise的速度，空间和时间效率。 我的devise受到UML原则的高度限制，所以值得我学习，但是我没有使用实际的UML图或者UML。
UML只是假设; 一个给定的。 或者说它对devise的影响是。
我现在在屏幕上是纯代码和数据。 我也有成就感。 🙂
取决于你正在绘制的内容和目的（假设你使用UML作为一种可视化build模语言，而不是那种不那么常见的抽象forms）。
如果与其他工程师沟通控制序列或类层次结构，则UML图是理想的。
将macros应用程序架构传达给客户或高级技术经理，您可能会发现，无论您需要多么有效，
请参阅“ logging软件体系结构” ，以获取有关架构视图的一些常用图表的很好的UML缺陷摘要。
另外一个提示 – 使用一个文本工具，比如出色的PlantUml – 有一个非常简单的DSL学习，然后你可以专注于意义，而不是强迫Visio绘制直线或者使用巨大的过度工程CASE工具。 检入PlantUml模型以进行源代码pipe理，并设置CI作业以自动构build和发布SVG或PNG。
我把它用于用例图表。 没有太多其他的东西。
我也使用UML进行初始devise。 在完成需求阶段和用例（UML和文本forms）之后，基本系统作为一个组件图进行布置，以识别单个组件，接口以及子系统。
我们只是在项目开始时才使用UML类图，而且在向其他开发人员解释我们自己的代码的时候。 但是这只是勉强，而不是logging我们的软件。
在我看来，关于UML（被人们，杂志）所讨论的很多，但并不是很多人真正使用它。
我决定我喜欢Fowler在他的书“UML Distilled”中描述的Cockburn风格的用例。 我非常喜欢它们，所以我devise了一种将它们直接embedded到C＃命名空间的实验性方法。
通过这样做，我可以根据用例的英语语言内容免费编码业务或UI逻辑，而无需编写任何types的域特定语言。 最直接的好处是我改进了代码的可读性（albiet以一种非常新颖和深奥的方式）。 这仍然是一个实验性的方法。 不过，我相信这可能是有用的。
这里是我发布的问题的链接，试图find其他方式来做我做的事情。
我认为传统的UML已经死了。 我的意思是静态的UML，它花费了几个月的模型需求build模和代码生成。 我们不能再等一个多星期才开始编码，因为我们必须更快更快地交付我们的项目。 如果你模型然后生成一个代码，生成的代码通常是如此糟糕，你需要修复它。 我花了更多的时间修复脏UML生成的代码几年前，而不是写一个干净的新代码。
我认为MDD（例如模型驱动的开发）已经死了，但不是UMLgraphics符号。 我仍然每天都在使用它，它运作得非常好。 当我得到新的要求，我立即build模成类图。 我首先反转现有的项目，然后创build新的元素并将其与现有的代码合并。在我现有的项目中创build我的需求的骨架不超过2个小时。 我喜欢用类图创build我的骨架，因为它提供了更高级别的抽象和代码。 真的很酷。 我使用Omondo EclipseUML，我为这个工具制造，对于其他供应商抱歉，但是这个工具改变了我的生活。 我每天两次将我的项目与离岸团队合并，重新创build新的图表。 这不是自动的，因为我更喜欢在接受提交之前检查代码。 我检查了编译和对象方法，只有UML能够给我一个已经完成的工作，如何添加胶水以及在哪里添加胶水以支持新的需求。 我很高兴，因为我不再使用肮脏的MDD代码生成，而是可以专注于UML符号和质量代码。
我觉得ULM对我无用，这伤害了我的创造力。 如果客户需要的话，我只生成UML文档。 但是我不使用它来build模。 build筑是一个不断发展的过程，我一遍又一遍地思考，不pipe在办公室里，我到处都有新的想法。 我经常重构，以接近最佳状态，首先考虑到代码。 希望我明白我的意思。
