Estudo Ida EVolta Codigo Docto UML

UM ESTUDO SOBRE A ENGENHARIA DE IDA E VOLTA ENTRE UML E JAVA
LUIS PAULO ALVES MAGALHES
UM ESTUDO SOBRE A ENGENHARIA DE IDA E VOLTA ENTRE UML E JAVA

Dissertao apresentada ao Programa de Ps-Graduao em Cincia da Computao do Instituto de Cincias Exatas da Universidade Federal de Minas Gerais como requisito parcial para a obteno do grau de Mestre em Cincia da Computao.
Orientador: Rodolfo Srgio Ferreira de Resende Coorientador: Antonio Maria Pereira de Resende
Belo Horizonte Julho de 2011
2011, Luis Paulo Alves Magalhes. Todos os direitos reservados.
Magalhes, Luis Paulo Alves. M188e Um estudo sobre a engenharia de ida e volta entre UML e Java / Luis Paulo Alves Magalhes. Belo Horizonte, 2011. xviii, 122 f. : il. ; 29cm Dissertao (mestrado) Universidade Federal de Minas Gerais Departamento de Cincia da Computao. Orientador: Rodolfo Srgio Ferreira de Resende. Coorientador: Antonio Maria Pereira de Resende. 1. Computao - Teses. 2. Engenharia de software Teses. 3. UML (Linguagem de modelagem padro) Teses. 4. Java (Linguagem de programao de computador) Teses. I. Orientador. II. Coorientador. III. Ttulo. CDU 519.6*32(043)
Resumo
No desenvolvimento de software, os modelos, dentre outros artefatos, podem facilitar o entendimento do software. Manter o cdigo e os modelos consistentes entre si no uma tarefa simples. Combinada com um processo iterativo e com as ferramentas adequadas, a engenharia de ida e volta permite que o cdigo e o modelo permaneam sincronizados. A UML tornou-se a representao grca mais presente em projetos de sistema de software orientado a objeto e a linguagem Java tornou-se uma das linguagens de programao mais utilizadas atualmente. Vrios trabalhos no incio dos anos 2000 discutiram a questo de navegar de UML para Java e de Java para UML, no contexto da teoria e das ferramentas CASE. Apesar da crescente popularidade, h pouca avaliao relatada sobre o uso do desenvolvimento baseado em UML. As duas tecnologias, UML e Java, evoluram de l pra c e muitos trabalhos se tornaram obsoletos. As ferramentas CASE devem ser expostas uma avaliao adequada a m de determinar se elas so ecazes de ajudar os usurios em sua meta. Este trabalho procurou avanar a discusso sobre o estado da arte da questo da engenharia de ida e volta entre as novas caractersticas da UML e as novas caractersticas da plataforma Java. Analisamos a transcrio do modelo para o cdigo e vice-versa, e tambm a interao da ferramenta com o usurio (desenvolvedor de software) durante o mapeamento de UML para Java e vice-versa. A capacidade de transcrio das ferramentas de UML para Java no teve grandes mudanas, considerando trabalhos dos ltimos anos. A interao da ferramenta com o usurio pode ser melhorada. Palavras-chave: Engenharia de Ida e Volta, Engenharia Reversa, Ferramentas Case, Mapeamento Modelo-Cdigo.
vii
Abstract
In software development, models, among other artifacts, can facilitate the understanding of the software. To Keep the code and models consistent with each other is not a simple task. Combined with an iterative process and with the right tools, forward and backward engineering allows code and model to stay synchronized. The UML has become the standard for graphical representation of object-oriented software systems design and the Java language has become one of the most widely used programming languages. Several studies in the early 2000 discussed the issue of how to translate from UML for Java and from Java to UML in the context of theory and CASE tools. The two languages, UML and Java, have evolved and this opens space for new studies. CASE tools should be exposed to a proper assessment to determine whether they are eective in helping users in their goals. This dissertation discusses some aspects related to the round trip engineering between UML and the Java language. The capability of tools transcription of UML for Java did not have major changes, considering the work of recent years. The interaction with the user of the tool can be improved. Keywords: Round-Trip Engineering, Reverse Engineering, Case Tools, ModelCode Mapping
ix
Lista de Figuras
2.1 Alteraes feitas no destino T devem ser reetidas de volta para a origem S. Portanto, algum tipo de transformao reversa transR necessria [Hettel et al., 2008]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relao entre Nvel de Abstrao, Engenharia Frente e Engenharia Reversa. [Harandi & Ning, 1990] . . . . . . . . . . . . . . . . . . . . . . . . . Engenharia Frente e Engenharia Reversa [Angyal et al., 2006]. . . . . . . Hierarquia dos diagramas UML [UML, 2011]. . . . . . . . . . . . . . . . . Engenharia frente de diagrama de classe realizado pela ferramenta StarUML: Relacionamento de Composio. . . . . . . . . . . . . . . . . . . . Engenharia frente de diagrama de classe realizado pela ferramenta StarUML: Relacionamento de Agregao. . . . . . . . . . . . . . . . . . . . . Ciclo de melhoria da ferramenta CASE [Traduzido: [Sensalire et al., 2009]]. Esteretipo instantiate [Superstructure, 2011]. . . . . . . . . . . . . . . . Tipos de extremidades de associao no relacionamento de associao simples [Superstructure, 2011]. . . . . . . . . . . . . . . . . . . . . . . . . . . Associao binria e ternria [Superstructure, 2011]. . . . . . . . . . . . . Agregao [Superstructure, 2011]. . . . . . . . . . . . . . . . . . . . . . . . Relacionamento de Composio [Superstructure, 2011]. . . . . . . . . . . . Adornos da extremidade de associao: navegabilidade, multiplicidade, sentena de propriedades e nomes da extremidade de associao [Superstructure, 2011]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Herana Simples entre classes. . . . . . . . . . . . . . . . . . . . . . . . . Herana Mltipla entre interfaces. . . . . . . . . . . . . . . . . . . . . . . .
9 11 13 17 18 19 31 39 41 41 41 42
2.2 2.3 2.4 2.5 2.6
3.1 3.2 3.3 3.4 3.5 3.6 3.7
43 45 45 46 47 48
3.8 3.9
3.10 Classes concretas, Classes abstratas e Interfaces. . . . . . . . . . . . . . . . 3.11 Diagrama de Classe [Superstructure, 2011] (Adaptado). . . . . . . . . . . . 3.12 Um diagrama de classe correspondente a um diagrama de estrutura composta. [Superstructure, 2011] . . . . . . . . . . . . . . . . . . . . . . . . . xi
3.13 Diagrama de estrutura composta da classe Car com a parte Wheel (i). . . 3.14 Diagrama de estrutura composta da classe Car com a parte Wheel (ii). . . 3.15 Diagrama de sequncia com o fragmento combinado alt. . . . . . . . . . . . 3.16 Diagrama de sequncia com o fragmento combinado loop gerando ambiguidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.17 Modelo elaborado na ferramenta Astah* para o estudo de caso 1. . . . . . 3.18 Cdigo gerado pela Astah* para o modelo da Figura 3.17. . . . . . . . . . 3.19 Modelo elaborado na ferramenta RSA para o estudo de caso 1. . . . . . . . 3.20 Cdigo gerado pela RSA a partir do modelo da Figura 3.19. . . . . . . . . 3.21 Modelo elaborado na ferramenta EA para o estudo de caso 1. . . . . . . . 3.22 Cdigo gerado pela RSA a partir do modelo da Figura 3.21. . . . . . . . . 3.23 Modelo elaborado na ferramenta Astah* para o estudo de caso 2(i). . . . . 3.24 Cdigos gerados pela Astah* para o modelo da Figura 3.23. . . . . . . . . 3.25 Modelo elaborado na ferramenta RSA para o estudo de caso 2(i). . . . . . 3.26 Cdigos Gerados Pela RSA Para o Modelo da Figura 3.25 . . . . . . . . . 3.27 Modelo elaborado na ferramenta EA referente ao estudo de caso 2(i). . . . 3.28 Cdigo gerado pela EA a partir do modelo da Figura 3.27. . . . . . . . . . 3.29 Modelo elaborado na ferramenta Astah* referente ao estudo de casoe 2(ii). 3.30 Cdigo gerado pela EA a partir do modelo da Figura 3.29. . . . . . . . . . 3.31 Modelo elaborado na ferramenta RSA referente ao estudo de caso 2(ii). . . 3.32 Cdigo gerado pela EA a partir do modelo da Figura 3.31. . . . . . . . . . 3.33 Modelo elaborado na ferramenta EA referente ao estudo de caso 2(ii). . . . 3.34 Cdigo gerado pela EA a partir do modelo da Figura 3.33. . . . . . . . . . 3.35 Modelo elaborado na ferramenta Astah* referente ao estudo de caso 3. . . 3.36 Modelo elaborado na ferramenta RSA referente ao estudo de caso 3. . . . . 3.37 Modelo elaborado na ferramenta EA referente ao estudo de caso 3. . . . . 3.38 Cdigo gerado pelas ferramentas referente ao modelo das Figuras 3.35, 3.36 e 3.37. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.39 Modelo elaborado na ferramenta Astah* referente ao estudo de caso 4. . . 3.40 Classe Window gerada pela ferramenta Astah*. . . . . . . . . . . . . . . . 3.42 Tipos pr-denidos pela ferramenta Astah*. . . . . . . . . . . . . . . . . . 3.43 Erro na engenharia reversa do estudo de caso 4. . . . . . . . . . . . . . . . 3.44 Modelo elaborado na ferramenta RSA referente ao estudo de caso 4. . . . . 3.45 Cdigo gerado pela RSA a partir do modelo da Figura 3.44. . . . . . . . . 3.46 rea de congurao que habilita a utilizao de classes de bibliotecas especcas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
49 49 51 51 52 52 53 53 54 54 55 56 56 57 58 58 59 59 60 60 61 61 64 64 65 66 67 68 69 69 70 72 73
3.41 Mensagem enviada ao usurio perguntando sobre a criao do novo tipo Area. 68
3.47 Transformao criada na RSA para gerar o cdigo do modelo do estudo de caso 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.48 Modelo elaborado na ferramenta EA referente ao estudo de caso 4. . . . . 3.49 Cdigo gerado pela EA a partir do modelo da Figura 3.48. . . . . . . . . . 3.50 Interface para importar bibliotecas. . . . . . . . . . . . . . . . . . . . . . . 3.51 Interface para importar bibliotecas. . . . . . . . . . . . . . . . . . . . . . . 3.52 Erro ocorrido na gerao de cdigo. . . . . . . . . . . . . . . . . . . . . . . 3.53 Modelo elaborado na ferramenta Astah* para o estudo de caso 5(i). . . . . 3.54 Mensagem exibida ao usurio solicitando uma escolha. . . . . . . . . . . . 3.55 Classicador estruturado Car criado a partir do diagrama de classes. . . . 3.56 Cdigo das classes Car, Engine e Wheel. . . . . . . . . . . . . . . . . . . . 3.57 Modelo elaborado na ferramenta RSA para o estudo de caso 5(i). . . . . . 3.58 Criao do diagrama de estrutura composta a partir da classe Car. . . . . 3.59 Cdigo gerado pela RSA a partir do modelo da Figura 3.57. . . . . . . . . 3.60 Diagrama de estrutura composta criado diretamente. . . . . . . . . . . . . 3.61 Mensagem exibida ao usurio solicitando o que usurio deseja fazer. . . . . 3.62 Modelo elaborado na ferramenta EA referente ao estudo de caso 5(i). . . . 3.63 Cdigo gerado pela EA a partir do modelo da Figura 3.62. . . . . . . . . . 3.64 Cdigo gerado pela EA a partir do modelo da Figura 3.62 aps ajuste. . . 3.65 Modelo elaborado na ferramenta Astah* referente ao estudo de caso 5(ii). . 3.66 Cdigo gerado pela Astah* a partir do modelo da Figura 3.65. . . . . . . . 3.67 Modelo elaborado na ferramenta RSA referente ao estudo de caso 5(ii). . . 3.68 Cdigo gerado pela RSA a partir do modelo da Figura 3.67. . . . . . . . . 3.69 Interao do usurio com a ferramenta para a insero de uma parte num classicador estruturado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.70 Interface utilizada pela RSA para mostrar ao usurio a transformao de modelo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.71 Modelo elaborado na ferramenta EA referente ao estudo de caso 5(ii). . . . 3.72 Cdigo gerado pela EA a partir do modelo da Figura 3.71. . . . . . . . . . 3.73 Modelo elaborado na ferramenta Astah* referente ao estudo de caso 6(i). . 3.74 Cdigo gerado pela Astah* a partir do modelo da Figura 3.73. . . . . . . . 3.75 Modelo elaborado na ferramenta RSA referente ao estudo de caso 6(i). . . 3.77 Interface utilizada pela RSA permitindo ao usurio denir a rea de cobertura do fragmento combinado. . . . . . . . . . . . . . . . . . . . . . . . . . 3.78 Cdigo gerado pela RSA a partir do modelo da Figura 3.75. . . . . . . . . 3.79 Modelo elaborado na ferramenta EA referente ao estudo de caso 6(i). . . . xiii
73 74 75 76 77 78 78 78 79 79 80 80 81 82 82 83 83 84 85 85 85 86 86 87 87 88 91 91 92
3.76 Fragmento combinado inserido no diagrama de sequncia na ferramenta RSA. 93 93 93 94
3.80 3.81 3.82 3.83 3.84 3.85 3.86 3.87 3.88
Modelo elaborado na ferramenta Astah* referente ao estudo de caso 6 (ii). Cdigo gerado pela Astah* a partir do modelo da Figura 3.80. . . . . . . . Modelo elaborado na ferramenta RSA referente ao estudo de caso 6 (ii). . . Interface utilizada pela RSA permitindo ao usurio denir a rea de cobertura do fragmento combinado. . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de sequncia aps a insero do fragmento combinado loop. . . . Insero de uma chamada assncrona dentro do fragmento combinado loop. Diagrama de sequncia nal, aps ajustes. . . . . . . . . . . . . . . . . . . Cdigo gerado a patir do diagrama de sequncia da Figura 3.86 pela RSA. Modelo elaborado na ferramenta EA referente ao estudo de caso 6(ii). . . .
94 95 95 95 96 97 98 98 99
xiv
Lista de Tabelas
3.1 3.2 3.3 4.1 4.2 4.3 4.4 4.5 4.6 4.7 Critrios para seleo das ferramentas CASE . . . . . . . . . . . . . . . . . 28 Relao dos critrios de avaliao das ferramentas CASE. . . . . . . . . . . 32 Tabela sumrio, contendo as ferramentas, critrios e valores atribudos . . 101 Ferramentas que suportam UML e Java encontradas no Google e no Bing. Disponibilidade das ferramentas CASE para download e suas licenas. . . . Ferramentas aps a aplicao do critrio C3, C4 e C5. . . . . . . . . . . . . Aplicao do critrio C6: Informaes sobre o frum. . . . . . . . . . . . . Resposta aos e-mails enviados para o suporte das ferramentas CASE. . . . Conceituao das ferramentas no frum da UML [UML, 2011] . . . . . . . Ferramentas Selecionadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 105 105 106 106 106 108
xv
Sumrio
Resumo Abstract Lista de Figuras Lista de Tabelas 1 Introduo 1.1 1.2 1.3 Contextualizao e Motivao . . . . . . . . . . . . . . . . . . . . . . . Objetivos e Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . vii ix xi xv 1 1 4 6 7 7 10 11 14 14 15 15 16 16 17 18 27 27 29
2 Reviso Bibliogrca 2.1 Engenharia de Ida e Volta . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.1.3 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.3 2.4 Engenharia Frente . . . . . . . . . . . . . . . . . . . . . . . . Engenharia Reversa . . . . . . . . . . . . . . . . . . . . . . . . . Ferramentas de CASE . . . . . . . . . . . . . . . . . . . . . . . Importncia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estado Atual . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aplicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mapeamento Modelo-cdigo . . . . . . . . . . . . . . . . . . . . . . . . Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Planejamento e Execuo dos Estudos de Caso 3.1 3.2 Critrios para Seleo das Ferramentas CASE . . . . . . . . . . . . . . Critrios para Avaliao de Ferramentas CASE . . . . . . . . . . . . . . xvii
3.3 3.4
3.5
Pers da UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estudos de Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 ESTUDO DE CASO 1 - Esteretipos . . . . . . . . . . . . . . . 3.4.2 ESTUDO DE CASO 2 Associaes: Associao Simples, Agregao e Composio; Extremidades de associao. . . . . . . . . 3.4.3 ESTUDO DE CASO 3 Classes concretas, Classes Abstratas e Interfaces: extends e implements. . . . . . . . . . . . . . . . . . 3.4.4 ESTUDO DE CASO 4 - Classes, Interfaces e Anotaes . . . . 3.4.5 ESTUDO DE CASO 5 - Estrutura Composta . . . . . . . . . . 3.4.6 ESTUDO DE CASO 6 - Fragmento Combinado . . . . . . . . . Aplicao dos Estudos de Caso . . . . . . . . . . . . . . . . . . . . . . 3.5.1 ESTUDO DE CASO 1 - Esteretipos . . . . . . . . . . . . . . . 3.5.2 ESTUDO DE CASO 2 - Associaes: Associao Simples, Agregao e Composio; Extremidades de associao . . . . . . . . 3.5.3 ESTUDO DE CASO 3 - Classes concretas, Classes Abstratas e Interfaces: extends e implements . . . . . . . . . . . . . . . . . 3.5.4 ESTUDO DE CASO 4 - Classes, Interfaces e Anotaes . . . . 3.5.5 ESTUDO DE CASO 5 - Estrutura Composta . . . . . . . . . . 3.5.6 ESTUDO DE CASO 6 - Fragmento Combinado . . . . . . . . .
34 35 39 39 44 45 47 50 50 52 54 63 65 77 90
4 Aspectos Prtico-Operacionais 103 4.1 Aplicao dos Critrios de Seleo das Ferramentas . . . . . . . . . . . 103 4.2 Cpia, Instalao e Utilizao das Ferramentas . . . . . . . . . . . . . . 108 5 Concluso 111 5.1 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 5.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Referncias Bibliogrcas 115
xviii
Captulo 1 Introduo
1.1 Contextualizao e Motivao
No desenvolvimento de software, os modelos, dentre outros artefatos, podem facilitar o entendimento. De acordo com Booch e outros [Booch et al., 2005], modelos so desenvolvidos para facilitar o entendimento do sistema que se est desenvolvendo, uma vez que permitem trabalhar em um nvel mais alto de abstrao. Abstrao uma habilidade humana fundamental que permite o projetista lidar com a complexidade [Khaled, 2009]. Modelagem consiste em construir uma abstrao de um sistema, concentrandose em aspectos de maior interesse e ignorando detalhes irrelevantes. Geralmente, a modelagem se concentra na construo de um modelo que seja simples o suciente para que uma pessoa possa compreend-lo completamente [Bruegge & Dutoit, 2009]. A modelagem um meio para lidar com a complexidade por permitir, de forma incremental, renar os modelos simples para outros mais detalhados que esto prximos da realidade. Conforme Booch e outros [Booch et al., 2005], com a modelagem, quatro objetivos so alcanados: Os modelos ajudam a visualizar o sistema como ele ou como se deseja que seja; Os modelos permitem especicar a estrutura e o comportamento de um sistema; Os modelos proporcionam um guia para a construo do sistema; Os modelos permitem documentar as decises tomadas. 1
Captulo 1. Introduo
A utilizao de modelos no desenvolvimento de software pode ter outras nalidades alm de facilitar o entendimento do sistema ou a comunicao entre os envolvidos na construo do sistema. Modelos abstratos de sistemas de software so criados e sistematicamente transformados para implementaes concretas [France & Rumpe, 2007]. o estado da arte fornecer a modelagem e a gerao de cdigo a partir dos modelos [Gessenharter, 2008]. De acordo com France e Rumpe [France & Rumpe, 2007], o tempo que se gasta construindo os modelos pode ser compensado com o tempo que seria gasto na construo de vrias linhas de cdigo, uma vez que este pode ser gerado sistematicamente a partir dos modelos. Por esta razo, a abordagem de Desenvolvimento Dirigido por Modelos (Model-Driven Development ) tem crescido nos ltimos anos. Segundo France e Rumpe [France & Rumpe, 2007], trabalhos atuais sobre metodologias de Engenharia Dirigida por Modelos (Model-Driven Engineering) tm se concentrado na produo de implementao e desenvolvimento de artefatos a partir de modelos detalhados. Modelos so criados para auxiliar em propsitos especcos, por exemplo, para apresentar para uma pessoa uma descrio entendvel de algum aspecto de um sistema ou para apresentar a informao de forma que possa ser mecanicamente analisada [France & Rumpe, 2007]. Os modelos so construdos em nvel mais alto de abstrao e podem ser transformados em cdigo automaticamente. A probabilidade de ocorrerem erros humanos durante a modelagem menor que durante a implementao [Ferdinand et al., 2008]. Em um ambiente de desenvolvimento de software centrado em modelo, modelos se tornam cidados de primeira classe no processo de desenvolvimento [Hettel et al., 2008]. Na fase de anlise do desenvolvimento do software, modelos so um dos primeiros artefatos do sistema de software, criados com base nos artefatos de requisitos. Atravs da tcnica de engenharia frente (forward engineering ), os modelos podem ser transformados em cdigo. Porm, os modelos tambm podem ser gerados em uma situao diferente. Na fase de manuteno, quando o software se encontra em grau de maturidade mais avanado, os modelos podem ser recuperados. Atravs da tcnica de engenharia reversa (reverse engineering ), os modelos podem ser gerados a partir do cdigo [Larman, 2008]. Uma vez que facilitar o entendimento do sistema um dos principais benefcios da utilizao de modelos, indispensvel que eles sejam consistentes entre si, ou seja, que eles estejam sincronizados. importante observar que desejvel que essa consistncia exista ao longo de todo o desenvolvimento de software para maximizar a utilizao dos modelos e o desenvolvedor usufrua de seus benefcios. medida que o software desenvolvido, mudanas ocorrem e os modelos cam desatualizados. A
1.1. Contextualizao e Motivao
engenharia reversa torna-se uma tcnica a ser aplicada aps cada iterao. Segundo Buss e Henshaw [Buss & Henshaw, 2010], a engenharia reversa uma disciplina da engenharia de software que inverte o tradicional ciclo de vida do software. De acordo com Antkiewicz e Czarnecki [Antkiewicz & Czarnecki, 2006], a engenharia de ida e volta (round-trip engineering ) consiste na aplicao da engenharia frente e da engenharia reversa. O objetivo da engenharia de ida e volta minimizar a distncia entre diferentes representaes do sistema. Ela fornece a tcnica que permite que os desenvolvedores circulem livremente entre o cdigo fonte e os modelos, apoiando a abordagem de desenvolvimento iterativo [Angyal et al., 2006]. Depois de sincronizar o modelo com o cdigo revisado, desenvolvedores podem escolher a melhor maneira de trabalhar: modicar mais o cdigo ou modicar o modelo. Segundo Wagelaar [Wagelaar, 2008], a engenharia de ida e volta til em situaes em que o modelo no fornece uma viso completa do software. Manter o cdigo e os modelos consistentes entre si no uma tarefa simples. No incomum que alguns modelos sejam deixados de lado [Kollman et al., 2002]. Segundo Pressman [Pressman, 2006], a manuteno de software pode representar mais de 60% do tempo de desenvolvimento de um software. Os quesitos inteligibilidade e manutenibilidade esto intimamente ligados. Em outras palavras, a facilidade de dar manuteno em um sistema de software est ligada facilidade de entender o sistema de software. difcil realizar manuteno em um software sem antes entendlo. A compreenso da funcionalidade e do comportamento de um sistema de software fundamental e facilitada por meio de sua abstrao, representada nos modelos. Tendo em vista os benefcios da utilizao dos modelos no desenvolvimento de software, percebe-se a importncia de mant-los sempre atualizados, isto , sempre reetindo o cdigo fonte atual. Atravs da combinao das tcnicas de engenharia frente e engenharia reversa, a engenharia de ida e volta garante cdigo e modelo consistentes. Combinada com um processo iterativo e com as ferramentas adequadas, a engenharia de ida e volta permite que o cdigo e o modelo permaneam sincronizados. Conforme Hidaka e outros [Hidaka et al., 2009], o modelo de transformao bidirecional - engenharia frente MODELO=>CDIGO e engenharia reversa CDIGO=>MODELO - desempenha um papel importante na manuteno da coerncia entre os dois modelos, e tem muitas aplicaes potenciais no desenvolvimento de software. A linguagem de representao UML (Unied Modeling Language ) [UML, 2011] tornou-se a representao grca mais presente em projetos de sistema de software orientado a objeto [Labiche, 2009] e a linguagem Java tornou-se uma das linguagens de programao mais utilizadas atualmente, sendo classicada em 1o lugar no TIBCO
Captulo 1. Introduo
desde 2005 [TIBCO, 2011]. Por este motivo, o nosso trabalho foi realizado utilizando essas duas tecnologias. Kollmann e outros [Kollman et al., 2002] armam que, devido s diferenas nos conceitos de desenho e nveis de implementao, no existe uma forma formalmente aceita para a interpretao da extrao de diagramas a partir do cdigo fonte. Um exemplo da diculdade de realizar engenharia reversa que existem conceitos no modelo de origem que no tm uma correspondncia no modelo de destino e vice-versa. Alm disso, pode haver vrios modelos fonte que esto sendo mapeados para um nico e mesmo modelo [Hettel et al., 2008]. Outros trabalhos ainda armam que tanto a especicao de Superestrutura da UML 2 [Superstructure, 2011] quanto a gerao de cdigo devem ser melhorados com relao a determinados aspectos [Gessenharter, 2008]. Vrios trabalhos no incio dos anos 2000 discutiram a questo de navegar de UML para Java e de Java para UML, no contexto da teoria e das ferramentas CASE [Kollman et al., 2002] [Harrison et al., 2000] [Gnova et al., 2003] [Briand et al., 2006] [Kollmann & Gogolla, 2001] [Gogolla & Kollmann, 2000] [Akehurst et al., 2007]. No entanto, conforme Anda e outros [[Anda et al., 2006] apud [Dzidek et al., 2008]], apesar da crescente popularidade, h pouca avaliao relatada sobre o uso do desenvolvimento baseado em UML. As duas tecnologias, UML e Java, evoluram de l pra c e muitos trabalhos se tornaram obsoletos. Segundo Sensalire [Sensalire et al., 2009], deve-se expor as ferramentas CASE a uma avaliao adequada a m de determinar se elas so ecazes para ajudar os usurios em sua meta. Apesar da armao, percebe-se a falta de uma orientao geral sobre como a interao entre ferramenta e usurio/desenvolvedor deve ser realizada, e muitos dos desenvolvedores de ferramentas efetuam pouca ou nenhuma avaliao.
1.2
Objetivos e Metodologia
O presente trabalho teve por objetivo estudar o estado da arte da engenharia de ida e volta, abordando alguns aspectos da relao entre UML e Java que so mais aderentes evoluo destas duas linguagens e das ferramentas de suporte. A abordagem do trabalho foi estudar a engenharia de ida e volta do ponto de vista das ferramentas. um trabalho com carter predominante de registrar a evoluo das duas linguagens e das ferramentas. Alm de analisar a consistncia entre modelo e cdigo, analisamos a informao na interao da ferramenta com o usurio (desenvolvedor de software), isto , como feito o mapeamento de UML para Java e vice-versa. Foram elaborados estudos de caso para analisar a consistncia entre modelo e cdigo e a interao da
1.2. Objetivos e Metodologia
ferramenta com o usurio durante a engenharia de ida e volta. Foram estabelecidos critrios para sistematizar a anlise. importante destacar que analisamos se existem informaes nas interaes, quando elas ocorrem e para quais aspectos as ferramentas permitem opes de mapeamento. A avaliao de dimenses tais como qualidade da interao, comunicabilidade, apreensibilidade so importantes mas no zeram parte do escopo do trabalho para efeito de simplicao. A importncia dos modelos e a forma como eles esto sendo considerados no contexto do desenvolvimento de software nos ltimos anos foram estudadas. No perodo de maro de 2010 a maro de 2011, foram pesquisadas e analisadas supercialmente, utilizando exemplos simples, diversas ferramentas CASE, entre livres e proprietrias. Pela complexidade da anlise, foram avaliadas apenas 3 ferramentas utilizando os critrios estabelecidos no captulo 3, a saber: Astah* [Astah*, 2011], Rational Software Architect [RSA, 2011] e Enterprise Architect [EA, 2011]. Existem vrios trabalhos, em diferentes contextos, que abordam a engenharia frente e a engenharia reversa. No primeiro caso, a engenharia frente de UML para Java analisada isoladamente; no segundo caso, a engenharia reversa de Java para UML analisada isoladamente; e, no terceiro caso, a combinao da engenharia frente e da engenharia reversa, que caracteriza a engenharia de ida e volta, analisada. Cabe ressaltar que h diferena entre a engenharia frente do primeiro caso e do terceiro caso. No primeiro caso, a engenharia frente extensa, o objetivo explorar ao mximo aspectos da ida de UML para Java; enquanto que, no terceiro caso, a engenharia frente no extensa. De modo anlogo, a engenharia reversa do segundo caso extensa e a do terceiro caso no extensa. Este trabalho no investiu de forma direta nas manifestaes dos dois primeiros casos, mais extensas e abrangentes, como por exemplo: traduzir vrios modelos com diferentes diagramas em um sistema; considerar um produto de software e transcrevlo em diversos modelos e diagramas da UML. Este trabalho estudou como pequenos trechos de modelo so tratados, no contexto da engenharia de ida e volta. Este trabalho pode ser do interesse de algum que esteja interessado em escolher uma ferramenta com suporte Engenharia de Ida e Volta entre UML e Java, pois discute alguns dos aspectos dessa questo. Tambem pode ser do interesse de desenhistas e programadores com relao a como navegar entre UML e Java. Este trabalho nao incluiu aspectos de MDE (Model-Driven Engineering).
Captulo 1. Introduo
1.3
Estrutura do Trabalho
Este trabalho est organizado da seguinte forma. O captulo 2 aborda os temas principais deste trabalho: engenharia frente, engenharia reversa e engenharia de ida e volta; ferramentas CASE; interao entre ferramenta e usurio; mapeamento modelo=>cdigo; e, por m, apresenta alguns trabalhos relacionados. O captulo 3 apresenta o planejamento e a execuo das vericaes do mapeamento UML=>Java e Java=>UML. So apresentados os critrios para a seleo das ferramentas, os critrios para avaliao das ferramentas, os estudos de caso, a execuo dos estudos de caso e a anlise dos resultados. O captulo 4 apresenta os aspectos prtico-operacionais. So apresentadas algumas diculdades encontradas durante o desenvolvimento do trabalho e as solues adotadas. O captulo 5 conclui o trabalho apresentando consideraes nais, ressaltando as contribuies e as limitaes. So discutidos ainda alguns trabalhos futuros.
Captulo 2 Reviso Bibliogrca

