ESCOLA POLITCNICA DE PERNAMBUCO

COMPARAO ENTRE FERRAMENTAS PARA LINHA DE PRODUTOS DE SOFTWARE

Trabalho de Concluso de Curso Engenharia da Computao

Rogrio Aguiar de Lima Jnior Orientador: Prof. Srgio Castelo Branco Soares

Recife, junho de 2008

ESCOLA POLITCNICA DE PERNAMBUCO

COMPARAO ENTRE FERRAMENTAS PARA LINHA DE PRODUTOS DE SOFTWARE

Trabalho de Concluso de Curso Engenharia da Computao

Este Projeto apresentado como requisito parcial para obteno do diploma de Bacharel em Engenharia da Computao pela Escola Politcnica de Pernambuco Universidade de Pernambuco.

Rogrio Aguiar de Lima Jnior Orientador: Prof. Srgio Castelo Branco Soares

Recife, junho de 2008

Rogrio Aguiar de Lima Jnior

COMPARAO ENTRE FERRAMENTAS PARA LINHA DE PRODUTOS DE SOFTWARE

ESCOLA POLITCNICA DE PERNAMBUCO

Resumo
A evoluo dos sistemas computacionais est possibilitando cada vez mais o acesso e manipulao de informaes em qualquer lugar. Essa ubiqidade de sistemas de informao baseados em software est tornando necessrio o desenvolvimento cada vez mais rpido de sistemas de software. Linha de Produtos de Software uma abordagem de desenvolvimento de famlias de produtos de software, que atendem um determinado segmento de mercado, baseada na composio de artefatos e na modelagem do domnio, bastante promissora e que tem apresentado uma grande aceitao no ambiente corporativo. Esse trabalho se prope a fazer uma anlise comparativa das principais solues de software gratuitas e comerciais que visam fornecer suporte s diversas etapas do desenvolvimento de uma linha de produtos.

ESCOLA POLITCNICA DE PERNAMBUCO

ii

Abstract
The evolution of computational systems is enabling more access to and manipulation of information anywhere. This ubiquity of software based information systems is making a necessity the faster development of software systems. Software Product Line is a very promising approach for developing families of software products, which pertain to a specific market segment, based on artifacts composition and domain modeling, which has been presenting a great acceptance in the corporate environment. This work proposes to make a comparative analysis of the main free and commercial software solutions which aim to provide support for the diverse steps of developing a software product line.

ESCOLA POLITCNICA DE PERNAMBUCO

iii

Sumrio
ndice de Figuras ndice de Tabelas Tabela de Smbolos e Siglas 1 Introduo
1.1 1.2 1.3 1.4 Objetivos Metodologia Escopo Organizao do trabalho

v vi vii 9
11 11 12 12

Fundamentao Terica
2.1 2.2 2.3 Linha de Produtos de Software Feature Model Configuration Knowledge

13
13 16 17

Anlise das ferramentas

3.1 fmp 3.1.1 Background 3.1.2 Custo 3.1.3 Implementao 3.1.4 Tcnica de modelagem e notao utilizada 3.1.5 Facilidade de uso 3.1.6 Estudo de caso 3.2 XFeature 3.2.1 Background 3.2.2 Custo 3.2.3 Implementao 3.2.4 Tcnica de modelagem e notao utilizada 3.2.5 Facilidade de uso 3.2.6 Estudo de caso 3.3 pure::variants 3.3.1 Background 3.3.2 Custo 3.3.3 Implementao 3.3.4 Tcnica de modelagem e notao utilizada 3.3.5 Facilidade de uso 3.3.6 Estudo de caso 3.4 Gears 3.4.1 Background 3.4.2 Custo 3.4.3 Tcnica de modelagem e notao utilizada

18
18 18 19 19 19 21 22 23 24 24 24 24 26 27 28 28 29 29 29 33 34 36 36 36 36

ESCOLA POLITCNICA DE PERNAMBUCO

iv

4 5

Comparao das Ferramentas

4.1 Ferramentas de Linhas de Produtos de Software

38
38

Concluso

41

ESCOLA POLITCNICA DE PERNAMBUCO

ndice de Figuras
Figura 1. Figura 2. Figura 3. Figura 4. Figura 5. Figura 6. Figura 7. Figura 8. Figura 9. Figura 10. Figura 11. Figura 12. Interface do fmp .......................................................................................................... 20 EShop no fmp ............................................................................................................. 23 Interface do XFeature................................................................................................. 26 Feature model do EShop no XFeature ....................................................................... 27 Instncia do EShop no XFeature ................................................................................ 28 Interface de Edio do Feature Model em modo rvore do pure::variants............... 30 Interface de Edio do Feature Model em modo tabela do pure::variants ............... 31 Interface de Edio do Family Model do pure::variants ........................................... 32 Interface de Edio de um Variant Model do pure::variants .................................... 33 Feature model do EShop no pure::variants ............................................................ 35 Instncia do EShop no pure::variants..................................................................... 35 Interface da Gears ................................................................................................... 37

ESCOLA POLITCNICA DE PERNAMBUCO

vi

ndice de Tabelas
Tabela 1. Tabela 2. Principais caractersticas das ferramentas .................................................................. 39 Recursos das ferramentas ........................................................................................... 40

ESCOLA POLITCNICA DE PERNAMBUCO

vii

Tabela de Smbolos e Siglas

(Dispostos por ordem de apario no texto) OO Orientao a Objetos RUP Rational Unified Process XP eXtreme Programming SPL Software Product Line AOP Aspect Oriented Programming DSL Domain Specific Language FODA Feature Oriented Domain Analysis IDE Integrated Development Environment EMF Eclipse Modeling Framework XML eXtensible Markup Language XSLT eXtensible Stylesheet Language Transformations XSL eXtensible Stylesheet Language GEF Graphical Editing Framework

ESCOLA POLITCNICA DE PERNAMBUCO

viii

Agradecimentos
Gostaria de agradecer, em primeiro lugar, a Deus por ter me dado sade e paz para realizar esse trabalho de concluso de curso e, em segundo lugar, ao meu Professor Orientador Srgio Soares pela dedicao e empenho dispensados no s a este trabalho, mas tambm a minha pessoa, como figura fundamental nesta orientao, minha famlia e minha noiva Karlise, por tantas ausncias justificadas, por tanto stress, pela pacincia, pelo incentivo nas horas mais difceis e pela crena na minha capacidade. Fica aqui o meu muito obrigado a todos que de alguma forma contriburam para que esse dia to esperado chegasse, a concluso do meu curso de graduao.

ESCOLA POLITCNICA DE PERNAMBUCO

