Por que eu devo ler este artigo:Este artigo aborda tópicos relacionados à Common Variability Language (CVL). Nele é descrito como a CVL permite especificar e representar variabilidades de Linhas de Produto de Software (LPS) por meio de modelos definidos pela linguagem de modelagem unificada (UML).

Uma aplicação prática é exemplificada com a LPS acadêmica Arcade Game Maker (AGM). Por fim, o modelo desenvolvido pela a aplicação de CVL é então comparado aos modelos gerados pela aplicação da abordagem de gerenciamento de variabilidades baseada em UML, SMarty.

Esse tema é útil para gerentes, arquitetos, estudantes e engenheiros de software interessados em aprofundar seus conhecimentos sobre representação de variabilidades por meio de linguagem de identificação específica, como a CVL, para auxiliar na atividade de gerenciamento de variabilidades em linhas de produto de software.

Possibilitando, ainda, a análise da comparação de modelos desenvolvidos por essa linguagem e por uma abordagem de gerenciamento de variabilidades baseada em UML.
Autores: Anderson da Silva Marcolino, Alisson Chiquitto, Edson A. Oliveira Junior e Itana Maria de Souza Gimenes

Uma Linha de Produto de Software (LPS) representa um conjunto de produtos de software que compartilham características comuns e gerenciáveis, que satisfazem as necessidades de um segmento particular do mercado ou de uma missão.

Também conhecido como uma família de produtos, os produtos desse conjunto de sistema de software são desenvolvidos de maneira sistemática a partir do núcleo de artefatos.

O núcleo de artefatos forma a base de uma LPS e, normalmente, inclui a arquitetura de linha de produto de software, componentes reusáveis, modelos de domínios, requisitos da LPS, planos de teste e modelos de características e de variabilidades.

Ao adotar a abordagem de LPS deve-se trabalhar com duas questões de igual importância. A engenharia de domínio, que está preocupada com a especificação de recursos de domínio, e a engenharia de aplicação, que está relacionada com o desenvolvimento eficiente de novos membros da LPS.

Por meio de uma LPS, diferentes customizações de aplicações de um mesmo domínio podem ser rapidamente criadas a partir de um conjunto de artefatos reusáveis (arquitetura comum, componentes, framework, modelos, etc.).

Quando os membros de uma família de produtos possuem algumas características diferentes entre si, é utilizado o conceito de variabilidade para representar essas diferenças. A variabilidade é, então, a forma como os membros de uma família de produtos podem se diferenciar entre si.

Uma variabilidade possui pontos de variação e variantes. A cada ponto de variação está associado um conjunto de variantes. As variabilidades são resolvidas por meio da escolha de uma ou mais variantes do conjunto de variantes relacionado, seguindo restrições para esta resolução.

A literatura existente apresenta diversos tipos de abordagens de gerenciamento de variabilidade, desde baseadas em UML até em linguagens de domínio específico. Este artigo adota a linguagem Common Variability Language (CVL) para exemplificar a representação de variabilidades por meio da sua aplicação prática e em seguida é comparada à abordagem Stereotype-based Management of Variability (SMarty), que possui a UML como base para a representação de variabilidades em LPSs.

A Linguagem Common Variability Language (CVL)

A linguagem CVL foi proposta para a Object Management Group (OMG) como uma tentativa de criar uma definição de padronização de variabilidade para software-intensive systems, e é definida em sua especificação como uma linguagem de domínio independente para especificar e resolver variabilidade.

A especificação de CVL inclui um metamodelo, semântica e sintaxe concreta para a modelagem de variabilidades. A CVL permite que as variabilidades de uma LPS sejam descritas por meio de um modelo de possíveis escolhas, as relações entre essas escolhas e um modelo base. A Figura 1 apresenta uma visão geral da linguagem CVL, bem como a terminologia associada. O modelo base em CLV é uma instância de qualquer metamodelo em conformidade com Meta-Object Facility (MOF).

Visão geral e terminologia
associada à CVL

Figura 1. Visão geral e terminologia associada à CVL.

De acordo com a padronização CVL, a linguagem deve suportar os mecanismos mais comuns de variabilidade, como as restrições sobre as variabilidades e os mecanismos de abstração que suportam a definição e a aplicação das especificações de variabilidade. Logo, CVL visa especificar as variabilidades independentemente do modelo base sobre o qual as variabilidades são aplicadas.

