Linha de Produto de Software (SPL)

1. Introdução

Nos últimos anos, muitas técnicas foram desenvolvidas para apoiar o reuso de software. Em comum, essas técnicas, possuem a característica de explorarem o fato de que sistemas em um mesmo domínio são similares e têm potencial de reuso, e que o reuso é possível em diferentes níveis, desde funções simples até aplicações completas, e que os padrões para componentes reusáveis facilitam o desenvolvimento. Dentre as principais técnicas que objetivam o reuso de software temos:

• Desenvolvimento de software baseado em componentes;

• Linhas de produtos de software;

• Geradores de aplicações;

• Padrões de software;

• Frameworks;

• Bibliotecas de código.

Um problema enfrentado por aqueles que desenvolvem software é escolher uma dentre as várias técnicas que apóiam o reuso de software, haja vista, o grau de similaridade existente entre elas. Além disso, a escolha da técnica a ser utilizada depende de um conjunto de variáveis como: dos requisitos do sistema, da tecnologia e dos ativos reusáveis disponíveis e do conhecimento da equipe de desenvolvimento. No entanto, os principais fatores a serem considerados no planejamento do reuso são:

• Cronograma de desenvolvimento do software – se o software tem de ser desenvolvido rapidamente, deve-se tentar utilizar o quanto possível sistemas prontos em vez de componentes individuais;

• Ciclo de vida previsto da aplicação – se o ciclo de vida do software em desenvolvimento estiver sendo projetado para ser longo, então, os esforços devem ser concentrados na facilidade de manutenção do sistema a longo prazo, em oposição às possibilidades imediatas de reuso. Nesse caso, deve ser evitada a utilização de componentes de terceiros que não disponibilizem acesso ao código-fonte, uma vez que, não é possível ter garantias de que esses fornecedores serão capazes de continuar a fornecer o suporte e evolução do ativo reutilizado. Além disso, é importante a disseminação uniforme do conhecimento entre os desenvolvedores sobre o software em desenvolvimento, para que, mais tarde, possa existir histórico sobre o seu desenvolvimento. Isso não implica necessariamente em adotar uma postura de documentação pesada e com isso, desprender muito tempo na sua realização.

• Conhecimento, habilidade e experiência da equipe de desenvolvimento – todas as tecnologias de reuso são complexas e demandam tempo da equipe de desenvolvimento em compreendê-la e utilizá-la eficientemente. Portanto, é importante observar a linha de conhecimento da equipe e utilizar a técnica de reuso que mais se aproxima desse conhecimento;

• Importância do software e de seus requisitos funcionais – se o software precisa ser certificado por entidades externas, em alguns casos, pode ser impossível usar estratégicas de reuso que se apóiam no uso de geradores de programas, que tendem a gerar códigos relativamente ineficientes do ponto de vista do desempenho e extensão;

• Domínio da aplicação – em alguns domínios de aplicação, tal como sistemas de informações industriais e médicas, há vários produtos genéricos que podem ser reusados por meio de configuração para uma situação específica;

• Plataforma sobre a qual o sistema será executado – Alguns modelos de componentes são específicos de plataforma, por isso, é importante observar qual a plataforma alvo da aplicação e utilizar os componentes desenhados para ela.

Reutilizar software é freqüentemente uma decisão mais gerencial do que técnica. Os gerentes podem não desejarem comprometer seus requisitos ao permitir o reuso de componentes reutilizáveis ou eles podem decidir que o desenvolvimento de componentes originais ajudará a criar uma base de ativos de software. Por isso, cabe a equipe de desenvolvimento (TI) auxilia-los, expondo os riscos e ganhos das suas escolhas.

2. Linhas de Produto de Software (SPL)

Uma das abordagens mais eficazes de reuso é a criação de linhas de produtos de software ou famílias de aplicações. Uma linha de produtos consiste em uma família de sistemas de software que têm um conjunto de funcionalidades e variáveis em comum. A vantagem da abordagem de linha de produtos de software é que as aplicações não compartilham apenas produtos arquiteturais de baixo nível, mas também, toda a especificação de alto nível como: requisitos e projetos (design) que podem ser reutilizados pelos diferentes membros da família. Para Clements e Northrop
(2002)¹ uma linha de produto de software é um conjunto intensivo de sistemas de software que compartilham e gerenciam um conjunto de características em comum que satisfazem uma necessidade específica de um domínio, e que são desenvolvidos a partir de um núcleo comum conforme prescrito.

