从用例到代码：用例分析(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