Resumo - Estudos primários versus ciclo de controle autônomo MAPE-K

A.1 Estudos primários versus ciclo de controle autônomo MAPE-K

2.8 Resumo

Esse capítulo apresentou conceitos que são utilizados no decorrer dessa tese, como linhas de produtos de software (dinâmicas), sistemas autoadaptativos e arquitetura de software. Este capítulo também relatou o estudo realizado seguindo o processo de mapeamento sistemático (Systematic Mapping Study – SMS), buscando na literatura artigos relacionados a dependability em DSPLs e SASs, e permitindo a análise dos desafios e das desvantagens da área (Seção 2.7).

Com o conhecimento obtido no mapeamento sistemático e em práticas realizadas con- juntamente com o grupo de pesquisa, foi possível projetar e implementar uma infraestrutura de implantação autoadaptativa, denominada Cosmapek. A infraestrutura Cosmapek foi desenvolvida com o objetivo de adquirir experiência no desenvolvimento de DSPLs, sendo conduzida em conjunto com outros pesquisadores do grupo de pesquisa e, posteri- ormente, estendida no contexto desta tese (Capítulo 6). Os requisitos da infraestrutura Cosmapek foram definidos com base nas conclusões do SMS e de seu estudo comparativo, sendo que tal infraestrutura é detalhada no Capítulo 3.

Cosmapek: Uma Infraestrutura de

Implantação Autoadaptativa para

Linhas de Produtos de Software

Dinâmicas

Utilizando os conceitos de linhas de produtos de software dinâmicas e sistemas autoadaptativos (Capítulo 2), bem como o conhecimento adquirido com a realização do mapeamento sistemático e de seu estudo comparativo, descrito na Seção 2.7, foi projetada e implementada a infraestrutura Cosmapek. Neste capítulo é descrita a Cosmapek, uma infraestrutura baseada em sistemas autoadaptativos para a implantação de configura- ções arquiteturais, em tempo de execução, em linhas de produtos de software dinâmicas. Essa infraestrutura 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. A infraestrutura Cosmapek foi projetada para permitir a reconfiguração arquitetural em tempo de execução em DSPLs implementadas em Java.

Este capítulo está estruturado conforme a seguir. Uma visão geral da Cosmapek é apresentada na Seção 3.1 e a infraestrutura Cosmapek é apresentada 3.2, incluindo sua organização interna e seu projeto arquitetural. Na Seção 3.3 é apresentado um estudo com o objetivo de verificar a viabilidade de construção e execução de DSPLs baseadas na Cosmapek. Por fim, na Seção 3.4, são discutidos os trabalhos relacionados, seguida das observações finais apresentadas na Seção 3.5.

3.1 Visão Geral

A infraestrutura de implantação adaptativa, denominada Cosmapek, é baseada nos conceitos de DSPL. A 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 (modelo PLA) para prover variabilidade, através da reconfiguração arquitetural em tempo de execução.

Além disso, a Cosmapek tem como seus alicerces os conceitos de sistemas autoadap-

tativos, do qual pode-se destacar:

• Arquitetura autoadaptativa: utiliza abordagem de adaptação externa, separando o mecanismo de adaptação da lógica da aplicação. Essa arquitetura autoadaptativa também segue o padrão arquitetural Reflection (Seção 2.2.5), que utiliza reflexão computacional e divide o sistema autoadaptativo em dois níveis ou subsistemas, um com a lógica de adaptação e outro com a lógica de domínio. Para a concepção da Cosmapek, esses dois níveis ou subsistemas foram projetados seguindo a nomencla- tura de subsistema gestor e subsistema gerenciado; e

• Ciclo de controle autônomo MAPE-K : compõe o núcleo de adaptação da infraestrutura Cosmapek. A infraestrutura Cosmapek implementa as principais atividades do ciclo MAPE-K, que são realizadas pelo subsistema gestor, por meio de componentes gestores, aqui chamados de módulos:

