Software evolution in componentware using requirements/assurances contracts.
In practice, pure top-down and refinement-based development processes are not sufficient. Usually, an iterative and incremental approach is applied instead. Existing methodologies, however, do not support such evolutionary development processes very well. In this paper, we present the basic concepts of an overall methodology based on component ware and software evolution. The foundation of our methodology is a novel, well-founded model for component-based systems. This model is sufficiently powerful to handle the fundamental structural and behavioral aspects of component ware and object-orientation. Based on the model, we are able to provide a clear definition of a software evolution step.During development, each evolution step implies changes of an appropriate set of development documents. In order to model and track the dependencies between these documents, we introduce the concept of Requirements/Assurances Contracts. These contracts can be rechecked whenever the specification of a component evolves, enabling us to determine the impacts of the respective evolution step. Based on the proposed approach, developers are able to track and manage the software evolution process and to recognize and avoid failures due to software evolution. A short example shows the usefulness of the presented concepts and introduces a practical description technique for Requirements/Assurances Contracts.
INTRODUCTION
Most of today's software engineering methodologies are
This paper originates from the research in the project A1
\Methods for Component-Based Software Engineering" at the
chair of Prof. Dr. Manfred Broy, Institut fur Informatik,
Technische Universitat Munchen. A1 is part of \Bayerischer
Forschungsverbund Software-Engineering" (FORSOFT) and supported
by Siemens AG, Department ZT.
based on a top-down development process, e.g., Object
Modeling Technique (OMT) [27], Objectory Process
[15], or Rational Unied Process (RUP) [14]. All
these methodologies share a common basic idea: During
system development a model of the system is built
and stepwise rened. A renement step adds additional
properties of the desired system to the model. At last
the model is a su-ciently ne, consistent, and correct
representation of the system under consideration. It
may be implemented by programmers or even partly
generated. Surely, all of these processes support local
iterations, for instance the RUP allows iterations during
analysis, design or implementation. However, the
overall process is still based on renement steps to improve
the specication model and nally end with the
desired system. In formal approaches, like ROOM [3] or
Focus [4] the concept of renement is even more strict.
These kinds of process models involve some severe draw-
backs: Initially, the customer often does not know all
relevant requirements, cannot state them adequately,
or even states inconsistent requirements. Consequently,
many delivered systems do not meet the customer's ex-
pectations. In addition, top-down development leads
to systems that are very brittle with respect to changing
requirements, because the system architecture and
the involved components are specically adjusted to the
initial set of requirements. This is in sharp contrast to
the idea of building a system from truly reusable com-
ponents, as the process does not take already existing
components into account. Beyond this, software maintenance
and life-cycle are not supported. This is extreme
critical as, for instance, nowadays maintenance
takes about 80 percent of the IT budget of Europe's
companies in the average, and 20 percent of the user
requirements are obsolete within one year [21].
However, software evolution as a basic concept is currently
not well supported. In our opinion, this is partly
due to the lack of a suitable overall componentware
methodology with respect to software evolution. Such
a methodology should at least incorporate the following
parts [26]:
The common system model provides a well-
dened conceptual framework for componentware
and software evolution is required as a reliable foundation

