universidade federal de sergipe centro de ciÊncias … · tura do provedor de nuvem. esta...

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




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




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)



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).


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


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


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


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.


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


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


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


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.


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


(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.


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-


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


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ó


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),


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.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"’


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 ;


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\">(.*)" ) )

{


. . . / / é 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


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) ;

}


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) ;

}


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 ) ;


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\">(.*)" ) )


{

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 ) ;

}


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.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-


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


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 ) ;

}


}}

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.


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


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.


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


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


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


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.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


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


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


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


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)


2-Não em pequena escala.



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)


2-Não. Somente em raríssimos 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)


2-Não. Somente em raríssimos 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


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


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


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


ú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.


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



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.


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 ( ) ;


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 ( ) ;


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]’