Linha de Produtos de Software: Conceitos e Ferramentas

Transcrição

1 Capítulo 3 Linha de Produtos de Software: Conceitos e Ferramentas Juliana Alves Pereira, Eduardo Figueiredo, Heitor Costa Abstract Software Product Line (SPL) is a development method for software reuse that has been increasingly used due to the ability to minimize the costs and maximize the quality of software artifacts. Although many tools are available to support SPL, students and junior developers do not hold enough knowledge about these tools to achieve the expected benefits of SPL. To address this problem, this chapter aims to introduce the concepts of SPL, focusing on supporting tools for management of its variability. We restrict our discussion to five tools that support the development of SPL, namely SPLOT, FeatureIDE, XFeature, fmp and pure::variants. The expected benefits and potential pitfalls of the use of these tools are discussed. Our goal is to provide an overview of various tools, but with particular focus on SPLOT tool which is used to illustrate the activities of creating a feature model and product configuration. Finally, we summarize a discussion on the potential benefits and drawback of SPL adoption. Resumo Linha de Produtos de Software (LPS) é um método de desenvolvimento que vem sendo difundido e utilizado por causa da capacidade de minimizar os custos e de maximizar a qualidade de software pelo reúso de artefatos. Apesar de muitas ferramentas para apoiar LPS estarem disponíveis, há estudantes e profissionais que não as conhecem suficientemente para alcançarem os benefícios esperados pela implantação de uma LPS. Assim, este capítulo visa à introdução dos conceitos de LPS com foco em cinco ferramentas para gerência de variabilidade em LPS: SPLOT, FeatureIDE, XFeature, fmp e pure::variants. Os benefícios esperados e as potenciais armadilhas pela utilização destas ferramentas são discutidos. O objetivo é fornecer uma visão geral de várias ferramentas, mas com foco particular na ferramenta SPLOT que é utilizada para criação de modelos de características e configuração de produtos. Por fim, uma discussão sobre o potencial do método de desenvolvimento baseado em LPS é apresentado nas conclusões.

2 3.1. Introdução Linha de Produtos de Software (LPS) é um método para sistematizar o reúso de software [Pohl et al 2005]. A mudança para o desenvolvimento baseado em reúso foi uma resposta às exigências de menores custos de desenvolvimento e manutenção, de sistemas de maior qualidade e de entregas mais rápidas de sistemas [Sommerville 2011], o que colabora para aumento na satisfação dos clientes [Dursckil et al 2004]. Uma LPS é um conjunto de sistemas de software definidos sobre uma arquitetura comum e que compartilham um mesmo conjunto de características (features) [Sommerville 2011]. Essas características compartilhadas pelos sistemas de um mesmo segmento de mercado são responsáveis pela satisfação de necessidades específicas dos clientes [Software Engineering Institute]. LPS surge como alternativa viável de desenvolvimento de sistemas de software que permite às empresas rápida entrada no mercado por fornecerem capacidade de customização em massa [Software Engineering Institute]. Grandes empresas de software, tais como, Celsius Tech 1, Nokia 2, Philips 3 e Avaya Telecom 4, adotaram LPS para desenvolver seus produtos [Dursckil et al 2004]. Com isso, o processo de desenvolvimento de sistemas de software começa a ter novo enfoque, diferente do utilizado tradicionalmente, visando ao reúso sistemático e ao cumprimento de exigências específicas dos clientes. O reúso sistemático de sistemas de software consiste de uma mudança da abordagem de desenvolvimento de sistemas únicos para o desenvolvimento de famílias de sistemas [AHEAD]. Com esse enfoque, promete-se obter ganhos na produtividade, produtos mais confiáveis e preço mais acessível. O conceito de desenvolvimento de sistemas de software em famílias consiste basicamente na criação e na manutenção de uma LPS que servirá como base para o desenvolvimento de um conjunto de sistemas relacionados a partir de artefatos comuns [Clements e Northrop 2002] [Pohl et al 2005]. Contudo, para apoio durante o desenvolvimento desta família de sistemas, são necessárias ferramentas de configuração e de gerência de variabilidade, tais como, SPLOT [Mendonça et al 2009], FeatureIDE [Thum et al 2012], XFeature [Pasetti e Rohlik 2005], fmp [Generative Software Development Lab 2012] e pure::variants. Estas ferramentas desviam o foco de um desenvolvimento convencional para uma abordagem de desenvolvimento baseada na composição de artefatos e na modelagem do domínio. Neste capítulo, os objetivos são abordar os conceitos teóricos fundamentais que envolvem LPS, mostrar algumas das ferramentas utilizadas para a configuração e gerência de variabilidade em LPS e apresentar um exercício prático com a ferramenta SPLOT [Mendonça et al 2009] com o intuito de fixar os conceitos abordados. SPLOT é uma ferramenta Web, gratuita e de código fonte aberto. Ela é utilizada para criação de modelos de características e configuração de produtos. No site da ferramenta, encontrase um repositório com centenas de modelos de características criados por usuários da ferramenta ao longo de 3 anos. Além disso, é disponibilizada uma versão em que é possível instalar o SPLOT em uma máquina particular para garantir a proteção dos

