From “Formal Methods” to System Modeling - Formal Methods and Hybrid Real-Time Systems - page 39

Deployment needs a more complex system model in which it can be expressed
what it means that a software system is executed on a particular piece of hardware.
However, our notion of a composed system and system hierarchy is already a concept
that helps to express such a structure. We only have to characterize certain composed
systems as hardware structures. Then we can express in our model that a number of
subsystems is placed onto one (abstract) hardware unit.

4.4 Observation and Degrees of Abstraction

The critical parts of a system model are the interface abstraction functions. They
determine the degree of abstraction that is provided by the concept of an interface.
The better the abstraction is, the more helpful the method is. It is easy to introduce a
partial ordering on abstractions. This allows us to speak about a greatest element and
a least element in the family of abstractions.
Without any restriction on the abstractions we are allowed to abstract away
everything. But then all state machines are considered to be the same. It is more
appropriate to fix a notion of interface observation, which is then the basis of an
interface abstraction. In a simple case the observation abstraction provides an
interface abstraction that is compositional. But this is not true, in general. In the ideal
case the interface abstraction is identical to the interface observation. But, in general,
the interface abstraction is too abstract to guarantee compositionality. Then additional
information has to be added to achieve compositionality.
Therefore given an observation abstraction we may look for an interface
abstraction that contains all the information of the observation abstraction, but is
compositional. The best (most radical) abstraction with this property is also called
fully abstract .

4.5 Software Development as Modeling Tasks

From the very beginning, when analyzing and understanding a problem domain we
start to work towards finding useful models. This goes on and on when we analyze
use cases and their specifications, the software architecture, the modularization of the
system and its implementation. Software development includes the modeling and
description of various aspects, such as:
•

application domains, their data structures, laws, and processes,

• software requirements, based on data models, functions, and processes,

• software architectures, their structure and principles,

• software components, their roles, interfaces, states, and behaviors,

• programs and modules, their internal structure, their runs and their

implementation,

test cases, their generality and usefulness.
If models are so important in software and systems engineering, a central question
of course is, what is a model in software engineering?
•

•

An annotated graph or diagram?

• A collection of class names, attributes, and method names?