X02 Um gerador de código MDA baseado em mapeamentos de modelos

Texto

(1)Pós-Graduação em Ciência da Computação. “XO2 – UM GERADOR DE CÓDIGO MDA BASEADO EM MAPEAMENTOS DE MODELOS” Por. João Paulo Augusto de Oliveira Ferreira Dissertação de Mestrado. Universidade Federal de Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao. RECIFE, OUTUBRO/2005.

(2)

(3) UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. JOÃO PAULO AUGUSTO DE OLIVEIRA FERREIRA. “XO2 – UM GERADOR DE CÓDIGO MDA BASEADO EM MAPEAMENTOS DE MODELOS". ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO.. ORIENTADOR(A): Roberto Souto Maior Barros. RECIFE, OUTUBRO/2005.

(4) Ferreira, João Paulo Augusto de Oliveira X02 – Um gerador de código MDA baseado em mapeamentos de modelos / João Paulo Augusto de Oliveira Ferreira. – Recife : O Autor, 2005. xx, 108 folhas : il., fig., tab. Dissertação (mestrado) – Universidade Federal de Pernambuco. CIn. Mestrado em Ciência da Computação, 2005. Inclui bibliografia e apêndice. 1. Sistema – Geração de código – Ambiente XO2. 2. Arquitetura de sistemas (MDA). 3. Padrão XMI. 4. Mapeamento de modelos. I. Título. 004.4’24 005.13. CDU (2.ed.) CDD (22.ed.). UFPE BC2006-045.

(5)

(6)

(7) Aos meus pais e av´ os pela educa¸ c˜ ao, incentivo e compreens˜ ao..

(8)

(9) AGRADECIMENTOS A todos que me ajudaram ao longo deste trabalho. Aos meus amigos e familiares. Aos professores Roberto e Décio. Ao professor Zeque e amigos do SIG@.. vii.

(10)

(11) Never send a human to do a machine’s job. — AGENT SMITH, THE MATRIX.

(12)

(13) RESUMO Atualmente, devido às exigências do mercado e à grande competitividade, as empresas precisam desenvolver sistemas de informa¸cão com qualidade e dentro de prazos cada vez mais curtos. Neste cenário, este trabalho apresenta o ambiente XO2 , que possibilita gerar grande parte do código-fonte de um sistema de informa¸c˜ ao orientado a objetos. O ambiente utiliza transforma¸cão de modelos com base na arquitetura MDA - Model Driven Architecture. Também propõe um documento para mapeamento de modelos e uma interface gráfica para auxiliar no processo de cria¸c˜ ao dos documentos e gera¸c˜ ao de código. O XO2 foi validado em um estudo de caso para substitui¸c˜ ao da camada de persistência do SIG@UFPE e mostrou-se capaz de aumentar a qualidade e consistência do código gerado, elevar o n´ıvel de abstra¸cão através da separa¸c˜ ao bem definida de papéis e responsabilidades proposta pela arquitetura MDA. Finalmente, o ambiente foi capaz de aumentar a produtividade do projeto pela redu¸cão de esfor¸co na realiza¸c˜ ao de tarefas repetitivas. Palavras-chave: gera¸cão de código, MDA, XMI, mapeamento de modelos.. xi.

(14)

(15) ABSTRACT Nowadays, companies need to provide high quality products and services within short periods of time. In this scenario, this work presents XO2 , a code generation environment, based on the MDA - Model Driven Architecture, which is aimed to automatically generating large parts of the implementation code of object-oriented software using model mappings and model transformations. The tool uses the MDA - Model Driven Architecture and proposes a markup language to represent model mappings and an user interface to help the documents creation and code generation activities. The XO2 tool was tested against a real case and prove its capacity to increase the generated code quality and consistency, increase the abstraction through the separation of concerns defined by the MDA. Finally, the tool increased the project overall productivity by reducing the amount of work spent on repetitive tasks. Keywords: code generation, MDA, XMI, model mapping.. xiii.

(16)

(17) ´ SUMARIO. Cap´ıtulo 1—Introdu¸c˜ ao 1.1 1.2 1.3. 1. Por que gerar código? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estrutura da Disserta¸cão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Cap´ıtulo 2—Gera¸c˜ ao de C´ odigo: Conceitos, Padr˜ oes e Tecnologias 2.1 2.2. Conceitos . . . . . . . . . . . . . . . . . . . Gera¸cão de Código . . . . . . . . . . . . . . 2.2.1 Modelos de Geradores de Código . . 2.2.2 Tipos de Geradores de Código . . . 2.2.2.1 Code Munger . . . . . . . . 2.2.2.2 Inline Code Expander . . . 2.2.2.3 Mixed Code . . . . . . . . 2.2.2.4 Partial Class Generator . . 2.2.2.5 Tier Generator . . . . . . . 2.2.3 Fluxo de desenvolvimento . . . . . . 2.3 Mapeamento OO-Relacional . . . . . . . . . 2.4 Padrões OMG - Object Management Group 2.4.1 MOF . . . . . . . . . . . . . . . . . 2.4.2 XMI . . . . . . . . . . . . . . . . . . 2.5 JMI . . . . . . . . . . . . . . . . . . . . . . 2.6 MDR . . . . . . . . . . . . . . . . . . . . . . 2.7 MDA . . . . . . . . . . . . . . . . . . . . . . 2.7.1 PIM - Plataform Indepent Model . . 2.7.2 PSM - Platform Specific Model . . . 2.7.3 Código-Fonte . . . . . . . . . . . . . 2.7.4 Transforma¸cões . . . . . . . . . . . . 2.8 Velocity . . . . . . . . . . . . . . . . . . . . 2.9 Hibernate . . . . . . . . . . . . . . . . . . . 2.10 Conclusões . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. 5 . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. Cap´ıtulo 3—Trabalhos Relacionados 3.1 3.2 3.3. XDoclet . . . 3.1.1 Pontos AndroMDA . 3.2.1 Pontos iQgen . . . . 3.3.1 Pontos. . . . . . . . Relevantes . . . . . . . Relevantes . . . . . . . Relevantes. . . . . . .. 1 3 3. 5 6 6 7 7 8 9 9 10 11 12 13 13 16 19 20 20 22 22 23 23 24 25 26 29. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . . xv. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 29 32 33 35 35 39.

(18) ´ SUMARIO. xvi 3.4 3.5 3.6. e-Gen . . . . 3.4.1 Pontos Qualiti Coder 3.5.1 Pontos Conclusões .. . . . . . . . Relevantes . . . . . . . Relevantes . . . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 40 41 42 42 42. Cap´ıtulo 4—XO2 - Um gerador de c´ odigo MDA baseado em mapeamentos de modelos 45 4.1 4.2. 4.3. 4.4 4.5. 4.6. Visão Geral . . . . . . . . . . . . . . . . . . . . Arquivos de Entrada . . . . . . . . . . . . . . . 4.2.1 O Diagrama de Classes . . . . . . . . . 4.2.2 O Template Velocity/XO2 . . . . . . . . 4.2.3 O Mapeamento de Modelos . . . . . . . Arquitetura das Classes XO2 . . . . . . . . . . 4.3.1 O pacote xo2 . . . . . . . . . . . . . . . 4.3.2 O pacote gui . . . . . . . . . . . . . . . 4.3.3 O pacote uml . . . . . . . . . . . . . . . 4.3.4 O pacote mapping . . . . . . . . . . . . 4.3.5 O pacote util . . . . . . . . . . . . . . Bibliotecas Utilizadas . . . . . . . . . . . . . . O processo de desenvolvimento com o XO2 . . 4.5.1 Cria¸cão do Modelo Orientado a Objetos 4.5.2 Cria¸cão do Documento de Mapeamentos 4.5.3 Cria¸cão dos Templates . . . . . . . . . . 4.5.4 Gera¸cão do Código-fonte . . . . . . . . . Conclusões . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. Cap´ıtulo 5—Testes e Resultados 5.1 5.2 5.3 5.4. Gerando código para sites da web . . . Gerando arquitetura em camadas para Resultados . . . . . . . . . . . . . . . . Conclusões . . . . . . . . . . . . . . .. 75 . o . .. . . . . . . . . . . . . projeto SIG@UFPE . . . . . . . . . . . . . . . . . . . . . . . .. Cap´ıtulo 6—Conclus˜ oes 6.1 6.2. 45 46 46 47 53 58 58 59 60 66 69 71 72 72 72 73 73 74. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 75 84 95 97 99. Contribui¸cões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101. Apˆ endice A—VTL - Velocity Template Language. 103.

