Run-Time Conflict Resolution for Personal Features

Run-Time Conflict Resolution for Personal Features

Joanne AtleeDepartment of Computer Science

University of Waterloo

University ofWaterloo

Motivation: Personal Features

• Trend towards giving users more control over their applications– subscriptions to telephone features– options for customizing game characters– pseudo-database interfaces to information systems

• Allow users to customize or create their own feature variations– specified using scripts and policies

Problem: Interactions

Users will create conflicting features

• Example: Policies to redirect calls– Redirect long distance calls to another number– Redirect calls from management to secretary

– What if a manager calls from long distance?

• Example: Call Screening vs. Call Transfer– Which calls are screened?

Problem: Interactions• Users are not application experts

– Currently, systems analysts are responsible for studying how features behaved in combination and for resolving undesired interactions.

• Users will create conflicting features– Need to help users detect and resolve conflicts

• Usability is an issue– Features and feedback must be expressed in terms that the

user can understand

Conflict Resolution• Detect and resolve conflicts at run-time

– corrective action only taken in the event of an actual interaction

– need not over-constrain features to avoid rare interactions

• Resolution Strategies– serialize features– impede a feature's progress– inhibit secondary, non-essential actions– query user

• Predictability is an issue– Resolution strategies must generate sensible resolutions

Topics Feature/Policy Specification Language

Proposed Run-Time Architecture

Off-Line Analyzer Run-Time System

Demonstration of Analyzer

Experiments

Model

Done

Doing

Doing

Policies - independent rules (data) that manipulate (activate, stimulate, and constrain) features

Model

Feature

Feature

Feature

Feature

Authentication

BillingLocation

Management

Data

Shared Resources

Da

taS

oftw

are

SW

/HW

Policies Policies

Shared System State

Features - independent functions (code) that manipulate shared system variables

Users manipulate policies

Subscriptions

Feature/Policy RulesEach feature and policy is modelled as a set of conditional rules that define how the feature/policy reacts to the system state.

on: event (message)if: condition (predicate on facts)then: actions (add or remove facts)assert: constraint (formula on facts)retract: constraint

Example: Notify me when Annie is in her Office if: Where(Annie,AnnieOffice) then: +Message(Jo, “Annie in AnnieOffice”)

