Dymos QoS: Uma Abordagem para Seleção de Serviços em Tempo de Execução em Linhas de Produto de...

“Dymos QoS: Uma Abordagem para Seleção de Serviçosem 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 [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE, FEBRUARY/2014

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ção de Serviçosem 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

RECIFE, FEBRUARY/2014

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 significadossemânticos podem expressar um pedaço da minha alma. No entanto coloco aqui o meuesforço em faze-lo de maneira singela ao mesmo tempo que extremamente sincera.

Agradeço primeiro ao Pai do Céu que sempre me protegeu, me guiou e atendeuaqueles pedidos que fiz da forma como julgou ser melhor. Sua bondade e graça é tamanhaa ponto de me amar imensamente mesmo eu não sendo um exemplo de filho. Por issoreservo a Ele este primeiro lugar nos meus agradecimentos.

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

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

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

vii

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 paraa indústria a ideia de padronização dos produtos. Ford, tempos depois, inventou alinha de produtos, onde a partir de então foi possível produzir em massa reduzindo otempo de entrega do produto e seus custos. No que tange a indústria de software, estaapresenta tanto uma produção manufatureira quanto em massa que gera produtos quesão denotados segundo Pohl et al. (2005) como software individual e software standard:uma clara influência do fordismo na concepção do paradigma de Linhas de Produtode Software (SPL). No entanto, este paradigma de desenvolvimento não foi concebidopara suportar mudanças nos requisitos de usuários em tempo de execução. Diante desteproblema, a academia tem desenvolvido e proposto maneiras de estender o paradigmade SPL de forma a permitir que essas reconfigurações dinâmicas do software sejamsuportadas. 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-se nestapesquisa 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 combase em uma análise que mensura e valida atributos de qualidade em níveis de serviçosespecificados pelo usuário. Para tanto foi necessária a revisão da literatura existente embusca de meios de analisar atributos de qualidade de serviços em tempo de execução emDSPL e o desenvolvimento exploratório de uma abordagem de reconfiguração da DSPLutilizando-se das características dinâmicas do OSGi como base em tal análise. Com afinalidade de validar a abordagem proposta, a mesma foi testada exploratoriamente emuma DSPL para o domínio de guia de visitas móveis e sensível ao contexto, onde pode-se verificar a assertividade desta. Ao final da validação exploratória pode-se observara 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 que estaefetividade demonstrada é válida para outras DSPLs de outros domínios.

Palavras-chave: Linhas de Produto de Software, SPL, SPL Dinâmica, DSPL, Qaulidadede Serviços

xi

Abstract

The industrial production before Taylor was essentially focused on manufacturing andunique products. The Taylorism and his time and motion studies have led to the industrythe idea of standardization of products. Ford, sometime later, invented the productline which from then on was possible to mass produce by reducing the delivery timeand product costs. Regarding the software industry, this presents both a manufacturingand mass production that generates products that are denoted for Pohl et al. (2005) asindividual software and standard software: a clear influence of Fordism in the designparadigm of Software Product Lines (SPL). However, this development paradigm was notdesigned to support changing requirements of users at runtime. Faced with this problem,the academy has developed and proposed ways to extend the paradigm of SPL in orderto enable such dynamic reconfigurations of software. From This effort emerged theDynamics Software Lines (DSPL) (Hallsteinsen et al., 2008). Considering this scenario,the objective of this dissertation is to contribute to this research area presenting a new wayof thinking which features a DSPL should be connected at runtime to a product based onan analysis that measures and validates quality attributes in service levels specified bythe user. For this it was necessary to review the existing literature searching means ofanalyzing service quality attributes at runtime in DSPL and a exploratory development ofan approach for reconfiguration of DSPL using dynamic features OSGi based. In order tovalidate the proposed approach , it was tested in a mobile and context-aware DSPL, wherewe can verify this assertiveness. At the end of the exploratory validation we can observethe effectiveness of the proposed approach in DSPL in which it was applied. However,it is necessary to perform statistical evidence for the hypothesis that this demonstratedeffectiveness is valid for other areas DSPLs other tests.

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

xiii

Sumário

Lista de Figuras xvii

Lista de Tabelas xix

Lista de Acrônimos xxi

Lista de Códigos Fonte xxiii

1 Introdução 11.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Problemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Métodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Visão Geral da Solução . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Escopo Negativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5 Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Revisão da Literatura 92.1 Computação Orientada a Serviços . . . . . . . . . . . . . . . . . . . . 9

2.2 Qualidade de Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Linhas de Produto de Software . . . . . . . . . . . . . . . . . . . . . . 11

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

Estudos em Derivação Dinâmica . . . . . . . . . . . . . . . . . 13

2.4 A Interação entre SOC e DSPL . . . . . . . . . . . . . . . . . . . . . . 18

2.5 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 DYMOS QoS 213.1 Análise Exploratória . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.1 Operações do DYMOS . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Intervenção Exploratória . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.1 Seleção de Serviços . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 Avaliação 334.1 Validação Exploratória . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Avaliação Estatística Descritiva . . . . . . . . . . . . . . . . . . . . . . 38

xv

4.3 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 Conclusão 435.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Referências Bibliográficas 47

xvi

Lista de Figuras

1.1 Cenário do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

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

3.1 DYMOS - Diagrama de Pacotes (de Oliveira Martins, 2013) . . . . . . 223.2 DYMOS - Diagrama de Sequência - Reconfiguração de Serviços (de Oli-

veira Martins, 2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3 DYMOS - Diagrama de Sequência - Descoberta de Serviços (de Oli-

veira Martins, 2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.4 DYMOS QoS - Diagrama de Pacotes . . . . . . . . . . . . . . . . . . . 273.5 DYMOS QoS - Diagrama de Sequência - Descoberta de Serviços . . . . 28

4.1 GreatTour - Modelo de Features . . . . . . . . . . . . . . . . . . . . . 344.2 Cin Tour - Modelo de Features . . . . . . . . . . . . . . . . . . . . . . 354.3 Tempo de Resposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.4 Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

xvii

Lista de Tabelas

4.1 Valores de QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2 Capacidades Máximas e Atuais . . . . . . . . . . . . . . . . . . . . . . 404.3 Custo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.4 Desempenho do Dymos QoS . . . . . . . . . . . . . . . . . . . . . . . 414.5 Desempenho do Dymos . . . . . . . . . . . . . . . . . . . . . . . . . . 42

xix

Lista de Acrônimos

DOP Delta Oriented Programing

DSPL Linha de Produtos de Software Dinâmica

SPL Linha de Produtos de Software

OSGi Open Service Gatway Initiactive

SCM Computação Orientada a Serviço

SOA Arquitetura Orientada a Serviço

SEI Software Engineering Institute

xxi

Lista de Códigos Fonte

3.1 XML de Serviços do DYMOS . . . . . . . . . . . . . . . . . . . . . . 223.2 XML de Serviços do DYMOS . . . . . . . . . . . . . . . . . . . . . . 233.3 XML de Atributos de Qualidade . . . . . . . . . . . . . . . . . . . . . 294.1 Descoberta de Serviços no Lado Cliente . . . . . . . . . . . . . . . . . 354.2 Services XML File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3 QoS Attributes XML File . . . . . . . . . . . . . . . . . . . . . . . . . 37

xxiii

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 meiosde pensar a atividade industrial. No que tange à indústria de software, esta, apresentatanto uma produção manufatureira quanto em massa que gera produtos que são denotadossegundo Pohl et al. (2005) como software individual e software standard.

Denota-se, neste contexto, uma clara influência do fordismo na concepção do para-digma de Linhas de Produto de Software (SPL). Neste paradigma os produtos de software

são criados a partir de um conjunto comum de características, diferenciando-se entre sipelo gerenciamento de um conjunto de características variáveis que diferenciam cadaproduto.

O paradigma SPL é tradicionalmente divido em duas fases: a fase de Engenharia deLinha de Produtos e a fase de Engenharia do Produto. Na primeira fase são definidase implementadas todas as características que estarão presentes em todos os produtoschamadas de core assets, assim como as características variáveis que podem ou nãoestar em um produto da SPL. Durante a fase de Engenharia de Produto, são selecionadaspara compor o produto além dos core assets as características variáveis que atendem adeterminados requisitos de usuários que justificam a sua escolha para a composição doproduto.

1

CAPÍTULO 1. INTRODUÇÃO

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áriosem tempo de execução. Diante deste problema, a academia tem desenvolvido e propostomaneiras de estender o paradigma de SPL, de forma a permitir que essas reconfiguraçõesdinâmicas do software sejam suportadas. Surgiram deste esforço as Linhas de Produto deSoftware Dinâmicas (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ívelbase possui características comuns a aplicações móveis e sensíveis ao contexto. Já o nívelespecífico é composto por características que pertencem a um determinado domínio denegócio (Marinho et 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 apartir de dispositivos que possuem o sistema operacional Android e fornecem informaçõessobre os pesquisadores e os ambientes do laboratório do grupo de pesquisas GREat daUniversidade Federal do Ceará e do Centro de Informática da Universidade Federal dePernambuco, 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.Parte das características do produto que variam em tempo de execução e os core assets daSPL estão presentes nos dispositivos móveis, enquanto outras características que variamem tempo de execuçã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 deadaptação automático que em tempo de execução selecione características da aplicação.Estas estarão habilitadas para o usuário adaptá-las segundo o contexto no qual a aplicaçãoestá inserida. Onde, o funcionamento deste mecanismo pode variar desde baseado emregras 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,

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

2

1.2. PROBLEMÁTICA

quanto as informações a respeito do estado do próprio dispositivo. Estas informações sãocoletadas a partir dos sensores do dispositivo, sendo a localização geográfica adquirida apartir da câmera ou do sensor de sinais NFC.

O estudo de de Oliveira Martins (2013) abordou a problemática do mecanismo dereconfiguração e a descoberta de serviços criando uma ferramenta chamada DYMOSframework. Este atua sempre que uma reconfiguração que ocorre no lado cliente exigindoreconfigurações nos serviços no lado servidor. No entanto, este estudo seleciona osserviços no lado servidor de forma arbitraria, sem realizar nenhuma análise nos serviçosque irão compor a DSPL. O que é tratado no trabalho como fora de escopo e possíveltrabalho 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 a linha de produto emtempo de execução com base nas preferências do usuário. Esta análise não aborda apenasa conformidade funcional como também a qualidade das característica apresentadas.

1.2 Problemática

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 emtempo de execução as informações contextuais (coletadas por sensores ou do status dopróprio dispositivo) e recebem estímulos do usuário que junto com essas informaçõesdefinem quais adaptações em tempo de execução devem ocorrer.

Quando uma adaptação ocorre no dispositivo mobile duas situações podem ser de-sencadeadas: a) a requisição a um web service presente e ativo no lado servidor ou b) arequisição a um web service ausente ou inativo no lado servidor. Para a situação a), aoencontrar o serviço os produtos da MobiLine o consomem como há de se esperar.

No tocante a situação b), a partir da criação do DYMOS, quando o serviço não éencontrado o framework é responsável por procurar um serviço para substituir o queestá indisponível de acordo com uma ordem de prioridade. Caso nenhum dos serviçosorganizados por prioridade esteja disponível, qualquer serviço que atenda a interfacerequisitada pela aplicação mobile é disponibilizado para consumo.

No entanto, Alferez and Pelechano (2011) argumentam que web services são executa-dos em ambientes complexos e heterogêneos e considerando este fato é apropriado queexistam mecanismos de adaptação de acordo com mudanças contextuais que efetuemreconfigurações que aumentem a qualidade do serviço prestado. Enquanto que, para Lin

3


Figura 1.1 Cenário do Problema

et al. (2010), do ponto de vista empresarial é fortemente desejável maximizar a qualidadede um serviço prestado levando em consideração os diversos entendimentos de o que équalidade do ponto de vista de diferentes clientes.

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 emDSPL ocorre; b) Desenvolver um método para a avaliação da qualidade e seleção dosserviços em tempo de execução; c) Avaliar a performance da abordagem proposta.

