从用例到代码：用例分析(6)

　　在这里，我们要对每个分析类进行处理。类的职责描述了这个类在系统中所提供的服务，而且其它类不会重复提供这些服务。各个类的职责不能重叠。

　　根据我们对汽车租借领域的理解，和对汽车租借专家、业务分析专家一起工作，我们在表3中，写出了我们对每个分析类的职责的理解。

　　表3：每个分析类的职责

　　James Rumbaugh与其它人 3 定义一个对象，或者说类，作为“一个概念，抽象，或者一个对业务来说有意义的，具有清晰定义的东西【我的重点】”。在类的职责定义中，首先要注意“清晰定义”，就是指明确指定了可以做什么，不可以做什么。

　　如果我们定义的职责出现错误怎么办?我们再重复一次，这无关紧要。我们已经开始，并且在不断取得进展。当我们对系统了解的更多之后，我们对类的职责作出些调整是很正常的。这样才能帮助我们把建模工作和软件做的更好的。

　　用例分析第五步：建立分析类之间的关系

　　我们已经确定了类的职责，下面将会设计一张UML类图作为起点，来找出分析类之间的关系。 建立类图有四个简单的步骤：

　　确定要进行建模的类(我们已经完成了)。

　　确定哪些分析类具有与其它类之间的关系。

　　对于任意两个之间具有关系的类，确定关系的语义 ：是关联、聚合、合成还是继承?

　　对于非继承关系，确认关系的多样性(指另一个类的多少个对象可以被关联到这个类的一个对象上面，类似于数据建模中的概念。)

　　通过以上步骤，加上我们前面确定的类的职责，我们得到了UML类图，如图6：

　　图6：汽车租借系统的类图

　　这个类图上有三种UML关系，用不同的线区分出来。简单的实线表明是关联关系。用来表明两个类之间的点对点的关系，每个类都会调用另一个类提供的操作。

　　在线上用实心菱形表示，在预约和保护产品之间的是合成关系(或者说不可共享的聚合关系)。这是个整体/部分的关系，或者说是一种拥有的关系。在这张类图上，合成关系表示预约拥有管理0个或者多个保护产品，这些保护产品被预约所拥有。更进一步来说，合成关系表明如果预约这个对象被销毁了，他所拥有的保护产品也必须被销毁，因为当保护产品不再是预约的一部分之后， 就失去了存在的意义。

　　在线上用空心菱形表示的，在汽车租用和汽车之间的是聚合关系(或者说，可共享的合成关系)。这也是个整体/部分的关系，或者说是一种拥有的关系，但是当我们销毁汽车租用的时候， 我们并不销毁汽车。这符合常理：因为汽车不出租时， 汽车对象会暂时成为“孤儿”，但是并不被销毁，只是把它提供给另一个汽车租用。

　　在关系两头的数字和* 符号叫做多样性描述。这些符号表明有多少个实例可以被连接到一个实例上。例如可以和一个顾客有关联关系的汽车的数量。或者，反过来，可以和一辆汽车有关联关系的顾客的数量。在这个类图里面，我们的多样性表明“对每位顾客，可以没有汽车预定，也可以有多项汽车预定”。反过来，就是“对每辆汽车，可以没有顾客预定，也可以有多个顾客预定”。

　　在分析中，我们试图确认，我们能够正确的表述和理解问题。对业务专家和分析专家来说，分析类图是一个有用的工具，帮助他们和技术人员一起审查设计，并且将设计进一步推进。

　　现在我们有了类，职责和一张显示类间关系的结构的类图。但是迄今为止，我们还没有涉及类的内部-没有操作和属性。而且类图是静态的。我们如何确认这些类能够完成我们在用例中描述的业务过程?这就是下一步的目的，这是一个非常重要的步骤，因为它将会把用例描述映射到分析类的潜在的操作上面。

　　用例分析第六步：确认分析类的行为

　　这些类如何协作完成预定一辆汽车这个用例?我们用UML交互图来找出分析类之间的这些交互动作。回忆一下前面提到的顺序图和协作图，就是两种交互图，它们是我们的用例实现的一部分，如图7所示，这是一张分析级别的顺序图，描述了预定一辆汽车这个用例。

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