3 dados. É possível baixar o código da ferramenta e do SPLAR (biblioteca Java criada para realizar a análise de modelos de características). Existe ainda uma função interessante chamada Configuration Workflow, controlada por um workflow, que permite a configuração sistemática de um produto por diversas pessoas envolvidas no projeto. O restante deste capítulo está estruturado da seguinte forma. O objetivo, prérequisitos e o público alvo estão destacados na Seção 3.2. Introdução a reúso de software e a LPS é apresentada na Seção 3.3. Algumas ferramentas para desenvolvimento de LPS são abordadas na Seção 3.4. A funcionalidade da ferramenta SPLOT é detalhada na Seção 3.5. Conclusões são discutidas na Seção Objetivo, Pré-requisitos e Público Alvo Técnicas de desenvolvimento baseada em LPS vem crescendo e se intensificando cada vez mais no mercado. Assim, neste capítulo, o principal objetivo é a introdução de conceitos de LPS bem como a sua aplicação prática utilizando uma ferramenta para gerenciamento de LPS. Espera-se que os leitores tenham conhecimento prévio em Programação Modular ou Programação Orientada a Objetos. Além disso, é desejável o conhecimento básico de Engenharia de Software. O público alvo é estudantes de graduação e pós-graduação e profissionais de diversas áreas que trabalham com desenvolvimento de sistemas de software. Trata-se de um tema que envolve conhecimento de Engenharia de Software, mas traz uma visão multidisciplinar do desenvolvimento de sistemas de software. Além dos leitores aprenderem os conceitos e princípios de LPS, espera-se que eles obtenham experiência prática no uso de ferramentas para LPS por meio de um exercício com a ferramenta SPLOT [Mendonça et al 2009] Reúso de Software com Linha de Produtos de Software A crescente necessidade de desenvolvimento mais ágil de sistemas de software maiores e mais complexos resultou em aumento significativo nas exigências por sistemas de software de melhor qualidade [Kang et al 1998] [Pohl et al 2005]. Ao longo dos últimos vinte anos, muitas técnicas foram desenvolvidas para oferecer suporte a reúso de software. Estas técnicas exploram os fatos dos sistemas, no mesmo domínio de aplicação, serem semelhantes e terem potencial para reúso [Sommerville 2011]. Uma das abordagens mais promissoras para o reúso é Linhas de Produto de Software (LPS) [Pohl et al 2005] Linhas de Produto de Software As LPS têm sido cada vez mais utilizadas como forma de reusar componentes de sistemas de software entre aplicações semelhantes [Clements e Brownsword 1996] [Clements e Northrop 2002]. Essa vantagem é alcançada, pois a sua arquitetura é projetada de um modo bem específico: características comuns a um domínio formam o núcleo e outras características definem pontos de variação [Jacobson et al 1997]. Uma LPS é um conjunto de sistemas de software que compartilham um conjunto comum de características, que atendam às necessidades específicas de um determinado segmento de mercado e são desenvolvidas a partir de um conjunto comum de bens essenciais de

