using abduction and induction for operational requirements elaboration

Using Abduction and Induction for Operational Requirements Elaboration

Dalal Alrajeh Oliver RayAlessandra Russo Sebastian Uchitel

AIAI 2007Sept. 15th 2007

2

System Development Cycle

Requirements

Design

Testing

Implementation

Requirements

3

Requirements Elaboration

Operationalization Techniques

Goals:BookRequestSatisfiedOperations: checkOut,issueReminder,..Agents:System, borrower,..Objects:

book(found,borrowed,…)

Operation: checkOut Operation: IssueReminderPrecondition: Book Available Trigger condition:has been borrowed for at

least 2wks and there hasn’t been areminder within the last week

4

Drawbacks

Patterns become too complex Restricted to pattern catalog Size of specification becomes too large

(some may be irrelevant) Lacks automated support

5

Approach Overview

Partial System Specification (LTL)

Scenarios (LTL)

Operational Requirements(LTL)

(1)Transform into a logic program(2) Run ILP system

(3) Transform into Requirement

Using Abduction & Induction

6

Mine Pump Controller

7

Linear Temporal Logic A propositional logic for modeling event-

based systems over a linear temporal structure

The language is composed of– Boolean Propositions (P)– Boolean operators(, ,, )– Temporal Operators (, ,, U ,W)

*Propositions divided into two disjoint sets (event propositions and fluent propositions).

Pf={pumpOn, criticalMethane, highWater}

Pe={switchPumpOn, switchPumpOff, signalCriticalMethane, signalNoCriticalMethane, signalHighWater, signalNoHighWater}

8

LTL Model

s0s1 s3s2signalNoHighWater

switchPumpOn switchPumpOff

signalNoHighWater

signalHighWater

Composed of a Labeled Transition System and a valuation function.

labels

Initial state

states

Transition Relation ={(s0,signalHighWater.s1),(s1, switchPumpOn,s2),…}

9

LTL Model -2 The truth value of an event fluent at state si depends

on the ith transition label . The truth value of a fluent proposition depends on

the path and position in a path of a labeled transition system.

LTL formulae are interpreted over paths of a Labeled Transition System LTS

HighWater U signalNotHighWater

s0s1 s3s2signalNoHighWater

switchPumpOn switchPumpOff

signalNoHighWater

signalHighWater

HighWater HighWaterPumpOn

HighWater

10

Partial System Specification-1


Scenarios (LTL)

System Requirements(LTL)


Partial System Specification

Initial state (0in) fi

(0jm) fj

Effect Axioms: (ef )

(e f )

Persistence Axioms: (f f W ET)

(f f W EI)

11

Partial System Specification- 2

Mine Pump Partial System Specification

Initial state: e.g.pumpOn criticalMethane highWater

Effect Axioms: e.g. (switchPumpOn pumpOn ) (switchPumpOff pumpOn )

Persistence Axioms: e.g. (pumpOn pumpOn W switchPumpOn) (pumpOn pumpOn W switchPumpOff)

12

Scenario Properties -1


Scenarios (LTL)



Scenario PropertiesUniversal scenario Property: satisfied by all possible system behavior.

(i<n) i ei n ()en

Existential scenario Property: satisfied by at least one.

(1j<m) j ej m ()em

13

Scenario Properties-2

Mine Pump Scenario PropertiesUniversal scenario Property:

signalCriticalMethane 2 signalHighWater 3switchPumpOn

Existential scenario Property: signalHighWater 2 switchPumpOnswitchPumpOn

14

A Model of the Mine PumpswitchPumpOn

u1=signalCriticalMethane 2 signalHighWater 3switchPumpOn

e1=signalHighWater 2 switchPumpOne2= switchPumpOn

15

Operational Requirements -1


Scenarios (LTL)



Precondition Axioms:

((1jn) ()fj e )

Trigger-Condition Axioms:

((1km) ()fk e)

16

Opertational Requirements -2

Mine Pump Operational Requirements:

Precondition Axioms: (criticalMethane switchPumpOn )

Trigger-Condition Axioms:

((highWater ¬ criticalMethene) switchPumpOn)

17

The Task

Given Partial System Specification Spec and a set of Universal and existential scenario properties SPu and Spe, find a set of pre- and trigger conditions (Pre U Trig) such that:

Spec U (Pre U Trig) |= spu

Spec U (Pre U Trig) |=/= ¬spe

*Pre U Trig are called a correct extension of Spec

18

Approach Overview


Scenarios (LTL)





19

Event Calculus Logic Program Domain dependent axioms

– Initial State: initially(F,S)– Effect Axioms: initiates(E,F,T,S), terminates(E,F,T,S),

– Event Axioms: impossible(E,T,S):-(not) holdsAt(F1,T,S),.. triggered(E,T,S):- (not) holdsAt(F1,T,S),..

Narrative:– attempt(E,T,S).

Domain independent axioms– holdsAt(F,T2,S):- initially(F,S), not clipped(0,F,T2,S)– holdsAt(F,T2,S):- happens(E,T1,S), initiates(E,F,S,T1),T1<T2,

not clipped(T1,F,T2,S).– clipped(T1,F,T2,S):- happens(E,T,S), terminates(E,F,T,S), T1<T , T < T2.– happens(E,T,S):- attempt(E,T,S), not impossible(E,T,S)– happens(E,T,S):- attempt(E,T,S), triggered(E,T,S).– :- triggered(E,T,S) , impossible(E,T,S).

20

Learning Event Calculus Programs

Given • Partial Set of Domain dependant axioms• Domain Independent axioms• Narrative• Event facts

Find • Additional Domain Dependant Axioms

that explain the event facts.

B

E

H

B U H |= E

21

Sound Translation

For any fluent f and position i

