Create a sequence diagram of the interaction between a receptionist and a customer in a hotel business.

Like Use Case diagrams, you use Sequence diagrams to model scenarios in the system. They offer a different level of detail:

In a Sequence diagram, an object appears on the diagram as a vertical dashed line with the name of the object at the top and the name of the object's class optionally drawn below the object name. Events appear as horizontal lines between objects. Event lines are drawn in chronological order: from the top of the diagram to the bottom. They do not necessarily have a one-to-one correspondence with the steps defined for a Use Case scenario.

To show the implementation details of a scenario, you can choose to draw either a Sequence or a Collaboration diagram, or both. System Architect automatically creates a Collaboration diagram from a Sequence diagram, and vice versa, when you invoke the Synchronize Diagram command from the Draw menu.

The Use Case technique has become a popular vehicle for finding objects during an object-oriented analysis of a system. After modeling the scenarios for the way a system works or should work, you can then examine those scenarios to find the objects necessary for the scenarios to take place.

One way to find objects is to examine the textual description or steps of every Use Case. Consider nouns in the textual description to be classes or class attributes and verbs to be methods of the classes.

For example, in the Make Reservation Use Case, in order for a Customer to request a reservation, two objects are necessary: Customer and Reception. In order for the step Check Diary for Room Availability to occur, the objects Room and Diary must exist. In order for the step Customer accepts accommodation to occur, the objects Customer and Room must exist, and so on. Looking at the steps of Make Reservation, you highlight possible objects in bold, possible class attributes in bold underline, and possible methods in italic.

Create a Sequence diagram, and make it a child of the Use Case diagram you created in the earlier section.

This will create a hypertext link between the two diagrams. For this tutorial, your Use Cases were in the Business Use Case View package. Build the Sequence diagrams in a Reservation System package in the Logical View package.

Add the other objects that you found in the steps of the Make Reservation Use Case: Reception, Reservation, Diary, and Room.

To add the object Reception, use a different technique than that used previously–reuse the class Reception of the package Reservation System that has been preloaded into this project encyclopedia.

Message/Stimulus lines are drawn between objects to show how and when they communicate. These lines (which you can refer to simply as message lines) are drawn chronologically from the top of the Sequence diagram to the bottom.

The message line represents a message sent from one object to another, in which the 'from' object is requesting that an operation be performed by the 'to' object. The 'to' object performs the operation using a method that its class, or one if its superclasses, contains. Later in this tutorial, you can specify the method that a 'from' object is requesting the 'to' object to invoke. First, concentrate on the messages passed between the objects:

The UML notation for showing that an object on a Sequence diagram is created is to draw a message line into the head of the name box at the top of the object lifeline. To show that Reservation is being created in this scenario, you will move the Reservation object lifeline downward so that you can draw a line into its header box.

The Reservation object compute its price and notify Reception, which will advise the Customer (Diary is not involved in this pricing process). If the Customer accepts the terms, Reception is notified, which reserves the room in the diary. Diary updates the Reservation status to Reserved.

The Sequence diagram should now look like the following:

A focus of control rectangle, or activation bar, is drawn on an object lifeline to show the period during which the object is performing an action. The activation bar represents both the duration of the action in time and the control relationship between the activation and its callers. The terms 'focus of control' and 'activation bar' are interchangeable.

When one object sends a message to another object, it is in essence asking it to do something. The object receiving the message must be able to perform this task and return an answer to the sending object. The receiving class performs an operation - it uses a specific method to perform this operation. This method can be represented in a programming language such as Java or C++ or Visual Basic.

On the Sequence diagram, you can specify what method is 'invoked' by the sending of a message from one object to another. The method invoked belongs to the class that the receiving object instantiates. In System Architect you can specify what method is associated with each message in the definition of the line. This method should become part of the 'to' class definition, or the definition of a superclass of the 'to' class.

At an early stage of analysis, you would normally not spend too much time figuring out the methods invoked; this would be performed at a later stage of design, when you would return to this diagram. For time's sake, in this tutorial, you can add methods at this point.

Model the following: when Reception sends the message Check Room Availability to the object Diary, the method getAvailability is invoked. To reserve the accommodation, you need a start date, the duration of the stay, and the room type. These will be parameters of the method:

Next, add the method invoked by the message Provisionally Book Room that is sent from Reception to Diary.

First add this method to the Diary class:

In this lesson you learned how to: