Abordagem dirigida a modelos para implantação automática de software em nuvem

Texto

(1)UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. Abordagem Dirigida a Modelos para Implantação Automática de Software em Nuvem. Franklin Magalhães Ribeiro Junior. SÃO CRISTÓVÃO/ SE 2015.

(2) UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. Franklin Magalhães Ribeiro Junior. Abordagem Dirigida a Modelos para Implantação Automática de Software em Nuvem. Dissertação apresentada ao Programa de PósGraduação em Ciência da Computação (PROCC) da Universidade Federal de Sergipe (UFS) como parte de requisito para obtenção do título de Mestre em Ciência da Computação.. Orientador: Prof. Dr. Tarcísio da Rocha. SÃO CRISTÓVÃO/ SE 2015.

(3) FICHA CATALOGRÁFICA ELABORADA PELA BIBLIOTECA CENTRAL UNIVERSIDADE FEDERAL DE SERGIPE. R484a. Ribeiro Junior, Franklin Magalhães Abordagem dirigida a modelos para implantação automática de software em nuvem / Franklin Magalhães Ribeiro Junior ; orientador Tarcísio da Rocha. – Aracaju, 2015. 126 f. : il. Dissertação (mestrado em Ciência Universidade Federal de Sergipe, 2014.. da. Computação)–. 1. Computação. 2. Linguagem de programação (Computadores). 3. Desdobramento da função qualidade. I. Rocha, Tarcísio da, orient. II. Título. CDU 004.43.

(4) Franklin Magalhães Ribeiro Junior. Abordagem Dirigida a Modelos para Implantação Automática de Software em Nuvem. Dissertação apresentada ao Programa de PósGraduação em Ciência da Computação (PROCC) da Universidade Federal de Sergipe (UFS) como parte de requisito para obtenção do título de Mestre em Ciência da Computação.. BANCA EXAMINADORA. Prof. Dr. Tarcísio da Rocha, Presidente Universidade Federal de Sergipe (UFS). Prof. Dr. Edward David Moreno, Membro Universidade Federal de Sergipe (UFS). Prof. Dr. Edmundo Roberto Mauro Madeira, Membro Universidade Estadual de Campinas (UNICAMP).

(5) Abordagem Dirigida a Modelos para Implantação Automática de Software em Nuvem. Este exemplar corresponde à redação da Dissertação de Mestrado, sendo a Defesa do mestrando Franklin Magalhães Ribeiro Junior para ser aprovada pela Banca examinadora.. São Cristóvão - SE, 05 de Janeiro de 2015. ______________________________________ Prof. Dr. Tarcísio da Rocha Orientador. ______________________________________ Prof. Dr. Edward David Moreno Membro. ______________________________________ Prof. Dr. Edmundo Roberto Mauro Madeira Membro.

(6) Dedicatória Esse trabalho é dedicado a minha família, em especial aos meus pais, Franklin e Luciana e aos meus avôs, Valentina, Marivaldo, Marlene e Ribeiro (in memoriam).. i.

(7) Agradecimentos Aos meus pais, Franklin e Luciana por estarem sempre presentes em todos os momentos, felizes e tristes, de derrota e de vitória, pelo carinho, apoio e confiança. Aos meus familiares, em especial às minhas irmãs, Larissa e Karoline e aos meus avôs, pelos momentos de felicidade e energia positiva. Aos meus amigos, em destaque a Thiago, Renan e Harry pelo companheirismo e momentos de descontração, e à Danila, pelo carinho, preocupação e por fazer parte dessa conquista. Ao professor Dr. Tarcísio, pela oportunidade e dedicação em todo o caminho deste trabalho. Aos professores do PROCC da UFS, pela motivação ao longo do mestrado, em especial a Edward, Ricardo e Rogério. Por fim, a todos aqueles com quem convivi durante esse período de novos caminhos.. ii.

(8) "A vida é uma sequência de encontros inéditos com o mundo, e portanto ela não se deixa traduzir em fórmulas de nenhuma espécie". (Clóvis de Barros). iii.

(9) Resumo A computação em nuvem oferece recursos para reduzir os custos computacionais nas instituições que utilizam recursos de hardware e software através da virtualização, além da entrega de software como serviço. Existem mecanismos automáticos para implantação de software em provedores de nuvem, no entanto, demandam codificação ou requerem conhecimento aprofundado do desenvolvedor acerca da tecnologia específica do provedor de nuvem, sobretudo da reconstrução de vários requisitos, já que ambientes em nuvem possuem arquiteturas de software próprias. Nesta pesquisa foi apresentada uma abordagem baseada em modelos para implantação automática de software no ambiente em nuvem. Foi apresentada uma breve revisão da literatura sobre as propostas existentes para implantação automática de software na nuvem. Foram analisadas as propostas, onde cinco mecanismos de implantação baseiam-se em script ou linguagem de programação, duas propostas utilizaram em mecanismos manuais e duas propostas aplicaram uma abordagem baseada em modelos para implantação de software na nuvem, no entanto ainda fortemente ligadas a aspectos manuais e de modelagem complexa, uma vez que requer do desenvolvedor a compreensão da arquitetura do provedor de nuvem. Esta investigação apresenta uma nova solução com arquitetura detalhada, casos de uso, fluxo de dados e visão conceitual de uma abordagem dirigida a modelos para implantação de software automática na nuvem. Nesta pesquisa também foi realizado um experimento onde a solução apresentou impactos positivos em manutenibilidade, apreensibilidade e na redução na carga de trabalho do desenvolvedor para implantar serviços de software na nuvem por meio de diagramas de implantação UML como entrada. Palavras-Chave- Computação em Nuvem, Deployment, Implantação Automática. iv.

(10) Abstract Cloud computing offers resources to reduce the computational costs in the institutions that uses hardware and software resources through virtualization, in addition the delivery of software as a service. There are mechanisms for automated software deployment in cloud providers, however it requires encoding or extensive knowledge for developer on the cloud provider specific technology, particularly the various requirements reconstruction, because cloud environments have their own software architectures. In this research was presented a model-based approach to automatic software deployment in the cloud environment. We presented a brief review of literature, with existing proposals for automated software deployment in cloud. In analyzed solutions, we found five that presents deployment mechanisms are script or programming language based, two proposals used manual mechanisms and two proposals applied the model-based approach to software deployment in the cloud, however still strongly linked to manual aspects and complex modeling, because it requires the developer to understand the cloud provider architecture. This research presents a new solution with detailed architecture, use cases, data flow and conceptual view of a model-based approach to automatic software deployment in the cloud. In this research was also conducted an experiment, where the solution presented positive impacts in maintainability, learn-ability and reduction of developer’s workload to deploy software services in the cloud, using UML deployment diagrams as input. Keywords- Cloud Computing, Deployment, Automatic Deployment. v.

(11) Lista de Figuras 2.1. Modelos de Entrega de Serviços da Nuvem. . . . . . . . . . . . . . . . . .. 5. 2.2. Camada de Virtualização (KSC.NET, 2013). . . . . . . . . . . . . . . . . .. 6. 2.3. Níveis de aprovisionamento de serviços na nuvem (LOPEZ, 2011). . . . . .. 7. 2.4. Aprovisionamento de recursos da nuvem por tempo (ARMBRUST, 2010). .. 9. 3.1. Arquitetura da Proposta (CALA; WATSON, 2010). . . . . . . . . . . . . .. 15. 3.2. Exemplo de Configuração para Deployment do Wrangler (JUVE; DEELMAN, 2011). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 18. 3.3. Arquitetura do Wrangler (JUVE; DEELMAN, 2011). . . . . . . . . . . . .. 19. 3.4. Arquitetura do Wrangler (ZHANG; LI; ZHENG, 2013). . . . . . . . . . . .. 21. 3.5. Modelos de Implantação Virtual (KONSTANTINOU, 2009). . . . . . . . .. 22. 3.6. Representação do MODAClouds (). . . . . . . . . . . . . . . . . . . . . . .. 24. 3.7. Mecanismos de Implantação (TALWAR; MILOJICIC; WU, 2005). . . . . .. 24. 4.1. Exemplo de Modelo Geral da Solução. . . . . . . . . . . . . . . . . . . . .. 31. 4.2. Exemplo de Modelo Específico da Solução. . . . . . . . . . . . . . . . . .. 32. 4.3. Exemplo de Modelo Geral com N Máquinas Virtuais e N Aplicações. . . .. 33. 4.4. Caso de Uso da Solução. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 34. 4.5. Arquitetura da Solução. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 36. 4.6. Diagrama de Atividades - Gerar Implantação Automática de Software. . . .. 38. 4.7. Exemplo de Identificação de Atributos no Modelo Geral - Módulo Associador. 39. 4.8. Diagrama de Atividades Interpretar Modelo Geral. . . . . . . . . . . . . .. 40. 4.9. Diagrama de Atividades Interpretar Modelo Específico. . . . . . . . . . . .. 41. 4.10 Diagrama de Atividades Criar Pilha de Software. . . . . . . . . . . . . . .. 42. vi.

