Linha de Produtos de Software: Conceitos e Ferramentas

Transcrição

1 Capítulo 1 Linha de Produtos de Software: Conceitos e Ferramentas Juliana Alves Pereira 1, Eduardo Figueiredo 1, Heitor Augustus Costa 2 1 Departamento de Ciência da Computação, Universidade Federal de Minas Gerais (UFMG) 2 Departamento de Ciência da Computação Universidade Federal de Lavras (UFLA) {juliana.pereira, figueiredo}@dcc.ufmg.br, heitor@dcc.ufla.br 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 recém formados que não as conhecem suficientemente para alcançarem os benefícios esperados pela implantação de uma LPS. Assim, este documento visa à introdução dos conceitos de LPS com foco em ferramentas para gerência de variabilidade em LPS. Os benefícios esperado e as potenciais armadilhas pela sua utilização de LPS são discutidos. Ademais, o documento apresentada brevemente algumas ferramentas de apoio ao desenvolvimento de LPS, tais como SPLOT, FeatureIDE, XFeature, fmp e pure::variants. O objetivo é apresentar uma visão geral de várias ferramentas mas com foco particular na ferramenta SPLOT. A ferramenta SPLOT será utilizada para criação de modelos de características e configuração de produtos. Por fim, as conclusões fazem uma discussão sobre o potencial do método de desenvolvimento baseado em LPS Introdução Linha de Produtos de Software (LPS) é um método para sistematizar o reúso de software [26]. A mudança para o desenvolvimento baseado em reúso foi uma resposta às exigências de menores custos de desenvolvimento e manutenção, sistemas de maior qualidade e entregas mais rápidas de sistemas [32], o que colabora para aumento na satisfação dos clientes [13]. Uma LPS é um conjunto de sistemas de software definidos sobre uma arquitetura comum e que compartilham um mesmo conjunto de características (features) [32]. Essas características compartilhadas pelos sistemas de um

2 mesmo segmento de mercado são responsáveis pela satisfação de necessidades específicas dos clientes [31]. LPS surge como uma 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 [31]. Grandes empresas de software, tais como, CelsiusTeach, Nokia, Philips e Avaya Telecom, adotaram LPS para desenvolver seus produtos [13]. Com isso, o processo de desenvolvimento 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 software consiste de uma mudança da abordagem de desenvolvimento de sistemas únicos para o desenvolvimento de famílias de sistemas [1]. Com esse enfoque, promete-se obter ganhos na produtividade, produtos mais confiáveis e a preço mais acessível. O conceito de desenvolvimento de software em famílias consiste basicamente na criação e manutenção de uma LPS que servirá como base para o desenvolvimento de um conjunto de sistemas relacionados a partir de artefatos comuns [9] [26]. Contudo, para apoio durante o desenvolvimento desta família de sistemas, são necessárias as ferramentas de configuração e de gerência de variabilidade, tais como, SPLOT [22], FeatureIDE [33], XFeature [24], fmp [15] e pure::variants [27]. 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. O objetivo deste documento é 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 [22] 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, encontra-se 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 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 funcionalidade interessante chamada Configuration Workflow. Esta funcionalidade é controlada por um workflow e permite a configuração sistemática de um produto por diversas pessoas envolvidas no projeto. O restante deste documento está estruturado da seguinte forma. O objetivo, prérequisitos e o público alvo deste texto são destacados na Seção 1.2. A Seção 1.3 faz uma introdução a reúso de software e LPS enquanto a Seção 1.4 apresenta ferramentas para desenvolvimento de LPS. As funcionalidades da ferramenta SPLOT são detalhadas na Seção 1.5 antes de concluirmos o documento 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, o principal objetivo deste documento é 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

