EVOLUTIONARY SOFTWARE LIFE CYCLE

FOR SELF-ADAPTING SOFTWARE SYSTEMS

Ahmed Ghoneim, Sven Apel and Gunter Saake

Department of Computer Science,

Otto-von-Guericke-University, Magdeburg, Germany

Keywords:

Reﬂection, Runtime Adaptation, Software Evolution, Meta-Data Techniques, UML.

Abstract:

Reactive non-stoppable software systems perform tasks continually to face environmental changes. These

changes require for adapting strategies of the set of behaviors, or to add new ones according to the ability of the

underlying hardware capabilities. Current approaches to runtime adaptation focus only on information which

is provided by the implementation phase. Design information is not involved, even though it is extremely

useful for adaptation, because they holds the semantics of the regarding software system. We present an

evolutionary life cycle for self-evolving software systems by combining the traditional spiral life cycle model,

known from software development with a reﬂective architecture which processes design information. This

allows the iterative evolution of software systems at runtime. The reﬂective architecture (especially the meta-

level) evolves the behavior and structure of the software system using its design information. Furthermore,

we propose the concept of meta-feedback to react ﬂexibly on the continuous changes of the environment. The

proposed life cycle practicability is illustrated through a case study, a robot control software.

1 INTRODUCTION

A major issue in the software engineering research

area is to develop software systems which can be

adapted and customized to ﬁt the environment and re-

quirements. A special class, reactive non-stoppable

software systems, needs to autonomously adapt itself

to runtime changes of the requirements and runtime

events, occurring in the environment. One prominent

approach to implement self-adaptable software sys-

tems are reﬂective architectures (Maes, 1987; Dowl-

ing and Cahill, 2001; Roman et al., 2001). Reﬂective

architectures provide information about their internal

structure and behavior. This information can be in-

spected and adapted to react to changes of the envi-

ronment or application requirements.

Our approach is based on our previous work on ar-

chitectural reﬂection (Cazzola et al., 2002; Cazzola

et al., 2004). Architectural reﬂection map the knowl-

edge from the design phase, e.g. UML diagrams, to

the running phase of the application, represented as

meta-data. This mapping makes it easier to decide

which runtime events are relevant and how to adapt.

The contribution of this article is the combination of

architectural reﬂection with the spiral life cycle model

for software development (cf. Sec. 2): In short, the

spiral software life cycle evolves a software system

by passing through different development phases (e.g.

analysis, design, implementation, etc.) iteratively

several times. Each phase modiﬁes and evolves the

software system. Our approach transfers this iterative

evolution to runtime. Doing so, we combine the spiral

life cycle model with a reﬂective architecture and an

evolution based on design information (architectural

reﬂection). This makes software evolution possible at

runtime, in order to adapt to changes of the environ-

ment and requirements.

To accomplish that, we divide the software system

into a base-level and a meta-level: The base-level con-

tains the running application and harvests and stores

the design information. The design information is

represented as UML/XMI documents (OMG, 2002).

The meta-level evolves and validates the systems be-

havior. It reacts to runtime changes, indicated by run-

time events, by triggering meta-cycles. Each meta-

cycle evolves and validates the behavior according to

one runtime event. The evolution and validation takes

place in the UML/XMI document using graph trans-

formation (cf. (Cazzola et al., 2004)). If multiple run-

time events occur the meta-cycles are processed se-

211

Ghoneim A., Apel S. and Saake G. (2005).

EVOLUTIONARY SOFTWARE LIFE CYCLE FOR SELF-ADAPTING SOFTWARE SYSTEMS.

In Proceedings of the Seventh International Conference on Enterprise Information Systems, pages 211-216

DOI: 10.5220/0002550202110216

 SciTePress

quentially, one by one. To reduce the gap between

the currently processed meta-data and the base-level

state, the meta-data are updated between two cycles at

a time. The updates, named meta-feedback, are reiﬁed

continuously from the base-level. If no more runtime

events occur, the meta-data are propagated back to the

base-level. Having done so, the behavioral changes

are applied to the base application at runtime.

The remaining paper is organized as follows: Sec-

tion 2 provides a brief overview of the methods and

tools we have adopted in our work; Section 3 de-

