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

Dymos QoS: Uma Abordagem para Seleo de Servios
em Tempo de Execuo em Linhas de Produto de Software

Dinmicas
Por
Jackson Raniel Florencio da Silva

Dissertao de Mestrado
Universidade Federal de Pernambuco

posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
RECIFE, FEBRUARY/2014
Universidade Federal de Pernambuco

Centro de Informtica
Ps-graduao em Cincia da Computao
Jackson Raniel Florencio da Silva
Dymos QoS: Uma Abordagem para Seleo de Servios

em Tempo de Execuo em Linhas de Produto de
Software Dinmicas
Trabalho apresentado ao Programa de Ps-graduao em

Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco como requisito parcial para
obteno do grau de Mestre em Cincia da Computao.
Orientador: Vinicius Cardoso Garcia
RECIFE, FEBRUARY/2014
Dedico esta dissertao a todas as pessoas que se

sacrificaram junto comigo nos momentos em que necessitei
ser ausente.
Agradecimentos
Utilizar palavras para expressar sentimentos to vastos na forma de agradecimento uma

tarefa difcil para mim. Nenhum conjunto de cdigos e seus respectivos significados
semnticos podem expressar um pedao da minha alma. No entanto coloco aqui o meu
esforo em faze-lo de maneira singela ao mesmo tempo que extremamente sincera.
Agradeo primeiro ao Pai do Cu que sempre me protegeu, me guiou e atendeu
aqueles pedidos que fiz da forma como julgou ser melhor. Sua bondade e graa tamanha
a ponto de me amar imensamente mesmo eu no sendo um exemplo de filho. Por isso
reservo a Ele este primeiro lugar nos meus agradecimentos.
A partir de agora os meus agradecimentos no seguem uma ordem de importncia,
visto que apenas vou agradecer aqueles que representam uma extenso do amor divino
aqui na terra. Sendo assim, agradeo aos meus pais, avs e irm por me devotarem tanto
amor desde a minha mais tenra idade, alm de me acompanhar a cada passo dado e me
ensinar tanto a cada dia.
Agradeo 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,
dedicao e tantas outras facetas foi meu arrimo durante muitos momentos.
Agradeo, por fim, ao meu orientador por ter me guiado durante esta caminhada.
Assim como agradeo ao Centro de Informtica da Universidade Federal de Pernambuco
por todo apoio estrutural que me foi dado durante a realizao desse trabalho.
vii
Omnia Vincit Amor.

VIRGLIO (70 a.c. - 19 a.c.)
Resumo
A produo industrial antes de Taylor era essencialmente manufatureira e focada em

produtos nicos. O Taylorismo e seus estudos de tempos e movimentos levaram para
a indstria a ideia de padronizao dos produtos. Ford, tempos depois, inventou a
linha de produtos, onde a partir de ento foi possvel produzir em massa reduzindo o
tempo de entrega do produto e seus custos. No que tange a indstria de software, esta
apresenta tanto uma produo manufatureira quanto em massa que gera produtos que
so denotados segundo Pohl et al. (2005) como software individual e software standard:
uma clara influncia do fordismo na concepo do paradigma de Linhas de Produto
de Software (SPL). No entanto, este paradigma de desenvolvimento no foi concebido
para suportar mudanas nos requisitos de usurios em tempo de execuo. Diante deste
problema, a academia tem desenvolvido e proposto maneiras de estender o paradigma
de SPL de forma a permitir que essas reconfiguraes dinmicas do software sejam
suportadas. Surgiram deste esforo as Linhas de Produto de Software Dinmicas (DSPL)
(Hallsteinsen et al., 2008). Levando em considerao este cenrio, objetiva-se nesta
pesquisa contribuir com a rea de DSPL apresentando uma nova maneira de pensar quais
caractersticas de uma DSPL devem ser ligadas em tempo de execuo a um produto com
base em uma anlise que mensura e valida atributos de qualidade em nveis de servios
especificados pelo usurio. Para tanto foi necessria a reviso da literatura existente em
busca de meios de analisar atributos de qualidade de servios em tempo de execuo em
DSPL e o desenvolvimento exploratrio de uma abordagem de reconfigurao da DSPL
utilizando-se das caractersticas dinmicas do OSGi como base em tal anlise. Com a
finalidade de validar a abordagem proposta, a mesma foi testada exploratoriamente em
uma DSPL para o domnio de guia de visitas mveis e sensvel ao contexto, onde podese verificar a assertividade desta. Ao final da validao exploratria pode-se observar
a efetividade da abordagem proposta na DSPL na qual foi aplicada. No entanto, fazse necessrio a execuo de testes estatsticos para comprovar a hiptese de que esta
efetividade demonstrada vlida para outras DSPLs de outros domnios.
Palavras-chave: Linhas de Produto de Software, SPL, SPL Dinmica, DSPL, Qaulidade
de Servios
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
Sumrio
Lista de Figuras
xvii
Lista de Tabelas
xix
Lista de Acrnimos
xxi
Lista de Cdigos Fonte

1
Introduo
1.1
Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Problemtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3
Viso Geral da Soluo . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4
Escopo Negativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5
Organizao da Dissertao . . . . . . . . . . . . . . . . . . . . . . . .
Mtodos
Reviso da Literatura
2.1
Computao Orientada a Servios . . . . . . . . . . . . . . . . . . . .
2.2
Qualidade de Servios . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3
Linhas de Produto de Software . . . . . . . . . . . . . . . . . . . . . .
11
2.3.1
O Estado da Arte em Derivao Dinmica . . . . . . . . . . . .
12
Estudos em Derivao Dinmica . . . . . . . . . . . . . . . . .
13
2.4
A Interao entre SOC e DSPL . . . . . . . . . . . . . . . . . . . . . .
18
2.5
Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
DYMOS QoS
21
3.1
Anlise Exploratria . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.1.1
Operaes do DYMOS . . . . . . . . . . . . . . . . . . . . . .
24
Interveno Exploratria . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.2.1
Seleo de Servios . . . . . . . . . . . . . . . . . . . . . . . .
30
Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.2
3.3
4
xxiii
Avaliao
33
4.1
Validao Exploratria . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.2
Avaliao Estatstica Descritiva . . . . . . . . . . . . . . . . . . . . . .
38
xv
4.3
5
Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
Concluso
5.1 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Limitaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
44
44
45
Referncias Bibliogrficas
xvi
47
Lista de Figuras
1.1
Cenrio do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
2.2
Distribuio Anual de Estudos a Respeito de Derivao Dinmica . . .

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 Sequncia - Reconfigurao de Servios (de Oliveira Martins, 2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DYMOS - Diagrama de Sequncia - Descoberta de Servios (de Oliveira Martins, 2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DYMOS QoS - Diagrama de Pacotes . . . . . . . . . . . . . . . . . . .
DYMOS QoS - Diagrama de Sequncia - Descoberta de Servios . . . .
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 Mximas e Atuais
Custo . . . . . . . . . . . . .
Desempenho do Dymos QoS .
Desempenho do Dymos . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
40
40
41
42
xix
Lista de Acrnimos
DOP
Delta Oriented Programing
DSPL
Linha de Produtos de Software Dinmica
SPL
Linha de Produtos de Software
OSGi
Open Service Gatway Initiactive
SCM
Computao Orientada a Servio
SOA
Arquitetura Orientada a Servio
SEI
Software Engineering Institute
xxi
Lista de Cdigos Fonte
3.1
3.2
3.3
4.1
4.2
4.3
XML de Servios do DYMOS . . . . .

XML de Servios do DYMOS . . . . .
XML de Atributos de Qualidade . . . .
Descoberta de Servios no Lado Cliente
Services XML File . . . . . . . . . . .
QoS Attributes XML File . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
23
29
35
36
37
xxiii
1
Introduo
- Quarenta e dois [...]

Eu verifiquei cuidadosamente e no h dvida de que a resposta essa.
Para ser franco, acho que o problema que vocs jamais souberam
qual a pergunta.
DOUGLAS ADAMS (O Guia do Mochileiro das Galxias)
O legado deixado por Ford com a criao da linha de produtos modificou os meios
de pensar a atividade industrial. No que tange indstria de software, esta, apresenta
tanto uma produo manufatureira quanto em massa que gera produtos que so denotados
segundo Pohl et al. (2005) como software individual e software standard.
Denota-se, neste contexto, uma clara influncia do fordismo na concepo do paradigma de Linhas de Produto de Software (SPL). Neste paradigma os produtos de software
so criados a partir de um conjunto comum de caractersticas, diferenciando-se entre si
pelo gerenciamento de um conjunto de caractersticas variveis 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 so definidas
e implementadas todas as caractersticas que estaro presentes em todos os produtos
chamadas de core assets, assim como as caractersticas variveis que podem ou no
estar em um produto da SPL. Durante a fase de Engenharia de Produto, so selecionadas
para compor o produto alm dos core assets as caractersticas variveis que atendem a
determinados requisitos de usurios que justificam a sua escolha para a composio do
produto.
CAPTULO 1. INTRODUO
O ato de selecionar o conjunto de caractersticas que iro compor o produto e construlo para ser entregue chamado de derivao de produto. Sendo assim, este paradigma de
desenvolvimento no foi concebido para suportar mudanas nos requisitos de usurios
em tempo de execuo. Diante deste problema, a academia tem desenvolvido e proposto
maneiras de estender o paradigma de SPL, de forma a permitir que essas reconfiguraes
dinmicas do software sejam suportadas. Surgiram deste esforo as Linhas de Produto de
Software Dinmicas (DSPL) (Hallsteinsen et al., 2008).
1.1
Motivao
O projeto Ubstructure1 mantm a MobiLine, que uma DSPL para aplicaes mveis
sensveis ao contexto dividida em dois nveis de abstrao: base e especfico. O nvel
base possui caractersticas comuns a aplicaes mveis e sensveis ao contexto. J o nvel
especfico composto por caractersticas que pertencem a um determinado domnio de
negcio (Marinho et al., 2012).
Esta SPL composta por dois produtos: o GREat Tour e o Cin Tour, que so guias de
visitas mveis sensveis ao contexto derivados da MobiLine. Ambos so executados a
partir de dispositivos que possuem o sistema operacional Android e fornecem informaes
sobre os pesquisadores e os ambientes do laboratrio do grupo de pesquisas GREat da
Universidade Federal do Cear e do Centro de Informtica da Universidade Federal de
Pernambuco, respectivamente.
Estes aplicativos utilizam informaes contextuais, como a localizao, o perfil e as
preferncias do usurio visitante. Assim como as requisies desencadeadas por este e as
caractersticas (features) do dispositivo mvel para adaptar seu prprio comportamento.
Parte das caractersticas do produto que variam em tempo de execuo e os core assets da
SPL esto presentes nos dispositivos mveis, enquanto outras caractersticas que variam
em tempo de execuo so ligadas ao produto a partir do acesso a servios Web.
Dentre os objetivos do projeto Ubstructure est a criao de um mecanismo de
adaptao automtico que em tempo de execuo selecione caractersticas da aplicao.
Estas estaro habilitadas para o usurio adapt-las segundo o contexto no qual a aplicao
est inserida. Onde, o funcionamento deste mecanismo pode variar desde baseado em
regras de condio ou at mesmo ser modelado como um problema de otimizao.
O contexto varia entre tipos de aplicaes e seus respectivos domnios. Na MobiLine
considera-se contexto tanto o ambiente fsico no qual o dispositivo mvel est inserido,
1 Projeto
apoiado pelo CNPq (MCT / CNPq 14/2011 - Universal), sob o processo de nmero
481417/2011-7.
1.2. PROBLEMTICA
quanto as informaes a respeito do estado do prprio dispositivo. Estas informaes so

coletadas a partir dos sensores do dispositivo, sendo a localizao geogrfica adquirida a
partir da cmera ou do sensor de sinais NFC.
O estudo de de Oliveira Martins (2013) abordou a problemtica do mecanismo de
reconfigurao e a descoberta de servios criando uma ferramenta chamada DYMOS
framework. Este atua sempre que uma reconfigurao que ocorre no lado cliente exigindo
reconfiguraes nos servios no lado servidor. No entanto, este estudo seleciona os
servios no lado servidor de forma arbitraria, sem realizar nenhuma anlise nos servios
que iro compor a DSPL. O que tratado no trabalho como fora de escopo e possvel
trabalho futuro.
Por outro lado, como apresentado em mais detalhes na Seo 2, a literatura de DSPL
no apresenta uma forma de selecionar as caractersticas que iro a linha de produto em
tempo de execuo com base nas preferncias do usurio. Esta anlise no aborda apenas
a conformidade funcional como tambm a qualidade das caracterstica apresentadas.
1.2
Problemtica
A Figura 1.1 representa o cenrio hipottico que exemplifica a problemtica abordada

neste estudo. Como relatado anteriormente os produtos da MobiLine requisitam em
tempo de execuo as informaes contextuais (coletadas por sensores ou do status do
prprio dispositivo) e recebem estmulos do usurio que junto com essas informaes
definem quais adaptaes em tempo de execuo devem ocorrer.
Quando uma adaptao ocorre no dispositivo mobile duas situaes podem ser desencadeadas: a) a requisio a um web service presente e ativo no lado servidor ou b) a
requisio a um web service ausente ou inativo no lado servidor. Para a situao a), ao
encontrar o servio os produtos da MobiLine o consomem como h de se esperar.
No tocante a situao b), a partir da criao do DYMOS, quando o servio no
encontrado o framework responsvel por procurar um servio para substituir o que
est indisponvel de acordo com uma ordem de prioridade. Caso nenhum dos servios
organizados por prioridade esteja disponvel, qualquer servio que atenda a interface
requisitada pela aplicao mobile disponibilizado para consumo.
No entanto, Alferez and Pelechano (2011) argumentam que web services so executados em ambientes complexos e heterogneos e considerando este fato apropriado que
existam mecanismos de adaptao de acordo com mudanas contextuais que efetuem
reconfiguraes que aumentem a qualidade do servio prestado. Enquanto que, para Lin
CAPTULO 1. INTRODUO
Figura 1.1 Cenrio do Problema
et al. (2010), do ponto de vista empresarial fortemente desejvel maximizar a qualidade

