3. CrossMDA-SPL: Uma Abordagem para Gerência de Variabilidades Dirigida
3.5. Diretrizes para Modelagem e Representação das Variabilidades na
3.5.2. Diretrizes Aplicadas ao Modelo de Variabilidades no CrossMDA-SPL
3.5.2.3. Tipos de Features e Modelagem das Variabilidades
3.5.2.3.1. Modelagem de Feature Opcional
As features opcionais são modeladas considerando os diferentes tipos de refinamentos/mudanças que elas realizam no modelo do núcleo (Tabela 2). A seguir ilustramos as diretrizes para modelar cada feature opcional considerando diferentes tipos de refinamentos.
Caso a feature opcional a ser modelada represente a criação de uma nova Classe, dependendo da especificação da feature, o engenheiro de domínio poderá modelar a forma como ela refina o modelo do núcleo sob três formas de relacionamentos diferentes: Herança, Implementação e Associação.
O modelo de features hipotético representado na Figura 13 é utilizado para ilustrar os diferentes tipos de features modelados pelas diretrizes propostas. O
representado por uma árvore, onde cada nó representa uma feature harmonizada em uma relação pai e filho(s). As arestas da árvore são interpretadas como o tipo do nó e indicam se a feature é mandatória, opcional ou alternativa. No modelo, uma feature mandatória é representada por uma aresta terminada por um círculo preenchido. Já uma feature opcional é representada por uma aresta terminada por círculo vazio. As features alternativas são representadas por arestas que estão ligadas e conectadas por um arco. Se o arco for vazio, deve-se escolher apenas uma das alternativas (alternativa exclusiva), se o arco for preenchido, é permitido escolher mais de uma alternativa (alternativa inclusiva).
Figura 13 - Modelo de features hipotético utilizado na modelagem das variabilidades usando as diretrizes propostas.
Espelhado no modelo de feature da Figura 13, a nova Classe, que representa a feature opcional sob as três formas de relacionamentos, é modularizada no modelo de variabilidades através da criação de um pacote que esteja relacionada à feature pai. Por exemplo, se a feature FeatureB é representada como um nó filho da feature FeatureA, o pacote será criado seguindo esse formato, “<domínio da LPS>.feature.FeatureA”, como se trata de uma feature opcional, o engenheiro terá que aplicar o estereótipo <<optional>>.
Logo após a criação do pacote será definido um Aspecto responsável por relacionar a nova Classe aos elementos do modelo do núcleo, através dos mecanismos da orientação a aspectos propostos pelo CrossMDA. Neste caso, a
modelagem deste Aspecto será específica para cada forma de relacionamento (herança, implementação e associação). Todos os aspectos criados no modelo de variabilidades são decorados com estereótipo <<aspect>>. Para a forma de relacionamento do tipo “Herança”, o engenheiro criará um aspecto (AspectFeatureB), dentro do mesmo pacote, que modifica alguma classe do modelo do núcleo incluindo uma herança entre a nova classe “FeatureB”. Esta modificação é indicada, no aspecto, por uma declaração intertipo definida através de um método decorado com o estereótipo “parents_extends” (Figura 14). É importante destacar que para as features com o tipo de refinamento Classe, são criadas, dentro do modelo de variabilidades, as respectivas classes que representam entidades do modelo do núcleo.
Figura 14 - Exemplo da modelagem de uma feature opcional com refinamento de classe e relacionamento de herança.
Sob a forma de relacionamento do tipo “Implementação”, o engenheiro também criará um aspecto (AspectFeatureB) nas mesmas condições. Todavia, o refinamento na classe incluirá uma mudança na estrutura fazendo com que a nova classe “FeatureB” implemente uma ou mais classes do modelo do núcleo. Esta modificação é indicada, no aspecto, por uma declaração intertipo definida através de um método decorado com o estereótipo “parents_implements”, ilustrado na Figura 15.
Figura 15 - Exemplo da modelagem de uma feature opcional com refinamento de classe e relacionamento de implementação.
Já na forma de relacionamento do tipo “Associação”, o engenheiro também criará um aspecto (AspectFeatureB) da mesma forma. Entretanto, essa forma de relacionamento representará novas associações entres as classes, por exemplo, a “FeatureB” será relacionada com a “FeatureA” através de uma associação. Desta forma, a diretriz propõe a definição de um aspecto que é responsável por introduzir a associação entre as classes. Este tipo de relacionamento ocorre por meio da definição de uma declaração intertipo definida em uma associação decorada com o estereótipo “introduction_association”. Como ilustrado na Figura 16, o aspecto (AspectFeatureB) é modelado de forma um pouco diferente. São criados três atributos (dois para representarem a multiplicidade da associação e um para representar o nome da associação) que correspondem à definição do introduction_association entre o aspecto e a classe (FeatureB) que será associada. Esses atributos são utilizados para validação do tipo de mapeamento association durante a fase de mapeamento.
Figura 16 - Exemplo da modelagem de uma feature opcional com refinamento de classe e relacionamento de associação.
Outra forma de relacionamento seria se a feature opcional representasse a adição de novos Atributos e/ou Métodos nas classes já existentes no modelo do núcleo. Para tal forma de relacionamento, os novos atributos e métodos serão introduzidos com declaração intertipos do tipo introduction_attribute e introduction_method propostos pelo CrossMDA. Para este caso, também será criado um pacote que esteja relacionado com a feature a ser modelada, como por exemplo, “<domínio da LPS>.feature.FeatureD”, e aplicado o estereótipo <<optional>> por se tratar de uma feature opcional. Cada feature será implementada por um Aspecto (FeatureE, FeatureF) diferente, modelado dentro do mesmo pacote. Cada aspecto é composto dos atributos ou métodos que serão adicionados às classes do modelo do núcleo, como ilustra a Figura 17.
Figura 17 - Exemplo da modelagem de uma feature opcional com refinamento em Atributos e/ou Métodos.
Outro caso seria se a feature opcional a ser modelada representasse Mudanças no Comportamento dos Métodos e Atributos das classes já existentes no modelo do núcleo. Este tipo de feature ocorre quando um método ou atributo de uma classe tem seu comportamento modificado com a presença de uma nova feature. Essas mudanças no comportamento dos métodos e atributos serão feitas com interceptações e adendos aos mesmos. Para modelagem deste tipo de feature, também é criado um pacote que esteja relacionado com a feature modelada, como por exemplo, “<domínio da LPS>>.feature.FeatureG”. Depois disto, modela-se um Aspecto para cada feature, dentro do mesmo pacote. Cada aspecto é formado pelas interceptações e adendos que serão aplicados aos métodos e/ou atributos. As interceptações constituem em definir quais métodos ou atributos dos elementos do modelo do núcleo terão seus comportamentos alterados, já os adendos representam
os comportamentos que serão aplicados. A Figura 18 ilustra a forma de modelagem do aspecto e seus respectivos adendos e interceptações.
Figura 18 - Exemplo da modelagem de uma feature opcional com refinamento de Mudanças no Comportamento dos Métodos e Atributos.
Por fim, o último refinamento que pode ser aplicado a uma feature opcional é a do tipo Associação entre Classes. Este refinamento representa a associação entres classes já existentes no modelo do núcleo. Ele já foi descrito acima, como uma forma de associar um refinamento do tipo classe.