CENTRO UNIVERSITRIO DA FEI

MARCELO UDO

INTERPRETAO E EQUIVALNCIA DE MODELOS UML.P E PDDL PARA

PLANEJAMENTO AUTOMTICO

So Bernardo do Campo
2009
 MARCELO UDO

INTERPRETAO E EQUIVALNCIA DE MODELOS UML.P E PDDL PARA

PLANEJAMENTO AUTOMTICO

Dissertao de Mestrado apresentada ao

Centro Universitrio da FEI para obteno do
ttulo de Mestre em Engenharia Eltrica,
orientado pelo Professor Dr. Flavio
Tonidandel.

So Bernardo do Campo
2009
Udo, Marcelo
Interpretao e equivalncia de modelos UML.P e PDDL para
Planejamento Automtico / Marcelo Udo. So Bernardo do Campo,
2009.
83 f. : il.

Dissertao de Mestrado em Engenharia Eltrica Centro

Universitrio da FEI.
Orientador: Prof. Dr. Flavio Tonidandel

1. Planejamento Automtico. 2. Engenharia do Conhecimento.

3. Interpretao. 4. PDDL. 5. UML.P. 6. F-Logic. I. Tonidandel, Fla-
vio, orient. II. Ttulo.

CDU 681.3.02
 MARCELO UDO

INTERPRETAO E EQUIVALNCIA DE MODELOS UML.P E PDDL PARA

PLANEJAMENTO AUTOMTICO

Dissertao de Mestrado
Centro Universitrio da FEI
Departamento de Engenharia Eltrica

Banca Examinadora:

___________________________________________
Prof. Dr. Flavio Tonidandel (Orientador) FEI

_________________________________________________
Prof. Dr. Flvio Soares Corra da Silva USP

_________________________________________________
Prof. Dr. Paulo Eduardo Santos FEI

So Bernardo do Campo
2009
Ao Esprito Universal e a vocs, que bem-
vindas dEle, possam me trazer o sonho
da realidade como a prpria realidade em
sonho e eu possa me sentir completo
como algum que passou e fez diferena
por aqui.
 AGRADECIMENTOS

Agradeo as orientaes, correes e sugestes do meu orientador Professor Dr. Flavio

Tonidandel e foram muitas at a concluso dessa dissertao de Mestrado. Agradeo a

oportunidade de estar participando de um projeto de ferramenta de Engenharia do

Conhecimento para Planejamento Automtico: a Ferramenta itSIMPLE. Agradeo aos

professores do Centro Universitrio FEI no que tange ao respeito e background na rea de IA.

Agradeo aos colegas da USP. Agradeo ao grande camarada Ferreira e por tanto tempo de

amizade sin cera. Agradeo as lembranas boas dos colegas de classe: Cleber, Adriane,

Cssio, Alexandre, Leandro, Lucas e Ferreira. Agradeo minha esposa pelos momentos cujo

dilogo era entre meus dedos e as teclas, meus olhos e a tela. Agradeo aos meus pais, Celso

e Maria, por tUDO. Agradeo Herika, minha irm, por me ajudar com a reviso do texto.

Agradeo ao amigo Alexandre Esteves, irmo de vontade. E para a senhora, minha av,

agradeo por me contar tantas histrias e quando penso na senhora, toda noite vira um palco

onde escuto o mundo solitrio respirar sozinho.

 O exame da similaridade proveitoso tanto para os
argumentos indutivos quanto para os silogismos
hipotticos, bem como para a formulao das
definies. Sua utilidade para o raciocnio indutivo se
explica porque sustentamos que pela induo dos
particulares, com base nas similaridades, que inferimos
o universal, visto no ser fcil empregar a inferncia se
desconhecemos os pontos de similaridade.
Aristteles
 RESUMO

Desde o incio da rea de Planejamento, muitas linguagens apareceram para descrever

domnios e seus problemas. Atualmente, a PDDL amplamente usada e aceita pelos

pesquisadores devido a sua robustez e expresso. Contudo, alguns pesquisadores da rea

criticam a PDDL, pois ela uma linguagem semelhante a um cdigo fonte e difcil de ser

utilizada como linguagem de modelagem de domnio. Isso foi uma das motivaes para as

pesquisas sobre Engenharia do Conhecimento para Planejamento Automtico.

Atualmente, a Engenharia do Conhecimento para domnios de planejamento e seus

problemas tem demonstrado relevncia para as aplicaes de Planejamento Automtico.

Desde o ICKEPS de 2005 (International Competition on Knowledge Engineering for

Planning & Scheduling), a comunidade de Planejamento Automtico tem pesquisado sobre

novas ferramentas, mtodos e linguagens de modelagem.

Nesse trabalho, a ferramenta de engenharia do conhecimento itSIMPLE possui a

linguagem UML.P conhecida como a UML com abordagem para planejamento automtico.

A necessidade interpretar os modelos UML.P em modelos PDDL. Como a UML.P e a

PDDL so semiformais, optou-se por utilizar a F-Logic, que uma lgica correta e

completa para apoiar essa interpretao.

Palavras-chave: Planejamento Automtico, Engenharia do Conhecimento, Interpretao,

PDDL, UML.P e F-Logic.

 ABSTRACT

Since the beginning of the Planning in Artificial Intelligence field, many languages have

appeared to describe domains and its problems. Nowadays, PDDL is broadly used and

accepted by the researchers due to its robustness and expression. However, some

researchers in the automatic planning field criticize PDDL, because it is a language similar

to a source code and difficult to be used as a domain modeling language. This was one of

the motivations for the research in the Knowledge Engineering for Automatic Planning.

Nowadays, the Knowledge Engineering for planning domains and problems has shown

relevance to the automatic planning applications. Since the ICKEPS05 (International

Competition on Knowledge Engineering for Planning & Scheduling), the automatic

planning community has researched new tools, methods, and modeling languages.

In this work, the knowledge engineering tool itSIMPLE has the UML.P language

known as UML for the Automatic Planning approach. The need is to interpret the UML.P

models into PDDL models. As UML.P and PDDL are semi-formal languages, it was

decided to use F-Logic, which is a sound and complete logic to give support to this

interpretation.

Key words: Automated Planning, Knowledge Engineering, Interpretation, PDDL, UML.P,

and F-Logic.
 LISTA DE FIGURAS

Figura 1 A necessidade da Interpretao Formal. 2

Figura 2 Definindo os requisitos de um Domnio em PDDL. 11
Figura 3 A categoria :Predicates da PDDL. 12
Figura 4 Domnio em PDDL do Mundo dos Blocos. 12
Figura 5 Restrio para os blocos do Mundo dos Blocos. 13
Figura 6 Ao pegar em PDDL do Mundo dos Blocos. 14
Figura 7 Problema dos TresBlocos em Planejamento. 14
Figura 8 Estado Inicial do Problema em PDDL do Mundo dos Blocos. 15
Figura 9 Estado Objetivo do Problema em PDDL do Mundo dos Blocos. 15
Figura 10 Rede Semntica. 18
Figura 11 Quadros. 19
Figura 12 Diagrama de Casos de Uso. 20
Figura 13 Diagrama de Classes. 21
Figura 14 Diagrama de Mquina de Estado. 22
Figura 15 Diagrama de Objetos. 23
Figura 16 Relacionamentos da UML.P. 23
Figura 17 Uma Classe em UML.P. 25
Figura 18 Situao usando diagrama de objetos. 25
Figura 19 Mapeamentos das sintaxes UML.P e PDDL em F-Logic. 26
Figura 20 Raciocnio sobre objetos com Flora-2. 28
Figura 21 Visualizador do Flora. 29
Figura 22 Ambiente de Engenharia do Conhecimento (MCCLUSKEY, 2000). 30
Figura 23 Interpretao Correspondente. 41
Figura 24 Interpretao Completa da UML.P em F-Logic e sua Interpretao Forma
Reduzida IFR. 51
Figura 25 Interpretao do domnio Mundo dos Blocos. 55
Figura 26 Equivalncia de Modelos. 60
Figura 27 Modelos UML.P e Modelos PDDL. 61
Figura 28 Nomenclaturas idnticas nos modelos UML.P e PDDL. 62
Figura 29 Diagrama de Classes para o domnio Satlite. 73
Figura 30 Diagrama de Classes para o domnio Jantar dos Filsofos. 74
Figura 31 Diagrama de Classes para o domnio Logstica. 75
Figura 32 Diagrama de Classes para o domnio Zeno Travel. 76
 LISTA DE TABELAS

Tabela 1 - STRIPS ................................................................................................................ 8

Tabela 2 - Distines entre Dados, Informao e Conhecimento ......................................... 16
Tabela 3 - Convertendo Frames para Regras........................................................................ 19
Tabela 4 Traduo de Modelos......................................................................................... 41
Tabela 5 - Classes F-Logic em Tipos PDDL....................................................................... 44
Tabela 6 - Mtodos escalar F-Logic em Predicados 1-rios PDDL ..................................... 45
Tabela 7 - Mtodos F-Logic em Predicados 2-rios e n-rio PDDL .................................... 50
Tabela 8 Assinatura Auxiliares para Modelos UML.P ...................................................... 52
Tabela 9 Interpretao de classes em F-Logic................................................................... 52
Tabela 10 Interpretao de atributos ................................................................................. 53
Tabela 11 Interpretao de Associao de Classes............................................................ 53
Tabela 12 Interseco de F-Molculas entre UML.P e PDDL. .......................................... 64
Tabela 13 Equivalncia entre UML.P e PDDL para o domnio Satlite............................. 73
Tabela 14 Equivalncia entre UML.P e PDDL para o domnio Jantar dos Filsofos ......... 74
Tabela 15 Equivalncia entre UML.P e PDDL para o domnio Logstica.......................... 75
Tabela 16 Equivalncia entre UML.P e PDDL para o domnio Zeno Travel ..................... 76
Tabela 17 F-tomos perdidos na Interpretao em modelo PDDL..................................... 77
 LISTA DE SMBOLOS

@ Separador de mtodo e parmetros em F-Logic;

; Separador de mtodos em F-Logic;

: Auxiliar de expresso -um de objeto em F-Logic;

:: Auxiliar de expresso -um de classe em F-Logic;

-> Auxiliar de expresso de dado escalar no herdvel em F-Logic;

->> Auxiliar de expresso de conjunto de dados no herdvel em F-Logic;

*-> Auxiliar de expresso de dado escalar herdvel em F-Logic;

*->> Auxiliar de expresso de conjunto de dados herdvel em F-Logic;

=> Define assinatura de dado escalar no herdvel em F-Logic;

=>> Define assinatura de conjunto de dados no herdvel em F-Logic;

U Domnio de uma F-Estrutura;

I
Smbolo que denota a Interpretao Correspondente PDDL e F-Logic. Esse smbolo

diferente do smbolo lgico de equivalncia, sendo ele apenas um smbolo apresentando uma

possvel interpretao correspondente entre duas linguagens.

 SUMRIO

CAPTULO 1 ................................................................................................................. 1
1. INTRODUO ....................................................................................................... 1
1.1. Motivaes ........................................................................................................... 3
1.2. Objetivo ............................................................................................................... 4
1.3. Estrutura da Dissertao ........................................................................................ 4
CAPTULO 2 ................................................................................................................. 6
2. REVISO BIBLIOGRFICA ...................................................................................... 6
2.1. Descrio de Aes................................................................................................ 6
2.2. Linguagens de Modelagem de Domnios de Planejamento .......................................... 7
2.2.1. STRIPS STanford Research Institute Problem Solver ............................................... 7
2.2.2. ADL Action Description Language ......................................................................... 9
2.2.3. PDDL Planning Domain Definition Language ........................................................ 10
2.2.4. Modelagem de Domnio e de Problema em PDDL .................................................... 11
2.3. Representao de Conhecimento usando Quadros e Grafos...................................... 16
2.3.1. Rede Semntica Semantic Network ..................................................................... 17
2.3.2. Quadros Frames ............................................................................................... 18
2.3.3. Rede Hbrida Hybrid Network ............................................................................. 20
2.4. Lgica desenvolvida para Classes e Objetos............................................................ 24
2.5. Ferramentas de Engenharia do Conhecimento ........................................................ 26
2.6. Engenharia do Conhecimento e o Planejamento Automtico ..................................... 29
CAPTULO 3 ............................................................................................................... 32
3. A F-LOGIC .......................................................................................................... 32
3.1. Sintaxe e Semntica da F-Logic............................................................................. 32
3.1.1. Propriedades da F-Logic ....................................................................................... 35
CAPTULO 4 ............................................................................................................... 41
4. INTERPRETAO DA PDDL EM F-LOGIC................................................................. 41
4.1. Correspondncia de Interpretao PDDL e F-Logic .................................................. 43
CAPTULO 5 ............................................................................................................... 51
5. INTERPRETAO DA UML.P EM F-LOGIC ............................................................... 51
5.1. Interpretao Completa UML.P em F-Logic ............................................................. 51
CAPTULO 6 ............................................................................................................... 60
6. INTERPRETAO DA UML.P EM PDDL UTILIZANDO A F-LOGIC ................................ 60
6.1. Estudo da Interpretao da UML.P para PDDL atravs da F-Logic.............................. 61
6.2. Exemplos da Equivalncia entre Modelos UML.P e PDDL utilizando a F-Logic .............. 72
6.3. Perdas Semnticas na Interpretao do modelo UML.P em modelo PDDL................... 77
CAPTULO 7 ............................................................................................................... 79
7. CONCLUSO ....................................................................................................... 79
7.1. Trabalhos Futuros................................................................................................ 79
REFERNCIAS BIBLIOGRFICAS ........................................................................ 80
 1

CAPTULO 1

1. INTRODUO

A Engenharia do Conhecimento (EC) para modelagem de domnios e problemas j

aceita atualmente na comunidade de Planejamento (AI Planning & Scheduling Community)
como relevante para o sucesso das aplicaes de Planejamento em Inteligncia Artificial (IA).
Sobre essa relevncia pode-se citar o ICKEPS (International Competition on Knowledge
Engineering for Planning & Scheduling), que existe desde 2005, e uma motivao para as
pesquisas na rea. Apesar da EC ainda estar no incio das atividades (MCCLUSKEY, 2002) e
a rea de Planejamento conviver com algumas restries, tais como: ferramentas, mtodos e,
principalmente, linguagens de modelagem de domnios.
Desde o incio das pesquisas em Planejamento, muitas linguagens tm sido desenvolvidas
para descrever domnios e seus problemas, evidenciando a necessidade da EC para aprimorar
a representao do conhecimento nessa rea. Atualmente, a linguagem PDDL
(MCDERMOTT, 1998), Planning Domain Definition Language, amplamente usada e aceita
pelos pesquisadores da comunidade de Planejamento devido a sua robustez e expressividade.
Contudo, a PDDL similar a uma linguagem executvel ou a um cdigo de mquina
(McCLUSKEY, 2002). Por essa razo, ela difcil de ser aceita no contexto de uma
linguagem de modelagem. De acordo com trabalhos importantes sobre a EC em
(MCCLUSKEY, 2000) e em (MCCLUSKEY, 2002) para a comunidade de Planejamento,
existe a necessidade de linguagem de modelagem, de mtodos, de ferramentas e de um
processo para a EC aplicada ao Planejamento Automtico. Por isso, j no primeiro ano do
ICKEPS, houve apresentaes de ferramentas de EC que utilizavam outras linguagens: Gipo
(SIMPSON et al. 2001) e UML.P (VAQUERO et al. 2005) de modelagem de domnios,
buscando uma nova maneira de se projetar domnios de Planejamento Automtico, que at
ento s podiam ser descritos em PDDL no que tange aos planejadores independentes de
domnio. Essas ferramentas tm a proposta de auxiliar a modelagem de domnios de
planejamento e, em seguida, gerar as descries em PDDL automaticamente.
Uma dessas ferramentas de EC (VAQUERO et al, 2005) chama-se itSIMPLE que possui
uma linguagem visual e intuitiva (VAQUERO et al, 2006), que at ento tem demonstrado
 2

sua utilizao para modelagem de conhecimento de domnios de planejamento nos congressos

nacionais e internacionais. A ltima demonstrao sobre o itSIMPLE para a comunidade de
Planejamento Automtico foi no ICAPS (International Conference on Automated Planning &
Scheduling) de 2008, onde foi apresentado em um workshop a aplicao do itSIMPLE
resolvendo problemas de gesto do conhecimento, escalonamento e planejamento na rea de
engenharia de software (UDO et al. 2008). No mesmo ICAPS, foi demonstrada a extrao de
conhecimento do diagrama de classes (GOMES et al. 2008) e sugestes para a competio de
engenharia do conhecimento (VAQUERO et al. 2008). O itSIMPLE tem demonstrado
resultados advindos de mais de 3 anos de pesquisa na EC para Planejamento Automtico.
O itSIMPLE possui a linguagem UML (BOOCH, JACOBSON, RUMBAUGH, 1999),
que surgiu na rea da Engenharia de Software na dcada de 90, com o objetivo de padronizar
noes de requisitos, classes, objetos, estados e elementos arquiteturais. Atualmente mantida
pela OMG (Object Modeling Group) e pode ser usada em muitas reas da cincia que
necessitem de modelagem de domnios. O itSIMPLE utiliza a UML.P, que a UML com
abordagem para Planejamento Automtico (VAQUERO et al, 2006).
Tanto a UML.P quanto a PDDL so entendidas como semiformais. A condio de ser
semiformal neste contexto significa uma linguagem que no possui um mapeamento
adequado entre sua sintaxe e sua semntica, apesar de existirem esquemas sobre como utilizar
a sua sintaxe (LKA, 2005). No caso da UML.P, ela possui diagramas e elementos
diagramticos para modelar domnios. Os prprios diagramas e elementos no esto
coerentemente mapeados em uma semntica, de modo que apresente problemas se existirem.
No caso da PDDL, existe uma semntica de sua verso 2.1 (FOX, M.; LONG, 2003), mas
ainda no h um mapeamento adequado de sua sintaxe com a sua semntica.
Atualmente, os modelos UML.P so interpretados em Modelos PDDL pelo itSIMPLE, o
que leva necessidade (figura 1) de uma formalizao dessa interpretao.

Figura 1 A necessidade da Interpretao Formal.

 3

Esse trabalho deve apresentar a Interpretao Formal, especificamente interpretao e

equivalncia de modelos, com a qual se garante que o modelo UML.P seja interpretado em
modelo PDDL. Tambm, esse trabalho fornece condies iniciais onde as alteraes em
qualquer um dos modelos sejam refletidas em ambos modelos, tanto do modelo UML.P em
modelo PDDL quanto modelo PDDL em modelo UML.P.

1.1. Motivaes
As motivaes desse presente trabalho, para melhor cit-las, foram classificadas em
motivaes acadmicas e motivaes industriais, assim como segue abaixo:
Acadmica
- Atender s necessidades da rea de Planejamento Automtico, que por sua
vez, desde seu incio, os pesquisadores direcionaram a pesquisa da rea para
melhorar as tcnicas e eficincia na gerao de planos, deixando a
Engenharia do Conhecimento em segundo plano (VAQUERO, 2007);
- Formalizar a interpretao da UML.P em PDDL atravs de uma Lgica
completa e correta como a F-Logic (KIFER; LAUSEN; WU, 1995) para
futuramente manter Bases de Conhecimento de domnios de Planejamento
Automtico;
- Atualmente, h idias sobre o uso de ferramentas da Engenharia do
Conhecimento por usurios comuns que no saibam quase nada sobre
Planejamento Automtico e necessitem de um plano com uma seqncia de
aes e que leve em considerao os recursos utilizados (MCCLUSKEY,
2002).
Industrial
- A UML j amplamente utilizada no quotidiano das empresas pelos
engenheiros de software e o objetivo da rea de Planejamento Automtico
em lidar com problemas reais, tal como: identificar a seqncia de aes a
partir de um estado inicial do problema, fazendo o escalonamento de
recursos para ento alcanar o estado objetivo, que resolve o problema. Tudo
isso, dado o conhecimento que se tem do domnio em questo para, ento,
gerar scripts de trabalho para vrios profissionais atuarem com mais preciso
e no-conformidades tendendo a zero no trabalho. Avanos importantes no
 4

contexto industrial. A UML.P pode ser implantada nas empresas para uso
dos engenheiros de software atravs da ferramenta itSIMPLE (VAQUERO et
al. 2005), que possui planejadores independentes de domnio embarcados.
No caso dessa dissertao, so planejadores que apenas precisam do domnio
e do problema especificados em PDDL.

1.2. Objetivo

O objetivo deste trabalho demonstrar que, para qualquer domnio de planejamento, a

interpretao do diagrama de classes da UML.P, especificamente classes, atributos e
associaes, pode ser realizada em tipos e predicados da PDDL.

1.3. Estrutura da Dissertao

Para a formalizao da interpretao do diagrama de classes da UML.P em tipos e

predicados da PDDL, para que haja confiabilidade na interpretao automtica da ferramenta
de EC, itSIMPLE, o contedo deste trabalho foi organizado da seguinte maneira:
Captulo 2: nesse captulo, apresenta-se uma descrio dos conceitos envolvidos na rea
de Engenharia do Conhecimento e na rea de Planejamento Automtico. H uma apresentao
sobre o conceito de Planejamento de Aes e algumas de suas principais linguagens de
modelagem de domnios e problemas. H tambm algumas representaes de conhecimento
na forma de redes mostrando a necessidade da modelagem de conhecimento. Apresenta-se
tambm a F-Logic para a representao de objetos. Sero apresentadas algumas ferramentas
de Engenharia do Conhecimento inclusive para a rea de Planejamento Automtico e, por
ltimo, sero apresentados alguns itens importantes sobre a Engenharia do Conhecimento
Aplicada para o Planejamento Automtico. A partir desse captulo, entende-se o uso da
UML.P como uma representao de conhecimento mais promissora para o uso dos
engenheiros do conhecimento do que as atuais linguagens da rea de Planejamento
Automtico. Entende-se tambm o porqu da utilizao da F-Logic para mapear a sintaxe
visual da UML.P. Alm disso, a F-Logic possui mapeamento com a Lgica de Predicados, o
que favorece essa mesma lgica no mapeamento da sintaxe da PDDL. Assim, com esses
entendimentos, cria-se as condies iniciais para a contribuio desse trabalho.