de um servio prestado levando em considerao os diversos entendimentos de o que
qualidade do ponto de vista de diferentes clientes.
Diante disto, o objetivo geral desta dissertao :
Propor uma abordagem de seleo em tempo de execuo das caractersticas
que iro compor uma DSPL com base em uma anlise de seus respectivos
atributos de qualidade
Na busca em atingir este objetivo geral foram definidos trs objetivos especficos: a)
Revisar a literatura a fim de identificar as maneiras pelas quais a derivao dinmica em
DSPL ocorre; b) Desenvolver um mtodo para a avaliao da qualidade e seleo dos
servios em tempo de execuo; c) Avaliar a performance da abordagem proposta.
1.2.1
Mtodos
Esta dissertao baseada na perspectiva filosfica positivista. Nesta perspectiva, as

avaliaes realizadas para a abordagem proposta no objetivo geral observam variveis que
4
1.3. VISO GERAL DA SOLUO
tero sempre os mesmos valores em observaes distintas realizadas por pesquisadores

diferentes. Para que isto seja possvel todos os passos seguidos em direo aos objetivos
especficos so descritos e os valores das variveis de observao disponibilizados. Para
que os objetivos especficos fossem alcanados foi necessrio estabelecer os mtodos
pelos quais este estudo seria guiado. Estes mtodos foram escolhidos de acordo com a
natureza de cada objetivo especfico
O objetivo especfico a) contemplado no Captulo 2. Trata-se de um estudo
bibliogrfico feito com base em revises da literatura estruturadas j publicadas. Procurase nesta parte bibliogrfica do estudo apresentar os principais conceitos abordados neste
estudo, bem como estabelecer o estado da arte para a rea de derivao dinmica em
DSPL.
O relato das etapas referentes ao objetivo especfico b) est presente no Captulo 3
e na primeira parte do Captulo 4. Devido a quantidade de conhecimento sistematizado a
respeito de derivao dinmica de produtos, optou-se pelo uso de mtodos exploratrios
como forma de atingir esse objetivo. Sendo assim, optou-se pela realizao de uma
anlise, uma interveno e uma validao exploratria para a satisfao desse objetivo
especfico.
A fim de atender ao objetivo especfico c), descrito no Captulo 4, optou-se por
um abordagem quantitativa. Esta abordagem expressa na forma de uma avaliao de
performance da abordagem proposta, fazendo uso da descrio estatstica das variveis
de controle e dos resultados observados.
1.3
Viso Geral da Soluo
Para alcanar o objetivo geral desta dissertao a abordagem proposta por de Oliveira Martins (2013) foi ampliada passando a ser chamada de DYMOS QoS. Esta soluo proposta
consiste de uma aplicao desenvolvida em linguagem JAVA e Open Service Gatway
Initiative (OSGi) que avalia individual e coletivamente os atributos de qualidade de
servio disponvel para a reconfigurao da SPL em tempo de execuo.
So levados em considerao enquanto atributos de qualidade para a seleo dos
servios em tempo de execuo: o custo da utilizao de um servio, as capacidades
atuais e totais de carga dos servios e o tempo de resposta. Como critrios de desempate,
so utilizados os atributos de qualidade de disponibilidade e confiabilidade.
A partir desta contribuio possvel modificar a situao b) apresentada na Seo 1.2
e ilustrada na Figura 1.1, de modo que a seleo do servio que substituir o que est
CAPTULO 1. INTRODUO
indisponvel deixa de ocorrer de acordo com a prioridade arbitrada. E passa a acontecer

de acordo com a qualidade dos servios disponveis no momento da requisio. Fica
eleito o servio que apresentar a maior pontuao fornecida pelo framework DYMOS
QoS. Ainda como efeito dessa contribuio, torna-se possvel um terceiro cenrio onde a
requisio por um servio retorna sempre um servio timo para determinado nvel de
servio requerido.
1.4
Escopo Negativo
Alguns tpicos que se relacionam com o objetivo desta pesquisa ou seus objetos no so
influenciados e no influenciam a mesma. Sendo assim, esto fora do escopo do presente
trabalho alguns tpicos como a especificao e implementao de agentes, sejam estes de
hardware ou de software, que responsabilizem-se pela monitorao do contexto onde os
produtos da DSPL esto inseridos.
Assume-se, neste estudo, que existem regras de contexto e derivao de produtos
determinadas. Sendo assim, a criao de tais regras considerada com fora do escopo
abordado. Da mesma maneira, no so abordadas tcnicas de precificao, regras de
estabelecimento de preos ou prazo de vigncia para os mesmos.
Os servios utilizados neste trabalho possuem atributos de qualidade que servem
como insumos para a avaliao dos mesmos. No entanto, o monitoramento de quebra de
acordos de nvel de servio ou de qualquer garantia a respeito dos valores desses atributos
de qualidade tambm so considerados como fora de escopo.
1.5
Organizao da Dissertao
O restante desta dissertao est organizada em quatro captulos. O Captulo 2 trata dos
conceitos bsicos relacionados a rea de SPL alm de apresentar o Estado da Arte em
derivao dinmica e explorar as deficincias desta temtica de pesquisa.
O Captulo 3 trata do desenvolvimento da abordagem proposta. Este captulo inicia
com a descrio do funcionamento do DYMOS, sobretudo no que diz respeito ao seu
mecanismo de descoberta de servios. A segunda parte deste captulo trata de apresentar as modificaes realizadas no framework com a criao dos componentes que so
responsveis pela anlise da qualidade dos servios em tempo de execuo.
No Captulo 4 demonstrada uma avaliao que valida o DYMOS QoS utilizando
os produtos da MobiLine. apresentado ainda, uma avaliao de performance para o
6
1.5. ORGANIZAO DA DISSERTAO
framework.
Por fim, o Captulo 5 encerra esta dissertao sumarizando os passos demonstrados
nos captulos anteriores e relatando o desfecho que foi possvel concluir com relao a
abordagem proposta. apresentado neste captulo as limitaes, contribuies e uma
lista de trabalhos futuros.
2
Reviso 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
comeo quanto o fim.
MATRIX (Dilogo entre Neo e o Arquiteto)
Sero explorados nesse captulo os conceitos utilizados nesta dissertao. Para tanto,
o captulo inicia com uma breve explanao a respeito dos conceitos fundamentais
da Computao Orientada a Servios (SOC). Em seguida so apresentados conceitos
relacionados a abordagem SPL e ento o estabelecimento do Estado da Arte em derivao
dinmica. Finaliza-se, ento com uma explanao crtica a respeito da interao entre
DSPL e SOC.
2.1
Computao Orientada a Servios
Enquanto paradigma computacional, SOC utiliza servios como elementos fundamentais

para o desenvolvimento de software estruturados em uma Arquitetura Orientada a Servios
(SOA). Na perspectiva de Mendona et al. (2013) este paradigma emergiu no intuito de
oferecer maior eficincia proviso 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 servios devem ser organizados, construdos e gerenciados. SOA fundamenta-se na utilizao de servios
como unidades fundamentais, suas respectivas descries e nas operaes de publicao,
descoberta, seleo e vinculao (Papazoglou and Georgakopoulos, 2003).
As arquiteturas orientadas a servios so utilizadas por proverem benefcios como
reusabilidade, flexibilidade, interoperabilidade (Erl, 2007) atravs dos princpios de baixo
CAPTULO 2. REVISO DA LITERATURA
acoplamento, contrato entre servios, descoberta de servios e granularidade alta ou

