JavaBeat

UML 2.0 in Action

by Leave a Comment

UML 2.0 in Action

A Project-Based Tutorial

The OMG Specification states:

		"The Unified Modeling Language (UML) is a graphical language for
		visualizing, specifying, constructing, and documenting the artifacts of a
		software-intensive system."

Modeling is an essential part of large software projects, which also helps in the development of medium and small projects. UML can be used to model a variety of systems: software systems, business systems, or any other system. With its changes and extensions, UML 2.0 now supports the modeling of business processes much better.

What This Book Covers

This book shows how, with UML, simple models of business processes and specification models can be created and read with little effort. Most books deal with UML almost in its entirety. However, often lack of time, previous knowledge, or motivation to deal with the topic with the necessary intensity prevents us from understanding the material completely and putting it into action. This book is meant for exactly these cases. It presents UML only partially and in a simplified manner. We put together those parts of UML whose application has proven to be practical.

Chapter 1 introduces us to UML and lists the advantages of using UML as a Modeling Language. Chapter 2 introduces us to the case study. The purpose of choosing a case study is to provide a coherent example through the chapters of this book. The chapter also explains several basic terms and concepts like models, views, diagrams, information systems, methods, and notations. The models and views provided by this book help choose the most suitable model for a requirement specification.

Chapter 3 discusses the construction of business system models. It explains the benefits of the different views in a business system and discusses the elements of each view. It also provides instructions about how to construct use case diagrams.

Chapter 4 illustrates how a conceptual model of an IT system can be developed with the help of UML. Chapter 5 describes the integration of the IT system into its environment.

It discusses how to model the messages that are exchanged between the various IT systems, and the processes that are necessary to exchange these messages.

Basic Principles and Background

Much of what will be explained in the next few chapters is based on a few fundamental concepts. These have been summarized in this chapter.

Introduction to the Case Study

For our case study we have chosen an airport—the UML Airport. Anyone who has ever been on a flight will have no problems understanding our example.

We will restrict our example to those areas of the airport that passengers are in contact with during departure, meaning we will take a closer look at passenger check-in and boarding. Figure 2.1 illustrates how passenger services can be distinguished from other areas of the airport. It shows the various stages that passengers go through until they are seated in the airplane, buckled up, and the plane is ready to take off. Not all stages passengers go through are related to passenger services. The stages that belong to passenger services are framed and printed in italic font.

A sequence of steps like this is called a scenario. However, the depicted scenario is only one of many possible scenarios. The following exceptions are possible for passenger check-in and boarding:

  • The passenger only has carry-on luggage.
  • The passenger doesn’t buy anything at the newsstand.
  • The passenger is running late and now has to check in as quickly as possible.
  • The passenger loses his or her boarding pass.
  • The passenger arrived by plane and merely has to change planes, meaning that he or she doesn’t leave the transit area.
  • The passenger checks in, but falls asleep on an uncomfortable chair in the waiting area, and misses the departure of his or her flight, despite being called repeatedly.
  • The passenger doesn’t get through passport inspection because his or her passport has expired.


	Think about which of the above-mentioned scenarios are relevant for passenger
	departure and whether there are more relevant scenarios than those mentioned.

The schematic illustration of the UML Airport in Figure 2.2 should help you to understand the events of the case study better. Many areas around the main passenger services are related in one or more ways to passenger services. Some examples are:

  • Ticket sales
  • Newsstand
  • Duty-free shop
  • Passport inspection/immigration
  • Flight control
  • Information desk
  • Baggage check-in and transportation

Passenger services have to exchange data with some of these areas. They also have to communicate with other areas of the airport. We will introduce those areas when we discuss business models and models of system integration. Therefore, the case study will be expanded further in the following chapters.

UML Airport is a small airport and the case study has been purposely kept simple. Anyone who has ever been on a flight should be able to understand the examples.

The purpose of the case study is to provide a coherent example throughout the chapters of this book. A few details of the case study require further explanation:

  • The plane ticket consists of the actual ticket and up to four additional sections. The ticket is the little booklet that has a separate coupon for every part of the trip. For example, a ticket could contain a coupon for the flight from Zurich to Frankfurt, one for the flight from Frankfurt to London, and one for the return flight from London to Zurich. Each time at check-in the appropriate coupon will be exchanged for a boarding pass. The ticket always stays with the passenger.
  • We distinguish between a flight and a flight number. For instance, a flight number could be LH435 or LX016. It stands for a regular flight that occurs at a certain time from the departure airport to the destination airport. A flight, on the other hand, would be, for example, LH435 on 26th August, 2000. It is, so to speak, an execution of a flight number. A flight could be canceled due to bad weather. A flight number is used as long as the airline offers a certain flight regularly.
  • We differentiate between three options for check-in:
    • Normal check-in with luggage at a normal check-in counter
    • Express check-in without luggage at a special check-in counter
    • Automated check-in without luggage at a machine

