软件工程UML八大误解

Posted 2021-04-17 软件工程之思

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件工程UML八大误解相关的知识，希望对你有一定的参考价值。

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标准是开放的，所以各厂商可以根据标准开发自己的UML工具，工具之间还可以通过XML交换模型。UML相关工具最多时达168种，经过市场的洗礼，现在还在更新的还有近百种。

Enterprise Architect（简称EA）逐渐成为大多数开发人员学习建模的首选工具。EA是目前最流行的UML建模工具，使用风格和以前的Rose接近，个头又不大，很方便开发人员自行安装学习，价格也适中，堪称性价比最好的工具。可以在类图、状态图层面上做设计级调试，生成可直接运行的代码。

误解三：许多开源软件没有用UML建模

许多流行起来的开源项目（Linux、Apache、mysql...）确实没有使用UML建模，但是这些项目的核心领域多为基础设施领域。基础设施领域的"负载"（需要依赖的领域的数量）比较低，只需关注计算机的资源，不需关注医院、税务、物流....。因为负载低，基础设施级别的分解和复用相对容易，而且基础设施领域有大量的教材和先行例子，程序员在学校里已经受过这方面的教育，大脑比较容易把握基础设施领域问题的复杂性，所以对显式建模的要求没有那么高。

很多能够带来利润的系统"负载"比较高，除了核心领域（如医院）的知识，还要依赖于其他非核心域的知识，而且，核心域并没有那么多人去研究。很少有类似这样的书，把一家医院的流程，各种业务对象之间的关系，用某种方法（彩色UML建模也好，以前的数据流图＋ER图也好）研究得透透的。要在市场上获得竞争优势，有必要把复用的级别提升到核心域的复用（因为其他的好处，竞争对手也能获得），这确实很难，但再难也要做。这时，建模技能就必不可少了。

在这方面，不少媒体有误导。媒体会访问某些“知名程序员”对建模的看法，得到的回答可能是“对我来说不重要”。这里面的原因是：基础设施领域的程序员更容易得到媒体青睐成为“知名程序员”，因为“芯片”、“操作系统”等词汇上的光环会把媒体晃晕。更不客气地说，其中一些“知名程序员”实际上仅仅是“玩家”，不了解开发带来利润的软件需要付出的辛劳。

和我们生活工作密切相关的软件，媒体关注得太少。一名白领，早上起来用微波炉热牛奶，开电视看新闻，坐电梯下楼，刷卡坐地铁，手机看微博，打卡进公司，用公司的业务系统工作。上面这句话中涉及到至少七个系统，其中估计只有微博的开发人员能登上媒体的版面。你知道微波炉的软件是谁写的吗？大多数开发人员做的软件和“知名程序员”不一样，让“知名程序员”来做这些软件，也未必做得来。Linus能做好一个医院信息系统吗？

误解四：UML模型是源代码的概要表现形式

持这样看法的开发人员，应该对软件开发的工作流没有概念，软件开发工作流以及推荐使用的UML元素如下图：

图1 各工作流以及推荐的UML元素

源代码（开发人员最终需要编辑的介质）能够表达的只是"设计"工作流的内容，所谓“代码就是设计”。UML模型的重点是表达前面三个工作流的内容。虽然最后目的是要得到代码，但没有前面几个工作流的正确的推导，正确的代码不会从天上掉下来。

一些书籍、文章、博客大谈“编码的艺术”，很多也属于概念不清，文中探讨的根本不是编码的技能，而是分析技能甚至是业务建模技能。编码确实有编码的技能，但到了编码时还在思考订单和商品、发票的关系是什么，相当于护士已经把注射器拿在手里了，还在思考病人可能是什么病，开什么药。

这种认为“UML模型是代码的概要形式”的误解不止“普通”的开发人员会有，一些著名的UML书籍作者也有。Martin Fowler所著的UML畅销书《UML精粹》，认为UML有三种用法：草稿、蓝图和编程语言，也是仅从编码的角度来说的。从Fowler写作的其他书籍《重构》、《企业应用架构模式》、《分析模式》等可以知道，他的研究工作集中在分析设计工作流，特别是设计工作流，不了解他在业务建模和需求方面有多少研究。