– O módulo Monitor monitora o subsistema gerenciado por meio de sensores e armazena a situação dos sensores (ativado ou desativado) na base de conhecimento;

– O módulo Analyzer utiliza os dados da base de conhecimento para analisar o subsistema gerenciado, a fim de decidir se deve ou não reconfigurar a arquitetura do subsistema;

– O módulo Planner gera planos de reconfiguração arquitetural de acordo com o modelo de features e seu mapeamento para elementos da arquitetura;

– Finalmente, o módulo Executor utiliza os efetores para implantar a nova con- figuração arquitetural, reconfigurando o subsistema gerenciado em execução, alterando sua configuração arquitetural atualmente implantada.

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 avaliar a implementação da Cosmapek e simultaneamente verificar a viabilidade de cons- trução de uma DSPL que seja executada na plataforma Android, foi implementada uma aplicação autoadaptativa para Android, denominada Buscame. A plataforma Android foi escolhida devido à escassez de infraestruturas e soluções autoadaptativas para essa plataforma e devido ao fato da linguagem de programação Java ser a base para o desenvolvimento de aplicações Android. A Seção 3.3 apresenta os detalhes sobre o estudo de viabilidade da DSPL Buscame.

3.2 Cosmapek

3.2.1 Infraestrutura

A infraestrutura Cosmapek é composta por dois subsistemas: o subsistema gestor e o subsistema gerenciado. O subsistema gestor é o núcleo da infraestrutura Cosmapek, enquanto que o subsistema gerenciado é uma DSPL que será desenvolvida e acoplada à Cosmapek.

Executor Analyzer

Monitor

Planner

Figura 3.1: Visão geral da infraestrutura Cosmapek.

A Figura 3.1 apresenta uma visão geral da infraestrutura Cosmapek, representando o subsistema gestor e uma configuração implantada do subsistema gerenciado.

Subsistema Gestor. O subsistema gestor é o núcleo da infraestrutura Cosmapek e tem a lógica de adaptação, sendo independente da DSPL e transparente à mesma, podendo ser reutilizado em diferentes domínios. O subsistema gestor engloba as principais atividades para executar um ciclo MAPE-K: Monitor, Analisador (Analyzer), Planejador (Planner) e Executor. A Figura 3.1 ilustra essas atividades formando um ciclo.

Os sensores monitoram o subsistema gerenciado e enviam essas informações para o módulo Monitor. O módulo Analisador usa os dados do módulo Monitor e analisa o subsistema gerenciado. O módulo Planejador gera os planos de reconfiguração arquitetural, selecionando a configuração arquitetural mais adequada para ser implantada, de acordo com a base de conhecimento. Finalmente, o módulo Executor utiliza os efetores para executar os planos de reconfiguração e implantar a nova arquitetura do subsistema gerenciado, alterando a configuração atualmente implantada.

O subsistema gestor fornece dois pontos de extensão onde serão conectados os sensores e efetores, que fazem parte do subsistema gerenciado. O primeiro ponto de extensão indica os sensores implementados e aos quais o módulo Monitor está conectado, permitindo a coleta de informações dos componentes dinâmicos do subsistema gerenciado. O segundo ponto de extensão refere-se aos efetores que manipularão a configuração arquitetural do subsistema gerenciado em tempo de execução. Sensores e efetores são usados,

respectivamente, para coletar detalhes e para alterar o comportamento do subsistema gerenciado.

Base de Conhecimento. Os modelos e artefatos que representam a DSPL são arma- zenados na base de conhecimento, como mostrado na Figura 3.1. Esta base reúne os subsídios necessários para conhecer a DSPL e alimentar o ciclo de controle do subsistema gestor. A base de conhecimento Cosmapek é composta por:

1. Modelo de features: é um arquivo XML contendo a representação da variabilidade dinâmica, que define em termos de features quais configurações podem ser aplicadas à DSPL;