CVL possui uma atividade denominada execução CVL (Figura 1) que produz modelos resolvidos para cada produto específico de uma LPS. Estes são especificados na mesma linguagem que o modelo base foi especificado (ex. UML e SysML) de uma LPS. Assim, as mesmas ferramentas utilizadas para a modelagem dos modelos base podem ser utilizadas para os resolvidos.

Para que os modelos de produtos específicos sejam materializados, a execução CVL toma como entrada:

· Um modelo base para a modelagem dos principais elementos de uma LPS. Esse modelo deve ser representado em uma linguagem MOF;

· Um modelo de variabilidades que é um modelo com elementos CVL para especificar variabilidades nos elementos do modelo base;

· Um conjunto de modelos de resolução que complementam o modelo de variabilidades com um conjunto de possíveis resoluções do modelo de variabilidades;

A Figura 2 mostra um modelo SysML de uma impressora com variabilidades. A parte superior da imagem mostra a variabilidade expressa em quatro pontos de variação, sendo:

· Três deles do tipo Object Existence (:ObjectExistence), indicando que os elementos do modelo poderão ser removidos durante o processo de derivação de produtos;

· Um ponto de variação do tipo Slot Value Assignment (:SlotValueAssignment), indicando que o valor threshold dentro do bloco EmgPower deve receber algum valor do modelo de resolução.

O exemplo da Figura 2 foi projetado sabendo que qualquer impressora poderá possuir ou não uma fonte de alimentação de emergência e, também, poderá possuir ou não um conector de alta velocidade. Tais características são expressas com uma árvore de especificação de variabilidades CVL (VSpec Tree).

Os VSpecs da árvore podem ser mapeados para um elemento do modelo base. Para esse mapeamento, um ponto de variação que está ligado a um elemento do modelo base é vinculado a um VSpec.

A definição de um modelo de variabilidades e o modelo base SysML compõem um modelo de LPS de acordo com CVL para o exemplo da Figura 3. Para gerar a materialização (materialization) de um produto da LPS é necessário um modelo de resolução, que resolve as VSpecs.

Sistema de Impressora -
Pontos de Variação em CVL sobre um Modelo Base MysML
abrir imagem em nova janela

Figura 2. Sistema de Impressora - Pontos de Variação em CVL sobre um Modelo Base SysML.

A Figura 3 exibe o ciclo CVL completo. Na parte superior está a VSpec Tree. Do lado direito da VSpec está o modelo de resolução com os valores que serão atribuídos para cada VSpec. Os pontos de variação no centro dessa figura estão vinculados ao modelo base SysML e aos VSpecs, sendo o mapeamento do modelo de resolução. No canto inferior direito temos a materialização de um produto específico, gerado após a atividade CVL Execution.

Existem quatro tipos de elementos em uma VSpec:

· Escolhas (Choices): são representados por retângulos com bordas arredondas. Sua resolução indica se um elemento deve ser removido ou não do modelo base durante a materialização;

· Variáveis (Variables): são representadas por uma elipse e recebem valores do modelo de resolução conforme o tipo da variável. Estes valores são atribuídos ao modelo base durante a materialização;

· Classificador de Variabilidade (Variability Classifiers - VClassifier): representam uma VSpec cuja resolução significa a criação de instâncias. Cada VClassifier tem uma “multiplicidade de instância” (instance multiplicity) que indica quantas instâncias desse VSpec devem ser criadas durante a materialização;

· VSpec Composto (Composite VSpec - CVSpec): é representado por um retângulo tracejado e é uma VSpec cuja resolução requer a resolução de um conjunto de VSpecs, identificados por meio do seu tipo, que é uma interface de variabilidades (variability interface). Tal interface nada mais é do que uma coleção de VSpecs que podem ser organizadas em estruturas de árvore.

Modelo de variabilidade, modelo de resolução e materialização
abrir imagem em nova janela

Figura 3. Modelo de variabilidade, modelo de resolução e materialização.

A LPS Arcade Game Maker

A Arcade Game Maker (AGM) é uma LPS pedagógica para jogos criada pelo SEI (Software Enigneering Institute) para apoiar o aprendizado e a experimentação de conceitos de LPS. É uma LPS não-comercial, que possui classes e código-fonte para os jogos Pong, Bowling e Brickles. Possui também um conjunto de documentos e modelos UML.

