DDD领域驱动设计批评文集>>
《软件方法》强化自测题集>>
《软件方法》各章合集>>
C)团队引进UML时，努力达到的最终目标应该是完整应用所有的UML元素D)
UML是软件开发人员和客户之间沟通的绝佳工具建模人员只需要根据当前所开发系统的特点，从这个工具箱中选择合适的工具就可以，并不需要“完整地”使用UML。有一些建模工具自带的案例模型会造成误解，一个模型里把所有的UML图都给用上了，但这是工具厂商出于展示其工具建模能力的目的而提供的，不可当真。该用多少UML元素，视所开发系统的类型以及对系统的质量要求而定。UML模型的目的是在软件组织内部沟通，不是为了和涉众沟通。如果受到“和涉众沟通”的影响，会导致迁就涉众的水平，模型质量大大下降——当然，这也正是某些人想要的遮羞布：不是我不想或者没有能力画得深刻一点，我是怕涉众看不懂！以医院看病类比。给患者做CT、磁共振的目的是医疗团队内部使用，不是为了和患者沟通。不能因为患者稍微看得懂CT或者喜欢看CT就给他多做CT，患者看不懂或不喜欢CT就不做。功能很少，但该功能从输入到输出的转换逻辑可能非常复杂。以下是彩蛋：
另外，“功能”是一个模糊用语，更严谨的是“用例”、“步骤”。不过，即使把“功能”换成“用例”，这句话也是不对的。
在同一愿景下，用例少的系统可能要比用例多的系统更复杂。
例如，愿景是为了减少做任务时出现的错误。
改进方案一的业务序列图如图1：
图1 改进方案一的业务序列图
从图1可以看出，在业务流程中的很多地方借助了人脑的思考。
竞品系统一的用例图如图2，有3个用例。
图2 竞品系统一的用例图
改进方案二的业务序列图如图3：
图3 改进方案二的业务序列图
从图3可以看出，岗位甲乙丙的责任已被转移到竞品系统二里面。你说啥？为什么还要岗位甲，领导干嘛不直接用系统做任务？你说呢？
竞品系统二的用例图如图4，只有1个用例。
图4 竞品系统二的用例图
假设这两个都可以满足愿景，您可以对比一下，哪个流程中的信息系统更复杂？
所有系统在问世之前，市场上都是“已经有很多现存产品”的，最原始的“竞品”就是“人脑系统”。如果随便做做，不参与竞争，不会感觉到建模的必要，怎么做都可以找出各种理由自圆其说这样做是合理的。就像打麻将，如果不耍钱或者只是一两块钱，出牌可能会“敏捷”得很，如果输了要剁手指，那么，每次出牌都要仔细盘算了。这个时候才会书到有时方恨少，后悔之前没好好练习算牌的技能。
因此，在最后讲到改进指南时，我们都会强调不要“做着玩”。要么做UMLChina出的题目，因为那些题目有清楚的约束条件，指引你去得到最佳答案；要么做真实的项目，因为真实项目也有清晰的约束条件——就是惟一的真实情况，它会指引或强迫你尽力去得到最佳答案。