Captulo

1
Linhas de Produtos de Software: Uma tendncia da indstria
Francisco Airton Pereira da Silva, Paulo Anselmo da Mota Silveira Neto, Vinicius Cardoso Garcia e Patrcia Fontinele Muniz

Abstract Over the past few years a new approach to software reuse has gained attention both by industry and academia. This approach is known as software product line development wich is based upon the systematic reuse of software artifacts, through exploiting commonalities and managing variabilities among products, that are established under a common architecture. This concept of product lines have been used by the manufacturing industry for a long time to reduce costs and increase productivity. However, product line practice in the software industry is a relatively new concept. Studies have shown that organizations can yield remarkable improvements mainly in productivity by applying this approach. In this context, this chapter presents some of the most important aspects related to software product lines, such as variability, development processes and nally presents some tools to support Software Product Line (SPL). Resumo Ao longo dos ltimos anos uma nova abordagem de reuso de software tem ganhado ateno tanto pela indstria quanto pela academia. Esta abordagem conhecida como Linhas de Produtos de Software na qual baseada na reutilizao sistemtica de artefatos de software, atravs da explorao de pontos comuns e a gesto de variabilidade entre os produtos, que so estabelecidos sob uma mesma arquitetura. Este conceito de linhas de produtos tem sido utilizado pela indstria de manufatura a anos para reduzir custos e aumentar a produtividade. No entanto esta prtica possui um conceito relativamente novo na indstria de software. Estudos tm demonstrado que as organizaes tm apresentado melhorias principalmente na produtividade aplicando esta abordagem. Neste contexto, este trabalho apresenta alguns dos aspectos mais importantes sobre linhas de produtos de software, tais como variabilidade, processos de desenvolvimento e nalmente mostrando algumas ferramentas de apoio a Linhas de Produtos de Software (LPS).

1.1. INTRODUO
A maneira que os bens de consumo so produzidos mudou signicativamente no decorrer do tempo. Anteriormente mercadorias eram especicas para clientes individuais. Cada vez mais, o nmero de pessoas que poderiam ter recursos para comprar vrios tipos de produto foi aumentando. No domnio dos automveis, isso levou inveno por Henry Ford da linha de produo, o que permitiu a produo para um mercado de massa muito mais barata do que a criao de cada produto em uma base artesanal. No entanto, a linha de produo reduziu as possibilidades de diversicao. A grosso modo, ambos os tipos de produtos, individual e os produzidos em massa tambm podem ser identicados no domnio de software: eles so denominados como software individual e software padro. Geralmente, cada um destes tipos de produtos tem suas desvantagens. Produtos de software individuais so bastante caros pois exigem um maior esforo desenvolvendo especidades de um nico produto, enquanto produtos de software padro (sem muita especicidade) existe a falta de diversicao suciente para atender bem s expectativas de muitos clientes diferentes. No incio os clientes estavam satisfeitos com os produtos padronizados em massa por um tempo, mas nem todas as pessoas queriam o mesmo tipo de carro para qualquer nalidade. Certos carros so usados para viajar por uma nica pessoa, outros por grandes famlias por exemplo. Assim, a indstria foi confrontada com uma crescente demanda por produtos individualizados. Este foi o incio da chamada customizao em massa, o que signicava atender s exigncias dos clientes dando-lhes o que eles queriam. Para o cliente a customizao em massa signica a capacidade de ter um produto individualizado, no entanto para a indstria signica maiores investimentos em tecnologia que elevam os preos de produtos individualizados e / ou menores margens de lucro para a empresa. Ambos os efeitos so indesejveis. Assim, muitas empresas, especialmente na indstria automobilstica, comearam a apresentar plataformas comuns para os seus diferentes tipos de carros planejando de antemo quais peas seriam usadas em vrios tipos de carros diferentes. Ao longo do tempo a plataforma foi sendo trabalhada a m de se tornar cada vez mais adaptvel a novos componentes. As partes compreendendo a plataforma eram geralmente mais caras em termos do projeto e os custos de preparao de fabricao. Porm esta estratgia levou a uma reduo no custo de produo para um tipo de carro particular [21]. A indstria de automveis passou por esta transformao na forma de produzir seus produtos e a indstria de software tambm necessita atender ao mesmo requisito de individualidade e cada vez mais produo em massa. O mercado de desenvolvimento de software precisa construir os produtos de software com melhor qualidade, reduo de custos, adaptao rpida s mudanas, e menor tempo de colocao no mercado atendendo s necessidades dos clientes. Visando estas expectativas vrios esforos em criar processos e arquituras de sistemas tem sido realizadas ao longo dos anos [16]. Seguindo por este caminho uma nova abordagem para reutilizao de software tem ganhado considervel ateno tanto pela indstria quanto pela academia. Esta abordagem conhecida como Linha de Produtos de Software (LPS) onde a idia bsica o

trabalho sobre um grupo de sistemas compartilhando um conjunto comum e gerenciado de funcionalidades (features) que satisfazem necessidades especcas de um segmento, e desenvolvidos a partir de um aglomerado comum de artefatos base e de forma previamente planejada. Em outras palavras LPS faz uso da reusabilidade para construir sistemas com menos esforo desde que estes pertenam a uma mesma famlia, ou seja, que possuam pontos em comum [17]. Este captulo est organizado como segue: na seo 1.2 ser apresentada uma viso geral sobre as peculiaridades sobre Linhas de Produtos de Software, incluindo idias comparativas entre estas metodologias e o reuso de software tradicional. Na seo 1.3 como as variantes de um produto podem ser gerenciadas. Na seo 1.4 atividades exercidas no desenvolvimento de LPS, mostrando algumas ferramentas. Finalmente na seo 1.5 so apresentadas as concluses.

1.2. VISO GERAL SOBRE LINHAS DE PRODUTOS DE SOFTWARE