2.1 Engenharia de Ida e Volta
No ambiente de desenvolvimento de software dirigido por modelo, varios modelos so utilizados para descrever um sistema de software em diferentes nveis de abstrao e em diferentes perspectivas [Hettel et al., 2008]. Os modelos so construdos com o objetivo de delimitar o problema que se est estruturando, restringindo o foco a poucos aspectos por vez [Booch et al., 2005]. De acordo com Booch e outros [Booch et al., 2005], a modelagem uma parte central de todas as atividades que levam implantao de um bom software. Modelos so construdos para: i) comunicar a estrutura e o comportamento desejados do sistema; ii) visualizar e controlar a arquitetura do sistema; iii) compreender melhor o sistema que se est elaborando; iv) expor oportunidades de simplicao e reaproveitamento; e v) gerenciar riscos. Atualmente, o desenvolvimento com abordagens baseadas em modelos explorado, pois os modelos no so apenas mais prximos do pensamento humano, mas tambm ajudam na comunicao entre os desenvolvedores. Vrias metodologias de desenvolvimento baseado em modelo tm sido desenvolvidas [Angyal et al., 2006]. A saber: 1. DSM (Domain-Specic Modeling - Modelagem de Domnio Especco) - uma maneira de desenhar e desenvolver sistemas em alto nvel de abstrao, focalizando de perto o domnio do problema. , geralmente, aplicada em conjunto com a programao generativa. Devido gerao automtica de cdigo, esta metodologia pode melhorar expressivamente a qualidade do cdigo fonte e aumentar a produtividade [DSM, 2011]; 7
Captulo 2. Reviso Bibliogrfica
2. MDA (Model-Driven Architecture - Arquitetura Dirigida por Modelo) - uma abordagem de desenvolvimento adotada e divulgada, dentre outros, pelo consrcio OMG (Object Management Group ) [OMG, 2011] e que aumenta o papel de modelos no processo de desenvolvimento. Ela usa modelos com diferentes nveis de abstrao para desenhar, modicar e manter sistemas de software. MDA foi proposta para a engenharia frente, em que modelos abstratos so criados pelos desenvolvedores [MDA, 2011]; 3. MIC (Model-Integrated Computing - Computao Integrada a Modelo) - uma tcnica que transforma modelos de domnio especco em cdigo executvel. MIC prov um framework para produo de software usando ambientes de metamodelagem e interpretadores de modelo. MIC apoia a criao de ambientes de modelagem exvel e ajuda a rastrear as mudanas dos modelos [MIC, 2011]; 4. MBD (Model-Based Development - Desenvolvimento Baseado em Modelo) - um mtodo cada vez mais aplicado na produo de artefatos de software, enfatiza o uso de modelos em todas as fases de desenvolvimento do sistema. Modelos so utilizados para descrever todos os artefatos do sistema, isto , interfaces, interaes e propriedades de todos os componentes que compem o sistema. Estes modelos podem ser manipulados de diferentes maneiras para analisar o sistema e, em alguns casos, gerar a implementao completa do sistema [Strmer et al., 2006]. So irrefutveis os benefcios da utilizao de modelo no desenvolvimento de software. Entretanto, existe uma diculdade. Tais modelos fazem mais sentido quando reetem o cdigo fonte, ou seja, quando esto sincronizados com o cdigo fonte. E manter modelo e cdigo consistentes no uma tarefa simples. No incomum que alguns modelos sejam deixados de lado. Segundo Hettel e outros [Hettel et al., 2008], devido necessidade de manuteno ou mudana de requisitos, o cdigo fonte alterado ou estendido. Se no houver algum tipo de amarrao, o modelo no reete mais o cdigo fonte modicado. Para evitar alteraes inconsistentes, o cdigo fonte tem sido reetido de volta para o modelo do sistema, conforme a Figura 2.1. Este processo conhecido como engenharia de ida e volta (RTE Round-Trip Engineering ). Uma das etapas do desenvolvimento de software que mais dependem dos modelos a atividade de manuteno. Para dar manuteno em um sistema preciso entend-lo. Conforme Pressman [Pressman, 2006], manutenibilidade e inteligibilidade esto intimamente ligadas. Em outras palavras, a capacidade de dar manuteno est estreitamente relacionada capacidade de compreender o sistema. razovel dar aten-
2.1. Engenharia de Ida e Volta
o especial a essa relao, uma vez que a manuteno pode representar mais de 60% do tempo do desenvolvimento de um software.
Figura 2.1. Alteraes feitas no destino T devem ser reetidas de volta para a origem S. Portanto, algum tipo de transformao reversa transR necessria [Hettel et al., 2008].
A engenharia de ida e volta uma tcnica que se prope a contornar esse problema. Ela permite a sincronizao entre cdigo e modelo: quaisquer alteraes do cdigo fonte so sincronizadas de volta para o modelo e vice-versa, de forma que o cdigo fonte permanece consistente com o modelo [Angyal et al., 2006]. Seguindo esse raciocnio, Angyal e outros [Angyal et al., 2006] tambm armam que a engenharia de ida e volta melhora a qualidade do software e a eccia do desenvolvimento. De acordo com Sendall e Kster [Sendall & Kster, 2004] e Angyal e outros [Angyal et al., 2006], a engenharia de ida e volta envolve a sincronizao de modelos e a manuteno dos mesmos compatveis, permitindo assim que o engenheiro de software possa trabalhar com diferentes representaes. Desta forma, depois de sincronizar o modelo com o cdigo revisado, desenvolvedores podem escolher a melhor maneira para trabalhar: alterar o cdigo ou alterar o modelo. Outra vantagem da engenharia de ida e volta apoiar o desenvolvimento de software dividido em iteraes, em vez de fases sequenciais [Angyal et al., 2006]. Uma iterao envolve todas as fases, e uma parte do desenho implementada como um arquivo executvel em uma iterao. As vantagens do Desenvolvimento Iterativo e Incremental (IID Iterative and Incremental Development ) so os riscos mais baixos, os erros podem ser detectados mais cedo e a facilidade de testar novas funes. A engenharia de ida e volta automatiza a sincronizao do cdigo fonte e dos modelos entre as iteraes. Segundo Sendall e Kster [Sendall & Kster, 2004], a engenharia de ida e volta est intimamente relacionada com as tradicionais disciplinas de engenharia de software: engenharia frente (mapeamento de modelo para cdigo), engenharia reversa (mapeamento de cdigo para modelo) e reengenharia (compreenso do software existente e modicao do mesmo). A engenharia de ida e volta , muitas vezes, erroneamente
10
denida como simplesmente suporte para a engenharia frente e para a engenharia reversa. Na verdade, a caracterstica da engenharia de ida e volta fundamental que a distingue da engenharia frente e engenharia reversa a capacidade de sincronizar os artefatos existentes, que evoluem gradualmente pela atualizao de forma simultnea de cada artefato para reetir as alteraes feitas para outros artefatos. Segundo Angyal e outros [Angyal et al., 2008], a engenharia de ida e volta tem foco na sincronizao. Outra caracterstica da engenharia de ida e volta a possibilidade de atualizao automtica dos artefatos em resposta s inconsistncias detectadas automaticamente. Nesse sentido, diferente da engenharia reversa e da engenharia frente, que podem ser tanto manuais (tradicional) quanto automticas (atravs da gerao automtica ou anlise dos artefatos). A atualizao automtica pode ser automtica ou sob demanda. Na engenharia de ida e volta automtica, todos os artefatos relacionados so atualizados imediatamente aps cada alterao feita em um deles. Na engenharia de ida e volta sob demanda, os autores dos artefatos podem evoluir simultaneamente os artefatos (mesmo em um sistema distribudo) e, em algum momento, vericar se existem inconsistncias e escolher propagar algumas delas e conciliar os potenciais conitos [Antkiewicz & Czarnecki, 2006]. Antkiewicz e Czarnecki [Antkiewicz & Czarnecki, 2006] apresentam uma abordagem qual se referem como engenharia de ida e volta gil. A abordagem oferece apoio sob demanda em vez de sincronizao automtica. Os artefatos a serem sincronizados podem ser editados de forma independente pelos desenvolvedores em seus espaos de trabalho local e a reconciliao (reconciliation ) das diferenas pode ser feita de forma iterativa. Alm disso, a abordagem gil assume que o modelo pode ser completamente recuperado a partir do cdigo utilizando anlise esttica. No entanto, dependendo do contexto, existem alguns obstculos. De acordo com Hettel e outros [Hettel et al., 2008], a diculdade com a engenharia de ida e volta o fato muitas vezes negligenciado de que as transformaes, em geral, no so nem totais nem injetoras. Em outras palavras, existem conceitos no modelo origem que no tm um correspondente no modelo destino e vice-versa. Alm disso, pode haver vrios modelos sendo mapeados para um nico e mesmo modelo destino.
2.1.1
Engenharia Frente
Segundo Pressman [Pressman, 2006], a engenharia frente a atividade que parte de uma abstrao de alto nvel de implementao lgica independente para a implementao fsica do software. Em termos prticos, a engenharia frente parte de um modelo desenvolvido para a gerao do cdigo fonte. Desta forma, com o cdigo fonte sendo
11
resultado direto do modelo, tem-se a garantia de modelo e cdigo fonte consistentes. De forma geral, a engenharia frente envolve a gerao de um ou mais artefatos de software que esto mais prximos em forma e nvel de detalhe para o sistema nal a ser implantado, em comparao com os artefatos de entrada. A Figura 2.2 ilustra um contexto em que a engenharia frente e a engenharia reversa so aplicadas.
Figura 2.2. Relao entre Nvel de Abstrao, Engenharia Frente e Engenharia Reversa. [Harandi & Ning, 1990]
De acordo com Sommerville [Sommerville, 2007], a engenharia frente o processo de desenvolvimento convencional de software, que inicia com uma especicao do sistema e envolve o projeto e a implementao de um novo sistema. Em outras palavras, o processo tradicional de passagem de abstraes de alto nvel e projetos lgicos para a implementao do sistema.
2.1.2
Engenharia Reversa
A engenharia reversa um ramo da engenharia de software responsvel por possibilitar a recuperao de informaes perdidas ao longo do desenvolvimento do software. De acordo com Chikofsky e Cross [Chikofsky & Cross II, 1990], a engenharia reversa pode ser denida como o processo de anlise para identicar seus componentes e seus interrelacionamentos e criar suas representaes em outra forma ou em nvel mais alto de abstrao. A engenharia reversa tem sido vista tradicionalmente como um processo de duas etapas: extrao e abstrao de informao. A extrao de informao analisa os artefatos do sistema objeto para coletar dados brutos, enquanto a abstrao cria documentos e vises orientadas ao usurio [Canfora & Di Penta, 2007]. Pressman [Pressman, 2006] dene a engenharia reversa como a atividade de reverter um software s suas denies mais abstratas de desenvolvimento - modelo -
12
com o objetivo de compreender como funciona e como no funciona para poder ser modicado de acordo com as necessidades apontadas pela reengenharia. Em termos prticos, a engenharia reversa faz o inverso da engenharia frente, parte do cdigo fonte para a gerao do modelo. Deste modo, tem-se a garantia de cdigo fonte e modelo consistentes. Segundo Canfora e Di Penta [Canfora & Di Penta, 2007], o padro IEEE-1219 [IEEE, 1993] considera a engenharia reversa como uma importante tecnologia de apoio para lidar com sistemas que possuem o cdigo fonte como a nica representao de conana. Os objetivos da engenharia reversa so mltiplos, por exemplo: i) lidar com a complexidade, gerando vises alternativas; ii) recuperar informaes perdidas; iii) detectar efeitos secundrios, sintetizando abstraes superiores; e iv) facilitar a reutilizao. De outra perspectiva, Canfora e Di Penta [Canfora & Di Penta, 2007] armam que a engenharia reversa pode ter dois grandes objetivos: redocumentao e recuperao de projeto. A redocumentao visa produo e reviso de vises alternativas de um determinado artefato, com o mesmo nvel de abstrao, por exemplo, bela escrita de cdigo fonte ou visualizao de Grafos de Fluxo de Controle (CFGs Control Flow Graphs ), enquanto a recuperao de projeto visa recriao de abstraes de desenho a partir do cdigo fonte, documentao existente, conhecimento de especialistas e qualquer outra fonte de informao. A engenharia reversa de um cdigo fonte pode gerar novamente o modelo de um sistema gracamente em nvel mais alto de abstrao. De forma mais genrica, a engenharia reversa aplicada para gerar um modelo mais abstrato de artefato de software [Angyal et al., 2006]. A Figura 2.3 ilustra a engenharia frente e a engenharia reversa. Em casos ecientes e timos, a engenharia frente e a engenharia reversa realizam apenas transformaes incrementais, de forma que partes do modelo sejam modicadas, em vez de todo o modelo. Muller e outros [Mller et al., 2000] destacaram a ideia da explorao de informaes extradas pela engenharia reversa no processo de desenvolvimento frente, ou seja, tornando algumas informaes ou artefatos - por exemplo, vises arquiteturais, diagramas de projeto, ligaes de rastreamento - disponveis para os desenvolvedores atravs do uso de tcnicas de engenharia reversa. Segundo Canfora e Di Penta [Canfora & Di Penta, 2007], a maturidade de hoje de vrias peas da tecnologia de engenharia reversa e a disponibilidade dos ambientes de desenvolvimento extensvel permitem a possibilidade de continuar realizando engenharia reversa enquanto um sistema de software est sendo desenvolvido. Esta ideia tem sido aplicada em outras reas da engenharia de software: por exemplo, Sa
13
Figura 2.3. Engenharia Frente e Engenharia Reversa [Angyal et al., 2006].
e Ernst [Sa & Ernst, 2003] propuseram a ideia de teste contnuo, isto , de executar repetidamente sutes de teste durante o desenvolvimento ou manuteno de uma parte da funcionalidade para melhorar a ecincia dos testes. No contexto da engenharia reversa, isso implicaria diferentes benefcios. Primeiro, atravs da extrao e constante atualizao de vises de alto nvel (por exemplo, vises arquiteturais ou diagramas de desenho, como os diagramas de classe, diagramas de sequncia, diagramas de estado) a partir do cdigo fonte em desenvolvimento, seria possvel fornecer ao desenvolvedor uma imagem mais clara do sistema sendo criado. Segundo, quando artefatos em diferentes nveis de abstrao esto disponveis, uma vericao de consistncia permanente entre eles pode ajudar a reduzir os erros de desenvolvimento, por exemplo, checando se o cdigo compatvel com o projeto ou est em conformidade com as pr e ps-condies. Terceiro, uma anlise contnua do cdigo em desenvolvimento e de outros artefatos pode ser utilizada para fornecer aos desenvolvedores com conhecimentos teis, por exemplo, sugerindo o uso de um componente particular ou melhorar a qualidade do cdigo fonte, por exemplo, atravs de melhoria do nvel dos comentrios, por meio do aumento de sua compreenso [Canfora & Di Penta, 2007]. Abordagens de engenharia reversa visam maior inteligibilidade de sistemas de software, e envolve documentao atualizada e modelos consistentes. A engenharia de ida e volta como um todo minimiza a distncia entre as diferentes representaes do sistema. As ferramentas CASE tm papel fundamental para possibilitar, de fato, aos desenvolvedores trabalharem com modelo UML e cdigo fonte.
14
2.1.3
Ferramentas de CASE
A sigla CASE signica Computer-Aided Software Engineering - Engenharia de Software Auxiliada por Computador. Neste texto vamos tratar o termo CASE como se fosse tambm um adjetivo e vamos referir a ferramentas CASE signicando ferramenta de CASE. Um dos benefcios oferecidos pelas ferramentas CASE orientar e disciplinar o processo de desenvolvimento de software. Ferramenta CASE uma classicao que abrange aplicaes baseadas em computadores que auxiliam atividades de engenharia de software, desde anlise de requisitos e modelagem at programao e testes [Issa et al., 2007]. Algumas vantagens oferecidas pelas ferramentas CASE, direta ou indiretamente, so: i) qualidade do produto nal; ii) produtividade; iii) minimizao do tempo para a tomada de deciso; iv) menor quantidade de cdigo de programao; v) melhoria e reduo de custos na manuteno. Em contrapartida, suas desvantagens podem ser vericadas com a incompatibilidade de ferramentas e o tempo de treinamento para utilizao da ferramenta. De acordo com Canfora e Di Penta [Canfora & Di Penta, 2007], um dos principais desaos da anlise de programa lidar com a alta dinamicidade. Muitas linguagens de programao amplamente utilizadas permitem a alta dinamicidade, que constitui um poderoso mecanismo de desenvolvimento, mas torna a anlise mais difcil. Por exemplo, linguagens como Java introduzem o conceito de reexo e a capacidade de carregar classes em tempo de execuo. A anlise dinmica , entretanto, necessria como um complemento necessrio para a anlise esttica. No contexto da linguagem UML, que ser abordada na seo 2.2, conforme Angyal e outros [Angyal et al., 2006], a maioria das ferramentas CASE realiza engenharia reversa e produz diagramas de classe, mas h falta de ferramentas de apoio para extrair outros diagramas.
2.2
UML
Esta seo tem como objetivo contextualizar a Linguagem de Modelagem Unicada (UML - Unied Modeling Language ) e justicar a sua importncia na modelagem de software, alm de apresentar o estado em que ela se encontra atualmente e mostrar alguns exemplos.
2.2. UML
15
2.2.1
Importncia
Dobing e Parsons [Dobing & Parsons, 2006] armam que a frequncia da utilizao de elementos da UML varia consideravelmente: diagramas de classe, diagramas de sequncia e diagramas de casos de uso so utilizados mais frequentemente, enquanto diagramas de colaborao so menos utilizados. A utilizao do diagrama de classe superior de qualquer outro diagrama. A principal utilidade da UML no desenvolvimento de software o entendimento. Existem outros benefcios que so consequncia, como a facilitao da comunicao entre desenvolvedores e comunicao entre desenvolvedor e cliente. Segundo Dobing e Parsons [Dobing & Parsons, 2006], ao contrrio do que arma a literatura popular, os desenvolvedores parecem acreditar que os diagramas da UML podem ser entendidos pelos clientes: os clientes esto mais envolvidos com narrativas de casos de uso e diagramas de atividade, mas esto mais envolvidos com os demais componentes do que eles esperavam. O trabalho realizado por Dobing e Parsons [Dobing & Parsons, 2006] relata que 73% dos entrevistados utilizavam o diagrama de classes em dois teros ou mais de seus projetos. J os casos de uso eram utilizados em 44%. Apenas 3% dos entrevistados disseram que os diagramas de classes nunca foram utilizados em seus projetos e 25% disseram o mesmo sobre os diagramas de colaborao. Os entrevistados com mais experincia em UML relataram que seus projetos utilizavam mais elementos, sugerindo que o nvel de utilizao dos componentes da UML pode aumentar medida que os prossionais adquirem experincia.
2.2.2
Estado Atual
A UML amadureceu signicativamente desde as primeiras verses. Vrias pequenas revises (UML 1.3, 1.4 e 1.5) ajustaram decincias e defeitos da primeira verso da UML. A verso UML 2.0 foi aprovada pela OMG em 2005 [UML, 2011]. Na poca da elaborao deste trabalho, a UML estava na verso 2.4 e sua evoluo tem acontecido continuamente. Para o nosso trabalho, foi considerada a verso liberada em janeiro de 2011. Por ser o padro de fato para a representao grca do desenvolvimento de sistemas de software orientado a objeto, a anlise crtica da Linguagem de Modelagem Unicada tem sido o foco de muitos esforos de pesquisa nos ltimos anos. A UML tem apoiado a modelagem de dados, a modelagem de negcios, a modelagem de objetos e a modelagem de componentes [UML, 2011].
16
2.2.3
Aplicao
Um diagrama a representao grca de um conjunto de elementos, geralmente representado como grafos de vrtices (itens) e arcos (relacionamentos). So desenhados para permitir a visualizao de um sistema sob diferentes perspectivas; nesse sentido, um diagrama constitui uma projeo de um determinado sistema [Booch et al., 2005]. Segundo Angyal e outros [Angyal et al., 2008], a UML demasiadamente genrica para apoiar ecientemente a modelagem de domnio especco bem delimitado, isto , a modelagem de todo o sistema em detalhes. Diagramas da UML no necessariamente elevam muito o nvel de abstrao, so apenas a representao visual de classes fonte. As ferramentas de modelagem da UML geram esqueletos do cdigo fonte a partir de diagramas, e uma vez que os esqueletos necessitam ser preenchidos manualmente, eles tambm oferecem facilidades de sincronizao, conhecida como ida e volta entre os diagramas e o cdigo fonte. Conforme Larman [Larman, 2008], todas as ferramentas da UML armam apoiar muitos dos aspectos do desenvolvimento, mas muitas deixam a desejar. Isso acontece porque muitas das ferramentas trabalham apenas com os modelos estticos: elas podem gerar diagramas de classe a partir do cdigo, mas no podem gerar diagramas de interao. Ou para a engenharia frente, elas podem gerar a denio de classe bsica (por exemplo, Java) a partir de um diagrama de classe, mas no os corpos de mtodos a partir de diagramas de interao. No entanto, o cdigo no apenas declarao de variveis, ele corresponde tambm a comportamento. Por exemplo, suponha que se deseja entender a estrutura bsica de uxo de chamada de uma aplicao ou framework existente. Se a ferramenta pode gerar um diagrama de sequncia a partir do cdigo, se torna muito mais fcil seguir a lgica de uxo de chamada do sistema para aprender suas colaboraes bsicas [Larman, 2008].
2.2.4
Diagramas
Os diagramas podem ser classicados e subdivididos em diagramas estruturais e diagramas comportamentais. Os diagramas estruturais da UML esto voltados para os aspectos estticos de um sistema, que podem ser considerados como a representao da estrutura relativamente estvel do sistema. J os diagramas comportamentais da UML esto voltados para os aspectos dinmicos do sistema, que podem ser considerados como a representao de suas partes que sofrem alteraes. A verso 2.4 do documento de Especicao da UML [Superstructure, 2011] discute 14 tipos de diagramas. A Figura 2.4 d uma viso geral dos diagramas UML.
2.3. Mapeamento Modelo-cdigo
17
Figura 2.4. Hierarquia dos diagramas UML [UML, 2011].
2.3
Mapeamento Modelo-cdigo
O mapeamento entre modelo e cdigo fonte de um software (mapeamento ModeloCdigo) no uma tarefa simples. Existem restries que tornam complexa a correspondncia de elementos no modelo com elementos do cdigo fonte. De acordo com Buarque [Buarque, 2009], existem problemas semnticos, complexidades e ambigidades inerentes aos modelos que tornam o processo de mapeamento de modelos uma tarefa rdua e propensa a falhas. Segundo France e outros [France et al., 2006], alm de toda a complexidade, a UML carece de preciso semntica, pois muitos dos seus elementos (primitivas) tm diferentes interpretaes e varia conforme o entendimento do projetista. Isso gera ambigidades. Pastor e Molina [Pastor & Molina, 2007] armam que a maioria dos mtodos baseados em UML tem elementos como generalizao, associao e agregao to ambguos e dependentes da interpretao do projetista que o resultado em termos do projeto de software imprevisvel. Isso porque os relacionamentos de classes tm mais semntica do que o proposto por esses mtodos. Assim, um modelo conceitual s ser preciso se, e somente se, esses relacionamentos estiverem claramente denidos. Segundo Kollmann e outros [Kollman et al., 2002], no existe formalizao para a representao grca dos modelos gerados pela engenharia reversa de sistemas de software orientado a objeto. As diversas ferramentas geralmente adotam extenses no formalizadas da UML e, como resultado, difcil, ou mesmo impossvel, garantir que a
18
semntica do modelo no seja ambgua quando se trabalha com diferentes ferramentas ao mesmo tempo. Por exemplo, como diferenciar, em nvel de cdigo, um relacionamento de agregao com um relacionamento de composio? Existem elementos visuais do diagrama de classes UML que permitem fazer a diferenciao. Entretanto, na linguagem Java, o relacionamento de agregao e o relacionamento de composio podem estar representados da mesma forma, como ilustrado na Figura 2.5 e na Figura 2.6. Desta forma, percebe-se que o mapeamento modelo-cdigo correto fundamental para o sucesso da engenharia de ida e volta. Se no existir correspondncia consistente, as ferramentas que automatizam o processo de engenharia frente e engenharia reversa no tero resultados consistentes, informaes sero perdidas a cada iterao.
Figura 2.5. Engenharia frente de diagrama de classe realizado pela ferramenta StarUML: Relacionamento de Composio.
2.4
Trabalhos Relacionados
Kollmann e outros [Kollman et al., 2002] realizaram um trabalho comparativo de quatro ferramentas. A primeira comparao feita entre duas verses das ferramentas comerciais Rational Rose e Together e a segunda comparao feita entre duas verses das ferramentas acadmicas IDEA e FUJABA. As quatro ferramentas foram utilizadas para fazer a engenharia reversa de um sistema denominado Java Mathaino. A anlise
2.4. Trabalhos Relacionados
19
Figura 2.6. Engenharia frente de diagrama de classe realizado pela ferramenta StarUML: Relacionamento de Agregao.
comparativa das verses das ferramentas examinou algumas propriedades do diagrama de classe da UML, a saber: i) Nmero de Classes; ii) Nmero de Associaes; iii) Tipos de Associaes; iv) Manipulao de Interfaces; v) Manipulao de Classes Java Collection; vi) Multiplicidades; vii) Nomes de Papis; viii) Classes Internas; ix) e Detalhes de Compartimento de Classe. Algumas ferramentas ofereciam pers utilitrios para medir um conjunto prdenido de mtricas, mas diferiam signicativamente entre si, tornando difcil comparar os resultados de maneira uniforme. Alm disso, nenhuma das ferramentas foi capaz de deduzir os elementos semanticamente equivalentes entre os vrios modelos UML e comparar seus estados internos. Os resultados das verses das ferramentas examinadas foram comparados em duas diferentes categorias: conceitos bsicos e avanados. Conceitos bsicos referem-se ao ncleo da UML, como classes e associaes, e exige que os resultados sejam uma representao vlida do modelo bsico de software (isto , nenhum elemento central tenha sido omitido ou imprecisamente representado). A segunda categoria avaliou a capacidade das ferramentas gerarem uma representao mais abstrata, em vez de uma viso de simples implementao. Isso inclui estratgias para recuperao de desenho e reconhecimento de fatos que no so imediatamente visveis a partir do cdigo fonte. Todas as ferramentas, nas verses examinadas, obtiveram sucesso nos conceitos
20
bsicos. Nos conceitos avanados, vericou-se que a capacidade de engenharia reversa das ferramentas industriais, Rational Rose e Together, no vai muito alm dos recursos bsicos de UML. Para as ferramentas acadmicas, IDEA e FUJABA, representaes mais abstratas e reconhecimento de caractersticas avanadas foram claramente o domnio: elas conseguiram reconhecer todas as caractersticas do conjunto de propriedades totalmente ou pelo menos at certo ponto, enquanto as ferramentas industriais no abordaram vrias delas (por exemplo, multiplicidades, associaes inversas e resoluo de container no foram abordadas pelas ferramentas industriais). Bellay e Gall [Bellay & Gall, 1997] apresentam um trabalho detalhado de comparao de ferramentas CASE de engenharia reversa. Eles avaliaram quatro ferramentas de engenharia reversa que analisam cdigo fonte C, a saber: Rene/C, Imagix4D, Sni+ e Rigi; investigaram as capacidades destas ferramentas, nas verses examinadas, atravs da aplicao delas em um sistema de software comercial incorporado como um estudo de caso; identicaram benefcios e decincias das quatro ferramentas e avaliaram sua aplicabilidade, sua usabilidade e sua extensibilidade. O enfoque principal foi sobre os recursos da ferramenta para gerar relatrios grcos, como rvores de chamadas, dados e grcos de controle de uxo. Eles armam que a avaliao da tecnologia de software depende do entendimento de: 1) como a tecnologia avaliada difere de outra tecnologia; e 2) como essas diferenas atendem s necessidades dos contextos especcos de uso. O contexto de uso foi a recuperao de informaes arquiteturais de sistemas de software embarcados. Foram escolhidos quatro representantes signicativamente diferentes de ferramentas de engenharia reversa para cobrir uma ampla gama de ferramentas. Ao nal das anlises, eles armam que nenhuma das ferramentas, naquelas verses, poderia ser declarada como melhor na avaliao, uma vez que elas eram bastante diferentes, com diferentes vantagens e desvantagens. Todas elas forneciam boa capacidade de engenharia reversa em contextos de uso diferentes. Como resultado mais geral, a ferramenta de avaliao mostrou que o desempenho e a capacidade de uma ferramenta de engenharia reversa so dependentes do estudo de caso e seu domnio de aplicao, bem como a nalidade da anlise. Khaled [Khaled, 2009] apresenta um trabalho de comparao de ferramentas segundo alguns critrios, a saber: documentao HTML, apoio total aos diagramas da UML, engenharia de ida e volta, integrao com ferramentas de modelagem de dados, exportao de diagramas e robustez. As ferramentas comparadas foram Rational Rose, ArgoUML, MagicDraw e Enterprise Architect. Foram feitas breves consideraes sobre a avaliao de cada uma das verses das ferramentas. Algumas descries eram simplesmente do tipo a ferramenta X capaz de gerar a documentao HTML. Ao nal,
21
foram apresentadas algumas concluses do tipo a ferramenta X a melhor escolha para a atividade Y. O objetivo do trabalho foi auxiliar um desenvolvedor na escolha da ferramenta mais adequada para determinada atividade. Arcelli e outros [Arcelli et al., 2005] realizaram um trabalho que consiste na comparao de ferramentas de engenharia reversa baseada em decomposio de mecanismos de desenho. Segundo eles, a utilidade dos mecanismos de desenho em engenharia frente bem conhecida e diversas ferramentas proveem suporte para sua aplicao no desenvolvimento de sistemas. No entanto, o papel dos mecanismos de desenho em engenharia reversa ainda argumentado, principalmente devido sua denio informal, que leva a vrias implementaes possveis de cada mecanismo. Um dos aspectos mais discutidos relacionados aos mecanismos de desenho a necessidade de sua formalizao de acordo com os inconvenientes que podem apresentar. A formalizao leva identicao dos chamados sub-mecanismos, que so elementos recorrentes fundamentais pelos quais os mecanismos de desenho so compostos. No trabalho, eles analisaram o papel dos sub-mecanismos utilizados em duas ferramentas de engenharia reversa: FUJABA e SPQR. A ateno esteve voltada para como os mecanismos eram sub-explorados para denir e detectar mecanismos de desenho. Neste contexto, h uma forte necessidade de formalizar mecanismos de desenho. Inevitavelmente, a formalizao leva identicao de elementos recorrentes regulares. Considerando os mecanismos de composies de elementos mais simples, pode-se reduzir signicativamente a criao de variantes em engenharia frente, ao mesmo tempo em que aumenta a possibilidade de identicar padres de aplicao em engenharia reversa. Angyal e outros [Angyal et al., 2006] realizaram um trabalho que analisa a importncia do desenvolvimento baseado em modelo e d uma viso geral do estado da arte de mtodos e ferramentas de engenharia reversa. Alm disso, considera a engenharia de ida e volta como uma abordagem que pode ser utilizada para alcanar melhor qualidade de software, uma vez que as mudanas que afetam o desenho no so feitas no cdigo, mas no modelo. O trabalho apresenta a modelagem visual de sistemas de software como uma representao do comportamento desejvel do sistema, em alto nvel de abstrao, que pode ser uma forma ecaz de tornar o processo de desenvolvimento de software mais eciente. O problema de inconsistncia do modelo com o cdigo, ao longo do processo de desenvolvimento, tambm analisado. Para ajudar os desenvolvedores a alcanar novamente a sincronia entre o modelo e cdigo, as ferramentas de engenharia reversa foram criadas. So abordadas algumas metodologias de desenvolvimento baseado em modelo,
22
a saber: i) DSM (Domain-Specic Modeling - Modelagem de Domnio Especco); ii) MDA (Model-Driven Architecture - Arquitetura Orientada a Modelo); iii) (ModelIntegrated Computing - Computao Integrada a Modelo); e iv) MBD (Model-Based Development - Desenvolvimento Baseado em Modelo). Ferramentas e abordagens mais relevantes so apresentadas, subdivididas de acordo com seu foco principal: i) Ferramentas CASE (Rational XDE, Together, Eclipse GMT, Fujaba e MetaEdit++); Parsers e Ferramentas de Cdigo Fonte (Columbus, CPP2XMI, Rigi, SHriMP, GUPRO e JavaCC); Reconhecimento de Padres de Projeto (CrocoPat, Columbus, PideJ, SPOOL e PINOT). O trabalho permite vericar que ainda h decincias quanto realizao de engenharia de ida e volta de forma plena. A maioria das ferramentas CASE no capaz de trabalhar com outros diagramas de forma satisfatria, a no ser com o diagrama de classes. Fazendo correlao com o trabalho de Kollmann e outros [Kollman et al., 2002], que diz que no existe ainda um esquema padro para a representao de modelos resultantes da engenharia reversa de um sistema, torna-se relevante a avaliao de verses recentes das ferramentas observando, principalmente, novos elementos que foram inseridos a partir da UML 2.0 Ali [Ali, 2005] realizou um trabalho que aborda a importncia da engenharia reversa de software como uma disciplina da engenharia de software. Segundo ele, a atrao da ateno dos estudantes no tem sido voltada para essa questo. Em vez de dar manuteno nos sistemas existentes, o desenvolvimento de novos softwares sempre tem tido prioridade. Porm, com a chegada da internet e da tecnologia clienteservidor, muitas organizaes desejam adaptar seus sistemas existentes. Desta forma, a tendncia tem se voltado um pouco para a evoluo de software e manuteno. E, agora, mais ainda, precisa-se de engenheiros de software que possam trabalhar ecazmente com os sistemas legados. Segundo Ali [Ali, 2005], utilizando as trs abordagens para a anlise de sistema empregando engenharia reversa (Anlise de Caixa Branca - White Box ; Anlise de Caixa Preta - Black Box ; e Anlise de Caixa Cinza - Gray Box ), estes so alguns mtodos geralmente utilizados pelos engenheiros de software: i) rastreamento de entrada; ii) estudar as diferentes verses do sistema; iii) cobertura de cdigo) iv) acesso kernel; v) extrao de informaes atravs de dados que tenham cado em buers compartilhados; e vi) estudo de APIs. O trabalho busca convencer os acadmicos que esto envolvidos no projeto de currculo de engenharia de software das universidades, universitrios e tambm aqueles que tambm podem fazer este curso na universidade. Existem alguns resultados: injetar conana em seus estudantes de engenharia para trabalhar em vrios problemas reais do
23
mundo uma abordagem desenvolvida por Barsotti [[Barsotti, 2003] apud [Ali, 2005]]. O trabalho de Ali [Ali, 2005] aborda a importncia da engenharia reversa de forma geral. Foi um trabalho breve, com levantamento de questes tericas e de estatsticas de pesquisas realizadas sobre a importncia da engenharia reversa no meio acadmico e na indstria. Percebe-se que a engenharia reversa uma atividade que exerce signicativa inuncia no meio onde empregada e est em ascenso. Outro trabalho relacionado foi realizado na Universidade de Missouri-Rolla [Robert. B. Stone, 2000], introduzindo tcnicas de engenharia reversa e estimulando estudantes a estudarem produtos do mundo real. E os resultados foram encorajadores: 77% dos estudantes consideraram que a introduo da metodologia de engenharia reversa reforou conceitos ensinados durante as aulas. E, ainda, 82% queriam que ela fosse incorporada em cursos futuros, especialmente em cursos de projeto. Atravs da engenharia reversa, estudantes de engenharia de software podem se beneciar: A melhor e mais profunda compreenso a primeira e principal vantagem do ensino de conceitos de engenharia reversa. Conhecimento valioso adquirido com a funcionalidade de hardware e software; A indstria de software , talvez, a indstria de mais rpida mutao. Avana por si prpria e amplia suas prticas para outros campos da cincia e engenharia; Uma vez que a engenharia reversa de um sistema uma tarefa difcil, o seu aprendizado auxilia no aprendizado de outras habildades; Muitas universidades ao redor do mundo oferecem engenharia reversa em um nvel avanado e elas esto conduzindo pesquisa. O trabalho realizado por Canfora e Di Penta [Canfora & Di Penta, 2007] apresenta uma pesquisa realizada na rea de engenharia reversa de software, discute histrias de sucesso e principais realizaes, e fornece um roteiro para possveis desenvolvimentos futuros luz das tendncias emergentes em engenharia de software. Eles apresentaram as principais realizaes da engenharia reversa durante a ltima dcada, organizadas em trs principais reas: anlise de programa, recuperao de projeto e visualizao. Em seguida, utilizando as mesmas trs reas, identicaram e discutiram questes que pudessem vir a ser desaos da engenharia reversa nos anos seguintes. Alm disso, identicaram desaos da engenharia reversa que derivam de paradigmas emergentes de computao, como a computao orientada a servio e
24
a computao autnoma. Por m, trataram a questo da facilitao da adoo da engenharia reversa. Segundo Canfora e Di Penta [Canfora & Di Penta, 2007], apesar da maturidade da engenharia reversa, e do fato de inmeros trabalhos de engenharia reversa parecerem temporariamente resolver problemas cruciais e atenderem importantes necessidades industriais, sua adoo na indstria ainda limitada. Eles apresentam algumas direes para avano: Educao de engenharia reversa: o ensino de engenharia reversa como uma parte integral do processo de projeto de software e no apenas como tcnicas para lidar com mudanas aumentar a conscincia do papel da engenharia reversa, contribuindo assim com reduo das barreiras; companhias devem investir em engenharia reversa ou pelo menos adotar prticas de engenharia reversa; Evidncias empricas:: especialmente durante os ltimos anos, a maioria das pesquisas em engenharia reversa tem sido validada empiricamente com estudos visando medir o desempenho de uma tcnica ou comparando-a com outras j existentes; Aumento da maturidade e interoperabilidade das ferramentas: isso deve ser questionado, pode ou no ser o papel dos pesquisadores. Entretanto, a avaliabilidade de ferramentas de engenharia reversa maduras e sua interoperabilidade iro favorecer a sua utilizao e, consequentemente, a sua adoo. Tonella e outros [Tonella et al., 2007] realizaram estudos empricos em engenharia reversa. Segundo eles, a engenharia reversa, que surgiu com o objetivo de modernizar os sistemas legados, normalmente escritos em linguagens de programao antigas, tem estendido sua aplicabilidade a praticamente todo o tipo de sistema de software. Alm disso, os mtodos originalmente concebidos para recuperar uma viso esquemtica de alto nvel do sistema destino tm sido alargados a vrios outros problemas enfrentados pelos programadores quando precisam entender e modicar o software existente. A posio dos autores que a prxima fase de desenvolvimento para esta disciplina seja necessariamente baseada na avaliao de mtodos empricos. Na verdade, essa avaliao necessria para adquirir conhecimento sobre os efeitos reais da aplicao de uma determinada abordagem, bem como para convencer os usurios nais dos custos e benefcios. A contribuio do trabalho deles para o estado da arte um roteiro para a pesquisa futura no campo, que inclui: clareamento do escopo de investigao, denio de uma taxonomia de referncia e adoo de um framework comum para a execuo de experimentos.
25
Hettel e outros [Hettel et al., 2008] realizaram um trabalho na rea de sincronizao de modelo, apresentando uma denio formal de engenharia de ida e volta e tratando da questo da semntica das alteraes no contexto de transformaes parciais ou no injetoras. De acordo com eles, no ambiente de desenvolvimento de software centrado em modelo, vrios modelos diferentes so utilizados para descreverem um sistema de software em diferentes camadas de abstrao e em diferentes perspectivas. Seguindo a viso MDA (Model Driven Architecture ), a transformao de modelo utilizada para apoiar o renamento gradual de modelos abstratos em modelos mais concretos. A denio formal da sincronizao de modelo em si e a transformao de ida e volta so apresentadas utilizando modelos matemticos. Hettel e outros [Hettel et al., 2008] consideram que a contribuio original de seu trabalho a denio formal de engenharia de ida e volta, no contexto de transformao do modelo. A denio proposta vai alm das abordagens existentes, uma vez que envolve transformaes parciais e no injetoras, que foram mostradas serem mais realistas que as transformaes injetoras requeridas pelas abordagens existentes para RTE ou sincronizao de modelo. Hidaka e outros [Hidaka et al., 2009] tambm armam que a transformao de modelo bidirecional desempenha um papel importante na manuteno da consistncia entre dois modelos, e tem muitas aplicaes potenciais no desenvolvimento de software, incluindo sincronizao de modelo, engenharia de ida e volta, evoluo de software, desenvolvimento de software de mltiplas vises e engenharia reversa. Entretanto, a semntica bidirecional no clara, o mtodo de bidirecionalizao de domnio especco e a falta de um framework semntico de desenvolvimento so problemas conhecidos que impedem a transformao de ser utilizada.
Captulo 3 Planejamento e Execuo dos Estudos de Caso

