[技术讨论]网络软件开发的bug分析与公司开发管理问题之腾讯篇三UML部分（有更新）

接上文腾讯篇第二部分，地址是：http://blog.csdn.net/qingrun/article/details/8552996

5.9 UML培训资料中的错误
几个月前在新浪微博中看到有人转发的这样一份据说是腾讯内部的培训资料，在《腾讯：从概念到产品-需求分析过程》的这份腾讯大学的培训资料中，笔者看到了很多错误，下面一一列举。
5.9.1 Actor的定义错误
第十八页的内容中提到了Actor的角色，这里的内容包含了一个错误。



系统之外的任何东西都是角色——Actor，这句话本身就是一种错误的表述。
在《UML参考手册》中文版中的Actor是这样定义的：actor参与者是直接与系统相互作用的系统、子系统或类的外部实体的抽象概念。参与者参与到用例或一组连贯的用例中以完成整个目标。
在这里Actor被翻译为参与者。
在《UML Concept》中Actor是这样定义的：与用例交互时，用例的使用者所充当的一系列相关角色。一个活动者对所通信的每个用例具有一个角色。更详细的解释就不张贴在这里了。
在这里Actor被翻译为活动者。
不管上面两篇文字中对Actor的翻译如何，其所强调的作用是相同的。
《UML参考手册》中强调与系统相互作用，这个词很关键。在《UML Concept》中强调使用者所充当的。
这两段话都强调了一个主动性，也就是Actor必须能够主动地发起触发。因此在很早以前笔者的博文里面就曾经提到了这一点：Actor必须是能够主动发起行为的，另外，Actor与用例的交互只是通信而不是互相操作，因此外部系统一般不能作为Actor来存在，因为系统之间的交互往往是通过接口实现的，发出信息并获取返回信息，获取的返回信息也必须有对返回信息进行处理的方法，也就是说，返回信息进入到这个外部系统的时候，会对外部系统内部的数据和操作产生影响。这时候就不符合Actor的主动要求了，否则，就会产生设计时的混乱，诸如时钟，定时器，数据库，一些触发类程序系统等等都可能因为这一点而被误判认定为Actor而不是外部Use Case或者外部系统。同样，大概在2004年曾经讨论过数据库是否可以作为Actor存在的问题，结论就是否定的。
再多说一句，对于系统和Actor之间的交互与系统和外部Use Case或者外部系统的交互是完全不同的。系统与Actor之间的交互，就是Actor进行操作和行为触发，然后系统执行并显示，并不存在对Actor直接的数据输入。而系统和外部Use Case或者外部系统的交互是会产生直接的数据输入的，至少返回值就是必须进行处理的。
5.9.2 Use Case到Actor的调用
在第20页出现了Use Case到Actor的调用。



根据前文中提到的Actor的定义可以看到，这个世界上不会发生Use Case调用Actor的事情，这样的事情是违背客观现实逻辑的。
而可能发生这种操作的应该是外部Use Case。
当然还有一种可能的错误分析情况，在笔者的blog中有这样一篇文字：http://blog.csdn.net/qingrun/article/details/6322312。其中有一副图，如下所示。



实际上在这里，不存在取款用例到顾客之间的关系，与系统操作相关的都是银行理财专员，银行理财专员最后把钱取到手，交给顾客的过程是不通过系统的，也就是说，顾客和系统之间并没有任何交互，不是系统的Actor之一。
5.9.3 外部系统不能用Actor来表示
外部系统也可以用Use Case来表述，只不过是外部Use Case，绝对不是Actor，Actor的创建必须是能够主动行为的对象，绝对不是一个只能被动响应，然后通过活动或者时间触发的对象。



上图中的银证转账系统应该是一个Use Case或者一个子系统，或者一个外部系统包，绝对不应该使用Actor来表示。
5.9.4 Use Case名称位置的问题



Use Case名称未必写在椭圆内，在最初也是影响力最大的Rational rose这个工具中就没有把名称写在椭圆内。
下面是几个常用UML工具的用例标示图。
Rose



EA



Trufun



StarUML



确实，在UML规范中是如此要求的，但是，实际实现中并没有都如此遵循，如果这里强调必须放在椭圆内，那Rose将被置于何地？毕竟Rose是Rational公司的产品，而Rational则是UML三巨头的公司。

