我觉得这不是个问题,bo没有了操作方法,还叫面向对象?比如说银行帐号Account对象,存款deposit(),取款withdraw()操作不属于Account对象,难道还属于别的对象?这不是很自然吗?
见 RUP统一软件过程
http://www-128.ibm.com/developerworks/cn/rational/rationaledge/content/mar05/5383/?ca=dwcn-newsletter-rationalN10098
对每个用例
建立一个用例实现
补充用例描述(如果需要的话)
从用例行为中,找出分析类
如果我们严格按照RUP过程进行,下一步应该是:
把行为分配给分析类
基于以下理由,这一次,我又会对RUP过程做一点小的改动:回顾一下我们的进展。我们刚刚找到了8个实体类,我们认为这些都是我们系统中的类。在我们做下一步之前,我们需要给这8个实体类增加一些内容,来确认他们是类。
有三种基本的方法来充实我们的分析类:
数据驱动的方法
行为驱动的方法,和
职责驱动的方法。
数据驱动的方法对于从事数据库工作,或者从事过程语言编程的人员来说很常见。他们就是用数据和数据之间的关系来认识、描述世界的,因此会首先去寻找类中的数据-一般没有什么标准的方法去寻找类的函数或功能。这看起来不错,但是数据只是工作的一半。实际上, 类的准确定义,包括了数据和对数据进行的操作。
行为驱动的方法有着双重的成立理由。首先找出类执行的操作,从中决定这些操作涉及的数据中,哪些应该被这个类所拥有。这很棒,但是我们如何确认我们为类找出的操作之间能够保持一致呢?如何区分操作和类,以明确这个操作是属于这个类,但是 其它的操作要属于同一个类,还是其它的类?我们需要某种方法来区分各个操作。这就是职责驱动的方法带给我们的。
职责驱动的方法是自上而下的,从总体的类及其职责的视图开始。首先定义一个类在业务中的“使命”,这个“使命”描述了这个类对外提供的服务。从军事术语上来说,就是责任和策略。操作和数据是战术层面上的(为战略服务的,服从于某些目标、策略的)。 2
一旦我们确定了我们的类的职责,我们就可以设计一个分析类图,来描述类间关系的整体结构。这个结构一般都是由业务领域决定的。一个UML分析类图可以帮助我们可视化的把这个关系的结构表示出来。
因此,我建议对标准的RUP过程做如下修改(次序的改变):粗体):
对每个分析类
描述类的职责
在分析类图上,建立分析类间的联系
把行为指定给分析类(找出操作)
描述每个类的属性和关系
定义类的属性
描述分析类间事件的相关性
u]