几年前，我们商店中的每个人都对UML感到疯狂。现在，每个人似乎都已冷静下来。

我很好奇是否在软件项目中仍然广泛使用UML。

如果是这样，这种用法是否仅限于白板？我们是否将其用作文档？我们是否使用工具从中生成代码？

有关的：

Is UML Practical?

解决方案

我将其用于用例图表。没什么其他的。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

我将UML用于初始设计，并在与其他开发人员交谈时作为讨论的辅助工具。但是，除了最初的设计之外，花费时间来保持UML处于最新状态是不值得的。

我也将UML用于初始设计。在完成了reqs阶段和用例(以UML和文本形式)之后，将基本系统布置为组件图，以标识单个组件，接口以及子系统。

我已经看到生成的UML用于帮助新员工掌握非常复杂的系统。由于UML是从代码自动生成的，因此它始终是最新的，并且有人发现它很有用。

参见SO：UML实用吗？有关该主题的更多回复。似乎UML对于交流概念和系统仍然有用。人们似乎将其用作描述而不是定义。如果将UML与实现本身分开，则将使两者保持同步会遇到麻烦。

UML死了，死了，死了：UML是真的死了，还是只有Cataleptic？

白板/文档还可以。从中生成代码？谁需要它，为什么？

我们仅在项目开始时才使用UML类图，这主要是在项目开始时使用，也有向其他开发人员解释我们自己的代码时使用的。但这只是草草，而不是记录我们的软件。

在我看来，关于UML(人们，杂志)的讨论很多，但是真正使用它的人并不多。

如果使用敏捷，则应该使用UML。

建模很重要。如果当然可以得到编写代码的乐趣，但是我们会浪费时间，并且不知道我们是否满足客户要求。我们可以建模以了解要求我们解决的问题，并加快开发时间，并将有用的产品交付给客户。

为价格过高的Monster电缆节省镀金。

我更喜欢UML的敏捷采用(例如白板草图)，而不是UML的瀑布式改编(例如，在Visio中绘制的过多复杂图文件)。

UML对于向其他人解释设计仍然有用。例如。使用简单的类图(即在完成这些有趣的类比之后)就可以轻松地解释复合设计模式。

面对新的或者旧的项目，而到处都是乱七八糟的类而又没有足够的文档说明时，可以使用一些手绘的类和序列图来快速入门。

我的团队还成功地使用了类图来生成数据库模式。也许有更好的方法，但这是另一个问题。

我在与其他开发人员的讨论中使用UML。我经常以为自己在通过图片将信息传递给其他人方面比较成功，因此在与团队其他成员进行头脑风暴时，我会在白板上绘制类图或者活动图。其他成员可以绘制和修改它，一旦我们都知道我们在说什么，我们就会倾向于使用它。我们没有直接从中生成代码的麻烦(部分是因为我们的工具太糟糕了)，但是另一方面，如果这样做的话，我们可能会感到更加受约束。自白板以来，这些设计改变了很多。

我一直使用UML(或者UML ispired)图形作为支持文档。这些文档提供了一个时间片，例如"这是我们最初的用户概念"。使文档保持最新是很困难的，只有在我们需要更改定义时才可以这样做。然后，我们又及时拍摄了快照。 UML不是设计，而是设计过程的一部分。

我使用了一些使用UML的代码生成工具，但仅用于生成初始存根。通常，一旦生成代码，它就会与图分开发展。

UML的一个问题是，在许多情况下，争论的焦点是适当的UML语法/样式，而不是专注于图纸是否帮助客户，分析师或者开发人员理解了这一概念。我知道语法在生成代码时很重要，但是我发现UML最适合用来理解一个概念。

实际上，我使用UML来帮助我可视化和思考问题。为此，顺序图，活动图和对象图非常有用。

当我们尝试交流软件层时，组件图非常有用。

部署图对于弄清楚打包和部署以及节点间的通信路径非常有用。

我发现类图最没有用处，因为大多数IDE都可以很容易地为我们提供构建时的类层次结构。

我们仍然使用UML。像这里的其他人一样，我发现它们极大地帮助了沟通。当人们有了视觉辅助工具时，交流变得更容易了(输入PowerPoint的受欢迎程度)。在项目的初始阶段尤其如此，其中firebird84之类的场景经常发生。一旦项目的开发人员开始编写代码，UML的艰辛工作就是对图表的维护。