Captulo 1 Introduo
A evoluo dos sistemas computacionais tem possibilitado cada vez mais o acesso e a manipulao de informaes em qualquer lugar. Essa ubiqidade de sistemas de informao baseados em software nos vrios aspectos da vida comum est tornando necessrio o desenvolvimento cada vez mais rpido de sistemas de software. Entretanto, com o aumento da demanda, houve tambm o aumento de fatores de qualidade exigidos pelos usurios finais dos sistemas, tais como disponibilidade, tolerncia a erros, usabilidade etc. Estes requisitos no-funcionais esto sendo cada vez mais cobrados dos desenvolvedores dos softwares. Visando atender as demandas das aplicaes atuais, os desenvolvedores se concentram no uso de paradigmas de programao tais como Orientao a Objeto (OO), que tem sido visto como uma soluo razovel para atingir reuso de software. Conseguindo atingir o objetivo de reuso de software, a diminuio do esforo utilizado no desenvolvimento e a utilizao de software previamente testado, os desenvolvedores tm mais tempo para atingir os requisitos no funcionais. Do lado dos processos de desenvolvimento de software, tm-se como exemplo o Rational Unified Process (RUP) e o eXtreme Programming (XP). Porm, estas metodologias, mesmo aliadas OO, no conseguem atingir um nvel de reuso adequado para o desenvolvimento de produtos de software que so constitudos em famlias. Com o objetivo de tratar da questo de desenvolvimento de famlias de software, surgiu o conceito de Linha de Produtos de Software (do ingls Software Product Lines SPL)[1]. As empresas esto descobrindo que essa prtica de construir conjuntos de sistemas relacionados a partir de artefatos comuns pode trazer melhorias quantitativas considerveis em

ESCOLA POLITCNICA DE PERNAMBUCO

10

produtividade, time to market (o tempo que leva desde a concepo de um produto at ele atingir o mercado), qualidade de produto e satisfao do consumidor. Uma Linha de Produtos de Software um conjunto de sistemas de software que compartilham de um conjunto de features (caractersticas) comum e gerenciado, que satisfazem as necessidades de um segmento de mercado particular ou misso e que so desenvolvidos a partir de um conjunto comum de artefatos de uma maneira pr-determinada [1]. As principais motivaes para o uso de Linhas de Produtos de Software so: Ganhos em produtividade em larga escala; Diminuio do time to market Manter a presena de mercado Manter um crescimento sem precedentes Melhorar a qualidade do produto Aumentar a satisfao do cliente Atingir objetivos de reuso Permitir customizao em massa Em face de todos os benefcios que a utilizao do conceito de Linha de Produtos de Software pode trazer, necessrio que se leve em considerao fatores que podem acarretar num alto custo de entrada para a implementao deste conceito em uma empresa. As empresas desejam diminuir seu custo e aumentar seu lucro, para isso um bom suporte ferramental se torna necessrio. Para apoiar a empresa na implantao de Linha de Produtos de Software existem vrias ferramentas que auxiliam desde a modelagem do domnio at a implementao real dos produtos. O suporte ferramental para Linha de Produtos de Software amplo, e este trabalho se prope a analisar fatores de custo e qualidade das ferramentas pure::variants[3], fmp[2], XFeature[4] e Gears[5].

ESCOLA POLITCNICA DE PERNAMBUCO

11

1.1 Objetivos
Neste trabalho ser feito um comparativo entre as ferramentas para Linha de Produtos de Software mais utilizadas do mercado com o objetivo de tornar mais fcil o processo de escolha, por parte de uma empresa, de qual ferramenta utilizar para suportar sua linha de produtos. Os objetivos e metas deste trabalho so: Identificao dos recursos existentes em cada ferramenta de SPL; Levantamento dos pontos fracos e fortes das ferramentas analisadas; Identificao dos pontos de possveis melhorias das ferramentas; Identificao dos cenrios onde cada ferramenta melhor se aplica.

1.2 Metodologia
Uma vez que este trabalho se prope a fazer uma avaliao de um conjunto de ferramentas, ser analisado um estudo de caso baseado na literatura, o EShop[2]. O EShop consiste numa famlia de produtos de lojas eletrnicas, que faz venda de produtos on-line. Essas lojas possuem as seguintes caractersticas: Forma de pagamento: pode ser carto de crdito, carto de dbito e ordem de compra. Deteco de fraudes. Envio: pode ser algum mtodo customizado (padro, gratuito), utilizar algum gateway de envio (UPS, FedEx, CanadaPost, USPC). Poltica de senha: o Expirao: nmero de dias ou nunca expira. o Caracteres necessrios: letras maisculas, nmeros, caracteres especiais, letras minsculas. Essa famlia de produtos permite uma customizao das caractersticas das lojas, apresentadas acima. Apesar de no representar uma modelagem completa de uma loja eletrnica essa famlia de produtos possui caractersticas suficientes para ilustrar os recursos das ferramentas de feature model que sero analisadas. A famlia permite ilustrar diversas situaes de cardinalidades (no mnimo um e no mximo infinitos tipos de caracteres necessrios para a senha, por exemplo), opcionalidade de

ESCOLA POLITCNICA DE PERNAMBUCO

12

features (deteco de fraudes, por exemplo), obrigatoriedade de features (forma de pagamento, por exemplo), features com atributos (nmero de dias de expirao, por exemplo). Visando atingir os objetivos deste trabalho, foram executados os seguintes passos: 1. Instalao: baixar e instalar as verses das ferramentas a serem analisadas. As ferramentas a serem avaliadas so: pure::variants, fmp, gears e XFeature. 2. Estudo: nesta tarefa as documentaes das ferramentas instaladas sero estudadas, visando facilitar a implementao do estudo de caso em cada ferramenta; 3. Anlise crtica: Nesta tarefa, os recursos que foram utilizados em cada ferramenta sero analisados de acordo com os seguintes critrios: background (comercial ou acadmico, se ainda est em desenvolvimento), tcnica de modelagem e notao utilizada (tipos de visualizao e manipulao de dados disponveis), implementao (plugin ou ferramenta stand-alone), facilidade de uso e custo. 4. Estudo de caso: o estudo de caso selecionado ser implementado em todas as ferramentas que sero analisadas. Nessa tarefa sero identificadas as vantagens que uma ferramenta pode ter sobre as outras. 5. Matriz de recursos: sero montadas tabelas comparativas que permitam que as ferramentas sejam analisadas pelos seus recursos de uma maneira visualmente simples.

1.3 Escopo
Este trabalho se limitar a avaliar as ferramentas pure::variants, fmp, Gears e XFeature. Os atributos destas ferramentas que sero analisados sero apenas os especificados na metodologia na Seo 1.2.

1.4 Organizao do trabalho

O Captulo 2 introduz os principais conceitos relacionados a Linha de Produtos de Software. J o Captulo 3 apresenta a anlise de cada ferramenta. O Captulo 4 apresenta as tabelas comparativas. Por fim, o Captulo 5 apresenta a concluso do trabalho.

ESCOLA POLITCNICA DE PERNAMBUCO

13

Captulo 2 Fundamentao Terica

Neste captulo sero apresentados os principais conceitos utilizados neste trabalho. Os mesmos sero apresentados de forma clara e concisa com o intuito de que diferentes pessoas de diferentes reas de estudo possam compreender.

2.1 Linha de Produtos de Software

