DESENVOLVIMENTO

ORIENTADO
A REÚSO DE
SOFTWARE
Introdução à
linha de produção
de software
Juliana Padilha

OBJETIVOS DE APRENDIZAGEM

> Conceituar linha de produção de software.

> Diferenciar os frameworks das linhas de produção de software.
> Exemplificar a arquitetura de uma linha de produção de software.

Introdução
A abordagem de reúso de software era considerada incomum até por volta do
ano 2000. A crescente demanda por entrega de software com prazos cada vez
mais exíguos, a redução de custos de produção e de manutenção e a exigência
de alta qualidade de software contribuíram para que o reúso sistemático de
software se tornasse uma prática comum. Portanto, ao longo dos anos várias
abordagens de reutilização de software foram propostas, incluindo: paradigmas
de orientação a objetos (polimorfismo, encapsulamento e herança), padrões de
projeto e de arquitetura, uso de componentes, frameworks de aplicações, entre
outras. Entretanto, como essas abordagens tradicionais não foram totalmente
satisfatórias, surgiu a necessidade de propor uma nova abordagem, conhecida
como linha de produtos de software (software product line — SPL).
2 Introdução à linha de produção de software

A ideia básica do desenvolvimento baseando em SPL é suportar o reúso de

software em grande escala. Para isso, conhecimentos da área de negócios são
recrutados para separar as partes semelhantes de um conjunto de produtos
relacionados que atendem a um determinado segmento de mercado. Desse
modo, torna-se possível desenvolver software de forma mais eficiente em
termos de custo, qualidade e tempo.
Neste capítulo, você verá a importância e os principais conceitos teóricos
da SPL, como o modelo de características (features model), a variabilidade,
aplicação-base (baseline) e as diferenças entre arquitetura de software tra-
dicional e a arquitetura de uma SPL.

Linha de produção de software

O reúso de software, como o próprio nome já diz, trata-se da reutilização de
algo já construído, com o objetivo de agilizar o desenvolvimento de software
e também reduzir custos. É importante salientar que o reúso não diz respeito
apenas à reutilização dos componentes, pois também engloba todo o plane-
jamento para que isso ocorra da forma mais eficiente possível.
De acordo com Sommerville (2019), existem diversas abordagens que
auxiliam o reúso de software, incluindo: bibliotecas, padrões de projeto e de
arquitetura, frameworks de aplicação, sistemas de sistemas, integração de
sistemas de aplicação (COTS), sistemas Enterprise Resource Planning (ERP),
sistemas de aplicação configuráveis, empacotamento de sistemas legados,
engenharia baseada em componentes, engenharia dirigida por modelos,
sistemas orientados a serviços, engenharia de software orientada a aspectos,
gerador de programas e SPL.
Uma das abordagens mais promissoras para o reúso de software é a SPL,
também denominada família de produtos. De acordo com Sommerville (2019, p.
413) a SPL é definida como “[…] um conjunto de aplicações com uma arquitetura
comum e componentes compartilhados, em que cada aplicação se especializa
em refletir requisitos específicos do cliente”. Em suma, pode-se definir SPL
como uma técnica para construir softwares baseados em componentes que
podem ser reutilizados para construir outros softwares sem muito esforço.
Afinal, um software é produzido por meio da união de vários componentes
prontos que são ligados e, em conjunto, geram o resultado esperado. A Figura 1,
apresentada a seguir, ilustra a ideia da abordagem de SPL.
 Introdução à linha de produção de software 3

Figura 1. Exemplificação genérica de uma SPL.

Conforme se observa na Figura 1, tomando como base vários elemen-

