Você está na página 1de 75

“Dymos QoS: Uma Abordagem para Seleção de Serviços

em Tempo de Execução em Linhas de Produto de Software
Dinâmicas”
Por

Jackson Raniel Florencio da Silva
Dissertação de Mestrado

Universidade Federal de Pernambuco
posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao

RECIFE, FEBRUARY/2014

Universidade Federal de Pernambuco
Centro de Informática
Pós-graduação em Ciência da Computação

Jackson Raniel Florencio da Silva

“Dymos QoS: Uma Abordagem para Seleção de Serviços
em Tempo de Execução em Linhas de Produto de
Software Dinâmicas”

Trabalho apresentado ao Programa de Pós-graduação em
Ciência da Computação do Centro de Informática da Universidade 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 é uma
tarefa difícil para mim. Nenhum conjunto de códigos e seus respectivos significados
semânticos podem expressar um pedaço da minha alma. No entanto coloco aqui o meu
esforç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 atendeu
aqueles pedidos que fiz da forma como julgou ser melhor. Sua bondade e graça é tamanha
a ponto de me amar imensamente mesmo eu não sendo um exemplo de filho. Por isso
reservo 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 divino
aqui na terra. Sendo assim, agradeço aos meus pais, avós e irmã por me devotarem tanto
amor desde a minha mais tenra idade, além de me acompanhar a cada passo dado e me
ensinar tanto a cada dia.
Agradeço àquela que em breve será a minha companheira eterna por estar ao meu
lado nos últimos sete anos construindo dia-a-dia um relacionamento de duas pessoas
em 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 Pernambuco
por 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 em
produtos únicos. O Taylorismo e seus estudos de tempos e movimentos levaram para
a indústria a ideia de padronização dos produtos. Ford, tempos depois, inventou a
linha de produtos, onde a partir de então foi possível produzir em massa reduzindo o
tempo de entrega do produto e seus custos. No que tange a indústria de software, esta
apresenta tanto uma produção manufatureira quanto em massa que gera produtos que
sã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 Produto
de Software (SPL). No entanto, este paradigma de desenvolvimento não foi concebido
para suportar mudanças nos requisitos de usuários em tempo de execução. Diante deste
problema, a academia tem desenvolvido e proposto maneiras de estender o paradigma
de SPL de forma a permitir que essas reconfigurações dinâmicas do software sejam
suportadas. Surgiram deste esforço as Linhas de Produto de Software Dinâmicas (DSPL)
(Hallsteinsen et al., 2008). Levando em consideração este cenário, objetiva-se nesta
pesquisa contribuir com a área de DSPL apresentando uma nova maneira de pensar quais
características de uma DSPL devem ser ligadas em tempo de execução a um produto com
base em uma análise que mensura e valida atributos de qualidade em níveis de serviços
especificados pelo usuário. Para tanto foi necessária a revisão da literatura existente em
busca de meios de analisar atributos de qualidade de serviços em tempo de execução em
DSPL e o desenvolvimento exploratório de uma abordagem de reconfiguração da DSPL
utilizando-se das características dinâmicas do OSGi como base em tal análise. Com a
finalidade de validar a abordagem proposta, a mesma foi testada exploratoriamente em
uma DSPL para o domínio de guia de visitas móveis e sensível ao contexto, onde podese verificar a assertividade desta. Ao final da validação exploratória pode-se observar
a efetividade da abordagem proposta na DSPL na qual foi aplicada. No entanto, fazse necessário a execução de testes estatísticos para comprovar a hipótese de que esta
efetividade demonstrada é válida para outras DSPLs de outros domínios.
Palavras-chave: Linhas de Produto de Software, SPL, SPL Dinâmica, DSPL, Qaulidade
de Serviços

xi

Abstract

The industrial production before Taylor was essentially focused on manufacturing and
unique products. The Taylorism and his time and motion studies have led to the industry
the idea of standardization of products. Ford, sometime later, invented the product
line which from then on was possible to mass produce by reducing the delivery time
and product costs. Regarding the software industry, this presents both a manufacturing
and mass production that generates products that are denoted for Pohl et al. (2005) as
individual software and standard software: a clear influence of Fordism in the design
paradigm of Software Product Lines (SPL). However, this development paradigm was not
designed to support changing requirements of users at runtime. Faced with this problem,
the academy has developed and proposed ways to extend the paradigm of SPL in order
to enable such dynamic reconfigurations of software. From This effort emerged the
Dynamics 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 way
of thinking which features a DSPL should be connected at runtime to a product based on
an analysis that measures and validates quality attributes in service levels specified by
the user. For this it was necessary to review the existing literature searching means of
analyzing service quality attributes at runtime in DSPL and a exploratory development of
an approach for reconfiguration of DSPL using dynamic features OSGi based. In order to
validate the proposed approach , it was tested in a mobile and context-aware DSPL, where
we can verify this assertiveness. At the end of the exploratory validation we can observe
the 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 demonstrated
effectiveness 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
1

2

3

Introdução

1

1.1

Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2

Problemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.2.1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.3

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

5

1.4

Escopo Negativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.5

Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . .

6

Métodos

Revisão da Literatura

9

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

DYMOS QoS

21

3.1

Análise Exploratória . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.1.1

Operações do DYMOS . . . . . . . . . . . . . . . . . . . . . .

24

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

26

3.2.1

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

30

Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.2
3.3
4

xxiii

Avaliação

33

4.1

Validação Exploratória . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.2

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

38

xv

4.3
5

Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

Conclusão
5.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43
44
44
45

Referências Bibliográficas

xvi

47

Lista de Figuras

1.1

Cenário do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1
2.2

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

13
14

3.1
3.2

22

3.4
3.5

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

4.1
4.2
4.3
4.4

GreatTour - Modelo de Features
Cin Tour - Modelo de Features .
Tempo de Resposta . . . . . . .
Desempenho . . . . . . . . . .

3.3

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

25
26
27
28
34
35
40
42

xvii

Lista de Tabelas

4.1
4.2
4.3
4.4
4.5

Valores de QoS . . . . . . . .
Capacidades Máximas e Atuais
Custo . . . . . . . . . . . . .
Desempenho do Dymos QoS .
Desempenho do Dymos . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

37
40
40
41
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
3.2
3.3
4.1
4.2
4.3

XML de Serviços do DYMOS . . . . .
XML de Serviços do DYMOS . . . . .
XML de Atributos de Qualidade . . . .
Descoberta de Serviços no Lado Cliente
Services XML File . . . . . . . . . . .
QoS Attributes XML File . . . . . . . .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

22
23
29
35
36
37

xxiii

1
Introdução

- Quarenta e dois [...]
Eu verifiquei cuidadosamente e não há dúvida de que a resposta é essa.
Para ser franco, acho que o problema é que vocês jamais souberam
qual é a pergunta.
—DOUGLAS ADAMS (O Guia do Mochileiro das Galáxias)

O legado deixado por Ford com a criação da linha de produtos modificou os meios
de pensar a atividade industrial. No que tange à indústria de software, esta, apresenta
tanto uma produção manufatureira quanto em massa que gera produtos que são denotados
segundo Pohl et al. (2005) como software individual e software standard.
Denota-se, neste contexto, uma clara influência do fordismo na concepção do paradigma 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 si
pelo gerenciamento de um conjunto de características variáveis que diferenciam cada
produto.
O paradigma SPL é tradicionalmente divido em duas fases: a fase de Engenharia de
Linha de Produtos e a fase de Engenharia do Produto. Na primeira fase são definidas
e implementadas todas as características que estarão presentes em todos os produtos
chamadas de core assets, assim como as características variáveis que podem ou não
estar em um produto da SPL. Durante a fase de Engenharia de Produto, são selecionadas
para compor o produto além dos core assets as características variáveis que atendem a
determinados requisitos de usuários que justificam a sua escolha para a composição do
produto.

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 de
desenvolvimento não foi concebido para suportar mudanças nos requisitos de usuários
em tempo de execução. Diante deste problema, a academia tem desenvolvido e proposto
maneiras de estender o paradigma de SPL, de forma a permitir que essas reconfigurações
dinâmicas do software sejam suportadas. Surgiram deste esforço as Linhas de Produto de
Software 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óveis
sensíveis ao contexto dividida em dois níveis de abstração: base e específico. O nível
base possui características comuns a aplicações móveis e sensíveis ao contexto. Já o nível
específico é composto por características que pertencem a um determinado domínio de
negócio (Marinho et al., 2012).
Esta SPL é composta por dois produtos: o GREat Tour e o Cin Tour, que são guias de
visitas móveis sensíveis ao contexto derivados da MobiLine. Ambos são executados a
partir de dispositivos que possuem o sistema operacional Android e fornecem informações
sobre os pesquisadores e os ambientes do laboratório do grupo de pesquisas GREat da
Universidade Federal do Ceará e do Centro de Informática da Universidade Federal de
Pernambuco, respectivamente.
Estes aplicativos utilizam informações contextuais, como a localização, o perfil e as
preferências do usuário visitante. Assim como as requisições desencadeadas por este e as
caracterí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 da
SPL estão presentes nos dispositivos móveis, enquanto outras características que variam
em 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 de
adaptaçã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ção
está inserida. Onde, o funcionamento deste mecanismo pode variar desde baseado em
regras de condição ou até mesmo ser modelado como um problema de otimização.
O contexto varia entre tipos de aplicações e seus respectivos domínios. Na MobiLine
considera-se contexto tanto o ambiente físico no qual o dispositivo móvel está inserido,
1 Projeto

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