scribes the evolutionary life cycle; To exemplify, Sec-

tion 4 applies the proposed life cycle to a robot control

software. Finally, Section 5 concludes.

2 BACKGROUND

2.1 Computational Reﬂection

Computational reﬂection (Maes, 1987) is a technique

for inspecting the current structure and behavior of

a software system. When using reﬂection, the sys-

tem is able to reason about its own behavior and per-

form selected changes at runtime. A reﬂective system

is divided into two levels, a base-level and a meta-

level. The base-level is the part of the system that

performs processing for the application, for instance

controlling transaction executions. The objects at the

base-level provide meta-interfaces that at the meta-

level gives access to the internal representation of the

system. The services provided by the meta-interfaces,

often referred to as the meta-object protocol (MOP),

allow inspection and modiﬁcation of system behavior

and structure (Kiczales et al., 1991).

Reﬂection is a technique that allows a software

system to maintain information about itself (meta-

information) and using this information to change

(adapt) its behavior. This is implemented by a causal

connection between base- (monitored system) and

meta-level (monitoring system).

2.1.1 Architectural Reﬂection

In (Cazzola et al., 2002; Cazzola et al., 2004) we have

proposed an infrastructure that dynamically adapts

software systems using architectural reﬂection. The

key idea of architectural reﬂection is to reuse the

knowledge of the design phase to evolve and vali-

date the structure and behavior of a software system

at runtime. The base-level consists of the running ap-

plication as well as of design information in form of

UML/XMI documents. The meta-level is composed of

an interpreter engine for managing the evolution and

validating consistency processes for runtime changes.

The evolution and validation is based on graph trans-

formation (Cazzola et al., 2004) which takes place

on the reiﬁed design information (UML/XMI docu-

ments).

2.2 Software Engineering Models

Software engineering models deﬁne how to develop

a software system. There are two schools of thought

in software engineering: ﬁrst, linear thinking fostered

by the waterfall life cycle (Royce, 1970). The water-

fall life cycle is divided into sequential phases analy-

sis, design, implementation and testing phase, which

evolve the software system sequentially. Second, iter-

ative or evolutionary thinking, fostered by the spiral

life cycle model (Boehm, 1988; Cotton, 1996; Gilb,

1988). It divides the software engineering space into

four quadrants: management planning, formal risk

analysis, engineering, and customer assessment. The

development cycle is divided into n-cycles. Each cy-

cle consists of waterfall phases. The result of each cy-

cle is a prototype, until the ﬁnal version of the product

is reached. Furthermore, user feedback is considered

at the output of each cycle. Therewith, new additional

features are included into the next cycle.

3 EVOLUTIONARY LIFE CYCLE

FOR DYNAMIC ADAPTATION

The structure of the evolutionary life cycle is based

on the spiral life cycle model. The life cycle is com-

posed of two cycles: the base-cycle and one or more

meta-cycles, as shown in Figure 1. The processes of

the base-cycle execute in sequential ﬂow. At the base-

cycle, the base-engine extracts the design information

in form of UML/XMI documents from the base appli-

cation to constitute the base-data. Adopting the ideas

of the spiral life cycle model, we instantiate multi-

ple meta-cycles, each for one runtime event. These

meta-cycles evolve and validate the behavior (using

the reiﬁed design information) in order to react to the

runtime events. The processes of the meta-cycles exe-

cute in an incremental ﬂow. The meta-processes start

by the reiﬁcation of the base-data to constitute the

meta-data at meta-level. Runtime events trigger the

instantiation of meta-cycles. Each meta-cycle evolves

the meta-data representation of the design informa-

tion using the evolutionary engine. The evolutionary

phase inside a meta-cycle is responsible for building

new meta-data including the runtime changes. Af-

terwards, the validation phase checks the consistency

(consistency checker) of the evolved meta-data ac-

cording to the effects of the runtime events. If a run-

time event occurs during a running meta-cycle, the

event is cached and a new cycle is instantiated after

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

212

...

cycle 2 cycle n

initialize update

design information

collect

data 0 cycle 1 data 1

UML/XMI documentsbase application

design

data n

reflectionreification

evolutionary engine

back propagation

consistency checking