Linha de Produtos de Software (do ingls Software Product Lines, SPL) [1] um framework de processos que focam no desenvolvimento de uma famlia de produtos com o objetivo de atingir um mercado especfico e baseado numa base comum de artefatos. Famlia de produtos de software um conjunto de produtos de software com caractersticas suficientemente similares para permitir a definio de uma infra-estrutura comum de estruturao dos itens que compem os produtos (membros) e a parametrizao das diferenas entre produtos. Um exemplo de uma famlia de produtos a famlia de produtos para controle de satlites (Ccontrol Channel Toolkit, Clements and Northrop, 2002): Arquitetura de software comum Componentes: escalonadores, rbita, Manobrista, Planejamento de acesso aos dados e Avaliao. Exemplo de variao: pontos de variao permitem que ferramentas especficas dos produtos gerem dados de rbita ou que fontes externas forneam dados de rbita. Em uma linha de produtos, h uma arquitetura genrica que comum a todos os produtos da linha; essa arquitetura adaptada permitindo a criao de um produto particular. Por exemplo, o sistema operacional Windows Vista pode ser considerado uma linha de produtos, uma vez que

ESCOLA POLITCNICA DE PERNAMBUCO

14

ele possui vrias verses com a mesma base arquitetural, que alterada, adicionando-se ou removendo componentes, para permitir a gerao das diversas verses. Cada produto da linha definido a partir de uma seleo de features, que so atributos que caracterizam as funcionalidades do produto. Essas selees dos diferentes pontos de variabilidade (diferenas tangveis entre produtos que podem ser reveladas e distribudas entre os artefatos da Linha de Produtos) de um produto so o conjunto de pontos onde ele difere dos outros produtos da linha. Existem vrios nveis de variabilidade: de cdigo, de recursos, de arquitetura etc. Os benefcios de uma Linha de Produtos de Software so derivados do reuso de artefatos de uma maneira estratgica e pr-definida. Quando o repositrio de artefatos da linha de produtos estiver estabelecido, os ganhos sero identificados nas seguintes reas: Requisitos: existem requisitos comuns da linha de produtos. Os requisitos dos produtos individuais so apenas deltas (diferenas) desta base estabelecida de requisitos, o que poupa uma anlise de requisitos mais extensiva. Arquitetura: A arquitetura de software de um programa ou sistema computacional a estrutura do sistema, que composta de componentes de software, as propriedades visveis externamente dos mesmos e a relao entre eles. A arquitetura uma parte fundamental para atingir os objetivos dos produtos, uma vez que a arquitetura tenha sido desenhada corretamente numa linha de produtos, ela ser usada para cada produto atravs de instanciao, poupando tempo e risco. O processo de instanciao consiste na adio ou remoo de partes da arquitetura que iro entrar ou no em um determinado produto da linha, permitindo que a arquitetura seja customizada para atender exatamente as necessidades do produto. Enquanto a academia tem focado em deixar a arquitetura definida explicitamente, com componentes e conectores, usando linguagens especficas de definio de arquitetura para descrever e gerar aplicaes, a indstria tem normalmente apenas uma compreenso conceitual da arquitetura, com pouca descrio explcita e, menos ainda, formal e, tambm, com solues ad-hoc para conexo entre elementos da arquitetura. A instanciao da arquitetura de um produto em uma linha de produtos de software feita, idealmente, como um processo automtico, que tem como entrada a seleo de caractersticas que estaro no produto, os componentes disponveis que implementam a arquitetura e o mapeamento das relaes entre estes. Componentes: Existem trs nveis de reuso de componentes: o Reuso de componentes em verses subseqentes dos produtos: o tipo mais comum que aplicado com facilidade pelas empresas. A idia que o cdigo que foi

ESCOLA POLITCNICA DE PERNAMBUCO

15

desenvolvido em uma verso do produto no seja descartado, e sim reaproveitado para verses subseqentes do produto, exceto em casos que requeiram uma completa reescrita da aplicao. o Reuso de componentes em verses do produto e em vrios produtos: nesse ponto que foca o uso de linha de produtos de software. Consiste no desenvolvimento de componentes que funcionam no apenas em um produto, mas nos vrios produtos da linha, e no apenas em uma verso dos produtos da linha, mas tambm nas verses subseqentes. o Reuso de componentes em verses do produto, em vrios produtos e em diferentes organizaes: muito longe de estar maduro, pouco aplicado na indstria. Engloba o reuso explicado no ponto anterior, e vai alm, propondo que os componentes sejam desenvolvidos de forma que possam ser utilizados por outras empresas, que podem, ou no, estar desenvolvendo produtos para o mesmo domnio que a empresa que desenvolve os componentes. Em alguns casos, at todos os componentes disponveis na linha de produtos podem ser usados em um determinado produto. Esses casos podem ser considerados utpicos, visto que na maior parte das vezes os componentes precisaram de alguma (mesmo que pouca) customizao para atender as necessidades de um produto. Esses componentes podem ser alterados atravs de herana, parmetros ou, at mesmo, programao orientada a aspectos (do ingls Aspect Oriented Programming AOP[7]). Modelagem e anlise: modelos de performance e suas respectivas anlises so artefatos da linha de produtos. Problemas comuns de distribuio, por exemplo, tais como: sincronizao, ausncia de deadlocks(situao em que ocorre um impasse e dois ou mais processos ficam impedidos de continuar suas execues) etc, so dados como eliminados em novos produtos, uma vez que os mesmos foram resolvidos nos artefatos comuns da linha de produtos. Teste: similarmente a requisitos, os artefatos de teste (plano de testes, processos de testes, casos de testes, dados de testes etc) j esto na linha de produtos, e s precisam ser adaptados baseados nas variaes do produto relacionado. Planejamento: o plano de produo, que responsvel pelo planejamento geral de todos os produtos, j est desenvolvido. As estimativas para novos produtos so mais confiveis, uma vez que os projetos existentes fornecem uma excelente base para comparao.

ESCOLA POLITCNICA DE PERNAMBUCO

16

Pessoal: Menos pessoas so necessrias para construir os produtos.

2.2 Feature Model

Feature uma propriedade do sistema que relevante para algum stakeholder (pessoa influenciada pelo desenvolvimento de um produto de software) e usada para capturar o que h de comum ou discriminar entre produtos de uma mesma linha. Um feature model consiste de um ou mais diagramas de features, que organizam os features em hierarquias. Modelagem de features permite que se modelem as propriedades comuns e variveis dos membros da linha de produtos, durante todos os estgios da engenharia de linhas de produtos. No caso do EShop, por exemplo, a modelagem de features identificaria que as lojas possuem features em comum, como o envio de produtos, e features opcionais, como deteco de fraude. So essas features opcionais, as alternativas e as com cardinalidade que permitem a diferenciao entre os diversos produtos da linha, uma vez que as features obrigatrias sempre esto presentes em todos os produtos da linha. A criao de um novo produto resume-se ento, no nvel de feature model seleo de quais features no-obrigatrias estaro disponveis no produto. Num estgio inicial, a modelagem de features permite a definio do escopo da linha de produtos, definindo quais features sero suportados pela linha, e quais no sero. Alm disso, feature models permitem a derivao de linguagens especficas de domnio (do ingls Domain Specific Languages DSL), que so usadas para especificar membros da linha de produtos usando Programao Generativa[8][9]. Modelagem de features foi proposta como parte do mtodo Feature Oriented Domain Analysis (FODA) [10], e desde ento tem sido aplicada em diversos domnios. Modelagem de features baseada em cardinalidade[11] estende a modelagem de features original do FODA com cardinalidade de features e de grupos, atributos de features, referncias no diagrama de features, e anotao definidas pelo usurio. Cardinalidade de features e de grupos permite que se definam, respectivamente, quantas cpias da mesma feature podem existir no modelo, e quantos filhos do grupo podem ser selecionados. As cardinalidades normalmente se encontram especificadas como: 0 a 1, 1 ou mais, 2 a 4, etc. Atributos de features permitem que as features possuam um valor em cada instncia do feature model, valor este que pode ser uma string, um inteiro, um booleano, etc. Por fim, anotaes permitem que o usurio adicione propriedades s features, alterando diretamente o meta-modelo, de modo que todas as features possuam a propriedade customizada.

