Capítulo

1
Linhas de Produtos de Software: Uma tendência
da indústria

Francisco Airton Pereira da Silva, Paulo Anselmo da Mota Silveira Neto,

Vinicius Cardoso Garcia e Patrícia Fontinele Muniz

Abstract

Over the past few years a new approach to software reuse has gained attention both by in-
dustry 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 archi-
tecture. 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 finally presents some tools
to support Software Product Line (SPL).

Resumo

Ao longo dos últimos anos uma nova abordagem de reuso de software tem ganhado aten-
ção tanto pela indústria quanto pela academia. Esta abordagem é conhecida como Li-
nhas de Produtos de Software na qual é baseada na reutilização sistemática de artefatos
de software, através da exploração de pontos comuns e a gestão de variabilidade entre os
produtos, que são estabelecidos sob uma mesma arquitetura. Este conceito de linhas de
produtos tem sido utilizado pela indústria de manufatura a anos para reduzir custos e au-
mentar a produtividade. No entanto esta prática possui um conceito relativamente novo
na indústria de software. Estudos têm demonstrado que as organizações têm 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 finalmente mostrando
algumas ferramentas de apoio a Linhas de Produtos de Software (LPS).
1.1. INTRODUÇÃO
A maneira que os bens de consumo são produzidos mudou significativamente no decorrer
do tempo. Anteriormente mercadorias eram especificas para clientes individuais. Cada
vez mais, o número de pessoas que poderiam ter recursos para comprar vários tipos de
produto foi aumentando. No domínio dos automóveis, isso levou à invenção por Henry
Ford da linha de produção, o que permitiu a produção para um mercado de massa muito
mais barata do que a criação de cada produto em uma base artesanal. No entanto, a linha
de produção reduziu as possibilidades de diversificação.
A grosso modo, ambos os tipos de produtos, individual e os produzidos em massa
também podem ser identificados no domínio de software: eles são denominados como
software individual e software padrão. Geralmente, cada um destes tipos de produtos tem
suas desvantagens. Produtos de software individuais são bastante caros pois exigem um
maior esforço desenvolvendo espeficidades de um único produto, enquanto produtos de
software padrão (sem muita especificidade) existe a falta de diversificação suficiente para
atender bem às expectativas de muitos clientes diferentes.
No início 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
finalidade. Certos carros são usados para viajar por uma única pessoa, outros por grandes
famílias por exemplo. Assim, a indústria foi confrontada com uma crescente demanda
por produtos individualizados. Este foi o início da chamada customização em massa, o
que significava atender às exigências dos clientes dando-lhes o que eles queriam.
Para o cliente a customização em massa significa a capacidade de ter um produto
individualizado, no entanto para a indústria significa maiores investimentos em tecnologia
que elevam os preços de produtos individualizados e / ou menores margens de lucro para
a empresa. Ambos os efeitos são indesejáveis. Assim, muitas empresas, especialmente
na indústria automobilística, começaram a apresentar plataformas comuns para os seus
diferentes tipos de carros planejando de antemão quais peças seriam usadas em vários
tipos de carros diferentes.
Ao longo do tempo a plataforma foi sendo trabalhada a fim de se tornar cada
vez mais adaptável a novos componentes. As partes compreendendo a plataforma eram
geralmente mais caras em termos do projeto e os custos de preparação de fabricação.
Porém esta estratégia levou a uma redução no custo de produção para um tipo de carro
particular [21].
A indústria de automóveis passou por esta transformação na forma de produzir
seus produtos e a indústria de software também necessita atender ao mesmo requisito de
individualidade e cada vez mais produção em massa. O mercado de desenvolvimento de
software precisa construir os produtos de software com melhor qualidade, redução de cus-
tos, adaptação rápida às mudanças, e menor tempo de colocação no mercado atendendo às
necessidades dos clientes. Visando estas expectativas vários esforços em criar processos
e arquituras de sistemas tem sido realizadas ao longo dos anos [16].
Seguindo por este caminho uma nova abordagem para reutilização de software
tem ganhado considerável atenção tanto pela indústria quanto pela academia. Esta abor-
dagem é conhecida como Linha de Produtos de Software (LPS) onde a idéia básica é o
trabalho sobre um grupo de sistemas compartilhando um conjunto comum e gerenciado
de funcionalidades (features) que satisfazem necessidades específicas 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 esforço desde que estes pertençam a uma mesma família, ou seja, que possuam
pontos em comum [17].
Este capítulo está organizado como segue: na seção 1.2 será apresentada uma vi-
são geral sobre as peculiaridades sobre Linhas de Produtos de Software, incluindo idéias
comparativas entre estas metodologias e o reuso de software tradicional. Na seção 1.3
como as variantes de um produto podem ser gerenciadas. Na seção 1.4 atividades exer-
cidas no desenvolvimento de LPS, mostrando algumas ferramentas. Finalmente na seção
1.5 são apresentadas as conclusões.

1.2. VISÃO GERAL SOBRE LINHAS DE PRODUTOS DE SOFTWARE