3 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 é composto de estudantes de graduação e pós-graduação e de profissionais de diversas áreas que trabalham com desenvolvimento 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 participantes 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 [22] Reuso de Software com Linha de Produtos de Software A crescente necessidade de um desenvolvimento cada vez mais ágil de sistemas de software, cada vez maiores e mais complexos resultou em um aumento significativo nas exigências por software de melhor qualidade [17][26]. 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 de os sistemas, no mesmo domínio de aplicação, serem semelhantes e terem potencial para reuso [32]. Uma das abordagens mais promissoras para o reuso é criar Linhas de Produto de Software (LPS) [26] Linhas de Produto de Software As LPS têm sido cada vez mais utilizadas como forma de reusar componentes de software entre aplicações semelhantes [8][9]. 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 [16]. 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 que são desenvolvidas a partir de um conjunto comum de bens essenciais de uma forma prescrita [26]. Ela pretende explorar as semelhanças e 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 [21]. É comum atualmente encontrar empresas que mantenham ou desenvolvam produtos de software a partir do mesmo segmento ou domínio. Este elevado grau de semelhança entre estes produtos de software permite a utilização do modelo de LPS com melhorias significativas nos seus processos de desenvolvimento [6]. 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 [31]. Através desta técnica, o processo de desenvolvimento de software começa a ter um novo enfoque diferente do utilizado tradicionalmente, visando o favorecimento do reuso e o cumprimento de exigências específicas dos clientes. Este novo enfoque, promete um ganho de produtividade, um produto de maior confiabilidade, qualidade, em um menor tempo e a um preço mais acessível, o que colabora para um aumento considerável na satisfação dos clientes [7][13]. Assim, o reuso sistemático de software consiste de uma mudança da abordagem de construção de sistemas únicos para o desenvolvimento de famílias de sistemas [7].

4 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 de todos os produtos dentro de uma família de sistemas [4][11]. 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 [22]. Assim, o modelo de característica tem um papel vital em LPS, fornecendo uma visão esquemática para representação de semelhanças e pontos de variabilidade dentro de uma família de sistemas [21]. Segundo [21], um modelo de característica é composto basicamente pelo diagrama de característica, regras de composição e análise relacional. Um diagrama de característica permite a visualização de recursos hierárquicos de uma LPS e suas relações [22]. Para verificar a variabilidade de um produto, pode-se utilizar diagramas de características e suas representações gráficas [17]. Em geral, as características estão organizadas nos diagramas de características utilizando Árvores [30] e Grafos Acíclicos Direcionados [20]. Essas características podem ser classificadas como obrigatórias (estão presente em todos os produtos extraídos da LPS), opcionais (não estão necessariamente presentes no produto extraído 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 [34]. A análise relacional faz recomendações indicando a melhor situação para que uma determinada característica seja ou não selecionada. Um método existente para análise de domínio é Feature-Oriented Domain Analysis (FODA) [17], que utiliza de um diagrama de característica para demonstrar as características identificadas e suas relações. A Figura 1 mostra um modelo de recursos de um sistema, denominado MobileMedia [14]. Os nós representam as características e as arestas mostram as relações entre elas. Um único nó raiz, MobileMedia, representa o conceito de domínio que está sendo modelado. Figura 1. Modelo de Característica MobileMedia.

5 As características opcionais são representadas com um círculo vazio, tal como Receive Photo, e elas podem ou não fazer parte do produto. Por outro lado, as características obrigatórias, tais como Media Management, são representadas por círculos cheios. Elas aparecem em todos os 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 alternativas. Por exemplo, Screen1, Screen2 e Screen3 são características alternativas para o Screen Size. A segunda indica que uma ou mais características podem ser selecionada, tais como Photo, Music e Video, que permitem a seleção de mais de uma opção em um produto. Além das características e seus relacionamentos, um modelo de característica também pode incluir regras de composição. As regras de composição referem-se a restrições adicionais para restringir combinações de características [5]. Ela é responsável por validar uma combinação de características independentes, ou seja, inclui restrições adicionais para as características e as suas relações [11]. Restrições (cross-tree constraints) são normalmente de inclusão ou 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)" [5]. Por exemplo, o modelo de característica 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 Ferramentas para Desenvolvimento de LPS Grandes empresas de software já adotaram LPS para desenvolver seus produtos [29]. O conceito de desenvolvimento de software nas famílias consiste na criação e manutenção de sistemas relacionados a partir de um conjunto comum de artefatos [9][26]. Neste contexto, as ferramentas de modelagem de características, tais como SPLOT [22], FeatureIDE [33], XFeature [24], fmp [15] e pure::variants [27], devem ser utilizadas para apoiar o desenvolvimento dessas famílias de sistemas. Essas ferramentas suportam a composição de artefatos em vez de fornecer uma abordagem de desenvolvimento convencional. Entretanto, o processo de escolha de uma destas ferramentas que melhor atende aos objetivos desejados durante a implementação de uma LPS está longe de ser trivial devido às muitas opções disponíveis. Nesta seção nos limitamos a introduzir as ferramentas SPLOT [22], FeatureIDE [33], XFeature [24], fmp [15] e pure::variants [27] para desenvolvimento de modelos de características. Apresentamos suas principais funcionalidades a fim de apoiar a escolha de uma das ferramentas aqui documentadas que melhor satisfaçam as expectativas para o desenvolvimento de uma LPS SPLOT O SPLOT [22] é uma plataforma aberta, baseada na Web que promove a pesquisa colaborativa em LPS. A plataforma atualmente oferece aos pesquisadores várias ferramentas para editar, analisar e configurar modelos de característica além de um repositório com modelos de característica criados pelos usuários da ferramenta ao longo dos últimos 3 anos. Ela oferece também uma versão da ferramenta independente que pode ser instalada em uma máquina particular que inclui o recurso de Configuração de Workflow.

