UML八大误解.pdfVIP

UML 八大误解 潘加宇 本文删节版发表于《程序员》2013年 11 期 UML（统一建模语言）是软件建模的表示法标准。我从 2002年开始专门从事研究和推广 UML 的工作， 在为软件组织提供 UML相关需求和设计技能服务时，经常会发现软件开发人员对 UML 建模存在种种误解。 本文归纳了最典型的八个误解加以剖析。 误解一：UML 是开发团队用来和客户沟通的 UML 模型是开发团队内部高效沟通的手段，但不是用来和涉众沟通的。拿音乐中的五线谱类比，五线 谱是音乐专业人士交流的工具，作曲要懂、编曲要懂、乐手要懂、指挥要懂、歌手要懂（注意：是懂五线 谱，不是人人都要用五线谱作曲），但听音乐的人不需要懂。UML 只是在“软件开发人员”圈子里面的统一 表示法，强迫开发人员思考，改善开发人员的交流，表达软件开发的模型。 另外，“和客户沟通”的说法本身就有问题，因为“客户”不是一个人，而是一个组织，里面有不同 角色和岗位的“涉众”。他们的学历职位有高有低，年龄有大有小，关注的利益更是各自不同，所以，和 涉众交流的介质不是模型本身，而是模型的各种视图。面对大领导，我们可以给他放幻灯片交流愿景；中 层干部喜欢看文档，我们可以按照他喜欢的格式给他炮制文档；一线操作工只关心他那一小块工作，我们 可以制作界面原型和他交流；有时候甚至有的涉众根本不喜欢看任何东西，我们还可以通过“谈话”这种 视图和他交流。涉众连谈话都不乐意，我们也可以通过观察来获取素材。许多伟大的创新需求正是有心人 在涉众不作声的情况下，观察涉众的行为得到的。 涉众能提供的只是需求的素材，没有资格也没有责任直接提供需求。软件需求不是由涉众直接提供的， 而是由需求工程师综合不同涉众的利益决定。就像电影剧本一样，剧本不是由观众直接提供的，而是由编 剧根据不同观众的口味编出来的。 如果不了解这个区分，直接拿 UML 模型去和涉众交流，很容易导致“四不像”。不少开发团队十年如 一日没有进步和积累，“交流影响开发”是原因之一。为了迁就不同涉众的知识水平，开发团队只好损害 模型的严谨性，即使是这样，涉众也不一定接受，交流效果还是不好，而且还会因为涉众的交流形式多变 而影响开发团队核心工作流的稳定─——双方都受害。客户的领导说，我不习惯看 UML 模型，就知道以前 看的是××标准格式的文档，我只在这个格式的文档上签字，难道我们就不用 UML 建模了？下一个项目的 客户领导喜欢另一种格式怎么办？下下个项目根本不需要签字怎么办？互联网网站没有“客户领导”签字 确认需求怎么办？建模的目的是帮开发团队思考，它可以指引开发团队发现到底需要向涉众了解什么，但 不是直接拿着模型和涉众交流。 开发人员有意无意把建模的目的理解成和涉众交流，有时背后的思想还是“懒”字，因为这样想，就 有了推卸责任的机会：不是我不想建模，就算我建模了，客户不想看啊。 误解二：UML 是Rational 公司的，Rose 是最好的UML 工具 说到UML，很多人会想到最开始推动UML诞生的“三友”：Grady Booch、James Rumbaugh和Ivar Jacobson。 在早期，“三友”的贡献是最大的。接下来，UML标准的管理和推动主要由 OMG（对象管理组织）负责，OMG 的成员是各大软件企业，包括 IBM、Microsoft、Oracle、Lockheed Martin 等。 在 OMG 的推动下，UML 被越来越多的标准组织采纳。2005 年开始，UML 被ISO 接纳为标准。和 UML 2.4.1 对应的标准是 ISO/IEC 19505-1:2012和 ISO/IEC 19505-2:2012。2011 年，中华人民共和国发布了统一建 模语言国家标准 GB/T28174。行业标准组织如医疗卫生信息化的标准组织 HL7、IT管理标准化组织 DMTF、 美国国防部等，也使用 UML 来描述它们的标准。 UML 诞生初期，最流行工具确实是 Rational Rose，甚至有些人会把 Rose 和 UML 混为一谈。2002 年 Rational被IBM 收购以后，名称变为 Rational Software Architect（简称RSA），这意味着如果现在您还 使用 Rose，那是在用十多年前的工具。 因为 UML 标准