Information Technology Reference
In-Depth Information
The Layer-System Concept
We believe each system is a component of one or more larger systems. The larger
systems are the context or environment in which the component system must work. Systems
comprise, thus, a layered set of subsystems below the layer with which we happen to be
dealing and a layered set of supersystems above that layer. This layered structure can be
exploited in representing systems and in defining the system development process. Most
systems are members of multiple-layered sets. The particular set(s) chosen to represent a
system are determined by the viewpoint(s) that are important for the particular system. Also,
every system has a set of essential requirements, which meet the needs of the context or
environment, and a set of physical requirements, which reflect the architectural and design
decisions made to satisfy the essential requirements. To succeed in the development of
complex systems, all system artifacts invoked by these principles must be represented
separately, but their relationships and interactions must also be represented.
The Modeling Concept
A model is an abstraction highlighting some aspects of real-world systems in order to
depict those aspects more clearly. A model has an objective (the question we want it to
answer) and a viewpoint—the point of view of one or more stakeholder(s). Abstract models
reduce the complexity of the real world to digestible chunks that are simpler to understand.
Different types of models answer different types of questions about the system they
represent. If we decide to build more than one model of a given system to investigate different
aspects, then we should somehow organize these models according to their relationships to
one another and to the system. Hence, we often need a framework to accommodate different
models.
The Separation of Concerns Concept
Every system has a specification comprising two important parts: system requirements
and system architecture. Both of these parts contain models. The “system requirements”
model is a technology-independent model of the problem the system is to solve. It represents
the “what.” The “system architecture” model is a technology-dependent model of the
solution to the problem. It represents the “how.” Typically, these two models are created for
the entire system and for every subsystem down to the lowest level in the system hierarchy.
And, it is important to separate the “what” and the “how” for the following reasons: It is often
useful to understand a problem independently of any particular solution. Any given problem
has many possible solutions. Selection of a particular solution is a trade-off process; we often
need to make numerous different trade-offs while keeping the problem statement unchanged.
The separation should support the principle of separation of concerns, which means dealing
with only one part of the system's complexity at a time. The “requirements” model has to cope
with only the essential problems; the “architecture” model has to cope with many constraints
imposed by technology and organization. This separation of the “what” and the “how” gives
us the flexibility to re-implement the “what” using new technology, but it also gives us the
convenience of reusability — not just for software or hardware but for requirements as well.
This is particularly important, because requirements are relatively more stable over longer
periods of time than technology.
