UML是否实用？

Question

在大学里,我有很多设计和面向UML的课程,我认识到UML可以用来使软件项目受益,特别是用例映射,但它真的很实用吗？我已经完成了一些合作工作条款,看起来UML并没有在业界大量使用.是否值得在项目中创建UML图表的时间？另外,我发现类图通常没用,因为查看类的头文件会更快.具体哪些图表最有用？

编辑:我的经验仅限于10个以下的小型开发人员项目.

编辑:许多好的答案,虽然不是最详细的,但我相信所选择的是最平衡的.

Answer 1

使用UML就像走路时看着你的脚.它通过无意识的方式做出有意识和明确的事情.初学者需要仔细考虑他们正在做什么,但专业程序员已经知道他们在做什么.大多数时候,编写代码本身比编写代码更快更有效,因为他们的编程直觉可以适应任务.

这不仅仅是关于你在做什么.从现在起六个月内出现并需要加快代码速度的新员工呢？从现在起五年后,当前正在进行该项目的所有人都离开了？

为以后加入项目的任何人提供一些基本的最新文档是非常有帮助的.我不提倡使用方法名称和参数(WAY太难维护)的完整的UML图表,但我认为系统中组件的基本图表及其关系和基本行为是非常宝贵的.除非系统设计发生剧烈变化,否则即使实施调整,这些信息也不会发生很大变化.

我发现文档的关键是适度.没有人会阅读50页完整的UML图表和设计文档,而不会在几页内入睡.另一方面,大多数人都希望得到5-10页的简单类图,其中包含一些基本描述如何系统放在一起.

我发现UML有用的另一种情况是,高级开发人员负责设计组件,然后将设计交给初级开发人员实施.

Answer 2

在一个足够复杂的系统中,有些地方认为某些UML很有用.

系统的有用图表因适用性而异.但最常用的是State Diagrams,Activity Diagrams和Sequence Diagram.

有许多企业向他们发誓,许多企业完全拒绝他们,完全浪费时间和精力.

最好不要过分考虑你最喜欢的项目,并选择适用的东西并且有意义.

Answer 3

使用UML就像走路时看着你的脚.它通过无意识的方式做出有意识和明确的事情.初学者需要仔细考虑他们正在做什么,但专业程序员已经知道他们在做什么.大多数时候,编写代码本身比编写代码更快更有效,因为他们的编程直觉可以适应任务.

唯一的例外是为什么你会在没有火炬的情况下在夜间发现自己在树林中并开始下雨 - 那么你需要看看你的脚以避免摔倒.有些时候你所承担的任务比你的直觉所能处理的更复杂,你需要放慢速度并明确说明程序的结构.然后,UML是您可以使用的众多工具之一.其他包括伪代码,高级架构图和奇怪的隐喻.

Answer 4

通用工作流和DFD对于复杂流程非常有用.根据我的经验,所有其他图表(ESPECIALLY UML)都毫无例外地浪费了时间和精力.

Answer 5

我不得不反对,UML被广泛使用 - 在设计IT项目的任何地方,UML通常会在那里.

现在是否使用得好是另一回事.

正如Stu所说,从开发人员的角度来看,我发现两个用例(以及用例描述)和活动图是最有用的.

在尝试显示关系以及对象属性(如持久性)时,类图非常有用.当谈到添加单个属性或属性时,它们通常是矫枉过正的,特别是因为一旦编写代码它们经常会过时.

UML最大的问题之一是在生成代码后需要保持最新的工作量,因为很少有工具可以从代码中重新设计UML,而且很少有人能做得很好.

Answer 6

我将通过提及我没有大型(类似IBM)企业开发环境的经验来证明我的答案.

我认为UML和方式Rational Unified Process的是,它更TALKING你要去比实际做什么DOING你打算做什么.

(换句话说,这主要是浪费时间)

Answer 7

只在我看来扔掉了.UML是一个很好的交流思想工具,唯一的问题是当你存储和维护它时,因为你实际上是创建了两个相同信息的副本,这就是它通常会被打击的地方.在第一轮实施之后,大部分UML应该从源代码生成,否则它将很快过时或需要大量时间(手动错误)以保持最新.

Answer 8

我在学校的最后两个学期共同教授了一个高级开发项目课程.该项目旨在用于当地非营利组织作为付费客户的生产环境.我们必须确保代码完成了我们的预期,并且学生们正在捕获满足客户需求所需的所有数据.

课堂时间有限,我在课堂外的时间也是如此.因此,我们不得不在每次课堂会议上进行代码审查,但有25名学生注册个人审核时间非常短.我们在这些审查会议中发现最有价值的工具是ERD,类图和序列图.ERD和类图仅在Visual Studio中完成,因此创建它们所需的时间对于学生来说是微不足道的.

这些图表很快就传达了大量信息.通过快速浏览学生的设计,我们可以快速隔离代码中的问题区域,并在现场进行更详细的审查.

如果不使用图表,我们就不得不花时间一个接一个地通过学生的代码文件来寻找问题.

Answer 9

我迟到了这个话题,并试着澄清一些小问题.询问UML是否有用太广泛了.大多数人似乎从典型/流行的UML中回答了问题,作为绘图/交流工具的视角.注意:Martin Fowler和其他UML书籍作者认为UML最适合仅用于通信.但是,UML还有许多其他用途.最重要的是,UML是一种建模语言,其符号和图表映射到逻辑概念.以下是UML的一些用法:

• 通讯
• 标准化设计/解决方案文档
• DSL(域特定语言)定义
• 模型定义(UML配置文件)
• 模式/资产使用
• 代码生成
• 模型到模型转换

鉴于上面的使用列表,Pascal的发布是不够的,因为它只涉及图表创建.如果上述任何一项成为关键成功因素或需要标准化解决方案的问题领域,项目可以从UML中受益.

讨论应该从UML如何过度使用或应用于小项目来讨论UML何时有意义或将实际改进产品/解决方案,就像应该使用UML时一样.在某些情况下,一个开发人员的UML也可以感知,例如模式应用程序或代码生成.

Answer 10

UML多年来一直为我工作.当我开始时,我读了Fowler的UML Distilled,他说"做足够的建模/架构/等等".只需使用您需要的!

Answer 11

尽管这个讨论长期以来一直不活跃，但我认为有一些重要的观点需要补充。

有缺陷的代码是一回事。如果顺流而下，设计错误确实会变得非常臃肿和丑陋。然而，UML 是自我验证的。我的意思是，通过允许您在多个数学封闭且相互检查的维度中探索模型，它可以产生稳健的设计。

UML 还有另一个重要的方面：它直接与我们最强的能力“对话”，即可视化能力。例如，如果 ITIL V3（本质上足够简单）以 UML 图的形式进行传达，那么它可能会在几十张 A3 折页上发布。相反，它以几本真正符合圣经的巨著问世，催生了整个行业，带来了惊人的成本和广泛的紧张性冲击。