ANDRÉ MESQUITA RINCON Implementação de uma Ferramenta

Transcrição

ANDRÉ MESQUITA RINCON
Implementação de uma Ferramenta Gráfica para Construção de
Hiperdocumentos Educacionais Baseados em Grafos
Conceituais e sua Conversão para o Formato XML
Palmas – TO
2004
“Monografia apresentada como requisito parcial
da disciplina Prática de Sistemas de
Informação II (TCC) do curso de Sistemas de
Informação, sob orientação do Prof°. M.Sc.
Fabiano Fagundes”
Palmas – TO
2004
“Monografia apresentada como requisito parcial
da disciplina Prática de Sistemas de
Informação II (TCC) do curso de Sistemas de
Informação, sob orientação do Prof°. M.Sc.
Fabiano Fagundes”
Aprovado em dezembro de 2004
BANCA EXAMINADORA
_______________________________________________
Prof. M.Sc. Fabiano Fagundes
Centro Universitário Luterano de Palmas
_______________________________________________
Prof. Jackson Gomes de Souza
_______________________________________________
Profª. M.Sc. Parcilene Fernandes Brito
Palmas – TO
2004
SUMÁRIO
1
INTRODUÇÃO ........................................................................................... 7
2
REVISÃO DA LITERATURA ..................................................................10
2.1
2.1.1
Conceitos nos Grafos Conceituais.....................................................14
2.1.3
Ligações nos Grafos Conceituais ......................................................15
2.1.2
XML (EXTENSIBLE MARKUP LANGUAGE).................................................16
2.3
FLASH ...................................................................................................18
2.4
2.4.1
Flash e XML .....................................................................................18
PROJETO COGITANT.............................................................................19
BCGCT e CoGXML...........................................................................21
MATERIAL E MÉTODOS........................................................................26
3.1
LOCAL E PERÍODO ..................................................................................26
3.2
MATERIAIS ............................................................................................26
3.2.1
Hardware..........................................................................................26
3.2.3
Fontes Bibliográficas ........................................................................27
3.2.2
3.3
4
Relações nos Grafos Conceituais ......................................................14
2.2
2.3.1
3
GRAFOS CONCEITUAIS ...........................................................................10
Software............................................................................................27
METODOLOGIA ......................................................................................27
RESULTADOS E DISCUSSÃO.................................................................28
4.1
ARQUITETURA .......................................................................................28
4.2
MODELO XML ......................................................................................29
4.3
FERRAMENTA DESENVOLVIDA ................................................................31
4.3.1
Elementos da Interface......................................................................33
4.3.3
Exemplo de utilização da ferramenta.................................................44
4.3.2
Restrições dos Grafos Conceituais ....................................................39
5
CONCLUSÕES FINAIS E TRABALHOS FUTUROS.............................47
6
REFERENCIAS BIBLIOGRÁFICAS.......................................................49
ANEXOS .............................................................................................................51
LISTA DE FIGURAS
Figura 1 – Exemplo de grafo conceitual utilizando a DF ..................................................11
Figura 2 - Exemplo de grafo conceitual utilizando a LF ...................................................12
Figura 3 – Exemplo de representação utilizando o CGIF ..................................................12
Figura 4 – Exemplo de representação utilizando o KIF.....................................................13
Figura 5 – Exemplo de uma DTD e de um arquivo XML válido.......................................17
Figura 6 – Tela da ferramenta desenvolvida usando a biblioteca do CoGITaNT ...............20
Figura 7 – Representação de Conceitos no BCGCT..........................................................22
Figura 8 – Representação de Relações no BCGCT ...........................................................23
Figura 9 – Representação de Conceitos no CoGXML.......................................................24
Figura 10 – Representação de Relações no CoGXML ......................................................25
Figura 11 – Arquitetura da ferramenta..............................................................................28
Figura 12 – DTD do modelo XML criado para ferramenta ...............................................29
Figura 13 – Exemplo de Grafo na Display Form com o código XML correspondente ......30
Figura 14 – Tela da ferramenta para construção de Grafos Conceituais ............................32
Figura 15 – Movieclips utilizados na ferramenta (Conceito e Relação) .............................33
Figura 16 – Movieclips utilizados na ferramenta (Ligação)...............................................34
Figura 17 – Função que desenha o corpo da Ligação........................................................34
Figura 18 – Exemplo da estrutura das classes implementadas...........................................35
Figura 19 – Buttons utilizados na ferramenta....................................................................35
Figura 20 – Função que instancia o objeto XML ..............................................................37
Figura 21 – Elementos do tipo Input text utilizados na implementação .............................38
Figura 22 – Elemento de interface do tipo listbox.............................................................39
Figura 23 – Restrições na criação de um Conceito............................................................40
Figura 24 – Restrições na criação de uma Relação ...........................................................41
Figura 25 – Restrição na criação de uma Ligação .............................................................42
Figura 26 – Restrições na criação do formato XML .........................................................43
Figura 27 – Exemplo de utilização da ferramenta .............................................................45
Figura 28 – Exemplo de GC no formato XML .................................................................46
LISTA DE ABREVIATURAS
EHDM (Hyperdocument Educational Design Method)
NCM (Nested Context Model)
RMM (Relationship Management Methodology)
OOHDM (Object-Oriented Hypermedia Design Model)
XML (eXtensible Markup Language)
GC (Grafos Conceituais)
DF (display form)
LF (linear form)
CGIF (Conceptual Graph Interchange Form)
KIF (Knowledge Interchange Format)
W3C (World Wide Web Consortiun)
SGML (Standard Generalized Markup Language)
ISO (International Organization for Standardization)
DTD (Document Type Definition)
CoGITaNT (Conceptual Graphs Integrated Tools allowing Nested Typed graphs)
BCGCT (Base de Connaissances Graphes Conceptuels Textuelle)
CoGXML (Conceptual Graphs XML)
LABMIDIA (Laboratório de Multimídia e Hipermídia)
RESUMO
O presente trabalho tem a finalidade de apresentar a implementação de uma parte
da ferramenta para criação de hiperdocumentos educacionais baseados em Grados
Conceituais. Visto que os hiperdocumentos educacionais têm alguns requisitos
diferenciados dos hiperdocumentos tradicionais e que os Grafos Conceituais permitem a
representação de conhecimento de forma gráfica em um formato logicamente preciso, a
ferramenta se apresenta como um auxílio na modelagem das informações que vão compor
estes documentos. Dado que a modelagem dos grafos pode ocorrer de várias formas
(como, por exemplo: texto ou elementos gráficos), a ferramenta pode ser utilizada para
comunicação entre ser humano e sistemas computacionais ou entre os próprios sistemas
computacionais através de um formato que possa ser interpretado por eles. A ferramenta,
implementada em Flash, permite a modelagem gráfica, por parte do usuário, e a traduz
para o formato XML (eXtensible Markup Language) para sua interpretação por sistemas
computacionais.
Palavras chave: Grafos Conceituais, Flash MX, Hiperdocumentos Educacionais, XML.
ABSTRACT
The present work aims to present the partial implementation of a tool for creation of
educational
hyperdocuments
hyperdocuments
have
some
based
in
Conceptual
requirements
different
Graphs.
from
Since
those
educational
of
traditional
hyperdocuments and that Conceptual Graphs allow the visual representation of knowledge
in a necessary logical format, the tool is an assistant in the modeling of information that
compose these documents. The modeling of graphs can be made of many forms (for
example: text or graphical elements), thus the tool can be used to communication between
human and machines or between machines and machines through an interpretable format.
The tool, implemented in Flash, allows the graphic modeling, made by the user, and
translates it to XML for its interpretation by computational systems.
Keywords: Conceptual Graphs, Flash MX, Educational Hyperdocuments, XML.
7
1 INTRODUÇÃO
A Internet trouxe consigo uma nova forma de navegação, representação e
transmissão das informações que se dá através de textos que podem ser acessados de
maneira não linear, ou seja, não possui uma forma única de leitura do seu conteúdo. Estes
são chamados de hipertextos. Quando se pensa em um conjunto de textos armazenados em
um único documento, tem-se, então, um hiperdocumento que, além de possibilitar a
ligação para outros hiperdocumentos, permite a ligação para partes do próprio documento.
Em Díaz (1995) encontra-se que uma das novidades que se apresentam com os
hiperdocumentos é a possibilidade de cada leitor navegar em um conjunto de informações
de forma diferente, isso sendo feito através de âncoras para outras partes do texto dentro de
um mesmo documento ou de outros documentos. Devido a isso, a autora acrescenta que
aplicações que trabalham com hiperdocumentos necessitam de metodologias e ferramentas
especiais que dão suporte ao desenvolvimento deste tipo de aplicações.
Os hiperdocumentos, quando utilizados no âmbito educacional, recebem a
denominação de hiperdocumentos educacionais. Atualmente, alguns esforços são
realizados para permitir o ensino utilizando a Internet como, por exemplo: o EHDM
(Hyperdocument Educational Design Method) que consiste em um método para elaboração
de hiperdocumentos educacionais; o desenvolvimento de ambientes colaborativos para
ensino à distância; entre outros. Além disso, existe uma preocupação no que diz respeito à
modelagem de hiperdocumentos educacionais, pois esses documentos devem levar em
consideração a coerência das informações e a sobrecarga cognitiva.
“Uma das características essenciais do hipertexto é sua capacidade de ligação. O
que são essas ligações, o que elas unem, que princípios regem estas ligações são, pois,
conceitos importantes para a elaboração de hiperdocumentos coerentes” (Campos, 2001).
Para que um hiperdocumento seja elaborado de forma coesa, deve-se levar em
8
consideração a disposição do conhecimento que se deseja apresentar, bem como das
ligações dentro do hiperdocumento.
A criação das ligações dentro de um hiperdocumento de forma a representar a
navegação da maneira como o desenvolvedor deseja tem sido alvo de inúmeras pesquisas
como, por exemplo, o NCM (Nested Context Model) (Casanova, 1991), o RMM
(Relationship Management Methodology) (Isakowitz, 1995) e o OOHDM (ObjectOriented Hypermedia Design Model) (Schwabe, 1995). Algumas conclusões que essas
pesquisas têm revelado indicam que ferramentas de auxílio à criação de ligações podem ser
úteis na representação das informações.
“A sobrecarga cognitiva presente em um hiperdocumento educacional diz respeito
ao esforço e concentração necessários para manter várias tarefas ao mesmo tempo”
(Conklin, 1987). O ser humano tem capacidade limitada de processamento de informação e
um esforço adicional para leitura, principalmente no que diz respeito à navegação entre as
informações, pode reduzir os recursos disponíveis para a compreensão.
Baseado na necessidade de uma ferramenta para criação de ligações de forma
automática para hiperdocumentos educacionais optou-se pelos Grafos Conceituais, pois
permitem a representação lógica de proposições, além de permitir a representação de
conhecimento em um formato que seja compreendido por humanos e por sistemas
computacionais.
A ferramenta será implementada em Macromedia Flash, pois é uma tecnologia que
permite a implementação de elementos de interatividade com o usuário. Além disso, o
Flash possui uma linguagem chamada ActionScript que pode ser utilizada para acesso aos
objetos como por exemplo: movieClips (clipes de filme), buttons (botões), input text
(caixas de texto), entre outros. Além disso, nessa linguagem, existe um objeto que permite
a manipulação de documentos XML (eXtensible Markup Language).
O texto está dividido em: revisão de literatura (na seção 2), onde são apresentados
os estudos teóricos sobre Grafos Conceituais; a linguagem XML, a tecnologia Flash e o
projeto CoGITaNT (Conceptual Graphs Integrated Tools allowing Nested Typed graphs);
a seção 3 corresponde aos materiais e métodos utilizados, em outras palavras, apresenta
elementos de hardwares, softwares, materiais bibliográficos e metodologias utilizadas
neste trabalho; os resultados e discussões (apresentados na seção 4), tem como finalidade
apresentar a DTD (Document Type Definition) que é utilizada para validação dos Grafos
Conceituais transformados para o formato XML, bem como detalhes da implementação da
9
ferramenta em Flash; na seção 5 são apresentadas as conclusões obtidas com a realização
deste, além de algumas sugestões de trabalhos futuros.
10
2 REVISÃO DA LITERATURA
Para a implementação da ferramenta proposta, realizou-se um estudo sobre uma
linguagem para criação do ambiente gráfico, do conhecimento do domínio de Grafos
Conceituais e da linguagem de marcação que será utilizada para transformação do grafo
construído em um arquivo que possa ser intercambiado e interpretado por sistemas
computacionais. Nesta seção serão apresentados os elementos que foram estudados para
implementação de uma ferramenta com as características citadas.
2.1
Grafos Conceituais
O Grafo Conceitual (GC) consiste em uma forma de representação do
conhecimento proposta por Sowa (2001a) que permite a representação lógica de
proposições. A ferramenta proposta neste trabalho permite a representação de proposições,
através de GC, utilizando três elementos: os Conceitos, que representam entidades do
mundo real; as Relações, que permitem relacionar os Conceitos; e as Ligações, que tem a
finalidade de ligar os elementos. A apresentação destes elementos será mais bem detalhada
nas próximas seções.
Outra característica dos Grafos Conceituais está na definição de que eles são
definidos como grafos bipartidos. Tal denominação advém do fato de não serem possíveis
ligações entre tipos iguais de nós (Conceitos e Relações). Em outras palavras, em um grafo
conceitual válido não existirão ligações entre um Conceito e outro ou entre uma Relação e
outra.
Os Grafos Conceituais podem ser classificados, segundo Sowa (2001a) em:

Vazio, em que o grafo não é composto por nenhum Conceito e nenhuma Relação,
não expressando assim, nenhum significado;
11

Singular, que são representados apenas por um Conceito, ou seja, sem ligação com
nenhuma Relação (por exemplo: o Conceito [Pessoa] sem ligação representa que
existe pessoa); e

