Jackson Raniel Florencio da Silva · 2019. 10. 25. · O ato de selecionar o conjunto de características que irão compor o produto e construí-lo para ser entregue é chamado de

DYMOS QOS: UMA ABORDAGEM PARA SELEÇÃODE SERVIÇOS EM TEMPO DE EXECUÇÃO EM

LINHAS DE PRODUTO DE SOFTWARE DINÂMICAS

por

Jackson Raniel Florencio da Silva

Dissertação de Mestrado

Universidade Federal de Pernambuco

[email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE2014

www.cin.ufpe.br/~posgraduacao

Universidade Federal de Pernambuco

Centro de InformáticaPós-graduação em Ciência da Computação

Jackson Raniel Florencio da Silva

DYMOS QOS: UMA ABORDAGEM PARA SELEÇÃODE SERVIÇOS EM TEMPO DE EXECUÇÃO EM

LINHAS DE PRODUTO DE SOFTWARE DINÂMICAS

Trabalho apresentado ao Programa de Pós-graduação em

Ciência da Computação do Centro de Informática da Univer-

sidade Federal de Pernambuco como requisito parcial para

obtenção do grau de Mestre em Ciência da Computação.

Orientador: Vinicius Cardoso Garcia

RECIFE2014

Dissertação de mestrado apresentada por Jackson Raniel Florencio da Silva ao programa dePós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federalde Pernambuco, sob o título Dymos QoS: Uma Abordagem para Seleçãode Serviços em Tempo de Execução emLinhas de Produto de Software Dinâmicas, orientada pelo Prof. Vinicius Cardoso Garcia eaprovada pela banca examinadora formada pelos professores:

———————————————————————–Prof. Kiev Santos Gama

Centro de Informática / UFPE

———————————————————————–Profa. Rossana Maria de Castro Andrade

Departamento de Computação / UFC

———————————————————————–Prof. Vinicius Cardoso GarciaCentro de Informática / UFPE

RECIFE2014

Dedico esta dissertação a todas as pessoas que se

sacrificaram junto comigo nos momentos em que necessitei

ser ausente.

Agradecimentos

Utilizar palavras para expressar sentimentos tão vastos na forma de agradecimento é umatarefa difícil para mim. Nenhum conjunto de códigos e seus respectivos significados semânticospodem expressar um pedaço da minha alma. No entanto coloco aqui o meu esforço em fazê-lode maneira singela ao mesmo tempo que extremamente sincera.

Agradeço primeiro ao Pai do Céu que sempre me protegeu, me guiou e atendeu aquelespedidos que fiz da forma como julgou ser melhor. Sua bondade e graça é tamanha a ponto deme amar imensamente mesmo eu não sendo um exemplo de filho. Por isso reservo a Ele esteprimeiro lugar nos meus agradecimentos.

A partir de agora os meus agradecimentos não seguem uma ordem de importância, vistoque apenas vou agradecer aqueles que representam uma extensão do amor divino aqui na terra.Sendo assim, agradeço aos meus pais, avós e irmã por me devotarem tanto amor desde a minhamais tenra idade, além de me acompanhar a cada passo dado e me ensinar tanto a cada dia.

Agradeço àquela que em breve será a minha companheira eterna por estar ao meu ladonos últimos sete anos construindo dia-a-dia um relacionamento de duas pessoas em apenas umaentidade. Este amor revelado na forma de amizade, companheirismo, dedicação e tantas outrasfacetas foi meu arrimo durante muitos momentos.

Agradeço, por fim, ao meu orientador por ter me guiado durante esta caminhada. Assimcomo agradeço ao Centro de Informática da Universidade Federal de Pernambuco por todo apoioestrutural que me foi dado durante a realização desse trabalho.

Omnia Vincit Amor.

—VIRGÍLIO (70 a.c. - 19 a.c.)

Resumo

A produção industrial antes de Taylor era essencialmente manufatureira e focada emprodutos únicos. O Taylorismo e seus estudos de tempos e movimentos levaram para a indústriaa ideia de padronização dos produtos. Ford, tempos depois, inventou a linha de produtos, onde apartir de então foi possível produzir em massa reduzindo o tempo de entrega do produto e seuscustos. No que tange a indústria de software, esta apresenta tanto uma produção manufatureiraquanto em massa que gera produtos que são denotados segundo POHL; BöCKLE; LINDEN(2005) como software individual e software standard: uma clara influência do fordismo naconcepção do paradigma de Linhas de Produto de Software (SPL). No entanto, este paradigmade desenvolvimento não foi concebido para suportar mudanças nos requisitos de usuários emtempo de execução. Diante deste problema, a academia tem desenvolvido e proposto maneirasde estender o paradigma de SPL de forma a permitir que essas reconfigurações dinâmicas dosoftware sejam suportadas. Surgiram deste esforço as Linhas de Produto de Software Dinâmicas(DSPL) (HALLSTEINSEN et al., 2008). Levando em consideração este cenário, objetiva-senesta pesquisa contribuir com a área de DSPL apresentando uma nova maneira de pensar quaiscaracterísticas de uma DSPL devem ser ligadas em tempo de execução a um produto com baseem uma análise que mensura e valida atributos de qualidade em níveis de serviços especificadospelo usuário. Para tanto foi necessária a revisão da literatura existente em busca de meios deanalisar atributos de qualidade de serviços em tempo de execução em DSPL e o desenvolvimentoexploratório de uma abordagem de reconfiguração da DSPL utilizando-se das característicasdinâmicas do OSGi como base em tal análise. Com a finalidade de validar a abordagem proposta,a mesma foi testada exploratoriamente em uma DSPL para o domínio de guia de visitas móveise sensível ao contexto, onde pode-se verificar a assertividade desta. Ao final da validaçãoexploratória pode-se observar a efetividade da abordagem proposta na DSPL na qual foi aplicada.No entanto, faz-se necessário a execução de testes estatísticos para comprovar a hipótese de queesta efetividade demonstrada é válida para outras DSPLs de outros domínios.

Palavras-chave: Linhas de Produto de Software. SPL. SPL Dinâmica. DSPL. Qualidade deServiços.

Abstract

The industrial production before Taylor was essentially focused on manufacturing andunique products. The Taylorism and his time and motion studies had led to the industry theidea of standardization of products. Ford, sometime later, invented the product line whichfrom then on was possible to mass produce by reducing the delivery time and product costs.Regarding the software industry, it presents both a manufacturing and mass production thatgenerates products that are denoted for Pohl et al. (2005) as individual software and standardsoftware: a clear influence of Fordism in the design paradigm of Software Product Lines (SPL).However, this development paradigm was not designed to support changing requirements ofusers at runtime. Faced with this problem, the academy has developed and proposed ways toextend the paradigm of SPL in order to enable such dynamic reconfigurations of software. Fromthis effort emerged the Dynamics Software Product Lines (DSPL) (Hallsteinsen et al., 2008).Considering this scenario, the objective of this dissertation is to contribute to this research areapresenting a new way of thinking which features a DSPL should be connected at runtime toa product based on an analysis that measures and validates quality attributes in service levelsspecified by the user. For this, it was necessary to review the existing literature searching meansof analyzing service quality attributes at runtime in DSPL and an exploratory development of anapproach for reconfiguration of DSPL using dynamic features OSGi based. In order to validatethe proposed approach , it was tested in a mobile and context-aware DSPL, where we can verifythis assertiveness. At the end of the exploratory validation we can observe the effectiveness ofthe proposed approach in DSPL in which it was applied. However, it is necessary to performstatistical evidence for the hypothesis that this demonstrated effectiveness is valid for other areasDSPLs other tests.

Keywords: Software Product Line. SPL. Dynamic SPL. SPL. Service Quality attributes.

Lista de Figuras

1.1 Cenário do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1 Distribuição Anual de Estudos a Respeito de Derivação Dinâmica . . . . . . . 232.2 MADAM Platform Architecture (HALLSTEINSEN et al., 2006) . . . . . . . . 24

3.1 DYMOS - Diagrama de Pacotes (OLIVEIRA MARTINS, 2013) . . . . . . . . 313.2 DYMOS - Diagrama de Sequência - Reconfiguração de Serviços (OLIVEIRA MAR-

TINS, 2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3 DYMOS - Diagrama de Sequência - Descoberta de Serviços (OLIVEIRA MAR-

TINS, 2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4 DYMOS QoS - Diagrama de Pacotes . . . . . . . . . . . . . . . . . . . . . . . 363.5 DYMOS QoS - Diagrama de Sequência - Descoberta de Serviços . . . . . . . . 36

4.1 GreatTour - Modelo de Features . . . . . . . . . . . . . . . . . . . . . . . . . 414.2 Cin Tour - Modelo de Features . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3 Tempo de Resposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4 Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Lista de Tabelas

4.1 Valores de QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2 Capacidades Máximas e Atuais . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3 Custo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4 Desempenho do Dymos QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.5 Desempenho do Dymos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Lista de Acrônimos

-DOP Delta Oriented ProgramingDSPL Linha de Produtos de Software DinâmicaSPL Linha de Produtos de SoftwareOSGi Open Service Gateway InitiactiveSCM Computação Orientada a ServiçoSOA Arquitetura Orientada a ServiçoSEI Software Engineering Institute

Sumário

1 Introdução 131.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2 Problemática e Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2.1 Métodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.3 Visão Geral da Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4 Escopo Negativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.5 Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Revisão da Literatura 192.1 Computação Orientada a Serviços . . . . . . . . . . . . . . . . . . . . . . . . 192.2 Qualidade de Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3 Linhas de Produto de Software . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.1 O Estado da Arte em Derivação Dinâmica . . . . . . . . . . . . . . . . 222.3.1.1 Estudos em Derivação Dinâmica . . . . . . . . . . . . . . . 23

2.4 A Interação entre SOC e DSPL . . . . . . . . . . . . . . . . . . . . . . . . . . 282.5 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3 DYMOS QoS 303.1 Análise Exploratória . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.1.1 Operações do DYMOS . . . . . . . . . . . . . . . . . . . . . . . . . . 323.2 Intervenção Exploratória . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2.1 Seleção de Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.3 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Avaliação 404.1 Validação Exploratória . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2 Avaliação Estatística Descritiva . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5 Conclusão 495.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Referências 53

131313

1Introdução

- Quarenta e dois [...]

Eu verifiquei cuidadosamente e não há dúvida de que a resposta é essa. Para

ser franco, acho que o problema é que vocês jamais souberam qual é a

pergunta.

—DOUGLAS ADAMS (O Guia do Mochileiro das Galáxias)

O legado deixado por Ford com a criação da linha de produtos modificou os meios depensar a atividade industrial. No que tange à indústria de software, esta, apresenta tanto umaprodução manufatureira quanto em massa que gera produtos que são denotados segundo POHL;BöCKLE; LINDEN (2005) como software individual e software standard.

Denota-se, neste contexto, uma clara influência do fordismo na concepção do paradigmade Linhas de Produto de Software (SPL). Neste paradigma os produtos de software são criados apartir de um conjunto comum de características, diferenciando-se entre si pelo gerenciamento deum conjunto de características variáveis que diferenciam cada produto.

O paradigma SPL é tradicionalmente divido em duas fases: a fase de Engenharia de Linhade Produtos e a fase de Engenharia do Produto. Na primeira fase são definidas e implementadastodas as características que estarão presentes em todos os produtos chamadas de core assets,assim como as características variáveis que podem ou não estar em um produto da SPL. Durantea fase de Engenharia de Produto, são selecionadas para compor o produto além dos core assets

as características variáveis que atendem a determinados requisitos de usuários que justificam asua escolha para a composição do produto.

O ato de selecionar o conjunto de características que irão compor o produto e construí-lo para ser entregue é chamado de derivação de produto. Sendo assim, este paradigma dedesenvolvimento não foi concebido para suportar mudanças nos requisitos de usuários em tempode execução. Diante deste problema, a academia tem desenvolvido e proposto maneiras deestender o paradigma de SPL, de forma a permitir que essas reconfigurações dinâmicas dosoftware sejam suportadas. Surgiram deste esforço as Linhas de Produto de Software Dinâmicas

1.1. MOTIVAÇÃO 14

(DSPL) (HALLSTEINSEN et al., 2008).

1.1 Motivação

O projeto Ubstructure1 mantém a MobiLine, que é uma DSPL para aplicações móveissensíveis ao contexto dividida em dois níveis de abstração: base e específico. O nível basepossui características comuns a aplicações móveis e sensíveis ao contexto. Já o nível específico écomposto por características que pertencem a um determinado domínio de negócio (MARINHOet al., 2012).

Esta SPL é composta por dois produtos: o GREat Tour e o Cin Tour, que são guias devisitas móveis sensíveis ao contexto derivados da MobiLine. Ambos são executados a partir dedispositivos que possuem o sistema operacional Android e fornecem informações sobre os pes-quisadores e os ambientes do laboratório do grupo de pesquisas GREat da Universidade Federaldo Ceará e do Centro de Informática da Universidade Federal de Pernambuco, respectivamente.

Estes aplicativos utilizam informações contextuais, como a localização, o perfil e aspreferências do usuário visitante. Assim como as requisições desencadeadas por este e ascaracterísticas (features) do dispositivo móvel para adaptar seu próprio comportamento. Partedas características do produto que variam em tempo de execução e os core assets da SPL estãopresentes nos dispositivos móveis, enquanto outras características que variam em tempo deexecução são ligadas ao produto a partir do acesso a serviços Web.

Dentre os objetivos do projeto Ubstructure está a criação de um mecanismo de adaptaçãoautomático que em tempo de execução selecione características da aplicação. Estas estarãohabilitadas para o usuário adaptá-las segundo o contexto no qual a aplicação está inserida. Onde,o funcionamento deste mecanismo pode variar desde baseado em regras de condição ou atémesmo ser modelado como um problema de otimização.

O contexto varia entre tipos de aplicações e seus respectivos domínios. Na MobiLineconsidera-se contexto tanto o ambiente físico no qual o dispositivo móvel está inserido, quantoas informações a respeito do estado do próprio dispositivo. Estas informações são coletadas apartir dos sensores do dispositivo, sendo a localização geográfica adquirida a partir da câmera oudo sensor de sinais NFC.

O estudo de OLIVEIRA MARTINS (2013) abordou a problemática do mecanismo dereconfiguração e a descoberta de serviços criando uma ferramenta chamada DYMOS framework.Este atua sempre que uma reconfiguração que ocorre no lado cliente exigindo reconfiguraçõesnos serviços no lado servidor. No entanto, este estudo seleciona os serviços no lado servidor deforma arbitraria, sem realizar nenhuma análise nos serviços que irão compor a DSPL. O que étratado no trabalho como fora de escopo e possível trabalho futuro.

Por outro lado, como apresentado em mais detalhes na Seção 2, a literatura de DSPLnão apresenta uma forma de selecionar as características que irão compor a linha de produto

1Projeto apoiado pelo CNPq (MCT / CNPq 14/2011 - Universal), sob o processo de número 481417/2011-7.

1.2. PROBLEMÁTICA E OBJETIVO 15

em tempo de execução com base nas preferências do usuário. Esta análise não aborda apenas aconformidade funcional como também a qualidade das característica apresentadas.

1.2 Problemática e Objetivo

A Figura 1.1 representa o cenário hipotético que exemplifica a problemática abordadaneste estudo. Como relatado anteriormente os produtos da MobiLine requisitam em tempo deexecução as informações contextuais (coletadas por sensores ou do status do próprio dispositivo)e recebem estímulos do usuário que junto com essas informações definem quais adaptações emtempo de execução devem ocorrer.

Figura 1.1: Cenário do Problema

Quando uma adaptação ocorre no dispositivo móvel duas situações podem ser desenca-deadas: a) a requisição a um web service presente e ativo no lado servidor; ou b) a requisição aum web service ausente ou inativo no lado servidor.

Para a situação a), ao encontrar o serviço os produtos da MobiLine o consomem comohá de se esperar. No tocante a situação b), a partir da criação do DYMOS, quando o serviçonão é encontrado, o framework é responsável por procurar um serviço para substituir o que estáindisponível de acordo com uma ordem de prioridade. Caso nenhum dos serviços organizados porprioridade esteja disponível, qualquer serviço que atenda a interface requisitada pela aplicaçãomobile é disponibilizado para consumo.