(12) 4.11 Exemplo de Obtenção das Coordenadas (X,Y) para Artefatos e Envoltória dos Nós . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 42. 4.12 Atividades de criação e ordenação de SubListas de Artefatos. . . . . . . . .. 43. 4.13 Módulo Alocador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 44. 4.14 Diagrama de Atividades Gerar Código da Implantação - Módulo Preparador.. 45. 4.15 Visão Conceitual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 47. 5.1. Representação visual de um Nó UML. . . . . . . . . . . . . . . . . . . . .. 49. 5.2. Script correspondente ao Nó da Figura 5.1. . . . . . . . . . . . . . . . . .. 49. 5.3. Exemplo de Representação visual de um artefato UML (Serviço). . . . . .. 50. 5.4. Script correspondente ao artefato (Serviço 1) da Figura 5.3. . . . . . . . . .. 50. 5.5. Representação visual da associação entre dois Nós. . . . . . . . . . . . . .. 51. 5.6. Script correspondente ao componente Associação da Figura 5.5. . . . . . .. 52. 5.7. Script correspondente aos componentes Associação e Nós da Figura 5.5. . .. 52. 5.8. Representação de uma dependência UML entre Nós. . . . . . . . . . . . .. 53. 5.9. Script correspondente aos componentes Dependência e os Nós da Figura 5.8.. 53. 5.10 Script correspondente aos Nós da Figura 5.8. . . . . . . . . . . . . . . . .. 54. 5.11 Exemplo das coordenadas dos Nós (representação visual). . . . . . . . . .. 55. 5.12 Exemplo do componente Part de String Sistema Operacional (representação visual). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 56. 5.13 Script correspondente à Figura 5.12. . . . . . . . . . . . . . . . . . . . . .. 56. 5.14 Ilustração do Algoritmo no Código Fonte 5.8. . . . . . . . . . . . . . . . .. 67. 5.15 Ilustração do Algoritmo no Código Fonte 5.10. . . . . . . . . . . . . . . .. 71. 5.16 Criação de Sublistas de Serviços pelo Intervalo do eixo X. . . . . . . . . .. 71. 5.17 Exemplo da Estrutura Lógica do Grafo de Serviços. . . . . . . . . . . . . .. 73. 5.18 Modelo Geral para a Implantação do e-commerce 14-commerce-loja-virtual.. 81. 5.19 Modelo Específico para a Implantação do e-commerce 14-commerce-lojavirtual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 82. 6.1. Gráfico de Médias das Métricas com e sem uso da Solução. . . . . . . . . .. 95. 6.2. Gráfico do Impacto nas Métricas com o uso da Solução. . . . . . . . . . . .. 96. vii.

(13) Lista de Tabelas 3.1. Mecanismos de Implantação das Propostas. . . . . . . . . . . . . . . . . .. 25. 3.2. Ferramentas CASE de Licença Gratuita. . . . . . . . . . . . . . . . . . . .. 27. 3.3. Características dos Arquivos de Saída das Ferramentas CASE. . . . . . . .. 28. 6.1. Tabela referente as perguntas do Escopo 1 . . . . . . . . . . . . . . . . . .. 93. 6.2. Tabela referente as perguntas do Escopo 2 . . . . . . . . . . . . . . . . . .. 93. 6.3. Escopo 3 Resultado da Solução Proposta. . . . . . . . . . . . . . . . . . .. 94. 6.4. Resultado com uso da Solução Proposta. . . . . . . . . . . . . . . . . . . .. 94. 6.5. Resultado SEM a Solução Proposta. . . . . . . . . . . . . . . . . . . . . .. 95. viii.

(14) Lista de Siglas API - Application Programming Interface AWS - Amazon Web Services CASE - Computer-Aided Software Engineering DDoS - Distributed Denial of Service IaaS - Infrastructure as a Service IDE - Integrated Development Environment MDA - Model-Driven Architecture OMG - Object Management Group PaaS - Platform as a Service SaaS - Software as a Service UML - Unified Modeling Language VM - Virtual Machine XML - Extensible Markup Language. ix.

(15) Sumário 1. 2. Introdução. 1. 1.1. Objetivos do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.2. Contribuições da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.3. Organização da Proposta de Dissertação . . . . . . . . . . . . . . . . . . .. 3. Fundamentação Teórica. 4. 2.1. Computação em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. 2.1.1. Camadas de Serviços na Nuvem . . . . . . . . . . . . . . . . . . .. 5. 2.1.2. Categorias de Nuvem . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 2.1.3. Implantação de Software na Nuvem . . . . . . . . . . . . . . . . .. 9. Desenvolvimento de Software Dirigido a Modelos . . . . . . . . . . . . . .. 10. 2.2.1. UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 12. 2.2.2. Ferramentas CASE . . . . . . . . . . . . . . . . . . . . . . . . . .. 13. 2.2. 3. Trabalhos Correlatos. 14. 3.1. D&C Based Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . .. 14. 3.2. SDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 16. 3.3. Wrangler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 17. 3.4. Disnix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 19. 3.5. Vega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 20. 3.6. User-Level Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 20. 3.7. Virtual Deployment Models . . . . . . . . . . . . . . . . . . . . . . . . .. 22. 3.8. MODAClouds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 23. 3.9. Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 23. x.

(16) 4. 5. 3.10 Análise das Ferramentas CASE . . . . . . . . . . . . . . . . . . . . . . . .. 26. Solução: AeroModelos. 29. 4.1. Visão Geral da Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 29. 4.2. Definição dos Modelos de Implantação de Software na Nuvem . . . . . . .. 31. 4.3. Casos de Uso da Solução . . . . . . . . . . . . . . . . . . . . . . . . . . .. 33. 4.4. Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 35. 4.4.1. Fluxo Geral do Sistema . . . . . . . . . . . . . . . . . . . . . . . .. 36. 4.4.2. Módulo Associador . . . . . . . . . . . . . . . . . . . . . . . . . .. 39. 4.4.3. Módulo Empilhador . . . . . . . . . . . . . . . . . . . . . . . . .. 40. 4.4.4. Módulo Alocador . . . . . . . . . . . . . . . . . . . . . . . . . . .. 43. 4.4.5. Módulo Preparador . . . . . . . . . . . . . . . . . . . . . . . . . .. 44. 4.4.6. Visão Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . .. 45. Implementação da Proposta. 48. 5.1. Interpretação dos Componentes UML . . . . . . . . . . . . . . . . . . . .. 48. 5.1.1. Interpretação de Nós . . . . . . . . . . . . . . . . . . . . . . . . .. 49. 5.1.2. Interpretação de Artefatos (Serviços) . . . . . . . . . . . . . . . .. 50. 5.1.3. Interpretação de Associações . . . . . . . . . . . . . . . . . . . . .. 51. 5.1.4. Interpretação de Dependências . . . . . . . . . . . . . . . . . . . .. 52. 5.1.5. Interpretação dos Artefatos contidos em um Nó . . . . . . . . . . .. 53. 5.1.6. Interpretação dos componentes Part UML . . . . . . . . . . . . . .. 56. Implementação do Módulo Associador . . . . . . . . . . . . . . . . . . . .. 57. 5.2.1. Leitura dos Arquivos de Entrada - Modelos Geral e Específico . . .. 58. 5.2.2. Método Ler - Modelo Geral . . . . . . . . . . . . . . . . . . . . .. 63. 5.2.3. Método Ler - Modelo Específico . . . . . . . . . . . . . . . . . . .. 65. Implementação do Módulo Empilhador . . . . . . . . . . . . . . . . . . .. 66. 5.3.1. Relacionamento de Dependências com Serviços (Artefatos) . . . .. 66. 5.3.2. Relacionamento de Máquinas Virtuais com Serviços . . . . . . . .. 68. 5.3.3. Criação da Pilha de Software . . . . . . . . . . . . . . . . . . . . .. 72. Implementação do Módulo Alocador . . . . . . . . . . . . . . . . . . . . .. 74. 5.4.1. 75. 5.2. 5.3. 5.4. Correlação dos Atributos "‘PartUML"’ com os Nós . . . . . . . . . xi.