ESCOLA POLITCNICA DE PERNAMBUCO

17

2.3 Configuration Knowledge

O feature model, por si s, apenas representa a modelagem do domnio, mas no representa o modo como os produtos deste domnio sero gerados a partir dos artefatos da linha de produtos. O mapeamento entre o feature model e os artefatos de implementao o que se chama de Configuration Knowledge[9]. Os artefatos de implementao podem estar modelados direto no modelo que representa o configuration knowledge ou em um modelo a parte, neste caso o configuration knowledge associar os artefatos de um modelo com as features do feature model. Quando no esto dentro do configuration knowledge, os artefatos de implementao encontram-se em um modelo que assume diferentes nomes, dependendo da ferramenta utilizada, tais como family model, component model, architecture model, etc. O mapeamento existente no configuration knowledge essencialmente um conjunto de regras que definem que artefatos de implementao (classes, arquivos de recursos, etc) entram em cada produto da linha. Tomando o EShop como exemplo, uma classe chamada FraudDetection que trata da deteco de fraudes estaria representada no configuration knowledge como uma regra que diz se a feature deteco de fraudes estiver selecionada em um produto, a classe entraria nesse produto tambm, essencialmente uma relao de implica (feature implica em artefato de implementao). Por trs do processo de gerao de produtos de uma linha de produtos de software se encontra uma engine de resoluo de expresses lgica, que checa se todas as restries presentes no feature model foram respeitadas em cada instncia, e, para cada seleo de features, verifica que artefatos de implementao estaro habilitados na instncia. Uma vez que todas as verificaes tenham sido realizadas, a sada do processo de gerao de produtos vai ter como resultado, para cada produto, uma lista dos artefatos de implementao habilitados no produto. Dependendo da ferramenta utilizada, o usurio pode especificar diretamente na ferramenta o que ser feito com essa lista, como gerar um projeto individual na IDE utilizada com uma cpia de cada artefato de implementao, ou invocar um sistema de empacotamento dos produtos que geraria os executveis finais, permitindo assim uma maior customizao do processo de gerao.

ESCOLA POLITCNICA DE PERNAMBUCO

18

Captulo 3 Anlise das ferramentas

Neste captulo ser apresentada a anlise de cada ferramenta. Os critrios analisados de cada ferramenta so: background, custo, implementao, tcnica de modelagem e notao utilizada e facilidade de uso. Ser analisado um estudo de caso em cada ferramenta, que permitir uma comparao das mesmas tendo uma linha base comum.

3.1 fmp
O fmp (Feature Model Plugin) um plugin para o Eclipse desenvolvido pelo Generative Software Development Lab, da University of Waterloo [17]. Ele utiliza como base o Eclipse Modeling Framework, o que, de acordo com os desenvolvedores, reduziu significativamente o esforo de desenvolvimento. O fmp apenas apresenta suporte modelagem do domnio, atravs de feature models. Ele no possui nenhuma funcionalidade de configuration knowledge, nem nada que permita, dentro do prprio fmp, o mapeamento necessrio entre features e artefatos da linha de produtos para permitir a gerao dos produtos.

3.1.1

Background

O fmp apresenta um background puramente acadmico, no sendo conhecido se ele utilizado comercialmente. O site do projeto indica que o mesmo est completo na verso 0.6.6 e que no est sendo mais mantido, em favor de um projeto chamado Ecore.fmp, que permitir a edio de modelos EMF Ecore [12], que so modelos no especificamente de features, e sua visualizao e

ESCOLA POLITCNICA DE PERNAMBUCO

19

desenvolvimento como feature models. O ECore.fmp est definido como em progresso, mas no h atualizaes no site desde 13 de Julho de 2007, e tambm no h nenhuma verso disponvel para download. Apesar de o fmp estar definido como completo, uma nova verso, 0.7.0, considerada em desenvolvimento, est disponvel no site. Essa nova verso muda o sistema de restries no feature model, substituindo o formato de expresses antigo, baseado em XPath 2.0[18], por uma linguagem de expresses mais simplificada.

3.1.2

Custo

Por ser uma ferramenta Open Source, o fmp completamente gratuito e, alm disso, o cdigo fonte do mesmo est disponvel para qualquer um que deseje contribuir com correes e novos features.

3.1.3

Implementao

O fmp foi implementado baseado na verso 3.2 do Eclipse (a verso mais recente a 3.3), utilizando o Eclipse Modeling Framework para definio do meta-modelo de feature model e utilizando os recursos de gerao de cdigo do EMF. Os modelos gerados pelo feature model so gravados no sistema como um arquivo XML (do ingls Extensible Markup Language), o que pode permitir que geradores, utilizando XSLT[13] (do ingls Extensible Stylesheet Language Transformation), por exemplo, possam processar o modelo. Por ser um plugin para o Eclipse e possuir uma API bem definida, possibilita que outras ferramentas se integrem com o mesmo; sabido que pelo menos uma ferramenta[14] se integra com o fmp.

3.1.4

Tcnica de modelagem e notao utilizada

O fmp implementa modelagem de features baseada em cardinalidades[11], ou seja, permite a definio de cardinalidades de feature e de grupo, atributos de feature, referncias e anotaes definidas pelo usurio. Cardinalidades de feature e grupo permitem que sejam especificados o nmero mnimo e mximo de filhos de uma feature que podem ser selecionados, 0 ou mais, 1 a 4, por exemplo. Atributos de feature permitem que cada feature possua um valor, que pode ser uma string, um booleano, um inteiro, etc, o que aumenta a expressividade do modelo. Anotaes definidas pelo

ESCOLA POLITCNICA DE PERNAMBUCO

20

usurio permitem que o usurio adicione novas propriedades as features, alm das bsicas (nome, cardinalidade, valor), permitindo assim uma maior customizao do modelo. Para suportar anotaes definidas pelo usurio, o fmp permite que o usurio altere o metamodelo do feature model, permitindo, por exemplo, que toda feature tenha um atributo chamado quantidade; ou qualquer coisa que o usurio deseje colocar. A Figura 1 demonstra a interface do fmp.

Figura 1. Interface do fmp

ESCOLA POLITCNICA DE PERNAMBUCO

21