1.2. PROBLEMÁTICA E OBJETIVO 16

No entanto, ALFEREZ; PELECHANO (2011) argumentam que web services são execu-tados em ambientes complexos e heterogêneos e considerando este fato é apropriado que existammecanismos de adaptação de acordo com mudanças contextuais que efetuem reconfigurações queaumentem a qualidade do serviço prestado. Enquanto que, para LIN et al. (2010), do ponto devista empresarial é fortemente desejável maximizar a qualidade de um serviço prestado levandoem consideração os diversos entendimentos de o que é qualidade do ponto de vista de diferentesclientes.

Diante disto, o objetivo geral desta dissertação é:

Propor uma abordagem de seleção em tempo de execução das características que

irão compor uma DSPL com base em uma análise de seus respectivos atributos de

qualidade

Na busca em atingir este objetivo geral foram definidos três objetivos específicos: a)Revisar a literatura a fim de identificar as maneiras pelas quais a derivação dinâmica em DSPLocorre; b) Desenvolver um método para a avaliação da qualidade e seleção dos serviços emtempo de execução; c) Avaliar a performance da abordagem proposta.

1.2.1 Métodologia

Esta dissertação é baseada na perspectiva filosófica positivista. Nesta perspectiva, asavaliações realizadas para a abordagem proposta no objetivo geral observam variáveis que terãosempre os mesmos valores em observações distintas realizadas por pesquisadores diferentes. Paraque isto seja possível todos os passos seguidos em direção aos objetivos específicos são descritose os valores das variáveis de observação disponibilizados. Para que os objetivos específicosfossem alcançados foi necessário estabelecer os métodos pelos quais este estudo seria guiado.Estes métodos foram escolhidos de acordo com a natureza de cada objetivo específico.

O objetivo específico “a)” é contemplado no Capítulo 2. Trata-se de um estudo bibliográ-fico feito com base em revisões da literatura estruturadas já publicadas. Procura-se nesta partebibliográfica do estudo apresentar os principais conceitos abordados neste estudo, bem comoestabelecer o estado da arte para a área de derivação dinâmica em DSPL.

O relato das etapas referentes ao objetivo específico “b)” está presente no Capítulo 3 e naprimeira parte do Capítulo 4. Devido a quantidade de conhecimento sistematizado a respeitode derivação dinâmica de produtos, optou-se pelo uso de métodos exploratórios como forma deatingir esse objetivo. Sendo assim, optou-se pela realização de uma análise, uma intervenção euma validação exploratória para a satisfação desse objetivo específico.

A fim de atender ao objetivo específico “c)”, descrito no Capítulo 4, optou-se por umabordagem quantitativa. Esta abordagem é expressa na forma de uma avaliação de performanceda abordagem proposta, fazendo uso da descrição estatística das variáveis de controle e dosresultados observados.

1.3. VISÃO GERAL DA SOLUÇÃO 17

1.3 Visão Geral da Solução

Para alcançar o objetivo geral desta dissertação a abordagem proposta por OLIVEIRA MAR-TINS (2013) foi ampliada passando a ser chamada de DYMOS QoS. Esta solução propostaconsiste de uma aplicação desenvolvida em linguagem JAVA e Open Service Gatway Initiative

(OSGi) que avalia individual e coletivamente os atributos de qualidade de serviço disponívelpara a reconfiguração da SPL em tempo de execução.

São levados em consideração enquanto atributos de qualidade para a seleção dos serviçosem tempo de execução: o custo da utilização de um serviço, as capacidades atuais e totaisde carga dos serviços e o tempo de resposta. Como critérios de desempate, são utilizados osatributos de qualidade de disponibilidade e confiabilidade.

A partir desta contribuição é possível modificar a situação b) apresentada na Seção 1.2 eilustrada na Figura 1.1, de modo que a seleção do serviço que substituirá o que está indisponíveldeixa de ocorrer de acordo com a prioridade arbitrada. E passa a acontecer de acordo coma qualidade dos serviços disponíveis no momento da requisição. Fica eleito o serviço queapresentar a maior pontuação fornecida pelo framework DYMOS QoS. Ainda como efeito dessacontribuição, torna-se possível um terceiro cenário onde a requisição por um serviço retornasempre um serviço ótimo para determinado nível de serviço requerido.

1.4 Escopo Negativo

Alguns tópicos que se relacionam com o objetivo desta pesquisa ou seus objetos não sãoinfluenciados e não influenciam a mesma. Sendo assim, estão fora do escopo do presente trabalhoalguns tópicos como a especificação e implementação de agentes, sejam estes de hardware ou desoftware, que responsabilizem-se pela monitoração do contexto onde os produtos da DSPL estãoinseridos.

Assume-se, neste estudo, que existem regras de contexto e derivação de produtos deter-minadas. Sendo assim, a criação de tais regras é considerada como fora do escopo abordado. Damesma maneira, não são abordadas técnicas de precificação, regras de estabelecimento de preçosou prazo de vigência para os mesmos.

Os serviços utilizados neste trabalho possuem atributos de qualidade que servem comoinsumos para a avaliação dos mesmos. No entanto, o monitoramento de quebra de acordos denível de serviço ou de qualquer garantia a respeito dos valores desses atributos de qualidadetambém são considerados como fora de escopo.

1.5 Organização da Dissertação

O restante desta dissertação está organizada em quatro capítulos. O Capítulo 2 trata dosconceitos básicos relacionados a área de SPL além de apresentar o Estado da Arte em derivação

1.5. ORGANIZAÇÃO DA DISSERTAÇÃO 18

dinâmica e explorar as deficiências desta temática de pesquisa.O Capítulo 3 trata do desenvolvimento da abordagem proposta. Este capítulo inicia com

a descrição do funcionamento do DYMOS, sobretudo no que diz respeito ao seu mecanismode descoberta de serviços. A segunda parte deste capítulo trata de apresentar as modificaçõesrealizadas no framework com a criação dos componentes que são responsáveis pela análise daqualidade dos serviços em tempo de execução.

No Capítulo 4 é demonstrada uma avaliação que valida o DYMOS QoS utilizando osprodutos da MobiLine. É apresentado ainda, uma avaliação de performance para o framework.

Por fim, o Capítulo 5 encerra esta dissertação sumarizando os passos demonstrados noscapítulos anteriores e relatando o desfecho que foi possível concluir com relação a abordagemproposta. É apresentado neste capítulo as limitações, contribuições e uma lista de trabalhosfuturos.

191919

2Revisão da Literatura

O que nos traz finalmente ao momento da verdade, em que a falha

fundamental é definitivamente expressa e a anomalia revela ser tanto o

começo quanto o fim.

—MATRIX (Diálogo entre Neo e o Arquiteto)

Serão explorados nesse capítulo os conceitos utilizados nesta dissertação. Para tanto, ocapítulo inicia com uma breve explanação a respeito dos conceitos fundamentais da ComputaçãoOrientada a Serviços (SOC). Em seguida são apresentados conceitos relacionados a abordagemSPL e então o estabelecimento do Estado da Arte em derivação dinâmica. Finaliza-se, então comuma explanação crítica a respeito da interação entre DSPL e SOC.

2.1 Computação Orientada a Serviços

Enquanto paradigma computacional, SOC utiliza serviços como elementos fundamentaispara o desenvolvimento de software estruturados em uma Arquitetura Orientada a Serviços(SOA). Na perspectiva de MENDONçA et al. (2013) este paradigma emergiu no intuito deoferecer maior eficiência à provisão de recursos computacionais utilizando componentes diversosde infraestrutura como servidores web e bancos de dados.

É de encargo da SOA determinar os meios pelos quais os serviços devem ser organiza-dos, construídos e gerenciados. SOA fundamenta-se na utilização de serviços como unidadesfundamentais, suas respectivas descrições e nas operações de publicação, descoberta, seleção evinculação (PAPAZOGLOU; GEORGAKOPOULOS, 2003).

As arquiteturas orientadas a serviços são utilizadas por proverem benefícios comoreusabilidade, flexibilidade, interoperabilidade (ERL, 2007) através dos princípios de baixoacoplamento, contrato entre serviços, descoberta de serviços e granularidade alta ou pequenaquantidade de requisições ao serviço para o desempenho de uma funcionalidade. Onde o baixoacoplamento diz respeito ao número de dependências entres os serviços e é alcançado a partir damodularização dos serviços fazendo com que sejam acessados através de contratos.

2.2. QUALIDADE DE SERVIÇOS 20

Dentro deste contexto, os clientes (serviços e aplicações que utilizam as funcionalidadesprovidas por um outro serviço) aderem aos contratos de comunicação, definidos por um oumais serviços. Estes contratos consistem de uma descrição das funcionalidades, características eformatos de dados do serviço. São utilizados, assim, normalmente formatos padronizados comocontratos a exemplo de XML, WSDL e XSD, como afirma ERL (2005).

Sendo assim, a descoberta de serviços ocorre sempre a partir da especificação descritivados mesmos (contrato), permitindo a sua localização e identificação. Ambas podem ocorrer apartir do Universal Descriptor, Discovery and Integration (UDDI) ou Uniform Resource Identifier

(URI), sendo utilizados diretamente por um cliente ou por um mecanismo de descoberta deserviço (JOSUTTIS, 2007).

A modularidade e reutilização providas pelo uso de SOC e SOA permitem que serviçossejam disponibilizados para a utilização de terceiros ou em sistemas diferentes dos sistemaspara os quais estes foram desenvolvidos. No âmbito de transações comerciais eventualmente édesejável que a qualidade do serviço (QoS) oferecido seja aferida para que sejam garantidas, porexemplo, cláusulas contratuais como a quantidade de resposta a uma determinada requisição porsegundo.