但是，我们不会从中生成代码，我还没有亲自与使用过UML的人交谈。

我已经决定喜欢Fowler在他的著作《 UML Distilled》中描述的Cockburn风格的用例。我非常喜欢它们，因此我设计了一种实验方法，将它们直接嵌入Cnamespaces。

通过这样做，我可以根据用例的英语内容免费地对业务或者UI逻辑进行编码，而无需编写任何特定于领域的语言。最直接的好处是，我提高了代码的可读性(以一种非常新颖而深奥的方式来简化)。它仍然是一种实验方法。但是，我相信它可能会有用。

这是我发布的问题的链接，我试图找到其他方法来做我所做的事情。

我每天都使用类图来讨论模型，包括对象和模式。这确实使DBA陷入困境，直到我们指出可以通过将所有箭头the滑到直线的另一端来从类图派生ERD…箭头仍然指向我们同一方向。在那里，现在描绘了FK。

两种类型的图之间有许多结构和语义上的细节有所不同，但是箭头转换似乎清除了这种思维障碍。

Together / J是一个很好的参考点，因为它不花力气来生产UML，它只在Java代码旁边。有趣的是，我是否曾在UML那里免费使用过UML。

我在那里发现它有用吗？老实说，我发现它对我所做的设计正在形成中的其他视觉保证和交叉检查很有用，并且作为视觉分类工具。我没有考虑基于图的特定逻辑或者架构。好吧，也许有时候我做到了。

值得花钱吗？这让我对过程感到满意。在其他人看来，这给人留下了深刻的印象。考虑了一下我正在做的事情，这节省了一些时间。总的来说，它使我更多地考虑了整洁和简单，每个对象占据屏幕空间的方式。这让我问我是否真的需要该属性，或者可以使它更整洁？它确实偶尔会帮助我"思考UML"。

有了其他经验，我现在可以一起使用Together / J吗？我现在将花费时间从头开始构建UML吗？

好了，当我查看一个项目的实际工作时，它包括编写UI设计，数据库模式和通信协议，并考虑用例和内存使用，带宽使用和安全性。实际上，除了面向对象/ UML之外，几乎所有可能需要考虑的东西。而且我不使用Together / J。

为什么是这样？

这是因为我现在已经将我从UML中获得的知识内部化了。我现在专注于实现设计的速度，空间和时间效率。我的设计受到UML原理的高度限制，因此值得学习所有这些知识，但是我不再使用实际的纸制UML图或者在UML中进行思考。

只是假设使用UML；给定的。或者更确切地说，它对设计的影响是。

我现在在屏幕上看到的是纯代码和数据。我也有成就感。 :-)

我认为传统的UML已死。我的意思是静态UML，它花费了几个月的需求建模和从模型生成代码。
我们不能等一个多星期就可以开始编码，因为我们必须越来越快地交付我们的项目。如果我们建模然后生成代码，则生成的代码通常非常糟糕，我们需要对其进行修复。与写干净的新代码相比，几年前，我花了更多时间来修复UML生成的脏代码。

我认为MDD(例如，模型驱动的开发)已失效，但不是UML图形符号。我仍然每天都在使用它，并且效果很好。当我收到新的要求时，我立即将其建模为类图。我首先撤消现有项目，然后创建新元素并将其与现有代码合并，将需求框架创建到现有项目中不超过2小时。我喜欢用类图创建骨架，因为它为我们提供了更高层次的抽象和代码。真的很酷。
我使用Omondo EclipseUML，并且为此工具而生，对其他供应商表示抱歉，但此工具改变了我的生活。我每天两次与海上团队合并我的项目，并重新创建新图。这不是自动的，因为我更喜欢在接受提交之前检查代码。我检查了编译以及对象方法，只有UML可以让我了解已完成的操作，添加胶水的方式和位置，以支持新需求。
我很高兴，因为我不再使用脏的MDD代码生成，而是可以专注于UML表示法和质量代码。

我发现ULM对我毫无用处，这损害了我的创造力。如果客户需要，我只会将UML生成为文档。但是我不使用它来建模类。
建筑是一个不断发展的过程，在这里我会三思而后行，不仅在办公室，而且在我身边到处都有新的想法。
我一直在重构，以使其更接近于最佳状态，首先要考虑的是代码。希望我你明白我的意思。