INSTITUTO DE COMPUTAÇÃO
Jane Dirce Alves Sandim Eleutério
Técnicas de Sistemas Autônomos e Autoadaptativos
para Apoiar Linhas de Produtos de Software Dinâmicas
CAMPINAS
2017
Técnicas de Sistemas Autônomos e Autoadaptativos para Apoiar
Linhas de Produtos de Software Dinâmicas
Tese apresentada ao Instituto de Computação da Universidade Estadual de Campinas como parte dos requisitos para a obtenção do título de Doutora em Ciência da Computação.
Orientadora: Profa. Dra. Cecília Mary Fischer Rubira
Este exemplar corresponde à versão final da Tese defendida por Jane Dirce Alves Sandim Eleutério e orientada pela Profa. Dra. Cecília Mary Fischer Rubira.
CAMPINAS
2017
Ficha catalográfica
Universidade Estadual de Campinas
Biblioteca do Instituto de Matemática, Estatística e Computação Científica Ana Regina Machado - CRB 8/5467
Eleutério, Jane Dirce Alves Sandim,
EL27t EleTécnicas de sistemas autônomos e autoadaptativos para apoiar linhas de produtos de software dinâmicas / Jane Dirce Alves Sandim Eleutério. – Campinas, SP : [s.n.], 2017.
EleOrientador: Cecília Mary Fischer Rubira.
EleTese (doutorado) – Universidade Estadual de Campinas, Instituto de Computação.
Ele1. Linhas de produto de software. 2. Sistemas de computação adaptativos. 3. Computação autônoma. 4. Software - Arquitetura. I. Rubira, Cecília Mary Fischer,1964-. II. Universidade Estadual de Campinas. Instituto de
Computação. III. Título.
Informações para Biblioteca Digital
Título em outro idioma: Techniques of autonomous and self-adaptive systems to support
dynamic software product lines
Palavras-chave em inglês:
Software product lines Adaptive computing systems Autonomic computing
Software architecture
Área de concentração: Ciência da Computação Titulação: Doutora em Ciência da Computação Banca examinadora:
Cecília Mary Fischer Rubira [Orientador] Eduardo Santana de Almeida
Claudia Maria Lima Werner Marco Paulo Amorin Vieira Breno Bernard Nicolau de França
Data de defesa: 28-07-2017
Programa de Pós-Graduação: Ciência da Computação
INSTITUTO DE COMPUTAÇÃO
Jane Dirce Alves Sandim Eleutério
Técnicas de Sistemas Autônomos e Autoadaptativos para Apoiar
Linhas de Produtos de Software Dinâmicas
Banca Examinadora:
• Profa. Dra. Cecília Mary Fischer Rubira Instituto de Computação, UNICAMP • Prof. Dr. Eduardo Santana de Almeida
Instituto de Matemática, UFBA
• Profa. Dra. Claudia Maria Lima Werner COPPE, UFRJ
• Prof. Dr. Marco Paulo Amorin Vieira
Departamento de Engenharia Informática, UC • Prof. Dr. Breno Bernard Nicolau de França
Instituto de Computação, UNICAMP
A ata da defesa com as respectivas assinaturas dos membros da banca encontra-se no processo de vida acadêmica do aluno.
Ao meu marido Pedro, por sido muito mais que marido durante esses anos e anos de dou-torado. Foi um amigo que ouviu meus lamentos nas horas difíceis, foi pai solteiro quando eu viajava e o deixava sozinho com o Leonardo, foi meu alvo quando eu precisava extra-vasar minha raiva, foi meu revisor de textos de inglês e português, foi o meu incentivador quando eu desanimei. Sem seu apoio esta conquista não seria possível.
Ao meu filho, Leonardo, que por diversas vezes perguntou se faltava muito ainda para eu terminar o doutorado.
Aos meus pais, Donaldo e Fátima, pelo apoio incondicional e pelo incentivo que sempre deram aos meus estudos.
À memória de meu sogro, Danillo Eleutério, que sempre dedicava um pouco do seu tempo para saber do andamento da minha pesquisa de doutoramento.
E, desde aquele dia,
já não durmo para descansar. Simplesmente durmo para sonhar.
Agradeço a minha orientadora, Cecília M.F. Rubira, que me ensinou a pesquisar durante todos esses anos e que me ensinou mais ainda sobre escrita em língua inglesa. E ainda me recebeu em sua casa quando precisei.
Agradeço aos meus amigos, Gisele e Daniel Gustavo, pelas inúmeras vezes que me receberam em sua casa, me ouviram, me emprestaram seu carro, e muitas outras coisas, quando eu ia à Campinas para as reuniões com a orientadora. Sentirei falta das tantas conversas com a Gisele.
Agradeço aos meus amigos da Faculdade de Computação (UFMS), em especial ao grupo de Engenharia de Software, que sempre me apoiou e entendeu meu distanciamento para me dedicar ao doutorado. Agradeço também de forma especial ao professor Nalvo F. Almeida Jr, que fez muito mais do que exigia seu papel de diretor da Faculdade de Computação, apoiando integralmente quem se dedicou a fazer doutorado e também aos professores Marcelo Turine, Henrique Mongelli e Edson Cáceres, que por diversas vezes me aconselharam e ajudaram durante esses anos. E também em especial aos amigos Francisco, Jucele, Ana Karina e Patrícia, por terem me ouvido, apoiado e ajudado tantas vezes.
Agradeço a minha amiga, Ivone, por ter compartilhado alegrias e lamentos de nossos doutorados, e por ter ajudado até na revisão desta tese.
Agradeço aos meus amigos do Instituto de Computação (Unicamp) pelas companhias nos almoços e lanches no Gatti e nos passeios pelo shopping Dom Pedro.
Agradeço aos funcionários e pesquisadores do Instituto de Instituto de Computação (Unicamp), que me auxiliaram em diferentes etapas deste projeto.
Cada vez mais, os sistemas modernos necessitam ter a capacidade de se autoadaptar às mudanças que ocorrem tanto no seu contexto de execução, quanto nas necessidades dos usuários. Pode-se citar, como exemplos de sistemas que exigem tal capacidade, as aplicações para dispositivos móveis, que precisam lidar com mudanças no ambiente, e os sistemas orientados a serviços, que precisam substituir serviços não confiáveis rapidamente interferindo minimamente na sua execução. Nesse contexto, Linha de Produtos de Soft-ware Dinâmica é uma abordagem de engenharia de softSoft-ware que pode ser utilizada para desenvolver sistemas autoadaptáveis baseados em comunalidades e variabilidades para uma família de sistemas similares. Entretanto, pesquisas recentes relataram que muitas soluções para linhas de produtos dinâmicas não conseguem cumprir todos os requisitos de adaptabilidade do sistema e, em muitos casos, elas são individualmente desenvolvi-das e sem padronização. A solução proposta nesta tese aborda o estudo de técnicas de desenvolvimento de sistemas autônomos e autoadaptativos e sua aplicação na melhoria das capacidades dinâmicas de linhas de produtos. Este trabalho envolve: (i) a defini-ção de uma taxonomia em duas dimensões, autoadaptadefini-ção e variabilidade, para abordar questões técnicas básicas do projeto e desenvolvimento de linhas de produtos dinâmicas; (ii) um modelo de referência que define diretrizes e processos de desenvolvimento para linhas de produtos de software dinâmicas com apoio para um mecanismo de variabili-dade dinâmica eficaz; e (iii) uma infraestrutura de implantação autoadaptativa estendida para atender ao modelo de referência, acompanhada de uma ferramenta de apoio. Um estudo de viabilidade foi conduzido para avaliar o modelo de referência proposto apoiado por ferramental para construir uma linha de produtos para duas plataformas diferentes, Android e JavaFX, através da medição da sobrecarga de processamento imposta pelo pro-cesso de adaptação. O estudo apresentou resultados promissores, indicando que a solução é eficiente para apoiar a construção de linhas de produtos de software dinâmicas.
Modern systems need to be able to self-adapt to changes in user needs, and changes affect-ing the system itself or its environment. Examples of systems demandaffect-ing self-adaptive capabilities include mobile devices applications, which should deal with environmental changes and service-oriented systems, which should replace unreliable services on-the-fly. In this context, dynamic software product line is an engineering approach for developing self-adaptive systems based on commonalities and variabilities for a family of similar sys-tems. However, researchers have reported many DSPL solutions fail to meet all system’s adaptability requirements, and in many cases, they are developed in ad hoc manner. The solution proposed in this thesis deals with the study of autonomous and self-adaptive systems development techniques and their application in the improvement of the dynamic capacities of product lines. Thus, this work encompasses: (i) the definition of a two-dimension taxonomy to address basic technical issues in the design and development of dynamic product lines; (ii) a reference model that provides guidelines and development processes for dynamic software product lines with support to an effective dynamic vari-ability mechanism; and (iii) a self-adaptive deployment infrastructure extended to meet the reference model, providing tooling support. We conducted a feasibility study to evalu-ate our tool-based reference model in the development of a dynamic software product line for the Android platform and for JavaFX technology. Using the study, we evaluated the feasibility of the solution by measuring the overhead imposed by the adaptation process. The study presented promising results, which indicate our solution is efficient to support the development of dynamic software product lines.
2.1 Relacionamento entre Modelo de Referência, Padrão Arquitetural,
Arqui-tetura de Referência e ArquiArqui-tetura de Software (adaptado de [29]). . . 31
2.2 Partes constituintes de um sistema autoadaptativo (adaptado de [186]). . . 32
2.3 Ciclo MAPE-K (adaptado de [110, 102]). . . 34
2.4 Classificação de software usando binding time (adaptado de [126]). . . 35
2.5 Relação entre meta level, base level e protocolo de metaobjeto (adaptado de [125]). . . 37
2.6 Primitivas do FORMS e seus relacionamentos (adaptado de [185]). . . 38
2.7 Modelo conceitual de DSPL. . . 39
2.8 Modelagem e derivação de variabilidades em SPL e DSPL. . . 40
2.9 Abordagens de modelagem de features derivadas de FODA (adaptado e estendido de [109, 39]). . . 42
2.10 Etapas e atividades do processo de revisão. . . 48
2.11 Sequência de busca. . . 49
2.12 Resultado do processo de seleção de estudos. . . 51
2.13 Classificação dos estudos em facetas. . . 53
3.1 Visão geral da infraestrutura Cosmapek. . . 63
3.2 O modelo arquitetural da infraestrutura Cosmapek. . . 65
3.3 Modelo de features da DSPL Buscame. . . 66
3.4 Modelo arquitetural da DSPL Buscame. . . 67
3.5 Documento XML de variabilidade da DSPL Buscame. . . 68
3.6 Documento XML de arquitetura da DSPL Buscame. . . 69
3.7 Intervalos de tempo para executar a atividade de análise na Buscame. . . . 70
3.8 Intervalos de tempo para executar as atividades de planejamento e execução de reconfiguração arquitetural na Buscame. . . 71
4.1 Dimensão de autoadaptação. . . 76
4.2 Dimensão de variabilidade em DSPL. . . 79
4.3 Atributos de qualidade dos subsistemas gestor e gerenciado. . . 100
5.1 Partes constituintes de um sistema autoadaptativo (adaptado de [186]). . . 111
5.2 Modelo conceitual do ISALYNE-RM. . . 112
5.3 Modelo conceitual de autoadaptação para DSPL (estendido de FORMS [185]). . . 114
5.4 Módulo de desenvolvimento de adaptação (extraído da Figura 5.2). . . 115
5.5 MAPEK-FM: Metamodelo de features para o MAPE-K aplicado a DSPLs. 118 5.6 Módulo de desenvolvimento de variabilidade (extraído da Figura 5.2). . . . 120
5.7 Metamodelo de variabilidade. . . 122
5.11 Processo de Reconfiguração do ISALYNE-RM. . . 128
5.12 Simulação da adaptação em termos de features e elementos arquiteturais. . 129
6.1 O modelo arquitetural do Reconfigurador da ISALYNE-Instance. . . 134
6.2 Seleção de features do Reconfigurador em relação ao MAPEK-FM. . . 135
6.3 Metamodelo da notação proposta para a modelagem de features. . . 136
6.4 Ferramentas e soluções que compõem a ISALYNE-IDE. . . 139
6.5 Processo de desenvolvimento de DSPLs apoiado pela ISALYNE-IDE. . . . 140
6.6 Interface gráfica com as diferentes visões da ferramenta ISALYNE-IDE. . . 140
6.7 Modelo de features da DSPL e-Shop. . . 143
6.8 Modelo PLA da DSPL e-Shop. . . 143
6.9 Mapeamento entre features e componentes usando ISLAYNE-IDE. . . 144
6.10 Componente CreditCard gerado seguindo o modelo DyCosmos. . . 145
6.11 Configuração de produto da versão JavaFX v1 da e-Shop. . . 145
6.12 Documento XML de variabilidade da e-Shop JavaFX v1. . . 146
6.13 Trecho do documento XML arquitetural da e-Shop JavaFX v1. . . 147
6.14 Relação entre componentes e serviços da DSPL e-Shop. . . 148
6.15 Interface ISensor provida pelo Reconfigurador da ISALYNE-Instance. . . . 149
6.16 Trecho do sensor conectado ao componente VisaA da e-Shop. . . 149
6.17 Telas do sistema e-Shop JavaFX v1. . . 151
6.18 Telas do sistema e-Shop Android. . . 151
6.19 Intervalos de tempo para executar as atividades de análise da e-Shop Ja-vaFX v1. . . 153
6.20 Intervalos de tempo para executar as atividades de planejamento e recom-posição na e-Shop JavaFX v1. . . 153
6.21 Intervalos de tempo para executar as atividades de análise da e-Shop Android.154 6.22 Intervalos de tempo para executar as atividades de planejamento e execução na e-Shop Android. . . 154
6.23 Comparação de tamanho entre as versões da DSPL e-Shop. . . 155
B.1 Thread do sensor conectado ao componente VisaA da e-Shop. . . 188
B.2 Trecho do sensor conectado ao componente VisaA da e-Shop. . . 189
B.3 Efetor do componente VisaA da e-Shop. . . 190
2.1 Conferências, Simpósios e Workshops considerados no SMS realizado. . . . 50
2.2 Estudos primários encontrados. . . 52
2.3 Estudos primários em relação a dependability. . . 56
2.4 Estudos primários em relação ao MAPE-K. . . 57
2.5 Estudos primários versus facetas de DSPL. . . 58
4.1 Plataformas tecnológicas para desenvolvimento de DSPLS. . . 82
4.2 Soluções de DSPL selecionadas. . . 83
4.3 Dimensão de autoadaptação das soluções de DSPL. . . 84
4.4 Dimensão de variabilidade das soluções de DSPL. . . 85
4.5 Sumário da dimensão de autoadaptação. . . 93
4.6 Sumário da dimensão de variabilidade de DSPL. . . 96
4.7 Sumário de dimensões. . . 99
4.8 Dimensão de autoadaptação versus atributos de qualidade. . . 103
4.9 Dimensão de variabilidade versus atributos de qualidade. . . 107
6.1 Componentes e interfaces do subsistema gestor da Cosmapek, classificados de acordo com os módulos do ISALYNE-RM. . . 133
6.2 Requisitos de adaptação do Reconfigurador. . . 134
6.3 Notação proposta para a modelagem de features estáticas e dinâmicas. . . 137
6.4 Requisitos de Variabilidade da DSPL e-Shop. . . 142
6.5 Definição dos objetivos da avaliação. . . 150
6.6 Sumarização dos dados coletados. . . 156
ADL Architetural Description Language AOM Aspect-Oriented Modeling
ASPL Autonomic Software Product Lines CVL Common Variability Language DAG Directed Acyclic Graph
DAS Dynamically Adaptive System DSL Domain Specific Language DSPL Dynamic Software Product Line FArM Feature-Architecture Mapping FBU Feature Binding Unit
FODA Feature-Oriented Domain Analysis FOP Feature-Oriented Programming
FORMS FOrmal Reference Model for Self-adaptation FOSD Feature-Oriented Software Development JSON JavaScript Object Notation
K Knowledge base
MAPE-K Monitor-Analyze-Plan-Execute – Knowledge base MDD Model-Driven Development
MDE Model-Driven Engineering MOP meta-object protocol
MoRE Model-Based Reconfiguration Engine OVM Orthogonal Variability Model
PLA Product Line Architecture
SAS Self-Adaptive Software System SCA Service Component Architecture
SLOC Source Lines of Code. Número de linhas de código-fonte não comenta-das.
SLR Systematic Literature Review SMS Systematic Mapping Study SOA Service-Oriented Architecture SOAP Simple Object Access Protocol SOC Service-Oriented Computing SPL Software Product Line
SPLE Software Product Line Engineering WSDL Web Services Description Language XML eXtensible Markup Language
1 Introdução 18
1.1 Definição do Problema e Questões de Pesquisa . . . 19
1.1.1 Uso de Ciclos de Controle Autônomos . . . 19
1.1.2 Ausência de Modelos de Referência para a Construção de DSPLs . 20 1.1.3 Escassez de Notações para Modelar Features Estáticas e Dinâmicas em Conjunto . . . 21
1.2 Solução Proposta . . . 22
1.2.1 Aplicação de Ciclos de Controle em DSPLs . . . 22
1.2.2 Uma Taxonomia e um Modelo de Referência para DSPLs . . . 23
1.2.3 Uma Solução Uniforme para Modelagem de Variabilidades Estática e Dinâmica . . . 26
1.3 Trabalhos Relacionados . . . 26
1.3.1 Sistemas Autoadaptativos e Computação Autônoma . . . 27
1.3.2 Linhas de Produtos de Software Dinâmicas . . . 28
1.4 Estrutura da Tese . . . 29
2 Fundamentação Teórica e Estado da Arte 30 2.1 Padrões Arquiteturais, Modelos de Referência e Arquiteturas de Referência 30 2.2 Sistemas de Software Autoadaptativos . . . 31
2.2.1 Autoadaptação . . . 31
2.2.2 Subsistema Gestor e Subsistema Gerenciado . . . 32
2.2.3 Ciclos de Controle Autônomos . . . 33
2.2.4 Binding Time . . . 34
2.2.5 Padrões Arquiteturais para Sistemas Autoadaptativos . . . 36
2.2.6 Modelo de Referência FORMS . . . 37
2.3 Linha de Produtos de Software Dinâmica . . . 38
2.3.1 Conceitos de Linhas de Produtos de Software . . . 38
2.3.2 Conceitos de Linhas de Produtos de Software Dinâmicas . . . 40
2.3.3 Modelagem de Variabilidade . . . 41
2.3.4 Arquitetura de Linha de Produtos . . . 43
2.3.5 Mapeamento de Features para Elementos Arquiteturais . . . 43
2.4 Sinergias entre SAS e DSPL . . . 44
2.5 Desenvolvimento Dirigido por Modelos . . . 45
2.6 Arquitetura Orientada a Serviços . . . 45
2.7 Pesquisa Preliminar por Dependability e Tolerância a Falhas em DSPLs . . 46
2.7.1 Fundamentos de Dependability e Tolerância a Falhas . . . 47
2.7.2 Método de Pesquisa . . . 47
2.7.6 Discussão . . . 60
2.8 Resumo . . . 60
3 Infraestrutura Autoadaptativa Cosmapek 61 3.1 Visão Geral . . . 61 3.2 Cosmapek . . . 62 3.2.1 Infraestrutura . . . 62 3.2.2 Projeto Arquitetural . . . 64 3.3 Estudo de Viabilidade . . . 65 3.3.1 O Componente Cliente . . . 66 3.3.2 O Componente Servidor . . . 68 3.3.3 Medições . . . 69 3.4 Trabalhos Relacionados . . . 70 3.5 Resumo . . . 72
4 Taxonomia para Soluções de DSPLs 73 4.1 Contextualização . . . 73
4.2 Uma Taxonomia para Soluções de DSPL . . . 74
4.2.1 Dimensão de Autoadaptação . . . 75
4.2.2 Dimensão de Variabilidade em DSPL . . . 78
4.3 Seleção de Soluções de DSPLs . . . 81
4.4 Avaliação e Discussão . . . 92
4.4.1 Avaliação da Dimensão de Autoadaptação (D1) . . . 92
4.4.2 Avaliação da Dimensão da Variabilidade (D2) . . . 95
4.4.3 Resumo . . . 98
4.5 Critérios Gerais de Projeto . . . 99
4.5.1 Atributos de Qualidade . . . 99
4.5.2 Uma Solução Ideal de DSPL . . . 102
4.6 Resumo . . . 109
5 Modelo de Referência ISALYNE-RM 110 5.1 Visão Geral . . . 110
5.2 Infraestrutura do Modelo de Referência . . . 111
5.2.1 Módulos . . . 112
5.2.2 Modelo conceitual. . . 113
5.3 Módulo de Desenvolvimento de Adaptação . . . 114
5.3.1 Requisitos de Adaptação . . . 115
5.3.2 Metamodelo de Adaptação . . . 117
5.3.3 Módulo de Decisão . . . 118
5.3.4 Módulo de Recomposição . . . 119
5.3.5 Módulo de Conhecimento . . . 120
5.4 Módulo de Desenvolvimento de Variabilidade . . . 120
5.4.1 Requisitos de Variabilidade de DSPL . . . 120
5.4.2 Metamodelo de Variabilidade . . . 122
5.4.3 Processo de Desenvolvimento de Variabilidade . . . 123
5.5 Módulo de Desenvolvimento de Interface Reflexiva . . . 126
6 ISALYNE-Instance 131
6.1 Visão Geral . . . 131
6.2 Reconfigurador . . . 132
6.2.1 Refinamento da Arquitetura . . . 132
6.2.2 Implementação do Reconfigurador . . . 133
6.3 Uma Notação para Modelagem de Features Estáticas e Dinâmicas . . . 135
6.3.1 Composição Estática e Dinâmica . . . 136
6.3.2 Feature Abstrata . . . 137
6.3.3 Restrição entre Árvores . . . 138
6.4 ISALYNE-IDE: Uma Ferramenta de Apoio para a Construção de DSPLs . 139 6.5 Processo de Construção do Sistema e-Shop . . . 141
6.5.1 Requisitos de Variabilidade da DSPL e-Shop . . . 141
6.5.2 Construção da DSPL e-Shop . . . 142
6.5.3 Construção da Interface Reflexiva . . . 148
6.6 Avaliação . . . 149
6.6.1 Planejamento do Estudo . . . 149
6.6.2 Sistemas Utilizados . . . 151
6.6.3 Execução do Estudo . . . 152
6.6.4 Análise e Interpretação dos Dados . . . 155
6.6.5 Limitações do Estudo . . . 156
6.7 Resumo . . . 157
7 Conclusões e Trabalhos Futuros 158 7.1 Conclusões . . . 158
7.2 Resumo das Contribuições . . . 160
7.2.1 Contribuições de Revisão da Literatura . . . 160
7.2.2 Contribuições Metodológicas . . . 160 7.2.3 Contribuições Tecnológicas . . . 161 7.3 Publicações . . . 162 7.4 Trabalhos Futuros . . . 163 Referências Bibliográficas 165 A Tabela completa 185 B Sensores e Efetores 188
Introdução
No mundo moderno, a necessidade de desenvolver sistemas de software que se adaptem a ambientes e dispositivos heterogêneos tem aumentado progressivamente. Os sistemas capazes de adaptar o seu comportamento ou a sua estrutura em tempo de execução, são denominados Sistemas de Software Autoadaptativos (SASs1) [51], que podem ser
altera-dos para se adequarem ao ambiente (hardware, sistema operacional e outros sistemas) ou para corrigir falhas que possam ocorrem durante sua execução, sem que haja interferência humana. Embora a autoadaptação em sistemas possa ocorrer de diversas maneiras, os ciclos de controle autônomos fornecem um mecanismo genérico para sistemas autoadap-tativos [186]. O ciclo de controle autônomo geralmente é modelado na forma do ciclo MAPE [186], sendo dividido em quatro atividades: Monitorar, Analisar, Planejar e Exe-cutar. Além disso, existe uma base de conhecimento compartilhada, que apoia o fluxo de informações exigido em todas as atividades do ciclo [186]. Na literatura, diversas soluções foram propostas para desenvolver sistemas autoadaptativos e serviram de base para o es-tabelecimento de modelos de referência e arquiteturas de referência, que podem orientar engenheiros de software na reutilização de conhecimento em um domínio ou conjunto de sistemas. Entre os modelos de referência estabelecidos para sistemas autoadaptativos, dois exemplos são o modelo de referência FORMS2 [185] e o modelo Three Layer Model
Architecture for Self-Management [112].
Nesse contexto, Linhas de Produtos de Software Dinâmicas (DSPL3) podem se
be-neficiar de técnicas de desenvolvimento de sistemas autoadaptativos, para permitir a adaptação em tempo de execução. As Linhas de Produtos de Software (SPL4)
abor-dam a identificação de comunalidades e variabilidades entre sistemas de software [109]. As comunalidades denotam features que fazem parte de cada produto na mesma forma, enquanto que a variabilidade é definida como a capacidade de um sistema de software ou de um artefato ser estendido, modificado, personalizado ou configurado para um contexto específico [109]. A variabilidade é estabelecida por um ponto de variação, que define um conjunto de variantes de software que o satisfazem. Em SPLs, o momento em que a re-solução de variabilidade é realizada tem o nome de binding time [115], que pode ocorrer
1Sigla do inglês Self-Adaptive Software System.
2Sigla do inglês FOrmal Reference Model for Self-adaptation. 3Sigla do inglês Dynamic Software Product Line.
4Sigla do inglês Software Product Line.
durante a fase de projeto para gerar um produto usando binding estático. No caso de DSPLs, o binding time deve ocorrer durante a execução para permitir a adaptação do produto através da variabilidade dinâmica. A variabilidade dinâmica pode ser represen-tada usando composições dinâmicas, que são conjuntos de features com binding dinâmico [162], enquanto que a variabilidade estática pode ser representada usando composições estáticas, que são conjuntos de features com binding estático [180].
1.1
Definição do Problema e Questões de Pesquisa
O problema que esta tese se propõe a resolver é dividido em três subproblemas, que são devidamente motivados e descritos nas próximas seções. Além disso, a cada um desses subproblemas são atribuídas uma ou mais questões de pesquisa (QP).
1.1.1
Uso de Ciclos de Controle Autônomos
Como resultado do seminário “Software Engineering for Self-Adaptive Systems”5 ocorrido
em 2008 em Schloss Dagstuhl, Cheng et al. publicaram em 2009, um estudo [51] no qual foi apresentado o cenário da área de pesquisa de Engenharia de Software para Sistemas Autoadaptativos, elencando-se os principais desafios dessa área de pesquisa. Nesse estudo, os autores divulgaram como um dos grandes desafios, a necessidade de se explicitar os ciclos de controle autônomos6, salientando ser essencial para o avanço da maturidade da engenharia de software aplicada a sistemas autoadaptativos. Os ciclos de controle autônomos deveriam tornar-se entidades de primeira classe em todo o ciclo de vida de sistemas autoadaptativos, onde a sua modelagem explícita facilitaria a realização das propriedades do sistema, permitindo a sua consulta e modificação em tempo de execução [51, 40].
Posteriormente, como resultado do segundo seminário7 ocorrido em 2010, Lemos et
al. [66] reafirmaram o estudo anterior [51] e o estenderam propondo temas e desafios adicionais, como a identificação de padrões para capturar a interação dos ciclos de controle autônomos nos sistemas autoadaptativos. Na terceira edição do seminário8, realizado em
dezembro de 2013, foi discutido sobre a importância dos ciclos de controle autônomos para se alcançar a software assurance [169]. Os autores [119] consideram os ciclos de controle autônomos como os pilares dos sistemas autoadaptativos e discutiram as relações existentes entre os ciclos de controle autônomos e os tipos de assurance, que sistemas autoadaptativos podem fornecer com foco nos níveis conceitual e de implementação.
No contexto de DSPLs, Metzger e Pohl [127] afirmaram que o uso dos conceitos de computação autônoma é um desafio no desenvolvimento de DSPL, enfatizando a aplicação dos ciclos de controle autônomos para a construção de DSPLs bem estruturadas. Além disso, Capilla et al. [44] discutiram a necessidade de explorar mecanismos de adaptação
5Disponível em http://www.dagstuhl.de/08031 e acessado em 05/Mai/2017. 6Do inglês autonomic control loops.
7Disponível em http://www.dagstuhl.de/10431 e acessado em 05/Mai/2017. 8Disponível em http://www.dagstuhl.de/13511 e acessado em 05/Mai/2017.
composicional [126] para implementar a variabilidade em tempo de execução nas DSPLs, em particular, a adoção do ciclo autônomo MAPE-K.
Entretanto, segundo Bencomo et al. [36], muitas soluções de DSPLs não são dinâmicas como deveriam ser, pois parcialmente (ou não) implementam as atividades autônomas e de adaptação de forma completa. A adoção de ciclos de controle autônomos contribui para a melhoria da maturidade da área de pesquisa de DSPLs, motivando a formulação das seguintes questões de pesquisa:
QP.1 Como as soluções para DSPL realizam a adaptação em tempo de exe-cução? As atividades de ciclos de controle autônomos são consideradas? QP.2 Como aplicar os ciclos de controle autônomos para gerenciar a
variabi-lidade de DSPLs?
1.1.2
Ausência de Modelos de Referência para a Construção de
DSPLs
Salehie e Tahvildari [167] argumentam que um desafio fundamental é como projetar soft-ware autoadaptativo para cumprir os requisitos de adaptação. Eles decompõem esse desafio na concepção do subsistema gestor e do subsistema gerenciado, bem como na criação de uma arquitetura responsável pela conexão desses subsistemas. Essa questão continua a ser bastante relevante no contexto de sistemas autoadaptativos e ganha uma maior amplitude no contexto de DSPLs, uma vez que não há um padrão a ser seguido e nem consenso sobre como construir uma DSPL. Salehie e Tahvildari [167] levantaram os seguintes questionamentos sobre o desenvolvimento de sistemas autoadaptativos que, no contexto deste trabalho, são aplicados ao projeto de DSPLs:
QP.3 Quais estilos arquiteturais são apropriados para o desenvolvimento de DSPLs?
QP.4 Quais interfaces e contratos precisam ser considerados para permitir o monitoramento e a realização da adaptação em sistemas de DSPL?
Embora haja numerosos esforços de pesquisa que investigam soluções para desenvolver DSPLs, ainda há uma ausência de modelos de referência e de arquiteturas de referência que poderiam ajudar a realizar os processos de adaptação, de gerenciamento da variabilidade e de instrumentação de sensores e efetores de forma sistemática. Além disso, Salehie e Tahvildari [167] argumentam que ações de adaptação dinâmica ainda não são amplamente apoiadas ou não são confiáveis [167].
A existência de modelos de referência é importante para auxiliar os engenheiros de software na árdua tarefa de projetar DSPLs. Na comunidade de sistemas autoadaptativos, existe uma tendência em definir e formalizar modelos de referência e arquiteturas de referência [185, 112], mas essas boas práticas ainda são pouco exploradas no contexto de DSPLs. Embora as primeiras publicações relacionadas a DSPLs tenham surgido em meados de 2006, ainda existe uma predominância de propostas de novas soluções [73, 36], ao invés de consolidar as já apresentadas. De acordo com as pesquisas realizadas
na literatura, não foi encontrado um modelo de referência estabelecido para apoiar o desenvolvimento de DSPLs. O uso de modelos de referência de sistemas autoadaptativos pode ser um ponto de partida adequado para o desenvolvimento de DSPLs, pois assegura a obtenção de propriedades desejáveis para sistemas dinâmicos e autoadaptativos. No entanto, em geral, os modelos de referência para sistemas autoadaptativos não podem ser diretamente aplicados ao desenvolvimento de DSPLs, pois não apoiam a variabilidade dinâmica para implementar composições dinâmicas.
Portanto, ainda há uma lacuna em modelos de referência e arquiteturas de referência de sistemas autoadaptativos, que podem servir de base ou orientar o projeto e a construção de DSPLs e sua efetiva aplicação prática para a geração de DSPLs. Da mesma forma, estruturas de implementação e ferramentas automatizadas são necessárias para dar apoio e realizar a instrumentação no processo de construção de DSPLs. Outro desafio é tornar as soluções para DSPL e tais ferramentas amplamente utilizáveis na indústria. Assim, com base nesses desafios, são formuladas as seguintes questões de pesquisa:
QP.5 Quais são as tecnologias, como modelos de componentes, modelo de serviços, frameworks, linguagens e ferramentas, utilizadas para o projeto e o desenvolvimento de DSPLs? Como facilitar a seleção das tecnologias que se enquadram em um determinado propósito?
QP.6 Como aplicar conhecimentos provenientes dos modelos de referências de sistemas autoadaptativos para o projeto e a construção de DSPLs?
1.1.3
Escassez de Notações para Modelar Features Estáticas e
Dinâmicas em Conjunto
Bosch et al. [39] listam a variabilidade dinâmica e o gerenciamento da variabilidade em tempo de execução como tendências da área de variabilidade de software. De acordo com Bosch et al. [39], o projeto de pontos de variação, de modo que o mecanismo de variabilidade (que determina o binding time) possa ser facilmente substituído durante a implementação do sistema, é particularmente importante.
Além disso, o mapeamento sistemático da literatura realizado neste trabalho, descrito na Seção 2.7, concluiu que o modelo de features é a técnica de modelagem mais utilizada para a especificação da variabilidade dinâmica em DSPLs. Apesar das numerosas notações para representar a modelagem da variabilidade usando o modelo de features, a maioria das notações representa apenas a variabilidade estática no modelo de features e, em geral, cada solução de DSPL propõe uma nova técnica para lidar com a variabilidade dinâmica com base em modelos de features. Nesse contexto, é definida a seguinte questão de pesquisa:
QP.7 Como representar as variabilidades estática e dinâmica conjuntamente de forma adequada na construção de DSPLs?
Em termos de notação para a modelagem de features, a modelagem da variabilidade dinâmica tem sido negligenciada, havendo poucas tentativas de representá-la, como, por exemplo, Lee e Muthig [117] e Ferber et al. [77]. O estudo comparativo realizado, deta-lhado no Capítulo 4, mostrou que, entre as soluções de DSPL analisadas, a maioria utiliza
notações tradicionais do modelo de features para representar apenas a variabilidade di-nâmica, desconsiderando a variabilidade estática. Entre as dezesseis soluções analisadas nesse estudo comparativo, apenas quatro soluções abordam as variabilidades estática e dinâmica em conjunto [46, 56, 116, 161]. Entretanto, essas soluções utilizam notações ad hoc para a modelagem de features ou representam a variabilidade espalhada em diferentes modelos que se complementam.
1.2
Solução Proposta
Esta tese descreve uma solução que visa avançar o estado da arte no que tange a concep-ção e implementaconcep-ção de linhas de produtos de software dinâmicas, mediante a aplicaconcep-ção de técnicas de sistemas autônomos e autoadaptativos. Para alcançar esse objetivo, as questões de pesquisa, apresentadas na seção anterior, foram respondidas a partir da com-binação de técnicas de quatro disciplinas: linhas de produtos de software (dinâmicas), sistemas autoadaptativos, desenvolvimento centrado na arquitetura de software e desen-volvimento baseado em componentes, conforme descrito nas seções subsequentes. Como não foi encontrado um modelo de referência específico para o desenvolvimento de DSPLs, a proposição de um modelo como esse é uma das contribuições originais desta pesquisa. As respostas para cada uma das questões de pesquisa da seção anterior, bem como a discussão das suas contribuições, são apresentadas a seguir.
1.2.1
Aplicação de Ciclos de Controle em DSPLs
QP.1 Como as soluções para DSPL realizam a adaptação em tempo de exe-cução? As atividades de ciclos de controle autônomos são consideradas? QP.2 Como aplicar os ciclos de controle autônomos para gerenciar a
variabi-lidade de DSPLs?
Como parte das atividades previstas nesta pesquisa, para encontrar uma solução ao problema relacionado à questão de pesquisa QP.1, foi realizado um mapeamento sistemá-tico da literatura, seguido de um estudo comparativo das soluções para DSPL encontradas (Seção 2.7), buscando identificar o ciclo autônomo de controle e o padrão de adaptação utilizados. Após a análise dos nove estudos primários selecionados, foi possível concluir que os desafios apontados pelos estudos [51, 66, 119] continuam sendo válidos, pois a mai-oria das soluções para DSPL encontradas não implementa o ciclo de controle autônomo. Entre as DSPLs analisadas, apenas duas [2, 133] implementaram o ciclo MAPE-K.
Com base nessas soluções, foram identificadas as comunalidades e variabilidades exis-tentes, especificando uma família de soluções para o desenvolvimento de linhas de produtos de software dinâmicos tolerantes a falhas. Foi realizada a modelagem das variabilidades de forma diferenciada para representar as atividades do ciclo autônomo de controle para permitir que, no momento de instanciar um produto da linha, o engenheiro de software possa escolher as variabilidades para cada fase do ciclo autônomo de controle da linha de produtos, ou seja, para as atividades de monitoramento, análise, planejamento e execução separadamente.
O mapeamento sistemático da literatura e o estudo comparativo da família de soluções fazem parte das contribuições desta tese, como revisão da literatura, e resultaram nas seguintes publicações:
• Eleutério, J.D.A.S.; Rubira, C.M.F. An Infrastructure to Support Autonomic Con-trol Loops in Dynamic Software Product Lines. Em: Int’l Conf. Software Eng. Research and Practice | SERP’15. Las Vegas, EUA; 2015:23-26.
• Eleutério, J.D.A.S.; Gaia, F.N.; Bondavalli, A.; Lollini, P.; Rodrigues, G.N.; Rubira, C.M.F. On the Dependability for Dynamic Software Product Lines: A Comparative Systematic Mapping Study. Em: 42th Euromicro Conference on Software Engine-ering and Advanced Applications (SEAA). Limassol, Chipre: IEEE; 2016:323-330. doi:10.1109/SEAA.2016.40. (com estudo comparativo)
Entre as soluções para DSPLs selecionadas no mapeamento sistemático realizado está incluída a infraestrutura ArCMAPE [133], que foi desenvolvida no contexto do grupo de pesquisa desta tese. Utilizando o conhecimento prático obtido com o grupo de pesquisa, foi projetada e implementada uma infraestrutura de implantação autoadaptativa denomi-nada Cosmapek, objetivando responder à questão de pesquisa QP.2 e obter experiência no desenvolvimento de DSPLs. Essa infraestrutura é derivada da família de soluções de DSPL estabelecida e realiza as atividades do ciclo de controle autônomo MAPE-K para a implantação de configurações arquiteturais em tempo de execução em linhas de produtos dinâmicas. O Cosmapek tem como ativos centrais um modelo de features composto de features estáticas e dinâmicas e um modelo de arquitetura de linha de produtos (mo-delo PLA) para prover variabilidade, através da reconfiguração arquitetural em tempo de execução. A infraestrutura Cosmapek foi projetada para permitir a reconfiguração arquitetural em tempo de execução em DSPLs implementadas em Java.
Assim, com o objetivo de validar a implementação da infraestrutura Cosmapek e si-multaneamente verificar a viabilidade de construção de uma DSPL que seja executada na plataforma Android, foi implementada uma aplicação autoadaptativa em Android, denominada Buscame. A plataforma Android foi escolhida devido à escassez de infraes-truturas e soluções autoadaptativas para essa plataforma, bem como ao fato da linguagem de programação Java ser a base para o desenvolvimento de aplicações Android.
A infraestrutura Cosmapek e sua avaliação são contribuições tecnológicas desta tese e resultaram na publicação descrita a seguir:
• Casquina, J.C.; Eleutério, J.D.A.S.; Rubira, C.M.F. Adaptive Deployment In-frastructure for Android Applications. Em: 2016 12th European Dependa-ble Computing Conference (EDCC). Gothenburg, Suécia: IEEE; 2016:218-228. doi:10.1109/EDCC.2016.25.
1.2.2
Uma Taxonomia e um Modelo de Referência para DSPLs
QP.3 Quais estilos arquiteturais são apropriados para o desenvolvimento de DSPLs?
QP.4 Quais interfaces e contratos precisam ser considerados para permitir o monitoramento e a realização da adaptação em sistemas de DSPL? QP.5 Quais são as tecnologias, como modelos de componentes, modelo de
serviços, frameworks, linguagens e ferramentas, utilizadas para o projeto e o desenvolvimento de DSPLs? Como facilitar a seleção das tecnologias que se enquadram em um determinado propósito?
QP.6 Como aplicar conhecimentos provenientes dos modelos de referências de sistemas autoadaptativos para o projeto e a construção de DSPLs?
Para responder às questões de pesquisa QP.3, QP.4 e QP.5, foi elaborado um estudo comparativo com a definição de uma taxonomia, cujo objetivo é investigar a aplicabilidade das soluções de DSPL existentes para desenvolver sistemas autoadaptativos com atributos de qualidade efetivos. As principais contribuições do estudo são: (i) a definição de uma taxonomia usada para discutir problemas de projeto técnico de uma solução de DSPL e para distinguir uma solução de outra, sendo que especialmente o apoio para variabilidade dinâmica e os requisitos de adaptabilidade são examinados em detalhes; (ii) a apresentação de um levantamento abrangente das propostas existentes de DSPLs; (iii) a comparação e avaliação das propostas investigadas, bem como a identificação das limitações na sua aplicação prática para o desenvolvimento de DSPLs; e (iv) a definição de um conjunto de soluções de projeto adequadas e de um modelo ideal para sistemas de DSPL.
Em relação à questão de pesquisa QP.3, a taxonomia proposta levantou os estilos ar-quiteturais e os padrões de projeto atualmente aplicados às soluções de DSPLs, discutindo as vantagens e desvantagens de usar cada opção. Nos estilos arquiteturais, concluiu-se que as DSPL usam arquiteturas híbridas, baseadas em componentes e orientadas a serviços. Nos padrões arquiteturais, as DSPLs são principalmente baseadas no padrão arquitetural Reflection.
Em relação à questão de pesquisa QP.4, a taxonomia proposta divide a DSPL em dois subsistemas, o subsistema gestor e o subsistema gerenciado. A dimensão de autoadaptação da taxonomia proposta visa auxiliar o projeto e a construção do subsistema gestor, ao definir questões de projeto claras sobre a adaptação durante a execução. Em relação ao subsistema gestor, é necessário construir mecanismos de monitoramento e adaptação, que sejam reutilizáveis por outras DSPLs, ou seja, que sejam independentes de domínio. Além disso, esses mecanismos precisam ser minimamente fáceis de entender e especialmente fáceis de se utilizar, para que os engenheiros de software possam aplicá-los em outras DSPLs.
No subsistema gerenciado, a DSPL necessita ser construída para ser “entendida” pelo subsistema gestor. Em outras palavras, a DSPL precisa exteriorizar interfaces e contratos sobre seu estado e funcionamento através de sensores, expondo seus pontos de variação, a fim de permitir o gerenciamento da variabilidade pelos efetores. A dimensão de va-riabilidade da taxonomia proposta visa auxiliar o projeto e a construção do subsistema gerenciado, ao definir questões de projeto que orientam a especificação da variabilidade para permitir à DSPL ser gerenciada pelo subsistema gestor.
Em relação à questão de pesquisa QP.5, foram apresentadas dezesseis soluções de DSPL, das quais nove são provenientes do mapeamento sistemático da literatura,
des-crito na Seção 2.7. Com as dezesseis soluções selecionadas, foi levantado o conjunto de tecnologias usadas, que são divididas em modelos de componentes, modelos de serviços, frameworks, APIs e ferramentas.
A definição da taxonomia é uma contribuição metodológica desta tese e o seu estudo comparativo faz parte das contribuições de revisão da literatura. A definição da taxonomia e o estudo comparativo resultou no seguinte trabalho:
• Eleutério, J.D.A.S.; Rubira, C.M.F. A Comparative Study of Dynamic Variability Realization in Dynamic Software Product Line Solutions: A Self-Adaptation Pers-pective. Em: International Journal on Software and Systems Modeling (SoSyM). 2017. [submetido].
Para responder à questão de pesquisa QP.6, foi proposto um modelo de referência, chamado ISALYNE-RM, para auxiliar o desenvolvimento de DSPL com um mecanismo de variabilidade dinâmico efetivo. O ISALYNE-RM utiliza a taxonomia proposta e divide o sistema em dois subsistemas, sendo a DSPL (subsistema gerenciado), que contém a lógica da aplicação e a variabilidade, e o Reconfigurador (subsistema gestor), que contém a lógica de adaptação e executa a reconfiguração da DSPL baseando-se nos modelos de variabilidade definidos. Além disso, o ISALYNE-RM define uma interface reflexiva para conectar ambos os subsistemas. A especificação do ISALYNE-RM também abrange um conjunto de módulos de processo e diretrizes, que definem os processos de desenvolvimento para orientar a construção do Reconfigurador, da DSPL e da interface reflexiva.
O ISALYNE-RM foi elaborado considerando: (i) modelos de referência de sistemas autoadaptativos e de sistemas autônomos; (ii) a família de soluções para DSPLs elabo-rada a partir dos resultados do mapeamento sistemático; (iii) a experiência obtida com o desenvolvimento da infraestrutura Cosmapek; e (iv) a taxonomia para DSPLs proposta. O modelo de referência ISALYNE-RM é uma das principais contribuições desta tese e tem como vantagens: (i) sistematizar o projeto de DSPLs, considerando os modelos de referência existentes para sistemas autoadaptativos; (ii) classificar os requisitos funcionais e não-funcionais envolvidos no desenvolvimento de DSPL, para orientar as decisões ar-quiteturais realizadas pelos engenheiros de software; e (iii) assegurar que o requisito de dinamicidade para DSPLs seja adequadamente cumprido.
Uma instância do modelo de referência proposto foi gerada para demostrar a sua viabilidade e efetividade, sendo implementada como uma evolução da infraestrutura Cos-mapek, apoiada por ferramental. Essa instância foi utilizada para desenvolver uma DSPL para o gerenciamento de vendas em lojas físicas, denominada de e-Shop. A DSPL e-Shop foi desenvolvida em duas versões, uma usando a tecnologia JavaFX e a outra usando Android, com o objetivo de avaliar a aplicabilidade da solução em ambientes distintos e as diferenças de desempenho entre as implementações. Os resultados preliminares mos-traram que: (i) o ISALYNE-RM pode ser considerado uma técnica eficaz para orientar a construção de DSPLs; (ii) o modelo de referência proposto facilita o desenvolvimento de DSPLs, pois orienta o engenheiro de software, apresentando os requisitos funcionais e não-funcionais e os procedimentos necessários para desenvolver uma DSPL, além de fornecer apoio ferramental; e (iii) a solução implementada baseada na instância do ISALYNE-RM não introduz uma sobrecarga de tempo excessiva para dar apoio à variabilidade dinâmica.
A definição do modelo de referência ISALYNE-RM é uma contribuição metodológica desta tese e resultou nas seguintes publicações:
• Venero, S.K.; Eleutério, J.D.A.S.; Rubira, C.M.F. Research contributions on adap-tive software architectures. Em: Proceedings of the 10th European Conference on Software Architecture Workshops - ECSAW’16. Copenhagen, Dinamarca: ACM Press; 2016:1-6. doi:10.1145/2993412.3004851.
• Eleutério, J.D.A.S.; Affonso, F.J.; Nakagawa, E.Y; Rubira, C.M.F. Towards a refe-rence model for Dynamic Software Product Line. Em: 11th European Conference on Software Architecture (ECSA 2017). 2017. [submetido].
1.2.3
Uma Solução Uniforme para Modelagem de Variabilidades
Estática e Dinâmica
QP.7 Como representar as variabilidades estática e dinâmica conjuntamente de forma adequada na construção de DSPLs?
Para responder à questão de pesquisa QP.7, foi proposta a extensão do modelo de features com a criação de uma notação, que permite representar as variabilidades estática e dinâmica conjuntamente. A notação proposta é uma extensão das notações FODA9
[107], que também incorpora conceitos de outras notações [116, 58, 177], permitindo a representação de composições dinâmicas, de features abstratas e de restrições entre árvores10. Esses três conceitos são combinados no modelo de features para representar a informação necessária, a fim de permitir a variabilidade dinâmica. Além disso, representar todas as informações necessárias para as variabilidades estática e dinâmica em um único modelo facilita a manutenção e a compreensão da DSPL.
Uma contribuição tecnológica desta tese é a criação da notação para modelagem de features, permitindo representar as variabilidades estática e dinâmica. Essa notação não foi publicada até o momento, entretanto fará parte do artigo a ser submetido à uma revista:
• Eleutério, J.D.A.S.; Affonso, F.J.; Nakagawa, E.Y; Rubira, C.M.F. Towards a refe-rence model for Dynamic Software Product Line. Em: Journal of Software: Practice and Experience. 2017. [em andamento].
1.3
Trabalhos Relacionados
Para facilitar o entendimento desta seção, foi realizada a divisão dos trabalhos relacionados que apresentam técnicas para sistemas autoadaptativos e computação autônoma, dos que apresentam técnicas para linhas de produtos de software dinâmicas.
9Sigla do inglês Feature-Oriented Domain Analysis. 10Do inglês cross-tree constraint.
1.3.1
Sistemas Autoadaptativos e Computação Autônoma
Atualmente, não foi encontrado na literatura um modelo de referência baseado em au-toadaptação que apoie o desenvolvimento de DSPLs. No entanto, alguns trabalhos re-lacionados foram encontrados, mas são modelos focados no desenvolvimento de sistemas autoadaptativos, como o FORMS [185] e o proposto por Kramer e Magee [112].
Kramer e Magee [112] apresentaram um modelo de referência para sistemas auto-gerenciáveis, que são capazes de realizar a autoconfiguração, autoadaptação, autocura, automonitoramento, entre outros. Esse modelo, chamado Three Layer Model Architec-ture for Self-Management, é baseado no padrão arquitetural de camadas11 [42], que ajuda a estruturar sistemas que podem ser decompostos em grupos de subtarefas, em que cada grupo de subtarefas esteja em um nível particular de abstração. O modelo de Kramer e Magee consiste em três camadas arquiteturais: camadas de gerenciamento de metas12,
camada de gerenciamento de mudanças13 e camada de controle de componentes14, que
formam uma arquitetura autogerenciada. Nessa arquitetura, seus componentes são auto-configurados, sendo compatíveis com uma especificação geral da arquitetura para atingir os objetivos do sistema. No entanto, as modificações da camada mais baixa (controle de componentes) são gerenciadas por um plano de ação, que identifica a viabilidade de adaptação e determina quais modificações podem ser implementadas. O modelo de refe-rência de Kramer e Magee não foi utilizado diretamente na elaboração do ISALYNE-RM, entretanto, algumas de suas características foram incorporadas ao ISALYNE-RM devido ao fato da solução de Gomaa et al. [90] utilizá-lo como base.
Weyns et al. [185] propuseram um modelo de referência para autoadaptação chamado FORMS. Esse modelo é composto por um conjunto de primitivas de modelagem formal-mente especificadas, que corresponde aos “pontos chave” de variação dentro de sistemas de software autoadaptativos. O modelo de referência FORMS é apresentado em detalhes na Seção 2.2.6, pois foi utilizado como base para o estabelecimento do ISALYNE-RM.
Além disso, Müller et al. [131] argumentaram sobre a necessidade de elementos de computação autônoma [102] para a concepção de sistemas de software autoadaptativos em tempo de execução. Segundo os autores, os sistemas de software podem ser chamados de autônomos se operarem principalmente sem intervenção externa (outro sistema ou humana), conforme regras ou políticas estabelecidas.
Cetina e Pelechano [49, 8] discutem como os modelos de variabilidade podem ser usa-dos para fornecer uma base semântica mais rica para a tomada de decisão, em tempo de execução, relacionada à computação autônoma. Segundo Cetina e Pelechano [49], para alcançar a computação autônoma, os modelos de variabilidade podem oferecer apoio aos engenheiros de sistemas autônomos, desde a concepção do sistema até sua execução. Eles propõem um processo com seis etapas, sendo três na fase de projeto e três durante a exe-cução. Durante a fase de projeto, Cetina e Pelechano [49] definem as seguintes etapas: (i) especificação da variabilidade do sistema reconfigurável; (ii) especificação do contexto do sistema reconfigurável; e (iii) análise das reconfigurações antes de executá-las. Em tempo
11Do inglês, layers architectural pattern. 12Do inglês, goal control layer.
13Do inglês, change control layer. 14Do inglês, component control layer.
de execução, o conhecimento de variabilidade pode ser usado para apoiar a computação autônoma. Desta forma, o esforço de modelagem feito durante a fase de projeto não é apenas útil para produzir o sistema, mas também para fornecer comportamento autônomo durante a execução. Para habilitar o comportamento autônomo, o sistema evolui de uma configuração para outra por si só, utilizando um mecanismo de reconfiguração baseado em modelos, a fim de realizar a reconfiguração conduzida por modelos de variabilidade em tempo de execução. Os autores propõem o MoRE [48, 47, 8] como uma implementa-ção desse mecanismo de configuraimplementa-ção baseado em modelos. O processo apresentado por Cetina e Pelechano [49] define as seguintes etapas durante a execução: (i) depuração das reconfigurações em tempo de execução; (ii) realização do controle das reconfigurações; e (iii) implantação do sistema na plataforma de destino. Entretanto, a solução de Cetina e Pelechano [49, 8] não considera o padrão do ciclo autônomo MAPE-K para a definição do mecanismo de reconfiguração. Além disso, a proposta do modelo de referência ISALYNE-RM visa aplicar conceitos de computação autônoma e de sistemas autoadaptativos para construir DSPLs, sendo inversa à proposta de Cetina e Pelechano [49, 8], que objetiva aplicar a modelagem de variabilidade em sistemas autônomos. A implementação do me-canismo de reconfiguração MoRE foi utilizado como um dos insumos para a elaboração do ISALYNE-RM.
1.3.2
Linhas de Produtos de Software Dinâmicas
Abbas et al. [1] combinaram os conceitos de aplicação autônoma e linha de produtos de software, introduzindo o conceito de Autonomic Software Product Lines (ASPL), ou seja, uma linha de produtos de software com características autônomas. Uma ASPL altera dinamicamente a configuração de um dado produto, usando como entrada as informações de contexto e executando as atividades do ciclo MAPE-K, de forma que o sistema use as informações de tempo de execução sobre o aplicativo e seu ambiente para se autogerenciar. Abbas et al. também propõem um framework ASPLE15, que considera duas linhas de
produtos separadas: (i) a engenharia de domínio ASPL, que define uma plataforma reutili-zável para a lógica de adaptação, sendo corresponde ao Reconfigurador no ISALYNE-RM; e (ii) a linha de produtos base (BSPL16), que se concentra na lógica da aplicação, sendo
correspondente à DSPL no ISALYNE-RM. No entanto, os autores focam apenas no de-senvolvimento da ASPL, não detalhando nem como as duas linhas de produtos (ASPL e BSPL) são integradas e nem como definir e implementar uma BSPL. A ASPL é uma SPL que usa o conceito de arquitetura reflexiva e segue o modelo de referência FORMS. De forma similar, este trabalho utilizou o MAPE-K e o FORMS como base para estabelecer o modelo de referência ISALYNE-RM. No entanto, o ISALYNE-RM concentra-se nas três partes que compõem um sistema reflexivo: o Reconfigurador (subsistema gestor), a DSPL (subsistema gerenciado) e a interface reflexiva que permite a interação entre eles.
Morin et al. [129] se basearam em ideias de SPLE17 e em modelagem orientada a
aspectos para desenvolverem sistemas autoadaptativos. Nessa abordagem, a arquitetura
15Do inglês, Autonomic Software Product Lines Engineering. 16Do inglês, Baseline Software Product Line.
do sistema é construída em três níveis. O nível inferior é responsável pela lógica de aplicação, o nível superior é responsável pelo planejamento da adaptação, enquanto que o nível intermediário liga as camadas superior e inferior. O nível intermediário cria uma ligação de baixo para cima, que analisa dados de sensores e os converte em informações de contexto úteis para o raciocínio, e também uma ligação de cima para baixo, que reflete as mudanças na arquitetura do sistema em execução. O nível superior usa modelos de features em tempo de execução para gerenciar a variabilidade do sistema de forma abstrata. A solução de Morin et al. [129] divide a arquitetura do sistema de forma similar à proposta no modelo de referência ISALYNE-RM. Entretanto, eles propõem uma solução de implementação de DSPL baseada em aspectos e não seguem o padrão MAPE-K, enquanto que o ISALYNE-RM é um modelo de referência que visa abranger as diferentes decisões de projeto para a concepção de DSPLs, baseando-se no padrão MAPE-K para organização da lógica de adaptação.
Paz e Arboleda [147] apresentaram um modelo formal, que é baseado nos princípios de satisfação de restrições, para abordar a tarefa do elemento Planejador, ou seja, o planejamento de adaptação dinâmica do ciclo MAPE-K para aplicações autoadaptati-vas corporatiautoadaptati-vas. Esse modelo foca na mudança de acordos de qualidade, enquanto as aplicações autoadaptativas corporativas estão em execução, entretanto, impactam direta-mente na arquitetura do sistema. Os autores utilizaram um exemplo de execução para demonstrar a aplicabilidade de tal modelo, mesmo em situações onde surgem interações complexas entre os elementos de contexto e a aplicação autoadaptativa corporativa alvo. No contexto de engenharia de linha de produtos, os modelos de decisão e de resolução da OVM18 foram utilizados para planejar a composição dos ativos principais de acordo com
configurações variáveis, que incluem os requisitos de usuários. No entanto, esse modelo formal tem como foco apenas a atividade de planejamento, enquanto que o modelo de re-ferência ISALYNE-RM considera todas as quatro atividades do ciclo autônomo MAPE-K (monitoramento, análise, planejamento e execução).
1.4
Estrutura da Tese
O restante desta tese é estruturado do seguinte modo: o Capítulo 2 apresenta os fun-damentos teóricos necessários para o completo entendimento desta proposta, bem como o mapeamento sistemático realizado para obter o estado da arte do desenvolvimento de DSPLs. O Capítulo 3 apresenta a infraestrutura Cosmapek, incluindo sua infraestru-tura e seu projeto arquiteinfraestru-tural, além de um estudo de viabilidade desenvolvido para sua avaliação. A definição de uma taxonomia para DSPLs é apresentada no Capítulo 4, in-cluindo um estudo comparativo que utiliza a taxonomia proposta. O modelo de referência ISALYNE-RM é descrito no Capítulo 5. Em seguida, para avaliar a aplicabilidade do mo-delo de referência proposto, no Capítulo 6 é apresentado uma instância do ISALYNE-RM apoiado por ferramentas e sua utilização para desenvolver a DSPL e-Shop como prova de conceito. No Capítulo 7 são discutidos os resultados desta tese, destacando as suas principais contribuições, além de indicar os trabalhos futuros.
Fundamentação Teórica e Estado da
Arte
Este capítulo descreve os fundamentos teóricos (disciplinas, técnicas e práticas) usados nesta pesquisa. A Seção 2.1 trata de padrões arquiteturais, modelos e arquiteturas de referência. A Seção 2.2 apresenta os fundamentos de Sistemas de Software Autoadap-tativo. A Seção 2.3 trata dos conceitos relacionados à Linha de Produtos de Software Dinâmica. A Seção 2.4 apresentada uma discussão relacionada à intersecção das áreas de Sistemas de Software Autoadaptativos e Linhas de Produtos de Software Dinâmicas. A Seção 2.5 trata de Desenvolvimento Dirigido por Modelos. Em seguida, a Seção 2.6 trata de Arquitetura Orientada a Serviços. A Seção 2.7 apresenta o mapeamento sistemático da literatura e um estudo comparativo entre abordagens que incluem atributos de depen-dability no desenvolvimento de linhas de produtos de software dinâmicas. E finalmente, a Seção 2.8 apresenta algumas observações finais.
2.1
Padrões Arquiteturais, Modelos de Referência e
Ar-quiteturas de Referência
Padrões arquiteturais, arquiteturas de referência e modelos de referência representam uma forma de reúso sistemático de conhecimento relacionado a um domínio ou conjunto de aplicações, em particular, relacionado ao projeto arquitetural. Bass et al. [29] definem padrões arquiteturais, modelos de referência e arquiteturas de referência como:
• Padrão arquitetural é uma descrição de elementos e tipos de relacionamentos, junta-mente com um conjunto de restrições sobre como eles podem ser usados. Um padrão pode ser pensado como um conjunto de restrições em uma arquitetura (nos tipos de elementos e seus padrões de interação), definindo um conjunto ou uma família de arquiteturas que o satisfaz [29];
• Modelo de referência é um padrão de decomposição de um problema conhecido em partes, que cooperativamente resolvem o problema. Os modelos de referência são uma característica de domínios com maior maturidade [29];
• Arquitetura de referência é um modelo de referência mapeado em elementos de software e o fluxo de dados entre eles [29]. Esses elementos de software trabalham juntos a fim de implementar as funcionalidades do modelo de referência. Uma arquitetura de referência é uma arquitetura genérica que provê a fundação para o futuro projeto de arquiteturas concretas [15].
Padrões arquiteturais, modelos de referência e arquiteturas de referência são conceitos úteis que capturam elementos de uma arquitetura, sendo que cada um é resultado de decisões de projeto tomadas em estágios precoces distintos, mas não são arquiteturas [29]. A Figura 2.1 mostra o relacionamento entre eles.
Padrão Arquitetural Modelo de Referência Arquitetura de Referência Arquitetura de Software
Figura 2.1: Relacionamento entre Modelo de Referência, Padrão Arquitetural, Arquite-tura de Referência e ArquiteArquite-tura de Software (adaptado de [29]).
2.2
Sistemas de Software Autoadaptativos
Esta seção apresenta os conceitos fundamentais de autoadaptação em software (Seção 2.2.1), subsistemas gestor e gerenciado (Seção 2.2.2), ciclos de controle autônomos (Seção 2.2.3) e binding time (Seção 2.2.4). Por fim, na Seção 2.2.5, são descritos os padrões arquiteturais Reflection e Microkernel e o modelo de referência FORMS (Seção 2.2.6).
2.2.1
Autoadaptação
Existem diversas técnicas que permitem ao software se adaptar ao ambiente de execução, possibilitando que sua estrutura seja modificada para reparar erros, melhorar o desem-penho, aumentar a disponibilidade e a segurança em resposta a ataques [126]. Mckinley et al. [126] apontam duas abordagens gerais para fazer adaptação dinâmica no software, sendo a adaptação parametrizada e a adaptação composicional. A adaptação parametri-zada envolve a modificação de variáveis de ambiente que determinam o comportamento do software. Já a adaptação composicional possibilita que módulos sejam adicionados ou substituídos dinamicamente, com o intuito de melhor ajustar o software às variações do ambiente em que é executado. Portanto, a adaptação parametrizada permite apenas ajus-tar parâmetros ou configurar o software para usar uma estratégia diferente, previamente implementada, não possibilitando a incorporação de novas estratégias. Já a adaptação composicional permite ao software se ajustar de acordo com suas novas necessidades em tempo de execução.
Os sistemas capazes de adaptar o seu comportamento ou estrutura em tempo de execução, ou seja, que realizam adaptação composicional, são chamados de Sistemas de
Figura 2.2: Partes constituintes de um sistema autoadaptativo (adaptado de [186]). Software Autoadaptativos (Self-Adaptive Software Systems – SASs) [51, 167, 141] ou Sis-temas Dinamicamente Adaptativos (Dynamically Adaptive System – DASs) [87]. Para realizar a adaptação e evolução, a análise do sistema é realizada de forma contínua e em paralelo com a operação e a manutenção do sistema. A satisfação dos requisitos do sis-tema é regulada e controlada, ajustando continuamente ou melhorando o comportamento do sistema de acordo com as condições do ambiente.
Existem na literatura diversas formas de classificar e categorizar os tipos de autoa-daptação, entre os quais se pode destacar Müller et al. [131] e Salehie e Tahvildari [167]. Segundo Müller et al. [131], a autoadaptação pode ser de dois tipos: (i) estática, onde os mecanismos de adaptação são explicitamente definidos pelos projetistas do sistema para serem escolhidos durante a execução; ou (ii) dinâmica, onde os planos de adaptação e re-quisitos de monitoramento devem ser produzidos e selecionados pelo sistema em tempo de execução. Já Salehie e Tahvildari [167] definem que a autoadaptação pode ser dividida em outras duas categorias: (i) interna, na qual a lógica da aplicação e a lógica de adaptação ficam entrelaçadas, sendo baseada em recursos de linguagem de programação, tais como expressões condicionais, parametrização e exceções; ou (ii) externa, onde o mecanismo de adaptação está em um motor externo separado da lógica da aplicação.
2.2.2
Subsistema Gestor e Subsistema Gerenciado
Seguindo a abordagem de adaptação externa, Weyns et al. [186] utilizam os termos gerais subsistema gestor e subsistema gerenciado para designar as partes constituintes de um sistema de software autoadaptativo, representados na Figura 2.2, onde:
• Subsistema gestor1 gerencia o subsistema gerenciado e é organizado de acordo com
um ciclo de controle autônomo [186], sendo também chamado de architecture layer [83], adaptation engine [167], meta level [42] e reflective subsystem [185];
• Subsistema gerenciado2 consiste na lógica de aplicação que fornece a funcionalidade
de domínio do sistema, sendo também chamado de system layer [83], core function
1Do inglês, managing subsystem. 2Do inglês, managed subsystem.
[167], base level [42] e base-level subsystem [185].
Nessa representação de Weyns et al. [186], o ambiente refere-se à parte do mundo exterior com a qual o sistema autoadaptativo interage e na qual os efeitos do sistema são observados e avaliados, podendo ser tanto hardware quanto software. Segundo os autores, os subsistemas gestor e gerenciado podem ser implementados centralizados ou descentralizados, e ambos subsistemas podem ser explicitamente separados ou (parcial-mente) entrelaçados. Além disso, o sistema gestor pode consistir em um ou mais ciclos de controle autônomos [186].
2.2.3
Ciclos de Controle Autônomos
Embora a autoadaptação em SASs possa ocorrer de várias maneiras, ciclos de controle autônomos3ou ciclos de realimentação4 fornecem o mecanismo genérico de autoadaptação [131]. Um ciclo de controle autônomo geralmente envolve quatro atividades principais: coletar, analisar, decidir e agir [67]. Sensores ou sondas coletam os dados do sistema em execução e de seu contexto sobre seu estado atual. Em seguida, os dados acumulados são limpos, filtrados, ajustados e finalmente armazenados para referência futura, a fim de construir um modelo preciso de estados passados e atuais. Em seguida, o diagnóstico analisa os dados para inferir tendências e identificar sintomas. Posteriormente, o plane-jamento tenta prever o futuro a fim de tomar decisões sobre a forma de agir em relação ao sistema de execução e seu contexto, através de atuadores ou efetores.
MAPE-K
Kephart e Chess [110] propuseram a noção de um elemento autônomo como um bloco de construção para sistemas de autogerenciamento5, na forma de um ciclo
Monitoramento-Análise-Planejamento-Execução com conhecimento compartilhado (MAPE-K) [110, 102], conforme mostra a Figura 2.3. O MAPE-K é um modelo de referência para a criação de ciclos de controle autônomos, composto por quatro atividades ou módulos:
• Monitoramento (Monitor): na primeira atividade do ciclo MAPE-K, os monitores capturam e processam informações de contexto do ambiente que é relevante para o processo de adaptação, através do uso de sensores6. As informações coletadas são
enviadas para a segunda atividade;
• Análise (Analyze): nesta atividade, os analisadores utilizam os dados coletados na atividade anterior e correlacionam informações de contexto para inferir sobre os dados do ambiente de execução e sobre o comportamento do sistema;
• Planejamento (Plan): na terceira atividade, os planejadores usam os dados analisa-dos para definir planos de adaptação;
3Do inglês autonomic control loops. 4Do inglês feedback loops.
5Do inglês, self-managing. 6Do inglês, sensors.
Figura 2.3: Ciclo MAPE-K (adaptado de [110, 102]).
• Execução (Execute): na última fase do ciclo, os executores implementam e executam os planos para adaptar o sistema atual e obter o comportamento desejado, através do uso de efetores7 ou atuadores8.
A atividade de monitoramento alimenta continuamente o ciclo de adaptação, reiniciando-o. A base de conhecimento (knowledge base – K) apoia o fluxo de informações necessárias ao longo de todo o ciclo. É comum encontrar na literatura uma variação do MAPE-K chamada MAPE, onde a base de conhecimento (K) continua existindo, todavia é abstraída para fins de simplificação, como ocorre em [186, 66].
Segundo Weyns et al. [186], as funções MAPE-K podem ser mapeadas para diferentes componentes ou integradas em um ou mais componentes. Assim, existem cinco diferen-tes padrões para MAPE-K descentralizado, considerando as interações entre as diferendiferen-tes fases de ciclos autônomos realizados pelos componentes MAPE-K, são eles: controle coor-denado9, compartilhamento de informações10, mestre/escravo11, planejamento regional12 e controle hierárquico13 [186, 66].
2.2.4
Binding Time
Binding time14 é o nome dado ao momento em que uma adaptação é efetivada. Krisper e Kreiner [113] definem o binding time como o último momento durante o ciclo de vida
7Do inglês, effectors. 8Do inglês, actuators.
9Do inglês, coordinated control. 10Do inglês, information sharing. 11Do inglês, master/slave. 12Do inglês, regional planning. 13Do inglês, hierarchical control.
14Entre as traduções possíveis estão “tempo vinculativo”, “tempo de ligação”, “tempo de amarração”,
entre outras. Por não haver um consenso em relação à tradução mais apropriada, nesta tese optou-se por manter o termo original em inglês.
