Program entanglement feature interaction and the feature language extensions flx
Download
1 / 39

Program entanglement, feature interaction and the Feature Language Extensions (FLX) - PowerPoint PPT Presentation


  • 336 Views
  • Uploaded on

Program entanglement, feature interaction and the Feature Language Extensions (FLX). Francis Leung Computer Science Illinois Institute of Technology. Ideal Software Development. Modular Programming

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Program entanglement, feature interaction and the Feature Language Extensions (FLX)' - Pat_Xavi


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
Program entanglement feature interaction and the feature language extensions flx l.jpg

Program entanglement, feature interaction and the Feature Language Extensions (FLX)

Francis Leung

Computer Science

Illinois Institute of Technology

Taiwan 2009


Ideal software development l.jpg
Ideal Software Development Language Extensions (FLX)

  • Modular Programming

    • Each functionality of an application can be developed as a reusable program module independent of other modules

    • Each new release is an integration of new modules and existing modules

    • Reality: the programs of different functionalities entangles in the same module; new releases are developed by changing existing code.

  • Automated Verification

    • There is a tool that can automatically verify whether an application satisfies assertions about it

    • Today’s software relies on case by case testing.

Taiwan 2009


Why can t we use automated verifier like the hardware designers l.jpg
Why can Language Extensions (FLX)’t we use automated verifier like the hardware designers?

  • Hardware

    • Finite state machine

    • Boolean logic

  • Software

    • State variables may not be bounded (e.g. integer)

    • Must reason on predicate logic whose variables have complex data structures (e.g. Is the linked list empty?)

Taiwan 2009


Flx approach to the verification problem l.jpg
FLX approach to the verification problem Language Extensions (FLX)

  • An executable FLX program is compiled into a finite state machine even if state variables are unbounded.

  • A new first order satisfiability algorithm that does not require iterations of solving a SAT problem.

    W.H. Leung, “On the Verifiability of Programs Written in the Feature Language Extensions,” HASE’07.

Taiwan 2009


Outline l.jpg
Outline Language Extensions (FLX)

  • Introduction

  • The feature interaction problem

  • The foundation constructs of the Feature Language Extensions (FLX)

  • Exception handling and extensibility in FLX

  • Conclusion

Taiwan 2009


Some terminology l.jpg
Some terminology Language Extensions (FLX)

  • A feature is some functionality of an application. It is also called a concern, an aspect etc. in the literature.

    • Congestion control and reliable data transport are two features of TCP

    • Plain old telephone call, call forwarding are two features of a telephony application

  • The programs of two features are entangled if they appear in the same method or function.

  • When a feature is implemented by changing the code of another feature, it implies that their programs are entangled.

Taiwan 2009


What it takes to add features to sw today l.jpg
What It Takes to Add Features to SW Today Language Extensions (FLX)

POTS as An Example

  • The programmer develops Call Waiting by changing the code of POTS

  • Call Forwarding is developed by changing the code of Call Waiting and POTS

  • Retry is developed by changing the code of Call Forwarding, Call Waiting and POTS, and so on

  • The programmer is not just implementing one feature. He must thoroughly understand change the code and test many features

  • Features are not reusable without each other

    • They are “entangled”

Taiwan 2009


Slide8 l.jpg

How does entangled code look like? Language Extensions (FLX)

Taiwan 2009


Outline9 l.jpg
Outline Language Extensions (FLX)

  • Introduction

    • The software verification challenge

    • The program entanglement problem

  • The feature interaction problem

  • The foundation constructs of the Feature Language Extensions (FLX)

  • Exception handling and extensibility in FLX

  • Conclusion

Taiwan 2009


Why are we still writing entangled code l.jpg
Why Are We Still Writing Entangled Code? Language Extensions (FLX)

The programmer is not experienced

The programmer is not well trained

The programmer is not given enough time and resources.

Because they use top-down

No, because they use bottom-up

It is due to object oriented programming

It is because they do not follow a plan (agile programming)

It is due to water fall

“Whoever blames will later be blamed. The times they are a changing” – I. Bob Dylan

The programmers cannot help it!

Taiwan 2009


