Software Architectures for Correct Components Assembly

1
Software Architectures for Correct Components
Assembly

• Paola Inverardi
• Dipartimento di Informatica
• Universita dellAquila

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
3
2
1
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

Fine but
Could have we been smarter?
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. (C1 C2 ... Cn) / L
• Deadlock (C1 C2 ... Cn) / 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
3
2
1
4
19
Filters
20
GZIP
21
Adaptor
22
Partial Equivalence

• 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

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

• Generate assumptions for each component.
• Get assumption not completely matched.
• Find a component behaviour that is partially
  equivalent to the assumption.
• If not found return false.
• Tag matched portion of assumption.
• Change initial states in assumption and component
  behaviour.
• If there are assumptions not completely matched
  go to 2.
• Return true.

26
Partial match
27
Partial match
28
Partial match
29
Successful Matching
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(KN)
• Time O(N3.K4.log(K)) vs O(KN)
• 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. (C1 C2 ... Cn) / L
• Deadlock (C1 C2 ... Cn) / L can reach a
  state where no actions are possible.

47
Connector Free Architecture
Component 1
Component 2
channel
channel
Component 3
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.

In CCS (C1f1 C2 f2 ... Cnfn K) \U
i1..n Actifi K is the synthesized
connector, fi are suitable relabelling functions
such that fi(a)ai, for all aÎActi
49
Approach description 3-step method
Connector Free Architecture
Component 1
Component 3
Component 2
50
Example

• A client/server (single-layer) system
• 2 clients (C1, C2)
• 1 server (C3).

sLbl3S3
sLbl2S2
sLbl3S3
sLbl1S1
sLbl2S2
sLbl1S1
sLbl2S2
sLbl3S3
sLbl3S3
sLbl1S1
sLbl2S2
sLbl1S1
sLbl3S3
sLbl1S1
sLbl2S2
sLbl2S2
sLbl3S3
sLbl1S1
sLbl3S3
sLbl1S1
sLbl2S2
51
Local Views AC-AS- graphs
How to model all the local views from the
component perspective?
52
Example AC-AS- graphs
53
If we know the SA EX- graphs
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 Ci has to CB-simulate the
  AS-Graph ASi.
• 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)
57
Deadlock Freeness an example

• Dining Philosophers Problem

Assigning a deadlock-free routing policy to the
connector it is possible to avoid the
deadlock scenario.
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 t transitions
• BP is the Büchi Automaton (automaton over
  infinite words) corresponding to P.
• Connector Model
• KSK is the Kripke structure corresponding to K
• BKSK is the Büchi Automaton corresponding to KSK

61
Property enforcing (third step)

• Enforcing procedure based on the construction of
  the product language
• 1. build the automaton BK,Pintersection that
  accepts L(BKSK) Ç L(BP)
• 2. if BK,Pintersection is not empty then
• derive KP as the fair connector graph
  corresponding to BK,Pintersection
• return KP as the P-satisfiyng connector graph.

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)
C1
C1
C2
C3
C2
C3
c
a
AC3
b
a
b
d
d
a
c
bMSC1
bMSC2
a
64
Our approach an example
from the AC-Graphs to the AS-Graphs for
each component
AC3
AS3
b
b
d
d
a
c
c
a
a
a
65
Our approach an example
from the AS-Graphs to the EX-Graphs for
each component
EX3
AS3
b?
d?
d3
b
a?
c?
a3
d
b3
c
a
a3
c3
a?
a
66
Our approach an example
EX-Graphs unification (coordinator graph) and
concurrency conflicts avoidance (deadlock-free
coordinator graph)
b1
EX1
a1
b?
a?
d2
d?
EX2
c2
a?
c?
a2
deadlock
EX3
b?
d?
d3
a?
c?
a3
b3
a3
c3
a?
67
Our approach an example
Coordination policy enforcing (failure-free
coordinator graph)
n
68
Our approach an example
Coordination policy enforcing (failure-free
coordinator graph)
BKS
K
!a1
b1
d2
b1
d2
k1
k6
k10
n
d3
a1
a2
p1
p0
a1
c2
k11
p3
a3
b3
true
p2
a2
a1
a2
a3
c3
k2
k3
k4
k5
k9
!a2
69
Our approach an example
Assembly code derivation (coordinator code
derivation)
c2
a3
(k4,p0)
(k9,p2)
(k10,p2)
c3
(k6,p1)
a3
b3
d3
b1
d2
(k2,p1)
(k3,p1)
(k11,p2)
(k1,p1)
(k2,p3)
c2
(k4,p1)
c3
(k9,p3)
70
(No Transcript)
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 documents content displaying scenario
• SYNCWR documents content synchronous
• updating scenario
• REPL documents content replication for
  asynchronous
• updating scenario
• ASYNCWR documents content asynchronous
  updating
• scenario

75
Application behavioral specification of the CW
system
76
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
coordinators code

• From the bMSCs and HMSCs specification we derive
  the models of the components interaction behavior
  (AC-Graphs)

79
Application automatic synthesis of the
coordinators code
80
Application automatic synthesis of the
coordinators 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
coordinators code
82
Application automatic synthesis of the
coordinators code

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

