O texto apresenta o contexto sobre o desenvolvimento de sistemas de software e a evolução do conceito de Linha de Produtos de Software (SPL). Apresenta alguns conceitos básicos sobre SPL como: - SPL é um paradigma para desenvolvimento de software em massa que utiliza uma plataforma e customização em massa. - SPL pode ser dividida em dois processos: Engenharia de Domínio e Engenharia de Aplicação. - Alguns benefícios apontados de SPL são fornecimento de produtos de forma massificada e customizados a baixo cust

1. UNIVERSIDADE DE PERNAMBUCO
DIÓGENES RICARDO FREITAS DE OLIVEIRA
UM ESTUDO SOBRE GERENCIAMENTO DE VARIABILIDADE DE REQUISITOS
EM LINHA DE PRODUTOS DE SOFTWARE
CARUARU
2011

2. UNIVERSIDADE DE PERNAMBUCO
DIÓGENES RICARDO FREITAS DE OLIVEIRA
UM ESTUDO SOBRE GERENCIAMENTO DE VARIABILIDADE DE REQUISITOS
EM LINHA DE PRODUTOS DE SOFTWARE
Monografia apresentada ao Curso de Sistemas de
Informação da Universidade de Pernambuco como
requisito parcial para a conclusão do curso de
Sistemas de Informação, sob orientação do Prof.
Msc. Humberto Rocha de Almeida Neto e co-
orientação do Prof. D.Sc. Vinicius Cardoso Garcia.
CARUARU
2011

3. Monografia de Graduação apresentada por Diógenes Ricardo Freitas de Oliveira
do Curso de Graduação em Sistemas de Informação da Faculdade de Ciência e
Tecnologia de Caruaru – Universidade de Pernambuco, sob o título “Um Estudo
Sobre Gerenciamento de Variabilidade de Requisitos em Linha de Produtos
de Software”, orientada pelo Prof. M.Sc. Humberto Rocha de Almeida Neto e
co-orientada pelo Prof. D.Sc. Vinicius Cardoso Garcia e aprovada pela Banca
Examinadora formada pelos professores:
Prof. D.Sc. Fernando Carvalho
Departamento de Sistemas de Informação / UPE
Prof. M.Sc. Vinicius Cardoso Garcia
Centro de Informática / UFPE
Visto e permitida a impressão.
Caruaru, XX de junho de 2011.
Prof. Cícero Garrozi
Coordenador do Curso de Bacharelado em Sistemas de Informação da
Faculdade de Ciência e Tecnologia de Caruaru – Universidade de
Pernambuco.

4. Aos meus familiares, irmãos, amigos e à minha amada.

5. AGRADECIMENTOS
Como filho de quem sou, segundo João 1:12 (60D.C), expresso minha
gratidão. Primeiramente ao meu Pai celestial, pelo privilégio de ser seu filho e gozar
da sua presença em minha vida de forma tão intensa, inclusive na produção desse
trabalho. Obrigado meu Deus, por ser um Pai tão bondoso, que me ajudou a
escrever, por me inspirar naqueles dias que eu não estava com a mínima vontade
(nem de ligar o computador). Sem Ti, nada posso fazer, te amo Pai.
Obrigado Jesus Cristo, por me dar este acesso ao Pai (I TIMÓTEO 2:5), sem
o qual não poderia estar em paz com Deus (Romanos 5:1) e viver da Sua presença
(ROMANOS 5:9-11).
À minha família, especialmente aos meus pais, Gilson Ricardo e Lunamar
Freitas, pela criação que vocês me deram. A painho pelo apoio, sem o qual não
poderia ter chegado aqui, por ser exatamente como o senhor é (essencial para
formação do meu caráter).
À minha irmã Amanda Jacqueline pelo companheirismo e paciência (não é
tanta assim, não). Eu agradeço a Deus por vocês existirem. Amo muito vocês, essa
é uma conquista nossa!
Ao meu amado, inspirador, conselheiro, Manuel Augustinho (in memoriam),
minha gratidão por tudo que o senhor fez, vô. Pelas inúmeras vezes que conversei o
senhor sobre meus problemas, inclusive da faculdade, que o senhor não entendia
direito de que era, mas falava exatamente o que eu precisava ouvir, impressionante!
Até logo meu herói e querido vô (Quem estuda, Deus ajuda, dizia ele).
Às minhas avós Lú e Deija pela compreensão, maravilhosos conselhos, pelas
disciplinas e paciência.
A vovó Aurora (95 anos) que sempre que me vê pergunta como estão os
estudos (eu tinha que dizer algo novo).
Aos Meus tios, em especial a tio Alexandre, vocês são muito importantes pra
mim.
À minha amada Elyda Laisa, pela ajuda direta e indireta nesse trabalho, por
ter paciência com minhas cismas, me acalmando nos momentos de agonia e pelo
incentivo. Obrigado minha linda, amo você demais.
Aos meus mestres Humberto Rocha e Vinícius Garcia pelas sugestões, idéias
e críticas (foram muitas). Vinícius, olho para trás e vejo como evoluí com seus

6. comentários, suas contribuições foram essenciais pra o fim desse trabalho. Deus
abençoe vocês.
Aos meus amigos de jornada da UPE, companheiros de trabalhos e projetos
(não vou citar nomes, senão não cabe).
Aos amigos de infância (Everton, João Paulo, entre outros) por me escutarem
e ajudar a aliviar a pressão da faculdade com lazer (Jiu-Jítsu, trilhas, viagens, PS3,
entre outras atividades). Valeu galera!
Aos meus irmãos em Cristo (Marcos, Romenilson, Rafael, Caio, Junior, Elifas,
entre outros) pelas palavras de sabedoria (essa aqui, só do povo de Deus) sempre
na hora certa... como Deus usou e usa vocês na minha vida! Graça e paz meus
irmãos, amo vocês.
Finalmente a todos aqueles que contribuíram direta ou indiretamente com o
fim desse trabalho, meus sinceros agradecimentos.

7. RESUMO
Linha de Produtos de Software é uma abordagem de desenvolvimento de
software criada para atender diferentes segmentos de mercado. Esta abordagem
tem apresentado grande aceitação no ambiente corporativo por permitir a
construção de aplicações de forma mais eficiente através do reuso de componentes
comuns, além de estar sendo extensivamente pesquisada por acadêmicos. Dentro
da Linha de Produtos de Software, a variabilidade tem o papel de fornecer recursos
para implementação dos produtos a partir de diferentes perspectivas, mantendo um
baixo custo de desenvolvimento e manutenção. Sendo assim, a adoção da Linha de
Produtos apresenta-se como uma solução vantajosa. A Engenharia de Requisitos do
Domínio é o ponto inicial para implementação da variabilidade. Este trabalho propõe
um conjunto de funcionalidades e características que devem compor uma
ferramenta que dê suporte ao Gerenciamento da variabilidade dentro Engenharia de
Requisitos em Linha de Produtos de Software, além de apresentar uma avaliação
das principais soluções.
Palavras-chave: Linha de produtos de software. Variabilidade. Gerenciamento de
variabilidade, Engenharia de Requisitos do Domínio.

8. ABSTRACT
Software Product Line is a software development approach designed to
address different market segments. This approach has had great acceptance in the
corporate environment by allowing the construction of applications more efficiently by
reusing common components, besides being extensively researched by academics.
In Software Product Line, the variability has a role in providing resources for
implementation of products from different perspectives, while maintaining a low cost
of development and maintenance. Thus, the adoption of Product Line presents itself
as an advantageous solution. The Domain Engineering Requirements is the starting
point for implementation of the variability. This -work- proposes a set of functionalities
and characteristics that should make a tool that supports the variability management
within the Requirements Engineering in Software Product Line and present an
evaluation of main solutions.
Keywords: Software Product Line, Variability. Variability Management, Domain
Egineering Requirements
.

9. LISTA DE FIGURAS
Figura 1: Custo para desenvolver N tipos de sistemas comparando o SSD com
SPLE. Adaptada de Pohl (2005, p.10) ...................................................................... 21
Figura 2: Ponto de variação e suas variantes ........................................................... 23
Figura 3: Principais atividades para SPLE adaptada de (NORTHROP e CLEMENTS,
2007) ......................................................................................................................... 25
Figura 4: Os subprocessos da Engenharia de Domínio e Engenharia de Aplicação.
Figura adaptada de (POHL et. al., 2005) .................................................................. 26
Figura 5: Etapas do processo da Engenharia de Requisitos. Adaptada
(SOMMERVILLE E KOTONYA, 1998) ...................................................................... 28
Figura 6: Processo de gerenciamento de variabilidade. Fonte: (BURGARELI, 2009,
p. 131) ....................................................................................................................... 30
Figura 7: Principais abordagens de gerenciamento de variabilidade. (CHEN et. al.,
2009) ......................................................................................................................... 31
Figura 8: Técnicas de Gerenciamento dos requisitos. Adaptada (EBERLEIN, 2002)
.................................................................................................................................. 34
Figura 9: Número de trabalhos selecionados para leitura completa .......................... 40
Figura 10: Número de trabalhos por base científica .................................................. 41