A utilização de SOC na Web manifesta-se na forma de Web services que é um tipoespecífico de serviço que é identificado por uma URI (PAPAZOGLOU; GEORGAKOPOULOS,2003). Algumas características comuns a web services que são utilizadas para a aferição desua qualidade foram elencadas por D’AMBROGIO (2006), são elas: latência, demanda, rede,controle de acesso, encriptação, disponibilidade e confiabilidade.

2.2 Qualidade de Serviços

Um serviço Web pode ter várias implementações oferecidas por diferentes provedores.Estas implementações têm a mesma funcionalidade mas podem ter diferentes valores para osseus atributos de QoS. Sendo assim, alguns critérios de qualidade podem ter melhores valoresem uma implementação do serviço e alguns piores em comparação a outras implementações(TANG; AI, 2010).

Mais precisamente, um serviço Web pode ser identificado por duas propriedades: fun-cionalidade e qualidade. Funcionalidade é o que o software pode oferecer e é tipicamenterepresentado por um conjunto de operações providas pelo serviço. Já a qualidade diz respeito a oquão bem um provedor de serviços pode fazer a entrega das funcionalidades deste (YU et al.,2010a).

O termo “qualidade” é utilizado para representar juízos de valor e por isso é um termode significado vago. No entanto, DEORA et al. (2006) argumenta que em SOC a qualidade énormalmente vista segundo as perspectivas de conformidade e reputação. Dentro da primeiraperspectiva, a qualidade é vista como um sinônimo de atendimento a especificações comotempo de reposta, custo e largura de banda. Já na perspectiva de qualidade enquanto reputação,

2.3. LINHAS DE PRODUTO DE SOFTWARE 21

trabalha-se com a percepção de um usuário a respeito de um serviço em geral.PAPAKOS; CAPRA; ROSENBLUM (2010) defendem que em aplicações cliente em

dispositivos móveis sofrem com mudanças de contexto que podem incluir mudanças nos recursosdo dispositivo, em variáveis ambientais e nas preferências do usuário em tempo de execução.Sendo assim, o nível de QoS exigido inicialmente pelo ambiente podem não estar de acordo comas capacidades do dispositivo em seu contexto atual resultando em um desperdício de recursos eum alto custo monetário.

Existe um conjunto de técnicas utilizadas para a seleção e composição de serviços emtempo de execução. Dentre elas a utilização de algorítimos genéticos como utilizado por TANG;AI (2010). Em seus estudos, YU; LIN (2004, 2005) utilizaram uma abordagem combinatória deseleção de serviços para uma composição de serviços estruturados como um pipeline simples euma abordagem utilizando Grafos Acíclicos Direcionados (DAG) onde cada caminho possívelno gráfico retorna uma seleção e composição de servições diferentes.

Em abordagens combinatórias, algorítimos de busca exaustiva ou de solução para oproblema da mochila do alpinista (MKCP) podem ser utilizados. O primeiro caso consiste emcomparar as seleções ou composições possíveis com base nos critérios de qualidade escolhidos.Este algorítimo sempre retorna a solução ótima apesar de apresentar um grande consumo detempo e memória. Já o seleciona os serviços a serem compostos pesos que são retirados decaracterísticas não funcionais dos serviços.

Nas abordagens DAG algorítimos que buscam por todas os caminhos possíveis de seleçãode serviços para composição no grafo para que posteriormente seja definido a partir de umaanálise combinatória quais serviços melhor atendem a uma determinada restrição de qualidade.Outro algorítimo que pode ser utilizado é o Constrained Bellman-Ford (CBF) que é um algorítimode busca em largura que seleciona um nó a cada nível do grafo de acordo com a restrição dequalidade imposta. Pode ser utilizado ainda o algorítimo Constrained Shortest Path (CSP) quefunciona basicamente como o CBF, apesar de ordenar topologicamente os nós do grafo noprimeiro passo de sua execução.

Existem ainda abordagens de seleção de serviços criadas para cenários específicos comoé o caso do estudo do PAPAKOS; CAPRA; ROSENBLUM (2010), que criou um mecanismopara descoberta de serviços em nuvem para dispositivos móveis. Ou ainda um framework emduas fases para seleção baseada em qualidade de serviços que utiliza uma linguagem de consultapara localizar, retornar e montar planos de execução desses serviços (YU et al., 2010b).

2.3 Linhas de Produto de Software

Custo, reusabilidade e time-to-marketing são aspectos que preocupam os fabricantes desoftware. Por outro lado, a gerência de configuração de software torna-se cada vez mais complexaà medida que aumentam as possibilidades de combinações de características (features) de umsoftware. O paradigma de Linhas de Produto de Software (SPL) vai de encontro a este problema


criando produtos de software a partir de um conjunto comum de características. O gerenciamentoda configuração ocorre com as variabilidades e as comonalidades entre os membros da linha deproduto de software.

Segundo o Software Engineering Institute (SEI)1, SPL é um conjunto de sistemas inten-sivos de software que compartilham um conjunto comum e gerenciado de funcionalidades quesatisfazem necessidades específicas de um segmento ou missão particular de mercado e que sãodesenvolvidos a partir de um conjunto comum de recursos principais (Core Assets) de maneiraprescrita. Os benefícios em adotar o paradigma SPL depende do contexto no qual ele é aplicado.Alguns dos benefícios mais comuns são a redução do custo e do time-to-marketing promovidopela reutilização dos core assets dos softwares da linha.

Não obstante, variações dinâmicas em requisitos dos usuários e no ambiente no qualo software está inserido em tempo de execução tornam-se cada vez mais frequentes, por issoexiste uma demanda crescente por sistemas capazes de se adaptar automaticamente ao encontraressas condições. Em 2008, HALLSTEINSEN et al. (2008) publicou um estudo que descreveuo conceito de Dynamic Software Product Lines (DSPL). Estas linhas de produto diferem dasoutras por não gerenciarem a variabilidade durante a fase de design do software, mas em tempode execução.

Uma DSPL representa normalmente cinco características: a) variabilidade dinâmica,b) a ligação (binding)de elementos da DSPL muda durante o ciclo de vida da aplicação, c)pontos de variação mudam em tempo de execução, d) mudanças inesperadas no contexto e e) sãodesenvolvidas para um contexto ou ambiente específico no lugar de um segmento de mercado(HALLSTEINSEN et al., 2008).

Opcionalmente, DSPLs podem ser sensíveis ao contexto a sua volta (PARRA; BLANC;DUCHIEN, 2009; ALI; CHITCHYAN; GIORGINI, 2009; ALFEREZ; PELECHANO, 2011),possuir propriedades autonômicas ou de auto-adaptação (ABBAS; ANDERSSON; WEYNS,2011; CETINA; FONS; PELECHANO, 2008; ABBAS, 2011) e tomada automática de decisão.Estas características compõem um desafio para um modelo de desenvolvimento de SPLs quegerencia a variabilidade fora da fase de design.

2.3.1 O Estado da Arte em Derivação Dinâmica

Na perspectiva de MORESI (2003), o Estado da Arte apresenta a partir da literaturajá publicada o que já se sabe sobre determinado tema, quais as lacunas existentes e onde seencontram os principais entraves teóricos ou metodológicos. No que diz respeito a derivaçãodinâmica, vários pesquisadores têm desenvolvido uma quantidade significante de estudos parainvestigar aspectos relacionados a reconfiguração de SPL em tempo de execução, que é tratadacomo parte da derivação do produto chamada derivação dinâmica (PARRA; BLANC; DUCHIEN,2009).

1http://www.sei.cmu.edu/productlines/


Apesar do termo DSPL ter sido detalhadamente descrito em HALLSTEINSEN et al.(2008), pelo menos quatro estudos abordaram a temática e trataram da derivação dinâmicaanteriormente (KIM; JEONG; PARK, 2005; GOMAA; SALEH, 2006; HALLSTEINSEN et al.,2006; LEE, 2006). A partir da utilização dos mesmos critérios descritos por SILVA et al. (2013)pode-se observar uma crescente, apesar de pequena, produção bibliográfica no decorrer dos anosabordando a temática de derivação dinâmica (Figura 2.1).

No entanto, BUREGIO; ALMEIDA; MEIRA (2010) afirma que para a área de DSPLa maior parte das contribuições estão relacionadas a proposição de soluções, em sua maioriaconcentradas no desenvolvimento de metodologias. Ao mesmo tempo que não são comuns deserem encontrados relatos de experiência e pesquisas que possam avaliar a aplicabilidade dosconceitos de DSPL no contexto industrial. Estas constatações são reforçadas no estudo de SILVAet al. (2013), no que tange aos estudos a respeito de derivação dinâmica levando à conclusão deque o campo de estudo está ainda em formação.

Figura 2.1: Distribuição Anual de Estudos a Respeito de Derivação Dinâmica

A seguir são apresentados estudos publicados entre os anos de 2005 e 2013 que apresenta-ram contribuições relevantes para a área de derivação dinâmica em DSPL em ordem cronológica.O objetivo desta apresentação é expressar a evolução das técnicas de derivação dinâmica aolongo do tempo.

2.3.1.1 Estudos em Derivação Dinâmica

KIM; JEONG; PARK (2005) desenvolveram, para um contexto de uma DSPL de jogospara dispositivos móveis, um framework de reconfiguração arquitetural em tempo de execuçãoque gerencia a reconfiguração dinâmica para ambientes embarcados. A solução proposta faz usode uma linguagem específica de domínio para descrever o sistema de maneira estática e umalinguagem para descrever modelos arquiteturais que especificam as regras que informam quaiscomponentes devem ser adicionados ou removidos da arquitetura do produto.

A abordagem “Dynamic Client Application Customization” (DAC) criada por GOMAA;SALEH (2006) é baseada na customização dos objetos da interface com o usuário em tempode execução baseada em features selecionadas e valores de variáveis parametrizadas. Estaabordagem consiste de uma arquitetura de SPL customizável baseada no padrão arquitetural


cliente/servidor, onde a aplicação cliente contém apenas objetos de interface com o usuário e umobjeto customizador. A aplicação do servidor contém todos os web services responsáveis porprover as funcionalidades do sistema e o suporte ao banco de dados.

Na DAC, a seleção de features direciona a customização dinâmica da arquitetura e aimplementação da linha de produto para a derivação da aplicação. Durante a modelagem dalinha de produto as features e suas dependências são descritas em um modelo (feature model).Durante a engenharia da aplicação, features são selecionadas pelo engenheiro de aplicação eutilizadas para customizar dinamicamente a arquitetura e implementação da aplicação.

HALLSTEINSEN et al. (2006) criaram a abordagem MADAM para construção de siste-mas adaptativos. O foco da abordagem está em sistemas distribuídos acessados por dispositivosmóveis onde a derivação dinâmica ocorre a partir de uma arquitetura de referência. A plataformaarquitetural que suporta a abordagem pode ser vista na Figura 2.2. O núcleo dessa arquitetura(Core) é composto por um middleware entre os componentes e a plataforma, e oferece serviçospara o gerenciamento de componentes, instâncias e recursos. O Context Manager é responsávelpor monitorar um conjunto de contextos relevantes no ambiente do sistema enviando e reunindoinformações que são utilizadas pelo Adaptation manager.

O Adaptation manager é responsável por avaliar o impacto das mudanças no contextosobre a aplicação e determinar quando uma adaptação deve ser efetuada, selecionando as va-riantes que melhor atendem as novas necessidades impostas pelo contexto. O configurador(Configurator) é responsável por realizar a configuração inicial da aplicação e as reconfigura-ções, observando quais variantes devem ser instanciadas e desativadas para alcançar o estadodeterminado pelo Adaptation manager.

Figura 2.2: MADAM Platform Architecture (HALLSTEINSEN et al., 2006)

Em uma abordagem orientada a features e sistemática de desenvolver core assets re-configuráveis dinamicamente, LEE (2006) desenvolvera um reconfigurador que acumula asfunções de monitorar e gerenciar a configuração de um produto em tempo de execução. Esteautor acredita que a derivação dinâmica pode ser realizada agrupando features em unidades de


bind e utilizando um reconfigurador que considera contextos (quando configurar), estratégias dereconfiguração (como reconfigurar) e ações de reconfiguração (o que reconfigurar).

Baseado no paradigma SPL CETINA; FONS; PELECHANO (2008) criou um métodopara desenvolver sistemas pervasivos dinamicamente adaptáveis. Neste estudo afirma-se que areconfiguração autônoma do produto pode ser realizada estendendo a abordagem do paradigmaSPL reutilizando a análise de escopo, características em comum e variabilidades. A reutilizaçãodesta análise é utilizada como entrada para um reconfigurador que em tempo de execução utilizao conhecimento contido nesta para realizar a derivação dinâmica.