(17) 5.5. 5.6 6. 7. 5.4.2. Separação de Listas de Nós em Listas de Objetos por Categorias . .. 5.4.3. Relacionamento de Provedores de Nuvem e Instâncias de VM com. 75. Máquinas Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . .. 77. Implementação do Módulo Preparador . . . . . . . . . . . . . . . . . . . .. 79. 5.5.1. Geração do Código do Arquivo Executável de Implantação . . . . .. 79. 5.5.2. Geração do Código das Regras da Aplicação e dos Serviços . . . .. 80. Estudo de Caso da Solução . . . . . . . . . . . . . . . . . . . . . . . . . .. 81. Experimentação da Solução. 83. 6.1. Formulação de Hipóteses . . . . . . . . . . . . . . . . . . . . . . . . . . .. 85. 6.2. Operação do Experimento . . . . . . . . . . . . . . . . . . . . . . . . . .. 87. 6.2.1. Instrumentação para o Experimento . . . . . . . . . . . . . . . . .. 91. 6.2.2. Preparação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 91. 6.2.3. Execução do Experimento . . . . . . . . . . . . . . . . . . . . . .. 92. 6.2.4. Resultados e Análise . . . . . . . . . . . . . . . . . . . . . . . . .. 92. Conclusão. 97. Referências. 98. A. 104. xii.

(18) Capítulo 1 Introdução Os recursos trazidos pela computação em nuvem reduzem os custos computacionais provenientes da necessidade de processamento de uma alta demanda de dados (CALA, 2010). Atualmente os recursos da nuvem se aplicam em soluções que compreendem diversas áreas do conhecimento, como por exemplo, a astronomia e a biologia. Pela necessidade no aumento da demanda de soluções para a ciência e para o mercado, os sistemas de software tornaram-se complexos. Hoje, sistemas críticos e complexos encontrados nas áreas da saúde, transportes, energia, segurança, dentre outras, já são uma realidade (BOEHM, 2011). Atualmente, considera-se vantajosa a execução destes sistemas em nuvem, já que a nuvem provê a distribuição do processamento e maior capacidade de armazenamento de serviços e aplicações, pontos fortes para a redução dos custos em TI (CHIEU, 2010). A nuvem também utiliza o conceito de virtualização para aprovisionamento dinâmico de recursos de hardware, assim a execução de uma aplicação ou serviço utiliza apenas os recursos físicos da nuvem sob demanda, evitando o desperdício de processamento. Além da redução dos custos de infraestrutura, a computação em nuvem possui uma abordagem baseada na entrega de serviços, onde o cliente pode requisitar um serviço de software no provedor de nuvem, implantado pelo fornecedor do serviço ou implantar o seu próprio serviço de software na nuvem. Entretanto, implantar um sistema de software em um ambiente na nuvem requer a reconstrução de vários requisitos existentes, já que ambientes em nuvem possuem arquiteturas de software próprias (CALA; WATSON, 2010), como é o caso de, por exemplo, a Azure Cloud (MICROSOFT COPORATION, 2013) e do AWS (AMAZON, 2013). 1.

(19) 1.1 Objetivos do Trabalho. 2. Ademais, em sistemas onde o desenvolvimento é bastante custoso, o estabelecimento de uma abordagem de implantação automática de serviços e aplicações na nuvem, que reduz a carga de trabalho aos desenvolvedores é vantajosa. Por isso, nesta pesquisa foi desenvolvida e experimentada uma solução de implantação automática de software na nuvem dirigida à modelos nomeada de AeroModelos, cujo o uso de modelos na solução de implantação apresenta impactos positivos sobre as métricas de carga de trabalho, manutenibilidade, apreensibilidade e consistência com o código.. 1.1. Objetivos do Trabalho. Esta pesquisa tem como objetivo propor uma solução para automatizar a implantação de software na nuvem em alto nível de abstração. Objetivos Específicos No âmbito de atender o objetivo geral, nesta pesquisa será realizada: • Especificação e definição da arquitetura do software para a solução dirigida a modelos UML de implantação automática de software na nuvem; • A definição e concepção dos modelos de implantação de software na nuvem; • O desenvolvimento de uma solução dirigida a modelos UML para a implantação automática de software na nuvem;. 1.2. Contribuições da Dissertação. As principais contribuições deste trabalho consistem na: • Conceituação da solução de implantação automática de software dirigida a modelos na nuvem, no âmbito de elevar o nível de abstração do desenvolvedor (fornecedor de serviços de software da nuvem), que reduz a carga de trabalho para a implantação do software; • Definição de modelos de implantação de software em nuvem; • Disponibilização da implementação e código fonte utilizado na elaboração da solução;.

(20) 1.3 Organização da Proposta de Dissertação. 3. • O compartilhamento da solução de implantação automática de software dirigida a modelos na nuvem com a comunidade científica para trabalhos futuros; Publicações RIBEIRO JUNIOR, F. M.; DA ROCHA, T. Model-Based Approach to Automatic Software Deployment in Cloud. Proceedings in 4th International Conference on Cloud Computing and Services Science. CLOSER 2014, Barcelona, Spain, 2014 D.O.I.: http://dx.doi.org/10.5220/0004941601510157.. 1.3. Organização da Proposta de Dissertação. O trabalho está organizado da seguinte maneira: o capítulo 2 apresenta a fundamentação teórica, o capítulo 3 descreve os trabalhos correlatos ao tema de implantação automática de software na nuvem, o capítulo 4 explana a arquitetura e visão geral da solução de implantação automática de software em nuvem dirigida a modelos (nomeada de AeroModelos), o capítulo 5 relata a implementação dos módulos da arquitetura da solução, o capítulo 6 apresenta um experimento afim de verificar o desempenho da solução e, finalmente, o capítulo 7 apresenta a conclusão e trabalhos futuros..

(21) Capítulo 2 Fundamentação Teórica Esta seção explana detalhadamente os principais conceitos teóricos acerca da computação em nuvem e do desenvolvimento de software dirigido a modelos, assim como uma breve introdução a definição de implantação de software na nuvem para maiores esclarecimentos desta investigação.. 2.1. Computação em Nuvem. Com infraestrutura baseada no compartilhamento de recursos de hardware e de software através da virtualização, a computação em nuvem faz um misto entre conceitos de computação em grade, computação distribuída e virtualização (KALAGIAKOS; KARAMPELAS, 2011). A computação em nuvem usa a virtualização como meio de utilizar recursos (do hardware) dos servidores sob demanda para execução de aplicações, com possibilidade de escalar os processos das aplicações. Os recursos físicos (de hardware) da nuvem estão distribuídos em servidores de alto poder de processamento, onde cada máquina da nuvem é denominada nó. Dentre os servidores em nuvem existentes podem-se destacar alguns, como o Amazon EC2 (AMAZON, 2013), IBM Research Cloud (IBM, 2013) e Azure Cloud (MICROSOFT COPORATION, 2013). A computação em nuvem representa um conjunto de modelos baseados na entrega de serviços (SAVU, 2011) e é comumente dividida em três camadas de aprovisionamento de serviços (SALAPURA, 2012), (MALATHI, 2011), são eles: software como um serviço (Software as a Service - SaaS), plataforma como um serviço (Plataform as a Service - PaaS) e infra4.