Models, Views, and Diagrams

What is a Model?

Models are often built in the context of business and IT systems in order to better understand existing or future systems. However, a model never fully corresponds to reality. Modeling always means emphasizing and omitting: emphasizing essential details and omitting irrelevant ones. But what is essential and what is irrelevant? There is no universal answer to this question. Rather, the answer depends on what the goals of the model are and who is viewing or reading it.

Think about what is emphasized or omitted in the following models:

  • A wind tunnel model of a car
  • A model of a building scaled at 1:50
  • A route plan of the subway
  • A map
  • An organization chart

The more information a model is supposed to give, the more complex and difficult it becomes. A map of Europe, for example, that simultaneously contains political, geological, demographic, and transportation-related information is hardly legible. The solution to this problem is to convey the different types of information on individual maps. Different views are formed of the objects under consideration. These views are interconnected in many ways. Generally, if one view is changed, all other views have to be adjusted as well. If, for instance, in the Netherlands new land is reclaimed from the North Sea, all views—meaning all maps—have to be updated.

The same is true for the model of a building. If a new wing is added to an existing building various views are affected, including the floor plan, the different exterior views, and the 3D-model made from wood. Figure 2.3 illustrates this in a schematic manner. In Section 2.4, The Models of our Case Study, we specifically address the relationships between the models we use in this book. The different views within each model are described in more detail in Chapter 3, Modeling Business Systems; Chapter 4, Modeling IT Systems; and Chapter 5, Modeling for System Integration.

Why do we Need Models?

As a general rule, a model of a system has to perform the following tasks:

  • Communication between all involved parties: In order to build the right system, it is essential that all involved parties think along the same lines. It is particularly important that everyone understands the terminology used, that customers agree upon the same requirements, that developers understand these requirements, and that the decisions made can still be understood months later.
  • Visualization of all facts for customers, experts, and users: All accumulated facts relevant to the system need to be presented in such a way that everyone concerned can understand them. However, according to our real-life experience, we often hit a wall of resistance when we want to communicate with diagrams instead of text. It is necessary to overcome this resistance. Behind it is often a fear of the unknown; and the diagrams might look a bit complicated at first. Therefore, this book contains directions on how to read each diagram.
  • Verification of facts in terms of completeness, consistency, and correctness: A (more or less) formal model makes it possible to verify the facts obtained for completeness, consistency, and correctness. In particular, the clear depiction of interrelationships makes it possible to ask specific questions, and to answer them. We will list these questions with each diagram.

Answer the following questions for yourself:

  • When was the last time you felt that you were at cross-purposes when you discussed a system?
  • When was the last time you felt that you were discussing the same issue over and over again?
  • When was the last time you wished that the consensus you reached during a discussion had been recorded?

Purpose and Target Group of a Model

In real life we often observe that the results of cumbersome, tedious, and expensive modeling simply disappear in a stack of paper on someone’s desk. We might ask why this is so. Two factors greatly influence the result of modeling: for whom do we create the model and for what purpose is it supposed to be used. If we don’t discuss and define these aspects sufficiently, we run the risk of creating models that don’t contain what is important to the user. In other words, if details are not emphasized and omitted appropriately, the model is rendered worthless.

To define the purpose and target group the following questions should be answered:

  • How much business expertise can we expect? Can we assume basic knowledge of the subject, or do we have to explain the fundamentals of the model’s events and processes?
  • What amount of detail does the target group need? What level of complexity does the model permit? If processes and systems are subject to constant changes, a highly detailed model might be unrealistic. This is because, most of the time, it is not possible to maintain those models in a satisfactory manner. A less detailed model requires less effort to develop and update, but it is also less precise.
  • How much time does the target group have to read and interpret the model? Prevent your model from disappearing in a stack of paper on someone’s desk by choosing the appropriate level of detail and complexity; otherwise, nobody might have enough time to read it.
  • What language can be used in the model? Does the target group understand technical business terms? Do they understand IT terminology? Let’s clarify with an easy example: If a bottle filled with water is labeled ‘water’, virtually anyone who can read will understand the bottle’s content. However, if the bottle is labeled ‘H2O’—even though this is correct—we reach a much smaller group of people, for example, the workers of a chemistry lab. Yet, the additional benefit is that it shows the composition of the content: hydrogen and oxygen. In either case, you will have to decide what ‘label’ is most appropriate for your target group.
  • What level of abstraction should you choose? The less abstract a model, the more comprehensible, and clear it is for the user. This is because a less abstract model is closer to the user’s actual use and language. On the other hand, models with a high level of abstraction are more reusable and they are more easily converted into IT systems. We can also prove more accurately that they are correct. IT specialists probably manage highly abstract models best. Users, on the other hand, might pull their hair out if asked to deal with a model like that.

