Supporting System/Component Interoperability During Requirements Engineering & Architecting

1. Supporting System/Component InteroperabilityDuring 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 Thinking of comfort: meal & fewer stops Find me a flight to Seattle 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 mismatchedassumptions 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 towork together[Wiki] • Ability of two or more systems or components toexchange information and to use the information that has been exchanged [IEEE] • Ability of systems, units, or forces to provide services toand accept services from other systems, units or forces and to use the services exchanged to enable them tooperate 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

13. Related Work Research Objective Systematically modeling components and assessing component interoperability Interoperability Assessment (Heuristics) (Interoperable) Component Model SIG Rule-based matching Requirements Architecture Model Finding Non-Functional Object Functional Relationship Syntactic Semantic State Keyword-based matching 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 <<own>> Object State Transition Interaction Goal Agent

21. Component Instance: Traffic Control System Component Goal Safety Turn green <<own>> 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 forStructure 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

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 (IWSSA’06), June 26-29, Las Vegas, 2006

29. Assessing Composite Component InteroperabilityAnalytical 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 (ICCBSS’06), 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 (ICCBSS’06), Orlando, U.S.A., 2006

31. Composite Component Assessment (cont.)An SIG Approach Interoperability Panasonic Base Station: Assessment Functional Non-Functional Structural Behavioral LGE Microwave Oven Model 2: Syntactic Semantic 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 (ICCBSS’06), 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 applianceANDtemperature control AND set temperature ANDsecurity 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.20) Sub-query 2: temperature control AND set temperature (0.25) Sub-query 3: security system controller AND set On 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 stakeholder’s query (0.301) security system controller (0.301) temperature controller (0.180) set On (0.180) get appliance (0.301) HACS controller 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 (ICCBSS’06), 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. 2. SDP: (Sequence of positive interactions) • Central controller changes the traffic light and the pedestrian light to 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”; • Central controller blinks the pedestrian light; • Central controller stops the blinking of the pedestrian light; • Central controller changes the traffic light to yellow; • Central controller changes the traffic light to red. 3. SP: (Positive model) Adapter created following the positive scenarios • 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 RP: (Properties extracted from positive scenarios) It is always true that if the “walk button” is pressed then the pedestrian light eventually becomes “walk”. AG ((WalkButton = Pressed) -> AF (PedestrianLight = Walk)) Case 1.1: Initial States Are Inconsistent(Central Controller,Positive Adapterand Traffic Light Controller: PRP, ¬PRN) Inconsistent Initial States 1. RP:To have a safe intersection, cars and pedestrians shall not encounter at the intersection. Adapter: Inconsistent initial states synchronized Proposed Solution:

38. Verification Result of Case 1.1(Central Controller,Positive Adapterand Traffic Light Controller: PRP, ¬PRN) 1. 3. UPPAAL Properties: 2. UPPAAL Model: 4. Verification Result: √ √ Properties of the Traffic Control System M |= PRP , ¬PRN

39. Case 1.2: Initial States Are Inconsistent(Central Controller,Negative Adapterand 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 Adapterand Traffic Light Controller: PRP, ¬PRN) 1. 3. UPPAAL Properties: 2. UPPAAL Model: 4. Verification Result: √ √ 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 Adapterand Traffic Light Controller: PRP, ¬PRN) 1. 3. UPPAAL Properties: 2. UPPAAL Model: 4. Verification Result: √ 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/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)

46. Plan of Research

47. QUESTIONS