Os artefatos mencionados na seo anterior devem ser reutilizados de uma forma consistente e sistemtica, a m de construir aplicativos robustos em LPS. Artefatos reutilizveis abrangem todos os tipos de artefatos de desenvolvimento de software, tais como modelos de requisitos, modelos de arquitetura, componentes de software e planos de teste. A experincia de projetos que fazem uso de reutilizao na dcada de 1990 mostraram que, sem planejamento adequado, os custos do projeto com reutilizao pode ser maior do que para desenvolver os artefatos a partir do zero. Assim, fundamental planejar com antecedncia os produtos para os quais a reutilizao ser aplicada, juntamente com as features que caracterizam estes produtos. O planejamento para reutilizao continua durante todo o processo de desenvolvimento [21]. Para facilitar a customizao em massa a plataforma deve fornecer os meios para satisfazer as necessidades dos diferentes stakeholders. Para este propsito, o conceito de variabilidade foi criado, para explorar as caractersticas que variam em relao aos diversos produtos. Como conseqncia de aplicar este conceito, os artefatos que podem serem diferentes nas aplicaes da linha de produtos so modelados usando variabilidade [21]. 1.2.1. Processos de Desenvolvimento O paradigma de linha de produtos de software dividido em dois processos, a saber: 1. Engenharia de Domnio: Este processo responsvel por estabelecer a plataforma de reutilizao e, assim denir comunalidade e a variabilidade da linha de produtos. A plataforma consiste em todos as tipos de artefatos de software (requisitos, design, testes, etc.) tambm chamados de ativos base. 2. Engenharia de Aplicao: Este processo responsvel por derivar aplicaes concretas a partir da plataforma estabelecida na engenharia de domnio. Ela explora a variabilidade da linha de produtos e assegura sua correta instanciao de acordo com as necessidades especcas das aplicaes nais.

Figura 1.1. Dois ciclos de vida que separam engenharia de domnio e aplicao.

A vantagem dessa diviso que h uma separao de objetivos, para construir uma plataforma robusta e para construir aplicaes especcas em um curto espao de tempo. Para ser ecaz, os dois processos devem interagir de uma maneira que seja benca para ambos. A Figura 1.1 mostra como estes processos interagem entre si e qual o resultado dos mesmos atravs de um uxo de informaes. Tanto na engenharia de domnio quanto na engenharia de aplicao so realizadas atividades de anlise, arquitetura, implementao e testes para ao nal serem gerados os produtos. 1.2.2. Linha de Produtos de Software e Reuso de Software Tradicional Desenvolvimento de uma LPS envolve "reuso"e a primeira vista este desenvolvimento pode parecer apenas um reuso de software tradicional. No entanto desenvolvimento de uma linha de produtos de software muito mais elaborado do que a reutilizao de software tradicional. No reuso de software tradicional, as organizaes possuem repositrios onde a sada de praticamente todo o esforo de desenvolvimento armazenado. Este repositrio normalmente contm alguma biblioteca de reutilizao de componentes, mdulos e algoritmos que desenvolvedores so incentivados a usar. O problema com este tipo de reutilizao que, geralmente, leva mais tempo para encontrar a funcionalidade desejada e adapt-la aplicao atual do que para constru-la novamente [7]. Este tipo de reutilizao ad hoc no o que caracteriza o desenvolvimento de linhas de produtos de software. Em desenvolvimento de linhas de produtos o reuso planejado, automatizado e sistemtico [20]. O "repositrio de reuso"de uma linha de

produtos de software conhecido como ativos base. Estes elementos incluem todos os artefatos que so os mais caros para desenvolver como modelos de domnio, requisitos, arquitetura, componentes, casos de teste, etc. Alm disso, esses ativos so do incio do desenvolvido a m de serem reutilizados em vrios produtos. Isto signica que a customizao de ativos para o produto atual, normalmente no inclue nenhum cdigo novo como ocorreria em abordagens tradicionais. Ao invs disto ocorre uma instanciao do produto, utilizando mecanismos de variabilidade incorporadas aos ativos base. Outra abordagem para reutilizao de software que se assemelha a de desenvolvimento de software em linhas de produtos conhecido como a abordagem "clone and own"[20]. Os produtos desenvolvidos por esta abordagem tem um foco no produto individual, no ocorre um foco na famlia de produtos de software, e portanto, no implementa os mecanismos de variabilidade que caracterizam o desenvolvimento da famlia de produtos. Portanto quando um projeto novo iniciado por esta abordagem, a equipe de desenvolvimento tenta encontrar um outro produto dentro da organizao que se assemelha o produto atual, tanto quanto possvel. Eles, ento, copiam tudo o que podem a partir desse projeto, modicam e adicionam o que necessario para lanar o novo produto. Esta abordagem pode render uma economia considervel em comparao com desenvolvimento de todos os produtos a partir do zero. No entanto, ao comparar o "clone and own"com a abordagem de desenvolvimento de linha de produtos, o "clone and own"apresenta algumas desvantagens principais: 1. No desenvolvimento de linha de produtos todos os artefatos de maiores custos do projeto so reutilizados, no apenas o cdigo que o foco principal da abordagem "clone and own". 2. No desenvolvimento de linha de produtos todos os ativos base so desenvolvidos tendo em mente a idia de reutilizao e variabilidade. Na abordagem "clone and own", tudo desenvolvido com foco no produto individual, onde os recursos no sero gastos no desenvolvimento de mecanismos de variabilidade que no sero usados por este produto. Isto implica que o "clone"exigir um esforo considervel de customizao para atender os requisitos do novo produto comparado a outro dentro de uma linha de produtos. Os ativos base de uma linha de produtos provavelmente no iro precisar de um alto grau de customizao para atender aos requisitos de novos produtos, mas sim uma instanciao de mecanismos integrados de variabilidade anteriormente construdos. 3. Quando "clonamos"um produto j existente, para criar um novo produto, as ligaes entre estes projetos so inexistentes e futuramente ocorrer manutenes individuais nos dois produtos. No caso do desenvolvimento de linha de produtos, uma economia considervel pode ser realizada ao longo do ciclo de vida destes, pois a manuteno dos ativos base uma responsabilidade compartilhada por todos os produtos na famlia.

