Geração de código estrutural implantável em nuvens a partir de modelos de componentes independentes de plataforma
183
0
0
Texto
(2) Universidade Federal de Pernambuco ´ Centro de Informatica - CIn. Thiago Araujo ´ Silva de Oliveira ´ ˜ DE CODIGO ´ GERAC ¸ AO ESTRUTURAL IMPLANTAVEL EM NUVENS A PARTIR DE MODELOS DE COMPONENTES INDEPENDENTES DE PLATAFORMA. Trabalho apresentado ao Programa de P´ os-gradua¸ c˜ ao em Ciˆ encia da Computa¸ c˜ ao do Centro de Inform´ atica - CIn da Universidade Federal de Pernambuco como requisito parcial para obten¸ c˜ ao do grau de Mestre em Ciˆ encia da Computa¸ c˜ ao.. Orientador: Prof. Dr. Jacques Louis Pierre Robin. Recife Fevereiro de 2011.
(3)
(4)
(5) Dedico ` a minha M˜ ae, Mainha, Ednalva... Ednalvinha..
(6) AGRADECIMENTOS. Primeiramente, agrade¸co a DEUS por ter me dado for¸ca para vencer todos o desafios em minha vida. Agrade¸co aos meus pais pela educa¸ca˜o e princ´ıpios ensinados, al´em do apoio em todos os momentos. Sem vocˆes, nada seria poss´ıvel. Agrade¸co as minhas irm˜as, Rosana e Juliana por se preocuparem com o meu bem estar, sa´ ude, alimenta¸c˜ao e tudo mais quando eu pouco me importava. Obrigado por tudo! Agrade¸co a minha namorada Janine, por todo carinho, afeto e compreens˜ao nas fases mais dif´ıceis deste trabalho. Agrade¸co mais ainda pelos tantos momentos felizes que me faziam esquecer dos problemas e obriga¸c˜oes. Agrade¸co aos grandes amigos alagoanos que fiz aqui em Pernambuco: Hugo, ´Icaro, Julio, Lek, Cheff, Bibi e Robertinho, pelo companheirismo, amizade e por terem me ajudado na realiza¸c˜ao desta pesquisa. Seja no Brasilit ou nas Gra¸cas, ser feliz aqui em Recife seria imposs´ıvel sem vocˆes. Agrade¸co aos ORCAs: Armando, Ramon, Ricardo, Ricson, Marcos, Weslei, Breno e especialmente Marcellus, pelas discuss˜oes, orienta¸c˜oes, por compartilhar solu¸co˜es, problemas e afli¸c˜oes do mestrado. A fam´ılia Oncase, empresa que acolheu, motivou e ajudou a tornar poss´ıvel a realiza¸ca˜o deste trabalho. Agradecimentos especiais aos membros da banca Vinicius Garcia e Franklin Ramalho pelas cr´ıticas construtivas, discuss˜oes e sobre orienta¸co˜es neste trabalho. Agrade¸co ao Jacques Robin pela orienta¸ca˜o.. vi.
(7) S´ o existem dois dias no ano que nada pode ser feito. Um se chama ontem e o outro amanh˜ a, portanto hoje ´ e o dia certo para amar, acreditar, fazer e principalmente viver. —DALAI LAMA.
(8) RESUMO. Model-Driven Engineering (MDE) visa melhorar a produtividade e qualidade de software, deslocando recursos que na maioria dos projetos s˜ao gastos em quest˜oes espec´ıficas da plataforma de programa¸ca˜o para direcionar esfor¸cos somente as quest˜oes de neg´ocio, independentes de plataforma. No ˆambito de um projeto com objetivo de implementa¸ca˜o em uma u ´nica plataforma, o retorno do investimento em modelos ´e claro somente se grande parte do c´odigo for gerado automaticamente a partir de modelos independentes de plataforma (PIM). No entanto, esse servi¸co ainda ´e um desafio, uma meta a ser atingida. Esta disserta¸c˜ao de mestrado contribui para o projeto WAKAME e mostra que esse objetivo ´e alcan¸c´avel. O projeto concentra esfor¸cos na constru¸ca˜o de uma ferramenta CASE MDE dispon´ıvel como uma aplica¸ca˜o WEB. Com o WAKAME, o desenvolvedor pode especificar o PIM da aplica¸c˜ao editando vis˜oes na ferramenta. As vis˜oes estruturais usam diagramas de classes UML, enquanto as operacionais utilizam express˜oes em OCL Imperativa. Essas vis˜oes s˜ao unificadas dentro de um modelo unificado (SUM), alvo das transforma¸co˜es. O WAKAME almeja que ao se concluir especifica¸ca˜o do PIM, o usu´ario possa automaticamente realizar a gera¸c˜ao de c´odigo e a implanta¸ca˜o da aplica¸c˜ao no servi¸co de nuvem da Google. Dentro desse objetivo, essa disserta¸c˜ao contribui na gera¸ca˜o de c´odigo estrutural e nas tarefas de infraestrutura da aplica¸ca˜o. Metodologicamente, este trabalho tamb´em contribui com uma inovadora arquitetura com duas fases de gera¸c˜ao de c´odigo: 1) cria¸ca˜o de uma nova representa¸ca˜o do modelo atrav´es de um framework de transforma¸c˜ao independente de plataforma; 2) realizar a transforma¸ca˜o da representa¸ca˜o em objetos para c´odigo atrav´es de um motor de templates. A nova representa¸ca˜o oferece uma arquitetura extens´ıvel para outras plataformas.. Palavras-chave: MDE, MDA, UML, Transforma¸ca˜o de Modelos, Gera¸c˜ao de C´odigo. viii.
(9) ABSTRACT. Model-Driven Engineering (MDE) aims at improving both software productivity and quality by shifting the concerns where most project resources are spent away from platform-specific programming, testing and deployment concerns and towards platformindependent business modeling concerns. Within the scope of a single project aiming at implementing a business model on a single platform, the return on such investment is clearcut only if almost all the code is automatically generated from the PIM. However, complete code generation from a general-purpose modeling language to a general-purpose programming platform remained to date an elusive goal. The failure to reach it undermined the credibility of the MDE vision for the projects of single platform. This master thesis contributes to the project WAKAME and shows that this goal is achievable. The project concentrates on building a CASE tool MDE available as a web application. With WAKAME, the developer can specify a PIM editing views of application within the tool. The structural views use UML class diagrams, while the behavioral expressions used in Imperative OCL. These views are unified within a unified model that is the target of transformations. In WAKAME, complete specification of the PIM, the user can perform code generation and deployment of application software that runs on Google’s cloud. In this ambitious project, this thesis contributes to the structural code generation and software infrastructure, tasks such as deployment, testing and combination with the component translation of IOCL from behavioral views, are the responsibility of this project. Methodologically, this work contributes an innovative architecture of two stages of code generation. First, the creation of a new model representation through a framework for transformation platform-independent. In second place is the transformation of that representation into code through an engine template. This new representation allows the inclusion of specific aspects of the platform and allows an extensible architecture to other platforms.. Keywords: MDE, MDA, UML, Transformation Model, Code Generation ix.
(10) ´ SUMARIO. Lista de Figuras. xv. Lista de Tabelas. xviii. Lista de Abreviaturas. xix. ˜ Cap´ıtulo 1—Introduc¸ao. 1. 1.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 1.2. Motiva¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3. 1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. 1.4. Fora do Escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5. 1.5. Estrutura da Disserta¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6. ˜ em Cap´ıtulo 2—Desenvolvimento Orientado por Modelos e a Computac¸ao Nuvem. 7. 2.1. Engenharia Dirigida por Modelos . . . . . . . . . . . . . . . . . . . . . .. 7. 2.2. Model Driven Architecture . . . . . . . . . . . . . . . . . . . . . . . . . .. 10. 2.2.1. UML e outros padr˜oes da OMG . . . . . . . . . . . . . . . . . . .. 11. 2.2.2. N´ıveis de Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . .. 12. 2.2.3. Transforma¸c˜ao de Modelos . . . . . . . . . . . . . . . . . . . . . .. 14. 2.2.4. Gera¸c˜ao de C´odigo . . . . . . . . . . . . . . . . . . . . . . . . . .. 15. 2.2.5. Vantagens e Desafios . . . . . . . . . . . . . . . . . . . . . . . . .. 16. Computa¸c˜ao em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . .. 18. 2.3.1. Princ´ıpios e Conceitos Relacionados . . . . . . . . . . . . . . . . .. 18. 2.3.2. Benef´ıcios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 21. 2.3.3. Google Appe Engine - GAE . . . . . . . . . . . . . . . . . . . . .. 22. 2.3. x.
(11) xi. ´ SUMARIO. 2.3.3.1. BigTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2.3.3.2. Avan¸cos e Limita¸co˜es com a GAE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 23. Combinando Computa¸ca˜o em Nuvem e MDE . . . . . . . . . . .. 24. Considera¸c˜oes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 25. 2.3.4 2.4. 23. Cap´ıtulo 3—KobrA2, Projeto WAKAME e KISF. 26. 3.1. Engenharia Baseada em Componentes . . . . . . . . . . . . . . . . . . .. 26. 3.2. Linha de Produto de Software . . . . . . . . . . . . . . . . . . . . . . . .. 27. 3.3. Modelagem Ortogr´afica . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 28. 3.4. M´etodo KobrA2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 30. 3.4.1. Introdu¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 30. 3.4.2. Vis˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 32. 3.4.3. Metamodelo KobrA2 . . . . . . . . . . . . . . . . . . . . . . . . .. 34. 3.4.4. Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 36. 3.5. Projeto WAKAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 36. 3.6. KISF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 39. 3.7. Considera¸c˜oes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 41. ´ Cap´ıtulo 4—StructuralGenerator: Um Gerador de Codigo Estrutural 4.1. 42. T´ecnicas e Abordagens Adotadas na Solu¸ca˜o . . . . . . . . . . . . . . . .. 43. 4.1.1. Gera¸c˜ao Estrutural . . . . . . . . . . . . . . . . . . . . . . . . . .. 43. 4.1.2. PIM->C´odigo: Usando Templates . . . . . . . . . . . . . . . . . .. 44. 4.1.2.1. PIM-C´odigo: Transforma¸ca˜o direta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4.1.2.2. 44. PIM-C´odigo: T´ecnicas de Implementa¸ca˜o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 45.
(12) xii. ´ SUMARIO. 4.1.2.3. Solu¸ca˜o Adotada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4.1.2.4. 4.2. 4.3. 46. Processo de Transforma¸ca˜o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 49. 4.1.3. Evolu¸ca˜o da Aplica¸ca˜o . . . . . . . . . . . . . . . . . . . . . . . .. 51. 4.1.4. Linha de Produto de Software no Gerador . . . . . . . . . . . . .. 52. 4.1.5. Transforma¸c˜oes sobre Vis˜oes Ortogr´aficas . . . . . . . . . . . . . .. 53. Caracter´ısticas Estruturais e de Infraestrutura das Aplica¸co˜es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 53. 4.2.1. Plataforma alvo: Java e Google App Engine - GAE . . . . . . . .. 54. 4.2.2. Componentes e Inje¸ca˜o de Dependˆencias . . . . . . . . . . . . . .. 54. 4.2.3. Persistˆencia: Objeto/Relacional . . . . . . . . . . . . . . . . . . .. 56. 4.2.4. Design por Contrato com Aspectos . . . . . . . . . . . . . . . . .. 59. 4.2.5. Gera¸c˜ao e Execu¸ca˜o de Testes . . . . . . . . . . . . . . . . . . . .. 62. 4.2.6. Automa¸c˜ao de Tarefas . . . . . . . . . . . . . . . . . . . . . . . .. 63. Considera¸c˜oes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 64. Cap´ıtulo 5—Projeto StructuralGenerator. 65. 5.1. Integra¸c˜ao com PIM WAKAME. . . . . . . . . . . . . . . . . . . . . . .. 65. 5.2. StructuralGenerator PIM . . . . . . . . . . . . . . . . . . . . . . . . . . .. 69. 5.2.1. Modelagem no WAKAME . . . . . . . . . . . . . . . . . . . . . .. 69. 5.2.2. StructuralGenerator: Realiza¸ca˜o . . . . . . . . . . . . . . . . . . .. 71. 5.2.3. ModelManager: Instancia¸c˜ao do modelo com KCGF . . . . . . . .. 75. 5.2.3.1. KobrA2 Code Generator Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 76. 5.2.4. ProjectManager: Tarefas de Infraestrutura . . . . . . . . . . . . .. 78. 5.2.5. CodeGenerator: Gera¸c˜ao de C´odigo . . . . . . . . . . . . . . . . .. 83. 5.2.5.1. Algoritmo de Gera¸c˜ao com KCGF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 84.
(13) xiii. ´ SUMARIO. 5.2.5.2. Templates FreeMarker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 85. 5.3. WAKAMEGeneratorTool . . . . . . . . . . . . . . . . . . . . . . . . . . .. 89. 5.4. Considera¸c˜oes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 91. ˜ do StructuralGenerator Cap´ıtulo 6—Avaliac¸ao. 92. 6.1. Processo de Experimento . . . . . . . . . . . . . . . . . . . . . . . . . . .. 92. 6.2. Defini¸ca˜o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 93. 6.3. Hip´oteses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 95. 6.4. Primeiro Experimento: WebAgency . . . . . . . . . . . . . . . . . . . . .. 96. 6.4.1. 97. Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1.1. 6.4.2. Amea¸cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 98. Opera¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 98. 6.4.2.1. WebAgency: PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 98. WebAgency: Implementa¸ca˜o Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 104. WebAgency: Artefatos Gerados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 105. An´alise e Interpreta¸ca˜o . . . . . . . . . . . . . . . . . . . . . . . .. 112. Segundo Experimento: CHROME . . . . . . . . . . . . . . . . . . . . . .. 114. 6.5.1. 114. 6.4.2.2 6.4.2.3 6.4.3 6.5. Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1.1. 6.5.2. Amea¸cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 115. Opera¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 115. 6.5.2.1. CHROME: PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 116. CHROME: Implementa¸ca˜o Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 120. CHROME: Artefatos Gerados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 120. An´alise e Interpreta¸ca˜o . . . . . . . . . . . . . . . . . . . . . . . .. 123. 6.5.2.2 6.5.2.3 6.5.3.
(14) xiv. ´ SUMARIO. 6.6. Considera¸c˜oes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Cap´ıtulo 7—Trabalhos Relacionados 7.1. 7.2. 124 125. Ferramentas Avaliadas . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 125. 7.1.1. Rational Software Architect - RSA . . . . . . . . . . . . . . . . .. 127. 7.1.2. MagicDraw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 128. 7.1.3. AndroMDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 128. 7.1.4. Acceleo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 130. Compara¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 132. ˜ Cap´ıtulo 8—Conclusao. 134. 8.1. Contribui¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 134. 8.2. Limita¸co˜es e Dificuldades . . . . . . . . . . . . . . . . . . . . . . . . . . .. 135. 8.3. Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 136. ˆ ´ Referencias Bibliograficas. 148. ˆ Apendice A—Web Agency - PIM. 149. A.1 Structural Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 149. A.2 Operational Specification . . . . . . . . . . . . . . . . . . . . . . . . . . .. 152. ˆ Apendice B—CHROME - PIM. 157. B.1 Structural Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 157. B.2 Operational Specification . . . . . . . . . . . . . . . . . . . . . . . . . . .. 160.
(15) LISTA DE FIGURAS. 2.1. Taxonomia dos Diagramas UML2. Fonte: [OMG10d]. . . . . . . . . . . .. 11. 2.2. N´ıveis de Modelo. Fonte: [KWB03]. . . . . . . . . . . . . . . . . . . . . .. 13. 2.3. Transforma¸ca˜o PIM-PSM-C´odigo. . . . . . . . . . . . . . . . . . . . . . .. 14. 2.4. Classifica¸ca˜o de Servi¸cos em Nuvens. Fonte:[YBDS08]. . . . . . . . . . .. 19. 3.1. Ilustra¸ca˜o das Vis˜oes Ortogr´aficas na Constru¸ca˜o Civil. Fonte: [CAB09].. 29. 3.2. Vis˜oes de um Componente KobrA2. Adaptada de [CAB09].. . . . . . . .. 33. 3.3. Pacote KobrA2::SUM::Structure do metamodelo KobrA2. . . . . . . . . .. 35. 3.4. WAKAME: Tela de Edi¸c˜ao dos Modelos. . . . . . . . . . . . . . . . . . .. 37. 3.5. KISF: Vis˜ao Estrutural da Realiza¸c˜ao dos Servi¸cos. . . . . . . . . . . . .. 40. 3.6. BusinessService: Vis˜ao Estrutural da Realiza¸c˜ao dos Servi¸cos. . . . . . .. 41. 4.1. WAKAMEGenerator e seus Subcomponentes. . . . . . . . . . . . . . . .. 42. 4.2. Gera¸ca˜o Baseada em API. . . . . . . . . . . . . . . . . . . . . . . . . . .. 46. 4.3. Templates e Metamodelo. Adaptada de [SV06]. . . . . . . . . . . . . . .. 47. 4.4. Ilustra¸ca˜o do Fluxo da Transforma¸c˜ao. . . . . . . . . . . . . . . . . . . .. 50. 4.5. Template FreeMarker:class.ftl. . . . . . . . . . . . . . . . . . . . . . . . .. 51. 4.6. Template FreeMarker: Macro property.ftl . . . . . . . . . . . . . . . . . .. 51. 4.7. StructuralGenerator: Vis˜ao Estrutural da Especifica¸ca˜o dos Servi¸cos. Extra´ıda do WAKAME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 55. 4.8. StructuralGenerator: Estrutura de Pacotes Java. Extra´ıda do MagicDraw.. 55. 4.9. Exemplo de Vis˜ao Estrutural da Especifica¸ca˜o dos Tipos. . . . . . . . . .. 58. 4.10 Classe Java Mapeada com Anota¸co˜es. . . . . . . . . . . . . . . . . . . . .. 58. 4.11 Exemplo de AspectoJ. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 61. 4.12 Aspecto: pr´e e p´os-condi¸co˜es. . . . . . . . . . . . . . . . . . . . . . . . .. 62. 5.1. 66. Integra¸c˜ao WAKAMEGenerator.. . . . . . . . . . . . . . . . . . . . . . . xv.
(16) LISTA DE FIGURAS 5.2. xvi. WAKAMEGenerator: Vis˜ao Estrutural da Realiza¸c˜ao dos Servi¸cos. Fonte [Mac09] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 67. 5.3. Transforma¸ca˜o: Diagrama de Sequˆencia. . . . . . . . . . . . . . . . . . .. 68. 5.4. PIM do StructuralGenerator: Vis˜ao Estrutural da Especifica¸ca˜o dos Servi¸cos. 70. 5.5. StructuralGenerator: Vis˜ao Estrutural da Especifica¸ca˜o dos Servi¸cos. . .. 71. 5.6. StructuralGenerator: Vis˜ao Estrutural da Realiza¸ca˜o dos Servi¸cos. . . . .. 72. 5.7. StructuralGenerator: Diagrama de Atividades. . . . . . . . . . . . . . . .. 73. 5.8. StructuralGenerator: Vis˜ao Estrutural da Especifica¸ca˜o dos Tipos. . . . .. 74. 5.9. StructuralGenerator:generate. . . . . . . . . . . . . . . . . . . . . . . . .. 74. 5.10 ModelManager : Vis˜ao Estrutural da Especifica¸c˜ao dos Servi¸cos. . . . . .. 76. 5.11 ModelManager : Vis˜ao Estrutural da Especifica¸c˜ao dos Tipos. . . . . . . .. 77. 5.12 ProjectManager : Vis˜ao Estrutural da Especifica¸c˜ao dos Servi¸cos. . . . . .. 79. 5.13 appengine-web.xml : Arquivo de Configura¸c˜ao da Aplica¸ca˜o. . . . . . . . .. 79. 5.14 build-core.xml : Script Ant principal da Transforma¸c˜ao. . . . . . . . . . .. 81. 5.15 build-create.xml : Script Ant para Cria¸ca˜o da Estrutura do Projeto. . . .. 82. 5.16 Chamada ao appcfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 83. 5.17 CodeGenerator : Vis˜ao Estrutural da Especifica¸c˜ao dos Servi¸cos. . . . . .. 83. 5.18 interfaceComponentClass.ftl : Template FreeMarker. . . . . . . . . . . . .. 85. 5.19 enumeration.flt: Template FreeMarker para Gera¸c˜ao de Enumera¸ca˜o. . .. 86. 5.20 operationDecl.ftl : Template FreeMarker para Gera¸c˜ao da Assinatura da Opera¸ca˜o. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 86. 5.21 aspect.ftl : Template FreeMarker para gera¸c˜ao de AspectJ. . . . . . . . . .. 87. 5.22 before.ftl : Template macro FreeMarker para gera¸c˜ao de Before( pr´e-condi¸c˜ao). 88 5.23 Classe JOperation do KCGF . . . . . . . . . . . . . . . . . . . . . . . . .. 89. 5.24 WAKAMEGeneratorTool : Diagrama de Implanta¸c˜ao. . . . . . . . . . . .. 90. 5.25 WAKAMEGeneratorTool : Em execu¸c˜ao. . . . . . . . . . . . . . . . . . .. 91. 6.1. Overview do processo. Fonte: [WRH+ 01] . . . . . . . . . . . . . . . . . .. 93. 6.2. WebAgencyBusinessService: Vis˜ao Estrutural da Especifica¸c˜ao dos Servi¸cos. 99. 6.3. WebAgencyBusinessService: Vis˜ao Estrutural da Realiza¸c˜ao dos Servi¸cos.. 99. 6.4. WebAgencyBusinessService: Vis˜ao Estrutural da Realiza¸c˜ao dos Tipos. .. 100. 6.5. WebAgencyPersistence: Vis˜ao Estrutural da Especifica¸c˜ao dos Servi¸cos. .. 101.
(17) LISTA DE FIGURAS. xvii. 6.6. WebAgencyBusinessFacade: Vis˜ao Operational da realiza¸c˜ao dos Servi¸cos. 101. 6.7. WebAgencyBusinessLogic: Vis˜ao Estrutural da Realiza¸c˜ao dos Servi¸cos. .. 102. 6.8. WebAgencyBusinessLogic: Vis˜ao Operational da Realiza¸c˜ao dos Servi¸cos.. 103. 6.9. Appraiser : Vis˜ao Operacional da Especifica¸c˜ao dos Servi¸cos. . . . . . . .. 104. 6.10 WebAgency: Eclipse - Package Explorer. . . . . . . . . . . . . . . . . . .. 106. 6.11 WebAgencyBusinessLogic: Interface. . . . . . . . . . . . . . . . . . . . .. 107. 6.12 WebAgencyBusinessLogic: Implementa¸ca˜o. . . . . . . . . . . . . . . . . .. 108. 6.13 Classe Loan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 109. 6.14 WebAgencyBusinessServiceTestCase: Caso de Testes. . . . . . . . . . . .. 110. 6.15 AppraiserCheck : Aspecto do Appraiser. . . . . . . . . . . . . . . . . . . .. 111. 6.16 Compara¸ca˜o das m´etricas de linhas de c´odigo . . . . . . . . . . . . . . .. 113. 6.17 CHROME : Vis˜ao Estrutural da Especifica¸ca˜o dos Servi¸cos. . . . . . . . .. 116. 6.18 CHROME : Vis˜ao Estrutural da Realiza¸c˜ao dos Servi¸cos. . . . . . . . . .. 117. 6.19 QueryProcess: Vis˜ao Estrutural da Realiza¸c˜ao dos Servi¸cos. . . . . . . .. 118. 6.20 Classe Loan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 119. 6.21 Interface FiredRules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 121. 6.22 Classe FiredRulesImpl. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 122. A.1 WebAgencyBusinessService - Specification Structural Class Service. . . .. 149. A.2 WebAgencyBusinessService - Realization Structural Class Service . . . .. 150. A.3 WebAgencyBusinessService - Realization Structural Class Type . . . . .. 150. A.4 WebAgencyBusinessFacade - Specification Structural Class Service . . . .. 151. A.5 WebAgencyBusinessLogic - Specification Structural Class Service . . . . .. 151. A.6 WebAgencyBusinessPersistence - Specification Structural Class Service .. 151. B.1 CHROME - Specification Structural Class Service . . . . . . . . . . . . .. 157. B.2 CHROME - Specification Structural Class Type . . . . . . . . . . . . . .. 158. B.3 CHROME - Realization Structural Class Service . . . . . . . . . . . . . .. 158. B.4 QueryProcessor - Realization Structural Class Service . . . . . . . . . . .. 159.
(18) LISTA DE TABELAS. 3.1. Funcionalidades de uma Ferramenta Ideal. . . . . . . . . . . . . . . . . .. 38. 6.1. M´etricas do WebAgency Manual. . . . . . . . . . . . . . . . . . . . . . .. 104. 6.2. WebAgencyBusinessLogic Manual: Testes Manuais . . . . . . . . . . . .. 105. 6.3. M´etricas do WebAgency Gerado. . . . . . . . . . . . . . . . . . . . . . .. 112. 6.4. WebAgencyBusinessLogic Gerada: Testes Manuais . . . . . . . . . . . . .. 112. 6.5. Raz˜oes entre as m´etricas da Quest˜ao 2. . . . . . . . . . . . . . . . . . . .. 114. 6.6. M´etricas do CHROME Manual. . . . . . . . . . . . . . . . . . . . . . . .. 120. 6.7. M´etricas do CHRome Gerado. . . . . . . . . . . . . . . . . . . . . . . . .. 123. 7.1. Tabela Comparativa das Ferramentas . . . . . . . . . . . . . . . . . . . .. 132. xviii.
(19) LISTA DE ABREVIATURAS. MDA MDE API CASE CRUD CBE DI DSL GAE GUI IDE IOCL KISF MOF OCL OMG OSM PIM PSM QVT SPL SUM UML WAKAME XMI DbC. Model Driven Architecture Model Driven Engineering Application Programming Interface Computer-Aided Software Engineering Create-Read-Update-Delete Component-Based Engineering Dependency of Injection Domain Specific Language Google App Engine Graphical User Interface Integrated Development Environment Imperative Object Constraint Language KobrA2 Web Application Framework Meta-Object Facility Object Constraint Language Object Management Group Orthographic Software Modeling Platform Independent Model Platform Specific Model Query/View/Transformation Software Product Line Single Underlying Model Unified Modeling Language Web App Kobra Model Engineering XML Metadata Interchange Design by Contract. xix.
(20) CAP´ITULO 1. ˜ INTRODUC ¸ AO. Neste cap´ıtulo, ser´a apresentado o contexto no qual este trabalho est´a envolvido, sua motiva¸c˜ao e objetivos. Por fim, ´e descrita a estrutura dessa disserta¸c˜ao. Ap´os introduzir a ´area na qual essa pesquisa est´a inserida, esse cap´ıtulo contextualiza os objetivos dessa disserta¸ca˜o, apresentando as motiva¸c˜oes, o foco, o contexto, as principais contribui¸co˜es e por fim, a estrutura dessa disserta¸c˜oes.. 1.1. CONTEXTO. O desenvolvimento de software ´e uma tarefa desafiadora. Os engenheiros de software tˆem sempre que lidar com um grande n´ umero de vari´aveis para construir aplica¸co˜es com sucesso. O completo entendimento do dom´ınio do projeto, as mudan¸cas que podem ocorrer durante o desenvolvimento, or¸camento e prazos s˜ao apenas algumas quest˜oes com as quais os engenheiros tˆem que se preocupar[Som01]. A a´rea da Engenharia de Software tem fornecido muitas t´ecnicas para facilitar o desenvolvimento, a caracter´ıstica comum entre elas, ´e a abstra¸ca˜o[SV06]. O uso de modelos oferece uma forma de abstra¸ca˜o. A linguagem padr˜ao adotada pela ind´ ustria para cria¸c˜ao de modelos ´e a UML(Unified Modeling Language)[OMG10d]. O foco nos modelos pode reduzir a complexidade da cria¸c˜ao e manuten¸c˜ao pois detalhes da plataforma podem ser abstra´ıdos no desenvolvimento, detalhes que podem ser obtidos mais adiante no processo por meio de transforma¸co˜es sobre os modelos. O desenvolvimento centrado em modelos ´e chamado de Engenharia Dirigida por Modelos(ModelDriven Engineering - MDE)[Sch06]. No in´ıcio do ano 2000, a Object Management Group (OMG)[OMG10a] definiu uma realiza¸ca˜o do MDE usando o termo Model Driven Architecture - MDA[OMG10f]. A OMG ´e um cons´orcio internacional, aberto e sem fins lucrativos, de empresas e institui¸c˜oes de todos os setores, com a finalidade de definir padr˜oes abertos para as mais diversas tecnologias. 1.
(21) 1.1 CONTEXTO. 2. O MDA define um conjunto de n´ıveis e pap´eis para os diferentes modelos usados dentro de um projeto MDE. Ele tamb´em define diretrizes de como construir e evoluir uma aplica¸ca˜o a partir de modelos. A OMG especifica um conjunto de padr˜oes abertos para sustentar o desenvolvimento seguindo o MDA. Os principais s˜ao UML e os demais padr˜oes que a cercam: MOF (Meta-Object Facility)[OMG10c], OCL (Object Constrait Language)[OMG10b] e o XMI(XML Metadata Interchange)[OMG10e]. A aborgagem de desenvolvimento MDA ´e baseado na cria¸ca˜o de um Modelo Independente de Plataforma (Platform Independent Model - PIM), na qual as funcionalidades da aplica¸c˜ao s˜ao formalmente definidas. Posteriormente, um ou mais motores de transforma¸ca˜o tem a fun¸ca˜o de traduzir o PIM para Modelos Espec´ıficos de Plataforma (Platform Independent Model - PSM), e provavelmente uma nova transforma¸ca˜o para c´odigo. A passagem direta do PIM para c´odigo tamb´em ´e poss´ıvel. A UML e os demais padr˜oes obtiveram ampla aceita¸c˜ao entre os profissionais e fornecedores de ferramentas MDE. No entanto, por serem de uso geral, suas especifica¸c˜oes s˜ao extensas, multi-facetadas e, em conjunto, incluem muitas redundˆancias[SSKK02]. Para aproveitar o poder de expressividade desses padr˜oes e garantir ganhos de produtividade aos projetos, ´e necess´ario seguir um processo sistem´atico que guie a cria¸c˜ao dos modelos e a evolu¸c˜ao para uma aplica¸c˜ao. O MDA ´e apenas uma filosofia, um framework conceitual, sua especifica¸c˜ao n˜ao define quais diagramas e artefatos devem ser usados[Kob04]. Para alcan¸car a alta produtividade com desenvolvimento dirigido por modelos ´e necess´aria a ado¸c˜ao de uma metodologia adequada a essa abordagem. Junto a um processo mais bem definido, ferramentas de modelagem e a autom´atica gera¸c˜ao de c´odigo s˜ao essenciais no ganho de produtividade frente `as abordagens convencionais de codifica¸ca˜o manual. O m´etodo KobrA2, ´e o resultado da colabora¸ca˜o entre o Prof. Colin Atkinson da Universidade Mannheim, Alemanha, e do grupo ORCAS1 liderado pelo Prof. Jacques Robin da Universidade Federal de Pernambuco. O m´etodo ´e a maior evolu¸c˜ao do processo KobrA original, publicado em 2002 no livro ”Component-Based Product Line Enginnering in UML”[ABB+ 02]. A necessidade de assistir o processo KobrA2 na cria¸c˜ao eficiente dos modelos levou ao surgimento da ferramenta WAKAME (Web App Kobra Model Engineering)[dTM09][Mac09]. 1. http://www.cin.ufpe.br/˜orcas/.
(22) ˜ 1.2 MOTIVAC ¸ AO. 1.2. 3. ˜ MOTIVAC ¸ AO. A atual vers˜ao do WAKAME carece de mecanismos de transforma¸c˜oes e gera¸ca˜o de c´odigo a partir de modelos PIM. Essa funcionalidade ´e fundamental para uma maior eficˆencia do uso do m´etodo KobrA2 na cria¸c˜ao de software atrav´es do WAKAME. A motiva¸c˜ao para o desenvolvimento dessa pesquisa ´e a contribui¸ca˜o junto ao WAKAME para o desenvolvimento de um motor de transforma¸ca˜o capaz de realizar a gera¸c˜ao de c´odigo a partir dos modelos criados por meio das vis˜oes KobrA2 na ferramenta. Diante disso, esta disserta¸ca˜o de mestrado investiga e prop˜oe uma ferramenta para gera¸ca˜o de c´odigo estrutural e a disponibiliza¸ca˜o da aplica¸c˜ao a partir de PIMs que seguem as vis˜oes do KobrA2 criadas no WAKAME. O foco dessa gera¸ca˜o ´e apenas a parte estrutural, logo n˜ao compreende a transforma¸ca˜o de toda especifica¸ca˜o presente no PIM em aplica¸c˜oes. No entanto, a ferramenta proposta tem a miss˜ao de auxiliar as demais transforma¸co˜es com a cria¸ca˜o de um ambiente e artefatos necess´arios a essas. Uma gera¸ca˜o completa envolve al´em dos aspectos estruturais, os operacionais e a interface gr´afica de usu´ario (GUI). Para alcan¸car essa completude, foi criado no grupo ORCAS para o WAKAME/KobrA2, o projeto WAKAMEGenerator. Essa pesquisa de mestrado est´a inserida nesse projeto. A realiza¸c˜ao dos seus objetivos est´a relacionda a trˆes pesquisas de mestrado. O escopo do WAKAMEGenerator est´a dividido no desenvolvimento de trˆes componentes: • Pesquisa, desenvolvimento e avalia¸c˜ao de um componente gerador de c´odigo para os artefatos estruturais de software. Esse componente ser´a respons´avel por percorrer o modelo SUM e transformar em c´odigo todos os elementos da hierarquia de componentes. Al´em das transforma¸co˜es, as tarefas de compila¸ca˜o, cria¸c˜ao de testes, documenta¸ca˜o, configura¸ca˜o de reposit´orio e implanta¸ca˜o s˜ao responsabilidades desse componente, denominado StructuralGenerator; • Pesquisa, desenvolvimento e avalia¸ca˜o de um gerador de c´odigo da camada de GUI. Esse componente ser´a respons´avel pela completa gera¸ca˜o da GUI, assim como o c´odigo de tratamento dos eventos que lidam com as intera¸co˜es do usu´ario e a comunica¸c˜ao cliente/servidor. Trabalho futuro, iniciado por Ramon Rabelo com o componente UIGenerator[Rabso]. • Pesquisa, desenvolvimento e avalia¸ca˜o de um gerador de c´odigo a partir de express˜oes OCL Imperativa (IOCL), componente chamado IOCLCompiler. Esse, al´em.
(23) 1.3 OBJETIVOS. 4. da gera¸ca˜o de c´odigo, deve possuir as responsabilidades de executar um parser sobre as express˜oes, realizando a verifica¸ca˜o sint´atica, e a an´alise semˆantica respons´avel por verificar a corretude das express˜oes com o modelo. Pesquisa realizada por Macellus Tavares[dCTso]. O StructuralGenerator, desenvolvido nesta pesquisa, deve orquestrar todo o processo de transforma¸ca˜o, pois al´em de implementar a cria¸ca˜o dos artefatos estruturais, ele usa os servi¸cos do IOCLCompiler para complementar a aplica¸ca˜o gerada com os aspectos comportamentais, corpo dos m´etodos, pr´e e p´os-condi¸co˜es.. 1.3. OBJETIVOS. Para alcan¸car os objetivos da gera¸c˜ao estrutural e a disponibiliza¸c˜ao de uma aplica¸ca˜o execut´avel a partir de modelos KobrA2 constru´ıdos no WAKAME, essa pesquisa de mestrado tem seus objetivos subdivididos em tarefas menores a serem realizadas: • Gerar aplica¸co˜es de Sistemas de Informa¸ca˜o (SI) a partir de modelos KobrA2 de componentes constru´ıdos por meio das vis˜oes produzidas no WAKAME com uso de Modelagem Ortogr´afica[AS08]; • Implantar as aplica¸co˜es criadas em nuvens computacionais. Combinando o MDA com a computa¸ca˜o em nuvem para se beneficiar com a abstra¸ca˜o de servi¸cos dessa nova tendˆencia. Para valida¸ca˜o, a implanta¸ca˜o ser´a realizada na plataforma de nuvens da Google; • Abstrair do usu´ario qualquer tarefa que necessite expertise tecnol´ogico, tornar todo processo independente de plataforma; • Criar e executar testes nas aplica¸c˜oes criadas; • Gerar uma infraestrutura capaz de executar verifica¸co˜es runtime na aplica¸ca˜o; • Criar uma interface com o usu´ario (GUI) que permita a execu¸ca˜o da gera¸c˜ao de c´odigo a partir de modelos produzidos no WAKAME; • Integra¸c˜ao com os demais componentes de transforma¸ca˜o e posteriormente com WAKAME e.
(24) 1.4 FORA DO ESCOPO. 5. • Valida¸c˜ao do m´etodo KobrA2 e do framework KISF[Mac09] atrav´es da utiliza¸ca˜o de ambos. A infraestrutura para verifica¸c˜ao de restri¸co˜es em tempo de execu¸c˜ao, junto aos elementos estruturais, ´e um diferencial desse trabalho. Nessa pesquisa, ´e utilizada uma abordagem do uso de aspectos, gerados a partir de pr´e e p´os-condi¸co˜es, para solucionar a quest˜ao das restri¸c˜oes. Em resumo, as maiores contribui¸c˜oes s˜ao: 1) Combinar MDA com a Computa¸c˜ao em Nuvem; 2) Criar infraestrutura capaz de executar verifica¸c˜oes sobre as restri¸c˜oes presentes no modelo e 3) Gera¸ca˜o de c´odigo a partir de modelos KobrA2, uma especializa¸ca˜o da UML2.. 1.4. FORA DO ESCOPO. Algumas quest˜oes relacionadas a gera¸ca˜o de c´odigo est˜ao fora do escopo dessa pesquisa. Em parte, algumas j´a citadas anteriormente s˜ao alcan¸cadas por projetos correlatos a esse. Outras limita¸co˜es ocorrem devido ao escopo da gera¸c˜ao de c´odigo estar restrito a modelos KobrA2, por ora criados no WAKAME. Em resumo, as quest˜oes n˜ao diretamente abordadas: • Modelagem UML/KobrA2. O WAKAME ser´a utilizado na cria¸ca˜o dos modelos; • Gera¸ca˜o de c´odigo comportamental. Na solu¸ca˜o desenvolvida, o IOCLCompiler ser´a usado na gera¸c˜ao do corpo das opera¸c˜oes; • Gera¸ca˜o de GUI. Pretende-se usar o componente UIGenerator; • Gerar c´odigo de qualquer modelo de classes UML; A solu¸c˜ao ser´a validada apenas para modelos UML2/KobrA2; • Gerar c´odigo a partir de modelos exportados de qualquer ferramenta CASE UML. A valida¸ca˜o ser´a realizada apenas sobre modelos advindos do WAKAME; • Gerar c´odigo execut´avel de qualquer tipo de aplica¸ca˜o. A principio, ser˜ao alvos dos experimentos apenas solu¸co˜es que necessitem somente de opera¸co˜es de persistˆencia. Aplica¸co˜es que requerem servi¸cos mais espec´ıficos providos por bibliotecas n˜ao est˜ao sendo cobertas at´e a presente data deste documento;.
(25) ˜ 1.5 ESTRUTURA DA DISSERTAC ¸ AO. 6. Os quesitos sobre as limita¸co˜es de escopo de ferramenta, modelo e tipos de aplica¸c˜ao s˜ao encarados como trabalhos futuros a esse projeto.. 1.5. ˜ ESTRUTURA DA DISSERTAC ¸ AO. Esta disserta¸ca˜o est´a organizada nesta introdu¸ca˜o e mais 7 cap´ıtulos. O Cap´ıtulo 2 aborda os conceitos fundamentais sobre a Engenharia de Software dirigida por modelos. Ele tamb´em apresenta as vantagens e os desafios atuais da ado¸c˜ao dos modelos como artefatos centrais no desenvolvimento. Ainda no segundo cap´ıtulo os princ´ıpios e benef´ıcios da Computa¸ca˜o em Nuvem s˜ao introduzidos. O Cap´ıtulo 3 apresenta o contexto da solu¸c˜ao adotada neste trabalho: a metodologia KobrA2 e seus fundamentos, o projeto WAKAME e o framework KISF[dTM09][Mac09]. O Cap´ıtulo 4 descreve as t´ecnicas e abordagens utilizadas no desenvolvimento das transforma¸co˜es no StructuralGenerator. Nessa parte, tamb´em s˜ao abordadas caracter´ısticas das aplica¸c˜oes geradas. Ainda no quarto cap´ıtulo, s˜ao discutidas as motiva¸co˜es das escolhas realizadas no desenvolvimento deste projeto. O Cap´ıtulo 5 apresenta o PIM do StructuralGenerator seguindo a metodologia KobrA2, sua integra¸ca˜o com o WAKAME e os demais componentes de transforma¸c˜ao. No Cap´ıtulo 6, ´e feita a descri¸c˜ao, transforma¸c˜ao e a avalia¸ca˜o de dois experimentos para demonstrar a efic´acia da gera¸ca˜o de c´odigo. O Cap´ıtulo 7 traz a avalia¸c˜ao das ferramentas relacionadas e a compara¸ca˜o com trabalho desenvolvido. Por fim, no Cap´ıtulo 8, a conclus˜ao, onde s˜ao enumeradas as contribui¸c˜oes, limita¸co˜es e os trabalhos futuros..
(26) CAP´ITULO 2. DESENVOLVIMENTO ORIENTADO POR MODELOS E A ˜ EM NUVEM COMPUTAC ¸ AO. Este cap´ıtulo tem o objetivo de abordar os principais conceitos das a´reas que esta pesquisa est´a fundamentada. Ele inicia com a introdu¸ca˜o da abordagem que usa modelos como artefatos principais no processo da constru¸c˜ao de software, o MDE (Model Driven Engineering). Posteriormente, s˜ao abordados os conceitos e princ´ıpios do MDA(Model Driven Architecture), uma realiza¸ca˜o do MDE. Ainda ser˜ao discutidas as vantagens e os atuais desafios do MDA, muitos desses desafios atacados pelo projeto maior, no qual este trabalho est´a envolvido, apresentado no cap´ıtulo seguinte. Au ´ltima se¸c˜ao desse cap´ıtulo apresenta os principais conceitos e benef´ıcios da computa¸ca˜o em nuvem, cuja combina¸ca˜o com MDE pode trazer avan¸cos a produtividade e uma maior ado¸c˜ao das a abordagens dirigidas por modelos.. 2.1. ENGENHARIA DIRIGIDA POR MODELOS. Os softwares est˜ao se tornando cada vez mais complexos, clientes exigem funcionalidades cada vez mais sofisticadas, a serem entregues em prazos cada vez mais curtos. No entanto, apesar dos avan¸cos significativos das linguagens de programa¸ca˜o e dos ambientes de desenvolvimento (IDEs), a produ¸ca˜o de softwares complexos utilizando tecnologias centradas em c´odigo ainda ´e dif´ıcil e dispendiosa[FR07]. A Engenharia Dirigida por Modelos (Model-Driven Engineering- MDE) busca aumentar a produtividade no desenvolvimento de software e gerenciar a sua complexidade atrav´es do uso de modelos. O MDE aposta no aumento do n´ıvel de abstra¸ca˜o atrav´es da mudan¸ca do foco das atividades de programa¸ca˜o para o modelagem da solu¸c˜ao. Nessa abordagem, os modelos passam a ser artefatos prim´arios no processo de desenvolvimento. Define-se modelo como uma abstra¸c˜ao de uma parte, uma funcionalidade, um comportamento ou uma defini¸c˜ao do sistema que est´a sendo observado[FR07]. 4. http://www.iag.biz/. 7.
(27) 2.1 ENGENHARIA DIRIGIDA POR MODELOS. 8. Nos processos tradicionais, como o RUP (Rational Unifield Process)[Kru00], os modelos s˜ao usados apenas durante as fases iniciais dos projetos, tendo como principal objetivo auxiliar a comunica¸ca˜o entre os membros da equipe e os stakeholders 1 . Eles s˜ao usados na defini¸ca˜o dos conceitos e posteriormente na arquitetura do software[Lar04]. Por´em, no decorrer do projeto esses modelos caem em desuso e se tornam desatualizados conforme o software ´e modificado em rela¸ca˜o `a especifica¸ca˜o original. Mantˆe-los atualizados tem um custo alto, pois n˜ao representam artefatos ativos para o projeto no atual processo. Outro problema comum ´e que muitas vezes os modelos produzidos n˜ao s˜ao precisos e formais. H´a casos onde eles s˜ao criados em ferramentas de texto ou de apresenta¸c˜ao, com linguagem natural[KWB03]. Para utilizar o MDE efetivamente, combinando tecnologia e processo, ´e necess´ario um desenvolvimento centrado em modelos durante todas as fases do projeto. Logo, esses modelos devem especificar todo o dom´ınio da solu¸c˜ao, ser precisos e n˜ao amb´ıguos. Eles devem ser formais e descritos em uma linguagem bem definida sintaticamente. A fun¸ca˜o de especificar essa linguagem cabe a um metamodelo, cujo papel ´e definir a sintaxe, a forma como os elementos do modelo podem ser utilizados, sua estrutura e as restri¸co˜es entre eles. O cumprimento desses requisitos viabiliza que cada vez mais tarefas sejam automatizadas por ferramentas, uma vez que esses modelos passam a ser comput´aveis[Sch06]. Diversas ferramentas CASE(Computer-Aided Software Engineering) j´a est˜ao dispon´ıveis para a tarefa de criar modelos. As ferramentas CASE MDE auxiliam o desenvolvimento atrav´es da automatiza¸ca˜o de tarefas. A automa¸c˜ao acontece por meio das transforma¸c˜oes entre modelos e gera¸ca˜o dos artefatos de uma aplica¸ca˜o. Algumas ferramentas geram entre 60% e 80% do c´odigo e demais artefatos necess´arios a uma aplica¸c˜ao[SV06]. Esses n´ umeros s˜ao alcan¸cados em softwares com pouco c´odigo comportamental e sem complexidade algor´ıtmica, por exemplo apenas CRUDs2 . O objetivo da automa¸ca˜o ´e acelerar o desenvolvimento de software, manter sua qualidade, diminuir erros humanos e reduzir a quantidade de trabalho necess´ario para constru¸c˜ao e manuten¸ca˜o dos sistemas[KWB03].. Apesar dos objetivos e dos muitos avan¸cos, o MDE ainda n˜ao alcan¸cou sua plenitude. Na busca de uma melhor solu¸ca˜o, h´a uma discuss˜ao entre os que utilizam o MDE sobre como e quais linguagens e padr˜oes devem ser utilizados para atender seus requisitos e pretens˜oes. 1 2. Pessoas interessadas, envolvidas e de voz ativa no projeto Sigla das opera¸c˜ oes: Create,Read, Update e Delete.
(28) 2.1 ENGENHARIA DIRIGIDA POR MODELOS. 9. Uma vertente aposta nas linguagens espec´ıficas de dom´ınio (Domain Specific Language - DSL). As DSLs s˜ao linguagens simplificadas, de escopo limitado e especializado, que mapeiam diretamente os conceitos do dom´ınio abordado em seus elementos [MHS05]. Elas podem se apresentar de forma textual ou gr´afica. Essas linguagens buscam suprir poss´ıveis dificuldades que uma linguagem de prop´osito geral, como a UML, teria para expressar um determinado dom´ınio ou tecnologia. Sendo especializadas, elas s˜ao geralmente bem menores que os padr˜oes de prop´osito geral (por exemplo as especifica¸co˜es UML2 contˆem mais de mil p´aginas). Isso torna seu aprendizado mais r´apido. As DSLs frequentemente s˜ao definidas sobre metamodelos propriet´arios, e s˜ao voltadas para ferramentas e plataformas propriet´arias. A Microsoft ´e a maior defensora do uso de DSLs. Em contraste, no ano de 2001 a Object Management Group (OMG) criou o MDA(Model Driven Architecture)[OMG10f] como uma especializa¸c˜ao do MDE, apresentando um framework conceitual totalmente suportado por padr˜oes abertos. As caracter´ısticas principais dessa abordagem s˜ao: 1. Propor UML como linguagem visual de prop´osito geral para modelar PIMs e PSMs das aplica¸co˜es; 2. Propor MOF para como linguagem visual de prop´osito geral para modelar linguagens de modelagem (i.e., para metamodelar); 3. Propor OCL como linguagem de modelagem e metamodelagem textual complementar a ambos UML e MOF; 4. Propor QVT como linguagem de especifica¸ca˜o de transforma¸co˜es de modelos; 5. Reusar UML na defini¸c˜ao de MOF, reusar OCL na defini¸c˜ao de QVT; 6. Representar os modelos de forma serializada em XMI; 7. Definir UML, MOF, OCL e QVT em MOF, OCL e XMI; A IBM, por sua vez, ´e uma das empresas que suporta e defende todos esses padr˜oes e objetivos do MDA, oferecendo um conjunto de ferramentas[Bro04] para apoiar o m´etodo. Esta pesquisa, est´a na a´rea das transforma¸co˜es de modelo, focando na gera¸c˜ao de c´odigo estrutural. Esse trabalho aposta no MDA e apoia a metodologia KobrA2 que tenta contribuir nas deficiˆencias ainda presentes no uso dos modelos. No cap´ıtulo 3 est˜ao resumidos os conceitos do projeto KobrA2. Na pr´oxima se¸c˜ao ser˜ao definidos os principais conceitos, desafios e as necessidades do MDA..
(29) 2.2 MODEL DRIVEN ARCHITECTURE. 2.2. 10. MODEL DRIVEN ARCHITECTURE. Hoje, na ind´ ustria de software existe uma grande variedade de plataformas tecnol´ogicas, que devido `a sua r´apida evolu¸c˜ao tornam-se obsoletas ao longo do tempo. Com a constante evola¸ca˜o das tecnologias, as empresas, muitas vezes, ficam tentadas a a migrar seus sistemas para essas novas tecnologias. Seguindo metodologias de Engenharia de Software dirigidas por c´odigo (como XP) essa tarefa de migra¸c˜ao requer frequentemente a reimplementa¸c˜ao de todo o sistema. O custo dessas tarefas de evolu¸ca˜o e manuten¸ca˜o ´e alto, logo se torna proibitivo. O MDA ´e o componente central da OMG para solucionar o problema da complexidade do desenvolvimento, evolu¸ca˜o e manuten¸ca˜o de software. A principal caracter´ıstica do MDA ´e a separa¸ca˜o das funcionalidades do sistema das quest˜oes t´ecnicas da implementa¸c˜ao, mudando o enfoque do desenvolvimento para o design da aplica¸c˜ao. O MDE tamb´em se apoia no uso dos modelos, mas n˜ao apresenta qualquer distin¸c˜ao quanto a serem dependentes ou n˜ao de tecnologia. O MDA, por sua vez, especifica dois n´ıveis de modelo[OMG10f][KWB03]: ´ um • Modelo Independente de Plataforma (Platform Independent Model - PIM): E modelo independente das tecnologias da solu¸c˜ao, ele apresenta uma perspectiva do modelo de neg´ocio. Expressa as regras de neg´ocio e as funcionalidades do software j´a com alguns aspectos computacionais, como por exemplo, quest˜oes sobre persistˆencia, transa¸ca˜o e seguran¸ca. Entretanto, os detalhes espec´ıficos sobre a implementa¸c˜ao desses servi¸cos n˜ao est˜ao presentes. Transforma¸co˜es sobre esse modelo d˜ao origem ao pr´oximo n´ıvel, o PSM; • Modelo Dependente de plataforma (Platform Specific Model - PSM): Este incorpora a`s informa¸co˜es dos modelos anteriores os conceitos da plataforma alvo da implementa¸c˜ao. Um PSM deve ser completo o suficiente para que seja poss´ıvel a gera¸ca˜o de toda a aplica¸c˜ao na plataforma alvo atrav´es das transforma¸co˜es com gera¸ca˜o de c´odigo. Um detalhe importante ´e que um PIM pode dar origem a v´arios PSMs de plataformas diferentes. Independˆencia de plataforma ´e a qualidade de um modelo em abstrair as caracter´ısticas tecnol´ogicas de uma determinada plataforma. O significado do termo plataforma ´e relativo a um particular ponto de vista, ou seja, um PIM para um contexto pode.
(30) 2.2 MODEL DRIVEN ARCHITECTURE. 11. ser o PSM em outro. Assim o conceito plataforma tem muitos aspectos e a independˆencia ´e relativa a alguns uns e outros n˜ao[WJ05]. Uma observa¸ca˜o importante sobre a classifica¸ca˜o dos modelos, ´e que um PIM ou PSM em geral n˜ao ´e representado apenas por um diagrama, ele deve conter um conjunto de diagramas com diferentes vis˜oes dos diversos aspectos do software.. 2.2.1. ˜ UML e outros padroes da OMG. O final dos anos 90 foi marcado pelo surgimento da UML, que logo se tornou a linguagem de modelagem de software mais adotada desde ent˜ao. Desde sua cria¸ca˜o a UML evoluiu bastante, hoje se encontra na vers˜ao 2.3. A Figura 2.1 exibe a nova estrutura dos diagramas UML2. A especifica¸ca˜o da UML tamb´em ´e promovida pela OMG, e desde sua vers˜ao 2.0 ´e definida formalmente a partir de um metamodelo. Sua defini¸ca˜o mais precisa busca diminuir as ambiguidades das vers˜oes anteriores que se utilizavam em excesso de linguagem natural em suas especifica¸co˜es.. Figura 2.1: Taxonomia dos Diagramas UML2. Fonte: [OMG10d].. A OMG, com o objetivo de fornecer a sustentabilidade ao MDA, criou uma fam´ılia de padr˜oes relacionados `a UML. Os principais s˜ao o Metamodel Object Facility - MOF[OMG10c], XML Metadata Interchange - XMI[OMG10e], Query/View/Transformation - QVT[QVT09], Object Constraint Language - OCL[OMG10b] e a Imperative OCL..
(31) 2.2 MODEL DRIVEN ARCHITECTURE. 12. O Meta-Object Facility (MOF) ´e um padr˜ao OMG que define uma linguagem abstrata usada para descrever metamodelos. A UML, por exemplo, ´e definida em MOF. A importˆancia dessa linguagem est´a em prover a interoperabilidade dos modelos entre ferramentas MDA. Cada ferramenta pode ter sua pr´opria implementa¸c˜ao do MOF. Atualmente o padr˜ao est´a na vers˜ao 2.0. O XML Metadata Interchange (XMI) ´e um padr˜ao OMG que viabiliza o intercˆambio dos metadados dos modelos entre as ferramentas, reposit´orios e middleware que suportem o metamodelo MOF. No MDA, XMI ´e usado no intercˆambio de modelos UML entre ferramentas com a persistˆencia desses na forma textual em XML. O Query/View/Transformation (QVT) especifica uma linguagem de transforma¸ca˜o de modelos. Possui tanto construtores declarativos com as rela¸co˜es entre os metamodelos, como tamb´em imperativos para defini¸ca˜o algor´ıtmica das transforma¸c˜oes. A Object Constraint Language (OCL) ´e uma linguagem h´ıbrida, funcional e orientada a objetos. Ela ´e usada para definir restri¸co˜es e consultas sobre modelos UML e metamodelos MOF. Express˜oes OCL podem ser usadas para especificar invariantes sobre classes, pr´e e p´os condi¸c˜oes sobre opera¸co˜es, atributos derivados e definir o corpo das opera¸co˜es sem efeitos colaterais. Ela surgiu da necessidade da UML em n˜ao conseguir expressar restri¸co˜es entre elementos de um modelo de forma adequada e produtiva[WK03]. Uma extens˜ao denominada IOCL foi definida na especifica¸ca˜o QVT, com inclus˜ao de construtores imperativos a linguagem OCL. Todas essas especifica¸co˜es de padr˜oes buscam suprir a necessidade do MDA na cria¸c˜ao de modelos precisos e completos. A cria¸c˜ao das linguagens e modelos envolve n´ıveis de modelagem. Como dito anteriormente, a fun¸c˜ao de um metamodelo ´e definir a semˆantica de como os elementos podem ser instanciados na nova linguagem. Um metamodelo tamb´em precisa ser especificado por uma linguagem de cria¸ca˜o de metamodelos, essa linguagem ´e denominada como uma linguagem de meta-metamodelo[KWB03].. 2.2.2. N´ıveis de Modelos. A Figura 2.2 ilustra os diferentes n´ıveis na defini¸c˜ao de modelos. No n´ıvel M3 , o mais abstrato, encontra-se o meta-metamodelo MOF como uma instˆancia de si mesmo. O MOF descreve uma meta-metalinguagem abstrata, utilizada para descrever outras metalinguagens para diferentes dom´ınios e tamb´em descreve um reposit´orio de metadados para suportar metadados dos metamodelos baseados no pr´oprio meta-metamodelo MOF..
(32) 2.2 MODEL DRIVEN ARCHITECTURE. 13. A implementa¸c˜ao mais pr´oxima da especifica¸ca˜o MOF ´e o metamodelo Ecore do projeto Eclipse Modeling Framework (EMF)[EMF10], que tamb´em disponibiliza o metamodelo UML em Ecore. A maioria das ferramentas atuais, inclusive as utilizadas e constru´ıdas neste trabalho, usam essa implementa¸c˜ao. Os metamodelos no n´ıvel M2 , instˆancias do MOF, s˜ao criados de acordo com os requisitos de dom´ınio, por exemplo no dom´ınio O.O. o metamodelo UML. No dom´ınio de Data Warehouse (DW) e Business Intelligence (BI) a OMG criou o metamodelo CWM (Common Warehouse Metamodel). Linguagens espec´ıficas de dom´ınio (DSLs) devem ser criadas nesse n´ıvel.. Figura 2.2: N´ıveis de Modelo. Fonte: [KWB03].. No n´ıvel M1 est˜ao os modelos das aplica¸co˜es reais, possivelmente em UML, criados por alguma ferramenta. O exemplo da Figura 2.2 s˜ao classes: Customer e Order . Os modelos no n´ıvel M1 seguem as regras e s˜ao criados por meio dos elementos dos metamodelos M2 . No u ´ltimo n´ıvel, M0 , est˜ao as instˆancias das classes de um sistema em execu¸ca˜o. Por exemplo, as instˆancias Customer e Order na base da Figura 2.2..
(33) 2.2 MODEL DRIVEN ARCHITECTURE. 2.2.3. 14. ˜ de Modelos Transformac¸ao. A especifica¸c˜ao QVT tem a fun¸ca˜o de definir e difundir linguagens de transforma¸ca˜o de modelos. As transforma¸co˜es s˜ao fundamentais no uso efetivo de modelos com produtividade e reusabilidade. Elas deixam mais produtiva a separa¸ca˜o dos conceitos do dom´ınio, da parte t´ecnica de implementa¸ca˜o, promovendo assim uma abstra¸c˜ao no desenvolvimento da solu¸c˜ao. Uma aplica¸ca˜o pode ser constru´ıda a partir da defini¸ca˜o de um PIM e de uma sequˆencia de transforma¸co˜es[KWB03]. A Figura 2.3 apresenta uma sequˆencia com as transforma¸co˜es entre os n´ıveis de modelo MDA.. Figura 2.3: Transforma¸c˜ao PIM-PSM-C´odigo.. A Figura 2.3 mostra somente a transforma¸ca˜o entre n´ıveis adjacentes, no entanto, ´e poss´ıvel que um PIM seja transformado em um novo PIM mais detalhado, o mesmo em outros PSMs. Segundo a especifica¸c˜ao do MDA[OMG10f], tamb´em ´e poss´ıvel que um modelo PIM seja transformado diretamente em c´odigo. A abordagem direta ´e mais comum no MDE[SV06]. Em [CH03],[MCG05] e [Met05] s˜ao detalhados estudos sobre transforma¸co˜es e suas classifica¸co˜es. Uma transforma¸ca˜o define o mapeamento dos conceitos descritos em um modelo para o seu pr´oximo n´ıvel. No caso de uma transforma¸ca˜o PIM para PSM, s˜ao inseridas ´ informa¸co˜es, elementos e restri¸c˜oes necess´arias para uma determinada plataforma. E poss´ıvel existir, para o mesmo PIM, um ou mais PSMs, basta que seja aplicada uma transforma¸ca˜o espec´ıfica a cada especificidade tecnol´ogica[CH03]..
(34) 2.2 MODEL DRIVEN ARCHITECTURE. 2.2.4. 15. ˜ de Codigo ´ Gerac¸ao. A transforma¸c˜ao de modelo para texto(Model To Text) na gera¸c˜ao de uma grande quantidade do c´odigo, economiza tempo no processo de desenvolvimento e disponibiliza solu¸c˜oes mais rapidamente. Al´em disso, as transforma¸c˜oes incorporam padr˜oes de projeto[GHJV95] especificados no PIM, boas pr´aticas e o conhecimento de especialistas nas plataformas alvo, tornando poss´ıvel produzir c´odigo de qualidade padronizada[KWB03]. O MDA defende que seja poss´ıvel a completa gera¸c˜ao de uma aplica¸ca˜o, enquanto o MDE acredita que qualquer ganho proveniente dessa automatiza¸c˜ao seja sucesso. N˜ao ´e de hoje que geradores de c´odigo s˜ao usados para aumentar a qualidade e velocidade no desenvolvimento de software, antes mesmo do MDE/MDA e o uso dos modelos. A principal tarefa dos geradores tradicionais ´e criar as partes repetitivas do c´odigo. O uso das transforma¸c˜oes de modelos com a utiliza¸c˜ao do MDA busca ir mais al´em que os geradores tradicionais. Ele procura gerar uma aplica¸c˜ao execut´avel a partir dos modelos, atendendo a todos os aspectos presentes em um software, como o estrutural, operacional, GUI e testes[SV06]. As transforma¸co˜es para c´odigo sem o uso de modelos precisos est´a limitada as solu¸co˜es de problemas comuns em dom´ınios simples. Seu uso acaba restrito a aplica¸co˜es totalmente baseadas em bancos de dados, onde existe um grande n´ umero de formul´arios e artefatos similares entre as entidades de dom´ınio[Her03]. Usualmente as ferramentas de gera¸ca˜o est˜ao acopladas nas IDEs e geram c´odigo a partir de artefatos limitados na representa¸c˜ao de especificidade sobre dom´ınio do projeto. Os artefatos fontes para a transforma¸c˜ao s˜ao muitas vezes modelos de classes UML iniciais e incompletos, ou esquemas de banco de dados. Ambos possuem apenas uma representa¸ca˜o inicial e simplista da aplica¸ca˜o [KF08]. Com essa limita¸c˜ao nas fontes, a gera¸ca˜o acaba ficando restrita e muito trabalho manual ainda ´e necess´ario. Para obter mais benef´ıcios na ado¸ca˜o de geradores ´e necess´ario criar mais do que apenas o c´odigo fonte estrutural, ´e indispens´avel criar as opera¸co˜es, automatizar tarefas e criar outros artefatos como: scripts de build e deploy, testes unit´arios, dados para testes, scripts de banco de dados, etc. Invariantes, pr´e e p´os-condi¸c˜oes presentes no modelo tamb´em devem ser traduzidas para aplica¸c˜ao [CDE08]. A OMG criou uma especifica¸ca˜o para que a comunidade possa submeter propostas de linguagens para transforma¸ca˜o de modelos MOF em c´odigo, uma Request For Propose (RFP) para o MOF Model to Text Transformation[MOF08]. O objetivo ´e usar na.
(35) 2.2 MODEL DRIVEN ARCHITECTURE. 16. defini¸ca˜o das transforma¸co˜es uma linguagem que ofere¸ca f´acil manipula¸c˜ao de modelos baseados em MOF e simplicidade na gera¸c˜ao de textos e arquivos. A submiss˜ao com maior aceita¸ca˜o pela comunidade MDA ´e o MOFScript[MOF10b][ONG+ 05]. Hoje, o MOFScript ´e um projeto da Eclipse Foundation1 , dentro do subprojeto Generative Modeling Technologies (GMT), e al´em da linguagem baseada em templates, o projeto oferece uma IDE para o desenvolvimento das transforma¸co˜es. Outras implementa¸co˜es da especifica¸c˜ao s˜ao as linguagens dos projetos M2T e Acceleo, ambas, assim como o MOFScript, inseridas no arcabou¸co de projetos Eclipse Modeling1 . Algumas abordagens de transforma¸ca˜o de modelos em c´odigo s˜ao apresentadas no Cap´ıtulo 4, suas vantagens e desvantagens s˜ao exemplificadas com as experiˆencias deste trabalho.. 2.2.5. Vantagens e Desafios. Ap´os apresentar os principais conceitos do MDA e MDE, ser´a enumerado aqui uma breve lista de benef´ıcios e posteriormente alguns desafios atualmente presentes no MDA. Muitas dessas quest˜oes foram apresentadas em [GR10] e [dGI09]: Produtividade: No MDA, desenvolvedores est˜ao focados em modelos de alto n´ıvel, no PIM, ao inv´es de c´odigo. Detalhes espec´ıficos que costumam consumir o maior tempo no projeto s˜ao alcan¸cados via transforma¸c˜ao; Transforma¸c˜oes autom´aticas: Elas est˜ao presentes desde fases iniciais do projeto, cobrindo todas as fases do processo de desenvolvimento. A execu¸ca˜o deve ser provida por ferramentas e assim automatizar as tarefas antes realizada por desenvolvedores; Portabilidade e independˆencia de plataforma: Um PIM apresenta um modelo independente que pode vir a ser transformado em m´ ultiplos PSM para diferentes plataformas. Os desenvolvedores focam na cria¸ca˜o do PIM que posteriormente s˜ao transformados em PSM e c´odigo das mais diversas plataformas; Aumento do n´ıvel de abstra¸c˜ao: O MDA alcan¸ca esse objetivo atrav´es dos n´ıveis de modelo, uma vez que a defini¸ca˜o do PIM abstrai qualquer complexidade tecnol´ogica da solu¸ca˜o. 1 2. http://www.eclipse.org/org/ http://www.eclipse.org/modeling/.
(36) 2.2 MODEL DRIVEN ARCHITECTURE. 17. Aumento da manutenibilidade: Projetos sempre sofrem modifica¸co˜es durante seu tempo de vida. Refatora¸co˜es podem melhorar significativamente a qualidade de um software. As mudan¸cas do projeto no MDA s˜ao realizadas no modelo e transforma¸co˜es e n˜ao no c´odigo. Alterar apenas os modelos ´e uma tarefa menos dispendiosa que as altera¸co˜es em c´odigo. Na modifica¸ca˜o de uma transforma¸ca˜o s˜ao corrigidos v´arios artefatos gerados, enquanto que numa abordagem manual, a modifica¸ca˜o seria um a um; Reuso: As transforma¸c˜oes s˜ao artefatos altamente reus´aveis, j´a que devem ser de prop´osito geral e n˜ao para apenas um dom´ınio espec´ıfico. Abaixo fraquezas e desafios pertinentes ao MDA: Potencial desalinhamento entre os modelos: No MDA, um conceito pode ser apresentado em diferentes n´ıveis de abstra¸c˜ao e presente em diferentes vis˜oes. O fato dos modelos evolu´ırem gradualmente (PIM-PSM e PSM-c´odigo), torna a sincroniza¸ca˜o uma tarefa complexa e poss´ıvel causa de inconsistˆencias. Escassez de um processo espec´ıfico: O MDA n˜ao define ou provˆe um concreto processo de desenvolvimento. Sua especifica¸c˜ao define apenas alguns conceitos e diretrizes no uso de modelos nos projetos. Falta um preciso processo MDA de prop´osito geral que possa abranger todas as fases de um projeto e todas as disciplinas da Engenharia de Software. Essa ausˆencia pode resultar em projetos que desviam seu alinhamento com o MDA; Carˆencia nas ferramentas: O MDA exige ferramentas adequadas que suportem a constru¸ca˜o, valida¸c˜ao, transforma¸c˜ao, testes e debug nos modelos, al´em da gera¸ca˜o e deploy da aplica¸ca˜o alvo com tudo que foi especificado. Rastreabilidade e escalabilidade: Durante o processo de desenvolvimento MDA s˜ao gerados e transformados uma grande quantidade de vis˜oes, dessa forma s˜ao necess´arios meios que consigam facilitar a manipula¸ca˜o desse grande n´ umero de diagramas; Verifica¸c˜ao e valida¸c˜ao (V & V): Proporcionar suporte a gera¸ca˜o de casos de teste, valida¸c˜ao formal e verifica¸ca˜o de modelos ´e crucial, mas ´e uma tarefa dif´ıcil. V & V devem ser realizadas tanto nos modelos como na aplica¸c˜ao gerada. Acreditando nos benef´ıcios e com a miss˜ao de contribuir em alguns desafios apresentados, este trabalho foi desenvolvido como parte dos projetos KobrA2 e WAKAME, que.
(37) ˜ EM NUVEM 2.3 COMPUTAC ¸ AO. 18. s˜ao bem mais amplos e abordam algumas das quest˜oes apresentadas. Portanto, para um maior entendimento dessa disserta¸ca˜o, o pr´oximo cap´ıtulo descreve esses projetos e faz seu alinhamento com este trabalho. Antes, por´em, ser´a apresentado um paradigma no qual esse trabalho se apoia para facilitar a distribui¸c˜ao das solu¸c˜oes MDE.. 2.3. ˜ EM NUVEM COMPUTAC ¸ AO. Na Se¸ca˜o, 3.5 ser´a apresentado o projeto WAKAME que se apresenta como uma implementa¸c˜ao do conceito Modelagem como Servi¸co (Modeling as a Service - MaaS), introduzido por Bruneliere em [HBJ10]. A pesquisa dessa disserta¸ca˜o investe na Computa¸ca˜o em Nuvem para implanta¸c˜ao das aplica¸co˜es transformadas. Bruneliere acredita no MaaS como forma de expandir o uso do MDE entre desenvolvedores. Entre os principais motivos apontados por ele, destaca-se a capacidade da cria¸ca˜o de modelos colaborativos, compartilhados em tempo real por membros de uma equipe distribu´ıda. A seguir ser˜ao abordados os principais conceitos da Computa¸ca˜o em Nuvem, uma nova tendˆencia em solu¸co˜es de tecnologia.. 2.3.1. Princ´ıpios e Conceitos Relacionados. Em [YBDS08], o termo Computa¸ca˜o em Nuvem ´e definido como uma cole¸c˜ao de novos e antigos conceitos de algumas ´areas como Arquitetura Orientada a Servi¸cos (ServiceOriented Architecture - SOA), grids computacionais e virtualiza¸ca˜o. A computa¸ca˜o em nuvem pode ser considerada um novo paradigma computacional que permite aos usu´arios utilizar uma infraestrutura tempor´aria atrav´es da Internet. Atualmente, muitos modelos de neg´ocio evolu´ıram para aproveitar essa nova tendˆencia, disponibilizando aplica¸co˜es, plataformas de desenvolvimento, reposit´orios de dados e infraestrutura de hardware como servi¸cos. A Amazon, Microsoft e a Google despontam como as maiores investidoras nesse ramo que ganhou muito interesse devido ao seu enorme potencial e os avan¸cos das tecnologias na a´rea. O termo nuvem ´e uma met´afora baseada em como a internet ´e representada nos diagramas de redes de computadores, e como forma de abstra¸ca˜o para esconder uma infraestrutura complexa. Defini¸co˜es e classifica¸co˜es dessa a´rea s˜ao apresentados por Youseff em [YBDS08], fazendo sua avalia¸ca˜o a partir das solu¸co˜es j´a disponibilizadas pela ind´ ustria de software..
(38) ˜ EM NUVEM 2.3 COMPUTAC ¸ AO. 19. Ele divide os servi¸cos em nuvem em cinco n´ıveis: aplica¸ca˜o, ambiente, infraestrutura, kernel e hardware. Na parte inferior da pilha dessa classifica¸ca˜o, representada na Figura 2.4, est´a o n´ıvel de hardware que s˜ao componentes f´ısicos reais. Algumas empresas oferecem subloca¸c˜ao de sua infraestrutura de hardware como servi¸co. No topo, o n´ıvel de aplica¸ca˜o onde os usu´arios acessam softwares implantados em nuvem a partir dos seus navegadores. A seguir ser˜ao detalhados alguns conceitos, usos e vantagens em cada n´ıvel de servi¸cos.. Figura 2.4: Classifica¸c˜ ao de Servi¸cos em Nuvens. Fonte:[YBDS08].. Aplica¸c˜ao Esse ´e o n´ıvel vis´ıvel aos usu´arios finais por meio das aplica¸co˜es. O principio ´e fornecer Software como Servi¸co (SaaS), o usu´ario pagar´a apenas pelo uso do software e n˜ao por sua implanta¸c˜ao. Ou seja, ao inv´es de comprar o software que o usu´ario precisa, ele vai pagar para us´a-lo quando necess´ario. O termo ”pagar”aqui ´e abstrato, os servi¸cos prestados podem ser pagos ou n˜ao. Essas aplica¸c˜oes em geral s˜ao disponibilizadas na WEB, assim ao inv´es usu´ario ter que instalar e configurar o software, ele simplesmente pode acess´a-lo em navegador. Este modelo traz benef´ıcios favor´aveis tanto aos usu´arios como aos provedores das aplica¸co˜es que tem mais facilidade em disponibilizar suas solu¸co˜es. As Google Apps1 , o SalesForce CRM2 e Yahoo! Maps3 s˜ao exemplos de aplica¸c˜oes como servi¸co. 1. http://www.google.com/apps http://www.salesforce.com 3 http://maps.yahoo.com 2.
(39) ˜ EM NUVEM 2.3 COMPUTAC ¸ AO. 20. Ambiente Os usu´arios desse n´ıvel s˜ao desenvolvedores de aplica¸c˜oes implant´aveis nas nuvens. Essa camada fornece uma plataforma de desenvolvimento com um conjunto de APIs e servi¸cos para facilitar a integra¸c˜ao com as aplica¸c˜oes a serem desenvolvidas. O servi¸co prestado por esta camada ´e chamado de Plataforma como Servi¸co (PaaS). Desenvolvedores tˆem os benef´ıcios do dimensionamento autom´atico e balanceamento de carga, bem como a integra¸c˜ao com outros servi¸cos, por exemplo, autentica¸c˜ao, servi¸cos de e-mail e pain´eis com dados do uso da aplica¸ca˜o. Desta forma, grande parte da sobrecarga de desenvolvimento ´e aliviada com o reuso desses servi¸cos e configura¸co˜es. Um exemplo dessa categoria de sistema ´e o Google App Engine - GAE4 , que j´a fornece um ambiente para as tecnologias Java e Python. A GAE foi usada nessa pesquisa e ser´a um pouco mais detalhada na Subse¸c˜ao 2.3.3. Infraestrutura Uma nuvem de infraestrutura oferece os recursos fundamentais para as camadas de n´ıvel mais alto (aplica¸ca˜o e ambiente). Os servi¸cos fornecidos pela camada de infraestrutura podem ser classificados em duas categorias: recursos computacionais, reposit´orio. • Recursos Computacionais As m´aquinas virtuais s˜ao a forma mais comum de fornecer recursos computacionais nessa categoria, com elas os usu´arios tˆem flexibilidade para customizar seus recursos na busca de uma melhor performance e eficiˆencia. Esse tipo de servi¸co ´e identificado por infraestrutura como servi¸co (IaaS). Os recentes avan¸cos na virtualiza¸c˜ao dos sistemas operacionais fizeram do conceito de IaaS ser plaus´ıvel. O Amazon’s Elastic Compute Cloud 21 ´e o exemplo mais popular desa forma de servi¸co. • Reposit´orio Os reposit´orios em nuvem permitem aos usu´arios armazenar dados remotamente e acess´a-los de qualquer lugar. Esse servi¸co ´e comumente chamado de data-storage como servi¸co (DaaS). Esses reposit´orios, assim como os convencionais, devem atender todos os requisitos de disponibilidade, confiabilidade, 4 21. code.google.com/appengine http://aws.amazon.com/ec2/.
Documentos relacionados
Se você vai para o mundo da fantasia e não está consciente de que está lá, você está se alienando da realidade (fugindo da realidade), você não está no aqui e
De seguida, vamos adaptar a nossa demonstrac¸ ˜ao da f ´ormula de M ¨untz, partindo de outras transformadas aritm ´eticas diferentes da transformada de M ¨obius, para dedu-
Promovido pelo Sindifisco Nacio- nal em parceria com o Mosap (Mo- vimento Nacional de Aposentados e Pensionistas), o Encontro ocorreu no dia 20 de março, data em que também
A disposição dos componentes do equipamento faz com que não só o feixe primário, mas também os raios X característicos resultantes passem através da amostra,
O desenvolvimento das interações entre os próprios alunos e entre estes e as professoras, juntamente com o reconhecimento da singularidade dos conhecimentos
UM ESTUDO DA HISTÓRIA AFRICANA ANTIGA REVELA UMA ANTERIOR DEFINIÇÃO AFRICANA DO SISTEMA DE MELANINA HUMANA COMO UM [INTEIRO] SANTO CORPO PRETO [HOLY BLACK BODY
Serpentine, alstonine et sempervirine, medicaments inhibant specifiquement les cellules cancéreuses et tumorales.. The African species of Strychnos.Part.II .The
Apesar da longa distância dos grandes centros urbanos do país, Bonito destaca- se, regionalmente, como uma área promissora dentro do Estado de Mato Grosso do Sul. Bonito,
