UMA REVISÃO DE ENGENHARIA DE REQUISITOS PARA LINHA DE PRODUTO DE SOFTWARE

Transcrição

1 UMA REVISÃO DE ENGENHARIA DE REQUISITOS PARA LINHA DE PRODUTO DE SOFTWARE DANUZA FERREIRA SANTANA NEIVA Universidade Federal de Pernambuco RECIFE, 03 DE MARÇO DE 2008

2 DANUZA FERREIRA SANTANA NEIVA ENGENHARIA DE REQUISITOS PARA LINHA DE PRODUTO DE SOFTWARE Monografia apresentada ao Curso de pós-graduação em Ciência da Computação, Centro de Informática, Universidade Federal de Pernambuco, como requisito parcial para conclusão da disciplina Engenharia de Requisitos. Professor: Prof. Jaelson Brelaz de Castro Recife 03 de março de 2008

3 RESUMO Linhas de Produto de Software envolve um grande número de stakeholders com diferentes interesses e necessidades. Assim, seu contexto é mais complexo que o cenário de sistema único e requer soluções para evitar requisitos incompletos e inconsistentes, que são algumas das grandes causas de falhas em projetos de desenvolvimento de software. Estas soluções podem ser encontradas com um processo sistemático de engenharia de requisitos que permita uma correta elicitação, análise, especificação, validação e gerenciamento de requisitos. Contudo, a escolha de métodos e técnicas de engenharia de requisitos depende das diferentes situações da linha de produto. Diante disto, este trabalho busca investigar o cenário de Engenharia de Requisitos para Linhas de Produtos de Software, comparando as principais abordagens de Linhas de Produto encontradas na literatura, e apresentando métodos e técnicas de Engenharia de Requisitos direcionados para o contexto em análise. Palavras-chave: Engenharia de Requisitos, Linhas de Produto de Software, Engenahria de Domínio, Reuso de Software.

4 LISTA DE FIGURAS Figura 1: Atividades essenciais da Linha de Produto de Software [4] Figura 2: Ciclo de Vida do VODRD [27] Figura 3: Modelo de especificação de viewpoints [27] Figura 4: Modelo de Meta [28] Figura 5: Exemplo de variabilidade de interesses inicial [28] Figura 6: Exemplo de Árvore de Decomposição [28] Figura 7: Relação entre Metas, Cenários e Features [16] Figura 8: Ambiente de suporte para metas, cenários e casos de uso[17] Figura 9: Estrutura do processo de modelagem de metas e cenários [17] Figura 10: Metas e Cenários em nível de negócio e serviço [17] Figura 11: Relação entre metas, cenários e casos de uso [17] Figura 12: Exemplo de modelo de features [19] Figura 13: Modelo de Features [20] Figura 14: Exemplo de modelo de features para o domínio de segurança de casa [5] Figura 15: Tipos de Casos de Uso [3] Figura 16: Exemplo de ponto de extensão [3] Figura 17: exemplo de caso de uso de inclusão [3] Figura 18: Capturando informações legadas para construção de casos de uso [18] Figura 19: Visão geral da abordagem PuLSE-CaVE [18] Figura 20: Exemplo de elementos de casos de uso identificados em manual do usuário [18].45 Figura 21: Agrupamento de Features [5] Figura 22: Variabilidade em especificação de requisito textual [5] Figura 23: Modelando variabilidade ortogonal em requisitos textuais [5] Figura 24: Representação do Cenário do Caso de Uso [5] Figura 25: Representação no Diagrama de Seqüência [5] Figura 26: Representação em Diagrama de Caso de Uso [5] Figura 27: Sumário das atividades essenciais de ER LISTA DE TABELAS Tabela 1: Mapeamento das atividades, técnicas e métodos de RE nas abordagens de LPS Tabela 2: Tipo de relação com conjunção correspondente... 28

5 SUMÁRIO 1 INTRODUÇÃO LINHAS DE PRODUTO DE SOFTWARE (LPS) ENGENHARIA DE REQUISITOS PARA LPS REVISÃO DE ER NAS ABORDAGENS DE LPS RESULTADOS Atividades, Técnicas e Métodos Elicitação Análise e Negociação Especificação Validação Gerenciamento Pontos de Vista das Abordagens Pontos Fortes e Fracos TÉCNICAS E MÉTODOS DE ER PARA LPS Baseada em Pontos de Vista (Viewpoints) PLSVA VODRD Baseado em Metas (Goals) GVAA Baseado em Metas e Cenários GSM Orientado a Features FODA e FORM Baseada em Caso de Uso PLUS PuLSE-CAVE Modelo de Variabilidade Ortogonal CONCLUSÃO Sumário e Discussão Trabalhos Relacionados REFERÊNCIAS... 55

6 1 INTRODUÇÃO À medida que as indústrias de software aumentam a sua capacidade de produção, cresce também a demanda por sistemas mais complexos e com mais qualidade [1]. Desta forma, a competitividade dessas aumenta de acordo com a sua habilidade para reagir rapidamente às mudanças do mercado e aos requisitos dos usuários [2]. Existem várias formas de direcionar a demanda por mudanças, porém, uma das mais efetivas é o reuso de software [2]. Diversas tecnologias têm surgido para solucionar os problemas de reuso, mas, muitas dessas tecnologias, tais como desenvolvimento baseado em componentes e padrões de projeto, dão ênfase apenas ao reuso de código, contudo, o código representa cerca de 20% do total dos custos de desenvolvimento de software [3]. Diante deste cenário, a área de Linhas de Produto de Software (LPS) tem emergido como um paradigma de desenvolvimento de software importante e viável [4], cujo objetivo não é apenas o reuso de código, mas, principalmente, o reuso da arquitetura e dos requisitos, além de outros artefatos. Os principais objetivos de uma linha de produto são: a) redução dos custos de desenvolvimento; b) aumento da qualidade; e c) redução do tempo de entrega dos produtos [5]. Este paradigma de reuso é composto por algumas áreas práticas, entre elas a Engenharia de Requisitos (ER). ER identifica os problemas do domínio e fornece suporte ao desenvolvimento de soluções de LPS através da elicitação, análise, especificação, gerenciamento e validação dos requisitos do sistema. Esta prática é essencial no desenvolvimento de software e requer um esforço significante do projeto. Entretanto, existem muitos problemas nas atividades de ER, e a maioria é referente a fatores sociais e organizacionais. Requisitos de software têm sido reconhecidos repetidamente durante os últimos 25 anos por ser um problema real [21]. Suas atividades normalmente envolvem muitos stakeholders com diferentes necessidades, que pode resultar em conflitos de interesses. Estudos [22] mostram que incompletudes e inconsistência de requisitos são alguns dos grandes fatores para deficiência e cancelamento de projetos de software. No contexto de LPS, as atividades de engenharia de requisitos são mais complexas, pois envolvem mais produtos e stakeholders, e requer atenções para variabilidade e plataforma de reuso [4, 12]. Assim, o desenvolvimento

7 7 de LPS deve ser suportado por um processo de ER adequado para seu contexto, que permita a redução de riscos, custos e tempo de entrega, e aumente a qualidade dos produtos de trabalho. A elicitação e especificação das funcionalidades corretas para implementar o reuso é um desafio fundamental nas abordagens de linha de produto. Dois diferentes problemas têm sido direcionados nessas atividades. Um é o problema de capturar requisitos comuns para todos os membros da linha de produto, e requisitos válidos apenas para partes dos membros da linha. Um outro problema existente é especializar e instanciar requisitos genéricos da linha de produto em requisitos da aplicação para produto único. Para tratar esses problemas, a relação entre requisitos do produto e linha tem sido representada em abordagem de modelagem, que precisam suportar os conceitos de parametrização, especializarão, e generalização [18]. Considerando o contexto apresentado, este trabalho busca investigar o cenário de Engenharia de Requisitos nas abordagens de Linhas de Produto de Software, identificando as melhores práticas, pontos fortes e fracos. E em seguida apresentar técnicas e métodos direcionados para o cenário identificado. Assim, nas subseções seguintes são apresentados conceitos relevantes para o entendimento da Linha de Produtos de Software e de Engenharia de Requisitos neste contexto. A Seção 2 descreve o estado da arte de engenharia de requisitos nas abordagens de LPS. A Seção 3 apresenta as técnicas e métodos de ER para LPS. E por fim, na Seção 4 os resultados da análise são discutidos e sumarizados, seguidos pela apresentação dos trabalhos relacionados. 1.1 LINHAS DE PRODUTO DE SOFTWARE (LPS) Até 1998, o processo de reuso de software seguia apenas a direção da Engenharia de Domínio. Entretanto, nesse mesmo período, a área de Linhas de Produtos de Software (LPS) surgiu como uma nova tendência [4][6]. A Engenharia de Domínio(ED) corresponde a uma coleção de atividades requeridas para estabelecer e manter um conjunto de conhecimento e infra-estrutura técnica necessária para desenvolver e manter eficientemente uma família de aplicações de um dado domínio do problema [7]. Enquanto uma Linha de Produto de Software é um conjunto de sistemas intensivos de software, que compartilham um conjunto comum de features 1 para satisfazer necessidades especificas de um segmento de mercado particular, e que são desenvolvidos de um conjunto de artefatos básicos, em uma maneira bem definida [3]. Os dois conceitos possuem muitas semelhanças, e alguns estudos consideram ED e LPS como sinônimos [8, 9]. 1 Features são características do sistema visíveis ao usuário.