O fmp s possui uma maneira de visualizar e editar o feature model, que em forma de rvore, como demonstrado na Figura 1, onde encontramos todos os recursos disponveis no fmp, tais como features obrigatrias, opcionais, em grupo, instncias, seleo de feature pelo usurio e automtica devido a uma restrio, a edio de restries, de propriedades da feature. Como foi mencionado anteriormente, o fmp permite a definio de restries sobre o feature model, de modo que o prprio fmp no permita que o usurio selecione a feature x quando houver uma restrio dizendo se a feature y estiver selecionada, no selecione a feature x. Todas as restries encontram-se na feature raiz do feature model. Na aba de propriedades o usurio pode editar os atributos presentes no meta-modelo (que podem ter sido adicionados pelo prprio usurio), tais como cardinalidade, descrio, nome. Para criao de instncias, o que chamado, na terminologia do fmp, de configurao de instncias, o usurio deve clicar com o boto direito na feature raiz do feature model e selecionar a opo new configuration of feature, o que gerar uma rvore no preenchida para que as features sejam selecionadas, respeitando as restries existentes no modelo.

3.1.5

Facilidade de uso

Por ser uma ferramenta integrada ao Eclipse, os desenvolvedores que j esto familiarizados com o desenvolvimento no Eclipse provavelmente no se sentiro desconfortveis ao utilizar o fmp. A linguagem utilizada para definies de restries, XPath, no apresenta uma boa legibilidade, mas a verso em desenvolvimento do fmp, disponvel no site da ferramenta, apresenta uma linguagem de definio de restries bastante simples. Como a definio de instncias do feature model encontra-se no mesmo modelo, junto com a definio do feature model, isso pode vir a ser um inconveniente com modelos grandes que possuam uma grande quantidade de instncias. O fmp permite que um modelo importe outro, permitindo que uma instncia fique definida em um arquivo, e o feature model em outro, porm, nos testes realizados com a ferramenta, essa funcionalidade apresentou problemas e no funcionou corretamente. A notao utilizada no editor de feature model simples, porm no intuitiva. Entretanto, aps a leitura da documentao da ferramenta e pouco tempo de uso, o usurio poder se acostumar facilmente com os cones e notaes utilizados.

ESCOLA POLITCNICA DE PERNAMBUCO

22

3.1.6

Estudo de caso

Uma vez que o estudo de caso originalmente do fmp, no houve problemas para a implementao do mesmo. Diversos recursos do fmp foram utilizados, tais como: grupo de features, cardinalidades, features opcionais, features com valor, referncias e configuraes. A criao do modelo do estudo de caso foi feita para que o modelo criado fosse exatamente o igual ao apresentado no artigo que descreve o estudo de caso. As features foram criadas na ordem apresentada no modelo, foram criados inicialmente um sub-modelo para cada uma das features: pagamento, envio e poltica de senha, uma vez que estes estivesse completos, o modelo da loja foi criado utilizando referncias para essas features, seguido da criao de uma instncia do modelo. O estudo de caso mostrou que fcil criar um feature model e instncias do mesmo utilizando o fmp. Como no h configuration knowledge, no houve nenhuma associao de artefatos reais com as features do domnio, nem a gerao de produtos individuais. A figura 2 apresenta o EShop desenvolvido no fmp. Pode-se identificar que todas as features do EShop foram modeladas claramente no fmp, podemos ver a feature opcional de deteo de fraude (opcionalidade representada por uma bola branca ao lado do nome), podemos ver a feature com atributo inteiro InDays que define o nmero de dias para a expirao da senha e grupos de features com cardinalidade, como tipos de pagamento, onde se pode escolher um ou mais tipos.

ESCOLA POLITCNICA DE PERNAMBUCO

23

Figura 2. EShop no fmp

3.2 XFeature
O XFeature um plugin para o Eclipse desenvolvido pela P&P Software, que uma empresa que se originou no Institute of Automatic Control of ETH (Swiss Federal Institute of Technology). O XFeature foi criado para demonstrar um conceito de uma ferramenta para automatizar o processo de modelagem e configurao de artefatos reusveis de software. A ferramenta se apresenta como inovadora pela possibilidade de customizao do meta-modelo da famlia de produtos[15].

ESCOLA POLITCNICA DE PERNAMBUCO

24

O XFeature apresenta suporte modelagem do domnio, atravs de feature models e no possui a funcionalidade de configuration knowledge, que permite o mapeamento necessrio entre features e artefatos da linha de produtos para permitir a gerao dos produtos.

3.2.1

Background

O XFeature apresenta um background puramente acadmico e corporativo. No conhecido se ele utilizado comercialmente, porm, o site da P&P lista como clientes passados e atuais da empresa as seguintes instituies: European Space Agency, Alenia-Spazio, Astrium GmbH, Alcatel Space of France, Roche Diagnostics AG, logo, possvel que alguns destes clientes esteja utilizando o XFeature. O site do projeto indica que o mesmo est atualmente na verso 2.1.2, que funciona na verso mais recente do Eclipse, a 3.3. O projeto encontra-se em constante desenvolvimento. Originalmente o XFeature foi desenvolvido visando o seu uso em aplicaes espaciais (sistemas de controle embutidos para naves espaciais, por exemplo), porm, no h nenhuma restrio na maneira que foi desenvolvido que no permita o seu uso em outros contextos.

3.2.2

Custo

Por ser uma ferramenta Open Source licenciado sob a GNU General Public Licence, o XFeature completamente gratuito, e, alm disso, o cdigo fonte do mesmo est disponvel para qualquer um que deseje contribuir com correes e novos features, que podem ser aceitas no projeto oficial a critrio da P&P.

3.2.3

Implementao

O XFeature foi implementado baseado na verso 3.3 do Eclipse, ao contrrio do fmp, ele no utilizou o EMF para a definio do meta-modelo de feature model. O seu editor baseado no GEF (Graphical Editing Framework) do Eclipse. O XFeature depende fortemente de XML e de transformaes XSL. Scripts Ant so utilizados para a verificao e gerao de arquivos de configurao da aplicao, tais como os que customizam o editor dos modelos.

3.2.4

Tcnica de modelagem e notao utilizada

Ao contrrio do fmp e do pure::variants, o XFeature extremamente flexvel, permitindo que a tcnica de modelagem de features seja escolhida pelo usurio, sendo fornecidas quatro

ESCOLA POLITCNICA DE PERNAMBUCO

25

configuraes diferentes: FD, FMP[11], ICSR[15] e SimplifiedICSR. Uma das configuraes justamente a utilizada pelo fmp. As configuraes FD e SimplifiedICSR so ambas baseadas na configurao ICSR. Essas configuraes definem quais so os elementos presentes no modelo de features que ser utilizado pelo usurio. ICSR bastante similar a FMP, tendo a mais a idia de macros de features, que permitem que o feature model seja dividido em vrias partes e composto atravs dessas macros, similarmente funcionalidade de macro presente em algumas linguagens de programao. FD e SimplifiedICSR removem algumas caractersticas de ICSR, SimplifiedICSR remove a idia de macros e FD que impe algumas restries sobre quais os possveis tipos de filhos para features macro. O processo de criao de modelos no XFeature consideravelmente mais complicado do que nas outras ferramentas. Primeiramente se define qual ser a configurao utilizada (FD, FMP, SimplifiedICSR ou ICSR). Em seguida, criado o que o XFeature chama de family model, que o meta-modelo do domnio. Aps a validao do family model sob a configurao utilizada, o usurio deve clicar em um boto que gera dois meta-modelos: o de aplicao e o de display. O meta-modelo de aplicao o que ser utilizado como configurao dos modelos que vo conter as instncias da linha de produto, e o meta-modelo de display define quais os elementos visuais que aparecero no editor. Apesar de ser mais complicado, o XFeature permite que o usurio tenha mais controle sobre como so criados os feature models, uma vez que o usurio no fica preso nica configurao presente nas outras aplicaes. Uma vez criados os modelos das instncias da linha de produtos, eles podem ser validados contra seu meta-modelo, que foi definido pelo usurio anteriormente. Quando os modelos estiverem validados, eles podem ser utilizados como entrada pra outras ferramentas que possuam a parte de configuration knowledge para gerar os produtos finais. A Figura 3 demonstra a interface do XFeature.