meta− meta− meta− meta− meta− meta−

meta−feedback

meta−object protocol

base−engine

meta−level

base−level

current

information

Figure 1: The Evolutionary Life Cycle

the former cycle has ﬁnished. It starts after the ﬁnish-

ing of the previous one. From the predecessor cycle

each meta-cycle gets the resulting meta-data as input.

To minimize the gap between the evolution phase us-

ing multiple meta-cycles and the base-level we pro-

pose the concept of meta-feedback. As mentioned

this idea is adopted form the spiral life cycle model.

The input meta-data of a new meta-cycle have to be

merged with the current base-data. Finally, if no new

event occurs in a deﬁned time interval the modiﬁed

meta-data are reﬂected back to the base-level. In the

following we discuss both cycle types in more detail:

Base-cycle. The base-cycle includes two linear

phases: The ﬁrst phase contains all base imple-

mentation units as requirements; that includes ob-

jects, attributes, methods, states, and their graphical

representation by using UML. By using the base-

engine the design information will be extracted.

The second phase: includes the UML/XMI docu-

ments. UML/XMI provides a simple translation of

UML diagrams which are more suitable for run-

time manipulation. The internal representation of

the base cycle is illustrated in Algorithm 1.

Data : objects, states, collaborations, UML represen-

tations

Result : UML/XMI schemas

repeat

if object, collaboration or state has changed then

create new UML/XMI document;

provide documents via meta-object protocol;

end

until base application is ﬁnished;

Algorithm 1: Base-cycle ﬂow

Meta-cycle. The meta-cycles can access design in-

formation of the base-level (base-data) using the

meta-object protocol. First, UML/XMI documents

are reiﬁed to constitute the meta-data. In fact they

are transferred from base- to meta-level at runtime.

Afterwards, multiple meta-cycles are instantiated,

each for processing one runtime event. If a runtime

event occurs during a running meta-cycle, the event

is cached. When the meta-cycle has ﬁnished, a new

cycle is instantiated. This new cycle processes the

cached event. Each meta-cycle evolves and val-

idates the meta-data in order to react to runtime

events, while the base-level system runs in paral-

lel. After each meta-cycle the resulting meta-data

are merged with the updated base-data, received

from the base-level. This reduces the gap between

the time used for the meta-cycle to modify reiﬁed

data and the changes for the running base appli-

cation during the meta-cycle processes. After the

last meta-cycle the meta-data are propagated back

to the base-level. The internal representation of the

meta-cycles is illustrated in Algorithm 2.

Evolution and validation as well as the merging and

update operations are based on graph transforma-

tions. These take place on the UML/XMI docu-

ments (cf. (Cazzola et al., 2004)). The following

section describes the UML operators which work on

UML/XMI documents and the overall evolutionary

life cycle.

Data : meta-data, runtime events

Result : new meta-data includes the runtime changes

repeat

if meta-data reiﬁed then

meta-level starts its processes to evolve and

validate consistency for the reiﬁed meta-data;

update meta-data;

for each runtime event do

evolutionary engine evolve the meta-data;

validate the modiﬁed data by using the

consistency checker;

end

until runtime events detected;

reﬂect modiﬁed meta-data back to the base-level;

Algorithm 2: Meta-cycle ﬂow

3.1 Formalized Design Information

This section introduces two operators, which are used

in the evolutionary life cycle to process design in-

formation: (1) the UML update operator which up-

dates one UML/XMI document using up-to-date de-

sign information. This operator is used to merge the

reiﬁed meta-data with the meta-feedback. (2) The

UML intersection operator, which processes the inter-

section between two UML/XMI documents is used to

EVOLUTIONARY SOFTWARE LIFE CYCLE FOR SELF-ADAPTING SOFTWARE SYSTEMS

213

get insight if consistency problems occur. To describe

these operators and clarify the internal processes, we

formalize the speciﬁcation of the design information

(UML/XMI documents):

General deﬁnitions. Starting point is the general de-

ﬁnition of a tree: G = {V, E}. The nodes of the

graph correspond to all possible tags of UML/XMI

documents (OMG, 2002), except the relations (e.g.

inheritance, association, etc.). The edges corre-

spond to the relations between the UML entities