Os artefatos mencionados na seção anterior devem ser reutilizados de uma forma consis-
tente e sistemática, a fim de construir aplicativos robustos em LPS. Artefatos reutilizáveis
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 experiência de projetos que fazem uso de reutilização na década de 1990 mos-
traram que, sem planejamento adequado, os custos do projeto com reutilização pode ser
maior do que para desenvolver os artefatos a partir do zero. Assim, é fundamental planejar
com antecedência os produtos para os quais a reutilização será aplicada, juntamente com
as features que caracterizam estes produtos. O planejamento para reutilização continua
durante todo o processo de desenvolvimento [21].
Para facilitar a customização em massa a plataforma deve fornecer os meios para
satisfazer as necessidades dos diferentes stakeholders. Para este propósito, o conceito
de variabilidade foi criado, para explorar as características que variam em relação aos
diversos produtos. Como conseqüência de aplicar este conceito, os artefatos que podem
serem diferentes nas aplicações da linha de produtos são 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 Domínio: Este processo é responsável por estabelecer a plataforma

de reutilização e, assim definir comunalidade e a variabilidade da linha de produtos.
A plataforma consiste em todos as tipos de artefatos de software (requisitos, design,
testes, etc.) também chamados de ativos base.

2. Engenharia de Aplicação: Este processo é responsável por derivar aplicações con-

cretas a partir da plataforma estabelecida na engenharia de domínio. Ela explora a
variabilidade da linha de produtos e assegura sua correta instanciação de acordo
com as necessidades específicas das aplicações finais.
 Figura 1.1. Dois ciclos de vida que separam engenharia de domínio e aplicação.

A vantagem dessa divisão é que há uma separação de objetivos, para construir uma
plataforma robusta e para construir aplicações específicas em um curto espaço de tempo.
Para ser eficaz, os dois processos devem interagir de uma maneira que seja benéfica para
ambos.
A Figura 1.1 mostra como estes processos interagem entre si e qual o resultado dos
mesmos através de um fluxo de informações. Tanto na engenharia de domínio quanto na
engenharia de aplicação são realizadas atividades de análise, arquitetura, implementação
e testes para ao final 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 reutilização de soft-
ware tradicional. No reuso de software tradicional, as organizações possuem repositórios
onde a saída de praticamente todo o esforço de desenvolvimento é armazenado. Este repo-
sitório normalmente contêm alguma biblioteca de reutilização de componentes, módulos
e algoritmos que desenvolvedores são incentivados a usar. O problema com este tipo de
reutilização é que, geralmente, leva mais tempo para encontrar a funcionalidade desejada
e adaptá-la à aplicação atual do que para construí-la novamente [7].
Este tipo de reutilização ad hoc não é o que caracteriza o desenvolvimento de
linhas de produtos de software. Em desenvolvimento de linhas de produtos o reuso é
planejado, automatizado e sistemático [20]. O "repositório de reuso"de uma linha de
produtos de software é conhecido como ativos base. Estes elementos incluem todos os
artefatos que são os mais caros para desenvolver como modelos de domínio, requisitos,
arquitetura, componentes, casos de teste, etc.
Além disso, esses ativos são do início do desenvolvido a fim de serem reutilizados
em vários produtos. Isto significa que a customização de ativos para o produto atual, nor-
malmente não inclue nenhum código novo como ocorreria em abordagens tradicionais.
Ao invés disto ocorre uma instanciação do produto, utilizando mecanismos de variabili-
dade incorporadas aos ativos base.
Outra abordagem para reutilização de software que se assemelha a de desenvol-
vimento 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 indivi-
dual, não ocorre um foco na família de produtos de software, e portanto, não implementa
os mecanismos de variabilidade que caracterizam o desenvolvimento da família de pro-
dutos.
Portanto quando um projeto novo é iniciado por esta abordagem, a equipe de de-
senvolvimento tenta encontrar um outro produto dentro da organização que se assemelha o
produto atual, tanto quanto possível. Eles, então, copiam tudo o que podem a partir desse
projeto, modificam e adicionam o que é necessario para lançar o novo produto. Esta abor-
dagem pode render uma economia considerável em comparação 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 algu-
mas desvantagens principais:

1. No desenvolvimento de linha de produtos todos os artefatos de maiores custos do

projeto são reutilizados, não apenas o código que é o foco principal da abordagem
"clone and own".

2. No desenvolvimento de linha de produtos todos os ativos base são desenvolvidos

tendo em mente a idéia de reutilização e variabilidade. Na abordagem "clone and
own", tudo é desenvolvido com foco no produto individual, onde os recursos não
serão gastos no desenvolvimento de mecanismos de variabilidade que não serão
usados por este produto. Isto implica que o "clone"exigirá um esforço considerá-
vel de customização para atender os requisitos do novo produto comparado a outro
dentro de uma linha de produtos. Os ativos base de uma linha de produtos pro-
vavelmente não irão precisar de um alto grau de customização para atender aos
requisitos de novos produtos, mas sim uma instanciação de mecanismos integrados
de variabilidade anteriormente construídos.

3. Quando "clonamos"um produto já existente, para criar um novo produto, as liga-