pequena quantidade de requisies ao servio para o desempenho de uma funcionalidade.
Onde o baixo acoplamento diz respeito ao nmero de dependncias entres os servios e
alcanado a partir da modularizao dos servios fazendo com que sejam acessados
atravs de contratos.
Dentro deste contexto, os clientes (servios e aplicaes que utilizam as funcionalidades providas por um outro servio) aderem aos contratos de comunicao, definidos por
um ou mais servios. Estes contratos consistem de uma descrio das funcionalidades,
caractersticas e formatos de dados do servio. So utilizados, assim, normalmente
formatos padronizados como contratos a exemplo de XML, WSDL e XSD, como afirma
Erl (2005).
Sendo assim, a descoberta de servios ocorre sempre a partir da especificao descritiva dos mesmos (contrato), permitindo a sua localizao e identificao. 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 servio (Josuttis, 2007).
A modularidade e reutilizao providas pelo uso de SOC e SOA permitem que
servios sejam disponibilizados para a utilizao de terceiros ou em sistemas diferentes
dos sistemas para os quais estes foram desenvolvidos. No mbito de transaes comerciais
eventualmente desejvel que a qualidade do servio (QoS) oferecido seja aferida para
que sejam garantidas, por exemplo, clusulas contratuais como a quantidade de resposta
a uma determinada requisio por segundo.
A utilizao de SOC na Web manifesta-se na forma de Web services que um tipo
especfico de servio que que identificado por uma URI (Papazoglou and Georgakopoulos, 2003). Algumas caractersticas comuns a web services que so utilizadas para a
aferio de sua qualidade foram elencadas por DAmbrogio (2006), so elas: latncia,
demanda, rede, controle de acesso, encriptao, disponibilidade e confiabilidade.
2.2
Qualidade de Servios
Um servio Web pode ter vrias implementaes oferecidas por diferentes provedores.
Estas implementaes tm a mesma funcionalidade mas podem ter diferentes valores
para os seus atributos de QoS. Sendo assim, alguns critrios de qualidade podem ter
melhores valores em uma implementao do servio e alguns piores em comparao a
outras implementaes (Tang and Ai, 2010).
10
2.3. LINHAS DE PRODUTO DE SOFTWARE
Mais precisamente, um servio Web pode ser identificado por duas propriedades: funcionalidade e qualidade. Funcionalidade o que o software pode oferecer e tipicamente
representado por um conjunto de operaes providas pelo servio. J a qualidade diz
respeito a o quo bem um provedor de servios pode fazer a entrega das funcionalidades
deste (Yu et al., 2010b).
O termo qualidade utilizado para representar juzos 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 reputao.
Dentro da primeira perspectiva a qualidade vista como um sinnimo de atendimento
a especificaes como tempo de reposta, custo e largura de banda. J na perspectiva de
qualidade enquanto reputao, trabalha-se com a percepo de um usurio a respeito de
um servio em geral.
Papakos and Rosenblum (2010) defendem que em aplicaes cliente em dispositivos
mveis sofrem com mudanas de contexto que podem incluir mudanas nos recursos do
dispositivo, em variveis ambientais e nas preferncias do usurio em tempo de execuo.
Sendo assim, o nvel de QoS exigido inicialmente exigido pelo podem no estar de acordo
com as capacidades do dispositivo em seu contexto atual resultando em um desperdcio
de recursos e um alto custo monetrio.
2.3
Linhas de Produto de Software
Custo, reusabilidade e time-to-marketing so aspectos que preocupam os fabricantes de

software. Por outro lado, a gerncia de configurao de software torna-se cada vez mais
complexa a medida que aumentam as possibilidades de combinaes de caractersticas
(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 caractersticas. O gerenciamento da configurao 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 especficas de um segmento ou misso particular de
mercado e que so desenvolvidos a partir de um conjunto comum de recursos principais
(Core Assets) de maneira prescrita. Os benefcios em adotar o paradigma SPL depende
do contexto no qual ele aplicado. Alguns dos benefcios mais comuns so a reduo do
1 http://www.sei.cmu.edu/productlines/
11
custo e do time-to-marketing promovido pela reutilizao dos core assets dos softwares
da linha.
No obstante, variaes dinmicas em requisitos dos usurios e no ambiente no qual
o software est inserido em tempo de execuo tornam-se cada vez mais frequentes, por
isso existe uma demanda crescente por sistemas capazes de se adaptar automaticamente
ao encontrar essas condies. 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 no gerenciarem a variabilidade durante a fase
de design do software, mas em tempo de execuo.
Uma DSPL representa normlamente cinco caractersticas: a) variabilidade dinmica,
b) a ligao (biding)de elementos da DSPL muda durante o ciclo de vida da aplicao, c)
pontos de variao mudam em tempo de execuo, d) mudanas inesperadas no contexto
e e) so desenvolvidas para um contexto ou ambiente especfico no lugar de um segmento
de mercado (Hallsteinsen et al., 2008).
Opcionalmente, DSPLs podem ser sensveis ao contexto a sua volta (Parra et al.,
2009; Ali et al., 2009; Alferez and Pelechano, 2011), possuir propriedades autonmicas
ou de auto-adaptao (Abbas et al., 2011; Cetina et al., 2008; Abbas, 2011) e tomada
automtica de deciso. Estas caractersticas compem 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 Derivao Dinmica
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 tericos ou metodolgicos. No que diz respeito a
derivao dinmica, vrios pesquisadores tm desenvolvido uma quantidade significante
de estudos para investigar aspectos relacionados a reconfigurao de SPL em tempo de
execuo, que tratada como parte da derivao do produto chamada derivao dinmica
(Parra et al., 2009).
Apesar do termo DSPL ter sido detalhadamente descrito em Hallsteinsen et al. (2008),
pelo menos quatro estudos abordaram a temtica e trataram da derivao dinmica
anteriormente (Kim et al., 2005; Gomaa and Saleh, 2006; Hallsteinsen et al., 2006; Lee,
2006). A partir da utilizao dos mesmos critrios descritos por da Silva et al. (2013)
pode-se observar uma crescente, apesar de pequena, produo bibliogrfica no decorrer
dos anos abordando a temtica de derivao dinmica (Figura 2.1).
No entanto, Buregio et al. (2010) afirma que para a rea de DSPL a maior parte das
12
contribuies esto relacionadas a proposio de solues, em sua maioria concentradas

no desenvolvimento de metodologias. Ao mesmo tempo que no so comuns de serem
encontrados relatos de experincia e pesquisas que possam avaliar a aplicabilidade dos
conceitos de DSPL no contexto industrial. Estas constataes so reforadas no estudo de
da Silva et al. (2013), no que tange aos estudos a respeito de derivao dinmica levando
concluso de que o campo de estudo est ainda em formao.
Figura 2.1 Distribuio Anual de Estudos a Respeito de Derivao Dinmica
A seguir so apresentados estudos publicados entres os anos de 2005 e 2013 que

apresentaram contribuies relevantes para a rea de derivao dinmica em DSPL em
ordem cronolgica. O objetivo desta apresentao expressar a evoluo das tcnicas de
derivao dinmica ao longo do tempo.
Estudos em Derivao Dinmica
Kim et al. (2005) desenvolveram, para um contexto de uma DSPL de jogos para dispositivos mveis, um framework de reconfigurao arquitetural em tempo de execuo
que gerencia a reconfigurao dinmica para ambientes embarcados. A soluo proposta
faz uso de uma linguagem especfica de domnio para descrever o sistema de maneira
esttica 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 customizao dos objetos da interface com o usurio em
tempo de execuo baseada em features selecionadas e valores de variveis parametrizadas. Esta abordagem consiste de uma arquitetura de SPL customizvel baseada no padro
arquitetural cliente/servidor, onde a aplicao cliente contm apenas objetos de interface
com o usurio e um objeto customizador. A aplicao do servidor contm todos os web
13
services responsveis por prover as funcionalidades do sistema e o suporte ao banco de

dados.
Na DAC, a seleo de features direciona a customizao dinmica da arquitetura e a
implementao da linha de produto para a derivao da aplicao. Durante a modelagem
da linha de produto as features e suas dependncias so descritas em um modelo (feature
model). Durante a engenharia da aplicao, features so selecionadas pelo engenheiro de
aplicao e utilizadas para customizar dinamicamente a arquitetura e implementao da
aplicao.
Hallsteinsen et al. (2006) criaram a abordagem MADAM para construo de sistemas
adaptativos. O foco da abordagem est em sistemas distribudos acessados por dispositivos mveis onde a derivao dinmica ocorre a partir de uma arquitetura de referncia.
A plataforma arquitetural que suporta a abordagem pode ser vista na Figura 2.2. O
ncleo dessa arquitetura (Core) composto por um middleware entre os componentes
e a plataforma, e oferece servios para o gerenciamento de componentes, instncias e
recursos. O Context Manager responsvel por monitorar um conjunto de contextos
relevantes no ambiente do sistema enviando e reunindo informaes que so utilizadas
pelo Adaptation manager.
O Adaptation manager responsvel pela avaliao do impacto das mudanas no
contexto sobre a aplicao e determinar quando uma adaptao deve ser efetuada, selecionando as variantes que melhor atendem as novas necessidades impostas pelo contexto. O
configurador (Configurator) responsvel por realizar a configurao inicial da aplicao
e as reconfiguraes, observando quais variantes devem ser instanciadas e desativadas
para alcanar o estado determinado pelo Adaptation manager.
Figura 2.2 MADAM Platform Architecture (Hallsteinsen et al., 2006)
14
Em uma abordagem orientada a features e sistemtica de desenvolver core assets

reconfigurveis dinamicamente, Lee (2006) desenvolvera um reconfigurador que acumula
as funes de monitorar e gerenciar a configurao de um produto em tempo de execuo.
Este autor acredita que a derivao dinmica pode ser realizada agrupando features
em unidades de bind e utilizando um reconfigurador que considera contextos (quando
configurar), estratgias de reconfigurao (como reconfigurar) e aes de reconfigurao
(o que reconfigurar).
Baseado no paradigma SPL Cetina et al. (2008) criou um mtodo para desenvolver
sistemas pervasivos dinamicamente adaptveis. Neste estudo afirma-se que a reconfigurao autnoma do produto pode ser realizada estendendo a abordagem do paradigma
SPL reutilizando a anlise de escopo, caractersticas em comum e variabilidades. A
reutilizao desta anlise utilizada como entrada para um reconfigurador que em tempo
de execuo utiliza o conhecimento contido nesta para realizar a derivao dinmica.
Wolfinger et al. (2008) em uma abordagem que utiliza plugins como features no
domnio de sistemas ERP2 , faz uso de variveis parametrizadas para adaptar o produto em
tempo de execuo. O primeiro artefato a ser gerado para a utilizao dessa abordagem
o conjunto de componentes em forma de plugin. Ento uma ferramenta chamada
DecisionKing empregada para gerar um modelo de variabilidades e outra ferramenta
de nome ProjectKing permite que sejam criados cenrios para configuraes especficas
modelo de variabilidades. Assim, um guia de configurao processa os modelos de
variabilidades com seus respectivos cenrios e apresenta as possveis decises a serem
tomadas em uma interface amigvel para o usurio do software. Por fim, um mecanismo
de descoberta na plataforma de plugins permite ligar e desligar os componentes baseandose nas decises do usurio.
Pukall et al. (2009) desenvolveu a metodologia chamada Feature-oriented Runtime
Adaptation que permite a atualizao de programas em tempo de execuo atravs da
evoluo dos recursos de uma SPL de forma dinmica. Toda a metodologia baseada
em susbstituies de classes em Java utilizando Java HotSwap e reimplementao do
corpo de mtodos.
O relacionamento entre SPL e computao orientada a servio foi claramente utilizado
por Yu et al. (2010a) ao apresentarem uma metodologia para a construo de aplicaes
baseadas em servios para ambientes heterogneos e dinmicos. A metodologia dividida
nas fases de engenharia de domnio, engenharia de aplicao e tempo de execuo.
proposto um processo de desenvolvimento centrado em domnios e orientado a arquitetura
2 Enterprise
Resource Planning
15
inspirada em SPL. na fase de tempo de execuo que, atravs de composio de servios