Este captulo apresenta a avaliao de trs ferramentas CASE - Astah*, Rational Software Architect e Enterprise Architect - realizada atravs da anlise dos mapeamentos de alguns modelos da UML para a linguagem Java e vice-versa. A seo 3.1 apresenta os critrios utilizados para selecionar as ferramentas que foram analisadas. A seo 3.2 apresenta os critrios utilizados para avaliar as ferramentas. A seo 3.3 faz uma discusso sobre Pers da UML. A seo 3.4 descreve e discute os estudos de caso elaborados a partir da verso 2.4 do documento de especicao de superestrutura da UML [Superstructure, 2011], publicado em janeiro de 2011. Ao m desta seo, obtm-se o conjunto de ferramentas a serem testadas neste trabalho de pesquisa e os estudos de caso aplicveis. A seo 3.5 apresenta a execuo dos estudos de caso em cada uma das ferramentas e algumas consideraes em relao aos resultados apresentados.
3.1
Critrios para Seleo das Ferramentas CASE
A seleo das ferramentas CASE baseou-se nas seguintes premissas: i) relevncia traduzida em participao no mercado e interesse (nos fruns eletrnicos, nos trabalhos cientcos, entre outros) das pessoas; e ii) seleo de 3 ferramentas para avaliao. Com foco nestas premissas, estabeleceram-se os seguintes critrios, apresentados na Tabela 3.1, para a seleo de ferramentas. Aplicando-se o critrio C1, relacionam-se as ferramentas CASE utilizadas no mercado, atualmente. Aplicou-se as expresses ferramentas de engenharia de ida e volta e round-trip engineering tools, ferramentas de engenharia reversa e reverse engineering tools e ferramentas UML e UML tools nos principais sistemas de busca 27
28
Captulo 3. Planejamento e Execuo dos Estudos de Caso
Tabela 3.1. Critrios para seleo das ferramentas CASE
Critrio C1
Descrio A busca das ferramentas deve ser feita em mquinas de busca poulares (por exemplo no Google e no Bing), aplicando-se as sentenas ferramentas de engenharia de ida e volta e round-trip engineering tools, ferramentas de engenharia reversa e reverse engineering tools; ferramentas UML e UML tools, tomando em considerao cerca de 50 elos de navegao (links). A ferramenta deve oferecer suporte a linguagem UML e a linguagem Java. A ferramenta deve possuir disponibilidade para ser copiada a partir do stio da organizao responsvel por ela. A ferramenta deve oferecer licena gratuita ou para teste temporrio, considerando-se que no foi colocada como parte do trabalho a obteno de recursos para aquisio de licenas. A ferramenta deve no ter sido descontinuada, e oferecer suporte UML 2. A ferramenta deve possuir frum de discusses e dvidas ativo, colhendose informaes relacionadas sua existncia, nmero de mensagens trocadas, nmero de membros e visualizaes, para se avaliar seu alcance no mercado. A ferramenta deve possuir lista de discusso recente e suporte.
C2 C3 C4
C5 C6
da atualidade, Google e Bing. Para cada sistema de busca, e para cada expresso, visitaram-se 50 links. Considerando 6 expresses, ento visitaram-se 300 links que, multiplicados por 2 sistemas de busca, totalizam 600 links visitados. O critrio C2 consiste em restringir a pesquisa para ferramentas CASE que suportam a linguagem de modelagem UML e a linguagem de programao Java. Com o escopo menor, possvel realizar um trabalho mais detalhado. A UML a linguagem mais popular para a representao grca de sistemas de software orientados a objeto e a linguagem Java representa uma das linguagens mais utilizadas atualmente, sendo classicada em 1o lugar no TIBCO desde 2005 [TIBCO, 2011]. Por esse motivo, este trabalho foi realizado utilizando essas duas tecnologias. O critrio C3 consiste em restringir a avaliao para apenas ferramentas CASE disponveis para cpia. Para no dependermos de envio de CDs ou outros esquemas que poderiam atrasar os trabalhos, optamos por avaliar ferramentas que estivessem disponveis na Internet para cpia. O critrio C4 consiste em restringir a avaliao para apenas ferramentas CASE livres, gratuitas ou pagas que ofeream licena de teste. A licena deve ser extensa o suciente para poder ser feita uma avaliao.
3.2. Critrios para Avaliao de Ferramentas CASE
29
O critrio C5 consiste em descartar as ferramentas CASE descontinuadas. H ferramentas que pararam de ser desenvolvidas e possuem apenas verses antigas. Neste caso a anlise de tais ferramentas s justicada em funo de interesses mais especcos do que os deste trabalho, no acompanhando a evoluo da linguagem. Desta forma, o trabalho deu preferncia s ferramentas CASE que esto em constante evoluo e possuem suporte UML 2. O critrio C6 consiste em restringir a avaliao para ferramentas CASE que possuam suporte, fruns, listas de discusso. Isto ajudou o autor desta pesquisa a sanar dvidas durante o teste das ferramentas e na avaliao da popularidade da ferramenta. Acredita-se que quanto mais pessoas se apresentam no frum, maior sua abrangncia no mercado. Esses ambientes e seus nmeros evidenciam maior ou menor aceitao e utilizao da ferramenta pelos usurios ou visitantes. Dentre as ferramentas encontradas, aps a aplicao dos critrios de seleo, selecionamos: Astah*, Rational Software Architect e Enterprise Architect. A aplicao dos critrios de seleo das ferramentas CASE relatada com mais detalhes na seo 4.1. A seo 3.2 discute os critrios que foram utilizados para avaliar as ferramentas selecionadas. O objetivo foi vericar as seguintes caractersticas: i) as ferramentas so consistentes na transcrio do modelo para o cdigo e vice-versa; ii) as ferramentas oferecem recursos que facilitam o usurio entender e/ou inuenciar o processo de mapeamento de UML para Java e vice-versa de forma clara. Por exemplo: os usurios sabem, em alto nvel, o caminho traado pela ferramenta para realizar as tarefas? Quando o mapeamento no um para um, a ferramenta comunica e interage permitindo que o usurio selecione opes ou fornea uma opo ou a ferramenta tem sempre uma escolha padro? A ferramenta exvel, isto , permite ao usurio inserir um tipo de atributo que no esteja pr-denido pela ferramenta? A ferramenta exibe algum tipo de mensagem, antes ou depois, quando a operao contm erro? Um objetivo prximo a estes descritos avaliao da comunicabilidade das ferramentas, mas em funo da complexidade de tal anlise esta dimenso cou fora do escopo do trabalho. Os critrios para avaliao de ferramentas CASE so analisados na prxima seo.
3.2
Critrios para Avaliao de Ferramentas CASE
Segundo Sensalire [Sensalire et al., 2009], deve-se expor as ferramentas a uma avaliao adequada a m de determinar se elas so ecazes para ajudar os usurios em sua meta. Apesar da armao, percebe-se a falta de uma orientao geral sobre como a
30
interao entre ferramenta e usurio (desenvolvedor) deve ser realizada, e muitos dos desenvolvedores de ferramentas efetuam pouca ou nenhuma avaliao. A falta desta orientao geral foi percebida aps a realizao de consultas nos principais sistemas de busca de trabalhos cientcos como Scopus, Springer, IEEExplore, ACM Digital Library, Portal de Peridicos CAPES. No foram encontrados trabalhos alinhados com nossas metas. Sabe-se de trabalhos como os de Clarisse Sieckenius [de Souza, 2005] [de Souza et al., 2010], mas o foco a questo da IHC - Interao Humano-Computador -, enquanto que o nosso foco so as questes tcnicas de opes de mapeamento UML para Java e Java para UML. Alm de analisar a transcrio de UML para Java e vice-versa, nossa avaliao consistiu em vericar se existem ou no opes de mapeamento e quais so as opes, caso existam. A avaliao de dimenses tais como qualidade da interao, comunicabilidade e apreensibilidade so importantes, mas no zeram parte do escopo do trabalho para efeito de simplicao. Decidimos, ento, desenvolver critrios prprios para avaliao das ferramentas CASE, conforme descritos na Tabela 3.2, cujo objetivo foi avaliar a transcrio do modelo para o cdigo e a interao entre usurio e ferramenta CASE durante o processo de mapeamento de ida e volta entre as linguagens UML e Java. Neste trabalho, os critrios denidos atendem a dois momentos distintos do processo de mapeamento entre UML e Java, ou engenharia de ida e volta. O primeiro momento trata da engenharia de IDA, responsvel por mapear modelos da UML para a linguagem Java. Neste primeiro momento, os modelos dos estudos de caso em UML foram mapeados para Java, utilizando as ferramentas CASE selecionadas para anlise. O cdigo gerado e a forma como ele foi gerado foram avaliados de acordo com os critrios da engenharia de ida, elaborados neste trabalho. O segundo momento trata da engenharia de VOLTA, responsvel por mapear cdigo em Java para modelos da UML, cujo processo tambm conhecido como engenharia reversa. Pretendamos elaborar outros estudos de caso com estruturas Java e analisar separadamente o mapeamento de Java para UML. No entanto, em razo da complexidade da avaliao, no foi possvel e este mapeamento foi analisado apenas utilizando o cdigo gerado pela engenharia de ida. Desta forma, a engenharia de volta no foi analisada de forma separada, apesar de algumas consideraes sobre ela terem sido feitas juntamente com as consideraes sobre a engenharia de ida. Deste modo, utilizam-se os critrios para a mapeamento de UML para Java, sendo que para cada critrio composto pelos seguintes itens: i) a identicao (ID); ii) a descrio; iii) o mtodo de conferncia; e iv) o sistema de avaliao. O ID representa o cdigo e o nome do critrio. A Descrio apresenta detalhadamente o objetivo do critrio.
31
O Mtodo de Conferncia descreve como a vericao do desempenho da ferramenta em cada estudo de caso, de modo que seja possvel analisar sistematicamente a conabilidade do mapemaneto. O Sistema de Avaliao descreve como as ferramentas sero classicadas, conforme seu desempenho. Uma pontuao atribuda de acordo com uma escala likert [Likert, 1932]. Por exemplo: (0) no atende; (1) atende parcialmente; e (2) atende totalmente. As consideraes e a pontuao foram feitas pelo autor do trabalho. O objetivo desta pontuao caracterizar e descrever cada ferramenta segundo cada um dos critrios. De acordo com Sensalire e outros [Sensalire et al., 2009], apesar de haver a falta de um guia geral para auxiliar na avaliao das ferramentas, cada pessoa que realiza uma avaliao, no entanto, tem experincias que, se compartilhadas, podem orientar avaliadores futuros. A Figura 3.1 mostra o ciclo de melhoria de uma ferramenta CASE [Sensalire et al., 2009].
Figura 3.1. Ciclo de melhoria da ferramenta CASE [Traduzido: [Sensalire et al., 2009]].
A Tabela 3.2 apresenta a relao dos critrios de avaliao das ferramentas CASE. O objetivo do critrio C1 vericar se o signicado do Modelo da UML preservado no Modelo da linguagem Java. H algum tipo de inconsistncia no cdigo gerado? Todos os detalhes do modelo so vericados no cdigo ou h informao perdida? O modelo produzido pela engenharia de volta corresponde ao modelo inicial? A utilizao do critrio C1 pode ajudar a identicar problemas do tipo inconsistncias que
32
Tabela 3.2. Relao dos critrios de avaliao das ferramentas CASE.
CRITRIOS ID: C1 - Conabilidade do Cdigo Gerado. Descrio: Este critrio propicia vericar se o cdigo gerado corresponde ao modelo elaborado pelo usurio. Mtodo de Conferncia: Inspeo de cdigo gerado em Java a partir da observao e entendimento do modelo desenhado em UML. Sistema de Avaliao: Aplicao de escala likert, adotando-se: 0 Cdigo inconsistente, 1 Cdigo parcialmente consistente, 2 Cdigo consistente. ID: C2 - Capacidade de Resoluo de Ambiguidades de Modelo. Descrio: Este critrio propicia vericar se a ferramenta capaz de resolver automaticamente ou semi-automaticamente ambiguidades durante o mapeamento de UML para Java. Mtodo de Conferncia: Inspeo se h interfaces de dilogo com o usurio, concedendo-lhe direito de escolha durante o processo de mapeamento de UML para Java, ou se h rea de congurao do mapeamento desejado. Sistema de Avaliao: Aplicao de escala likert, adotando-se: 0 No resolve, 1 Resolve parcialmente, 2 Resolve. ID: C3 - Consistncia Interna da Ferramenta. Descrio: Este critrio propicia vericar se a ferramenta capaz de, a partir de um modelo UML desenhado pelo usurio, gerar cdigo Java e fazer a engenharia reversa, construindo um modelo UML, compatvel com o modelo inicial elaborado pelo modelador. Mtodo de Conferncia: Inspeo de modelo gerado observando detalhes (tipos de atributos, tipos de relacionamentos entre classes, multiplicidade, extremidades de associao, sentena de propriedades, entre outros) existentes no modelo inicial. Sistema de Avaliao: Aplicao de escala likert, adotando-se: 0 Inconsistente, 1 Parcialmente Consistente, 2 Consistente. ID: C4 - Flexibilidade e Robustez da Ferramenta. Descrio: Este critrio propicia vericar se a ferramenta permite ser detalhado em nvel de modelo tanto quanto pode ser detalhado em nvel de cdigo utilizando a importao de bibliotecas. Mtodo de Conferncia: Inspeo se possvel importar/habilitar bibliotecas que permitam elaborar um modelo robusto e detalhado, modelar todo tipo de relacionamento, de modo a diminuir a implementao manual de cdigo. Inspeo se os tipos utilizados no modelo esto presentes nos pr-denidos, nas bibliotecas ou no modelo. Sistema de Avaliao: Aplicao de escala likert, adotando-se: 0 No Robusta, 1 Parcialmente Robusta, 2 Robusta.
comprometem a qualidade do software. Para facilitar a vericao da correspondncia entre modelo e cdigo, procurou-se denir um cdigo esperado para os modelos ava-
33
liados de cada estudo de caso apresentados na seo 3.4, mas durante as pesquisas no foram encontrados relatos de boas prticas para gerao de cdigo Java a partir de um determinado elemento da UML. Desta forma, sero vericadas se os elementos Java gerados a partir dos modelos so consistentes com a linguagem Java e se representam, de fato, as estruturas do modelo. O objetivo do critrio C2 vericar como a ferramenta trata a engenharia frente e a engenharia reversa quando efetivamente h defeitos. Sabe-se que a relao entre modelo e cdigo no sempre um para um [Hettel et al., 2008]. Isto , um modelo nem sempre ter apenas uma forma nica de representao em nvel de cdigo e vice-versa. Por exemplo, considere um modelo em que h uma associao do tipo 1 para N entre as classes A e B. H vrias formas de transcrever esta parte do modelo. Podem ser usadas colees ou podemos usar arranjos, por exemplo. A ferramenta disponibiliza algum tipo de interface que permite ao usurio escolher alguma das opes ou existe uma soluo padro? Existe alguma rea de congurao em que o usurio possa escolher a opo de gerao que seja mais adequada ao seu interesse? Enm, de alguma forma, o usurio pode intervir no resultado apresentado pela ferramenta? O objetivo do critrio C3 vericar se a ferramenta cria, perde ou transforma alguma informao no processo de engenharia frente ou na engenharia reversa. Observe que o critrio C1 verica consistncia somente na engenharia frente. Dado um modelo elaborado, ser gerado pela ferramenta o respectivo cdigo. Em seguida, sem realizar nenhum tipo de alterao no que foi gerado pela ferramenta, o cdigo gerado ser a entrada para a ferramenta gerar de volta o modelo. Teoricamente, este modelo gerado deveria ser idntico ao modelo inicial. O objetivo do critrio C4 vericar se a ferramenta trata de forma adequada as especicaes de pacotes, bibliotecas, classes e interfaces. Por exemplo, na criao de um diagrama de classe, os tipos das classes, atributos e mtodos so pr-denidos nas ferramentas. Considerando a realidade de muitas linguagens de programao possurem diversas bibliotecas com vrios tipos de atributos e mtodos, para uma ferramenta que d suporte a mais de uma linguagem, no razovel prever todos os tipos possveis. Desta forma, ou a ferramenta se limita a ter um mnimo de opes ou permite a importao de biblioteca relacionada a determinada linguagem e, consequentemente, a possibilidade de declarar no modelo tipos dessa biblioteca. Por exemplo, na biblioteca java.lang.Math existe um mtodo chamado sqrt (double a), com caractersticas pr-denidas. Se o desenvolvedor desejasse declarar um mtodo deste tipo no modelo, no seria interessante implementar tudo do incio. Ao contrrio, desejvel que a ferramenta permita algum tipo de importao e utilizao desta biblioteca no modelo.
34
3.3
Pers da UML
A UML fornece um conjunto de mecanismos de extenso - esteretipos, valores etiquetados (tagged values ) e restries - para especializao dos seus elementos, permitindo a personalizao de extenses da UML para aplicaes de domnio especco. Essas personalizaes so conjuntos de extenses da UML agrupadas em pers da UML (UML proles ) [Mller et al., 2008]. Um perl da UML dene uma maneira especca de utilizao da UML. Por exemplo, Java prole dene uma maneira de modelar cdigo fonte Java em UML [OMG, 2011]. Conforme Mueller e outros [Mueller et al., 2006], os pers permitem personalizar a UML de forma que qualquer sistema poderia, em teoria, ser modelado em qualquer nvel de detalhe. Um perl feito por um conjunto de esteretipos, valores etiquetados e restries para denir como a sintaxe e a semntica do modelo so estendidos para uma terminologia de domnio especco. Como os pers podem estender um meta-modelo, eles so derivados da denio MOF (Meta Object Facility ) e fornecem extensibilidade apenas o suciente para criar uma perspectiva, evitando a complexidade da denio de um meta-modelo novo [Mueller et al., 2006]. O perl deve ser capaz de especializar a semntica dos elementos do meta-modelo da UML. Por exemplo, em um modelo com o perl Java model , a generalizao de classes deve ser capaz de restringir a herana simples sem ter que atribuir explicitamente um esteretipo classe Java para toda instncia de classe. Existem vrias razes pelas quais se pode querer personalizar um meta-modelo. Uma delas que as informaes adicionadas podem ser utilizadas na transformao de um modelo para outro modelo ou cdigo (como a denio de regras de mapeamento entre o modelo e o cdigo Java) [Superstructure, 2011]. Deveria existir um UML Prole para modelos de desenho ou para modelos de implementao utilizando a linguagem Java ou utilizando a plataforma J2EE - assim como existe para CORBA, SysML, SoaML, entre outros. No foi encontrado no Catlogo de Especicaes de Pers da UML (Catalog of UML Proles Specications ) [OMG, 2011] um UML Prole for Java. O documento Metamodel and UML Prole for Java and EJB Specications , de fevereiro de 2004, disponvel no stio da OMG [OMG, 2011], faz referncia a um Java Prole, onde so mapeados conceitos de metamodelo Java para elementos do perl. No entanto, no foram encontradas atualizaes desde aquela poca, o que permite dizer que as mudanas a partir da UML 2 no foram consideradas. Consequentemente, sem a referncia de um UML Prole for Java , os desen-
3.4. Estudos de Caso
35
volvedores das ferramentas so levados a construir seu prprio perl. Com o objetivo de vericar o perl que cada uma das trs ferramentas selecionadas utiliza, enviamos uma mensagem para o suporte de cada ferramenta perguntando qual UML Prole for Java era utilizado pela ferramenta. A Astah* deu a seguinte resposta: atualmente, no oferecemos qualquer UML Prole que possa ser baixado e aplicado na Astah*. No entanto, a edio professional tem a capacidade de personalizar o UML prole, permitindo ao usurio: i) especicar TaggedValues e import-los; ii) especicar conjunto de cones personalizados para os Esteretipos; e iii) denir valores especcos Java (atributos, mtodos, enum, nal, entre outros).. A RSA respondeu dizendo informaes sobre os produtos da IBM esto disponveis no stio dela. No stio foi encontrado um material que mostra como aplicar um perl. Na RSA, o perl de UML para Java contm vrios esteretipos que podem ser aplicados para validar elementos no modelo de origem e esteretipos que controlam como a transformao gera o cdigo Java. No recebemos resposta do pessoal de suporte da Enterprise Architect. No entanto, analisando a ferramenta vericou-se ser possvel especicar os esteretipos (o nome do esteretipo, onde ele aplicado e comentrios sobre ele), os valores etiquetados e as restries. O esteretipo instantiate, por exemplo - utilizado na seo 3.4.1 -, pode ser denido no perl.
3.4
Estudos de Caso
Foram elaborados 6 estudos de caso para a vericao da forma como as ferramentas CASE realizam a transcrio de UML para Java e vice-versa, e como elas interagem com o usurio ao realizar a engenharia de ida e volta (engenharia frente e engenharia reversa). De acordo com Gessenharter [Gessenharter, 2008], o suporte modelagem UML por meio de diagramas de classe e a gerao do cdigo a partir dele so importantes tendncias atuais das ferramentas. Mas, enquanto desenhar diagramas, geralmente, bem suportado, a gerao de cdigo de alcance limitado. Classes associativas, multiplicidades, agregao e composio no so corretamente ou no so processadas pela maioria dos geradores de cdigo. Segundo Szlenk [Szlenk, 2008], uma razo pode ser o fato da semntica no ser formalmente denida na especicao da UML. Como resultado, as associaes so normalmente transformadas em cdigo com as mesmas propriedades das classes associadas ou conjuntos tipados correspondentes. Assim,
36
difcil determinar como uma dada mudana em um modelo inuencia o seu signicado e, por exemplo, se uma determinada transformao de modelo preserva a semntica do modelo ou no. A Arquitetura Dirigida por Modelos (Model Driven Architecture - MDA) da OMG [OMG, 2011] uma abordagem para o processo de Desenvolvimento Dirigido por Modelos (Model Driven Development - MDD) utilizando a UML [UML, 2011]. MDD concentra-se em modelos, em que o cdigo gerado a partir dele. Apenas a qualidade de um modelo deve inuenciar a qualidade do cdigo, isto , um modelo altamente detalhado que abrange todos os aspectos de uma aplicao deve resultar em cdigo gerado automaticamente, sem necessidade de adaptaes. Esta ambio requer boas ferramentas de gerao de cdigo. A maioria dos geradores de cdigo produz um cdigo que no cobre todos os elementos do modelo de entrada [Gessenharter, 2008]. Apesar de haver controvrsias, uma vez que, por exemplo, Bertrand Meyer [Meyer, 1997] considera que a associao um elemento estranho orientao a objetos, de acordo com Diskin e outros [Diskin et al., 2008], a associao entre classes um construto centrado na modelagem OO. Entretanto, a semntica precisa de associaes no foi denida, e apenas os tipos mais bsicos so implementados nas modernas ferramentas de engenharia frente e reversa. Esta situao problemtica: os modelos so o resultado da anlise e das fases de concepo e devem obedecer a todos os requisitos de um sistema e, portanto, o cdigo gerado deve abranger toda a semntica do modelo. Caso contrrio, a conformidade do cdigo com o modelo continua a ser de responsabilidade exclusiva do desenvolvedor. Isto implica em mais linhas de cdigo escrito mo e propenso a erros [Gessenharter, 2008]. Gessenharter [Gessenharter, 2008] arma que, alm disso, a vericao do modelo invalidada. O cdigo gerado deve possuir todas as restries que sempre devem ser realizadas, como o caso em um SGBD relacional, onde a denio de chaves estrangeiras permite tambem denir a rejeio da remoo de uma tupla se isso resultar em uma violao das restries do nvel conceitual. Os estudos de caso elaborados basearam-se em 3 (trs) diagramas da UML. O diagrama de classe, por ser o diagrama mais utilizado da UML [Dobing & Parsons, 2006] e uma das mais populares apresentaes visuais de desenho de software [Sharif & Maletic, 2009]; o diagrama de estrutura composta, por ter relao direta com o diagrama de classe e ser um novo recurso da UML 2.x; e o diagrama de sequncia, por ser o principal diagrama de interao [Superstructure, 2011] e um dos principais diagramas comportamentais. O diagrama de sequncia tambm possui novos recursos que surgiram a partir da UML 2.x como os fragmentos combinados e os
37
usos de interao. O objetivo no exaurir todas as possibilidades de modelagem, mas: 1. apontar detalhes importantes no implementados pelas ferramentas; 2. identicar elementos no suportados pelas ferramentas; 3. analisar casos de mapeamento incorreto de UML para Java; 4. analisar casos de mapeamento incorreto de Java para UML; e 5. vericar se a ferramenta interage com o usurio durante a engenharia de ida e volta. DIAGRAMA DE CLASSE De acordo com a verso 2.4 do documento de especicao de Superestrutura da UML [Superstructure, 2011], publicado em janeiro de 2011, os elementos de modelo (model elements ) mais comuns do diagrama de classe so: Associao; Agregao; Classe; Composio; Dependncia; Generalizao; Interface; Realizao de Interface; Realizao. DIAGRAMA DE ESTRUTURA COMPOSTA De acordo com o documento de especicao de Superestrutura da UML [Superstructure, 2011], os elementos mais comuns do diagrama de estrutura composta so: Parte; Porta;
38
Colaborao; Uso de Colaborao; Conector; Papel de ligao (role binding ). DIAGRAMA DE SEQUNCIA De acordo com o documento de especicao de Superestrutura da UML [Superstructure, 2011], dois dos vrios elementos utilizados no diagrama de sequncia so: Fragmentos de Interao; Usos de Interao. A maioria das guras que contm os modelos utilizados nos estudos de caso foi retirada do documento de especicao de Superestrutura da UML [Superstructure, 2011]. As guras utilizadas no estudo de caso 3 foram escolhidas segundo o critrio da simplicidade para facilitar os trabalhos. As guras que se referem ao estudo de caso 6 foram retiradas do trabalho de Micskei e Waeselynck [Micskei & Waeselynck, 2010]. O documento de especicao de Superestrutura da UML [Superstructure, 2011] possui algumas instrues de estilo (Style Guidelines ) que identicam as convenes de notao recomendada pela especicao. Se aplicadas de forma consistente, a compreenso e a comunicao so facilitadas. Por exemplo, existe uma orientao de estilo que sugere que os nomes das classes devem estar em negrito e outra que sugere que os nomes das classes abstratas sejam escritos em itlico. No entanto, no foi encontrado na verso 2.4 do documento de especicao de Superestrutura da UML [Superstructure, 2011] nenhum tipo de conveno de notao que mostre qual a forma correta de codicar qualquer estrutura dos modelos da UML para a linguagem Java. Pretendamos apresentar, considerando a verso 1.6 da linguagem Java, apresentar cdigos esperados resultantes do mapeamento dos modelos de cada estudo de caso para a linguagem Java, a m de facilitar a vericao e validao dos resultados apresentados pelas ferramentas. Entretanto, como durante as pesquisas no foram encontrados relatos de boas prticas para gerao de cdigo Java a partir de um determinado elemento da UML, optamos por realizar a vericao analisando se as estruturas Java geradas so construes vlidas da plataforma Java e se correspondem ou no a interpretaes que podem ser entendidas.
39
3.4.1
ESTUDO DE CASO 1 - Esteretipos
Os esteretipos estendem o vocabulrio da UML permitindo a criao de novos tipos de elementos semelhantes aos j existentes, porm especcos para o problema. Eles permitem aos usurios denir a semntica de notao, alargando assim a linguagem [Sharif & Maletic, 2009]. Um perl da UML o elemento que contm esteretipos, valores etiquetados e restries que podem ser utilizados para estender o meta-modelo da UML [Ziadi et al., 2003]. O modelo da Figura 3.2 foi utilizado neste estudo de caso. Esta modelagem utilizada em um dos documentos da UML e o objetivo aqui no interpretar o signicado, mas sim vericar o tratamento dado aos esteretipos pelas ferramentas. Em funo disso no ser discutido o perl da UML correspondente a este esteretipo.
Figura 3.2. Esteretipo instantiate [Superstructure, 2011].
3.4.2
ESTUDO DE CASO 2 Associaes: Associao Simples, Agregao e Composio; Extremidades de associao.
Segundo Milicev [Milicev, 2007], infelizmente, apesar do conceito de associao ser muito antigo e herdado de outras tcnicas de modelagem de sucesso, ainda no existe um entendimento totalmente sem ambiguidade sobre ele. Esse conceito essencialmente simples foi signicativamente melhorado para aumentar a expressividade da linguagem. Infelizmente, essas melhorias introduziram muitas novas ambiguidades na interpretao de todo o conceito. Conceitualmente e visualmente, os relacionamentos de associao simples, agregao e composio tm diferenas. Porm, sua distino no cdigo no clara, se que feita. Essa distino geralmente no feita no cdigo pelas ferramentas. Na linguagem Java, esses trs tipos de relacionamentos possuem cdigo similar. Gessenharter [Gessenharter, 2008] arma que classes de associao, multiplicidades, agregao e composio no so corretamente ou no so processadas pela maioria dos geradores de cdigo. As ferramentas geralmente no consideram a diferena entre uma associao simples, uma agregao e uma composio. Linguagens de programao orientadas a objeto no contm sintaxe ou semntica para expressar associaes diretamente. Desta forma, associaes da UML tm
40
sido implementadas por uma combinao adequada de classes, atributos e mtodos [Gnova et al., 2003]. Conforme Gessenharter [Gessenharter, 2009], difcil implementar relacionamentos por dois principais motivos: eles fornecem uma semntica complexa para entidades relacionadas e no so construtos de primeira classe nas linguagens de programao modernas. O desao de implementar relacionamentos em cdigo resolver a semntica de elementos abstratos do modelo e transform-las em referncias ou ponteiros da linguagem destino. Uma extremidade de associao pode ser adornada com um nome de papel (role name ), uma multiplicidade, uma sentena de propriedades (property string ), uma navegabilidade, um modicador de visibilidade, entre outros [Superstructure, 2011]. Uma associao descreve um conjunto de tuplas cujos valores se referem a instncias tipadas. Uma instncia de uma associao chamada de ligao. A Figura 3.3 mostra os tipos de extremidades de associao no relacionamento de associao simples (navegvel, no navegvel e no especicado), mapeia todas as combinaes de extremidades. AB navegvel para os dois lados. CD no navegvel para nenhum lado. EF no possui navegabilidade especicada. GH no navegvel para G e navegvel para H. IJ no possui navegabilidade especicada para I e navegvel para J. A Figura 3.4 mostra uma associao ternria. A Figura 3.5 mostra uma agregao com a extremidade de associao de A com navegabilidade no especicada e de B no navegvel. O ponto ao lado das classes indica que a extremidade de associao ao lado de da classe A uma propriedade de B e a extremidade de associao ao lado de B propriedade de A. A Figura 3.6 mostra uma composio com extremidades de associao navegveis e nomeadas.
3.4.2.1
Associao simples, Agregao e Composio
Segundo Gessenharter [Gessenharter, 2008], a situao da gerao de cdigo em relao s associaes surpreendente. As ferramentas avaliadas no consideram a diferena entre associaes simples, agregaes ou composies. Akehurst e outros [Akehurst et al., 2007] consideram til o uso de referncias, mas o descarta porque este mecanismo certamente no impede o acesso a partes excludas. Eles propem uma ideia simples aplicvel: ligaes so sempre acessveis, diretamente pelas instncias referenciadas ou indiretamente pela associao. Se o todo de uma composio excludo, os valores de ligaes que referenciam suas partes devem ser denidos como nulos se as ligaes no so uma instncia da prpria composio. Se nem o todo nem suas partes so referenciados por uma propriedade de outra classe,
41
Figura 3.3. Tipos de extremidades de associao no relacionamento de associao simples [Superstructure, 2011].
Figura 3.4. Associao binria e ternria [Superstructure, 2011].
Figura 3.5. Agregao [Superstructure, 2011].
ambos permanecem ligados, mas inacessveis a partir de qualquer outro lugar e podem ser removidos pelo coletor de lixo. Um problema no resolvido que a destruio das ligaes pode violar multiplicidades das classes associadas. Os modelos das guras 3.3, 3.4, 3.5 e 3.6 so mostrados para abordar com exemplos os tipos de associao. Nosso objetivo no foi estudar todas as possibilidades e
42
Figura 3.6. Relacionamento de Composio [Superstructure, 2011].
este estudo de caso utilizou apenas o modelo da Figura 3.6.
3.4.2.2
Adornos da extremidade de associao
De acordo com Akehurst e outros [Akehurst et al., 2007], o conceito de associao no existe em linguagens de programao orientadas a objeto como Java. Consequentemente, a m de gerar o cdigo de um modelo da UML necessrio elaborar um mapeamento para a linguagem de programao OO escolhida. Os limites superiores das multiplicidades so rudimentarmente implementados. Se ele for maior que 1, o atributo que representa a extremidade de associao do tipo coleo. Assim, apenas dois estados so identicados, um limite superior que igual a 1 ou um de maior valor. As ferramentas, geralmente, no rejeitam uma nova ligao se o limite superior violado [Gessenharter, 2008]. Uma propriedade (property ) um elemento da UML que pode ser considerado sob dois pontos de vista: i) no meta-modelo, em que ela um atributo (structural feature ); ou ii) um valor com nome que denota um aspecto de um elemento, por exemplo, uma classe, uma associao, entre outros [Superstructure, 2011]. Algumas propriedades so predenidas e outras podem ser denidas pelo usurio. As propriedades denem caractersticas de elementos da modelagem. As propriedades podem ser apresentadas de vrias formas. A forma mais usual a sentena de propriedade (property string ). O formato geral um conjunto de sentenas da forma nome=valor, por exemplo abc, def=xyz. A primeira propriedade, abc, implica uma propriedade booleana e uma abreviao de abc=true. A segunda propriedade, def, tem valor xyz. A especicao da UML dene 0, 1 ou mais propriedades para cada um dos elementos da modelagem [Superstructure, 2011]. A sentena de propriedade unique para uma extremidade de associao representa, portanto, que unique=true.
43
As sentenas de propriedade so colocadas entre chaves e servem para dar detalhes da associao. Por exemplo, a propriedade subset <nome da propriedade> serve para mostrar que a extremidade um subconjunto da propriedade chamada <nome da propriedade> [Superstructure, 2011]; a propriedade union serve para mostrar que a extremidade obtida como sendo a unio de seus subconjuntos; a propriedade ordered serve para mostrar que a extremidade representa um conjunto ordenado; a propriedade unique serve para mostrar que a extremidade representa uma coleo que no permite que os mesmos elementos apaream mais de uma vez. As propriedades das extremidades de associao so pouco apoiadas pelas ferramentas [Gessenharter, 2008]. A Figura 3.7 mostra um modelo com nomes da extremidade de associao, sentenas de propriedade e multiplicidade. Se existe a indicao de navegabilidade da classe Customer para a classe Purchase, ento a extremidade purchase uma propriedade da classe Customer. O trabalho realizado por Gessenharter [Gessenharter, 2008] vericou o estado da arte da gerao de cdigo a partir do diagrama de classe da UML avaliando 13 ferramentas - entre elas Astah*, RSA e Enterprise Architect, avaliadas neste trabalho. Todas as ferramentas avaliadas geraram cdigo para as associaes utilizando atributos nas classes. No caso de uma associao binria, cada classe foi gerada com um atributo que pode armazenar uma referncia para a classe oposta. O trabalho vericou que na maioria das ferramentas os limites superiores das multiplicidades so rudimentarmente implementados. Alm disso, a ausncia da representao da propriedade navegabilidade no cdigo leva a associaes que so navegveis em ambos os sentidos. Esta suposio problemtica porque as associaes no navegveis podem ser teis com classes de associao e, portanto, devem ser autorizadas e traduzidas para o cdigo [Gessenharter, 2008]. O modelo da Figura 3.7 foi utilizado neste estudo de caso.
Figura 3.7. Adornos da extremidade de associao: navegabilidade, multiplicidade, sentena de propriedades e nomes da extremidade de associao [Superstructure, 2011].
44
3.4.3
ESTUDO DE CASO 3 Classes concretas, Classes Abstratas e Interfaces: extends e implements.
O conceito de herana bem estudado na literatura e caracteriza as linguagens de programao orientadas a objeto [Chiril et al., 2010] [Parkinson & Bierman, 2008] [Smans et al., 2009]. A linguagem Java dene: i) a relao de herana (extends ) entre classes; ii) a relao de herana entre interfaces (extends ); e iii) a relao de implementao (implements ) entre classe e interface. A relacao extends denida utilizando conceitos de herana simples e no utiliza conceitos de herana mltipla [Lewis & Loftus, 2007]. No entanto, Java suporta herana mltipla entre interfaces, isto , uma interface I1 pode herdar as caractersticas de uma interface I2 e de uma interface I3. Apesar de herana ser considerada no mbito da relao extends, de acordo com Chirila e outros [Chiril et al., 2010], os aspectos de herana devem ser considerados tanto em relao a extends como em relao a implements. Segundo Tempero e outros [Tempero et al., 2008], existem diferentes tipos de vrtices para distinguir diferentes tipos de tipos (types ), isto , classes (C), interfaces (I), enums (E), annotations (A) e exceptions (Ex). Podemos distinguir as classes e interfaces por elas terem relaes bastante diferentes entre si e desempenharem papis diferentes em uma hierarquia de herana. Distinguimos enums e annotations porque, embora sejam implementadas, respectivamente, como classes especializadas e interfaces, suas funes so diferenciadas. A Figura 3.8 mostra um relacionamento de herana simples e a Figura 3.9 mostra um relacionamento de herana mltipla. Um problema relacionado falta de implementao de herana mltipla em Java, segundo Warth e outros [Warth et al., 2006], a necessidade de duplicao de uma quantidade signicativa de cdigo em determinados momentos. Kegel e Steimann [Kegel & Steimann, 2008] ressaltam os aspectos positivos e negativos da herana em programas orientados a objetos. Como aspecto positivo permite o reuso de implementao com o mnimo de esforo e como aspecto negativo estabelece forte acoplamento entre as classes e tende a inchar as interfaces das subclasses com membros desnecessrios. Esse aspecto negativo particularmente um problema em linguagens como Java, cuja noo de subclasse mistura os conceitos de herana e subtipagem (typing ) de modo que a primeira no pode ser desfrutada sem o ltimo. 1. Exemplo de herana simples entre classes: C1 extends C2 2. Exemplo de herana mltipla entre interfaces: I1 extends I2, I3
45
Figura 3.8. Herana Simples entre classes.
Figura 3.9. Herana Mltipla entre interfaces.
Os trabalhos cientcos pesquisados continham apenas modelos simples, explorando apenas o relacionamento extends. Para facilitar os trabalhos, foi usado o critrio simplicidade para escolher o modelo utilizado no estudo de caso. A Figura 3.10 mostra um modelo com classes concretas, classes abstratas e interfaces, e os relacionamentos extends e implements. A Figura 3.10 mostra um modelo em que a classe concreta Pessoa implementa a interface IPessoa; a classe concreta MGEndereo estende a classe abstrata Endereo que, por sua vez, implementa a interface IEndereo. O modelo da Figura 3.10 foi utilizado neste estudo de caso.
3.4.4
ESTUDO DE CASO 4 - Classes, Interfaces e Anotaes
O diagrama de classe um dos um dos diagramas mais utilizados da UML e presente na anlise e desenho de software [Artale et al., 2010]. Conceitos de modelagem de classe so os conceitos mais utilizados em UML. Alguns projetos de desenvolvimento criam apenas modelos contendo apenas diagramas de classe [France et al., 2006].
46
Figura 3.10. Classes concretas, Classes abstratas e Interfaces.
Dobing e Parsons [Dobing & Parsons, 2006] realizaram um trabalho experimental em que foram entrevistados 171 analistas que utilizavam a UML e outros 11 que utilizavam componentes da UML como parte de outra metodologia OO. Os entrevistados relataram ter se envolvido em uma mdia de 27 projetos (cerca de 6,2 utilizando a UML), ao longo de uma carreira de 15 anos em tecnologia da informao. O trabalho realizado por Dobing e Parsons [Dobing & Parsons, 2006] relata que 73% dos entrevistados utilizavam o diagrama de classes em dois teros ou mais de seus projetos. Kollmann e outros [Kollman et al., 2002] realizaram um trabalho que analisou o estado da arte das ferramentas de engenharia reversa em relao ao mapeamento de Java para diagramas de classe da UML. Alguns elementos do diagrama de classe analisados foram: i) nmero de classes; ii) nmeros de associaes; iii) tipos de associaes; iv) multiplicidades; entre outros. Alguns desses elementos foram utilizados como mtricas por Manso e outros [Manso et al., 2003] para analisar a complexidade estrutural do diagrama de classe. Com o objetivo de analisar ferramentas de engenharia de ida e volta e estender o trabalho de Kollmann e outros [Kollman et al., 2002], este estudo de caso tem como objetivo analisar como feito o mapeamento de alguns elementos da UML para a linguagem Java, entre eles as anotaes (annotations ) padronizadas de classes. Foram analisados como esses conceitos so considerados durante o mapeamento de UML para Java. A Figura 3.11 mostra um diagrama de classes com classes (abstratas e no abstratas), atributos (estticos e no estticos), mtodos (estticos e no estticos)
47
e interfaces. Durante e aps esse processo de mapeamento, foram feitas vericaes e consideraes sobre a interao da ferramenta com o usurio e a consistncia dos artefatos de sada da ferramenta.
Figura 3.11. Diagrama de Classe [Superstructure, 2011] (Adaptado).
3.4.5
ESTUDO DE CASO 5 - Estrutura Composta
A funo do diagrama de estrutura composta estender a capacidade de modelagem da UML, alm das classes e relacionamentos e , principalmente, auxiliar a modelagem de estruturas internas de classes com um conceito mais bem denido de decomposio [Oliver & Luukala, 2006]. Segundo France e outros [France et al., 2006], um diagrama de estrutura composta descreve a estrutura interna de um classicador estruturado. Um classicador estruturado pode ser associado com portas que representam pontos de interaes com o classicador. No foram encontrados trabalhos cientcos que abordam a relao entre UML e Java no que se refere ao diagrama de estrutura composta. No foram encontrados
48
relatos de boas prticas para gerao de cdigo Java a partir do diagrama de estrutura composta.
3.4.5.1
Estrutura composta I
A Figura 3.12 mostra um diagrama de classe, esquerda, que corresponde em certo sentido ao diagrama de estrutura composta, direita. O diagrama de estrutura composta complementa o diagrama de classes e mostra detalhes da estrutura interna de uma classe. O fato de a multiplicidade entre as classes Wheel e Engine serem N:N no diagrama de classes e 2:1 no diagrama de estrutura composta no signica que h inconsistncia. Vrias objetos da classes Wheel pode se relacionar com vrios objetos da classe Engine. Mas, no contexto da classe Car, o classicador estruturado Car possui duas partes: uma coleo de dois elementos do tipo Wheel, chamado de rear (duas rodas traseiras) e um elemento do tipo Engine (motor). Desta forma, pode-se entender que um objeto do tipo carro possui duas rodas traseiras que so tracionadas por um motor atravs de um eixo. importante observar que o diagrama de estrutura composta considera os elementos em nvel de objetos, isto , em instncias de classe. Outro aspecto importante que se pode vericar no diagrama de estrutura composta a denio do relacionamento do classicador estruturado, o todo, com as partes. A linha que contorna a parte Wheel contnua, enquanto a linha que contorna a parte Engine tracejada. A linha contnua representa o relacionamento de composio, j a linha tracejada representa o relacionamento de associao simples. O diagrama de estrutura composta da Figura 3.12 foi utilizado neste estudo de caso.
Figura 3.12. Um diagrama de classe correspondente a um diagrama de estrutura composta. [Superstructure, 2011]
49
3.4.5.2
Estrutura Composta II
A Figura 3.13 e a Figura 3.14 mostram que, num diagrama de estrutura composta, possvel fazer especializaes (vrios tipos de Wheel) com mais facilidade que num diagrama de classe. A declarao de quatro objetos do mesmo tipo, assim como a denio de seus relacionamentos uma tarefa mais simples no diagrama de estrutura composta que no diagrama de classe. Porm, se o diagrama de estrutura composta no puder ser utilizado como entrada para o mapeamento de UML para Java, ou seja, se no puder ser feito o mapeamento desse diagrama para o cdigo, os detalhes particulares que podem ser vericados no diagrama caro como informaes perdidas aps o processo de mapeamento. O modelo da Figura 3.13 foi utilizado neste estudo de caso.
Figura 3.13. Diagrama de estrutura composta da classe Car com a parte Wheel (i).
Figura 3.14. Diagrama de estrutura composta da classe Car com a parte Wheel (ii).
50
3.4.6
ESTUDO DE CASO 6 - Fragmento Combinado
Os diagramas de comportamento da UML incluem muitos conceitos que no so apresentados nas linguagens de programao mais populares, como C++ e Java, por exemplo: eventos, estados, histrico de estados (history states ), entre outros. Isto signica que no existe um mapeamento um-para-um entre um statechart - composto por estados, eventos e transies - e sua implementao. [Jakimi & Elkoutbi, 2009]. A partir da UML 2.0, o diagrama de sequncia sofreu algumas alteraes. A verso 2.0 da UML modicou signicativamente o Diagrama de Sequncia e a expressividade da linguagem foi consideravelmente aumentada [Micskei & Waeselynck, 2010]. No foram encontrados trabalhos cientcos que abordam a relao entre UML e Java no que se refere aos fragmentos combinados. No foram encontrados relatos de boas prticas para gerao de cdigo Java a partir destes elementos do diagrama de sequncia. 3.4.6.1 Fragmento Combinado I
A Figura 3.15 mostra um diagrama sequncia que possui o fragmento combinado alt. Este diagrama foi utilizado neste estudo de caso. O fragmento combinado alt representa uma estrutura condicional. As operaes que fazem parte do primeiro compartimento s so executados se a condio for satisfeita. Do contrrio, apenas os mtodos do segundo compartimento sero executados. 3.4.6.2 Fragmento Combinado II
A Figura 3.16 mostra um diagrama de sequncia que possui o fragmento combinado loop. O objetivo dos fragmentos combinados resumir um conjunto de informaes numa estrutura mais simples. O termo loop indica iterao, assim como alt representa uma estrutura condicional. Porm, h casos em que essas estruturas feitas para auxiliar no entendimento o tornam confuso, como pode ser vericado na Figura 3.16. Dentro das limitaes do fragmento combinado loop esto o mtodo m2 completamente e o mtodo m1 parcialmente. Nessas condies, surge a questo: ambos os mtodos m1 e m2 so afetados pelo fragmento combinado loop ou apenas o mtodo m2?
3.5
Aplicao dos Estudos de Caso
Esta seo apresenta os resultados obtidos a partir da aplicao dos estudos de caso apresentados na seo 3.4, utilizando as trs ferramentas selecionadas - Astah*, Ra-
3.5. Aplicao dos Estudos de Caso
51
Figura 3.15. Diagrama de sequncia com o fragmento combinado alt.
Figura 3.16. Diagrama de sequncia com o fragmento combinado loop gerando ambiguidade.
tional Software Architect e Enterprise Architect. As subsees desta seo esto em conformidade com as subsees da seo 3.4. Os comentrios do cdigo gerado que possuam apenas informaes como data, autor, verso do projeto e ans, foram retirados. Apenas as informaes relevantes e pertinentes anlise foram preservadas na apresentao do cdigo. Os cdigos gerados pelas ferramentas referente a cada estudo de caso so apresentados.
52
3.5.1
ESTUDO DE CASO 1 - Esteretipos
A Figura 3.17 mostra o modelo elaborado na Astah* para o estudo de caso 1. O relacionamento de dependncia entre a classe CarFactory e a classe Car estereotipado. O cdigo gerado pela Astah* mostrado na Figura 3.18. Foram mapeadas apenas as classes. A informao conceitual do esteretipo e do relacionamento de dependncia no foi mapeada.
Figura 3.17. Modelo elaborado na ferramenta Astah* para o estudo de caso 1.
Figura 3.18. Cdigo gerado pela Astah* para o modelo da Figura 3.17.
Considerando os critrios estabelecidos neste captulo, Astah* teve o seguinte desempenho: C1 Conabilidade do Cdigo Gerado: Parcialmente consistente (1). Astah* gerou as duas classes conforme apresentado no modelo. Porm, no fez referncia no cdigo ao esteretipo e ao relacionamento entre a classe CarFactory e a classe Car. C2 Capacidade de Resoluo de Ambiguidades do Modelo: No se aplica (0). No existem estruturas no modelo que podem ser mapeadas de mais de uma forma. C3 Consistncia Interna da Ferramenta: Parcialmente consistente (1). Aps realizar a engenharia reversa, apenas as classes foram recuperadas. O relacionamento de dependncia e o esteretipo no foram recuperados, uma vez que no foram mapeados na engenharia frente. C4 Flexibilidade e Robustez da Ferramenta: Parcialmente robusta (1). O modelo foi elaborado conforme o modelo do estudo de caso. No entanto, a ferramenta no utiliza todas as informaes constantes no modelo ao fazer o mapeamento do modelo para o cdigo. A Figura 3.19 mostra o modelo elaborado na RSA. A simplicidade do modelo facilita a gerao do cdigo. Porm, o esteretipo do relacionamento de dependncia
53
entre a classe CarFactory e a classe Car no foi mapeado no cdigo. A Figura 3.20 mostra o cdigo gerado pela RSA.
Figura 3.19. Modelo elaborado na ferramenta RSA para o estudo de caso 1.
Figura 3.20. Cdigo gerado pela RSA a partir do modelo da Figura 3.19.
Considerando os critrios estabelecidos neste captulo, RSA teve o seguinte desempenho: C1 Conabilidade do Cdigo Gerado: Parcialmente consistente (1). O mapeamento realizado pela RSA produziu as duas classes, conforme apresentado no modelo. Porm, o esteretipo e o relacionamento de dependncia no foram mapeados. C2 Capacidade de Resoluo de Ambiguidades do Modelo: No se aplica (0). No existem estruturas no modelo que podem ser mapeadas de mais de uma forma. C3 Consistncia Interna da Ferramenta: Parcialmente consistente (1). Apenas as duas classes foram recuperadas pela engenharia reversa. O relacionamento de dependncia e o esteretipo no foram recuperados, uma vez que no foram mapeados na engenharia frente. C4 Flexibilidade e Robustez da Ferramenta: Parcialmente robusta (1). O modelo foi elaborado conforme o modelo do estudo de caso. No entanto, a ferramenta no utiliza todas as informaes constantes no modelo ao fazer o mapeamento do modelo para o cdigo. A Figura 3.21 mostra o modelo elaborado na EA. No houve diculdade para a elaborao do modelo. Porm, EA no mapeou para o cdigo o esteretipo nem relacionamento de dependncia entre a classe CarFactory e a classe Car. A Figura 3.22 mostra o cdigo gerado pela EA. Considerando os critrios estabelecidos neste captulo, EA teve o seguinte desempenho:
54
Figura 3.21. Modelo elaborado na ferramenta EA para o estudo de caso 1.
C1 Conabilidade do Cdigo Gerado: Parcialmente consistente (1). EA gerou as duas classes conforme apresentado no modelo. No entanto, no fez referncia no cdigo ao esteretipo e ao relacionamento entre a classe CarFactory e a classe Car. C2 Capacidade de Resoluo de Ambiguidades do Modelo: No se aplica (0). No existem estruturas no modelo que podem ser mapeadas de mais de uma forma. C3 Consistncia Interna da Ferramenta: Parcialmente consistente (1). A engenharia reversa recuperou apenas as classes. Como o relacionamento de dependncia e o esteretipo foram mapeados na engenharia frente, no foram recuperados. C4 Flexibilidade e Robustez da Ferramenta: Parcialmente robusta (1). O modelo foi elaborado conforme o modelo do estudo de caso. No entanto, a ferramenta no utiliza todas as informaes constantes no modelo ao fazer o mapeamento do modelo para o cdigo.
3.5.2
ESTUDO DE CASO 2 - Associaes: Associao Simples, Agregao e Composio; Extremidades de associao
3.5.2.1
Associao simples, Agregao e Composio
A Figura 3.23 mostra o modelo elaborado na ferramenta Astah*. O que h de destaque neste estudo de caso a multiplicidade que existe na extremidade de associao da classe Slider. A Figura 3.24 mostra o cdigo criado pela Astah*. Este exemplo permite vericar que a opo default da Astah* para representar um conjunto de dados do mesmo tipo a criao de uma Collection. No foi solicitado nenhum tipo de inter-
55
veno do usurio para a escolha da estrutura mais adequada para a representao da multiplicidade. Poderia ter criado um List, um Array ou um Vector, por exemplo, mas foi criada uma Collection. A Astah* tambm no foi precisa na denio do tamanho da estrutura de dados. A multiplicidade da classe Slider 2 e no innita, como foi mapeado no cdigo. possvel perceber que os nomes das extremidades de associao (scrollbar na extremidade da classe Slider; title na extremidade da classe Header; e body na extremidade da classe Panel) foram utilizados pela ferramenta. O atributo do tipo Slider declarado na classe Window recebeu o nome de scrollbar ; o atributo do tipo Header declarado na classe Window recebeu o nome de title ; o atributo do tipo Panel declarado na classe Window recebeu o nome de body . Entretanto, a informao visual e conceitual dos relacionamentos de composio foi perdida. Observando o modelo, possvel armar que o relacionamento entre a classe Window e as outras classes de composio. Observando o cdigo, no possvel armar o mesmo. O relacionamento de composio generalizado para o de associao simples. No foi exibido nenhum tipo de mensagem informando isso ao usurio. A partir do cdigo gerado, foi realizada a engenharia reversa. Todas as classes foram recuperadas, assim como os nomes nas extremidades de associao. Entretanto, os relacionamentos entre as classes foram mapeados como associaes simples, em vez de composio. Como a multiplicidade na extremidade de associao da classe Slider foi mapeada para o cdigo como N, a engenharia de volta mapeou a multiplicidade como *, em vez de 2.
Figura 3.23. Modelo elaborado na ferramenta Astah* para o estudo de caso 2(i).
A Figura 3.25 mostra o modelo elaborado na RSA referente ao modelo do estudo de caso 2. A Figura 3.26 mostra o cdigo gerado. O relacionamento de composio foi informao perdida, uma vez que RSA o mapeou como associao simples. A multipli-
56
Figura 3.24. Cdigos gerados pela Astah* para o modelo da Figura 3.23.
cidade da extremidade de associao da classe Slider foi considerada no mapeamento. Foi gerada uma coleo de Slider de tamanho 2 utilizando arranjos. Os arranjos so a estrutura padro utilizada para representar colees com limite superior denido. Apesar de haver outras formas de mapeamento da multiplicidade, RSA no forneceu essas opes ao usurio. A engenharia reversa, utilizando o cdigo gerado, produziu um modelo correspondente ao modelo inicial. As multiplicidades e os nomes nas extremidades de associao foram gerados corretamente. No entanto, o relacionamento de composio foi informao perdida, a engenharia reversa gerou relacionamentos de associao simples.
Figura 3.25. Modelo elaborado na ferramenta RSA para o estudo de caso 2(i).
57
Figura 3.26. Cdigos Gerados Pela RSA Para o Modelo da Figura 3.25
A Figura 3.27 mostra o modelo elaborado na EA referente ao modelo do estudo de caso 2. A Figura 3.28 mostra o cdigo gerado pela EA a partir do modelo da Figura 3.27. possvel observar que no h no cdigo qualquer elemento que faa meno ao relacionamento de composio. Alm disso, a multiplicidade denida na extremidade de associao da classe Slider foi ignorada. Esperava-se o mapeamento de uma coleo do tipo Slider. A navegabilidade foi mapeada corretamente, foi criado um atributo referente a cada classe que est associada com a classe Window. Os nomes dos atributos foram os mesmos dos nomes das extremidades de associao A engenharia reversa recuperou as classes, os relacionamentos e os nomes das extremidades de associao. Os nomes das extremidades de associao, assim como a navegabilidade dos relacionamentos foram recuperados. No entanto, a multiplicidade o elemento que caracteriza o relacionamento de composio foram informaes perdidas.
3.5.2.2
Adornos da extremidade de associao
A Figura 3.29 mostra o modelo elaborado na Astah* para o estudo de caso 2. A Figura 3.30 mostra o cdigo gerado pela Astah*. Os cdigos das classes Purchase e Account foram gerados conforme o esperado. O cdigo da classe Customer foi gerado com dois atributos, observando a multiplicidade. No entanto, a Astah* no especicou o
58
Figura 3.27. Modelo elaborado na ferramenta EA referente ao estudo de caso 2(i).
Figura 3.28. Cdigo gerado pela EA a partir do modelo da Figura 3.27.
tamanho da coleo do tipo Account. Diferentemente da coleo do tipo Purchase, que no tem limite superior denido, a coleo de Account limitada em 5 no modelo. Nos dois casos, a estrutura Collection foi utilizada, por default, para representar a coleo. No foi fornecido ao usurio nenhum tipo de opo de mapeamento quanto escolha da estrutura mais adequada para representar a coleo. A multiplicidade no foi ignorada, mas o mapeamento no observou os detalhes especicados no modelo. As sentenas de propriedade ordered, unique e unique no
59
foram consideradas no mapeamento. Como pode ser visto no cdigo gerado, no foi feita nenhuma referncia a estas estruturas. A engenharia reversa recuperou as classes e os nomes das extremidades de associao, conforme o modelo. No entanto, a multiplicidade da extremidade de associao da classe Account foi recuperada sem especicar o limite superior estabelecido no modelo. A navegabilidade, que existia apenas na direo de Customer para Purchase e de Customer para Account, aps a engenharia reversa existe em todos as direes. Alm disso, as sentenas de propriedade foram informaes perdidas.
Figura 3.29. Modelo elaborado na ferramenta Astah* referente ao estudo de casoe 2(ii).
A Figura 3.31 mostra o modelo elaborado na ferramenta RSA para o estudo de caso 2. No foi possvel inserir as sentenas de propriedade ordered, unique e unique. A Figura 3.32 mostra o cdigo gerado pela RSA. O relacionamento da classe Customer com a classe Purchase de 1:N. RSA criou, por defatult, na classe Customer uma coleo do tipo Purchase, utilizando a estrutura Set. Para representar a multiplicidade entre a classe Customer e a classe Account, RSA criou um arranjo com 5 posies . possvel inferir que a RSA utiliza diferentes tipos de estrutura de acordo com a
60
multiplicidade. Quando os limites inferior e/ou superior esto denidos, a estrutura [] utilizada; quando o no esto denidos, a estrutura Set utilizada. Porm, no foi oferecido nenhum tipo de opo de mapeamento. As classes Account e Purchase foram criadas com seus corpos vazios, observando a navegabilidade denida no modelo. Como no foi possvel inserir as sentenas de propriedade unique e ordered, unique, a anlise do mapeamento foi prejudicada. A engenharia reversa gerou um modelo com todas as caractersticas denidas no modelo inicial.
Figura 3.31. Modelo elaborado na ferramenta RSA referente ao estudo de caso 2(ii).
A Figura 3.33 mostra o modelo elaborado na ferramenta EA para o estudo de caso 2. No foi possvel inserir todas as sentenas de propriedade, encontramos apenas ordered. A Figura 3.34 mostra o cdigo gerado pela EA a partir do modelo da Figura 3.33. A classe Customer possui atributos que fazem referncia classe Account e classe Purchase, observando a navegabilidade especicada no modelo. No entanto, a multiplicidade nas extremidades de associaes destas classes foi ignorada nos dois casos. Em vez de um atributo simples, deveria ter sido gerada uma coleo.
61
As extremidades de associao da classe Customer no possuem navegabilidade especicada. A EA gerou um atributo na classe Account para fazer referncia classe Customer, mas no fez o mesmo na classe Purchase. A sentena de propriedade na extremidade de associao da classe Account no foi mapeada. A engenharia reversa gerou um modelo com os principais elementos presentes no modelo inicial, mas houve informao perdida. Por no terem sido mapeadas na engenharia frente, as multiplicidades no puderam ser recuperadas. Da mesma forma, a sentena de propriedade ordered no foi recuperada. Em virtude do atributo mapeado na classe Account para fazer referncia classe Customer, a navegabilidade foi recuperada como navegvel nas duas direes.
Figura 3.33. Modelo elaborado na ferramenta EA referente ao estudo de caso 2(ii).
Considerando os critrios estabelecidos neste captulo, Astah* teve o seguinte desempenho: C1 Conabilidade do Cdigo Gerado: Parcialmente consistente (1). As classes e os relacionamentos foram recuperados corretamente. No entanto, nas duas situaes apresentadas, o mapeamento da multiplicidade no observou o limite superior especicado no modelo.
62
C2 Capacidade de Resoluo de Ambiguidades do Modelo: Resolve parcialmente (1). As multiplicidades observadas nas duas situaes permitem mais de um tipo de mapeamento. Astah* optou, por default, por representar a coleo com a estrutura Set. A navegabilidade denida como no especicada mapeada para o cdigo como navegvel, embora o usurio no seja consultado se a opo mais adequada. C3 Consistncia Interna da Ferramenta: Parcialmente Consistente (1). Todas as classes e relacionamentos foram recuperados pela engenharia reversa. Todavia, as informaes conceituais relacionamento de composio e as sentenas de propriedades - foram perdidas durante o processo de ida e volta. Alm disso, os limites superiores especicados no modelo tambm foram generalizados como ilimitados. A navegabilidade dos relacionamentos do modelo gerado tambm no correspondeu do modelo inicial. C4 Flexibilidade e Robustez da Ferramenta: Parcialmente robusta (1). Foi possvel denir todos os detalhes do modelo conforme o estudo de caso 2. No entanto, a multiplicidade e a navegabilidade foram mapeadas sem observar detalhes claros do modelo. Considerando os critrios estabelecidos neste captulo, RSA teve o seguinte desempenho: C1 Conabilidade do Modelo Gerado: Consistente (2). Todas as classes foram geradas, assim como os relacionamentos, a navegabilidade, a multiplicidade e os nomes nas extremidades de associao. Como no foi possvel inserir as sentenas de propriedade unique e ordered, unique, parte da anlise foi prejudicada. C2 Capacidade de Resoluo de Ambiguidades do Modelo: Resolve parcialmente (1). As multiplicidades observadas nas duas situaes permitem mais de um tipo de mapeamento. RSA utilizou duas diferentes estruturas Java para mapear uma coleo com limite superior denido e outra com limite superior ilimitado. No entanto, no foi fornecido nenhum tipo de opo de mapeamento ao usurio. C3 Consistncia Interna da Ferramenta: Parcialmente consistente (1). O modelo gerado a partir da engenharia reversa recuperou todas as informaes presentes no modelo inicial, com exceo do relacionamento de composio, que foi recuperado como um relacionamento de associao simples. Mas, como se trata de informao conceitual e a linguagem Java no dene uma estrutura que o diferencie da associao simples, isso no considerado um erro. A multiplicidade foi recuperada corretamente, assim como os nomes das extremidades de associao. C4 Flexibilidade e Robustez da Ferramenta: Parcialmente Robusta (1). Com exceo do relacionamento de composio, que informao conceitual, a RSA preservou todas as informaes do modelo, tanto no mapeamento de UML para Java quanto
63
de Java para UML. No entanto, a anlise foi prejudicada em parte porque no foi possvel inserir as sentenas de propriedade no modelo. Considerando os critrios estabelecidos neste captulo, a EA teve o seguinte desempenho: C1 Conabilidade do Modelo Gerado: Parcialmente consistente (1). As classes e os atributos foram gerados conforme as especicaes do modelo. No entanto, a multiplicidade na extremidade de associao da classe Slider no foi considerada no mapeamento. C2 Capacidade de Resoluo de Ambiguidades: No se aplica (0). A parte do cdigo que permite vericar a capacidade de resolver ambigidades a coleo do tipo Slider, que pode ser representado de vrias maneiras. A EA sequer gerou essa coleo. Ela ignorou a multiplicidade, o que diferente de no ser capaz de resolver a ambiguidade. C3 Consistncia Interna da Ferramenta: Parcialmente consistente (1). O modelo gerado a partir da engenharia reversa recuperou todas as informaes presentes no modelo inicial, com exceo da multiplicidade. As informaes conceituais - relacionamento de composio e sentena de propriedades - no foram mapeadas para o cdigo. Portanto, tambm no foram mapeadas de volta para o modelo. C4 Flexibilidade e Robustez da Ferramenta: Parcialmente robusta (1). A multiplicidade, que um aspecto bsico e importante do diagrama de classes, foi ignorada no mapeamento. No foi possvel inserir todas as sentenas de propriedades no modelo.
3.5.3
ESTUDO DE CASO 3 - Classes concretas, Classes Abstratas e Interfaces: extends e implements
A Figura 3.35, a Figura 3.36 e a Figura 3.37 mostram os modelos elaborados nas ferramentas Astah*, RSA e EA, respectivamente, referente ao estudo de caso 3. Os modelos foram elaborados com facilidade. Os cdigos gerados pelas ferramentas foram idnticos. A Figura 3.38 mostra o cdigo. As classes, as interfaces e os relacionamentos de realizao (realization ) e herana (extends ) foram mapeados corretamente. O relacionamento de realizao representado em Java pela palavra reservada implements. A Figura 38 mostra as classes Endereco e Pessoa implementando as interfaces IEndereco e IPessoa, respectivamente. A classe MGEndereco estende a classe Endereco. A partir do cdigo gerado, a engenharia reversa recuperou todos os elementos constantes no modelo inicial. Todas as ferramentas obtiveram desempenho similar.
64
Figura 3.35. Modelo elaborado na ferramenta Astah* referente ao estudo de caso 3.
Figura 3.36. Modelo elaborado na ferramenta RSA referente ao estudo de caso 3.
Considerando os critrios estabelecidos neste captulo, as ferramentas obtiveram o seguinte desempenho: C1 Conabilidade do Modelo Gerado: Consistente (2). Todos os elementos do modelo foram mapeados corretamente para o cdigo: as classes, as interfaces e os relacionamentos de realizao e de herana.
65
Figura 3.37. Modelo elaborado na ferramenta EA referente ao estudo de caso 3.
C2 Capacidade de Resoluo de Ambiguidades: No se aplica (0). Os elementos do modelo possuem relao de um para um com os elementos do cdigo, isto , existe apenas uma forma de mapeamento. Este estudo de caso no explorou a capacidade da ferramenta resolver ambiguidades. C3 Consistncia Interna da Ferramenta: Consistente (2). O modelo gerado pela engenharia reversa a partir do cdigo mapeado corresponde exatamente ao modelo inicial. C4 Flexibilidade e Robustez da Ferramenta: Robusta (2). As ferramentas permitem a insero do relacionamento extends entre classes e implements entre classe e interface, conforme a linguagem Java. No entanto, no permitem a insero do relacionamento realizes entre classes, mas apenas entre classe e interface.
3.5.4
ESTUDO DE CASO 4 - Classes, Interfaces e Anotaes
A Figura 3.39 mostra o modelo elaborado na Astah* referente ao estudo de caso 4. A Figura 3.40 mostra o cdigo da classe Window gerado aps a engenharia de ida. Alm da classe Window, foram criadas, com o corpo vazio, as classes Area, Rectangle, WindowAbstract, WindowInterface e XWindow. As classes Area, Rectangle e XWindow foram criadas pela Astah* pelo fato de serem declarados atributos desses tipos e eles no estarem pr-denidos. A Figura 3.41
66
Figura 3.38. Cdigo gerado pelas ferramentas referente ao modelo das Figuras 3.35, 3.36 e 3.37.
mostra a mensagem exibida ao usurio no momento da declarao do atributo size, do tipo Area. perguntado se o usurio deseja criar esse novo tipo no modelo corrente. A vantagem dessa solicitao ter a certeza de que s sero declaradas variveis de tipos pr-denidos. A Figura 3.42 mostra alguns tipos pr-denidos nas ferramentas. Porm, para o contexto em que se considere a importao de bibliotecas da linguagem Java, a criao de novos tipos no interessante. Desta forma, Astah* tambm permite importar bibliotecas de forma que seja possvel declarar atributos de outros tipos alm dos pr-denidos. Os tipos dos atributos, mtodos, retornos e parmetros foram mapeados conforme o modelo, alm da visibilidade. O atributo colors, que uma coleo de String, foi mapeado utilizando arranjos - [ ] -, observando a multiplicidade denida no modelo. No entanto, Astah* gerou cdigo com erro de sintaxe para o atributo size. A instanciao
67
Figura 3.39. Modelo elaborado na ferramenta Astah* referente ao estudo de caso 4.
correta para a declarao seria public Area area = new Area(100, 100). O elemento anotao no foi mapeado para o cdigo. Com exceo da declarao do atributo size e do atributo visibility, o cdigo gerado pela ferramenta foi consistente com o modelo. A interface WindowInterface e a classe abstrata WindowAbstract foram mapeadas corretamente. Para manter a consistncia, Astah* criou as classes referentes aos tipos no pr-denidos: Area, Rectangle e XWindow. Aps obter o cdigo gerado, foi feito o processo contrrio. Como havia erro de sintaxe no cdigo da classe Window, Astah* exibiu uma mensagem de erro, conforme a Figura 3.43. O modelo no foi gerado de volta, caracterizando inconsistncia interna da ferramenta, uma vez que produziu um artefato e no foi capaz de interpret-lo. Considerando os critrios estabelecidos neste captulo, Astah* teve o seguinte desempenho: C1 - Conabilidade do Cdigo Gerado: Cdigo parcialmente consistente (1). Com exceo do erro de sintaxe da declarao dos atributos size e visibility, o cdigo gerado
68
Figura 3.40. Classe Window gerada pela ferramenta Astah*.
Figura 3.41. Mensagem enviada ao usurio perguntando sobre a criao do novo tipo Area.
consistente com o modelo especicado. C2 - Capacidade de Resoluo de Ambiguidades de Modelo: Resolve parcialmente
69
Figura 3.42. Tipos pr-denidos pela ferramenta Astah*.
Figura 3.43. Erro na engenharia reversa do estudo de caso 4.
(1). O atributo colors permite mais de um tipo de mapeamento. A coleo poderia ter sido representada por Set, List ou Vector, por exemplo. No houve interao com o usurio, mas pode-se vericar que a opo default da ferramenta para representar uma coleo utilizar arranjo. Existe uma rea de congurao em que pode ser alterada a opo default. C3 - Consistncia Interna da Ferramenta: Inconsistente (0). Ocorreu erro no processo de engenharia reversa e no foi possvel gerar o modelo a partir do cdigo. Observa-se, neste caso, que a ferramenta gerou cdigo e foi incapaz de mapear de volta para o modelo este cdigo que ela mesma gerou. Com a correo manual da sintaxe da
70
inicializao do atributo size, Astah* foi capaz de gerar o modelo, que correspondeu ao modelo inicial. C4 - Flexibilidade e Robustez da Ferramenta: Parcialmente Robusta (1). Para declarar um atributo do tipo Area, foi necessrio criar a respectiva classe no modelo. Um ponto positivo da ferramenta foi restringir a declarao de atributos a tipos prdenidos ou tipos existentes nas bibliotecas importadas. Um ponto negativo foi a ferramenta ter gerado cdigo com erro de sintaxe. A Figura 3.44 mostra o modelo elaborado na RSA conforme estabelecido no estudo de caso 4. Alguns detalhes, como parmetros e tipos dos parmetros, so omitidos no modelo para sintetizar o que exibido, mas so propriamente denidos nas propriedades. Por exemplo, apesar de existirem dois mtodos window(), o primeiro no possui parmetros e o segundo possui dois parmetros A Figura 3.45 mostra o cdigo gerado pela ferramenta.
Figura 3.44. Modelo elaborado na ferramenta RSA referente ao estudo de caso 4.
71
O cdigo gerado parcialmente consistente com o modelo. Os tipos dos atributos, dos mtodos, dos parmetros e dos mtodos foram preservados, assim como a visibilidade. A interface WindowInterface e a classe abstrata WindowAbstract foram mapeadas corretamente. Os aspectos somente de leitura e abstrato so representados na linguagem Java, respectivamente, com as palavras reservadas nal e abstract. O atributo staticReadOnlyB, esttico e somente de leitura, no teve este aspecto mapeado para o cdigo. De modo anlogo, o mtodo staticAbstract, esttico e abstrato, no teve este aspecto mapeado para o cdigo. O elemento anotao no foi mapeado para o cdigo. O atributo size foi mapeado para o cdigo sem inicializao. Por outro lado, o atributo visibility foi inicializado corretamente. No permitido declarar atributo de tipo no existente, como foi o caso do tipo XWindow. Nenhuma informao foi exibida ao usurio, apenas no foi permitida a declarao deste tipo. Ento, criou-se a classe do tipo XWindow no prprio modelo. A partir de ento, pode-se declarar atributo deste novo tipo. um ponto positivo porque garante que, para que sejam utilizados, todos os, de fato, tipos existam. O atributo colors foi mapeado utilizando a estrutura Set da biblioteca java.util da linguagem Java para representar a coleo. A coleo poderia ser representada de outras formas. No entanto, RSA no ofereceu opes de mapeamento. A RSA tem a opo de habilitar ou importar as bibliotecas da linguagem Java. Em uma rea de congurao, como mostrado na Figura 3.46, possvel habilitar a consulta de tipos de classes em bibliotecas referenciadas. Assim, podem-se instanciar objetos dos tipos existentes na biblioteca. A RSA gera o cdigo de um modelo de forma indireta, isto , atravs de uma transformao. Nessa transformao, possvel habilitar ou desabilitar algumas funes. Desse modo, o usurio pode interagir com a ferramenta para inuenciar no cdigo gerado. A Figura 3.47 mostra a transformao criada na RSA para gerar o cdigo referente ao modelo estabelecido no estudo de caso 4. Considerando os critrios estabelecidos neste captulo, RSA teve o seguinte desempenho: C1 - Conabilidade do Cdigo Gerado: Parcialmente consistente (1). O aspecto somente de leitura do atributo staticReadOnlyB e aspecto abstrato do mtodo staticAbstractD no foram mapeados. Alm disso, o atributo size no foi inicializado com os valores especicados no modelo. C2 - Capacidade de Resoluo de Ambiguidades de Modelo: Resolve parcialmente (1). A coleo do atributo colors permite mais de um tipo de mapeamento. A RSA utiliza a estrutura Set, por default, para representar a multiplicidade com limite
72
superior indenido. RSA no interagiu com o usurio. C3 - Consistncia Interna da Ferramenta: Parcialmente Consistente (1). Aps o mapeamento de Java para UML, todos os atributos foram recuperados, assim como seus tipos e suas visibilidades. No entanto, o aspecto somente de leitura do atributo staticReadOnlyB e o aspecto abstrato do mtodo staticAbstractD foram informaes perdidas aps a ida e a volta. C4 - Flexibilidade e Robustez da Ferramenta: Parcialmente Robusta (1). A RSA permite criar classes manualmente e tambm habilitar a utilizao de classes de bibliotecas especcas. Todavia, o par ordenado (100, 100) denido como valor inicial
73
Figura 3.46. rea de congurao que habilita a utilizao de classes de bibliotecas especcas.
Figura 3.47. Transformao criada na RSA para gerar o cdigo do modelo do estudo de caso 4.
para o atributo size no foi mapeado. A Figura 3.48 mostra o modelo elaborado na Enterprise Architect. Os atributos e os mtodos so ordenados a cada insero, por isso a disposio deles no a mesma do modelo do estudo de caso. A ferramenta esconde os nomes dos parmetros, deixando explcitos apenas os tipos, como pode ser visto nos mtodos attacth e setSize, mas no interfere no mapeamento. O cdigo gerado pela EA mostrado na Figura 3.49. O cdigo gerado parcialmente consistente com o modelo. RSA gerou cdigo com erro de sintaxe para o atributo do tipo Area. A instanciao correta para a declarao seria public Area area = new Area(100, 100). Outra falha foi ignorar a multiplicidade do atributo colors, do tipo String. O modelo mostra uma coleo do tipo String e o
74
Figura 3.48. Modelo elaborado na ferramenta EA referente ao estudo de caso 4.
cdigo mostra um atributo simples. No entanto, os outros atributos e mtodos foram mapeados corretamente, assim como a interface WindowInterface e a classe abstrata WindowAbstract. A EA possui tipos pr-denidos e permite tambm importar bibliotecas. A Figura 3.50 mostra a interface que permite ao usurio inserir a biblioteca. A ferramenta no impede que seja declarado atributo ou mtodo de um tipo que no est pr-denido ou no pertence a nenhuma biblioteca. Desta forma, EA permite utilizar tipos no existentes no modelo corrente, levando inconsistncia. A Figura 3.51 mostra a interface exibida pela EA para a gerao de cdigo. So mapeadas apenas a classe Window, a classe abstrata WindowAbstract e a interface WindowInterface. Como EA no impede a declarao de tipos alm dos pr-denidos e das bibliotecas, foram declarados atributos dos tipos Area, Rectangle e XWindow, mas no foi solicitada a criao de elementos de classes, no modelo, referentes a esses
75
tipos. Desta forma, os atributos so de tipos que no existem no contexto do modelo. A Figura 3.52 mostra uma mensagem exibida durante o mapeamento do modelo para o cdigo. Apesar de vericar e exibir a mensagem de erro, gerado o cdigo com erro referente inicializao do atributo size. Em seguida, aps o mapeamento contrrio, do cdigo para modelo, o modelo gerado conforme o modelo inicial, embora seja exibida uma mensagem de erro, referente inicializao do atributo size. Considerando os critrios estabelecidos neste captulo, EA teve o seguinte desempenho: C1 - Conabilidade do Cdigo Gerado: Parcialmente consistente (1). Os atri-
76
Figura 3.50. Interface para importar bibliotecas.
butos, mtodos, parmetros e retornos foram gerados corretamente, respeitando seus tipos e visibilidades. No entanto, houve erro de sintaxe na inicializao do atributo size e a multiplicidade do atributo colors foi ignorada. C2 - Capacidade de Resoluo de Ambiguidades de Modelo: No se aplica (0). A parte do cdigo que permite vericar a capacidade de resolver ambiguidades a coleo do atributo colors, que pode ser representado de vrias maneiras. EA sequer gerou essa coleo. Ela ignorou a multiplicidade, o que diferente de no ser capaz de resolver a ambiguidade. C3 - Consistncia Interna da Ferramenta: Parcialmente consistente (1). Apesar de gerar cdigo com erro de sintaxe, EA conseguiu gerar um modelo similar ao modelo inicial fazendo o mapeamento contrrio. Todos os atributos, mtodos e parmetros, assim como seus tipos e visibilidades, foram recuperados. O atributo size foi representado no modelo da mesma forma que no modelo inicial. Todavia, o atributo colors no foi mapeado como uma coleo de String e sim como um atributo simples. C4 - Flexibilidade e Robustez da Ferramenta: Parcialmente Robusta (1). A EA permite criar classes manualmente e tambm utilizar classes de bibliotecas importadas. Todavia, permite a declarao de tipos no existentes no contexto do modelo; gera
77
Figura 3.51. Interface para importar bibliotecas.
cdigo com erro de sintaxe, como aconteceu com a inicializao do atributo size; e desconsidera a multiplicidade no mapeamento, como aconteceu com o atributo colors.
3.5.5
3.5.5.1
ESTUDO DE CASO 5 - Estrutura Composta

