Upload
candie
View
59
Download
0
Embed Size (px)
DESCRIPTION
Formalizing the Asynchronous Evolution of Architecture Patterns. Cristóbal Costa-Soria Universidad Politécnica de Valencia Reiko Heckel University of Leicester. Workshop on Self-Organizing Software Architectures (SOAR’09 ) September 14 th 2009 – Cambrige (Uk). Outline. Introduction - PowerPoint PPT Presentation
Citation preview
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_S
Ap1
1..1
B1..n
1..1 1..n1..1
Att-1Bin-1
v0 Sys_S
Ap1
1..1
C1..n
1..1
1..n
1..1
A-C
Bin-1
v1Sys_S
Ap1
1..1
C1..n
1..1
1..n
1..1
A-C
Bin-1
D1..1
C-D
1..1
v2
S1 : Sys
A1 B1
S2 : Sys
A6 B6
B5
Instance-of
S1 : Sys
A1
C3
timet5t1 t3
S1 : Sys
A1
C3
t8
D4S2 : 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_S
Ap1
1..1
B1..n
1..1 1..n1..1
Att-1Bin-1
v0 Sys_S
Ap1
1..1
C1..n
1..1
1..n
1..1
A-C
Bin-1
v1Sys_S
Ap1
1..1
C1..n
1..1
1..n
1..1
A-C
Bin-1
D1..1
C-D
1..1
v2
S1 : Sys
A1 B1
S2 : Sys
A6 B6
B5
Instance-of
S1 : Sys
A1
C3
timet5t1 t3
S1 : Sys
A1
C3
t8
D4S2 : 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_S
Ap1
1..1
B1..n
1..1 1..n1..1
Att-1Bin-1
v0 Sys_S
Ap1
1..1
C1..n
1..1
1..n
1..1
A-C
Bin-1
v1Sys_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_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_S
A1..1
B1..n
1..1 1..n1..1
Att-1Bin-1
v0
p1
Sys_S
Ap1
1..1
C1..n
1..1
1..n
1..1
A-C
Bin-1
v1Sys_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_S
A1..1
B1..n
1..1 1..n1..1
Att-1Bin-1
p1
Sys_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: [email protected]