Luigi Logrippo

Download Report

Transcript Luigi Logrippo

Feature Interactions
as Inconsistencies
Luigi Logrippo
SITE
[email protected]
1
http://www.site.uottawa.ca/~luigi/
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
2
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:
Do this
Do that
New VoIP and Web based systems
Security
Many others
3
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
4
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
5
FI in communications
A has C in OCS list
FI: CF defeats OCS
3. A gets connected to C .
C
A
2. B forwards to C
1. A calls B
OCS: Originating Call Screening
CF: Call Forward
B
B has CF to C
6
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
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
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
9
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
10
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
11
This idea is explicit in
Within an explicit logic framework:
Felty and Namjoshi, FIW 2000
Various papers of Aiguier and LeGall, e.g. Formal Methods 2006 (LNCS
4085)
More generally talking about ‘conflicts’, ‘broken assumptions’,
etc.
Kolberg, Magill, Wilson, IEEE Comm., 2003
Gorse, Logrippo, Sincennes, originally in Gorse’s Master’s thesis of 2000
and eventually published in SoSym 2006
Metzger et al., FIW 2003 and 2005
Turner, Blair 2006
Etc.
12
Interesting aside on logic
Not all inconsistencies we have identified are straight
logical inconsistencies…
Some are infinite loops
Others may be deadlocks
What is the logic interpretation of an infinite loop or a
deadlock?
What is the computational interpretation of a logical
inconsistency?
Subject of ongoing work on the relationship between lambda
calculus and logic
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 symptom
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 postconditions 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
Use of pre- and post-conditions
Enable(A,B) (positive interaction)
The post-condition of A is implied by the pre-condition of B
Disable(A,B) (negative interaction)
The post-condition of A is not implied by the pre-condition of
B
Conflict of post-conditions: (negative interactions)
The expected postconditions of two actions conflict directly
• Special case: they request the same resources
The expected postconditions of two actions conflict because
of parameters
17
How to choose pre- and post-condition
Communications systems are very complex and every action is
the result of, also produces, very complex conditions
Only few elements can be expressed in pre- and post-conditions
that are meant for analysis
These elements can only be chosen in terms of broad
generalizations
The choice of these elements is of course vital for producing a
useful analysis
In terms of the characteristics of APPEL, we have chosen to
focus on two elements:
Call states
State of the media
18
How to determine conflicts
Similarly, conflicts must be determined in terms
of broad generalizations
E.g. if one action requests a resource of a certain
type, then it might disable another action that
requires the same type of resources
These generalizations can be made more
specific when more information is available
19
Example 1
20
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
21
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
22
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
23