6 A Figura 2 ilustra a página inicial do SPLOT. Como mostrado nesta figura, as seguintes funcionalidades estão disponíveis na ferramenta: (i) Editor do modelo de característica, (ii) Configuração do produto, (iii) Análise automática, (iv) Repositório do modelo de característica e (v) Workflow de configuração de característica. Além destas funcionalidades a ferramenta apresenta código fonte livre, que pode ser personalizado e/ou continuado por indivíduos ou grupos interessados em desenvolver novas funcionalidades e apoiar o paradigma de LPS. Por fim, através da página da ferramenta, temos acesso aos parceiros de pesquisa, bem como trabalhos desenvolvidos relacionados ao SPLOT. Detalharemos as funcionalidades do SPLOT na Seção 1.6. Figura 2. Página inicial do SPLOT FeatureIDE FeatureIDE [33] é um framework baseado em Eclipse, amplamente utilizado, que abrange várias atividades no processo de desenvolvimento de LPS. É integrado com várias ferramentas de composição e de anotação, como AHEAD [1], FeatureHouse [2], Feature C++ [3], DeltaJ [28], AspectJ [10], Munge [23], Antenna [25], CIDE [18], e muitas linguagens, incluindo Java, C++, Haskell, C, C#, JavaCC, e XML [18]. FeatureIDE foi desenvolvido para suportar tanto a programação orientada a aspectos quanto a programação orientada a característica [12][19]. Fornece uma interface de usuário coerente e automatização das tarefas [33]. FeatureIDE fornece um editor de modelo de característica com suporte a recursos abstratos (ou seja, recursos que não pertencem a artefatos de implementação). Por exemplo, a característica Favourites da 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 (ver Figura 3). Como modelos de característica podem mudar fortemente ao longo do tempo, na ferramenta FeatureIDE é permitido mover uma característica (incluindo suas sub-características) para uma nova característica pai. Os modelos de característica criados com FeatureIDE são armazenados em um formato XML. Os usuários podem editar o modelo de característica graficamente e textualmente simultaneamente. Os modelos também podem ser armazenados em diversos formatos gráficos ou impressos em um arquivo PDF.