Estrela, em que uma Relação está ligada a mais de um Conceito (por exemplo:
[Pessoa]->(Na)->[Cadeira]).
Para que a utilização de GC permita uma modelagem de conhecimento condizente
com a realidade, Sowa (2001b) apresenta três características importantes:
Grafos Conceituais são humanamente legíveis: um GC consiste na representação
de um conhecimento que determinado indivíduo possui. Uma das formas de se fazer tal
representação é utilizando os elementos gráficos do GC – essa representação é conhecida
como display form (DF). A Figura 1, abaixo, apresenta um exemplo de grafo conceitual
utilizando a DF.
Figura 1 – Exemplo de grafo conceitual utilizando a DF
Na DF, os Conceitos são representados por retângulos, as Relações por elipses e as
Ligações pelas setas. No exemplo da Figura 1, acima, existem dois Conceitos (Pessoa e
Cadeira), uma Relação (Na) e duas Ligações que são representadas pelas setas (uma que
chega na relação e outra que sai da relação). A Figura acima representa o seguinte
conhecimento “Pessoa Na Cadeira”. O fato de um GC permitir que um conhecimento seja
representado graficamente e, posteriormente, ser interpretado por computador, consiste em
um dos pontos que podem ser considerados como vantagem para escolha desse sistema
como base da ferramenta desenvolvida.
Grafos Conceituais são computacionalmente interpretáveis: GC possui uma
notação chamada de forma linear ou linear form (LF). A LF consiste na representação do
conhecimento em um formato computacionalmente interpretável. No caso da proposta de
Sowa (2001a), o formato interpretável é em forma de String (Texto) como o exemplo da
Figura 2. No caso da ferramenta proposta, o formato interpretável será XML (melhor
explicado posteriormente na seção 2.2).
12
[Pessoa] -> (Na) -> [Cadeira]
Figura 2 - Exemplo de grafo conceitual utilizando a LF
Na LF, os Conceitos são representados por colchetes, as Relações por parênteses e
as Ligações pelas setas montadas com os caracteres “-” seguidos de “>”. O exemplo da
Figura 2 representa o mesmo conhecimento da Figura 1 (“Pessoa Na Cadeira”).
Grafos conceituais permitem a representação de significado em um formato
logicamente preciso: quando se cria um GC para representação do conhecimento através
de seus elementos, utilizam-se formas que permitem essa representação em um formato
logicamente preciso. Entre alguns desses formatos, encontram-se o conceptual graph
interchange form (CGIF) e Knowledge Interchange Format (KIF) que são apresentados
por Sowa (2001b).
Em Sowa (2001b), encontra-se que a forma gráfica e a forma linear são para
comunicação entre humanos ou entre humanos e máquinas, já o CGIF e o KIF podem ser
utilizados permitir o intercâmbio do GC entre as próprias máquinas. Para representar a
sintaxe do CGIF são usados os conference labels. Considera-se como um conference label
cada nó do GC, por exemplo [Pessoa: *x] como exemplificado na Figura 3. A união dos
conference labels, forma a sintaxe do CGIF.
Forma Completa: [Pessoa: *x] [Cadeira: *y] (Na ?x ?y)
Forma simplificada: (Na [Pessoa] [Cadeira])
Figura 3 – Exemplo de representação utilizando o CGIF
A Figura 3 apresenta um exemplo das duas possíveis formas de se representar os
Grafos Conceituais utilizando o CGIF segundo Sowa (2001b). Na primeira forma
apresentada, chamada de forma completa, encontram-se outros dois elementos: os defining
labels representados por “*x” e “*y” que recebem a denominação dos conceitos existentes
no grafo; e os bound labels representados por “?x” e “?y” que são os Conceitos das
extremidades de uma Relação. Na segunda forma, chamada de forma simplificada, o
número de conference labels pode ser diminuído atribuindo os valores diretamente sem a
necessidade dos bound e defining labels.
13
Outra forma de permitir o intercâmbio do GC entre as próprias máquinas é a lógica
do Knowledge Interchange Format que, segundo Sowa (2001b), possui sua forma baseada
no cálculo de predicados. Na Figura 4 é apresentado um exemplo.
Forma KIF - (exists ((?x Pessoa) (?y Cadeira)) (Na ?x ?y))
Figura 4 – Exemplo de representação utilizando o KIF
Na Figura 4 é apresentada a sintaxe KIF de representação de Grafos Conceituais
que foi baseada no cálculo de predicados. Na forma KIF, primeiramente utiliza-se a
palavra reservada exists para representar que existe o conceito Pessoa que é “guardado” na
variável “x”, existe o conceito Cadeira que é “guardado” na variável “y” e existe a Relação
Na que possui os conceitos atribuídos a x e y como extremidades.
Ainda sobre os formatos de representação de Grafos Conceituas para comunicação
entre máquinas, propostos por Sowa (2001a), vale comentar que apresentam
complexidades maiores que as apresentadas nos exemplos acima. Tal complexidade referese à quantidade de Conceitos, Relações, Ligações e outros elementos presentes no modelo
completo dos Grafos Conceituais como, por exemplo, negações, quantificadores
existenciais, definição de proposições, definição de situações como pode ser encontrado
em Sowa (2001c). No entanto, a ferramenta proposta tem a finalidade de permitir a criação
e tradução de Grafos Conceituais no modelo básico (utilizando apenas Conceitos, Relações
e Ligações).
A construção de uma ferramenta que atenda a todas as restrições existentes no
modelo de Grafos Conceituais será apresentada neste trabalho como um trabalho futuro na
seção 5, visto que para a implementação dessa ferramenta é proposto um modelo XML
simplificado (através de uma DTD), apresentando algumas restrições existentes no modelo
GC. Nas próximas seções serão apresentados maiores detalhes sobre o modelo XML
criado e sobre o estudo de outros modelos XML existentes. Além disso, Conceitos,
Relações e suas Ligações serão mais bem explicados para permitir uma melhor
compreensão da função deles dentro dos Grafos Conceituais.
14
2.1.1 Conceitos nos Grafos Conceituais
O Conceito consiste em um dos elementos mais importantes dentro do Grafo
Conceitual. Um exemplo dessa importância está na possibilidade de existir um grafo
apenas com um Conceito. Geralmente quando se recorre a um sistema de GC o usuário
está buscando uma forma de representar as ligações existentes no conhecimento que ele
possui sobre vários conceitos do mundo real.
Um Conceito tem a finalidade de representar alguma entidade do mundo real, como
nos exemplos citados anteriormente, nos quais era necessário representar um conhecimento
sobre as “Pessoas nas Cadeiras”. Identificou-se que existem dois Conceitos “Pessoas” e
“Cadeiras”. Para outro conhecimento bastante semelhante ao anterior, “Pessoas estão
sentadas nas Cadeiras”, podem-se identificar três conceitos, que são “Pessoas”, “Sentadas”
e “Cadeiras”. O que se quer demonstrar é que um Conceito pode ser qualquer “coisa” do
mundo real e para definir se ele fará parte ou não de um Grafo Conceitual, deve-se analisar
o domínio e abstrair qual a relevância de tal entidade.
O Conceito é dividido em Tipo do Conceito e Referente do Conceito. Essa
divisão existe para permitir que um Conceito mais genérico possa ser mais especificado.
Por exemplo: constatou-se que um GC possui a necessidade de dois Conceitos do tipo
“Pessoa”. E é necessário que seja especificado que uma pessoa é “Canhota” e a outra é
“Destra”. Assim, pode-se dizer que o tipo do conceito é “Pessoa” e os referentes são:
“Canhota” e “Destra”. Então, os Conceitos serão chamados de [Pessoa: Canhota] e
[Pessoa: Destra]. Nota-se que Canhota e Destra são tipos de pessoas que possuem
características diferentes.
2.1.2 Relações nos Grafos Conceituais
As Relações são outro tipo de entidade existente nos Grafos Conceituais. Como as
restrições dos GC não permitem a ligação entre Conceitos, as Relações apresentam-se
como entidades importantes na representação do relacionamento entre Conceitos. As
Relações possuem três características importantes: Tipo da Relação, Valência da Relação e
Assinatura da Relação.
O Tipo da Relação consiste no nome que é dado à Relação. Uma boa prática de
criação de GC, utilizada pelos usuários do sistema de Grafos Conceituais, consiste em
15
atribuir ao Tipo da Relação um nome que possa representar semântica para a Relação à
qual ele foi atribuído. Por exemplo, para o seguinte conhecimento, “Pessoa na Cadeira”,
não seria semanticamente adequado criar o seguinte Grafo: [Pessoa] -> (Atributo) ->
[Cadeira], pois “atributo” pode não representar adequadamente o conhecimento que se
propõe que é o fato da Pessoa se localizar em uma Cadeira.
A Valência da Relação corresponde ao número de Conceitos que se ligam a ela. A
valência se torna um elemento importante na medida em que, através dela, não se permite
criar Relações com Tipos iguais e Valências diferentes, ou seja, se uma Relação com o
Tipo “Atributo” e com Valência “dois” foi criada dentro do GC, sempre que outra Relação
com este mesmo Tipo for criada, a Valência deverá possuir o mesmo valor. A criação de
uma Relação com Tipos iguais e valências diferentes poderia acarretar uma maior
dificuldade no entendimento de uma determinada Relação dentro do Grafo Conceitual.
Vale salientar que, para cada GC, o número de valência de uma Relação deverá ser sempre
constante para aquele GC. As valências recebem nomenclaturas especiais de acordo com
seu valor: para o valor um, a valência é chamada de “monoadic”; para dois, a valência é
chamada de “dyadic”; para o valor três, a valência é chamada de “triadic”; e para números
maiores que quatro a denominação é “n-adic” (por exemplo: “quatroadic”, “cincoadic”, e
assim por diante).
A Assinatura da Relação armazena os tipos dos Conceitos os quais ela está ligada.
Ela consiste em uma tupla composta pelos tipos dos Conceitos que estão ligados com a
Relação. Este elemento pode ser importante para guardar a ordem de apresentação dos
conceitos na interpretação do modelo por máquina. Não foi utilizada na implementação da
ferramenta, pois essa restrição não foi inserida no modelo XML criado. (maiores detalhes
na seção 2.2).
2.1.3 Ligações nos Grafos Conceituais
As Ligações nos Grafos Conceituais têm a finalidade de representar a semântica
existente entre um Conceito e uma Relação. Como foi apresentado anteriormente, quando
se deseja criar um GC, devem-se identificar quais Conceitos e Relações farão parte dele.
Por exemplo, para representar o conhecimento “Pessoa é Inteligente”, identificaram-se dois
Conceitos (Pessoa e Inteligente) e uma Relação que pode ser denominada (Atributo).
Assim, tem-se o Grafo [Pessoa] (Atributo) [inteligente]. No entanto, esse GC ainda não
16
está completo, pois não existe a forma de leitura que liga os elementos. Para permitir essa
forma de leitura é que existem as Ligações.
Nota-se que o exemplo acima, quando adicionadas suas Ligações, pode possuir
mais de uma forma de leitura. Por exemplo, uma forma correta de construção do Grafo
Conceitual acima, segundo a especificação de Sowa (2001a), seria [Pessoa] -> (Atributo) > [Inteligente]. As Ligações para este caso estão da seguinte maneira: uma chegando na
Relação (Atributo) proveniente do Conceito [Pessoa] e outra partindo da Relação
(Atributo) com destino ao Conceito [Inteligente]. A leitura correspondente é “Pessoa
possui um Atributo que é Inteligente”. Agora será apresentado o seguinte Grafo
Conceitual: [Inteligente] -> (Atributo) -> [Pessoa]. Nota-se que o GC ainda representa o
mesmo conhecimento que o anterior, no entanto, a forma de leitura das Ligações sofreu
uma pequena alteração: “Inteligente é um atributo que pertence à Pessoa”.
Todos os elementos que foram apresentados nessa seção são fundamentais para
construção de um Grafo Conceitual. Estes elementos estão presentes na ferramenta
proposta. A ferramenta permite a criação de um Grafo Conceitual utilizando a display form
e depois a transforma em um formato interpretável pela máquina. Neste caso, um arquivo
XML. Na próxima seção será apresentada a linguagem XML.
2.2
XML (eXtensible Markup Language)
O XML foi desenvolvido pela W3C (World Wide Web Consortiun) e, segundo
Anderson (2001), consiste em uma linguagem de marcação que permite a criação de
marcações específicas para cada domínio. A estrutura de um documento XML é criada em
um formato de árvore, em que um documento se inicia através de um elemento raiz que, de
acordo com a necessidade, pode ter elementos filhos vinculados a ele, mantendo assim,
uma hierarquia. O XML tem como base o modelo do SGML (Standard Generalized
Markup Language) que, em 1986, era o padrão de troca e armazenamento de dados pela
ISO (International Organization for Standardization).
O XML foi utilizado na implementação da ferramenta por apresentar algumas
características que foram importantes na criação do modelo:

Permite a criação de tags (marcações) específicas para cada domínio, no caso deste
trabalho, possibilitou a criação de marcações específicas para o domínio de Grafos
Conceituais;
17


Possibilita armazenar os dados sem a preocupação de como esses dados serão
apresentados (para isso podem-se utilizar folhas de estilo ou objetos próprios para
manipulação de XML, existentes em algumas linguagens programação); e, por fim,
Permite a criação de algumas restrições que os arquivos XML devem possuir
através do modelo definido em uma DTD (Document Type Definition).
Para que um sistema computacional consiga interpretar e validar dados descritos
em um arquivo XML é necessário que exista uma gramática que permita essa validação.
Para Anderson (2001), uma forma de se criar essa gramática está na DTD. Em outras
palavras, uma DTD pode ser utilizada para modelar um domínio e suas restrições. Na
Figura 5 serão apresentados uma DTD e um arquivo XML válido.
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
<?xml version="1.0"?>
<!DOCTYPE graph [
<!ELEMENT graph (concept?)>
<!ELEMENT concept EMPTY>
<!ATTLIST concept idConcept ID #REQUIRED
typeConcept CDATA #REQUIRED
referring CDATA #IMPLIED>
]>
<graph>
<concept idConcept="Conceito1" typeConcept="Pessoa" />
</graph>
Figura 5 – Exemplo de uma DTD e de um arquivo XML válido
A Figura 5 apresenta uma parte da DTD e de um arquivo XML para o domínio de
Grafos Conceituais. A linha 1 apresenta a especificação da versão XML utilizada, neste
caso a versão é “1.0”. Nas linhas 2 a 8 tem-se a criação da DTD. Nesta DTD, a linha 2 traz
a especificação do início da criação da DTD. A linha 3 apresenta a criação do elemento
graph e, dentro dos parênteses, existe a restrição sobre a possibilidade de um grafo poder
ter ou não um elemento concept. A linha 4 apresenta o elemento concept que é do tipo
EMPTY (vazio). Nas linhas 5 a 7 são apresentados os atributos do elemento concept que
são: idConcept do tipo identificador (ID) e obrigatório (REQUIRED); typeConcept que é
composto por texto (CDATA) e também obrigatório; e, por fim, o atributo referring que
também é composto por texto e é opcional (IMPLIED). Nas linhas 9 a 11 tem-se o arquivo
XML em que a linha 9 apresenta o elemento raiz que inicia o arquivo. A linha 10 traz o
elemento que é filho do elemento raiz e está em um nível inferior na árvore do documento.
A linha 11 finaliza o arquivo XML com a marcação de fechamento do elemento raiz que
foi aberto na linha 9. Nota-se que o elemento da linha 10 não necessitou de uma tag de
fechamento, pois trata-se de um elemento vazio (EMPTY).
18
Para implementação da ferramenta, utilizou-se uma linguagem de programação que
permite a manipulação de documentos XML, bem como sua validação por uma DTD. Uma
linguagem que permite a criação de ambientes gráficos e a manipulação XML é o
ActionScript do Flash. A próxima seção apresenta algumas características do Objeto XML
disponibilizado pelo ActionScript, bem como da tecnologia Flash.
2.3
Flash
O Flash consiste em uma tecnologia para criação de clipes de filmes dinâmicos que
possuem grande número de interações com o usuário. O Flash utiliza imagens vetoriais, em
que as imagens são construídas através de cálculos matemáticos das formas geométricas
das figuras (os vetores) (Prestes, 2003). Como resultado da utilização da descrição
geométrica das figuras tem-se um redimensionamento perfeito das imagens facilitando,
assim, a sua portabilidade.
Existem alguns elementos do Flash que foram utilizados neste trabalho que
permitem a interação do usuário com o sistema e dinamicidade dos programas criados em
Flash, entre eles: movieClips (clipes de filme) e buttons (botões). Além disso, vale
apresentar outros conceitos do Flash como o palco do filme que consiste no espaço onde o
clipe de filme será criado. Um clipe de filme, por sua vez, trabalha outros conceitos como
scene (cena), onde cada cena pode ter várias camadas e uma camada pode possui vários
níveis. Por fim, um nível é um número exclusivo que especifica o nível de profundidade no
qual um filme especificado deve ser colocado.
Para controlar a interação entre o usuário e o sistema ou entre os elementos do
sistema, existe a linguagem do Flash chamada ActionScript. O ActionScript é a linguagem
de script do Macromedia Flash MX que permite definir o comportamento que um
programa Flash terá. Através do ActionScript, os elementos inseridos no palco do filme,
bem como outros objetos instanciados (como o objeto XML), podem ser acessados.
2.3.1 Flash e XML
Segundo o Manual Flash MX (2004), os métodos e as propriedades do objeto XML
do Flash são usados para carregar, analisar, enviar, montar e manipular árvores de
documento XML. Nessa seção serão apresentadas algumas propriedades que serão
19
utilizadas na implementação da ferramenta, bem como alguns métodos que irão acessar
tais propriedades.

