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

Aus dem Klappentext

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

John Wiley & Sons

Chapter One

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