Sequence Diagrams
Class diagrams show how classes interact with each other, but they do not give you a feel for how instances of those classes will interact in a real situation. Instead, sequence diagrams model this type of behavior. These diagrams do this by showing objects and the messages that pass between these objects. In this appendix, you will learn the UML syntax for sequence diagrams by exploring two examples, the first of which is shown in Figure A.10.
Figure A.10. Sequence Diagram #1.
This first example shows most of the commonly used UML syntax for sequence diagrams. You place actors and boxes that represent objects or classes when their static methods are accessed at the top of the diagram. Descending from these items are dashed vertical lines that represent the life of the item. These lines are known as lifelines. The rectangles these lines pass through are activations, and these represent the time the objects require to do their work. The horizontal arrows represent messages—the communication between items that you model.
As you can see, the actor sends a message to the first object, and the message in this instance take the form, “Wishes to…”—just a plain text description of the interaction. For example, this first object could be an instance of a servlet that the user calls. The first object then sends a message to the second object. In the diagram, the message is labeled <<create>>, which illustrates that the first object creates the second object. Likewise, the first object sends another message to the second object, but this time toward the end of its activation. This message is labeled <<destroy>>, and the lifeline of the second object is marked with a large X. This signifies that the first object deletes the second object. The other type of message that is used frequently, but is not shown in Figure A.10, is where the message label represents the name of the method an object calls on another object or class.
Figure A.11 shows a sequence diagram where a user wants to access some service of the system that requires authentication. The user sends a message to the Controller object, stating that he or she wants to access the system. This object creates an instance of the Authenticator class. The user then supplies this object with his or her username and password. The Authenticator receives these credentials and calls the static isEmployee() method of the Employee class. Notice how the message label in this instance is the method name together with a comma-separated parameter list. The isEmployee() method performs some form of processing on the parameters. In reality, this might involve looking up information in a data store. However, the example is simplified in this instance, so assume that this method does not require the services of any other class. You will notice that up to this point, all the UML syntax is the same as that shown in the previous example.
After the isEmployee() method finishes its work, it returns an Employee object to the Authenticator object. As you can see, the UML syntax for this is a dashed horizontal line that points to the calling class or object and an optional label that indicates what is returned. At this point, the Authenticator object returns the Employee object to the Controller object. It then sends a <<destroy>> message to itself. This type of message is known as a self-call and is shown as a message arrow that leaves an activation and then doubles back to return to that activation. That's it; the sequence is complete.
The two previous examples show you the majority of the UML syntax you require to draw and understand sequence diagrams. The only other syntax that you may need to know relates to messages. Specifically, all the messages shown in this appendix have full arrow heads. This signifies that the messages are synchronous—the caller ceases operation until the called object returns. In reality, you might want to model situations where you require asynchronous messages. For example, you may have an object that creates new threads so that it can carry on with some other processing. To markup these types of messages, you show a half arrow head rather than a full arrow head.