1.2.3. Aspectos importantes na adoo de Linhas de Produtos de Software A adoo de linhas de produtos de software diferente em alguns sentidos em relao a adopo de outros tipos de tecnologias e processos. Sua adoo requer bastante tempo, principalmente em estgios iniciais [17]. Isso envolve a mudana na forma de desenvolvimento de sistemas que possui a idia de sistema nico para o desenvolvimento de vrios produtos a partir de uma plataforma [19]. A adoo envolve ter uma base de ativos base, processos de suporte, e estruturas organizacionais; desenvolver produtos a partir da base de ativos de uma forma que sejam atingidos objetivos de negcio; e instituir mecanismos para melhorar e extender o esforo de produo de software, desde que faa sentido. No entanto, dependendo do cenrio, atingir as metas de adoo pode tornar-se uma atividade complexa. A m de evitar complexidades adicionais durante a fase de adoo, Gary [8] argumenta que uma organizao que pretende adotar uma abordagem de linha de produto deve ter objetivos claros em mente. Para atingir seus objetivos, a organizao seleciona um ou mais estratgias de adoo que especicam como ele sero abraadas as prticas de linhas de produtos. Em seguida, um plano de adoo mostra em detalhes que atividades devem ser realizadas para implementar essas estratgias. Neste sentido, todo o conceito de adoo de linha de produtos se torna muito pessoal para a organizao, o contexto especco parece desempenhar um papel signicativo na deciso de adoo [8]. Portanto, a transferncia deve ser sistematicamente e planejada. 1.2.4. Vantagens em Linhas de Produtos de Software Teorias relacionadas a linhas de produtos de software pode gerar diversos benefcios classicados em trs tipos: benefcios organizacionais, os benefcios de engenharia de software e os benefcios de negcio. Os benefcios organizacionais agrupam vantagens como uma melhor compreenso do domnio, a maior facilidade de treinar pessoas, um produto de maior qualidade e consequentemente conana do cliente. Os benefcios da engenharia de software incluem vantagens como a reutilizao de requisitos e seus componentes, uma melhor anlise de requisitos, uma outra viso sobre os requisitos para o cliente, controle de qualidade de software, estabelecimento de padres de programao. E por ltimo mas no menos importante, benefcios comerciais dizem respeito reduo de manu-teno e custos de teste (graas reutilizao entre vrios produtos semelhantes). Alm disso, as linhas de produtos geram uma melhor ecincia nos processos e a possibilidade de aumentar o oramento e melhorar o planejamento do tempo por ter maior controle dos componentes que fazem parte do produto nal. Uma descrio detalhada dos benefcios pode ser encontrada na seo "benefcios e custos da linha de produtos"em [6]. Vrias estatsticas concretas so apresentados para ilustrar as melhorias de custos, tempo de mercado e produtividade [15].

1. Nokia capaz de produzir 25-30 modelos diferentes de celular por ano por causa da abordagem de linha de produtos. 2. Cummins, Inc., foi capaz de reduzir o tempo que leva para produzir o software de um motor diesel de cerca de um ano para cerca de uma semana. 3. Motorola observou uma melhoria de produtividade de 400% em uma famlia de determinado tipo de celular. 4. Hewlett-Packard reportou uma reduo no time to market por um fator de sete e um aumento na produtividade por um fator de seis, em uma famlia de sistemas de impressoras.

1.2.5. Desvantagens em Linhas de Produtos de Software Realizar uma mudana de um modo original de desenvolvimento de software em uma organizao do ponto de vista de um produto nico para uma abordagem com linha de produtos envolve uma mudana fundamental para a organizao e para as mentalidades que pode trazer o que chamamos de resistncia a mudanas. Outro problema est relacionado ao fato de poucos engenheiros de software terem uma viso global sobre toda a arquitetura de linha de produtos. Nos estudos de caso apresentados em vrias partes do livro [11], ele enfatiza a necessidade de um especialista na linha de produtos que sabe perfeitamente como funciona o domnio da aplicao, que tem responsabilidade suciente, autoridade, experincia dentro da empresa, que tem motivao e compreenso sobre teorias em linhas de produtos de software. Algumas diculdades podem aparecer, quando uma deciso deve ser tomada para mesclar ou no um novo produto com a linha de produtos. A evoluo do domnio requer cautela para xar o alcance da linha de produtos. De fato, um escopo muito amplo torna a manuteno de ativos base demasiadamente complexa para haver reutilizao de forma ecaz, e um escopo muito limitado no justica o custo de desenvolvimento e manuteno do ncleo dos ativos base. Projetar arquiteturas de linha de produto muitas vezes se torna difcil, devido falta de diretrizes, representaes maduras de como validar arquiteturas de referncia e ferramentas integradas para desenvolver e explorar as linhas de produtos de software. Dado as diculdades apresentadas, Sholom [11] lista alguns problemas diferentes com base em um questionrio, ressaltando que a resistncia organizacional e de investimento so os mais crticos dentre todos os problemas (Tabela 1.1). Quando comparamos o desenvolvimento tradicional de software com o desenvolvimento a partir de linhas de produtos (Figure 1.2), podemos salientar que neste ltimo precisa-se de uma gesto a longo prazo, porque os benefcios visveis no so imediatos. De fato, nos primeiros estgios em LPS necessrio um investimento inicial considervel onde o ponto de equilbrio de investimento/retorno seria alcanado geralmente a mdio prazo. Um nmero suciente de produtos devem ser desenvolvidos a m de apreciar as vantagens reais .

Tabela 1.1.

Riscos na

adoo de LPS [11]

