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

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

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

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

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

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

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

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

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

　　我们可以这样命名：

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

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

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

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

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