ções entre estes projetos são inexistentes e futuramente ocorrerá manutenções indi-
viduais nos dois produtos. No caso do desenvolvimento de linha de produtos, uma
economia considerável pode ser realizada ao longo do ciclo de vida destes, pois
a manutenção dos ativos base é uma responsabilidade compartilhada por todos os
produtos na família.
1.2.3. Aspectos importantes na adoção de Linhas de Produtos de Software
A adoção de linhas de produtos de software é diferente em alguns sentidos em relação a
adopção de outros tipos de tecnologias e processos. Sua adoção requer bastante tempo,
principalmente em estágios iniciais [17]. Isso envolve a mudança na forma de desenvolvi-
mento de sistemas que possui a idéia de sistema único para o desenvolvimento de vários
produtos a partir de uma plataforma [19].
A adoção 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 negócio; e instituir mecanismos para melhorar e extender o esforço
de produção de software, desde que faça sentido. No entanto, dependendo do cenário,
atingir as metas de adoção pode tornar-se uma atividade complexa.
A fim de evitar complexidades adicionais durante a fase de adoção, Gary [8] argu-
menta que uma organização que pretende adotar uma abordagem de linha de produto deve
ter objetivos claros em mente. Para atingir seus objetivos, a organização seleciona um ou
mais estratégias de adoção que especificam como ele serão abraçadas as práticas de linhas
de produtos. Em seguida, um plano de adoção mostra em detalhes que atividades devem
ser realizadas para implementar essas estratégias.
Neste sentido, todo o conceito de adoção de linha de produtos se torna muito pes-
soal para a organização, o contexto específico parece desempenhar um papel significativo
na decisão de adoção [8]. Portanto, a transferência 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 benefícios clas-
sificados em três tipos: benefícios organizacionais, os benefícios de engenharia de soft-
ware e os benefícios de negócio.
Os benefícios organizacionais agrupam vantagens como uma melhor compreen-
são do domínio, a maior facilidade de treinar pessoas, um produto de maior qualidade e
consequentemente confiança do cliente.
Os benefícios da engenharia de software incluem vantagens como a reutilização
de requisitos e seus componentes, uma melhor análise de requisitos, uma outra visão
sobre os requisitos para o cliente, controle de qualidade de software, estabelecimento de
padrões de programação.
E por último mas não menos importante, benefícios comerciais dizem respeito
à redução de manu-tenção e custos de teste (graças à reutilização entre vários produtos
semelhantes). Além disso, as linhas de produtos geram uma melhor eficiência nos pro-
cessos e a possibilidade de aumentar o orçamento e melhorar o planejamento do tempo
por ter maior controle dos componentes que fazem parte do produto final. Uma descrição
detalhada dos benefícios pode ser encontrada na seção "benefícios e custos da linha de
produtos"em [6].
Várias estatísticas concretas são 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 família de

determinado tipo de celular.

4. Hewlett-Packard reportou uma redução no time to market por um fator de sete e

um aumento na produtividade por um fator de seis, em uma família de sistemas de
impressoras.

1.2.5. Desvantagens em Linhas de Produtos de Software

Realizar uma mudança de um modo original de desenvolvimento de software em uma
organização do ponto de vista de um produto único para uma abordagem com linha de
produtos envolve uma mudança fundamental para a organização e para as mentalidades
que pode trazer o que chamamos de resistência a mudanças.
Outro problema está relacionado ao fato de poucos engenheiros de software te-
rem uma visão global sobre toda a arquitetura de linha de produtos. Nos estudos de caso
apresentados em várias partes do livro [11], ele enfatiza a necessidade de um especia-
lista na linha de produtos que sabe perfeitamente como funciona o domínio da aplicação,
que tem responsabilidade suficiente, autoridade, experiência dentro da empresa, que tem
motivação e compreensão sobre teorias em linhas de produtos de software.
Algumas dificuldades podem aparecer, quando uma decisão deve ser tomada para
mesclar ou não um novo produto com a linha de produtos. A evolução do domínio requer
cautela para fixar o alcance da linha de produtos. De fato, um escopo muito amplo torna
a manutenção de ativos base demasiadamente complexa para haver reutilização de forma
eficaz, e um escopo muito limitado não justifica o custo de desenvolvimento e manutenção
do núcleo dos ativos base.
Projetar arquiteturas de linha de produto muitas vezes se torna difícil, devido à
falta de diretrizes, representações maduras de como validar arquiteturas de referência e
ferramentas integradas para desenvolver e explorar as linhas de produtos de software.
Dado as dificuldades apresentadas, Sholom [11] lista alguns problemas diferentes com
base em um questionário, ressaltando que a resistência organizacional e de investimento
são os mais críticos dentre todos os problemas (Tabela 1.1).
Quando comparamos o desenvolvimento tradicional de software com o desenvol-
vimento a partir de linhas de produtos (Figure 1.2), podemos salientar que neste último
precisa-se de uma gestão a longo prazo, porque os benefícios visíveis não são imediatos.
De fato, nos primeiros estágios em LPS é necessário um investimento inicial considerável
onde o ponto de equilíbrio de investimento/retorno seria alcançado geralmente a médio
prazo. Um número suficiente de produtos devem ser desenvolvidos a fim de apreciar as
vantagens reais .
 Tabela 1.1. Riscos na adoção de LPS [11]
Risco Porcentagem
Resistencia organizacional 52%
Resistência da gestão 36%
Resistência dos desenvolvedores 32%
Preocupações com grandes investimentos 45%
Falta de pessoal devidamente treinado 29%
Incapacidade de medir o impacto 19%
Preocupação com o tempo de um projeto 18%

Figura 1.2. Comparação 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 é limi-
tada durante todo o projeto de construção do mesmo. No início a quantidade de sistemas
possíveis é grande pois as restrições são mínimas. Durante a execução do projeto na cons-
trução do sistema as possibilidades diminuem, até que finalmente em tempo de execução
existe exatamente um sistema apenas. Em cada etapa do desenvolvimento, decisões de
design são feitas. Cada decisão restringe o número de possíveis sistemas
Com a abordagem de LPS as variabilidades são modeladas na arquitectura de
referência da LPS (através da representação dos Pontos de Variabilidade e Variantes res-
pectivos) e resolvidas antes da instalação dos produtos.