7 Figura 3. Editor do modelo de característica. Um modelo de característica pode conter cross-tree constraints. Para este fim, FeatureIDE fornece um editor em que as restrições podem ser criadas ou editadas. O editor é enriquecido com um assistente de conteúdo para fácil manuseamento, bem como verificações de validade sintática e semântica. A Figura 4 mostra como as restrições são construídas no FeatureIDE. Por exemplo, estas verificações podem detectar características mortas. Uma características morta significa que ela e as subcaracterísticas, se houver, nunca farão parte de qualquer uma das instâncias possíveis da LPS. Além do formato de visualização em diagrama (Figura 3), a ferramenta permite a visualização do modelo em formato outline como mostrado na Figura 5. O editor de configuração mostrado na Figura 6 recebe como entrada o modelo de característica 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 delas deve ser marcada como atual. O editor de configuração oferece suporte aos desenvolvedores na criação de configurações válidas. Ele indica se uma configuração é válida na etapa de configuração atual. Além disso, apenas as escolhas de configurações válidas podem ser configuradas (propagação de decisões) [21]. Por exemplo, uma característica obrigatória no modelo de característica não pode ser eliminada e duas características alternativas não podem ser selecionados ao mesmo tempo.

8 Figura 4. Tela de criação e edição de restrições. Figura 5. Formato outline do modelo de características.

9 Figura 6. Tela para configuração do produto no FeatureIDE. Após criação do modelo de característica, é realizada a implementação dos sistemas de software desejados, com mapeamento entre os artefatos de implementação e as características. O mapeamento é necessário para gerar automaticamente um sistema de software com base em uma seleção de características. Usando o modelo de característica, uma configuração válida e artefatos de implementação, sistemas de software podem ser gerados automaticamente na ferramenta FeatureIDE. O processo de desenvolvimento é realizado no IDE Eclipse [33] XFeature O XFeature [24] é uma ferramenta de modelagem implementada como um plugin do Eclipse, cujo objetivo principal é automatizar a modelagem e configuração de artefatos reusáveis. A ferramenta está disponível como software livre e aberto (sob a licença GNU - General Public License) para download no site do projeto [35]. Inicialmente, o 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, o XFeature ainda está em fase de testes e é raramente utilizado na indústria de software. A ferramenta é usada para construir um modelo de um conjunto de ativos de 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 filhas. XFeature apresenta flexibilidade durante a representação gráfica dos modelos de característica. Ela é projetado para ser parametrizada com um modelo de exibição e o modelo de exibição define como os elementos 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 [24].

10 A Figura 7 mostra a tela da área de edição do modelo de característica, que é dividida em três partes: (i) A área de edição de nós é onde o usuário pode adicionar ou excluir nós para o modelo de característica (Figura 7 (a)); (ii) A área de edição de propriedades é onde o usuário pode editar os valores das propriedades de cada (Figura 7 (b)); e (iii) A área de exibição do nó de árvore é uma área somente de exposição (ou seja, sem edição) onde o usuário pode navegar sob a estrutura da árvore do modelo de característica. Esta área será normalmente usada para navegar rapidamente na árvore de característica (Figura 7 (c)). Na prática, a interface de edição também inclui outras áreas (por exemplo, barras de comando, as áreas de gestão de projetos e arquivos, etc.). O XFeature é considerado uma ferramenta extremamente flexível por permitir controle do usuário na escolha dentre as configurações suportadas. Figura 7 Interface do XFeature [24] Feature Modeling Plugin (fmp) Semelhante ao XFeature, o fmp [18] é uma ferramenta implementada como plugin do Eclipse, com características puramente acadêmica sendo utilizada no auxílio ao desenvolvimento de LPS. Desenvolvida na Universidade de Waterloo, possui integração com o Rational Software Modeler (RSM) 1 e o Rational Sofrware Architect (RSA) 1. Entretanto, atualmente o projeto encontra-se descontinuado. O fmp facilita a modelagem de suas características pelo usuário ao permitir sua modelagem baseada em cardinalidade. Ela possui recursos de geração de código na definição de seu meta-modelo do modelo de características. Entretanto, apesar de ser 1 Família de produtos IBM Rational:

11 uma ferramenta de notação simples, é pouco intuitiva. A Figura 8 mostra as funcionalidades disponibilizadas pela ferramenta como a seleção de característica obrigatória, opcional, grupos de características, instâncias, edição das propriedades das características, configuração de restrições, dentre outras opções. Como mostrado pela Figura 8, 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 [15].