ESCOLA POLITCNICA DE PERNAMBUCO

26

Figura 3. Interface do XFeature O XFeature s possui uma maneira de visualizar e editar os seus modelos, que em forma de rvore, como demonstrado na Figura 3, onde encontramos feature raiz, no topo da rvore, features opcionais, pontilhadas, e features obrigatrias, em caixas amarelas, assim como o editor de propriedades de features. O XFeature tambm permite a definio de restries globais sobre o feature model. O usurio cria um modelo de restries, que passa pelo global constraints compiler, que vai gerar um conjunto de arquivos XSL que permitem a verificao das restries.

3.2.5

Facilidade de uso

Igualmente ao fmp, o XFeature integrado com o Eclipse. Entretanto, a facilidade de uso normalmente associada com o fato de ser uma ferramenta integrada com um ambiente de desenvolvimento conhecido praticamente inexistente com o XFeature. A quantidade de arquivos de validao, gerao, display, meta-modelos etc, enorme. A barreira de entrada para que um usurio aprenda para que serve cada arquivo de difcil transposio. consideravelmente repetitiva e trabalhosa a criao de instncias do feature model, uma vez que o usurio no apresentado a um modelo completo para seleo, ele deve criar a rvore inteira, n por n, podendo criar apenas os ns definidos no feature model.

ESCOLA POLITCNICA DE PERNAMBUCO

27

De todas as ferramentas analisadas, o XFeature foi a menos intuitiva e com a pior usabilidade.

3.2.6

Estudo de caso

O estudo de caso foi desenvolvido utilizando como meta-modelo para definio do feature model a configurao FMP disponvel no XFeature. Como a configurao FMP prov os recursos disponveis no fmp, no houve dificuldade para criar o feature model. As figuras 4 e 5 apresentam os modelos criados durante o estudo de caso no XFeature. A notao difere um pouco do fmp, mas podemos ver todas as features encontradas no estudo de caso do fmp nas figuras 4 e 5. A cardinalidade representada visualmente como um range entre os sinais de menor < e maior >, onde <1..1> significa que apenas uma feature deve ser selecionada, <0..1> significa que 0 ou 1 feature devem ser selecionadas e <1..*> significa que uma ou mais features devem ser selecionadas. A criao de instncias no XFeature consideravelmente mais trabalhosa do que no fmp, uma vez que elas tm que ser criadas n a n, dado que no somos apresentados a um feature model completo para seleo de apenas as features desejadas. Assim como o fmp, no h configuration knowledge e no houve nenhuma associao de artefatos reais com as features do domnio, nem a gerao de produtos individuais.

Figura 4. Feature model do EShop no XFeature

ESCOLA POLITCNICA DE PERNAMBUCO

28

Figura 5. Instncia do EShop no XFeature

3.3 pure::variants
O pure::variants um plugin para o Eclipse desenvolvido pela pure-systems GmbH, uma empresa que se originou no Institute Otto-von-Guericke-Universitt Magdeburg e no Fraunhofer Instituts Rechnerarchitektur und Softwaretechnik. A empresa tem como objetivo o desenvolvimento de softwares para sistemas embarcados, que se baseia no desenvolvimento de componentes de software e de ferramentas de desenvolvimento de software. O pure::variants foi desenvolvido para suportar o desenvolvimento e a implantao de linhas de produtos e famlias de software. O pure::variants prov suporte no desenvolvimento durante as atividades de anlise, modelagem, implementao e implantao. O pure::variants apresenta suporte modelagem do domnio, atravs de feature models e possui a funcionalidade de configuration knowledge, que permite o mapeamento necessrio entre features e artefatos da linha de produtos para permitir a gerao dos produtos.

3.3.1

Background

O pure::variants provavelmente teve um incio acadmico, dado que a pure-systems surgiu em institutos acadmicos, mas cresceu a ponto de se tornar uma ferramenta comercial extremamente rica. O projeto encontra-se em constante desenvolvimento e, similarmente ao XFeature, foi inicialmente criado visando o mercado de sistemas embarcados, mas tambm usado em outros ambientes, especialmente na indstria automotiva.

ESCOLA POLITCNICA DE PERNAMBUCO

29

3.3.2

Custo

O pure::variants uma ferramenta comercial, logo, requer licena para uso. Ela possui uma verso gratuita para testes, que no pode ser usada comercialmente e possui restries no tamanho dos modelos. sabido que o custo do pure::variants varia muito dependendo da quantidade de licenas adquiridas. Mas sabe-se que normalmente o preo de uma licena para uma mquina na verso developer custa em torno de 200 euros por ms. O custo tambm varia dependendo de qual verso da ferramenta ser utilizada, a Professional ou a Enterprise. A verso Enterprise possui controle de verses integrado (utilizando CVS, por exemplo), permite que o usurio desfaa modificaes no modelo mesmo aps ele ter sido fechado (no apenas quando ele est aberto, como ocorre na Professional), colaborao on-line e gerenciamento de modelos centralizado.

3.3.3

Implementao

O pure::variants funciona com a verso 3.3 do Eclipse, mas no se utiliza dos frameworks de modelagem e editores grficos utilizados pelo fmp e pelo XFeature. O pure::variants utiliza uma arquitetura cliente-servidor, onde o cliente o plugin do Eclipse que utilizado pelo usurio, enquanto o servidor, que faz o trabalho de modificao real dos modelos, um aplicativo C++ que fica rodando em background.

3.3.4

Tcnica de modelagem e notao utilizada

O pure::variants utiliza uma notao baseada em FODA, descrita em um artigo[16]. Ele possui 3(trs) tipos de modelos diferentes: o feature model onde so definidas as caractersticas comuns e variabilidades da linha de produtos, o family model a parte do configuration knowledge onde se encontram os componentes que compem os artefatos da linha de produtos, e o variant model que o modelo que define uma instncia da linha de produtos. A diviso dos 3 modelos clara e consideravelmente mais intuitiva do que os inmeros meta-modelos e modelos que o XFeature define, e a definio das instncias em arquivos separados facilita a organizao da linha. Alm disso, as mudanas no feature model so sincronizadas automaticamente com os variant models. Uma vez criados os variant models, eles podem ser validados para determinar se cumprem as restries do feature model, que foi definido pelo usurio anteriormente. Uma vez que estes modelos estejam validados, eles podem ser usados juntamente com o family model e o feature model para a gerao dos produtos da linha, utilizando os recursos de gerao do pure::variants.

ESCOLA POLITCNICA DE PERNAMBUCO

30

As Figuras de 6 a 9 demonstram a interface do pure::variants.

