1. Formalizing the Asynchronous Evolution of Architecture Patterns Workshop on Self-Organizing Software Architectures (SOAR’09) September 14 th 2009 – Cambrige (Uk) Cristóbal Costa-Soria Universidad Politécnica de Valencia Reiko Heckel University of Leicester

2. Outline  Introduction  Example: PRISMA ADL  Asynchronous Evolution of Types  Conclusions

3. 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

4. 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

5. 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 A p1 1..1 B 1..n 1..11..n 1..1 Att-1 Bin-1 v0v0 Sys_S A p1 1..1 C 1..n 1..1 1..n 1..1 A-C Bin-1 v1v1 Sys_S A p1 1..1 C 1..n 1..1 1..n 1..1 A-C Bin-1 D 1..1 C-D 1..1 v2v2 S1 : Sys A1B1 S2 : Sys A6 B6 B5 Instance-of S1 : Sys A1 C3 time t5t5 t1t1 t3t3 S1 : Sys A1C3 t8t8 D4 S2 : Sys A6 C6 t6t6 instances types (versions)

6. Asynchronous Evolution  Additional challenges wrt Synchronous Evolution –Type Conformance –Version Management –Order of evolution processes –Coherence of interactions Sys_S A p1 1..1 B 1..n 1..11..n 1..1 Att-1 Bin-1 v0v0 Sys_S A p1 1..1 C 1..n 1..1 1..n 1..1 A-C Bin-1 v1v1 Sys_S A p1 1..1 C 1..n 1..1 1..n 1..1 A-C Bin-1 D 1..1 C-D 1..1 v2v2 S1 : Sys A1B1 S2 : Sys A6 B6 B5 Instance-of S1 : Sys A1 C3 time t5t5 t1t1 t3t3 S1 : Sys A1C3 t8t8 D4 S2 : Sys A6 C6 t6t6 instances types (versions)

7. 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 propagated to each instance –which applies it independently t1t1 t5t5 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 A p1 1..1 B 1..n 1..11..n 1..1 Att-1 Bin-1 v0v0 Sys_S A p1 1..1 C 1..n 1..1 1..n 1..1 A-C Bin-1 v1v1 Sys_S A p1 1..1 C 1..n 1..1 1..n 1..1 A-C Bin-1 D 1..1 C-D 1..1 v2v2

8. 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

9. 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 A p1 1..1 B 1..n 1..11..n 1..1 Att-1 Bin-1 CD 1..n1..1 A-C C-D 1..1 1..n +2+2 +1+1 +1+1 -1 +2+2 -1 t1t1 t5t5 Sys_S A 1..1 B 1..n 1..11..n 1..1 Att-1 Bin-1 v0v0 p1 Sys_S A p1 1..1 C 1..n 1..1 1..n 1..1 A-C Bin-1 v1v1 Sys_S A p1 1..1 C 1..n 1..1 1..n 1..1 A-C Bin-1 D 1..1 C-D 1..1 v2v2

10. 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

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_S A 1..1 B 1..n 1..11..n 1..1 Att-1 Bin-1 p1 Sys_S A p1 1..1 C 1..n 1..1 1..n 1..1 A-C Bin-1

12. 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)

13. 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

14. 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

15. 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

16. Questions Thank you very much for your attention Workshop on Self-Organizing Software Architectures (SOAR’09) September 14 th 2009 – Cambrige (Uk) Cristóbal Costa-Soria Information Systems and Software Engineering Research Group Department of Information Systems and Computation Universidad Politécnica de Valencia Spain Home page: http://issi.dsic.upv.es/~ccostahttp://issi.dsic.upv.es/~ccosta Email: ccosta@dsic.upv.esccosta@dsic.upv.es

17. Towards the Simulation & verification  Graph-based Abstract Syntax –Typed Graph of the PRISMA Metamodel –Example of a Graph Transformation Rule