Entanglement conditions l.jpg
Entanglement Conditions* Language Extensions (FLX)

  • C1: If features interact;

  • C2: Executed by the same sequential process; and

  • C3: Implemented by a programming language that require specification of execution flows

  • The programs of these features will inevitably entangle.

  • If features do not interact, their programs do not have to be entangled.

    *W. H. Leung, “Program entanglement, feature interaction and the Feature Language Extensions,” Computer Networks, Feb., 2007

Taiwan 2009


Terminology l.jpg
Terminology Language Extensions (FLX)

  • Two features interact if their behavior changes when integrated together

  • A feature is implemented by computer programs

  • The behavior of a feature is its execution flow and output for a given input

  • An interaction condition is a condition under which the behavior of the interacting features changes.

    • value of variables, a particular point in the execution path

  • An interaction condition is resolved by specification of the changed behavior

Taiwan 2009


Examples of feature interaction l.jpg
Examples of feature interaction Language Extensions (FLX)

  • Adding call forwarding or do not disturb changes the behave of POTS when the phone is called

  • Adding congestion control changes the behavior of reliable data transport when a duplicated acknowledgement is received

  • Adding exception handling changes the behavior of the application program when the system throws an exception

  • A new release typically will consist of new features that change the behavior of old features

Taiwan 2009


Another example of entangled code l.jpg
Another Example of Entangled Code Language Extensions (FLX)

  • When a function throws a new exception, programs that call the function may have to be changed

  • Programs that transitively (indirectly) call the function may also have to be changed

  • Existing programming languages offer very little help to programmers

  • Many popular programs hang often because exceptions are not handled

Function throws a new exception

Taiwan 2009


What is the solution l.jpg
What is the solution? Language Extensions (FLX)

  • Is it sufficient to put all the blue, green, orange and purple code into separate files (or modules)?

  • To implement purple, you still have to go through and often times change blue, green and orange.

  • Purple cannot be understood by itself.

  • Purple cannot be reused without blue, green, and orange.

Taiwan 2009


Requirements for solving the program entanglement problem l.jpg
Requirements for solving the program entanglement problem Language Extensions (FLX)

  • The programs of interacting features can be developed independent of one another

  • There is a tool to automatically detect feature interaction conditions

  • Features can be integrated without changing the code of other features

  • Features can be reused independent of one another

  • Programmers add features by changing the code of other features

  • They must manually read large amount of code to determine where to make the changes

  • The programs of interacting features are entangled in the same reusable program unit

  • Features cannot be reused without each other

Taiwan 2009


Outline17 l.jpg
Outline Language Extensions (FLX)

  • Introduction

    • The software verification challenge

    • The program entanglement problem

  • The feature interaction problem

    • The entanglement conditions

    • Requirements for the solution

  • The foundation constructs of the Feature Language Extensions (FLX)

  • Exception handling and extensibility in FLX

  • Conclusion

Taiwan 2009


Flx is meant for feature rich components l.jpg
FLX is meant for feature rich components Language Extensions (FLX)

Phone Agent

Router

Digit Analysis

Feature Package

Call Processing

Feature Package

Phone

Taiwan 2009


Flx relaxes c3 and supports non procedural programming l.jpg
FLX relaxes C3 and supports non-procedural programming Language Extensions (FLX)

  • A program unit consists of a condition and a program body

  • When a condition becomes true, the corresponding program body is executed

  • Programmer does not sequence the execution order of the program units

Program Unit 1

Program Unit 2

Program Unit N

Condition 1

Condition 2

..

Condition N

..

Program Body 1

Program Body 2

Program Body N

Taiwan 2009


An example program unit l.jpg
An Example Program Unit Language Extensions (FLX)

Idle

Ringing

Term-request

ReceiveCall {

condition: state.equals (State.IDLE);

event: TerminationRequest e; {

Ringing r = new Ringing (e.FromPhoneID);

rt.sendEvent ( r);

state = State.RINGING;

}

}

Taiwan 2009


Features and feature packages written in flx are reusable l.jpg

Basic Language Extensions (FLX)

Telephony

POTS

residential

package

business

package

call

waiting

3-

way

home

inter-

com

selectiv

call

forward

call

pick-

up