WOLFINGER et al. (2008) em uma abordagem que utiliza plugins como features nodomínio de sistemas ERP2, faz uso de variáveis parametrizadas para adaptar o produto em tempode execução. O primeiro artefato a ser gerado para a utilização dessa abordagem é o conjunto decomponentes em forma de plugin. Então uma ferramenta chamada DecisionKing é empregadapara gerar um modelo de variabilidades e outra ferramenta de nome ProjectKing permite quesejam criados cenários para configurações específicas modelo de variabilidades. Assim, umguia de configuração processa os modelos de variabilidades com seus respectivos cenários eapresenta as possíveis decisões a serem tomadas em uma interface amigável para o usuário dosoftware. Por fim, um mecanismo de descoberta na plataforma de plugins permite ligar e desligaros componentes baseando-se nas decisões do usuário.

PUKALL; SIEGMUND; CAZZOLA (2009) desenvolveu a metodologia chamada “Feature-oriented Runtime Adaptation” que permite a atualização de programas em tempo de execuçãoatravés da evolução dos recursos de uma SPL de forma dinâmica. Toda a metodologia é baseadaem substituições de classes em Java utilizando “Java HotSwap” e reimplementação do corpo demétodos.

O relacionamento entre SPL e computação orientada a serviço foi claramente utilizadopor YU; LALANDA; BOURRET (2010) ao apresentarem uma metodologia para a construçãode aplicações baseadas em serviços para ambientes heterogêneos e dinâmicos. A metodologiaé dividida nas fases de engenharia de domínio, engenharia de aplicação e tempo de execução.É proposto um processo de desenvolvimento centrado em domínios e orientado a arquiteturainspirada em SPL. É na fase de tempo de execução que, através de composição de serviçosdinâmica, acontece a reconfiguração.

Foi provado ser possível realizar uma derivação dinâmica a partir do compilador Java noestudo de SUNKLE; PUKALL (2010). Este estudo utilizou o FeatureJ, que é uma abordagem deimplementação de SPL, com uma representação de features e variabilidades como se fossemtipos de uma linguagem de programação. Esta representação é utilizada como entrada para aderivação do produto em tempo de compilação e execução. Já GüNTHER; SUNKLE (2010)apresentaram uma maneira de modelar, implementar features, realizar a composição dinâmicadestas em tempo de execução e modificar a SPL e suas variantes utilizando a linguagem deprogramação Ruby.

2Enterprise Resource Planning


No âmbito de sistemas de cuidados com a saúde, CARVALHO; LOQUES; MURTA(2010) desenvolveu uma abordagem para gerenciamento dinâmico de variabilidades baseada emcontratos arquiteturais. Estes contratos, especificados na linguagem CBabel, são instanciados emtempo de execução de acordo com as variações no contexto.

LEE; KOTONYA (2010) é uma continuação do estudo realizado pelo mesmo autor(LEE,2006) onde é descrita uma possível solução para a derivação dinâmica que relaciona uma análiseorientada a features e um framework orientado e sensível a qualidade dos serviços de um SPL.Os autores acreditam que features podem ser mapeadas em serviços.

ALFEREZ; PELECHANO (2011) desenvolveu um método para projetar e implementarweb services autônomos e sensíveis ao contexto em SPL. Os autores argumentam que se web

services forem caracterizados por features, então a ativação e desativação de features em tempode execução pode guiar a reconfiguração autonômica de composição de serviços a depender demudanças no contexto. Neste caso, os produtos são uma composição de serviços. Para que sejapossível uma composição de serviços, os autores sugerem a criação de um modelo de composiçãofeito a partir de um diagrama UML de atividades. Este modelo ilustra os web services e os fluxosde sequência entre eles que estabelece a ordem na qual cada web services deve ser ativado.

GOMAA; HASHIMOTO (2011) descreve uma arquitetura para a adaptação dinâmica deprodutos de uma SPL baseado em SOA. Esta arquitetura contém um serviço de monitoramentoque verifica continuamente o estado do sistema em execução e o encaminha para o serviçode calibragem, que percebendo uma situação no contexto que necessite de uma ação enviauma requisição ao dispositivo de seleção dinâmica de features. Este dispositivo determina seexiste a necessidade de mudanças na configuração que está sendo executada. Ele determinadinamicamente as modificações necessárias para o modelo de features da aplicação e envia anova seleção de features para o serviço de gerenciamento de mudança. Fica a cargo do serviço degerenciamento de mudanças determinar a diferença entre a nova seleção de features e a original,determinar os componentes e conectores que precisar sem adicionados ou removidos e geraruma sequência de comandos de adaptação que correspondem as mudanças que precisam serefetuadas.

Em (PARRA et al., 2011), os autores propuseram uma abordagem unificada com oobjetivo de dar suporte a todo o ciclo de desenvolvimento de software. A abordagem consideraque a criação do produto inicial é realizada através de adaptações no projeto. Uma vez criadoe entregue o produto pode ser objeto de adaptações dinâmicas. A abordagem, que utilizaadaptação a partir de aspectos, é feita em duas entidades principais. A primeira é um metamodelounificado de aspectos utilizados para definir tanto adaptações em tempo de projeto quanto emtempo de execução.A segunda é uma plataforma que realiza de modo transparente as adaptaçõesexpressadas no metamodelo unificado.

Esses modelos ligam cada feature em particular com um conjunto de componentesopcionais que podem fazer parte do produto. Cada modelo contém as informações necessáriaspara a composição, incluindo: a) as localizações modificadas pela feature, b) os elementos a


serem adicionados e c) o conjunto de modificações a serem realizadas para que esses elementospossa ser adicionados.

ROSENMüLLER et al. (2011) apresentaram em seu estudo transformações de códigopara integrar o bind estático e dinâmico de features em SPLs a nível de modelagem e implemen-tação. Esta abordagem permite que desenvolvedores mudem flexivelmente o tempo de bind decada feature usando o mesmo código como base. As unidades de bind são geradas estaticamentepara reduzir a sobrecarga do processo de derivação dinâmica. Os autores garantem a composiçãosegura do bind dinâmico utilizando regras de composição descritas em um modelo de features

que contém as regras de reconfiguração que representam as transformações de código que sãoutilizadas para a criação das unidades de bind dinâmico.

SHEN et al. (2011) propuseram um método orientado a features para suportar recon-figuração de variabilidades em tempo de execução. Neste estudo é introduzido o conceito demodelo de funções, que é um nível intermediário entre as variantes das features e suas respecti-vas implementações. Durante o processo de adaptação a reconfiguração da feature variante émapeado no modelo de funções. Neste contexto as funções relacionadas com as variabilidadespodem ser adaptadas para estar disponíveis ou indisponíveis quando a reconfiguração em tempode execução é realizada. Como as funções não podem ser removidas da aplicação em execução,o gerenciamento dessas interações com as funções mapeadas apoia a reconfiguração.

DAMIANI; PADOVANI; SCHAEFER (2012) apresentam para este campo de estudo osconceitos de Delta Oriented Programing (DOP). Um produto em particular em uma DOP SPL égerado aplicando-se as modificações contidas em módulos delta adequados para um núcleo desistema, que podem sempre ser assumido como vazio. O gráfico de reconfiguração define quaisconfigurações o sistema pode adaptar em tempo de execução e descreve como objetos alocadosna pilha precisam ser realocados.

O estudo de BARESI; MILANO (2012) demonstra uma maneira de enriquecer as com-posições da Business Process Execution Language (BPEL) com o gerenciamento dinâmico devarabilidades. A solução proposta utiliza a Common Variability Language (CVL) para aumentaros processos BPEL com variabilidades, que torna possível a criação de DSPLs e uma versãodinâmica da BPEL para gerenciar e executá-las.

Em 2013, dois estudos a respeito da derivação dinâmica foram concluídos pelo “AdvancedSystem and Software Engineering Research Technologies Lab”(AssertLabs): no primeiro (SILVAet al., 2013), dentre outras coisas, pode-se verificar que no contexto de DSPLs orientadas aserviço existem algumas abordagens para a reconfiguração desses serviços em tempo de execuçãocom base em atributos de qualidade. No entanto, nenhuma dessas abordagens utiliza acordos denível de serviços ou demonstra evidências de que podem ser reutilizadas em DSPLs de domíniosdistintos.

O segundo estudo foi uma dissertação de mestrado (OLIVEIRA MARTINS, 2013), ondefoi desenvolvido o DYMOS framework com o propósito de gerenciar variabilidades dinâmicasem SPL orientadas a serviços e sensíveis ao contexto. Este framework possibilita que serviços

2.4. A INTERAÇÃO ENTRE SOC E DSPL 28

sejam adicionados ou removidos da configuração do produto em tempo de execução por meio demecanismos de auto-implantação, de modo que o funcionamento do sistema não seja afetadoe que tais modificações sejam aplicadas e reconhecidas imediatamente. Possui também ummecanismo de descoberta de serviços, que provê uma abstração entre o cliente e o serviço,permitindo efetuar orquestração de serviços e agregar critérios para a seleção do serviço maisadequados, de acordo com uma requisição.

2.4 A Interação entre SOC e DSPL

Pelo fato de SOC e SPL serem paradigmas utilizados com certa frequência pela comuni-dade de reuso de software não é difícil encontrar na literatura estudos bem sucedidos que tratamserviços como features, onde a determinação de quais serviços vão compor o produto é feitaatravés do modelo de features selecionado para cada produto a ser derivado. No entanto, estemapeamento estático de serviços, não atende aos requisitos de dinamicidade de uma DSPL.

É notório que SOA segue um abordagem de reuso e composição de serviços enquantoSPL, apesar de ter como benefício a reutilização, corresponde a uma abordagem de construçãoe decomposição (PARRA; BLANC; DUCHIEN, 2009). Porém as características antagônicasdesses paradigmas (composição e decomposição) não são conflitantes já que a composição deserviços em uma SPL tradicional ocorre em um momento pré-derivação e a decomposição ocorreno momento da derivação do produto.

Desta forma, DSPLs tradicionais podem também não apresentar dificuldades quanto aeste antagonismo. Não obstante, certamente este problema afetará uma DSPL orientada a serviçoque precisa decidir com base em alguma análise (Ex.: prioridade, resposta ao contexto e QoS)quais serviços devem ser plugados em tempo de execução. Visto que derivação (decomposição)e composição estão ocorrendo no mesmo momento.

Exemplos de como essa questão é tratada podem ser vistos, por exemplo, no estudorealizado por YU; LALANDA; BOURRET (2010), a DSPL orientada a serviços faz a análisede quais serviços compõem o produto unicamente verificando a disponibilidade dos serviços.Adicionalmente, o estudo de LEE (2006) apresenta uma DSPL orientada a serviços onde asfeatures são mapeadas em serviços. Esta DSPL realiza uma análise e um planejamento em tempode execução baseados em mudanças contextuais para definir quais features, e consequentemente,quais serviços devem compor o produto.

Em um estudo de cunho exploratório posterior (LEE; KOTONYA, 2010) esta abordagemé modificada fazendo com que a análise em tempo de execução seja feita com base em acordosde nível de serviço impostos pela linha de produto. Onde, assim como nos estudos de ALFEREZ;PELECHANO (2011) e GOMAA; HASHIMOTO (2011), sempre que ocorre uma quebra noacordo de nível de serviço, o framework procura por outro serviço que satisfaça as condiçõesdesejadas. Não foram expressas no estudo detalhes sobre quais seriam essas condições (atributosde QoS) ou como a negociação é feita.

2.5. CONCLUSÕES 29

2.5 Conclusões

Este capítulo explanou os conceitos relacionados a SOC, SPL e o estabelecimento doEstado da Arte a respeito da derivação dinâmica e sua interação com SOC. A partir disto,conclui-se que: é ausente na literatura estudos que atendam ao cenário motivacional descrito naSeção 1.1, ou seja, que definam os serviços que vão compor a DSPL orientada a serviço combase em uma análise de atributos de QoS realizada a cada requisição do usuário.

O próximo capítulo apresenta a construção de uma abordagem ferramental para trataresta lacuna. A abordagem baseia-se na extensão do framework DYMOS, acrescendo-lhe acapacidade de avaliar e selecionar serviços com base em atributos de qualidade.

303030

3DYMOS QoS

Esse caminho não há outro

Que por você faça

—SKANK (Acima do Sol)

Estudos exploratórios são realizados geralmente em áreas onde há pouco conhecimentoacumulado e sistematizado, como é o caso da área de derivação dinâmica em DSPL relatadono Seção 2. Este tipo de estudo também possui uma natureza de sondagem e não comportahipóteses que todavia podem surgir no final da pesquisa (MORESI, 2003).

Este capítulo apresenta uma análise e intervenção exploratória realizadas no DYMOS,que é um mecanismo de reconfiguração e descoberta de serviços apresentado e desenvolvido porOLIVEIRA MARTINS (2013). Cada uma das fases desse estudo exploratório são apresentadasa seguir.

Vale ressaltar que o framework DYMOS trabalha com features em dois níveis de abstraçãodistintos. No primeiro nível estas features são compostas de uma chamada a um serviço no ladocliente da aplicação e um contrato existe no lado servidor. No segundo nível de abstração asfeatures são todas alternativas e implementadas como serviços Web.