Estrutura Composta I
A Figura 3.53 mostra o modelo elaborado na ferramenta Astah* para o estudo de caso 5 (i). Astah* fornece a opo de criar o diagrama de estrutura composta a partir do diagrama de classe. Aps criar o diagrama de estrutura composta desta forma, a classe Car foi arrastada para dentro do diagrama de estrutura composta. A ferramenta exibiu a mensagem mostrada na Figura 3.54, perguntando ao usurio se Car seria uma classe estruturada ou uma classe. Aps conrmar, o classicador estruturado Car foi criado com apenas a parte rear, do tipo Wheel, como pode ser visto na Figura 3.55, indicando que a instncia de Wheel est contida na classe Car. Em seguida, a parte e, do tipo Engine, e o conector foram inseridos no classicador estruturado Car. Aps criar o diagrama de estrutura composta a partir do diagrama de classe,
78
Figura 3.52. Erro ocorrido na gerao de cdigo.
Figura 3.53. Modelo elaborado na ferramenta Astah* para o estudo de caso 5(i).
Figura 3.54. Mensagem exibida ao usurio solicitando uma escolha.
foram feitos ajustes para que ele casse conforme o diagrama de estrutura composta do estudo de caso. Em virtude disso, o diagrama de classe foi levemente alterado
79
Figura 3.55. Classicador estruturado Car criado a partir do diagrama de classes.
automaticamente pela Astah*. Como o objetivo desse estudo de caso vericar a gerao do cdigo a partir do diagrama de estrutura composta, optou-se por deix-lo coerente com o modelo do estudo de caso, embora as multiplicidades da associao entre a classe Wheel e Engine tenha sido alterada. Astah* no gera o cdigo a partir de um diagrama, mas sim a partir das classes do modelo. Desta forma, uma vez que o diagrama de estrutura composta composto pelo classicador estruturado Car e pelas partes Wheel e Engine, o mapeamento produziu o cdigo das classes Car, Wheel e Engine, como pode ser visto na Figura 3.56. As multiplicidades foram consideradas pela Astah* no mapeamento. No entanto, no foi observada a especicao do limite superior. A estrutura Collection foi utilizada, por default, para representar a coleo. No foi fornecida nenhuma opo de mapeamento para o usurio, embora a multiplicidade pudesse ter sido mapeada utilizando outra estrutura.
Figura 3.56. Cdigo das classes Car, Engine e Wheel.
80
A Figura 3.57 mostra o modelo elaborado na RSA para o estudo de caso 5 (i). O diagrama de estrutura composta, direita, foi criado a partir do diagrama de classe, esquerda. Aps clicar com o boto direito sobre a classe Car, foi selecionada a opo de incluir um diagrama de estrutura composta, como pode ser visto na Figura 3.58.
Figura 3.57. Modelo elaborado na ferramenta RSA para o estudo de caso 5(i).
Figura 3.58. Criao do diagrama de estrutura composta a partir da classe Car.
81
Aps a gerao do diagrama de estrutura composta a partir do diagrama de classe, apenas o conector a: Axle no foi mapeado, tendo sido posteriormente inserido manualmente. Aps inseri-lo, no foi possvel especicar a multiplicidade 2:1 da classe Wheel com a classe Engine no diagrama de estrutura composta por meio do conector a: Axle. Visualmente, isso no compromete o modelo, uma vez que o arranjo com limite superior 2, na parte rear do tipo Wheel, representa duas instncias desse tipo relacionadas com uma instncia do tipo Engine. Aps a engenharia frente, as multiplicidades nas extremidades de associao de Wheel e Engine foram mapeadas sem especicar limite superior, conforme o diagrama de classes. Isso permite vericar que o diagrama de estrutura composta representa uma instncia mais detalhada dos objetos denidos no diagrama de classe. O cdigo gerado a partir das classes do modelo. A Figura 3.59 mostra o cdigo gerado. Pode-se observar que a classe Car reete o que est denido no diagrama de estrutura composta e no diagrama de classes. RSA mapeou a multiplicidade especicada no diagrama de classe, gerando uma coleo utilizando a estrutura Set. Na classe Car, foram gerados um atributo do tipo Engine e um arranjo com duas posies do tipo Wheel. Apesar de mapear multiplicidades para o cdigo com estruturas diferentes, RSA no interagiu com o usurio fornecendo as opes de mapeamento.
82
A Figura 3.60 mostra um diagrama de estrutura composta criado diretamente, sem a utilizao do diagrama de classes. Inicialmente, foi criado o classicador estruturado Car2. Em seguida, inseriu-se uma parte. Foi exibida a mensagem mostrada na Figura 3.61, solicitando ao usurio o que ele deseja fazer. Foi escolhida a opo Criar Classe, criou-se a classe Wheel2 e criou-se a parte rear, do tipo Wheel2. O mesmo foi feito para a parte e, do tipo Engine2. Aps ajustar os outros detalhes, o cdigo gerado foi similar ao cdigo gerado a partir do modelo da Figura 3.57. No foi identicado nenhum tipo de relacionamento entre as classes Wheel2 e Engine2. possvel dizer que, na RSA, os relacionamentos entre as partes de um classicador estruturado s existem se eles existirem no diagrama de classe.
Figura 3.60. Diagrama de estrutura composta criado diretamente.
Figura 3.61. Mensagem exibida ao usurio solicitando o que usurio deseja fazer.
A Figura 3.62 mostra o diagrama de estrutura composta elaborado na ferramenta EA para o estudo de caso 5 (i). Inicialmente, foi criado o classicador estrutura Car e
83
sua respectiva classe no modelo. Em seguida, ao inserir a parte rear, a EA no solicitou a criao de uma classe ou a especicao do tipo de rear. O mesmo aconteceu com a parte e. Isso gerou inconsistncia no modelo, uma vez que as partes rear e e deveriam se referir a classes no diagrama de classe. Desta forma, aps a engenharia frente, no foram mapeadas. O mapeamento do diagrama de estrutura composta para o modelo produziu apenas a classe Car, sem corpo, como pode ser visto na Figura 3.63.
EA no gerou automaticamente as classes nem solicitou a criao das mesmas, permitindo a inconsistncia no modelo. Para contornar o problema, as classes foram inseridas no modelo manualmente. A Figura 3.64 mostra o cdigo gerado pela EA a partir do novo modelo. Foram geradas as trs classes. A classe Car contm o atributo rear do tipo Wheel pelo fato de a linha contnua da parte rear indicar que a parte est contida na instncia de Car. As multiplicidades no foram observadas. O classicador estruturado Car possui as duas partes na sua estrutura interna, mas seu respectivo cdigo faz referncia apenas parte Wheel. A parte e, do tipo Engine, se relaciona com dois objetos da parte rear, do tipo Wheel, mas como a navegabilidade no especicada, apenas a classe Wheel tem um atributo para se referir classe Engine.
84
A engenharia reversa produziu um modelo com classes com as caractersticas do cdigo. Algumas informaes foram perdidas. Aps recuperar o modelo com as classes, o diagrama de estrutura criado, a partir das classes do modelo, no continha a multiplicidade e o conector especicados no modelo inicial.
Figura 3.64. Cdigo gerado pela EA a partir do modelo da Figura 3.62 aps ajuste.
3.5.5.2
Estrutura Composta II
A Figura 3.65 mostra o diagrama de estrutura composta elaborado na ferramenta Astah* para o estudo de caso 5 (ii). A Figura 3.66 mostra o cdigo gerado para as classes Car e Wheel. Como foi mencionado no estudo de caso anterior, a ferramenta Astah* no gera um cdigo a partir de um diagrama, mas sim a partir das classes do modelo. A classe Car foi gerada sem nenhum atributo. As partes declaradas no classicador estruturado mostradas no modelo no foram declaradas no cdigo da classe Car. Uma vez que as partes fazem parte da estrutura interna do classicador estrutura, e so contornadas por linha contnua, a classe Car deveria fazer referncia s partes. A classe Wheel foi gerada corretamente, com os dois atributos do tipo String. Isso permite deduzir que se o diagrama de estrutura composta for usado para complementar o diagrama de classe, o mapeamento do modelo para o cdigo mais convel. Isto , no recomendado gerar o cdigo a partir de um diagrama de estrutura composta diretamente na Astah*, pois algumas estruturas no so consideradas no mapeamento. A Figura 3.67 mostra o modelo elaborado na ferramenta RSA referente ao estudo de caso 5 (ii). A classe Wheel foi criada com os atributos tire e size do tipo String, conforme especicado no estudo de caso. A Figura 3.68 mostra o cdigo gerado. Foram gerados quatro atributos do tipo Wheel na classe Car. A classe Wheel foi gerada com os dois atributos do tipo String. O cdigo reete o no modelo. A Figura 3.69 mostra a interao que a RSA faz com o usurio durante o processo de insero de uma parte no classicador estruturado Car. perguntado ao usurio se
85
Figura 3.65. Modelo elaborado na ferramenta Astah* referente ao estudo de caso 5(ii).
Figura 3.66. Cdigo gerado pela Astah* a partir do modelo da Figura 3.65.
Figura 3.67. Modelo elaborado na ferramenta RSA referente ao estudo de caso 5(ii).
ele deseja criar uma classe ou selecionar um elemento existente, por exemplo. A Figura 3.70 mostra a interao que RSA faz com o usurio para mostrar as alteraes que esto sendo feitas do cdigo para modelo. Nesse caso, no h nenhuma alterao, o modelo e o cdigo esto consistentes. Como foi mencionado anteriormente, RSA no gera cdigo a partir de um diagrama, mas sim a partir do modelo de classes. O modelo construdo durante a criao dos diagramas.
86
Figura 3.69. Interao do usurio com a ferramenta para a insero de uma parte num classicador estruturado.
A Figura 3.71 mostra o diagrama de estrutura composta elaborado na ferramenta EA para o estudo de caso 5 (ii). A Figura 3.72 mostra o cdigo gerado a partir do modelo da Figura 3.71. Pode-se observar na classe Car que os elementos que fazem parte da estrutura interna do classicador estruturado Car no foram mapeados. Consequentemente, a engenharia reversa no conseguiu recuperar tais informaes ao fazer o mapeamento contrrio. Considerando os critrios estabelecidos neste captulo, Astah* teve o seguinte desempenho: C1 Conabilidade do Cdigo Gerado: Parcialmente consistente (1). No primeiro
87
Figura 3.70. Interface utilizada pela RSA para mostrar ao usurio a transformao de modelo.
modelo, o limite superior da multiplicidade no observado. Um relacionamento de 1:2 e 1:N mapeado da mesma forma. No segundo modelo As classes foram criadas. No
88
entanto, o cdigo da classe Car foi gerado sem nenhum atributo. As partes inseridas no classicador estruturado Car, instncias relacionadas com instncia de Car, no foram mapeadas para o cdigo. C2 Capacidade de Resoluo de Ambiguidades do Modelo: Resolve parcialmente (1). A multiplicidade observada no primeiro modelo permite mais de um tipo de mapeamento. Astah* utilizou a estrutura Collection para representar a multiplicidade, mas no forneceu nenhuma opo de mapeamento para o usurio. C3 Consistncia Interna da Ferramenta: Parcialmente consistente (1). No primeiro modelo, as multiplicidades e os nomes das extremidades de associao no foram recuperados, apesar das classes e das associaes terem sido recuperadas. No segundo modelo, a engenharia reversa gerou o modelo com as classes Car e Wheel. A classe Wheel foi recuperada corretamente. No entanto, o classicador estruturado Car no teve as partes recuperadas, uma vez que no haviam sido mapeadas pela engenharia de ida. C4 Flexibilidade e Robustez da Ferramenta: Parcialmente robusta (1). A Astah* permite inserir uma parte no classicador estruturado, mas caso o diagrama de estrutura composta no esteja associado a um diagrama de classes, algumas estruturas no so consideradas no mapeamento. Considerando os critrios estabelecidos neste captulo, RSA teve o seguinte desempenho: C1 Conabilidade do Cdigo Gerado: Consistente (2). Em relao ao primeiro e ao segundo modelo, o cdigo gerado consistente. As multiplicidades foram mapeadas corretamente, assim como os nomes das extremidades de associao. Algumas informaes, como os nomes dos conectores - frontaxle e rearaxle -, no foram mapeadas, mas se tratam de informaes conceituais. C2 Capacidade de Resoluo de Ambiguidades do Modelo: Resolve parcialmente (1). A multiplicidade observada no primeiro modelo permite mais de um tipo
89
de mapeamento. RSA utilizou a estrutura arranjos e a estrutura Set para representar a multiplicidade, mas no forneceu nenhuma opo de mapeamento para o usurio. C3 Consistncia Interna da Ferramenta: Consistente (2). A engenharia reversa foi capaz de recuperar os elementos presentes no modelo inicial, uma vez que o mapeamento do modelo para o cdigo considerou tais elementos. Os nomes dos conectores frontaxle e rearaxle no foram considerados; no entanto, so informaes conceituais, assim como o relacionamento de composio. C4 Flexibilidade e Robustez da Ferramenta: Robusta (2). O diagrama de estrutura composta gerado de forma consistente a partir do diagrama de classe. RSA faz engenharia frente e engenharia reversa por meio de transformaes de modelo. O que mapeado, na verdade, so as classes do modelo e no os diagramas propriamente ditos. Ao fazer uma transformao, RSA permite vericar e selecionar as alteraes que estaro ocorrendo. Considerando os critrios estabelecidos neste captulo, EA teve o seguinte desempenho: C1 Conabilidade do Cdigo Gerado: Parcialmente consistente (1). As classes correspondentes ao classicador estruturado e s partes foram criadas. No entanto, o cdigo da classe Car foi gerado sem nenhum atributo. No primeiro modelo, a multiplicidade foi ignorada. No segundo modelo, as partes inseridas no classicador estruturado Car, instncias relacionadas com a instncia Car, no foram mapeadas para o cdigo. C2 Capacidade de Resoluo de Ambiguidades do Modelo: No se aplica (0). A multiplicidade entre as partes rear e e foi mapeada para o cdigo. Desta forma, no foi possvel vericar a capacidade de EA resolver ambiguidades. C3 Consistncia Interna da Ferramenta: Parcialmente consistente (1). No primeiro modelo, as classes foram recuperadas, mas como foi perdida informao aps engenharia frente, o modelo recuperado no correspondeu totalmente ao modelo inicial. No segundo modelo, a engenharia reversa gerou o modelo com as classes Car e Wheel. A classe Wheel foi recuperada corretamente. No entanto, o classicador estruturado Car no teve as partes recuperadas, uma vez que no haviam sido mapeadas durante a engenharia frente. C4 Flexibilidade e Robustez da Ferramenta: Parcialmente robusta (1). A EA permite inserir uma parte no classicador estruturado, mas no a considera no mapeamento. A EA permitiu a inconsistncia entre o diagrama de estrutura composta e o modelo. Foi possvel criar partes no diagrama de estrutura composta sem que se denissem seus tipos.
90
3.5.6
3.5.6.1
ESTUDO DE CASO 6 - Fragmento Combinado

