Supporting SystemComponent Interoperability During Requirements Engineering

1
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
2
Outline
1. Motivation 2. Research objective problem
statement 3. Related work 4. Ongoing work 5.
Remaining work
3
A FedEx Delivery Example - Syntax Mis-match
FedEx accepts only three digit apartment,
therefore truncating the last two digits
2200 Waterview PKWY APT 25103 Richardson, TX 75080
2200 Waterview PKWY APT 251 Richardson, TX 75080
SonyStyle Online Store
Delivery Tag
FedEx Delivery System
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
4
Travel Planning Using Web Service - Different
Expectation
Different Expectation
Thinking of comfort economy
Ask for economy class flight ticket
AA 2345 (No meal, multiple stops)
Thinking of economy price
Find me a flight to Seattle
Thinking of comfort meal fewer stops
Expedia, Travalocity, etc.
Airline Reservation System
Traveler
Traveler is unhappy with the tight schedule, due
to the limited time allowed at transfer
Travel agent, Expedia and Airline are unhappy,
due to their revenue and profit loss
Expedia
Traveler
What is missing? Hidden/different expectations
5
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
6
Desirable Scenario for A Traffic Control System
North-south bound left-turn yields to the
crossing pedestrian, because of the red light
OK
7
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
8
Outline
1. Motivation 2. Research objective problem
statement 3. Related work 4. Ongoing work 5.
Remaining work
9
Research Objective
Methods for systematically modeling components
and assessing component interoperability during
requirements engineering and architectural design
10
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

11
Outline
1. Motivation 2. Research objective problem
statement 3. Related work 4. Ongoing work 5.
Remaining work
12
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
• Ability of systems, units, or forces to provide
  services to and accept services from other
  systems, units 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 ones other devices
  CIMIT

Wide variety of notions about interoperability,
which seems to necessitate modeling of components
13
Related Work
Research Objective
Systematically modeling components and assessing
component interoperability
(Interoperable) Component Model
Interoperability Assessment (Heuristics)
SIG
Rule-based matching
Requirements
Architecture
Model Finding
Non-Functional
Object
Functional
Relationship
Keyword-based matching
State
Syntactic
Semantic
Interaction
Model Checking
Structural
Behavioral
Case-based matching
Intermediaries
Dependency List
Association
AHP
Object
Goal
Agent
State
Interaction
14
Related Work On Interoperability
15
Related Work On Interoperability (cont.)

• Rosenblum Natarajan
• JavaBeans component
• C2 architectural style
• ARABICA composition environment
• Composition based on C2 style rules, events and
  wrapper

• Mouakher Lanoix
• UML 2.0 component with interfaces and state
  transitions
• Adapters to match components
• Verifying component interoperability using B
  formalism

B model of Adapter_1 between Controller and
MultiLights component
An Adapter between Controller and MultiLights
component
Wrapping of OTS components in C2-style
architectures. General model of wrapping for C2
I. Mouakher, A. Lanoix and J. Souquieres,
Component Adaptation Specification and
Validation, Proc. of 11th International Workshop
on Component-Oriented Programming, Nantes,
France, July 3-7, 2006
D.S. Rosenblum and R. Natarajan, Supporting
Architectural Concerns In Component
Interoperability Standards, IEE Proceedings on
Software, Vol. 147, No. 6, pp. 215-223, 2000
16
Outline
1. Motivation 2. Research objective problem
statement 3. Related work 4. Ongoing work 5.
Remaining work
17
Ongoing Work

• Component model
• Interoperability dimensions

18
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

19
Notion of ComponentRequirements Architectural
Level
Component
W
Our work focuses on these levels, by utilizing
keyword-/case-based matching, AHP, model
checking/finding, rule-based matching, etc as
much as possible
R
S
AD
DD
Impl
Most works focus on these levels
Testing
Maint
Legend W World, R Requirements, S
Specification, AD Architecture, DD Detail
Design, Impl Implementation, Maint
Maintenance.
20
Proposal For Component Model
Component

Object
State Transition
Interaction
Goal
Agent
21
Component Instance Traffic Control System
Component
Goal
Safety
Turn green

Turn yellow
Turn red
Central Controller
Apply to walk
State Transition
Agent
Sequence of messages
Object
22
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

23
Dimensions of Interoperability
Structural Communication Context-Aware
Object
Structural Coordination Context-Aware
Structural Context-Aware
Name
Structural Collaboration Context-Aware
Architecture
Interface
Type
Behavioral Communication Context-Aware
Interaction
Non-Functional Context-Aware
Interoperability
Behavioral Coordination Context-Aware
Behavioral Context-Aware

Non-Functional
Behavioral Collaboration Context-Aware
Non-Functional Context-Unaware
Structural Communication Context-Unaware
Requirements
Structural Coordination Context-Unaware
Functional Context-Aware
Structural Context-Unaware
Structural Collaboration Context-Unaware
Functional
Behavioral Communication Context-Unaware
Functional Context-Unaware
Behavioral Context-Unaware
Behavioral Coordination Context-Unaware
Behavioral Collaboration Context-Unaware
24
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

25
Switching between Assessment Schemes
Keyword Matching
Blind, exhaustive search No criteria No human
involvement
Blind, exhaustive search Unstructured model No
weight
Structured model instances Weight Structured
input (e.g., class, interface)
Criteria Human involvement
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 Matching
Analytic Hierarchy Process (AHP)
Structured criteria Structured input (e.g.,
class, interface) Preference not associated with
instance of model, but thru Human involvement
18
26
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