1.2.1 Métodos

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

4

1.3. VISÃO GERAL DA SOLUÇÃO

terão sempre os mesmos valores em observações distintas realizadas por pesquisadoresdiferentes. Para que isto seja possível todos os passos seguidos em direção aos objetivosespecíficos são descritos e os valores das variáveis de observação disponibilizados. Paraque os objetivos específicos fossem alcançados foi necessário estabelecer os métodospelos quais este estudo seria guiado. Estes métodos foram escolhidos de acordo com anatureza de cada objetivo específico

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

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

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

1.3 Visão Geral da Solução

Para alcançar o objetivo geral desta dissertação a abordagem proposta por de 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 GatwayInitiative (OSGi) que avalia individual e coletivamente os atributos de qualidade deserviço disponível para a reconfiguração da SPL em tempo de execução.

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

A partir desta contribuição é possível modificar a situação b) apresentada na Seção 1.2e ilustrada na Figura 1.1, de modo que a seleção do serviço que substituirá o que está

5


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. Ficaeleito o serviço que apresentar a maior pontuação fornecida pelo framework DYMOSQoS. Ainda como efeito dessa contribuição, torna-se possível um terceiro cenário onde arequisição por um serviço retorna sempre um serviço ótimo para determinado nível deserviç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 presentetrabalho alguns tópicos como a especificação e implementação de agentes, sejam estes dehardware ou de software, que responsabilizem-se pela monitoração do contexto onde osprodutos da DSPL estão inseridos.

Assume-se, neste estudo, que existem regras de contexto e derivação de produtosdeterminadas. Sendo assim, a criação de tais regras é considerada com fora do escopoabordado. Da mesma maneira, não são abordadas técnicas de precificação, regras deestabelecimento de preços ou prazo de vigência para os mesmos.

Os serviços utilizados neste trabalho possuem atributos de qualidade que servemcomo insumos para a avaliação dos mesmos. No entanto, o monitoramento de quebra deacordos de nível de serviço ou de qualquer garantia a respeito dos valores desses atributosde qualidade també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 emderivação 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 iniciacom a descrição do funcionamento do DYMOS, sobretudo no que diz respeito ao seumecanismo de descoberta de serviços. A segunda parte deste capítulo trata de apresen-tar as modificações realizadas no framework com a criação dos componentes que sãoresponsáveis pela análise da qualidade dos serviços em tempo de execução.

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

6

1.5. ORGANIZAÇÃO DA DISSERTAÇÃO

framework.Por fim, o Capítulo 5 encerra esta dissertação sumarizando os passos demonstrados

nos capítulos anteriores e relatando o desfecho que foi possível concluir com relação aabordagem proposta. É apresentado neste capítulo as limitações, contribuições e umalista de trabalhos futuros.

7

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,o capítulo inicia com uma breve explanação a respeito dos conceitos fundamentaisda Computação Orientada a Serviços (SOC). Em seguida são apresentados conceitosrelacionados a abordagem SPL e então o estabelecimento do Estado da Arte em derivaçãodinâmica. Finaliza-se, então com uma explanação crítica a respeito da interação entreDSPL 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 componentesdiversos de infraestrutura como servidores web e bancos de dados.