Risco Porcentagem Resistencia organizacional 52% Resistncia da gesto 36% Resistncia dos desenvolvedores 32% Preocupaes com grandes investimentos 45% Falta de pessoal devidamente treinado 29% Incapacidade de medir o impacto 19% Preocupao com o tempo de um projeto 18%

Figura 1.2. Comparao de custos entre abordagem tradicional e LPS [11]

1.3. VARIABILIDADE
O conceito de variabilidade est relacionado s possibilidades de mudar ou personalizar um sistema. A Figura 1.3 ilustra como a variabilidade de um sistema de software limitada durante todo o projeto de construo do mesmo. No incio a quantidade de sistemas possveis grande pois as restries so mnimas. Durante a execuo do projeto na construo do sistema as possibilidades diminuem, at que nalmente em tempo de execuo existe exatamente um sistema apenas. Em cada etapa do desenvolvimento, decises de design so feitas. Cada deciso restringe o nmero de possveis sistemas Com a abordagem de LPS as variabilidades so modeladas na arquitectura de referncia da LPS (atravs da representao dos Pontos de Variabilidade e Variantes respectivos) e resolvidas antes da instalao dos produtos. Um Ponto de Variabilidade corresponde a um aspecto de variao funcional num elemento de software base. O ponto de variabilidade dene o conjunto de possveis variantes, o mecanismo de variabilidade a utilizar para os instanciar e o tempo de ativao dos variantes, e.g. instanciao da arquitectura de software do produto, tempo de compilao, execuo.

 Um Variante corresponde a uma opo do conjunto de possveis instncias de variao que um ponto de variabilidade poder originar.

Figura 1.3. Quantidade de produtos possveis

Em geral h sempre um certo grau de variabilidade difcil de manter em LPS. Reusabilidade e exibilidade tm sido a fora motriz por trs do desenvolvimento de tcnicas como orientao a objetos, frameworks orientados a objeto e LPS. Os Pontos de Variabilidade podem ser apresentados em vrios nveis de abstrao [4]: Descrio da Arquitetura. Tipicamente, o sistema descrito usando uma combinao de documentos de alto nvel de design, linguagens de descrio de arquitetura e documentao textual. Documentao por Diagramas. A este nvel o sistema pode ser descrito usando vrias notaes UML. Cdigo-Fonte. A este nvel, uma descrio completa na forma de cdigo-fonte criado. Cdigo Compilado. O cdigo fonte convertido para o cdigo compilado usando um compilador. Os resultados desta compilao pode ser inuenciada por meio de directivas de pr-processamento para ento o resultaodo ser combinado. Cdigo Ligado. Durante a fase de ligao, os resultados da fase de compilao so combinados. Isto pode ser feito estaticamente (em tempo de compilao) ou dinamicamente (em tempo de execuo).

 Cdigo de Execuo. Durante a execuo, o sistema j construdo iniciado e congurado. Ao contrrio das representaes anteriores, o sistema de execuo dinmico e muda o tempo todo. 1.3.1. Gerenciando Variabilidades Ao desenvolver uma LPS, o objetivo nal torn-la exvel o suciente para atender s novas exigncias. Os pontos de variabilidade mais importantes precisam ser identicados antecipadamente, a m de alcanar este objetivo. Acontece que muitas vezes muito difcil de adaptar uma arquitetura existente para suportar um certo ponto de variabilidade. Segundo Muhammad [4] a gesto da variabilidade consiste nas seguintes tarefas: Identicando Variabilidades. Na fase inicial de desenvolvimento de uma LPS, os desenvolvedores so confrontadas com uma srie de requisitos. Eles devem de alguma forma trabalhar sobre estes requisitos formando uma especicao mais adequada para a LPS. O objetivo deste processo no chegar a um especicao completa da LPS, mas sim identicar a diferena entre os produtos (ou seja, onde as "coisas"tendem a variar) e quais caractersticas so compartilhadas por todos os produtos. Feature Models apresentam uma excelente forma de representar variabilidades. Introduzindo a variabilidade no sistema. Uma vez que a variabilidade foi identicada, o sistema deve ser projetado de tal forma que ela possa ser introduzida. Existe uma ampla gama de mecanismos e tcnicas para esta tarefa. O mecanismo escolhido depende do nvel em que a variabilidade introduzida, o tempo que o sistema ser ligado a um variante particular e a forma como novas variantes (se houver) sero adicionadas ao sistema. Agrupando as variantes. Esta fase resulta em um conjunto de variantes associadas a um ponto de variabilidade. A coleo de variantes pode ser implcita ou explcita. No caso da implcita o sistema baseia-se no conhecimento dos desenvolvedores ou usurios para escolherem variantes adequadas quando assim for necessrio. Uma coleo explcita, por outro lado, implica que o sistema pode, por si s, decidir qual variante usar. A coleo pode ser fechada, o que signica que nenhuma nova variante pode ser adicionada, ou ela pode permanecer aberta para novas adies. Vinculando o sistema a uma variante. Resulta em um sistema onde um ponto de variabilidade particular associado a uma de suas variantes. Esta vinculao pode ser feita internamente ou externamente, a partir da perspectiva de sistemas. Uma ligao interna implica que o sistema possui a capacidade de vincular uma variante particular, ao passo que se a ligao realizada externamente, o sistema tem que contar com outras ferramentas, como ferramentas de gerenciamento de congurao para executar a vinculao. Relacionando esta com o agrupamento de variantes, vemos que a gesto de variabilidade pode ser implcita e externa, implcita e interna, ou explcita e interna. A seleo de qual variante usar envolve escolher uma variante dentre o conjunto de variantes.

