Filter
Top Products
Chapter 1. Introduction 5
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.
7
L. 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)
8
Localities in MDSD are a good example of this. See the discussion in chapters 2 and 5.