equence diagrams are used to map out class interactions. A sequence diagram is made up of objects, each with its own object lifeline. Interactions between the objects occur by messages that are sent from one object to the next. By convention, the messages are sent from left to right across the flow of a diagram, with the message returns being sent back right to left. There are situations where two objects are communicating back and forth or in sequence diagrams with multiple sets of actions where the messages will not follow the convention but those should be minimized as much as possible. Objects can create and destroy other objects; they can communicate synchronously and asynchronously; and act upon themselves.
Sequence diagrams augment the class, component, and deployment diagrams by showing the sequence of activities that occur between two or more objects. This helps when defining the behavior for the methods in the class diagrams.
Figure 1 shows a typical sequence diagram with four objects. Object3 is creating and destroying Object4. There is both recursive and self-calling messages on Object1 and Object2's lifelines, respectively. Notice the diagonal line that occurs when there is a time delay between Object1 and Object2. The diagonal lines will often occur in diagrams when the emphasis is place on the network delay between two objects communicating. In most sequence diagrams the lifelines will extend to the end of the page except when one object controls the lifetime of the other.
Richman's New Method for Communicating with Clients
|Figure 1. Example Sequence Diagram: The example diagram shows four objects and various actions between them.|
In my last article
, I developed a component diagram for viewing the value of a stock. At the time, my fictional company, Richman, Inc., was only concerned with its brokers using the site. However, in a later release executives decided they wanted some method of communicating with clients directly. In this article, I'll attempt to evolve the models to accommodate these changing requirements.
Before deciding on the technology changes, I will use a sequence diagram to show the relationships between some of the already existing classes. One of the requirements for communicating with the client is to allow the client to get the value of one of his orher securities (see Figure 2).
Notice in Figure 2 that objects can also have stereotypes and that the three objects are not named except for their class type. (Stereotype has the same meaning for sequence diagrams as it does for the class diagrams. A stereotype is the method in UML for classifying an object type. In Figure 2 I use the <external> classifier to show that the quote server is a third-party object.) The actual return isn't critical here but it is possible to add the return value to the return message. The Client object also continues to do work after the value is returned.
The client class requests the value of a security given a security's name as a parameter. The Portfolio object receives the security's name and then gets the current price of the security from the external quote vendor. Some work is done in each case by the classes and then the price is returned first to the Portfolio and then to the Client.
Figure 2 would be sufficient if I am getting the value of a single unit from the Portfolio only. The requirement could also be to get the combined value of that security (based on shares owned). From the sequence diagram this is not clear.
Figure 2. Sending Quotes: The sequence diagram shows the internal method for Richman Inc. to send securities quotes to its clients.
Figure 3. Total Value: Here I've added a recursive value calculation to Figure 2 to emphasize that there is work to be done in adding up all the security prices and returning the value once the quote is known.
In Figure 3
I've added to the diagram in order to indicate that a value calculation needs to be performed. Although it still isn't completely clear, at least I know that there is a separate step to calculate the security's value, which can be easily refactored later if it isn't correct.
Thus far, the sequence diagrams do not address how I am going to communicate with the client. I want to keep the functionality of the current method of communicating with the internal brokers from the last article but I also want the ability to work with the client directly. To accomplish this I've decided to use a Web service.