1. Software Architectures for Correct Components Assembly Paola Inverardi Dipartimento di Informatica Universita’ dell’Aquila

2. Several people contributed to the general issue … Alexander Wolf Daniel Yankelevich Sebastian Uchitel Simone Scriboni Massimo Tivoli

3. Presentation Scheme Introduction Motivation Software Architectures and Component-based systems Our Approach  Without a fixed Software Architecture Infrastructure Assumptions Partial Equivalence  The role of fixed Software Architecture Synthesis Conclusions + Future Work

4. We believe that… Model construction should be part of the development process.  Early identification of problems. Analysis by model checking.  Increased confidence on the adequacy and validity of the final product.  Mechanical verification of properties. In particular: Design of concurrent systems.  Integration of components can introduce interaction problems that are hard to detect.  Deadlock, starvation, safety and liveness properties.

5. Motivation In some cases existing model checking techniques can be too expensive to be applied successfully.  State explosion problem.  Techniques developed to accommodate a very broad range of concurrent systems.

6. The role of Software Architecture Very high level system abstraction Component and connectors Architectural Properties Does this help in managing verification problems?

7. A bit of history: CP 1 32 4

8. CP: HTTP to improve the performance of UNIX-based WWW browsers by Garlan, Kindred, and Wing 1995. compresses and uncompresses data across the network by using gzip compression/decompression program together with standard HTTP servers. To assemble the Compressing Proxy from HTTP servers and gzip, use an adaptor to manage interfaces The adaptor acts as a pseudo CERN HTTP filter, communicating with the upstream and downstream filters through a function-call interface, and with gzip using pipes connected to a separate gzip process.