10. LISTA DE TABELAS
Tabela 1: Principais formas de representação do gerenciamento de variabilidade... 32
Tabela 2: Informações das Ferramentas ................................................................... 43
Tabela 3: Ferramentas e suas características........................................................... 44
Tabela 4: Ferramentas e suas funcionalidades ......................................................... 47
Tabela 5: Funcionalidades propostas ........................................................................ 48
Tabela 6: Funcionalidades complementares propostas ............................................ 49
Tabela 7: Critérios de usabilidade ............................................................................. 49

11. LISTA DE SIGLAS
SSD - Single System Development
SPL - Software Product Line
SPLE - Software Product Line Engineering
SEI - Software Engineering Institute
VaMoS - Variability Modeling of Software-intesive

12. SUMÁRIO
1. INTRODUÇÃO ................................................................................................... 14
1.1. Contextualização......................................................................................... 14
1.2. Problema de Pesquisa ................................................................................ 15
1.3. Objetivos ..................................................................................................... 15
1.3.1. Objetivo Geral ........................................................................................ 15
1.3.2. Objetivos Específicos ............................................................................ 16
1.4. Justificativa ................................................................................................. 16
1.5. Escopo Negativo ......................................................................................... 17
1.6. Contribuições .............................................................................................. 17
1.7. Estrutura do Trabalho ................................................................................. 18
2. REFERENCIAL TEÓRICO ................................................................................ 19
2.1. Linha de Produtos de Software ................................................................... 19
2.1.1. Definição ................................................................................................ 19
2.2.2. Quando usar SPL ................................................................................... 20
2.2. Variabilidade ............................................................................................... 21
2.2.1. Conceitos ............................................................................................... 22
2.2.2. Tipos de Variabilidade ........................................................................... 23
2.2.3. Níveis de Variabilidade .......................................................................... 24
2.2.4. Classificação das Variantes ................................................................... 24
2.3. Entendendo o funcionamento da SPLE ...................................................... 25
2.3.1. Engenharia de Domínio ......................................................................... 26
2.3.2. Engenharia de Aplicação ....................................................................... 27
2.4. Engenharia de Requisitos do Domínio ........................................................ 28
2.4.1. Gerenciamento de Variabilidade nos Requisitos ................................... 29
3. METODOLOGIA ................................................................................................ 37
3.1. Natureza da pesquisa ................................................................................. 37
3.1.1. Quanto aos fins...................................................................................... 37
3.1.2. Quanto aos meios.................................................................................. 37
3.1.3. Formas de abordagem .......................................................................... 38
3.2. Análise dos dados .......................................................................................... 38

13. 4. UM ESTUDO SOBRE GERENCIAMENTO DE VARIABILIDADE DE
REQUISITOS EM LINHA DE PRODUTOS DE SOFTWARE ................................... 40
4.1. Resultado das Pesquisas ............................................................................ 40
4.1.1. Critérios de Seleção das Ferramentas .................................................. 41
4.2. Investigação das Ferramentas .................................................................... 42
4.2.1. Ferramentas Selecionadas .................................................................... 42
4.2.2. Características das Ferramentas ........................................................... 43
4.2.3. Funcionalidades das Ferramentas......................................................... 45
4.3. Proposta...................................................................................................... 48
4.4. Trabalhos Relacionados ............................................................................. 50
5. CONSIDERAÇÕES FINAIS ............................................................................... 51
5.1. Limitações ................................................................................................... 51
5.2. Lições Aprendidas....................................................................................... 52
5.3. Recomendações para trabalhos futuros ..................................................... 52
6. REFERÊNCIAS ................................................................................................. 53
ANEXO 1 – BUSCA NAS BASES CIENTÍFICAS .................................................. 57

14. 14
1. INTRODUÇÃO
1.1. Contextualização
Desde o início do desenvolvimento de sistemas computacionais até os dias
de hoje, muitos deles vêm sendo produzidos sob uma perspectiva de manufatura
(Desenvolvimento de Sistema Único, do inglês Single System Development). A idéia
de produção de software em massa, embora remota, já se mostrava presente em
alguns trabalhos de pesquisadores que observavam a similaridade dos produtos
desenvolvidos.
Na década de 70 deu-se início a um conceito de Família de Produtos
(PARNAS, 1979), no qual se projetava que vários sistemas que possuíssem as
mesmas características estivessem dentro do mesmo domínio. Dessa forma, iniciou-
se o conceito Linha de Produtos de Software (do inglês Software Product Lines –
SPL).
No contexto atual do desenvolvimento de sistemas, requisitos não-funcionais
como confiabilidade, manutenibilidade, reusabilidade, entre outros, tornam-se cada
vez mais importantes. Segundo o Bergey (2000) várias empresas já ganharam
melhorias quantificáveis no quesito eficiência, produtividade e qualidade através da
abordagem de SPL, que tem como características essenciais de seu funcionamento,
estas condições não técnicas.
Segundo Pohl et. al. (2005), uma SPL é um paradigma para desenvolvimento
de software que se utiliza de uma plataforma e da customização em massa.
A SPL pode ser dividida em dois grandes processos: desenvolvimento da
plataforma, que é um conjunto de artefatos reusáveis; e desenvolvimento dos
produtos, realizado a partir dos artefatos da plataforma. Em geral, o primeiro
processo é denominado Engenharia de Domínio e o segundo, Engenharia de
Aplicação.
De acordo com o Software Engineering Institute (SEI), alguns dos principais
benefícios de uma SPL é o fornecimento de produtos de forma massificada e, no
entanto, customizados e a baixo custo1. Pohl et. al. (2005) ressaltam ainda a
importância da SPL no ambiente moderno:
1
http://www.sei.cmu.edu/productlines/frame_report/benefits.costs.htm. Acesso em: 11/05/2011.

15. 15
Portanto, atualmente há uma forte necessidade para adoção da engenharia
linha de produtos, quando pode ser observado um domínio de software,
especialmente quando o tamanho e a complexidade ultrapassam os limites
do que é viável com as abordagens tradicionais. (POHL et. al, 2005, p.14).
Em meio a esses pontos, a variabilidade dos artefatos é a questão chave para
o desenvolvimento desse paradigma de desenvolvimento.
Segundo Weiss e Chi Tau (1999), variabilidade é a forma como os membros
de uma família de produtos podem se diferenciar entre si. Devido à sua importância,
faz-se necessário uma atenção especial ao seu gerenciamento, através de formas e
ferramentas que deem apoio ao desenvolvimento, manutenção, evolução entre
outros. No contexto dos requisitos, a fase da SPL responsável pelo gerenciamento
da variabilidade é a Engenharia de Requisitos do Domínio.
1.2. Problema de Pesquisa
Devido à importância do gerenciamento da variabilidade, este trabalho se
propõe a analisar as principais ferramentas que podem auxiliar no processo de
gerenciamento de variabilidade na Engenharia de Requisitos do Domínio da SPLE.
Pretende-se, ao término deste trabalho, ter identificado subsídios suficientes
para encontrar uma resposta para a seguinte indagação: Quais são as principais
características e funcionalidades que devem compor uma ferramenta que apóie
efetivamente o Gerenciamento de Variabilidade de Requisitos do Domínio em Linha
de Produtos de Software?
1.3. Objetivos
Os objetivos da pesquisa dividem-se em geral e específicos, os quais serão
definidos a seguir.
1.3.1. Objetivo Geral
Propor um conjunto de funcionalidades que apóie o gerenciamento de
variabilidade em SPL no contexto da Engenharia de Requisitos do Domínio,
baseando-se no estado da arte da academia e melhores práticas da indústria.

16. 16
1.3.2. Objetivos Específicos
Com a finalidade de atingir o objetivo geral são definidos os seguintes
objetivos específicos:
 Investigar os processos de gerenciamento de variabilidade de requisitos para
Linha de Produtos de Software.
 Pesquisar ferramentas acadêmicas e industriais que dêem suporte ao
gerenciamento de variabilidade em Linhas de Produto de Software no
contexto da Engenharia de Requisitos do Domínio.
 Identificar e documentar funcionalidades básicas e complementares de cada
ferramenta.
 Realizar uma análise das ferramentas, de acordo com suas funcionalidades.
1.4. Justificativa
O gerenciamento de variabilidade é uma das principais atividades na SPLE
(Software Product Line Engineering) sendo considerada a chave para a
exeqüibilidade da plataforma.
Academicamente, esse estudo é importante pois irá identificar as principais
funcionalidades para uma ferramenta que apóie o gerenciamento de variabilidade
dos requisitos de domínio. E, através desta identificação, dando subsidio que
acadêmicos possam desenvolver uma solução que atenda a necessidade do
gerenciamento de variabilidade na SPLE.
A contribuição prática deste trabalho está na identificação das principais
ferramentas para o gerenciamento de variabilidade de requisitos envolvidas do
processo de desenvolvimento da SPL, a fim de garantir a eficiência da plataforma de
desenvolvimento.
Além disso, a identificação e análise das principais ferramentas envolvidas no
processo de desenvolvimento dos requisitos poderão auxiliar as fábricas de software
a escolher a que melhor se adéqua ao seu processo de desenvolvimento.

