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