行为驱动的方法有着双重的成立理由。首先找出类执行的操作,从中决定这些操作涉及的数据中,哪些应该被这个类所拥有。这很棒,但是我们如何确认我们为类找出的操作之间能够保持一致呢?如何区分操作和类,以明确这个操作是属于这个类,但是 其它的操作要属于同一个类,还是其它的类?我们需要某种方法来区分各个操作。这就是职责驱动的方法带给我们的。
职责驱动的方法是自上而下的,从总体的类及其职责的视图开始。首先定义一个类在业务中的“使命”,这个“使命”描述了这个类对外提供的服务。从军事术语上来说,就是责任和策略。操作和数据是战术层面上的(为战略服务的,服从于某些目标、策略的)。 2
一旦我们确定了我们的类的职责,我们就可以设计一个分析类图,来描述类间关系的整体结构。这个结构一般都是由业务领域决定的。一个UML分析类图可以帮助我们可视化的把这个关系的结构表示出来。
因此,我建议对标准的RUP过程做如下修改(次序的改变):粗体):
对每个分析类
描述类的职责
在分析类图上,建立分析类间的联系
把行为指定给分析类(找出操作)
描述每个类的属性和关系
定义类的属性
描述分析类间事件的相关性
用例分析第四步:描述类的职责
在这里,我们要对每个分析类进行处理。类的职责描述了这个类在系统中所提供的服务,而且其它类不会重复提供这些服务。各个类的职责不能重叠。
根据我们对汽车租借领域的理解,和对汽车租借专家、业务分析专家一起工作,我们在表3中,写出了我们对每个分析类的职责的理解。
表3:每个分析类的职责
James Rumbaugh与其它人 3 定义一个对象,或者说类,作为“一个概念,抽象,或者一个对业务来说有意义的,具有清晰定义的东西【我的重点】”。在类的职责定义中,首先要注意“清晰定义”,就是指明确指定了可以做什么,不可以做什么。
文章来源于领测软件测试网 https://www.ltesting.net/