83
(No Transcript)
84
(No Transcript)
85
Application automatic synthesis of the
coordinators 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.

86
(No Transcript)
87
Application automatic synthesis of the
coordinators code

• By visiting the graph of the policy-satisfying
  coordinator behavior we derive the actual code
  implementing the coordinator component.

88
(No Transcript)
89
HRESULT write(S_DA da) if(sLbl 24)
if((chId 1) (pState 0))
retValue dssObj-gtwrite(da) pState
1 sLbl 24 return retValue else
if((chId 2) (pState 1))
retValue dssObj-gtwrite(da) pState
0 sLbl 24 return retValue
else if(sLbl k56) if((chId 1)
(pState 0)) retValue
dssObj-gtwrite(da) pState 1 sLbl
44 return retValue else if((chId
2) (pState 1)) retValue
dssObj-gtwrite(da) pState 0 sLbl
42 return retValue else if(sLbl
42) if((chId 1) (pState 0))
retValue dssObj-gtwrite(da)
pState 1 sLbl 24 return retValue
else if(sLbl 44) if((chId 2)
(pState 1)) retValue
dssObj-gtwrite(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-gtwrite(da) pState
1 sLbl 24 return retValue else
if((chId 2) (pState 1))
retValue dssObj-gtwrite(da) pState
0 sLbl 24 return retValue
else if(sLbl k56) if((chId 1)
(pState 0)) retValue
dssObj-gtwrite(da) pState 1 sLbl
44 return retValue else if((chId
2) (pState 1)) retValue
dssObj-gtwrite(da) pState 0 sLbl
42 return retValue else if(sLbl
42) if((chId 1) (pState 0))
retValue dssObj-gtwrite(da)
pState 1 sLbl 24 return retValue
else if(sLbl 44) if((chId 2)
(pState 1)) retValue
dssObj-gtwrite(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-gtwrite(da) pState
1 sLbl 24 return retValue
else if((chId 2) (pState 1))
retValue dssObj-gtwrite(da) pState
0 sLbl 24 return retValue

91
HRESULT replicate(S_DA da, LCOPY plc)
if(sLbl 24) if((chId 1) (pState
0)) retValue dssObj-gtreplicate(da,
plc) pState 0 sLbl 42 return
retValue else if((chId 2)
(pState 0)) retValue
dssObj-gtreplicate(da, plc) pState 0
sLbl 44 return retValue else
if((chId 1) (pState 1))
retValue dssObj-gtreplicate(da, plc)
pState 1 sLbl 42 return retValue
else if((chId 2) (pState 1))
retValue dssObj-gtreplicate(da, plc)
pState 1 sLbl 44 return retValue
else if(sLbl 42) if((chId 2)
(pState 0)) retValue
dssObj-gtreplicate(da, plc) pState 0
sLbl 56 return retValue else
if((chId 2) (pState 1))
retValue dssObj-gtreplicate(da, plc)
pState 1 sLbl 56 return retValue
else if(sLbl k44) if((chId 1)
(pState 0)) retValue
dssObj-gtreplicate(da, plc) pState 0
sLbl 56 return retValue else
if((chId 1) (pState 1))
retValue dssObj-gtreplicate(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-gtreplicate(da,
plc) pState 0 sLbl 42 return
retValue else if((chId 2)
(pState 0)) retValue
dssObj-gtreplicate(da, plc) pState 0
sLbl 44 return retValue else
if((chId 1) (pState 1))
retValue dssObj-gtreplicate(da, plc)
pState 1 sLbl 42 return retValue
else if((chId 2) (pState 1))
retValue dssObj-gtreplicate(da, plc)
pState 1 sLbl 44 return retValue
else if(sLbl 42) if((chId 2)
(pState 0)) retValue
dssObj-gtreplicate(da, plc) pState 0
sLbl 56 return retValue else
if((chId 2) (pState 1))
retValue dssObj-gtreplicate(da, plc)
pState 1 sLbl 56 return retValue
else if(sLbl k44) if((chId 1)
(pState 0)) retValue
dssObj-gtreplicate(da, plc) pState 0
sLbl 56 return retValue else
if((chId 1) (pState 1))
retValue dssObj-gtreplicate(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-gtreplicate(da
, plc) pState 0 sLbl 42
return retValue else if((chId
2) (pState 0)) retValue
dssObj-gtreplicate(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(KP,C1,..,Cn,Cn1,..Cnm)
• compositional in the property enforcing process
• P is already validated in K along the paths
  corresponding to the paths of KP.

100
Example compositionality
P P G(F(ltS1,S2,S3,X,Ygt)) Ù
G(F(ltS1,S2,S3,X,Ygt)) for all states g
ltS1,S2,S3,X,Ygt in K for which the unification
procedure has applied the compositional
unification step. P1, P2 where P1
G(F(ltS1,S2,S3,S4,S5gt)) Ù G(F(ltS1,S2,S3,S4,S5gt)
) and P2 G(F(ltS1,S2,S3,S4,S5gt)) Ù
G(F(ltS1,S2,S3,S4,S5gt)).
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 CallPay
  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/inverard