DYMOS: Uma Abordagem para Suporte A Variabilidades Dinâmicas em Linhas de Produto de Software Orientado A Serviços e Sensível Ao Contexto

DYMOS: Uma abordagem para suporte a variabilidades
dinmicas em Linhas de Produto de Software Orientado a

Servios e Sensvel ao Contexto
Por
Dhiego Abrantes de Oliveira Martins

Dissertao de Mestrado
Universidade Federal de Pernambuco

posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
Recife, Agosto/2013
Universidade Federal de Pernambuco

Centro de Informtica
Ps-graduao em Cincia da Computao
Dhiego Abrantes de Oliveira Martins
DYMOS: Uma abordagem para suporte a

variabilidades dinmicas em Linhas de Produto de
Software Orientado a Servios e Sensvel ao Contexto
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

Co-Orientador: Uir Kulesza
Recife, Agosto/2013
Este trabalho representa um passo muito importante em

minha vida e eu o dedico a meus pais, que sempre sero
minha fonte inesgotvel de inspirao em querer uma
superao a cada dia, lutando de mos limpas pelo meu
crescimento pessoal e profissional.
iii
Agradecimentos
Inicialmente eu agradeo a Deus, por ter me permitido chegar at aqui e cumprir com
sucesso os meus objetivos. Apenas ele sabe o quo desgastante [e prazerosa] foi esta
jornada.
Agradeo a meus pais Carlos e Branca, por todo o esforo e dedicao incomensurveis para me prover o melhor, dentro de seus limites. A minha irm Mirella, pelos
momentos de pacincia quando eu estava em momentos de stress. Eu amo vocs.
Agradeo a minha namorada, Marta Soraya, pela pacincia, companheirismo, apoio,
fora e motivao que sempre me proporcionou. Sem voc, tudo seria mais difcil. Ou
simplesmente no seria.
Agradeo aos inesquecveis amigos dos CInFuturo: Paulo Fernando, Airton Pereira,
Lenin Abadi, Marco Andr, Thiago Vieira, Rodolfo Arruda, Adriano Tito, Bruno Felipe e Hlio Rodrigues. Senhores, que a nossa amizade seja eterna! Obrigado pelos
momentos de descontrao!
Agradeo aos amigos Jackson Raniel e Ren Gadelha, por estarem presentes quando
mais precisei e, simplesmente, por serem amigos verdadeiros!
Agradeo aos demais amigos, com quem compartilhei momentos de aprendizado e
de aperreios em disciplinas, artigos e projetos: Fernando Selleri, Joo Emanoel (Joo
de Tuta), Jamilson Batista, Ivan Samuel, Kelliton Brito (KBrito) e Fernando Carvalho
(Fish).
Agradeo aos companheiro de AP Jlio Cesar (Pastor Jlio) e Rodrigo pelo companheirismo e tirao de onda durante o tempo que convivemos no mesmo AP. Que
vocs casem primeiro!!! hahaha
Agradeo aos Professores Silvio Meira (Engenharia de Software), Augusto Sampaio
(PLP), Fbio Queda (Metodologia de Pesquisa e Systematic Literature Review), Paulo
Borba e Fernando Castor (Arquitetura de Software), e Srgio Soares (Engenharia de
Software Experimental).
Agradeo aos meus Orientadores Vinicius Garcia e Uir Kulesza pela pacincia durante todo este processo de aprendizado e lapidao do conhecimento. Obrigado por
todas as contribuies construtivas e por acreditarem no meu trabalho. Obrigado por
no me darem de comer e me ensinarem a caar!
Agradeo a Profa. Rossana Andrade e ao Prof. Kiev Gama por aceitarem compor a
banca examinadora da minha defesa de mestrado.
Por fim, agradeo a Universidade Federal de Pernambuco e a todos que a compe.
iv
Those mist covered mountains

Are a home now for me
But my home is the lowlands
And always will be
Some day youll return to
Your valleys and your farms
And youll no longer burn
To be brothers in arms
Through these fields of destruction
Baptism of fire
Ive whittnessed your suffering
As the battles raged higher
And though they did hurt me so bad
In the fear and alarm
You did not desert me
My brothers in arms
Theres so many different worlds
So many different suns
And we have just one world
But we live in different ones
Now the suns gone to hell
And the moons riding high
Let me bid you farewell
Every man has to die
But its written in the starlight
And every line on your palm
Were fools to make war
On our brothers in arms
DIRE STRAITS (Brothers in Arms)
Resumo
notrio o surgimento de ambientes cada vez mais dinmicos, exigindo sistemas mais
flexveis, de forma que componentes possam ser plugados ou desplugados durante o seu
ciclo de vida, inclusive em tempo de execuo. Para atender estes requisitos, necessrio
que decises sobre possveis adaptaes e variaes do produto possam ser tomadas em
tempo de execuo. Sistemas Sensveis ao Contexto atendem a esse propsito, sendo
capazes de adaptar-se em tempo de execuo de acordo com mudanas no ambiente,
obedecendo um conjunto de regras.
Quando tcnicas de Linhas de Produto de Software (LPS) so aplicadas no desenvolvimento de sistemas adaptativos, tais decises podem resultar na configurao de um
novo produto. Em uma LPS tradicional, um produto derivado de acordo com sua configurao, que ocorre na fase de design e consiste na seleo de features que iro compor
o produto, remoo das features que no faro parte do produto e ligao dos pontos de
variao.
Linhas de Produto de Software Dinmicas extendem o conceito convencional de LPS
abordando aspectos dinmicos, provendo uma abordagem para tratar variabilidades que
precisam ser manipuladas em tempo de execuo.
Quando alinhamos paradigmas como Sistemas Sensveis ao Contexto, Arquitetura
Orientada a Servios e LPS, podemos enfrentar alguns desafios. O sistema derivado de
uma LPS composto por features e pontos de variao. Considerando que o modelo de
Arquitetura Orientada a Servios segue o padro arquitetural Cliente-Servidor, podemos
ter um cenrio em que as features que compem o produto no lado cliente podem enderear uma composio de servios. Dessa forma, os pontos de variao podem sofrer
variabilidades de acordo com mudanas no contexto, exigindo a execuo de reconfiguraes nos servios de modo a atender tais variabilidades. As abordagens propostas
atualmente no oferecem um suporte para esse tipo de problema ou so incipientes, estando em fases iniciais de pesquisa.
Neste trabalho apresentado um estudo sobre variabilidades dinmicas em Linhas
de Produto de Software Orientadas a Servios e Sensveis ao Contexto, innvestigando
especificamente situaes quando features que endeream um ou mais servios so reconfiguradas no lado cliente, requerendo reconfiguraes nos servios, no lado servidor.
Palavras-chave: sistemas adaptativos, arquitetura orientada a servios, linhas de produto de software dinmicas, reconfigurao dinmica, variabilidade dinmica
vi
Abstract
It is well known that the onset of more and more dynamic environments requires more
flexible systems, so that components can be unplugged or plugged during their life cycle,
including at run time. To meet these requirements, it is necessary that decisions on
possible adaptations and variations of the product can be made at runtime. Contextaware Systems (CAS) meets this purpose, being able to adapt at run time according to
changes in the environment, obeying a set of rules.
When Software Product Line (SPL) techniques are applied in the development of
adaptive systems, such decisions may result in the setting of a new product. In a traditional SPL, a product is derived according to its configuration, which occurs in the design
phase, and consists of selecting features that will make the product, removing features
that are not part of the product and the binding of variation points.
DSPL extends the conventional concept of SPL addressing dynamic aspects, providing an approach to address variability that needs to be manipulated at runtime. When
paradigms such as CAS, SOA and SPL align, we face some challenges. The system
derived from an SPL is composed of variation points and features. Whereas the model of SOA follows the Client-Server architectural pattern, we have a scenario in which
the features that make the product on the client side can address a service composition.
Thus, the variation points may suffer from variabilities according to changes in context,
demanding the execution of reconfigurations services to meet such variability. The proposed approaches do not currently offer support for this type of problem or are incipient,
being in the early stages of research.
This work presents a study of variability dynamics in LPSOSSC, investigating specific situations where features that address one or more services are reconfigured, requiring
reconfiguration on the server side.
Keywords: adaptive system, service-oriented architecture, dynamic software product
line, dynamic reconfiguration, dynamic variability, runtime variability
vii
Lista de Figuras
1.1
DYMOS: Arquitetura Externa . . . . . . . . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
Custos do desenvolvimento de uma Linha de Produto . . . . . . . . .

Atividades Essenciais na Engenharia de Linha de Produto de Software
Arquitetura Orientada a Servios: Papis e Operaes . . . . . . . . .
Linha de Produto Orientadas a Servios: Configurao de Produtos . .
Composio de features . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
DYMOS: Viso Geral da Arquitetura . . . . . . . . . . . . . . . . . . .

Especificao de Descritores . . . . . . . . . . . . . . . . . . . . . . .
Relacionamento entre Descritores . . . . . . . . . . . . . . . . . . . .
Descritor de Servios: Estrutura de Metadados . . . . . . . . . . . . . .
Descritor de Servios: Exemplo Prtico . . . . . . . . . . . . . . . . .
Descritor de Variabilidades: Estrutura de Metadados . . . . . . . . . .
Descritor de Variabilidades: Exemplo Prtico . . . . . . . . . . . . . .
Descritor de WSDL: Fluxo de Dados . . . . . . . . . . . . . . . . . . .
Componente ServiceContext: Uma viso sob uma perspectiva de dependncia entre componentes . . . . . . . . . . . . . . . . . . . . . . . . .
Reconfigurando Variabilidades Dinmicas: Diagrama de Sequncia . .
Descoberta de Servios: Viso geral sobre a interao entre componentes
Descoberta de Servios: Servios descritos para um exemplo prtico . .
Descoberta de Servios: Diagrama de Sequncia . . . . . . . . . . . .
3.10
3.11
3.12
3.13
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
.
.
.
.
.
Abordagem utilizada na MobiLine . . . . . . . . . . . . . . . . . . . .

GREat Tour: Modelo de Feature Parcial . . . . . . . . . . . . . . . . .
MySQLServiceProvider: Dependncia entre o Servio Provedor de Conexes e os demais Servios Modularizados . . . . . . . . . . . . . . .
MySQLDataSourceFactory: Fbrica de conexes MySQL utilizando JDBC
MySQLDataSourceFactory: Configurao iPOJO do Componente e sua
Instncia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LoginService: Especificao . . . . . . . . . . . . . . . . . . . . . . .
LoginService: Configurao parcial do arquivo POM . . . . . . . . . .
LoginServiceProvider: Uma implementao para o LoginService . . . .
LoginServiceProvider: Mtodos para estabelecer e finalizar uma conexo com o banco de dados . . . . . . . . . . . . . . . . . . . . . . . .
6
10
12
18
20
21
29
30
31
32
33
34
35
36
37
38
40
41
42
49
51
54
55
56
57
57
58
60
viii
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
LoginServiceProvider: Configurao de Instncia . . . . . . . . . . . .

LoginServiceProvider: Configurao parcial do arquivo POM . . . . . .
GREat Tour: Descritor de Servios . . . . . . . . . . . . . . . . . . . .
GREat Tour: Descritor de Variabilidades . . . . . . . . . . . . . . . . .
CIn Tour: Modelo de Feature Parcial . . . . . . . . . . . . . . . . . . .
CIn Tour: Descritor de Servios . . . . . . . . . . . . . . . . . . . . .
CIn Tour: Descritor de Variabilidades . . . . . . . . . . . . . . . . . .
Aplicao Cliente: Declarao de constantes e Interao com Servio .
Aplicao Cliente: Descoberta de Servio por meio da biblioteca DymosClientLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.19 Aplicao Cliente: Reconfigurao de variabilidades por meio da biblioteca DymosClientLib . . . . . . . . . . . . . . . . . . . . . . . . .
60
61
63
64
66
67
68
69
70
70
ix
Lista de Tabelas
3.1
4.1
Relao entre Componentes, Requisitos Funcionais e Requisitos NoFuncionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
Relao entre Features e Artefatos . . . . . . . . . . . . . . . . . . . .
52
Lista de Acrnimos
AOS
Arquitetura Orientada a Servios
COS
Computao Orientada a Servios
DS
Descritor de Servios
DV
Descritor de Variabilidades
WSR
Web Service Resolver
ELPS
Engenharia de Linha de Produto de Software
JAXB
Java Architecture for XML Binding
LPS
Linha de Produto de Software
LPSD
Linha de Produto de Software Dinmica
LPSOS
Linha de Produto de Software Orientado a Servios
LPSOSSC Linha de Produto de Software Orientado a Servios e Sensvel ao
Contexto
RF
Requisito Funcional
RNF
Requisito No-Funcional
SSC
Sistema Sensvel ao Contexto
WSDL
Web Service Definition Language
XML
Extensible Markup Language
xi
Sumrio
Introduo
1.1 Motivao . . . . . . . . .
1.2 Problemtica . . . . . . .
1.3 Viso Geral da Soluo . .
1.4 Escopo Negativo . . . . .
1.5 Organizao da Dissertao
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Reviso da Literatura
2.1 Linhas de Produto de Software: Uma viso geral . . . . . . .
2.1.1 Motivao . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Engenharia de Linha de Produto de Software . . . . .
2.1.3 Modelos de Adoo de Linhas de Produto de Software
2.1.4 Linhas de Produto de Software Dinmicas . . . . . . .
2.2 Computao Orientada a Servios: Uma viso geral . . . . . .
2.2.1 Arquiteturas Orientadas a Servios . . . . . . . . . . .
Motivao . . . . . . . . . . . . . . . . . . . . . . . .
Princpios e Papis . . . . . . . . . . . . . . . . . . .
2.2.2 Linhas de Produto Orientadas a Servios . . . . . . .
2.3 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
DYMOS Framework
3.1 Viso Geral da Soluo . . . . . . . . . . . . . . . . . . . . . .
3.2 Elicitao de Requisitos . . . . . . . . . . . . . . . . . . . . . .
3.3 Tecnologias Utilizadas . . . . . . . . . . . . . . . . . . . . . .
3.4 Arquitetura e Implementao . . . . . . . . . . . . . . . . . . .
3.4.1 Componentes Descritores . . . . . . . . . . . . . . . .
Descritor de Servios . . . . . . . . . . . . . . . . . . .
Descritor de Variabilidades . . . . . . . . . . . . . . . .
Web Service Resolver . . . . . . . . . . . . . . . . . .
3.4.2 Componente ServiceContext . . . . . . . . . . . . . . .
Reconfigurando Variabilidades Dinmicas . . . . . . . .
Descoberta de Servios . . . . . . . . . . . . . . . . . .
Reconstruindo o ServiceContext com o ContextHotBuild
3.4.3 Componente ApplicationService . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
3
5
7
8
.
.
.
.
.
.
.
.
.
.
.
9
9
10
11
13
14
15
16
16
17
19
21
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
26
27
28
29
31
33
35
36
37
39
43
44
xii
3.4.4
4
Decises Arquiteturais e Concluso . . . . . . . . . . . . . . .
Uma Avaliao Preliminar

4.1 MobiLine . . . . . . . . . . . . . . . . . . . .
4.2 GREat Tour . . . . . . . . . . . . . . . . . . .
4.2.1 Anlise e Definies . . . . . . . . . .
4.2.2 Analisando o Modelo de Features . . .
4.2.3 Analisando os Artefatos . . . . . . . .
4.2.4 Modularizando Servios . . . . . . . .
MySQLServiceProvider . . . . . . . .
LoginService . . . . . . . . . . . . . .
LoginServiceProvider . . . . . . . . .
4.2.5 Descrevendo Servios e Variabilidades
4.3 CIn Tour . . . . . . . . . . . . . . . . . . . . .
4.3.1 Analisando o Modelo de Features . . .
4.3.2 Descrevendo Servios e Variabilidades
4.4 Analisando e Integrando a Aplicao Cliente .
4.5 Consideraes Finais . . . . . . . . . . . . . .
45
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
48
48
50
50
51
52
53
54
56
58
62
65
65
67
68
70
Concluso
5.1 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
72
73
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Referncias
74
Apndice
81
A Componentes Descritores
A.1 Descritor de Servios . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Descritor de Variabilidades . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Descritor de WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
82
83
84
xiii
1
Introduo
A vida simples, mas ns insistimos em complic-la.

Life is really simple, but we insist on making it complicated.
CONFUCIUS
1.1
Motivao
notrio o surgimento de ambientes cada vez mais dinmicos, exigindo sistemas mais
flexveis, de forma que componentes possam ser plugados ou desplugados durante o seu
ciclo de vida, inclusive em tempo de execuo (Kim et al., 2005; Niebuhr et al., 2009).
Para atender estes requisitos, necessrio que decises sobre possveis adaptaes e
variaes do sistema possam ser tomadas em tempo de execuo. Sistemas Sensveis
ao Contexto (SSCs) atendem a esse propsito, sendo capazes de adaptar-se em tempo
de execuo de acordo com mudanas no ambiente, obedecendo um conjunto de regras
(Hallsteinsen et al., 2006; Kim et al., 2005; Oreizy et al., 1999).
Quando tcnicas de Linha de Produto de Software (LPS) so aplicadas no desenvolvimento de sistemas adaptativos, tais decises podem resultar na configurao de um
novo produto. Em uma LPS tradicional, um produto derivado de acordo com sua configurao, que ocorre na fase de design ou de implementao (Rosenmller et al., 2011) e
consiste na seleo de features que iro compor o produto, remoo das features que no
faro parte do produto e ligao dos pontos de variao (Alferez and Pelechano, 2011).
No entanto, no domnio de sistemas adaptativos, decises sobre quais so as features que
iro compor o produto podem estar ligadas a algum atributo ou caracterstica do ambiente, requerendo que a LPS seja dinmica, de modo que tais decises possam ser adiadas
da fase de desenvolvimento para a fase de execuo (Galster, 2010; Hallsteinsen et al.,
1.1. MOTIVAO
2008). Neste contexto, diversas pesquisas (Dhungana et al., 2007; Hallsteinsen et al.,
2006; Kim et al., 2005; Wolfinger et al., 2008), de diferentes reas, tm investigado
sobre a utilizao de abordagens de LPS no desenvolvimento de sistemas adaptativos.
Linhas de Produto de Software Dinmicas (LPSDs) (Hallsteinsen et al., 2008) estendem o conceito convencional de Linhas de Produto de Software abordando aspectos dinmicos e provendo uma abordagem para tratar variabilidades que precisam ser
manipuladas em tempo de execuo (Bencomo et al., 2012). LPSDs efetuam bind1 e
unbind2 de pontos de variao em tempo de execuo. Com isso, introduzido o conceito de variabilidade dinmica, possibilitando que o produto derivado de uma LPS seja
reconfigurado em tempo de execuo (Bencomo et al., 2010).
Tecnologias orientadas a servios possuem caractersticas que so requeridas por
muitas LPS (Yu et al., 2010), provendo uma estrutura dinmica e desacoplada, de modo
que possibilite obter mais flexibilidade e maior poder de adaptao a novos cenrios (Ye
et al., 2007). Este tipo de tecnologia utilizado para o desenvolvimento de software
como servio, resultando em componentes com baixo acoplamento e interoperabilidade
entre linguagens e plataformas (Demirkan et al., 2008). Com o objetivo de construir
artefatos de software cada vez mais reutilizveis, diversas abordagens (Galster, 2010;
Raatikainen and Mannisto, 2007; Segura et al., 2007; Smith and Lewis, 2009; Trujillo
and Kaestner, 2007) tm investigado o uso do modelo de Arquitetura Orientada a Servios (AOS) para este propsito. Com isso, surge o conceito de Linha de Produto de
Software Orientado a Servios (LPSOS) (Krut and Cohen, 2008), unindo prticas de
orientao a servios a LPS, para construir aplicaes customizadas, de acordo com
um segmento especfico de mercado. Este modelo de arquitetura possui caractersticas
dinmicas e flexveis que podem ajudar a obter uma gerncia de variabilidades mais
otimizada (Galster, 2010).
LPSOS representa uma categoria de LPSD, que desenvolvida seguindo uma arquitetura orientada a servios e, do ponto de vista da Engenharia de Linha de Produto de
Software (ELPS), possvel perceber benefcios como o suporte contnuo a mudanas
no contexto e a possibilidade de combinar servios em vrias configuraes, simplificando a implantao de pontos de variao que, por exemplo, embora utilizem a mesma
base de servios, necessitam passar por adaptaes para atender a diferentes requisitos
(Lee et al., 2012). Portanto, importante a existncia de tcnicas de engenharia de software que apoie o desenvolvimento de sistemas com baixo acoplamento, dinmicos e
1 associao
de uma variante a um ponto de variao