8 8 Entretanto, as principais diferenças entre elas têm direcionado para a consolidação de Linhas de Produtos de Software como um processo mais efetivo de desenvolvimento. Bayer et al. [6] define três razões básica que tornam a Engenharia de Domínio menos efetiva: (i) escopo equivocado da área de aplicação; (ii) lacunas de orientação operacional; e, (iii) foco excessivo nos assuntos organizacionais. As atividades essenciais de uma linha de produto são [4]: Desenvolvimento dos artefatos básicos (core assets), infra-estrutura essencial para o reuso, base para o desenvolvimento do produto em uma linha de produto. Exemplos de core assets são: arquitetura, componentes, especificação de requisitos, modelo do domínio, plano de testes, entre outros. Essa atividade é também conhecida como Engenharia do Domínio. Desenvolvimento dos produtos a partir dos core assets do domínio. Essa atividade é também chamada de Engenharia da Aplicação. Gerenciamento em nível organizacional e técnico da linha de produto. Essas três atividades são altamente iterativas e relacionadas, como pode ser visto na Figura 1. Muitas organizações iniciam a linha de produto desenvolvendo primeiro os artefatos básicos, ou seja, adotam abordagens pró-ativas. Outras organizações iniciam com apenas um ou um pequeno número de produtos, e então desenvolvem a linha de produtos (artefatos básicos e aplicações futuras) a partir deles, adotando abordagens reativas. Ambas as abordagens compartilham um dos grandes benefícios da linha de produto, a idéia que todos os membros da linha de produto são baseados em um único conjunto de artefatos. Com isso, o esforço de manutenção é reduzido para uma base de artefato único [10]. De acordo com Clements e Northrop [4], a Linha de Produto de Software permite que a organização ganhe vantagem competitiva devido ao aumento da produtividade em larga escala, aumento da qualidade, redução dos custos, redução do tempo de entrega, e minimização dos riscos dos produtos. Contudo, iniciar uma linha de produtos de software é uma decisão de negócio que não deveria ser feita aleatoriamente. Antes de começar a desenvolver uma linha de produto, a organização deve estabelecer objetivos sólidos e específicos para adotar essa estratégia de reuso. Uma linha de produtos de software requer um investimento inicial como também custos progressivos com a manutenção dos core assets. Inicialmente, os custos da linha de produtos são um pouco maiores que os benefícios, pois, muitos dos custos estão associados com a sua implantação. Os benefícios, por outro lado, aumentam a cada entrega de produto. Uma vez a abordagem estabelecida, a produtividade da organização acelera, e então os benefícios superam os custos. Mudanças tecnológicas, e em

9 9 práticas organizacionais e gerenciais são barreiras para a adoção bem sucedida da linha de produtos. O sucesso da prática de linha de produtos é uma combinação cuidadosa de aprimoramento tecnológico, organizacional, do processo e dos negócios [4]. Figura 1: Atividades essenciais da Linha de Produto de Software [4]. Áreas práticas da engenharia de software, tais como, engenharia de requisitos, apóiam o desenvolvimento das atividades essenciais da linha de produtos, fornecendo técnicas apropriadas para os tipos de abordagens (pró-ativa ou reativa). Na seção seguinte é apresentada uma visão geral das características principais de engenharia de requisitos para linhas de produtos de software, contextualizando as diferenças da engenharia de requisitos tradicional. 1.2 ENGENHARIA DE REQUISITOS PARA LPS Requisitos são definidos como uma especificação do que deve ser implementado no sistema. Descrevem como o sistema deve se comportar, informações do domínio de aplicação, restrições da operação do sistema, ou especificações de uma propriedade ou atributo do sistema [1]. A Engenharia de Requisitos fornece os mecanismos apropriados para entender os desejos do cliente, analisar as suas necessidades, avaliar a sua viabilidade, negociar uma melhor solução, validá-la, especificá-la de maneira não ambígua, e gerenciar os requisitos como eles são transformados em um sistema operacional [11]. O termo engenharia implica que

10 10 técnicas sistemáticas e repetíveis devem ser usadas para assegurar que os requisitos do sistema sejam completos, consistentes e relevantes [1]. No contexto de linha de produtos, os requisitos definem as aplicações e suas features, e são divididos em dois grupos: os requisitos comuns, que representam os requisitos de toda a linha de produtos; e os requisitos variáveis, que são específicos para um subconjunto de produtos. Requisitos comuns são representados com pontos de variação que podem ser instanciados para criar requisitos específicos do produto. As principais diferenças entre engenharia de requisitos para linha de produtos e para sistema único são [4, 5, 13]: Elicitação de Requisitos para linha de produtos foca no escopo, e deve capturar antecipadamente as variações esperadas ao longo do ciclo de vida da linha de produtos. Em geral, o processo de elicitação de requisitos para linhas de produtos envolve um maior número de stakeholders comparado com a elicitação de requisitos de um sistema único. Análise de Requisitos para linhas de produtos envolve a identificação de variações e similaridades nos requisitos elicitados, e a identificação de oportunidades para o extenso reuso com a linha de produtos. Esta análise deve envolver um mecanismo de resposta mais vigoroso para as solicitações, apontando onde um sistema particular pode encontrar economia se estiver hábil para usar mais requisitos comuns e menos requisitos únicos. Capturar requisitos para um grupo de sistemas pode requerer uma análise sofisticada e negociação intensiva para a escolha de requisitos comuns e variáveis. A análise de requisitos também deve identificar conflitos nos novos requisitos, analisando seu impacto na arquitetura do domínio. Esses conflitos devem ser resolvidos não apenas de um ponto de vista lógico, mas também considerando assuntos do mercado e econômicos. Especificação de Requisitos permite agora documentar os requisitos comuns da linha de produtos e os requisitos específicos dos produtos. A especificação dos requisitos comuns da linha de produtos deve incluir expressões simbólicas que permita que os requisitos específicos de um produto possam ser preenchidos, expandidos ou instanciados. Verificação de Requisitos inclui uma ampla concentração de revisores e ocorre em estágios. Em primeiro lugar, os requisitos comuns da linha de produtos devem ser verificados. Em seguida, quando um produto é desenvolvido ou atualizado, os

11 11 requisitos específicos do produto devem ser verificados. Nesta fase, os requisitos comuns da linha de produtos também devem ser verificados para certificar-se de que eles fazem sentido para este produto. Gerenciamento de Requisitos deve apresentar subsídios para tratar as atividades comuns e variáveis do processo de engenharia de requisitos. Políticas de gerenciamento de mudanças devem prever um mecanismo formal para propor alterações na linha de produtos e apoiar a avaliação sistemática do modo como alterações propostas terão um impacto na linha. Políticas de gerenciamento de mudanças governam como as mudanças nos requisitos da linha de produtos são propostas, analisadas e revisadas. O acoplamento entre os requisitos da linha de produtos e os core assets é identificada através da utilização de relações de rastreabilidade entre os requisitos e seus core assets associados. As práticas de RE inevitavelmente variam de uma organização para outra. Alguns fatores contribuem para a variabilidade do processo de RE, tais como maturidade técnica da organização, cultura organizacional, e domínio de aplicação [1]. Em linha de produtos existem muitas situações que influenciam diretamente a engenharia de requisitos, tais como [6, 12]: Contexto inicial: a linha de produto pode começar do zero; pode ser introduzida enquanto alguns produtos estão sendo desenvolvidos; ou ainda pode ser iniciada a partir da reengenharia de sistemas existentes. A estratégia de elicitação dos requisitos é influenciada pelo contexto em que a linha de produtos é iniciada. Orientação do mercado: a linha de produtos pode ser construída para um segmento de mercado especifico, sem um cliente concreto em mente; ou pode ser direcionada para projetos individuais de clientes. Esta decisão influencia a identificação dos stakeholders envolvidos na engenharia de requisitos, bem como a estratégia de elicitação a ser adotada. Tipo do produto: produtos individuais que complementam outros produtos para formar um software integrado (suite); ou sistemas similares, com funcionalidades comuns, direcionados para um segmento do mercado ou perfil de cliente. Assim como as outras situações anteriormente, o tipo de produto influencia no processo de elicitação dos requisitos. Maturidade do domínio: o domínio pode ser antigo, e por isso ser entendido facilmente; ou o domínio pode ser novo, podendo dificultar o entendimento do

12 12 problema. Assim, o nível de maturidade do domínio afeta diretamente a elicitação dos requisitos. Estabilidade do domínio: domínio estável, ou seja, não espera sua mudança em um futuro próximo; ou um domínio que muda constantemente. A estabilidade do domínio deve ser analisada para identificar melhores estratégias para o gerenciamento de mudanças dos requisitos Arquitetura: capacidade e restrições da plataforma de reuso. Isto influencia a negociação dos requisitos, pois os novos requisitos precisam ser consistentes com a plataforma. Tamanho da organização: número de empregados na organização que trabalham com desenvolvimento de linha de produtos de software. Isto afeta diretamente a estrutura organizacional, influenciando o nível de formalidade do processo de engenharia de requisitos. Distribuição geográfica da organização: número de locais de desenvolvimento envolvidos no desenvolvimento da linha de produto. Isto influencia a estratégia de gerenciamento dos requisitos, em que deve ser permitido o acesso aos requisitos de qualquer lugar. A escolha da ferramenta de suporte também é influenciada por esses fatores. A maioria das diferentes situações descritas influencia diretamente a elicitação dos requisitos, demonstrando a relevância de um processo de elicitação bem definido e customizado para diferentes contextos da linha de produtos. A seleção das técnicas de elicitação depende das características situacionais da linha de produtos, bem como de quais informações são necessárias para o seu desenvolvimento.