(22) 2.1 Computação em Nuvem. 5. estrutura como um serviço (Infrastructure as a Service - IaaS).. 2.1.1. Camadas de Serviços na Nuvem. As camadas de serviços que compõem a nuvem (SaaS, PaaS e IaaS) estão intrinsecamente relacionadas de maneira hierárquica. Como pode ser observado na Figura 2.1 a camada IaaS suporta a PaaS que por sua vez, suporta a SaaS.. Figura 2.1: Modelos de Entrega de Serviços da Nuvem. O SaaS corresponde um dos serviços de mais alto nível da nuvem, onde nesta camada o provedor fornece a aplicação para o usuário suportada pelas camadas inferiores (IaaS e PaaS), cuja aplicação pode ser distribuída para vários nós da nuvem. Um exemplo de SaaS é o aplicativo Office 365 (MICROSOFT, 2013), onde o cliente pode usufruir dos recursos do Pacote Office da Microsoft através da infraestrutura da nuvem. Na nuvem, a camada PaaS constitui em uma API (Application Programming Interface), ou seja, os serviços fornecidos por esta camada correspondem a interfaces programáveis para suportar serviços em nível de aplicação (da camada SaaS). Com o PaaS, o desenvolvimento de aplicações web torna-se mais veloz (LV, 2010), isto porque o desenvolvedor obtêm suporte de programação PaaS para desenvolver as suas aplicações, por exemplo, a Google App Engine (GOOGLE, 2013), que oferece um serviço em nível PaaS para que o usuário desenvolva suas aplicações na nuvem do Google. Na computação em nuvem, na camada IaaS, os recursos do hardware são gerenciados por uma camada de virtualização, que fica entre a camada física da nuvem e a de aplicação (PaaS e SaaS), com isto uma aplicação na nuvem pode requisitar determinados recursos do hardware através das máquinas virtuais (GOMES, 2012)..

(23) 2.1 Computação em Nuvem. 6. Como a virtualização abstrai a camada física da nuvem, para a computação em nuvem é possível que os recursos do hardware sejam fornecidos sob demanda (MUTHUNAGAI; KARTHIC; SUJATHA, 2012), por exemplo, suponha a execução de uma aplicação na nuvem: sem a virtualização esta aplicação ocuparia todos os recursos físicos do nó (máquina) em que está sendo executada, porém com a virtualização, apenas (uma parte dos) os recursos essenciais para a aplicação serão disponibilizados para uso pela mesma. Na Figura 2.2 pode ser percebida a tecnologia de virtualização, que contêm no nível mais baixo, a infraestrutura de rede (servidores, rede e banco de dados), em uma camada acima a camada da virtualização, seguida por três máquinas virtuais (VM), onde para cada VM está encapsulada uma aplicação e o sistema operacional.. Figura 2.2: Camada de Virtualização (KSC.NET, 2013). Devido ao aprovisionamento dinâmico de recursos, a computação em nuvem é escalável, ou seja, um cliente dos serviços da nuvem pode executar vários processos em larga escala, pois a computação em nuvem provê o processamento distribuído com recursos sob demanda para cada um destes processos. Na camada IaaS, além da gerência e utilização dos recursos do hardware sob demanda, da distribuição, da enorme capacidade de processamento e armazenamento, o cliente do ambiente na nuvem não precisa se preocupar com a manutenção da infraestrutura oferecida pela nuvem. Esta responsabilidade é do fornecedor do serviço da nuvem. Como pode ser percebido na Figura 2.3, a computação em nuvem apresenta redução significativa para os custos de TI (MARSTON, 2011), onde o usuário pode usufruir de cada.

(24) 2.1 Computação em Nuvem. 7. nível de serviço (IaaS, PaaS e SaaS) fornecido pelo provedor da nuvem sem atentar-se aos detalhes das camadas de serviços abaixo de seu serviço utilizado.. Figura 2.3: Níveis de aprovisionamento de serviços na nuvem (LOPEZ, 2011). Ademais, além da divisão da nuvem sob a perspectiva de modelos de entrega de serviço, tais quais o SaaS, PaaS e IaaS. Estima-se que a quantidade de modelos de serviços na nuvem aumentará, pois conceitos como, por exemplo, armazenamento como serviço (Storage as a Service) e área de trabalho virtual como serviço (Virtual Desktop as a Service) poderão ser adotados para a computação em nuvem como modelos de serviço (DUDIN; SMETANIN, 2011).. 2.1.2. Categorias de Nuvem. A nuvem também está dividida em categorias, como nuvem pública, privada, híbrida e comunitária (SANCHEZ; CAPPELLOZZA, 2012), cada uma com diferentes características, (cada tipo mais adequado para soluções específicas) a fim de atender as necessidades do usuário. A nuvem privada geralmente é projetada para fornecer serviços a uma organização. Nessa categoria de nuvem, o fator segurança comumente é maior que em nuvens públicas, já que o uso de seus serviços é restrito para a empresa que a mantêm. Em contrapartida a.

(25) 2.1 Computação em Nuvem. 8. organização deve arcar com as despesas de infraestrutura física e gerenciamento da nuvem (IYOOB; ZARIFOGLU; DIEKER, 2013), (MALATHI, 2011). Na nuvem pública os serviços são fornecidos para vários usuários espalhados pelo globo, por isso a nuvem pública possui maior capacidade de processamento e armazenamento que a nuvem privada, embora esteja mais suscetível a ataques distribuídos de negação de serviço (RIMAL, 2011). Ademais, na nuvem híbrida contém parte dos dados de uma organização numa nuvem pública e outra parte numa nuvem privada (por questões de segurança). Já a nuvem comunitária dispõe o compartilhamento de sua infrestrutura entre diversas organizações de interesses em comum. Devido ao aprovisionamento de serviços a computação em nuvem também é vantajosa no ponto de vista da economia de: • Energia elétrica: pois a eletricidade é consumida apenas pelos componentes de hardware das máquinas que estão sendo executadas para determinada aplicação; • Processamento: devido à virtualização, que objetiva a destinação de determinado recurso de hardware a uma aplicação (ARMSTRONG, 2011), ou seja, o aprovisionamento dinâmico dos recursos do hardware; • Mercado: por adotar o lema pay as you go, referente a utilização de recursos sob demanda, onde o usuário dos recursos de nuvem apenas paga pelo nó que está sendo utilizado e pela quantidade de tempo de execução da aplicação naquele nó (GOMES, 2012). Além de ser financeiramente econômica pelo consumo de recursos sob demanda (pay as you go), a computação em nuvem é também mais veloz pela sua escalabilidade (MARSTON, 2011), já que, por exemplo, a utilização de 1000 servidores por uma hora não custa mais que utilizar um servidor em 1000 horas (ARMBRUST, 2010). Ademais, por possuir recursos físicos com grande poder de processamento, a nuvem também suporta grandes demandas, estando sempre disponível, mesmo em épocas sazonais em que pode haver um pico na demanda pelos recursos da nuvem além do esperado. A nuvem também evita o desperdício de recursos disponíveis, mesmo em momentos que não há picos na demanda por esses recursos. Essa adaptação dos recursos disponíveis na.