dinmica, acontece a reconfigurao.
Foi provado ser possvel realizar uma derivao dinmica a partir do compilador
Java no estudo de Sunkle and Pukall (2010). Este estudo utilizou o FeatureJ, que uma
abordagem de implementao de SPL, com uma representao de features e variabilidades
como se fossem tipos de uma linguagem de programao. Esta representao utilizada
como entrada para a derivao do produto em tempo de compilao e execuo. J
Gnther and Sunkle (2010) apresentaram uma maneira de modelar, implementar features,
realizar a composio dinmica destas em tempo de execuo e modificar a SPL e suas
variantes utilizando a linguagem de programao Ruby.
No mbito de sistemas de cuidados com a sade, Carvalho et al. (2010) desenvolveu
uma abordagem para gerenciamento dinmico de variabilidades baseada em contratos
arquiteturais. Estes contratos, especificados na linguagem CBabel, so instanciados em
tempo de execuo de acordo com as variaes no contexto.
Lee and Kotonya (2010) uma continuao do estudo realizado pelo mesmo autor(Lee,
2006) onde descrita uma possvel soluo para a derivao dinmica que relaciona uma
anlise orientada a features e um framework orientado e sensvel a qualidade dos servios
de um SPL. Os autores acreditam que features podem ser mapeadas em servios.
Alferez and Pelechano (2011) desenvolveu um mtodo para projetar e implementar
web services autnomos e sensveis ao contexto em SPL. Os autores argumentam que
se web services forem caracterizados por features, ento a ativao e desativao de
features em tempo de execuo pode guiar a reconfigurao autonmica de composio
de servios a depender de mudanas no contexto. Neste caso, os produtos so uma
composio de servios. Para que seja possvel uma composio de servios, os autores
sugerem a criao de um modelo de composio feito a partir de um diagrama UML de
atividades. Este modelo ilustra os web services e os fluxos de sequncia entre eles que
estabelece a ordem na qual cada web services deve ser ativado.
Gomaa and Hashimoto (2011) descreve uma arquitetura para a adaptao dinmica de
produtos de uma SPL baseado em SOA. Esta arquitetura contm um servio de monitoramento que verifica continuamente o estado do sistema em execuo e o encaminha para o
servio de calibragem, que percebendo uma situao no contexto que necessite de uma
ao envia uma requisio ao dispositivo de seleo dinmica de features. Este dispositivo
determina se existe a necessidade de mudanas na configurao que est sendo executada.
Ele determina dinamicamente as modificaes necessrias para o modelo de features da
aplicao e envia a nova seleo de features para o servio de gerenciamento de mudana.
16
Fica a cargo do servio de gerenciamento de mudanas determinar a diferena entre

a nova seleo de features e a original, determinar os componentes e conectores que
precisar sem adicionados ou removidos e gerar uma sequncia de comandos de adaptao
que correspondem as mudanas 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 criao do produto inicial realizada atravs de adaptaes no projeto.
Uma vez criado e entregue o produto pode ser objeto de adaptaes dinmicas. A
abordagem, que utiliza adaptao a partir de aspectos, feita em duas entidades principais.
A primeira um metamodelo unificado de aspectos utilizados para definir tanto adaptaes
em tempo de projeto quanto em tempo de execuo.A segunda uma plataforma que
realiza de modo transparente as adaptaes 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 contm as informaes
necessrias para a composio, incluindo: a) as localizaes modificadas pela feature,
b) os elementos a serem adicionados e c) o conjunto de modificaes a serem realizadas
para que esses elementos possa ser adicionados.
Rosenmller et al. (2011) apresentaram em seu estudo transformaes de cdigo
para integrar o bind esttico e dinmico de features em SPLs a nvel de modelagem e
implementao. Esta abordagem permite que desenvolvedores mudem flexivelmente o
tempo de bind de cada feature usando o mesmo cdigo como base. As unidades de bind
so geradas estaticamente para reduzir a sobrecarga do processo de derivao dinmica.
Os autores garantem a composio segura do bind dinmico utilizando regras de composio descritas em um modelo de features que contm as regras de reconfigurao que
representam as transformaes de cdigo que so utilizadas para a criao das unidades
de bind dinmico.
Shen et al. (2011) props um mtodo orientado a features para suportar reconfigurao
de variabilidades em tempo de execuo. Neste estudo introduzido o conceito de modelo
de funes, que um nvel intermedirio entre as variantes das features e suas respectivas
implementaes. Durante o processo de adaptao a reconfigurao da feature variante
mapeado no modelo de funes. Neste contexto as funes relacionadas com as
variabilidades podem ser adaptadas para estar disponveis ou indisponveis quando a
reconfigurao em tempo de execuo realizada. Como as funes no podem ser
removidas da aplicao em execuo, o gerenciamento dessas interaes com as funes
mapeadas apoia a reconfigurao.
17
Damiani et al. (2012) apresenta para este campo de estudo os conceitos de Delta
Oriented Programing (DOP). Um produto em particular em uma DOP SPL gerado
aplicando-se as modificaes contidas em mdulos delta adequados para um ncleo de
sistema, que podem sempre ser assumido como vazio. O grfico de reconfigurao define
quais configuraes o sistema pode adaptar em tempo de execuo e descreve como
objetos alocados na pilha precisam ser realocados.
O estudo de Baresi and Milano (2012) demonstra uma maneira de enriquecer as
composies da Business Process Execution Language (BPEL) com o gerenciamento
dinmico de varabilidades. A soluo proposta utiliza a Common Variability Language
(CVL) para aumentar os processos BPEL com variabilidades, que torna possvel a criao
de DSPLs e uma verso dinmica da BPEL para gerenciar e execut-las.
Em 2013 dois estudos a respeito da derivao dinmica foram concludos 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 servio existem algumas abordagens para a reconfigurao desses
servios em tempo de execuo com base em atributos de qualidade. No entanto nenhuma
dessas abordagens utiliza acordos de nvel de servios ou demonstra evidncias de que
podem ser reutilizadas em DSPLs de domnios distintos.
O segundo estudo foi uma dissertao de mestrado (de Oliveira Martins, 2013), onde
foi desenvolvido o DYMOS framework com o propsito de gerenciar variabilidades dinmicas em SPL orientadas a servios e sensveis ao contexto. Este framework possibilita
que servios sejam adicionados ou removidos da configurao do produto em tempo de
execuo por meio de mecanismos de auto-implantao, de modo que o funcionamento
do sistema no seja afetado e que tais modificaes sejam aplicadas e reconhecidas
imediatamente. Possui tambm um mecanismo de descoberta de servios, que prov uma
abstrao entre o cliente e o servio, permitindo efetuar orquestrao de servios e agregar
critrios para a seleo do servio mais adequados, de acordo com uma requisio.
2.4
A Interao entre SOC e DSPL
Pelo fato de SOC e SPL serem paradigmas utilizados com certa frequncia pela comunidade de reuso de software no difcil encontrar na literatura estudos bem sucedidos
que tratam servios como features, onde a determinao de quais servios vo compor
o produto feita atravs do modelo de features selecionado para cada produto a ser
derivado. No entanto, este mapeamento esttico de servios, no atende aos requisitos de
18
2.5. CONCLUSES
dinamicidade de uma DSPL.

notrio que SOA segue um abordagem de reuso e composio de servios enquanto
SPL, apesar de ter como benefcio a reutilizao, corresponde a uma abordagem de construo e decomposio (Parra et al., 2009). Porm as caractersticas antagnicas desses
paradigmas (composio e decomposio) no so conflitantes j que a composio de
servios em uma SPL tradicional ocorre em um momento pr-derivao e a decomposio
ocorre no momento da derivao do produto.
Desta forma, DSPLs tradicionais podem tambm no apresentar dificuldades quanto
a este antagonismo. No obstante, certamente este problema afetar uma DSPL orientada
a servio que precisa decidir com base em alguma anlise (Ex.: prioridade, resposta ao
contexto e QoS) quais servios devem ser plugados em tempo de execuo. Visto que
derivao (decomposio) e composio esto ocorrendo no mesmo momento.
Exemplos de como essa questo tratada podem ser vistos, por exemplo, no estudo
realizado por Yu et al. (2010a), a DSPL orientada a servios faz a anlise de quais
servios compem o produto unicamente verificando a disponibilidade dos servios.
Adicionalmente, o estudo de Lee (2006) apresenta uma DSPL orientada a servios onde
as features so mapeadas em servios. Esta DSPL realiza uma anlise e um planejamento
em tempo de execuo baseados em mudanas contextuais para definir quais features, e
consequentemente quais servios, devem compor o produto.
Em um estudo de cunho exploratrio posterior (Lee and Kotonya, 2010) esta abordagem modificada fazendo com que a anlise em tempo de execuo seja feita com base
em acordos de nvel de servio 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 nvel de servio o framework procura por outro servio
que satisfaa as condies desejadas. No foram expressas no estudo detalhes sobre quais
seriam essas condies (atributos de QoS) ou como a negociao feita.
2.5
Concluses
Este captulo explanou os conceitos relacionados a SOC, SPL e o estabelecimento do

Estado da Arte a respeito da derivao dinmica e sua interao com SOC. A partir disto,
conclui-se que: ausente na literatura estudos que atendam ao cenrio motivacional
descrito na Seo 1.1, ou seja, que definam os servios que vo compor a DSPL orientada
a servio. Com base em uma anlise de atributos de QoS realizada a cada requisio do
usurio.
19
O prximo captulo apresenta a construo de uma abordagem ferramental para tratar

esta lacuna. A abordagem baseia-se na extenso do framework DYMOS, acrescendo-lhe
a capacidade de avaliar e selecionar servios com base em atributos de qualidade.
20
3
DYMOS QoS
Esse caminho no h outro

Que por voc faa
SKANK (Acima do Sol)
Estudos exploratrios so realizados geralmente em reas onde h pouco conhecimento acumulado e sistematizado, como o caso da rea de derivao dinmica em DSPL
relatado no Captulo 2. Este tipo de estudo tambm possui uma natureza de sondagem e
no comporta hipteses que todavia podem surgir no final da pesquisa (Moresi, 2003).
Este captulo apresenta uma anlise e interveno exploratria realizadas no DYMOS,
que um mecanismo de reconfigurao e descoberta de servios apresentado e desenvolvido por de Oliveira Martins (2013). Cada uma das fases desse estudo exploratrio so
apresentadas a seguir.
Vale ressaltar que o framework DYMOS trabalha com features em dois nveis de
abstrao distintos. No primeiro nvel estas features so compostas de uma chamada a um
servio no lado cliente da aplicao e um contrato existe no lado servidor. No segundo
nvel de abstrao as features so todas alternativas e implementadas como servios Web.
Portanto, a fim de evitar mal entendidos, as features de primeiro nvel sero tratadas
por este nome, enquanto as do segundo nvel sero tratadas como servios ou servios
Web. Ainda assim, o framework possui um servio Web chamado ApplicationService
que assim como os outros elementos da arquitetura exibida na Seo 3.1 ser tratado
21
CAPTULO 3. DYMOS QOS
apenas como componente.
3.1
Anlise Exploratria
O framework DYMOS est estruturado como apresentado na Figura 3.1. Essa arquitetura
apresenta um servio Web chamado ApplicationService, o componente ServiceContext, o continer OSGi e trs elementos descritores: o ServiceDescriptor que descreve
o que pode ser plugado em tempo de execuo ao produto da SPL, o VariabilityDescriptor que descreve os pontos de variao e, finalmente, o WSDescriptor que descreve o
WSDL de cada servio Web.
Figura 3.1 DYMOS - Diagrama de Pacotes (de Oliveira Martins, 2013)
O ServiceDescriptor utiliza um arquivo XML como o apresentado no trecho de