1.3.2. Feature Model Comunalidade e variabilidade entre produtos de uma linha pode ser expressa em termos de features. O conceito de feature foi originalmente apresentado pelo mtodo Feature Oriented Domain Analysis (FODA). De acordo com este modelo uma feature uma caracterstica do sistema visvel ao usurio nal. Uma feature denida como uma unidade lgica de comportamento que especicada por um conjunto de requisitos funcionais e de qualidade. Alm disso, o comportamento deve ser relevante para um ou vrios stakeholders de um produto [7]. O conceito de feature simplica o trabalho com os requisitos, porque ele pode ser usado para agrupar um conjunto de requisitos relacionados. Em outras palavras, as features so uma forma de abstrair os requisitos. importante perceber que existe uma relao n-para-n entre features e requisitos. Por esta relao com os requisitos o conceito de feature pode tambm diminuir a distncia em termos de comunicao entre o usurio nal e o desenvolvedor. Os usurios podem reportar defeitos ou requisies de uma nova funcionalidade por meio de features e desenvolvedores podem ento reinterpretar esta representao transformando-a em aes a serem aplicadas ao ciclo de vida da construo do produto [7]. Deste modo, medida que reunimos em um grco, as features de um sistema ns construmos um feature model. O feature model procura apresentar uma viso geral de alto nvel das principais caractersticas comuns e variveis de uma linha de produtos. 1.3.3. Notao F.O.D.A O mtodo Feature Oriented Domain Analysis (FODA) foi desenvolvido no Software Engineering Institute para representar gracametne o feature model. Sua descrio detalhada do processo de Anlise de Domnio o fez tornar-se um dos mtodos mais populares na dcada de 1990. Em particular, FODA fez uma contribuio signicativa para a popularidade atual da anlise orientada a modelo: o uso de vrias vises complementares de um domnio para transmitir informaes mais completas sobre ele [14]. A modelagem de features de maneira explcita a chave para o mtodo FODA, e base para muitos dos trabalhos posteriores. FODA se posiciona como parte integrante da engenharia de domnio a m de facilitar a engenharia de aplicao. O feature model foi introduzido como parte do mtodo FODA, e representa uma hierarquia de propriedades de conceitos do domnio. uma das tcnicas mais bem sucedidas para facilitar a reutilizao de artefactos de software. O feature model uma representao hierrquica, que visa captar os relacionamentos estruturais entre as features de um domnio de aplicao. O modelo tambm representa as features comuns e variveis de instncias de conceitos (por exemplo, sistemas de software) e dependncias entre as features variveis. Um feature model consiste em um diagrama composto de features e alguma informao adicional, tais como descries semnticas de cada feature, pontos variveis, prioridades e regras de dependncia. No contexto das linhas de produto de software, um feature model representa a prpria linha de produtos. Uma feature pode ser de um dos seguintes tipos:

 Obrigatria: A feature tem de estar presente em todos os membros da linha de produtos. Opcional: A feature pode ou no estar presente em um membro da linha de produtos. Alternativa: uma feature que composta de um conjunto de features das quais se escolhe uma ou mais, devendo-se indicar se necessrio escolher apenas uma ou se se pode escolher mais que uma. Nestas features necessrio fazer a distino de alternativas OR, que permite mais do que uma feature, e XOR, que mostra a excluso mtua. Uma feature obrigatria representada por uma aresta terminada por um crculo preenchido a preto. Uma feature opcional representada por uma aresta terminada por um crculo vazio. As features alternativas so representadas por arestas que esto ligadas e conectadas por um arco. Se o arco for vazio deve-se escolher apenas uma das alternativas (XOR), se for preenchido permitido escolher mais de uma alternativa (OR) [23]. Czarnecki [13] prope colocar cardinalidade nas features para poder remover ambiguidades e representar a informao mais facilmente, sendo as diferentes cardinalidades assim denidas: 0..1 Pode-se escolher uma ou nenhuma feature do conjunto de sub-features. 1 Exatamente uma feature tem de ser escolhida de um conjunto de sub-features. 0..* Um nmero arbitrrio de features (ou nenhuma) tem de ser selecionado do conjunto de sub-features. 1..* Pelo menos uma feature tem de ser seleccionada do conjunto de sub-features.

Figura 1.4. e-Shop [22]

A Figura 1.4 mostra uma possvel representao para o modelo de features do Sistema e-Shop [22].

Neste modelo so features obrigatrias Catalog, Payment, GUI e Info, so features opcionais Security, Banners, Offers, Search. A feature Security possui um grupo de subfeatures numa alternativa XOR que indica que apenas uma delas escolhida para a aplicao. No caso da feature Payment, esta composta por duas sub-features numa alternativa OR (uma ou as duas podem ser escolhidas). Note que uma feature lha pode aparecer apenas em um produto se sua feature superior aparecer. A feature raiz parte de todos os produtos dentro da LPS. Adicionalmente aos relacionamentos parental entre features, pode ocorrer tambm o que chamamos de cross-tree entre features, que signica que uma feature pode estar relacionada a outra s que no em uma relao de parentesco, podendo ser dos seguintes dois tipos: Requires. Se uma feature A requer a feature B, a incluso de A em um produto implica na incluso tambm de B. No sistema de exemplo pagamento com carto de crdito deve implementar uma poltica de segurana alta. Excludes. Se a feature A exclui a feature B, ambas as features no podem fazer parte do mesmo produto. No sistema de exemplo o produto que implementar uma interface GUI mobile no deve incluir suporte a banners. 1.3.4. Conguration 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 Conguration Knowledge [12]. Os artefatos de implementao podem estar modelados direto no modelo que representa o conguration knowledge ou em um modelo a parte, neste caso o conguration knowledge associar os artefatos de um modelo com as features do feature model. Quando no esto dentro do conguration 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 conguration knowledge essencialmente um conjunto de regras que denem que artefatos de implementao (classes, arquivos de recursos, etc) entram em cada produto da linha. Tomando o E-Shop 1.4 como exemplo em um ambiente de desenvolvimento orientado a objetos, uma classe chamada Catalog (que trata dos produtos disponveis na loja) estaria representada no conguration knowledge como uma regra que diz se a feature Catalog 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 verica se todas as restries presentes no feature model foram respeitadas em cada instncia, e, para cada seleo de features, verica que artefatos de implementao estaro habilitados na instncia. Uma vez que todas as vericaes 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 especicar 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 nais, permitindo assim uma maior customizao do processo de gerao.