Portanto, a fim de evitar mal entendidos, as features de primeiro nível serão tratadas poreste nome, enquanto as do segundo nível serão tratadas como serviços ou serviços Web. Aindaassim, o framework possui um serviço Web chamado “ApplicationService” que assim como osoutros elementos da arquitetura exibida na Seção 3.1 será tratado apenas como componente.

3.1 Análise Exploratória

O framework DYMOS está estruturado como apresentado na Figura 3.1. Essa arquiteturaapresenta um serviço Web chamado “ApplicationService”, o componente “ServiceContext”, ocontêiner OSGi e três elementos descritores: o “ServiceDescriptor” que descreve o que pode serplugado em tempo de execução ao produto da SPL, o “VariabilityDescriptor” que descreve ospontos de variação e, finalmente, o “WSDescriptor” que descreve o WSDL de cada serviço Web.

3.1. ANÁLISE EXPLORATÓRIA 31

Figura 3.1: DYMOS - Diagrama de Pacotes (OLIVEIRA MARTINS, 2013)

O “ServiceDescriptor” utiliza um arquivo XML como o apresentado no trecho de código3.1 para descrever os serviços. Este XML contém uma lista de campos estruturados para cadaserviço Web como um campo “Id” fazendo o papel de identificador exclusivo, os campos “servi-ceSpec” e “serviceImpl” que contém os valores que identificam a interface e uma implementaçãopara o serviço. Cada descrição de serviço tem, opcionalmente, uma lista de serviços alternativosque possuem uma referência para outro serviço Web.

Listing 3.1: XML de Serviços do DYMOS

<?xml version="1.0"?>

<services>

...

<service id="imageService"

service-impl="com.assertLab.imageServiceImpl">

<service-spec>com.assertLab.imageService</service-spec>

<alternative-service ref="imageService1" priority="1" />

</service>

<service id="imageService1"

service-impl="com.assertLab.imageService1">

<service-spec>com.assertLab.imageService</service-spec>

</service>

...

</services>

</variabilities>

A estrutura de metadados de variabilidade utilizada pelo “VariabilityDescriptor”, apre-sentado no trecho de código 3.2, define uma lista de variabilidades com uma identificação (ID)do atributo “id”, um nome através do atributo “name” e um conjunto de variantes. Desta forma,uma variante consiste em um ID e um nome de um conjunto de referências a serviços. Este


conjunto de referências é responsável por manter os serviços ativos quando a variação estiverativada.

Listing 3.2: XML de Serviços do DYMOS


<variabilities>

<variability id="accessMode">

<variant id="infraredMode">

<service-ref ref="hiService" />

</variant>

</variability>

<variability>

<variant id="batteryHalfLife">

<service-ref ref="imageService" />

</variant>

</variability>

</variabilities>

O “WSDescriptor” é usado para operações de descoberta de serviços e sua principalfunção, de acordo com um determinado serviço disponível, é descrever os atributos que nãosão descritos pelo “ServiceDescriptor”. E que são específicos para cada implementação de umserviço como “ServiceName”, “PortType” ou “Target Namespace”. Assim, “WSDescriptor”permite maior flexibilidade ao framework, acrescentando características dinâmicas e levementeacopladas.

O componente “ServiceContext” faz uso de todos os componentes descritores. A utiliza-ção destes componentes permite ao “ServiceContext” obter todas as informações descritas naforma de objetos Java, auxiliando-o no gerenciamento de variabilidade e serviços descritos. Estagestão utiliza as informações sobre a variabilidade e serviços para manipular o contêiner OSGi.

O componente ApplicationService foi implementado para funcionar como uma fachada,criando um isolamento entre o cliente e os outros componentes da estrutura. Assim, reduziu-se onúmero de objetos que os clientes necessitam lidar. O objetivo principal do componente é exporoperações, permitindo, assim, a descoberta de serviço e a gestão de variabilidade.

3.1.1 Operações do DYMOS

O “ServiceContext” é o componente responsável pelas principais operações do DYMOS:reconfiguração de variabilidades, descoberta de serviços e “ContextHotBuild”. A reconfiguraçãode variabilidades ocorre em resposta a uma variação no contexto no lado cliente da aplicaçãoque resulta em uma reconfiguração. Em seguida, o DYMOS a partir da sua operação dereconfiguração adapta o contexto dos serviços (lado servidor) para atender a necessidade dareconfiguração no lado cliente. A sequência desta operação pode ser visualizada na Figura 3.3.


Figura 3.2: DYMOS - Diagrama de Sequência - Reconfiguração de Serviços(OLIVEIRA MARTINS, 2013)

A operação de descoberta de serviços utiliza como critério de seleção de serviçosWeb a prioridade descrita para cada serviço alternativo no XML de serviços utilizado pelocomponente “ServiceDescriptor” e a disponibilidade do mesmo no contêiner OSGi. A seleçãoé direcionada pelos atributos “service-impl”, “service-spec” e “priority”, que é definido no“alternative-service”.

Esta operação inicia-se no lado cliente da SPL a partir da invocação do método “getEnd-Point” do “ApplicationService” (ver Figura 3.2). O método em questão recebe como parâmetroo ID do serviço desejado que é passado para o “SeviceContext”, onde a requisição é tratada combase nas informações passadas pelo “ServiceDescriptor”. Logo, o ID passado como parâmetrodeve ser o ID de um serviço descrito no XML de serviços.

É de responsabilidade do “ServiceContext” enviar requisição ao contêiner OSGi uti-lizando como base os atributos “service-ref”, “service-impl” e “alternative-service” com afinalidade de encontrar um serviço que seja satisfatório para a invocação feita ao método “ge-tEndPoint”. O processo de seleção do serviço Web ocorre em três fases:

� busca por um serviço Web que satisfaça a especificação e implementação definidanos atributo “service-spec” e o “service-Impl”;

� busca por um serviço alternativo, levando em consideração a prioridade definida noatributo “priority”;

� busca por qualquer serviço presente no contêiner OSGi que satisfaça a especificação

3.2. INTERVENÇÃO EXPLORATÓRIA 34

desejada.

A execução das fases de seleção, apresentadas anteriormente, é sequencial. No entantosó acontecerá a execução de uma fase subsequente caso a fase anterior seja incapaz de encontrarum serviço adequado. Após a seleção do serviço Web, o “ServiceContext” interage com ocomponente WSDescriptor passando como parâmetro o endereço onde o serviço selecionadoencontra-se e recebendo como resposta o end point, o name space e o nome do serviço. Estesdados são retornados para o lado cliente da DSPL.

Figura 3.3: DYMOS - Diagrama de Sequência - Descoberta de Serviços(OLIVEIRA MARTINS, 2013)

Outra operação do DYMOS é a “ContextHotBuild”. Esta é a operação responsável pelasoperações de bind em tempo de execução. Todos os serviços Web que são tratados pela DSPLcomo features de segundo nível estão empacotados em bundles OSGi, tornando possível queeles sejam ativados e desativados, plugados e desplugados da DSPL sem a necessidade de queo software seja recompilado. Sendo assim, fica sob a responsabilidade do componente “OSGiContainer” gerenciar a operação de “ContextHotBuild” a partir do gerenciamento do ciclo devida dos bundles.

3.2 Intervenção Exploratória

Visto que, na perspectiva de KHEZRIAN et al. (2010), por um lado a descoberta deserviços permite que a relação entre cliente e serviços não seja tratada de forma fixa ou acoplada,


com vistas à seleção de um serviço mais adequado baseado em critérios estabelecidos. Por outrolado, a descoberta de serviços no DYMOS apesar de efetiva pode não ser a ideal ao considerarapenas um critério para a seleção dos serviços.

É importante pontuar que a utilização da prioridade como critério único além de limitara descoberta de serviços a torna arbitrária e delega ao engenheiro de software a responsabilidadede determinar qual serviço deve ser plugado ao produto em tempo de execução na fase de design

da aplicação. Este cenário pode caracterizar uma perda de dinamicidade para a DSPL. Combase nesta observação e no intuito de atingir o objetivo de propor uma abordagem de seleção emtempo de execução das características que irão compor uma DSPL e com base em uma análise deseus respectivos atributos de qualidade, propõe-se estender o DYMOS, passando a denomina-lode DYMOS QoS.

A proposta de extensão consiste em modificar a situação b) apresentada na Seção 1.2.Nesta situação a seleção de serviço para substituir o serviço indisponível ocorre de acordo coma prioridade arbitrada. Propõe-se que a seleção de serviços ocorra de acordo com a qualidadedos serviços disponíveis no lado servidor no momento em que a solicitação é realizada no ladocliente.

Assim, será selecionado o serviço que tiver a maior pontuação fornecida pelo DYMOSQoS. Esta nova abordagem torna possível que uma terceira situação ocorra, onde sempre querealizada uma requisição a um serviço no lado cliente, o serviço retornado será sempre o quetiver a melhor avaliação dos atributos de qualidade no nível de serviço exigido.

Para tanto, dois novos componentes foram adicionados a arquitetura do DYMOS: o“ServiceLevelProvider” e o “Broker”, como pode ser visualizado na Figura 3.4. O primeiroarmazena informações contextuais sobre os serviços Web de forma estruturada em um arquivoXML e atualiza essas informações de acordo com as mudanças que ocorrem no contexto. Ocomponente “Broker” é responsável por analisar os atributos de qualidade para cada serviço emtempo de execução durante a descoberta de serviços.

A fim de que seja possível ao “Broker” realizar essa análise, o componente “ServiceLe-velProvider” armazena em um XML alguns atributos de qualidade, tais como nível de serviço,capacidade máxima, a capacidade atual, tempo de resposta e custo. A análise do “Broker” calculaa utilidade (YU; LIN, 2005) de cada serviço no nível de serviço escolhido e envia esta informaçãopara o componente “ServiceContext”, que continua sendo o principal responsável pelo processode descoberta de serviços.

Esta intervenção requer uma modificação no componente “ServiceContext” de modo quedurante a execução do método “findAlternativeService” a prioridade descrita no XML de serviçosdeve ser desconsiderada, os atributos de qualidade de cada serviço devem ser recuperadas e autilidade de cada serviço deve ser calculada.

A Figura 3.5 ilustra como essa modificação afeta a sequência da execução do processode descoberta de serviços. Ao perceber que a implementação do serviço requisitado não estápresente no contêiner OSGi, o “ServiceContext” requisita ao “ServiceLevelProvider” a lista dos


Figura 3.4: DYMOS QoS - Diagrama de Pacotes

Figura 3.5: DYMOS QoS - Diagrama de Sequência - Descoberta de Serviços

serviços alternativos com seus respectivos valores para os atributos de qualidade estruturadosdentro de objetos “AlternativeServiceQoS”.


Os atributos de qualidade têm valores distintos para cada serviço em cada nível deserviço, como é apresentado no Código 3.3 que representa o XML de atributos de qualidadeutilizado pelo “ServiceLevelProvider”. Os atributos de qualidade dos serviços utilizados nessaabordagem são: custo, capacidade máxima e atual, nível, tempo de resposta, confiabilidade edisponibilidade.

Listing 3.3: XML de Atributos de Qualidade

...

<serviceLevel id="1">

<cost>2,07</cost>

<curCapacity>0</curCapacity>

<level>1</level>

<maxCapacity>42</maxCapacity>

<name>imageService1</name>

<responseTime>23379</responseTime>

<serviceSpec>com.assertLab.imageService</serviceSpec>

</serviceLevel>


<cost>0,29</cost>


<level>2</level>





</serviceLevel>

...

Apesar da nomenclatura dos atributos de qualidade dizer muito a respeito dos mesmos,estes não são suficientes para evitar interpretações distintas. Por isso, vale ressaltar que o atributode custo representa o custo de um determinado serviço em um dado nível de serviço. Estaabordagem não determina como o custo do serviço deve ser definido, possibilitando a utilizaçãodo DYMOS QoS de acordo com diversos modelos de precificação.

Os atributos de capacidade máxima e atual representam respectivamente quantos clientesao mesmo tempo podem utilizar e quantos estão utilizando um serviço em um determinado nívelde serviço. O atributo nível refere-se ao nível de serviço ao qual os demais atributos de qualidadepertencem. O atributo de tempo de resposta armazena o valor de qual tempo de resposta emmicrossegundos deve ser esperado de um serviço no nível de serviço em questão.

Os atributos de nome e especificação do serviço, tem função meramente identificadora.Enquanto os atributos de confiabilidade e disponibilidade são baseados em dados históricos. Ovalor do primeiro é incrementado sempre que o serviço requisitado responde a uma requisição em


tempo igual ou menor ao especificado no atributo de tempo de resposta e decrementado quandoocorre o contrário. O atributo de disponibilidade é incrementado sempre que uma requisição aum serviço tem uma resposta e decrementado quando o serviço se mostra indisponível.

3.2.1 Seleção de Serviços

De acordo com o que já foi explanado, o componente “Broker” é responsável por realizaras análises dos atributos de qualidade dos serviços Web. O “Broker” do DYMOS QoS é derivadodas abordagens de CHEN; YU; LIN (2003); YU; LIN (2004, 2005), onde cada provedor deserviços Web oferece diversos níveis de serviço para cada funcionalidade.

