1.6. Sequence Models in UML¶
Figure 1.6.1: A UML sequence model for a streaming media player execution
As noted previously, state models omit information about timing or the sequence of events that a
system encounters while it is running. UML sequence models provide a
different view of the system, by looking at the sequence of communication messages that are
exchanged during an execution of the system. Figure 1.6.1 shows an example of the messages that might
be exchanged between the streaming media player (whose states are those in Figure 1.5.1) and the
server that is providing the data to play. The player starts by connecting to the server; the
server’s response could denote the event that triggers the transition to the Connected state.
The player then starts requesting data in chunks of 16 KB, buffering the data until it is ready to
be played.
UML sequence models use lifelines to denote one entity’s perspective over time;
the start time would be at the top and later time is farther down. UML sequence models use a solid
arrow head (such as the Connect message) to denote synchronous messages, with the open
arrow head (such as the request for bytes 16384-32767) to denote asynchronous messages. The
distinction indicates whether or not the sender must wait while the message is sent or if it can do
something else during that time. For instance, it would make sense for the Connect and the first
request to be synchronous messages, because that connection and initial data are necessary to get
started. Then, once the system has started playing the buffered data, additional requests for more
data could be sent as asynchronous messages. Throughout this book, we will mostly be modeling
communication as asynchronous messages, which is common for concurrent systems.
Figure 1.6.1 illustrates three additional key features of UML sequence models.
First, the dotted message lines indicate that a message is a reply. This notation is
especially useful for synchronous messages to illustrate the linkage between the request and the
response. The Play Movie message is a self-message, which indicates a meaningful event
on that lifeline. That is, from that message, the movie is being played, as long as there is data
available. While the movie is playing, additional asynchronous messages are sent and more data is
received for buffering. Lastly, the message that ends at a circle between the lifelines denotes a
lost message. This notation indicates that the media player sent the message, but the server
did not receive it. This type of lost message is common in networked systems, as we will explore in
Chapters 4 and 5.
Throughout this book, we will use both UML state models and sequence models to illustrate key ideas in relation to concurrent systems. Understanding how to read and interpret these models is an important skill in this area. Unlike state models, however, there is no particular translation for sequence models. Specifically, the type of message that would need to be sent depends on the underlying form of communication, such as pipes or sockets, which we will discuss in later chapters.