13 13 2 REVISÃO DE ER NAS ABORDAGENS DE LPS O processo de engenharia de requisitos ainda não é bem definido nas abordagens de LPS e de engenharia de domínio encontradas na literatura. Este resultado foi concluído a partir de uma revisão sistemática dessas abordagens, fornecendo evidências empíricas sobre as atividades de requisitos, e identificando suas direções, pontos fortes e fracos. A análise deste estudo foi construída a partir de questões de pesquisa, que serão apresentadas a seguir. Q1. Quais atividades, técnicas e métodos de engenharia de requisitos são adotados em cada abordagem de LPS? Esta questão objetiva identificar as atividades, técnicas e métodos de ER nas abordagens de LPS, e avaliar sua completude de acordo com critérios baseados nas necessidades de um processo básico de ER. De acordo com Kotonya e Sommerville [1], um processo é um conjunto organizado de atividades que transformam entradas em saídas. Em ER, um processo inevitavelmente varia de uma organização para outra, mas suas entradas e saídas são similares na maioria dos casos. Sua variabilidade é influenciada por diversos fatores, tais como maturidade técnica organizacional, cultura da organização, e domínio de aplicação. Assim, seus métodos e técnicas devem ser selecionados e customizados de acordo com o contexto da organização. Um processo básico de ER deve definir atividades para elicitação, análise e negociação, validação, especificação e gerenciamento de requisitos; a estrutura e planejamento das atividades; suas entradas e saídas, as diretrizes; e os papéis associados com suas atividades [1]. Portanto, em cada atividade, técnica e método encontrados nas abordagens são analisados esses requisitos básicos. Os dados coletados são classificados de acordo com os subcomponentes de ER (elicitação, análise e negociação, validação, especificação e gerenciamento de requisitos). Esses dados também são padronizados de acordo com esquema de nomes comuns, de maneira que possibilite mapear como a RE é definida no cenário de LPS. Q2. A abordagem possui ponto de vista tecnológica e/ou sócio-organizacional? As abordagens são classificadas em dois pontos de vista, o tecnológico e o socioorganizacional. O ponto de vista tecnológico tem uma visão objetiva dos requisitos e destaca aspectos tecnológicos do sistema. O ponto de vista socio-organizacional tem uma visão subjetiva dos requisitos, seu foco são os aspectos sociais e organizacionais dos sistemas de informação. As abordagens deste tipo de ponto de vista assumem que existem diferentes visões do mundo, considerando necessidades humanas e organizacionais. Elas definem

14 14 objetivos de negócio, razões dos requisitos, perspectives de diferentes stakeholders, e necessidades do mercado. Pontos de vista tecnológicos e socio-organizacionais são interrelacionados e descrevem diferentes perspectivas do domínio. Estas questões orientaram a revisão, onde foram incluídas abordagens de SPL e Engenharia de Domínio que apresentavam uma ou mais atividade de ER. As abordagens de Engenharia de Domínio foram consideradas por possuírem muitas similaridades com LPS. Estudos com informações insuficientes ou não direcionados para área de software foram excluídos desta análise. Uma breve descrição sobre as abordagens selecionadas é apresentada a seguir, seguindo a ordem cronológica de publicação. FODA (Feature-Oriented Domain Analysis 1990) [19] é um método de análise de domínio que consiste de três fases principais: análise de contexto (escopo), modelagem do domínio, e arquitetura do domínio. Desde sua publicação (1990), o processo FODA vem sendo adotado e estendido em outras abordagens. Algumas organizações definem variações deste processo, fornecendo mais detalhes na análise de domínio (ex. FORM [20]); outras integram o FODA com outros modelos no contexto de linha de produto de software (ex. Framework do SEI [4]) ou engenharia de domínio (ex. RiDE [25] e Odyssey [23]). FAST (Family-oriented Abstraction, Specification, and Translation ) [8, 9] é um processo sistemático para analisar família de produtos potenciais e desenvolver facilidades para produção efetiva dos membros da família. Este abordagem é composta de dois subprocessos - Engenharia de Domínio e Engenharia de Aplicação que são conectados por iterações contínuas para guiar a evolução da família e de seus artefatos. Nestas iterações, o ambiente é re-analisado, refinado e melhorado quanto necessário. FORM (Feature-Oriented Reuse Method ) [20] é um processo sistemático para Engenharia do Domínio (ED) e Engenharia da Aplicação (EA). As variabilidades e semelhanças das aplicações do domínio são capturadas como features, compondo o modelo do domínio que é utilizado para o desenvolvimento da arquitetura e dos componentes. A engenharia do domínio consiste de três fases: análise de contexto, análise de domínio e modelagem da arquitetura. PuLSE (Product Line Software Engineering ) [6, 10, 26] é uma das metodologias pioneiras e com maior experiência em Linhas de Produto de Software. Desde 1999, essa abordagem vem sendo experimentada em diferentes indústrias, consolidando sua aplicabilidade em uma larga variedade de contextos. Isso é possível devido, principalmente,

15 15 ao seu forte foco nos produtos, e seus processos e técnicas de customização e instanciação. A abordagem é dividida em três elementos principais: a) fases de desenvolvimento: descrevem as atividades executadas para configurar e usar o ambiente; b) componentes técnicos: em geral capturam processos, métodos, ferramentas e experiências relacionadas a práticas de uma linha de produto particular; e c) os componentes de suporte: pacotes de informações ou guias que permitem melhor adaptação, evolução e desenvolvimento da linha de produto. Framework do SEI (Software Engineering Institute ) [4] é um compêndio de atividades e práticas necessárias para ter sucesso com linha de produto de software. Seu desenvolvimento foi baseado em experiências na indústria, e desde sua publicação, em , ele vem evoluindo através de novas versões, que representam um esforço incremental para capturar as mais recentes informações sobre as práticas bem sucedidas de linha de produto. Este framework é estruturado para: a) descrever os fundamentos, benefícios e atividades essenciais da linha de produto de software; b) definir áreas práticas necessárias para uma organização ter a capacidade de desenvolver uma linha de produto de software; e c) definir práticas especificas para cada área. Suas atividades essenciais são executadas através das áreas práticas, que por usa vez utilizam práticas especificas. Três atividades essenciais são identificadas para o desenvolvimento de uma linha de produtos: desenvolvimento dos core assets (engenharia de domínio); desenvolvimento do produto (engenharia da aplicação); e gerenciamento. Odyssey (1999) [23] é um framework de desenvolvimento de software orientado a domínio, desenvolvido pela COPPE/UFRJ 3. Este ambiente dar suporte ao processo de engenharia de domínio e engenharia da aplicação; e é formado por modelos conceituais, modelos arquiteturais, e modelos de implementação. CoPAM (Component-Oriented Platform Architecture Method ) [24] é uma família de métodos para linha de produtos de software. Para cada linha (família) de produto é desenvolvido um método de acordo com o contexto de negócio e estrutura organizacional. Sua estrutura é composta por três subprocessos: engenharia da plataforma (engenharia do domínio); engenharia do produto (engenharia da aplicação); e engenharia da família (gerenciamento da engenharia da plataforma e engenharia do produto). 2 3 Fonte: Instituto Alberto Coimbra de Pós Graduação e Pesquisa de Engenharia / Universidade Federal do Rio de Janeiro.

16 16 Kobra (Komponentenbasierte Anwendungsentwicklung ) [2] é uma abordagem sistemática para engenharia de linha de produto baseada em componente. De uma perspectiva de linha de produto, esta abordagem é uma customização pré-definida do PuLSE. Seu princípio básico é a separação dos interesses, por exemplo, a especificação dos produtos é separada da especificação dos processos. Suas duas fases principais são: engenharia do framework (engenharia do domínio) e engenharia da aplicação. PLUS (Product Line UML-Based Software Engineering 2005) [3] é um processo evolucionário e iterativo para o desenvolvimento de linhas de produto de software, que usa a notação UML (Unified Modeling Language). Os dois maiores ciclos de vida desse processo são: engenharia da linha de produtos de software (engenharia de domínio) e engenharia da aplicação. As fases da engenharia da linha de produtos de software são: modelagem dos requisitos, modelagem da análise, modelagem do projeto, implementação incremental dos componentes, e teste. Framework SPLE (Software Product Line Engineering ) [5] fornece suporte à engenharia de domínio e engenharia de aplicação. A engenharia de domínio é composta pelos seguintes sub-processos: gerenciamento do produto, engenharia de requisitos do domínio, projeto do domínio, implementação e teste do domínio. O processo de engenharia da aplicação é composto pela engenharia de requisitos, projeto, implementação e teste da aplicação. RiDE (RiSE Process for Domain Engineering )[25] é um processo de engenharia de domínio desenvolvido pelo RiSE 4. Três etapas importantes definem o processo geral: Análise de Domínio, Projeto do Domínio e Implementação do Domínio. Mais detalhes sobre essas abordagens é descrito a seguir. A próxima seção descreve como estas abordagens são direcionadas para tratar a engenharia de requisitos, mostrando os resultados da revisão sistemática. 2.1 RESULTADOS Nesta seção serão relatados os resultados da revisão sistemática de acordo com as questões de pesquisa Atividades, Técnicas e Métodos As abordagens foram analisadas de acordo com as necessidades de um processo básico de ER, e foram classificados em três categorias: não definido, parcialmente definido, e definido. Atividades, técnicas e métodos encontrados que definem entradas, saídas, diretrizes e papéis 4 Grupo de Pesquisa de Reuso em Engenharia de Software, coordenado pelo Profº Silvio Meira.

