来源:http://hi.baidu.com/dongyuejiang/blog/item/b59ba6ecf1e0652163d09f5a.html
作者:安庆风 小布鲁斯的blog
我发现,在OO和UML几乎一统天下的今天,仍有很多系统分析员对OO和UML一知半解,甚至包括很多已经使用了很久UML的系统分析员。 于是打算写一个系列文章,将多年来的工作经验做一个总结。对初学者起个启蒙作用,也希望抛砖引喻,与各路大虾共同探讨,共同提高。 这个系列文章将以我对OO和系统分析的理解为主,从UML基础开始,阐述面向对象的需求分析方法,过程,并以RUP为例,阐述如何将OO过程与软件过程有机结合在一起,做一个真正OO应用。 好了,今天是第一篇。想得很远,真希望我能坚持下去,呵呵 用例是什么?其原始英文是usecase,直译过来就成了用例。这也是一个比较贴切的叫法了,从字面的直接理解就是使用的例子。另一种比较流行的定义是用例就是与使用者(actor)交互的,并且给使用者提供可观测的有意义的结果的一系列活动的集合。 最具普遍意义的理解错误是认为用例就是功能的划分和描述,认为一个用例就是一个功能点。在这种理解下,用例变成了仅仅是较早前需求中功能框图的翻版,很多人用用例来划分子系统,功能模块和功能点。如果这样,用例根本没有存在的必要。有意思的是,造成这种理解错误的相当一部分原因却是因为对OO思想的理解不够深入,本质上说,把用例当成功能点的系统分析员脑子里还是面向过程的那一套思想,虽然他们在使用OO的工具,OO的语言,号称在做面向对象的开发,但过程的影子还没有从他们脑子里彻底抹去。 除去以上的特征,笔者觉得用例的含义还要更深些。首先,用例的背后是一种需求方法论。其核心是以参与者为中心(区别于以计算机系统为中心),从参与者的角度来描述他要做的日常工作(区别于以业务流程描述的方式),并分析这些日常工作之间是如何交互的(区别于数据流的描述方式)。换句话说,用例分析的首要目标不是要弄清楚某项业务是如何一步一步完成的,而是要弄清楚有多少参与者?每个参与者都做什么?业务流程分析则是后续的工作了。其次,用例简直就是为OO而生的,其思想完美的符合OO。用例分析方法试图找到问题领域内所有相对独立的参与者和事件,并把业务流程当成是这些参与者和事件之间的交互结果(在UML用活动图或序列图来描述)。因此,用例方法被吸纳到OO之后,UML得以以完备的形式出现,用例成为了真正的OO核心。在RUP里,这种核心作用被发挥到极致,产生了用例驱动(usecase driven)的软件过程方法,在RUP里,软件生产的所有过程和产物都是围绕着用例形成的。 可以说,用例分析是OO的第一步。如果用例分析本身出了问题,对业务架构,软件架构的影响是很大的,将大大削弱OO的优势--复用、扩展。笔者认为软件复用可以分为三个层次,最低层次的复用是代码级复用,这是由OO语言特性提供支持的,例如继承,聚合,多态;较高层次的复用是组件级复用,这是由设计模式提供支持的,例如Factory模式,Builder模式;最高层次的复用则是服务级复用,这在很大程度上是由应用服务器和通讯协议来提供支持的,例如最近炒得火热的SOA(面向服务的应用)架构。用例分析的好坏也许对代码级和组件级的复用影响不太大,但对服务级的复用影响却是巨大的。笔者认为服务级复用是OO的最高境界,而结构良好的用例分析则是达到这一境界的基础。 如果你的分析习惯是在调研需求时最先弄清楚有多少部门,多少岗位,然后找到每一个岗位的业务代表,问他们类似的问题:你平时都做什么?这件事是谁交办的?做完了你需要通知或传达给谁吗?做这件事情你都需要填写些什么表格吗?....那么恭喜你,你已经OO啦! |