(19) LISTA DE FIGURAS. 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21 2.22 2.23. Funcionamento de um gerador de código ativo . . . . . . . . . . . . . . . Funcionamento de um gerador de código passivo . . . . . . . . . . . . . Funcionamento de um gerador de código do tipo Code Munger . . . . . Funcionamento do Javadoc . . . . . . . . . . . . . . . . . . . . . . . . . Funcionamento de um gerador de código do tipo Inline Code Expander . Funcionamento de um gerador de código Mixed Code . . . . . . . . . . . Funcionamento de um gerador de código Partial Class . . . . . . . . . . Funcionamento de um gerador de código do tipo Tier . . . . . . . . . . . Gerador de código Tier para aplica¸c˜ ao J2EE . . . . . . . . . . . . . . . . Fluxo de desenvolvimento convencional . . . . . . . . . . . . . . . . . . . Fluxo de desenvolvimento com gerador de código . . . . . . . . . . . . . Representa¸cão da linguagem XML em MOF . . . . . . . . . . . . . . . . Principais elementos do padrão MOF . . . . . . . . . . . . . . . . . . . . Representando uma classe em XMI . . . . . . . . . . . . . . . . . . . . . Representa¸cão das classes Carro e Pessoa . . . . . . . . . . . . . . . . . Representa¸cão da classe Carro . . . . . . . . . . . . . . . . . . . . . . . . Visão geral dos principais elementos da linguagem UML . . . . . . . . . Ciclo de Desenvolvimento Tradicional do RUP . . . . . . . . . . . . . . Ciclo de Desenvolvimento MDA . . . . . . . . . . . . . . . . . . . . . . . Transforma¸cões MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transforma¸cões MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . Padrão MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. 6 7 8 8 8 9 10 10 11 12 12 15 16 17 17 18 20 21 22 23 23 24 26. 3.1 3.2 3.3 3.4. Diagrama de classes UML . . . . . . . . Interface gráfica do iQgen . . . . . . . . Interface gráfica do e-Gen Modeler . . . Interface gráfica do e-Gen Design Portal. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 30 36 40 41. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11. Visão Geral do XO2 . . . . . . . . . . . . . . . Diagrama UML . . . . . . . . . . . . . . . . . . Mapeamentos . . . . . . . . . . . . . . . . . . . Principais elementos do mapeamento M3 L . . . Diagrama UML com heran¸ca . . . . . . . . . . Principais pacotes do ambiente XO2 . . . . . . O pacote XO2 . . . . . . . . . . . . . . . . . . . A interface gráfica de mapeamento de modelos A interface gráfica de gera¸cão de código . . . . A interface XO2lement . . . . . . . . . . . . . . A classe XO2Package . . . . . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. 46 48 53 54 56 58 59 60 61 61 62. xvii. . . . .. . . . .. . . . ..

(20) xviii. LISTA DE FIGURAS. 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20. A interface XO2Classifier . . . . . . . . . . . . . . . . . . . A classe XO2Method . . . . . . . . . . . . . . . . . . . . . . Classes que representam os relacionamentos . . . . . . . . . Estrutura de um documento XMI . . . . . . . . . . . . . . . O pacote mapping . . . . . . . . . . . . . . . . . . . . . . . Mapeamento Classe/Tabela. . . . . . . . . . . . . . . . . . . Principais componentes externos e apis utilizados pelo XO2 Etapas do processo de gera¸cão de código do XO2 . . . . . . Inser¸cão do XO2 no processo de desenvolvimento tradicional. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 63 63 65 65 66 67 71 72 73. 5.1 5.2 5.3 5.4 5.5 5.6 5.7. Documentos responsáveis pelo cadastro Modelo de projeto . . . . . . . . . . . . Tela de atualiza¸cão produzida pelo XO2 Os subsistemas do sistema SIG@UFPE . A distribui¸cão do sistema SIG@UFPE . Arquitetura em camadas do SIG@UFPE Representa¸cão UML da classe Prédio . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 76 76 84 85 85 87 88. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . ..

(21) LISTA DE TABELAS. 2.1. Arquitetura MOF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14. 3.1 3.2 3.3 3.4 3.5 3.6. Pontos relevantes ao uso do XDoclet . . . . . . . . Pontos relevantes ao uso do AndroMDA . . . . . . Pontos relevantes ao uso do iQgen . . . . . . . . . Pontos relevantes ao uso do e-Gen . . . . . . . . . Pontos relevantes ao uso do Qualiti Coder . . . . . Principais caracter´ısticas dos ambientes analisados. 4.1. Pontos relevantes ao uso do XO2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 74. 5.1. Tempo de desenvolvimento (em horas) com e sem ambiente XO2 . . . . . . . . . 96. 6.1. Comparativo entre o XO2 e outros ambientes . . . . . . . . . . . . . . . . . . . . 100. xix. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 32 35 39 42 43 43.

(22)

(23) CAPÍTULO 1. ˜ INTRODUC ¸ AO. Na era da informa¸cão, em um cenário de grande competitividade, a sobrevivência de uma empresa depende principalmente da qualidade de seus produtos e servi¸cos, da agilidade na resolu¸cão de problemas, e da satisfa¸cão de seus clientes. As empresas são obrigadas a implantar modelos de qualidade, automatizar seus processos, e obviamente investir na aquisi¸c˜ ao e/ou no desenvolvimento de sistemas de informa¸c˜ ao que atendam às suas demandas. Neste contexto, onde um sistema de informa¸c˜ ao pode ser um diferencial e também uma arma competitiva, o processo de constru¸c˜ ao do sistema passa a ser estratégico e, como tal, necessita seguir critérios r´ıgidos de qualidade e diversos outros fatores que pertencem ao escopo da engenharia de software. A engenharia de software, por sua vez, procura adaptar práticas bem-sucedidas de outras engenharias no contexto de cria¸cão de sistemas, o que motiva pesquisas em torno de assuntos como reuso de componentes e automatiza¸c˜ ao do processo de desenvolvimento. Esta disserta¸cão apresenta um ambiente para automatizar e acelerar a etapa de implementa¸cão de um processo de desenvolvimento de software. O ambiente proposto por este trabalho, denominado XO2 , propõe-se a gerar uma grande parte do código-fonte de um sistema de informa¸c˜ ao orientado a objetos através da transforma¸cão de modelos, independentemente da plataforma, arquitetura e linguagem de programa¸cão, seguindo os princ´ıpios da arquitetura MDA - Model Driven Architecture [KWB03]. A utiliza¸cão do ambiente XO2 resulta em benef´ıcios como: (1) aumento da qualidade e padroniza¸c˜ ao do código-fonte, (2) aumento da consistência do código, (3) aumento da produtividade através da automatiza¸cão e acelera¸c˜ ao do processo de desenvolvimento e (4) abstra¸c˜ ao pela separa¸cão bem definida de papéis e responsabilidades. O ambiente XO2 difere de solu¸cões já existentes, pois além de modelos OO - Orientados a Objetos descritos em UML [BRJ98], podem ser utilizados como entrada do sistema outros modelos, como o ER - Entidade-Relacionamento [BCNN91], cujos elementos quando relacionados servem como insumo para cria¸cão de grande parte do código-fonte de sistemas de informa¸c˜ ao. 1.1. Por que gerar c´ odigo?. Desde o in´ıcio da sua história, o homem vem procurando formas de agilizar o seu trabalho. Ferramentas e processos foram desenvolvidos para otimizar e aumentar a qualidade da realiza¸c˜ ao de tarefas repetitivas. Na engenharia de software não poderia ser diferente. Atualmente, as empresas precisam de sistemas mais completos, com n´ umero reduzido de bugs e com um tempo de desenvolvimento cada vez mais curto. Além disso, os projetos de sistemas precisam ser mais robustos e seus requisitos são alterados constantemente [Joh05]. Diante deste cenário, surgiram técnicas, padrões, frameworks 1 e metodologias de desenvolvimento voltados para a agiliza¸c˜ ao dos proces1. Arcabou¸co, um conjunto de classes para atender as necessidades de um determinado problema.. 1.