• Um Ponto de Variabilidade corresponde a um aspecto de variação funcional num

elemento de software base. O ponto de variabilidade define o conjunto de possíveis
variantes, o mecanismo de variabilidade a utilizar para os instanciar e o tempo de
ativação dos variantes, e.g. instanciação da arquitectura de software do produto,
tempo de compilação, execução.
 • Um Variante corresponde a uma opção do conjunto de possíveis instâncias de va-
riação que um ponto de variabilidade poderá originar.

Figura 1.3. Quantidade de produtos possíveis

Em geral há sempre um certo grau de variabilidade difícil de manter em LPS.

Reusabilidade e flexibilidade têm sido a força motriz por trás do desenvolvimento de
técnicas como orientação a objetos, frameworks orientados a objeto e LPS.
Os Pontos de Variabilidade podem ser apresentados em vários níveis de abstração
[4]:

• Descrição da Arquitetura. Tipicamente, o sistema é descrito usando uma combi-

nação de documentos de alto nível de design, linguagens de descrição de arquitetura
e documentação textual.

• Documentação por Diagramas. A este nível o sistema pode ser descrito usando
várias notações UML.

• Código-Fonte. A este nível, uma descrição completa na forma de código-fonte é

criado.

• Código Compilado. O código fonte é convertido para o código compilado usando

um compilador. Os resultados desta compilação pode ser influenciada por meio de
directivas de pré-processamento para então o resultaodo ser combinado.

• Código Ligado. Durante a fase de ligação, os resultados da fase de compilação

são combinados. Isto pode ser feito estaticamente (em tempo de compilação) ou
dinamicamente (em tempo de execução).
 • Código de Execução. Durante a execução, o sistema já construído é iniciado e
configurado. Ao contrário das representações anteriores, o sistema de execução é
dinâmico e muda o tempo todo.

1.3.1. Gerenciando Variabilidades

Ao desenvolver uma LPS, o objetivo final é torná-la flexível o suficiente para atender às
novas exigências. Os pontos de variabilidade mais importantes precisam ser identificados
antecipadamente, a fim de alcançar este objetivo. Acontece que muitas vezes é muito
difícil de adaptar uma arquitetura existente para suportar um certo ponto de variabilidade.
Segundo Muhammad [4] a gestão da variabilidade consiste nas seguintes tarefas:

• Identificando Variabilidades. Na fase inicial de desenvolvimento de uma LPS,

os desenvolvedores são confrontadas com uma série de requisitos. Eles devem de
alguma forma trabalhar sobre estes requisitos formando uma especificação mais
adequada para a LPS. O objetivo deste processo não é chegar a um especificação
completa da LPS, mas sim identificar a diferença entre os produtos (ou seja, onde
as "coisas"tendem a variar) e quais características são compartilhadas por todos os
produtos. Feature Models apresentam uma excelente forma de representar variabi-
lidades.

• Introduzindo a variabilidade no sistema. Uma vez que a variabilidade foi iden-

tificada, o sistema deve ser projetado de tal forma que ela possa ser introduzida.
Existe uma ampla gama de mecanismos e técnicas para esta tarefa. O mecanismo
escolhido depende do nível em que a variabilidade é introduzida, o tempo que o
sistema será ligado a um variante particular e a forma como novas variantes (se
houver) serão adicionadas ao sistema.

• Agrupando as variantes. Esta fase resulta em um conjunto de variantes associadas

a um ponto de variabilidade. A coleção de variantes pode ser implícita ou explícita.
No caso da implícita o sistema baseia-se no conhecimento dos desenvolvedores ou
usuários para escolherem variantes adequadas quando assim for necessário. Uma
coleção explícita, por outro lado, implica que o sistema pode, por si só, decidir
qual variante usar. A coleção pode ser fechada, o que significa que nenhuma nova
variante pode ser adicionada, ou ela pode permanecer aberta para novas adições.

• Vinculando o sistema a uma variante. Resulta em um sistema onde um ponto de

variabilidade particular é associado a uma de suas variantes. Esta vinculação pode
ser feita internamente ou externamente, a partir da perspectiva de sistemas. Uma
ligação interna implica que o sistema possui a capacidade de vincular uma variante
particular, ao passo que se a ligação é realizada externamente, o sistema tem que
contar com outras ferramentas, como ferramentas de gerenciamento de configura-
ção para executar a vinculação. Relacionando esta com o agrupamento de variantes,
vemos que a gestão de variabilidade pode ser implícita e externa, implícita e interna,
ou explícita e interna. A seleção 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 método Feature
Oriented Domain Analysis (FODA). De acordo com este modelo uma feature é uma ca-
racterística do sistema visível ao usuário final. Uma feature é definida como uma unidade
lógica de comportamento que é especificada por um conjunto de requisitos funcionais e
de qualidade. Além disso, o comportamento deve ser relevante para um ou vários sta-
keholders de um produto [7].
O conceito de feature simplifica o trabalho com os requisitos, porque ele pode
ser usado para agrupar um conjunto de requisitos relacionados. Em outras palavras, as
features são uma forma de abstrair os requisitos. É importante perceber que existe uma
relação n-para-n entre features e requisitos.
Por esta relação com os requisitos o conceito de feature pode também diminuir a
distância em termos de comunicação entre o usuário final e o desenvolvedor. Os usuários
podem reportar defeitos ou requisições de uma nova funcionalidade por meio de features e
desenvolvedores podem então reinterpretar esta representação transformando-a em ações
a serem aplicadas ao ciclo de vida da construção do produto [7].
Deste modo, á medida que reunimos em um gráfico, as features de um sistema
nós construímos um feature model. O feature model procura apresentar uma visão geral
de alto nível das principais características comuns e variáveis de uma linha de produtos.