(26) 2.1 Computação em Nuvem. 9. nuvem pode ser observada na Figura 2.4.. Figura 2.4: Aprovisionamento de recursos da nuvem por tempo (ARMBRUST, 2010).. 2.1.3. Implantação de Software na Nuvem. Para que o software execute corretamente numa arquitetura em nuvem, faz-se necessário a implantação deste e(ou) dos demais serviços que este software depende na nuvem, cujos serviços são compostos ou tratados como componentes. A OMG, (2006) define o processo de implantação de componentes em etapas como: • Instalação: que armazena pacotes de software em um repositório de controle; • Configuração: cuja função primária consta em configurar o repositório, para que parte da aplicação seja executada; • Planejamento: que provê um plano de implantação para decidir qual parte da aplicação será executada; • A preparação: que decide onde o software será executado; • Lançamento: cujo papel é de conectar as instâncias dos componentes a fim de executar o software como todo. Uma maneira mais eficiente da implantação de software em ambientes em nuvem é a automatização desse processo, já que detalhes dispensáveis de configuração poderiam ser abstraídos, além de reduzir a carga de esforço humano na implantação de software. Ademais, a implantação automática de software na nuvem é vantajosa, devido à eliminação de tarefas manuais como: a configuração da pilha de software, a autenticação entre.

(27) 2.2 Desenvolvimento de Software Dirigido a Modelos. 10. máquinas virtuais, a definição das dependências dos componentes de serviço e entre os serviços, a definição das dependências temporais e espaciais e finalmente, a análise dos recursos disponíveis nos ambientes em nuvem, a fim de identificar se o nó na nuvem atende os requisitos mínimos de determinado serviço (KONSTANTINOU, 2009). Dentre as características mais importantes na implantação automática em nuvem, destacam-se o uso de: • Coordenadores: que gerenciam uma pilha de software (CALA; WATSON, 2010); • Pilha de Software: contém serviços que suportam uma aplicação; • Máquina Virtual (VM): onde os serviços da pilha de software executam para suportar a aplicação (ARMSTRONG, 2011) e • Nós clientes: que encapsulam a VM (JUVE; DEELMAN, 2011).. 2.2. Desenvolvimento de Software Dirigido a Modelos. Atualmente, há uma crescente dependência dos sistemas pelo software, como o sistema: bancário, de saúde, transporte, comunicação, dentre outros (BOEHM, 2011). Para que um determinado software seja desenvolvido, os requisitos devem estar claros aos engenheiros de software (PRESSMAN, 2006). Porém, este entendimento é normalmente de alta complexidade, a qual dificulta a análise e o desenvolvimento do software elaborado. Em software, a redução da complexidade, custo e tempo de desenvolvimento são desafios. O desenvolvimento de software dirigido a modelos promete lidar com estes desafios, pois visa à redução na carga do esforço humano do desenvolvedor durante o ciclo de vida do software. O desenvolvimento de software dirigido a modelos lida melhor com a complexidade do software, pois mesmo que o uso das linguagens de programação e scripts na construção do software expresse o comportamento e o domínio em que está inserida a sua solução, o poder de abstração para um determinado problema pela linguagem de programação ou por scripts é menor que a abstração oferecida pelo uso de modelos, já que os modelos possuem representatividade visual da solução e independem de limitações por parte das tecnologias de codificação atual..

(28) 2.2 Desenvolvimento de Software Dirigido a Modelos. 11. Além da redução nos esforços humanos na codificação, por estar em um nível de abstração maior, o uso do desenvolvimento de software dirigido por modelos aumenta a qualidade do código gerado pelos modelos e reduz os possíveis erros de codificação (FAZZIKI, 2012) e por conseguinte, os custos. Na elaboração do software, a abstração da solução de um problema está fortemente ligada à modelagem do sistema, por isso, sobretudo no escopo do desenvolvimento dirigido a modelos, é necessário aos engenheiros de software verificar a consistência da solução proposta pelo software com relação aos modelos, como por exemplo, a correlação do domínio da solução do software com a quantidade de detalhes contidos nos modelos (CHOW, 2010). Como não há uma métrica para caracterizar quantitativamente o nível de abstração necessário em um modelo, a abstração em demasia na modelagem do sistema pode ser um problema, já que na análise de código dirigida a modelos, o valor dos modelos é reforçado quando há correspondência ao código (JACKSON; RINARD, 2000). Um dos fatores atrelados ao desenvolvimento pelo uso dos modelos consiste na tradução dos modelos em linhas de código (algoritmo), por isso, uma das barreiras do desenvolvimento dirigido por modelos é a fidelidade da tradução dos modelos para com o algoritmo gerado, ou seja, a correspondência da solução do problema expresso no modelo com a mesma solução representada pelo código gerado pelo modelo. Por muitas vezes, em sua criação, os modelos ocultarem detalhes essenciais e requisitos do sistema, sobretudo modelos relacionados à realização de uma sequência de tarefas, no desenvolvimento dirigido a modelos é comum o abuso na chamada decomposição funcional dos modelos (FOWLER, 1998), onde muitas vezes os modelos são abstraídos a ponto de dificultar a compreensão dos mesmos, quando na verdade esta compreensão deveria ser simples e concreta (FOWLER, 1998). Por isso, uma das questões de pesquisa em desenvolvimento de software dirigido a modelos está ligada a como este tipo de desenvolvimento pode lidar com a lacuna do domínio do problema com relação ao domínio da implementação do software através de técnicas de modelagem (FRANCE; RUMPE, 2007). Uma maneira de lidar com essas lacunas é a divisão dos modelos em diferentes ângulos do sistema, como a visão física, conceitual, de processos, fluxo de controle, fluxo de dados, representação dos objetos, dentre outros. Onde estas várias perspectivas em visões de um.

(29) 2.2 Desenvolvimento de Software Dirigido a Modelos. 12. sistema pode ser uma solução de parte dos problemas de complexidade do software (LAND, 2002). Para melhor definir essas diversas visões de um sistema, pode-se destacar a representação visual destas visões através de modelos de software. Para isto, pode-se referenciar uma das mais conhecidas e utilizadas linguagens para modelagem de sistemas de software pela comunidade, a UML, Unified Modeling Language (OMG, 2006).. 2.2.1. UML. Como mencionado, os modelos independem das diversas tecnologias de linguagens de programação e possuem como uma das vantagens para a modelagem na criação de sistemas de software uma possível universalização de modelos geradores de código, ou seja, o uso dos modelos de software com uma língua-franca (HAILPERN; TARR, 2006) para o desenvolvimento de software. Na modelagem de sistemas de software, pode-se destacar o padrão Unified Modeling Language (UML), elaborado e especificado pelo Object Management Group (OMG, 2006), por ser um padrão largamente conhecido e utilizado pelos engenheiros de software no mundo. A UML foi aprovada como padrão de modelagem de sistemas em 1997 e muitas vezes, é citada como a língua franca do desenvolvimento de software dirigido a modelos (LINK, 2008). Na tentativa de abstrair a solução do software e ao mesmo tempo manter a correspondência do código com a modelagem, os modelos de software apresentsdam dois tipos de categorias, dentre elas, a categoria de modelos pelo viés conceitual do software e os modelos relacionados à execução do software (FRANCE; RUMPE, 2007). Dentre os modelos relacionados ao desenvolvimento do software, destacam-se os modelos atrelados aos requisitos do software, à arquitetura do software e o modelo de implantação. Com relação aos modelos referentes à execução do software, pode se destacar, por exemplo, o diagrama de objetos da UML. A UML possui vários diagramas, onde cada diagrama corresponde a uma descrição do sistema em perspectivas diferentes (DAN; DANNING, 2011) em alto nível de abstração. Entre os tipos de diagramas destacam-se o diagrama de classes, que representa uma visão do sistema pelo ponto de vista dos objetos, o diagrama de atividades que corresponde ao fluxo.

