Fundamental Modeling Concepts: Effective Communication of IT Systems - Softcover

Knopfel, Andreas

Softcover

ISBN 10: 047002710X ISBN 13: 9780470027103

Verlag: Wiley, 2002

Inhaltsangabe

A must-have book for systems analysts, architects and managers interested in enhancing successful communication in their organisation.

• Provides detailed examples of how to understand and implement ‘fundamental modeling concepts’ for IT-systems communication
• Provides an already successfully implemented model that has been used at: Siemens, Alcatel, SAP and others
• Benefits from extensive theoretical and practical research
• Provides guidelines on how ‘fundamental modeling concepts’ can be used to support UML, OO, MDA and Architectural Patterns

Über diesen Titel

Über die Autorin bzw. den Autor

Dr. Andreas Knöpfel is an FMC expert and learnt much about its practical value during his four years at SAP. He now works as a system analyst and requirements engineer.

Dr. Bernhard Gröne worked at SAP for 5 years as system analyst and architect. Following that, he completed his PhD at the Hasso-Plattner-Institute at the University of Potsdam. His research topics are analyzing and modeling complex systems and patterns.

Dr. Peter Tabeling has several years of industrial and academic experience in the modeling of complex systems, among them SAP's R/3 system. He is currently Assistant Professor at the Hasso-Plattner-Institute at the University of Potsdam, where he researches and gives lectures on FMC and other topics.

Von der hinteren Coverseite

To develop information processing systems requires effective and efficient communication between many people. In order to understand requirements and design decisions, there is a need for a common conceptual model of the system: one that represents the architecture of the system. Communication between experts from different domains requires a common terminology and notation that is easy to apply.

This is where Fundamental Modeling Concepts (FMC) steps in. Primarily FMC is a consistent and coherent way to think and talk about information processing systems. It enables people to communicate the concepts and structures of complex information systems in an efficient way.

FMC provides you with a powerful tool for the early stages of system analysis and design. It is independent of any application domain or platform technology. It can be applied to business systems, to embedded systems or interactive systems, to systems which are implemented by programming computer systems, to wiring hardware components, to organizing the workflow between humans or to combined solutions.

Starting from a simple example, you will become familiar with the different types of system structures and their graphical representation. The authors’ unique approach presents mappings between conceptual and implementation models and provides you with guidelines for the identification of system structures.

Auszug. © Genehmigter Nachdruck. Alle Rechte vorbehalten.

Fundamental Modeling Concepts

Effective Communication of IT SystemsBy Andreas Knopfel Bernhard Grone Peter Tabeling

John Wiley & Sons

Copyright © 2006 Andreas Knopfel
All right reserved.
ISBN: 978-0-470-02710-3

Chapter One

Introduction

"But the business of software building isn't really high-tech at all. It's most of all a business of talking to each other and writing things down. Those who were making major contributions to the field were more likely to be its best communicators than its best technicians." - Tom DeMarco [DeM95]

1.1 The need for communication

1.1.1 Software and people

Developing software is a hard task. Many approaches have been followed in order to implement more functionality in less code statements and to support coding with powerful tools. Unfortunately, software projects are still hard to handle. One reason is that the 'human factor' becomes more and more important, as:

software is being developed in teams;

many projects require an integration of third-party products or other existing software which have to be understood; and

coding only takes a small fraction of the total time to develop a software product, as collecting requirements, organizing teamwork and discussing concepts becomes more and more important.

In a nutshell: being able to understand, describe, and communicate technical information becomes an increasingly important skill required by architects, developers and project managers.

Figure 1.1 shows a typical project set-up from the communication point of view. The architect communicates with the client, the management and the team of developers. For each of them, he or she has to focus on different aspects and use different levels of technical detail.

This chapter outlines the communication tasks of an architect which will be addressed in this book.

1.1.2 Structure information to prepare communication

"Take a look at the product XY and tell us if we can build on it in our project."

There are so many systems, platforms and technologies that you have to understand before you can write a single line of code. By learning a technology, or analyzing an existing system, you need to build a model of it in your mind.

By jotting down the models, you are able to recall this knowledge later on. Furthermore, you can use them to communicate this information to other people.