Fragmento Combinado I
A Figura 3.73 mostra o diagrama de sequncia elaborado na ferramenta Astah* para o estudo de caso 6 (i). A Figura 3.74 mostra o cdigo gerado a partir do modelo da Figura 3.73. O fragmento combinado alt foi inserido sem nenhum tipo de restrio, isto , com qualquer disposio, mesmo que causasse ambiguidade. Foram geradas apenas as classes com seus corpos vazios. Os mensagens listadas no diagrama de sequncia foram ignorados pela ferramenta. Da mesma forma, o fragmento combinado alt, que representa uma estrutura condicional, foi ignorado. Isso refora a ideia de que a Astah* gera o cdigo a partir do que est denido nas classes do modelo e no de um diagrama. Uma chamada de mtodo no diagrama de sequncia implementada na linguagem Java como um mtodo ou operao. A chamada assncrona da classe B para a classe A, no modelo, deveria ter sido mapeada na classe A como um mtodo, no cdigo. A classe B chamou um mtodo da classe A. No entanto, nem as chamadas de mtodos nem o fragmento combinado alt foram mapeados para o cdigo. A continuao (continuation) tambm no foi mapeada. A Figura 3.75 mostra o diagrama de sequncia elaborado na RSA referente ao estudo de caso 6 (i). A Figura 3.76 e a Figura 3.77 mostram a forma como a ferramenta RSA permite a insero de um fragmento combinado no diagrama de sequncia. Escolhe-se o fragmento combinado e, no diagrama de sequncia, mostra-se a rea que ele ir cobrir. Aps delimitar a rea que ser encoberta pelo fragmento combinado, exibida uma tela perguntando ao usurio quais linhas de vida estaro encobertas, de fato, pelo fragmento combinado. A Figura 3.78 mostra o cdigo gerado pela RSA a partir do modelo da Figura 3.75. O fragmento combinado e as continuaes (continuations) no foram mapeadas. A Figura 3.79 mostra o diagrama de sequncia elaborado na ferramenta EA para o estudo de caso 6 (i). A verso de teste utilizada no trabalho no disponibiliza a opo de engenharia frente quando se est trabalhando com diagramas de sequncia. Dessa forma, no foi possvel analisar o mapeamento feito pela ferramenta EA para este estudo de caso.
3.5.6.2
Fragmento Combinado II
A Figura 3.80 mostra o diagrama de sequncia elaborado na Astah* referente ao estudo de caso 6 (ii). O cdigo gerado pela Astah* a partir do modelo da Figura 3.80 pode
91
Figura 3.73. Modelo elaborado na ferramenta Astah* referente ao estudo de caso 6(i).
ser visto na Figura 3.81. Da mesma forma que no estudo de caso anterior, Astah* gerou apenas as classes vazias. As chamadas de mtodos e o fragmento combinado loop foram ignorados. O cdigo foi criado sem nenhum tipo de referncia a esses dois tipos de elementos. Um dos objetivos desse estudo de caso vericar a capacidade de resoluo de
92
Figura 3.75. Modelo elaborado na ferramenta RSA referente ao estudo de caso 6(i).
ambiguidade da ferramenta. O fragmento combinado loop foi a estrutura analisada. Entretanto, se nem as chamadas das linhas de vida foram mapeados para o cdigo, quanto mais o fragmento combinado. A Figura 3.82 mostra um diagrama de sequncia no momento em que est sendo denida a rea de cobertura de um fragmento combinado. Como se pode observar, a rea encobre a linha de vida A e a linha de vida B, com a chamada m2 completamente no seu interior e a chamada m1 parcialmente. A disposio deste fragmento combinado gera ambiguidade. Apenas a mensagem m2 seria inuenciada, uma vez que o fragmento combinado a encobre totalmente, ou a mensagem m1 tambm seria inuenciada, uma vez que a operao faz parte da linha de vida B? Para evitar ambiguidade, RSA exibe uma tela perguntando ao usurio quais linhas de vida estaro encobertas, de fato, pelo fragmento combinado, como pode ser visto na Figura 3.83. Dessa forma, pode-se deduzir que RSA considera a cobertura das mensagens e no das operaes existentes nas linhas de vida.
93
Figura 3.76. Fragmento combinado inserido no diagrama de sequncia na ferramenta RSA.
Figura 3.77. Interface utilizada pela RSA permitindo ao usurio denir a rea de cobertura do fragmento combinado.
94
Figura 3.80. Modelo elaborado na ferramenta Astah* referente ao estudo de caso 6 (ii).
95
Figura 3.82. Modelo elaborado na ferramenta RSA referente ao estudo de caso 6 (ii).
Figura 3.83. Interface utilizada pela RSA permitindo ao usurio denir a rea de cobertura do fragmento combinado.
96
Porm, ocorre algo inesperado. O fragmento combinado inserido no diagrama de sequncia, mas as mensagens m1 e m2 so levadas para baixo, conforme Figura 3.84.
Figura 3.84. Diagrama de sequncia aps a insero do fragmento combinado loop.
Em seguida, para tentar ajustar o diagrama de sequncia conforme o modelo do estudo de caso, tentou-se inserir uma chamada assncrona da classe B para a classe, como havia sido feito anteriormente. Uma tela foi exibida perguntando se era desejado criar um novo mtodo ou utilizar um mtodo existente, dentre eles o m2, como pode ser visto na Figura 3.85. Aps os ajustes, tentando adequar o diagrama de sequncia ao modelo do estudo de caso, chegou-se na estrutura mostrada na Figura 3.86. Para que as duas chamadas fossem inuenciadas pelo fragmento combinado loop, a rea de cobertura teve que abranger completamente as chamadas. Ao contrrio do que se tinha deduzido antes, para denir a rea de cobertura e evitar ambiguidades, RSA no considera as operaes das linhas de vida, mas sim as mensagens. A Figura 3.87 mostra o cdigo gerado a partir do diagrama de sequncia da
97
Figura 3.85. Insero de uma chamada assncrona dentro do fragmento combinado loop.
Figura 3.86. Apenas as mensagens foram mapeadas. O fragmento combinado e as continuaes no foram mapeadas. A Figura 3.88 mostra o diagrama de sequncia elaborado na ferramenta EA para o estudo de caso 6(ii). A verso de teste utilizada no trabalho no disponibiliza a opo de engenharia frente quando se est trabalhando com diagramas de sequncia. Dessa forma, no foi possvel analisar o mapeamento feito pela ferramenta EA para este estudo de caso. Considerando os critrios estabelecidos neste captulo, Astah* teve o seguinte desempenho: C1 Conabilidade do Cdigo Gerado: Parcialmente consistente (1). As classes do diagrama de sequncia foram criadas corretamente, mas os detalhes do diagrama de sequncia foram todos ignorados, as chamadas de mtodo e os fragmentos combinados. C2 Capacidade de Resoluo de Ambiguidades do Modelo: No resolve (0). A ambiguidade que pode ser considerada nesse estudo de caso a disposio do fragmento combinado. Astah* permite qualquer disposio do fragmento, inclusive a que causa
98
Figura 3.86. Diagrama de sequncia nal, aps ajustes.
Figura 3.87. Cdigo gerado a patir do diagrama de sequncia da Figura 3.86 pela RSA.
ambiguidade. C3 Consistncia Interna da Ferramenta: Parcialmente consistente (1). Nenhum os elementos do diagrama de sequncia foram mapeados, com exceo das linhas de vida, que geraram as classes. Nem as chamadas de mtodos foram mapeados. A
99
engenharia reversa recuperou apenas as linhas de vida. C4 Flexibilidade e Robustez da Ferramenta: Parcialmente robusta (1). A EA permitiu inserir os elementos no diagrama de sequncia, mas eles no foram utilizadas no mapeamento do modelo para o cdigo. Considerando os critrios estabelecidos neste captulo, RSA teve o seguinte desempenho: C1 Conabilidade do Cdigo Gerado: Parcialmente consistente (1). O cdigo corresponde ao modelo. As classes foram criadas e seus mtodos tambm. Mas os fragmentos combinados no foram mapeados. C2 Capacidade de Resoluo de Ambiguidades do Modelo: Resolve (2). A tela exibida ao usurio solicitando a seleo das linhas de vida que sero encobertas pelo fragmento combinado evita que haja ambiguidade no modelo. Apenas as disposies coerentes so permitidas pela RSA. C3 Consistncia Interna da Ferramenta: Parcialmente consistente (1). Os fragmentos combinados no foram mapeados para o cdigo. Consequentemente, no foram recuperaddos para o modelo. Desta forma, o modelo produzido pela engenharia reversa no possui as mesmas caractersticas do modelo inicial. C4 Flexibilidade e Robustez da Ferramenta: Parcialmente robusta (1). A RSA permitiu inserir os elementos no modelo. Atravs de mensagens e caixas de dilogo ao usurio, garantiu o modelo consistente. No entanto, no mapeou o fragmento combinado para o cdigo.
100
Considerando os critrios estabelecidos neste captulo, a RSA teve o seguinte desempenho: C1 Conabilidade do Cdigo Gerado: No se aplica (0). C2 Capacidade de Resoluo de Ambiguidades do Modelo: No se aplica (0). C3 Consistncia Interna da Ferramenta: No se aplica (0). C4 Flexibilidade e Robustez da Ferramenta: No se aplica (0). A Tabela 3.3 mostra os resultados obtidos aps a aplicao dos estudos de caso. Apesar de nortear e sistematizar a avaliao, os critrios estabelecidos e a atribuio de valores devem ser interpretados com cuidado. O objetivo foi analisar alguns poucos aspectos; foi vericado, em relao aos aspectos analisados, se a ferramenta atende, atende parcialmente ou no atende; no foi vericado o quo bem a ferramenta atende. Considerando os aspectos analisados, a ferramenta RSA nos deu a impresso de ser melhor atualizada. Existe sincronizao entre os diagramas. Por exemplo, a insero de uma chamada de mtodo em um diagrama de sequncia implica na insero de um mtodo na respectiva classe do modelo; a insero de um relacionamento de composio em um diagrama de classe implica na insero de uma parte com linha contnua no diagrama de estrutura composta. As trs ferramentas oferecem a opo de sincronizao entre modelo e cdigo. Neste caso, apenas as alteraes so atualizadas para o cdigo ou para o modelo. Se o modelo possui mais informaes que o cdigo - como o relacionamento de composio e as sentenas de propriedade -, a sincronizao aps alteraes no cdigo mantm as informaes exclusivas do modelo. Desta forma, uma vez que o modelo tenha sido criado, a sincronizao de modelo e cdigo a cada iterao possibilita contornar problemas como a perda de informao conceitual ao longo do desenvolvimento. De forma geral, as trs ferramentas interagem pouco com o usurio. A maioria das interaes so mensagens informativas de erro ou de sucesso aps uma operao. Quando o mapeamento no um para um, isto , um elemento do modelo pode ser mapeado de mais de uma forma para o cdigo, nenhuma ferramenta oferece alternativas de mapeamento. Mas existem situaes com interao. A RSA evitou situaes de ambiguidade, por exemplo, quando interagiu com o usurio para inserir corretamente o fragmento combinado no diagrama de sequncia, conforme discutido na seo 3.5.6.2. As estruturas bsicas do diagrama de classe, como classes, atributos, mtodos e relacionamentos, foram mapeadas corretamente em todas as ferramentas. No entanto, elementos como multiplicidade e navegabilidade tiveram mapeamentos divergentes. EA generalizou todas as multiplicidades como 1; Astah* considerou as diferentes multiplicidades, mas no observou os limites superiores denidos; RSA observou os limites denidos.
101
Tabela 3.3. Tabela sumrio, contendo as ferramentas, critrios e valores atribudos