Captulo 3: nesse captulo apresenta-se a F-Logic com mais detalhes, especificamente

definies sobre sua sintaxe e sua semntica, de modo a entender seu uso nos captulos
 5

posteriores nas interpretaes de Modelos UML.P e PDDL. Pois, essas interpretaes devem
contar com o mapeamento de ambas linguagens para a F-Logic.

Captulo 4: nesse captulo apresenta-se a interpretao correspondente da F-Logic e

PDDL. Essa apresentao mostra como os elementos da PDDL, tais como, tipos e predicados
so interpretados em classes e mtodos da F-Logic e vice versa.

Captulo 5: nesse captulo apresenta-se a Interpretao Completa do diagrama de classes

da UML.P em F-Logic (GOMES, 2008) de modo que um subconjunto dessa interpretao,
chamada de interpretao IFR de forma reduzida, evidenciada para demonstrar a
equivalncia com a interpretao correspondente da PDDL e F-Logic.

Captulo 6: nesse captulo demonstra-se a equivalncia de f-tomos da F-Logic

provenientes da Interpretao Correspondente e da Interpretao IFR de Forma Reduzida, que
respectivamente tratam da PDDL e da UML.P. Demonstra-se tambm que a Interpretao
Correspondente conseqncia lgica da Interpretao Completa (GOMES, 2008) e, assim, o
Modelo UML.P pode ser interpretado em Modelo PDDL.

Captulo 7: nesse captulo apresenta-se a concluso desse trabalho, assim como as

conjecturas sobre trabalhos futuros.
 6

CAPTULO 2

2. REVISO BIBLIOGRFICA

Neste captulo foi realizada uma reviso bibliogrfica com o intuito de avaliar conceitos
necessrios para este trabalho, que surgiram em pesquisas sobre Representao do
Conhecimento, Engenharia do Conhecimento e Planejamento Automtico; apresentar a UML
e sua abordagem para planejamento automtico chamada UML.P (VAQUERO et al. 2006) e
juntamente da PDDL apresentando algumas lacunas que necessitam ser preenchidas. Alm
disso, esse captulo faz uma preparao dos conceitos que sero utilizados para mostrar que
factvel para o engenheiro do conhecimento, ou projetista de domnio realizar a modelagem
de qualquer domnio em UML.P e obter instantaneamente esse domnio j especificado em
PDDL.

2.1. Descrio de Aes

Para a rea de Planejamento Automtico, a descrio das aes que afetam os estados do
mundo com mudanas importante como representao do conhecimento e componente
fundamental para uma linguagem de modelagem de domnios (LIFSCHITZ; REN, 2007). De
acordo com Dana Nau, adquirir esse conhecimento uma das coisas mais importantes para a
pesquisa de Planejamento Automtico, pois os planejadores poderiam ser mais teis ao lidar
com problemas reais (NAU, 2007).
Surgiram muitas abordagens para representao de aes, tais como: o clculo situacional
(situation calculus) (MCCARTHY; HAYES, 1969), o clculo de eventos (event calculus)
(KOWALSKI; SERGOT, 1986) e o STRIPS (FIKES; NILSSON, 1971), todavia, na rea de
Planejamento Automtico, a linguagem ADL (PEDNAUT, 1989) foi a que melhor atendeu a
rea na modelagem de domnios reais, at ento, difceis de serem modelados pelo STRIPS.
A maneira pela qual a ADL foi criada permite trabalhos de pesquisa sobre descrio de
aes modernas como o C+ (LIFSCHITZ; REN, 2007), que toma como referncia sua
formalizao e o raciocnio sobre os efeitos das aes (PEDNAULT, 1994).
Para este trabalho, logo abaixo, sero apresentadas algumas linguagens de modelagem de
domnios de planejamento. Como a STRIPS, que define as aes como uma transformao de
 7

um conjunto de frmulas em lgica de primeira ordem, e a ADL, que possui uma descrio
dos efeitos das aes para atender a efeitos dependentes de contexto e por ltimo a PDDL,
que incorpora a STRIPS, a ADL e outras linguagens na sua descrio.
Recordando que esse presente trabalho tem por objetivo tratar os tipos e predicados da
PDDL, que so por sua vez importantes para a descrio das aes.

2.2. Linguagens de Modelagem de Domnios de Planejamento

2.2.1. STRIPS STanford Research Institute Problem Solver

A partir do incio da dcada de 70 houve a introduo da STRIPS (FIKES; NILSSON,

1971), que inovou a rea de Planejamento com a descrio de estados do mundo
(TONIDANDEL, 2003), alm de uma estrutura para problemas de planejamento usada at os
dias de hoje.
A STRIPS, alm de ser um sistema de planejamento, tem uma representao conhecida
com o mesmo nome STRIPS, que uma representao clssica de Planejamento que usa em
sua estrutura frmulas em lgica de primeira ordem para descrever o mundo e um conjunto de
operadores que representam as aes (COPPIN, 2004). O operador da STRIPS possui dois
componentes: a Precondio e o Efeito, que so utilizados para demonstrar as regras para
disparo de uma ao e mudanas no estado do mundo.
A precondio de um operador, segundo (RUSSELL; NORVIG, 2004), possui um
conjunto de literais que devem ser vlidos para que o operador seja disparado e, caso isso
ocorra, o efeito do operador mudar o estado atual para um novo estado, porque possui um
conjunto de literais positivos que deve ser adicionado a um determinado estado do mundo
(lista de adio) e um conjunto de literais negativos que deve ser eliminado desse mesmo
estado do mundo (lista de eliminao). Para exemplificar melhor a linguagem STRIPS,
considere o exemplo abaixo retirado de (LUGER, 2004) que lida com (P) precondies, (A) a
lista de adio e (E) a lista de eliminao:
 8

Tabela 1 - STRIPS
P: agarra( ) livre(X) sobre_a_mesa(X)
Pega(X) A: agarra(X)
E: sobre_a_mesa(X) agarra( )
P: agarra(X)
Descarrega(X) A: sobre_a_mesa(X) agarra( ) livre(X)
E: agarra(X)
Fonte: Luger, 2004

Na tabela acima, h a demonstrao das listas de precondies (P), de adio (A) e de

eliminao (E). Nesse exemplo, o operador pega(X) significa que o operador responsvel
pela ao pega o bloco X, entretanto, para que esse operador seja disparado, ele precisa
satisfazer as precondies (P), isto , a garra do rob deve estar livre (agarra( )), o bloco X
no pode possuir nada sobre ele (livre(X)) e o bloco X deve estar sobre a mesa
(sobre_a_mesa(X)). Se o operador pega(X) satisfizer essas precondies, ele deve aplicar a
lista de eliminao (E), que exclui do estado atual o fato do bloco X estar sobre a mesa
(sobre_a_mesa(X)) e o fato da garra estar livre (agarra( )), e deve aplicar a lista de adio
(A), que inclui o fato da garra do rob segurar o bloco X (agarra(X)) no estado atual
tranformando-o no estado sucessor.
Alm disso, importante citar que a precondio dos operadores deve possuir apenas
literais positivos e isso uma das restries na STRIPS. Ou seja, no podem existir literais
negativos na precondio dos operadores.
Outras restries na STRIPS que devem ser citadas so: a Hiptese de Mundo Fechado,
cujos literais que no so mencionados so tratados como falsos, o Objetivo do Problema,
que deve conter apenas conjunes, assim como os efeitos de cada operador e Literais
Bsicos (sem quantificadores) (RUSSELL; NORVIG, 2004). Essas restries acabaram
evidenciando fragilidades na STRIPS ao lidar com problemas de Planejamento.
Entretanto, havia uma fragilidade da linguagem STRIPS na literatura que a deixava
informal demais para uma linguagem com o objetivo de especificar domnios e problemas de
Planejamento, ocasionando o mau uso da linguagem STRIPS. Da, isso foi tratado por
LIFSCHITZ (1987), que definiu uma semntica que a direcionou para um uso adequado.
 9

Enfim, as outras fragilidades citadas acima tambm motivaram pesquisadores a tentar

solucion-las, ao passo que houve a criao de uma linguagem chamada ADL, que uma
extenso da STRIPS.

2.2.2. ADL Action Description Language

A ADL (PEDNAUT, 1989) tambm uma linguagem de especificao de domnios e

problemas de Planejamento, que mais expressiva que a STRIPS e, por isso, pode representar
problemas de planejamento que seriam difceis para a STRIPS representar (COPPIN, 2004).

A ADL proporciona, segundo (RUSSELL; NORVIG, 2004) (COPPIN, 2004), efeitos

condicionais, tipos, disjunes de literais, predicado de igualdade e quantificadores, alm da
hiptese de mundo aberto. Os efeitos condicionais so efeitos que devem acontecer de acordo
com sua condio para que a ao seja executada. Os tipos so associados s variveis, por
exemplo, (b : Bloco, h : Mo). As disjunes de literais so representaes tais como:
Sobre(blocoA, blocoB) (Em(blocoA, Mesa) Sobre(blocoA, blocoC)). Na ADL h o
predicado de igualdade, por exemplo, (bloco1 = bloco2). A hiptese de mundo aberto,
diferentemente da hiptese de mundo fechado na STRIPS, determina que os literais no
citados so informaes desconhecidas.

Essas melhorias proporcionadas pela ADL, ainda segundo (RUSSELL; NORVIG, 2004),
facilitaram a leitura dos modelos de planejamento, de modo que a ADL tem sido usada em
trabalhos atuais de Planejamento Automtico para Sistemas de Transio de Grafos
(EDELKAMP; JABBAR; LAFUENTE, 2005), o que demonstra ganhos nos tratamentos de
problemas de Planejamento de domnios reais devido flexibilidade da ADL. Algumas dessas
melhorias foram tambm incorporadas na prpria linguagem STRIPS.

No entanto, a rea de Planejamento Automtico, com as melhorias supracitadas com a

criao da ADL, alm de melhorias na prpria STRIPS e outras linguagens que surgiam e
haviam de surgir, demonstrava a falta de padronizao na rea e isso contribua
negativamente at para a avaliao do desempenho dos planejadores (MCDERMOTT, 1998).
Esse status na rea motivou a padronizao de uma linguagem de definio de domnios de
planejamento: PDDL.
 10

2.2.3. PDDL Planning Domain Definition Language

A PDDL em 1998 foi apresentada por Drew McDermott (1998) e se tornou um padro
como linguagem de especificao de domnios e problemas utilizada nas competies de
planejamento. A PDDL incorpora as descries feitas em STRIPS ou ADL. Apesar de alguns
pesquisadores da comunidade de Planejamento Automtico no apreciar algumas das
funcionalidades da PDDL, tais como: a descrio de tempo, a semelhana com cdigo fonte, o
trabalho pouco intuitivo, etc.; mesmo assim, no h como negar o avano que ela tem
proporcionado rea (FOX, M.; LONG, 2003). A PDDL desde o seu comeo teve um papel
extremamente importante por ter pressionado a comunidade de Planejamento a produzir
planejadores que controlassem problemas de planejamento mais realsticos (MCDERMOTT,
2003).

Ao buscar tratar problemas de Planejamento mais realsticos, ou seja, domnios reais e

complexos, a modelagem em PDDL tornou-se bastante extensa e difcil de ser usada. Alm
disso, no trivial apresentar ou compreender um modelo em PDDL. Isso era diferente
quando a rea de Planejamento lidava apenas com Toy Problems (MCCLUSKEY, 2002)
porque a modelagem em PDDL no era extensa e reduzia a complexidade da linguagem
devido ao tamanho do domnio.

Pode-se perceber que nos idos do Planejamento Clssico, quando a maioria dos problemas
de Planejamento eram conhecidos como Toy Problems, no havia problemas com a STRIPS
no que tange modelagem extensa, porque o domnio era simples em relao ao que se
passou a exigir da comunidade de Planejamento. Para McCluskey (2003), a PDDL no foi
projetada para ser associada com modelagem de domnios, pois a mesma, segundo
McCluskey, parece uma linguagem de mquina. Olhando singularmente para esse aspecto,
a PDDL no uma linguagem de modelagem prtica do engenheiro do conhecimento ou
projetista de domnio para ser aplicada a modelagem e isso se amplia quando se trata de
domnios reais e complexos.

Dessa forma, h fragilidades na PDDL como uma linguagem de modelagem de domnios

de planejamento, ao passo que, atualmente, ela possui alta expressividade ao lidar com
domnios reais e complexos devido sua especificao e semntica criada para a verso 2.1
(FOX, M.; LONG, 2003), que uma extenso do trabalho de Lifschitz (1987). E isso aponta
 11

para a necessidade da rea de Planejamento Automtico manter essa expressividade da PDDL

e, se possvel, prover melhoria nessa expressividade.

Na prxima subseo, h uma demonstrao do uso da PDDL para modelar o domnio

Mundo dos Blocos e um problema de planejamento de Trs Blocos.

2.2.4. Modelagem de Domnio e de Problema em PDDL

A modelagem em PDDL categoriza em certa ordem as informaes que sero necessrias

para os planejadores independentes de domnio gerarem um plano. Para elucidar essas
informaes, abaixo h algumas partes da modelagem de domnio do Mundo dos Blocos para
explicar as categorias Requerimentos, Tipagem, Precondies Negativas, Precondies
Quantitativas, Tipos, Predicados, Funes, Restries e Ao da PDDL:

