RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


UML for the Software Developer, Part 6: Interaction Diagrams : Page 2

Interaction or sequence diagrams are the critical link between the static class diagrams and how the classes behave. A well-defined sequence diagram will find missing classes, elucidate the sequence of events for class interaction, and define the methods needed for each class.

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 <filename>.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.

Mark Goetsch is an Enterprise Software Architect with Wheels, Inc, and has more than fifteen years of experience in software development, enterprise modeling, and software architecture. He has another seven years experience as a trader, dealer, Broker, and an expert in e-trading. He was one of the enterprise modelers of the Tapestry Project at ABNAMRO, one of the most extensive uses of UML component and deployment diagrams to date. He is the lead architect for the MAP (Meta-Architectural Processes) framework, which is a framework for mapping the role of the software architect into software development processes. Mark is certified in Intermediate UML with the OMG and a member of WWISA. He also has a Masters in Distributed Systems from DePaul University.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date