17 17 foram classificados como definido. Se eles foram encontrados sem essas características, então foram classificados como parcialmente definida. E quando não encontrados foram classificados como não definido. Em cada sub-componentes de RE foram analisados suas necessidades de acordo com [4, 13, 15], como segue: a) elicitação deve definir atividades para descoberta de requisitos e variações antecipadas; b) análise e negociação devem encontrar variações e similaridades; identificar conflitos em novos requisitos, analisando seu impacto na arquitetura de domínio; identificar oportunidades de reuso; e estabelecer acordos para satisfazer todos os stakeholders; c) especificação deve documentar os requisitos das aplicações e da linha de produto; d) validação deve checar a consistência, completude e qualidade dos requisitos comuns e variáveis; e e) gerenciamento deve gerenciar as requisições de mudanças e a rastreabilidade. Assim, as abordagens foram mapeadas em atividades, métodos e técnicas de acordo com um esquema de nomes comuns, e agrupados nos sub-componentes apresentados anteriormente. Este mapeamento é apresentado na Tabela 1. Foram analisadas apenas as atividades, técnicas e métodos identificados nas abordagens, que são apresentados a seguir. Algumas técnicas e métodos são aplicáveis em mais de um sub-componente de ER, mas foram classificados onde são mais utilizados. A prototipagem, por exemplo, pode auxiliar na elicitação e validação, mas é mais aplicável em elicitação Elicitação α) Identificar fontes de requisitos: a informação vem de múltiplas fontes, assim é importante identificar as fontes necessárias para entender o domínio, tais como produtos existentes. Produtos competidores, literatura do domínio, especialistas do domínio [5, 19]. β) Identificar interesses de negócio: descobrir estratégias de negócio, vantagens competitivas para a empresa, seus objetivos de alto nível de abstração que devem ser satisfeitos com SPL. χ) Identificar restrições: capturar requisitos que definem limitações na LPS, tais como restrições de domínio e de projeto. δ) Identificar os interesses de marketing: conhecer as necessidades de Mercado, as vantagens competitivas, suas tendências atuais e futuras que ajudam na definição do domínio da LPS.

18 18 ε) Identificar artefatos disponíveis para reuso: buscar por artefatos que já estão disponíveis e analisar se eles são úteis como bases de reuso para linha de produto. φ) Entrevista: técnica que envolve discussão estruturada ou aberta entre um entrevistador (ex. analista de domínio) e um sujeito (ex. especialista do domínio) para elicitação dos requisitos. γ) Workshop: técnica que envolve um grupo de pessoas participando ativamente para elicitar e negociar requisitos. η) Viewpoint: técnica que identifica diferentes perspectivas dos requisitos do sistema. ι) Prototipagem: demonstração do sistema que simula seu comportamento, ajudando os stakeholders para refinar suas idéias sobre os requisitos dos produtos Análise e Negociação a) Definir limites da LPS: defining which requirements should be outside the scope of the SPL. b) Classificar Requisitos: categorizar requisitos como funcional e não-funcional (ex. atributos de qualidade, restrições). c) Priorizar Requisitos: prioridades são atribuídas aos requisitos, refletindo sua importância para os stakeholders. Isto ajuda os stakeholders na decisão e acordo nos requisitos básicos para LPS [5, 15, 26]. d) Analisar variações e similaridades: capturar os requisitos comuns (para todos os produtos) e variáveis (de produtos específicos) das aplicações do domínio. O principal objetivo da engenharia de requisitos do domínio é o desenvolvimento de artefatos comuns e variáveis para a linha de produto em ordem que permita o reuso em larga escala na engenharia da aplicação [5] Especificação a) Definir modelos padrões: definir um conjunto de modelos padrões (templates), que deve ser usado para organizar a descrição dos requisitos. Estes templates podem representar diferentes visões dos requisitos, desde a uma descrição mais abstrata (ex. modelo de features) a uma descrição mais detalhada (ex. modelo de casos de uso). b) Descrever termos padrões: identificar e armazenar termos padrões, tais como terminologias do domínio.

19 19 c) Descrever variabilidade: identificar pontos de variações nos documentos de requisitos. Requisitos comuns são escritos com pontos de variações que serão usados para criar requisitos específicos do produto. A documentação do ponto de variação permite que clientes localizem as decisões deitas. Por outro lado, a documentação de variações permite que clientes considerem as opções disponíveis para cada decisão [5]. d) Documentação Textual: documentação de requisitos textuais em linguagem natural. e) Documentação em XML: os requisitos são documentados usando linguagem de marcação - XML(eXtensible Markup Language). Este tipo de representação pode ser aplicada para permitir a documentação explícita de variabilidade em requisitos textuais [5]. f) Caso de Uso: requisitos são documentados usando modelos de casos de uso. g) Modelo de Features: requisitos são organizados por features, que representam as características do sistema visíveis pelos usuários finais [19]. h) Modelo de Decisão: todos as variações são descritas como decisões. i) Modelo Entidade-Relacionamento: representa o conhecimento do domínio explicitamente em termos de entidades do domínio e suas relações [2] Validação a) Definir casos de teste: para cada requisito é proposto um ou mais plano de teste, que pode ser usado para checar se o sistema reúne os requisitos. Esta é uma forma efetiva de revelar problemas em requisitos, tais como incompletude e ambigüidade [15]. b) Organização inspeção/revisão: a linha de produto deve ser validada por um grupo de pessoas responsáveis pela checagem dos requisitos, que se reúnem para discutir problemas com os requisitos e acordos para solucionar os problemas [15] Gerenciamento a) Definir gerenciamento de mudança: definir políticas para gerenciar mudanças para os requisitos que define como as mudanças são propostas e avaliadas, analisando seus efeitos. b) Definir rastreabilidade: definir quais informações de rastreabilidade devem ser mantidas e como elas devem ser representadas. Isto permite encontrar dependências entre requisitos, e entre requisitos e outros artefatos do domínio.

20 20 Tabela 1: Mapeamento das atividades, técnicas e métodos de RE nas abordagens de LPS. Abordagens/ Esquema comum de nomes FODA (1990) FAST (1997) FORM (1998) PuLSE (1999) Framework SEI (1999) ODYSSEY (1999) COPAM (2000) Kobra (2002) PLUS (2005) Framework SPLE (2005) RiDE (2007) Atividades Técnicas Atividades Métodos de Representação Atividades Elicitação Identificar fontes de requisitos Identificar Stakeholders Identificar Interesses de Negócio Identificar restrições Identificar necessidades de marketing Identificar artefatos disponíveis para reuso Entrevista Workshop Viewpoint Prototipagem Análise e Negociação Definir limites da LPS Classificar Requisitos Priorizar Requisitos Analisar variações e similaridades Especificação Definir templates padrões Descrever termos padrões Descrever variabilidade Documentação Textual Documentação XML Caso de Uso Modelo de Feature Modelo de Decisão Modelo Entidade- Relacionamento Validação Definir casos de teste Organizar inspeção/revisão Gerenciamento Definr Gerenciamento de Mudança Definir Rastreabilidade Legenda Não definido. Definido Parcialmente Definido

21 Pontos de Vista das Abordagens O ponto de vista tecnológico foi considerado por todas as abordagens analisadas. Este resultado é esperado, pois a visão de aspectos tecnológicos é um critério básico para um desenvolvimento de software, e frequentemente são representados em métodos tradicionais e estruturados, tais como modelo de caso de uso e modelo entidade-relacionamento. De acordo com a análise sistemática, apenas o Framework do SEI [4] apresenta o ponto de vista tecnológico e sócio-organizacional de maneira completa. Ele sugere modelagem de caso de uso e de features, que captura os aspectos tecnológicos; definem escopo e indica a modelagem viewpoints para capturar aspectos sócio-organizacionais. Entre as outras abordagens, três apresentam apenas aspectos tecnológicos [2, 3, 23], e sete apresentam ponto de vista tecnológico e algumas características do ponto de vista sócio-organizacional. 2.3 Pontos Fortes e Fracos A análise dos pontos fortes e fracos pode ajudar a melhorar o processo de ER para LPS, e identificar melhores práticas para serem aplicadas nesse contexto. A seguir são apresentados a avaliação relativa a cada abordagem. FODA [19]. Em geral, as atividades, papéis, entradas e saídas deste processo são bem definidos, e alguns produtos de trabalho são determinados com diretrizes. Seu principal produto é o modelo de features, que é útil para a representação do domínio, em que variabilidade e comunhão são identificadas. Além disso, modelo de features é entrada de outros modelos no processo. No entanto, existem algumas lacunas no processo, como segue. Ele não descreve como realizar a elicitação, ele apenas diz que features comuns e variáveis devem ser capturados. A validação do modelo de features é definida, mas não possui diretrizes. Não são definidos atividades para o gerenciamento e negociação de requisito. Os requisitos são documentados como modelos de features e entidade-relacionamento, que são representações de alto nível de abstração. Assim, a sua especificação não é suficiente para orientar a equipe de desenvolvimento. FAST [8, 9]. Esta abordagem define papéis em todas as etapas, e tem como característica chave de ER a especificação direcionada para derivação de uma DSL (Domain Language Specification) - linguagem de especificação de domínio -, que permite traduzir automaticamente os requisitos em código executável, contribuindo para o desenvolvimento de protótipos para validação dos requisitos. Contudo, o processo de desenvolvimento de DSL tem um custo elevado. Assim, ele torna-se mais arriscado, pois requisitos incorretos e