Algumas das propriedades do objeto XML que serão utilizadas:
XmlDecl: deve receber informações sobre a declaração de um documento XML
(possui a seguinte sintaxe: objXML.xmlDecl = "<?xml version=\"1.0\" encoding
= \"ISO-8859-1\"?>";);

DocTypeDecl: retorna informações sobre a declaração doctype do documento
XML (possui a seguinte sintaxe: objXML.docTypeDecl="<!DOCTYPE Grafo
SYSTEM \"grafo.dtd\">";);

Status: retorna um valor inteiro que indica o resultado da análise de um objeto
XML (possui a seguinte sintaxe: S = objXML.status).
Além das propriedades, serão utilizados alguns métodos como, por exemplo:
sendAndLoad() que envia o objeto XML para uma URL passada por parâmetro e recebe
o resultado do processamento. A sintaxe do método que envia e recebe o resultado do
processamento e a seguinte: objXML.sendAndLoad(strURL,auxiliarXML,”POST”);.
As propriedades e os métodos do objeto XML, em conjunto com as propriedades e
eventos dos elementos do Flash, servem como introdução ao estudo completo dos
elementos que deverão ser utilizados para implementação da ferramenta. Na seção de
resultados e discussões serão apresentadas telas da ferramenta, o formato XML que é
utilizado para validar os Grafos Conceituais criados e outros métodos do ActionScript
utilizados na implementação. Na próxima seção será apresentado o estudo realizado
durante este trabalho. Este estudo visou conhecer iniciativas na área de desenvolvimento
de softwares que fossem utilizados para interpretação de Grafos Conceituais pos sistemas
computacionais. O projeto que foi estudado é denominado de projeto CoGITaNT.
2.4
Projeto CoGITaNT
O projeto CoGITaNT consiste em um projeto Francês encabeçado pela Équipe
représentation de connaissances par des graphes desenvolvida dentro do LIRMM
(Laboratoire d'Informatique, de Robotique et de Microélectronique de Montpellier). Os
membros dessa equipe criaram uma biblioteca C++ que permite o desenvolvimento de
softwares baseados em Grafos Conceituais (CoGITaNT, 2001).
20
A biblioteca fornece mecanismos de leitura e manipulação de Grafos Conceituais
através de sistemas que possuem mecanismos de processamento de Grafos Conceituais
(CoGITaNT, 2001). Para leitura e validação dos grafos, a biblioteca oferece mecanismos
de criação e de leitura nos formatos BCGCT (formato nativo do CoGITaNT) que significa
Base de Connaissances Graphes Conceptuels Textuelle, no formato CoGXML
(Conceptual Graphs XML), formato CGIF e na forma linear (CoGITaNT, 2001). O
formato BCGCT será explicado na seção 4.1, juntamente com o CoGXML que consiste na
representação XML do BCGCT. A ferramenta desenvolvida com essa tecnologia pode ser
adquirida gratuitamente no site do projeto CoGITaNT. Um exemplo de utilização dela
pode ser visualizado na Figura 6.
C
A
B
D
Figura 6 – Tela da ferramenta desenvolvida usando a biblioteca do CoGITaNT
A Figura 6 apresenta a tela da ferramenta com as várias formas de visualização e de
edição que ela possibilita. Em “A” tem-se a forma de Grafos Conceituais aninhados; nessa
forma são permitidas as construções de elementos dentro uns dos outros.
Exemplificando: uma possível forma de leitura do Grafo presente em “A” seria:
existe um Conceito com o tipo Personne e com o Referente Pierre que é agent do Conceito
21
Penser (neste caso agent é uma Relação). O Conceito Penser possui a Relação objet e esta
Relação está ligada a Tableau: A. A tableau contém uma représentation que é composta
por uma scène que possui um attribut ligado ao Conceito Bucolique. A scène é descrita
(através do description) como sendo um Couple (representando um par ou uma dupla)
composta (composant) dos seguintes Grafos: Personne que é agent do Conceito Pêcher e
Personne que é agent do Conceito Dormir. O Couple está ligado à Relação dans que
possui o Conceito Barque que, por sua vez, está ligado à Relação sur que possui o
Conceito Lac. Em um português coloquial, o que está sendo representado é o seguinte:
“Pierre, que é uma pessoa, pensa em uma cena bucólica (fazendo referência a uma cena
simples e/ou comum) onde uma pessoa pesca e dorme em um barco sobre um lago”.
Ainda sobre a Figura 6, na parte marcada pela letra “B” apresenta-se a forma linear
de uma parte do conhecimento explicado acima. Uma forma de leitura seria: “Pensar
possui um agente que é uma pessoa que pesca dentro de um barco”. A parte representada
pela letra “C” consiste no modelo BCGCT. Por fim, a parte referente à letra “D” consiste
em uma representação, na display form, do mesmo conhecimento citado na forma linear.
A interface apresentada acima permite a edição de Grafos Conceituais aninhados,
além de permitir a manipulação na forma linear e utilizando o modelo BCGCT. Esses
recursos estão disponíveis na ferramenta porque os desenvolvedores utilizaram todos as
formas de criação de Grafos Conceituais que a biblioteca permite. Existe uma parte da
ferramenta que permite a edição de Grafos Conceituais básicos na display form, assim,
quando a ferramenta desenvolvida como parte desse trabalho for apresentada, será
realizada também uma comparação entre elas.
Como foi citado anteriormente, existe um modelo chamado CoGXML que foi
desenvolvido a partir do modelo BCGCT, na próxima seção serão apresentados os
modelos: BCGCT e o CoGXML.
2.4.1 BCGCT e CoGXML
A proposta deste trabalho de se construir uma ferramenta para criação de Grafos
Conceituais surgiu aliada à idéia de permitir que esses Grafos pudessem ser transformados
para um formato interpretável por computador, e a forma escolhida para tal interpretação
foi o modelo XML. Dentre os motivos dessa escolha tem-se a característica do XML de ser
multiplataforma, permitindo que o arquivo seja transmitido para qualquer sistema
22
computacional. Além disso, o XML permite a construção de modelos específicos para o
domínio de Grafos Conceituais e também permite a criação de algumas restrições através
das DTD’s.
Após a escolha do XML, verificou-se a necessidade de encontrar algum trabalho
relacionado a este tema para que fossem feitas comparações com um modelo que estivesse
em funcionamento. Foi assim que se conheceu o modelo CoGXML do projeto CoGITaNT.
A partir deste modelo verificou-se que ele apresentava uma quantidade de elementos maior
que a necessária para construção de Grafos Conceituais básicos (como se propõe a
ferramenta desenvolvida neste trabalho). A partir daí seguiu-se com um estudo
aprofundado sobre o projeto citado acima e verificou-se a existência de um modelo que
deu origem ao CoGXML: o BCGCT.
O BCGCT consiste em um formato textual para representação de Grafos
Conceituais básicos e também para Grafos com formatos aninhados (como o exemplo da
Figura 6 da seção anterior). Alguns exemplos que serão apresentados sobre essa forma de
representação irão tratar da parte referente à criação de Conceitos, Relações e Ligações
para permitir a comparação com o modelo XML criado para este trabalho. Na Figura 7
tem-se a representação de criação de Conceitos.
1.TConSet:
2.
ConceptTypes:
3.
Universal;
4.
Action;
5.
Attribute;
6.
Entity;
7.
Think;
8.
Sleep;
9.
Fish;
10.
Lake;
11.
Place;
12. EndConceptTypes;
13. Order:
14.
Action < Universal;
15.
Attribute < Universal;
16.
Entity < Universal;
17.
Think < Action;
18.
Sleep < Action;
19.
Fish < Action;
20.
Lake < Place;
21.
EndOrder;
22.EndTConSet;
Figura 7 – Representação de Conceitos no BCGCT
23
A Figura 7 apresenta a forma de representação dos Conceitos de um Grafo
Conceitual em BCGCT. A linha 1 possui a marcação TConSet que tem por finalidade
iniciar a representação dos Conceitos e a sua ordem. Na linha 2 existe a marcação
ConceptTypes que apresenta o início da especificação das nomenclaturas dos Conceitos,
que vai da linha 3 até a linha 11, e é encerrada na linha 12 pela marcação
EndConceptTypes que finaliza a especificação das nomenclaturas. A partir da linha 13,
com a marcaão Order até a linha 21, com a marcação EndOrder, é que se define a ordem
dos conceitos. A ordem consiste em uma novidade apresentada por essa forma de
representação. No BCGCT, o usuário não informa o Tipo do Conceito e seu Referente
separadamente. O que acontece nestes casos é o seguinte: o usuário cadastra apenas os
Tipos dos Conceitos (como Lake, Sleep, Action e Place) e depois define a “ordem de
existência” que eles seguem (como o mecanismo de herança em Orientação a Objeto).
Exemplificando, na linha 18 e 20 aparecem os Conceitos Sleep, que é considerado um tipo
de Action e Lake que é considerado um tipo de Place. Para a criação das Relações de um
Grafo Conceitual nesta forma de representação segue-se a mesma lógica, como pode ser
visto na Figura 8.
1.TRelSet:
2.
RelationTypes:
3.
attr{Signature:2,Entity,Attribute};
4.
in{Signature:2,Entity,Place};
5.
object{Signature:2,Action,Entity};
6.
EndRelationTypes;
7.
Order:
8.
EndOrder;
9.EndTRelSet;
Figura 8 – Representação de Relações no BCGCT
A Figura 8 apresenta a forma de representação das Relações de um Grafo
Conceitual em BCGCT. A linha 1 possui a marcação TRelSet que tem por finalidade
iniciar a representação das Relações e a sua ordem (esta marcação é finalizada na linha 9
com EndTRelSet). Na linha 2 existe a marcação que apresenta o início da especificação das
nomenclaturas das Relações e dos Conceitos que ela relaciona, que vai da linha 3 até a
linha 5, e é encerrada na linha 6 pela marcação que finaliza a especificação das
nomenclaturas. Assim como nos Conceitos, também é possível definir a ordem entre as
Relações, mas no exemplo da Figura 8 este recurso não foi utilizado, por isso a marcação
24
de ordem é aberta na linha 7 e encerrada na linha 8 sem conter elementos entre delas. Para
exemplificar a criação de uma relação pode-se considerar a linha 4 em que é criada a
Relação “in” que possui a valência “2” (representado por signature) e relaciona os
Conceitos Entity e Place. Os elementos apresentados acima são algumas formas de
representação do BCGCT que, como dito anteriormente, é um modelo de representação de
Grafos Conceituais em forma de texto no qual o CoGXML foi baseado.
O CoGXML possui características bastante semelhantes ao formato anterior. A
maioria dos elementos do BCGCT possui sua respectiva representação no CoGXML. Na
Figura 9 é apresentado um exemplo.
1.<conceptTypes>
2.
<ctype id="c0" label="Universal"/>
3.
<ctype id="c1" label="Action"/>
4.
<ctype id="c2" label="Attribute"/>
5.
<ctype id="c3" label="Entity"/>
6.
<ctype id="c4" label="Think"/>
7.
<ctype id="c5" label="Sleep"/>
8.
<ctype id="c6" label="Fish"/>
9.
<ctype id="c7" label="Lake"/>
10.
<ctype id="c8" label="Place"/>
11.
<order id1="c1" id2="c0"/>
12.
13.
14.
15.
16.
17.
18. </conceptTypes>
Figura 9 – Representação de Conceitos no CoGXML
A Figura 9 apresenta a forma de representação dos Conceitos de um Grafo
Conceitual em CoGXML. A linha 1 possui a marcação que tem por finalidade iniciar a
representação dos Conceitos e a sua ordem. Da linha 2 até a linha 10 tem-se a criação dos
Conceitos. Para exemplificar será utilizada a linha 9 em que o Conceito possui o atributo id
com valor “c7” e atributo label com o valor “Lake”. Após a criação dos Conceitos com
seus atributos, é então dado início à criação da ordem (seguindo a mesma lógica do
BCGCT). Por exemplo, na linha 17 ocorre a definição de que o Conceito com atributo id
de valor “c7” é um subtipo do Conceito com atributo id “c8” de valor “Place”. A definição
da ordem é realizada entre as linhas 11 e 17. Já na linha 18, existe a marcação
</conceptTypes> que finaliza a definição dos Conceitos e a ordem entre eles. Após a
25
definição dos Conceitos, definem-se também as Relações. Um exemplo pode ser
visualizado na Figura 10.
1.<relationTypes>
2.
<rtype id="r0" label="attr" idSignature="c6 c2"/>
3.
<rtype id="r1" label="in" idSignature="c6 c12"/>
4.
<rtype id="r2" label="object" idSignature="c1 c6"/>
5.</relationTypes>
Figura 10 – Representação de Relações no CoGXML
A Figura 10 apresenta a forma de representação das Relações de um Grafo
Conceitual em CoGXML. A linha 1 possui a marcação que tem por finalidade iniciar a
representação das Relações e a sua ordem (esta marcação é finalizada na linha 5). Da linha
2 até a 3 apresentam-se as marcações que especificam as Relações e os Conceitos que elas
relacionam. Para exemplificar a criação de uma relação pode-se considerar a linha 4. Nessa
linha é criada a Relação com atributo id com valor “r2”, o atributo label com valor
“object” e o atributo idSignature com o valor “c1 c6” (o último atributo contem o id dos
Conceitos que ela relaciona).
Estes foram alguns elementos necessários para composição de Grafos Conceituais
em CoGXML. Tanto este modelo XML, quanto o modelo textual BCGCT, desenvolvidos
pelo projeto CoGITaNT, possuem inúmeros elementos que permitem a criação de Grafos
que dão suporte à Grafos aninhados (como foi citado anteriormente). Para construção deste
tipo de Grafo, deve-se realizar um estudo mais completo sobre estes elementos, bem como
da biblioteca C++ que permite a construção de softwares que dão suporte a estes
elementos. Neste trabalho foi realizado apenas um estudo introdutório para auxiliar na
proposta de um modelo XML para implementação da ferramenta em Flash.
26
3 MATERIAL E MÉTODOS
Nesta seção serão apresentados os recursos utilizados durante o desenvolvimento
do trabalho. Entre eles, têm-se pesquisas bibliográficas, recursos de hardware e de
software. Os recursos utilizados de hardware e software foram disponibilizados pelos
laboratórios de informática do curso de Sistemas de Informação do CEULP/ULBRA.
3.1
Local e período
Monografia desenvolvida como requisito parcial da disciplina de Prática em
Sistemas de Informação II cursada no oitavo período do Curso de Sistemas de Informação
do CEULP/ULBRA no segundo semestre de 2004. Este trabalho foi desenvolvido como
uma pesquisa assinada pelo LABMIDIA (Laboratório de Multimídia e Hipermídia) que
disponibilizou recursos de hardware e software.
3.2
Materiais
Os recursos de hardware e software utilizados neste trabalho estão disponíveis nos
laboratórios de informática do curso Sistemas de Informação do CEULP/ULBRA, já os
recursos bibliográficos foram adquiridos na Internet (exceto os livros disponíveis no
LABMIDIA). Na subseção seguinte segue uma enumeração dos recursos utilizados.
3.2.1 Hardware

Pentium III, 750 Mhz e 128 Mb de RAM (laboratórios de informática).
27
3.2.2 Software

Microsoft Windows 2000 Professional;

Internet Explorer 6.0;





Microsoft Office XP;
Acrobat Reader 6.0;
Macromedia Flash MX;
Macromedia Fireworks MX;
Macromedia Dreamweaver MX.
3.2.3 Fontes Bibliográficas

Teses de Mestrados;

Artigos;



3.3
Trabalhos de Conclusão de Curso;
Livros;
Sites.
Metodologia
Primeiramente foi definido um modelo utilizando a DTD da linguagem XML para
validar arquivos XML gerados a partir da interpretação dos Grafos Conceituais na forma
gráfica. Depois deu-se início à implementação de uma ferramenta que pudesse permitir a
criação de Grafos Conceituais básicos e permitisse a interpretação citada acima.
A implementação foi realizada com ActionScript 1.0. A implementação iniciou-se
através da programação estruturada, no entanto, verificou-se que a utilização do paradigma
da Orientação a Objetos (através da implementação de classes) permitiria a recuperação
das informações necessárias.
28
4 RESULTADOS E DISCUSSÃO
Nesta seção serão apresentados alguns dos resultados obtidos com a realização
deste trabalho. Dentre eles, a arquitetura da ferramenta desenvolvida, o modelo XML para
interpretação de Grafos Conceituais básicos, bem como a própria ferramenta, seus
elementos e sua implementação.
4.1
Arquitetura
A visualização da arquitetura da ferramenta auxilia na compreensão da forma como
os módulos foram implementados, permite um melhor entendimento dos passos que são
realizados para o resultado que é gerado pela ferramenta e apresenta um elemento que se
propõe como continuação do trabalho. A Figura 11 apresenta a arquitetura da ferramenta.
A
B
C
Figura 11 – Arquitetura da ferramenta
A ferramenta gráfica para construção de hiperdocumentos educacionais pode ser
dividida em três partes distintas no que diz respeito à implementação. A primeira parte,
indicada pela letra “A” na Figura 11, consiste no espaço para edição dos Grafos
Conceituais no modo gráfico, a segunda parte, indicada pela letra “B” na Figura 11, diz
respeito à interpretação do modo gráfico para um Formato XML e a terceira parte, ,
29
indicada pela letra “C” na Figura 11, refere-se à criação dos hiperdocumentos educacionais
a partir do formato XML.
No desenvolvimento deste trabalho, as partes implementadas estão marcadas por
um retângulo pontilhado na Figura 11. Ou seja, a ferramenta permite a criação de Grafos
Conceituais básicos em modo gráfico (possibilitando a criação de Conceitos, Relações e
Ligações) e realiza a tradução para um formato XML. A terceira parte, referente à geração
dos hiperdocumentos educacionais é apresentada como continuação deste, na seção 5. Na
próxima seção será apresentado o modelo XML utilizado na interpretação dos Grafos
Conceituais.
4.2
Modelo XML
O modelo XML desenvolvido neste trabalho permite a criação e validação de
Grafos Conceituais básicos (leia-se: Conceitos, Relações e Ligações). Para apresentar este
modelo, deve-se primeiramente apresentar a DTD que valida os documentos para que se
entenda o valor de cada elemento. Na Figura 12 tem-se a DTD do modelo XML.
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
<!ELEMENT graph (concept*, relation*, link*)>
<!ELEMENT concept EMPTY>
<!ATTLIST concept idConcept ID #REQUIRED
typeConcept CDATA #REQUIRED
referring CDATA #IMPLIED>
<!ELEMENT relation EMPTY>
<!ATTLIST relation idRelation ID #REQUIRED
typeRelation CDATA #REQUIRED
valence CDATA #REQUIRED>
<!ELEMENT link EMPTY>
<!ATTLIST link idLink ID #REQUIRED
cid IDREF #REQUIRED
13:
rid IDREF #REQUIRED>
Figura 12 – DTD do modelo XML criado para ferramenta
A Figura 12 apresenta a DTD do modelo XML criado para validação dos Grafos
Conceituais criados na ferramenta desenvolvida neste trabalho. A linha 1 apresenta a
criação do elemento graph que possui: zero ou mais elementos concept, relation e link. A
restrição de zero ou mais, que é representado pelo “*” ao lado direito de cada elementos
(vide linha 1) se faz necessária, pois um Grafo Conceitual pode ser do tipo vazio (sem
elementos) ou do tipo simples (com apenas um Conceito).
30
A linha 2 apresenta o elemento concept que é do tipo EMPTY (ou seja, elemento
vazio). Nas linhas 3 a 5 são apresentados os atributos do elemento concept que são:
idConcept do tipo identificador (ID) obrigatório (REQUIRED); typeConcept
que é
composto por texto (CDATA) e também obrigatório; e, por fim, o atributo referring que
também é composto por texto e é opcional (IMPLIED).
A linha 6 apresenta o elemento relation que é do tipo EMPTY (assim como o
concept). Nas linhas 7 a 9 são apresentados os atributos do elemento relation que são:
idRelation do tipo identificador (ID) obrigatório (REQUIRED); typeRelation
que é
composto por texto (CDATA) e também obrigatório; e, por fim, o atributo valence que
também é composto por texto e é obrigatório.
A linha 10 apresenta o elemento link que é do tipo EMPTY (assim como o concept
e o relation). Nas linhas 11 a 13 são apresentados os atributos do elemento link que são:
idLink do tipo identificador (ID) obrigatório (REQUIRED); cid e rid que são do tipo
(IDREF) que fazem referencia a um elemento do tipo (ID) que esteja presente no
documento XML.
Na Figura 13 será apresentado um exemplo de Grafo Conceitual com seu
documento XML correspondente.
Figura 13 – Exemplo de Grafo na Display Form com o código XML correspondente
O Grafo Conceitual apresentado na Figura 13 pode ser lido da seguinte forma:
“Professor, que é um tipo de pessoa, está na Cadeira”. Existem dois Conceitos [Pessoa:
Professor] e [Cadeira] e estes possuem a Relação (Na). Ainda na Figura 12 tem-se o código
XML que representa o Grafo Conceitual. As linhas 1 e 2 apresentam marcações que
31
representam declarações do documento XML. A linha 3 apresenta a tag raiz que inicia o
grafo (o grafo é finalizado na linha 9).
A linha 4 apresenta o Conceito identificado pelo atributo idConcept com valor
“Conceito1”. Além deste atributo identificador, ainda existem outros dois atributos que são
typeConcept com valor “Pessoa” e referring com valor “Professor”. A linha 5 apresenta o
outro Conceito presente no Grafo que é identificado pelo atributo idConcept com valor
“Conceito2” e o outro atributo é typeConcept com valor “Cadeira” (nota-se que este
Conceito não possui um referring atribuído.
A linha 6 apresenta a Relação identificada pelo atributo idRelation com valor
“Relacao1”. Além deste atributo identificador, ainda existem outros dois atributos que são
typeRelation com valor “Na” e valence com valor “2”.
A linha 7 apresenta a Ligação identificada pelo atributo idLink com valor “Ligacao1” que,
além deste atributo identificador, ainda possui outros dois atributos que são cid com valor
“Conceito1” e rid com valor “Relacao1” que fazem referência aos ID’s dos elementos que
ela liga. A linha 8, analogamente à linha 7, apresenta a Ligação identificada pelo atributo
idLink com valor “Ligacao2”. Além deste atributo identificador, ainda possui outros dois
atributos que são cid com valor “Conceito2” e rid com valor “Relacao1” que fazem
referência aos ID’s dos elementos que ela liga. A ferramenta, seus componentes e a sua
implementação serão apresentados na próxima seção.
4.3
Ferramenta desenvolvida
A ferramenta desenvolvida neste trabalho foi criada utilizando a tecnologia Flash e
a linguagem ActionScript 1.0. O Flash permite a criação de ambientes gráficos para
interação com o usuário através de seus elementos. A ferramenta permite a criação de
Grafos Conceituais básicos (utilizando Conceitos, Relações e Ligações) e transforma este
grafo para um formato XML. A Figura 14 representa a tela da ferramenta com um Grafo
Conceitual criado.
32
A
B
C
Figura 14 – Tela da ferramenta para construção de Grafos Conceituais
A Figura 14 apresenta a tela da ferramenta para a construção de Grafos Conceituais.
Antes de descrever alguns elementos de interface individualmente, além das restrições para
construção de Grafos Conceituais que foram implementadas, será ilustrada nessa seção, a
tela da ferramenta.
A tela da ferramenta pode ser dividida em três partes de acordo com sua função.
Por exemplo: a parte superior da ferramenta (Figura 14 – A) consiste no espaço destinado a
abrigar as opções de construção do Grafo Conceitual, ou seja, caixas de texto para inserção
de texto e botões para criação dos elementos dos Grafos Conceituais; na parte central da
ferramenta (Figura 14 – B) o usuário poderá posicionar os elementos; e na parte inferior
(Figura 14 – C) a ferramenta apresenta informações para usuário (como mensagens de erro
ou confirmação de operação).
33
Para mostrar os elementos utilizados na implementação individualmente, esta seção
será subdividida em: elementos gráficos do Flash (e estrutura da implementação) e
restrições do GC que foram implementadas.
4.3.1 Elementos da Interface
Os elementos de interface do Flash MX que foram utilizados são: movieclips para
criação dos Conceitos, Relações e Ligações; buttons para criar os botões que inserem os
elementos do Grafo Conceitual na ferramenta, além do botão para transformação do GC no
formato XML; input text para permitir que o usuário digite valores como tipo do Conceito
e tipo da Relação; combobox para escolha da valência da Relação; e listbox para
representar a comunicação da ferramenta com o usuário (apresentando informações sobre
restrições para determinadas tentativas de ações dos usuários). Nessa seção, será
apresentado cada elemento de interface, bem como sua funcionalidade e seu código
ActionScript correspondente. A Figura 15 apresenta alguns movieclips utilizados.
Figura 15 – Movieclips utilizados na ferramenta (Conceito e Relação)
A figura acima apresenta dois elementos utilizados na ferramenta que são do tipo
movieclip. Para a definição dos Conceitos (Figura 15 – A) e das Relações (Figura 15 – B),
o movieclip correspondente a cada um, foi desenhado com tamanho fixo e inserido na
biblioteca do Flash.
Assim, para que eles sejam inseridos no espaço de trabalho da ferramenta e fiquem
visíveis ao usuário, é invocado o método que anexa o movieclip (a sintaxe deste método é a
seguinte):
attachMovie("NomeNaBiblioteca",Nome,profundidade);.
Dentro dos movieclips Conceito e Relação existe um input text que recebe um valor
digitado pelo usuário (o espaço para o usuário informar este valor será apresentado
posteriormente). A Figura 16 apresenta os outros elementos do tipo movieclip que foram
utilizados.
34
Figura 16 – Movieclips utilizados na ferramenta (Ligação)
A Figura 16 apresenta os elementos movieclip que compõem a Ligação. Apesar de
ser do tipo movielclip, como os da Figura 15, eles apresentam características diferentes.
Para desenhar o corpo da Ligação (Figura 16 – A), utiliza-se o movieclip de outra forma
como é apresentado na Figura 17 que representa a função que desenha o corpo da Ligação.
1:
2:
3:
4:
5:
6:
function desenhaLigacao(){
var linha = createEmptyMovieClip("Ligacao",
2000+_global.numeroLigacao);
linha.lineStyle(2, 0x000000, 100);
linha.moveTo(_global.comecaX,_global.comecaY);
linha.lineTo(_global.fimX, _global.fimY);
}
Figura 17 – Função que desenha o corpo da Ligação
A Figura 17 que representa a codificação da função que desenha o corpo da
Ligação através da API 2D do Macromedia Flash MX. A linha 1 apresenta a declaração da
função. A linha 2 apresenta a declaração de uma variável que recebe o valor do método
que cria um movieclip vazio para que seja desenhada uma linha, neste caso o corpo da
Ligação (Figura 16 – A). A linha 3 possui valores atributos da linha como: espessura e cor.
A linha 4 apresenta o método que irá marcar o ponto de início da linha; e a linha 5
apresenta o método que irá desenhar a linha até o ponto passado por parâmetro (entende-se
como ponto uma coordenada X,Y no plano bidimensional).
A ponta da Ligação (Figura 16 – B) é um elemento movieclip que possui
características semelhantes aos da Figura 15 no que diz respeito à criação e forma de
inserção na ferramenta. No entanto, quando o elemento é inserido (sempre no ponto final
do corpo da Ligação), são realizados cálculos matemáticos que retornam o valor do ângulo
que a ponta da Ligação deve ser rotacionado. Essa rotação tem a finalidade de acompanhar
a inclinação do corpo da Ligação quando necessário (nos códigos em anexo tem-se a
apresentação e explicação dos cálculos matemáticos para rotação da ponta da Ligação).
A Figura 18 apresenta os buttons que foram utilizados na implementação da
ferramenta. No entanto, para um melhor entendimento das instâncias das classes que são
criadas com alguns dos buttons, vale apresentar a estrutura das classes utilizadas na
35
implementação. Foram criadas três classes (Conceito, Relacao e Ligacao) que são
instanciadas dadas determinadas ações do usuário. Seguindo o paradigma da Orientação a
Objetos (Meyer, 1989), as classes foram criadas sobre a estrutura apresentada na Figura 18.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
function nomeDaClasse(){
//Construtor
//Atributos
this.id = valor;
this.getId = getId;
}
//Métodos
function getId(){
return this.id;
}
Figura 18 – Exemplo da estrutura das classes implementadas
A Figura 18 apresenta a estrutura básica das classes implementadas na ferramenta.
Na linha 1 é criado o nome da classe. Nas linhas 2 a 5 tem-se o espaço reservado para o
construtor. No exemplo, o construtor atribui um valor para o atributo id (linha 4) e cria
outro atributo que receberá a implementação de um método (linha 5). Entre as linhas 7 a 10
existe a implementação do método que foi definido no construtor (linha5). Vale comentar
que para cada classe existem atributos e métodos específicos que serão explicados à
medida que os elementos de interface vão sendo demonstrados nessa seção.
Sobre a declaração de classe da Figura 18, que representa a sintaxe da declaração
de classe do ActionScript, pode-se dizer que ela possui uma sintaxe de declaração de classe
diferenciada em relação à Orientação a Objetos no que diz respeito à sua estruturação, pois
tal sintaxe é bastante semelhante à sintaxe do JavaScript que é baseada na ECMA-262
(1999).
O código completo de cada classe não será apresentado devido ao seu tamanho,
mas a codificação completa da ferramenta está disponível nos anexos deste trabalho. Na
Figura 19, abaixo, são apresentados os buttons.
A
B
C
D
Figura 19 – Buttons utilizados na ferramenta
A Figura 19 apresenta os quatro elementos do tipo button que foram utilizados na
ferramenta. Nessa seção, a funcionalidade de cada botão será explicada apenas
36
textualmente, já os códigos de ActionScript de cada botão serão apresentados e explicados
separadamente na seção 4.3.2 que diz respeito às restrições de criação dos Grafos
Conceituais.
Na Figura 19 (A), o quadrado tem a finalidade de fazer algumas verificações das
restrições sobre a criação dos Conceitos e depois instanciar um objeto da Classe Conceito.
No construtor do Conceito, será atribuído valor aos seguintes atributos: idConceito
receberá "Conceito"+_global.numeroConceito;.
A parte de código representada por _global.numeroConceito consiste em
uma variável global que controla o número de Conceitos criados. Essa variável tem a
finalidade de fazer com que o idConceito sempre possua um valor único); os atributos
tipoConceito e referente receberão valores informados pelo usuário; e o
noConceito receberá seu valor em forma de um nó XML com os atributos que foram
citados acima (por exemplo, "<concept
idConcept=\""+idConceito+"\"
typeConcept=\""+tipoConceito+"\"referring=\""+referente+"\"/>
";).
A elipse (Figura 19 – B) tem a finalidade de fazer algumas verificações das
restrições sobre a criação das Relações (tais restrições serão explicadas na próxima seção)
e depois instanciar um objeto da Classe Relacao.
No construtor da Relacao, será atribuído valor aos seguintes atributos:
idRelacao receberá "Relacao"+_global.numeroRelacao.
A variável (_global.numeroRelacao é uma variável global que controla o
número de Relações criadas. Essa variável tem a finalidade fazer com que o idRelacao
sempre possua um valor único); os atributos tipoRelacao e valencia receberão
valores informados pelo usuário; e o noRelacao receberá seu valor em forma de um nó
XML
com
os
atributos
citados
acima
(por
exemplo,
"<relation
idRelation=\""+idRelacao+"\" typeRelation=\""+tipoRelacao+"\"
valence=\""+valencia+"\" />";).
O botão ligação (Figura 19 – C) possui um código que atribui à variável
_global.botaoLigacao o valor true. Essa variável é global e tem a finalidade de
representar que o botão ligação foi clicado, ou seja, a ferramenta está pronta para que uma
Ligação seja criada (o processo de instanciação de um objeto da classe Ligação será
apresentado posteriormente).
37
O botão XML (Figura 19 – D), assim como os botões conceito e relação, também
realiza verificação de algumas restrições para criação do Grafo Conceitual e depois invoca
uma função responsável pela instanciação do objeto XML (este objeto XML corresponde a
interpretação do GC na forma gráfica para um formato XML interpretável por máquina). A
função que instancia o objeto XML será apresentada na Figura 20.
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
_global.criaXML = function(){
var strNos = "", i;
for(i = 0; i < _global.vetorConceito.length; i++){
strNos = strNos + _global.vetorConceito[i].getNoConceito();
}
for(i = 0; i < _global.vetorRelacao.length; i++){
strNos = strNos + _global.vetorRelacao[i].getNoRelacao();
}
for(i = 0; i < _global.vetorLigacao.length; i++){
strNos = strNos + _global.vetorLigacao[i].getNoLigacao();
}
var strURL = "http://skywalker/ImplCLASSE/default.asp";
objXML = new XML("<graph>" + strNos+ "</graph>");
objXML.docTypeDecl = "<!DOCTYPE graph SYSTEM \"grafoRincon.dtd\">";
objXML.xmlDecl="<?xml version=\"1.0\"encoding=\"ISO-8859-1\"?>";
if(objXML.status == 0){
var auxXML = new XML();
auxXML.onLoad = function(sucess){
if (sucess)
_root.listBox.addItem("Informação: Formato XML criado com
SUCESSO");
else
_root.listBox.addItem("Erro: Servidor não encontrado");
}
objXML.sendAndLoad(strURL, auxXML, "POST");
}
else{
trace("Erro: Arquivo XML não é válido");
}
}
Figura 20 – Função que instancia o objeto XML
A Figura 20 apresenta a instanciação do objeto XML, mas vale lembrar que existem
verificações de restrições anteriores à chamada desta função que serão apresentadas
próxima seção.
Na linha 1 é definido o nome da função. A linha 2 apresenta a instanciação de
algumas variáveis auxiliares dentro da função. Entre as linhas 3 à 11, é montada uma string
com os valores dos nós de cada objeto das três classe (nota-se que essa string é montada
através da varredura realizada nos vetores que guardam as instâncias das três classes). A
linha 12 apresenta a declaração da variável que recebe a URL da página que irá salvar o
objeto XML em um arquivo.
38
Na linha 13 instancia-se um objeto, do tipo XML, que recebe por parâmetro o
documento que é formado com o elemento raiz, concatenado com a string que recebeu o
valor de cada nó. As linhas 14 e 15 trazem as declarações de versão do XML que está
sendo utilizada e do arquivo DTD que deve ser utilizada na validação. A linha 16 verifica
se o status do arquivo é “0” (este valor corresponde a um XML bem formado) e na linha
27 tem-se o erro que informa se o documento XML não é válido. Entre as linhas 17 e 24
tem-se o trecho de código responsável pelo envio do objeto XML para um servidor e por
obter a resposta sobre a criação do arquivo XML. Na próxima figura, a 21, serão
apresentados os elementos do tipo input text e o elemento do tipo combobox.
A
B
D
C
Figura 21 – Elementos do tipo Input text utilizados na implementação
A Figura 21 apresenta os cinco elementos do tipo inuput text que são utilizados na
ferramenta. Dos cinco, três elementos fazem parte da criação do Conceito e da Relação
(Figura 21 – A). Eles possuem a função de permitir que o usuário informe um valor para os
elementos. Para o Conceito, os valores a serem informados são Tipo e Referente e no caso
da Relação, o Tipo.
Os itens marcados como “B” e “C” na Figura 21 também são do tipo input text. No
entanto, eles recebem os valores digitados pelo usuário em “A”. Para fazer a atribuição em
“B”
utiliza-se
o
seguinte
código:
eval(idConceito).textoConceito.text=_root.tipoConceito.text+"
:"+_root.referenteConceito.text;.
Nota-se que neste código existe a função eval, que acessa o movieclip pelo nome
passado por parâmetro. Assim o input text da (Figura 21 – B) que está dentro do movieclip
pode receber os valores digitados nos input text referentes à criação do Conceito (Figura
21 – A).
39
Para fazer a atribuição em “C”, faz-se uso do seguinte código que é bastante
semelhante ao anterior (aquele que foi apresentado para a criação do Conceito):
eval(idRelacao).textoRelacao.text=_root.tipoRelacao.text;
onde também se utiliza a função eval, que acessa o movieclip pelo nome passado por
parâmetro. Com isso o input text da (Figura 21 – B) que está dentro do movieclip pode
receber os valores digitados nos campos referentes à criação da Relação (Figura 21 – A).
O elemento combobox (Figura 21 – D) consiste em uma lista predefinida de valores
que podem ser escolhidos para definir a valência da Relação. No caso desta ferramenta
foram listados seis elementos: “monoadic”, “dyadic”, “tresadic”, “quatroadic”, “cincoadic”
e “seisadic” (a valência não possui um limite, no entanto, para a ferramenta foi apresentado
o limite “seis” para realização dos testes). Vale comentar que existem algumas restrições
na atribuição destes valores descritos acima e que elas serão exemplificadas na próxima
seção. A Figura 22, abaixo, apresenta o elemento de interface do tipo listbox.
Figura 22 – Elemento de interface do tipo listbox
A Figura 22 apresenta o elemento de interface do tipo listbox. Como foi dito
anteriormente, ele tem a finalidade de apresentar algumas restrições sobre determinadas
tentativas de ações dos usuários. Na Figura 22 existem alguns exemplos de erros que foram
apresentados, erros referentes a algumas restrições de criação de um Grafo Conceitual e
que serão explicados na próxima seção.
4.3.2 Restrições dos Grafos Conceituais
Nessa seção serão apresentados os códigos de implementação que tem a finalidade
de seguir as regras de criação de um Grafo Conceitual básico, propostas por Sowa (2001a),
além das restrições do modelo XML apresentado na seção 4.1.1. A primeiras restrições a
serem tratadas serão sobre: a necessidade de um Conceito necessitar de Tipo definido
40
(sendo que o Referente é opcional) e também sobre um Conceito não poder se repetir
dentro de GC. Para isso apresenta-se a Figura 23.
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
on(press){//Evento disparado quando botão conceito é pressionado
if(textTipoConceito == undefined){
_root.listBox.addItem("Erro: Digite o tipo do conceito");
}
else{
if(_global.existeConceito()){
_root.listBox.addItem("Erro: Esse conceito já existe");
}
else{
_global.numeroConceito++;
_global.vetorConceito.push(new classeConceito());
}
}
Figura 23 – Restrições na criação de um Conceito
A Figura 23 apresenta as restrições que a ferramenta impõe para a criação de um
Conceito. Essas restrições foram implementadas dentro do evento que é acionado quando o
botão conceito é pressionado (como descrito na linha 1).
Na linha 2 é realizada uma verificação sobre a existência de texto na variável
textTipoConceito que foi definida como variável do input text tipoConceito.
Se esta variável estiver vazia é adicionado um erro no listbox (linha 3). Caso exista algum
valor digitado para o Tipo do Conceito, então é realizada uma nova verificação na linha 6.
Essa verificação é feita através da chamada da função que varre o vetor procurando
por um Conceito com os mesmos valores do que se está tentando criar. Caso a função
encontre este Conceito (ou seja, igual ao que se está tentando criar), um erro é adicionado
no listbox (linha 7). Caso a função não encontre um valor igual, então é instanciado um
Conceito que é adicionado ao seu vetor correspondente (linha 11). Os códigos da Figura
24, abaixo, são referentes às restrições da criação de uma Relação.
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
on(press){//Envento disparado quando o botão Relação é pressionado
if((textTipoRelacao == undefined)){
_root.listBox.addItem("Erro: Digite o tipo da relação");
}
else{
if(_global.existeRelacao()){
_root.listBox.addItem("Atenção: Essa relação já existe no grafo
e para sua valência prevalecerá o valor anterior");
_global.numeroRelacao++;
var novaRelacao = new classeRelacao();
novaRelacao.setValencia(_global.valenciaEncontrada);
_global.vetorRelacao.push(novaRelacao);
}
else{
41
15:
16:
17:
18:
}
}
}
_global.vetorRelacao.push(new classeRelacao());
Figura 24 – Restrições na criação de uma Relação
A Figura 24 apresenta as restrições que a ferramenta impõe para a criação de uma
Relação. Essas restrições foram implementadas dentro do evento que é acionado quando o
botão Relação é pressionado (como descrito na linha 1). Na linha 2 é realizada uma
verificação sobre a existência de texto na variável textTipoRelacao que foi definida
como variável do input text tipoRelacao. Se esta variável estiver vazia é adicionado
um erro no listbox (linha 3). Caso exista algum valor digitado para o Tipo da Relação,
então é realizada uma nova verificação na linha 6.
Essa verificação é feita através da chamada da função que varre o vetor procurando
por uma Relação com o mesmo valor de Tipo do que se está tentando criar. Caso a função
encontre uma Relação com o Tipo igual ao que se está tentando criar, uma mensagem de
atenção é adicionada no listbox (linha 7).
Independente do retorno da função, é instanciado um objeto da classe Relação que é
adicionado ao seu vetor correspondente (linhas 11 e 15). A diferença está no fato de que,
quando a função encontra uma Relação com o Tipo igual ao da que se está querendo criar,
uma variável global recebe o valor da valência que a função encontrou e depois é
repassado este valor para a Relação instanciada (linhas 9 e 10). Isso corresponde à restrição
dos Grafos Conceituais que exige que uma Relação com o mesmo Tipo tenha sempre a
valência igual dentro de um mesmo GC. Os códigos presentes na Figura 25, abaixo, são
referentes às restrições da criação de uma Ligação.
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
if(_global.botaoLigacao){
_global.cidAtual = this;
_global.criandoLigacao = true;
_global.botaoLigacao = false;
}
else{
if(_global.primeiroEscolhido){
if((_global.cidAtual.getIdConceito() == null) ||
_global.ridAtual.getIdRelacao() == null)){
_root.listBox.addItem("Erro:Ligação incorreta. Mesmo elemento");
}
else{
if(criaLigacao(this,_global.ridAtual.getIdRelacao(),"Conceito")){
_root.listBox.addItem("Erro:Ligação incorreta.Elementos já
ligados");
}
else{
42
16:
17:
18:
19:
20:
21:
22:
23:
24:
_global.numeroLigacao++;
_global.vetorLigacao.push(new classeLigacao());
desenhaLigacao();
_global.ridAtual.setLigacoesDaRelacao(
_global.cidAtual.getIdConceito());
_global.cidAtual.setLigacoesDoConceito(
_global.ridAtual.getIdRelacao());
}
}
}
}
Figura 25 – Restrição na criação de uma Ligação
A Figura 25 apresenta a implementação de algumas restrições sobre a criação de
uma Ligação. Esse código está presente no evento onPress do Conceito, mas neste
mesmo evento da Relação existe um código semelhante.
O código da Figura 25 pode ser descrito da seguinte forma. O código entra as linhas
1 a 5 é executado quando o Conceito é o elemento de qual a Ligação está partindo. A linha
1 verifica se o botão ligação foi clicado fazendo com que a sua variável correspondente
receba true (como foi explicado anteriormente). A linha 2 atribui o próprio objeto a uma
outra variável global. Esta variável é utilizada como uma variável auxiliar na criação da
Ligação. A linha 3 atribui o valor true a uma outra variável global que, por sua vez, tem
a finalidade de indicar que a Ligação está sendo criada e que o primeiro elemento já foi
escolhido. A linha 4 atribui o valor false à variável que indica que o botão ligação foi
clicado. Isso se faz necessário, pois, caso contrário, o programa executaria o primeiro
bloco do código novamente quando chegar no evento do segundo elemento da Ligação.
O código entra as linhas 7 e 23 é executado quando o Conceito é o elemento cuja
Ligação está chegando. A linha 7 faz a verificação sobre a variável global que representa
que uma ligação está sendo criada, sendo que o primeiro elemento já foi escolhido. A linha
8 verifica se os elementos que estão se ligando são do mesmo Tipo e, caso a verificação
seja verdadeira, adiciona um erro ao listbox (linha 9) (vale lembrar que isso é uma restrição
dos GC segundo Sowa (2001a)).
A linha 12 verifica, através de uma função, se já existe Ligação entre os elementos
que se está tentando ligar. A função realiza uma varredura no vetor de Ligações do
Conceito (que é um atributo da classe), verificando se o Conceito já está ligado àquela
Relação. Caso a função retorne true, é inserido um erro no list Box (linha 13). Caso
nenhuma restrição seja encontrada, então é instanciado um objeto da classe Ligação que é
adicionado ao seu vetor correspondente (linha 17).
43
Na linha 18 é invocada a função que desenha a Ligação (a codificação dessa função
foi explicada na seção 4.2.1). E, por fim, nas linhas 19 e 20, são adicionados aos vetores de
cada classe os identificadores dos elementos que foram ligados (neste caso, o vetor que é
preenchido é o que foi declarado como atributo de cada classe).
A diferença que este código possui, quando utilizado na classe Relação, está em
uma verificação a mais, que é realizada com intuito de descobrir se a Relação já não fez
todas as Ligações que sua valência permite. Isso é feito através de uma função que
compara o número de vezes que o identificador de determinada Relação aparece dentro do
vetor de Ligações e, caso seja igual à valência da Relação, não permite que o usuário crie
mais Ligações que envolvam aquela Relação. A Figura 26, abaixo, apresenta as restrições
existentes para criação do XML.
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
on(press){ //Envento disparado quando o botão XML é pressionado
if(_global.vetorConceito.length > 1){
if(_global.vetorLigacao.length > 0){
if(_global.verificaLigacao()){
_global.criaXML();
}
else{
_root.listBox.addItem("XML não pode ser criado. Existem
relações com ligações faltando");
}
}
else{
}
}
else{
if((_global.vetorConceito.length == 0) or
(_global.vetorConceito.length == 1)){
if(_global.vetorRelacao.length > 0){
_global.criaXML();
}
else{
}
}
else{
_global.criaXML();
}
}
}
}
Figura 26 – Restrições na criação do formato XML
44
A Figura 26 tem a finalidade de representar o código implementado para as
restrições da geração do GC no formato XML. Esse código está dentro de um evento do
botão XML que é disparado quando ele é pressionado (linha 1). O trecho de código que
está entre as linha 2 e 14 é executado quando o GC possui mais de um Conceito. Essa
verificação na linha 2 faz-se necessária, pois, caso não existam elementos, deverá ser
verificado se o Grafo é vazio (sem elementos) ou se o Grafo é simples (onde existe apenas
um Conceito) como na linha 16.
Considerando que o primeiro bloco de códigos será executado (linhas 2 à 14), a
linha 3 realiza uma verificação sobre a existência de Ligações. Caso existam Ligações no
GC, é necessário fazer uma outra verificação para saber se todas as Relações foram ligadas
na quantidade informada em sua valência (linha 4). Se não existirem Ligações, então é
adicionado um erro ao list Box na linha 12.
A verificação a respeito da quantidade especificada na valência, para cada Relação,
é realizada por uma função que varre os vetores de Relação e de Ligação, comparando a
valência com a quantidade de vezes que a Relação foi ligada. Caso todas as Ligações
tenham sido feitas corretamente, a função que cria o XML é invocada na linha 5 (vale
lembrar que a codificação dessa função foi apresentada na seção 4.2.1), caso contrário, é
adicionado um erro ao list Box na linha 8.
O segundo bloco de código, entre as linhas 16 e 30, diz respeito à verificação se um
GC é vazio ou simples. Caso seja constatado que existe apenas um Conceito, ou que não
existe nenhum (linha 16), é realizada uma outra verificação para saber se existe Relação no
GC (linha 17). Caso exista Relação, deve-se verificar se sua valência está sendo respeitada
(linha 18), caso não exista Relação, o objeto XML é criado (linha 26). Se a verificação da
valência estiver sendo respeitada (linha 18), então o objeto XML é criado (linha 19), do
contrário, é adicionado um erro ao list Box na linha 22. Na próxima seção será apresentado
um exemplo de utilização da ferramenta.
4.3.3 Exemplo de utilização da ferramenta
Após apresentar alguns elementos de interface e as restrições que foram
implementadas, será apresentado nessa seção um exemplo de utilização da ferramenta.
Para este exemplo considera-se o seguinte conhecimento sobre Árvores da disciplina de
Estruturas de Dados: o Conceito Est de Da (representando Estruturas de Dados) possui um
45
Tipo e esse Tipo é o Conceito Árvore. O Conceito Árvore, por sua vez possui PréRequisitos: Ponteiro e Recursividade. Além disso, o Conceito Árvore pode possuir um
exemplo e este exemplo é Árvore Binária. O exemplo da construção deste conhecimento
está na Figura 27.
Figura 27 – Exemplo de utilização da ferramenta
A Figura 27 consiste em um exemplo de utilização da ferramenta com os elementos
gráficos e as restrições para criação de um Grafo Conceitual como foi apresentado na seção
anterior. Na Figura 28, abaixo, é demonstrado o formato XML, correspondente ao GC
criado acima.
46
Figura 28 – Exemplo de GC no formato XML
A Figura 28 representa o GC ilustrado, no seu modo gráfico, pela Figura 27. A
apresentação do formato XML no browser, foi criada para que o resultado do Grafo
Conceitual que a ferramenta gera, possa ser visualizado, no entanto, vale comentar que este
formato XML pode ser enviado para um servidor através dos códigos do flash. No
servidor, ele pode ser acessado por alguma linguagem de programação para WEB,
permitindo a criação dos hiperdocumentos educacionais.
O servidor foi configurado com intuito de apresentar o resultado que é gerado pela
ferramenta, ou seja, o documento XML correspondente ao Grafo Conceitual criado, mas
não será mais bem explicado por não fazer parte do foco principal deste trabalho. No
entanto, o processamento do documento XML pelo servidor, juntamente com a criação dos
hiperdocumentos educacionais, consiste em um trabalho futuro (como será descrito na
seção 5).
47
5 CONCLUSÕES FINAIS E TRABALHOS FUTUROS
A utilização de Grafos Conceituais na representação de conhecimento e na
comunicação entre sistemas computacionais vem sendo utilizada desde 2001 pela equipe
francesa denominada de Équipe représentation de connaissances par des graphes. Esta
equipe desenvolveu um projeto que, dentre outros resultados, disponibilizou uma
biblioteca C++ para a implementação de ferramentas que dão suporte à criação e
interpretação de Grafos Conceituais.
Os Grafos Conceituais são utilizados, por esta equipe, na comunicação entre robôs.
A utilização de Grafos Conceituais na comunicação entre robôs apresentou resultados
satisfatórios e fez com que eles, além da biblioteca, desenvolvessem uma ferramenta que
dá suporte a vários elementos dos Grafos Conceituais como, por exemplo: negação, criação
de situações, criação de preposições, disjunções, entre outros. Vale comentar que a
biblioteca permite a criação de Grafos Conceituais complexos ou básicos, sendo que, quem
vai decidir sobre a quantidade de elementos que deseja-se implementar, é o desenvolvedor.
Visto que eles trabalham com intuito de permitir a comunicação entre sistemas
computacionais com suporte a todos os elementos de Grafos Conceituais propostos por
Sowa (2001a), os modelos de interpretação de Grafos Conceituais por máquina, propostos
por eles (o BCGCT e o seu correspondente em XML: o CoGXML), são bastantes
complexos no que diz respeito à quantidade de elementos e de ligações entre eles. Devido a
isso, o modelo completo utilizado por eles pode se tornar complexo para um usuário que
venha a utilizar a ferramenta para criação de hiperdocumentos educacionais.
Os Grafos Conceituais podem ser utilizados para representação do conhecimento
através de hiperdocumentos educacionais, e a união desses dois elementos em uma só
ferramenta, tornar-se-ia interessante na medida em que poderia ajudar usuários leigos no
que diz respeito à criação de hiperdocumentos educacionais.
48
Pode-se concluir, através da implementação desta ferramenta, que a tecnologia
Flash, aliada aos elementos da linguagem XML, permite a criação de ferramentas gráficas
que atendem às necessidades de uma aplicação que dê suporte à criação de Grafos
Conceituais básicos e, além disso, realize a interpretação deste GC para um formato XML.
Através deste trabalho, entretanto, não é possível determinar se o modelo XML criado para
implementação da ferramenta deste trabalho pode ser utilizado para especificação de
conteúdo didático em hiperdocumentos educacionais, pois tais hiperdocumentos têm
requisitos diferenciados em relação a hiperdocumentos tradicionais no que diz respeito à
necessidade de coerência das informações ali presentes. Assim, seria necessário realizar a
implementação do último módulo desta ferramenta que apresentaria a necessidade ou não
de adicionar elementos ao modelo XML.
A partir disso propõem-se alguns trabalhos futuros:

Implementação do módulo que interpreta o modelo XML para criação dos
hiperdocumentos educacionais;

Caso julguem-se necessário, fazer alterações na DTD do modelo XML utilizado

Realizar um estudo sobre a biblioteca C++ do projeto CoGITaNT para fazer

pela ferramenta para tradução dos grafos;
melhorias na implementação ou até mesmo para utilizá-la, se constatado que o flash
não dá suporte aos outros elementos do Grafo Conceitual;
Verificar a possibilidade de implementação da ferramenta utilizando API’s do
JAVA que permitem a criação de interfaces gráficas a manipulação de arquivos
XML caso seja constatado que o Flash e a biblioteca C++ do projeto CoGITaNT

não sejam eficientes na construção da ferramenta;
Aprofundar os estudos sobre outras formas de representação do conhecimento para
construção de hiperdocumentos educacionais.
A ferramenta desenvolvida neste trabalho é eficaz no que se propõe, ou seja,
permite a criação de Grafos Conceituais básicos (utilizando Conceitos, Relações e
Ligações) e a interpretação para um formato XML.
49
6 REFERENCIAS BIBLIOGRÁFICAS
(ANDRESON, 2001)
Anderson, Richard; et all. Professional XML. Ciência
Moderna: Rio de Janeiro – RJ, 2001.
(CAMPOS, 2001)
Campos, M.L.A. A Organização de Unidades do
Conhecimento em Hiperdocumentos: o modelo conceitual como um espaço
comunicacional para a realização da autoria. Tese de Doutorado em Ciência da
Informação. IBICT-UFRJ/ECO, Rio de Janeiro, 2001.
(CASANOVA, 1991)
Casanova, M. et al. The nested context model for
hyperdocuments. Hypertext ’91 Proceedings, pp. 193–201. ACM, ACM Press, 1991
(COGITANT, 2001)
CoGITaNT. Conceptual Graphs Integrated Tools allowing
Nested Typed graphs. Équipe représentation de connaissances par des graphes.
LIRMM (Laboratoire d'Informatique, de Robotique et de Microélectronique de
Montpellier – França). Disponível em http://cogitant.sourceforge.net/docs/index.html.
Acesso em 28/10/2004.
(CONKLIN, 1987)
Conklin, J. Hypertext: An Introduction and Survey. IEEE
Computer, v.10, n.9, p 17-41,1987.
(DÍAZ, 1995)
Díaz, A. et al. RMC: A Tool to Design WWW Applications.
Jornal da World Wide Web, 1a edição. Dezembro 1995.
(ECMA-262, 1999)
ECMA-262. ECMAScript Language Specification. 3a
edição.
Dezembro
1999.
Disponível
em
http://www.ecmainternational.org/publications/standards/Ecma-262.htm. Acesso em 25/11/2004.
(ISAKOWITZ, 1995)
Isakowitz, T. et al. RMM: A Methodology for Structured
Hypermedia Design. Communications of the ACM, Agosto 1995.
50
(MANUAL DO FLASH MX, 2004)
Corporation Inc, 2004.
Manual
do
Flash
MX.
Macromedia
(MEYER, 1989)
Meyer, Bertrand. Object Oriented Software Construction.
Englewood Cliffs, NJ: Prentice Hall, 1989.
(PRESTES, 2003)
Álvaro Nunes Prestes. Implementação de uma Aplicação
para Análise das Funcionalidades XML do FLASH. Palmas, 2003. Estágio (Bacharel
em Sistemas de Informação) – Centro Universitário Luterano de Palmas, Tocantins,
2003.
(SCHWABE, 1995)
Schwabe, D. The Object-Oriented Hypermedia Design
Model. Communications of the ACM, v.38, n.8, p.45-46, 1995.
(SOWA, 2001a)
Sowa, John F. Conceptual Graphs. Disponível em
http://www.jfsowa.com/cg/. Acesso em: 25 de setembro de 2004.
(SOWA, 2001b)
Sowa, John F. Conceptual Graph Examples. Disponível em
http://users.bestweb.net/~sowa/cg/cgexamp.htm#Ex_1. Acesso em: 30 de outubro de
2004.
(SOWA, 2001c)
Sowa, John F. Conceptual Graph Standard. Disponível em
http://users.bestweb.net/~sowa/cg/cgstand.htm. Acesso em: 30 de outubro de 2004.
51
ANEXOS
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
CÓDIGO ACTIONSCRIPT DA IMPLEMENTAÇÃO DA FERRAMENTA
//Frame Inicial - Camada Framework
//Variáveis Globais
//Restrição sobre valores nos input text(Letras A-Z e Números 0-9)
_root.referenteConceito.restrict = "A-Z 0-9";
_root.tipoConceito.restrict = "A-Z 0-9";
_root.tipoRelacao.restrict = "A-Z 0-9";
//Variáveis auxiliares para criação da ligação
_global.cidAtual = null;
_global.ridAtual = null;
/*Variável utilizada para criação da Relação
quando existe uma do mesmo tipo*/
_global.valenciaEncontrada = null;
//Variáveis para controle do número de elementos criados
_global.numeroConceito = 0;
_global.numeroRelacao = 0;
_global.numeroLigacao = 0;
//Variáveis para desenho do corpo da ligação
_global.comecaX;//Ponto Inicial X
_global.comecaY;//Ponto Inicial Y
_global.fimX;//Ponto Final X
_global.fimY;//Ponto Final Y
//Variáveis que indicam quando a ligação está sendo criada
_global.criandoLigacao = false;
_global.primeiroEscolhido = false;
//Vetores que guardam os objetos correspondentes aos elementos
_global.vetorConceito = new Array();
_global.vetorRelacao = new Array();
_global.vetorLigacao = new Array();
//Clase Ligação
function classeLigacao(){
//Construtor
//Atributos
//Atributo identificador
this.idLigacao = "Ligacao"+_global.numeroLigacao;
//Identificador do Conceito
this.cid = _global.cidAtual.getIdConceito();
//Identificador da Relação
this.rid = _global.ridAtual.getIdRelacao();
//Atributo Nó XML da Ligação
this.noLigacao = "<link idLink=\""+this.idLigacao+"\"
cid=\""+this.cid+"\" rid=\""+this.rid+"\"/>";
//Métodos
//Método que retorna o identificador
this.getIdLigacao = getIdLigacao;
//Método que retorna o id do Conceito
this.getCid = getCid;
//Método que retorna o id da Relação
this.getRid = getRid;
//Método que retorna o Nó XML
this.getNoLigacao = getNoLigacao;
}
52
86:
87:
88:
89:
90:
91:
92:
93:
94:
95:
96:
97:
98:
99:
100:
101:
102:
103:
104:
105:
106:
107:
108:
109:
110:
111:
112:
113:
114:
115:
116:
117:
118:
119:
120:
121:
122:
123:
124:
125:
126:
127:
128:
129:
130:
131:
132:
133:
134:
135:
136:
137:
138:
139:
140:
141:
142:
//Implementação dos métodos
function getIdLigacao(){//Nome
return this.idLigacao;//Retorno
}
function getCid(){//Nome
return this.cid;//Retorno
}
function getRid(){//Nome
return this.rid;//Retorno
}
function getNoLigacao(){//Nome
return this.noLigacao;//Retorno
}
//Classe Conceito
function classeConceito(){
//Construtor
//Atributos
//Atributo Identificador
this.idConceito = "Conceito"+_global.numeroConceito;
//Atributo tipo
this.tipoConceito = _root.tipoConceito.text;
//Atributo referente
this.referente = _root.referenteConceito.text;
//Vetor de Relações ligadas
this.ligacoesDoConceito = new Array();
//Atributo Nó XML do Conceito
this.noConceito = null;
if(textReferente == undefined){//Se NÃO exite Referente
this.noConceito = "<concept idConcept=\""+this.idConceito+"\"
typeConcept=\""+this.tipoConceito+"\"/>";
}
else{//Se exite Referente
this.noConceito = "<concept idConcept=\""+this.idConceito+"\"
typeConcept=\""+this.tipoConceito+"\"
referring=\""+this.referente+"\"/>";
}
//Métodos
//Método que retorna o identificador
this.getIdConceito = getIdConceito;
//Método que retorna o tipo
this.getTipoConceito = getTipoConceito;
//Método que retorna o referente
this.getReferente = getReferente;
//Método que retorna o Nó XML
this.getNoConceito = getNoConceito;
//Método que seta a Relação que se liga com o Conceito
this.getLigacoesDoConceito = getLigacoesDoConceito;
//Método que retorna o vetor de Relações que ligam com o Conceito
this.setLigacoesDoConceito = setLigacoesDoConceito;
//Método que retorna o objeto
this.getObjetoConceito = getObjetoConceito;
//Métodos do Moviel Clip - Referente a parte Gráfica
//Atacha o elemento Conceito da biblioteca
attachMovie("Conceito", this.idConceito, _global.numeroConceito);
//Faz com que o elemento siga o movimento do mouse
startDrag(this.idConceito,true,76,112,718,503);
//Preenche o Input text dentro do Conceito
if(textReferente == undefined){//Se NÃO existe Referente
53
143:
144:
145:
146:
147:
148:
149:
150:
151:
152:
153:
154:
155:
156:
157:
158:
159:
160:
161:
162:
163:
164:
165:
166:
167:
168:
169:
170:
171:
172:
173:
174:
175:
176:
177:
178:
179:
180:
181:
182:
183:
184:
185:
186:
187:
188:
189:
190:
191:
192:
193:
194:
eval(this.idConceito).textoConceito.text =
_root.tipoConceito.text;
}
else{//Se existe Referente
eval(this.idConceito).textoConceito.text =
_root.tipoConceito.text+":"+_root.referenteConceito.text;
}
}
//Implementação dos Métodos
function getIdConceito(){//Nome
return this.idConceito;//Retorno
}
function getTipoConceito(){//Nome
return this.tipoConceito;//Retorno
}
function getReferente(){//Nome
return this.referente;//Retorno
}
function getNoConceito(){//Nome
return this.noConceito;//Retorno
}
function getObjetoConceito(){//Nome
return this;//Retorno
}
function getLigacoesDoConceito(){//Nome
return this.ligacoesDoConceito;//Retorno
}
function setLigacoesDoConceito(elemento){//Nome
this.ligacoesDoConceito.push(elemento);//Atribuição
}
//Implementação dos Eventos que herdam de Movie Clip
//Instanciação
classeConceito.prototype = new MovieClip();
//Evento disparado quando o MovieClip recebe o click do mouse
classeConceito.prototype.onPress = function(){
stopDrag();//O movie clip pára de seguir os movimentos do mouse
if(_global.botaoLigacao){
//Objeto conceito atribuido à variável global auxiliar
//Atribuição de valores a variáveis globais auxiliares
}
else{//Se o botão Ligação NÃO foi pressionado
//Criação da Ligação no Conceito
if(_global.primeiroEscolhido){//Se o 1° elemento da Ligação
já foi escolhido
/*Se alguma variável auxiliar de criação da Ligação
está como
null é porque a Ligação está sendo feito entre
elementos iguais*/
(_global.ridAtual.getIdRelacao() == null)){
//Erro adicionado ao list box
_root.listBox.addItem("Erro: Ligação incorreta.
Mesmo elemento");
}
else{//Os elementos são diferentes
//Se os elementos já estão ligados
54
195:
196:
197:
198:
199:
200:
201:
202:
203:
204:
205:
206:
207:
if(criaLigacao(this,
_global.ridAtual.getIdRelacao(),"Conceito")){
_root.listBox.addItem("Erro: Ligação
incorreta. Elementos já ligados");
}
else{//Se os elementos NÃO estão ligados
//Incremento do número de Ligações
//Cria a instância da Ligação e adiciona no
vetor
_global.vetorLigacao.push(new
classeLigacao());
//Função que desenha a Ligação - Parte
Gráfica
desenhaLigacao();
//Seta o vetor Relação que o Conceito que
está ligando
_global.ridAtual.setLigacoesDaRelacao(_global.cidAtual.getIdConceit
o());
208:
//Seta o vetor Conceito que a Relação que
está ligando
209:
_global.cidAtual.setLigacoesDoConceito(_global.ridAtual.getIdRelaca
o());
210:
}
211:
}
212:
//Variáveis auxiliares recebem valores default
213:
214:
215:
216:
}
217: }
218: }
219: //Evento disparado quando o mouse sai de dentro do MovieClip
220: classeConceito.prototype.onRollOut = function(){
221: if(_global.criandoLigacao){//Se o botão Ligação foi pressionado
222:
//Ponto inicial do desenho da Ligação
223:
_global.comecaX = _xmouse;
224:
_global.comecaY = _ymouse;
225:
226:
_global.primeiroEscolhido = true;
227:
228: }
229: }
230: //Evento disparado quando o mouse entra dentro do MovieClip
231: classeConceito.prototype.onRollOver = function() {
232: if(_global.primeiroEscolhido){//Se o primeiro elemento foi
escolhido
233:
//Ponto final do desenho da Ligação
234:
_global.fimX = _xmouse;
235:
_global.fimY = _ymouse;
236:
237:
238: }
239: }
240:
241: //Classe Relação
242:
55
243: function classeRelacao(){
244: //Construtor
245: //Atributos
246: //Atributo identificador
247: this.idRelacao = "Relacao"+_global.numeroRelacao;
248: //Atributo do tipo
249: this.tipoRelacao = _root.tipoRelacao.text;
250: //Atributo valência
251: this.valencia = _root.comboBox.getValue()
252: //Atributo Nó XML da Relação
253: this.noRelacao = "<relation idRelation=\""+this.idRelacao+"\"
typeRelation=\""+this.tipoRelacao+"\" valence=\""+this.valencia+"\"
/>";
254: //Vetor de Conceitos Ligados
255: this.ligacoesDaRelacao = new Array();
256: //Métodos
257: //Método que retorna o identificador
258: this.getIdRelacao = getIdRelacao;
259: //Método que retorna o tipo
260: this.getTipoRelacao = getTipoRelacao;
261: //Método que retorna a valência
262: this.getValencia = getValencia;
263: //Método que seta a valência
264: this.setValencia = setValencia;
265: //Método que retorna o Nó XML
266: this.getNoRelacao = getNoRelacao;
267: //Método que retorna o objeto
268: this.getObjetoRelacao = getObjetoRelacao;
269: //Método que seta o Conceito que se liga com a Relação
270: this.setLigacoesDaRelacao = setLigacoesDaRelacao;
271: //Método que retorna o vetor de Conceitos que ligam com a Relação
272: this.getLigacoesDaRelacao = getLigacoesDaRelacao;
273: //Métodos do Moviel Clip - Referente a parte Gráfica
274: //Atacha o elemento Relação da biblioteca
275: attachMovie("Relacao", this.idRelacao, 1000 +
_global.numeroRelacao);
276: //Faz com que o elemento siga o movimento do mouse
277: startDrag(this.idRelacao,true,88,112,705,503);
278: //Preenche o Input text dentro da Relação
279: eval(this.idRelacao).textoRelacaoCriada.text =
_root.tipoRelacao.text;
280: }
281: //Implementação dos Métodos
282: function getIdRelacao(){//Nome
283: return this.idRelacao;//Retorno
284: }
285: function getTipoRelacao(){//Nome
286: return this.tipoRelacao;//Retorno
287: }
288: function getValencia(){//Nome
289: return this.valencia;//Retorno
290: }
291: function getNoRelacao(){//Nome
292: return this.noRelacao;//Retorno
293: }
294: function getObjetoRelacao(){//Nome
295: return this;//Retorno
296: }
297: function getLigacoesDaRelacao(){//Nome
298: return this.ligacoesDaRelacao;//Retorno
56
299:
300:
301:
302:
303:
304:
305:
306:
307:
308:
309:
310:
311:
312:
313:
314:
315:
316:
317:
318:
319:
320:
321:
322:
323:
324:
325:
326:
327:
328:
329:
330:
331:
332:
333:
334:
335:
336:
337:
338:
339:
340:
341:
342:
343:
344:
345:
346:
}
function setValencia(elemento){//Nome
this.valencia = elemento;//Atribuição
}
function setLigacoesDaRelacao(elemento){//Nome
this.ligacoesDaRelacao.push(elemento);//Atribuição
}
//Implementação dos Eventos que herdam de Movie Clip
//Instanciação
classeRelacao.prototype = new MovieClip();
//Evento disparado quando o MovieClip recebe o click do mouse
classeRelacao.prototype.onPress = function(){
stopDrag();//O movie clip pára de seguir os movimentos do mouse
if(_global.botaoLigacao){//se o botão Ligação foi clicado
//Se a Relação ainda não fez o número máximo de Ligações
permitidas
if(this.getLigacoesDaRelacao().length < this.getValencia()){
//Objeto Relação atribuido à variável global auxiliar
_global.ridAtual = this;
}
else{//Se a Relação já fez o número de Ligações permitidas
_root.listBox.addItem("Erro: Ligação incorreta. Relação
possui as ligações possíveis");
}
}
else{//Se o botão Ligação NÃO foi pressionado
//Criação da Ligação na Relação
if(_global.primeiroEscolhido){//Se o 1° elemento da Ligação
já foi escolhido
/*Se alguma variável auxiliar de criação da Ligação
está como
null é porque a Ligação está sendo feito entre
elementos iguais*/
(_global.ridAtual.getIdRelacao() == null)){
_root.listBox.addItem("Erro: Ligação incorreta.
Mesmo elemento");
}
else{//Os elementos são diferentes
//Se os elementos já estão ligados
if(criaLigacao(this,
_global.cidAtual.getIdConceito(),"Relacao")){
incorreta. Elementos já ligados");
}
else{//Se os elementos NÃO estão ligados
//Se a Relação ainda não fez o número
máximo de Ligações permitidas
if(this.getLigacoesDaRelacao().length <
this.getValencia()){
//Incremento do número de Ligações
//Cria a instância da Ligação e
adiciona no vetor
57
347:
348:
349:
350:
351:
classeLigacao());
Parte Gráfica
que está ligando
_global.vetorLigacao.push(new
//Função que desenha a Ligação desenhaLigacao();
//Seta o vetor Relação que o Conceito
_global.ridAtual.setLigacoesDaRelacao(_global.cidAtual.getIdConceit
o());
352:
//Seta o vetor Conceito que a Relação
que está ligando
353:
_global.cidAtual.setLigacoesDoConceito(_global.ridAtual.getIdRelaca
o());
354:
}
355:
else{//Se a Relação já fez o número de
Ligações permitidas
356:
357:
incorreta. Relação possui as ligações possíveis");
358:
}
359:
}
360:
}
361:
//Variáveis auxiliares recebem valores default
362:
363:
364:
365:
}
366: }
367: }
368: //Evento disparado quando o mouse sai de dentro do MovieClip
369: classeRelacao.prototype.onRollOut = function() {
370: if(_global.criandoLigacao){//Se o botão Ligação foi pressionado
371:
//Ponto inicial do desenho da Ligação
372:
_global.comecaX = _xmouse;
373:
_global.comecaY = _ymouse;
374:
375:
_global.primeiroEscolhido = true;
376:
377: }
378: }
379: //Evento disparado quando o mouse entra dentro do MovieClip
380: classeRelacao.prototype.onRollOver = function(){
381: if(_global.primeiroEscolhido){//Se o primeiro elemento foi
escolhido
382:
//Ponto final do desenho da Ligação
383:
_global.fimX = _xmouse;
384:
_global.fimY = _ymouse;
385:
386:
_global.ridAtual = this;
387: }
388: }
389:
390: //Registro das classes
391:
392: //Utilizados pra informações aos desenvolvedor em tempo de projeto
393: //Realiza o registro das três classes implementadas
394: //Apresenta a mensagem de registro com sucesso caso a classe seja
registrada
58
395: //Apresenta a mensagem de erro caso exista algum problema com o
registro
396: if(Object.registerClass("Conceito",classeConceito)==true){//Conceito
397: trace("Classe Conceito Registrada com sucesso");
398: }
399: else{
400: trace("Classe Conceito NÃO foi Registrada com sucesso.");
401: }
402: if(Object.registerClass("Relacao",classeRelacao)==true){//Relação
403: trace("Classe Relação Registrada com sucesso");
404: }
405: else{
406: trace("Classe RELAÇÃO NÃO foi Registrada com sucesso.");
407: }
408: if(Object.registerClass("Ligacao",classeLigacao)==true){//Ligação
409: trace("Classe Ligacao Registrada com sucesso");
410: }
411: else{
412: trace("Classe Ligacao NÃO foi Registrada com sucesso.");
413: }
414:
415: Funções
416:
417: //Função que verifica a existencia de Conceito no vetor
418: _global.existeConceito = function(){
419: //variáveis usadas na função
420: var achou = false, i = 0, vazio = "";
421: //Laço de repetição que percorre o vetor enquanto a informação não
for encontrada
422: while((achou == false) and (i < _global.vetorConceito.length)){
423:
//Se o tipo digitado é igual ao tipo do objeto do vetor
424:
if(textTipoConceito ==
_global.vetorConceito[i].getTipoConceito()){
425:
426:
427:
428:
429:
430:
431:
432:
433:
434:
435:
436:
437:
438:
439:
440:
441:
vazio){
vazio
//Se NÃO foi digitado um referente pelo usuário
if(textReferente == undefined){
//Se o referente do objeto do vetor está vazio
if(_global.vetorConceito[i].getReferente() ==
//Conceito encontrado
achou = true;
}
//Se o referente do objeto do vetor NÃO está
else{
}
digitado
//Conceito NÃO encontrado
achou = false;
}
//Se foi digitado um referente pelo usuário
else{
//Se o referente do objeto do vetor é igual ao
if(textReferente ==
_global.vetorConceito[i].getReferente()){
442:
//Conceito encontrado
443:
achou = true;
444:
}
59
445:
446:
447:
ao digitado
//Se o referente do objeto do vetor NÃO é igual
else{
448:
achou = false;
449:
}
450:
}
451:
}
452:
//Se o tipo digitado NÃO é igual ao tipo do objeto do vetor
453:
else{
454:
455:
achou = false;
456:
}
457:
//Incrementa o contador
458:
i++;
459: }
460: return achou;//Retorno da função
461: }
462:
463: //Função que procura existencia de Relação
464: _global.existeRelacao = function(){
466: var achou = false, i = 0;
467: //Laço de repetição que percorre o vetor enquanto a informação não
for encontrada
468: while((achou == false) and (i < _global.vetorRelacao.length)){
469:
//Se o tipo do objeto do vetor é igual ao digitado
470:
if((textTipoRelacao ==
_global.vetorRelacao[i].getTipoRelacao())){
471:
//Relação encontrada
472:
achou = true;
473:
//Valência do objeto encontrado é atribuída à variável
auxiliar
474:
_global.valenciaEncontrada =
_global.vetorRelacao[i].getValencia();
475:
}
476:
//Se o tipo do objeto do vetor NÃO é igual ao digitado
477:
else{
478:
//Relação NÃO encontrada
479:
achou = false;
480:
}
481:
482:
i++;
483: }
484: return achou;//Retorno da função
485: }
486:
487: //Função que verifica se a ligação pode ser criada
488: criaLigacao = function(classe, inserir, parametro){
490: var i = 0, achou = false, vet = new Array();
491: //Se a função foi invocada pelo Conceito
492: if(parametro == "Conceito"){
493:
//Atribui o vetor de ligações do Conceito à variável auxiliar
494:
vet = classe.getLigacoesDoConceito();
495: }
496: //Se a função foi invocada pela Relação
497: else{
498:
//Atribui o vetor de ligações da Relação à variável auxiliar
60
499:
500:
501:
502:
503:
504:
505:
506:
507:
508:
509:
510:
511:
512:
513:
vet = classe.getLigacoesDaRelacao();
}
do{//Início do laço de repetição
//Se o parâmetro foi encontrado no vetor
if(inserir == vet[i]){
//Ligação encontrada
achou = true;
}
//Se o parâmetro NÃO foi encontrado no vetor
else{
//Ligação NÃO encontrada
achou = false;
}
i++;
//Laço de repetição que percorre o vetor enquanto a informação não
for encontrada
514: }while((achou == false and i < vet.length));
515: return achou;//retorno da função
516: }
517:
518: /*Função que verifica se as todas as ligações foram feitas de acordo
519: com a valência de cada Relação*/
520: _global.verificaLigacao = function(){
522: var ok = false, i, cont;
523: //Laço de repetição que percorre o vetor de Relações
524: for(i = 0; i < _global.vetorRelacao.length; i++){
525:
//Inicia o contador
526:
cont = 0;
527:
//Laço de repetição que percorre o vetor de Ligações
528:
for(j = 0; j < _global.vetorLigacao.length; j++){
529:
//Se o identificador da Relação é igual ao rid da
Ligação
530:
if(_global.vetorRelacao[i].getIdRelacao() ==
_global.vetorLigacao[j].getRid()){
531:
532:
cont++;
533:
}
534:
}
535:
//Se a valência da Relação é igual ao contador
536:
if(cont == _global.vetorRelacao[i].getValencia()){
537:
//Ligações realizadas corretamente
538:
ok = true;
539:
}
540:
//Se a valência da Relação NÃO é igual ao contador
541:
else{
542:
//Ligações NÃO realizadas corretamente
543:
ok = false;
544:
}
545: }
546: return ok;//Retorno da função
547: }
548:
549: //Função que Cria XML e envia para o servidor
550: _global.criaXML = function(){
552: var strNos = "", i;
553: //Varre o vetor Conceito e concatena o atributo do Nó XML
554: for(i = 0; i < _global.vetorConceito.length; i++){
555:
strNos = strNos + _global.vetorConceito[i].getNoConceito();
61
556:
557:
558:
559:
560:
561:
562:
563:
564:
565:
566:
567:
568:
569:
570:
571:
572:
573:
574:
575:
576:
577:
578:
579:
580:
581:
582:
583:
584:
585:
}
//Varre o vetor Relação e concatena o atributo do Nó XML
for(i = 0; i < _global.vetorRelacao.length; i++){
strNos = strNos + _global.vetorRelacao[i].getNoRelacao();
}
//Varre o vetor Ligação e concatena o atributo do Nó XML
for(i = 0; i < _global.vetorLigacao.length; i++){
strNos = strNos + _global.vetorLigacao[i].getNoLigacao();
}
//Variável com a URL do servidor
var strURL = "http://skywalker/ImplCLASSE/default.asp";
//Instanciação do objeto XML
objXML = new XML("<graph>" + strNos+ "</graph>");
//Informa a declaração do docType
objXML.docTypeDecl = "<!DOCTYPE graph SYSTEM \"grafoRincon.dtd\">";
//Informa a declaração da versão XML
objXML.xmlDecl = "<?xml version=\"1.0\" encoding = \"ISO-88591\"?>";
if(objXML.status == 0){//Se o objeto XML é bem formado
//Instanciação da variável XML que recebe o retorno do
servidor
var auxXML = new XML();
//Método utilizado quando o objeto é carregado
auxXML.onLoad = function(sucess){
if (sucess)//Se a resposta do servidor foi ok
//Adiciona informação no list box
_root.listBox.addItem("Informação: Formato XML
criado com SUCESSO");
else//Se a resposta do servidor NÃO foi ok
//Adiciona erro no list box
_root.listBox.addItem("Erro: Servidor não
encontrado");
}
/*Método que envia o objeto XML para o servidor utilizando o
método
POST e carrega no objeto XML auxiliar*/
objXML.sendAndLoad(strURL, auxXML, "POST");
}
else{//Se o objeto XML NÃO é bem formado
//Adiciona erro no list box
trace("Erro: Arquivo XML não é válido");
}
}
586:
587:
588:
589:
590:
591:
592:
593:
594:
595: //Função que desenha a ligação
596: function desenhaLigacao(){
597: //Instanciação da variável que recebe o movie clip vazio
598: var linha = createEmptyMovieClip("Ligacao",
2000+_global.numeroLigacao);
599: //Altera propriedades da seta
600: linha.lineStyle(2, 0x000000, 100);
601: //Indica o ponto inicial do desenho da Ligação
602: linha.moveTo(_global.comecaX,_global.comecaY);
603: //Indica o ponto Final do desenho da Ligação
604: linha.lineTo(_global.fimX, _global.fimY);
605: //Função que rotaciona a seta de acordo com a inclinação da Linha
606: rotacionarSeta();
607: }
608:
609: //Função que rotaciona a seta de acordo com a inclinação da Linha
62
610: rotacionarSeta = function(){
611: //Atacha o elemento Ponta da biblioteca
612: var ponta = attachMovie("Ponta",
Ponta+_global.numeroLigacao,4000+_global.numeroLigacao);
613: //Move o elemento para o ponto final do corpo da Ligação
614: ponta._x = _global.fimX;
615: ponta._y = _global.fimY;
616: //quadro inferior direito onde x e y aumentam
617: if((_global.fimX > _global.comecaX) and (_global.fimY >
_global.comecaY)){
618:
//u = (c1-a1,c2-a2)
619:
u1 = (_global.fimX - _global.comecaX);
620:
u2 = (_global.fimY - _global.comecaY);
621:
//v = (c1-b1,c2-b2)
622:
v1 = (_global.fimX - _global.comecaX);
623:
v2 = (_global.fimY - _global.fimY);
624:
numerador = u1*v1+u2*v2; //u * v = u1*v1 + u2*v2
(multiplicação de vetores)
625:
//denominador = modulo (u) * modulo (v) (multiplicação
vetorial)
626:
denominador =
Math.sqrt((Math.pow(u1,2)+Math.pow(u2,2)))*Math.sqrt((Math.pow(v1,2)
+Math.pow(v2,2)));
627:
//angulo teta = u*v(multiplicação vetorial)/u*v(multiplicação
vetorial em modulo)
628:
teta = numerador/denominador;
629:
//rotacionar = arc cos de teta em grau (a função retorna em
radianos)
630:
arccos = Math.acos(teta);
631:
//regra de três pra transformar de radianos pra graus
632:
rotacionar = 180*arccos/Math.PI;
633:
//propriedade rotation do movie clip recebe o resultado da
operação
634:
ponta._rotation = rotacionar;
635: }
636: //quadro inferior esquerdo onde x diminui e y aumenta
637: if((_global.fimX < _global.comecaX) and (_global.fimY >
_global.comecaY)){
638:
u1 = (_global.comecaX - _global.fimX);
639:
u2 = (_global.comecaY - _global.fimY);
640:
v1 = (_global.comecaX - _global.comecaX);
641:
v2 = (_global.comecaY - _global.fimY);
642:
numerador = u1*v1+u2*v2;
643:
denominador =
+Math.pow(v2,2)));
644:
645:
646:
rotacionar = (180*arccos/Math.PI)+90;
647:
648: }
649: //quadro superior direito onde x aumenta e y diminue
650: if((_global.fimX > _global.comecaX) and (_global.fimY <
_global.comecaY)){
651:
u1 = (_global.fimX - _global.comecaX);
652:
u2 = (_global.fimY - _global.comecaY);
653:
v1 = (_global.fimX - _global.fimX);
654:
v2 = (_global.fimY - _global.comecaY);
655:
63
656:
657:
658:
659:
660:
661:
662:
663:
664:
665:
666:
667:
668:
669:
670:
671:
672:
673:
674:
675:
676:
677:
678:
679:
680:
681:
682:
683:
684:
685:
686:
687:
688:
denominador =
+Math.pow(v2,2)));
}
//quadro superior esquerdo onde x e y diminuem
if((_global.fimX < _global.comecaX) and (_global.fimY <
_global.comecaY)){
u1 = (_global.comecaX - _global.fimX);
u2 = (_global.comecaY - _global.fimY);
v1 = (_global.comecaX - _global.fimX);
v2 = (_global.comecaY - _global.comecaY);
denominador =
+Math.pow(v2,2)));
}
//quando a ligação está em linha reta (apontando para o SUL)
if((_global.fimX == _global.comecaX) and (_global.fimY >
_global.comecaY)){
ponta._rotation = 90;
}
//quando a ligação está em linha reta (apontando para o NORTE)
if((_global.fimX == _global.comecaX) and (_global.fimY <
_global.comecaY)){
}
//quando a ligação está em linha reta (apontando para o OESTE)
if((_global.fimX < _global.comecaX) and (_global.fimY ==
_global.comecaY)){
}
//quando a ligação está em linha reta (apontando para o LESTE)
if((_global.fimX > _global.comecaX) and (_global.fimY ==
_global.comecaY)){
}
}
689:
690:
691:
692:
693: Botões
694:
695: //Evento disparado quando o botão Conceito é pressionado
696: on(press){
697: //Criação da ligação é interrompida caso esteja acontecendo
698: _global.botaoLigacao = false;
699: _global.criandoLigacao = false;
700: if(textTipoConceito == undefined){//Se NÃO foi digitado um tipo
701:
702:
_root.listBox.addItem("Erro: Digite o tipo do conceito");
703: }
704: else{//Se foi digitado um tipo
705:
if(_global.existeConceito()){//Se existe um Conceito com o
valor digitado
64
706:
707:
_root.listBox.addItem("Erro: Esse conceito já existe");
708:
}
709:
else{//Se NÃO existe um Conceito com o valor digitado
710:
//Incremento do número de Conceitos
711:
_global.numeroConceito++;
712:
//Cria a instância do Conceito e adiciona no vetor
713:
_global.vetorConceito.push(new classeConceito());
714:
}
715: }
716: //Atribui valores default à variáveis auxiliares
717: textReferente = undefined;
718: textTipoConceito = undefined;
719: }
720:
721: //Evento disparado quando o botão Relação é pressionado
722: on(press){
723: //Criação da ligação é interrompida caso esteja acontecendo
724: _global.botaoLigacao = false;
725: _global.criandoLigacao = false;
726: if((textTipoRelacao == undefined)){//Se NÃO foi digitado um tipo
727:
728:
_root.listBox.addItem("Erro: Digite o tipo da relação");
729: }
730: else{//Se foi digitado um tipo
731:
//Se existe uma Relação com o valor digitado
732:
if(_global.existeRelacao()){
733:
734:
_root.listBox.addItem("Atenção: Essa relação já existe
no grafo e para sua valência prevalecerá o valor anterior");
735:
//Incremento do número de Relações
736:
737:
//Cria a instância da Relação
738:
var novaRelacao = new classeRelacao();
739:
//Recebe o valor da valência da variável auxiliar
740:
novaRelacao.setValencia(_global.valenciaEncontrada);
741:
//Adiciona no vetor
742:
_global.vetorRelacao.push(novaRelacao);
743:
}
744:
//Se NÃO existe uma Relação com o valor digitado
745:
else{
746:
//Incremento do número de Relações
747:
748:
//Cria a instância da Relação e adiciona no vetor
749:
_global.vetorRelacao.push(new classeRelacao());
750:
}
751: }
752: //Atribui valores default à variáveis auxiliares
753: textTipoRelacao = undefined;
754: textValencia = undefined;
755: }
756:
757: //Evento disparado quando o botão Ligação é pressionado
758: on(press){
759: //Variável global que informa que uma Ligação pode ser criada
760: _global.botaoLigacao = true;
761: }
762:
763: //Evento disparado quando o botão XML é pressionado
764: on(press){
65
765:
766:
767:
768:
769:
770:
771:
772:
773:
774:
775:
776:
777:
778:
779:
780:
781:
782:
783:
784:
785:
786:
787:
788:
789:
790:
791:
792:
793:
794:
795:
796:
797:
798:
799:
//Se existe mais de um elemento no vetor de Conceitos
if(_global.vetorConceito.length > 1){
//Se existe elemento no vetor de Ligações
if(_global.vetorLigacao.length > 0){
//Se todas as Ligações foram realizadas segundo a
valência
//Função que cria o arquivo XML
_global.criaXML();
}
//Se alguma das Ligações NÃO foram realizadas segundo a
valência
else{
_root.listBox.addItem("XML não pode ser criado.
Existem relações com ligações faltando");
}
}
//Se NÃO existe elemento no vetor de Ligações
else{
}
}
else{
//Se existe 0 ou 1 elemento no vetor de Conceitos
if((_global.vetorConceito.length == 0) or
(_global.vetorConceito.length == 1)){
//Se existem elementos no vetor de Relações
if(_global.vetorRelacao.length > 0){
//Se todas as Ligações foram realizadas segundo a
valência
_global.criaXML();
}
//Se alguma das Ligações NÃO foram realizadas
segundo a valência
else{
_root.listBox.addItem("XML não pode ser
criado. Existem relações com ligações faltando");
800:
801:
802:
803:
804:
805:
806:
807:
808: }
809: }
}
}
}
//Se NÃO existem elementos no vetor de Relações
else{
_global.criaXML();
}

ANDRÉ MESQUITA RINCON Implementação de uma Ferramenta

Transcrição

Documentos relacionados

Ferramenta para análise de dados gerados no LanGuard

Manual de validação do arquivo XML

Cours de Portugais - Ecole Primaire Confirmation d`inscription

Tim-Berners Lee

1. arquivo xml

Tratamento de XML com JavaScript e com PHP

UNIVERSIDADE FEDERAL DE MINAS GERAIS DEPARTAMENTO

Suit small file

imprima

memento para uso de pais e filhos