Dynamic Software Architectures Verification using DynAlloy

1. Dynamic Software Architectures Verification using DynAlloy Antonio Bucchiarone IMT Graduate School of Lucca, Italy and ISTI-CNR of Pisa, Italy antonio.bucchiarone@imtlucca.it and Juan P. Galeotti Universidad de Buenos Aires, Argentina jgaleotti@dc.uba.ar

2. Agenda • Global Computing Systems (GCSs) • Dynamic Software Architectures for GCSs • Running Example • DSA Formal Modeling • A Typed Graph Grammar Approach • DSA Structural Verification • DynAlloy • Conclusions and Future Work

3. Global Computing Systems • Globality • Autonomous computational entities created or controlled by different owners (i.e., Services) • Heterogeneity • Different devices that provide different configurations and functionalities • Mobility • Movement of the physical platforms or entities that change platforms • User-Dependent • The end-user is always the source of each change (i.e., adaptation) • Fault-Torelance • No interruption of services • Scalability • From small to big systems (i.e., new service request)

4. Dynamic Software Architectures • Network component-based SW systems • adaptive systems • New requirements • Constraints during run-time • Run-time reconfigurations • Add/del/update components, connectors and connections • Programmed, Self-Repairing, Ad-Hoc, etc..

5. Bike Bike Assistance Service Station Assistance Service Station Access Point Chaining Point Chaining Point A Road Assistance Service - I …

6. access access Bike Station Bike Assistance Service Station Access Point Access Point left right left right Chaining Point Chaining Point Chaining Point Chaining Point A Road Assistance Service - II • Cell = Station + accessing bikes • Cell-chains = links of cells by chaining point • Migration of bikes to adjacent cells • Station shut down • Orphan bikes -> repairing reconfiguration

7. Global Computing Systems (GCSs) • Dynamic Software Architectures for GCSs • Running Example • DSA Formal Modeling • A Typed Graph Grammar Approach • DSA Structural Verification • DynAlloy • Conclusions and Future Work

8. Typed Graph Grammar (TGG) Approach

9. Hypergraph = SA Configuration A (hyper)graphis a triple H = (NH , EH , ΦH), where • NHis the set of nodes • EHis the set of (hyper)edges, and • ΦH: EH NH+describes connections of each edge

10. Typed Hypergraph = Configuration • Style: an hypergraph T • Configuration: a pair where: • |G| is the underlying graph, and • is a total hypergraph morphism

11. SPO Rewriting = Reconfiguration • A set of rewriting productions • A production is a partial, injective morphism of T-typed graphs p: L→R • L and R areT-typed hypergraphs that are called left-hand and right-hand side of the production • Given a T-typed graph G and a production p, a rewriting of G using p can be executing a Single-Pushout Approach (SPO)

12. Example of Production • Reconfiguration rule that migrates a bike (b1) to the rightward station (s4)

13. Typed Graph Grammar = DSA • A DSA will be described by a T-typed graph grammar • G = <T, Gin, P> where: • Gin is the initial (T-typed) graph • T defines the style • P is a set of productions • G →*G’ to denote that there exists a possible empty sequence of derivation step from G to G’ using the productions in P

14. Characterisation of Dynamism • Given a grammar G = <T, Gin, P> we define: • The set R(G) of reachable configurations • All configurations to which the initial configuration Gincan evolve • The set Dp(G) of desirable configurations • The set of all T-typed configurations that satisfies a desired property P

15. Programmed dynamism • All architectural changes are identified at design-time and triggered by the system itself • A programmed DSA A is associated with a grammar GA=<T,Gin,P> • The grammar fixes the types of all elements in the architecture, and their possible connections • The productions state the possible way in which a configuration may change • Programmed Dynanism provides an implicit definition of desirable configurations DP(G) = R(G)

16. Global Computing Systems (GCSs) • Dynamic Software Architectures for GCSs • Related Works • DSA Formal Modeling • A Typed Graph Grammar Approach • DSA Structural Verification • SAs and Style with Alloy • Programmed Dynamism with Alloy • DynAlloy Verification of DSAs • Conclusions and Future Work

17. Alloy • Alloy provides a logic to represent properties or constraints on models • First-Order Logic • Alloy Analyzer (SAT Solver) • It explores (a bounded fragment) of the state space of all possible models. • We have implemented TGG concepts in Alloy

