METODOLOGIAS DE LINHAS DE PRODUTO DE SOFTWARE: PLUS E FRAMEWORK PROPOSTO PELO POHL

PLUS

As linhas de produtos de software, ou família de produtos/sistemas é uma das abordagens mais eficazes de reuso de software. As LPS oferecem grandes melhorias no desenvolvimento de sistemas, tais como a redução dos custos, aumento na produtividade, melhoria na qualidade do produto. A partir das LPS, surgiram então métodos que auxiliam na modelagem e na codificação das aplicações.

Um método bem usado, baseado em UML, é conhecido como PLUS (Product Line UML-Based Software Engineering). O método estende os métodos de modelagem e processos de sistemas individuais para tratar de LPS. O PLUS fornece adições para o processo de modelagem de sistemas únicos, que serão abordados mais adiante.

Para dar suporte ao desenvolvimento de linhas de produto de software, o método pode ser integrado a outros métodos e processos de software tradicionais. Ele é um processo iterativo, orientado a objeto e compatível com o USDP (Unified Software Development Process) e o modelo de desenvolvimento em espiral.

O objetivo do Plus é modelar explicitamente a comunalidade (atributos em comum) e a variabilidade (atributos variáveis) de uma linha de produtos de software.

O método propõe uma análise na comunalidade e na variabilidade de acordo com os requisitos da LPS. Desenvolvendo então o modelo de casos de uso da linha de produto, o modelo de análise, a arquitetura da LPS e os componentes reusáveis. Realizando testes de componentes e das features da aplicação. E armazena os artefatos em um repositório da LPS.

A engenharia de software da aplicação em individual, é composta pelo desenvolvimento da mesma, que é uma parte da Linha de Produto de Software. E a todo tempo os desenvolvedores fazem uso dos artefatos armazenados no repositório durante o ciclo de engenharia da LPS.

Dados os requisitos gerais da aplicação individual temos que o modelo de casos de uso da linha de produto deriva o modelo de casos de uso da aplicação, e também que modelo de análise da linha de produto deriva o modelo de análise da aplicação, e por fim, que a arquitetura da LPS deriva a arquitetura da aplicação. Ou seja, temos sempre que a linha de produto sempre vai auxiliando na arquitetura, modelagens das aplicações individuais.

Finalmente, com a arquitetura da aplicação e os componentes do repositório da engenharia da linha de produto, é feita a implantação da aplicação executável na linha de produto.

Os Requisitos da aplicação de modelagem da linha de produto de softwares tem como abordagem o desenvolvimento destes modelos de requisitos e é comparado com o feature model (caracteristicas do modelo) da LPS, assim determinando quais feature podem fazer parte dessa aplição.

Sua aplicação típica é a feature do kernel (Caracteristicas do núcleo), mais algumas features opcionais e alternativas.

Podemos ver também a Analysis Modeling (Análise da modelagem), Design Modeling (Modelo de Projeto).

Analisis Modeling: abrange os modelos estáticos e os modelos dinâmicos.

Design Modeling: é adaptada a partir da arquitetura da SPL e a features dessa aplicação indicam quais compontentes são selecionandos.

Pode ser feito testes funcionais e de integração para essas aplicações.

FRAMEWORK (Proposto por Pohl)

Framework para Engenharia de linha de produção de software

O framework incorpora conceito central de engenharia de linha de produção tradicional, ou seja, o uso de plataformas e a capacidade de fornecer customização em massa.

No contexto de software, plataforma é um conjunto de artefatos reutilizáveis, que unidos de uma forma consistente e sistemática formam aplicações.

O paradigma de linha de produto de software separa dois processos:

● Domain engineering (Engenharia de domínio): Processo da engenharia de linha de produto de software no qual partes comuns e variáveis da linha de produto são definidas e realizadas.

● Application engineering (Engenharia de aplicação): Processo da engenharia de linha de produdo de software no qual as aplicações da linha de produto são construídas reusando artefatos do domínio e explorando a variabilidade da linha de produto.

A vantagem dessa divisão é que existe a separação de dois interesses: construir uma plataforma robusta e construir aplicações específicas do cliente em um curto período de tempo. Para ser eficaz, os dois processos têm que interagir de modo que os dois sejam beneficiados.

A separação em dois processos também indica a divisão de interesses respeitando a variabilidade. Domain engineering é responsável por assegurar que a variabilidade disponível é apropriada para produzir o aplicativo. Isso envolve mecanismos comuns para derivação de uma aplicação específica. A plataforma é definida com a quantidade certa de flexibilidade em muitos artefatos reutilizáveis. Grande parte de engenharia de aplicações consiste em reusar plataformas e ligar a variabilidade como necessário para diferentes aplicações.

Visão geral do Framework

O processo de engenharia de domínio é composto por cinco subprocessos chave: gerenciamento de produtos (product management), engenharia de requisitos (domain requirements engineering), projeto de domínio (domain design), domínio de realização (domain realisation) e teste de domínio (domain testing).

O processo de engenharia de aplicação é composto pelos sub-processos de aplicação de engenharia de requisitos (application requirements engineering), design da aplicação (application design), aplicação de realização (application realisation) e aplicação de teste (application testing).

O framework difere os tipos de desenvolvimento de artefatos: artefatos de domínio e de aplicações. Os artefatos de domínio inclui a plataforma da linha de produção de software. Os artefatos de aplicações representam todos os tipos de desenvolvimento de artefatos de aplicações específicas.Como a plataforma é usada para derivar mais que uma aplicação, engenharia de aplicação tem de manter artefatos de aplicação específica para cada uma separadamente.

Engenharia de domínio

Os principais objetivos da engenharia de domínio são: ● Definir a semelhança e a variabilidade da linha de produto de software;

● Definir o conjunto de aplicações para os quais os softwares são planejado, ou seja, define o escopo da linha de produto