Especificação do PDM

Na abordagem FOMDA, o Modelo de Descrição de Plataformas (PDM) é um Modelo de Features. O objetivo do projetista de transformações ao especificar o PDM é identificar características não funcionais que podem ser utilizadas para desenvolver sistemas em uma organização. Características que ele pode especificar nesta visão são relacionadas com arquiteturas de desenvolvimento, padrões de projeto, serviços de software, tecnologias de desenvolvimento, hardware, restrições temporais, etc.

O objetivo do projetista de transformações, na primeira etapa de organização de transformações da FOMDA, é determinar um domínio tecnológico e arquitetural, que o projetista de aplicações pode utilizar para desenvolver qualquer aplicação deste domínio. A primeira etapa de organização de transformações é baseada na abordagem de Tekinerdogan et al. (Tekinerdogan et al 2004).

A Figura 21 apresenta um exemplo de PDM, no qual características não funcionais, utilizadas para desenvolver aplicações em uma organização qualquer, foram especificadas. Este é um exemplo simples e especifica que: (1) o uso de padrões de projeto (design patterns) é opcional, mas caso esteja selecionado no modelo, podem ser utilizados os padrões MVC e

Observer; (2) o desenvolvimento de uma aplicação precisa da escolha de uma linguagem de

programação, que deve ser Java ou VB.NET; (3) toda a aplicação precisa conter uma interface gráfica de usuário, que deve ser desenvolvida com Swing, JSP ou ASP.

Figura 21 - Exemplo de PDM para a Abordagem FOMDA

É determinado que, se a linguagem de programação escolhida for Java, então a interface gráfica não pode ser ASP. Da mesma maneira, se a linguagem escolhida for VB.NET, a interface gráfica da aplicação não pode ser Swing nem JSP. Não é possível especificar estas regras graficamente no FM. Porém, como foi explicado na Seção 2.3.2, composition rules podem ser adicionadas nas características do FM. Isto pode ser feito nas características Java e

VB.NET ( como é mostrado na Tabela 1), em que as regras para seleção destas características

são especificadas textualmente como composition rules.

Tabela 1 - Regras Para Composição de Características

Característica Composition Rule

Java excludes “ASP”

VB.NET excludes “Swing” and “JSP”

7.3.2 Instanciação do PDM (Transição da Primeira Etapa para a Segunda)

O PDM é definido pelo projetista de transformações e utilizado pelos projetistas de aplicações. Com base no PDM definido na Figura 21, o projetista de aplicações está limitado a desenvolver software utilizando os recursos identificados nesta figura. Para desenvolver um sistema, o projetista de aplicações seleciona as características do PDM que quer utilizar. Esta tarefa determina a transição da primeira etapa de organização de mapeamentos e transformações e modelos para a segunda das etapas definidas na abordagem FOMDA. A Figura 22 mostra em destaque características que poderiam ter sido selecionadas por um projetista de aplicações para desenvolver sistemas.

Na abordagem FOMDA, a partir desta seleção, o PDM é utilizado para aplicar transformações em um modelo de sistema. O PDM recebe como entrada um PIM e o transforma em um PSM. Isto é realizado com o auxílio da ferramenta FOMDA Toolkit, de maneira semi-automatizada, ou seja, é necessária a intervenção do projetista de aplicação.

Cada característica selecionada no PDM precisa efetuar uma transformação. Uma transformação pode adicionar, por exemplo, marcações no modelo de entrada, que podem ser utilizadas por outras transformações para gerar o PSM. Neste sentido, é importante identificar quais são as transformações que cada característica deve realizar num modelo de sistema.

Figura 22 - Instância de PDM Usada para Desenvolver Aplicações

7.3.3 Mapeamento de Transformações em Características do FM

Transformações são transformadores especificados na terceira e quartas etapas de organização de transformação e podem ser adicionadas nas características do FM. Isto significa que mapeamentos de transformadores da categoria TMD podem ser utilizados por cada característica do modelo. Características do FM não possuem relação direta com transformações nas abordagens estudas na literatura (Czarnecki 1998, Czarnecki e Simon 2003, Deeltra et al. 2003). Logo, o meta-modelo de Features, mostrado na Figura 23, foi estendido para suportar transformadores, como é mostrado na Figura 24.