ESTUDO DE CASO 1 CRITRIOS C1 C2 C3 C4 CRITRIOS C1 C2 C3 C4 CRITRIOS C1 C2 C3 C4 ASTAH 1 0 1 1 ASTAH 1 1 1 1 ASTAH 2 0 2 2 RSA 1 0 1 1 RSA 2 1 1 1 RSA 2 0 2 2 EA 1 0 1 1 EA 1 0 1 1 EA 2 0 2 2 ESTUDO DE CASO 4 CRITRIOS C1 C2 C3 C4 CRITRIOS C1 C2 C3 C4 CRITRIOS C1 C2 C3 C4 ASTAH 1 1 0 1 ASTAH 1 1 2 1 ASTAH 1 0 1 1 RSA 1 1 1 1 RSA 2 1 2 2 RSA 1 2 1 1 EA 1 0 1 1 EA 1 0 1 1 EA 0 0 0 0
ESTUDO DE CASO 2
ESTUDO DE CASO 5
ESTUDO DE CASO 3
ESTUDO DE CASO 6
Captulo 4 Aspectos Prtico-Operacionais

Este captulo apresenta alguns aspectos prtico e operacionais. O processo de seleo das ferramentas detalhado na seo 4.1. Alm disso, so relatadas, na seo 4.2, as diculdades encontradas e as solues adotadas com relao: i) ao download e instalao das ferramentas; ii) s dvidas quanto elaborao dos modelos nas ferramentas, como, por exemplo, a insero de um relacionamento de associao ternria entre classes; iii) questes sobre recursos e solues das ferramentas, como, por exemplo, a possibilidade de se importar bibliotecas para instanciar no modelo o maior nmero de tipos de uma linguagem de programao especca; entre outros.
4.1
Aplicao dos Critrios de Seleo das Ferramentas
Aps aplicar o critrio C1 e o critrio C2 encontraram-se as ferramentas apresentadas na Tabela 4.1. Em seguida, aplicou-se os critrios C3, C4 e C5, disponibilidade de cpia pela internet, tipo de licena e ferramenta em desenvolvimento e suporte UML 2, respectivamente, obtendo-se o seguinte resultado, apresentado na Tabela 4.2: A ferramenta Rational TAU no possui verso gratuita ou licena para teste, alm de a ltima verso ter sido lanada em fevereiro de 2009; As informaes encontradas sobre as ferramentas ArgoUML, BOUML, FUJABA, StarUML, Rational TAU, Together e Umbrello permitem armar que elas no esto em desenvolvimento; 103
104
Captulo 4. Aspectos Prtico-Operacionais
Tabela 4.1. Ferramentas que suportam UML e Java encontradas no Google e no Bing.
ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
FERRAMENTA ArgoUML Artisan Studio Astah* BOUML Eclipse (plugin MyEclipse) EclipseUML Enterprise Architect FUJABA MagicDraw UML MicroGOLD with Class NetBeans Poseidon UML Power Designer Rational Software Architect - RSA Rational Rhasody Rational TAU StarUML Together Umbrello Umodel Visual Paradigm
No foram encontradas verses das ferramentas ArgoUML, Artisan Studio, FUJABA, MicroGOLD with Class, NetBeans e PowerDesigner que suportassem a UML 2; Considerando que a ferramenta TAU G2 no possui licena para teste, decidiuse, ento, descart-la por no ser possvel test-la. As ferramentas ArgoUML, Artisan Studio, BOUML, FUJABA, MicroGOLD with Class, NetBeans, PowerDesigner, StarUML, TAU G2, Together e Umbrello no esto mais em desenvolvimento e/ou no possuem verses que suportam a UML2. Desta forma, decidiu-se descart-las. Aps estas consideraes, as ferramentas elencadas at o critrio C5 so listadas na Tabela 4.3: A partir da Tabela 4.3, aplicou-se o critrio C6, que consiste em vericar se h frum de discusso ativo e a popularidade da ferramenta. Aps a busca de informaes nos fruns das ferramentas buscando preencher a Tabela 4.4, algumas informaes no foram encontradas. Foram enviadas mensagens para o suporte das ferramentas listadas na Tabela 4.3 para levantar informao. Alguns suportes no responderam, outros ar-
4.1. Aplicao dos Critrios de Seleo das Ferramentas
105
Tabela 4.2. Disponibilidade das ferramentas CASE para download e suas licenas.
ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 FERRAMENTA ArgoUML Artisan Studio Astah* BOUML Eclipse (MyEclipse) EclipseUML Enterprise Architect FUJABA MagicDraw UML MicroGOLD with Class NetBeans Poseidon UML Power Designer RSA Rational Rhapsody Rational TAU StarUML Together Umbrello Umodel Visual Paradigm DOWNLOAD SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM TIPO DE LICENA Gratuita 30 dias 20 dias + 30 dias Gratuita 30 dias 30 dias 30 dias Gratuita Demo 30 dias Gratuita 30 dias 30 dias 30 dias 30 dias Paga Gratuita 30 dias 30 dias 10 dias + 20 dias EM DESEVOLVIMENTO NO SIM SIM NO SIM SIM SIM NO SIM SIM SIM SIM SIM SIM SIM NO NO NO NO SIM SIM UML 2 NO NO SIM SIM SIM SIM SIM NO SIM NO NO SIM NO SIM SIM SIM SIM SIM SIM SIM SIM
Tabela 4.3. Ferramentas aps a aplicao do critrio C3, C4 e C5.
ID 1 2 3 4 5 6 7 8 9 10
FERRAMENTA Astah* Eclipse (plugin MyEclipse) EclipseUML Enterprise Architect MagicDraw UML Poseidon UML Rational Rhapsody Rational Software Architect RSA Umodel Visual Paradigm
maram no ter informao alm das discusses no frum, outros armaram no poder revelar informao a quem no fosse cliente da empresa. As informaes encontradas ao m de todas as pesquisas e consultas, realizadas no perodo de janeiro a fevereiro de 2011, so apresentadas na Tabela 4.4. A Tabela 4.5 apresenta informaes, no campo OBSERVAES, que especicam as respostas das mensagens enviadas para o suporte e/ou frum das ferramentas. A Tabela 4.6 mostra a conceituao das ferramentas no frum da UML [UML, 2011] segundo alguns aspectos, a saber: usabilidade, desenho, simulao (executabilidade) e conformidade com as especicaes. Todas as ferramentas listadas e avaliadas no frum da UML esto presentes nesta pesquisa. Porm, nem
106
todas as ferramentas desta pesquisa esto presentes no frum da UML.