cdigo 3.1 para descrever os servios. Este XML contm uma lista de campos estruturados
para cada servio Web como um campo Id fazendo o papel de identificador exclusivo, os
campos serviceSpec e serviceImpl que contm os valores que identificam a interface
e uma implementao para o servio. Cada descrio de servio tem, opcionalmente,
uma lista de servios alternativos que possuem uma referncia para outro servio Web.
Cdigo Fonte 3.1 XML de Servios do DYMOS
<?xml version="1.0"?>
<services>
...
<service id="imageService"
22
3.1. ANLISE EXPLORATRIA

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 cdigo 3.2, define uma lista de variabilidades com uma identificao
(ID) do atributo id, um nome atravs do atributo name e um conjunto de variantes.
Desta forma, uma variante consiste em um ID e um nome de um conjunto de referncias a
servios. Este conjunto de referncias responsvel por manter os servios ativos quando
a variao estiver ativada.
Cdigo Fonte 3.2 XML de Servios do DYMOS
<variabilities>
<variability id="accessMode">
<variant id="infraredMode">
<service-ref ref="hiService" />
</variant>
</variability>
<variability>
<variant id="batteryHalfLife">
<service-ref ref="imageService" />
</variant>
</variability>
</variabilities>
O WSDescriptor usado para operaes de descoberta de servios e sua principal

funo, de acordo com um determinado servio disponvel, descrever os atributos que
no so descritos pelo ServiceDescriptor. E que so especficos para cada implementao de um servio como ServiceName, PortType ou Target Namespace. Assim,
WSDescriptor permite maior flexibilidade ao framework, acrescentando caractersticas
23
dinmicas e levemente acopladas.

O componente ServiceContext faz uso de todos os componentes descritores. A
utilizao destes componentes permite ao ServiceContext obter todas as informaes
descritas na forma de objetos Java, auxiliando-o no gerenciamento de variabilidade e
servios descritos. Esta gesto utiliza as informaes sobre a variabilidade e servios
para manipular o continer 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 nmero de objetos que os clientes necessitam lidar. O objetivo principal do
componente expor operaes, permitindo, assim, a descoberta de servio e a gesto de
variabilidade.
3.1.1
Operaes do DYMOS
O ServiceContext o componente responsvel pelas principais operaes do DYMOS:

reconfigurao de variabilidades, descoberta de servios e ContextHotBuild. A reconfigurao de variabilidades ocorre em resposta a uma variao no contexto no lado cliente
da aplicao que resulta em uma reconfigurao. Em seguida, o DYMOS a partir da sua
operao de reconfigurao adapta o contexto dos servios (lado servidor) para atender
a necessidade da reconfigurao no lado cliente. A sequncia desta operao pode ser
visualizada na Figura 3.3.
A operao de descoberta de servios utiliza como critrio de seleo de servios
Web a prioridade descrita para cada servio alternativo no XML de servios utilizado pelo
componente ServiceDescriptor e a disponibilidade do mesmo no continer OSGi. A
seleo direcionada pelos atributos service-impl, service-spec e priority, que
definido no alternative-service.
Esta operao inicia-se no lado cliente da SPL a partir da invocao do mtodo
getEndPoint do ApplicationService (ver Figura 3.2). O mtodo em questo recebe
como parmetro o ID do servio desejado que passado para o SeviceContext, onde a
requisio tratada com base nas informaes passadas pelo ServiceDescriptor. Logo,
o ID passado como parmetro deve ser o ID de um servio descrito no XML de servios.
de responsabilidade do ServiceContext enviar requisio ao continer OSGi
utilizando como base os atributos service-ref, service-impl e alternative-service
com a finalidade de encontrar um servio que seja satisfatrio para a invocao feita ao
mtodo getEndPoint. O processo de seleo do servio Web ocorre em trs fases:
24
3.1. ANLISE EXPLORATRIA
Figura 3.2 DYMOS - Diagrama de Sequncia - Reconfigurao de Servios (de Oliveira Martins,
2013)
busca por um servio Web que satisfaa a especificao e implementao definida

nos atributo service-spec e o service-Impl;
busca por um servio alternativo, levando em considerao a prioridade definida
no atributo priority;
busca por qualquer servio presente no continer OSGi que satisfaa a especificao
desejada.
A execuo das fases de seleo, apresentadas anteriormente, sequencial. No entanto
s acontecer a execuo de uma fase subsequente caso a fase anterior seja incapaz de
encontrar um servio adequado. Aps a seleo do servio Web, o ServiceContext
interage com o componente WSDescriptor passando como parmetro o endereo onde o
servio selecionado encontra-se e recebendo como resposta o end point, o name space e
o nome do servio. Estes dados so retornados para o lado cliente da DSPL.
Outra operao do DYMOS a ContextHotBuild. Esta a operao responsvel pelas operaes de bind em tempo de execuo. Todos os servios Web que so tratados pela
25
Figura 3.3 DYMOS - Diagrama de Sequncia - Descoberta de Servios (de Oliveira Martins,
2013)
DSPL como features de segundo nvel esto empacotados em bundles OSGi, tornando
possvel 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 operao de ContextHotBuild a partir
do gerenciamento do ciclo de vida dos bundles.
3.2
Interveno Exploratria
Visto que, na perspectiva de Khezrian et al. (2010), por um lado a descoberta de servios
permite que a relao entre cliente e servios no seja tratada de forma fixa ou acoplada,
com vistas seleo de um servio mais adequado baseado em critrios estabelecidos.
Por outro lado, a descoberta de servios no DYMOS apesar de efetiva pode no ser a
ideal ao considerar apenas um critrio para a seleo dos servios.
importante pontuar que a utilizao da prioridade como critrio nico alm de
limitar a descoberta de servios a torna arbitrria e delega ao engenheiro de software a
responsabilidade de determinar qual servio deve ser plugado ao produto em tempo de
26
3.2. INTERVENO EXPLORATRIA
execuo na fase de design da aplicao. Este cenrio pode caracterizar uma perda de
dinamicidade para a DSPL. Com base nesta observao e no intuito de atingir o objetivo
de propor uma abordagem de seleo em tempo de execuo das caractersticas que iro
compor uma DSPL e com base em uma anlise de seus respectivos atributos de qualidade,
prope-se estender o DYMOS, passando a denomina-lo de DYMOS QoS.
A proposta de extenso consiste em modificar a situao b) apresentada na Seo 1.2.
Nesta situao a seleo de servio para substituir o servio indisponvel ocorre de acordo
com a prioridade arbitrada. Prope-se que a seleo de servios ocorra de acordo com a
qualidade dos servios disponveis no lado servidor no momento em que a solicitao
realizada no lado cliente.
Assim, ser selecionado o servio que tiver a maior pontuao fornecida pelo DYMOS
QoS. Esta nova abordagem torna possvel que uma terceira situao ocorra, onde sempre
que realizada uma requisio a um servio no lado cliente, o servio retornado ser
sempre o que tiver a melhor avaliao dos atributos de qualidade no nvel de servio
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 informaes contextuais sobre os servios Web de forma estruturada
em um arquivo XML e atualiza essas informaes de acordo com as mudanas que
ocorrem no contexto. O componente Broker responsvel por analisar os atributos de
qualidade para cada servio em tempo de execuo durante a descoberta de servios.
Figura 3.4 DYMOS QoS - Diagrama de Pacotes
27
A fim de que seja possvel ao Broker realizar essa anlise, o componente ServiceLevelProvider armazena em um XML alguns atributos de qualidade, tais como nvel de
servio, capacidade mxima, a capacidade atual, tempo de resposta e custo. A anlise
do Broker calcula a utilidade (Yu and Lin, 2005) de cada servio no nvel de servio
escolhido e envia esta informao para o componente ServiceContext, que continua
sendo o principal responsvel pelo processo de descoberta de servios.
Esta interveno requer uma modificao no componente ServiceContext de modo
que durante a execuo do mtodo findAlternativeService a prioridade descrita no XML
de servios deve ser desconsiderada, os atributos de qualidade de cada servio devem ser
recuperadas e a utilidade de cada servio deve ser calculada.
Figura 3.5 DYMOS QoS - Diagrama de Sequncia - Descoberta de Servios
A Figura 3.5 ilustra como essa modificao afeta a sequncia da execuo do processo
de descoberta de servios. Ao perceber que a implementao do servio requisitado no
28
3.2. INTERVENO EXPLORATRIA
est presente no continer OSGi, o ServiceContext requisita ao ServiceLevelProvider

a lista dos servios alternativos com seus respectivos valores para os atributos de qualidade
estruturados dentro de objetos AlternativeServiceQoS.
Os atributos de qualidade tm valores distintos para cada servio em cada nvel
de servio, como apresentado no Cdigo 3.3 que representa o XML de atributos de
qualidade utilizado pelo ServiceLevelProvider. Os atributos de qualidade dos servios
utilizados nessa abordagem so: custo, capacidade mxima e atual, nvel, tempo de
resposta, confiabilidade e disponibilidade.
Cdigo Fonte 3.3 XML de Atributos de Qualidade
...
<serviceLevel id="1">
<cost>2,07</cost>
<curCapacity>0</curCapacity>
<level>1</level>
<maxCapacity>42</maxCapacity>
<name>imageService1</name>
<responseTime>23379</responseTime>
<serviceSpec>com.assertLab.imageService</serviceSpec>
</serviceLevel>
<cost>0,29</cost>
<level>2</level>
</serviceLevel>
...
Apesar da nomenclatura dos atributos de qualidade dizer muito a respeito dos mesmos,
estes no so suficientes para evitar interpretaes distintas. Por isso, vale ressaltar
que o atributo de custo representa o custo de um determinado servio em um dado
nvel de servio. Esta abordagem no determina como o custo do servio deve ser
definido, possibilitando a utilizao do DYMOS QoS de acordo com diversos modelos
de precificao.
Os atributos de capacidade mxima e atual representam respectivamente quantos
29
clientes ao mesmo tempo podem utilizar e quantos esto utilizando um servio em um