(define (domain Mundo_dos_Blocos)

(:requirements :typing :negative-preconditions :quantified-
preconditions :constraints)
(:types
Manipulador - object
Bloco object
Mesa - object
Figura 2 Definindo os requisitos de um Domnio em PDDL.

Na figura acima, h a definio do nome do domnio como Mundo_dos_Blocos. A

categoria :requirements uma das categorias mais importantes na PDDL, pois a cada
definio de um novo modelo de domnio, os requirements definem as caractersticas do
domnio a ser tratado, ou seja:
[:disjunctive-preconditions] onde permitido que o operador lgico OU seja utilizado
nos objetivos;
[:typing] define que o modelo pode representar tipos de objetos;
:strips - essa caracterstica define os domnios no formato da linguagem STRIPS;
:adl - essa caracterstica define um super conjunto do formato STRIPS, que inclui as
seguintes caractersticas:

Declarao de tipos (:types);

Precondies negativas (:negative-preconditions);

Precondies disjuntas (:disjunctive-preconditions);

Igualdades (:equality);
 12

Precondies quantificadas (:quantified-preconditions);

Efeitos condicionais (:conditional-effects).
Ainda na figura acima, o domnio do Mundo dos Blocos foi definido como um domnio
que pode definir tipos, definir quantificadores e negaes como precondies de operadores e
definir restries para o domnio. Alm disso, esse domnio tem definido em :Types, trs
tipos de classes: Manipulador, Mesa e Bloco.
J na figura abaixo, h a representao da categoria :predicates em PDDL que define os
predicados do domnio Mundo dos Blocos:

(:predicates
(sobre ?blo - Bloco ?blo1 - Bloco)
(segurando ?man - Manipulador ?blo - Bloco)
(sobreMesa ?blo - Bloco ?mes - Mesa)
(garraLivre ?man - Manipulador)
(nadaSobre ?blo - Bloco)
)

Figura 3 A categoria :Predicates da PDDL.

Na figura acima, o domnio Mundo dos Blocos tem definido seus predicados que relatam
a seguinte informao: um bloco fica sobre outro bloco ou no, o manipulador pode segurar
um bloco, podem existir blocos sobre a mesa e o manipulador pode ter sua garra livre e, por
ltimo, um bloco pode ter sua face topo livre. Nessa categoria, o projetista de domnio pode
definir as relaes rgidas (state invariants) do domnio, que so as relaes que se mantm
imutveis no domnio, e as relaes flexveis (fluents), que so relaes mutveis no domnio.
Ainda sobre relaes flexveis de domnio, o Mundo dos Blocos pode ter exemplificado
outra categoria importante da PDDL que funciona como uma relao flexvel, chamada de
:functions, que define as funes que lidam com valores numricos, assim como segue
abaixo:

(:functions
(pesoMesa ?mes Mesa))

Figura 4 Domnio em PDDL do Mundo dos Blocos.

 13

Na figura 4, a funo pesoMesa mais o smbolo ? seguido por mes e Mesa

significam que a funo pesoMesa possui como atributo ms do tipo Mesa. Todas as
vezes que aparecer o smbolo ? na PDDL, o engenheiro do conhecimento est descrevendo
um determinado atributo ou parmetro j lhe atribuindo o Tipo correto.
Ainda na figura 4, o domnio Mundo dos Blocos possui a definio de uma funo que
deve medir o peso da Mesa dados os blocos sobre ela. Na PDDL h tambm uma categoria
sobre algo que restrinja o domnio com restries. Por exemplo, pode-se ter definido para o
domnio Mundo dos Blocos um peso mximo que a mesa suporte. Na PDDL, isso pode ser
tratado com outra categoria sobre restries.
Na figura abaixo, tem-se a categoria :constraints, onde o projetista de domnio pode
restringir o domnio com regras:

(:constraints
(and
(forall (?blo1 - Bloco ?blo2 - Bloco ?blo - Bloco)
(always
(imply
(and
(sobre ?blo ?blo1)
(sobre ?blo ?blo2)
)
(= ?blo1 ?blo2)
)
)
)

Figura 5 Restrio para os blocos do Mundo dos Blocos.

Na figura acima, a restrio significa que, se um bloco est sobre outro bloco, ento, s
pode estar sobre esse bloco.
J a representao das aes parte essencial para a rea de planejamento e a PDDL
mantm inclusive a abrangncia que a ADL (PEDNAULT, 1989) trouxe para a rea de
Planejamento Automtico no que tange descrio de aes, que tem atualmente apoiado o
desenvolvimento de novos trabalhos na rea sobre transformao de grafos (EDELKAMP;
JABBAR; LAFUENTE, 2005). Para exemplificar essa descrio de aes na PDDL, segue a
definio de uma ao do Mundo dos Blocos:
 14

(:action pegar
:parameters (?m - Manipulador ?x - Bloco ?t - Mesa)
:precondition
(and
(sobreMesa ?x ?t)
(nadaSobre ?x)
(garraLivre ?m))
:effect
(and
(segurando ?m ?x)
(not (garraLivre ?m))
(not (sobreMesa ?x ?t)))
)

Figura 6 Ao pegar em PDDL do Mundo dos Blocos.

Na figura acima, a ao pegar somente ser executada se as precondies forem satisfeitas

tais como: um bloco esteja sobre a mesa, no haja nada sobre esse bloco e a garra do
manipulador esteja livre. Se forem satisfeitas as precondies, ento, a ao pegar ser
executada transformando o estado atual em um estado sucessor com as seguintes mudanas: a
garra do manipulador no est mais livre, o bloco no est mais sobre a mesa e o manipulador
est segurando o bloco.
Descrevendo todas as aes do domnio Mundo dos Blocos como a ao pegar da figura
6, finaliza-se a descrio de domnio da PDDL, sendo necessrio agora definir um ou mais
problemas de Planejamento para o domnio modelado. Para tanto, sero apresentadas partes
do arquivo de problema de planejamento em PDDL para o Mundo dos Blocos. A seguir esto
os objetos envolvidos no problema:

(define (problem TresBlocos)

(:domain Mundo_dos_Blocos)
(:objects
A - Bloco
B - Bloco
C - Bloco
Manipulador1 - Manipulador
Mesa1 - Mesa
)
Figura 7 Problema dos TresBlocos em Planejamento.

Na figura acima, o problema de planejamento TresBlocos segue a definio do domnio

Mundo_dos_Blocos, onde h trs blocos A, B e C, um manipulador chamado Manipulador1 e
uma mesa chamada Mesa1. Esses so os objetos envolvidos no domnio.
A seguir, ser apresentada a figura referente ao estado inicial do problema de planejamento:
 15

(:init
(sobreMesa C Mesa1)
(sobre B C)
(sobre A B)
(nadaSobre A)
(garraLivre Manipulador1)
)

Figura 8 Estado Inicial do Problema em PDDL do Mundo dos Blocos.

Na figura 8, referente ao estado inicial do problema, existem os seguintes fatos: o bloco C

est sobre a Mesa1, o bloco B est sobre o bloco C, o bloco A est sobre o bloco B, no h
nada sobre o bloco A e a garra do Manipulador1 est livre.
Abaixo, segue a definio do estado objetivo:

(:goal
(and
(sobre C B)
(sobre B A)
(sobreMesa A Mesa1)
(nadaSobre C)
(garraLivre Manipulador1)
)
)
Figura 9 Estado Objetivo do Problema em PDDL do Mundo dos Blocos.

Na figura acima, h a definio do estado objetivo onde o bloco C deve estar sobre o
bloco B, o bloco B deve estar sobre o bloco A, o bloco A deve estar sobre a Mesa1, nada deve
estar sobre o bloco C e o Manipulador1 deve ter sua garra livre.
Nessa subseo, foram expostas as categorias da PDDL e como o projetista de domnio
pode definir domnios e problemas de planejamento utilizando essas categorias. Pode-se notar
que essa linguagem no apropriada para as atividades de aquisio, anlise e modelagem de
um processo de EC devido a sua semelhana com cdigo fonte.
Na prxima seo, h uma reviso sobre representao de conhecimento na forma de
redes com a finalidade de mostrar a propenso do ser humano desde pocas remotas a utilizar
redes para melhor representar o conhecimento adquirido.
 16

2.3. Representao de Conhecimento usando Quadros e Grafos

Primeiramente, necessrio definir o conceito conhecimento que esse presente trabalho

aborda tomando definies da rea de Engenharia do Conhecimento (SCHREIBER et al,
2000) que faz a seguinte distino:
Dados so sinais sem interpretao tais como caracteres, smbolos e concatenao
desses ltimos, que esto na vida do ser humano e mquinas em grande
quantidade;
Informao o significado atribudo aos dados de tal forma que os dados sempre
so os mesmos, entretanto, pode-se atribuir significado (informao) diferente aos
dados e, logo, a informao nem sempre ser a mesma;
Conhecimento o todo composto de dados e informao de tal maneira que tanto
as pessoas como as mquinas podem pr o uso desse conhecimento na prtica.
Dessa maneira, o Conhecimento possui dois aspectos distintos: um obter o
propsito para se alcanar o objetivo e o outro, capacidade de gerar nova
informao.
Para exemplificar essas distines, segue a tabela abaixo:
Tabela 2 - Distines entre Dados, Informao e Conhecimento
Distino entre Conceitos
Caracterstica Exemplo
Dado Caracteres Brutos sem interpretao ...---...
Informao Significado anexado ao dado SOS
Alerta de Emergncia
Propsito e Competncia para a Informao;
Conhecimento Incio de Operao de
Potencial para gerar ao.
Resgate
Fonte: SCHREIBER et al, 2004

Dadas as distines supracitadas entre dados, informao e conhecimento, parte desse

trabalho cita modelos projetados em uma representao de conhecimento em forma de rede
chamada de UML para Planejamento Automtico, conhecida na rea como UML.P. Essa
linguagem possui diagramas que, de acordo com SOWA (2006), so redes. O fato de cada
diagrama possuir um propsito, SOWA (2006) cita a UML como rede hbrida. Entretanto,
nem todos os diagramas da UML so redes. A propsito, os quatro diagramas da UML.P so
redes: casos de uso, mquina de estados, objetos e classes.
Dessa maneira, buscou-se com essa reviso avaliar a evoluo dessa estrutura de
representao de conhecimento at o que a UML.P atualmente para Planejamento
Automtico.
 17

2.3.1. Rede Semntica Semantic Network

A primeira Rede Semntica apareceu na histria no sculo 234-305 d.C. cujo filsofo
Porfrio comentou o mtodo de Aristteles para categorizao de supertipos e subtipos usando
uma rede. Apenas, em 1909, Charles S. Peirce criou o que ele chamou de grafos existenciais
com a primeira formalizao da rede semntica usando a lgica moderna (RUSSELL;
NORVIG, 2004) (SOWA, 2006).
Porm, houve um destaque na dcada de 60 (RUSSELL; NORVIG, 2004) quando Ross
Quillian props um modelo computacional para a memria humana chamado de memria
semntica justamente pelo seu interesse por memria humana e processamento de linguagens
(BITTENCOURT, 2006). J na dcada de 70, houve grande interesse pelas redes semnticas
implementadas em sistemas para compreenso da linguagem natural devido facilidade de
representar o conhecimento com a sua notao.
A Rede Semntica uma representao visual de ns e arcos que se relacionam. Os ns
so qualificados como categorias ou classes, conceitos e objetos, ao passo que os arcos,
geralmente, so qualificados como predicados em lgica de primeira ordem e possuem a
restrio de apenas relacionar dois ns, ou seja, um relacionamento binrio. Atravs desses
componentes da rede semntica e uma orientao usada para model-la, obtm-se uma
representao do domnio pretendido (SOWA, 2006).
A orientao para a modelagem de uma Rede Semntica ajuda na leitura do domnio
representado e composta de algumas regras, tais como (NILSSON, 1998):
H dois tipos de Ns:

Ns que podem ser categorias ou propriedades das categorias;

Ns que representam os prprios objetos do domnio.
H trs tipos de Arco:

Arco denotando herana conhecido como arco -um;

Arco para instncia de categorias;

Arcos para funes.
Entretanto, Bittencourt (2006) cita tambm o arco parte-de e chama os Arcos para
funes de especficos do domnio chamando-os de Traos. Essa definio de arcos e ns
ajudam na interpretao do domnio. Todavia, no impede que o projetista cometa erros na
modelagem da rede.
 18

Apesar da Herana de Propriedades ser uma das caractersticas mais importantes do

mtodo de representao das redes semnticas, necessrio implementar polticas de herana
para evitar problemas tais como a Herana Mltipla que leva a erros de deduo sobre a rede.
Para exemplificar como uma rede semntica, h uma modelagem reduzida do captulo 2
desse presente trabalho na figura 10 e essa rede possui arcos -um, -parte e traos.

Figura 10 Rede Semntica.

Com a rede semntica da figura 10 tem-se uma leitura visual e intuitiva que facilita o
entendimento do domnio. Por exemplo, sabe-se que a UML.P uma especializao da UML
e que ela uma rede hbrida.
A coerncia do domnio deve depender bastante da viso do projetista ou engenheiro do
conhecimento, de tal forma que a Rede Semntica possa ser validada. Contudo, mesmo com
essa restrio, evidente o uso massivo das redes semnticas como representao do
conhecimento, tanto que Marvin Minsky na dcada de 70, segundo (RUSSELL; NORVIG,
2004) e (BITTENCOURT, 2006), produziu um trabalho sobre Frames, usando as redes
semnticas.

2.3.2. Quadros Frames

Os Quadros, mais conhecidos como Frames, foram desenvolvidos com base nas redes
semnticas cujo objetivo foi destacar as propriedades das categorias e evidenciar os
 19

relacionamentos com outros quadros (BENDER, 1996). Um frame algo que contm Slots
(vaga em um esquema), onde cada atributo de uma categoria ou frame um slot. Um frame
pode se relacionar com outros frames. Por exemplo, dois frames: Veculo e Caminho, onde
Caminho -um Veculo. O frame Caminho possui um slot que o -um do tipo Veculo,
dessa forma, veja abaixo uma figura com esse exemplo:

Figura 11 Quadros.

Marvin Minsky foi criticado por criar algo j existente nas linguagens orientadas a objetos
(RUSSELL; NORVIG, 2004). Todavia, seu trabalho acabou fornecendo uma melhor direo
para as linguagens orientadas a objetos (BITTENCOURT, 2006) e ao longo da dcada de 70
houve esforos para formalizar a rede semntica e os frames.
Pode-se tratar os frames com lgica de primeira ordem como no exemplo a seguir
(BENDER, 1996):
Tabela 3 - Convertendo Frames para Regras
Predicado Significado
frame(X) X um frame
Is-a(X, Y) Frame Y um caso especial do frame X
slot(X, S) S um slot de X
default(X, S, V) V o valor default do slot S de X
Fonte: BENDER, 1996

Alm da possibilidade de se aplicar a lgica em sistemas baseados em frames com seus

atributos internos, esses sistemas podem tratar de um raciocnio guiado por expectativas, pois
a partir dos atributos internos e os relacionamentos dos frames busca-se preencher um
objetivo inter e intra frames (BITTENCOURT, 2006).
Entretanto, houve aplicaes diferentes de redes que levou SOWA (2006) a citar a UML
como rede hbrida com diagramas responsveis por cenrios do domnio (casos de uso),
 20

atividades, estados, classes, objetos e outros diagramas. Prxima subseo deve detalhar
melhor a UML.

2.3.3. Rede Hbrida Hybrid Network

A rede hbrida (neste trabalho trata-se de uma linguagem com uma coleo de redes com
diferentes propsitos) de maior uso atualmente a UML, que foi criada por Booch, Jacobson,
Rumbaugh (1999) na rea da Engenharia de Software para a modelagem de sistemas (SOWA,
2006) e possui um subconjunto de diagramas que so redes. A UML citada como uma rede
hbrida devido ao fato de possuir diferentes tipos de redes (SOWA, 2006), entretanto, nem
todos os diagramas da UML so redes, tais como: diagrama de seqncia, diagrama de tempo,
etc. A UML.P (VAQUERO et al, 2006), que uma abordagem da UML para a rea de
Planejamento Automtico, possui 4 (quatro) diagramas (redes):

Diagrama de Casos de Uso esse diagrama trata das interaes entre os Agentes,
chamados de Atores, e os casos de uso, subobjetivos do domnio. A seguir, um
exemplo do domnio Logstica para o diagrama de casos de uso:

Figura 12 Diagrama de Casos de Uso.

Os casos de uso so como subobjetivos ou aes dos agentes na figura 12

denotando dirigir da origem at o destino, carregar pacotes, descarregar
pacotes, voar da origem at o destino, etc.

Diagrama de Classes o principal diagrama da UML.P por ser o diagrama que
demonstra a definio das relaes entre as classes como tipos de objetos e as
propriedades das classes. O diagrama de classe utilizado na UML.P como o
diagrama que define o modelo esttico dos domnios de planejamento automtico
possui propsitos semelhantes rede semntica e aos frames quanto a modelar o
 21

conhecimento dos domnios, alm de possuir o conceito de multiplicidade entre as

classes. A seguir, um exemplo de diagrama de classes do domnio Logstica:

Figura 13 Diagrama de Classes.

Na figura acima, o domnio Logstica possui as classes Avio e Caminho que

so subclasses da classe Veculo. Um avio fica parado em um aeroporto, por isso,
a associao paradoEm da classe Avio para a classe Aeroporto com
multiplicidade 0..* (zero ou muitos) para apenas 1. A classe Aeroporto
subclasse da classe Lugar. O caminho pode estar tanto no aeroporto quanto em
algum local, por isso, a associao no da classe Caminho para a classe Lugar
com multiplicidade 0..* (zero ou muitos) para apenas 1. A classe Lugar a
superclasse das classes Local e Aeroporto. Qualquer lugar est dentro de apenas
uma cidade, por isso, a classe Cidade possui associao do tipo agregao
dentroDaCidade com a classe Lugar, onde a multiplicidade dessas duas classes
significa que muitos lugares fazem parte exclusiva de uma cidade. Por ltimo,
qualquer pacote carregado de um lugar para um veculo e transportado para outro
lugar para, ento, descarreg-lo l mesmo. Por isso, a classe Pacote pode ter 0..*
instncias de pacotes com associao EstEm com a classe Lugar com
multiplicidade 0..1, ou seja, o pacote est no lugar ou no. O pacote pode estar no
veculo, por isso a associao no da classe Pacote para a classe Veculo com
multiplicidade 0..* para 0..1, com o mesmo significado da multiplicidade da classe
Pacote para a classe Lugar.
 22

Diagrama de Mquinas de Estado um tipo especial de rede executvel que no

suporta paralelismo e no possui marcaes para controlar o disparo de transies.
Ao invs disso, utiliza-se da OCL, que uma verso da Lgica de Primeira Ordem
para a orientao a objeto, com a qual se especifica as precondies e os efeitos de
um operador (SOWA, 2006). Entretanto, a OCL possui o mesmo problema que a
PDDL: semelhana com cdigo fonte. Abaixo, segue um exemplo desse diagrama
no domnio Logstica:

Figura 14 Diagrama de Mquina de Estado.

Diagrama de Objetos uma rede na qual h um grafo com ns que so objetos,

instncias de classes, com seus links que refletem os relacionamentos realizados no
diagrama de classes. Esse diagrama usado para definir o estado atual e o estado
objetivo, que uma necessidade para utilizar a tecnologia de Planejamento
Automtico. Segue um exemplo desse diagrama sobre o domnio Logstica:
 23

Figura 15 Diagrama de Objetos.

Na figura acima, apresentado o diagrama de objetos mostrando que h um pacote

em um local na cidade de So Paulo. Nesse local h tambm um caminho. Na
cidade de So Paulo h um aeroporto e um avio parado l. Da mesma forma h a
mesma representao na cidade do Rio de Janeiro. Isso, por exemplo, pode ser a
situao atual do domnio Logstica e a situao objetivo pode ser o pacote de So
Paulo no Rio de Janeiro e o pacote do Rio de Janeiro em So Paulo. Para fazer
isso, h que se modelar outro diagrama de objetos para essa situao.

No diagrama de classes da UML.P existem particularidades semelhantes quelas

orientaes que foram apresentadas nas Redes Semnticas quanto ao relacionamento de ns e
essas particularidades servem para que a modelagem tenha uma sintaxe visual prxima aos
requisitos do domnio em questo:

Figura 16 Relacionamentos da UML.P.

Na UML h um relacionamento chamado de dependncia, mas no utilizada na UML.P

para classes. Na figura 16 demonstram-se 4 tipos de relacionamentos na UML.P, a primeira
 24

seta a que define herana assim como o -um na rede semntica, a segunda seta significa
que alguma classe chamada parte compe outra classe chamada todo, e a terceira seta
para as associaes entre classes. A quarta seta no havia na rede semntica e usada para
intensificar a segunda seta -parte, pois ela significa que determinada parte s existe para
compor determinado todo, por exemplo, o brao parte de Joo e no existiria sem Joo.
Com os relacionamentos e as redes descritas acima possvel descrever um domnio real
de Planejamento Automtico e, tambm, descrever um conjunto de problemas pertinentes a
esse domnio com o intuito de se obter Planos com uma seqncia de aes levando em
considerao os recursos a serem utilizados. Exemplo disso, o Domnio de Lean Software
Development na rea de engenharia de software com um problema de cumprimento de prazos
e escalonamento de recursos (UDO et al. 2008). Entretanto, falta uma definio formal para a
UML.P que herdou essa deficincia da prpria UML.
Essa deficincia foi tratada parcialmente em GOMES (2008), que formalizou a
interpretao completa do diagrama de classes da UML.P, utilizando a lgica no-monotnica
F-Logic que pode ser aplicada a objetos e ser revisada na prxima seo.

2.4. Lgica desenvolvida para Classes e Objetos

Este trabalho utilizar a lgica no-monotnica chamada de Frame Logic ou F-Logic,

porque se pretende fornecer base para a interpretao da UML.P em PDDL atravs dessa
lgica. Lembrando que isso se deve ao fato de ambas serem semiformais. Vale ressaltar para
esse fim que existem trabalhos em (RAMALHO; ROBIN, 2004) e em (RAMALHO; ROBIN;
SCHIEL, 2004) que j apresentaram o diagrama de classes da UML sendo interpretado em F-
Logic. Esses trabalhos motivaram a Interpretao Completa criada em (GOMES, 2008). Alm
disso, a F-Logic torna possvel o uso futuro da UML.P com o raciocnio orientado para um
sistema baseado em conhecimento (KBS).
A F-logic (KIFER; LAUSEN, WU, 1995) ou Frame Logic um formalismo aplicado a
linguagens orientadas a objeto ou baseadas em Quadros (frames). O nome Frame Logic vem
do trabalho de Marvin Minsky, em 1975, na rea de IA, apresentado nesse trabalho na seo
2.3.2 sobre Quadros. Entretanto, ao invs de usar a terminologia usada nos Quadros (frames),
os autores adotaram a terminologia da orientao a objeto.
A F-Logic uma lgica de primeira ordem orientada a objeto (KIFER; LAUSEN, WU,
1995), acrescentando lgica de predicados, as propriedades de objetos com estrutura interna
complexa, hierarquias de classe e herana, tipos e encapsulamento.
 25

A formalizao da F-Logic visto em (KIFER; LAUSEN, WU, 1995) criou a possibilidade

do clculo de predicados ser analisado como um caso especial da F-Logic e com algum
esforo pode-se adaptar a teoria da lgica clssica para a F-Logic, permitindo compatibilidade
com muitos sistemas existentes.
Para mostrar o uso da F-Logic, ser modelada abaixo uma classe em UML.P chamada
Bloco, que possui dois atributos:
nadaSobre um atributo que significa que no h nada em cima do bloco;
sobre um relacionamento de associao que significa que um bloco pode estar
sobre outro bloco.

Figura 17 Uma Classe em UML.P.

Na sintaxe da F-Logic a representao da classe acima deve ficar assim como segue:
Bloco[nadaSobre@=> Boolean; sobre@=> Bloco].
O smbolo => significa que se trata da assinatura de mtodo escalar para um atributo ou
associao da UML.P. O smbolo => ser apresentado em detalhes no captulo 3. Nesse
caso, trata-se das regras sobre como um bloco analisado no domnio mundo dos blocos.
E para criar, por exemplo, uma situao baseada nessa classe e em suas propriedades
(atributos e associaes), instancia-se objetos em UML.P assim como segue:

Figura 18 Situao usando diagrama de objetos.

 26

Na sintaxe da F-Logic, a representao dos objetos acima deve ficar assim como segue:
bloco1:Bloco[nadaSobre@->true, sobre@->bloco2].
bloco2:Bloco[nadaSobre@->false].
O smbolo -> acima o mtodo escalar de dados para os objetos UML.P utilizando
regras e representando fatos. O smbolo -> ser apresentado em detalhes no captulo 3.
Ainda no captulo 3, tanto a sintaxe da F-Logic quanto sua semntica correta e completa
sero detalhadas, de modo a compreender a interpretao completa da UML.P em F-Logic
realizada em (GOMES, 2008), alm da criao da interpretao correspondente da PDDL em
F-Logic e vice versa, tal como pode ser visto na seguinte figura:

Figura 19 Mapeamentos das sintaxes UML.P e PDDL em F-Logic.

Com a figura acima, pretende-se realizar a mesma estratgia de mapeamento utilizada na

interpretao completa (GOMES, 2008) para a sintaxe da PDDL em F-Logic e vice versa,
I
chamada Interpretao Correspondente simbolizada por . A partir dessa estratgia das
interpretaes completa e correspondente, ser demonstrada a equivalncia dos modelos
UML.P e PDDL.
Na prxima seo, haver apresentaes de ferramentas de engenharia do conhecimento.
Uma dessas ferramentas o itSIMPLE, que vem sendo apresentada como uma ferramenta que
satisfaz os anseios da comunidade de Planejamento Automtico considerando os processos de
Engenharia do Conhecimento.

2.5. Ferramentas de Engenharia do Conhecimento

Desde o ICKEPS05, competio de EC para Planejamento Automtico, a comunidade de

Planejamento Automtico conheceu trs ferramentas para modelagem de domnios e
problemas de planejamento: o ModPlan, o GIPO e o itSIMPLE.
O ModPlan (EDELKAMP; MEHLER, 2005) uma ferramenta de engenharia do
conhecimento, onde possvel incluir os arquivos de domnio e de problema em formato
 27

PDDL. Com o ModPlan tambm possvel escolher uma tcnica de Planejamento

Automtico cujo Planejador ser escolhido para tratar o problema; nele h algoritmos de
aprendizagem, visualizao de planos, planejadores embarcados e validao de domnios e
problemas.
O GIPO (SIMPSON et al, 2001) uma ferramenta que possui como representao do
conhecimento a linguagem OCLh, que significa Object-Centred Language, com o objetivo de
aprimorar a aquisio de conhecimento e o processo de validao, alm de melhorar o
processo de gerao dos planos. O GIPO significa Graphical Interface for Planning with
Objects e foi construdo para que no fosse necessrio um especialista em Planejamento
Automtico, ou seja, para que pudesse ser manuseada por um usurio comum; todavia, ainda
possui uma interface complexa para esse objetivo. O GIPO tambm uma ferramenta para ser
usada em um processo de Engenharia do Conhecimento para Planejamento Automtico.
O itSIMPLE (VAQUERO et al. 2005), Integrated Tool Software Interface for Modeling
Planning Environments, uma ferramenta para o processo de Engenharia do Conhecimento
cuja modelagem realizada usando a UML.P. Atualmente, o itSIMPLE possui planejadores
em linux e windows embarcados para gerao de plano e, tambm, h a possibilidade de
avaliar as mudanas de estado no domnio com a navegao dentro das aes do plano, alm
de avaliar os grficos de uso dos recursos do domnio em um dado problema. Para os
diagramas de mquina de estado, pode-se fazer a anlise dos resultados usando Redes de
Petri.
As tcnicas, mtodos, prticas da EC esto pouco-a-pouco fazendo parte da rea de
Planejamento, apesar de ainda estar no incio; o que demonstra muita pesquisa a ser realizada
pela comunidade (MCCLUSKEY, 2003).
Nesta seo foram apresentadas trs ferramentas da EC para Planejamento Automtico,
todavia, faz-se necessrio apresentar outra ferramenta que no foi construda para a rea de
Planejamento Automtico, mas como uma ferramenta de programao do conhecimento de
propsito geral. Essa ferramenta o FLORA-2, que baseada no compilador XSB e possui
como lgicas a Frame Logic e a Transaction Logic (LUDSCHER; YANG; KIFER, 1999).
O interessante sobre a Transaction Logic, de acordo com (KIFER; LAUSEN; WU, 1995),
que ela pode ser estendida de modo que seu Orculo de dados utilize frmulas bem formadas
em F-Logic, passando a ser chamada de Transaction F-Logic por (KIFER; LAUSEN; WU,
1995). Isso demonstra a possibilidade de usar o raciocnio dinmico dos objetos e, para a
UML.P, interpretar seu diagrama de mquina de estados.
 28

Para esclarecer melhor como o FLORA-2 funciona, abaixo h uma apresentao de sua
interface, onde:
H uma definio de classes, regras e objetos;
No caso abaixo, a regra :
- ?X:Bloco[nadaSobre->false] :- ?Y:Bloco[nadaSobre->true, sobre->?X].
Se o bloco Y no tem nada sobre ele e ele est sobre outro bloco X, ento, o
bloco X tem outro bloco sobre ele;
O bloco 1 no tem nada sobre ele e ele est sobre o bloco 2;
Foi perguntado Base de Conhecimento (BC) do Flora: o bloco 2 no tem nada
sobre ele, tem? O Flora responde: tem. Isso pode ser visto na tela como:
- bloco2:Bloco[nadaSobre->true].
No.

Figura 20 Raciocnio sobre objetos com Flora-2.

Na figura 20 segue a descrio em F-Logic:

//Definio de Classes
Boolean[].
Bloco[nadaSobre=>Boolean,
sobre=>Bloco].
//Definio de Regras
?X:Bloco[nadaSobre->false]:-?Y:Bloco[nadaSobre->true,sobre->?X].
//Definio de Objetos
bloco1:Bloco[nadaSobre->true, sobre->bloco2].
//Consulta BC
bloco2:Bloco[nadaSobre->false].

O Flora-2 tambm possui um visualizador das classes e objetos criados assim como seus
atributos e valores:
 29

Figura 21 Visualizador do Flora.

Visualizadores como o da figura 21 facilita manter a modelagem de domnio e de

problemas para o projetista de domnio ou engenheiro do conhecimento. Alm disso, o uso de
BCs e interfaces intuitivas podem ser o caminho para levar o planejamento automtico ao uso
comercial.
De acordo com McCluskey (2000), existe a necessidade de um KBS (Knowledge Base
System) para conhecimento sobre aes que suporte a reusabilidade de modelagem para
domnios de Planejamento e o FLORA-2 pode auxiliar nessa necessidade. Para este trabalho,
o FLORA-2 foi apresentado como uma ferramenta onde a F-Logic pode ser usada como um
possvel KBS para os domnios e problemas de Planejamento Automtico modelados pelo
itSIMPLE.

2.6. Engenharia do Conhecimento e o Planejamento Automtico

A Engenharia do Conhecimento (SIMPSON et al, 2001) para Planejamento Automtico

o processo que lida com a aquisio, validao e manuteno dos modelos de domnio de
planejamento, alm da seleo e otimizao apropriada dos recursos para planejamento.
Assim, so os processos da engenharia do conhecimento que suportam os processos de
planejamento. Para esses processos, h uma proposta de McCluskey de um modelo que um
ambiente para a engenharia do conhecimento (MCCLUSKEY, 2000) destinado ao
Planejamento Automtico:
 30

Figura 22 Ambiente de Engenharia do Conhecimento (MCCLUSKEY, 2000).

Esse Modelo de Ambiente da Engenharia do Conhecimento para o Planejamento

Automtico mostra que usurios e gerentes de domnio possam ter ferramentas de interface
amigveis com informaes de Planejamento sem qualquer necessidade de entender a
inerncia do Planejamento Automtico. J o engenheiro do conhecimento tem a
responsabilidade sobre os nveis desse modelo: manter as ferramentas de interface, manter as
ferramentas de manuteno (aquisio e validao de conhecimento), criar e manter os
modelos de domnio. Para o nvel da aplicao de Planejamento Automtico, o engenheiro do
conhecimento deve manter os planos existentes, prover os algoritmos de planejamento para a
criao de novos planos de acordo com as tarefas do domnio em questo (MCCLUSKEY,
2000).

McCluskey props esse ambiente de suporte para a Engenharia do Conhecimento e lista

algumas aes para a comunidade de Planejamento. Uma das aes seria a realizao de
pesquisas sobre ferramentas visuais que possam ajudar na modelagem de todo o modelo de
domnio tais como: objetos, estados, hierarquias de objetos, assim como aes. McCluskey
 31

tambm comps aes para avaliar os mtodos da engenharia usada para o Planejamento e
tambm sugere que as linguagens de modelagem de domnio sejam estruturadas, alm de uma
BC de Planejamento ampla. McCluskey props aes, tambm, no que tange semntica das
linguagens utilizadas em planejamento, assim como a PDDL, para que haja um processo forte
de padronizao para dar suporte a qualquer informao necessria e relacionada ao
Planejamento Automtico.

Sendo assim, essa viso sobre a Engenharia do Conhecimento para Planejamento

Automtico indica o porqu dessas ferramentas de EC como Gipo e itSIMPLE e suas
linguagens visuais serem aceitas na comunidade. Alm disso, a motivao de um dia possuir
KBS para a rea de Planejamento Automtico (MCCLUSKEY, 2000) implica formalizao
dos domnios e problemas. Portanto, o objetivo desse trabalho que visa demonstrar a
formalizao da interpretao do diagrama de classes da UML.P em tipos e predicados da
PDDL parte do caminho para um dia existir um KBS para a rea de Planejamento
Automtico.
 32

CAPTULO 3

3. A F-LOGIC

Essa dissertao tem como objetivo demonstrar que modelos UML.P provenientes do
diagrama de classes podem ser interpretados em modelos PDDL, especificamente, tipos e
predicados. Contudo, devido s duas linguagens, UML.P e PDDL, serem semiformais,
utilizou-se a F-Logic, que uma lgica correta e completa, para demonstrar como interpretar
os elementos dos modelos UML.P em elementos dos modelos PDDL. A Interpretao
Completa j foi criada em (GOMES, 2008), e ela faz o mapeamento da sintaxe visual do
diagrama de classes da UML.P na F-Linguagem da F-Logic. Assim, esse trabalho tambm
deve utilizar-se da mesma estratgia: mapear a sintaxe da PDDL na F-Linguagem da F-Logic.
Portanto, esse captulo deve detalhar as definies necessrias para compreender as
Interpretaes Completa e Correspondente e, tambm, sobre a equivalncia dos modelos
UML.P e PDDL a partir da teoria da F-Logic.
Dessa maneira, a partir da prxima seo, devem ser apresentadas as propriedades da F-
Logic (KIFER, LAUSEN, WU, 1995).

3.1. Sintaxe e Semntica da F-Logic

A F-Logic uma lgica de primeira ordem para objetos de acordo com (KIFER,
LAUSEN, WU, 1995), pois possui propriedades claramente atreladas ao objeto, tais como,
classes e mtodos. Dadas essas consideraes, para que a sua sintaxe tenha como demonstrar
as propriedades atreladas ao objeto, em (KIFER, LAUSEN, WU, 1995) h uma definio para
F-Molculas que trata dessa questo e ela ser apresentada tal como segue:

Definio 3.1: Uma molcula em F-Logic (F-Molcula) dada pelas seguintes afirmaes
(KIFER, LAUSEN, WU, 1995):
1. Uma definio IS-A dada na forma C::D ou na forma O:C, onde C, D e O so id-
termos;
 33

2. Uma molcula de objeto dada na forma de O[uma lista separada por ; de expresses
de mtodos]. Uma expresso de mtodo pode ser:
a. Expresso de dados no herdvel:
i. Expresso escalar (k 0):
ScalM@Q1,...,Qk -> T
ii. Expresso de conjunto de valores (l, m 0):
SetM@R1,...,Rl ->> {S1,...,Sm}
b. Expresso de dados escalares e de conjunto de valores herdveis. Essas expresses
so como as expresses de dados no herdveis exceto que os smbolos -> e ->>
so substitudos por *-> e *->> respectivamente.
c. Expresso de Assinatura:
i. Assinatura escalar (n, r, 0):
ScalM@V1,...,Vn => {A1,...,Ar}
ii. Assinatura de conjunto de valores (s, t, 0).
SetM@W1,...,Ws =>> {B1,...,Bt}

A definio acima mostra como a sintaxe da f-molcula e, a partir dela, h como

representar frames e objetos. Para esclarecer essa definio, no item 1, os id-termos so
identificadores de objetos e a f-molcula IS-A C::D significa que C um tipo de D e O:C
significa que O um elemento de C.
Os itens 2a e 2b no sero utilizados nesse trabalho porque o item 2a lida com a
descrio de fatos em F-Logic e o item 2b lida com a descrio de fatos que foram herdados.
Como esse trabalho lida apenas com a descrio de domnios de Planejamento Automtico,
ento, apenas deve-se utilizar a descrio em F-Logic que lida com as f-molculas IS-A e de
assinaturas de mtodos, que so os itens 1 e 2c respectivamente.
Entretanto, para um entendimento completo da definio, o item 2a, ScalM um mtodo
que possui como retorno uma tupla de objetos e SetM um mtodo que possui uma ou mais
tuplas de objetos. Por exemplo, a f-molcula O[ScalM@Q1,...,Qk -> T]significa que
O o id-termo objeto, Q1, ..., Qk so objetos como parmetros e T tambm um objeto. O
smbolo @ da F-Logic separa a descrio de mtodo ScalM ou SetM de seus parmetros e o
smbolo -> da F-Logic representa que deve existir apenas uma tupla de objeto de
determinado tipo: T. Dessa maneira, essa f-molcula pode ser representada tal como segue:
Robo1[segurando@BlocoA, Mesa1->True]. J o mtodo O[SetM@R1,...,Rl
 34

->>{S1,...,Sm}] possui definio de f-molcula semelhante a do ScalM descrita

acima, exceto o smbolo ->> da F-Logic, que representa a existncia de uma ou mais tupla
de objetos para cada tipo representado: {S1,...,Sm}. Dessa maneira, esse mtodo pode
ser representado como Caneta[tem@->>{Tampa, Refil, Corpo}].
J o item 2b lida com a descrio de fatos que so herdados das assinaturas do item 1 e
2c, por exemplo:
- a f-molcula do item 1 pode ser Homem :: Pessoa, Homem do tipo
Pessoa;
- a f-molcula do item 2c pode ter os mtodos Pessoa[temRG@=>String;
temCPF@=>String];
- Para utilizar a f-molcula do item 2b, sobre herana de mtodos, a classe
Homem herda as assinaturas dos mtodos temRG e temCPF da classe
Pessoa da seguinte maneira: Marcelo : Homem[temRG@*>24144590-14;
temCPF@*>370021198-01]. Lembrando que Marcelo : Homem
significa que Marcelo um elemento da classe Homem;
As f-molculas do item 2c lidam com a descrio de assinaturas de mtodos da F-Logic
como apresentado acima. Essas f-molculas definem a tipagem dos programas em F-Logic,
que a condio para que as f-molculas dos itens 2a e 2b possam ser descritas.
Dessa maneira, usando o mesmo exemplo, a f-molcula de assinatura de mtodos do item
2c, Robo[segurando@Bloco; Mesa => Booleano] possibilita a existncia da f-molcula de
descrio de fatos Robo1[segurando@BlocoA, Mesa1->True] para que seja satisfazvel e,
da mesma maneira, a f-molcula de assinatura de mtodos Produto[tem@=>>{Atributo}]
possibilita a existncia da f-molcula de descrio de fatos Caneta[tem@->>{Tampa, Refil,
Corpo}] para que tambm seja satisfazvel.
Nessa dissertao apenas se levar em considerao as expresses de mtodos de
assinatura (definio 3.1 item 2c) para um valor, que a assinatura escalar ScalM, e para
vrios valores, que a assinatura de conjunto de valores SetM. Essas expresses de mtodos
de assinatura escalar e de conjunto de valores so as utilizadas em F-Logic para lidar com
classes, que parte do foco dessa dissertao.
Com a F-Mlecula descreve-se os programas na F-Linguagem, ou seja, a sintaxe da F-
Logic. Nas subsees a seguir, devem ser apresentadas propriedades da F-Logic como a F-
estrutura, que a semntica da F-Logic.
 35

3.1.1. Propriedades da F-Logic

Em (KIFER, LAUSEN, WU, 1995) apresenta-se frmulas complexas e sobre como

descrev-las em F-Logic, chamadas de F-Frmulas. Algumas diretrizes sobre essas frmulas
esto como segue:
i) F-Molculas so F-Frmulas;
ii) , , so F-Frmulas se e tambm forem;
iii) um literal uma frmula molecular ou sua negao;
iv) o conectivo de implicao com o mesmo significado da Lgica Clssica, mas
diferente em termos de sentido da seta para no ser confundido com a definio 3.1 item
2a;
v) usa-se os demais smbolos iguais ao da Lgica Clssica exceto o smbolo implicao
descrito em iv);