12 Pure::variants Desenvolvido pela Pure Systems 2, uma empresa especializada no desenvolvimento de software baseado em reúso, o Pure::variants [27] é uma das ferramentas para o desenvolvimento de LPSs mais maduras que se pode encontrar atualmente. Pode ser utilizada como um plugin do Eclipse e integrada a algumas ferramentas comerciais, como o Enterprise Architecht 3 e IBM Rational Rhapsody 4. O pure::variants [27] é uma ferramenta utilizada no suporte à modelagem, implementação, implantação e desenvolvimento (atividades de análise). Ela funciona através de uma arquitetura cliente-servidor, tendo como cliente o plugin 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. Figura 9. Interface do pure::variants [27]. A interface do modelo de característica é visualizada pela Figura 9. Nesta interface, temos: (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 [17]. A ferramenta permite visualizar a mesma interface de edição na opção de modo tabela

13 Essa opção apresenta maiores informações da característica manipulada, tais como seu ID, nome único, nome visível e seu tipo. A tela apresentada pela Figura 10 é utilizada para configuração de produtos da LPS através da seleção de características. A ferramenta tem como pontos positivos uma variabilidade de editores e wizards, tornando-a uma ferramenta mais versátil e de maneira geral mais organizada e completa. Além disso, ela oferece uma linguagem proprietária alternativa e muito intuitiva, voltada para usuários comuns. Figura 10. Tela de configuração de produtos no pure::variants [27] Funcionalidades da Ferramenta SPLOT Esta seção detalha as principais funcionalidades da ferramenta SPLOT. O editor de modelo de característica é apresentado na Seção A Seção discute a funcionalidade para configuração do produto enquanto a análise automática de modelo de característica é apresentada na Seção Finalmente, a Seção mostra o funcionamento do repositório de modelos de característica e a Seção apresenta brevemente o workflow de configuração de característica Editor do Modelo de Característica Durante a edição de um modelo de característica na ferramenta SPLOT, duas opções estão disponíveis: (i) criar um novo modelo e (ii) editar um modelo existente. A Figura 11 mostra estas duas opções na interface da ferramenta SPLOT. Ao escolher a opção: Criar um novo modelo, será disposta uma tela da Figura 12 para edição de um novo modelo de característica. Além do editor de modelo, esta 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.

14 Figura 11. Opções de edição do modelo de características. A criação de um modelo de característica é disposta 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. A adição de informações para o modelo criado é necessário para salvar o modelo no repositório SPLOT. É através destas informações que será possível identificar o modelo criado e posteriormente alterar o modelo. A visualização estatística do modelo contabiliza os tipos de características (por exemplo: quantidade total de características, características mandatórias, opcionais, alternativas, entre outras). A análise de consistência permite identificar características mortas caso existam, bem como a validade do modelo criado. As demais opções são: (i) configurar modelo de característica, (ii) exportar modelo (formato XML) e (iii) salvar modelo no repositório. Após a criação de um modelo de característica como o apresentado pela Figura 13, podemos realizar alterações no modelo. Para acessar o menu de restrições clique com o botão direito do mouse em qualquer lugar da restrição. As alterações são realizadas, clicando com o botão direito do mouse sob o nome da característica e escolhendo uma das opções disponíveis (por exemplo, criar ou excluir características). Quando uma característica é renomeada ou excluída, todas as restrições referentes a essa característica são automaticamente atualizadas ou excluídas. É possível também, visualizar as estatísticas e consistência (clicar em Run Analysis ) do modelo de característica criado como mostrado na Figura 14. Para realizar os próximos passos é necessário que o modelo seja salvo no repositório. Para isto o modelo deve (i) ser consistente, (ii) ter no mínimo 10 características, (iii) não ter características mortas e (iv) ter pelo menos os campos obrigatórios da tabela de informações devidamente preenchidos.

15 Figura 12. Editor do modelo de característica. Figura 13 Alterar modelo de característica.

16 Figura 14 Análise estatística e de consistência do modelo de característica Configuração do Produto Para configuração de produtos é necessário clicar sobre o ícone de configuração disponível no editor de modelo de característica (ver Figura 12). Um redirecionamento é realizado para a tela que contem o repositório SPLOT, basta selecionar o modelo de característica criado e estará apto a configurar um produto. A Figura 15 mostra a tela para configuração de um produto. Nesta tela, temos duas opções disponíveis para cada característica do modelo: (i) selecionar característica - indicado pelo símbolo e (ii) remover característica. No momento da configuração, as técnicas de auto-completar serão automaticamente realizadas. Por exemplo, ao selecionar uma das características alternativas Screen 1, Screen 2 ou Screen 3, automaticamente as demais serão removidas do produto. Ao lado do modelo, uma tabela é disposta com os passos realizados pelo usuário durante a configuração do produto. Além da configuração interativa, SPLOT suporta a pesquisa sob um catalogo de produtos baseada em características. Ou seja, é feita uma busca por produtos em catálogos de produtos reais com base em decisões da configuração de características. A Figura 16 mostra a busca por um produto laptop no catálogo de produtos. Nesta busca, ao marcar ou desmarcar características em um modelo de característica 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 possuem sempre 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.

17 Figura 15. Configuração do produto na ferramenta SPLOT. Figura 16. Pesquisa sob um catálogo de produtos.

18 Análise Automática A análise automática do modelo descreve algumas estatísticas como, por exemplo, quantidade de características mandatórias, opcionais e alternativas. A Figura 17 mostra uma tela de análise automática no SPLOT. Além dos dados estatísticos, é possível obter informações de consistência e de métricas para os modelos de característica. Estas métricas têm se mostrado muito úteis para a comparação de modelos de característica e consequentes avaliações de suas complexidades. Figura 17. Análise automática do modelo de característica Repositório do Modelo de Característica Atualmente, o repositório do SPLOT contém aproximadamente 250 modelos de características com aproximadamente 7000 características no total. 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. A Figura 18 mostra uma lista de algum modelos de características armazenados no repositório do SPLOT. A métrica CTCR tem se mostrado útil na análise da complexidade do modelo de característica para instancias SAT. CTCR é definido como a razão entre o número de características distintas nas restrições em relação ao número de características do modelo de característica. Por exemplo, digamos que um modelo tem 10 características, 2 delas são parte de uma restrição única ligada ao modelo (por exemplo, característica_1 implica característica_2 ). Nós dizemos então, que o CTCR para este modelo é de 0,2 ou (20%).

19 Figura 18. Repositório de modelos de característica. 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ística é imposta pelas seguintes regras: (i) consistência - todos os modelos são garantidos para ser consistente (contém pelo menos uma configuração válida), (ii) correção - nenhum dos modelos contém características mortas e (iii) transparência - todos os modelos identificam os seus autores (ou literatura relacionada) e fornecem algumas informações de contato Workflow de Configuração de Característica Em um workflow é possível definir um fluxo de configuração de um produto. Este fluxo é realizado por diversas pessoas envolvidas no projeto de forma sistemática e controlado através de um workflow. Pelo uso desta funcionalidade, cada pessoa pode trabalhar na configuração da parte do modelo sobre a qual tem responsabilidade Conclusão Este documento fez uma introdução aos conceitos de LPS com foco em ferramentas para gerência de variabilidade em LPS. Os benefícios esperado e as potenciais armadilhas pela sua utilização de LPS foram discutidos. O documento apresentou cinco ferramentas para apoio ao desenvolvimento de LPS: SPLOT, FeatureIDE, XFeature, fmp e 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.

20 Agradecimentos Este trabalho recebeu apoio financeiro da FAPEMIG, processos APQ e APQ , e do CNPq processo / Referências [1] AHEAD Tool Suite. Available: < users/schwartz/ats.html>. Accessed: 20/06/2012. [2] Apel, S.; Kästner, C.; Lengauer, C. FeatureHouse: Language-Independent, Automatic Software Composition. In: Int'l Conf. on Software Engineering (ICSE). pp [3] 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 [4] 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 [5] 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 [6] 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 (2003). [7] Brito, R.; Colanzi, T. (2008) 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. [8] Clements, P.; Brownsword, L.: A Case Study in Successful Product Line Development. Technical Report CMU/SEI-96-TR-0160, Software Engineering Institute (1996). [9] Clements, P. e Northrop, L. (2002) Software Product Lines: Practices and Patterns. Reading, Addison-Wesley Professional. [10] A. Colyer, A. Clement, G. Harley, M. Webster, Eclipse AspectJ: Aspect-Oriented Programming with AspectJ and the Eclipse AspectJ Development Tools, 1st Edition., Addison-Wesley Professional, [11] Czarnecki, K.; Kim, C. H. P. Cardinality-Based Feature Modeling and Constraints: A Progress Report. In: International Workshop on Software Factories at OOPSLA. pp [12] Batory, D.; Sarvela, J. N.; and Rauschmayer, A. (2004) Scaling Step-Wise Refinement. IEEE Transactions on Software Engineering, Vol. 30, N. 6. [13] Dursckil, R.; Spinolal, M.; Burnett, R.; Reinehr, S. (2004) Linhas de Produto de Software: riscos e vantagens de sua implantação. VI Simpósio Internacional de Melhoria de Processos de Software.

21 [14] Figueiredo, et al. Evolving Software Product Lines with Aspects: An Empirical Study on Design Stability. In: Int'l Conf. on Software Engineering (ICSE). pp [15] Generative Software Development Lab, Disponível em: Acesso em: 30/09/2012. [16] I. Jacobson, M. Griss, P. Johnson (1997) Software Reuse: Architecture, Process and Organization for Business success, Addison-Wesley, [17] 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 [18] C. Kastner, S. Apel, and M. Kuhlemann. Granularity in software product lines. In Proc. Int l Conf. on Software Engineering, [19] Kiczales, G.; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, J.; and Irwin, J. (1997) Aspect-Oriented Programming, Proceedings of the European Conference on Object-Oriented Programming (ECOOP), pp [20] B. D. McKay, G. F. Royle, I. M. Wanless, F. E. Oggier, N. J. A. Sloane, and H. Wilf (2004) "Acyclic Digraphs and Eigenvalues of -Matrices." J. Integer Sequences 7, Article , 1-5. [21] M. Mendonça, Efficient reasoning techniques for large scale feature models, Ph.D. Thesis, University of Waterloo, Canada, 2009 [22] Marcílio Mendonça, Moises Branco, Donald Cowan: 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, October 2009, Orlando, Florida, USA. [23] Munge Development Team, Munge: A Purposely-Simple Java Preprocessor, Website, available online at ; visited on January 11th, [24] A. Pasetti (P&P Software GmbH / ETH-Zurich) and O.Rohlik (ETH-Zurich). Technical Note on a CONCEPT FOR THE XFEATURE TOOL, Issue: 1.3.Reference: PP-TN-XFT June p. [25] J. Pleumann, O. Yadan, E. Wetterberg, Antenna: An Ant-to-End Solution For Wireless Java, [26] Pohl, K.; Bockle, G.; Linden, F.J.V.D. (2005) Software Product Line Engineering: Foundations, Principles and Techniques. Springer. [27] pure::variants Eclipse Plug-in User's Guide. Version 2.0 for pure::variants p. Published [28] I. Schaefer, L. Bettini, V. Bono, F. Damiani, N. Tanzarella, Delta-oriented programming of software product lines, in: Proc. Int l Software Product Line. Conference, SPLC, Springer, Berlin, Heidelberg, New York, London, 2010, pp

22 [29] Sharp, D. C. Reducing Avionics Software Cost Through Component Based Product Line Development. Software Technology Conference [30] P. Sochos, I. Philippow, M. Riebisch, (2004) "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/2004. [31] Software Engineering Institute. Acesso em: 12/05/2012. [32] Sommerville, I. Engenharia de Softwawe, 9a. Edição. Pearson, pág [33] T. Thum, et al., FeatureIDE: An extensible framework for feature-oriented software development, Science of Computer Programming (2012), doi: /j.scico [34] J. Van Gurp, J. Bosch, M. Svahnberg (2001): On the notion of variability in software product lines. Proc. Working IEEE/IFIP Conf. Software Architecture (WICSA 01). [35] XFeature. Acesso em: 20/07/2012.