de uma variante a um ponto de variao
2 dissociao
1.2. PROBLEMTICA
flexveis (Ali and Babar, 2009).

Diversas solues para desenvolvimento de sistemas sensveis ao contexto foram
propostas (Kon et al., 2000; Rocha et al., 2007; Viana and Andrade, 2008). No entanto,
apesar de algumas dessas abordagens proverem mecanismos que permitem o reuso de artefatos, elas no so aplicadas de forma sistemtica durante as fases de desenvolvimento
de software Marinho et al.. Em contrapartida, Marinho et al. e Parra et al. propem
abordagens sistemticas para desenvolvimento desse tipo de sistema, onde o primeiro
autor utiliza tcnicas de LPS e o segundo autor combina tcnicas de LPS e AOS.
Quando alinhamos paradigmas como Sistemas Sensveis ao Contexto, AOS e LPS,
podemos enfrentar alguns desafios. O sistema derivado de uma LPS composto por
features e pontos de variao. Considerando que o modelo de AOS segue o padro
arquitetural Cliente-Servidor (Erl, 2007), podemos ter um cenrio em que as features
que compem o produto no lado cliente podem enderear uma composio de servios,
que est em execuo no lado servidor. Dessa forma, os pontos de variao podem
sofrer variabilidades de acordo com mudanas no contexto, de modo que features da
aplicao cliente sejam ativadas ou desativadas, exigindo a execuo de reconfiguraes
nos servios de modo a atender tais variabilidades. As abordagens propostas atualmente
no oferecem um suporte para esse tipo de problema ou so incipiente, estando em fases
iniciais de pesquisa.
Portanto, possvel perceber a necessidade de um framework que permita a reconfigurao de tais variabilidades, efetuando reconfiguraes dinmicas em Linhas de Produto de Software Orientado a Servios e Sensvel ao Contexto.
1.2
Problemtica
O principal desafio quando utilizamos tcnicas de LPS no desenvolvimento de SSCs

a necessidade de adiar decises que ocorreriam na fase de design ou de implementao
para a fase de execuo (runtime). Tais decises influenciam diretamente nos artefatos
de software que compem o produto.
De acordo com (Pohl et al., 2005), um produto derivado de uma LPS composto
por caractersticas (features) comuns e variveis (variabilities). Desse modo, no cenrio
de Linha de Produto de Software Orientado a Servios e Sensvel ao Contexto, o produto pode ser composto por features que, para entrar em execuo, precisam utilizar um
servio ou uma composio deles.
Se considerarmos servios como parte de uma feature, ao ocorrer uma ativao ou
1.2. PROBLEMTICA
desativao de uma ou mais features no sistema, e em tempo de execuo, necessrio

efetuar uma reconfigurao na composio dos servios, de modo que a adaptao das
features e mudana no contexto seja atendida (Alferez and Pelechano, 2011).
Dessa forma, faz-se necessrio um framework que seja responsvel por tratar reconfiguraes de tais variabilidades. De acordo com (Erl, 2007), o modelo de AOS segue o
padro arquitetural Cliente-Servidor. Ento, como o cliente e o servidor so executados
em ambientes diferentes, necessrio que o framework seja capaz de (i) receber notificaes sobre mudanas na composio de features da aplicao cliente, para que (ii)
reconfiguraes possam ser efetuadas no lado servidor.
SSCs so flexveis, dinmicos e se adaptam em tempo de execuo de acordo com
mudanas no ambiente, obedecendo um conjunto de regras (Hallsteinsen et al., 2006;
Kim et al., 2005; Oreizy et al., 1999). Quando mudanas ocorrem, reconfiguraes so
executadas, tornando disponvel ou indisponvel um ou mais servios, compondo uma
plataforma de servios dinmica. Considerando que os servios estaro em execuo
em uma plataforma com caractersticas dinmicas, necessrio um (iii) mecanismo de
descoberta de servios, que insira uma camada de abstrao entre o cliente, o servidor e
o servio requisitado.
Com isso, espera-se que haja um menor acoplamento e maior flexibilidade, visto que
no devem existir requisies para um servio especfico, de forma fixa, mas para um
servio que atenda a uma determinada especificao. O mecanismo de descoberta de
servios deve ser responsvel por selecionar com base em critrios de seleo o servio
mais adequado e retornar a sua referncia (endpoint) para que possa ser acessado.
O problema investigado pode ser expressado por meio de perguntas de pesquisa, nas
quais suas respostas definem a abordagem a ser investigada no trabalho. A abordagem
utilizada neste trabalho direcionada para responder a seguinte pergunta:
Como possvel permitir reconfiguraes de variabilidades dinmicas em Linhas
de Produto de Software Orientado a Servios e Sensvel ao Contexto (LPSOSSCs)?
Portanto, como forma de obter uma resposta para esta pergunta de pesquisa,
Neste trabalho apresentado um estudo sobre variabilidades dinmicas em
Linha de Produto de Software Orientado a Servios e Sensvel ao Contexto,
investigando especificamente situaes quando features que endeream um
ou mais servios so reconfiguradas no lado cliente, requerendo reconfiguraes nos servios, no lado servidor. Como resultado deste estudo
1.3. VISO GERAL DA SOLUO
provido um framework para suporte a reconfigurao e descoberta de servios.
1.3
Viso Geral da Soluo
De modo a permitir variabilidades dinmicas em LPSOSSCs, foi proposto e desenvolvido o DYMOS Framework. apresentado por meio da da Figura 1.1, a forma como o
DYMOS est disposto em relao as demais tecnologias utilizadas.
O DYMOS prov, de uma forma desacoplada, uma plataforma de reconfigurao de
variabilidades dinmicas e descoberta de servios para Linhas de Produto de Software
Orientado a Servios e Sensvel ao Contexto. O DYMOS oferece algumas vantagens
como: possibilidade de Gerncia de variabilidades de uma forma leve e simples, permitindo 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; Mecanismo de Descoberta de Servio, que prov uma abstrao
entre o Cliente e o Servio, permitindo agregar critrios para a seleo do servio mais
adequado, de acordo com uma requisio; As principais funcionalidades do DYMOS
esto dispostas na forma de servios web e, por meio destes, obtida a caracterstica de
interoperabilidade, permitindo que o framework seja utilizado por aplicaes desenvolvidas em outras plataformas.
De acordo com (Gomaa and Hashimoto, 2011), possvel classificar uma reconfigurao em tempo de execuo como comportamental, arquitetural ou reconfigurao
de componentes. Uma adaptao comportamental ocorre quando o comportamento do
sistema alterado, mantendo a mesma estrutura e arquitetura. Uma adaptao arquitetural ocorre quando a arquitetura do sistema impactada diretamente pela adaptao.
Uma adaptao de componentes envolve uma substituio de um componente por outro
que implemente a mesma interface. O tipo de reconfigurao executada pelo DYMOS
se trata de reconfigurao de componentes.
O framework foi desenvolvido de forma modular utilizando tecnologias OSGi3 . Como
forma de obter componentes modularizados, foi utilizado o iPOJO4 , que um framework
para desenvolvimento de componentes orientados a servio para compor sistemas modulares que requerem adaptaes em tempo de execuo (Escoffier et al., 2007). Como
3 http://www.osgi.org
4 http://felix.apache.org/site/apache-felix-ipojo.html
plataforma de execuo, utilizado o framework Apache Felix5 , que uma implementao do OSGi Service Platform. Para expor funcionalidades por meio de servios web,
utilizado o OSGi Distribudo6 , que um subprojeto do Apache CXF7 .
Figura 1.1 DYMOS: Arquitetura Externa
Com o objetivo de abordar os itens i, ii e iii destacados na Seo 1.2, os seguintes

itens foram desenvolvidos em forma de componentes como parte da soluo:
Descritor de Servios permite descrever servios, indicando um ID (identificador), especificaes, implementaes e regras que so aplicadas quando a operao de
descoberta de servio solicitada. Quando h uma requisio, tais regras devem
ser utilizadas a fim de selecionar o servio adequado.
Descritor de Variabilidades permite descrever variabilidades, indicando pontos de variao. A descrio consiste na atribuio de um ID e um mapeamento entre
pontos de variao e um ou mais servios.
Mecanismo de Reconfigurao de Servios responsvel por reconfigurar os servios para atender a mudanas no ambiente. A reconfigurao feita em termos
de ativao ou desativao de um ou mais servios, tornando-os disponveis ou
indisponveis para utilizao. Este componente atende ao item ii, mencionado na
Seo 1.2.
5 http://felix.apache.org/
6 http://cxf.apache.org/distributed-osgi.html
7 http://cxf.apache.org
1.4. ESCOPO NEGATIVO
Mecanismo de Descoberta de Servios responsvel por prover operaes de descoberta de servios. Essas operaes possibilitam a recuperao de referncias (endpoint) de acesso a servios, informando o ID atribudo na descrio do servio.
Este mecanismo deve selecionar o servio mais adequado, de acordo com o ID
informado e, em seguida, deve ser retornado o endpoint do servio para que possa
ser utilizado pelo cliente. Com isso, servios podem ser inseridos ou removidos a
qualquer momento, sem haver a necessidade de alterao de cdigo no cliente ou
no servidor.
Os itens Descritor de Servios e Descritor de Variabilidades so utilizados pelos
mecanismos de Reconfigurao e Descoberta de Servios, de modo que as operaes
de reconfigurao e descoberta de servios sejam efetuadas de acordo com cada uma
das descries. De modo a permitir os Descritores de Servios e de Variabilidades, foi
definida e disponibilizada uma sintaxe baseada em XML, que dever ser utilizada para
especificar cada um dos itens.
As operaes de reconfigurao e descoberta de servios que so providas respectivamente pelo Mecanismo de Reconfigurao de Servios e Mecanismo de Descoberta de Servios, esto disponveis por meio de Servios Web. O Servio Web referente
operaes de reconfigurao permite que o framework seja notificado sobre mudanas
no contexto, atendendo ao item i, mencionado na Seo 1.2
Uma descrio mais detalhada sobre a soluo proposta apresentada no Captulo
3.
1.4
Escopo Negativo
Alguns aspectos que so relacionados a esta pesquisa no so considerados como parte

do escopo deste trabalho. Este trabalho pode ser visto como um passo inicial de uma
pesquisa sobre Reconfigurao Dinmica de Variabilidades em Linhas de Produto de
Software Orientado a Servios e Sensvel ao Contexto (LPSOSSCs). Assim, alguns
pontos no so diretamente endereados por este trabalho:
Agente Para que um sistema possa adaptar-se, preciso que algum componente notifique sobre uma possvel mudana no contexto. Isso torna necessrio a implementao de agentes, que so responsveis por observar o contexto e informar
sobre tais mudanas. Nossa soluo oferece um conjunto de mecanismos que so
responsveis por receber notificaes sobre adaptaes.
1.5. ORGANIZAO DA DISSERTAO
Interpretao de Regras de Contexto Para determinar quais so os componentes que

sero adaptados, algumas regras definidas previamente devem ser consideradas.
No entanto, quando ocorre uma notificao de mudana no contexto, a aplicao
cliente deve ser responsvel por analisar tais regras e notificar a nossa soluo,
indicando quais os pontos de variao sero afetados.
1.5
Organizao da Dissertao
A estrutuda dessa dissertao est organizada da seguinte forma:

No Captulo 2 apresentada uma reviso da literatura, de modo a efetuar uma contextualizao sobre as principais reas abordadas neste trabalho. No Captulo 3 apresentada em detalhes a soluo proposta neste trabalho, destacando os requisitos elencados,
a funo de cada componente da soluo e como estes componentes permitiram atender
os requisitos. No Captulo 4 apresentada uma avaliao preliminar da abordagem proposta por meio de um estudo de caso. No Captulo 5 so apresentadas as Consideraes
Finais, Principais Contribuies e Trabalhos Futuros.
2
Reviso da Literatura
O silncio um amigo verdadeiro que nunca trai.
Silence is a true friend who never betrays.
CONFUCIUS
2.1
Linhas de Produto de Software: Uma viso geral
A ELPS tem seus princpios inspirados em fbricas de automveis, que possuiam produtos com um custo mais interessante quando produzidos em massa do que quando
produzidos de forma individual. Estas fbricas utilizam uma plataforma comum para
derivar os produtos que podem ser customizados de acordo com as necessidades de um
segmento de mercado (Clements and Northrop, 2001).
Uma linha de produto pode ser definida como um grupo de sistemas de software que
compartilham um conjunto de caractersticas em comum e que satisfazem as necessidades especficas de um segmento de mercado. Este grupo de sistemas so desenvolvidos com base em um conjunto de core assets, que so documentos, especificaes,
componentes e outros artefatos de software que possam ser reutilizados durante o desenvolvimento de cada sistema de software que compe a linha de produto (Clements and
Northrop, 2001).
O objetivo da ELPS explorar partes comuns em um conjunto de sistemas, enquanto
gerencia as partes variveis, permitindo o desenvolvimento de uma famlia de sistemas
de uma forma rpida e com baixo custo quando comparado ao desenvolvimento de um
sistema separadamente (Gomaa, 2004). demonstrado por meio da Figura 2.1 uma
comparao entre o custo de produo de um nico produto e o custo de produo de
vrios produtos.
2.1. LINHAS DE PRODUTO DE SOFTWARE: UMA VISO GERAL
Figura 2.1 Custos do desenvolvimento de uma Linha de Produto. Adaptado de (Linden et al.,
2007)
Observando a Figura 2.1, a linha slida representa o custo de desenvolvimento de

sistemas de forma independente, enquanto a linha pontilhada representa o custo de desenvolvimento de sistemas utilizando ELPS. Como possvel perceber, o custo do desenvolvimento de uma pequena quantidade de sistemas utilizando ELPS relativamente
alto e, a medida que a aumenta-se a quantidade de sistema desenvolvidos, o custo de cada
sistema desenvolvido diminui e o custo acumulado da produo cresce mais lentamente
quando comparado ao custo de desenvolvimento de sistemas individuais.
2.1.1
Motivao
Existem diversas razes para desenvolver uma famlia de produtos utilizando o paradigma de ELPS. Este paradigma proporciona muitos benefcios e, de acordo com (Pohl
et al., 2005), estes benefcios consistem em:
Uma vez que muitos produtos so desenvolvidos com base em um conjunto de
core assets comuns, o custo de desenvolvimento e tempo de entrega de produtos individuais so reduzidos consideravelmente. No entanto, exigido um
investimento inicial e um longo perodo de tempo para desenvolver os core assets
que sero reutilizados durante o desenvolvimento de cada produto.
10
Os core assets de uma plataforma de LPS so reutilizados em muitos produtos.

Dessa forma, os core assets so revisados, testados e reutilizados muitas vezes, em
diferentes cenrios. Isto torna mais fcil encontrar e corrigir possveis problemas,
aumentando a qualidade do produto.
Quando os artefatos da plataforma da LPS so modificados ou novos artefatos so
adicionados, as mudanas so refletidas para todos os produtos derivados desta
LPS. Isto torna a manuteno e evoluo mais simples e com custo mais baixo
do que tratar cada produto de forma separada.
Em uma LPS, os produtos so customizados de acordo com as necessidades do
cliente ou de um segmento especfico de mercado. Ento, os produtos entregues
atendem a necessidades e requisitos individuais com um baixo custo e alta qualidade, proporcionando um aumento na satisfao do cliente.
No entanto, apesar de proporcionar estes benefcios, o gerenciamento das variabilidades essencial para o sucesso de uma linha de produto (Pohl et al., 2005), pois
diferentes produtos so desenvolvidos a partir da plataforma da LPS em conjunto com
uma seleo de variabilidades.
Variabilidades representam diferenas entre os produtos de uma LPS, e por meio
do gerenciamento de variabilidades que diversos produtos so construdos a partir de
um conjunto de artefatos reutilizveis. A partir da etapa de configurao do produto,
possvel efetuar a ligao entre pontos de variao (variation point) e variaes (variant).
Para ilustrar um exemplo, podemos citar como um ponto de variao o tipo de acesso do
sistema e, como exemplo de variao, podemos citar autenticao por usurio e senha,
biometria, reconhecimento facial, etc.
Na prxima seo ser detalhado o processo de desenvolvimento e as atividades da
ELPS.
2.1.2
Engenharia de Linha de Produto de Software
As atividades da Engenharia de Linha de Produto de Software (ELPS) so divididas em

duas fases principais, que de acordo com (Pohl et al., 2005) e (Linden et al., 2007),
consistem na Engenharia de Domnio e Engenharia de Aplicao.
Engenharia de Domnio a fase onde estabelecida uma plataforma reutilizvel e customizvel, identificando e definindo as partes comuns e variveis da linha de produto;
11
Engenharia de Aplicao a fase em que os produtos so construdos por meio da

reutilizao dos core assets da plataforma e seleo de variabilidades para permitir
customizaes do produto.
O processo de engenharia de aplicao composto por atividades para (i) configurao do produto, que consiste na construo de combinaes vlidas de variabilidades identificadas no processo de engenharia de domnio; (ii) derivao do
produto, que consiste no processo concreto de construo de uma aplicao da
LPS (Pohl et al., 2005).
Neste sentido, necessrio utilizar um tipo de processo que considere o reuso de
artefatos nas fases de Engenharia de Domnio e Aplicao. (Clements and Northrop,
2001) define trs importantes atividades para a ELPS, conforme apresentado na Figura
2.2:
Figura 2.2 Atividades Essenciais na Engenharia de Linha de Produto de Software. Adaptado de

(Clements and Northrop, 2001)
Conforme possvel observar na Figura 2.2, as fases consistem no Desenvolvimento de core assets, Desenvolvimento do Produto e Gerenciamento.
Desenvolvimento de core assets esta atividade equivalente Engenharia de Domnio.
Nesta etapa so produzidos um conjunto de core assets, um plano de produo e
12
definido o escopo da linha de produto. recebido como entrada os pontos comuns

e variveis dos produtos, padres, requisitos e abordagens para a realizao dos
core assets.
Desenvolvimento do Produto esta atividade equivalente Engenharia de Aplicao.
Recebe como entrada os core assets produzidos na fase anterior e os requisitos
para a produo de um produto especfico.
Gerenciamento esta atividade importante devido a existncia de interao entre as
etapas de Desenvolvimento de core assets e Desenvolvimento do Produto
(Clements and Northrop, 2001). De acordo com (Pohl et al., 2005), o gerenciamento em um nvel tcnico e organizacional possui ligao com todo o processo
da engenharia da linha de produto, influenciando diretamente no seu sucesso.
Sero apresentadas na prxima seo algumas abordagens utilizadas na adoo do
paradigma de LPS.
2.1.3
Modelos de Adoo de Linhas de Produto de Software
Muitas organizaes so motivadas a adotar o paradigma de LPS, principalmente por

razes econmicas, pois utilizando as abordagens de LPS possvel obter a reutilizao
de artefatos em larga escala durante o desenvolvimento de software, reduzindo consideravelmente os custos de desenvolvimento e tempo de entrega dos produtos (Linden
et al., 2007).
Para a adoo bem sucedida do paradigma de LPS, exigido um esforo por parte da
organizao interessada, que pode utilizar alguns modelos de adoo de acordo com seus
objetivos, requisitos, tempo e oramento disponvel para investimentos. De acordo com
(Krueger, 2002), os modelos de adoo consistem nas abordagens Pro-ativa, Reativa e
Extrativa:
Pro-ativa este modelo de adoo equivalente ao modelo cascata no desenvolvimento
convencional de software, onde todas as variaes do produto so analisadas, projetadas e, por fim, implementadas. Este modelo ideal para organizaes que tm
o domnio completo sobre os requisitos da linha de produto e que possuem tempo
e recursos disponveis para um longo perodo de desenvolvimento.
Reativa neste modelo, as variaes do produto so analisadas, projetadas e implementadas de forma incremental, permitindo que o escopo da LPS evolua de acordo
13
com a demanda por novos produtos ou novos requisitos em produtos j existentes.

