Linhas de Produto de Software

Algumas empresas de software se especializam em um determinado nicho de mercado, desenvolvendo diversos produtos específicos de um domínio. Essas empresas criam um ambiente análogo aos das linhas de produção da indústria, no qual softwares que compartilham diversas características em comum são construídos de forma mais eficiente. Esse tipo de ambiente compõe uma Linha de Produtos de Software (LPS) (MOHAMED-ALI e MOAWAD, 2010; POHL et al., 2005; CLEMENTS e NORTHROP, 2001).

Diversas abordagens de LPS podem ser encontradas na literatura, como Application-

based DOmain Modeling (ADOM) (KRAMER e STURM, 2010), Product Line UML-based Software engineering (PLUS) (GOMAA, 2004), Product Line Software Engineering (PuLSE)

(BAYER et al., 1999) e Family-oriented Abstraction, Specification, and Translation (FAST) (WEISS e LAI, 1999). Apesar das diferenças na forma como tratam o problema, em geral, as abordagens de LPS seguem o modelo de processo mostrado na Figura 2.13, no qual são identificados dois ciclos (SCHMID e ALMEIDA, 2013; CZARNECKI, 2005): Engenharia do Domínio, em que ocorre a definição do domínio e a construção dos recursos (DSLs, ferramentas, softwares reutilizáveis e documentos) da LPS; e Engenharia da Aplicação, na qual os produtos são desenvolvidos com o apoio dos recursos da LPS.

Figura 2.13. Modelo de processo de uma LPS. Adaptado de Czarnecki (2005).

De maneira similar ao processo de desenvolvimento de um único software, a engenharia de domínio também é dividida em análise, projeto e implementação, porém, com enfoque em um conjunto de softwares (RAMOS et al., 2013; PEROVICH et al., 2009; CZARNECKI, 2005). Na etapa de análise da engenharia de domínio ocorre a definição das características que compõem o domínio da LPS. Uma característica é uma propriedade que agrega valor aos usuários de um software e são documentadas em um modelo de características (Feature Model) (JÉZÉQUEL, 2012; SEPÚLVEDA et al., 2012; BENAVIDES et al., 2010; KANG et al., 1990) do domínio. Nesse tipo de modelo, as características são organizadas no formato de árvore, sendo que a raiz representa os produtos da LPS. As características são classificadas como obrigatórias ou opcionais e podem ter variantes (CZARNECKI e WASOWSKI, 2007).

Na Figura 2.14 é mostrado um modelo de características no qual está representada uma adaptação do domínio de veículos autônomos do kit Lego Mindstorms® NXT 2.03_.

Nesse domínio um veículo (Vehicle) é decomposto em quatro características: duas opcionais, sensor (Sensor) e braços (Arms); e duas obrigatórias, motor (Engine) e dispositivo de locomoção (Locomotion Device). O veículo pode ter até três sensores: infravermelho (Infrared Sensor), sensor de luz (Light Sensor) e sensor de toque (Touch Sensor). Além disso, o veículo poder usar um dos dois tipos de dispositivo de locomoção: rodas (Wheels) ou esteira (Caterpillar).

Figura 2.14. Modelo de características do domínio de veículos autônomos.

Na etapa de projeto são definidos os recursos reutilizáveis com base nas características do domínio. Normalmente, a arquitetura comum a todos os produtos da LPS é representada por um framework (STURM e KRAMER, 2010; KIM et al., 2004; WEISS e LAI, 1999). Também podem ser criados metamodelos para compor o escopo de DSLs e geradores. Além disso, outros recursos pré-existentes, específicos ou não de domínio, podem ser incorporados a LPS, como por exemplo, repositórios, ferramentas de desenvolvimento e frameworks de middleware. Por fim, na etapa de implementação, todos os recursos reutilizáveis específicos da LPS são construídos.

A engenharia de aplicação é composta pelas etapas de requisitos, derivação e construção (SCHMID e ALMEIDA, 2013; CZARNECKI, 2005). Na etapa de requisitos um subconjunto das características do domínio e suas variantes são selecionados com base nos requisitos do produto em desenvolvimento. Características específicas do produto também podem ser acrescentadas. Assim, o modelo do produto com base na DSL da LPS é criado como uma instância do modelo de características do domínio. Na etapa de derivação, cria-se um modelo que considera os recursos que serão reutilizados para desenvolver o produto. Por fim, na etapa de construção ocorre a construção do produto com o reúso dos recursos da LPS e com a criação das suas partes específicas.

Como também é mostrado na Figura 2.13, existe uma troca bidirecional de informações/recursos entre ambos os ciclos. A engenharia de domínio supre a engenharia de aplicação com os recursos reutilizáveis da LPS, enquanto que a engenharia de aplicação fornece um feedback sobre novas características que podem ser incorporadas ao domínio. Portanto, o domínio de uma LPS pode evoluir a medida que novos produtos são desenvolvidos (RAMOS et al., 2013; CZARNECKI, 2005).

Na literatura são encontradas diversas ferramentas que apoiam o desenvolvimento de LPSs (PEREIRA et al., 2013). Na Subseção 2.5.1 é apresentada a ferramenta Pure:variants, que apoia todas as etapas da Engenharia de Domínio e Engenharia de Aplicação.

2.5.1 Pure::variants

Pure::variants (PURE SYSTEMS, 2013) é uma ferramenta de uso proprietário criada com base no Eclipse IDE, que permite a criação de LPSs a partir de uma aplicação base. Os produtos desenvolvidos com a LPS são variantes dessa aplicação base, formados por um subconjunto das suas características.

A interface da Pure::variants é apresentada na Figura 2.15. As características são organizadas em uma notação de árvore, mostrada no centro da figura. No modelo à direita é possível definir a arquitetura da LPS por meio de uma modelagem dos componentes que

implementam cada característica do domínio. Caixas de seleção no modelo de características permitem selecionar as características que se aplicam a um produto e gerar o seu código-fonte com base no modelo de componentes. Um manual da ferramenta Pure::variants para construção de uma LPS a partir do código-fonte de uma aplicação é apresentado no Apêndice B.

Figura 2.15. Interface da ferramenta Pure::variants (Pure, 2013).