A abordagem de linha de produto de software tem como objetivo principal promover a geração de produtos específicos com base na reutilização de uma infra-estrutura central. Uma linha de produto representa um conjunto de sistemas que compartilham características comuns e gerenciáveis que satisfazem as necessidades de um segmento particular do mercado ou de uma missão. Esse conjunto de sistemas é também chamado de família de produtos. Os membros da família são produtos específicos desenvolvidos de maneira sistemática a partir de um conjunto comum de artefatos da linha de produto.

1. Implementing Product Line Variabilities
Ailton Felix de L. Filho :: Michel Alves dos Santos ∗
Outubro de 2012
Conteúdo
1 Introdução 1
2 Requisitos de Apóio à Implementação 2
3 Quadro para Comparação de Abordagens de
Programação 2
3.1 Exemplos . . . . . . . . . . . . . . . . . . . 3
4 Avaliação 3
5 Conclusões 3
Referências 4
1 Introdução
A abordagem de linha de produto de software tem
como objetivo principal promover a geração de pro-
dutos específicos com base na reutilização de uma
infra-estrutura central.
Uma linha de produto representa um conjunto de
sistemas que compartilham características comuns
e gerenciáveis que satisfazem as necessidades de um
segmento particular do mercado ou de uma missão.
Esse conjunto de sistemas é também chamado de
família de produtos. Os membros da família são
produtos específicos desenvolvidos de maneira siste-
mática a partir de um conjunto comum de artefatos
da linha de produto.
O SEI (Software Engineering Institute), através
da iniciativa PLP (Product Line Practice), estabe-
leceu as atividades essenciais de uma abordagem de
linha de produto. Essas atividades, como podem ser
vistas na Figura 1, são o Desenvolvimento do Núcleo
de Artefatos, também conhecida como Engenharia
de Domínio, o Desenvolvimento do Produto, tam-
bém conhecida como Engenharia de Aplicação, e o
Gerenciamento da Linha de Produto [Jun05].
Uma infra-estrutura de linha de produto de soft-
ware cobre vários sistemas, isto devido ao número
de membros que uma linha de produto possui.
Para mostrar uma linha de produto, os assets (re-
cursos) de um software têm de cobrir todos os ele-
∗Bacharelandos em Ciência da Computação, Univer-
sidade Federal do Estado de Alagoas (UFAL). E-mail:
{afdlf2, michel.mas}@gmail.com. Disciplina: Linha de
Produto de Software. Docente Responsável: Arturo.
Figura 1: Atividades essenciais de linha de pro-
duto de software. Os três círculos indicam que
as atividades de uma linha de produto são alta-
mente interligadas e iterativas.
mentos da família do produto de onde o mesmo foi
construído e suas correspondentes regras de compo-
sição.
O artigo aborda a questão de manipulação de va-
riabilidade de linha de produto (ver [WEI99]) em
nível de código. Para esse fim várias abordagens de
implementação são examinadas com respeito ao uso
das mesmas em um contexto de linha de software.
A proposta do trabalho não é transmitir mais pre-
ocupação em tecnologias, mas somente informar so-
bre as possibilidades de seu uso para manipular va-
riabilidades de código em linha de produto. É dei-
xado claro também que o conjunto de abordagens
apresentado no trabalho não é completo.
Em [Cop95] um método de design que leva vanta-
gem do popular apóio a linguagem de programação
para múltiplos paradigmas é apresentado. O livro
mantém um foco nos problemas relacionados a com-
preensão de comunalidades e variabilidades, o que o
torna de interesse para a engenharia de linha de pro-
duto.
1

