View
214
Download
0
Category
Tags:
Preview:
Citation preview
Software Architectures for Correct Components Assembly
Paola Inverardi
Dipartimento di Informatica
Universita’ dell’Aquila
Several people contributed to the general issue …
Alexander Wolf Daniel Yankelevich Sebastian Uchitel Simone Scriboni Massimo Tivoli
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
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.
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.
The role of Software Architecture Very high level system abstraction
Component and connectors
Architectural Properties
Does this help in managing verification problems?
A bit of history: CP
3
Compressing HTTP Proxy (CP)
Adaptor(Pseudo Filter)
Filter Filter
GZIP
function-call interface
UNIX pipe interface
UNIX process
component
channel 1 2
3 41
32
4
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.
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.
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.
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 …
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?
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
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
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.
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.
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.
Back to CP
3
Compressing HTTP Proxy (CP)
Adaptor(Pseudo Filter)
Filter Filter
GZIP
function-call interface
UNIX pipe interface
UNIX process
component
channel 1 2
3 41
32
4
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
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
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.
Deadlock Freedom Checking Algorithm1. 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.
call return call
return
output
restart
output
service
ServerActual Behaviour
ClientAssumed Behaviour
Successful Matching
Stopping nodes
Successful Matching (II)
return
return
output
restart
call output
service
ServerActual Behaviour
ClientAssumed Behaviour
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.
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.
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?
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
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.
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.
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).
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.
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?
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.
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.
Connector Free Architecture
Component 1
Component 2 channel
Component 3
channel
A Connector Free Architecture (CFA) is a set ofcomponents directly connected in a synchronous way.
In CCS : (C1 | C2 | ... | Cn) \ Ui=1..n Acti
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.
RE
QU
ES
TN
OT
IFIC
AT
ION
Connectortop
bottom
Component 1
top
bottomchannel 1
Component 2
top
bottom
channel 2
Component 3
top
bottom
channel 3
In CCS:(C1[f1] | C2 [f2] | ... | Cn[fn] | K) \U i=1..n Acti[fi]
K is the synthesized connector, fi are suitable relabelling functions such that fi()=i, for all Acti
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 ConnectorConnector code(assembly code)
Example A client/server (single-layer) system:
2 clients (C1, C2); 1 server (C3).
C1 C2 C3a
b
S1
bMSCs:
S1 S2
HMSC:
C1 C2 C3c
d
a
S2
sLbl1=S1
sLbl2=S2 sLbl3=S3
sLbl1=S’1sLbl2=S2 sLbl3=S’3
sLbl1=S1
sLbl2=S2 sLbl3=S3
sLbl1=S1 sLbl2=S2sLbl3=S3
sLbl1=S1 sLbl2=S’2 sLbl3=S’’3
sLbl1=S1 sLbl2=S’’2 sLbl3=S’’’3
sLbl1=S1 sLbl2=S2sLbl3=S3
Local Views: AC-AS- graphsC1 C2
C3
CFA-system
How to model all the local views from the component
perspective?
Example: AC-AS- graphs
Knowing the composition mechanism
AS: assumptions on the environment AS1: c
a
db a
S1
SI1
S2
SI2
SII2
S3
SII3
SIII3
c
a
d
SI3
abAS2: AS3:
AC: the inner knowledgeAC1: c
a
db a
S1
SI1
S2
SI2
SII2
S3
SII3
SIII3
c
a
d
SI3
abAC2: AC3:
If we know the SA …EX- graphs
C1 C2
C3
K1 2
3CBA-system
Knowing the characteristics of the connector, i.e. the environment
EX: assumptions on the connector
EX1: c2
a2
d?b1
a1
S1
SI1
S2
SI2
SII2
EX2: EX3:
a?
b?
S1
SI1
c?
a?
d2
S2 SI2
SII2
c?
a?
d3S3
SII3
c3
a3
d?
S3SII
3
SIII3
SIII3
b3
a3
b?
a?
S3SI
3
SI3
Example: EX-Graphs unification (first step)
K: c2 a2
d3K1
K5c3
a3
d2
K4
K9
K10K11
b3
a3
b1
a1
K2K3
K6
K7K8
nodes labels:
a1 a3
K1=<S1,S2,S3>
K2=<S1,S2,S3>K3=<SI
1,S2,SI3>
K4=<S1,S2,S3>
K5=<S1,SI2,S
II3>
K6=<SI1,S2,S
I3>
K7=<S1,SI2,S
II3>
K8=<SI1,S
I2,S
III3>
K9=<S1,SI2,S
II3>
K10=<S1,SII
2,SIII
3>
K11=<S1,SII
2,SIII
3>
is based on a usual first-order unification algorithm
EX1: c2
a2
d?b1
a1
S1
SI1
S2
SI2
SII2
EX2: EX3:
a?
b?
S1
SI1
c?
a?
d2
S2 SI2
SII2
c?
a?
d3S3
SII3
c3
a3
d?
S3SII
3
SIII3
SIII3
b3
a3
b?
a?
S3SI
3
SI3
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).
Example: deadlock recovery (second step)
K: c2 a2
d3K1
K5c3
a3
d2
K4
K9
K10K11
b3
a3
b1
a1
K2K3
K6
K7K8
nodes labels:
a1 a3
K1=<S1,S2,S3>
K2=<S1,S2,S3>K3=<SI
1,S2,SI3>
K4=<S1,S2,S3>
K5=<S1,SI2,S
II3>
K6=<SI1,S2,S
I3>
K7=<S1,SI2,S
II3>
K8=<SI1,S
I2,S
III3>
K9=<S1,SI2,S
II3>
K10=<S1,SII
2,SIII
3>
K11=<S1,SII
2,SIII
3>
AS1: c
a
db a
S1
SI1
S2
SI2
SII2
S3
SII3
SIII3
c
a
d
SI3
abAS2: AS3:
a
b
<=CB
<=CB
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-freerouting policy to the connector
it is possible to avoid the deadlockscenario.
Table
Connector Based Architectural View
Connector
Table
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.
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
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}; 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;
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,P
intersection;
return KP as the P-satisfiyng connector graph.
Property enforcing (third step)
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
Our approach: an examplefrom the bMSCs and HMSCs specification to theAC-Graphs for each component (from Sebastian Uchitel,
Jeff Kramer and Jeff Magee):
a
b
c
a
d
AC3
C1 C2 C3
ab
bMSC1
C1 C2 C3c
a
bMSC2
d
bMSC1bMSC2
a
a
bb
bMSC1 bMSC2
HMSC
c
c
a
a
dd
Our approach: an examplefrom the AC-Graphs to the AS-Graphs for eachcomponent:
a
b
c
a
d
AC3
a
b
c d
AS3
a
Our approach: an examplefrom the AS-Graphs to the EX-Graphs for eachcomponent:
a
b
c d
AS3
a
EX3
a?
a3
b3
b?
c?
c3 a?
a3
d3d?
Our approach: an exampleEX-Graphs unification (coordinator graph) and concurrency conflicts avoidance (deadlock-free coordinator graph):
EX3
a?
a3
b3
b?
c?
c3 a?
a3
d3d?
a1
a?
b?
b1EX1
c2
c? a2
a?
d?d2
EX2
a1
a?
c2
c?
K
a1
a3
c2
c3
b3
b1
a2
a3
d3d2
a1
a3
deadlock
K
a1
a3
c2
c3
b3
b1
a2
a3
d3d2
Our approach: an exampleCoordination policy enforcing (failure-free coordinator graph):
K
a1
a3
c2
c3
b3
b1
a2
a3
d3d2
KSK
{a1}{a3}{c2} {c3}
{b3}{b1,d2}
{a2}
{a3}{d3}
P=F((a1 X(!a1 U a2)) (a2 X(!a2 U a1)))
BKS
a1
a3
c2
c3
b3
b1
a2
a3
d3d2
K
b1 d2k1
k2k3
k6
k4 k5 k9
k10
k11
BPCBA
a1 a2
a2 a1
!a1
!a2
true
p0p1
p2
p3 ∩
PCBA=F((a1 X(!a1 U a2)) (a2 X(!a2 U a1)))
Our approach: an exampleCoordination policy enforcing (failure-free coordinator graph):
BKS
a1
a3
c2
c3
b3
b1
a2
a3
d3d2
K
b1 d2k1
k2k3
k6
k4 k5 k9
k10
k11
BPCBA
a1 a2
a2 a1
!a1
!a2
true
p0p1
p2
p3 ∩(k1,p0)
a1a3b3
b1
a2
c2 c3
a2
c2 c3a3
d3d2
a1
(k2,p1)(k3,p1)
(k6,p1)
(k1,p1)
(k4,p1) (k5,p1)(k9,p3)
(k4,p0) (k5,p0) (k9,p2) (k10,p2)
(k11,p2)
(k1,p2)
(k2,p3)c2
c3(k4,p2)
(k5,p2)
Our approach: an example
Assembly code derivation (coordinator code derivation):
(k1,p0)a1
a3b3b1
c2 c3
c2 c3a3
d3d2
(k2,p1)(k3,p1)
(k6,p1)
(k1,p1)
(k4,p1)
a2
(k5,p1)(k9,p3)
(k4,p0)
a2
(k5,p0) (k9,p2) (k10,p2)
(k11,p2)a1
(k1,p2)
(k2,p3)
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.
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?
Application: a semi-synchronous CW system
The following assumption is needed in order to obtain consistency maintenance: when a user wantsto work in asynchronous mode, the DSS expects that allother users work in asynchronous mode too.
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;
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:
^
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):
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):
Application: automatic synthesis of the coordinator’s code By unifying each EX-Graph we can derive
the model of the connector behavior in the CBA version of the system:
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.
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.
IUI1
IUI2
COORDINATOR COMPONENT
DSS
These interfaces exportfive services:- write (affected by the policy)- replicate (affected by the policy)- open (a simple delegation)- close (a simple delegation)- read (a simple delegation)
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; } } 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)
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; } 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; }…
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 ...}
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 ...}
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.
Summarizing
A general framework to synthesize coordinator connectors for black-box component-based systems
Assumes a fixed SA Can capture globally observable
properties
Automatic synthesis tool architectureMSC
specificationof composed
systemscenario1
HMSCspecification of thecomposed system
connector-freearchitecture
From (H)MSC toLTS Translator
AC-Graph 1 AC-Graph 2 AC-Graph 3
AS-Graph 1 AS-Graph 2 AS-Graph 3
EX-Graph 1 EX-Graph 2 EX-Graph 3
UnificationAlgorithm
Connector Model
Failure-free ConnectorModel
Connector CodeBuilder
Failure-freeConnector SourceCode (Assembly
Code)
Property enforcingAlgorithm
MSCspecificationof composed
systemscenario2
MSCspecificationof composed
systemscenario3
AC-Graph 4
AS-Graph 4
EX-Graph 4
intermediatecomponent views
From LTL formulas toBuchi AutomataTranslator
LTL properties set(expectedbehaviors)
Buchi Automata set(unexpected behaviors)
..
..
CB-SimulationChecker
Failure-free ConnectorModel satisfying
componentsassumptions
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).
C1 C2
C3
C4 C5 C6
2-layer CFA architecture
layer 1
layer 2
C1 C2
Bottom ComponentBehavior of C3
C4 C5 C6
Top ComponentBehavior of C3
single-layer CFA architecture 1
single-layer CFA architecture 2
Compositionality
The approach is compositional with respect to the assembled system evolution;
compositional in the connector synthesis process: K’ = F(KP,C1,..,Cn,Cn+1,..Cn+m);
compositional in the property enforcing process: P is already validated in K’ along the paths
corresponding to the paths of KP.
Example: compositionalityC1:
b a
a
c
d
a3
b1
a1
b3
b1
a1
b2
a2
C2:
b a b a
K
d c
b
CBA1:
add and components
b a b a b aCBA2: a
c
d c
b
d
a5
a1
c5
c4
b5b1
d5
d4
d5
d4d4
d5
a3
b1
a1b3
b1
a1b2
a2
a3
b1a1
b3
b1
a1 b2
a2
KI
S1
SI1
S2
SI2
C3: S3
SI3
C4: S4
SI4
C5: S5
SI5
SII5
SIII5
C1: S1
SI1
C2: S2
SI2
C3: S3
SI3
C4: S4
SI4
C5: S5
SI5
SII5
SIII5
KI1
KI14
{P : P = G(F(<S’1,S’2,S3,X,Y>)) G(F(<S’1,S2,S’3,X,Y>)) for all statesg =<S1,S2,S3,X,Y> in K’ for which the unification procedure has applied the compositional unification step}.
{P1, P2} where P1 = G(F(<S’1,S’2,S3,S4,S5>)) G(F(<S’1,S2,S’3,S4,S5>)) andP2 = G(F(<S’1,S’2,S3,S’4,S’’’5>)) G(F(<S’1,S2,S’3,S’4,S’’’5>)).
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.
What is good
Automatic synthesis of correct assembly
Automatic production of connector code
General coordination properties
Evolutionary, i.e. we can change coordinator
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).
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
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
Recommended