Este modelo ideal para organizaes que no conseguem prever os requisitos da
linha de produto e que no tm a possibilidade de interromper o desenvolvimento
da linha de produto ou estender o tempo durante o processo de adoo.
Extrativa a construo da LPS feita a partir da extrao de caractersticas comuns
e variveis de um conjunto de sistemas de software previamente desenvolvidos.
Este modelo ideal para organizaes que pretendem migrar o seu modelo de
desenvolvimento de software, saindo do modelo convencional para o modelo de
desenvolvimento de linhas de produto.
Cada um dos modelos de adoo est associado a um conjunto de riscos e benefcios.
A abordagem pro-ativa possui mais riscos pois o ciclo de desenvolvimento longo e
requer um investimento inicial considerado alto. No entanto, o retorno de investimento
alto quando comparado com os retornos de investimento das abordagens reativa e
extrativa (Alves et al., 2005; Clements and Northrop, 2001). Em contrapartida, estas
abordagens podem eliminar as barreiras encontradas no processo de adoo, reduzir
riscos e permitir uma adoo rpida, pois nem sempre possvel diminuir ou parar a
produo de software durante a transio (Krueger, 2002).
A adoo do paradigma de LPS requer um investimento inicial, adequaes no processo de desenvolvimento e possivelmente modificaes na estrutura organizacional da
empresa (Linden et al., 2007). Alm disso, possvel citar alguns pr-requisitos para
a adoo deste paradigma como utilizar uma tecnologia que permita implementar os
conceitos de linhas de produto, processos bem definidos, pessoas que conhecem as necessidades do mercado, a fim de identificar as semelhanas e variaes entre os produtos,
e um domnio estvel de negcio (Pohl et al., 2005). Neste sentido, para que a escolha de
um modelo de adoo que possa atender da melhor forma as expectativas da organizao, necessrio que haja uma anlise de alguns fatores relativos a prpria organizao
como objetivos, tempo e recursos disponveis.
2.1.4
Linhas de Produto de Software Dinmicas
Quando tcnicas de Linha de Produto de Software (LPS) so aplicadas no desenvolvimento de sistemas adaptativos, tais decises podem resultar na configurao de um novo
produto. Em uma LPS tradicional, um produto derivado de acordo com sua configurao, que ocorre na fase de design ou de implementao (Rosenmller et al., 2011) e
consiste na seleo de features que iro compor o produto, remoo das features que no
14
2.2. COMPUTAO ORIENTADA A SERVIOS: UMA VISO GERAL
faro parte do produto e ligao dos pontos de variao (Alferez and Pelechano, 2011).
No entanto, no domnio de sistemas adaptativos, decises sobre quais so as features
que iro compor o produto podem estar ligadas a algum atributo ou caracterstica do
ambiente, requerendo que a LPS seja dinmica, de modo que tais decises possam ser
adiadas da fase de desenvolvimento para a fase execuo (Galster, 2010; Hallsteinsen
et al., 2008). Nesse contexto, diversas pesquisas (Dhungana et al., 2007; Hallsteinsen
et al., 2006; Kim et al., 2005; Wolfinger et al., 2008), de diferentes reas, tm investigado
sobre Linhas de Produto de Software Dinmicas (LPSDs), que consiste na utilizao de
abordagens de LPS no desenvolvomento de sistemas adaptativos.
O termo Linhas de Produto de Software Dinmicas (em ingls, Dynamic Software
Product Lines, ou DSPL) foi introduzido em 2008 por (Hallsteinsen et al., 2008). O
autor apresenta um novo conceito que utiliza abordagens de LPS para construir sistemas
que podem ser adaptados em tempo de execuo, de acordo com requisitos do usurio e
mudanas no ambiente.
Linhas de Produto de Software Dinmicas (LPSDs) (Hallsteinsen et al., 2008) estendem o conceito convencional de Linhas de Produto de Software abordando aspectos
dinmicos, provendo uma abordagem para tratar variabilidades que precisam ser manipuladas em tempo de execuo (Bencomo et al., 2012). LPSDs efetuam bind e unbind
de pontos de variao em tempo de execuo. Com isso, introduzido o conceito de
variabilidade dinmica, possibilitando que o produto derivado de uma LPS seja reconfigurado em tempo de execuo (Bencomo et al., 2010).
LPSD um termo relativamente novo e diversas pesquisas esto em evoluo. Na
Seo 2.3 sero apresentados os principais trabalhos relacionados nossa abordagem e,
por fim, ser feita uma discusso sobre as vantagens apresentadas por nossa proposta.
2.2
Computao Orientada a Servios: Uma viso geral
O desenvolvimento de software orientado a servios apresenta uma abordagem para

construo de aplicaes distribudas, que possuem suas funcionalidades expostas como
servios para serem utilizadas por outras aplicaes ou servios. Este tipo de aplicao
geralmente possui uma arquitetura orientada a servios (em ingls, Service-Oriented Architecture, ou SOA) e permite o reuso de software, uma vez que seus artefatos podem
ser decompostos em unidades lgicas distintas como servios e componentes. Alguns
estudos (Raatikainen and Mannisto, 2007; Segura et al., 2007; Trujillo and Kaestner,
2007) tm investigado e discutido a possibilidade de utilizar o modelo de arquitetura
15
orientada a servios em conjunto com abordages de LPS. Com isso, surge o conceito de
LPSOS (Krut and Cohen, 2008), unindo abordagens de orientao a servios a LPS, para
construir aplicaes customizadas, de acordo com um segmento especfico de mercado.
2.2.1
Arquiteturas Orientadas a Servios
Nos ltimos anos, metodologias para desenvolvimento de sistemas e arquiteturas tm

evoludo, partindo de um paradigma de desenvolvimento de aplicaes monolticas e
centralizadas para um paradigma de aplicaes distribudas. Computao Orientada a
Servios (COS) (em ingls, Service-Oriented Computing, ou SOC) um paradigma cujo
o objetivo o desenvolvimento de aplicaes integradas e implantadas em ambientes
distribudos, utilizando servios como elementos fundamentais (Papazoglou and Georgakopoulos, 2003). De acordo com (Raatikainen and Mannisto, 2007), tais servios
devem ser independentes de plataforma, auto descritivos, e autocontidos, de forma que
seja possvel desenv-los e implant-los de forma independente, permitindo a composio de aplicaes distribudas de forma rpida e com baixo custo.
De modo a obter mais eficincia, agilidade e produtividade, o paradigma de computao orientada a servios por meio de metodologias de desenvolvimento de software,
utiliza o modelo de Arquitetura Orientada a Servios (AOS). Com este estabelecido
um modelo de arquitetura que prov uma infraestrutura entre servios interconectados
por meio de interfaces padronizadas (Papazoglou and Georgakopoulos, 2003).
Motivao
A adoo do paradigma de computao orientada a servios no uma tarefa fcil, e
muitas empresas tm falhado neste processo. No entanto, a proposta deste paradigma
bastante atrativa para organizaes que desejam obter mais efetividade em suas solues
(Erl, 2007). Existem diversos motivos para adotar o modelo de AOS e produzir software
utilizando o paradigma de desenvolvimento orientado a servios. As principais razes
para adotar o modelo de AOS so:
Reusabilidade: a reusabilidade um dos principais objetivos da Engenharia de
Software e, no contexto de AOS, a possibilidade de compor novos servios reutilizando servios j existentes prov algumas vantagens para a organizao como
Retorno de Investimento (em ingls, Return on Investiments, ou ROI), qualidade de
software, diminuio de custos e tempo de entrega (Elfatatry and Layzell, 2004).
16
Flexibilidade e Agilidade: constantemente os sistemas de software precisam passar por modificaes para atender novos requisitos, que so requeridos por novas
exigncias de mercado (Carter, 2007). Por isso, a arquitetura do sistema de software deve ser reconfigurvel, de uma forma simples. As caractersticas do modelo
de AOS permitem um melhor alinhamento entre o sistemas de software e as necessidades de mercado por meio da integrao de novos servios e reuso de servios
existentes, possibilitando responder rapidamente a possveis mudanas nos requisitos (Endrei et al., 2004).
Integrao e Interoperabilidade: servios podem ser desenvolvidos de forma independente e ento so compostos com outros servios a fim de prover funcionalidades de uma aplicao que pode ser facilmente adaptada a novos requisitos
e, por meio da interoperabilidade, servios heretogneos so facilmente integrados, permitindo a troca de mensagem entre estes (Erl, 2005; Zi-yun and Ru-long,
2011).
O modelo de arquitetura orientada a servios normalmente definido com base em
um conjunto de princpios (Erl, 2005). Sero apresentados na prxima seo os princpios que so diretamente relacionados com este modelo de arquitetura.
Princpios e Papis
Conforme mencionado anteriormente, o modelo de arquitetura orientada a servios
definido com base em um conjunto de princpios que apoiam suas caractersticas. Os
princpios que so diretamente relacionados com este modelo de arquitura so:
Acoplamento: este princpio se refere ao nmero de dependncias entre servios.
O baixo acoplamento obtido por meio do uso de padres e contratos de servios
entre clientes e provedores, que permitem a interao dos servios utilizando interfaces bem definidas. O princpio do acoplamento tambm afeta outro atributos
de qualidade como a modificabilidade e reusabilidade da aplicao (McGovern
et al., 2003).
Contrato de Servio: servios aderem a contratos de comunicao, definidos por
um ou mais servios. Neste contrato so definidos formato de dados, regras e
caractersticas dos servios e suas funcionalidades. Para permitir estas definies,
so utilizados formatos padronizados como XML, WSDL e XSD (Erl, 2005; Dirksen, 2013).
17
Autonomia e Abstrao: os servios devem ser autnomos e auto-contidos, tendo

o controle sobre a lgica que encapsulada por eles e provendo uma abstrao de
suas funcionalidades por meio do seu contrato de servio (Erl, 2005).
Descoberta de Servios: servios so especificados de uma forma descritiva para
permitir a sua localizao por meio de mecanismos de descoberta de servios,
como o UDDI1 (Universal Description, Discovery and Integration) (Erl, 2005) e
o WS-Discovery (Microsoft Corporation, 2005).
Alta Granularidade: servios provem abstraes que suportam a separao de
interesses de domnio (separation of concerns) e visibilidade de informao (information hidding). Devido a existncia de chamadas remotas, a performance do
servio comprometida e, por esta razo, os servios devem prover funcionalidades de alta granularidade, diminuindo a necessidade de vrias chamadas remotas
para resolver uma nica requisio.
O modelo de arquitetura orientada a servios no trata apenas aspectos sobre a definio de servios, mas tambm prov definies de papis e suas responsabilidades. De
acordo com (Erl, 2007) e (Papazoglou and Georgakopoulos, 2003), so definidos quatro
papis, conforme apresentado na Figura 2.3.
Figura 2.3 Arquitetura Orientada a Servios: Papis e Operaes. Adaptado de (Papazoglou

and Georgakopoulos, 2003)
Conforme a Figura 2.3, os papis consistem em: Cliente (Service Consumer), Provedor de Servio (Service Provider), Registro e Descoberta de Servios (Service Registry)
e o Contrato de Servio (Service Contract). Tambm possvel observar nesta mesma
figura, os relacionamentos entre os papis elencados acima.
1 http://uddi.xml.org
18
Cliente: pode ser uma aplicao, um servio ou outra entidade de software que
necessita acessar o servio. Este acesso pode ser possibilitado diretamente por
meio do URI (Uniform Resource Identifier) ou por meio da descoberta de servios,
utilizando o registro de servio (Josuttis, 2007).
Provedor de Servio: a entidade que recebe e processa as requisies efetuadas
pelo Cliente. Esta entidade pode ser uma aplicao legada, um componente ou
outra entidade de software que expe sua interface como servio (Josuttis, 2007),
provendo uma implementao para um especificao ou contrato de servio. As
informaes sobre provedores de servios so publicadas no registro de servios
(McGovern et al., 2003).
Registro de Servio: entidade responsvel por manter as informaes sobre contratos de servios e provedores. Esta entidade pode ser utilizada para implementao de atributos de qualidade de servios como disponibilidade e modificabilidade
(Garcia-Gonzalez et al., 2010).
Contrato de Servios: por meio do contrato de servio especificado a forma
como o Cliente ir interagir com o Provedor do Servio. Este contrato especifica
o formato das mensagens, condies para acessar o Provedor do servio e pode
descrever atributos de qualidade (Erl, 2005; McGovern et al., 2003).
2.2.2
Linhas de Produto Orientadas a Servios
Os paradigmas de AOS e LPS possuem um objetivo em comum, que a motivao

por reutilizao de artefatos em vez de desenvolv-los do incio. Isto implica ganhos
em produtividade, reduo de custos e tempo de entrega. LPS explora caractersticas
comuns e variveis entre um conjunto de sistemas e o paradigma de AOS possui caractersticas que so requeridas por muitas LPSs (Yu et al., 2010), provendo uma estrutura
dinmica e desacoplada, de modo que possibilite obter mais flexibilidade e maior poder
de adaptao a novos cenrios (Ye et al., 2007). Com o objetivo de construir artefatos
de software cada vez mais reutilizveis, diversas abordagens (Galster, 2010; Raatikainen
and Mannisto, 2007; Segura et al., 2007; Smith and Lewis, 2009; Trujillo and Kaestner,
2007) tm investigado o uso do modelo de Arquitetura Orientada a Servios (AOS) em
conjunto com abordagens de LPS.
Algumas abordagens propostas (Istoan et al., 2009; Medeiros, 2010; Ribeiro, 2010)
que tratam questes relacionadas a Linhas de Produto Orientadas a Servios, consideram
19
unidades de servios como features, conforme a Figura 2.4.
Figura 2.4 Linha de Produto Orientadas a Servios: Configurao de Produtos
Conforme apresentado na Figura 2.4, cada unidade de servio considerada uma

feature, que pode compor a configurao do produto, respeitando restries que determinam os servios como Obrigatrio, Opcional ou Alternativo.
Na abordagem proposta neste trabalho, considerado que os servios so partes
de uma feature. Ou seja, conforme apresentado na Figura 2.5, uma feature pode ser
composta por um ou mais servios e um conjunto de implementaes que utilizam tais
servios para prover funcionalidades.
20
2.3. TRABALHOS RELACIONADOS
Figura 2.5 Composio de features
Com essa definio, foi possvel estabelecer um alinhamento entre as adaptaes

