# 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.