你还使用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在办公室里,我到处都有新的想法。 我经常重构,以接近最佳状态,首先考虑到代码。 希望我明白我的意思。