5.9.5 扩展，也就是extend关系的错误绘制
扩展也就是extend关系的使用错误，这个在2002年我的文字中就写过，extend关系是从后向前绘制的，正好和include关系相反。
下面两幅图中的extend关系都错了。






Extend关系是后者对前者的扩展，或者说逻辑上表示后者对前者的扩展，而数据流向是从前者进入后者的，因此和Include关系的箭头方向正好相反。两者的差别表示是，Include表示前者执行完，必然执行后者，而Extend则表示前者执行完未必执行后者。
更典型的错误例子图如下。



注：从实际的业务逻辑上，这张图也绘制错了，存钱和取钱都不代表必须打印单据，因此，下面的两个包含关系也应该是扩展关系，即extend关系。如果不相信，就自己去银行ATM上操作几次就知道了。
举一个国外99年的资料中的例子：



这是为了说明一个问题，大家在面对资料的时候，至少要学好基本的概念和知识，否则会出现很多错误和不必要的混乱。
注意：虽然笔者曾经说过，只要团队内保持一致，如何使用UML都没有关系，但是，当你的团队需要学习很多外部资源来熟悉一个标准的时候，还是应该尽量把标准的基础知识学准确了，否则，当他们看到你的团队资料和外部资料不同的时候，就会无法理解，甚至产生怀疑和冲突，毕竟不是每一个成员都可以达到对知识灵活运用而不僵化教条的水平的。

5.9.6 从Use Case指向Actor的箭头



关于这页中提到的include和extend关系的区别，请看下面的链接http://blog.csdn.net/qingrun/article/details/6026717，http://blog.csdn.net/qingrun/article/details/5799615。
但是，关于Use Case指向Actor的箭头错误，在前面5.9.2中已经解释过了。
5.9.7 与外部系统互动的错误绘制
既有extend关系错误，也有从Use Case指向Actor的错误。



5.9.8 Sequence Diagram在需求阶段的错误使用
这是一个可能有争议的话题，不过，考虑了很久后还是决定放在这里。
Use Case的阐述中使用Sequence Diagram，把设计模型中的常用表示图用在了需求分析阶段！这样的跨阶段使用完全是违背了时序图创建的本意和用途的，一般而言，需求阶段只需要使用状态活动图或者泳道图，这不是时序图来进行这样的细节描述。
另外，需求阶段的产物一般而言会要求用户可以看懂，而用户一般不会看懂比较专业的时序图或者协作图（时序图和协作图是可以1v1直接转换的）的表达方式，只有状态/活动图或者泳道图才适合在需求阶段使用。



即使在2008年笔者曾经提供给西安楚凡使用的Use Case阐述模型化的表示方法中，也只是用到了泳道图就解决了这个问题，而不需要使用时序图来表达。
另外，现在确实有很多书籍资料中把时序图用在需求阶段进行需求细化的表示，可是他们确实忘记了，在UML的表述中，时序图是和协作图1v1转换的，如果你使用了时序图在需求阶段，那么协作图用于需求阶段也应该是可以的，但是，却几乎没有看到过协作图用于需求阶段的例子。
最后，即使是用例细化的过程中，涉及到用例大小度量和数量计算的时候，这个时候往往是需要考虑项目规模的，也就是需要度量开发周期的时候，用例的大小度量和数量的基础，用状态/活动图以及泳道图中的元用例/活动/状态作为基础进行计算是一个非常方便的方法，而在时序图中则很难找到合适的对应关系。
另外， Sequence diagram应该是来源于Rumbaugh的OMT方法中的动态模型和Jacobson的OOSE方法的时序图，在 OOSE方法中时序图是设计模型阶段的组成部分，并不是需求阶段使用的。在OMT方法中的动态模型中强调：“动态模型描述与时间和操作顺序有关的系统特征——激发事件、事件序列、确定事件先后关系的状态以及事件和状态的组织。”因此也是属于分析设计阶段的内容，不是需求阶段的表示方法。
虽然笔者有过一些关于用法上不拘一格的观点，但是，凡此种种，至少到目前为止，并没有必须把时序图用于需求阶段的铁证。因此，笔者还是建议在需求阶段或者说在任何阶段都不要信手拿来主义，把其他阶段的表示法拿来就用，这是不合适的。
5.9.9 其他错误
剩下的内容还有一些错误因为不是明显的或者不能用一些简短的文字证明，这里就不再列出来了。

下文继续腾讯篇第四部分。