如果我们定义的职责出现错误怎么办?我们再重复一次，这无关紧要。我们已经开始，并且在不断取得进展。当我们对系统了解的更多之后，我们对类的职责作出些调整是很正常的。这样才能帮助我们把建模工作和软件做的更好的。
用例分析第五步：建立分析类之间的关系
我们已经确定了类的职责，下面将会设计一张UML类图作为起点，来找出分析类之间的关系。 建立类图有四个简单的步骤：
确定要进行建模的类(我们已经完成了)。
确定哪些分析类具有与其它类之间的关系。
对于任意两个之间具有关系的类，确定关系的语义 ：是关联、聚合、合成还是继承?
对于非继承关系，确认关系的多样性(指另一个类的多少个对象可以被关联到这个类的一个对象上面，类似于数据建模中的概念。)
通过以上步骤，加上我们前面确定的类的职责，我们得到了UML类图，如图6：
图6：汽车租借系统的类图
这个类图上有三种UML关系，用不同的线区分出来。简单的实线表明是关联关系。用来表明两个类之间的点对点的关系，每个类都会调用另一个类提供的操作。
在线上用实心菱形表示，在预约和保护产品之间的是合成关系(或者说不可共享的聚合关系)。这是个整体/部分的关系，或者说是一种拥有的关系。在这张类图上，合成关系表示预约拥有管理0个或者多个保护产品，这些保护产品被预约所拥有。更进一步来说，合成关系表明如果预约这个对象被销毁了，他所拥有的保护产品也必须被销毁，因为当保护产品不再是预约的一部分之后， 就失去了存在的意义。
在线上用空心菱形表示的，在汽车租用和汽车之间的是聚合关系(或者说，可共享的合成关系)。这也是个整体/部分的关系，或者说是一种拥有的关系，但是当我们销毁汽车租用的时候， 我们并不销毁汽车。这符合常理：因为汽车不出租时， 汽车对象会暂时成为“孤儿”，但是并不被销毁，只是把它提供给另一个汽车租用。
在关系两头的数字和* 符号叫做多样性描述。这些符号表明有多少个实例可以被连接到一个实例上。例如可以和一个顾客有关联关系的汽车的数量。或者，反过来，可以和一辆汽车有关联关系的顾客的数量。在这个类图里面，我们的多样性表明“对每位顾客，可以没有汽车预定，也可以有多项汽车预定”。反过来，就是“对每辆汽车，可以没有顾客预定，也可以有多个顾客预定”。
在分析中，我们试图确认，我们能够正确的表述和理解问题。对业务专家和分析专家来说，分析类图是一个有用的工具，帮助他们和技术人员一起审查设计，并且将设计进一步推进。
现在我们有了类，职责和一张显示类间关系的结构的类图。但是迄今为止，我们还没有涉及类的内部-没有操作和属性。而且类图是静态的。我们如何确认这些类能够完成我们在用例中描述的业务过程?这就是下一步的目的，这是一个非常重要的步骤，因为它将会把用例描述映射到分析类的潜在的操作上面。
文章来源于领测软件测试网 https://www.ltesting.net/