17. 17
1.5. Escopo Negativo
A proposta deste trabalho está inserida em um contexto mais amplo, portanto
faz-se necessário tratar alguns aspectos que não estão relacionados no escopo
deste trabalho.
Adicionalmente, as funcionalidades propostas para a ferramenta não
compõem um conjunto absoluto de requisitos necessários, que devem sempre estar
presentes em qualquer ferramenta para SPL. Estes requisitos dependem das
necessidades do ambiente onde a mesma será utilizada.
Ressaltamos que os seguintes aspectos não fazem parte do escopo deste
trabalho:
 Processo de gerenciamento de variabilidade: embora seja feita uma breve
explanação sobre a atuação do gerenciamento de variabilidade dos requisitos
no contexto da SPLE, não serão tratadas, com detalhes, a variabilidade em
outras fases da SPL - como arquitetura, implementação e testes.
 Abordagem de SPL: mesmo sendo dada uma visão geral sobre as principais
abordagens em SPL e uma descrição sintetizada das fases da SPLE, este
trabalho não propõe um framework para desenvolvimento de SPL.
 Ferramenta: apesar de serem levantadas as principais características e
funcionalidades que devem estar presentes em uma ferramenta para o
gerenciamento de variabilidade dos requisitos, tal ferramenta não será
desenvolvida neste trabalho.
1.6. Contribuições
As principais contribuições deste trabalho são:
 A compreensão dos pontos principais que estão evolvidos nos processos de
gerenciamento de variabilidade de requisitos para Linha de Produtos de
Software.
 A pesquisa das ferramentas acadêmicas e industriais que dão suporte às
atividades necessárias no gerenciamento de variabilidade em Linhas de
Produto de Software no contexto da Engenharia de Requisitos do Domínio.

18. 18
 A identificação e descrição de funcionalidades básicas e complementares
necessárias em uma ferramenta que apóia eficientemente a Engenharia de
Requisitos do Domínio.
 Uma análise comparativa da presença das principais funcionalidades e
características nas ferramentas identificadas durante a pesquisa.
1.7. Estrutura do Trabalho
Neste capítulo, foi apresentada a contextualização da Engenharia de
Requisitos em Linha de Produtos de Software, além do problema de pesquisa, e a
definição dos objetivos, a fim de responder a pergunta de pesquisa. Adicionalmente,
foi explanada a justificativa para execução do trabalho e suas contribuições.
Este trabalho está estruturando, a partir daqui, da seguinte maneira:
No capítulo 2 está o referencial teórico, que apresenta os principais
componentes envolvidos no contexto da Engenharia de Requisitos em Linha de
Produtos de Software.
O capítulo 3 trata a forma de escrita deste trabalho, bem como método para
realização da pesquisa e a forma de análise de dados.
O capítulo 4 trata dos resultados do trabalho, apresentando também os
trabalhos e ferramentas selecionados, a proposta de funcionalidades e os trabalhos
relacionados.
Por fim, são expostas as considerações finais acerca do trabalho.

19. 19
2. REFERENCIAL TEÓRICO
Este capítulo apresenta os conceitos básicos sobre Linha de Produtos de
Software, Variabilidade e o Gerenciamento de Variabilidade de Requisitos do
Domínio.
2.1. Linha de Produtos de Software
O termo linha de produtos de software surgiu como uma mescla de outros
termos. Nas décadas de 70 e 80, pesquisadores como Parnas (1976), Habermann
(1976), Neighbors (1984) entre outros, já estudavam a oportunidade da utilização de
uma forma de produção mais econômica e rápida, observando práticas da industria
como produção em massa atrelada à customização. Era notada a similaridade de
sistemas de software, os quais recebiam o nome de família de sistemas ou família
de produtos.
Nas próximas seções serão conceituados os principais componentes e
atividades envolvidas no processo de SPL e descritos os principais processos sobre
o funcionamento da SPLE.
2.1.1. Definição
Uma linha de produtos compreende um conjunto de produtos que se destinam
a um segmento de mercado específico ou a uma missão particular (NORTHROP e
CLEMENTS, 2007).
Antes de melhor definir SPL precisamos conhecer outros conceitos
importantes envolvidos nessa abordagem.
Primeiramente, é preciso compreender um conceito muito presente nas
abordagens da SPL, que é o conceito de feature2. Segundo Czarnecki et. al. (2005)
uma feature é um aspecto, qualidade ou característica de um software ou de
sistemas que é proeminente visível ao usuário ou a outro sistema.
Outro importante conceito é o de core assets, que consiste de itens reusáveis,
tais como requisitos, modelos, componentes, arquitetura, planos de testes, casos de
testes, entre outros artefatos. Este conjunto, denominado plataforma, é a base para
2
Neste trabalho, o termo feature não é traduzido por entendermos que a tradução (característica), na
língua portuguesa, não traduz o que tecnicamente o termo significa.

20. 20
a linha de produtos de software, seus itens podem ser reusados por diferentes
membros da família de produtos e podem evoluir junto à plataforma.
Com o entendimento desses conceitos, podemos compreender melhor a
definição de SPL de Clements e Northrop, bastante aceita na academia:
Uma linha de produtos de software é um conjunto de sistemas com uso
intensivo de reúso software que compartilham um conjunto de features
comuns e gerenciáveis, que satisfazem às necessidades específicas de um
segmento de mercado particular ou missão, e que são desenvolvidos a
partir de um conjunto de core assets comuns, de modo planejado.
(CLEMENTS E NORTHROP, 2001, p. 05).
Uma diferença básica entre o processo SSD e SPLE é que o primeiro é
focado no contrato, somente no produto final e a ser entregue no prazo; já o
segundo tem uma visão estratégica, enxerga a oportunidade de negócio em
determinado segmento do mercado (conhecido dentro do processo de SPLE como
domínio). Na engenharia de software, o termo domínio é definido como uma parte
especializada do conhecimento, uma área de experiência ou um conjunto de
funcionalidades que se relacionam (NORTHROP E CLEMENTS, 2007).
Assim como deve ser analisada a viabilidade de aplicar qualquer mudança em
uma empresa, seja um software, um processo de desenvolvimento, uma ferramenta,
ou uma metodologia. Deve-se verificar quando a prática do paradigma da
engenharia de linha de produtos é viável, o que será visto a seguir.
2.2.2. Quando usar SPL
A utilização da abordagem de SPLE é válida quando há oportunidade para o
desenvolvimento de softwares que compartilham características comuns. Uma
análise de mercado e outros estudos podem ser feitos a fim de confirmar se a
utilização da abordagem é válida.
Quando a fabricação de produtos de forma individual, sob um processo de
SSD, acarretaria em um custo muito alto, a SPLE contribuiria, neste caso, para a
redução deste custo, além de aumentar a qualidade dos produtos e valorizar o
capital humano (SEI3).
Como em qualquer outra área, as mudanças nas práticas de engenharia de
software têm que ser justificadas sob a perspectiva econômica. Essa é uma das
3
http://www.sei.cmu.edu/productlines/frame_report/benefits.costs.htm. Acesso em:11/05/2011.

21. 21
principais razões para a adoção da SPLE, que tem como forte argumento a redução
dos custos.
Segundo Pohl et. al. (2005), quando os artefatos de uma plataforma são
reusados em diferentes tipos de sistema, há uma redução de custo de cada sistema.
Porém, antes de os componentes serem reusados, a empresa deve fazer um
investimento inicial maior para criar a plataforma. Os custos serão reduzidos ao
longo do desenvolvimento dos produtos, através da reutilização dos artefatos da
plataforma.
A Figura 1 mostra a diferença de custo ao desenvolver produtos, sob os
diferentes paradigmas de desenvolvimento (SSD e SPLE), apresentando o ponto de
quebra existente quando aproximadamente três sistemas são desenvolvidos, a
SPLE passa a ter menor esforço de acumulado, mesmo tendo um investimento
inicial maior.
Figura 1: Custo para desenvolver N tipos de sistemas comparando o SSD com SPLE. Adaptada de Pohl
(2005, p.10)
A questão principal, que evidencia essa diferença no esforço para o
desenvolvimento de produtos sob as diferentes abordagens, está na aplicação
variabilidade, que será conceituada a seguir.
2.2. Variabilidade
Nesta seção, serão explanados os aspectos referentes à variabilidade, tais
como seus tipos, níveis e sua classificação.

22. 22
2.2.1. Conceitos
Para o funcionamento da SPLE uma das questões-chave é a variabilidade. A
importância deste assunto é tal que há um workshop internacional sobre o assunto:
VaMoS4 (Variability Modeling of Software-intesive). O conceito de variabilidade é
apresentado, a fim de compreender seu funcionamento na Engenharia de Requisitos
do Domínio.
Bachmann e Clements (2005) definem variabilidade como a habilidade de um
sistema ou core asset que, no ambiente de desenvolvimento, apóia a produção de
um conjunto de artefatos que diferem entre si. O que significa a adaptação no uso
dos core assets em diferentes produtos.
A variabilidade tem participação em todo o ciclo de vida do processo da
SPLE, porém “o objetivo da variabilidade em linha de produtos de software é
maximizar o retorno sobre o investimento (ROI) para construção e manutenção dos
produtos dentro de um período de tempo específico ou de um número de produtos”
(BACHMANN e CLEMENTS, 2005, p.10).
Em SPL, a variabilidade fornece a flexibilidade para diferenciar e diversificar
produtos. Nela, a habilidade de um artefato ser configurado, customizado, estendido
ou mudado para um uso específico em um contexto é dada através de alguns
conceitos vistos adiante, de acordo com (BACHMANN e CLEMENTS 2005) e
(LINDEN et. al., 2007):
 Variante: Representa um objeto de variabilidade dentro dos artefatos de