2. Modelo arquitetural + Mapeamento de features: é um arquivo XML contendo os elementos arquiteturais (componentes, sensores e conectores) e a ordem de prioridade de implantação desses elementos;

3. Estado dos sensores: é uma estrutura de dados, gerada durante a execução do sistema, que registra os estados dos sensores do sistema. O estado de sensor pode ser “ativo” ou “desativado” e representa um sinalizador que indica se há um problema, sendo usado pelo subsistema gestor para definir se alguma ação é necessária; e 4. Elementos arquiteturais executáveis: são representações binárias dos elementos do

modelo arquitetural.

Os dois primeiros itens são arquivos XML que devem ser produzidos e fornecidos pelo desenvolvedor da DSPL. O terceiro item é automaticamente gerado pelo subsistema gestor durante a execução, enquanto que o último item são os arquivos compilados referentes à DSPL.

3.2.2 Projeto Arquitetural

A Figura 3.2 apresenta o diagrama UML da infraestrutura Cosmapek, contendo três tipos de componentes de implementação: (i) componentes que implementam as funcionalidades do ciclo MAPE-K: Monitor, Analyzer, Planner e Executor; (ii) componentes que geren- ciam a base de conhecimento: Components, Features, Connectors e Variability; e (iii) componentes que fazem o apoio operacional do subsistema gestor: Reader e Controller.

Esse modelo arquitetural se refere somente ao subsistema gestor e fornece: (i) dois pontos de extensão para o desenvolvimento dos sensores e efetores, que farão parte da DSPL, que são as interfaces ISensor e IExecution, respectivamente; e (ii) duas interfaces para que a aplicação principal inicie o subsistema gestor (IControllerManager e IReaderManager). A interface IControllerManager é usada para especificar o intervalo de tempo que a infraestrutura deve aguardar para analisar o registro dos sensores. A interface IReaderManager é usada para especificar os arquivos de configuração necessários para a infraestrutura.

A infraestrutura Cosmapek foi implementada em Java seguindo o modelo de imple- mentação de componentes dinâmicos DyCosmos [46] e Java Reflection API, gerando um

<<component>> Components <<component>> Features <<component>> Monitor <<component>> Variability <<component>> Connectors <<component>> Reader <<component>> Controller <<component>> Analyzer <<component>> Planner <<component>> Executor <<sensor>> ASensorSample IFeatureManager IConnectorManager IVariabilityManager IReadingManager ISensorManager IPlanningManager IComponetManager IAnalysisManager ISensor <<sensor>> <<application>> <<component>> Give me a solution without these failed features Give me the elements that will be reconfigured

Update the elements that work at runtime (this sends the feature names) Give me the sensors that are executing. IExecution IExecutionManager Sensor Component Annotation

Application Required interface Provided interface Application <<application>> <<sensor>> ASensorSample IControllerManager Give me the failed features

Figura 3.2: O modelo arquitetural da infraestrutura Cosmapek.

total de 8.655 SLOC1_{. O código-fonte da infraestrutura Cosmapek está disponível em}

https://git.facom.ufms.br/jane.eleuterio/Cosmapek.

3.3 Estudo de Viabilidade

Os smartphones, hoje em dia, fornecem o mesmo poder de computação e capacidades similares aos computadores pessoais de uma década atrás, permitindo o desenvolvimento de aplicações complexas [43]. Consequentemente, as aplicações móveis podem exigir requisitos não funcionais, tais como tolerância a falhas, execução distribuída e a capacidade de lidar com variações na disponibilidade de serviços e de recursos computacionais.

No entanto, a maioria dos aplicativos móveis de hoje são implantados usando confi- gurações estáticas e são incapazes de tolerar falhas durante sua execução. Um aplicativo implantado com configuração estática é preparado para um contexto inicial e, em geral, não está preparado para alterações que podem ocorrer durante sua execução. Em con- traste, a implantação dinâmica permite que os aplicativos se autoadaptem às mudanças que ocorrem no ambiente.