A Figura 23 apresenta o meta-modelo de Features, especificado com base no Modelo de Features de Czarnecki (Czarnecki 1998). Na Tabela 2, a coluna “Meta-dado” contém os meta-dados (definidos na Figura 23) que são utilizados para especificar os possíveis relacionamentos que podem ser estabelecidos entre as características do Modelo de Features de Czarnecki.

Figura 23 - Meta-Modelo de Features

Na abordagem FOMDA, transformadores podem ser mapeados para características do FM. O meta-modelo de Features foi incorporado e estendido no meta-modelo FOMDA. A Figura 24 apresenta extensões aplicadas no elemento FeatureElement, em destaque nesta figura. O meta-dado FeatureElement foi estendido pelo meta-dado FOMDAFeatureElement.

FOMDAFeatureElement é o meta-dado que especifica uma característica do FM, com

extensões para aplicar transformações. Este meta-dado possui um relacionamento com o meta-dado TransformationDescriptor, que descreve uma transformação. Uma instância do meta-dado TransformationDescriptor precisa conter uma instância do meta-dado

Transformer, que é o transformador da categoria TMD. Uma característica de um FM pode

aplicar mais de uma transformação e, para isto, ela deve disponibilizar mais de um transformador.

Analisando as características em destaque na Figura 22, é possível ter uma noção das características que são utilizadas para transformar um PIM em um PSM. Como discutido anteriormente, para transformar um PIM em um PSM, é necessário especificar ordem nas transformações. Para identificar a ordem das transformações é necessário identificar antes as entradas e saídas de cada característica do FM. Isto implica em identificar que tipo de elemento uma característica do FM pode adicionar no modelo fonte do sistema (após uma determinada transformação). Além disso, também é necessário identificar as marcações nos elementos do modelo de sistema. Estas são utilizadas por uma característica do FM para

aplicar transformações. Portanto, identificar o que uma característica recebe como entrada e o que ela gera como saída é uma tarefa importante. A abordagem FOMDA resolve isso adicionando às características parâmetros de entrada e de saída.

Tabela 2 - Relacionamentos e Respectivos Meta-dados do Modelo de Features Nome da

Relação Descrição Representação Gráfica Meta-dado

Optional

Relation A característica relacionada pode ser selecionada OptionalRelation Mandatory

Relation A característica relacionada sempre é necessária no modelo MandatoryRelation Mandatory

Mutually Exclusive Relation

É obrigatória a seleção de apenas uma característica dentre as demais características definidas na relação

MandatoryXORRelation Optional

Mutually Exclusive Relation

É opcional a seleção de apenas uma característica dentre as demais

características definidas na relação OptionalXORRelation Or No mínimo uma característica, dentre as demais definidas na

relação, precisa ser selecionada OrRelation

Requires

Se uma característica está selecionada e ela contém este tipo de relação, então a característica relacionada com ela precisa também ser selecionada

Requires

Excludes

Se uma característica está selecionada e ela contém este tipo de relação, então a característica relacionada com ela não pode ser selecionada

Não Possui

Representação Gráfica Excludes

O meta-dado FeatureParameter pode ser utilizado para documentar parâmetros de entrada e saída de cada característica. Ele é um tipo de ParameterDescriptor e, portanto, contém um nome e descreve o tipo de objeto que pode ser armazenado no atributo element. Além disso, um parâmetro de uma característica pode conter marcações, que são estereótipos restrições ou tagged values. Estas marcações servem para documentar, de maneira detalhada, os elementos de modelos que podem ser recebidos ou gerados por uma característica. Como cada característica pode conter muitos transformadores e os transformadores podem receber parâmetros distintos, as características também o podem. Além disso, é possível especificar mais de uma saída para uma característica, visto que transformadores podem efetuar transformações diferentes e, portanto, gerar modelos diferentes como resultado. A adição de

parâmetros de entrada e saída às características do FM é um ponto positivo na abordagem FOMDA, porque documenta em alto nível as entradas e saídas das transformações.

Figura 24 - Extensões do Meta-Modelo de Features