Modelling the Asynchronous Dynamic Evolution of Architectural Types

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– Example of a dynamic change required:

• To introduce a new architectural specification

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

among the different nodes– Example of a dynamic change required:

• Modify the criteria for local decisions, new 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

pe

s (v

ersi

ons)

Instance-of Instance-of

becomes becomes

becomes

(time a type/instance is created/evolved)

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

pe

s (v

ersi

ons)

Instance-of Instance-of

becomes becomes

becomes

(time a type/instance is created/evolved)

Async. Evolution: Evolution Process

New type specification New Evolution Process

Evolution Process: a 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

Graph-based Abstract Description– Typed Graph of the

PRISMA Metamodel

– Example of a Graph Transformation Rule

Towards the Simulation & verification

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

10

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)

11

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

Async. Evolution: Type Updating

Previous interaction patterns must be preserved– A condition to guarantee the coherence of interactions

at the instance-level

New type must be syntactically and semantically compatible with the old type– But only at the level of interactions (ports)– Thus, a new type may provide less functionality but still

maintain compatibility with existing instances.

15

Async. Evolution: Instance Updating

Precondition:– An instance belongs to an updated type and has been

quiesced

Updating: old instance can be transformed or migrated to the new version– Transformation/Migration of previous state– Updating of connections

16

Asynchronous Evolution: Coherence of Interactions

We are assuming semantic compatibility

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

17

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)

18

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