Based on the system model a set of description
techniques for componentware are needed. Developers
need to model and document the evolution of
a single component or a whole system.
Development should be organized according to
a software evolution process. This includes
guidelines for the usage of the description techniques
as well as reasonable evolution steps.
To minimize the costs of software evolution, systems
should be based on evolution-resistant ar-
chitectures. Such architectures contain a common
basic infrastructure for components, like
DCOM [2], CORBA [22], or Java Enterprise
Beans [16]. But even more important are business-oriented
standard architectures, that are evolution-
resistant.
At last, all former aspects should be supported by
tools.
The contribution of this work can be seen from two different
perspectives. From the viewpoint of specica-
tion methods, it constitutes a sophisticated basic system
model as solid foundation for new techniques in
the areas of software architectures, componentware, and
object-orientation. From a software engineering per-
spective, it provides a clear understanding of software
evolution steps in an evolutionary development process.
Moreover, it oers a new description technique, called
Requirements/Assurances Contracts. These contracts
can be rechecked whenever the specication of an component
evolves. This allows us to determine the impacts
of the respective evolutionary step.
The paper is structured as follows. Section 2 provides
the basic denitions to model dynamics in a component-based
system. In the next section, Section 3, we specify
the observable behavior of an entire component-based
system based on former denitions. In Section 4, we
provide a composition technique that enables us to determine
the behavior of the system from the behavior
of its components. Section 5 will complete the formal
model with a simple concept of types. These types are
described by development documents. Section 6 introduces
our view of development documents and evolution
steps on those documents. In Section 7 we present
the concept of Requirements/Assurances Contracts to
model explicitly the dependencies between development
documents. Section 8 provides a small example to show
the usefulness of the proposed concepts in case of software
evolution. A short conclusion ends the paper.
This section elaborates the basic concepts and notions
of our formal model for component-based systems. The
system model incorporates two levels: The instance-level
represents the individual operational units of a
component-based system that determine its overall be-
havior. We distinguish between component, interface,
connection, and variable instances. We dene a number
of relations and conditions that model properties of
those instances. The type-level contains a normalized
abstract description of a subset of common instances
with similar properties.
Although some models for component-based and object-oriented
systems exist, we need to improve them for an
evolutionary approach. Formal models, like for instance
Focus [4] or temporal logic [17], are strongly connected
with renement concepts (cf. Section 1). Furthermore,
these methods do not contain well elaborated type concepts
or sophisticated description techniques, that are
needed to discuss the issues of software evolution (as in
case of evolution the types and the descriptions are usually
evolved). Moreover, in practice formal methods are
not applicable, since formal models are too abstract and
do not provide a realistic view on today's component-based
systems.
Architectural description languages, like MILs, Rapide,
Aesop, UniCon, are other, less formal approaches. As
summarized in [5] they introduce the concepts of components
and communication between them via connec-
tors, but do not consider all behavior-related aspects
of a component system. In a component-based system
behavior is not limited to the communication between
pairs of components, but also includes changes to the
overall connection structure, the creation and destruction
of instances, and even the introduction of new types
at runtime. In the context of componentware and software
evolution, these aspects are essential because dynamic
changes of a system may happen both during its
construction at design-time as well as during its execution
at runtime, either under control of the system itself
or initiated by human developers.
Other approaches, like pre/post specications cannot
specify mandatory external calls that components must
make. This restriction also applies to Meyer's design
by contract [20] and the Java Modeling Language
(JML) [18], although they are especially targeted at
component-based development.
int =7
String

int i =5

Figure

1: A Component System: Behavioral Aspects
For that reason, we elaborated a novel, more realistic
model. We claim, that the presented formal model is
powerful enough to handle the most di-cult aspects of
component-based systems (cf. Figure 1): dynamically
changing structures, a shared global state, and at last
mandatory call-backs. Thus, we separate the behavior
of component-based systems into these three essential
parts:
Structural behavior captures the changes in the
system structure, including the creation or deletion
of instances and changes in the connection as well
as aggregation structure.
Variable valuations represent the local and
global data space of the system. This enables us
to model a shared global state.
Component communication describes message-based
asynchronous interaction between compo-
nents. Thus, we can specify mandatory call-backs
without problems.
In the following sections we rst come up with de-
nitions for these three separate aspects of behavior in
component-based systems.
Components are the basic building blocks of a
component-based system. Each component possesses
a set of local attributes, a set of sub-components, and a
set of interfaces. Interfaces may be connected to other
interface via connections. During runtime some of these
basic building blocks are created and deleted.
In order to uniquely address the basic elements of a
component-based system, we introduce the disjoint sets:
VARIABLES  ID.
As

Figure