2

1.2. PROBLEMÁTICA

quanto as informações a respeito do estado do próprio dispositivo. Estas informações são
coletadas a partir dos sensores do dispositivo, sendo a localização geográfica adquirida a
partir da câmera ou do sensor de sinais NFC.
O estudo de de Oliveira Martins (2013) abordou a problemática do mecanismo de
reconfiguração e a descoberta de serviços criando uma ferramenta chamada DYMOS
framework. Este atua sempre que uma reconfiguração que ocorre no lado cliente exigindo
reconfigurações nos serviços no lado servidor. No entanto, este estudo seleciona os
serviços no lado servidor de forma arbitraria, sem realizar nenhuma análise nos serviços
que irão compor a DSPL. O que é tratado no trabalho como fora de escopo e possível
trabalho futuro.
Por outro lado, como apresentado em mais detalhes na Seção 2, a literatura de DSPL
não apresenta uma forma de selecionar as características que irão a linha de produto em
tempo de execução com base nas preferências do usuário. Esta análise não aborda apenas
a 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 abordada
neste estudo. Como relatado anteriormente os produtos da MobiLine requisitam em
tempo de execução as informações contextuais (coletadas por sensores ou do status do
próprio dispositivo) e recebem estímulos do usuário que junto com essas informações
definem quais adaptações em tempo de execução devem ocorrer.
Quando uma adaptação ocorre no dispositivo mobile duas situações podem ser desencadeadas: a) a requisição a um web service presente e ativo no lado servidor ou b) a
requisição a um web service ausente ou inativo no lado servidor. Para a situação a), ao
encontrar 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 que
está indisponível de acordo com uma ordem de prioridade. Caso nenhum dos serviços
organizados por prioridade esteja disponível, qualquer serviço que atenda a interface
requisitada pela aplicação mobile é disponibilizado para consumo.
No entanto, Alferez and Pelechano (2011) argumentam que web services são executados em ambientes complexos e heterogêneos e considerando este fato é apropriado que
existam mecanismos de adaptação de acordo com mudanças contextuais que efetuem
reconfigurações que aumentem a qualidade do serviço prestado. Enquanto que, para Lin

3

CAPÍTULO 1. INTRODUÇÃO

Figura 1.1 Cenário do Problema

et al. (2010), do ponto de vista empresarial é fortemente desejável maximizar a qualidade
de 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 em
DSPL ocorre; b) Desenvolver um método para a avaliação da qualidade e seleção dos
serviç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, as
avaliaçõ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 pesquisadores
diferentes. Para que isto seja possível todos os passos seguidos em direção aos objetivos
específicos são descritos e os valores das variáveis de observação disponibilizados. Para
que os objetivos específicos fossem alcançados foi necessário estabelecer os métodos
pelos quais este estudo seria guiado. Estes métodos foram escolhidos de acordo com a
natureza de cada objetivo específico
O objetivo específico “a)” é contemplado no Capítulo 2. Trata-se de um estudo
bibliográfico feito com base em revisões da literatura estruturadas já publicadas. Procurase nesta parte bibliográfica do estudo apresentar os principais conceitos abordados neste
estudo, bem como estabelecer o estado da arte para a área de derivação dinâmica em
DSPL.
O relato das etapas referentes ao objetivo específico “b)” está presente no Capítulo 3
e na primeira parte do Capítulo 4. Devido a quantidade de conhecimento sistematizado a
respeito de derivação dinâmica de produtos, optou-se pelo uso de métodos exploratórios
como forma de atingir esse objetivo. Sendo assim, optou-se pela realização de uma
análise, uma intervenção e uma validação exploratória para a satisfação desse objetivo
específico.
A fim de atender ao objetivo específico “c)”, descrito no Capítulo 4, optou-se por
um abordagem quantitativa. Esta abordagem é expressa na forma de uma avaliação de
performance da abordagem proposta, fazendo uso da descrição estatística das variáveis
de 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 Martins (2013) foi ampliada passando a ser chamada de DYMOS QoS. Esta solução proposta
consiste de uma aplicação desenvolvida em linguagem JAVA e Open Service Gatway
Initiative (OSGi) que avalia individual e coletivamente os atributos de qualidade de
serviço disponí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 dos
serviços em tempo de execução: o custo da utilização de um serviço, as capacidades
atuais 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.2
e ilustrada na Figura 1.1, de modo que a seleção do serviço que substituirá o que está

5

CAPÍTULO 1. INTRODUÇÃO

indisponível deixa de ocorrer de acordo com a prioridade arbitrada. E passa a acontecer
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 DYMOS
QoS. Ainda como efeito dessa contribuição, torna-se possível um terceiro cenário onde a
requisição por um serviço retorna sempre um serviço ótimo para determinado nível de
serviço requerido.

1.4

Escopo Negativo

Alguns tópicos que se relacionam com o objetivo desta pesquisa ou seus objetos não são
influenciados e não influenciam a mesma. Sendo assim, estão fora do escopo do presente
trabalho alguns tópicos como a especificação e implementação de agentes, sejam estes de
hardware ou de software, que responsabilizem-se pela monitoração do contexto onde os
produtos da DSPL estão inseridos.
Assume-se, neste estudo, que existem regras de contexto e derivação de produtos
determinadas. Sendo assim, a criação de tais regras é considerada com fora do escopo
abordado. Da mesma maneira, não são abordadas técnicas de precificação, regras de
estabelecimento de preços ou prazo de vigência para os mesmos.
Os serviços utilizados neste trabalho possuem atributos de qualidade que servem
como insumos para a avaliação dos mesmos. No entanto, o monitoramento de quebra de
acordos de nível de serviço ou de qualquer garantia a respeito dos valores desses atributos
de 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 dos
conceitos básicos relacionados a área de SPL além de apresentar o Estado da Arte em
derivaçã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 inicia
com a descrição do funcionamento do DYMOS, sobretudo no que diz respeito ao seu
mecanismo de descoberta de serviços. A segunda parte deste capítulo trata de apresentar as modificações realizadas no framework com a criação dos componentes que são
responsá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 utilizando
os 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 a
abordagem proposta. É apresentado neste capítulo as limitações, contribuições e uma
lista de trabalhos futuros.

7

2
Revisã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 fundamentais
da Computação Orientada a Serviços (SOC). Em seguida são apresentados conceitos
relacionados a abordagem SPL e então o estabelecimento do Estado da Arte em derivação
dinâmica. Finaliza-se, então com uma explanação crítica a respeito da interação entre
DSPL e SOC.

2.1

Computação Orientada a Serviços