Dentro de uma f-molcula podem existir vrios mtodos que juntos de sua classe so
considerados f-tomos. Em (KIFER, LAUSEN, WU, 1995), existe tambm a explicao dos
f-tomos, tal como segue:
A f-molcula X[ScalM@=>A; SetM@=>>B] equivalente conjuno de seus f-tomos
X[ScalM@=>A] X[SetM@=>>B].
Os f-tomos apresentados acima so importantes para se entender que uma f-molcula
muitas vezes no atmica como nas f-molculas IS-A, apresentadas na definio 3.1 item 1.
Por isso, f-molculas podem ser decompostas em um conjunto de f-tomos.
Portanto, nesse trabalho ser utilizado o termo f-tomo, que a parte atmica da F-
Linguagem. Os f-tomos sero bastante utilizados no captulo 4 sobre a Interpretao
Correspondente, no captulo 5 sobre a Interpretao IFR de forma reduzida e no captulo 6
sobre equivalncia e interpretao dos modelos UML.P e PDDL.
Outra propriedade essencial da F-Logic a sua semntica chamada de F-estrutura, que
um mapeamento contendo estruturas semnticas de acordo com sua tupla I= U, U, U, IF,
I, I->>, I*, I*->>, I=>, I=>>, onde cada elemento dessa tupla possui um mapeamento com
sua sintaxe, tambm conhecida como F-Linguagem (KIFER; LAUSEN; WU, 1995). A saber,
as estruturas semnticas so:
- U o domnio de I;
- U o mapeamento que denota a herana de classes em F-Logic;
 36

- U o mapeamento que denota quando um objeto membro de uma classe;

- IF um mapeamento dos programas em F-Logic;
- I e I->> so os mapeamentos de mtodos escalar e de conjunto de valores no
herdveis (objetos);
- I* e I*->> so os mapeamentos de mtodos escalar e de conjunto de valores ambos
herdveis (objetos);
- I=> e I=>> so os mapeamentos de mtodos escalar e de conjunto de valores de
assinatura (Classes).

Apenas os itens da tupla I=U, U, I=>, I=>> fazem parte dessa dissertao no que tange
a interpretar o diagrama de classes na UML.P e os tipos e predicados da PDDL. Para
relembrar, o smbolo U o mapeamento da sintaxe da f-molcula descrita na definio 3.1
item 1 e os smbolos I=> e I=>> so os mapeamentos da sintaxe descrita na definio 3.1 item
2c.
Com a explicao da F-estrutura da F-Logic, apresenta-se como a definio a seguir
utiliza a semntica para demonstrar a satisfao das F-Molculas (KIFER; LAUSEN; WU,
1995):

Definio 3.2 (Satisfao das F-Molculas) Seja I uma F-estrutura e G uma F-Molcula.
Escreve-se I G se e somente se as regras abaixo se mantm:
1. Quando uma F-Molcula G uma assero IS-A ento:
i) (Q) U (P), se G = Q :: P; ou
(Q) U (P), se G = Q : P
ii) Quando uma F-Molcula G uma molcula de objeto da forma O[a ; lista
separada de expresses de mtodo], ento para toda expresso de mtodo E em G,
as seguintes condies devem-se manter:
a) Se E um mtodo escalar no herdvel na forma ScalM@Q1, ... , Qk T, o
elemento I(k) ((ScalM))((O), (Q1), ... , (Qk)) deve ser definido e igual a
(T). As mesmas condies devem ser mantidas para o caso de E ser uma
expresso escalar herdvel, apenas necessrio mudar o I(k) por I(k)*.
b) Se E um mtodo de conjunto de valores no herdvel na forma SetM@R1, ...
, Rl ->> {S1, ... , Sm}, o conjunto I(l)->> ((SetM))((O), (R1), ... , (Rl)) deve
ser definido e conter o conjunto {(S1), ... , (Sm)}. As mesmas condies
 37

devem ser mantidas para o caso de E ser uma expresso de vrios valores
herdvel, apenas necessrio mudar o I(k)->> por I(k)*->>.
c) Se E um mtodo escalar de assinatura na forma ScalM@Q1, ... , Qn => {R1,
... , Ru}, ento o conjunto I(n)=> ((ScalM))((O), (Q1), ... , (Qn)) deve ser
definido e conter o conjunto {(R1), ... , (Ru)}.
d) Se E um mtodo de conjunto de valores de assinatura na forma SetM@V1,
... , Vs =>> {W1, ... , Wv}, ento o conjunto I(s)=>> ((SetM))((O), (V1), ... ,
(Vs)) deve ser definido e conter o conjunto {(W1), ... , (Wv)}.

De acordo com (KIFER; LAUSEN; WU, 1995) as condies da definio 3.2 denotam o
seguinte:
- A condio (i) apresenta (Q) como uma subclasse de (P) na forma G = Q :: P, ou
(Q) como um membro da classe (P) na forma G = Q : P. Como exemplo, pode-se
citar o domnio Logstica onde a classe Caminho uma subclasse da classe Veculo,
ou um objeto caminho Mercedes Benz que membro da classe Caminho;
- As condies (a) e (b) denotam que a funo de interpretao, para instncias, deve
ser definida com os tipos apropriados e permitir resultados compatveis com esses
tipos. Esses tipos compatveis fazem parte das assinaturas de mtodos nas condies
(c) e (d);
- As condies (c) e (d) denotam que o tipo do mtodo ScalM ou SetM devem ser
especificados pela expresso com os tipos associados a este mtodo pela funo I.

Nesta dissertao, a satisfao das f-molculas se dar pelas condies i), c) e d). Isso
porque se levar em considerao a assero IS-A e as expresses de mtodo para assinatura,
que so as condies que descrevem o domnio de Planejamento Automtico. J as outras
condies, seguem o especificado nas condies i), c) e d) para os problemas de Planejamento
Automtico.
Na F-Logic h importantes propriedades: a assero IS-A, a Igualdade e as Expresses de
Assinaturas. Assim ser apresentada cada uma delas de acordo com (KIFER; LAUSEN; WU,
1995).

Propriedades do Relacionamento IS-A

a) Reflexibilidade IS-A
 38

I  p :: p significa que p subclasse dele mesmo e isso decorre logicamente da F-

estrutura I;
b) Transitividade IS-A
Se I  p :: q e I  q :: r, ento, I  p :: r
Se p subclasse de q e q subclasse de r, ambos decorrendo logicamente da F-
estrutura I, ento, p tambm subclasse de r, decorrendo logicamente da mesma F-
estrutura I.
c) Relacionamento Acclico IS-A
Se I  p :: q e I  q :: p, ento, I  p q
Se p subclasse de q e q tambm subclasse de p, ambos decorrendo logicamente da
F-estrutura I, ento, p igual a q como conseqncia lgica da F-estrutura I.
d) Incluso de Subclasse
Se I  p : q e I  q :: r, ento, I  p : r
Se p membro da classe q e r superclasse de q, ambos decorrendo logicamente da F-
estrutura I, ento, p tambm membro da classe r como conseqncia lgica da F-
estrutura I.
As propriedades do Relacionamento IS-A utilizadas nessa dissertao so aquelas citadas
nos itens a), b) e c), que sero utilizadas nas provas dos teoremas no captulo 6. J o item d)
lida com a descrio de fatos em F-Logic, como j explicado, trata-se de problemas de
Planejamento Automtico e est fora do escopo deste trabalho que lida apenas com os
domnios de Planejamento Automtico.
Outras propriedades importantes na F-Logic so aquelas que determinam como representar
a igualdade:
Propriedades da Igualdade (Equality)
Os lemas abaixo servem para expressar as propriedades usuais da igualdade.
a) Propriedade Reflexiva
Para todo p U(F), I  p p;
b) Propriedade Simtrica
Se I  p q, ento, I  q p;
c) Propriedade Transitiva
Se I  p q e I  q r, ento, I  p r.
 39

As propriedades da Igualdade na F-Logic permitem que se utilize inferncias para tratar os

programas em F-Logic que lidam com igualdade. Para finalizar, existem outras propriedades,
tambm importantes, chamadas de expresses de assinaturas:

Propriedades das Expresses de Assinatura

O smbolo utilizado abaixo
> denota tanto => quanto =>>. O smbolo s significa uma
classe em F-Logic, o r e p denotam tambm classes em F-Logic, q1, ..., qk so parmetros de
classes em F-Logic e mthd denota tanto um mtodo escalar quanto um mtodo de conjunto de
valores. Dessa maneira, em F-Logic pode-se ter as seguintes regras de inferncia:
a) Herana de Tipos
Se I  p[mthd@q1, ..., qk
>s] e I  r :: p, ento, I  r[mthd@q1, ..., qk
>s];
Se p[mthd@q1, ..., qk
>s] conseqncia lgica de I e r :: p tambm conseqncia
lgica de I, ento, deduz-se que r[mthd@q1, ..., qk
>s] conseqncia lgica de I.
b) Restrio de Input
Se I  p[mthd@q1, ..., qi, ..., qk
>s] e I  qi :: qi, ento, I  r[mthd@q1, ... , qi, ...,
qk
>s];
Se p[mthd@q1, ..., qi, ..., qk
>s] conseqncia lgica de I e qi :: qi tambm
conseqncia lgica de I, ento, deduz-se que r[mthd@q1, ... , qi, ..., qk
>s]
conseqncia lgica de I.
c) Output Relaxado
Se I  p[mthd@q1, ..., qk
>r] e I  r :: s, ento, I  r[mthd@q1, ..., qk
>s];
Se p[mthd@q1, ..., qk
>r] conseqncia lgica de I e r :: s tambm conseqncia
lgica de I, ento, deduz-se que r[mthd@q1, ..., qk
>s] conseqncia lgica de I.

Com as propriedades supracitadas, possvel elaborar programas bem tipados em F-

Logic. Para ilustrar essa elaborao de F-Programas, considere o exemplo dado em (KIFER;
LAUSEN; WU, 1995):
empregado :: pessoa pessoa[nome@=>texto]
assistente :: estudante estudante[bebe@=>>cerveja; mantm@=>acordo]
assistente :: empregado empregado[salrio@=>inteiro; mantm@=>carro]
assistente[mantm@=>antigidade]
O exemplo acima mostra que a classe assistente acumula os seguintes f-tomos em sua f-
molcula:
 40

assistente[nome@=>texto; bebe@=>cerveja; mantm@=>(acordo, carro, antigidade)]

O mtodo da classe assistente mantm@=>antigidade, mas possui tambm como herana
duas assinaturas da classe estudante e empregado.
Como pode ser visto nesse exemplo, a F-Logic possui tanto sintaxe como semntica
robusta para tratar os modelos de engenharia do conhecimento baseada em Objetos.
As interpretaes propostas nessa dissertao para a UML.P e para a PDDL levam em
considerao essas propriedades da F-Logic, apesar de no cit-las diretamente nas
definies. Ou seja, respeitam-se essas propriedades para que se tenha F-Frmulas bem
tipadas.
O prximo captulo, utilizar a F-Logic para interpretar tipos e predicados da PDDL e vice
versa.
 41

CAPTULO 4

4. INTERPRETAO DA PDDL EM F-LOGIC

A PDDL utilizada para descrever o conhecimento sobre domnios de planejamento.

Entretanto, a PDDL uma linguagem semiformal. Como fora explicado no captulo 3, a F-
Logic ser utilizada para provar que a UML.P pode ser descrita em PDDL devido ao fato de
ela ser uma lgica formal correta e completa. Isso garante uma forma de se verificar a
descrio dos domnios caso haja contradies.
I
Nesse captulo haver definies para a Interpretao Correspondente de tipos e
predicados da descrio PDDL em classes e mtodos da descrio F-Logic da figura abaixo:

Figura 23 Interpretao Correspondente.