domínio, como um componente. São instâncias em um ponto de variação.
 Ponto de variação: Representação de um objeto da variabilidade, onde se
decide a escolha entre as variantes, normalmente enriquecida por
informações contextuais do domínio.
A Figura 2, a seguir, adaptada de Pohl et. al (2005, p. 153), mostra um
exemplo de um ponto de variação e as variantes que podem ser escolhidas para ele.
4
VaMoS - Workshop Internacional sobre Modelagem de Variabilidade em Software Específicos

23. 23
Figura 2: Ponto de variação e suas variantes
 Variação: Forma como duas variantes diferem entre si.
 Mecanismo de variabilidade: Responsável por implementar a variabilidade.
 Dependência de variantes: Usado para denotar as diferentes escolhas da
variante no ponto de variação, essa notação inclui cardinalidade e outros
atributos.
 Restrições de dependências das variantes: Descreve as dependências nas
seleções das variantes, apresentam-se de duas formas:
o Requerida: Indica se a variante depende de outra.
o Exclusiva: Indica se a variante entra em conflito com outra.
Devido à importância da variabilidade no funcionamento da SPL, a mesma
deve ser “definida, representada, explorada, implementada, evoluída, entre outros”
(LINDEN et. al., 2007, p. 8). A seguir, outros pontos relevantes na compreensão da
variabilidade.
2.2.2. Tipos de Variabilidade
Os core assets desenvolvidos podem ser utilizados tanto no domínio (na
plataforma), quanto para produtos específicos. Segundo Linden et. al. (2007), a
variabilidade pode ser dividida em três tipos:
 Comum: Uma característica (funcional ou não funcional) que pode ser
comum para todos os produtos da SPL e é implementada na plataforma.

24. 24
 Variável: Característica que deve ser comum para alguns produtos, mas não
todos. Deve ser explicitamente modelada de forma que possa ser aplicada em
um produto selecionado.
 Específica do produto: Uma característica que deve ser parte de um
produto. Normalmente com especialidades não exigidas pelo domínio, mas
por clientes individuais.
2.2.3. Níveis de Variabilidade
Svahnberg e Bosch (2000) argumentam que a variabilidade ocorre em vários
níveis, os quais são apresentados abaixo:
 Nível da linha de produto: Diz respeito à forma como os diferentes produtos
na SPL variam.
 Nível do produto: Trata de como a variabilidade está preocupada com a
arquitetura; da escolha dos componentes de um determinado produto e se
eles estão ligados entre si.
 Nível dos componentes: Neste nível, a variabilidade consiste em como
adicionar novas implementações da interface do componente, e também
como estes evoluem ao longo do tempo.
 Nível do subcomponente: Um componente contém um conjunto de features.
Neste nível, estas features são selecionadas para criar um componente para
um produto particular.
 Nível de código: Acontece no nível do desenvolvimento, e é onde a maior
parte da variabilidade entre produtos acontece.
2.2.4. Classificação das Variantes
Neste trabalho, é considerada a classificação das variantes associadas a um
ponto de variação de acordo com Czarnecki et. al. (2005) e Pohl et. al. (2005), que
segue:
 Mandatória: Deve ser selecionada para a aplicação se e somente se o ponto
de variação é parte da aplicação. Quando uma variante é obrigatória;

25. 25
 Opcional: Acontece quando uma variante pode, mas não precisa ser parte de
um produto da SPL. Quando uma variante pode ser necessária ou não;
 Alternativa Inclusiva: Quando se deve escolher uma ou mais variantes;
 Alternativa Exclusiva: Quando somente uma das variantes é necessária;
 Alternativa Mutuamente Inclusiva: Quando duas ou mais variantes são
sempre necessárias juntas.
Uma vez que a questão da variabilidade na SPLE foi esclarecida, faz-se
necessário esclarecer o funcionamento da SPL e como a variabilidade é aplicada no
contexto da Engenharia de requisitos do domínio.
2.3. Entendendo o funcionamento da SPLE
Uma vez apresentadas as definições referentes a features, core assets e às
formas da variabilidade, é possivel aprofundar um pouco mais a discussão sobre os
processos essenciais para o funcionamento da SPLE.
Apesar das inúmeras abordagens existentes, os processos de
desenvolvimento assemelham-se em muitos pontos. Em alguns casos, apenas a
nomenclatura de cada atividade é diferente.
A Figura 3, a seguir, mostra as três principais atividades envolvidas na SPLE,
segundo o modelo do SEI (Software Engineering Institute).
Figura 3: Principais atividades para SPLE adaptada de (NORTHROP e CLEMENTS, 2007)

26. 26
A seguir serão descritos os subprocessos e os componentes que estão
envolvidos nestas atividades principais, agora baseado no modelo de Pohl et. al.
(2005). A Figura 4, a seguir apresenta uma visão detalhada das etapas do ciclo de
desenvolvimento da SPLE segundo o modelo Pohl et. al. (2005).
Figura 4: Os subprocessos da Engenharia de Domínio e Engenharia de Aplicação. Figura adaptada de
(POHL et. al., 2005)
Como mostra a Figura 4 acima, em relação aos aspectos técnicos de
desenvolvimento, a SPLE divide-se basicamente em duas atividades: Engenharia de
Domínio e Engenharia de Aplicação. A única fase que considera aspectos não-
técnicos é a de Gerenciamento do Produto. Cada uma destas fases será mostrada
com mais detalhes nas seções seguintes.
2.3.1. Engenharia de Domínio
É nesta fase que acontece o entendimento do domínio e a construção (para o
reuso) de uma plataforma de artefatos reusáveis, a partir da qual serão
desenvolvidos os produtos. Segundo Czarnecki e Eisenecker (2005, p. 36), o
objetivo da Engenharia de Domínio:

27. 27
É realizar as atividades de coleta, organização e armazenamento de
experiências passadas no desenvolvimento de sistemas, ou partes do
sistema em um domínio específico, na forma de core assets e providenciar
meios adequados para reusá-los (recuperação, qualificação, adaptação,
montagem, entre outros) ao construir novos sistemas.
A seguir serão descritas as etapas desse processo segundo (POHL et. al.,
2005):
 Gerenciamento do produto: Trata normalmente de aspectos não técnicos,
aborda questões econômicas e de estratégia de mercado.
 Engenharia de requisitos do domínio: Engloba todas as atividades de
elicitação e documentação do que é similar e variável nos requisitos.
Ressaltamos que este trabalho foca na maneira como as ferramentas podem
apoiar na identificação, documentação, representação e outras atividades
necessárias na realização desta etapa.
 Projeto do domínio: Aborda todas as atividades para a construção da
arquitetura de referência, a qual fornece uma estrutura que apóia a arquitetura
de todas as aplicações da SPL.
 Realização do domínio: Trata em um nível de detalhe maior a arquitetura e a
implementação dos componentes reusáveis.
 Testes do domínio: É responsável pela verificação e validação dos
componentes reusáveis.
Os artefatos gerados no processo de Engenharia de Domínio são reusados
para desenvolver os produtos na próxima fase, que é Engenharia de Aplicação.
2.3.2. Engenharia de Aplicação
A Engenharia de Aplicação é fase em que os produtos são desenvolvidos
(com reuso) com base nos core assets construídos na Engenharia de Domínio.
As etapas da Engenharia de Aplicação são as seguintes (POHL et. al., 2005):
 Engenharia de requisitos da aplicação: Reúne todas as atividades para a
elicitação dos requisitos das aplicações.
 Projeto da aplicação: Engloba as atividades para produção da arquitetura
específica, baseada na arquitetura de referência. Seleciona e configura as
partes específicas do produto em questão.

28. 28
 Realização da aplicação: Desenvolve as aplicações específicas. As
principais preocupações são com a seleção e configuração dos componentes
para formar a aplicação.
 Testes da aplicação: Compreende as atividades necessárias para validar e
verificar a aplicação em relação à sua especificação.
Estas atividades são realizadas sob uma característica essencial no uso do
paradigma de SPL: a variabilidade, a qual deve ser explorada ao longo de todo o
ciclo de desenvolvimento (criação dos requisitos, na elaboração do modelo
arquitetural, nos modelos de documentos, entre outros).
2.4. Engenharia de Requisitos do Domínio
A Engenharia de Requisitos é a base para o desenvolvimento de softwares no
paradigma SSD, bem como a engenharia de requisitos do domínio é para a SPL.
Segundo Sommerville e Kotonya (1998) existem cinco atividades típicas dos
processos de engenharia de requisitos.
Captura dos Análise dos Especificação
requisitos requisitos dos requisitos
Verificação dos Gerenciamento
requisitos dos requisitos
Figura 5: Etapas do processo da Engenharia de Requisitos. Adaptada (SOMMERVILLE E KOTONYA,
1998)
Na construção de uma plataforma da SPL, essas atividades são executadas
na fase de Engenharia de Requisitos do Domínio, uma vez que é nesta fase que os
requisitos serão “transformados” em variantes. Sendo assim, os requisitos devem
estar elicitados antes, fazendo necessárias essas atividades, mesmo sendo de
processos de desenvolvimento tradicionais.