(24) 2. ˜ INTRODUC ¸ AO. sos. Entre eles destacam-se Agile Modeling [SWA02], XP [KB04] e AOP [JDG03], que reduzem drasticamente o esfor¸co despendido na produ¸c˜ ao de artefatos durante as fases de levantamento de requisitos, análise e projeto e ainda facilitam a implementa¸c˜ ao dos sistemas. Ainda assim, na fase de implementa¸c˜ ao, o desenvolvedor precisa escrever um grande n´ umero de linhas de código, devido ao uso de frameworks “pesados”. Desta forma, surge nas empresas o questionamento sobre o desperd´ıcio do racioc´ınio e do tempo dos seus desenvolvedores em atividades repetitivas (cria¸cão de infra-estrutura de código, documenta¸c˜ ao, testes unitários), enquanto estes poderiam estar ocupados com o desenvolvimento de um código-fonte que realmente exigisse a interferência humana (implementa¸c˜ ao de regras de negócio) [Mei05] [Nic05]. A utiliza¸cão de frameworks que fazem uso intensivo de código escrito destaca o valor da substitui¸cão da mão-de-obra humana por um ambiente gerador de código. Arquiteturas em camadas, EJB [MH01], persistência de dados utilizando middlewares como o Hibernate [Hib05] são exemplos de frameworks que fazem uso intensivo de escrita de código, que na sua grande maioria não necessita de racioc´ınio para ser criado, pois segue um padrão repetitivo. Este é o ambiente ideal para a utiliza¸cão de ferramentas capazes de gerar código, pois estas seriam capazes de eliminar o esfor¸co do desenvolvedor na cria¸c˜ ao do código repetitivo. Gera¸cão de código é o processo de produzir código de alto n´ıvel através de descri¸c˜ oes de requisitos ou modelos de negócio. Atualmente existem dezenas de ferramentas que auxiliam os desenvolvedores na fase de implementa¸c˜ ao do desenvolvimento de software. As ferramentas vão desde simples wizards que auxiliam na cria¸c˜ ao de trechos de código até ambientes que produzem a arquitetura completa de um sistema. O primeiro benef´ıcio que se obtém pela utiliza¸c˜ ao de um gerador de código é o aumento da produtividade. Não menos significativos são os aumentos de: qualidade, consistência e abstra¸cão. Qualidade. Devido à grande quantidade de código-fonte escrito durante o desenvolvimento de um sistema, é bem provável que novas melhorias de código não sejam propagadas por toda base de código escrito. A utiliza¸cão de um ambiente gerador de código cria, através dos templates, uma base de código que poderá ser recriada a cada nova execu¸c˜ ao. Desta forma, a corre¸cão de erros e as melhorias no código serão aplicadas instantaneamente em todo o código do sistema. ` medida que aumenta-se a qualidade dos templates, a qualidade da base de código geA rada também aumenta, pois a qualidade do código produzido por um gerador está diretamente relacionada à qualidade dos templates utilizados. Consistˆ encia. O código produzido por um ambiente gerador de código está de acordo com os padrões de projeto e com os padrões de codifica¸caõ (nomes de classes, vari´ aveis, métodos, alinhamento) e é consistente em toda a sua base de código. O código-fonte produzido é mais fácil de ser entendido, de sofrer manuten¸c˜ ao e de ser utilizado. O gerador de código encoraja o desenvolvedor a trabalhar de acordo com a arquitetura e com os padrões do projeto. Produtividade. Como os desenvolvedores não precisam desenvolver código repetitivo, o cronograma do projeto torna-se bastante otimizado (itera¸c˜ oes mais curtas), pois tem-se uma quantidade maior de horas para elaborar e implementar as regras de negócio. Com mais tempo para implementa¸cão das regras de negócio os desenvolvedores podem buscar a melhor solu¸c˜ ao para cada problema e, ainda, dar mais aten¸c˜ ao às fases de prototipa¸c˜ ao e testes. ´ notório que os requisitos de um projeto estão sempre sendo alterados [Joh05], desta forma E.

(25) 1.2 OBJETIVOS. 3. o ganho na produtividade também será percebido durante a manuten¸c˜ ao do projeto. Com a simples altera¸cão dos modelos um novo código-fonte compat´ıvel com os requisitos poderá ser gerado rapidamente. Abstra¸ c˜ ao. A grande maioria dos geradores de código produzem código a partir do processamento de modelos abstratos e regras de transforma¸c˜ ao (templates). O grande valor desta abordagem é a possibilidade de se produzir código para outras plataformas. Esta abstra¸c˜ ao é traduzida na portabilidade do sistema para outras plataformas. A abstra¸cão propicia ao arquiteto experimentar diferentes abordagens para resolu¸c˜ ao de um determinado problema utilizando diferentes arquiteturas e plataformas. 1.2. Objetivos. Este trabalho teve por objetivo o desenvolvimento de um ambiente gerador de código, denominado XO2 , com a capacidade de produzir código-fonte a partir de vários modelos abstratos do sistema. Enquanto a maioria dos geradores de código utilizam apenas um modelo para produzir código, o XO2 permite a utiliza¸cão de vários modelos como entrada para o ambiente. Depois de uma vasta pesquisa, foi comprovada a inexistência de um padrão de mapeamento de modelos abstratos. Sendo assim, este trabalho também propõe um documento escrito em linguagem XML, denominado M3 L - Model Mapping Markup Language, capaz de representar, de forma simplificada, liga¸cões entre modelos orientados a objetos, entidade-relacionamento, etc. O documento M3 L contém apenas um subconjunto de todos os elementos necessários para representar de forma fiel o mapeamento de modelos. Porém, com esse pequeno n´ umero de elementos já se conseguiu provar a eficiência e a utilidade do mapeamento de modelos em um ambiente gerador de código. O ambiente XO2 foi modelado utilizando a linguagem UML e sua implementa¸c˜ ao foi realizada na linguagem Java, com o intuito de manter a modularidade, extensibilidade e reusabilidade do código. Assim como o documento M3 L, o protótipo XO2 implementa apenas uma parte da solu¸c˜ ao do problema, pois permite ao usuário utilizar apenas o modelo orientado a objetos e o entidaderelacionamento. No entanto, o padrão de modelagem e o protótipo foram projetados de forma que sejam capazes de serem estendidos. Foi implementada uma interface gráfica para auxiliar a constru¸c˜ ao do documento M3 L e execu¸cão do ambiente XO2 . Para a valida¸cão do ambiente foi utilizado como estudo de caso o SIG@UFPE - Sistema de Informa¸cão e Gestão Acadêmica Universidade Federal de Pernambuco [UFP05]. O XO2 foi configurado para produzir boa parte do código arquitetural do sistema e os resultados dos testes foram bastante animadores no que concerne à qualidade e consistência do código-fonte produzido, além dos ganhos de produtividade e aumento na capacidade de abstra¸c˜ ao durante as fases de análise e projeto do sistema. 1.3. Estrutura da Disserta¸c˜ ao. Além desta se¸cão introdutória, esta disserta¸c˜ ao é composta por mais cinco cap´ıtulos. Cap´ıtulo 2 - Apresenta um resumo sobre os principais conceitos, padrões e ferramentas.

(26) ˜ INTRODUC ¸ AO. 4. relevantes ao entendimento deste trabalho. Nele será explicado o conceito de gera¸c˜ ao de código 2 juntamente com os principais tipos de geradores de código e alguns padrões OMG . Ainda são detalhadas algumas ferramentas utilizadas no desenvolvimento do protótipo. ´ feita uma análise dos principais Cap´ıtulo 3 - Apresenta alguns trabalhos relacionados. E ambientes geradores de código existentes. Cap´ıtulo 4 - Apresenta detalhadamente o ambiente XO2 , sua arquitetura, decisões de projeto, seu funcionamento, como extrair o máximo do ambiente e ainda como estendê-lo. Cap´ıtulo 5 - Apresenta os testes e resultados obtidos através da utiliza¸c˜ ao do ambiente XO2 em dois problemas distintos: produzir websites dinâmicos em linguagem Perl [WCO00] e alterar a camada de persistência do sistema SIG@UFPE. Cap´ıtulo 6 - Apresenta as contribui¸c˜ oes deste trabalho, as conclusões tiradas e os trabalhos futuros.. 2. Object Management Group. Cons´ orcio regulamentador de alguns padr˜ oes para sistemas distribu´ıdos e orientados a objetos.

(27) CAPÍTULO 2. ˜ DE CODIGO: ´ ˜ GERAC ¸ AO CONCEITOS, PADROES E TECNOLOGIAS. Este cap´ıtulo apresenta os principais conceitos, padrões e tecnologias relevantes ao entendimento do ambiente de gera¸cão de código proposto neste trabalho. Primeiramente, serão definidos alguns termos utilizados ao longo do texto. Em seguida, o leitor será apresentado ao conceito de gera¸cão de código e mapeamento OO-Relacional. Posteriormente, os padrões da OMG serão introduzidos. Finalmente, serão detalhadas as tecnologias Velocity [CG03] e Hibernate [Hib05]. 2.1. Conceitos. No contexto deste trabalho, sistema de informa¸c˜ ao ou sistema é todo software ou parte de software desenvolvido com o propósito de resolver um problema espec´ıfico, variando de um simples website até um complexo sistema financeiro. Um modelo ou diagrama de sistema é a descri¸caõ ou especifica¸c˜ ao com um determinado propósito do sistema ou de uma de suas partes. Um modelo geralmente é apresentado como uma combina¸cão de gráficos e textos. O texto pode ser escrito em alguma linguagem de modelagem ou mesmo em linguagem natural. Ao longo deste trabalho serão utilizados amplamente termos como analista de sistemas, arquiteto de sistemas, engenheiro de software e designer. Analista de sistemas ou simplesmente analista é responsável por definir e especificar os requisitos funcionais e não-funcionais de um sistema. Ainda é responsável por, juntamente com o usuário, criar um protótipo da interface gráfica. O analista deve possuir um amplo conhecimento do negócio que está sendo modelado. Ele irá trabalhar juntamente com os futuros usuários do sistema e com os profissionais de TI, atuando como um mediador entre o mundo tecnológico e o mundo do negócio. O analista precisa ser capaz de identificar problemas e oportunidades e, ainda, propor solu¸c˜ oes. Se de um lado o analista precisa conhecer os meandros do negócio modelado e os jargões da equipe de TI, ele não deve estar “intoxicado” pela tecnologia. O arquiteto de sistemas ou apenas arquiteto é responsável por definir a arquitetura de software, a plataforma e a linguagem de implementa¸c˜ ao. Ele também deve sugerir reutiliza¸c˜ ao de componentes e projetar classes reusáveis e solu¸c˜ oes arquiteturais. A arquitetura define a quantidade e responsabilidades das camadas de um sistema e a comunica¸cão entre essas camadas. O arquiteto deve estar em contato com o analista para ter uma visão completa das necessidades do negócio ao mesmo tempo que deve guiar os desenvolvedores, tendo sempre como objetivos qualidade e robustez. O desenvolvedor ou engenheiro de software é responsável pela escrita do código-fonte, além de realizar testes de unidade e de performance e corrigir defeitos apontados. Designer é o profissional responsável pela elabora¸c˜ ao e cria¸c˜ ao das interfaces gráficas do sistema. Geralmente é um profissional especializado em artes gráficas e que não necessita ter 5.

(28) ˜ DE CODIGO: ´ ˜ GERAC ¸ AO CONCEITOS, PADROES E TECNOLOGIAS. 6. muitos conhecimentos da área de engenharia de software. 2.2. Gera¸c˜ ao de C´ odigo. Gera¸cão de código é o processo de escrever um software que tem a capacidade de escrever outros softwares. Desta forma, um gerador de código recebe alguns parâmetros de entrada, realiza um processamento e, finalmente, produz código-fonte como sa´ıda [Her03]. Os geradores de código podem ser classificados de acordo com o tipo de gera¸c˜ ao de código utilizado e de acordo com o tipo de arquivos de entrada e sa´ıda. Frameworks como J2EE [MH01] e .NET [and03] for¸cam a escrita de um n´ umero muito maior de linhas de código, pois geralmente as classes de negócio dão origem a vários documentos fonte. Analogamente, quanto mais complexo for o framework mais recomendada será a utiliza¸c˜ ao de um ambiente gerador de código. 2.2.1. Modelos de Geradores de C´ odigo. Herrington [Her03] classifica os geradores de acordo com o tipo de gera¸c˜ ao em: ativos e passivos. Os geradores ativos podem ser executados diversas vezes sobre o mesmo código de acordo com as altera¸cões realizadas no input (arquivo de entrada). O código editado é mantido através de se¸cões protegidas que garante a sua existência em futuras gera¸c˜ oes de código. A Figura 2.1 ilustra o ciclo de um gerador de código ativo.. Figura 2.1 Funcionamento de um gerador de código ativo. Um gerador ativo é capaz de ler e entender um modelo abstrato do sistema e produzir o código-fonte base de implementa¸cão do sistema para uma determinada plataforma e, ainda, é capaz de proteger o código editado. Os geradores passivos permitem que o código seja gerado uma u ńica vez e toda a manuten¸c˜ ao necessária deverá ser realizada por parte dos desenvolvedores. A Figura 2.2 ilustra o ciclo de um gerador de código passivo. Os geradores passivos fornecem uma acelera¸c˜ ao inicial na produtividade do projeto, no entanto, caso os requisitos sejam alterados todas as modifica¸c˜ oes realizadas na base de código.

(29) ˜ DE CODIGO ´ 2.2 GERAC ¸ AO. 7. Figura 2.2 Funcionamento de um gerador de código passivo. serão perdidas a cada execu¸cão do ambiente. Muitos dos geradores de código passivos são solu¸co˜es criadas pelos próprios desenvolvedores para resolver tarefas simples e repetitivas. Um gerador de código passivo é muito u ´til na produ¸c˜ ao de coment´ arios e anota¸c˜ oes no código. Este tipo de gerador de código é bastante difundido como wizard em IDEs - Integrated Development Environment1 . Geralmente uma IDE utiliza um gerador passivo para produzir o código base (declara¸cão de pacote e classe e blocos de coment´ ario) de uma classe que será editado pelo desenvolvedor. 2.2.2. Tipos de Geradores de C´ odigo. Nesta se¸cão, serão abordados os principais tipos de geradores de código que são classificados por Herrington [Her03] de acordo com os arquivos de entrada (utilizados como insumo para o ambiente) e sa´ıda (produzidos pelo ambiente). 2.2.2.1 Code Munger O gerador conhecido como Code Munger2 é o tipo mais comum. A partir de um código-fonte de entrada, o “munger” seleciona as partes importantes e as utiliza para criar um ou mais arquivos de sa´ıda. A Figura 2.3 apresenta o fluxo de processo de um gerador de código do tipo Code Munger. O gerador recebe os arquivos de entrada e, geralmente através de expressões regulares ou análise de código somados a templates internos ou externos, constrói os arquivos de sa´ıda. Um gerador deste tipo geralmente é utilizado para criar documenta¸c˜ ao através da leitura de variáveis e métodos. O Javadoc [Sun05b], exemplo de Code Munger, realiza a leitura e análise de código-fonte Java em busca de comentários e marca¸c˜ oes para em seguida produzir documenta¸c˜ ao em forma de documentos HTML. A Figura 2.4 ilustra o funcionamento do Javadoc. Em rela¸cão à qualidade, o Javadoc produz documenta¸c˜ ao bastante precisa pois os comentários são mantidos ao longo do código-fonte e como esse será completamente percorrido pelo Javadoc, o desenvolvedor não precisa criar as entradas para os nomes e tipos de vari´ aveis. 1 2. Ambiente de desenvolvimento integrado que provê interface gr´ afica, editor, compilador e depurador de c´ odigo G´ıria em inglês que significa comportamento simplista.

(30) 8. ˜ DE CODIGO: ´ ˜ GERAC ¸ AO CONCEITOS, PADROES E TECNOLOGIAS. Figura 2.3 Funcionamento de um gerador de código do tipo Code Munger. A utiliza¸cão do Javadoc também fornece um ganho na produtividade, pois o desenvolvedor é liberado da tarefa cansativa de criar e manter uma documenta¸c˜ ao externa. Isto ocorre porque o código-fonte desenvolvido já contém internamente a documenta¸c˜ ao necessária. Um gerador do tipo Code Munger possui um baixo n´ıvel de abstra¸c˜ ao, já que a entrada é geralmente o próprio código-fonte.. Figura 2.4 Funcionamento do Javadoc. 2.2.2.2 Inline Code Expander Um gerador de código do tipo Inline Code Expander recebe um código-fonte com marcadores que serão “expandidos” ou transformados durante a produ¸cão do código. A Figura 2.5 ilustra o fluxo de controle de um inline code expander.. Figura 2.5 Funcionamento de um gerador de código do tipo Inline Code Expander. Como percebe-se pela Figura 2.5, existem dois códigos-fonte. O primeiro, escrito pelo de-.

(31) ˜ DE CODIGO ´ 2.2 GERAC ¸ AO. 9. senvolvedor, contém uma série de marca¸c˜ oes. O segundo, produzido pelo gerador de código, é o código que deverá ser compilado. Um Inline Code Expander é freq¨ uentemente utilizado para estender código SQL em um código-fonte já existente. Os desenvolvedores adicionam notas ou marca¸c˜ oes que servem como indica¸cões para o gerador. Este por sua vez analisa o código e sempre que encontra uma indica¸cão, insere o novo código. A utiliza¸cão de um Inline Code Expander fornece uma qualidade maior no código do projeto, pois fornece de forma independente a infra-estrutura de acesso aos dados exigida para a execu¸c˜ ao dos comandos SQL. Ele também deixa o código de infra-estrutura consistente ao longo de toda a base de código. 2.2.2.3 Mixed Code Assim como o Inline Code Expander e o Code Munger, o Mixed Code recebe um código-fonte como entrada, o transforma e produz um código-fonte de sa´ıda. Porém o código de sa´ıda é armazenado no próprio arquivo de entrada, sobrescrevendo o conte´ udo existente. A Figura 2.6 representa o funcionamento de um gerador Mixed Code.. Figura 2.6 Funcionamento de um gerador de código Mixed Code. 2.2.2.4 Partial Class Generator Como o próprio nome indica, um gerador Partial Class é responsável por criar parte de uma camada da aplica¸c˜ ao. Um gerador de código deste tipo produz um conjunto básico de classes para implementar atividades simples. Caso seja necessário, extensões da classe devem ser criadas para implementar novas funcionalidades. Este funcionamento é ilustrado na Figura 2.7. Um exemplo t´ıpico de um gerador de código Partial Class é aquele utilizado para construir uma camada de acesso aos dados. O gerador cria o código de persistência para cada classe e seus campos. Sendo assim, qualquer funcionalidade extra dever´ a ser implementada em uma classe derivada. Numa avalia¸cão geral, percebe-se que um gerador deste tipo controla toda a estrutura de acesso à base de dados, assim a qualidade do código estará diretamente associada aos templates utilizados para gera¸cão de código. Altera¸c˜ oes nos templates serão contempladas em todo o código gerado. Como a API de acesso aos dados é criada automaticamente, haver´ a uma padroniza¸c˜ ao nas assinaturas dos métodos e nomes de vari´ aveis, facilitando o entendimento e manuten¸c˜ ao do código gerado, além de reduzir o n´ umero de erros. Portabilidade é mais um benef´ıcio da utiliza¸c˜ ao de um gerador de código deste tipo, pois a lógica de acesso aos dados é extra´ıda das classes de negócio e armazenada em arquivos de.

(32) ˜ DE CODIGO: ´ ˜ GERAC ¸ AO CONCEITOS, PADROES E TECNOLOGIAS. 10. Figura 2.7 Funcionamento de um gerador de código Partial Class. defini¸cão tornando a camada de persistência portável para outra plataforma. 2.2.2.5 Tier Generator Um gerador Tier3 é capaz de gerar uma camada inteira de um sistema multi-camada. Num sistema web, pode ser uma camada de acesso aos dados, camada de negócio ou de interface gráfica com o usuário.. Figura 2.8 Funcionamento de um gerador de código do tipo Tier. A Figura 2.8 mostra como funciona um gerador Tier. O gerador recebe um documento com a defini¸cão abstrata do sistema e um conjunto de templates que serão utilizados para produzir 3. Do inglês camada.

(33) ˜ DE CODIGO ´ 2.2 GERAC ¸ AO. 11. os documentos de sa´ıda. Nestes documentos estará contida uma camada completa da aplica¸c˜ ao. A principal diferen¸ca entre os geradores Tier e Partial Class é que o primeiro produz e mantém todo o código da camada e o segundo deixa a cria¸c˜ ao das classes especializadas para o desenvolvedor. A Figura 2.9 ilustra um gerador Tier que produz a camada de acesso aos dados de uma aplica¸cão J2EE [MH01]. Percebe-se que o gerador produz toda a camada de persistência dos dados. Como o gerador de código é responsável pela constru¸c˜ ao da camada, obtém-se consistência por toda a base de código gerada. A velocidade com que o gerador de código produz uma camada da aplica¸c˜ ao permite que o arquiteto experimente diversos estilos e estruturas de classes, simplesmente alterando os templates e gerando novamente o código. Seria imposs´ıvel para um desenvolvedor fazer as mesmas altera¸cões em uma base inteira de código consumindo o mesmo tempo.. Figura 2.9 Gerador de código Tier para aplica¸cão J2EE. 2.2.3. Fluxo de desenvolvimento. A utiliza¸cão de um ambiente gerador de código provoca uma altera¸c˜ ao no fluxo de desenvolvimento de um sistema. No fluxo convencional, representado na Figura 2.10, os desenvolvedores escrevem o código, fazem a compila¸cão e em seguida testam o código. Caso necessário, o código será editado reiniciando o fluxo. A utiliza¸cão de um gerador de código adiciona duas etapas responsáveis pela cria¸c˜ ao dos templates e gera¸cão da base de código. A Figura 2.11 ilustra o fluxo de desenvolvimento com gerador de código. Na fase de cria¸cão dos templates, o arquiteto e o engenheiro verificam quais necessidades serão codificadas de forma que o template forne¸ca um código fiel à modelagem. Na fase de gera¸cão de código, os templates e os arquivos de defini¸c˜ ao serão inseridos no ambiente gerador de código. Dependendo do gerador de código utilizado, o código produzido.

(34) ˜ DE CODIGO: ´ ˜ GERAC ¸ AO CONCEITOS, PADROES E TECNOLOGIAS. 12. Figura 2.10 Fluxo de desenvolvimento convencional. Figura 2.11 Fluxo de desenvolvimento com gerador de código. poderá ser editado e então, juntamente com o código escrito pelos desenvolvedores, compilado. Caso necessário o fluxo será reiniciado. 2.3. Mapeamento OO-Relacional. Os desenvolvedores de sistemas orientados a objetos que utilizam SGBD4 relacional como forma de persistência de dados geralmente gastam uma boa parte do tempo de programa¸c˜ ao para tornar os objetos de negócio persistentes. Isto acontece pela diferen¸ca fundamental entre o paradigma orientado a objetos e o paradigma relacional. A base do paradigma OO é um objeto que possui atributos, comportamento e heran¸ca, enquanto que a base do paradigma relacional é uma tabela que tem a capacidade de armazenar dados e relacionar-se com outras tabelas. Segundo Yoder [YJW98] a diferen¸ca entre os paradigmas é similar à impedância entre circuitos eletrônicos, sendo assim, quando se conecta um sistema orientado a objetos a bancos de dados relacionais obtém-se circuitos que funcionam independentemente e com sinais (formato de dados) não-compat´ıveis. Existem algumas formas para contornar o problema da “impedância” entre modelos, entre elas: utiliza¸cão de um SGBD orientado a objetos, criar um “circuito” (middleware) que inserido 4. Sistema de Gerenciamento de Bancos de Dados ou Banco de Dados..

(35) ˜ 2.4 PADROES OMG - OBJECT MANAGEMENT GROUP. 13. entre os paradigmas realize de forma transparente a troca de dados. Ou seja, cria-se uma camada de persistência de dados capaz de converter os objetos de negócio do sistema em tabelas do banco e dados relacional. Apesar da existência de vários SGBDs orientados a objetos [LC97], estes ainda não se tornaram um padrão da ind´ ustria. Ainda, os SGBDs relacionais possuem algumas vantagens como performance e capacidade de processamento de consultas SQL. Já existem várias ferramentas que realizam a “ponte” entre os modelos OO e relacional, entre elas: TopLink [Ora05b], Hibernate [Hib05], JDO [JR03]. Essas ferramentas utilizam o conceito de camada de persistência transparente5 (persistent layer transparency) que realiza a transforma¸cão dos objetos em tabelas e relacionamentos de um banco de dados relacional. Geralmente, o usuário necessita configurar o middleware indicando o mapeamento entre suas classes e as tabelas do banco de dados. Uma vez configuradas as regras de mapeamento, os usuários não precisam mais se preocupar com as tabelas e os relacionamentos, já que a persistência e recupera¸cão dos dados será realizada de forma transparente pela camada de persistência. E mais, o desenvolvedor não precisará escrever consultas SQL para atualiza¸c˜ ao e recupera¸cão de dados. Um sistema que utiliza uma camada de persistência convencional torna-se “engessado”, pois altera¸cões no SGBD necessitam de reescrita de código. Já um sistema com camada de persistência transparente possibilita a substitui¸c˜ ao do SGBD sem que haja reescrita de códigofonte. Existem várias propostas de padrões de mapeamento entre os modelos OO e ER, no entanto, não existe um padrão de facto. Este trabalho segue o padrão de mapeamento proposto por Ambler [Amb00]. Segundo o padrão proposto por Scott Ambler, um atributo da classe corresponde a zero ou mais colunas de uma tabela em um banco de dados relacional. Zero, pois nem todos os atributos da classe são persistentes, alguns atributos são calculados. Mais colunas, pois um atributo como endere¸co deve dar origem a várias colunas como rua, n´ umero, bairro, etc. O padrão propõe também que uma classe de negócio seja mapeada para uma ou mais tabelas, e prevê a implementa¸cão de heran¸cas e relacionamentos. Alguns desses tópicos serão abordados com mais detalhes ao longo deste trabalho à medida em que se fizer necessário. 2.4 2.4.1. Padr˜ oes OMG - Object Management Group MOF. Atualmente, com as grandes empresas inseridas na era da computa¸c˜ ao, cada uma possui seu próprio padrão de dados. O grande problema é que cada empresa armazena seus dados em diferentes formatos, complicando cada vez mais a comunica¸c˜ ao eletrônica entre as empresas ´ envolvidas. E poss´ıvel tomar como exemplo um banco que realiza milhares de transferências eletrônicas diariamente, e grande parte dessas transa¸c˜ oes envolvem institui¸c˜ oes que utilizam vários padrões de arquivos. As institui¸c˜ oes envolvidas precisam encontrar um padrão para intercambiar tais arquivos. Desse problema surgiu a necessidade de um padrão para definir o formato de armazenamento e compartilhamento de dados. 5 A aplica¸ca õ utiliza a mesma API de acesso aos dados, independentemente da forma de armazenamento e do SGBD utilizado. O conceito de camada de persistência transparente simplifica a aplica¸c˜ ao e aumenta a manutenibilidade, escondendo os detalhes da implementa¸ca õ de persistência dos dados..

(36) ˜ DE CODIGO: ´ ˜ GERAC ¸ AO CONCEITOS, PADROES E TECNOLOGIAS. 14. O padrão MOF - Meta-Object Facility é o padrão OMG [BRJ98] que especifica uma linguagem abstrata para descri¸cão de outras linguagens. MOF também é um meta-metamodelo e sua sintaxe abstrata é utilizada para descrever metamodelos. A arquitetura MOF possui quatro camadas como ilustra a tabela 2.1. N´ıvel M0. Camada dados. M1. metadados / modelos. M2. meta-metadados / metamodelos. M3. meta-metamodelo. Exemplos Registros de uma tabela de um BD, instˆ ancias de classes Java Tabelas, colunas de um BD, classes, métodos e atributos Java Defini¸c˜ ao dos elementos de uma base dados como Tabela, Coluna, descri¸c˜ ao dos construtores da linguagem Java MOF. Tabela 2.1 Arquitetura MOF. A figura mostra que cada n´ıvel M(x), onde x<3, é descrito utilizando construtores definidos no n´ıvel M(x+1). O n´ıvel M3 é o n´ıvel mais alto, enquanto que o n´ıvel 0 é o mais baixo e representa os dados. São elementos do n´ıvel 0 as instâncias de classes da linguagem, os registros de uma tabela de banco de dados, etc. O n´ıvel 1 representa os metadados ou modelos, são eles que definem a estrutura dos dados, podendo ser as tabelas e colunas de um banco de dados ou as classes da linguagem Java. O n´ıvel 2 é o n´ıvel dos meta-metadados ou metamodelos, são os elementos que definem os modelos e conceitos como tabela, coluna, classe, etc. Finalmente, o n´ıvel 3 ou meta-metamodelo é o responsável pela defini¸c˜ ao dos metamodelos. A cria¸c˜ ao de um metamodelo para definir o padrão XML[Har01] e seus elementos será utilizada para ilustrar a utiliza¸cão do padrão MOF na cria¸c˜ ao de metamodelos. Um documento XML pode ser descrito como um conjunto de nós. Estes nós podem ser: elementos, atributos e texto, assim como no Exemplo 2.1. Exemplo 2.1 Um t´ıpico documento XML 1 <a l u n o s > 2 <p e s s o a nome=”Maria”/> 3 <p e s s o a nome=”J o s e ”/> 4 <c u r s o >C i e n c i a da Computacao</c u r s o > 5 </p e s s o a > 6 </a l u n o s >. O exemplo contém os seguintes nós do tipo elemento (ElementNode), segundo a ordem em que aparecem: alunos, pessoa, pessoa, curso. Os nós do tipo atributo (AttributeNode) são: nome e nome. O u ńico nó do tipo texto (TextNode) é “Ciencia da Computacao”. A partir do exemplo, pode-se afirmar sobre a estrutura de um documento XML que: Cada n´ o possui um nome (em nós de tipo texto o nome é formado pelo próprio texto); N´ os elemento podem conter outros nós elemento, nós atributo ou nós texto; N´ os atributo possuem um valor (e.g. nome tem valor Maria); e.

(37) ˜ 2.4 PADROES OMG - OBJECT MANAGEMENT GROUP. 15. Em cada documento XML existe apenas um elemento raiz.. A Figura 2.12 exibe uma poss´ıvel representa¸c˜ ao, em MOF, do modelo da linguagem XML.. Figura 2.12 Representa¸cão da linguagem XML em MOF. As caixas na figura representam classes MOF. Existe uma classe abstrata chamada Node com um atributo name: é esta classe que captura o fato de que todos os nós possuem um nome. A classe Node é uma generaliza¸cão de classes não-abstratas que representam os três diferentes tipos de nós: ElementNode, TextNode e AttributeNode. Entre as classes ElementNode e Node existe uma associa¸cão MOF chamada contains que captura o fato de que cada classe ElementNode pode conter zero ou mais nós internos. Para limitar a apenas um a quantidade de elementos raiz, foi criada uma subclasse de ElementNode chamada RootNode para representar o elemento raiz. O nome do documento XML é armazenado no atributo documentName. O metamodelo captura toda a informa¸c˜ ao que diz respeito à estrutura dos documentos XML, desta forma será identificado como metamodelo da linguagem XML. Como percebe-se, o padrão MOF não foi utilizado para representar a gramática, mas sim a estrutura da linguagem XML. ´ importante saber que a especifica¸c˜ E ao MOF não define nenhuma representa¸c˜ ao textual ou gráfica da linguagem. O metamodelo apresentado foi ilustrado utilizando-se a nota¸c˜ ao UML. A Figura 2.13 ilustra os principais elementos do padrão MOF e como eles estão relacionados entre si. ´ interessante notar a organiza¸cão dos elementos. Todas as classes são subclasses do eleE mento modelo (ModelElement). O classifier é uma interface que define classes (Class), tipos de dados (DataType) e associa¸cões (Association). Um namespace pode ser visto como um agrupador de elementos. Os elementos contidos em um namespace recebem o nome de feature e podem ser comportamentais (BehavioralFeature) e estruturais (StructuralFeature). Opera¸cões ou métodos (Operation) e exce¸cões (Exception) são features comportamentais. Os atributos (Attribute) e referências (Reference) são features estruturais. Tanto (Package) como Classifier são subclasses de GeneralizableElement e portanto podem ser generalizados..

(38) ˜ DE CODIGO: ´ ˜ GERAC ¸ AO CONCEITOS, PADROES E TECNOLOGIAS. 16. Figura 2.13 Principais elementos do padrão MOF. 2.4.2. XMI. XML Metadata Interchange [GDB02] é o padrão da OMG para armazenamento e compartilhamento de metamodelos MOF através de documentos XML. O padrão define um conjunto de regras para gerar DTDs ou XML Schemas a partir de metamodelos MOF e as regras para serializa¸cão de instâncias desses metamodelos. Analogamente, o padrão possibilita o armazenamento e intercâmbio de modelos UML na forma de documentos XML. As principais caracter´ısticas do padrão XMI são: Provê um padr˜ ao para representa¸c˜ ao de objetos em XML, permitindo o intercˆ ambio efetivo de objetos; Especifica como criar XML Schemas a partir de modelos; Permite a cria¸c˜ ao de documentos XML básicos que, mais tarde, possam evoluir através da adi¸cão de elementos à estrutura; e Os usu´ arios não precisam conhecer a fundo a linguagem XML para utilizar o padrão.. A versão 2.0 do padrão XMI permite, adicionalmente, o mapeamento de modelos UML em XML Schemas. Como o padrão define o mapeamento dos objetos em XML, não será necessário definir a forma pela qual esses objetos serão intercambiados ou transformados, já que todo o processo será realizado por um software capaz de interpretar o padrão XMI..

(39) ˜ 2.4 PADROES OMG - OBJECT MANAGEMENT GROUP. 17. Figura 2.14 Representando uma classe em XMI. A Figura 2.14 apresenta um modelo UML contendo uma classe Carro e os atributos ano e marca. Logo abaixo, tem-se um documento XMI que armazena os dados de um objeto da classe Carro. Este documento pode ser validado por um XML Schema produzido a partir do modelo. Um documento XMI é capaz de armazenar qualquer modelo MOF e suas instâncias, e de definir vários aspectos envolvidos na descri¸c˜ ao de objetos, entre eles: representar objetos na forma de elementos e atributos XML; fazer a liga¸c˜ ao entre objetos de um mesmo arquivo ou distribu´ıdos em vários arquivos; identificar objetos e referenciá-los; controlar a vers˜ ao dos objetos em um modelo XMI; e validar documentos XMI através de DTDs e XML Schemas. Os dois principais tipos de documentos definidos pelo padrão XMI são os próprios documentos XMI e XMI Schema. Um documento XMI permite armazenar, por exemplo, os objetos de um diagrama de objetos UML. Um documento XMI Schemas possibilita o armazenamento de modelos orientados a objetos. Essa versatilidade do padrão XMI para representar dados e meta-dados é uma de suas principais caracter´ısticas. A Figura 2.15 mostra um diagrama de classes com uma classe Carro e uma classe Pessoa. A associa¸cão da classe Carro com a classe Pessoa dá origem ao atributo motorista. O relacionamento também indica que um carro pode ter zero ou mais objetos da classe Pessoa.. Figura 2.15 Representa¸cão das classes Carro e Pessoa. ´ poss´ıvel representar instâncias das classes apresentadas na figura através de atributos ou E elementos XML. O Exemplo 2.2 mostra um trecho de documento XMI para representar instâncias das classes do modelo. Neste caso, tem-se um objeto carro que possui dois motoristas..

(40) ˜ DE CODIGO: ´ ˜ GERAC ¸ AO CONCEITOS, PADROES E TECNOLOGIAS. 18. Exemplo 2.2 Trecho de documento XMI 1 <Carro m o t o r i s t a=”P1 P2”/> 2 <M o t o r i s t a xmi : i d=”P1”/> 3 <M o t o r i s t a xmi : i d=”P2”/>. O atributo XML motorista no elemento carro representa as referências para os elementos Motorista. O valor do atributo motorista contém os identificadores de cada um dos elementos Pessoa que representa o motorista do carro. A representa¸cão dos objetos do modelo poderia igualmente ser realizada utilizando elementos XML. Neste caso seriam utilizados links para identificar e referenciar os objetos. Desta forma cada referência apontaria para o identificador do objeto associado. Todavia, o elemento conteria apenas referências para elementos com os dados do motorista. O Exemplo 2.3 ilustra um poss´ıvel documento XMI que utiliza objetos para representar os objetos. Exemplo 2.3 Trecho de documento XMI 1 2 3 4 5 6. <Carro> <m o t o r i s t a h r e f=”#P1”/> <m o t o r i s t a h r e f=”#P2”/> </Carro> <Pessoa xmi : i d=”P1”/> <Pessoa xmi : i d=”P2”/>. Como percebe-se, foram criados dois elementos motorista dentro de Carro, no atributo href destes elementos está uma URI que aponta para os elementos do documento que contêm as defini¸cões dos objetos Pessoa. A relevância do padrão XMI para o entendimento do resto desse trabalho está na capacidade de armazenamento modelos UML, mais especificamente, os elementos de um diagrama de classes. A versão 1.2 do padrão XMI foi utilizada para representar os modelos que serão utilizados durante a implementa¸cão do ambiente XO2 .. Figura 2.16 Representa¸cão da classe Carro. A Figura 2.16 ilustra uma classe Carro que contém apenas um atributo ano do tipo int. O Exemplo 2.4 ilustra trechos de um documento XMI para armazenar o modelo. Exemplo 2.4 Trecho de documento XMI 1 ... 2 <UML: C l a s s xmi . i d = ’ sm $ 23d278 : 1 0 1 8 6 dedd48 :−7 f f 6 ’ 3 name = ’ Carro ’ v i s i b i l i t y = ’ p u b l i c ’> 4 <UML: C l a s s i f i e r . f e a t u r e > 5 <UML: A t t r i b u t e xmi . i d = ’ sm $ 23d278 : 1 0 1 8 6 dedd48 :−7 f e 9 ’ 6 name = ’ ano ’ v i s i b i l i t y = ’ p r i v a t e ’>.

(41) 2.5 JMI. 7 8 9 10 11 12 13 14 15. 19. <UML: S t r u c t u r a l F e a t u r e . type> <UML: DataType xmi . i d r e f = ’ sm $ 23d278 : 1 0 1 8 6 dedd48 :−7 fde ’/> </UML: S t r u c t u r a l F e a t u r e . type> </UML: A t t r i b u t e > </UML: C l a s s i f i e r . f e a t u r e > </UML: C l a s s > ... <UML: DataType xmi . i d = ’ sm $ 23d278 : 1 0 1 8 6 dedd48 :−7 fde ’ name = ’ i n t ’/> . . .. A declara¸cão da classe Carro é expressa pelo código encontrado entre as linhas 2 e 12. Foram exibidos apenas os atributos mais importantes, no caso id, name e visibility. Primeiramente, tem-se o xmi.id, que é um identificador u ńico dentro do modelo e poderá ser utilizado para referenciar a classe. O formato do id varia de acordo com a ferramenta utilizada. Prosseguindo, o atributo name identifica o nome da classe. Em visibility será armazenado o identificador de visibilidade da classe (public, protected, private). A linha 4 cria um compartimento para os features (atributos, métodos) de um classifier. Para o exemplo apresentado, o u ńico elemento será o atributo ano, declarado na linha 5. Assim como o elemento class, o elemento attribute possui id, name e visibility. Além disso, deve possuir um tipo. O atributo ano é do tipo inteiro, assim na linha 8, há um elemento datatype que referencia o tipo int declarado pelo código da linha 14. O exemplo ilustra como a flexibilidade fornecida pelo padrão XMI torna os documentos mais extensos. A Figura 2.17 mostra uma visão geral dos principais elementos da linguagem UML e como eles relacionam entre si. 2.5. JMI. O padrão Java Metadata Interface [Sun05d] permite a interoperabilidade entre o padrão MOF e linguagem Java. Se XMI provê o armazenamento de modelos MOF em documentos XML, JMI torna capaz a utiliza¸cão de modelos MOF em aplica¸c˜ oes Java. JMI é um servi¸co extens´ıvel que facilita o acesso de aplicativos escritos na plataforma Java a um repositório de metadados descritos em MOF. As ferramentas que utilizam JMI deixam expostos todos os metadados utilizados, facilitando assim a cria¸c˜ ao de plug-ins ou extensões. JMI provê: Um framework de metadados que fornece um modelo de programa¸c˜ ao Java para acesso aos metadados contidos em um repositório;. oes Java; e Um framework para integrar e estender ferramentas e aplica¸c˜ Integra¸c˜ ao com modelos OMG e sua arquitetura de metadados.. Finalmente, como uma implementa¸c˜ ao em Java para acesso a metadados descritos em MOF, JMI especifica um conjunto de regras para gerar um conjunto de interfaces Java que possibilitem a manipula¸cão da informa¸cão contida em instâncias do metamodelo..

(42) ˜ DE CODIGO: ´ ˜ GERAC ¸ AO CONCEITOS, PADROES E TECNOLOGIAS. 20. Figura 2.17 Visão geral dos principais elementos da linguagem UML. 2.6. MDR. O MDR - Metadata Repository [MDR05] é um repositório de metadados MOF. O repositório é capaz de interpretar e armazenar qualquer metamodelo MOF. Metamodelos e metadados podem ser importados e exportados do MDR utilizando o padrão XMI. Sendo assim, os metadados armazenados no repositório podem ser manipulados através de JMI. O MDR é desenvolvido como parte do projeto NetBeans [Net05] e na prática fornece aos sistemas implementados em Java um acesso direto a repositórios de documentos MOF. Este acesso é promovido através da integra¸c˜ ao de três padrões existentes: MOF (defini¸c˜ ao de metamodelos), XMI (armazenamento de metamodelos em documentos XML) e JMI (API Java para acesso a metadados). O MDR permite que uma aplica¸c˜ ao leia e manipule documentos XMI facilmente sem que haja uma necessidade do conhecimento do padrão. 2.7. MDA. O MDA - Model Driven Architecture [KWB03] é um framework para desenvolvimento de software definido pela OMG totalmente baseado em modelos e transforma¸c˜ oes de modelos. O MDA define como separar especifica¸c˜ ao e implementa¸c˜ ao de um sistema em uma plataforma..

(43) 21. 2.7 MDA. Figura 2.18 Ciclo de Desenvolvimento Tradicional do RUP. O MDA permite: Especificar um sistema independentemente de plataforma; Escolher uma plataforma espec´ıfica para implementa¸c˜ ao do sistema; e Transformar a especifica¸c˜ ao do sistema em uma especifica¸c˜ ao para uma determinada plataforma. Os três principais objetivos da arquitetura MDA são: portabilidade, interoperabilidade e reusabilidade através de uma separa¸cão arquitetural de preocupa¸c˜ oes 6 . A utiliza¸cão do MDA não requer grandes altera¸c˜ oes no ciclo de desenvolvimento de software iterativo e incremental do RUP [Kru00]. O ciclo de desenvolvimento tradicional como mostra a Figura 2.18 tem como fases geradoras de modelos (de análise e projeto) as fases 1 a 3 (requisitos, an´ alise e projeto). Contudo, tais artefatos come¸cam a perder seu valor quando é iniciada a fase ` medida que o sistema é alterado, a distância entre o que foi modelado de implementa¸cão. A ´ preciso disciplina e integra¸c˜ nas primeiras fases e o código implementado aumenta. E ao entre o analista e o desenvolvedor para que toda altera¸c˜ ao ou corre¸c˜ ao do código-fonte seja refletida nos modelos de Análise e Projeto e vice-versa. O ciclo de desenvolvimento MDA, como mostra a Figura 2.19, é bem parecido com um ciclo tradicional de desenvolvimento. A principal diferen¸ca entre o processo MDA e o processo tradicional é que as transforma¸cões entre os modelos no processo tradicional são feitas manualmente e no MDA são realizadas com o aux´ılio de ferramentas, eliminando a necessidade de 6. Segundo este conceito, é essencial separar as partes mut´ aveis das partes triviais de um sistema para conseguir reutiliza¸ca õ das partes triviais..

