Exam zone
Sequence diagram Objects, Lifelines, Messages, and other odds and ends. Figure 4-1 shows a typical sequence diagram. The objects involved in the collaboration are shown at the top. The stick figure (actor) at left represents an anonymous object. It is the source and sink of all the messages entering and leaving the collaboration. Not all sequence diagrams have such an anonymous actor, but many do.
The dashed lines hanging down from the objects and the actor are called lifelines. A message being sent from one object to another is shown as an arrow between the two lifelines. Each message is labeled with its name. Arguments appear either in the parenthesis that follow the name, or next to data tokens (the little arrows with the circles on the end). Time is in the vertical dimension, so the lower a message appears the later it is sent. The skinny little rectangle on the lifeline of the LoginServlet object is called an activation. Activations are optional; most diagrams don’t need them. They represent the time that a function executes. In this case it shows how long the login function runs. The two messages leaving the activation to the right were sent by the login method. The unlabeled arrow shows the login function returning to the actor, and passing back a return value. Note the use of the e variable in the getEmployee message. This signifies the value returned by getEmployee. Notice also that the Employee object is named e. You guessed it, they’re one and the same. The value that getEmployee returns is a reference to the Employee object. Finally, notice that EmployeeDB is a class, not an object. This can only mean that getEmployee is a static method. Thus, we’d expect EmployeeDB to be coded as in Listing 4-1.
Creation and Destruction We can show the creation of an object on a sequence diagram using the convention shown in Figure 4-2. An unlabeled message terminates on the object to be created, not on it’s lifeline. We would expect ShapFactory to be implemented as shown in Listing 4-2.
In Java we don’t explicitly destroy objects. The garbage collector does all the explicit destruction for us. However, there are times when we want to make it clear that we are done with an object and that, as far as we are concerned, the garbage collector can have it. Figure 4-3 shows how we denote this in UML. The lifeline of the object to be released comes to a premature end at a large X. The message arrow terminating on the X represents the act of releasing the object to the garbage collector.
Listing 4-3 shows the implementation we might expect from this diagram. Notice that the clear method sets the topNode variable to nil. Since the TreeMap is the only object that holds a reference to that TreeNode instance, it will be released to the garbage collector.
Simple Loops You can draw a simple loop in a UML diagram by drawing a box around the messages that repeat. The loop condition can appear somewhere in the box, usually at the lower left. See Figure 4-4.
This is a useful notational convention. However, it is not wise to try to capture algorithms in sequence diagrams. Sequence diagrams should be used to expose the connections between objects not the nitty gritty details of an algorithm.
Cases and Scenarios Rule: Don’t draw sequence diagrams like Figure 4-5 with lots of objects and scores of messages. Nobody can read them. Nobody will read them. They’re a huge waste of time. Rather, learn how to draw a few smaller sequence diagrams that capture the essense of what you are trying to do. Each sequence diagram should fit on a single page, with plenty of room left for explanatory text. You should not have to shrink the icons down to tiny sizes to get them to fit on the page.
Also, don’t draw dozens or hundreds of sequence diagrams. If you have too many, they won’t be read. Find out what’s common about all the scenarios and focus on that. In the world of UML diagrams, commonalities are much more important than differences. Use your diagrams to show common themes and common practices. Don’t use them to
document every little detail. If you really need to draw a sequence diagram to describe the way messages flow, then do them succinctly, and sparingly. Draw as few of them as possible. First of all, ask youself if the sequence diagram is necessary at all. Code is often more communicative and economical. Listing 4-4, for example, shows what the code for the Payroll class might look like. This code is very expressive, and stands on its own. We don’t need the sequence diagram to understand it. So perhaps there’s no need to draw the sequence diagram. Perhaps the code is good enough to stand on its own. When code can stand on its own, then diagrams are redundant and wasteful.