UML建模的认识

1.7 但…仅限于开发团队内部

但是，这里要注意一点：这种沟通仅限于开发团队内部，UML 模型不是用来和涉众沟通的！
经常有人问：客户看不懂UML 怎么办？这个问题本身就有问题，提问者潜意识里可能认为“客户”
是一个人，其实“客户”是一大堆“涉众”，他们所在领域不同，学历职位有高有低，年龄有大有小，
健康有好有坏，关注的利益更是各自不同，怎么能寄望用一个模型和所有的涉众沟通？
拿五线谱类比，五线谱是音乐专业人士交流的工具，作曲要懂、编曲要懂、乐手要懂、指挥要懂、
歌手要懂（注意：是懂五线谱，不是人人都要用五线谱作曲）。但哼着“什么样的节奏是最呀最摇摆”
的打工仔不需要懂五线谱。UML 只是在“软件开发人员”圈子里面的统一表示法，强迫开发人员思考，
改善开发人员的交流，表达软件开发的模型。

那么，和涉众交流的介质是什么呢？不是模型本身，而是模型的各种视图。面对大领导，我们可
以给他放幻灯片交流愿景；中层干部喜欢看文档，我们可以按照他喜欢的格式给他炮制文档；一线操
作工只关心他那一小块工作，我们可以制作界面原型和他交流；有时候甚至有的涉众根本不喜欢看任
何东西，我们还可以通过“谈话”这种视图和他交流。极端一点说，如果客户的领导喜欢“潜规则”，
不排除派一名美貌女（男）员工去通过“潜规则”这种视图来和领导交流的可能。
另外，和涉众交流的内容应该聚焦于需求的素材─涉众利益（涉众希望什么担心什么），而不是需
求。软件的需求规约相当于电影剧本。电影剧本并不是由观众直接提供的，而是由编剧根据不同观众
的口味编出来的。同样，软件需求不是由涉众直接提供的，而是由需求工程师综合不同涉众的利益编
造出来的。涉众没有资格、也没有责任提供需求，这一点后面在“需求启发”一章中再详述。
和涉众交流的形式应该采用视图，而不是模型
和涉众交流的内容应该聚焦涉众利益，而不是需求。

20
不管涉众向我们索取什么材料，都把它看作视图，不管涉众向我们提供什么信息，都把它看作素
材（涉众利益）。视图和模型的分离、交流和建模的分离，带来了灵活多变的交流方式和严谨稳定的开
发内核。