(44) 22. ˜ DE CODIGO: ´ ˜ GERAC ¸ AO CONCEITOS, PADROES E TECNOLOGIAS. Figura 2.19 Ciclo de Desenvolvimento MDA. que altera¸cões realizadas no código ou em um diagrama sejam refletidas nos outros diagramas através de um processo manual. A Figura 2.20 ilustra as transforma¸c˜ oes executadas por uma ferramenta MDA. Na arquitetura MDA, transforma¸c˜ ao é o processo de produzir um modelo a partir de outro já existente. Essa transforma¸cão é realizada através de diretivas conhecidas como regras de transforma¸cão. O MDA possui três diferentes de modelos (PIM, PSM e código-fonte) que são sucintamente descritos a seguir. 2.7.1. PIM - Plataform Indepent Model. O PIM, como o próprio nome indica, modelo independente de plataforma e tecnologia, é o primeiro modelo definido e apresenta um alto n´ıvel de abstra¸c˜ ao. Um modelo PIM descreve um modelo de negócio e os detalhes de como as funcionalidades do sistema serão implementadas sem especificar detalhes sobre as tecnologias utilizadas. 2.7.2. PSM - Platform Specific Model. O PSM é um modelo de sistema para uma determinada plataforma e tecnologia, ele contém detalhes da implementa¸cão e da tecnologia empregada. O PSM é oriundo do PIM e é produzido de acordo com uma série de regras de transforma¸c˜ ao previamente definidas. Um PIM pode ser transformado em vários PSMs. Para cada plataforma tecnológica dever´ a ser gerado um PSM diferente..

