Formalizing the Asynchronous Evolution of Architecture Patterns

Workshop on Self-Organizing Software Architectures (SOAR’09)September 14th 2009 – Cambrige (Uk)

Cristóbal Costa-SoriaUniversidad Politécnica de Valencia

Reiko Heckel University of Leicester

Outline

Introduction

Example: PRISMA ADL

Asynchronous Evolution of Types

Conclusions

Motivation

Need for dealing with unanticipated changes

Self-Adaptive Systems– Governed by centralized architecture specifications– Introduce a new architectural specification

Self-Organized Systems – Governed by local decisions based on the interactions

among the different nodes– Modify the criteria for local decisions, introduce

agreements, …

Dynamic evolution need to deal with– A distributed environment which cannot be stopped

and has some autonomous subsystems

Asynchronous Evolution of Types

Example: PRISMA ADL

PRISMA ADL– Symmetrical Aspect-Oriented ADL– Formal language (modal logic of actions and π-calculus)– Supported by a MDD tool which automatically

generates code

System: Primitive to define a composite comp.– Concept for defining hierarchical architectures– Type specification: architecture pattern– Instances: architecture configurations

4

Elements of a System Architecture Pattern– Architectural Elements (AE): components, systems

– Attachments: Connections among AE

– System ports: to communicate with the environment

– Bindings: connect ports to internal AE

Asynchronous Evolution

(Dynamic) Asynchronous Evolution of Types– A type can be evolved several times while its instances

are still evolving to a previous version– Instances can evolve independently of each other

Sys_SSys_S

Ap1

1..1

B1..n

1..1 1..n1..1

Att-1Bin-1

v0 Sys_SSys_S

Ap1

1..1

C1..n

1..1

1..n

1..1

A-C

Bin-1

v1Sys_SSys_S

Ap1

1..1

C1..n

1..1

1..n

1..1

A-C

Bin-1

D1..1

C-D

1..1

v2

S1 : SysS1 : Sys

A1 B1

S2 : SysS2 : Sys

A6 B6

B5

Instance-of

S1 : SysS1 : Sys

A1

C3

timet5t1 t3

S1 : SysS1 : Sys

A1

C3

t8

D4

S2 : SysS2 : Sys

A6

C6

t6

inst

ance

sty

pes

(ver

sion

s)

Asynchronous Evolution

Additional challenges wrt Synchronous Evolution– Type Conformance– Version Management– Order of evolution processes– Coherence of interactions

Sys_SSys_S

Ap1

1..1

B1..n

1..1 1..n1..1

Att-1Bin-1

v0 Sys_SSys_S

Ap1

1..1

C1..n

1..1

1..n

1..1

A-C

Bin-1

v1Sys_SSys_S

Ap1

1..1

C1..n

1..1

1..n

1..1

A-C

Bin-1

D1..1

C-D

1..1

v2

S1 : SysS1 : Sys

A1 B1

S2 : SysS2 : Sys

A6 B6

B5

Instance-of

S1 : SysS1 : Sys

A1

C3

timet5t1 t3

S1 : SysS1 : Sys

A1

C3

t8

D4

S2 : SysS2 : Sys

A6

C6

t6

inst

ance

sty

pes

(ver

sion

s)

Async. Evolution: Evolution Process

New type specification New Evolution Process

Evolution Process: set of evolution operations that changes the previous type specification– Additions, removals or updates

Each set of evolution operations is propagatedto each instance– which applies it independently

t1 t5

AddArchitecturalElement(‘C’,CType,1,-1);AddAttachmentType(‘A-C’, ’A’, ’pA’, 1,1, ’C’, ’pC1’, 1, -1);RemoveAttachmentType(‘A-B’); RemoveArchitecturalElement(‘B’);

AddArchitecturalElement(‘D’,DType,1,1);AddAttachmentType(‘C-D’, ’C’, ’pC2’,1, -1, ’D’, ’pD’, 1, 1);

Sys_SSys_S

Ap1

1..1

B1..n

1..1 1..n1..1

Att-1Bin-1

v0 Sys_SSys_S

Ap1

1..1

C1..n

1..1

1..n

1..1

A-C

Bin-1

v1Sys_SSys_S

Ap1