(e.g. classes, objects, etc.). In the following we call

these graphs UML trees. We deﬁne two operations

on UML trees:

UML intersection operator. This operator deter-

mines the intersection of two UML trees. The

result is a tree with the intersection of the node

and edge set. To allow empty intersections the

root node v

is left (the root node of UML/XMI

documents is not an UML entity. It serves only as

root for all UML entities.):

⊖G

= {(V

∩V

)\{v

}, {e | e ∈ E

∩E

∧

e /∈ {v

} × (V

∪ V

)}} (1)

UML update operator. The UML update operator

deﬁnes how two UML trees are merged. Thereby,

the ﬁrst operand is dominant. That means, if in both

node or edge sets equal elements are included, the

element of the ﬁrst operand is chosen to become

part of the resulting set. Therefore this operand is

not commutative:

⊕G

= {{v, w | v ∈ V

, w ∈ V

∧ w /∈ V

{e, h | e ∈ E

, h ∈ E

∧ h /∈ E

}} (2)

The intersection operator is used to ﬁnd conﬂicts

between two versions of design information, e.g.

the currently processed meta-data conﬂict with the

currently occurred changes at the base-level (meta-

feedback). The update operator is used to merge the

meta-data and the meta-feedback.

3.2 Formal Description of the

Evolutionary Life Cycle

The evolutionary life cycle consists of several meta-

cycles (Φ

with i = 0, 1, . . . , n and n ∈ N). Each

meta-cycle gets reiﬁed base-data in form of an UML

tree as argument. It modiﬁes/evolves and validates

these input data according to its corresponding run-

time event. If a meta-cycle is active and a run-

time event occurs, it is interrupted and a successor

cycle is invoked. All meta-cycles except the ﬁrst

(∀Φ

with i > 0) get the modiﬁed data as input from

its predecessor cycle. We deﬁne a meta-cycle Φ

as a

function which transforms the input graph G

to G

′

= Φ

) (3)

The input data of the ﬁrst meta-cycle (Φ

) is the rei-

ﬁed (by the base-engine) UML tree which describes

the current base-level state. For every other meta-

cycle (Φ

, with i 6= 0) the input tree is the result of

i−1

merged with new reiﬁed UML tree U

of the

base-level (meta-feedback) using the UML update op-

erator:

= U

⊕ G

′

i−1

(4)

In the following a sequence of two meta-cycles is de-

picted:

′

= Φ

)

i+1

= U

i+1

⊕ G

′

i+1

= Φ

i+1

)

(5)

A consistency problem occurs if the resulting tree G

′

of meta-cycle Φ

overlaps the tree U

i+1

with updated

base-level state. The problem can be found out using

the UML intersection operator. In the current form

UML update operator replaces all nodes and edges of

′

with equal ones of U

i+1

. Several others are think-

able.

To clarify the functionality of the evolutionary cy-

cle we present the required algorithm for the pre-

sented algebraic operations:

UML intersection operator. The intersection opera-

tor gets two UML trees as input and returns a graph

as output which contains all nodes and edges which

are in both input trees except of the root node v

and the edges which are connected to v

. The algo-

rithm is depicted in Algorithm 3:

Data : ﬁrsttree, secondtree

Result : resulttree

for each node ∈ ﬁrsttree do

if node ∈ secondtree and node 6= v

then

add node to resulttree;

end

for each edge ∈ ﬁrsttree do

if edge ∈ secondtree and edge is not connected to

then

add edge to resulttree;

end

Algorithm 3: Algorithm of the UML intersection opera-

tor

UML update operator. The update operator gets

two UML trees as input and returns a tree whose

nodes and edges belong to the ﬁrst input tree and

the nodes and edges which belong to the second in-

put graph and are not part of the ﬁrst input graph.

The corresponding algorithm is depicted in Algo-

rithm 4:

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

214

Data : ﬁrsttree, secondtree

Result : resulttree

for each node ∈ ﬁrsttree and edge ∈ ﬁrsttree do

add node and edge to resulttree;

end

for each node ∈ secondtree and edge ∈ secondtree do

if node and edge /∈ ﬁrsttree then

add node and edge to resulttree;

end

Algorithm 4: Algorithm of the UML-update operator

