Baumann UML 2.0 in Action: A project-based tutorial

A detailed and practical book and eBook walk-through showing how to apply UML to real world development projects
1. Auflage 2025
ISBN: 978-1-84719-042-0
Verlag: De Gruyter
Format: PDF
Kopierschutz: Adobe DRM (»Systemvoraussetzungen)

E-Book, Englisch, 248 Seiten

Most books about UML describe it almost in its entirety. Inevitably you're left with only a superficial knowledge of the range of UML elements, without a deep and intuitive understanding of how to apply UML as a whole to real world design problems. This book doesn't set out to cover all of UML, but instead pulls together those parts of UML with immediate practical relevance and presents them as part of a coherent process for using UML in your actual development projects.This book is designed to be read while you work on a real project. After an initial review of the essentials of UML and the design process, it begins with the modeling of a business system and its business processes, in this case an airport. Then the IT system intended to serve that business process is described and analysed. Finally the integration of the system into the production environment is covered in detail. The book can be used in two ways: it can be read through as a thorough grounding in how UML really works in practice; in addition it can be used as stand alone guide to that particular aspect of your own project. Both result in an intuitive understanding of how to actually use UML.

Autoren/Hrsg.

Baumann, Henriette

Fachgebiete

• Mathematik | Informatik EDV | Informatik EDV & Informatik Allgemein

Leseproben

2.2 Models, Views, and Diagrams

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

Note

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.

Figure 2.3 Different views of an object

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, , 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, ; Chapter 4, ; and Chapter 5, .

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

Note

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?

2.2.3 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: , Addison-Wesley, 1999), in magazines, or ask your coworkers.

2.2.4 Process of Analysis

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

Figure 2.4 Process of Analysis

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