Supporting system component interoperability during requirements engineering architecting l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 47

Supporting System/Component Interoperability During Requirements Engineering & Architecting PowerPoint PPT Presentation


  • 217 Views
  • Uploaded on
  • Presentation posted in: Industry

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

Download Presentation

Supporting System/Component Interoperability During Requirements Engineering & Architecting

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Supporting system component interoperability during requirements engineering architecting l.jpg

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


Slide2 l.jpg

Outline

1. Motivation

2. Research objective & problem statement

3. Related work

4. Ongoing work

5. Remaining work


Slide3 l.jpg

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


Slide4 l.jpg

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


Slide5 l.jpg

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


Slide6 l.jpg

Desirable Scenario for A Traffic Control System

North-south bound left-turn yields to the crossing pedestrian, because of the red light

OK


Slide7 l.jpg

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


Slide8 l.jpg

Outline

1. Motivation

2. Research objective & problem statement

3. Related work

4. Ongoing work

5. Remaining work


Slide9 l.jpg

Research Objective

Methods for systematically modeling components and assessing component interoperability during requirements engineering and architectural design


Slide10 l.jpg

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


Slide11 l.jpg

Outline

1. Motivation

2. Research objective & problem statement

3. Related work

4. Ongoing work

5. Remaining work


Slide12 l.jpg

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


Slide13 l.jpg

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


Slide14 l.jpg

Related Work On Interoperability


Slide15 l.jpg

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


Slide16 l.jpg

Outline

1. Motivation

2. Research objective & problem statement

3. Related work

4. Ongoing work

5. Remaining work


Slide17 l.jpg

Ongoing Work

  • Component model

  • Interoperability dimensions


Slide18 l.jpg

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


Slide19 l.jpg

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.


Slide20 l.jpg

Proposal For Component Model

Component

<<own>>

Object

State Transition

Interaction

Goal

Agent


Slide21 l.jpg

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


Slide22 l.jpg

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


Slide23 l.jpg

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


Slide24 l.jpg

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


Slide25 l.jpg

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


Slide26 l.jpg

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


Slide27 l.jpg

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


Slide28 l.jpg

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


Assessing composite component interoperability analytical hierarchy process l.jpg

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


Assessing composite components interoperability cont analytical hierarchy process l.jpg

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


Composite component assessment cont an sig approach l.jpg

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


Slide32 l.jpg

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


Slide33 l.jpg

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


Slide34 l.jpg

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


Slide35 l.jpg

Comparison of Alloy & Model Checker

L. Chung , W. Ma and K. Cooper, “Supporting Component interoperability Through Integrated Techniques”, Working Memo


Slide36 l.jpg

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)


Slide37 l.jpg

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:


Slide38 l.jpg

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


Slide39 l.jpg

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))


Slide40 l.jpg

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


Slide41 l.jpg

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


Slide42 l.jpg

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


Slide43 l.jpg

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


Slide44 l.jpg

Outline

1. Motivation

2. Research objective & problem statement

3. Related work

4. Ongoing work

5. Remaining work


Slide45 l.jpg

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)


Slide46 l.jpg

Plan of Research


Slide47 l.jpg

QUESTIONS


  • Login