ANÁLISE DE REQUISITOS EM LINHAS DE PRODUTO DE SOFTWARE

Transcrição

1 ANÁLISE DE REQUISITOS EM LINHAS DE PRODUTO DE SOFTWARE THIAGO FERNANDES LINS DE MEDEIROS Universidade Federal de Pernambuco RECIFE, 02 DE AGOSTO DE 2009

2 THIAGO FERNANDES LINS DE MEDEIROS ANÁLISE DE REQUISITOS EM LINHAS DE PRODUTO DE SOFTWARE Monografia apresentada ao Curso de pósgraduaçã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 02 de Agosto de 2008

3 Resumo A fim de obter software de qualidade e com alta produtividade, é necessário, cuidadosamente, analisar, modelar, especificar e gerenciar os requisitos do sistema. O reuso de software é uma abordagem muito promissora para se alcançar o aumento de produtividade e garantir a qualidade dos sistemas desenvolvidos. Linha de Produto de Software é uma abordagem para reuso de software que tem mostrado bons resultados para se alcançar estes objetivos. No contexto da engenharia de requisitos aplicada a linhas de produto de software, este trabalho busca identificar as principais técnicas para a análise de requisitos dentro de um processo de engenharia de requisitos para linhas de produtos e apresentar um comparativo entre as abordagens identificadas. Palavras-chave: Engenharia de Requisitos, Linha de Produto de Software, Análise de Requisitos, Modelo de Variabilidade. 3

4 Sumário Resumo... 3 Sumário... 4 Lista de Figuras Introdução Fundamentação Teórica Linha de Produtos de Software (LPS) Engenharia de Requisitos Métodos para Análise de Requisitos em LPS Modelo de Features Modelo de Variabilidade Ortogonal (MVO) Modelo de Variabilidade Orientado a Aspectos Modelo de Variabilidade Multi-paradigma Discussão e Conclusão Referências Bibliográficas

5 Lista de Figuras Figura 1: Artefatos de uma LPS (1) e os produtos gerados a partir do reuso desses artefatos (2, 3 e 4)... 9 Figura 2: Atividades Essenciais de uma Linha de Produto de Software Figura 3: Exemplo de Modelo de Features Figura 4: Notação Gráfica do Modelo de Variabilidade Ortogonal Figura 5: Variabilidade em Requisitos Textuais Figura 6: MVO Associado a Modelo de Features Figura 7: MVO Associado a Casos de Uso Figura 8: MVO Associado a Diversos Artefatos de Requisitos Figura 9: Sistema de Segurança Eletrônica Modelado Com a Linguagem ADORA Figura 10: Combinação de Paradigmas e Variabilidade

6 1. Introdução O uso de computadores e produtos de software tem aumentado enormemente nos últimos anos. Existe um aumento na demanda, além da complexidade do software necessário. A fim de obter produtos de alta qualidade, juntamente com uma maior produtividade, é necessário, cuidadosamente, analisar, modelar, especificar e gerenciar requisitos de sistema. Isto não só simplificaria o projeto e a implementação do sistema, mas também reduziria o número de defeitos que são identificados mais tarde na fase de implementação. Engenharia de Requisitos é introduzida para resolver estas questões no início do processo de desenvolvimento. Um processo de engenharia de requisitos bem estabelecido assegura que os requisitos de sistema são devidamente elicitados, analisados, documentados, verificados e gerenciados. Várias outras tentativas têm sido realizadas para aumentar a produtividade e a qualidade dos produtos de software. Uma abordagem muito promissora é o reuso de software. Linha de Produto de Software (LPS) é uma abordagem para reuso de software, que foca no desenvolvimento de uma família de sistemas. O objetivo principal é desenvolver um framework que representa a família, que é então customizado para desenvolver produtos específicos. Uma família de produtos é uma coleção de produtos semelhantes, que compartilham a maioria das funcionalidades. Assim, existem inúmeros requisitos que são comuns em toda a família, mas outros são únicos para cada produto. Portanto, um processo de engenharia de requisitos bem estabelecido é essencial para qualquer linha de produto [Kuloor & Eberlein, 2002]. No contexto da engenharia de requisitos aplicada a linhas de produto de software, este trabalho busca identificar as principais técnicas para a análise de requisitos dentro de um processo de engenharia de requisitos para linhas de produtos e apresentando uma discussão entre as abordagens identificadas. Assim, na seção seguinte é apresentada a fundamentação teórica, descrevendo conceitos relevantes para o entendimento de Linha de Produtos de Software e de Engenharia de Requisitos neste contexto. A Seção 3 apresenta técnicas para a análise dos requisitos de uma linha de produto e na Seção 4 é apresentada uma discussão e conclusão a respeito das 6