4 uma forma prescrita [Pohl et al 2005]. Ela pretende explorar as semelhanças e as diferenças dentro de uma família de sistemas em um campo particular de aplicação e fornece uma infra-estrutura para a derivação membros comuns dessa família [Mendonça 2009]. É comum encontrar empresas que mantenham ou desenvolvam sistemas de software a partir do mesmo segmento ou domínio. Este elevado grau de semelhança entre esses sistemas permite a utilização do modelo de LPS com melhorias significativas nos seus processos de desenvolvimento [Birk et al 2003]. Portanto, as LPS estão a emergir como um processo de desenvolvimento viável e importante, que permite às empresas a entrada rápida no mercado, resposta flexível e fornecem uma capacidade de customização em massa [Software Engineering Institute]. Utilizando LPS, o processo de desenvolvimento de sistemas de software começa a ter novo enfoque, diferente do utilizado tradicionalmente, visando ao favorecimento do reúso e ao cumprimento de exigências específicas dos clientes. Esse novo enfoque promete ganho de produtividade e produto com mais confiabilidade e qualidade, em menor tempo e a preço mais acessível, o que colabora para aumento considerável na satisfação dos clientes [Brito e Colanzi 2008] [Dursckil et al 2004]. Assim, o reúso sistemático de sistemas software consiste de uma mudança da abordagem de construção de sistemas únicos para o desenvolvimento de famílias de sistemas [Brito e Colanzi 2008] Modelos de Características Modelo de característica é o padrão de fato para representar a variabilidade de uma LPS e o espaço de possíveis configurações dos produtos dentro de uma família de sistemas [Bagheri 2010] [Czarnecki e Kim 2005]. Modelos de variabilidade estão presentes em quase todas as fases e atividades do ciclo de vida de LPS, como a análise do domínio da aplicação, escopo, seleção de produtos, derivação do produto, tempo de execução e evolução [Mendonça et al 2009]. Assim, o modelo de característica tem papel vital em LPS, fornecendo visão esquemática para representação de semelhanças e pontos de variabilidade dentro de uma família de sistemas [Mendonça 2009]. Um modelo de característica é composto basicamente por diagrama de características, regras de composição e análise relacional [Mendonça 2009]. Um diagrama de característica permite a visualização de recursos hierárquicos de uma LPS e suas relações [Mendonça et al 2009]. Para verificar a variabilidade de um produto, pode-se utilizar diagramas de características e suas representações gráficas [Kang et al 1998]. Em geral, as características estão organizadas nos diagramas de características utilizando Árvores [Sochos et al 2004] e Grafos Acíclicos Direcionados [McKay et al 2004]. Essas características podem ser classificadas como obrigatórias (presentes nos produtos extraídos da LPS), opcionais (não necessariamente presentes nos produtos extraídos da LPS) ou alternativas (conjunto de características exclusivas ou não exclusivas). As regras de composição são responsáveis pela validação das combinações de características, ou seja, garantem a correta semântica entre as combinações realizadas [Van Gurp et al 2001]. A análise relacional faz recomendações indicando a melhor situação para que uma determinada característica seja ou não selecionada.

5 Um método existente para análise de domínio é Feature-Oriented Domain Analysis (FODA) [Kang et al 1998], que utiliza de um diagrama de características para mostrar as características identificadas e suas relações. Um modelo de recursos de um sistema, denominado MobileMedia [Figueiredo et al 2008], é apresentado na Figura 1. Os nós representam as características e as arestas as relações entre elas. Um único nó raiz, MobileMedia, representa o conceito de domínio modelado. As características opcionais são representadas com um círculo vazio, por exemplo, Receive Photo, e podem ou não fazer parte do produto. Por outro lado, as características obrigatórias, por exemplo, Media Management, são representadas por círculos cheios e aparecem nos produtos que contenham a característica pai. Características alternativas podem ser exclusivas (XOR) ou não exclusivas (OR). A primeira indica que apenas uma sub-característica pode ser selecionada a partir das características alternativas, por exemplo, Screen1, Screen2 e Screen3 são características alternativas para Screen Size e apenas uma deve ser selecionada. A segunda indica que uma ou mais características podem ser selecionadas, por exemplo Photo, Music e Video são características alternativas para a Media Selection e todas ou um subconjunto delas podem ser selecionadas. Figura 1. Modelo de Características MobileMedia Além das características e seus relacionamentos, um modelo de características pode incluir regras de composição referentes a restrições adicionais para combinações de características [Benavides et al 2006]. Ela é responsável por validar uma combinação de características independentes, ou seja, inclui restrições adicionais às características e suas relações [Czarnecki e Kim 2005]. Restrições (cross-tree constraints) são normalmente de inclusão ou de exclusão enunciadas da forma: se a característica F for incluída, então a características X também deve ser incluída (ou excluída) [Benavides et al 2006]. Por exemplo, o modelo de característica apresentado na Figura 1 mostra uma restrição entre SMSTransfer e CopyMedia. Isto é, se receber uma foto via SMS, esta foto deve ser copiada para o álbum.