Nesta abordagem fica sob a responsabilidade do “Broker” coletar as informações a res-peito dos candidatos a provedores de serviço. Para tanto, este componente, apanha as definiçõesde serviço e nível de serviço dos clientes e então realiza uma verificação nos compromissos dequalidade oferecidos pelos serviços.

O “Broker” utiliza uma função para a otimização da seleção dos serviços Web chamadapor YU; LIN (2004, 2005) de função de utilidade. Esta função é baseada em um conjunto deparâmetros que englobam informações estáticas (nível de serviço), as necessidades de qualidadedo lado cliente e a capacidade dinâmica do servidor (carga).

Para que seja possível o entendimento da função de utilidade algumas definições precisamser esclarecidas. A primeira delas é que serviços Web que oferecem a mesma funcionalidadepodem ter características não funcionais distintas. O conjunto desses serviços que oferecem amesma funcionalidade é chamado de classe de serviço e denotado por S, sendo cada serviço deuma classe denotado individualmente por s. O nível de serviço oferecido por um único serviçoWeb é denotado por l. A confiabilidade é uma restrição de qualidade a respeito do atraso noprovimento de um serviço denotada por R.

Cada serviço Web tem suas próprias definições. O número de níveis de serviço que cadaserviço Web oferece é obtido a partir da definição L(s) e o tempo de serviço é denotado pore(s, l). As definições adotadas a respeito da carga de cada serviço são Cmax(s, l) e Ccur(s, l), ondeo primeiro denota a capacidade máxima e o segundo a carga atual em um determinado nível deserviço. Por fim, o custo para cada nível de serviço é denotado por c(s, l).

A função de utilidade toma as decisões de seleção com base na função de benefício(Equação 3.1), que por sua vez baseia-se na carga do serviço. A função é utilizada para que osserviços selecionados tenham uma baixa carga, oferecendo assim menores tempos de respostareais. Isso implica em um balanceamento global das cargas dos serviços evitando sobrecargas.

b(s, l) =Cmax(s, l)−Ccur(s, l)

Cmax(s, l)

� �3.1

A função de utilidade pode ser vista na Equação 3.2, onde wb e wc são os pesos de umbenefício de custo, b(s, l) e c(s, l) são os benefícios e os custos, escolhendo serviço s no nível del, avgb e avgc são o benefício médio e o custo médio para os serviços disponíveis no nível de

3.3. CONCLUSÕES 39

serviço escolhido, e, finalmente, stdb e stdc são o desvio padrão de benefício e custo. O objetivodessa função é maximar o benefício e minimizar o custo no momento de uma seleção de serviço.

F(s, l) = wb ∗ (b(s, l)−avgb

stdb)+wc ∗ (1−

c(s, l)−avgc

stdc)

� �3.2

3.3 Conclusões

Este capítulo tratou da análise e intervenção exploratória realizadas para contribuir comos objetivos deste estudo apresentando um entendimento do processo de descoberta de serviçosdo DYMOS e a classificação das features utilizadas por este. Partindo desta análise foi possívelconstruir uma abordagem de descoberta de serviços com base na análise de atributos de QoS.

A análise implementada para a seleção de serviços é fundamentada na idéia de queum componente pode atuar como mediador avaliando a necessidade do cliente e encontrandoum serviço que melhor se enquadre nesta necessidade. O trabalho do componente mediador(“Broker”) é regido pela relação custo-benefício especificada na forma de funções matemáticasdefinidas por YU; LIN (2004, 2005). O próximo capítulo trata da de uma validação realizadacom a abordagem aqui proposta para demonstrar a sua efetividade. Assim como é relatada umaavaliação da performance da mesma.

404040

4Avaliação

O poder permanece onde os homens crêem que ele deve permanecer.

—GEORGE R. R. MARTIN (A Fúria dos Reis, As Crônicas de Gelo e Fogo)

A fim de avaliar a abordagem proposta no Capítulo 3 foram desenvolvidas uma validaçãoe uma avaliação quantitativa, ambas apresentadas nesse capítulo. A primeira de natureza aplicadae exploratória quanto aos objetivos. Para esta procura-se demonstrar o DYMOS QoS em ação naDSPL Mobiline relatada no Capítulo 1.

A avaliação quantitativa é de natureza básica e descritiva no que diz respeito aos fins.Estudos descritivos, de uma maneira geral, expõem características de determinada populaçãoou de determinado fenômeno, podendo estabelecer correlações entre variáveis e definir suanatureza. Não obstante, não tem compromisso de explicar os fenômenos descritos sem excluir apossibilidade de servir como base para fazê-lo (MORESI, 2003).

4.1 Validação Exploratória

Os produtos da Mobiline foram os objetos da validação exploratória. Para isso, primeirofoi necessário adequar o lado do cliente da DSPL e posteriormente configurar o DYMOS QoS,assim construindo os arquivos XML necessários aos componentes descritores e ao ServiceLevel-Provider.

O GREatTour e o Cin Tour são guias de visitas móveis sensíveis ao contexto derivadosda MobiLine. Ambos são executados a partir de dispositivos que possuam o sistema operacionalAndroid e fornecem informações sobre os pesquisadores e os ambientes do laboratório dogrupo de pesquisas GREat da Universidade Federal do Ceará e do Centro de Informática daUniversidade Federal de Pernambuco, respectivamente.

Estes aplicativos utilizam informações contextuais, como localização, perfil e preferên-cias do usuário visitante, assim como as requisições desencadeadas por este e as características dodispositivo móvel para adaptar seu próprio comportamento. Parte das características do produtoque variam em tempo de execução e os core assets da SPL estão presentes nos dispositivos

4.1. VALIDAÇÃO EXPLORATÓRIA 41

móveis, enquanto outras características que variam em tempo de execução são ligadas ao produtoa partir do acesso a serviços Web.

Figura 4.1: GreatTour - Modelo de Features

Uma visão geral das features desses dois produtos são apresentadas nas Figura 4.11

e Figura 4.2. O Cin Tour é uma versão mais leve do Great Tour, diferindo deste por nãoapresentar as features de autenticação, de vídeo e de captura da localização do usuário utilizandoa tecnologia NFC.

A chamada aos serviços do lado servidor da SPL deve ser feita a partir da utilizaçãodas bibliotecas “KSOAP”2 e “DymosClientLib”. Esta última possui uma classe chamada“VariabilityContex”, que permite o suporte a reconfiguração de variabilidades dinâmicas e aclasse “ServiceEndpointFactory” que suporta a descoberta de serviços. Há também a classe“ServiceEndPoint” que cria objetos com a capacidade de armazenar o end point, o namespace e onome do serviço Web.

O Código 4.1 apresenta como deve ser feita uma requisição a um serviço Web no DYMOSQoS. Primeiro é necessária a criação de um objeto “ServiceEndPoint” que recebe o retornodo método “getEndPoint()” da classe “ServiceEndPointFactory”. Este método recebe comoparâmetro o nome da variante ou da interface para o serviço desejado e o número referente aonível de serviço esperado.

Listing 4.1: Descoberta de Serviços no Lado Cliente

1Disponível em: http://goo.gl/weMfAf2https://code.google.com/p/ksoap2-android/


Figura 4.2: Cin Tour - Modelo de Features

...

private ServiceEndPoint endpoint;

this.endpoint = ServiceEndPointFactory.getEndPoint("imageService", 1);

SoapObject request = new SoapObject(endpoint.getNamespace(), METHOD_NAME);

HttpTransportSE transport = new HttpTransportSE(endpoint.getEndpoint());

transport.call(SOAP_ACTION, envelope);

...

Para a abordagem do DYMOS QoS ser totalmente funcional cada vez que um serviçoestiver para ser chamado no lado do cliente, o nível de serviço desejado e o end point desse serviçoprecisa ser atualizado. Isso é feito através de uma chamada para os métodos requireLevel() egetServiceEndPoint() do serviço Web ApplicationService do framework que ocorre por meio dométodo “getEndPoint” no lado cliente.

Para exemplificar o funcionamento dos DYMOS QoS em uma situação real, a variante“ImageService” foi ativada e todos os seus serviços alternativos descritos na Listagem 4.2 com ocusto, a capacidade máxima (Cmax), a capacidade atual (cCurr) e o valor da função de utilidade(UF) mostrados na Tabela 4.1. Isto posto, foi possível experimentar o framework nas trêssituações descritas na Seção 1.3.

Listing 4.2: Services XML File



<services>

...

<service id="imageService" service−impl="com.assertLab.imageServiceImpl">

<service−spec>com.assertLab.imageService</service−spec>

<alternative−service ref="imageService1" />





</service>

<service id="imageService1" service−impl="com.assertLab.imageService1">


</service>



</service>



</service>



</service>



</service>

...

</services>

</variabilities>

Listing 4.3: QoS Attributes XML File

...


<cost>2,07</cost>


<level>1</level>





</serviceLevel>



<cost>0,29</cost>


<level>2</level>





</serviceLevel>

...

Tabela 4.1: Valores de QoS

Service cMax cCurr Cost UFimageService1 42 0 2,07 0,82imageService2 39 9 6,86 -0,58imageService3 30 17 0,56 0,18imageService4 23 22 6,97 -1,83imageService5 43 26 9,69 -1,82

O primeiro passo da validação é certificar que o comportamento do framework ficouinalterado no que diz respeito a situações onde a descoberta de serviços alternativos não sefaz necessária. Neste caso, uma requisição ao end point da variante “ImageService” é feita noproduto Mobiline. O “ServiceContext” utiliza os componentes descritores do framework paraidentificar a implementação e a especificação da variante. Assim, o “ServiceContext” verifica adisponibilidade do serviço no contêiner OSGi e envia o end point para o dispositivo móvel.

Nenhum problema foi detectado durante a execução deste primeiro passo e o end point

retornado foi o do serviço “imageService”, como era esperado. Diante disto, o primeiro passo davalidação foi concluído, restando para ser realizado o passo que utiliza a descoberta de serviçosalternativos.

No que se refere ao segundo passo, este verifica se a seleção do serviço que substituirá oque está indisponível deixa de ocorrer de acordo com a prioridade arbitrada e passa a acontecerde acordo com a qualidade dos serviços disponíveis no momento da requisição. Fica eleito oserviço que apresentar a maior pontuação fornecida pelo framework.

Para avaliar esta segunda situação o serviço “ImageService” foi inativado no contêinerOSGi e mantidos todos os serviços alternativos ativados. Quando uma solicitação para o end point

desta variante é feito o “ServiceContext” requisita ao “Broker” uma lista de serviços alternativose suas respectivas pontuações para a função de utilidade. Assim, o “ServiceContext” retornaráo end point exigido para a variação, considerando o serviço ativo com a maior pontuação nafunção de utilidade no contêiner OSGi.

Neste caso, o serviço escolhido foi o “imageService1”. Esta resposta denota que aescolha do framework foi correta, visto que este era o serviço com o maior valor para a funçãode utilidade, como demonstrado na Tabela 4.1.

4.2. AVALIAÇÃO ESTATÍSTICA DESCRITIVA 45

Um terceiro cenário foi proposto na Seção 1.3, onde uma requisição oriunda do clientepor um end point retorna sempre o serviço com melhor qualidade. Neste caso entende-se pormelhor qualidade o serviço com maior valor na função utilidade.

Para que esse terceiro cenário aconteça, o serviço prioritário deve ser substituído por umserviço sem implementação e ser colocado junto dos serviços alternativos. O que implica noregistro de seus atributos de qualidade no XML de atributos de qualidade.

Este terceiro cenário também é validado pelo segundo passo, visto que não existemalterações no fluxo de execução do DYMOS QoS. O que ocorre neste caso é apenas uma decisãode não manter um serviço prioritário por parte do engenheiro de software.

4.2 Avaliação Estatística Descritiva

A avaliação estatística descritiva tem cunho quantitativo, o que implica afirmar que todaela é baseada na filosofia positivista. Onde as variáveis a serem observadas são consideradasobjetivas e portanto diferentes observadores em outras visualizações encontrarão os mesmosresultados aqui apresentados. Por se tratar de uma observação numérica elimina-se a possibilidadede desacordo a respeito dos valores dessas variáveis (WAINER, 2007).

A ausência de um conjunto de dados reais a respeito da performance de outras técnicasde seleção de serviços no âmbito da área de DSPL cerceiou a possibilidade de experimentaçãoestatística para avaliar a abordagem proposta nesta dissertação. Diante disto, optou-se pelacriação de um benchmark com o intuito de aferir a performance do DYMOS QoS.

O benchmark consiste em uma classe de serviços contendo 100 serviços Web no formatode “bundles” OSGi e conjuntos de 4 níveis de serviço para cada serviço Web. Cada nível deserviço contém um identificador, um custo, a capacidade máxima e atual, o nome e a especificaçãodo serviço e o tempo de resposta.

O identificador, o nome e a especificação dos serviços são dados categóricos. Para essetipo de dado não existe sentido em fazer outra operação a não ser a verificação do valor dosmesmos. Esses dados tem a única função de identificar a qual serviço pertencem durante oprocesso de descoberta de serviço.

