Taiwan 2009 1

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

Francis LeungComputer Science

Illinois Institute of Technology

Taiwan 2009 2

Ideal Software Development

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 3

Why can’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 4

FLX approach to the verification problem

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 5

Outline

Introduction The feature interaction problem The foundation constructs of the

Feature Language Extensions (FLX) Exception handling and extensibility

in FLX Conclusion

Taiwan 2009 6

Some terminology

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 7

What It Takes to Add Features to SW Today

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”

POTS as An Example

Taiwan 2009 8

How does entangled code look like?

Taiwan 2009 9

Outline

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 10

Why Are We Still Writing Entangled Code?The programmer is not experienced

The programmer is not well trainedThe programmer is not given enough time and resources.

Because they use top-down

It is due to object oriented programming

It is due to water fall“Whoever blames will later be blamed. The times they are a changing” – I. Bob Dylan

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

No, because they use bottom-up

The programmers cannot help it!

Taiwan 2009 11

Entanglement Conditions*

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 12

Terminology

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 13

Examples of feature interaction

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 14

Another Example of Entangled Code

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 15

What is the solution?

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 16

Requirements for solving the program entanglement problem

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

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

Taiwan 2009 17

Outline

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 18

FLX is meant for feature rich components

Phone

Digit Analysis

Feature Package

Call Processing

Feature Package

Phone Agent

Router

Taiwan 2009 19

FLX relaxes C3 and supports non-procedural programming

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 20

An Example Program Unit

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 21

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

callwaiting

3-way

homeinter-com

selectivcallforward

callpick-up

BasicTelephony

POTS

residentialpackage

businesspackage

Domain Anchor feature

Taiwan 2009 22

An Example Domain Statement

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 23

An Anchor Feature

anchor feature Pots {domain BasicTelephony;MakeCall {

condition: state.equals(State.IDLE);

event: Offhook; {fone.applyDialTone();state = State.DIALING;

} }

ReceiveCall { }

RingPhone { }

OutpulseDigits { }

…}

Taiwan 2009 24

An Example Feature

Feature DoNotDisturb {domain BasicTelephony;anchor Pots;

SayBusy {condition: all;event: TerminationRequest e; {

Busy b = new Busy(e.FromPhoneID);rt.sendEvent ( b);

}}

}

Taiwan 2009 25

An Example Feature Package

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 26

Feature Interaction 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.

(1) Do not disturbSayBusy {condition: state.equals(State.IDLE);event: Term-request e; {

Busy b = new Busy(e.fromPID):rt.sendEvent (b); }

}

(2) Call Forwarding ForwardCall {

condition: state.equals (State.IDLE);event: Term-request e; {

If (forwardNumber != “” && forwardNumber != e.fromPID) {

rt.send (forwardNumber, e);

stop; }

}

Taiwan 2009 27

Feature interaction resolution using program units

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 28

Straight Precedence

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

feature Billing { domain: BasicTelephony; anchor: POTS;

StartMeter { condition: state.equals(State.AUDIBLE); event: Answer e; {

CallRecord=new CallRecord (e.fromPID); meter.start (1 second); } }}

feature package NoFreeCalls { domain:BasicTelephony; features: Billing,Pots;

straightPrecedence (Billing, Pots);}

Taiwan 2009 29

Multiple precedence lists

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 30

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.

Billing DND POTS CatchAll

Billing Straight precedence

Priority precedence

DND Priority precedence

Priority precedence

POTS Priority precedence

CatchAll

Taiwan 2009 31

Outline

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 32

Reusable FLE exception features example 1

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 33

Reusable FLE exception featureexample 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 34

Extending a domain statement

domain RobustTelephony extends BasicTelephony {exceptions:

RingCKTBrokenException;ConfCKTBrokenException;// and others

}

Taiwan 2009 35

Putting them together

feature package RobustSCF{domain: RobustTelephony;features: SelectiveCallForwarding, DamageControl,

CatchAll;PriorityPrecedence: {DamageControl,

SelectiveForwarding, CatchAll};}

Taiwan 2009 36

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 37

Outline

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 38

Requirements for solving the program entanglement problem

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

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

Taiwan 2009 39

Conclusions

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