da aplicao Cliente e os servios disponveis no lado Servidor. Esse alinhamento foi
possibilitado por meio de reconfiguraes na composio de servios, de acordo com as
features adaptadas na aplicao Cliente.
2.3
Trabalhos Relacionados
Durante o desenvolvimento deste trabalho foi possvel identificar alguns trabalhos relacionados. Estes trabalhos so descritos abaixo:
(Parra et al., 2009) prope uma Linha de Produto Dinmica, Orientada a Servio e
Sensvel ao Contexto denominada CAPucine. Esta linha de produto possui uma abordagem orientada a modelos e dividida em dois processos para a execuo da derivao do
produto. No primeiro processo, todas as features selecionadas so associadas ao artefato
que corresponde ao modelo parcial do produto, que composto e transformado para gerar o produto. O segundo processo referente a adaptaes dinmicas, que so efetuadas
utilizando o FraSCAti2 . O FraSCAti uma plataforma de Arquitetura de Componentes
Orientados a Servio (em ingls, Service Component Architecture, ou SCA) com propriedades dinmicas que permite operaes de bind e unbind de componentes em tempo
de execuo.
2 http://frascati.ow2.org/
21
2.3. TRABALHOS RELACIONADOS
(Yu et al., 2010) prope uma abordagem que dividida em trs fases e une conceitos
de LPS a COS para desenvolver composies dinmicas de servios. A primeira fase
da abordagem consiste em especificar a arquitetura da linha de produto, efetuando a
sua integrao com o modelo de variabilidades. A segunda fase consiste em definir
composies de servios, que devem seguir a arquitetura da linha de produto. A terceira
fase consiste em criar e manter de forma autnoma a aplicao construda com base na
arquitetura da linha de produto.
(Alferez and Pelechano, 2011) prope uma abordagem para projetar e implementar
Web Services Sensveis ao Contexto em uma famlia de sistemas. A abordagem proposta apoiada pelo (MoRE-WS), que uma plataforma de reconfigurao guiada por
modelos, onde so utilizados modelos de variabilidades como polticas de adaptao
para gerar e executar de forma automtica o plano de reconfigurao.
A partir destes trabalhos foram identificadas algumas limitaes na tentativa de apliclos no cenrio de LPSOSSC que seguem o modelo de AOS utilizando o padro arquitetural Cliente-Servidor (Erl, 2007), onde features que compem o produto no lado cliente
podem enderear uma composio de servios.
Uma limitao encontrada no trabalho proposto por (Parra et al., 2009) diz respeito
a complexidade da abordagem, que dificulta a sua utilizao em sistemas de pequeno
porte ou que esto na fase inicial da adoo do paradigma de LPS. No trabalho proposto
por (Alferez and Pelechano, 2011), foi possvel observar uma limitao que consiste
em considerar um servio como uma nica feature, efetuando adaptaes dinmicas por
meio da substituio de seus provedores. Neste caso, no so tratadas as features que
so compostas no apenas por servios, mas tambm por outros artefatos que utilizam
tais servios para prover suas funcionalidades.
Por fim, conforme colocado por (Silva et al., 2013), os reconfiguradores utilizados
pelas abordagens atuais, inclusive (Yu et al., 2010), apresentam um forte acoplamento
com sua respectiva LPSD.
No prximo captulo (Captulo 3) ser apresentada a soluo proposta neste trabalho,
detalhando como a soluo trata as limitaes descritas nesta seo.
22
3
DYMOS Framework
Seja uma referncia em qualidade. Algumas pessoas no esto
acostumadas com um ambiente em que a excelncia esperada.
Be a yardstick of quality. Some people arent used to an environment
where excellence is expected.
STEVE JOBS
3.1
Viso Geral da Soluo
O DYMOS prov, de uma forma desacoplada, uma plataforma de reconfigurao de variabilidades dinmicas e descoberta de servios para Linhas de Produto de Software Orientado a Servios e Sensvel ao Contexto. O DYMOS oferece algumas vantagens como:
possibilidade de Gerncia de Variabilidades de uma forma leve e simples, permitindo
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; Mecanismo de Descoberta de Servio, que prov uma abstrao entre o
Cliente e o Servio, permitindo agregar critrios para a seleo do servio mais adequado, de acordo com uma requisio; As principais funcionalidades do DYMOS esto
dispostas na forma de servios web e, por meio destes, obtida a caracterstica de interoperabilidade, permitindo que o framework seja utilizado por aplicaes desenvolvidas
em outras plataformas.
De acordo com (Gomaa and Hashimoto, 2011), possvel classificar uma reconfigurao em tempo de execuo como comportamental, arquitetural ou reconfigurao
de componentes. Uma adaptao comportamental ocorre quando o comportamento do
23
sistema alterado, mantendo a mesma estrutura e arquitetura. Uma adaptao arquitetural ocorre quando a arquitetura do sistema impactada diretamente pela adaptao.
Uma adaptao de componentes envolve uma substituio de um componente por outro
que implemente a mesma interface. O tipo de reconfigurao executada pelo DYMOS
se trata de reconfigurao de componentes.
O DYMOS foi desenvolvido de forma modular utilizando tecnologias OSGi, com
a finalidade de permitir variabilidades dinmicas em Linhas de Produto de Software
Orientado a Servios e Sensvel ao Contexto (LPSOSSCs). apresentado por meio da
Figura 1.1, a forma como o DYMOS est disposto em relao as demais tecnologias
utilizadas.
Como forma de obter componentes modularizados, foi utilizado o iPOJO, que um
framework para desenvolvimento de componentes orientados a servio para sistemas dinamicamente adaptveis (Escoffier et al., 2007). Como plataforma de execuo, foi utilizado o framework Apache Felix, que uma implementao do OSGi Service Platform.
Para expor funcionalidades atravs de servios web, foi utilizado o OSGi Distribudo,
que um subprojeto do Apache CXF.
Dessa forma, faz-se necessrio um framework que seja responsvel por tratar reconfiguraes de tais variabilidades. De acordo com (Erl, 2007), o modelo de AOS segue o
padro arquitetural Cliente-Servidor. Ento, como o cliente e o servidor so executados
em ambientes diferentes, necessrio que o DYMOS seja capaz de (i) receber notificaes sobre mudanas no contexto, para que (ii) reconfiguraes possam ser efetuadas.
SSCs so flexveis, dinmicos e se adaptam em tempo de execuo de acordo com
mudanas no ambiente, obedecendo um conjunto de regras (Hallsteinsen et al., 2006;
Kim et al., 2005; Oreizy et al., 1999). Quando mudanas ocorrem, reconfiguraes so
executadas, tornando disponvel ou indisponvel um ou mais servios, compondo uma
plataforma de servios dinmica. Considerando que os servios estaro em execuo
em uma plataforma com caractersticas dinmicas, necessrio um (iii) mecanismo de
descoberta de servios, que insira uma camada de abstrao entre o cliente, o servidor e
o servio requisitado.
Com isso, espera-se que haja um menor no acoplamento e maior flexibilidade, visto
que no devem existir requisies para um servio especfico, de forma fixa, mas para
um servio que atenda a uma determinada especificao. O mecanismo de descoberta
de servios deve ser responsvel por selecionar e prover uma referncia (endpoint) para
o servio mais adequado.
Na Seo 1.2 foi apresentada a problemtica tratada na abordagem proposta neste
24
trabalho e foram elencados os itens i, ii e iii que, respectivamente, endeream as funcionalidades de recebimento de notificaes sobre mudanas no contexto, reconfigurao
de variabilidades e descoberta de servios. Com o objetivo de abordar estes itens, os
seguintes artefatos foram desenvolvidos em forma de componentes como parte da soluo:
Descritor de Servios permite descrever servios, indicando um ID (identificador), especificaes, implementaes e regras que so aplicadas quando a operao de
descoberta de servio solicitada. Quando h uma requisio, tais regras devem
ser utilizadas a fim de selecionar o servio adequado.
Descritor de Variabilidades permite descrever variabilidades, indicando pontos de variao. A descrio consiste na atribuio de um ID e um mapeamento entre
pontos de variao e um ou mais servios.
Mecanismo de Reconfigurao de Servios responsvel por reconfigurar os servios para atender a mudanas no ambiente. A reconfigurao feita em termos
de ativao ou desativao de um ou mais servios, tornando-os disponveis ou
indisponveis para utilizao. Este componente atende ao item ii, mencionado na
Seo 1.2.
Mecanismo de Descoberta de Servios responsvel por prover operaes de descoberta de servios. Essas operaes possibilitam a recuperao de referncias (endpoint) de acesso a servios, informando o ID atribudo na descrio do servio.
Este mecanismo deve selecionar o servio mais adequado, de acordo com o ID
informado e, em seguida, deve ser retornado o endpoint do servio para que possa
ser utilizado pelo cliente. Com isso, servios podem ser inseridos ou removidos a
qualquer momento, sem haver a necessidade de alterao de cdigo no cliente ou
no servidor. Este componente atende ao item iii, mencionado na Seo 1.2.
Os itens Descritor de Servios e Descritor de Variabilidades so utilizados pelos
mecanismos de Reconfigurao e Descoberta de Servios, de modo que as operaes
de reconfigurao e descoberta de servios sejam efetuadas de acordo com cada uma
das descries. De modo a permitir os Descritores de Servios e de Variabilidades, foi
definida e disponibilizada uma sintaxe baseada em XML, obedecendo um meta-modelo.
Esta sintaxe dever ser utilizada para especificar cada um dos itens.
As operaes de reconfigurao e descoberta de servios que so providas respectivamente pelo Mecanismo de Reconfigurao de Servios e Mecanismo de Desco-
25
3.2. ELICITAO DE REQUISITOS
berta de Servios, esto disponveis atravs de servios web. O servio web referente a
operaes de reconfigurao, permite que o framework seja notificado sobre mudanas
no contexto, atendendo ao item i, mencionado na Seo 1.2.
Nas prximas sees deste captulo sero apresentados mais detalhes sobre a soluo
proposta neste trabalho.
3.2
Elicitao de Requisitos
Nesta seo sero apresentados os requisitos elicitados para o desenvolvimento do DYMOS Framework.
Elicitao de Requisitos o processo identificao das necessidades de um determinado domnio de negcio. Este processo executado com o apoio de usurios, clientes e
stakeholders1 (Tiwari et al., 2012). Os requisitos de um sistema so categorizados como
Requisitos Funcionais (RFs) ou Requisitos No-Funcionais (RNFs). por meio de RFs
que as funcionalidades so elencadas, descrevendo as operaes que o sistema deve prover. Os RNFs elencam restries de qualidade que so atribudas aos RFs (Ullah et al.,
2011).
Analisando a problemtica descrita na Seo 1.2 e o objetivo proposto neste trabalho,
foi possvel elicitar os Requisitos Funcionais (RFs) e Requisitos No-Funcionais (RNFs)
do framework proposto. Os requisitos esto detalhados abaixo:
RF1 necessrio prover uma forma de descrever servios, variabilidades e mapeamento entre estes.
RF2 A aplicao cliente composta por features que podem ser ativadas ou desativadas
de acordo com mudanas no ambiente. Dessa forma, o DYMOS deve prover um
mecanismo que possibilite receber notificaes sobre mudanas na composio
das features na aplicao cliente.
RF3 necessrio o desenvolvimento de um mecanismo capaz de tratar a notificaes
sobre mudanas na composio das features, identificando as variabilidades que
sero afetadas.
RF4 O DYMOS deve ser capaz de efetuar reconfiguraes na plataforma de servios
de acordo com as variabilidades identificadas no RF3.
1 Pessoa
ou Entidade interessada no projeto
26
3.3. TECNOLOGIAS UTILIZADAS
RF5 O DYMOS deve prover um mecanismo para descoberta de servios, de modo que
quando houver uma requisio por um determinado servio, seja retornada uma
referncia para o servio mais adequado.
RF6 necessria a existncia de um mecanismo que permita a implantao de novos
servios e atualizao dos descritores de servios e variabilidades em tempo de
execuo, de modo que variabilidades possam ser includas ou excludas sem a
necessidade de interromper a execuo do DYMOS.
RF7 Para possibilitar a descoberta de servios, o mecanismo deve receber o ID atribudo
ao servio no descritor e, e acordo com este, o servio mais adequado deve ser
selecionado.
RF8 Deve existir a possibilidade de mapear servios alternativos, que devem ser utilizados em caso de indisponibilidade do servio principal.
RF9 A seleo do servio adequado deve acontecer de acordo com uma prioridade, que
atribuda na descrio do servio.
RNF1 O RF1 deve ser contemplado por meio de uma linguagem baseada em XML.
Os descritores devem ser tratados como meta-dados e convertidos em objetos,
e devem ser utilizados no gerenciamento das reconfiguraes e descobertas de
servios.
RNF2 O RF2 deve estar disponvel por meio de servios web.
3.3
Tecnologias Utilizadas
apresentado por meio da Figura 1.1, a forma como o DYMOS est disposto em relao
s demais tecnologias utilizadas. Nesta seo apresentada uma breve descrio sobre
cada uma das delas.
OSGi O framework OSGi define um conjunto de especificaes que permitem o desenvolvimento de modulares em Java, provendo um maior controle sobre a estrutura
do cdigo e gerenciamento dinmico do ciclo de vida dos componentes. Este
framework permite que componentes sejam instalados, inicializados, encerrados,
atualizados e desinstalados sem a necessidade de reiniciar a aplicao (de Castro Alves, 2011; Hall et al., 2011).
27
3.4. ARQUITETURA E IMPLEMENTAO
Apache Felix uma distribuio open-source, mantida pela Apache Foundation com o
apoio da comunidade. Este framework implementa a verso 4.x da especificao
OSGi Service Platform e utilizado como plataforma de execuo de aplicaes
OSGi.
iPOJO um modelo de componente orientado a servio que tem como objetivo simplificar o desenvolvimento de aplicaes OSGi. O iPOJO permite o desenvolvimento
de componentes orientados a servio para compor sistemas modulares que requerem adaptaes em tempo de execuo (Escoffier et al., 2007).
OSGi Distribudo (em ingls, Distributed OSGi ou DOSGi) um subprojeto do
Apache CXF. O DOSGi fornece uma implementao de referncia com base em
Web Services, que segue a especificao OSGi Remote Services e permite que
aplicaes OSGi sejam implantadas na forma de servios web.
Alm das tecnologias mencionadas acima, tambm foi utilizado o JAXB2 (Java Architecture for XML Binding). O JAXB consiste em um conjunto de bibliotecas Java que
permitem a converso de XML em objetos Java e vice-versa.
A utilizao das tecnologia mencionadas nesta seo possibilitou o desenvolvimento
da soluo proposta neste trabalho. A Seo 3.4 descrever com mais detalhes a escolha
destas tecnologias e onde cada uma delas foram utilizadas.
3.4
Arquitetura e Implementao
A arquitetura de software tem um papel importante no seu ciclo de vida. Na arquitetura

desenhada a estrutura e organizao que define como os componentes e subsistemas
interagem, permitindo uma viso mais clara sobre a anlise e projeto de componentes do
sistema (Kruchten et al., 2006). Alm disso, por meio da arquitetura do software que
a estrutura geral do sistema separada em termos de componentes e conexes, a partir
de detalhes internos de cada componentes (Shaw and Garlan, 1996).
De acordo com (Clements et al., 2003), uma arquitetura de software pode ser vista
como uma ligao entre os requisitos de um sistema e a implementao, descrevendo
componentes, ligaes entre estes e possveis restries. Nesse contexto, ns definimos
a arquitetura do DYMOS com o objetivo de atender os requisitos descritos na Seo 3.2.
apresentada por meio da Figura 3.1 uma viso geral da Arquitetura do DYMOS,
destacando os principais componentes e suas respectivas ligaes. Conforme possvel
2 http://www.oracle.com/technetwork/articles/javase/index-140168.html
28
observar na figura, os principais componentes so o ServiceContext, o VariabilityDescriptor, o ServiceDescriptor, o WSResolver e o ApplicationService, que externaliza as
funcionalidades de descoberta de servios e reconfigurao de variabilidades por meio
de web services.
Figura 3.1 DYMOS: Viso Geral da Arquitetura
As prximas subsees apresentam a arquitetura sob diferentes vises e discusses

sobre os principais componentes. Por fim, na Seo 3.4.4 feita uma discusso sobre as
decises arquiterurais e como os requisitos elencados foram atendidos.
3.4.1
Componentes Descritores
Como forma de permitir a descrio de elementos como Variabilidades e Composio de

Servios, ns definimos estruturas de metadados, que podem ser visualizadas no Captulo A do Apndice. Estas estruturas foram modeladas utilizando notaes XSD (XML
Schema Definition) e permitem que os elementos sejam descritos por meio de XML,
podendo ser convertidos para uma estrutura de objetos Java, que so utilizadas para gerenciar as informaes sobre as Variabilidades e Composies de Servios. Como um
requisito para prover a descrio do elemento em forma de objetos Java, necessrio
que o descritor siga a especificao definida pela interface ObjectDescriptor.
29
Conforme possvel observar na Figura 3.2, so definidos mtodos getObjectDescriptors que possuem diferentes parmetros, provendo vrias formas de entrada de dados, onde o tipo de retorno T representa o tipo do elemento descrito. Alm desses
mtodos, o descritor tambm prov um mtodo para efetuar uma converso inversa, de
objeto Java para XML.
Figura 3.2 Especificao de Descritores
Os descritores implementados para o DYMOS consistem em: Descritor de Servios

(DS), por meio do componente (ServiceDescriptor); Descritor de Variabilidades (DV)
por meio do componente (VariabilityDescriptor); e o Web Service Resolver (WSR) por
meio do componente (WSResolver). apresentado por meio da Figura 3.3 como a especificao de cada descritor est disposta em relao a especificao genrica ObjectDescriptor.
30
Figura 3.3 Relacionamento entre Descritores
Como possvel perceber na Figura 3.3, a especificao de cada descritor herda da

especificao genrica ObjectDescriptor, efetuando a substituio do tipo T pelo respectivo tipo do descritor.
A seguir, sero apresentados detalhes sobre a implementao de cada um dos descritores.
Conforme mencionado anteriormente, ns definimos uma estrutura de metadados que
foi modelada utilizando notaes XSD e possibilitam descrever, por meio de XML, os
servios que estaro ligados a features do produto. Os metadados definidos para descrever Servios obedecem a estrutura de classes apresentada na Figura 3.4.
31
Figura 3.4 Descritor de Servios: Estrutura de Metadados
Conforme foi definido a estrutura dos metadados de Servios, possvel observar na

Figura 3.4 que um Servio possui: uma Identificao (ID), por meio do atributo id;
uma Especificao, por meio do atributo serviceSpec; uma Implementao, por meio
do atributo serviceImpl; e um conjunto de Servios Alternativos, que possuem uma
referncia para um outro servio descrito e uma prioridade.
Ao descrever um servio, necessrio atribuir um Identificador nico e uma Especificao, que indica um contrato de implementao (interface) que o servio implementa.
Apesar de no ser mandatrio, alm dessas informaes, possvel atribuir uma determinada Implementao e um conjunto de Servios Alternativos. apresentado por meio
da Figura 3.5 um exemplo prtico de Descries de Servios.
32
<?xml version="1.0"?>
<services>
<service id="dataBaseAccessService"
service-impl="br.ufpe.cin.assert.ws.dataAccess.impl.DataBaseAccessServiceImpl">
<service-spec>br.ufpe.cin.assert.ws.dataAccess.IDataAccessService</service-spec>
<alternative-service ref="fileAccessService" priority="1" />
</service>
<service id="fileAccessService"
service-impl="br.ufpe.cin.assert.ws.dataAccess.impl.FileAccessServiceImpl">
<service-spec>br.ufpe.cin.assert.ws.dataAccess.IDataAccessService</service-spec>
</service>
<service id="dataEncryptService"
service-impl="br.ufpe.cin.assert.encrypt.ws.dataEncrypt.impl.EncryptServiceImpl">
<service-spec>br.ufpe.cin.assert.encrypt.ws.dataEncrypt.IDataEncryptService</service-spec>
</service>
<service id="authService">
<service-spec>br.ufpe.cin.assert.auth.ws.IAuthService</service-spec>
</service>
</services>
Figura 3.5 Descritor de Servios: Exemplo Prtico
Referente a atribuio de valores aos atributos, a especificao e implementao do

servio devem seguir o padro de nome de classe Java na forma completa, como demonstrado na figura. Um Servio Alternativo pode ser declarado atribuindo um valor
ao atributo service-ref, que deve ser um ID de um servio j descrito. Cada Servio
Alternativo deve receber uma prioridade.
Por meio do DS, possvel obter objetos Java que representam as informaes sobre
os servios descritos, permitindo que tais informaes sejam utilizadas pelo DYMOS
nas operaes de Reconfigurao e Descoberta de Servios. A estrutura de metadados de
servios pode ser visualizada na Seo A.1 e a forma como as informaes provenientes
de tais metadados so utilizadas em tais operaes so descritas com mais detalhes na
Seo 3.4.2
Assim como foi feito no DS, para o DV tambm foi definida uma estrutura de metadados que possibilitam descrever, por meio de XML, as variabilidades que faro parte do
produto. Os metadados definidos para descrever Variabilidades obedecem a estrutura de
classes apresentada na Figura 3.6.
Conforme foi definido a estrutura dos metadados de Variabilidades, possvel ob-
33
servar na Figura 3.6 que uma Variabilidade possui: uma Identificao (ID), por meio do
atributo id; uma nome , por meio do atributo name; e um conjunto de variaes
(Variant). Uma Variant composta por um ID, um nome e um conjunto de Referncia
para Servios.
Figura 3.6 Descritor de Variabilidades
Ao descrever uma variabilidade, necessrio atribuir um Identificador nico, um

Nome no obrigatrio e um conjunto de variaes (Variant). Um elemento do tipo (Variant) representa uma possibilidade de variao na configurao de um produto (Pohl
et al., 2005) e pode ser descrito indicando um Identificador nico, um Nome e um conjunto de Referncia para Servios. O conjunto de Referncia para Servios representam
os servios que so endereados por features e que devem ser ativados ou desativados
quando uma reconfigurao efetuada. Para cada referncia deve ser atribuindo o valor
do atributo service-ref coincidente com um ID vlido de servio j descrito. apresentado por meio da Figura 3.7 um exemplo prtico de Descries de Variabilidades.
34
<variabilities>
<variability id="dataAccess">
<variant id="dataBaseAccess">
<service-ref ref="dataBaseAccessService" />
</variant>
<variant id="fileAccess">
<service-ref ref="fileAccessService" />
<service-ref ref="dataEncryptService" />
</variant>
</variability>
<variability id="authVariability">
<variant id="auth">
<service-ref ref="authService" />
</variant>
</variability>
</variabilities>
Figura 3.7 Descritor de Variabilidades: Exemplo Prtico
No exemplo apresentado por meio da Figura 3.7, so descritas duas variabilidades,

que so: dataAccess e authVariability. Cada uma das variabilidades possuem possibilidades de variaes que so: dataBaseAccess e fileAccess para a variabilidade
dataAccess; e auth para a variabilidade authVariability.
Cada uma das variaes descritas podem enderear um conjunto de Referncias para
Servios, formando uma composio de servios. Esta composio de servios atendem
a uma ou mais features do produto e deve manter os servios ativos e disponveis quando
a variao estiver ligada a estas features. Isso quer dizer que, de acordo com o exemplo
demonstrado na Figura 3.7, no momento em que a variao fileAccess for ligada ao
produto, os servios fileAccessService e dataEncryptService devem estar ativos e
disponveis para uso.
A estrutura de metadados de variabilidades pode ser visualizada na Seo A.2 e a
forma como as informaes provenientes de tais metadados so utilizadas em operaes
de reconfigurao de variabilidades so descritas com mais detalhes na Seo 3.4.2
Web Service Resolver
Na definio e modelagem dos metadados referentes ao WSDL, foi utilizado uma estrutura XSD que permite descrever, por meio de XML, servios como um conjunto de
operaes. O WSR utiliza a verso 1.1 da estrutura, que est disponvel na Seo A.3.
Este componente no faz interao direta com o usurio e utilizado por outros componentes da arquitetura.
35
O WSR utilizado em operaes de Descoberta de Servios, sendo a sua principal

funo, prover de acordo com um determinado servio, atributos que no so descritos
no DS e que so particulares a cada implementao de um servio como ServiceName,
PortType, Target Namespace, etc. Dessa forma, o WSR permite uma maior flexibilidade
ao DYMOS, agregando caractersticas dinmicas e de baixo acoplamento. apresentado
por meio da Figura 3.8 o fluxo de dados durante a execuo deste descritor.
Figura 3.8 Descritor de WSDL: Fluxo de Dados
Conforme possvel visualizar na Figura 3.8 o dado de entrada um Web Service

Definition Language (WSDL) referente a um determinado servio e obtido como sada
um objeto Java que permite acessar, de forma mais simples, as informaes sobre este
servio. Na Seo 3.4.2 feita uma explanao com mais detalhes sobre a utilidade
deste componente e como as informaes obtidas atravs dele so teis para a operao
de Descoberta de Servios.
3.4.2
Componente ServiceContext
Uma vez que os Servios esto descritos e mapeados nas descries de Variabilidades por meio de Composio de Servios, as informaes sobre tais descries devem
ser utilizadas no gerenciamento das Variabilidades, em tempo de execuo. O Componente ServiceContext responsvel por manter tais informaes em memria, de modo
que seja possvel utiliz-las durante as operaes de Reconfigurao de Variabilidades e
Descoberta de Servios. Durante o decorrer desta seo mecionaremos os termos Contexto de Servios e Contexto de Variabilidades, que respectivamente significam os
servios descritos e as variabilidades descritas, ambos em memria. apresentado por
meio da Figura 3.9 uma viso sob uma perspectiva de dependncia entre o ServiceContext e os demais componentes, indicando a relao entre eles atravs de importao e
exportao de pacotes (packages).
36
Figura 3.9 Componente ServiceContext: Uma viso sob uma perspectiva de dependncia entre
componentes
Conforme possvel observar na Figura 3.9, 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, permitindo
o gerenciamento das Variabilidades e Servios descritos. Este gerenciamento consiste
em utilizar as informaes sobre as Variabilidades e Servios para em manipular o container OSGi, efetuando operaes como install, uninstall, start, stop e getEndpoint.
As principais funcionalidades implementadas pelo componente ServiceContext so
as operaes de Reconfigurao de Variabilidades, Descoberta de Servios e ContextHotBuild. Cada uma destas funcionalidades so descritas com mais detalhes nas
prximas sees.
Reconfigurando Variabilidades Dinmicas
Utilizar tcnicas de LPS tem se mostrado uma forma eficiente de lidar com diferentes
necessidades dos usurios (Hallsteinsen et al., 2006), uma vez que possvel construir
37
um produto de software por meio da seleo das variabilidades. No entanto, as tcnicas

de LPS na sua forma tradicional no so adequadas para produtos cuja arquitetura precisa ser adaptada em tempo de execuo, como aplicaes sensveis ao contexto. Esse
tipo de aplicao possui variabilidades dinmicas, exigindo que a arquitetura da LPS
seja capaz de tratar tais variabilidades (Hallsteinsen et al., 2008).
Para tratar esse tipo de questo, foi implementado no DYMOS mecanismos para reconfigurao de variabilidades dinmicas. Por meio dos mecanismos de reconfigurao,
possvel ativar ou desativar servios que so endereados por variabilidades, de acordo
com mudanas no contexto notificadas pela aplicao cliente. Ou seja, quando h uma
mudana no contexto e a aplicao se adapta, o DYMOS notificado para que efetue
reconfigurao nos servios, de forma que as adaptaes da aplicao sejam atendidas.
Para que seja possvel efetuar uma reconfigurao, o DYMOS deve ser notificado
sobre a adaptao na aplicao e informado sobre as variabilidades que foram afetadas.
apresentado por meio da Figura 3.10, a sequncia das operaes necessrias para
efetuar a reconfigurao de variabilidades dinmicas.
Figura 3.10 Reconfigurando Variabilidades Dinmicas: Diagrama de Sequncia
38
Conforme possvel observar na Figura 3.10, a aplicao Client notifica o DYMOS