18. Hypergraph = SA Configuration A (hyper)graphis a triple H = (NH , EH , ΦH), where • NHis the set of nodes • EHis the set of (hyper)edges, and • ΦH: EH NH+describes connections of each edge // Bindingabstract sig Node{}//Portsabstract sig Label{}//Componentsabstract sig Edge{ conn: Label->lone Node} // Software Architectureabstract sig Graph { he: set Edge, n: set Node, l: set Label}

19. Style // Bike-Style basic elements abstract sig Access_Point, Chain_Point extends Node{} abstract sig Access extends Label{} abstract sig Left extends Label{} abstract sig Right extends Label{} abstract sig Bike extends Edge{} { #conn=1 and conn.univ in Access and univ.conn in Access_Point } abstract sig Bikestation extends Edge{} { #conn=2 and conn.univ in Left+Right and univ.conn in Chain_Point } abstract sig Station extends Edge{} { #conn=3 and conn.univ in Left+Right+Access and univ.conn in Chain_Point+Access_Point } // Style Constraints fact Style_constraints { ... // if two stations are connected, they share one unique node all disj s1,s2: Station | attached[s1,s2]=>#(last[s1.conn]&last[s2.conn]) = 1 // each Chain_Point node have at most two or at least one edge connected all cp: Chain_Point | #(conn.cp)>0 and #(conn.cp)<=2 ... }

20. Programmed Dynamism • Set of reconfiguration rules in Alloy • Left and Right-side HyperGraphs • Single-Pushout Graph Transformation pred isPartialMorphism [g: Graph, h: Graph, f: Fun, t1, t2: Tau] {…} pred isTotalGraphMorphism [g: Graph, h: Graph, f: Fun, t1,t2:Tau] {…} pred isMatch[ga: Graph ,gb: Graph, f: Fun, t1,t2:Tau] {…} pred isProd[p: Production, f: Fun, t1,t2:Tau] pred rwStepPre[G1:Graph, Pr: Production, M1: Fun, P:Fun, t1:Tau, t2:Tau, t3:Tau, t4: Tau ] {…} pred rwStepPost[G1:Graph, G2:Graph, Pr: Production, m1:Fun, m2:Fun, r1:Fun,r2:Fun,t1:Tau, t2:Tau,t3:Tau,t4:Tau] {…}

21. Verification using DynAlloy • Extension of Alloy modeling language (M. Frias & J. Galeotti – ICSE’05) • It allow to define atomic actions and more complex actions (programs) • A given property P is invariant under sequences of applications of some operations • Our case : operation = Rewriting Step

22. Properties • Each Bike can be connected to only one access point using one port of type Access pred Property1 [tgg: TGG]{ all g: tgg.graphs | all e1: g.he |Type[e1,Bike] => one l1: g.l, n1:g.n |(Type[n1,Access_Point] and Type[l1,Access]) and e1.conn = l1->n1 } • If one bike is connected to an access point then must exist a unique station that is connected to the same access point pred Property3[tgg:TGG]{ all g:tgg.graphs| all e1:g.he | Type[e1,Bike]=> one e2:g.he | Type[e2,Station] && connected [e1, e2]}

23. Verification using DynAlloy • Model-finding • Initial Configuration • An instance satisfying the style and having a certain number of bikes, stations and bikestations • Invariant Analysis • If a property P is invariant under sequences of reconfigurations

24. Model Finding module MODEL-FINDING ... open STYLE open TGG … one sig G1 extends Graph{} fact{ G1.he=b1+s1+bs1 G1.n=cp1+cp2+cp3+ap1 G1.l=a1+a2+l1+r1+l2+r2} pred show[]{} run show for 1 Graph, 3 Edge, 4 Node, 6 Label

25. Invariant Analysis • Property3 is Valid because there are no bikes in the target configuration

26. Global Computing Systems (GCSs) • Dynamic Software Architectures for GCSs • Related Works • DSA Formal Modeling • A Typed Graph Grammar Approach • DSA Structural Verification • DynAlloy • Conclusions and Future Work

27. Conclusions • Modeling of DSA using TGGs • Programmed Dynamism • Verification of DSA using Alloy/DynAlloy • Structural Adaptations • Tool Support • Modeling & Verification

28. Future Works • Properties associated to each kind of DSA formalized in GT-VC07 • Self-repairing, Ad-Hoc, etc.. • Verification of behavioral properties • Behavioral Adaptations • Model-checking • ARMADA Framework Development • Automated ReMorphing Ambient for Dynamic Architectures • Eclipse-based (EMF) • Existing tools (AGG, DiaGen, GTXL, etc.) extension • Integration with some Model-Checker

29. Questions!