Modelagem de Dados com o Perfil UML GeoProfile e Transformações MDA na Ferramenta Enterprise Architect

Transcrição

1 Modelagem de Dados com o Perfil UML GeoProfile e Transformações MDA na Ferramenta Enterprise Architect Thiago B. Ferreira, Sergio M. Stempliuc Faculdade Governador Ozanam Coelho Fagoc) Ubá, MG, Brazil {thiagao.ti,smstempliuc@gmail.com Jugurta Lisboa-Filho Universidade Federal de Viçosa UFV) Viçosa, MG, Brazil jugurta@ufv.br Resumo Proposto para padronizar a modelagem conceitual de bancos de dados geográficos e contendo os diferentes níveis de abstração da arquitetura MDA, o GeoProfile é um perfil UML que pode ser introduzido em diversas ferramentas CASE já consolidadas pela infraestrutura da UML. Este artigo tem como objetivo descrever o uso do GeoProfile na ferramenta CASE Enterprise Architect e da linguagem de transformação da ferramenta para permitir transformações automáticas entre os diversos níveis da arquitetura MDA. Palavras-chave: Bancos de Dados Geográficos; GeoProfile; MDA; Enterprise Architect; transformação; PIM; PSM; SQL. I. INTRODUÇÃO Visando atender as necessidades da especificação de dados espaciais, nos últimos 20 anos pesquisadores desenvolveram ou adaptaram modelos conceituais de dados para aplicação geográfica [5]. Porém, estas inovações trouxeram o problema da falta de padrão na modelagem conceitual, dificultando a comunicação entre projetos criados por ferramentas CASE Computer-Aided Software Engineering) específicas [3]. Com intuito de padronizar a área, foi especificado um perfil UML Unified Modeling Language) nomeado GeoProfile alinhado com a normas ISO [4] e arquitetura MDA Model Driven Architecture) [2]. O GeoProfile atua em um alto nível de abstração na modelagem conceitual de BDGeo e utiliza as ferramentas CASE já consolidadas pela infraestrutura da UML [5]. No site do Projeto do perfil GeoProfile 1 é possível observar que diferente dos modelos conceituais este perfil não necessita de uma ferramenta especifica, uma vez que pode-se valer de ferramentas CASE como: Rational Software Modeler RSM) 2, Papyrus UML2 Modeler 3, Visual Paradigm for UML 4 Star UML 5 e Enterprise Architect EA) 6. Através de estudos empíricos de versões recentes das ferramentas listadas no site do projeto, foi possível constatar que diferente das demais, a EA fornece uma linguagem própria de transformação entre os diversos níveis da arquitetura MDA. De modo similar ao trabalho de [6], no qual foram apresentadas as transformações MDA de diagramas elaborados a partir do GeoProfile na ferramenta RSM, este trabalho apresenta o uso da ferramenta EA e os desafios para o desenvolvimento de um mecanismo de transformação MDA para bancos de dados geográficos utilizando o perfil GeoProfile. Este artigo é organizado como segue: a seção 2 apresenta o conceito de Perfil UML, o Perfil GeoProfile e a arquitetura MDA; a seção 3 apresenta o uso do GeoProfile na ferramenta Enterprise Architect e a transformação entre as etapas do MDA; a seção 4 apresenta a geração de código SQL pela ferramenta EA; a seção 5 apresenta a conclusão e os trabalhos futuros. II. PERFIL UML, GEOPROFILE E MDA Constituído de estereótipos, tagged values e constraints) o perfil UML é um mecanismo de extensão para sanar a necessidade de aplicações mais complexas. Os estereótipos são caracterizados como um dos principais veículos para customização da UML [1], sendo usado pelo GeoProfile durante a representação de formas geométricas. Tagged values são meta-atributos associados a um estereótipo específico, responsáveis por adicionar informações aos elementos do modelo, que podem ser avaliados por máquinas e interpretados por seres humanos [1,8]. As constraints são restrições aplicadas aos elementos do modelo e podem ser expressas através da OCL Object Constraint Language) [8]