sobre uma mudana no contexto, indicando qual o ponto de variao que foi afetado.
A notificao ocorre por meio de uma requisio assncrona ao web service responsvel
por receber tais notificaes. Na Seo 3.4.3 sero expostos mais detalhes sobre os web
services disponveis para a aplicao Client.
Uma vez que a notificao recebida pelo componente ApplicationContext, a mesma
repassada ao ServiceContext para que possa ser tratada, utilizando as informaes obtidas a partir do DV e DS. Inicialmente, de acordo com a variante informada na notificao, so recuperadas as suas configuraes, que so mantidas no Contexto de Variabilidades pelo componente ServiceContext. Como j apresentado na Seo 3.4.1, a
descrio de uma variabilidade consiste em um conjunto de variaes, que so configuradas a partir de uma composio de servios.
Por meio da configurao da variabilidade, so identificados os servios endereados
a ela e, utilizando os atributos service-spec e service-impl descritos no DS respectivamente como argumentos dos mtodos findBundleService e findBundleServiceImpl,
so buscados no OSGi Container os respectivos mdulos que so responsveis por prover tais servios. Os mdulo encontrados so ativados e, aps isso, os servios devero
estar disponveis para utilizao.
Descoberta de Servios
Quando uma requisio por um servio efetuada, uma questo que pode ser levantada
sobre como selecionar o servio adequado. A seleo de um servio feita com base
em requisitos funcionais e requisitos no-funcionais e, dentre um grande conjunto de
servios, um nico servio deve ser selecionado, de modo que a funcionalidade seja
provida (Yu and Reiff-Marganiec, 2008).
Mecanismos de descoberta de servios agregam caractersticas dinmicas a uma soluo de software, permitindo que a relao entre cliente e servios no seja tratada de
forma fixa ou acoplada. A utilizao de mecanismos de descoberta de servios permitem, inclusive, acrescentar critrios que podem determinar, dentre um conjunto de servios, a seleo de um servio mais adequado (Khezrian et al., 2010). Como exemplo de
tais critrios, possvel citar fatores como uptime, confiabilidade, latncia, quantidade
de pacotes perdidos, ou caractersticas mais bsicas como uma simples verificao se o
servio est ativo e seleo por prioridade em caso de indisponibilidade.
No contexto do DYMOS, foram implementados mecanismos que so responsveis
por operaes de Descoberta de Servios. apresentada por meio da Figura 3.11, uma
39
viso geral sobre a interao entre os componentes envolvidos nestas operaes.
Figura 3.11 Descoberta de Servios: Viso geral sobre a interao entre componentes
De acordo com o que exposto na Figura 3.11, uma operao de descoberta de servios iniciada a partir de uma requisio feita pela aplicao cliente, que demonstrada
pelo item 1. Aps receber a requisio, o item 2 executado e quando o componente ApplicationService a repassa para o componente ServiceContext, para que possa
ser tratada. O tratamento da requisio, demonstrado pelo item 3, consiste em analisar
um conjunto de critrios pr-definidos para que seja possvel selecionar o servio mais
adequado para atender tal requisio.
Os critrios adotados na implementao dos mecanismos de Descoberta de Servios
do DYMOS consistem na verificao de disponibilidade de um servio e seleo de
servios alternativos de acordo com uma prioridade. Estes critrios so definidos de
acordo com as informaes descritas no DS, como apresentado na Figura 3.12.
40
<services>
<service id="service1"
service-impl="br.ufpe.cin.assert.ws.service1.impl.Service1Impl">
<service-spec>br.ufpe.cin.assert.ws.greetService.IGreetService</service-spec>
<alternative-service ref="service2" priority="3" />
</service>
<service id="service2" service-impl="br.ufpe.cin.assert.ws.service2.impl.Service4Impl">
</service>
<service id="service3">
</service>
<service id="service4" service-impl="br.ufpe.cin.assert.ws.service4.impl.Service4Impl">
</service>
</services>
Figura 3.12 Descoberta de Servios: Servios descritos para um exemplo prtico
Os atributos utilizados nas operaes de descoberta de servios so: o serviceimpl, onde definida a implementao do servio; o service-spec, onde definido a
especificao ou contrato do servio; e o priority definido em alternative-service,
que elenca servios alternativos indicando uma prioridade para cada um. apresentado
na Figura 3.13 o diagrama que representa a sequncia de funes executadas durante a
operao de descoberta de servios.
41
Figura 3.13 Descoberta de Servios: Diagrama de Sequncia
Conforme possvel observar na Figura 3.13, a execuo de uma operao de descoberta de servio iniciada quando h uma requisio por um servio atravs do mtodo
getEndpoint, onde informado o ID do servio requerido. O principal objetivo desse
tipo de operao recuperar uma referncia (endpoint) de um servio que atenda a uma
determinada funcionalidade, para que seja possvel utiliz-lo.
Quando a requisio recebida pelo componente ApplicationContext, ela repassada ao ServiceContext para que possa ser tratada, utilizando as informaes obtidas a
partir do DS. Inicialmente, de acordo com o servio requisitado, so recuperadas as suas
informaes, que so mantidas em memria pelo componente ServiceContext. Aps
recuperar tais informaes, os atributos service-impl, service-spec e alternativeservice so utilizados para efetuar a seleo do servio.
42
Com o objetivo de encontrar o servio mais adequado para atender a requisio recebida, o componente ServiceContext interage com o OSGi Container a fim de identificar
o bundle responsvel por prover tal servio. A sequncia utilizada na seleo do servio
consiste em (i) buscar por um servio que atenda Especificao e Implementao definida no DS por meio dos atributos service-spec e service-impl respectivamente;
caso acontea uma falha no item i e o servio no possa ser encontrado utilizando estes
atributos, (ii) efetuada uma busca por servios alternativos, respeitando a prioridade
definida no atributo priority e considerando que os menores nmeros so mais prioritrios. caso acontea uma falha no item ii e no seja possvel selecionar um servio, (iii)
efetuada uma busca por servios que provem uma implementao para a Especificao definida no atributo service-spec, considerando inclusive, os servios que esto
em execuo no OSGi Container e que no esto descritos no DS.
Aps encontrar e selecionar o servio mais adequado, o ServiceContext interage com
o componente WSResolver informando o endereo onde o servio est publicado, e obtem como resposta as informaes que constam no WSDL em forma de objetos Java.
Tais objetos so processados e como resposta gerado um valor que corresponde a
uma referncia para o servio selecionado. A resposta gerada, que obedece o formato
serviceEndpoint;targetNamespace;serviceName, enviada ao cliente que efetuou a
requisio do servio.
O mecanismo de Descoberta de Servios implementado como parte do DYMOS
oferece uma abstrao entre o cliente e o servio. Essa abstrao possibilita a existncia
de requisies por servios informando um ID previamente mapeado com um conjunto
de informaes sobre o servio, que so utilizadas como critrios de seleo. Consequentemente, obtido um menor acoplamento entre o cliente e o servio, possibilitando
inclusive, a implantao de forma facilitada de atualizaes de servios que j esto em
execuo ou de novos servios.
Reconstruindo o ServiceContext com o ContextHotBuild
Com o passar do tempo, um software necessita ser atualizado por diferentes razes como
resoluo de bug, melhoria dos seus componentes, ou por questes de adaptao do
software para atender a novos requisitos (Alhazbi and Jantan, 2006). Hot swapping
e On-the-Fly Software Replacement so termos utilizados no contexto de evoluo de
software, que consiste em reconfiguraes em tempo de execuo, permitindo adicionar,
remover ou atualizar dinamicamente um componente (Tan, 2001; Oreizy et al., 1998).
Conforme elicitado por meio do requisito funcional RF6, necessria a existncia
43
de um mecanismo que permita a implantao de novos servios e atualizao dos descritores de servios e variabilidades em tempo de execuo, de modo que variabilidades
possam ser includas ou excludas sem a necessidade de interromper a execuo do framework.
Com o objetivo de atender este requisito, foi desenvolvido como parte do DYMOS
o ContextHotBuild, que permite o hot swapping de servios e variabilidades. O ContextHotBuild responsvel por capturar mudanas no ciclo de vida dos componentes
instalados no OSGi Container, e no contexto do DYMOS, em especial quando o estado
do componente alterado para INSTALLED.
No momento em que um novo componente instalado, o DYMOS faz uma nova leitura no DS e no DV por meio do ContextHotBuild, em busca de atualizaes nas informaes descritas e, em seguida, reconstri o contexto de servios e variabilidades. Este
mecanismo tambm prov uma facilidade para operaes de implantao de componentes no OSGi Container, que consiste em disponibilizar um diretrio para implantao
de componentes. Dessa forma, quando componentes so inseridos ou removidos de tal
diretrio, so executadas no OSGi Container operaes de install e uninstall respectivamente. Isto gera uma mudana no ciclo de vida dos componentes, e consequentemente,
uma reconstruo no Contexto de Servios e Variabilidades.
Este mecanismo permite a incluso ou remoo de servios e variabilidades sem a
necessidade de interromper a execuo do framework, e inclusive de uma forma facilitada, no exigindo o contato direto com o OSGi Container para instalao ou remoo
de componentes por meio de linhas de comando.
3.4.3
Componente ApplicationService
De acordo com (Gamma et al., 1995), estruturar um sistema em subsistemas ajuda a

reduzir a complexidade, minimizando a dependncia entre eles. Os subsistemas se tornam mais complexos a medida que evoluem e quando aplicados padres, resultam em
um maior nmero de classes menores. Isso torna o subsistema mais reutilizvel, porm
mais difcil de utilizar.
Uma Fachada (em ingls, Facade) pode fornecer como comportamento padro uma
viso do sistema, que suficientemente boa para a maioria dos clientes (Gamma et al.,
1995). Dessa forma, o componente ApplicationService foi implementado utilizando o
padro de projeto Facade.
Como o nome do padro de projeto adotado sugere, o componente ApplicationService foi implementado de forma a funcionar como uma fachada, criando um isolamento
44
entre os clientes e os demais componentes do framework. Dessa forma, reduzido o

nmero de objetos com que os clientes precisam lidar.
O principal objetivo do componente ApplicationService externalizar as operaes
de Reconfigurao de Variabilidades e Descoberta de Servios. Estas operaes so
disponibilizadas por meio de web services, de forma que, todas as requisies recebidas
devem ser delegadas ao componente ServiceContext para que possam ser tratadas.
Este componente foi implementado utilizando o iPOJO para obt-lo na forma de
bundle OSGi e o CXF DOGSi para expor suas funcionalidades por meio de web services.
3.4.4
Decises Arquiteturais e Concluso
Esta seo apresenta uma discusso sobre as decises arquiteturais e como foi possvel
atender os Requisitos RFs e os RNFs elicitados. As decises arquiteturais basicamente
consistiram em: escolha da plataforma OSGi que iramos utilizar; escolha do modelo de
componentes que seria seguido para desenvolver os componentes da soluo proposta;
escolha da tecnologia que seria utilizada para expor os servios na forma de web services; escolha da tecnologia que seria utilizada para tratar os descritores como objetos
Java; e por fim, qual seriam os critrios utilizados na operao de descoberta de servios.
Um dos principais objetivos desse trabalho efetuar um estudo sobre variabilidades
dinmicas em LPSOSSC e, como resultado, foi desenvolvido o DYMOS, que um
framework cujo princpio suportar esse tipo de variabilidade nessa categoria de LPS.
O desenvolvido do DYMOS foi baseado em tecnologias OSGi, que consiste em um
conjunto de especificaes para desenvolvimento de software Java na forma de mdulos
(bundles). O OSGi oferece benefcios como reduo na complexidade dos componentes,
permite o reuso, atualizaes e adaptaes dinmicas, e por esses motivos foi adotado
como plataforma de execuo.
Abaixo sero descritas com mais detalhes as principais decises arquiteturais que
permitiram projetar e implementar o DYMOS:
Plataforma OSGi Por se tratar de um conjunto de especificaes, o OSGi possui diversas distribuies que so mantidas por diversas organizaes. Dentre essas
distribuies, possvel citar as mais conhecidas: o Equinox, que mantido pela
Eclipse Foundation; o Knoplerfish, que mantido pela Makewave (Gatespace Telematics); o Felix, que mantido pela comunidade e distribudo sob a licena
Apache.
A distribuio adotada como plataforma de execuo do framework foi o Apa-
45
che Felix. Esta distribuio possui uma documentao de acesso fcil, que inclui
documentao online, fruns, grupos de discusso e tutoriais. Esses fatores influenciaram positivamente na escolha da ferramenta pois facilitou consideravelmente
o aprendizado, agilizando a sua utilizao.s
Modelo de Componentes Os modelos de componentes consistem em especificaes
que foram seguidas para permitir o desenvolvimento dos componentes OSGi. Atualmente, os principais modelos de componentes so o BluePrint, Declarative Services e o iPOJO.
Dentre estas opes, foi adotado o iPOJO como modelo de componente pois ele
possui caractersticas que no so suportadas pelos demais modelos. Dentre as
caractersticas, podemos citar a possibilidade de utilizar Java Annotations para
efetuar a configurao dos servios, o suporte a composio de servios e controle
do seu ciclo de vida. Estes fatores contriburam para a escolha do iPOJO pois
este se mostrou um modelo de componente que permite o desenvolvimento dos
componentes de uma forma mais rpida e simples.
Expor Servios como Web Services Para expor Servios como Web Services, foi adotado o CXF DOSGi. Esse framework foi adotado por ser compatvel com o iPOJO
e pelo fcil acesso a documentao por meio de material online, fruns e grupos de
discusso. Alm disso, outro fator que contribuiu para a adoo desse framework
foi o suporte oferecido ao uso de servios de uma forma distribuda, ou seja, que
esto em execuo em diferentes instncias da plataforma OSGi.
Tratar informaes descritas em XML As informaes sobre os Servios e Variabilidades so descritas na forma de XML. Ento, como uma forma de atender o requisito no-funcional RNF1 e facilitar o gerenciamento das informaes durante a
execuo das operaes, as informaes precisam ser convertidas em objetos Java.
Inicialmente foi adotado o XStream3 , que consiste em um conjunto de bibliotecas
para converter objetos Java em XML e vice-versa. No entanto, existiram alguns
problemas de compatibilidade entre as bibliotecas pois ainda no existia uma verso compatvel com OSGi. Por esse motivo, foi decidido adotar o JAXB, que
consiste em um conjunto de bibliotecas que so providas por meio do Java que
possuem compatibilidade com a tecnologia OSGi. O JAXB possibilitou a gerao dos metamodelos de Servios e Variabilidades a partir de estruturas definidas
3 http://xstream.codehaus.org/
46
utilizando notaes XSD.

Critrios de Seleo de Servios Diversas abordagens se baseiam em requisitos nofuncionais para efetuar uma seleo de servio e um fator que pode influenciar tal
seleo a qualidade do servio, que pode ser medida por meio de mtricas como
confiabilidade, tempo de resposta e reputao (Yu and Reiff-Marganiec, 2008).
Como critrios de seleo de servio, foram definidos dois critrios, onde o primeiro consiste na verificao de disponibilidade do servio e o segundo, consiste
na seleo de servios com base na preferncia do usurio, por meio de uma prioridade definida no DS. Estes critrios foram definidos com o objetivo de ser
simples, enquanto permite uma configurao mais flexvel.
Por fim, apresentado por meio da Tabela 3.1 a relao entre Componentes, Requisitos Funcionais e Requisitos No-Funcionais. possvel visualizar na Tabela 3.1 quais
os requisitos so atendidos por cada componente e, inclusive, quais so os componentes
que esto envolvidos na resoluo de cada requisito.
Requisitos Funcionais (RF) e Requisitos No-funcionais (RNF)
Componentes
RF1 RF2 RF3 RF4 RF5 RF6 RF7 RF8 RF9 RNF1 RNF2
ApplicationService
ServiceDescriptor
VariabilityDescriptor
WSResolver
HotBuildContext
ServiceContext
Tabela 3.1 Relao entre Componentes, Requisitos Funcionais e Requisitos No-Funcionais
Ser apresentada no prximo captulo (Captulo 4), uma avaliao preliminar que
demonstra a aplicao da abordagem proposta neste trabalho.
47
4
Uma Avaliao Preliminar
Quem nunca cometeu um erro nunca tentou algo novo.

A person who never made a mistake never tried anything new.
ALBERT EINSTEIN
apresentado neste captulo uma avaliao preliminar que demonstra a aplicao da

abordagem proposta neste trabalho. A abordagem proposta consiste em prover suporte
a variabilidades dinmicas em LPSOSSC por meio do DYMOS Framework. A avaliao
foi executada em dois produtos derivados da MobiLine, que uma LPS aninhada cujo
domnio de aplicaes mveis e sensveis ao contexto (Marinho et al., 2012). So
apresentados mais detalhes sobre a MobiLine na Seo 4.1.
Neste estudo foram utilizados dois produtos provenientes do nvel especfico da
MobiLine. Um dos produtos o GREat Tour, que trata-se de um Guia de Visitas Mvel
e Sensvel ao Contexto, utilizado no Departamento de Cincias da Computao da Universidade Federal do Cear (UFC). O segundo produto o CIn Tour, que trata-se de uma
aplicao para o mesmo propsito, porm com menos funcionalidades, que utilizado
no Centro de Informtica (CIn) da Universidade Federal de Pernambuco (UFPE).
Na prxima seo ser feita uma breve apresentao sobre a MobiLine e, nas sees
consecutivas, sero detalhadas as etapas executadas nesta avaliao.
4.1
MobiLine
A MobiLine uma LPS multinvel cujo domnio o de aplicaes mveis e sensveis ao

contexto. De modo a possibilitar o desenvolvimento de aplicaes utilizando tcnicas de
LPS, preciso uma anlise prvia do domnio a fim de identificar semelhanas e diferenas entre as aplicaes (Pohl et al., 2005). Levando em considerao um domnio amplo
48
4.1. MOBILINE
e complexo como o de aplicaes mveis e sensveis ao contexto, a modelagem da LPS

pode no ser bem sucedida. Com o objetivo de tratar esta complexidade, a abordagem
adotada na MobiLine consiste em dividir a anlise de domnio em dois nveis: nvel base
e nvel especfico. Esta diviso apresentada por meio da Figura 4.1.
Figura 4.1 Abordagem utilizada na MobiLine (Marinho et al., 2012)
De acordo com a abordagem adotada, o nvel base composto por funcionalidades

mais gerais e comuns que esto presentes em aplicaes mveis e sensveis ao contexto.
As principais funcionalidades identificadas neste nvel foram ambiente de execuo
dinmica, adaptabilidade e sensibilidade ao contexto.
No nvel especfico, o escopo restrito a um domnio especfico de negcio. Um
modelo de features produzido aps efetuar uma juno das features requeridas pelo
domnio especfico de negcio com as features selecionadas no nvel base. Para demonstrar o uso da abordagem proposta, (Marinho et al., 2012) seleciona um domnio de
negcio, que o domnio de Guia de Visitas Mvel e Sensvel ao Contexto. Este Guia de
Visitas trata-se de uma aplicao, executando em um dispositivo mvel, utilizada para
49
4.2. GREAT TOUR
guiar visitantes em um ambiente desconhecido como museu, parque, ou uma cidade.
4.2
GREat Tour
O GREat Tour um Guia de Visitas Mvel e Sensvel ao Contexto criado a partir da