27
Evaluating Structural Interoperability Keyword
Matching Cook Frozen Entree Using Structural
Diagrams
LGE Microwave Oven
Panasonic Base Station
??
?
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 _at_.
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
(IWSSA06), June 26-29, Las Vegas, 2006
28
Evaluating Structural Interoperability
(cont.) Case-Based Matching Group of Functions
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
(IWSSA06), June 26-29, Las Vegas, 2006
29
Assessing Composite Component InteroperabilityAna
lytical Hierarchy Process
Relative priorities of simple components
Prioritized measure for each criterion per
component set
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 (ICCBSS06), Orlando, U.S.A., 2006
30
Assessing Composite Components Interoperability
(cont.) Analytical Hierarchy Process
Determining the priorities for criteria
Prioritized measure of composite components
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 (ICCBSS06), Orlando, U.S.A., 2006
31
Composite Component Assessment (cont.)An SIG
Approach
Interoperability
Panasonic Base Station
Assessment
Functional
Non-Functional
Behavioral
Structural
LGE Microwave Oven Model 2
Semantic
Syntactic
X
M1
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 (ICCBSS06), Orlando, U.S.A., 2006
32
Query Collection and Requirements
ElicitationFind anything that can fulfill all or
some of the query to a certain degree
Refined Query Tree
Initial Query Tree
0.563 Refined Query HACS controller AND time
AND get appliance AND temperature control AND set
temperature AND security system controller AND
set On
Query system control AND appliance OR time AND
add appliance NOT remove appliance AND AC
controller AND set temperature AND security
system AND set alarm AND NOT deactivate alarm
Model of components
Assessment techniques
(0.55) Sub-query 1 HACS controller AND time AND
get appliance
Criteria
(0.25) Sub-query 3 security system controller
AND set On
(0.20) Sub-query 2 temperature control AND set
temperature
Sub-query 1 system control AND appliance OR time
AND add appliance NOT remove appliance
Refinement Process
Sub-query 3 security system AND set alarm AND
(NOT deactivate alarm)
.
Sub-query 2 AC controller AND set temperature
Assessing stakeholders query
(0.301) security system controller
(0.301) temperature controller
(0.180) set On
(0.301) HACS controller
(0.180) get appliance
security system
- deactivate alarm
system control
add appliance
AC controller
Refinement, suggestion and confirmation
Priorities, relationship between individual
components
(0.081) time
(0.180) set temperature
appliance OR time
- remove appliance
set temperature
set alarm
Dashed line stands for requirements change.
Priority as number in the curved parenthesis,
similarity metric is in the rectangular
parenthesis.
appliance
time
Minus sign preceding sub-query stands for 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 (ICCBSS06), Orlando, U.S.A., 2006
33
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

34
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

35
Comparison of Alloy Model Checker
L. Chung , W. Ma and K. Cooper, Supporting
Component interoperability Through Integrated
Techniques, Working Memo
36
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 )

• Case 1.1 (Pos Adapter) Synchronization (Adapter
  moves Traffic Light Controller forward to Red
  On state.)
• Verification result of case 1.1
• Case 1.2 (Neg Adapter) Synchronization
• when the traffic light is yellow/red and the
  walk button is pressed)
• Verification result of case 1.2
• Verification result of case 1.3 With a
  corrected model

(SP PRP, SP PRN)
(SN PRP, SN PRN ? M, SD, R false)
As expected (SP PRP, SP PRN, SN PRP,
SN ? PRN)
37
Case 1.1 Initial States Are Inconsistent(Central
Controller, Positive Adapter and Traffic Light
Controller PRP, PRN)
1. RP To have a safe intersection, cars and
pedestrians shall not encounter at the
intersection.
Inconsistent Initial States
Adapter Inconsistent initial states synchronized
Proposed Solution
38
Verification Result of Case 1.1(Central
Controller, Positive Adapter and Traffic Light
Controller PRP, PRN)
3. UPPAAL Properties
1.
2. UPPAAL Model
4. Verification Result
v
v
Properties of the Traffic Control System
M PRP , PRN
39
Case 1.2 Initial States Are Inconsistent(Central
Controller, Negative Adapter and Traffic Light
Controller PRP, PRN)
1. RN To have a risky intersection, cars and
pedestrians shall encounter at the intersection.
Inconsistent Initial States
Adapter Inconsistent initial states synchronized
2. SDN (Sequence of positive interactions w. neg
traces)

• Central controller changes the traffic light to
  yellow/red
• Pedestrian pressed the walk button, waiting for
  crossing
• Central controller receives the message
• Central controller sends a message to the
  pedestrian light to change it to walk

Adapter created following the negative scenarios
3. SN (Negative model)
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
RN (Properties extracted from negative scenarios)
In the same direction, the traffic light is
red/yellow, the pedestrian light is walk. EF
((TrafficLight Red/Yellow) (PedestrianLight
Walk))
40
Verification Result of Case 1.2(Central
Controller, Negative Adapter and Traffic Light
Controller PRP, PRN)
3. UPPAAL Properties
1.
2. UPPAAL Model
4. Verification Result
v
v
Properties of the Traffic Control System
M PRN
Expected result M PRP , M ? PRN ? M, SD, R
false
41
Verification Result of Case 1.3 Corrected
Model(Central Controller, Negative Adapter and
Traffic Light Controller PRP, PRN)
3. UPPAAL Properties
1.
2. UPPAAL Model
4. Verification Result
v
X
Properties of the Traffic Control System
As expected SP PRP, SP PRN SN PRP,
SN ? PRN
42
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

43
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
44
Outline
1. Motivation 2. Research objective problem
statement 3. Related work 4. Ongoing work 5.
Remaining work
45
Expected Contribution

• Representation of component at requirements/archit
  ecture 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)

46
Plan of Research
47
QUESTIONS