Features and feature packages written in FLX are reusable

  • Features are written based on a model instead of the code of other features

  • Features and feature packages are integrated in a feature package

  • One can integrate different combinations of features and feature packages into different feature packages

Anchor feature

Domain

Taiwan 2009


An example domain statement l.jpg
An Example Domain Statement Language Extensions (FLX)

domain BasicTelephony {

variables:

DTenum State (DIALING, OUTPULSING, BUSY, AUDIBLE, TALKING, RINGING, DISCONNECT, IDLE};

State state = State.IDLE;

events:

TerminationRequest;

Busy;

Ringing;

Answer;

Disconnect;

Onhook;

Offhook;

Digits;

TimeOut;

resources:

Phone fone;

Router rt;

}

Taiwan 2009


An anchor feature l.jpg
An Anchor Feature Language Extensions (FLX)

anchor feature Pots {

domain BasicTelephony;

MakeCall {

condition: state.equals(State.IDLE);

event: Offhook; {

fone.applyDialTone();

state = State.DIALING;

}

}

ReceiveCall { }

RingPhone { }

OutpulseDigits { }

}

Taiwan 2009


An example feature l.jpg
An Example Feature Language Extensions (FLX)

Feature DoNotDisturb {

domain BasicTelephony;

anchor Pots;

SayBusy {

condition: all;

event: TerminationRequest e; {

Busy b = new Busy(e.FromPhoneID);

rt.sendEvent ( b);

}

}

}

Taiwan 2009


An example feature package l.jpg
An Example Feature Package Language Extensions (FLX)

feature package QuietPhone {

domain: BasicTelephony;

features: DoNotDisturb, Pots, CatchAll;

PriorityPrecedence {DoNotDisturb, Pots, CatchAll};

}

The priority precedence list specifies that when an interaction condition becomes true, the program unit belonging to the feature with the highest precedence gets executed.

Taiwan 2009