MobiLine. Esta aplicao foi implementada para auxiliar visitantes a conhecerem o
laboratrio de pesquisa e desenvolvimento do GREat (Grupo de Redes, Engenharia de
Software e Sistemas) da Universidade Federal do Cear.
A aplicao executada no dispositivo mvel do visitante e fornece informaes
sobre os pesquisadores e ambientes do laboratrio que so visitados. O seu comportamento se adapta de acordo com o contexto atual do visitante, que abrange a localizao
do visitante, seu perfil ou preferncias, as caractersticas do seu dispositivo mvel, e informaes a respeito de outras pessoas presentes na mesma sala em que o visitante se
encontra.
Sero apresentadas nesta seo as etapas executadas na avaliao do uso do DYMOS
para permitir variabilidades dinmicas no GREat Tour. As etapas executadas consistem
em um conjunto de anlises e definies, que sero detalhadas nas prximas sees.
4.2.1
Anlise e Definies
Como j foi mencionado, a execuo da avaliao foi efetuada com base em um conjunto
de anlises e definies. As anlises auxiliaram na identificao de o que necessita ser
efetuado para permitir variabilidades dinmicas no GREat Tour, utilizando a abordagem
proposta por meio do DYMOS. Adicionalmente, as definies permitiram determinar
como ser efetuada a avaliao.
Abaixo est destacado o conjunto de anlises efetuadas:
1. Anlise do modelo de features do produto a fim de selecionar features e pontos de
variao para serem utilizados na avaliao.
2. Anlise da implementao dos artefatos referentes s features selecionadas, a fim
de identificar as tecnologias utilizadas e verificar a compatibilidade com o OSGi.
3. Analisar os casos de incompatibilidade, definindo uma estratgia para efetuar a
migrao da implementao atual para um modelo de implementao compatvel
com OSGi.
50
4.2. GREAT TOUR
4. Anlise da implementao dos artefatos da aplicao cliente, a fim de identificar

os pontos que passaro por refatorao para que possibilite a compatibilidade com
o DYMOS.
De acordo com as anlises efetuadas, foi possvel elencar um conjunto de definies que guiaram esta avaliao, especificando como as etapas seriam executadas. Ser
descrito nas prximas sees os resultados obtidos a partir da execuo de cada anlise.
4.2.2
Analisando o Modelo de Features
Esta etapa consistiu em analisar o modelo de features do GREat Tour com a finalidade de
selecionar features e pontos de variao que seriam utilizados na avaliao da abordagem
proposta. Por meio da Figura 4.2 apresentado de forma parcial o modelo de features do
GREat Tour. A notao utilizada para desenhar tal modelo foi proposta por (Czarnecki
and Eisenecker, 2000).
Figura 4.2 GREat Tour: Modelo de Feature Parcial
No modelo apresentado por meio da Figura 4.2 possvel visualizar as features selecionadas para a avaliao. Tais features consistem em funcionalidades referentes a
51
4.2. GREAT TOUR
Segurana (Privacy), que determina se o acesso a aplicao ser concedido por meio de
Autorizao (Authorization) que, por ser uma feature opcional, no ter critrios de segurana para acesso; a Visualizao de Documentos (Show Document), que especifica o
tipo de mdia que estar disponvel para visualizao, que pode ser Texto (Text), Imagem
(Image) ou Vdeo (Video); o vdeo como um tipo de mdia tambm considerado uma
feature, que pode possuir um provedor local ou externo.
Dessa forma, de acordo com as features selecionadas, possvel sumarizar os pontos de variao, que consistem em Modo de Acesso, Tipo de Mdia disponvel para
Visualizao e Provedor de Stream de Vdeo.
Na prxima seo ser descrita a anlise efetuada sobre a implementao dos artefatos referentes s features selecionadas.
4.2.3
Analisando os Artefatos
Nesta etapa, foi efetuada uma anlise na implementao dos artefatos referentes s features selecionadas. O objetivo desta anlise identificar os artefatos, suas implementaes,
as tecnologias utilizadas e, por fim, verificar a compatibilidade com o OSGi.
De forma a possibilitar esta anlise, inicialmente foi necessrio efetuar a identificao dos artefatos. Isto foi possvel por meio de uma inspeo no-sistemtica nas implementaes da aplicao, de uma forma abrangente, buscando nestas implementaes
a funcionalidades ligadas s features.
Como resultado desta anlise, foi possvel visualizar a relao entre features, artefatos e implementaes, que apresentada por meio da Tabela 4.1.
Features
Artefatos
Privacy
LoginService
Show Document TextService, ImageService, VideoService

Video
LocalVideoProviderService, ExternalVideoProviderService
Tabela 4.1 Relao entre Features e Artefatos
Adicionalmente, por meio de uma anlise nas implementaes dos artefatos, foi possvel observar que suas funes so disponibilizadas na forma de Servios Web. utilizado o Java como linguagem de programao, Apache Axis1 como framework para
construo de web services e o Apache Tomcat2 como servidor web.
1 http://axis.apache.org/axis/
2 http://tomcat.apache.org/
52
4.2. GREAT TOUR
Por fim, conclumos que as implementaes no possuem compatibilidade com OSGi

pois no esto implementados na forma de bundles. Dessa forma, para permitir a reconfigurao dinmica das features por meio do DYMOS, necessrio que as implementaes dos artefatos relacionados a estas features sejam portadas para o modelo de
componentes OSGi, mantendo suas funcionalidades externalizadas por meio de Servios
Web.
Ser apresentado na prxima seo a estratgia adotada nesta atividade.
4.2.4
Modularizando Servios
De acordo com a anlise efetuada na etapa anterior, foi observado que os artefatos LoginService, TextService, ImageService, VideoService (LocalVideoProviderService e ExternalVideoProviderService) no possuem implementaes compatveis com OSGi, ou
seja, no possvel efetuar a implantao desses servios em um container OSGi.
Nesta etapa foram analisados estes casos de incompatibilidade, em seguida, foi definida uma estratgia para efetuar a portabilidade da implementao atual para um modelo
de implementao compatvel com OSGi. A estratgia utilizada para efetuar a portabilidade consiste em separar Interfaces (API) e Implementaes, de modo que sejam empacotadas em bundles diferentes. Esta estratgia considerada uma boa prtica (best
practice) e prov uma maior flexibilidade a aplicao (Hall et al., 2011; de Castro Alves, 2011). Para efetuar a gerao dos artefatos em arquivos JAR, foi utilizado o Apache
Maven3 3.0.4 com o plugin maven-bundle-plugin4 , que permitiu a configurao dos
metadados do artefato de uma forma simples.
A anlise efetuada sobre estas implementaes permitiu identificar os principais mtodos utilizados para prover uma determinada funcionalidade, determinar quais so os
mtodos que iro compor a API do servio e verificar a existncia de interao desses
artefatos com componentes que no tm compatibilidade com OSGi. Como parte dos
resultados obtidos por meio desta anlise, percebeu-se que todos os servios utilizam
acesso a banco de dados para prover suas funcionalidades, tornando necessrio a implementao de um componente OSGi capaz de prover este tipo de acesso aos servios que
sero migrados, conforme apresentado na Figura 4.3.
3 http://maven.apache.org/
4 http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
53
4.2. GREAT TOUR
Figura 4.3 MySQLServiceProvider: Dependncia entre o Servio Provedor de Conexes e os

demais Servios Modularizados
O banco de dados utilizado o MySQL5 5.6, o acesso feito por meio de JDBC
(Java Database Connectivity) com o driver verso 5.1.
Ser apresentado na prxima seo detalhes sobre a implementao do componente
responsvel por prover acesso ao banco de dados.
MySQLServiceProvider
definido por meio do OSGi Service Platform Release 4 um conjunto de especificaes
que permite a criao de conexes a banco de dados utilizando JDBC. Estas especificaes esto contidas na API DataSourceFactory6 e definem mtodos para criao de trs
tipos de conexo: DataSource, ConnectionPoolDataSource e XADataSource.
No componente MySQLServiceProvider, foi implementado apenas a criao de conexes do tipo DataSource pois as operaes efetuadas nas implementaes atuais do
artefatos no necessitam de suporte a pool de conexes ou transaes. Para isso, foi
criada a classe MySQLDataSourceFactory que prov uma implementao que segue a
especificao de DataSourceFactory, conforme apresentado na Figura 4.4.
5 http://www.mysql.com/
6 http://www.osgi.org/javadoc/r4v42/org/osgi/service/jdbc/DataSourceFactory.html
54
4.2. GREAT TOUR
Figura 4.4 MySQLDataSourceFactory: Fbrica de conexes MySQL utilizando JDBC
Conforme apresentado na Figura 4.4, o mtodo responsvel pela criao de objetos

DataSource o createDataSource. Este mtodo recebe como parmetro um objeto do
tipo Properties contendo as propriedades necessrias para configurar e estabelecer uma
conexo com o banco de dados. As propriedades so acessadas e utilizadas na criao
do objeto DataSource e, em seguida, o objeto criado retornado.
Em OSGi, uma aplicao pode ser composta por diferentes componentes, ento necessrio estabelecer uma forma de inicializar e finalizar a execuo de cada componente
individualmente. Nesta avaliao, foi utilizado o iPOJO na modularizao dos componentes, que responsvel por gerenciar o ciclo de vida do componente. apresentado
por meio da Figura 4.5, as configuraes do componente MySQLServiceProvider e sua
instncia.
55
4.2. GREAT TOUR
Figura 4.5 MySQLDataSourceFactory: Configurao iPOJO do Componente e sua Instncia
Conforme possvel observar na Figura 4.5, a configurao do MySQLDataSourceFactory como um componente iPOJO, consiste na definio das tags component
e instance. A descrio da tag component efetuada indicando o nome do componente por meio do atributo name e a classe que prov a sua implementao por
meio do atributo classname. A descrio da tag instance permite a configurao
da instncia do componente, indicando as propriedades e valores necessrios para a sua
instanciao.
Sero apresentados na prxima seo detalhes sobre a modularizao do servio
referente ao artefato de Privacidade (Privacy).
LoginService
Conforme j mencionado anteriormente, a estratgia utilizada na modularizao dos
servios considerada uma boa prtica, que consiste em separar Interfaces (API) e Implementaes, de modo que sejam empacotadas em bundles diferentes. Como parte do
resultado da anlise das implementaes, foram identificados os principais mtodos utilizados para prover a funo de autenticao na aplicao. Isso permitiu determinar os
mtodos que iro compor a API do componente LoginService, e que ir direcionar a sua
implementao. apresentado por meio da Figura 4.6 a especificao do componente
LoginService.
56
4.2. GREAT TOUR
Figura 4.6 LoginService: Especificao
Conforme apresentado na Figura 4.6, a especificao do componente recebe a anotao @WebService, indicando que suas funcionalidades estaro disponveis na forma
de servios web. O principal mtodo identificado para prover a funcionalidade de autenticao foi o auth, que recebe como parmetro o login e o password do usurio.
apresentado por meio da Figura 4.7 a configurao parcial do arquivo POM (Project
Object Model), que utilizado pelo Apache Maven para gerenciar as dependncias entre
artefatos e efetuar a gerao dos bundles.
Figura 4.7 LoginService: Configurao parcial do arquivo POM
A configurao do componente (bundle) efetuada no arquivo POM, apresentado

na Figura 4.7. O tipo de empacotamento do artefato definido por meio da tag packaging, que por se tratar de um componente OSGi, foi definido como bundle. Os
57
4.2. GREAT TOUR
atributos groupId e artifactId so utilizados para determinar a identidade do artefato,

juntamente com a sua verso (version). Por meio do plugin maven-bundle-plugin
feita a configurao dos metadados do bundle, indicando um valor para o atributo SymbolicName e o pacote exportado. Essas configuraes permitem o empacotamento do
bundle que contm a especificao do componente LoginService.
LoginServiceProvider
Aps a definio da especificao do componente LoginService, necessrio prover
uma implementao que possibilite determinar um comportamento para cada funo.
apresentado por meio da Figura 4.8, um resultado parcial da migrao da implementao
atual do artefato de Autenticao para o modelo de componente OSGi. A implementao
do componente LoginServiceProvider obedece as mesmas regras e utiliza as mesmas
bibliotecas, em conjunto com o DataSourceFactory.
Figura 4.8 LoginServiceProvider: Uma implementao para o LoginService
58
4.2. GREAT TOUR
Conforme apresentado na Figura 4.8, foram atribudas implementao as anotaes @Component, que define que a implementao corresponde a um tipo de componente; @Provides, que indica que o componente responsvel por prover um servio; e @WebService, que indica que o componente deve estar disponvel na forma
de servio web. O atributo dsf do tipo DataSourceFactory, que corresponde a uma fbrica de conexes do tipo DataSource, recebeu a anotao @Requires. Esta anotao
determina uma dependncia entre os servios e permite que o framework efetue a injeo desta dependncia, de acordo com o servio disponvel no contexto OSGi. O servio
que dever ser injetado nesta dependncia o MySQLServiceProvider, que prov uma
implementao para esta fbrica de conexes.
Conforme mencionado anteriormente, o principal mtodo identificado para prover
a funcionalidade de autenticao foi o auth, que recebe como parmetro o login e
o password do usurio e responsvel por verificar a sua autenticidade. Para permitir
essa verificao, efetuada uma consulta no banco de dados por meio de uma conexo
obtida com o mtodo openConn(). A verificao efetuada e em seguida retornado
um valor do tipo boolean, com true caso a autenticao seja validada ou false caso
contrrio. Por fim, a conexo finalizada por meio do mtodo closeConn().
Os detalhes sobre os mtodos openConn() e closeConn() so apresentados por
meio da Figura 4.9. Para estabelecer uma conexo com o banco de dados, por meio do
mtodo openConn() foram atribudos valores para propriedades que so utilizadas para
criar a conexo, como DataSourceFactory.JDBC_URL, DataSourceFactory.JDBC_USER
e DataSourceFactory.JDBC_PASSWORD. Por meio do atributo dsf, acessado o mtodo createDataSource passando as propridades como parmetro. Com isso, obtido
um objeto DataSource e, a partir deste, uma conexo estabelecida e atribuda ao atributo connection para que possa ser utilizado pelo mtodo auth, na operao de
autenticao. O mtodo closeConn() utilizado para finalizar a conexo.
59
4.2. GREAT TOUR
Figura 4.9 LoginServiceProvider: Mtodos para estabelecer e finalizar uma conexo com o
banco de dados
apresentado por meio da Figura 4.10 as informaes utilizadas na configurao

da instncia do servio, que ser publicado como um Servio Web. A configurao
efetuada por meio da definio de propriedades, atribuio nome e valores para cada
uma.
Figura 4.10 LoginServiceProvider: Configurao de Instncia
Conforme a Figura 4.10, as propriedades definidas so:

service.exported.interfaces denota as interfaces Java que devem estar disponveis
remotamente. O valor * foi atribudo a esta propriedade para indicar que todas
as interfaces registradas no contexto OSGi estaro disponveis.
service.exported.configs especifica o mecanismo utilizado para disponibilizar o servio. O valor org.apache.cxf.ws foi atribudo a esta propriedade para indicar
que o servio deve ser disponibilizado na forma de Servio Web.
60
4.2. GREAT TOUR
org.apache.cxf.ws.address especifica o endereo em que o servio deve estar disponvel. O valor http://0.0.0.0:9090/loginService foi atribudo a esta propriedade,
indicando o endereo do servio. O valor 0.0.0.0 do endereo determina que o
servio estar acessvel atravs de todas as interfaces de rede, o valor 9090 indica a porta onde o servio est em execuo e loginService representa o nome
de acesso do servio.
O iPOJO efetua a criao da instncia e o Apache CXF utiliza as informaes atribudas na configurao para efetuar a publicao do Servio Web. Por fim, de acordo
com a Figura 4.11, efetuado a configurao do arquivo POM de modo a permitir o
gerenciamento das dependncias do componente e a gerao do bundle referente ao LoginServiceProvider.
Figura 4.11 LoginServiceProvider: Configurao parcial do arquivo POM
Conforme apresentado na Figura 4.11, o artefato ser empacotado como um bundle
61
4.2. GREAT TOUR
OSGi, assim como ocorreu com o componente LoginService. Por meio da tag dependency estabelecida uma dependncia com o artefato LoginService, indicando o groupId, artifactId e version do componente. A dependncia entre os artefatos estabelecida
pois o componente LoginServiceProvider prov uma implementao para o componente
LoginService.
Por meio do plugin maven-bundle-plugin feita a configurao dos metadados
do bundle, indicando um valor para o atributo SymbolicName e, por meio do atributo
Private-Package determinada a remoo da visibilidade do pacote onde est localizada a implementao do servio. Essas configuraes permitem o empacotamento do
bundle referente ao componente LoginServiceProvider, que contm a implementao do
componente LoginService.
A migrao dos demais artefatos descritos na Seo 4.2.3 para o modelo de componentes OSGi seguiu a mesma estratgia utilizada na implementao dos componentes
LoginService e LoginServiceProvider. As implementaes referentes a estes artefatos
esto disponveis em https://github.com/dhiegoabrantes/dymos-evaluation-ws.
4.2.5
Descrevendo Servios e Variabilidades
Nesta etapa foi efetuada a descrio dos servios e variabilidades que compem a configurao do GREat Tour. A descrio destes elementos permite o gerenciamento dos
servios de modo a suportar variabilidades dinmicas, efetuando reconfiguraes em
tempo de execuo, de acordo com mudanas no ambiente. apresentada na Figura
4.12 a descrio dos servios que compem a configurao do produto.
62
4.2. GREAT TOUR
<services>
<service id="loginService"
service-impl="br.ufpe.cin.assertlab.dymos.ws.impl.LoginServiceImpl">
<service-spec>br.ufpe.cin.assertlab.dymos.ws.LoginService</service-spec>
</service>
<service id="textService"
service-impl="br.ufpe.cin.assertlab.dymos.ws.impl.TextServiceImpl">
<service-spec>br.ufpe.cin.assertlab.dymos.ws.TextService</service-spec>
</service>
<service id="imageService"
service-impl="br.ufpe.cin.assertlab.dymos.ws.impl.ImageServiceImpl">
<service-spec>br.ufpe.cin.assertlab.dymos.ws.ImageService</service-spec>
</service>
<service id="localVideoService"
service-impl="br.ufpe.cin.assertlab.dymos.ws.impl.LocalVideoProviderServiceImpl">
<service-spec>br.ufpe.cin.assertlab.dymos.ws.VideoService</service-spec>
</service>
<service id="externalVideoService"
service-impl="br.ufpe.cin.assertlab.dymos.ws.impl.ExternalVideoProviderServiceImpl">
<service-spec>br.ufpe.cin.assertlab.dymos.ws.VideoService</service-spec>
<alternative-service ref="localVideoService" priority="1" />
</service>
</services>
Figura 4.12 GREat Tour: Descritor de Servios
Conforme a Figura 4.12, os servios descritos so relacionados aos artefatos identificados a partir da anlise do modelo de features do GREat Tour. De acordo com a
mesma figura, o DS composto por loginService, que possui a especificao definida
por meio da interface LoginService e a implementao provida pela classe LoginServiceImpl; textService, que possui a especificao definida por meio da interface TextService e a implementao provida pela classe TextServiceImpl; imageService, que
possui a especificao definida por meio da interface ImageService e a implementao
provida pela classe ImageServiceImpl; localVideoService, que possui a especificao definida por meio da interface VideoService e a implementao provida pela classe
LocalVideoProviderServiceImpl; e, por fim, o externalVideoService, que tambm
possui a especificao definida por meio da interface VideoService e a implementao
provida pela classe ExternalVideoProviderServiceImpl. atribudo ao servio externalVideoService o localVideoService como servio alternativo. Com isso, quando
houver uma requisio pelo servio externalVideoService e houver indisponibilidade,
63
4.2. GREAT TOUR
o servio localVideoService deve ser selecionado.