O nível de serviço é uma medida ordinal. Neste caso, além de ter fins de categorizaçãopermite uma ordenação dos valores. Os níveis de serviço utilizados neste benchmark estãocompreendidos entre os valores 1 e 4, incluindo-os. Os dados referentes à capacidade, o custoe o tempo de resposta são medidas de razão e não possuem nenhuma função de categorização,mas operações matemáticas com estes fazem sentido.

Esses valores foram gerados automaticamente a partir de um programa escrito em JAVA.Foi definido nesse programa que o identificador deveria ser sequencial e único, a capacidademáxima e atual são inteiros positivos não maiores que 50, o tempo de resposta representados emmilissegundos também é um inteiro positivo não maior que 61000, 51000, 31000 e 11000 paraos níveis de um a quatro respectivamente. O custo é sempre um fração positiva maior que zero e


menor que dez.A Figura 4.3 apresenta graficamente a distribuição do tempo de resposta máximo ofere-

cido por cada serviço. Nesta é evidenciada a concentração de menores tempos de resposta nosníveis 3 e 4, ao passo que os maiores tempos de resposta encontram-se nos níveis 1 e 2. Contudo,é notório que mesmo os níveis de serviço 1 e 2 apresentam tempos de resposta máximos tãobaixos quanto os outros níveis.

A Tabela 4.2 apresenta os valores médios, medianos e os desvios padrão dos serviçosWeb em cada nível de serviço. A Tabela 4.3, de maneira análoga, apresenta esses mesmos valoresem relação aos custos praticados pelos serviços Web. Tanto as capacidades quanto os custos daamostra gerada apresentam médias e medianas similares entre si, o que pode ser um indicativode que estes dados tem uma distribuição normal de probabilidade.

Tabela 4.2: Capacidades Máximas e Atuais

Média Mediana Desvio PadrãoLevel Máxima Atual Máxima Atual Máxima Atual1 25,64 13,25 25 12 14,36350932 11,085463452 25,14 12,48 24,5 7,5 15,32254548 12,385862913 24,78 11,11 24 8,5 13,81273326 9,8131493424 26,98 13,98 27,5 11 14,12372472 11,7115157

Figura 4.3: Tempo de Resposta

Tabela 4.3: Custo

Level Média Mediana Desvio Padrão1 4,82 4,56 2,742 5,20 5,09 2,743 5,48 5,71 2,734 4,99 4,97 2,86


Todos os 100 serviços do benchmark foram postos dentro do contêiner OSGi e registradosnos arquivos XML dos descritores do DYMOS QoS. Após isso 100 execuções foram realizadascom 4 subgrupos da população de serviços. O primeiro subgrupo possuía 5 serviços, o segundo10, o terceiro 50 e o último foi composto por toda a população.

Todas as execuções foram realizadas em um notebook com um processador A6 com 6GB de memória RAM, sistema operacional Windows 8, Java Virtual Machine (JVM) e Java

Development Kit (JDK) 1.7. Antes da extração dos tempos de execução foi realizado o Warm Up

do ambiente, executando cada subgrupo da população de serviços duas vezes utilizando comoparâmetro para a JVM -XX:+PrintCompilation, -verbose:gc e -XX:CICompilerCount=1.

Tabela 4.4: Desempenho do Dymos QoS

Quantidadede Serviços

Média Mediana Desvio Padrão DesempenhoRelativo(%)

100 10596089267,56 10566183253 137289824,950 5748081772,13 5703638330 103294539,4 84,341310510 1005138360,88 984489598,5 37707131,55 471,86970435 561101255,45 562455565 11848639,2 79,13671572

Tabela 4.5: Desempenho do Dymos

Quantidadede Serviços

Média Mediana Desvio Padrão DesempenhoRelativo (%)

100 44718748,65 42730676,00 5234277,24550 47238874,62 45913599,50 7166111,98 −5,3348560710 47566174,54 45192888,50 9912151,66 −0,6880938465 39972607,83 38636221,50 6680693,484 18,99692595

Para que se pudesse ter uma medida mais exata do tempo de execução do DYMOS QoSdurante o processo de seleção de serviço com base nos atributos de qualidade apresentadosas medidas foram feitas em nanosegundos. A Figura 4.4 apresenta o desempenho para cadaexecução em todos os subgrupos.

A Tabela 4.4 apresenta os valores médios, medianos e de desvio para cada um dossubgrupos além do desempenho relativo entre eles. O desempenho relativo é representado pelopercentual da quantidade de tempo de execução média da seleção de serviços no DYMOS QoScom relação ao desempenho anterior.

Ou seja, caso o desempenho relativo seja maior que zero em uma das linhas da tabela,então a linha imediatamente superior apresentou um tempo médio de execução maior. Casocontrário o tempo médio de execução da linha imediatamente superior foi menor.

Como pode ser observado, o tempo de execução para o subgrupo com 50 serviços Web

foi 84% menor em relação ao subgrupo com 100 serviços e 472% maior com relação ao subgrupocom 10 serviços. Esta informação evidencia que a abordagem utilizada pode não ser escalonável.

4.3. CONCLUSÕES 48

O mesmo procedimento de avaliação foi realizado com o DYMOS Framework coma diferença de que os níveis de serviço e seus respectivos atributos não foram utilizados. Oresultado destas execuções podem ser vistas Tabela 4.5. Ao se comparar os desempenhosdo DYMOS Framework com o DYMOS QoS, fica nítido que o problema de escalabilidadeapresentado no DYMOS QoS não é oriundo do DYMOS Framework, mas sim da intervençãoexploratória realizada nesta dissertação.

Figura 4.4: Desempenho

4.3 Conclusões

Este capítulo apresentou uma validação exploratória da abordagem proposta e umaavaliação estatística de desempenho. Pode-se concluir a partir da validação que a abordagemproposta é funcional para a MobiLine, exigindo pouco esforço para ser adotada pela DSPL. Valesalientar, no entanto, que apesar dos indícios de que a abordagem seja compatível com outrasDSPLs, esta não é uma afirmação que possa ser feita com base nesta validação.

A avaliação estatística descreve em termos quantitativos o desempenho da abordagemproposta. Pode-se concluir, a partir da observação do comportamento do DYMOS QoS que aabordagem pode não ser escalonável. Fato devido ao tempo gasto para a descoberta dos serviçosem classes grandes de serviço que se apresenta relativamente maior do que o esperado quandocomparado com classes de serviços menores.

Vale salientar ainda, que os dados utilizados para a execução da avaliação de performancesão dados gerados. Portanto existe um risco de que esses dados apresentem um viés que podeser considerado com uma ameaça a validade do estudo. Outra limitação é o fato de não estardisponível na literatura nenhum outro benchmark ou abordagem relacionada disponível parauma comparação dentro de um desenho experimental adequado.

494949

5Conclusão

Eu é que não me sento

No trono de um apartamento

Com a boca escancarada

Cheia de dentes

Esperando a morte chegar

—RAUL SEIXAS (Ouro de Tolo)

Neste capítulo final serão apresentadas as contribuições, limitações e uma breve explana-ção a respeito dos trabalhos futuros. Esta dissertação foi iniciada com uma contextualização arespeito da temática abordada, junto com a problematização e a descrição dos métodos utilizadospara que os objetivos fossem alcançados no Capítulo 1. Neste mesmo capítulo ficou estabelecidoque o objetivo deste trabalho era propor uma abordagem de seleção, em tempo de execução dascaracterísticas que irão compor a DSPL com base em uma análise de seus respectivos atributosde qualidade.

No Capítulo 2 foram explanados os termos que pertencentes à área de SPL e SOC, paramlehor compreensão e aplicação destes. Posteriormente, foi apresentado o estado da arte noque tange à derivação dinâmica em DSPL, elencando os estudos que já foram publicados arespeito na área em ordem cronológica. Este capítulo encerrou com uma discussão em tornodas limitações das contribuições dos estudos que tratam sobre derivação dinâmica em DSPLsorientadas a serviço, apresentando a lacuna na qual esta pesquisa esteve centralizada.

A este ponto, dada a ausência de trabalhos na literatura que atendessem a necessidadede definir os serviços com base na requisição de usuários e ao mesmos tempo ao objetivoestabelecido, foi proposta a abordagem do DYMOS QoS no Capítulo 3. Neste capítulo sãoapresentadas as modificações realizadas no DYMOS e a inclusão dos componentes responsáveispela realização da seleção de serviços em tempo de execução com base nos estudos de CHEN;YU; LIN (2003); YU; LIN (2004, 2005).

No Capítulo 4 ocorre tanto a validação exploratória quanto a avaliação estatística des-

5.1. CONTRIBUIÇÕES 50

critiva da abordagem proposta. A partir desse pode-se concluir que a abordagem apresentadafunciona para a linha de produto na qual foi validada, sendo melhor utilizada com pequenasquantidades de serviços a serem avaliados em tempo de execução.

5.1 Contribuições

A primeira contribuição deste trabalho é a criação de uma abordagem de seleção, emtempo de execução das características (serviços) que irão compor a DSPL com base em umaanálise de seus respectivos atributos de qualidade. Esta abordagem utiliza-se de procedimentosque já estavam presentes no processo de derivação de produtos da Mobiline, agregando apenascomo responsabilidade do engenheiro de software a necessidade de descrever os atributos dequalidade dos serviços.

Outra contribuição é o fornecimento de um mecanismo que permite a seleção de serviçoscom base na abordagem de CHEN; YU; LIN (2003); YU; LIN (2004, 2005). Este mecanismoserá licenciado como código aberto e disponibilizado no site do autor desta dissertação1 . Obenchmark utilizado para a avaliação da proposta é de domínio público e disponibilizado juntocom o software sob a mesma licença, caracterizado assim a ultima contribuição desta dissertação.

5.2 Limitações

WAZLAWICK (2009) classifica em cinco categorias os estilos de pesquisa correntesem Ciência da Computação: apresentação de um produto, apresentação de algo diferente,apresentação de algo possivelmente melhor, apresentação de algo reconhecidamente melhor eapresentação de uma prova. Dentro dessa classificação esta dissertação enquadra-se na categoriade “apresentação de algo diferente”.

Esta classificação justifica-se pela primeira contribuição deste estudo que é apresentaruma maneira diferente de resolver o problema da seleção de serviços em tempo de execução emuma DSPL orientada a serviços. Segundo o mesmo autor (WAZLAWICK, 2009), este tipo depesquisa é característico de áreas emergentes e os trabalhos são apresentados como comparações,mais comumente qualitativas, entre técnicas.

O estado da arte realizado na Seção 2.3.1.1 apresenta estudos como apresentação de umproduto ou de algo novo, o estágio mais básico da classificação de (WAZLAWICK, 2009). Estesestudos apresentam abordagens avaliadas qualitativamente dada as suas respectivas aplicações emdeterminadas linhas de produto. Não é possível assegurar portanto que estas mesmas abordagensfuncionem em outros contextos e com outras linhas de produtos, o que é um indício de falta dematuridade na área de DSPL em derivação dinâmica em DSPLs orientadas a serviço.

Esta constatação é corroborada pelos estudos de BUREGIO; ALMEIDA; MEIRA (2010);ALVES et al. (2009); BENCOMO; LEE; HALLSTEINSEN (2010); BENCOMO; HALLSTEIN-

1www.cin.ufpe.br/ jrfs/dymosqos

5.3. TRABALHOS FUTUROS 51

SEN; ALMEIDA (2012); SILVA et al. (2013), que ao mapearem a área de DSPL observaram quea maioria dos estudos publicados até então apresentam como contribuição o desenvolvimentode metodologias e propostas de soluções para situações específicas. Estas soluções não estãodisponíveis em local público para o uso por parte dos outros pesquisadores, impossibilitandouma comparação entre abordagens.

Estas limitações no campo de estudos de DSPLs, tornaram-se um fator limitante parao estudo desenvolvido nesta dissertação. A ausência de outras ferramentas e de dados maisdetalhados a respeitos de outras abordagens impossibilitou a criação de um desenho experimentalrebuscado para o estudo aqui apresentado. Um benchmark de serviços e seus respectivos atributosde qualidade foi criado para mitigar esse problema e contribuir para que a área de derivaçãodinâmica em DSPL evolua para um novo estágio dentro da classificação de WAZLAWICK(2009).

A criação e manutenção de um benchmark é uma tarefa nobre na opinião de WAINER(2007). No entanto, benchmarks gerados por ferramentas podem conter um viés. Os indíciosde normalidade probabilística relatados no final do Capítulo 4 podem indicar um viés o que seapresenta como uma limitação desse conjunto de dados.

Também foi realizada uma breve pesquisa na área de SOC a procura de abordagens queestivessem publicados os seus dados para que fosse possível a comparação. Mas igualmente, nãohouve sucesso no que diz respeito a esta busca.

5.3 Trabalhos Futuros

