You are on page 1of 59

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 coorientaçã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. 1.2. 1.3. Contextualização......................................................................................... 14 Problema de Pesquisa ................................................................................ 15 Objetivos ..................................................................................................... 15

1.3.1. Objetivo Geral ........................................................................................ 15 1.3.2. Objetivos Específicos ............................................................................ 16 1.4. 1.5. 1.6. 1.7. 2. Justificativa ................................................................................................. 16 Escopo Negativo ......................................................................................... 17 Contribuições .............................................................................................. 17 Estrutura do Trabalho ................................................................................. 18

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. 4.2. Resultado das Pesquisas ............................................................................ 40 Investigação das Ferramentas .................................................................... 42

4.1.1. Critérios de Seleção das Ferramentas .................................................. 41 4.2.1. Ferramentas Selecionadas .................................................................... 42 4.2.2. Características das Ferramentas ........................................................... 44 4.2.3. Funcionalidades das Ferramentas......................................................... 46 4.3. 4.4. 5. Proposta...................................................................................................... 49 Trabalhos Relacionados ............................................................................. 51

CONSIDERAÇÕES FINAIS ............................................................................... 52 5.1. 5.2. 5.3. Limitações ................................................................................................... 52 Lições Aprendidas....................................................................................... 53 Recomendações para trabalhos futuros ..................................................... 53

6.

REFERÊNCIAS ................................................................................................. 55 ANEXO 1 – BUSCA NAS BASES CIENTÍFICAS .................................................. 59

14

1. 1.1.

INTRODUÇÃO 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, iniciouse 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ãoté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.

Captura dos requisitos

Análise dos requisitos

Especificação dos requisitos

Verificação dos requisitos

Gerenciamento 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

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 UML 6, 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

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

http://www.google.com.br/ 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.

244 65 62 59 59

• Trabalhos retornados após as buscas nas bases científicas • Trabalhos selecionados após a leitura do título • Trabalhos selecionados após a exclusão dos repetidos • Trabalhos selecionados após a leitura dos resumos • Trabalhos selecionados para leitura completa

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

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 40 30 20 10 1 0 ACM IEEE Science Direct Scopus Google 10 2 24 46

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

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 ArborCraft

Tipo de licença Gratuito

Background Plugin

Código Fonte Não disponível Não disponível Não disponível Não disponível Não disponível Não disponível Não disponível OpenSource Não disponível Não disponível OpenSource Não disponível OpenSource Não disponível Não disponível Não disponível Não disponível OpenSource Não disponível OpenSource

Ano 2008

Tipo Acadêmico

Abordagem Baseada Processo orientado a features Processo próprio Pohl et al. (2005) Processo genérico Processo próprio Processo orientado a features Processo orientado a features Processo orientado a features Processo próprio ModelDriven FODA

Domain Doors

Não disponível Comercial

Stand-alone Stand-alone

1995 2005

Industrial Acadêmico e Industrial Industrial Acadêmico Acadêmico

Doppler Dream EA-Miner

Comercial Comercial Gratuito

Plugin Stand-alone Plugin

2008 2005 2007

FAMILIAR

Não disponível Gratuito

Plugin

2011

Acadêmico

FeatureIDE

Plugin

2007

Acadêmico e Industrial Industrial Acadêmico Acadêmico

Gears MD-SPL Feature Modeling Plug-in Odyssey OpenOME Pluss Pure:variants ReqSys

Comercial Gratuito Gratuito

Stand-alone Plugin Plugin

2010 2009 2004

Gratuito Gratuito Comercial Comercial e Gratuito Não disponível Gratuito Gratuito

Stand-alone Plugin Não disponível Plugin Plugin

2002 2005 2006 2008 2011

Acadêmico Acadêmico Acadêmico e Industrial Acadêmico e Industrial Acadêmico

Processo próprio FODA PLUS Extensão do FODA Processo orientado a features FODA Processo orientado a features Processo orientado a features Processo genérico

Requiline SPLOT

Stand-alone Online

2005 2011

Acadêmico Acadêmico

ToolDAy

Comercial

Stand-alone

2008

Acadêmico e Industrial Acadêmico

XVCL

Gratuito

Plugin

2009

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.

Tabela 3: Ferramentas e suas características

Feature Modeling Plug-in

Ferramentas FeatureIDE FAMILIAR ArborCraft EA-Miner

Pure:variants

OpenOME

Requiline

Odyssey

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 ●

● ● ● ● ● ● ● ● ● ● ● ● ● ●

● ● ● ● ● ● ● ●

● ● ● ● ● ● ● ● ● ● ●

● ●

● ●

XVCL

Caracteríticas

ToolDAy

MD-SPL

Doppler

ReqSys

Domain

SPLOT

Dream

Gears

Doors

Pluss

● ●

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.

Tabela 4: Ferramentas e suas funcionalidades

Feature Modeling Plug-in

Ferramentas FeatureIDE

Pure:variants

OpenOME

ToolDAy
● ● ● ● ● ● ● ● ●

ArborCraft

FAMILIAR

Doppler

EA-Miner

Requiline

Odyssey

MD-SPL

ReqSys

Domain

Gears

SPLOT

Dream

Doors

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

● ● ●

● ● ● ● ●

● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●

● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●

Pluss

Funcionalidades

● ● ● ● ● ● ● ● ● ●

● ● ●

● ●

● ● ● ● ● ●

● ●

● ●

● ●

● ● ●

● ● ●

● ● ●

● ●

● ●

● ● ● ●

● ● ●

● ●

● ● ●

● ● ●

● ●

● ●

● ●

● ● ●

● ●

● ●

● ●

XVCL

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 Aprimoramentos da checagem de consistências

Descrição 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 Representação de todos os requisitos da plataforma Controle de mudanças dos requisitos

Possibilidade de alteração nas formas (mandatória, opcional, etc.) das variantes. 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. 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. 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.

Evolução

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 Automatização

Descriçã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

Estimativa de tempo

Detecção de requisitos em desuso Suporte a evoluçã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. 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. Ao longo tempo, monitorar a utilização dos requisitos e alertar sobre a não utilização ou pouca utilização dos mesmos. 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 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.

Análise de impacto

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 Interface amigável

Descrição Fornecer uma interface amigável e intuitiva sobre os requisitos disponíveis na ferramenta. Fornecer uma explicação detalhada das funcionalidades da ferramenta

Help/Manual

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-2000TN-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 20037-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-TR021, 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