6 3.4. Ferramentas para Desenvolvimento de LPS Grandes empresas de software adotaram LPS para desenvolver seus produtos [Sharp 1998]. O conceito de desenvolvimento de sistemas de software em famílias consiste na criação e na manutenção desses sistemas relacionados a partir de um conjunto comum de artefatos [Clements e Northrop 2002] [Pohl et al 2005]. As ferramentas de modelagem de características, tais como, SPLOT [Mendonça et al 2009], FeatureIDE [Thum et al 2012], XFeature [Pasetti e Rohlik 2005], fmp [Generative Software Development Lab 2012] e pure::variants, devem ser utilizadas para apoiar o desenvolvimento dessas famílias de sistemas e suportam a composição de artefatos em vez de fornecer uma abordagem de desenvolvimento convencional. Entretanto, o processo de escolha de uma dessas ferramentas que melhor atende aos objetivos desejados durante a implementação de uma LPS está longe de ser trivial por causa das muitas opções disponíveis. Nesta seção, as ferramentas SPLOT [Mendonça et al 2009], FeatureIDE [Thum et al 2012], XFeature [Pasetti e Rohlik 2005], fmp [Generative Software Development Lab 2012] e pure::variants para desenvolvimento de modelos de características são brevemente introduzidas. Além disso, são apresentadas suas principais funções a fim de apoiar a escolha de uma das ferramentas que melhor satisfaçam as expectativas para o desenvolvimento de uma LPS SPLOT SPLOT [Mendonça et al 2009] é uma plataforma aberta, baseada na Web e que promove a pesquisa colaborativa em LPS. A plataforma oferece aos pesquisadores várias ferramentas para editar, analisar e configurar modelos de características além de um repositório com modelos de características criados pelos usuários da ferramenta ao longo dos últimos 3 anos. Além disso, é oferecida uma versão da ferramenta independente que pode ser instalada em uma máquina particular que inclui o recurso de Configuração de Workflow. A página inicial do SPLOT é apresentada na Figura 2. As seguintes funções estão disponíveis: i) Editor do modelo de característica; ii) Configuração do produto; iii) Análise automática; iv) Repositório do modelo de características; e v) Workflow de configuração de características. Além dessas funções, SPLOT apresenta código fonte livre, que pode ser personalizado e/ou continuado por indivíduos ou grupos interessados em desenvolver novas funções e apoiar a ideia de LPS. Por fim, pode-se ter acesso aos parceiros de pesquisa, bem como trabalhos desenvolvidos relacionados ao SPLOT. As funções do SPLOT estão detalhadas na Seção FeatureIDE FeatureIDE [Thum et al 2012] é um framework baseado em Eclipse, amplamente utilizado e que abrange várias atividades no processo de desenvolvimento de LPS. Esse framework está integrado a várias ferramentas de composição e de anotação, tais como, AHEAD, FeatureHouse [Apel et al 2009], Feature C++ [Apel et al 2005], DeltaJ [Schaefer et al 2010], AspectJ [Colyer et al 2004], Munge [Munge Development Team], Antenna [Schaefer et al 2010] e CIDE [Kastner et al 2008], e a muitas linguagens, por exemplo, Java, C++, Haskell, C, C#, JavaCC e XML [Kastner et al 2008]. FeatureIDE

7 foi desenvolvido para suportar programação orientada a aspectos e programação orientada a características [Batory et al 2004] [Kiczales et al 1997] e fornece interface de usuário coerente e automatização das tarefas [Thum et al 2012]. Figura 2. Página Inicial do SPLOT FeatureIDE fornece um editor de modelo de característica com suporte a recursos abstratos (recursos não pertencem a artefatos de implementação). Por exemplo, a característica Favourites do modelo de características apresentado na Figura 3 é uma característica abstrata. O modelo de característica pode ser construído graficamente pela adição e remoção de características no editor gráfico (Figura 3). Como modelos de característica podem mudar ao longo do tempo, na ferramenta FeatureIDE, é permitido mover uma característica e suas sub-características para uma nova característica pai. Os modelos de características criados com FeatureIDE são armazenados em um formato XML. Os usuários podem editar o modelo de características graficamente e/ou textualmente e esses modelos podem ser armazenados em diversos formatos gráficos ou impressos em um arquivo.pdf. Um modelo de características pode conter cross-tree constraints. Para isso, FeatureIDE fornece um editor em que as restrições podem ser criadas ou editadas. Esse editor é enriquecido com um assistente de conteúdo para fácil manuseamento, bem como verificações de validade sintática e semântica. As restrições são construídas no FeatureIDE conforme é apresentado na Figura 4; por exemplo, verificações podem detectar características mortas. Essas características e suas sub-características, se houverem, não farão parte de qualquer uma das instâncias possíveis da LPS. Além do formato de visualização em diagrama (Figura 3), no FeatureIDE, pode-se visualizar o modelo de características em formato outline (Figura 5). O editor de configuração mostrado na Figura 6 recebe como entrada o modelo de características e oferece opções de configuração. O usuário seleciona as características e o produto é configurado e salvo em um arquivo de configuração. Múltiplas configurações podem ser criadas e uma deve ser marcada como atual. O editor de configuração oferece suporte aos desenvolvedores na criação de configurações válidas. Além disso, apenas as escolhas de configurações válidas podem ser configuradas (propagação de decisões) [Mendonça 2009]. Por exemplo, uma característica obrigatória