1.3.3. Notação F.O.D.A

O método Feature Oriented Domain Analysis (FODA) foi desenvolvido no Software En-
gineering Institute para representar graficametne o feature model. Sua descrição detalhada
do processo de Análise de Domínio o fez tornar-se um dos métodos mais populares na
década de 1990. Em particular, FODA fez uma contribuição significativa para a popula-
ridade atual da análise orientada a modelo: o uso de várias visões complementares de um
domínio para transmitir informações mais completas sobre ele [14].
A modelagem de features de maneira explícita é a chave para o método FODA, e
é base para muitos dos trabalhos posteriores. FODA se posiciona como parte integrante
da engenharia de domínio a fim de facilitar a engenharia de aplicação.
O feature model foi introduzido como parte do método FODA, e representa uma
hierarquia de propriedades de conceitos do domínio. É uma das técnicas mais bem su-
cedidas para facilitar a reutilização de artefactos de software. O feature model é uma
representação hierárquica, que visa captar os relacionamentos estruturais entre as features
de um domínio de aplicação. O modelo também representa as features comuns e variá-
veis de instâncias de conceitos (por exemplo, sistemas de software) e dependências entre
as features variáveis. Um feature model consiste em um diagrama composto de features
e alguma informação adicional, tais como descrições semânticas de cada feature, pontos
variáveis, prioridades e regras de dependência.
No contexto das linhas de produto de software, um feature model representa a
própria linha de produtos. Uma feature pode ser de um dos seguintes tipos:
 • Obrigatória: A feature tem de estar presente em todos os membros da linha de
produtos.
• Opcional: A feature pode ou não estar presente em um membro da linha de produ-
tos.
• Alternativa: É uma feature que é composta de um conjunto de features das quais
se escolhe uma ou mais, devendo-se indicar se é necessário escolher apenas uma
ou se se pode escolher mais que uma. Nestas features é necessário fazer a distinção
de alternativas OR, que permite mais do que uma feature, e XOR, que mostra a
exclusão mútua.

Uma feature obrigatória é representada por uma aresta terminada por um círculo
preenchido a preto. Uma feature opcional é representada por uma aresta terminada por um
círculo vazio. As features alternativas são representadas por arestas que estão 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] propõe colocar cardinalidade nas features para poder remover am-
biguidades e representar a informação mais facilmente, sendo as diferentes cardinalidades
assim definidas:

• 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 número arbitrário 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 possível representação para o modelo de features do

Sistema e-Shop [22].
 Neste modelo são features obrigatórias Catalog, Payment, GUI e Info, são fea-
tures 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 aplicação. 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 filha pode aparecer apenas em um produto se sua feature
superior aparecer. A feature raiz é parte de todos os produtos dentro da LPS. Adicional-
mente aos relacionamentos parental entre features, pode ocorrer também o que chamamos
de cross-tree entre features, que significa que uma feature pode estar relacionada a outra
só que não em uma relação de parentesco, podendo ser dos seguintes dois tipos:

• Requires. Se uma feature A requer a feature B, a inclusão de A em um produto

implica na inclusão também de B. No sistema de exemplo pagamento com cartão
de crédito deve implementar uma política de segurança alta.

• Excludes. Se a feature A exclui a feature B, ambas as features não podem fazer

parte do mesmo produto. No sistema de exemplo o produto que implementar uma
interface GUI mobile não deve incluir suporte a banners.

1.3.4. Configuration Knowledge

O feature model, por si só, apenas representa a modelagem do domínio, mas não repre-
senta o modo como os produtos deste domínio serão gerados a partir dos artefatos da linha
de produtos. O mapeamento entre o feature model e os artefatos de implementação é o
que se chama de Configuration Knowledge [12].
Os artefatos de implementação podem estar modelados direto no modelo que re-
presenta 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 não estão dentro do configuration knowledge, os artefatos de implemen-
tação encontram-se em um modelo que assume diferentes nomes, dependendo da ferra-
menta utilizada, tais como family model, component model, architecture model, etc.
O mapeamento existente no configuration knowledge é essencialmente um con-
junto de regras que definem que artefatos de implementação (classes, arquivos de recur-
sos, 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 disponíveis na loja) estaria representada no configuration knowledge
como uma regra que diz se a feature Catalog estiver selecionada em um produto, a classe
entraria nesse produto também, essencialmente uma relação de implica (feature implica
em artefato de implementação).
Por trás do processo de geração de produtos de uma linha de produtos de soft-
ware se encontra uma engine de resolução de expressões lógica, que verifica se todas as
restrições presentes no feature model foram respeitadas em cada instância, e, para cada
seleção de features, verifica que artefatos de implementação estarão habilitados na ins-
tância. Uma vez que todas as verificações tenham sido realizadas, a saída do processo de
geração de produtos vai ter como resultado, para cada produto, uma lista dos artefatos de
implementação habilitados no produto.
Dependendo da ferramenta utilizada, o usuário pode especificar diretamente na
ferramenta o que será feito com essa lista, como gerar um projeto individual na IDE
utilizada com uma cópia de cada artefato de implementação, ou invocar um sistema de
empacotamento dos produtos que geraria os executáveis finais, permitindo assim uma
maior customização do processo de geração.

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 três atividades essenciais e altamente interati-
vas que se misturam práticas de negócios e tecnologia. Em primeiro lugar, atividade de
Core Asset Development onde o objetivo não é criar o produto final 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 ati-
vos base já desenvolvidos anteriormente reusando-os. Finalmente Management Activity,
que inclui gestão técnica e organizacional [16]. A Figura 1.5 mostra esta tríade de ativida-
des essenciais. Cada círculo giratório representa uma das atividades essenciais. Todos os
três são ligados entre si e em movimento perpétuo, mostrando que todos os três são essen-
ciais e estão intimamente ligados, podendo ocorrer em qualquer ordem, e são 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 compõem a plataforma da linha de produto [16]. O objetivo desta
atividade é definir os aspectos comuns e a variabilidade da linha de produtos, e, portanto,
obter artefatos reutilizáveis para em seguida possuir uma capacidade de produção maior
[21]. A Figura 1.6 mostra o núcleo desta atividade juntamente com suas saídas e insumos
necessários.

