um estudo sobre gerenciamento de variabilidade de requisitos em linha de produtos de software

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

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

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

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

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

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.

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.

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

.

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

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

Tabela 6: Funcionalidades complementares propostas ............................................ 50

Tabela 7: Critérios de usabilidade ............................................................................. 50

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

GVLPS – Gerenciamento de Variabilidade em Linha de produtos de Software

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

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

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

4.2.3. Funcionalidades das Ferramentas ......................................................... 46

4.3. Proposta ...................................................................................................... 49

4.4. Trabalhos Relacionados ............................................................................. 51

5. CONSIDERAÇÕES FINAIS ............................................................................... 52

5.1. Limitações ................................................................................................... 52

5.2. Lições Aprendidas....................................................................................... 53

5.3. Recomendações para trabalhos futuros ..................................................... 53

6. REFERÊNCIAS ................................................................................................. 55

ANEXO 1 – BUSCA NAS BASES CIENTÍFICAS .................................................. 59

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 - SSD).

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), que se assemelha a linha de produção comum, com divisão de atividades,

atores e sistematização de processos.

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

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

1 Conceito originado do toyotismo, que significa basicamente fabricar produtos

customizados com a economia de custo da linha de produção.

15

entanto, customizados e a baixo custo2. Pohl et. al. (2005) ressaltam ainda a

importância da SPL no ambiente moderno:

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.

2 http://www.sei.cmu.edu/productlines/frame_report/benefits.costs.htm. Acesso em: 11/05/2011.

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

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:

Outras fases do 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

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

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 é necessário conhecer outros conceitos

importantes envolvidos nessa abordagem.

Primeiramente, é preciso compreender um conceito muito presente nas

abordagens da SPL, que é o conceito de feature3. 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

3 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

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, pode-se compreender melhor a

definição de SPL de Clements e Northrop:

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 (SEI4).

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

4 http://www.sei.cmu.edu/productlines/frame_report/benefits.costs.htm. Acesso em:11/05/2011.

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.

22

2.2. Variabilidade Nesta seção, serão explanados os aspectos referentes à variabilidade, tais

como seus tipos, níveis e sua classificação.

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:

VaMoS5 (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.

5 VaMoS - Workshop Internacional sobre Modelagem de Variabilidade em Software Específicos

23

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.

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:

24

Comum: Uma característica (funcional ou não funcional) que pode ser

comum para todos os produtos da SPL e é implementada na plataforma.

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 associada a um

ponto de variação de acordo com Czarnecki et. al. (2005) e Pohl et. al. (2005), que

segue:

25

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;

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

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

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

Ressalta-se 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

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.

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.

Captura dos requisitos

Análise dos requisitos

Especificação dos requisitos

Verificação dos requisitos

Gerenciamento dos requisitos

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

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

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

representação da variabilidade dos requisitos, tem sido utilizado como base para

abordagens como FORM, FDL entre outras. 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

Existem várias formas de representar a variabilidade dos requisitos, de acordo

com a abordagem adotada: casos de uso, classes UML6, 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

6 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

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

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.

35

A visualização da árvore de variabilidade, junto com o modelo de decisão e

dos componentes, facilita o entendimento dos stakeholders 7no processo de decisão

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.

7 Pessoas interessadas no projeto (clientes, usuários finais, gerentes, programadores, entre outros).

36

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.

Fica mostrado 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.

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

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

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 Google8 e em bibliotecas

científicas, entre as quais: Association for Computing Machinery (ACM)9,

Scientific Eletronic Library Online (SciELO)10, Institute of Electrical and

Electronic Engineers (IEEE Xplore)11. Com foco em trabalhos posteriores a

2007, assemelhando-se em alguns pontos com o protocolo de pesquisa de

Revisão Sistemática de Literatura. Uma vez que o conjunto de ferramentas

encontrado por Lisboa será utilizada como base para este trabalho

8 http://www.google.com.br/

9 http://portal.acm.org/

10 http://www.scielo.org/php/index.php

11 http://ieeexplore.ieee.org/

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

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.

Figura 9: Número de trabalhos selecionados para leitura completa

•Trabalhos retornados após as buscas nas bases científicas 244

•Trabalhos selecionados após a leitura do título 65

•Trabalhos selecionados após a exclusão dos repetidos 62

•Trabalhos selecionados após a leitura dos resumos 59

•Trabalhos selecionados para leitura completa 59

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.

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.

46

1

10

2

24

0

10

20

30

40

50

60

ACM IEEE ScienceDirect

Scopus Google

Trabalhos selecionados para leitura

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, são apresentadas 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

Tabela 2: Informações das Ferramentas

Nome Tipo de licença

Background Código Fonte

Ano Tipo Abordagem

Baseada

ArborCraft Gratuito Plugin Não disponível

2008 Acadêmico Processo orientado a features

Domain Não disponível

Stand-alone Não disponível

1995 Industrial Processo próprio

Doors Comercial Stand-alone Não disponível

2005 Acadêmico e Industrial

Pohl et al. (2005)

Doppler Comercial Plugin Não disponível

2008 Industrial Processo genérico

Dream Comercial Stand-alone Não disponível

2005 Acadêmico Processo próprio

EA-Miner Gratuito Plugin Não disponível


FAMILIAR Não disponível

Plugin Não disponível


FeatureIDE Gratuito Plugin Open-Source


Processo orientado a features

Gears Comercial Stand-alone Não disponível

2010 Industrial Processo próprio

MD-SPL Gratuito Plugin Não disponível

2009 Acadêmico Model-Driven

Feature Modeling Plug-in

Gratuito Plugin Open-Source

2004 Acadêmico FODA

Odyssey Gratuito Stand-alone Não disponível

2002 Acadêmico Processo próprio

OpenOME Gratuito Plugin Open-Source


Pluss Comercial Não disponível

Não disponível


PLUS

Pure:variants Comercial e Gratuito



Extensão do FODA

ReqSys Não disponível



Requiline Gratuito Stand-alone Não disponível


SPLOT Gratuito Online Open-Source


ToolDAy Comercial Stand-alone Não disponível


Processo orientado a features

XVCL Gratuito Plugin Open-Source

2009 Acadêmico Processo genérico

44

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

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.

Ferramentas

Caracteríticas

Arb

orC

raft

Dom

ain

Doo

rs

Dop

ple

r

Dre

am

EA

-Min

er

FA

MIL

IAR

Fea

ture

IDE

Fea

ture

Mo

de

ling

Plu

g-in

Ge

ars

MD

-SP

L

Od

ysse

y

Op

enO

ME

Plu

ss

Pu

re:v

arian

ts

Req

Sys

Req

uili

ne

SP

LO

T

Too

lDA

y

XV

CL

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 ● ● ● ● ● ● ● ● ● ●

Tabela 3: Ferramentas e suas características

46

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

RDL12·, 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.

12

Requirements Description Language – padrão de escrita de requisitos que facilita a geração de artefatos em ferramentas.

47

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.

Ferramentas

Funcionalidades

Arb

orC

raft

Dom

ain

Doors

Dre

am

Dop

ple

r

EA

-Min

er

FA

MIL

IAR

Fea

ture

IDE

Featu

re

Mo

delin

g

Plu

g-in

Ge

ars

MD

-SP

L

Odyssey

OpenO

ME

Plu

ss

Pure

:vari

ants

ReqS

ys

Requ

iline

SP

LO

T

Too

lDA

y

XV

CL

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 ● ● ● ●

Tabela 4: Ferramentas e suas funcionalidades

49

4.3. Proposta

Além das funcionalidades encontradas durante a pesquisa, as quais foram

descritas na Tabela 4, algumas novas funcionalidades, aprimoramentos e critério de

usabilidade foram sugeridos pelo autor desde trabalho. Estas porpostas foram

sugeridas a parpltir 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 checagem de consistências

No monitoramento das variantes, podem ocorrer repetições e/ou 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 requisitos

Possibilidade de alteração nas formas (mandatória, opcional, etc.) das variantes.

Representação de todos os requisitos da plataforma

Um modelo representativo sob diferentes perspectivas (clientes, 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 requisitos

Algumas modificações que podem surgir ao longo da evolução da 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 dos requisitos

Dependendo da abordagem adotada, um componente, um aspecto ou 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

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 em desuso

Ao longo tempo, monitorar a utilização dos requisitos e alertar sobre a não 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

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

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.

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

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.

No entanto, as ferramentas open-source selecionadas nesta pesquisa podem

ser estudadas e implementadas novas funcionalidades, observando as propostas

sugeridas.

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.

54

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.

55

6. REFERÊNCIAS

BACHMANN, F. e CLEMENTS, P., Variability in Software Product Lines, Software

Engineering Institute, Pittsburgh, USA, Technical Report CMU/SEI-2005-TR-012,

2005.

BERGEY, J; Fisher, M; GALLAGHER, B; JONES, L; NORTHROP, L: Basic Concepts of Product Line Practice for the DoD. Technical Note CMU/SEI-2000-TN-001. Carnegie Mellon University., 2000. BEUCHE, D.; HOLGER, P.; WOLFGANG S. P.. Variability Management with

Feature Models. In Proceedings of the Software Variability Management Workshop,

pages 72–83, University of Groningen, The Netherlands. Technical Report IWI 2003-

7-01, February 2003.

BOTTERWECK, G.; Thiel, S.; NESTOR, D.; SAAD, bin A.; CAWLEY C.; Visual Tool

Support for Configuring and Understanding Software Product Lines, Lero, The

Irish Software Engineering Research Centre, 2008.

BURGARELI L. K, Gerenciamento de Variabilidade de Linha De Produtos de

Software com Utilização de Objetos Adaptáveis e Reflexão, Tese de doutorado,

Escola Politécnica da Universidade de São Paulo ,São Paulo, 2009.

CHEN, Lianping; MUHAMMAD, Ali Babar, CAWLEY Ciaran; A Status Report on

the Evaluation of Variability Management Approaches Lero, the Irish Software

Engineering Research Centre, University of Limerick, Ireland, 2009b.

CHEN, Lianping; MUHAMMAD, Ali Babar, NOUR, Ali; Variability Management in

Software Product Lines: A Systematic Review SPLC '09 Proceedings of the 13th

International Software Product Line Conference Carnegie Mellon University

Pittsburgh, PA, USA, 2009.

CLEMENTS P. e NORTHROP L., Software Product Lines: Practices and

Patterns, Addison-Wesley, pp. 608, 2001.

56

CZARNECKI, K.; EISENECKER, U.W. Generative Programming: Methods, Techniques, and Applications. Canada: Addison -Wesley, 2005. DJEBBI, O e SALINESI, C.; Criteria for Comparing Requirements Variability

Modeling Notations for Product Lines, In: Comparative Evaluation in

Requirements Engineering, 2006. CERE '06, 2006.

EBERLEIN, Chethana Kuloor Armin, Requirements Engineering for Software

Product Lines, The University of Calgary, 2500 University Drive, N.W, Calgary,

Alberta, Canada, 2002.

GRISS, M.; FAVARO, J.; D’ALLESSANDRO, M. Integrating Feature Modeling with

the RSEB. Proceedings of Fifth International Conference on Software Reuse

(ICSR’5), Victoria, Canada, pp. 76-85, June 1998.

HABERMANN, A. N.; FLON, L.; COOPRIDER, L.; Modularization and Hierarchy in

a Family of Operating Systems. Communications of the ACM, 19(5):266–272,

1976.

HONORATO, Gilson. Conhecendo o Marketing. Manole: Barueri, 2004.

KANG K., COHEN S., HESS J., NOVAK W., PETERSON A., Feature-Oriented

Domain Analysis (FODA) Feasibility Study. Technical report, CMU/SEI-90-TR-

021, November 1990

KHURUM, M.; GORSCHEK, T.; A systematic review of domain analysis

solutions for product lines, Journal of Systems and Software 82, 2009.

LINDEN, Van der; FRANK J., SCHMID, Klaus; ROMMES, Eelco. Software Product

Lines in Action: The Best Industrial Practice in Product Line Engineering,

Springer-Verlag Berlin Heidelberg, pp. 26, 2007.

LISBOA, L.B.; GARCIA, V.C.; LUCRÉDIO, D.; ALMEIDA, E.S. de; MEIRA, S.R.L;

Fortes, R.P.M.; A systematic review of domain analysis tools, Information and

Software Technology 52, 1 - 13, 2010.

57

MACHADO, P. e SAMPAIO, A. Automatic Test-Case Generation, Testing

Techniques in Software Engineering, Second Pernambuco Summer School on

Software Engineering, Recife, Brasil, 2007.

NEIGHBORS, J. M. The Draco Approach to Constructing Software from

Reusable Components. IEEE Transactions on Software Engineering, 10(5):564–

573, Sept. 1984.

NEIVA, D.F.S., RiPLE-RE: A Requirements Engineering Process for Software

Product Lines, M.Sc. Dissertação, Universidade Federal de Pernambuco, Brasil,

2009.

NORTHROP, L. M. e CLEMENTS, P.C. A Framework for Software Product Line

Practice. Version 5.0. Pittsburg. Software Engineering Institute, 2007. Disponível

em: < http://www.sei.cmu.edu/productlines/framework.html >. Acesso em: 28 fev.

2010 às 10:24.

PARNAS, D. L. Designing Software for Ease of Extension and Contraction. IEEE

Transactions on Software Engineering 5, 2, p. 128–138, 1979.

PARNAS, D. L. On the Design and Development of Program Families. IEEE

Transactions on Software Engineering, SE- 5(2):1–9, 1976.

POHL, K.; BÖCKLE, G.; VAN DER LINDEN, F.: Software Product Line

Engineering – Foundations, Principles, and Techniques. Springer, Heidelberg

2005.

REIS, Linda G.. Produção de monografia: da teoria à prática. 2ª Edição. Senac:

Brasília, 2008.

SCHMID, K.; e JOHN, I.; A Customizable Approach to Full Lifecycle Variability

Management, Sci. Comput. Program.,vol. 53, pp. 259-284, 2004.

58

SOMMERVILLE, I. e KOTONYA, G. Requirements Engineering: Processes and

Techniques. John Wiley e Son Ltd. 1998.

SOMMERVILLE, Ian; Software Engineering, Eighth Edition, Pearson Education

Limited, Republica da China, excluindo Hong Kong, Macau, and Taiwan, 2007

SVAHNBERG M. e BOSCH J.; Issues Conserning Variability in Software Product

Lines. In Development and Evolution of Software Architectures for Product

Families, Proceedings of International Workshop IW-SAPF- 3, Vol 1429 of Lecture

Notes in Computer Science, Springer, March 2000, pages 146-157, 2000.

SVAHNBERG, M.; VAN GURP J.; BOSCH J.; Research report: On the Notion of

Variability in Software Product Lines. Blekinge Institute of Technology Research

Report 2000:2, ISSN: 1103-1581, 2001.

WEISS, D.; CHI TAU, R. L. Software product-line engineering: a family-based

software development process. Boston: Addison-Wesley, 1999.

59

ANEXO 1 – BUSCA NAS BASES CIENTÍFICAS Base 1: http://www.scopus.com Data da busca: 10/05/2011 Strings utilizada: (("software product line") OR ("product families")) AND ("tool") AND ("variability management") AND ("requirements") AND ("domain engineering") Resultados: 10 Após exclusão pelo título: 4 Base 2: http://search.scielo.org/ Data da busca: 10/05/2011 Strings utilizadas: (("software product line") OR ("product families")) AND ("tool") AND ("variability management") AND ("requirements") AND ("domain engineering") Resultados: 0 Após exclusão pelo título: 0 Base 3: http://ieeexplore.ieee.org/ Data da busca: 10/05/2011 Strings utilizadas: (("software product line") OR ("product families")) AND ("tool") AND ("variability management") AND ("requirements") AND ("domain engineering") Resultados: 2 Após exclusão pelo título: 0 Base 4: http://www.sciencedirect.com/ Data da busca: 10/05/2011 Strings utilizadas: (("software product line") OR ("product families")) AND ("tool") AND ("variability management") AND ("requirements") AND ("domain engineering") Resultados: 13 Após exclusão pelo título: 10 BASE 5: http://portal.acm.org/ Data da busca: 10/05/2011 Strings utilizadas: (("software product line") OR ("product families")) AND ("tool") AND ("variability management") AND ("requirements") AND ("domain engineering") Resultados: 219 Após exclusão pelo título: 49

um estudo sobre gerenciamento de variabilidade de requisitos em linha de produtos de software

Documents