, i |= f For any event e and

position i , i |= e

Obtaining program composed of (Spec)

– Nar={attempt(ei,i-1,s)| ei is the ith label in }

Given

– System Specification Spec

– A finite path =e1,e2,…

|= holdsAt(f,i, )

|= happens(e,i-1, )

22

Step 1: Transform Specification into Logic Program -1

LTL Initial State Axioms

Initial state facts

pumpOn criticalMethane highWater

not initially(pumpOn,S). not initially(criticalMethane,S). not initially(highWater,S).

23


LTL Effect Axioms

EC effect Axioms

(switchPumpOn pumpOn ) (switchPumpOff pumpOn )

initiates(switchPumpOn,pumpOn,T,S). terminates(switchPumpOff,pumpOn,T,S).

24


Scenario PropertiessignalCriticalMethane 2 signalHighWater 3switchPumpOn

Narrative

attempt(signalCriticalMethane,0,u1).attempt(signalHighWater ,1,u1).attempt(switchPumpOn,2,u1). Event facts

happens(signalCriticalMethane,0,u1).happens(signalHighWater ,1,u1).

not happens(switchPumpOn,2,u1).

25


Universal Scenario PrportiessignalHighWater switchPumpumpOn

Narrativeattempt(signalHighWater,0,e1).attempt(switchPumpOn,1,e1). Action facts

happens(signalHighWater,0,e1).happens(switchPumpOn,1,e1).

26

Approach Overview


Scenarios (LTL)





27

XHAIL: Extended Hybrid Abductive Inductive Learning Three phases

– Abductive: Produce a set of ground atoms such that B U |= E

– Deductive: Produce a set of ground clauses K ={k = :- b }

– Inductive: Produces a hypothesis H subsumes K

28

Step 2: Using XHAIL modeh(*,impossible(#event, +time,+scenario))

modeh(*,triggered(#event, +time, +scenario))modeb(*,holdsAt(#fluent,+time,+scenario))

modeb(*,not holdsAt(#fluent, +time,+scenario))

%

initiates(switchPumpOn,pumpOn,T,S).

terminates(switchPumpOff,pumpOn,T,S).

%attempt(signalCriticalMethane,0,u1). attempt(signalHighWater,1,u1).attempt(switchPumpOn,2,u1).%happens(signalCriticalMethane,0,u1). happens(signalHighWater,1,u1).not happens(switchPumpOn,2,u1).% initiates

happens(E,T,S) :- attempts (E,T,S) , not impossible (E,T,S)

holdsAt(F,T2,S) :- initiates (E,F,T,S) , happens (E,T,S), not clipped(T1,F,T2,S).

={triggered(switchPumpOn, 1, e2), impossible(switchPumpOn, 2,u1), impossible(tswitchPumpOn, 0,e1)}

K={triggered(switchPumpOn, 1, e2):- holdsAt(highWater,1,e2).not holdsAt(pumpOn,2,e2),

not holdsAt(criticalMethane,2,e2).impossible(switchPumpOn, 2,u1):- holdsAt(highWater,2,u1). not holdsAt(pumpOn,2,u1), holdsAt(criticalMethane,2,u1).impossible(switchPumpOn, 0,e1) :- not holdsAt(highWater,0, e1),

not holdsAt(pumpOn,0,e1),not holdsAt(criticalMethane,0, e1).

H={triggered(switchPumpOn, X, Y):- holdsAt(highWater,X,Y). not holdsAt(criticalMethane,X,Y).impossible(switchPumpOn, X,Y):-holdsAt(criticalMethane,X,Y).impossible(switchPumpOn, X,Y) :- not holdsAt(highWater,X, Y)}

29

Approach Overview


Scenarios (LTL)





30

Step 3: Transform into Requirements

Hypothesis

LTL Operational requirements

triggered(turnPumpOn, X, Y):- holdsAt(highWater,X,Y). not holdsAt(methane,X,Y).

( (highWater criticalMethane) switchPumpOn)

impossible(turnPumpOn, X,Y):-holdsAt(methane,X,Y).

( criticalMethane switchPumpOn)

31

A Correct Extension with respect to an Inductive solution

Obtaining the corresponding:– Partial System Description

– Set of Scenario properties

Find:– A a correct extension with

respect to Spec and SPu U SPe

Given • Partial Set of Domain

dependant axioms• Domain Independent

axioms• Narrative• Event facts

Find • Additional Domain

dependant Axiomsthat explain the event facts

B U H |= E Spec U -1(H) |= spu

Spec U -1(H) |=\= spe

B

E

H

32

Extended Specification Model

SpecSpec U Pre U Trig

switchPumpOn

33

Conclusion

Novel application of Abduction and Induction in the requirements elaboration process.

The need for non-monotonic Learning systems.

The Framework provides a back-end computational approach for the operationalization process.

34

Current and Future Work -1

Including Information about goals and agents in the partial specification

Learning other types of requirements such as post-conditions.

Learning requirements from discrete-time based models (goal driven models).

35

Current and Future Work -2

Handling incomplete scenarios Representing system Goals and assumptions

as Integrity constraints. Integrating ILP and model checking

techniques such that scenarios are generated automatically using model checking tools.

Thorough comparison of results obtained from other non monotonic approaches.

36

Thank You

37

An LTS of the Mine Pump

38

Theorem 2

Given – a partial specification – set of consistent scenario properties – the EC theory (B,E)=Tr(Spec,SPu,SPe) – S be the set of EC event axioms.

Then, – For any inductive generalisation H of E wrt. B and S, the

corresponding set Tr(Pre U Trig)=(H) of LTL pre-condition and trigger-condition axioms is a correct extension of Spec with respect to SPu and SPe.

using abduction and induction for operational requirements elaboration

Documents