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

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

• Francis Leung
• Computer Science
• Illinois Institute of Technology

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
• Todays software relies on case by case testing.

3
Why cant 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?)

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,
  HASE07.

5
Outline

• Introduction
• The feature interaction problem
• The foundation constructs of the Feature Language
  Extensions (FLX)
• Exception handling and extensibility in FLX
• Conclusion

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.

7
What It Takes to Add Features to SW Today
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

8
How does entangled code look like?
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

10
Why Are We Still Writing Entangled Code?
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!
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

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

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

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

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

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

18
FLX is meant for feature rich components
Phone Agent
Router
Digit Analysis Feature Package
Call Processing Feature Package
Phone
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
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
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

Anchor feature
Domain
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

23
An Anchor Feature
anchor feature Pots domain BasicTelephony Mak
eCall condition state.equals(State.IDLE) e
vent Offhook fone.applyDialTone() state
State.DIALING ReceiveCall
RingPhone OutpulseDigits
24
An Example Feature
Feature DoNotDisturb domain BasicTelephony an
chor Pots SayBusy condition all event
TerminationRequest e Busy b new
Busy(e.FromPhoneID) rt.sendEvent ( b)

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

(2) Call Forwarding ForwardCall
condition state.equals (State.IDLE) event
Term-request e If (forwardNumber !
forwardNumber ! e.fromPID) rt.send
(forwardNumber, e) stop

• Do not disturb
• SayBusy
• condition state.equals(State.IDLE)
• event Term-request e
• Busy b new Busy(e.fromPID)
• rt.sendEvent (b)

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

28
Straight Precedence
feature Billing domain BasicTelephony
anchor POTS StartMeter condition
state.equals(State.AUDIBLE) event Answer e
CallRecordnew CallRecord (e.fromPID)
meter.start (1 second)
feature package NoFreeCalls
domainBasicTelephony features
Billing,Pots straightPrecedence (Billing,
Pots)

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

29
Multiple precedence lists
feature package BilledQuietPhone domain
BasicTelephony feature DND, Billing, POTS,
CatchAll straightPrecedence (Billing,
POTS) priorityPrecedence (Billing,
CatchAll) priorityPrecedence (DND, POTS,
CatchAll)

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

30
It is sufficient to only implement priority and
straight precedence lists
Billing DND POTS CatchAll
Billing Straight precedence Priority precedence
DND Priority precedence Priority precedence
POTS Priority precedence
CatchAll
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, ICFI07.
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

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)

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

34
Extending a domain statement

• domain RobustTelephony extends BasicTelephony
• exceptions
• RingCKTBrokenException
• ConfCKTBrokenException
• // and others

35
Putting them together

• feature package RobustSCF
• domain RobustTelephony
• features SelectiveCallForwarding, DamageControl,
  CatchAll
• PriorityPrecedence DamageControl,
  SelectiveForwarding, CatchAll

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

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

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

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