Towards Compositional
Synthesis of Evolving Systems
Shiva Nejati
Mehrdad Sabetzadeh Marsha Chechik
University of Toronto
Sebastian Uchitel
Pamela Zave
U. of Buenos Aires
AT&T Labs
Imperial College London
Nov 13 2008
Motivation: Change Analysis
REQUIREMENTS
ARCHITECTURE
2
Motivation: Change Analysis
Change
REQUIREMENTS
ARCHITECTURE
2
Motivation: Change Analysis
Change
REQUIREMENTS
ARCHITECTURE
2
Motivation: Change Analysis
Change
REQUIREMENTS
ARCHITECTURE
Can we preserve existing architectural
constraints after changing the requirements?
2
Background: Feature-Based Systems
➜ Features
➥ Units of functionality
F1
F2
➜ Feature Interaction
➥ Ways in which features modify one another’s
behaviours
➣ some are desirable, some are not
F1
F2
3
Background: Feature-Based Systems
➜ Features
➥ Units of functionality
F1
F2
➜ Feature Interaction
➥ Ways in which features modify one another’s
behaviours
➣ some are desirable, some are not
F1
F2
3
Background: Feature-Based Systems
➜ Features
➥ Units of functionality
F1
F2
➜ Feature Interaction
➥ Ways in which features modify one another’s
behaviours
➣ some are desirable, some are not
F1
✔
F2
✘
3
Background: Feature-Based Systems
➜ Features
➥ Units of functionality
F1
F2
➜ Feature Interaction
➥ Ways in which features modify one another’s
behaviours
➣ some are desirable, some are not
F1
✔
F2
✘
➜ Avoiding “BAD” Interactions
➥ Putting features in a suitable architecture
➣ typically a linear one, e.g., stack or pipeline
3
Features
Call Blocking (CB)
s1
s0
initial
cb.setup?
checking
cb.reject; /
cb.unavail!
s3
cb.accept; /
cb.setup!
s2
idle
blocked
Call Blocking blocks calling
requests coming from
addresses on a blocked list
Record Voice Mail (RVM)
t0
initial
t1
rvm.setup?/
rvm.setup!
idle
t2
rvm.unavail?
dialogue
Record Voice Mail
records a voice mail
message when the
callee is not available
4
Feature Interaction
Call Blocking (CB)
s1
s0
initial
cb.setup?
checking
cb.reject; /
cb.unavail!
s3
cb.accept; /
cb.setup!
s2
idle
blocked
Record Voice Mail (RVM)
t0
initial
t1
rvm.setup?/
rvm.setup!
idle
t2
rvm.unavail?
dialogue
5
Feature Interaction
Call Blocking (CB)
s1
s0
initial
cb.setup?
checking
cb.reject; /
cb.unavail!
s3
cb.accept; /
cb.setup!
s2
idle
blocked
unavail
Record Voice Mail (RVM)
t0
initial
t1
rvm.setup?/
rvm.setup!
idle
t2
rvm.unavail?
dialogue
5
Feature Interaction
Call Blocking (CB)
s1
s0
initial
cb.setup?
checking
cb.reject; /
cb.unavail!
s3
cb.accept; /
cb.setup!
s2
idle
blocked
unavail
Record Voice Mail (RVM)
t0
initial
t1
rvm.setup?/
rvm.setup!
idle
t2
rvm.unavail?
dialogue
5
Feature Interaction
Call Blocking (CB)
s1
s0
initial
cb.setup?
checking
cb.reject; /
cb.unavail!
s3
cb.accept; /
cb.setup!
s2
idle
blocked
unavail
RVM records a message
Record Voice Mail (RVM) from a blocked caller!
t0
initial
t1
rvm.setup?/
rvm.setup!
idle
t2
rvm.unavail?
dialogue
5
Resolving Interactions
Call Blocking (CB)
Record Voice Mail (RVM)
s1
s0
initial
cb.setup?
checking
cb.reject; /
cb.unavail!
s3
cb.accept; /
cb.setup!
s2
t0
t1
initial
idle
t2
idle
rvm.setup?/
rvm.setup!
rvm.unavail? / dialogue
rvm.voicemail;
rvm.unavail!
blocked
unavail
unavail
Call Blocking (CB)
s1
s0
Record Voice Mail (RVM)
initial
t0
t1
initial
rvm.setup?/
rvm.setup!
CB
idle
t2
rvm.unavail? / dialogue
rvm.voicemail;
rvm.unavail!
RVM
unavail
cb.setup?
checking
cb.reject; /
cb.unavail!
s3
RVM
cb.accept; /
cb.setup!
s2
idle
blocked
CB
unavail
6
Resolving Interactions
Call Blocking (CB)
Record Voice Mail (RVM)
s1
s0
initial
cb.setup?
checking
cb.reject; /
cb.unavail!
s3
cb.accept; /
cb.setup!
s2
✘
t0
t1
initial
idle
rvm.setup?/
rvm.setup!
blocked
initial
rvm.setup?/
rvm.setup!
CB
idle
✔
Call Blocking (CB)
s1
s0
Record Voice Mail (RVM)
t1
rvm.unavail? / dialogue
rvm.voicemail;
rvm.unavail!
unavail
unavail
t0
t2
idle
initial
t2
rvm.unavail? / dialogue
rvm.voicemail;
rvm.unavail!
RVM
unavail
cb.setup?
checking
cb.reject; /
cb.unavail!
s3
RVM
cb.accept; /
cb.setup!
s2
idle
blocked
CB
unavail
6
Problem:
Synthesizing Feature Orderings
➜ Feature sets evolve over time
7
Problem:
Synthesizing Feature Orderings
➜ Feature sets evolve over time
➥ Adding features
F1
F2
7
Problem:
Synthesizing Feature Orderings
➜ Feature sets evolve over time
➥ Adding features
F1
F2 + F3
7
Problem:
Synthesizing Feature Orderings
➜ Feature sets evolve over time
➥ Adding features
F1
F2 + F3
F2
F3
F1
7
Problem:
Synthesizing Feature Orderings
➜ Feature sets evolve over time
➥ Adding features
F1
F2 + F3
F2
F3
F1
7
Problem:
Synthesizing Feature Orderings
➜ Feature sets evolve over time
➥ Adding features
F1
F2 + F3
F2
F3
F1
7
Problem:
Synthesizing Feature Orderings
➜ Feature sets evolve over time
➥ Adding features
F1
F2 + F3
F2
F3
F1
May require reordering
7
Problem:
Synthesizing Feature Orderings
➜ Feature sets evolve over time
➥ Adding features
F1
F2 + F3
➥ Removing features
F1
F2
F2
F3
F1
May require reordering
F3
7
Problem:
Synthesizing Feature Orderings
➜ Feature sets evolve over time
➥ Adding features
F1
F2 + F3
➥ Removing features
F1
F2
F2
F3
F1
May require reordering
F3
7
Problem:
Synthesizing Feature Orderings
➜ Feature sets evolve over time
➥ Adding features
F1
F2 + F3
➥ Removing features
F1
F2
F3
F2
F3
F1
May require reordering
F1
F3
7
Problem:
Synthesizing Feature Orderings
➜ Feature sets evolve over time
➥ Adding features
F1
F2 + F3
➥ Removing features
F1
F2
F3
F2
F3
F1
May require reordering
F1
✘ F3
May not remain stable
7
Problem:
Synthesizing Feature Orderings
➜ Feature sets evolve over time
➥ Adding features
F1
F2 + F3
➥ Removing features
F1
F2
F3
F2
F3
F1
May require reordering
F1
✘ F3
May not remain stable
➥ Changes may invalidate an existing feature arrangement
➥ Need to recompute orderings after each change
7
Problem:
Synthesizing Feature Orderings
➜ Feature sets evolve over time
➥ Adding features
F1
F2 + F3
F2
F3
F1
May require reordering
➥ Removing features
F1
F2
F3
F1
✘ F3
May not remain stable
➥ Changes may invalidate an existing feature arrangement
➥ Need to recompute orderings after each change
Expensive!
7
➜ Goal
Solution Overview
➥ Reusing feature orderings across changes
➜ Reasoning about arbitrary sets of identical processes
➥ via exploiting behavioural equivalences
8
➜ Goal
Solution Overview
➥ Reusing feature orderings across changes
➜ Reasoning about arbitrary sets of identical processes
➥ via exploiting behavioural equivalences
Equivalence too strong for
features with diverse behaviours!
8
➜ Goal
Solution Overview
➥ Reusing feature orderings across changes
➜ Reasoning about arbitrary sets of identical processes
➥ via exploiting behavioural equivalences
Equivalence too strong for
features with diverse behaviours!
➜ Our approach: Use weaker notions of similarity
➥ resulting from the application of design patterns
8
Outline
➜ Feature-Based Systems
➜ Problem: Synthesizing Feature Orderings
➜ Main Result: Use of transparency to enable
efficient feature ordering
➜ Evaluation
➥ Case study
➥ Tool Support
➥ Experience
➜ Limitations & Related Work
➜ Conclusion
9
Transparency Pattern
Transparency: A feature is unobservable except
when providing its service
(P1) Transparency does not affect the behaviour of the
composition
(P2) Features exhibit transparency for certain (but not
necessarily all) input data
Call Blocking (CB)
s1
s0
initial
cb.setup?
checking
cb.reject; /
cb.unavail!
s3
cb.accept; /
cb.setup!
s2
idle
blocked
10
Transparency Pattern
Transparency: A feature is unobservable except
when providing its service
(P1) Transparency does not affect the behaviour of the
composition
(P2) Features exhibit transparency for certain (but not
necessarily all) input data
Call Blocking (CB)
s1
s0
initial
cb.setup?
checking
cb.reject; /
cb.unavail!
s3
blocked
cb.accept; /
cb.setup!
s2
idle
“If a call comes from a
non-blocked caller, then
CB is unobservable”
10
Transparency Pattern
Transparency: A feature is unobservable except
when providing its service
(P1) Transparency does not affect the behaviour of the
composition
(P2) Features exhibit transparency for certain (but not
necessarily all) input data
Call Blocking (CB)
s1
s0
initial
cb.setup?
checking
cb.reject; /
cb.unavail!
s3
blocked
cb.accept; /
cb.setup!
s2
idle
“If a call comes from a
non-blocked caller, then
CB is unobservable”
10
Transparency Pattern
Transparency: A feature is unobservable except
when providing its service
(P1) Transparency does not affect the behaviour of the
composition
(P2) Features exhibit transparency for certain (but not
necessarily all) input data
We exploit transparency to develop an
efficient feature ordering algorithm
Call Blocking (CB)
s1
s0
initial
cb.setup?
checking
cb.reject; /
cb.unavail!
s3
blocked
cb.accept; /
cb.setup!
s2
idle
“If a call comes from a
non-blocked caller, then
CB is unobservable”
10
Use of Transparency
Formalization
(P1) A process T is transparent for a system S if for
every feature F of S
F=
! F || T
(P2) Every feature F of S subsumes T
T! F
11
Use of Transparency
Formalization
(P1) A process T is transparent for a system S if for
every feature F of S
F=
! F || T
(P2) Every feature F of S subsumes T
T! F
Illustration
S1
F1
F2
F3
S2
F1
F3
A Safety property φ
(no bad interaction)
11
Use of Transparency
Formalization
(P1) A process T is transparent for a system S if for
every feature F of S
F=
! F || T
(P2) Every feature F of S subsumes T
T! F
Illustration
S1
F1
S2
F3
F2
F1
T
F1
F3
A Safety property φ
(no bad interaction)
F3
11
Use of Transparency
Formalization
(P1) A process T is transparent for a system S if for
every feature F of S
F=
! F || T
(P2) Every feature F of S subsumes T
T! F
Illustration
F1
F2
by (P2)
⊆
S1
F1
S2
F3
T
F1
F3
A Safety property φ
(no bad interaction)
F3
11
Use of Transparency
Formalization
(P1) A process T is transparent for a system S if for
every feature F of S
F=
! F || T
(P2) Every feature F of S subsumes T
T! F
Illustration
F1
F2
by (P2)
⊆
S1
F1
S2
F3
T
F1
F3
A Safety property φ
(no bad interaction)
=! by (P1)
F3
11
Use of Transparency
Formalization
(P1) A process T is transparent for a system S if for
every feature F of S
F=
! F || T
(P2) Every feature F of S subsumes T
T! F
Illustration
F1
F2
by (P2)
⊆
S1
F1
S2
F3
T
F1
F3
=! by (P1)
F3
A Safety property φ
(no bad interaction)
S1 |= φ ⇒ S2 |= φ
S2 !|= φ ⇒ S1 !|= φ
11
Outline
➜ Feature-Based Systems
➜ Problem: Synthesizing Feature Orderings
➜ Main Result: Use of transparency to enable
efficient feature ordering
➜ Evaluation
➥ Case study
➥ Tool Support
➥ Experience
➜ Limitations & Related Work
➜ Conclusion
12
Case Study
➜ Telecom features (from AT&T)
➥ arranged within the Distributed Feature Composition
(DFC) architecture
[Jackson & Zave IEEE TSE’98]
➜ The base system:
P.l.setup?
l
caller
S1
P.r.setup!
S0
P.r.unavail?
P.l.unavail!
S2
r
callee
13
Case Study
➜ Telecom features (from AT&T)
➥ arranged within the Distributed Feature Composition
(DFC) architecture
[Jackson & Zave IEEE TSE’98]
➜ The base system:
setup
setup
P.l.setup?
l
caller
S1
P.r.setup!
S0
P.r.unavail?
P.l.unavail!
S2
r
callee
13
Case Study
➜ Telecom features (from AT&T)
➥ arranged within the Distributed Feature Composition
(DFC) architecture
[Jackson & Zave IEEE TSE’98]
➜ The base system:
setup
setup
P.l.setup?
l
caller
S1
unavail
P.r.setup!
S0
P.r.unavail?
P.l.unavail!
S2
r
unavail
callee
13
Case Study
➜ Telecom features (from AT&T)
➥ arranged within the Distributed Feature Composition
(DFC) architecture
[Jackson & Zave IEEE TSE’98]
➜ The base system:
setup
setup
P.l.setup?
l
S1
caller
P.l.unavail!
P.r.setup!
unavail
P.r.unavail?
S0
S2
r
callee
unavail
➜ Features extend the base system
setup
setup!
setup?
l
unavail!
caller
CB
r
setup?
l
unavail? unavail!
setup!
RVM
r
setup?
l
unavail? unavail!
QT
setup!
r
setup?
l
unavail? unavail!
unavail
setup!
SFM
setup?
r
AC
l
unavail? unavail!
setup!
setup?
l NATO
unavail? unavail!
r
setup!
r
unavail?
callee
13
Transparency in Pipelines
Transparent box (T):
P.l.setup?
S1
P.r.setup!
S0
P.r.unavail?
P.l.unavail!
S2
14
Transparency in Pipelines
Transparent box (T):
P.l.setup?
S1
A pipeline feature (F):
P.r.setup!
S0
P.r.unavail?
P.l.unavail!
S2
F=
! F || T
T! F
14
Transparency in Pipelines
Transparent box (T):
P.l.setup?
S1
A pipeline feature (F):
|| : parallel composition
: trace equivalence
! : stuttering simulation
=
!
P.r.setup!
S0
P.r.unavail?
P.l.unavail!
S2
F=
! F || T
T! F
14
Transparency in Pipelines
Transparent box (T):
P.l.setup?
S1
A pipeline feature (F):
|| : parallel composition
: trace equivalence
! : stuttering simulation
=
!
P.r.setup!
S0
P.r.unavail?
P.l.unavail!
S2
Language(F||T) = Language(F)
T! F
14
Transparency in Pipelines
Transparent box (T):
P.l.setup?
S1
A pipeline feature (F):
|| : parallel composition
: trace equivalence
! : stuttering simulation
=
!
P.r.setup!
S0
P.r.unavail?
P.l.unavail!
S2
Language(F||T) = Language(F)
T !stut F
14
Transparency in Pipelines
Transparent box (T):
P.l.setup?
S1
P.l.unavail!
P.r.setup!
A pipeline feature (F):
|| : parallel composition
: trace equivalence
! : stuttering simulation
=
!
S0
P.r.unavail?
S2
Language(F||T) = Language(F)
T !stut F
s8
An example Feature (CB):
cb.l.setup?
cb.r.setup!
s0 cb.l.setup? s1 cb.accept; s2 cb.r.setup! s3
cb.r.unavail?
cb.l.unavail! s7
cb.r.unavail?
cb.l.unavail!
cb.reject; s4
s6
cb.l.unavail! s
5
cb.l.setup?
cb.r.unavail?
14
Transparency in Pipelines
Transparent box (T):
P.l.setup?
S1
P.l.unavail!
P.r.setup!
A pipeline feature (F):
|| : parallel composition
: trace equivalence
! : stuttering simulation
=
!
S0
P.r.unavail?
S2
Language(F||T) = Language(F)
T !stut F
s8
An example Feature (CB):
cb.l.setup?
cb.r.setup!
s0 cb.l.setup? s1 cb.accept; s2 cb.r.setup! s3
cb.r.unavail?
cb.l.unavail! s7
cb.r.unavail?
cb.l.unavail!
cb.reject; s4
s6
cb.l.unavail! s
5
cb.l.setup?
cb.r.unavail?
14
Our Order Synthesis Algorithm
Features F1 F2
Properties ϕ1 ϕ2
Fn
ϕn
15
Our Order Synthesis Algorithm
Features F1 F2
Properties ϕ1 ϕ2
Fn
ϕn
FindPairwiseConstraints:
ModelCheck(Fi < Fj , ϕk )
Error!
15
Our Order Synthesis Algorithm
Features F1 F2
Properties ϕ1 ϕ2
Fn
ϕn
FindPairwiseConstraints:
ModelCheck(Fi < Fj , ϕk )
Features F1 F2
Properties ϕ1 ϕ2
Constraints F1 < F2
Fn
ϕn
Fn < F2
Error!
15
Our Order Synthesis Algorithm
Features F1 F2
Properties ϕ1 ϕ2
Fn
ϕn
FindPairwiseConstraints:
ModelCheck(Fi < Fj , ϕk )
Error!
Features F1 F2
Properties ϕ1 ϕ2
Constraints F1 < F2
Fn
ϕn
Fn < F2
OrderPipeline:
1: Let P be a permutation of 1 , 2 , . . . , n satisfying the input
Constratins
2: ModelCheck(FP[1] < FP[2] < . . . < FP[n] , ϕk )
15
Our Order Synthesis Algorithm
Features F1 F2
Properties ϕ1 ϕ2
Fn
ϕn
FindPairwiseConstraints:
ModelCheck(Fi < Fj , ϕk )
Error!
Features F1 F2
Properties ϕ1 ϕ2
Constraints F1 < F2
Fn
ϕn
Fn < F2
OrderPipeline:
1: Let P be a permutation of 1 , 2 , . . . , n satisfying the input
Constratins
2: ModelCheck(FP[1] < FP[2] < . . . < FP[n] , ϕk )
A safe feature ordering
15
Our Order Synthesis Algorithm
Features F1 F2
Properties ϕ1 ϕ2
Fn
ϕn
FindPairwiseConstraints:
ModelCheck(Fi < Fj , ϕk )
LTSA
Error!
Features F1 F2
Properties ϕ1 ϕ2
Constraints F1 < F2
Fn
ϕn
Fn < F2
OrderPipeline:
1: Let P be a permutation of 1 , 2 , . . . , n satisfying the input
Constratins
2: ModelCheck(FP[1] < FP[2] < . . . < FP[n] , ϕk )
A safe feature ordering
15
Our Order Synthesis Algorithm
Features F1 F2
Properties ϕ1 ϕ2
Fn
ϕn
FindPairwiseConstraints:
ModelCheck(Fi < Fj , ϕk )
LTSA
Features F1 F2
Properties ϕ1 ϕ2
Constraints F1 < F2
Fn
ϕn
Fn < F2
ConstraintOrderPipeline:
Solver
Error!
1: Let P be a permutation of 1 , 2 , . . . , n satisfying the input
Constratins
2: ModelCheck(FP[1] < FP[2] < . . . < FP[n] , ϕk )
A safe feature ordering
15
Our Order Synthesis Algorithm
Features F1 F2
Properties ϕ1 ϕ2
Fn
ϕn
FindPairwiseConstraints:
ModelCheck(Fi < Fj , ϕk )
LTSA
Features F1 F2
Properties ϕ1 ϕ2
Fn
ϕn
Constraints F1 < F2
Fn < F2
ConstraintOrderPipeline:
Solver
Error!
1: Let P be a permutation of 1 , 2 , . . . , n satisfying the input
Constratins
2: ModelCheck(FP[1] < FP[2] < . . . < FP[n] , ϕk )
LTSA
A safe feature ordering
15
Experience: Input
➜ A telecom usage made up of six features
➥ All features realize the transparency pattern
➜ Undesirable interactions
➥ Elicited from domain experts, e.g.,
➣ A blocked caller should not be allowed to engage in a
dialogue with the system
➣ The timer interval should never include the time that
the system takes having a dialogue with a user
➣ “Quite Time” feature cannot stop a caller from leaving a
voicemail message
16
Experience: Results
➜ Steps for computing a correct feature ordering
➥ Computing pairwise constraints
➣ Time: 6.47s, Memory: 10M
➥ Finding an ordering that satisfies pairwise constraints
➣ Time & Memory: negligible
➥ Computing and verifying global composition
➣ Time: 16 min, Memory: 1Gig
17
Outline
➜ Feature-Based Systems
➜ Problem: Synthesizing Feature Orderings
➜ Main Result: Use of transparency to enable
efficient feature ordering
➜ Evaluation
➥ Case study
➥ Tool Support
➥ Experience
➜ Limitations & Related Work
➜ Conclusion
18
Limitations
➜ Transparency requirements hold when
➥ Features can be moved into transparency
independently from other features
➣ features are loosely coupled
➜ Implementation details of DFC remain to be
considered
➥ Legacy features
➥ Unbounded channels
➥ Dynamic bindings and dynamic usages
19
Related Work
➜ Feature interaction analysis
➥ Reasoning about and resolving interactions
➣ Assumes a feature arrangement is given a priori
➠ through a precedence ordering [Jackson & Zave TSE’98,
Hay & Atlee FSE’00]
➠ via component interfaces [Hall Computer Networks’00,
Krishnamurthi & Fisler FSE’02]
➥ Verifying DFC
➣ Exploiting symmetry of communication port behaviours
[Dominguez & Day ASE’05]
➥ Computing feature orderings
➣ Categorizing and partitioning features
[Zimmer & Atlee
FIW’05]
20
Related Work (Cnt’d)
➜ Compositional Verification
➥ Model checking parameterized systems
➣ Arbitrarily large set of “bisimilar” components
➠ reasoning about mutual exclusion protocols [Emerson et.
al. POPL’95, CASE’00]
➥ Assume-guarantee style
➣ Fixed set of components
➠ manually constructing env assumptions [Pnueli’85]
➠ using learning techniques to construct env assumptions
[Colbeigh, Giannakopoulou, Pasareanu TACAS’03]
➠ automatically constructing a transparent interface for
each component [Cheung, Kramer TOSEM’96]
21
Conclusions
➜ An algorithm for synthesizing linear feature
arrangements
➥ Transparency pattern is used to achieve scalability
➥ The algorithm is implemented and applied to a set
of telecom features
➜ Future work
➥ Constructing more reliable and stable systems
➣ by finding appropriate abstractions, patterns and
guidelines
➠ some might be general
➠ but most are likely to be domain-specific
22
Thank You!