22 22 incompletos podem conduzir a uma grande perda de investimento. Considerando as atividades essenciais de RE, este processo não apresenta informações sobre o gerenciamento de requisitos, nem diretrizes para elicitação e especificação. FORM [20]. Em FORM, as features são modeladas com diferentes perspectivas: features de capacidade (preocupação principal dos usuários); features do ambiente operacional e da tecnologia do domínio (preocupação principal dos analistas do sistema e arquitetos); e features de implementação (preocupação principal dos desenvolvedores). Algumas atividades essenciais do RE não estão definidas no processo. Não há informações sobre gerenciamento (ex. gerenciamento de mudança e rastreabilidade) e negociação (ex. priorização de requisitos) dos requisitos. E não são definidas diretrizes para elicitação. PuLSE [6, 10, 26]. Em geral, esta abordagem tem entradas e saídas claramente definidas nas atividades de análise e modelagem. Sua flexibilidade permite a instanciação e customização de técnicas e modelos de requisitos para aplicações específicas, prevendo a evolução do projeto com conseqüentes mudanças nos requisitos. No entanto, a abordagem tem pouca informação sobre os seus artefatos (produtos trabalho) de requisitos. A validação dos requisitos é pouco descrita no processo, e não há uma definição clara dos papéis nas diferentes fases de requisitos de engenharia. Framework do SEI [4]. O framework do SEI é uma tecnologia madura de linha de produto de software, que vem sendo publicada e evoluída desde Em geral, o SEI define fundamentos e diretrizes para ER em SPL. Ele define práticas especificas e configuráveis para executar a ER, e apresenta os riscos associados com esse contexto. No entanto, o framework não identifica papéis entre os stakeholder, nem atividades para validação de requisitos. O gerenciamento de requisitos também é pouco definido, não definindo atividades para rastreabilidade dos artefatos. Odyssey [23] Este framework é apoiado por uma ferramenta que permite a especificação dos modelos do domínio; a integração de informações de diferentes domínios; o gerenciamento de seus modelos e rastreabilidade entre os modelos conceituais. Através de padrões conceituais são sugeridas práticas de modelagem do domínio, fornecendo documento padronizado para descrever os conceitos do domínio. Entretanto, existem lacunas nas atividades relacionadas à engenharia de requisitos, em que não são definidos atividades para elicitação e validação de requisitos. 5

23 23 CoPAM [24]. O COPAM permite adaptar seus métodos para diferentes contextos, considerando o interesses de negócios e a estrutura organizacional. Seu processo é focado em arquitetura, deixando muitas lacunas no processo de engenharia de requisitos. Não existem informações no processo sobre técnicas para validação, gerenciamento e negociação de requisitos, e seu processo de elicitação é pouco definido. Kobra [2]. Essa abordagem foca no projeto e especificação dos componentes. Diversos modelos e procedimentos para especificação são fornecidos. O processo de manutenção é bem definido, com atividades para gerenciar configuração e mudança, e planejar manutenção. Além disso, o KobrA é um processo flexível que pode ser customizado para diferentes contextos. Por outro lado, existem algumas lacunas em ER para essa abordagem. Por exemplo, fases essenciais em ER não são definidas claramente, tais como elicitação e negociação de requisitos. Em geral, os stakeholders essenciais não são identificados no processo, nem as fontes do conhecimento de domínio. PLUS [3] O PLUS fornece exemplos e diretrizes para executar a modelagem com notação UML, adicionando variabilidades para adequar à realidade de um desenvolvimento da linha de produtos, o que torna o processo de modelagem um dos pontos fortes dessa abordagem. Contudo, em geral, o PLUS não apresenta atividades para elicitação, negociação e gerenciamento dos requisitos. Framework SPLE [5]. Este trabalho descreve a especificação de requisitos de forma satisfatória, apresentando diferentes maneiras de representação em documentação textual e modelos. Estes documentos são descritos com relações de rastreabilidade entre eles, mas é difícil mantê-lo em um domínio grande e complexo sem um apoio ferramental. Em geral, processo de ER não é definido satisfatoriamente. Não são definidas atividades de validação de requisitos, nem papéis e stakeholders para toda a ER. RiDE [25]. Este processo é definido de maneira sistemática. São definidos procedimentos e papéis entre os stakeholders para executar as atividades; e os artefatos, entradas e saídas são bem definidos. No entanto, o processo de engenharia de requisitos é definido superficialmente. As atividades de elicitação, especificação e validação são definidas em nível de features. Em geral, não são apresentadas técnicas para elicitação e gerenciamento de requisitos, nem atividades de especificação mais detalhadas, tais como caso de uso.

24 24 3 TÉCNICAS E MÉTODOS DE ER PARA LPS São apresentadas a seguir algumas técnicas e métodos de Engenharia de Requisitos direcionadas para o contexto de LPS. 3.1 Baseada em Pontos de Vista (Viewpoints) Stakeholder possuem diferentes perspectivas e necessidades em relação à linha de produto. Desta forma, a técnica de viewpoints pode ser utilizada nos estágios iniciais da elicitação para identificar diferentes interesses e necessidades. Esta técnica também contribui para a análise e especificação dos requisitos de software. Viewpoints são um mecanismo explicito que considera diferentes perspectivas do problema e sistema, originadas de diferentes stakeholders [1]. Em um viewpoint pode conter, além dos requisitos, informações sobre o ambiente, domínio do sistema, fontes e razões dos requisitos [15] PLSVA Jaber et al. [14] propõe um modelo de viewpoints, PLSVA (Product Line Stakeholder Viewpoint Approach) com três visões da linha de produto, como segue: A visão da gerência da organização, que possui um entendimento claro sobre as direções da LPS. Ele interage com clientes, faz decisões de negócios, e é responsável por responder questões do tipo quem é o cliente e pessoa de contato; qual o intervalo de tempo, cronograma, custos e equipe dos produtos da LPS. A visão da equipe de reuso da organização, que foca nos artefatos e produtos do domínio. Esta equipe é capaz de identificar artefatos, o nível de reuso, e tipos de componentes usados. A visão dos desenvolvedores, que é interessada na arquitetura da LPS, produtos, sistema operacional e plataforma utilizado, artefatos, tipos de componentes e suas interfaces. O desenvolvimento dos viewpoints é realizado através do método VORD (Viewpointoriented Requirements Definition) [1], que é direcionado para descoberta e análise de requisitos. O modelo proposto utiliza as três primeiras fases do VORD: Identificação de Viewpoint: descoberta de viewpoint dos stakeholders e identificação dos atributos, tarefas e sub-viewpoints específicos.

25 25 Estruturação do Viewpoint: agrupamento dos viewpoints relacionados em uma hierarquia. Viewpoints comuns são agrupados no nível mais alto da hierarquia. Documentação do Viewpoint: refina a descrição dos viewpoints identificados. Contudo, o modelo proposto não identifica viewpoints suficientes para expressar todos os interesses relacionados à linha de produto. Não são identificados, por exemplo, as perspectivas da equipe de marketing, dos usuários e clientes - principais interessados na linha de produto VODRD VODRD (Viewpoint-Oriented Domain Requirements Definition) [27] é um método iterativo para análise de requisitos do domínio a partir da perspectiva dos stakeholders. Suas atividades são conduzidas em quatro etapas: definir escopo do domínio (scope domain), caracterizar domínio (characterize domain), documentar pontos de vista (documentar viewpoints), e analisar pontos de vista do documento (analyze document viewpoints). O ciclo de vida dessas etapas pode ser visto na Figura 2; Figura 2: Ciclo de Vida do VODRD [27] A definição do escopo do domínio compreende a identificação dos stakeholders e viewpoints do domínio. Esta atividade é realizada através de entrevistas e análise de documentos existentes. Para caracterizar o domínio são analisadas as fontes dos requisitos e então são definidos entidades (termos comuns) do domínio em um dicionário do domínio. Este dicionário deve ser criado por um analista do domínio e revisado por um especialista do domínio. A documentação dos viewpoints é baseada nos sistemas existentes. Nesta etapa os requisitos de cada produto do domínio são alocados para os viewpoints apropriados. Os viewpoints são documentados de acordo com um modelo padrão (Figura 3), em que são definidas a justificativa para inclusão (razão); associações de rastreabilidade; e requisitos com identificação, razão, associações e definição.