Figura 6. Interface de Edio do Feature Model em modo rvore do pure::variants Na Figura 6 encontramos features obrigatrias (com exclamao), features or (com um X), features alternativas (com ) e features opcionais (com interrogao).

ESCOLA POLITCNICA DE PERNAMBUCO

31

Figura 7. Interface de Edio do Feature Model em modo tabela do pure::variants A Figura 7 simplesmente oferece uma forma diferente de visualizao, em forma de tabela, onde se pode ver tambm o ID, o nome nico, o nome visvel e o tipo da feature.

ESCOLA POLITCNICA DE PERNAMBUCO

32

Figura 8. Interface de Edio do Family Model do pure::variants A Figura 8 apresenta o Family Model, onde encontramos componentes (as caixas marrons), restries (as expresses aps a placa com exclamao), classes (as bolas verdes com um C), aspectos (as bolas laranjas com um A), arquivos (o papel dobrado na borda).

ESCOLA POLITCNICA DE PERNAMBUCO

33

Figura 9. Interface de Edio de um Variant Model do pure::variants A Figura 9 mostra a interface de seleo de features em uma instncia do feature model no pure::variants, as features so selecionadas marcando-se a checkbox adjacente s mesmas. O produto resultante de uma instncia pode ser visualizado de forma similar ao family model utilizado como base. Todos os elementos que no entraram na instncia so omitidos do family model durante esta visualizao. Alm disso, o pure::variants prov um engenho de transformao baseado em XLST, que pode ser estendido pelo usurio, permitindo a customizao dos arquivos que sero gerados quando uma instncia for transformada.

3.3.5

Facilidade de uso

Similarmente ao fmp, o pure::variants integrado ao Eclipse, o que facilita o seu uso por desenvolvedores que j utilizam o ambiente de desenvolvimento. Entretanto, o pure::variants possui uma quantidade maior de editores e wizards que o fmp, alm de introduzir mais conceitos, o que pode dificultar o uso inicial da ferramenta. Como a definio de instncias do feature model encontra-se em arquivos separados, isso facilita a organizao da estrutura de arquivos do projeto. O uso de prolog para a definio de

ESCOLA POLITCNICA DE PERNAMBUCO

34

restries poderia ser considerado uma pssima escolha. Entretanto, pvscl, a linguagem alternativa prpria do pure::variants para definio de restries consideravelmente mais simples e intuitiva do que prolog. Usurios mais avanados tero todo o poder que prolog oferece, enquanto usurios comuns podero usar pvscl sem dificuldades.

3.3.6

Estudo de caso

A diviso entre os modelos no estudo de caso desenvolvido no pure::variants foi bastante clara. O feature model especificou o domnio, porm sem a possibilidade de definir cardinalidades como utilizado no fmp e no XFeature, entretanto, o uso de features or e alternative puderam substituir os casos existentes no estudo de caso. O variant model era atualizado automaticamente refletindo as mudanas do feature model, e, similarmente ao fmp, era apresentado em forma de rvore completa para a seleo de features. Uma vez feita a seleo de features, o usurio deve clicar na opo check model para verificar se a seleo de features respeita todas as restries no modelo. O family model no foi utilizado, uma vez que isso iria requerer o desenvolvimento de uma aplicao de lojas on-line, o que estava fora do escopo do projeto. Entretanto, ele poderia ter sido usado para a definio de componentes Java que s entrariam num produto quando devidas features fossem selecionadas. Aps ajustar o sistema de transformao para gerar o que o usurio deseja, o processo de derivao um simples clique no boto transform model de um variant model. As Figuras 10 e 11 apresentam os modelos gerados durante o estudo de caso no pure::variants.

ESCOLA POLITCNICA DE PERNAMBUCO

35

Figura 10. Feature model do EShop no pure::variants

Figura 11. Instncia do EShop no pure::variants

ESCOLA POLITCNICA DE PERNAMBUCO

36

3.4 Gears
Ao contrrio de todas as ferramentas analisadas at agora, a Gears, desenvolvida pela BigLever Software Inc., no um plugin para o Eclipse, e sim uma ferramenta completamente stand-alone. A empresa tem como objetivo o desenvolvimento de softwares para sistemas embarcados, que se baseia no desenvolvimento de componentes de software e de ferramentas de desenvolvimento de software. A Gears uma das ferramentas de feature model mais populares no mundo comercial, o que motivou a idia de avali-la, porm no foi possvel utiliz-la, pois os desenvolvedores no forneceram uma verso demo. Entretanto, tentou-se descobrir o mximo sobre a mesma para apresentar neste trabalho.

3.4.1

Background

Ao contrrio das outras ferramentas analisadas, a Gears essencialmente uma ferramenta com fundo comercial, em contraste s avaliadas anteriormente, que possuam fundo acadmico. De acordo com a BigLever a Gears utilizada com sucesso pela LSI Logic, pela Salion e pela HomeAway, citando resultados impressionantes obtidos aps o uso da ferramenta. O projeto continua sendo desenvolvido e suportado pela empresa atualmente.

3.4.2

Custo
3 dias de um projeto de

O custo exato da Gears desconhecido, porm, na seo de avaliao disponvel no site, o pacote de avaliao getting started custa 5 mil dlares e inclui

desenvolvimento e consultoria piloto onsite (algum da BigLever iria na empresa pessoalmente acompanhar desenvolvimento), meio dia de preparao e ps-processamento interativo off-site (na prpria BigLever) para resumir os resultados e garantia de satisfao, se o cliente no estiver 100% satisfeito, o custo do pacote reembolsado.

3.4.3

Tcnica de modelagem e notao utilizada

As informaes sobre a tcnica de modelagem e notao utilizadas pela Gears so escassas. Sabe-se que ela utiliza uma metodologia de linhas de produtos chamada 3-Tiered Software Product Line Methodology, que aparenta ser similar ao que o pure::variants oferece, que contm os seguintes nveis: base tier gerenciamento de variaes e gerao de produtos, middle tier desenvolvimento focado nos artefatos core, top tier evoluo do portfolio baseada em features.

ESCOLA POLITCNICA DE PERNAMBUCO

37

A base tier pode ser considerada a parte de variant models e gerao de produtos do pure::variants, enquanto middle tier seria o family model e o top tier seria o feature model. A Figura 7 demonstra a interface da Gears.

Figura 12. Interface da Gears

ESCOLA POLITCNICA DE PERNAMBUCO

38

Captulo 4 Comparao das Ferramentas

Visando facilitar a comparao entre as ferramentas, utilizando os critrios que foram analisados no captulo anterior, assim como alguns recursos que as ferramentas possuam, ou no, este captulo apresentar as tabelas comparativas entre as ferramentas.

4.1 Ferramentas de Linhas de Produtos de Software

A Tabela 1 apresenta uma comparao entre as ferramentas analisadas com os critrios que foram analisados a fundo no Captulo 3. Ela resume todas as informaes apresentadas nas sees do Captulo 3 sobre cada ferramenta.

ESCOLA POLITCNICA DE PERNAMBUCO

39