8 no modelo de características não pode ser eliminada e duas características alternativas não podem ser selecionadas ao mesmo tempo. Figura 3. Editor do Modelo de Características Figura 4. Tela de Criação e Edição de Restrições Após criação do modelo de características, é realizada a implementação dos sistemas de software desejados, com mapeamento entre os artefatos de implementação e as características. Esse mapeamento é necessário para gerar automaticamente um sistema de software com base em uma seleção de características. Utilizando o modelo de características, uma configuração válida e artefatos de implementação, sistemas de software podem ser gerados pelo FeatureIDE. O processo de desenvolvimento é realizado no IDE Eclipse [Thum et al 2012].

9 Figura 5. Formato outline do modelo de características. Figura 6. Tela para configuração do produto no FeatureIDE XFeature XFeature [Pasetti e Rohlik 2005] é uma ferramenta de modelagem implementada como um plug-in do Eclipse, cujo objetivo principal é automatizar a modelagem e a configuração de artefatos reusáveis. Essa ferramenta está disponível como software livre e aberto (sob a licença GNU - General Public License) para download no site do projeto [XFeature]. Inicialmente, XFeature foi criado para auxiliar o desenvolvimento de aplicações espaciais, mas, de maneira geral, suporta o desenvolvimento baseado em LPS. Focado na criação de modelos e meta-modelos, XFeature está em fase de testes e é raramente utilizado na indústria de software. XFeature é usada para construir um modelo de um conjunto de ativos de sistemas software configuráveis. Esse modelo tem uma estrutura de árvore em que cada nó representa uma característica e cada característica pode ser descrita por um conjunto de sub-características, representadas como nós filhos. Essa ferramenta apresenta flexibilidade durante a representação gráfica dos modelos de característica e é projetada para ser parametrizada com um modelo de exibição que define como os elementos

10 individuais do modelo de característica (os nós do diagrama de característica, as linhas que ligam os nós pais aos nós filhos, etc.) devem ser processados graficamente [Pasetti e Rohlik 2005]. A tela da área de edição do modelo de características é apresentada na Figura 7 e está dividida em três partes: i) área de edição de nós, onde o usuário pode adicionar ou excluir nós para o modelo de características (Figura 7a); ii) área de edição de propriedades, onde o usuário pode editar os valores das propriedades de cada característica (Figura 7b); e iii) área de exibição do nó de árvore,onde o usuário pode navegar sob a estrutura da árvore do modelo de característica (Figura 7c). Na prática, a interface de edição inclui outras áreas (por exemplo, barras de comando e áreas de gestão de projetos e arquivos). XFeature é uma ferramenta extremamente flexível por permitir controle do usuário na escolha dentre as configurações suportadas. Figura 7. Interface do XFeature [Pasetti e Rohlik 2005] Feature Modeling Plugin (fmp) Semelhante ao XFeature, fmp [Kastner et al 2008] é uma ferramenta implementada como plug-in do Eclipse com características puramente acadêmica, sendo utilizada no auxílio ao desenvolvimento de LPS, desenvolvida na Universidade de Waterloo e possui integração com o Rational Software Modeler (RSM) e o Rational Sofrware Architect (RSA), ambos da família de produtos da IBM 5. O projeto dessa ferramenta encontra-se descontinuado. O fmp facilita a modelagem de suas características pelo usuário ao permitir sua modelagem baseada em cardinalidade. Essa ferramenta possui recursos de geração de código na definição de seu meta-modelo do modelo de características, mas, apesar de utilizar notação simples, é pouco intuitiva. Na Figura 8, são apresentadas as funções disponibilizadas pela ferramenta, tais como, seleção de característica obrigatória, opcional, grupos de características, instâncias, edição das propriedades das 5 Família de produtos IBM Rational:

11 características e configuração de restrições. Somente o formato em estilo de árvore é disponibilizado para visualização e edição do modelo de características manipulado. Figura 8. Interface do fmp [Generative Software Development Lab 2012] Pure::variants Desenvolvido pela Pure Systems 6, uma empresa especializada no desenvolvimento de software baseado em reúso, o pure::variants é uma das ferramentas para o desenvolvimento de LPSs mais maduras que se pode encontrar atualmente. Pode ser utilizada como um plug-in do Eclipse e integrada a algumas ferramentas comerciais, como o Enterprise Architecht 7 e IBM Rational Rhapsody 8. O pure::variants é uma ferramenta utilizada no suporte à modelagem, implementação, implantação e desenvolvimento (atividades de análise). Sua arquitetura é cliente-servidor, tendo como cliente o plug-in do Eclipse IDE utilizado pelo usuário e como servidor um aplicativo C++ rodando em background. Encontra-se disponível na Internet uma versão gratuita com algumas restrições em sua utilização