29. 29
Segundo Eberlein (2002), as maiores metas da engenharia de domínio são:
identificar o potencial dos produtos e seus requisitos, analisar esses requisitos,
projetá-los e implementá-los em um framework reutilizável.
Uma vez elicitados os requisitos e construído modelo de variabilidade
correspondente, a rastreabilidade pode ser aplicada, por exemplo, no mapeamento
de elementos da arquitetura, do código fonte, entre outros core assets, como casos
de teste.
Como exemplo de suporte a essa atividade, podemos citar a ferramenta
TARGET (Machado, 2007), na qual a rastreabilidade pode ser verificada na geração
de casos de testes a partir das especificações dos casos de uso.
Sendo assim, a identificação da variabilidade dos requisitos deve ser
especificada. Diante desta necessidade, a utilização de uma ferramenta que apóie
essa atividade é indispensável.
Na próxima seção, será apresentado o gerenciamento de variabilidade dos
requisitos e como as notações e técnicas podem ajudar, e também compreender
como as ferramentas poderão apoiar a execução dessa atividade.
2.4.1. Gerenciamento de Variabilidade nos Requisitos
Durante esta pesquisa, não foi encontrada uma definição formal, tendo em
vista as diferentes visões sobre requisitos entre as abordagens, porém, o processo
Gerenciamento de Variabilidade nos Requisitos pode ser considerado como uma
atividade, a qual está totalmente interligada e interage com as atividades de
Engenharia de Domínio e de Engenharia de Aplicação, apoiando a criação e a e
evolução do core assets e dos produtos (NORTHROP e CLEMENTS, 2007).
Segundo Schmid e John (2004) o gerenciamento de variabilidade é uma
preocupação que surge em todas as fases do ciclo de vida da SPLE, sendo a
principal característica que a distingue o paradigma de SPL das outras abordagens.
A Figura 6, a seguir, mostra o processo de gerenciamento de variabilidade de
acordo com Burgareli (2009). Ela mostra como os artefatos de entrada (por exemplo,
documento de requisitos) são processados em subfases (identificação,
especificação e implementação). Como saída, tem-se um modelo com a
variabilidade implementada, por exemplo, feature model.

30. 30
Figura 6: Processo de gerenciamento de variabilidade. Fonte: (BURGARELI, 2009, p. 131)
Ao longo dos anos, muitas abordagens para o gerenciamento de variabilidade
foram levantadas a fim de padronizar e garantir a eficiência do desenvolvimento da
SPLE. A Figura 7 mostra a evolução cronológica e os relacionamentos entre as
principais abordagens, de onde se originaram.
A pesquisa realizada por (CHEN et. al., 2009) retrata parte das diferentes
abordagens existentes. O método Feature-Oriented Domain Analysis – FODA
(KANG, 1990), por ser uns dos primeiros a tratar a análise do domínio, inclusive na

31. 31
representação da variabilidade dos requisitos, tem sido utilizado como base para
muitas abordagens. Seu método sofreu aprimoramentos ao longo dos anos e ainda
é a base de pesquisas atuais. O FODA trata a análise de domínio através de
features.
Esta grande quantidade de abordagens, porém, acaba por dificultar sua
utilização, uma vez que o interessado deve pesquisar com maiores detalhes e
analisar cada uma delas a fim de identificar a que melhor se adapta ao seu perfil.
Figura 7: Principais abordagens de gerenciamento de variabilidade. (CHEN et. al., 2009)
De uma maneira geral, estas abordagens foram desenvolvidas para tratar
problemas específicos, baseados em experiências pelas quais os autores passaram.
Tais experiências trouxeram consigo diferentes notações, técnicas e ferramentas
utilizadas no gerenciamento da variabilidade dos requisistos. Trataremos alguns
deles a seguir:
2.4.1.1. Notações
Notação é a forma como são representados os core assets.
Djebbi e Salinesi (2006) relatam em sua experiência, divergências nas
terminologias e nos processos, e a não padronização nas notações.

32. 32
Existem várias formas de representar a variabilidade dos requisitos, de acordo
com a abordagem adotada: casos de uso, classes UML 5, aspectos, serviços e
features. Sendo este último utilizado pela maioria das metodologias.
A Tabela 1 mostra as principais formas de representação gráfica do
gerenciamento de variabilidade, de acordo com revisão sistemática de literatura
realizada por (CHEN et. al., 2009b). É importante que haja independência de
notação e customização, a fim de facilitar sua adoção.
Uma das primeiras notações gráficas foi introduzida pelo método FODA
(KANG, 1990). Nele, permite-se a representação de features obrigatórias, opcionais
e alternativas e suas diversas relações com as variantes domínio, não somente dos
requisitos mas também da arquitetura e implementação. Mais tarde, esta notação foi
integrada a outros processos, como o Feature-Oriented Reuse Method - FORM
(GRISS, 1998) e outros, apresentados na Figura 7.
Tabela 1: Principais formas de representação do gerenciamento de variabilidade
Nome
Modelo de Feature
Usando UML e sua extensibilidade
Variabilidade expressa como parte de uma técnica que modela a
arquitetura do sistema
Usando linguagem natural
Variabilidade expressa como parte de uma técnica que modela os
componentes do sistema
X-frames organizados em camadas hierárquicas
Linguagem de domínio específico
Técnicas formais com base em matemática
Técnicas baseadas em ontologias
Solução a partir da perspectiva de orientação a aspectos
Gerenciamento de variabilidade ortogonal
Gerência de configuração baseado em modelagens
Usando técnicas de visualização da informação
Fonte: (CHEN et. al., 2009b)
Nessa integração, as construções básicas da notação permaneceram
inalteradas, entretanto algumas representações gráficas eram diferentes do proposto
5
Linguagem unificada de modelagem - Unified Modeling Language Specification, Version 2.0 (Final
Adopted Specification, ptc/03-02-08), 2003, www.omg.org/cgi-bin/doc?ptc/2003-08-02, acessado em
15/04/2011 às 02:32.

33. 33
pelo método FODA, devido aos novos problemas encontrados e novas tecnologias
que surgiram.
Svahnberg et al. (2001), estenderam a notação de Griss (1998) com algumas
novas construções. Foi acrescentada a possibilidade de expressar o tempo de
ligação, ou seja, o momento em que uma feature específica é realmente selecionada
para ser incluída em um produto. Isto resultou em redução dos esforços de
desenvolvimento e da ociosidade da SPL, e foi introduzida uma nova categoria de
features: features externas (features oferecidas por uma plataforma alvo de um
sistema).
Entretanto, a aplicabilidade de todas essas notações é limitada pelo fato de
que muitas delas necessitam de ferramentas de modelagem para fins específicos,
como a representação da cardinalidade em UML.
Neste trabalho, as principais ferramentas são apresentadas, especificando o
modelo de notação aos quais elas dão suporte.
2.4.1.2. Técnicas
A adoção de técnicas de visualização da variabilidade dos requisitos pode
ajudar os colaboradores a apoiar tarefas essenciais da SPL, como a Engenharia de
Requisitos do Domínio, e reforçar na compreensão do funcionamento e potencial da
SPLE.
A seguir são apresentadas algumas técnicas adotadas no funcionamento do
gerenciamento de variabilidade dentro da Engenharia de Requisitos do Domínio.
De acordo com Eberlein (2002) as técnicas do SSD em muito assemelham-se
com as da SPL, porém nesta última, existem preocupações relacionadas a outros
aspectos com respeito a variabilidade, similaridade, rastreabilidade, entre outros.
A Figura 8, a seguir, apresenta algumas técnicas utilizadas no gerenciamento
dos requisitos de acordo com Eberlein (2002).

34. 34
Figura 8: Técnicas de Gerenciamento dos requisitos. Adaptada (EBERLEIN, 2002)
Com todas essas atividades, os requisitos podem ser gerenciados de forma
muito eficiente com o apoio das ferramentas adequadas. É possível gerenciar vários
documentos, modelos e outros artefatos dos produtos e da plataforma sem muito
esforço. Além das mudanças nos requisitos, que podem ser facilmente geridas
através de técnicas de controle de versão.
Na próxima seção, será conhecido os aspectos que levam à adoção de
ferramentas para apoiar o gerenciamento de variabilidade dentro da Engenharia de
Requisitos do Domínio.
2.4.1.3. Ferramentas
Na Engenharia de Requisitos do Domínio, a visualização do modelo de
variabilidade é fundamental para a aplicação em produtos, na evolução da
plataforma, no apoio ao rastreabilidade, entre outras.
A visualização da árvore de variabilidade, junto com o modelo de decisão e
dos componentes, facilita o entendimento dos stakeholders no processo de decisão