(30) 2.2 Desenvolvimento de Software Dirigido a Modelos. 13. das atividades realizadas no sistema, o diagrama de estados que abstrai o comportamento dos objetos e o diagrama de implantação, que descreve como deve ocorrer a interação dos componentes físicos e lógicos do sistema, entre outros.. 2.2.2. Ferramentas CASE. A criação dos modelos para softwares de grande escala e complexidade pode ainda tornar-se árdua se feito manualmente. Por isso, no âmbito de auxiliar o desenvolvimento de sistemas de software, sobretudo na criação dos modelos a fim de abstrair o funcionamento do software e seus requisitos (ZAPATA; CHAVERRA, 2010), foram propostas ferramentas classificadas como Computer-aided software engineering (CASE). As ferramentas CASE, auxiliam as tarefas da engenharia de software e na etapa de criação dos modelos de software, caracterizam-se como Upper CASE, pois lidam com o planejamento do software em nível conceitual, ou seja, em mais alto nível de abstração. Dentre ferramentas caracterizadas como Upper CASE, pode-se citar algumas como, ArgoUML((COLLABNET INC, 2013)), StarUML((PLASTIC SOFTWARE, 2013)), UmbrelloUML((KDE, 2013))e VioletUML((VIOLET. . . , 2013)). Todas estas apresentam uma tradução de seus modelos em metalinguagens, como por exemplo, o eXtensible Markup Language (XML), um facilitador no desenvolvimento de software dirigido a modelos, pela interpretação do modelo visual em uma metalinguagem textual (e essencial na geração de código). Contudo, somente a tradução do modelo visual à metalinguagem (gerada pelas ferramentas Upper CASE) é ainda insuficiente para a geração de código pelo desenvolvimento dirigido por modelos, uma vez que não há tradução direta do modelo visual para uma linguagem de programação, onde se pressupõe que o software já esteja pronto para ser executado e totalmente funcional de acordo com os requisitos especificados..

(31) Capítulo 3 Trabalhos Correlatos Nesta pesquisa, após realizada uma investigação bibliográfica acerca das abordagens de implantação automática de software em nuvem, foram encontrados e selecionados os trabalhos de (CALA; WATSON, 2010), (CHIEU, 2010), (JUVE; DEELMAN, 2011), (KONSTANTINOU, 2009), (LI, 2012), (BURG, 2009) e (ZHANG; LI; ZHENG, 2013), onde em cada proposta foi descrita e explanada nesta seção, no âmbito de analisar cada investigação relacionada.. 3.1. D&C Based Deployment. Em seu trabalho, Cala e Watson (2010) apresentaram uma plataforma de implantação automática em nuvem, baseada no Deployment and Configuration of Component-based Applications Specfication (D&C) (OMG, 2006). O trabalho foi impulsionado pela necessidade de execução de uma aplicação que analisa a estrutura química de um fármaco, o QSAR, utilizada por um sistema multi-agente, chamado de Discovery Bus. Tendo em vista que, a arquitetura de fluxo do QSAR utiliza algoritmos de exploração exaustiva para decifrar estruturas químicas e que essa exploração exaustiva demanda grande carga de processamento, o software foi implantado em nuvem para redução dos custos de processamento. No âmbito de implantar o Discovery Bus no Azure Cloud, os autores perceberam que havia incompatibilidade da linguagem de programação do software e do ambiente em nuvem, o que impossibilitou a criação dos componentes do Discovery Bus na nuvem. A arquitetura da proposta foi estruturada com quatro elementos, dentre os quais, o Controller, Queue Storage (fila de serviços), 14.

(32) 3.1 D&C Based Deployment. 15. Deployer Engine e Blob Storage, como podem ser percebidos na Figura 3.1.. Figura 3.1: Arquitetura da Proposta (CALA; WATSON, 2010). O processo para a implantação funciona da seguinte forma: através do Controller (controlador) são definidos os planos de implantação (nestes planos são definidas as dependências e configuração para cada aplicação) que mais tarde serão enfileirados em uma fila de armazenamento de serviços. Depois de criada a fila de serviços de software, cada serviço é enviado a um módulo Deployer Engine para que seja realizada a implantação de software na nuvem, como especificado previamente pelo plano de implantação, o qual define a instalação e plataforma de execução do software. Além disso, um plano de implantação, definido por Cala e Watson (2010) também pode ter dependências de outros planos de implantação, ou seja, pode depender de outras aplicações para ser suportado (tal como uma plataforma de software). Para lidar com a dependência de outros softwares, os planos de implantação relacionamse uns com os outros de acordo com o tipo de dependência. Para a dependência do plano de implantação em nível de sistema em que ocorrerá a execução do software, existe a dependência por meio do OSLibrary Deployer, que permite acesso para solicitar pacotes de software a planos em níveis superiores ao seu, assim como também é possível a dependência com uma plataforma de software em outro plano de implantação, onde os dois tipos de dependências herdam uma interface definida como IDeployer, a qual possui operações de instalação, desinstalação, ativação e desativação do software que esta especificado pelo plano de implantação. Finalmente, os pesquisadores definiram um nível de virtualização de processo ligados.

(33) 3.2 SDO. 16. ao OSLibrary Deployer, que define restrições temporais e espaciais, a fim de permitir a busca de um plano de implantação que melhor se adéqüe à implantação de um determinado componente de software, como por exemplo: Componentes baseados em Java, devem ser preferencialmente implantados em nós que possuam o JRE.. 3.2. SDO. Em sua pesquisa, Li et al. (2012) propuseram a implantação de software em um ambiente na nuvem e satisfizeram a implantação de serviços em uma gama de cenários, como o cenário de nuvens privadas, bursted clouds, federated cloud, multi-cloud e brokering cloud. Os autores explanaram os diferentes cenários de implantação em nuvem, onde, para todos eles, foi denominado o provedor de nuvem como provedor de infraestrutura (IP), que oferece recursos que podem ser usados por um provedor de serviços (SP), onde o SP oferece aos clientes a possibilidade de implantar serviços na nuvem. Para a implantação em nuvem, a abordagem apresentou alguns passos dentre os quais: • A descoberta de provedores de infraestrutura: onde se devem identificar os provedores de nuvem disponíveis para a implantação; • A filtragem dos provedores de infraestrutura (IP): para verificar se o provedor de nuvem atende os requisitos desejados pela aplicação; • A negociação e otimização da implantação: onde um SP deve ser capaz de negociar a disponibilidade dos provedores de nuvem para um serviço, já que nem sempre é desejável implantar o serviço em um mesmo provedor de nuvem; • A contextualização do serviço: para instalar uma aplicação em uma VM com a pilha de software e o S.O. já instalados; • O upload do serviço para a nuvem e • A Service Level Agreement (SLA), cujo serviço deve operar de acordo com as expectativas do SP..

(34) 3.3 Wrangler. 17. A fim de executar os passos descritos, os autores propuseram uma arquitetura para atender os requisitos da implantação de software, a qual foi nomeada de Service Deploy Optimizer (SDO), a qual implanta os componentes dos serviços a diferentes provedores de nuvem. Os autores validaram a arquitetura proposta usando o OPTIMUS toolkit que inclui um conjunto de componentes independentes, com recursos IP e SP. Cujo estudo de verificação foi realizado em três cenários de implantação em nuvem, o de nuvem privada, brokering cloud e bursting cloud. Por fim, concluíram que maior parte do tempo de implantação depende do cenário da nuvem.. 3.3. Wrangler. Em sua pesquisa Juve e Deelman (2011), descreveram e avaliaram um sistema chamado Wrangler, que objetiva a implantação de aplicações em um provedor na nuvem. Para realização da implantação de software na nuvem, o Wrangler possui como entrada um documento XML com as configurações da implantação na nuvem, como pode ser observado na Figura 3.2, onde cada nó define as características atribuídas ao uso de recursos do hardware. Após as configurações do nó, o Wrangler envia o documento XML a um serviço web que gerencia o provisionamento de máquinas virtuais (VMs) e interage com diferentes provedores de nuvem, como por exemplo, o Amazon EC2, Eucaliptus e openNebula. Os autores descreveram como requisitos funcionais do Wrangler: • O provisionamento dinâmico, o qual deve atender aos requisitos que mudam com o tempo, permitindo que o usuário adicione ou remova nós (VM) em tempo de execução; • A configuração das dependências dos serviços, tanto para a pilha de software, como para o caso de aplicações distribuídas; • A capacidade de implantação em vários provedores em nuvem; • O monitoramento da implantação, para o caso de ocorrência de erros. Para atender os requisitos funcionais, a arquitetura da proposta utilizou quatro conceitos: clientes, coordenador, agentes e plugins (como pode ser percebido na Figura 3.3):.

