From System Specifications to
Component Behavioral Models
Ivo Krka
George Edwards
Yuriy Brun
Nenad Medvidovic
Background
• Early development specifications
• Partial
• System-level
• Scenarios and properties
• Mapping early specifications to more comprehensive
behavioral models is beneficial
Problem Statement
• Early development phases
• Partial Specifications
• System-level
we and
synthesize
•How
E.g., can
scenarios
properties more
comprehensive
behavioral models from early specifications?
• Mapping early specifications to more comprehensive
behavioral models is beneficial
Web Cache Example
Client
Cache
Server
requestCache
requestServer
responseServer
responseCache
requestCache
responseCache
responseCache
pre: cached = true
post: none
requestServer
pre: cached = false
post: none
responseServer
pre: none
post: cached = true
dataUpdate
pre: none
post: cached = false
dataChanged
pre: none
post: cached = false
Current Solutions
• Component-level model synthesis [1]
Client
Cache
Server
responseCache -- pre: cached = true; post: none
requestServer -- pre: cached = false; post: none
requestCache
responseServer -- pre: none; post: cached = true
requestServer
responseServer
dataUpdate -- pre: none; post: cached = false
dataChanged -- pre: none; post: cached = false
responseCache
requestCache
responseCache
Can Client request data twice in a row?
Can Server send data without
Cache’s request?
Synthesize
Etc.
Cache
S1
requestCache
S2
requestServer
S3
responseServer
requestCache
S5
S4
responseCache
Modeling Partial Behavior
• Modal Transition Systems (MTS)
• Required behavior
• Potential behavior
• Marked with “?” sign
MTS M
e1?
e1
S1
e2
S2
S3
e3
e3?
e1?
e2
S4
Current Solutions
• System-level partial behavioral model synthesis [2]
• Shortcomings
• Potential errors – system-level perspective
• Components cannot satisfy the specification
• Overlook discrepancies among specifications
• Scale, analyzability and comprehensibility
Our Approach
NEW IDEA:
Generating Component-Level
Partial-Behavior Models (MTSs)
Component-Level MTS Synthesis
• Inputs
• Sequence
diagrams
• Pre/post
constraints
• Outputs
• Component
MTSs
Component-Level MTS Synthesis
Specs
Componentlevel constraints
generation
Sequence
diagram
annotation
Final MTS
generation
Initial MTS
generation
Phase 1
Sequence
diagram
annotation
Specs
Componentlevel constraints
generation
Final MTS
generation
Initial MTS
generation
• Pre/post constraints
• System-level
• Pre/post constraints
• Each component
responseCache
pre: cached = true
post: none
requestServer
pre: cached = false
post: none
responseServer
pre: none
post: cached = true
dataUpdate
pre: none
post: cached = false
dataChanged
pre: none
post: cached = false
Cache
responseCache
pre: cached = true
post: none
requestServer
pre: cached = false
post: none
responseServer
pre: none
post: cached = true
dataChanged
pre: none
post: cached = false
Phase 2
Sequence
diagram
annotation
Specs
Component-level
constraints
generation
Final MTS
generation
Initial MTS
generation
• Initial MTS
• Component
pre/post constraints
• Only potential
transitions
requestCache?,
requestServer?,
dataChanged?
Cache
S1
requestCache?,
responseCache?,
responseServer?
responseServer?
(F)
S2
(T)
dataChanged?
Phase 3
Sequence
diagram
annotation
Specs
Component-level
constraints
generation
Final MTS
generation
Initial MTS
generation
• Pre/post constraints
• Annotated scenarios
• Scenarios
The data is initially not cached. • Conditions must hold
Cache
Cache
responseCache
pre: cached = true
post: none
F
requestCache
requestServer
F
requestServer
pre: cached = false
post: none
F
responseServer
responseServer
pre: none
post: cached = true
dataChanged
pre: none
post: cached = false
responseCache
T
requestCache
T
responseCache
T
T
Phase 4
Sequence
diagram
annotation
Specs
Final MTS
generation
Component-level
constraints
generation
Initial MTS
generation
• Initial MTS
• Final MTS
The scenario is incorporated into the MTS as
• Strong refinement
requiredSDs
behavior.
• Annotated
requestServer?
dataChanged?
Cache
S1
requestCache?
requestCache
(F)
responseServer?
(F)
responseServer
responseCache?
dataChanged?
S4
S3
requestCache?
dataChanged?
responseServer?
requestServer
S2
(F)
requestServer?
responseCache
S5
(T)
requestCache?
requestCache
(T)
responseServer?
responseServer?
S6
(T)
responseCache
Utilization 1: Discovery of Specification
Discrepancies
• Scenario cannot execute
• Constraint violated
• Component cannot reach desirable state
• Missing events
Client
Cache
Server
requestCache
responseCache
dataUpdate
requestCache
requestServer
responseServer
responseCache
Utilization 2: Requirements Elicitation
• Propose new scenarios
Client
Cache
Server
requestCache
• Infer/propose new properties
requestServer
responseServer
dataUpdate
When the data is not cached and the request is pending, the
request will be pending indataChanged
the next state
requestServer
□((requestPending  ¬ cached )→○(requestPending
))
Utilization 3: OTS Component Selection
1
2
• Multiple candidate
components
• Satisfaction of required
behavior
3
• No proscribed behavior
Selection
1
Utilization 4: As-intended vs. As-implemented
• Comparison
• Introduced proscribed behavior?
• Missing required behavior?
• Architectural drift
e1?
e1
S1
e1
S2
e3
S1
S2
e3?
e3?
e2
e2
e2
e2
S3
S3
Conclusions
• Synthesis algorithm the first step
• Component-level MTSs
• Notable potential contributions
Thank you!
Questions?