Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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
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ós-
Graduaçã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ên-
cia da Computação.
Orientador: Prof. Dr. Tarcísio da Rocha
SÃO CRISTÓVÃO/ SE
2015
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 da Computação)– Universidade Federal de Sergipe, 2014.
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
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ós-
Graduaçã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ên-
cia 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)
Abordagem Dirigida a Modelos para Implantação
Automática de Software em Nuvem
Este exemplar corresponde à redação da Disser-
taçã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
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
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 momen-
tos 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 tra-
balho.
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
"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
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 conheci-
mento 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 ar-
quiteturas 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 implan-
taçã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 arquite-
tura 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 re-
alizado 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
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 deploy-
ment 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 devel-
oper 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 ap-
proach 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
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; DEEL-
MAN, 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
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-loja-
virtual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
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
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
Sumário
1 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
2 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
2.2 Desenvolvimento de Software Dirigido a Modelos . . . . . . . . . . . . . . 10
2.2.1 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Ferramentas CASE . . . . . . . . . . . . . . . . . . . . . . . . . . 13
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
3.10 Análise das Ferramentas CASE . . . . . . . . . . . . . . . . . . . . . . . . 26
4 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
5 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
5.2 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
5.3 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
5.4 Implementação do Módulo Alocador . . . . . . . . . . . . . . . . . . . . . 74
5.4.1 Correlação dos Atributos "‘PartUML"’ com os Nós . . . . . . . . . 75
xi
5.4.2 Separação de Listas de Nós em Listas de Objetos por Categorias . . 75
5.4.3 Relacionamento de Provedores de Nuvem e Instâncias de VM com
Máquinas Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.5 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
5.6 Estudo de Caso da Solução . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6 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
7 Conclusão 97
Referências 98
A 104
xii
Capítulo 1
Introdução
Os recursos trazidos pela computação em nuvem reduzem os custos computacionais pro-
venientes 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 encon-
trados 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 abor-
dagem 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 am-
biente 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 (AMA-
ZON, 2013).
1
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 auto-
má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;
1.3 Organização da Proposta de Dissertação 3
• O compartilhamento da solução de implantação automática de software dirigida a mo-
delos na nuvem com a comunidade científica para trabalhos futuros;
Publicações
RIBEIRO JUNIOR, F. M.; DA ROCHA, T. Model-Based Approach to Automa-
tic 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.
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 compu-
taçã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 po-
der 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 ser-
viç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 infra-
4
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 apli-
caçõ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).
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 nu-
vem: 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
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 co-
munitá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
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 re-
curso de hardware a uma aplicação (ARMSTRONG, 2011), ou seja, o aprovisiona-
mento 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
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 à elimi-
nação de tarefas manuais como: a configuração da pilha de software, a autenticação entre
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 ser-
viç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 requi-
sitos 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 complexi-
dade, 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 desa-
fios. 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.
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 li-
gada à 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 pro-
posta 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 ne-
cessá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 desenvolvi-
mento 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 funcio-
nal 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 mo-
delos 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
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 pro-
gramaçã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 desenvolvi-
mento 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 correspon-
dê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 mode-
los 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
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 plane-
jamento 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, Ar-
goUML((COLLABNET INC, 2013)), StarUML((PLASTIC SOFTWARE, 2013)), Umbrel-
loUML((KDE, 2013))e VioletUML((VIOLET. . . , 2013)). Todas estas apresentam uma tra-
dução de seus modelos em metalinguagens, como por exemplo, o eXtensible Markup Lan-
guage (XML), um facilitador no desenvolvimento de software dirigido a modelos, pela in-
terpretaçã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 ferramen-
tas 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 total-
mente funcional de acordo com os requisitos especificados.
Capítulo 3
Trabalhos Correlatos
Nesta pesquisa, após realizada uma investigação bibliográfica acerca das abordagens de im-
plantação automática de software em nuvem, foram encontrados e selecionados os trabalhos
de (CALA; WATSON, 2010), (CHIEU, 2010), (JUVE; DEELMAN, 2011), (KONSTAN-
TINOU, 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 rela-
cionada.
3.1 D&C Based Deployment
Em seu trabalho, Cala e Watson (2010) apresentaram uma plataforma de implantação auto-
mática em nuvem, baseada no Deployment and Configuration of Component-based Applica-
tions 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ími-
cas 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 implan-
tar 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 estrutu-
rada com quatro elementos, dentre os quais, o Controller, Queue Storage (fila de serviços),
14
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 (con-
trolador) são definidos os planos de implantação (nestes planos são definidas as dependên-
cias 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 relacionam-
se 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 de-
pendê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ên-
cia 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
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 nu-
vem 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 expec-
tativas do SP.
3.3 Wrangler 17
A fim de executar os passos descritos, os autores propuseram uma arquitetura para aten-
der os requisitos da implantação de software, a qual foi nomeada de Service Deploy Optimi-
zer (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 con-
junto 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 nu-
vem, 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):
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 coorde-
nadores 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.
3.4 Disnix 19
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 distri-
buí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 pa-
cote, 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
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 pro-
puseram 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 espe-
cificaçõ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 utili-
zada 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) desenvol-
veram 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
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
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
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 dife-
rentes 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
3.9 Discussão 24
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 lingua-
gem 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-
3.9 Discussão 25
Propostas Manual Script Linguagem Dirigido a Modelos Modelos SimplesMODAClouds X
Disnix X XVirtual Models X X X X
Vega XD&C Based X
Wrangler XSDO X
UserLevel XSolução da Pesquisa (AeroModelos) X X
Tabela 3.1: Mecanismos de Implantação das Propostas.
dels(KONSTANTINOU, 2009) e MODAClouds(ARDAGNA, 2012) apresentam uma abor-
dagem 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 pro-
cesso 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 vantajo-
sas 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 pro-
cesso 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 abor-
dagem requer certa compreensão do usuário final sobre detalhes da estrutura de computação
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 ferramen-
tas, 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 (VI-
OLET. . . , 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
3.10 Análise das Ferramentas CASE 27
Ferramenta UML Plataforma/S.O.ArgoUML Java
Dia GTK+Gaphor PyGTKModelio Windows/LinuxNClass Windows/Linux/Mac
StarUML WindowsUmbrello Windows/Unix
VioletUML Java
Tabela 3.2: Ferramentas CASE de Licença Gratuita.
embora de forma similar, apresentam bruscas diferenças em seus arquivos de saída (percebi-
das com um editor de texto).
Percebeu-se também que as ferramentas ArgoUML, Gaphor, NClass, Umbrello e Viole-
tUML não possuem em sua funcionalidade o recurso do diagrama de implantação e que o
uso de outro diagrama como substituto para o diagrama de implantação poderia dificultar na
assimilação do usuário para com a modelagem, visto que a saída da proposta apresentada
gera uma implantação de software.
Nesta investigação foi descoberto que somente três ferramentas, Dia, Modelio e Sta-
rUML apresentaram diagrama de implantação e que as ferramentas ArgoUML e Umbrello,
embora possuam o diagrama de distribuição como meio para criação de componentes do tipo
nós, similar ao diagrama de implantação, não possuem os recursos UML buscados por esta
investigação, os quais somente estão presentes no diagrama de implantação.
Percebeu-se que as metalinguagens de saída das ferramentas UML, os softwares Ar-
goUML, Dia, Gaphor, Modelio e NClass apresentaram apenas as coordenadas (x,y) de loca-
lização dos componentes UML, ou seja, foi percebido que não houve uma preocupação na
saída gerada em identificar os componentes com qualquer tipo de associação entre os mes-
mos, a não ser as coordenadas de onde os componentes UML estão localizados graficamente.
Tais características estão exibidas na Tabela 3.3.
Além disso, descobriu-se que apenas três ferramentas, StarUML, Umbrello e VioletUML
apresentaram arquivos de saída (diagramas UML) com metalinguagens de maior facilidade
para a interpretação, por possuírem identificadores não somente das coordenadas dos com-
ponentes visuais da UML, mas também IDs das associações entre os mesmos.
3.10 Análise das Ferramentas CASE 28
Ferramenta UML Diagrama de Implantação Formato não textual Identificação das Coordenadas Componente com ID Identificação das AssociaçõesArgoUML X X
Dia X X XGaphor X XModelio X XNClass X X
StarUML X X X XUmbrello X X X
VioletUML X X X
Tabela 3.3: Características dos Arquivos de Saída das Ferramentas CASE.
Foi percebido que apenas as ferramentas Dia, Modelio e StarUML estão de acordo com
as especificações almejadas por esta pesquisa, por possuirem o diagrama de implantação.
Porém a Modelio apresentou em sua saída uma metalinguagem binária (não textual) e a
ferramenta Dia, não apresentou identificação clara entre as associações dos componentes.
Dentre as ferramentas pesquisadas, a ferramenta StarUML apresentou-se como a mais
completa na lista de requisitos desejáveis, percebidos na Tabela 3.3, já que além de atender a
identificação dos componentes UML por meio da metalinguagem gerada em seu arquivo de
saída, a ferramenta possui o diagrama de implantação.
Capítulo 4
Solução: AeroModelos
Devido ao aumento na complexidade dos sistemas e serviços de software, os custos com
a implantação de serviços em um ambiente em nuvem subiram. Ademais, sabe-se que a
implantação automática de serviços pode reduzir os custos com complexidade, além disso
sabe-se que com o uso de modelos na implantação pode ser possível obter um ganho maior
na produtividade e escalabilidade da implantação. Por isso esta investigação propõe o uso
de modelos visuais em que seja possível a geração automática de código para a implanta-
ção (deployment) de serviços no âmbito de tentar reduzir consideravelmente os custos de
complexidade e esforços humanos no deployment.
Esta seção explana como foram definidos os modelos de implantação, a arquitetura e
a visão conceitual da proposta para a implantação automática de software na nuvem, além
disso, também é apresentada a maneira como será realizada a interpretação dos modelos
UML em adequação à proposta, já que para a solução são utilizados diagramas de deploy-
ment(implantação) UML (OBJECT MANAGEMENT GROUP, 2011) como entrada.
4.1 Visão Geral da Solução
Para a tarefa de implantação de software na nuvem cabe ao desenvolvedor definir o sistema
operacional, o provedor de nuvem, a chave de acesso ao provedor, a(s) máquina(s) alocada(s)
ao provedor, os serviços (e plataformas) que dão suporte à aplicação e o diretório onde se
encontram os serviços e a aplicação.
Em uma abordagem prática, suponha que o desenvolvedor deseje implantar uma aplica-
29
4.1 Visão Geral da Solução 30
ção na nuvem que dependa de dois serviços, por exemplo, dois outros softwares ou plata-
formas. Para cumprir esta tarefa seria necessário ao desenvolvedor adquirir uma chave de
acesso ao provedor que deseja implantar a aplicação, eleger uma máquina (nó) do provedor
de nuvem para suportar a aplicação, realizar a configuração de uma máquina virtual, instalar
da máquina virtual em um provedor de nuvem, instalar de um sistema operacional na má-
quina virtual, bem como a implantação dos serviços e aplicação na ordem de dependência
dos serviços e da aplicação também desta máquina virtual.
Para tornar a implantação automática de software na nuvem por meio de modelos possí-
vel (inclusive o exemplo prático apresentado no parágrafo acima), a solução desta pesquisa
propõe que inicialmente que o desenvolvedor tenha implementado (caso necessário) os servi-
ços que deseja implantar na nuvem, assim como ter criado os modelos UML de implantação
(de software na nuvem), onde serão definidas todas as informações necessárias (máquinas
virtuais, serviços, aplicações, dependências, sistemas operacionais das máquinas virtuais,
repositório dos serviços e máquinas virtuais, banco de dados, provedor de nuvem, chaves de
acesso) para a implantação apenas como forma de parâmetros (sem necessidade de codificar
ou configurar nenhuma máquina virtual).
Após a criação e definição dos modelos com seus respectivos parâmetros de entrada, o
usuário desenvolvedor utiliza como entrada no sistema os modelos e os serviços e então é
disparada a implantação automática pelo sistema, nela ocorrem quatro etapas, sendo duas
para a interpretação dos modelos UML, uma etapa da criação da pilha de software e outra
para a geração automática de código. No que se refere as etapas de intepretação dos modelos
de implantação UML, temos que (i) corresponde a interpretação de um modelo específico
(que contem os elementos referentes ao provedor de nuvem, chave de acesso, instância da
máquina virtual na nuvem e repositório) e (ii) a interpretação do modelo geral (que contem
os elementos referentes às máquinas virtuais, sistema operacional, serviços, banco de dados,
dependências e aplicações). No que se refere a etapa da criação da pilha de software temos
que a pilha de software é definida pela pilha de dependências entre os serviços (que foram
descobertos na etapa de interpretação do modelo geral).
Na primeira etapa o após disparada a implantação automática, o sistema inicialmente in-
terpreta o modelo geral coletando seus dados através de um arquivo de formato similar ao
XML, o .uml, onde nele estão contidos os dados que o desenvolvedor especificou no modelo,
4.2 Definição dos Modelos de Implantação de Software na Nuvem 31
instanciando lista de objetos máquina virtual, dependências, S.O. e serviços. Na etapa de cri-
ação da pilha de software o sistema relaciona os serviços às respectivas máquinas virtuais e
depois relaciona as dependências com os serviços de cada máquina virtual individualmente.
Ao finalizar essas duas etapas iniciais já foram coletados todos os dados referentes às má-
quinas virtuais e serviços, então, para coletar os dados restantes (como a qual provedor de
nuvem a máquina virtual será instalada) é iniciada a etapa de interpretação do modelo es-
pecífico, onde é também lido um arquivo de formato similar ao XML (formato .uml) para
a coleta dos dados e finalmente após todos os dados coletados, é realizada a etapa de ge-
ração automática de código, onde o código é gerado e executado pelo sistema, para que se
concretize a implantação automática de software na nuvem.
4.2 Definição dos Modelos de Implantação de Software na
Nuvem
No âmbito de buscar uma proposta implantação de software na nuvem, a solução tem como
entradas dois diagramas de deployment UML: o primeiro é geral (conforme o exemplo da
Figura 4.1) e independente de provedor de nuvem, apenas representando as máquinas virtuais
(VMs), o sistema operacional e as dependências entre os serviços alocados a estas VMs, já
o segundo é específico (conforme o exemplo da Figura 4.2) e possui aspectos específicos
vinculados à infraestrutura da nuvem como, por exemplo, as chaves de acesso ao provedor.
Figura 4.1: Exemplo de Modelo Geral da Solução.
Pode-se perceber que o exemplo de modelo geral representado pela Figura 4.1 abrange
4.2 Definição dos Modelos de Implantação de Software na Nuvem 32
todas as caracerísticas necessárias (serviços, dependencias entre serviços, sistema operacio-
nal, máquina virtual, aplicação, banco de dados e campos opcionais para cada serviço, como
por exemplo a versão do serviço, o diretório do serviço, entre outros) para a implantação
do software independente do provedor de nuvem e que o modelo específico (Figura 4.2) co-
leta as informações necessárias para a implantação efetiva do software na nuvem, tais quais:
chave de acesso, repositório dos serviços e aplicação da máquina virtual e instância de VM
na nuvem. Logo pode-se verificar que, para a efetiva modelagem do modelo específico, faz-
se inicialmente necessária a criação do modelo geral, já que o modelo específico precisa das
informações da máquina virtual, conforme a Figura 4.2.
A relação entre o modelo específico e o geral pode ser percebida de tal forma que no
exemplo da Figura 4.2 o nó Virtual Machine corresponde ao mesmo nó representado no
exemplo da Figura 4.1, sendo o provedor de nuvem, o repositório e o banco de dados do
modelo específico da Figura 4.2 correspondente ao nó Virtual Machine da Figura 4.1.
Figura 4.2: Exemplo de Modelo Específico da Solução.
Ao partir de uma solução prática (em grande escala), supondo que o desenvolvedor deseje
a implantação de várias aplicações, o uso de modelos poderia tornar o trabalho de implanta-
ção de software menos árduo, pela redução de codificação e pelo aumento na produtividade
da implantação, além de lidar com softwares legado, uma vez que o modelo geral é inde-
pendente do provedor de nuvem, o que possibilita a migração da implantação para outro
provedor de nuvem, como pode-se perceber na Figura 4.3.
4.3 Casos de Uso da Solução 33
Figura 4.3: Exemplo de Modelo Geral com N Máquinas Virtuais e N Aplicações.
4.3 Casos de Uso da Solução
A principal vantagem da proposta é o foco na redução dos custos com tempo e esforços
humanos para a implantação. A redução nos valores das métricas (tempo e investimento
humano) pode provir do mecanismo de implantação através do uso de diagramas de de-
ployment UML como entrada (ao invés do uso de código). Afinal, é sabido que o uso de
desenvolvimento dirigido a modelos para gerar código aumenta a qualidade do software,
além de reduzir os custos e possíveis erros de codificação (FAZZIKI, 2012).
O diagrama de casos de uso da proposta pode ser observado na Figura 4.4 que visa ilustrar
a minimização dos esforços humanos no processo de implantação. Nesse caso de uso, pode-
se observar que a carga de trabalho é resumida na criação dos diagramas de deployment
UML e na implementação dos serviços (caso necessário). Onde o usuário, apenas teria que
utilizar como entrada do sistema os serviços implementados, os dois modelos de deployment,
um geral (para VMs e serviços) e o outro específico (correspondente aos aspectos da nuvem
escolhida).
O diagrama de casos de uso da Figura 4.4 é composto por sete casos de uso (onde cinco
são ligados ao sistema e estão detalhados na seções seguintes), são eles:
• Implementar Serviços: no qual o desenvolvedor irá implementar os serviços e aplica-
4.3 Casos de Uso da Solução 34
Figura 4.4: Caso de Uso da Solução.
ção que deseja implantar no provedor de nuvem;
• Criar Modelo de Implanatação Específico e Geral: que consiste na modelagem da im-
plantação a ser realizada, onde estarão as informações necessárias para a implantação
de cada aplicação;
• Disparar Implantação Automática: que possui uma visão geral do fluxo de atividades
do sistema como um todo;
• Gerar Código da Implantação: que descreve as tarefas necessárias para a geração do
código de configuração dos serviços e máquinas virtuais a serem implantadas;
• Interpretar Modelo Específico: que corresponde a interpretação e coleta de dados do
modelo de implantação UML relacionado às características específicas do provedor de
nuvem;
• Interpretar Modelo Geral: que corresponde a interpretação e coleta de dados do mo-
delo de implantação UML relacionado aos serviços, aplicações e máquinas virtuais (e
portanto que é independente de provedor de nuvem);
• Criar Pilha de Software: que é responsável pela criação da pilha de software, a qual
representa a sequência em que os serviços devem ser instalados na máquina virtual,
já que existe uma ordem de dependência entre os serviços, ou seja, um serviço A que
4.4 Arquitetura 35
dependa de um serviço B, somente executará corretamente quando B for instalado e
executar antes de A.
Além disso, dentre os casos de uso do diagrama, dois deles ("Implementar Serviços"e
"Modelar Modelos de Implantação Específico e Geral") pertecem somente ao escopo do
desenvolvedor e cinco pertencem ao escopo do sistema, sendo em que apenas um caso de
uso nomeado de "Disparar Implantação Automática de Software", o desenvolvedor poderá
somente inserir os modelos criados no caso de uso "Criar Modelos de Implantação Específico
e Geral".
4.4 Arquitetura
A arquitetura proposta está dividida em três visões (de sistema, local e remota) e é composta
por cinco módulos, nomeados de Controlador, Associador, Empilhador, Alocador e Prepara-
dor. Na Figura 4.5 pode ser vista a arquitetura do sistema proposto para implantação dirigida
a modelos de software em nuvem. Dentre as visões estão:
• A visão de sistema: que mostra os cinco módulos do sistema (Controlador, Associador,
Empilhador, Alocador e Preparador);
• A visão local: que corresponde à visão do usuário, ou seja, à interação humano-
computador (que usa como entrada passwords e os diagramas de deployment UML);
• A visão remota: que inclui a criação de uma instância do servidor Chef (OPSCODE,
2013) na nuvem e o estágio final da implantação, correspondente à instalação do
software na nuvem.
Na arquitetura, o módulo de Controlador gerencia os outros quatro módulos, atuando
como um intermediário na comunicação entre os módulos e é responsável por:
• Enviar os serviços obtidos do Associador ao Empilhador e os relacionamentos de de-
pendência entre os serviços (pilha de software), do Empilhador para o Preparador;
• Habilitar a comunicação do Alocador com a nuvem;
• Informar ao Alocador sobre a criação da instância do servidor na nuvem;
4.4 Arquitetura 36
Figura 4.5: Arquitetura da Solução.
• Informar ao Preparador que sistema operacional deve ser instalado na VM;
• Informar ao Preparador que pilha de software deve ser alocado na respectiva VM;
• Gerenciar a ordem da transmissão de informação e realização de tarefas entre os mó-
dulos.
4.4.1 Fluxo Geral do Sistema
Para explanar o funcionamento de sistema de modo geral, foi criado um diagrama de ativi-
dades baseado no caso de uso "Disparar Implantação Automática"proveniente do diagrama
de casos de uso (conforme pode ser visto na Figura 4.4).
O diagrama de atividades pode ser observado na Figura 4.6 e é composto pelo escopo
dos cinco módulos da arquitetura do sistema e pelo escopo do usuário desenvolvedor. Ele
define o gráfico de fluxo do sistema de maneira geral, além de conter atividades definidas
4.4 Arquitetura 37
como outros diagramas de atividades que também pertencem ao diagrama de caso de uso
(da Figura 4.4) e que, inclusive, são essenciais para o funcionamento do caso de uso "Dis-
parar Implantação Automática", são eles: "Interpretar Modelo Geral", "Interpretar Modelo
Específico", "Criar Pilha de Software"e "Gerar Código da Implantação".
4.4 Arquitetura 38
Figura 4.6: Diagrama de Atividades - Gerar Implantação Automática de Software.
4.4 Arquitetura 39
4.4.2 Módulo Associador
A rotina do módulo Associador começa no momento em que o usuário fornece dois dia-
gramas de implantação UML (o específico e o geral). A partir disso, o módulo Associador
interpreta os diagramas UML para coletar a informação relacionada aos componentes UML,
conforme a Figura 4.7
Figura 4.7: Exemplo de Identificação de Atributos no Modelo Geral - Módulo Associador.
Para que sejam interpretadas as informações dos modelos geral e específico, o módulo
Associador possui um fluxo de atividades para cada um dos modelos, representado pelos Di-
agramas de Atividades nas Figuras 4.8 e 4.9, referente aos casos de uso "Interpretar Modelo
Geral"e "Interpretar Modelo Específico"respectivamente (conforme a Figura 4.4).
Como pode ser observado na Figura 4.8, o diagrama de atividades referente ao modelo
geral inicia com a atividade "Abrir Arquivo", que abre o arquivo de extensão .uml (exemplo:
modeloGeral.uml) para identificar as variváveis de cada elemento da UML nele contidos.
Após essa etapa, o Associador identifica o tipo do elemento UML e instancia um objeto de
acordo com o tipo de elemento UML, seja ele um artefato (serviços e aplicação), nó (máquina
virtual), dependência, associação ou "containerView" (sistema operacional).
Análogo ao fluxo de atividades referente à interpretação do modelo geral, o caso de
uso "Interpretar Modelo Específico"é representado pelo diagrama de atividades da Figura
4.9 e também identifica os tipos de elementos UML para criar instâncias de objetos, com a
diferença de que neste fluxo serão instanciados objetos relacionados a aspectos específicos
da implantação de software, como o objetos da classe repositório, chave de acesso, banco de
dados, provedor de nuvem.
4.4 Arquitetura 40
Figura 4.8: Diagrama de Atividades Interpretar Modelo Geral.
4.4.3 Módulo Empilhador
O módulo Empilhador é responsável pela criação das pilhas de software, como previamente
especificadas no diagrama de deployment (implantação) UML pelo usuário e estabelece as
dependências da pilha de software, de acordo com o modelo de deployment UML de serviços
e empilha os serviços, para que sejam instalados futuramente seguindo a ordem da pilha.
Antes de iniciar o fluxo de atividades, o módulo Empilhador recebe, através do Contro-
lador, todas as listas de objetos de artefatos (serviços), dependências, containers (sistemas
operacionais) e nós (máquinas virtuais) criadas pelo módulo Associador, conforme a Figura
4.8.
Como pode ser percebido na Figura 4.10, o módulo Empilhador inicia o fluxo de ati-
vidades ordenando a lista de objetos artefatos. Após isto, o módulo Empilhador executa a
tarefa "Relacionar Lista de Dependências"que atribui uma varivável "DependeDe" a um ob-
4.4 Arquitetura 41
Figura 4.9: Diagrama de Atividades Interpretar Modelo Específico.
jeto Artefato (serviço) a fim de mais tarde identificar as dependências entre os serviços, para
a criação da pilha de software. Nota-se que na Figura 4.7 os atributos head e tail do elemento
"Dependência"estão relacionados aos atributos ID dos serviços (artefatos UML).
Ao seguir o fluxo de atividades, para que seja possível a descobrir que serviços (artefatos)
pertencem aos respectivos nós, podemos adotar a solução de comparar cada coordenada
(x,y) do serviço para verificar se o serviço está contido na envoltória do nó (como pode ser
percebido na Figura 4.11), isso poderia ser realizado ao varrer uma lista m de nós e uma lista
n de serviços, na comparação de um para um, o que implicaria em uma complexidade de
O(n*m) neste algorimo de identificação.
Contudo, com um número alto de nós (pelo menos 7 nós) e serviços (pelo menos 10
serviços), supondo que ambas as listas de nós e serviços estejam desordenadas (no pior caso:
para cada busca de um serviço pertencente a um nó, o elemento nó correspondente somente
seria encontrado como último elemento da lista), então foi desenvolvido um algoritmo de
4.4 Arquitetura 42
Figura 4.10: Diagrama de Atividades Criar Pilha de Software.
complexidade O ((n+m) + (m*log m) + (n*log n)) a fim de ordenar os serviços e nós o mais
próximo possível um do outro, para que na varredura das listas, a busca de um elemento ser-
viço que pertença a envoltória de um elemento nó o algoritmo seja o mais próximo possível
de uma busca ótima (sendo ele somente utilizado caso n>=10 e m>=7).
Figura 4.11: Exemplo de Obtenção das Coordenadas (X,Y) para Artefatos e Envoltória dosNós
4.4 Arquitetura 43
O módulo Empilhador então cria sublistas a partir da lista de artefatos, onde cada sublista
está contida em um intervalo da coordenada X, feito isto, cada sublista de objetos artefatos
é ordenada por Y e a lista de Nós é ordenada pela coordenada X. Tal abordagem é utilizada
para redução da complexidade computacional na atividade "Relacionar Artefatos com Nós"e
pode ser observada na Figura 4.12, já que somente os nós de coordenadas próximas aos
seus respectivos serviços serão mais facilmente encontrados que se a solução tivesse que
comparar cada nó com cada artefato.
Figura 4.12: Atividades de criação e ordenação de SubListas de Artefatos.
Na atividade "Relacionar Artefatos com Nós", que compara as coordenadas (X,Y) dos
serviços com as coordenadas das Máquinas Virtuais, afim de identificar quais serviços per-
tencem a quais máquinas virtuais, para cada objeto Nó (máquina virtual) é atribuída uma
lista de objetos que ao longo da comparação armazena os obejtos artefatos (serviços). De-
pois disso, cada lista de serviços de cada máquina virtual é ordenada de acordo com a depen-
dência de cada objeto serviço e então é criada a pilha de software. Finalmente cada sistema
operacional é relaconado ao seu respectivo Nó.
4.4.4 Módulo Alocador
O Alocador acessa a nuvem e cria uma instância do servidor Chef (OPSCODE, 2013). De-
pois de criada a instância do servidor na nuvem, o Alocador torna possível a implantação
4.4 Arquitetura 44
na nuvem, pois, uma vez o servidor na nuvem, os clientes vinculados ao mesmo poderão
executar sobre o ambiente em nuvem, conforme a Figura 4.13.
Figura 4.13: Módulo Alocador.
4.4.5 Módulo Preparador
O módulo Preparador recebe uma confirmação do módulo Alocador, de que a instância do
servidor foi criada na nuvem. Então o Preparador coleta informações relacionadas ao mo-
delo geral (lista de nós, com suas respectivas pilhas de software e sistema operacional) e ao
modelo específico (chave de Acesso, tipo de máquina física na nuvem em que será insta-
lada a máquina virtual, provedor de nuvem e o identificador da instância da VM na nuvem),
conforme pode ser percebido na Figura 4.14.
Com as informações coletadas, o Preparador cria para cada máquina virtual do modelo
geral, um arquivo de configuração de implantação chamado de cookbook dos serviços na
nuvem (que é um tipo arquivo com código escrito na linguagem de programação ruby do
framework Chef (OPSCODE, 2013)) e, para cada aplicação do modelo específico, outro ar-
quivo contendo as regras da aplicação, o qual contém as informações específicas para o pro-
vedor de nuvem. Além disso, existe um arquivo (que define as regras da aplicação) nomeado
de "cookbook de dependências", que descreve especificamente as regras de como acontece
o relacionamento das dependências entre os serviços e a aplicação. Alguns "cookbooks de
dependências", por serem genéricos, podem ser automaticamente gerados, já outros somente
podem ser escritos pelo programador, ou seja, eles devem ser entendidos como serviços que
não farão parte do modelo em si, mas que devem ser implementados pelo desenvolvedor
como um serviço.
Após criados os "cookbooks" a partir dos modelos geral e específico, o módulo Prepa-
rador executa o código dos arquivos e assim prepara um cliente com uma máquina virtual
4.4 Arquitetura 45
Figura 4.14: Diagrama de Atividades Gerar Código da Implantação - Módulo Preparador.
(VM), instala o sistema operacional na VM, aloca os serviços (da pilha de software) na VM
e finalmente, implanta a aplicação na nuvem. Depois disso, a aplicação pode ser executada
pelo provedor.
4.4.6 Visão Conceitual
Para observar os prinicpais aspectos da proposta, foi desenvolvida uma visão conceitual,
como pode ser observada na Figura 4.15, usando o Amazon EC2 (AMAZON, 2013) como
provedor de nuvem, o Chef (OPSCODE, 2013) como gerenciador de servidor e a ferramenta
StarUML (PLASTIC SOFTWARE, 2013) para a modelagem dos diagramas UML. A visão
conceitual é composta pelos quatro módulos mencionados na arquitetura da solução, onde
cada um destes módulos corresponde a um estado em uma máquina de estados, conforme a
Figura 4.15.
Na visão conceitual, o estado que representa o módulo Associador apresenta a inter-
pretação da metalinguagem gerada pelo diagrama de deployment UML (criado através do
StarUML). Após a análise da metalinguagem gerada pelo StarUML, como pode-se observar
4.4 Arquitetura 46
na Figura 4.15, foi percebido que o nó Virtual Machine está representado como elemento do
array OwnedViews[], que possui um tipo type=UMLNodeView, um identificador guid e as
coordenadas em valores do tipo inteiro, pelas variáveis Left, Top, Width e Height.
Pode ser observado na Figura 4.15 que a associação de dependência entre os artefatos
Service[n] e Service[n-1] é identificada pelo tipo type=UMLDependencyView e que esta
associação possui dois atributos do tipo ID, identificados por head e tail, que correspondem
aos identificadores dos artefatos UML Service[n] e Service[n-1], onde Service[n] depende
de Service[n-1]. Além disso, pode-se perceber que o atributo guid atribuído a Service[n]
corresponde ao ID do atributo head na associação de dependência.
O modulo Empilhador identifica quais componentes UML (artefatos) estão dentro da en-
voltória do nó UML, ou seja, quais serviços pertencem ao nó e os armazena em listas de
artefatos (pilhas de software correspondentes ao respectivo nó). Para que isso seja possí-
vel, é necessário comparar as coordenadas de cada nó com as de cada artefato, porém, a
complexidade dessa técnica seria O(m*n), onde m é o número de nós e n a quantidade de
artefatos.
Para reduzir a complexidade do algoritmo O(m*n), foi desenvolvido um algoritmo de
complexidade O((n + m) + (m*log m) + (n*log n)), que apresenta complexidade menor, mas
apenas se n>=10 e m>=7. A solução usará a técnica de complexidade O (m*n) para m<7 e
n<10 (ver Figura 4.15).
Para o estado Alocador, neste exemplo, foi utilizado o Chef (Opscode, 2013), como
ferramenta para a criação de uma instância do servidor na nuvem Amazon EC2 (Amazon,
2013). Nele são usadas as chaves de acesso e senhas, escritas no arquivo chamado de knife.rb,
que são requeridas pelo provedor EC2.
O modulo Preparador é responsável por criar a máquina virtual e pela instalação do
sistema operacional escolhido pelo usuário na VM criada. Depois disso, esse módulo cria
um nó cliente, aloca a máquina virtual a este cliente e então a solução sobe (upload) todos
os serviços (elementos da lista ArtifactList) à máquina virtual.
Finalmente, as regras da aplicação são definidas de acordo com os serviços referentes ao
nó VM que ela depende (ver Figura 4.15). Esta tarefa requer conhecimento do repositório
em que se encontram os serviços e da chave de acesso do provedor de nuvem. Após esse
processo, a aplicação é levantada para a nuvem.
4.4 Arquitetura 47
Figura 4.15: Visão Conceitual.
Capítulo 5
Implementação da Proposta
No âmbito de explanar a solução proposta por esta pesquisa, neste capítulo está detalhada
a geração de código e implementação da solução dirigida a modelos para a implantação
automática de software na nuvem, que compreende a interpretação dos modelos UML (Geral
e Específico), além do comportamento (proposto por esta pesquisa) dos modelos UML de
implantação de software na nuvem, o detalhamento dos módulos referentes à arquitetura
proposta (Associador, Empilhador, Alocador e Preparador).
Ademais, também foi apresentado um exemplo de funcionamento da solução proposta na
prática em um serviço comercial (na empresa SWX) e exibido o código gerado pela proposta
para esta solução.
5.1 Interpretação dos Componentes UML
Nesta seção está detalhada a maneira como na solução (o módulo Associador) interpreta
(extrai os dados) dos diagramas de implantação UML criados pelo desenvolvedor, através da
metalinguagem que é gerada pela ferramenta StarUML.
Para entender como é realizada a extração dos dados pela solução, esta seção também
descreve a estrutura de cada componente de deployment UML necessário para a compreensão
e interpretação da metalinguagem que representa os modelos Geral e Específico. Para isso,
foi criado um exemplo de diagrama de implantação na ferramenta StarUML, e em seguida,
adicionados componentes UML, tais quais: nós, artefatos, associação entre nós, dependência
entre artefatos e containers dos nós, onde cada componente UML pode ser identificado por
48
5.1 Interpretação dos Componentes UML 49
trechos de scripts da metalinguagem de saída (de extensão “.uml”).
5.1.1 Interpretação de Nós
No exemplo do diagrama de deployment foi criado um nó nomeado de Máquina Virtual
(Figura 5.1). Exibido na forma gráfica pela ferramenta StarUML e que pode ser considerado
pela solução como uma máquina virtual, um provedor de nuvem ou banco de dados.
Figura 5.1: Representação visual de um Nó UML.
Correlato à Figura 5.1, pode-se obter o trecho da metalinguagem correspondente exibido
no script da Figura 5.2.
Figura 5.2: Script correspondente ao Nó da Figura 5.1.
A primeira parte destacada na Figura 5.2 (por um retângulo de numeração “1”, na linha
23) denomina um objeto OBJ, o qual possui o como atributos name = “OwnedViews [0]”
que indica um componente UML, sendo este um elemento [0] no vetor OwnedViews. Ainda
na mesma linha (23) pode-se perceber a variável type = “UMLNodeView” que representa
o tipo do componente (um nó) e que a atribuição guid = “1lMd4rzMu0mijjg9mwAglgAA”
representa o identificador (ID) deste nó.
A segunda parte do trecho da Figura 5.2 contem quatro linhas, cuja primeira linha (26),
possui um atributo name = “Left” type = “integer”>372, indicando o ponto 372 da coor-
denada X, representada graficamente no diagrama. O mesmo acontece nas demais linhas
5.1 Interpretação dos Componentes UML 50
(27 a 29), onde em name = “Top” apresenta a coordenada Y e em “Width” e “Height” as
dimensões do nó que está representado visualmente pela Figura 5.1.
Finalmente, a terceira parte (linha 34) apresenta os atributos
name="Text"type="string»Máquina Virtual que indicam que o elemento declarado na
parte 1 do trecho do script “OwnedViews [0] corresponde ao nó criado pelo usuário na
ferramenta StarUML de String = “Máquina Virtual”.
5.1.2 Interpretação de Artefatos (Serviços)
Para a interpretação da representação visual dos serviços e de aplicações, foi criado um
artefato (nomeado de Serviço 1) dentro do nó denominado “Máquina Virtual” no diagrama
de deployment da ferramenta, ilustrado pela Figura 5.3.
Figura 5.3: Exemplo de Representação visual de um artefato UML (Serviço).
A partir da Figura 5.3 pode-se obter o trecho em script do nó “Máquina Virtual”, que
permaneceu da mesma maneira que descrito na Figura 5.2 e também o trecho referente ao
artefato nomeado de “Serviço 1”, percebido na Figura 5.4.
Figura 5.4: Script correspondente ao artefato (Serviço 1) da Figura 5.3.
5.1 Interpretação dos Componentes UML 51
O artefato da Figura 5.4 possui padrões similares ao da Figura 5.2 por conter as mesmas
três partes anteriormente analisadas, cuja parte 1 corresponde ao elemento do vetor Owned-
Views [], no qual o artefato foi alocado na posição [1], o atributo type = “UMLArtifactView”
que caracteriza o tipo do componente UML como do tipo artefato e o identificador pelo
atributo “guid”.
O script percebido na Figura 5.4 é também caracterizado por conter na segunda parte,
(trecho contido no retângulo 2), as coordenadas gráficas (X e Y) do artefato. Além de conter
(na linha 64) a String de nome designada pelo programador ao artefato, neste exemplo,
denominada de “Serviço 1”.
5.1.3 Interpretação de Associações
Para identificar as associações foi criado um outro exemplo com dois nós (”Nó 1” e ”Nó
2”), como pode ser percebido na Figura 5.5 e estabelecida uma associação entre os mes-
mos. Após a criação do componente associação foi descoberto que a ferramenta gera como
saída um trecho adiconal de script que apresenta o atributo type="UMLAssociationView",
correspondente ao tipo da associação e que, neste exemplo, ela foi armazenada no vetor
OwnedViews na posição [2] (como ilustrado na Figura 5.6).
Figura 5.5: Representação visual da associação entre dois Nós.
Como pode ser percebido na Figura 5.6, a saída para a associação UML também está
dividida em três partes (numeração da Figura 5.6), cuja primeira corresponde ao elemento
do vetor OwnedViews, tipo e identificador, a segunda corresponde às coordenadas visuais
(X e Y) e a terceira se refere aos atributos “Head” e “Tail” que estão designados aos iden-
tificadores dos nós “Nó 2” e “Nó 1” respectivamente. Como pode ser observado na Figura
5.7.
Após a análise do script da Figura 5.7 é possível observar a realiza-
ção da associação entre os Nós, já que a linha 86 possui o identificador
name="Head»xJKbnzb+P0ejH/tscC7PVwAA, o qual é idêntico ao identificador atri-
5.1 Interpretação dos Componentes UML 52
Figura 5.6: Script correspondente ao componente Associação da Figura 5.5.
Figura 5.7: Script correspondente aos componentes Associação e Nós da Figura 5.5.
buído ao atributo guid do “Nó 2” na linha 52, assim como é notória a percepção de que na
linha 87 consta o identificador name="Tail»1lMd4rzMu0mijjg9mwAglgAA, que corresponde
ao identificador atribuído a guid do “Nó 1” (na linha 23).
5.1.4 Interpretação de Dependências
Para analisar a saída gerada por dependências na notação UML, foi criado um exemplo
com um nó que representa uma máquina virtual (“Máquina Virtual”) e dentro deste nó, dois
artefatos, um serviço (denominado de “Serviço 1”) e uma aplicação (nomeada de “App”), a
qual depende deste serviço. Este diagrama pode ser observado na Figura 5.8.
Pode-se perceber que assim como na subseção anterior, referente à metalinguagem de
saída relacionada ao componente UML da associação, o componente da dependência apre-
sentou o mesmo padrão de comportamento, onde nos atributos “Head” e “Tail” constam
os identificadores de cada artefato ligados à dependência, (no caso do exemplo, os artefatos
5.1 Interpretação dos Componentes UML 53
Figura 5.8: Representação de uma dependência UML entre Nós.
“Serviço 1” e “App”). O trecho do script relacionado ao componente da dependência pode
ser percebido na Figura 5.9.
Figura 5.9: Script correspondente aos componentes Dependência e os Nós da Figura 5.8.
Na Figura 5.9 pode-se observar que (na linha 112) o atributo type da dependência se
apresentou como UMLDependencyView, o que possibilita a identificação desta relação entre
componentes UML, como uma dependência. Além disso, foi percebido que nas dependên-
cias o identificador do artefato ligado ao atributo Head (“App”) sempre depende do identifi-
cador ligado ao Tail (“Serviço 1”).
5.1.5 Interpretação dos Artefatos contidos em um Nó
Nesta investigação foi descoberto que a saída gerada pela StarUML para as associações e
dependências UML estão relacionadas aos demais componentes da UML através de identifi-
cadores (guid), porém não foi possível perceber o relacionamento entre, por exemplo, um Nó
5.1 Interpretação dos Componentes UML 54
e seus Artefatos (através de guid), característica essencial para identificar por exemplo, que
conjuntos de serviços estão contidos em cada Nó. Como pode ser percebido visualmente no
exemplo citado na Figura 5.8, onde o nó “Máquina Virtual” possui dois serviços de software
(artefatos denominados de “Serviço 1” e “App”) que estão contidos nele.
Figura 5.10: Script correspondente aos Nós da Figura 5.8.
Para a interpretação no escopo do relacionamento entre nós (Máquinas Virtuais) e arte-
fatos (Serviços), foi necessária a identificação das coordenadas dos mesmos, no âmbito de
descobrir quais artefatos estão contidos na envoltória de um nó. Para isso, faz-se necessária
a obtenção das coordenadas (x,y) a partir dos valores obtidos de cada componente UML.
Como exemplificado na Figura 5.10, o atributo, Left corresponde à coordenda X superior
esquerda (Xo) e o atributo Top está relacionado à coordenada Y superior esquerda (Yo),
5.1 Interpretação dos Componentes UML 55
conforme a expressão (1).
(1)
Xo = Left;
Yo = Top;
Para obtenção das coordenadas (x,y) na margem inferior direta, faz-se necessário o cál-
culo apresentado na expressão (2), a qual utiliza os atributos Width e Height.
(2)
Xi = Xo + Width;
Yi = Yo + Height;
Ao utilizar como referência a saída gerada pela Figura 5.8, (conforme a Figura 5.10),
percebeu-se que ao calcular as coordenadas dos elementos UML de acordo com as expres-
sões (1) e (2) foram obtidos os valores para as coordenadas do nó “Máquina Virtual” e do
artefato “App”, conforme a Figura 5.11.
Figura 5.11: Exemplo das coordenadas dos Nós (representação visual).
5.1 Interpretação dos Componentes UML 56
5.1.6 Interpretação dos componentes Part UML
O componente Part (também conhecido como container) do diagrama de implantação é visu-
almente representado dentro da envoltória de um nó. Na solução proposta por esta pesquisa,
o elemento Part pode representar um sistema operacional instalado em um nó (máquina vir-
tual), uma chave de acesso de um nó (provedor de nuvem) ou ainda um identificador de um
nó (instância de VM).
Para que fosse entendido o comportamento de um componente UML do tipo Part foi adi-
cionado visualmente este elemento em um diagrama de implantação (previamente explanado
e visualmente representado pela Figura 5.8), conforme pode ser percebido na Figura 5.12.
Para este componente Part foi obtido o script correlato à Figura 5.13.
Figura 5.12: Exemplo do componente Part de String Sistema Operacional (representaçãovisual).
Figura 5.13: Script correspondente à Figura 5.12.
No exemplo da Figura 5.13 foi possível perceber que (na linha 52) o
5.2 Implementação do Módulo Associador 57
componente Part se apresenta como um elemento do vetor "ContainedVi-
ews[]" de índice [0] do tipo type="UMLPartView" e que possui o identificador
guid="omRbZMQI5k6gi6OdNL6FIAAA".
Ademais, foi percebido que um dos identificadores do componente Part (na linha 60), no-
meado de “ContainerViews” estabeleceu equivalência com o identificador “guid” (da linha
23) do Nó que o elemento Part está contido visualmente, o Nó de nomenclatura “Máquina
Virtual” da Figura 5.12. Finalmente, foi observado que (na linha 63) pode ser identificada
a nomenclatura do componente Part modelado pelo usuário (que é uma String com o valor
“Sistema Operacional”).
5.2 Implementação do Módulo Associador
Para a interpretação do código em UML, foi implementado na solução o módulo Associador,
que utiliza os modelos Geral e Específico (modelados pelo usuário desenvolvedor) como
entrada na solução proposta.
A rotina de execução do módulo Associador foi dividida em duas etapas: (i) Interpretação
do Modelo Geral e (ii) Interpretação do Modelo Específico, cujo o código foi escrito na
linguagem de programação Java para a interpretação dos componentes UML.
Para a interpretação dos Modelos Geral e Específico foram usados arquivos de entrada,
os quais lidos linha a linha (primeiro o arquivo relacionado ao Modelo Geral e em seguida
ao Específico) através de um "‘BufferedReader"’ que foi implementado em duas Classes,
a primeira classe nomeada de "‘Associador"’ (Geral) e a segunda "‘AssociadorEspecifico"’,
onde cada uma das duas possui um método denominado "‘Ler()"’.
O método "‘Ler()"’ da classe Associador corresponde ao bloco de código responsável
pela leitura do arquivo do Modelo Geral enquanto que na classe AssociadorEspecifico ele
corresponde à leitura do arquivo do Modelo Específico. O método Ler() em ambas as classes
contem blocos de código em comum no âmbito de identificar os componentes UML, tanto
na leitura do arquivo Geral como do Específico. Porém, o método "‘Ler()"’ contém blocos
de código diferentes à medida em que identifica o que cada componente UML representa.
Para melhor explanar as similaridades dos blocos de código de "‘Ler()"’ esta seção foi
dividida em três subseções, a primeira explana os blocos de código que o método "‘Ler"’
5.2 Implementação do Módulo Associador 58
possui em comum nas duas Classes e as outras duas apresentam a implementação de "‘Ler()"’
para a interpretação de cada Modelo (Geral e Específico) separadamente.
5.2.1 Leitura dos Arquivos de Entrada - Modelos Geral e Específico
Para a interpretação dos modelo Geral e Específico foi implementado o método "‘Ler()"’, que
realiza a leitura de um arquivo de entrada correspondente aos Modelos Geral e Específico
como por exemplo:"‘ModeloGeral.uml"’ e "‘ModeloEspecifico.uml"’.
A cada linha lida no arquivo o algoritmo busca pela substring "‘OwnedViews"’, que re-
ferencia um componente UML do tipo artefato, nó, associação ou dependência. Quando a
linha do arquivo que contém a substring "‘OwnedViews"’ é encontrada, o método busca por
uma outra substring na mesma linha do arquivo, onde essa substring pode ser: (i) "‘UMLNo-
deView"’ que representa um Nó, (ii) "‘UMLArtifactView"’ que representa um artefato, (iii)
"‘UMLAssociationView"’ que representa uma associação (apenas usado na interpretação do
Modelo Específico) e (iv) "‘UMLDependencyView"’ que representa uma dependência. Essa
implementação pode ser percebida no código do Código Fonte 5.1.
No Código Fonte 5.1 pode-se perceber que para cada tipo de componente UML foi atri-
buído um valor inteiro na variável "‘type"’ e que cada valor em inteiro corresponde a um tipo
de componente UML.
Código Fonte 5.1: Diferenciação dos Tipos de OwnedViews
i f ( s t r . ma tches ("(.*)\"OwnedViews(.*)" ) )
{
. . .
sw i t ch ( t i p o )
{
case "UMLNodeView" :
System . o u t . p r i n t l n ("Tipo NODE" ) ; t y p e =1;
break ;
case "UMLArtifactView" :
System . o u t . p r i n t l n ("Tipo Artefato" ) ; t y p e =2;
break ;
case "UMLAssociationView" :
System . o u t . p r i n t l n ("Tipo Associacao" ) ; t y p e =3;
break ;
5.2 Implementação do Módulo Associador 59
case "UMLDependencyView" :
System . o u t . p r i n t l n ("Tipo Dependencia" ) ; t y p e =4;
break ;
d e f a u l t : System . o u t . p r i n t l n ("" ) ;
}
Além da diferenciação e busca pelas substrings de cada tipo (artefato, nó, associação e
dependência) em "‘OwnedViews"’, caso a substring "‘OwnedViews"’ não seja encontrada
também é feita uma busca pela substring "‘ContainerViews"’ que corresponde a um com-
ponente PartUML (como foi descrito na subseção 5.16 Interpretação dos Componentes Par-
tUML).
Na ocorrência da substring "‘ContainerViews"’, é verificado se a substring "‘PartUML-
View"’ também está presente na mesma linha e em caso afirmativo, à variável "‘type"’ é
atribuído um valor inteiro "‘5"’, como pode ser observado no Código Fonte 5.2.
Código Fonte 5.2: Identificação de uma PartUML
i f ( s t r . ma tches ("(.*)OBJ name=\"ContainedViews(.*)" ) )
{
a u x i l i a r _ d e _ l i n h a = l i n h a ;
i n t a u x I n i c i o T I P O = s t r . indexOf ("\"UMLPartView" ) ;
i n t auxFimTIPO = s t r . indexOf ("\" guid" ) ;
System . o u t . p r i n t l n ( a u x I n i c i o T I P O +" "+
auxFimTIPO ) ;
S t r i n g t i p o = s t r . s u b s t r i n g ( a u x I n i c i o T I P O +1 ,
auxFimTIPO ) ;
t y p e =5; / / pode s e r um componente PartUML
i f ( t y p e ==5)
{
i f ( s t r . ma tches ("(.*)REF name=\"
ContainerView\">(.*)" ) )
{
5.2 Implementação do Módulo Associador 60
. . . / / é de f a t o um PartUML
}
}
Além disso, foi também implementado um bloco para a busca pelo identificador (ID)
de cada componente UML. O algoritmo permanece na mesma linha do arquivo de leitura e
busca pela substring de início "‘guid="’ e final "‘>"’, onde entre esse início e fim da substring
está contido um valor do tipo String que corresponde ao identificador do componente UML.
O código desta busca pode ser percebido no Código Fonte 5.3.
Código Fonte 5.3: Busca pelo identificador de um componente UML
i n t a u x I n i c i o I D = s t r . indexOf ("guid=\"" ) ;
i n t auxFimID = s t r . indexOf ("\">" ) ;
S t r i n g ID = s t r . s u b s t r i n g ( a u x I n i c i o I D +6 , auxFimID ) ;
s e t I D ( ID ) ;
Após a identificação dos componentes UML pela variável "‘type"’ foram implementados
três blocos de código "‘if"’: (i) o primeiro possui um bloco que verifica se a variável "‘type"’
possui o valor 1 (tipo Nó) ou 2 (tipo Artefato), (ii) o segundo bloco verifica se a variável
type possui o valor 3 (tipo associação) ou 4 (tipo dependência) e (iii) o terceiro verifica se à
variável "‘type"’ foi atribuído o valor 5 (PartUML).
Em seguida à verificação do valor da variável "‘type"’ (tipo do componente UML) foi co-
dificado para cada tipo UML blocos de código com objetivo de coletar os atributos referentes
aos componentes UML.
Para "‘type"’=1 (tipo Nó) ou "‘type"’=2 (tipo Artefato) foi codificado a coleta de dados
como as coordenadas de localização visual dos componentes UML representadas por "‘left"’,
"‘top"’, "‘width"’ e "‘height"’ (exatamente nessa ordem), bem como o nome do componente
UML pela variável "‘NOME"’.
Como pode ser percebido no Código Fonte 5.4, para a coleta dos dados relacionados às
coordenadas ("‘left"’, "‘top"’, "‘width"’ e "‘height"’ nessa ordem) dos componentes UML,
foram verificados na leitura das linhas do arquivo o "‘casamento"’ com os caracteres conti-
dos nas substrings de início "‘r>̈"’ e final "‘</"’, onde entre esses caracteres de início e final
da substring está um valor String que foi convertido para inteiro e contem a respectiva co-
ordenada. Para os caracteres contidos nas substrings de início "‘g>̈"’ e final "‘</XP"’ está o
5.2 Implementação do Módulo Associador 61
valor em String que representa o nome do Artefato ou Nó. Para melhor visualização perceba
como está disposto o script explicado nos exemplos das Figuras 5.1 e 5.2.
Código Fonte 5.4: Identificação das Coordenadas e Nome dos Nós e Artefatos
i f ( t y p e ==1 | | t y p e ==2) / / OBJETO NÓ ou ARTEFATO
{
i f ( a u x i l i a r _ d e _ l i n h a +3 == l i n h a ) {
i n t auxIn ic ioLEFT = s t r . indexOf ("r\">" ) ;
i n t auxFimLEFT = s t r . indexOf ("</" ) ;
S t r i n g LEFT = s t r . s u b s t r i n g ( auxIn ic ioLEFT +3 ,
auxFimLEFT ) ;
s e t L e f t ( I n t e g e r . p a r s e I n t ( LEFT ) ) ;
System . o u t . p r i n t l n ( LEFT ) ;
}
e l s e i f ( a u x i l i a r _ d e _ l i n h a +4 == l i n h a ) {
i n t auxIn ic ioTOP = s t r . indexOf ("r\">" ) ;
i n t auxFimTOP = s t r . indexOf ("</" ) ;
S t r i n g TOP = s t r . s u b s t r i n g ( auxIn ic ioTOP +3 ,
auxFimTOP ) ;
s e tT op ( I n t e g e r . p a r s e I n t (TOP) ) ;
System . o u t . p r i n t l n (TOP) ;
}
e l s e i f ( a u x i l i a r _ d e _ l i n h a +5 == l i n h a ) {
i n t auxInicioWIDTH = s t r . indexOf ("r\">" ) ;
i n t auxFimWIDTH = s t r . indexOf ("</" ) ;
S t r i n g WIDTH = s t r . s u b s t r i n g ( auxInicioWIDTH +3 ,
auxFimWIDTH ) ;
s e t W i d t h ( I n t e g e r . p a r s e I n t (WIDTH) ) ;
System . o u t . p r i n t l n (WIDTH) ;
}
e l s e i f ( a u x i l i a r _ d e _ l i n h a +6 == l i n h a ) {
i n t auxInicioHEIGHT = s t r . indexOf ("r\">" ) ;
i n t auxFimHEIGHT = s t r . indexOf ("</" ) ;
S t r i n g HEIGHT = s t r . s u b s t r i n g ( auxInicioHEIGHT +3 ,
auxFimHEIGHT ) ;
5.2 Implementação do Módulo Associador 62
System . o u t . p r i n t l n (HEIGHT) ;
s e t H e i g h t ( I n t e g e r . p a r s e I n t (HEIGHT) ) ;
a u x i l i a r _ d e _ l i n h a =0; / / para de comparar as
l i n h a s das coordenadas
}
i f ( s t r . ma tches ("(.*)name=\"Text\" type=\"string\">(.*)" )
)
{
i n t auxInicioNOME = s t r . indexOf ("g\">" ) ;
i n t auxFimNOME = s t r . indexOf ("</XP" ) ;
S t r i n g NOME = s t r . s u b s t r i n g ( auxInicioNOME +3 ,
auxFimNOME ) ;
System . o u t . p r i n t l n (NOME) ;
Para a coleta dos atributos dos componentes UML do tipo Associação (com valor de
"‘type"’=3) e do tipo Dependência ("‘type"’=4) foi criado um bloco de código para a ob-
tenção dos atributos "‘Head"’ e "‘Tail"’, onde no tipo Associação e Dependência, ambos os
atributos correspondem a ligação entre dois nós pelos seus identificadores, já para o com-
ponente do tipo Dependência, o atributo "‘Head"’ corresponde ao identificador do Serviço
(Artefato) que depende do Serviço representado pelo identificador do atributo "‘Tail"’.
A identificação das variáveis "‘Head"’ e "‘Tail"’ para os tipos de componentes UML
Associação e Dependência foi realizada através da busca por substrings de início "‘d "’ e
final "‘/XP"’ sendo percebida no Código Fonte 5.5.
Código Fonte 5.5: Identificação dos links e Nome dos Nós e Artefatos
e l s e i f ( t y p e == 3 | | t y p e == 4) / / A s s o c i a ç ã o e Dependência
{
i f ( s t r . ma tches ("(.*)name=\"Head\">(.*)" ) )
{
i n t auxInicioHEAD = s t r . indexOf ("d\">" ) ;
i n t auxFimHEAD = s t r . indexOf ("</XP" ) ;
S t r i n g HEAD = s t r . s u b s t r i n g ( auxInicioHEAD +3 ,
auxFimHEAD ) ;
se tHead (HEAD) ;
}
e l s e i f ( s t r . ma tches ("(.*)name=\"Tail\">(.*)" ) )
5.2 Implementação do Módulo Associador 63
{
i n t aux In i c ioTAIL = s t r . indexOf ("\">" ) ;
i n t auxFimTAIL = s t r . indexOf ("</XP" ) ;
S t r i n g TAIL = s t r . s u b s t r i n g ( aux In i c ioTAIL +2 ,
auxFimTAIL ) ;
s e t T a i l ( TAIL ) ;
Depois de coletados os atributos referentes aos componentes UML foi implementada
a criação de listas de objetos, como listas de objetos nós, máquinas virtuais, provedores
de nuvem, instância de máquina, serviços (artefatos), sistemas operacionais e atributos dos
serviços. Contudo, a instanciação desses objetos e a criação de suas respectivas listas foram
realizadas de maneira diferente com relação a cada modelo (Geral e Específico).
5.2.2 Método Ler - Modelo Geral
O código do método "‘Ler()"’ referente à Classe Associador (Geral), cujo papel é de inter-
pretar e coletar dados dos componentes UML contidos no modelo Geral, foi implementado
para a criação de listas de objetos (de acordo à proposta do Modelo Geral).
O método da classe funciona da seguinte forma: para cada tipo de componente UML
foi desenvolvido um bloco de código para a criação dos objetos (do tipo Serviço, Máquina
Virtual, Sistema Operacional, Dependência e Atributo de Serviço), onde para cada valor da
variável "‘type"’ representa um tipo de objeto.
Para cada tipo de componente UML foi instanciado um objeto e este objeto foi alocado
em uma lista de objetos do mesmo tipo. Em seguida o tipo recebe o valor "‘0"’ e todo
processo do método "‘Ler()"’ é repetido até que o algoritmo chegue ao final do arquivo.
O código desenvolvido pode ser observado no Código Fonte 5.6 e no Apêndice as Classes
UMLNode, UMLartefato, UMLdependencia e UMLPart.
Código Fonte 5.6: Criação das Listas de Objetos (Nós, Serviços, Dependências e PartUML)
i f ( t y p e == 1) / / Máquinas V i r t u a i s
{
UMLnode node = new UMLnode ( ge t ID ( ) , g e t L e f t ( ) ,
ge tTop ( ) , ge tWid th ( ) , g e t H e i g h t ( ) , NOME) ;
L i s t a N o d e s . add ( node ) ;
}
5.2 Implementação do Módulo Associador 64
e l s e i f ( t y p e == 2) / / S e r v i ç o s
{
UMLar tefa to a r t e f a t o = new UMLar tefa to ( ge t ID ( ) ,
g e t L e f t ( ) , ge tTop ( ) , ge tWid th ( ) , g e t H e i g h t ( ) ,
NOME) ;
L i s t a A r t e f a t o s . add ( a r t e f a t o ) ;
}
t y p e =0;
. . .
i f ( t y p e == 4) / / Dependênc ias
{
UMLdependencia d e p e n d e n c i a = new UMLdependencia ( ge t ID ( ) ,
ge tHead ( ) , g e t T a i l ( ) ) ;
L i s t a D e p e n d e n c i a . add ( d e p e n d e n c i a ) ;
}
t y p e =0;
. . .
i f ( t y p e == 5) / / PartUML pode s e r p a r t e de um a t r i b u t o do s e r v i ç o ou
S i s t e m a O p e r a c i o n a l
{
PartUML p a r t e = new PartUML (NOME, ge t ID ( ) ) ;
L i s t a P a r t . add ( p a r t e ) ;
t y p e =0;
}
Categorização dos componentes "‘PartUML"’
Assim que é interpretado o Modelo Geral, faz se a distinção dos componentes "‘PartUML"’
como sendo objetos do tipo sistema operacional ou atributos de serviços, para isso foi desen-
volvido um algoritmo que varre os objetos da lista de serviços e verifica se o identificador
dos objetos "‘PartUML"’ é igual a algum identificador dos objetos da lista de serviços e em
caso afirmativo o objeto "‘PartUML"’ é adicionado na lista de atributos do respectivo serviço
e removido da lista de "‘PartUML"’ original. No fim, todos os componentes "‘PartUML"’
que permaneceram na lista original são adicionados numa lista de sistemas operacionais.
5.2 Implementação do Módulo Associador 65
5.2.3 Método Ler - Modelo Específico
Para o método "‘Ler()"’ da Classe "‘AssociadorEspecífico"’ que recebe como parâmetro o
caminho do arquivo do Modelo Específico, também foram implementadas listas de objetos
de Classes correspondentes a Provedor de Nuvem, Instância de Máquina, Máquina Virtual,
Associação e Container, onde os objetos Container (também conhecidos por PartUML) po-
dem representar a chave de acesso do provedor de nuvem, a instância de máquina na nuvem
e o caminho do repositório ou pasta em que os serviços da máquina virtual estão localizados.
Nesse método ocorrem as seguintes etapas: logo após a coleta dos atributos dos compo-
nentes UML foi implantado no método "‘Ler()"’ que de acordo com cada tipo de componente
UML realiza a criação de uma lista de objetos alocando os objetos em suas listas. Depois,
ao valor de "‘type"’ é atribuído zero, assim o algoritmo lê a próxima linha do arquivo e re-
pete todo o processo do método Ler() até que se encerre o arquivo. Tal abordagem pode ser
percebida no Código Fonte 5.7.
Código Fonte 5.7: Criação das Listas de Objetos (Nós, Associações e Container)
i f ( t y p e == 1)
{
Nodes node = new Nodes ( ge t ID ( ) , NOME, g e t L e f t ( ) , ge tTop ( ) ,
ge tWid th ( ) , g e t H e i g h t ( ) ) ;
L i s t a N o d e s . add ( node ) ;
t y p e = 0 ;
}
. . .
i f ( t y p e == 3)
{
UMLassociacao a s s o c = new UMLassociacao ( ge t ID ( ) , ge tHead ( ) ,
g e t T a i l ( ) ) ;
L i s t a A s s o c i a c a o . add ( a s s o c ) ;
t y p e = 0 ;
}
. . .
5.3 Implementação do Módulo Empilhador 66
i f ( t y p e ==5)
{
C o n t a i n e r Ct = new C o n t a i n e r (NOME, ge t ID ( ) ) ;
L i s t a C o n t a i n e r . add ( Ct ) ;
t y p e = 0 ;
}
5.3 Implementação do Módulo Empilhador
Para definir a pilha de software (dependência entre os serviços de software) e também definir
os serviços pertencentes às suas respectivas máquinas virtuais foi codificado, a partir da
solução proposta por esta pesquisa, o módulo Empilhador.
O módulo Empilhador é somente pertencente à implementação relacionada ao arquivo
do Modelo Geral, uma vez que somente este modelo possui um ou mais serviços em sua
definição e uma ou mais máquinas virtuais onde os serviços estão alocados.
Para facilitar o entendimento e a própria implementação do Empilhador, foi definida uma
classe nomeada de "‘Empilhador"’, a qual contem alguns métodos, cujo três deles são usados
para reduzir a complexidade na comparação das coordenadas dos serviços com as máquinas
virtuais (se um determinado serviço pertence a uma máquina virtual). Os métodos da classe
"Empilhador"serão abordados como subseções nesta seção.
5.3.1 Relacionamento de Dependências com Serviços (Artefatos)
Para relacionar as dependências com os serviços foram utilizadas duas listas de objetos,
obtidas a partir do módulo Associador (anterior a este), a primeira denominada de "‘lista-
Dependencia"’ que contém uma lista de objetos da classe "‘UMLdependencia"’ e a segunda
nomeada de "‘listaArtefatos"’ que corresponde a uma lista de objetos do tipo "‘UMLarte-
fato"’ (que são os objetos referentes aos serviços de software).
Para que a relação serviços e dependências fosse bem sucedida inicialmente foi imple-
mentado na classe "‘UMLartefato"’ (classe correspondente aos serviços do Modelo Geral)
um vetor de atributos chamado de "‘DependeDe"’ que tem por utilidade indicar qual(is) o(s)
serviço(s) (através do identificador ID) que o objeto da lista de serviços (listaArtefatos) de-
5.3 Implementação do Módulo Empilhador 67
pende para ser excutado. O processo de identificação desse tipo de dependência entre servi-
ços foi realizada com a implementação do Código Fonte 5.8 que também pode ser observado
ilustrativamente pela Figura 5.14.
Código Fonte 5.8: Método Relaciona Dependências com Serviços
p u b l i c s t a t i c vo id R e l a c i o n a D e p e n d e n c i a C o m A r t e f a t o s ( ) {
f o r ( i n t i =0 ; i < A s s o c i a d o r . g e t L i s t a A r t e f a t o s ( ) . s i z e ( ) ; i ++) {
f o r ( i n t j =0 ; j < A s s o c i a d o r . g e t L i s t a D e p e n d e n c i a ( ) . s i z e ( ) ; j ++) {
i f ( A s s o c i a d o r . g e t L i s t a A r t e f a t o s ( ) . g e t ( i ) . gu id . e q u a l s (
A s s o c i a d o r . g e t L i s t a D e p e n d e n c i a ( ) . g e t ( j ) . head ) )
{
A s s o c i a d o r . g e t L i s t a A r t e f a t o s ( ) . g e t ( i ) . se tDependeDe (
A s s o c i a d o r . g e t L i s t a D e p e n d e n c i a ( ) . g e t ( j ) . t a i l ) ;
}
}
}
}
Figura 5.14: Ilustração do Algoritmo no Código Fonte 5.8.
Na Figura 5.14 pode se notar que cada objeto da lista de objetos Dependência possui
os atributos "‘head"’ e "‘tail"’ correspondentes aos identificadores dos serviços Service[b] e
Service[a] respectivamente, onde Service [b] depende de Service[a]. Além disso, os objetos
Artefato (que são os Serviços) possuem o seu prórpio identificador.
O algoritmo representado pelo Código Fonte 5.8 varre toda a lista de objetos dependên-
cia ("‘getListaDependencia()"’) para cada artefato. Quando o identificador (guid) do objeto
artefato em questão for igual ao identificador do atributo "‘head"’ de um objeto na lista de
dependências, então o vetor de atributos "‘dependeDe"’ do objeto artefato (serviço) recebe
o atributo "‘tail"’ do objeto dependência em questão. Com isso um serviço obterá o serviço
5.3 Implementação do Módulo Empilhador 68
que ele depende para ser executado. Este mesmo processo de forma inversa é realizado para
a obtenção do identificador, por exemplo, de um serviço pai que dependa de um serviço fi-
lho, onde o filho armazenará o ID do serviço pai em uma variável denominada "‘anterior"’
(usada mais tarde para a criação da pilha de software).
5.3.2 Relacionamento de Máquinas Virtuais com Serviços
Na concepção do Modelo Geral é possível que um usuário desenvolvedor elabore uma ou
várias máquinas virtuais e para cada uma delas, que sejam alocados um ou muitos serviços
de software. Logo, ainda que o módulo Associador tenha realizado a tarefa de criar uma lista
de objetos de serviços e outra de máquinas virtuais, somente (puramente) com estes objetos
é impossível obter-se a relação de serviços contidos em máquinas virtuais, a não ser que
apenas exista uma e somente uma máquina virtual onde todos os serviços estariam ligados
a mesma. Por isso foram implementados no código da classe "‘Empilhador"’ métodos para
relacionar os serviços com suas respectivas máquinas virtuais.
Para a estabelecer a relação entre entre os serviços que estão dentro da envoltória de suas
respectivas máquinas virtuais foi implementado um método que varre uma lista de máquinas
virtuais (nós) para cada serviço (artefato), onde para cada serviço é verificado se o serviço
percente a envoltória (se as coordenadas X e Y do serviço estão contidas na envoltória do
nó) do objeto máquina virtual (nó), a implementação dessa proposta pode ser percebida no
Código Fonte 5.9
Código Fonte 5.9: Relacionamento entre a Lista de Máquinas Virtuais e Lista de Serviços
f o r ( i n t w=0; w< g e t L i s t a N o d e s ( ) . s i z e ( ) ;w++) {
f o r ( i n t i =0 ; i < g e t L i s t a A r t e f a t o s ( ) . s i z e ( ) ; i ++) {
i f ( Empi lhador . Pertence_ao_NODE ( g e t L i s t a N o d e s ( ) . g e t (w) . X1 , g e t L i s t a N o d e s
( ) . g e t (w) . X0 , g e t L i s t a N o d e s ( ) . g e t (w) . Y1 , g e t L i s t a N o d e s ( ) . g e t (w) . Y0 ,
g e t L i s t a A r t e f a t o s ( ) . g e t ( i ) . Xa , g e t L i s t a A r t e f a t o s ( ) . g e t ( i ) . Ya ) == t rue )
{
g e t L i s t a N o d e s ( ) . g e t (w) . Lis taDeArtefa tosdoNODE . add ( g e t L i s t a A r t e f a t o s ( ) .
g e t ( i ) ) ;
g e t L i s t a A r t e f a t o s ( ) . remove ( i ) ;
}
5.3 Implementação do Módulo Empilhador 69
}}
Foi observado que essa abordagem representada no Código Fonte 5.9 de relacionamento
entre nós e artefatos apresentou uma complexidade algorítmica de O(N*M), com "‘N"’ nós
e "‘M"’ serviços, já que para todos os N nós de uma lista são verificados todos M serviços
de outra lista (N*M vezes). Contudo foi percebido que essa técnica, a medida em que se
aumenta o número de N e M possui complexidade quadrática e em alguns casos desvantajosa.
Para reduzir a complexidade do algoritmo de relacionamento entre máquinas virtuais e
serviços foi desenvolvido um algoritmo geométrico de complexidade O((N+M)+ (M*log M)
+ (N*log N)), que quando N>=7 e M>=10 se apresentou de menor complexidade algorítmica
que a solução anterior de complexidade O (N*M).
Por isso, para os casos em que o número de máquinas virtuais é inferior a sete e que o
número de serviços é inferior a dez foi utilizada a solução de complexidade O(N*M), porém
nas demais ocorrências será executado pelo algoritmo a solução de complexidade O((N+M)+
(M*log M) + (N*log N)) que está explanado na subseção abaixo.
A solução de menor complexidade foi implementada em cinco etapas: (i) a ordenação da
lista de VMs pela coordenada X, (ii) a ordenação da lista de objetos serviços pela coordenada
X, (iii) a criação de sublistas de serviços pela coordenada X, (iv) a ordenação de cada sublista
de serviços por Y e (v) o relacionamento de máquinas virtuais e sublistas de serviços. Onde
o algoritmo de ordenação utilizado para ordenar as listas de objetos pelo atributo coordenada
X ou Y foi o heapsort de complexidade O(n*log n), com n elementos em uma lista.
Criação das Sublistas de Serviços
Após a etapa de desenvolvimento de ordenação da lista de objetos de serviços pela coorde-
nada X foi implementada a criação de sublistas de serviços, onde cada sublista compreende
um intervalo do eixo horizontal X.
O estabelecimento do intervalo do eixo X foi implementado da seguinte maneira: o algo-
ritmo armazena numa variável (nomeada de "intervalo") o maior valor da coordenada de X
(que é o último elemento da lista de serviços) e subtrai do menor valor de X (que é o primeiro
objeto da lista de serviços) e em seguida, divide essa variável pela quantidade de nós (VMs),
obtendo assim o intervalo de X para as sublistas de serviços.
5.3 Implementação do Módulo Empilhador 70
Para delimitar o valor de X em que uma sublista de serviços inicia e termina, foi decla-
rado um vetor nomeado de "‘X limite[]"’ que contem valores do eixo X, onde cada elemento
de "‘X limite[]"’ possui valores separados por um mesmo intervalo (que foi definido previa-
mente pela variável "‘intervalo"’). Essa implementação de intervalos e o vetor "‘X limite[]"’
podem ser percebidas no Código Fonte 5.10 e para melhor compreensão, visualizada na
Figura 5.15.
Código Fonte 5.10: Método Definir Intervalo entre Sublistas
p u b l i c s t a t i c i n t [ ] D e f i n i r _ I n t e r v a l o ( ) {
i n t numero_de_nodes = A s s o c i a d o r . g e t L i s t a N o d e s ( ) . s i z e ( ) ;
i n t i n t e r v a l o = ( i n t ) ( ( MAX_intervalo − M I N _ i n t e r v a l o ) / numero_de_nodes ) ;
. . .
X _ l i m i t e [ 0 ] = 0 ;
X _ l i m i t e [ 1 ] = i n t e r v a l o + M I N _ i n t e r v a l o ;
f o r ( i n t i =2 ; i <= numero_de_nodes ; i ++)
{
X _ l i m i t e [ i ] = X _ l i m i t e [ i −1] + i n t e r v a l o ;
}
re turn X _ l i m i t e ;
}
Após a definição dos intervalos das sublistas de serviços foi desenvolvido o código de
criação dessas sublistas, com cada sublista referente aos serviços que estão dentro de um
determinado intervalo do eixo X. Para isso, inicialmente o algoritmo varre os N serviços da
lista de serviços e verifica se um serviço de índice em questão possui um atributo referente
à coordenada do eixo X dentro do intervalo do vetor "‘X limite[1]"’, caso possua, seu índice
será gravado na variável "‘VetorMAX[]"’ que delimita cada sublista de serviços pelo índice e,
assim, o algoritmo passa para o próximo objeto em lista de serviços até que seja encontrado
um serviço que não possua um X no intervalo de X limite[1], então será incrementado 1
no índice do vetor "‘X limite[]"’ e no vetor "‘VetorMAX[]"’ a fim de delimitar a próxima
5.3 Implementação do Módulo Empilhador 71
Figura 5.15: Ilustração do Algoritmo no Código Fonte 5.10.
sublista (e todo o processo é repetido até que chegue ao fim da lista de serviços). Essa
proposta pode ser percebida no exemplo da Figura 5.16.
Figura 5.16: Criação de Sublistas de Serviços pelo Intervalo do eixo X.
Relacionamento de Máquinas Virtuais e Sublistas de Serviços
Finalmente, foi implemtentado um código de ordenação heapsort para que cada sublista de
serviços (individualmente) fosse ordenada pela coordenada Y. Com isso, pode se perceber
que cada sublista está dentro de um mesmo intervalo de X e ordenada por Y. Quando ocorrer
o algoritmo da busca de relacionamento entre as sublistas de serviços e a lista de máquinas
virtuais, a complexidade não irá tender a ser quadrática, já que não será necessário que seja
varrida a lista com todos os N serviços para todas as M máquinas virtuais, pois com cada
sublista em um intervalo de X e ordenada por Y, apenas seriam varridos os K serviços de
cada sublista, onde N é igual ao somatório de K.
5.3 Implementação do Módulo Empilhador 72
Logo, sabendo que N é igual a soma de todos os K serviços das sublistas, onde N é
o número total de serviços, temos que o custo para o relacionamento da lista das M má-
quinas virtuais com os K serviços de cada sublista é O(N+M), que o custo de ordenação
por X da lista de N serviços e da ordenação por Y nas sublista é de O(N*log N) e que o
a complexidade da ordenação de máquinas virtuais por X é de O(M*log M), totalizando
a complexidade dessa abordagem de relacionamento de máquinas virtuais com serviços de
O(N+M)+O(N*log N)+O(M*log M) que é menos custoso que a abordagem convencional de
complexidade O(N*M) quando M>=7 e N>=10.
5.3.3 Criação da Pilha de Software
Depois do processo de descoberta dos serviços com suas respectivas máquinas virtuais, cada
máquina virtual possuirá uma lista de serviços com suas dependências, porém desordenados
e sem ligação direta uns com os outros, por isso faz se necessária a criação de uma pilha
de software para cada máquina virtual. Esta pilha de software é composta pelos serviços e
aplicação na ordem em que devem ser instalados, para que por exemplo um serviço A que
depende de um serviço B, seja implantado apenas após a implantação do serviço B.
Para a criação da pilha de software de cada máquina virtual individualmente foi imple-
mentado um algoritmo baseado no algoritmo de ordenação topológica. A ideia da solução
consiste em montar um grafo, cujos nós desta estrutura de dados são os objetos serviços
(contidos na lista de serviços de cada VM), onde para cada serviço há uma variável chamada
de "‘anterior"’ que contém o valor do identificador (ID) do serviço pai (o serviço a que é dado
o suporte), o identificador (ID) do próprio serviço em questão e uma lista de dependências
nomeada de "‘ListaDependeDe[]"’ (lista de serviços que o serviço em questão depende).
Logicamente, o grafo de serviços que servirá de base para a criação da pilha de software,
já foi implementada quando foi executado o algoritmo de relacionamento entre dependências
e serviços, através dele, cada serviço recebeu um valor para o atributo "‘anterior"’ e a lista
dependências de serviços "‘ListaDependeDe[]"’. Logo, o grafo apenas precisa de um ponto
de partida que inicia com uma busca pela lista de serviços, no âmbito de encontrar o serviço
raiz (a aplicação) que possui um valor nulo na varivável "‘anterior"’. Um exemplo do grafo
da solução pode ser percebido na Figura 5.17
Depois que identificado o serviço raiz do grafo, foi implementado um algoritmo que
5.3 Implementação do Módulo Empilhador 73
Figura 5.17: Exemplo da Estrutura Lógica do Grafo de Serviços.
realiza uma busca em profundidade pelo serviço que possui a lista de dependências ("‘de-
pendeDe[]"’) com valor nulo (vazia). Quando encontrado o serviço que possui a lista depen-
deDe[] vazia, ele é empilhado na pilha de software e o serviço pai (o seu anterior) é buscado.
Em seguida, da lista de dependências do serviço pai é removida a dependência que ele tinha
com o serviço filho, que acabou de ser empilhado. Então é verificado se este serviço pai pos-
sui mais algum serviço na sua lista de dependências. Em caso afirmativo o mesmo processo
é realizado (até que a lista do serviço pai fique vazia e todos os filhos sejam empilhados)
e, caso a lista de dependências do serviço pai seja nula (vazia), então ele é empilhado e o
seu serviço pai é buscado e assim sucessivamente, até que o algoritmo retorne à raiz e a raiz
não possua nenhuma dependência. O peseudocódigo deste algoritmo pode ser percebido em
Código Fonte 5.11.
Código Fonte 5.11: Algoritmo de Criação da Pilha de Software
j = S e r v i ç o R a i z . i d ;
5.4 Implementação do Módulo Alocador 74
whi le ( S e r v i ç o R a i z . l i s t a D e p e n d e D e != n u l l )
{
i f ( s e r v i ç o [ j ] . dependeDe ( ) == n u l l ) / / s e não depende de ninguém
{
Empi lha r ( S e r v i ç o [ j ] ) ;
j = B u s c a r S e r v i ç o A n t e r i o r ( s e r v i ç o [ j ] . a n t e r i o r ) ; / / busca na l i s t a
de s e r v i ç o s o ID do s e r v i ç o p a i que s e r á o novo " ‘ j " ’
S e r v i ç o [ j ] . DependeDe ( ) . remove ( ) ;
}
e l s e / / s e e x i s t e um ou mais s e r v i ç o s na l i s t a de d e p e n d ê n c i a s
{
j = Busca rP rox imaDependenc ia ( s e r v i ç o [ j ] . dependeDe ( ) ) ; / / busca na l i s t a
de s e r v i ç o s o ID do s e r v i ç o f i l h o que s e r á o novo " ‘ j " ’
}
}
5.4 Implementação do Módulo Alocador
Após a interpretação do Modelo Específico, faz se necessária a alocação de(s) provedor(es)
de nuvem às máquinas virtuais e o estabelecimento das instâncias de máquinas (machine
image) na nuvem com as máquinas virtuais que se deseja implantar.
O módulo Alocador utiliza como parâmetro de entrada (tudo que foi obtido a partir do
módulo AssociadorEspecífico que são) todas as listas de objetos coletados do Modelo Espe-
cífico, são elas: lista de nós, cujos nós podem ser máquinas virtuais, provedores de nuvem
ou imagens de máquina virtual e os atributos do tipo "‘container"’(PartUML) que são atri-
butos dos objetos nós e podem representar o repositório dos serviços nas máquinas virtuais,
o identificador da imagem de VM e a chave de acesso ao provedor de nuvem.
Tendo em vista que o módulo Alocador recebe uma lista de nós contendo vários tipos de
nós em diferentes categorias e que os atributos dos nós como "‘PartUML"’ também possuem
diferentes categorias, foi implementado para este módulo uma classe chamada "‘Alocador"’
que realiza quatro etapas: (i) a correlação dos atributos da lista "‘containers"’ com os objetos
da lista de nós, (ii) a separação das listas de nós em categorias, tais quais: nuvem, imagem
de VM e VM, (iii) o relacionamento do(s) objeto(s) provedor(es) de nuvem com a lista de
5.4 Implementação do Módulo Alocador 75
objetos de máquinas virtuais e (iv) o relacionamento da lista de imagem(ns) de VM(s) com
a lista de objetos de máquinas virtuais.
5.4.1 Correlação dos Atributos "‘PartUML"’ com os Nós
Para relacionar os atributos especificados pelo desenvolvedor no Modelo Específico com
os seus respectivos nós, onde cada nó possui um tipo diferente de atributo, foi codificado
um método nomeado de "‘RelacionarNodesContainer"’ que varre todos os "‘i"’ nós da lista
"‘ListaNodes"’ e compara os casos em que o identificador ("‘guid"’) dos nós é igual ao iden-
tificador ("‘guid"’) dos atributos ("‘container"’) em "‘ListaContainer"’, em caso afirmativo
o objeto nó em questão recebe como atributo o nome do "‘container"’, essa implementação
pode ser observada no Código Fonte 5.12.
Código Fonte 5.12: Método que Relaciona os Containers com os Nós
p u b l i c s t a t i c vo id R e l a c i o n a r N o d e s C o n t a i n e r ( ) {
f o r ( i n t i = 0 ; i < g e t L i s t a N o d e s ( ) . s i z e ( ) ; i ++)
{
f o r ( i n t j = 0 ; j < g e t L i s t a C o n t a i n e r ( ) . s i z e ( ) ; j ++)
{
i f ( g e t L i s t a N o d e s ( ) . g e t ( i ) . gu id . e q u a l s ( g e t L i s t a C o n t a i n e r ( )
. g e t ( j ) . gu id ) )
{
g e t L i s t a N o d e s ( ) . g e t ( i ) . s e t C o n t a i n e r ( g e t L i s t a C o n t a i n e r ( ) .
g e t ( j ) . nome ) ;
break ;
}
}
}
}
5.4.2 Separação de Listas de Nós em Listas de Objetos por Categorias
Após o relacionamento entre os nós e seus atributos, foi percebido que era preciso imple-
mentar um bloco de código para a categorização dos nós contidos na lista de objetos nós, já
que eles poderiam fazer parte de três categorias de nós: (i) provedor de nuvem, (ii) máquina
5.4 Implementação do Módulo Alocador 76
virtual e (iii) imagem de VM na nuvem. Para isso foi implementado um método de separação
da lista de nós em listas de uma das três categorias.
O método para distribuir os objetos da listas de nós em suas respectivas categorias pode
ser percebido no Código Fonte 5.13 e foi implementado da seguinta forma: para cada objeto
na lista de nós é verificado se o atributo container do nó possui a substring "‘ami"’ ou "‘ssh"’,
caso o atributo do nó inicie com a substring "‘ami"’ o objeto nó é adicionado numa lista de
objetos correspondente a instância de VM (nomeada de "‘ListaInstanciaMaquina"’), caso o
atributo do nó inicie com a substring "‘ssh"’ o objeto é adicionado a uma lista de provedores
de nuvem (ListaProvedorNuvem) e caso contrário o nó, objeto da lista de nós, entra como
parâmetro no construtor de uma lista de objetos de máquinas virtuais (ListaVM).
Código Fonte 5.13: Método que Separa os Nós em Categorias
p u b l i c s t a t i c vo id S e p a r a r L i s t a s ( )
{
f o r ( i n t i = 0 ; i < g e t L i s t a N o d e s ( ) . s i z e ( ) ; i ++) {
S t r i n g s t r = g e t L i s t a N o d e s ( ) . g e t ( i ) . g e t C o n t a i n e r
( ) ;
i f ( s t r . ma tches ("ami(.*)" ) )
{
L i s t a I n s t a n c i a M a q u i n a . add ( g e t L i s t a N o d e s ( )
. g e t ( i ) ) ; / / imagem de VM
} e l s e i f ( s t r . ma tches ("ssh(.*)" ) )
{
Lis taProvedorNuvem . add ( g e t L i s t a N o d e s ( ) .
g e t ( i ) ) ; / / nuvem
} e l s e
{
VM vm = new VM( g e t L i s t a N o d e s ( ) . g e t ( i ) .
guid , g e t L i s t a N o d e s ( ) . g e t ( i ) . nome ,
g e t L i s t a N o d e s ( ) . g e t ( i ) . g e t C o n t a i n e r ( ) ,
g e t L i s t a N o d e s ( ) . g e t ( i ) . Xa ,
g e t L i s t a N o d e s ( ) . g e t ( i ) . Ya ) ;
ListaVM . add (vm) ; / / VM
}
}
}
5.4 Implementação do Módulo Alocador 77
5.4.3 Relacionamento de Provedores de Nuvem e Instâncias de VM
com Máquinas Virtuais
Para relacionar os provedores de nuvem com as máquinas virutais foram utilizadas a lista
de objetos de provedores de nuvem e a lista de objetos de máquinas virtuais, obtidas na
etapa anterior (Separação de Listas) neste mesmo módulo, além da utilização da lista de
associações (obtida no módulo Associador).
A multiplicidade no relacionamento entre máquinas virtuais e provedores de nuvem per-
mite que uma nuvem possa estar ligada a várias máquinas virtuais (VM) e o relacionamento
entre VMs e instâncias de VM permite que várias VMs sejam relacionadas a mesma instân-
cia, onde essa ligação entre nuvens e máquinas virtuais, assim como instâncias e máquinas
virtuais e VMs é estabelecida por uma Associação UML.
Como explanado anteriormente no script da Figura 5.7 pode se perceber que os atributos
"‘head"’ e "‘tail"’ dos objetos que representam as Associações recebem os valores dos iden-
tificadores ("‘guid"’) dos nós (instãncia de VM, provedor de nuvem e máquina virtual) que
se relacionam através da associação.
Para que fosse possível identificar o relacionamento de provedores de nuvem com má-
quinas virtuais foi implementado um algoritmo que varre toda a lista de objetos associação
para cada objeto da lista dos provedores de nuvem e inclusive os objetos da lista de máqui-
nas virtuais. Na varredura é verificado se o atributo "‘head"’ de uma associação é igual ao
identificador do objeto provedor de nuvem e se o atributo "‘tail"’ é igual ao identificador do
objeto máquina virtual (ou vice versa).
Ao encontrar o relacionamento da associação entre provedores de nuvem e máquinas
virtuais por meio dos atributos "‘head"’ e "‘tail"’ (da associação), em cada um dos objetos
máquinas virtuais, para cada VM na lista de máquinas virtuais (ListaVM) é recebido como
atributo o objeto provedor de nuvem, isto pode ser percebido no código dessa abordagem em
Código Fonte 5.14. A mesma abordagem foi utilizada para o relacionamento entre instâncias
de VM e VMs como pode ser observado no Código Fonte 5.15.
Código Fonte 5.14: Método que Relaciona os Provedores de Nuvem com as VMs
5.4 Implementação do Módulo Alocador 78
p u b l i c s t a t i c vo id RelacionarVM_Nuvem ( ) / / a t r a v é s da l i s t a de a s s o c i a ç ã o
{
f o r ( i n t i = 0 ; i < g e t L i s t a A s s o c i a c a o ( ) . s i z e ( ) ; i ++) {
f o r ( i n t j = 0 ; j < g e tL i s t aP r o v e do r N u v em ( ) . s i z e ( ) ; j ++) {
f o r ( i n t w = 0 ; w<getLis taVM ( ) . s i z e ( ) ;w++) {
i f ( ( ( getLis taVM ( ) . g e t (w) . gu id . e q u a l s ( g e t L i s t a A s s o c i a c a o ( ) . g e t ( i
) . Head ) )&&(g e t L i s t a P r o ve d o r Nu v e m ( ) . g e t ( j ) . gu id . e q u a l s (
g e t L i s t a A s s o c i a c a o ( ) . g e t ( i ) . T a i l ) ) ) | | ( ( ge tLis taVM ( ) . g e t (w) .
gu id . e q u a l s ( g e t L i s t a A s s o c i a c a o ( ) . g e t ( i ) . T a i l ) )&&(
g e tL i s t a P r o v e d o r N u v e m ( ) . g e t ( j ) . gu id . e q u a l s ( g e t L i s t a A s s o c i a c a o
( ) . g e t ( i ) . Head ) ) ) )
{
getLis taVM ( ) . g e t (w) . se tProvedorNuvem ( g e t L i s t a P r o v e d o r N u v e m ( ) .
g e t ( j ) ) ;
break ;
}
}
}
}
}
Código Fonte 5.15: Método que Relaciona as Instâncias com as VMs
p u b l i c s t a t i c vo id R e l a c i o n a r V M _ I n s t a n c i a ( ) / / a t r a v é s da l i s t a de
a s s o c i a ç ã o {
f o r ( i n t i = 0 ; i < g e t L i s t a A s s o c i a c a o ( ) . s i z e ( ) ; i ++) {
f o r ( i n t j = 0 ; j < g e t L i s t a I n s t a n c i a M a q u i n a ( ) . s i z e ( ) ; j ++) {
f o r ( i n t w = 0 ; w<getLis taVM ( ) . s i z e ( ) ;w++) {
i f ( ( ( getLis taVM ( ) . g e t (w) . gu id . e q u a l s ( g e t L i s t a A s s o c i a c a o ( ) . g e t ( i
) . Head ) )&&( g e t L i s t a I n s t a n c i a M a q u i n a ( ) . g e t ( j ) . gu id . e q u a l s (
g e t L i s t a A s s o c i a c a o ( ) . g e t ( i ) . T a i l ) ) ) | | ( ( ge tLis taVM ( ) . g e t (w) .
gu id . e q u a l s ( g e t L i s t a A s s o c i a c a o ( ) . g e t ( i ) . T a i l ) )&&(
g e t L i s t a I n s t a n c i a M a q u i n a ( ) . g e t ( j ) . gu id . e q u a l s (
g e t L i s t a A s s o c i a c a o ( ) . g e t ( i ) . Head ) ) ) )
{
getLis taVM ( ) . g e t (w) . s e t I n s t a n c i a H a r d w (
g e t L i s t a I n s t a n c i a M a q u i n a ( ) . g e t ( j ) ) ;
break ;
5.5 Implementação do Módulo Preparador 79
}
}
}
}
}
5.5 Implementação do Módulo Preparador
Após coletados todos os dados e atributos pelo módulo Associador acerca dos serviços,
máquinas virtuais, provedores de nuvem, banco de dados, imagem de VM, repositório da
VM e após processados os dados pelos módulos Alocador e Empilhador para obtenção dos
relacionamentos entre máquinas virtuais e serviços, provedores de nuvem, instância de VM e
pilha de software, fica possibilitada a etapa de geração de código da implantação de software
na nuvem.
Para gerar o código automaticamente foi implantado o código correspondente ao módulo
Preparador (descrito no capítulo anterior), através de uma classe nomeada "‘Preparador"’.
Na classe Preparador são gerados dois arquivos de saída para cada máquina virtual modelada
pelo desenvolvedor no Modelo Geral e Específico, onde o primeiro arquivo corresponde a
um script de implantação contendo o código executável para implantação e o segundo as
regras da aplicação e serviços. Os códigos gerados para a implantação são escritos pelo
Preparador em linguagem ruby e seguem os padrões da plataforma Chef (Opscode, 2013).
5.5.1 Geração do Código do Arquivo Executável de Implantação
Para gerar o código do arquivo de implantação foi implementado um método (nomeado de
"‘PrepararArquivosKNIFE"’) que varre a lista de máquinas virtuais (obtida a partir dos três
módulos anteriores), onde para cada objeto máquina virtual é chamado um segundo método
(nomeado de "‘EscreverArquivoChefporNODE"’) que possui como parâmetros de entrada
os atributos do objeto VM em questão, são eles: a pilha de software, a nomenclatura dos
serviços, da aplicação, do sistema operacional, do provedor de nuvem, da imagem de VM e
do atributo identificador dessa imagem.
Ademais, previamente a geração de código (seguindo os padrões do arquivo Chef) são
5.5 Implementação do Módulo Preparador 80
concatenadas as Strings com os nomes dos Serviços na ordem da pilha de software (exceto
o nome da aplicação) em uma variável nomeada de "‘ServiçoComposto"’ para que seja pas-
sada como parâmetro no método que gera o código aumomaticamente. A implementação da
geração de código do primeiro arquivo pode ser percebida no Código Fonte A.1 (no Apên-
dice).
Como pode ser observado, o Código Fonte A.1 (no Apêndice) foi implementado em cinco
partes: (i) a criação ou sobrescrição do arquivo de implantação, (ii) o cabeçalho do arquivo,
contendo o caminho das definições("‘cookbooks"’) dos serviços, (iii) os nomes e definições
dos serviços e da aplicação, (iv) uma chamada às regras dos serviços e aplicação (que estão
definidas no outro arquivo que será gerado pelo Preparador) e (v) o código executável da
implantação, que contêm a especificação da nuvem, imagem de VM, sistema operacional,
pilha de software e aplicação. Uma abordagem prática será relatada na última subseção do
módulo Preparador.
5.5.2 Geração do Código das Regras da Aplicação e dos Serviços
Assim como na geração de código do arquivo de implantação, para a geração do código ar-
quivo com das regras da aplicação e dos serviços foi desenvolvido um método (denominado
de "‘PrepararArquivosKNIFE"’) que varre uma lista de máquinas virtuais, onde para cada
objeto VM foi implementado um segundo método (nomeado de "‘EscreverArquivoChefpo-
rEspecifico"’) que gera o arquivo contendo as regras da aplicação e dos serviços da pilha
de software para cada uma das máquinas virtuais, ou seja, é também gerado um arquivo
contendo as regras da aplicação e dos serviços para cada VM.
A geração do código do arquivo correspondente às regras da aplicação foi implementada
em cinco partes: (i) a criação ou sebrescrição do arquivo referente às regras dos serviços,
(ii) o cabeçalho do arquivo, composto pelo nome da aplicação e uma indicação de que ele
representa as regras, (iii) o corpo do arquivo com o nome da aplicação, o repositório da apli-
cação e dos serviços, chave de acesso ao provedor de nuvem e a "‘url"’ do banco de dados da
aplicação, (iv) opcionalmente as regras dos serviços, contendo por exemplo a versão de cada
serviço, porta, host, senha e usuário e (v) a nomenclatura de cada serviço e aplicação que
serão executados na máquina virtual, na ordem em que estão na pilha de software. O código
da Implementação dessas regras pode ser percebido no Código Fonte A.2 (no Apêndice.)
5.6 Estudo de Caso da Solução 81
5.6 Estudo de Caso da Solução
Para a visualização do código de saída gerado pela solução desta pesquisa foi implantado um
software (usado pela indústria) na nuvem com o uso da solução proposta por esta pesquisa,
cujo software implantado foi um e-commerce, produto da empresa SWX Softwares. Para a
implantação deste software foram criados os modelos Geral e Específico contendo todos os
requisitos necessários para a implantação.
No Modelo Geral foram descritos os requisitos máquina virtual com o nome de 14Com-
merce, a aplicação 14commerce-loja-virtual, os serviços RDS(servidor de banco de dados),
WordPress (sistema de gerenciamento de conteúdos para Web), Nginx que é um servidor
Web (correlato ao apache + MySql) e a url do banco de dados, além disso foram estabele-
cidas as dependências entre os serviços e modelada a descrição o sistema operacional, no
caso o Ubuntu e especificadas as versões, repositório e host para cada serviço (quando ne-
cessário). O modelo geral que foi criado para a implantação pode ser percebido na Figura
5.18.
Figura 5.18: Modelo Geral para a Implantação do e-commerce 14-commerce-loja-virtual.
5.6 Estudo de Caso da Solução 82
No modelo Específico foram descritos o provedor de nuvem que foi o Elastic Cloud
2, o repositório ("‘41 14commerce-1.5.0-rc02-02.zip"’) em que se encontram os servi-
ços e aplicação da máquina virtual (14commerce) e a imagem de VM (t1.micro) com o
identificador("‘ami-967edcff"’) da imagem na nuvem, além das associações entre a instân-
cia da VM, provedor de nuvem e máquina virtual. O modelo Específico criado pode ser
percebido na Figura 5.19
Figura 5.19: Modelo Específico para a Implantação do e-commerce 14-commerce-loja-virtual.
Após o uso dos modelos Geral e Específico como entrada na solução foram gerados os
arquivos que contem as regras da aplicação e serviços e o código executável da implantação
que podem ser percebidos respectivamente nos Códigos Fonte A.3 e A.4 (no Apêndice A).
Capítulo 6
Experimentação da Solução
Após a implementação da solução, a mesma foi avaliada através de um estudo de caso.
Contudo, para obtermos as métricas necessárias para a avaliação da solução, foi utilizado
o GQM (Goal, Question, Metric), uma abordagem de planejamento idealizada por Basili
e apresentada em (SOLINGEN; BERGHOUT, 1999). O GQM é um método que propõe
a definição das métricas (objetivas) de avaliação em uma experimentação, sobretudo uma
avaliação de software, visto que este tipo de avaliação é subjetiva. Com isso, o método
GQM inicia de um objetivo (goal) para que dele sejam elaboradas perguntas (question) e
do resultado dessas perguntas sejam estabelecidas as métricas (metric) que serão utilizadas
como medidas para a avaliação do software.
É válido ressaltar que a experimentação não foi o foco desta pesquisa e que no Estado
de Sergipe apenas foi encontrada uma empresa que lida com a implantação de software na
nuvem, por isso a experimentação foi realizada apenas como a aplicação de um estudo de
caso na empresa SWX Softwares no parque tecnológico do Estado de Sergipe (o Sergipetec).
Neste contexto, esta pesquisa focou a análise da abordagem dirigida a modelos para a
implantação automática de software na nuvem, com finalidade de avaliar o uso dos modelos
da solução, com respeito à usabilidade, aprendizado e esforço de implantação do software
na nuvem, do ponto de vista de desenvolvedores de serviços de software, no contexto da
indústria.
Como mencionado anteriormente, o método GQM parte dos objetivos que se deseja al-
cançar com o software, para que sejam realizadas perguntas a partir dos objetivos e por fim, a
elaboração das métricas que serão utilizadas na avaliação do software. Com isso temos que:
83
84
Os objetivos são:
• Avaliar a usabilidade da solução de implantação automática de software por meio de
modelos;
• Avaliar o esforço humano referente à solução de implantação automática de software
por meio de modelos;
• Avaliar a relevância da solução para o ensino da implantação de serviços de software
na nuvem;
Através dos objetivos pôde-se elaborar as questões para obtenção das métricas, que são:
• A proposta trazida pela solução de implantação dirigida a modelos é de fácil assimila-
ção (aprendizado)?
• Qual o grau de relevância da solução proposta frente aos métodos de implantação de
software sem o uso de modelos?
• Em pequena escala (1 a 3 máquinas virtuais) a solução reduziria o esforço de implan-
tação de software na nuvem ?
• Em grande escala, a solução reduziria o esforço de implantação de software na nuvem?
• Com o uso da solução ficam mais claros os conceitos de computação em nuvem e
como funciona a implantação de software na nuvem?
• É relevante o uso deste tipo de solução para o ensino de implantação de software na
nuvem?
• A solução é eficaz?
• A solução limita a realização da implantação?
• A solução apresenta riqueza e facilidade em detalhes de documentação e manutenção?
Por fim, ao realizar uma análise das perguntas e baseado nas métricas para avaliação
de software estabelecidas segundo Santos (2008) e Nielsen (1993) foram encontradas as
métricas:
6.1 Formulação de Hipóteses 85
• Apreensibilidade (facilidade de aprendizagem)
• Carga de Trabalho
• Consistência
• Atratividade
• Manutenibilidade
6.1 Formulação de Hipóteses
Previamente ao experimento foram elaboradas hipóteses dos possíveis resultados acerca das
métricas de avaliação. Para a formulação de hipóteses acerca de cada métrica de software
obtida pelo método GQM, observam-se as três hipóteses que serão utilizadas para cada va-
riável que depende dos resultados do experimento, ou seja foram elaboradas hipóteses para
cada métrica de avaliação.
Com isso, temos as hipóteses dos possíveis resultados na avaliação que são: hipóteses
nula (Ho), alternativa (H1) e alternativa (H2), onde (Ho) corresponde a hipótese que não
apresenta efeito colateral, (H1) corresponde à hipótese que se deseja alcançar e (H2) a hipó-
tese de efeito indesejado.
As variáveis Independentes (meios utilizados na avaliação do experimento que perma-
necem inalteradas em todo o experimento) são:
• Provedor de Nuvem
• Ferramenta StarUML
• Modelo Geral
• Modelo Específico
As variáveis Dependentes (métricas utilizadas como resultado da avalição do experi-
mento) são:
• Apreensibilidade (facilidade de aprendizagem)
6.1 Formulação de Hipóteses 86
• Redução da Carga de Trabalho em Pequena Escala
• Redução da Carga de Trabalho em Grande Escala
• Consistência
• Atratividade
• Manutenibilidade
HIPÓTESE 1: Para a variável dependente, Apreensibilidade (Ap):
• (Ho): (Ap)Solução = (Ap)Sem modelos.
• (H1): (Ap)Solução > (Ap)Sem modelos.
• (H2): (Ap)Solução < (Ap)Sem modelos.
HIPÓTESE 2: Para a variável dependente, Redução da Carga de Trabalho para Implan-
tação de Software em Pequena Escala (Carga Pq):
• (Ho): (Carga Pq)Solução = (Carga Pq)Sem modelos.
• (H1): (Carga Pq)Solução > (Carga Pq)Sem modelos.
• (H2): (Carga Pq)Solução < (Carga Pq)Sem modelos.
HIPÓTESE 3: Para a variável dependente, Redução da Carga de Trabalho para Implan-
tação de Software em Grande Escala (Carga Grd):
• (Ho): (Carga Grd))Solução = (Carga Grd))Sem modelos.
• (H1): (Carga Grd))Solução > (Carga Grd))Sem modelos.
• (H2): (Carga Grd))Solução < (Carga Grd))Sem modelos.
HIPÓTESE 4: Para a variável dependente, Manutenibilidade (Manut):
• (Ho): (Manut)Solução = (Manut)Sem modelos.
• (H1): (Manut)Solução > (Manut)Sem modelos.
6.2 Operação do Experimento 87
• (H2): (Manut)Solução < (Manut)Sem modelos.
Para as variáveis dependentes Atratividade e Consistência apenas foi observado o com-
portamento das mesmas no experimento, sem prévia inferência de nenhuma hipótese como
medida comparativa em relação ao experimento com e sem o uso de modelos.
6.2 Operação do Experimento
Nesta seção está descrita a operação do experimento que compreende a instrumentação uti-
lizada para o mesmo, a tarefa de preparação, execução do experimento e a maneira como foi
realizada a validação dos dados coletados.
Na etapa de execução do experimento foi utilizado um questionário aos participantes do
experimento no âmbito de se coletar dados referentes às métricas de Apreensibilidade, Carga
de Trabalho, Consistência, Atratividade e Manutenibilidade de implantação de software na
nuvem.
O questionário foi utilizado em quatro escopos, o primeiro escopo referente ao nível de
experiência do desenvolvedor de serviços, o segundo e terceiro relacionado apenas à Solução
proposta, ou seja, sem uso de comparações com outras soluções e o quarto com intuito de
comparar a solução proposta com a solução atualmente utilizada na empresa SWX Softwares
através do uso das métricas.
Escopo 1 (Geral)
P1. Qual o seu grau de familiaridade com a UML?
1-Nenhum
2-Pouco
3-Razoável
4-Familiarizado
5-Uso Constante
P2. Há quanto tempo você trabalha/ou com implantação de serviços de software na nuvem?
1-Menos de um mês
2-Menos de três meses
6.2 Operação do Experimento 88
3-Entre três meses e um ano
4-Entre um e dois anos
5-Mais de dois anos
Escopo 2 (Relacionado apenas a Solução e subjetivo)
P1. A solução atendeu suas expectativas? Comente.
1-Não
2-Moderadamente
3-Sim
P2. Para realizar a implantação de software na nuvem, é de sua preferência o uso de
modelos ou de código? Comente.
1-Codificação manual
2-Preferência pelo uso de modelos
P3. Em sua opinião, a interface da ferramenta CASE auxiliar (o StarUML) atende as
necessidades deste tipo de solução. Ou seja, ela possui interface gráfica amigável à solução
de implantação? Comente.
1-A interface deveria ser customizada
2-A interface é pouco amigável
3-A interface é amigável
Escopo 3 (Relacionado apenas a Solução e objetivo com avaliação das métricas)
P1. Você usaria a solução rotineiramente? (Atratividade)
1-Não
2-Pouco
3-Usaria somente em grande escala de implantações
4-Usaria mesmo em pequena escala de implantações
5-Sempre
6.2 Operação do Experimento 89
P2. Com o uso da solução ficam mais claros os conceitos de como funciona a implantação
de software na nuvem? (Consistência)
1-Não fica claro, a solução é demasiado complexa
2-Fica pouco claro
3-Fica claro, porém possui algumas inconsistências
4-Fica claro o funcionamento da implantação, mas faltam detalhes
5-É fiel aos requisitos necessários para a implantação de serviços na nuvem
Escopo 4 (Comparativo e objetivo com uso das métricas)
P1. A proposta trazida pela solução de implantação dirigida a modelos é de fácil
assimilação? (Apreensibilidade)
1-Não. É bastante difícil de aprender
2-Não. Ela é um pouco complicada de aprender
3-Mais ou menos. É preciso um bom tempo de prática
4-Sim. Tive poucos problemas para aprender
5-Sim. É bastante intuitiva
P2. A proposta trazida pela solução convencional é de fácil assimilação?
(Apreensibilidade)
1-Não. É bastante difícil de aprender
2-Não. Ela é um pouco complicada de aprender
3-Mais ou menos. É preciso um bom tempo de prática
4-Sim. Tive poucos problemas para aprender
5-Sim. É bastante intuitiva
P3. Em pequena escala, 1 a 3 máquinas virtuais, a solução com o uso de modelos reduziu o
esforço de implantação de software na nuvem? (Carga de Trabalho)
1-Não. É preferível outra solução de implantação
2-Não em pequena escala.
3-Razoavelmente. Depende do serviço que se deseja implantar
6.2 Operação do Experimento 90
4-Quase sempre. Porém não em todos os casos
5-É sempre preferível utilizar a solução com modelos
P4. Em pequena escala, 1 a 3 máquinas virtuais, a solução sem o uso de modelos reduziu o
esforço de implantação de software na nuvem? (Carga de Trabalho)
1-Não. É preferível outra solução de implantação
2-Não em pequena escala.
3-Razoavelmente. Depende do serviço que se deseja implantar
4-Quase sempre. Porém não em todos os casos
5-É sempre preferível utilizar a solução sem o uso de modelos
P5. Em grande escala, mais de 4 máquinas virtuais, a solução com o uso de modelos
reduziu o esforço de implantação de software na nuvem? (Carga de Trabalho)
1-Não. É preferível outra solução de implantação
2-Não. Somente em raríssimos casos
3-Razoavelmente. Depende do serviço que se deseja implantar
4-Quase sempre. Porém não em todos os casos
5-É sempre preferível utilizar a solução com modelos
P6. Em grande escala, mais de 4 máquinas virtuais, a solução sem o uso de modelos
reduziu o esforço de implantação de software na nuvem? (Carga de Trabalho)
1-Não. É preferível outra solução de implantação
2-Não. Somente em raríssimos casos
3-Razoavelmente. Depende do serviço que se deseja implantar
4-Quase sempre. Porém não em todos os casos
5-É sempre preferível utilizar a solução sem o uso de modelos
P7. A proposta trazida pela solução de implantação dirigida a modelos é bem documentada
e de fácil manutenção? (Manutenibilidade)
1-Não. Não se apresenta arquitetura clara para o desenvolvedor
2-É possível, mas a arquitetura é difícil de ser visualizada
6.2 Operação do Experimento 91
3-Mais ou menos.
4-Sim. A arquitetura é clara.
5-É muito fácil de realizar manutenção. A arquitetura é bastante intuitiva.
P8. A proposta trazida pela solução de implantação por meio de codificação é bem
documentada e de fácil manutenção? (Manutenibilidade)
1-Não. Não se apresenta arquitetura clara para o desenvolvedor
2-É possível, mas a arquitetura é difícil de ser visualizada
3-Mais ou menos.
4-Sim. A arquitetura é clara.
5-É muito fácil de realizar manutenção. A arquitetura é bastante intuitiva.
6.2.1 Instrumentação para o Experimento
Para realizar a coleta de dados referente às métricas Apreensibilidade, Consistência, Atrati-
vidade e Redução na Carga de Trabalho de implantação de software na nuvem pela Solução
Proposta, os materiais utilizados foram:
• Computador Pessoal - PC
• Provedor de Nuvem - (AWS)
• Ferramenta CASE StarUML
• Arquitetura de Rede Internet
• Solução Desenvolvida por esta Pesquisa para a Implantação de Software na Nuvem
Dirigida por Modelos
6.2.2 Preparação
Para o experimento foi solicitado aos participantes que utilizassem o software da Solução
desenvolvida por esta pesquisa para que fosse implantado um serviço de software no pro-
vedor de nuvem da Amazon Web Services (AWS). Os participantes foram treinados acerca
de como deveriam realizar a implantação com o uso da solução dirigida por modelos. Com
6.2 Operação do Experimento 92
isso, eles ficaram cientes de que para a implantação de software na nuvem utilizariam a fer-
ramenta auxiliar StarUML para modelar os modelos Geral e Específico (como entrada para
a implantação de software).
6.2.3 Execução do Experimento
Na execução do experimento os participantes elaboraram os modelos Geral e Específico para
implantar um serviço de software na AWS, cujos modelos foram utilizados como entrada na
Solução proposta por esta pesquisa.
O software que foi implantado para a execução do experimento foi o 14-Commerce, um
serviço web de loja virtual da empresa SWX. Esta aplicação web possui dependências como,
os serviços Niginx, WordPress e RDS (Relational Database Service) com seus respectivos
modelos Geral e Específico, como podem ser observados nas Figuras 5.18 e 5.19 (no capítulo
5).
Após a implantação bem sucedida dos serviços de software, os participantes responderam
a um questionário que continha as perguntas apresentadas anteriormente na seção Operação
do Experimento referentes ao software da solução.
6.2.4 Resultados e Análise
Após a execução da solução pelos desenvolvedores foi obtido o serviço e-commerce implan-
tado na nuvem AWS e aplicado um questionário aos desenvolvedores participantes afim de
se obter as métricas de Apreensibilidade, Carga de Trabalho, Consistência, Atratividade e
Manutenibilidade.
O questionário possuiu quatro escopos, sendo o primeiro relacionado a experiência do
desenvolvedor, o segundo questionando o impacto da solução, o terceiro para medir a atra-
titividade, limitações e a consistência da solução com o código para o desenvolvedor e o
quarto com intuito de realizar um comparativo das demais métricas obtidas pela solução
com modelos contra a solução manual.
Após aplicado o questionário, como resultado do primeiro escopo de perguntas foram
obtidos os dados apresentados na Tabela 6.1. Nela podemos perceber que todos os partici-
pantes apresentaram um nível pelo menos razoável de familiarização com a UML (tinham
6.2 Operação do Experimento 93
Participantes Familiaridade com a UML Experiência com Implantação1 Razoável Mais de dois anos2 Familiarizado Um a dois anos3 Razoável Entre 3 meses e um ano4 Familiarizado Menos de um mês
Tabela 6.1: Tabela referente as perguntas do Escopo 1
Participantes Atendeu Expectativas? Preferência de Solução Parte gráfica1 Sim Modelos A interface é pouco amigável2 Moderadamente Modelos Deveria ser mais customizada3 Sim Manual Interface pouco amigável4 Sim Modelos A interface é amigável
Tabela 6.2: Tabela referente as perguntas do Escopo 2
conhecimento prévio da UML) e que dois participantes possuiam experiência de mais de um
ano com implantação de software na nuvem.
Com a aplicação do questionário também foram obtidos os dados relacionados às per-
guntas do segundo escopo que podem ser percebidos de forma organizada pela Tabela 6.2,
nesta pode-se perceber que para todos os participantes as expectativas oferecidas pela solu-
ção foram atentidas, que três dos quatro participantes responderam preferência pela solução
dirigida a modelos, enquanto apenas um optou pela solução manual e que três dos partici-
pantes responderam que a interface da ferramenta para a criação dos modelos UML deveria
ser customizada, onde apenas um respondeu que não.
Para os escopos 3 e 4 do questionário cada pergunta correspondeu a uma das métricas
que se desejou analisar, onde para cada alternativa de uma pergunta foi atribuído um peso
relacionado à métrica que a pergunta correspondia, cujo peso tinha valor de 1(um) a 5(cinco),
onde quanto mais próximo do valor 5(cinco) mais correlacionado à métrica a alternativa
estaria.
Após coletados os dados referentes ao escopo 3 do questionário foram obtidos os resul-
tados das métricas de Atratividade e Consistência dispostos na Tabela 6.3, onde para cada
métrica foi obtido um valor numérico correspondente ao peso da métrica em questão, onde
o peso máximo é o valor cinco (5). Além disso, para cada métrica foi obtida uma média
de acordo com os pesos atribuídos por cada participante que também pode ser percebida na
6.2 Operação do Experimento 94
última coluna da Tabela 6.3.
Com as médias obtidas pelo escopo 3 pode-se perceber que para o usuário desenvolvedor
a Solução aprensentou Consistência enquanto solução de implantação de software na nuvem
em um nível de 90% e Atratividade de uso para os usuários em 60%.
No caso da moderada aceitação no que se refere a Atratividade deve-se ao fato de que
75% dos participantes responderam que a interface deveria ser customizada, já o fato de a
consistência ter tido de 90% de aceitação deveu-se ao fato de que para os usuários a solução
por modelos em alguns casos mais específicos ainda possui fatores limitantes, embora dois
dos quatro participantes tenham respondido que a solução por modelos seja fiel aos requisitos
de implantação de software na nuvem.
Métricas Pesos por Participantes Média Ponderada dos Pesos
Atratividade 4 3 2 3 3Consistência 4 5 4 5 4,5
Tabela 6.3: Escopo 3 Resultado da Solução Proposta.
Depois de aplicado o questionário para cada participante foram obtidos os dados referen-
tes ao Escopo 4. Foi realizada a coleta e análise dos dados, onde para cada métrica foram
obtidos os valores que podem ser percebidos nas Tabelas 6.4 e na Tabela 6.5, cuja primeira
apresenta os resultados com o uso da solução e a segunda sem o uso da solução.
Métricas Pesos por Participantes Média Ponderada dos Pesos
Apreensibilidade 4 4 4 5 4,25Redução da Carga de Trabalho(Pequena Escala) 3 3 4 5 3,75Redução da Carga de Trabalho(Grande Escala) 4 4 4 5 4,25
Manutenibilidade 4 4 4 4 4
Tabela 6.4: Resultado com uso da Solução Proposta.
Analisadas as Tabelas 6.4 e 6.5 pode se perceber que segundo os participantes, com o
uso de modelos para a implantação de software na nuvem, todas as médias das métricas de
apreensibilidade, redução nas cargas de trabalho em grande e pequena escala de implantação
e a capacidade de manutenibilidade no que se refere à implantação de software na nuvem se
apresentaram maiores que as médias dessas mesmas métricas com relação ao uso da solução
6.2 Operação do Experimento 95
Métricas Pesos por Participantes Média Ponderada dos Pesos
Apreensibilidade 3 2 2 4 2,75Redução da Carga de Trabalho(Pequena Escala) 3 2 3 1 2,25Redução da Carga de Trabalho(Grande Escala) 3 4 3 2 3
Manutenibilidade 3 2 2 3 2,5
Tabela 6.5: Resultado SEM a Solução Proposta.
convencional por meio de codificação. Fato que torna-se mais claro como pode-se perceber
no gráfico da Figura 6.1.
Figura 6.1: Gráfico de Médias das Métricas com e sem uso da Solução.
No gráfico da Figura 6.2 pode-se observar em pontos percentuais o impacto na diferença
dos pesos atribuídos pelas médias de cada participante com relação ao uso e não uso da solu-
ção por modelos para a implantação de software na nuvem. Pôde-se observar que em média
nos participantes com relação a cada uma das métricas de manutenibilidade, apreensibilidade
e redução da carga de trabalho em pequena escala de implantação foi percebido um impacto
positivo de 30% em pontos percentuais com o uso da solução e que em relação à carga de
trabalho em grande escala de implantação foi percebido um impacto positivo de 25%.
Logo foram satisfeitas todas as hipóteses (H1) para todas as métricas avaliadas com re-
lação à experimentação da solução proposta por esta investigação.
6.2 Operação do Experimento 96
Figura 6.2: Gráfico do Impacto nas Métricas com o uso da Solução.
Capítulo 7
Conclusão
Nesta pesquisa foi apresentada uma abordagem dirigida a modelos para implantação au-
tomática de software na nuvem, que utiliza diagramas UML como entrada, no âmbito de
prover uma redução na carga de trabalho para os desenvolvedores na tarefa de implantação
de software na nuvem.
Além disso, foi elaborado nesta investigação a concepção dos modelos UML de entrada
na solução de implantação, de forma que possibilitou ao usuário desenvolvedor criar os mo-
delos de implantação intuitivamente com pouco esforço de aprendizado.
Ademais, esta pesquisa definiu um padrão para modelos de implantação de software
em nuvem (consistente com o código), onde os requisitos para a tarefa de implantação de
aplicações na nuvem ficaram mais visíveis, visto que não existe a definição de um padrão
universal de modelos para a implantação de software na nuvem.
A solução possibilita a geração automática de código dos modelos UML de implanta-
ção em algoritmos escritos em ruby com auxílio da ferramenta Chef, onde os códigos são
executados e a implantação de software é realizada de maneira automática. Para que isso
fosse possível foi elaborado pela pesquisa o comportamento de dois modelos de implantação
na nuvem, um geral e um específico, onde o primeiro corresponde ao comportamento das
máquinas virtuais (VMs) e todos os serviços que se deseja implantar e o segundo é referente
às características específicas da nuvem em que são instalados os serviços e VMs.
Após a solução implentamentada e funcional, foi realizado um experimento envolvendo
uma situação real em parceria com a empresa SWX Softwares, especializada para lidar com
implantação de software na nuvem. No experimento os desenvolvedores da corporação utili-
97
98
zaram o produto elaborado por esta pesquisa e a ferramenta StarUML para a criação dos mo-
delos (conforme instruídos do comportamento da solução dos modelos geral e específico).
Em seguida foi respondido um questionário para verificação das métricas de apreensibili-
dade, manutenibilidade e redução da carga de trabalho dos desenvolvedores.
Como resultado do experimento (estudo de caso aplicado à quatro participantes) da so-
lução desenvolvida por esta investigação, percebeu-se que houve uma redução na carga de
trabalho em média de até 25% para os desenvolvedores, além do impacto positivo de 30%
de aumento nas métricas de apreensibilidade e manutenibilidade da solução de implantação
de software na nuvem.
Como trabalho futuro espera-se desenvolver uma interface gráfica customizada para a
criação dos modelos UML, visto que a ferramenta StarUML, utilizada como apoio para a
criação dos modelos possui componentes gráficos pouco específicos de acordo com o que foi
projetado para o ideal de implantação de software na nuvem nesta pesquisa, comprometendo
a assimilação dos modelos para o usuário desenvolvedor. Ademais será investigada uma
maneira de possiblitar que a solução gere a implantação automática de uma mesma máquina
virtual dois ou mais provedores de nuvem, inclusive em nuvens híbridas.
Finalmente é esperado que futuramente seja replicado o experimento em maior escala e
utilizados os testes de normalidade e testes estatísticos paramêtricos para maior relevância
e validação do experimento, visto que devido à falta de participantes, somente foi realizado
um estudo de caso.
REFERÊNCIAS
ALMEIDA, M. et al. MODAClouds architecture - Initial version.[S.l.], May 2013. Disponível em: <http://www.modaclouds.eu/wp-content/uploads/2012/09/MODACloudsD3.2.1MODACloudsArchitectureInitialV ersion.pdf>.
AMAZON. Amazon Elastic Cloud. maio 2013. Disponível em:<http://aws.amazon.com/ec2>.
ARDAGNA, D. et al. Modaclouds: A model-driven approach for the design and executionof applications on multiple clouds. In: Modeling in Software Engineering (MISE), 2012ICSE Workshop on. [S.l.: s.n.], 2012. p. 50–56. ISSN 2156-788.
ARMBRUST, M. et al. A view of cloud computing. Commun. ACM, ACM, NewYork, NY, USA, v. 53, n. 4, p. 50–58, abr. 2010. ISSN 0001-0782. Disponível em:<http://doi.acm.org/10.1145/1721654.1721672>.
ARMSTRONG, D. et al. Towards a contextualization solution for cloud platform services.In: Cloud Computing Technology and Science (CloudCom), 2011 IEEE Third InternationalConference on. [S.l.: s.n.], 2011. p. 328–331.
BOEHM, B. Some future software engineering opportunities and challenges. In: NANZ, S.(Ed.). The Future of Software Engineering. Springer Berlin Heidelberg, 2011. p. 1–32. ISBN978-3-642-15186-6. Disponível em: <http://dx.doi.org/10.1007/978-3-642-15187-31>.
BURG, S. van der et al. Software deployment in a dynamic cloud: From device to serviceorientation in a hospital environment. In: Software Engineering Challenges of CloudComputing, 2009. CLOUD ’09. ICSE Workshop on. [S.l.: s.n.], 2009. p. 61–66.
CALA, J. Adaptive Deployment of Component-based Applications in Distributed Systems.218 p. Tese (Doutorado) — Faculty Of Electrical Engineering, Automatics, ComputerScience And Electronics, 2010.
CALA, J.; WATSON, P. Automatic software deployment in the azure cloud. In:Proceedings of the 10th IFIP WG 6.1 International Conference on DistributedApplications and Interoperable Systems. Berlin, Heidelberg: Springer-Verlag, 2010.(DAIS’10), p. 155–168. ISBN 3-642-13644-3, 978-3-642-13644-3. Disponível em:<http://dx.doi.org/10.1007/978-3-642-13645-012>.
CHIEU, T. et al. Simplifying solution deployment on a cloud through composite appliances.In: Parallel Distributed Processing, Workshops and Phd Forum (IPDPSW), 2010 IEEEInternational Symposium on. [S.l.: s.n.], 2010. p. 1–5.
99
REFERÊNCIAS 100
CHOW, K. O. An abstraction-driven approach for complex model-based softwaredevelopment. In: Software Engineering (WCSE), 2010 Second World Congress on. [S.l.:s.n.], 2010. v. 1, p. 133–136.
COLLABNET INC. ArgoUML. set. 2013. Disponível em: <http://argouml.tigris.org/>.
DAN, L.; DANNING, L. Applying model driven to software development: A universitylibrary case study. In: Communication Software and Networks (ICCSN), 2011 IEEE 3rdInternational Conference on. [S.l.: s.n.], 2011. p. 179–183.
DIA DEVELOPERS. Dia Diagram Editor. set. 2013. Disponível em: <http://dia-installer.de/>.
DUDIN, E. B.; SMETANIN, Y. G. A review of cloud computing. Sci. Tech. Inf. Process.,Springer-Verlag New York, Inc., Secaucus, NJ, USA, v. 38, n. 4, p. 280–284, out. 2011.ISSN 0147-6882. Disponível em: <http://dx.doi.org/10.3103/S0147688211040083>.
FAZZIKI, A. et al. A service oriented information system: A model driven approach. In:Signal Image Technology and Internet Based Systems (SITIS), 2012 Eighth InternationalConference on. [S.l.: s.n.], 2012. p. 466–473.
FOWLER. Use and Abuse Cases. In: . [S.l.: s.n.], 1998. v. 1, p. 1–2.
FRANCE; RUMPE. Model-driven development of complex software: A researchroadmap. In: 2007 Future of Software Engineering. Washington, DC, USA: IEEEComputer Society, 2007. (FOSE ’07), p. 37–54. ISBN 0-7695-2829-5. Disponível em:<http://dx.doi.org/10.1109/FOSE.2007.14>.
GAPHOR. Gaphor. set. 2013. Disponível em: <http://gaphor.sourceforge.net/>.
GOMES. Estudo do Paradigma Computação em Nuvem. 89 p. Dissertação (Mestrado) —Instituto Superior de Engenharia de Lisboa, 2012.
HAILPERN, B.; TARR, P. Model-driven development: The good, the bad, and the ugly.IBM Syst. J., IBM Corp., Riverton, NJ, USA, v. 45, n. 3, p. 451–461, jul. 2006. ISSN0018-8670. Disponível em: <http://dx.doi.org/10.1147/sj.453.0451>.
IYOOB, I.; ZARIFOGLU, E.; DIEKER, A. B. Cloud computing operati-ons research. Service Science, v. 5, n. 2, p. 88–101, 2013. Disponível em:<http://pubsonline.informs.org/doi/abs/10.1287/serv.1120.0038>.
JACKSON, D.; RINARD, M. Software analysis: A roadmap. In: Proceedingsof the Conference on The Future of Software Engineering. New York, NY,USA: ACM, 2000. (ICSE ’00), p. 133–145. ISBN 1-58113-253-0. Disponível em:<http://doi.acm.org/10.1145/336512.336545>.
JUVE, G.; DEELMAN, E. Automating application deployment in infrastructureclouds. In: Proceedings of the 2011 IEEE Third International Conference on CloudComputing Technology and Science. Washington, DC, USA: IEEE Computer Society,2011. (CLOUDCOM ’11), p. 658–665. ISBN 978-0-7695-4622-3. Disponível em:<http://dx.doi.org/10.1109/CloudCom.2011.102>.
REFERÊNCIAS 101
KALAGIAKOS, P.; KARAMPELAS, P. Cloud computing learning. In: Application ofInformation and Communication Technologies (AICT), 2011 5th International Conferenceon. [S.l.: s.n.], 2011. p. 1–4.
KDE. Umbrello The UML Modeller. out. 2013. Disponível em: <http://umbrello.kde.org/>.
KONSTANTINOU, A. V. et al. An architecture for virtual solution compositionand deployment in infrastructure clouds. In: Proceedings of the 3rd InternationalWorkshop on Virtualization Technologies in Distributed Computing. New York, NY,USA: ACM, 2009. (VTDC ’09), p. 9–18. ISBN 978-1-60558-580-2. Disponível em:<http://doi.acm.org/10.1145/1555336.1555339>.
LAND, R. A Brief Survey of Software Architecture. [S.l.], February 2002. Disponível em:<http://www.es.mdh.se/publications/294->.
LI, W. et al. A general approach to service deployment in cloud environments. In: Cloudand Green Computing (CGC), 2012 Second International Conference on. [S.l.: s.n.], 2012.p. 17–24.
LINK, S. et al. Focusing graphical user interfaces in model-driven software development.In: Advances in Computer-Human Interaction, 2008 First International Conference on.[S.l.: s.n.], 2008. p. 3–8.
LOPEZ, M. Migrating Data into Microsofts Data Platform SQL Azure. [S.l.], May2011. Disponível em: <http://www.solidq.com/sqj/JournalDocuments/2011-May-Issue/Migrating-Data-into-Microsofts-Data-Platform-SQL-Azure.pdf>.
LV, C. et al. Paas: A revolution for information technology platforms. In: Educationaland Network Technology (ICENT), 2010 International Conference on. [S.l.: s.n.], 2010. p.346–349.
MALATHI, M. Cloud computing concepts. In: Electronics Computer Technology (ICECT),2011 3rd International Conference on. [S.l.: s.n.], 2011. v. 6, p. 236–239.
MARSTON, S. et al. Cloud computing - the business perspective. Decis. Sup-port Syst., Elsevier Science Publishers B. V., Amsterdam, The Netherlands, TheNetherlands, v. 51, n. 1, p. 176–189, abr. 2011. ISSN 0167-9236. Disponível em:<http://dx.doi.org/10.1016/j.dss.2010.12.006>.
MICROSOFT COPORATION. Azure Cloud. jun. 2013. Disponível em:<http://www.windowsazure.com/en-us>.
MODELIOSOFT. Modelio The Open Source Modeling Environment. set. 2013. Disponívelem: <http://www.modelio.org/>.
MUTHUNAGAI, S. U.; KARTHIC, C. D.; SUJATHA, S. Efficient access of cloud resourcesthrough virtualization techniques. In: Recent Trends In Information Technology (ICRTIT),2012 International Conference on. [S.l.: s.n.], 2012. p. 174–178.
NIELSEN, J. Usability Engineering. [S.l.]: Boston, MA: Academic Press, 1993.
REFERÊNCIAS 102
OBJECT MANAGEMENT GROUP. Unified Modeling Language (OMG UML)Infrastructure, Version 2.4.1. 2011.
OMG. Deployment and Configuration of Component-based Distributed ApplicationsSpecification, Version 4.0. abr. 2006.
OPSCODE. Chef. jun. 2013. Disponível em: <http://www.getchef.com/>.
PLASTIC SOFTWARE. StarUML The Open Source UML/MDA Platform. 2013.Disponível em: <http://staruml.sourceforge.net/en/>.
PRESSMAN, R. S. Engenharia de software. 6 ed. São Paulo: McGraw-Hill, 2006.
RIMAL, B. P. et al. Architectural requirements for cloud computing systems: Anenterprise cloud approach. J. Grid Comput., Springer-Verlag New York, Inc.,Secaucus, NJ, USA, v. 9, n. 1, p. 3–26, mar. 2011. ISSN 1570-7873. Disponível em:<http://dx.doi.org/10.1007/s10723-010-9171-y>.
SALAPURA, V. Cloud computing: Virtualization and resiliency for data center computing.In: Computer Design (ICCD), 2012 IEEE 30th International Conference on. [S.l.: s.n.],2012. p. 1–2. ISSN 1063-6404.
SANCHEZ; CAPPELLOZZA. Antecedentes da adoção da computação em nuvem: efeitosda infraestrutura, investimento e porte. RAC Revista de Administração Contemporânea,v. 16, p. 646–663, 2012.
SANTOS, R. C. dos. Systems usability evaluation metrics review (revisão das métricas paraavaliação de usabilidade de sistemas). In: Global Business And Technology AssociationConference. GBATA 2008. [S.l.: s.n.], 2008.
SAVU, L. Cloud computing: Deployment models, delivery models, risks and researchchallenges. In: Computer and Management (CAMAN), 2011 International Conference on.[S.l.: s.n.], 2011. p. 1–4.
SOLINGEN; BERGHOUT. The Goal/Question/Metric Method: A practical guide forquality improvement of software development. [S.l.]: McGraw-Hill, 1999.
TALWAR, V.; MILOJICIC, D.; WU, Q. Approaches for service deployment. In: . [S.l.:s.n.], 2005. v. 9, p. 70–80.
TIHANYI, B. NClass. out. 2013. Disponível em:<http://nclass.sourceforge.net/support.html>.
VIOLET UML Editor. out. 2013. Disponível em:<http://alexdp.free.fr/violetumleditor/page.php>.
ZAPATA, C. M.; CHAVERRA, J. J. Una Mirada Conceptual a la GeneracionAutomatica de Codigo. Revista EIA, scieloco, p. 155 – 169, 07 2010. ISSN 1794-1237. Disponível em: <http://www.scielo.org.co/scielo.php?script=sciarttextpid =S1794− 12372010000100011nrm = iso>.
REFERÊNCIAS 103
ZHANG, Y.; LI, Y.; ZHENG, W. Automatic software deployment using user-level virtualization for cloud-computing. Future Gener. Comput. Syst., Elsevier SciencePublishers B. V., Amsterdam, The Netherlands, The Netherlands, v. 29, n. 1, p. 323–329, jan.2013. ISSN 0167-739X. Disponível em: <http://dx.doi.org/10.1016/j.future.2011.08.012>.
Apêndice A
Código Fonte A.1: Geração do Código da Implantação
p u b l i c s t a t i c vo id EscreverArquivoChefporNODE ( S t r i n g P a s t a S a i d a , S t r i n g
a p l i c a c a o , S t r i n g se rv icoCompos to , S t r i n g SO , S t r i n g nomeNODE , S t r i n g
MAQUINA, S t r i n g numeroAMI ) {
t r y {
F i l e f i l e = new F i l e ( P a s t a S a i d a +"/"+nomeNODE+".rb" ) ;
/ / s e a r q u i v o não e x i s t e , c r i e a r q u i v o
i f ( ! f i l e . e x i s t s ( ) ) {
f i l e . c r e a t e N e w F i l e ( ) ;
}
F i l e W r i t e r fw = new F i l e W r i t e r ( f i l e .
g e t A b s o l u t e F i l e ( ) ) ;
B u f f e r e d W r i t e r bw = new B u f f e r e d W r i t e r ( fw ) ;
S t r i n g caminhoPATH = "cookbooks-plataform/"+
se rv i coCompos to +"/Berksfile" ;
/ /−−−−−−−−−CABEÇALHO
bw . w r i t e ("berksfile:" ) ;
bw . newLine ( ) ;
bw . w r i t e (" path: ’"+caminhoPATH+"’" ) ;
bw . newLine ( ) ;
/ /−−−−−−−−−−−−−−−−−−−−−−COOKBOOKS−−−−−−−−−−−−−−−−
104
105
bw . w r i t e ("cookbooks:" ) ;
bw . newLine ( ) ;
i f ( s e r v i coCompos to . e q u a l s ("" ) ) {}
e l s e {
bw . w r i t e ("- "+ se rv i coCompos to +":" ) ;
bw . newLine ( ) ;
}
bw . w r i t e ("- "+ a p l i c a c a o +":" ) ;
bw . newLine ( ) ;
/ / bw . w r i t e ("− 14 Base : " ) ;
/ / bw . newLine ( ) ;
/ /−−−−−−−−−−−−−−−−−−−−−−ROLES−−−−−−−−−−−−−−−−
bw . w r i t e ("roles:" ) ;
bw . newLine ( ) ;
i f ( s e r v i coCompos to . e q u a l s ("" ) ) {}
e l s e {
bw . w r i t e ("- "+ se rv i coCompos to +":" ) ;
bw . newLine ( ) ;
}
bw . w r i t e ("- "+ a p l i c a c a o +":" ) ;
bw . newLine ( ) ;
/ / bw . w r i t e ("− 14 Base : " ) ;
/ / bw . newLine ( ) ;
/ /−−−−−−−−−−−−−−−KNIFE−−−−−−−−−−−−−−−−
bw . w r i t e ("knife:" ) ;
bw . newLine ( ) ;
bw . w r i t e (" - ec2 server create:" ) ;
bw . newLine ( ) ;
i f ( s e rv i coCompos to . e q u a l s ("" ) ) {
bw . w r i t e (" - -I "+numeroAMI+" -x "+SO+" -f "+MAQUINA+" -r ’
role["+ a p l i c a c a o +"]’" ) ; }
e l s e {
106
bw . w r i t e (" - -I "+numeroAMI+" -x "+SO+" -f "+MAQUINA+" -r ’
role["+ se rv i coCompos to +"], role["+ a p l i c a c a o +"]’" ) ;
}
/ /−−−−−−FECHA ARQUIVO−−−−−−−−−
bw . c l o s e ( ) ;
} catch ( IOExcep t ion e ) {
e . p r i n t S t a c k T r a c e ( ) ;
}}
Código Fonte A.2: Geração do Código das Regras da Implantação
p u b l i c s t a t i c vo id E s c r e v e r A r q u i v o C h e f p o r E s p e c i f i c o ( S t r i n g P a s t a S a i d a ,
S t r i n g nomeNODE , S t r i n g r e p o s i t o r i o , S t r i n g ChaveAcesso , S t r i n g
BancoDeDados , S t r i n g se rv icoCompos to , S t r i n g a p l i c a c a o )
{
t r y {
F i l e f i l e = new F i l e ( P a s t a S a i d a +"/"+"ROLE_de_"+
nomeNODE+".rb" ) ;
i f ( ! f i l e . e x i s t s ( ) ) {
f i l e . c r e a t e N e w F i l e ( ) ;
}
F i l e W r i t e r fw = new F i l e W r i t e r ( f i l e .
g e t A b s o l u t e F i l e ( ) ) ;
B u f f e r e d W r i t e r bw = new B u f f e r e d W r i t e r ( fw ) ;
/ /−−−−−−−−−−−i n i c i o −−−−−−−
bw . w r i t e ("{" ) ;
bw . newLine ( ) ;
bw . w r i t e (" \"name\": \""+ a p l i c a c a o +"\"" +"," ) ;
bw . newLine ( ) ;
bw . w r i t e (" \"description\": \"\"," ) ;
bw . newLine ( ) ;
bw . w r i t e (" \"json_class\": \"Chef::Role\"," ) ;
bw . newLine ( ) ;
bw . w r i t e (" \"default_attributes\": {" ) ;
bw . newLine ( ) ;
bw . w r i t e (" }," ) ;
107
bw . newLine ( ) ;
/ /−−−−−−−−−−−−−−−−−corpo
bw . w r i t e (" \"override_attributes\": {" ) ;
bw . newLine ( ) ;
bw . w r i t e (" \"app\": {" ) ;
bw . newLine ( ) ;
bw . w r i t e (" \"name\": \""+ a p l i c a c a o +"\"," ) ;
bw . newLine ( ) ;
bw . w r i t e (" \"repository_url\": \"\"," ) ; / / "+
r e p o s i t o r i o +"
bw . newLine ( ) ;
bw . w r i t e (" \"access_key\": \""+ ChaveAcesso
+"\"," ) ;
bw . newLine ( ) ;
bw . w r i t e (" \"tag\": \"\"," ) ; / / v e r i f i c a r
bw . newLine ( ) ;
bw . w r i t e (" \"database_url\": \""+
BancoDeDados +"\"," ) ;
bw . newLine ( ) ;
bw . w r i t e (" \"source_url\": \"" + r e p o s i t o r i o
+ "\"" ) ;
bw . newLine ( ) ;
bw . w r i t e (" }" ) ;
bw . newLine ( ) ;
bw . w r i t e (" }," ) ;
bw . newLine ( ) ;
/ / p a r t e dos s e r v i ç o s
bw . w r i t e (" \"chef_type\": \"role\"," ) ;
bw . newLine ( ) ;
/ / l i s t a s de s e r v i ç o s
bw . w r i t e (" \"run_list\": [" ) ;
bw . newLine ( ) ;
bw . w r i t e (" \"recipe[14Base]\"," ) ; / /
v e r i f i c a r
bw . newLine ( ) ;
i f ( s e r v i coCompos to . e q u a l s ("" ) ) {}
108
e l s e {
bw . w r i t e (" \"recipe["+ se rv i coCompos to +"
]\"," ) ; / / v e r i f i c a r
bw . newLine ( ) ;
}
bw . w r i t e (" \"recipe["+ a p l i c a c a o +"]\"" ) ; / /
v e r i f i c a r
bw . newLine ( ) ;
bw . w r i t e (" ]," ) ;
bw . newLine ( ) ;
bw . w r i t e (" \"env_run_lists\": {" ) ;
bw . newLine ( ) ;
bw . w r i t e (" }" ) ;
bw . newLine ( ) ;
bw . w r i t e ("}" ) ;
bw . newLine ( ) ;
/ /−−−−−−FECHA ARQUIVO−−−−−−−−−
bw . c l o s e ( ) ;
}
catch ( IOExcep t ion e ) {
e . p r i n t S t a c k T r a c e ( ) ;
}
}
Código Fonte A.3: Exemplo do Código das Regras da Implantação
{
"name" : "14S_14commerce-loja-vitual" ,
"description" : "" ,
"json_class" : "Chef::Role" ,
"default_attributes" : {
} ,
"override_attributes" : {
"app" : {
"name" : "14S_14commerce-loja-vitual" ,
"repository_url" : "" ,
109
"access_key" : "ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCa1bABmW1Gy3qQp54MWIJ
4ggzmT+dGVzJLzXOEASxdCeyFucRuX+
jxTpfrpFM7wjbpB3hlapQu4r6SxNeBymHSLUPfYCN7onj5Ll9
1iJgdgmcxGY3BIgBmAWJyVdK3UUOiIBWKL22UMtYgcLCaPU0GlKXOUQDk41eXVbBB/9
miSuFY1TtOeUt
nMDkx8o+MBJbVuY2Cbe1g51DglzMSCJfr4JA457HrFypmj4oQOt+Y4rWZWCku4BfEMr/
JUcRWgoLo/wA
JW3eKAZlEzbU2AyRcX6zEDuq3ApWzgLYMsL1fChov9TmjmTqCaukV+sKhyp1UusymlE/8
RmrbZPKf31S
h [email protected]\nssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDNRrWQJ3cWDIoN8Po0
Viw07v2Cs9W/UV9VhYgvjcZKWEsIw8baY5sQ+
pJFFWm1b5i1ZL73SVwPGcyRJCcMCVshb7Yrk0krk7/Z
MEuap9m1W3hlWuysHCyrjx8/nfr9FXOn7fxXU2uhD0uLQi21vT7sSsENDSSg+7
TmiFtl4QeTYjbZW45e
mcThdEwp4XH2macNgYAFHzkLQePAweFkuIbEJER1jK+ThFk18scvtSnYOM/
YGkm8Oq6KpBxAqzZ5wVii
zrrPeTaxtUX6LcHUabAEg9GHCLqm0Hucf+gOV5nZIo3DKJWewuLqq8Q4+
mQ8TvUrER9XaqqOm6Ux9JhG
zoFd [email protected]\n" ,
"tag" : "" ,
"database_url" : "42_2014-09-10-14commerce_tag-1.5.0_rc02-02.sql" ,
"source_url" : "41_14commerce-1.5.0-rc02-02.zip" ,
"database" : {
"host" : "factory14.cghmqpscak7o.us-east-1.rds.amazonaws.com" ,
"user" : "factory14" ,
"password" : "factory14"
} ,
"nginx" : {
"version" : "1.2.9"
} ,
"wordpress" : {
"version" : "3.9_pt_BR" ,
"repourl" : "http://wordpress.org/"
}
}
110
} ,
"chef_type" : "role" ,
"run_list" : [
"recipe[14Base]" ,
"recipe[NginPressRDS]" ,
"recipe[14S_14commerce-loja-vitual]"
] ,
"env_run_lists" : {
}
}
Código Fonte A.4: Exemplo do Código de Implantação
b e r k s f i l e :
p a t h : ’cookbooks-plataform/NginPressRDS/Berksfile’
cookbooks :
− NginPressRDS :
− 14 commerce−l o j a −v i r t u a l :
− 14 Base :
r o l e s :
− NginPressRDS :
− 14 commerce−l o j a −v i r t u a l :
− 14 Base :
k n i f e :
− ec2 s e r v e r c r e a t e :
− −I ami−967 e d c f f −x ubun tu −f t 1 . micro −r ’role[NginPressRDS], role
[14commerce-loja-virtual], role[14Base]’