tos distintos (ilustrados, nesse caso, como diferentes figuras geométricas),
é possível reusá-los para criar novos produtos de software e, se for necessário,
também é possível incluir novos elementos (o Produto 2, por exemplo, teve
a inclusão da figura geométrica losango).
Segundo Ferguson (2019), uma pesquisa realizada pelo Software Engine-
ering Institute (SEI) constatou que existem inúmeros benefícios para o uso
da SPL, com destaque para: produção de software em larga escala, redução
do tempo de lançamento do produto de software no mercado, melhoria
na qualidade do produto, aumento da satisfação do cliente, capacidade
de personalizar ou configurar rapidamente o produto de software e até a
capacidade de amparar um crescimento sem precedentes. No entanto, a SPL
também apresenta algumas desvantagens, pois não se encaixa nos planos
de desenvolvimento de todas as organizações, sobretudo naquelas inseridas
em mercados que passam por mudanças frequentes e cujos produtos estão
cada vez mais diversificados. Há também os produtos que se inserem em
domínios com futuros incertos e, portanto, representam um grande risco para
o sucesso de uma organização de SPL (KAKOLA; DUEÑAS, 2006).
No próximo tópico, examinaremos as diferenças entre duas formas de
reúso de software: a tradicional e a de SPL.

Ao contrário do desenvolvimento de um produto de forma comum,

isto é, um por vez, uma organização que adota uma linha de produto
precisa se antecipar às mudanças que ocorrerão durante todo o tempo de vida
útil do produto de software (KAKOLA; DUEÑAS, 2006).
4 Introdução à linha de produção de software

Diferenças entre reúso tradicional e SPL

O desenvolvimento de uma SPL abrange a reutilização de software e, a prin-
cípio, pode parecer que são semelhantes. Entretanto, isso é uma falácia.
O desenvolvimento da SPL é muito mais elaborado que uma simples reutili-
zação de código da forma tradicional (ERIKSSON, 2003).
No reúso tradicional, a reutilização do software é feita por meio de re-
positórios que armazenam o software desenvolvido, como as bibliotecas de
componentes, para que possam ser reutilizados. No entanto, esses reposi-
tórios não são organizados para facilitar o reúso em larga escala, pois no
reúso tradicional é utilizada a metodologia clone and own (C&O, ou “clonar e
se adonar”), em que um produto similar ao que será desenvolvido é localizado
no repositório e clonado. Nesse caso, tudo que for possível reaproveitar
desse software será reutilizado, modificado e, se for o caso, suplementado
pelo que seja necessário para desenvolver um novo produto de software.
Segundo Ghabach (2018), o uso da abordagem clone and own pode ocorrer
em diferentes estágios de desenvolvimento de software, embora seja mais
comum no nível de código.
Em contraposição, no reúso em linhas de produtos, não somente o código é
o foco do reúso, mas também os requisitos e toda a documentação associada
ao software. Segundo Kakola e Dueñas (2006), esse nível estratégico de reu-
tilização resulta em economia de tempo e de custo de produção. Entretanto,
só ocorrerá se a organização tiver disciplina nas etapas de planejamento,
processo e execução. Desse modo, o código nos repositórios é utilizado por
meio da instanciação, pois já estão preparados para a variabilidade (partes
variáveis), que é uma característica importante dentro da SPL.
A variabilidade é definida como a capacidade de alterar ou adaptar um
sistema (PEREIRA; FIGUEIREDO; COSTA, 2015). Exemplos de variabilidade incluem
o tipo de sistema operacional a ser adotado e as funcionalidades presentes
ou ausentes nos produtos da linha.
Quanto maior a variabilidade de um sistema, mais fácil será torná-lo apto
a determinados tipos de alterações, desde que sempre sejam bem planejadas.
Como exemplo, considere a comparação da produção de software com a pro-
 Introdução à linha de produção de software 5

dução de veículos: um carro possui diversos componentes, como motor, capô,