determinado nvel de servio. O atributo nvel refere-se ao nvel de servio 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 servio no
nvel de servio em questo.
Os atributos de nome e especificao do servio, tem funo meramente identificadora. Enquanto os atributos de confiabilidade e disponibilidade so baseados em dados
histricos. O valor do primeiro incrementado sempre que o servio requisitado responde
a uma requisio em tempo igual ou menor ao especificado no atributo de tempo de
resposta e decrementado quando ocorre o contrrio. O atributo de disponibilidade
incrementado sempre que uma requisio a um servio tem uma resposta e decrementado
quando o servio se mostra indisponvel.
3.2.1
Seleo de Servios
De acordo com o que j foi explanado, o componente Broker responsvel por realizar
as anlises dos atributos de qualidade dos servios Web. O Broker do DYMOS QoS
derivado das abordagens de Chen et al. (2003); Yu and Lin (2004, 2005), onde cada
provedor de servios Web oferece diversos nveis de servio para cada funcionalidade.
Nesta abordagem fica sob a responsabilidade do Broker coletar as informaes a
respeito dos candidatos a provedores de servio. Para tanto, este componente, apanha as
definies de servio e nvel de servio dos clientes e ento realiza uma verificao nos
compromissos de qualidade oferecidos pelos servios.
O Broker utiliza uma funo para a otimizao da seleo dos servios Web chamada por Yu and Lin (2004, 2005) de funo de utilidade. Esta funo baseada em
um conjunto de parmetros que englobam informaes estticas (nvel de servio), as
necessidades de qualidade do lado cliente e a capacidade dinmica do servidor (carga).
Para que seja possvel o entendimento da funo de utilidade algumas definies
precisam ser esclarecidas. A primeira delas que servios Web que oferecem a mesma
funcionalidade podem ter caractersticas no funcionais distintas. O conjunto desses
servios que oferecem a mesma funcionalidade chamado de classe de servio e denotado
por S, sendo cada servio de uma classe denotado individualmente por s. O nvel de
servio oferecido por um nico servio Web denotado por l. A confiabilidade uma
restrio de qualidade a respeito do atraso no provimento de um servio denotada por R.
Cada servio Web tem suas prprias definies. O nmero de nveis de servio que
cada servio Web oferece obtido a partir da definio L(s) e o tempo de servio
30
3.3. CONCLUSES
denotado por e(s, l). As definies adotadas a respeito da carga de cada servio so
Cmax (s, l) e Ccur (s, l), onde o primeiro denota a capacidade mxima e o segundo a carga
atual em um determinado nvel de servio. Por fim, o custo para cada nvel de servio
denotado por c(s, l).
A funo de utilidade toma as decises de seleo com base na funo de benefcio
(Equao 3.1), que por sua vez baseia-se na carga do servio. A funo utilizada para
que os servios selecionados tenham uma baixa carga, oferecendo assim menores tempos
de resposta reais. Isso implica em um balanceamento global das cargas dos servios
evitando sobrecargas.
b(s, l) =
Cmax (s, l) Ccur (s, l)

Cmax (s, l)

3.1
A funo de utilidade pode ser vista na Equao 3.2, onde wb e wc so os pesos de um

benefcio de custo, b(s, l) e c(s, l) so os benefcios e os custos, escolhendo servio s no
nvel de l, avgb e avgc so o benefcio mdio e o custo mdio para os servios disponveis
no nvel de servio escolhido, e, finalmente, stdb e stdc so o desvio padro de benefcio
e custo. O objetivo dessa funo maximar o benefcio e minimizar o custo no momento
de uma seleo de servio.
F(s, l) = wb (
3.3
b(s, l) avgb
c(s, l) avgc
) + wc (1
)
stdb
stdc

3.2
Concluses
Este captulo tratou da anlise e interveno exploratria realizadas para contribuir com
os objetivos deste estudo apresentando um entendimento do processo de descoberta de
servios do DYMOS e a classificao das features utilizadas por este. Partindo desta
anlise foi possvel construir uma abordagem de descoberta de servios com base na
anlise de atributos de QoS.
A anlise implementada para a seleo de servios fundamentada na idia de que um
componente pode atuar como mediador avaliando a necessidade do cliente e encontrando
um servio que melhor se enquadre nesta necessidade. O trabalho do componente
mediador (Broker) regido pela relao custo-benefcio especificada na forma de
funes matemticas definidas por Yu and Lin (2004, 2005). O prximo captulo trata
da de uma validao realizada com a abordagem aqui proposta para demonstrar a sua
efetividade. Assim como relatada uma avaliao da performance da mesma.
31
4
Avaliao
O poder permanece onde os homens crem que ele deve permanecer.

GEORGE R. R. MARTIN (A Fria dos Reis, As Crnicas de Gelo e
Fogo)
A fim de avaliar a abordagem proposta no Captulo 3 foram desenvolvidas uma

validao e uma avaliao quantitativa, ambas apresentadas nesse captulo. A primeira de
natureza aplicada e exploratria quanto aos objetivos. Para esta procura-se demonstrar o
DYMOS QoS em ao na DSPL Mobiline relatada no Captulo 1.
A avaliao quantitativa de natureza bsica e descritiva no que diz respeito aos
fins. Estudos descritivos, de uma maneira geral, expem caractersticas de determinada
populao ou de determinado fenmeno, podendo estabelecer correlaes entre variveis
e definir sua natureza. No obstante, no tem compromisso de explicar os fenmenos
descritos sem excluir a possibilidade de servir como base para faz-lo (Moresi, 2003).
4.1
Validao Exploratria
Os produtos da Mobiline foram os objetos da validao exploratria. Para isso, primeiro

foi necessrio adequar o lado do cliente da DSPL e posteriormente configurar o DYMOS
QoS, assim construindo os arquivos XML necessrios aos componentes descritores e ao
ServiceLevelProvider.
O GREatTour e o Cin Tour so guias de visitas mveis sensveis ao contexto derivados
da MobiLine. Ambos so executados a partir de dispositivos que possuam o sistema
operacional Android e fornecem informaes sobre os pesquisadores e os ambientes do
laboratrio do grupo de pesquisas GREat da Universidade Federal do Cear e do Centro
de Informtica da Universidade Federal de Pernambuco, respectivamente.
33
CAPTULO 4. AVALIAO
Estes aplicativos utilizam informaes contextuais, como localizao, perfil e preferncias do usurio visitante, assim como as requisies desencadeadas por este e as
caractersticas do dispositivo mvel para adaptar seu prprio comportamento. Parte das
caractersticas do produto que variam em tempo de execuo e os core assets da SPL
esto presentes nos dispositivos mveis, enquanto outras caractersticas que variam em
tempo de execuo so ligadas ao produto a partir do acesso a servios Web.
Figura 4.1 GreatTour - Modelo de Features
Uma viso geral das features desses dois produtos so apresentadas nas Figura 4.11 e
Figura 4.2. O Cin Tour uma verso mais leve do Great Tour, diferindo deste por no
apresentar as features de autenticao, de vdeo e de captura da localizao do usurio
utilizando a tecnologia NFC.
A chamada aos servios do lado servidor da SPL deve ser feita a partir da utilizao
das bibliotecas KSOAP2 e DymosClientLib. Esta ltima possui uma classe chamada
VariabilityContex, que permite o suporte a reconfigurao de variabilidades dinmicas
e a classe ServiceEndpointFactory que suporta a descoberta de servios. H tambm a
1 Disponvel
em: http://goo.gl/weMfAf
2 https://code.google.com/p/ksoap2-android/
34
4.1. VALIDAO EXPLORATRIA
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 servio Web.
O Cdigo 4.1 apresenta como deve ser feita uma requisio a um servio Web no
DYMOS QoS. Primeiro necessria a criao de um objeto ServiceEndPoint que
recebe o retorno do mtodo getEndPoint() da classe ServiceEndPointFactory. Este
mtodo recebe como parmetro o nome da variante ou da interface para o servio desejado
e o nmero referente ao nvel de servio esperado.
Cdigo Fonte 4.1 Descoberta de Servios 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
CAPTULO 4. AVALIAO
Para a abordagem do DYMOS QoS ser totalmente funcional cada vez que um servio
estiver para ser chamado no lado do cliente, o nvel de servio desejado e o end point
desse servio precisa ser atualizado. Isso feito atravs de uma chamada para os mtodos
requireLevel() e getServiceEndPoint() do servio Web ApplicationService do framework
que ocorre por meio do mtodo getEndPoint no lado cliente.
Para exemplificar o funcionamento dos QoS DYMOS em uma situao real, a variante
ImageService foi ativada e todos os seus servios alternativos descritos na Listagem
4.2 com o custo, a capacidade mxima (Cmax), a capacidade atual (cCurr) e o valor da
funo de utilidade (UF) mostrados na Tabela 4.1. Isto posto, foi possvel experimentar o
framework nas trs situaes descritas na Seo 1.3.
Cdigo Fonte 4.2 Services XML File
<services>
...
<service id="imageService" serviceimpl="com.assertLab.imageServiceImpl">
<servicespec>com.assertLab.imageService</servicespec>
<alternativeservice ref="imageService1" />
</service>
<service id="imageService1" serviceimpl="com.assertLab.imageService1">
</service>
</service>
</service>
</service>
36
4.1. VALIDAO EXPLORATRIA

</service>
...
</services>
</variabilities>
Cdigo Fonte 4.3 QoS Attributes XML File
...
<cost>2,07</cost>
<level>1</level>
</serviceLevel>
<cost>0,29</cost>
<level>2</level>
</serviceLevel>
...
Tabela 4.1 Valores de 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 validao certificar que o comportamento do framework ficou

inalterado no que diz respeito a situaes onde a descoberta de servios alternativos no
se faz necessria. Neste caso, uma requisio ao end point da variante ImageService
37
CAPTULO 4. AVALIAO
feita no produto Mobiline. O ServiceContext utiliza os componentes descritores

do framework para identificar a implementao e a especificao da variante. Assim, o
ServiceContext verifica a disponibilidade do servio no continer OSGi e envia o end
point para o dispositivo mvel.
Nenhum problema foi detectado durante a execuo deste primeiro passo e o end
point retornado foi o do servio imageService, como era esperado. Diante disto, o
primeiro passo da validao foi concludo, restando para ser realizado o passo que utiliza
a descoberta de servios alternativos.
No que se refere ao segundo passo, este verifica se a seleo do servio que substituir
o que est indisponvel deixa de ocorrer de acordo com a prioridade arbitrada e passa a
acontecer de acordo com a qualidade dos servios disponveis no momento da requisio.
Fica eleito o servio que apresentar a maior pontuao fornecida pelo framework.
Para avaliar esta segunda situao o servio ImageService foi inativado no continer
OSGi e mantidos todos os servios alternativos ativados. Quando uma solicitao para o
end point desta variante feito o ServiceContext requisita ao Broker uma lista de
servios alternativos e suas respectivas pontuaes para a funo de utilidade. Assim, o
ServiceContext retornar o end point exigido para a variao, considerando o servio
ativo com a maior pontuao na funo de utilidade no continer OSGi.
Neste caso, o servio escolhido foi o imageService1. Esta resposta denota que a
escolha do framework foi correta, visto que este era o servio com o maior valor para a
funo de utilidade, como demonstrado na Tabela 4.1.
Um terceiro cenrio foi proposto na Seo 1.3, onde uma requisio oriunda do cliente
por um end point retorna sempre o servio com melhor qualidade. Neste caso entede-se
melhor qualidade o servio com maior valor na funo utilidade.
Para que esse terceiro cenrio acontea, o servio prioritrio deve ser substitudo por
um servio sem implementao e ser colocado junto dos servios alternativos. O que
implica no registro de seus atributos de qualidade no XML de atributos de qualidade.
Este terceiro cenrio tambm validado pelo segundo passo, visto que no existem
alteraes no fluxo de execuo do DYMOS QoS. O que ocorre neste caso apenas uma
deciso de no manter um servio prioritrio por parte do engenheiro de software.
4.2
Avaliao Estatstica Descritiva
A avaliao estatstica descritiva tem cunho quantitativo, o que implica afirmar que toda
ela baseada na filosofia positivista. Onde as variveis a serem observadas so conside38
4.2. AVALIAO ESTATSTICA DESCRITIVA
radas objetivas e portanto diferentes observadores em outras visualizaes encontraro