Practical Tips

Compromises have to be made between the level of abstraction, clarity, and the amount of detail used for a model. It is possible to develop several model components, differing in degree of formality and detail, in order to satisfy different target groups. In this way communication between model builders, customers, users, and developers can be facilitated much more easily. It is important not to ‘overdo’ it, but to adjust the model to its target groups and their uses.

Analysis or design patterns are example models that describe common design and modeling methods. You should, whenever possible, look for these example models: on the Internet, in books (for example, Martin Fowler: Analysis Patterns: Reusable Object Models, Addison-Wesley, 1999), in magazines, or ask your coworkers.

Process of Analysis

Figure 2.4 shows the process of analysis, which consists of obtaining, representing, and verifying facts:

This is the job of the analyst. The process of analysis produces a specification that comes from the model and other representations. The analyst works with knowledge carriers, such as customers, users, and domain experts:

  • Facts are obtained by collaboration between analysts and domain experts in which knowledge carriers contribute domain knowledge and analysts contribute methodological knowledge.
  • Facts are represented in diagrams and documents, which are usually prepared by the analyst.
  • Facts are verified only by knowledge carriers, since they alone can decide if the presented facts are correct. Verification is absolutely essential. Without it we might have pretty diagrams, but the probability is high that the facts represented are faulty. In simple terms: development of a model without verification is absolutely worthless!

Practical Tips

It is impossible to develop and verify a usable model without mastering the technical foundations of a topic. Where do we find these knowledge carriers who know something about the systems that we want to model? We have had good experiences with the following groups of people:

  • People who are involved in performing, operating, and controlling business processes
  • Users of similar or related IT systems
  • Customers, who are often critical and creative knowledge carriers
  • Business Partners
  • Domain Experts
  • Management
  • External Observers

Several helpful techniques have proven to be useful for the analysis and understanding of business processes:

  • Observing employees at work
  • Participating in the investigated business processes
  • Taking the role of an outsider (e.g. of a customer)
  • Carrying out surveys
  • Conducting interviews
  • Brainstorming with everyone involved
  • Discussing with domain experts
  • Reviewing existing forms, documentation, specifications, handbooks, and work tools
  • Describing the organizational structure and workflow management (organization charts, etc.)

Diagrams as Views

Each particular UML diagram corresponds to one view of a model of a system. Depending on the type of diagram used, different aspects are either emphasized or omitted. All the different views combined result in a good model of a system. Most of the UML diagrams are graphs (as shown in Figure 2.5), implying that they consist of elements that are connected through lines:

In order to read diagrams, you have to know what types of elements and lines are allowed and what they mean. We will explain this for the diagrams we use throughout the following chapters.

Even computer aided software engineering- (CASE) tools treat UML diagrams as views. They use a database in which the information about the model is stored. Each diagram shows—as a view—a part of that information. In this way, the CASE tool helps to preserve the consistency of each view. If, for example, the name of a class is changed in a class diagram, the statechart diagram of that class is automatically updated:

The model database is what fundamentally differentiates a CASE tool from a graphical program (Figure 2.6). Any UML diagram can be generated easily with paper and pencil or a graphical program. In this case, however, the various diagrams are nothing more than drawings. Only the use of a CASE tool with a database, according to UML specifications, permits consistent collection, management, and modification of model information. UML provides its own database model: the UML meta-model, a component of the UML specifications (“OMG: Unified Modeling Language: Infrastructure, Version 2.0, Final Adopted Specification, September 2003, and OMG: Unified Modeling Language: Superstructure, Version 2.0, Revised Final Adopted Specification, October 2004″: http://www.omg.org). All elements found in UML diagrams, as well as the descriptions of these elements, are contained in the UML meta-model. It states, for example, that a class can have attributes and methods. This “data model” of UML as a language, is the foundation of the model databases of all UML CASE tools. Unfortunately, many CASE tools are hungry for resources, expensive, poorly developed, cumbersome, and require extensive training. Despite this, except for very small projects, their use is worthwhile.