É de encargo da SOA determinar os meios pelos quais os serviços devem ser or-ganizados, construídos e gerenciados. SOA fundamenta-se na utilização de serviçoscomo unidades fundamentais, suas respectivas descrições e nas operações de publicação,descoberta, seleção e vinculação (Papazoglou and 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 baixo

9

CAPÍTULO 2. REVISÃO DA LITERATURA

acoplamento, contrato entre serviços, descoberta de serviços e granularidade alta oupequena quantidade de requisições ao serviço para o desempenho de uma funcionalidade.Onde o baixo acoplamento diz respeito ao número de dependências entres os serviços eé alcançado a partir da modularização dos serviços fazendo com que sejam acessadosatravés de contratos.

Dentro deste contexto, os clientes (serviços e aplicações que utilizam as funcionalida-des providas por um outro serviço) aderem aos contratos de comunicação, definidos porum ou mais serviços. Estes contratos consistem de uma descrição das funcionalidades,características e formatos de dados do serviço. São utilizados, assim, normalmenteformatos padronizados como contratos a exemplo de XML, WSDL e XSD, como afirmaErl (2005).

Sendo assim, a descoberta de serviços ocorre sempre a partir da especificação des-critiva dos mesmos (contrato), permitindo a sua localização e identificação. Ambaspodem ocorrer a partir do Universal Descriptor, Discovery and Integration (UDDI) ouUniform Resource Identifier (URI), sendo utilizados diretamente por um cliente ou porum mecanismo de descoberta de serviço (Josuttis, 2007).

A modularidade e reutilização providas pelo uso de SOC e SOA permitem queserviços sejam disponibilizados para a utilização de terceiros ou em sistemas diferentesdos sistemas para os quais estes foram desenvolvidos. No âmbito de transações comerciaiseventualmente é desejável que a qualidade do serviço (QoS) oferecido seja aferida paraque sejam garantidas, por exemplo, cláusulas contratuais como a quantidade de respostaa uma determinada requisição por segundo.

A utilização de SOC na Web manifesta-se na forma de Web services que é um tipoespecífico de serviço que que é identificado por uma URI (Papazoglou and Georgako-poulos, 2003). Algumas características comuns a web services que são utilizadas para aaferição de sua 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 valorespara os seus atributos de QoS. Sendo assim, alguns critérios de qualidade podem termelhores valores em uma implementação do serviço e alguns piores em comparação aoutras implementações (Tang and Ai, 2010).

10

2.3. LINHAS DE PRODUTO DE SOFTWARE

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 dizrespeito a o quão bem um provedor de serviços pode fazer a entrega das funcionalidadesdeste (Yu et al., 2010b).

O termo “qualidade” é utilizado para representar juízos de valor e por isso é umtermo de significado vago. No entanto, Deora et al. (2006) argumenta que em SOC aqualidade é normalmente vista segundo as perspectivas de conformidade e reputação.Dentro da primeira perspectiva a qualidade é vista como um sinônimo de atendimentoa especificações como tempo de reposta, custo e largura de banda. Já na perspectiva dequalidade enquanto reputação, trabalha-se com a percepção de um usuário a respeito deum serviço em geral.

Papakos and Rosenblum (2010) defendem que em aplicações cliente em dispositivosmóveis sofrem com mudanças de contexto que podem incluir mudanças nos recursos dodispositivo, 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 exigido pelo podem não estar de acordocom as capacidades do dispositivo em seu contexto atual resultando em um desperdíciode recursos e um alto custo monetário.

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 maiscomplexa a medida que aumentam as possibilidades de combinações de características(features) de um software. O paradigma de Linhas de Produto de Software (SPL) vai deencontro a este problema criando produtos de software a partir de um conjunto comumde características. O gerenciamento da configuração ocorre com as variabilidades e ascomonalidades entre os membros da linha de produto de software.

Segundo o Software Engineering Institute (SEI)1, SPL é um conjunto de sistemasintensivos de software que compartilham um conjunto comum e gerenciado de funciona-lidades que satisfazem necessidades específicas de um segmento ou missão particular demercado e que são desenvolvidos a partir de um conjunto comum de recursos principais(Core Assets) de maneira prescrita. Os benefícios em adotar o paradigma SPL dependedo contexto no qual ele é aplicado. Alguns dos benefícios mais comuns são a redução do

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

11


custo e do time-to-marketing promovido pela 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, porisso existe uma demanda crescente por sistemas capazes de se adaptar automaticamenteao encontrar essas condições. Em 2008, Hallsteinsen Hallsteinsen et al. (2008) publicouum estudo que descreveu o conceito de Dynamic Software Product Lines (DSPL). Estaslinhas de produto diferem das outras por não gerenciarem a variabilidade durante a fasede design do software, mas em tempo de execução.

Uma DSPL representa normlamente cinco características: a) variabilidade dinâmica,b) a ligação (biding)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 contextoe e) são desenvolvidas para um contexto ou ambiente específico no lugar de um segmentode mercado (Hallsteinsen et al., 2008).

Opcionalmente, DSPLs podem ser sensíveis ao contexto a sua volta (Parra et al.,2009; Ali et al., 2009; Alferez and Pelechano, 2011), possuir propriedades autonômicasou de auto-adaptação (Abbas et al., 2011; Cetina et al., 2008; Abbas, 2011) e tomadaautomática de decisão. Estas características compõem um desafio para um modelo dedesenvolvimento de SPLs que gerencia 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 literatura jápublicada o que já se sabe sobre determinado tema, quais as lacunas existentes e ondese encontram os principais entraves teóricos ou metodológicos. No que diz respeito aderivação dinâmica, vários pesquisadores têm desenvolvido uma quantidade significantede estudos para investigar aspectos relacionados a reconfiguração de SPL em tempo deexecução, que é tratada como parte da derivação do produto chamada derivação dinâmica(Parra et al., 2009).

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 et al., 2005; Gomaa and Saleh, 2006; Hallsteinsen et al., 2006; Lee,2006). A partir da utilização dos mesmos critérios descritos por da Silva et al. (2013)pode-se observar uma crescente, apesar de pequena, produção bibliográfica no decorrerdos anos abordando a temática de derivação dinâmica (Figura 2.1).

No entanto, Buregio et al. (2010) afirma que para a área de DSPL a maior parte das

12


contribuições estão relacionadas a proposição de soluções, em sua maioria concentradasno desenvolvimento de metodologias. Ao mesmo tempo que não são comuns de seremencontrados 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 deda Silva et al. (2013), no que tange aos estudos a respeito de derivação dinâmica levandoà conclusão de que 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 entres os anos de 2005 e 2013 queapresentaram contribuições relevantes para a área de derivação dinâmica em DSPL emordem cronológica. O objetivo desta apresentação é expressar a evolução das técnicas dederivação dinâmica ao longo do tempo.

Estudos em Derivação Dinâmica

Kim et al. (2005) desenvolveram, para um contexto de uma DSPL de jogos para dis-positivos 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 propostafaz uso de uma linguagem específica de domínio para descrever o sistema de maneiraestática e uma linguagem para descrever modelos arquiteturais que especificam as regrasque informam quais componentes devem ser adicionados ou removidos da arquitetura doproduto.

A abordagem “Dynamic Client Application Customization” (DAC) criada por Gomaaand Saleh (2006) é baseada na customização dos objetos da interface com o usuário emtempo de execução baseada em features selecionadas e valores de variáveis parametriza-das. Esta abordagem consiste de uma arquitetura de SPL customizável baseada no padrãoarquitetural cliente/servidor, onde a aplicação cliente contém apenas objetos de interfacecom o usuário e um objeto customizador. A aplicação do servidor contém todos os web

13


services responsáveis por prover as funcionalidades do sistema e o suporte ao banco dedados.

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 modelagemda linha 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 deaplicação e utilizadas para customizar dinamicamente a arquitetura e implementação daaplicação.

Hallsteinsen et al. (2006) criaram a abordagem MADAM para construção de sistemasadaptativos. O foco da abordagem está em sistemas distribuídos acessados por dispositi-vos móveis onde a derivação dinâmica ocorre a partir de uma arquitetura de referência.A plataforma arquitetural que suporta a abordagem pode ser vista na Figura 2.2. Onúcleo dessa arquitetura (Core) é composto por um middleware entre os componentese a plataforma, e oferece serviços para o gerenciamento de componentes, instâncias erecursos. O Context Manager é responsável por monitorar um conjunto de contextosrelevantes no ambiente do sistema enviando e reunindo informações que são utilizadaspelo Adaptation manager.

O Adaptation manager é responsável pela avaliação do impacto das mudanças nocontexto sobre a aplicação e determinar quando uma adaptação deve ser efetuada, selecio-nando as variantes que melhor atendem as novas necessidades impostas pelo contexto. Oconfigurador (Configurator) é responsável por realizar a configuração inicial da aplicaçãoe as reconfigurações, observando quais variantes devem ser instanciadas e desativadaspara alcançar o estado determinado pelo Adaptation manager.

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

14


Em uma abordagem orientada a features e sistemática de desenvolver core assets

reconfiguráveis dinamicamente, Lee (2006) desenvolvera um reconfigurador que acumulaas funções de monitorar e gerenciar a configuração de um produto em tempo de execução.Este autor acredita que a derivação dinâmica pode ser realizada agrupando features

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

Baseado no paradigma SPL Cetina et al. (2008) criou um método para desenvolversistemas pervasivos dinamicamente adaptáveis. Neste estudo afirma-se que a reconfigu-raçã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. Areutilização desta análise é utilizada como entrada para um reconfigurador que em tempode execução utiliza o 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 emtempo de execução. O primeiro artefato a ser gerado para a utilização dessa abordagemé o conjunto de componentes em forma de plugin. Então uma ferramenta chamadaDecisionKing é empregada para gerar um modelo de variabilidades e outra ferramentade nome ProjectKing permite que sejam criados cenários para configurações específicasmodelo de variabilidades. Assim, um guia de configuração processa os modelos devariabilidades com seus respectivos cenários e apresenta as possíveis decisões a seremtomadas em uma interface amigável para o usuário do software. Por fim, um mecanismode descoberta na plataforma de plugins permite ligar e desligar os componentes baseando-se nas decisões do usuário.

Pukall et al. (2009) desenvolveu a metodologia chamada “Feature-oriented RuntimeAdaptation” que permite a atualização de programas em tempo de execução através daevolução dos recursos de uma SPL de forma dinâmica. Toda a metodologia é baseadaem susbstituições de classes em Java utilizando “Java HotSwap” e reimplementação docorpo de métodos.

O relacionamento entre SPL e computação orientada a serviço foi claramente utilizadopor Yu et al. (2010a) ao apresentarem uma metodologia para a construção de aplicaçõesbaseadas em serviços para ambientes heterogêneos e dinâmicos. A metodologia é divididanas 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 arquitetura

2Enterprise Resource Planning

15