Evolutionary life cycle. The evolutionary life cycle

reiﬁes base-data (see Alg. 5). In the main running

phase it instantiates multiple meta-cycles (init).

Runtime events can occur during a running meta-

cycle. In this case the event is cached and after the

ﬁnished cycle an new one is instantiated. The new

cycles get the meta-data merged with the updated

base-data as input (update). If the last meta-cycle

has ﬁnished the meta-data are passed back to the

base-level.

Data : event, reiﬁed inputtree

while event && current metacycle not ﬁnished do

init(metacycle, event);

modiﬁedtree = startmetacycle(metacycle,

inputtree);

if metacycle not ﬁnished then

inputtree = update(reify(), modiﬁedtree);

end

Algorithm 5: Algorithm of the evolutionary life cycle

4 CASE STUDY: ROBOT

CONTROL SOFTWARE

Robot control software is one representative exam-

ple for a reactive non-stoppable software system. Ro-

bots interact strongly with their environment and react

continuously to external changes and events. In this

section we discuss how to apply the proposed evolu-

tionary life cycle to robot systems, e.g. working Sony

Legged Robots (SLR) (Fujita et al., 1999). For ex-

planation, we use a robot soccer scenario: Each robot

team consists of three robots including a goalkeeper.

Robots can move, shoot and have sensors to observe

the ﬁeld, the ball and the other robots.

To clarify the appliance of our approach to this sce-

nario, we discuss the internal phases of the evolution-

ary life for robot control software:

Base-cycle. In Figure 2, we illustrate the representa-

Base Engine

Player

RedTeam RobotRB:

States

instance of

Robot Instance,

Objects, Classes

Midfielder

Midfield

Defender

Midfield

Attacker

<UML:attribute>

<UML:states>

< UML:attribute name="color"/>

</UML:attribute>

<UML:Class name="RedTeam">

UML:state name=midfielder .runtime="tr"/>

<...>

<UML:Class.instance>

</UML:states>

<UML:Class.instance name="RobotRB"/>

<UML:attribute.value value="Red"/>

<UML:states.value value="true" runtime="1 min"/>

</UML:Class.instance>

<...>

</UML:Class>

UML/XMI Document

Figure 2: A robots base-cycle

tion of the UML diagrams for a robot. As one can

see design information consists of class/object dia-

grams and state charts. This design information is

transformed by the base-engine to UML/XMI docu-

ments. The meta-level can access these documents

using the meta-object protocol.

Meta-cycle. When the base-engine has ﬁnished, the

extracted data will be reiﬁed to constitute the meta-

data. In Figure 3, we illustrate the structure of

meta-cycles in detail. The evolutionary controller

waits for runtime events, e.g., the ball or the goal

is near. If a runtime event occurs the meta-cycle

evolves the system behavior, e.g., pass the ball to

another robot. If there is no new runtime event

the modiﬁed meta-data are reﬂected back to the

base-level and therewith the behavior of the ro-

bot changes. But in dynamic environments like

the robot soccer scenario, runtime events occur fre-

quently. Because of this fact, we cache runtime

events which occur during a running meta-cycle.

After the cycle has ﬁnished, a new one is instan-

tiated to react on the new event, e.g. the shooting

line to the goal is blocked. To take the current base

application state into account, e.g. new knowledge

about the robot player distribution over the ﬁeld,

the output meta-data from the ﬁnished cycle are

merged (using the UML update operator) with the

meta-feedback from the base-level. These merged

data are the input of the new cycle. If no more event

occur the meta-data are reﬂected back to the base-

level.

For a better understanding, imagine the following

example: A robot senses an opponent robot near the

ball. What is the best behavior for the robot? The ro-

bot can use the following knowledge in form of meta-

data to make decisions:

• position of the ball, and distance to the ball

• distribution of the robots over the ﬁeld

• distance to the goal and opponents

Based on this knowledge about the environment, a ro-

bot can make several decisions, e.g.:

• move to the ball autonomously

• let another team member move

• block opponents to reach the ball

EVOLUTIONARY SOFTWARE LIFE CYCLE FOR SELF-ADAPTING SOFTWARE SYSTEMS

215

current design data