There are many modeling techniques and notations which address various purposes. This book will present the Fundamental Modeling Concepts (FMC) which were developed to support communication about technical systems.

The FMC block diagram in Figure 1.2 shows a person who reads system descriptions, such as handbooks, documentation or the source code, observes and uses the system in service, to work out a new set of system models. In this case, the architect or developer uses modeling to structure information about a system, to abstract from too many details, or to obtain an overview.

1.1.3 Retrieve system information from people

"You must have missed this topic in the list of requirements!"

"Ask someone from department X to explain their module, we need to integrate it into our product. Unfortunately, they are very busy at the moment."

It is not unusual that important system knowledge can only be found in the heads of their developers and architects. Even worse, sometimes it is spread over many people but no one has a complete picture.

This scenario is similar to the previous Section 1.1.2, but in this case you need to interview humans to obtain technical information. Many factors can affect efficient communication. Even assuming that all interviewees are willing to share their knowledge, there is still the danger of talking at cross-purposes or of focusing on unimportant details.

You can support interviews with diagrams, as shown in Figure 1.3, because you can show the interviewee what you have understood so far, and establish a common terminology. Furthermore, working with graphics to grasp abstract structures makes communication more effective - there is something to 'point at' while discussing.

Another scenario also deals with obtaining information from people: finding out the customer's requirements. A typical problem of requirements engineering are requirements which come up after the development has already begun. It is simply not realistic for a customer to think of every requirement before he or she has seen or even touched a solution, usually a prototype.

Mental Prototypes can support the process of finding and formulating requirements. A mental protoype is a model of a system which outlines a potential system solution. It describes functionality, but leaves open most of the implementation details. The customers can imagine how the system works, check if their requirements are met and whether they are happy with this solution.

Mental prototyping only works if customers can understand the model easily and can execute the model in their mind.

1.1.4 Communicate system information to people

"I will write this program for the customer, but please don't ask me to explain it to them."

"Don't annoy me with those marketing diagrams. I want more substantial information, but no source code, please!"

"Can you please explain ..."

Sharing knowledge is a crucial task when working in a team. Communication becomes more complex if you have to address more than one or two people, and if they have different knowledge and expectations.

In this scenario, you need to consider didactical issues, as you need to transport your knowledge to other people in an efficient way. As Figure 1.4 shows, diagrams of system models can support this process, assuming that the addressees understand them quickly.

1.1.5 Support communication

"I don't think we're talking about the same subject."

It is not unusual for people to talk at cross-purposes, so use the same words even though they may have a different meaning to them, or do not contain the same level of detail.

If the discussion is about technical issues, you can avoid this situation by using system models to focus the discussion (see Figure 1.5). Use pencil and paper or the whiteboard to point out what you have understood so far and ask if everyone agrees with that. The discussion will usually focus on your diagrams. Invite participants to modify them to show their point of view. Section 8.4.1 introduces some steps to support meetings.

Figure 1.5 shows five people communicating via a common channel at the bottom. They also use system models to support communication (three modify them, two only read them).

1.1.6 Structure teamwork

"I need to know who's working on which topic."

"You too? I thought it was my task to design this interface!"

"My colleague is ill and I have no clue what he's been doing for the last months."

Managing a team of developers requires a great deal of communication. The project manager has to know who is working on which part of the system and has to make sure that the parts will later work together. It is therefore useful if the project manager can map the tasks of each developer to the elements of the system architecture whenever possible.

The architecture of the system to be developed should be known to everyone who is working on it. Developers should know the purpose of the components on which they are working, their future interaction with other components and the names of those who work on them.

A good means of mapping tasks to architectural elements is the System Map. It is a diagram showing a detailed model of the system and its architecture. After being developed by architects, it serves as a basis for discussion about details and should be known by all team members.

1.2 The FMC Idea

1.2.1 Requirements for a modeling technique supporting communication

Using system models to support communication among people sets some requirements for the modeling technique and its notation:

Abstraction. The ability to describe the conceptual architecture on many different levels of abstraction is of major importance.

Simplicity. A description technique should be restricted to a few elementary concepts and notational elements.

