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.

Figure 1. Example Sequence Diagram: The example diagram shows four objects and various actions between them.

Richman’s New Method for Communicating with Clients
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 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.

Web Services in UML
The Web service is a new paradigm in how classes communicate. Web services are comprised of three functions: the service, the directory, and the consumer. The service is published to the directory so that the client can locate it and bind with the service.

The service class contains the methods or operations that are called; the directory publishes the Web service and its methods so that they can be looked up by an outside consumer. The consumer binds with the Web service so that it can call the services methods or operations remotely (see Figure 4).

My fictional company, Richman Inc, decided that it would send its technology-savvy customers a URL to the Web service. To access a Web service requires an interface called a proxy. The proxy is built by accessing an XML file containing information about the service, its methods, and port information. The XML is in a standard format WSDL (Web services description language).

The XML file is stored with the service and can be accessed by adding “?WSDL” next to the URL link. The WSDL itself is auto-generated from Visual Studio by adding the attribute [web method] to a service class. Once a WSDL file is downloaded by the consumer it can be turned into a proxy using the command line “wsdl.exe .WSDL” and compiling the results.

Figure 4. Components: The image is a class diagram showing the three components to a Web service.

Figure 5. Sequence Diagram for Richman’s Web Service: IIS will create an object QuoteService of the class Portfolio and then destroy the object when it is finished.

Richman’s New Web Service
Richman’s first Web service, shown in Listings 1 and 2, will implement the quote-retrieval process from Figure 2. It comprises only the service (Listing 1), which exposes the operation represented by the class containing the [webmethod], and the proxy (Listing 2), which the consumer uses to bind to the service.

In the auto-generated class used by the client (see Listing 2) there is a binding to the URL for the Richman Web service: http://localhost/richman/quoteservice.asmx. The second part is the “this.invoke(“RequestStockValue”, new object[] {SecurityName})” statement. From a practical standpoint you are accessing the Web service using IIS, which will take care of instantiating an new object calling the “RequestStockValue” on the new object, returning SecurityName and deleting the object (see Figure 5).

Figure 6. Simplified Sequence Diagram for Richman’s Web Service: There is no more need for IIS to be shown; the creation and deletion for QuoteService is left out.

Figure 7. Fragments: This is a replacement for the recursive call in Figure 3. The fragment AddingTrades uses a looping construct to get a trade from the database return it and add it to a counter until there are no more trades (for each trade in trades).

A single Web service can be complicated. In most cases this detail in Figure 5 is not necessary and only the parts of the Web service that show the method calls from the client to the Web service are needed. I decided to simplify the original sequence diagram in this example to one that showed the client, the service class, and the calls to the external quote engine (see Figure 6).

Adding Fragments
The 2.0 version of UML adds a feature called fragments to sequence diagrams. Fragments are pieces of a sequence diagram that are encapsulated by a programming construct. Programming constructs include alternative choices, options, breakpoints, parallel actions, critical regions, assertions, and loops. Other fragments include weak sequencing for when order doesn’t matter, messages that cannot occur, messages that the fragment cannot handle, and a number of others. Fragments are an article unto themselves, but an example is shown in Figure 7.

Wrapping Things Up
This article is the last of a six-part series on UML for the software developer. My purpose was to give you an introduction to how UML can help with the software development process. If you take nothing else away from this series, here are some important rules of the road for modeling using UML:

• Adapt the modeling style to the environment and not the environment to the modeling style. There is no one style that works in all software development environments. In agile methodologies the style is more communication-based, with the approval process being based on the code produced and not the model itself. This whiteboard style is quick and informal. RUP and other more architectural methodologies are formal, with approval occurring on the models, not the code. This is sometimes referred to as blueprinting.
• Build your models to the intended audience. Be prepared to display the same model to different stakeholders. This might mean that there are two versions of the same model.
• Have an adoption path for UML. Reading an article or a book is not enough. Start with something small and manageable and figure out how to diagram it. For larger organizations it helps to have some training to kick-start the process but then have some type of reinforcement in the actual environment.
• Use the model; don’t merely rely on it for documentation. Modeling can open up new ideas and find flaws in a project that are missed in code. In my own experience this has been extremely valuable. In most cases a software architect or senior-level developer will develop the diagram and we will roundtable it with some of the other architects and come out with much stronger solutions. However, I rarely look at the diagrams once the coding has started.

In this series I covered classes, associations, components, deployments, and sequences. This composes the heart of UML. There was also coverage on n-tier development, patterns, architectural patterns, and Web services from a design perspective. I chose not to focus on a particular version of UML or to deal wit the low-level issues of syntax. See the sidebar, “Additional Reading on UML,” for my hand-picked list of great books for the software developer learning UML.