inspirada 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 compiladorJava no estudo de Sunkle and Pukall (2010). Este estudo utilizou o FeatureJ, que é umaabordagem de implementação de SPL, com uma representação de features e variabilidadescomo se fossem tipos de uma linguagem de programação. Esta representação é utilizadacomo entrada para a derivação do produto em tempo de compilação e execução. JáGünther and Sunkle (2010) apresentaram uma maneira de modelar, implementar features,realizar a composição dinâmica destas em tempo de execução e modificar a SPL e suasvariantes utilizando a linguagem de programação Ruby.

No âmbito de sistemas de cuidados com a saúde, Carvalho et al. (2010) desenvolveuuma abordagem para gerenciamento dinâmico de variabilidades baseada em contratosarquiteturais. Estes contratos, especificados na linguagem CBabel, são instanciados emtempo de execução de acordo com as variações no contexto.

Lee and 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 umaanálise orientada a features e um framework orientado e sensível a qualidade dos serviçosde um SPL. Os autores acreditam que features podem ser mapeadas em serviços.

Alferez and Pelechano (2011) desenvolveu um método para projetar e implementarweb services autônomos e sensíveis ao contexto em SPL. Os autores argumentam quese web services forem caracterizados por features, então a ativação e desativação defeatures em tempo de execução pode guiar a reconfiguração autonômica de composiçãode serviços a depender de mudanças no contexto. Neste caso, os produtos são umacomposição de serviços. Para que seja possível uma composição de serviços, os autoressugerem a criação de um modelo de composição feito a partir de um diagrama UML deatividades. Este modelo ilustra os web services e os fluxos de sequência entre eles queestabelece a ordem na qual cada web services deve ser ativado.

Gomaa and 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 monitora-mento que verifica continuamente o estado do sistema em execução e o encaminha para oserviço de calibragem, que percebendo uma situação no contexto que necessite de umaação envia uma requisição ao dispositivo de seleção dinâmica de features. Este dispositivodetermina se existe a necessidade de mudanças na configuração que está sendo executada.Ele determina dinamicamente as modificações necessárias para o modelo de features daaplicação e envia a nova seleção de features para o serviço de gerenciamento de mudança.

16


Fica a cargo do serviço de gerenciamento de mudanças determinar a diferença entrea nova seleção de features e a original, determinar os componentes e conectores queprecisar sem adicionados ou removidos e gerar uma sequência de comandos de adaptaçãoque correspondem as mudanças que precisam ser efetuadas.

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 abordagemconsidera que a criação do produto inicial é realizada através de adaptações no projeto.Uma vez criado e entregue o produto pode ser objeto de adaptações dinâmicas. Aabordagem, que utiliza adaptação a partir de aspectos, é feita em duas entidades principais.A primeira é um metamodelo unificado de aspectos utilizados para definir tanto adaptaçõesem tempo de projeto quanto em tempo de execução.A segunda é uma plataforma querealiza de modo transparente as adaptações expressadas 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çõesnecessárias para 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 realizadaspara que esses elementos possa 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 eimplementação. Esta abordagem permite que desenvolvedores mudem flexivelmente otempo de bind de cada feature usando o mesmo código como base. As unidades de bind

são geradas estaticamente para reduzir a sobrecarga do processo de derivação dinâmica.Os autores garantem a composição segura do bind dinâmico utilizando regras de compo-sição descritas em um modelo de features que contém as regras de reconfiguração querepresentam as transformações de código que são utilizadas para a criação das unidadesde bind dinâmico.

Shen et al. (2011) propôs um método orientado a features para suportar reconfiguraçãode variabilidades em tempo de execução. Neste estudo é introduzido o conceito de modelode funções, que é um nível intermediário entre as variantes das features e suas respectivasimplementaçõ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 asvariabilidades podem ser adaptadas para estar disponíveis ou indisponíveis quando areconfiguração em tempo de execução é realizada. Como as funções não podem serremovidas da aplicação em execução, o gerenciamento dessas interações com as funçõesmapeadas apoia a reconfiguração.

17


Damiani et al. (2012) apresenta para este campo de estudo os conceitos de Delta

Oriented Programing (DOP). Um produto em particular em uma DOP SPL é geradoaplicando-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 definequais configurações o sistema pode adaptar em tempo de execução e descreve comoobjetos alocados na pilha precisam ser realocados.

O estudo de Baresi and Milano (2012) demonstra uma maneira de enriquecer ascomposições da Business Process Execution Language (BPEL) com o gerenciamentodinâmico de varabilidades. A solução proposta utiliza a Common Variability Language

(CVL) para aumentar os processos BPEL com variabilidades, que torna possível a criaçãode DSPLs e uma versão dinâmica da BPEL para gerenciar e executá-las.

Em 2013 dois estudos a respeito da derivação dinâmica foram concluídos pelo “Ad-vanced System and Software Engineering Research Technologies Lab”(AssertLabs): noprimeiro (da Silva et al., 2013), dentre outras coisas, pode-se verificar que no contexto deDSPLs orientadas a serviço existem algumas abordagens para a reconfiguração dessesserviços em tempo de execução com base em atributos de qualidade. No entanto nenhumadessas abordagens utiliza acordos de nível de serviços ou demonstra evidências de quepodem ser reutilizadas em DSPLs de domínios distintos.

O segundo estudo foi uma dissertação de mestrado (de Oliveira Martins, 2013), ondefoi desenvolvido o DYMOS framework com o propósito de gerenciar variabilidades dinâ-micas em SPL orientadas a serviços e sensíveis ao contexto. Este framework possibilitaque serviços sejam adicionados ou removidos da configuração do produto em tempo deexecução por meio de mecanismos de auto-implantação, de modo que o funcionamentodo sistema não seja afetado e que tais modificações sejam aplicadas e reconhecidasimediatamente. Possui também um mecanismo de descoberta de serviços, que provê umaabstração entre o cliente e o serviço, permitindo efetuar orquestração de serviços e agregarcritérios para a seleção do serviço mais adequados, 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 comu-nidade de reuso de software não é difícil encontrar na literatura estudos bem sucedidosque tratam serviços como features, onde a determinação de quais serviços vão comporo produto é feita através do modelo de features selecionado para cada produto a serderivado. No entanto, este mapeamento estático de serviços, não atende aos requisitos de

18