(45) 23. 2.7 MDA. 2.7.3. C´ odigo-Fonte. A transforma¸cão do modelo PSM em código é a u ´ltima etapa do processo MDA de desenvolvimento. Com o PSM especificado para uma tecnologia ou plataforma, esta transforma¸c˜ ao ocorre de forma bastante simples, utilizando apenas as regras de transforma¸c˜ ao já definidas. Assim, o código poderá ser gerado automaticamente sem a interferência humana.. Figura 2.20 Transforma¸cões MDA. 2.7.4. Transforma¸c˜ oes. Como abordado anteriormente, o MDA é totalmente baseado em modelos e transforma¸c˜ oes entre modelos. As transforma¸cões podem ser manuais ou automáticas. A Figura 2.21 ilustra detalhadamente as transforma¸cões entre os modelos PIM e PSM.. Figura 2.21 Transforma¸cões MDA. Através da Figura 2.21 percebe-se que no PIM são detalhados tipos e padrões independentes da plataforma utilizada. O PSM contém os mesmos tipos e padrões, desta vez reescritos com os detalhes da plataforma na qual o sistema será implementado. O MDA ainda está em fase de evolu¸c˜ ao e estabelecimento na ind´ ustria. Alguns desafios ainda persistem, entre eles a transforma¸cão automática entre os modelos PIM e PSM que atualmente.

