ArgoCASEGEO - Uma Ferramenta CASE de Código-Aberto para o
Modelo UML-GeoFrame
Jugurta Lisboa Filho
Maurício Fidélis Rodrigues Júnior
Jaudete Daltio
Universidade Federal de Viçosa - Departamento de Informática
Campus da UFV, 36570-000 Viçosa, MG, Brasil
{jugurta, mfrj, jdaltio}@dpi.ufv.br
Resumo
Este artigo descreve o desenvolvimento de uma ferramenta CASE de código aberto, a ArgoCASEGEO, bem como sua arquitetura modular. A ferramenta ArgoCASEGEO permite a modelagem de banco de dados geográficos com base no modelo conceitual UML-GeoFrame, que é específico para aplicações de Sistemas de Informação Geográfica (SIG). O artigo descreve ainda as regras de transformação empregadas pelo módulo de geração automático do esquema lógico-espacial para o SIG GeoMedia. O dicionário de dados associado ao esquema modelado é armazenado como um documento XML/XMI, visando sua utilização por outros programas.
1. Introdução.
Bancos de Dados Geográficos (BDG) são coleções de dados georreferenciados, manipulados por Sistemas de Informação Geográfica (SIG). Na área de geoprocessamento, normalmente é o próprio usuário que desenvolve as aplicações de SIG. Assim, redundância e inconsistência são características marcantes na maioria dos BDG, muitas vezes comprometendo a confiabilidade do sistema e, conseqüentemente, pondo em risco grandes investimentos públicos ou privados. Desta forma, o desenvolvimento de metodologias e de ferramentas que auxiliem os projetistas de BDG são fundamentais para a melhoria da qualidade das aplicações de SIG.
Um BDG pode ser projetado com base em metodologias tradicionais de projeto de banco de dados [8], ou seja, as fases de projeto conceitual, lógico e físico devem ser contempladas. Um esquema conceitual de dados é elaborado na fase de projeto conceitual, sendo necessário definir o modelo de dados a ser utilizado, o que vai facilitar a comunicação entre projetistas e/ou usuários envolvidos. Diversos modelos específicos para modelagem de BDG têm sido propostos e aperfeiçoados nos últimos anos, entre os mais citados estão os modelos GeoOOA [14], MADS [23], OMT-G [4], UML+SpatialPVL [1] e UML-GeoFrame [17].
Concluída a modelagem conceitual, o próximo passo - projeto lógico - consiste na transformação do esquema conceitual em um esquema de dados compatível com o modelo de dados do software de SIG que será utilizado. Esta etapa de transformação de um esquema conceitual em um esquema lógico-espacial, e sua implantação em um software de SIG, pode ser feita de forma automática por uma ferramenta CASE (Computer Aided Software Engineering). Alguns dos modelos conceituais citados anteriormente são suportados por ferramentas CASE como, por exemplo, Perceptory [5], REGIS [13], AIGLE [15] e Editor Java MADS [20].
Porém, uma dificuldade enfrentada por estas ferramentas é que cada software de SIG implementa seu próprio modelo de dados. A falta de um modelo de representação de dados espaciais padronizado acarreta problemas na troca de dados entre softwares de SIG distintos, que incluem perda na precisão de dados, comprometimento de qualidade da informação, perda de definições de atributos e georreferenciamento. Para que o intercâmbio de dados espaciais aconteça sem o comprometimento da informação é necessário um alto grau de interoperabilidade entre os SIG. Com esta finalidade, o consórcio OpenGIS vem definindo um modelo padrão para a troca de dados, que é suportado pela linguagem XML/GML (Geography Markup Language), para o transporte e o armazenamento de informações geográficas, incluindo aspectos geométricos e propriedades de objetos de interesse [24].
Este artigo descreve a arquitetura da ArgoCASEGEO, uma ferramenta CASE de código aberto para modelagem de BDG que suporta o modelo UML-GeoFrame [17]. O esquema conceitual elaborado por esta ferramenta é armazenado em um documento XML (Extensible Markup Language), de forma que possa ser facilmente acessado e manipulado. Esta ferramenta também provê um módulo de geração automática, capaz de gerar esquemas de dados para os formatos mais comumente encontrados nos principais SIG comerciais. Além disso, a ArgoCASEGEO possui suporte para reutilização de esquemas de dados baseado em padrões de análise [9].
O restante deste artigo está organizado da seguinte forma: a seção 2 apresenta um resumo do modelo UML-GeoFrame. A seção 3 descreve as vantagens do uso de padrões de análise na modelagem conceitual de BDG. A seção 4 detalha o desenvolvimento da ferramenta ArgoCASEGEO, mostrando sua arquitetura e descrevendo cada módulo implementado. Considerações finais e trabalhos futuros são descritos na seção 5.
2. O Modelo UML-GeoFrame.
A modelagem conceitual de BDG com base na linguagem UML [3] e no framework GeoFrame [17] produz um esquema de banco de dados de fácil entendimento, melhorando a comunicação entre projetistas e/ou usuários. Além de ser usado na elaboração de esquemas de banco de dados, o modelo UML-GeoFrame é adequado para especificação de padrões de análise [9].
O GeoFrame é um framework conceitual que fornece um diagrama de classes básicas para auxiliar o projetista nos primeiros passos da modelagem conceitual de dados de uma nova aplicação de SIG. O uso conjunto do diagrama de classes da linguagem UML e o GeoFrame permitem a solução da maioria dos requisitos de modelagem de aplicações de SIG. Um esquema conceitual de dados geográficos construído com base no modelo UML-GeoFrame inclui, por exemplo, a modelagem dos aspectos espaciais da informação geográfica e a diferenciação entre objetos convencionais e objetos/campos geográficos. A especificação desses elementos é feita com base no conjunto de estereótipos mostrados na Figura 1.
Figura 1 – Estereótipos do Modelo UML-GeoFrame
O primeiro conjunto de estereótipos (Fenômeno geográfico e Objeto convencional) é usado para diferenciar os dois principais tipos de objetos pertencentes a um BDG. Fenômeno geográfico é especializado
Componente espacial de campos geográficos Componente espacial de objetos geográficos Fenômeno geográfico e Objeto convencional
Ponto Linha PolígonoObj. espacial complexo
Campo geográfico Objeto não geográfico Objeto geográfico
Pontos irregulares Grade de pontos TIN Polígonos adjacentes Isolinhas Grade de células
em Objeto geográfico () e Campo geográfico (), segundo as duas formas de percepção dos fenômenos geográficos, descritas por Goodchild [11]. Objetos não geográficos são modelados de forma tradicional e são identificados através do estereótipo ().
Os conjuntos de estereótipos Componente espacial de objetos geográficos e Componente espacial de campos geográficos são usados para a modelagem do componente espacial de fenômenos segundo as visões de objeto e de campo, respectivamente. A existência de múltiplas representações é modelada através da combinação de dois ou mais estereótipos em uma mesma classe. Por exemplo, uma classe Município pode ter duas formas de abstração de seu componente espacial, pontual e poligonal, o que é especificado pelo par de estereótipos ().
Por último, o estereótipo <<função>> é usado para caracterizar um tipo especial de associação que ocorre na modelagem de campos categóricos. Segundo Chrisman [7], numa estrutura de cobertura categórica o espaço é classificado em categorias mutuamente exclusivas, ou seja, uma variável possui um valor do tipo categoria em todos os pontos dentro de uma região (ex.: tipos de solos). A Figura 2 ilustra um diagrama de classes no modelo UML-GeoFrame contendo dois temas: EducaçãoeMeio-Ambiente.
Figura 2 – Exemplo de esquema UML-GeoFrame
No tema Educação, modelado como um pacote UML, pode-se observar as classes de fenômenos geográficos na visão de objetos Cidade e Bairro, cuja representação espacial é do tipo polígono, e a classe Escola, com representação espacial do tipo ponto. Além destas,Alunoé uma classe modelada como objeto não geográfico. No tema Meio-Ambiente estão modeladas três classes de fenômenos geográficos percebidos na visão de campo, que sãoVegetação,RelevoeTemperatura, cada uma com seus diferentes tipos de representação espacial. Este tema inclui ainda a classeTipo Vegetação, que é modelada como objeto não geográfico, estando associada à classe Vegetação (representada por polígonos adjacentes) através do estereótipo <<função categórica>>, ou seja, cada região/polígono está associada a um tipo de vegetação.
3. Padrões de Análise.
Um padrão de análise é um mecanismo de reutilização que permite aos projetistas menos experientes reutilizarem o conhecimento de outros especialistas. Segundo Gamma e outros, “um padrão apresenta a essência de uma solução para um problema recorrente, em um contexto específico” [10]. Esta definição genérica, que serve tanto para os padrões de projeto (design patterns) quanto para os padrões de análise (analysis patterns) compreende as idéias fundamentais de um padrão. A expressão “uma solução para um problema” significa que cada padrão identifica um problema e apresenta uma solução para ele. A expressão “essência de uma solução” significa que somente os elementos essenciais são descritos, deixando os aspectos específicos para serem detalhados pelo projetista, dado que aspectos específicos normalmente não são reutilizados. A expressão “problema recorrente” significa que os padrões devem ser descritos para problemas
Meio-Ambiente Vegetação
Relevo Tipo Vegetação Tempe-ratura <<função>> Educação Escola nome contato endereço * Bairro idBairro nome Aluno nome endereço responsável 1 * 1 Cidade codMun nome população 1 *que já ocorreram diversas vezes e irão ocorrer novamente. Por último, “em um contexto específico” significa que a solução completa é válida para um contexto particular.
Um padrão de análise descreve um conjunto de classes, possivelmente pertencentes a diferentes hierarquias de classes, e as associações existentes entre elas [9]. Padrões de análise podem ser vistos, portanto, como uma forma de descrever subesquemas de projetos mais complexos, os quais ocorrem com freqüência durante o processo de modelagem de muitas aplicações. O uso de padrões melhora, de forma significativa, o tempo de desenvolvimento de novas aplicações, uma vez que a reutilização ocorre através de subesquemas e não através de classes isoladas [12].
Geralmente, um padrão de análise apresenta a solução do problema de uma forma mais sugestiva do que prescritiva, fornecendo um modelo e a discussão do porquê a solução é proposta desta forma, suas vantagens e desvantagens. Segundo Fowler, a contribuição realmente importante de um padrão não é o modelo fornecido como solução, mas sim, o raciocínio que está por trás desta solução [9].
A maioria dos padrões de análise publicados até o momento foi projetada, principalmente, para solucionar problemas de aplicações comerciais como, por exemplo, os padrões descritos em [9] e [12]. No entanto, a idéia de padrões de análise pode ser usada para aumentar a qualidade e a produtividade no desenvolvimento de aplicações não-convencionais como as aplicações de SIG. A adequabilidade do uso de padrões de análise na modelagem de BDG é mostrada em [16]. Exemplos de padrões de análise para aplicações de SIG podem ser encontrados em [2] e [18].
4. A Ferramenta ArgoCASEGEO.
ArgoCASEGEO é uma ferramenta CASE que tem como objetivo dar suporte à modelagem de BDG com base no modelo UML-GeoFrame. Os esquemas de dados elaborados a partir desta ferramenta são armazenados no formato XMI (XML Metadata Interchange), uma sintaxe para armazenamento de esquemas conceituais de dados, em documentos XML [21].
Em síntese, XMI combina os benefícios da XML para definição, validação e compartilhamento de formatos de documentos com os benefícios da linguagem de modelagem visual UML para especificação, visualização, construção e documentação de objetos distribuídos e modelos de negócios.
Uma ferramenta CASE é, antes de tudo, um software de desenho gráfico. Para evitar um grande esforço de programação no sentido de desenvolver uma ferramenta gráfica desde o início, optou-se por utilizar como ponto de partida algum software gráfico existente. Este software deveria suportar o desenho de diagramas de classes da linguagem UML e ser extensível para suportar os estereótipos definidos no modelo UML-GeoFrame.
Após analisar algumas alternativas, optou-se pelo editor ArgoUML como ferramenta de trabalho. Assim, a ArgoCASEGEO foi desenvolvida como uma extensão do software ArgoUML, uma ferramenta de modelagem que se encontra sobre uma licença de utilização e distribuição open-source, desenvolvida na linguagem Java. ArgoUML suporta diversos diagramas UML, como o de classes, casos de uso, atividade e de colaboração.
A Figura 3 ilustra a arquitetura da ferramenta ArgoCASEGEO, que é composta de quatro módulos. O Módulo Gráfico permite projetar o esquema conceitual, provendo um conjunto de construtores do modelo UML-GeoFrame. O Módulo Dicionário de Dados armazena a descrição detalhada dos elementos do diagrama criado pelo projetista, no formato XMI. O Módulo Geração Automática permite a transformação de esquemas conceituais armazenados no dicionário de dados em esquemas lógicos correspondentes a alguns modelos utilizados em SIG comerciais. O Módulo de Engenharia Reversa, ainda não implementado, possibilitará ao projetista obter esquemas conceituais a partir de aplicações de SIG existentes.
Figura 3 – Arquitetura da Ferramenta ArgoCASEGEO
As seções seguintes descrevem detalhadamente cada um destes módulos.
4.1 Módulo Gráfico.
A ferramenta ArgoCASEGEO possibilita a criação de diagramas que contêm os construtores e estereótipos sugeridos pelo modelo UML-GeoFrame. A partir deste diagrama o usuário pode criar o seu esquema conceitual de dados. Um esquema conceitual UML-GeoFrame suporta três tipos distintos de classes: Objeto Geográfico, Objeto não Geográfico e Campo Geográfico. Os campos existentes nas classes implementadas apresentam nome, atributos (e seus respectivos domínios), operações e símbolos correspondentes ao tipo de representação espacial.
Essas classes podem estar relacionadas entre si por meio de relacionamentos como generalização & especialização, agregação, composição ou associação. Numa associação podem ser especificados o nome do relacionamento e a multiplicidade de cada classe. As classes podem estar agrupadas de forma a constituírem um determinado tema, o que é modelado pelo construtor Pacote, da linguagem UML. A barra de construtores disponíveis é ilustrada na figura 4.
Figura 4: Barra de Ferramentas para o diagrama UML-GeoFrame
Módulo Gráfico Diagrama UML-GeoFrame ArgoUML (Java)
Módulo Dicionário de Dados Metamodelo UML-GeoFrame XML/XMI Repositório de Padrões de Análise Repositório de Esquemas Conceituais de dados
Módulo Geração Automática Regras de Transformação Conceitual-Lógico Formato Shape GeoMedia OpenGIS (GML) Módulo de Engenharia Reversa Regras de Transformação Lógico-Conceitual outros formatos TerraLib
A Figura 5 ilustra o ambiente ArgoCASEGEO contendo o padrão de análiseMalha Viária Urbana, composto das classesNóLogradouro,TrechoLogradouroeMalhaViária, que são subclasses da classe Objeto_Geográfico () e a classeLogradouro, subclasse de Objeto_Não_Geográfico (), isto é, não possui representação espacial. A classeNóLogradouropossui representação espacial do tipo ponto (),Trecho Logradouro do tipo linha () e Malha Viáriado tipo complexo (). Estão representados relacionamentos do tipo associação e agregação entre as classes modeladas.
Figura 5 – Ambiente gráfico do ArgoCASEGEO representando o padrão de análise Malha Viária no modelo UML-GeoFrame.
Um esquema de dados UML-GeoFrame pode ser salvo como um novo Padrão de Análise, podendo ser (re)utilizado em novos esquemas de dados, compondo-se assim, o Catálogo de Padrões de Análise. Por outro lado, se o projetista está iniciando um novo projeto é interessante antes consultar os padrões de análise existentes a fim de reutilizá-los. Além do diagrama, um padrão de análise pode conter uma documentação adicional, na qual podem estar descritos o contexto, as forças e exemplos de uso do padrão.
4.2. Módulo Dicionário de Dados.
O dicionário armazena o esquema de dados criado pelo usuário. Um esquema possui dois tipos de dados, os gráficos (desenho) e os semânticos (nomes das classes, dos atributos, multiplicidades das associações, etc). No dicionário de dados são armazenados os dados semânticos, enquanto os dados gráficos são armazenados em um arquivo do próprio ArgoCASEGEO.
O dicionário de dados armazena os esquemas conceituais no formato XMI. Toda classe é delimitada por um tag (ou marcação) que contém o nome da classe, suas representações espaciais (que variam de acordo com
<Foundation.Core.Class> <Foundation.Core.ModelElement.name>TrechoLogradouro</Foundation.Core.ModelElement.name> <Foundation.Core.GeneralizableElement.isLine xmi.value="true"/> <Foundation.Core.Classifier.feature> <Foundation.Core.Attribute> <Foundation.Core.ModelElement.name>SentidoCirc</Foundation.Core.ModelElement.name> <Foundation.Core.Classifier xmi.idref="xmi.16"/> </Foundation.Core.Attribute> <Foundation.Core.Operation> <Foundation.Core.ModelElement.name>getSentidoCir</Foundation.Core.ModelElement.name> <Foundation.Core.Classifier xmi.idref="xmi.14"/> <Foundation.Core.Parameter.type> <Foundation.Core.Classifier xmi.idref="xmi.21"/> </Foundation.Core.Parameter.type> </Foundation.Core.Operation> </Foundation.Core.Classifier.feature> </Foundation.Core.Class> <Foundation.Core.Association xmi.id="xmi.5"> <Foundation.Core.ModelElement.name>Rel_Logr_Trec</Foundation.Core.ModelElement.name> <Foundation.Core.Association.connection> <Foundation.Core.AssociationEnd xmi.id="xmi.6"> <Foundation.Core.AssociationEnd.isNavigable xmi.value="true"/> <Foundation.Data_Types.MultiplicityRange xmi.id="xmi.8"> <Foundation.Data_Types.MultiplicityRange.lower>1</Foundation.Data_Types.Multiplic ityRange.lower> <Foundation.Data_Types.MultiplicityRange.upper>*</Foundation.Data_Types.Multiplic ityRange.upper> </Foundation.Data_Types.MultiplicityRange> </Foundation.Core.AssociationEnd.association> </Foundation.Core.AssociationEnd> </Foundation.Core.Association.connection> </Foundation.Core.Association>
o tipo de classe especificada) e suas características (features). A tag “feature” possui dois níveis de detalhamento, responsáveis por armazenar os dados correspondentes a seus atributos e operações.
A figura 6 exemplifica o dicionário de dados correspondente à classe TrechoLogradouro, que possui representação espacial do tipo linha, o atributoSentidoCirce a operaçãogetSentidoCirc. Os tipos usados nesta definição, incluindo o tipo do atributo, parâmetros e valores de retorno das operações são referenciados externamente para outro trecho de código do mesmo arquivo que armazena as definições destes tipos, criado pelo próprio ArgoUML.
Figura 6 – Representação de uma classe UML-GeoFrame em XMI
Os relacionamentos entre as classes modeladas no esquema são mantidos em um tag específico, que armazena seu nome, propriedades relacionadas (que variam de acordo com o tipo, associação, agregação ou composição), sua multiplicidade e as referências das classes que compõe o relacionamento. Para a definição de generalizações, o tag interno é responsável por armazenar referências às subclasses e às superclasses. Herança múltipla é permitida.
Por fim, as definições dos pacotes são mantidas em um tag mais externo, que engloba todas as outras descritas anteriormente e possui apenas seu nome como atributo. A figura 7 exemplifica o dicionário de dados correspondente à associaçãoRel_Logr_Trec, que possui navegabilidade em ambas direções, multiplicidade um-para-muitos (1-*) e referências para as classes que o compõe.
4.3. Módulo Geração Automática.
Após a realização da modelagem conceitual, o usuário necessita transformar o esquema elaborado em uma implementação efetiva, caracterizando uma aplicação de SIG. Isto deve ser realizado após a definição do software de SIG que será utilizado. Como cada software de SIG possui seu próprio modelo lógico de dados, não é possível estabelecer um conjunto único de regras de transformação para fazer a geração automática do esquema lógico-espacial, ao contrário por exemplo da transformação de esquemas conceituais Entidade-Relacionamento em esquemas lógicos dos SGBD relacionais. Desta forma, para cada software de SIG a ferramenta ArgoCASEGEO necessita de um Módulo de Geração Automática (MGA) específico. Espera-se que com a adoção de um modelo de dados padrão, em desenvolvimento pelo Consórcio OpenGIS [22], este problema seja resolvido.
Dois MGAs já foram implementados na ferramenta ArgoCASEGEO. O primeiro módulo, descrito em [19], transforma esquemas UML-GeoFrame para o formato Shape, usado no SIG ArcView 3.2 (ESRI) e importado por quase todos os outros SIG. Um segundo módulo de geração, apresentado na seção abaixo, transforma esquemas conceituais UML-GeoFrame em esquemas lógico-espaciais do SIG GeoMedia, da Intergraph. Os próximos módulos a serem implementados são: (1) MGA-GML, que irá gerar esquemas segundo o modelo padrão que está sendo desenvolvido pelo consórcio OpenGIS; (2) MGA-TerraLib, que irá gerar esquemas de dados no formato da biblioteca de componentes espaciais TerraLib [6].
4.3.1. Módulo de Geração Automática GeoMedia.
O MGA-GeoMedia tem como entrada a identificação do dicionário de dados que contém o esquema conceitual a ser transformado. Para a criação de um ambiente de trabalho dentro deste software é necessária a criação de uma conexão com um banco de dados existente, que possa armazenar os layers (camadas de dados espaciais) de representação vetorial, ou seja, uma coleção de elementos do tipo ponto, linha, polígono ou objeto complexo, e as tabelas associadas a estes layers. Desta forma, o MGA-GeoMedia cria um banco de dados para armazenar todos os elementos gerados pelo mapeamento automático. O GeoMedia suporta vários outros SGBD relacionais.
Para cada elemento do esquema conceitual de dados é aplicada uma determinada regra de transformação. A seguir estão descritas estas regras.
Regra 1 – Pacotes
Um pacote é composto por um conjunto de classes inter-relacionadas. Portanto, define-se um banco de dados GeoMedia para cada pacote no esquema conceitual, que armazenará todos os temas gerados pelo mapeamento correspondente a ele, tanto os layers quanto suas tabelas relacionadas. Classes que não estejam definidas dentro de um pacote são armazenadas em um banco de dados padrão criado pelo mapeamento. Os nomes destes arquivos e suas localizações são fornecidos pelo usuário.
Regra 2 – Classes do tipo Objeto Geográfico ()
Cada classe modelada como Objeto_Geográfico gera pelo menos um layer dentro do seu banco de dados correspondente, cuja representação espacial é definida de acordo com o estereótipo de representação a ela atribuída. Estas representações espaciais só podem ser do tipo ponto, linha, polígono ou objeto complexo. O conjunto de atributos definidos na classe é associado à representação espacial, sendo definidos como campos da mesma tabela relacional.
Para classes que possuam múltiplas representações espaciais o usuário pode escolher entre gerar vários layers com as distintas representações espaciais ou optar pela criação de um único layer de representação complexa, onde podem ser definidos tanto pontos, quanto linhas ou polígonos. O projetista deve decidir, em tempo de execução, qual tipo de mapeamento deseja.
Regra 3 – Classes do tipo Campo Geográfico ()
Como foi dito na seção 2, a realidade geográfica pode ser observada de acordo com duas visões [11]. A visão de campos geográficos enxerga o espaço geográfico como uma superfície contínua, sob a qual variam os fenômenos a serem observados segundo diferentes distribuições.
O GeoMedia é um software vetorial, ou seja, possibilita apenas a representação espacial de objetos do tipo ponto, linha ou polígono. Portanto, não é possível realizar um mapeamento automático dos objetos que são modelados como campo. Porém, segundo Goodchild [11], as representações de campos geográficos nada mais são do que agregações de pontos, linhas e polígonos, acoplados a características espaciais. Um campo com representação espacial do tipo Isolinhas, por exemplo, pode ser mapeado em um layer de representação do tipo linha, possuindo um valor (cota) associado a cada linha. De acordo com esta análise, o programa propõe algumas sugestões de mapeamento para o projetista, que pode optar por uma delas. Além dos atributos sugeridos, são acrescidos à tabela também os atributos pertencentes a cada classe.
Regra 4 – Classes do tipo Objeto Não Geográfico ()
Cada classe modelada como Objeto_Não_Geográfico gera apenas uma tabela dentro do banco de dados correspondente. Objetos são classificados como Não Geográficos justamente por não possuírem representação espacial.
Regra 5 – Associação, Agregação e Composição
O mapeamento de relacionamentos do tipo agregação, composição e associação é realizado de acordo com a multiplicidade especificada. Existem basicamente três grandes tipos de multiplicidades de uma associação: um-para-um (1..1); um-para-muitos (1..*); e muitos-para-muitos (*..*), sendo que os demais tipos são derivações destes. Este mapeamento se baseia nas regras de transformação de associações especificadas em um esquema conceitual para um esquema lógico de um SGBD relacional, que são bem conhecidas [8]. Regra 6 –Generalização & Especialização
O mapeamento de relacionamentos do tipo generalização-especialização (IS-A) pode ser realizado de três formas distintas, descritas sucintamente abaixo. Estas opções de generalização são informadas pelo projetista durante a criação do esquema conceitual, sendo a opção (A) adotada como padrão. São elas:
Opção A: Os atributos da superclasse e das subclasses são unidos em uma única tabela, que recebe o nome da superclasse. A representação espacial é escolhida de acordo com os tipos das subclasses associadas. Por exemplo, seja a superclasse Recursos_Hidricos que possui as subclasses Rio e Lago. Se ambas subclasses possuírem representação espacial do tipo polígono, Recursos_Hidricos também será mapeada com esta representação. Porém, se Riofor do tipo linha e Lagodo tipo polígono,Recursos_Hidricosterá representação múltipla.
Opção B: São mapeadas apenas as subclasses, de acordo com seus atributos e representações espaciais. Os atributos da superclasse são acrescentados ao conjunto de atributos das subclasses.
Opção C: É criada para cada classe uma tabela contendo seus atributos. As subclasses possuem a representação espacial definida no esquema conceitual e a superclasse é composta apenas de uma tabela. Os atributos definidos como chave da superclasse são mapeados também como atributos das subclasses. Cada classe dá origem a um layer com a representação espacial especificada e a uma tabela associada que contém os atributos descritivos. As tabelas referentes às subclasses têm a mesma chave da tabela referente à superclasse.
Para exemplificar o processo de geração automática pode-se tomar como entrada o dicionário de dados do esquema conceitual mostrado na figura 5 (Padrão Malha Viária). O MGA-GeoMedia irá criar o esquema lógico-espacial mostrado na Figura 8. A janela Malha_Viária, com a sub-janela Legend ilustra o esquema espacial gerado, composto de três layers:Malha_Viária, com representação do tipo Objeto Complexo; Nó-Logradouro, com representação do tipo ponto; e Trecho_Logradouro, com representação do tipo linha. As demais janelas ilustram as tabelas relacionais que foram geradas, são elas: Logradouro, Malha_Viária, Nó-Logradouro e Trecho_Logradouro. Com exceção da tabela Logradouro, as outras três tabelas ficam automaticamente relacionadas com seus respectivos layers. A partir deste esquema o usuário pode optar por incluir ou importar os dados, realizando o processo de carga do BDG.
Figura 8 - Esquema Malha Viária gerado automaticamente para o GeoMedia
5. Conclusões.
O uso de uma ferramenta CASE no processo de desenvolvimento de aplicações de SIG faz com que o tempo de criação do projeto seja reduzido, possibilitando uma conseqüente redução de custos e aumento na qualidade dos bancos de dados geográficos.
A ferramenta ArgoCASEGEO foi desenvolvida para auxiliar o projetista a desenvolver suas aplicações de SIG com mais qualidade, seguindo uma metodologia de projeto tendo como base um modelo conceitual específico para aplicações geográficas e uma coleção reutilizável de padrões de análise. A documentação produzida ao longo do projeto (ex.: esquema conceitual e dicionário de dados) possibilita posteriores consultas e visualizações, o que facilita consideravelmente a futura manutenção do sistema e a geração imediata de novas versões da aplicação com as atualizações. O armazenamento do dicionário de dados no formato XML/XMI permite o intercâmbio de esquemas e pode servir para novos usos como, por exemplo, por ferramentas automáticas de descoberta e busca de padrões de análise.
Como trabalhos futuros estão previstos o desenvolvimento dos novos módulos de geração automática (MGA-GML e MGA-TerraLib) e a implementação do módulo de engenharia reversa.
Agradecimento
Este trabalho foi parcialmente financiado pelo Conselho Nacional de Desenvolvimento Científico e Tecnológico – CNPq, entidade governamental brasileira promotora do desenvolvimento científico e tecnológico.
6. Referências bibliográficas.
[1] Bédard, Y. “Visual modeling of spatial databases towards spatial extensions and UML”, Geomatica, v.53, n.2, 1999. [2] Bhering, E. M.; Lisboa Filho, J.; Calijuri, M. L.; Souza, L. A. DE. A. “Sistema de informação da rede de
infra-estrutura sanitária de Cachoeiro de Itapemirim-ES”. Informática Pública, v.4, n.1, 2002.
[3] Booch, G.; Jacobson, I.; Rumbaugh, J. The Unified Modeling Language User Guide. Addison-Wesley, 1998. [4] Borges, K. A. V.; Davis Jr, C. D. Laender, A.H.F. “OMT-G: an object-oriented data model for geographic
applcations”. GeoInformatica, v.5, n.3, 2001.
[5] Brodeur, J; Bérdard, Y.; Proulx, M., J.; “Modeling Geospatial Application Databases using UML-based Repositories Aligned with International Standards in Geomatics”. In Proc. 8th ACM GIS, Washinghton D.C, 2000. [6] Câmara, G.; Monteiro, A. M. V.; Cartaxo, R.; Paiva, J. A. C. “TerraLib - Tecnologia Brasileira de Geoinformação:
para quem e para quê?”, Informática Pública, v.4, n.1, 2002.
[7] Chrisman, N. Exploring Geographic Information Systems. John Wiley & Sons, 1997. [8] Elmasri, R.; Navathe, S. B. Fundamentals of Database Systems. 3.ed. Addison-Wesley, 2000. [9] Fowler, M. Analysis Patterns: Reusable Object Models. Addison Wesley Longman, 1997.
[10] Gamma, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, 1994. [11] Goodchild, M. F., “Geographical data modeling”, Computers & Geosciences, v.18, n. 4, 1992, pp 401-408. [12] Hay, D. C. Data Model Patterns: Conventions of Thought. Dorset House Publishing, 1995.
[13] Isoware. CASE-Toll REGIS. Disponível em http://www.isoware.de/, Acessado em março de 2002. [14] Kösters, G. et al. “GIS-Application Development with GeoOOA”. Int. Jounnal of GIS, v.11, n.4, 1997.
[15] Lbath A., Pinet, F. “The Development and Customization of GIS-Based Applications and Web-Based GIS Applications with the CASE Tool AIGLE”. In Proc. 8th ACM GIS, Washinghton D.C, 2000.
[16] Lisboa Filho, J.; Iochpe, C.; Beard, K. “Applying Analysis Patterns in the GIS Domain”. In Proc. 10th Annual Colloquium of the SIRC, Dunedin, NZ, 1998,.
[17] Lisboa Filho, J.; Iochpe, C. “Specifying analysis patterns for geographic databases on the basis of a conceptual framework”. In Proc.7th ACM GIS, Kansas City, 1999.
[18] Lisboa Filho, J.; Iochpe, C.; Borges, K. A. “Analysis patterns for GIS data schema reuse on urban management applications”. CLEI Electronic Journal, v.5, n.2, 2002, pp 1-15.
[19] Lisboa Filho, J.; Pereira, M. A. “Desenvolvimento de uma ferramenta CASE para o Modelo UML-Geoframe com Suporte para Padrões de Análise”. In: IV Simpósio Brasileiro de Geoinformática - GEOINFO, 2002, Caxambú-MG. Anais... Caxambú: SBC, 2002.
[20] Minout, M.; Parent, C.; Zimányi, E. A Tool for Transforming Conceptual Schemas of Spatio-Temporal Databases with Multiple Representations. In Proc. of the IASTED Int. Conf. on Database Applications, DBA'2004, Innsbruck, Austria, 2004.
[21] Object Management Group. Meta Objects Facility (MOF) Specification. 2000. Available in: http://www.omg.org. [22] OpenGIS. The OpenGIS Guide. K. Buehler and L Mckee (eds). Open GIS Consortium Technical Committee, 1998. [23] Parent, C. et al. “Spatio-temporal conceptual models: data structures + space + time”. In Proc.7th ACM GIS, Kansas
City, 1999.
[24] Simon Cox , Paul Daisey, Ron Lake, Clemens Portele, Arliss Whiteside. OpenGIS® Geography Markup Language (GML) Implementation Specification. Open GIS Consortium, Inc., 2003.