Essa estratgia de interpretao j foi provada em (KIFER; LAUSEN; WU, 1995) a partir
do Teorema 18.1, que demonstra os mapeamentos entre a F-Logic e a Lgica de Predicados,
onde esse teorema demonstra que factvel a interpretao de um para outro e vice versa. Em
(DECKER, 1998), h tambm um trabalho sobre como representar a F-Logic em Lgica de
Predicados (o smbolo na tabela 4 significa interpretado em) a partir de uma tabela
chamada de esquema de traduo para a F-Logic:

Tabela 4 Traduo de Modelos

Orientao a Objeto Lgica de Predicados
C::D Sub(C, D )
O:C instance(O, C)
O[M->>V] Method(O,M,V)
C[M=>>D] methodtype(C,M,D)
instance(O, C) method(O,M,V)
O:C[M->>V:D]
instance(V, D)
Fonte: DECKER, 1998

A tabela acima possui as seguintes tradues de F-Logic em Lgica de Predicados:

 42

- C::D um f-tomo e significa que C subclasse de D que pode ser traduzido na

Lgica de Predicados atravs do predicado Sub(C, D), que significa que C
subclasse de D;
- O::C um f-tomo e significa que O uma instncia (membro) de C que pode ser
traduzido na Lgica de Predicados atravs do predicado instance(O, C), que
significa que C instncia de D;
- O[M->>V] um f-tomo e significa que O possui o mtodo de dados M com
retorno V que pode ser traduzido na Lgica de Predicados atravs do predicado
Method(O,M,V), que significa que o predicado Method est definido para O com o
nome do mtodo M e o valor V;
- C[M=>>D] um f-tomo e significa que C possui o mtodo de assinatura M com
retorno D que pode ser traduzido na Lgica de Predicados atravs do predicado
methodtype(C,M,D), que significa que o predicado methodtype est definido para
C com o nome do tipo do mtodo M e o tipo D;
- Em F-Logic, os f-tomos O:C[M->>V:D] necessitam da seguinte traduo em
Lgica de Predicados: instance(O, C) & method(O,M,V) & instance(V, D).

Ainda na tabela acima, juntamente com o trabalho de (DECKER, 1998), discute-se a

representao de conhecimento para domnios especficos onde se demonstra um esquema de
traduo para a F-Logic desde a Lgica de Predicados. Direcionamento semelhante j foi
fornecido em (KIFER; LAUSEN; WU, 1995) onde se apresenta a F-Logic como uma
adaptao da Lgica de Predicados para objetos, chamando-a de Lgica de Primeira Ordem
para Objetos. Para essa dissertao, a utilidade desses Mapeamentos do teorema 18.1 em
(KIFER; LAUSEN; WU, 1995) torna possvel explorar a interpretao de modelos PDDL em
F-Logic e vice versa.
Como descrito em (KIFER; LAUSEN; WU, 1995), h uma tcnica de traduo da F-
Logic para a Lgica de Predicados chamada de flattening com predicados chamados de
wrapper, semelhante ao esquema de traduo descrito em (DECKER, 1998) e exposto na
tabela acima, para codificar diferentes tipos de especificao. Entretanto, nesta dissertao
optou-se por utilizar uma pequena variao dessa traduo descrita em (KIFER; LAUSEN;
WU, 1995) e em (LUDSCHER; YANG; KIFER, 1999). Essa pequena variao da traduo
no utiliza os wrapper predicates. Como exemplo dessa pequena variao, seja um f-tomo
do Mundo dos Blocos: Manipulador[Segurando@=>Bloco], esse f-tomo pode ser
 43

interpretado em Lgica de Predicados como Segurando(Manipulador, Bloco). E desse

I
modo que as definies a seguir devem denotar a Interpretao Correspondente .
Com essa finalidade, na seo 4.1 apresenta-se a Interpretao Correspondente da
descrio de tipos, predicados 1-rios, predicados 2-rios e predicados n-rios da PDDL e as
classes e mtodos da F-Logic.

4.1. Correspondncia de Interpretao PDDL e F-Logic

Nessa seo sero apresentadas algumas definies necessrias para mostrar como a
Interpretao Correspondente entre os elementos da PDDL, tais como, Tipos e Predicados e
as classes e mtodos da F-Logic. Vale informar que o smbolo utilizado para denotar a
I
Interpretao Correspondente nas definies .
I
A Interpretao Correspondente mostra uma interpretao possvel da PDDL em
F-Logic e vice versa. Nesse contexto, interpretao significa ler uma descrio PDDL e
descrev-la em F-Logic e vice versa.
No caso dos tipos e subtipos da PDDL existe uma interpretao em F-Logic baseada na
propriedade IS-A. Para exemplificar essa interpretao, pode-se citar o domnio Logstica que
j amplamente exposto nos trabalhos sobre PDDL, que possui os tipos Veculo, Pacote,
Lugar, Cidade, Caminho, Avio, Aeroporto e Localizao. A descrio em F-Logic para os
tipos do domnio Logstica :
Cidade :: , Veculo :: , Pacote ::  e Lugar :: . Essa descrio significa que cada Tipo
est contido no conjunto universal de Tipos ;
Caminho :: Veculo, Avio :: Veculo, Aeroporto :: Local, Localizao :: Local. Essa
descrio significa que cada subtipo um subconjunto de um dado Tipo. Abaixo, apresenta-se
a definio para a Interpretao Correspondente de Tipos e Subtipos da PDDL e das classes e
subclasses da F-Logic.

Definio 4.1 (Interpretao Correspondente de Tipos PDDL e Classes F-Logic) Os tipos da

PDDL descritos no elemento (:types e as Classes da F-Logic tm uma interpretao
I
correspondente da seguinte forma ti T Cli :: Cl.
 44

Com a definio 4.1, o domnio Mundo dos Blocos, por exemplo, pode ser interpretado de
I
PDDL em F-Logic e vice-versa.

Tabela 5 - Classes F-Logic em Tipos PDDL

F-Logic Classes Interpretao PDDL Tipos
Manipulador :: Cl. (:types
Bloco :: Cl. I Manipulador - T
Mesa :: Cl. Bloco - T
Mesa - T)

Em F-Logic a interpretao precisa satisfazer sua semntica a partir da F-estrutura I vista

no captulo 3. Por exemplo, considere o domnio Logstica e suponha as F-frmulas em:
- I = {Veculo, Local, Pacote, Cidade, Caminho :: Veculo, Avio :: Veculo,
Localizao :: Local, Aeroporto :: Local};
- Se G = {Caminho :: Veculo}, ento, IG ser satisfeita.
- Do contrrio, se G = {Caminho :: Local}, ento, I|
G, ou seja, IG no foi
satisfeita.
A definio 4.1 mostra como interpretar os tipos e subtipos da PDDL e as classes e
subclasses da F-Logic.
Tendo a definio de como interpretar os tipos PDDL e as Classes F-Logic, pode-se agora
interpretar os Predicados 1-rios da PDDL e seus correspondentes Mtodos F-Logic. Esses
predicados so aqueles que determinam a propriedade de um dado tipo, por exemplo,
(disponvel ?maq Mquina) que semanticamente descreve se uma dada Mquina est
disponvel ou no. Levando em considerao, esse exemplo, sua interpretao em F-Logic de
(disponvel ?maq Mquina) Mquina[disponvel@=> Booleano] onde Booleano o tipo
primitivo descrito em F-Logic para Verdadeiro ou Falso. A definio abaixo demonstra como
essa interpretao correspondente entre os predicados 1-rios da PDDL e mtodos da F-
Logic.

Definio 4.2 (Interpretao Correspondente de Predicados 1-rios PDDL e Mtodos F-

Logic) Os Predicados 1-rios da PDDL descritos no elemento (:predicates na forma
( P1i ?tipo tj) e Mtodos F-Logic tm uma interpretao correspondente da seguinte forma
I
i,j P1i (tj) i,j Clj [ScalMi@=> Booleano], onde:
 45

I
a) PDDL: i,j P1i (tj) em F-Logic: Clj G e ScalMi@=>{Booleano} E sendo que
E G onde E o conjunto de mtodos e Booleano um tipo primitivo para que a F-
estrutura I G seja satisfeita;
b) A interpretao Correspondente feita para cada termo envolvido das duas linguagens:
I I
P1i ScalMi, tj Clj e o tipo primitivo Booleano representa o verdadeiro ou
falso da Lgica de Predicados.

Seguindo a definio 4.2, pode-se interpretar os mtodos sem parmetros da F-Logic e os

predicados 1-rios em PDDL.
A tabela abaixo demonstra como interpretar o domnio Mundo dos Blocos de acordo com
a definio 4.2:
Tabela 6 - Mtodos escalar F-Logic em Predicados 1-rios PDDL
F-Logic Mtodos sem parmetros Interpretao PDDL Predicados 1-rios
Bloco[nadaSobre@=>Booleano]. (:predicates
Manipulador[garraVazia@=>Booleano]. I (nadaSobre ?tip Bloco)
(garraVazia ?tip Manipulador)
)

Assim, para todo predicado em PDDL na forma ( P1i ? tipo tj), que idntico a um
mtodo E na F-Logic, bem tipado de acordo com a F-estrutura I(n)=>, de modo que E G e I
G seja satisfeita. Logo, todas as interpretaes de PDDL em F-Logic devem satisfazer sua
F-estrutura.
Para esclarecer a definio 4.2 no que tange F-Logic, tenha o domnio Planta de
Manufatura onde o tipo Mquina foi interpretado de PDDL em F-Logic:
- G = {Mquina :: };
- E = {Mquina[disponvel@=>Booleano]};
- Portanto, E G para que I G seja satisfeita.
No caso dos Predicados 2-rios e n-rios, h a necessidade de definir um tipo do
predicado como o mais relevante entre os tipos para denomin-lo como Tipo mais Relevante
(TMR) do predicado. Houve uma abordagem semelhante a essa utilizada para interpretar a
PDDL em Objetos em (TONIDANDEL et al, 2006). A definio abaixo para obter o TMR
uma abordagem com a qual se pode ter o uso da Lgica de Primeira Ordem para Objetos
como vista em (KIFER; LAUSEN; WU, 1995), j que na Lgica de Predicados isso no
necessrio. Para a PDDL, o TMR no provoca nenhuma perda semntica.
 46

Definio 4.3 (TMR Tipo mais Relevante e Parmetros) Os Predicados da PDDL 2-rios na
forma ( P 2i ?tipo tj?tipo1tl) e n-rios na forma ( P 2i ?tipo tj?tipo1tl? ... ?tipontn) com n > 2
possuem apenas um tipo mais relevante da lista de tipos.
1. Para o Predicado 2-rio, h uma lista com 2 tipos onde o primeiro tipo o TMR:
Seja o predicado P 2i (tj, tl), onde o tipo tj o Tipo mais Relevante e tl o segundo tipo;
2. O tipo TMR de um predicado PDDL o id-termo Classe F-Logic;
3. Para o Predicado n-rio para n > 2, h uma lista com n tipos onde o primeiro tipo o
TMR e os demais, Parmetros:
Seja P ni (tj, tl,..., tn), o tipo tj o Tipo mais Relevante e tl,..., tn so Parmetros.

O Tipo mais relevante (TMR) foi definido como o tipo com o qual se ter o id-termo
Classe de cada assinatura de mtodo em F-Logic e os Parmetros so classes que esto nos
mtodos como parmetros. Para a lgica de objetos F-Logic, as aes e transformaes de
estados acontecem a partir dos objetos e, por isso, necessrio ter um tipo mais relevante que
seja responsvel por essas aes. Isso no tem relevncia para a PDDL.
A F-Logic uma Lgica de Primeira Ordem para Objetos e, assim, quando h mais de um
tipo na lista de tipos de um predicado, para interpretar esse predicado em F-Logic necessrio
assumir que o primeiro Tipo da lista de tipos o TMR e, assim, ele ser o id-termo Classe em
F-Logic.
Com a definio 4.3 tem-se, ento, o id-termo Classe escolhido em predicados com mais
de um tipo. Para completar a definio da Interpretao Correspondente de predicados n-rios
PDDL, com n > 2, e mtodos escalares F-Logic segue a definio abaixo:

Definio 4.4 (Interpretao Correspondente de Predicados n-rios PDDL e de mtodos

escalares com parmetros F-Logic) Os Predicados n-rios, com n > 2, da PDDL descritos no
elemento (:predicates na forma ( P ni ?tipoj tj?tipoltl,..., ?tipontn) e mtodos escalares com
parmetros da F-Logic na forma Clj[ScalMi@Ql,..., Qn=>Booleano] tm uma interpretao
correspondente da seguinte forma
I
i,j,l,...,n P ni (tj, tl,..., tn) i,j,l,...,n Clj [ScalMi@Ql,..., Qn=> Booleano], onde:
 47

I
a) PDDL: i,j,l,...,n P ni (tj, tl,..., tn) F-Logic:Clj G e ScalMi@Ql,...,Qn=>{Booleano}
E onde:
i) Em PDDL, o tipo tj o TMR;
ii) Em F-Logic, o id-termo classe Clj o TMR;
iii) Em PDDL, os tipos tl, ..., tn da Lista de Tipos dos predicados so Parmetros dos
mtodos escalares na F-Logic;
iv) Em F-Logic, o TMR e os Parmetros dos mtodos escalares so os tipos da Lista
de Tipos de predicados em PDDL:
Lista de Tipos LT = {TMR, {Parmetros}};
v) Do predicado n-rio da PDDL em mtodo escalar da F-Logic tem-se:
TMR[ P ni @Parmetros=>Booleano];
vi) Do mtodo escalar em F-Logic em predicado n-rio da PDDL tem-se:
ScalMi(TMR, Parmetros);
b) A interpretao Correspondente feita para cada termo envolvido das duas
I I I
linguagens: P ni ScalMi, tj Clj, tl,...,tn Ql,...,Qn e o tipo primitivo
Booleano representa o verdadeiro ou falso da Lgica de Predicados.

Para esclarecer a definio acima, seja o predicado (Acessvel ?tipo1 Veculo ?tipo2
?tipo3 Localizao) do domnio MetricVehicle. Pela definio 4.3, o tipo TMR Veculo
e ele o id-termo classe. Pela definio 4.4, o predicado Acessvel deve ser interpretado em
F-Logic como Veculo[Acessvel@Localizao, Localizao=>Booleano]. Em seguida,
pode-se demonstrar tambm a interpretao desse mtodo com parmetros da F-Logic
Veculo[Acessvel@Localizao, Localizao=>Booleano] em predicado n-rio da PDDL
(Acessvel ?tipo Veculo ?tipo1 ?tipo2 Localizao). Por exemplo, pela definio 4.3 sabe-
se que Veculo o TMR e os Parmetros so a classe Localizao, de modo que se tem a
lista de tipos LT={TMR,{Parmetros}}. Pela definio 4.4, o mtodo escalar com
parmetros ScalMi Acessvel interpretado como Predicado P ni . E, logo, a interpretao

P ni (LT), que nesse exemplo trata-se do predicado (Acessvel ?tipo Veculo ?tipo1 ?tipo2
Localizao). Dessa maneira, todos os predicados n-rios, com n > 2, e os mtodos com
parmetros da F-Logic tm uma Interpretao Correspondente.
 48

No caso dos Predicados 2-rios da PDDL na forma ( P 2i ?tipojtj ?tipoltl) pode-se

interpretar esse predicado de duas formas em F-Logic se a descrio de domnio em PDDL
for a nica fonte para a interpretao. Isso acontece porque em F-Logic, pela sua assinatura de
mtodo, no h como saber se haver tuplas de objeto ou apenas uma tupla.
Para um melhor esclarecimento sobre =>, no domnio Mundo dos Blocos tem-se que:
- o predicado 2-rio em PDDL (sobre ?tipBloco?tipoBloco) deve ser interpretado
adequadamente como Bloco[sobre@=>Bloco];
- Assim s pode existir estados onde apenas um bloco fica sobre outro bloco, isto ,
(sobre A B) em PDDL ou A[sobre@->B] em F-Logic. No poderia nesse caso
existir (sobre C B) em PDDL ou C[sobre@->B] em F-Logic;
- O smbolo => na F-Logic denota casos onde s pode haver uma tupla de objetos.
Na PDDL, ou isso tratado em uma constraint ou pelas descries das aes.

Para um melhor esclarecimento sobre =>>, no domnio Planta de Manufatura tem-se

que:
- O predicado 2-rio (tem?tipProduto?tipoAtributo) deve ser interpretado
adequadamente como Produto[tem @=>>Atributo];
- Assim, um produto pode ter mais de um atributo;
- Em PDDL tem-se os seguintes literais (tem Caneta Corpo) (tem Caneta Tampa) (tem
Caneta Refil) mostrando a idia de que um produto pode ter n atributos;
- Em F-Logic, a mesma descrio feita para a PDDL acima, Caneta[tem @->>
{Corpo, Tampa, Refil}] tambm mostrando a idia de que um produto pode ter n
atributos;
- O smbolo =>> na F-Logic denota casos onde h mais de uma tupla de objetos. Na
PDDL isso no levado em considerao.

Dessa maneira, fazendo a interpretao de Predicados 2-rios da PDDL apenas a partir das
informaes dos predicados, no h como evidenciar a interpretao adequada em F-Logic.
Poderia existir uma poltica de modelagem onde o engenheiro do conhecimento devesse criar
constraints em todos os casos que houvesse predicados como o predicado (sobre ?tip
Bloco?tipoBloco). Assim, quando no houver constraints, ento, a escolha do smbolo
=>>.
 49

Portanto, pela definio abaixo, optou-se pela Interpretao Correspondente dos

Predicados 2-rios da descrio de domnio da PDDL e mtodos de conjunto de valores da F-
Logic que fornecesse maior abrangncia ao seu uso. Assim, escolheu-se o smbolo =>>, que
significa uma ou mais tuplas de objetos.

Definio 4.5 (Interpretao Correspondente e Abrangente de Predicados 2-rios PDDL e

mtodos F-Logic) Os Predicados 2-rios da PDDL da descrio de domnio na forma
( P 2i ?tipojtj ?tipoltl) e o mtodo F-Logic na forma Clj [SetMi@=>> Cll] tm uma
interpretao correspondente da seguinte forma
I
i,j,l P 2i (tj, tl) i,j,l Clj [SetMi@=>> Cll], onde:
a) Como tj o TMR e s existe o segundo tipo tl na lista de tipos, ento, trata-se de um
predicado 2-rio;
b) Do predicado 2-rio PDDL em mtodo de conjunto de valores F-Logic,
TMR[Predicado@=>>Segundo Tipo];
c) Do mtodo de conjunto de valores F-Logic em predicado 2-rio PDDL
SetMi(id-termo classe, Cll);
d) A interpretao Correspondente feita para cada termo envolvido das duas linguagens:
I I I
P 2i SetMi, tj Clj e tl Ql .

Com a definio 4.5 acima, mostra-se que a partir da descrio de domnio da PDDL
optou-se por interpretar os predicados 2-rios de forma abrangente, ou seja, fornecendo a todo
predicado 2-rio a possibilidade de lidar com mais de uma tupla de objetos na F-Logic.
Justamente porque na PDDL os seus predicados no possuem essa informao.
Do contrrio, como j explanado, poderia utilizar-se o elemento (:contraints para suprir o
modelo PDDL com essa informao. Por exemplo, sabe-se que no domnio Mundo dos
Blocos, um bloco somente pode ficar sobre outro Bloco, ou em cima da mesa, ou ainda na
garra do rob. Para tratar isso como uma constraint abaixo segue a descrio em PDDL:
(:constraints
(and
(forall (?blo1 - Block ?blo2 - Block ?blo - Block)
(always
(imply(and(on ?blo ?blo1)(on ?blo ?blo2))(= ?blo1 ?blo2)
))))
 50

Essa constraint auxiliaria como interpretar predicados 2-rios em PDDL para o smbolo
=> em F-Logic.
Portanto, os predicados 2-rios da PDDL sero interpretados conforme a definio 4.5 da
Interpretao Correspondente com o smbolo =>> que lhe fornece maior abrangncia na F-
Logic. Lembrando que os predicados na PDDL no possuem esse tipo de informao.
Dessa forma, cumpre-se as interpretaes de classes, mtodos escalares e mtodos de
conjunto de valores da F-Logic e os tipos, predicados 1-rios, 2-rios e n-rios da PDDL. Para
exemplificar as ltimas definies a tabela abaixo mostra algumas dessas interpretaes:

Tabela 7 - Mtodos F-Logic em Predicados 2-rios e n-rio PDDL

F-Logic Mtodos Interpretao PDDL Predicados 2-rios e n-rios
Bloco[sobre@=>> Bloco]. (:predicates
Bloco[encima@=>> Mesa]. (sobre ?tip ?tip1 Bloco)
I
Rob[segurando@Bloco, Mesa => Booleano]. (encima ?tip Bloco ?tip1 Mesa)
(segurando ?tip Robo ?tip Bloco
?tip1 Mesa))
)

No domnio Mundo dos Blocos da tabela acima, para explicar uma das interpretaes da
tabela, colocou-se um rob para organizar blocos em mais de uma mesa. Por isso, o mtodo
Robo[segurando@Bloco, Mesa => Booleano]. Da a sua interpretao em um predicado n-
rio segurando(Robo, Bloco, Mesa) ou em PDDL (segurando ?tip Robo ?tip Bloco ?tip1
Mesa)). As interpretaes ora apresentadas na tabela esto de acordo com as ltimas
definies que completam o como interpretar classes, mtodos escalar e de conjunto de
valores da F-Logic, alm dos tipos, predicados 1-rios, 2-rios e n-rios da PDDL.
Prximo captulo, ser discutida a interpretao de modelos UML.P em F-Logic
apresentada em (GOMES, 2008) para extrao de conhecimento semelhante discusso
apresentada aqui sobre PDDL e F-Logic
 51

CAPTULO 5

5. INTERPRETAO DA UML.P EM F-LOGIC

Nesse captulo, ser apresentada a interpretao do diagrama de classes da UML.P em

classes e mtodos da descrio F-Logic de acordo com (GOMES, 2008). Dessa Interpretao
Completa em F-Logic do diagrama de classes da UML.P, criar-se- uma interpretao
chamada IFR de forma reduzida que est contida na Interpretao Completa. Essa
interpretao IFR de forma reduzida ser utilizada para demonstrar a equivalncia com a
Interpretao Completa entre a F-Logic e PDDL.