suspensão, entre outros, que podem ser reaproveitados/reutilizados entre
modelos distintos. A forma como os componentes são projetados garantirá
um maior ou menor reaproveitamento entre os modelos de veículos. Além
disso, esses componentes também poderão apresentar opções de variabi-
lidade, cor, resistência de materiais, entre outras configurações (PEREIRA;
FIGUEIREDO; COSTA, 2015).
Um dos principais mecanismos para modelar a variabilidade é o modelo
de características (feature model). Primeiramente, é preciso apresentar e
compreender o conceito de feature, definida como um atributo, isto é, uma
característica do sistema que é visível ao usuário final, ou seja, um contexto
do software com que o usuário final tem contato direto. As features permitem
o agrupamento de um conjunto de requisitos relacionados, em que a relação
entre as elas e os requisitos ocorre de n para n, ou seja, de muitos para muitos
(PEREIRA; FIGUEIREDO; COSTA, 2015).
Já um modelo de características trata-se de uma representação compacta
de todos os produtos, referentes aos recursos utilizados durante todo o
processo de criação da SPL, como definição de arquitetura e/ou partes do
código. A representação visual desse modelo é baseada na ideia de uma
árvore, em que a raiz representa um conceito e as folhas as suas features
(PEREIRA; FIGUEIREDO; COSTA, 2015).
Essa representação é utilizada para facilitar o entendimento dos requisitos
reportados pelos usuários finais aos desenvolvedores. Assim, os usuários
finais podem apontar novas necessidades ou ausência de certas features. Em
suma, o feature model é aplicado para representar em alto nível as principais
características semelhantes e suas variáveis (mutáveis) numa SPL.
A representação gráfica de um modelo de características é feita por meio
da notação Feature Oriented Domain Analysis. Trata-se de uma notação
específica para representar graficamente as partes comuns e variáveis dos
produtos de software que compõem uma família de produtos (KANG; LEE;
DONOHOE, 2002).
A Figura 2 apresenta um modelo de características para um telefone mó-
vel que ajudará na compreensão dos termos da notação Feature Oriented
Domain Analysis.
6 Introdução à linha de produção de software

Figura 2. Exemplificação de um modelo de características.

Fonte: Adaptada de Ghabach (2018).

Nesse modelo de features, as relações e restrições respeitam os critérios

e notações a seguir (GHABACH, 2018).

„ Raiz: recurso que representa o conceito do modelo de características

que está sendo criado. Nesse exemplo, smartphone é a raiz, que possui
as seguintes características (recursos-filhos): ligações, GPS, tela e mídia.
„ Feature obrigatória: serve para ilustrar as relações obrigatórias entre os
recurso-pai e recursos-filhos. Nesse exemplo, observa-se que todos os
smartphones deverão ter as seguintes funcionalidades: ligações e tela.
„ Feature opcional: utilizada para ilustrar um relacionamento opcional
entre um recurso-pai e um recurso-filho. Nesse exemplo, observa-se
que todos os smartphones podem oferecer ou não os recursos de GPS e
mídia. Como se trata de funcionalidade opcional, nem todo smartphone
que possui GPS obrigatoriamente terá a funcionalidade de mídia.
„ Feature alternativa XOR: utilizada para demonstrar uma relação al-
ternativa entre um grupo de recursos-filhos e um recurso-pai. Logo,
apenas um recurso do grupo poderá ser selecionado quando o recurso-
-pai está presente. No exemplo da Figura 2, o smartphone poderá ter
apenas uma tela, que poderá ser básica, colorida ou de alta resolução.
 Introdução à linha de produção de software 7

„ Feature alternativa OR: utilizada para demonstrar uma relação al-

