Luigi Logrippo SITE

1. Luigi LogrippoSITE Feature Interactions as Inconsistencies luigi@site.uottawa.ca http://www.site.uottawa.ca/~luigi/

2. Development • Early research on FI was based on the idea that Fis were the result of complex interleavings of features • See Feature Interaction contexts • Later it became understood that, more simply, if features are logically inconsistent then they cannot coexist

3. Main idea • Many software flaws can be discovered by making the logic precise and thoroughly examining it by the use of logic tools • Formal methods • Feature interactions are the result of logic flaws • Inconsistency of specs • Application areas: • New VoIP and Web based systems • Security • Many others Do this Do that

4. Feature Interaction in Automotive • Electronic Stability Program (ESP) and Cruise Control (CC) • ESP: Break if wheels slip on wet road • CC: Increase speed until cruise speed is reached • FI detectable by the fact that the two features have contradicting requirements

5. Protection rings in Bell-LaPadula security model High security personnel can use delegation to transfer access rights to lower security personnel FI: Delegation defeats BLP

6. A has C in OCS list A C B B has CF to C FI in communications FI: CF defeats OCS . 3. A gets connected to C 2. B forwards to C 1. A calls B OCS: Originating Call Screening CF: Call Forward

7. Infinite loops FIs • Companies A, B and C have policies where each of them uses the next in a loop as suppliers of parts in excess of inventory • This can start a chain reaction with potentially disastrous effects! Send 800 pucks Send 1000 hockey pucks Send 400 Send 600 pucks Send 400 pucks FI: subcontracting defeats itself

8. Infinite loops FIs • Companies A, B and C have policies where each of them uses the next in a loop as suppliers of parts in excess of inventory • This can start a chain reaction with potentially disastrous effects! Send 800 pucks Send 1000 hockey pucks Send 400 Send 600 pucks Send 400 pucks FI: subcontracting defeats itself

9. Presence communications features 1 • Alice: call Bob urgently about meeting cancellation • Bob’s policy: send to voice mail all calls that arrive when I am moving faster than 50Km/h • FI: Bob’s policy defeats Alice’s urgent call policy

10. Presence communications features 2 • Alice: call Bob as soon as he arrives in building • Bob: call Alice as soon as she arrives in building • One of the two policies will be defeated by the other

11. FIs as inconsistencies • There is FI when there is inconsistency between: • Two simultaneous actions of one agent • ESP – CC example • Two simultaneous actions of two different agents • ‘Call as soon as gets in the building’ example • An action and the requirements of a user • Actions and systems requirements • Infinite loop example • Inconsistency of actions is

12. This idea is explicit in • Felty and Namjoshi, FIW 2000 • Various papers of Aiguier and LeGall, most notably one appeared in Formal Methods 2006 (LNCS 4085) • Gorse, Logrippo, Sincennes, originally in Master’s thesis of 2000 and eventually published in SoSym 2006 • Turner, Blair 2006

13. How do we know about the conflicts • This can be obvious, in cases where there is a straight contradiction • A and not A • But this is rarely the case • Most papers leave it to the systems designer to state whether two actions or requirements are in contradiction, • E.g. accept call contradicts disconnect

14. Determining more precisely inconsistency of actions • So action inconsistency is usually a suspicion • Based on knowledge of expected systems behavior • Detection is tentative • Detection tool identifies possible conflict scenarios and interaction must be confirmed by human inspection

15. Next step of analysis:Considering pre- & post-conditions • Wu and Schulzrinne have moved forward with this idea • Not entirely new… • Introducing the idea of conflicts between pre- and post-conditions of actions • Whether actions conflict can be determined on the basis of their pre-and post-conditions • This can provide information also on possible FI resolution

16. How to detect • Specifications must be made precise! • Sometimes they are already sufficiently precise, e.g. in a XML-based language • E.g.BPEL • Constraint Logic Programming • Given a set of logic constraints, CPL tools can tell whether • There is a solution, constraints are satisfiable • There is no solution, in fact there is a counterexample

17. How to solve • Solution is a more complex problem, will depend from • User intentions, • Try to identify user goals • May require an interactive system • Solution methods will vary according to the application domain

18. Conclusions • Complex designs require the composition of complex features • With a lot of user control on what will happen in different situation (user policies) • Introduction of these features will require sophisticated methods to control different situations of feature conflicts