35. 35
e na configuração do produto escolhido (BOTTERWECK, 2008, p. 2). Portanto, a
usabilidade deve ser um atributo a ser levado em consideração em uma ferramenta.
Há uma tendência a problemas de compreensão do funcionamento da SPLE,
tanto por parte dos clientes, como por engenheiros de software também. Isso se
deve a fatores como:
 A complexidade dos relacionamentos entre core assets.
 As fases do desenvolvimento da plataforma (Engenharia de requisitos do
domínio, Projeto do domínio, entre outras).
 Os subprocessos destas fases acima.
 As inúmeras abordagens para aplicação da SPLE
 Entre outros.
O gerenciamento das variações deve ser apoiado por ferramentas
automatizadas, que apóiem os diversos recursos da SPLE. Como, por exemplo, a
identificação de onde há exigências ou existência da aplicação da rastreabilidade,
entre outros.
Algumas abordagens podem acabar por exigirem o apoio de uma ferramenta
adequada à sua forma.
Beuche et. al. (2003), relata alguns fatores a serem considerados em uma
ferramenta, ou um conjunto delas, para que apóiem o processo de gerenciamento
de variabilidade como um todo. São elas:
 Fácil, e com modelos universais para representar como as variabilidades e
similaridades devem ser apoiadas.
 A variabilidade deve ser gerenciada em todos os níveis.
 A introdução de novas técnicas de expressar a variabilidade deve ser possível
e fácil.
Como a maioria das abordagens utiliza features como notação, sua
representação é normalmente compreendida. Porém, a descrição gráfica das
características das features requer ferramentas especiais para melhor entendimento.

36. 36
Fica demonstrado que inúmeras variáveis estão envolvidas no contexto das
ferramentas que apoiam o gerenciamento de variabilidade dos requisitos:
manutenção, implementação, usabilidade, entre outras.
No Capítulo 4 é apresentada uma análise das principais ferramentas que
apoiam o gerenciamento de variabilidade dentro da Engenharia de Requisitos do
Domínio, levando em consideração questões importantes surgidas ao logo dessa
pesquisa, como notações, técnicas, abordagens apoiadas pelas ferramentas, entre
outros aspectos.

37. 37
3. METODOLOGIA
Neste capítulo, é descrito como a pesquisa será realizada através da
descrição da natureza da pesquisa, da forma de abordagem, quanto aos objetivos, e
aos procedimentos técnicos. Ou seja, será descrita a metodologia utilizada neste
trabalho.
Segundo Silva (2006) metodologia cientifica é um conjunto de processos e
operações mentais que se deve empregar nas investigações. É a linha de raciocínio
adotada no processo de pesquisa, que para uma pesquisa seja efetuada é
necessário um conjunto de procedimentos intelectuais e técnicos.
3.1. Natureza da pesquisa
A natureza da pesquisa pode ser classificada quanto aos fins, quantos aos
meios e quanto à forma de abordagem. Segundo Silva (2006), a pesquisa científica
caracteriza-se pelo esforço ordenado de explicar ou compreender dos dados
encontrados.
3.1.1. Quanto aos fins
A pesquisa que será realizada neste trabalho é classificada, quanto aos fins,
como exploratória e descritiva.
Segundo Honorato (2004, p.96), a pesquisa exploratória “é a pesquisa que
tem como principal objetivo descobrir ideias, percepções, gerar hipóteses mais
precisas para um estudo aprofundado”. É realizada neste trabalho pela revisão de
literatura.
De acordo com Andrade (2006), na pesquisa descritiva o pesquisador
observa, registra, analisa, classifica e interpreta os fatos sem interferir neles. É
realizada neste trabalho a partir da análise das ferramentas.
3.1.2. Quanto aos meios
A pesquisa que é realizada neste trabalho é classificada, quanto aos meios,
como bibliográfica, a qual fornecerá o embasamento teórico para o estudo,
proporcionando mais familiaridade com o tema. Segundo Silva (2006) uma pesquisa

38. 38
bibliográfica é elaborada a partir de material já publicado, constituindo
principalmente de livros, artigos de periódicos e atualmente com material
disponibilizado na internet.
3.1.3. Formas de abordagem
Quanto à forma de abordagem, a pesquisa é essencialmente qualitativa.
Segundo Reis (2008, p.57), a pesquisa qualitativa “tem como objetivo
interpretar e dar significados aos fenômenos analisados. Nesta abordagem, os
resultados não são traduzidos em números (...) ou categorias homogêneas”.
3.2. Análise dos dados
A análise dos dados é realizada da seguinte maneira:
 Selecionar ferramentas a partir do trabalho de Lisboa (2008) – A
dissertação de Liana Lisboa, cujo título é “ToolDAy – A Tool for Domain
Analysis” foi realizada a partir de uma revisão sistemática de literatura sobre
ferramentas para Análise de Domínio em SPL.
Entre as ferramentas encontradas por Lisboa durante a revisão
sistemática de literatura, serão selecionadas aquelas que dêem suporte ao
gerenciamento de variabilidade dos requisitos.
Este trabalho foi escolhido devido à sua completude, no que se refere
às ferramentas encontradas.
 Pesquisar ferramentas para Engenharia de Requisitos em SPL – As
ferramentas serão pesquisadas no site de buscas Google 6 e em bibliotecas
científicas, entre as quais: Association for Computing Machinery (ACM)7,
Scientific Eletronic Library Online (SciELO)8, Institute of Electrical and
Electronic Engineers (IEEE Xplore)9. Uma vez que o conjunto de ferramentas
encontrado por Lisboa será utilizada como base para este trabalho, as
pesquisas serão realizadas focando em trabalhos posteriores a 2007.
6
http://www.google.com.br/
7
http://portal.acm.org/
8
http://www.scielo.org/php/index.php
9
http://ieeexplore.ieee.org/

39. 39
 Relacionar ferramentas – as ferramentas encontradas (a partir do trabalho
de Lisboa e pela pesquisa) serão mais profundamente estudadas e, em
seguida, relacionadas com os seguintes dados: Nome, Autor(es), Tipo de
Licença, Background, Disponibilidade do Código, Ano, Tipo e Abordagem em
que se baseia.
 Analisar documentação das ferramentas e catalogar funcionalidades –
As funcionalidades das ferramentas encontradas para gerenciamento de
variabilidade dos requisitos serão listadas a partir da análise da
documentação disponível.
 Propor funcionalidades – Por fim, funcionalidades complementares, que não
foram listadas nas ferramentas analisadas, também poderão ser propostas.

40. 40
4. UM ESTUDO SOBRE GERENCIAMENTO DE VARIABILIDADE DE
REQUISITOS EM LINHA DE PRODUTOS DE SOFTWARE
Neste capítulo, será exposto o processo realizado para a execução deste
trabalho. Inicialmente será descrita a pesquisa das ferramentas e as características
de cada uma delas e, em seguida, serão listadas suas funcionalidades.
4.1. Resultado das Pesquisas
A pesquisa retornou 244 resultados (Anexo 1). No entanto, a fim de delimitar
e refinar tais resultados, foram incluídos somente trabalhos publicados a partir de
2007, uma vez que este estudo também se utiliza do resultado da revisão
sistemática sobre ferramentas de Análise de Domínio realizada por Lisboa (2008).
O refinamento foi realizado inicialmente pela leitura dos títulos. Após esta
etapa, outros trabalhos foram excluídos pela leitura do resumo. Após estes passos,
restaram 59 trabalhos, considerados relevantes para o domínio desta pesquisa.
A Figura 9, abaixo, mostra a quantidade de trabalhos resultantes após a
execução de cada uma destas etapas.
• Trabalhos retornados após as buscas nas
244 bases científicas
• Trabalhos selecionados após a leitura do
65 título
• Trabalhos selecionados após a exclusão
62 dos repetidos
• Trabalhos selecionados após a leitura
59 dos resumos
• Trabalhos selecionados para leitura
59 completa
Figura 9: Número de trabalhos selecionados para leitura completa

41. 41
Além das pesquisas com as strings de buscas nas bases científicas (Anexo 1)
pesquisas esporádicas foram realizadas no Google.
A Figura 10 mostra a quantidade de trabalhos selecionados para leitura em
cada base científica pesquisada e no buscador Google.
Trabalhos selecionados para leitura
60
50 46
40
30 24
20
10
10
1 2
0
ACM IEEE Science Scopus Google
Direct
Figura 10: Número de trabalhos por base científica
4.1.1. Critérios de Seleção das Ferramentas
Uma vez selecionados os principais trabalhos faz-se necessário adotar
critérios para seleção das ferramentas, visando alcançar o objetivo geral desta
pesquisa, que é focado na Engenharia de Requisitos do Domínio. Os critérios estão
descritos a seguir.
 Critérios de inclusão: Os critérios estabelecidos para inclusão das
ferramentas encontradas para a análise:
o Ferramentas que apoiam a fase de Engenharia de Requisitos do
Domínio com alguma funcionalidade.
o Ferramentas com a documentação de suas funcionalidades ou
características.

42. 42
Estes critérios devem estar presentes em todas as ferramentas encontradas
na pesquisa, tendo em vista o grande número de ferramentas retornado.
 Critérios de exclusão: Os critérios estabelecidos para exclusão das