7 abordagens estudadas. Por fim, a Seção 5 contém as referências bibliográficas utilizadas neste trabalho. 7

8 2. Fundamentação Teórica 2.1 Linha de Produtos de Software (LPS) Linhas de produtos de software surgem no final da década de 90 como uma nova tendência a ser explorada e começa a ser vista como um dos avanços mais promissores para o desenvolvimento de software eficiente [Clements & Northrop, 2001]. Até então, o processo de reuso de software seguia apenas a direção da Engenharia de Domínio (ED), que 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 [Mili et al., 2002]. Em 1999 Bayer et al. propõe uma metodologia para Engenharia de Linha de Produto de Software (PuLSE) e define três razões básicas que tornam a ED menos efetiva que a LPS: (i) escopo equivocado da área de aplicação; (ii) lacunas de orientação operacional; (iii) foco excessivo nos assuntos organizacionais [Bayer et al., 1999]. A metodologia foi desenvolvida com o propósito de permitir a concepção e implantação de linhas de produto de software dentro de uma grande variedade de contextos empresariais. Segundo o [SEI, 2007], uma Linha de Produto de Software é um conjunto de sistemas intensivos de software, que compartilham um conjunto comum de features 1 para satisfazer necessidades específicas de um segmento de mercado particular, e que são desenvolvidos a partir de um conjunto de artefatos básicos, de maneira bem definida. Assim, em uma LPS, é feito um planejamento de que características comuns serão reutilizadas entre os produtos que serão desenvolvidos (diferente do que acontece em sistemas únicos, nos quais o reuso não é planejado, é oportunista, como quando um simples trecho de código de um produto existente é reutilizado em um novo produto) e, a partir desse planejamento, são construídos os artefatos comuns (core assets) (1 na Figura 1) que, posteriormente, são utilizados para gerar os diversos 1 Features são características ou funcionalidades do sistema visíveis ao usuário 8

9 produtos da linha (2, 3 e 4 na Figura 1). Como mostrado na Figura 1, nenhum dos produtos gerados é igual ao outro, cada um deles possui variações específicas. Figura 1: Artefatos de Uma LPS (1) e os Produtos Gerados a Partir do Reuso Desses Artefatos (2, 3 e 4) Desse modo, 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 [Clements & Northrop, 2001]. Contudo, iniciar uma linha de produtos de software é uma decisão de negócio que não deve 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 artefatos básico (core assets). Inicialmente os custos da linha de produto são um pouco maiores que os benefícios, pois, muitos dos custos estão associados com a sua implantação. Os 9

10 benefícios, por outro lado, aumentam a cada entrega de produto. Uma vez que a abordagem esteja estabelecida, a produtividade da organização acelera, e então os benefícios superam os custos. Mudanças tecnológicas, 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 [Clements & Northrop, 2001]. De acordo com o framework proposto pelo SEI (Software Engineering Institute), uma linha de produto é composta por três atividades essenciais [SEI, 2007]: 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 2. 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. 10

11 Figura 2: Atividades Essenciais de uma Linha de Produto de Software Na seção seguinte é apresentada uma visão geral da engenharia de requisitos aplicada a linhas de produto de software, apresentando as diferenças da engenharia de requisitos tradicional. 2.2 Engenharia de Requisitos A parte mais difícil da construção de um sistema de software é decidir precisamente o que construir. Nenhuma parte do trabalho conceitual é tão difícil quanto estabelecer os requisitos técnicos detalhados. Nenhuma parte do trabalho prejudica tanto o sistema resultante se ele estiver errado. Nenhuma parte é tão difícil de corrigir mais tarde [Brooks, 1987]. A incapacidade de produzir requisitos de software completos, corretos e sem ambigüidade ainda é considerada a maior causa de falha de software hoje em dia [Dorfman, 1997]. Requisitos são descrições do que o sistema deve fazer, como ele deve se comportar, as propriedades que ele deve exibir, as qualidade que deve possuir, e as 11