26 26 Após a documentação, os requisiteis são analisados e comparados nos viewpoints para identificar quais são reusáveis. Os artefatos gerados por esse método são o seguinte: dicionário de domínio, viewpoints do domínio, catálogo dos requisitos reusáveis. Figura 3: Modelo de especificação de viewpoints [27] Este método possui diretrizes bem definidas para construir os viewpoints, propondo atividades para elicitação, análise, especificação e gerenciamento dos requisitos. Contudo, em sua atividade de gerenciamento de requisitos não são definidos relações de rastreabilidade entre requisitos e outros artefatos da SPL, nem há descrições sobre a origem de cada requisito. Da perspectiva de reuso, este método não representa as variablidades de maneira satisfatória, com pontos de variações que facilite a tomada de decisão entre os requisitos do domínio para instanciação de uma aplicação da SPL.

27 Baseado em Metas (Goals) As metas identificam as razões para os requisitos da linha de produto, e representam direções, propósitos, objetivos de uma organização [17], e as causas das suas variações [28]. Este método fornece uma forma natural para identificar variabilidade em fases iniciais de requisitos, por permitir a captura de alternativas para que os stakeholders alcancem suas metas [28] GVAA GVAA (Goal-based Variability Acquisition and Analysis) é um processo de variabilidade intensivo para decompor e analisar metas. Estas metas são representas em digramas formais, que são estruturados em árvores de decomposição AND/OR. Um exemplo deste diagrama pode ser visto na Figura 4. Figura 4: Modelo de Meta [28] Metas (figuras ovais no diagrama) podem ser satisfeitas ou não satisfeitas. Quando uma meta g (de goal) possui uma decomposição AND em g1,...,gn, então g é satisfeita se, e somente se, gi é satisfeita para todos os i s. Se g é uma decomposição OR, ela é satisfeita se, e somente se, existe um i tal que gi é satisfeito. Em adicional, alguns tipos de relações são usados para representar restrições entre metas. Tais tipos de relações são mostrados na Tabela 2, com sua conjunção equivalente. O tipo de relação 1 expressa que quando g1 é satisfeito, g2 também é. Ao contrário do tipo 2, que indica que g2 não é satisfeito quando g1 satisfaz as condições. Os tipos 4 e 5 seguem a mesma lógica dos tipos 1 e 2, respectivamente, adicionando a recíproca das condições. Por exemplo, se g1 é satisfeito, g2 também é, e vice-

28 28 versa. Já o tipo 3 indica que g2 não pode ser satisfeito ao menos que g1 seja satisfeito. E por fim, as restrições mais complexas são representadas através de retângulos (ver Figura 5). Tabela 2: Tipo de relação com conjunção correspondente Tipo de Relação Conjunção Cada meta de alto nível pode ser associada a um conjunto de interesses, em resposta para que refinamentos alternativos da meta possam ser introduzidos. Este conjunto de interesse é classificado da seguinte forma: Agentive (A): interesse dos agentes (atores) cujas atividades afetam o estado das transações implícitas da meta. Ex: {Máquina, usuário}a envia mensagem. Dative (D): interesse dos agentes afetados pelas atividades implícitas da meta. Ex.: Enviar uma mensagem para {o administrador, o usuário}d. Objective (O): é o interesse do objeto que é afetado pelas atividades implícitas da meta. Ex: Enviar {uma mensagem de , um fax}o Factitive(F): é a preocupação do objeto ou ser que é resultante da atividade, ou é entendido como parte do verbo, por exemplo, Formata Texto {negrito, itálico}f. Process(P): é o interesse que representa o instrumento (P.ins) que envolve a execução das atividades, ou os meios (P.mea) e maneira (P.man) como a atividade é executada. Ex: pagamento {por débito, por crédito}p.ins. Locational (L): é o interesse sobre a localização espacial ocupada pela atividade genérica que é implicada pelo verbo. Ex: enviar uma mensagem {no carro, no ônibus}l. Temporal (T): é o interesse sobre a duração (T.dur) ou freqüência (T.frq) da atividade que é implicada pelo verbo. Ex. Verificar mensagem toda {hora, 10 min}t.frq. Conditional (C):interesse referente a condição alternativa sob a qual a meta pode ser representada (C.con), ou a sinais alternativas para o início de

29 29 atividades trigger (C.tri). Ex: Enviar produto apenas se {pagamento efetuado}c.con. Extent (E) interesses de variabilidade referentes ao grau alternativo pela qual a atividade é executada. Ex: Exibir os primeiros {10, 20 30}E registros. Figura 5: Exemplo de variabilidade de interesses inicial [28]. Um conjunto de variabilidade de interesses é identificado inicialmente para cada meta de alto nível, seguido por uma decomposição de metas para formar a árvore AND/OR. Antes de iniciar a decomposição, são analisadas as variabilidades de interesses que são relevantes para a meta (ex. Be Notified, na Figura 5). A coleção de interesses constitui o frame de variabilidade da meta. O conjunto de frames do domínio é usado para derivar variabilidades de interesses específicos para o problema. Em paralelo à definição de interesses, são considerados fatos contextuais que podem variar enquanto a meta está sendo representada, e influenciar a seleção e identificação de alternativas. Estes fatos podem ser intencionais, ou não intencionais. Na figura 5 estes fatores são representados no tópico de dependência ( depends on ). Uma vez que os interesses relevantes e seus domínios são coletados, é iniciada a etapa de decomposição da meta. Cada meta é rotulada com expressões unresolved, resolved e addressed. Inicialmente, para cada meta principal é atribuído o rótulo unresolved. Quando uma meta possui uma decomposição AND, todos os interesses relevantes para a meta pai são herdados por num mínimo uma das submetas. Quando uma meta possui uma decomposição OR, exatamente uma variabilidade de interesse relevante é direcionada, enquanto as outras

30 30 são automaticamente herdadas. Uma variabilidade de interesse é direciona para particionar seu domínio e atribuir cada partição para sua submetas OR. Se a partição contém apenas um elemento do domínio, então o interesse é rotulado como resolved, e suas submetas não herdam a decomposição da meta. Se existe mais elementos, então seu rótulo é addressed. O modelo de decomposição pode ser visto na Figura 6. Mais detalhes sobre o processo de decomposição e resolução de variabilidade pode ser visto em [28]. Figura 6: Exemplo de Árvore de Decomposição [28] Portanto, este método define a variabilidade com base nas necessidades e metas dos stakeholders, apresentando uma abordagem baseada em intenções organizacionais. Seus frames de variabilidade de interesses permitem descrever o conjunto de elementos do domínio (ex.: atores e condições) para representar o cenário envolvido em cada meta. Contudo, este método não categoriza os requisitos (ex.: funcionais e não funcionais), e sua notação não é de fácil entendimento, necessitando de visões complementares para atender aos diferentes tipos de stakeholders.

31 Baseado em Metas e Cenários OS cenários descrevem os comportamentos dos produtos, e são chaves para definição do escopo da linha de produto [4]. Eles descrevem interações de usuários ou sistemas com produtos na linha de produto. Estas interações podem ser comuns para todos os produtos, ou únicas para um subconjunto de produtos [16]. Assim, requisitos variantes são encontrados quando há mais de uma forma de representar cenário para alcançar uma meta, ou seja, existem cenários alternativos ou opcionais GSM Kim et al. [17] propõe uma modelagem de metas e cenários (Goal and Scenario Modeling - GSM) para identificar os requisitos do domínio e fornecer a razão para eles. Em sua primeira proposta [16], metas e cenários são integrados com features, e são representados em um modelo de requisitos do domínio (RMD). O processo RMD consiste em três atividades macros, que são: definição do escopo da LPS, análise de requisitos do domínio, e análise de variabilidades e semelhanças. Em [17], as features são substituídas pela Representação dos Requisitos do Domínio (RRD), ou seja, depois que as metas e cenários são identificados, os requisitos do domínio são representados como diagrama de casos de uso variáveis. A Figura 7 apresenta a relação entre cenários, metas e features [16]. Cada feature da LPS representa e exibe os comportamentos dos produtos que são descritos por cenários. Estes, por sua vez, capturam requisitos que descrevem situações reais ou comportamentos concretos. As metas são alcançadas por cenários, e relaciona-se indiretamente com as features. O processo de elicitação consiste em atividades de descoberta de metas, preparação dos cenários e conexão das features. Todas essas atividades são acompanhadas pela análise de variabilidade e semelhanças. Estas atividades são repetidas incrementalmente até completar a hierarquia de requisitos do domínio.

32 32 Figura 7: Relação entre Metas, Cenários e Features [16]. A abordagem mais recente [17], apresentada na Figura 8, possui uma árvore de metas como saída da modelagem de metas e cenários, consistindo de quatro níveis: nível de negócio, nível de serviço, nível de interação e nível interno. Estes níveis são hierarquias abstratas que representam diferentes perspectivas. O nível de negócio mostra qual é o objetivo de negócio da organização. O nível de serviço apresenta quais serviços podem alcançar o objetivo de negócio, e como o escopo na linha de produto é determinado. Os requisitos na linha de produto são identificados na perspective da interação entre o próprio sistema e entidades externas, também chamadas de agentes. O nível interno apresenta as funcionalidades entre objetos do sistema. Figura 8: Ambiente de suporte para metas, cenários e casos de uso[17]. Todas as metas se relacionam entre si através da árvore de metas. São definidos quatro tipos de metas de acordo com o nível de requisitos do domínio, que são: meta de negócio, meta de serviço, meta de interação e meta interna. Enquanto os cenários são classificados em três tipos: cenário de serviço, cenário de interação e cenário interno, como pode ser visto na

