GSSI PhD in Computer Science
L’Aquila, Italy
Nov 11th, 2013
Component-based design and connector synthesis
(Lecture 1)
Massimo Tivoli
Email: [email protected]
Roadmap of this lecture
• CBSE basic principles
• What is a component?
(very briefly)
• Object-oriented design vs component-based design
• What is a connector?
• Connector synthesis
• background notions
• synthesis of centralized coordinators [SCP08]
• synthesis of distributed coordinators [JSS08]
What is CBSE and why?
• CBSE was born at the end of 90’s as a reuse-based software
engineering approach
• huge number of software applications available
• OO development was found to be less appropriate
• time-to-market
• Focus on reuse of third-party software entities and their
integration according to a certain goal
CBSE essentials
• Independent components
• Component standards
• Middleware
• Development process
CBSE’s open issues
• Component trust
• Component certification
• Emergent properties prediction
• Requirement tradeoffs
CBSE’s open issues
• Component trust
• black-box nature
• unexpected internal behavior
• malicious behavior
This is the main focus of my 2 lectures on
• Component certification “Component-based design and connector synthesis”
• in case a component does not behave as expected, it is very difficult to establish
responsibilities
• conformance check against a formal specification is not of much interest for the
industry
• Emergent properties prediction
• although one could use trustworthy and certified components, once they are put
together in an uncontrolled way, the resulting system can exhibit some issues or
undesired properties
• automated or systematic methods to solve integration issues are crucial to
effectively support correct-by-construction component assembly
• Requirement tradeoffs
• it is very frequent that the available components do not completely reflect the
specified local requirements
• systematic tradeoff analysis methods are highly needed
What is a component?
• In the literature there exist several definitions of the component concept
(indeed, too many!)
• “A software component is a unit of composition with contractually
specified interfaces and explicit context dependencies only. A
software component can be deployed independently and is subject to
third-party composition.” [C. Szyperski, Component Software –
Beyond Object Oriented Programming, Addison Wesley, 1998]
• “A component is a unit of distributed program structure that
encapsulates its implementation behind a strict interface comprised of
services provided by the component to other components in the
system and services required by the component and implemented
elsewhere. The explicit declaration of a component's requirements
increases reuse by decoupling components from their operating
environment.” [S. Crane, Component Interaction in Distributed
Systems, ICCDS’98]
What is a component?
• In the literature there exist several definitions of the component concept
(indeed, too many!)
• “A software component is a unit of composition with contractually
specified interfaces and explicit context dependencies only. A
software component can be deployed independently and is subject to
third-party composition.” [C. Szyperski, Component Software –
Beyond Object Oriented Programming, Addison Wesley, 1998]
• “A component is a unit of distributed program structure that
encapsulates its implementation behind a strict interface comprised of
services provided by the component to other components in the
system and services required by the component and implemented
elsewhere. The explicit declaration of a component's requirements
increases reuse by decoupling components from their operating
environment.” [S. Crane, Component Interaction in Distributed
Systems, ICCDS’98]
What is a component?
• In the literature there exist several definitions of the component concept
(indeed, too many!)
• “A software component is a unit of composition with contractually
specified interfaces and explicit context dependencies only. A
software component can be deployed independently and is subject to
third-party composition.” [C. Szyperski, Component Software –
Beyond Object Oriented Programming, Addison Wesley, 1998]
• “A component is a unit of distributed program structure that
encapsulates its implementation behind a strict interface comprised of
services provided by the component to other components in the
system and services required by the component and implemented
elsewhere. The explicit declaration of a component's requirements
increases reuse by decoupling components from their operating
environment.” [S. Crane, Component Interaction in Distributed
Systems, ICCDS’98]
What is a component?
• In the literature there exist several definitions of the component concept
(indeed, too many!)
• “A software component is a unit of composition with contractually
specified interfaces and explicit context dependencies only. A
software component can be deployed independently and is subject to
third-party composition.” [C. Szyperski, Component Software –
Beyond Object Oriented Programming, Addison Wesley, 1998]
• “A component is a unit of distributed program structure that
encapsulates its implementation behind a strict interface comprised of
services provided by the component to other components in the
system and services required by the component and implemented
elsewhere. The explicit declaration of a component's requirements
increases reuse by decoupling components from their operating
environment.” [S. Crane, Component Interaction in Distributed
Systems, ICCDS’98]
What is a component?
• In the literature there exist several definitions of the component concept
(indeed, too many!)
• “A software component is a unit of composition with contractually
specified interfaces and explicit context dependencies only. A
software component can be deployed independently and is subject to
third-party composition.” [C. Szyperski, Component Software –
Beyond Object Oriented Programming, Addison Wesley, 1998]
• “A component is a unit of distributed program structure that
encapsulates its implementation behind a strict interface comprised of
services provided by the component to other components in the
system and services required by the component and implemented
elsewhere. The explicit declaration of a component's requirements
increases reuse by decoupling components from their operating
environment.” [S. Crane, Component Interaction in Distributed
Systems, ICCDS’98]
So, what is a component?
(a revised version of Michael Stal’s definition - http://www.softwareresearch.net/fileadmin/src/docs/publications/J010.pdf)
• A component is a self-contained black-box entity that provides
(resp., requires) functionalities to (resp., from) its environment by
defining its interfaces, hence making them public (i.e., accessible
from outside)
• An interface defines the syntax and (as much as possible) the
semantics of the functionalities it comprises and, hence,
represents a contract between the component and its
environment
• In order to build an assembly, components may support their
composition with other components by providing “quasireflective” mechanisms (such as introspection, controllability,
configuration management, etc.)
Object-oriented design vs component-based
design
OO design
CB design
• Objects fit together like pieces • Components are really
in a jigsaw puzzle
loosely-coupled
• System interaction
mechanisms can be designed
into the objects
• Interaction mechanisms left
out of the individual
components
• The interaction mechanisms a
component rely on depend on
the context and its
environment
Component-based design
• The components that comprise a system typically do not exactly
fit together as pieces of a jigsaw puzzle
• They leave significant integration gaps that must somehow be
filled with additional code
• Such integration code is often referred to as “assembly code”
and is typically highly special purpose and specific
• Thus, by simplifying matters, a component-based system
consists of component instances and their connectors (i.e., the
“assembly code”)
What is a connector?
• Architectural element that models
• Simple interactions
• Complex & semantically rich interactions
• Each connector provides
What is a connector?
• Connector  Component
• Interaction abstraction and/or parameterization
• Specification of complex interactions
• Connectors allow to realize component independence
Software connector roles
• Locus of interaction among set of components
• Protocol specification (sometimes implicit) that defines its
properties
• (some) Roles
• communication
• coordination
• mediation/adaptation
Connectors as communicators
• Focus on the middleware layer
• Support for defining
• different communication mechanisms
• constraints on communication structure/direction
• constraints on quality of service
• Separates communication from computation
• May influence non-functional system characteristics
Connectors as coordinators
• Focus on the application layer
• Determine computation control
• Control delivery of data
• Separates the control-flow from the computation
• Orthogonal to communication and mediation/adaptation
Connectors as mediators/adapters
• Focus on both the application layer and the middleware
layer
• Enable interaction of independently developed, mismatched
components
• Mismatches based on interaction
Roadmap of this lecture
• CBSE basic principles
• What is a component?
(very briefly)
• Object-oriented design vs component-based design
• What is a connector?
• Connector synthesis
• background notions
• synthesis of centralized coordinators [SCP08]
• synthesis of distributed coordinators [JSS08]
Automated connector synthesis
• CBSE promotes the extensive and dynamic reuse of
heterogeneous and independent software components
• Heterogeneous components may be willing to cooperate in
order to reach some common goal even though they meet
dynamically and do not have a priori knowledge of each
other
• Challenge: how to automatically achieve the
interoperability between heterogeneous components?
Modeling the component observable behavior
aka component protocol
• The term protocol refers to interaction protocols or observable protocols
• We consider application-layer protocols (as opposed to middlewarelayer protocols)
• behavior of a component in terms of the sequences of messages at
the interface level, which it exchanges with other components
• the notion of protocol abstracts from the content of the exchanged
messages, i.e., values of method/operation parameters, return
values, etc.
• Our focus is on harmonizing the behavioral protocol (e.g., scheduling of
operation calls) of heterogeneous components rather than performing
mediation of communication primitives or of data encoding/decoding
(i.e., middleware-layer connectors)
Modeling application-layer protocols: an example
• By using Labeled Transition Systems (LTSs)
FileHandler
Input actions, e.g., open,
model
- methods that can be called;
- receiving messages;
- return values.
Output actions, e.g., ack,
model
- method calls;
- message transmission;
- exceptions.
open
write
read
close
ack
Interoperability
• The ability of heterogeneous protocols to interact and correctly coordinate to
achieve their goal(s)
• Interaction expressed as synchronization
• two protocols interact if they are able to synchronize on common actions
• for application-layer protocols, it goes beyond single basic synchronizations and
may require a well defined sequence of synchronization to be achieved (a primary
from of coordination)
• E.g., sendItems <-> receiveItems
(simple case)
sendItems <-> receiveItem … receiveItem (more complex case)
• Coordination expressed as the achievement of a specified goal
• two protocols succeed in coordinating if they interact through synchronization
according to the achievement of their goal(s)
• Goal usually specified in some automata-based or temporal logic formalism
The interoperability problem
• It concerns the problem of both enabling interaction and achieving correct
coordination (w.r.t. the specified goal)
• Solution: automatic synthesis of application-layer connectors
• Automatic coordinator synthesis (my past research)
• the main focus is on addressing correct coordination by assuming the
interaction problem already solved
• Automatic mediator synthesis (my recent research in the CONNECT EU
project)
• it focuses on the whole interoperability problem, i.e., addressing interaction +
correct coordination
The need for coordinators
already interacting black-box
components
Component 1
their interaction may deadlock…
…or violate a specified desired
behavior
Component 3
Component 2
desired behavior
specification
solution
Component 1
Component 3
Coordinator
Component 2
the coordinator is an additional component
synthesized so as to intercept all component
interactions in order to prevent deadlocks and
those interactions that violate the specified
desired behavior
The need for coordinators: the shared resource
scenario
AlternatingProtocol desired
behavior specification
Deadlock!
Screenshots from the SYNTHESIS tool. I’ll give a short demo of it.
The need for mediators: scenario 1 of the SWS
challenge (http://sws-challenge.org/wiki/)
• Two components implemented using different standards and protocols: the Moon Client
(MC) and the Blue Service (BS)
Login
MOON
Client
(MC)
Login
Close
Interaction
mismatches concern
the semantics and
granularity of protocol
actions
CreateOrder
SelectItem
CreateOrder
StartOrder
AddItemToOrder
SetItemQuantity
ConfirmItem
ConfirmItem
GetConfirmation
BLUE
Service
(BS)
SetItemQuantity
SelectItem
PayThirdParty
CloseOrder
Close
CloseOrder
PayThirdParty
PlaceOrder
AddItemToOrder
GetConfirmation
StartOrder AddItemToOrder Quit
GetConfirmation
PlaceOrder Quit
Roadmap of this lecture
• CBSE basic principles
• What is a component?
(very briefly)
• Object-oriented design vs component-based design
• What is a connector?
• Connector synthesis
• background notions
• synthesis of centralized coordinators [SCP08]
• synthesis of distributed coordinators [JSS08]
Automatic synthesis of Failure-Free
Coordinators (FFC)
• Interaction issues are assumed to be already solved
• protocols are already able to synchronize, although deadlocks in their
interaction can occur or their interaction could not satisfy specified
behavioral properties
• A specific instance of the interoperability problem
• given a set of interacting components, C, and a set of behavioral properties,
P, automatically derive a deadlock-free assembly, A, of these components
which guarantees every property in P, if possible
• A is a composition of the components in C plus a synthesized coordinator
• the coordinator is an additional component that controls the message
exchange to prevent possible deadlocks and those interactions violating the
properties in P
• Two different approaches (following slides)
• centralized coordinators
• distributed coordinators
Automatic synthesis of centralized FFC: basic Idea
• A simple software architecture structure which
exploits the separation between functional
behavior and interaction behavior
• Extra information at component level: component
assumptions
• Our approach
• detect software anomalies
• prevent software anomalies
• guarantee given coordination policies (behavioral
properties)
Automatic synthesis of centralized FFC: modeling
• Component behaviour modelled using finite state machines
• Assembly through parallel composition of component models
• In the context of CCS
• Components: sequence and choice operators
E.g. FileHandler = open.(read + write)*.close.FileHandler
• Assembly: 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
Automatic synthesis of centralized FFC:
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
Automatic synthesis of centralized FFC: background
notions (cont’d)
• Coordinator Free Architecture (CFA)
Component 1
Component 2
channel
channel
Component 3
a Coordinator Free Architecture (CFA) is a set of
components directly connected in a synchronous way
in CCS :
(C1 | C2 | ... | Cn) \ Ui=1..n Acti
Automatic synthesis of centralized FFC: background
notions
• Coordinator Based Architecture (CBA)
top
REQUEST
bottom
channel 1
top
Coordinator
channel 2
channel 3
bottom
top
top
Component 2
NOTIFICATION
Component 1
Component 3
bottom
bottom
in CCS:
(C1[f1] | C2 [f2] | ... | Cn[fn] | K) \U i=1..n Acti[fi]
K is the synthesized connector, fi a suitable relabeling function
Automatic synthesis of centralized FFC: component
local views
How to model all the local views from the component
perspective?
msg2
msg1
AC-Graph: the inner knowledge
msg3
Knowing the composition mechanism and the property
msg1
AS-Graph: assumptions on the environment
msg3
Knowing the characteristics of the coordinator
msg1?
msg2
msg1C
msg2C
msg2?
EX-Graph: assumptions on the coordinator
msg3C
msg3?
Automatic synthesis of centralized FFC: component
local views unification
is based on a
usual first-order
unification algorithm
C1
C2
Coordinator
C3
msg2C1
msg1C1
msg2C2
msg1?
msg1?
msg2?
coordinator
graph obtained
by the unification
of the EX-Graphs
msg2?
msg1C2
msg1C3
msg2?
msg1C1
msg1?
msg2C3
msg1C3
msg2C1
msg2C3
msg1C2
msg1C3
msg2C2
Automatic synthesis of centralized FFC: deadlock
freedom
• Dining Philosophers Problem
Table
Table
Coordinator
Deadlock Scenario:
• component Philosopher1 requests and
gets the resource of component Fork1;
• component Philosopher2 requests and
gets
resource ofacomponent
Fork2;
bythe
assigning
deadlock-free
routing policy to the coordinator,
• component Philosopher1 requests and
itwaits
is possible
to avoid the deadlock
for the resource of component
scenario
Fork2;
Coordinator Free Architectural View
Coordinator Based Architectural View
40
• component Philosopher2 requests and
waits for the resource of component
Fork1;
Automatic synthesis of centralized FFC: 3-step
method
Coordinator Free Architecture
Component 1
Component 3
Component 2
local views of each component
Component 1
Component 3
Failure-free
Coordinator
Deadlock-free
Coordinator
(no-op) Coordinator
Component 2
Deadlock-free
Coordinator
BasedArchitecture
Architecture
Coordinator
BasedBased
Architecture
Failure-free
Coordinator
Coordinator
code
Coordination
policy
deadlock-freeness
(assembly code)
Automatic synthesis of centralized FFC: running
example
CFA
P
C
C1 and C2 has to interact by
following an Alternating Interaction
Protocol
Automatic synthesis of Centralized FFC: running
example
Deadlock-free Coordinator
No-op Coordinator
Automatic synthesis of centralized FFC: running
example
- The Failure-free Coordinator is a refinement
of the deadlock-free one that obeys the
alternating protocol specified by P
-It is obtained by performing a suitable notion
of synchronous product between P and the
deadlock-free coordinator
class K : public IC3 {
// stores the current state of the coordinator
private static int sLbl;
Automatic synthesis of centralized FFC: running
example
// stores the current state of the
HRESULT
method1(S_DA da) {
// property automaton
private
static==
int 0)
pState;
if(sLbl
{
These interfaces export
services:
• By
visiting
modeling
FFC
protocol, the
if((chId
== 1)
&&LTS
(pState
== 0)) { thethree
// stores
the
number
ofthe
clients
- method1 (affected by the policy)
private pState
static int clientsCounter
= 1; sLbl
== 0;
9;
actual
code
implementing
the coordinator
- method2 (affected by the policy)
return
c3Obj->method1(da);
// channel's
number
of ais
client
- method3 (a simple delegation)
component
automatically
derived
private
} int chId;
(k0,p0)
// }
COM smart pointer; is a reference to
C++C3implementation
for COM/DCOM component-based
// …
the•inner
object
/* other
if-statements for each
?C3.method1_1
private
static C3* c3Obj;
(centralized FFC) – in this example…
C1 systems
FFC state in which it is possible
...
!C3.method1_3
to perform method1 */ …
C3
// the constructor
• AspectJ implementation for J2EE applications,
i.e., EJB
?C3.retValue1_3
K()
C2{
systems (distributed FFC) – in the
sLbl component-based
= 0;
return
E_Handle;
!C3.retValue1_1
pState = 0;
following
slides…
COORDINATOR
COMPONENT
} clientsCounter++;
chId = clientsCounter;
c3Obj = new C3();
...
}
(k9,p1)
Roadmap of this lecture
• CBSE basic principles
• What is a component?
(very briefly)
• Object-oriented design vs component-based design
• What is a connector?
• Connector synthesis
• background notions
• synthesis of centralized coordinators [SCP08]
• synthesis of distributed coordinators [JSS08]
Automatic Synthesis of distributed FFC: the
reference architectural style
black-box
components
synchronous
channels
coordination
wrappers
standard communication
additional communication
f1
f2
Distributed CBA
f3
f4
asynchronous
channels
a demo for this approach, and related SYNTHESIS tool,
will be given later…
Automatic synthesis of distributed FFC: first step of
the method
CentralizedCoordinator-Free
Coordinator-Based
Architecture
Architecture
(CFA)
(Centralized CBA
C1
C2
Centralized Coordinator
C3
C4
based on the previous approach
Automatic synthesis of distributed FFC: second
step of the method
Centralized CBA
C1
C2
1) Deadlock-freedom
analysis
Centralized Coordinator (LTS)
2) Desired behavior analysis
C3
P
C4
Desired behavior
specification:
LTS-based notation
Automatic synthesis of distributed FFC: second
step of the method
Distributed CBA
C1
C2
W2
W1
C3
P
» Deadlock free
W4
» Desired behavior
satisfying
C4
(automatically distributed
by Synthesis)
Centralized Coordinator
W3
Distributed Coordinator
(i.e., set of wrappers)
Automatic synthesis of distributed FFC: summing
up
C1
C2
C3
C4
synthesis of the
centralized
coordinator LTS
C1
C2
C3
C4
network of interacting
components (LTSs)
+
desired behavior LTS
P
synthesis of the
actual distributed and
correct coordinator
(i.e., actual code of
the component local
wrappers)
C1
C2
W1
W2
W3
W4
C3
C4
Automatic synthesis of distributed FFC: running
example
C1
C2
C3
C4
A possible deadlock can occur if both C3 and C4 perform the
action at the right of the initial state s0
P
C3 cannot
access resource
C2 without
performing
authentication, first
Automatic synthesis of distributed FFC: running
example
Red nodes represent possible occurring deadlocks
Automatic synthesis of distributed FFC: running
example
when C3 is willing to
perform action p1, its
wrapper, FC3, must
ask permission to the
other wrappers in order to
discover whether the
global state is different from
S12 (C3 is allowed to perform
p1) or not (C3 is not allowed
to perform p1)
LC
FCLC

{}
FC2  {}
1
LC
C3
F
 S12 !C 2. p1
FCLC
 S 2 !C1. p
4
E.g., S12 = <S3,S0,S0,S9>,
FC3 will ask to FC1, FC2, and
FC3, if their supervised
components are in, or will
reach, the states S3, S0, and
S9, respectively
Automatic synthesis of distributed FFC: running
example
each wrapper knows
what are the property
states from which it is
allowed to perform some
action, which action, and
the related target states
UA


FCUA

*
*
*
*
*
F
C2  * * * * *
1
FCUA
3
S0 !C2.Connect

!C1.p
S1
S1
!C2.p1
 
S1 !C1.FreeP
S1 !C2.Connect

S1 !C2.FreeP1
S1 * *
S0
*
S0 * *

S1 * *


S1
!C1.p
S1
*
*

S1 * * UA 
!C2.p1
S1 * *
 FC 4  S1
S1 * *


S1 !C1.FreeP S1 * *
S1 * *


S1 !C2.FreeP1 S1 * *

S0 * *
Automatic synthesis of distributed FFC: wrapper
pseudo-code
• A wrapper FC establishes when its controlled component C
can move (by cooperating with the other wrappers FH):
• The component C must be active (with respect to P)
• Before moving by means of action a, FC checks in FCLC if a is an action that can lead to
forbidden states
• If it is, FC has to ask the permission to the other component wrappers before performing a
• If not, FC allows C to perform a without asking anything
• If C is allowed to perform action a, FC has to check in FCUA whether a makes P change its
state or not
• If it does, FC has to send a block message to all the wrappers whose supervised component
cannot move (with respect to P) and an unblock message to all the ones whose supervised
component was blocked, but now can move because of the new state of P
• When FC asked, to some FH, for the permission of performing an action
• FH answer to FC whenever FH is in, or will reach, a state different from the one for which FH has
been enquired by FC
• otherwise, FH does not answer hence attempting to block FC
Automatic synthesis of distributed FFC: running
example
• for each action, a pointcut is defined in order to intercept the
corresponding method call
For instance, the wrapper for C3 (i.e., for Client1) is an
• for each action,
an advice after() is defined in order to update the
Aspect instrumenting the .class of C3 as follows:
current local state (i.e., state), the property state (i.e., ps), and to
inform all the other wrappers of the updated current local state (i.e.,
Notify())
e.g.,
after() returning (int res) : Connect_action() {
if((state.intValue() == 0) && (res != -1)) state = new Integer(0);
if((ps.read() == 0) && (res != -1)) ps.write(1);
e.g., pointcut
Connect_action() : call(int Server2.Connect(..));
Notify();
}
Automatic synthesis of distributed FFC: running
example
• an advice around() is used to enforce the specified desired behavior, it
is defined for any component action that is a negative action on the
property automaton
• for each action a stored into the last chance states table, an advice
before() is defined in order to eventually unblock possible wrappers
e.g.,
e.g.,
still
waiting for the permission to proceed
and, in turn, ask for the
int around() : FreeP1_action() {
int around() : p1_action() {
permission to proceed on a
e.g.,
if((ps.read() == 0)) { return -1; }
return proceed();
}
if((ps.read() == 0)) { return -1; }
before() : p1_action() {
return proceed();
Notify();
}
AmIAllowed();
}
Bibliography
• [SCP08] M. Tivoli and P. Inverardi, Failure-free
coordinators synthesis for component-based
architectures (2008), in: Science of Computer
Programming, 71:3(181-212)
• [JSS08] M. Autili, L. Mostarda, A. Navarra and M. Tivoli,
Synthesis of decentralized and concurrent adaptors for
correctly assembling distributed component-based
systems (2008), in: Journal of Systems and Software,
81:12(2210-2236)
GSSI PhD in Computer Science
L’Aquila, Italy
Nov 11th, 2013
Component-based design and connector synthesis
(Lecture 1)
Massimo Tivoli
Email: [email protected]
Thank you for your attention!
Any questions?