2. 2 Requisitos de Apóio à Im-
plementação
As variabilidades podem ser inicialmente identifi-
cadas por meio do conceito de feature [VAN01]. Este
conceito teve origem na engenharia de domínio. Fe-
ature pode ser definida como uma característica de
um sistema que é relevante e visível para o usuário
final [KAN].
Toda variabilidade encontrada em um contexto
de linha de software pode ser conectada com uma
feature correspondente. A relação entre feature e
variabilidade é de 1 : N, pois a implementação da
mesma geralmente se encontra espalhada pelos ar-
quivos fontes e módulos.
Uma visão global dos tipos de features e o critério
para inclusão da mesma em uma instância de linha
de produto pode ser vista na Tabela 1.
Tipo de Feature Significado
Obrigatória A feature deve ser sempre incluída.
Opcional A feature é um complemento independente
que pode ser incluída ou não.
Alternativo A feature substitui uma outra feature quando
incluída.
Mutualmente Inclusiva
Para que uma feature seja incluída, outras
features específicas devem ser também
incluídas e vice-versa.
Mutualmente Exclusivas
Para que uma feature seja incluída, outras
features específicas não devem ser incluídas e
vice-versa.
Tabela 1: Tipos de features.
Variablidades podem ser principalmente classifi-
cadas como positivas e negativas. A Tabela 2 mostra
como as variablidades podem ser categorizadas.
Tipo de Variabilidade Significado
Positiva Quando adicionam funcionalidades.
Negativa Quando removem funcionalidade.
Opcional Quando um código é incluído.
Alternativo Quando um código é substituído.
Funcional Quando a funcionalidade muda.
Plataforma / Ambiente Quando a plataforma ou ambiente mudam.
Tabela 2: Tipos de features.
Um fator importante no gerenciamento de varia-
bilidade é o seu tempo de resolução. Ele indica em
qual momento uma ou mais variantes serão associa-
das a um determinado ponto de variação [VAN00].
O tempo de resolução de variabilidade pode ser
classificado como [ANA01]:
• Tempo de compilação;
• Tempo de ligação;
• Tempo de execução;
• Tempos de atualização.
O tempo de resolução de variabilidade restringe
a escolha de mecanismos de implementação de va-
riabilidade. Por exemplo, se uma variabilidade
é resolvida em tempo de execução, não se pode
implementá-la com um mecanismo que é definido
em tempo de compilação [FRI02].
Os principais parâmetros de variação são as inter-
faces e as implementações correspondentes. A inici-
alização de módulo também é considerada como um
possível parâmetro de variação.
Uma técnica de implementação claramente conta
com a escolha da linguagem de programação. A
decisão de qual linguagem usar é tipicamente resol-
vida sobre uma instânciação do produto. Portanto
a criação e descobrimento de uma aquitetura de re-
ferência para uma linha de produto como uma base
para instanciação de membros é uma das atividades
fundamentais dessa área.
3 Quadro para Comparação
de Abordagens de Progra-
mação
No artigo [MA01] (ver também [ANA01]), várias
abordagens para variabilidade de codificação são
apresentadas, onde o mesmo descreve as caracte-
rísticas de cada um delas, onde também, no mesmo
artigo, é possível encontrar uma matriz que faz com-
parações entre estas abordagens. São elas:
1. Agregação / Delegação: permite que obje-
tos deleguem funcionalidades;
2. Herança: adiciona funções básicas às super-
classes e funções especializadas às subclasses;
3. Parametrização: representa software reutili-
zável como uma biblioteca de componentes pa-
rametrizados;
4. Sobrecarga: esta técnica utiliza o mesmo
nome de um elemento para operar de manei-
ras diferentes;
5. Propriedades do Delphi: propriedades as-
sociadas a ações específicas como leitura ou
atualização de dados;
6. Carga Dinâmica de Classe: todas as classes
são carregadas na memória assim que estas são
necessárias;
7. Bibliotecas Estáticas: contém um conjunto
de funções exeternas que podem ser linkadas
em um aplicação depois da mesma ter sido
compilada;
2