2.5. CONCLUSÕES

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 cons-trução e decomposição (Parra et al., 2009). Porém as características antagônicas dessesparadigmas (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çãoocorre no momento da derivação do produto.

Desta forma, DSPLs tradicionais podem também não apresentar dificuldades quantoa este antagonismo. Não obstante, certamente este problema afetará uma DSPL orientadaa serviço que precisa decidir com base em alguma análise (Ex.: prioridade, resposta aocontexto e QoS) quais serviços devem ser plugados em tempo de execução. Visto quederivaçã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 et al. (2010a), a DSPL orientada a serviços faz a análise de quaisserviç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 ondeas features são mapeadas em serviços. Esta DSPL realiza uma análise e um planejamentoem tempo de execução baseados em mudanças contextuais para definir quais features, econsequentemente quais serviços, devem compor o produto.

Em um estudo de cunho exploratório posterior (Lee and Kotonya, 2010) esta aborda-gem é modificada fazendo com que a análise em tempo de execução seja feita com baseem acordos de nível de serviço impostos pela linha de produto. Onde, assim como nosestudos de Alferez and Pelechano (2011) e Gomaa and Hashimoto (2011), sempre queocorre uma quebra no acordo de nível de serviço o framework procura por outro serviçoque satisfaça as condições desejadas. Não foram expressas no estudo detalhes sobre quaisseriam essas condições (atributos de QoS) ou como a negociação é feita.

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 motivacionaldescrito na Seção 1.1, ou seja, que definam os serviços que vão compor a DSPL orientadaa serviço. Com base em uma análise de atributos de QoS realizada a cada requisição dousuário.

19


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-lhea capacidade de avaliar e selecionar serviços com base em atributos de qualidade.

20

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 conheci-mento acumulado e sistematizado, como é o caso da área de derivação dinâmica em DSPLrelatado no Capítulo 2. Este tipo de estudo também possui uma natureza de sondagem enão comporta hipó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 desenvol-vido por de Oliveira Martins (2013). Cada uma das fases desse estudo exploratório sãoapresentadas a seguir.

Vale ressaltar que o framework DYMOS trabalha com features em dois níveis deabstração distintos. No primeiro nível estas features são compostas de uma chamada a umserviço no lado cliente da aplicação e um contrato existe no lado servidor. No segundonível de abstração as features 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 tratadaspor este nome, enquanto as do segundo nível serão tratadas como serviços ou serviçosWeb. Ainda assim, o framework possui um serviço Web chamado “ApplicationService”que assim como os outros elementos da arquitetura exibida na Seção 3.1 será tratado

21

CAPÍTULO 3. DYMOS QOS

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 “ServiceCon-text”, o contêiner OSGi e três elementos descritores: o “ServiceDescriptor” que descreveo que pode ser plugado em tempo de execução ao produto da SPL, o “VariabilityDescrip-tor” que descreve os pontos de variação e, finalmente, o “WSDescriptor” que descreve oWSDL de cada serviço Web.

Figura 3.1 DYMOS - Diagrama de Pacotes (de Oliveira Martins, 2013)

O “ServiceDescriptor” utiliza um arquivo XML como o apresentado no trecho decódigo 3.1 para descrever os serviços. Este XML contém uma lista de campos estruturadospara cada serviço Web como um campo “Id” fazendo o papel de identificador exclusivo, oscampos “serviceSpec” e “serviceImpl” que contém os valores que identificam a interfacee uma implementação para o serviço. Cada descrição de serviço tem, opcionalmente,uma lista de serviços alternativos que possuem uma referência para outro serviço Web.

Código Fonte 3.1 XML de Serviços do DYMOS

<?xml version="1.0"?>

<services>

...

<service id="imageService"

22

3.1. ANÁLISE EXPLORATÓRIA

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 aserviços. Este conjunto de referências é responsável por manter os serviços ativos quandoa variação estiver ativada.

Código Fonte 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 quenão são descritos pelo “ServiceDescriptor”. E que são específicos para cada implementa-ção de um serviço como “ServiceName”, “PortType” ou “Target Namespace”. Assim,“WSDescriptor” permite maior flexibilidade ao framework, acrescentando características

23


dinâmicas e levemente acopladas.

O componente “ServiceContext” faz uso de todos os componentes descritores. Autilização destes componentes permite ao “ServiceContext” obter todas as informaçõesdescritas na forma de objetos Java, auxiliando-o no gerenciamento de variabilidade eserviços descritos. Esta gestão utiliza as informações sobre a variabilidade e serviçospara manipular o contêiner OSGi.

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

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 reconfi-guração de variabilidades ocorre em resposta a uma variação no contexto no lado clienteda aplicação que resulta em uma reconfiguração. Em seguida, o DYMOS a partir da suaoperação de reconfiguração adapta o contexto dos serviços (lado servidor) para atendera necessidade da reconfiguração no lado cliente. A sequência desta operação pode servisualizada na Figura 3.3.

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. Aseleçã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“getEndPoint” do “ApplicationService” (ver Figura 3.2). O método em questão recebecomo parâmetro o ID do serviço desejado que é passado para o “SeviceContext”, onde arequisição é tratada com base nas informações passadas pelo “ServiceDescriptor”. Logo,o ID passado como parâmetro deve ser o ID de um serviço descrito no XML de serviços.

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

24

3.1. ANÁLISE EXPLORATÓRIA

Figura 3.2 DYMOS - Diagrama de Sequência - Reconfiguração de Serviços (de Oliveira Martins,2013)

• 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 definidano atributo “priority”;

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

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 deencontrar um serviço adequado. Após a seleção do serviço Web, o “ServiceContext”interage com o componente WSDescriptor passando como parâmetro o endereço onde oserviço selecionado encontra-se e recebendo como resposta o end point, o name space eo nome do serviço. Estes dados são retornados para o lado cliente da DSPL.

Outra operação do DYMOS é a “ContextHotBuild”. Esta é a operação responsável pe-las operações de bind em tempo de execução. Todos os serviços Web que são tratados pela

25


Figura 3.3 DYMOS - Diagrama de Sequência - Descoberta de Serviços (de Oliveira Martins,2013)

DSPL como features de segundo nível estão empacotados em bundles OSGi, tornandopossível que eles sejam ativados e desativados, plugados e desplugados da DSPL sem anecessidade de que o software seja recompilado. Sendo assim, fica sob a responsabilidadedo componente “OSGi Container” gerenciar a operação de “ContextHotBuild” a partirdo gerenciamento do ciclo de vida dos bundles.

3.2 Intervenção Exploratória

Visto que, na perspectiva de Khezrian et al. (2010), por um lado a descoberta de serviçospermite 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 outro lado, a descoberta de serviços no DYMOS apesar de efetiva pode não ser aideal ao considerar apenas um critério para a seleção dos serviços.

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

26

3.2. INTERVENÇÃO EXPLORATÓRIA

execução na fase de design da aplicação. Este cenário pode caracterizar uma perda dedinamicidade para a DSPL. Com base nesta observação e no intuito de atingir o objetivode propor uma abordagem de seleção em tempo de execução das características que irãocompor uma DSPL e com base em uma análise de seus respectivos atributos de qualidade,propõe-se estender o DYMOS, passando a denomina-lo de 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 acordocom a prioridade arbitrada. Propõe-se que a seleção de serviços ocorra de acordo com aqualidade dos serviços disponíveis no lado servidor no momento em que a solicitação érealizada no lado cliente.

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 sempreque realizada uma requisição a um serviço no lado cliente, o serviço retornado serásempre o que tiver a melhor avaliação dos atributos de qualidade no nível de serviçoexigido.

Para tanto, dois novos componentes foram adicionados a arquitetura do DYMOS:o “ServiceLevelProvider” e o “Broker”, como pode ser visualizado na Figura 3.4. Oprimeiro armazena informações contextuais sobre os serviços Web de forma estruturadaem um arquivo XML e atualiza essas informações de acordo com as mudanças queocorrem no contexto. O componente “Broker” é responsável por analisar os atributos dequalidade para cada serviço em tempo de execução durante a descoberta de serviços.

Figura 3.4 DYMOS QoS - Diagrama de Pacotes

27


A fim de que seja possível ao “Broker” realizar essa análise, o componente “Service-LevelProvider” armazena em um XML alguns atributos de qualidade, tais como nível deserviço, capacidade máxima, a capacidade atual, tempo de resposta e custo. A análisedo “Broker” calcula a utilidade (Yu and Lin, 2005) de cada serviço no nível de serviçoescolhido e envia esta informação para o componente “ServiceContext”, que continuasendo o principal responsável pelo processo de descoberta de serviços.

Esta intervenção requer uma modificação no componente “ServiceContext” de modoque durante a execução do método “findAlternativeService” a prioridade descrita no XMLde serviços deve ser desconsiderada, os atributos de qualidade de cada serviço devem serrecuperadas e a utilidade de cada serviço deve ser calculada.

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

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

28

3.2. INTERVENÇÃO EXPLORATÓRIA

está presente no contêiner OSGi, o “ServiceContext” requisita ao “ServiceLevelProvider”a lista dos serviços alternativos com seus respectivos valores para os atributos de qualidadeestruturados dentro de objetos “AlternativeServiceQoS”.

Os atributos de qualidade têm valores distintos para cada serviço em cada nívelde serviço, como é apresentado no Código 3.3 que representa o XML de atributos dequalidade utilizado pelo “ServiceLevelProvider”. Os atributos de qualidade dos serviçosutilizados nessa abordagem são: custo, capacidade máxima e atual, nível, tempo deresposta, confiabilidade e disponibilidade.

Código Fonte 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 ressaltarque o atributo de custo representa o custo de um determinado serviço em um dadonível de serviço. Esta abordagem não determina como o custo do serviço deve serdefinido, possibilitando a utilização do DYMOS QoS de acordo com diversos modelosde precificação.

Os atributos de capacidade máxima e atual representam respectivamente quantos

29


clientes ao mesmo tempo podem utilizar e quantos estão utilizando um serviço em umdeterminado nível de serviço. O atributo nível refere-se ao nível de serviço ao qual osdemais atributos de qualidade pertencem. O atributo de tempo de resposta armazena ovalor de qual tempo de resposta em microssegundos deve ser esperado de um serviço nonível de serviço em questão.

Os atributos de nome e especificação do serviço, tem função meramente identifica-dora. Enquanto os atributos de confiabilidade e disponibilidade são baseados em dadoshistóricos. O valor do primeiro é incrementado sempre que o serviço requisitado respondea uma requisição em tempo igual ou menor ao especificado no atributo de tempo deresposta e decrementado quando ocorre o contrário. O atributo de disponibilidade éincrementado sempre que uma requisição a um serviço tem uma resposta e decrementadoquando 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é derivado das abordagens de Chen et al. (2003); Yu and Lin (2004, 2005), onde cadaprovedor de serviços Web oferece diversos níveis de serviço para cada funcionalidade.

Nesta abordagem fica sob a responsabilidade do “Broker” coletar as informações arespeito dos candidatos a provedores de serviço. Para tanto, este componente, apanha asdefinições de serviço e nível de serviço dos clientes e então realiza uma verificação noscompromissos de qualidade oferecidos pelos serviços.

O “Broker” utiliza uma função para a otimização da seleção dos serviços Web cha-mada por Yu and Lin (2004, 2005) de função de utilidade. Esta função é baseada emum conjunto de parâmetros que englobam informações estáticas (nível de serviço), asnecessidades de qualidade do lado cliente e a capacidade dinâmica do servidor (carga).

Para que seja possível o entendimento da função de utilidade algumas definiçõesprecisam ser esclarecidas. A primeira delas é que serviços Web que oferecem a mesmafuncionalidade podem ter características não funcionais distintas. O conjunto dessesserviços que oferecem a mesma funcionalidade é chamado de classe de serviço e denotadopor S, sendo cada serviço de uma classe denotado individualmente por s. O nível deserviço oferecido por um único serviço Web é denotado por l. A confiabilidade é umarestrição de qualidade a respeito do atraso no provimento 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 quecada serviço Web oferece é obtido a partir da definição L(s) e o tempo de serviço é

30

3.3. CONCLUSÕES

denotado por e(s, l). As definições adotadas a respeito da carga de cada serviço sãoCmax(s, l) e Ccur(s, l), onde o primeiro denota a capacidade máxima e o segundo a cargaatual em um determinado nível de serviç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 paraque os serviços selecionados tenham uma baixa carga, oferecendo assim menores temposde resposta reais. Isso implica em um balanceamento global das cargas dos serviçosevitando 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 nonível de l, avgb e avgc são o benefício médio e o custo médio para os serviços disponíveisno nível de serviço escolhido, e, finalmente, stdb e stdc são o desvio padrão de benefícioe custo. O objetivo dessa função é maximar o benefício e minimizar o custo no momentode 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 deserviços do DYMOS e a classificação das features utilizadas por este. Partindo destaanálise foi possível construir uma abordagem de descoberta de serviços com base naanálise de atributos de QoS.

A análise implementada para a seleção de serviços é fundamentada na idéia de que umcomponente pode atuar como mediador avaliando a necessidade do cliente e encontrandoum serviço que melhor se enquadre nesta necessidade. O trabalho do componentemediador (“Broker”) é regido pela relação custo-benefício especificada na forma defunções matemáticas definidas por Yu and Lin (2004, 2005). O próximo capítulo tratada de uma validação realizada com a abordagem aqui proposta para demonstrar a suaefetividade. Assim como é relatada uma avaliação da performance da mesma.

31

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

A fim de avaliar a abordagem proposta no Capítulo 3 foram desenvolvidas umavalidação e uma avaliação quantitativa, ambas apresentadas nesse capítulo. A primeira denatureza aplicada e exploratória quanto aos objetivos. Para esta procura-se demonstrar oDYMOS QoS em ação na DSPL Mobiline relatada no Capítulo 1.

A avaliação quantitativa é de natureza básica e descritiva no que diz respeito aosfins. Estudos descritivos, de uma maneira geral, expõem características de determinadapopulação ou de determinado fenômeno, podendo estabelecer correlações entre variáveise definir sua natureza. Não obstante, não tem compromisso de explicar os fenômenosdescritos sem excluir a possibilidade 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 DYMOSQoS, assim construindo os arquivos XML necessários aos componentes descritores e aoServiceLevelProvider.

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 sistemaoperacional Android e fornecem informações sobre os pesquisadores e os ambientes dolaboratório do grupo de pesquisas GREat da Universidade Federal do Ceará e do Centrode Informática da Universidade Federal de Pernambuco, respectivamente.

33

CAPÍTULO 4. AVALIAÇÃO

Estes aplicativos utilizam informações contextuais, como localização, perfil e pre-ferências do usuário visitante, assim como as requisições desencadeadas por este e ascaracterísticas do dispositivo móvel para adaptar seu próprio comportamento. Parte dascaracterísticas do produto que variam em tempo de execução e os core assets da SPLestão presentes nos dispositivos móveis, enquanto outras características que variam emtempo de execução são ligadas ao produto a 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 eFigura 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árioutilizando a 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âmicase a classe “ServiceEndpointFactory” que suporta a descoberta de serviços. Há também a

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

34

4.1. VALIDAÇÃO EXPLORATÓRIA

Figura 4.2 Cin Tour - Modelo de Features

classe “ServiceEndPoint” que cria objetos com a capacidade de armazenar o end point, onamespace e o nome do serviço Web.

O Código 4.1 apresenta como deve ser feita uma requisição a um serviço Web noDYMOS QoS. Primeiro é necessária a criação de um objeto “ServiceEndPoint” querecebe o retorno do método “getEndPoint()” da classe “ServiceEndPointFactory”. Estemétodo recebe como parâmetro o nome da variante ou da interface para o serviço desejadoe o número referente ao nível de serviço esperado.

Código Fonte 4.1 Descoberta de Serviços no Lado Cliente

...

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

...

35


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ço precisa ser atualizado. Isso é feito através de uma chamada para os métodosrequireLevel() e getServiceEndPoint() do serviço Web ApplicationService do framework

que ocorre por meio do método “getEndPoint” no lado cliente.

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

Código Fonte 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>



36

4.1. VALIDAÇÃO EXPLORATÓRIA

</service>

...

</services>

</variabilities>

Código Fonte 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 QoSService 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ãose faz necessária. Neste caso, uma requisição ao end point da variante “ImageService”

37


é feita no produto Mobiline. O “ServiceContext” utiliza os componentes descritoresdo framework para identificar a implementação e a especificação da variante. Assim, o“ServiceContext” verifica a disponibilidade 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, oprimeiro passo da validação foi concluído, restando para ser realizado o passo que utilizaa descoberta de serviços alternativos.

No que se refere ao segundo passo, este verifica se a seleção do serviço que substituiráo que está indisponível deixa de ocorrer de acordo com a prioridade arbitrada e passa aacontecer de acordo com a qualidade dos serviços disponíveis no momento da requisição.Fica eleito o serviç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 oend point desta variante é feito o “ServiceContext” requisita ao “Broker” uma lista deserviços alternativos e 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çoativo com a maior pontuação na funçã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 afunção de utilidade, como demonstrado na Tabela 4.1.

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 entede-semelhor 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 porum serviço sem implementação e ser colocado junto dos serviços alternativos. O queimplica no registro 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 umadecisão de 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 conside-

38

4.2. AVALIAÇÃO ESTATÍSTICA DESCRITIVA

radas objetivas e portanto diferentes observadores em outras visualizações encontrarãoos mesmos resultados aqui apresentados. Por se tratar de uma observação numéricaelimina-se a possibilidade de desacordo a respeito dos valores dessas variáveis (Wainer,2007).

A ausência de um conjunto de dados reais a respeito da performance de outrastécnicas de seleção de serviços no âmbito da área de DSPL cerceiou a possibilidade deexperimentação estatística para avaliar a abordagem proposta nesta dissertação. Diantedisto, optou-se pela criação de um benchmark com o intuito de aferir a performance doDYMOS QoS.

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

O identificador, o nome e a especificação dos serviços são dados categóricos. Paraesse tipo de dado não existe sentido em fazer outra operação a não ser a verificação dovalor dos mesmos. Esses dados tem a única função de identificar a qual serviço pertencemdurante o processo 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 custo e o tempo de resposta são medidas de razão e não possuem nenhuma função decategorização, mas operações matemáticas com estes fazem sentido.

Esses valores foram gerados automaticamente a partir de um programa escrito emJAVA. Foi definido nesse programa que o identificador deveria ser sequencial e único, acapacidade máxima e atual são inteiros positivos não maiores que 50, o tempo de respostarepresentados em milissegundos também é um inteiro positivo não maior que 61000,51000, 31000 e 11000 para os níveis de um a quatro respectivamente. O custo é sempreum fração positiva maior que zero e menor que dez.

A Figura 4.3 apresenta graficamente a distribuição do tempo de resposta máximooferecido por cada serviço. Nesta é evidenciada a concentração de menores tempos deresposta nos níveis 3 e 4, ao passo que os maiores tempos de resposta encontram-se nosníveis 1 e 2. Contudo, é notório mesmo os níveis de serviço 1 e 2 apresentam tempos deresposta máximos tão baixos 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

39


valores em relação aos custos praticados pelos serviços Web. Tanto as capacidades quantoos custos da amostra gerada apresentam médias e medianas similares entre si, o que podeser um indicativo de que estes dados tem uma distribuição normal de probabilidade.

Tabela 4.2 Capacidades Máximas e AtuaisMédia Mediana Desvio Padrão

Level 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 CustoLevel 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 eregistrados nos arquivos XML dos descritores do DYMOS QoS. Após isso 100 execuçõesforam realizadas com 4 subgrupos da população de serviços. O primeiro subgrupo possuía5 serviços, o segundo 10, 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 com6 GB de memória RAM, sistema operacional Windows 8, Java Virtual Machine (JVM) e

40

4.3. CONCLUSÕES

Java Development Kit (JDK) 1.7. Antes da extração dos tempos de execução foi realizadoo Warm Up do ambiente, executando cada subgrupo da população de serviços duasvezes utilizando como parâmetro para a JVM -XX:+PrintCompilation, -verbose:gc e-XX:CICompilerCount=1.

Para que se pudesse ter uma medida mais exata do tempo de execução do DYMOSQoS durante o processo de seleção de serviço com bases nos atributos de qualidadeapresentados as medidas foram feitas em nanosegundos. A Figura 4.4 apresenta odesempenho para cada execuçã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 é representadopelo percentual da quantidade de tempo de execução média da seleção de serviços noDYMOS QoS com relação ao desempenho anterior.

Como pode ser observado, o tempo de execução para o subgrupo com 50 serviçosWeb foi 84% menor em relação ao subgrupo com 100 serviços e 472% maior com relaçãoao subgrupo com 10 serviços. Esta informação evidencia que a abordagem utilizada podenão ser escalonável.

O mesmo procedimento de avaliação foi realizado com o DYMOS Framework com adiferenç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 escalabili-dade apresentado no DYMOS QoS não é oriundo do DYMOS Framework, mas sim daintervenção exploratória realizada nesta dissertação.

Tabela 4.4 Desempenho do Dymos QoSQauntidadede Seviç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

4.3 Conclusões

Este capítulo apresentou uma validação exploratória da abordagem proposta e uma avali-ação estatística de desempenho. Pode-se concluir a partir da validação que a abordagem

41


Tabela 4.5 Desempenho do DymosQauntidadede Seviç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

Figura 4.4 Desempenho

proposta é funcional para a MobiLine, exigindo pouco esforço para ser adotada pelaDSPL. Vale salientar, no entanto, que apesar dos indícios de que a abordagem seja com-patível com outras DSPLs, esta não é uma afirmação que possa ser feita com base nestavalidaçã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 QoSque a abordagem pode não ser escalonável. Fato devido ao tempo gasto para a descobertados serviços em classes grandes de serviço que se apresenta relativamente maior do queo esperado quando comparado com classes de serviços menores.

Vale salientar ainda, que os dados utilizados para a execução da avaliação de perfor-mance são dados gerados. Portanto existe um risco de que esses dados apresentem um viésque pode ser considerado com uma ameaça a validade do estudo. Outra limitação é o fatode não estar disponível na literatura nenhum outro benchmark ou abordagem relacionadadisponível para uma comparação dentro de um desenho experimental adequado.

42

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 breveexplanação a respeito dos trabalhos futuros. Esta dissertação foi iniciada com umacontextualização a respeito da temática abordada, junto com a problematização e adescrição dos métodos utilizados para que os objetivos fossem alcançados no Capítulo 1.Neste mesmo capítulo ficou estabelecido que o objetivo deste trabalho era propor umaabordagem de seleção, em tempo de execução das características que irão compor a DSPLcom base em uma análise de seus respectivos atributos de qualidade.

No Capítulo 2 foram explanados os termos que pertencentes à área de SPL e SOC,para mlehor compreensão e aplicação destes. Posteriormente, foi apresentado o estadoda arte no que tange à derivação dinâmica em DSPL, elencando os estudos que jáforam publicados a respeito na área em ordem cronológica. Este capítulo encerrou comuma discussão em torno das limitações das contribuições dos estudos que tratam sobrederivação dinâmica em DSPLs orientadas a serviço, apresentando a lacuna na qual estapesquisa 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

43

CAPÍTULO 5. CONCLUSÃO

são apresentadas as modificações realizadas no DYMOS e a inclusão dos componentesresponsáveis pela realização da seleção de serviços em tempo de execução com base nosestudos de Chen et al. (2003); Yu and Lin (2004, 2005).

No Capítulo 4 ocorre tanto a validação exploratória quanto a avaliação estatísticadescritiva da abordagem proposta. A partir desse pode-se concluir que a abordagemapresentada funciona para a linha de produto na qual foi validada, sendo melhor utilizadacom pequenas quantidades 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 baseem uma análise de seus respectivos atributos de qualidade. Esta abordagem utiliza-se de procedimentos que já estavam presentes no processo de derivação de produtosda Mobiline, agregando apenas como responsabilidade do engenheiro de software anecessidade de descrever os atributos de qualidade dos serviços.

Outra contribuição é o fornecimento de um mecanismo que permite a seleção deserviços com base na abordagem de Chen et al. (2003); Yu and Lin (2004, 2005). Estemecanismo será licenciado como código aberto e disponibilizado no site do autor destadissertação1 . O benchmark utilizado para a avaliação da proposta é de domínio público edisponibilizado junto com o software sob a mesma licença, caracterizado assim a ultimacontribuição desta dissertação.

5.2 Limitações

Wazlawick (2009) classifica em cinco categorias os estilos de pesquisa correntes emCiência da Computação: apresentação de um produto, apresentação de algo diferente,apresentação de algo possivelmente melhor, apresentação de algo reconhecidamentemelhor e apresentação de uma prova. Dentro dessa classificação esta dissertação enquadra-se na categoria de “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 deexecução em uma DSPL orientada a serviços. Segundo o mesmo autor (Wazlawick,2009), este tipo de pesquisa é característico de áreas emergentes e os trabalhos sãoapresentados como comparações, mais comumente qualitativas, entre técnicas.

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

44

5.3. TRABALHOS FUTUROS

O estado da arte realizado na Seção 2.3.1 apresenta estudos como apresentação de umproduto ou de algo novo, o estágio mais básico da classificação de (Wazlawick, 2009).Estes estudos apresentam abordagens avaliadas qualitativamente dada as suas respectivasaplicações em determinadas linhas de produto. Não é possível assegurar portanto queestas mesmas abordagens funcionem em outros contextos e com outras linhas de produtos,o que é um indício de falta de maturidade na área de DSPL em derivação dinâmica emDSPLs orientadas a serviço.

Esta constatação é corroborada pelos estudos de Buregio et al. (2010); Alves et al.

(2009); Bencomo et al. (2010, 2012); da Silva et al. (2013), que ao mapearem a áreade DSPL observaram que a maioria dos estudos publicados até então apresentam comocontribuição o desenvolvimento de metodologias e propostas de soluções para situaçõesespecíficas. Estas soluções não estão disponíveis em local público para o uso por partedos outros pesquisadores, impossibilitando uma 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 dadosmais detalhados a respeitos de outras abordagens impossibilitou a criação de um desenhoexperimental rebuscado para o estudo aqui apresentado. Um benchmark de serviços eseus respectivos atributos de qualidade foi criado para mitigar esse problema e contribuirpara que a área de derivação dinâmica em DSPL evolua para um novo estágio dentro daclassificaçã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. Osindícios de normalidade probabilística relatados no final do Capítulo 4 pode indicar umviés o que se apresenta como uma limitação desse conjunto de dados.

Também foi realizada uma breve pesquisa na área de SOC a procura de abordagensque estivessem publicados os seus dados para que fosse possível a comparação. Masigualmente, não houve 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 oportu-nidades de pesquisa que não deve deixar de ser levado em consideração. Basta olhar paraas áreas de carência de estudos apontadas por Buregio et al. (2010); Alves et al. (2009);Bencomo et al. (2010, 2012); da Silva et al. (2013).

A área de DSPL como um todo e a derivação dinâmica em si carecem do desenvolvi-

45

CAPÍTULO 5. CONCLUSÃO

mento de modelos, ferramentas, algorítimos e discussões conceituais. Os principais tiposde estudos ausentes 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 abor-dagens de descoberta de serviços utilizando técnicas de composição ou de inteligênciaartificial, como algorítimos genéticos, por exemplo. A comparação entre essas outrastécnicas em diversos contextos 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, especificadopela IBM (2006). Diminuindo assim, a necessidade de intervenção humana na derivaçãodinâmica da DSPL 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 SocialMachines pode ter resultados científicos relevantes. Visto que a descoberta de serviçospoderia ser facilitada em um ambiente onde os mesmos já ofertem informações semânticasao seu próprio respeito.

Do ponto de vista mercadológico, tem se tornado frequente que sistemas de Internetsejam portados para dispositivos móveis utilizando tecnologias como HTML5 e JavaS-cript. Apesar de ser uma abordagem que representa um menor custo de desenvolvimento,sobretudo quando o sistema precisa ser executado a partir de diferentes sistemas operaci-onais, ela torna-se um impeditivo no que diz respeito ao uso de recursos do dispositivo ena programação de reconfiguraçõ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 foilançada em 2007 e deu os seus primeiros passos em 2013.

Uma investigação científica para o desenvolvimento de um mecanismo que permitaa reconfiguração dinâmica de artefatos de código em JavaScript pode ter resultadosmercadológicos relevantes no que diz respeito aos sistemas de Internet que estão sendoportados para dispositivos móveis.

46

Referências Bibliográficas

Abbas, N. (2011). Towards autonomic software product lines. volume 46.

Abbas, N., Andersson, J., and Weyns, D. (2011). Knowledge evolution in autonomicsoftware product lines. page 1, New York, New York, USA. ACM Press.

Alferez, G. H. and Pelechano, V. (2011). Context-Aware Autonomous Web Services inSoftware Product Lines. pages 100–109. Ieee.

Ali, R., Chitchyan, R., and Giorgini, P. (2009). Context for goal-level product linederivation.

Alves, V., Schneider, D., Becker, M., Bencomo, N., and Grace, P. (2009). Comparitivestudy of variability management in software product lines and runtime adaptablesystems.

Baresi, L. and Milano, P. (2012). Service-Oriented Dynamic Software Product Lines.Number Cvl, pages 42–48.

Bencomo, N., Lee, J., and Hallsteinsen, S. (2010). How dynamic is your DynamicSoftware Product Line?

Bencomo, N., Hallsteinsen, S., and Almeida, E. (2012). A View of the Landscape ofDynamic Software Product Lines. pages 1–1.

Buregio, V., Almeida, E., and Meira, S. (2010). Characterizing Dynamic SoftwareProduct Linesâ A Preliminary Mapping Study. pages 53–60.

Carvalho, S. T., Loques, O., and Murta, L. (2010). Dynamic Variability Management inProduct Lines: An Approach Based on Architectural Contracts. pages 61–69. Ieee.

Cetina, C., Fons, J., and Pelechano, V. (2008). Applying Software Product Lines to BuildAutonomic Pervasive Systems. Number ii, pages 117–126. Ieee.

Chen, H. C. H., Yu, T. Y. T., and Lin, K.-J. L. K.-J. (2003). QCWS: an implementation ofQoS-capable multimedia Web services.

da Silva, J. R. F., da Silva, F. A. P., do Nascimento, L. M., Martins, D. A., and Garcia,V. C. (2013). The dynamic aspects of product derivation in dspl: A systematic literaturereview. In Information Reuse and Integration (IRI), 2013 IEEE 14th International

Conference on, pages 466–473.

47

REFERÊNCIAS BIBLIOGRÁFICAS

D’Ambrogio, A. (2006). A model-driven wsdl extension for describing the qos ofwebservices. In Web Services, 2006. ICWS ’06. International Conference on, pages 789–796.

Damiani, F., Padovani, L., and Schaefer, I. (2012). A Formal Foundation for DynamicDelta-Oriented Software Product Lines. pages 1–10.

de Oliveira Martins, D. A. (2013). DYMOS: Uma abordagem para suporte a variabilida-

des dinâmicas em Linhas de Produto de Software Orientado a Serviços e Sensível ao

Contexto. Master’s thesis, Universidade Federal de Pernambuco, Recife, Pernambuco,Brazil.

Deora, V., Shao, J., Gray, W. A., and Fiddian, N. (2006). Modelling quality of service inservice oriented computing. In Service-Oriented System Engineering, 2006. SOSE ’06.

Second IEEE International Workshop, pages 95–101.

Erl, T. (2005). Service-Oriented Architecture: Concepts, Technology, and Design.

Erl, T. (2007). SOA and Web Services. In SOA Principles of Service Design, chapter 3,pages 46–50. Prentice Hall.

Gomaa, H. and Hashimoto, K. (2011). Dynamic software adaptation for service-orientedproduct lines. page 1, New York, New York, USA. ACM Press.

Gomaa, H. and Saleh, M. (2006). Software Product Line Engineering and DynamicCustomization of a Radio Frequency Management System. pages 345–352.

Günther, S. and Sunkle, S. (2010). Dynamically adaptable software product lines usingRuby metaprogramming. pages 80–87, New York, New York, USA. ACM Press.

Hallsteinsen, S., Stav, E., Solberg, a., and Floch, J. (2006). Using Product Line Techniquesto Build Adaptive Systems. pages 141–150. Ieee.

Hallsteinsen, S., Hinchey, M., Park, S., and Schmid, K. (2008). Dynamic softwareproduct lines. Computer, (April), 93–95.

IBM (2006). An architectural blueprint for autonomic computing. Technical Report June.

Josuttis, N. (2007). SOA in Practice. O’reilly.

48


Khezrian, M., Wan Kadir, W. M. N., Ibrahim, S., Mohebbi, K., Munusamy, K., andTabatabaei, S. G. H. (2010). An evaluation of state-of-the-art approaches for webservice selection. In Proceedings of the 12th International Conference on Information

Integration and Web-based Applications & Services, iiWAS ’10, pages 885–889,New York, NY, USA. ACM.

Kim, M., Jeong, J., and Park, S. (2005). From product lines to self-managed systems: anarchitecture-based runtime reconfiguration framework. pages 66–72.

Lee, J. (2006). A Feature-Oriented Approach to Developing Dynamically ReconfigurableProducts in Product Line Engineering. pages 131–140. Ieee.

Lee, J. and Kotonya, G. (2010). Combining service-orientation with product line engine-ering. Number June, pages 35–41.

Lin, K.-J., Zhang, J., Zhai, Y., and Xu, B. (2010). The design and implementation ofservice process reconfiguration with end-to-end QoS constraints in SOA. Service

Oriented Computing and Applications, 4(3), 157–168.

Marinho, F. G., Andrade, R. M., Werner, C., Viana, W., Maia, M. E., Rocha, L. S., Tei-xeira, E., Filho, J. a. B. F., Dantas, V. L., Lima, F., and Aguiar, S. (2012). MobiLine: ANested Software Product Line for the domain of mobile and context-aware applications.Science of Computer Programming.

Mendonça, D. F., Rodrigues, G. N., Favacho, A., and Holanda, M. (2013). A SystematicMapping Study on Service Oriented Computing in the Context of Quality of Services.pages 39–48.

Moresi, E. (2003). Metodologia da pesquisa.

Papakos, P. and Rosenblum, D. S. (2010). VOLARE : Context-Aware Adaptive CloudService Discovery for Mobile Systems. pages 32–38.

Papazoglou, M. P. and Georgakopoulos, D. (2003). Introduction: Service-orientedcomputing. Commun. ACM, 46(10), 24–28.

Parra, C., Blanc, X., and Duchien, L. (2009). Context awareness for dynamic service-oriented product lines. pages 131–140.

Parra, C., Blanc, X., Cleve, A., and Duchien, L. (2011). Unifying design and runtimesoftware adaptation using aspect models. volume 76, pages 1247–1260. Elsevier B.V.

49


Pohl, K., Böckle, G., and van der Linden, F. (2005). Software Product Line Engineering:

Foundations, Principles, and Techniques.

Pukall, M., Siegmund, N., and Cazzola, W. (2009). Feature-oriented runtime adaptation.page 33, New York, New York, USA. ACM Press.

Rosenmüller, M., Siegmund, N., Apel, S., and Saake, G. (2011). Flexible feature bindingin software product lines. volume 18, pages 163–197.

Shen, L., Peng, X., Liu, J., and Zhao, W. (2011). Towards feature-oriented variabilityreconfiguration in dynamic software product lines.

Sunkle, S. and Pukall, M. (2010). Using reified contextual information for safe run-timeadaptation of software product lines. pages 1–6, New York, New York, USA. ACMPress.

Tang, M. and Ai, L. (2010). A hybrid genetic algorithm for the optimal constrainedweb service selection problem in web service composition. Computation (CEC), 2010

IEEE Congress on.

Wainer, J. (2007). Métodos de pesquisa quantitativa e qualitativa para a Ciência daComputação. Atualização em Informática. Org: Tomasz Kowaltowski; Karin Breitman.

Rio de Janeiro: Ed. PUC-Rio, pages 1–42.

Wazlawick, R. (2009). Metodologia de pesquisa para ciência da computação, volume 1.Elsevier Brasil.

Wolfinger, R., Reiter, S., Dhungana, D., Grunbacher, P., and Prahofer, H. (2008). Sup-porting Runtime System Adaptation through Product Line Engineering and Plug-inTechniques. pages 21–30. Ieee.

Yu, J., Lalanda, P., and Bourret, P. (2010a). An Approach for Dynamically Building andManaging Service-Based Applications. pages 51–58. Ieee.

Yu, Q., Rege, M., Bouguettaya, A., Medjahed, B., and Ouzzani, M. (2010b). A two-phaseframework for quality-aware Web service selection. Service Oriented Computing and

Applications, 4(2), 63–79.

Yu, T. and Lin, K. (2004). Service selection algorithms for Web services with end-to-endQoS constraints. In IEEE International Conference on E-Commerce Technology.

50


Yu, T. and Lin, K.-J. (2005). Service selection algorithms for Web services with end-to-end QoS constraints. Information Systems and e-Business Management, 3(2), 103–126.

51

Dymos QoS: Uma Abordagem para Seleção de Serviços em Tempo de Execução em Linhas de Produto de...

Documents

Transcript of Dymos QoS: Uma Abordagem para Seleção de Serviços em Tempo de Execução em Linhas de Produto de...