从用例到代码:用例分析(5)

发表于:2015-03-13来源:uml.org.cn作者:不详点击数: 标签:测试用例
图5:用来寻找分析类的问题 如果某一个答案是不是,那么这个候选词很可能不是一个类。再继续检查下一个词。如果答案是是的,那么继续检查下一个问

  图5:用来寻找分析类的问题

  如果某一个答案是“不是”,那么这个候选词很可能不是一个类。再继续检查下一个词。如果答案是“是的”,那么继续检查下一个问题,如果所有的问题的答案都是肯定的,这个候选词就是一个类。再继续检查下一个词。

  我们对每个候选词做检查,就会得到类似于表2的结果:

  表2:名词检查结果

  请注意租借地点已经被加进去了,虽然它不是用例的一部分。在与我们的业务专家(Subject Matter Experts,SMEs)们谈话时我们发现,业务中会使用 地点来指代一个地址,或者一个租借部门。为了不致于混淆,我们一致统一使用单词租借地点来表示业务地点,也就是发生租借和归还的地方。

  从这个列表中,我们列出了通过了问题检查的词,也就是下面列出的分析类:

  啊哈!在总共得30多个候选中,现在我们只需要面对选出的8个分析类。前面的四个问题帮助我们缩小了搜索范围,是个很有效的工具。

  但是我们有没有犯错呢?有没有漏过某个真正的类,或者把一个不该作为类的词加进来了?这并不重要。RUP的迭代特性,会逐渐暴露出我们犯过的错误,并允许我们用尽量小的代价来修正它们。分析和设计的目标不是先把一切事情设计的很完美,而是当你需要确认这些事情的时候,才去确认这些。开始阶段往往是最困难的,我们现在实现了对象(或者说类)从无到有的突破!重要的是我们已经起步了,而且我们能够按照面向对象的方法一步一步的取得进展。

  我们现在完成了RUP的用例分析活动中的前三步:

  对每个用例

  建立一个用例实现

  补充用例描述(如果需要的话)

  从用例行为中,找出分析类

  如果我们严格按照RUP过程进行,下一步应该是:

  把行为分配给分析类

  基于以下理由,这一次,我又会对RUP过程做一点小的改动:回顾一下我们的进展。我们刚刚找到了8个实体类,我们认为这些都是我们系统中的类。在我们做下一步之前,我们需要给这8个实体类增加一些内容,来确认他们是类。

  有三种基本的方法来充实我们的分析类:

  数据驱动的方法

  行为驱动的方法,和

  职责驱动的方法。

  数据驱动的方法对于从事数据库工作,或者从事过程语言编程的人员来说很常见。他们就是用数据和数据之间的关系来认识、描述世界的,因此会首先去寻找类中的数据-一般没有什么标准的方法去寻找类的函数或功能。这看起来不错,但是数据只是工作的一半。实际上, 类的准确定义,包括了数据和对数据进行的操作。

  行为驱动的方法有着双重的成立理由。首先找出类执行的操作,从中决定这些操作涉及的数据中,哪些应该被这个类所拥有。这很棒,但是我们如何确认我们为类找出的操作之间能够保持一致呢?如何区分操作和类,以明确这个操作是属于这个类,但是 其它的操作要属于同一个类,还是其它的类?我们需要某种方法来区分各个操作。这就是职责驱动的方法带给我们的。

  职责驱动的方法是自上而下的,从总体的类及其职责的视图开始。首先定义一个类在业务中的“使命”,这个“使命”描述了这个类对外提供的服务。从军事术语上来说,就是责任和策略。操作和数据是战术层面上的(为战略服务的,服从于某些目标、策略的)。 2

  一旦我们确定了我们的类的职责,我们就可以设计一个分析类图,来描述类间关系的整体结构。这个结构一般都是由业务领域决定的。一个UML分析类图可以帮助我们可视化的把这个关系的结构表示出来。

  因此,我建议对标准的RUP过程做如下修改(次序的改变):粗体):

  对每个分析类

  描述类的职责

  在分析类图上,建立分析类间的联系

  把行为指定给分析类(找出操作)

  描述每个类的属性和关系

  定义类的属性

  描述分析类间事件的相关性

  用例分析第四步:描述类的职责

原文转自:http://www.uml.org.cn/Test/200904165.asp