ternativa entre um grupo de recursos-filhos e um recurso-pai.
Em contraposição à feature alternativa XOR, na OR poderá ser selecio-
nado um ou mais recursos do grupo no qual o recurso-pai está presente.
Então, nesse exemplo, um smartphone que possui o recurso-pai mídia
poderá ter câmera, MP3, ou então os dois recursos.
„ Restrições: Requires refere-se a um relacionamento direcionado de
um recurso A para um recurso B, isto é, cada produto que contém a
funcionalidade 1 deve conter a funcionalidade 2. No exemplo da Figura 2,
o smartphone que contém uma câmera também deverá ter uma tela de
alta resolução. Já em Excludes ocorre o inverso: há uma exclusão entre
dois recursos A e B. Isto é, cada produto que contém a funcionalidade 1
não pode conter a funcionalidade 2 — devendo apresentar uma outra.
Nesse exemplo, é possível observar que nenhum smartphone possui
GPS se sua tela for a básica.

Conforme se observa pela Figura 2, o modelo de características é bastante

útil para compreender os recursos presentes e selecionar apenas aqueles
necessários para o desenvolvimento do novo produto de software. A repre-
sentação visual torna mais rápida e fácil a compreensão até para pessoas que
não são desenvolvedoras, como os usuários finais. Na próxima seção, serão
apresentadas as principais diferenças entre os frameworks de aplicação e as
linhas de produtos, pois muitas vezes o conceito de framework pode parecer
confuso em relação às outras formas de reúso de software, como a SPL.

Diferenças entre frameworks e SPL

De acordo como Sommerville (2019), os primeiros entusiastas do desenvol-
vimento orientado a objetos sinalizaram que seu uso poderia trazer muitos
benefícios, visto que poderiam reusar os objetos em diferentes softwares.
Entretanto, com o passar dos anos essa recomendação se mostrou falsa, pois
os objetos são muitas vezes granulares e muito particularizados para um
determinado software e, normalmente, acaba-se consumindo mais tempo para
entendê-los e adaptá-los para reaproveitamento do que para implementá-
-los do zero.
8 Introdução à linha de produção de software

A experiência com a abordagem de reúso de software comprovou que é

mais acertado utilizar essa abordagem em um processo de desenvolvimento
orientado a objetos por meio de abstrações mais genéricas, como frameworks.
Segundo os autores Schmidt, Gokhale e Natarajan (2004), um framework é
definido como um conjunto integrado de artefatos de software (como classes,
objetos e componentes) que colaboram para proporcionar uma arquitetura
reusável para uma família de aplicações relacionadas.
Os frameworks são considerados uma abordagem muito eficiente para
o reúso de software, visto que os softwares desenvolvidos por meio deles
podem vir a se tornar a base para um futuro reúso, inclusive por meio da
metodologia de SPL. Como já mencionado, as linhas de produtos são derivadas
de softwares já existentes, isto é, uma determinada organização desenvolve
um software e, se posteriormente for necessária a criação de um sistema
semelhante, basta reusar o código do software que já foi desenvolvido para
criar o novo. Entretanto, a evolução contínua da estrutura do software poderá
ser corrompida e, consequentemente, proporcionar dados a essa estrutura
à medida que novas instâncias são criadas/inseridas. Portanto, para evitar
esse problema, é recomendado que seja projetada uma linha de produtos
genérica (SOMMERVILLE, 2019).
Uma linha de produtos genérica é criada após a identificação das fun-
cionalidades comuns nas instâncias de produto, para assim desenvolver
uma aplicação-base (baseline), também frequentemente denominada pelo
termo em inglês core assets. De acordo com Ghabach (2018) core assets são
os artefatos e recursos reutilizáveis que formam a base da SPL. Geralmente,
incluem a arquitetura, os componentes reutilizáveis, os modelos de domínio,
as declarações de requisitos de software, a documentação, as especificações,
cronogramas, orçamentos, planos e casos de teste e também as descrições
de processos. É importante ressaltar que normalmente são incluídos os
elementos descritos anteriormente, mas não estão limitados a apenas esses
(GHABACH, 2018).
O desenvolvimento de uma aplicação-base, ou seja, de core assets, é uma
atividade em que são selecionados os elementos necessários para a derivação
de novos produtos de software. Essa atividade simplifica o reúso e a recon-
figuração do software (SOMMERVILLE, 2019), pois é nela que ocorre a análise
das restrições do produto e da produção, a observação das semelhanças e
variações e até o processo a ser utilizado para derivar os novos produtos de
software (GHABACH, 2018).
 Introdução à linha de produção de software 9

