4 时序图

    本节讨论的时序图把设计带入比类图更低的抽象层次(更高层次的细节)。时序图必须清晰反映组件之间的交互。

    4.1 定时

    定时问题使得协议转化为时序图和之后转化为状态图的过程变得困难。在协议描述中，同一时刻会发生一个或多个动作，即使这些动作在某种原因下相关也是如此。例如，聊天室不应该在收到请求之前发送接收或拒绝消息。这样的话，输出迹中出现“在时刻1请求;在时刻1接收”就是正确的，如果出现“在时刻1接收;在时刻1请请求”，那就是不正确的。

    一种可能的解决方案是使用tuple(t, s)表示时间，t是以秒计数的浮点时间，s是整数序号。以这种方式，正确的输出可以写成“在时刻(1.0s, 0)请求;在时刻(1.0s, 1)接收”。序列“在时刻(1.0s, 0)接收;在时刻(1.0s, 1)请求”则是不正确的。

    4.2 请求和消息模式

    请求模式如图二所示。Client首先会调用Manager的方法mrequest。然后Manager通过调用ChatRoom的方法request中继这个调用。ChatRoom立刻响应，回调Manager的方法maccept或mreject。然后请求Client会接收到由Manager中继的响应。

    图三是消息模式，在系统中随机产生消息，进行传递。注意ChatRoom在收到一次请求后故意延时一秒钟。在这两个时序图中，没有其它延时存在。

    4.3 类图和协议之间的一致性问题

    与类图之间的一致性是容易检查的，可以通过收集组件接收到的所有方法调用来达成。例如，在请求模式中，Manager接收mrequest、maccept和mreject。在消息模式中，它接收msend和mbroadcast。这五个方法在类图中都有定义，但没有定义其它的公有方法。由于时序图中并没有给出参数，那样就没有检查参数的必要。检查过程可以自动化。可以部分检查协议的一致性。从请求时序图中很容易就能看出，聊天室在时刻0收到一个请求，在时刻0接收或拒绝这个客户。这两个时刻的绝对值并不重要。重要的是，回复确实会在同一时间发回。这样设计者就可以手工检查“某个时间应该会发生什么”。如果用到后面讨论的基于规则的方法，有限的自动检查也是可以做到的。

    注意基本的时序图无法表达某个时间或某个阶段不应该发生的事情。比方说，协议中会含有这样的意思，聊天室在没有收到请求时不会接收或拒绝客户。时序图中不会包含这样的信息。这会在模型中带来设计错误，影响后续开发步骤的正确性。另一种可能的设计错误是时序图的语义。例如，在请求模式中，时序图描述：如果客户发送mrequest，管理器没有时间前置地发送request，聊天室发送maccept或mreject，也没有时间前置，然后管理器发送accept或reject。不幸地是，迟钝的客户不会发送任何请求，这显然是系统当中的一个问题，不能通过检查时序图检测出来。最坏的情况是根本没有客户连接，这样系统就会永远停机。为了补偿信息丢失，需要UML形式化体系中的其它设计，它们并不完全依赖时序图，或者就要对时序图进行扩展。一个极好的使用时序图并引入扩展的例子是Live Sequence Charts，参见Harel的文章[1]。