2 O GeoProfile é um perfil UML que une características de maior destaque dos modelos conhecidos pela comunidade de BDGeo: OMT-G, MADS, GeoOOA, UML-GeoFrame e o modelo da ferramenta Perceptory. Por ser um perfil UML possibilita um nível de abstração mais alto garantido pela abordagem MDA, auxiliando os projetistas nos primeiros passos de um projeto em BDGeo [5]. Outra vantagem é ser automaticamente suportado por ferramentas CASE já consolidadas pela infraestrutura da UML, utilizando-as na modelagem de banco de dados geográficos e promovendo assim interoperabilidade e padronização da área [3]. MDA é uma abordagem proposta pela [7] que permite o desenvolvimento de sistemas em diferentes níveis de abstração [3]. Os níveis de abstração da MDA podem ser separados em CIM, PIM e PSM. O CIM Computation Independent Model) não mostra detalhes da estrutura do sistema, mas o ambiente em que o sistema vai operar [7]. Em relação ao GeoProfile, os estereótipos são aplicados na classe, podendo ser, por exemplo, representação do tipo ponto, linha ou polígono. O PIM Platform Independent Model) é um modelo independente de qualquer tecnologia de implementação [2], contendo os requisitos de software necessários. No GeoProfile, os estereótipos são apresentados como atributos da classe. O PSM Platform Specific Model) especifica detalhes a respeito da plataforma no qual será implementado. Para plataforma de modelo relacional, as classes do GeoProfile são convertidas em tabelas [5]. Os artefatos produzidos pela abordagem MDA são modelos formais que podem ser entendidos por computadores, e após sofrerem transformações chegarão a uma etapa final de código-fonte abordagem top_down) ou em altos níveis de abstração abordagem bottom_up) [1]. A Figura 1 ilustra a atuação de ferramentas de transformação nos níveis da arquitetura MDA. Figura 1. Utilização de Ferramentas de transformações na abordagem MDA. Fonte: Adaptado de [2]. III. TRANSFORMAÇÕES MDA APLICADAS AO GEOPROFILE NA ENTERPRISE ARCHITECT Utilizando a ferramenta CASE Enterprise Architect EA) versão 9.0 Ultimate trial), comercializada pela Sparx Systems para o planejamento e construção de sistemas de software, este trabalho procurou reproduzir os diferentes níveis de abstração especificados pela arquitetura MDA. Apesar do GeoProfile em sua definição valer-se da modelagem de um CIM, considerou-se desnecessário para o trabalho transformações de CIM para PIM, pois durante a elaboração dos diagramas percebeu-se que conceitos abstratos e específicos acabam por se misturar na ferramenta EA. Podese considerar que o diagrama elaborado com o GeoProfile nessa ferramenta se enquadra como um CIM pela abstração e uso de estereótipos textuais, ao mesmo tempo que se enquadra como PIM por permitir a especificação dos tipos de dados dos atributos das classes. Classificando-se então seus diagramas como PIM, na Figura 2 as classes Cidade e Escola são objetos espaciais do tipo polígono e ponto, respectivamente. A classe Distrito possui múltipla representação espacial de polígono e ponto e Professor é uma classe sem representação geográfica. Figura 2. Diagrama construído na Enterprise Architect a partir do Perfil GeoProfile, representando o PIM da abordagem MDA. Com o PIM obtido, o próximo passo foi obter o PSM. Para isso a ferramenta disponibiliza no menu Tools/Model Transformation MDA) modelos de transformações que dão origem a PSMs para C#, EJB, Java, DDL entre outros, mas por serem transformações genéricas, suportam somente tipos de dados comuns a estas linguagens, e não as especificidades relacionadas ao uso de estereótipos. Um modelo de transformação para PSM que chamou a atenção foi o DDL Data Definition Language), por apresentar transformações de diagramas de classe em diagramas de tabelas e permitir a transformação de tipos de dados de acordo com o SGBD selecionado. No entanto, a DDL por padrão não faz a transformação dos estereótipos das classes, mas no menu Settings/Transformations Templates há códigos-fontes em uma linguagem específica para os modelos de transformação que podem ser modificados para tarefas específicas de transformação dos diagramas do GeoProfile. Além da modificação de códigos templates, ainda é permitida a criação de novos modelos de transformação. Para um novo modelo de transformação MDA de PIM para PSM do GeoProfile, foram aproveitados códigos do modelo de transformação DDL para a transformação de classes em tabelas, transformação dos relacionamentos e confecção de chaves primárias e estrangeiras. Também foi aproveitado um código referente à criação de pacotes, comum a todos os modelos de transformação, modificando-se apenas o nome do pacote a ser criado. O Código 1 é responsável pela criação do pacote GeoProfile_PSM, e será executado toda vez que o modelo de transformação do GeoProfile for solicitado.