Figura 1.6. Desenvolvimento de Ativos Base [17]

As setas rotatórias na Figura 1.6 sugerem que não há um momento certo de adici-
onar uma restrição ou novos padrões no desenvolvimento e estas entradas afetam direta-
mente as saídas no processo. Em alguns contextos os produtos existentes são a base para
os ativos base em outros estes podem ser desenvolvidos do zero para futuro reuso.
Ativos base incluem, mas não estão limitados à arquitetura e sua documentação,
especificações, componentes de software, ferramentas como geradores de componentes
ou aplicação, modelos de desempenho, cronogramas, orçamentos, planos de teste, casos
de teste, planos de trabalho e processo descrições [17].
Embora possa ser possível a criação de ativos base que podem ser utilizados em
todos os produtos sem quaisquer adaptações, em muitos casos, algumas adaptações são
necessárias para torná-los mais utilizáveis no contexto mais amplo de uma linha de pro-
dutos. Logo, mecanismos de variação dos principais ativos base utilizados ajudam a con-
trolar as adaptações necessárias e suportar as diferenças entre os produtos de software
[5]. Essas adaptações 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 são desenvolvidos a partir dos

ativos base, com base no plano de produção, para satisfazer as exigências da linha de
produtos de software. Os insumos essenciais da atividade de desenvolvimento de produto
são requisitos, escopo da linha de produtos, ativos base e o plano de produção [3].
De posse do plano de produção, que detalha como os ativos base serão 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 saídas e fatores contextuais.

Figura 1.7. Desenvolvimento de Produtos [17]

Como na Figura 1.5, as setas de rotação na Figura 1.7 indicam iterações entre as
partes envovidas. Por exemplo, a existência e a disponibilidade de um determinado pro-
duto pode assim afetar os requisitos de produtos subseqüentes. Como outro exemplo de
construção, um produto que tem em comunalidades previamente não reconhecidas em re-
lação a outro produto da linha vai criar a necessidade de para atualização dos ativos base e
fornecer uma base para explorar essa comunilidade em futuros produtos [17]. Além disso,
esta atividade tem a obrigação de dar feedback sobre quaisquer problemas ou deficiências
encontradas com os ativos base.

1.4.1.3. Atividade de Gestão

A atividade de Management desempenha um papel vital no sucesso da institucionalização

da linha dentro de uma organização porque fornece e coordena a sua infra-estrutura neces-
sária. Esta tarefa envolve atividades essenciais realizadas a nível técnico e organizacionais
para apoiar o ciclo de vida do processo [3].
A gestão supervisiona a construção dos ativos base e atividades de desenvolvi-
mento do produto, garantindo que os grupos que constroem os ativos base e os grupos que
constroem os produtos estão plenamente envolvidos nas atividades individuais, acompa-
nhando o processo definido para a linha de produtos acompanhando seu progresso [17].
Isto representa não apenas os aspectos técnicos mas também aspectos gerenciais e orga-
nizacionais.
O conjunto de ativos base e plano de como eles são usados para construir os pro-
dutos não nascem sem previamente estudar o ambiente, caracterizar o negócio, portanto
deve existir investimento organizacional. A gestão deve dirigir, controlar e garantir a plena
utilização dos ativos. Linhas de produtos de software está mais relacionado a práticas de
negócios do que práticas técnicas [17].
Embora as organizações sejam diferentes em termos da natureza de seus produtos,
de mercado ou missão, objetivos de negócio, estrutura organizacional, cultura e políticas,
as disciplinas de processo de software, e assim por diante, atividades essenciais aqui dis-
cutidas aplicam-se em qualquer situação, uma vez que representam o nível mais alto de
generalidade, que envolve os aspectos mais importantes sobre o desenvolvimento em LPS.
Em geral, as organizações realizam essa divisão de responsabilidades em uma
variedade de maneiras. Algumas organizações têm equipes dedicadas a cada função e
outros usam as mesmas pessoas para ambas. Depende da disponibilidade orçamentária,
estratégia entre outros aspectos. Na verdade, é válido mencionar que não há atividade
primária, isto é, em alguns contextos, os produtos já existentes são 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 gestão é a
atividade responsável pelo sucesso ou fracasso do produto final de uma linha de produtos.

1.4.2. Abordagens de Construção de Linha de Produtos de Software

Segundo Chen [10], existem três abordagens principais de desenvolvimento em linha de
produtos de software (ver Figura 1.8):