1.4. ENGENHARIA DE LINHA DE PRODUTOS DE SOFTWARE

1.4.1. Atividades Essenciais em Linha de Produtos de Software Linhas de Produto de Software combinam trs atividades essenciais e altamente interativas que se misturam prticas de negcios e tecnologia. Em primeiro lugar, atividade de Core Asset Development onde o objetivo no criar o produto nal imediatamente e sim visa o desenvolvimento de ativos a serem reutilizados em outras atividades posteriores. Em segundo lugar, vem a atividade denominada Product Development que parte dos ativos base j desenvolvidos anteriormente reusando-os. Finalmente Management Activity, que inclui gesto tcnica e organizacional [16]. A Figura 1.5 mostra esta trade de atividades essenciais. Cada crculo giratrio representa uma das atividades essenciais. Todos os trs so ligados entre si e em movimento perptuo, mostrando que todos os trs so essenciais e esto intimamente ligados, podendo ocorrer em qualquer ordem, e so altamente iterativos [17].

Figura 1.5. Atividades Essenciais [17]

1.4.1.1. Desenvolvimento de Ativos Base Core Asset Development uma atividade na forma de ciclo de vida que resulta em ativos base que em conjunto compem a plataforma da linha de produto [16]. O objetivo desta atividade denir os aspectos comuns e a variabilidade da linha de produtos, e, portanto, obter artefatos reutilizveis para em seguida possuir uma capacidade de produo maior [21]. A Figura 1.6 mostra o ncleo desta atividade juntamente com suas sadas e insumos necessrios.

Figura 1.6. Desenvolvimento de Ativos Base [17]

As setas rotatrias na Figura 1.6 sugerem que no h um momento certo de adicionar uma restrio ou novos padres no desenvolvimento e estas entradas afetam diretamente as sadas no processo. Em alguns contextos os produtos existentes so a base para os ativos base em outros estes podem ser desenvolvidos do zero para futuro reuso. Ativos base incluem, mas no esto limitados arquitetura e sua documentao, especicaes, componentes de software, ferramentas como geradores de componentes ou aplicao, modelos de desempenho, cronogramas, oramentos, planos de teste, casos de teste, planos de trabalho e processo descries [17]. Embora possa ser possvel a criao de ativos base que podem ser utilizados em todos os produtos sem quaisquer adaptaes, em muitos casos, algumas adaptaes so necessrias para torn-los mais utilizveis no contexto mais amplo de uma linha de produtos. Logo, mecanismos de variao dos principais ativos base utilizados ajudam a controlar as adaptaes necessrias e suportar as diferenas entre os produtos de software [5]. Essas adaptaes devem ser planejadas antes do desenvolvimento e facilitada para a equipe de desenvolvimento do produto sem colocar em risco as propriedades existentes dos ativos base.

1.4.1.2. Desenvolvimento de Produtos Na atividade de desenvolvimento de produto, os produtos so desenvolvidos a partir dos ativos base, com base no plano de produo, para satisfazer as exigncias da linha de produtos de software. Os insumos essenciais da atividade de desenvolvimento de produto so requisitos, escopo da linha de produtos, ativos base e o plano de produo [3]. De posse do plano de produo, que detalha como os ativos base sero utilizados para construir um produto, o engenheiro de software pode montar as partes da linha de produtos. A Figura 1.7 ilustra o produto atividade de desenvolvimento, juntamente com suas sadas e fatores contextuais.

Figura 1.7. Desenvolvimento de Produtos [17]

Como na Figura 1.5, as setas de rotao na Figura 1.7 indicam iteraes entre as partes envovidas. Por exemplo, a existncia e a disponibilidade de um determinado produto pode assim afetar os requisitos de produtos subseqentes. Como outro exemplo de construo, um produto que tem em comunalidades previamente no reconhecidas em relao a outro produto da linha vai criar a necessidade de para atualizao dos ativos base e fornecer uma base para explorar essa comunilidade em futuros produtos [17]. Alm disso, esta atividade tem a obrigao de dar feedback sobre quaisquer problemas ou decincias encontradas com os ativos base.

1.4.1.3. Atividade de Gesto A atividade de Management desempenha um papel vital no sucesso da institucionalizao da linha dentro de uma organizao porque fornece e coordena a sua infra-estrutura necessria. Esta tarefa envolve atividades essenciais realizadas a nvel tcnico e organizacionais para apoiar o ciclo de vida do processo [3]. A gesto supervisiona a construo dos ativos base e atividades de desenvolvimento do produto, garantindo que os grupos que constroem os ativos base e os grupos que