1..1

C1..n

1..1

1..n

1..1

A-C

Bin-1

D1..1

C-D

1..1

v2

Formalization of the semantics

Typed Graph Transformations to describe the observed behaviour of each evolution operation– Type Graph: PRISMA metamodel (M2) extended with

evolution concepts– Instance Graph: A system type (M1) + its instances (M0)– Graph transformation rules: change the instance graph

(i.e. affect both type-level and instance-level)

Transformation rules– Describe evolution operations (type-level) or

reconfiguration operations (instance-level)– Define preconditions and postconditions– Asynchronously executed– Self-contained– Defined in an architecture-based concrete syntax

Asynchronous Evolution: Type-Level

Evolution operations are directly concerned with changes at the type-level– E.g. AddArchitecturalElement

Each change is stored in the type specification together with the related version – Evolution Tags

9

Sys_SSys_S

Ap1

1..1

B1..n

1..1 1..n1..1

Att-1Bin-1

CD1..n1..1 A-C

C-D

1..11..n+2 +1

+1

-1

+2

-1

t1 t5Sys_SSys_S

A1..1

B1..n

1..1 1..n1..1

Att-1Bin-1

v0

p1

Sys_SSys_S

Ap1

1..1

C1..n

1..1

1..n

1..1

A-C

Bin-1

v1Sys_SSys_S

Ap1

1..1

C1..n

1..1

1..n

1..1

A-C

Bin-1

D1..1

C-D

1..1

v2

Asynchronous Evolution: Type-Level

Evolution Tags – Type conformance: instances can converge gradually

to the next version– Version management: each version can be obtained

from the tagged specification– Order of evolutions: each instance only takes into

account the evolution tags driving to the next version

Example: R1 – AddArchitecturalElement– Integrates a new AE type and adds a new evolution tag

(type-level)

10

Async. Evolution: Instance-Level

Reconfiguration operations are concerned with changes at the instance-level– E.g. CreateArchitecturalElement

A reconfiguration operation can be triggered: – by the system instance itself– as a consequence of a change at the type-level

Changes are constrained by the type level:– Properties defined in the specification (e.g. cardinality)– Valid types and connections

• An instance cannot be created if it has not been defined!

If there are pending evolutions, reconfigurations must converge to the next version– E.g. Cannot create instances of a type that is going to

be removed in the next version

Sys_SSys_S

A1..1

B1..n

1..1 1..n1..1

Att-1Bin-1

p1

Sys_SSys_S

Ap1

1..1

C1..n

1..1

1..n

1..1

A-C

Bin-1

Async. Evolution: Instance-Level

Example: R2 – CreateArchitecturalElement

– The type to instantiate must remain defined until the next version

• If the type has been removed, it has been done in future versions (> S1.version + 1)

Async. Evolution: Instance-Level

An instance completes an evolution operation when it has integrated all the changes of this operation– The Link pending_evol is removed from this instance

An instance finishes an evolution process when all the evolution operations are completed– Then, the instance will start to converge to version+1

Asynchronous Evolution: Coherence of Interactions

We are assuming conservative changes

Non-conservative changes will impact the context of each system instance

Current interactions are not affected– They are finished safely: Quiescence is a precondition

of deletion operations

Future interactions with– Signature mismatches

• Avoided, since connections are removed

– Behavioral mismatches• Need the generation of adaptors

14

Conclusions & Further Work

Introduction to the semantics of Async. Evolution– Allows introducing changes concurrently without

waiting to sequence all the changes– Evolution semantics defined by means of local rules– Version management by means of evolution tags– Instances evolve gradually to the next version and

independently of other instances

Further works– Fully decentralized model.

Decentralized at the instance-level Centralized at the type-level

– Evaluation of the complete set of rules• Simulation in a graph transformation tool (AGG)

15

Questions

Thank you very much for your attention

Workshop on Self-Organizing Software Architectures (SOAR’09)September 14th 2009 – Cambrige (Uk)

Cristóbal Costa-Soria

Information Systems and Software Engineering Research GroupDepartment of Information Systems and ComputationUniversidad Politécnica de ValenciaSpain

Home page: http://issi.dsic.upv.es/~ccosta

Email: ccosta@dsic.upv.es