12 A interface do modelo de características é apresentada na Figura 9 e possui as seguintes informações: i) características obrigatórias (representadas por!); ii) características alternativas OR (representadas por X); e iii) características opcionais (representadas por? ). Sua arquitetura é definida pela notação FODA [Kang et al 1998]. A ferramenta permite visualizar a mesma interface de edição na opção de modo tabela. Essa opção apresenta mais informações da característica manipulada, tais como ID, nome único, nome visível e tipo. A tela de configuração de produtos da LPS utilizando seleção de características é apresentada na Figura 10. Figura 9. Interface do pure::variants Figura 10. Tela de Configuração de Produtos no pure::variants Pure::variants tem como pontos positivos variabilidade de editores e wizards, tornando-a uma ferramenta versátil e, de maneira geral, mais organizada e completa.

13 Além disso, ela oferece uma linguagem proprietária alternativa e intuitiva, voltada para usuários comuns Funcionalidade da Ferramenta SPLOT Nesta seção, são detalhadas as principais funções da ferramenta SPLOT. O editor de modelo de características é apresentado na Seção A funcionalidade para configuração do produto é discutida na Seção A análise automática de modelo de características é apresentada na Seção O funcionamento do repositório de modelos de características é mostrado na Seção O workflow de configuração de características é tratado brevemente na Seção Editor do Modelo de Características Durante a edição de um modelo de características na ferramenta SPLOT, duas opções estão disponíveis: i) criar um novo modelo; e ii) editar um modelo existente. A interface da ferramenta SPLOT que contém essas opções é apresentada na Figura 11. Ao escolher a opção Criar um novo modelo, a tela para edição de um novo modelo de características é apresentada (Figura 12). Além do editor de modelos, essa tela possui: i) uma tabela com informações das características; ii) restrições (constraints); iii) informações do modelo; iv) visualização estatística; e v) análise da consistência. Figura 11. Opções de Edição do Modelo de Características A representação de um modelo de características é no formato de árvore. A tela de informações das características é utilizada no momento da edição do modelo, para melhor documentar as características. As restrições são formas de validar combinação de características independentes e a adição de informações para o modelo criado é necessário para salvar o modelo no repositório SPLOT. Com essas informações, pode-se identificar o modelo criado e alterá-lo. A visualização estatística do modelo contabiliza os tipos de características (por exemplo, quantidade de características e características mandatórias, opcionais e alternativas). A análise de consistência permite identificar características mortas, caso existam, bem como a validade do modelo criado. As demais

14 opções são: i) configurar modelo de características; ii) exportar modelo de características (formato XML); e iii) salvar modelo no repositório. Figura 12. Editor do Modelo de Características Após a criação de um modelo de características (Figura 13), pode-se realizar alterações no modelo. Para acessar o menu de restrições, deve-se clicar com o botão direito do mouse em qualquer lugar da restrição. As alterações são realizadas ao clicar com o botão direito do mouse sobre o nome da característica e escolher uma das opções disponíveis (por exemplo, criar ou excluir características). Quando uma característica é renomeada ou excluída, as restrições referentes a essa característica são automaticamente atualizadas ou excluídas. Além disso, pode-se visualizar as estatísticas e a consistência (clicar em Run Analysis ) do modelo de características criado (Figura 14). Antes de armazenar o modelo de características em um repositório, deve-se verificar (i) sua consistência, (ii) a quantidade de características (mínimo 10), (iii) a não existência de características mortas e (iv) o preenchimento adequado dos campos obrigatórios da tabela de informações Configuração do Produto Para configuração de produtos, deve-se clicar sobre o ícone de configuração disponível no editor de modelo de característica (Figura 12). Um redirecionamento é realizado para a tela que contém o repositório SPLOT, em seguida, deve-se selecionar o modelo de característica criado para ser possível configurar um produto (Figura 15). Nesta tela, duas opções estão disponíveis para cada característica do modelo: i) selecionar característica (indicado pelo símbolo ); e ii) remover característica (indicado pelo símbolo ). No momento da configuração, as técnicas de autocompletar são automaticamente realizadas. Por exemplo, ao selecionar uma das características alternativas Screen 1, Screen 2 ou Screen 3, automaticamente, as demais são removidas do produto. Ao lado do modelo, uma tabela é disposta com os passos realizados pelo usuário durante a configuração do produto.