33 33 Figura 9. Uma representação mais detalhadas da variabilidade entre os cenários pode ser vista na Figura 10. Figura 9: Estrutura do processo de modelagem de metas e cenários [17] Um cenário é escrito como uma combinação de <S + V + Propósito + Direção + Maneira>, onde S é representa os agentes que interagem com o sistema, ou o próprio sistema concebido; V é um verbo ativo; Propósito é um objeto conceitual ou físico; Direção é uma fonte ou destino; e Maneira é a forma em que o cenário é implementado. Por exemplo, o cenário O HIS checa a temperatura atual com a temperatura do sensor é descrito como segue: <O HIS> = S, < checa> = V, <a temperatura atual> = Propósito, <com a temperatura do sensor> = Maneira. Figura 10: Metas e Cenários em nível de negócio e serviço [17].

34 34 Casos de uso são utilizados para refinar os requisitos, pois metas e cenários não os representam de maneira suficiente. Os requisitos do domínio são representados nos casos de uso através da transferência de regras de orientação, que ajudam a identificar requisitos comuns e variáveis como casos de uso variáveis. No nível de interação são identificadas relações entre o sistema e seus agentes, e o propósito da especificação do caso de uso é descrever como os agentes podem interagir com o sistema para obter serviços e alcançar suas metas. A Figura 5 apresenta a relação entre metas, cenários e casos de uso. Figura 11: Relação entre metas, cenários e casos de uso [17]. Este trabalho apresenta um método de modelagem eficiente para identificar requisitos em diferentes níveis de abstração, separando diferentes perspectivas, e permitindo a rastrebilidade entre os requisitos do domínio. A definição de múltiplas perspectivas aproxima esta técnica do mecanismo de viewpoints, contudo não são definidos os stakeholders envolvidos em cada visão. As razões dos requisitos são mapeadas através das metas, mas não são definidas suas fontes.

35 Orientado a Features Features são características, qualidades ou aspectos do sistema visíveis pelo usuário [19]. Sua modelagem é definida de maneira abstrata, sendo útil para parametrização dos produtos do domínio, possibilitando a identificação de diferenças entre aplicações através de refinamentos. Assim, o modelo de features pode ser utilizado por analistas de requisitos para negociar as funcionalidades das aplicações com os usuários. Os desenvolvedores podem utilizar o modelo de features para identificar o que necessita ser parametrizado em outros modelos e na arquitetura, e como essa parametrização deve ser feita. Além disso, este modelo representa um espaço de decisões para o desenvolvimento de software, em que é possível identificar candidatos de componentes reusáveis [20] FODA e FORM O método FODA (Feature-Oriented Domain Analysis) [19] propõe uma modelo de features para linhas de produto, em que são aplicadas primitivas de agregação e generalização para capturar as semelhanças das aplicações no domínio em termos de abstrações. O FORM (Feature-Oriented Reuse Method) [20] define a modelagem de features como uma extensão do modelo do FODA[19]. Sua estrutura é direcionada para auxiliar o desenvolvimento da arquitetura do domínio e de componentes. Estes dois métodos são apresentados em uma única seção por apresentarem o mesmo conceito de modelagem. Inicialmente, as features são identificadas através do conhecimento do domínio obtido dos especialistas do domínio, e de outras fontes, tais como documentações e sistemas existentes. Em seguida, as features são categorizadas em quatro perspectivas: i) capacidade, ii) ambiente operacional, iii) tecnologia do domíno, e iv) técnica de implementação. A capacidade caracteriza um serviço, operação, função ou desempenho que uma aplicação pode possuir. Eles podem ser subdividas em funcionais e não funcionais. O ambiente operacional representa atributos do ambiente em que uma aplicação é usada e operada. Tecnologia do domínio e técnica de implementação representam detalhes de implementação em um nível mais técnico e baixo, sendo que o primeiro representa características especificas do domínio, e o segundo representa características genéricas. Após a categorização, as features são analisadas e organizadas, construindo o modelo de features, que representa features padrões de uma família de sistemas no domínio e a relação entre elas. As features são relacionadas através de um grafo hierárquico AND/OR, com

36 36 relações dos to tipo: obrigatória, opcional, alternativa, composto-de, especialização/generalização, e implementado-por. O termo features alternativas indica que não mais que uma especialização em um grupo de features pode ser feita para o sistema. Algumas regras de composição complementam o diagrama de features. Features opcionais e alternativas que não podem ser selecionadas quando uma feature é selecionada deve ser declarada com a expressão mutuamente exclusiva com. Features opcionais e alternativas que devem ser selecionadas quando uma feature é selecionada deve ser definida usando a expressão requer. As razões para as features também são representadas no modelo, como pode ser vista na Figura 12. A representação mais detalhadas deste modelo pode ser vista na Figura 13. Figura 12: Exemplo de modelo de features [19].

37 Figura 13: Modelo de Features [20] 37

38 38 Este modelo possui especificações de requisitos em níveis abstratos, e por isso deve ser agregado a outros modelos para permitir uma base de conhecimento adequado para o desenvolvimento da linha de produto. Em um domínio maior, é difícil manter o gerenciamento dessas features, pois o modelo torna-se complexo. O modelo também possui o problema de ambigüidade, direcionando a diferentes interpretações. Por exemplo, na Figura 14, a feature de controle de entrada (admittance Control) tem duas features alternativas: acesso cartão magnético(magnet Card Access) e acesso a PIN (PIN Access), mas essa representação leva à diferentes interpretações: Cada uma das aplicações deve suportar exatamente um dos controles de entrada? Uma aplicação deve suportar ambos os tipos de controle de entrada. O usuário decide qual tipo de controle usará. Uma aplicação deve suportar um dos tipos ou ambos os tipos de controle de entrada. Figura 14: Exemplo de modelo de features para o domínio de segurança de casa [5] 3.5 Baseada em Caso de Uso Os casos de uso têm sido muito eficientes para modelar os requisitos funcionais de sistema único [3]. Para ser utilizado em linhas de produto de software, é necessário adaptações que para representar as variabilidades do domínio, permitindo a instanciação das aplicações. A seguir são apresentados alguns métodos para casos de uso no contexto de SPL. Diversas abordagens apresentam soluções para casos de uso, tais como [3], [18], [31] e [32]. Entretanto, neste trabalho serão apresentadas apenas as abordagens [3] e [18] por possuírem propósitos diferenciados, enquanto a [31] e [32] possuem o mesmo objetivo de [3].

39 PLUS O PLUS (Product Line UML-Based Software Engineering) [3] descreve a variabilidade do domínio através de casos de uso e modelos de features. O método classifica os casos de uso em três tipos: casos de uso obrigatórios (kernel), que são necessários para todos os membros da LPS; casos de uso opcionais, que são necessários para apenas alguns membros da LPS; e casos de uso alternativos, onde diferentes casos de uso são necessários para diferentes membros da linha de produto. Além dos casos de uso, os atores também podem apresentar variabilidade. Assim, os atores podem ser opcionais, alternativos ou obrigatórios.. Um exemplo da representação desses tipos pode ser vista na Figura 15. Figura 15: Tipos de Casos de Uso [3] Os casos de uso são documentados seguindo um modelo padrão, como segue: Nome caso de Uso: para cada caso de uso é dado um nome. Categoria de Reuso: especifica se o caso de uso é obrigatório, alternativo, ou opcional. Sumário: descrição breve do caso de uso. Atores: atores do caso de uso. Dependência: seção opcional que descreve se um caso de uso depende de outro, ou seja, se a relações extends ou include. Pré-condições: especifica uma ou mais condições que devem ser verdadeiras para iniciar o caso de uso.

40 40 Descrição: descreve as seqüências principais do caso de uso. Esta descrição é em forma de entrada do ator, seguida por resposta do sistema. O sistema é tratado como uma caixa preta, portanto não se deve descrever como o sistema faz internamente para responder para o ator. Alternativas: descreve seqüências alternativas do fluxo principal. Pontos de variação: seção opcional que define os lugares na descrição do caso de uso onde diferentes funcionalidades podem ser introduzidas para diferentes membros da linha de produto. Mais detalhes sobre essa seção será apresentado a seguir. Pós-condições: seção que descreve as condições que são sempre verdadeiras no final do caso de uso, se a seqüência principal tem sido seguida. Questões fora de série: documenta questões sobre o caso de uso para serem discutidas com os usuários. O PLUS trata as variações de duas formas. Para pequenas variações, o ponto de variação é descrito no próprio caso de uso, indicando o lugar no caso de uso onde a mudança ocorreu. Isto pode incluir uma linha ou uma seqüência alternativa. Quando o caso de uso se torna complexo devido à quantidade de alternativas, é necessário definir as variações em outros casos de uso e definir relações include ou extend. Em representações de pequenas variações, as seguintes informações devem ser fornecidas: Nome do ponto de variação. Tipo de funcionalidade que será inserida no ponto de variação. Esses tipos podem ser opcional, alternativo obrigatório e alternativo opcional. Linha no caso de uso descreve onde a variabilidade pode ser inserida. Descrição da funcionalidade inserida no ponto de variação. Funcionalidade alternativa ou opcional pode ser incluída no ponto de variação. Um ponto de variação que especifica funcionalidade opcional descreve funcionalidades que pode ou não ser fornecidas por um dado membro da linha de produto. Se a opção identificada pelo ponto de variação for selecionada para um produto, então esta funcionalidade será inserida no local identificado no ponto de variação. Um ponto de variação que especifica funcionalidade alternativa descreve muitas possíveis funcionalidades alternativas, uma das quais deve ser inserida no local do caso de uso especificado pelo ponto de variação. Quando uma das alternativas deve sempre ser selecionada, então a funcionalidade possui o tipo alternativo obrigatório. Se for possível não escolher uma alternativa, então seu tipo é alternativo opcional. Em pontos de variações complexas, as seqüências alternativas ou opcionais são divididas em caso de uso separado. Se o novo caso de uso for uma alternativa do ponto de variação,