• Proativa: Com esta abordagem os ativos base são desenvolvidos primeiro para
futuro produtos. Aqui são considerados todos os produtos a serem gerados previa-
mente fazendo-se um planejamento inicial completo.

• Reativa: Nesta abordagem os ativos base já existem, bem como uma versão da linha
de produtos, o que acontece é a evolução desta linha realizando-se incrementos na
mesma à medida que novos requisitos aparecem.

• Extrativa: Com esta abordagem, inicialmente são analizados quais os produtos

já existentes e como eles são estruturados de modo a extrair as comunalidades e
variabilidades destes para então poder se derivar uma versão inicial da Linha de
Produtos.

Dependendo do grau de planejamento, a abordagem proativa pode ser classificada

em abordagem big bang e abordagem incrementa (ver Figura 1.9).
 Figura 1.8. Abordagens em LPS

Na estratégia big bang, LPS é adotada para os novos produtos de uma só vez,
uma mudança drástica. Primeiramente a engenharia de domínio é construída completa-
mente e a plataforma é modelada e desenvolvida. Quando os ativos base estão prontos a
engenharia de aplicação inicia e as aplicações são derivadas da plataforma [21].
Com abordagem incremental, os ativos base são gradualmente desenvolvidas para
suporte aos futuros produtos.
Já a abordagem reativa pode ser quebrada em três 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 não permite que os produtos individuais

estejam desatualizados em relação aos ativos base comuns a vários produtos, ou seja, a
plataforma deve manter sempre a integridade em relação aos produtos, exigindo que novas
características comuns sejam implementadas primeiro nos ativos base que irão compor os
produtos, em seguida, construindo os produtos.
Tanto o branch-and-unit quanto a abordagem bulk-integration permitem um desa-
linhamento temporário entre ativos base e os produtos individuais. A diferença entre estas
duas sub-abordagens está na quantidade de produtos que se espera ser lançado antes de
atualizar os ativos base.
A estratégia branch-and-unit exige que novas features comuns sejam reintegradas
nos ativos base imediatamente após o lançamento do novo produto, enquanto que bulk-
integration permite que novas features comuns serem reintegrados após o lançamento de
um grupo de produtos.
Estas abordagens não são mutuamente exclusivas. Por exemplo, uma linha de
produtos pode ser adotada por meio de um abordagem proativa e, em seguida, evoluir
através de uma abordagem reativa.