Diante do exposto, é possível observar que tanto os frameworks de apli-

cação quanto as SPLs são bem semelhantes. Segundo Sommerville (2019,
p. 418), ambas abordagens “[…] apoiam arquitetura e componentes comuns
e requerem novo desenvolvimento para criar uma versão específica de um
sistema”. No entanto, existem algumas diferenças entre essas abordagens,
que são descritas a seguir (SOMMERVILLE, 2019).

„ A implementação dos frameworks é fundamentada em características de

orientação a objetos, como herança, polimorfismo e encapsulamento.
Geralmente, seu código não é modificado, mas quando há possibilidade,
as modificações são limitadas a cada tipo de framework. Já uma SPL
não é necessariamente criada por meio da orientação a objetos. Ao
contrário do que ocorre nos frameworks, não há uma limitação em
relação a alterações, exclusão, reescrita dos componentes (código).
„ Grande parte dos frameworks fornecem suporte geral, ao invés de um
suporte específico para um determinado domínio, como frameworks
específicos para a criação de aplicações web. Já uma SPL abrange
informações detalhadas do domínio e da plataforma, como aplicações
para o gerenciamento de veículos de emergência. Isso ocorre porque
as linhas de produtos são constituídas por uma família de aplicações
relacionadas; assim, quando uma nova aplicação é projetada, o ponto
de início geralmente é o membro mais próximo da família de aplicações
e não a aplicação mais genérica.
„ Geralmente, os frameworks não possuem componentes que permitam
a interação com o hardware. Já as SPLs têm suporte para a interface
com hardwares, como para uma família de impressoras.

Tomando como base as diferenças entre frameworks e linhas de produtos

elencadas anteriormente, conclui-se que é possível utilizar/estender um
framework para a criação de uma base de linha de produtos, desde que te-
nham componentes específicos do domínio da aplicação. Na próxima seção,
serão descritas as diferenças entre a arquitetura de um software tradicional
e a arquitetura de um software que adota a abordagem de SPL. Basicamente,
a diferença entre elas está na permissão do conjunto de variações.
10 Introdução à linha de produção de software

Arquitetura de uma linha de produção

de software
De acordo com Zwinkau (2019), a arquitetura de um sistema de software é
definida como as estruturas fundamentais de um sistema, em que cada es-
trutura inclui os elementos do software, as propriedades desses elementos
e as relações entre eles. Em resumo, a arquitetura de um software pode ser
definida simplesmente como a organização de um software. É por isso que ela
deve ser o primeiro artefato de um projeto de desenvolvimento de software.
A arquitetura de software é bastante efetiva para o entendimento dos
componentes do produto de software. Como é ela quem determina a estrutura
do software, também facilita a compreensão da equipe de desenvolvimento.
É por isso que a arquitetura do software, além de ser o primeiro artefato a
ser projetado, também é considerado o mais importante de um projeto de
software. Se essa arquitetura for mal projetada, poderá ocorrer diversos
problemas no desempenho, na escalabilidade e até para na evolução do
software (ERIKSSON, 2003).
A arquitetura de SPL tem aspectos peculiares em comparação com as ar-
quiteturas de software convencionais, pois na arquitetura de linha de produtos
são definidos um conjunto de variações que são explicitamente permitidas.
Já nas arquiteturas convencionais, praticamente qualquer variação é permi-
tida, desde que os requisitos do produto sejam atendidos (ERIKSSON, 2003).
Geralmente, a arquitetura de uma SPL reflete um estilo ou padrão de
arquitetura geral para uma aplicação específica. Suponha, por exemplo, que
um software de linha de produtos foi desenvolvido para gerenciar o envio de
veículos para atender determinados serviços de emergência. Os operadores
desse software terão o papel de atender os chamados (ligações telefônicas)
e identificar o veículo de atendimento de emergência o mais apropriado para
tratar o incidente relatado no chamado. A partir daí, os desenvolvedores desse
tipo de software poderão comercializar versões dele para diversos serviços
de emergência, como ambulâncias, bombeiros e polícia (SOMMERVILLE, 2019).
 Introdução à linha de produção de software 11