A AGM possui alguns artefatos essenciais, como: o modelo de características, o modelo de casos de usos, o modelo de classes e a arquitetura lógica de componentes. A Figura 4 apresenta o modelo de casos de uso da LPS AGM.

Modelo de casos de uso da
LPS AGM
abrir imagem em nova janela

Figura 4. Modelo de casos de uso da LPS AGM .

A seguir é apresentada a descrição dos casos de uso exibidos na Figura 4:

1. GamePlayer: ator responsável por executar as principais ações de um jogo produzido pela AGM;

2. GameInstaller: ator responsável por ações de configuração dos jogos (instalação e desinstalação) produzidos pela AGM;

3. Check Previous Best Score: verifica e apresenta a melhor pontuação registrada anteriormente;

4. Save Score: salva a pontuação corrente do jogador;

5. Save Game: salva o jogo em andamento;

6. Install Game: instala o jogo escolhido;

7. Exit Game: encerra o jogo em andamento;

8. Uninstall Game: remove o jogo selecionado;

9. Play Selected Game: um ator seleciona o jogo e inicia a sua execução;

10. Play Bowling: inicia o jogo Bowling;

11. Play Brickles: inicia o jogo Brickles;

12. Play Pong: inicia o jogo Pong;

13. Animation Loop: executa as ações de animação dos jogos;

14. Initialization: inicializa o jogo selecionado e apresenta o GameBoard.

Na próxima seção, o modelo de casos de uso será utilizado como modelo base para uma aplicação da linguagem CVL.

CVL aplicada ao modelo de casos de uso da AGM

O modelo de casos de uso da AGM, ilustrado na Figura 4, é utilizado como modelo base para a aplicação prática de CVL.

A partir dele foi desenvolvida uma representação da árvore VSpec em CVL, conforme a Figura 5.

No topo da imagem há uma VSpec do tipo Choice. Save score e Check score são opcionais, porém estão com linha contínua pois não são do tipo Choice e sim do tipo VClassifier. A multiplicidade [0..1] indica a quantidade mínima e máxima de instâncias que devem ser criadas para um produto especifico. Save Game, Exit Game, Install Game e Uninstall Game são obrigatórios.

O ponto de variação Play Selected Game é representado por um retângulo com bordas arredondadas, sendo uma VSpec do tipo Choice (Escolha). A linha contínua indica que Play Selected Game é obrigatória quando uma instância da AGM for criada

O triângulo vazio com a marcação “1..3” representa a operação OR, indicando que no mínimo 1 e no máximo 3 das VSpecs Play Brickles, Play Pong e Play Bowling podem ser escolhidas. A linha tracejada significa que não são obrigatórias.

As VSpecs Initialization e Animation Loop são obrigatórias e, por isso, estão relacionadas com uma linha continua. É importante notar que, caso a VSpec relacionada não seja do tipo Choice, a linha será sempre continua.

Após a criação da árvore VSpec para o modelo de casos de uso da AGM foi desenvolvido um modelo de resolução, que ilustra as seleções na AGM (Figura 5). Tal modelo não possui valores (True/False) associados neste momento.

Modelo de resolução associado
às VSpecs AGM

abrir imagem em nova janela

Figura 5. Modelo de resolução associado às VSpecs AGM.

As VSpecs Save Score e Check Previous Score, Play Brickles, Play Bowling e Play Pong estão associadas com o modelo de resolução, pois são as VSpecs que podem ser escolhidas para a criação de uma instância de AGM.

A Figura 6 apresenta a árvore de VSpecs e o modelo de resolução, que estavam presentes na Figura 5, além dos pontos de variação (Variation Points) e do modelo base apresentado pelo diagrama de casos de uso da AGM em UML.

Na parte inferior da Figura 7 está o modelo Base (Modelo de Casos de Uso da AGM). No centro da figura foram definidos cinco pontos de variação CVL do tipo Object Existence, que estão relacionados aos elementos do modelo base que podem ser selecionados (Check Previous Best Score, Save Score, Play Brickles, Play Pong e Play Bowling).

Uma vez que o modelo de variabilidades está relacionado com as VSpecs e com os elementos do modelo base, é possível colocar em execução a atividade CVL Execution, permitindo a materialização de produtos.

A Figura 7 apresenta um exemplo de materialização de um produto específico da AGM para os jogos Pong e Bowling. Tal materialização é possível por causa do modelo de resolução que define, neste momento, valores True/False para um produto específico.

relacionamento entre o
modelo de variabilidades (pontos de variação CVL), modelo base e VSpecs