Enquanto paradigma computacional, SOC utiliza serviços como elementos fundamentais
para 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 de
oferecer maior eficiência à provisão de recursos computacionais utilizando componentes
diversos de infraestrutura como servidores web e bancos de dados.
É de encargo da SOA determinar os meios pelos quais os serviços devem ser organizados, construídos e gerenciados. SOA fundamenta-se na utilização de serviços
como 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 como
reusabilidade, 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 ou
pequena 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 acessados
através de contratos.
Dentro deste contexto, os clientes (serviços e aplicações que utilizam as funcionalidades providas por um outro serviço) aderem aos contratos de comunicação, definidos por
um 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, normalmente
formatos padronizados como contratos a exemplo de XML, WSDL e XSD, como afirma
Erl (2005).
Sendo assim, a descoberta de serviços ocorre sempre a partir da especificação descritiva dos mesmos (contrato), permitindo a sua localização e identificação. Ambas
podem ocorrer a partir do Universal Descriptor, Discovery and Integration (UDDI) ou
Uniform Resource Identifier (URI), sendo utilizados diretamente por um cliente ou por
um mecanismo de descoberta de serviço (Josuttis, 2007).
A modularidade e reutilização providas pelo uso de SOC e SOA permitem que
serviços sejam disponibilizados para a utilização de terceiros ou em sistemas diferentes
dos sistemas para os quais estes foram desenvolvidos. No âmbito de transações comerciais
eventualmente é desejável que a qualidade do serviço (QoS) oferecido seja aferida para
que sejam garantidas, por exemplo, cláusulas contratuais como a quantidade de resposta
a uma determinada requisição por segundo.
A utilização de SOC na Web manifesta-se na forma de Web services que é um tipo
específico de serviço que que é identificado por uma URI (Papazoglou and Georgakopoulos, 2003). Algumas características comuns a web services que são utilizadas para a
aferiçã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 valores
para os seus atributos de QoS. Sendo assim, alguns critérios de qualidade podem ter
melhores valores em uma implementação do serviço e alguns piores em comparação a
outras 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: funcionalidade e qualidade. Funcionalidade é o que o software pode oferecer e é tipicamente
representado por um conjunto de operações providas pelo serviço. Já a qualidade diz
respeito a o quão bem um provedor de serviços pode fazer a entrega das funcionalidades
deste (Yu et al., 2010b).
O termo “qualidade” é utilizado para representar juízos de valor e por isso é um
termo de significado vago. No entanto, Deora et al. (2006) argumenta que em SOC a
qualidade é normalmente vista segundo as perspectivas de conformidade e reputação.
Dentro da primeira perspectiva a qualidade é vista como um sinônimo de atendimento
a especificações como tempo de reposta, custo e largura de banda. Já na perspectiva de
qualidade enquanto reputação, trabalha-se com a percepção de um usuário a respeito de
um serviço em geral.
Papakos and Rosenblum (2010) defendem que em aplicações cliente em dispositivos
móveis sofrem com mudanças de contexto que podem incluir mudanças nos recursos do
dispositivo, em variáveis ambientais e nas preferências do usuário em tempo de execução.
Sendo assim, o nível de QoS exigido inicialmente exigido pelo podem não estar de acordo
com as capacidades do dispositivo em seu contexto atual resultando em um desperdício
de 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 de
software. Por outro lado, a gerência de configuração de software torna-se cada vez mais
complexa 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 de
encontro a este problema criando produtos de software a partir de um conjunto comum
de características. O gerenciamento da configuração ocorre com as variabilidades e as
comonalidades entre os membros da linha de produto de software.
Segundo o Software Engineering Institute (SEI)1 , SPL é um conjunto de sistemas
intensivos de software que compartilham um conjunto comum e gerenciado de funcionalidades que satisfazem necessidades específicas de um segmento ou missão particular de
mercado 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 depende
do contexto no qual ele é aplicado. Alguns dos benefícios mais comuns são a redução do
1 http://www.sei.cmu.edu/productlines/

11