Desse modo, pode-se afirmar que a hipótese do sistema de expedição de

veículos de emergência representa um exemplo de arquitetura genérica de
alocação e gerenciamento de recursos. A Figura 3 ilustra a arquitetura desse
tipo de software, em que o gerenciamento de banco de dados (BD) inclui os
recursos disponíveis do BD, o gerenciamento de recursos envolve os com-
ponentes para implementar a política de alocação de recursos definida pelo
cliente/organização e o gerenciamento de entrada e saída (E/S) e a interação
que possibilitam aos usuários interagirem com o software por meio de uma
interface para solicitar ou liberar os recursos de E/S (SOMMERVILLE, 2019).

Figura 3. Arquitetura de um sistema de gerenciamento de recursos.

Fonte: Sommerville (2019, p. 420).

A arquitetura apresentada na Figura 3 pode ser instanciada de forma a

incluir os módulos necessários para a criação de uma linha de produto de
software para o mesmo tipo de software — expedição de veículos de emer-
gência — conforme ilustra a Figura 4.
12 Introdução à linha de produção de software

Figura 4. Arquitetura de uma linha de produto de software para o sistema de expedição de

veículos.
Fonte: Sommerville (2019, p. 421).

Pela Figura 4, pode-se observar os componentes presentes em cada nível,

explicados a seguir (SOMMERVILLE, 2019).

„ Nível 1 (nível de interação): é onde estão os componentes fornecem uma

interface com o operador e outra com os softwares de comunicação
utilizados.
„ Nível 2 (nível de gerenciamento de E/S): é onde estão os componentes
que lidam com autenticação do operador, geração de relatórios de
incidentes e de veículos expedidos, apoio à geração de mapas, plane-
jamento de rotas e também fornecimento de um mecanismo para os
operadores consultarem os bancos de dados do software.
„ Nível 3 (nível de gerenciamento de recursos): é onde ficam os compo-
nentes que permitem a localização e a expedição dos veículos, o geren-
ciamento de status de veículos e também o registrado de incidentes.
„ Nível 4 (nível do banco de dados): inclui gerenciamento de transações,
banco de dados de equipamentos, veículos e mapas e registro de
incidentes.
 Introdução à linha de produção de software 13

É importante salientar que as SPLs são arquitetadas para serem reconfi-

guráveis, podendo haver adição ou remoção de componentes, definição de
novos parâmetros, etc. Logo, para se criar uma nova instância do software
de serviços de emergência, provavelmente será necessário alterar os com-
ponentes individuais. É provável, por exemplo, que os bombeiros disponham
de muitos tipos de veículos, como um para combate a incêndios, outro para
apenas socorrer vítimas, etc. Nesse caso específico, pode ser necessário
definir uma estrutura de banco de dados para cada um dos tipos diferentes
de veículos (SOMMERVILLE, 2019).
Como vimos no decorrer desse capítulo, a industrialização do processo
de desenvolvimento de software foi inspirada na indústria automotiva, que
utiliza a metodologia de linha de produtos para a produção de veículos em
larga escala. Com o passar dos anos, a engenharia de software observou que
as vantagens de aplicar essa metodologia, com suas devidas adaptações,
poderia proporcionar a criação de novos produtos de software em curto
período de tempo. Desse modo, para promover o reúso de software em larga
escala, a engenharia de software criou a abordagem SPL, que trouxe inúmeros
benefícios, como a automatização de tarefas repetitivas, a redução no tempo
de entrega do produto, a diminuição no custo de produção de software, entre
outros.

