UML是否实用？

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

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

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

1> 17 of 26..：

---

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

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

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

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

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

---

"从现在起六个月内出现的新雇员怎么样,需要加快代码的速度？" 呃..看代码怎么样？这是加快代码速度的唯一准确而完整的方法.考虑到我们是程序员,也是最自然的方式.我认为我们必须查看一个图表才能理解完全可笑的代码,并且这种垃圾在某种程度上变得普遍存在.

---

即使代码是@BobTurbo,一张图片仍然值得千言万语.我没有看到任何反对这一点的理性论证 - 其中包括以"嗯_real_程序员......"开头的论据.如果我要与我的团队就建筑问题进行对话,我不打算透露胶带10页源代码到白板上.

---

我发现在开始编码之前绘制一个UML类图节省了我的时间.它让我可以看到设计缺陷和缺陷,并与我的同事讨论这些.更好的是,如果使用CASE工具绘制它们,它们将生成应用程序的基本结构代码.所以投资回报是三倍.

---

同意BobTurbo,我从未对UML有任何用处,尤其是其他人的UML.我总是喜欢直接看代码.

2> Pascal..：

---

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

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

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

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

3> Marcus Downi..：

---

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

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

---

关于这个网站的奇怪的事情,没有办法告诉你在第一段中引用某人然后不同意它们.但是,是的,真的:伪代码也是一种很好的图表技术,并且非常常用.涉及树林,火炬等的奇怪隐喻也很棒.

4> Stu..：

---

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

5> samjudson..：

---

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

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

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

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

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

6> Seibar..：

---

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

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

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

---

我不会投票给你,因为我认为这是一个很好的答案,但我不能不同意.每当我绘制一些东西时,我就会节省数小时或数月的开发时间,而且我几乎总是单独开发(最近).

---

谈论和撰写您想做的事情有助于您和其他人更快地了解和发现可能的问题。

7> Quibblesome..：

---

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

8> 小智..：

---

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

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

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

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

9> Ted Johnson..：

---

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

通讯

标准化设计/解决方案文档

DSL(域特定语言)定义

模型定义(UML配置文件)

模式/资产使用

代码生成

模型到模型转换

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

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

10> Sean Kearon..：

---

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