apresentado por meio da Figura 4.13, a descrio das variabilidades presentes na
configurao do GREat Tour. As variabilidades esto descritas de acordo com as features
do produto e seus pontos de variao, que foram sumarizados por meio da anlise do
modelo de features, descrita na Seo 4.2.2. De acordo com esta anlise, os pontos de
variao sumarizados consistem em Modo de Acesso, Tipo de Mdia disponvel para
Visualizao e Provedor de Stream de Vdeo.
<variabilities>
<variability id="privacy">
<variant id="authentication">
<service-ref ref="loginService" />
</variant>
</variability>
<variability id="showDocument">
<variant id="textMedia">
<service-ref ref="textService" />
</variant>
<variant id="imageMedia">
<service-ref ref="imageService" />
</variant>
</variability>
<variability id="video">
<variant id="localVideo">
<service-ref ref="localVideoService" />
</variant>
<variant id="externalVideo">
<service-ref ref="externalVideoService" />
</variant>
</variability>
</variabilities>
Figura 4.13 GREat Tour: Descritor de Variabilidades
Os pontos de variao so descritos por meio da tag variability, que recebeu como
ID o nome da feature respectiva. Cada um dos pontos de variao so associados a
variantes, que so descritas por meio da tag variant.
Conforme a Figura 4.13, foram descritos os pontos de variao privacy, que
est relacionado a feature Privacy, definindo authentication como uma variante;
showDocument, que est relacionado a feature Show Document, definindo textMedia e imageMedia como variantes.
De acordo com o modelo de features, o ponto de variao showDocument recebe-
64
4.3. CIN TOUR
ria uma terceira variante, que seria o provedor de stream de vdeo. No entanto, como esta
variante pode ser alternada entre um provedor local ou externo, foi decidido a decompor em um novo ponto de variao, o video, que est relacionado a feature Video,
definindo localVideo e externalVideo como variantes;
Na Seo 4.4 ser detalhado a anlise e adequao da aplicao para notificar o
DYMOS sobre mudanas no ambiente e utilizar a funo de descoberta de servios.
Posteriormente, na Seo 4.5 ser feita uma discusso sobre os resultados obtidos por
meio desta avaliao.
4.3
CIn Tour
O CIn Tour um Guia de Visitas Mvel e Sensvel ao Contexto criado a partir da MobiLine, assim como o GREat Tour. Esta aplicao foi implementada para auxiliar visitantes a conhecer o CIn (Centro de Informtica) da Universidade Federal de Pernambuco.
A aplicao executada no dispositivo mvel do visitante e fornece informaes
sobre os pesquisadores e ambientes do laboratrio que so visitados. O seu comportamento se adapta de acordo com o contexto atual do visitante, que abrange a localizao
do visitante, seu perfil ou preferncias, as caractersticas do seu dispositivo mvel, e informaes a respeito de outras pessoas presentes na mesma sala em que o visitante se
encontra.
Ser apresentado nesta seo as etapas executadas na avaliao do uso do DYMOS
para permitir variabilidades dinmicas no CIn Tour. Como o CIn Tour e o GREat Tour
so derivados da mesma LPS, possvel ambos possuam features em comum. Dessa
forma, esperado como resultado desta avaliao a possibilidade de reuso dos artefatos
migrados para o GREat Tour, necessitando apenas o ajuste dos Descritores de Servios
e Variabilidades, de acordo com a configurao do CIn Tour.
As etapas executadas sero detalhadas nas prximas sees.
4.3.1
Analisando o Modelo de Features
Esta etapa consistiu em analisar o modelo de features do CIn Tour com a finalidade de
identificar features e pontos de variao em comum com o modelo de features do GREat
Tour. De acordo com esta anlise foi possvel perceber a ausncia de algumas features
que esto presentes no GREat Tour como Privacy e Video, evidenciando que o CIn
Tour possui um nmero menor de features, o que a torna uma aplicao de menor porte.
65
4.3. CIN TOUR
Por meio da Figura 4.14 apresentado de forma parcial o modelo de features do CIn
Tour, de acordo com as features identificadas.
Figura 4.14 CIn Tour: Modelo de Feature Parcial
No modelo apresentado por meio da Figura 4.14 possvel visualizar as features em

comum, que consistem em funcionalidades referentes a Visualizao de Documentos
(Show Document), que especifica o tipo de mdia que estar disponvel para visualizao,
que pode ser Texto (Text) ou Imagem (Image).
Dessa forma, de acordo com estas features, possvel sumarizar um nico ponto de
variao, que consiste no Tipo de Mdia disponvel para Visualizao.
Na prxima seo sero apresentadas as descries dos servios e variabilidades do
CIn Tour, de acordo com os artefatos reutilizados do GREat Tour.
66
4.3. CIN TOUR
4.3.2
Descrevendo Servios e Variabilidades
Nesta etapa foi efetuada a descrio dos servios e variabilidades que compem a configurao do CIn Tour. A descrio destes elementos permite o gerenciamento dos servios de modo a suportar variabilidades dinmicas, efetuando reconfiguraes em tempo
de execuo, de acordo com mudanas no ambiente. apresentado na Figura 4.15 a
descrio dos servios que compem a configurao do produto.
<services>
<service id="textService"
service-impl="br.ufpe.cin.assertlab.dymos.ws.impl.TextServiceImpl">
<service-spec>br.ufpe.cin.assertlab.dymos.ws.TextService</service-spec>
</service>
<service id="imageService"
service-impl="br.ufpe.cin.assertlab.dymos.ws.impl.ImageServiceImpl">
<service-spec>br.ufpe.cin.assertlab.dymos.ws.ImageService</service-spec>
</service>
</services>
Figura 4.15 CIn Tour: Descritor de Servios
Conforme a Figura 4.15, os servios descritos so relacionados aos artefatos ligados s features identificadas a partir da anlise do modelo de features do CIn Tour. De
acordo com a mesma figura, o DS composto por textService, que possui a especificao definida por meio da interface TextService e a implementao provida pela classe
TextServiceImpl; e imageService, que possui a especificao definida por meio da
interface ImageService e a implementao provida pela classe ImageServiceImpl;
apresentado por meio da Figura 4.13, a descrio das variabilidades presentes na
configurao do CIn Tour. As variabilidades esto descritas de acordo com as features
do produto e seus pontos de variao, que foram sumarizados por meio da anlise do
modelo de features, descrita na Seo 4.3.1. De acordo com esta anlise, foi possvel
sumarizar apenas um ponto de variao que consiste em Tipo de Mdia disponvel para
Visualizao.
67
4.4. ANALISANDO E INTEGRANDO A APLICAO CLIENTE
<variabilities>
<variability id="showDocument">
<variant id="textMedia">
<service-ref ref="textService" />
</variant>
<variant id="imageMedia">
<service-ref ref="imageService" />
</variant>
</variability>
</variabilities>
Figura 4.16 CIn Tour: Descritor de Variabilidades
Conforme a Figura 4.13, foi descrito o ponto de variao showDocument, que est
relacionado a feature Show Document, definindo textMedia e imageMedia como
variantes;
Na Seo 4.4 ser detalhado a anlise e adequao da aplicao para notificar o
DYMOS sobre mudanas no ambiente e utilizar a funo de descoberta de servios.
Posteriormente, na Seo 4.5 ser feita uma discusso sobre os resultados obtidos por
meio desta avaliao.
4.4
Analisando e Integrando a Aplicao Cliente
Ser descrito nesta seo as etapas executadas para permitir a integrao das aplicaes cliente, GREat Tour e CIn Tour, com o DYMOS, a fim de utilizar as principais
funcionalidades providas, que consiste na reconfigurao de variabilidades dinmicas e
descoberta de servios. Para permitir a integrao entre a aplicao e o DYMOS, foi
desenvolvida uma biblioteca Java, denominada DymosClientLib, que prov a possibilidade da aplicao cliente utilizar as funes providas pelo DYMOS.
A biblioteca desenvolvida considerada leve por ser composta basicamente por classes como VariabilityContext, que permite o suporte a reconfigurao de variabilidades
dinmicas e o ServiceEndpointFactory, que permite o suporte a descoberta de servios. A utilizao desta biblioteca permite a integrao entre a aplicao cliente e o DYMOS. Para efetuar a integrao, foi necessrio analisar as implementaes da aplicao
de modo a determinar como a adequao seria possibilitada.
Inicialmente foi analisado a forma como ocorria a interao entre a aplicao cliente e os servios. Como resultado desta anlise, observou-se que a aplicao utiliza a
plataforma Android e que para cada servio utilizado existe uma classe correspondente.
68
4.4. ANALISANDO E INTEGRANDO A APLICAO CLIENTE
Por exemplo, a interao com o servio de autenticao do usurio intermediada pela

classe LoginWS. Tambm foi possvel observar a utilizao da biblioteca kSOAP7
para estabelecer a comunicao entre aplicao e servio. Dessa forma, a classe LoginWS recebe requisies por meio de seus mtodos e, utilizando o kSOAP, estabelece
uma comunicao com o servio a fim de obter uma resposta para a requisio recebida.
Conforme possvel observar no item 1 da Figura 4.17, so declarados os atributos
referentes ao servio. Estes atributos so utilizados para estabelecer uma comunicao
com o servio e, de acordo com a figura, so definidos de uma forma fixa, por meio de
constantes. demonstrado no item 2 desta mesma figura, a utilizao destes atributos
na criao de instncias de objetos da biblioteca kSOAP.
Figura 4.17 Aplicao Cliente: Declarao de constantes e Interao com Servio
Conforme descrito na Seo 3.4.2, quando executada uma operao de descoberta

de servio, obtido como resposta um valor que corresponde a uma referncia para o servio solicitado e que obedece o seguinte formato serviceEndpoint;targetNamespace;serviceName.
De modo a facilitar a manipulao das informaes sobre a referncia do servio, o valor
obtido como resposta encapsulado em um objeto. Este objeto modelado pela classe
ServiceEndpoint presente na DymosClientLib e possui os atributos endpoint,
namespace e serviceName.
A integrao com o DYMOS de modo a utilizar a funcionalidade de descoberta de
servios foi possibilitada por meio da substituio das constantes declaradas na Figura
4.17 pela declarao do atributo endpoint do tipo ServiceEndpoint, conforme o
item 1 da Figura 4.18. De acordo com o item 2, a referncia para o servio atu7 https://code.google.com/p/ksoap2-android/
69
4.5. CONSIDERAES FINAIS
alizada antes de cada execuo, utilizando o mtodo getEndpoint da classe ServiceEndpointFactory, informando o ID do servio requerido. Posteriormente, as informaes so utilizadas para estabelecer uma comunicao com o servio e executar uma
determinada operao.
Figura 4.18 Aplicao Cliente: Descoberta de Servio por meio da biblioteca DymosClientLib
A integrao com o DYMOS de modo a utilizar a funcionalidade de reconfigurao

de variabilidades foi possibilitada por meio dos mtodos activate e deactivate da
classe VariabilityContext, informando o ID da variante afetada. apresentado por
meio da Figura 4.19 um exemplo de utilizao destes mtodos, efetuando um reconfigurao de variabilidades por meio da ativao e desativao de features.
Figura 4.19 Aplicao Cliente: Reconfigurao de variabilidades por meio da biblioteca DymosClientLib
A utilizao destes mtodos foram inseridas em pontos de adaptao das aplicaes

GREat Tour e CIn Tour.
4.5
Consideraes Finais
Foi apresentado neste captulo uma avaliao preliminar que demonstra a aplicao da
abordagem proposta neste trabalho em dois produtos derivados de uma mesma LPS,
70
4.5. CONSIDERAES FINAIS
o GREat Tour e o CIn Tour, de modo a permitir a reconfigurao de variabilidades

dinmicas nestes produtos. Adicionalmente, foram demonstradas as etapas e definies
iniciais que guiaram a execuo desta avaliao.
Os produtos utilizados nesta avaliao implementavam uma arquitetura de LPS que
no possuia suporte a tecnologia OSGi. Dessa forma, foi necessrio um esforo inicial para efetuar a modularizao das implementaes, executando a portabilidade dos
servios para um modelo de implementao compatvel com OSGi.
Foi possvel perceber a viabilidade na utilizao da abordagem proposta para permitir reconfigurao de variabilidades dinmicas, por meio de operaes de Reconfigurao e Descoberta de Servios. Adicionalmente, conclui-se que os servios modularizados podem ser reutilizados por outros produtos da mesma LPS, facilitando a adoo
desta abordagem para outros produtos e proporcionando ganhos em custo e tempo de
entrega.
Sero apresentadas no prximo captulo as consideraes finais deste trabalho, destacando as principais contribuies e trabalhos futuros.
71
5
Concluso
Um passo frente e voc no est mais no mesmo lugar
One step forward and you are not in the same place
CHICO SCIENCE (Um Passeio No Mundo Livre, Afrociberdelia)
O paradigma de Linhas de Produto de Software Dinmicas envolve aspectos sobre

o desenvolvimento de Sistemas Sensveis ao Contexto utilizando abordagens de Linhas
de Produto de Software. A gerncia de variabilidades dinmicas um desafio que est
endereado ao paradigma de Linhas de Produto de Software Dinmicas e diversas abordagens so propostas e contribuem para a evoluo deste paradigma.
Neste trabalho foram investigadas situaes em que h reconfigurao de features
que esto na aplicao cliente e que, para prover suas funcionalidades, utilizam servios. Dessa forma, foi proposta uma soluo para prover, de uma forma desacoplada e
independente, uma plataforma de reconfigurao de variabilidades dinmicas e descoberta de servios para Linhas de Produto de Software Orientado a Servios e Sensvel ao
Contexto.
5.1
Contribuies
Como resultado deste trabalho, possvel destacar como principais contribuies:

DYMOS Framework: Por meio do DYMOS Framework, foi possvel prover, de
uma forma desacoplada, uma plataforma de reconfigurao de variabilidades dinmicas e descoberta de servios para Linhas de Produto de Software Orientado
a Servios e Sensvel ao Contexto. Por meio da utilizao do framework, possvel obter vantagens como Gerncia de Variabilidade de uma forma leve e simples;
72
5.2. TRABALHOS FUTUROS
Mecanismo de Descoberta de Servio, que permite agregar critrios para a seleo do servio mais adequado, de acordo com uma requisio; Funcionalidades
Interoperveis por meio de Servios Web.
Avaliao Preliminar: A execuo da Avaliao Preliminar nos permitiu averiguar a utilidade e efetividade da soluo proposta neste trabalho. Como parte
da avaliao, foi necessrio analisar implementaes de servios legados e, em
seguida, modelar e implementar estes servios seguindo o modelo de implementao OSGi. Os Sistemas derivados da LPS MobiLine, GREat Tour e CIn Tour,
foram adaptados para utilizar o DYMOS Framework e, com isso, alm de continuar tratando reconfiguraes comportamentais, tambm passaram a tratar reconfiguraes de componentes.
5.2
Trabalhos Futuros
Algumas limitaes de abordagens atuais so endereadas neste trabalho, no entanto,

