Get documents about "Slide 1 - University of Texas at Dallas
Document Sample
Supporting System/Component Interoperability
During Requirements Engineering & Architecting
Weimin Ma
Ph.D. Supervisory Committee:
Prof. Lawrence Chung (Advisor)
Prof. Kendra Cooper
Prof. Gopal Gupta
Prof. Jing Dong
Outline
1. Motivation
2. Research objective & problem statement
3. Related work
4. Ongoing work
5. Remaining work
A FedEx Delivery Example
- Syntax Mis-match
FedEx accepts only three digit apartment,
therefore truncating the last two digits
2200 Waterview PKWY APT 25103 2200 Waterview PKWY APT 251
Richardson, TX 75080 Richardson, TX 75080
SonyStyle Online Store FedEx Delivery System Delivery Tag
Customer
Driver has difficulty of
finding the location
Customer is unhappy,
due to no/wrong delivery
Customer
What is wrong? Syntactic format difference
Sony considers apartment complexes; FedEx considers small apartments
Travel Planning Using Web Service
- Different Expectation
Different
Expectation
Ask for economy Thinking of AA 2345
Find me a class flight ticket comfort & (No meal,
Thinking of multiple stops)
Thinking of flight to economy
economy:
comfort: meal Seattle price
& fewer stops
Expedia, Airline Reservation
Traveler Travalocity, etc. System
Traveler is unhappy with the Travel agent, Expedia and
tight schedule, due to the Airline are unhappy, due to
limited time allowed at transfer
Traveler Expedia their revenue and profit loss
What is missing? Hidden/different expectations
Accident Scenario for A Traffic Control System
North-south bound left-turn does not yield to
the crossing pedestrian
NOT OK
What is the cause? Traffic light and pedestrian signal not coordinated well
Desirable Scenario for A Traffic Control System
North-south bound left-turn yields to the
crossing pedestrian, because of the red light
OK
Is Component Interoperability A Real Issue?
“The most pernicious and subtle
bugs are system bugs arising from
mismatched assumptions made by
the authors of various components.”
Fred Brooks, “The Mythical Man-Month”, Reading, Massachusetts, pp.142, 1975
Outline
1. Motivation
2. Research objective & problem
statement
3. Related work
4. Ongoing work
5. Remaining work
Research Objective
Methods for systematically modeling
components and assessing component
interoperability during requirements engineering
and architectural design
Problem Statement
• Interoperability consideration mostly on low-level code
reuse
• But we additionally need requirements and architectural level consideration
Eg., In FedEx delivery example: structure of address attribute/type
• Interoperability consideration mostly being focused on
functionalities only
• But we additionally need non-functional consideration
Eg., In travel planning: consideration of expectation
• Informal description of components, hence coarse-grained
analysis, at requirements and architectural level
• But we additionally need more precise representation and more rigorous analysis
Eg., In traffic control: state transition for individual controller, sequences of
interactions among controllers
Outline
1. Motivation
2. Research objective & problem statement
3. Related work
4. Ongoing work
5. Remaining work
What is Interoperability?
- Some Definitions
• Ability of diverse systems and organizations to work together [Wiki]
• Ability of two or more systems or components to exchange information and to use the information
that has been exchanged [IEEE]
provide services to and accept services from other systems, units
• Ability of systems, units, or forces to
or forces and to use the services exchanged to enable them to operate effectively together
[Federal Standard 1037C]
• Capability to communicate, execute programs, or transfer data among various functional units
in a manner that requires the user to have little or no knowledge of the unique characteristics of those units
[ISO/IEC 2382-01]
• Ability to take a medical device out of its box and easily make it work with one’s other devices
[CIMIT]
Wide variety of notions about interoperability, which seems to
necessitate modeling of components
Related Work
Systematically modeling components and Research
assessing component interoperability
Objective
(Interoperable) Interoperability
Component Model Assessment (Heuristics)
Requirements Architecture Rule- SIG
based
matching
Non-Functional Object Model
Functional Relationship Finding
Syntactic Semantic State Interaction Keyword
-based Model
Structural Behavioral matching Checking
Intermediaries Dependency Association Case-
List based AHP
Object Goal Agent State Interaction matching
(Interoperable) Component Model Interoperability Assessment
Related Work Requirements Architecture Keyword Case- AHP Rule- Model Model SIG
-based based based Checking Finding Context
Non- Structural Behavioral Object Inter- Association
Functional action
Related Work On Interoperability
(Interoperable) Component Model Interoperability Assessment
Related Work Requirements Architecture Keyword Case- AHP Rule- Model Alloy SIG
-based based based Checking (Model Context
Non- Structural Behavioral Object Inter- Association Finder)
Functional action
[Elvesater & Hahn] √ √
[Bhuta & Boehm] √ √ √
[Atkinson, Bunse & √ √ √ √ √
Grob]
[Becker & √ √
Romanovsky]
[Schaf er & Knapp] √ √ √
[Supakkul, Oladimeji √ √ √
& Chung]
[Grilo & Jardim- √
Goncalves]
[Jung & Kim] √ √
[Barrett & Clarke] √ √ √
[SEI (SOSI)] √ √
[Cubo & Salaun] √ √ √ √
[Firat & Madnick] √ √ √ √
[Vallecillo & √ √
Hernandez]
[Mouakher & Lanoix] √ √ √
[Rosenblum & √ √ √
Natarajan]
[Mohamed & Rube] √ √ √
Related Work On Interoperability (cont.)
[Rosenblum & Natarajan]: [Mouakher & Lanoix]:
• JavaBeans component • UML 2.0 component with interfaces
• C2 architectural style and state transitions
• ARABICA composition environment • Adapters to match components
• Composition based on C2 style rules, • Verifying component interoperability
events and wrapper using B formalism
B model of Adapter_1
between Controller and
An Adapter between Controller and MultiLights component
MultiLights component
Wrapping of OTS components in C2-style
architectures. General model of wrapping for C2
D.S. Rosenblum and R. Natarajan, “Supporting Architectural Concerns In Component I. Mouakher, A. Lanoix and J. Souquieres, “Component Adaptation: Specification and
Interoperability Standards”, IEE Proceedings on Software, Vol. 147, No. 6, pp. 215-223, Validation”, Proc. of 11th International Workshop on Component-Oriented Programming,
2000 Nantes, France, July 3-7, 2006
Outline
1. Motivation
2. Research objective & problem statement
3. Related work
4. Ongoing work
5. Remaining work
Ongoing Work
• Component model
• Interoperability dimensions
Necessity For Modeling Component
In order to assess component interoperability:
• Need to capture notion of component, i.e., structure, behavior,
expectation, agent and etc.
• Little work has been done on this
• We use the approach in the next slide
Notion of Component
Requirements & Architectural Level
Component:
W Our work focuses on these levels,
R S by utilizing keyword-/case-based
matching, AHP, model
checking/finding, rule-based
AD
matching, etc as much as possible
DD
Most works focus on Impl
these levels
Testing
Maint
Legend:
W – World, R – Requirements, S – Specification, AD – Architecture,
DD – Detail Design, Impl – Implementation, Maint – Maintenance.
Proposal For Component Model
Component
<<own>>
Object State Interaction Goal Agent
Transition
Component Instance: Traffic Control System
Component
Goal
Turn green
<<own>> Safety
Turn yellow
Turn red
Apply to walk Central
Controller
Timer
Alternator
State & Agent
Transition Sequence of
messages
Object
Necessity For Interoperability Dimensions
In order to assess component interoperability:
• Need to consider the dimensions of many different of types of
concerns
• Eg.
Communication: sender & message & receiver
Coordination: initiator (sender) & listener & messages in different ordering
Collaboration: initiator (sender) & goal & listener & messages in different ordering
• Existing work not precise enough for interoperability assessment
• We follow the approach in the next slide
Dimensions of Interoperability Structural
Communication
Context-Aware
Object Structural
Structural Coordination
Context-Aware Context-Aware
Name
Structural
Architecture Interface Collaboration
Context-Aware
Type Behavioral
Interaction Non-
Communication
Context-Aware
Interoperability Functional Behavioral
Context- Behavioral Coordination
Non- Aware
Context-Aware Context-Aware …
Behavioral
Functional Non- Collaboration
Context-Aware
Functional
Context- Structural
Communication
Requirements Unaware Context-Unaware
Structural
Functional Structural Coordination
Context- Context-Unaware Context-Unaware
Aware Structural
Collaboration
Context-Unaware
Functional
Behavioral
Communication
Functional Context-Unaware
Context- Behavioral Behavioral
Unaware Context-Unaware Coordination
Context-Unaware
Behavioral
Collaboration
Context-Unaware
Ongoing Work With Extension
• Component model
• Dimensions of interoperability
• Assessing component against interoperability dimension
• Structural interoperability
• Keyword-/Case-based matching scheme with heuristic formula
• Analytical Hierarchy Process
• Behavioral interoperability
• Model checking w.r.t. properties extracted from positive/negative
scenarios
• Model finding using Alloy
Switching between Assessment Schemes
Keyword
Matching
Structured model (& instances)
(Importance) weight associated with instance of model
Structured input (e.g., class, interface)
No human involvement at time of eval
Case-Based Analytic
Matching Structured criteria Hierarchy
Structured input (e.g., class, interface)
Preference not associated with instance of model, but thru Process
Human involvement
(AHP)
18
Contribution to Structural Interoperability
Assessment
• Proposed notion of similarity for structural interoperability (as indicated by
Fred Brooks’ statement “mismatched assumptions”)
• Consideration of relationship (association) among sub-components in
similarity measurement using keyword-based matching
• Integration techniques for component interoperability assessment using
AHP and SIG
Evaluating Structural Interoperability
Keyword Matching “Cook Frozen Entree” Using Structural Diagrams
Panasonic Base Station: LGE Microwave Oven:
??
Assessment formula for Structure Interoperability:
Number of
relationship
For example, between Panasonic BS “cook frozen entrée” and LGE MO “Sensor cook frozen entrée ”, the similarity value is:
0.189 @.
W. Ma, K. Cooper and L. Chung, “Component-Aware System Architecting: A Software Interoperability Perspective”, Proc. of the 6th
International Workshop on System/Software Architecting (IWSSA’06), June 26-29, Las Vegas, 2006
Evaluating Structural Interoperability (cont.)
Case-Based Matching Group of Functions
Structural LGE HomeNet (Model 1) LGE HomeNet (Model 2) Samsung Home Network …
Interoperability (Model 3)
Set cooking time (1) Selecting timer / (0.197) Set timer / (0.197) Setting cooking time / (1.0)
Cook frozen entrée Sensor cook → frozen entrée / (0.262) Sensor cook → frozen entrée Cook / (0.333)
(1)
/ (0.189 @)
Intermittent stop (3) Intermittent stop / (1.0) Intermittent stop / (1.0) Intermittent stop / (1.0)
Weighted 0.692 0.677 0.867
Average
Heuristic formula for similarity between Panasonic BS “Set cooking time”, “Cook
frozen entrée” and “Intermittent stop” and its counterparts in LGE MO Model2:
For example, interoperability metric between Panasonic BS “Set cooking time”,
“Cook frozen entrée” and “Intermittent stop” and counterparts in LGE MO Model2 is:
W. Ma, K. Cooper and L. Chung, “Component-Aware System Architecting: A Software Interoperability Perspective”, Proc. of the 6th
International Workshop on System/Software Architecting (IWSSA’06), June 26-29, Las Vegas, 2006
Assessing Composite Component Interoperability
Analytical Hierarchy Process
Relative priorities of simple components
“System “AC “Security Priorities
Control” Controller” System”
“System Control” 1 3 2 0.55
“AC Controller” 1/2 1 1/2 0.20
“Security System” 2/3 2/3 1 0.25
Prioritized measure for each criterion per component set
Component Set Component Set Component Set
1 2 3
Class Name 0.650 0.500 0.725
Attribute 0.550 0.550 0.000
Operation 0.375 0.200 0.225
Relationship 0.910 0.060 0.030
(0.045) (0.470) (0.485)
Note: similarity measure is in the parenthesis, and distance value is outside parenthesis.
L. Chung , W. Ma and K. Cooper, “Requirements Elicitation Through Model -Driven Evaluation of Software components”, Proc. of the 5th
International Conference on COTS-Based Software Systems (ICCBSS’06), Orlando, U.S.A., 2006
Assessing Composite Components Interoperability (cont.)
Analytical Hierarchy Process
Determining the priorities for criteria
Class Attribute Operation Relationship Priorities
Name
Class Name 1 3 5/4 1 0.301
Attribute 1/4 1 0.45 1/5 0.081
Operation 3/4 1.75 1 0.40 0.180
Relationship 1.5 4 3 1 0.438
Prioritized measure of composite components
Component Set Component Set Component Set
1 2 3
Weighted 0.672 0.563 0.529
overall
assessment
L. Chung , W. Ma and K. Cooper, “Requirements Elicitation Through Model -Driven Evaluation of Software components”, Proc. of the 5th
International Conference on COTS-Based Software Systems (ICCBSS’06), Orlando, U.S.A., 2006
Composite Component Assessment (cont.)
Panasonic Base Station:
An SIG Approach Interoperability
Assessment Functional
Non-
Structural Behavioral Functional
LGE Microwave
Oven Model 2: Syntactic Semantic
M1
X
M2
X X X
M1
M2
M3
Samsung Microwave
Oven Model 3:
L. Chung , W. Ma and K. Cooper, “Requirements Elicitation Through Model -Driven Evaluation of Software components”, Proc. of the 5th
International Conference on COTS-Based Software Systems (ICCBSS’06), Orlando, U.S.A., 2006
Query Collection and Requirements Elicitation
Find anything that can fulfill all or some of the query to a certain degree
Initial Query Tree Refined Query Tree
[0.563]
Query: Refined Query:
system control AND appliance OR HACS controller AND time AND get
time AND add appliance NOT appliance AND temperature control
remove appliance AND AC AND set temperature AND security
components
Assessment
controller AND set temperature
techniques
system controller AND set On
Model of
AND security system AND set alarm
AND NOT deactivate alarm
Criteria
(0.55)
(0.20) (0.25)
Sub-query 1:
Sub-query 2: Sub-query 3:
……….
HACS
temperature security
Sub-query 1: controller
Assessing stakeholder’s query
Sub-query 3: control AND system
system control AND time
Sub-query 2: security system set controller
AND appliance AND get
AC controller AND set alarm temperature AND set On
OR time AND Refinement Process appliance
AND set AND (NOT
add appliance
temperature deactivate
NOT remove
alarm)
appliance
(0.301) (0.301) (0.180)
(0.301) (0.180) temperatu security
HACS get set On
system add security - deactivate re system
AC controller appliance controller
control appliance system alarm controller
controller Ref inement, Priorities,
suggestion relationship (0.081)
(0.180)
and between time
appliance - remove set set set
conf irmation individual temperature
OR time appliance temperature alarm
components
Dashed line stands f or requirements change.
appliance time Priority as number in the curved parenthesis, similarity
metric is in the rectangular parenthesis.
Minus sign preceding sub-query stands f or logic NOT.
L. Chung, W. Ma and K. Cooper, “Requirements Elicitation Through Model -Driven Evaluation of Software components”, Proc. of the 5th
International Conference on COTS-Based Software Systems (ICCBSS’06), Orlando, U.S.A., 2006
Ongoing Work With Extension
• Component model
• Dimensions of interoperability
• Assessing component against interoperability dimension
• Structural interoperability
• Keyword-/Case-based matching scheme with heuristic formula
• Analytical Hierarchy Process
•Behavioral interoperability
• Model checking with properties extracted from
positive/negative scenarios
• Model finding using Alloy
Contribution to Behavioral Interoperability
Assessment
• Component representing requirements level specification
• Safety and liveness derived from positive scenarios with negative
traces
• Verification of positive/negative model from positive/negative scenarios
when using adapters through model checking/finding
• Negative model from negative scenarios ensures the correctness of
positive model
Comparison of Alloy & Model Checker
No. Alloy [Jackson & et. al] Model Checker (SPIN, SCR, SMV etc.)
1 Analyzing state machines with Analyzing several state machines running in
operations over complex states parallel, each with relatively simple state
2 State with data structure (tables, trees, State with primitive data structure
etc)
3 Model finder, i.e., finding model for a Checking a state machine is a model of a
formula formula
4 Declarative specification, allow partial Mostly not declarative: input is program
model to be analyzed; incremental uses assignment to describe transition step
analysis of a model
5 Visual model instance to ensure the Not always visual model instance
correctness of the model
Model Checker (Formal Tropos) Model Analyzer (Alloy)
Requirements Temporal Requirements Automatic Structural First Order Instance of User-Def ined
Framework Specif ication Analysis Verif ication modeling Logic Invariants Properties
Language language Generation Checking
Goal, agent, Consistency,
strategic assertion, Goal, agent,
dependency possibility dependency
L. Chung , W. Ma and K. Cooper, “Supporting Component interoperability Through Integrated Techniques”, Working Memo
Illustration: A Traffic Control System
(Components Are Non-Interoperable Without Adapters)
The central controller and the traffic light controller are
interoperable with pos/neg adapters
Expected: (SP |= PRP, SP |= ¬ PRN, SN |= PRP, SN |≠ PRN):
(Components: Initial states are inconsistent )
1. Case 1.1: (Pos Adapter): Synchronization (Adapter moves Traffic Light Controller
forward to “Red On” state.)
2. Verification result of case 1.1 (S |= P , S |= ¬ PRN)
P RP P
3. Case 1.2: (Neg Adapter): Synchronization &
when the traffic light is yellow/red and the walk button is pressed)
1. Verification result of case 1.2: (SN |= PR , SN |= PR → M, SD, R |= false)
P N
2. Verification result of case 1.3 – With a corrected model
As expected: (SP |= PRP, SP |= ¬ PRN, SN |= PRP, SN |≠ PRN)
Case 1.1: Initial States Are Inconsistent
(Central Controller, Positive Adapter and Traffic Light Controller: PRP, ¬PRN)
Adapter: Inconsistent Initial States 1. RP: To have a safe intersection, cars and pedestrians shall not
encounter at the intersection.
Inconsistent
initial states 2. SDP: (Sequence of positive interactions)
synchronized 1.
2.
Central controller changes the traffic light and the pedestrian light to red;
Pedestrian pressed the “walk button”, waiting for crossing;
3. Central controller receives the message;
4. Central controller sends a message to the pedestrian light to change it to “walk”;
5. Central controller blinks the pedestrian light;
6. Central controller stops the blinking of the pedestrian light;
7. Central controller changes the traffic light to yellow;
8. Central controller changes the traffic light to red.
Central Traffic
Controller Light 3. SP: (Positive model) Adapter created
Initial State Red Green following the
Light Light positive scenarios
Proposed Solution:
• In its red state, adapter commands traffic light controller from green to red;
• Before going back to red state, the adapter commands the traffic light
controller to the green state.
4. P P: (Properties extracted from positive scenarios)
R
It is always true that if the “walk button” is pressed then the
pedestrian light eventually becomes “walk”.
AG ((WalkButton = Pressed) -> AF (PedestrianLight = Walk))
Verification Result of Case 1.1
(Central Controller, Positive Adapter and Traffic Light Controller: PRP, ¬PRN)
1. 3. UPPAAL Properties:
Safety 1. “No false delaying”: A[] not deadlock
2. “The traf f ic light is in yellow and the pedestrian signal is walking can not
happen together”: A[] not (TL_sys.Yellow_On and PS_sys.Walking)
Liveness 3. “When the controller is in red, eventually the pedestrian signal is in “do not
walk””: A[] (Controller_sys.Red_Light_On imply PS_sys.Do_Not_Walk)
4. “When the push button is pressed, eventually the pedestrian signal is in
“walking””: A<> (PB_sys.Press_issued imply PS_sys.Walking)
5. “When the controller is in red, eventually the pedestrian signal is in “do not
walk” and the traf f ic light is in red”: A<> (Controller_sys.Red_Light_On imply
PS_sys.Do_Not_Walk and Controller_sys.Red_Light_On imply TL_sys.Initial)
6. “When the controller is in green, eventually the traf f ic light is in green light”:
A<> (Controller_sys.Green_Light_On imply TL_sys.Light_On)
7. “When the controller is in “walk ready”, eventually the pedestrian signal is in
“walk ready””: A<> (Controller_sys.Walk_Ready imply PS_sys.Walk_Ready)
2. UPPAAL Model: 8. “When the controller is in walking, eventually the pedestrian signal is in
“walking””: A<> (Controller_sys.Walking imply PS_sys.Walking)
9. “When the controller is in “pedestrian signal blinking”, eventually the pedestrian
signal is in blinking”: A<> (Controller_sys.pedestrian_singnal_blinking imply
PS_sys.Blinking)
10. “When the controller is in “no walk”, eventually the pedestrian signal is in “do
not walk””: A<> (Controller_sys.no_walk imply PS_sys.Do_Not_Walk)
11. “When the controller is in “yellow on”, eventually the traf f ic light is in “yellow
on””: A<> (Controller_sys.yellow_on imply TL_sys.Yellow_On)
4. Verification Result:
√ √
Properties of the Traffic Control System
M |= PRP , ¬PRN
Case 1.2: Initial States Are Inconsistent
(Central Controller, Negative Adapter and Traffic Light Controller: PR
P
, ¬PRN)
Inconsistent Initial States 1. RN: To have a risky intersection, cars and pedestrians shall
Adapter: encounter at the intersection.
Inconsistent 2. SDN: (Sequence of positive interactions w. neg traces)
initial states 1. Central controller changes the traffic light to yellow/red;
Pedestrian pressed the “walk button”, waiting for crossing;
synchronized 2.
3. Central controller receives the message;
4. Central controller sends a message to the pedestrian light to change it to “walk”;
5. …
Adapter created
Central Traffic 3. SN: (Negative model) following the
Controller Light negative scenarios
Initial State Red Green
Light Light
Proposed Solution:
• When the adapter in “Yellow on” state and the walk button is pressed, the
adapter goes into the “Walk button recorded” state;
• In red state, the adapter transitions to “walk ready” state when “walk button
recorded” is true.
4. P N: (Properties extracted from negative scenarios)
R
In the same direction, the traffic light is red/yellow, the
pedestrian light is “walk”.
EF ((TrafficLight = Red/Yellow) ˄ (PedestrianLight = Walk))
Verification Result of Case 1.2
(Central Controller, Negative Adapter and Traffic Light Controller: PR
P
, ¬PRN)
1. 3. UPPAAL Properties:
Safety 1. “No false delaying”: A[] not deadlock
2. “The traffic light is in yellow/red and the pedestrian signal is walking
can not happen together”: A[] not (TL_sys.Yellow_On and
PS_sys.Walking)
Liveness 3. “When the controller is in red, eventually the pedestrian signal is in “do not walk””: A[]
(Controller_sys.Red_Light_On imply PS_sys.Do_Not_Walk)
4. “When the push button is pressed, eventually the pedestrian signal is
in “walking””: A<> (PB_sys.Press_issued imply PS_sys.Walking)
5. “When the controller is in red, eventually the pedestrian signal is in “do not walk” and the traffic
light is in red”: A<> (Controller_sys.Red_Light_On imply PS_sys.Do_Not_Walk and
Controller_sys.Red_Light_On imply TL_sys.Initial)
6. “When the controller is in green, eventually the traffic light is in green light”:
A<> (Controller_sys.Green_Light_On imply TL_sys.Light_On)
7. “When the controller is in “walk ready”, eventually the pedestrian signal is in “walk ready””: A<>
(Controller_sys.Walk_Ready imply PS_sys.Walk_Ready)
2. UPPAAL Model: 8. “When the controller is in walking, eventually the pedestrian signal is in “walking””: A<>
(Controller_sys.Walking imply PS_sys.Walking)
9. “When the controller is in “pedestrian signal blinking”, eventually the pedestrian signal is in
blinking”: A<> (Controller_sys.pedestrian_singnal_blinking imply PS_sys.Blinking)
10. “When the controller is in “no walk”, eventually the pedestrian signal is in “do not walk””: A<>
(Controller_sys.no_walk imply PS_sys.Do_Not_Walk)
11. “When the controller is in “yellow on”, eventually the traffic light is in “yellow on””: A<>
(Controller_sys.yellow_on imply TL_sys.Yellow_On)
4. Verification Result:
√ √
Properties of the Traffic Control System
M |= ¬PRN
Expected result: M |= PR , M |≠ ¬PR → M, SD, R |= false
Verification Result of Case 1.3 – Corrected Model
(Central Controller, Negative Adapter and Traffic Light Controller: PR
P
, ¬PRN)
1. 3. UPPAAL Properties:
Safety 1. “No false delaying”: A[] not deadlock
2. “The traffic light is in yellow/red and the pedestrian signal is walking
can not happen together”: A[] not (TL_sys.Yellow_On and
PS_sys.Walking)
Liveness 3. “When the controller is in red, eventually the pedestrian signal is in “do not walk””: A[]
(Controller_sys.Red_Light_On imply PS_sys.Do_Not_Walk)
4. “When the push button is pressed, eventually the pedestrian signal is
in “walking””: A<> (PB_sys.Press_issued imply PS_sys.Walking)
5. “When the controller is in red, eventually the pedestrian signal is in “do not walk” and the traffic
light is in red”: A<> (Controller_sys.Red_Light_On imply PS_sys.Do_Not_Walk and
Controller_sys.Red_Light_On imply TL_sys.Initial)
6. “When the controller is in green, eventually the traffic light is in green light”:
A<> (Controller_sys.Green_Light_On imply TL_sys.Light_On)
7. “When the controller is in “walk ready”, eventually the pedestrian signal is in “walk ready””: A<>
(Controller_sys.Walk_Ready imply PS_sys.Walk_Ready)
2. UPPAAL Model: 8. “When the controller is in walking, eventually the pedestrian signal is in “walking””: A<>
(Controller_sys.Walking imply PS_sys.Walking)
9. “When the controller is in “pedestrian signal blinking”, eventually the pedestrian signal is in
blinking”: A<> (Controller_sys.pedestrian_singnal_blinking imply PS_sys.Blinking)
10. “When the controller is in “no walk”, eventually the pedestrian signal is in “do not walk””: A<>
(Controller_sys.no_walk imply PS_sys.Do_Not_Walk)
11. “When the controller is in “yellow on”, eventually the traffic light is in “yellow on””: A<>
(Controller_sys.yellow_on imply TL_sys.Yellow_On)
4. Verification Result:
√
Properties of the Traffic Control System
X
As expected: SP |= PRP, SP |= ¬ PRN; SN |= PRP, SN |≠ PRN
Contribution of Using Model Finder For
Behavioral Interoperability Assessment
• Finding cases for interoperable/non-interoperable components
• Invariants as liveness/safety property
• Non-/interoperable cases for negative model to ensure the correctness
of the positive model
Finding Cases of Interoperable Components
Using Alloy
Component Model
No Instance Found
An Instance Found
(Manually) Translated Alloy Model
Possible Alloy Execution Result for the Component Model
Outline
1. Motivation
2. Research objective & problem statement
3. Related work
4. Ongoing work
5. Remaining work
Expected Contribution
Representation of component at requirements/architecture
level
(problem statement: interoperability consideration mostly on low-level code reuse)
(problem statement: informal description of components)
(Integrated) Techniques for component interoperability
assessment along many different dimensions of
component interoperability
(problem statement: interoperability consideration mostly being focused on
functionalities only)
Plan of Research
Number Tasks Estimated
Schedule
1 Refinements on component modeling and interoperability dimensions 1 month
2 Model verification using model finders 1 month
3 Integration of goal/anti-goal, model/anti-model, and model verification 1 month
techniques
4 Provision of heuristics for, integration of, assessment techniques 1 month
5 Validation and tool support 2 months
6 Thesis write-up and miscellaneous tasks 1 months
QUESTIONS