A infraestrutura Cosmapek foi projetada para permitir reconfiguração arquitetural em tempo de execução em DSPLs implementadas em Java. A plataforma Android tem a linguagem de programação Java como base para o desenvolvimento de suas aplicações. Com o objetivo de verificar a viabilidade da implementação da infraestrutura Cosmapek e, simultaneamente, verificar a viabilidade da construção de uma DSPL que execute na plataforma Android, foi implementada uma aplicação autoadaptativa em Android, denominada Buscame.

A Buscame permite ao usuário a realização de buscas por empresas localizadas perto de uma localização geográfica específica, utilizando o Google Maps, sendo dividida em

Figura 3.3: Modelo de features da DSPL Buscame.

componente servidor, que contém os serviços REST, provedores de informação que são utilizadas pela aplicação, e componente cliente, que contém a aplicação Android. Esses dois componentes da aplicação Buscame são discutidos a seguir.

3.3.1 O Componente Cliente

O componente cliente contém a aplicação Android, que corresponde a um sistema autoadaptativo composto por: (i) uma DSPL, que contém a variabilidade e a lógica de negócio da aplicação Buscame; e (ii) pela infraestrutura Cosmapek, que gerencia e manipula a DSPL.

Modelagem de features. Para o desenvolvimento da aplicação Buscame, primeira- mente foram definidos os requisitos e levantadas as variabilidades, utilizando a modelagem de features. O modelo de features foi elaborado graficamente utilizando a ferramenta FeatureIDE [176, 65], sendo gerada a representação em um documento XML correspon- dente ao modelo. Entretanto, a ferramenta FeatureIDE não possui uma notação para a modelagem de features dinâmicas. Assim, os modelos gerados foram estendidos para atender a essas necessidades. O novo modelo de features foi desenhado manualmente, no qual foram definidos retângulos tracejados para separar as features estáticas e dinâmicas, como mostra a Figura 3.3. A DSPL Buscame possui cinco features estáticas e obrigató- rias, que representam o núcleo para o funcionamento da aplicação, bem como oito features dinâmicas, que podem ser selecionadas e aplicadas em tempo de execução.

Modelagem arquitetural. O modelo arquitetural da aplicação Buscame, ou modelo PLA, foi elaborado na forma de diagramas de componentes UML, utilizando a ferramenta Astah [50]. A Figura 3.4 apresenta o modelo PLA da DSPL Buscame, sendo composta de:

• Quatro componentes base: Controller, UI, Company e Client, que estão presentes em toda configuração implantada da DSPL. Esses componentes compõem a estrutura base para a execução da aplicação Buscame;

Figura 3.4: Modelo arquitetural da DSPL Buscame.

• Oito componentes dinâmicos: Product, ProductB, ProductC, Location, LocationB, LocationC, Con figuration e ConfigurationB, que são componentes relacionados a fe- aturesdinâmicas e que podem ser implantados ou desligados em tempo de execução. Esses componentes realizam requisições REST para o provedor de serviços;

• Oito componentes sensores: ProductSensor, ProductBSensor, ProductCSensor, LocalizationSensor, LocalizationBSensor, LocalizationCSensor, Con figurationSensor e Con figurationBSensor, que são responsáveis por captar informações do respectivo componente dinâmico ao qual está associado.

Mapeamento entre features e componentes. App é uma feature abstrata que representa a aplicação Buscame e contém a feature Buscame, que representa o núcleo da aplicação e é mapeada aos componentes Controller, UI, Company e Client. As features Configuration, Localization e Product são abstratas e têm como função agrupar um sub- conjunto de features que pertencem ao mesmo ponto de variação. Cada ponto de variação contém uma escolha entre features alternativas mutuamente excludentes. Os três pontos de variação contêm features dinâmicas e suas resoluções somente poderão ocorrer durante a execução. Cada feature dinâmica é mapeada a um componente dinâmico de mesmo nome.