3. 8. Bibliotecas de Ligação Dinâminca: são
carregadas quando necessárias em uma aplica-
ção em tempo de execução;
9. Compilação Condicional: possibilita o con-
trole sobre os segmentos de código a serem in-
cluídos ou excluídos da compilação de um pro-
grama;
10. Frames: reuso hierárquico de entidades de
montagem de software;
11. Reflexão: é a habilidade de um programa ma-
nipular, na forma de dados, algo que representa
o estado de um programa durante sua própria
execução;
12. Programação Orientada a Aspecto: téc-
nica desenvolvida pela Xerox PARC (http:
//www.parc.com/);
13. Padrões de Projeto: muitos dos padrões de
projeto podem variar e fornecer soluções para
o gerenciamento de variabilidade.
3.1 Exemplos
Um dos exemplos das técnicas apresentadas é o
uso do Padrão de Projeto Builder. O Builder é um
exemplo de padrão de criação que pode ser usado
para carregar código variante em tempo de execu-
ção. Este padrão é adequado quando a lógica da
construção de objetos complexos deve ser separada
do usuário desses objetos e quando essa lógica deve
facilitar a construção de variações. A estrutura do
padrão pode ser vista na Figura 2.
Figura 2: Padrão Builder.
Product representa o objeto complexo a ser cons-
truído. O administrador coordena a construção do
produto pela chamada do objeto ConcreteBuilder.
Esse objeto implementa a mesma interface para cri-
ação de partes que é definida na classe abstrata Buil-
der. Porém, cada ConcreteBuilder cria partes dife-
rentes.
4 Avaliação
Qualquer decisão tomada durante o processo de
desenvolvimento do software pode comprometer a
sua qualidade final. Para se produzir software com
alta qualidade, é necessário investir em qualidade
em todos os pontos do processo.
Qualidade de software é um processo sistemático
que focaliza as etapas e artefatos produzidos com o
objetivo de garantir a conformidade de processos e
produtos, prevenindo e eliminando defeitos [Bar02].
Para avaliação, um critério de técnica de imple-
mentação deve ser definido e uma classificação deve
ser feita para expressar o grau de satisfação.
Escopo, flexibilidade, eficiência, compatilidade
binária são exemplos de qualidades fundamentais
que devem ser identificados para comparar e ava-
liar técnicas de implementação de linha de produto.
5 Conclusões
A gestão sistemática da variabilidade em nível de
código é um campo bastante imaturo. É chegada a
conclusão de que mais trabalhos nessa área devem
ser feitos.
Outra conclusão que se é chegada pelo trabalho
[MA01] é de que diferentes abordagens foram neces-
sárias para dar suporte a diferentes problemas. Isso
significa dizer que técnicas precisam ser mapeadas
para problemas conhecidos. Além disso, a combina-
ção de técnicas disponíveis é algo que não pode ser
evitado.
Referências
[ANA01] ANASTASOPOULOS, M. Implementing
product line variabilities, volume 26. ACM
SIGSOFT Software Engineering Notes,
May 2001.
[Bar02] Alexandre Bartié. Garantia de Qualidade
de Software. 2002.
[Cop95] James Coplien. Multi-Paradigm Design
for C++. 1995.
[FRI02] FRITSCH, C.; LEHN, A.; STROHM,
T. Evaluating variability implementation
mechanisms. In In: INTERNATIONAL
WORKSHOP ON PRODUCT LINE EN-
GINEERING, 2., 2002, Seattle. Procee-
dings, pages 59–64, 2002.
[Jun05] Edson A. Oliveira Junior. Um processo de
gerenciamento de variabilidade para linha
de produto de software. Departamento
de Informática, Universidade Estadual de
Maringá, 2005.
[KAN] KANG, K. Feature-oriented domain
analysis (foda) - feasibility study. Tech-
nical report, Technical Report CMU/SEI-
90-TR-21, SEI/CMU, Pittsburgh.
3

4. [MA01] Cristina G. Michalis A. Implementing pro-
duct line variabilities. Fraunhofer Insti-
tute for Experimental Software Enginee-
ring and Centre for Software Reliability
Department of Computing Science Uni-
versity of Newcastle, 2001.
[VAN00] VAN GURP, J.; BOSCH, J. Managing va-
riability in software product lines. In In:
THE WORKING IEEE/IFIP CONFE-
RENCE ON SOFTWARE ARCHITEC-
TURE, 2000, Amsterdam. Proceedings,
2000.
[VAN01] VAN GURP, J.; BOSCH, J. On the no-
tion of variability in software product li-
nes. In In: THE WORKING IEEE/IFIP
CONFERENCE ON SOFTWARE AR-
CHITECTURE, 2001, Amsterdam. Pro-
ceedings, 2001.
[WEI99] WEISS. D, CHI TAU, R. L. Software
product-line engineering: a family-based
software development process. 1999.
4