ferramentas encontradas para a análise:
o Ferramentas que apoiam outras fases da SPL que não a fase de
Engenharia de Requisitos do Domínio
o Ferramentas que servem de suporte somente para gerenciamento de
variabilidade, não apoiando as tarefas da Engenharia de Requisitos.
o Ferramentas sem documentação que trate de suas funcionalidades ou
características.
Os critérios foram aplicados após a leitura completa da documentação ou
referência da ferramenta, quando encontrados. Nas próximas seções é apresentado
as características e funcionalidades relevantes das principais ferramentas,
observando os critérios acima.
4.2. Investigação das Ferramentas
Nesta seção, é apresentada as ferramentas selecionadas as quais contêm as
funcionalidades relevantes na Engenharia de Requisitos de Domínio.
4.2.1. Ferramentas Selecionadas
Após a realização da pesquisa, foram encontradas 20 ferramentas que
apóiam direta ou indiretamente o Gerenciamento de Variabilidade na Engenharia de
Requisitos do Domínio, observando os critérios levantados na seção 4.1.1. Uma
síntese destas ferramentas e suas funcionalidades são mostradas a seguir, na
Tabela 2.

43. 43
Tabela 2: Informações das Ferramentas
Tipo de Código Abordagem
Nome Background Ano Tipo
licença Fonte Baseada
ArborCraft Gratuito Plugin Não 2008 Acadêmico Processo
disponível orientado a
features
Domain Não Stand-alone Não 1995 Industrial Processo
disponível disponível próprio
Doors Comercial Stand-alone Não 2005 Acadêmico Pohl et al.
disponível e (2005)
Industrial
Doppler Comercial Plugin Não 2008 Industrial Processo
disponível genérico
Dream Comercial Stand-alone Não 2005 Acadêmico Processo
disponível próprio
EA-Miner Gratuito Plugin Não 2007 Acadêmico Processo
disponível orientado a
features
FAMILIAR Não Plugin Não 2011 Acadêmico Processo
disponível disponível orientado a
features
FeatureIDE Gratuito Plugin Open- 2007 Acadêmico Processo
Source e Industrial orientado a
features
Feature Gratuito Plugin Open- 2004 Acadêmico FODA
Modeling Source
Plug-in
Odyssey Gratuito Stand-alone Não 2002 Acadêmico Processo
disponível próprio
OpenOME Gratuito Plugin Open- 2005 Acadêmico FODA
Source
Pluss Comercial Não Não 2006 Acadêmico PLUS
disponível disponível e Industrial
Pure:variants Comercial Plugin Não 2008 Acadêmico Extensão do
e Gratuito disponível e Industrial FODA
ReqSys Não Plugin Não 2011 Acadêmico Processo
disponível disponível orientado a
features
Requiline Gratuito Stand-alone Não 2005 Acadêmico FODA
disponível
SPLOT Gratuito Online Open- 2011 Acadêmico Processo
Source orientado a
features
ToolDAy Comercial Stand-alone Não 2008 Acadêmico Processo
disponível e Industrial orientado a
features
XVCL Gratuito Plugin Open- 2009 Acadêmico Processo
Source genérico
4.2.2. Características das Ferramentas
As funcionalidades e características selecionadas por este estudo foram
escolhidas após a leitura completa dos trabalhos. Além disto, os nomes de

44. 44
ferramentas citadas nos trabalhos foram pesquisados tanto nas bases científicas
utilizadas (já citadas na seção 4.2), quanto no tradicional método de busca Google, a
fim de encontrar a documentação referida das mesmas.
A seguir, uma breve descrição das principais características selecionadas
para análise desta pesquisa.
 Notação por XML: Representação dos requisitos no formato de XML. Essa
característica facilita a implantação da rastreabilidade.
 Notação por UML: Representação dos requisitos no formato de UML. Esse
formato é bastante utilizado na indústria, o que facilita adoção por parte dos
envolvidos.
 Notação por feature model: Esse modelo é o mais antigo (KANG, 1990) e
bastante utilizado pela maioria das abordagens e ferramentas, devido à sua
eficácia em representar a variabilidade dos requisitos.
 Notação de Serviços: Uma notação moderna. Poucas abordagens e
ferramentas tratam especificamente sobre requisitos em uma SPL orientada a
serviços.
 Notação de Aspectos: Representação de requisitos em forma de conjunto
(aspectos).
 Suporte a outros processos: Existem outras notações criadas para atender
necessidades específicas, ou extensões de abordagens clássicas, conforme
explanado em Chen (2009).
A Tabela 3, a seguir, mostra as ferramentas selecionadas, apontando suas
características.

45. Tabela 3: Ferramentas e suas características
Ferramentas
Feature Modeling
Pure:variants
FeatureIDE
OpenOME
FAMILIAR
ArborCraft
EA-Miner
Requiline
Odyssey
ToolDAy
MD-SPL
Doppler
ReqSys
Domain
SPLOT
Dream
Plug-in
Gears
Doors
Pluss
Caracteríticas
XVCL
Notação por XML ● ● ● ● ● ●
Notação por UML ● ● ● ●
Notação por features models ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●
Notação de Aspectos ● ● ●
Notação de Serviços ●
Suporte a outros processos ● ● ● ● ● ● ● ● ● ●

46. 45
4.2.3. Funcionalidades das Ferramentas
Após a análise das ferramentas, as funcionalidades mais relevantes foram
selecionadas para análise. Para esta seleção foram observados os critérios
estabelecidos na seção 4.1.1. A seguir é dada uma breve descrição destas
funcionalidades.
 Identificação Automática de Variantes: Esta funcionalidade permite que,
através da análise léxica e semântica do documento de requisitos, seja
gerada a árvore de features com suas dependências, tipos e classificação. A
identificação de potenciais variabilidades dentro do documento de requisitos
acontece na interpretação do mesmo, por meio de padrões de escrita, como
RDL10·, por exemplo.
 Identificação de Variantes: É a base para identificação dos requisitos.
Define o que comum e o que é específico da plataforma.
 Tipos das Variantes: Uma extensão do ponto anterior. Trata da observação
dos tipos, níveis e classificação, tomando por base os critérios de cada um
deles, pesquisados na seção 2.2.
 Modelo de Decisão: Suporte à seleção de quais requisitos serão usados no
produto derivado.
 Tratamento de RNF: Especificação dos Requisitos Não Funcionais.
 Checagem de consistência: Após a seleção dos requisitos, checar se os
mesmos estão conforme as regras estabelecidas no modelo geral (isto é, o
feature model).
 Rastreabilidade: Muitos aspectos devem levar consideração este ponto. Por
exemplo, a criação do feature model, a partir do documento de requisitos; a
geração automática de componentes da arquitetura, entre outros artefatos da
plataforma.
 Técnicas de Modelagem: A utilização de técnicas de modelagem para
representar o escopo dá uma visão geral das variações do domínio. Podendo
ser usados para isto tabelas, árvores, modelos, entre outros.
10
Requirements Description Language – padrão de escrita de requisitos que facilita a geração de
artefatos em ferramentas.

47. 46
 Features por Requisitos em Linguagem Natural: Os requisitos
representados em linguagem natural facilitam o entendimento por parte dos
clientes, no momento da seleção dos requisitos.
 Hierarquia de Variantes: Forma de representar o quanto os requisitos
dependem de outros e como estão relacionados.
 Operações em Variantes: Operações básicas de cadastro, alteração,
remoção, possibilitando operações de dependência, atribuições, construção
de árvores entre outras.
 Composição de Variantes: Conforme a evolução ou alterações necessárias,
fazer a composição entre duas ou mais variantes.
 Cardinalidade nas Variantes: Oferecer diferentes tipos de relações entre as
variantes. Como composição, generalização / especificação e implementação.
A Tabela 4, a seguir, mostra as ferramentas selecionadas e as
funcionalidades de cada uma delas.

48. Tabela 4: Ferramentas e suas funcionalidades
Ferramentas
Feature Modeling
FeatureIDE
Pure:variants
OpenOME
ToolDAy
ArborCraft
FAMILIAR
Doppler
EA-Miner
Requiline
Odyssey
MD-SPL
ReqSys
Domain
Gears
SPLOT
Plug-in
Dream
Doors
XVCL
Funcionalidades
Pluss
Identificação Automática de Variantes ● ● ● ● ● ● ●
Identificação de Variantes ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●
Modelo de Decisão ● ● ● ● ● ● ● ● ●
Tratamento de RNF ● ● ● ● ●
Checagem de consistência ● ● ● ● ● ● ● ● ● ● ●
Rastreabilidade ● ● ● ● ● ● ● ● ●
Técnicas de Modelagem ● ● ● ● ● ● ● ● ● ● ●
Variantes por Requisitos em Linguagem Natural ● ● ●
Hierarquia de Variantes ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●
Tipos de Variantes ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●
Operações em Variantes ● ● ● ● ● ●
Composição de Variantes ● ● ● ● ● ● ●
Cardinalidade nas Variantes ● ● ● ●

