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 (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

KobrA artifacts

Object Constraint Language

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

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

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)

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

StripsSearchPlanner

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

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

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..*

StateSearchPlanner Komponent Realization

StateSearchPlanner Komponent Realization Beahviour model

StateChart

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.

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

POPPlanner

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

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

Ordering constraints

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

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

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

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*

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

StripsPOPPlanner Komponent RealizationStructural Model

StripsPOPPlanner Komponent RealizationFunctional Model

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

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