guard {actions {

Shared System StateThe rules manipulate the shared system state, which is a database of facts, events, and constraints about user data and feature state.

• Each fact and event is a tuple (an element of a set, relation, or function):

Call_Subscribe(Steve)Call_Subscribe(Marsha)Call_Subscribe(JohnM)

CF_Subscribe(Marsha)VM_Subscribe(Marsha)CS_Subscribe(Steve)

CS_List(Steve,JohnM)

PhoneInRoom(JohnPhone,JohnOffice)PhoneInRoom(MarshaPhone,MarshaOffice)PhoneInRoom(StevePhone,SteveOffice)

Where(John,MarshaOffice)Where(Marsha,MarshaOffice)Where(Steve,SteveOffice)

Rank(Marsha,4)Rank(Steve,4)Rank(JohnM,10)

Call(conn1,Steve,o_newcall)Connection(conn1,Steve)Originator(conn1,Steve)

Tone(Steve,dialtone)

Event(answer,Annie)

FeatureSubscriptions

FeatureState

EventsFeature

Data

Shared System State

The rules manipulate the shared system state, which is a database of facts, events, and constraints about user data and feature state. • Each constraint is a named formula on facts or fact patterns Marsha cannot initiate calls; she can only receive them

NoCall(Marsha): no c | Originator(c, Marsha)

No one on Steve’s screening list may be in Steve’s connection conn1

CSCon(conn1,Steve): all u | not CS_List(Steve,u) or not Connection(conn1,u)

Universal quantification

More Feature Rules

Call ScreeningIf a caller subscribes to call screening, keep screening list entries out of connection

if: Connection(?c,?u) and CS_Subscribe(?u) and: not CSCon(?c,?u) assert: +CSCon(?c,?u)

Call Forward to LocationForward my calls to my current location

if: Call(?c, ?t, allocate, ?o, Marsha)and: Where(Marsha,?p_room) and Owner(?p,?p_room)then: –Call(?c, ?t, allocate, ?o, Marsha)then: Message(Redirect,?c, ?o, Marsha, ?p)

Existential quantification (bound throughout rule)

More Feature RulesBoss in RoomIf a higher ranking person is in room, forward to voice mail calls destined for me

if: Call(?c, ?t, allocate, ?o, Marsha)and: PhoneInRoom(?t, ?t_room)and: Where(Marsha,?t_room) and Where(?p,?t_room) and: Rank(Marsha)<Rank(?p) and Rank(?o)<Rank(?p)then: –Call(?c, ?t, allocate, ?o, Marsha)then: Message(Redirect,?c,?o,Marsha,MarshaVM)

COordinating User-preferences at Run-Time (COURT)

Context

Connections

OrganizationalStructure

LocationPermissions

Devices

Shared ResourcesConstraints&

Policies

Feature

Policies

FeatureFeature

Feature

Facts, Events,Feature interaction manager (FIM) agents implement application/user-specific resolution strategies.

FeatureInteractionManager

COURT ArbitrationPolicies

Feature

Policies

FeatureFeature

Feature

Facts, Events,&

Constraints


1. Features/policies monitor system

Policies

Feature

Policies

FeatureFeature

Feature

Facts, Events,&

Constraints


2. Features/policies declare intentions(changes to facts and constraints)

Policies

Feature

Policies

FeatureFeature

Feature

Facts, Events,&

Constraints


3. FIMs detect interactions and arbitrate resolutions

Policies

Feature

Policies

FeatureFeature

Feature

Facts, Events,&

Constraints


4. Features execute resolutions

COURT Interactions

Features/policies interact when the feature’s/policy’sindividual actions conflict

• feature invocations are inconsistent• new feature invocation violates constraints

• new constraint is violated by currently active features

• constraints are unsatisfiable

COURT Interactions

Features/policies interact when the feature’s/policy’sindividual actions conflict

• feature invocations are inconsistent• new feature invocation violates constraints

• new constraint is violated by currently active features

• constraints are unsatisfiable

These interactions should be detected and resolved

COURT Reasoning with Inconsistencies

Twist - Tolerating an interaction introduces an inconsistency into the system state (database).

• The actions of a higher priority feature may violate a constraints of a lower priority feature (e.g., one cannot screen calls from emergency services)

• A constraint may be unsatisfied when it is introduced(e.g., one can add currently connected parties to a screening list)

This means that the system and features must be able to continue to function when the database is inconsistent.

COURT Reasoning with InconsistenciesThe only interaction classes we try to detect are

• inconsistencies among new predicates +Rel(x,y) -Rel(x,y) +Funct(x,y) -Funct(x,y) +Funct(x,y) -Funct(x,z)

• violations or re-violations of a constraint

Let State be the current system state State’ be the system state after some rule State’ contain constraint i.C(i)

i . ( State C(i) and State’ C(i) )

COURT ResolutionBig Question: Which resolution strategies generally produce predictable behaviours?

• abort a feature/policy (e.g., based on priorities)• abort a rule• abort a rules’ individual actions, constraints• specify exceptional rules, behaviour• serialize conflicting accesses to shared resources• specify resolution policies• negotiate a compromise• tolerate inconsistency• combine the above techniques

Topics Feature/Policy Specification Language

Proposed Run-Time Architecture

Off-Line Analyzer Run-Time System

Demonstration of Analyzer

Experiments

Model

Done

Doing

Doing

COURT Off-Line Analyzer

S h a r e d S y s t e m S t a t eT h e r u l e s m a n i p u l a t e t h e s h a r e d s y s t e m s t a t e ,w h i c h i s a d a t a b a s e o f f a c t s , e v e n t s , a n dc o n s t r a i n t s a b o u t u s e r d a t a a n d f e a t u r e s t a t e .

• E a c h f a c t a n d e v e n t i s a t u p l e ( a n e l e m e n t o f as e t , r e l a t i o n , o r f u n c t i o n ) :

C a l l _ S u b s c r i b e ( S t e v e )C a l l _ S u b s c r i b e ( M a r s h a )C a l l _ S u b s c r i b e ( J o h n M )

C F _ S u b s c r i b e ( M a r s h a )V M _ S u b s c r i b e ( M a r s h a )C S _ S u b s c r i b e ( S t e v e )

C S _ L i s t ( S t e v e , J o h n M )

P h o n e I n R o o m ( J o h n P h o n e , J o h n O f f i c e )P h o n e I n R o o m ( M a r s h a P h o n e , M a r s h a O f f i c e )P h o n e I n R o o m ( S t e v e P h o n e , S t e v e O f f i c e )

W h e r e ( J o h n , M a r s h a O f f i c e )W h e r e ( M a r s h a , M a r s h a O f f i c e )W h e r e ( S t e v e , S t e v e O f f i c e )

R a n k ( M a r s h a , 4 )R a n k ( S t e v e , 4 )R a n k ( J o h n M , 1 0 )

C a l l ( c o n n 1 , S t e v e , o _ n e w c a l l )C o n n e c t i o n ( c o n n 1 , S t e v e )O r i g i n a t o r ( c o n n 1 , S t e v e )

T o n e ( S t e v e , d i a l t o n e )

E v e n t ( a n s w e r , A n n i e )

F e a t u r eS u b s c r i p t i o n s

F e a t u r eS t a t e

E v e n t sF e a t u r e

D a t a

Feature/Policy RulesEach feature and policy is modelled as a set ofconditional rules that define how the feature/policyreacts to the system state.

on: event (message)if: condition (predicate on facts)then: actions (add or remove facts)assert: constraint (formula on facts)retract: constraint

Example: Notify me when Ann is in her Office if: Where(Ann,AnnOffice) then: +Message(Jo, “Ann in AnnOffice”)

guard {actions {

Reachable (conflict-free) State Space

User(Bob)User(Ann)User(Sally)CanCall(Sally)CanReceive(Bob)CanReceive(Ann)LPSB(Bob,VM)

Where(Bob, AnnOffice)Where(Ann, AnnOffice)Rank(Bob,3)Rank(Ann,4)Rank(Sally,3)

Event(newcall, Sally)InEventInEventInEvent ((( newcallnewcallnewcall , Sally), Sally), Sally)InEvent(dailed, Sally,Bob)InEvent(answer Bob)InEvent(disconnect Bob)InEvent(disconnect Sally)



InEvent(newcall, Sally)InEvent(dailed, Sally, Bob)InEvent(answer Bob)InEvent(disconnect Bob)InEvent(disconnect Sally)




Connection(c1, Sally)Originator(c1, Sally)



Event(Event(Event( newcallnewcallnewcall , Sally), Sally), Sally)InEvent(dailed, Sally,Bob)InEvent(answer Bob)InEvent(disconnect Bob)InEvent(disconnect Sally)

World 1 World 3

<duplicate of World 1>

World 4

World 5

...










Event(Event(Event( newcallnewcallnewcall , Sally), Sally), Sally)InEvent(dailed, Sally,Bob)InEvent(answer Bob)InEvent(disconnect Bob)InEvent(disconnect Sally)

World 6 World 7 World 9

...




World 8

World 29




World 28




World 30

...

...




World 42

...

...


World 41

Analyzer

Log of Interactions and ResolutionsEvent: routeselectedWorld: 18 Interaction Occured.

( (lpsf-rule-one 1 sally bob bob) (true))

Conflicting Action: (lpsb-rule-one 1 sally bob bob)

Event: routeselectedWorld: 18 Interaction Occured.

( (lpsf-rule-one 1 sally bob bob) (true))

Conflicting Action: (tcm-rule-four 1 bob sally bob)

We have implemented a reachability analyzer that composes features according to some encapsulated resolution strategy.

Log of Interactions and ResolutionsEvent: routeselectedWorld: 18 Interaction Occured.

( (lpsf-rule-one 1 Steve Marsha Marsha) (true))

Conflicting Action: (lpsb-rule-one 1 Steve Marsha Marsha)

Event: routeselectedWorld: 42 Interaction Occured.

( (lpsf-rule-one 1 Steve Marsha Marsha) (true))

Conflicting Action: (lpsb-rule-one 1 Steve Marsha Marsha)

Reachable (conflict-free) State Space



Event(newcall, Sally)InEvent(newcall, Sally)InEvent(newcall, Sally)InEvent(dailed, Sally,Bob)InEvent(answer Bob)InEvent(disconnect Bob)InEvent(disconnect Sally)










Event(newcall, Sally)Event(newcall, Sally)InEvent(dailed, Sally,Bob)InEvent(answer Bob)InEvent(disconnect Bob)InEvent(disconnect Sally)

World 1 World 3


World 4

World 5

...










Event(newcall, Sally)Event(newcall, Sally)InEvent(dailed, Sally,Bob)InEvent(answer Bob)InEvent(disconnect Bob)InEvent(disconnect Sally)

World 6 World 7 World 9

...




World 8

World 29




World 28




World 30

...

...




World 42

...

...


World 41

DemoBoss in RoomIf a higher ranking person is in room, forward to voice mail calls destined for me

if: Call(?c, ?t, allocate, ?o, Marsha)and: PhoneInRoom(?t, ?t_room)and: Where(Marsha,?t_room) and Where(?p,?t_room) and: Rank(Marsha)<Rank(?p) and Rank(?o)<Rank(?p)then: –Connection(?c, ?t) then: Message(Redirect,?c,?o,Marsha,MarshaVM)

Call Forward to LocationForward my calls to my current location

if: Call(?c, ?t, allocate, ?o, Marsha)and: Where(Marsha,?p_room) and Owner(?p,?p_room)then: –Connection(?c,t) then: Message(Redirect,?c, ?o, Marsha, ?p)

ExperimentsWe are experimenting with different resolution strategies, to identify those that are generally effective, computationally feasible, and produce predictable behaviours.

Features:POTSCall ScreeningsCall Forward (U, B, NA, VM)Call WaitingThree-Way CallingDistinct RingingAutomatic RecallCall Return“Boss in Room”“Call Forward to my Location”“Forward Person/Group to Secretary”“Notify me when Person is in Location”“Notify me when Team Members Gather”

Resolution Strategies:Feature priorityAction priority

Run-Time System

Constraints&

Policies

Feature

Policies

FeatureFeature

Feature

Facts, Events,


Analyzer

detectenabled rules database

detect and resolveinteractions

We’re in the process of distributing the analyzer functionality to run-time agents.

SummaryGoals Rapid, modular, dynamic development of features

Predictable behaviour of feature combinations

Simple, expressive feature modelling language

Static analyzer that reports conflict resolutions

Experiments to evaluate resolution strategies

Run-time system to resolve interactions

Done

Done

Goals

Doing

Doing

Information that modifies system behaviour• data (cf. program)• manipulate features (cf. manipulate variables)• specify long-lived goals and constraints

Features are no longer invoked and stimulated only by input events or call states

• Forward calls to voice mail if boss is in the room• Notify me when Ann is in her office

Policies

Documents

Run-Time Conflict Resolution for Personal Features