shared phenomena that must be enforced by the system to be developed.
In developing a machine, software
engineers must first derive a speci-
fication from the requirements and
so must understand the relevant as-
sumptions to be made about the en-
vironment in which the machine is
expected to work, namely those affect-
ing achievement of desired results;
these assumptions are typically called
domain knowledge; Zave and Jack-
son31 said it this way: “The primary
role of domain knowledge is to bridge
the gap between requirements and
The set of relevant assumptions
captured by domain knowledge en-
ables software engineers to prove
(through the machine) they are able
to achieve the desired requirements.
Now let R and S be (prescriptive) state-
ments describing the requirements
and the specification in some formal
notation, respectively, and let D be
the (descriptive) formal statements
specifying the domain assumptions.
If S and D are satisfied and consistent,
then a software engineer should be
able to prove R also holds
Figure 2 outlines how this formalism applies to a simplified version
of a medical-assistance system from
Calinescu et al. 5 The specification S,
domain assumptions D, and requirements R of the system satisfy Equation 1. The specification S describes
a service-based implementation of
the medical-assistance system, including the ability to analyze patient
data (provided by service s2) or send a
patient-requested alarm (service s1).
If service s2 is invoked, the result of
the analysis determines whether the
system should change the drugs prescribed to the patient (service s3), send
an alarm (service s1), or do nothing.
D describes the domain assumptions
in terms of failure rates and service
costs s1, s2, and s3. The requirements R
for the application include reliability-related requirements, defining, say,
the maximum tolerated probability of
failure for a specific sequence of service invocations.
Domain assumptions play a fundamental role in building systems that
purpose of building
a machine is always
found in the world.
satisfy requirements. Engineers must
know in advance the workings of the
environment in which their software
will be embedded, since the software
is able to achieve the expected goals
under only certain assumptions of the
behavior of the domain described by
D. Should these assumptions be invalidated, the software developed will most
likely fail to satisfy its requirements.
Software evolution deals with
changes affecting the machine, or
specification S, that then cause changes in the implementation. Software
evolution is triggered by a violation
of the correctness criterion in Equation 1 discovered after the software is
released. This violation may occur for
any of three reasons:
˲ The implemented machine does
not satisfy the specification;
˲ The behavior of the environment
diverges from the domain assumptions D made when the specification
was devised; and
˲ The requirements R do not capture the goals software users wish to
achieve in the world.
A response to these changes is traditionally handled by modifying the
software offline during a maintenance
phase. The first reason corresponds
to corrective maintenance. The second corresponds to adaptive maintenance; that is, S must be changed to
satisfy the requirements under the
newly discovered domain properties.
And the third corresponds to perfective maintenance; that is, changes in
R require that S also changes; for example, business goals might evolve
over time or new features might be
requested by software users. Because
maintenance is an offline activity,
software is returned to the development stage where the necessary
changes are analyzed, prioritized, and
scheduled. Changes are then handled
by modifying the application’s specification, design, and implementation.
The evolved system is then verified,
typically through some kind of regression testing, and redeployed.
Offline maintenance does not meet
the needs of emerging application
scenarios in which systems must run
continuously and be capable of adapting autonomously the moment the
need for change is detected. Here, we
are interested in changes in the envi-