9. CP components behavior the upstream filter offers data along channel 1 (to AD and the downstream filter accept data along channel 4 (from AD). GZ accepts data along channel 2 (from AD). It can then end its input and start offering data along channel 3 (to AD), and then end. AD accepts data along channel 1 (from an upstream filter) and must wait until it has stopped accepting the data before it can offer data on channel 2 (to GZ).It can then end its output.

10. Verification: 2 deadlocks the adaptor and gzip reach a state in which one is willing to output on channel 2 while the other is willing to output on channel 3. Both components are trying to output. Both the adaptor and gzip are trying to input, one on channel 3 and the other on channel 2.

11. How do we verify CP SA? We build the complete model of the 4 components (automata) Model check to find deadlocks Could have we been smarter? Fine but …

12. Component-based systems Component-based systems (CBS).  Growing acceptance in industry.  Characteristics of concurrent systems. Can new (and more efficient) model checking techniques be developed in the context of CBS?

13. Component-based software development Focuses on building large software systems by integrating previously-existing software components [SEI-CMU]. Embodies the "buy, don't build" philosophy [Brooks 87]. Boosted by…  Increase in the quality and variety of Commercial Off- The-Shelf (COTS) components.  Component integration technologies. E.g. COM & CORBA  Lower development and maintenance budgets. Introduces a new approach to system design

14. Designing component-based systems Components are…  autonomous, decoupled, concurrent and possibly distributed entities.  with well defined interfaces for communication and synchronisation. Integration context provides…  abstraction framework for integrating components. E.g. network, operating system, data representation…  standard services: naming, yellow pages,…  capabilities for accessing component services. Only simple interactions are supported. For example: In CORBA only 3: Synchronous, Deferred Synchronous and One Way

15. Checking Deadlock Freedom in CBS Can we take advantage of…  Simple interaction mechanisms.  Flat architecture. … in CBS to check for deadlock freedom? YES How? Our approach is based on…  Extra information at component level: Assumptions.  Tightly coupled with: property and architecture.  Local checks. E.i. component to component. Results:  Efficient but incomplete deadlock detection.

16. Modelling Component behaviour modelled using finite state machines. Integration through parallel composition of component models. In the context of CCS  Components: sequence and choice operators. E.g. Server = call.service.return.Server.  Integration: parallel composition and restriction operators. E.g. (C 1 | C 2 |... | C n ) / L Deadlock: (C 1 | C 2 |... | C n ) / L can reach a state where no actions are possible.

17. Assumptions Component requirement on its environment in order to guarantee a property in a specific integration context. In a sense we are enhancing component semantics. In our case we use: “My context never blocks me” or in other words “If I can perform action a, my context must be able to perform action a”. Assumptions modeled in the same way as components.

18. Back to CP 1 32 4

19. Filters

20. GZIP

21. Adaptor

22. Relation between component assumptions and behaviours. Compare assumptions with context. Based on observational equivalence… A  B: If A can do action a then B can also do a and continue to be observationally equivalent to A. and allows partial matching… Partial Equivalence

23. When does not arise deadlock? If no one of the components indefinitely blocks, the system does not deadlock Each component always work when the environment always provides what it needs All the components assumptions are satisfied by somebody else actual behavior

24. Partial Equivalence Requires behaviours to be equivalent up to a set of stopping nodes. A  B: If A can do action a then B can also do a and always continues to be observationally equivalent to A up to a certain set of stopping states.

25. Deadlock Freedom Checking Algorithm 1. Generate assumptions for each component. 2. Get assumption not completely matched. 3. Find a component behaviour that is partially equivalent to the assumption. 4. If not found return false. 5. Tag matched portion of assumption. 6. Change initial states in assumption and component behaviour. 7. If there are assumptions not completely matched go to 2. 8. Return true.

26. Partial match

29. Successful Matching Stopping nodes

30. Successful Matching (II)

31. New Adaptor

32. New match 1

33. New match 2

34. New match 3

35. New match 4

36. Deadlock Freedom Checking Algorithm Complexity (For N graphs of K states):  Space : O(K.N) vs. O(K N )  Time : O(N 3.K 4.log(K)) vs O(K N ) Incomplete: Some Deadlock Free Systems are not detected. Because of...  Use of partial equivalence.  Use of local approach to a global property. We have a prototype implementation.  Hope to get feedback on where incompleteness appears…  and how to make the approach more complete.

37. What can we conclude? Deadlock freedom checking algorithm that…  has very good space complexity and comparable time complexity.  is incomplete. The concept of assumptions as an extension to component semantics. Framework that might be extendable to other properties and integration contexts.

38. So far so good but … We have modelled AC and AS component behaviors We do not have hypothesis on the SA, i.e. on the interaction infrastructure We are able to efficiently capture some behavioral problems Can we do better?

39. Let us re-consider the problem software projects are based on the integration of COTS components. Integration frameworks are fixed: CORBA, COM/DCOM, etc. Component based technologies provide composition mechanisms

40. What is the problem? The ability to establish properties on the assembly code by only assuming a relative knowledge of the single components properties. A software architecture represents the reference skeleton used to compose components and let them interact:  interactions among components are represented by the notion of software connector.

41. What would we like to do: extend the analysis of component-based systems to general safety and liveness properties; provide recovery strategies besides property analysis;  (e.g.: avoid deadlock, starvation and guarantee safety and liveness) make the whole approach as automatic as possible; validate the approach on several concrete component- based architectural models.

42. Problem description Given a set of components C and a set of properties P automatically derive an assembly A of these components which satisfies every property in P. Basic ingredients:  the type of components we refer to (COTS, black-box);  the type of properties we want to check (functional, interaction behaviors);  the type of systems we want to build (component-based).

43. Basic idea A simple software architecture structure which exploits the separation between functional behavior and Integration/Communication behavior. Extra information at component level: component actual behavior and assumptions. Our approach:  detect software anomalies;  remove software anomalies;  guarantee a given coordination policy.

44. Components information …Again Component actual behavior Component assumptions on its environment in order to guarantee a property in a specific integration context. In the case of deadlock case we use: “My context never blocks me” or in other words “If I can perform action a, my context must be able to perform action a”. How do we produce this additional information?

45. Modeling the system Partial behavioural specification of the composed system:  bMSCs (basic Message Sequence Charts) a bMSC describes a single scenario as a set of finite interactions between a set of components;  HMSCs (High-level Message Sequence Charts) a HMSC provides the means for composing bMSCs as a directed graph where nodes represent bMSCs and edges indicate their possible continuations. Specification of the behavioural properties to be enforced:  LTL (Linear-time Temporal Logic) is a formalism for describing sequences of transitions between states in reactive system; operators are provided for describing events along a single computation path.

46. Modeling … continuing Component behaviour modelled using finite state machines:  finite-state CCS (Calculus of Communicating Systems);  LTS (Labelled Transitions System). Integration through parallel composition of component models. In the context of CCS  Components: prefix and choice operators. E.g. ServerA = (call_service1.return1 + call_service2.return2).ServerA  Integration: parallel composition and restriction operators. E.g. (C 1 | C 2 |... | C n ) / L Deadlock: (C 1 | C 2 |... | C n ) / L can reach a state where no actions are possible.

47. Connector Free Architecture Component 1 Component 2 channel Component 3 channel A Connector Free Architecture (CFA) is a set of components directly connected in a synchronous way. In CCS : (C 1 | C 2 |... | C n ) \ U i=1..n Act i

48. Connector Based Architecture differences from C2 style:  synchronous message passing;  connectors cannot directly communicate;  connectors are only routing devices, without any filtering policies;  connectors have a strictly sequential input-output behavior. REQUEST NOTIFICATION Connector top bottom Component 1 top bottom channel 1 Component 2 top bottom channel 2 Component 3 top bottom channel 3 In CCS: (C 1 [f 1 ] | C 2 [f 2 ] |... | C n [f n ] | K) \U i=1..n Act i [f i ] K is the synthesized connector, f i are suitable relabelling functions such that f i (  )=  i, for all  Act i

49. Approach description: 3-step method Component 1 Component 3 Component 2 Connector Free Architecture Connector Based Architecture Component 1 Component 3 Component 2 Connector local views of each component deadlock-freeness Component 1 Deadlock-free Connector Based Architecture Component 3 Component 2 Deadlock-free Connector Behavioral property Component 1 Failures-free Connector Based Architecture Component 3 Component 2 Failure-free Connector Connector code (assembly code)

50. Example A client/server (single-layer) system:  2 clients (C1, C2);  1 server (C3). sLbl1=S 1 sLbl2=S 2 sLbl3=S 3 sLbl1=S’ 1 sLbl2=S 2 sLbl3=S’ 3 sLbl1=S 1 sLbl2=S 2 sLbl3=S 3 sLbl1=S 1 sLbl2=S 2 sLbl3=S 3 sLbl1=S 1 sLbl2=S’ 2 sLbl3=S’’ 3 sLbl1=S 1 sLbl2=S’’ 2 sLbl3=S’’’ 3 sLbl1=S 1 sLbl2=S 2 sLbl3=S 3

51. Local Views: AC-AS- graphs C1C2 C3 CFA-system How to model all the local views from the component perspective?

52. Example: AC-AS- graphs Knowing the composition mechanism AS: assumptions on the environment AC: the inner knowledge

53. If we know the SA …EX- graphs C1C2 C3 K 1 2 3 CBA-system Knowing the characteristics of the connector, i.e. the environment EX: assumptions on the connector

54. Example: EX-Graphs unification (first step) is based on a usual first-order unification algorithm

55. Deadlock recovery (second step) It is enough to prune all the finite branches of the connector transition graph. A further check:  the portion of the connector graph related with the communication with C i has to CB-simulate the AS- Graph AS i.  CB-simulation is a notion of “state-based” equivalence. We cannot solve behavioral failures that are not identifiable with precise behaviors of the synthesized connector (black-box setting).

56. Example: deadlock recovery (second step)        a b <= CB

57. Deadlock Freeness: an example Dining Philosophers Problem: Connector Free Architectural View component Philosopher1 requests and gets the resource of component Fork1; component Philosopher2 requests and gets the resource of component Fork2; component Philosopher1 requests and waits for the resource of component Fork2; component Philosopher2 requests and waits for the resource of component Fork1; Deadlock Scenario: Assigning a deadlock-free routing policy to the connector it is possible to avoid the deadlock scenario. Table Connector Based Architectural View Connector Table

58. Beyond Deadlock A designer can now think not only of a deadlock- free routing policy but of a precise scheduling one. For instance he might want:  the philosophers to eat in turn or that  the Philosopher1 always eats twice before Philosopher2. The approaches we are experimenting are based on two existent line of research in the program verification area:  usual model checking approach;  supervisory control theory.

59. Beyond Deadlock: Model Checking Approach We must adapt the usual model checking approach to our approach; We need:  some kind of temporal logic to define properties that represent unexpected behavior of the system;  an existent translation algorithm of a behavioral property to a graph with the same structure of the connector graph (Büchi Automata Theory);  an existent structural mismatches search strategy to find structural mismatches between portions of the connector graph and a property graph

60. Property enforcing (third step) By exploiting the automata-based model checking approach. Property specification:  LTL as specification language;  AP={ t : t is a tuple of states in the AC-Graphs where each state in t is not reachable only through  transitions};  B P is the Büchi Automaton (automaton over infinite words) corresponding to P. Connector Model:  KS K is the Kripke structure corresponding to K;  B KS K is the Büchi Automaton corresponding to KS K ;

61. Enforcing procedure based on the construction of the product language:  1. build the automaton B K,P intersection that accepts L(B KS K )  L(B P );  2. if B K,P intersection is not empty then derive K P as the “fair” connector graph corresponding to B K,P intersection ; return K P as the P-satisfiyng connector graph. Property enforcing (third step)

62. Synthesizing dynamic information off black-box components assume a (partial) standard specification for the components interaction behavior (e.g.: MSC and HMSC): we can adapt a translation algorithm from an HMSC to a finite state machine to our approach; Use black-box component inspection techniques (e.g: Interface Propagation Analysis – J. Voas)  inspection techniques are not completely automatic;  An inspection technique should benefit of the knowledge of the type of components and architectural interaction model.  we can try to increase the automation of these techniques and extend them in order to derive a behavioral specification that reflects the constraints of the architectural model; We can only synthesize observable behaviors

63. Our approach: an example from the bMSCs and HMSCs specification to the AC-Graphs for each component (from Sebastian Uchitel, Jeff Kramer and Jeff Magee) : a b c a d AC 3 C1 C2C3 a b bMSC 1 C1 C2C3 c a bMSC 2 d bMSC 1 bMSC 2 a a b b bMSC 1 bMSC 2 HMSC c c a a d d

64. Our approach: an example from the AC-Graphs to the AS-Graphs for each component: a b c a d AC 3 a b c d AS 3 a

65. Our approach: an example from the AS-Graphs to the EX-Graphs for each component: a b c d AS 3 a EX 3 a?a? a3a3 b3b3 b?b? c?c? c3c3 a?a? a3a3 d3d3 d?d?

66. Our approach: an example EX-Graphs unification (coordinator graph) and concurrency conflicts avoidance (deadlock-free coordinator graph): EX 3 a?a? a3a3 b3b3 b?b? c?c? c3c3 a?a? a3a3 d3d3 d?d? a1a1 a?a? b?b? b1b1 EX 1 c2c2 c?c? a2a2 a?a? d?d? d2d2 EX 2 a1a1 a?a? c2c2 c?c? K a1a1 a3a3 c2c2 c3c3 b3b3 b1b1 a2a2 a3a3 d3d3 d2d2 a1a1 a3a3 deadlock K a1a1 a3a3 c2c2 c3c3 b3b3 b1b1 a2a2 a3a3 d3d3 d2d2

67. Our approach: an example Coordination policy enforcing (failure-free coordinator graph): K a1a1 a3a3 c2c2 c3c3 b3b3 b1b1 a2a2 a3a3 d3d3 d2d2 KS K {a 1 } {a 3 } {c 2 } {c 3 } {b 3 } {b 1,d 2 } {a 2 } {a 3 } {d 3 } P=F((a 1 X(!a 1 U a 2 )) (a 2 X(!a 2 U a 1 ))) B KS a1a1 a3a3 c2c2 c3c3 b3b3 b1b1 a2a2 a3a3 d3d3 d2d2 K b1b1 d2d2 k1k1 k2k2 k3k3 k6k6 k4k4 k5k5 k9k9 k 10 k 11 BPBP CBA a1a1 a2a2 a2a2 a1a1 !a 1 !a 2 true p0p0 p1p1 p2p2 p3p3 ∩ P CBA =F((a 1 X(!a 1 U a 2 )) (a 2 X(!a 2 U a 1 )))

68. Our approach: an example Coordination policy enforcing (failure-free coordinator graph): B KS a1a1 a3a3 c2c2 c3c3 b3b3 b1b1 a2a2 a3a3 d3d3 d2d2 K b1b1 d2d2 k1k1 k2k2 k3k3 k6k6 k4k4 k5k5 k9k9 k 10 k 11 BPBP CBA a1a1 a2a2 a2a2 a1a1 !a 1 !a 2 true p0p0 p1p1 p2p2 p3p3 ∩ (k 1,p 0 ) a1a1 a3a3 b3b3 b1b1 a2a2 c2c2 c3c3 a2a2 c2c2 c3c3 a3a3 d3d3 d2d2 a1a1 (k 2,p 1 ) (k 3,p 1 ) (k 6,p 1 ) (k 1,p 1 ) (k 4,p 1 ) (k 5,p 1 ) (k 9,p 3 ) (k 4,p 0 )(k 5,p 0 )(k 9,p 2 )(k 10,p 2 ) (k 11,p 2 ) (k 1,p 2 ) (k 2,p 3 ) c2c2 c3c3 (k 4,p 2 ) (k 5,p 2 )

69. Our approach: an example Assembly code derivation (coordinator code derivation): (k 1,p 0 ) a1a1 a3a3 b3b3 b1b1 c2c2 c3c3 c2c2 c3c3 a3a3 d3d3 d2d2 (k 2,p 1 ) (k 3,p 1 ) (k 6,p 1 ) (k 1,p 1 ) (k 4,p 1 ) a2a2 (k 5,p 1 ) (k 9,p 3 ) (k 4,p 0 ) a2a2 (k 5,p 0 )(k 9,p 2 )(k 10,p 2 ) (k 11,p 2 ) a1a1 (k 1,p 2 ) (k 2,p 3 )

71. A more complex example Starting point:  group-ware systems development by assembling third-party components; Our proposed approach to this problem:  automatic synthesis of failure-free software connectors (i.e. failure-free coordinators). An application example of our approach to group-ware systems:  a Collaborative Writing (CW) system development by assembling third-party components.

72. State of the art The coordination of concurrent activities is a very important and difficult task in the area of Computer Supported Cooperative Work (CSCW). Many approaches there exist in literature:  a common idea: separation of computation from coordination for multi- threaded application;  they work in a white-box components setting and they are flexible in terms of supported controlled coordination policies. But what happens when we deal with group-ware applications built by assembling third-party (i.e. COTS) components?  the issue is not only in specifying and analyzing a coordination policy rather in being able to enforce it out of a set of already implemented (local) behaviors;  the challenge: how to predict possible coordination policies of the components interaction behavior by only exploiting a limited knowledge of the single components computational behavior?

73. Application: a semi-synchronous CW system The following assumption is needed in order to obtain consistency maintenance: when a user wants to work in asynchronous mode, the DSS expects that all other users work in asynchronous mode too.

74. Application: behavioral specification of the CW system Possible scenarios of the composed system (basic Message Sequence Charts):  OPEN: ‘open work session’ scenario;  OPENF:‘failed work session opening’ scenario;  CLOSE:‘close work session’ scenario;  READ:‘document’s content displaying’ scenario;  SYNCWR:‘document’s content synchronous updating’ scenario;  REPL:‘document’s content replication for asynchronous updating’ scenario;  ASYNCWR:‘document’s content asynchronous updating’ scenario;

75. Application: behavioral specification of the CW system

77. Application: coordination policy specification Coordination policy: “every client who requires to commit an update on the shared document will eventually always be able to perform this update”. LTL formula corresponding to the policy:  P1 = G(F(write1 )) G(F(write2 )) Büchi Automaton corresponding to P1: ^

78. Application: automatic synthesis of the coordinator’s code From the bMSCs and HMSCs specification we derive the models of the components interaction behavior (AC-Graphs):

79. Application: automatic synthesis of the coordinator’s code IUI I DSS

80. Application: automatic synthesis of the coordinator’s code By assuming the rules of the CBA style, from the AC-Graphs we derive the models of the connector expected behavior for each component (EX-Graphs):

81. Application: automatic synthesis of the coordinator’s code

82. By unifying each EX-Graph we can derive the model of the connector behavior in the CBA version of the system:

85. Application: automatic synthesis of the coordinator’s code In order to obtain the concurrency conflict-free (i.e. deadlock-free) coordinator we prune all the finite branches of the synthesized connector model. In order to obtain the model of the coordination policy-satisfying coordinator we enforce the policy on the model of the concurrency conflict- free coordinator:  we exploit the automata-based model checking approach.

87. Application: automatic synthesis of the coordinator’s code By visiting the graph of the policy- satisfying coordinator behavior we derive the actual code implementing the coordinator component.

88. IUI1 IUI2 COORDINATOR COMPONENT DSS These interfaces export five services: - write (affected by the policy) - replicate (affected by the policy) - open (a simple delegation) - close (a simple delegation) - read (a simple delegation)

89. HRESULT write(S_DA da) { if(sLbl == 24) { if((chId == 1) && (pState == 0)) { retValue = dssObj->write(da); pState = 1; sLbl = 24; return retValue; } else if((chId == 2) && (pState == 1)) { retValue = dssObj->write(da); pState = 0; sLbl = 24; return retValue; } else if(sLbl == k56) { if((chId == 1) && (pState == 0)) { retValue = dssObj->write(da); pState = 1; sLbl = 44; return retValue; } else if((chId == 2) && (pState == 1)) { retValue = dssObj->write(da); pState = 0; sLbl = 42; return retValue; } else if(sLbl == 42) { if((chId == 1) && (pState == 0)) { retValue = dssObj->write(da); pState = 1; sLbl = 24; return retValue; } else if(sLbl == 44) { if((chId == 2) && (pState == 1)) { retValue = dssObj->write(da); pState = 0; sLbl = 24; return retValue; } return E_HANDLE; }

90. HRESULT write(S_DA da) { if(sLbl == 24) { if((chId == 1) && (pState == 0)) { retValue = dssObj->write(da); pState = 1; sLbl = 24; return retValue; } else if((chId == 2) && (pState == 1)) { retValue = dssObj->write(da); pState = 0; sLbl = 24; return retValue; } else if(sLbl == k56) { if((chId == 1) && (pState == 0)) { retValue = dssObj->write(da); pState = 1; sLbl = 44; return retValue; } else if((chId == 2) && (pState == 1)) { retValue = dssObj->write(da); pState = 0; sLbl = 42; return retValue; } else if(sLbl == 42) { if((chId == 1) && (pState == 0)) { retValue = dssObj->write(da); pState = 1; sLbl = 24; return retValue; } else if(sLbl == 44) { if((chId == 2) && (pState == 1)) { retValue = dssObj->write(da); pState = 0; sLbl = 24; return retValue; } return E_HANDLE; } HRESULT write(S_DA da) { if(sLbl == 24) { if((chId == 1) && (pState == 0)) { retValue = dssObj->write(da); pState = 1; sLbl = 24; return retValue; } else if((chId == 2) && (pState == 1)) { retValue = dssObj->write(da); pState = 0; sLbl = 24; return retValue; } … write1 write4 wview4 wview1 (k24,p0) (k24,p1)

91. HRESULT replicate(S_DA da, LCOPY* plc) { if(sLbl == 24) { if((chId == 1) && (pState == 0)) { retValue = dssObj->replicate(da, plc); pState = 0; sLbl = 42; return retValue; } else if((chId == 2) && (pState == 0)) { retValue = dssObj->replicate(da, plc); pState = 0; sLbl = 44; return retValue; } else if((chId == 1) && (pState == 1)) { retValue = dssObj->replicate(da, plc); pState = 1; sLbl = 42; return retValue; } else if((chId == 2) && (pState == 1)) { retValue = dssObj->replicate(da, plc); pState = 1; sLbl = 44; return retValue; } else if(sLbl == 42) { if((chId == 2) && (pState == 0)) { retValue = dssObj->replicate(da, plc); pState = 0; sLbl = 56; return retValue; } else if((chId == 2) && (pState == 1)) { retValue = dssObj->replicate(da, plc); pState = 1; sLbl = 56; return retValue; } else if(sLbl == k44) { if((chId == 1) && (pState == 0)) { retValue = dssObj->replicate(da, plc); pState = 0; sLbl = 56; return retValue; } else if((chId == 1) && (pState == 1)) { retValue = dssObj->replicate(da, plc); pState = 1; sLbl = 56; return retValue; } return E_HANDLE; }

92. HRESULT replicate(S_DA da, LCOPY* plc) { if(sLbl == 24) { if((chId == 1) && (pState == 0)) { retValue = dssObj->replicate(da, plc); pState = 0; sLbl = 42; return retValue; } else if((chId == 2) && (pState == 0)) { retValue = dssObj->replicate(da, plc); pState = 0; sLbl = 44; return retValue; } else if((chId == 1) && (pState == 1)) { retValue = dssObj->replicate(da, plc); pState = 1; sLbl = 42; return retValue; } else if((chId == 2) && (pState == 1)) { retValue = dssObj->replicate(da, plc); pState = 1; sLbl = 44; return retValue; } else if(sLbl == 42) { if((chId == 2) && (pState == 0)) { retValue = dssObj->replicate(da, plc); pState = 0; sLbl = 56; return retValue; } else if((chId == 2) && (pState == 1)) { retValue = dssObj->replicate(da, plc); pState = 1; sLbl = 56; return retValue; } else if(sLbl == k44) { if((chId == 1) && (pState == 0)) { retValue = dssObj->replicate(da, plc); pState = 0; sLbl = 56; return retValue; } else if((chId == 1) && (pState == 1)) { retValue = dssObj->replicate(da, plc); pState = 1; sLbl = 56; return retValue; } return E_HANDLE; } HRESULT replicate(S_DA da, LCOPY* plc) { if(sLbl == 24) { if((chId == 1) && (pState == 0)) { retValue = dssObj->replicate(da, plc); pState = 0; sLbl = 42; return retValue; } else if((chId == 2) && (pState == 0)) { retValue = dssObj->replicate(da, plc); pState = 0; sLbl = 44; return retValue; } …

93. import idss.idl;... library K1_1_Lib {... coclass K1_1 { [default] interface IDSS; }... class K1_1 : public IDSS { // stores the current state of the connector private static int sLbl; // stores the current state of the // property automaton private static int pState; // stores the number of clients private static int clientsCounter = 0; // channel's number of a client private int chId; // COM smart pointer; is a reference to // the DSS object private static DSS* dssObj;... // the constructor K1_1() { sLbl = 24; pState = 0; clientsCounter++; chId = clientsCounter; dssObj = new DSS();... } // implemented methods... }

94. class K1_1 : public IDSS { // stores the current state of the connector private static int sLbl; // stores the current state of the // property automaton private static int pState; // stores the number of clients private static int clientsCounter = 0; // channel's number of a client private int chId; // COM smart pointer; is a reference to // the DSS object private static DSS* dssObj;... // the constructor K1_1() { sLbl = 24; pState = 0; clientsCounter++; chId = clientsCounter; dssObj = new DSS();... } import idss.idl;... library K1_1_Lib {... coclass K1_1 { [default] interface IDSS; }... class K1_1 : public IDSS { // stores the current state of the connector private static int sLbl; // stores the current state of the // property automaton private static int pState; // stores the number of clients private static int clientsCounter = 0; // channel's number of a client private int chId; // COM smart pointer; is a reference to // the DSS object private static DSS* dssObj;... // the constructor K1_1() { sLbl = 24; pState = 0; clientsCounter++; chId = clientsCounter; dssObj = new DSS();... } // implemented methods... }

95. What we achieved in this example ? We have:  described a connector-based architectural approach to component assembly;  applied it in order to automatically synthesize coordinators components for COTS group-ware applications;  applied it in a real-scale context (namely the Microsoft COM/DCOM applications context). Our approach focuses on detection of concurrent activities conflicts and on enforcing coordination policies on the assembly. The software architecture imposed on the composed system allows for easy replacement of a connector with an other one in order to make the whole system flexible with respect to different coordination policies. The approach is oriented to coordination protocols enforcing besides coordination protocols analysis.

96. Summarizing A general framework to synthesize coordinator connectors for black-box component-based systems Assumes a fixed SA Can capture globally observable properties

97. Automatic synthesis tool architecture

98. Dealing with multi-layer systems Idea:  make the layers of a multi-layer architecture completely independent in order to reduce a multi-layer system in a set of single-layer subsystems. Behavior of a component within the multi-layer hierarchy as:  i) top component behavior (Bottom domain AC-Graph);  ii) bottom component behavior (Top domain AC-Graph).

99. Compositionality The approach is compositional with respect to the assembled system evolution; compositional in the connector synthesis process:  K’ = F(K P,C 1,..,C n,C n+1,..C n+m ); compositional in the property enforcing process:  P is already validated in K’ along the paths corresponding to the paths of K P.

100. Example: compositionality {P : P = G(F( ))  G(F( )) for all states g = in K’ for which the unification procedure has applied the compositional unification step}. {P 1, P 2 } where P 1 = G(F( ))  G(F( )) and P 2 = G(F( ))  G(F( )).

101. Where are we applying the approach?  “Web Service” orchestration (MURST-CNR SP4 project in collaboration with “ThinkTeam”): coordination of software components interacting through a WAN (e.g.: INTERNET network);  policy enforcing by adding behaviors to the connector rather than cutting behaviors (MURST-CNR SP4 project in collaboration with Telecom ITALIA Research Laboratories): to make possible the extension of already existent services of an application (e.g.: adding security and commit features to the “Call&Pay Taxi” service);  system security at architectural level: malicious component updating; malicious component replacing.

102. What is good Automatic synthesis of correct assembly Automatic production of connector code General coordination properties Evolutionary, i.e. we can change coordinator

103. What is bad …still in progress We have not:  considered only one component based contexts, which can greatly influence/constrain many of the above mentioned choices (what type of information we have to store in the AC-Graph nodes?);  implemented a complete framework supporting the whole approach automation and the integration with others tools (e.g.: LTSA);  analyzed human cost and the user interaction degree (great influence on the applicability);  proposed how to specify a property in a more user-friendly manner: study the applicability of the property elucidation approach;  Fully experimented how to avoid the state-space explosion problem in order to reduce the complexity of the synthesis: on-the-fly connector synthesis; study the applicability of partial order reduction techniques; study the applicability of the assume-guarantee paradigm (compositional reasoning techniques).

104. References Uncovering Architectural Mismatch in Component Behavior D. Compare, Paola Inverardi,, A.L. Wolf Science Of ComputerProgramming (33)2 (1999) pp. 101-131 Static Checking of Systems Behaviors Using Derived Component Assumptions Paola Inverardi, Daniel Yankelevich, Alexander L. Wolf ACM TOSEM vol. 9, n.3, July 2000, pp.239-272. Proving Deadlock Freedom in Component-Based Programming Paola Inverardi, Sebastian Uchitel Proceedings FASE 2001, LNCS 2029, Genova April 2001

105. References Automatic Synthesis of Deadlock free connectors for COM/DCOM Applications Paola Inverardi, Massimo Tivoli ACM Proc. FSE/ESEC 2001, Vienna 2001 Connectors Synthesis for Deadlock-Free Component Based Architectures Paola Inverardi, Simone Scriboni IEEE Proc. 16th ASE 2001. Deadlock free Software Architectures for COM/DCOM Applications Paola Inverardi, Massimo Tivoli Journal of System and Software, CBSE Special Issue Automatic synthesis of coordinators of COTS group-ware applications: an example A. Bucchiarone, P.Inverardi, M.Tivoli DMC 2003, IEEE proceedings WETICE 2003 Web pages: http://www.di.univaq.it/~tivoli/, http://www.di.univaq.it/inverardhttp://www.di.univaq.it/~tivoli/