reified design information

operator

update

<<meta−object>>

evolutionary controller

result of meta−cycle

trigger

meta−cycle

validationevolution

meta−feedback

modified meta−data

new meta−data

UML/XMI Document

meta−data

meta−level

base−level

Figure 3: Evolutionary life cycle and meta-feedback con-

cept

• move to a defender position

Data : OppPos, BallPos, GoalPos, MyPos

if dist(OppPos, BallPos) < dist(MyPos, BallPos) then

move to defender position; switch to defender state;

else

if ﬁreline is blocked then

pass to nearest team member;

switch to attacker state;

else

shoot the ball; switch to kick-off state;

end

Algorithm 6: Rules to adapt the behavior of a robot.

Algorithm 6 shows possible rules to make a deci-

sion, based on the reiﬁed sensor information. If the

opponent is closer to the ball, the robot moves to a

defender position to block the offense. If the robot

itself is closer to the ball, it has two alternatives: If

the ﬁre line to the goal is blocked he passes the ball

to a team member; if there is no opponent robot in

the line to the goal it can shoot directly. It can be

seen that the robot uses reiﬁed sensor information to

make decisions. Moreover, robots use the reiﬁed de-

sign information to switch between states (defender,

attacker, kick-off).

5 CONCLUSION

We have proposed an evolutionary life cycle that is

suitable for self-adapting object-oriented information

systems. The key idea of our approach is to com-

bine the concepts of the spiral life cycle model and

architectural reﬂection, to map the ability of contin-

uous evolution from the development phase to run-

time execution. In this context, we have proposed the

meta-feedback concept to update the meta-data itera-

tively in order to consider the current base-level state.

Furthermore, we have illustrated the formal descrip-

tion of evolutionary life cycle. Finally, we have pre-

sented an application of our evolutionary life cycle on

a working Sony Legged Robot (SLR).

In future work, we will provide a consistency run-

time formal framework for all phases of the proposed

life cycle as well as extensive experiments.

REFERENCES

Boehm, B. (1988). A Spiral Model for Software Develop-

ment and Enhancement. IEEE Computer, 21(5).

Cazzola, W., Ghoneim, A., and Saake, G. (2002). Reﬂective

Analysis and Design for Adapting Object Run-time

Behavior. In Proc. of the 8th Int. Conf. on Object-

Oriented Information Systems (OOIS’02).

Cazzola, W., Ghoneim, A., and Saake, G. (2004). Software

Evolution through Dynamic Adaptation of Its OO De-

sign. In Objects, Agents and Features: Structur-

ing Mechanisms for Contemporary Software, LNCS.

Springer-Verlag.

Cotton, T. (1996). Evolutionary Fusion: A Customer Ori-

ented Incremental Life Cycle for Fusion. In Hewlett-

Packard Journal.

Dowling, J. and Cahill, V. (2001). The K-Component Ar-

chitecture Meta-Model for Self-Adaptive Software. In

Proc. of 3rd Int. Conf. on Metalevel Architectures and

Separation of Crosscutting Concerns (Reﬂection’01).

Fujita, M. et al. (1999). Vision, Strategy, and Localization

Using the Sony Legged Robots at RoboCup-98. AI

Magazine.

Gilb, T. (1988). Principles of Software Engineering Man-

agement. Addison-Wesley.

Kiczales, G., des Rivi

eres, J., and Bobrow, D. G. (1991).

The Art of the Metaobject Protocol. MIT Press.

Maes, P. (1987). Concepts and Experiments in Computa-

tional Reﬂection. In Proc. of the 2nd Conf. on Object-

Oriented Programming Systems, Languages, and Ap-

plications (OOPSLA’87).

OMG (2002). OMG-XML Metadata Interchange (XMI)

Speciﬁcation, v1.2. OMG Modeling and Metadata

Speciﬁcations.

Roman, M., Kon, F., and Campbell, R. (2001). Reﬂective

Middleware: From Your Desk to Your Hand. IEEE

Distributed Systems Online (Special Issue on Reﬂec-

tive Middleware), 2(5).

Royce, W. W. (1970). Managing the Development of Large

Software Systems: Concepts and Techniques. In Proc.

of WESCON.

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

216