constroem os produtos esto plenamente envolvidos nas atividades individuais, acompanhando o processo denido para a linha de produtos acompanhando seu progresso [17]. Isto representa no apenas os aspectos tcnicos mas tambm aspectos gerenciais e organizacionais. O conjunto de ativos base e plano de como eles so usados para construir os produtos no nascem sem previamente estudar o ambiente, caracterizar o negcio, portanto deve existir investimento organizacional. A gesto deve dirigir, controlar e garantir a plena utilizao dos ativos. Linhas de produtos de software est mais relacionado a prticas de negcios do que prticas tcnicas [17]. Embora as organizaes sejam diferentes em termos da natureza de seus produtos, de mercado ou misso, objetivos de negcio, estrutura organizacional, cultura e polticas, as disciplinas de processo de software, e assim por diante, atividades essenciais aqui discutidas aplicam-se em qualquer situao, uma vez que representam o nvel mais alto de generalidade, que envolve os aspectos mais importantes sobre o desenvolvimento em LPS. Em geral, as organizaes realizam essa diviso de responsabilidades em uma variedade de maneiras. Algumas organizaes tm equipes dedicadas a cada funo e outros usam as mesmas pessoas para ambas. Depende da disponibilidade oramentria, estratgia entre outros aspectos. Na verdade, vlido mencionar que no h atividade primria, isto , em alguns contextos, os produtos j existentes so quebrados em ativos base, enquanto que em outros, os ativos base podem ser desenvolvidos para uso futuro [18]. De acordo com Clements e Northrop [17], em muitos casos, a parte da gesto a atividade responsvel pelo sucesso ou fracasso do produto nal de uma linha de produtos. 1.4.2. Abordagens de Construo de Linha de Produtos de Software Segundo Chen [10], existem trs abordagens principais de desenvolvimento em linha de produtos de software (ver Figura 1.8): Proativa: Com esta abordagem os ativos base so desenvolvidos primeiro para futuro produtos. Aqui so considerados todos os produtos a serem gerados previamente fazendo-se um planejamento inicial completo. Reativa: Nesta abordagem os ativos base j existem, bem como uma verso da linha de produtos, o que acontece a evoluo desta linha realizando-se incrementos na mesma medida que novos requisitos aparecem. Extrativa: Com esta abordagem, inicialmente so analizados quais os produtos j existentes e como eles so estruturados de modo a extrair as comunalidades e variabilidades destes para ento poder se derivar uma verso inicial da Linha de Produtos. Dependendo do grau de planejamento, a abordagem proativa pode ser classicada em abordagem big bang e abordagem incrementa (ver Figura 1.9).

Figura 1.8. Abordagens em LPS

Na estratgia big bang, LPS adotada para os novos produtos de uma s vez, uma mudana drstica. Primeiramente a engenharia de domnio construda completamente e a plataforma modelada e desenvolvida. Quando os ativos base esto prontos a engenharia de aplicao inicia e as aplicaes so derivadas da plataforma [21]. Com abordagem incremental, os ativos base so gradualmente desenvolvidas para suporte aos futuros produtos. J a abordagem reativa pode ser quebrada em trs subcategories (ver Figura 1.9):

Figura 1.9. Subcategorias de abordagens em LPS [10]

baseado em infra-estrutura,

 baseado em branch-and-unit, e baseado em bulk-integration. A abordagem baseada em infra-estrutura no permite que os produtos individuais estejam desatualizados em relao aos ativos base comuns a vrios produtos, ou seja, a plataforma deve manter sempre a integridade em relao aos produtos, exigindo que novas caractersticas comuns sejam implementadas primeiro nos ativos base que iro compor os produtos, em seguida, construindo os produtos. Tanto o branch-and-unit quanto a abordagem bulk-integration permitem um desalinhamento temporrio entre ativos base e os produtos individuais. A diferena entre estas duas sub-abordagens est na quantidade de produtos que se espera ser lanado antes de atualizar os ativos base. A estratgia branch-and-unit exige que novas features comuns sejam reintegradas nos ativos base imediatamente aps o lanamento do novo produto, enquanto que bulkintegration permite que novas features comuns serem reintegrados aps o lanamento de um grupo de produtos. Estas abordagens no so mutuamente exclusivas. Por exemplo, uma linha de produtos pode ser adotada por meio de um abordagem proativa e, em seguida, evoluir atravs de uma abordagem reativa. 1.4.3. Ferramentas Nesta seo iremos abordar algumas ferramentas relacionadas basicamente modelagem de feature models. Aguiar [2] realizou um estudo comparativo sobre as principais ferramentas de apoio a Linha de Produtos de Software e abaixo seguem algumas caractersticas descritivas deste trabalho. 1.4.3.1. fmp O fmp (Feature Model Plugin) um plugin gratuito para o Eclipse desenvolvido pelo Generative Software Development Lab, da University of Waterloo [1]. Ele utiliza como base o Eclipse Modeling Framework, o que, de acordo com os desenvolvedores, reduziu signicativamente o esforo de desenvolvimento. O fmp apenas apresenta suporte modelagem do domnio, atravs de feature models. Ele no possui nenhuma funcionalidade de conguration 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. 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 (do ingls Extensible Stylesheet Language Transformation), por exemplo, possam processar o modelo. Por ser um plugin para o Eclipse e possuir uma API bem denida, possibilita que outras ferramentas se integrem com o mesmo.

Figura 1.10. Interface do fmp

O fmp implementa modelagem de features baseada em cardinalidades [13], ou seja, permite a denio de cardinalidades de feature e de grupo, atributos de feature, referncias e anotaes denidas pelo usurio. Cardinalidades de feature e grupo permitem que sejam especicados o nmero mnimo e mximo de lhos 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 denidas pelo 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 denidas pelo usurio, o fmp permite que o usurio altere o meta-modelo do feature model, permitindo, por exemplo, que toda feature tenha um atributo chamado "quantidade"; ou qualquer coisa que o usurio deseje colocar (Ver Figura 1.10). 1.4.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 congurao de artefatos reusveis de software. A ferramenta se apresenta como inovadora pela possibilidade de customizao do metamodelo da famlia de produtos [9]. O XFeature tem suporte modelagem do domnio, atravs de feature models e no possui a funcionalidade de conguration knowledge, que permite o mapeamento necessrio entre features e artefatos da linha de produtos para permitir a gerao dos produtos. 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. Em relao implementao, o XFeature foi implementado baseado na verso 3.3 do Eclipse, ao contrrio do fmp, ele no utilizou o EMF para a denio 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 vericao e gerao de arquivos de congurao da aplicao, tais como os que customizam o editor dos modelos. O processo de criao de modelos no XFeature consideravelmente mais complicado do que nas outras ferramentas. Primeiramente se dene qual ser a congurao utilizada (FD, FMP, SimpliedICSR 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 congurao 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 congurao dos modelos que vo conter as instncias da linha de produto, e o meta-modelo de display dene 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 ca preso nica congurao 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 denido pelo usurio anteriormente. Quando os modelos estiverem validados, eles podem ser utilizados como entrada pra outras ferramentas que possuam a parte de conguration knowledge para gerar os produtos nais. A Figura 1.11 demonstra a 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 denio 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 vericao das restries.

Figura 1.11. Interface do Xfeature

1.4.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 conguration knowledge, que permite o mapeamento necessrio entre features e artefatos da linha de produtos para permitir a gerao dos produtos. 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 modicaes 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. O pure::variants utiliza uma notao baseada em FODA. Ele possui 3(trs) tipos de modelos diferentes: o feature model: onde so denidas as caractersticas comuns e variabilidades da linha de produtos, o family model: a parte do conguration knowledge onde se encontram os componentes que compem os artefatos da linha de produtos, e o variant model: que o modelo que dene 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 dene, e a denio 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 denido 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. A Figura 1.12 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).