15 Figura 13 Alterar modelo de característica. Figura 14 Análise estatística e de consistência do modelo de característica. Além da configuração interativa, SPLOT suporta a pesquisa em um catálogo de produtos baseada em características. Assim, é feita uma busca por produtos em catálogos de produtos reais com base em decisões da configuração de características. A busca por um produto laptop no catálogo de produtos é apresentada na Figura 16. Nessa busca, ao marcar ou desmarcar características em um modelo de características, os usuários são capazes de filtrar produtos no catálogo de tal forma que apenas os produtos que correspondem às características configuradas pelos usuários são mostrados. Os usuários têm a garantia de encontrar pelo menos um produto no catálogo que corresponda à sua configuração. SPLOT usa um diagrama de decisão binário para implementar uma busca pelo(s) produto(s) no catálogo, a partir das características selecionadas.

16 Figura 15. Configuração do Produto na Ferramenta SPLOT Figura 16. Pesquisa em um Catálogo de Produtos Análise Automática A análise automática do modelo descreve algumas estatísticas, por exemplo, quantidade de características mandatórias, opcionais e alternativas. Uma tela de análise automática no SPLOT é apresentada na Figura 17. Além dos dados estatísticos, pode-se obter informações de consistência e de métricas para os modelos de características. Estas métricas têm se mostrado úteis para a comparação de modelos de características e consequentes avaliações de suas complexidades.

17 Figura 17. Análise automática do Modelo de Características Repositório do Modelo de Característica Atualmente, o repositório do SPLOT contém aproximadamente 250 modelos de características com aproximadamente características. Os modelos foram extraídos de publicações acadêmicas ou criados por usuários da ferramenta. Eles podem ser editados usando o editor de característica on-line do SPLOT. Uma lista de modelos de características armazenados no repositório do SPLOT é apresentada na Figura 18. A métrica CTCR tem se mostrado útil na análise da complexidade do modelo de características para instancias SAT e é definida como a razão entre a quantidade de características distintas nas restrições e a quantidade de características do modelo de características. Por exemplo, seja um modelo com 10 características, sendo 2 parte de uma restrição única ligada ao modelo (por exemplo, característica_1 implica característica_2). O CTCR para este modelo de características é de 0,2 ou (20%). O objetivo principal do repositório é incentivar o compartilhamento de conhecimento entre os pesquisadores e melhorar a qualidade de pesquisas. A qualidade do repositório de modelos de características é imposta pelas seguintes regras: i) consistência, os modelos são garantidos para ser consistente (contém pelo menos uma configuração válida); ii) correção, os modelos não contêm características mortas; e iii) transparência, os modelos identificam seus autores (ou literatura relacionada) e fornecem algumas informações de contato Workflow de Configuração de Característica Em um workflow, pode-se definir um fluxo de configuração de um produto. Este fluxo é realizado por diversas pessoas envolvidas no projeto de forma sistemática e controlada por meio de um workflow. Assim, cada pessoa pode trabalhar na configuração da parte do modelo sobre a qual tem responsabilidade.

18 Figura 18. Repositório de Modelos de Características 3.6. Conclusão Neste capítulo, foi feita uma introdução aos conceitos de LPS com foco em ferramentas para gerência de variabilidade em LPS. Os benefícios esperados e as potenciais armadilhas pela sua utilização foram discutidos. Além disso, foram apresentadas cinco ferramentas para apoio ao desenvolvimento de LPS: i) SPLOT; ii) FeatureIDE; iii) Feature; iv) fmp; e v) pure::variants. A ferramenta SPLOT foi utilizada para ilustrar mais detalhes, por exemplo, sobre a criação de modelos de características e a configuração de produtos. Agradecimentos Este trabalho recebeu apoio financeiro da FAPEMIG, processos APQ e APQ , e do CNPq processo / Referências AHEAD Tool Suite. Available: < users/schwartz/ats.html>. Accessed: 20/06/2012. Apel, S.; Kästner, C.; Lengauer, C. FeatureHouse: Language-Independent, Automatic Software Composition. In: Int'l Conf. on Software Engineering (ICSE). pp Apel, S.; Leich, T.; Rosenmüller, M.; Saake, G. FeatureC++: On the Symbiosis of Feature-Oriented and Aspect-Oriented Programming. In: Int'l Conference on Generative Prog. and Component Engineering (GPCE). pp