(35) 3.3 Wrangler. 18. Figura 3.2: Exemplo de Configuração para Deployment do Wrangler (JUVE; DEELMAN, 2011). • Os clientes executam nas máquinas de cada usuário e enviam solicitações aos coordenadores para lançar, consultar e finalizar implantações. • O coordenador é o serviço web que gerencia implantações, ele aceita solicitações dos clientes e requisita provisões aos provedores de nuvem, além de coletar informações sobre o estado da implantação. • O agente deve ser pré-instalado na VM e é responsável pela coleta de informações sobre o provedor. • Os plugins são scripts que através do agente implementam o comportamento da VM, ou seja, um plugin serve como entrada para reconfiguração de uma VM. Por fim, os autores descrevem que um dos pontos fortes do Wrangler é a segurança da comunicação entre os componentes do sistema, cujo algoritmo SSL é utilizado para dar suporte à mesma..

(36) 19. 3.4 Disnix. Figura 3.3: Arquitetura do Wrangler (JUVE; DEELMAN, 2011).. 3.4. Disnix. Objetivando a homogeneidade do acesso a serviços apenas encontrados em dispositivos físicos de um hospital ligados a redes de topologias complexas e de diferentes políticas de segurança, como aparelhos de ressonância magnética, computadores, entre outros, (BURG, 2009) propuseram uma arquitetura para aplicações, em que os componentes de software são automaticamente implantados na nuvem, com uso de um modelo de declarativo chamado Nix e o Disnix (como extensão do Nix). Os autores utilizaram a proposta em um protótipo de sistema médico, o SDS2, o qual foi projetado como um aplicativo composto por um grande conjunto de componentes (serviços), cujos serviços apresentavam restrição de não poderem ser executados em uma mesma máquina e executados em uma nuvem privada. O Nix, utilizado na abordagem, constrói pacotes de descrição funcional e executa uma ação de compilação, já o Disnix, extensão do Nix, suporta operações de implantação distribuída. O mesmo contem uma interface que permite que outro processo ou usuário acesse o Nix remotamente. Para implantar serviços, o Disnix usa três modelos, o modelo de serviços, de infra-estrutura e de distribuição. O modelo de serviços descreve os serviços que podem ser distribuídos através dos computadores em rede, onde cada serviço é tratado como um pacote, que possuiu ou não interdependências descritas. O modelo de infra-estrutura (modelo para o gerenciamento da nuvem privada) é uma expressão Nix que especifica as máquinas.

(37) 3.5 Vega. 20. disponíveis na nuvem. Por fim, o modelo de distribuição é uma expressão Nix, que liga modelos de serviços a de infraestrutura, mapeando os serviços aos computadores. Finalmente, para garantir a confiabilidade da implantação de aplicações, os autores propuseram artifícios em sua proposta que garantiam que versões mais antigas de serviços (softwares) já implantados na nuvem não afetassem as novas versões do mesmo serviço (em outras palavras, há um controle de versões na implantação de software).. 3.5. Vega. Em suas pesquisas, Chieu et al. propuseram um framework noemado de Vega, o qual foi implementado para a nuvem IBM Research Compute Cloud e objetiva a especificação dos requisitos da solução de implantação de software na nuvem usando XML. No Vega existe uma biblioteca nomeada de Image Library, onde cada imagem compõe aplicações e especificações da solução de implantação (bem como as configurações de hardware que uma imagem irá utilizar), onde essas imagens da biblioteca são utilizadas para compor uma VM. Os autores relatam que o framework apresentado provê mecanismos que possibilitam aos administradores configurar as dependências entre as VMs e entre as aplicações (pilha de software). O Vega também gerencia recursos do hardware (configurações da máquina utilizada na nuvem) e de rede (hosts e políticas de segurança). Finalmente os autores afirmam que essa técnica possui uma falha, pois não funciona bem em cenários muito complexos, já que os comandos de configuração precisam ser coordenados entre diferentes VMs.. 3.6. User-Level Deployment. No âmbito de desacoplar o software da VM, os autores Zhang, Li e Zheng (2013) desenvolveram um framework para implantação de aplicações em nuvem, cuja ideia visa a redução do tempo e gastos com implantação. Esta proposta difere das demais abordagens apresentadas até o momento, pois nesta proposta o software não estaria pré-instalado em uma imagem de VM. No artigo, os autores apontaram problemas existentes nas abordagens utilizadas para implantação em nuvem, como o problema de sobrecarga de armazenamento, cujas imagens.

(38) 3.6 User-Level Deployment. 21. de VM deveriam ser previamente configuradas com um sistema operacional (S.O.), além de problemas como o exemplificado a seguir: suponha que existam duas aplicações A e B pré-instaladas cada uma em diferentes imagens de VM (imagem com aplicação A e imagem com aplicação B), as quais devem trabalhar em conjunto (ou seja, essas imagens deveriam ser instaladas em uma terceira VM), mas para isso o provedor deve criar uma nova VM. Porém, a necessidade de criar novas VMs para a combinação de aplicações gera um custo muito alto. Para resolver os problemas apontados pelos autores, eles apresentaram um mecanismo de isolamento em nível de usuário para isolar a aplicação da VM e do sistema operacional. A solução consiste em prover um servidor central de distribuição para fornecer software sob demanda às VMs, ao invés de uma VM conter um software previamente instalado. Os autores apresentam o framework e dividem sua funcionalidade em três etapas, (i) a de preparação do software, em que o cliente armazena o software em um repositório; (ii) a seleção do software, que permite ao cliente a escolha do software no repositório, e (iii) a implantação do software escolhido para executar remotamente em uma VM na nuvem, onde esta VM na nuvem troca informações com a VM que contem o sistema operacional instalado no lado cliente, conforme a Figura 3.4.. Figura 3.4: Arquitetura do Wrangler (ZHANG; LI; ZHENG, 2013). Ou seja, a VM (que conterá o software) é inicializada pelo servidor e nela é instalado o software que o cliente escolheu do repositório. O software escolhido seria transmitido por uma sequência de bits para uma VM local (que contém o SO instalado) com sobreposição de execução, que permitiria que não fossem alocadas várias VMs e, por sua vez, a não espera do carregamento de uma imagem de VM inteira para executar o software. Finalmente os autores fizeram um protótipo da proposta, onde foram implantadas dez aplicações e perceberam que.

(39) 3.7 Virtual Deployment Models. 22. o sistema sofre perda de desempenho, pela carga de transferência de dados ao cliente.. 3.7. Virtual Deployment Models. Em Konstantinou et al. (2009) apresentaram uma arquitetura que suporta a implantação de software dirigida a modelos, a técnica mostra quatro fases, tais quais a fase de criação de imagens virtuais (Virtual Appliance), o modelo de solução virtual (VSM), o modelo de solução virtual de implantação (VSDM) e o plano de implantação virtual da solução (VSDP). Konstantinou, et al. (2009) também explanaram as quatro fases da sua proposta, em (i) consta a atuação dos usuários denominados especialistas de domínio, os quais constroem aplicações virtuais implementadas em imagens virtuais pré-configuradas, (ii) o VSM que descreve os requisitos da implantação e a configuração da rede, (iii) a VSDM, que deve agregar as configurações de uma nuvem específica para que possa seguir a (iv) um plano de implantação (VSDP), que pode ser executado pelo usuário, conforme a Figura 3.5.. Figura 3.5: Modelos de Implantação Virtual (KONSTANTINOU, 2009). Devido ao plano de implantação (VSDP) operar em dois níveis, um de controle das VMs e outro de configuração da pilha de software, a complexidade nessa abordagem foi reduzida, já que foram abstraídos aspectos como problema de versão de software e compatibilidade do software com a nuvem. Finalmente os autores projetaram um protótipo da solução, com uso de XML para viabilizar a comunicação entre as imagens de VM e a abordagem dirigida a.

