1 / 39

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

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

yachi
Download Presentation

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

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Program entanglement, feature interaction and the Feature Language Extensions (FLX) Francis Leung Computer 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 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

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

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

  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 Agent Router Digit Analysis Feature Package Call Processing Feature Package Phone 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. Basic 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

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

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

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

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

More Related