os mesmos resultados aqui apresentados. Por se tratar de uma observao numrica
elimina-se a possibilidade de desacordo a respeito dos valores dessas variveis (Wainer,
2007).
A ausncia de um conjunto de dados reais a respeito da performance de outras
tcnicas de seleo de servios no mbito da rea de DSPL cerceiou a possibilidade de
experimentao estatstica para avaliar a abordagem proposta nesta dissertao. Diante
disto, optou-se pela criao de um benchmark com o intuito de aferir a performance do
DYMOS QoS.
O benchmark consiste em uma classe de servios contendo 100 servios Web no
formato de bundles OSGi e conjuntos de 4 nveis de servio para cada servio Web.
Cada nvel de servio contm um identificador, um custo, a capacidade mxima e atual, o
nome e a especificao do servio e o tempo de resposta.
O identificador, o nome e a especificao dos servios so dados categricos. Para
esse tipo de dado no existe sentido em fazer outra operao a no ser a verificao do
valor dos mesmos. Esses dados tem a nica funo de identificar a qual servio pertencem
durante o processo de descoberta de servio.
O nvel de servio uma medida ordinal. Neste caso, alm de ter fins de categorizao
permite uma ordenao dos valores. Os nveis de servio utilizados neste benchmark esto
compreendidos entre os valores 1 e 4, incluindo-os. Os dados referentes capacidade,
o custo e o tempo de resposta so medidas de razo e no possuem nenhuma funo de
categorizao, mas operaes matemticas 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 mxima e atual so inteiros positivos no maiores que 50, o tempo de resposta
representados em milissegundos tambm um inteiro positivo no maior que 61000,
51000, 31000 e 11000 para os nveis de um a quatro respectivamente. O custo sempre
um frao positiva maior que zero e menor que dez.
A Figura 4.3 apresenta graficamente a distribuio do tempo de resposta mximo
oferecido por cada servio. Nesta evidenciada a concentrao de menores tempos de
resposta nos nveis 3 e 4, ao passo que os maiores tempos de resposta encontram-se nos
nveis 1 e 2. Contudo, notrio mesmo os nveis de servio 1 e 2 apresentam tempos de
resposta mximos to baixos quanto os outros nveis.
A Tabela 4.2 apresenta os valores mdios, medianos e os desvios padro dos servios
Web em cada nvel de servio. A Tabela 4.3, de maneira anloga, apresenta esses mesmos
39
CAPTULO 4. AVALIAO
valores em relao aos custos praticados pelos servios Web. Tanto as capacidades quanto
os custos da amostra gerada apresentam mdias e medianas similares entre si, o que pode
ser um indicativo de que estes dados tem uma distribuio normal de probabilidade.
Tabela 4.2 Capacidades Mximas e Atuais
Level
1
2
3
4
Mdia
Mxima Atual
25,64
13,25
25,14
12,48
24,78
11,11
26,98
13,98
Mediana
Mxima Atual
25
12
24,5
7,5
24
8,5
27,5
11
Desvio Padro
Mxima
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
Mdia
4,82
5,20
5,48
4,99
Mediana
4,56
5,09
5,71
4,97
Desvio Padro
2,74
2,74
2,73
2,86
Todos os 100 servios do benchmark foram postos dentro do continer OSGi e

registrados nos arquivos XML dos descritores do DYMOS QoS. Aps isso 100 execues
foram realizadas com 4 subgrupos da populao de servios. O primeiro subgrupo possua
5 servios, o segundo 10, o terceiro 50 e o ltimo foi composto por toda a populao.
Todas as execues foram realizadas em um notebook com um processador A6 com
6 GB de memria RAM, sistema operacional Windows 8, Java Virtual Machine (JVM) e
40
4.3. CONCLUSES
Java Development Kit (JDK) 1.7. Antes da extrao dos tempos de execuo foi realizado
o Warm Up do ambiente, executando cada subgrupo da populao de servios duas
vezes utilizando como parmetro para a JVM -XX:+PrintCompilation, -verbose:gc e
-XX:CICompilerCount=1.
Para que se pudesse ter uma medida mais exata do tempo de execuo do DYMOS
QoS durante o processo de seleo de servio com bases nos atributos de qualidade
apresentados as medidas foram feitas em nanosegundos. A Figura 4.4 apresenta o
desempenho para cada execuo em todos os subgrupos.
A Tabela 4.4 apresenta os valores mdios, medianos e de desvio para cada um dos
subgrupos alm do desempenho relativo entre eles. O desempenho relativo representado
pelo percentual da quantidade de tempo de execuo mdia da seleo de servios no
DYMOS QoS com relao ao desempenho anterior.
Como pode ser observado, o tempo de execuo para o subgrupo com 50 servios
Web foi 84% menor em relao ao subgrupo com 100 servios e 472% maior com relao
ao subgrupo com 10 servios. Esta informao evidencia que a abordagem utilizada pode
no ser escalonvel.
O mesmo procedimento de avaliao foi realizado com o DYMOS Framework com a
diferena de que os nveis de servio e seus respectivos atributos no foram utilizados. O
resultado destas execues podem ser vistas Tabela 4.5. Ao se comparar os desempenhos
do DYMOS Framework com o DYMOS QoS, fica ntido que o problema de escalabilidade apresentado no DYMOS QoS no oriundo do DYMOS Framework, mas sim da
interveno exploratria realizada nesta dissertao.
Tabela 4.4 Desempenho do Dymos QoS
Qauntidade
de Sevios
100
50
10
5
4.3
Mdia
Mediana
Desvio Padro
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
Concluses
Este captulo apresentou uma validao exploratria da abordagem proposta e uma avaliao estatstica de desempenho. Pode-se concluir a partir da validao que a abordagem
41
CAPTULO 4. AVALIAO
Tabela 4.5 Desempenho do Dymos
Qauntidade
de Sevios
100
50
10
5
Mdia
Mediana
Desvio Padro
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 esforo para ser adotada pela
DSPL. Vale salientar, no entanto, que apesar dos indcios de que a abordagem seja compatvel com outras DSPLs, esta no uma afirmao que possa ser feita com base nesta
validao.
A avaliao estatstica descreve em termos quantitativos o desempenho da abordagem
proposta. Pode-se concluir, a partir da observao do comportamento do DYMOS QoS
que a abordagem pode no ser escalonvel. Fato devido ao tempo gasto para a descoberta
dos servios em classes grandes de servio que se apresenta relativamente maior do que
o esperado quando comparado com classes de servios menores.
Vale salientar ainda, que os dados utilizados para a execuo da avaliao de performance so dados gerados. Portanto existe um risco de que esses dados apresentem um vis
que pode ser considerado com uma ameaa a validade do estudo. Outra limitao o fato
de no estar disponvel na literatura nenhum outro benchmark ou abordagem relacionada
disponvel para uma comparao dentro de um desenho experimental adequado.
42
5
Concluso
Eu que no me sento
No trono de um apartamento
Com a boca escancarada
Cheia de dentes
Esperando a morte chegar
RAUL SEIXAS (Ouro de Tolo)
Neste captulo final sero apresentadas as contribuies, limitaes e uma breve

explanao a respeito dos trabalhos futuros. Esta dissertao foi iniciada com uma
contextualizao a respeito da temtica abordada, junto com a problematizao e a
descrio dos mtodos utilizados para que os objetivos fossem alcanados no Captulo 1.
Neste mesmo captulo ficou estabelecido que o objetivo deste trabalho era propor uma
abordagem de seleo, em tempo de execuo das caractersticas que iro compor a DSPL
com base em uma anlise de seus respectivos atributos de qualidade.
No Captulo 2 foram explanados os termos que pertencentes rea de SPL e SOC,
para mlehor compreenso e aplicao destes. Posteriormente, foi apresentado o estado
da arte no que tange derivao dinmica em DSPL, elencando os estudos que j
foram publicados a respeito na rea em ordem cronolgica. Este captulo encerrou com
uma discusso em torno das limitaes das contribuies dos estudos que tratam sobre
derivao dinmica em DSPLs orientadas a servio, apresentando a lacuna na qual esta
pesquisa esteve centralizada.
A este ponto, dada a ausncia de trabalhos na literatura que atendessem a necessidade
de definir os servios com base na requisio de usurios e ao mesmos tempo ao objetivo
estabelecido, foi proposta a abordagem do DYMOS QoS no Captulo 3. Neste captulo
43
CAPTULO 5. CONCLUSO
so apresentadas as modificaes realizadas no DYMOS e a incluso dos componentes

responsveis pela realizao da seleo de servios em tempo de execuo com base nos
estudos de Chen et al. (2003); Yu and Lin (2004, 2005).
No Captulo 4 ocorre tanto a validao exploratria quanto a avaliao estatstica
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 servios a serem avaliados em tempo de execuo.
5.1
Contribuies
A primeira contribuio deste trabalho a criao de uma abordagem de seleo, em

tempo de execuo das caractersticas (servios) que iro compor a DSPL com base
em uma anlise de seus respectivos atributos de qualidade. Esta abordagem utilizase de procedimentos que j estavam presentes no processo de derivao de produtos
da Mobiline, agregando apenas como responsabilidade do engenheiro de software a
necessidade de descrever os atributos de qualidade dos servios.
Outra contribuio o fornecimento de um mecanismo que permite a seleo de
servios com base na abordagem de Chen et al. (2003); Yu and Lin (2004, 2005). Este
mecanismo ser licenciado como cdigo aberto e disponibilizado no site do autor desta
dissertao1 . O benchmark utilizado para a avaliao da proposta de domnio pblico e
disponibilizado junto com o software sob a mesma licena, caracterizado assim a ultima
contribuio desta dissertao.
5.2
Limitaes
Wazlawick (2009) classifica em cinco categorias os estilos de pesquisa correntes em

Cincia da Computao: apresentao de um produto, apresentao de algo diferente,
apresentao de algo possivelmente melhor, apresentao de algo reconhecidamente
melhor e apresentao de uma prova. Dentro dessa classificao esta dissertao enquadrase na categoria de apresentao de algo diferente.
Esta classificao justifica-se pela primeira contribuio deste estudo que apresentar
uma maneira diferente de resolver o problema da seleo de servios em tempo de
execuo em uma DSPL orientada a servios. Segundo o mesmo autor (Wazlawick,
2009), este tipo de pesquisa caracterstico de reas emergentes e os trabalhos so
apresentados como comparaes, mais comumente qualitativas, entre tcnicas.
1 www.cin.ufpe.br/
44
jrfs/dymosqos
5.3. TRABALHOS FUTUROS
O estado da arte realizado na Seo 2.3.1 apresenta estudos como apresentao de um