Figura 1.12. Interface de Edio do Family Model do pure::variants

1.5. Concluses
Ao longo deste captulo foram analizados diversos conceitos sobre LPS, propiciando ao leitor uma viso geral sobre o assunto. Alm disto foram mostradas caractersticas sobre a notao F.O.D.A para construo de feature models bem como o que vem a ser uma Conguration Knowledge, dentre outros conceitos e princpios. Foi visto que as organizaes podem obter benefcios de negcio considerveis em termos de reduo de custos, reduo do tempo de colocao no mercado, aumento na qualidade do produto, etc, aplicando desenvolvimento de linhas de produto. H, porm, riscos e custos associados adopo das empresas para esta adoo que devem ser avaliados antes de embarcar em uma iniciativa de reutilizao deste tipo. Organizaes tm colocado projetos ad hoc em "stand by"a m de deixar livre recursos para construir ativos base de uma LPS. Isto implica em grandes custos, no etando existem muitas experincias bem sucedidas deste tipo de empreendimento. Portanto qualquer organizao que desenvolve produtos como sistemas simples, que tem bons conhecimentos do domnio do negcio e um nvel razoavelmente elevado de maturidade do processo, deve, pelo menos, fazer um estudo de viabilidade para observar se o desenvolvimento de uma LPS pode ser benca para eles.

Referncias
[1] GENERATIVE SOFTWARE DEVELOPMENT GROUP. http://www.sei.cmu.edu/plp/ web-page acessada em 14 de outubro de 2011. [2] Rogerio Aguiar. Comparacao entre ferramentas para Linha de Produtos de Software. Escola Politecnica de Pernambuco. Departamento de Sistemas e Computacao. http://dsc.upe.br/ tcc/20081/RogeriomonograaFinal.pdf Acessado em 14 de outubro de 2011. [3] F. Ahmed, P. Campbell, and M.S. Lagharid. Cognitive factors in software product line engineering. In Computer Modelling and Simulation, 2009. UKSIM 09. 11th International Conference on, pages 352 355, march 2009. [4] Muhammad Ali Babar, Lianping Chen, and Forrest Shull. Managing variability in software product lines. IEEE Software, 27:8991, 94, 2010. [5] Felix Bachmann and Paul C Clements. Variability in software product lines. Software Engineering Institute Pittsburgh USA, (September):46, 2005. [6] Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2 edition, 2003. [7] Jan Bosch. Design and use of software architectures: adopting and evolving a product-line approach. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA, 2000. [8] Stan Buhne, Gary Chastek, Timo Kakola, Peter Knauber, Linda Northrop, and Steffen Thiel. S.: Exploring the context of product line adoption. In In: Proc. 5th Int. Workshop on Product Family Engineering, 2003.

[9] V Cechticky, A Pasetti, O Rohlik, and W Schaufelberger. Xml-based feature modelling. Software Reuse Methods Techniques and Tools, pages 101114, 2004. [10] Y Chen, G C Gannod, and J S Collofello. A software product line process simulator. Software Process: Improvement and Practice, 11(4):385409, 2006. [11] Sholom Cohen. Product line state of the practice report. Technical report, Software Engineering Institute, Carnegie Mellon University, 2002. [12] Krzysztof Czarnecki and Ulrich W. Eisenecker. Generative programming: methods, tools, and applications. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA, 2000. [13] Eisenecker U. Czarnecki K., Helsen S. Staged conguration using feature models, software product lines. International Conference SPLC, 2004. [14] K Kang. Feature-oriented domain analysis feasibility study. Technical report, SEI Technical Report, 1990. [15] Paul C. Clements Len Baas and Rick Kazman. Software Architecture in Practice. Second Edition. SEI Series in Software Engineering. Addison-Wesley, 2003. [16] Schmid K. Linden, F. J. v. d. and E. Rommes. Software Product Lines in Action:The Best Industrial Practice in Product Line Engineering. Springer-Verlag, 2007. [17] C.A. Long. Software product lines: practices and patterns [book review]. Software, IEEE, 19(4):131 132, jul/aug 2002. [18] John D. McGregor, Linda M. Northrop, Salah Jarrad, and Klaus Pohl. Guest editors introduction: Initiating software product lines. IEEE Softw., 19:2427, July 2002. [19] Northrop. Software product line adoption roadmap. SEI Technical Note, 2004. [20] SEI PLP. Framework for Product Line Practice. http://www.sei.cmu.edu/plp/, 2003. [21] Klaus Pohl, Gnter Bckle, and Frank J. van der Linden. Software Product Line Engineering: Foundations, Principles and Techniques. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2005. [22] S. Segura, R.M. Hierons, D. Benavides, and Ruiz-Corte. Automated test data generation on the analyses of feature models: A metamorphic testing approach. pages 35 44, april 2010. [23] Arie van Deursen and Paul Klint. Domain-specic language design requires feature descriptions. Journal of Computing and Information Technology, 10, 2001.