As limitações da área de pesquisa desta dissertação representam um conjunto de opor-tunidades de pesquisa que não deve deixar de ser levado em consideração. Basta olhar para asáreas de carência de estudos apontadas por BUREGIO; ALMEIDA; MEIRA (2010); ALVESet al. (2009); BENCOMO; LEE; HALLSTEINSEN (2010); BENCOMO; HALLSTEINSEN;ALMEIDA (2012); SILVA et al. (2013).

A área de DSPL como um todo e a derivação dinâmica em si carecem do desenvolvimentode modelos, ferramentas, algorítimos e discussões conceituais. Os principais tipos de estudosausentes são relatos de experiência, pesquisas de validação e avaliação.

Um caminho de pesquisa que parece interessante é a identificação de outras abordagensde descoberta de serviços utilizando técnicas de composição ou de inteligência artificial, comoalgorítimos genéticos, por exemplo. A comparação entre essas outras técnicas em diversoscontextos de DSPL podem trazer resultados científicos relevantes.

Outro caminho que pode ser trilhado é o estudo de como uma DSPL para dispositivosmóveis pode se tornar um sistema autônomo nos termos do ciclo MAPE-K, especificado pelaIBM (2006). Diminuindo assim, a necessidade de intervenção humana na derivação dinâmica daDSPL ao passo que esta torna-se mais assertiva e menos onerosa.

Estudar a sinergia entre DSPLs orientadas a serviços e a área de estudos das Social

5.3. TRABALHOS FUTUROS 52

Machines pode ter resultados científicos relevantes. Visto que a descoberta de serviços poderiaser facilitada em um ambiente onde os mesmos já ofertem informações semânticas ao seu própriorespeito.

Do ponto de vista mercadológico, tem se tornado frequente que sistemas de Internetsejam portados para dispositivos móveis utilizando tecnologias como HTML5 e JavaScript.Apesar de ser uma abordagem que representa um menor custo de desenvolvimento, sobretudoquando o sistema precisa ser executado a partir de diferentes sistemas operacionais, ela torna-seum impeditivo no que diz respeito ao uso de recursos do dispositivo e na programação dereconfigurações dinâmicas.

Por outro lado, existe um desejo da OSGi Aliance de tornar o OSGi compatível comdiversas linguagens de programação. Parte desse desejo é expresso na RFP-159 que foi lançadaem 2007 e deu os seus primeiros passos em 2013.

Uma investigação científica para o desenvolvimento de um mecanismo que permita areconfiguração dinâmica de artefatos de código em JavaScript pode ter resultados mercadológicosrelevantes no que diz respeito aos sistemas de Internet que estão sendo portados para dispositivosmóveis.

535353

Referências

ABBAS, N. Towards autonomic software product lines. In: Anais. . . [S.l.: s.n.], 2011. v.46, n.0.

ABBAS, N.; ANDERSSON, J.; WEYNS, D. Knowledge evolution in autonomic softwareproduct lines. In: New York, New York, USA. Anais. . . ACM Press, 2011. p.1.

ALFEREZ, G. H.; PELECHANO, V. Context-Aware Autonomous Web Services in SoftwareProduct Lines. In: ACM PRESS. Anais. . . Ieee, 2011. p.100–109.

ALI, R.; CHITCHYAN, R.; GIORGINI, P. Context for goal-level product line derivation. In:IEEE. Anais. . . [S.l.: s.n.], 2009.

ALVES, V. et al. Comparitive study of variability management in software product lines andruntime adaptable systems. In: Anais. . . [S.l.: s.n.], 2009.

BARESI, L.; MILANO, P. Service-Oriented Dynamic Software Product Lines. In: Anais. . .[S.l.: s.n.], 2012. n.Cvl, p.42–48.

BENCOMO, N.; HALLSTEINSEN, S.; ALMEIDA, E. A View of the Landscape of DynamicSoftware Product Lines. In: Anais. . . [S.l.: s.n.], 2012. p.1–1.

BENCOMO, N.; LEE, J.; HALLSTEINSEN, S. How dynamic is your Dynamic SoftwareProduct Line? In: Anais. . . [S.l.: s.n.], 2010.

BUREGIO, V.; ALMEIDA, E.; MEIRA, S. Characterizing Dynamic Software Product Linesâ APreliminary Mapping Study. In: Anais. . . [S.l.: s.n.], 2010. p.53–60.

CARVALHO, S. T.; LOQUES, O.; MURTA, L. Dynamic Variability Management in ProductLines: an approach based on architectural contracts. In: Anais. . . Ieee, 2010. p.61–69.

CETINA, C.; FONS, J.; PELECHANO, V. Applying Software Product Lines to BuildAutonomic Pervasive Systems. In: IEEE. Anais. . . Ieee, 2008. n.ii, p.117–126.

CHEN, H. C. H.; YU, T. Y. T.; LIN, K.-J. L. K.-J. QCWS: an implementation of qos-capablemultimedia web services. In: IEEE. Anais. . . [S.l.: s.n.], 2003.

D’AMBROGIO, A. A Model-driven WSDL Extension for Describing the QoS ofWeb Services.In: WEB SERVICES, 2006. ICWS ’06. INTERNATIONAL CONFERENCE ON. Anais. . .[S.l.: s.n.], 2006. p.789–796.

DAMIANI, F.; PADOVANI, L.; SCHAEFER, I. A Formal Foundation for DynamicDelta-Oriented Software Product Lines. In: Anais. . . [S.l.: s.n.], 2012. p.1–10.

DEORA, V. et al. Modelling Quality of Service in Service Oriented Computing. In:SERVICE-ORIENTED SYSTEM ENGINEERING, 2006. SOSE ’06. SECOND IEEEINTERNATIONAL WORKSHOP. Anais. . . [S.l.: s.n.], 2006. p.95–101.

ERL, T. Service-Oriented Architecture: concepts, technology, and design. [S.l.: s.n.], 2005.760p.

REFERÊNCIAS 54

ERL, T. SOA and Web Services. In: SOA Principles of Service Design. [S.l.]: Prentice Hall,2007. p.46–50.

GOMAA, H.; HASHIMOTO, K. Dynamic software adaptation for service-oriented productlines. In: New York, New York, USA. Anais. . . ACM Press, 2011. p.1.

GOMAA, H.; SALEH, M. Software Product Line Engineering and Dynamic Customization of aRadio Frequency Management System. In: ACM PRESS. Anais. . . [S.l.: s.n.], 2006. p.345–352.

GüNTHER, S.; SUNKLE, S. Dynamically adaptable software product lines using Rubymetaprogramming. In: New York, New York, USA. Anais. . . ACM Press, 2010. p.80–87.

HALLSTEINSEN, S. et al. Using Product Line Techniques to Build Adaptive Systems. In:ACM PRESS. Anais. . . Ieee, 2006. p.141–150.

HALLSTEINSEN, S. et al. Dynamic software product lines. Computer, [S.l.], n.April, p.93–95,2008.

IBM. An architectural blueprint for autonomic computing. [S.l.: s.n.], 2006. (June).

JOSUTTIS, N. SOA in Practice. [S.l.]: O’reilly, 2007.

KHEZRIAN, M. et al. An Evaluation of State-of-the-art Approaches for Web Service Selection.In: INTERNATIONAL CONFERENCE ON INFORMATION INTEGRATION ANDWEB-BASED APPLICATIONS & SERVICES, 12., New York, NY, USA. Proceedings. . .ACM, 2010. p.885–889. (iiWAS ’10).

KIM, M.; JEONG, J.; PARK, S. From product lines to self-managed systems: anarchitecture-based runtime reconfiguration framework. In: ACM. Anais. . . [S.l.: s.n.], 2005.p.66–72.

LEE, J. A Feature-Oriented Approach to Developing Dynamically Reconfigurable Products inProduct Line Engineering. In: Anais. . . Ieee, 2006. p.131–140.

LEE, J.; KOTONYA, G. Combining service-orientation with product line engineering. In: IEEE.Anais. . . [S.l.: s.n.], 2010. n.June, p.35–41.

LIN, K.-J. et al. The design and implementation of service process reconfiguration withend-to-end QoS constraints in SOA. Service Oriented Computing and Applications, [S.l.],v.4, n.3, p.157–168, June 2010.

MARINHO, F. G. et al. MobiLine: a nested software product line for the domain of mobile andcontext-aware applications. Science of Computer Programming, [S.l.], May 2012.

MENDONçA, D. F. et al. A Systematic Mapping Study on Service Oriented Computing in theContext of Quality of Services. In: Anais. . . [S.l.: s.n.], 2013. p.39–48.

MORESI, E. Metodologia da pesquisa. [S.l.: s.n.], 2003.

OLIVEIRA MARTINS, D. A. de. DYMOS: uma abordagem para suporte a variabilidadesdinâmicas em linhas de produto de software orientado a serviços e sensível ao contexto.2013. Dissertação (Mestrado em Ciência da Computação) — Universidade Federal dePernambuco, Recife, Pernambuco, Brazil.

REFERÊNCIAS 55

PAPAKOS, P.; CAPRA, L.; ROSENBLUM, D. S. Volare: context-aware adaptive cloud servicediscovery for mobile systems. In: INTERNATIONAL WORKSHOP ON ADAPTIVE ANDREFLECTIVE MIDDLEWARE, 9. Proceedings. . . [S.l.: s.n.], 2010. p.32–38.

PAPAZOGLOU, M. P.; GEORGAKOPOULOS, D. Introduction: service-oriented computing.Commun. ACM, New York, NY, USA, v.46, n.10, p.24–28, Oct. 2003.

PARRA, C.; BLANC, X.; DUCHIEN, L. Context awareness for dynamic service-orientedproduct lines. In: OF THE 9TH . Anais. . . [S.l.: s.n.], 2009. p.131–140.

PARRA, C. et al. Unifying design and runtime software adaptation using aspect models. In:Anais. . . Elsevier B.V., 2011. v.76, n.12, p.1247–1260.

SPRINGER (Ed.). Software Product Line Engineering: foundations, principles, andtechniques. [S.l.: s.n.], 2005. 467p.

PUKALL, M.; SIEGMUND, N.; CAZZOLA, W. Feature-oriented runtime adaptation. In:ELSEVIER B.V., New York, New York, USA. Anais. . . ACM Press, 2009. p.33.

ROSENMüLLER, M. et al. Flexible feature binding in software product lines. In: ACM PRESS.Anais. . . [S.l.: s.n.], 2011. v.18, n.2, p.163–197.

SHEN, L. et al. Towards feature-oriented variability reconfiguration in dynamic softwareproduct lines. In: Anais. . . [S.l.: s.n.], 2011.

SILVA, J. R. F. da et al. The dynamic aspects of product derivation in DSPL: a systematicliterature review. In: INFORMATION REUSE AND INTEGRATION (IRI), 2013 IEEE 14THINTERNATIONAL CONFERENCE ON. Anais. . . [S.l.: s.n.], 2013. p.466–473.

SUNKLE, S.; PUKALL, M. Using reified contextual information for safe run-time adaptation ofsoftware product lines. In: New York, New York, USA. Anais. . . ACM Press, 2010. p.1–6.

TANG, M.; AI, L. A hybrid genetic algorithm for the optimal constrained web service selectionproblem in web service composition. Computation (CEC), 2010 IEEE Congress on, [S.l.],2010.

WAINER, J. Métodos de pesquisa quantitativa e qualitativa para a Ciência da Computação.Atualização em Informática. Org: Tomasz Kowaltowski; Karin Breitman. Rio de Janeiro:Ed. PUC-Rio, [S.l.], p.1–42, 2007.

WAZLAWICK, R. Metodologia de pesquisa para ciência da computação. [S.l.]: ElsevierBrasil, 2009. v.1.

WOLFINGER, R. et al. Supporting Runtime System Adaptation through Product LineEngineering and Plug-in Techniques. In: ACM PRESS. Anais. . . Ieee, 2008. p.21–30.

YU, J.; LALANDA, P.; BOURRET, P. An Approach for Dynamically Building and ManagingService-Based Applications. In: IEEE. Anais. . . Ieee, 2010. p.51–58.

YU, Q. et al. A two-phase framework for quality-aware Web service selection. ServiceOriented Computing and Applications, [S.l.], v.4, n.2, p.63–79, Mar. 2010.

YU, Q. et al. A two-phase framework for quality-aware Web service selection. ServiceOriented Computing and Applications, [S.l.], v.4, n.2, p.63–79, Mar. 2010.

REFERÊNCIAS 56

YU, T.; LIN, K. Service selection algorithms for Web services with end-to-end QoS constraints.In: IEEE INTERNATIONAL CONFERENCE ON E-COMMERCE TECHNOLOGY. Anais. . .[S.l.: s.n.], 2004.

YU, T.; LIN, K.-J. Service selection algorithms for Web services with end-to-end QoSconstraints. Information Systems and e-Business Management, [S.l.], v.3, n.2, p.103–126,July 2005.

Documents

Jackson Raniel Florencio da Silva · 2019. 10. 25. · O ato de selecionar o conjunto de características que irão compor o produto e construí-lo para ser entregue é chamado de