Tabela 4.4. Aplicao do critrio C6: Informaes sobre o frum.
ID 1 2 3 4 5 6 7 8 9 10
FERRAMENTAS Astah* Eclipse (myEclipse) EclipseUML Enterprise Architect MagicDraw Poseidon UML Rhapsody RSA UModel Visual Paradigm
MENSAGENS 789 21.205 571 75.672 1.152 6.830 1.968 18.338 8.814 8.854
MEMBROS 451.082 No encontrado 2.044 19.241 324 1.674 No encontrado No encontrado 11.615 No encontrado
VISUALIZAES 21.771 No encontrado No encontrado No encontrado No encontrado No encontrado 70.512 124.783 No encontrado No encontrado
Tabela 4.5. CASE.

ID 1 2 3 4 5 6 7 8 9 10
Resposta aos e-mails enviados para o suporte das ferramentas

OBSERVAES Respondeu. Explicao da discrepncia de informaes do frum. No respondeu. Respondeu. No revela informaes alm do que est no frum. Respondeu. Nenhuma informao alm das constantes no frum. Respondeu. Nenhuma informao alm das constantes no frum. No respondeu. No respondeu. Respondeu. Nenhuma informao alm das constantes no frum. No respondeu. Respondeu. No pode revelar informaes a quem no cliente.
FERRAMENTAS Astah* Eclipse (myEclipse) EclipseUML Enterprise Architect MagicDraw Poseidon UML Rhapsody RSA UModel Visual Paradigm
Tabela 4.6. Conceituao das ferramentas no frum da UML [UML, 2011]