Referências
ERIKSSON, M. An introduction to software product line development. In: UME'S STUDENT
CONFERENCE IN COMPUTING SCIENCE, 7., 2003. Proceedings […] [S. l.: s. n.], 2003. p. 26–37.
FERGUSON, R. Decisions for sustaining a software product line. Pittsburgh: [s. n.], 2019.
Disponível em: https://insights.sei.cmu.edu/blog/decisions-for-sustaining-a-software-
-product-line/. Acesso em: 28 ago. 2021.
GHABACH, E. Supporting clone-and-own in software product line. 2018. These (Doctored
in Computer Science) — Université Côte d’Azur, Nice, France, 2018. Disponível em: https://
tel.archives-ouvertes.fr/tel-01931217/document. Acesso em: 28 ago. 2021.
KAKOLA, T.; DUEÑAS, J. C. Software product lines: research issues in engineering and
management. Berlin: Springer-Verlag Berlin Heidelberg, 2006.
KANG, K. C.; LEE, J.; DONOHOE, P. Feature-oriented product line engineering. IEEE
Software, v. 19, p. 58–65, 2002.
PEREIRA, J. A.; FIGUEIREDO, E.; COSTA, H. A. Linhas de produtos de software: conceitos
e ferramentas. Minas Gerais: UFMG; LAVRAS, 2015. Disponível em: https://homepages.
dcc.ufmg.br/~kattiana/spl2tools/doc/Minicurso_Final_v1.pdf. Acesso em: 28 ago. 2021.
SCHMIDT, D. C.; GOKHALE, A.; NATARAJAN, B. Leveraging application frameworks: why
frameworks are important and how to apply them effectively. ACM Queue, v. 2, n. 5,
p. 66–75, 2004. Disponível em: https://queue.acm.org/detail.cfm?id=1017005. Acesso
em: 28 ago. 2021.
14 Introdução à linha de produção de software

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2019.

ZWINKAU, A. Definitions of software architecture. [S. l.: s. n.], 2019. Disponível em: https://
beza1e1.tuxen.de/definitions_software_architecture.html. Acesso em: 28 ago. 2021.

Leituras recomendadas
ALAM, M. M.; KHAN, A.; ZAFAR, A. A comprehensive study of software product line
frameworks. International Journal of Computer Applications, v. 115, p. 11–17, 2016.
DURSCKI, R. C. et al. Linhas de produto de software: riscos e vantagens de sua implan-
tação. In: SIMPÓSIO INTERNACIONAL DE MELHORIA DE PROCESSOS DE SOFTWARE, 6.,
2004, São Paulo. Anais eletrônicos [...] Disponível em: https://www.researchgate.net/
publication/242761922_Linhas_de_Produto_de_Software_riscos_e_vantagens_de_
sua_implantacao. Acesso em: 28 ago. 2021.
FIGUEIREDO, E. et al. Evolving software product lines with aspects: an empirical study
on design stability. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING (ICSE
2008), 30., 2008, Leipzig. Proceedings […] Disponível em: https://www.researchgate.net/
publication/221554577_Evolving_software_product_lines_with_aspects_An_empiri-
cal_study_on_design_stability. Acesso em: 28 ago. 2021.
NORTHROP, L. M. SEI's software product line tenets. IEEE Software, v. 19, n. 4, p. 32-40,
2002. doi: 10.1109/MS.2002.1020285.

Os links para sites da web fornecidos neste capítulo foram todos

testados, e seu funcionamento foi comprovado no momento da
publicação do material. No entanto, a rede é extremamente dinâmica; suas
páginas estão constantemente mudando de local e conteúdo. Assim, os edito-
res declaram não ter qualquer responsabilidade sobre qualidade, precisão ou
integralidade das informações referidas em tais links.