Figura 24 Interpretao Completa da UML.P em F-Logic e sua Interpretao Forma Reduzida IFR.

Vale relembrar que os trabalhos em (RAMALHO; ROBIN, 2004) e em (RAMALHO;

ROBIN; SCHIEL, 2004) possuem o diagrama de classes da UML interpretado em F-Logic.
Esses trabalhos motivaram a Interpretao Completa criada em (GOMES, 2008) e a figura
acima apresenta o subconjunto dessa Interpretao Completa, que a Interpretao IFR de
forma reduzida.
Atravs das prximas sees sero demonstradas as interpretaes Completa e Forma
Reduzida.

5.1. Interpretao Completa UML.P em F-Logic

As assinaturas auxiliares foram interpretadas em (GOMES, 2008) para fornecer suporte

aos conceitos da UML.P, tais como, tipos primitivos (booleano, inteiro e nulo), limites de
conjunto, mutabilidade, tipo da associao, tipo do esteretipo, a caracterstica da associao
e a classe fundamental, que a classe universal que contm todas as classes.
 52

Tabela 8 Assinatura Auxiliares para Modelos UML.P

Assinaturas Auxiliares Descrio
tipoPrimDado[existe => booleano; Determina os tipos de dados primrios que
existe *-> verdadeiro]
sero utilizados na interpretao da UML.P.
Os tipos de dados sero: Inteiro, booleano,
entre outros.
limConjunto [existe => booleano; Determina os limites de qualquer conjunto
existe *-> verdadeiro]
dado na UML.P.
mutabilidade[existe => booleano; Determina a mutabilidade das associaes.
existe *-> verdadeiro]
assocTipoEx[existe => booleano; existe Determina o tipo da associao.
*-> verdadeiro]
tipoEstereotipo[existe => booleano; Determina o tipo do esteretipo das classes.
existe *-> verdadeiro]
caracteristica[existe => booleano; Determina as caractersticas das associaes.
existe *-> verdadeiro]
classeFund[existe => booleano ; Determina a classe fundamental que
estereotipo => tipoEstereotipo; existe
*-> verdadeiro] estruturar todas as classes dos domnios.

Fonte: Gomes, 2008

Qualquer diagrama de classes projetado para um domnio em questo pode utilizar as

assinaturas auxiliares para enriquecer o Modelo. Essa propriedade da Interpretao Completa
realizada em (GOMES, 2008) adaptou-se ao considerar todos os elementos visuais do
diagrama de classes.
Na tabela a seguir h a interpretao F-Logic para o elemento Classe da UML.P.

Tabela 9 Interpretao de classes em F-Logic

Simbologia Esteretipo Interpretao F-Logic
UML.P
classe::classeFund
<> classe[ estereotipo *-> ester_nulo]
classe::classeFund
<Agente> ester_Agente:tipoEstereotipo classe[ estereotipo *->
Ester_Agente]
Classe::classeFund
<Utilitrio> ester_Utilitario:tipoEstereotipo classe[ estereotipo *->
Ester_Utilitario]
Fonte: GOMES, 2008

Essa interpretao torna possvel descrever em F-Logic todas as classes projetadas para
um determinado domnio.
Com a interpretao F-Logic para classes, agora apresenta-se como interpretar os atributos
de uma classe UML.P assim como segue na tabela a seguir:
 53

Tabela 10 Interpretao de atributos

Simbologia UML.P Interpretao F-Logic
Classe[attr => A; attr@limConjunto => inteiro;
attr@lim_Inferior *-> 1; attr@lim_Superior *-> 1;
attr@caracteristica => mutabilidade; attr@atrib_carac *->
mut_Alteravel]

Classe[attr@A0, , An => B; attr@limConjunto => inteiro;

attr@lim_Inferior *-> 1; attr@lim_Superior *-> 1;
attr@caracteristica => mutabilidade; attr@atrib_carac *->
mut_Alteravel]

Fonte: GOMES, 2008

Como apresentado na tabela acima, h dois tipos de atributos interpretados em F-Logic:

atributo com parmetros e sem parmetros. A tabela acima mostra o f-tomo Classe[attr
@=>A] onde A um tipo primitivo.
Aps apresentar as interpretaes F-Logic para classe e atributos, sero mostradas as
interpretaes para associaes de classes tal como segue na prxima tabela.

Tabela 11 Interpretao de Associao de Classes

Associao de Classes: Simples e Agregao

Interpretao F-Logic
P/ Vj,t = 1
classeA[associao_classeB => mutabilidade; associao_classeB *-> <mutabilidade>;
associao_classeB_fimB => classeB;
associao_classeB_fimB@limConjunto => inteiro;
associao_classeB_fimB@lim_Inferior *-> <Vs>;
associao_classeB_fimB@lim_Superior *-> <Vt>;
associao_classeB_fimB@caracteristica => assocTipoEx;
associao_classeB_fimB@assoc_TipoEx *-> <AssociaoTipo>]
P/ Vj,t > 1
As assinaturas sero idnticas as mostradas acima, porm o mtodo
associao_classeX_fimX=>classeX ter o smbolo => substitudo por =>>.

Associao de Classes: Composio

 54

Interpretao F-Logic

A interpretao para a ClasseA ser idntica ao primeiro e segundo exemplo desta tabela,
observando a navegabilidade da associao e ao tipo de associao, e a ClasseB ter sua
interpretao da seguinte maneira:
classeB[associao_classeA => mutabilidade;
associao_classeA *-> <mutabilidade>;
associao_classeA_fimA => classeA;
associao_classeA_fimA@limConjunto => inteiro;
associao_classeA_fimA@lim_Inferior *-> 1;
associao_classeA_fimA@lim_Superior *-> 1;
associao_classeA_fimA@caracteristica => assocTipoEx;
associao_classeA_fimA@assoc_TipoEx *-> assoc_Composicao]
Fonte: GOMES, 2008

Dadas as interpretaes expostas nas tabelas acima, a seguir as F-Molculas com seus F-
tomos:
ASSINATURAS AUXILIARES (FIXO)

tipoPrimDado[existe => booleano; existe *-> verdadeiro]

limConjunto[existe => booleano; existe *-> verdadeiro]
mutabilidade[existe => booleano; existe *-> verdadeiro]
assocTipoEx[existe => booleano; existe *-> verdadeiro]
tipoEstereotipo[existe => booleano; existe *-> verdadeiro]
caracteristica[existe => booleano; existe *-> verdadeiro]
classeFund[existe => booleano ; estereotipo => tipoEstereotipo; existe *->
verdadeiro].

As assinaturas auxiliares possibilitam que os diagramas de classes da UML.P sejam

interpretados em F-Logic tendo um F-tomo para cada elemento do diagrama. Por exemplo,
h um F-tomo para os tipos primitivos de dados, tais como, booleano e inteiro. H um F-
tomo para definir as condies limtrofes da multiplicidade das associaes de classes. Um
F-tomo para a mutabilidade. F-tomos para o tipo de associao, o tipo de esteretipo da
classe, a caracterstica e a classe universal.
Aps mostrar a padronizao das assinaturas auxiliares em qualquer diagrama de classes,
leva-se em considerao o domnio Mundo dos Blocos para demonstrar as interpretaes F-
Logic:
 55

Figura 25 Interpretao do domnio Mundo dos Blocos.

Generalizaes de Classes

Bloco::classeFund
Mesa::classeFund
Manipulador::classeFund

As generalizaes de classes expostas acima como F-tomos, todas elas so subclasses da

classeFund, que a classe universal. Aps demonstrar como descrever a criao das classes,
abaixo seguem as descries de assinaturas de classes:

Assinaturas de Classes

ester_agente : tipoEstereotipo

No F-tomo acima, descreve-se que o esteretipo Agente pertence classe Tipo de

Esteretipo, onde objetos Agentes so aqueles que operam mudanas no domnio. Abaixo, o
F-tomo esteretipo da classe Manipulador mostra-se como Agente no domnio Mundo dos
Blocos.

Manipulador[estereotipo@*->ester_Agente;
garraVazia@=> Booleano;

No F-tomo acima, garraVazia um mtodo escalar com o tipo primitivo Booleano. Para
a classe Manipulador h duas situaes: sua garra est vazia ou no. Nos trs F-tomos logo
 56

abaixo, h a descrio sobre as condies limtrofes do mtodo garra vazia e os dois ltimos
F-tomos lidam com a mutabilidade e seu tipo para a classe Manipulador:

garraVazia@limConjunto => inteiro;

garraVazia@lim_Inferior *-> 1;
garraVazia@lim_Superior *-> 1;
garraVazia@caracteristica=>mutabilidade;
garraVazia@atrib_carac*->mut_Estatico]

A classe Bloco abaixo possui na sua descrio o formato semelhante ao da classe

Manipulador, exceto o F-tomo que descreve Agente. Pois Bloco no opera mudanas no
domnio.

Bloco[nadaSobre@=> Booleano;
nadaSobre@limConjunto => inteiro;
nadaSobre@lim_Inferior *-> 1;
nadaSobre@lim_Superior *-> 1;
nadaSobre@caracteristica=>mutabilidade;
nadaSobre@atrib_carac*->mut_Estatico]

Dessa forma, foram apresentados os F-tomos pertinentes a descrio dos atributos de

classes, ou mtodos em F-Logic. Abaixo esto os F-tomos pertinentes s associaes de
classes:

Assinatura das Associaes

Manipulador[segurando_Bloco@=>mutabilidade;
segurando_Bloco@*->mut_Estatico;
segurando_Bloco_segurando@=>Bloco;

Os F-tomos acima so F-tomos compactos, pois, possuem na sua descrio as seguintes

estruturas: Manipulador [nA_nCEO @ => mutabilidade] no primeiro f-tomo e Manipulador
[nA_nCEO_nEOA @ => nCEO] no segundo f-tomo, onde nA nome da associao, nCEO
o nome da classe de extremidade oposta e nEOA o nome da extremidade oposta da
associao de acordo com (GOMES, 2008). Abaixo, os primeiros trs F-tomos lidam com as
condies limtrofes da multiplicidade da associao entre Manipulador e Bloco. Os dois
ltimos F-tomos dizem respeito associao.

segurando_Bloco_segurando@limConjunto=>inteiro;
segurando_Bloco_segurando@lim_Inferior*->1;
segurando_Bloco_segurando@lim_Superior*->*;
segurando_Bloco_segurando@caracteristica=>assocTipoEx;
segurando_Bloco_segurando@assoc_TipoEx*->assoc_Simples]
 57

Abaixo esto os F-tomos descritos para a classe Bloco. Como pode ser visto, essa
descrio bastante semelhante descrio realizada acima para classe Manipulador. bvio
que se trata de uma descrio maior porque ela lida com duas associaes para a classe em
questo:

Bloco[sobre_Bloco@=>mutabilidade;
sobre_Bloco_sobre@=>Bloco;
sobre_Bloco_sobre@limConjunto=>inteiro;
sobre_Bloco_sobre@caracteristica=>assocTipoEx;
sobre_Bloco*->mut_Estatico;
sobre_Bloco_sobre@lim_Inferior*->1;
sobre_Bloco_sobre@lim_Superior*->1;
sobre_Bloco_sobre@assoc_TipoEx*->assoc_Simples;
sobreMesa_Mesa@=>mutabilidade;
sobreMesa_Bloco_sobreMesa@=>Bloco;
sobreMesa_Bloco_sobreMesa@limConjunto=>inteiro;
sobreMesa_Bloco_sobreMesa@caracteristica=>assocTipoEx;
sobreMesa_Bloco@*->mut_Estatico;
sobreMesa_Bloco_sobreMesa@lim_Inferior*->1;
sobreMesa_Bloco_sobreMesa@lim_Superior*->1;
sobreMesa_Bloco_sobreMesa@assoc_TipoEx*->assoc_Simples]

Com os exemplos de descrio apresentados anteriormente para o domnio Mundo dos

Blocos, buscou-se esclarecer o uso das interpretaes postas em tabelas de acordo com
(GOMES, 2008).
Como fora relatado no incio desse captulo, a descrio em F-Logic da Interpretao
Completa do diagrama de classes UML.P possui muitos F-tomos que apropriadamente esto
adaptados para descrever cada elemento do diagrama de classes. Entretanto, tambm fora
relatado no incio desse captulo que ser criada uma Interpretao IFR de Forma Reduzida
que ter alguns F-tomos da Interpretao Completa.

Definio 5.1 (IFR Interpretao F-Logic Forma Reduzida) A Forma Reduzida um

conjunto de F-tomos extrados da Interpretao Completa em F-Logic de acordo com as
seguintes asseres:
1. A interpretao Completa em F-Logic uma frmula composta de F-tomos;
2. A interpretao Forma Reduzida uma frmula composta de F-tomos;
3. De tal maneira que F na teoria da F-Logic;
4. Assim, a Forma Reduzida possui os seguintes F-tomos:
a. Classe Classe::classeFund;
b. Atributo Simples Classe[attr@=> A] onde A o tipo primitivo Booleano;
 58

c. Atributo com parmetros Classe[attr@A0, , An@=> B] onde B o tipo primitivo

Booleano e A0, , An so parmetros;
d. Associao de Classes Classe[associao_classeB_fimB@=> classeB]:
i. um F-tomo compacto;
ii. Sua forma estendida : Classe[associao@=> classeB] Classe[fimB@=>
classeB] Classe[associao_classeB_fimB@=>classeB];
e. O F-tomo escolhido da forma estendida Classe[associao@=>classeB].

Com a definio acima da Interpretao IFR de Forma Reduzida, pode-se demonstrar que
apropriadamente ela um subconjunto da Interpretao Completa.

Teorema 5.1 (Da Interpretao Completa deriva-se a Forma Reduzida) A Interpretao F-

Logic Completa do diagrama de classes possui n F-tomos.
Seja IFR a Interpretao Forma Reduzida levando em considerao os seus F-tomos
da definio 5.1, IFR Interpretao Completa.
Prova
1. Seja a definio 5.1 itens a), b), c) e e), h 4 F-tomos para a descrio da IFR;
Onde IFR={ f-atom1 f-atom2 f-atom3 f-atom4}.
2. Os 4 tipos de f-tomos so:
a. f-atom1 = todas as classes na forma Classe :: classeFund;
b. f-atom2 = todos os atributos simples das classes na forma
Classe[attr@=>A] onde A o tipo primitivo Booleano;
c. f-atom3 = todos os atributos com parmetros das classes na forma
Classe[attr@A0, , An@=>B] onde B o tipo primitivo Booleano e
A0, , An so parmetros de classes;
d. f-atom4 = todas as associaes de classes na forma
Classe[associao@=>classeB];
3. A Interpretao F-Logic Completa possui uma conjuno de n tipos de F-tomos;
4. A Interpretao IFR de Forma Reduzida possui uma conjuno de 4 tipos de F-
tomos contidos na conjuno de n tipos de F-tomos da Interpretao Completa;
5. Assim, obtm-se os 4 tipos de F-tomos da Interpretao Completa:
f atom1 f atom 2 ... f atomn 2 f atomn 1 f atomn
f atom1 f atom 2 f atom3 f atom 4
 59

6. IFR Interpretao Completa

Com o Teorema 5.1 demonstra-se como obter a IFR da descrio de F-tomos realizada
em (GOMES, 2008). Tambm importante citar que a interpretao IFR de forma reduzida
so 4 tipos de f-tomos que possuem equivalncia com os f-tomos da Interpretao
Correspondente da PDDL e F-Logic, que foi apresentada no captulo 4. Esses 4 tipos de f-
tomos da IFR so o f-tomo de classe, o f-tomo de Associao, o f-tomo de Atributo
simples e o f-tomo de Atributo com parmetros. Esses f-tomos so equivalentes
respectivamente ao f-tomo de Tipo, o f-tomo de Predicado 2-rio, o f-tomo de Predicado
1-rio e o f-tomo de Predicado n-rio da Interpretao Correspondente.
No prximo captulo sero demonstradas as equivalncias entre F-tomos da UML.P e F-
tomos da PDDL, alm de demonstrar a equivalncia do modelo UML.P com o modelo
PDDL.
 60

CAPTULO 6

6. INTERPRETAO DA UML.P EM PDDL UTILIZANDO A F-LOGIC

No captulo 4 apresentou-se como interpretar tipos, predicados 1-rios, predicados 2-rios

e predicados n-rios da PDDL em classes e mtodos da F-Logic e vice versa. J no captulo 5
utilizou-se da Interpretao Completa do Diagrama de Classes da UML.P em classes e
mtodos da F-Logic realizada em (GOMES, 2008). E como se trata de um trabalho sobre
extrao de conhecimento h n tipos de F-tomos descritos nessa Interpretao de modo a
apropriadamente representar o diagrama de classes. Entretanto, para essa dissertao o
objetivo demonstrar que classes, atributos de classes e associaes na UML.P podem ser
interpretados em tipos e predicados da PDDL. Como j fora citado, UML.P e PDDL so
linguagens semiformais e, por isso, escolheu-se a F-Logic. Da, no mesmo captulo 5, obteve-
se 4 tipos de F-tomos da Interpretao Completa da UML.P correspondentes aos F-tomos
da Interpretao Correspondente do captulo 4, chamando-a de interpretao IFR de forma
reduzida.
Dessa forma, pretende-se neste captulo provar a interpretao de elementos do modelo
UML.P em elementos do modelo PDDL de acordo com a figura a seguir:

Figura 26 Equivalncia de Modelos.

A figura acima representa a Interpretao Correspondente do captulo 4, a Interpretao

Completa de acordo com (GOMES, 2008), que por inferncia criou-se a IFR, Interpretao de
Forma Reduzida, ambas do captulo 5. A IFR tem elementos que possuem equivalncia com
 61

os elementos da Interpretao Correspondente, que ser demonstrada nesse captulo. E para

finalizar, pretende-se demonstrar que os elementos dos Modelos PDDL so conseqncia
lgica dos elementos dos Modelos UML.P de acordo com a figura abaixo:

Figura 27 Modelos UML.P e Modelos PDDL.

Portanto, atravs das prximas sees, haver demonstraes sobre as provas de

equivalncia de modelos.

6.1. Estudo da Interpretao da UML.P para PDDL atravs da F-Logic

Esta seo pe em discusso o objetivo desse trabalho que apresentar demonstraes da

interpretao da UML.P em PDDL. Entretanto, foi necessrio definir um conjunto de
elementos para tratar domnios de Planejamento Automtico. Esse conjunto de elementos
possui Classes na linguagem UML.P e Tipos na linguagem PDDL, Associaes e Atributos
na linguagem UML.P e Predicados na linguagem PDDL.
Para tanto, houve a necessidade de produzir a seguinte definio com o objetivo de
apresentar exatamente os elementos que devem ser tratados nessa seo.

Definio 6.1 (Suposio Restritiva de Declarao de Domnios) A Suposio Restritiva de

Declarao de Domnios (SRDD) define os elementos que os modelos em UML.P e PDDL
possuem em comum para Domnios de Planejamento Automtico.
i. Seja o mesmo domnio U modelado tanto em UML.P quanto em PDDL;
ii. Sendo que em UML.P existe um conjunto de classes chamado Cl ={Cl1, Cl2, ...,
Cln} onde cada classe de Cl possui nomenclatura idntica a um tipo de T em
PDDL do conjunto de tipos T ={T1, T2, ..., Tn} formando uma bijeo;
 62

iii. Existe em UML.P um conjunto de atributos At ={At1, At2, ..., Ati}, onde cada
atributo de At possui nomenclatura idntica a um predicado 1-rio de P1 em

PDDL do conjunto P1 ={ P11 , P12 , ..., P1i } formando uma bijeo;

iv. Existe em UML.P um conjunto de associaes As ={As1, As2, ..., Asj}, onde cada
associao de As possui nomenclatura idntica a um predicado 2-rio de P 2 em

PDDL do conjunto P 2 ={ P12 , P 22 , ..., P 2j } formando uma bijeo;

v. Existe em UML.P um conjunto de atributos com parmetros Atp ={Atp1, Atp2, ...,
Atpi}, onde cada atributo com parmetros de Atp possui nomenclatura idntica a
um predicado n-rio de P n em PDDL do conjunto P n ={ P 1n , P n2 , ..., P ni }
formando uma bijeo;

Para esclarecer o objetivo da SRDD definida acima, a figura abaixo apresenta que
considerando a SRDD, h para o mesmo Domnio U, dois modelos um em UML.P e outro
em PDDL. Sendo que esses dois modelos possuem quatro conjuntos e o essencial que um
modelo em UML.P com esses quatro conjuntos possui a mesma nomenclatura com os outros
quatro conjuntos do modelo em PDDL, formando ambos bijees.

Figura 28 Nomenclaturas idnticas nos modelos UML.P e PDDL.

Tomando o domnio Mundo dos Blocos, a SRDD restringe que em UML.P haja o
elemento visual classe com nomenclatura Bloco e restringe que em PDDL haja a descrio
de tipo com nomenclatura Bloco. Qualquer variao sobre isso j no permite fazer a
correspondncia de modelos.
 63

Outro fato importante na correspondncia de modelos UML.P e PDDL, foi o

levantamento de algumas propriedades visveis a partir da interpretao em F-Logic. Pois,
para um predicado 2-rio em PDDL no importa a multiplicidade. J a UML.P com sua
associao importa muito a multiplicidade. Quando os modelos so interpretados em F-Logic,
na UML.P h distino clara entre uma tupla de objetos na descrio F-Logic com o smbolo
=> e mais de uma tupla de objetos na descrio F-Logic com o smbolo =>>. Entretanto,
como foi visto no captulo 4, para a PDDL no faz diferena e por isso na Interpretao
Correspondente, um predicado 2-rio da PDDL interpretado com o smbolo =>> em F-
Logic, porque garante uma abrangncia maior PDDL. Porm, para a correspondncia entre
a UML.P e a PDDL, foi necessrio aplicar um relaxamento na associao em UML.P
interpretada em F-Logic para garantir a equivalncia com o predicado 2-rio em PDDL.

Definio 6.2 (F-tomo de associao UML.P relaxado) Todo o f-tomo obtido de modelos
UML.P a partir da Interpretao Completa e Interpretao IFR de forma reduzida deve ser
relaxado substituindo o smbolo => para o smbolo =>>.