3 Package{ name="geoprofile_psm" "% Código 1. Código-fonte para criação do pacote GeoProfile_PSM. A transformação dos estereótipos foi realizada através de condicionais que avaliam o tipo geográfico de um estereótipo ponto, linha, polígono, etc.). Todo estereótipo geográfico que se encontra em um diagrama de classe deve virar uma coluna na respectiva tabela. O Código 2 é responsável pela transformação dos estereótipos Point e Polygon, sendo similar a transformação para o estereótipo Line. Para o estereótipo Point, as colunas terão o nome formado da concatenação do nome da classe com a string Point, e o tipo de dado, que até então não existia vazio), convertido para GM_Point. O mesmo ocorre para o tipo Polygon, sendo formado pela concatenação com a string Polygon, e o tipo de dado GM_Polygon. Esses são tipos de dados espaciais do SGBD Oracle. %IF classstereotype == "Point"% COLUMN { name=%qt%%convert_nameclassname, "Pascal Case","Camel Case")%Point%qt% type=%qt%%convert_typegenoptdefaultd atabase,"gm_point")%%qt% %endif% %IF classstereotype == "Polygon"% COLUMN { name=%qt%%convert_nameclassname, "Pascal Case","Camel Case") %Polygon%qt% Figura 3. Problemas na multirrepresentação geográfica). Além disso, foi desenvolvido um código para transformação dos tipos de dados disponibilizados pela ferramenta no nível PIM, p. ex., Character e Integer, em tipos de dados reconhecidos pelo SGBD Oracle. Caso algum tipo seja diferente dos especificados na transformação, estes são passados como campos vazios para o PSM. O Código 3 é responsável pela transformação do tipo de dado Character para Varchar. Column { %TRANSFORM_CURRENT"type",stereotype", "collection","constant","containment", "ordered", "static", "volatile")% $type1 = %atttype% %if $type1 == "Character"% type=%qt%%convert_typegenoptdefaultdat abase,"varchar2")%%qt% %endif% Código 3. Código para conversão dos tipos dos atributos. No entanto, não foi necessário desenvolver um código para atribuição de tamanhos de campo como, por exemplo, Varchar230) e Number8,2), pois a ferramenta pode ser préconfigurada para atribuir valores a estes tipos de dados, conforme ilustra a Figura 4. Código 2. Conversão do estereotipo Polygon em coluna. type=%qt%%convert_typegenoptdefaultdat Apesar da ferramenta EA permitir o uso de múltiplos estereótipos, abase,"gm_polygon")%%qt% durante a transformação não é permitido que todos sejam processados. Pode-se observar que no Código 2, a primeira linha apresenta um if para comparar uma variável classstereotype %endif% com uma string Polygon). Esta variável possui somente a string do primeiro estereótipo da classe, não sendo encontrada uma solução até o momento para se capturar os demais. A Figura 3-a ilustra a classe Distrito, com múltipla representação geográfica, e o estereótipo Polygon separado por vírgula do estereótipo Point. A Figura 3-b apresenta as propriedades dessa classe, destacando-se o local onde, embora seja uma combo box, contém somente o primeiro estereótipo Polygon), também armazenado na variável classstereotype. Figura 4. Customização dos tipos de dados dos atributos usados durante a transformação de PIM para PSM.