19 Bagheri, E.; Noia, T. D.; Ragone, A.; Gasevic, D. Configuring Software Product Line Feature Models Based on Stakeholders Soft and Hard Requirements. In: Int'l Conf. on Software Product Lines (SPLC). pp Benavides, D.; Ruiz-Cortés, A.; Trinidad, P.; Segura, S. A Survey on the Automated Analyses of Feature Models. In: Jornadas de Ingeniería del Software y Bases de Datos. pp Birk, A., Heller, G., John, I., von der Maßen, T., Müller, K., Schmid, K.: Product Line Engineering Industrial Nuts and Bolts. Fraunhofer IESE, /E, Kaiserslautern Brito, R.; Colanzi, T. Avaliação da adequação do uso de aspectos na implementação de variabilidades de linha de produto de software. Departamento de Informática - Universidade Estadual de Maringá (UEM). 21 p Clements, P.; Brownsword, L.: A Case Study in Successful Product Line Development. Technical Report CMU/SEI-96-TR-0160, Software Engineering Institute Clements, P. e Northrop, L. Software Product Lines: Practices and Patterns. Reading, Addison-Wesley Professional Colyer A.; Clement A.; Harley G.; Webster M. Eclipse AspectJ: Aspect-Oriented Programming with AspectJ and the Eclipse AspectJ Development Tools, 1st Edition., Addison-Wesley Professional, Czarnecki, K.; Kim, C. H. P. Cardinality-Based Feature Modeling and Constraints: A Progress Report. In: International Workshop on Software Factories at OOPSLA. pp Batory, D.; Sarvela, J. N.; and Rauschmayer, A. Scaling Step-Wise Refinement. IEEE Transactions on Software Engineering, Vol. 30, N Dursckil, R.; Spinolal, M.; Burnett, R.; Reinehr, S. Linhas de Produto de Software: riscos e vantagens de sua implantação. VI Simpósio Internacional de Melhoria de Processos de Software Figueiredo, et al. Evolving Software Product Lines with Aspects: An Empirical Study on Design Stability. In: Int'l Conf. on Software Engineering (ICSE). pp Generative Software Development Lab, Disponível em: Acesso em: 30/09/2012. Jacobson I.; Griss M.; Johnson P. Software Reuse: Architecture, Process and Organization for Business success, Addison-Wesley, Kang, K. C.; Kim, S.; Lee, J.; Kim, K.; Shin, E.; Huh, M. FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures. In: Journal Annals of Software Engineering. V. 5. pp Kastner C., Apel S., and Kuhlemann M.. Granularity in software product lines. In Proc. Int l Conf. on Software Engineering, 2008.

20 Kiczales, G.; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, J.; and Irwin, J. Aspect-Oriented Programming, Proceedings of the European Conference on Object-Oriented Programming (ECOOP), pp McKay B. D., Royle G. F., Wanless I. M., Oggier F. E., Sloane N. J. A., and Wilf H. "Acyclic Digraphs and Eigenvalues of -Matrices." J. Integer Sequences 7, Article , Mendonça M., Efficient reasoning techniques for large scale feature models, Ph.D. Thesis, University of Waterloo, Canada, 2009 Mendonça M.; Branco M.; Cowan D. S.P.L.O.T. Software Product Lines Online Tools. In Companion to the 24th ACM SIGPLAN International Conference on Object-Oriented Programing, Systems, Languages, and Applications, OOPSLA 2009, Orlando, Florida, USA. October Munge Development Team. Munge: A Purposely-Simple Java Preprocessor, Website, available online at plugin; visited on January 11th, Pasetti A. (P&P Software GmbH / ETH-Zurich) and Rohlik O. (ETH-Zurich). Technical Note on a CONCEPT FOR THE XFEATURE TOOL, Issue: 1.3.Reference: PP-TN- XFT p. June Pleumann J.; Yadan O.; Wetterberg E. Antenna: An Ant-to-End Solution For Wireless Java, Pohl, K.; Bockle, G.; Linden, F.J.V.D. Software Product Line Engineering: Foundations, Principles and Techniques. Springer pure::variants Eclipse Plug-in User's Guide. Version 2.0 for pure::variants p. Published Schaefer I., Bettini L., Bono V., Damiani F., Tanzarella N., Delta-oriented programming of software product lines, in: Proc. Int l Software Product Line. Conference, SPLC, Springer, Berlin, Heidelberg, New York, London, pp Sharp, D. C. Reducing Avionics Software Cost Through Component Based Product Line Development. Software Technology Conference Sochos P., Philippow I., Riebisch M. "Feature-Oriented Development of Software Product Lines: Mapping Feature Models to the Architecture". In: (Ed.). Object- Oriented and Internet-Based Technologies: Springer Berlin / Heidelberg, v.3263/ Software Engineering Institute. Acesso em: 12/05/2012. Sommerville, I. Engenharia de Softwawe, 9a. Edição. Pearson, pág Thum T. et al. FeatureIDE: An extensible framework for feature-oriented software development, Science of Computer Programming Van Gurp J., Bosch J., Svahnberg M. On the notion of variability in software product lines. Proc. Working IEEE/IFIP Conf. Software Architecture (WICSA 01) XFeature. Acesso em: 20/07/2012.