41 41 então ele será estendido do caso de principal, se as condições apropriadas forem satisfeitas. É importante destacar que o caso de uso base não depende da extensão do caso de uso e pode funcionar independentemente. A extensão do caso de uso, por outro lado, só funciona se a condição no caso de uso base for satisfeita. No caso de uso base os pontos de extensões são definidos para indicar o local exato onde uma ou mais extensão deve ser incluída. Um exemplo de relação extend com ponto de extensão é mostrado na Figura 16. Figura 16: Exemplo de ponto de extensão [3]. Relações includes são usadas para suportar casos de uso opcionais. Estes casos de uso opcionais, ou de inclusão, possuem características abstratas, ou seja, o caso de não pode ser executado sozinho. Quando o caso de uso base inclui este novo caso de uso obedecendo a uma condição de inclusão. Um exemplo da relação de inclusão pode ser visto na Figura 17. Após a definição dos casos de uso, o PLUS propõe a construção do modelo de features a partir de grupos de casos de uso que compartilham similaridades. Mais delathes sobre esse processo pode ser encontrado em [3]. Portanto, o PLUS fornece diretrizes suficientes para modelar os requisitos funcionais e as variabilidades da LPS baseada em casos de uso, e orientada como derivar features a partir de casos de uso. No entanto, os modelos propostas para a especificação não representam as razões dos requisitos, nem diferentes visões dos stakeholders.

42 42 Figura 17: exemplo de caso de uso de inclusão [3] PuLSE-CAVE Muitas vezes a linha de produto é iniciada a partir de produtos predecessores, tais como linha de produtos existente, sistemas legados ou sistemas em desenvolvimento. Assim, os artefatos já existentes podem ser usados como base de conhecimento para o desenvolvimento da linha de produto. Fantechi et al. [18] define a abordagem PuLSE 6 -CaVE (Commonality and Variability Elicitation) para derivar requisitos de linha de produto em forma de casos de uso, a partir da análise de documentos de usuários de sistemas existentes, como pode ser visto na Figura 18. Com esta abordagem é possível identificar features comuns e variáveis, elementos de caso de uso, tarefas, e requisitos. O PuLSE-CaVE é dividido nas fases seguintes: Preparação: compreende a coleta de documentos existentes; seleção dos documentos que cobrem a variabilidade da linha de produto; divisão destes documentos em partes gerenciáveis e comparáveis; e decisão sobre a quantidade de variabilidade nas partes definidas. Busca: as partes dos documentos identificadas são analisadas, e os elementos dos casos de uso são buscados através de heurísticas. Os elementos de casos de uso que podem ser identificados são: nomes, atores, metas, pré-condições, pós-condições, etapas do fluxo principal, e etapas do fluxo secundário. Seleção, mudança e modificação: os elementos dos casos de uso são selecionados, checados e ajustados pelo especialista do domínio. 6 PuLSE (Product Line Software Engineering) é uma framework definido pelo Fraunhofer IESE para desenvolver linhas de produto de software.

43 43 Figura 18: Capturando informações legadas para construção de casos de uso [18]. As primeiras duas etapas podem ser executadas por pessoas que têm pouco entendimento do domínio, eles não precisam ser o especialista do domínio. A terceira etapa requer o envolvimento do especialista do domínio para validar as entidades da documentação que foram selecionadas. A visão geral da abordagem pode ser vista na Figura 19. Figura 19: Visão geral da abordagem PuLSE-CaVE [18]. As heurísticas utilizadas para identificar os elementos comuns e variáveis dos casos de uso são: Títulos de seções ou subseções tipicamente contêm nomes de casos de uso;

44 44 Frases como apenas por, por usar, no caso de podem ser marcadas como précondições dos casos de uso; Pré-condições e metas dos casos de uso podem ser encontradas no início dos capítulos; Pré-condições podem ser encontradas antes ou na descrição do caso de uso; Frases como normalmente, frequentemente, com a exceção, exceto podem marcar os fluxos secundários dos casos de uso; As listas enumeradas ou com marcadores são marcados como um processo ordenado do fluxo principal, e descreve o caso de uso; Sentenças que descrevem interações com o sistema na forma de para fazer isto...faça isso... são descrições do caso de uso; Voz passiva é tipicamente um marcador para atividade do sistema. Estas sentenças podem ser utilizadas na descrição do caso de uso. As variabilidades e semelhanças nos elementos dos casos de uso podem ser encontradas com as heurísticas seguintes: Elementos arbitrários que ocorrem apenas em um manual de usuário provavelmente são elementos opcionais; Títulos ou subtítulos que ocorrem em apenas uma das documentações pode ser um caso de uso opcional; Títulos ou subtítulos que têm nomes diferentes ou ligeiramente diferentes, mas que ocupam o mesmo lugar na tabela de conteúdos, são possíveis casos de uso alternativos; Frases que diferem em apenas uma ou poucas palavras podem ser evidências para alternativas; Se valores numéricos diferem, então eles podem ser variabilidades paramétricas; Itens de menu que são escritos em apenas alguns dos documentos podem ser uma funcionalidade opcional ou alternativa (casos de uso ou partes deles);

45 45 Figura 20: Exemplo de elementos de casos de uso identificados em manual do usuário [18]. A efetividade desta técnica depende da padronização dos documentos do usuário. Se os documentos são estruturados de maneira diferente, torna-se difícil aplicar as heurísticas para encontrar variabilidades e semelhanças.

46 Modelo de Variabilidade Ortogonal Pohl et al. [5] propõe um modelo de variabilidade ortogonal (MVO), que representa variabilidade em um diagrama (Variability Diagram) e relaciona suas entidades com as variações dos artefatos de requisitos, definindo explicitamente a variabilidade da linha de produto. O MVO é proposto também para resolver problemas encontrados em diversos artefatos de requisitos para SPL, tais como modelo de features e casos de uso. No modelo de features, Pohl el al. [5] aponta o problema de representação de agrupamento de features. Por exemplo, na Figura 21, as features Câmera Surveillance e Outdoor Câmera Surveillance não podem ser agrupadas apenas com o modelo de features. Através do modelo de variabilidade ortogonal, o problema de agrupamento pode ser resolvido, relacionando o agrupamento com uma variação do modelo. Figura 21: Agrupamento de Features [5]. Na especificação de requisitos textual, há uma forte expressividade dos requisitos, contudo, o uso de linguagem natural direciona também ao problema de ambigüidade. Estes documentos expressam a variabilidade por palavras chaves ou frases, por exemplo: O sistema de segurança da casa deve ser equipado com câmeras coloridas ou preta e branca capazes de capturar imagens infra-vermelho. Neste exemplo, não está claro se apenas câmeras coloridas, ou ambas os tipos devem ser capazes de fotografar infra-vermelho. Assim,

47 47 a esta forma de documentação de variabilidade deixa aberturas para ambigüidade. Para evitar a ambigüidade, a variabilidade deve ser definida de forma explícita, como o exemplo da figura 22. Figura 22: Variabilidade em especificação de requisito textual [5]. No entanto, se for necessário utilizar esse ponto de variação em outras partes do documento, será necessário reescrever o texto. Assim, o MVO pode ser utilizado para solucionar esse problema, como pode ser visto na Figura 23. Figura 23: Modelando variabilidade ortogonal em requisitos textuais [5]. O MVO também permite a representação de variabilidade em modelos de caso de uso, tais como cenários de casos de uso (Figura 24), diagrama de seqüência (Figura 25), diagrama de caso de uso (Figura 26). Outros diferentes modelos também são representados através da variabilidade, tais como diagrama de fluxo de dados, diagrama de classes, diagramas de máquina de estado. Todos os artefatos de requisitos são relacionados com um único diagrama

48 48 de variabilidade de maneira que facilite a rastreabilidade, facilitando as futuras mudanças nos requisitos. Figura 24: Representação do Cenário do Caso de Uso [5]. Figura 25: Representação no Diagrama de Seqüência [5].

49 49 Figura 26: Representação em Diagrama de Caso de Uso [5]. A proposta de MVO é viável quando existe uma ferramenta de suporte para manter a ratreabilidade dos artefatos de requisitos que são relacionados com o diagrama de variabilidade. Ao contrário, é complexo gerenciar a grande quantidade de artefatos e de requisitos relacionados com um único modelo de variabilidade.