O interesse na abordagem de linha produto de software emergiu a partir da percepção dos desenvolvedores, de que reutilizar arquiteturas de software traz muito mais benefícios do que reutilizar componentes individuais.

A idéia de linha de produtos não é nova. Há vários exemplos de utilização do conceito de linha de produto na história antiga, as pirâmides do Egito é um exemplo das primeiras construções a utilizar o conceito, e na atualidade, temos o exemplo da indústria aeronáutica, com o Airbus A-318, A-319, A-320, A-321, que compartilham características em comum incluindo motores, equipamentos de navegação e equipamento de comunicação. Na indústria de TI temos como exemplo a empresas fornecedoras de ERP (Enterprise Resource Planning) que são sistemas projetados de forma “genérica”, ou seja, sistemas que possuem todas as características que permeiam os processos de negócio da maioria das empresas na atualidade.

Para o desenvolvimento de linha de produtos, ele deve envolver a análise de quais características (requisitos funcionais) da família são comum, quais são opcionais e quais são alternativos. Após a realização dessa análise, o objetivo é transferido ao projeto da arquitetura da família da linha de produtos que tem componentes em comum (requisitos compartilhados por todos os membros da família), os componentes opcionais (requeridos apenas por alguns membros da família) e componentes variáveis (diferentes versões de um mesmo componente são requeridos por diferentes membros da família). Para modelar e projetar famílias de sistemas, as concepções da análise e projeto de sistema de produto simples necessita ser estendida para suportar o conceito de linhas de produto de software.

Linhas de produto de software são projetadas para re-configuração. Essa re-configuração pode envolver a adição ou remoção de componentes do sistema, definição de parâmetros e restrições para os componentes, além da inclusão de conhecimento dos processos de negócio.

Linhas de produtos de software podem ser configuradas em dois pontos no processo de desenvolvimento:

• Configuração em tempo de implantação na qual um sistema é projetado para ser configurado pelos clientes ou pelos consultores que trabalham com o cliente. O conhecimento dos requisitos do cliente e do ambiente operacional do sistema é incorporado em um conjunto de arquivos de configuração usados pelo sistema genérico;

• Configuração em tempo de projeto na qual a organização responsável por desenvolver o software projeta-o a partir de um núcleo comum da linha de produtos e trabalha sobre a especificidade do cliente, o que resulta em um novo sistema.

Pode-se pensar em linhas de produtos de software como instâncias e especializações de arquiteturas mais genéricas. Uma aplicação é muito geral; linhas de produtos de software especializam a arquitetura para um tipo específico de aplicação.

De maneira geral, as etapas envolvidas na adaptação de uma família de aplicações para criar uma nova aplicação são as representadas na figura 1.

Figura 1 Etapas envolvidas na adaptação de uma aplicação da família de produtos.

A adoção dos conceitos da linha de produtos de software pode ser adotada pelas organizações de forma gradual, para não causar muito impacto na forma como a equipe está acostumada a trabalhar. Primeiro a organização mapear as funcionalidades que permeiam as aplicações desenvolvidas internamente. Exemplo: controle de acesso, sistema de auditoria, controle de transação, etc.. Dessa forma, ela pode extrair essas funcionalidades mapeadas, e concentra-las em um núcleo (core) para que venham ser utilizadas nas novas aplicações e ou adaptadas nas já existentes, reduzindo assim, o custo do desenvolvimento e o tempo de entrega das aplicações (time-to-market).

Quanto aos aspectos arquiteturais, à preocupação que deve existir, diz respeito à definição e disponibilização de aplicações reutilizáveis em oposição a disponibilização de componentes reutilizáveis, e para isso, vários paradigmas podem ser utilizados e combinados, dentre os quais, cabe destacar:

1. Programação Orientada a Aspectos (AOP) – para separação e implementação dos requisitos transversais (crosscutting concerns);

2. Padrões de software (Design Patterns, Analysis Pattern, etc.) – para a documentação e definição de um vocabulário uníssono a ser utilizado entre os desenvolvedores;

3. Model-Driven Architecture – desenvolver aplicações a partir de modelos, mudando o foco do desenvolvimento do código para o modelo, incorporando níveis diferentes de abstração.

1 CLEMENTS, J.; NORTHROP, A. Software Product Lines, 2002.