Formalizing the Asynchronous Evolution of Architecture Patterns

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

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 distributedenvironment which cannot be stopped and has some autonomous subsystems  Asynchronous Evolution of Types

4. Example: PRISMA ADL • 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 • 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

5. Asynchronous Evolution D C C B A A A A1 A6 A1 A6 A1 B5 B6 B1 C3 C6 C3 D4 types (versions) v2 v1 v0 Sys_S Sys_S Sys_S 1..1 1..1 1..1 1..1 p1 p1 1..1 1..1 1..1 1..n Bin-1 Bin-1 1..1 p1 1..1 1..n Bin-1 Att-1 1..n 1..n 1..1 A-C A-C 1..1 Instance-of C-D 1..n 1..n S1 : Sys instances S1 : Sys S2 : Sys S1 : Sys S2 : Sys t6 t1 t3 t5 t8 time • (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

6. Asynchronous Evolution D C C B A A A A1 A6 A1 A6 A1 B5 B6 B1 C3 C6 C3 D4 types (versions) v2 v1 v0 Sys_S Sys_S Sys_S 1..1 1..1 1..1 1..1 p1 p1 1..1 1..1 1..1 1..n Bin-1 Bin-1 1..1 p1 1..1 1..n Bin-1 Att-1 1..n 1..n 1..1 A-C A-C 1..1 Instance-of C-D 1..n 1..n S1 : Sys instances S1 : Sys S2 : Sys S1 : Sys S2 : Sys t6 t1 t3 t5 t8 time • Additional challenges wrt Synchronous Evolution • Type Conformance • Version Management • Order of evolution processes • Coherence of interactions

7. Async. Evolution: Evolution Process D C B C A A A v2 v1 v0 t1 t5 Sys_S Sys_S Sys_S 1..1 1..1 1..1 1..1 p1 p1 1..1 1..1 1..1 1..n Bin-1 Bin-1 1..1 p1 1..1 1..n Bin-1 Att-1 1..n 1..n 1..1 A-C A-C 1..1 C-D 1..n 1..n 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); • 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

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 D D C C C B B A A A A v2 v1 t1 t5 Sys_S Sys_S v0 Sys_S 1..1 1..1 1..1 1..1 p1 p1 1..1 1..1 1..1 1..n -1 -1 1..1 p1 Sys_S Bin-1 Bin-1 1..1 1..n Bin-1 Att-1 1..1 1..n 1..n 1..n 1..1 +1 A-C A-C p1 1..1 1..1 1..n A-C 1..1 1..1 1..n +2 +2 +1 Bin-1 1..1 Att-1 C-D 1..n 1..n 1..n C-D • 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. Asynchronous Evolution: Type-Level • Evolution Tags • Type conformance: instances can converge graduallyto 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 B C A A Sys_S 1..1 1..1 p1 1..1 Sys_S Bin-1 1..1 1..n 1..n A-C p1 1..1 1..1 1..n Bin-1 Att-1 1..n • 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

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

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)

16. Questions Thank you very much for your attention 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/~ccosta Email: ccosta@dsic.upv.es Workshop on Self-Organizing Software Architectures (SOAR’09) September 14th2009 – Cambrige (Uk)