CAPÍTULO 2. REVISÃO DA LITERATURA

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 qual
o software está inserido em tempo de execução tornam-se cada vez mais frequentes, por
isso existe uma demanda crescente por sistemas capazes de se adaptar automaticamente
ao encontrar essas condições. Em 2008, Hallsteinsen Hallsteinsen et al. (2008) publicou
um estudo que descreveu o conceito de Dynamic Software Product Lines (DSPL). Estas
linhas de produto diferem das outras por não gerenciarem a variabilidade durante a fase
de 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 contexto
e e) são desenvolvidas para um contexto ou ambiente específico no lugar de um segmento
de mercado (Hallsteinsen et al., 2008).
Opcionalmente, DSPLs podem ser sensíveis ao contexto a sua volta (Parra et al.,
2009; Ali et al., 2009; Alferez and Pelechano, 2011), possuir propriedades autonômicas
ou de auto-adaptação (Abbas et al., 2011; Cetina et al., 2008; Abbas, 2011) e tomada
automática de decisão. Estas características compõem um desafio para um modelo de
desenvolvimento 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 onde
se encontram os principais entraves teóricos ou metodológicos. No que diz respeito a
derivação dinâmica, vários pesquisadores têm desenvolvido uma quantidade significante
de estudos para investigar aspectos relacionados a reconfiguração de SPL em tempo de
execuçã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âmica
anteriormente (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 decorrer
dos 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

2.3. LINHAS DE PRODUTO DE SOFTWARE

contribuições estão relacionadas a proposição de soluções, em sua maioria concentradas
no desenvolvimento de metodologias. Ao mesmo tempo que não são comuns de serem
encontrados relatos de experiência e pesquisas que possam avaliar a aplicabilidade dos
conceitos de DSPL no contexto industrial. Estas constatações são reforçadas no estudo de
da 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 que
apresentaram contribuições relevantes para a área de derivação dinâmica em DSPL em
ordem cronológica. O objetivo desta apresentação é expressar a evolução das técnicas de
derivação dinâmica ao longo do tempo.
Estudos em Derivação Dinâmica
Kim et al. (2005) desenvolveram, para um contexto de uma DSPL de jogos para dispositivos móveis, um framework de reconfiguração arquitetural em tempo de execução
que gerencia a reconfiguração dinâmica para ambientes embarcados. A solução proposta
faz uso de uma linguagem específica de domínio para descrever o sistema de maneira
estática e uma linguagem para descrever modelos arquiteturais que especificam as regras
que informam quais componentes devem ser adicionados ou removidos da arquitetura do
produto.
A abordagem “Dynamic Client Application Customization” (DAC) criada por Gomaa
and Saleh (2006) é baseada na customização dos objetos da interface com o usuário em
tempo de execução baseada em features selecionadas e valores de variáveis parametrizadas. Esta abordagem consiste de uma arquitetura de SPL customizável baseada no padrão
arquitetural cliente/servidor, onde a aplicação cliente contém apenas objetos de interface
com o usuário e um objeto customizador. A aplicação do servidor contém todos os web

13

CAPÍTULO 2. REVISÃO DA LITERATURA

services responsáveis por prover as funcionalidades do sistema e o suporte ao banco de
dados.
Na DAC, a seleção de features direciona a customização dinâmica da arquitetura e a
implementação da linha de produto para a derivação da aplicação. Durante a modelagem
da 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 de
aplicação e utilizadas para customizar dinamicamente a arquitetura e implementação da
aplicação.
Hallsteinsen et al. (2006) criaram a abordagem MADAM para construção de sistemas
adaptativos. O foco da abordagem está em sistemas distribuídos acessados por dispositivos 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. O
núcleo dessa arquitetura (Core) é composto por um middleware entre os componentes
e a plataforma, e oferece serviços para o gerenciamento de componentes, instâncias e
recursos. O Context Manager é responsável por monitorar um conjunto de contextos
relevantes no ambiente do sistema enviando e reunindo informações que são utilizadas
pelo Adaptation manager.
O Adaptation manager é responsável pela avaliação do impacto das mudanças no
contexto sobre a aplicação e determinar quando uma adaptação deve ser efetuada, selecionando as variantes que melhor atendem as novas necessidades impostas pelo contexto. O
configurador (Configurator) é responsável por realizar a configuração inicial da aplicação
e as reconfigurações, observando quais variantes devem ser instanciadas e desativadas
para alcançar o estado determinado pelo Adaptation manager.

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

14

2.3. LINHAS DE PRODUTO DE SOFTWARE

Em uma abordagem orientada a features e sistemática de desenvolver core assets
reconfiguráveis dinamicamente, Lee (2006) desenvolvera um reconfigurador que acumula
as 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 (quando
configurar), 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 desenvolver
sistemas pervasivos dinamicamente adaptáveis. Neste estudo afirma-se que a reconfiguração autônoma do produto pode ser realizada estendendo a abordagem do paradigma
SPL reutilizando a análise de escopo, características em comum e variabilidades. A
reutilização desta análise é utilizada como entrada para um reconfigurador que em tempo
de 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 no
domínio de sistemas ERP2 , faz uso de variáveis parametrizadas para adaptar o produto em
tempo 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 chamada
DecisionKing é empregada para gerar um modelo de variabilidades e outra ferramenta
de nome ProjectKing permite que sejam criados cenários para configurações específicas
modelo de variabilidades. Assim, um guia de configuração processa os modelos de
variabilidades com seus respectivos cenários e apresenta as possíveis decisões a serem
tomadas em uma interface amigável para o usuário do software. Por fim, um mecanismo
de descoberta na plataforma de plugins permite ligar e desligar os componentes baseandose nas decisões do usuário.
Pukall et al. (2009) desenvolveu a metodologia chamada “Feature-oriented Runtime
Adaptation” que permite a atualização de programas em tempo de execução através da
evolução dos recursos de uma SPL de forma dinâmica. Toda a metodologia é baseada
em susbstituições de classes em Java utilizando “Java HotSwap” e reimplementação do
corpo de métodos.
O relacionamento entre SPL e computação orientada a serviço foi claramente utilizado
por Yu et al. (2010a) ao apresentarem uma metodologia para a construção de aplicações
baseadas em serviços para ambientes heterogêneos e dinâmicos. A metodologia é dividida
nas fases de engenharia de domínio, engenharia de aplicação e tempo de execução. É
proposto um processo de desenvolvimento centrado em domínios e orientado a arquitetura
2 Enterprise

Resource Planning

15

CAPÍTULO 2. REVISÃO DA LITERATURA

inspirada em SPL. É na fase de tempo de execução que, através de composição de serviços
dinâmica, acontece a reconfiguração.
Foi provado ser possível realizar uma derivação dinâmica a partir do compilador
Java no estudo de Sunkle and Pukall (2010). Este estudo utilizou o FeatureJ, que é uma
abordagem de implementação de SPL, com uma representação de features e variabilidades
como se fossem tipos de uma linguagem de programação. Esta representação é utilizada
como 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 suas
variantes utilizando a linguagem de programação Ruby.
No âmbito de sistemas de cuidados com a saúde, Carvalho et al. (2010) desenvolveu
uma abordagem para gerenciamento dinâmico de variabilidades baseada em contratos
arquiteturais. Estes contratos, especificados na linguagem CBabel, são instanciados em
tempo 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 uma
análise orientada a features e um framework orientado e sensível a qualidade dos serviços
de um SPL. Os autores acreditam que features podem ser mapeadas em serviços.
Alferez and Pelechano (2011) desenvolveu um método para projetar e implementar
web services autônomos e sensíveis ao contexto em SPL. Os autores argumentam que
se web services forem caracterizados por features, então a ativação e desativação de
features em tempo de execução pode guiar a reconfiguração autonômica de composição
de serviços a depender de mudanças no contexto. Neste caso, os produtos são uma
composição de serviços. Para que seja possível uma composição de serviços, os autores
sugerem a criação de um modelo de composição feito a partir de um diagrama UML de
atividades. Este modelo ilustra os web services e os fluxos de sequência entre eles que
estabelece a ordem na qual cada web services deve ser ativado.
Gomaa and Hashimoto (2011) descreve uma arquitetura para a adaptação dinâmica de
produtos de uma SPL baseado em SOA. Esta arquitetura contém um serviço de monitoramento que verifica continuamente o estado do sistema em execução e o encaminha para o
serviço de calibragem, que percebendo uma situação no contexto que necessite de uma
ação envia uma requisição ao dispositivo de seleção dinâmica de features. Este dispositivo
determina 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 da
aplicação e envia a nova seleção de features para o serviço de gerenciamento de mudança.
16

2.3. LINHAS DE PRODUTO DE SOFTWARE

Fica a cargo do serviço de gerenciamento de mudanças determinar a diferença entre
a nova seleção de features e a original, determinar os componentes e conectores que
precisar sem adicionados ou removidos e gerar uma sequência de comandos de adaptação
que correspondem as mudanças que precisam ser efetuadas.
Em (Parra et al., 2011), os autores propuseram uma abordagem unificada com o
objetivo de dar suporte a todo o ciclo de desenvolvimento de software. A abordagem
considera 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. A
abordagem, 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ções
em tempo de projeto quanto em tempo de execução.A segunda é uma plataforma que
realiza de modo transparente as adaptações expressadas no metamodelo unificado.
Esses modelos ligam cada feature em particular com um conjunto de componentes
opcionais que podem fazer parte do produto. Cada modelo contém as informações
necessá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 realizadas
para que esses elementos possa ser adicionados.
Rosenmüller et al. (2011) apresentaram em seu estudo transformações de código
para integrar o bind estático e dinâmico de features em SPLs a nível de modelagem e
implementação. Esta abordagem permite que desenvolvedores mudem flexivelmente o
tempo 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 composição descritas em um modelo de features que contém as regras de reconfiguração que
representam as transformações de código que são utilizadas para a criação das unidades
de bind dinâmico.
Shen et al. (2011) propôs um método orientado a features para suportar reconfiguração
de variabilidades em tempo de execução. Neste estudo é introduzido o conceito de modelo
de funções, que é um nível intermediário entre as variantes das features e suas respectivas
implementações. Durante o processo de adaptação a reconfiguração da feature variante
é mapeado no modelo de funções. Neste contexto as funções relacionadas com as
variabilidades podem ser adaptadas para estar disponíveis ou indisponíveis quando a
reconfiguração em tempo de execução é realizada. Como as funções não podem ser
removidas da aplicação em execução, o gerenciamento dessas interações com as funções
mapeadas apoia a reconfiguração.

17

CAPÍTULO 2. REVISÃO DA LITERATURA

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 é gerado
aplicando-se as modificações contidas em módulos delta adequados para um núcleo de
sistema, que podem sempre ser assumido como vazio. O gráfico de reconfiguração define
quais configurações o sistema pode adaptar em tempo de execução e descreve como
objetos alocados na pilha precisam ser realocados.
O estudo de Baresi and Milano (2012) demonstra uma maneira de enriquecer as
composições da Business Process Execution Language (BPEL) com o gerenciamento
dinâ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ção
de 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 “Advanced System and Software Engineering Research Technologies Lab”(AssertLabs): no
primeiro (da Silva et al., 2013), dentre outras coisas, pode-se verificar que no contexto de
DSPLs orientadas a serviço existem algumas abordagens para a reconfiguração desses
serviços em tempo de execução com base em atributos de qualidade. No entanto nenhuma
dessas abordagens utiliza acordos de nível de serviços ou demonstra evidências de que
podem ser reutilizadas em DSPLs de domínios distintos.
O segundo estudo foi uma dissertação de mestrado (de Oliveira Martins, 2013), onde
foi 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 possibilita
que serviços sejam adicionados ou removidos da configuração do produto em tempo de
execução por meio de mecanismos de auto-implantação, de modo que o funcionamento
do sistema não seja afetado e que tais modificações sejam aplicadas e reconhecidas
imediatamente. Possui também um mecanismo de descoberta de serviços, que provê uma
abstração entre o cliente e o serviço, permitindo efetuar orquestração de serviços e agregar
critérios para a seleção do serviço 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 comunidade de reuso de software não é difícil encontrar na literatura estudos bem sucedidos
que tratam serviços como features, onde a determinação de quais serviços vão compor
o produto é feita através do modelo de features selecionado para cada produto a ser
derivado. 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 enquanto
SPL, apesar de ter como benefício a reutilização, corresponde a uma abordagem de construção e decomposição (Parra et al., 2009). Porém as características antagônicas desses
paradigmas (composição e decomposição) não são conflitantes já que a composição de
serviços em uma SPL tradicional ocorre em um momento pré-derivação e a decomposição
ocorre no momento da derivação do produto.
Desta forma, DSPLs tradicionais podem também não apresentar dificuldades quanto
a este antagonismo. Não obstante, certamente este problema afetará uma DSPL orientada
a serviço que precisa decidir com base em alguma análise (Ex.: prioridade, resposta ao
contexto e QoS) quais serviços devem ser plugados em tempo de execução. Visto que
derivação (decomposição) e composição estão ocorrendo no mesmo momento.
Exemplos de como essa questão é tratada podem ser vistos, por exemplo, no estudo
realizado por Yu et al. (2010a), a DSPL orientada a serviços faz a análise de quais
serviços compõem o produto unicamente verificando a disponibilidade dos serviços.
Adicionalmente, o estudo de Lee (2006) apresenta uma DSPL orientada a serviços onde
as features são mapeadas em serviços. Esta DSPL realiza uma análise e um planejamento
em tempo de execução baseados em mudanças contextuais para definir quais features, e
consequentemente quais serviços, devem compor o produto.
Em um estudo de cunho exploratório posterior (Lee and Kotonya, 2010) esta abordagem é modificada fazendo com que a análise em tempo de execução seja feita com base
em acordos de nível de serviço impostos pela linha de produto. Onde, assim como nos
estudos de Alferez and Pelechano (2011) e Gomaa and Hashimoto (2011), sempre que
ocorre uma quebra no acordo de nível de serviço o framework procura por outro serviço
que satisfaça as condições desejadas. Não foram expressas no estudo detalhes sobre quais
seriam 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 do
Estado da Arte a respeito da derivação dinâmica e sua interação com SOC. A partir disto,
conclui-se que: é ausente na literatura estudos que atendam ao cenário motivacional
descrito na Seção 1.1, ou seja, que definam os serviços que vão compor a DSPL orientada
a serviço. Com base em uma análise de atributos de QoS realizada a cada requisição do
usuário.

19

CAPÍTULO 2. REVISÃO DA LITERATURA

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

20

3
DYMOS 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 conhecimento acumulado e sistematizado, como é o caso da área de derivação dinâmica em DSPL
relatado no Capítulo 2. Este tipo de estudo também possui uma natureza de sondagem e
nã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 desenvolvido por de Oliveira Martins (2013). Cada uma das fases desse estudo exploratório são
apresentadas a seguir.
Vale ressaltar que o framework DYMOS trabalha com features em dois níveis de
abstração distintos. No primeiro nível estas features são compostas de uma chamada a um
serviço no lado cliente da aplicação e um contrato existe no lado servidor. No segundo
ní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 tratadas
por este nome, enquanto as do segundo nível serão tratadas como serviços ou serviços
Web. 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 arquitetura
apresenta um serviço Web chamado “ApplicationService”, o componente “ServiceContext”, o contêiner OSGi e três elementos descritores: o “ServiceDescriptor” que descreve
o que pode ser plugado em tempo de execução ao produto da SPL, o “VariabilityDescriptor” que descreve os pontos de variação e, finalmente, o “WSDescriptor” que descreve o
WSDL 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 de
código 3.1 para descrever os serviços. Este XML contém uma lista de campos estruturados
para cada serviço Web como um campo “Id” fazendo o papel de identificador exclusivo, os
campos “serviceSpec” e “serviceImpl” que contém os valores que identificam a interface
e 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”, apresentado no trecho de código 3.2, define uma lista de variabilidades com uma identificação
(ID) do atributo “id”, um nome através do atributo “name” e um conjunto de variantes.
Desta forma, uma variante consiste em um ID e um nome de um conjunto de referências a
serviços. Este conjunto de referências é responsável por manter os serviços ativos quando
a variação estiver ativada.
Código Fonte 3.2 XML de Serviços do DYMOS
<?xml version="1.0"?>
<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 principal
função, de acordo com um determinado serviço disponível, é descrever os atributos que
nã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

CAPÍTULO 3. DYMOS QOS

dinâmicas e levemente acopladas.
O componente “ServiceContext” faz uso de todos os componentes descritores. A
utilização destes componentes permite ao “ServiceContext” obter todas as informações
descritas na forma de objetos Java, auxiliando-o no gerenciamento de variabilidade e
serviços descritos. Esta gestão utiliza as informações sobre a variabilidade e serviços
para manipular o contêiner OSGi.
O componente ApplicationService foi implementado para funcionar como uma fachada, criando um isolamento entre o cliente e os outros componentes da estrutura. Assim,
reduziu-se o número de objetos que os clientes necessitam lidar. O objetivo principal do
componente é expor operações, permitindo, assim, a descoberta de serviço e a gestão de
variabilidade.

3.1.1

Operações do DYMOS

O “ServiceContext” é o componente responsável pelas principais operações do DYMOS:
reconfiguração de variabilidades, descoberta de serviços e “ContextHotBuild”. A reconfiguração de variabilidades ocorre em resposta a uma variação no contexto no lado cliente
da aplicação que resulta em uma reconfiguração. Em seguida, o DYMOS a partir da sua
operação de reconfiguração adapta o contexto dos serviços (lado servidor) para atender
a necessidade da reconfiguração no lado cliente. A sequência desta operação pode ser
visualizada na Figura 3.3.
A operação de descoberta de serviços utiliza como critério de seleção de serviços
Web a prioridade descrita para cada serviço alternativo no XML de serviços utilizado pelo
componente “ServiceDescriptor” e a disponibilidade do mesmo no contêiner OSGi. A
seleção é direcionada pelos atributos “service-impl”, “service-spec” e “priority”, que é
definido no “alternative-service”.
Esta operação inicia-se no lado cliente da SPL a partir da invocação do método
“getEndPoint” do “ApplicationService” (ver Figura 3.2). O método em questão recebe
como parâmetro o ID do serviço desejado que é passado para o “SeviceContext”, onde a
requisiçã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 OSGi
utilizando 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 ao
mé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 definida
nos atributo “service-spec” e o “service-Impl”;
• busca por um serviço alternativo, levando em consideração a prioridade definida
no atributo “priority”;
• busca por qualquer serviço presente no contêiner OSGi que satisfaça a especificação
desejada.
A execução das fases de seleção, apresentadas anteriormente, é sequencial. No entanto
só acontecerá a execução de uma fase subsequente caso a fase anterior seja incapaz de
encontrar 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 o
serviço selecionado encontra-se e recebendo como resposta o end point, o name space e
o 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 pelas operações de bind em tempo de execução. Todos os serviços Web que são tratados pela

25

CAPÍTULO 3. DYMOS QOS

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, tornando
possível que eles sejam ativados e desativados, plugados e desplugados da DSPL sem a
necessidade de que o software seja recompilado. Sendo assim, fica sob a responsabilidade
do componente “OSGi Container” gerenciar a operação de “ContextHotBuild” a partir
do 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ços
permite que a relação entre cliente e serviços não seja tratada de forma fixa ou acoplada,
com vistas à seleção de um serviço mais adequado baseado em critérios estabelecidos.
Por outro lado, a descoberta de serviços no DYMOS apesar de efetiva pode não ser a
ideal 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 de
limitar a descoberta de serviços a torna arbitrária e delega ao engenheiro de software a
responsabilidade 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 de
dinamicidade para a DSPL. Com base nesta observação e no intuito de atingir o objetivo
de propor uma abordagem de seleção em tempo de execução das características que irão
compor 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 acordo
com a prioridade arbitrada. Propõe-se que a seleção de serviços ocorra de acordo com a
qualidade 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 DYMOS
QoS. Esta nova abordagem torna possível que uma terceira situação ocorra, onde sempre
que 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ço
exigido.
Para tanto, dois novos componentes foram adicionados a arquitetura do DYMOS:
o “ServiceLevelProvider” e o “Broker”, como pode ser visualizado na Figura 3.4. O
primeiro armazena informações contextuais sobre os serviços Web de forma estruturada
em um arquivo XML e atualiza essas informações de acordo com as mudanças que
ocorrem no contexto. O componente “Broker” é responsável por analisar os atributos de
qualidade para cada serviço em tempo de execução durante a descoberta de serviços.

Figura 3.4 DYMOS QoS - Diagrama de Pacotes

27

CAPÍTULO 3. DYMOS QOS

A fim de que seja possível ao “Broker” realizar essa análise, o componente “ServiceLevelProvider” armazena em um XML alguns atributos de qualidade, tais como nível de
serviço, capacidade máxima, a capacidade atual, tempo de resposta e custo. A análise
do “Broker” calcula a utilidade (Yu and Lin, 2005) de cada serviço no nível de serviço
escolhido e envia esta informação para o componente “ServiceContext”, que continua
sendo o principal responsável pelo processo de descoberta de serviços.
Esta intervenção requer uma modificação no componente “ServiceContext” de modo
que durante a execução do método “findAlternativeService” a prioridade descrita no XML
de serviços deve ser desconsiderada, os atributos de qualidade de cada serviço devem ser
recuperadas 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 processo
de 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 qualidade
estruturados dentro de objetos “AlternativeServiceQoS”.
Os atributos de qualidade têm valores distintos para cada serviço em cada nível
de serviço, como é apresentado no Código 3.3 que representa o XML de atributos de
qualidade utilizado pelo “ServiceLevelProvider”. Os atributos de qualidade dos serviços
utilizados nessa abordagem são: custo, capacidade máxima e atual, nível, tempo de
resposta, 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>
<serviceLevel id="2">
<cost>0,29</cost>
<curCapacity>38</curCapacity>
<level>2</level>
<maxCapacity>48</maxCapacity>
<name>imageService1</name>
<responseTime>44639</responseTime>
<serviceSpec>com.assertLab.imageService</serviceSpec>
</serviceLevel>
...

Apesar da nomenclatura dos atributos de qualidade dizer muito a respeito dos mesmos,
estes não são suficientes para evitar interpretações distintas. Por isso, vale ressaltar
que o atributo de custo representa o custo de um determinado serviço em um dado
nível de serviço. Esta abordagem não determina como o custo do serviço deve ser
definido, possibilitando a utilização do DYMOS QoS de acordo com diversos modelos
de precificação.
Os atributos de capacidade máxima e atual representam respectivamente quantos

29

CAPÍTULO 3. DYMOS QOS

clientes ao mesmo tempo podem utilizar e quantos estão utilizando um serviço em um
determinado nível de serviço. O atributo nível refere-se ao nível de serviço ao qual os
demais atributos de qualidade pertencem. O atributo de tempo de resposta armazena o
valor de qual tempo de resposta em microssegundos deve ser esperado de um serviço no
nível de serviço em questão.
Os atributos de nome e especificação do serviço, tem função meramente identificadora. Enquanto os atributos de confiabilidade e disponibilidade são baseados em dados
históricos. O valor do primeiro é incrementado sempre que o serviço requisitado responde
a uma requisição em tempo igual ou menor ao especificado no atributo de tempo de
resposta e decrementado quando ocorre o contrário. O atributo de disponibilidade é
incrementado sempre que uma requisição a um serviço tem uma resposta e decrementado
quando o serviço se mostra indisponível.

3.2.1

Seleção de Serviços

De acordo com o que já foi explanado, o componente “Broker” é responsável por realizar
as 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 cada
provedor 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 a
respeito dos candidatos a provedores de serviço. Para tanto, este componente, apanha as
definições de serviço e nível de serviço dos clientes e então realiza uma verificação nos
compromissos de qualidade oferecidos pelos serviços.
O “Broker” utiliza uma função para a otimização da seleção dos serviços Web chamada por Yu and Lin (2004, 2005) de função de utilidade. Esta função é baseada em
um conjunto de parâmetros que englobam informações estáticas (nível de serviço), as
necessidades 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ções
precisam ser esclarecidas. A primeira delas é que serviços Web que oferecem a mesma
funcionalidade podem ter características não funcionais distintas. O conjunto desses
serviços que oferecem a mesma funcionalidade é chamado de classe de serviço e denotado
por S, sendo cada serviço de uma classe denotado individualmente por s. O nível de
serviço oferecido por um único serviço Web é denotado por l. A confiabilidade é uma
restriçã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 que
cada 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ão
Cmax (s, l) e Ccur (s, l), onde o primeiro denota a capacidade máxima e o segundo a carga
atual 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 para
que os serviços selecionados tenham uma baixa carga, oferecendo assim menores tempos
de resposta reais. Isso implica em um balanceamento global das cargas dos serviços
evitando sobrecargas.
b(s, l) =

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


3.1

A função de utilidade pode ser vista na Equação 3.2, onde wb e wc são os pesos de um
benefício de custo, b(s, l) e c(s, l) são os benefícios e os custos, escolhendo serviço s no
nível de l, avgb e avgc são o benefício médio e o custo médio para os serviços disponíveis
no nível de serviço escolhido, e, finalmente, stdb e stdc são o desvio padrão de benefício
e custo. O objetivo dessa função é maximar o benefício e minimizar o custo no momento
de uma seleção de serviço.
F(s, l) = wb ∗ (

3.3

b(s, l) − avgb
c(s, l) − avgc
) + wc ∗ (1 −
)
stdb
stdc


3.2

Conclusões

Este capítulo tratou da análise e intervenção exploratória realizadas para contribuir com
os objetivos deste estudo apresentando um entendimento do processo de descoberta de
serviços do DYMOS e a classificação das features utilizadas por este. Partindo desta
análise foi possível construir uma abordagem de descoberta de serviços com base na
análise de atributos de QoS.
A análise implementada para a seleção de serviços é fundamentada na idéia de que um
componente pode atuar como mediador avaliando a necessidade do cliente e encontrando
um serviço que melhor se enquadre nesta necessidade. O trabalho do componente
mediador (“Broker”) é regido pela relação custo-benefício especificada na forma de
funções matemáticas definidas por Yu and Lin (2004, 2005). O próximo capítulo trata
da de uma validação realizada com a abordagem aqui proposta para demonstrar a sua
efetividade. Assim como é relatada uma avaliação da performance da mesma.

31

4
Avaliação

O poder permanece onde os homens crêem que ele deve permanecer.
—GEORGE R. R. MARTIN (A Fúria dos Reis, As Crônicas de Gelo e
Fogo)

A fim de avaliar a abordagem proposta no Capítulo 3 foram desenvolvidas uma
validação e uma avaliação quantitativa, ambas apresentadas nesse capítulo. A primeira de
natureza aplicada e exploratória quanto aos objetivos. Para esta procura-se demonstrar o
DYMOS 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 aos
fins. Estudos descritivos, de uma maneira geral, expõem características de determinada
população ou de determinado fenômeno, podendo estabelecer correlações entre variáveis
e definir sua natureza. Não obstante, não tem compromisso de explicar os fenômenos
descritos 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, primeiro
foi necessário adequar o lado do cliente da DSPL e posteriormente configurar o DYMOS
QoS, assim construindo os arquivos XML necessários aos componentes descritores e ao
ServiceLevelProvider.
O GREatTour e o Cin Tour são guias de visitas móveis sensíveis ao contexto derivados
da MobiLine. Ambos são executados a partir de dispositivos que possuam o sistema
operacional Android e fornecem informações sobre os pesquisadores e os ambientes do
laboratório do grupo de pesquisas GREat da Universidade Federal do Ceará e do Centro
de 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 preferências do usuário visitante, assim como as requisições desencadeadas por este e as
características 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 da SPL
estão presentes nos dispositivos móveis, enquanto outras características que variam em
tempo 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 e
Figura 4.2. O Cin Tour é uma versão mais leve do Great Tour, diferindo deste por não
apresentar as features de autenticação, de vídeo e de captura da localização do usuário
utilizando a tecnologia NFC.
A chamada aos serviços do lado servidor da SPL deve ser feita a partir da utilização
das bibliotecas “KSOAP”2 e “DymosClientLib”. Esta última possui uma classe chamada
“VariabilityContex”, que permite o suporte a reconfiguração de variabilidades dinâmicas
e a classe “ServiceEndpointFactory” que suporta a descoberta de serviços. Há também a
1 Disponível

em: http://goo.gl/weMfAf

2 https://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, o
namespace 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 no
DYMOS QoS. Primeiro é necessária a criação de um objeto “ServiceEndPoint” que
recebe o retorno do método “getEndPoint()” da classe “ServiceEndPointFactory”. Este
método recebe como parâmetro o nome da variante ou da interface para o serviço desejado
e 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

CAPÍTULO 4. AVALIAÇÃO

Para a abordagem do DYMOS QoS ser totalmente funcional cada vez que um serviço
estiver 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étodos
requireLevel() 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 Listagem
4.2 com o custo, a capacidade máxima (Cmax), a capacidade atual (cCurr) e o valor da
função de utilidade (UF) mostrados na Tabela 4.1. Isto posto, foi possível experimentar o
framework nas três situações descritas na Seção 1.3.
Código Fonte 4.2 Services XML File
<?xml version="1.0"?>
<services>
...
<service id="imageService" service−impl="com.assertLab.imageServiceImpl">
<service−spec>com.assertLab.imageService</service−spec>
<alternative−service ref="imageService1" />
<alternative−service ref="imageService2" />
<alternative−service ref="imageService3" />
<alternative−service ref="imageService4" />
<alternative−service ref="imageService5" />
</service>
<service id="imageService1" service−impl="com.assertLab.imageService1">
<service−spec>com.assertLab.imageService</service−spec>
</service>
<service id="imageService2" service−impl="com.assertLab.imageService2">
<service−spec>com.assertLab.imageService</service−spec>
</service>
<service id="imageService3" service−impl="com.assertLab.imageService3">
<service−spec>com.assertLab.imageService</service−spec>
</service>
<service id="imageService4" service−impl="com.assertLab.imageService4">
<service−spec>com.assertLab.imageService</service−spec>
</service>
<service id="imageService5" service−impl="com.assertLab.imageService5">
<service−spec>com.assertLab.imageService</service−spec>

36

4.1. VALIDAÇÃO EXPLORATÓRIA
</service>
...
</services>
</variabilities>
Código Fonte 4.3 QoS Attributes XML File
...
<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>
<serviceLevel id="2">
<cost>0,29</cost>
<curCapacity>38</curCapacity>
<level>2</level>
<maxCapacity>48</maxCapacity>
<name>imageService1</name>
<responseTime>44639</responseTime>
<serviceSpec>com.assertLab.imageService</serviceSpec>
</serviceLevel>
...

Tabela 4.1 Valores de QoS

Service
imageService1
imageService2
imageService3
imageService4
imageService5

cMax
42
39
30
23
43

cCurr
0
9
17
22
26

Cost
2,07
6,86
0,56
6,97
9,69

UF
0,82
-0,58
0,18
-1,83
-1,82

O primeiro passo da validação é certificar que o comportamento do framework ficou
inalterado no que diz respeito a situações onde a descoberta de serviços alternativos não
se faz necessária. Neste caso, uma requisição ao end point da variante “ImageService”

37

CAPÍTULO 4. AVALIAÇÃO

é feita no produto Mobiline. O “ServiceContext” utiliza os componentes descritores
do 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, o
primeiro passo da validação foi concluído, restando para ser realizado o passo que utiliza
a 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 a
acontecer 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êiner
OSGi e mantidos todos os serviços alternativos ativados. Quando uma solicitação para o
end point desta variante é feito o “ServiceContext” requisita ao “Broker” uma lista de
serviços 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ço
ativo 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 a
escolha do framework foi correta, visto que este era o serviço com o maior valor para a
funçã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 cliente
por um end point retorna sempre o serviço com melhor qualidade. Neste caso entede-se
melhor qualidade o serviço com maior valor na função utilidade.
Para que esse terceiro cenário aconteça, o serviço prioritário deve ser substituído por
um serviço sem implementação e ser colocado junto dos serviços alternativos. O que
implica 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 existem
alterações no fluxo de execução do DYMOS QoS. O que ocorre neste caso é apenas uma
decisã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 toda
ela é baseada na filosofia positivista. Onde as variáveis a serem observadas são conside38

4.2. AVALIAÇÃO ESTATÍSTICA DESCRITIVA

radas objetivas e portanto diferentes observadores em outras visualizações encontrarão
os mesmos resultados aqui apresentados. Por se tratar de uma observação numérica
elimina-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 outras
técnicas de seleção de serviços no âmbito da área de DSPL cerceiou a possibilidade de
experimentação estatística para avaliar a abordagem proposta nesta dissertação. Diante
disto, optou-se pela criação de um benchmark com o intuito de aferir a performance do
DYMOS QoS.
O benchmark consiste em uma classe de serviços contendo 100 serviços Web no
formato 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, o
nome 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. Para
esse tipo de dado não existe sentido em fazer outra operação a não ser a verificação do
valor dos mesmos. Esses dados tem a única função de identificar a qual serviço pertencem
durante 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ção
permite uma ordenação dos valores. Os níveis de serviço utilizados neste benchmark estão
compreendidos 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 de
categorização, mas operações matemáticas com estes fazem sentido.
Esses valores foram gerados automaticamente a partir de um programa escrito em
JAVA. Foi definido nesse programa que o identificador deveria ser sequencial e único, a
capacidade máxima e atual são inteiros positivos não maiores que 50, o tempo de resposta
representados 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 é sempre
um fração positiva maior que zero e menor que dez.
A Figura 4.3 apresenta graficamente a distribuição do tempo de resposta máximo
oferecido por cada serviço. Nesta é evidenciada a concentração de menores tempos de
resposta nos níveis 3 e 4, ao passo que os maiores tempos de resposta encontram-se nos
níveis 1 e 2. Contudo, é notório mesmo os níveis de serviço 1 e 2 apresentam tempos de
resposta 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ços
Web em cada nível de serviço. A Tabela 4.3, de maneira análoga, apresenta esses mesmos

39

CAPÍTULO 4. AVALIAÇÃO

valores em relação aos custos praticados pelos serviços Web. Tanto as capacidades quanto
os custos da amostra gerada apresentam médias e medianas similares entre si, o que pode
ser um indicativo de que estes dados tem uma distribuição normal de probabilidade.
Tabela 4.2 Capacidades Máximas e Atuais

Level
1
2
3
4

Média
Máxima Atual
25,64
13,25
25,14
12,48
24,78
11,11
26,98
13,98

Mediana
Máxima Atual
25
12
24,5
7,5
24
8,5
27,5
11

Desvio Padrão
Máxima
Atual
14,36350932 11,08546345
15,32254548 12,38586291
13,81273326 9,813149342
14,12372472 11,7115157

Figura 4.3 Tempo de Resposta

Tabela 4.3 Custo

Level
1
2
3
4

Média
4,82
5,20
5,48
4,99

Mediana
4,56
5,09
5,71
4,97

Desvio Padrão
2,74
2,74
2,73
2,86

Todos os 100 serviços do benchmark foram postos dentro do contêiner OSGi e
registrados nos arquivos XML dos descritores do DYMOS QoS. Após isso 100 execuções
foram realizadas com 4 subgrupos da população de serviços. O primeiro subgrupo possuía
5 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 com
6 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 realizado
o Warm Up do ambiente, executando cada subgrupo da população de serviços duas
vezes 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 DYMOS
QoS durante o processo de seleção de serviço com bases nos atributos de qualidade
apresentados as medidas foram feitas em nanosegundos. A Figura 4.4 apresenta o
desempenho para cada execução em todos os subgrupos.
A Tabela 4.4 apresenta os valores médios, medianos e de desvio para cada um dos
subgrupos além do desempenho relativo entre eles. O desempenho relativo é representado
pelo percentual da quantidade de tempo de execução média da seleção de serviços no
DYMOS QoS com relação ao desempenho anterior.
Como pode ser observado, o tempo de execução para o subgrupo com 50 serviços
Web foi 84% menor em relação ao subgrupo com 100 serviços e 472% maior com relação
ao subgrupo com 10 serviços. Esta informação evidencia que a abordagem utilizada pode
não ser escalonável.
O mesmo procedimento de avaliação foi realizado com o DYMOS Framework com a
diferença de que os níveis de serviço e seus respectivos atributos não foram utilizados. O
resultado destas execuções podem ser vistas Tabela 4.5. Ao se comparar os desempenhos
do DYMOS Framework com o DYMOS QoS, fica nítido que o problema de escalabilidade apresentado no DYMOS QoS não é oriundo do DYMOS Framework, mas sim da
intervenção exploratória realizada nesta dissertação.
Tabela 4.4 Desempenho do Dymos QoS

Qauntidade
de Seviços
100
50
10
5

4.3

Média

Mediana

Desvio Padrão

10596089267,56
5748081772,13
1005138360,88
561101255,45

10566183253
5703638330
984489598,5
562455565

137289824,9
103294539,4
37707131,55
11848639,2

Desempenho
Relativo
(%)
84,3413105
471,8697043
79,13671572

Conclusões

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

41

CAPÍTULO 4. AVALIAÇÃO

Tabela 4.5 Desempenho do Dymos

Qauntidade
de Seviços
100
50
10
5

Média

Mediana

Desvio Padrão

44718748,65
47238874,62
47566174,54
39972607,83

42730676,00
45913599,50
45192888,50
38636221,50

5234277,245
7166111,98
9912151,66
6680693,484

Desempenho
Relativo (%)
−5,33485607
−0,688093846
18,99692595

Figura 4.4 Desempenho

proposta é funcional para a MobiLine, exigindo pouco esforço para ser adotada pela
DSPL. Vale salientar, no entanto, que apesar dos indícios de que a abordagem seja compatível com outras DSPLs, esta não é uma afirmação que possa ser feita com base nesta
validação.
A avaliação estatística descreve em termos quantitativos o desempenho da abordagem
proposta. Pode-se concluir, a partir da observação do comportamento do DYMOS QoS
que a abordagem pode não ser escalonável. Fato devido ao tempo gasto para a descoberta
dos serviços em classes grandes de serviço que se apresenta relativamente maior do que
o esperado quando comparado com classes de serviços menores.
Vale salientar ainda, que os dados utilizados para a execução da avaliação de performance são dados gerados. Portanto existe um risco de que esses dados apresentem um viés
que pode ser considerado com uma ameaça a validade do estudo. Outra limitação é o fato
de não estar disponível na literatura nenhum outro benchmark ou abordagem relacionada
disponível para uma comparação dentro de um desenho experimental adequado.

42

5
Conclusão
Eu é que não me sento
No trono de um apartamento
Com a boca escancarada
Cheia de dentes
Esperando a morte chegar
—RAUL SEIXAS (Ouro de Tolo)

Neste capítulo final serão apresentadas as contribuições, limitações e uma breve
explanação a respeito dos trabalhos futuros. Esta dissertação foi iniciada com uma
contextualização a respeito da temática abordada, junto com a problematização e a
descriçã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 uma
abordagem de seleção, em tempo de execução das características que irão compor a DSPL
com 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 estado
da 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 com
uma discussão em torno das limitações das contribuições dos estudos que tratam sobre
derivação dinâmica em DSPLs orientadas a serviço, apresentando a lacuna na qual esta
pesquisa esteve centralizada.
A este ponto, dada a ausência de trabalhos na literatura que atendessem a necessidade
de definir os serviços com base na requisição de usuários e ao mesmos tempo ao objetivo
estabelecido, 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 componentes
responsáveis pela realização da seleção de serviços em tempo de execução com base nos
estudos 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ística
descritiva da abordagem proposta. A partir desse pode-se concluir que a abordagem
apresentada funciona para a linha de produto na qual foi validada, sendo melhor utilizada
com 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, em
tempo de execução das características (serviços) que irão compor a DSPL com base
em uma análise de seus respectivos atributos de qualidade. Esta abordagem utilizase de procedimentos que já estavam presentes no processo de derivação de produtos
da Mobiline, agregando apenas como responsabilidade do engenheiro de software a
necessidade de descrever os atributos de qualidade dos serviços.
Outra contribuição é o fornecimento de um mecanismo que permite a seleção de
serviços com base na abordagem de Chen et al. (2003); Yu and Lin (2004, 2005). Este
mecanismo será licenciado como código aberto e disponibilizado no site do autor desta
dissertação1 . O benchmark utilizado para a avaliação da proposta é de domínio público e
disponibilizado junto com o software sob a mesma licença, caracterizado assim a ultima
contribuição desta dissertação.

5.2

Limitações

Wazlawick (2009) classifica em cinco categorias os estilos de pesquisa correntes em
Ciência da Computação: apresentação de um produto, apresentação de algo diferente,
apresentação de algo possivelmente melhor, apresentação de algo reconhecidamente
melhor e apresentação de uma prova. Dentro dessa classificação esta dissertação enquadrase na categoria de “apresentação de algo diferente”.
Esta classificação justifica-se pela primeira contribuição deste estudo que é apresentar
uma maneira diferente de resolver o problema da seleção de serviços em tempo de
execuçã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ão
apresentados como comparações, mais comumente qualitativas, entre técnicas.
1 www.cin.ufpe.br/

44

jrfs/dymosqos

5.3. TRABALHOS FUTUROS

O estado da arte realizado na Seção 2.3.1 apresenta estudos como apresentação de um
produto 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 respectivas
aplicações em determinadas linhas de produto. Não é possível assegurar portanto que
estas 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 em
DSPLs 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 área
de DSPL observaram que a maioria dos estudos publicados até então apresentam como
contribuição o desenvolvimento de metodologias e propostas de soluções para situações
específicas. Estas soluções não estão disponíveis em local público para o uso por parte
dos outros pesquisadores, impossibilitando uma comparação entre abordagens.
Estas limitações no campo de estudos de DSPLs, tornaram-se um fator limitante para
o estudo desenvolvido nesta dissertação. A ausência de outras ferramentas e de dados
mais detalhados a respeitos de outras abordagens impossibilitou a criação de um desenho
experimental rebuscado para o estudo aqui apresentado. Um benchmark de serviços e
seus respectivos atributos de qualidade foi criado para mitigar esse problema e contribuir
para que a área de derivação dinâmica em DSPL evolua para um novo estágio dentro da
classificação de Wazlawick (2009).
A criação e manutenção de um benchmark é uma tarefa nobre na opinião de Wainer
(2007). No entanto, benchmarks gerados por ferramentas podem conter um viés. Os
indícios de normalidade probabilística relatados no final do Capítulo 4 pode indicar um
vié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 abordagens
que estivessem publicados os seus dados para que fosse possível a comparação. Mas
igualmente, 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 oportunidades de pesquisa que não deve deixar de ser levado em consideração. Basta olhar para
as áreas de carência de estudos apontadas por Buregio 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 tipos
de 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 abordagens de descoberta de serviços utilizando técnicas de composição ou de inteligência
artificial, como algorítimos genéticos, por exemplo. A comparação entre essas outras
té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 dispositivos
móveis pode se tornar um sistema autônomo nos termos do ciclo MAPE-K, especificado
pela IBM (2006). Diminuindo assim, a necessidade de intervenção humana na derivação
dinâ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 Social
Machines pode ter resultados científicos relevantes. Visto que a descoberta de serviços
poderia ser facilitada em um ambiente onde os mesmos já ofertem informações semânticas
ao seu próprio respeito.
Do ponto de vista mercadológico, tem se tornado frequente que sistemas de Internet
sejam portados para dispositivos móveis utilizando tecnologias como HTML5 e JavaScript. Apesar de ser uma abordagem que representa um menor custo de desenvolvimento,
sobretudo quando o sistema precisa ser executado a partir de diferentes sistemas operacionais, ela torna-se um impeditivo no que diz respeito ao uso de recursos do dispositivo e
na programação de reconfigurações dinâmicas.
Por outro lado, existe um desejo da OSGi Aliance de tornar o OSGi compatível com
diversas linguagens de programação. Parte desse desejo é expresso na RFP-159 que foi
lançada em 2007 e deu os seus primeiros passos em 2013.
Uma investigação científica para o desenvolvimento de um mecanismo que permita
a reconfiguração dinâmica de artefatos de código em JavaScript pode ter resultados
mercadológicos relevantes no que diz respeito aos sistemas de Internet que estão sendo
portados 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 autonomic
software product lines. page 1, New York, New York, USA. ACM Press.
Alferez, G. H. and Pelechano, V. (2011). Context-Aware Autonomous Web Services in
Software Product Lines. pages 100–109. Ieee.
Ali, R., Chitchyan, R., and Giorgini, P. (2009). Context for goal-level product line
derivation.
Alves, V., Schneider, D., Becker, M., Bencomo, N., and Grace, P. (2009). Comparitive
study of variability management in software product lines and runtime adaptable
systems.
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 Dynamic
Software Product Line?
Bencomo, N., Hallsteinsen, S., and Almeida, E. (2012). A View of the Landscape of
Dynamic Software Product Lines. pages 1–1.
Buregio, V., Almeida, E., and Meira, S. (2010). Characterizing Dynamic Software
Product Linesâ A Preliminary Mapping Study. pages 53–60.
Carvalho, S. T., Loques, O., and Murta, L. (2010). Dynamic Variability Management in
Product Lines: An Approach Based on Architectural Contracts. pages 61–69. Ieee.
Cetina, C., Fons, J., and Pelechano, V. (2008). Applying Software Product Lines to Build
Autonomic 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 of
QoS-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 literature
review. 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 ofweb
services. In Web Services, 2006. ICWS ’06. International Conference on, pages 789–
796.
Damiani, F., Padovani, L., and Schaefer, I. (2012). A Formal Foundation for Dynamic
Delta-Oriented Software Product Lines. pages 1–10.
de Oliveira Martins, D. A. (2013). DYMOS: Uma abordagem para suporte a variabilidades 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 in
service 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-oriented
product lines. page 1, New York, New York, USA. ACM Press.
Gomaa, H. and Saleh, M. (2006). Software Product Line Engineering and Dynamic
Customization of a Radio Frequency Management System. pages 345–352.
Günther, S. and Sunkle, S. (2010). Dynamically adaptable software product lines using
Ruby metaprogramming. pages 80–87, New York, New York, USA. ACM Press.
Hallsteinsen, S., Stav, E., Solberg, a., and Floch, J. (2006). Using Product Line Techniques
to Build Adaptive Systems. pages 141–150. Ieee.
Hallsteinsen, S., Hinchey, M., Park, S., and Schmid, K. (2008). Dynamic software
product 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

REFERÊNCIAS BIBLIOGRÁFICAS

Khezrian, M., Wan Kadir, W. M. N., Ibrahim, S., Mohebbi, K., Munusamy, K., and
Tabatabaei, S. G. H. (2010). An evaluation of state-of-the-art approaches for web
service selection. In Proceedings of the 12th International Conference on Information
Integration and Web-based Applications &#38; 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: an
architecture-based runtime reconfiguration framework. pages 66–72.
Lee, J. (2006). A Feature-Oriented Approach to Developing Dynamically Reconfigurable
Products in Product Line Engineering. pages 131–140. Ieee.
Lee, J. and Kotonya, G. (2010). Combining service-orientation with product line engineering. Number June, pages 35–41.
Lin, K.-J., Zhang, J., Zhai, Y., and Xu, B. (2010). The design and implementation of
service 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., Teixeira, E., Filho, J. a. B. F., Dantas, V. L., Lima, F., and Aguiar, S. (2012). MobiLine: A
Nested 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 Systematic
Mapping 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 Cloud
Service Discovery for Mobile Systems. pages 32–38.
Papazoglou, M. P. and Georgakopoulos, D. (2003). Introduction: Service-oriented
computing. Commun. ACM, 46(10), 24–28.
Parra, C., Blanc, X., and Duchien, L. (2009). Context awareness for dynamic serviceoriented product lines. pages 131–140.
Parra, C., Blanc, X., Cleve, A., and Duchien, L. (2011). Unifying design and runtime
software adaptation using aspect models. volume 76, pages 1247–1260. Elsevier B.V.

49

REFERÊNCIAS BIBLIOGRÁFICAS

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 binding
in software product lines. volume 18, pages 163–197.
Shen, L., Peng, X., Liu, J., and Zhao, W. (2011). Towards feature-oriented variability
reconfiguration in dynamic software product lines.
Sunkle, S. and Pukall, M. (2010). Using reified contextual information for safe run-time
adaptation of software product lines. pages 1–6, New York, New York, USA. ACM
Press.
Tang, M. and Ai, L. (2010). A hybrid genetic algorithm for the optimal constrained
web 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 da
Computaçã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). Supporting Runtime System Adaptation through Product Line Engineering and Plug-in
Techniques. pages 21–30. Ieee.
Yu, J., Lalanda, P., and Bourret, P. (2010a). An Approach for Dynamically Building and
Managing Service-Based Applications. pages 51–58. Ieee.
Yu, Q., Rege, M., Bouguettaya, A., Medjahed, B., and Ouzzani, M. (2010b). A two-phase
framework 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-end
QoS constraints. In IEEE International Conference on E-Commerce Technology.
50

REFERÊNCIAS BIBLIOGRÁFICAS

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

51