produto ou de algo novo, o estgio mais bsico da classificao de (Wazlawick, 2009).
Estes estudos apresentam abordagens avaliadas qualitativamente dada as suas respectivas
aplicaes em determinadas linhas de produto. No possvel assegurar portanto que
estas mesmas abordagens funcionem em outros contextos e com outras linhas de produtos,
o que um indcio de falta de maturidade na rea de DSPL em derivao dinmica em
DSPLs orientadas a servio.
Esta constatao 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 ento apresentam como
contribuio o desenvolvimento de metodologias e propostas de solues para situaes
especficas. Estas solues no esto disponveis em local pblico para o uso por parte
dos outros pesquisadores, impossibilitando uma comparao entre abordagens.
Estas limitaes no campo de estudos de DSPLs, tornaram-se um fator limitante para
o estudo desenvolvido nesta dissertao. A ausncia de outras ferramentas e de dados
mais detalhados a respeitos de outras abordagens impossibilitou a criao de um desenho
experimental rebuscado para o estudo aqui apresentado. Um benchmark de servios e
seus respectivos atributos de qualidade foi criado para mitigar esse problema e contribuir
para que a rea de derivao dinmica em DSPL evolua para um novo estgio dentro da
classificao de Wazlawick (2009).
A criao e manuteno de um benchmark uma tarefa nobre na opinio de Wainer
(2007). No entanto, benchmarks gerados por ferramentas podem conter um vis. Os
indcios de normalidade probabilstica relatados no final do Captulo 4 pode indicar um
vis o que se apresenta como uma limitao desse conjunto de dados.
Tambm foi realizada uma breve pesquisa na rea de SOC a procura de abordagens
que estivessem publicados os seus dados para que fosse possvel a comparao. Mas
igualmente, no houve sucesso no que diz respeito a esta busca.
5.3
Trabalhos Futuros
As limitaes da rea de pesquisa desta dissertao representam um conjunto de oportunidades de pesquisa que no deve deixar de ser levado em considerao. Basta olhar para
as reas de carncia 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 derivao dinmica em si carecem do desenvolvi-
45
CAPTULO 5. CONCLUSO
mento de modelos, ferramentas, algortimos e discusses conceituais. Os principais tipos

de estudos ausentes so relatos de experincia, pesquisas de validao e avaliao.
Um caminho de pesquisa que parece interessante a identificao de outras abordagens de descoberta de servios utilizando tcnicas de composio ou de inteligncia
artificial, como algortimos genticos, por exemplo. A comparao entre essas outras
tcnicas em diversos contextos de DSPL podem trazer resultados cientficos relevantes.
Outro caminho que pode ser trilhado o estudo de como uma DSPL para dispositivos
mveis pode se tornar um sistema autnomo nos termos do ciclo MAPE-K, especificado
pela IBM (2006). Diminuindo assim, a necessidade de interveno humana na derivao
dinmica da DSPL ao passo que esta torna-se mais assertiva e menos onerosa.
Estudar a sinergia entre DSPLs orientadas a servios e a rea de estudos das Social
Machines pode ter resultados cientficos relevantes. Visto que a descoberta de servios
poderia ser facilitada em um ambiente onde os mesmos j ofertem informaes semnticas
ao seu prprio respeito.
Do ponto de vista mercadolgico, tem se tornado frequente que sistemas de Internet
sejam portados para dispositivos mveis 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 programao de reconfiguraes dinmicas.
Por outro lado, existe um desejo da OSGi Aliance de tornar o OSGi compatvel com
diversas linguagens de programao. Parte desse desejo expresso na RFP-159 que foi
lanada em 2007 e deu os seus primeiros passos em 2013.
Uma investigao cientfica para o desenvolvimento de um mecanismo que permita
a reconfigurao dinmica de artefatos de cdigo em JavaScript pode ter resultados
mercadolgicos relevantes no que diz respeito aos sistemas de Internet que esto sendo
portados para dispositivos mveis.
46
Referncias Bibliogrficas
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 100109. 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 4248.
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 11.
Buregio, V., Almeida, E., and Meira, S. (2010). Characterizing Dynamic Software
Product Lines A Preliminary Mapping Study. pages 5360.
Carvalho, S. T., Loques, O., and Murta, L. (2010). Dynamic Variability Management in
Product Lines: An Approach Based on Architectural Contracts. pages 6169. Ieee.
Cetina, C., Fons, J., and Pelechano, V. (2008). Applying Software Product Lines to Build
Autonomic Pervasive Systems. Number ii, pages 117126. 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 466473.
47
REFERNCIAS BIBLIOGRFICAS
DAmbrogio, 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 110.
de Oliveira Martins, D. A. (2013). DYMOS: Uma abordagem para suporte a variabilidades dinmicas em Linhas de Produto de Software Orientado a Servios e Sensvel ao
Contexto. Masters 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 95101.
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 4650. 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 345352.
Gnther, S. and Sunkle, S. (2010). Dynamically adaptable software product lines using
Ruby metaprogramming. pages 8087, 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 141150. Ieee.
Hallsteinsen, S., Hinchey, M., Park, S., and Schmid, K. (2008). Dynamic software
product lines. Computer, (April), 9395.
IBM (2006). An architectural blueprint for autonomic computing. Technical Report June.
Josuttis, N. (2007). SOA in Practice. Oreilly.
48
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 & Services, iiWAS 10, pages 885889,
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 6672.
Lee, J. (2006). A Feature-Oriented Approach to Developing Dynamically Reconfigurable
Products in Product Line Engineering. pages 131140. Ieee.
Lee, J. and Kotonya, G. (2010). Combining service-orientation with product line engineering. Number June, pages 3541.
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), 157168.
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.
Mendona, 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 3948.
Moresi, E. (2003). Metodologia da pesquisa.
Papakos, P. and Rosenblum, D. S. (2010). VOLARE : Context-Aware Adaptive Cloud
Service Discovery for Mobile Systems. pages 3238.
Papazoglou, M. P. and Georgakopoulos, D. (2003). Introduction: Service-oriented
computing. Commun. ACM, 46(10), 2428.
Parra, C., Blanc, X., and Duchien, L. (2009). Context awareness for dynamic serviceoriented product lines. pages 131140.
Parra, C., Blanc, X., Cleve, A., and Duchien, L. (2011). Unifying design and runtime
software adaptation using aspect models. volume 76, pages 12471260. Elsevier B.V.
49
Pohl, K., Bckle, 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.
Rosenmller, M., Siegmund, N., Apel, S., and Saake, G. (2011). Flexible feature binding
in software product lines. volume 18, pages 163197.
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 16, 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). Mtodos de pesquisa quantitativa e qualitativa para a Cincia da
Computao. Atualizao em Informtica. Org: Tomasz Kowaltowski; Karin Breitman.
Rio de Janeiro: Ed. PUC-Rio, pages 142.
Wazlawick, R. (2009). Metodologia de pesquisa para cincia da computao, 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 2130. Ieee.
Yu, J., Lalanda, P., and Bourret, P. (2010a). An Approach for Dynamically Building and
Managing Service-Based Applications. pages 5158. 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), 6379.
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
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), 103126.
51

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

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

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

Transféré par

Droits d'auteur :

Formats disponibles

Dymos QoS: Uma Abordagem para Seleo de Servios

em Tempo de Execuo em Linhas de Produto de Software

Jackson Raniel Florencio da Silva

Universidade Federal de Pernambuco

Universidade Federal de Pernambuco

Jackson Raniel Florencio da Silva

Dymos QoS: Uma Abordagem para Seleo de Servios

Trabalho apresentado ao Programa de Ps-graduao em

Orientador: Vinicius Cardoso Garcia

Dedico esta dissertao a todas as pessoas que se

Utilizar palavras para expressar sentimentos to vastos na forma de agradecimento uma

Omnia Vincit Amor.

A produo industrial antes de Taylor era essencialmente manufatureira e focada em

Lista de Cdigos Fonte

Viso Geral da Soluo . . . . . . . . . . . . . . . . . . . . . . . . . .

Computao Orientada a Servios . . . . . . . . . . . . . . . . . . . .

Linhas de Produto de Software . . . . . . . . . . . . . . . . . . . . . .

O Estado da Arte em Derivao Dinmica . . . . . . . . . . . .

Estudos em Derivao Dinmica . . . . . . . . . . . . . . . . .

A Interao entre SOC e DSPL . . . . . . . . . . . . . . . . . . . . . .

Avaliao Estatstica Descritiva . . . . . . . . . . . . . . . . . . . . . .

Distribuio Anual de Estudos a Respeito de Derivao Dinmica . . .

DYMOS - Diagrama de Pacotes (de Oliveira Martins, 2013) . . . . . .

GreatTour - Modelo de Features

Delta Oriented Programing

Linha de Produtos de Software Dinmica

Linha de Produtos de Software

Open Service Gatway Initiactive

Computao Orientada a Servio

Arquitetura Orientada a Servio

Software Engineering Institute

Lista de Cdigos Fonte

XML de Servios do DYMOS . . . . .

- Quarenta e dois [...]

quanto as informaes a respeito do estado do prprio dispositivo. Estas informaes so

A Figura 1.1 representa o cenrio hipottico que exemplifica a problemtica abordada

Figura 1.1 Cenrio do Problema

et al. (2010), do ponto de vista empresarial fortemente desejvel maximizar a qualidade

Esta dissertao baseada na perspectiva filosfica positivista. Nesta perspectiva, as

1.3. VISO GERAL DA SOLUO

tero sempre os mesmos valores em observaes distintas realizadas por pesquisadores

Viso Geral da Soluo

indisponvel deixa de ocorrer de acordo com a prioridade arbitrada. E passa a acontecer

1.5. ORGANIZAO DA DISSERTAO

Computao Orientada a Servios

Enquanto paradigma computacional, SOC utiliza servios como elementos fundamentais

CAPTULO 2. REVISO DA LITERATURA

acoplamento, contrato entre servios, descoberta de servios e granularidade alta ou

2.3. LINHAS DE PRODUTO DE SOFTWARE

Linhas de Produto de Software

Custo, reusabilidade e time-to-marketing so aspectos que preocupam os fabricantes de

CAPTULO 2. REVISO DA LITERATURA

O Estado da Arte em Derivao Dinmica

Na perspectiva de Moresi (2003), o Estado da Arte apresenta a partir da literatura j

2.3. LINHAS DE PRODUTO DE SOFTWARE

contribuies esto relacionadas a proposio de solues, em sua maioria concentradas

Figura 2.1 Distribuio Anual de Estudos a Respeito de Derivao Dinmica

A seguir so apresentados estudos publicados entres os anos de 2005 e 2013 que

CAPTULO 2. REVISO DA LITERATURA

services responsveis por prover as funcionalidades do sistema e o suporte ao banco de

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

2.3. LINHAS DE PRODUTO DE SOFTWARE

Em uma abordagem orientada a features e sistemtica de desenvolver core assets

CAPTULO 2. REVISO DA LITERATURA