25
A KobrA and OCL model for backward state-space search planning and partial order- planning with STRIPS Ana Emília ([email protected]) Jairson Vitorino ([email protected]) Setembro, 2004

Ana Emília ([email protected]) Jairson Vitorino ([email protected]) Setembro, 2004

  • Upload
    odell

  • View
    24

  • Download
    0

Embed Size (px)

DESCRIPTION

A KobrA and OCL model for backward state-space search planning and partial order-planning with STRIPS. Ana Emília ([email protected]) Jairson Vitorino ([email protected]) Setembro, 2004. KobrA method overview. Developed at Fraunhofer IESE Integrates: Component based development (CBD) - PowerPoint PPT Presentation

Citation preview

Page 1: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

A KobrA and OCL model for backward state-space search

planning and partial order-planning with STRIPS

Ana Emília ([email protected])Jairson Vitorino ([email protected])

Setembro, 2004

Page 2: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

KobrA method overview

• Developed at Fraunhofer IESE • Integrates:

– Component based development (CBD)

– Model-driven architecture (MDA)– Product-line approach

• Komponents creation applied on a recursive fashion

Page 3: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

KobrA artifacts

Page 4: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

Object Constraint Language

• Part of the UML standard.• Formal Specification Language.

Precise semantics.• (Quite) easy to read syntax.• Why? Because UML is not enough!

Page 5: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

An OCL Example

Natural language description OCL statement

Age Vehicle´s owner must be at least 18 context Vehicleinv: self. Owner. age >= 18

Nobody can have more than 3 vehicles context Personinv: self.fleet–>size <= 3