49. 48
4.3. Proposta
Além das funcionalidades encontradas durante a pesquisa, as quais foram
descritas acima, algumas novas funcionalidades, aprimoramentos e critério de
usabilidade foram sugeridos pelo autor desde trabalho. Estas porpostas foram
sugeridas a partir da observação das necessidades da Engenharia de Requisitos do
Domínio, observadas após a leitura dos artigos selecionados.
As Tabelas 5, 6 e 7, a seguir, mostram este levantamento:
Tabela 5: Funcionalidades propostas
Funcionalidade Descrição
Aprimoramentos da No monitoramento das variantes, podem ocorrer repetições e/ou
checagem de consistências clones de requisitos, estando descritos diferentes, mas realizando a
mesma tarefa. Especialmente em SPL, com processo orientado a
features, isto causa problemas em features alternativas. Uma das
soluções para isto está no refatoramento das variantes que estão com
esse comportamento.
Dinamicidade dos Possibilidade de alteração nas formas (mandatória, opcional, etc.) das
requisitos variantes.
Representação de todos os Um modelo representativo sob diferentes perspectivas (clientes,
requisitos da plataforma arquitetos, programadores) a fim de facilitar a compreensão do que está
disponível, ou do que se deseja ou precisa.
Controle de mudanças dos Algumas modificações que podem surgir ao longo da evolução da
requisitos plataforma, alterando assim o estado dos requisitos existentes e inclusão
de novos requisitos, operações do tipo: Novo requisito, alterar requisito,
apagar requisito, definir como oculto, definir com específico, definir como
em desuso.
Evolução Suporte à evolução da plataforma, representando as alterações das
variantes ao longo dos anos, bem como os novos requisitos que foram
incluídos na plataforma.
Composição das variantes Dependendo da abordagem adotada, um componente, um aspecto ou
dos requisitos serviço, podem compor um conjunto de componentes, aspectos ou
serviços.
SPL orientada a serviços Neste caso, trataremos alguns pontos específicos deste contexto:
 Operações de parametrização para controle de quais variantes
estarão ativas na aplicação dos serviços em cada produto.
 Descrição da composição dos requisitos que estão presentes
em cada serviço.
 A forma de modelagem específica dos tipos de variáveis nesse
ambiente e seus relacionamentos.

50. 49
Além das funcionalidades descritas anteriormente, que são intrínsecas à
Engenharia de Requisitos do Dominío, sob suas direfente formas de abordagem, a
seguir apresentaremos algumas funcionalidades e caracteríscas complementares.
Tabela 6: Funcionalidades complementares propostas
Funcionalidade Descrição
Automatização  Identificação automática das características das variantes, a partir
da análise léxica e semântica.
 Geração de código a partir da interpretação dos atributos dos
requisitos.
Medição de esforço A análise da complexidade na qual o requisito está inserido: a partir da
análise da quantidade de atributos, relacionamentos, tempo de vida, entre
outros.
Estimativa de tempo Na derivação de produtos, calcular a estimativa de tempo, levando em
consideração a quantidade dos novos requisitos específicos da aplicação e
os já existentes na plataforma.
Detecção de requisitos Ao longo tempo, monitorar a utilização dos requisitos e alertar sobre a não
em desuso utilização ou pouca utilização dos mesmos.
Suporte a evolução Ao longo da evolução, tratar das features em desuso na plataforma, com
resolução de conflitos no modelo após “exclusão” das mesmas
Análise de impacto Realizar checagem de impacto, no esforço de manutenção, financeiro,
entre outros, quanto à inserção, modificação, exclusão de uma ou mais
variantes.
A seguir, a proposta também dos critérios de usabilidade, os quais visam
proporcionar um ambiente mais fácil e intuitivo para os usuários da ferramenta. Os
requisitos identificados estão detalhados a seguir:
Tabela 7: Critérios de usabilidade
Critério Descrição
Interface amigável Fornecer uma interface amigável e intuitiva sobre os requisitos disponíveis na
ferramenta.
Help/Manual Fornecer uma explicação detalhada das funcionalidades da ferramenta
Importar/Exportar Funções de importação e exportação, gerando arquivos do tipo XML, XMI,
PDF, XLS entre outros, e permitindo a visualização dos dados em outras
ferramentas.

51. 50
4.4. Trabalhos Relacionados
Embora a análise sobre gerenciamento de variabilidade tenha sido objeto de
estudo de outros trabalhos, poucos autores têm lidado especificamente com as
ferramentas que dão suporte à Engenharia de Requisitos no contexto da SPL.
Este trabalho está relacionado à dissertação de Lisboa (2008) que trata das
ferramentas que apoiam a Análise de Domínio, a qual serviu de fonte para a
realização do presente estudo. Além deste, outros trabalhos foram relevantes e
adequados dentro da temática pesquisada. Como exemplos, podemos citar a
pesquisa de Khurum e Gorschek (2009), que realizaram uma Revisão Sistemática
da Literatura sobre as ferramentas de suporte à análise de domínio em SPL;
Várias ferramentas que apoiam a Engenharia de Requisitos do Domínio foram
identificadas durante esta pesquisa, conforme descrito no capítulo 4, e suas análises
serviram para o desenvolvimento da tabela de funcionalidades. Porém novas
necessidades podem surgir ao longo tempo, culminando em novas características e
funcionalidades.

52. 51
5. CONSIDERAÇÕES FINAIS
Neste trabalho foram apresentados insumos para um estudo sobre o
gerenciamento de variabilidade dos requisitos em Linha de Produtos de Software. A
fim responder a indagação: Quais são as principais características e funcionalidades
que devem compor uma ferramenta que apoie efetivamente o Gerenciamento de
Variabilidade de Requisitos do Domínio em Linha de Produtos de Software?
No desenvolvimento, foram relatados alguns conceitos-chave envolvidos na
SPL como core assets, plataforma, domínio, features entre outros. Após uma breve
contextualização envolvendo os processos de gerenciamento de variabilidade de
requisitos, foram mostradas as principais notações e técnicas envolvidas no contexto
da Engenharia de Requisitos do Domínio.
Por fim, foi apresentada uma análise das principais ferramentas e proposto
um conjunto de funcionalidades e características, a fim propor recursos para o
desenvolvimento de soluções mais abrangentes e adequadas para o problema da
Engenharia de Requisitos na SPLE.
Este capítulo está organizado nas seguintes subseções: limitações (5.1),
lições aprendidas (5.2) e recomendações para trabalhos futuros (5.3).
5.1. Limitações
Nesta seção, são mostrados os pontos do trabalho que de alguma forma,
limitam a pesquisa. São eles:
 Escassez de materiais que discutem explicitamente, a utilização de técnicas
para a Engenharia de Requisitos no paradigma da SPL.
 A dependência dos estudos publicados. A presente pesquisa ficou restrita aos
dados reportados nos trabalhos encontrados, não tendo utilizado outras
fontes, tais como questionários ou entrevistas.
 A quantidade de ferramentas. Mesmo com o alto número de ferramentas,
estas não davam suporte a todas as atividades necessárias para a execução
efetiva da Engenharia de Requisitos. Boa parte destas ferramentas atendia a
apenas uma necessidade específica.
 Grande quantidade de abordagens, que tratam com notações de diferentes
tipos, limitando a utilização das ferramentas.

53. 52
O surgimento de novas formas (notações, técnicas, métodos), limita o
resultado dessa pesquisa, uma vez que as ferramentas deverão ter novas
funcionalidades e características que demandam o desenvolvimento de novas
soluções. O presente trabalho, porém, serve com base para evolução das mesmas.
5.2. Lições Aprendidas
Vários conhecimentos e experiências foram adquiridos ao longo do
desenvolvimento desta pesquisa.
Durante a pesquisa, diferentes formas foram encontradas de lidar com
Engenharia de Requisitos, mesmo com a grande maioria utilizando o feature model
para representá-la, outras formas são utilizadas para entender a necessidade
específica de cada interessado. Portanto, a realização da SPLE pode ser utilizada
sob diferentes perspectivas de como empregar a Engenharia de Requisitos.
A seção de “Recomendações para trabalhos futuros” das pesquisas
selecionadas serviram de inspiração para a construção da tabela de funcionalidades
propostas, que poderá servir como base no desenvolvimento de novas soluções.
Um conjunto de funcionalidades e características, consistentes com as
necessidades no âmbito dos projetos de software modernos, foi construído para
facilitar as atividades no contexto da Engenharia de Requisitos do Domínio.
5.3. Recomendações para trabalhos futuros
A principal recomendação para trabalhos futuros é o desenvolvimento de
ferramentas que atendam às necessidades observadas durante a pesquisa. Várias
soluções podem ser desenvolvidas, de acordo com as novas perspectivas de
adoção da SPL, sejam orientadas a serviços, orientadas a aspectos ou novas
abordagens de tratamento dos componentes.
Além disto, outras funcionalidades que deem suporte a novas tecnologias e
modelos poderiam ser implementados para novas abordagens de SPL, a partir de
uma especificação nova de tratamento da variabilidade dos requisitos.
Esta pesquisa ainda pode evoluir para outras áreas envolvidas no ciclo de
desenvolvimento da SPL, como arquitetura, realização e testes, tanto na Engenharia
de Domínio, como na Engenharia de Aplicação.