Um estudo sobre o gerenciamento de variabilidade em LInha de produto de software

1,554
-1

Published on

variabilidade, requisito, spl, lps

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,554
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
39
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Um estudo sobre o gerenciamento de variabilidade em LInha de produto de software

  1. 1. UNIVERSIDADE DE PERNAMBUCO DIÓGENES RICARDO FREITAS DE OLIVEIRAUM ESTUDO SOBRE GERENCIAMENTO DE VARIABILIDADE DE REQUISITOS EM LINHA DE PRODUTOS DE SOFTWARE CARUARU 2011
  2. 2. UNIVERSIDADE DE PERNAMBUCO DIÓGENES RICARDO FREITAS DE OLIVEIRAUM ESTUDO SOBRE GERENCIAMENTO DE VARIABILIDADE DE REQUISITOS EM LINHA DE PRODUTOS DE SOFTWARE Monografia apresentada ao Curso de Sistemas de Informação da Universidade de Pernambuco como requisito parcial para a conclusão do curso de Sistemas de Informação, sob orientação do Prof. Msc. Humberto Rocha de Almeida Neto e co- orientação do Prof. D.Sc. Vinicius Cardoso Garcia. CARUARU 2011
  3. 3. Monografia de Graduação apresentada por Diógenes Ricardo Freitas de Oliveirado Curso de Graduação em Sistemas de Informação da Faculdade de Ciência eTecnologia de Caruaru – Universidade de Pernambuco, sob o título “Um EstudoSobre Gerenciamento de Variabilidade de Requisitos em Linha de Produtosde Software”, orientada pelo Prof. M.Sc. Humberto Rocha de Almeida Neto eco-orientada pelo Prof. D.Sc. Vinicius Cardoso Garcia e aprovada pela BancaExaminadora formada pelos professores: Prof. D.Sc. Fernando Carvalho Departamento de Sistemas de Informação / UPE Prof. M.Sc. Vinicius Cardoso Garcia Centro de Informática / UFPEVisto e permitida a impressão.Caruaru, XX de junho de 2011.Prof. Cícero GarroziCoordenador do Curso de Bacharelado em Sistemas de Informação daFaculdade de Ciência e Tecnologia de Caruaru – Universidade dePernambuco.
  4. 4. Aos meus familiares, irmãos, amigos e à minha amada.
  5. 5. AGRADECIMENTOS Como filho de quem sou, segundo João 1:12 (60D.C), expresso minhagratidão. Primeiramente ao meu Pai celestial, pelo privilégio de ser seu filho e gozarda sua presença em minha vida de forma tão intensa, inclusive na produção dessetrabalho. Obrigado meu Deus, por ser um Pai tão bondoso, que me ajudou aescrever, 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), semo 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 LunamarFreitas, pela criação que vocês me deram. A painho pelo apoio, sem o qual nãopoderia ter chegado aqui, por ser exatamente como o senhor é (essencial paraformaçã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 osenhor sobre meus problemas, inclusive da faculdade, que o senhor não entendiadireito 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, pelasdisciplinas e paciência. A vovó Aurora (95 anos) que sempre que me vê pergunta como estão osestudos (eu tinha que dizer algo novo). Aos Meus tios, em especial a tio Alexandre, vocês são muito importantes pramim. À minha amada Elyda Laisa, pela ajuda direta e indireta nesse trabalho, porter paciência com minhas cismas, me acalmando nos momentos de agonia e peloincentivo. Obrigado minha linda, amo você demais. Aos meus mestres Humberto Rocha e Vinícius Garcia pelas sugestões, idéiase críticas (foram muitas). Vinícius, olho para trás e vejo como evoluí com seus
  6. 6. comentários, suas contribuições foram essenciais pra o fim desse trabalho. Deusabenç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 escutareme 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) semprena hora certa... como Deus usou e usa vocês na minha vida! Graça e paz meusirmãos, amo vocês. Finalmente a todos aqueles que contribuíram direta ou indiretamente com ofim desse trabalho, meus sinceros agradecimentos.
  7. 7. RESUMO Linha de Produtos de Software é uma abordagem de desenvolvimento desoftware criada para atender diferentes segmentos de mercado. Esta abordagemtem apresentado grande aceitação no ambiente corporativo por permitir aconstrução de aplicações de forma mais eficiente através do reuso de componentescomuns, além de estar sendo extensivamente pesquisada por acadêmicos. Dentroda Linha de Produtos de Software, a variabilidade tem o papel de fornecer recursospara implementação dos produtos a partir de diferentes perspectivas, mantendo umbaixo custo de desenvolvimento e manutenção. Sendo assim, a adoção da Linha deProdutos apresenta-se como uma solução vantajosa. A Engenharia de Requisitos doDomínio é o ponto inicial para implementação da variabilidade. Este trabalho propõeum conjunto de funcionalidades e características que devem compor umaferramenta que dê suporte ao Gerenciamento da variabilidade dentro Engenharia deRequisitos em Linha de Produtos de Software, além de apresentar uma avaliaçãodas principais soluções.Palavras-chave: Linha de produtos de software. Variabilidade. Gerenciamento devariabilidade, Engenharia de Requisitos do Domínio.
  8. 8. ABSTRACT Software Product Line is a software development approach designed toaddress different market segments. This approach has had great acceptance in thecorporate environment by allowing the construction of applications more efficiently byreusing common components, besides being extensively researched by academics.In Software Product Line, the variability has a role in providing resources forimplementation of products from different perspectives, while maintaining a low costof development and maintenance. Thus, the adoption of Product Line presents itselfas an advantageous solution. The Domain Engineering Requirements is the startingpoint for implementation of the variability. This -work- proposes a set of functionalitiesand characteristics that should make a tool that supports the variability managementwithin the Requirements Engineering in Software Product Line and present anevaluation of main solutions.Keywords: Software Product Line, Variability. Variability Management, DomainEgineering Requirements.
  9. 9. LISTA DE FIGURASFigura 1: Custo para desenvolver N tipos de sistemas comparando o SSD comSPLE. Adaptada de Pohl (2005, p.10) ...................................................................... 21Figura 2: Ponto de variação e suas variantes ........................................................... 23Figura 3: Principais atividades para SPLE adaptada de (NORTHROP e CLEMENTS,2007) ......................................................................................................................... 25Figura 4: Os subprocessos da Engenharia de Domínio e Engenharia de Aplicação.Figura adaptada de (POHL et. al., 2005) .................................................................. 26Figura 5: Etapas do processo da Engenharia de Requisitos. Adaptada(SOMMERVILLE E KOTONYA, 1998) ...................................................................... 28Figura 6: Processo de gerenciamento de variabilidade. Fonte: (BURGARELI, 2009,p. 131) ....................................................................................................................... 30Figura 7: Principais abordagens de gerenciamento de variabilidade. (CHEN et. al.,2009) ......................................................................................................................... 31Figura 8: Técnicas de Gerenciamento dos requisitos. Adaptada (EBERLEIN, 2002).................................................................................................................................. 34Figura 9: Número de trabalhos selecionados para leitura completa .......................... 40Figura 10: Número de trabalhos por base científica .................................................. 41
  10. 10. LISTA DE TABELASTabela 1: Principais formas de representação do gerenciamento de variabilidade... 32Tabela 2: Informações das Ferramentas ................................................................... 43Tabela 3: Ferramentas e suas características........................................................... 44Tabela 4: Ferramentas e suas funcionalidades ......................................................... 47Tabela 5: Funcionalidades propostas ........................................................................ 48Tabela 6: Funcionalidades complementares propostas ............................................ 49Tabela 7: Critérios de usabilidade ............................................................................. 49
  11. 11. LISTA DE SIGLASSSD - Single System DevelopmentSPL - Software Product LineSPLE - Software Product Line EngineeringSEI - Software Engineering InstituteVaMoS - Variability Modeling of Software-intesive
  12. 12. SUMÁRIO1. 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 ................................................................................. 182. REFERENCIAL TEÓRICO ................................................................................ 19 2.1. Linha de Produtos de Software ................................................................... 19 2.1.1. Definição ................................................................................................ 19 2.2.2. Quando usar SPL ................................................................................... 20 2.2. Variabilidade ............................................................................................... 21 2.2.1. Conceitos ............................................................................................... 22 2.2.2. Tipos de Variabilidade ........................................................................... 23 2.2.3. Níveis de Variabilidade .......................................................................... 24 2.2.4. Classificação das Variantes ................................................................... 24 2.3. Entendendo o funcionamento da SPLE ...................................................... 25 2.3.1. Engenharia de Domínio ......................................................................... 26 2.3.2. Engenharia de Aplicação ....................................................................... 27 2.4. Engenharia de Requisitos do Domínio ........................................................ 28 2.4.1. Gerenciamento de Variabilidade nos Requisitos ................................... 293. METODOLOGIA ................................................................................................ 37 3.1. Natureza da pesquisa ................................................................................. 37 3.1.1. Quanto aos fins...................................................................................... 37 3.1.2. Quanto aos meios.................................................................................. 37 3.1.3. Formas de abordagem .......................................................................... 38 3.2. Análise dos dados .......................................................................................... 38
  13. 13. 4. UM ESTUDO SOBRE GERENCIAMENTO DE VARIABILIDADE DEREQUISITOS EM LINHA DE PRODUTOS DE SOFTWARE ................................... 40 4.1. Resultado das Pesquisas ............................................................................ 40 4.1.1. Critérios de Seleção das Ferramentas .................................................. 41 4.2. Investigação das Ferramentas .................................................................... 42 4.2.1. Ferramentas Selecionadas .................................................................... 42 4.2.2. Características das Ferramentas ........................................................... 43 4.2.3. Funcionalidades das Ferramentas......................................................... 45 4.3. Proposta...................................................................................................... 48 4.4. Trabalhos Relacionados ............................................................................. 505. CONSIDERAÇÕES FINAIS ............................................................................... 51 5.1. Limitações ................................................................................................... 51 5.2. Lições Aprendidas....................................................................................... 52 5.3. Recomendações para trabalhos futuros ..................................................... 526. REFERÊNCIAS ................................................................................................. 53 ANEXO 1 – BUSCA NAS BASES CIENTÍFICAS .................................................. 57
  14. 14. 141. INTRODUÇÃO1.1. Contextualização Desde o início do desenvolvimento de sistemas computacionais até os diasde hoje, muitos deles vêm sendo produzidos sob uma perspectiva de manufatura(Desenvolvimento de Sistema Único, do inglês Single System Development). A idéiade produção de software em massa, embora remota, já se mostrava presente emalguns trabalhos de pesquisadores que observavam a similaridade dos produtosdesenvolvidos. 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 asmesmas características estivessem dentro do mesmo domínio. Dessa forma, iniciou-se o conceito Linha de Produtos de Software (do inglês Software Product Lines –SPL). No contexto atual do desenvolvimento de sistemas, requisitos não-funcionaiscomo confiabilidade, manutenibilidade, reusabilidade, entre outros, tornam-se cadavez mais importantes. Segundo o Bergey (2000) várias empresas já ganharammelhorias quantificáveis no quesito eficiência, produtividade e qualidade através daabordagem 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 desenvolvimentode software que se utiliza de uma plataforma e da customização em massa. A SPL pode ser dividida em dois grandes processos: desenvolvimento daplataforma, que é um conjunto de artefatos reusáveis; e desenvolvimento dosprodutos, realizado a partir dos artefatos da plataforma. Em geral, o primeiroprocesso é denominado Engenharia de Domínio e o segundo, Engenharia deAplicação. De acordo com o Software Engineering Institute (SEI), alguns dos principaisbenefícios de uma SPL é o fornecimento de produtos de forma massificada e, noentanto, customizados e a baixo custo1. Pohl et. al. (2005) ressaltam ainda aimportância da SPL no ambiente moderno:1 http://www.sei.cmu.edu/productlines/frame_report/benefits.costs.htm. Acesso em: 11/05/2011.
  15. 15. 15 Portanto, atualmente há uma forte necessidade para adoção da engenharia linha de produtos, quando pode ser observado um domínio de software, especialmente quando o tamanho e a complexidade ultrapassam os limites do que é viável com as abordagens tradicionais. (POHL et. al, 2005, p.14). Em meio a esses pontos, a variabilidade dos artefatos é a questão chave parao desenvolvimento desse paradigma de desenvolvimento. Segundo Weiss e Chi Tau (1999), variabilidade é a forma como os membrosde 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 eferramentas que deem apoio ao desenvolvimento, manutenção, evolução entreoutros. No contexto dos requisitos, a fase da SPL responsável pelo gerenciamentoda variabilidade é a Engenharia de Requisitos do Domínio.1.2. Problema de Pesquisa Devido à importância do gerenciamento da variabilidade, este trabalho sepropõe a analisar as principais ferramentas que podem auxiliar no processo degerenciamento de variabilidade na Engenharia de Requisitos do Domínio da SPLE. Pretende-se, ao término deste trabalho, ter identificado subsídios suficientespara encontrar uma resposta para a seguinte indagação: Quais são as principaiscaracterísticas e funcionalidades que devem compor uma ferramenta que apóieefetivamente o Gerenciamento de Variabilidade de Requisitos do Domínio em Linhade Produtos de Software?1.3. Objetivos Os objetivos da pesquisa dividem-se em geral e específicos, os quais serãodefinidos a seguir.1.3.1. Objetivo Geral Propor um conjunto de funcionalidades que apóie o gerenciamento devariabilidade em SPL no contexto da Engenharia de Requisitos do Domínio,baseando-se no estado da arte da academia e melhores práticas da indústria.
  16. 16. 161.3.2. Objetivos Específicos Com a finalidade de atingir o objetivo geral são definidos os seguintesobjetivos 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 aexeqüibilidade da plataforma. Academicamente, esse estudo é importante pois irá identificar as principaisfuncionalidades para uma ferramenta que apóie o gerenciamento de variabilidadedos requisitos de domínio. E, através desta identificação, dando subsidio queacadêmicos possam desenvolver uma solução que atenda a necessidade dogerenciamento de variabilidade na SPLE. A contribuição prática deste trabalho está na identificação das principaisferramentas para o gerenciamento de variabilidade de requisitos envolvidas doprocesso de desenvolvimento da SPL, a fim de garantir a eficiência da plataforma dedesenvolvimento. Além disso, a identificação e análise das principais ferramentas envolvidas noprocesso de desenvolvimento dos requisitos poderão auxiliar as fábricas de softwarea escolher a que melhor se adéqua ao seu processo de desenvolvimento.
  17. 17. 171.5. Escopo Negativo A proposta deste trabalho está inserida em um contexto mais amplo, portantofaz-se necessário tratar alguns aspectos que não estão relacionados no escopodeste trabalho. Adicionalmente, as funcionalidades propostas para a ferramenta nãocompõem um conjunto absoluto de requisitos necessários, que devem sempre estarpresentes em qualquer ferramenta para SPL. Estes requisitos dependem dasnecessidades do ambiente onde a mesma será utilizada. Ressaltamos que os seguintes aspectos não fazem parte do escopo destetrabalho:  Processo de gerenciamento de variabilidade: embora seja feita uma breve explanação sobre a atuação do gerenciamento de variabilidade dos requisitos no contexto da SPLE, não serão tratadas, com detalhes, a variabilidade em outras fases da SPL - como arquitetura, implementação e testes.  Abordagem de SPL: mesmo sendo dada uma visão geral sobre as principais abordagens em SPL e uma descrição sintetizada das fases da SPLE, este trabalho não propõe um framework para desenvolvimento de SPL.  Ferramenta: apesar de serem levantadas as principais características e funcionalidades que devem estar presentes em uma ferramenta para o gerenciamento de variabilidade dos requisitos, tal ferramenta não será desenvolvida neste trabalho.1.6. Contribuições As principais contribuições deste trabalho são:  A compreensão dos pontos principais que estão evolvidos nos processos de gerenciamento de variabilidade de requisitos para Linha de Produtos de Software.  A pesquisa das ferramentas acadêmicas e industriais que dão suporte às atividades necessárias no gerenciamento de variabilidade em Linhas de Produto de Software no contexto da Engenharia de Requisitos do Domínio.
  18. 18. 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 deRequisitos em Linha de Produtos de Software, além do problema de pesquisa, e adefiniçã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 principaiscomponentes envolvidos no contexto da Engenharia de Requisitos em Linha deProdutos de Software. O capítulo 3 trata a forma de escrita deste trabalho, bem como método pararealização da pesquisa e a forma de análise de dados. O capítulo 4 trata dos resultados do trabalho, apresentando também ostrabalhos e ferramentas selecionados, a proposta de funcionalidades e os trabalhosrelacionados. Por fim, são expostas as considerações finais acerca do trabalho.
  19. 19. 192. REFERENCIAL TEÓRICO Este capítulo apresenta os conceitos básicos sobre Linha de Produtos deSoftware, Variabilidade e o Gerenciamento de Variabilidade de Requisitos doDomínio.2.1. Linha de Produtos de Software O termo linha de produtos de software surgiu como uma mescla de outrostermos. Nas décadas de 70 e 80, pesquisadores como Parnas (1976), Habermann(1976), Neighbors (1984) entre outros, já estudavam a oportunidade da utilização deuma forma de produção mais econômica e rápida, observando práticas da industriacomo produção em massa atrelada à customização. Era notada a similaridade desistemas de software, os quais recebiam o nome de família de sistemas ou famíliade produtos. Nas próximas seções serão conceituados os principais componentes eatividades envolvidas no processo de SPL e descritos os principais processos sobreo funcionamento da SPLE.2.1.1. Definição Uma linha de produtos compreende um conjunto de produtos que se destinama um segmento de mercado específico ou a uma missão particular (NORTHROP eCLEMENTS, 2007). Antes de melhor definir SPL precisamos conhecer outros conceitosimportantes envolvidos nessa abordagem. Primeiramente, é preciso compreender um conceito muito presente nasabordagens da SPL, que é o conceito de feature2. Segundo Czarnecki et. al. (2005)uma feature é um aspecto, qualidade ou característica de um software ou desistemas 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 detestes, entre outros artefatos. Este conjunto, denominado plataforma, é a base para2 Neste trabalho, o termo feature não é traduzido por entendermos que a tradução (característica), nalíngua portuguesa, não traduz o que tecnicamente o termo significa.
  20. 20. 20a linha de produtos de software, seus itens podem ser reusados por diferentesmembros da família de produtos e podem evoluir junto à plataforma. Com o entendimento desses conceitos, podemos compreender melhor adefinição de SPL de Clements e Northrop, bastante aceita na academia: Uma linha de produtos de software é um conjunto de sistemas com uso intensivo de reúso software que compartilham um conjunto de features comuns e gerenciáveis, que satisfazem às necessidades específicas de um segmento de mercado particular ou missão, e que são desenvolvidos a partir de um conjunto de core assets comuns, de modo planejado. (CLEMENTS E NORTHROP, 2001, p. 05). Uma diferença básica entre o processo SSD e SPLE é que o primeiro éfocado no contrato, somente no produto final e a ser entregue no prazo; já osegundo tem uma visão estratégica, enxerga a oportunidade de negócio emdeterminado segmento do mercado (conhecido dentro do processo de SPLE comodomínio). Na engenharia de software, o termo domínio é definido como uma parteespecializada do conhecimento, uma área de experiência ou um conjunto defuncionalidades que se relacionam (NORTHROP E CLEMENTS, 2007). Assim como deve ser analisada a viabilidade de aplicar qualquer mudança emuma empresa, seja um software, um processo de desenvolvimento, uma ferramenta,ou uma metodologia. Deve-se verificar quando a prática do paradigma daengenharia 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 odesenvolvimento de softwares que compartilham características comuns. Umaanálise de mercado e outros estudos podem ser feitos a fim de confirmar se autilização da abordagem é válida. Quando a fabricação de produtos de forma individual, sob um processo deSSD, acarretaria em um custo muito alto, a SPLE contribuiria, neste caso, para aredução deste custo, além de aumentar a qualidade dos produtos e valorizar ocapital humano (SEI3). Como em qualquer outra área, as mudanças nas práticas de engenharia desoftware têm que ser justificadas sob a perspectiva econômica. Essa é uma das3 http://www.sei.cmu.edu/productlines/frame_report/benefits.costs.htm. Acesso em:11/05/2011.
  21. 21. 21principais razões para a adoção da SPLE, que tem como forte argumento a reduçãodos custos. Segundo Pohl et. al. (2005), quando os artefatos de uma plataforma sãoreusados 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 uminvestimento inicial maior para criar a plataforma. Os custos serão reduzidos aolongo do desenvolvimento dos produtos, através da reutilização dos artefatos daplataforma. A Figura 1 mostra a diferença de custo ao desenvolver produtos, sob osdiferentes paradigmas de desenvolvimento (SSD e SPLE), apresentando o ponto dequebra existente quando aproximadamente três sistemas são desenvolvidos, aSPLE passa a ter menor esforço de acumulado, mesmo tendo um investimentoinicial 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 odesenvolvimento de produtos sob as diferentes abordagens, está na aplicaçãovariabilidade, que será conceituada a seguir.2.2. Variabilidade Nesta seção, serão explanados os aspectos referentes à variabilidade, taiscomo seus tipos, níveis e sua classificação.
  22. 22. 222.2.1. Conceitos Para o funcionamento da SPLE uma das questões-chave é a variabilidade. Aimportância deste assunto é tal que há um workshop internacional sobre o assunto:VaMoS4 (Variability Modeling of Software-intesive). O conceito de variabilidade éapresentado, a fim de compreender seu funcionamento na Engenharia de Requisitosdo Domínio. Bachmann e Clements (2005) definem variabilidade como a habilidade de umsistema ou core asset que, no ambiente de desenvolvimento, apóia a produção deum conjunto de artefatos que diferem entre si. O que significa a adaptação no usodos core assets em diferentes produtos. A variabilidade tem participação em todo o ciclo de vida do processo daSPLE, 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 dosprodutos 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 diversificarprodutos. Nela, a habilidade de um artefato ser configurado, customizado, estendidoou mudado para um uso específico em um contexto é dada através de algunsconceitos vistos adiante, de acordo com (BACHMANN e CLEMENTS 2005) e(LINDEN et. al., 2007):  Variante: Representa um objeto de variabilidade dentro dos artefatos de domínio, como um componente. São instâncias em um ponto de variação.  Ponto de variação: Representação de um objeto da variabilidade, onde se decide a escolha entre as variantes, normalmente enriquecida por informações contextuais do domínio. A Figura 2, a seguir, adaptada de Pohl et. al (2005, p. 153), mostra umexemplo de um ponto de variação e as variantes que podem ser escolhidas para ele.4 VaMoS - Workshop Internacional sobre Modelagem de Variabilidade em Software Específicos
  23. 23. 23 Figura 2: Ponto de variação e suas variantes  Variação: Forma como duas variantes diferem entre si.  Mecanismo de variabilidade: Responsável por implementar a variabilidade.  Dependência de variantes: Usado para denotar as diferentes escolhas da variante no ponto de variação, essa notação inclui cardinalidade e outros atributos.  Restrições de dependências das variantes: Descreve as dependências nas seleções das variantes, apresentam-se de duas formas: o Requerida: Indica se a variante depende de outra. o Exclusiva: Indica se a variante entra em conflito com outra. Devido à importância da variabilidade no funcionamento da SPL, a mesmadeve ser “definida, representada, explorada, implementada, evoluída, entre outros”(LINDEN et. al., 2007, p. 8). A seguir, outros pontos relevantes na compreensão davariabilidade.2.2.2. Tipos de Variabilidade Os core assets desenvolvidos podem ser utilizados tanto no domínio (naplataforma), quanto para produtos específicos. Segundo Linden et. al. (2007), avariabilidade pode ser dividida em três tipos:  Comum: Uma característica (funcional ou não funcional) que pode ser comum para todos os produtos da SPL e é implementada na plataforma.
  24. 24. 24  Variável: Característica que deve ser comum para alguns produtos, mas não todos. Deve ser explicitamente modelada de forma que possa ser aplicada em um produto selecionado.  Específica do produto: Uma característica que deve ser parte de um produto. Normalmente com especialidades não exigidas pelo domínio, mas por clientes individuais.2.2.3. Níveis de Variabilidade Svahnberg e Bosch (2000) argumentam que a variabilidade ocorre em váriosníveis, os quais são apresentados abaixo:  Nível da linha de produto: Diz respeito à forma como os diferentes produtos na SPL variam.  Nível do produto: Trata de como a variabilidade está preocupada com a arquitetura; da escolha dos componentes de um determinado produto e se eles estão ligados entre si.  Nível dos componentes: Neste nível, a variabilidade consiste em como adicionar novas implementações da interface do componente, e também como estes evoluem ao longo do tempo.  Nível do subcomponente: Um componente contém um conjunto de features. Neste nível, estas features são selecionadas para criar um componente para um produto particular.  Nível de código: Acontece no nível do desenvolvimento, e é onde a maior parte da variabilidade entre produtos acontece.2.2.4. Classificação das Variantes Neste trabalho, é considerada a classificação das variantes associadas a umponto de variação de acordo com Czarnecki et. al. (2005) e Pohl et. al. (2005), quesegue:  Mandatória: Deve ser selecionada para a aplicação se e somente se o ponto de variação é parte da aplicação. Quando uma variante é obrigatória;
  25. 25. 25  Opcional: Acontece quando uma variante pode, mas não precisa ser parte de um produto da SPL. Quando uma variante pode ser necessária ou não;  Alternativa Inclusiva: Quando se deve escolher uma ou mais variantes;  Alternativa Exclusiva: Quando somente uma das variantes é necessária;  Alternativa Mutuamente Inclusiva: Quando duas ou mais variantes são sempre necessárias juntas. Uma vez que a questão da variabilidade na SPLE foi esclarecida, faz-senecessário esclarecer o funcionamento da SPL e como a variabilidade é aplicada nocontexto 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 àsformas da variabilidade, é possivel aprofundar um pouco mais a discussão sobre osprocessos essenciais para o funcionamento da SPLE. Apesar das inúmeras abordagens existentes, os processos dedesenvolvimento assemelham-se em muitos pontos. Em alguns casos, apenas anomenclatura de cada atividade é diferente. A Figura 3, a seguir, mostra as três principais atividades envolvidas na SPLE,segundo o modelo do SEI (Software Engineering Institute). Figura 3: Principais atividades para SPLE adaptada de (NORTHROP e CLEMENTS, 2007)
  26. 26. 26 A seguir serão descritos os subprocessos e os componentes que estãoenvolvidos 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 dedesenvolvimento 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 dedesenvolvimento, a SPLE divide-se basicamente em duas atividades: Engenharia deDomí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á mostradacom 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 oreuso) de uma plataforma de artefatos reusáveis, a partir da qual serãodesenvolvidos os produtos. Segundo Czarnecki e Eisenecker (2005, p. 36), oobjetivo da Engenharia de Domínio:
  27. 27. 27 É realizar as atividades de coleta, organização e armazenamento de experiências passadas no desenvolvimento de sistemas, ou partes do sistema em um domínio específico, na forma de core assets e providenciar meios adequados para reusá-los (recuperação, qualificação, adaptação, montagem, entre outros) ao construir novos sistemas. A seguir serão descritas as etapas desse processo segundo (POHL et. al.,2005):  Gerenciamento do produto: Trata normalmente de aspectos não técnicos, aborda questões econômicas e de estratégia de mercado.  Engenharia de requisitos do domínio: Engloba todas as atividades de elicitação e documentação do que é similar e variável nos requisitos. Ressaltamos que este trabalho foca na maneira como as ferramentas podem apoiar na identificação, documentação, representação e outras atividades necessárias na realização desta etapa.  Projeto do domínio: Aborda todas as atividades para a construção da arquitetura de referência, a qual fornece uma estrutura que apóia a arquitetura de todas as aplicações da SPL.  Realização do domínio: Trata em um nível de detalhe maior a arquitetura e a implementação dos componentes reusáveis.  Testes do domínio: É responsável pela verificação e validação dos componentes reusáveis. Os artefatos gerados no processo de Engenharia de Domínio são reusadospara desenvolver os produtos na próxima fase, que é Engenharia de Aplicação.2.3.2. Engenharia de Aplicação A Engenharia de Aplicação é fase em que os produtos são desenvolvidos(com reuso) com base nos core assets construídos na Engenharia de Domínio. As etapas da Engenharia de Aplicação são as seguintes (POHL et. al., 2005):  Engenharia de requisitos da aplicação: Reúne todas as atividades para a elicitação dos requisitos das aplicações.  Projeto da aplicação: Engloba as atividades para produção da arquitetura específica, baseada na arquitetura de referência. Seleciona e configura as partes específicas do produto em questão.
  28. 28. 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 doparadigma de SPL: a variabilidade, a qual deve ser explorada ao longo de todo ociclo de desenvolvimento (criação dos requisitos, na elaboração do modeloarquitetural, 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 noparadigma SSD, bem como a engenharia de requisitos do domínio é para a SPL. Segundo Sommerville e Kotonya (1998) existem cinco atividades típicas dosprocessos de engenharia de requisitos. Captura dos Análise dos Especificação requisitos requisitos dos requisitos Verificação dos Gerenciamento requisitos dos requisitos Figura 5: Etapas do processo da Engenharia de Requisitos. Adaptada (SOMMERVILLE E KOTONYA, 1998) Na construção de uma plataforma da SPL, essas atividades são executadasna fase de Engenharia de Requisitos do Domínio, uma vez que é nesta fase que osrequisitos serão “transformados” em variantes. Sendo assim, os requisitos devemestar elicitados antes, fazendo necessárias essas atividades, mesmo sendo deprocessos de desenvolvimento tradicionais.
  29. 29. 29 Segundo Eberlein (2002), as maiores metas da engenharia de domínio são:identificar o potencial dos produtos e seus requisitos, analisar esses requisitos,projetá-los e implementá-los em um framework reutilizável. Uma vez elicitados os requisitos e construído modelo de variabilidadecorrespondente, a rastreabilidade pode ser aplicada, por exemplo, no mapeamentode elementos da arquitetura, do código fonte, entre outros core assets, como casosde teste. Como exemplo de suporte a essa atividade, podemos citar a ferramentaTARGET (Machado, 2007), na qual a rastreabilidade pode ser verificada na geraçãode casos de testes a partir das especificações dos casos de uso. Sendo assim, a identificação da variabilidade dos requisitos deve serespecificada. Diante desta necessidade, a utilização de uma ferramenta que apóieessa atividade é indispensável. Na próxima seção, será apresentado o gerenciamento de variabilidade dosrequisitos e como as notações e técnicas podem ajudar, e também compreendercomo as ferramentas poderão apoiar a execução dessa atividade.2.4.1. Gerenciamento de Variabilidade nos Requisitos Durante esta pesquisa, não foi encontrada uma definição formal, tendo emvista as diferentes visões sobre requisitos entre as abordagens, porém, o processoGerenciamento de Variabilidade nos Requisitos pode ser considerado como umaatividade, a qual está totalmente interligada e interage com as atividades deEngenharia de Domínio e de Engenharia de Aplicação, apoiando a criação e a eevolução do core assets e dos produtos (NORTHROP e CLEMENTS, 2007). Segundo Schmid e John (2004) o gerenciamento de variabilidade é umapreocupação que surge em todas as fases do ciclo de vida da SPLE, sendo aprincipal característica que a distingue o paradigma de SPL das outras abordagens. A Figura 6, a seguir, mostra o processo de gerenciamento de variabilidade deacordo 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 avariabilidade implementada, por exemplo, feature model.
  30. 30. 30 Figura 6: Processo de gerenciamento de variabilidade. Fonte: (BURGARELI, 2009, p. 131) Ao longo dos anos, muitas abordagens para o gerenciamento de variabilidadeforam levantadas a fim de padronizar e garantir a eficiência do desenvolvimento daSPLE. A Figura 7 mostra a evolução cronológica e os relacionamentos entre asprincipais abordagens, de onde se originaram. A pesquisa realizada por (CHEN et. al., 2009) retrata parte das diferentesabordagens existentes. O método Feature-Oriented Domain Analysis – FODA(KANG, 1990), por ser uns dos primeiros a tratar a análise do domínio, inclusive na
  31. 31. 31representação da variabilidade dos requisitos, tem sido utilizado como base paramuitas abordagens. Seu método sofreu aprimoramentos ao longo dos anos e aindaé a base de pesquisas atuais. O FODA trata a análise de domínio através defeatures. Esta grande quantidade de abordagens, porém, acaba por dificultar suautilização, uma vez que o interessado deve pesquisar com maiores detalhes eanalisar 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 tratarproblemas específicos, baseados em experiências pelas quais os autores passaram.Tais experiências trouxeram consigo diferentes notações, técnicas e ferramentasutilizadas no gerenciamento da variabilidade dos requisistos. Trataremos algunsdeles 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 nasterminologias e nos processos, e a não padronização nas notações.
  32. 32. 32 Existem várias formas de representar a variabilidade dos requisitos, de acordocom a abordagem adotada: casos de uso, classes UML 5, aspectos, serviços efeatures. Sendo este último utilizado pela maioria das metodologias. A Tabela 1 mostra as principais formas de representação gráfica dogerenciamento de variabilidade, de acordo com revisão sistemática de literaturarealizada por (CHEN et. al., 2009b). É importante que haja independência denotaçã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, opcionaise alternativas e suas diversas relações com as variantes domínio, não somente dosrequisitos mas também da arquitetura e implementação. Mais tarde, esta notação foiintegrada 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 permaneceraminalteradas, entretanto algumas representações gráficas eram diferentes do proposto5 Linguagem unificada de modelagem - Unified Modeling Language Specification, Version 2.0 (FinalAdopted Specification, ptc/03-02-08), 2003, www.omg.org/cgi-bin/doc?ptc/2003-08-02, acessado em15/04/2011 às 02:32.
  33. 33. 33pelo método FODA, devido aos novos problemas encontrados e novas tecnologiasque surgiram. Svahnberg et al. (2001), estenderam a notação de Griss (1998) com algumasnovas construções. Foi acrescentada a possibilidade de expressar o tempo deligação, ou seja, o momento em que uma feature específica é realmente selecionadapara ser incluída em um produto. Isto resultou em redução dos esforços dedesenvolvimento e da ociosidade da SPL, e foi introduzida uma nova categoria defeatures: features externas (features oferecidas por uma plataforma alvo de umsistema). Entretanto, a aplicabilidade de todas essas notações é limitada pelo fato deque muitas delas necessitam de ferramentas de modelagem para fins específicos,como a representação da cardinalidade em UML. Neste trabalho, as principais ferramentas são apresentadas, especificando omodelo 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 podeajudar os colaboradores a apoiar tarefas essenciais da SPL, como a Engenharia deRequisitos do Domínio, e reforçar na compreensão do funcionamento e potencial daSPLE. A seguir são apresentadas algumas técnicas adotadas no funcionamento dogerenciamento de variabilidade dentro da Engenharia de Requisitos do Domínio. De acordo com Eberlein (2002) as técnicas do SSD em muito assemelham-secom as da SPL, porém nesta última, existem preocupações relacionadas a outrosaspectos com respeito a variabilidade, similaridade, rastreabilidade, entre outros. A Figura 8, a seguir, apresenta algumas técnicas utilizadas no gerenciamentodos requisitos de acordo com Eberlein (2002).
  34. 34. 34 Figura 8: Técnicas de Gerenciamento dos requisitos. Adaptada (EBERLEIN, 2002) Com todas essas atividades, os requisitos podem ser gerenciados de formamuito eficiente com o apoio das ferramentas adequadas. É possível gerenciar váriosdocumentos, modelos e outros artefatos dos produtos e da plataforma sem muitoesforço. Além das mudanças nos requisitos, que podem ser facilmente geridasatravés de técnicas de controle de versão. Na próxima seção, será conhecido os aspectos que levam à adoção deferramentas para apoiar o gerenciamento de variabilidade dentro da Engenharia deRequisitos do Domínio.2.4.1.3. Ferramentas Na Engenharia de Requisitos do Domínio, a visualização do modelo devariabilidade é fundamental para a aplicação em produtos, na evolução daplataforma, no apoio ao rastreabilidade, entre outras. A visualização da árvore de variabilidade, junto com o modelo de decisão edos componentes, facilita o entendimento dos stakeholders no processo de decisão
  35. 35. 35e na configuração do produto escolhido (BOTTERWECK, 2008, p. 2). Portanto, ausabilidade 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 sedeve 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 ferramentasautomatizadas, que apóiem os diversos recursos da SPLE. Como, por exemplo, aidentificaçã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 ferramentaadequada à sua forma. Beuche et. al. (2003), relata alguns fatores a serem considerados em umaferramenta, ou um conjunto delas, para que apóiem o processo de gerenciamentode variabilidade como um todo. São elas:  Fácil, e com modelos universais para representar como as variabilidades e similaridades devem ser apoiadas.  A variabilidade deve ser gerenciada em todos os níveis.  A introdução de novas técnicas de expressar a variabilidade deve ser possível e fácil. Como a maioria das abordagens utiliza features como notação, suarepresentação é normalmente compreendida. Porém, a descrição gráfica dascaracterísticas das features requer ferramentas especiais para melhor entendimento.
  36. 36. 36 Fica demonstrado que inúmeras variáveis estão envolvidas no contexto dasferramentas que apoiam o gerenciamento de variabilidade dos requisitos:manutenção, implementação, usabilidade, entre outras. No Capítulo 4 é apresentada uma análise das principais ferramentas queapoiam o gerenciamento de variabilidade dentro da Engenharia de Requisitos doDomínio, levando em consideração questões importantes surgidas ao logo dessapesquisa, como notações, técnicas, abordagens apoiadas pelas ferramentas, entreoutros aspectos.
  37. 37. 373. METODOLOGIA Neste capítulo, é descrito como a pesquisa será realizada através dadescrição da natureza da pesquisa, da forma de abordagem, quanto aos objetivos, eaos procedimentos técnicos. Ou seja, será descrita a metodologia utilizada nestetrabalho. Segundo Silva (2006) metodologia cientifica é um conjunto de processos eoperações mentais que se deve empregar nas investigações. É a linha de raciocínioadotada 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 aosmeios e quanto à forma de abordagem. Segundo Silva (2006), a pesquisa científicacaracteriza-se pelo esforço ordenado de explicar ou compreender dos dadosencontrados.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 quetem como principal objetivo descobrir ideias, percepções, gerar hipóteses maisprecisas para um estudo aprofundado”. É realizada neste trabalho pela revisão deliteratura. De acordo com Andrade (2006), na pesquisa descritiva o pesquisadorobserva, registra, analisa, classifica e interpreta os fatos sem interferir neles. Érealizada neste trabalho a partir da análise das ferramentas.3.1.2. Quanto aos meios A pesquisa que é realizada neste trabalho é classificada, quanto aos meios,como bibliográfica, a qual fornecerá o embasamento teórico para o estudo,proporcionando mais familiaridade com o tema. Segundo Silva (2006) uma pesquisa
  38. 38. 38bibliográfica é elaborada a partir de material já publicado, constituindoprincipalmente de livros, artigos de periódicos e atualmente com materialdisponibilizado 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 objetivointerpretar e dar significados aos fenômenos analisados. Nesta abordagem, osresultados não são traduzidos em números (...) ou categorias homogêneas”.3.2. Análise dos dados A análise dos dados é realizada da seguinte maneira:  Selecionar ferramentas a partir do trabalho de Lisboa (2008) – A dissertação de Liana Lisboa, cujo título é “ToolDAy – A Tool for Domain Analysis” foi realizada a partir de uma revisão sistemática de literatura sobre ferramentas para Análise de Domínio em SPL. Entre as ferramentas encontradas por Lisboa durante a revisão sistemática de literatura, serão selecionadas aquelas que dêem suporte ao gerenciamento de variabilidade dos requisitos. Este trabalho foi escolhido devido à sua completude, no que se refere às ferramentas encontradas.  Pesquisar ferramentas para Engenharia de Requisitos em SPL – As ferramentas serão pesquisadas no site de buscas Google 6 e em bibliotecas científicas, entre as quais: Association for Computing Machinery (ACM)7, Scientific Eletronic Library Online (SciELO)8, Institute of Electrical and Electronic Engineers (IEEE Xplore)9. Uma vez que o conjunto de ferramentas encontrado por Lisboa será utilizada como base para este trabalho, as pesquisas serão realizadas focando em trabalhos posteriores a 2007.6 http://www.google.com.br/7 http://portal.acm.org/8 http://www.scielo.org/php/index.php9 http://ieeexplore.ieee.org/
  39. 39. 39 Relacionar ferramentas – as ferramentas encontradas (a partir do trabalho de Lisboa e pela pesquisa) serão mais profundamente estudadas e, em seguida, relacionadas com os seguintes dados: Nome, Autor(es), Tipo de Licença, Background, Disponibilidade do Código, Ano, Tipo e Abordagem em que se baseia. Analisar documentação das ferramentas e catalogar funcionalidades – As funcionalidades das ferramentas encontradas para gerenciamento de variabilidade dos requisitos serão listadas a partir da análise da documentação disponível. Propor funcionalidades – Por fim, funcionalidades complementares, que não foram listadas nas ferramentas analisadas, também poderão ser propostas.
  40. 40. 404. UM ESTUDO SOBRE GERENCIAMENTO DE VARIABILIDADE DEREQUISITOS EM LINHA DE PRODUTOS DE SOFTWARE Neste capítulo, será exposto o processo realizado para a execução destetrabalho. Inicialmente será descrita a pesquisa das ferramentas e as característicasde 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 delimitare refinar tais resultados, foram incluídos somente trabalhos publicados a partir de2007, uma vez que este estudo também se utiliza do resultado da revisãosistemá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 estaetapa, 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 aexecução de cada uma destas etapas. • Trabalhos retornados após as buscas nas 244 bases científicas • Trabalhos selecionados após a leitura do 65 título • Trabalhos selecionados após a exclusão 62 dos repetidos • Trabalhos selecionados após a leitura 59 dos resumos • Trabalhos selecionados para leitura 59 completa Figura 9: Número de trabalhos selecionados para leitura completa
  41. 41. 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 emcada base científica pesquisada e no buscador Google. Trabalhos selecionados para leitura 60 50 46 40 30 24 20 10 10 1 2 0 ACM IEEE Science Scopus Google Direct Figura 10: Número de trabalhos por base científica4.1.1. Critérios de Seleção das Ferramentas Uma vez selecionados os principais trabalhos faz-se necessário adotarcritérios para seleção das ferramentas, visando alcançar o objetivo geral destapesquisa, que é focado na Engenharia de Requisitos do Domínio. Os critérios estãodescritos a seguir.  Critérios de inclusão: Os critérios estabelecidos para inclusão das ferramentas encontradas para a análise: o Ferramentas que apoiam a fase de Engenharia de Requisitos do Domínio com alguma funcionalidade. o Ferramentas com a documentação de suas funcionalidades ou características.
  42. 42. 42 Estes critérios devem estar presentes em todas as ferramentas encontradasna 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 oureferência da ferramenta, quando encontrados. Nas próximas seções é apresentadoas características e funcionalidades relevantes das principais ferramentas,observando os critérios acima. 4.2. Investigação das Ferramentas Nesta seção, é apresentada as ferramentas selecionadas as quais contêm asfuncionalidades relevantes na Engenharia de Requisitos de Domínio. 4.2.1. Ferramentas Selecionadas Após a realização da pesquisa, foram encontradas 20 ferramentas queapóiam direta ou indiretamente o Gerenciamento de Variabilidade na Engenharia deRequisitos do Domínio, observando os critérios levantados na seção 4.1.1. Umasíntese destas ferramentas e suas funcionalidades são mostradas a seguir, naTabela 2.
  43. 43. 43 Tabela 2: Informações das Ferramentas Tipo de Código Abordagem Nome Background Ano Tipo licença Fonte Baseada ArborCraft Gratuito Plugin Não 2008 Acadêmico Processo disponível orientado a features Domain Não Stand-alone Não 1995 Industrial Processo disponível disponível próprio Doors Comercial Stand-alone Não 2005 Acadêmico Pohl et al. disponível e (2005) Industrial Doppler Comercial Plugin Não 2008 Industrial Processo disponível genérico Dream Comercial Stand-alone Não 2005 Acadêmico Processo disponível próprio EA-Miner Gratuito Plugin Não 2007 Acadêmico Processo disponível orientado a features FAMILIAR Não Plugin Não 2011 Acadêmico Processo disponível disponível orientado a features FeatureIDE Gratuito Plugin Open- 2007 Acadêmico Processo Source e Industrial orientado a features Feature Gratuito Plugin Open- 2004 Acadêmico FODA Modeling Source Plug-in Odyssey Gratuito Stand-alone Não 2002 Acadêmico Processo disponível próprio OpenOME Gratuito Plugin Open- 2005 Acadêmico FODA Source Pluss Comercial Não Não 2006 Acadêmico PLUS disponível disponível e Industrial Pure:variants Comercial Plugin Não 2008 Acadêmico Extensão do e Gratuito disponível e Industrial FODA ReqSys Não Plugin Não 2011 Acadêmico Processo disponível disponível orientado a features Requiline Gratuito Stand-alone Não 2005 Acadêmico FODA disponível SPLOT Gratuito Online Open- 2011 Acadêmico Processo Source orientado a features ToolDAy Comercial Stand-alone Não 2008 Acadêmico Processo disponível e Industrial orientado a features XVCL Gratuito Plugin Open- 2009 Acadêmico Processo Source genérico4.2.2. Características das Ferramentas As funcionalidades e características selecionadas por este estudo foramescolhidas após a leitura completa dos trabalhos. Além disto, os nomes de
  44. 44. 44ferramentas citadas nos trabalhos foram pesquisados tanto nas bases científicasutilizadas (já citadas na seção 4.2), quanto no tradicional método de busca Google, afim de encontrar a documentação referida das mesmas. A seguir, uma breve descrição das principais características selecionadaspara 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 suascaracterísticas.
  45. 45. Tabela 3: Ferramentas e suas características Ferramentas Feature Modeling Pure:variants FeatureIDE OpenOME FAMILIAR ArborCraft EA-Miner Requiline Odyssey ToolDAy MD-SPL Doppler ReqSys Domain SPLOT Dream Plug-in Gears Doors PlussCaracteríticas XVCLNotação por XML ● ● ● ● ● ●Notação por UML ● ● ● ●Notação por features models ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●Notação de Aspectos ● ● ●Notação de Serviços ●Suporte a outros processos ● ● ● ● ● ● ● ● ● ●
  46. 46. 454.2.3. Funcionalidades das Ferramentas Após a análise das ferramentas, as funcionalidades mais relevantes foramselecionadas para análise. Para esta seleção foram observados os critériosestabelecidos na seção 4.1.1. A seguir é dada uma breve descrição destasfuncionalidades.  Identificação Automática de Variantes: Esta funcionalidade permite que, através da análise léxica e semântica do documento de requisitos, seja gerada a árvore de features com suas dependências, tipos e classificação. A identificação de potenciais variabilidades dentro do documento de requisitos acontece na interpretação do mesmo, por meio de padrões de escrita, como RDL10·, por exemplo.  Identificação de Variantes: É a base para identificação dos requisitos. Define o que comum e o que é específico da plataforma.  Tipos das Variantes: Uma extensão do ponto anterior. Trata da observação dos tipos, níveis e classificação, tomando por base os critérios de cada um deles, pesquisados na seção 2.2.  Modelo de Decisão: Suporte à seleção de quais requisitos serão usados no produto derivado.  Tratamento de RNF: Especificação dos Requisitos Não Funcionais.  Checagem de consistência: Após a seleção dos requisitos, checar se os mesmos estão conforme as regras estabelecidas no modelo geral (isto é, o feature model).  Rastreabilidade: Muitos aspectos devem levar consideração este ponto. Por exemplo, a criação do feature model, a partir do documento de requisitos; a geração automática de componentes da arquitetura, entre outros artefatos da plataforma.  Técnicas de Modelagem: A utilização de técnicas de modelagem para representar o escopo dá uma visão geral das variações do domínio. Podendo ser usados para isto tabelas, árvores, modelos, entre outros.10 Requirements Description Language – padrão de escrita de requisitos que facilita a geração deartefatos em ferramentas.
  47. 47. 46  Features por Requisitos em Linguagem Natural: Os requisitos representados em linguagem natural facilitam o entendimento por parte dos clientes, no momento da seleção dos requisitos.  Hierarquia de Variantes: Forma de representar o quanto os requisitos dependem de outros e como estão relacionados.  Operações em Variantes: Operações básicas de cadastro, alteração, remoção, possibilitando operações de dependência, atribuições, construção de árvores entre outras.  Composição de Variantes: Conforme a evolução ou alterações necessárias, fazer a composição entre duas ou mais variantes.  Cardinalidade nas Variantes: Oferecer diferentes tipos de relações entre as variantes. Como composição, generalização / especificação e implementação. A Tabela 4, a seguir, mostra as ferramentas selecionadas e asfuncionalidades de cada uma delas.
  48. 48. Tabela 4: Ferramentas e suas funcionalidades Ferramentas Feature Modeling FeatureIDE Pure:variants OpenOME ToolDAy ArborCraft FAMILIAR Doppler EA-Miner Requiline Odyssey MD-SPL ReqSys Domain Gears SPLOT Plug-in Dream Doors XVCLFuncionalidades PlussIdentificação Automática de Variantes ● ● ● ● ● ● ●Identificação de Variantes ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●Modelo de Decisão ● ● ● ● ● ● ● ● ●Tratamento de RNF ● ● ● ● ●Checagem de consistência ● ● ● ● ● ● ● ● ● ● ●Rastreabilidade ● ● ● ● ● ● ● ● ●Técnicas de Modelagem ● ● ● ● ● ● ● ● ● ● ●Variantes por Requisitos em Linguagem Natural ● ● ●Hierarquia de Variantes ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●Tipos de Variantes ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●Operações em Variantes ● ● ● ● ● ●Composição de Variantes ● ● ● ● ● ● ●Cardinalidade nas Variantes ● ● ● ●
  49. 49. 484.3. Proposta Além das funcionalidades encontradas durante a pesquisa, as quais foramdescritas acima, algumas novas funcionalidades, aprimoramentos e critério deusabilidade foram sugeridos pelo autor desde trabalho. Estas porpostas foramsugeridas a partir da observação das necessidades da Engenharia de Requisitos doDomínio, observadas após a leitura dos artigos selecionados. As Tabelas 5, 6 e 7, a seguir, mostram este levantamento: Tabela 5: Funcionalidades propostasFuncionalidade DescriçãoAprimoramentos da No monitoramento das variantes, podem ocorrer repetições e/ouchecagem de consistências clones de requisitos, estando descritos diferentes, mas realizando a mesma tarefa. Especialmente em SPL, com processo orientado a features, isto causa problemas em features alternativas. Uma das soluções para isto está no refatoramento das variantes que estão com esse comportamento.Dinamicidade dos Possibilidade de alteração nas formas (mandatória, opcional, etc.) dasrequisitos variantes.Representação de todos os Um modelo representativo sob diferentes perspectivas (clientes,requisitos da plataforma arquitetos, programadores) a fim de facilitar a compreensão do que está disponível, ou do que se deseja ou precisa.Controle de mudanças dos Algumas modificações que podem surgir ao longo da evolução darequisitos plataforma, alterando assim o estado dos requisitos existentes e inclusão de novos requisitos, operações do tipo: Novo requisito, alterar requisito, apagar requisito, definir como oculto, definir com específico, definir como em desuso.Evolução Suporte à evolução da plataforma, representando as alterações das variantes ao longo dos anos, bem como os novos requisitos que foram incluídos na plataforma.Composição das variantes Dependendo da abordagem adotada, um componente, um aspecto oudos requisitos serviço, podem compor um conjunto de componentes, aspectos ou serviços.SPL orientada a serviços Neste caso, trataremos alguns pontos específicos deste contexto:  Operações de parametrização para controle de quais variantes estarão ativas na aplicação dos serviços em cada produto.  Descrição da composição dos requisitos que estão presentes em cada serviço.  A forma de modelagem específica dos tipos de variáveis nesse ambiente e seus relacionamentos.
  50. 50. 49 Além das funcionalidades descritas anteriormente, que são intrínsecas à Engenharia de Requisitos do Dominío, sob suas direfente formas de abordagem, a seguir apresentaremos algumas funcionalidades e caracteríscas complementares. Tabela 6: Funcionalidades complementares propostasFuncionalidade DescriçãoAutomatização  Identificação automática das características das variantes, a partir da análise léxica e semântica.  Geração de código a partir da interpretação dos atributos dos requisitos.Medição de esforço A análise da complexidade na qual o requisito está inserido: a partir da análise da quantidade de atributos, relacionamentos, tempo de vida, entre outros.Estimativa de tempo Na derivação de produtos, calcular a estimativa de tempo, levando em consideração a quantidade dos novos requisitos específicos da aplicação e os já existentes na plataforma.Detecção de requisitos Ao longo tempo, monitorar a utilização dos requisitos e alertar sobre a nãoem desuso utilização ou pouca utilização dos mesmos.Suporte a evolução Ao longo da evolução, tratar das features em desuso na plataforma, com resolução de conflitos no modelo após “exclusão” das mesmasAná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. 51. 504.4. Trabalhos Relacionados Embora a análise sobre gerenciamento de variabilidade tenha sido objeto deestudo de outros trabalhos, poucos autores têm lidado especificamente com asferramentas que dão suporte à Engenharia de Requisitos no contexto da SPL. Este trabalho está relacionado à dissertação de Lisboa (2008) que trata dasferramentas que apoiam a Análise de Domínio, a qual serviu de fonte para arealização do presente estudo. Além deste, outros trabalhos foram relevantes eadequados dentro da temática pesquisada. Como exemplos, podemos citar apesquisa de Khurum e Gorschek (2009), que realizaram uma Revisão Sistemáticada 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 foramidentificadas durante esta pesquisa, conforme descrito no capítulo 4, e suas análisesserviram para o desenvolvimento da tabela de funcionalidades. Porém novasnecessidades podem surgir ao longo tempo, culminando em novas características efuncionalidades.
  52. 52. 515. CONSIDERAÇÕES FINAIS Neste trabalho foram apresentados insumos para um estudo sobre ogerenciamento de variabilidade dos requisitos em Linha de Produtos de Software. Afim responder a indagação: Quais são as principais características e funcionalidadesque devem compor uma ferramenta que apoie efetivamente o Gerenciamento deVariabilidade de Requisitos do Domínio em Linha de Produtos de Software? No desenvolvimento, foram relatados alguns conceitos-chave envolvidos naSPL como core assets, plataforma, domínio, features entre outros. Após uma brevecontextualização envolvendo os processos de gerenciamento de variabilidade derequisitos, foram mostradas as principais notações e técnicas envolvidas no contextoda Engenharia de Requisitos do Domínio. Por fim, foi apresentada uma análise das principais ferramentas e propostoum conjunto de funcionalidades e características, a fim propor recursos para odesenvolvimento de soluções mais abrangentes e adequadas para o problema daEngenharia de Requisitos na SPLE. Este capítulo está organizado nas seguintes subseções: limitações (5.1),lições aprendidas (5.2) e recomendações para trabalhos futuros (5.3).5.1. Limitações Nesta seção, são mostrados os pontos do trabalho que de alguma forma,limitam a pesquisa. São eles:  Escassez de materiais que discutem explicitamente, a utilização de técnicas para a Engenharia de Requisitos no paradigma da SPL.  A dependência dos estudos publicados. A presente pesquisa ficou restrita aos dados reportados nos trabalhos encontrados, não tendo utilizado outras fontes, tais como questionários ou entrevistas.  A quantidade de ferramentas. Mesmo com o alto número de ferramentas, estas não davam suporte a todas as atividades necessárias para a execução efetiva da Engenharia de Requisitos. Boa parte destas ferramentas atendia a apenas uma necessidade específica.  Grande quantidade de abordagens, que tratam com notações de diferentes tipos, limitando a utilização das ferramentas.

×