Program entanglement feature interaction and the Feature Language

Program entanglement, feature interaction and the Feature Language Extensions (FLX) Francis Leung Computer Science Illinois Institute of Technology Taiwan 2009 1

Ideal Software Development ¡ Modular Programming l l l ¡ 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 l l 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 2

Why can’t we use automated verifier like the hardware designers? ¡ Hardware l l ¡ Finite state machine Boolean logic Software l l 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 3

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 4

Outline Introduction ¡ The feature interaction problem ¡ The foundation constructs of the Feature Language Extensions (FLX) ¡ Exception handling and extensibility in FLX ¡ Conclusion ¡ Taiwan 2009 5

Some terminology ¡ A feature is some functionality of an application. It is also called a concern, an aspect etc. in the literature. l l ¡ ¡ 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 6

What It Takes to Add Features to POTS as An Example 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 l Taiwan 2009 They are “entangled” 7

How does entangled code look like? Taiwan 2009 8

Outline ¡ Introduction l l 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 9

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! Taiwan 2009 10

Entanglement Conditions* ¡ ¡ ¡ C 1: If features interact; C 2: Executed by the same sequential process; and C 3: 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 11

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. l ¡ value of variables, a particular point in the execution path An interaction condition is resolved by specification of the changed behavior Taiwan 2009 12

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 13

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 14

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 15

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 ¡ ¡ Taiwan 2009 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 16

Outline ¡ Introduction l l ¡ The feature interaction problem l l ¡ ¡ ¡ The software verification challenge The program entanglement 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 17

FLX is meant for feature rich components Phone Agent Digit Analysis Feature Package Call Processing Feature Package Router Phone Taiwan 2009 18

FLX relaxes C 3 and supports nonprocedural programming ¡ A program unit consists of a condition and a program body Program Unit 1 ¡ ¡ Program Unit 2 Condition 1 Condition 2 Program Body 1 Program Body 2 Program Unit N . . Condition N Program Body N When a condition becomes true, the corresponding program body is executed Programmer does not sequence the execution order of the program units Taiwan 2009 19

An Example Program Unit Idle Ringing Term-request Receive. Call { condition: state. equals (State. IDLE); event: Termination. Request e; { Ringing r = new Ringing (e. From. Phone. ID); rt. send. Event ( r); state = State. RINGING; } } Taiwan 2009 20

Features and feature packages written in FLX are reusable ¡ Basic Telephony Domain call waiting 3 way residential package POTS Anchor feature home intercom ¡ selectiv call forward call pickup business package Taiwan 2009 ¡ 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 21

An Example Domain Statement domain Basic. Telephony { variables: DTenum State (DIALING, OUTPULSING, BUSY, AUDIBLE, TALKING, RINGING, DISCONNECT, IDLE}; State state = State. IDLE; events: Termination. Request; Busy; Ringing; Answer; Disconnect; Onhook; Offhook; Digits; Time. Out; resources: } Phone fone; Router rt; Taiwan 2009 22

An Anchor Feature anchor feature Pots { domain Basic. Telephony; Make. Call { condition: state. equals(State. IDLE); event: Offhook; { fone. apply. Dial. Tone(); state = State. DIALING; } } Receive. Call { } Ring. Phone { } Outpulse. Digits { } } … Taiwan 2009 23

An Example Feature Do. Not. Disturb { domain Basic. Telephony; anchor Pots; } Say. Busy { condition: all; event: Termination. Request e; { Busy b = new Busy(e. From. Phone. ID); rt. send. Event ( b); } } Taiwan 2009 24

