《软件工程实践者的思想(PDF格式)》第11章

接下来咨询公司会与我们的客户一起做业务建模，然　
后再做业务到需求的映射，再抽取需求并完成需求建模。　
他们做业务建模的时候，可能使用一些客户业务范畴内的　
符号和标识；而在做需求建模时，则需要使用一些软件行　
…45
…………………………………………………………Page　50……………………………………………………………
第　4　章 流于形式的沟通
业中（　的设计和分析人员）　习惯的符号和标识。
这些符号和标识也有个专用名称，“En。。。　这个叫模型　
语言（ML）　。”他们无时无刻不在向你展现他们的专业（这已　
经是他们还存在的唯一原因了）　。
如果他们更加专业，他们会告诉你他们用的是　UML　。　
向你介绍这个名词的时候，他们的眼镜或者眼睛里通常将　
大放异彩。
①　
UML　是模型世界里的世界语 。
到现在为止，你应该看到，咨询公司除了把问题搞得　
更加复杂之外，他们仍然需要面对最直接的问题：与客户　
如何交流？
他们的解决之道是模型语言。
有什么差别吗？
程序员不能要求客户会　C　Language　，难道需求分析师　
们就能要求客户会　Modeling　Language 吗？！
2。 项目文档真的可以用甲骨文来写
独　孤　木　（http：//javaworld。。tw/） 曾　经　在　一　篇　
《UML；　OOAD　and　RUP　》中讨论到　UML 实际应用中的问　
题。其中的两个问题是：
① 现实的情况未必如此。但UML　这个名词起码显示了它本源性的　
期望：Unified　Modeling　Language（　统一模型语言）　。
…46
…………………………………………………………Page　51……………………………………………………………
『大道至简』
） “大部分的使用者，以及客户的信息人员，其实　
并没有足够的能力，来确认这些文件（User　Case）　
的正确性与完整性。”
） “除了客户不了解UML　，OOAD 跟　RUP 以外，　
另外一个更糟糕的现象就是　project team 里面　
的人也不懂。”
这实在是很有趣的事。
看来在一些情况下，在项目中使用　UML 只是完全不　
懂的老板，以及什么都懂的博士的主意，而真实的场景中　
去做事的那些客户与项目成员，其实是未见得就能用好　
UML 的。
仅以　UML 的　User Case 来说，由“用例图”和“用　
例规约”组成。规约跟我们写的需求说明书差不多，不过　
更加细节罢了，而且还有一套相应的方法论来阐述如果去　
实作。图则很简单，就是几个图形符号来描述系统边界和　
角色关系。
显然甲骨文也能描述范围与关系。例如甲骨文中的　
①　，这个边界就定义　
“家”这个字，就是上有房子下有猪　
得很好；在古文中，“三”通常是泛指，跟UML　图中的线　
条上标注的那个“*　”是同义的，而甲骨文中“众”这个　
① 至于是“内有猪”还是“下有猪”的问题，不是我们要争论的。　
有些考古学家根据甲骨文的象形来认为古人与家猪是杂居的，但　
我想那时的猪可能还比较野性，因此这种可能性还是小些。
…47
…………………………………………………………Page　52……………………………………………………………
第　4　章 流于形式的沟通
字，就是日字下立有三个人，也就是在同一个日头下做事　
的很多人即为“众”，这个关系也描述得很确切。
所以只要你运用得法，甲骨文一样可以用来画用例图　
和写用例规约。同样的，只要约定一套“语法”，你同样　
可以用甲骨文来做活动图、类图、构件图……以及这些图　
相关的规约。相比来说，古巴比伦人使用的楔形文字“象　
形性”差一些，因此我不建议用它来画用例图。
既然甲骨文可以用来做为一种模型语言（　同时它也是　
一种文字和口头的语言）　，那么，如果你的项目中面对的　
对象是商周文化的考古学家，以及你的项目组都由精通这　
种语言的成员构成，这时你就可以用甲骨文来做项目文　
档，以及画各种模型图例。
你要明白，要让考古学家看懂用例图，难度远大于看　
懂甲骨文。与其要求他们学一种语言，不如使用他们那个　
世界的通用语（　当然，前提你的项目组也懂得这种语言）　。
在韩愈的《答陈生书》中，他因自己不会“速化之术”，　
所以说陈生是“求道于盲”。然而他用了一个不恰当的比　
喻：要知道盲人并非不知道路如何走，只是他不能象常人　
一样描述他所知道的路。因此“问道于盲”是没有错误的，　
真正错误的是你睁着眼睛问。
我们需要在正常人与盲人之间建立一种沟通的方式，　
既然盲人不能睁开眼睛，那么你就闭上眼睛好了。
…48
…………………………………………………………Page　53……………………………………………………………
『大道至简』
UML 图在一些客户眼里无异于盲人的世界，如果需　
要向他们做需求调研，你只能使用一种这些客户能够理解　
和接受的方式，例如表格、流程图以及……更深入的交谈。
你要确认你的沟通方式是否有效，而不是去追求这种　
方式是不是　UML　，以及用　UML　表达得是否正确。——客　
户是因为他认为你理解了他们的需求，而在“需求确认书”　
上签字，而不是因为你的　UML 画得是否精准。
现在来思考：为什么非要让客户看UML　图呢？如果　
有能够满足“极限编程（XP）　”所要求的“现场客户①　”，那　
当然可以不画用例图；相反，如果客户雇了一个专家组来　
评审需求，那么你就老老实实地画用例图好了。
需要留意的是，专家组还要一种方式与客户沟通，这　
有可能不是　UML　。——当然，客户愿意增加沟通成本，　
那是他们的事。
一旦源头确定，你就可以接下来约定在项目组中要使　
用的沟通方式。愚公——这个伟大的项目经理——所使用　
的“聚室而谋曰”，就是很好的沟通方式。当然，如果客　
户精通　UML　，那么我想愚公采用的项目沟通方式将会是　
“聚室而论UML　”。我想一定会这样，因为愚公是很懂得　
沟通的、伟大的项目经理。
① 这是极限编程的特征之一，指的是要求客户可以在程序员开发　
的第一现场，随时可以向程序员确认完成功能的有效性，以及修　
正需求或者先前的需求描述。
…49
…………………………………………………………Page　54……………………………………………………………
第　4　?