ID 1 2 3 4 5 6 7 8 9 10 FERRAMENTAS Astah* Eclipse (myEclipse) EclipseUML Enterprise Architect MagicDraw Poseidon UML Rhapsody RSA UModel Visual Paradigm Usabilidade 3 3 3 2 3 3 3 Desenho 4 4 3 3 3 4 3 Simulao/ Executabilidade 1 2 1 3 2 1 1 Conformidade com as especicaes 3 4 1 4 4 2 4 TOTAL 11 13 8 12 12 10 11
Considerando o nmero de membros, observa-se que a Astah* a mais popular, seguida pela Enterprise Architect e Umodel, respectivamente. Observando-se apenas o nmero de mensagens, a Enterprise Architect a mais popular; a Astah* no parece
4.1. Aplicao dos Critrios de Seleo das Ferramentas
107
ser to expressiva, em vista da discrepncia entre o nmero de mensagens e o nmero de membros. Uma mensagem foi enviada ao suporte da ferramenta Astah* para se obter uma explicao para o baixo nmero de mensagens no frum da Astah*, se comparado com o nmero de membros. Foi retornado que cerca de 38% dos membros so residentes no Japo e eles utilizam outro frum em japons. Alm disso, muitos dos membros no possuem o ingls como sua primeira lngua. Eles tambm oferecem suporte tcnico por correio eletrnico para os clientes que possuem licenas vlidas, uma vez que a maioria deles entra em contato diretamente via correio em vez de utilizar frum. Essas so algumas razes que eles assumem para justicar o baixo nmero de mensagens no frum. importante ressaltar que o nmero de mensagens informado no frum das ferramentas est relacionado a toda funcionalidade da ferramenta. Isto , so consideradas todas as mensagens que dizem respeito a qualquer tipo de recurso que a ferramenta oferece, seja relacionada UML ou no. Se a ferramenta suporta o desenvolvimento Java, sem envolver UML, e o frum aborda questes simplesmente de Java, as mensagens relacionadas a esta questo so consideradas. Desta forma, o nmero de mensagens por si s no suciente para dizer se a ferramenta mais ou menos popular no que diz respeito engenharia de ida e volta. O nmero de mensagens pode dizer o quanto uma ferramenta discutida pelos usurios. O nmero de mensagens, o nmero de membros e o nmero de visualizaes so parmetros que ajudam inferir o quanto a ferramenta aceita ou o quanto as pessoas se interessam pela ferramenta. Eles foram utilizados para se escolher as trs ferramentas consideradas mais adequadas para tornar o trabalho mais representativo. O nmero de mensagens a informao que est disponvel nos fruns de todas as ferramentas. A ferramenta Enterprise Architect possui o nmero de mensagens muito superior ao das outras ferramentas. A ferramenta Enterprise Architect tambm possui um nmero relativamente alto de membros se comparado ao das outras ferramentas. Por esses motivos, ela foi selecionada. Alm dela, Astah* tambm foi selecionada pelo altssimo nmero de membros. A terceira ferramenta selecionada foi a RSA. A RSA uma ferramenta robusta muito utilizada no mercado e nos trabalhos cientcos. O conceito atribudo s ferramentas no frum da UML, como pode ser visto na Tabela 4.6, mostra a Magic Draw com pequena vantagem em relao s outras ferramentas. Nossa inteno era utilizar neste trabalho a ferramenta mais bem conceituada no frum da UML. No entanto, a verso da ferramenta Magic Draw disponvel para teste no realiza engenharia frente ou reversa, o que compromete sua avaliao neste trabalho. A Tabela 4.7 mostra as trs ferramentas selecionadas que foram avaliadas.
108
Desejava-se avaliar tambm ferramentas gratuitas. Todavia, os recursos oferecidos por estas estavam bem aqum do que era esperado das ferramentas.
Tabela 4.7. Ferramentas Selecionadas
ID 1 2 3
FERRAMENTA Astah* Enterprise Architect Rational Software Architect RSA
4.2
Cpia, Instalao e Utilizao das Ferramentas
A ferramenta RSA e Enterprise Architect possuem licena de teste para apenas 30 dias, enquanto que a Astah* possui licena para 40 dias, extensvel por mais 50 dias. Considerando o tempo para aprender a usar a ferramenta e o amadurecimento e renamento deste trabalho, 30 dias no foram sucientes para avaliar as ferramentas. Foi necessrio instal-las em outras duas mquinas, em momentos diferentes, para completar a avaliao. As verses das trs ferramentas utilizadas neste trabalho foram: i) Astah* - verso 6.3, Professional, liberada em novembro de 2010; ii) Enterprise Architect - verso 8.0, Professional, liberada em outubro de 2010; e iii) Rational Software Architect - verso 8.0, liberada em agosto de 2010. Algumas diculdades no momento da elaborao dos modelos dos estudos de caso, em cada ferramenta, foram: i) a disposio diferente, em cada ferramenta, dos elementos da UML e dos recursos da ferramenta; ii) os diferentes procedimentos para realizar a engenharia de ida e volta. A insero de elementos bsicos no modelo, como classes, atributos e associaes, simples e pode ser feita de maneira similar em cada ferramenta. Existe uma barra, ao lado ou acima do diagrama, com elementos da UML. No entanto, para inserir outros elementos como, por exemplo, sentena de propriedades, em cada ferramenta se faz de uma forma diferente. Enquanto que, para realizar o mapeamento de UML para Java na RSA, necessrio criar uma transformao de UML para Java (Transformation UML to Java) e denir alguns parmetros, na Astah* e na Enterprise Architect bastava selecionar os modelos e clicar em um boto ou em um item de menu gerar cdigo. Apesar de no ser necessrio criar uma transformao nestas ferramentas, possvel denir alguns parmetros como, por exemplo, a estrutura Java para qual ser mapeada uma coleo.
4.2. Cpia, Instalao e Utilizao das Ferramentas
109
Vericou-se que a associao n-ria no suportada pelas ferramentas. RSA e Astah* no possuem o elemento associao ternria dentre os elementos da UML. Aps contato com o suporte destas ferramentas, Astah* armou que futuramente pretende adicionar esse elemento ferramenta. Enterprise Architect, apesar de permitir a representao de associaes, no as mapeia para o cdigo; no modelo, trs classes so visualmente conectadas, mas aps o mapeamento nenhuma estrutura no cdigo considera a associao ternria. A utilizao de bibliotecas de uma linguagem especca para instanciar elementos no modelo UML possvel nas trs ferramentas neste trabalho, importamos bibliotecas da linguagem Java. Aps no identicarmos como realizar essa importao na ferramenta Astah*, enviamos mensagem ao suporte e, aps seguir as orientaes recebidas, conseguimos realizar a operao com sucesso. As dvidas de utilizao foram resolvidas atravs de consultas aos fruns e aos materiais disponibilizados nos stios das ferramentas. Alm disso, uma srie de mensagens foi enviada aos suportes das ferramentas para responder questes especcas relacionadas: i) licena; ii) a recursos da ferramenta; iii) a como se realizar determinada operao; iv) tipo de perl da UML utilizado pela ferramenta; entre outros.
Captulo 5 Concluso
5.1 Consideraes Finais
Neste trabalho foi estudada a questo da engenharia de ida e volta entre a linguagem UML e a linguagem Java. Inicialmente, a inteno era realizar um trabalho similar ao de Kollmann e outros [Kollman et al., 2002] e vericar a capacidade das ferramentas CASE atuais realizarem a engenharia de ida e volta, considerando o diagrama de classes e a linguagem Java, utilizando um sistema real. Como a UML 2 possui outros elementos importantes que no foram analisados naquele trabalho, foram adicionados alguns deles na anlise deste trabalho. Aquele trabalho avaliou a transcrio do cdigo para o modelo. Este trabalho avaliou a transcrio em ambos os sentidos e tambm questes tcnicas de mapeamento do modelo para o cdigo e do cdigo para o modelo. Pela complexidade da anlise, o trabalho se limitou a avaliar apenas trs ferramentas. Alm disso, este trabalho no objetivou exaurir todas as possibilidades de mapeamento entre as duas linguagens, mas apresentar alguns casos considerados relevantes. Alguns trabalhos sobre interao entre ferramenta e usurio (desenvolvedor) relacionados engenharia de ida e volta, isto , ao mapeamento modelo=>cdigo e cdigo=>modelo, focaram em aspectos de implementao [Akehurst et al., 2007] [Gessenharter, 2008] [Gessenharter, 2009] [Diskin et al., 2008]. Por outro lado, outros trabalhos focaram na usabilidade da ferramenta de forma geral, cuidando da questo de IHC - Interao Humano-Computador [de Souza, 2005] [de Souza et al., 2010]. No entanto, no conhecemos trabalhos que tratam de questes tcnicas de opes de mapeamento entre UML e Java. Alm de analisar a transcrio de UML para Java e vice-versa, este trabalho se preocupou em avaliar se existem ou no opes de mapeamento. Cabe ressaltar que dimenses como qualidade da interao, comunicabilidade, 111
112
Captulo 5. Concluso
apreensibilidade so importantes, mas no zeram parte do escopo do trabalho para efeito de simplicao. Vericamos a engenharia de ida e volta implementada pelas ferramentas. Atravs das tcnicas de engenharia frente e engenharia reversa, as ferramentas possibilitam a sincronizao de modelo e cdigo. Aspectos que no so mapeados do modelo para o cdigo - informaes conceituais - permanecem inalterados no modelo aps sincronizar o cdigo alterado com o modelo. Existem alguns aspectos do modelo que no so mapeados da maneira esperada e podem comprometer a qualidade do cdigo. Observamos que a interao da ferramenta com o usurio basicamente restrita ao envio de mensagens de erro ou de sucesso ao usurio aps cada operao. H casos em que ocorrem erros e no exibido nenhum tipo de mensagem informativa. Diante de um mapeamento com mais de uma opo, no foi solicitado o auxlio do usurio. As ferramentas possuem uma opo default, para cada mapeamento, que pode ser modicada numa rea de congurao. A capacidade de transcrio das ferramentas de UML para Java no teve grandes mudanas, considerando trabalhos dos ltimos anos [Akehurst et al., 2007] [Gessenharter, 2008]. As associaes continuam sendo mapeadas sem diferenciar composio, agregao e associaes simples. Nem todos os adornos das extremidades de associao so mapeados para o cdigo. Os elementos que surgiram a partir da UML 2 - como o diagrama de estrutura composta e os fragmentos combinados do diagrama de sequncia - so suportados pelas ferramentas. No entanto, o mapeamento dessas estruturas para o cdigo ainda precrio.
5.2
Trabalhos Futuros
Em busca de maior aprimoramento sobre estudos de avaliao da interao das ferramentas CASE com o usurio (desenvolvedor), outros aspectos da relao UML e Java podem analisados. A nfase deste trabalho foi o mapeamento de UML para Java, isto , engenharia frente. Desta forma, consideramos interessante estender o trabalho dando nfase ao mapeamento de Java para UML. A relao da UML com outras linguagens de programao orientadas a objeto, como C++, pode ser do interesse destes desenvolvedores. Outro trabalho futuro seria analisar outras dimenses da usabilidade, como qualidade da interao, comunicabilidade, apreeensibilidade, entre outros. Apenas trs ferramentas foram avaliadas. Para melhor representao da realidade, seria interessante a avaliao de um nmero maior de ferramentas. Alm disso,
5.2. Trabalhos Futuros
113
consideramos importante que essa avaliao fosse feita por um grupo de desenvolvedores que no tivessem contato anterior com ferramentas especcas para avaliar aspectos de facilidade de aprendizado, dentre outros, e por um grupo de desenvolvedores com experincia nas ferramentas para avaliar aspectos como, por exemplo, preciso e consistncia. Neste trabalho foram analisados apenas alguns aspectos. Acreditamos que uma maior abrangncia trar maiores contribuies.
Referncias Bibliogrcas
[Akehurst et al., 2007] Akehurst, D.; Howells, G. & Maier, K. M. (2007). Implementing associations: UML 2.0 to Java 5. Software and Systems Modeling, 6(1):3--35. [Ali, 2005] Ali, M. R. (2005). Why teach reverse engineering? SIGSOFT Softw. Eng. Notes, 30:1--4. [Anda et al., 2006] Anda, B.; Hansen, K.; Gullesen, I. & Thorsen, H. K. (2006). Experiences from introducing UML-based development in a large safety-critical project. Empirical Softw. Engg., 11:555--581. [Angyal et al., 2006] Angyal, L.; Lengyel, L. & Charaf, H. (2006). An Overview of the State-of-The-Art Reverse Engineering Techniques. 7th International Symposium of Hungarian Researchers on Computational Intelligence. [Angyal et al., 2008] Angyal, L.; Lengyel, L. & Charaf, H. (2008). A synchronizing technique for syntactic model-code round-trip engineering. Em Engineering of Computer Based Systems, 2008. ECBS 2008. 15th Annual IEEE International Conference and Workshop on the, pp. 463--472. [Antkiewicz & Czarnecki, 2006] Antkiewicz, M. & Czarnecki, K. (2006). Frameworkspecic modeling languages with round-trip engineering. Em MoDELS06, pp. 692-706. [Arcelli et al., 2005] Arcelli, F.; Masiero, S.; Raibulet, C. & Tisato, F. (2005). A comparison of reverse engineering tools based on design pattern decomposition. Em Software Engineering Conference, 2005. Proceedings. 2005 Australian, pp. 262--269. [Artale et al., 2010] Artale, A.; Calvanese, D. & Ibez Garca, A. (2010). Full satisability of UML class diagrams. Em Proceedings of the 29th international conference on Conceptual modeling, ER10, pp. 317--331, Berlin, Heidelberg. Springer-Verlag. 115
116
Referncias Bibliogrficas
[Astah*, 2011] Astah* (2011). Astah* professional verso 6.3. Disponvel em http:// astah.change-vision.com/en/product/astah-professional.html, acessado em 07/2011. [Barsotti, 2003] Barsotti, D. (2003). Giving back in a big way. Disponvel em http: //www.progressiveengineer.com, acessado em 07/2011. [Bellay & Gall, 1997] Bellay, B. & Gall, H. (1997). A comparison of four reverse engineering tools. Em Proceedings of the Fourth Working Conference on Reverse Engineering (WCRE 97), pp. 2--11, Washington, DC, USA. IEEE Computer Society. [Booch et al., 2005] Booch, G.; Rumbaugh, J. & Jacobson, I. (2005). Unied Modeling Language User Guide, The (2nd Edition) (Addison-Wesley Object Technology Series). Addison-Wesley Professional. [Briand et al., 2006] Briand, L. C.; Labiche, Y. & Leduc, J. (2006). Toward the reverse engineering of UML sequence diagrams for distributed Java software. IEEE Trans. Softw. Eng., 32:642--663. [Bruegge & Dutoit, 2009] Bruegge, B. & Dutoit, A. H. (2009). Object-Oriented Software Engineering Using UML, Patterns, and Java. Prentice Hall Press, Upper Saddle River, NJ, USA, 3rd edio. [Buarque, 2009] Buarque, A. S. M. (2009). Desenvolvimento de software dirigido por modelos: Um foco em engenharia de requisitos. Dissertao de Mestrado. Universidade Federal de Pernambuco. [Buss & Henshaw, 2010] Buss, E. & Henshaw, J. (2010). A software reverse engineering experience. Em CASCON First Decade High Impact Papers, CASCON 10, pp. 42-60, New York, NY, USA. ACM. [Canfora & Di Penta, 2007] Canfora, G. & Di Penta, M. (2007). New frontiers of reverse engineering. Em 2007 Future of Software Engineering, FOSE 07, pp. 326--341, Washington, DC, USA. IEEE Computer Society. [Chikofsky & Cross II, 1990] Chikofsky, E. J. & Cross II, J. H. (1990). Reverse engineering and design recovery: A taxonomy. IEEE Softw., 7:13--17. [Chiril et al., 2010] Chiril, C.-B.; Sakkinen, M.; Lahire, P. & Jurca, I. (2010). Reverse inheritance in statically typed object-oriented programming languages. Em Proceedings of the 4th Workshop on MechAnisms for SPEcialization, Generalization and inHerItance, MASPEGHI 10, pp. 5:1--5:5, New York, NY, USA. ACM.
117
[de Souza, 2005] de Souza, C. S. (2005). The Semiotic Engineering of HumanComputer Interaction (Acting with Technology). The MIT Press. [de Souza et al., 2010] de Souza, C. S.; Leito, C. F.; Prates, R. O.; Amlia Bim, S. & da Silva, E. J. (2010). Can inspection methods generate valid new knowledge in HCI? the case of semiotic inspection. Int. J. Hum.-Comput. Stud., 68:22--40. [Diskin et al., 2008] Diskin, Z.; Easterbrook, S. M. & Dingel, J. (2008). Engineering associations: From models to code and back through semantics. Em Technology of Object-Oriented Languages and Systems, pp. 336--355. [Dobing & Parsons, 2006] Dobing, B. & Parsons, J. (2006). How UML is used. Commun. ACM, 49:109--113. [DSM, 2011] DSM (2011). Domain-specic modeling. Disponvel em http://www. dsmforum.org acessado em 07/2011. [Dzidek et al., 2008] Dzidek, W. J.; Arisholm, E. & Briand, L. C. (2008). A realistic empirical evaluation of the costs and benets of UML in software maintenance. IEEE Trans. Softw. Eng., 34:407--432. [EA, 2011] EA (2011). Enterprise Architect. verso 8.0, professional. Disponvel em http://www.sparxsystems.com.au/, acessado em 07/2011. [Ferdinand et al., 2008] Ferdinand, C.; Heckmann, R.; Wol, H.-J.; Renz, C.; Parshin, O. & Wilhelm, R. (2008). Model-driven development of reliable automotive services. captulo Towards Model-Driven Development of Hard Real-Time Systems, pp. 145-160. Springer-Verlag, Berlin, Heidelberg. [France & Rumpe, 2007] France, R. & Rumpe, B. (2007). Model-driven development of complex software: A research roadmap. Em 2007 Future of Software Engineering, FOSE 07, pp. 37--54, Washington, DC, USA. IEEE Computer Society. [France et al., 2006] France, R. B.; Ghosh, S.; Dinh-Trong, T. & Solberg, A. (2006). Model-driven development using UML 2.0: Promises and pitfalls. Computer, 39:59-66. [Gnova et al., 2003] Gnova, G.; Del Castillo, C. R. & Llorens, J. (2003). Mapping UML Associations into Java Code. JOURNAL OF OBJECT TECHNOLOGY, 2(5):135--162.
118
[Gessenharter, 2008] Gessenharter, D. (2008). Mapping the UML2 semantics of associations to a Java code generation model. Em Proceedings of the 11th international conference on Model Driven Engineering Languages and Systems, MoDELS 08, pp. 813--827, Berlin, Heidelberg. Springer-Verlag. [Gessenharter, 2009] Gessenharter, D. (2009). Implementing UML associations in Java: a slim code pattern for a complex modeling concept. Em Proceedings of the Workshop on Relationships and Associations in Object-Oriented Languages, RAOOL 09, pp. 17--24, New York, NY, USA. ACM. [Gogolla & Kollmann, 2000] Gogolla, M. & Kollmann, R. (2000). Re-documentation of Java with UML class diagrams. Em Proc. 7th Reengineering Forum, Reengineering Week 2000, pp. 41--48. [Harandi & Ning, 1990] Harandi, M. T. & Ning, J. Q. (1990). Knowledge-based program analysis. IEEE Softw., 7:74--81. [Harrison et al., 2000] Harrison, W.; Barton, C. & Raghavachari, M. (2000). Mapping UML designs to Java. Em Proceedings of the 15th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, OOPSLA 00, pp. 178--187, New York, NY, USA. ACM. [Hettel et al., 2008] Hettel, T.; Lawley, M. & Raymond, K. (2008). Model synchronisation: Denitions for round-trip engineering. Em Proceedings of the 1st international conference on Theory and Practice of Model Transformations, ICMT 08, pp. 31--45, Berlin, Heidelberg. Springer-Verlag. [Hidaka et al., 2009] Hidaka, S.; Hu, Z.; Kato, H. & Nakano, K. (2009). A compositional approach to bidirectional model transformation. Em Software Engineering - Companion Volume, 2009. ICSE-Companion 2009. 31st International Conference on, pp. 235--238. [IEEE, 1993] IEEE (1993). Std. 1219 - IEEE standard for software maintenance. [Issa et al., 2007] Issa, L.; Pdua, C. I. P. S.; Resende, R. F.; Viveiros, S. & de Alcntara dos Santos Neto, P. (2007). Desenvolvimento de interface com usurio dirigida por modelos com gerao automtica de cdigo. Em CIbSE, pp. 341--354. [Jakimi & Elkoutbi, 2009] Jakimi, A. & Elkoutbi, M. (2009). Automatic code generation from UML statechart. International Journal of Engineering, 1(2):165--168.
119
[Kegel & Steimann, 2008] Kegel, H. & Steimann, F. (2008). Systematically refactoring inheritance to delegation in Java. Em Proceedings of the 30th international conference on Software engineering, ICSE 08, pp. 431--440, New York, NY, USA. ACM. [Khaled, 2009] Khaled, L. (2009). A comparison between UML tools. Em Environmental and Computer Science, 2009. ICECS 09. Second International Conference on, pp. 111--114. [Kollman et al., 2002] Kollman, R.; Selonen, P.; Stroulia, E.; Syst, T. & Zundorf, A. (2002). A study on the current state of the art in tool-supported UML-based static reverse engineering. Em Proceedings of the Ninth Working Conference on Reverse Engineering (WCRE02), pp. 22--32, Washington, DC, USA. IEEE Computer Society. [Kollmann & Gogolla, 2001] Kollmann, R. & Gogolla, M. (2001). Application of UML associations and their adornments in design recovery. Em Proceedings of the Eighth Working Conference on Reverse Engineering (WCRE01), WCRE 01, pp. 81--90, Washington, DC, USA. IEEE Computer Society. [Labiche, 2009] Labiche, Y. (2009). Models in software engineering. captulo The UML Is More Than Boxes and Lines, pp. 375--386. Springer-Verlag, Berlin, Heidelberg. [Larman, 2008] Larman, C. (2008). Utilizando UML e Padres 3ed. BOOKMAN COMPANHIA ED. [Lewis & Loftus, 2007] Lewis, J. & Loftus, W. (2007). Java software solutions: foundations of program design. Pearson/Addison-Wesley. [Likert, 1932] Likert, R. (1932). A technique for the measurement of attitudes. [Manso et al., 2003] Manso, M. E.; Genero, M. & Piattini, M. (2003). No-redundant metrics for UML class diagram structural complexity. Em Proceedings of the 15th international conference on Advanced information systems engineering, CAiSE03, pp. 127--142, Berlin, Heidelberg. Springer-Verlag. [MDA, 2011] MDA (2011). Model driven architecture. Disponvel em http://www. omg.org/mda/specs.htm acessado em 07/2011. [Meyer, 1997] Meyer, B. (1997). UML: The positive spin. Disponvel em http: //archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html acessado em 07/2011.
120
[MIC, 2011] MIC (2011). Model-integrated computing. Institute for Software Integrated Systems. Disponvel em http://www.isis.vanderbilt.edu/research/MIC acessado em 07/2011. [Micskei & Waeselynck, 2010] Micskei, Z. & Waeselynck, H. (2010). The many meanings of UML 2 Sequence Diagrams: a survey. Software and Systems Modeling. [Milicev, 2007] Milicev, D. (2007). On the semantics of associations and association ends in UML. IEEE Trans. Softw. Eng., 33:238--251. [Mller et al., 2008] Mller, M.; Olderog, E.-R.; Rasch, H. & Wehrheim, H. (2008). Integrating a formal method into a software engineering process with UML and Java. Form. Asp. Comput., 20:161--204. [Mueller et al., 2006] Mueller, W.; Rosti, A.; Bocchio, S.; Riccobene, E.; Scandurra, P.; Dehaene, W. & Vanderperren, Y. (2006). UML for ESL design: basic principles, tools, and applications. Em Proceedings of the 2006 IEEE/ACM international conference on Computer-aided design, ICCAD 06, pp. 73--80, New York, NY, USA. ACM. [Mller et al., 2000] Mller, H. A.; Jahnke, J. H.; Smith, D. B.; Storey, M.-A.; Tilley, S. R. & Wong, K. (2000). Reverse engineering: a roadmap. Em Proceedings of the Conference on The Future of Software Engineering, ICSE 00, pp. 47--60, New York, NY, USA. ACM. [Oliver & Luukala, 2006] Oliver, I. & Luukala, V. (2006). On UMLs Composite Structure Diagram. Em Fifth Workshop on System Analysis and Modelling, Kaiserslautern, Germany. [OMG, 2011] OMG (2011). Object Management Group. Disponvel em http://www. omg.org/ acessado em 07/2011. [Parkinson & Bierman, 2008] Parkinson, M. J. & Bierman, G. M. (2008). Separation logic, abstraction and inheritance. Em Proceedings of the 35th annual ACM SIGPLAN-SIGACT Symposium on Principles of programming languages, POPL 08, pp. 75--86, New York, NY, USA. ACM. [Pastor & Molina, 2007] Pastor, O. & Molina, J. C. (2007). Model-Driven Architecture in Practice: A Software Production Environment Based on Conceptual Modeling. Springer-Verlag New York, Inc., Secaucus, NJ, USA.
121
[Pressman, 2006] Pressman, R. S. (2006). Engenharia de software. Editora McGrawHill. ISBN 8586804576, 6 edio. [Robert. B. Stone, 2000] Robert. B. Stone, D. A. M. (2000). The touchy -feely side of engineering education: Bringing hands-on experience to classroom. ASEE Midwest Section Conference. Boston, EUA. [RSA, 2011] RSA (2011). Rational Software Architect. verso 8.0. Disponvel em http://www-01.ibm.com/software/awdtools/architect/swarchitect, acessado em 07/2011. [Sa & Ernst, 2003] Sa, D. & Ernst, M. D. (2003). Reducing wasted development time via continuous testing. Em Proceedings of the 14th International Symposium on Software Reliability Engineering, ISSRE 03, pp. 281--292, Washington, DC, USA. IEEE Computer Society. [Sendall & Kster, 2004] Sendall, S. & Kster, J. M. (2004). Taming Model RoundTrip Engineering. Vancouver, Canada. [Sensalire et al., 2009] Sensalire, M.; Ogao, P. & Telea, A. (2009). Evaluation of software visualization tools: Lessons learned. 5th IEEE International Workshop on Visualizing Software for Understanding and Analysis, 2009. VISSOFT 2009. p19-26. [Sharif & Maletic, 2009] Sharif, B. & Maletic, J. (2009). An empirical study on the comprehension of stereotyped UML class diagram layouts. Em Program Comprehension, 2009. ICPC 09. IEEE 17th International Conference on, pp. 268--272. [Smans et al., 2009] Smans, J.; Jacobs, B. & Piessens, F. (2009). Implicit dynamic frames: Combining dynamic frames and separation logic. Em Proceedings of the 23rd European Conference on ECOOP 2009 Object-Oriented Programming, Genoa, pp. 148--172, Berlin, Heidelberg. Springer-Verlag. [Sommerville, 2007] Sommerville, I. (2007). Software Engineering. International computer science series. Addison-Wesley. [Strmer et al., 2006] Strmer, I.; Conrad, M.; Fey, I. & Drr, H. (2006). Experiences with model and autocode reviews in model-based software development. Em Proceedings of the 2006 international workshop on Software engineering for automotive systems, SEAS 06, pp. 45--52, New York, NY, USA. ACM.
122
[Superstructure, 2011] Superstructure (2011). Superstructure - OMG Unied Modeling Language. verso 2.4. Disponvel em: http://www.omg.org/spec/UML/ 2.4/Superstructure/PDF/. [Szlenk, 2008] Szlenk, M. (2008). Balancing agility and formalism in Software Engineering. captulo UML Static Models in Formal Approach, pp. 129--142. Springer-Verlag, Berlin, Heidelberg. [Tempero et al., 2008] Tempero, E.; Noble, J. & Melton, H. (2008). How do Java programs use inheritance? an empirical study of inheritance in Java software. Em Proceedings of the 22nd European conference on Object-Oriented Programming, ECOOP 08, pp. 667--691, Berlin, Heidelberg. Springer-Verlag. [TIBCO, 2011] TIBCO (2011). TIBCO: The power of now. Disponvel em http: //www.tibco.com.br/, acessado em 07/2011. [Tonella et al., 2007] Tonella, P.; Torchiano, M.; Du Bois, B. & Syst, T. (2007). Empirical studies in reverse engineering: state of the art and future trends. Empirical Softw. Eng., 12:551--571. [UML, 2011] UML (2011). Unied Modeling OMGlanguage. Disponvel em http: //www.uml.org/, acessado em 07/2011. [Wagelaar, 2008] Wagelaar, D. (2008). Challenges in bootstrapping a model-driven way of software development. In: ChaMDE 2008 Workshop Proceedings: International Workshop on Challenges in Model-Driven Software Engineering, pp. 25-30. [Warth et al., 2006] Warth, A.; Stanojevi, M. & Millstein, T. (2006). Statically scoped object adaptation with expanders. Em Proceedings of the 21st annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, OOPSLA 06, pp. 37--56, New York, NY, USA. ACM. [Ziadi et al., 2003] Ziadi, T.; Hlout, L. & marc Jzquel, J. (2003). Towards a UML prole for software product lines. Em In PFE, pp. 129--139. Springer.

Estudo Ida EVolta Codigo Docto UML

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Estudo Ida EVolta Codigo Docto UML

Enviado por

Direitos autorais:

Formatos disponíveis

UM ESTUDO SOBRE A ENGENHARIA DE IDA E VOLTA ENTRE UML E JAVA

LUIS PAULO ALVES MAGALHES

UM ESTUDO SOBRE A ENGENHARIA DE IDA E VOLTA ENTRE UML E JAVA

Belo Horizonte Julho de 2011

2011, Luis Paulo Alves Magalhes. Todos os direitos reservados.

2.2 2.3 2.4 2.5 2.6

3.1 3.2 3.3 3.4 3.5 3.6 3.7

3.76 Fragmento combinado inserido no diagrama de sequncia na ferramenta RSA. 93 93 93 94

3.80 3.81 3.82 3.83 3.84 3.85 3.86 3.87 3.88

Mapeamento Modelo-cdigo . . . . . . . . . . . . . . . . . . . . . . . . Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1. Contextualizao e Motivao

1.2. Objetivos e Metodologia

Captulo 2 Reviso Bibliogrca

Captulo 2. Reviso Bibliogrfica

2.1. Engenharia de Ida e Volta

Captulo 2. Reviso Bibliogrfica

2.1. Engenharia de Ida e Volta

Captulo 2. Reviso Bibliogrfica

2.1. Engenharia de Ida e Volta

Figura 2.3. Engenharia Frente e Engenharia Reversa [Angyal et al., 2006].

Captulo 2. Reviso Bibliogrfica

Captulo 2. Reviso Bibliogrfica

2.3. Mapeamento Modelo-cdigo

Figura 2.4. Hierarquia dos diagramas UML [UML, 2011].

Captulo 2. Reviso Bibliogrfica

2.4. Trabalhos Relacionados

Captulo 2. Reviso Bibliogrfica

2.4. Trabalhos Relacionados

Captulo 2. Reviso Bibliogrfica

2.4. Trabalhos Relacionados

Captulo 2. Reviso Bibliogrfica

2.4. Trabalhos Relacionados

Captulo 3 Planejamento e Execuo dos Estudos de Caso

Critrios para Seleo das Ferramentas CASE

Captulo 3. Planejamento e Execuo dos Estudos de Caso

Tabela 3.1. Critrios para seleo das ferramentas CASE

3.2. Critrios para Avaliao de Ferramentas CASE

Critrios para Avaliao de Ferramentas CASE

Captulo 3. Planejamento e Execuo dos Estudos de Caso

3.2. Critrios para Avaliao de Ferramentas CASE

Captulo 3. Planejamento e Execuo dos Estudos de Caso

Tabela 3.2. Relao dos critrios de avaliao das ferramentas CASE.

3.2. Critrios para Avaliao de Ferramentas CASE

Captulo 3. Planejamento e Execuo dos Estudos de Caso

3.4. Estudos de Caso

Captulo 3. Planejamento e Execuo dos Estudos de Caso

3.4. Estudos de Caso

Captulo 3. Planejamento e Execuo dos Estudos de Caso

3.4. Estudos de Caso

ESTUDO DE CASO 1 - Esteretipos

Figura 3.2. Esteretipo instantiate [Superstructure, 2011].

ESTUDO DE CASO 2 Associaes: Associao Simples, Agregao e Composio; Extremidades de associao.

Captulo 3. Planejamento e Execuo dos Estudos de Caso

Associao simples, Agregao e Composio

3.4. Estudos de Caso

Figura 3.4. Associao binria e ternria [Superstructure, 2011].

Figura 3.5. Agregao [Superstructure, 2011].

Captulo 3. Planejamento e Execuo dos Estudos de Caso

Figura 3.6. Relacionamento de Composio [Superstructure, 2011].

este estudo de caso utilizou apenas o modelo da Figura 3.6.

Adornos da extremidade de associao

3.4. Estudos de Caso

Captulo 3. Planejamento e Execuo dos Estudos de Caso