(46) ˜ DE CODIGO: ´ ˜ GERAC ¸ AO CONCEITOS, PADROES E TECNOLOGIAS. 24. é realizada pelas ferramentas através da escrita dos templates. Acredita-se que, no futuro, o MDA torne-se um padrão tanto na área acadêmica quanto na ind´ ustria de desenvolvimento de software por trazer benef´ıcios como: ao precisa escrever o código-fonte básico; Produtividade: o desenvolvedor n˜ Portabilidade: com a separa¸c˜ ao do PIM e do PSM, um projeto desenvolvido em MDA pode ser facilmente portável, bastando a cria¸c˜ ao de um modelo espec´ıfico para a plataforma; Interoperabilidade: visto que ele permite o relacionamento entre diferentes modelos PSM; e Manutenibilidade: altera¸c˜ oes no modelo PIM são refletidas diretamente no modelo PSM.. 2.8. Velocity. Em seu in´ıcio, a World Wide Web era constitu´ıda puramente por páginas estáticas criadas com a linguagem HTML. Com o passar do tempo, os desenvolvedores sentiram a necessidade de produzir conte´ udo dinâmico e personalizado. Linguagens como Perl [WCO00], ASP [Wei00], PHP [WT04] e JSP [Ber03] fornecem uma infra-estrutura completa para a cria¸c˜ ao de conte´ udo dinâmico para websites. O padrão MVC - Model View Controller [GHJV95] surgiu para separar a interface gráfica do sistema, assim o designer preocupa-se apenas com a parte visual, enquanto que os desenvolvedores se preocupam com a parte funcional e dinâmica do site. Segundo o padrão, o modelo ou regras de negócio devem ser separados da apresenta¸c˜ ao e do controlador. A Figura 2.22 ilustra o padrão MVC.. Figura 2.22 Padrão MVC.