abrir imagem em nova janela

Figura 6. Relacionamento entre o modelo de variabilidades (pontos de variação CVL), modelo base e VSpecs.

 Materialização de um produto
específico AGM contendo os jogos
abrir imagem em nova janela

Figura 7. Materialização de um produto específico AGM contendo os jogos Pong e Bowling.

A AGM de acordo com a abordagem SMarty

Esta seção apresenta a geração de um modelo de variabilidades para casos de uso para o diagrama de caso de uso (Figura 4) de acordo com as diretrizes da abordagem SMarty.

A abordagem SMarty é composta de um perfil UML 2.0, com um conjunto de estereótipos e meta atributos – chamado SMartyProfile – que permite identificar as diferentes variabilidades de uma LPS, bem como os elementos comuns. Adicionalmente, SMarty possui um processo, o SMartyProcess.

Este processo auxilia o usuário, por meio de diretrizes específicas para cada modelo UML (casos de uso, classe, sequencia, componentes e atividades), a aplicarem os diferentes elementos existentes no SMartyProfile. Neste contexto, as seguintes diretrizes, para diagramas de caso de uso, foram consideradas para gerar a Figura 8:

· Play Selected Game está relacionado através do estereótipo <<extend>> com três casos de uso, Play Brickles, Play Pong e Play Bowling. Dessa forma, por meio da diretriz D.1 da abordagem SMarty temos:

o Play Selected Game é um ponto de variação, pois é o caso de uso estendido no relacionamento;

o Play Brickles, Play Pong e Play Bowling são variantes inclusivas, pois são os casos de uso que estendem, sendo marcados com o estereótipo <<alternative_OR>, uma vez que o usuário pode selecionar qualquer combinação de um, dois ou três jogos.

A diretriz D.5 sugere que o caso de uso Check Previous Best Score dependa do caso de uso Save Score, pois a associação entre eles está marcada com o estereótipo <<requires>>.

Os casos de uso Initialization e Animation Loop associados aos casos de uso Play Brickles, Play Pong e Play Bowling por meio de <<include>> e marcados como <<mandatory>> são considerados como variantes obrigatórias, de acordo com a diretriz D.3.

Essa diretriz ainda sugere que os casos de uso Check Previous Best Score, Save Score, Save Game, Exit Game, Install Game e Uninstall Game sejam variantes, pois estão associadas aos atores GamePlayer e/ou GameInstaller, sendo os dois primeiros opcionais, pois estão marcados como <<optional>>, e os quatro últimos obrigatórios, uma vez que estão marcados como <<mandatory>>.

Modelo de Casos de Uso da
AGM de acordo com SMarty
abrir imagem em nova janela

Figura 8. Modelo de Casos de Uso da AGM de acordo com SMarty.

Comparação da modelagem de variabilidade com CVL e Smarty

Uma vez realizada a aplicação de CVL à LPS AGM, podem-se elencar alguns pontos interessantes de discussão com relação à modelagem de variabilidades com CVL e SMarty. São eles:

· Modelo Base Suportado. CVL permite o uso de qualquer modelo base que possa ser definido por meio do metamodelo MOF. SMarty suporta modelos UML, porém algumas extensões para SysML, por exemplo, fornecem indícios da possibilidade de ser aplicada a outros modelos UML;

· Tipo de Elemento Modelado. CVL define elementos próprios para a modelagem de variabilidades como, por exemplo, VSpecs e pontos de variações próprios o que torna a linguagem independente do modelo base usado. SMarty, porém, se restringe ao uso de estereótipos em modelos base UML;

· Processo de Apoio à Aplicação da Linguagem/Abordagem. CVL não fornece um processo documentado de como deve ser feita a aplicação dos elementos que compõem a linguagem. O documento ainda não oficialmente divulgado pela OMG apresenta a especificação dos elementos que compõem CVL com exemplos simples. SMarty, por meio do SMartyProcess, fornece um conjunto de diretrizes que guiam o usuário na identificação e representação de variabilidades;

· Rastreabilidade. CVL não apresenta elementos explícitos que permitem a rastreabilidade em diferentes níveis de modelos base utilizados. SMarty, por meio do meta-atributo realizes do estereótipo variability, permite rastrear diferentes níveis do modelo base UML usado;