Elaboração dos documentos XML. O documento XML gerado pela ferramenta Fe- atureIDE foi então manualmente estendido para permitir a especificação de quais features eram dinâmicas, além do mapeamento entre features e componentes. A Figura 3.5 mostra o documento XML com o modelo de features estendido, contendo as features estáticas e dinâmicas e o mapeamento para os respectivos componentes.

<?xml version="1.0" encoding="UTF−8" standalone="no"?> <featureModel>

<andabstract="true" mandatory="true" name="App">

<andmandatory="true" name="Buscame" umlcomponents="Controller/Company/UI/Client"> <altabstract="true" mandatory="true" name="Configuration">

<featuredynamic="true" mandatory="true" name="ConfigurationA" umlcomponents="ConfigurationA"/> <featuredynamic="true" mandatory="true" name="ConfigurationB" umlcomponents="ConfigurationB"/> </alt>

<altabstract="true" mandatory="true" name="Localization">

<featuredynamic="true" mandatory="true" name="LocalizationA" umlcomponents="LocalizationA"/> <featuredynamic="true" mandatory="true" name="LocalizationB" umlcomponents="LocalizationB"/> <featuredynamic="true" mandatory="true" name="LocalizationC" umlcomponents="LocalizationC"/> </alt>

<altabstract="true" name="Product">

<featuredynamic="true" mandatory="true" name="ProductA" umlcomponents="ProductA"/> <featuredynamic="true" mandatory="true" name="ProductB" umlcomponents="ProductB"/> <featuredynamic="true" mandatory="true" name="ProductC" umlcomponents="ProductC"/> </alt>

</and> </and> </struct> </featureModel>

Figura 3.5: Documento XML de variabilidade da DSPL Buscame.

Similarmente, o modelo arquitetural foi manualmente transformado para atender ao modelo de componentes DyCosmos e então traduzido para um documento XML, contendo os componentes, os conectores, os sensores e a ordem de prioridade. O valor baixo de prioridade indica um componente com baixa ou nenhuma dependência, devendo ser implantado antes dos demais, enquanto que o valor alto de prioridade denota um componente com muitas dependências, sendo que este somente poderá ser implantado após a implantação de suas dependências. O estabelecimento da ordem de prioridade foi realizado manualmente, através da transformação do modelo PLA em um grafo acíclico direcionado (DAG2_{) e da aplicação de um algoritmo de ordenação topológica. A Figura}

3.6 mostra parcialmente o documento XML construído para representar a arquitetura.

Codificação. A implementação foi realizada com o uso do ambiente de programação Android Studio3_{, a linguagem Java e seguindo o modelo de implementação de componentes}

DyCosmos [46]. A aplicação construída corresponde a aproximadamente 9.320 SLOC.

3.3.2 O Componente Servidor

No componente servidor, foram implementados oito serviços divididos em três grupos, sendo eles Con figuration, Localization e Product. Cada grupo de serviços possui servi- ços alternativos4 que têm a mesma funcionalidade, as mesmas informações armazenadas e quase o mesmo código, provendo seus serviços em portas diferentes, e utilizando diferentes bancos de dados para o armazenamento de suas informações. Especificamente, foi utilizado o OrientDB, sistema de gerenciamento de banco de dados NoSQL, para o

