desenvolvimento de um plug-in eclipse para modelagem de …siaibib01.univali.br/pdf/marcos antonio...
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ MESTRADO EM CIÊNCIA E TECNOLOGIA AMBIENTAL
Desenvolvimento de um plug-in Eclipse para modelagem de aplicações geoespaciais
Marcos Antonio da Rocha Ferreira
Itajaí, 1 de junho, 2009
UNIVERSIDADE DO VALE DO ITAJAÍ MESTRADO EM CIÊNCIA E TECNOLOGIA AMBIENTAL
Desenvolvimento de um plug-in Eclipse para modelagem de aplicações geoespaciais
Marcos Antonio da Rocha Ferreira
Dissertação apresentada à Universidade do Vale do Itajaí, como parte dos requisitos para obtenção do grau de Mestre em Ciência e Tecnologia Ambiental. Orientador: Prof. Dr. Rafael Medeiros Sperb
Itajaí, 1 de junho, 2009
i
SUMÁRIO
LISTA DE FIGURAS ...........................................................................................................iv
LISTA DE QUADROS .........................................................................................................vi
LISTA DE ABREVIAÇÕES............................................................................................... vii
RESUMO..............................................................................................................................ix
1 INTRODUÇÃO...................................................................................................................1
1.1 Definição do problema ..................................................................................................3
1.2 Justificativa ...................................................................................................................4
1.3 Objetivos.......................................................................................................................5
1.3.1 Objetivo geral .........................................................................................................5
1.3.2 Objetivos específicos ..............................................................................................5
1.4 Metodologia e estrutura do trabalho ..............................................................................6
2 MODELOS CONCEITUAIS PARA DADOS GEOGRÁFICOS .......................................10
2.1 Noções básicas sobre SIGs ..........................................................................................10
2.2 Banco de Dados Geográficos.......................................................................................11
2.3 Modelos de dados........................................................................................................12
2.4 Modelos conceituais de dados geográficos ..................................................................15
2.4.1 Modelo E-R..........................................................................................................15
2.4.2 Modelo IFO..........................................................................................................16
2.4.3 Modelo OO...........................................................................................................17
2.4.3.1 Modelo OMT-G .............................................................................................18
2.4.3.1.1 Representação gráfica de geo-campos e geo-objetos.................................20
2.4.3.1.2 Relacionamentos......................................................................................21
2.4.4 Comparação entre os formalismos E-R, IFO e OO................................................22
2.5 Considerações finais....................................................................................................24
3 CONVERSÃO DE MODELOS UML PARA GML ESQUEMA .......................................25
3.1 Noções básicas sobre XML esquema e GML esquema ................................................25
3.2 Gerando GML esquemas a partir de modelos UML.....................................................27
3.2.1 Pacotes .................................................................................................................28
ii
3.2.2 Classes – Regras gerais .........................................................................................30
3.2.2.1 Classes – Tipos básicos ..................................................................................30
3.2.2.2 Classes – DataType ........................................................................................31
3.2.2.3 Classes – FeatureType....................................................................................32
3.2.2.4 Classes – Type ...............................................................................................33
3.2.2.5 Classes – Enumerations ..................................................................................34
3.2.2.6 Classes – CodeList .........................................................................................35
3.2.2.7 Classes – Union..............................................................................................36
3.3 Atributos .....................................................................................................................36
3.4 Relacionamentos .........................................................................................................37
3.5 Entidades geográficas..................................................................................................39
3.6 Ferramentas de conversão de UML para GML esquema..............................................41
3.7 Exemplos de GML esquema........................................................................................42
3.8 Considerações finais....................................................................................................42
4 PLUG-IN UML2GML.......................................................................................................44
4.1 Características do plug-in UML2GML ........................................................................44
4.2 Arquitetura do plug-in UML2GML .............................................................................44
4.2.1 Model Driven Architecture ...................................................................................46
4.2.2 Plataforma Eclipse ................................................................................................48
4.2.2.1 Arquitetura da plataforma Eclipse ..................................................................48
4.2.2.2 Plug-in Eclipse ...............................................................................................50
4.2.2.3 Eclipse Modeling ...........................................................................................51
4.2.2.4 GMF ..............................................................................................................52
4.2.3 MDT/Papyrus .......................................................................................................54
4.2.3.1 Perfil OGC .....................................................................................................56
4.2.4 Java Emitter Template ..........................................................................................57
4.3 Diagrama de atividade do plug-in UML2GML............................................................59
4.4 Procedimentos de uso do plug-in UML2GML.............................................................60
4.5 Procedimento de teste e validação do plug-in UML2GML ..........................................61
iii
4.6 Considerações finais....................................................................................................64
5 ESTUDO DE CASO: CONCAR .......................................................................................65
5.1 CONCAR - Comissão Nacional de Cartografia ...........................................................65
5.2 Estrutura de Dados Geoespaciais Digitais Vetoriais da MND ......................................66
5.3 Procedimentos para a aplicação do estudo de caso.......................................................67
5.3.1 Seleção de pacote para o estudo de caso................................................................68
5.3.2 Modelagem do pacote dentro da ferramenta Papyrus.............................................71
5.3.3 GML esquema do estudo de caso ..........................................................................76
5.3.4 Exemplo de produto gerado a partir do GML esquema Relevo..............................80
5.4 Considerações finais....................................................................................................82
6 RESULTADOS E DISCUSSÕES......................................................................................83
6.1 Plug-in UML2GML ....................................................................................................83
6.2 Estudo de caso ............................................................................................................84
7 CONSIDERAÇÕES FINAIS.............................................................................................88
7.1 Conclusões..................................................................................................................88
7.2 Recomendações...........................................................................................................91
REFERÊNCIAS ...................................................................................................................92
ANEXO I – Lista de objetos GML da série ISO 19100.........................................................96
ANEXO II – Dicionário de dados da categoria Relevo..........................................................99
iv
LISTA DE FIGURAS
Figura 1. Metodologia e estrutura da dissertação.....................................................................6
Figura 2. Arquitetura de um SIG...........................................................................................11
Figura 3. Fases de um projeto de banco de dados. .................................................................12
Figura 4. Processo de modelagem conceitual ........................................................................13
Figura 5. Evolução histórica dos modelos conceituais para dados geográficos. .....................15
Figura 6. Construtores básicos do modelo E-R......................................................................16
Figura 7. Notação gráfica do modelo IFO.. ...........................................................................17
Figura 8. Notação gráfica do modelo OO..............................................................................18
Figura 9. Notação gráfica para as classes do modelo OMT-G. ..............................................19
Figura 10. Exemplos de representação de geo-campos no modelo OMT-G.. .........................20
Figura 11. Representação de geo-objetos no modelo OMT-G. ..............................................21
Figura 12. Relacionamentos do modelo OMT-G...................................................................21
Figura 13. Cardinalidade.......................................................................................................22
Figura 14. Estrutura de componentes de um XML esquema..................................................26
Figura 15. Exemplo de mapeamento de informações de um pacote UML. ............................27
Figura 16. Padrão de mapeamento de informações de pacote. ...............................................28
Figura 17. Exemplificação da utilização do recurso dos elementos <include> e <import> em um GML esquema.. ..............................................................................................................29
Figura 18. Exemplo trivial do mapeamento de uma classe UML para um GML esquema “Estrada”..............................................................................................................................31
Figura 19. Exemplo do mapeamento de uma classe UML com o estereótipo <<DataType>>...............................................................................................................................................31
Figura 20. Exemplo do mapeamento de uma classe UML com o estereótipo <<FeatureType>>.................................................................................................................33
Figura 21. Exemplo do mapeamento de uma classe UML com estereótipo <<Type>> ou sem estereótipo.. ..........................................................................................................................34
Figura 22. Exemplo do mapeamento de uma classe UML com o estereótipo <<Enumeration>>.. ..............................................................................................................34
Figura 23. Exemplo do mapeamento de uma classe UML com o estereótipo <<CodeList>>...............................................................................................................................................35
v
Figura 24. Exemplo do mapeamento de uma classe UML com o estereótipo <<Union>>.. ...36
Figura 25. Padrões para o mapeamento do relacionamento em um documento GML esquema..............................................................................................................................................37
Figura 26. Padrão de mapeamento para relacionamento com uma extremidade navegável. ...38
Figura 27. Padrão de mapeamento para relacionamento de agregação...................................38
Figura 28. Padrão de mapeamento para relacionamento com as duas extremidades navegáveis..............................................................................................................................................39
Figura 29. Exemplo de conversão de classes UML com estereótipos de entidades geográficas..............................................................................................................................................41
Figura 30. Arquitetura do plug-in UML2GML......................................................................45
Figura 31. Visão geral do funcionamento de uma MDA........................................................47
Figura 32. Arquitetura da plataforma Eclipse: elementos obrigatórios (branco), elementos não obrigatórios, porém recomendados (cinza claro) e elementos opcionais (cinza escuro)..........49
Figura 33. Arquitetura de um plug-in Eclipse........................................................................51
Figura 34. Arquitetura do GMF. ...........................................................................................52
Figura 35. Funcionamento do GMF. .....................................................................................53
Figura 36. Arquitetura MDT/Papyrus. ..................................................................................55
Figura 37. Perspectiva MDT/Papyrus. ..................................................................................56
Figura 38. Palette tools da ferramenta Papyrus com os estereótipos do modelo OMT-G. ......57
Figura 39. Funcionamento do JET. .......................................................................................58
Figura 40. Diagrama de atividade do plug-in UML2GML. ...................................................60
Figura 41. Procedimentos para uso do plug-in UML2GML...................................................61
Figura 42. Modelo conceitual exemplo proposto pela OGC (2007) e implementado na ferramenta Papyrus com perfil OGC. ....................................................................................62
Figura 43. Estrutura organizacional da CONCAR.................................................................66
Figura 44. Etapas para aplicação do estudo de caso...............................................................68
Figura 45. Modelo conceitual original do pacote Relevo da EDGV.......................................70
Figura 46. Exemplo da ocorrência da não-conformidade 3 no pacote Relevo e seu respectivo mapeamento para GML esquema..........................................................................................72
Figura 47. Modelo conceitual do pacote Relevo na ferramenta Papyrus. ...............................75
Figura 48. Trecho do documento GML exemplo gerado a partir do GML esquema do pacote Relevo. Parte superior: visualização gráfica do documento GML completo. .........................81
vi
LISTA DE QUADROS
Quadro I. Comparação entre os formalismos para modelos conceituais de dados geográficos...............................................................................................................................................23
Quadro II. Resumo do mapeamento de conceitos UML para elementos GML esquema.. ......28
Quadro III. Parte superior: tipos ISO básicos convertidos para tipos XML esquema. Parte inferior: tipos espaciais convertidos para GML. ....................................................................30
Quadro IV. Mapeamento de geometria para objetos GML.. ..................................................40
Quadro V. Relação de não-conformidades encontradas no modelo conceitual Relevo e seus respectivos protocolos de correção........................................................................................86
vii
LISTA DE ABREVIAÇÕES
AIXM Aeronautical Information eXchange Model ANA Agência Nacional da Água API Application Programming Interface
ATL ATLAS Transformation Language BDG Banco de Dados Geográficos CASE Computer-Aided Software Engineering CONCAR Comissão Nacional de Cartografia CSML Climate Science Modelling Language CVS Concurrent Versions System
DDL Data Definition Language DSG Diretoria de Serviço Geográfico EDGV Estruturação de Dados Geoespaciais Vetoriais EMF Eclipse Modeling Framework EMFT Eclipse Modeling Framework Technology
E-R Entity-Relationship FME Feature Manipulation Engine
FWTools Frank Warmerdam Tools
GEF Graphical Editing Framework Geo-ER Geo Entity-Relationship GeoIFO Geo Is-a relationships, Functional relationships, Complex objects
Geo-OM Geographic-object Modeling GeoSciML Geoscience Markup Language GISER Geographic Information System Entity Relational GMF Graphical Modeling Framework GML Geographic Markup Language
GMOD Generic Model Organism Databate
HTML HyperText Markup Language
IBGE Instituto Brasileiro de Geografia e Estatística IDE Integrated Development Environment IFO Is-a relationships, Functional relationships, Complex objects
INDE-Brasil Infraestrutura Nacional de Dados Espaciais do Brasil IPTU Imposto sobre a Propriedade Predial e Territorial Urbana
ISO International Organization for Standardization
ISO/DIS International Organization for Standardization/Draft International
Standard
JDT Java Development Tool
JET Java Emmitter Template
JFace Java Face
JSP Java Server Pages
M2M Model to Model M2T Model to Text MADS Modeling of Application Data with Spatio-temporal features
MDA Model Driven Architecture
MDD Model Driven Development MDE Model Driven Engineering MDT Model Development Tools
MND Mapoteca Nacional Digital
viii
Modul-R Module-Relationship MOF Meta-object Facility
MVC Model–View–Controller OCL Object Constraint Language OGC Open Geospatial Consortium
OMG Object Management Group OMT-G Object Modeling Technique-Geographic OO Orientação a Objetos OSGi Open Services Gateway Initiative PCN Política Cartográfica Nacional PDA Personal Digital Assistants PDE Plug-in Development Environment PIM Platform Independent Model PSM Platform Specific Model
SCN Sistema Cartográfico Nacional SDE Subcomissão de Dados Espaciais SensorML Sensor Markup Language SGBD Sistema Gerenciador de Banco de Dados SIG Sistema de Informação Geográfica SNIRH Sistema Nacional de Informação sobre Recursos Hídricos SQL Structured Query Language SWT Standard Widget Toolkit TIN Triangulated Irregular Network uDig User-friendly, Desktop-located, Internet-oriented, GIS-ready
UML Unified Modeling Language
UML2 Unified Modeling Language 21
UML2GML UML to GML UMT-QVT UML Query, View, Transformation USM Unifying Semantic Model VBA Visual Basic for Application
W3C World Wide Web Consortium XMI XML Metadata Interchange XML eXtensible Markup Language
1 Nota do autor: não confundir com a linguagem UML. UML2, nesta dissertação, se refere ao metamodelo utilizado dentro da plataforma Eclipse.
ix
RESUMO
O presente trabalho teve o objetivo de desenvolver um plug-in Eclipse que possibilitasse a
conversão de modelos UML (Unified Modeling Language) de dados geográficos para GML
(Geographic Markup Language) esquemas. Um plug-in é um mecanismo de extensão da
ferramenta Eclipse, plataforma de conjunto de serviços usados na construção de aplicações.
Um modelo conceitual UML pode ser qualificado como a descrição e a definição de conteúdo
de dados, além de estruturas e regras a eles aplicadas. Um GML esquema é uma gramática
XML (eXtensible Markup Language) utilizada na descrição de esquemas de aplicação
(application schemas). Um esquema de aplicação é empregado para gerar outros produtos,
como documentos GML, esquemas de Bancos de Dados Geográficos e códigos de
programação para aplicações SIG, sejam desktop, móvel ou Web. A metodologia adotada para
a realização deste trabalho foi dividida em três grandes etapas: revisão bibliográfica,
implementação e análise. A etapa de revisão forneceu o conhecimento necessário para a etapa
de implementação, a qual gerou resultados (dentre eles, a ferramenta proposta pela
dissertação) que passaram para a etapa de análise. Essa última etapa, por sua vez, produziu as
conclusões e as considerações finais do trabalho. A implementação em si do plug-in envolveu
diversos conceitos e tecnologias, tais como: plataforma Eclipse (base tecnológica da
ferramenta); MDA (Model Driven Architecture, conceito de transformação de modelos UML
para código); GMF (Graphical Modeling Framework, ferramenta para geração de editores
gráficos baseados em modelos de domínios); EMF (Eclipse Modeling Framework, ferramenta
de criação e acessos a modelos); UML2 (padrão UML 2.x em formato de metamodelo para a
plataforma Eclipse); JET (Java Emitter Template, ferramenta geradora de templates); Papyrus
(editor gráfico UML). Para validação e teste do plug-in, foi elaborado um estudo de caso,
baseado em um modelo UML proposto pela CONCAR (Comissão Nacional de Cartografia).
No final do estudo de caso, foi gerado um GML esquema, o qual, por sua vez, gerou um
documento GML totalmente válido e funcional. Os resultados da aplicação do estudo de caso
demonstram o enorme potencial da ferramenta proposta por esta dissertação, porém também
mostram a necessidade dos desenvolvedores de GML esquemas de tomarem certos cuidados
durante o processo de modelagem, para que o GML esquema resultante seja adequado à
aplicação-alvo.
Palavras-chave: GML, MDA, UML, plug-in Eclipse, modelos conceituais.
x
ABSTRACT
This work aimed at developing an Eclipse plug-in to allow the conversion of UML (Unified
Modeling Language) models to GML (Geographic Markup Language) schemas. A plug-in is
an extension mechanism of Eclipse, which is a platform of a set of services used for building
applications. A UML conceptual model may be regarded as the description and definition of
data content, plus structures and rules applied to it. A GML schema is a XML (eXtensible
Markup Language) grammar used for describing application schemas. An application schema
is used to generate other products, such as GML documents, Geographic Database schemas,
and programming codes for GIS applications, whether desktop, mobile or Web applications.
This work's methodology was divided into three steps: literature research, implementation,
and analysis. The first step provided the knowledge required by the implementation step,
which generated results (as the tool proposed by this work) that underwent the analysis step.
This last step produced the work's conclusions and final thoughts. The implementation of the
plug-in involved many concepts and technologies, for instance: Eclipse platform (the tool's
technological base); MDA (Model Driven Architecture - concept for transforming UML
models into code); GMF (Graphical Modeling Framework - tool for generating graphic
editors based on domain models); EMF (Eclipse Modeling Framework - tool for creating and
accessing models); UML2 (UML 2.x standard in metamodel format for the Eclipse platform);
JET (Java Emitter Template - tool for generating templates); Papyrus (UML graphic editor).
As means to validate and test the plug-in, a case study was elaborated, based on a UML
model proposed by CONCAR (Comissão Nacional de Cartografia - Brazilian Commission on
Cartography). In the end of the case study, a GML schema was generated, which in turn
generated a fully valid and functional GML document. The case study results show the large
potential of the tool proposed by this work. Nevertheless, they also point that GML schema
developers shall be cautious during the modeling process, so that the resultant GML schema
is appropriate to the target application.
Keywords: GML, MDA, UML, Eclipse plug-in, conceptual models.
1
1 INTRODUÇÃO
Interpretar a realidade ao redor é um comportamento inerente ao ser humano desde
seus primórdios, quando o homem pré-histórico representava seu ambiente através de pinturas
rupestres, até a atualidade, quando o desenvolvimento da tecnologia possibilita o acesso a
informações geográficas através do uso de celulares e PDA (Personal Digital Assistants). A
atividade de interpretar a realidade, seja no passado pré-histórico ou nos dias atuais, requer
uma ferramenta fundamental: um modelo.
Um modelo pode ser definido como uma representação simplificada da realidade
(SAYÃO, 2001). O homem pré-histórico utilizava um conjunto de representações pictóricas
(animais, figuras humanas e figuras geométricas abstratas) para descrever situações do seu
dia-a-dia, como danças, caças e rituais religiosos. Pode-se dizer que essas representações
pictóricas fazem parte de um modelo que descreve a realidade do cotidiano da pré-história.
Portanto, em sua essência, tal modelo não é muito diferente dos modernos modelos
conceituais de dados geográficos que utilizam pictogramas para representar objetos
geográficos do mundo real.
Na área de Sistemas de Informação Geográfica (SIG), um modelo busca sistematizar o
entendimento a respeito de objetos e fenômenos. Porém, objetos e fenômenos reais são
complexos demais para permitir uma representação completa. Logo, é necessário construir
uma abstração dos objetos e fenômenos do mundo real, de modo a se obter uma forma de
representação convincente, embora simplificada, que seja adequada às finalidades do SIG
(BORGES, 1997; BORGES; DAVIS JR.; LAENDER, 2005).
Uma abstração pode ser definida como um processo que busca o entendimento de um
sistema através de uma abordagem reducionista. Isso significa que uma abstração obtém o
conhecimento de um sistema dividindo-o em componentes separados, e, assim, cada
componente passa a ser visualizado em níveis diferentes de detalhes, de acordo com a
necessidade de compreensão e representação das diversas entidades de interesse do SIG e suas
interações (BORGES; DAVIS JR.; LAENDER, 2005).
Lisboa Filho et al. (2000) definem modelo de dados como o processo de abstração em
que somente os elementos essenciais da realidade observada são enfatizados, descartando os
elementos não-essenciais. Por sua vez, um modelo conceitual pode ser definido como a
descrição e a definição do conteúdo dos dados, além de estruturas e regras a eles aplicadas. A
modelagem conceitual é sempre baseada em algum formalismo, como, por exemplo:
Entidade-Relacionamento (E-R); Orientado a Objetos (OO); IFO (Is-a relationships,
2
Functional relationships, Complex objects). O formalismo mais utilizado é o OO, existindo
diversos modelos de dados geográficos que utilizam essa abordagem, como o modelo OMT-G
(Object Modeling Technique-Geographic).
O resultado do processo de modelagem conceitual, denominado esquema conceitual, é
apresentado através de uma linguagem formal de descrição (LISBOA FILHO et al., 2000).
No caso do formalismo OO, a linguagem de descrição mais utilizada é a UML (Unified
Modeling Language). A UML é padronizada pelo Object Management Group (OMG), sendo
hoje a linguagem mais difundida para modelagem. É utilizada em inúmeros projetos
comerciais ou open source e ensinada para um número cada vez maior de profissionais ou
estudantes de ciência da computação.
Para uso comercial, a modelagem conceitual UML tem, à disposição, uma série de
ferramentas, como a IBM Rational Rose2. Ferramenta conceituada que disponibiliza, aos
usuários, vários recursos que facilitam e automatizam o processo de modelagem conceitual.
Dentro da comunidade open source, destaca-se a iniciativa da Fundação Eclipse com
inúmeros sub-projetos de ferramentas de modelagem UML, como por exemplo: TopCased;
Moskitt; Papyrus (editor UML utilizado nesta dissertação). Essa diversidade de ferramentas
do Projeto Eclipse se deve às seguintes características:
• Estrutura modular, voltada para o uso e o desenvolvimento de plug-in;
• Existência do subprojeto Eclipse Modeling, focado na utilização de tecnologias
relacionadas a desenvolvimento baseado em modelagem;
• Existência de projetos de editores UML com foco no desenvolvimento contínuo do
framework EMF (Eclipse Modeling Framework), que possibilita a manipulação de
modelos conceituais de forma transparente.
Com a popularização das tecnologias SIG, é cada vez maior a demanda por
ferramentas que proporcionem não apenas recursos que facilitem o desenvolvimento dessas
tecnologias, mas que também sigam os padrões internacionalmente aceitos pela comunidade,
como a OGC (Open Geospatial Consortium). A tecnologia da plataforma Eclipse, junto com
seu subprojeto Modeling, se mostram mais do que capacitados para atender a demanda por
desenvolvimento de ferramentas open source voltadas para modelagem de dados geográficos.
Das figuras rupestres do homem pré-histórico até os modernos editores UML Eclipse
que agregam recursos MDA (Model Driven Architecture), foi um longo caminho. No entanto,
2 www.ibm.com/software/rational
3
a essência comum de ambas as atividades continua a mesma: a necessidade da humanidade de
descrever o ambiente que a rodeia, numa tentativa de entender seu papel no mundo.
1.1 Definição do problema
Na área ambiental, existem numerosos exemplos de aplicações da tecnologia SIG, tais
como estudo de desastres naturais (terremotos, tsunamis, enchentes, dentre outros), avaliação
de recursos naturais como água e petróleo, planejamento urbano de grandes metrópoles e
monitoramento da poluição do ar causada pelo uso de combustíveis fósseis (ONSRUD et al.,
2004).
Proporcional à quantidade de aplicações da tecnologia SIG, o volume disponível de
dados geográficos relacionados com a área ambiental está aumentando rapidamente. A essa
premissa, acrescenta-se o fato de que, com o uso da Internet, há um maior intercâmbio de
informações entre SIGs de diferentes organizações (sejam militares, governamentais ou não-
governamentais). Está sendo montado um cenário em que uma grande quantidade de dados
geoespaciais é transportada entre diferentes entidades que, por sua vez, utilizam esses dados
de formas distintas entre si (KOTZINOS & CHRYSOULAKYS, 2003). Diante desse fato,
surge o conceito de Infraestrutura de Informações Espaciais (Spatial Information
Infrastructure).
Um Infraestrutura de Informações Espaciais pode ser definida como uma iniciativa
que busca responder a necessidades de informações geoespaciais de domínios diferentes,
espalhadas em governos, indústrias, instituições acadêmicas, organizações e comunidade de
interesse público. Partindo desse conceito, nasce, de forma institucional, a Infraestrutura
Nacional de Dados Espaciais – INDE (National Spatial Data Infrastructure - NSDI), definida
como a tecnologia, política, padrões, recursos humanos e atividades relacionadas necessárias
para adquirir, processar, distribuir, usar, manter e arquivar dados geoespaciais (OMB, 2001
apud ONSRUD et al., 2004). No Brasil, em 2008, uma iniciativa similar é criada: o Governo
Federal institui, através de decreto, a Infraestrutura Nacional de Dados Espaciais Brasil
(INDE-Brasil3).
Um padrão utilizado em uma INDE é a tecnologia de documentos GML (Geographic
Markup Language), que possibilita o intercâmbio de dados geoespaciais. Um documento
GML é um padrão XML (eXtensible Markup Language) para transporte e armazenamento de
informações geográficas (OGC, 2007). O problema abordado nesta dissertação é o processo
3 Nota do autor: conferir o tópico 5.2.
4
de criação de documentos GML para comunidades ou domínios específicos. A base para a
criação de um documento GML é o GML esquema (GML schema), que tem a função de
descrever a estrutura de dados (geoespaciais e atributos) de um documento GML.
Um GML esquema, além de definir a estrutura de dados de um documento GML,
possui a função de fornecer a interoperabilidade dos padrões OGC e disponibilizar, aos seus
usuários, um grande leque de classes básicas que possibilitam a estruturação dos dados
conforme as necessidades da comunidade à qual o GML esquema é destinado.
A notação da linguagem UML é cada vez mais dominada por profissionais de áreas
distintas da computação, o que viabiliza o desenvolvimento de ferramentas que automatizem
a geração de GML esquemas a partir de modelos conceituais UML, seguindo os padrões
estabelecidos pela OGC (2007). O público-alvo dessas ferramentas consiste em comunidades
de áreas diversas que desejam padronizar e divulgar seus próprios dados geográficos.
1.2 Justificativa
A disponibilização de ferramentas que facilitem o desenvolvimento de GML esquemas
é uma das principais reivindicações da comunidade SIG, haja vista a crescente demanda por
dados geográficos e a necessidade de divulgação e compartilhamento destes por entidades
civis e governamentais. Duas iniciativas de órgãos federais brasileiros confirmam essa
tendência:
• A Agência Nacional de Água (ANA), dentro da iniciativa do Sistema Nacional de
Informação sobre Recursos Hídricos (SNIRH), propõe métodos de construção e
modelagem da base hidrográfica para suporte à gestão de recursos hídricos (ANA,
2006);
• A Comissão Nacional de Cartografia (CONCAR) propõe a estruturação dos dados
geográficos vetoriais da Mapoteca Digital Nacional (MDN) através de modelos
UML (CONCAR, 2007).
É importante salientar que ambas as iniciativas empregam, como modelo de dados
geográficos, o modelo OMT-G proposto por Borges (1997). Frozza (2007) afirma que não há
ferramenta específica para a criação de GML esquemas baseados no modelo OMT-G. Apesar
de a ferramenta proposta por esta dissertação não ser específica para o modelo OMT-G, mas
para modelos UML em geral, ela obviamente pode ser utilizada para esse fim, com pequenas
mudanças no modelo conceitual OMT-G4.
4 A descrição das mudanças necessárias no modelo conceitual se encontra no tópico 5.3.2 deste trabalho.
5
Dentro das opções de ferramentas de conversão de modelos UML para GML, na
realidade em que a dissertação foi elaborada, não há registro de plug-in Eclipse que viabilize
esse processo. Fora dessa categoria, existem as ferramentas5: UMT-QVT; UML/INTERLIS;
ShapeChange; FullMoon. Todas são ferramentas open source e baseadas na linguagem Java,
mas nenhuma utiliza a plataforma Eclipse.
Não foi encontrada nenhuma ferramenta comercial específica para a conversão de
modelos UML para GML. No entanto, no trabalho de Hess (2004), foi desenvolvido um
script (escrito na linguagem Visual Basic for Application - VBA) em formato addIn para a
ferramenta CASE (Computer-Aided Software Engineering) comercial IBM Rational Rose.
Deve-se considerar, porém, que esse script se encontra defasado, já que foi desenvolvido para
a versão GML 3.0, antes da publicação do Anexo E da ISO/DIS 19136 pela OGC (2007).
1.3 Objetivos
1.3.1 Objetivo geral
Desenvolver um plug-in para a plataforma Eclipse, integrada à ferramenta open source
Papyrus, que tenha a capacidade de modelar e converter modelos conceituais descritos em
linguagem UML para documentos GML esquema, seguindo as regras de conversão do Anexo
E da norma ISO/DIS 19136.
1.3.2 Objetivos específicos
• Aplicar métodos MDA (Model-Driven Architecture) que implementem as regras
de conversão de modelos UML para GML esquema descritas no anexo E da norma
ISO/DIS 19136;
• Elaborar um perfil UML que disponibilize classes GML básicas e estereótipos que
representem objetos geográficos básicos (linha, ponto e polígono) e integrá-lo ao
editor UML da ferramenta Papyrus;
• Integrar os métodos computacionais desenvolvidos a uma aplicação em formato de
plug-in para a plataforma Eclipse;
• Definir procedimentos para selecionar uma das categorias de modelos conceituais
propostos pela CONCAR (2007) como estudo de caso de aplicação do plug-in
proposto por esta dissertação;
5 Nota do autor: uma descrição das ferramentas está disponível no tópico 3.6.
6
• Desenvolver soluções ou protocolos de mapeamento para tratar não-conformidades
dos modelos conceituais propostos pela CONCAR (2007) que, por ventura,
possam interferir no processo de conversão em GML esquema;
• Gerar um GML esquema a partir de um modelo conceitual baseado em um estudo
de caso. Para tanto, devem ser usados um dos modelos conceituais propostos pela
CONCAR (2007), mais o plug-in desenvolvido por este trabalho;
• Produzir, a partir do GML esquema do estudo de caso e de dados reais, um
documento GML exemplo para demonstrar o uso potencial do plug-in Eclipse.
1.4 Metodologia e estrutura do trabalho
A metodologia adotada para a realização do presente trabalho, conforme visto na
Figura 1, está dividida em três grandes etapas: revisão bibliográfica, implementação e análise.
A etapa de revisão produz o conhecimento necessário para a etapa de implementação, a qual
gera resultados (dentre eles, a ferramenta proposta por esta dissertação) que passam para a
etapa de análise. Essa última etapa, por sua vez, produz as conclusões e as considerações
finais do trabalho. Em cima dessas três etapas, foram elaborados os capítulos da dissertação,
com exceção do presente capítulo, que traz: a introdução da dissertação; a definição dos
problemas e a justificativa para a realização do trabalho; objetivos gerais e específicos;
métodos e estrutura do trabalho.
Figura 1. Metodologia e estrutura da dissertação.
7
O Capítulo 2 apresenta uma revisão bibliográfica que aborda os modelos conceituais
para dados geográficos, primeiramente com uma introdução aos conceitos básicos sobre
modelagem de dados. Em seguida, é feito um pequeno histórico dos modelos de dados
geográficos e o paradigma (E-R, OO e IFO) aplicado pelas principais propostas de modelos
conceituais usados pela comunidade SIG. Neste capítulo, a única proposta de modelo
abordada é o modelo OMT-G (BORGES, 1997), já que é a proposta de modelo conceitual
utilizada pela CONCAR (2007) na Estruturação de Dados Geográficos e Vetoriais (EDGV)
para a Mapoteca Nacional Digital (MND).
O objetivo do Capítulo 2 em si não é fazer uma discussão aprofundada sobre o modelo
OMT-G, mas adquirir o conhecimento necessário para possibilitar o entendimento dos
modelos conceituais de dados geográficos propostos pela CONCAR (2007) e posterior
conversão dos modelos para GML esquema.
O Capítulo 3 é dedicado à descrição do processo de conversão de modelos conceituais
UML para GML esquema, seguindo as regras da norma ISO/DIS 19136 (OGC, 2007).
Inicialmente, é feita uma breve revisão sobre XML esquema e GML esquema, apresentando o
procedimento para criação de novos dados geográficos em um documento GML esquema. O
mecanismo de criação de dados geográficos é o que torna um documento GML esquema tão
versátil, já que põe, à disposição do desenvolvedor, classes básicas sobre as quais ele cria seus
dados geográficos de acordo com as necessidades de sua aplicação (HESS & IOCHPE, 2003).
Posteriormente, o Capítulo 3 passa a se concentrar na descrição das regras para
conversão de modelos UML para GML esquema. Os elementos UML (pacote, classes,
relacionamentos) têm regras específicas e padrões de mapeamento distintos. Por exemplo, o
mapeamento de classes depende do uso ou não de certos estereótipos6, pois há um padrão de
mapeamento que deve ser adotado para cada estereótipo. Para os relacionamentos, o
mapeamento deve levar em conta o tipo do relacionamento e a navegabilidade deste. Casos
omissos nas regras da OGC (2007), como o mapeamento de classes que representam
entidades geográficas7, tiveram sua solução baseada em abordagens citadas em literaturas do
assunto. O objetivo da revisão bibliográfica feita neste capítulo é dar subsídios para a próxima
etapa da dissertação, que é implementar métodos computacionais que apliquem as normas da
OGC (2007) na conversão de modelos UML para GML esquema.
6 <<FeatureType>>, <<DataType>>, <<DataType>>, <<Union>>, <<CodeList>> e <<Enumeration>>. 7 Recurso implementado através de estereótipos por alguns modelos de dados geográficos, como o modelo OMT-G.
8
O Capítulo 4 da dissertação descreve o procedimento de implementação do plug-in
proposto, doravante denominado UML2GML. O objetivo do capítulo é apresentar os
conceitos, tecnologias e procedimentos adotados para viabilizar a construção do plug-in
UML2GML. O capítulo inicia apresentando características do plug-in e sua arquitetura
interna, baseada em camadas, em que os conceitos MDA de transformação de modelos são
aplicados com a ajuda de diversas tecnologias, tais como a plataforma Eclipse8 e as
ferramentas do projeto Eclipse Modeling: GMF, EMF e JET. Cada tecnologia ou ferramenta é
discutida em tópicos específicos, em que são detalhados seu funcionamento e colaboração
dentro do projeto de construção do plug-in. Finalizando o capítulo, são apresentados os
procedimentos de uso do plug-in UML2GML e os procedimentos de teste e validação, que
foram feitos em cima do modelo conceitual exemplo proposto pela OGC (2007).
O Capítulo 5 apresenta os procedimentos adotados para desenvolver um estudo de
caso baseado em modelos conceituais propostos pela CONCAR. O capítulo inicia
apresentando o órgão federal responsável pela padronização dos dados geográficos
brasileiros, a CONCAR. Em seguida, é descrito o processo de criação da EDGV e seus
objetivos. A segunda parte do capítulo se concentra em descrever os procedimentos adotados
na dissertação para selecionar uma das categorias de modelos conceituais propostos pela
EDGV.
Após o processo de seleção do modelo conceitual mais adequado para o estudo de
caso, são discutidos os procedimentos adotados para lidar com as quatro não-conformidades
encontradas durante o processo de inserção do modelo editor UML da ferramenta Papyrus.
Caso essas não-conformidades não tivessem sido devidamente tratadas, o documento GML
esquema gerado pelo plug-in não seria válido.
O Capítulo 5 é finalizado apresentando o GML esquema gerado a partir do modelo
conceitual do estudo de caso. Como exemplo de possível produto final, é demonstrado um
documento GML com sua respectiva visualização gráfica, gerado a partir do GML esquema
do estudo de caso.
O Capítulo 6 é dedicado aos resultados da dissertação e sua discussão. São analisados
os resultados obtidos pela aplicação do estudo de caso proposto no capítulo anterior, e
também é feita uma síntese dos objetivos alcançados pela dissertação.
8 Camada mais interna da arquitetura do plug-in, responsável por encapsular todas as tecnologias utilizadas na construção da ferramenta.
9
O Capítulo 7 apresenta as considerações finais e as conclusões da dissertação, além de
apresentar propostas e recomendações para trabalhos futuros.
10
2 MODELOS CONCEITUAIS PARA DADOS GEOGRÁFICOS
Neste capítulo, é apresentada uma introdução sobre os conceitos de modelagem de
dados geográficos. Inicialmente, são expostas, de forma sucinta, noções básicas sobre
Sistemas de Informação Geográfica (SIG) e o seu principal componente, o Banco de Dados
Geográficos. Posteriormente, o foco passa a ser modelos conceituais para dados geográficos,
que podem ser classificados pelo formalismo que utilizam: modelos Entidade-
Relacionamento (E-R), modelos Orientados a Objetos (OO) e modelos IFO (Is-a
Relationships, Functional Relationships, Complex Object). Detalhes de cada formalismo são
apresentados em tópicos específicos deste capítulo.
Apesar de o paradigma OO possuir o maior número de propostas de modelos
conceituais para dados geográficos na literatura, no tópico que trata de modelos de dados OO,
uma única proposta de modelo é abordada: o OMT-G, proposto por Borges (1997). Essa
preferência se deve ao fato de que o estudo de caso aplicado no presente trabalho é um
modelo conceitual que faz parte das especificações técnicas para a EDGV da CONCAR
(2007), que utiliza o modelo OMT-G.
2.1 Noções básicas sobre SIGs
SIGs são sistemas que realizam o tratamento computacional de dados espaciais e que
se diferenciam dos sistemas de informação convencionais pela capacidade de armazenar
tantos os atributos descritivos, como geometrias de diferentes dados geográficos (CÂMARA,
2005). Como pode ser observado na Figura 2, os principais componentes da arquitetura de um
SIG são (LISBOA FILHO, 2001):
• Interface – componente do SIG com o nível mais próximo do usuário, define como
o sistema é operado e controlado;
• Entrada de dados – nível intermediário de um SIG e responsável pela obtenção de
dados através de diversos métodos, tais como meio óptico, digitalização de mapas
ou aquisição via meios magnéticos;
• Funções de processamento – componente que deve fornecer operações para
recuperação de informações com base em critérios de natureza espacial e não-
espacial, tais como operações topológicas, álgebra de mapa, modelagem numérica
de terreno e processamento de imagens;
11
Figura 2. Arquitetura de um SIG. Fonte: Lisboa Filho (2001).
• Visualização e plotagem - os mecanismos de visualização e plotagem devem
oferecer suporte adequado para a apreensão cognitiva dos aspectos relevantes dos
dados pesquisados pelo SIG;
• Banco de Dados Geográficos – nível mais externo de um SIG e responsável pelo
armazenamento e recuperação dos dados espaciais e seus atributos.
É obrigatória a presença de todos os componentes acima citados em um SIG. Porém,
em cada SIG, em função de seus objetivos e necessidades específicas, os componentes da
arquitetura são construídos de forma distinta.
2.2 Banco de Dados Geográficos
Um Banco de Dados Geográficos (BDG) tem, como principal função, estruturar e
armazenar dados de forma que possibilite a realização de operações de análises e consulta
(LISBOA FILHO & IOCHPE, 2001). O BDG pertence à categoria dos bancos de dados não-
convencionais e caracteriza-se não somente pelo armazenamento de dados, como também
pelo relacionamento destes com suas respectivas posições geográficas (CASTRO et al.,
2003). O processo de desenvolvimento de um banco de dados pode ser dividido em três
etapas, conforme detalhado na Figura 3:
12
Mundo Real
Projeto Conceitual
Projeto Lógico
Projeto Físico
Análise de Requisitos Requisitos do Banco de Dados
Esquema Conceitual (Modelo Conceitual)
Modelo Lógico (Modelo de Dados)
Esquema Físico (Modelo Implementação)
Independe de software
Dependente de Software
Figura 3. Fases de um projeto de banco de dados. Fonte: Lisboa Filho & Iochpe (2001).
• Etapa I (Projeto conceitual) – a partir de uma abstração do mundo real, é obtida
uma representação conveniente (modelo conceitual) que atenda à análise de
requisitos e finalidades do banco de dados, sendo que a utilização de modelos visa
a facilitar a comunicação e o entendimento entre usuários e projetistas;
• Etapa II (Projeto lógico) – tem o objetivo de definir, no nível do Sistema
Gerenciador de Banco de Dados (SGBD), as estruturas de dados que implementam
os requisitos da modelagem conceitual (HEUSER, 2004);
• Etapa III (Projeto físico) – são definidos os parâmetros físicos de acesso ao banco
de dados, procurando aperfeiçoar o desempenho do sistema como um todo.
Tempo de implementação, custo de produção e complexidade na modelagem dos
fenômenos reais são fatores críticos que devem ser considerados quando se opta pela
construção de um SIG. É no projeto de BDG que se concentra grande parte desses fatores
críticos, principalmente frente ao desafio da interoperabilidade e evolução para sistemas
baseados na Web.
2.3 Modelos de dados
Davis Jr. (1998) define um modelo conceitual como um conjunto de conceitos usados
para descrever as estruturas e as operações em um banco de dados. Em um modelo, procura-
se sistematizar o entendimento que as pessoas têm a respeito de objetos e fenômenos do
13
mundo real, visando representá-los em um sistema informatizado. Como objetos e fenômenos
reais são complexos demais para uma representação completa diante dos recursos à
disposição dos SGBD’s atuais, torna-se necessário construir uma abstração dos objetos, de
modo a obter uma representação conveniente, embora simplificada, que seja adequada à
finalidade das aplicações de banco de dados (BORGES, 1997).
Conforme pode ser visto na Figura 4, o processo de modelagem compreende a
descrição dos possíveis conteúdos de dados, além de estruturas e regras a ele aplicáveis
(LISBOA FILHO & IOCHPE, 2001). Utilizando-se sempre algum formalismo conceitual
(modelo E-R ou OO), obtém-se, como resultado, o esquema conceitual. Um formalismo
conceitual é um conjunto de conceitos, elementos e regras que são usados no processo de
modelagem da realidade. O produto final do processo de modelagem, o esquema conceitual, é
sempre apresentado em linguagem formal, expressa através de uma sintaxe e/ou notação
gráfica.
Modelos de dados podem ser classificados em três tipos (BORGES & FONSECA,
1996):
• Modelos de dados clássicos – descrevem a estrutura de um banco de dados em um
nível de abstração mais próximo da estrutura física do armazenamento de dados.
Caracterizam-se por sua inflexibilidade, que exige a adequação da realidade à
estrutura proposta pelo modelo. Exemplos de modelos de dados clássicos são:
modelo relacional, modelo em rede e modelo hierárquico;
Formalismo Conceitual
Processo
de
Modelagem
Esquema
Conceitual
Técnicas Formais de Descrição
Linguagem Léxica
Notação Gráfica
Realidade
Figura 4. Processo de modelagem conceitual. Fonte: Lisboa Filho & Iochpe (1999).
14
• Modelos de dados semânticos – utilizados para capturar a semântica dos dados e,
conseqüentemente, modelar e especificar propriedades reais e imaginadas. Os
modelos de dados semânticos se caracterizam por descreverem a estrutura de
banco de dados em um nível de abstração independente dos aspectos da
implementação. O modelo E-R de Chen e o modelo OO são exemplos de modelos
de dados semânticos;
• Modelos de dados físicos – descrevem as estruturas físicas de armazenamento de
dados.
Diante das características únicas da representação de dados para um BDG, a
modelagem de dados é definida como o processo de abstração em que os elementos essenciais
da realidade são enfatizados, sendo descartados os elementos não-essenciais. Um modelo de
dados fornece uma base formal (notacional e semântica) para as ferramentas e técnicas usadas
para suportar a modelagem de dados (LISBOA FILHO & IOCHPE, 2001; LISBOA FILHO,
2001).
Borges (1997) relaciona um conjunto de requisitos necessários para um modelo de
dados voltado especificamente para aplicações geográficas:
• Fornecer um alto nível de abstração;
• Representar e diferenciar os diversos tipos de dados envolvidos nas aplicações
geográficas, tais como ponto, linha, área, imagem, dentre outros;
• Representar tanto as relações geoespaciais e suas propriedades, como também
associações simples de rede;
• Ser capaz de especificar regras de integridade geoespacial;
• Ser independente da implementação;
• Suportar classes georreferenciadas e classes convencionais, assim como os
relacionamentos entre elas;
• Ser adequado aos conceitos natos que o ser humano tem sobre os dados
geoespaciais, representando as visões de campo e de objeto;
• Utilizar conceitos de níveis de informação, possibilitando que uma entidade
geográfica seja associada a diversos níveis de informação;
• Representar múltiplas visões e séries temporais, assim como os relacionamentos
temporais.
15
2.4 Modelos conceituais de dados geográficos
Conforme visto na Figura 5, os modelos conceituais têm sido adaptados para atender
às necessidades impostas por SIGs desde início da década de 90 (LISBOA FILHO &
IOCHPE, 1999). Nota-se que todos os modelos propostos são baseados em algum
formalismo, tais como o modelo E-R, OO e o formalismo IFO.
2.4.1 Modelo E-R
O modelo E-R foi introduzido por Chen em 1976, sendo a abordagem semântica mais
conhecida e certamente uma das mais usadas (DATE, 2000). O modelo E-R utiliza três
termos (Figura 6): entidade, relacionamentos e atributos.
Uma entidade é uma representação abstrata de um objeto do mundo real que possui
uma existência independente e que deseja guardar e recuperar informações sobre esse objeto
(BORGES, 1997). Entidades podem ser classificadas em regulares e fracas. Uma entidade
fraca depende da existência de alguma outra entidade, no sentido de que ela não pode existir,
se essa outra entidade não existir. Uma entidade regular, por sua vez, não depende da
existência de outra (DATE, 2000).
Figura 5. Evolução histórica dos modelos conceituais para dados geográficos. Fonte: Lisboa Filho & Iochpe (2001).
16
Figura 6. Construtores básicos do modelo E-R. Fonte: Borges (1997).
No modelo E-R, um relacionamento é uma associação entre duas ou mais entidades
(BORGES & FONSECA, 1996). Um relacionamento, quanto à cardinalidade, pode ser: um
para um, de um para muitos, ou de muitos para muitos (também conhecido como de muitos
para um). Já os atributos são propriedades usadas para descrever uma entidade ou um
relacionamento.
Sendo o modelo semântico mais antigo, torna-se óbvio que as primeiras tentativas para
a adaptação dos requisitos de SIG foram feitas neste modelo. Bédard e Paquete, em 1989,
foram responsáveis pelo pioneirismo na utilização do modelo E-R para modelar BDG.
Posteriormente, o modelo E-R deu origem à extensão denominada Modul-R, que serviu de
base para vários modelos e ferramentas CASE subseqüentes, tais como Perceptory, que
emprega o formalismo OO com a sintaxe da linguagem UML (LISBOA FILHO & IOCHPE,
2001). Outros modelos que empregam o formalismo E-R que podem ser citados são: GISER
(Geographic Information System Entity Relational), USM (Unifying Semantic Model) e Geo-
ER.
2.4.2 Modelo IFO
O modelo IFO (Is-a Relationships, Functional Relationships, Complex Object) é um
modelo altamente estruturado que utiliza atributos e tipos construtores para agregação e
agrupamento (BORGES; DAVIS JR.; LAENDER, 2005). Os tipos construtores básicos do
modelo IFO são: objetos, fragmentos e relacionamentos “é uma” (“is a”). Os três tipos
básicos de objetos são (Figura 7):
• Imprimível – objeto que pode ser diretamente representado como entrada e saída;
• Abstrato – objeto físico ou conceitual que não seja imprimível;
• Livres – funcionam como links nos relacionamentos de generalização e
especialização.
17
Figura 7. Notação gráfica do modelo IFO. Fonte: Borges; Davis Jr.; Laender (2005).
O relacionamento entre os tipos é representado pelo fragmento. Um fragmento contém
os tipos e as funções (mas não relacionamentos de generalização e/ou especialização) sujeitos
a certas regras (BORGES & FONSECA, 1996). Fragmentos são usados para modelar
associações “um para um” entre dois objetos. Já associações do tipo “um para muitos” são
modeladas indiretamente, usando fragmentos e agrupamento.
O modelo IFO possui um alto nível de abstração, mas não é suficientemente claro.
Além disso, ele não representa todas as propriedades geométricas dos objetos geográficos
(TIMES, 1994 apud BORGES & FONSECA, 1996). Existem somente dois modelos de dados
geográficos que utilizam o formalismo do modelo IFO: GeoIFO e Milne (LISBOA FILHO &
IOCHPE, 2001).
2.4.3 Modelo OO
Em um modelo OO, todas as entidades são abstraídas como objetos, que possuem uma
identidade que o distingue pela sua própria existência, e não pelas propriedades descritivas
que ele possa ter (BORGES; DAVIS JR.; LAENDER, 2005). Cada objeto pertence a uma
classe, que é a descrição de um conjunto de objetos que compartilham os mesmos atributos,
operações, relacionamentos e semântica. A notação gráfica do modelo OO pode ser vista na
Figura 8.
Classes de objetos são, com freqüência, definidas hierarquicamente e fazem uso de um
conceito mais importante em OO: herança. Herança é um mecanismo de compartilhamento de
características, utilizando o relacionamento de generalização (BORGES & FONSECA, 1996).
18
Figura 8. Notação gráfica do modelo OO. Fonte: Borges; Davis Jr.; Laender (2005).
Uma generalização é um relacionamento entre classes que produz uma hierarquia:
uma ou mais classes generalizam-se em uma classe de nível mais alto, sendo que as classes de
nível mais baixo são chamadas de subclasses, e a classe de nível mais alto é denominada
superclasse (BOOCH; RUMBAUGH; JACOBSON, 2006).
Como modelos de dados geográficos que utilizam o formalismo OO, podem ser
citados: GMOD (SALLES et al., 1998), Perceptory (BÉDARD, 1999), OMT-G (BORGES,
1997), MADS (PARENT, 1998), UML-Geoframe (LISBOA FILHO, 2001), e Geo-OM
(TRYFONA; PFOSER; HADZILACOS, 1997).
2.4.3.1 Modelo OMT-G
O modelo OMT-G é baseado em primitivas definidas para o diagrama de classes da
UML (Unified Modeling Language) e possui primitivas geográficas, com o objetivo de
aumentar a capacidade de representação de semântica do modelo OO para BDG’s. O modelo
é baseado em três conceitos principais: classe, relacionamento e restrições de integridade
espaciais. As classes, no modelo OMT-G, estão divididas em dois tipos, com suas respectivas
representações gráficas, conforme a Figura 9 (BORGES; DAVIS JR.; LAENDER, 2005):
19
Figura 9. Notação gráfica para as classes do modelo OMT-G. Fonte: adaptado de Borges; Davis Jr.; Laender (2005).
• Georreferenciada – descreve um conjunto de objetos que possuem representação
geoespacial e estão associadas a regiões da superfície da terra. A representação
gráfica, no modelo OMT-G, inclui um retângulo, utilizado para indicar a forma
geométrica da representação (Figura 9a). Exemplos: relevo e solo de uma
determinada região;
• Convencional - descreve um conjunto de objetos com propriedades,
comportamento, relacionamento e semânticas semelhantes e que têm alguma
relação com os objetos geoespaciais, mas não possuem propriedades geométricas.
A representação gráfica das classes convencionais é a mesma utilizada na UML
(Figura 9b). Um exemplo desse tipo de classe é a que define os proprietários de
imóveis cadastrados para fins de tributação (IPTU9) que possuem relação de
propriedade com lotes e edificações.
Com a utilização desses dois tipos de classes, é possível modelar os fenômenos
encontrados em aplicações de SIG: os de variação contínua no espaço, os de variação discreta
e os não-espaciais. Por convenção, os fenômenos de variação contínua são denominados geo-
campos, e os fenômenos com variação discreta são chamados de geo-objetos (DAVIS JR.,
1998).
9 Imposto sobre a Propriedade Predial e Territorial Urbana.
20
2.4.3.1.1 Representação gráfica de geo-campos e geo-objetos
No canto esquerdo das classes georreferenciadas, são utilizados pictogramas que
representam a natureza geométrica do dado. No modelo OMT-G, são definidas cinco classes
descendentes de geo-campos: isolinhas, subdivisão planar, tesselação planar, amostragem e
malha triangular (Triangulated Irregular Network - TIN). Representações gráficas das cinco
classes, com os respectivos exemplos de geo-campos, podem ser vistas na Figura 10
(BORGES; DAVIS JR.; LAENDER, 2005).
No caso dos geo-objetos, há duas classes: geo-objetos com geometria e geo-objetos
com geometria e topologia. A classe geo-objeto com geometria representa objetos que
possuem propriedades geométricas que podem ser especializadas em: ponto, linha e polígono
(exemplos e representações gráficas podem ser vistos na Figura 11a). Por sua vez, a classe
geo-objeto com geometria e topologia representa objetos que possuem, além de propriedades
geométricas, propriedades topológicas voltadas especificamente para a representação de
estruturas em redes, como redes de água e esgoto (BORGES; DAVIS JR.; LAENDER, 2005).
A notação utilizada deve ser nó, linha direcionada e linha bi-direcionada (Figura 11b). Os
segmentos orientados traduzem o sentido do fluxo da rede (unidirecional ou bidirecional),
dando mais semântica à representação.
Figura 10. Exemplos de representação de geo-campos no modelo OMT-G. Fonte: Borges; Davis Jr.; Laender (2005).
21
Figura 11. Representação de geo-objetos no modelo OMT-G. Fonte: Borges; Davis Jr.; Laender (2005).
2.4.3.1.2 Relacionamentos
O modelo OMT-G apresenta os seguintes tipos de relacionamentos (BORGES, 1997;
DAVIS JR., 1998; BORGES; DAVIS JR.; LAENDER, 2005):
• Associações simples – representam relacionamentos estruturais entre objetos de
diferentes classes, tanto as convencionais, quanto as georreferenciadas. A instância
individual de uma associação é denominada link, sendo que uma associação pode
ter, sobre o seu nome, uma seta indicando o sentido da relação (Figura 12a);
• Relacionamento geoespacial – representam relações topológicas, métricas, ordinais
e difusas. Algumas relações podem ser calculadas a partir de coordenadas de cada
objeto durante a execução das operações de análise geoespacial. Relações
topológicas são exemplos deste caso (Figura 12b);
Figura 12. Relacionamentos do modelo OMT-G. Fonte: Borges; Davis Jr.; Laender (2005).
22
• Hierarquia geoespacial – caso particular, em que uma relação de dependência entre
classes é definida por critérios geoespaciais. Um exemplo deste tipo de
relacionamento pode ser um polígono que contenha todo o espaço modelado com
um ou mais geo-objetos. No mesmo caso, uma hierarquia geoespacial pode ser
utilizada para relacionar geo-campos com geo-objetos (Figura 12c);
• Relacionamento em rede – relacionamento entre objetos que estão conectados uns
com os outros. Relacionamentos de redes são indicados por duas linhas
pontilhadas paralelas, entre as quais o nome do relacionamento é anotado (Figura
12d). São, em geral, especificados entre classe de nós e uma classe de arcos.
Entretanto, estruturas de rede sem nó podem ser definidas, especificando um
relacionamento recursivo sobre uma classe de arcos (Figura 12e).
A cardinalidade dos relacionamentos representa o número de instâncias de uma classe
que podem estar associadas à instância de outra classe (BORGES; DAVIS JR.; LAENDER,
2005). No modelo OMT-G, é adotada a mesma notação gráfica usada na UML (Figura 13).
2.4.4 Comparação entre os formalismos E-R, IFO e OO
Um método de avaliação dos três tipos de formalismos para modelos de dados
geográficos foi proposta por Hadzilacos & Tryfona (1998). Para isso, definiram os seguintes
critérios de avaliação:
• Expressividade – quanto mais expressivo for um modelo, mais próxima da
realidade é sua descrição;
• Poder de abstração - um dos critérios para avaliar a semântica de um modelo é a
capacidade de representar a realidade através da abstração. Ser capaz de
compreender e atribuir estrutura a objeto possibilita a aproximação do mesmo em
relação à semântica do modelo;
Figura 13. Cardinalidade. Fonte: Borges; Davis Jr.; Laender (2005).
23
• Complexidade - essa parece ser uma das questões mais cruciais na seleção de um
modelo de banco de dados. Há uma relação de equilíbrio usual entre a
expressividade e a complexidade. Quanto mais expressivo for um modelo, mais
complexo ele aparenta ser;
• Facilidade de compreensão – a característica de facilidade de compreensão e
adaptação/utilização do modelo está relacionada à sua complexidade. Modelos
com facilidade de compreensão possibilitam integrar o usuário e o desenvolvedor
durante a etapa de modelagem de um sistema, uma vez que é o usuário quem
possui o conhecimento do domínio do sistema, e é o desenvolvedor quem traduz
esse conhecimento para o modelo conceitual da aplicação. Modelos que possam
ser facilmente compreendidos são críticos nesse processo;
• Extensibilidade – com o surgimento de novas técnicas, padrões e abordagens para
SIGs, modelos conceituais devem ter a capacidade de se estender para agregá-los.
Além disso, a extensibilidade possibilita que conhecimentos obtidos de técnicas
clássicas sejam atualizados com os avanços da área.
Aplicando os critérios acima definidos, Hadzilacos & Tryfona (1998) obtiveram os
seguintes resultados (resumidos no Quadro I):
• O formalismo E-R pode ser facilmente estendido; contudo, possui pouca
expressividade semântica para dados geoespaciais. Em alguns casos, modelos E-R
aparentam ser demasiado simples, sem apresentar soluções elegantes. É um
formalismo facilmente compreendido pelos usuários;
• O formalismo IFO pode ser facilmente estendido, além de produzir modelos
complexos, porém compreensíveis, para os usuários. Possui mecanismos
sofisticados e semanticamente ricos para representar dados geoespaciais;
Quadro I. Comparação entre os formalismos para modelos conceituais de dados geográficos. Fonte: Hadzilacos & Tryfona (1998).
Expressividade Complexidade Facilidade de compreensão Extensibilidade
E-R Baixo Baixo Alto Alto IFO Médio Médio Médio Alto OO Alto Médio Médio Alto
24
• O formalismo OO oferece alto nível de expressividade, é mais compreensível do
que o IFO e pode ser facilmente estendido. O resultado é semanticamente rico o
suficiente para representar espaço. A capacidade de capturar propriedades
dinâmicas de objetos geográficos é uma das suas principais vantagens. No caso do
formalismo OO, o modelo utilizado para comparação foi o OMT (existem
inúmeros modelos de dados OO, tais como o modelo UML, OMT-G, etc.).
2.5 Considerações finais
Apesar de existirem muitas propostas de modelos conceituais para dados geográficos,
sejam modelos E-R, modelos OO ou modelos IFO, não há consenso, dentro da comunidade
SIG, sobre qual seria o mais adequado para a representação de estruturas de dados
geográficos. Cada proposta de modelo conceitual tem ênfase em algum domínio específico da
modelagem conceitual de dados, como, por exemplo, o aspecto temporal dos dados
geográficos, atendendo a necessidade específica de cada segmento da comunidade SIG.
Dentro da comunidade SIG brasileira, o modelo conceitual de dados geográfico mais popular
é modelo OMT-G, sendo inclusive o modelo utilizado na estruturação da Mapoteca Nacional
Digital (MND) (CONCAR, 2007).
25
3 CONVERSÃO DE MODELOS UML PARA GML ESQUEMA
O presente capítulo apresenta a técnica de conversão de documentos UML (Unified
Modeling Language) para GML (Geographic Markup Language) esquema. Um GML
esquema é uma gramática XML (eXtensible Markup Language) utilizada na descrição de
esquemas de aplicação (application schema), bem como na produção de documentos GML,
usados no transporte e armazenamento de informação geográfica (OGC, 2007).
A primeira parte do capítulo se concentra na definição de documentos XML esquema
e sua relação com o GML esquema. É demonstrado, através de um exemplo, como se utiliza a
linguagem XML esquema para construir um documento GML esquema com um novo tipo de
dado.
A segunda parte do capítulo foca o processo de decodificação de modelos conceituais
UML para GML esquema. São descritas as regras da norma ISO/DIS 19136 (OGC, 2007),
que definem o processo de transformação de elementos UML (pacotes, classes, atributos de
classes e relacionamentos) para elementos GML esquema.
A última parte do capítulo apresenta algumas ferramentas disponíveis para conversão
de modelos UML para GML esquema. Também é apresentada uma listagem sucinta de GML
esquemas para aplicações de comunidades de áreas de conhecimento diversas (aeronáutica,
geologia, biologia, dentre outras), todas disponíveis para acesso público.
3.1 Noções básicas sobre XML esquema e GML esquema
XML é um padrão W3C10 (World Wide Web Consortium) para representação de
dados, sendo o método padrão para troca de dados através da Internet. Para que essa troca de
dados seja bem-sucedida, a estrutura do documento XML deve ser validada através de regras
definidas em uma linguagem denominada XML esquema (XML schema) (GUNAWAN,
2004; TESCH JR., 2002).
Estruturalmente, um XML esquema é formado por blocos denominados componentes
do esquema, que consistem em doze componentes classificados em três categorias, conforme
visualizado na Figura 14 (TESCH JR., 2002):
10 http://www.w3.org/
26
Figura 14. Estrutura de componentes de um XML esquema. Fonte: Tesch Jr. (2002).
• Componentes primários – formados por definições de tipos simples ou complexos,
declarações de elementos e atributos;
• Componentes secundários – formados por attribute group, identity-constraint e
definition model-group;
• Componente helper – formado por annotations, model-group, particles e
wildcards.
Um documento GML, por sua vez, é um padrão de documento XML proposto pela
Open Geospatial Consortium (OGC) para transporte e armazenamento de informações
geográficas, incluindo suas informações geoespaciais e atributos (OGC, 2007). A estrutura do
documento GML está baseada na sintaxe do XML esquema com suporte a XML namespaces;
dessa forma, é possível definir os elementos (tags) que descreverão os dados. Um GML
esquema, portanto, pode ser definido como um documento que descreve a estrutura de dados
(geoespaciais e atributos) de um documento GML.
As especificações do GML esquema incluem XML esquemas que contêm modelos de
geometrias, feições e superfícies. Assim, de posse desses esquemas, pode-se definir um
esquema próprio para uma aplicação. Porém, é necessário atender a algumas exigências, para
obter a conformidade do GML esquema (CÂMARA, 2005):
• Os tipos desenvolvidos devem ser obrigatoriamente subtipos do GML:
“gml:AbstractFeatureType” ou “gml:AbstractFeatureCollectionType” para feições
e “gml:AbstractGeometryType” ou “gml:GeometryCollectionType” para a
geometria;
27
• Um esquema de aplicação GML não pode mudar o nome, definição ou tipo de
dados dos elementos obrigatórios do GML;
• Definições de tipos abstratos podem ser livremente estendidas ou restritas;
• O esquema de aplicação deve estar disponível a qualquer um que receba o dado
estruturado por aquele esquema;
• Os esquemas não podem utilizar o namespace “http://www.opengis.net/gml”.
Na Figura 15, pode ser visto o exemplo de um GML esquema com a criação de um
novo tipo - no caso, “hidrografia”. Na linha nove, pode-se observar a definição de um novo
tipo, que é um subtipo de “gml:AbstractFeatureType”. Na linha dezesseis, é criado um novo
elemento (tag) denominado “rio”, que utiliza o novo tipo “hidrografia”. Também é definido
que o novo elemento tenha o atributo “substitutionGroup” com o valor “gml:
AbstractFeatureType”, o que garante, a uma aplicação, a leitura dos dados (CÂMARA,
2005). O sufixo “ex” indica que o tipo “ex:hidrografia” pertence ao domínio do namespace
“ex”, declarado no cabeçalho do esquema.
3.2 Gerando GML esquemas a partir de modelos UML
A forma mais prática de produzir um esquema de aplicação é através de um modelo
conceitual da aplicação. O suporte de um modelo conceitual possibilita um bom entendimento
do domínio da aplicação, e a UML pode ser utilizada com esse propósito (GUNAWAN,
2004).
A norma ISO/DIS 19136 (OGC, 2007) define um grupo de regras de decodificação de
modelos UML para GML esquema. Dependendo do elemento UML a ser decodificado,
algumas dessas regras são triviais, e outras, não. No Quadro II, pode ser visto um resumo do
processo de decodificação de elementos UML para elementos GML esquema. Nos tópicos
subseqüentes, são apresentadas as características de cada regra em relação ao mapeamento
dos elementos UML.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
<?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://www.myorg.com/exemples" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gml="http://www.opengis.net/gml" elementFormDefault="qualified" version="1.0"> <complexType name="hidrografia"> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence> <element ref="gml:centerLineOf"/> </sequence> </extension> </complexContent> </complexType> <element name="rio" type="ex:hidrografia" substitutionGroup=" gml:AbstractFeatureType"/> </schema>
Figura 15. Exemplo de mapeamento de informações de um pacote UML. Fonte: Câmara (2005).
28
Quadro II. Resumo do mapeamento de conceitos UML para elementos GML esquema. Fonte: OGC (2007).
Conceito UML GML Esquema
Classe com estereótipos
Elemento global <complexType> com regras específicas para cada estereótipo. Os estereótipos aceitos são: FeatureType, Type, DataType,
Union, CodeList e Enumeration. Outros estereótipos são ignorados.
Classe sem estereótipos Elemento global <complexType> com regras semelhantes ao estereótipo Type.
Atributos Elemento local <element> com o atributo “type” definido por normas da série ISO 19100.
Relacionamentos Elemento local <complexType>.
Herança Derivação do elemento global <complexType> por extensão (elemento <extension>).
Pacotes Namespace. Cardinalidades Atributos locais “maxOccurs” e “minOccurs”.
3.2.1 Pacotes
Um pacote (package) contém todos os elementos UML que serão mapeados em um
documento GML esquema. Usualmente, em um mapeamento de UML para GML esquema,
cada pacote só pode estar associado a um documento GML esquema. Relacionamentos entre
pacotes são mapeados através da utilização do recurso de XML namespaces.
O componente namespaces tem, como objetivo, determinar o escopo para os
elementos declarados no documento XML esquema, ou seja, namespaces especificam o
contexto para os tipos de elementos e nomes dos atributos usados nos documentos XML
esquema (TESCH JR., 2002).
Para cada pacote UML a ser mapeado, é criado um documento esquema denominado
“nome_do_pacote.xsd”, que segue um padrão de estrutura descrito pela Figura 16. Nesse
padrão, o elemento <schema> possui algumas propriedades (“targetNamespace”, “version”,
“xmlns”, “elementFormDefault”), que são assim definidas:
1 2 3 4 5 6 7 8 9 10 11 12
<?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://www.myorg.com/parcels" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gml="http://www.opengis.net/gml" xmlns:gp="http://www.myorg.com/geodeticPoints" elementFormDefault="qualified" version="1.0"> <include schemaLocation="Building.xsd"/> <import namespace="http://www.myorg.com/geodeticPoints" schemaLocation="GeodeticPoints.xsd"/> <import namespace="http://www.opengis.net/gml/3.2" schemaLocation="base/gml.xsd"/> <!--...--> </schema>
Figura 16. Padrão de mapeamento de informações de pacote. Fonte: OGC (2007).
29
• As propriedades “targetNamespace” e “version” são alteradas de acordo com os
valores rotulados no pacote UML - no caso, nome e versão do pacote. O atributo
“targetNamespace” é utilizado para definir o namespace que está sendo descrito
no XML esquema. O atributo “version” indica a versão do XML esquema; se o
valor rotulado “version” não for especificado na UML, o valor “unknown” é
utilizado;
• A propriedade “xmlns” é utilizada para definir um namespace default para o
esquema. Ao se utilizar um namespace default, os elementos do esquema não
precisam usar um prefixo de namespace quando declarados. O atributo “xmlns”
com o valor “http://www.w3.org/2001/XMLSchema” indica que o elemento utiliza
tipo de dados esquema (schema, element, complexType, sequence, string, boolean
e assim por diante). O recurso de prefixos possibilita o emprego de vários
namespaces em um documento esquema. O uso desse tipo de recurso pode ser
observado nos atributos “xmlns:xlink”, “xmlns:gml” e “xmlns:gp”;
• A propriedade “elementFormDefault” pode assumir o valor “qualified” ou
“unqualified”. Esse atributo é utilizado para indicar quando os valores dos
elementos são limitados (qualificados) por um namespace default.
O mapeamento de relações de dependências entre pacotes exige a utilizacão de
recursos de “import” e “include” no documento. Ambos possibilitam o uso de um outro
documento XML esquema dentro do esquema. Utiliza-se o elemento <include> quando o
documento XML esquema referencia um outro documento XML esquema com o mesmo
namespace. Entretanto, se o documento XML esquema referencia um outro documento de um
namespace diferente, utiliza-se o elemento <import>. A Figura 17 exemplifica o uso dos
elementos <include> e <import> em um documento GML esquema.
Figura 17. Exemplificação da utilização do recurso dos elementos <include> e <import> em um GML esquema.
Fonte: Galdos (2003).
30
3.2.2 Classes – Regras gerais
A OGC (2007) define algumas regras gerais para a conversão de classes UML para
elementos de um documento GML esquema:
• Os seguintes estereótipos de classes UML são reconhecidos: <<FeatureType>>,
<<Type>>, <<DataType>>, <<Union>>, <<Codelist>> e <<Enumeration>>.
Todas as classes com outros estereótipos são ignoradas na conversão de UML para
GML esquema. Classes sem estereótipos seguem a regra de conversão para classes
com estereótipos <<Type>>;
• Cada classe é convertida para elemento, cujo atributo name é o próprio nome da
classe, e o tipo é definido como sendo a concatenação do nome da classe com o
sufixo “Type”;
• As operações de classe UML são ignoradas na conversão;
• Todas as classes podem ter de zero a um (1) supertipo; portanto, o recurso de
herança múltipla é ignorado.
3.2.2.1 Classes – Tipos básicos
A regra de conversão dos tipos básicos transforma componentes de uma linguagem
(no caso, UML) para um componente correspondente de outra linguagem (GML esquema).
Portanto, as regras de conversão UML – GML esquema devem suportar tanto elementos
gerais da UML, quanto elementos específicos da série ISO 19100. A Figura 18 ilustra uma
conversão trivial dos elementos UML: classe, atributos e tipo do atributo. A classe “Estrada”
é convertida para um XML esquema correspondente <complexType>. O tipo do atributo é
convertido conforme o Quadro III11 em tipos ISO específicos.
Quadro III. Parte superior: tipos ISO básicos convertidos para tipos XML esquema. Parte inferior: tipos espaciais convertidos para GML. Fonte: Grønmo; Solheim; Skogan (2002).
Tipos básicos de acordo com a ISO 19103 Tipos básicos XML esquema
CharacterString string Integer integer Date date Boolean boolean Real Decimal
Tipos espaciais de acordo com a ISO 19107 Tipos básicos XML esquema
GM_Point PointPropertyType GM_Curve LineStringPropertyType GM_CompositeSurface PolygonPropertyType
11 Nota do autor: a versão completa se encontra no Anexo I deste trabalho.
31
1 2 3 4 5 6 7 8 9 10 11
<complexType name="EstradaType"> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence> <element name="classificao" type="string"/> <element name="numero" type="string"/> <element name="linearGeometry" type="gml:LineStringPropertyType"/> </sequence> </extension> </complexContent> </complexType>
Figura 18. Exemplo trivial do mapeamento de uma classe UML para um GML esquema “Estrada”. Fonte: OGC (2007).
3.2.2.2 Classes – DataType
As classes com o estereótipo <<DataType>> seguem as seguintes regras em seu
mapeamento para GML (exemplo de mapeamento na Figura 19):
• Se a classe não tem um supertipo, ela deve ser de um tipo não derivado de dentro
do XML esquema. Se a classe utiliza um supertipo, este não pode ser derivado de
“gml:AbstractObject” (direta ou indiretamente);
• O elemento mapeado deve ter os seguintes atributos configurados: “name” (nome
da classe), “type” (nome da classe mais o sufixo Type), “abstractness” (valor
“true”, se a classe for abstrata) e “substitutiongroup” (nome da superclasse ou
“gml:AbstractObject”, se a classe não for uma superclasse);
• Um elemento <complexType> deve ser criado para essa classe (o atributo “name”
deve ter o valor alterado para o nome da classe, acrescentado do sufixo
PropertyType). Essa regra só se aplica, caso o atributo “noPropertyType” da
classe, no modelo UML original, esteja com o valor diferente de “true”.
1 2 3 4 5 6
<complexType name="ParcelNameType"> <sequence> <element name="street" type="string" minOccurs="0" maxOccurs="1"/> <element name="city" type="string" minOccurs="1" maxOccurs="1"/> </sequence> </complexType>
Figura 19. Exemplo do mapeamento de uma classe UML com o estereótipo <<DataType>>. Fonte: adaptado de OGC (2007).
32
3.2.2.3 Classes – FeatureType
As classes com o estereótipo <<FeatureType>> seguem as seguintes regras em seu
mapeamento para GML (exemplo de mapeamento na Figura 20):
• As classes devem ser derivadas direta ou indiretamente de
“gml:AbstractFeatureType”. Se a classe não tem um supertipo, ela deve estender
diretamente de “gml:AbstractFeatureType”. No entanto, se a classe é estendida de
um supertipo, este deve ser derivado de “gml:AbstractFeatureType” (direta ou
indiretamente);
• O elemento mapeado deve ter os seguintes atributos configurados: “name” (nome
da classe), “type” (nome da classe mais o sufixo Type), “abstractness” (valor
“true”, se a classe for abstrata) e “substitutiongroup” (nome da superclasse ou
gml:AbstractFeature);
• Um elemento <complexType> deve ser criado para essa classe (o atributo “name”
deve ter o valor alterado para o nome da classe, acrescentado do sufixo
PropertyType). Essa regra só se aplica, caso o atributo “noPropertyType” da
classe, no modelo UML original, esteja com o valor diferente de “true”.
• Um elemento <complexType> deve ser criado para essa classe (o atributo “name”
deve ter o valor alterado para o nome da classe, acrescentado do sufixo
“PropertyByValueType”). Essa regra só se aplica, caso o atributo
“byValuePropertyType” da classe, no modelo UML original, esteja com o valor
“true”.
33
1 2 3 4 5 6 7 8 9 10 11 12 13
<complexType name="BuildingType"> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence> <element name="extent" type="gml:SurfacePropertyType"/> <element name="address" type="pcl:AddressPropertyType"/> <element name="type" type="pcl:BuildingTypeType"/> </sequence> </extension> </complexContent> </complexType> <element name="Building" type="pcl:BuildingType" substitutionGroup="gml:AbstractFeature"/>
Figura 20. Exemplo do mapeamento de uma classe UML com o estereótipo <<FeatureType>>. Fonte: OGC (2007).
3.2.2.4 Classes – Type
As classes sem estereótipo ou com o estereótipo <<Type>> seguem as seguintes
regras em seu mapeamento para GML (exemplo de mapeamento na Figura 21):
• Classes com o estereótipo <<Type>> devem ser derivadas direta ou indiretamente
de “gml:AbstractGMLType”. Se a classe não tem um supertipo, ela deve estender
diretamente de “gml:AbstractGMLType”. Porém, se a classe é estendida de um
supertipo, este deve ser derivado de “gml:AbstractGMLType” (novamente direta
ou indiretamente). Neste caso, a classe não pode ser estendida de
“gml:AbstractFeatureType”, seja direta ou indiretamente;
• Um elemento <complexType> deve ser criado para essa classe (o atributo “name”
deve ter o valor alterado para o nome da classe, acrescentado do sufixo
“PropertyType”). Essa regra só se aplica, caso o atributo “noPropertyType” da
classe, no modelo UML original, esteja com o valor diferente de “true”.
<<FeatureType>>Bulding
+extent: GM_Surface+adress: Adress+type: BuldingType
34
Elipse
+center: DirectPosition
+semiminor: Vector
+semimajor: Vector
<<Abstract>>
GM_CurveSegment
1 2 3 4 5 6 7 8 9 10 11 12 13
<element name="Ellipse" type="ex:EllipseType" substitutionGroup="gml:AbstractCurveSegment"/> <complexType name="EllipseType"> <complexContent> <extension base="gml:AbstractCurveSegmentType"> <sequence> <element name="center" type="gml:DirectPositionType"/> <element name="semiminor" type="gml:VectorType"/> <element name="semimajor" type="gml:VectorType"/> </sequence> </extension> </complexContent> </complexType>
Figura 21. Exemplo do mapeamento de uma classe UML com estereótipo <<Type>> ou sem estereótipo. Fonte: OGC (2007).
3.2.2.5 Classes – Enumerations
As classes com o estereótipo <<Enumeration>> são mapeadas como <simpleType> no
XML esquema. O atributo “base” é do tipo “string”, sendo que o domínio dos valores é
restringido por um conjunto de valores literais que são especificados pelos nomes dos
atributos da classe (exemplo de mapeamento pode ser visto na Figura 22).
1 2 3 4 5 6 7 8 9 10
<simpleType name="BuildingTypeType"> <restriction base="string"> <enumeration value="church"/> <enumeration value="school"/> <enumeration value="garage"/> <enumeration value="residential houses"/> <enumeration value="unknown"/> <enumeration value="mixed"/> </restriction> </simpleType>
Figura 22. Exemplo do mapeamento de uma classe UML com o estereótipo <<Enumeration>>. Fonte: OGC (2007).
35
3.2.2.6 Classes – CodeList
A OGC (2007) define que uma classe UML com um estereótipo <<CodeList>> e sem
o atributo “asDictionary” da classe no modelo UML original com o valor “true” deve ser
mapeada como uma classe com estereótipo <<Enumerations>>, mas com algumas diferenças
(exemplo de mapeamento na Figura 23):
• Devem-se utilizar padrões de restrições (facets), tais como “<pattern
value=’other:\w{2}’/>”, para estabelecer valores pré-definidos na lista. Utilizam-
se expressões regulares nas descrições das restrições;
• Se um código for especificado como um valor de “code list”, somente o código
pode ser utilizado no elemento <enumeration>;
• Um código pode ser qualificado com o uso de uma anotação <appinfo>, com um
elemento <gml:description> especificando um valor texto para os valores dos
elementos <enumeration>.
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 31 32 33 34
<simpleType name="ParcelUsageType"> <union memberTypes="pcl:ParcelUsageEnumerationType pcl:ParcelUsageOtherType"/> </simpleType> <simpleType name="ParcelUsageEnumerationType"> <restriction base="string"> <enumeration value="1"> <annotation> <appinfo><gml:description>factory</gml:description></appinfo> </annotation> </enumeration> <enumeration value="2"> <annotation> <appinfo><gml:description>road</gml:description></appinfo> </annotation> </enumeration> <enumeration value="3"> <annotation> <appinfo><gml:description>residential</gml:description></appinfo> </annotation> </enumeration> <enumeration value="4"> <annotation> <appinfo>< gml:description>offices</gml:description></appinfo> </annotation> </enumeration> </restriction> </simpleType> <simpleType name="ParcelUsageOtherType"> <restriction base="string"> <pattern value="other: \w{2,}"/> </restriction> </simpleType>
Figura 23. Exemplo do mapeamento de uma classe UML com o estereótipo <<CodeList>>. Fonte: OGC (2007).
36
3.2.2.7 Classes – Union
As classes com o estereótipo <<Union>> são mapeadas como <complexType> no
XML esquema. Os atributos da classe são mapeados como elementos que compõem a tag
<choice>. Os tipos dos atributos são mapeados de forma usual. Um exemplo de mapeamento
pode ser visto na Figura 24.
3.3 Atributos
O OGC (2007) define que atributos de classe UML são mapeados em um documento
GML esquema conforme as regras a seguir:
• Atributos de classes UML são mapeados como sendo uma tag <element>, em que
o valor do atributo “type” é definido pelas normas da série ISO 19100 (exemplos
de conversões podem ser encontrados na Quadro III);
• Se a classe possui os estereótipos <<Enumeration>> ou <<CodeList>>, os “types”
do atributo de classe são ignorados;
• O atributo “name” da tag <element> deve receber, como valor, o nome do atributo
UML a ser mapeado;
• A cardinalidade do atributo UML é mapeada através dos atributos “maxOccurs” e
“minOccurs”:
o O número máximo de vezes que um elemento pode aparecer é dado pelo
atributo “maxOccurs”. Esse número deve ser inteiro positivo. Se há um
número máximo de ocorrências do elemento (indicadas pelo símbolo “*”
na UML), a cardinalidade tem o seu valor convertido para “unbounded”;
o O número mínimo de vezes que um elemento pode aparecer é dado pelo
atributo “minOccurs”. Um elemento é obrigatório quando o valor do
atributo “minOccurs” é um (1) ou mais.
<<Union>>
RemoteResource
+name: String
+URI: anyURI
1 2 3 4 5 6
<complexType name="RemoteResourceType"> <choice> <element name="name" type="string"/> <element name="uri" type="anyURI"/> </choice> </complexType>
Figura 24. Exemplo do mapeamento de uma classe UML com o estereótipo <<Union>>. Fonte: OGC (2007).
37
3.4 Relacionamentos
Os relacionamentos UML (sejam composição, agregação ou associação) são tratados
da mesma maneira no mapeamento para documento GML, conforme as regras abaixo:
• Somente são mapeadas associações com extremidades nomeadas e navegáveis,
sejam ambas as extremidades do relacionamento ou somente uma extremidade
navegável. Associações com ambas as extremidades não-navegáveis ou com
extremidades não-nomeadas são ignoradas;
• Para cada relacionamento, é gerado um <element> local com o atributo “name”
igual ao relacionamento UML. O atributo “type” é definido como um property
type (nome da classe que faz referência no relacionamento mais o sufixo
“PropertyType”);
• Para representar relacionamentos, utiliza-se “gml:AssociationAttributeGroup”,
para providenciar o suporte a recursos XLink (método padrão que possibilita a
utilização de hipertextos em documentos XML);
• No modelo UML original, se o valor da tag “noPropertype” não estiver definido
com o valor “false”, é inserido um novo tipo, usando:
o O padrão A (Figura 25a), se o valor da tag “byValuePropertyType” não
estiver disponível ou com o valor “false”;
o O padrão B (Figura 25b), se o valor da tag “byValuePropertyType” for
igual a “true”.
• Os aspectos da navegabilidade do relacionamento são mapeados através de
padrões. Cada tipo de navegabilidade utiliza um padrão diferente:
o Relacionamento com somente uma extremidade navegável (Figura 26);
o Relacionamento do tipo agregação (Figura 27);
o Relacionamento com duas extremidades navegáveis (Figura 28);
1 2 3 4 5 6
<complexType name="NomeClassePropertyType"> Padrão A <sequence minOccurs="0"> <element ref="NomeClasse"/> </sequence> <AttributeGroup ref="gml:AssociationAttributeGroup"/> </complexType>
1 2 3 4 5
<complexType> Padrão B
<sequence> <element ref="NomeClasse"/> </sequence> </complexType>
Figura 25. Padrões para o mapeamento do relacionamento em um documento GML esquema.
38
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 31 32
<complexType name="ClasseAType"> <complexContent> <extension base="gml:AbstractGMLType"> <sequence> <element name="ClasseB" type="ClasseBPropertyType" minOccurs="0" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType> <complexType name="ClasseAPropertyType"> <sequence minOccurs="0"> <element ref="ClasseA"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup" /> </complexType> <element name="ClasseA" type="ClasseAType" substitutionGroup="gml:AbstractGML"/> <complexType name="ClasseBType"> <complexContent> <extension base="gml:AbstractGMLType"> </extension> </complexContent> </complexType> <complexType name="ClasseBPropertyType"> <sequence minOccurs="0"> <element ref="ClasseB"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup" /> </complexType> <element name="ClasseB" type="ClasseBType" substitutionGroup="gml:AbstractGML"/>
Figura 26. Padrão de mapeamento para relacionamento com uma extremidade navegável.
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 31 32
<complexType name="ClassAType"> <complexContent> <extension base="gml:AbstractGMLType"> <sequence> <element name="classeB" type="ClassBPropertyType" minOccurs="0" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType> <complexType name="ClassAPropertyType"> <sequence minOccurs="0"> <element ref="ClassA"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup" /> </complexType> <complexType name="ClassBType"> <complexContent> <extension base="gml:AbstractGMLType"> <sequence> </sequence> </extension> </complexContent> </complexType> <complexType name="ClassBPropertyType"> <sequence minOccurs="0"> <element ref="ClassB"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup" /> </complexType>
Figura 27. Padrão de mapeamento para relacionamento de agregação.
39
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 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
<complexType name="classeAType"> <complexContent> <extension base="gml:AbstractGMLType"> <sequence> <element name="classeB" type="ClassBPropertyType" minOccurs="0" maxOccurs="unbounded"> <annotation> <appinfo> <gml:reversePropertyName>classeA</gml:reversePropertyName> </appinfo> </annotation> </element> </sequence> </extension> </complexContent> </complexType> <complexType name="classeAPropertyType"> <sequence minOccurs="0"> <element ref="classeA"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup" /> </complexType> <element name="classeA" type="ClasseAType" substitutionGroup="gml:AbstractGML"/> <complexType name="ClasseBType"> <complexContent> <extension base="gml:AbstractGMLType"> <sequence> <element name="classeA" type="ClasseAPropertyType" minOccurs="0" maxOccurs="unbounded"> <annotation> <appinfo> <gml:reversePropertyName>classeB</gml:reversePropertyName> </appinfo> </annotation> </element> </sequence> </extension> </complexContent> </complexType> <element name="classeB" type="ClassBType" substitutionGroup="gml:AbstractGML"/> <complexType name="ClasseBPropertyType"> <sequence minOccurs="0"> <element ref="classeB"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup" /> </complexType>
Figura 28. Padrão de mapeamento para relacionamento com as duas extremidades navegáveis.
3.5 Entidades geográficas
Modelos de dados como o OMT-G descrevem a geometria das entidades geográficas
através de estereótipos, representados visualmente, no modelo conceitual, por pictogramas.
Porém, como visto no tópico 3.2.2 deste capítulo, somente os estereótipos <<FeatureType>>,
<<Type>>, <<DataType>>, <<Union>>, <<CodeList>> e <<Enumeration>> são
considerados durante o processo de conversão de modelo UML para GML esquema; todos os
outros estereótipos são ignorados. Em outras palavras, o documento OGC (2007) não
especifica qual o procedimento de decodificação das classes UML que utilizam framework ou
modelos de dados geográficos.
40
Uma abordagem descrita por Hess (2004) apresenta uma solução para a questão da
decodificação de entidades geográficas. Nessa abordagem, a representação geométrica
indicada pelo estereótipo da classe é mapeada como um <element>, isto é, o estereótipo é
tratado como mais um atributo da classe. Se houver mais de um estereótipo na classe, é criado
um elemento <choice> com todas as opções de representação geométrica da classe. Esse
procedimento é necessário devido ao fato de que, em um documento GML, uma entidade
geográfica só pode ter uma geometria associada a ele.
O plug-in Eclipse desenvolvido neste trabalho utiliza um perfil UML12 que dá suporte
a objetos GML em modelos conceituais produzidos pela ferramenta. Nesse perfil, são
disponibilizados três estereótipos representando os geo-objetos: ponto, linha e polígono. O
mapeamento desse perfil para GML esquema apresenta a questão de que a série ISO 19100
disponibiliza diferentes objetos GML para as geometrias ponto, linha e polígono, conforme
pode ser visto no Quadro IV.
A solução adotada por este trabalho foi utilizar o elemento <choice> nos
mapeamentos dos estereótipos linha e polígono do perfil UML aplicado pelo plug-in. A
adoção dessa solução possibilita, ao usuário final do GML esquema convertido, ter a opção de
utilizar uma geometria mais adequada para sua aplicação. Um exemplo de conversão de
classes UML com estereótipos de entidades geográficas (no caso, o estereótipo linha) pode ser
visto na Figura 29.
Quadro IV. Mapeamento de geometria para objetos GML. Fonte: adaptado de Hess (2004).
GML Objeto Geometria
GM_Point Ponto GM_Curve Linha LineString Linha GM_OrientableCurve Linha GM_CompositeCurve Linha GM_Solid Polígono GM_CompositeSolid Polígono Polygon Polígono
12 Nota do autor: mais detalhes sobre o perfil UML podem ser encontrados no tópico 4.2.3.1.
41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
<element name="classeA" type="classeAType" substitutionGroup="gml:AbstractFeature"/> <complexType name="classeAType"> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence> <choice> <element ref="gml:Curve"/> <element ref="gml:LineString"/> <element ref="gml:OrientableCurve"/> <element ref="gml:CompositeCurve"/> </choice> </sequence> </extension> </complexContent> </complexType>
Figura 29. Exemplo de conversão de classes UML com estereótipos de entidades geográficas.
3.6 Ferramentas de conversão de UML para GML esquema
No período em que este trabalho foi desenvolvido, estavam disponíveis as seguintes
ferramentas de conversão de modelos UML para GML esquema:
• UMT-QVT13 - ferramenta open source voltada para transformação de modelos e
geração de códigos a partir de modelos UML/XMI. O UMT-QVT não possui
editor gráfico; todo o processo de criação e edição dos modelos UML é feito em
documentos XMI (XML Metadata Interchange, padrão do OMG para troca de
informações baseadas em XML), que é um formato suportado por diversas
ferramentas UML. O UMT-QVT (versão 0.98) gera um GML esquema baseado na
versão 3.0; logo, uma versão já defasada;
• UML/INTERLIS editor14 - ferramenta open source que disponibiliza um editor
gráfico UML com suporte à abordagem MDA. O gerador de código da ferramenta
produz um GML esquema baseado na versão 3.2;
• ShapeChange15 - ferramenta open source baseada na linguagem Java e voltada
para a conversão de modelos UML para GML esquema. O ShapeChange não
possui editor gráfico; todo o processo de conversão do modelo UML é baseado no
formato XMI. A ferramenta é disponibilizada apenas em formato de servlet (classe
13 http://umt-qvt.sourceforge.net 14 http://www.umleditor.org 15 http://www.interactive-instruments.de/index.php?id=28&L=1
42
Java usada para estender servidores Web Java, como o Apache Tomcat). A versão
do GML esquema gerado pela ferramenta é baseada na versão 3.2.1;
• FullMoon16 - ferramenta open source baseada em linguagem Java que implementa
um framework de processamento ou transformação de documento XML para
diversos formatos de saída. A ferramenta é baseada em linha de comando;
portanto, não é disponibilizado um editor gráfico. Todo o processo de conversão
do modelo UML é baseado no formato de documento XMI. O GML esquema
gerado pela ferramenta é baseado na versão 3.2.1.
3.7 Exemplos de GML esquema
O GML esquema é um importante mecanismo de interoperabilidade; por essa razão,
diversas instituições e órgãos governamentais disponibilizam, para o público e comunidade de
interesse, o GML esquema de dados de áreas específicas. Segue uma listagem de alguns GML
esquemas disponíveis para uso ou consulta:
• AIXM17 (Aeronautical Information eXchange Model) – GML esquema construído
para possibilitar o gerenciamento e distribuição de dados AIS (Aeronautical
Information Service, dados aeronáuticos em formato digital);
• CSML18 (Climate Science Modelling Language) – padrão de modelo de dados e
GML esquema para dados atmosféricos e oceanográficos;
• GeoSciML19 (Geoscience Markup Language) – GML esquema para transporte e
representação de informações geológicas;
• SensorML20 (Sensor Markup Language) – padrão aprovado pela OGC que
providencia um modelo e GML esquema para descrever sensores e processos de
medição e aquisição de dados por sensores.
3.8 Considerações finais
As regras de conversão de UML para GML esquema descritas no documento OGC
(2007) não se aplicam a todos os elementos disponíveis em um modelo conceitual. Portanto,
existem brechas nas regras que exigem uma intervenção, para que o modelo conceitual a ser
convertido não perca informações pertinentes durante o processo.
16 http://projects.arcs.org.au/trac/fullmoon/wiki 17 http://www.aixm.aero 18 http://csml.badc.rl.ac.uk 19 http://www.geosciml.org 20 http://www.opengeospatial.org/standards/sensorml
43
Para este trabalho, existem dois pontos omissos por essas regras que podem interferir
no resultado final. O primeiro é o procedimento de decodificação de classes que utilizam
estereótipos do perfil UML aplicado pelo plug-in Eclipse implementado por este trabalho. O
segundo ponto omisso é a situação de que, nas normas da série ISO 19100, são
disponibilizadas diferentes entidades para representar a mesma geometria. Para esses dois
pontos, foram adotadas soluções similares ao uso do elemento <choice> da linguagem XML
esquema.
As soluções adotadas neste trabalho não interferem na validação dos GML esquemas
gerados. A possibilidade de ocorrência de propagação de erros ou efeitos colaterais devido ao
uso do GML esquema (que usaram essas soluções) é analisada nos capítulos subseqüentes.
44
4 PLUG-IN UML2GML
O presente capítulo se concentra no processo de desenvolvimento do plug-in
UML2GML para a plataforma Eclipse. O capítulo não traz detalhes de implementação do
código em si, mas sim a descrição dos conceitos e tecnologias empregados neste. Além disso,
é descrito o funcionamento da arquitetura interna do plug-in, para que o objetivo do trabalho
fosse atingido: criar um GML esquema a partir de um modelo UML.
A primeira parte do capítulo detalha brevemente as principais características do plug-
in e a sua arquitetura interna. Na arquitetura interna, são listados, de forma sucinta, os
conceitos e tecnologias empregados em seu funcionamento. A segunda parte do capítulo foca
a caracterização dos conceitos e tecnologias e a especificação da colaboração dos mesmos
para o funcionamento do plug-in. A última parte do capítulo apresenta o funcionamento em si
do plug-in UML2GML dentro da plataforma Eclipse e o resultado final da aplicação do plug-
in em modelo conceitual exemplo, proposto pela OGC.
4.1 Características do plug-in UML2GML
O plug-in UML2GML possui as seguintes características:
• Plug-in para plataforma Eclipse, desenvolvido na ferramenta PDE (Plug-in
Development Environment) integrada no IDE (Integrated Development
Environment) Eclipse versão 3.4.2 (codinome Ganymede);
• Capacidade de converter modelos conceituais desenvolvidos em UML2 (somente
diagramas de classes) para GML esquema (versão GML 3.2.1). A conversão pode
ser feita em modelos UML2 que utilizem ou não um perfil (no caso desta
dissertação, foi elaborado um perfil denominado perfil OGC, que dá suporte ao uso
de objetos GML da série ISSO 19100);
• Integração com a interface gráfica da ferramenta open source MDT/Papyrus.
4.2 Arquitetura do plug-in UML2GML
A arquitetura do plug-in UML2GML pode ser dividida em quatro camadas distintas
que encapsulam conceitos e tecnologias utilizadas na implementação e na geração do GML
esquema (Figura 30):
• Camada plataforma Eclipse – camada mais externa, que engloba o conceito de
plug-in como mecanismo de extensão da ferramenta Eclipse. Agrega inúmeras
ferramentas e tecnologias que, no final, produzem o GML esquema;
45
Figura 30. Arquitetura do plug-in UML2GML.
• Camada MDA – camada intermediária, que abrange o uso da abordagem MDA
(Model Driven Architecture) na transformação de modelos UML em código;
• Camada Papyrus – camada interna composta pela ferramenta Papyrus. O Papyrus
utiliza os componentes UML221 e GMF22 para a construção de editores gráficos
UML para finalidades específicas. O recurso de extensão UML usado nessa
camada é um perfil denominado perfil OGC. A utilização de todas essas
tecnologias em conjunto gera um editor gráfico UML com suporte a objetos GML
da série ISO 19100. Esse editor produz modelos UML que são convertidos para
GML esquema;
• Camada UML2GML – camada interna em que ocorre a conversão do modelo
UML em GML esquema. Dentro dessa camada, a ferramenta EMF (Eclipse
Modeling Framework) é utilizada para acessar e manipular o modelo UML da
camada Papyrus. A conversão em si é feita utilizando as normas de decodificação
da OGC (2007). A formatação do documento GML esquema gerado é realizada
utilizando templates da ferramenta JET (Java Emitter Template). O produto final
da camada é um GML esquema pronto para uso.
21 Padrão UML 2.x em formato de metamodelo para a plataforma Eclipse. 22 Nota do autor: conferir tópico 4.2.2.4.
46
4.2.1 Model Driven Architecture
Model Driven Architecture (MDA), também conhecida como MDE (Model Driven
Engineering) e MDD (Model Driven Development), é uma metodologia criada pelo OMG23
(Object Management Group) que propõe que o modelo, além de ser um meio de documentar
sistemas, passe a figurar também como uma etapa fundamental de construção do software.
Em outras palavras, MDA é a tecnologia que possibilita a transformação de modelos UML
em outros modelos e/ou artefatos (FERRARINI, 2008; SEVESTRE, 2008). Para viabilizar
essa transformação, a MDA faz uso do conceito de modelos PIM e PSM:
• PIM (Plataform Independent Model) – modelo que captura as características
fundamentais do sistema a ser desenvolvido, podendo-se utilizar qualquer tipo de
modelo ou metodologia, sendo a UML a mais comum. Ao criar o modelo, o
analista indica, através do uso de um perfil24, qual é o tipo de elemento concreto
que será produzido pelas transformações subseqüentes (SEVESTRE, 2008). Um
único PIM pode gerar vários PSM para diversas tecnologias existentes;
• PSM (Plataform Specific Model) – modelo diretamente ligado à tecnologia e aos
serviços providos pela plataforma onde o sistema é desenvolvido. Usualmente,
deve ser gerado de forma automática a partir de um PIM (FERRARINI, 2008). O
PSM se relaciona com o PIM através de um perfil UML, que disponibiliza
estereótipos e etiquetas que possibilitam, a um PSM, gerar um artefato (i. e.
código, documento ou outro PSM). Um PSM também utiliza conjuntos de
parâmetros (específicos para o projeto em questão) que auxiliam na tarefa de gerar
artefatos subseqüentes (SEVESTRE, 2008).
Um diagrama que exemplifica o funcionamento da MDA pode ser visto na Figura 31.
No lado esquerdo da imagem, PIM, PSM e parâmetros entram no mecanismo de
transformação e resultados nos artefatos do sistema real, sejam código-fonte, descritores
XML ou XML esquema e DDLs (Data Definition Language), como scripts SQL (Structured
Query Language).
23 http://www.omg.org/mda/ 24 Perfil (profile) é um conjunto de estereótipos ou etiquetas (tags) disponíveis para utilização em determinado contexto ou domínio da aplicação.
47
I
I
Figura 31. Visão geral do funcionamento de uma MDA. Fonte: Sevestre (2008).
As principais vantagens na utilização da MDA são (FERRARINI, 2008; BELIX,
2006):
• Portabilidade – obtida através da separação do conhecimento da aplicação dos seus
respectivos mapeamentos para uma plataforma determinada;
• Interoperabilidade - múltiplos PSMs gerados a partir de um PIM podem ter
relacionamentos, os quais são denominados bridges (pontes) dentro do vocabulário
MDA. Por exemplo, uma classe persistente “Logradouro”, no PIM, pode ser
transformada em classe, em código ou em um script SQL para um banco de dados;
• Produtividade – obtida através da automação do código-fonte, componentes e
documentação;
• Qualidade – o incremento de qualidade dos produtos é obtido pelo uso de padrões
testados e boas práticas que podem ser produzidas pelas transformações;
• Manutenção – obtida pela separação de conceitos e pela possibilidade de se fazer o
rastreamento entre a especificação e o código-fonte gerado.
As principais desvantagens na utilização da MDA são a complexidade e a rigidez do
modelo produzido: o desempenho do código gerado pelo mecanismo de transformação
geralmente é inferior ao produzido por um programador.
O mecanismo de transformação é considerado uma parte crucial para a abordagem
MDA, podendo ser definido como o processo de geração de um modelo-alvo a partir de um
modelo-fonte (BELIX, 2006). Partindo dessa definição, o mecanismo de transformação pode
ser dividido em dois tipos: Modelo para Modelo (M2M) e Modelo para Textos (M2T). As
ferramentas MDA geralmente trazem embutidas, em suas soluções, esses conceitos, e muitas
vezes são transparentes para o usuário (FERRARINI, 2008).
48
Dentro da comunidade MDA, muito esforço está sendo feito para a produção de
ferramentas que gerem códigos para aplicações. Relevantes resultados têm sido obtidos pela
comunidade da ferramenta open source Eclipse dentro de um projeto denominado Modeling25
(FAUCHER & LAFAYE, 2007). O projeto Eclipse Modeling enfoca a evolução e a promoção
de tecnologias MDA dentro da comunidade Eclipse, providenciando a unificação de
conjuntos de frameworks, ferramentas e padrões de implementação.
4.2.2 Plataforma Eclipse
Eclipse é uma plataforma de desenvolvimento open source baseada em Java. Por si
mesma, é um framework e um conjunto de serviços utilizados na construção de aplicações e
plug-ins que estendem a própria plataforma.
A plataforma Eclipse é usualmente reconhecida por seus usuários como um IDE para
programação em linguagem Java. No entanto, seu potencial de uso é bem maior com o PDE
(Plug-in Development Environment). O principal objetivo do PDE é estender a plataforma,
construindo ferramentas que se integrem perfeitamente com o ambiente Eclipse. Como tudo
no Eclipse é um plug-in, com o PDE, os desenvolvedores têm, à disposição, uma ferramenta
com condições equitativas na produção de extensões que atenda aos requisitos de coesão e
unificação do IDE para os usuários (ANISZCZYK & GALLARDO, 2007). Essa paridade e
consistência não estão limitadas a ferramentas de programação. O framework da plataforma
Eclipse pode ser utilizado como “base” para outros tipos de aplicações não relacionadas ao
desenvolvimento de software, tais como os SIGs open source uDig26 e Open Jump27.
4.2.2.1 Arquitetura da plataforma Eclipse
A plataforma Eclipse leva o conceito de plug-ins ao extremo, pois agrega quase todos
os seus componentes através desse mecanismo (com exceção do Core ou núcleo da
plataforma). Segue abaixo a descrição de alguns dos componentes mais relevantes
(ANISZCZYK & GALLARDO, 2007):
• Runtime – parte responsável por definir o modelo Eclipse de plug-ins, baseada na
especificação OSGi. O runtime também disponibiliza os serviços adicionais de
logging e concorrência de processos;
25 http://www.eclipse.org/modeling/ 26 http://udig.refractions.net/ 27 http://openjump.org/
49
• OSGi (Open Services Gateway Initiative) - ambiente orientado a serviços e
baseado em componentes para gerenciar o ciclo de vida de softwares - em outras
palavras, um sistema de módulos (DOEDERLEIN, 2007);
• JFace/SWT – o SWT (Standard Widget Toolkit) é um conjunto de componentes
visuais utilizados na aparência da plataforma Eclipse. JFace é a camada superior
do SWT que providencia classes MVC (Model–View–Controller) que facilitam o
desenvolvimento de aplicativos gráficos na plataforma Eclipse;
• Workbench – interface gráfica do usuário, é o que dá personalidade ao Eclipse.
Conceitos de views, perspectivas e editores são definidos nesse nível;
• Help – providencia assistência ao usuário através de um sistema de ajuda. Consiste
em documentação on-line com sistema de busca e no mecanismo de cheatsheets
(lista interativa que ensina o passo-a-passo para a realização de certas tarefas no
Eclipse);
• Update – providencia facilidades na atualização de um aplicativo ou plug-in de
uma versão para outra mais atualizada;
• Team – framework que permite, aos desenvolvedores, o controle de versão de
plug-in ou aplicativos. Um exemplo de implementação team é o plug-in CVS,
disponibilizado dentro do pacote Eclipse.
A arquitetura da plataforma Eclipse é uma estrutura voltada para plug-in. Conforme
visto na Figura 32, seus componentes podem ser divididos em três tipos:
• Elementos obrigatórios - componentes básicos e obrigatórios da plataforma
Eclipse e a única parte não implementada como plug-in (cor branca na Figura 32);
Figura 32. Arquitetura da plataforma Eclipse: elementos obrigatórios (branco), elementos não obrigatórios, porém recomendados (cinza claro) e elementos opcionais (cinza escuro). Fonte: Aniszczyk & Gallardo (2007).
50
• Elementos não obrigatórios, porém recomendados - componentes Eclipse não
obrigatórios, mas de inserção altamente recomendada em plug-ins ou aplicativos
que usem a plataforma Eclipse (cor cinza claro na Figura 32);
• Elementos não obrigatórios – componentes completamente opcionais em uma
aplicação ou plug-in da plataforma Eclipse (destaque cinza na Figura 32).
4.2.2.2 Plug-in Eclipse
Um plug-in é o bloco de construção fundamental da plataforma Eclipse. A ferramenta
Eclipse é a soma de componentes plug-ins, cada um contribuindo com funcionalidades para a
plataforma, sendo que esses plug-ins são ativados quando a funcionalidade se faz necessária
(MELHEM & GLOZIC, 2003). Estruturalmente, cada plug-in reside em um subdiretório
denominado eclipse/plugins dentro do local de instalação do Eclipse. Os diretórios e arquivos
normalmente encontrados em um diretório de plug-in são:
• Arquivo plugin.xml – manifesto contendo informações de detalhes do plug-in, tais
como nome do plug-in, versão da dependência, extensões, dentre outros;
• Arquivo plugin.properties – arquivo de configuração de propriedades para o
plugin.xml;
• Arquivo about.html – arquivo HTML com informações sobre versão e licença do
plug-in;
• Pasta lib – diretório de bibliotecas (arquivos em formato .jar) necessárias para o
funcionamento do plug-in;
• Pasta icon – pasta com ícones utilizados pelo plug-in.
Conforme visto na Figura 33, na arquitetura de um plug-in Eclipse, quando a
plataforma Eclipse é iniciada, o módulo Core examina a lista de plug-ins disponíveis no
diretório plugins e os carrega no sistema, se eles estiverem configurados. Dentro do módulo
Core, o runtime é responsável pela inicialização, funcionamento e gerenciamento dos plug-ins
dentro do Eclipse. Ainda dentro do módulo Core, há o workspace, que administra os recursos
do usuário, organizados dentro de um ou mais projetos. O módulo Core é genérico e tem um
comportamento igual para todos os plug-ins, com ou sem interface para o usuário. O módulo
de interface do usuário é responsável pela entrada e saída de dados dos plug-ins, podendo ser
dividido em três grupos: workbench, JFace e SWT. O layout em módulos da arquitetura de
um plug-in Eclipse possibilita o uso dos recursos dos módulos Core e interface através das
51
Figura 33. Arquitetura de um plug-in Eclipse. Fonte: Guclu (2008).
ferramentas PDE e JDT (Java Development Tool, IDE para programação em linguagem Java),
além permitir a troca de recursos entre plug-ins.
O PDE é um conjunto de ferramentas focadas no desenvolvimento de plug-ins para o
Eclipse. O PDE pode ser dividido em três componentes:
• PDE UI – componente principal, que agrega as ferramentas para criação,
desenvolvimento, teste, depuração e disponibilização de plug-ins Eclipse;
• PDE Build – componente que automatiza as funções de montagem (compilação e
execução) do plug-in;
• PDE API Tools – componente API (Application Programming Interface) que
disponibiliza o acesso aos recursos do PDE para desenvolvedores de plug-ins.
4.2.2.3 Eclipse Modeling
Eclipse Modeling é um projeto focado na utilização de tecnologias relacionadas a
desenvolvimento baseado em modelagem (MDD, MDA, MDE, dentre outros) dentro da
comunidade Eclipse. O objetivo do projeto é concentrar todos os projetos relacionados a essa
tecnologia, promovendo a colaboração, unificação e melhoria da interoperabilidade dos
projetos. Abaixo seguem alguns projetos agregados ao Eclipse Modeling (ECLIPSE, 2008):
• EMF - framework para modelagem e geração de código a partir de modelos;
• GEF (Graphical Editing Framework) – framework para criação de editores
gráficos genéricos;
52
• GMF (Graphical Modeling Framework) – framework para geração de editores
gráficos baseados em modelos de domínios, utilizando EMF e GEF;
• UML2 (Unified Modeling Language 2.0) – baseado nas especificações do OMG,
Eclipse UML2 é uma implementação EMF da UML 2.x em formato meta-modelo
para a plataforma Eclipse.
4.2.2.4 GMF
GMF é um framework utilizado na construção de editores gráficos baseados na
plataforma Eclipse. O framework pode ser dividido em dois componentes principais: tooling e
runtime (GMF, 2008). O componente tooling do GMF disponibiliza uma abordagem
orientada a modelos para geração dos editores gráficos. O componente runtime disponibiliza
os elementos e ferramentas básicas para o editor.
O funcionamento do GMF pode ser sintetizado pelo diagrama de sua arquitetura,
(Figura 34), em que um editor gráfico gerado pela ferramenta GMF depende diretamente do
componente GMF runtime, que incorpora, por sua vez, as ferramentas EMF e GEF
(PLANTE, 2006). A ferramenta EMF providencia uma infraestrutura runtime para instanciar
e manipular modelos; já o GEF é um framework MVC que cria os elementos gráficos do
editor.
Figura 34. Arquitetura do GMF. Fonte: GMF (2008).
53
O EMF possibilita a modelagem do domínio do editor gráfico, usando um meta-
modelo próprio denominado Ecore. O Ecore é relativamente mais simples que as
especificações MOF (Meta Object Facility) da MDA (SANGIORGI et al., 2007). Por ser
independente da linguagem, o Ecore não é capaz de gerar código, sendo necessária a
transformação em outro meta-modelo específico para a geração do código. Na Figura 35, é
mostrado um workflow com o processo de criação de meta-modelos até a obtenção do código
do editor gráfico. As etapas desse workflow são descritas abaixo:
• Criação do modelo do domínio – modelo que define a parte não-gráfica que será
gerenciada pelo editor;
• Criacão do modelo de definição do diagrama – modelo que define os elementos
gráficos que poderão ser mostrados pelo editor;
• Criação do modelo de mapeamento do diagrama – modelo que define o
mapeamento entre os elementos do modelo de domínio e os elementos gráficos;
• Geração do código do editor gráfico;
• Customização do código do editor gráfico, se necessário.
Plante (2006) afirma que as principais vantagens na utilização do GMF runtime são:
• Proporciona um look & feel (aparência) consistente para todos os editores gráficos
baseados em GMF;
• Proporciona a opção de o editor poder ser criado manualmente de cima para baixo
e/ou gerado a partir de ferramentas padronizadas pelo GMF;
• Gerencia a persistência do diagrama, permitindo que o programador se concentre
na regra de négocios do editor;
Figura 35. Funcionamento do GMF. Fonte: Plante (2006).
54
• A natureza extensível do GMF runtime permite, ao programador, a construção de
editores totalmente “em aberto”, que, por sua vez, podem ser extendidos por
terceiros;
• Já está integrado e com suporte a novas tecnologias, como EMFT (projeto Eclipse
que agrega novas tecnologias em incubação e que extendem o EMF) e OCL
(Object Constraint Language, linguagem declarativa usada para descrever regras
aplicadas a modelos UML);
• Define um meta-modelo de notação que pode ser ampliado, a fim de permitir a
separação da notação do modelo com as questões semânticas;
• Segue padrões bem concebidos de design, codificação, teste e implantação;
• Futuras melhorias da comunidade GMF podem ser facilmente integradas ao editor.
4.2.3 MDT/Papyrus
Papyrus é uma ferramenta open source baseada na plataforma Eclipse dedicada à
modelagem com UML2 (PAPYRUS, 2009). Desde outubro de 2008, o Papyrus faz parte do
MDT Eclipse, projeto que tem dois objetivos: fornecer implementações de padrões de
metamodelos para a indústria e providenciar ferramentas-exemplo para o desenvolvimento de
modelos baseados nesses metamodelos.
A arquitetura do Papyrus (Figura 36) tem, como componente principal, o Papyrus
UML Editor, que é baseado na plataforma Eclipse, sendo complementado pelas ferramentas
Eclipse EMF, GEF e UML2. Como pode ser visto em sua arquitetura, o Papyrus não adota
complementarmente a tecnologia GMF (o conceito de GMF runtime não é totalmente
utilizado). Contudo, a partir da versão 2.0, sua arquitetura será baseada em GMF (PAPYRUS,
2009).
Os principais mecanismos de extensões da ferramenta Papyrus são:
• Perfil – mecanismo de extensão da UML que possibilita utilizar a UML de acordo
com necessidades específicas de uma tecnologia (SANDRI, 2006);
• Geração de código – suporte integrado para geração de código em linguagem Java.
Suporte a geração de código em linguagem C e C++ disponível em formato plug-
in. As ferramentas disponíveis no Papyrus para geração de código são Acceleo28 e
JET;
28 http://www.acceleo.org
55
Figura 36. Arquitetura MDT/Papyrus. Fonte: Papyrus (2009).
• Transformação de modelos – a transformação entre modelos (seja de modelos PIM
para PSM ou de PSM para outro PSM) no Papyrus pode ser feita utilizando a ATL
(ATLAS Transformation Language). A ATL é uma linguagem para transformação
de modelos em geral que segue as recomendações do OMG para o framework
MDA.
A plataforma Eclipse utiliza o conceito de perspectiva, que consiste no conjunto de
janelas com funcionalidades associadas a uma determinada tarefa. Por exemplo, a perspectiva
Java está associada com todas as ferramentas para a programação em linguagem Java. Cada
perspectiva tem views (visões), abas e editores apropriados para cada tarefa específica. A
perspectiva utilizada pelo Papyrus é composta por (Figura 37):
• Navigator explorer – utilizado tanto para navegação do projeto quanto para
navegação entre os elementos do modelo;
• Multi editor – editor gráfico em que é construído o modelo;
• Palette tools – conjunto de ferramentas disponíveis seja de criação ou de edição,
para o processo de modelagem;
56
Figura 37. Perspectiva MDT/Papyrus.
• Bird view – visualizador e navegador gráfico do modelo;
• Properties view – permite visualizar as propriedades do elemento gráfico
selecionado.
4.2.3.1 Perfil OGC
Um perfil ou profile é um pacote UML, uma coleção de estereótipos, definições de
etiquetas (tags) e restrições (constraints), um subconjunto de elementos padrões UML, ou
também novos tipos de dados para facilitar a construção de modelos para propósitos
específicos, isto é, um perfil fornece mecanismos que possibilitam estender a linguagem UML
(LIMA, 2005).
No presente trabalho, foi elaborado um perfil denominado perfil OGC. A utilização
desse perfil possibilita o uso de objetos GML29 dentro da ferramenta Papyrus, além de
disponibilizar os seguintes estereótipos:
• FeatureType – utilizado para modelar uma feição;
• DataType – utilizado para modelar um novo tipo de dado;
• Union – utilizado para modelar uma estrutura de dados denominada união, que é
uma junção de duas classes em uma única classe;
• CodeList – utilizado para modelar uma estrutura de dados em formato de lista de
constantes;
29 Uma listagem completa de objetos GML está disponível no Anexo I deste trabalho.
57
• Enumeration – utilizado para modelar uma estrutura de dados em formato de lista
restrita de valores literais.
Além desses estereótipos específicos para a construção de modelo de uma aplicação
GML esquema, o perfil OGC disponibiliza três estereótipos, baseados em geo-objetos do
modelo OMT-G. Os três estereótipos são geo-objetos que representam objetos geográficos
individualizáveis que possuem identificação com elementos do mundo (BORGES, 1997):
• Ponto – representa por um símbolo uma entidade geográfica;
• Linha – representa um segmento de reta formado por uma linha simples;
• Polígono – um arco ou poli-linha, o polígono representa uma área.
No caso específico dos geo-objetos, o plug-in UML2GML disponibiliza um acesso
rápido a esses estereótipos através da palette tools da ferramenta Papyrus (Figura 38).
4.2.4 Java Emitter Template
A ferramenta Java Emitter Template (JET) é utilizada em implementações que
necessitam de recursos de geradores de código. Um gerador de código é um componente
MDA cujo objetivo é descrever um software usando modelos abstratos (sejam modelos
EMF/ECORE ou modelos UML) para, em seguida, refinar e transformar esses modelos em
código (JET, 2009).
Figura 38. Palette tools da ferramenta Papyrus com os estereótipos do modelo OMT-G.
58
Embora seja possível criar modelos abstratos e transformá-los manualmente em
código, a utilização de uma abordagem MDA possibilita automatizar o processo de geração
de código, já agregando, ao código, “boas práticas” de engenharia de software. Porém, nem
sempre o código gerado é “perfeito“, uma vez que algumas técnicas de engenharia de
software tendem a ser dependentes do contexto - ou seja, o que pode ser ótimo em um
contexto pode não ser tão bom em outro. Mecanismos de transformação MDA podem
resolver esse problema através da inclusão de algum componente de modificação do código
gerado. Isso é freqüentemente feito com a utilização de templates. Com templates, criam-se
artefatos que podem efetuar substituições do código gerado conforme a necessidade da
aplicação. Criar e manipular templates são as funções principais do JET em um mecanismo de
geração de código.
Os principais componentes do JET são (a interação e o funcionamento dos
componentes do JET podem ser vistos na Figura 39):
• JET template – script contendo elementos e trechos de código que definem como
um modelo pode ser mapeado para código;
• JET genlet – classe Java que contém um método denominado generate. Esse
método recebe um argumento, um modelo e retorna uma string contendo o código
gerado a partir do modelo;
• JET generator – aplicação que carrega o modelo a partir de um arquivo e, em
seguida, invoca o JET genlet e salva o código gerado em arquivos.
A sintaxe dos templates JET é muito similar à linguagem JSP (Java Server Pages),
sendo composta essencialmente por (EBERLE & BOSCH, 2006):
Figura 39. Funcionamento do JET.
59
• Diretivas JET
o <%@jet attr=”valor” %> – interfere na transformação do template, porém
não produz qualquer saída para o gerador de código.
• Elementos script JET
o <%=expressão %> – expressão Java que, quando avaliada como correta
pelo JET, produz uma saída para o gerador de código;
o <%script %> – trecho de código Java que pode ou não produzir uma saída
para o gerador de código.
• Objetos implícitos Java
o argument – objeto Java passado para o template durante a invocação do
método generate.
• Textos fora dos elementos script JET
o são automaticamente inseridos no saída do gerador de código.
4.3 Diagrama de atividade do plug-in UML2GML
Na Figura 40, pode ser visto o diagrama de atividade do plug-in UML2GML. Através
desse diagrama, é possível verificar os aspectos dinâmicos do funcionamento do plug-in.
Destaca-se a utilização de regras de conversão específicas para classes com e sem
estereótipos. O uso de templates JET após o processo de conversão, tanto no cabeçalho do
documento GML esquema, quanto na conversão das classes do modelo, possibilita a
formatação do documento em um padrão válido.
60
Figura 40. Diagrama de atividade do plug-in UML2GML.
4.4 Procedimentos de uso do plug-in UML2GML
O procedimento de uso do plug-in UML2GML é bastante simples, envolvendo as
seguintes etapas (Figura 41):
1. Seleção do modelo UML que se deseja converter para GML esquema na janela
Navigator explorer (clicando-se com o botão direito do mouse sobre o arquivo do
modelo);
2. Seleção da opção UML2GML (sub-menu “Gerar GML esquema”);
3. Preenchimento dos campos da tela de configuração do gerador de GML:
61
Figura 41. Procedimentos para uso do plug-in UML2GML.
o Diretório em que será salvo o GML esquema;
o Nome do arquivo GML esquema;
o Namespace do documento esquema gerado;
o Prefixo do documento esquema gerado.
4. Aviso de sucesso do procedimento de conversão.
4.5 Procedimento de teste e validação do plug-in UML2GML
Como procedimento de teste e validação do plug-in UML2GML, foi definido o uso de
um modelo conceitual de teste. Esse modelo de teste foi modelado na ferramenta Papyrus
com o perfil OGC e posteriormente convertido para GML esquema, o qual finalmente foi
validado por um parser XML esquema. Um parser é uma ferramenta que verifica se a sintaxe
de um documento XML esquema atende aos padrões estabelecidos pela W3C. A ferramenta
parser utilizada nesta dissertação foi a Altova XMLSpy 2008 Enterprise Edition30.
O modelo-teste selecionado foi o modelo conceitual exemplo proposto pelo Anexo E
do documento OGC (2007). Na Figura 42, é apresentado o modelo-teste já implementado
dentro da ferramenta Papyrus. Nota-se, no modelo resultante, o uso do perfil OGC através dos
estereótipos <<FeatureType>>,<<DataType>>, <<Enumeration>> e <<CodeList>>.
30 http://www.altova.com/
62
Figura 42. Modelo conceitual exemplo proposto pela OGC (2007) e implementado na ferramenta Papyrus com perfil OGC.
Também no modelo conceitual exemplo e fazendo parte do perfil OGC, estão os
objetos da série ISO 19100: GM_CurveSegment, GM_Surface, Polygon, Area, DirectPosition
e Vector.
A etapa subseqüente foi o processo de converter o modelo conceitual UML, produzido
no Papyrus, para GML esquema. O resultado do processo de conversão pode ser visto no
trecho de código abaixo. Após a etapa de conversão, foi utilizada a ferramenta parser Altova
XMLSpy 2008, para efetuar a validação do GML esquema produzido. O resultado da análise
da ferramenta parser retornou que o documento esquema gerado pelo plug-in UML2GML é
“válido”.
1 2 3 4 5 6 7 8 9 10
<?xml version="1.0" encoding="UTF-8"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:tmp="http://www.mynamespace.com/myUMLModel" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gml="http://www.opengis.net/gml/3.2" targetNamespace="http://www.mynamespace.com/myUMLModel" elementFormDefault="qualified" version="1.0"> <!--=================================================--> <import namespace="http://www.opengis.net/gml/3.2" schemaLocation="gml/3.2.1/gml.xsd"/> <import namespace="http://www.w3.org/1999/xlink" schemaLocation="xlink/1.0.0/xlinks.xsd"/> <!--=================================================--> <element name="Parcel" type="tmp:ParcelType" substitutionGroup="gml:AbstractFeature"/> <complexType name="ParcelType">
63
11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 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 86 87 88 89 90 91
<complexContent> <extension base="gml:AbstractFeatureType"> <sequence> <element name="area" type="gml:AreaType"/> <element name="extent" type="gml:PolygonType"/> <element name="hasBuilding" type="tmp:BuildingPropertyType" minOccurs="0" maxOccurs="unbounded"/> <element name="owner" type="tmp:PersonPropertyType" minOccurs="0" maxOccurs="unbounded"> <annotation> <appinfo> <gml:reverseProperty>tmp:owns</gml:reverseProperty> </appinfo> </annotation> </element> </sequence> </extension> </complexContent> </complexType> <complexType name="ParcelPropertyType"> <sequence minOccurs="0"> <element ref="tmp:Parcel"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup"/> </complexType> <element name="Person" type="tmp:PersonType" substitutionGroup="gml:AbstractFeature"/> <complexType name="PersonType"> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence> <element name="firstName" type="string"/> <element name="lastName" type="string"/> <element name="owns" type="tmp:ParcelPropertyType" maxOccurs="unbounded"> <annotation> <appinfo> <gml:reverseProperty>tmp:owner</gml:reverseProperty> </appinfo> </annotation> </element> </sequence> </extension> </complexContent> </complexType> <complexType name="PersonPropertyType"> <sequence> <element ref="tmp:Person"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup"/> </complexType> <element name="Building" type="tmp:BuildingType" substitutionGroup="gml:AbstractFeature"/> <complexType name="BuildingType"> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence> <element name="extent" type="gml:SurfacePropertyType"/> <element name="address"> <complexType> <sequence> <element name="address" type="tmp:AddressType"/> </sequence> </complexType> </element> <element name="type" type="tmp:BuildingTypeType"/> </sequence> </extension> </complexContent> </complexType> <complexType name="BuildingPropertyType"> <sequence minOccurs="0"> <element ref="tmp:Building"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup"/> </complexType> <complexType name="AddressType"> <sequence> <element name="street" type="string" minOccurs="0"/> <element name="houseNumber" type="string" minOccurs="0"/> <element name="poBox" type="string" minOccurs="0"/>
64
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
<element name="city" type="string"/> <element name="postalCode" type="string"/> <element name="country" type="tmp:CountryCodeType" default="DE" minOccurs="0"/> </sequence> </complexType> <simpleType name="BuildingTypeType"> <restriction base="string"> <enumeration value="church"/> <enumeration value="school"/> <enumeration value="garage"/> <enumeration value="residentialHouse"/> <enumeration value="unknown"/> <enumeration value="mixed"/> </restriction> </simpleType> <simpleType name="CountryCodeType"> <union memberTypes="tmp:CountryCodeEnumerationType tmp:CountryCodeOtherType"/> </simpleType> <simpleType name="CountryCodeEnumerationType"> <restriction base="string"> <enumeration value="DE"/> <enumeration value="US"/> <enumeration value="CA"/> <enumeration value="..."/> </restriction> </simpleType> <simpleType name="CountryCodeOtherType"> <restriction base="string"> <pattern value="other:\w{2,}"/> </restriction> </simpleType> <element name="Elipse" type="tmp:ElipseType" substitutionGroup="gml:AbstractCurveSegment"/> <complexType name="ElipseType"> <complexContent> <extension base="gml:AbstractCurveSegmentType"> <sequence> <element name="center" type="gml:DirectPositionType"/> <element name="semiminor" type="gml:VectorType"/> <element name="semimajor" type="gml:VectorType"/> </sequence> </extension> </complexContent> </complexType> </schema>
4.6 Considerações finais
A plataforma Eclipse tem, como principal característica, a versatilidade e a capacidade
de disponibilizar soluções tecnológicas para os mais variados tipos de problemas. Essa
qualidade pôde ser comprovada na prática durante a implementação do plug-in UML2GML,
projeto que integra inúmeras tecnologias MDA. A integração das tecnologias MDA usadas
nesse projeto é extremamente facilitada devido às características da arquitetura da plataforma
Eclipse, composta por inúmeros módulos, com foco no uso massivo de plug-ins.
Entretanto, a utilização da plataforma Eclipse teve, como desafio, a grande curva de
aprendizado necessária para obter o conhecimento para: unir conceitos e tecnologias MDA;
utilizar a tecnologia de construção de plug-ins Eclipse; agregar, de forma homogênea,
ferramentas bastante distintas, como EMF, GEF e templates JET. Todo esse conhecimento
teve de ser obtido para que, no final, fosse construída a ferramenta proposta por esta
dissertação.
65
5 ESTUDO DE CASO: CONCAR
Este capítulo apresenta um estudo de caso com a utilização do plug-in UML2GML. O
objetivo desse estudo de caso é verificar a potencialidade prática da Estrutura de Dados
Geoespaciais Digitais Vetoriais (EDGV) da Mapoteca Nacional Digital (MND). Para isso,
neste capítulo, inicialmente são apresentados o órgão responsável pela EDGV (a CONCAR -
Comissão Nacional de Cartografia) e todo o processo para a criação da EDGV e seus
objetivos.
A segunda parte do capítulo se concentra nos procedimentos para a aplicação do
estudo de caso com o uso da EDGV. São detalhados desde o processo de seleção do pacote
mais adequado para mostrar o potencial de utilização da EDGV até os protocolos de ajustes
que foram adotados para que o modelo conceitual da EDGV escolhido fosse convertido para
um documento GML esquema válido com o uso do plug-in UML2GML.
O capítulo é finalizado apresentando um exemplo de documento GML gerado a partir
de um GML esquema, o qual, por sua vez, foi produzido a partir de um modelo conceitual
proposto pela EDGV.
5.1 CONCAR - Comissão Nacional de Cartografia
A CONCAR surgiu em 1994, vinculada ao Ministério de Planejamento, Orçamento e
Gestão (conforme a estrutura organizacional mostrada na Figura 43), com o objetivo de
coordenar e orientar a elaboração e a implementação da Política Cartográfica Nacional (PCN)
e a manutenção do Sistema Cartográfico Nacional (SCN), com vistas à ordenação da
aquisição, produção e disseminação de informações geoespaciais (CONCAR, 2009).
Dentro do organograma da CONCAR, existe a Infraestrutura Nacional de Dados
Espaciais do Brasil (INDE-Brasil), que tem, por objetivo (BRASIL, 2008):
• Promover o adequado ordenamento na geração, armazenamento, acesso,
compartilhamento, disseminação e uso dos dados geoespaciais de origem federal,
estadual, distrital e municipal, em proveito do desenvolvimento do país;
• Promover a utilização, na produção dos dados geoespaciais pelos órgãos públicos
das esferas federal, estadual, distrital e municipal, dos padrões e normas
homologados pela CONCAR;
66
Figura 43. Estrutura organizacional da CONCAR. Fonte: Adaptado de CONCAR (2009).
• Evitar a duplicidade de ações e o desperdício de recursos na obtenção de dados
geoespaciais pelos órgãos da administração pública por meio da divulgação dos
metadados relativos a esses dados, disponíveis nas entidades e nos órgãos públicos
das esferas federal, estadual, distrital e municipal.
5.2 Estrutura de Dados Geoespaciais Digitais Vetoriais da MND
Integrando a INDE-Brasil, existe a MND, que é o conjunto de dados geoespaciais
devidamente estruturados, armazenados em repositórios distribuídos e compartilhados,
referentes ao espaço geográfico brasileiro. O acervo da MND é constituído por dados
referentes às informações geoespaciais produzidas pelo SCN e por dados de terceiros. No
caso dos dados de terceiros, estes são submetidos a uma auditoria técnica, para verificar a
compatibilidade com os padrões estabelecidos.
No início da década de 90 do século passado, com o crescimento do uso da tecnologia
digital, houve uma ruptura na padronização da produção cartográfica brasileira. As duas
instituições brasileiras responsáveis pelo mapeamento topográfico sistemático terrestre, o
Exército Brasileiro, através da DSG (Diretoria de Serviço Geográfico), e o IBGE (Instituto
Brasileiro de Geografia e Estatística), adotavam padronizações diferentes no processo de
produção cartográfica digital. Diante da necessidade de padronização e conseqüente
agregação dos dados digitais ao acervo da MND, a CONCAR, em 2004, iniciou discussões
67
para o desenvolvimento de um novo modelo, de modo a unificar os padrões de estrutura de
dados espaciais vetoriais (BORBA; MOTA; BRITO, 2008; CONCAR, 2007)
A CONCAR, em 2007, através da Subcomissão de Dados Espaciais (SDE) e do
Comitê de Estruturação da MND, lançou as Especificações Técnicas para a Estruturação de
Dados Geoespaciais Digitais Vetoriais (EDGV) para a MND. O objetivo da EDGV é
padronizar estruturas que viabilizem o compartilhamento de dados, a interoperabilidade e a
racionalização de recursos entre os produtos e usuários de dados e informações cartográficas
(CONCAR, 2007).
A EDGV utiliza o paradigma modelo OO, com modelagem conceitual baseada no
modelo OMT-G proposto por Borges (1997). O modelo conceitual proposto pela EDGV é
organizado em treze categorias: abastecimento de água e saneamento básico; administração
pública; educação e cultura; energia e comunicação; estruturas econômicas; hidrografia;
limites; localidades; pontos de referência; relevos; saúde e serviço social; sistema de
transporte; vegetação. Na EDGV, cada pacote contempla um diagrama de classes, em que
existem basicamente três tipos de classes (BORBA; MOTA; BRITO, 2008):
• Classes de feição – possuem geometria associada (ponto, linha, polígono);
• Classes agregadoras – não possuem geometria, somente agregam classes que
possuem geometria;
• Classes de domínio – não possuem geometria e não agregam outras classes,
simplesmente descrevem um conjunto de valores comuns. Podem ser referenciadas
por classes do tipo feição e agregadoras.
5.3 Procedimentos para a aplicação do estudo de caso
Para efetuar a aplicação do estudo de caso, foi definida uma série de etapas a seguir
(Figura 44):
1. Seleção do pacote EDGV em que seria efetuado o estudo de caso;
2. Modelagem do pacote dentro da ferramenta MDT/Papyrus com perfil OGC;
3. Conversão do modelo UML produzido para GML esquema, utilizando o plug-in
UML2GML;
4. Validação do GML esquema através da ferramenta parser Altova XMLSpy 2008;
5. Utilização do GML esquema validado para gerar outros produtos (documento
GML, aplicação GML esquema, esquema para banco de dados, dentre outros).
68
Figura 44. Etapas para aplicação do estudo de caso.
5.3.1 Seleção de pacote para o estudo de caso
A EDGV possui trezes categorias distintas, sendo que, em alguns casos, há
relacionamentos entre as categorias. Por exemplo: na categoria Vegetação, há o
relacionamento entre ela e a categoria Estrutura Econômica e, ainda, com a categoria
Hidrografia. Em termos práticos, isso gera uma grande gama de possibilidades de escolha de
categoria para uso em um estudo de caso. Diante desse fato, a presente dissertação definiu
alguns critérios de seleção de pacotes EDGV, enumerados a seguir:
• Complexidade moderada;
• Relevância no uso do modelo conceitual dentro da comunidade SIG;
• Disponibilidade de dados reais para popular o produto final gerado pelo GML
esquema.
Definir a complexidade de um modelo conceitual é subjetivo, porém, necessário,
devido a sua influência no produto final gerado e, por conseqüência, na análise dos resultados
do estudo de caso. Dessa forma, nesta dissertação, preferiu-se adotar critérios relativos à
quantidade de classes do modelo conceitual, uso de relacionamentos geoespaciais, e a
existência ou não de relacionamentos com outras categorias:
• Categoria com complexidade alta – categoria com mais de trinta classes, utiliza
todos os relacionamentos geoespaciais e não-espaciais disponíveis no modelo
OMT-G e possui relacionamento com mais de uma categoria da EDGV;
• Categoria com complexidade moderada – categoria com menos de trinta classes,
utiliza todos os relacionamentos geoespaciais e não-espaciais disponíveis no
69
modelo OMT-G e pode possuir um ou mais relacionamentos com outras categorias
da EDGV;
• Categoria com complexidade baixa – categoria com menos de quinze classes, não
utiliza todos os relacionamentos geoespaciais e atributos disponíveis no modelo
OMT-G e pode possuir nenhum ou mais de um relacionamento com outras
categorias.
O critério de relevância no uso do modelo conceitual dentro da comunidade SIG é
outro critério subjetivo. Contudo, também deve ser considerado, pois é através desse critério
que se emula, no estudo de caso, uma situação mais próxima da realidade da comunidade SIG
brasileira. Utilizar categorias amplamente usadas pela comunidade SIG do Brasil possibilita
ter parâmetros comparativos mais próximos da realidade de uso da ferramenta proposta pela
dissertação. Não se discute, nesse critério, a importância ou não de determinada categoria da
EDGV; apenas se define que serão utilizadas categorias mais empregadas por potenciais
usuários da ferramenta.
O último critério definido é o requisito de disponibilidade de dados reais para popular
o produto final gerado pelo GML esquema. A entrada de dados reais para popular um
documento GML gerado a partir de um GML esquema possibilita validar ou avaliar situações
de erros ou problemas de modelagem na EDGV em situação de uso real.
Com base nos critérios estabelecidos nesta dissertação para a seleção do pacote EDGV
a ser utilizado no estudo de caso, foi escolhido o pacote Relevo (Figura 45), por apresentar as
seguintes características:
• Complexidade moderada que se destaca por apresentar o uso de todas as primitivas
geométricas em sua modelagem conceitual;
• Largo uso dentro da comunidade SIG;
• Disponibilidade, pelo IBGE, de dados reais para a aplicação do estudo de caso.
70
Figura 45. Modelo conceitual original do pacote Relevo da EDGV. Fonte: CONCAR (2007).
71
5.3.2 Modelagem do pacote dentro da ferramenta Papyrus
Após a escolha do pacote EDGV, a próxima etapa consistiu na inserção do pacote
Relevo dentro da ferramenta Papyrus com perfil OGC. Durante esse processo, foi verificada a
presença de não-conformidades que poderiam interferir no processo de geração do documento
GML esquema. As não-conformidades identificadas no pacote Relevo EDGV são:
• Não-conformidade 1 - utilização de relacionamentos espaciais nas classes:
Curva_Batimetrica, Massa_Dagua, Ponto_Cotado_Batimetrico,
Ponto_Cotado_Altimetrico, Pico, Curva_Nivel e Dolina. Relacionamentos
geoespaciais não são suportados pela atual versão do GML (3.2.1); portanto, não
há como mapear grande parte dos relacionamentos apresentados no modelo
conceitual do pacote Relevo da EDGV em um GML esquema;
• Não-conformidade 2 - utilização da especialização disjunta total31, que é um
mecanismo da UML denominado restrição, empregado para melhor definir a
semântica de classes especializadas. A OGC (2007) não especifica nenhuma regra
de mapeamento para restrições UML;
• Não-conformidade 3 – utilização dos estereótipos <<Ponto>>, <<Linha>>,
<<Poligono>> sem considerar o conceito de herança de classes na modelagem
OO. Por exemplo, a superclasse Elemento_Fisiografico_Natural utiliza o
estereótipo <<Ponto>>, e a subclasse <<Rocha>> emprega o mesmo estereótipo
<<Ponto>>. O resultado, no GML esquema, é que uma entidade geográfica fica
associada a duas geometrias, o que não é permitido pela OGC (2007),
impossibilitando a validação do documento. Uma visualização do problema pode
ser conferida na Figura 46;
31 Na notação UML, uma especialização é disjunta quando uma instância de uma superclasse é membro de uma e somente uma das subclasses. Já uma especialização é total quando a união de todas as instâncias das subclasses equivale ao conjunto de instâncias da superclasse (BORGES; DAVIS JR; LAENDER, 2005).
72
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
<element name="Elemento_Fisiografico_Natural" type="tmp:Elemento_Fisiografico_NaturalType" substitutionGroup="gml:AbstractFeature" /> <complexType name="Elemento_Fisiografico_NaturalType"> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence> <!--A geometria ponto da superclasse é definida aqui--> <element ref="gml:Point"/> </sequence> </extension> </complexContent> </complexType> <element name="Rocha" type="tmp:RochaType" substitutionGroup="tmp:Elemento_Fisiografico_Natural" /> <complexType name="RochaType"> <complexContent> <extension base="tmp:Elemento_Fisiografico_NaturalType"> <sequence> <!-- A geometria ponto novamente é definida aqui na subclasse. Portanto, a subclasse tem associada a ela duas geometrias ponto: uma geometria herdada da superclasse, e outra geometria definida na subclasse. Se for utilizada uma ferramenta parser XML esquema neste documento, ele não será validado como GML esquema--> <element ref="gml:Point"/> </sequence> </extension> </complexContent> </complexType>
Figura 46. Exemplo da ocorrência da não-conformidade 3 no pacote Relevo e seu respectivo mapeamento para GML esquema.
• Não-conformidade 4 – no dicionário32 de dados do modelo, há a ocorrência de
atributos replicados em algumas superclasses e subclasses. Por exemplo, a
superclasse Elemento_Fisiografico_Natural tem todos os atributos replicados em
suas subclasses, com exceção do atributo tipoElemNata (atributo do tipo
alfanumérico, que indica o tipo de formação do relevo). Esse não é um
procedimento usual em um dicionário de dados de um modelo OO; por isso, foi
classificado como não-conformidade.
Após verificar todas as não-conformidades, o procedimento seguinte foi definir
protocolos para tratá-las na ferramenta Papyrus e viabilizar a geração do GML esquema do
pacote Relevo da EDGV. Os protocolos de tratamento para as não-conformidades são:
32 Nota do autor: o dicionário de dados do pacote Relevo está disponível para consulta no Anexo II deste trabalho.
73
• Protocolo de tratamento da não-conformidade 1 – Borges, Davis Jr. e Laender
(2005) descrevem que, no processo de mapeamento de diagramas de classes OMT-
G para bancos relacionais, é definido que em geral os relacionamentos
geoespaciais explicitados no modelo OMT-G (incluindo agregações espaciais) não
são materializados em esquemas físicos do banco. Por outro lado, constituem
declarações do relacionamento esperado entre instâncias das classes envolvidas e,
freqüentemente, denotam restrições de integridades geoespaciais. Partindo do
mesmo princípio, esta dissertação definiu que os relacionamentos espaciais do
pacote Relevo seriam convertidos para relacionamentos não-espaciais. A OGC
(2007) especifica que somente relacionamentos com extremidades navegáveis e
nomeadas podem ser mapeados para GML esquema. Diante desse fato,
estabeleceu-se que a navegabilidade dos relacionamentos fosse determinada pelo
sentido de leitura dos relacionamentos;
• Protocolo de tratamento da não-conformidade 2 – as restrições UML para
relacionamentos de generalização, especialização ou composição são regras
semânticas que agregam informações adicionais a um modelo conceitual. Porém,
essas informações adicionais não podem ser traduzidas na atual versão de um
documento GML. Portanto, adotou-se, como protocolo, ignorar as restrições UML
e aplicar as regras de conversão da OGC (2007) para relacionamentos de
agregação, especialização e composição;
• Protocolo de tratamento da não-conformidade 3 – adotou-se, como padrão, que as
subclasses com os estereótipos <<Linha>>, <<Ponto>> e <<Poligono>> já
definidos nas respectivas superclasses tivessem os estereótipos retirados. Somente
podem permanecer nas subclasses os estereótipos que ainda não foram utilizados
nas respectivas superclasses. Em resumo, a geometria definida na superclasse deve
ser seguida por suas subclasses;
• Protocolo de tratamento da não-conformidade 4 – foi definido que todos os
atributos replicados das superclasses nas respectivas subclasses seriam retirados.
Em outras palavras, uma vez definido um atributo na superclasse, fica explícito
que esse atributo está acessível para as subclasses (conforme definido pelo
conceito de herança da modelagem OO), não sendo, portanto, necessário replicar
esses atributos nas subclasses.
74
Após a aplicação dos protocolos de tratamento, outro fato a ser considerado é a
questão de mapear ou não as classes de outros pacotes EDGV dentro do modelo conceitual.
Essa questão não foi considerada uma não-conformidade, pois não interfere no resultado do
processo de conversão para GML esquema. A solução adotada foi desconsiderar essas classes
e não mapeá-las no documento GML esquema. A justificativa para esse procedimento é
simplificar o modelo conceitual e, por conseqüência, facilitar a análise do mesmo, além de
focar no tema escolhido para o estudo de caso. As classes desconsideradas foram: Vegetacao;
Ilhas; Trechos_Rodoviario e Trecho_Ferroaviaria; Barragem. As exceções para esse
procedimentos foram as classes Massa_Dagua e Limite_MassaDagua devido à quantidade de
dados reais disponíveis para essas classes.
Finalizados todos os procedimentos de preparação do pacote Relevo da EDGV, o
processo de modelagem na ferramenta Papyrus foi iniciado. O resultado final pode ser visto
na Figura 47, pronto para ser convertido para GML esquema através do plug-in UML2GML.
75
Figura 47. Modelo conceitual do pacote Relevo na ferramenta Papyrus.
76
5.3.3 GML esquema do estudo de caso
Após finalizar o processo de modelagem na ferramenta Papyrus do pacote
Relevo da EDGV, foi efetuado o processo de conversão do modelo UML produzido
para GML esquema. O resultado pode ser visto abaixo. O documento GML esquema
gerado em seguida passou pelo parser XML esquema, Altova XMLSpy 2008
Enterprise Edition. O resultado da análise da ferramenta retornou que o documento
esquema é “válido”.
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 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
<?xml version="1.0" encoding="UTF-8"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:tmp="http://www.univali.br/g10/concar_relevo" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gml="http://www.opengis.net/gml/3.2" targetNamespace="http://www.univali.br/g10/concar_relevo" elementFormDefault="qualified" version="1.0"> <!--=================================================--> <import namespace="http://www.opengis.net/gml/3.2" schemaLocation="gml/3.2.1/gml.xsd"/> <import namespace="http://www.w3.org/1999/xlink" schemaLocation="xlink/1.0.0/xlinks.xsd"/> <!--=================================================--> <element name="Curva_Batimetria" type="tmp:Curva_BatimetriaType" substitutionGroup="tmp:Isolinha_Hipsometrica"/> <complexType name="Curva_BatimetriaType"> <complexContent> <extension base="tmp:Isolinha_HipsometricaType"> <sequence> <element name="profundidade" type="integer"/> </sequence> </extension> </complexContent> </complexType> <complexType name="Curva_BatimetriaPropertyType"> <sequence minOccurs="0"> <element ref="tmp:Curva_Batimetria"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup"/> </complexType> <element name="Curva_nivel" type="tmp:Curva_nivelType" substitutionGroup="tmp:Isolinha_Hipsometrica"/> <complexType name="Curva_nivelType"> <complexContent> <extension base="tmp:Isolinha_HipsometricaType"> <sequence> <element name="geometriaAproximada" type="boolean"/> <element name="cota" type="integer"/> <element name="depressao" type="boolean"/> <element name="indice" type="string"/> </sequence> </extension> </complexContent> </complexType> <complexType name="Curva_nivelPropertyType"> <sequence minOccurs="0"> <element ref="tmp:Curva_nivel"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup"/> </complexType> <element name="Isolinha_Hipsometrica" type="tmp:Isolinha_HipsometricaType" abstract="true" substitutionGroup="gml:AbstractFeature"/> <complexType name="Isolinha_HipsometricaType"> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence> <choice> <element ref="gml:Curve"/> <element ref="gml:LineString"/> <element ref="gml:OrientableCurve"/> <element ref="gml:CompositeCurve"/> </choice>
77
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 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
</sequence> </extension> </complexContent> </complexType> <element name="Elemento_Fisiografico" type="tmp:Elemento_FisiograficoType" substitutionGroup="gml:AbstractFeature"/> <complexType name="Elemento_FisiograficoType"> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence> <choice> <element ref="gml:Curve"/> <element ref="gml:LineString"/> <element ref="gml:OrientableCurve"/> <element ref="gml:CompositeCurve"/> </choice> <element name="nome" type="string"/> <element name="geometriaAproximada" type="boolean"/> <element name="nomeAbrev" type="string"/> </sequence> </extension> </complexContent> </complexType> <element name="Elemento_Fisiografico_Natural" type="tmp:Elemento_Fisiografico_NaturalType" substitutionGroup="tmp:Elemento_Fisiografico"/> <complexType name="Elemento_Fisiografico_NaturalType"> <complexContent> <extension base="tmp:Elemento_FisiograficoType"> <sequence> <choice> <element ref="gml:Polygon"/> <element ref="gml:Solid"/> <element ref="gml:CompositeSolid"/> </choice> <element name="tipoEleNat" type="string"/> </sequence> </extension> </complexContent> </complexType> <complexType name="Elemento_Fisiografico_NaturalPropertyType"> <sequence minOccurs="0"> <element ref="tmp:Elemento_Fisiografico_Natural"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup"/> </complexType> <element name="Alteracao_Fisiografica_Antropica" type="tmp:Alteracao_Fisiografica_AntropicaType" substitutionGroup="tmp:Elemento_Fisiografico"/> <complexType name="Alteracao_Fisiografica_AntropicaType"> <complexContent> <extension base="tmp:Elemento_FisiograficoType"> <sequence> <element name="tipoAlterAntrop" type="string"/> </sequence> </extension> </complexContent> </complexType> <element name="Gruta_Caverna" type="tmp:Gruta_CavernaType" substitutionGroup="tmp:Elemento_Fisiografico_Natural"/> <complexType name="Gruta_CavernaType"> <complexContent> <extension base="tmp:Elemento_Fisiografico_NaturalType"> <sequence> <element ref="gml:Point"/> <element name="tipoGrutaCaverna" type="string"/> </sequence> </extension> </complexContent> </complexType> <element name="Duna" type="tmp:DunaType" substitutionGroup="tmp:Elemento_Fisiografico_Natural"/> <complexType name="DunaType"> <complexContent> <extension base="tmp:Elemento_Fisiografico_NaturalType"> <sequence> <element ref="gml:Point"/> <element name="fixa" type="boolean"/> </sequence> </extension> </complexContent> </complexType>
78
142 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 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222
<element name="Dolina" type="tmp:DolinaType" substitutionGroup="tmp:Elemento_Fisiografico_Natural"/> <complexType name="DolinaType"> <complexContent> <extension base="tmp:Elemento_Fisiografico_NaturalType"> <sequence> <element ref="gml:Point"/> </sequence> </extension> </complexContent> </complexType> <complexType name="DolinaPropertyType"> <sequence minOccurs="0"> <element ref="tmp:Dolina"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup"/> </complexType> <element name="Fenda_Falha" type="tmp:Fenda_FalhaType" substitutionGroup="tmp:Elemento_Fisiografico_Natural"/> <complexType name="Fenda_FalhaType"> <complexContent> <extension base="tmp:Elemento_Fisiografico_NaturalType"> <sequence> <element name="tipoFendaFalha" type="string"/> </sequence> </extension> </complexContent> </complexType> <element name="Escapa_Talude" type="tmp:Escapa_TaludeType" substitutionGroup="tmp:Elemento_Fisiografico_Natural"/> <complexType name="Escapa_TaludeType"> <complexContent> <extension base="tmp:Elemento_Fisiografico_NaturalType"> <sequence> <element name="tipoEscapaTalude" type="string"/> </sequence> </extension> </complexContent> </complexType> <element name="Rocha" type="tmp:RochaType" substitutionGroup="tmp:Elemento_Fisiografico_Natural"/> <complexType name="RochaType"> <complexContent> <extension base="tmp:Elemento_Fisiografico_NaturalType"> <sequence> <element ref="gml:Point"/> <element name="tipoRocha" type="string"/> </sequence> </extension> </complexContent> </complexType> <element name="Pico" type="tmp:PicoType" substitutionGroup="tmp:Elemento_Fisiografico_Natural"/> <complexType name="PicoType"> <complexContent> <extension base="tmp:Elemento_Fisiografico_NaturalType"> <sequence> <element ref="gml:Point"/> </sequence> </extension> </complexContent> </complexType> <complexType name="PicoPropertyType"> <sequence minOccurs="0"> <element ref="tmp:Pico"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup"/> </complexType> <element name="Ponto_Hipsometria" type="tmp:Ponto_HipsometriaType" abstract="true" substitutionGroup="gml:AbstractFeature"/> <complexType name="Ponto_HipsometriaType"> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence> <element ref="gml:Point"/> </sequence> </extension> </complexContent> </complexType>
79
223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303
<element name="Ponto_Cotado_Altimetro" type="tmp:Ponto_Cotado_AltimetroType" substitutionGroup="tmp:Ponto_Hipsometria"/> <complexType name="Ponto_Cotado_AltimetroType"> <complexContent> <extension base="tmp:Ponto_HipsometriaType"> <sequence> <element name="geometriaAproximada" type="boolean"/> <element name="cotaComprovada" type="boolean"/> <element name="cota" type="string"/> </sequence> </extension> </complexContent> </complexType> <complexType name="Ponto_Cotado_AltimetroPropertyType"> <sequence> <element ref="tmp:Ponto_Cotado_Altimetro"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup"/> </complexType> <element name="Ponto_Cotado_Batimetrico" type="tmp:Ponto_Cotado_BatimetricoType" substitutionGroup="tmp:Ponto_Hipsometria"/> <complexType name="Ponto_Cotado_BatimetricoType"> <complexContent> <extension base="tmp:Ponto_HipsometriaType"> <sequence> <element name="profudidade" type="string"/> </sequence> </extension> </complexContent> </complexType> <element name="Massa_Dagua" type="tmp:Massa_DaguaType" substitutionGroup="gml:AbstractFeature"/> <complexType name="Massa_DaguaType"> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence> <choice> <element ref="gml:Polygon"/> <element ref="gml:Solid"/> <element ref="gml:CompositeSolid"/> </choice> <element name="nome" type="string"/> <element name="geometriaAproximada" type="boolean"/> <element name="tipoMassaAgua" type="string"/> <element name="regime" type="string"/> <element name="salidanidade" type="string"/> <element name="nomeAbrev" type="string"/> <element name="limite_Massa_Dagua" type="tmp:Limite_Massa_DaguaPropertyType" minOccurs="0" maxOccurs="unbounded"> <annotation> <appinfo> <gml:reverseProperty>tmp:massa_Dagua</gml:reverseProperty> </appinfo> </annotation> </element> </sequence> </extension> </complexContent> </complexType> <complexType name="Massa_DaguaPropertyType"> <sequence minOccurs="0"> <element ref="tmp:Massa_Dagua"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup"/> </complexType> <element name="Limite_Massa_Dagua" type="tmp:Limite_Massa_DaguaType" substitutionGroup="gml:AbstractFeature"/> <complexType name="Limite_Massa_DaguaType"> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence> <choice> <element ref="gml:Curve"/> <element ref="gml:LineString"/> <element ref="gml:OrientableCurve"/> <element ref="gml:CompositeCurve"/> </choice> <element name="geometriaAproximada" type="boolean"/>
80
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
<element name="tipoLimMassa" type="string"/> <element name="materialPredominante" type="string"/> <element name="alturaMediaMargem" type="string"/> <element name="nomeAbrev" type="string"/> <element name="massa_Dagua" type="tmp:Massa_DaguaPropertyType" minOccurs="0" maxOccurs="unbounded"> <annotation> <appinfo> <gml:reverseProperty>tmp:limite_Massa_Dagua</gml:reverseProperty> </appinfo> </annotation> </element> </sequence> </extension> </complexContent> </complexType> <complexType name="Limite_Massa_DaguaPropertyType"> <sequence minOccurs="0"> <element ref="tmp:Limite_Massa_Dagua"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> <attributeGroup ref="gml:OwnershipAttributeGroup"/> </complexType> <element name="Trecho_Massa_Dagua" type="tmp:Trecho_Massa_DaguaType" substitutionGroup="tmp:Massa_Dagua"/> <complexType name="Trecho_Massa_DaguaType"> <complexContent> <extension base="tmp:Massa_DaguaType"> <sequence> <element name="tipoTrechoMassa" type="string"/> </sequence> </extension> </complexContent> </complexType> </schema>
5.3.4 Exemplo de produto gerado a partir do GML esquema
Relevo
Um desenvolvedor pode produzir vários produtos a partir de um GML esquema,
tais como documentos GML, esquemas de BDG e aplicações GML esquema (aplicação
desktop, móvel ou Web que usualmente tem parte do seu código gerado a partir de um
GML esquema). Para a presente dissertação, a título de exemplo, é apresentado, na
Figura 48, um documento GML gerado a partir do GML esquema do pacote Relevo. No
caso, os dados são reais: a região retratada é a Lagoa da Conceição, na cidade de
Florianópolis, estado de Santa Catarina, Brasil.
O documento GML exemplo foi produzido a partir de uma aplicação GML
esquema desktop. Essa aplicação exemplo recebe, como entrada, os dados reais, e
produz, como saída, o documento GML devidamente validado a partir do esquema do
pacote Relevo da EDGV. Outro ponto a destacar é que essa aplicação também teve
parte do seu código gerado a partir do GML esquema do pacote Relevo. Para tanto, foi
utilizada a ferramenta Apache XMLBeans33 (versão 2.4), que produz toda a estrutura de
33 http://xmlbeans.apache.org/
81
dados uma aplicação em linguagem Java a partir de um XML esquema. A visualização
gráfica do documento GML foi obtida com o software Gaia 334, um visualizador de
arquivos GML.
<?xml version="1.0" encoding="UTF-8"?> <gml:FeatureCollection gml:id="ID_1" xsi:schemaLocation="http://www.univali.br/g10/concar_relevo concar_relevo.xsd" xmlns:con="http://www.univali.br/g10/concar_relevo" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <gml:description>Estudo de caso CONCAR Relevo</gml:description> <gml:boundedBy> <gml:Envelope srsName="UTM69-22S" srsDimension="2"> <gml:lowerCorner>746418.845898339 6927449.8</gml:lowerCorner> <gml:upperCorner>771685.9 6955680.57144168</gml:upperCorner> </gml:Envelope> </gml:boundedBy> <gml:featureMember> <con:Massa_Dagua gml:id="ad1010"> <gml:Polygon gml:id="ad2020"> <gml:exterior> <gml:LinearRing> <gml:posList srsDimension="2" srsName="UTM69-22S">747032.7 6953343.9 747071.4 6953374.5 747090.7 6953397 747104.6 6953437.2 747119.4 6953501 747135.4 6953542.6 747159 6953586.6 747173.8 6953608 747208.4 6953644.9 747232.9 6953661.3 747245.1 6953673.3 747314.374112811 6953714.10300237 747400.1 6953736.4 747412.5 6953737.5 747425.8 6953730.8 747428.6 6953724.9 747427.5 6953715 747418.5 6953687.5 747365.4 6953605.4 747292.1 6953418.6 747270.2 6953372.7 747244.1 6953328.9 747229.6 6953311.3 747179 6953261.6 747162 6953236 747134.1 6953172.4 747086.8 6953013.3 747073.6 6953003.2 747063.1 6953000.1 747048 6953014.8 747018.7 6953065.1 747004.4 6953110.1 747002 6953132.5 746984.1 6953218.8 746980.9 6953248.3 746992 6953297.9 747032.7 6953343.9</gml:posList> </gml:LinearRing> </gml:exterior> </gml:Polygon> <con:nome>Oceano Atlântico</con:nome> <con:geometriaAproximada>false</con:geometriaAproximada> <con:tipoMassaAgua>Oceano</con:tipoMassaAgua> <con:regime>Permanente</con:regime> <con:salidanidade>Salgada</con:salidanidade> <con:nomeAbrev>OA</con:nomeAbrev> </con:Ponto_Cotado_Altimetro> </gml:featureMember> </gml:FeatureCollection>
Figura 48. Trecho do documento GML exemplo gerado a partir do GML esquema do pacote Relevo. Parte superior: visualização gráfica do documento GML completo.
34 http://www.thecarbonproject.com/gaia.php
82
5.4 Considerações finais
Ao submeter a ferramenta proposta por esta dissertação a condições reais
proporcionadas por um estudo de caso, consegue-se simular situações de uso do dia-a-
dia de um desenvolvedor de GML esquemas. Submetida ao “estresse” de uma situação
real de uso, tanto as vantagens, quanto as desvantagens da ferramenta ficam evidentes.
Aplicar uma ferramenta a um estudo de caso possibilita definir o limite de uso
da mesma, seja esse limite imposto pelos conceitos dos modelos conceituais OO, seja
pelas tecnologias empregadas na construção da ferramenta ou pelos padrões adotados
pela comunidade SIG. Neste capítulo, somente com a definição dos limites do plug-in
UML2GML, pôde-se verificar situações que impediam que os modelos conceituais
propostos pela CONCAR (2007) pudessem ser convertidos para GML esquemas
válidos. Mais detalhes sobre as não-conformidades e as soluções adotadas neste
trabalho podem ser vistos no capítulo subseqüente.
83
6 RESULTADOS E DISCUSSÕES
6.1 Plug-in UML2GML
O processo de implementação do plug-in UML2GML mostrou uma tendência de
mudança de papel dos modelos UML no desenvolvimento de sistemas. Os modelos
UML deixam de exercer somente a função de documentar o processo de
desenvolvimento e passam também a exercer o papel de ferramenta geradora de código.
Isso ocorre através das tecnologias e conceitos MDA, automatizando parte do processo
de implementação de aplicações.
O próprio plug-in UML2GML teve parte significativa de seu código gerada com
ajuda da tecnologia MDA, disponibilizada principalmente pelo projeto Modeling da
Fundação Eclipse (GMF, EMF, JET e Papyrus). Com essa abordagem, o esforço de
programação foi concentrado onde era realmente crítico: o processo de implementação
das regras da ISO/DIS 19136. Outro fato interessante é que o plug-in UML2GML
também pode ser considerado uma ferramenta MDA, uma vez que, a partir de um
modelo UML, o plug-in gera automaticamente um código - no caso, no formato GML
esquema.
Como já declarado, a parte crítica do desenvolvimento do plug-in foi
implementar métodos de programação para conversão de elementos UML, seguindo as
regras da norma ISO/DIS 19136. Para a presente dissertação, a grande questão foi como
lidar com as regras omissas, ou seja, não era exposto, nas regras, o procedimento a ser
adotado para mapear certos elementos UML. Os dois casos omissos foram:
• Classes que utilizam estereótipos definidos no perfil UML do plug-in;
• Disponibilização, pela série ISO 19100, de diferentes entidades para
representar a mesma geometria de uma classe.
No primeiro caso, a solução adotada foi a proposta por Hess (2004), isto é, a
transformação do estereótipo em atributo da classe. Essa solução se mostrou satisfatória
durante o processo de implementação e teste do estudo de caso, gerando GML
esquemas válidos e consistentes. No segundo caso, a solução adotada foi bastante
similar ao primeiro, também gerando, durante a implementação do estudo de caso,
GML esquemas válidos e consistentes. É importante salientar que, caso não fosse
adotada nenhuma solução para as duas omissões, o modelo UML geraria um GML
84
esquema válido. Porém, haveria perda de informações do modelo original para o GML
esquema.
Há outra solução para o segundo caso, mas não foi adotada devido a sua maior
complexidade, que envolveria a utilização de tags no perfil UML do plug-in. Outra
desvantagem na adoção dessa solução com tags é que o GML esquema gerado a partir
dessa solução seria menos versátil. Nesta solução, o desenvolvedor que utilizaria esse
esquema teria menos opções de geometrias para uma entidade geográfica, uma vez que
a geometria seria definida em uma tag no modelo conceitual, e não mais no momento
em que o desenvolvedor fosse usar o GML esquema.
O mecanismo de extensão UML utilizado neste trabalho foi um perfil
denominado perfil OGC, que disponibiliza tipos e estereótipos GML empregados no
editor UML do Papyrus. A implementação do perfil foi feita usando o próprio editor
UML da ferramenta Papyrus, que já disponibiliza uma ferramenta para que o perfil
UML seja integrado à estrutura do plug-in de forma transparente. O acesso e a
manipulação dos tipos e estereótipos criados no perfil OGC foram feitos utilizando o
framework EMF. Durante a implementação do estudo de caso, o perfil OGC se mostrou
extremamente funcional, principalmente com a implementação dos acessos rápido em
estilo Palette dos estereótipos que representam geo-objetos (<<Linha>>, <<Ponto>> e
<<Poligono>>). Todos os GML esquemas gerados a partir de modelos conceituais que
empregaram esse perfil foram considerados válidos e consistentes.
A integração do módulo de conversão de UML para GML, o perfil OGC e a
ferramenta Papyrus foi feita através dos recursos da ferramenta PDE do próprio Eclipse.
O PDE também disponibiliza soluções para a questão de dependência de bibliotecas do
plug-in UML2GML.
6.2 Estudo de caso
A realização do estudo de caso utilizando um modelo conceitual proposto pela
CONCAR (2007) foi feita basicamente em cinco etapas (descritas no tópico 5.3 desta
dissertação). Segue uma avaliação dos resultados obtidos em cada etapa:
1. Seleção do pacote EDGV para a realização do estudo de caso – o pacote
selecionado foi o do tema Relevo, que atendeu a todos os requisitos
estabelecidos por esta dissertação (complexidade, relevância do tema e
disponibilidade de dados reais);
85
2. Modelagem do pacote EDGV dentro da ferramenta Papyrus – o processo
inicialmente não foi bem-sucedido devido à ocorrência de quatro não-
conformidades (Quadro V), as quais poderiam impedir o processo de
transformação do modelo UML em GML esquema. Após a correção das
não-conformidades do modelo conceitual Relevo, o processo de modelagem
foi refeito com sucesso;
3. Conversão do modelo UML produzido para GML esquema, utilizando o
plug-in UML2GML – efetuado com sucesso;
4. Validação do GML esquema através de uma ferramenta parser XML
esquema – o resultado da ferramenta parser Altova XMLSpy 2008
Enterprise Edition retornou o documento GML esquema como válido;
5. Utilização do GML esquema validado para gerar outros produtos – o produto
selecionado foi um documento GML gerado com a ferramenta Apache
XMLBeans, sendo a validação feita pela ferramenta. Para a visualização
gráfica do documento, foi utilizada a ferramenta Gaia 3 Viewer.
A proposta desta dissertação, ao trabalhar com o estudo de caso, foi bem-
sucedida, haja vista que foi possível, através desse procedimento, avaliar e validar todos
os recursos do plug-in UML2GML em uma situação real de uso. Entretanto, o modelo
conceitual Relevo proposto pela CONCAR (2007), em um primeiro momento, não pôde
ser convertido para um GML esquema válido, devido à ocorrência das quatro não-
conformidades supracitadas. No Quadro V, pode ser vista a relação de não-
conformidades encontradas no modelo conceitual Relevo e seus respectivos protocolos
de correção. Pode-se concluir, analisando o Quadro V, que o modelo conceitual Relevo,
em sua forma original, utilizando a norma de conversão da ISO/DIS 19136, não gera
um GML esquema válido. No entanto, deve-se lembrar que a proposta da CONCAR
(2007) para seus modelos conceituais não previu a utilização destes na produção de
GML esquemas.
86
Quadro V. Relação de não-conformidades encontradas no modelo conceitual Relevo e seus respectivos protocolos de correção.
Causa ISO/DIS 19136 Erro do modelo conceitual Erro do plug-in Procedimento de correção Perda de informação
Não-conformidade 1
Utilização de relacionamentos espaciais. Documentos GML versão 3.2.1 ainda não suportam relacionamentos espaciais.
Não especifica nenhum procedimento de mapeamento para esse tipo de relacionamento.
Não; o modelo OMT-G oferece suporte a relacionamentos espaciais de acordo com Borges (1997).
Não; o plug-in segue o que definem as regras de conversão, que, neste caso, são omissas. Portanto, o plug-in ignora o relacionamento.
Relacionamentos espaciais são transformados em relacionamentos simples. A navegabilidade do relacionamento é definida pelo sentido de leitura do relacionamento, procedimento este baseado no descrito por Borges, Davis Jr. e Laender (2005).
Há perda de informação, mas não total. Ao transformar relacionamentos espaciais em relacionamentos simples, perde-se a semântica do relacionamento espacial; porém, o relacionamento físico entre as entidades é preservado.
Não-conformidade 2
Utilização da restrição UML no relacionamento do tipo especialização disjunta total.
Não especifica nenhum procedimento de mapeamento para esse tipo de relacionamento.
Não; é um mecanismo semântico válido para modelos UML.
Não; o plug-in segue o que definem as regras de conversão, considerando um relacionamento do tipo especialização comum.
Há duas opções de correção: uma com uma abordagem conservadora e outra com uma abordagem mais radical. A abordagem conservadora seria não efetuar nenhum tipo de correção. A abordagem mais radical envolveria o acréscimo de uma classe com o estereótipo <<Union>>, englobando todas as classes envolvidas no relacionamento de especialização disjunta como atributos dessa nova classe. A abordagem utilizada nesta dissertação foi conservadora, pois a abordagem radical poderia descaracterizar e muito o modelo conceitual original, o que não é o objetivo do estudo de caso. Contudo, ambas as abordagens são válidas.
Na correção conservadora, sim; porém, não tanta, já que, por si só, todo relacionamento de especialização é do tipo total. Por sua vez, na correção radical, não haveria perda de informação.
Não-conformidade 3
Utilização dos estereótipos <<Ponto>>, <<Linha>> e <<Poligono>>, sem considerar o conceito de herança de classes na modelagem OO.
Somente estereótipos definidos na norma são considerados.
Não, uma vez que o documento proposto pela CONCAR (2007) tem o objetivo de documentar especificações. Caso fosse um modelo conceitual para uma aplicação real, estaria incorreto.
Não; o plug-in segue o que definem as regras de conversão, considerando um relacionamento do tipo herança.
As subclasses com os estereótipos <<Linha>>, <<Ponto>> e <<Poligono>> já definidos nas respectivas superclasses teriam os estereótipos retirados.
Não.
Não-conformidade 4
No dicionário de dados do modelo conceitual Relevo, há a ocorrência de atributos replicados em algumas superclasses e subclasses.
Situação não pertinente à norma.
Sim, provavelmente causado pela ferramenta utilizada na produção do dicionário de dados.
Não; considera atributos de classes.
Não foi efetuado nenhum procedimento de correção. Não.
87
Fica evidente, ao analisar a EDGV, a forma didática em que os temas foram
modelados. Em outras palavras, as abstrações utilizadas nos modelos privilegiam mais o
entendimento do tema, do que a aplicabilidade do modelo em um sistema de informação. O
mérito ou não de se utilizar tal abstração em um documento de especificação de órgão federal
não está no escopo desta dissertação. Contudo, à luz das diretivas da INDE-Brasil, deve-se
considerar a importância do documento GML como instrumento de interoperabilidade, seja
por uso direto, seja por acesso WFS35. Portanto, a questão de possibilitar a utilização da
tecnologia GML esquema nas propostas de modelos conceituais da CONCAR deve ser
revista/considerada pela mesma, haja vista que os modelos EDGV, no estado atual, não
viabilizam a geração dessa importante ferramenta de intercâmbio de dados geoespaciais.
Após o processo de correção das não-conformidades do modelo conceitual Relevo da
EDGV, o mesmo foi convertido para GML esquema novamente. O processo de análise do
parser XML esquema resultou em “documento esquema válido”. Em seguida, foi gerado um
documento GML a partir do novo esquema validado. Uma análise do documento GML
levanta uma questão pertinente: houve perda de informações do modelo conceitual durante o
processo de conversão para GML esquema? Analisando o GML esquema produzido e as não-
conformidades tratadas no modelo original, a resposta é positiva. Quando se leva em conta
que o modelo conceitual original não foi modelado com o objetivo de produzir um GML
esquema, a perda de informações do modelo é maximizada. Por outro lado, um modelo
conceitual modelado desde o princípio com o objetivo de gerar um GML esquema poderia
diminuir a perda de informações ou mesmo eliminá-la.
35 Web Feature Service - especificação de serviço OGC que possibilita a visualização de informações geográficas pela Internet.
88
7 CONSIDERAÇÕES FINAIS
7.1 Conclusões
O plug-in proposto por esta dissertação gera um GML esquema a partir de um modelo
UML. A avaliação e o teste do plug-in foram realizados com a ajuda de um estudo de caso -
no caso, um modelo conceitual proposto pela CONCAR (2007). Durante o processo de
conversão, o GML esquema gerado não era válido devido à existência de não-conformidades
no modelo conceitual original. As não-conformidades foram corrigidas, e o processo
recomeçou, sendo que, no final, o GML esquema gerado foi analisado como válido. O
procedimento de alterar o modelo conceitual original levanta algumas questões que devem
respondidas por esta dissertação:
• O plug-in proposto pela dissertação pode ser considerado validado, já que gerou o
GML esquema válido somente após o modelo conceitual ser alterado?
• As correções efetuadas alteraram a semântica do modelo original?
A resposta para o primeiro questionamento é positiva: o plug-in UML2GML pode ser
considerado válido. O que inviabilizou o processo de conversão foi o modelo conceitual
original, que apresentava características que não permitiram a sua validação no formato GML
esquema. Neste caso, o que deve ser revisto é o uso de modelos conceituais da EDGV da
MND como referência ao desenvolvimento de GML esquemas, e as implicações práticas que
isso pode ter na implantação do INDE-Brasil, tanto, por exemplo, na modelagem de BDG,
como na interoperabilidade de dados geográficos. Ou seja, a preocupação quanto à
consistência para integração de dados deve ser considerada.
A resposta para o segundo questionamento também é positiva: houve perda da
semântica original do modelo conceitual, principalmente em relação a informações sobre os
relacionamentos geoespaciais, conforme comentado anteriormente. Se essa perda foi ou não
significativa, depende do uso que se fará do GML esquema. Por exemplo: se o GML esquema
for utilizado para gerar um documento GML, a perda de informação pode ser considerada
pequena ou inexistente, pois a principal função desse tipo de documento é armazenar ou
transportar informações geográficas. Em outras palavras, usualmente, documentos GML são
utilizados em um nível físico da aplicação; nesse nível, as informações pertinentes a
relacionamentos geoespaciais não são utilizadas, sendo, portanto, desnecessárias para essa
89
finalidade. Porém, se o GML esquema for utilizado para gerar, por exemplo, o código Java36
de uma aplicação (logo, um nível lógico da aplicação), a informação referente aos
relacionamentos espaciais é importante, pois constitui declarações do relacionamento
esperado entre instâncias das classes envolvidas e freqüentemente denotam restrições de
integridade espaciais (BORGES; DAVIS JR.; LAENDER, 2005).
O plug-in UML2GML validado, como exposto no estudo de caso, é uma ferramenta
que facilita o processo de desenvolvimento de um GML esquema. Entretanto, de maneira
alguma garante que o GML esquema atenderá os requisitos da aplicação-alvo. Essa
responsabilidade é do desenvolvedor, que deve considerar os seguintes fatos na fase de
modelagem conceitual do GML esquema:
• Ao utilizar modelos conceituais de terceiros, como os propostos pela CONCAR
(2007), deve-se considerar que o objetivo inicial do modelo pode não ser gerar
GML esquemas. Portanto, não-conformidades podem ocorrer, e suas eventuais
correções podem alterar a semântica do modelo original, propagando erros em
efeito cascata, até os produtos que eventualmente utilizem esse GML esquema;
• Produtos de GML esquema próximo do nível físico da aplicação, como
documentos GML e shapefile37 (formato vetorial de dados geográficos), estão
menos propensos aos efeitos de perda de informação do modelo conceitual
original;
• O produto esquemas de BDG também são menos suscetíveis ao problema de perda
de informações do modelo conceitual, pois também estão em um nível físico da
aplicação. No entanto, é preciso que, no modelo conceitual UML, sejam definidos
alguns atributos a mais nas classes, os quais representariam as chaves primárias e
estrangeiras das tabelas do banco de dados. Nos modelos conceituais propostos
pela CONCAR (2007), não há definição de chaves para uso em banco de dados. Já
nos modelos conceituais propostos pela ANA (2006), estão definidas tanto as
chaves primárias, quanto as estrangeiras nas classes. A conversão de GML
esquema para esquema de banco de dados pode ser feita das seguintes formas:
o Proposta de Borba, Mota e Brito (2008) - nessa abordagem, todos os
elementos do GML esquema são agrupados em única tabela do banco de
dados, e os relacionamentos espaciais são ignorados;
36 Nota do autor: isso pode ser feito utilizando a ferramenta Apache XMLBeans. 37 Nota do autor: a conversão de GML para shapefile pode ser feita utilizando a ferramenta comercial FME (Feature Manipulation Engine). Uma versão trial está disponível em http://www.safe.com/.
90
o Proposta de Borges, Davis Jr. e Laender (2005) – abordagem para
conversão do modelo conceitual OMT-G para esquema de banco de dados
geográficos. Essa abordagem tem uma desvantagem: é teórica, pois exige a
adaptação das regras propostas pelos autores para GML esquema;
o Ferramenta open source FWTools 2.0.638, um conjunto de programas
voltados para o desenvolvimento de aplicações SIG. Um dos programas
que compõe a FWTools é o ogc2ogr que possibilita a importação de dados
de um documento GML para os BDG PostGIS e MySQL com extensão
GIS. Deve-se destacar que nesta solução é necessário gerar um documento
GML a parti do GML esquema desejado e ainda popular esse documento
com dados, somente após realizar esse processo é possível importar o
documento GML para o BDG;
o Ferramenta comercial Snowflake Go Loader39, disponível apenas para o
BDG Oracle Spatial40.
• Produtos de GML esquema próximo do nível lógico da aplicação, como código de
programação, seja para aplicação desktop, móvel ou Web, são propensos aos
efeitos de perda de informação do modelo conceitual original;
• Nada impede a utilização de modelos de dados geográficos (OMT-G e UML-
Geoframe) no processo de modelagem de GML esquemas. Contudo, é inevitável a
ocorrência de não-conformidades no modelo conceitual original.
A adoção da tecnologia MDA no desenvolvimento de software é uma tendência. Não
se justificativa a não-utilização dessa ferramenta pelos desenvolvedores de SIG, dado que sua
adoção traz inúmeros benefícios (agilidade no desenvolvimento, qualidade do produto gerado,
busca por consistência, facilidade de manutenção, dentre outros). Porém, não basta somente
adotar a tecnologia. É necessário que o desenvolvedor de SIG adote o conceito de MDA,
porque, no conceito MDA, o papel da UML mudou de instrumento de documentação para
ferramenta geradora de código. Nesse novo paradigma, a qualidade do código produzido está
diretamente relacionada à qualidade do processo de modelagem do modelo UML da
aplicação. Esse fato foi comprovado nos resultados obtidos pela presente dissertação.
38 http://fwtools.maptools.org/ 39 http://www.snowflakesoftware.co.uk/products/goloader/ 40 http://www.oracle.com/technology/products/spatial/index.html
91
7.2 Recomendações
Para dar continuidade ao presente trabalho, seguem algumas recomendações:
• Ampliar a quantidade de testes da ferramenta. Há um grande número de variações
em modelos conceituais UML que pode afetar as regras da ISO/DIS 19136, a qual
omite certos pontos em suas regras. Todas essas variações devem ser testadas, e o
GML esquema gerado deve ser validado;
• Aprimoramento do perfil UML proposto por esta dissertação, o perfil OGC, e
inclusão de novos tipos GML. Na versão atual do perfil, foram implementados os
tipos simples (integer, float, string, Date e assim por diante) e os tipos básicos do
pacote Geometry (GM_Point, GM_Solid, GM_Curve, dentre outros). O restantes
dos pacotes de tipos devem ser implementados (Topology, Time, Coordinate
Reference System, Datum, etc.). Deve ser considerada a criação de novos
estereótipos, como estereótipos representando geo-objetos com geometria e
topologia (objetos que possuem propriedades geométricas e propriedades
topológicas);
• Implementar a capacidade do plug-in de efetuar auditoria no modelos conceituais,
ou seja, identificar não-conformidades, além de sugerir soluções ao usuário de
como corrigir não-conformidades;
• Implementar a capacidade de engenharia reversa, ou seja, a partir de um GML
esquema, é gerado um modelo UML. Esse processo de decodificação é descrito no
Anexo F da norma ISO/DIS 19136 (OGC, 2007);
• Pesquisar uma futura integração com as ferramentas SIG OpenJump e uDig;
• Pesquisar o uso de Ontologia para determinar a equivalência semântica entre GML
esquemas (FROZZA, 2007). O uso dessa tecnologia permitiria a interoperabilidade
entre diferentes GML esquemas.
92
REFERÊNCIAS
ANA. Topologia hídrica: método de construção e modelagem da base hidrográfica para suporte à gestão de recursos hídricos (versão 1.11). Agência Nacional de Águas, Superintendência de Gestão da Informação. Brasília: SGI, 2006. 29p. ANISZCZYK, C. & GALLARDO, D. Get started with the Eclipse platform. 2007. Disponível em: <http://www.ibm.com/developerworks/opensource/library/os-eclipse-platform/>. Acesso em: 27 out. 2008. BÉDARD, Y. Visual modelling of spatial databases: towards spatial PVL and UML. Geomatica, v.53, n.2, p.169-186, 1999. BELIX, J. E. Um estudo sobre MDA: suporte fornecido pela UML e reuso de soluções pré-definidas. 2006. 127f. Dissertação de mestrado - Escola Politécnica da Universidade de São Paulo, Departamento de Engenharia de Computação e Sistemas Digitais, Universidade de São Paulo, 2006. BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. 2. ed. rev. Rio de Janeiro: Elsevier, 2006. p.474.
BORBA, R. L. R; MOTA, G. L. A.; BRITO, J. L. N. S. Metodologia para representação da Estrutura de Dados Geoespacial Vetorial da Mapoteca Nacional Digital em bancos de dados geográficos relacionais. In: SIMPÓSIO BRASILEIRO DE GEOINFORMÁTICA, X, 2008, Rio de Janeiro. BORGES, K. A. V.; DAVIS JR., C. A; LAENDER, A. H. F. Modelagem conceitual de dados geográficos. In: CASANOVA, M. A. et al. (Org.). Bancos de dados geográficos. Curitiba: MundoGeo, 2005. BORGES, K. A. V. Modelagem de dados geográficos: uma extensão do modelo OMT para aplicações geográficas. 1997. Dissertação de mestrado - Fundação João Pinheiro, Belo Horizonte, 1997. ______ & FONSECA, F. T. Modelagem de dados geográficos em discussão. In: GIS BRASIL 96, 1996, Curitiba. Anais... p.525-532. BRASIL. Decreto n° 6.666, de 27 de novembro de 2008. Institui, no âmbito do Poder Executivo federal, a Infraestrutura Nacional de Dados Espaciais - INDE, e dá outras providências. Disponível em: <http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6666.htm>. Acesso em: 21 jan. 2009. CÂMARA, G. Representação computacional de dados geográficos. In: CASANOVA, M. A. et al. (Org.). Bancos de dados geográficos. Curitiba: MundoGeo, 2005. CASTRO, A. F. et al. Desenvolvimento e aplicação de um Banco de Dados Geográficos na elaboração de mapas da morfodinâmica costeira e sensibilidade ambiental ao derramamento de óleo em áreas costeiras localizadas no estado do Rio Grande do Norte. Revista Brasileira de Geociências, 33 (2-Suplemento), p.53-64, 2003.
93
CONCAR. Comissão Nacional de Oceanografia. 2009. Disponível em: <http://www.concar.ibge.gov.br>. Acesso em: 21 jan. 2009. ______. 2007. Especificações técnicas para Estruturação de Dados Geoespaciais Digitais Vetoriais (versão 2.0). NCB-CC/E 0001A07. p.207. DATE, C. J. Introdução a sistema de banco de dados. Rio de Janeiro: Campus, 2000. p.804. DAVIS JR., C. A. Modelagem de dados geográficos (parte I). InfoGeo, Curitiba, v.1(2), p.38-40, 1. jul. 1998. DOEDERLEIN, O. P. Eclipse 3.3: novidades no Núcleo. Revista Java Magazine, n.47, ano V, p.14-23, 2007. EBERLE, S. & BOSCH, R. MDT Engineering with Eclipse and EMF. 2006. Disponível em: <http://www.ias.uni-stuttgart.de/vorlesungen/rv/vorlesung/WS0607/4_Ringvorlesung_Eberle.pdf>. Acesso em: 20 jan. 2009. ECLIPSE. Eclipse modeling project. 2008. Disponível em: <http://www.eclipse.org/modeling/>. Acesso em: 27 de out. 2008. FAUCHER C. & LAFAYE, J. Y. Model-Driven Engineering for implementing the ISO 19100 series of international standards. In: COASTGIS’07, 8., 2007, Santander, Espanha. Proceedings... p.424-433. FERRARINI, A. Model Driven Architecture (MDA). Revista Mundo Java, Curitiba, n.27, ano V, p.44-49, 2008. FROZZA, A. A. Um método para determinar a equivalência semântica entre esquemas GML. 2007. Dissertação de mestrado – Universidade Federal de Santa Catarina, Programa de Pós-graduação em Ciência da Computação, Florianópolis, 2007. GALDOS System Inc. Developing and managing GML application schemas. May 15, 2003. Disponível em: <http://www.geoconnections.org/developersCorner/devCorner_devNetwork/components/GML_bpv1.3_E.pdf> Acesso em: 20 ago. 2008. GMF. Graphical Modeling Framework. 2008. Disponível em: <http://www.eclipse.org/modeling/gmf/>. Acesso em: 27 out. 2008. GRØNMO, R.; SOLHEIM, I.; SKOGAN, D. Experiences of UML-to-GML encoding. In: AGILE CONFERENCE ON GEOGRAPHIC INFORMATION SCIENCE, 5., 2002, Palma, Mallorca, Spain. Proceedings… AGILE, 2002. GUCLU, K. A first look at Eclipse plug-in programming. 2008. Disponível em: <http://www.developer.com/java/other/article.php/10936_3316241_1>. Acesso em: 25 nov. 2008.
94
GUNAWAN, L. A. Mapping UML class and UML attribute onto XML schema using UML profile. Integral, v.9, n.2, July 2004. HADZILACOS, T.; TRYFONA, N. Evaluation of database modeling methods for Geographic Information Systems. Australian Journal of Information Systems, v.6, iss.1, p.15-26, 1998. HESS, G. N. Unificação semântica de esquemas conceituais de banco de dados geográficos. 105f. 2004. Dissertação de mestrado (Programa de Pós-graduação em Computação) – Instituto de Informática, Universidade Federal do Rio Grande do Sul, Porto Alegre, 2004. ______ & IOCHPE, C. Utilizando a GML na identificação de candidatos a padrão de análise para BDG. In: GEOINFO - SIMPÓSIO BRASILEIRO DE GEOINFORMÁTICA, 5., 2003, Campos do Jordão. Anais... HEUSER, C. A. Projeto de banco de dados. 5. ed. Porto Alegre: Sagra Luzzatto, 2004. JET. Java Emitter Template. 2009. Disponível em: <http://www.eclipse.org/modeling/m2t/?project=jet>. Acesso em: 10 jan. 2009. KOTZINOS, D. & CHRYSOULAKIS, N. Design of GIS Web Service for environmental monitoring using satellite imaging to calculate vegetation indices. In: COST-719 INTERNATIONAL SYMPOSIUM ON GIS AND REMOTE SENSING: ENVIRONMENTAL APPLICATIONS, 2003, Volos, Greece. Proceedings…
LIMA, A. S. UML 2.0: do requisito à solução. São Paulo: Érica, 2005. LISBOA FILHO, J. Projeto de banco de dados para sistemas de informação geográfica. Revista Eletrônica de Iniciação Científica – REIC/SBC, v.1, n.2, 2001. ______ & IOCHPE, C. Modelagem de banco de dados geográficos. In: CONGRESSO BRASILEIRO DE CARTOGRAFIA, XX, 2001, Porto Alegre. LISBOA FILHO, J. et al. Modelagem conceitual de banco de dados geográficos: o estudo de caso do projeto PADCT/CIAMB. In: CENTRO DE ECOLOGIA/UFRGS (Org.). Carvão e meio ambiente. Porto Alegre: Editora da UFRGS, 2000. LISBOA FILHO, J. Um estudo sobre modelos conceituais de dados para projeto de banco de dados geográficos. Revista IP - Informática Pública, Belo Horizonte, v.1, n.2, p.67-90, 1999. MELHEM, W. & GLOZIC, D. PDE does plug-ins. 2003. Disponível em: <http://www.eclipse.org/articles/Article-PDE-does-plugins/PDE-intro.html>. Acesso em: 25 nov. 2008. OGC. OpenGIS® Geography Markup Language (GML) encoding standard. 2007. Disponível em: <http://www.opengeospatial.org/standards/gml>. Acesso em: 27 ago. 2008.
95
ONSRUD, H. et al. The future of the spatial information infrastructure. In: MCMASTER, R. B. & USERY, E. L. (Eds.). A research agenda for Geographic Information Science. Boca Raton: CRC Press, 2004. p.225-255. PAPYRUS. Papyrus UML: open source tool for graphical UML2 modelling. 2009. Disponível em: <http://www.papyrusuml.org/>. Acesso em: 25 jan. 2009. PARENT, C. Modeling spatial data in the MADS conceptual model. In: INTERNATIONAL SYMPOSIUM ON SPATIAL DATA HANDLING – SDH 98, 1998, Vancouver, Canada. Proceedings... July 1998, 11-15. PLANTE, F. Introducing the GMF runtime. 2006. Disponível em: <http://www.eclipse.org/articles/Article-Introducing-GMF/article.html>. Acesso em: 27 out. 2008. SALLES, M. A. V. et al. Desenvolvimento de um sistema automatizado de apoio ao projeto de banco de dados geográficos. In: GIS BRASIL 98, 1998, Curitiba. Anais… p.1-10. SANDRI, A. Profile em UML para modelagem simplificada de interfaces gráficas em aplicativos. 2006. 86f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) - Centro Universitário La Salle, 2006. SANGIORGI, U. B. et al. HiperionCAD: desenvolvimento orientado a modelos aplicado ao projeto de redes de fibra óptica. In: WORKSHOP EM DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES, 1., 2007, Porto de Galinhas. Anais... SAYÃO, L. F. Modelos teóricos em ciência da informação - abstração e método científico. Ciência e Informação, Brasília, v.30, 2001. Disponível em: <http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0100-19652001000100010&lng=en&nrm=iso>. Acesso em: 12 jan. 2009. SEVESTRE, P. M. MDA prático com AndroMDA: primeiros passos. Revista Mundo Java, Curitiba, n.27, ano V, p.50-57, 2008. TESCH JR., J. R. XML schema. Florianópolis: Visual Books, 2002. TRYFONA, N.; PFOSER, D.; HADZILACOS, T. Modeling behavior of geographic objects: an experience with the object modeling technique. In: INTERNATIONAL CONFERENCE ON ADVANCED INFORMATION SYSTEMS ENGINEERING, 9., 1997. Proceedings… June 1997, 16-20, p.347-359.
96
ANEXO I – Lista de objetos GML da série ISO 19100 Implementation of types from the ISO 19100 series of International Standards. Fonte: OGC (2007).
UML class GML object element GML type GML property type GM_Object gml:AbstractGeometry gml:AbstractGeometryType gml:GeometryPropertyType GM_Primitive gml:AbstractGeometricPrimtiv
e gml:AbstractGeometricPrimtiveType
gml:GeometricPrimtivePropertyType
DirectPosition — — gml:DirectPositionType GM_Position — — gml:geometricPositionGroup
(group) GM_PointArray — — gml:geometricPositionListGro
up (group) GM_Point gml:Point gml:PointType gml:PointPropertyType GM_Curve gml:Curve gml:CurveType gml:CurvePropertyType GM_Surface gml:Surface gml:SurfaceType gml:SurfacePropertyType GM_PolyhedralSurface gml:PolyhedralSurface gml:PolyhedralSurfaceType anonymous property typea GM_TriangulatedSurface gml:TriangulatedSurface gml:TriangulatedSurfaceType anonymous property type GM_Tin gml:Tin gml:TinType anonymous property type GM_Solid gml:Solid gml:SolidType gml:SolidPropertyType GM_OrientableCurve gml:OrientableCurve gml:OrientableCurveType gml:CurvePropertyType GM_OrientableSurface gml:OrientableSurface gml:OrientableSurfaceType gml:SurfacePropertyType GM_Ring gml:Ring gml:RingType — GM_Shell gml:Shell gml:ShellType — — gml:LineString gml:LineStringType — — gml:Polygon gml:PolygonType — — gml:LinearRing gml:LinearRingType — GM_CompositePoint gml:Point gml:PointType gml:PointPropertyType GM_CompositeCurve gml:CompositeCurve gml:CompositeCurveType anonymous property type GM_CompositeSurface gml:CompositeSurface gml:CompositeSurfaceType anonymous property type GM_CompositeSolid gml:CompositeSolid gml:CompositeSolidType anonymous property type GM_Complex gml:GeometricComplex gml:GeometricComplexType gml:GeometricComplexPrope
rtyType GM_Aggregate gml:MultiGeometry gml:MultiGeometryType gml:MultiGeometryPropertyT
ype GM_MultiPoint gml:MultiPoint gml:MultiPointType gml:MultiPointPropertyType GM_MultiCurve gml:MultiCurve gml:MultiCurveType gml:MultiCurvePropertyType GM_MultiSurface gml:MultiSurface gml:MultiSurfaceType gml:MultiSurfacePropertyTyp
e GM_MultiSolid gml:MultiSolid gml:MultiSolidType gml:MultiSolidPropertyType GM_MultiPrimitive gml:MultiGeometry gml:MultiGeometryType gml:MultiGeometryPropertyT
ype GM_CurveSegment gml:AbstractCurveSegment gml:AbstractCurveSegmentT
ype —
GM_Arc gml:Arc gml:ArcType — GM_ArcByBulge gml:ArcByBulge gml:ArcByBulgeType — — gml:ArcByCenterPoint gml:ArcByCenterPointType — GM_ArcString gml:ArcString gml:ArcStringType — GM_ArcStringByBulge gml:ArcStringByBulge gml:ArcStringByBulgeType — GM_Bezier gml:Bezier gml:BezierType — GM_BsplineCurve gml:BSpline gml:BSplineType — GM_Circle gml:Circle gml:CircleType — — gml:CircleByCenterPoint gml:CircleByCenterPointTyp
e —
GM_Clothoid gml:Clothoid gml:ClothoidType — GM_CubicSpline gml:CubicSpline gml:CubicSplineType — GM_GeodesicString gml:GeodesicString gml:GeodesicStringType — GM_LineString gml:LineStringSegment gml:LineStringSegmentType — GM_OffsetCurve gml:OffsetCurve gml:OffsetCurveType — GM_SurfacePatch gml:AbstractSurfacePatch gml:AbstractSurfacePatchTyp
e —
GM_GriddedSurface gml:AbstractGriddedSurface gml:AbstractGriddedSurfaceType
—
GM_ParametricCurveSurface
gml:AbstractParametricCurveSurface
gml:AbstractParametricCurveSurfaceType
—
GM_Cone gml:Cone gml:ConeType — GM_Cylinder gml:Cylinder gml:CylinderType — GM_Geodesic gml:Geodesic gml:GeodesicType — GM_Polygon gml:PolygonPatch gml:PolygonPatchType — — gml:Rectangle gml:RectangleType — GM_Sphere gml:Sphere gml:SphereType —
97
GM_Triangle gml:Triangle gml:TriangleType — TP_Object gml:AbstractTopology gml:AbstractTopologyType anonymous property type TP_Node gml:Node gml:NodeType gml:DirectedNodePropertyTy
pe TP_Edge gml:Edge gml:EdgeType gml:DirectedEdgePropertyTy
pe TP_Face gml:Face gml:FaceType gml:DirectedFacePropertyTyp
e TP_Solid gml:TopoSolid gml:TopoSolidType gml:DirectedTopoSolidProper
tyType TP_DirectedNode — — gml:DirectedNodePropertyTy
pe TP_DirectedEdge — — gml:DirectedEdgePropertyTy
pe TP_DirectedFace — — gml:DirectedFacePropertyTyp
e TP_DirectedSolid — — gml:DirectedTopoSolidProper
tyType TP_Complex gml:TopoComplex gml:TopoComplexType gml:TopoComplexPropertyTy
pe — gml:TopoPoint gml:TopoPointType gml:TopoPointPropertyType — gml:TopoCurve gml:TopoCurveType gml:TopoCurvePropertyType — gml:TopoSurface gml:TopoSurfaceType gml:TopoSurfacePropertyTyp
e — gml:TopoVolume gml:TopoVolumeType gml:TopoVolumePropertyTyp
e TM_Object gml:AbstractTimeObject gml:AbstractTimeObjectType anonymous property type TM_Complex gml:AbstractTimeComplex gml:AbstractTimeComplexTy
pe anonymous property type
TM_GeometricPrimitive gml:AbstractTimeGeometricPrimtive
gml:AbstractTimeGeometricPrimtiveType
gml:TimeGeometricPrimtivePropertyType
TM_Instant gml:TimeInstant gml:TimeInstantType gml:TimeInstantPropertyType TM_Period gml:TimePeriod gml:TimePeriodType gml:TimePeriodPropertyType TM_TopologicalComplex gml:TimeTopologyComplex gml:TimeTopologyComplexT
ype gml:TimeTopologyComplexPropertyType
TM_TopologicalPrimitive gml:AbstractTimeTopologyPrimtive
gml:AbstractTimeTopologyPrimtiveType
gml:TimeTopologyPrimtivePropertyType
TM_Node gml:TimeNode gml:TimeNodeType gml:TimeNodePropertyType TM_Edge gml:TimeEdge gml:TimeEdgeType gml:TimeEdgePropertyType TM_PeriodDuration — — gml:duration (property
element), xsd:duration TM_IntervalLength — — gml:timeInterval (group),
gml:TimeIntervalLengthType TM_Duration — — gml:timeLength (group) TM_Position — — gml:TimePositionType TM_IndeterminateValue — — @TimeIndeterminateValue
(attribute on TimePositionType)
TM_Coordinate — — xsd:decimal TM_CalDate — — gml:CalDate TM_ClockTime — — xsd:time TM_DateAndTime — — xsd:dateTime TM_Calendar gml:TimeCalendar gml:TimeCalendarType gml:TimeCalendarPropertyTy
pe TM_CalendarEra gml:TimeCalendarEra gml:TimeCalendarEraType gml:TimeCalendarEraPropert
yType TM_Clock gml:TimeClock gml:TimeClockType gml:TimeClockPropertyType TM_CoordinateSystem gml:TimeCoordinateSystem gml:TimeCoordinateSystemT
ype anonymous property type
TM_OrdinalReferenceSystem
gml:TimeOrdinalReferenceSystem
gml:TimeOrdinalReferenceSystemType
anonymous property type
TM_OrdinalEra gml:TimeOrdinalEra gml:TimeOrdinalEraType gml:TimeOrdinalEraPropertyType
SC_CRS gml:AbstractCRS gml:AbstractCRSType gml:CRSPropertyType SI_LocationInstance — — gml:LocationName CV_Coverage gml:AbstractCoverage gml:AbstractCoverageType anonymous property type CV_ContinuousCoverage gml:AbstractContinuousCovera
ge gml:AbstractContinuousCoverageType
anonymous property type
CV_DiscreteCoverage gml:AbstractDiscreteCoverage gml:DiscreteCoverageType anonymous property type CV_DiscretePointCoverage gml:MultiPointCoverage gml:MultiPointCoverageType anonymous property type CV_DiscreteCurveCoverage gml:MultiCurveCoverage gml:MultiCurveCoverageTyp
e anonymous property type
CV_DiscreteSurfaceCoverag gml:MultiSurfaceCoverage gml:MultiSurfaceCoverageTy anonymous property type
98
e pe CV_DiscreteSolidCoverage gml:MultiSolidCoverage gml:MultiSolidCoverageType anonymous property type CV_DiscreteGridPointCoverage
gml:GridCoverage gml:GridCoverageType anonymous property type
CharacterString — — xsd:string Boolean — — xsd:boolean Real, Number — — xsd:double Decimal — — xsd:decimal Date — — xsd:date Time — — xsd:time DateTime — — xsd:dateTime Integer — — xsd:integer,
xsd:nonPositiveInteger, xsd:negativeInteger, xsd:nonNegativeInteger, xsd:positiveIntegerb
Vector — — gml:VectorType GenericName, LocalName or ScopeName
— — gml:CodeType
Length, Distance — — gml:LengthType Angle — — gml:AngleType Speed — — gml:SpeedType Scale — — gml:ScaleType Area — — gml:AreaType Volume — — gml:VolumeType Measure — — gml:MeasureType Sign — — gml:SignType UnitOfMeasure — — gml:UnitOfMeasureType a An anonymous type following the pattern for GML property types. The object element referenced or embedded inline is the element in the fourth column in the same row. b Multiple values in the second column are given to support the reverse mapping described in Annex F.
99
ANEXO II – Dicionário de dados da categoria Relevo
Dicionário de dados da categoria Relevo da EDGV. Fonte: CONCAR (2007).
100
Relevo:
Classe Descrição Código Primitiva geométrica
Isolinha_Hipsometrica Classe não instanciável especializada em Curva_Nível e Curva_Batimetrica.
2.01 -
Classe Descrição Código Primitiva geométrica
Curva_Nivel
Linha contínua e fechada que representa a sucessão dos pontos de mesma
altitude, referidos ao “datum” vertical estabelecido. 2.02
Atributo Tipo Tama nho
Descrição Domínio Descrição Requisito Fotografia
Sim -
geometriaAproximada Boleano - Indica que a geometria adquirida é aproximada, em relação a escala prevista para o produto cartográfico.
Não -
NÃO NULO -
cota Inteiro -
Valor numérico da altitude ortométrica da Curva
A ser preenchido Ex: 800
NÃO NULO -
Sim -
depressao Boleano -
Linha fechada coincidente com a curva de nível, que representa uma superfície rebaixada em relação a uma área na qual está contida. O atributo indica se a curva de nível define uma depressão
Não -
NÃO NULO -
Mestra Curva múltipla do quíntuplo da eqüidistância empregada, sendo a primeira, a relativa ao nível de referência, de altitude igual a zero.
Normal Curva traçada no intervalo das curvas de nível mestras, sendo múltipla da eqüidistância empregada. indice
Alfanumérico 8
Indica o Índice da Curva de Nível
Auxiliar Curva traçada com o valor adicional de eqüidistância, com o intuito de melhor representar o relevo.
NÃO NULO -
101
Classe
Descrição
Código Primitiva geométrica
Curva_Batimetrica
Para massas d’água interiores: Linha imaginária que une pontos de
mesma profundidade em relação às médias das mínimas das vazantes
(nível de redução local).
2.03
Atributo Tipo Tama
nho Descrição Domínio Descrição Requisito
Fotografia
profundidade
Inteiro - Valor da Profundidade da Curva
A ser preenchido -
NULO -
Classe Descrição Código Primitiva geométrica
Ponto_Hipsometrico
Classe não instanciável especializada em Ponto_Cotado_Altimetrico e
Ponto_Cotado_Batimetrico. 2.04 -
102
Classe Descrição Código Primitiva geométrica
Ponto_Cotado_Altimetrico Ponto com cota de altitude conhecida. 2.05
Atributo Tipo Tama
nho Descrição Domínio Descrição Requisito
Fotografia
Sim -
geometriaAproximada Boleano - Indica que a geometria adquirida é aproximada, em relação a escala prevista para
Não -
NÃO NULO -
- Sim
Altitudes determinadas por um dos métodos: 1)Nivelamento geométrico; 2)Rastreamento de satélites; 3)Nivelamento trigonométrico; 4)Nivelamento barométrico. cotaComprovada
Boleano - Indica se a cota no ponto é comprovada
Não Altitudes determinadas por métodos fotogramétricos e a inserção dos mesmos, na carta, objetiva complementar o traçado das curvas de nível na representação do relevo.
NÃO NULO
-
cota
Real - Indica o valor da altitude ortométrica do ponto, em metros.
A ser preenchido -
NÃO NULO -
Classe Descrição Código Primitiva geométrica
Ponto_Cotado_Batimetrico Ponto com cota de profundidade conhecida. 2.06
Atributo Tipo Tama
nho Descrição Domínio Descrição Requisito
Fotografia
profundidade
Real - Indica o valor da profundidade no ponto, em metros.
A ser preenchido -
NÃO NULO -
Classe Descrição Código Primitiva geométrica
Elemento_Fisiografico
Classe não instanciável especializada em
Elemento_Fisiografico_Natural e Alteracao_Fisiografica_Antropica. 2.07 -
103
Classe Descrição Código Primitiva geométrica
Elemento_Fisiografico_
Natural
Formações naturais da fisiografia. 2.08
Atributo Tipo Tama
nho Descrição Domínio Descrição Requisito
Fotografia
nome Alfanumérico 80 Nome completo da instância A ser preenchido Ex: Serra das Araras.
NULO
-
Sim -
geometriaAproximada Boleano - Indica que a geometria adquirida é aproximada, em relação a escala prevista para o produto cartográfico.
Não -
NÃO NULO -
Desconhecido - -
Serra
Terreno acidentado com fortes desníveis, por vezes associado às escarpas de planaltos.
2.08_a
Morro Monte pouco elevado, cuja altitude é aproximadamente de 100 a 200 metros.
2.08_b
Montanha Grande elevação natural do terreno com altura acima de 300 metros. (Manual de Reambulação-IBGE)
2.08_c
Chapada
Tipo de relevo caracterizado por grandes superfícies planas, geralmente horizontais, com altitudes superiores a 600 metros.
2.08_d
Maciço
Grande massa de rochas eruptivas ou metamórficas ocupando extensas áreas, que já foram parcialmente erodidas.
2.08_e
Planalto Grande extensão de terrenos mais ou menos planos ou levemente ondulados, situados em altitudes variáveis, por vezes cortados por vales encaixados, originados a partir da erosão sobre rochas cristalinas ou sedimentares.
2.08_f
Planície Extensão de terreno extremamente plano e originado pelo acúmulo recente de sedimentos fluviais, marinhos ou lacustres.
2.08_g
Cordilheira Sistema de altas montanhas produzidas pelo orogenismo (falhas e dobras), geralmente situadas nas margens continentais.
2.08_h
Península Ponta de terra emersa cercada de água por todos os lados, excetuando-se apenas um deles, pelo qual se liga ao continente.
2.08_i
tipoElemNat
Alfanumérico 11
Indica o tipo de formação de relevo
Ponta Extremidade saliente da costa, de fraca elevação, que avança de forma aguçada em direção ao mar.
NÃO NULO
2.08_j
104
Cabo Parte saliente da costa de regular altitude, que avança em direção ao mar.
2.08_k
Praia
Área coberta e descoberta periodicamente pelas águas, acrescida da faixa subseqüente de material detrítico, tais como areias, cascalhos, seixos e pedregulhos até o limite onde se inicie a vegetação natural, ou, em sua ausência, onde comece um outro ecossistema (Lei 7.661/88). Podendo ocorrer tanto no litoral, quanto na beira de rios, lagos, etc.
2.08_l
Outros -
nomeAbrev Alfanumérico 50 Nome ou abreviatura padronizada A ser preenchido
- NULO
-
105
Classe Descrição Código Primitiva geométrica
Fenda_Falha
Estrutura do substrato rochoso caracterizada por uma superfície planar
de descontinuidade física das rochas, gerada, principalmente, por
esforços tectônicos.
2.09
Atributo Tipo Tama
nho Descrição Domínio Descrição Requisito
Fotografia
nome Alfanumérico 80 Nome completo da instância A ser preenchido -
NULO
-
Sim -
geometriaAproximada Boleano - Indica que a geometria adquirida é aproximada, em relação a escala prevista para o produto cartográfico.
Não -
NÃO NULO -
Desconhecido - -
Fenda Abertura estreita que se observa nas rochas, devido ao alargamento da diáclase.
2.09_a
Diáclase Plano de ruptura ou fratura de direção variada, provocada, principalmente, por esforços tectônicos que separam ou tendem a separar em duas partes um bloco de rocha primitivamente uno ao longo do qual não tenha ocorrido deslocamento das partes separadas.
2.09_b
Falha Fratura existente na rocha, na qual ocorre um deslocamento perceptível das partes, ao longo do plano de fratura, seja no sentido vertical (falhas normais e falhas inversas) ou no sentido horizontal (falhas transcorrentes).
2.09_c
tipoFendaFalha
Alfanumérico 15 Tipo de fenda ou falha
Outros Outros não listados.
NÃO NULO
-
nomeAbrev Alfanumérico 50 Nome ou abreviatura padronizada A ser preenchido
- NULO
-
106
Classe Descrição Código Primitiva geométrica
Dolina
Depressão de forma acentuadamente circular, afunilada, com larguras e
profundidades variadas, que aparecem nos terrenos calcários 2.10
Atributo Tipo Tama
nho Descrição Domínio Descrição Requisito
Fotografia
nome Alfanumérico 80 Nome completo da instância A ser preenchido -
NULO
2.10_a
Sim -
geometriaAproximada Boleano - Indica que a geometria adquirida é aproximada, em relação a escala prevista para o produto cartográfico.
Não -
NÃO NULO -
nomeAbrev Alfanumérico 50 Nome ou abreviatura padronizada A ser preenchido
- NULO
-
107
Classe Descrição Código Primitiva geométrica
Duna
Monte de areia móvel ou não, acumulado nas áreas litorâneas ou
continentais pela ação de deposição do vento dominante. 2.11
Atributo Tipo Tama
nho Descrição Domínio Descrição Requisito
Fotografia
nome Alfanumérico 80 Nome completo da instância A ser preenchido -
NULO
2.11_a
Sim -
geometriaAproximada Boleano - Indica que a geometria adquirida é aproximada, em relação a escala prevista para o produto cartográfico.
Não -
NÃO NULO -
Sim Existe vegetação sobre a duna (total ou parcial)
fixa
Boleano - Indica se a duna é fixa. Não
Não existe vegetação sobre a mesma (total ou parcial)
NÃO NULO -
nomeAbrev Alfanumérico 50 Nome ou abreviatura padronizada A ser preenchido
- NULO
-
108
Classe
Descrição
. Código Primitiva geométrica
Escarpa_Talude
Escarpa - Rampa ou aclive de terrenos que aparecem nas bordas dos planaltos, serras, etc.
Talude - superfície inclinada do terreno na base de um morro ou de uma encosta onde se encontra um depósito de detritos
2.12
Atributo Tipo Tama
nho Descrição Domínio Descrição Requisito
Fotografia
nome Alfanumérico 80 Nome completo da instância A ser preenchido -
NULO
2.12_a
Sim -
geometriaAproximada Boleano - Indica que a geometria adquirida é aproximada, em relação a escala prevista para o produto cartográfico.
Não -
NÃO NULO -
Escarpa -
tipoEscarpaTalude Alfanumérico 17 Indica se uma escarpa ou um talude.
Talude ou falésia -
NÃO NULO -
nomeAbrev Alfanumérico 50 Nome ou abreviatura padronizada A ser preenchido
- NULO
-
109
Classe Descrição Código Primitiva geométrica
Gruta_Caverna
Cavidade de formas variadas que aparece mais freqüentemente nas rochas
calcárias ou em arenitos de cimento calcário. 2.13
Atributo Tipo Tama
nho Descrição Domínio Descrição Requisito
Fotografia
nome Alfanumérico 80 Nome completo da instância A ser preenchido -
NULO
-
Sim -
geometriaAproximada Boleano - Indica que a geometria adquirida é aproximada, em relação a escala prevista para o produto cartográfico.
Não -
NÃO NULO -
Gruta Cavidade de pequenas dimensões em monte, rochedo, ou sob a terra.
2.13_a
tipoGrutaCaverna
Alfanumérico 15 Indica o tipo da instância Caverna
Cavidade de grandes dimensões em monte, rochedo ou sob a terra.
NÃO NULO
2.13_b
nomeAbrev Alfanumérico 50 Nome ou abreviatura padronizada A ser preenchido
- NULO
110
Classe Descrição Código Primitiva geométrica
Pico
Ponto culminante, definido, de uma montanha, serra ou de todo um
conjunto de relevo. 2.14
Atributo Tipo Tama
nho Descrição Domínio Descrição Requisito
Fotografia
nome Alfanumérico 80 Nome completo da instância A ser preenchido -
NULO
2.14_a
Sim -
geometriaAproximada Boleano - Indica que a geometria adquirida é aproximada, em relação a escala prevista para o produto cartográfico.
Não -
NÃO NULO -
nomeAbrev Alfanumérico 50 Nome ou abreviatura padronizada A ser preenchido
- NULO
-
111
Classe Descrição Código Primitiva geométrica
Rocha
Formação natural de minerais agregados, resultante de um processo
geológico determinado, que integra a crosta terrestre. 2.15
Atributo Tipo Tama
nho Descrição Domínio Descrição Requisito
Fotografia
nome Alfanumérico 80 Nome completo da instância A ser preenchido -
NULO
-
Sim -
geometriaAproximada Boleano - Indica que a geometria adquirida é aproximada, em relação a escala prevista para o produto cartográfico.
Não -
NÃO NULO -
Matacão - pedra Denominação genérica usada para qualquer fragmento de rocha, com diâmetro maior que 25 cm.
2.15_a
Penedo - isolado Nome regional dado aos penhascos ou pontões constituídos pelo afloramento de rocha nua, geralmente superiores a 100 metros.
2.15_b
tipoRocha
Alfanumérico 20 Indica se a rocha está isolada ou se pertence a uma área com vários afloramentos rochosos. Área rochosa -
lajedo Toda e qualquer exposição de rochas na superfície da Terra.
NÃO NULO
2.15_c
nomeAbrev Alfanumérico 50 Nome ou abreviatura padronizada A ser preenchido
- NULO
-
112
Classe Descrição Código Primitiva geométrica
Terreno_Exposto
Local onde ocorre exposição do solo, caracterizada pela preponderante
ausência de vegetação, mesmo que apresente elementos de vegetação esparsos
irrelevantes no contexto da área.
2.16
Atributo Tipo Tama
nho Descrição Domínio Descrição Requisito
Fotografia
Sim -
geometriaAproximada Boleano - Indica que a geometria adquirida é aproximada, em relação a escala prevista para o produto cartográfico.
Não -
NÃO NULO -
Desconhecido Causa desconhecida. -
Pedregoso Afloramento de pedras
2.16_a
Areia Afloramento de areia.
2.16_b
Terra Afloramento de terra
2.16_c
Lago Asfáltico Acúmulo de resíduos asfálticos em uma depressão do terreno.
2.16_d
Cascalho Um depósito, nível ou acumulação de fragmentos de rochas e/ou minerais mais grossos do que areia, principalmente com tamanho de seixos.
2.16_e
tipoTerrExp
Alfanumérico 16 Indica o tipo do terreno exposto.
Saibro Argila misturada com areia e pedras.
NÃO NULO
2.16_f
Natural Se a causa da exposição for natural.
causaExposicao
Alfanumérico 10 Se a causa da exposição do solo é natural ou artificial. Artificial
Se a causa da exposição for resultado da ação efetiva do homem.
NÃO NULO -
113
Classe Descrição Código Primitiva geométrica
Alteracao_Fisiografica_Antropica
Alterações antrópicas que o relevo sofre em função da ocupação humana
do terreno para um determinado fim. 2.17
Atributo Tipo Tama
nho Descrição Domínio Descrição Requisito
Fotografia
nome Alfanumérico 80 Nome completo da instância A ser preenchido -
NULO
-
Sim -
geometriaAproximada Boleano - Indica que a geometria adquirida é aproximada, em relação a escala prevista para o produto cartográfico.
Não -
NÃO NULO -
Desconhecido - -
Resíduo de bota-fora Áreas de disposição de resíduos inertes, geralmente provenientes da construção de estradas.
2.17_a
Resíduo sólido em geral Áreas de disposição de resíduos sólidos em geral, provenientes da construção
civil.
2.17_b
Caixa de empréstimo Área de retirada de material proveniente de cortes em obras de engenharia.
2.17_c
Área aterrada Elevação do nível do terreno, para aproveitamento de área.
2.17_d
Corte Obra cuja terra foi retirada para a formação de plataformas horizontais para servir a passagem de rodovias ou ferrovias.
2.17_e
tipoAlterAntrop
Alfanumérico 22 Indica o tipo de alteração do relevo.
Aterro É a elevação do nível do terreno formando plataformas horizontais, com o aproveitamento, quando possível, da terra proveniente do corte, para servir a passagem de rodovias ou ferrovias.
NÃO NULO
2.17_f
nomeAbrev Alfanumérico 50 Nome ou abreviatura padronizada A ser preenchido
- NULO
-