· Criação de Modelos de Variabilidade Complementares. CVL exige a criação de dois modelos, além do modelo base, para que o processo de materialização possa ocorrer: (1) modelo de variabilidades, contendo os VSpecs organizados em árvores, e (2) os modelos de resolução.

Tais modelos são simples de serem criados e tornam CVL independente do modelo base. Já SMarty não exige a criação de nenhum modelo complementar. As variabilidades são anotadas na forma de estereótipos no modelo base UML;

· Suporte Ferramental para Representação de Variabilidade. CVL, por exigir a criação de modelos complementares e que são próprios à linguagem, exige o uso de ferramentas específicas. Para tanto, existem duas ferramentas: um plugin para Eclipse chamado CVL Tool do SINTEF e o aplicativo CVL 2 Tool. SMarty, por sua vez, pode ser apoiada por qualquer ferramenta UML que permita a definição de novos estereótipos ou a incorporação do SMartyProfile;

· Suporte Automatizado para a Geração de Produtos Específicos. CVL, por meio do plugin CVL Tools do SINTEF, permite a geração de instâncias de modelos base utilizados. SMarty por sua vez não possui suporte a essa atividade.

A Tabela 1 apresenta um resumo da modelagem com CVL e SMarty.

Critério

CVL

SMarty

Modelo Base

Qualquer DSL segundo MOF

UML e extensões

Tipo de Elemento Modelado

VSpecs

Pontos de Variação

Estereótipos UML

Processo de Apoio à Modelagem

Não possui

SMartyProcess com diretrizes

Rastreabilidade

Não suporta

Por meio do estereótipo <<realizes>>

Modelos de Variabilidade Complementares

VSpecs, modelo de variabilidade com pontos de variação e modelo de resolução

Não são necessários

Ferramental para Modelar Variabilidade

Plugin CVL Tool do SINTEF para Eclipse e CVL 2 Tool

Qualquer ferramenta de modelagem UML

Ferramental para a Geração de Produtos

Plugin CVL Tool do SINTEF para Eclipse

Não possui

Tabela 1. Resumo da Modelagem da LPS AGM com CVL e SMarty.

Gerenciamento de variabilidades é uma das atividades técnicas mais importantes do controle de uma LPS. Várias abordagens têm sido propostas nos últimos anos. Neste trabalho foi estudada a linguagem CVL por meio da sua aplicação à LPS AGM.

CVL foi aplicada aos modelos de casos de uso da AGM com o objetivo de ilustrar como os elementos CVL são criados e como esses se relacionam.

Para tanto, VSpecs CVL foram criadas para os principais elementos AGM, bem como um modelo de variabilidades e um modelo de resolução para casos de uso. Com base nesses modelos foi possível materializar (gerar) instâncias (produtos específicos) do modelo base.

Além de aplicar CVL à LPS AGM, foi realizada uma comparação da modelagem com a linguagem CVL e com a abordagem SMarty com relação a vários critérios como apoio automatizado, necessidade de criação de modelos complementares e rastreabilidade.

A adoção de CVL, SMarty ou outras abordagens de gerenciamento de variabilidades existentes apoiam a melhora na qualidade e, consequentemente, a obtenção dos diversos benefícios obtidos pela adoção de LPS.

A aplicação destas de modo conciso torna-se, portanto, parte essencial para a adoção de metodologias relevantes no contexto industrial ou acadêmico para a composição de diferentes artefatos e, assim, na geração final de produtos provenientes da linha corretamente.

Referências

· Marcolino, A.; Oliveira Junior, E. A.; Gimenes, I. M. S.; Maldonado, J. C. Towards the Eectiveness of a Variability Management Approach at Use Case Level. In: Proc. of the Int. Conf. on Software Engineering & Knowledge Engineering, 2013, p. 214-219.

· Oliveira Junior, E. A.; Gimenes, I. M. S.; Maldonado, J. C. Systematic Management of Variability in UML-based Software Product Lines. Journal of Universal Computer Science (Print), v. 16, p. 2374-2393, 2010.

· Rouillé, E.; Combemale, B.; Barais, O.; Touzet, D.; Jézéquel, Jm. Leveraging CVL to Manage Variability in Software Process Lines. 9th Asia-Pacific Software Engineering Conference (APSEC 2012), Hong Kong, 2012.

· Haugen, Ø. Common Variability Language (CVL) - OMG Revised Submission. 2012.

· SEI Software Engineering Institute Arcade Game Maker Pedagogical Product Line, 2010.

Sugestão de conteúdo