12 restrições que o sistema e seu desenvolvimento devem satisfazer. O Institute of Electrical and Electronics Engineers (IEEE) define um requisito como: 1. Uma condição ou capacidade necessária para solucionar um problema ou atingir um objetivo de um usuário; 2. Uma condição ou capacidade que deve ser atendida ou estar presente em um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto; 3. Uma representação documentada de uma condição ou capacidade como na definição 1 ou 2 [IEEE, 1990]. Engenharia de requisitos enfatiza o uso de técnicas sistemáticas e repetíveis que assegurem a completude, consistência e relevância dos requisitos do sistema [Sommerville, 1997]. A engenharia de requisitos é composta basicamente por cinco atividades: Elicitação de requisitos: é o processo de descoberta, revisão, documentação e entendimento das necessidades e restrições dos usuários para o sistema. Análise de requisitos: é o processo de refinamento das necessidades e restrições dos usuários. Especificação de requisitos: é o processo de documentação das necessidades e restrições dos usuários de forma clara e precisa. Verificação de requisitos: é o processo de assegurar que os requisitos do sistema são completos, corretos, consistentes e claros. Gerenciamento de requisitos: é o processo de programar, coordenar, e documentar as atividades da engenharia de requisitos, que são, elicitação, análise, especificação e verificação [Dorfman, 1997]. Para se aplicar a engenharia de requisitos ao contexto das linhas de produtos, devem ser levadas em conta as diferenças existentes entre se desenvolver um sistema único e uma linha de produtos, já que na LPS, os requisitos constituem um importante 12

13 artefato e que podem ser de tipos diferentes. Podem ser requisitos comuns, que representam os requisitos de toda a linha de produtos, ou 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. Abaixo são apresentadas as principais diferenças entre engenharia de requisitos para uma linha de produto e para um sistema único [Pohl et al., 2005]: Elicitação de Requisitos para linhas 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 13

14 atualizado, os 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. Como pode ser visto, a análise de requisitos em linhas de produtos é uma das atividades mais importantes no processo de engenharia de requisitos, sendo uma atividade fundamental para o desenvolvimento da linha, pois é a atividade responsável por identificar a variabilidade dos requisitos e analisar seu impacto tanto arquitetural quanto econômico. Na próxima seção serão introduzidas abordagens para a análise dos requisitos em linhas de produtos de software. 14

15 3. Métodos para Análise de Requisitos em LPS Nesta seção serão apresentadas diferentes abordagens para a análise dos requisitos de uma linha de produtos de software, ou seja, formas de identificação e representação adequada da variabilidade. 3.1 Modelo de Features O modelo de features foi proposto em 1990, como parte do método FODA (Feature-Oriented Domain Analysis) [Kang, 1990] e integrando também o método FORM (Feature-Oriented Reuse Method) [Kang, 1998]. Mesmo tendo sido proposto inicialmente para a análise de domínio, ela continua sendo até hoje uma prática muito utilizada em linhas de produto de software e parte integrante de diversos estudos de sua utilização em conjunto com outras técnicas. O objetivo da análise de features é capturar um entendimento dos usuários finais e clientes a respeito das capacidades gerais de aplicações em um domínio. O foco da análise deve ser na perspectiva do usuário final com relação as funcionalidades da aplicação, isto é, os serviços providos pelas aplicações e o ambiente operacional em que o sistema está inserido. O principal interesse na análise dos requisitos para uma linha de produtos está em identificar as similaridades de uma família de aplicações, então o modelo de features deve capturar as features em comum e as diferenças entre as aplicações de uma linha. O modelo de features serve acima de tudo, como um meio de comunicação entre usuários e desenvolvedores. Para os usuários, o modelo de features mostra quais são as funcionalidades padrão do sistema, quais são as outras funcionalidades que eles podem escolher e quando elas podem ser escolhidas. Para os desenvolvedores, o modelo de features indica o que necessita ser parametrizado na arquitetura da LPS e como essa parametrização deve ser feita. 15