1 shows, a component-based system may
change its structure dynamically. Some of these basic
elements may be created or deleted (ALIVE). New interfaces
may be assigned to components (ASSIGNED).
Interfaces may be connected to or de-connected from
other interfaces (CONNECTED). New Subcomponents
may be aggregated by existing parent-components
(PARENT). The following denitions cover the structural
behavior of component-based systems:
Note, that this approach is strong enough to handle not
only dynamic changing connections structures in systems
but also mobile systems as, for instance it covers
mobile components that migrate from one parent component
to another (PARENT).
Usually, the state space of a component-based system
is not only determined by its current structure but also
by the values of the component's attributes (cf. Figure
1). With VALUES the set of all possible valuations
for attributes and parameters are denoted. They are
in essence mappings of variables (attributes, parame-
ters, etc.) to values of appropriate type (VALUATION).
These variables belong to components, characterizing
the state of the component (ALLOCATION). The
following denitions cover the variable valuations of
component-based systems:
Later on we will allow components to change the values
of other component's variables (cf. Section 4). Thus,
we can model shared global states as well-known from
object-oriented systems. Note, we do not elaborate on
the underlying type system of the variables and values
here, but assume an appropriate one to be given.
COMPONENT COMMUNICATION
Based on existing formal system models, e.g. Focus [4],
sequences of messages represent the fundamental units
of communication. In order to model message-based
communication, we denote the set of all possible messages
with M, and the set of arbitrary nite message
sequences with M  . Within each time interval components
resp. interfaces receive message sequences arriving
at their interfaces resp. connections and send message
sequences to their respective environment, as given by
the following denition (cf. Figure 1):
The used message-based communication is asyn-
chronous, like CORBA one-way calls. Hence, call-backs
based on those asynchronous one-way calls can be explicitly
specied within our model. But one cannot
model \normal" blocking call-backs as usual in object-oriented
programming languages. However, our observation
shows, call-backs need not to be blocking calls.
Often call-backs are used to make systems extensible.
In layered system architectures they occur as calls from
lower into higher layers in which the are known as
up-calls. These up-calls are usually realized by asynchronous
events (cf. the Layers Pattern in [9]). Another
representative application of call-backs as asynchronous
events is the Observer Pattern [11]. There
the observer may be notied via asynchronous events
if the observed object has changed. To sum up, we
believe call-backs as supported in our model are powerful
enough to model real component-based systems under
the assumption that a middleware supporting asynchronous
message exchange is available.
SYSTEM SNAPSHOT
Based on all former denitions we are now able to characterize
a snapshot of a component-based system. Such
a snapshot captures the current structure, variable val-
uation, and actual received messages. Let SNAPSHOT
denote the type of all possible system snapshots:
CONNECTED  PARENT  ALLOCATION
VALUATION  EVALUATION
Let SYSTEM denote the innite set of all possible sys-
tems. A given snapshot snapshot s 2 SNAPSHOT of
a system s 2 SYSTEM 1 is tuple that capture the current
active sets of components, interfaces, connections,
1 In the remainder of this paper we will use this shortcut.
Whenever we want to assign a relation X to a system s 2 SYSTEM
(component c 2 COMPONENT) we say X s
and variables, the current assignment of interfaces to
components, the current connection structure between
interfaces, the current super-/sub-component relation-
ship, the current assignment of variables to components,
the current values of components, and nally the current
messages for the components.
Similar to related approaches [4], we regard time as an
innite chain of time intervals of equal length. We use
N as an abstract time axis, and denote it by T for clar-
ity. Furthermore, we assume a time synchronous model
because of the resulting simplicity and generality. This
means that there is a global time scale that is valid for all
parts of the modeled system. We use timed streams, i.e.
nite or innite sequences of elements from a given do-
main, to represent histories of conceptual entities that
change over time. A timed stream (more precisely, a
stream with discrete time) of elements from the set X is
an element of the type
with Nnf0g. Thus, a timed stream maps each
time interval to an element of X. The notation x t is
used to denote the element of the valuation x 2 X T at
Streams may be used to model the behavior of sys-
tems. Accordingly, SNAPSHOT T is the type of all system
snapshot histories or simply the type of the behavior
relation of all possible systems:
CONNECTED T  PARENT T  ALLOCATION T
VALUATION T  EVALUATION T
Let Snapshot T
s  SNAPSHOT T be the behavior a sys-
tem. A given snapshot history snapshot s 2 Snapshot T
s
is a timed stream of tuples that capture the changing
snapshots snapshot t
s
Obviously, a couple of consistency conditions can be dened
on such a formal behavior specication Snapshot T
s .
For instance, we may require that all assigned interfaces
are assigned to an active component:
assigned t
s
alive t
s
Furthermore, components may only be connected via
their interfaces if one component is the parent of the
other component or if they both have the same parent
component. Connections between interfaces of the same
component are also valid:
connected t
s
assigned t
s
s
parent t
s
s
parent t
s
s
(b)
We can imagine an almost innite set of those consistency
conditions. A full treatment is beyond the
scope of this paper, as the resulting formulae are rather
lengthy. A deeper discussion of this issue can be found
in [1].
In the previous sections we have presented the observable
behavior of a component-based system. This behavior
is a result of the composition of all component
behaviors. To show this coherence we rst have to provide
behavior descriptions of a single component. In
practice are transition-relations an adequate behavior
description technique. In our formal model we use a
novel kind of transition-relation: In contrast to \nor-
predecessor
state and successor state|the presented transition
relation is a relation between a certain part of the
system-wide predecessor state and a certain part of the
wished system-wide successor state:
Let behavior c  BEHAVIOR be the behavior of a component
COMPONENT. The informal meaning of each
tuple in behavior c is: If the specied part of the system-wide
predecessor state ts (given by the rst snapshot),
the component wants the system to be in the system-wide
successor-state in the next step (given by the second
snapshot). Consequently we need some specialized
runtime system that collects at each time step from all
components all wished successor states and composes a
new well-dened successor state for the whole system.
The main goal of such a runtime system is to determine
the system snapshot snapshot t+1
s
from the snapshot
snapshot t
s
and the set of behavior relations behavior c of
all components. In essence, we can provide a formulae
to calculate the system behavior from the initial conguration
snapshot 0
s
, the behavior relations behavior c ,
and external stimulations via messages at free inter-
are interfaces that are not
connected with other interfaces and thus can be stimulated
from the environment.
First we have to calculate all transition-tuples of all active
components:
behavior t
s
alive t
s
true
behavior c
Now, we can calculate all transition-tuples of the active
components that t the actual system state. Let
transition t
s be the set of all those transition-tuples that
could re:
transition t
s
s
s
Before we can come up with the nal formulae for the
calculation of the system snapshot snapshot t+1
s
we need
a new operator on relations. This operator takes a relation
X and replaces all tuples of X with tuples of Y if
the rst element of both tuples is equal
At last, we are now able to provide the complete formulae
to determine the system snapshot snapshot t+1
s
snapshot t+1
s
(alive t+1
s
assigned t+1
s
connected t+1
s
parent t+1
s
allocation t+1
s
alive t+1
s
alive t
s
assigned t+1
s
assigned t
s
connected t+1
s
connected t
s
parent t+1
s
parent t
s
allocation t+1
s
allocation t
s
valuation t+1
s
s
evaluation t+1
s
evaluation t
s
Intuitively spoken, the next system snapshot
(snapshot t+1
s
) is a tuple. Each element of this tuple,
for instance alive t+1
s
, is a function, that is determined
simply by merging the former function (alive t
s
) and the
\delta-function"  8 (transition t
s
This \delta-function"
includes all \wishes" of all transition-relations that re.
The basic concepts and their relations as covered
in the previous sections provide mathematical
denitions for the constituents of a component-based
system at runtime. However, in order to
present an adequate model useful for practical de-
velopment, we introduce the concept of a type.
CONNECTION TYPE [ VARIABLES TYPE  TYPE
be the innite set of all types. A type models all common
properties of a set of instance in an abstract way.
TY PE OF assigns to each instance (component, inter-
face, connection, and variables) its corresponding type:
Let PREDICATE be the innite set of all predicates
that might ever exist. Predicates (boolean expres-
sions) on a type are functions from instances of this
type to BOOLEAN. For instance, for the component
behavior c is a predicate
on the type of c. This is one of the simplest predicate
we can imagine. It provides a direct mapping from
the type-level to the instance-level. The predicate is
true, if the arbitrary transition is part of component
the behavior. Now, we can dene functions that provide
an abstract description for all existing types 3 :
2 The \standard" notation  denotes the set of
m-tuples as a result of the projection of the relation R of arity r
onto the components
3 P(A) denotes the powerset of the set A.
6 SOFTWARE EVOLUTION
Usually, during the development of a system, various development
documents are created. These development
documents are concrete descriptions, in contrast to the
abstract descriptions linked to types as discussed in the
last sections. Such a development document is separate
unit that describes a certain aspect of, or \view" on
the system under development. In componentware we
typically have the following kinds of documents:
Structural Documents describe the internal
structure of a system or component. The structure
of a component consists of its subcomponents
and the connections between the subcomponents
and with the supercomponent, e.g. aggregation or
inheritance in UML Class Diagrams [23] or architecture
description languages [5].
Interface Documents describe the interfaces of
components. Currently most interface descriptions
(e.g. CORBA IDL [24]) only allow one to specify
the syntax of component interfaces. Enhanced descriptions
that also capture behavioral aspects use
pre- and post-conditions, e.g. Eiel [20] or the Java
Modeling Language [18].
Protocol Documents describe the interaction between
a set of components. Typical interactions
are messages exchange, call hierarchies, or dynamic
changes in the connection structure. Examples of
protocol descriptions are: Sequence Diagrams in
UML [23], Extended Event Traces [6], or Interaction
Interfaces [7].
Implementation Documents describe the implementation
of a component. Program code is the
most popular kind of those descriptions, but we can
also use automatons, like in [28, 12] or some kind
of greybox specications [8]. Especially in componentware
the implementation of a component can
be (recursively) described by a set of structural, in-
terface, protocol, and implementation documents.
During development we describe a system|or more exactly
the types of the system|by sets of those docu-
ments. Let DOC be the innite set of all possible doc-
uments. Each type of a component-based system is described
by a set of those development documents:
The semantics of a given set of development documents
is simply a mapping from this set of documents to a
set of predicates. Thus, we can dene a semantic function
which assigns to a given set of documents a set of
properties characterizing the system:
The semantic mapping from the concrete descriptions
of a system (doc s  DOC) into a set of predicates is
correct, if these predicates are equal with the predicates
of the abstract description of each t 2 TYPE. More for-
mally, the semantic mapping is correct if the following
Documents
sem (doc )
sem (doc )s
s

Figure

2: Software Evolution during System Development
condition holds:
sem s (described by s description s (t)
As already discussed in Section 1, the ability for software
to evolve in a controlled manner is one of the most
critical areas of software engineering. Developers need
support for an evolutionary approach. Based on the semantic
function SEM, we are able to formulate the concept
of an evolution step. Figure 2 shows three typical
evolution steps during system development. An evolution
step in our sense causes changes in the set of development
documents within a certain time step as given
by the functions of type EVOLVE:
We call an evolution step of a set of documents doc s
renement, if the condition
sem s (evolve s (doc s
abstraction, if the condition
sem s (doc s )  sem s (evolve s (doc s
strict evolution, if the condition
sem s (doc s ) 6 sem s (evolve s (doc s ))^
sem s (evolve s (doc s
sem s (doc s ) \ sem s (evolve(doc s
total change, if the condition
sem s (doc s ) \ sem s (evolve s (doc s holds.
Obviously, we should pay the most attention to the
strict evolution. In the remaining paper we use evolution
and strict evolution as synonymous, unless if
we explicitly distinguish the various kinds of evolution
steps. A more detailed discussion about the dierences
between evolution and renement steps can be found
in [26].
CONTRACTS
If a document changes via an evolution step, the consequences
for documents that rely on the evolved document
are not clear at all. Normally, the developer
who causes the evolution step has to check whether the
other documents are still correct or not. As the concrete
dependencies between the documents are not explicitly
formulated, the developer has usually to go into
the details of all concerned documents. For that reason
we claim that an evolution-based methodology must be
able to model and track the dependencies between the
various development documents.
To reach this goal we have to make the dependencies between
the development documents more explicit. Cur-
rently, in description techniques or programming languages
dependencies between dierent documents can
only be modeled in an extremely rudimentary fashion.
For instance, in UML [23] designers can only specify the
relation uses between documents or in Java [10] programmers
have to use the import statement to specify
that one document relies on another.
Surely, more sophisticated specication techniques ex-
ist, e.g. Evolving Interoperation Graphs [25], Reuse
Contracts [29, 19], or Interaction Contracts [13]. Evolving
Interoperation Graphs provide a framework for
change propagation if a single class changes. These
graphs take only into account the syntactical interface
of classes and the static structure (class hierarchy) of
the system, but not the behavioral dependencies.
Reuse Contracts address the problem of changing implementations
of a stable abstract specication. There,
evolution con
icts in the scope of inheritance are dis-
cussed, but not con
icts in component collaborations.
This might be helpful to predict the consequences of
evolving a single component, but the eects for other
components or the entire system are not clear at all.
Finally, Interaction Contracts are used to specify the
collaborations between objects. Although the basic idea
of interaction contracts|to specify the behavioral dependencies
between objects|seems to be a quite good
suggestion, this approach takes neither evolution nor
componentware su-ciently into account. Interaction
contracts strongly couple the behavior specication of
the component seen as an island and the behavioral dependencies
to other components. Hence, the impacts of
an evolutionary step can not be determined.
Contract B
Contract A
Contract B
Contract A
A
A
Assurances
Requirements

Figure

3: Requirements/Assurances Contracts between Development Documents of Component Types
To avoid these drawbacks and support an evolution-
based development process at the best, we propose to
decouple the component island specication from the behavioral
dependencies specication. The following two
types of functions allow us to determine the behavioral
specication of a single component seen as an island:
Intuitively, a function requires s 2 REQUIRES calculates
for a given set of documents doc s 2 P(DOC)
the set of predicates the component type ct 2
COMPONENT TYPE expects from its environment.
The function assures s 2 ASSURES calculates the set
of predicates the component type provides to its environment

We need specialized description techniques to model the
required and assured properties of a certain component
explicitly within this development document. Such description
techniques must be strongly structured. They
should have at least two additional parts capturing the
set of required and assured properties (cf. Figure 3):
Requirements: In the requirements part the designer
has to specify the properties the component
needs from its environment.
Assurances: In the assurances part the designer
describes the properties the component assures to
its environment, assuming its own requirements are
fullled.
Once these additional aspects are specied (formally
given by the functions requires s and assures s ), the designer
can explicitly state the behavioral dependencies
between the components by specifying for each component
the assurances that guarantee the requirements.
We call such explicit formulated dependencies Require-
ments/Assurances Contracts (r/a-contracts). Figure 3
illustrates the usage of those contracts. The three development
documents include the additional requirements
(white bubble) and assurances (black bubble) parts. Developers
can explicitly model the dependencies between
the components by r/a-contracts shown as double arrowed
lines. Formally a r/a-contract is a mapping between
the required properties of a component and the
assured properties of other components:
For a given contract contract s 2 CONTRACT the predicate
fulfilled s 2 FULFILLED holds, if all required properties
of a component are assured by properties of other
components:
fulfilled s (ct)(requires s (ct)(described by s (ct))) ()
(ct)(described by s (ct))g
(x)(described by s (x))g
In the case of software evolution the designer or
a tool has to re-check whether requirements of
components, that rely on the assurances of the
evolved component, are still guaranteed. Formally
the tool has to re-check whether the predicate
fulfilled s (ct)(requires s (ct)(evolve s (described by s (ct))))
still holds.
For instance, in Figure 3 component C has changed over
time. The designer has to validate whether Contract B
still holds. More exactly, he or she has to check whether
the requirements of component C are still satised by the
assurances of component A or not.
The advantages of r/a-contracts come only fully to validity
if we have adequate description techniques to
specify the requirements and assurances of components
within development documents. In the next section we
provide a small sample including some simple description
techniques to prove the usefulness of r/a-contracts.
To illustrate the practical relevance of the proposed r/a-
contracts we want to discuss a short example. Consider
a windows help screen as shown in Figure 4. It contains
two components: a text box and a list box control
element. The content of the text box restricts the presented
help topics in the list box. Whenever the user
changes the content of the text box|simply by adding
a single character|the new selection of help topics is
immediately presented in the list box.
Component HelpText
Component HelpList

Figure

4: A Short Sample: Windows Help Screen
A simple implementation of such a help screen may contain
the two components HelpText and HelpList. The
collaboration between these two components usually follows
the Observer Pattern [11]. In the case of an \ob-
servable" component (HelpText) changing parts of its
state, all \observing" components (HelpList) are notied
Components in a system often evolve. To make the windows
help screen more evolution resistant, one should
specify the help screen in a modular fashion. Thus, we
use two dierent kinds of descriptions as proposed in
Section 7:
Descriptions of the behavior of a single component
seen as an island start with COMPONENT and
descriptions of the behavioral dependencies between
components start with
RA-CONTRACT.
In the example description technique we use, keywords
are written with capital letters. Each component island
specication consists of two parts in the specication:
The rst part is the REQUIRES part containing all interfaces
the component needs. For each interface the
required predicates (syntax and behavior) are explicitly
specied. The second part is the ASSURES part capturing
all interfaces the component provides to its environ-
ment. For each interface the assured predicates (again
syntax and behavior) are explicitly described.
The notation and semantic within these parts is equal to
the one used for the interaction contracts [13]. The language
only supports the actions of sending a message M
to a component C, denoted by C !M , and change of a
value v, denoted by v. The ordering of actions can be
explicitly given by the operator \;", an IF-THEN-ELSE
construct, or be left unspecied by the operator k. The
language also provides the construct ho for the
repetition of an expression e separated by the operator
for all variables v which satisfy c.
Now, we can start out with a textual specication of
the requirements and assurances of the two components
HelpText and HelpList|the components island spec-
ication:
COMPONENT HelpText
REQUIRES INTERFACE Observer
WITH METHODS
ASSURES INTERFACE TextBox
WITH LOCALS
WITH METHODS
The component HelpText requires an interface supporting
the method update():void. Note that, in the context
of this specication the required interface is named
Observer. This represents neither a global name nor a
type of the required interface. Later, we can explicitly
model the mapping between the various required and
assured interface and method names via the proposed
r/a-contracts. Additionally, the component HelpText
assures an interface TextBox with the two methods
getText():String and addText(t:String):void.
When addText(t) is called the method update() is invoked
for all observers.
Correspondingly, the component HelpList requires an
interface named Observable that includes the method
getText():String. Moreover, whenever the return
value of getText() changes, the update() method of
the component HelpList has to be called via the interface
ListBox. This is the basic behavior requirement
the component HelpList needs to be assured by its environment

COMPONENT HelpList
REQUIRES INTERFACE Observable
WITH METHODS
WITH INVARIANTS
ASSURES INTERFACE ListBox
WITH LOCALS
WITH METHODS
Now, we can specify two r/a-contracts: One to satisfy
the requirements of the component HelpList and
the other for the requirements of component HelpText.
Such a contract contains two sections: The rst sec-
tion, the INSTANTIATION, declares the participants of
the contract and their initial conguration. For in-
stance, in the contract HelpListContract are two participants
hl:HelpList and ht:HelpText instantiated
and the initial connection between both is established.
Note, the variables declared in the instanciation section
are global identiers, as one must be able to refer them
in the current contract as well as in other contracts.
The second section, the PREDICATE MAPPING, maps the
required interfaces to assured interfaces of the partic-
ipants. Additionally, it contains the most important
part of the contract: the \proof". There, the designer
has to validate the correctness of the contract, means
he or she has to proof whether the syntax and behavior
of the requirements/assurance pair ts together. The
contract HelpListContract includes a proof. It simply
starts with conjunction of all assured predicates of the
interface ht.TextBox and has to end with all required
predicates of the interface hl.Observable:
RA-CONTRACT HelpListContract
INSTANTIATION
HelpList
MAPPING: REQUIRED hl.Observable
ASSURED BY ht.TextBox
RA-CONTRACT HelpTextContract
INSTANTIATION
MAPPING: REQUIRED ht.Observer
ASSURED BY hl.ListBox
proof is omitted
Once the windows help screen is completely specied
and implemented, it usually takes a couple of months
until one of the components appears in a new, improved
version. In our example, the new version of the component
HelpText has been evolved. The new version
assures an additional method addChar(c:Char):void.
For performance reasons, this method does not guarantee
that the observers are notied if the method is
invoked:
COMPONENT HelpText
REQUIRES INTERFACE Observer
WITH METHODS
ASSURES INTERFACE TextBox
WITH LOCALS
WITH METHODS
The assurances part in the specication of the component
HelpText has changed. Therefore, the designer
or a tool should search for all r/a-contracts where
HelpText is used to fulll the requirements of other
components. Once, all of these contracts are identied,
the corresponding proofs have to be re-done. In our
example the contract HelpListContract is concerned.
The designer has to re-check whether the goal ht !
can be reached. But the premises have been changed.
Obviously the goal cannot be derived, as a call of
addChar(c) changes the return value of the method
getT ext() but does not result in an update() for the
HelpList|whenever the text in HelpText changes
update() is called|are no longer satised by the new
component HelpText. The current design of the system
may not longer meet the expectations or the re-
quirements. Now, the designer can decide to keep the
former component in use or to realize a workaround in
the HelpList component. However, this is outside the
scope of the discussed concepts.
9 CONCLUSION AND FUTURE WORK
The ability for software to evolve in a controlled manner
is one of the most critical areas of software engineer-
ing. Therefore, a overall evolution-based development
methodology for componentware is needed. In this paper
we have outlined a well-founded common system
model for componentware that copes with the most difcult
behavioral aspects in object-orientation or com-
ponentware: dynamicall changing structures, a shared
global state, and nally mandatory call-backs. The
model presented includes the concepts of a type and abstract
as well as concrete descriptions for types. During
system development a set of those descriptions are cre-
ated. Software evolution means that these descriptions
are changed over time. Thus, we need techniques to determine
the impacts of the respective evolution steps.
With the presented requirements/assurances-contracts
developers can explicitly model the dependencies between
the dierent components. Whenever a component
or the entire system changes the contracts show
the consequences for other components. Contracts help
the developer to manage the evolution of the complete
system.
A number of additional issues remain items of future
work: We are currently working on a rst prototype
runtime environment for the presented system model.
We still have to elaborate on the underlying type sys-
tem. Addionally, we have to provide more sophisticated
graphical description techniques based on UML and
OCL (structural documents, interface documents, protocol
documents, and implementation documents). A
complete development example will show these description
techniques in practice. For each of those description
techniques a clear semantical mapping into the system
model has to be dened. Additionally, syntax compatible
checkers, theorem prover, and model checker could
be included to run the correctness proof for evolution
steps semi-automatically or even full-automatically. Fi-
nally, we have to develop tool support and provide a set
of evolution-resistant architectures based on technical
componentware infrastructures like CORBA, DCOM, or
Java Enterprise Beans.

ACKNOWLEDGEMENTS

I am grateful to Klaus Bergner, Manfred Broy, Ingolf
Kruger, Jan Philipps, Bernhard Rumpe, Bernhard
Schatz, Marc Sihling, Oskar Slotosch, Katharina Spies,
and Alexander Vilbig for interesting discussions and
comments on earlier versions of this paper.



--R

A formal model for componentware.


The design of distributed systems - an introduction to FOCUS


Interaction Interfaces - Towards a scienti c foundation of a methodological usage of Message Sequence Charts


Java in a Nutshell.
Design Patterns: Elements of Reusable Object-Oriented Soft- ware
On Visual Formalisms.
Specifying Behavioral Compositions in Object-Oriented Sys- tems
The Uni


The temporal logic of actions.
Preliminary design of JML: A behavioral interface speci
Managing software evolution through reuse contracts.

500 Europa: Der Club der Innovatoren.


Client/Server Programming with Java and CORBA.
Modeling Software Evolution by Evolving Inter-operation Graphs
Executive Summary: Software Evolution in Componentware - A Practical Approach

Formale Methodik des Entwurfs verteilter ob- jektorientierter Systeme
Reuse Contracts: Managing the Evolution of Reusable Assets.
--TR
On visual formalisms
Contracts: specifying behavioral compositions in object-oriented systems
Object-oriented software engineering
Object-oriented modeling and design
Real-time object-oriented modeling
The temporal logic of actions
Design patterns
Reuse contracts
Pattern-oriented software architecture
Client/server programming with Java and CORBA
Object-oriented software construction (2nd ed.)
The unified software development process
Software Change and Evolution
Using Extended Event Traces to Describe Communication in Software Architectures
Interaction Interfaces - Towards a Scientific Foundation of a Methodological usage of Message Sequence Charts
A Plea for Grey-Box Components
formal methods;contracts;componentware;software evolution;software architecture;description techniques;object-orientation