误解五：UML建模和迭代开发冲突

有的开发团队以“敏捷”为名，放弃了建模技能的学习，借口是“反正一开始不可能把所有东西都想明白，先做做看吧！”。“先做做看”和建模并不矛盾，不能把“敏捷”、“迭代”当作偷懒的庇护所。

一名从护士成长起来的医生，只掌握了打针的技能，却缺少检查、诊断、拟治疗方案等技能，索性说：“唉，反正再高明的大夫，也不能一个疗程把病人治好，干脆我也别花那么多心思了，先随便给病人打一针看看吧，不好再来！“迭代”只是一个底线，确实，再高明的大夫也没有把握一个疗程就治好病人，但是检查、诊断等技能越精湛，所需要的疗程就越少。

光喊口号“先做最重要的需求”是没用的，你知道哪些需求最重要吗？掌握业务建模技能，能帮助你准确定位最重要的需求。光喊口号“分离变化”是没用的，你知道哪些容易变，哪些不容易变吗？掌握分析设计技能，能让你看到变和不变的部分。

唱曲的名家，唱到极快之处，吐字依然干净利落；快节奏的现代足球，职业球员的一招一式依然清清楚楚；即时战略游戏高手要在极短时间内完成多次操作，动作依然井然有序。在激烈竞争的年代需要快速应变，掌握技能才能真敏捷。世上无易事，偷懒要不得。

刚入行的开发人员体会不到建模的重要性，是正常的。就像下象棋，初学者面对单车对马双士、单马对单士等已经有共识的局面还需要思考良久，最终还拿不下来甚至输掉。这时中局和布局的书在他看来多半是枯燥无味的，还不如把一本实用残局汇编看熟了，学到一些奇技淫巧，也能在菜市场赢几盘棋。不过，要迈向职业棋手的境界，参加更残酷的竞争，就体会到中局和布局的重要了。

误解六：能否给我一个完整的UML案例？

经常有这样的问题“能不能给一个案例，完完整整地实施了整套UML？”这是一种误解，这样的案例不应该有。可以把UML看作一个完备的工具箱，里面各种工具都有。您只需要从这个工具箱中选择适合您的项目类型的工具用上就可以，并不需要“完整地”使用UML。不只是UML，对编程语言也一样的。很多人说“我用Java”，其实只是用Java的一小部分，而且很长时间内只用这一小部分就够了。

即使针对你的项目类型，挑选出了一些适用的UML元素，也不提倡一次性都用到下一个项目中，而应该找出最值得改进的工作流，一点点引进。

例如，一个工期比较紧迫的管理信息系统，业务建模和需求工作流就很重要，毕竟这个项目不满足客户的要求，后面的生意也就没了，而分析设计就没那么重要，因为先不用考虑复用和扩展的问题，那么，可以只在关键的业务流程做业务建模，在关键的用例认真定义需求，然后按照熟悉的套路开发。需要引进的UML元素可能有：业务序列图、系统用例图、系统用例规约。

反之，如果做一个医疗设备，需求可能容易获得，但是对系统的质量要求非常高，不允许出任何错误，这时，前面的业务建模、需求工作流可以不改进，把分析设计工作流作为改进重点。需要引进的UML元素可能有：类图、状态机图、序列图。

如果开发团队能够最终改进到覆盖所有工作流，自然是件好事，但是大多数项目来说，点状的逐步改进更符合实际情况。UML如何完整应用在业务建模、需求、分析、设计工作流，这些年以来已经有不少围绕案例讲解的书籍。阅读之后也不要一次性照搬，还是要慢慢来。一些工具厂商出于展示其工具建模能力的目的，在建模工具自带的案例模型中，把所有的UML图都给用上了，这也要注意辨别，不可当真。

误解七：大师们不写UML书了

最开始一批UML书籍，基本上是方法学家所写。最近几年，以“UML”为题的新书大多为高校教材或普及性教材。这并不是说UML已经不重要，而是没有必要再去强调，焦点不再是“要不要UML”，而是如何把UML建模高效应用到软件开发各工作流中。

下图是amazon.cn上搜索的最近三个月出版的UML书籍结果。

【软件工程】UML八大误解