A definio acima permite que os f-tomos de associao de classes em UML.P sejam

equivalentes aos f-tomos de predicados 2-rios em PDDL. Entretanto, isso j demonstra uma
perda semntica na traduo de modelos de UML.P para PDDL.
Para o desenvolvimento desse trabalho, a definio 6.2 e a SRDD juntamente das
Interpretaes Completa, IFR e Correspondente permitem mostrar para o mesmo domnio,
que um modelo PDDL pode ser obtido automaticamente a partir de um modelo em UML.P,
que a proposta da ferramenta de EC, chamada itSIMPLE.
Por exemplo, na tabela a seguir, para o domnio Mundo dos Blocos, tem-se na primeira
coluna o diagrama de classes da UML.P, na ltima coluna apresenta-se a descrio em PDDL
e, em comum a essas colunas a declarao em F-Logic.
 64

Tabela 12 Interseco de F-Molculas entre UML.P e PDDL.

UML.P F-Logic em comum s PDDL
duas Linguagens
(define(domain undoDosBlocos)
Manipulador ::  (:requirements : typing)
Bloco ::  (:types
Mesa ::  Manipulador object
Bloco object
Bloco[sobre @=>> Bloco, naMesa Mesa object )
@=>> Mesa, nadaSobre @=> (:predicates
booleano] (sobre ?blo - Bloco ?blo1 - Bloco)
(segurando ?man - Manipulador
Manipulador[segurando @=>> ?blo - Bloco)
Bloco, garraVazia @=> Booleano] (naMesa ?blo - Bloco ?mes - Mesa)
(garraVazia ?man - Manipulador)
(nadaSobre ?blo Bloco) )

A tabela acima mostra como classes e tipos, associaes, atributos e predicados so ambos
interpretados facilmente em uma lgica correta e completa como a F-Logic. Dessa maneira,
comprovando interpretaes como essa, alcana-se o objetivo desse trabalho que validar as
modelagens em UML.P para PDDL.
Dessa maneira, demonstra-se atravs dos teoremas abaixo que os f-tomos da UML.P, na
Interpretao IFR de Forma Reduzida, so equivalentes aos f-tomos da Interpretao
Correspondente da PDDL em F-Logic.

Teorema 6.1 (Equivalncia de f-tomo de classe UML.P e f-tomo de tipo PDDL)

Considerando a SRDD e sendo um f-tomo IS-A de subclasse e classe da UML.P e um f-
tomo IS-A de subtipo e tipo da PDDL, tem-se que , se a nomenclatura de Cli e Cl
so idnticas s de Ti e T.
Prova
De acordo com a SRDD, a nomenclatura de classe idntica a de Tipo. Pela
Interpretao Completa e a Interpretao IFR de forma reduzida tem-se o f-tomo de
classe e subclasse na forma Cli :: Cl da F-Logic. Pela Interpretao Correspondente
tem-se o f-tomo de tipo e subtipo na forma Ti :: T da F-Logic. Para que os f-tomos
sejam iguais na F-Logic, utiliza-se a propriedade acclica da IS-A de acordo com a
semntica da F-estrutura I:
Se I  Cl :: T e I  T :: Cl , ento, I  Cl T
Se I  Cli :: Ti e I  Ti :: Cli , ento, I  Cli Ti
Pela propriedade da igualdade (equality) da F-logic, tem-se a simetria:
 65

Se I  Cl T, ento, I  T Cl
Se I  Cli Ti, ento, I  Ti Cli
Como o f-tomo = Cli ::Cl e o f-tomo = Ti ::T, portanto,

Com o teorema 6.1 tem-se que qualquer f-tomo de classe e sua subclasse em UML.P tem
equivalncia com um f-tomo de tipo e seu subtipo em PDDL de acordo com a SRDD.
J no prximo teorema busca-se provar que todos os f-tomos IS-A para classes do
modelo UML.P so equivalentes aos f-tomos IS-A para tipos do modelo PDDL.

Teorema 6.2 (Equivalncia de Modelos para f-tomos IS-A) Considerando a SRDD e sendo a
frmula UML.P, que possui todos os f-tomos IS-A para o modelo UML.P e a frmula PDDL,
que possui todos os f-tomos IS-A para o modelo PDDL, tem-se que UML.P PDDL, se
todas as classes de Cl tm nomenclatura idntica aos tipos de T.
Prova
De acordo com a SRDD, a nomenclatura das classes do conjunto Cl idntica a dos
tipos do conjunto T, formando uma bijetora. O fato de ser uma bijetora supe-se que
haja uma funo f e sua inversa f -1, de modo que f :Cl T se e somente se f -1:T Cl.
Da, pelo teorema 6.1 para toda nomenclatura idntica entre Cl e T demonstra-se a
equivalncia entre f-tomos. Como Cl e T formam uma bijeo, eles tm a mesma
cardinalidade, ento, os modelos so equivalentes no que tange s classes e aos tipos
UML.P PDDL

Com o teorema 6.2, todas as classes da UML.P e tipos da PDDL foram interpretados em
F-Logic, de modo que todos eles tenham a forma de f-tomos IS-A.
A seguir, o teorema demonstrar a equivalncia entre um f-tomo de associao de classe
e um f-tomo de predicado 2-rio.

Teorema 6.3 (Equivalncia de f-tomo de associao UML.P e f-tomo de predicado 2-rio

PDDL) Considerando a SRDD, e sendo um f-tomo de associao de classe de As da
UML.P e um f-tomo de predicado 2-rio de P 2 da PDDL, tem-se que , se a

nomenclatura de associao de classe Asj idntica de predicado 2-rio P 2j .

Prova
 66

De acordo com a SRDD, a nomenclatura de associao de classe idntica a de

predicado 2-rio. Pela Interpretao Completa e a Interpretao IFR de forma
reduzida tem-se o f-tomo de associao de classe na forma Cli[Asj@=>Cll] da F-
Logic. Pela definio 6.2, o f-tomo deve ser relaxado em Cli[Asj@=>>Cll]. Pela
Interpretao Correspondente tem-se o f-tomo de predicado 2-rio na forma
Ti[ P 2j @=>>Tl] da F-Logic. Pelo teorema 6.2, Cli Ti e Cll Tl. Como Asj tem a

mesma nomenclatura que P 2j , ento, Cli[Asj@=>>Cll] Ti[ P 2j @=>>Tl].

Portanto,

Com o teorema 6.3 tem-se que qualquer f-tomo de associao de classes em UML.P tem
equivalncia com um f-tomo de predicado 2-rio em PDDL de acordo com a SRDD.
A seguir, o teorema 6.4 demonstrar que todos os f-tomos de associao de classes do
modelo UML.P e de predicados 2-rios do modelo PDDL so equivalentes.

Teorema 6.4 (Equivalncia de Modelos para f-tomos de associao de classes e de

predicados 2-rios) Considerando a SRDD e sendo a frmula UML.P, que possui todos os f-
tomos de associao de classes do modelo UML.P e a frmula PDDL, que possui todos os f-
tomos de predicados 2-rios do modelo PDDL, tem-se que UML.P PDDL, se todas as
associaes de classes de As tm nomenclatura idntica aos predicados 2-rios de P 2 .
Prova
De acordo com a SRDD, a nomenclatura das associaes de classes do conjunto As
idntica a dos predicados 2-rios do conjunto P 2 , formando uma bijetora. O fato de ser

uma bijetora supe-se que haja uma funo f e sua inversa f -1, de modo que f: As P 2

se e somente se f -1: P 2 As. Da, pelo teorema 6.3 para toda nomenclatura idntica

entre As e P 2 demonstra-se a equivalncia entre f-tomos desde que pelo teorema 6.2,

as classes e tipos tenham igualdade. Como As e P 2 formam bijeo, eles tm a mesma

cardinalidade e os modelos UML.P e PDDL so equivalentes no que tange s
associaes de classes e aos predicados 2-rios UML.P PDDL

Com o teorema 6.2 e 6.4, provou-se que dado um mesmo domnio, onde o engenheiro do
conhecimento ou projetista de domnio use a mesma nomenclatura para definir seus tipos e
 67

predicados 2-rios no modelo PDDL e as classes e associaes de classes no modelo UML.P,

esses modelos seriam equivalentes sempre.
A seguir, demonstrar-se- que um atributo de classe da UML.P equivalente a um
predicado 1-rio da PDDL.

Teorema 6.5 (Equivalncia de f-tomo de atributo de classe UML.P e f-tomo de predicado

1-rio PDDL) Considerando a SRDD e sendo um f-tomo de atributo de classe de At da
UML.P e um f-tomo de predicado 1-rio de P1 da PDDL, tem-se que , se a

nomenclatura de Ati idntica de P1i .

Prova
De acordo com a SRDD, a nomenclatura de atributo de classe idntica a de predicado
1-rio. Pela Interpretao Completa e a Interpretao IFR de forma reduzida tem-se o
f-tomo de atributo de classe da UML.P na forma Cli[Ati@=>Booleano] da F-Logic.
Pela Interpretao Correspondente tem-se o f-tomo de predicado 1-rio da PDDL
na forma Ti [ P1i @=>Booleano] da F-Logic. Pelo teorema 6.2, tem-se que Cli Ti. Como

Ati tem a mesma nomenclatura que P1i , ento, Cli[Ati@=>Booleano] Ti

[ P1i @=>Booleano]

Com o teorema 6.5 tem-se que qualquer f-tomo de atributo simples em UML.P tem
equivalncia com um f-tomo de predicado 1-rio em PDDL de acordo com a SRDD. O
importante demonstrar no teorema a seguir que todos os atributos simples de um modelo em
UML.P so equivalentes aos predicados 1-rios de um modelo em PDDL.

Teorema 6.6 (Equivalncia de Modelos para f-tomos de atributo de classes e de predicados

1-rios) Considerando a SRDD e sendo a frmula UML.P, que possui todos os f-tomos de
atributos de classes do modelo UML.P e a frmula PDDL, que possui todos os f-tomos de
predicados 1-rios do modelo PDDL, tem-se que UML.P PDDL, se todos os atributos de
classes de At tm nomenclatura idntica aos predicados 1-rios de P1 .
Prova
De acordo com a SRDD, a nomenclatura dos atributos de classes do conjunto At
idntica a dos predicados 1-rios do conjunto P1 , formando uma bijetora. O fato de ser
 68

uma bijetora supe-se que haja uma funo f e sua inversa f -1, de modo que f: At P1

se e somente se f -1: P1 At. Da, pelo teorema 6.5 para toda nomenclatura idntica

entre At e P1 demonstra-se a equivalncia entre f-tomos desde que pelo teorema 6.2,

as classes e tipos tenham igualdade. Como At e P1 formam bijeo, eles tm a mesma

cardinalidade e os modelos UML.P e PDDL so equivalentes no que tange aos
atributos de classes e aos predicados 1-rios UML.P PDDL

Com o teorema 6.6, todo atributo de classe pode ser interpretado em predicado 1-rio da
PDDL.
A seguir, o prximo teorema lida com a equivalncia entre f-tomos de atributo com
parmetros de classe e de predicado n-rio.

Teorema 6.7 (Equivalncia de f-tomo de atributo de classe UML.P com parmetros e f-

tomo de predicado n-rio PDDL) Considerando a SRDD e sendo um f-tomo de atributo de
classe com parmetros de Atp da UML.P e um f-tomo de predicado n-rio de P n da

PDDL, tem-se que , se a nomenclatura de Atpi idntica de P ni .

Prova
De acordo com a SRDD, a nomenclatura de atributo com parmetros de classe
idntica a de predicado n-rio. Pela Interpretao Completa e a Interpretao IFR de
forma reduzida tem-se o f-tomo de atributo com parmetros de classe da UML.P na
forma Cli [Atpi@p1, , pn =>Booleano] da F-Logic. Pela Interpretao Correspondente
tem-se o f-tomo de predicado n-rio da PDDL na forma Ti[ P ni @p1,,pn=>Booleano]

da F-Logic. Pelo teorema 6.2, tem-se que Cli Ti. Os parmetros p1,,pn so classes ou
tipos, ento, tambm pelo teorema 6.2, p1 p1 ,, pn pn. A ordem dos parmetros
importa devido Interpretao Correspondente utilizar o TMR para interpretar
predicados em F-Logic. Como o atributo de classe com parmetros Atpi tem a mesma
nomenclatura que o predicado n-rio P ni , ento, Cli [Atpi@p1, , pn =>Booleano]

Ti[ P ni @p1,,pn=>Booleano]
 69

Com o teorema 6.7, sabe-se que um f-tomo de atributo com parmetros de classe
equivalente a um f-tomo de predicado n-rio. O prximo teorema demonstra que todos esses
atributos so equivalentes aos predicados n-rios de acordo com sua demonstrao.

Teorema 6.8 (Equivalncia de Modelos para f-tomos de atributo com parmetros de classes
e de predicados n-rios) Considerando a SRDD e sendo a f-frmula UML.P, que possui todos os
f-tomos de atributos com parmetros de classes do modelo UML.P e a f-frmula PDDL, que
possui todos os f-tomos de predicados n-rios do modelo PDDL, tem-se que UML.P PDDL,
se todos os atributos com parmetros de classes de Atp tm nomenclatura idntica aos
predicados n-rios de P n .
Prova
De acordo com a SRDD, a nomenclatura dos atributos com parmetros de classes do
conjunto Atp idntica a dos predicados n-rios do conjunto P n , formando uma
bijetora. O fato de ser uma bijetora supe-se que haja uma funo f e sua inversa f -1, de
modo que f: Atp P n se e somente se f -1: P n Atp. Da, pelo teorema 6.7 para toda

nomenclatura idntica entre Atp e P n demonstra-se a equivalncia entre f-tomos

desde que pelo teorema 6.2, as classes e tipos tenham igualdade, assim como os
parmetros que tambm so classes e tm de possuir mesma ordem. Como Atp e P n
formam bijeo, eles tm a mesma cardinalidade e os modelos UML.P e PDDL so
equivalentes no que tange aos atributos com parmetros de classes e aos predicados n-
rios UML.P PDDL

Com o teorema 6.8 tem-se que qualquer f-tomo de atributo com parmetros em UML.P
tem equivalncia com um f-tomo de predicado n-rio em PDDL de acordo com a SRDD.
Os teoremas 6.1-8 demonstram que os f-tomos dos modelos em UML.P e PDDL de
acordo com a SRDD so equivalentes.
(Exemplo dos Teoremas 6.1-8) No domnio Mundo dos Blocos, pode-se exemplificar o
teorema da seguinte maneira:
1. Para Cl1 :: Cl T1 :: T:
a. Cl1 T1 Manipulador e Cl T, que so idnticos e tratam-se do conjunto universal
dos tipos ou classes, de modo que Manipulador Manipulador;

2. Para Cl1[As1@=>Cl2] T1[ P12 @=>T2]:

 70

a. Cl1 T1 Manipulador, Cl2 T2 Bloco, de modo que As1 e P12 sejam o mtodo
Segurando. Para que a descrio do mtodo de conjunto de valores seja:
Manipulador[Segurando@=>>Bloco] Manipulador[Segurando@=>>Bloco];

3. Para Cl1[At1@=> booleano] T1[ P11 @=> Booleano]:

a. Cl1 T1 Manipulador, de modo que At1 e P11 sejam o mtodo garraVazia, e

Booleano o tipo primitivo para verdadeiro ou falso. Assim, a descrio de mtodo
escalar seja:
Manipulador[garraVazia@=>Booleano] Manipulador[garraVazia@=>Booleano].
4. Para Cl1[Atp1@ Cl2, Cl3=> booleano] T1[ P 1n @T2, T3=> booleano]:
a. Cl1 T1 Manipulador, Cl2 T2 Bloco e Cl3 T3 Mesa, de modo que Atp1 e P 1n
sejam o mtodo segurando, e booleano o tipo primitivo para verdadeiro ou falso.
Assim, a descrio de mtodo escalar Manipulador [segurando@Bloco, Mesa =>
booleano] Manipulador [segurando@Bloco, Mesa =>booleano].

Como houve a demonstrao de que os Modelos UML.P e PDDL possuem f-tomos de

acordo com a SRDD, IFR e Interpretao Correspondente, de modo que estes f-tomos sejam
equivalentes. Isso leva a provar que uma frmula que representa a conjuno de f-tomos
tanto do modelo UML.P quanto do modelo PDDL sejam equivalentes tambm. Dessa forma,
atravs do teorema abaixo busca-se provar que um modelo UML.P na IFR e SRDD
equivalente a outro modelo PDDL na Interpretao Correspondente e SRDD.

Teorema 6.9 (Equivalncia de modelos UML.P e PDDL) Considerando a SRDD, duas f-

frmulas possuem todos os f-tomos dos modelos UML.P e PDDL, onde a f-frmula
decorrente da Interpretao IFR de forma reduzida da UML.P e a f-frmula decorrente da
Interpretao Correspondente da PDDL, que so consideradas equivalentes , se as
classes Cl so equivalentes aos tipos T, se os atributos de classes At so equivalentes aos
predicados 1-rios P1 , se os atributos com parmetros de classes Atp so equivalentes aos

predicados n-rios P n e se as associaes de classes As so equivalentes aos predicados 2-

rios P 2 .
Prova
A f-frmla possui conjunes de todos os f-tomos do modelo UML.P e a f-frmula
possui conjunes de todos os f-tomos do modelo PDDL. As f-frmulas e seguem a
 71

restrio da SRDD e como possuem conjunes de f-tomos no importa a ordem deles

dentro da f-frmula devido lei da comutao. Assim, Pelo teorema 6.2 tem-se que
todas as classes Cl so equivalentes aos tipos T. Pelo teorema 6.6 tem-se que todos os
atributos de classes At so equivalentes aos predicados 1-rios P1 . Pelo teorema 6.8
tem-se que todos os atributos com parmetros de classes Atp so equivalentes aos
predicados n-rios P n . Pelo teorema 6.4 tem-se que todas as associaes de classes As
so equivalentes aos predicados 2-rios P 2 . Portanto, h equivalncia de modelos
entre UML.P e PDDL de acordo com a SRDD, de modo que

(Exemplo do Teorema 6.9) Aproveitando o exemplo dos teoremas 6.1-8 para

exemplificar o teorema 6.9, tem-se as seguintes f-frmulas do Mundo dos Blocos:
Os teoremas 6.1-8 expem que as f-frmulas e possuem f-tomos (
1, 2, ..., n)
(
1, 2, ..., n) e que podem ser demonstrados para cada f-tomo (
n 1, n-1 2, ..., 2
n-1, 1 n), entretanto, a ordem dos f-tomos nas f-frmulas no se trata de algo que possa
ser intuitivo, isto , 20 5 . Mas pela lei da comutao garante que as f-frmulas so
idnticas. O exemplo abaixo para demonstra os f-tomos com ordem diferente dentro
de cada f-frmula. Entretanto, ambos conjuntos de f-frmulas e possuem os mesmos f-
tomos:

= (Bloco[sobre@=>> Bloco, nadaSobre@=> Booleano, naMesa@=>> Mesa],

Manipulador[garraVazia@=> Booleano, segurando@=>> Bloco]) = (Bloco[nadaSobre@=>
Booleano, naMesa@=>> Mesa, sobre@=>> Bloco], Manipulador[segurando@=>> Bloco,
garraVazia@=> Booleano]). De tal modo que as f-frmulas sejam .

Com o teorema 6.9 demonstrou-se que o modelo UML.P de acordo com a IFR e a SRDD
equivalente ao modelo PDDL de acordo com a Interpretao Correspondente e a SRDD.
Entretanto, na Interpretao Completa do modelo UML.P h muitos outros f-tomos
(GOMES, 2008). Por isso, no teorema 6.10 abaixo demonstra-se que um modelo PDDL
conseqncia lgica de um modelo UML.P, mas o contrrio no verdadeiro. Essa
demonstrao de que o modelo PDDL conseqncia lgica de um modelo UML.P s
possvel porque o teorema 11.3 em (KIFER; LAUSEN; WU, 1995) demonstra que a deduo
F-Logic correta utilizando suas propriedades e regras de inferncia.
 72

Teorema 6.10 (Conseqncia Lgica da Interpretao) O modelo da PDDL de acordo com

a SRDD e a Interpretao Correspondente sobre tipos e predicados conseqncia lgica na
teoria da F-Logic de um modelo em UML.P sobre o diagrama de classes a partir da
Interpretao Completa, tal que F para o mesmo Domnio .
Prova
Sendo a SRDD e a Interpretao Correspondente utilizadas para o modelo apenas e
a Interpretao Completa para o modelo , ento, tem-se os modelos interpretados em
f-tomos. Como o modelo em UML.P possui mais f-tomos que o modelo em PDDL
e o teorema 6.9 prova que o modelo UML.P e PDDL so equivalentes de acordo com a
SRDD e a Interpretao IFR de forma reduzida e, ainda, pelo teorema 5.1 prova-se que
a Interpretao IFR de forma reduzida Interpretao Completa, tem-se que e,
logo, F

Com os teoremas apresentados nesse captulo, essa dissertao demonstrou que factvel
a interpretao de modelos da UML.P em modelos da PDDL de acordo com a suposio
SRDD.

6.2. Exemplos da Equivalncia entre Modelos UML.P e PDDL utilizando a

F-Logic

Esta seo demonstra alguns exemplos de modelos em UML.P e PDDL considerando as

definies e teoremas dos captulos 3, 4, 5 e 6.
A seguir se demonstrar quatro domnios de Planejamento Automtico: Satlite, Jantar
dos Filsofos, Logstica e Zeno Travel de acordo com o propsito dessa dissertao.
Para o domnio Satlite, segue seu diagrama de classes com as associaes, atributos de
classes e classes:
 73

Figura 29 Diagrama de Classes para o domnio Satlite.

O diagrama de classes UML.P para o domnio Satlite possui 4 (quatro) classes, 4 (quatro)
associaes de classes e 3 (trs) atributos de classes. As classes, seus atributos e suas
associaes fazem parte da suposio SRDD. Dessa forma, esses so os elementos que
possuem equivalncia com os elementos PDDL de acordo com a Interpretao
Correspondente em F-Logic.
Para o diagrama de classes do domnio Satlite, abaixo segue a tabela com a descrio F-
Logic em comum descrio PDDL e ao diagrama de classes.

Tabela 13 Equivalncia entre UML.P e PDDL para o domnio Satlite

F-Logic Classes e Mtodos PDDL Tipos e Predicados
Satelite :: ClasseFund. (define (domain Satellite_Domain)
Instrumental :: ClasseFund. (:requirements :typing)
Modo :: ClasseFund. (:types
Direcao :: ClasseFund. Satelite - T
Instrumental - T
Instrumental[acoplado@=>>Satelite; Modo - T
calibrandoAlvo@=>>Direcao; Direcao - T)
suportando=>>Modo; (:predicates
funcionando@=>Booleano; (acoplado ?ins - Instrumental ?sat
calibrado@=>Booleano]. - Satelite)
(apontando ?sat - Satelite ?dir -
Satelite[disponibilidade@=>Booleano; Direcao)
apontando=>>Direcao]. (calibrandoAlvo ?ins - Instrumental
?dir - Direcao)
(suportando ?ins - Instrumental
?mod - Modo)
(disponibilidade ?sat - Satelite)
(funcionando ?ins - Instrumental)
(calibrado ?ins - Instrumental)))
 74

Na tabela acima, os elementos PDDL, que so os tipos, predicados 1-rios e predicados 2-

rios equivalentes ao elementos da UML.P de acordo com a SRDD, advm da Interpretao
Correspondente de ambas com a F-Logic. Portanto, as classes e mtodos da F-Logic so
iguais para ambas.
O Prximo exemplo o domnio Jantar de Filsofos, que se encontra no diagrama de
classes com as associaes, atributos de classes e classes:

Figura 30 Diagrama de Classes para o domnio Jantar dos Filsofos.

Da mesma maneira demonstrada para o domnio Satlite, o diagrama de classes para o

Jantar de Filsofos foi projetado. Percebe-se que ele possui os mesmos elementos: classes,
atributos e associaes de classes.
Para o diagrama de classes acima, abaixo segue a tabela com a descrio F-Logic em
comum descrio PDDL e ao diagrama de classes.

Tabela 14 Equivalncia entre UML.P e PDDL para o domnio Jantar dos Filsofos
F-Logic Classes e Mtodos PDDL Tipos e Predicados
Filosofo :: ClasseFund. (define (domain Dining_Philosophers)
Garfo :: ClasseFund. (:requirements :typing)
(:types
Filosofo[direito@=>>Garfo; Filosofo - T
esquerdo@=>>Garfo; segurando=>>Garfo; Garfo - T)
faminto@=>Booleano; (:predicates
temEsquerdo@=>Booleano; (direito ?fil - Filosofo ?gar -
temDireito@=>Booleano; Garfo)
comendo@=>Booleano; (esquerdo ?fil - Filosofo ?gar -
pensando@=>Booleano]. Garfo)
(segurando ?fil - Filosofo ?gar -
Garfo)
(faminto ?fil - Filosofo)
(temEsquerdo ?fil - Filosofo)
(comendo ?fil - Filosofo)
(pensando ?fil - Filosofo)
(temDireito ?fil - Filosofo)
)
 75

Percebe-se tambm a partir da tabela, as mesmas interpretaes em F-Logic no que tange

aos seus Mtodos e Classes de acordo com as definies e a suposio SRDD. Pode-se
tambm verificar a partir dos teoremas do captulo 6, a equivalncia dos f-tomos que foram
interpretados da UML.P e da PDDL em uma descrio comum em F-Logic.
No prximo domnio Logstica, se encontra o diagrama de classes com as associaes,
atributos de classes, classes e subclasses. Tambm existe a mesma orientao para a
interpretao.

Figura 31 Diagrama de Classes para o domnio Logstica.

O diagrama de classes projetado para o domnio Logstica possui como diferena aqui os
relacionamentos de Herana. Por exemplo,as classes Caminho e Avio so do tipo Veculo e
as classes Local e Aeroporto so do tipo Lugar.
Para o diagrama de classes acima, abaixo segue a tabela com a descrio F-Logic em
comum descrio PDDL e ao diagrama de classes.

Tabela 15 Equivalncia entre UML.P e PDDL para o domnio Logstica

F-Logic Classes e Mtodos PDDL Tipos e Predicados
Veiculo :: ClasseFund. (define (domain Logistic_Domain)
Caminhao :: Veiculo. (:requirements :typing)
Aviao :: Veiculo. (:types
Lugar :: ClasseFund. Veiculo - T
Local :: Lugar. Caminhao - Veiculo
Aeroporto :: Lugar. Aviao - Veiculo
Pacote :: ClasseFund. lugar - T
Cidade :: ClasseFund. Local - lugar
Aeroporto - lugar
Pacote[dentroDo@=>>Veiculo; Pacote - T
estaEM@=>>Lugar]. Cidade - T)
Lugar[dentroDaCidade=>>Cidade]. (:predicates
Caminho[no@=>>Lugar]. (dentroDo ?pac - Pacote ?vei - Veiculo)
Avio[paradoEm@=>>Aeroporto]. (EstaEm ?pac - Pacote ?lug - lugar)
(dentroDaCidade ?lug - lugar ?cid -
Cidade)
 76

(no ?cam - Caminhao ?lug - lugar)

(paradoEm ?avi - Aviao ?aer -
Aeroporto))

Percebe-se que a partir das definies do captulo 4 possvel fazer a Interpretao

Correspondente em F-Logic. E a partir da interpretao IFR de Forma Reduzida do captulo 5
tem-se tambm os f-tomos da F-Logic. Para o mesmo domnio de acordo com a SRDD, os
modelos UML.P e a PDDL possui equivalncia.
Para o ltimo domnio Zeno Travel abaixo, se encontra o diagrama de classes com as
associaes, atributos de classes e classes:

Figura 32 Diagrama de Classes para o domnio Zeno Travel.

Para o diagrama de classes acima, abaixo segue a tabela com a descrio F-Logic em
comum descrio PDDL e ao diagrama de classes.

Tabela 16 Equivalncia entre UML.P e PDDL para o domnio Zeno Travel

F-Logic Classes e Mtodos PDDL Tipos e Predicados
Cidade :: ClasseFund. (define (domain Zeno_Travel_Domain)
Agente :: ClasseFund. (:requirements :typing)
Pessoa :: Agente. (:types
Aeronave :: Agente. Cidade - T
PostodeCombustivel :: ClasseFund. Agente - T
Pessoa - Agente
Agente[estaEm@=>>Cidade]. Aeronave - Agente
Pessoa[dentroDe@=>>Aeronave]. PostodeCombustivel - T)
PostodeCombustivel[pertence=>>Cidade]. (:predicates
(estaEm ?age - Agente ?cid -
Cidade)
(dentroDe ?pes - Pessoa ?aer -
Aeronave)
(pertence ?pos - PostodeCombustivel
?cid - Cidade))

Esses exemplos demonstram a equivalncia de modelos UML.P e PDDL no que tange

suposio SRDD, a Interpretao Correspondente e a interpretao IFR da Forma Reduzida
de modo que os F-tomos da F-Logic so equivalentes.
 77

Prxima seo, sero apresentadas as perdas ao interpretar o modelo UML.P em modelo

PDDL.

6.3. Perdas Semnticas na Interpretao do modelo UML.P em modelo

PDDL

As perdas semnticas na interpretao do modelo UML.P em modelo PDDL so inerentes

dos f-tomos da Interpretao Completa (GOMES, 2008) que no fazem parte da
Interpretao IFR de forma reduzida considerando as restries da SRDD. Ou seja, os f-
tomos sobre classes, associao de classes e atributos de classes. Na tabela abaixo, a primeira
coluna referente ao f-tomo no interpretado em PDDL e a segunda coluna trata do seu
significado e, conseqentemente, sua perda semntica ao no ser interpretado em PDDL.

Tabela 17 F-tomos perdidos na Interpretao em modelo PDDL

F-tomo da Interpretao Completa no utizado na Interpretao IFR Significado da Interpretao de classe,
de forma reduzida
ester_Agente:tipoEstereotipo
classe[ estereotipo *-> Ester_Agente]
ester_Utilitario:tipoEstereotipo
classe[ estereotipo *-> Ester_Utilitario]
Classe[attr@limConjunto => inteiro;
attr@lim_Inferior *-> 1;
attr@lim_Superior *-> 1]
Classe[attr@caracteristica => mutabilidade;
attr@atrib_carac *-> mut_Alteravel]
classeA[associao_classeB => mutabilidade;
associao_classeB *-> <mutabilidade>]
ClasseA[associao_classeB_fimB@limConjunto => inteiro;
associao_classeB_fimB@lim_Inferior *-> <Vs>;
associao_classeB_fimB@lim_Superior *-> <Vt>]
ClasseA[
associao_classeB_fimB@caracteristica => assocTipoEx;
associao_classeB_fimB@assoc_TipoEx *-> <AssociaoTipo>]
associao de classes e atributos de
classe em F-Logic
Esses dois f-tomos representam que dada
classe uma agente no modelo, isto , a
classe que provoca mudanas nos estados
do mundo com seus operadores. Na
PDDL, no esto claramente representadas
que certas aes so de alguns Agentes.
Desse modo, no tem sido interessante
saber no modelo quem so os objetos
agentes.
Esses dois f-tomos representam que dada
classe uma classe utilitria. No
provoca mudanas nos estados do mundo.
Como explicado acima, se no h Agentes,
tambm no se mostra interessante na
PDDL saber os objetos que so passivos
no modelo.
Esses trs f-tomos representam a
multiplicidade de um atributo de classe.
Isso pode ser tratado na PDDL a partir do
elemento (:Constraints com algum esforo.
Esses dois f-tomos representam a
mutabilidade de um atributo. Na PDDL
no h esse tipo de informao no modelo.
Esses dois f-tomos representam como a
associao de classe: esttica ou altervel.
Na PDDL no h esse tipo de informao
no modelo.
Esses trs f-tomos representam como
exatamente a multiplicidade da associao
de classes A e B pelos valores <Vs> e
<Vt>. Isso pode ser tratado na PDDL a
partir do elemento (:Constraints com
algum esforo.
Esses dois f-tomos representam como
exatamente o tipo de associao em cada
extremidade da associao. Ou seja, a
ClasseA tem uma extremidade chamada
 78

fimB, que a extremidade de contato com

ClasseA[associao@=>ClasseB] relaxado em
ClasseA[associao@=>>ClasseB]
a classe B, cuja <AssociaoTipo> pode
ser simples, ou agregao, ou composio.
Essa perda semntica no relevante para
o modelo em PDDL.
O relaxamento da associao de => em
=>> ocasiona uma perda semntica
porque na PDDL isso no faz diferena.
Esse relaxamento permite tratar mais de
uma tupla de objetos sempre.

Os f-tomos que foram perdidos na interpretao em PDDL podem servir de motivao

para enriquecer a descrio em PDDL e, conseqentemente, otimizar os algoritmos dos
planejadores. J a UML.P pode fornecer com sua descrio em F-Logic uma base de
conhecimento rica em domnios e problemas de planejamento automtico, de modo que o
engenheiro do conhecimento ou projetista de domnio pudesse obter informao quando
estivesse projetando domnios ou apenas precisando de informaes sobre algum domnio.
Prximo captulo sero apresentadas as concluses desse trabalho.
 79

CAPTULO 7

7. CONCLUSO

Nesse trabalho foi possvel demonstrar a equivalncia de modelos UML.P e PDDL de

acordo com a suposio SRDD Suposio Restritiva de Declarao de Domnios, que
atravs da utilizao da F-Logic houve como interpretar ambos modelos em F-tomos e pelos
teoremas aqui apresentados demonstrou-se a equivalncia entre esses f-tomos. Alm disso,
sabe-se que tanto a PDDL como a UML.P so linguagens semiformais e caso fosse feito
apenas com essas linguagens essa formalizao, teramos resultados ainda com essa
deficincia.
Portanto, a partir da modelagem do diagrama de classes da UML.P pode-se interpretar
tipos e predicados da PDDL atravs da formalizao da F-Logic. Isso garante que qualquer
domnio de Planejamento Automtico possa ser modelado pelo itSIMPLE atravs da UML.P
e, depois, ter a descrio em PDDL.

7.1. Trabalhos Futuros

Nesse trabalho conjecturou-se a mesma abordagem para as funes da PDDL. Para as

funes pode-se utilizar dois tipos primitivos da UML.P: o tipo int que significa inteiro e o
tipo float, ponto flutuante. O inteiro para clculos discretos e o ponto flutuante para clculos
contnuos. Dessa maneira, utilizando a F-Logic pode-se ter F-tomos para as funes em
PDDL tais como: Classe[ScalM@=>int] ou Classe[ScalM@=>float].
J para tratar os operadores da UML.P e as aes da PDDL pode-se utilizar os operadores
da UML.P j interpretados em F-Logic na Interpretao Completa (GOMES, 2008) e uma
extenso da F-Logic para a Lgica de Transaes (BONNER; KIFER, 1993)
(TONIDANDEL, 2003). Essa extenso apresentada em (KIFER; LAUSEN; WU, 1995)
como Transaction F-Logic, que possui em seu orculo de dados a descrio em F-Logic.
Dessa maneira, as aes de Planejamento Automtico podem ser definidas em clusulas de
Horn utilizando a Lgica de Primeira Ordem para Objetos. Alm disso, manter essas
descries em Transaction F-Logic como Base de Conhecimento de Planejamento
Automtico.
 80

REFERNCIAS BIBLIOGRFICAS

ARISTTELES. rganon. Trad. Edson Bini. Bauru: Edipro, 2005.

BENDER, E.A. Mathematical Methods in Artificial Intelligence. IEEE Computer Society

Press, 1996.

BITTENCOURT, G. Inteligncia Artificial Ferramentas e Teorias. UFSC. 3a Edio. 2006.

BONNER, A. J.; KIFER, M. Transaction Logic programming. Technical Report CSRI-323,

Computer Systems Research Institute, university of Toronto, 1993.

BOOCH, Grady; JACOBSON, Ivar; RUMBAUGH, James. The Unified Modeling Language
User Guide. Addison-Wesley, 1999.

COPPIN, B. Artificial Intelligence Illuminated. Sudbury, MA, Jones and Bartlett, 2004.

DECKER, S. On domain-specific declarative knowledge representation and database

languages. In Proc. of the 5th International KRDB Workshop, pages 9.19.7, 1998.

EDELKAMP, S.; MEHLER, T. Knowledge Acquisition and Knowledge Engineering in the

ModPlan Workbench. Proceedings of the International Planning Competition.
International Conference on Automated Planning and Scheduling. Monterey, pages 26.33,
2005.

EDELKAMP, S.; JABBAR, S.; LAFUENTE, A. L. Action Planning for Graph Transition
Systems. Verification and Validation of Model-Based Planning and Scheduling Systems
(VVPS). Monterey, AAAI Press, pages 58-66, 2005.

FIKES, R.E.; NILSSON, N.J. STRIPS: A New Approach to the Application of Theorem
Proving to Problem Solving. Technical Note 43r. AI Center, SRI International, 333
Ravenswood Ave, Menlo Park, CA 94025, May 1971.

FOX, M.; LONG, D. 2003. PDDL 2.1: An Extension to PDDL for Expressing Temporal
Planning Domains. Journal of Artificial Intelligence Research 20:61-124.

GOMES, M. L. EXTRAO DE CONHECIMENTO DE DOMNIOS DE PLANEJAMENTO

DESCRITOS EM UML.P. 2008. Monografia (Mestrado em Engenharia Eltrica).

GOMES, M. L.; VAQUERO, T. S.; SILVA, J. R.; TONIDANDEL, F. Extracting State

Constraints from UML Planning Models. In: ICAPS-08 Workshop on Knowledge
Engineering for Planning and Scheduling (KEPS). Sydney, Australia. 2008.

KIFER, M.; LAUSEN, G.; WU, J. Logical Foundations of object-oriented and frame-based
languages. Journal of ACM, v. 42, p. 741-843, May 1995.
 81

KOWALSKI, R.; SERGOT, M. A logic-based calculus of events. New Generation

Computing, 4(1), p. 67-95, 1986.

LIFSCHITZ, V. On the Semantics of STRIPS, in Workshop Reasoning about Actions and

Plans, s.1., 1987. Proceedings. s.n. 1987, p.1-9.

LIFSCHITZ, V; REN, W. The Semantics of Variables in Action Descriptions, in Proceedings

of the Twenty-Second National Conference on Artificial Intelligence (AAAI), 2007. 1025-
1030.

LKA, M. Extensional and intensional semantics of pUML objects. In: IIT.SRC 2005
Informatics and Information Technology Student Research Conference. Bratislava, April
2005, J. Minrov (supervisor), pp. 167174.

LUDSCHER, B.; YANG, G.; KIFER, M. Flora: The Secret of Object-Oriented

Programming. Technical Report, SUNY at Stony Brook, 1999.

LUGER, George F. Artificial Intelligence: Structures and Strategies for Complex Problem
Solving (5th Edition). Addison-Wesley, 2004.

MCCARTHY, J.; HAYES, P. J. Some Philosophical Problems from the Standpoint of

Artificial Intelligence. In B. Meltzer and D. Michie, editors, Machine Intelligence 4, p.
463-502. Edinburgh University Press, 1969.

MCCLUSKEY T. L. The Knowledge Engineering for Planning Roadmap in the PLANET

final report to the EC, November 2000.

MCCLUSKEY T. L. Knowledge Engineering: Issues for the AI Planning Community.

Proceedings of the AIPS-2002 Workshop on Knowledge Engineering Tools and
Techniques for AI Planning, Toulouse, France, April 2002.

MCCLUSKEY T. L. PDDL: A Language with a Purpose?, Proceedings of the ICAPS-03

workshop on PDDL, International Conference on Automated Planning and Scheduling,
June, 2003 (ICAPS'03).

MCDERMOTT, D. & the AIPS-98 Planning Competition Committee 1998. PDDL The
Planning Domain Definition Language. Tech. rep., Available at:
www.cs.yale.edu/homes/dvm.

MCDERMOTT, D. PDDL2.1 - The Art of the Possible? Commentary on Fox and Long.
Journal of Artificial Intelligence Research 20:145 148, 2003.

NILSSON, N. J. Artificial Intelligence : A New Synthesis. Morgan Kaufmann; 1st

edition,1998.

OMG Object Management Group, 2001. Unified Modeling Language Specification: version
2.1. URL: www.omg.org/uml.
 82

PEDNAULT, E. ADL: Exploring the middle ground between STRIPS and the situation
calculus. In International Conference on Principles of Knowledge Representation and
Reasoning, 1., Toronto, 1989. Proceedings. s.n. 1989, p.324-332.

PEDNAULT, E. ADL and the state-transition model of action. Journal of Logic and
Computation, 4:467512, 1994.

RAMALHO, F., ROBIN, J. and SCHIEL, U. Concurrent Transaction Frame Logic Formal
Semantics for UML Activity and Class Diagrams. Electronic Notes in Theoretical
Computer Science, Volume 95, 17 May 2004 Edited by A. Cavalcanti and P. Machado,
Elsevier, 2004.

RAMALHO, F., ROBIN, J. Mapping UML Class Diagrams to Object-Oriented Logic

Programs for Formal Model-Driven Development. 3rd Workshop in Software Model
Engineering, 11 Oct 2004.

RUSSELL, S.; NORVIG, P. Inteligncia Artificial, ed Campus, 2004.

SCHREIBER G., AKKERMANS H., ANJEWIERDEN A., DE HOOG R., SHADBOLT N.,
VAN de Velde W., WIELINGA B. Knowledge engineering and management. The
CommonKADS methodology. MIT Press, 2000.

SIMPSON R. M.; MCCLUSKEY T. L.; ZHAO W.; AYLETT R.S.; DONIAT C. An

Integrated Graphical Tool to support Knowledge Engineering in AI Planning.
Proceedings of the European Conference on Planning, Toledo, Spain, September 2001.

SOWA, J. F. (2006). Semantic networks. (Revised and extended version of an article

originally written for the Encyclopedia of Artificial Intelligence, edited by Stuart C.
Shapiro, Wiley, 1987, second edition, 1992). http://www.jfsowa.com/pubs/semnet.htm

TONIDANDEL, F. Desenvolvimento e implementao de um sistema de planejamento

baseado em casos. 2003. 188 p. Tese (Doutorado) - ESC POLITECNICA, Universidade
de So Paulo, So Paulo, 2003.

TONIDANDEL F., VAQUERO T.S., and SILVA J.R. Reading PDDL, Writing an Object-
Oriented Model. In Leture Notes in Computer Science. International Joint Conference on
AI IBERAMIA/SBIA. Springer-Verlag. 2006.

UDO, M. ; VAQUERO, T. S. ; SILVA, J. R. ; TONIDANDEL, F. Lean Software

Development Domain. In: 18th International Conference on Automated Planning and
Scheduling (ICAPS), 2008, Sydney. Australia. ICAPS-08 Workshop on Scheduling and
Planning Applications (SPARK), 2008.

VAQUERO, T. S.; TONIDANDEL, F.; SILVA, J. R. 2005. The itSimple tool for Modeling
Planning Domains. ICAPS 2005 Competition ICKEP, Monterey, California, USA.

VAQUERO, T. S.; TONIDANDEL, F.; BARROS, L. N. de; SILVA, J. R. 2006. On the Use
of UML.P for Modeling a Real Application to the Planning Problem.
 83

VAQUERO, T. S. itSIMPLE: Ambiente Integrado de Modelagem e Anlise de Domnios de

Planejamento Automtico. 2007. Monografia (Mestrado em Engenharia Mecatrnica).

VAQUERO, T. S.; TONIDANDEL, F.; BARROS, L.N. ; SILVA, J. R. Modeling a Real

Application as a Planning Problem by using UML.P. In: VIII SBAI - Simpsio Brasileiro
de Automao Inteligente, 2007, Florianpolis, Brazil, 2007. Full Paper.

VAQUERO, T. S.; TONIDANDEL, F.; SILVA, J. R. Suggestions for the Knowledge

Engineering Competition. In: ICAPS-08 Workshop on Knowledge Engineering for
Planning and Scheduling (KEPS). Sydney, Australia. 2008.