1.4.3. Ferramentas
Nesta seção 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 características descriti-
vas 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
significativamente o esforço de desenvolvimento.
O fmp apenas apresenta suporte à modelagem do domínio, através de feature mo-
dels. Ele não possui nenhuma funcionalidade de configuration knowledge, nem nada que
permita, dentro do próprio fmp, o mapeamento necessário entre features e artefatos da
linha de produtos para permitir a geração dos produtos.
Os modelos gerados pelo feature model são gravados no sistema como um arquivo
XML (do inglês Extensible Markup Language), o que pode permitir que geradores, uti-
lizando XSLT (do inglês 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.
 Figura 1.10. Interface do fmp

O fmp implementa modelagem de features baseada em cardinalidades [13], ou

seja, permite a definição de cardinalidades de feature e de grupo, atributos de feature,
referências e anotações definidas pelo usuário.
Cardinalidades de feature e grupo permitem que sejam especificados o número
mínimo e máximo 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.
Anotações definidas pelo usuário permitem que o usuário adicione novas propriedades
as features, além das básicas (nome, cardinalidade, valor), permitindo assim uma maior
customização do modelo.
Para suportar anotações definidas pelo usuário, o fmp permite que o usuário al-
tere o meta-modelo do feature model, permitindo, por exemplo, que toda feature tenha
um atributo chamado "quantidade"; ou qualquer coisa que o usuário 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 au-
tomatizar o processo de modelagem e configuração de artefatos reusáveis de software.
A ferramenta se apresenta como inovadora pela possibilidade de customização do meta-
modelo da família de produtos [9].
O XFeature tem suporte à modelagem do domínio, através de feature models e não
possui a funcionalidade de configuration knowledge, que permite o mapeamento neces-
sário entre features e artefatos da linha de produtos para permitir a geração dos produtos.
Originalmente o XFeature foi desenvolvido visando o seu uso em aplicações espa-
ciais (sistemas de controle embutidos para naves espaciais, por exemplo), porém, não há
nenhuma restrição na maneira que foi desenvolvido que não permita o seu uso em outros
contextos.
Em relação à implementação, o XFeature foi implementado baseado na versão 3.3
do Eclipse, ao contrário do fmp, ele não utilizou o EMF para a definição 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 transformações XSL. Scripts Ant
são utilizados para a verificação e geração de arquivos de configuração da aplicação, tais
como os que customizam o editor dos modelos.
O processo de criação de modelos no XFeature é consideravelmente mais com-
plicado do que nas outras ferramentas. Primeiramente se define qual será a configuração
utilizada (FD, FMP, SimplifiedICSR ou ICSR). Em seguida, é criado o que o XFeature
chama de family model, que é o meta-modelo do domínio. Após a validação do family
model sob a configuração utilizada, o usuário deve clicar em um botão que gera dois
meta-modelos: o de aplicação e o de display. O meta-modelo de aplicação é o que será
utilizado como configuração dos modelos que vão conter as instâncias da linha de pro-
duto, e o meta-modelo de display define quais os elementos visuais que aparecerão no
editor. Apesar de ser mais complicado, o XFeature permite que o usuário tenha mais con-
trole sobre como são criados os feature models, uma vez que o usuário não fica preso à
única configuração presente nas outras aplicações.
Uma vez criados os modelos das instâncias da linha de produtos, eles podem ser
validados contra seu meta-modelo, que foi definido pelo usuário anteriormente. Quando
os modelos estiverem validados, eles podem ser utilizados como entrada pra outras ferra-
mentas que possuam a parte de configuration knowledge para gerar os produtos finais.
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 obrigatórias, em caixas ama-
relas, assim como o editor de propriedades de features. O XFeature também permite a
definição de restrições globais sobre o feature model. O usuário cria um modelo de restri-
ções, que passa pelo global constraints compiler, que vai gerar um conjunto de arquivos
XSL que permitem a verificação das restrições.
 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-Universität 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 implan-
tação de linhas de produtos e famílias de software. O pure::variants provê suporte no
desenvolvimento durante as atividades de análise, modelagem, implementação e implan-
tação.
O pure::variants apresenta suporte à modelagem do domínio, através de feature
models e possui a funcionalidade de configuration knowledge, que permite o mapeamento
necessário entre features e artefatos da linha de produtos para permitir a geração dos
produtos.
O pure::variants é uma ferramenta comercial, logo, requer licença para uso. Ela
possui uma versão gratuita para testes, que não pode ser usada comercialmente e possui
restrições no tamanho dos modelos. É sabido que o custo do pure::variants varia muito
dependendo da quantidade de licenças adquiridas. Mas sabe-se que normalmente o preço
de uma licença para uma máquina na versão developer custa em torno de 200 euros por
mês.
O custo também varia dependendo de qual versão da ferramenta será utilizada, a
Professional ou a Enterprise. A versão Enterprise possui controle de versões integrado
(utilizando CVS, por exemplo), permite que o usuário desfaça modificações no modelo
mesmo após ele ter sido fechado (não apenas quando ele está aberto, como ocorre na
Professional), colaboração on-line e gerenciamento de modelos centralizado.
O pure::variants utiliza uma notação baseada em FODA. Ele possui 3(três) tipos
de modelos diferentes: o feature model: onde são definidas as características comuns e
variabilidades da linha de produtos, o family model: a parte do configuration knowledge
onde se encontram os componentes que compõem os artefatos da linha de produtos, e o
variant model: que é o modelo que define uma instância da linha de produtos.
A divisão dos 3 modelos é clara e consideravelmente mais intuitiva do que os
inúmeros meta-modelos e modelos que o XFeature define, e a definição das instâncias em
arquivos separados facilita a organização da linha. Além disso, as mudanças no feature
model são sincronizadas automaticamente com os variant models.
Uma vez criados os variant models, eles podem ser validados para determinar
se cumprem as restrições do feature model, que foi definido pelo usuário anteriormente.
Uma vez que estes modelos estejam validados, eles podem ser usados juntamente com
o family model e o feature model para a geração dos produtos da linha, utilizando os
recursos de geração do pure::variants.
A Figura 1.12 apresenta o Family Model, onde encontramos componentes (as
caixas marrons), restrições (as expressões após a placa com exclamação), 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 Edição do Family Model do pure::variants

1.5. Conclusões
Ao longo deste capítulo foram analizados diversos conceitos sobre LPS, propiciando ao
leitor uma visão geral sobre o assunto. Além disto foram mostradas características sobre
a notação F.O.D.A para construção de feature models bem como o que vem a ser uma
Configuration Knowledge, dentre outros conceitos e princípios.
Foi visto que as organizações podem obter benefícios de negócio consideráveis
em termos de redução de custos, redução do tempo de colocação no mercado, aumento
na qualidade do produto, etc, aplicando desenvolvimento de linhas de produto. Há, po-
rém, riscos e custos associados à adopção das empresas para esta adoção que devem ser
avaliados antes de embarcar em uma iniciativa de reutilização deste tipo.
Organizações têm colocado projetos ad hoc em "stand by"a fim de deixar livre
recursos para construir ativos base de uma LPS. Isto implica em grandes custos, no etando
existem muitas experiências bem sucedidas deste tipo de empreendimento.
Portanto qualquer organização que desenvolve produtos como sistemas simples,
que tem bons conhecimentos do domínio do negócio e um nível razoavelmente elevado de
maturidade do processo, deve, pelo menos, fazer um estudo de viabilidade para observar
se o desenvolvimento de uma LPS pode ser benéfica para eles.

Referências
[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 Soft-
ware. Escola Politecnica de Pernambuco. Departamento de Sistemas e Computacao.
http://dsc.upe.br/ tcc/20081/RogeriomonografiaFinal.pdf Acessado em 14 de outu-
bro 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:89–91, 94, 2010.
[5] Felix Bachmann and Paul C Clements. Variability in software product lines. Soft-
ware 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 Stef-
fen 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 mo-
delling. Software Reuse Methods Techniques and Tools, pages 101–114, 2004.

[10] Y Chen, G C Gannod, and J S Collofello. A software product line process simulator.
Software Process: Improvement and Practice, 11(4):385–409, 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 configuration 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:24–27, 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, Günter Böckle, 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 gene-
ration on the analyses of feature models: A metamorphic testing approach. pages
35 –44, april 2010.

[23] Arie van Deursen and Paul Klint. Domain-specific language design requires feature
descriptions. Journal of Computing and Information Technology, 10, 2001.

View publication stats