2_{Sigla do inglês, Directed Acyclic Graph.} 3_{https://developer.android.com/studio/}

4_{Do inglês alternate services, técnica de tolerância a falhas que permite composições confiáveis de}

<?xml version="1.0" encoding="UTF−8" standalone="no"?> <config>

<!−−static components −−>

<componentname="Controller" feature="Buscame" isSensor="false" orderT="149"/> <componentname="Company" feature="Buscame" isSensor="false" orderT="141"/> ...

<!−−dynamic components −−>

<componentname="Configuration" feature="ConfigurationServiceA" isSensor="false" orderT="132"/> <componentname="ConfigurationB" feature="ConfigurationServiceB" isSensor="false" orderT="137"/> <componentname="Product" feature="ProductServiceA" isSensor="false" orderT="102"/>

...

<!−−special cases −−>

<componentname="Conn_sensors_configurationSensor" feature="ConfigurationServiceA" orderT="131"/>

<componentname="Conn_sensors_configurationBSensor" feature="ConfigurationServiceB" orderT="136"/>

<componentname="Conn_sensors_localizationSensor" feature="LocalizationServiceA" orderT="116"/> ...

<!−− sensors−−>

<componentname="ConfigurationSensor" feature="ConfigurationServiceA" isSensor="true" orderT="134"/> <componentname="ConfigurationBSensor" feature="ConfigurationServiceB" isSensor="true" orderT="139"/> <componentname="LocalizationSensor" feature="LocalizationServiceA" isSensor="true" orderT="119"/> ...

</componets> <connectors>

<!−− cosmapek.connectors are also cosmapek.components−−>

<connectorname="Conn_ui_controller" origin="Ui" destination="Controller" orderT="148"/> <connectorname="Conn_client_controller" origin="Client" destination="Controller" orderT="146"/> <connectorname="Conn_client_ui" origin="Client" destination="Ui" orderT="145"/>

<connectorname="Conn_company_controller" origin="Company" destination="Controller" orderT="142"/> ...

</connectors> </config>

Figura 3.6: Documento XML de arquitetura da DSPL Buscame.

armazenamento dos dados da aplicação Buscame. Os serviços contabilizam aproximadamente 3202 SLOC, sendo implementados usando o Restlet, um framework que mapeia os conceitos REST para classes Java [120].

3.3.3 Medições

A aplicação Buscame e a infraestrutura Cosmapek foram executadas em um smartphone da marca Motorola, modelo Moto G (2ª geração), com o sistema operacional Android (Versão 5.0 API 21 Lollipop). Os serviços foram executados em um computador portátil da marca Toshiba, com processador Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz e memória RAM de 4GB. As medições foram executadas em duas etapas.

A primeira etapa teve como objetivo examinar se a aplicação Buscame, usando a infraestrutura Cosmapek, tem a capacidade de lidar com cenários excepcionais. Para alcançar esse objetivo, foram projetadas duas atividades, as quais foram aplicadas aleatoriamente durante três horas: (i) na primeira atividade, foi desativado algum serviço utilizado no momento e aguardou-se a reação da aplicação Buscame ao evento causado; e (ii) na segunda atividade, foi reativado apenas um serviço anteriormente desativado e aguardou-se a reação da aplicação. Ao analisar os registros gerados pela aplicação, verificou-se que a aplicação Buscame teve a sua configuração arquitetural alterada diversas vezes em res- posta aos eventos causados. Entretanto, ocorreu um atraso na detecção dos eventos por parte dos sensores, possivelmente causado pelo sistema operacional Android.

0 500 1000 1500 2000 2500 3000 3500 0 1 2 3 4 5 6 7 8 T emp o em milise gundos An´alise

Figura 3.7: Intervalos de tempo para executar a atividade de análise na Buscame.

A segunda etapa consistiu em medir o desempenho da infraestrutura Cosmapek ao realizar uma adaptação na DSPL Buscame. Para simular diferentes ambientes, foram criados scripts em Shell e em Java que desativam e reativam periodicamente, de forma controlada, os serviços. Especificamente, nesta etapa, foi executado um experimento para medição, onde cada ambiente simulado foi construído aleatoriamente para ter pelo menos uma solução aplicada. Nessa medição, a cada 5 minutos e 30 segundos, foi gerado um novo

No documento Técnicas de sistemas autônomos e autoadaptativos para apoiar linhas de produtos de software dinâmicas (páginas 60-74)