IBM SG24-7368-00 manual Introduction

Managing complexity by managing levels of abstraction and levels of detail

Very often, when dealing with a system of systems, it is difficult to manage the details of system design at different levels of abstraction and detail. Issues at one level of the system get intertwined with issues at another; requirements and design at one level get confused with requirements and design at another.

Think of it this way—if your concern is to travel from Cambridge, England to Rome, Italy, you will be thinking about planes, trains, and automobiles—you probably do not want to be thinking about the wiring in the airplane, or the details of the air control system, or the brake system in the car.

Engineers have a tendency to want to jump down to the details. So when they talk about a system for getting you to your destination, they are as likely to talk about problems with the air control software or the wiring of a piece of hardware as they are to talk about larger-grained issues. This can lead to confusion and errors—diving too deep too early causes integration problems and constrains a solution too early. Requirements are usually best understood in context; jumping levels leads to a loss of context.

In our consulting practice at IBM, we have found it useful to manage the level of abstraction, and to use the appropriate level of detail for the level of abstraction under consideration. Also, we use a formal meta model to provide rigor to our reasoning.7 Briefly, we consider two kinds of levels: model levels and levels of decomposition. Model level refers to what phase of our thinking we are in—analysis models should be less detailed than design models, for example. Decomposition level refers to how deep we are in the structural hierarchy of the system.

This is one of the foundational concepts for MDSD. For example, if we are creating a model for analysis, and we want to reason about distribution issues, we should use entities that do not commit us too early to design decisions.8 If we are reasoning about the enterprise, we use entities that are appropriate for that level of decomposition, and keep our thinking at that level until it is appropriate to go to the next level of decomposition.

7L. Balmelli, J. Densmore, D. L. Brown, M. Cantor, B. Brown, and T. Bohn, Specification for the Rational Unified Process for Systems Engineering—Semantics and Metamodel, Technical Report RC23966, IBM Thomas J. Watson Research Center, Hawthorne, NY 10532, (May 2006)

8Localities in MDSD are a good example of this. See the discussion in chapters 2 and 5.

Chapter 1. Introduction 5