1 Luigi Logrippo SITE Feature Interactions as Inconsistencies

Slides:



Advertisements
Similar presentations
Before and During!. You cant just show up at a conference! There are things we need to do to get ready. BEFORE.
Advertisements

Testing Relational Database
Design by Contract.
Improving Argumentative Stance Prewriting and Organizational Strategy.
Agenda Introduction Requirements Architecture Issues Implementation Q/A Kundan Singh and Henning Schulzrinne, Columbia University.
1 Luigi Logrippo SITE Feature Interactions as Inconsistencies
Lab Telemàtica II: VoIP 2008/2009 Anna Sfairopoulou Page 1 Advanced services with SIP.
Distributed Databases Logical next step in geographically dispersed organisations goal is to provide location transparency starting point = a set of decentralised.
PDDL: A Language with a Purpose? Lee McCluskey Department of Computing and Mathematical Sciences, The University of Huddersfield.
SWE Introduction to Software Engineering
Requirements Elicitation Chapter 4. Establishing Requirements Two questions –What is the purpose of the system –What is inside and what is outside the.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
EXPERT SYSTEMS Part I.
Building Knowledge-Driven DSS and Mining Data
SM3121 Software Technology Mark Green School of Creative Media.
1CMSC 345, Version 4/04 Verification and Validation Reference: Software Engineering, Ian Sommerville, 6th edition, Chapter 19.
© Siemens 2006 All Rights Reserved 1 Challenges and Limitations in a Back-End Controlled SmartHome Thesis Work Presentation Niklas Salmela Supervisor:
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Rapid software development to validate requirements l.
An Intelligent Broker Architecture for Context-Aware Systems A PhD. Dissertation Proposal in Computer Science at the University of Maryland Baltimore County.
On Roles of Models in Information Systems (Arne Sølvberg) Gustavo Carvalho 26 de Agosto de 2010.
Katanosh Morovat.   This concept is a formal approach for identifying the rules that encapsulate the structure, constraint, and control of the operation.
Firewalls Paper By: Vandana Bhardwaj. What this paper covers? Why you need a firewall? What is firewall? How does a network firewall interact with OSI.
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
CPSC 871 John D. McGregor Module 1 Session 2 Requirements Elicitation/analysis.
Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 1.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Topics Covered: Software requirement specification(SRS) Software requirement specification(SRS) Authors of SRS Authors of SRS Need of SRS Need of SRS.
1 REQUIREMENT ENGINEERING Chapter 7. 2 REQUIREMENT ENGINEERING Definition Establishing what the customer requires from a software system. OR It helps.
1 Luigi Logrippo Kamel Adi Inconsistency and incompleteness in security policies
Features, Policies and Their Interactions Joanne M. Atlee Department of Computer Science University of Waterloo.
1 Detecting Script-to-Script Interactions in Call Processing Language Masahide Nakamura, Ken-ichi Matsumoto, Grad. School of Information Science, Nara.
Software component evaluation A developer’s perspective Sony Corporation’s presentation for the 6 th International Common Criteria Conference.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa REQUIREMENT SPECIFICATION Today: Requirements Specification.
ETHICAL ISSUES SURROUND ELECTRONIC COMMUNICATIONS Unit 3.
The Changing Nature of Feature Interaction Ken Turner University of Stirling Lydie du Bousquet IMAG Glenn Bruns Bell Labs, Lucent Technologies Luigi Logrippo.
소프트웨어공학 강좌 1 Chap 7. Software Prototyping - Rapid software development to validate requirements -
DEBUGGING. BUG A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected.
S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Feature Description and Feature Interaction Analysis with Use Case Maps and.
UML-1 3. Capturing Requirements and Use Case Model.
UML-1 8. Capturing Requirements and Use Case Model.
Software component evaluation A developer’s perspective Sony Corporation’s presentation for the 6 th International Common Criteria Conference.
CPSC 371 John D. McGregor Session 32 This is it..
Service Creation Model and Framework Focus: control, redirection services Challenges: –Simplicity, user-friendliness –Flexibility –Robustness (e.g., feature.
Stefan Marti Speech Interface Group MIT Media Lab.
Run-Time Conflict Resolution for Personal Features Joanne Atlee Department of Computer Science University of Waterloo University of Waterloo.
Software Prototyping Rapid software development to validate requirements.
RECOGNIZING, ANALYZING, AND CONSTRUCTING ARGUMENTS
CONCLUSION The conclusion of this work is that it is possible to develop a problem-solving method providing evolutionary computational support to general.
6° of Darkness or Using Webs of Trust to Solve the Problem of Global Indexes.
September XACML: Consistency analysis Luigi Logrippo Université du Québec University of Ottawa
1 Access Control Policies: Modeling and Validation Luigi Logrippo & Mahdi Mankai Université du Québec en Outaouais.
Software Requirements Specification Document (SRS)
Yr 7.  Pupils use mathematics as an integral part of classroom activities. They represent their work with objects or pictures and discuss it. They recognise.
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
MICON 2000 F ormal methods for design methodology by Luigi Logrippo with D. Amyot, R. Chan, L. Charfi, N. Gorse, J.Sincennes, R. Plesa,... S CHOOL OF I.
1 Logic issues in policy languages Luigi Logrippo Université du Québec en Outaouais and University of Ottawa Canada.
FIW Panel on New Features Will VOIP Cause the Next Evolution of Features? Debbie Pinard Aphrodite Telecom, a Division of Pika Technologies.
Semantic Web in Context Broker Architecture Presented by Harry Chen, Tim Finin, Anupan Joshi At PerCom ‘04 Summarized by Sungchan Park
Luigi Logrippo SITE Logic and implementation issues in VoIP and security
Electronic Business: Concept and Applications Department of Electrical Engineering Gadjah Mada University.
1 Software Requirements Descriptions and specifications of a system.
Problem Solving Methodology 1
Evolution of UML.
Chapter 5 – Requirements Engineering
Verification and Validation
Validating Access Control Policies with Alloy
Participants and Collaborators
From Laws to Programs: A Logical Design Approach
Feature Interactions as Inconsistencies
Dave Marples Communications Division
Presentation transcript:

1 Luigi Logrippo SITE Feature Interactions as Inconsistencies

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 delegatio n to transfer access rights to lower security personnel FI: Delegation defeats BLP

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

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 1000 hockey pucks Send 800 pucks Send 600 pucks Send 400 pucks Send 400 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 1000 hockey pucks Send 800 pucks Send 600 pucks Send 400 pucks Send 400 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