16 O modelo é constituído de agrupamentos lógicos de features, ou seja, grupos de funcionalidades de mesmo interesse. As features podem ser obrigatórias, alternativas ou opcionais. Por exemplo, as features automatic e manual são alternativas e a feature air-conditioning é opcional, como indicado na Figura 3 por pequenos arcos e círculos, respectivamente. Features alternativas podem ser imaginadas como especializações de uma categoria mais geral. As features alternativas servem para indicar que no máximo uma especialização pode ser feita para um grupo de features de um 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. A seleção de features opcionais ou alternativas não é feita de modo arbitrário. Ela é feita normalmente baseada em objetivos ou interesses dos usuários finais e clientes. Figura 3: Exemplo de Modelo de Features 16

17 3.2 Modelo de Variabilidade Ortogonal (MVO) Abordagens como o FODA e FORM são adequadas para documentar tanto as funcionalidades similares quanto as variáveis de uma linha de produtos. Entretanto, isto pode levar a modelos enormes e complexos. Devido a isto, Pohl et al. propõe um modelo de variabilidade ortogonal [Pohl et al., 2005] que representa apenas os aspectos variáveis de uma linha de produtos, reduzindo o tamanho do modelo e também a complexidade. Além disso, o MVO pode ser utilizado para documentar a variabilidade de diversos tipos de artefatos como requisitos textuais, outros tipos de modelos e até casos de testes. Os principais conceitos do MVO são os pontos de variação (o que varia) e as variantes (como ele varia). Cada ponto de variação tem que possuir pelo menos uma variação. Na Figura 4 temos a notação gráfica do modelo de variabilidade ortogonal. Em seguida exemplos da utilização do MVO para a resolução de problemas em artefatos de requisitos são apresentados. Figura 4: Notação Gráfica do Modelo de Variabilidade Ortogonal Requisitos textuais expressam a variabilidade através de palavras chaves ou frases. A documentação da variabilidade dos requisitos dessa forma deixa espaço para 17

18 ambigüidades, ou seja, um problema que pode levar a uma análise errada do sistema. Por exemplo: O sistema de segurança da casa deve ser equipado com câmeras coloridas ou preta e branca capazes de capturar imagens em infravermelho. Neste exemplo, não está claro se apenas câmeras coloridas, ou ambos os tipos devem ser capazes de fotografar em infravermelho. A Figura 5 ilustra essa variabilidade definida de forma explícita, evitando a ambigüidade. Figura 5: Variabilidade em Requisitos Textuais O MVO também pode ser utilizado em conjunto com outros modelos para representar a variabilidade, como modelo de features (Figura 6), diagramas de casos de uso (Figura 7), cenários de casos de uso, diagramas de seqüência. Dessa forma, todos os artefatos de requisitos ficam relacionados com um único diagrama de variabilidade, facilitando possíveis mudanças nos requisitos e também a rastreabilidade (Figura 8). 18

19 Figura 6: MVO Associado a Modelo de Features Figura 7: MVO Associado a Casos de Uso 19

20 Figura 8: MVO Associado a Diversos Artefatos de Requisitos Então, as principais vantagens em se adotar o uso do MVO são: Melhora da comunicação: abstrações de alto nível de artefatos variáveis simplificam a comunicação da variabilidade da linha de produtos. Melhora na tomada de decisões: desenvolvedores têm que tomar decisões conscientes para introduzir variabilidade explicitamente. Melhora na rastreabilidade: as dependências entre os artefatos variáveis podem ser facilmente encontradas empregando o uso de associações de restrição. 20

21 3.3 Modelo de Variabilidade Orientado a Aspectos Segundo Stoiber, as linguagens de modelagem atuais como UML não suportam a modelagem de variabilidade. Resultado em duas alternativas não satisfatórias. Representar todas as similaridades e variantes em um único modelo e identificar todas as variantes de forma manual, sem auxilio de restrições de modelagem, levando a modelos imprecisos e errôneos. Ou então, criar uma modelo separado para cada variante de produto, o que significa que todos os requisitos comuns devem ser replicados em cada variante de produto, criando redundância e como conseqüência, ineficiência e inconsistência do modelo [Stoiber et al., 2007]. Desenvolvimento de software orientado a aspectos lida com os interesses transversais (crosscutting concerns) em sistemas de software. Estes interesses não podem ser separados de outros interesses pela forma de modularização convencional, ou seja, fazem parte de vários outros módulos e não podem ser modularizados através de técnicas como orientação a objetos. Uma separação e modularização antecipada dos interesses transversais favorece o aumento da qualidade e reduz custos de manutenção e evolução. Além disso, diversos estudos enfatizam as similaridades entre desenvolvimento orientado a aspectos e a engenharia de linhas de produto de software [Loughran et al., 2005], [Nyssen et al., 2005], [Mezini et al., 2006], [Siy et al., 2007]. A fim de resolver problemas de precisão, eficiência e consistência, Stoiber propõe uma abordagem para a análise dos requisitos, aplicando modelagem de variabilidade orientada a aspectos utilizando a linguagem ADORA [Glinz et al., 2002]. Inicialmente são modeladas as similaridades e objetos abstratos são criados para os componentes. Em seguida, todas as variantes são modeladas como um bloco de aspecto (um retângulo com duas bordas cortadas), como pode ser visto na figura 9. Os detalhes das variantes são representados através de diagramas de estados e diagramas de cenários, descrevendo o comportamento e interação do usuário do componente. Retângulos com bordas arredondadas representam os estados e os círculos ovais representam os cenários, que constituem casos de uso ou passos do caso de uso na notação UML. 21

