UML序列图中消息的交互情况
序列图用于展现各参与方为达成某一行为所开展的交互以及时间顺序,其中的交互依靠消息来实现。消息是从一条生命线到另一条生命线的通信,通常呈现为水平或倾斜向下的箭头,从发送方生命线出发,指向接收方生命线。若有必要,这些消息中能够传递参数值,但需保证参数类型和值与接收生命线角色所定义的操作相匹配。
1.同步消息及其返回消息
用带有实心箭头的实线来表示同步消息。发送方生命线向接收方生命线发送同步消息后,发送方会进入等待状态。同步消息的返回消息采用带有V形箭头的虚线表示,由接收方生命线指向发送方生命线。一般而言,同步消息通过发送方调用接收方的操作来达成。图1呈现了同步消息的发送与返回过程。
发送方在向接收方发送同步消息后需要等待返回结果,但这并不意味着发送方一定会被阻止发送或接收其他消息,UML序列图允许非阻塞的同步行为。建模者要明白,序列图中的参与者是角色而非实例,所以发送方可能存在多个部分或包含线程,当前的等待或许仅仅是阻塞其中一个。要是发送的同步消息能够明确其返回消息的信息,或者在当前所表达的行为里不需要特意展现返回消息,那么在序列图中可以省略返回消息的绘制。要是建模的是概念性的序列图,那么同步消息仅仅意味着发送者确保接收者收到了消息;否则,它表示发送者正在调用接收者的一个操作,并且发送者会等待响应。消息名称放置在箭头上方,遵循接收者定义的操作语法。被调用的操作必须是接收者“操作”的成员,或者是从接收者的超类中继承而来的。操作的参数可以根据场景给出合适的值。
2.异步消息
用带有V形箭头的实现来表示异步消息。发送异步消息时,发送方不会等待回复。而接收方必须是一个活动类,异步消息可以是硬件或软件中断。大多基于Web的交互是从浏览器到服务器的异步消息,随后是另一个方向的异步消息。
异步消息可以是异步方式调用的操作(许多编程语言提供了异步操作定义机制),也可以是发送的信号。由于无法回复,异步消息不能有返回值或输出参数。图2展示了一个唤醒信号(Wakeup),信号只能有输入参数,可以将这些参数列在信号的独立分隔栏中。在图2中,唤醒信号的参数是message:String。信号也能够在状态图和活动图中展示。
图3展示了一个系统类,它是活动类(可选地通过双竖线边框表示)。在其单独分隔的“接收(RECEPTIONS)”栏中,展示该类能够接收的信号,形式类似操作的格式。在图3中展示了唤醒(Wakeup)信号。
在序列图中使用信号的示例如图4所示,生命线Lifeline1向System发送了一条异步消息,该消息为上述所定义的信号Wakeup。异步消息必须是接收者“接收”的成员,或者从接收者的超类继承而来。要是建模的是概念性的序列图,那么异步消息仅仅意味着发送者不等待响应。此外,接收者类必须是一个活动类,尽管一些建模者在建模时并不会特意将接收者使用表示“活动”的表示符号(即双竖线边框)。
3.自消息
自消息是指来自参与者自身的消息,可能是发送给其独立的内部部分或线程。自消息从一条生命线上发出并到达同一生命线。自消息可以是同步或异步的,建模时能够像同步消息或异步消息那样通过箭头类型进行区分。对于同步的自消息还可能存在类似同步消息的虚线返回箭头。
图5所示的序列图在Lifeline1上展示了同步自消息,在Lifeline2上展示了异步自消息。