4 Após seguir o tutorial no site do projeto GeoProfile para sua incorporação na ferramenta EA e os conceitos que foram apresentados até o momento, é possível se utilizar o menu Tools/Model Transformation MDA) e selecionar a transformação GeoProfile_PSM para que, a partir do PIM da Figura 2, seja gerado o PSM da Figura 5. Figura 5. PSM gerado a partir de transformações MDA). Após seguir os passos descritos para a geração do PSM e comparar o Diagrama ilustrado na Figura 2 PIM) com o diagrama da Figura 5 PSM),, pode-se observar que para relacionamentos semânticos, ou seja, aqueles que não envolvem relacionamentos topológicos entre objetos geográficos, são criadas automaticamentes as chaves estrangeiras nas classes. Por exemplo, para relacionamento semântico entre as classes Distrito e Escola, foi criada a chave estrangeira distritoid na última classe. O modelo relacional hoje já não apresenta grandes desafios acerca da transformação entre os modelos PIM e PSM. No entanto, as características espaciais, que envolvem novos tipos de dados e relacionamentos topológicos, adicionam dificuldades durante essa transformação, o que requer a investigação de uma extensão das regras padrão estipuladas para o modelo relacional. Outra dificuldade é a falta de padronização a respeito da implementação desses tipos de dados e relacionamentos nos diferentes SGBDs. Como consequência disso, é interessante que as novas regras de transformação possam ser especificadas nas ferramentas, o que ocorre na ferramenta EA através da possibilidade de se customizar ou criar uma nova linguagem de transformação. A Figura 4 mostra que novos tipos de dados podem ser criados durante a transformação para um tipo particular de SGBD, o que ajuda na especificação de atributos espaciais. Mas algumas complicações podem ocorrer quando considerados os tipos temporais e de visão de campo, devido ao próprio conceito ser diferente dos tipos convencionais. Além disso, relacionamentos topológicos também são mais complexos de serem transformados para o PSM, uma vez que especificam restrições de integridade entre os tipos espaciais envolvidos, não sendo possível realizar esta tarefa simplesmente pela criação de chaves estrangeiras. IV. GERAÇÃO DE CÓDIGO SQL NA EA PARA O SGBD ORACLE SPATIAL O código SQL com o script de criação da estrutura de tabelas, relacionamentos e restrições de integridade é a última etapa do MDA para se alcançar de forma automática a implementação do que foi especificado inicialmente em alto nível de abstração PIM). A ferramenta Enterprise Architect fornece nativamente a geração do script SQL para as classes com o estereótipo Table presentes no PSM. Para realizar esta tarefa deve-se selecionar as propriedades do pacote GeoProfile_PSM e então utilizar a opção de transformação Generate DDL para que sejam fornecidas as opções para geração do código SQL. Através da Figura 6 é possível observar que além de gerar a tabela com as respectivas colunas, a ferramenta EA fornece algumas opções para geração do código SQL. Os passos são: Na Figura 6, selecionar as tabelas a serem transformadas em códigos SQL; Apontar o local onde o código fonte será armazenado isto em Single File Selecionar as opções para geração do código SQL, por exemplo: Primary Key, Foreign Key e Stored Procedures. Executar a transformação de PSM para código SQL através do botão Generate. Figura 6. Janela para gerar código SQL do pacote GeoProfile_PSM).

5 Desta forma os Códigos 4 e 5 apresentam os códigos SQL gerados na ferramenta EA como último artefato da arquitetura MDA. Tanto o Código 4 quanto o Código 5 são originados do PSM apresentado na Figura 5, porém foram separados para melhor entendimento e adequação ao presente trabalho. O Código 4 apresenta o script SQL responsável pela criação das tabelas do banco de dados no caso o Oracle. USE DATABASE oracle; DROP TABLE Cidade CASCADE CONSTRAINTS; DROP TABLE Distrito CASCADE CONSTRAINTS; DROP TABLE Escola CASCADE CONSTRAINTS; DROP TABLE Professor CASCADE CONSTRAINTS; CREATE TABLE Cidade Populacao NUMBER8,2), cidadepolygon GM_Polygon, cidadeid CREATE TABLE Distrito NUMBER8,2) NOT NULL distritopolygon GM_Polygon, distritoid NULL, cidadeid CREATE TABLE Escola Endereco NUMBER8,2) NOT NUMBER8,2) escolapoint GM_Point, escolaid distritoid CREATE TABLE Professor NUMBER8,2) NOT NULL, NUMBER8,2) Código 4. Janela para gerar código SQL do pacote GeoProfile_PSM). Endereco professorid NUMBER8,2) NOT NULL, escolaid NUMBER8,2) O Código 5 apresenta as alterações feitas nas tabelas criadas para inclusão de Primary Keys e Foreign Keys. ALTER TABLE Cidade ADD CONSTRAINT PK_Cidade PRIMARY KEY cidadeid) USING INDEX ; ALTER TABLE Distrito ADD CONSTRAINT PK_Distrito PRIMARY KEY distritoid) USING INDEX ; ALTER TABLE Escola ADD CONSTRAINT PK_Escola PRIMARY KEY escolaid) USING INDEX; ALTER TABLE Professor ADD CONSTRAINT PK_Professor PRIMARY KEY professorid) USING INDEX ; ALTER TABLE Distrito ADD CONSTRAINT Possui FOREIGN KEY cidadeid) REFERENCES Cidade cidadeid ALTER TABLE Escola ADD CONSTRAINT Dentro_de FOREIGN KEY distritoid) REFERENCES Distrito distritoid ALTER TABLE Professor ADD CONSTRAINT Trabalha FOREIGN KEY escolaid) REFERENCES Escola escolaid Código 5. Adição de Primary Keys e Foreign Keys nas tabelas criadas.