22 Figura 9: Sistema de Segurança Eletrônica Modelado Com a Linguagem ADORA A semântica da variabilidade também é mostrada na Figura 9. Para o mecanismo de abertura da porta (Open the Door) têm-se duas opções, Open Door by Keypad e Open Door by Figerprint Reader e uma deve ser escolhida. Estes dois cenários são modelados com o símbolo O, representando que pelo menos uma deve ser escolhida ou que ambas são possíveis (ou lógico). Para as duas variantes de Open Door by Keypad, os cenários são identificados com um X, indicando que apenas uma das duas é possível (ou-exclusivo lógico). 3.4 Modelo de Variabilidade Multi-Paradigma De acordo com Laguna, a idéia original do modelo de features é tentar representar, simultaneamente, diferentes modelos de variabilidade como variabilidade estrutural, variabilidade comportamental, variabilidade não-funcional, etc. Portanto, a diferenciação destes diferentes aspectos, separando-os em diferentes modelos, pode trazer benefícios para o desenvolvimento da linha de produtos [Laguna, 2008]. Basicamente, os requisitos de uma LPS podem ser organizados em requisitos comportamentais, que representam funcionalidades ou serviços, e decisões de projeto que descrevem como o sistema deve se comportar em situações particulares. Propõe- 22

23 se então que os aspectos estruturais sejam representados por modelos de domínio (diagramas de classe UML); os aspectos comportamentais sejam expressos através de modelos de casos de uso UML; os requisitos não funcionais sejam analisados com modelos orientados a metas (goal models); e que o modelo de features seja utilizado como um modelo central, interligado a todos os outros modelos, expressando os diferentes aspectos de variabilidade. A engenharia de requisitos orientada a metas (Goal Oriented Requirements Engineering GORE) propõe uma modelagem explicita das intenções do sistema (os porquês ). As principais vantagens destas abordagens é que elas podem ser usadas para estudar alternativas nos requisitos (utiliza modelos AND/OR para as diferentes alternativas), além de permitir o relacionamento entre requisitos funcionais e nãofuncionais. Uma meta é um objetivo que o sistema sob análise deve atingir [van Lamsweerde, 2001]. Existem dois tipos de metas (goals): hardgoals, que representam requisitos funcionais e podem ser verificados objetivamente e os softgoals, utilizados para a representação de requisitos não-funcionais e que são verificados de forma subjetiva. Este modelo é ideal para uma representação mais abstrata dos interesses da linha de produto, pois está mais relacionado com os problemas a serem resolvidos e, portanto, mais relacionado com os clientes. Os modelos UML são diagramas convencionais que são organizados em pacotes. Em [Laguna et al., 2007], é proposta uma técnica em que as features similares são organizadas em pacotes base, e cada feature opcional em um pacote inclui um conjunto de diagramas UML que são a solução para alcançar essa feature. As variantes de plataforma, ambiente operacional em que as aplicações funcionarão e serão usadas, devem ser consideradas em um segundo estágio, já que a maioria dos pontos de variação são independentes do ambiente operacional. Contribui com isto o paradigma da engenharia orientada a modelos (Model Driven Engineering MDE), que faz a separação do modelo independente de plataforma (PIM) do modelo especifico de plataforma (PSM). A Figura 10 apresenta um resumo da combinação de todos os paradigmas. 23