Feature interaction l.jpg
Feature Interaction Language Extensions (FLX)

  • (2) Call Forwarding

  • ForwardCall {

    • condition: state.equals (State.IDLE);

    • event: Term-request e; {

    • If (forwardNumber != “” &&

    • forwardNumber != e.fromPID) {

    • rt.send (forwardNumber, e);

    • stop;

    • }

    • }

  • Two program units interact if the conjunction of their condition parts is satisfiable.

  • Two features interact if a program unit in one feature interacts with a program unit in the other feature.

  • Do not disturb

  • SayBusy {

    • condition: state.equals(State.IDLE);

    • event: Term-request e; {

    • Busy b = new Busy(e.fromPID):

    • rt.sendEvent (b);

      • }

    • }

Taiwan 2009


Feature interaction resolution using program units l.jpg
Feature interaction resolution using program units Language Extensions (FLX)

feature package SelectiveForwarding {

PriorityPrecedence: { DND, CF, POTS};

…..

selectToForward {

condition: state.equals(State.IDLE);

event: Term-request e; {

if (phoneIDlist.contains(e.FromPhoneID))

DND;

else

CF;

stop;

}

}

Taiwan 2009


Straight precedence l.jpg
Straight Precedence Language Extensions (FLX)

feature Billing {

domain: BasicTelephony;

anchor: POTS;

StartMeter {

condition: state.equals(State.AUDIBLE);

event: Answer e; {

CallRecord=new CallRecord (e.fromPID);

meter.start (1 second);

}

}

}

When an interaction condition becomes true, program units of the features will be executed according to their precedence.

feature package NoFreeCalls {

domain:BasicTelephony;

features: Billing,Pots;

straightPrecedence (Billing, Pots);

}

Taiwan 2009


Multiple precedence lists l.jpg
Multiple precedence lists Language Extensions (FLX)

Multiple precedence lists may lead to order or type contradictions. Contradiction may be resolved by program units.

feature package BilledQuietPhone {

domain: BasicTelephony;

feature: DND, Billing, POTS, CatchAll;

straightPrecedence (Billing, POTS);

priorityPrecedence (Billing, CatchAll);

priorityPrecedence (DND, POTS, CatchAll);

}

Taiwan 2009


It is sufficient to only implement priority and straight precedence lists l.jpg
It is sufficient to only implement priority and straight precedence lists*

All contradiction free precedence list sets can be represented by a matrix like this.

* L. Yang, A. Chaven, K. Ramachandra, W. H. Leung, Resolving feature interaction using precedence lists in the Feature Language Extensions,” ICFI’07.

Taiwan 2009


Outline31 l.jpg
Outline precedence lists*

  • Introduction

    • The software verification challenge

    • The program entanglement problem

  • The feature interaction problem

    • The entanglement conditions

    • Requirements for the solution

  • The foundation constructs of the Feature Language Extensions (FLX)

    • Model: domain statement, anchor feature

    • Features and feature packages

    • Precedence lists

  • Exception handling and extensibility in FLX

  • Conclusion

Taiwan 2009


Reusable fle exception features example 1 l.jpg
Reusable FLE exception features example 1 precedence lists*

exception feature CatchAll {

domain: BasicTelephony;

anchor: Pots;

catch {

condition: all;

event: any; {

System.out.println (“CatchAll: unexpected condition and event”);

this.dump (domain, event);

}

}

Taiwan 2009


Reusable fle exception feature example 2 l.jpg
Reusable FLE exception feature precedence lists*example 2

exception feature DamageControl {

domain: RobustTelephony;

anchor: Pots;

illegalOnhook {

condition: state.NotEquals(State.IDLE);

event: Onhook; {

System.out.println (“Illegal Onhook”);

fone.disable ();

stop ();

}

}

brokenRingCkt {

condition: all;

event: RingCktBrokenException e; {

System.out.println (“Major Alarm: Ring CKT broken:”, e.id);

stop ();

}

}

}

Taiwan 2009


Extending a domain statement l.jpg
Extending a domain statement precedence lists*

domain RobustTelephony extends BasicTelephony {

exceptions:

RingCKTBrokenException;

ConfCKTBrokenException;

// and others

}

Taiwan 2009


Putting them together l.jpg
Putting them together precedence lists*

feature package RobustSCF{

domain: RobustTelephony;

features: SelectiveCallForwarding, DamageControl, CatchAll;

PriorityPrecedence: {DamageControl, SelectiveForwarding, CatchAll};

}

Taiwan 2009


Some properties of exception handling and extensibility in flx l.jpg
Some properties of exception handling and extensibility in FLX

  • Exception handling

    • Normal processing features and exception handling features can be developed independently

    • Exception features confines the scope of exceptions

    • Exceptions handling does not have a different control flow model

    • Supports the complete set of termination models

  • Extensibility

    • A model can evolve without changing existing code

    • Original features can be integrated with features developed with the evolved model

Taiwan 2009


Outline37 l.jpg
Outline FLX

  • Introduction

    • The software verification challenge

    • The program entanglement problem

  • The feature interaction problem

    • The entanglement conditions

    • Requirements for the solution

  • The foundation constructs of the Feature Language Extensions (FLX)

    • Domain statement, anchor feature

    • Features and feature packages

    • Precedence lists

  • Exception handling and extensibility in FLX

    • Reusable exception features

    • FLX models can be evolved without changing code

  • Conclusion

Taiwan 2009


Requirements for solving the program entanglement problem38 l.jpg
Requirements for solving the program entanglement problem FLX

  • The programs of interacting features can be developed independent of one another

  • There is a tool to automatically detect feature interaction conditions

  • Features can be integrated without changing the code of other features

  • Features can be reused independent of one another

  • Programmers add features by changing the code of other features

  • They must manually read large amount of code to determine where to make the changes

  • The programs of interacting features are entangled in the same reusable program unit

  • Features cannot be reused without each other

Taiwan 2009


Conclusions l.jpg
Conclusions FLX

  • FLX is designed to

    • Solve the program entanglement problem

    • Provide support for automatic assertion based verification

  • We have used FLX to develop a telephony application with 40 some features and feature packages, a human behavior simulator

  • We are using it to develop a Skype based call center, an operating system kernel subsystem and a web based computer game

  • Current focus is to make the FLX compiler more robust

  • Preparing to develop a verifier

  • A research version of the FLX compiler, example code, papers, theses are downloadable from www.openflx.org

Taiwan 2009