所以我和我的老师一起参加了几个研究项目，他喜欢UML类图。使用它们构建一个保存在数据库中的非常复杂的数据结构（表示可以根据现实世界问题的物理变化的图形）
我发现UML并不仅仅是在初始阶段之外使用。我发现有5个人，多学科，UML将建成。然后当编程开始时，必须更改UML。一遍又一遍......然后发生的事情是UML会因为需求而超出项目进度，然后发生可能发生的更糟糕的事情......陈旧的评论。
其他人有同样的感受吗？有更好的工具吗？在我的下一个项目中，我决定采用不同的方式。定义所有不同用户交互的流程图。然后程序被编程为流程图而不是UML图的结构。我发现我不必改变任何一个的结构，新的人更快地理解程序。
这是一个很好的方法，因为程序增长超过30k行代码？ 50K？ 10万？
在UML防御中，我会说这个。用UML构建程序可以让您更快地发现设计模式。哪个非常好。
有人有任何意见吗？
答案 0 :(得分：1)
如果将它与Java语言一起使用，那么类图绝对是神奇的。我能够建模，生成代码，更改我的代码，重构它再次与UML等合并..;从来没有问题，总是一个完美的更新文档。 对于数据库创建，我使用带有hibernate的java注释，这是从我的类图中创建的。
真的很棒！
答案 1 :(得分：0)
我个人认为UML类图最适合低级设计。最好将高级设计细节保持抽象......
真的找到了这个答案UML Diagrams - Discussion非常好。
答案 2 :(得分：0)
许多开发人员认为在U.M.L.制作设计/模型。或其他，将留下来。改变图表非常frecuent。由于时间和原因，一些开发人员在初始版本之后跳过更新图表。资源限制。
我的建议是你应该习惯于制作软件应用程序的想法。是复杂的，它会非常频繁地改变，而不是建筑师制作他们的UML（“蓝图”）的建筑，而且一旦基于UML设计的程序（“建筑”），它就会保持这种状态。
使用几个增量原型版本，包括建模和编程，而不是考虑单个复杂的应用程序，可以适用于您的软件团队。
说实话，建筑物及其蓝图也可能不像软件应用程序那样频繁，但是，他们确实如此。
答案 3 :(得分：0)
迈克尔，
你的老师似乎死于UML Fever（Article Link）： - ）
许多人对UML有“错误”的理解。（它是什么，不是什么）
UML只是标准图表符号框，行等。使用通用符号的可视化建模可以是一个很好的帮助，但它不像知道如何在对象中进行设计和思考那么重要。这种设计知识是一种非常不同且更重要的技能，和不是通过学习UML符号或使用CASE或MDA工具来掌握的。 没有良好的面向对象设计和编程技巧的人绘制UML只是绘制糟糕的设计。 应用UML和模式：面向对象的分析和设计与迭代开发简介，第三版作者：Craig Larman [ 1.6。什么是UML？] ）
还有关于绘制UML图的“错过理解” （何时绘制图表以及谁将绘制图表）
有用的UML由经验丰富的OO程序员（理想情况下在白板上成对）勾勒出来，作为创意思考和沟通的辅助，然后他们自己使用他们自己的草图 * < em>作为灵感 *在编程期间。 ...... 重要的是能够创造出良好的物体设计和程序 - OOA / D的艺术。当橡胶遇到困难并且需要削减代码时，重要的是我们的能力分配责任并创建低耦合，高内聚，易于理解和易于修改的设计。 这与知道诸如UML之类的图表符号非常不同。（ Craig Larman，UML是什么，不是 Article Link < / em>的）
许多人认为UML只有一个图表:(或者只是一个有用的图表）类图。这也是错误的。
范例的名称是面向对象建模/设计/编程/。 不是以班级为导向 ...... 类图只显示了类之间的静态关系。你无法理解一个真正面向对象的系统，只是看它的“静态”结构。
面向对象程序的运行时结构通常与其代码结构几乎没有相似之处。代码结构在编译时被冻结;它由固定继承关系中的类组成。 程序的运行时结构由快速变化的通信对象网络组成。实际上，这两种结构在很大程度上是独立的。 试图从另一个中理解一个就像试图从植物和动物的静态分类中了解生态系统的活力，反之亦然。 [设计模式，可重用面向对象的元素由Erich Gamma，Richard Helm，Ralph Johnson，John Vlissides编写的软件[关于运行时和编译时结构]
因此，使用序列或通信来探索这些交互，digrams也很有用。
作为一项规则:(如此简单，如此遗忘的规则）
如果您正在绘制图表，您应该有充分的理由：为什么要这样做？如果你没有具体的答案（答案必须显示真正的好处），不要画任何东西。建模不是文档活动。并且吃自己的狗的食物。为自己画画，而不是为他人画画。