(40) 3.8 MODAClouds. 23. modelos, com a representação dos pacotes da aplicação virtual em open virtualization format (OVF).. 3.8. MODAClouds. Na pesquisa em Ardagna (2012) e European Commission (2014) foi apresentado o projeto MODAClouds que ainda está sendo desenvolvido com auxílio da European Commission como uma abordagem dirigida a modelos para o design e execução de aplicações em diferentes tecnologias de nuvens. A arquitetura do MODAClouds foi dividida em dois escopos o design da implantação do software e o monitoramento da execução do software na nuvem (quanto ao QoS). O primeiro escopo abarca o uso de uma IDE (própria do MODAClouds), onde através dela o usuário pode definir três níveis, cada um constituído por vários modelos (ALMEIDA, 2013) para implantação de software na nuvem: (i) o nível de modelos onde são detalhados as restrições, o modelo de requisitos do negócio da aplicação, o modelo de dados e o modelo de comportamento do serviço, nomeado de (CIM), (ii) o nível dos modelos cujos artefatos são representados de acordo com cada serviço definido em (CIM) e independentes da tecnologia da nuvem, nomeado de (CPIM) e (iii) o nível dos modelos específicos para o provedor de nuvem de acordo com cada componente em (CPIM), nomeado de (CPSM). Uma visão geral do funcionamento do MODAClouds pode ser percebida na Figura 3.6. Os autores também relatam que o MODAClouds também é capaz de lidar com software legado, uma vez que é dividido por níveis de modelos (CIM, CPIM e CPSM), onde por exemplo para a tarefa de troca de um provedor de nuvem para outro seria apenas necessário a mudança no nível CPSM. Apesar do alto nível de abstração para a implantação do software na nuvem, parte do nível CPSM deve ser parcialmente implementado (em código) para que seja realizada a implantação na nuvem, além de exigir do desenvolvedor certo conhecimento da tecnologia da nuvem em que se deseja implantar o software.. 3.9. Discussão. Com o objetivo de descobrir e analisar os mecanismos utilizados por soluções relacionadas à implantação automática de software na nuvem foram selecionadas algumas características.

(41) 24. 3.9 Discussão. Figura 3.6: Representação do MODAClouds (). relevantes das propostas apresentadas no estado da arte. Talwar, Milojicic e Wu (2005) discutiram os mecanismos existentes para implantação de serviços, como mecanismos de implantação manual, por meio de scripts, linguagens de programação e baseado em modelos. Os autores perceberam que mecanismos de linguagem de programação e abordagem dirigida a modelos lidam melhor com os custos, porém, aumentam a complexidade da solução, como pode ser percebido na Figura 3.7.. Figura 3.7: Mecanismos de Implantação (TALWAR; MILOJICIC; WU, 2005). Dentre os trabalhos relacionados, percebeu-se que o mecanismo Virtual Mo-.

(42) 25. 3.9 Discussão Propostas Manual MODAClouds Disnix X Virtual Models X Vega D&C Based Wrangler SDO UserLevel Solução da Pesquisa (AeroModelos). Script Linguagem Dirigido a Modelos Modelos Simples X X X X X X X X X X X X. Tabela 3.1: Mecanismos de Implantação das Propostas. dels(KONSTANTINOU, 2009) e MODAClouds(ARDAGNA, 2012) apresentam uma abordagem por implantação de software dirigido a modelos e com geração de código, como pode ser percebido na Tabela 3.1. Além disso, percebeu-se que D&C Based(CALA; WATSON, 2010) apresentou alguns modelos para a implantação, porém apenas para restrições no processo de implantação e não na tarefa de implantação propriamente dita (além de não gerar código). Observou-se que as soluções D&C Based(CALA; WATSON, 2010), SDO(LI, 2012) e UserLevel Deployment(ZHANG; LI; ZHENG, 2013) utilizaram o mecanismo baseado em linguagem de programação, que em contraste com as abordagens Vega(CHIEU, 2010), Wrangler(JUVE; DEELMAN, 2011) e Disnix(BURG, 2009) apresentaram se mais vantajosas quanto ao investimento de tempo para o processo de implantação (ver Tabela 3.1). As soluções das abordagens Vega(CHIEU, 2010), Wrangler(JUVE; DEELMAN, 2011) e Disnix(BURG, 2009) utilizaram mecanismos manuais ou script, o que exige mais tempo para o processo de implantação, ademais, de acordo com Fazziki et al. (2012) e Talwar, Milojicic e Wu (2005) estes mecanismos têm um menor grau de vantagens, porque aumentam os custos com relação ao código e aos esforços humanos. Além disso percebeu-se que as propostas Virtual Models(KONSTANTINOU, 2009) e Disnix(BURG, 2009) apresentaram mecanismos semi-automáticos para a implantação. Em outras palavras, nessas abordagens ainda há a necessidade de intervenção manual no processo de implantação. Também foi descoberto que a proposta em MODAClouds(ARDAGNA, 2012) apresentou uma abordagem dirigida a modelos para a implantação de software, no entanto, esta abordagem requer certa compreensão do usuário final sobre detalhes da estrutura de computação.

(43) 3.10 Análise das Ferramentas CASE. 26. em nuvem , além da grande carga de informação nos modelos demandada ao usuário para a implantação. Nossa solução (AeroModelos) consiste em uma abordagem dirigida a modelos (a qual requer poucos modelos) para implantação automática de software na nuvem, cujo único conhecimento específico do desenvolvedor sobre a nuvem seja a chave de acesso e o nome do provedor, já que os detalhes mais específicos serão abstraídos. O objetivo dessa abordagem é a implantação de software em um nível de abstração mais elevado, no âmbito de reduzir o investimento humano e o tempo para a implantação, tanto quanto possível, já que o ’uso de uma abordagem com base em modelos é a melhor maneira de aumentar a produtividade do desenvolvedor’ (FAZZIKI, 2012).. 3.10. Análise das Ferramentas CASE. Como mencionado, a proposta visa à utilização de modelos como recurso de entrada, a fim de reduzir os esforços humanos. Assim, uma das tarefas da proposta seria a interpretação dos arquivos gerados pelos diagramas UML e a conversão em código executável para a implantação na nuvem. Para auxiliar a criação de entradas no formato de modelos (diagramas visuais UML), para o usuário desenvolvedor, foram investigadas ferramentas de modelagem que obedecem ao padrão UML (por ser um padrão de modelagem amplamente utilizado pela comunidade), com objetivo de identificar se há um padrão gerado nos arquivos de saída dessas ferramentas, ou seja, se os modelos visuais possuem alguma metalinguagem adequada para que seja interpretada pelo módulo Associador. Para interpretar os diagramas de implantação do padrão UML, foram identificados e analisados os arquivos de saída de oito ferramentas CASE de modelagem UML de licença gratuita, dentre elas: ArgoUML (COLLABNET INC, 2013), Dia(DIA DEVELOPERS, 2013), Gaphor(GAPHOR, 2013), Modelio (MODELIOSOFT, 2013),NClass (TIHANYI, 2013),StarUML (PLASTIC SOFTWARE, 2013), Umbrello (KDE, 2013), VioletUML (VIOLET. . . , 2013). A listagem destas ferramentas está disposta na tabela 3.2, a qual evidencia a ferramenta e a plataforma ou sistema operacional, no qual ela executa. Após a análise das saídas geradas pelas ferramentas CASE, percebeu-se que todas elas.