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

发表于:2015-05-05来源:uml.org.cn作者:不详点击数: 标签:用例分析
图7: 预定一辆汽车的分析阶段的顺序图 你会看到,在这个图中我已经引入了一个非业务类-UCController。这个用例控制类表示的是一个尚未进一步定义的类

  图7: 预定一辆汽车的分析阶段的顺序图

  你会看到,在这个图中我已经引入了一个非业务类-UCController。这个用例控制类表示的是一个尚未进一步定义的类,它的职责是从用户那里接收事件和消息。我发现大多数读者都会感到困惑:一个业务类(例如出租地点或者预约)来接收用户的消息?因此我通常会给我的分析交互图增加一个通用的用例控制类,来表示这个逻辑,而且方便了读者的理解。在设计阶段,我们会把这个类改名为 ReserveAVehicleController,但是现在我用这个通用的名字UCController 来表示。

  顺序图和交互图包括几乎相同的内容,它们只是表示方式不同而已。选用哪一种图主要取决于是否方便和个人偏好。在顺序图中,对象按竖列对齐,按照从上到下的时间线来顺序排列。标了数字和文字的水平线叫做消息。在一个顺序图中,消息的顺序用它们的位置来表示:按照时间顺序从上到下排列,因此排在下面的消息就在排在上面的消息之后发生。消息从一个对象的时间线上开始,在一条时间线上终止(一般都是另一个对象的时间线),但是有时也会终止在同一个对象的时间线上,如图7中的消息21。

  顺序图与协作图相比,有一个非常明显的优点,就是在图左边的脚本。这些文字是从用例,或者场景中摘取的,对顺序图的描述。这些描述就是对预约汽车这个用例的一个简短的描述。通过把这些脚本放在图边,使得消息的含义变得非常清晰。而且把消息、对象和原先的用例相结合起来。用例中的每条语句都会对应图中的一个或多个消息,在顺序图上,这表示的非常清楚。

  我想强调一下,在分析阶段的交互图中很重要的一点就是:消息表明了意图,而不是实现,也不是接口在预约汽车顺序图上,消息只是简单的表明了,我希望接收消息的对象做什么事情,消息并不代表一次函数调用。函数调用这些更具体的信息,会在设计阶段确定。但是现在,我们只需要在这个用例中,类的职责。

  我们如何找出这些消息呢?只要看看我们的职责的定义就可以了。例如,在第八步中,租借地点要决定在这个地点,哪些汽车是可用的。在第九步中,汽车租借要提供在这个地点,能够满足用户要求的日期和时间的所有汽车。在第十步,租借中的每个汽车都需要回答它本身是否满足某些租借条件。请注意所有这些知识都不在租借地点这个对象中。我们把这些知识分布到了我们的所有分析类当中,因此每个类都可以按照定义来完成一部分工作。

  UML说明:对象-是否需要命名?

  在顺序图中,对象框没有名字“:”,这些对象叫做匿名对象。但是也可以为对象起一个名字。如果我们有一个类叫做Account,我们可以这样命名:

  我们可以这样命名:

A
c
c
o
u
n
t

  如果我们建立两个Account类的实例对象,FredsStash和EthelsMadMoney,它们将是这样:

FredsStash : Account EthelsMadMoney : Account

  以左边的一个为例,表明“FredsStash是Account类型的一个对象”。 如何决定是否给一个对象命名呢?如果系统中的一个实体类,有一个很清楚的名字,你可能想为它的对象起一个名字。如果你的图中有一个示范的对象(类似于数据模型中的数据表例子),你也可以用一个有名字的对象。但是对大多数情况来说,匿名对象就足够了。我们只关系类和对象提供了什么服务,致于对象的名字并不会影响到对象的行为。

  用例分析第七步:描述属性和关系

  在分析中,我们会发现,类为了完成自己的职责,会需要一些属性(也就是类的属性变量)。从类的职责列表中,我们可以确定分析类的一些属性。另外一些属性要从常识中得出(例如,每个汽车对象应该有一个独一无二的标识属性,与实际的汽车上的汽车联盟的标准汽车编号相对应)。

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