Tabela 1. Principais caractersticas das ferramentas Critrio Background Suporte a processo Notao utilizada Ferramentas Fmp Acadmico No rvore XFeature Acadmico No rvore Diagrama pure::variants Industrial Sim e rvore, Diagrama Tabela Implementao Tipo de licena Plugin Open Source Plugin Open Source Plugin Gratuito Comercial Cdigo fonte Tcnicas modelagem Disponvel de Baseada Disponvel em Varivel No disponvel Derivada FODA No disponvel de Desconhecido Stand-alone e Comercial e Gears Industrial Sim Desconhecido

cardinalidade

A Tabela 1 apresenta critrios de alto nvel, incluindo alguns que so mais do interesse da gerncia do que dos desenvolvedores, tais como tipo de licena, background e suporte a processo (se suportam mais do que apenas a modelagem do domnio, se suportam a gerao do produtos, documentao dos modelos, edio do cdigo, etc), que afeta vrios nveis do desenvolvimento de um projeto, no apenas a programao. J a Tabela 2 apresenta recursos disponveis nas ferramentas que so mais pertinentes aos desenvolvedores que iro utiliz-las no dia a dia. Ela apresenta uma comparao entre alguns dos recursos disponveis nas ferramentas analisadas. Alguns destes recursos foram mencionados no Captulo 3, porm alguns que foram considerados importantes pelo autor tambm so apresentados, como controle de verso, se as features podem ser documentadas, se a ferramenta possui checagem de consistncia dos modelos, etc.

ESCOLA POLITCNICA DE PERNAMBUCO

40

Tabela 2. Recursos das ferramentas Critrio Representao de dados em forma tabular Checagem de consistncia Documentao das features Controle de Verso Possui configuration knowledge Derivao de produtos Restries Ferramentas fmp No Sim Sim No No No XFeature pure::variants No Sim Sim No No No Sim Sim Sim Sim Sim Sim Prolog pvSCL Sim No /

XPath e linguagem XSL prpria

Cardinalidade em relacionamentos

Sim

Com esses dados em mo, espera-se que a tomada de deciso por parte dos desenvolvedores e da gerncia sobre qual ferramenta utilizar para facilitar o desenvolvimento de uma Linha de Produtos de Software seja simplificada, podendo ser fundamenta em critrios que sejam importantes para a empresa, critrios estes que podem variar de uma empresa para outra.

ESCOLA POLITCNICA DE PERNAMBUCO

41

Captulo 5 Concluso
A utilizao do conceito de Linhas de Produto de Software tem gerado muitos casos de sucesso na indstria, e, definitivamente, algo que deve ser considerado por empresas que desejam manter a competitividade no mercado em que trabalham. Este trabalho apresentou uma anlise comparativa entre 4(quatro) das principais ferramentas de apoio ao desenvolvimento baseado em Linha de Produtos de Software. Uma das ferramentas, a Gears, no pde ser analisada a fundo, uma vez que no havia uma verso para testes disponvel on-line. Este estudo demonstrou as principais caractersticas das ferramentas analisadas e apresentou os dados de forma resumida e concisa, permitindo que gerentes e desenvolvedores possam fazer uma escolha consciente sobre qual ferramenta devem utilizar na sua linha de produtos. Pde-se perceber que se a empresa deseja mais do que apenas modelar o domnio, a escolha certa seria uma das ferramentas pagas, uma vez que as gratuitas no possuem o recurso de configuration knowledge. Como trabalhos futuros, outras ferramentas existentes podem ser analisadas, assim como uma anlise mais a fundo das que foram apresentadas neste trabalho pode ser realizada, como a utilizao do recurso de configuration knowledge do pure::variants, alm de tambm a realizao de estudos empricos do uso das ferramentas em um ambiente real de desenvolvimento de linhas de produtos.

ESCOLA POLITCNICA DE PERNAMBUCO

42

Bibliografia
[1] CLEMENTS, Paul e Northrop, LINDA. Software Product Lines: Practices and Patterns. Addison-Wesley, 2002 [2] ANTIEWICZ, M. e CZARNECKI, K.. FeaturePlugin: Feature Modeling Plug-in for Eclipse. In Eclipse 04: Proceedings of the 2004 OOPSLA Workshop on Eclipse Technology eXchange, OOPSLA, Vancouver, British Columbia, Canada, Pages 67 - 72, ACM Press, 2004. [3] PURE::VARIANTS, pgina web http://www.pure-

systems.com/Variant_Management.49.0.html, acessado em 20 de abril de 2008. [4] XFEATURE, pgina weeb http://www.pnp-software.com/XFeature/, acessado em 20 de abril de 2008. [5] [6] GEARS, pgina web http://www.biglever.com/, acessado em 20 de abril de 2008. KRUEGER, Charles. Easing the transition to software mass customization. In Proceedings of the 4th International Workshop on Software Product-Family Engineering. Spain, October 2001. [7] KICZALES, G., LAMPING, J., MENDHEKAR, A., MAEDA, C., LOPES, C., LOINTGIER, J. e IRWIN, J.. Aspect-oriented programming. ECOOP, 1997. [8] CZARNECKI, K.. Overview of Generative Software Development. In Proceedings of the European Commission and US National Science Foundation Strategic Research Workshop on Unconventional Programming Paradigms, September, 1517, 2004, Mont Saint-Michel, France, 2004. [9] CZARNECKI, K. e EISENECKER, U.. Generative Programming: Methods, Tools, and Applications. Addison-Wesley, 2000. [10] KANG, K., COHEN, S., HESS, J., NOWAK, W. e PETERSON, S.. Feature-oriented domain analysis (FODA) feasibility study. Technical Report CMU/SEI-90TR -21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, Nov. 1990.

ESCOLA POLITCNICA DE PERNAMBUCO

43

[11]

CZARNECKI, K., HELSEN, S. e EISENECKER, U.. Formalizing cardinality-based feature models and their specialization. Software Process Improvement and Practice, 10(1):729, jan/mar 2005.

[12]

EMF ECLIPSE MODELING FRAMEWORK, http://www.eclipse.org/emf/, acessado em 20 de abril de 2008.

[13]

XSLT

EXTENSIBLE

STYLESHEET

TRANSFORMATIONS,

pgina

web

http://www.w3.org/TR/xslt, acessado em 20 de abril de 2008. [14] CIRILO, E., KULESZA, U. e LUCENA, C.. GenArch: Uma Ferramenta baseada em Modelos para Derivao de Produtos de Software. Anais da Sesso de Ferramentas do SBCARS 2007. [15] CECHTICKY, V., PASETTI, A., ROHLIK, O. e SCHAUFELBERGER, W.. XML-Based Feature Modelling. In J. Bosch and C. Krueger, editors, Software Reuse: Methods, Techniques and Tools: 8th International Conference, ICSR 2004, Madrid, Spain, July 5-9, 2009. Proceedings, volume 3107 of Lecture Notes in Computer Science, pages 101-114. Springer-Verlag, 2004. [16] BEUCHE, D., PAPJEWSKI, H. e SCHRODER-PREIKSCHAT W.. Variability Management with Feature Models. Proceedings of the Workshop on Software Variability Management, 2003: p. 72-83. [17] GENERATIVE SOFTWARE DEVELOPMENT GROUP, pgina web

http://gsd.waterloo.ca/, acessado em 20 de abril de 2008. [18] XML PATH LANGUAGE (XPATH) 2.0, pgina web http://www.w3.org/TR/xpath20, acessado em 20 de abril de 2008.