A Model-Driven Software Reuse Approach (in portuguese)

maior em determinada parte do processo, procurando solucionar parte do problema. Em
termos gerais, um processo de reutilização de software deve definir ao menos duas atividades
essenciais: o desenvolvimento para reutilização, que consiste no desenvolvimento dos artefatos
de software que serão posteriormente reutilizados, e o desenvolvimento com reutilização,
que consiste no desenvolvimento de aplicações que reutilizam os artefatos previamente
desenvolvidos.
Esta distinção entre desenvolvimento para/com reutilização é o ponto fundamental da
abordagem de engenharia de software conhecida como Linha de Produtos de Software
(CLEMENTS; NORTHROP, 2002; LINDEN; SCHMID; ROMMES, 2007), descrita a seguir.
2.1.2.1 Linhas de produtos de software
A origem desta abordagem pode ser rastreada até um trabalho da década de 1970, de
Parnas (1976), o mesmo autor que definiu os conceitos de encapsulamento da informação, um
dos fundamentos da orientação a objetos. Neste trabalho é descrito o conceito de famílias de
programas, e apesar de inicialmente ter focado na variabilidade em termos das características
não funcionais, Parnas estabelece a base para as linhas de produto de software (LINDEN;
SCHMID; ROMMES, 2007).
O princípio definido era o de estudar primeiro o que os programas de uma mesma
família tinham em comum, para depois tentar entender o que os diferenciava. Em seguida,
duas alternativas de método produziam programas incompletos que implementavam as partes
comum da família, e deixavam as partes variáveis para serem instanciadas posteriormente: o
método de refinamento por etapas (stepwise refinement), que produzia um programa no qual
alguns tipos de operandos e operadores eram deixados sem implementação; e o método de
especificação dos módulos, que baseava-se na especificação em alto nível de unidades de
comportamento de programas e no encapsulamento da informação para que o restante do código
pudesse ser idealizado e construído. Para construir um novo programa, um desenvolvedor
reutilizava este programa incompleto e o completava de acordo com as variabilidades desejadas,
seja providenciando os operadores e operandos, ou efetivamente implementando os módulos
especificados.
Ou seja, há uma mudança de foco. Ao invés de desenvolver software considerando os
requisitos de um único sistema, tenta-se desenvolver software que consiga atender aos requisitos
de um conjunto de sistemas similares, de forma que é possível reaproveitar as partes comuns e
apenas desenvolver o que é completamente novo. Na nomenclatura típica da área de linhas de
produtos de software, este conjunto de sistemas similares é chamado de família de produtos, ou
33