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: [email protected]
Top Related