24 Figura 10: Combinação de Paradigmas e Variabilidade O modelo de metas representa a intenção da linha produto, isto é, os objetivos de alto nível que a aplicação deve solucionar, e as características nãofuncionais. O modelo de features representa os requisitos funcionais do usuário final, conectada aos hardgoals do modelo de metas. Os modelos UML organizam a arquitetura da LPS, ligada ao modelo de features. As features que configuram o ambiente operacional devem ser consideradas em ultimo estagio, com a adoção do paradigma da engenharia orientada a modelos. 24

25 4. Discussão e Conclusão O mercado de software está cada vez mais competitivo e exigente. Torna-se necessário o desenvolvimento de software com alta qualidade e produtividade, além de redução de custo e tempo de entrega dos sistemas. Linha de Produto de Software é uma abordagem de reuso que busca alcançar estes objetivos, criando uma família de produtos que podem ser customizados em massa. Tanto para o desenvolvimento de um sistema único, quanto para uma linha de produtos, a engenharia de requisitos tem um papel importantíssimo, tendo a função de conseguir traduzir as necessidades dos clientes em sistemas que resolvam seus problemas. Em linhas de produtos, a variabilidade dos requisitos é um dos pontos principais a ser levado em consideração e sua análise deve ser feita de forma cuidadosa. Neste trabalho foram apresentadas diferentes abordagens para a análise dos requisitos de uma linha de produtos, ou seja, como analisar a variabilidade dos requisitos. A seguir, são feitas algumas considerações a respeito das abordagens apresentadas. Dentre as técnicas que foram abordadas, o modelo de features é a forma mais utilizada para representar a variabilidade e a que apresenta o maior nível de maturidade, apresentando diversos relatos de uso na indústria. Entretanto, a modelagem de features apresenta características visíveis ao usuário em um nível alto de abstração, pois seu maior objetivo é orientar a tomada de decisão entre as variabilidades do domínio, facilitando a identificação do reuso e parametrização de outros artefatos. No entanto, este tipo de representação é insuficiente para especificar os requisitos de maneira que direcione o desenvolvimento da LPS, não descrevendo os comportamentos do sistema. Park et al. [Park et al., 2004] diz que abordagens orientadas a features não mostram diretamente os resultados da análise de variabilidade e semelhanças de maneira que satisfaça os objetivos de alto nível de 25

26 negócio da organização. Além disso, os benefícios do modelo de features dependem do tamanho do domínio, pois sua modelagem hierárquica em uma única visão torna-se inviável em uma LPS complexa, com um grande número de features. Diante deste cenário, algumas abordagens têm integrado este modelo com outras modelagens de requisitos, tais como a proposta baseada em casos de uso de [Gomaa, 2005], e a abordagem baseada em metas e cenários de [Park et al., 2004]. A proposta do modelo de variabilidade ortogonal enfrenta grandes problemas no que diz respeito ao suporte ferramental. Torna-se inviável manter a rastreabilidade dos artefatos de requisitos que são relacionados com o diagrama de variabilidade sem uma ferramenta adequada para essa função, devido à complexidade em gerenciar a grande quantidade de artefatos e requisitos relacionados com um único modelo de variabilidade. A abordagem orientada a aspectos de Stoiber apresenta uma vantagem na utilização de uma linguagem própria para a modelagem de aspectos. Por outro lado, os modelos criados são normalmente maiores e mais complexos que os modelos de features, por exemplo. E isto pode prejudicar, por parte dos clientes, o entendimento dos modelos nas primeiras fases de negociação dos requisitos da linha de produtos. No método de Laguna, as diversas representações de diferentes pontos de vista podem auxiliar no entendimento da linha de produtos por todos os envolvidos no processo de desenvolvimento. Desde clientes a desenvolvedores, provendo um modelo com nível adequado de abstração para cada um. Porém, a grande quantidade de modelos criados pode acabar burocratizando a técnica, já que diversos modelos terão que ser criados e mantidos. 26