Everyone´s car is black context Personinv: self.fleet–>forAll(v | v.colour = #black)

Nobody can have more than 3 black vehicles context Personinv: self.fleet–>select(v | v.colour = #black)–>size <= 3

Nobody can have more than 3 black vehicles context Personinv: self.fleet–>iterate(v; acc:Integer=0| if (v.colour=#black)then acc + 1 else acc endif) <=3

A person younger than 18 cannot own a car context Personinv: age<18 implies self.fleet–>forAll(v | not v.oclIsKindOf(Car))

There is one red car context Carinv: Car.allInstances()->exists(c | c.colour=#red)

Page 6: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

The Planning Problem• Coming up with a sequence of actions

that will achieve a goal• STRIPS planning language: comes in

propositional or first-order logic flavor• STRIPS represents states, goals and

actions

Page 7: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

StripsSearchPlanner

Page 8: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

StripsSearchPlanner modelling• Strips_States

– Positive propositional literal conjunction– Positive First-order literals conjunction– Ground– Function-free– Closed-world assumption

• Strips_Goal Strips_States

• Strips_actions– Name– Parameter_List– Precondition

• Positive function free literals conjunction• Literal.Variables Parameter_List.Variables

– Effect• Function freee literals conjunction

Page 9: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

Basic algorithm• Do

1. Find Action A consistent and relevant if not possible return failure

2. Goal.remove(A.effect.positiveLiterals)3. Goal.add(A.precondition.PositiveLiterals)4. If checkIfIsReached (InitialState) return Solution

• While goal not achieved

Page 10: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

StateSearchPlanner Komponent Specification

Goal

StateSearchPlanner

<<Subject>>

StateCurrent: List of Positive Literals

STRUCTURAL MODEL

ActionName: stringParameterList: List of variablesEffect: List of LiteralsPrecondition: List of Positive LiteralsEffectPositiveLiterals()EffectNegativeLiterals()

Plan

0..*

Page 11: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

StateSearchPlanner Komponent Realization

Page 12: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

StateSearchPlanner Komponent Realization Beahviour model

StateChart

Page 13: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

Functional Model OCL statement Explanation

context StateSearchPlanner::predecessor():Actionpre truepos result = self.avaliableActionList->select(a|true) and self.actionList->size = self.actionList@pre->size + 1

O resultado do método predecessor() é uma ação e o tamanho da lista de ações do plano é incrementado de um.

context Action inv actionConsistentConstraint : self . effect . literal -> forAll ( l | not l . isPositive implies not self . owner . goal . current -> includes ( l ) )

context Action inv actionRelevantConstraint : self . effect . literal -> exists ( l | l . isPositive and self . owner . goal . current -> includes ( l ) )

Nenhum literal positive da ação Action pode ocorrer nos literais do objetivo.

A ação na lista de planos precisa ser relevante, isto é, existe pelo menos um literal positivo do efeito que também pertence aos literais do objetivo.

context AvailableAction inv variablePreconditionConstraint : self . precondition . literal -> includes ( parameterList . name ) implies self -> includes ( parameterList . name ) context AvailableAction inv variableEffectConstraint : self . effect . literal -> includes ( parameterList . name ) implies self -> includes ( parameterList . name )

Todas as variáveis dos parâmetros das precondições precisam pertencer a listas de parâmetros da ação.

Todas as variáveis dos parâmetros dos efeitos precisam pertencer a listas de parâmetros da ação.

Page 14: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

Functional ModelOCL statement Explanation

context AvaliableAction ::effectPositiveLiterals() : Listpre truepost result = {1..self.effect.literal->size} -> iterate(x; y:List()=List{} | if (self.effect.literal.isPositive) then y->includes(sef.effect.literal) else y endiff )

context AvaliableAction ::effectNegativeLiterals() : Listpre truepost result = {1..self.effect.literal->size} -> iterate(x; y:List()=List{} | if not (self.effect.literal.isPositive) then y->includes(sef.effect.literal) else y endiif)

O resultado do método effectPositiveLiterals() é a lista de literais positivos dos efeitos.

O resultado do método effectNegativeLiterals() é a lista de literais negativos dos efeitos.

context State inv : self . current -> forAll (L | L.isPositive = true )

Todos os literais do estado state (estado inicial) são positivos

Page 15: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

POPPlanner

Page 16: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

StripsPOPPlanner modelling• Strips_States

– Positive propositional literal conjunction– Positive First-order literals conjunction– Ground– Function-free– Closed-world assumption

• Strips_Goal Strips_States

• Strips_actions– Name– Parameter_List– Precondition

• Positive function free literals conjunction• Literal.Variables Parameter_List.Variables

– Reserved actions: START and FINISH (POP algorithm)– Effect

• Function freee literals conjunction

Page 17: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

Actions set• Empty plan contains {START,FINISH}• START

– No precondition– Effect: all literals composing the initial

state

• FINISH– No effects– Preconditions: literals composing the goal

Page 18: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

Ordering constraints

• A < B – Action A must be executed before action B

– A < B and B < A are not allowed (loops)

Page 19: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

Causal Links

• A B– Effect of action A is precondition p of action B– Cannot be canceled by other actions executed

between A and B execution

• Ex.: RightSock RightShoe

• C conflicts with causal link causal p:– C has effect p– C may happen between A and B according to

ordering restrictions

p

RightSockOn

Page 20: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

StripsPOPPlanner Komponent Specification

STRUCTURAL MODEL

Constraints:Goal.Instance State.InstanceActions.Precondition.variables Action.ParameterList.Variables

Goal

StateCurrent: List of Positive Literals

ActionName: stringParameterList: List of variablesEffect: List of LiteralsPrecondition: List of Positive LiteralsEffectPositiveLiterals()EffectNegativeLiterals()

Ordering

CausalLinks

previous: ActionCurrent : Action

precondition:literal

*

0..1

POPPlanlistOfOrederedActions:Orderingsuccessor()linearization()

CLList*

Page 21: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

StripsPOPPlanner Komponent Specification

STRUCTURAL MODEL

Constraints:Contex Ordering: Invariant For All objects ordering O1 and O2 there cannot be O1.previous=O2.current or O1.current = O2.previous. // this means NO LOOPS

Goal

StateCurrent: List of Positive Literals

ActionName: stringParameterList: List of variablesEffect: List of LiteralsPrecondition: List of Positive LiteralsEffectPositiveLiterals()EffectNegativeLiterals()

Ordering

CausalLinks

previous: ActionCurrent : Action

precondition:literal

*

0..1

CLListCL : List of CausalLinks

*

POPPlanlistOfOrederedActions:Orderingsuccessor()linearization()

1

Page 22: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

StripsPOPPlanner Komponent RealizationStructural Model

Page 23: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

StripsPOPPlanner Komponent RealizationFunctional Model

Page 24: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

Project Analysis

• KobrA: – small problems, only on interaction– Small structural models– Knowledge in embedded in Constraints and methods

• OCL: Using OCL forces a better understanding of the model and better specification

• Drawbacks: – Lack of better examples of OCL– Tool used (Poseidon) do not conform to OCL current

specification– There is no Case tool for KobrA

Page 25: Ana Emília (aemq@cin.ufpe.br) Jairson Vitorino (jv@cin.ufpe.br) Setembro, 2004

Conclusions

• OCL captures some behaviour aspects• OCL does not include side effects• Further investigation is necessary to

use OCL in statechart and other behavioural diagrams

• It may be necessary to extend KobrA to provide bottom-up modeling and better COTS integration