6 Como apresentado pela Figura 2 representando o PIM), pela Figura 5 representando o PSM) e pelos Códigos 4 e 5 representando o código fonte SQL), é possível se efetuar transformação MDA nas fases PIM, PSM e código fonte SQL para BDGeo usando o Perfil GeoProfile na ferramenta EA. No entanto, existem restrições impostas pela ferramenta, no caso do exemplo, a transformação da múltipla representação geográfica da classe Distrito. Como o código SQL é gerado a partir do modelo PSM apresentado na Figura 5, a tabela Distrito não apresenta as características espaciais Polygon e Point inicialmente especificadas no modelo PIM. Apesar desse obstáculo, a ferramenta consegue gerar um código SQL para implementação no SGBD Oracle. A ferramenta EA apresenta várias possibilidades de geração de código fonte, porém o modelo DDL não fornece opção de customização, tanto para geração do PSM quanto para geração do código SQL. A customização para geração do PSM só foi alcançada através do uso de Templates customizáveis, mas por hora a geração de código SQL utilizou somente a transformação direta da ferramenta através da opção Generate DDL. Fica evidente que a opção do menu settings/code Generation Templates fornecerá também linguagens customizáveis e até mesmo a possibilidade de desenvolvimento de uma linguagem específica para transformação do diagrama PSM do GeoProfile em um arquivo de texto com o código fonte SQL para criação do banco de dados. V. CONCLUSÃO Este trabalho mostrou que diagramas criados a partir do GeoProfile na ferramenta CASE Enterprise Architect podem ser submetidos a transformações MDA desde o PIM até o código fonte SQL, utilizando-se de linguagens de transformação customizáveis. Apesar de alguns problemas momentâneos, como a falta de recurso para transformação de múltiplos estereótipos em uma classe, a ferramenta fornece recursos interessantes para automatizar a geração de todos os modelos da arquitetura MDA, garantindo assim uma fidelidade maior do que é especificado em alto nível e o que realmente será implementado no SGBD. Como trabalhos futuros, pretende-se aprimorar a linguagem de transformação apresentada para que seja possível a transformação de todos os estereótipos do perfil GeoProfile, o que inclui os aspectos temporais, visão de campo e relacionamentos topológicos. Além disso, deve-se observar que a partir do modelo PSM a transformação deve considerar os tipos de dados utilizados pelos diferentes SGBDs, tanto para os atributos convencionais quanto os geográficos e temporais. A sequência deste trabalho será a investigação da especificação de restrições de integridade através da OCL Object Constraint Language), tanto daquelas inerentes ao perfil GeoProfile quanto das que podem ser inseridas pelo projetista em seus diagramas. O uso de tais restrições com a OCL deve incluir a verificação sintática e semântica de suas expressões, baseados nos tipos de objetos geográficos e nos relacionamentos topológicos permitidos. Além disso, deve ser realizada a transformação dessas restrições entre os diversos modelos da arquitetura MDA, incluindo a geração de código fonte capaz de garantir a integridade e consequentemente melhorar a qualidade dos dados. ACKNOWLEDGMENT HEADING 5) Projeto parcialmente financiado pela Fagoc e pelas agências FAPEMIG e CNPq. REFERENCES [1] Erikson, H., Penker, M., Lyons, B and Fado, D. 2004). UML 2 Toolkit, OMG Press. [2] Kleppe, A., Warmer, J. e Bast, W. 2003). MDA Explained: The Model Driven Architecture: Practice and Promise, Addison Wesley, 1th edition. [3] Lisboa Filho, J., Sampaio, G.B., Nalon, F.R. and Borges, K.A.V. 2010). A UML Profile for Conceptual Modeling in GIS Domain. In International Workshop on Domain Engineering DE@CAISE 2010, p [4] Nalon, F. R., et al. 2011). Applying the model driven architecture approach for geographic database design using a UML Profile and ISO standards. Journal of Information and Data Management, v.2, n.2, p [5] Nalon, F. R., Lisboa Filho, J., and Peixoto, D. A. 2010). Modelagem de dados geográficos utilizando um perfil UML alinhado a padrões internacionais e à abordagem MDA. In Workshop brasileiro de desenvolvimento de software dirigido por modelos WB-DSDM in CBSoft), Salvador, p [6] Nalon, F. R.; Lisboa Filho, J.; Borges, K. A. V.; Braga, J. L.; Andrade, M. V. A. In: SIMPÓSIO BRASILEIRO DE GEOINFORMÁTICA GEOINFO), 11, 2010), Campos do Jordão-SP. Anais... São José dos Campos: MCT/INPE, p [7] Object Management Group. 2003). MDA Guide, v.1.0.l. OMG, Needham, MA, USA. [8] Object Management Group. 2007). Unified Modeling Language: Superstructure, v OMG, Needham, MA, USAs