27 5. Referências Bibliográficas (Bayer et al., 1999) Bayer, J.; Flege, O.; Knauber, P.; Laqua, R.; Muthig, D.; Schmid, K.; Widen, T. & DeBaud, J. (1999), PuLSE: A Methodology to Develop Software Product Lines, in ACM SIGSOFT Symposium o Software Reusability, pp (Brooks, 1987) Brooks, F. "No Silver Bullet: Essence and Accidents of Software Engineering." Computer 20, 4 (April 1987): (Clements & Northrop, 2001) Clements, P. & Northrop, L. (2001), Software Product Lines: Practices and Patterns, Addison-Wesley (Dorfman, 1997) Dorfman, M. & Thayer, R. H. Software Requirements Engineering. Los Alamitos, CA: IEEE Computer Society Press, 1997 (Glinz et al., 2002) Glinz, M., Berner, S., and Joos, S.: Object-Oriented Modeling with ADORA. Information Systems, 27 (6) (Gomaa, 2005) Gomaa, H. (2005), Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures, Addison-Wesley. (IEEE, 1990) Institute of Electrical and Electronic Engineers. IEEE Standard Glossary of Software Engineering Terminology (IEEE Std ). New York, NY: Institute of Electrical and Electronics Engineers, 1990 (Kang, 1990) Kang, K.; Cohen, S.; Hess, J.; Novak, W.; & Peterson, A. Feature-Oriented Domain Analysis (FODA) Feasibility Study (CMU/SEI-90-TR-021, ADA235785). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1990 (Kang, 1998) Kang, K.; Kim, S.; Lee, J.; Shin, E.; & Huh, M. "FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures." Annals of Software Engineering 5, 5 (September 1998):

28 (Kuloor & Eberlein, 2002) Kuloor, C. and Eberlein, A. (2002). "Requirements Engineering for Software Product Lines," Proceedings of the 15th International Conference on Software and Systems Engineering and their Applications (ICSSEA'02), Paris, France (Laguna et al., 2007) Laguna, M. A., Gonzáles-Bauxauli, B., and Marqués, J. M. Seamless Development of Software Product Lines: Feature Models to UML Traceability. GPCE 07. Salzburg, Austria 2007 (Laguna, 2008) Laguna, M. A., Gonzáles-Bauxauli, B. Product Line Requirements: Multi- Paradigm Variability Models. Anais do WER08 - Workshop em Engenharia de Requisitos, Barcelona, Catalonia, Spain, Setembro 12-13, 2008, pp (Loughran et al., 2005) Loughran, N., Sampaio, A., Rashid, A.: From Requirements Documents to Feature Models for Aspect Oriented Product Line Implementation. Workshop on MDD in Product Lines at MODELS (Mezini et al., 2006) Mezini, M. and Ostermann, K.: Variability management with feature-oriented programming and aspects. 12th ACM SIGSOFT International Symposium on Foundations of Software Engineering. Newport Beach, USA (Mili et al., 2002) Mili, H.; Mili, A.; Yacoub, S. & Addy, E. (2002), Reuse-Based Software Engineering, Willey, pp. 636 (Nyssen et al., 2005) Nyssen, A., Tyszberowicz, S., and Weiler, T.: Are aspects useful for managing variability in software product lines? A case study. Aspects and Software Product Lines: An Early Aspects Workshop, at SPLC-Europe (Park et al, 2004) Park, S.; Kim, M. & Sugumaran, V. (2004), A scenario, goal and feature-oriented domain analysis approach for developing software product lines, in, pp (13) 28

29 (Pohl et al., 2005) Pohl, K.; Böckle, G. & van der Linden (2005), Software Product Line Engineering:Foundations, Principles, and Techniques, Springer (SEI, 2007) Software Engineering Institute (SEI), A Framework for Software Product Line Practice, Version 5.0, (Siy et al., 2007) Siy, H., Aryal, P., Winter, V., and Zand, M Aspectual Support for Specifying Requirements in Software Product Lines. Workshop on Early Aspects at ICSE. Minneapolis,USA (Sommerville, 1997) Sommerville, I. & Sawyer, P. Requirements Engineering: A Good Practice Guide. New York, NY: John Wiley & Sons, 1997 (Stoiber et al., 2007) Stoiber, R., Meier, S., and Glinz, M Visualizing Product Line Domain Variability by Aspect-Oriented Modeling. In Proceedings of the Second international Workshop on Requirements Engineering Visualization (October 15-19, 2007) (Van Lamsweerde, 2001) Van Lamsweerde, A. Goal-Oriented Requirements Engineering: A Guided Tour, IEEE Symposium Requirements Engineering, 2001, pp