An Example Feature Package feature package Quiet. Phone { domain: Basic. Telephony; features: Do. Not. Disturb, Pots, Catch. All; Priority. Precedence {Do. Not. Disturb, Pots, Catch. All}; } 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 25

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 disturb Say. Busy { condition: state. equals(State. IDLE); event: Term-request e; { Busy b = new Busy(e. from. PID): rt. send. Event (b); } } (2) Call Forwarding Forward. Call { condition: state. equals (State. IDLE); event: Term-request e; { If (forward. Number != “” && forward. Number != e. from. PID) { rt. send (forward. Number, e); stop; } } Taiwan 2009 26

Feature interaction resolution using program units feature package Selective. Forwarding { Priority. Precedence: { DND, CF, POTS}; …. . } select. To. Forward { condition: state. equals(State. IDLE); event: Term-request e; { if (phone. IDlist. contains(e. From. Phone. ID)) DND; else CF; stop; } Taiwan 2009 27

Straight Precedence feature Billing { domain: Basic. Telephony; anchor: POTS; Start. Meter { condition: state. equals(State. AUDIBLE); event: Answer e; { } feature package No. Free. Calls { domain: Basic. Telephony; features: Billing, Pots; straight. Precedence (Billing, Pots); } Call. Record=new Call. Record (e. from. PID); meter. start (1 second); } } When an interaction condition becomes true, program units of the features will be executed according to their precedence. Taiwan 2009 28

Multiple precedence lists feature package Billed. Quiet. Phone { domain: Basic. Telephony; feature: DND, Billing, POTS, Catch. All; straight. Precedence (Billing, POTS); priority. Precedence (Billing, Catch. All); priority. Precedence (DND, POTS, Catch. All); } Multiple precedence lists may lead to order or type contradictions. Contradiction may be resolved by program units. Taiwan 2009 29

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

Outline ¡ Introduction l l ¡ The feature interaction problem l l ¡ The entanglement conditions Requirements for the solution The foundation constructs of the Feature Language Extensions (FLX) l ¡ The software verification challenge The program entanglement problem Model: domain statement, anchor feature Features and feature packages Precedence lists Exception handling and extensibility in FLX Conclusion Taiwan 2009 31

Reusable FLE exception features example 1 exception feature Catch. All { domain: Basic. Telephony; anchor: Pots; catch { condition: all; event: any; { System. out. println (“Catch. All: unexpected condition and event”); this. dump (domain, event); } } Taiwan 2009 32

Reusable FLE exception feature example 2 exception feature Damage. Control { domain: Robust. Telephony; anchor: Pots; illegal. Onhook { condition: state. Not. Equals(State. IDLE); event: Onhook; { System. out. println (“Illegal Onhook”); fone. disable (); stop (); } } broken. Ring. Ckt { condition: all; event: Ring. Ckt. Broken. Exception e; { System. out. println (“Major Alarm: Ring CKT broken: ”, e. id); stop (); } } } Taiwan 2009 33

Extending a domain statement domain Robust. Telephony extends Basic. Telephony { exceptions: Ring. CKTBroken. Exception; Conf. CKTBroken. Exception; // and others } Taiwan 2009 34

Putting them together feature package Robust. SCF{ domain: Robust. Telephony; features: Selective. Call. Forwarding, Damage. Control, Catch. All; Priority. Precedence: {Damage. Control, Selective. Forwarding, Catch. All}; } Taiwan 2009 35

Some properties of exception handling and extensibility in FLX ¡ Exception handling l l ¡ 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 l l A model can evolve without changing existing code Original features can be integrated with features developed with the evolved model Taiwan 2009 36

Outline ¡ Introduction l l ¡ The feature interaction problem l l ¡ l l Domain statement, anchor feature Features and feature packages Precedence lists Exception handling and extensibility in FLX l l ¡ The entanglement conditions Requirements for the solution The foundation constructs of the Feature Language Extensions (FLX) l ¡ The software verification challenge The program entanglement problem Reusable exception features FLX models can be evolved without changing code Conclusion Taiwan 2009 37

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 ¡ ¡ Taiwan 2009 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 38

Conclusions ¡ FLX is designed to l l ¡ ¡ ¡ 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 39