novas questes surgiram durante o tratamento destas limitaes. Ento, tais questes
devem ser tratadas como trabalhos a serem executados no futuro:
O Apache CXF, por meio do OSGi Distribudo, permite a importao e utilizao
de um servio que est publicado e em execuo em container OSGi diferentes.
Com isso, pretendemos avaliar o uso do DYMOS Framework na reconfigurao
de variabilidades dinmicas que endeream servios distribudos.
Atualmente, DYMOS Framework permite a descoberta de servios, que utiliza
como critrio de seleo a disponibilidade do servio com base em uma prioridade
definida pelo usurio. Planeja-se investigar a modularizao da funcionalidade de
Descoberta de Servios em um novo componente, de modo que possibilite a implementao de componentes responsveis por selecionar um servio de acordo
com o seu prprio critrio. Isto ir permitir a troca de componentes de descoberta de servios em tempo de execuo, possibilitando prover novos critrios de
seleo sem afetar a execuo da aplicao.
Pretende-se desenvolver um componente de descoberta e seleo de servios com
base em atributos de qualidade. Este componente ser utilizado para avaliar o item
descrito anteriormente.
73
Referncias
Alferez, G. and Pelechano, V. (2011). Context-aware autonomous web services in software product lines. In Software Product Line Conference (SPLC), 2011 15th International, pages 100109. 1, 4, 15, 22
Alhazbi, S. and Jantan, A. (2006). Multi-level mediator-based technique for classes
hot swapping in java applications. In Information and Communication Technologies,
2006. ICTTA 06. 2nd, volume 2, pages 28892892. 43
Ali, N. and Babar, M. (2009). Modeling service oriented architectures of mobile applications by extending soaml with ambients. In Software Engineering and Advanced
Applications, 2009. SEAA 09. 35th Euromicro Conference on, pages 442449. 3
Alves, V., Matos, P., Cole, L., Borba, P., and Ramalho, G. (2005). Extracting and evolving mobile games product lines. In Proceedings of the 9th international conference
on Software Product Lines, SPLC05, pages 7081, Berlin, Heidelberg. SpringerVerlag. 14
Bencomo, N., Lee, J., and Hallsteinsen, S. O. (2010). How dynamic is your dynamic
software product line? In SPLC Workshops, pages 6168. 2, 15
Bencomo, N., Hallsteinsen, S., and Santana de Almeida, E. (2012). A view of the
dynamic software product line landscape. Computer, 45(10), 3641. 2, 15
Carter, S. (2007). The New Language of Business: SOA e Web 2.0. IBM Press. 17
Clements, P. and Northrop, L. (2001). Software Product Lines: Practices and Patterns.
Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. 9, 12, 13, 14
Clements, P., Garlan, D., Little, R., Nord, R., and Stafford, J. (2003). Documenting software architectures: views and beyond. In Software Engineering, 2003. Proceedings.
25th International Conference on, pages 740741. 28
Czarnecki, K. and Eisenecker, U. (2000). Generative programming: methods, tools, and
applications. Addison Wesley. 51
de Castro Alves, A. (2011). OSGi in Depth. Manning Publications Co., Greenwich, CT,
USA, 1st edition. 27, 53
74
REFERNCIAS
Demirkan, H., Kauffman, R. J., Vayghan, J. A., Fill, H.-G., Karagiannis, D., and Maglio,
P. P. (2008). Service-oriented technology and management: Perspectives on research
and practice for the coming decade. Electron. Commer. Rec. Appl., 7(4), 356376. 2
Dhungana, D., Grnbacher, P., and Rabiser, R. (2007). Domain-specific adaptations of
product line variability modeling. In Situational Method Engineering, pages 238251.
2, 15
Dirksen, J. (2013). SOA Governance in Action: REST and Web Service architecture.
Manning Publication Co., Shelter Island, NY 11964. 17
Elfatatry, A. and Layzell, P. (2004). Negotiating in service-oriented environments. Commun. ACM, 47(8), 103108. 16
Endrei, M., Ang, J., Arsanjani, A., Chua, S., Comte, P., Krogdahl, P., Luo, M., and
Newling, T. (2004). Patterns: Service-Oriented Architecture and Web Services. IBM
Redbooks. 17
Erl, T. (2005). Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall PTR, Upper Saddle River, NJ, USA. 17, 18, 19
Erl, T. (2007). SOA Principles of Service Design (The Prentice Hall Service-Oriented
Computing Series from Thomas Erl). Prentice Hall PTR, Upper Saddle River, NJ,
USA. 3, 4, 16, 18, 22, 24
Escoffier, C., Hall, R., and Lalanda, P. (2007). ipojo: an extensible service-oriented
component framework. In Services Computing, 2007. SCC 2007. IEEE International
Conference on, pages 474481. 5, 24, 28
Galster, M. (2010). Enhancing runtime variability in software product lines through
service-orientation. In SPLC Workshops, pages 4752. 1, 2, 15, 19
Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1995). Design patterns: elements
of reusable object-oriented software. Addison-Wesley Longman Publishing Co., Inc.,
Boston, MA, USA. 44
Garcia-Gonzalez, J., Gacitua-Decar, V., and Pahl, C. (2010). Service registry: A key
piece to enhance reuse in soa. The Architecture Journal, 21. 19
75
REFERNCIAS
Gomaa, H. (2004). Designing Software Product Lines with UML: From Use Cases
to Pattern-Based Software Architectures. Addison Wesley Longman Publishing Co.,
Inc., Redwood City, CA, USA. 9
Gomaa, H. and Hashimoto, K. (2011). Dynamic software adaptation for service-oriented
product lines. In Proceedings of the 15th International Software Product Line Conference, Volume 2, SPLC 11, pages 35:135:8, New York, NY, USA. ACM. 5, 23
Hall, R., Pauls, K., McCulloch, S., and Savage, D. (2011). OSGi in Action: Creating
Modular Applications in Java. Manning Publications Co., Greenwich, CT, USA, 1st
edition. 27, 53
Hallsteinsen, S., Stav, E., Solberg, A., and Floch, J. (2006). Using product line techniques to build adaptive systems. In Software Product Line Conference, 2006 10th
International, pages 10 pp.150. 1, 2, 4, 15, 24, 37
Hallsteinsen, S., Hinchey, M., Park, S., and Schmid, K. (2008). Dynamic software
product lines. Computer, 41(4), 9395. 1, 2, 15, 38
Istoan, P., Nain, G., Perrouin, G., and Jezequel, J.-M. (2009). Dynamic software product
lines for service-based systems. In Proceedings of the 2009 Ninth IEEE International
Conference on Computer and Information Technology - Volume 02, CIT 09, pages
193198, Washington, DC, USA. IEEE Computer Society. 19
Josuttis, N. (2007). Soa in Practice: The Art of Distributed System Design. OReilly
Media, Inc. 19
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. 39
Kim, M., Jeong, J., and Park, S. (2005). From product lines to self-managed systems:
an architecture-based runtime reconfiguration framework. In Proceedings of the 2005
workshop on Design and evolution of autonomic application software, DEAS 05,
pages 17, New York, NY, USA. ACM. 1, 2, 4, 15, 24
76
REFERNCIAS
Kon, F., Romn, M., Liu, P., Mao, J., Yamane, T., Magalhes, L., and Campbell, R.
(2000). Monitoring, security, and dynamic configuration with the dynamictao reflective orb. In J. Sventek and G. Coulson, editors, Middleware 2000, volume 1795 of
Lecture Notes in Computer Science, pages 121143. Springer Berlin Heidelberg. 3
Kruchten, P., Obbink, H., and Stafford, J. (2006). The past, present, and future for
software architecture. Software, IEEE, 23(2), 2230. 28
Krueger, C. (2002). Eliminating the adoption barrier. Software, IEEE, 19(4), 2931. 13,
14
Krut, R. and Cohen, S. (2008). Service-oriented architectures and software product lines
- putting both together. In SPLC, page 383. 2, 16
Lee, J., Kotonya, G., and Robinson, D. (2012). Engineering service-based dynamic
software product lines. Computer, 45(10), 4955. 2
Linden, F. J. v. d., Schmid, K., and Rommes, E. (2007). Software Product Lines in
Action: The Best Industrial Practice in Product Line Engineering. Springer-Verlag
New York, Inc., Secaucus, NJ, USA. 10, 11, 13, 14
Marinho, F. G., Andrade, R. M., Werner, C., Viana, W., Maia, M. E., Rocha, L. S.,
Teixeira, E., Filho, J. 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, (0). 3, 48, 49
McGovern, J., Tyagi, S., Stevens, M., and Mathew, S. (2003). Java Web Services Architecture. Elsevier Science. 17, 19
Medeiros, F. M. (2010). Sople-de: An approach to design service-oriented product line
architecture. 19
Microsoft Corporation (2005). Web services dynamic discovery (ws-discovery). 18
Niebuhr, D., Rausch, A., Klein, C., Reichmann, J., and Schmid, R. (2009). Achieving
dependable component bindings in dynamic adaptive systems - a runtime testing approach. In Self-Adaptive and Self-Organizing Systems, 2009. SASO 09. Third IEEE
International Conference on, pages 186197. 1
77
REFERNCIAS
Oreizy, P., Medvidovic, N., and Taylor, R. N. (1998). Architecture-based runtime software evolution. In Proceedings of the 20th international conference on Software engineering, ICSE 98, pages 177186, Washington, DC, USA. IEEE Computer Society.
43
Oreizy, P., Gorlick, M., Taylor, R., Heimhigner, D., Johnson, G., Medvidovic, N., Quilici, A., Rosenblum, D., and Wolf, A. (1999). An architecture-based approach to selfadaptive software. Intelligent Systems and their Applications, IEEE, 14(3), 5462. 1,
4, 24
Papazoglou, M. P. and Georgakopoulos, D. (2003). Introduction: Service-oriented computing. Commun. ACM, 46(10), 2428. 16, 18
Parra, C., Blanc, X., and Duchien, L. (2009). Context awareness for dynamic serviceoriented product lines. In Proceedings of the 13th International Software Product
Line Conference, SPLC 09, pages 131140, Pittsburgh, PA, USA. Carnegie Mellon
University. 21, 22
Parra, C. A., Quinton, C., and Duchien, L. (2012). Capucine: Context-aware serviceoriented product line for mobile apps. ERCIM News, 2012(88). 3
Pohl, K., Bckle, G., and Linden, F. J. v. d. (2005). Software Product Line Engineering:
Foundations, Principles and Techniques. Springer-Verlag New York, Inc., Secaucus,
NJ, USA. 3, 10, 11, 12, 13, 14, 34, 48
Raatikainen, M., M. V. and Mannisto, T. (2007). Comparison of service and software
product family modeling. In In Proceedings of the 11th International Software Product Line Conference (SPLC 07) - 1st International Workshop on Service Oriented
Architectures and Product Lines (SOAPL 07), Kyoto. Japan. 2, 15, 16, 19
Ribeiro, H. B. G. (2010). An approach to implement core assets in service-oriented
product lines. 19
Rocha, L. S., Castro, C., Machado, J., and Andrade, R. (2007). Using dynamic reconfiguration and context notification for ubiquitous software development. In Proceedings
of 21st Brazilian Symposium on Software Engineering (SBES-XXI), pages 219235. 3
Rosenmller, M., Siegmund, N., Pukall, M., and Apel, S. (2011). Tailoring dynamic
software product lines. SIGPLAN Not., 47(3), 312. 1, 14
78
REFERNCIAS
Segura, S., Benavides, D., Ruiz-Corts, A., and Trinidad, P. (2007). A taxonomy of
variability in web service flows. In Service Oriented Architectures and Product Lines
(SOAPL 07), Kyoto. Japan. 2, 15, 19
Shaw, M. and Garlan, D. (1996). Software architecture: perspectives on an emerging
discipline. Prentice-Hall, Inc., Upper Saddle River, NJ, USA. 28
Silva, J. R. F., Silva, F. A. P., Nascimento, L. M., Martins, D. A. O., and Garcia, V. C.
(2013). The Dynamic Aspects of Product Derivation in DSPL: a Systematic Literature
Review. Proceedings of the 2013 IEEE 14thInternational Conference on Information
Reuse and Integration, pages 466473. 22
Smith, D. and Lewis, G. (2009). Service-oriented architecture (soa) and software product
lines: Preimplementation decisions. In In Proceedings of the 13th International Software Product Line Conference (SPLC 09) - 3st International Workshop on Service
Oriented Architectures and Product Lines (SOAPL 09), San Francisco, CA, USA. 2,
19
Tan, L. (2001). SwapBox: a Hot-Swapping Framework for Swappable JavaBeans. Masters thesis, Department of System and Computer Engineering, Carleton University,
Ottawa, Canada. 43
Tiwari, S., Rathore, S., and Gupta, A. (2012). Selecting requirement elicitation techniques for software projects. In Software Engineering (CONSEG), 2012 CSI Sixth
International Conference on, pages 110. 26
Trujillo, S., A. S. and Kaestner, C. (2007). Product lines that supply other product lines:
A service-oriented approach. In In Proceedings of the 11th International Software
Product Line Conference (SPLC 07) - 1st International Workshop on Service Oriented Architectures and Product Lines (SOAPL 07), Kyoto. Japan. 2, 15, 19
Ullah, S., Iqbal, M., and Khan, A. (2011). A survey on issues in non-functional requirements elicitation. In Computer Networks and Information Technology (ICCNIT),
2011 International Conference on, pages 333340. 26
Viana, W. and Andrade, R. M. (2008). Xmobile: A mb-uid environment for semiautomatic generation of adaptive applications for mobile devices. Journal of Systems
and Software, 81(3), 382 394. <ce:title>Selected Papers from the 2006 Brazilian
Symposia on Databases and on Software Engineering</ce:title>. 3
79
REFERNCIAS
Wolfinger, R., Reiter, S., Dhungana, D., Grunbacher, P., and Prahofer, H. (2008). Supporting runtime system adaptation through product line engineering and plug-in techniques. In Composition-Based Software Systems, 2008. ICCBSS 2008. Seventh International Conference on, pages 2130. 2, 15
Ye, E., Moon, M., Kim, Y., and Yeom, K. (2007). An approach to designing serviceoriented product-line architecture for business process families. In Advanced Communication Technology, The 9th International Conference on, volume 2, pages 999
1002. 2, 19
Yu, H. Q. and Reiff-Marganiec, S. (2008). Non-functional property based service selection: A survey and classification of approaches. In Non Functional Properties and
Service Level Agreements in Service Oriented Computing Workshop co-located with
The 6th IEEE European Conference on Web Services. 39, 47
Yu, J., Lalanda, P., and Bourret, P. (2010). An approach for dynamically building and
managing service-based applications. In Services Computing Conference (APSCC),
2010 IEEE Asia-Pacific, pages 5158. 2, 19, 22
Zi-yun, D. and Ru-long, W. (2011). Efsm task scheduling model research in the soa
integration platform. In Computer and Management (CAMAN), 2011 International
Conference on, pages 13. 17
80
Apndice
81
A
Componentes Descritores
A.1
Abaixo apresentado a definio da estrutura de metadados referente ao Descritor de

Servios.
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="services">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="1" ref="service" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="service">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="service-spec" type="xsd:string" />
<xsd:element maxOccurs="unbounded" minOccurs="0"
ref="alternative-service" />
</xsd:sequence>
<xsd:attribute name="id" type="xsd:string" use="optional" />
<xsd:attribute name="service-impl" type="xsd:string"
use="optional" />
</xsd:complexType>
</xsd:element>
<xsd:element name="alternative-service">
<xsd:complexType>
<xsd:attribute name="ref" type="xsd:string" use="optional" />
<xsd:attribute name="priority" type="xsd:string" use="optional" />
</xsd:complexType>
</xsd:element>
</xsd:schema>
82
A.2. DESCRITOR DE VARIABILIDADES
A.2

Variabilidades.
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="variabilities">
<xsd:complexType>
<xsd:sequence>
ref="variability" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="variability">
<xsd:complexType>
<xsd:sequence>
ref="variant" />
</xsd:sequence>
<xsd:attribute name="id" type="xsd:string" use="required" />
<xsd:attribute name="name" type="xsd:string" use="optional" />
</xsd:complexType>
</xsd:element>
<xsd:element name="variant">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="1" ref="service-ref"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:string" use="required" />
<xsd:attribute name="name" type="xsd:string" use="optional" />
</xsd:complexType>
</xsd:element>
<xsd:element name="service-ref">
<xsd:complexType>
<xsd:attribute name="ref" type="xsd:string" use="optional" />
</xsd:complexType>
</xsd:element>
</xsd:schema>
83
A.3. DESCRITOR DE WSDL
A.3
Descritor de WSDL

WSDL.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://schemas.xmlsoap.org/wsdl/"
elementFormDefault="qualified">
<xs:complexType mixed="true" name="tDocumentation">
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded" processContents="lax" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="tDocumented">
<xs:annotation>
<xs:documentation>
This type is extended by component types to allow them to be documented
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="documentation" type="wsdl:tDocumentation"
minOccurs="0" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="tExtensibleAttributesDocumented"
abstract="true">
<xs:complexContent>
<xs:extension base="wsdl:tDocumented">
<xs:annotation>
<xs:documentation>
This type is extended by component types to allow attributes from
other namespaces to be added.
</xs:documentation>
</xs:annotation>
<xs:anyAttribute namespace="##other"
processContents="lax" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="tExtensibleDocumented" abstract="true">
<xs:complexContent>
<xs:extension base="wsdl:tDocumented">
<xs:annotation>
<xs:documentation>
This type is extended by component types to allow elements from other
namespaces to be added.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"
processContents="lax" />
</xs:sequence>
</xs:extension>
84

</xs:complexType>
<xs:element name="definitions" type="wsdl:tDefinitions">
<xs:key name="message">
<xs:selector xpath="wsdl:message" />
<xs:field xpath="@name" />
</xs:key>
<xs:key name="portType">
<xs:selector xpath="wsdl:portType" />
</xs:key>
<xs:key name="binding">
<xs:selector xpath="wsdl:binding" />
</xs:key>
<xs:key name="service">
<xs:selector xpath="wsdl:service" />
</xs:key>
<xs:key name="import">
<xs:selector xpath="wsdl:import" />
<xs:field xpath="@namespace" />
</xs:key>
</xs:element>
<xs:group name="anyTopLevelOptionalElement">
<xs:annotation>
<xs:documentation>
Any top level optional element allowed to appear more then once - any
child of definitions element except wsdl:types. Any extensibility
element is allowed in any place.
</xs:documentation>
</xs:annotation>
<xs:choice>
<xs:element name="import" type="wsdl:tImport" />
<xs:element name="types" type="wsdl:tTypes" />
<xs:element name="message" type="wsdl:tMessage">
<xs:unique name="part">
<xs:selector xpath="wsdl:part" />
</xs:unique>
</xs:element>
<xs:element name="portType" type="wsdl:tPortType" />
<xs:element name="binding" type="wsdl:tBinding" />
<xs:element name="service" type="wsdl:tService">
<xs:unique name="port">
<xs:selector xpath="wsdl:port" />
</xs:unique>
</xs:element>
</xs:choice>
</xs:group>
<xs:complexType name="tDefinitions">
<xs:complexContent>
<xs:extension base="wsdl:tExtensibleDocumented">
85

<xs:sequence>
<xs:group ref="wsdl:anyTopLevelOptionalElement" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="targetNamespace" type="xs:anyURI"
use="optional" />
<xs:attribute name="name" type="xs:NCName" use="optional" />
</xs:extension>
</xs:complexType>
<xs:complexType name="tImport">
<xs:complexContent>
<xs:extension base="wsdl:tExtensibleAttributesDocumented">
<xs:attribute name="namespace" type="xs:anyURI" use="required" />
<xs:attribute name="location" type="xs:anyURI" use="required" />
</xs:extension>
</xs:complexType>
<xs:complexType name="tTypes">
<xs:complexContent>
<xs:extension base="wsdl:tExtensibleDocumented" />
</xs:complexType>
<xs:complexType name="tMessage">
<xs:complexContent>
<xs:sequence>
<xs:element name="part" type="wsdl:tPart" minOccurs="0"
</xs:sequence>
<xs:attribute name="name" type="xs:NCName" use="required" />
</xs:extension>
</xs:complexType>
<xs:complexType name="tPart">
<xs:complexContent>
<xs:attribute name="element" type="xs:QName" use="optional" />
<xs:attribute name="type" type="xs:QName" use="optional" />
</xs:extension>
</xs:complexType>
<xs:complexType name="tPortType">
<xs:complexContent>
<xs:sequence>
<xs:element name="operation" type="wsdl:tOperation"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
</xs:extension>
</xs:complexType>
86

<xs:complexType name="tOperation">
<xs:complexContent>
<xs:sequence>
<xs:choice>
<xs:group ref="wsdl:request-response-or-one-way-operation" />
<xs:group ref="wsdl:solicit-response-or-notification-operation" />
</xs:choice>
</xs:sequence>
<xs:attribute name="parameterOrder" type="xs:NMTOKENS"
use="optional" />
</xs:extension>
</xs:complexType>
<xs:group name="request-response-or-one-way-operation">
<xs:sequence>
<xs:element name="input" type="wsdl:tParam" />
<xs:sequence minOccurs="0">
<xs:element name="output" type="wsdl:tParam" />
<xs:element name="fault" type="wsdl:tFault" minOccurs="0"
</xs:sequence>
</xs:sequence>
</xs:group>
<xs:group name="solicit-response-or-notification-operation">
<xs:sequence>
<xs:element name="output" type="wsdl:tParam" />
<xs:sequence minOccurs="0">
<xs:element name="input" type="wsdl:tParam" />
<xs:element name="fault" type="wsdl:tFault" minOccurs="0"
</xs:sequence>
</xs:sequence>
</xs:group>
<xs:complexType name="tParam">
<xs:complexContent>
<xs:attribute name="message" type="xs:QName" use="required" />
</xs:extension>
</xs:complexType>
<xs:complexType name="tFault">
<xs:complexContent>
<xs:attribute name="message" type="xs:QName" use="required" />
</xs:extension>
</xs:complexType>
<xs:complexType name="tBinding">
<xs:complexContent>
87

<xs:sequence>
<xs:element name="operation" type="wsdl:tBindingOperation"
</xs:sequence>
<xs:attribute name="type" type="xs:QName" use="required" />
</xs:extension>
</xs:complexType>
<xs:complexType name="tBindingOperationMessage">
<xs:complexContent>
</xs:extension>
</xs:complexType>
<xs:complexType name="tBindingOperationFault">
<xs:complexContent>
</xs:extension>
</xs:complexType>
<xs:complexType name="tBindingOperation">
<xs:complexContent>
<xs:sequence>
<xs:element name="input" type="wsdl:tBindingOperationMessage"
minOccurs="0" />
<xs:element name="output" type="wsdl:tBindingOperationMessage"
minOccurs="0" />
<xs:element name="fault" type="wsdl:tBindingOperationFault"
</xs:sequence>
</xs:extension>
</xs:complexType>
<xs:complexType name="tService">
<xs:complexContent>
<xs:sequence>
<xs:element name="port" type="wsdl:tPort" minOccurs="0"
</xs:sequence>
</xs:extension>
</xs:complexType>
<xs:complexType name="tPort">
<xs:complexContent>
<xs:attribute name="binding" type="xs:QName" use="required" />
88

</xs:extension>
</xs:complexType>
<xs:attribute name="arrayType" type="xs:string" />
<xs:attribute name="required" type="xs:boolean" />
<xs:complexType name="tExtensibilityElement" abstract="true">
<xs:attribute ref="wsdl:required" use="optional" />
</xs:complexType>
</xs:schema>
89

DYMOS: Uma Abordagem para Suporte A Variabilidades Dinâmicas em Linhas de Produto de Software Orientado A Serviços e Sensível Ao Contexto

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DYMOS: Uma Abordagem para Suporte A Variabilidades Dinâmicas em Linhas de Produto de Software Orientado A Serviços e Sensível Ao Contexto

Uploaded by

Copyright:

Available Formats

DYMOS: Uma abordagem para suporte a variabilidades

dinmicas em Linhas de Produto de Software Orientado a

Dhiego Abrantes de Oliveira Martins

Universidade Federal de Pernambuco

Universidade Federal de Pernambuco

Dhiego Abrantes de Oliveira Martins

DYMOS: Uma abordagem para suporte a

Trabalho apresentado ao Programa de Ps-graduao em

Orientador: Vinicius Cardoso Garcia

Este trabalho representa um passo muito importante em

Those mist covered mountains

DYMOS: Arquitetura Externa . . . . . . . . . . . . . . . . . . . . . .

Custos do desenvolvimento de uma Linha de Produto . . . . . . . . .

DYMOS: Viso Geral da Arquitetura . . . . . . . . . . . . . . . . . . .

Abordagem utilizada na MobiLine . . . . . . . . . . . . . . . . . . . .

LoginServiceProvider: Configurao de Instncia . . . . . . . . . . . .

Relao entre Componentes, Requisitos Funcionais e Requisitos NoFuncionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Relao entre Features e Artefatos . . . . . . . . . . . . . . . . . . . .

Arquitetura Orientada a Servios

Computao Orientada a Servios

Web Service Resolver

Engenharia de Linha de Produto de Software

Java Architecture for XML Binding

Linha de Produto de Software

Linha de Produto de Software Dinmica

Linha de Produto de Software Orientado a Servios

LPSOSSC Linha de Produto de Software Orientado a Servios e Sensvel ao

Sistema Sensvel ao Contexto

Web Service Definition Language

Extensible Markup Language

Decises Arquiteturais e Concluso . . . . . . . . . . . . . . .

Uma Avaliao Preliminar

A vida simples, mas ns insistimos em complic-la.

de uma variante a um ponto de variao

flexveis (Ali and Babar, 2009).

O principal desafio quando utilizamos tcnicas de LPS no desenvolvimento de SSCs

desativao de uma ou mais features no sistema, e em tempo de execuo, necessrio

1.3. VISO GERAL DA SOLUO

provido um framework para suporte a reconfigurao e descoberta de servios.

Viso Geral da Soluo

1.3. VISO GERAL DA SOLUO

Figura 1.1 DYMOS: Arquitetura Externa

Com o objetivo de abordar os itens i, ii e iii destacados na Seo 1.2, os seguintes

1.4. ESCOPO NEGATIVO

Alguns aspectos que so relacionados a esta pesquisa no so considerados como parte

1.5. ORGANIZAO DA DISSERTAO

Interpretao de Regras de Contexto Para determinar quais so os componentes que

A estrutuda dessa dissertao est organizada da seguinte forma:

Linhas de Produto de Software: Uma viso geral

2.1. LINHAS DE PRODUTO DE SOFTWARE: UMA VISO GERAL

Observando a Figura 2.1, a linha slida representa o custo de desenvolvimento de

2.1. LINHAS DE PRODUTO DE SOFTWARE: UMA VISO GERAL

Os core assets de uma plataforma de LPS so reutilizados em muitos produtos.

Engenharia de Linha de Produto de Software

As atividades da Engenharia de Linha de Produto de Software (ELPS) so divididas em

2.1. LINHAS DE PRODUTO DE SOFTWARE: UMA VISO GERAL

Engenharia de Aplicao a fase em que os produtos so construdos por meio da

Figura 2.2 Atividades Essenciais na Engenharia de Linha de Produto de Software. Adaptado de

2.1. LINHAS DE PRODUTO DE SOFTWARE: UMA VISO GERAL

definido o escopo da linha de produto. recebido como entrada os pontos comuns

Modelos de Adoo de Linhas de Produto de Software

Muitas organizaes so motivadas a adotar o paradigma de LPS, principalmente por

2.1. LINHAS DE PRODUTO DE SOFTWARE: UMA VISO GERAL