Universality. Although being simple, a description technique should also offer enough expressive power to cover a wide range of system types without being bound to a specific paradigm.

Separation of concerns. The description of complex systems has to include different conceptual aspects. It is important for an architectural description technique to support the separation of these aspects by offering comprehensive means for their illustration.

Aesthetics and secondary notation. The notational elements of an architectural description technique should support proper layout including the easy formation of graphical patterns.

1.2.2 FMC

The Fundamental Modeling Concepts (FMC) presented in this book are examples of a modeling technique created especially to support the communication about information processing systems. FMC uses a simple notation which can be used easily for ad-hoc creation of models in meetings. FMC is not tied to a programming paradigm, and can even be used for information processing systems which are implemented with a hardware / software mix. FMC has been created and refined by Siegfried Wendt and his group in many industrial projects. FMC is based on established concepts such as Petri nets and Entity / Relationship modeling, and has been consequently tailored to support communication.

1.2.3 Three aspects - Three diagram types

Three fundamental aspects

FMC separates three fundamental aspects of an information processing system:

Compositional Structure describes the structure of the system in terms of active and passive components. Agents are active and process information, while storages and channels are passive components which keep or transport information. With the help of this structure, we can see which agent can access which storages and communicate with other agents via channels or storages.

Behavior of agents that operate on data, and respond to requests which they receive via channels.

Data / value structure describe the structure of information which can be found in storages or is sent via channels, as well as the relationships between data in different storages.

One diagram type per aspect

For each of the three fundamental aspects, FMC provides one diagram type, as depicted in Figure 1.6 which shows block diagrams for the compositional structure, Petri Nets for the behavior, and Entity / Relationship diagrams (E/R diagrams) for data / value structure. This figure also shows which questions are answered by which diagram type.

Relationship between the diagram types

The compositional structure provided by a block diagram is the cornerstone of an FMC model. Petri nets then describe the behavior of an agent or a set of agents that can be found in the block diagram. Entity/Relationship diagrams are needed if the structure of data and their relationships require amore abstract description. Nevertheless, this data can be located in storages and channels of the block diagram. Figure 1.6 shows the relationship between the three FMC diagram types.

Take a look at Section 6.1 to learn more about the FMC meta model describing the elements of the diagram types and their relationships.

1.3 Outline of this book

Chapters 2 to 5 deal with the introduction of the three FMCdiagram types: Block diagrams for compositional structures, FMC Petri Nets for dynamic structures, and Entity/Relationship diagrams for value structures. These chapters also provide exercises to help you recapitulate what you have learned so far.

Chapter 6 goes into greater detail of FMCmodeling. It introduces the FMCmeta model and advanced modeling concepts, such as structure variance, abstraction and refinement, or non-hierarchical transformations.

As most information processing systems are implemented using software, mapping the system structures of FMC models to implementation is an important aspect which is discussed in Chapter 7.

Chapter 8 focuses on ways of applying FMC in your daily work. The scenarios described there originate from the authors' experience, but the list is not exhaustive. Most of them deal with communication.

The intention of FMC modeling is to support communication. This makes high demands on comprehensibility of diagrams, which depends on various factors that are the subject of Chapter 9.

Chapter 10 discusses FMC's relationship to other modeling approaches such as Structured Analysis (SA) and the Unified Modeling Language (UML).

The pattern language for request processing servers in Chapter 11 is one of the results of the analysis of various server systems and shows how FMC diagrams can be used to describe server concepts in a compact and concise way.

The appendix of this book provides, among other things, reference sheets for the notation of the three FMC diagram types, and a glossary of important FMC terms.

(Continues...)

Excerpted from Fundamental Modeling Conceptsby Andreas Knopfel Bernhard Grone Peter Tabeling Copyright © 2006 by Andreas Knopfel. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Details zur Ausgabe

• Verlag: Wiley
• Erscheinungsdatum: 2002
• Sprache: Englisch
• ISBN 10: 047002710X
• ISBN 13: 9780470027103
• Einband: Tapa blanda
• Anzahl der Seiten: 352
• Kontakt zum Hersteller: Nicht verfügbar
• Verantwortliche Person: Nicht verfügbar