dos requisitos à arquitetura em linhas de produtos de ... · minha mãe, mércia, minhas tias e...
TRANSCRIPT
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
CENTRO DE CIÊNCIAS EXATAS E DA TERRA
DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA
PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO
Dissertação de Mestrado
Dos Requisitos à Arquitetura em Linhas de Produtos
de Software: Uma Estratégia de Transformações
entre Modelos
Keivilany Janielle de Lima Coelho
Natal / RN
Janeiro de 2012
KEIVILANY JANIELLE DE LIMA COELHO
Dos Requisitos à Arquitetura em Linhas de Produtos
de Software: Uma Estratégia de Transformações
entre Modelos
Dissertação de mestrado submetida à banca exa-
minadora como requisito parcial para obtenção do
título de mestre em Sistemas e Computação da
Universidade Federal do Rio Grande do Norte.
Profª. Drª. Thaís Vasconcelos Batista
Orientadora
Natal / RN
Janeiro de 2012
Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial
Especializada do Centro de Ciências Exatas e da Terra – CCET.
Coelho, Keivilany Janielle de Lima.
Dos requisitos à arquitetura em linhas de produtos de software: uma estratégia
de transformações entre modelos / Keivilany Janielle de Lima Coelho. – Natal, RN,
2012.
107 f. : il.
Orientador: Profa. Dra. Thaís Vasconcelos Batista.
Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro
de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada.
Programa de Pós-Graduação em Sistemas e Computação.
1. Programa de computador (Software) – Dissertação. 2. Arquitetura de softwa-
re – Dissertação. 3. Rastreamento – Dissertação. 4. Mapeamento – Dissertação. 5.
Desenvolvimento dirigido por modelos I. Batista, Thaís Vasconcelos. II. Título.
RN/UF/BSE-CCET CDU 004.4
Agradecimentos
Ninguém faz nada sozinho. E não poderia ser diferente, nesse momento tão crucial da
minha jornada. Não estive sozinha em momento algum desse processo, mesmo quando, fisi-
camente, éramos somente eu e o meu computador.
A Deus, que me capacita, abre meu entendimento para compreender o complexo, me
fortalece quando quero esmorecer e me renova, quando estou quase desistindo.
Agradeço também a meus familiares, pelo suporte, pela torcida, pelas orações, pela
presença, pelas palavras de força. Minha mãe, Mércia, minhas tias e primas, meu pai, minhas
avós: muito obrigada!
Ao meu filho Gabriel, pela (im) paciência com minhas ausências e longos períodos no
computador. Isso foi por nós dois, meu filho, acredite. Você é o mais importante pra mim,
sempre será.
A Rodrigo, pela ajuda contundente no mestrado, neste trabalho e na vida.
Aos colegas do Consiste, pela assistência e disponibilidade. E a Lidiane Oliveira, por
tudo! Devo muito disto aqui a você!
Agradeço, também, aos professores do DIMAP-UFRN, por compartilhar seus precio-
sos conhecimentos e pelas contribuições. Muito obrigada à professora Lyrene e ao professor
Uirá, por me ajudar a tornar meu trabalho melhor. E a Nélio Cacho, pelo encaminhamento
que me conduziu até aqui, grata!
Agradeço à minha orientadora Thais, pela orientação sempre presente, objetiva, pelas
oportunidades e pela paciência com os meus momentos difíceis.
Por fim, agradeço ao CNPQ, por acreditar neste projeto, nos concedendo o suporte fi-
nanceiro imprescindível para o nosso sucesso.
“O que torna a vida lúgubre é a ausência
de motivação. O que a torna complicada é
a multiplicidade de motivações. O que
torna a vida vitoriosa é a singularidade
da motivação.”
(George Eliot)
Resumo
O rastreamento entre modelos das atividades de requisitos e arquitetura é uma estra-
tégia que busca evitar a perda de informações, reduzindo o gap entre essas duas ati-
vidades iniciais do ciclo de vida do software. No contexto das Linhas de Produto de
Software (LPS), é importante que haja um suporte a esse rastreamento, que permita
a correspondência entre as duas atividades, com um gerenciamento satisfatório das
variabilidades. Buscando atender a essa questão, este trabalho apresenta um proces-
so de mapeamento bi-direcional, definindo regras de transformação entre elementos
de modelo de requisitos orientado a objetivos (descrito em PL-AOVgraph) e ele-
mentos de descrição arquitetural (definida em PL-AspectualACME). Essas regras de
mapeamento são avaliadas em um estudo de caso: a LPS Ginga ForAll. Para auto-
matizar essa transformação, implementamos a ferramenta MaRiPLA (Mapping Re-
quirements to Product Line Architecture), através de técnicas do desenvolvimento
dirigido a modelos (Model-driven Development – MDD), incluindo a linguagem de
transformações entre modelos Atlas Transformation Language (ATL) – com especi-
ficação de metamodelos do tipo Ecore – em conjunto com os frameworks Xtext, de
definição DSL, e Acceleo, de geração de código, em ambiente Eclipse. Por fim, os
modelos gerados são avaliados, com base em atributos de qualidade como variabili-
dade, derivabilidade, reusabilidade, corretude, rastreabilidade, completude, evoluti-
bilidade e manutenibilidade, extraídos do Modelo de Qualidade CAFÉ.
Palavras-chave: Linhas de Produto de Software, Transformações entre modelos,
MDD, ATL, Xtext, Acceleo, PL-AspectualACME, PL-AOVgraph, MaRiPLA
Abstract
The tracking between models of the requirements and architecture activities
is a strategy that aims to prevent loss of information, reducing the gap between
these two initial activities of the software life cycle. In the context
of Software Product Lines (SPL), it is important to have this support, which al-
lows the correspondence between this two activities, with management of variabili-
ty. In order to address this issue, this paper presents a process of bi-
directional mapping, defining transformation rules between elements of a goal-
oriented requirements model (described in PL-AOVgraph) and elements of an arc-
hitectural description (defined in PL-AspectualACME). These mapping rules are
evaluated using a case study: the GingaForAll LPS. To automate this transforma-
tion, we developed the MaRiPLA tool (Mapping Requirements to Prod-
uct Line Architecture), through MDD techniques (Model-
driven Development), including Atlas Transformation Language (ATL) –
with specification of Ecore metamodels – jointly with Xtext , a DSL definition
framework, and Acceleo, a code generation tool, in Eclipse environment. Finally,
the generated models are evaluated based on quality attributes such as variabili-
ty, derivability, reusability, correctness, traceability, completeness, evolvability and
maintainability, extracted from the CAFÉ Quality Model.
Keywords: Software Product Lines, Model Transformations, MDD, ATL, Xtext,
Acceleo, PL-AspectualACME, PL-AOV-Graph, MaRiPLA
Sumário
1.Introdução ................................................................................................................. 14
1.1 Motivação ................................................................................................... 16
1.2 Objetivos ..................................................................................................... 17
1.3 Estrutura do trabalho ................................................................................... 18
2. Fundamentação Teórica ......................................................................................... 19
2.1 Linhas de Produtos de Software e Modelos de Features .............................. 19
2.2 Modelos de Metas ....................................................................................... 20
2.3 Linguagens de Descrição Arquitetural ......................................................... 22
2.4 Transformações entre Modelos com MDD e ATL ....................................... 26
2.5 Tecnologias Utilizadas ................................................................................ 28
2.5.1 Linguagem de Transformações ATL ...................................................... 28
2.5.2 Xtext ..................................................................................................... 30
2.5.3 Acceleo ................................................................................................. 31
2.6 A Linha de Produtos Ginga ForAll .............................................................. 32
2.6.1 PL-AOVgraph do Ginga ForAll............................................................. 34
2.6.2 Descrição Arquitetural do Ginga ForAll ................................................ 35
3. Processo de Mapeamento entre Modelo de Metas e Descrição Arquitetural ............ 39
3.1 Processo de Mapeamento ............................................................................ 39
3.2 Regras de Mapeamento ............................................................................... 40
4. MaRiPLA .............................................................................................................. 45
4.1 Apresentação e Descrição da Ferramenta ..................................................... 45
4.2 Detalhes da Implementação ......................................................................... 46
4.2.1 Transformações Modelo a Modelo (M2M) ............................................ 46
4.2.2 Transformações Texto a Modelo (T2M) ................................................ 49
4.2.3 Transformação Modelo a Texto (M2T) .................................................. 52
4.2.4 Integração dos Projetos .......................................................................... 53
5. Avaliação dos Resultados....................................................................................... 56
5.1 O Modelo de Qualidade CAFÉ .................................................................... 56
5.2 Avaliação da Descrição PL-AspectualACME gerada a partir de PL-
AOVgraph ........................................................................................................... 57
5.3 Avaliação da Descrição PL-AOVgraph gerada a partir de PL-
AspectualACME .................................................................................................. 58
6. Trabalhos Relacionados ......................................................................................... 62
6.1 FArM (Sochos et al, 2006) .......................................................................... 62
6.2 A Metamodeling Approach to Tracing Variability between Requirements and
Architecture in Software Product Lines (Moon et al, 2007) .................................. 63
6.3 A Model Transformation Approach to Derive Architectural Models from
Goal-Oriented Requirement Models (Lucena, 2010) ............................................ 64
6.4 MaRiSA-MDD (Medeiros, 2008) ................................................................ 65
6.5 ReqSys (Santos, 2010) e ReqSys-MDD ....................................................... 65
7. Conclusão .............................................................................................................. 66
7.1 Contribuições .............................................................................................. 66
7.2 Trabalhos Futuros........................................................................................ 67
Referências ................................................................................................................... 69
Apêndice I – Gramática Xtext do PL-AOVgraph .......................................................... 72
Apêndice II – Gramática Xtext do PL-AspectualACME ............................................... 75
Apêndice III – Script de Templates Acceleo para PL-AOVgraph .................................. 79
Apêndice IV – Script de Templates Acceleo para PL-AspectualACME ........................ 81
Apêndice V – Regras ATL para Transformações de PL-AOVgraph em PL-
AspectualACME........................................................................................................... 84
Apêndice VI – Regras ATL para Transformações de PL-AspectualACME em PL-
AOVgraph .................................................................................................................... 97
Apêndice VII – Descrição PL-AspectualACME gerada a partir de PL-AOVgraph ...... 103
Apêndice VIII – Descrição PL-AOVgraph gerada a partir de PL-AspectualACME ..... 107
Lista de Figuras
Figura 1: Modelo de Features ................................................................................... 20
Figura 2: Metamodelo de PL-AOVgraph .................................................................. 21
Figura 3: Modelo de Metas PL-AOVgraph ............................................................... 21
Figura 4: Attachments entre conector aspectual e conectores regulares em
AspectualACME ...................................................................................................... 23
Figura 5: Metamodelo de PL-AspectualACME ......................................................... 25
Figura 6: Exemplo PL-AspectualACME ................................................................... 26
Figura 7: Processo Geral de Transformação de Modelos ........................................... 27
Figura 8: Processo de Transformações com ATL ...................................................... 28
Figura 9: Exemplo da Ferramenta ATL ..................................................................... 29
Figura 10: Editor de Gramática e Editor de Linguagem, no Xtext ............................. 30
Figura 11: Exemplo Acceleo ..................................................................................... 31
Figura 12: Diferentes plataformas de transmissão de sinal de TV Digital .................. 32
Figura 13: Modelo de features do Ginga ForAll ........................................................ 33
Figura 14: Descrição PL-AOVgraph do Ginga ForAll (trecho) ................................. 34
Figura 15: PL-AspectualACME do Ginga ForAll (trecho) ........................................ 37
Figura 16: Processo de mapeamento entre PL-AOVgraph e PL-AspectualACME ..... 39
Figura 17: Transformação de elementos PL-AOVgraph em elementos PL-
AspectualACME ...................................................................................................... 43
Figura 18: Trecho de regra de transformação ATL .................................................... 44
Figura 19: Arquitetura da ferramenta MaRiPLA ....................................................... 45
Figura 20: Projeto ATL............................................................................................. 47
Figura 21: Modelos .xmi do Ginga ForAll em PL-AOVgraph e PL-AspectualACME48
Figura 22: Modelos .genmodel e pacotes gerados ..................................................... 50
Figura 23: Projetos Xtext de PL-AOVgraph e PL-AspectualACME .......................... 51
Figura 24: Projetos Acceleo de PL-AOVgraph e PL-AspectualACME...................... 52
Figura 25: Menu da ferramenta MaRiPLA ................................................................ 53
Figura 26: Interação com usuário para opção de selecionar arquivo de entrada ......... 53
Figura 27: Seleção do arquivo de entrada .................................................................. 54
Figura 28: Geração de PL-AspectualACME a partir de PL-AOVgraph ..................... 54
Figura 29: Geração de PL-AOVgraph a partir de PL-AspectualACME ..................... 55
Figura 30: Rastreamento do Conector Aspectual de PL-AspectualACME para o
relacionamento transversal de PL-AOVgraph ........................................................... 60
Lista de Tabelas
Tabela 1: Relação de dependências entre features do Ginga ForAll........................... 34
Tabela 2: Regras de mapeamento entre PL-AOVgraph e PL-AspectualACME ......... 41
Lista de Abreviaturas e Siglas
ADL – Architectural Description Language
ADT – ATL Development Tools
ATL – Atlas Transformation Language
BNF – Backus-Naur Form
DSL – Domain Specific Language
DSOA – Desenvolvimento de Software Orientado a Aspectos
EMF – Eclipse Modelling Framework
FArM – Feature-Archtecture Mapping
FODA – Feature-Oriented Analysis Method
KM3 – Kernel MetaMetaModel
LPS – Linha de Produto de Software
MaRiSA – Mapping Requirements to Software Architecture
MaRiPLA – Mapping Requirements to Product Line Architecture
MDD – Model Driven Development
MOF – Meta-Object Facility
M2M – Model to Model
M2T – Model to Text
OCL – Object Constraint Language
RAS – Reusable Asset Specification
TCS – Textual Concrete Syntax
T2M – Text to Model
UML – Unified Modelling Language
XHTML – eXtensible Hypertext Markup Language
XMI – XML Metadata Interchange
14
1. Introdução
No desenvolvimento de software, segundo Nuseibeh e Easterbrook (2000), a principal
medida de sucesso de um sistema é o grau em que ele se alinha ao propósito para o qual foi
idealizado. A Engenharia de Requisitos (Thayer e Dorfman, 1997) tem papel importante na
busca desse alinhamento, utilizando-se de diversas estratégias de identificação, modelagem,
análise, evolução e validação.
Para a modelagem de requisitos, uma estratégia comumente usada são os modelos de
metas (Giorgini et al, 2002), que permitem representar não só os requisitos funcionais, como
também os objetivos de negócio e atributos de qualidade de software, através de decomposi-
ção de metas. O modelo de metas V-Graph (Yu et al, 2004) apresenta três elementos (softme-
tas, metas e tarefas) organizados em árvores and/or, com possíveis relacionamentos entre es-
ses elementos (make, help, unknown, hurt e break) e permite a descrição de nós intencionais
(metas e softmetas) e nós operacionais (tarefas). Porém, apesar dessas vantagens na modela-
gem de requisitos, V-Graph não oferece suporte à separação de elementos que podem estar
entrelaçados e espalhados em diferentes dimensões das características do software (elementos
transversais). Para resolver esse problema, em Silva (2006), é apresentado AOV-Graph, uma
extensão do modelo V-Graph para dar suporte a relacionamentos transversais nos estágios
iniciais do desenvolvimento de software (EA, 2011). AOV-Graph, porém, não trata da mode-
lagem de variabilidades, um conceito amplamente difundido na atualidade, em virtude do uso
cada vez mais frequente de Linhas de Produtos de Software (LPS) como técnica de reuso de
software.
No universo das LPS, o gerenciamento de requisitos inicia-se, normalmente, com a
modelagem das variabilidades, através dos modelos de features (Kang et al, 1990), que são
diagramas de features com informações adicionais sobre descrições de features e regras de
relacionamento. Nesses modelos, são representados os requisitos de LPS, através de features
obrigatórias, opcionais e alternativas.
Para aplicar o gerenciamento de variabilidades na atividade de requisitos de LPS, San-
tos (2010) propôs a integração entre modelos de features e modelos de metas, e apresentou
PL-AOVgraph. PL-AOVgraph é um modelo de metas que estende AOV-Graph para o domí-
nio de LPS, permitindo, assim, que se expressem, além de requisitos e relacionamentos trans-
versais, as variabilidades.
15
Além do gerenciamento dos requisitos, outra atividade do ciclo de vida do software
merece atenção nos estágios iniciais do desenvolvimento: a definição da arquitetura do soft-
ware (Shaw e Garlan, 1993). É nessa etapa que é descrita a estrutura e o comportamento do
sistema, bem como as propriedades do software que conduzem à sua implementação e evolu-
ção. Descrever a arquitetura antes de iniciar a construção do sistema permite uma melhor
compreensão do sistema e favorece a detecção prematura de eventuais falhas no design, redu-
zindo significativamente os custos para correção. Uma das formas comumente usadas para
descrever arquiteturas de software são as Linguagens de Descrição Arquitetural (Architectural
Description Languages - ADL) (Clements, 1996), que descrevem os elementos arquiteturais
em termos de componentes e as relações entre eles através de conectores. Dentre diversas
ADLs, pode-se destacar a ADL ACME (Garlan et al, 1997), por ser uma ADL de propósito
geral, que fornece um formato de intercâmbio para ferramentas e ambientes de desenvolvi-
mento arquiteturais, fornecendo uma base para o desenvolvimento de novas ADLs (de domí-
nio específico), e incluindo suporte à extensibilidade.
Batista et al (2006) propuseram uma extensão à ADL ACME, com suporte a intera-
ções transversais, chamada de AspectualACME, que foi estendida posteriormente para descri-
ção de arquiteturas de LPS em Adachi (2009) e Adachi et al (2011), dando origem a PL-
AspectualACME. Essa extensão não acrescentou novos elementos, apenas enriqueceu seman-
ticamente elementos existentes da linguagem, para oferecer suporte à variabilidade.
Para reduzir o gap entre as atividades de requisitos e arquitetura de software e evitar a
perda de informações na passagem de uma atividade para outra, há um investimento atual no
uso de técnicas de rastreamento entre as duas atividades, através do mapeamento entre ele-
mentos dos modelos que as representam. Muitos, porém, não abrangem o universo das LPS
ou, quando abrangem, não automatizam esse mapeamento através de uma ferramenta (algu-
mas dessas estratégias são brevemente descritas no Capítulo 6, Trabalhos Relacionados).
Uma ferramenta existente, que realiza esse rastreamento, é MaRiSA-MDD (Medeiros,
2008). Essa ferramenta realiza transformações bidirecionais, dirigidas a modelos, entre AOV-
Graph e AspectualACME, utilizando a linguagem de transformações Atlas Transformation
Language – ATL (ATL, 2006), para as transformações entre modelos, e o mecanismo Textual
Concrete Syntax – TCS (TCS, 2006), para a manipulação de descrições textuais. Abordamos
MaRiSA na seção 6.4 deste trabalho.
O objetivo deste trabalho é estender MaRiSA-MDD, integrando as atividades de defi-
nição de requisitos e arquitetura de LPS, epropor MaRiPLA (Mapping Requirements to Pro-
duct Line Architecture), uma estratégia de mapeamento bi-direcional entre modelo de metas,
16
descrito em PL-AOVgraph (obtido a partir de modelo de features) e descrição arquitetural,
em PL-AspectualACME. Esse mapeamento busca garantir a correspondência entre essas duas
atividades iniciais do desenvolvimento de LPS.
A fidelidade às tecnologias utilizadas em MaRiSA-MDD (ATL e TCS), no entanto,
não pôde ser garantida integralmente, em virtude da indisponibilidade do mecanismo TCS no
período da implementação do presente trabalho. MaRiPLA é, então, implementada utilizando
(como em MaRiSA) técnicas MDD e a linguagem de transformação ATL, para as transforma-
ções entre modelos. Porém, para a manipulação de descrições textuais, a ferramenta utiliza o
framework de definição de DSL Xtext (XTEXT, 2011) e o gerador de código Acceleo (AC-
CELEO, 2011). MaRiPLA, assim como MaRiSA, é implementada no ambiente Eclipse (E-
CLIPSE, 2011). Este trabalho define um processo e as regras de mapeamento entre os dois
modelos e aplica essas regras em um estudo de caso, a LPS Ginga ForAll (Saraiva et al,
2010).
Ao final, tem-se uma descrição arquitetural gerada a partir de modelo de metas, que é
avaliada com base nos atributos de qualidade, específicos de LPS, extraídos do Modelo de
Qualidade CAFÉ (Anastasopoulos e Bayer, 2002): variabilidade, derivabilidade, reusabilida-
de, corretude, rastreabilidade, completude, evolutibilidade e manutenibilidade..
1.1 Motivação
Na engenharia de LPS, com a obtenção da descrição arquitetural a partir de modelos
de metas, permite-se que tal arquitetura seja mais detalhada e consistente com os requisitos
especificados na atividade de definição de requisitos. A transformação entre modelos de me-
tas e descrição arquitetural de LPS é, portanto, importante para que as tomadas de decisão
nessas atividades (requisitos e arquitetura) sejam bem gerenciadas e haja maior correspondên-
cia entre elas e uma consequente diminuição do gap entre os modelos e artefatos produzidos
nessas duas atividades do processo de desenvolvimento de software.
Há, também, uma redução no esforço para a geração da arquitetura inicial da LPS e
um aumento na facilidade de manutenção da LPS, uma vez que a rastreabilidade entre os dois
modelos permite melhor localização dos elementos alterados, em caso de mudanças nas espe-
cificações de um ou outro.
O mapeamento evita, também, a perda de informações importantes das atividades ini-
ciais, no momento da definição da arquitetura, beneficiando, também, as atividades subse-
quentes do desenvolvimento de software, uma vez que o projeto detalhado e a implementação
dependem de um modelo arquitetural que seja consistente com os requisitos.
17
1.2 Objetivos
O objetivo principal deste trabalho é definir e implementar transformações MDD entre
modelos de metas e descrição arquitetural para LPS, a fim de prover suporte ao rastreamento
entre requisitos e arquitetura de LPS. O modelo de metas utilizado na transformação é o PL-
AOVgraph, e a descrição arquitetural é descrita em PL-AspectualACME.
As transformações entre os modelos devem ocorrer de forma bidirecional, ou seja, de
PL-AOVgraph para PL-AspectualACME e vice-versa. As transformações automatizadas são
implementadas, nesse trabalho, em ambiente Eclipse (ECLIPSE, 2011), com ATL (ATL,
2006), Xtext (XTEX, 2011) e Acceleo (ACCELEO, 2011), dando origem à ferramenta MaRi-
PLA (Mapping Requirements to Product Line Architecture), uma extensão de MaRiSA-MDD
(Medeiros, 2008) para o universo de LPS.
Os objetivos específicos do trabalho incluem:
Definição do processo de mapeamento entre os modelos;
Definição das regras de mapeamento entre os modelos, estendendo a definição
de regras existente em MaRiSA-MDD;
Especificação dos metamodelos de PL-AOVgraph e PL-AspectualACME, no
ambiente Eclipse, estendendo os metamodelos de AOV-Graph e Aspectua-
lACME, respectivamente;
Especificação das transformações em ATL nas duas vias (goals2arch e ar-
ch2goals), em conformidade com os metamodelos previamente criados e es-
tendendo as regras atl existentes em MaRiSA-MDD;
Definição dos modelos para o estudo de caso escolhido, em conformidade com
os metamodelos previamente definidos;
Definição da gramática BNF de PL-AspectualACME e de PL-AOVgraph no
framework Xtext
Definição das especificações textuais de PL-AOVgraph e de PL-
AspectualACME do estudo de caso Ginga ForAll
Definição dos scripts de templates Acceleo nas duas linguagens
Realização das transformações texto a modelo (T2M) no Xtext, modelo a mo-
delo (M2M) no ATL e modelo a texto (M2T) no Acceleo
Integração das transformações em um Plug-in Eclipse
18
1.3 Estrutura do trabalho
O restante deste trabalho está estruturado da seguinte forma: o Capítulo 2 apresenta a
fundamentação teórica, com os conceitos básicos importantes para o trabalho – Linhas de
Produtos de Software, Modelos de Features, Modelos de Metas, Descrição Arquitetural para
LPS, Model-Driven Development – MDD, Linguagem de Transformações ATL, Xtext, Acce-
leo e a apresentação da LPS Ginga ForAll, nosso estudo de caso, com as respectivas descri-
ções PL-AOVgraph e PL-AspectualACME; o Capítulo 3 apresenta o processo de mapeamen-
to e a definição das regras de mapeamento entre PL-AOVgraph e PL-AspectualACME; no
Capítulo 4, apresentamos a ferramenta MaRiPLA, com a descrição e a arquitetura da ferra-
menta e os detalhes da implementação nos níveis modelo a modelo, texto a modelo e modelo
a texto, junto à integração em um plug-in; no Capítulo 5, apresentamos a avaliação dos resul-
tados obtidos com o estudo de caso; o Capítulo 6 traz os trabalhos relacionados e suas limita-
ções com relação ao presente trabalho; o Capítulo 7, por fim, apresenta a conclusão, contribu-
ições e idéias para trabalhos futuros. Há, ainda, os Apêndices, com modelos e descrições usa-
dos e/ou gerados neste trabalho.
19
2. Fundamentação Teórica
Este Capítulo apresenta os conceitos básicos importantes para a compreensão do traba-
lho. Na seção 2.1, discorremos sobre Linhas de Produto de Software e modelos de features,
como principal estratégia de modelagem de variabilidades na atividade de requisitos de LPS;
na seção 2.2, falamos sobre modelos de metas como alternativa para expressar requisitos, com
V-Graph e suas extensões AOV-Graph e PL-AOVgraph (este último com suporte a variabili-
dades); na seção 2.3, apresentamos a ADL ACME e suas extensões AspectualACME e PL-
AspectualACME (esta última para o domínio de LPS); na seção 2.4, abordamos o tema das
transformações entre modelos com MDD e ATL; na seção 2.5, descrevemos o funcionamento
das tecnologias utilizadas: a linguagem de transformações ATL, o framework de definição de
DSL Xtext, e a ferramenta Acceleo, para geração de código a partir de modelo; na seção 2.6,
explicamos a LPS Ginga ForAll, nosso estudo de caso, apresentando, em seguida, os trechos
de descrições em PL-AOVgraph e PL-AspectualACME do Ginga ForAll.
2.1 Linhas de Produtos de Software e Modelos de Features
Na engenharia de Linhas de Produtos de Software, o gerenciamento da variabilidade é
importante para reduzir os riscos inerentes ao desenvolvimento inicial de uma LPS (Linden,
2007). Essa variabilidade é expressa através de diversos modelos existentes, dentre os quais,
os modelos de features, que foram propostos como parte do método de análise orientada por
features (Feature-Oriented Analysis method – FODA) (Kang et al, 1990).
Um modelo de features é um diagrama de features, que consiste em uma representa-
ção em árvore, cujos nós são as features e as arestas são as relações entre elas, e contém in-
formações adicionais sobre descrições das features e regras de relacionamento (entre outras).
Além disso, o modelo de features representa features obrigatórias (mandatory features), op-
cionais (optional features) ou alternativas – que podem ser do tipo inc-or (inclusive-or featu-
res) ou xor (exclusive-or features).
Uma feature obrigatória representa uma característica ou funcionalidade que é comum
a todos os produtos da LPS. Features opcionais existem em apenas alguns produtos da LPS.
Features alternativas xor oferecem opções de escolha em que uma, e somente uma, subfeature
do conjunto deve ser selecionada. As features do tipo inc-or exigem que, no mínimo, uma
subfeature seja escolhida, mas pode-se selecionar mais do que uma.
A Figura 1 representa um modelo de features genérico, que ilustra a representação grá-
fica de cada tipo de feature, com uma legenda.
20
Figura 1: Modelo de Features
Root Feature é a raiz do modelo de features, que representa a LPS. F1 é uma feature
opcional, com três subfeatures obrigatórias (F2, F3 e F4). F5 é uma feature obrigatória com
duas subfeatures alternativas (F6 e F7) do tipo xor. Por fim, F8 é uma feature obrigatória com
três subfeatures alternativas do tipo inc-or (F9, F10 e F11).
2.2 Modelos de Metas
Modelos de metas são abordagens que expressam graficamente requisitos funcionais e
não funcionais de um sistema, através de decomposição de metas, e têm a finalidade de apon-
tar como satisfazer uma meta, utilizando-se, quando necessário, submetas (Giorgini, 2002).
O modelo de metas V-Graph (Yu et al, 2004) representa, textual e graficamente, ele-
mentos (tarefas, metas e softmetas) e as relações entre esses elementos (relacionamento de
contribuição e de correlação), em uma hierarquia em árvore.
As relações de contribuição podem ser do tipo and (quando o elemento é obrigatório),
or (quando o elemento é opcional) e xor (quando apenas um dos elementos nesse relaciona-
mento pode ser satisfeito, para que seu pai também seja).
As relações de correlação expressam as interações entre os elementos (como uns inter-
ferem nos outros positiva ou negativamente), e são do tipo make (um elemento só existe se o
outro existir), break (um elemento impossibilita a existência do outro), help (um elemento
reforça o outro), unknown (há influência, mas não se pode determinar se é positiva ou negati-
va) e hurt (um requisito afeta o outro).
AOV-Graph (Silva, 2006) é uma extensão desse modelo de metas, que adiciona o re-
lacionamento transversal, para dar suporte à orientação a aspectos. PL-AOVgraph (Santos,
2010) é uma extensão de AOV-Graph para o domínio de LPS, que adiciona o relacionamento
de contribuição inc-or, além das novas propriedades: isFeature (que determina se uma meta,
softmeta ou tarefa deve ser representada como uma feature no modelo de features da LPS);
typeFeature (que indica que tipo de feature meta, softmeta ou tarefa irá representar no modelo
de features; groupFeature (que define quais features são agrupadas); e cardinality (que repre-
21
senta a cardinalidade entre features e grupos de features). Cardinality pode ser cardinality-
Min, cardinalityMax, cardinalityGroupMin e cardinalityGroupMax.
A Figura 2 ilustra o metamodelo de PL-AOVgraph, em UML (Unified Modelling
Language) (UML, 2011), que inclui elementos de V-Graph e AOV-Graph, além dos elemen-
tos adicionais supracitados.
Figura 2: Metamodelo de PL-AOVgraph
O metamodelo de PL-AOVgraph estende o metamodelo de AOV-Graph, incluindono-
vas propriedades (subclasses do elemento existente Property) e o relacionamento in-cor é
adicionado como um novo label para as Decomposition Categories. É criado, também, um
novo relacionamento, o de contribuição. O metamodelo da Figura 2 é definido e utilizado em
um trabalho atualmente em andamento (ver seção 6.5), com base na definição de PL-
AOVgraph de Santos (2010).
A Figura 3 ilustra um modelo de metas genérico, com a representação gráfica em PL-
AOVgraph e a respectiva descrição textual ao lado.
Figura 3: Modelo de Metas PL-AOVgraph
22
De forma análoga ao modelo de features apresentado na seção anterior, o modelo de
metas da Figura 3 tem uma raiz (Goal Model). Além disso, conta com três tarefas (tasks), que
são: T1 (com relacionamento de contribuição or), T5 (com relacionamento de contribuição
and) e T8 (também com relacionamento do tipo and), cada uma com subtarefas e relaciona-
mentos de contribuição do tipo and (T2, T3, T4), do tipo xor (T6 e T7) e do tipo inc-or (T9,
T10 e T11). Tem também, no modelo, uma Softmeta (SoftGoal, Sg1), com relacionamento de
contribuição do tipo and.
2.3 Linguagens de Descrição Arquitetural
Linguagens de Descrição Arquitetural (ADL – Architectural Description Language)
(Clements, 1996) são utilizadas para descrever arquitetura de software, em termos de compo-
nentes, conectores e as interações entre esses elementos. Uma ADL pode ser uma linguagem
formal ou semi-formal, pode ser descritiva, gráfica ou ambas.
Existem diversas ADLs na indústria e na academia, para diversos domínios de aplica-
ção. A ADL ACME (Garlan et al, 1997) proporciona a integração de diversas ferramentas
desenvolvidas para dar suporte a diversas ADLs, fornecendo um mecanismo para a troca de
informações arquiteturais. Seus elementos são os components (elementos básicos), connectors
(modelam interações entre componentes), ports (interfaces dos componentes), roles (interfa-
ces dos conectores), system (grafo cujos nós são os componentes e arestas são os conectores),
representation (descrição interna de um componente), bindings (fazem a correspondência
entre a representação interna de um elemento e sua interface externa) e attachments (descre-
vem de que forma os componentes se conectam através dos conectores).
Além dos elementos estruturais, ACME define properties (propriedades), que incluem
informações adicionais sobre qualquer elemento, exceto attachments, através de triplas (no-
me, tipo, valor). Há também os constructs Type e Family, usados respectivamente para definir
um vocabulário de tipos abstratos para os elementos da ADL e definir estilos arquiteturais em
termos de tipos abstratos de elementos.
AspectualACME (Batista et al, 2006) estende ACME para dar suporte à orientação a
aspectos, incluindo o aspectual connector e os mecanismos de quantificação. O aspectual
connector tem três elementos que definem a semântica das conexões entre os components: (i)
Base role, que se conecta às portas dos conectores de comportamento regular; (ii) Crosscut-
ting role, que se conecta às portas de componentes de comportamento aspectual; e (iii) Glue
clause, que é a composição entre um base role e um crosscutting role e define onde um com-
ponente regular será afetado por um componente aspectual, por exemplo.
23
Os mecanismos de quantificação simplificam sintaticamente as referências aos diver-
sos pontos de junção na descrição arquitetural. São inseridos no campo de configuração (atta-
chments), através de wildcards, que denotam nomes ou partes de nomes de componentes e
suas portas (representados pelo símbolo „*‟). A quantificação é usada na conexão entre o Base
role de um aspectual connector e um ou mais componentes de comportamento regular.
A Figura 4 mostra um conector aspectual e seus attachments com conectores regula-
res, descritos em AspectualACME.
Figura 4: Attachments entre conector aspectual e conectores regulares em AspectualACME
As duas portas do AspectualComponent (aPort e bPort, na descrição textual) são liga-
das aos crosscutting roles dos conectores aspectuais C1 e C2, respectivamente. Os base roles
dos conectores aspectuais (aBaseRole e bBaseRole) são ligados, respectivamente, às portas
cPort e dPort, dos componentes regulares do exemplo da Figura 4.
PL-AspectualACME (Adachi, 2009) e (Adachi et al, 2011) é uma extensão de Aspec-
tualACME, que não adiciona novos elementos à ADL, mas apenas enriquece semanticamente
alguns elementos existentes, definindo um novo estilo arquitetural para LPS. Para representar
as restrições (constraints) que podem existir nos relacionamentos entre as features de uma
LPS, PL-AspectualACME utiliza, também, elementos da linguagem de predicados baseada
em lógica de primeira ordem, e também estendida a partir de ACME, Armani (Monroe,
1998). Armani é utilizada para expressar restrições arquiteturais sobre elementos ACME, a-
través de invariantes (restrições que devem ser seguidas) e heurísticas (sugestões que podem
ou não ser seguidas). São elementos de Armani: quantificador universal (forall), quantificador
existencial (exists) e um construct que permite a definição de novas funções (Analysis).
Os constructs de PL-AspectualACME são os seguintes:
24
a. Family – extensão do elemento Family de ACME, define o estilo arquitetural Pro-
ductLineT para LPS;
b. VariationPointT – extensão do elemento Component de ACME, encapsula pontos
de variação opcionais (OptionalT), alternativos (AlternativeT) e inclusive-or (Inclusi-
veOrT);
c. Representation – extensão do elemento representation de ACME, encapsula as va-
riantes;
d. Property variants – extensão do elemento property de ACME, lista as variabilida-
des de um ponto de variação;
e. VariationPortT – porta que abstrai o mecanismo de seleção de variantes em um Va-
riationPointT;
f. Property SelectedVariants – indica as variantes escolhidas para uma Variation-
PortT, na configuração do produto;
g. Analysis requires – extensão do predicado Armani analysis, define restrições entre
features do tipo A requer B; e
h. Analysis excludes – extensão do predicado Armani analysis, define restrições entre
features do tipo A exclui B.
O estilo arquitetural definido (ProductLineT) serve de template para definir arquitetu-
ras de LPS específicas e os elementos de PL-AspectualACME acima definidos são utilizados
para modelar variabilidades. As similaridades são modeladas, dessa forma, como componen-
tes ou portas regulares.
A Figura 5 ilustra o metamodelo de PL-AspectualACME, que inclui elementos de
ACME e AspectualACME, com a nova semântica de alguns elementos.
25
Figura 5: Metamodelo de PL-AspectualACME
De acordo com o metamodelo, uma família (Family) contém Systems que, por sua vez,
contém Components (que podem ser comuns ou do tipo VariationPointT, OptionalT, Alterna-
tiveT ou InclusiveOrT). System contém, também, attachments, bem como elementos Armani
Analysis Requires e Analysis Excludes e Connectors. Um Component possui portas e, se for
um VariationPointT, possui a porta VariationPortT. Component é um tipo de Element, assim
como Connectors, Ports, Roles e Systems. Connector contém Roles e o tipo de Role (Role,
Base Role ou Crosscutting Role) define se o comportamento do Connector é regular ou aspec-
tual. Se um Connector for aspectual, ele contém Glue, que define gluetypes, que consiste na
forma com que consiste no tipo do advice do aspecto (around, before, after). Um Component
pode, ainda, conter outros componentes e também pode conter Representations dentro dele.
Uma Representation contém Bindings e Systems. Um elemento pode ter ou não propriedades.
A propriedade Variants e a propriedade SelectedVariants são tipos de propriedades (estendem
o elemento Property).
O metamodelo apresentado na Figura 5 é uma extensão do metamodelo de Aspectua-
lACME, incluindo alterações propostas com base na definição mais recente de PL-
AspectualACME (Adachi et al, 2011).
26
A Figura 6 ilustra um pequeno exemplo de PL-AspectualACME, textualmente, com
uma representação gráfica (apenas para compreensão) ao lado.
Figura 6: Exemplo PL-AspectualACME
No exemplo genérico apresentado na Figura 6, a Família de Produtos, do tipo Produc-
tLineT de nome „Exemplo‟ possui um Component do tipo VariationPointT chamado „comp‟,
que é obrigatório e possui dois componentes internos a ele: (i) C1, que é obrigatório e possui a
porta „c1Port‟, que provê o serviço do componente C1; e (ii) C2, que é opcional. C2 é repre-
sentado, na descrição PL-AspectualACME, na propriedade variants, e sua representação in-
terna é modelada através do elemento Representation, que encapsula o System C2 e suas vari-
antes inclusive-or: C3, C4 e C5 (cada uma modelada através de suas representations e sys-
tems). As variantes C2, C3, C4 e C5 são selecionadas através da porta VariationPortT do pon-
to de variação que as contém.
2.4 Transformações entre Modelos com MDD e ATL
No campo da engenharia de modelos, os modelos são considerados entidades de pri-
meira classe. Um modelo deve ser definido de acordo com a semântica do seu metamodelo.
Da mesma forma, o metamodelo deve estar de acordo com um metametamodelo. Nessa arqui-
tetura de três camadas (modelo, metamodelo e metametamodelo), o metametamodelo está,
normalmente, de acordo com a sua própria semântica. Metametamodelos existentes incluem o
MOF (Meta-Object Facility, definido pela OMG) (OMG/MOF, 2005) e o Ecore, que foi in-
troduzido com o Eclipse Modelling Framework (EMF) (EMF, 2011).
27
Considerar modelos como entidades de primeira classe requer que haja um conjunto
de ferramentas que defina algumas operações dedicadas a modelos. Nesse contexto, a trans-
formação entre modelos parece ser das mais úteis operações sobre modelos, facilitando a
geração de um modelo a partir de outros modelos, sendo que ambos devem estar de acordo
com os seus respectivos metamodelos.
A engenharia de modelos considera, tanto quanto possível, todos os itens manipulados
como modelos. Assim, a transformação de modelos por si só é definida como um modelo.
Esse modelo de transformação deve estar de acordo com o seu metamodelo de transformação,
que é quem define a semântica da transformação. Assim como com os outros metamodelos, o
metamodelo de transformação, por sua vez, deve estar de acordo com o seu metametamodelo.
A Figura 7 ilustra o processo completo de transformação de modelos.
Figura 7: Processo Geral de Transformação de Modelos
Um modelo Ma (que está de acordo com o seu metamodelo MMa) é transformado em
um modelo Mb (que está de acordo com o seu metamodelo MMb). A transformação é defini-
da pelo modelo Mt (que está de acordo com o seu metamodelo MMt). Todos esses metamode-
los devem estar de acordo com um metametamodelo (como MOF ou Ecore).
Para realizar uma transformação entre modelos, portanto, é necessário criar os meta-
modelos de origem e de destino e projetar esses metamodelos em uma forma „computável‟.
Neste trabalho, foi utilizado o ambiente Eclipse (ECLIPSE, 2011) e o seu conjunto de ferra-
mentas de modelagem, o Eclipse Modelling Framework (EMF) (EMF, 2011).
A versão „computável‟ dos metamodelos criados no EMF é um arquivo do tipo XMI
(XML Metadata Interchange) (OMG-XMI, 2011). E as transformações entre os modelos são
realizadas em uma linguagem específica de transformação entre modelos: Atlas Transforma-
tion Language (ATL) (ATL, 2006).
O ATL Development Tools (ADT) conta, para editar metamodelos no EMF, com o
Kernel MetaMetaModel (KM3), que é uma notação textual dedicada à edição de metamode-
28
los. Há, também, a possibilidade de se construir os metamodelos graficamente, através do
editor gráfico do EMF (nas versões mais recentes do Eclipse). Assim, criamos um diagrama
(similar a um diagrama de classes da UML simplificado), com classes e relacionamentos entre
essas classes, que representam os elementos dos modelos que se deseja manipular e os rela-
cionamentos entre eles. Esse diagrama gera, automaticamente, na ferramenta, um metamodelo
com extensão .ecore, que será utilizado como base para a construção do modelo a ser manipu-
lado, bem como para a criação das regras de mapeamento entre os modelos em ATL.
A Figura 8 mostra o processo de transformação com os metamodelos ecore.
Figura 8: Processo de Transformações com ATL
O modelo Ma, que está de acordo com o seu metamodelo MMa é transformado em um
modelo Mb, que está de acordo com o seu metamodelo MMb. O arquivo de transformação
Ma2Mb.atl deve estar em conformidade com o metamodelo de transformação ATL. Os dois
metamodelos MMa e MMb, bem como o metamodelo ATL devem estar em conformidade
com o metametamodelo ecore.
2.5 Tecnologias Utilizadas
Nessa seção, apresentamos as tecnologias MDD, que são parte do projeto EMF (EMF,
2011), utilizadas para a implementação deste trabalho. Na seção 2.5.1, apresentamos a lingua-
gem de transformações entre modelos ATL; na seção 2.5.2, discorremos sobre o framework
de definição de DSL (Domain Specific Language) e transformações texto a modelo Xtext e na
seção 2.5.3, falamos sobre o gerador de código a partir de modelos Acceleo.
2.5.1 Linguagem de Transformações ATL
ATL (ATL, 2006) é uma linguagem de transformações entre modelos e um kit de fer-
ramentas, desenvolvidos pelo grupo de pesquisa ATLAS INRIA & LINA (ATLAS, 2010),
que permite gerar um conjunto de modelos de destino a partir de um conjunto de modelos de
29
origem. O kit de ferramentas ATL funciona em ambiente Eclipse (ECLIPSE, 2011) e faz parte
do projeto EMF (EMF, 2011).
A linguagem é especificada através de metamodelos, juntamente com sua sintaxe tex-
tual concreta, e pode ser declarativa ou imperativa. O estilo declarativo expressa, basicamen-
te, mapeamentos entre elementos de um modelo de origem e elementos de um modelo de des-
tino. A linguagem também permite o uso de constructs imperativos auxiliares, quando há
questões específicas do mapeamento que dificilmente serão expressas da forma declarativa.
A transformação ATL é composta de regras que definem como cada elemento do mo-
delo de origem será transformado no respectivo elemento do modelo de destino. Esses mode-
los são definidos através de metamodelos, como os expostos no Capítulo 2 deste trabalho.
A Figura 9 ilustra um exemplo de uso da linguagem ATL.
Figura 9: Exemplo da Ferramenta ATL
Ao lado esquerdo, na figura, temos o projeto ATL criado, com os modelos de origem e
destino authors.ecore e persons.ecore, além do arquivo de transformação Author2Person.atl.
Ao lado direito, é exibido o código da transformação implementada nesse arquivo de trans-
formação.
O corpo da transformação conta com um cabeçalho, em que temos inicialmente o no-
me da transformação (module Author2Person), na primeira linha, seguido da definição dos
modelos de origem e destino na segunda linha (create OUT : Person from IN : Author) e uma
regra de transformação (rule Author) de um dos elementos do modelo authors (Author) em
um elemento do modelo persons (Person).
Além das regras (rules), ATL conta, também com elementos opcionais, como helpers
(que são blocos de código que funcionam de forma similar aos métodos da orientação a obje-
tos) e regras auxiliares (lazy rules e called rules). Os helpers podem ser declarados no corpo
da transformação ou em um arquivo atl separado chamado library. Maiores detalhes sobre a
linguagem ATL podem ser consultados em (ATL, 2006).
30
2.5.2 Xtext
XTEXT (XTEXT, 2011) é um framework de suporte a desenvolvimento de lingua-
gens, que podem ser linguagens de programação de propósito geral ou mesmo linguagens
específicas de domínio (DSL). O framework funciona em ambiente Eclipse (ECLIPSE, 2011)
e permite criar linguagens novas ou utilizar as suas ferramentas para fornecer suporte a lin-
guagens existentes.
A definição da gramática de uma linguagem pode ser feita do zero ou com base em um
metamodelo existente. Ao criar um projeto Xtext, o editor da gramática é apresentado, com as
definições que podem ser editadas (no caso do projeto ter sido criado com base em um meta-
modelo existente) ou em branco, para que as definições sejam criadas livremente, de acordo
com a sintaxe textual da ferramenta. Nesse editor, definimos toda a sintaxe da linguagem,
com suas regras, tokens e palavras reservadas.
Definida a linguagem, o Xtext gera a infraestrutura da linguagem e o editor da lingua-
gem já pode ser testado.
A Figura 10 mostra um trecho do editor de gramática, juntamente com o editor da lin-
guagem especificada nessa gramática.
Figura 10: Editor de Gramática e Editor de Linguagem, no Xtext
Na Figura 10 (a), temos o editor da gramática „MyDsl’, com os elementos Model e
Greeting. O elemento Model é composto por um ou vários elementos Greeting (representado
pela variável greetings). O símbolo „*‟ indica essa composição de um para vários. Cada ele-
mento Greeting, por sua vez, contém a palavra reservada „Hello’, recebe um nome, que é o
identificador, e também possui o token obrigatório „!‟. A Figura 10 (b) mostra o editor da lin-
31
guagem criada, após a geração da infraestrutura da linguagem, com dois elementos Greeting:
„Hello Xtext!‟ e „Hello World!‟.
No Xtext, a associação da gramática da DSL criada a partir do respectivo metamodelo
permite a geração de especificação xmi a partir da gramática. Assim, além da criação da gra-
mática das duas linguagens (PL-AOVgraph e PL-AspectualACME), este trabalho executa a
geração da especificação xmi das duas linguagens a partir de suas gramáticas, realizando as
transformações de descrição textual para representação gráfica dessas descrições (modelo). O
resultado da transformação serve, então, de insumo para a transformação modelo a modelo em
ATL.
2.5.3 Acceleo
Acceleo (ACCELEO, 2011) é uma ferramenta criada pela Obeo (OBEO, 2011) para
geração de código a partir de modelos, que podem ser UML (UML, 2011), MOF (OMG-
MOF, 2008) ou EMF (EMF, 2011). Assim como ATL (ATL, 2006) e Xtext (XTEXT, 2011),
Acceleo também é executado em ambiente Eclipse e é baseado nos princípios MDD.
No Acceleo, com base em um metamodelo existente, criamos um Script com templa-
tes do código de alguma linguagem (também existente), que será gerado. A Figura 11 exibe
um exemplo do script de templates, com o respectivo código gerado.
(a) (b)
Figura 11: Exemplo Acceleo
Na Figura 11 (a), temos um script para transformação de UML para XHTML (eXten-
sible Hypertext Markup Language) (XHTML, 2011). Na primeira linha, é feita referência ao
metamodelo UML que será usado na geração de código. Em seguida (em marrom), é definido
o script com o tipo de modelo, o nome do script e a extensão do arquivo de saída. Depois,
32
temos o template para as tags HTML, com seus conteúdos. Na Figura 11 (b), temos o código
XHTML gerado como resultado.
2.6 A Linha de Produtos Ginga ForAll
O Ginga ForAll (Saraiva et al, 2010) é uma iniciativa de pesquisadores da Universida-
de Federal do Rio Grande do Norte (UFRN), que refatora o middleware de TV digital Ginga
(Ginga, 2006), fornecendo uma versão baseada em LPS, acrescentando configurabilidade ao
middleware, através do gerenciamento automático de variabilidades.
O ambiente de execução das aplicações de TV digital é altamente heterogêneo, em vir-
tude da existência de diversos dispositivos de recepção e das grandes diferenças entre esses
dispositivos em termos de hardware e Software. A Figura 12, extraída de (Saraiva et al,
2010), expressa, de forma simplificada, essa heterogeneidade de plataformas.
Figura 12: Diferentes plataformas de transmissão de sinal de TV Digital
Os sinais de transmissão de TV digital podem ser recebidos por TVs com conversores
embutidos, TVs com conversores externos, dispositivos móveis, como notebooks e celulares
com receptores portáteis, veículos com receptores móveis, entre outros. Além dessa diferença
explícita de hardware, esses aparelhos operam em plataformas de software distintas.
Assim, o Ginga ForAll surgiu como uma LPS do middleware Ginga, para dar suporte
ao gerenciamento das funcionalidades comuns e variáveis dessa tecnologia, para as diversas
plataformas que a implementam, sendo esse o principal propósito do projeto. O Ginga ForAll
também foi idealizado aliando os conceitos de LPS a técnicas de MDD e Desenvolvimento de
Software Orientado a Aspectos (DSOA) (AOSD, 2011). Dessa forma, enquanto o DSOA mo-
dulariza as funcionalidades transversais (crosscut concerns) do Ginga, o MDD facilita a ma-
nipulação dos modelos que especificam a arquitetura da LPS, que expressa as variabilidades
do middleware através do seu modelo de features.
33
A equipe realizou uma análise inicial de domínio do núcleo principal do Ginga, o Gin-
ga Common Core (GingaCC) e, então, refatorou a sua arquitetura, estendendo-a para uma
arquitetura (orientada a aspectos) de LPS..
Ginga ForAll foi escolhida como estudo de caso por se tratar de uma aplicação real e
por contemplar todos elementos necessários à completude da representação das transforma-
ções: variabilidade, interações entre features e relacionamentos transversais. O modelo de
features de Ginga ForAll é ilustrado na Figura 13.
Figura 13: Modelo de features do Ginga ForAll
Dentre as features do Ginga ForAll, foram selecionadas algumas, para representar va-
riabilidade, interações entre features e relacionamentos transversais nas transformações im-
plementadas em MaRiPLA (circuladas em vermelho na figura). Tuner (define a seleção do
canal físico de transmissão do sinal de TV) é um ponto de variação obrigatório, com variantes
opcionais (FileSystem, IP, Terrestrial e Satellite); Demultiplexer é um ponto de variação o-
brigatório, com variantes alternativas (implementa o demultiplexador em software ou em
hardware, para cada Tuner); Platform é um ponto de variação obrigatório, com variantes al-
ternativas, que definem a plataforma de execução de TV digital (ST, Broadcom, PC ou Mobi-
le); Conditional Access é um componente obrigatório e representa a função de controlar o
acesso a conteúdos resritos transmitidos aos receptores de TV. Há interações entre a variante
Hardware, do ponto de variação Demultiplexer, e as variantes PC e Mobile, do ponto de vari-
ação Platform (ver Tabela 1). Além disso, Ginga ForAll apresenta relacionamentos transver-
sais entre alguns elementos. Um exemplo é o ponto de variação Conditional Access, que inter-
fere no elemento Tuner, atuando na comunnicação desse elemento com o Demultiplexer. Por
questão de espaço, as demais features do modelo de features do Ginga ForAll não foram re-
presentadas nas transformações de MaRiPLA.
As interações entre features do Ginga ForAll são apresentadas na Tabela 1.
34
Tabela 1: Lista de dependências entre features do Ginga ForAll
Ponto de Variação
Variante Restrição Variante
Demultiplexer
Hardware Exclui Plataformas PC e Mobile
Application Manager
JavaDTV ou NCL/Lua Requer Data Processing com Ap-
plication Building
NCL/Lua Complemen-
tary Requer NCL/Lua Basic
NCL/Lua Basic +
Complementary Requer
Todos os formatos de mídia
do Media Processing
De acordo com a Tabela 1, ao selecionar a variante Hardware do ponto de variação De-
multiplexer, não podem ser selecionadas as variantes PC e Mobile do ponto de variação Platform.
Ao selecionar a variante JavaDTV ou a variante NCL_Lua, do ponto de variação Application Ma-
nager, deve ser selecionada também a variante Application Building, de Data Processing. Se o
NCL_Lua for selecionado como Complementary, isto requer que seja selecionada, também, a va-
riante Basic do NCL_Lua. Por fim, se forem selecionadas as duas variantes de NCL_Lua (Basic e
Complementary), todos os formatos do Media Processing devem ser selecionados.
2.6.1 PL-AOVgraph do Ginga ForAll
A Figura 14 mostra um trecho do modelo PL-AOVgraph da LPS Ginga ForAll, definido ma-
nualmente, a partir do modelo de features do Ginga ForAll.
aspect_oriented_model{
goal_model "ginga"{
task"Tuner"(and){
task"Terrestrial"(or){}
task"Filesystem"(or){}
task"Satelite"(or){}
task"IP"(or){
task"IPTV"(and){}
task"InternetTV"(and){}
task"P2PTV"(and){}
}
}
task"Platform"(and){
task"Broadcom"(xor){}
task"ST"(xor){}
task"PC"(xor){}
task"Mobile"(xor){}
}
task"ConditionalAcess"(and){}
task"Demultiplexer"(and){
task"Hardware"(xor){}
task"Software"(xor){}
}
correlation (break){
source : task_ref "Hardware"
target : task_ref "PC"
}
correlation (break){
source : task_ref "Hardware"
target : task_ref "Mobile"
}
crosscutting {
source: task_ref "ConditionalAcess"
pointcut pc1: include "Tuner"
advice (around): pc1 {
task_ref "ConditionalAcess" (and)
}
}
}
};
Figura 14: Descrição PL-AOVgraph do Ginga ForAll (trecho)
35
Na descrição da Figura 14, são modeladas as features Tuner (tarefa), Platform (tarefa),
ConditionalAccess (tarefa) e Demultiplexer (tarefa). Também são representadas, no modelo,
as restrições entre features do Ginga ForAll, em conformidade com aquelas ilustradas na Ta-
bela 1, através dos relacionamentos de correlação (Correlation make, para restrição do tipo
„requer‟ e Correlation break, para restrição do tipo „exclui‟). No caso, é representado o rela-
cionamento Correlation do tipo break, que modela as restrições entre a feature Hardware, de
Demultiplexer e as features PC e Mobile, de Platform. Além disso, o modelo ilustra, também,
o relacionamento transversal (crosscutting) entre o elemento Conditional Access e o elemento
Tuner.
PL-AOVgraph apresenta, ainda, limitações com relação à definição de nomes dos re-
quisitos. A nomeação dos elementos foi feita de acordo com os nomes das features do modelo
de features do Ginga ForAll. Como não há heurísticas pré-definidas para a nomeação dos e-
lementos, do engenheiro de requisitos pode intervir, editando os nomes como lhe convier.
2.6.2 Descrição Arquitetural do Ginga ForAll
O mesmo trecho do Ginga ForAll descrito em PL-AOVgraph foi descrito em PL-
AspectualACME e é representado na Figura 15.
Componente Tuner
family ginga:new ProductLineT extended with={
system ginga={
component Tuner: new VariationPointT extended with={
variationPortT tunerVarPort={};
port tunerPort={};
property variants={"IP, Filesystem, Terrestrial, Satelite"};
representation Terrestrial={
system Terrestrial={
component Terrestrial: new OptionalT extended with={
port terrestrialPort={};
};
};
binding (tunerVarPort to terrestrialPort;);
};
representation Filesystem={
system Filesystem={
component Filesystem: new OptionalT extended with={
port fsPort={};
};
};
36
binding (tunerVarPort to fsPort;);
};
representation Satelite={
system Satelite={
component Satelite: new OptionalT extended with={
port satPort={};
};
};
binding (tunerVarPort to satPort;);
};
representation IP={
system IP={
component IP: new OptionalT extended with={
port ipPort={};
variationPortT ipVarPort={};
property variants={"InternetTV, IPTV, P2PTV"};
representation IPTV={
system IPTV={
component IPTV: new OptionalT extended with ={
port iptvPort={};
};
};
binding (ipPort to iptvPort;);
};
representation InternetTV={
system InternetTV={
component InternetTV : new OptionalT extended with ={
port intPort={};
};
};
binding (ipPort to intPort;);
};
representation P2PTV={
system P2PTV={
component P2PTV : new OptionalT extended with ={
port p2ptvPort={};
};
};
binding (ipVarPort to p2ptvPort;);
};
};
};
binding (tunerVarPort to ipPort;);
};
};
Componentes Platform, Conditional Access e Demultiplexer
component Platform: new VariationPointT extended with={
variationPortT platfVarPort={};
port platfPort={};
property variants={"ST, Broadcom, Mobile, PC"};
representation Broadcom={
system Broadcom={
component Broadcom: new AlternativeT extended with={
port broadPort={};
};
};
37
binding (platfVarPort to broadPort;);
};
representation ST={
system ST={
component ST: new AlternativeT extended with={
port stPort={};
};
};
binding (platfVarPort to stPort;);
};
representation PC={
system PC={
component PC: new AlternativeT extended with={
port pcPort={};
};
};
binding (platfVarPort to pcPort;);
};
representation Mobile={
system Mobile={
component Mobile: new AlternativeT extended with={
port mobilePort={};
};
};
binding (platfVarPort to mobilePort;);
};
};
component ConditionalAcess={
port condPort={};
};
component Demultiplexer: new VariationPointT extended with={
variationPortT demuxVarPort={};
port demuxPort={};
property variants={"Software, Hardware"};
representation Hardware={
system Hardware={
component Hardware: new AlternativeT extended with={
port hardPort={};
};
};
binding (demuxVarPort to hardPort;);
};
representation Software={
system Software={
component Software: new AlternativeT extended with={
port softPort={};
};
};
binding (demuxVarPort to softPort;);
};
};
connector gingaConn={
base role tunerBrole={
refPort={Tuner};
};
crosscutting role condCrole={
refPort={ConditionalAcess};
};
glue={crosscutting element:condCrole glueType:around base ele-
ment:tunerBrole};
};
attachment={tunerBrole to Tuner};
attachment={condCrole to ConditionalAcess};
design invariant excludes (Hardware, PC);
design invariant excludes (Hardware, Mobile);
};
};
Figura 15: PL-AspectualACME do Ginga ForAll (trecho)
38
Na Figura 15 são descritos os VariationPointT Tuner (obrigatório, com variantes op-
cionais, descritas através de Representations), Platform (obrigatório, com variantes alternati-
vas, descritas através de Representations), Demultiplexer (obrigatório, com variantes alterna-
tivas, descritas através de Representations) e ConditionalAccess (obrigatória e sem filhos).
Foram descritas, também, restrições Armani, em conformidade com o que foi exposto na Ta-
bela 1, o connector que modela uma relação transversal entre os elementos Conditional Ac-
cess e Tuner, além dos attachments dessa relação.
A descrição arquitetural da Figura 15 foi definida, também de forma manual, a partir
do modelo de features do Ginga ForAll, utilizando os mesmos nomes dos elementos do mode-
lo de features.
O Ginga ForAll é uma LPS extensa, por isso, foi selecionada apenas uma parte de sua
descrição arquitetural para o estudo de caso deste trabalho e, ainda assim, alguns elementos
que não estão diretamente associados a variabilidades foram abstraídos. Os elementos descri-
tos foram escolhidos com base em sua riqueza semântica, a fim de que possamos mostrar a
maior quantidade possível de elementos de PL-AOVgraph e de PL-AspectualACME, no mo-
mento do rastreamento.
39
3. Processo de Mapeamento entre Modelo de Metas e Descrição
Arquitetural
Este Capítulo define o processo que conduz o mapeamento entre modelos de metas e
descrição arquitetural proposto por este trabalho. A seção 3.1 ilustra, em uma visão macro, o
processo em si, com as respectivas atividades; a seção 3.2 discorre sobre o mapeamento entre
os modelos, com a definição das regras de mapeamento e os fluxos de atividades para cada
uma das direções de mapeamento.
3.1 Processo de Mapeamento
O processo de mapeamento inicia com um modelo PL-AOVgraph (gerado a partir do
modelo de features, conforme (Santos, 2010), ou, no sentido inverso, com um modelo PL-
AspectualACME, que pode ser gerado do zero ou a partir de um modelo de features ou de um
modelo qualquer de requisitos. Isso caracteriza a bidirecionalidade das transformações. A
Figura 16 mostra o fluxo de atividades desse processo.
Figura 16: Processo de mapeamento entre PL-AOVgraph e PL-AspectualACME
O processo de transformações ocorre em três níveis: (i) transformações texto-modelo;
(ii) transformações modelo-modelo; e (iii) transformações modelo-texto. Partindo de PL-
40
AOVgraph para PL-AspectualACME (ver parte superior da Figura 16), temos uma descrição
textual de PL-AOVgraph (que é o modelo de entrada), que será verificada conforme a BNF da
linguagem definida no framework Xtext. Feita a verificação, essa descrição textual é transfor-
mada, através de mecanismos do Xtext, em um modelo ecore .xmi (transformação texto-
modelo). Este modelo, por sua vez, deve estar de acordo com o seu metamodelo ecore previ-
amente definido e, aplicando-se as regras ATL, é transformado em um modelo ecore .xmi de
PL-AspectualACME (transformação modelo-modelo). O modelo ecore .xmi de PL-
AspectualACME deve estar em conformidade com o seu respectivo metamodelo ecore. Após
essa verificação de conformidade, aplicam-se a este modelo as definições do Script de templa-
tes Acceleo de PL-AspectualACME, para realizar a transformação do modelo xmi em descri-
ção textual de PL-AspectualACME (Transformação modelo-texto), que é o resultado final da
transformação.
De forma similar, na transformação de PL-AspectualACME para PL-AOVgraph (ver
parte inferior da Figura 16), temos a especificação textual de PL-AspectualACME como mo-
delo de entrada. Essa especificação deve estar de acordo com sua BNF, definida no Xtext.
Após a verificação, é realizada a transformação texto-modelo, de descrição PL-
AspectualACME em modelo ecore xmi de PL-AspectualACME. Este modelo deve estar em
conformidade com seu metamodelo e, então, é transformado (Transformação modelo-modelo)
em modelo ecore xmi de PL-AOVgraph, através das regras ATL. Após a verificação do ecore
xmi de PL-AOVgraph gerado, este é transformado em descrição textual PL-AOVgraph, atra-
vés da aplicação das definições do Script de templates Acceleo para o PL-AOVgraph. Essa
descrição resultante é o modelo de saída da transformação.
As descrições resultantes de ambos os sentidos de transformação devem estar de acor-
do com as respectivas BNFs.
A bidirecionalidade das transformações também se caracteriza pela possibilidade da
especificação gerada na saída da transformação ser utilizada como entrada para a transforma-
ção no fluxo inverso.
3.2 Regras de Mapeamento
A Tabela 2 resume as regras de mapeamento entre os modelos PL-AOVgraph e PL-
AspectualACME.
41
Tabela 2: Regras de mapeamento entre PL-AOVgraph e PL-AspectualACME
PL-AOVgraph PL-AspectualACME
1 Aspect_Oriented_Model Family
2 GoalModel System
3
8
Task/Goal/Softgoal com Contribuição
“and”, “or”, “xor” ou “inc-or”
Component + Port + Property ElementType
VariationPointT + Port + VariationPortT
+Property ElementType + property Variants
OptionalT + Port + VariationPortT +Property ElementType + property Variants
AlternativeT + Port + VariationPortT
+Property ElementType + property Variants
InclusiveOrT + Port + VariationPortT + Property ElementType + property Variants
Representation/System/Component + Ports +
Property ElementType + property Variants
4 Correlation Make Analysis Requires
5 Correlation Break Analysis Excludes
6 Correlation hurt, unknown, help Property hurt, unknown, help
7
Propriedades (CardinalityMin, Cardina-
lityMax, CardinalityGroupMin, Cardina-
lityGroupMax, isFeature, GroupFeature e Generic Property)
Property
8 Relacionamento transversal (Crosscut-
ting) Connector aspectual + Attachments
Como já foi exposto, o processo de mapeamento é bidirecional, ou seja, as transforma-
ções entre os elementos de PL-AOVgraph e de PL-AspectualACME ocorrem nos dois senti-
dos. Assim, temos que:
1. Aspect_Oriented_Model, de PL-AOVgraph é transformado em Family de PL-
AspectualACME e vice-versa, pois representam o modelo em sua totalidade;
2. Goal_Model, de PL-AOVgraph, que representa o elemento raiz do modelo, é
transformado em System de PL-AspectualACME e vice-versa;
3. Task, Goal ou SoftGoal, de PL-AOVgraph são transformados em Components (se
for elemento do primeiro nível da hierarquia de features) ou Representations (se
for de segundo nível em diante) com System e Component. Os Components gera-
dos podem ser do tipo VariationPointT, OptionalT, AlternativeT, InclusiveOrT, de
acordo com o tipo de contribuição do elemento de origem (and, or, xor ou inc-or).
Cada Component recebe uma Property do tipo ElementType, que definirá a partir
de que tipo de elemento (task, goal ou softgoal) de PL-AOVgraph foi gerado, além
de uma porta. Se for um ponto de variação recebe, também, uma Property do tipo
Variants, que lista as suas variantes, e uma VariationPortT.
42
4. Correlation Make, de PL-AOVgraph, é transformado em Analysis Requires de PL-
AspectualACME e vice-versa;
5. Correlation Break, de PL-AOVgraph, é transformado em Analysis Excludes de
PL-AspectualACME e vice-versa;
6. Correlation Hurt, Unknown e Break de PL-AOVgraph, são transformadas em Pro-
perties Hurt, Unknown e Break de PL-AspectualACME e vice-versa;
7. Properties de PL-AOVgraph são transformadas em Properties com o mesmo no-
me em PL-AspectualACME e vice-versa;
8. Relacionamento transversal (Crosscutting) de PL-AOVgraph é transformado em
Connector aspectual de PL-AspectualACME, gerando, também, Attachments. No
sentido inverso, o conector aspectual gera o relacionamento transversal e os ele-
mentos específicos desse relacionamento em PL-AOVgraph são gerados a partir de
propriedades do conector e seus papéis (roles).
As regras de transformação buscam estender as regras definidas em MaRiSA-MDD
(Medeiros, 2008). No entanto, com as atualizações nos metamodelos das duas linguagens,
além da necessidade de representação de variabilidades e interações entre features nas trans-
formações, apenas as regras mais básicas foram aproveitadas. Essas regras são as regras 2, 6 e
7.
As regras 1, 4 e 5 são novas, pois tratam de elementos que representam variabilidades
(Family, na regra 1 e as interações entre features nas regras 4 e 5). A regra 8, apesar de já e-
xistir em MaRiSA, é definida de forma diferente, uma vez que os metamodelos das lingua-
gens sofreram alterações e os elementos que representam os relacionamentos transversais fo-
ram diretamente afetados nessas alterações. Os metamodelos anteriores de AOV-Graph e de
AspectualACME podem ser visualizados em Medeiros (2008).
A regra 3 é a que oferece a contribuição mais significativa para as transformações.
Enquanto em MaRiSA, tínhamos um elemento de AOV-Graph (task, goal ou softgoal) sendo
transformado em um componente de AspectualACME e vice-versa, em MaRiPLA, é nessa
transformação que lidamos de forma mais direcionada com as variabilidades de LPS.
A Figura 17 ilustra as quatro situações que podem ocorrer no momento da transforma-
ção.
43
Figura 17: Transformação de elementos PL-AOVgraph em elementos PL-AspectualACME
Na situação 1, quando o elemento PL-AOVgraph tem relacionamento de contribuição
„and‟ e não tem filhos, a transformação ocorre de maneira similar ao que ocorre em MaRiSA:
o elemento é transformado em um componente comum, obrigatório, de PL-AspectualACME.
Na situação 2, o elemento com contribuição „and‟ e que tem filhos é transformado no elemen-
to VariationPointT da arquitetura, pois corresponde a um ponto de variação.
Na situação 3, o elemento de PL-AOVgraph, tendo ou não filhos, se não for do tipo
„and‟, é transformado em OptionalT (se tiver contribuição „or‟), AlternativeT (se for do tipo
„xor‟) ou InclusiveOrT (se for „inc-or‟). Por fim, na situação 4, caso o elemento tenha um pai
(feature do segundo nível em diante da hierarquia do modelo de features), é transformado no
elemento Representation, que encapsula o elemento System, que contém o componente (cuja
variabilidade é definida pelo elemento PL-AOVgraph que o gera).A Figura 18 apresenta um
trecho de uma das regras de transformação de PL-AOVgraph para PL-AspectualACME, em
que um elemento (task, goal ou softgoal), com contribuição „xor‟, com ou sem filhos, é trans-
formado em um ponto de variação alternativo (AlternativeT).
-- 05 - Elemento de primeiro nível na hierarquia de features, com ou sem filhos e
relacionamento de contribuição 'xor' é transformado em AlternativeT de plaspetua-
lacme:
rule alternativeT{
from
elem : PLAOVgraph!Element ((elem.type=#task or elem.type=#goal or
elem.type=#softgoal) and (elem.refImmediateComposite().oclType() = PLAOV-
graph!Goal_Model)and (elem.hasContribution()) and
elem.getContribution()='xor')
to
var : PLAspectualACME!AlternativeT (
name <- elem.name,
property <- valProp,--gerando property elementType
property <- valProp2,--gerando property variants
44
port <- valPort2, --gerando variation port
port <- valPort --gerando port
...
}
Figura 18: Trecho de regra de transformação ATL
Além de transformar o elemento PL-AOVgraph em um ALternativeT de PL-
AspectualACME, a regra gera a propriedade ElementType, que determina a partir de qual
elemento de PL-AOVgraph (task, goal ou softgoal) foi gerado o componente de PL-
AspectualACME. Como o elemento gerado é um ponto de variação, é gerada, também a pro-
priedade Variants, que lista as variantes desse ponto de variação. Além disso, para componen-
tes, é gerada uma porta e, para pontos de variação, além da porta, uma VariationPortT.
No sentido inverso, as tranformações são mais simples. O componente PL-
AspectualACME é transformado em um elemento PL-AOVgraph. Se houver a propriedade
ElementType, esta define o tipo de elemento (task, goal ou softgoal). Se não houver, é gerada
uma task. O tipo de contribuição é definido pelo tipo de componente (se obrigatório, opcional,
alternativo ou inclusive-or).
Os Apêndices V e VI apresentam o conjunto completo das regras de transformação em
ATL.
45
4. MaRiPLA
Nesse Capítulo, á apresentada a ferramenta MaRiPLA (na seção 4.1), com a sua arqui-
tetura e os detalhes de sua implementação (seção 4.2). As Descrições resultantes são apresen-
tadas na seção 4.3.
4.1 Apresentação e Descrição da Ferramenta
Mapping Requirements to Product Line Architecture (MaRiPLA) é uma ferramenta
implementada em um ambiente Eclipse, que realiza transformações entre modelo de metas,
descrito na linguagem PL-AOVgraph e descrição arquitetural em PL-AspectualACME.
A ferramenta realiza as transformações nos dois sentidos (de descrição de requisitos
para descrição arquitetural e vice-versa), recebendo como entrada uma descrição textual em
uma dessas linguagens e gerando como saída uma descrição textual na outra linguagem. Esse
fluxo ocorre conforme o exposto na Figura 19, em que apresentamos a arquitetura da ferra-
menta.
Figura 19: Arquitetura da ferramenta MaRiPLA
A ferramenta é implementada em ambiente Eclipse, com os recursos do EMF. Os ele-
mentos centrais das tranformações são os metamodelos ecore, a partir dos quais, criamos os
elementos necessários à implementação de MaRiPLA.
Como citado anteriormente, foram criadas transformações em três níveis: texto-a-
modelo (T2M), modelo-a-modelo (M2M) e modelo-a-texto (M2T), todas baseadas nos meta-
modelos Ecore. Assim, com base nos metamodelos de PL-AOVgraph e PL-AspectualACME,
46
foram definidas as gramáticas BNF das duas linguagens no Xtext, em arquivos .xtext, nos
quais foram definidas as sintaxes dessas linguagens. Ao executar essas gramáticas, são gera-
dos analisadores e, então, pode-se abrir os editores específicos na plataforma Eclipse.
No Xtext, as transformações T2M são realizadas através de uma classe Java (escrita
manualmente), que acessa os elementos da linguagem e define em que tipo de modelo aquela
descrição textual pode ser transformada. No caso deste trabalho, a descrição textual é trans-
formada no seu respectivo modelo xmi (OMG-XMI, 2011).
As transformações M2M são realizadas com ATL. Foi criado um projeto ATL para
cada sentido de transformação (requisitos para arquitetura e arquitetura para requisitos). Nes-
ses projetos, foram definidas regras de transformação em arquivos .atl, que foram a base para
gerar as classes Java de transformação do plug-in ATL.
As transformações M2T são realizadas com Acceleo. Um script de templates .mtl foi
definido para cada linguagem (PL-AOVgraph e PL-AspectualACME), especificando sua sin-
taxe (de acordo com a BNF definida no Xtext). Ao salvar o arquivo .mtl, são geradas automa-
ticamente classes Java de transformação.
Todas essas transformações foram integradas em um plug-in Eclipse.
4.2 Detalhes da Implementação
Esta seção apresenta os detalhes da implementação e funcionamento de cada um dos
níveis de transformação de modelos. Na seção 4.2.1, falamos sobre as transformações mode-
lo-modelo, com regras ATL; na seção 4.2.2, falamos sobre as transformações texto-modelo,
com o framework Xtext; na seção 4.2.3, discorremos sobre as transformações modelo-texto
no Acceleo; por fim, mostramos a integração das transformações em um plug-in, originando a
ferramenta MaRiPLA, na seção 4.2.4.
4.2.1 Transformações Modelo a Modelo (M2M)
Como ilustrado na Figura 19, os elementos centrais da ferramenta MaRiPLA são os
metamodelos ecore. Assim, as transformações modelo a modelo que serão executadas entre os
elementos de PL-AOVgraph e de PL-AspectualACME ocorrerão através da manipulação dos
elementos de seus metamodelos, com a linguagem de transformação ATL (ATL, 2006). Dessa
forma, após a definição dos metamodelos de PL-AOVgraph e de PL-AspectualACME (ilus-
trados no Capítulo 2 deste trabalho), criamos um projeto ATL, ao qual denominamos Mari-
plaM2M, conforme a Figura 20.
47
Figura 20: Projeto ATL
No projeto ATL definido, criamos um diretório para os modelos de entrada (InModel),
onde serão armazenados os modelos .xmi de entrada do nosso estudo de caso, em PL-
AOVgraph e em PL-AspectualACME; um diretório para os metamodelos ecore das duas lin-
guagens (Metamodels); um diretório para armazenar os modelos .xmi resultantes, após a apli-
cação das transformações (OutModel); e um último diretório para armazenar os arquivos das
transformações ATL (Transformations). Neste último, criamos três arquivos ATL: (i)
Arq2Req.atl, para as regras de transformação de PL-AspectualACME para PL-AOVgraph; (ii)
Req2Arq.atl, para as regras no sentido inverso; e (iii) Helpers.atl, que consiste em uma biblio-
teca de Helpers ATL, auxiliares para os dois conjuntos de regras.
4.2.1.1 Modelos do Estudo de Caso
Para implementar as transformações, criamos dois modelos de entrada, com base no
estudo de caso da LPS Ginga ForAll. Um em PL-AOVgraph e outro em PL-AspectualACME,
como ilustramos na Figura 21.
48
(a) PL-AOVgraph xmi do Ginga ForAll (b) PL-AspectualACME xmi do Ginga ForAll
Figura 21: Modelos .xmi do Ginga ForAll em PL-AOVgraph e PL-AspectualACME
No modelo PL-AOVgraph, temos (de acordo com o metamodelo apresentado no Capí-
tulo 2) o elemento Aspect_Oriented_Model, que representa um modelo orientado a aspectos.
Inserido nesse modelo, temos o elemento Goal_Model, nomeado „Ginga‟, que é o elemento
correspondente à raiz do modelo de features. O Goal_Model tem diversos elementos, que
correspondem às features do Ginga ForAll. Neste exemplo, ilustramos um trecho do modelo
com algumas dessas features, que são: Tuner (e suas subfeatures FileSystem, IP, Terrestrial e
Satellite), Platform (com suas subfeatures ST, Broadcom, PC e Mobile), Contitional Access
(sem filhos) e Demultiplexer (com suas subfeatures Hardware e Software). Além disso, o
modelo apresenta os relacionamentos de contribuição entre as features, que representam as
características de variabilidade (and, para features obrigatórias, or para features opcionais, xor
para features alternativas do tipo „ou exclusivo‟ e inc-or para features do tipo „ou inclusivo‟).
Também contém relacionamentos de correlação do tipo break (que representam interações do
tipo „feature a exclui feature b‟) entre os elementos Hardware e PC e entre Hardware e Mobi-
49
le. Por fim, temos o relacionamento transversal, que apresenta o elemento Conditional Access
como elemento transversal (Advice), que afeta transversalmente o elemento Tuner (Pointcut).
Equivalente ao modelo PL-AOVgraph da Figura 21-a, temos o modelo PL-
AspectualACME (Figura 21-b) do mesmo estudo de caso. Assim, temos a Family de nome
„Ginga‟, que contém o System também de nome „Ginga‟. O System contém os elementos, que
podem ser componentes, conectores, attachments ou restrições Armani. Nesse caso, temos o
conector „GingaConn‟, que modela o relacionamento transversal entre o componente Conditi-
onal Access e o Ponto de Variação Tuner, através do Base Role Tuner, do Crosscutting Role
Conditional Access e da glue around. Temos os pontos de variação Tuner, Platform e Demul-
tiplexer (obrigatórios e com filhos) e o componente obrigatório e sem filhos Conditional Ac-
cess. Cada ponto de variação tem uma propriedade chamada „variants‟, que contém a lista de
suas variantes e cada variante de um ponto de variação é ilustrada por sua Representation, que
contém um System e o elemento Binding (responsável por conectar uma variante ao seu ponto
de variação, na Representation). Cada System de uma Representation tem o componente que
representa a variante. Esse componente terá os seus elementos internos, como portas, proprie-
dades, entre outros.
Os attachments, no modelo, conectam os roles dos conetores aos respectivos elemen-
tos. Por fim, o elemento Analysis Excludes modela as restrições Armani entre Hardware e PC
e entre Hardware e Mobile.
4.2.1.2 Regras ATL
As regras ATL executam as transformações entre os elementos dos metamodelos eco-
re. Os Apêndices V e VI apresentam as regras ATL para transformações de PL-AOVgraph em
PL-AspectualACME e vice-versa, respectivamente.
4.2.2 Transformações Texto a Modelo (T2M)
A transformação de texto para modelo consiste em transformar a descrição textual de
uma determinada linguagem em sua representação gráfica. Neste trabalho, transformamos as
descrições textuais de PL-AOVgraph e PL-AspectualACME em suas respectivas representa-
ções em xmi, com base no metamodelo ecore que definimos para ambas as linguagens, na fase
das transformações modelo a modelo. Assim, criamos um projeto Xtext para cada linguagem
e associamos esse projeto ao respectivo metamodelo.
Essa associação é feita através do EMF Generator Model, que é um recurso da plata-
forma EMF, que permite a geração automática de código Java referente aos elementos do me-
tamodelo com o qual estivermos trabalhando. Essas classes Java vão servir para geração au-
50
tomática da BNF das duas linguagens, e também para permitir a integração futura de todos os
projetos em um só (confirmando a centralização dos metamodelos nas transformações). Po-
demos criar o modelo .genmodel com base em um diagrama UML, em modelos de classe Ro-
se (IBM/ROSE, 2011), em modelos ecore, entre outros. Ao criarmos um modelo para cada
linguagem, geramos a implementação de ambas as linguagens.
A Figura 22 mostra o Project Explorer do Eclipse, após a criação do .genmodel e ge-
ração de código de ambos os metamodelos.
Figura 22: Modelos .genmodel e pacotes gerados
Os modelos .genmodel criados estão circulados na imagem, assim como os respectivos
pacotes que contém as classes de sua implementação.
Ao criarmos o projeto Xtext, definimos que o mesmo será criado com base em um me-
tamodelo existente e o associamos ao .genmodel previamente criado. No projeto Xtext, defi-
nimos a gramática de cada uma das linguagens. Ao criarmos o projeto Xtext com base em um
modelo existente, como fizemos, uma gramática é gerada automaticamente, de acordo com os
elementos do modelo existente. Podemos, então, editar essa gramática, como desejarmos.
Além disso, no momento de sua criação, devemos definir a extensão da linguagem. A exten-
são de PL-AOVgraph será *.plaovgraph e a extensão de PL-AspectualACME será
*.plaspectualacme.
A Figura 23 mostra os projetos Xtext de PL-AOVgraph e de PL-AspectualACME no
Project Explorer do Eclipse.
51
(a) PL-AOVgraph (b) PL-AspectualACME
Figura 23: Projetos Xtext de PL-AOVgraph e PL-AspectualACME
Os arquivos em destaque, na Figura, PLAOVgraph. Xtext e PLAspectualACME.xtext
são os arquivos da gramática gerada de ambas as linguagens.
Ao finalizar a definição da gramática, geramos a infraestrutura da linguagem, que con-
siste em um conjunto de pacotes e classes que implementam essa infraestrutura.
Ao gerar a gramática, podemos abrir um editor no Eclipse, no qual definimos as des-
crições textuais das linguagens, de acordo com a gramática gerada. Foi neste editor que foram
feitas as descrições do estudo de caso apresentadas nas Figuras 14 e 15, nas seções 2.8.1 e
2.8.2, do Capítulo 2 deste trabalho.
As gramáticas de PL-AOVgraph e de PL-AspectualACME, definidas no projeto Xtext,
podem ser visualizadas nos Apêndices I e II, ao final deste trabalho.
A transformação de texto para modelo é implementada através de uma classe Java que
configura o ResourceSet1 do projeto para receber o arquivo da descrição textual, executar a
transformação em um modelo ecore xmi e armazená-lo em um local definido. Esse modelo
xmi gerado a partir da descrição textual será, no momento da integração dos projetos, utiliza-
do como modelo de entrada para as transformações modelo a modelo no projeto ATL.
1 A interface EMF org.eclipse.emf.ecore.resource.Resource representa uma localização de armazenamento físico (como arquivo ou URL) e
fornece métodos para serializar e carregar dados. Cada recurso (resource) é armazenado em um ResourceSet, que representa uma coleção de
recursos que foram criados e carregados juntos, permitindo referências entre eles.
52
4.2.3 Transformação Modelo a Texto (M2T)
Após a execução da transformação modelo a modelo com ATL, o modelo de saída da
transformação deverá ser transformado em uma descrição textual, que será o resultado final
da transformação completa (texto-modelo-texto). No Acceleo, recebemos um modelo ecore
xmi, que está de acordo com o metamodelo ecore de uma dada linguagem e o transformamos
em descrição textual da dita linguagem. Para isso, utilizamos scripts com templates de código,
de acordo com a sintaxe da linguagem.
Foram criados dois projetos Acceleo, no qual foram definidos scripts com os templa-
tes de cada uma das linguagens: PL-AspectualACME e PL-AOVgraph. No momento da cria-
ção do projeto, selecionamos o tipo de modelo a partir do qual a descrição será gerada (no
nosso caso, o ecore). Assim, fazemos referências aos elementos do modelo, no momento de
definir os templates. O script de templates gera uma classe Java, que é quem implementa as
transformações de modelo em texto.
Os projetos do Acceleo são ilustrados na Figura 24.
Figura 24: Projetos Acceleo de PL-AOVgraph e PL-AspectualACME
Os arquivos generatePLAOVgraph.mtl e generatePLAspectualACME.mtl consistem
nos scripts nos quais criamos os templates das linguagens. Os scripts Acceleo de PL-
AOVgraph e de PL-AspectualACME são exibidos nos Apêndices III e IV, ao final deste tra-
balho.
53
4.2.4 Integração dos Projetos
Após a execução das transformações separadamente, integramos as ferramentas em
um único plug-in Eclipse.
Ao executar o plug-in, geramos o menu da ferramenta MaRiPLA em uma aplicação
Eclipse, conforme Figura 25.
Figura 25: Menu da ferramenta MaRiPLA
O menu MaRiPLA oferece as opções de transformação PL-AOVgraph to PL-
AspectualACME e PL-AspectualACME to PL-AOVgraph. Ao selecionar uma das opções, a
ferramenta pergunta ao usuário se deseja selecionar um arquivo de entrada, conforme Figura
26.
Figura 26: Interação com usuário para opção de selecionar arquivo de entrada
Ao decidirmos selecionar um arquivo, somos direcionados ao sistema de diretórios,
onde escolhemos o arquivo desejado. Nesse caso, o arquivo de entrada PL-AOVgraph, que é a
descrição textual de PL-AOVgraph do Ginga ForAll, apresentada no Capítulo 2. A Figura 27
mostra essa ação.
54
Figura 27: Seleção do arquivo de entrada
Ao selecionar o arquivo de entrada, um projeto é criado no Project Explorer, com a
descrição gerada. As Figuras 28 e 29 mostram a geração das descrições de PL-AOVgraph
para PL-AspectualACME e de PL-AspectualACME para PL-AOVgraph, respectivamente.
Figura 28: Geração de PL-AspectualACME a partir de PL-AOVgraph
Na geração do projeto PL-AspectualACME, com a descrição em PL-AspectualACME,
o usuário pode abrir o arquivo gerado e editá-lo como desejar.
55
Figura 29: Geração de PL-AOVgraph a partir de PL-AspectualACME
De forma análoga ao que expusemos na Figura 28, a descrição de PL-AOVgraph é ge-
rada automaticamente, a partir de PL-AspectualACME, podendo ser aberta no editor e altera-
da como o arquiteto desejar.
As descrições completas de PL-AspectualACME e de PL-AOVgraph, geradas no
momento das transformações, podem ser visualizadas nos Apêndices VII e VIII, respectiva-
mente.
56
5. Avaliação dos Resultados
Neste Capítulo, avaliamos os resultados obtidos nas transformações implementadas.
Os modelos PL-AOVgraph e PL-AspectualACME gerados podem ser visualizados nos Apên-
dices VII e VIII deste trabalho. Na seção 5.1, falamos sobre o Modelo de Qualidade CAFÉ
(Anastasopoulos e Bayer, 2002), utilizado para avaliar as descrições geradas. Como o rastre-
amento é realizado de forma bidirecional, avaliamos a descrição arquitetural PL-
AspectualACME gerada a partir de PL-AOVgraph, na seção 5.2, e, na seção 5.3, avaliamos
PL-AOVgraph gerado a partir de PL-AspectualACME.
5.1 O Modelo de Qualidade CAFÉ
O Modelo de Qualidade CAFÉ (Anastasopoulos e Bayer, 2002) tem por objetivo ofe-
recer suporte à criação e avaliação de arquitetura de LPS, buscando formalizar requisitos de
qualidade, através da definição de uma coleção de atributos de qualidade específicos de famí-
linhas de produtos de software. A avaliação de ambos os modelos foi realizada com base nos
atributos de qualidade definidos neste modelo. Também foi observada a representação de e-
lementos transversais nos dois modelos. Os atributos de qualidade definidos pelo modelo
CAFÉ são:
a) Variabilidade - capacidade de conter partes comuns e variáveis que foram cla-
ramente separadas umas das outras, capturando similaridades, pontos de varia-
ção e suas interdependências, tipos de variabilidades (opcional, alternativa,
cardinalidade);
b) Derivabilidade - capacidade de gerar produtos específicos a partir da infraes-
trutura comum;
c) Reusabilidade - capacidade de reuso para diferentes produtos da LPS;
d) Corretude – extensão em que a arquitetura satisfaz sua especificação e atingir
os propósitos da LPS. Esse atributo envolve as subcaracterísticas de rastreabi-
lidade e completude;
e) Evolutibilidade - capacidade de evolução, lidando com as mudanças e com o
aumento de complexidade, ao longo do tempo;
f) Manutenibilidade - capacidade de a arquitetura ser modificada, quando neces-
sário.
57
5.2 Avaliação da Descrição PL-AspectualACME gerada a partir de PL-
AOVgraph
Com relação ao critério de variabilidade, a descrição gerada apresenta os elementos
comuns e variáveis, através dos tipos de componentes obrigatórios (Components e Variation-
PointT, apresentados na descrição gerada) e pontos de variabilidade (OptionalT e Alternati-
veT, apresentados na descrição gerada), que são definidos com base no tipo da contribuição
do modelo PL-AOVgraph de origem (capturando tipos de variabilidades and, or, xor, inc-or).
Além disso, a arquitetura define relações de dependências entre features, através das restri-
ções Armani. Assim, determinamos que esse critério é satisfeito pela arquitetura gerada.
O critério de derivabilidade é, também, atendido em razão do suporte que a arquitetu-
ra fornece para derivação de produtos específicos. Os pontos de variação e os componentes
obrigatórios gerados são elementos comuns, que serão reusados em cada produto, permitindo
essa capacidade de derivação, através de suas portas (Port e/ou VariationPortT).
A reusabilidade pode ser atendida pelo núcleo de elementos comuns da arquitetura.
Os componentes obrigatórios e os pontos de variação (VariationPointT) gerados são altamen-
te reusáveis, pois são comuns a todos os elementos da LPS. No estudo de caso específico,
todos os elementos de primeiro nível da hierarquia são obrigatórios ou pontos de variação.
Um exemplo é o ponto de variação Tuner, que é obrigatório e possui quatro variantes opcio-
nais (IP, Terrestrial, FileSystem e Satellite). O ponto de variação, nesse caso, é um elemento
comum a todos os produtos da LPS, por ser obrigatório, o que permite que o mesmo seja reu-
tilizado em cada uma das combinações diferentes de seleção de suas variantes.
Com relação ao atributo corretude, analisamos o atendimento da arquitetura gerada à
sua especificação. Nesse quesito, apenas a corretude sintática pode ser garantida, uma vez que
a corretude semântica depende de fatores subjetivos, dependendo da interferência do arquiteto
(como, por exemplo, com relação à nomeação dos elementos). O modelo gerado é sintatica-
mente bem formado, atendendo as regras específicas da linguagem de descrição arquitetural.
As subcaracterísticas desse atributo (rastreabilidade e completude) são, também, atendidas,
uma vez que são gerados todos os tipos de elementos PL-AspectualACME (completude),
como family, system, components, ports, roles, properties, analysis. Cada elemento foi gerado
a partir de elementos PL-AOVgraph, e isso contribui com a característica da rastreabilidade,
que consiste na capacidade da arquitetura ser mapeada para (ou a partir de) um modelo de
outra atividade do ciclo de desenvolvimento. Uma pequena limitação nesse quesito, porém,
foi a falta de elementos PL-AOVgraph que gerem conectores comuns de PL-
58
AspectualACME. No caso do relacionamento transversal, geramos o conector aspectual. Co-
nectores comuns, porém, não foram contemplados na transformação, em virtude dessa carên-
cia. Com relação aos elementos de PL-AOVgraph que não possuem correspondentes em PL-
AspectualACME, estes geraram propriedades (como o operand, do relacionamento transver-
sal, por exemplo, que gerou a property operand, no conector aspectual). Com relação à nome-
ação de certos elementos,observamos que alguns nomes gerados são extensos, uma vez que a
implementação da ferramenta os gera com base nos nomes dos elementos de origem e acres-
centando informações que permitem uma melhor identificação. Um exemplo disso são as por-
tas geradas, que recebem o nome do componente que as contém, acrescentando-se a String
„Port’ (para porta comum) ou „VarPort’ (para porta de variação). O elemento „Conditiona-
lAccess’, por exemplo, gerou o componente „ConditionalAcces’ com a porta „ConditionalAc-
cessPort’. Apesar de não constituir uma regra específica da linguagem, não é uma boa prática
atribuir nomes muito extensos aos elementos de um modelo. Em casos como esse, porém, o
arquiteto pode intervir e editar os nomes.
Com relação ao atributo evolutibilidade, observamos que o modelo gerado oferece a
possibilidade de intervenção do arquiteto em qualquer momento ou localização da descrição
arquitetural, nas possíveis evoluções da LPS. Essa capacidade de evolução é suportada pela (e
também suporta a) rastreabilidade, pois evoluções na arquitetura serão incorporadas ao mo-
delo de requisitos e vice-versa.
A manutenibilidade também é permitida, de acordo com os mesmos critérios do atri-
buto evolutibilidade. O arquiteto pode interferir no modelo gerado no momento que desejar,
editando-o e podendo, assim, aplicar as alterações no modelo de requisitos via transformação
automatizada na ferramenta MaRiPLA.
Por fim, com relação à representação de elementos transversais, temos o conector as-
pectual, com base role, crosscutting role e glue, representando a relação transversal.
5.3 Avaliação da Descrição PL-AOVgraph gerada a partir de PL-
AspectualACME
No modelo PL-AOVgraph gerado, a variabilidade é observada a partir dos relacio-
namentos de contribuição (and, or, xor, inc-or), que identificam os elementos obrigatórios,
opcionais e alternativos da LPS. As restrições entre features são, por sua vez, representadas
pelos relacionamentos de correlação do tipo break, entre os elementos hardware e pc e hard-
ware e mobile, do estudo de caso.
59
Os relacionamentos de contribuição também permitem que seja atendido o atributo
derivabilidade, pois elementos com contribuição and (comuns a todos os produtos da LPS)
que possuem filhos com contribuição or, xor ou inc-or, definem a derivação dos produtos
específicos.
Da mesma forma que na arquitetura, a reusabilidade pode ser atendida por meio dos
elementos do núcleo comum da LPS. Um elemento com contribuição and com filhos or, xor
ou inc-or, por exemplo, pode ser reusado em várias configurações diferentes de seus filhos
que são variáveis.
Com relação à corretude, observamos que os elementos gerados de PL-AOVgraph es-
tão todos exatamente em conformidade com sua semântica. Tanto os elementos quanto os
relacionamentos foram gerados com localização exata e na hierarquia correta.
É possível que uma arquitetura descrita do zero, ou a partir de um modelo de requisi-
tos diferente do modelo de metas, não contemple todos os elementos que são definidos neste
tipo de modelo. Assim, na análise da completude, que é sub-atributo da corretude, PL-
AOVgraph gerado de PL-AspectualACME contempla todos os elementos específicos do es-
tudo de caso Ginga ForAll. Componentes de PL-AspectualACME foram transformados em
tasks e a contribuição (and, or, xor, inc-or) é definida pelo tipo de componente (obrigatório,
alternativo, opcional, inclusive-or). A partir das restrições Armani, foram geradas correlações
entre elementos e a partir do conector aspectual, foi gerado um relacionamento transversal.
Não houve geração de goals nem de softgoals, uma vez que a arquitetura descrita do zero não
define esse tipo de elemento. No trecho de descrição do Ginga ForAll usado, de toda forma,
temos apenas tasks. Se houvesse tais elementos, os mesmos seriam gerados caso a descrição
arquitetural de entrada fosse criada a partir de um PL-AOVgraph ou por um arquiteto que
conhecesse o modelo de metas e representasse esses tipos nas propriedades dos componentes.
No relacionamento transversal, não são gerados elementos como Intertype Declarations, at-
tributtes ou elements. Isso ocorre, também, por a arquitetura ser gerada do zero (sem definição
das propriedades), mas de qualquer forma, o estudo de caso não contempla tais elementos
(que estariam representados, também, em propriedades da arquitetura). O mesmo ocorre com
os diversos tipos de propriedades de PL-AOVgraph.
Com relação à rastreabilidade, que é outro sub-atributo da corretude, conseguimos
definir correspondências relativamente precisas entre os elementos de PL-AspectualACME e
PL-AOVgraph. Houve uma dificuldade, porém, nesse aspecto, em virtude do metamodelo de
PL-AOVgraph possuir uma quantidade de elementos superior à quantidade de elementos do
metamodelo de PL-AspectualACME. O relacionamento transversal de PL-AOVgraph é repre-
60
sentado com uma riqueza maior de detalhes do que a descrição arquitetural. A rastreabilida-
de, nesse caso, é garantida por meio das propriedades de PL-AspectualACME, bem como
pela possibilidade da linguagem ATL de permitir geração de vários elementos a partir de um
único. Isso nos permite afirmar que a ferramenta define um modelo de rastreabilidade simpli-
ficado, uma vez que as propriedades permitem identificar o elemento de origem. Um conector
aspectual de PL-AspectualACME, por exemplo, possui os elementos BaseRole, Crosscuttin-
gRole e Glue. A partir desse conector, porém, devemos gerar um relacionamento transversal
com advice (com joinPointAdvice e advice category) e pointcut (com operand, operator e
JoinPointPointcut) em PL-AOVgraph. Além disso, há as Intertype Declarations, com Ele-
ments e Attributes. Como representar tantos elementos e sub-elementos a partir de um simples
conector? A Figura 30 ilustra essa possibilidade.
Figura 30: Rastreamento do Conector Aspectual de PL-AspectualACME para o relacionamento
transversal de PL-AOVgraph
O conector aspectual gerou o relacionamento transversal. Durante a transformação, fo-
ram criados os elementos Advice e Pointcut (a regra ATL gera o elemento e permite criar,
internamente, os seus sub-elementos). Intertype Declaration seria gerado a partir de uma pro-
priedade específica do conector (não foi gerado, por não ser contemplado no estudo de caso).
Advice Category foi gerado a partir da Glue do conector, pois ambos representam o tipo do
advice no relacionamento transversal (around, before ou after). JoinPoint Pointcut é referente
ao elemento ao qual o BaseRole está conectado. Operand e Operator, por sua vez, são gerados
a partir de propriedades do BaseRole. Por fim, JoinPoint Advice é gerado a partir do elemento
ao qual o CrosscuttingRole se liga.
Os atributos evolutibilidade e manutenibilidade são garantidos, na descrição PL-
AOVgraph gerada, pelas mesmas razões que em PL-AspectualACME. A descrição é gerada
em um editor em que o engenheiro é livre para acrescentar ou alterar as informações que de-
61
sejar (dentro das regras específicas da linguagem), podendo, então, re-executar as transforma-
ções, transferindo as alterações ou acréscimos à arquitetura.
É importante salientar que as descrições geradas foram avaliadas subjetivamente, uma
vez que o modelo de qualidade não define métricas, mas apenas atributos de qualidade especí-
ficos.
62
6. Trabalhos Relacionados
Este Capítulo descreve brevemente os trabalhos relacionados ao tema desta disserta-
ção, citando seus pontos positivos e limitações, com relação à abordagem atual.
6.1 FArM (Sochos et al, 2006)
Na abordagem FArM (Feature-Architecture Mapping) (Sochos et al, 2006), o modelo
de features é progressivamente refinado, no intuito de enriquecer as informações contidas em
suas features.
Nesse refinamento, são definidas quatro transformações: (i) features de que expressam
atributos de qualidade e features não relacionadas à arquitetura são „resolvidas‟ a fim de gerar
um modelo de features com apenas features funcionais (podendo-se integrar features com
outras features, remover features ou adicionar novas features); (ii) features que expressam
requisitos arquiteturais difíceis de atender também são „resolvidas‟ com os mesmos critérios
que na primeira transformação; (iii) são criadas relações de interação entre as features do mo-
delo de features resultante das duas primeiras transformações (em que uma feature usa outra,
altera o comportamento de outra ou então contradiz o comportamento de outra) e (iv) são cri-
adas relações de hierarquia entra as features (em que subfeatures especializam feature pai, é
parte da feature pai ou apresentam alternativas para a feature pai).
Ao longo das transformações, ocorre geração paralela de componentes. Ao final, o ar-
quiteto escolhe um estilo arquitetural e esses componentes são adaptados ao estilo escolhido.
O método leva em consideração, nessa adaptação, a composição de produto e a flexibilidade
da LPS e busca atender essas questões através de uma integração explícita através de meca-
nismos de plugin. A feature raiz do modelo de features implementa uma plataforma de cone-
xão, em que serão conectados os componentes gerados.
A abordagem trata de uma questão importante, com relação a modelos de requisitos de
LPS, uma vez que busca enriquecer o modelo de features que, por si só, carece de informa-
ções importantes para definição da arquitetura de LPS. A resolução dos elementos não-
arquiteturais e não funcionais, bem como a interação entre features e hierarquia, que são rela-
ções específicas de LPS que não podem ser abstraídas, permitem o mapeamento entre requisi-
tos e arquitetura.
Em MaRiPLA, resolvemos essa questão usando o modelo orientado a objetivos, que
possui maior riqueza de informações que o modelo de features, definindo elementos específi-
63
cos para requisitos não funcionais e interações entre features, por exemplo. Se houver um
modelo de goals definido, o esforço para melhoria do modelo de features é, assim, reduzido.
É importante salientar, porém, que esse enriquecimento do modelo de features realiza-
do com o método poderia contribuir para a nossa abordagem, uma vez que o modelo de goals
é produzido a partir de modelo de features. Um modelo de features enriquecido poderia gerar
um modelo de goals também mais robusto.
Outro aspecto a observar na abordagem FArM, é que não trata dos interesses transver-
sais que uma LPS pode apresentar. É importante tratar tais interesses, uma vez que a definição
de tais interesses na atividade inicial de requisitos, unida ao mapeamento, facilita a detecção
desses interesses na atividade de arquitetura. MaRiPLA utiliza modelo de requisitos e arquite-
tural orientados a aspectos, tratando, assim, essa questão.
Por fim, o método FArM é um método ainda manual de mapeamento, que utiliza duas
equipes experientes em requisitos e design arquitetural para manipular o modelo de features e
descrever os componentes gerados. Ainda há a lacuna de uma ferramenta específica e integra-
da, que automatize as transformações. Os autores do trabalho sugerem o uso de diversas fer-
ramentas existentes para manipulação dos modelos.
A automatização da ferramenta MaRiPLA, por sua vez, reduz esforço e tempo de de-
rivação de arquitetura, gerando a descrição arquitetural a partir de requisitos e permitindo
intervenção do arquiteto, caso necessário, para acrescentar ou alterar informações.
6.2 A Metamodeling Approach to Tracing Variability between Requirements and
Architecture in Software Product Lines (Moon et al, 2007)
O trabalho sugere a estratégia de metamodelagem para dar suporte ao rastreamento da
variabilidade em requisitos e arquitetura de LPS.
Os autores propõem dois metamodelos, representando requisitos de domínio e arquite-
tura de domínio de LPS, com base na Reusable Asset Specification (OMG-RAS, 2005), expli-
cam a variabilidade dos elementos de cada metamodelo e, então, definem o rastreamento entre
esses dois metamodelos, em um terceiro metamodelo.
Na especificação dos metamodelos, o modelo RAS é estendido, através da adição de
novos elementos de modelagem de requisitos (para o metamodelo de requisitos) e de modela-
gem arquitetural (para o metamodelo de arquitetura), além de elementos que expressam varia-
bilidades.
64
A partir desses dois metamodelos criados, define-se um terceiro metamodelo, que ex-
pressa os links de rastreabilidade entre requisitos e arquitetura, ilustrando graficamente os
relacionamentos de dependência entre os artefatos de ambos os metamodelos, e definindo
matrizes de rastreabilidade, que fornecem o raciocínio para as decisões de similaridades e
variabilidades nos dois modelos e seus artefatos.
A metamodelagem com base em um padrão específico (no caso, o padrão RAS) sim-
plifica o rastreameto entre os dois modelos, uma vez que ambos os metamodelos têm um nú-
cleo comum, estendendo apenas os elementos específicos de requisitos e arquitetura de LPS.
Os metamodelos usados em MaRiPLA, apesar de ambos serem definidos com base em uma
mesma tecnologia (ecore-EMF), não apresentam essa mesma similaridade de núcleo (devido à
peculiaridade de cada uma das linguagens), o que torna o mapeamento mais complexo.
Outra diferença é que no presente trabalho o mapeamento não se dá por meio de me-
tamodelagem, mas são definidas regras de mapeamento precisas, para rastrear elemento a
elemento dos metamodelos, além de utilizar DSLs específicas e tecnologias MDD para definir
transformações em vários níveis.
Além disso, a mesma tecnologia utilizada em MaRiPLA poderia ser utilizada para
descrever os mapeamentos, uma vez que a abordagem ainda não possui uma ferramenta espe-
cífica que os suporte e afirma-se que a rastreabilidade apresentada pode ser descrita em OCL
(Object Constraint Language) (OMG-OCL, 2012) e diversas ferramentas CASE UML podem
avaliar as expressões para reforçar essa rastreabilidade.
6.3 A Model Transformation Approach to Derive Architectural Models from
Goal-Oriented Requirement Models (Lucena, 2010)
Este trabalho realiza transformação entre modelo de requisitos orientado a objetivos e
descrição arquitetural. O modelo de requisitos é o modelo i* (Yu, 1995) e o modelo arquitetu-
ral é a ADL ACME (Garlan et al, 1997).
Na abordagem, é proposto um processo de mapeamento, em que são realizadas três a-
tividades principais: (i) análise dos elementos internos do modelo; (ii) definição de regras de
transformações horizontais, para lidar com a complexidade inerente a modelos i*, aproximan-
do design arquitetural, com a geração de um modelo i* modular e (iii) definição de regras de
mapeamento verticais para transformar i* modular em ACME. A arquitetura gerada é refina-
da, para incluir os requisitos não funcionais e, por fim, é avaliada com base em métricas de
modularidade, comparando soluções arquiteturais obtidas através da abordagem com soluções
arquiteturais definidas de forma ad hoc.
65
A abordagem tem similaridades com o trabalho realizado com MaRiPLA, por tratar da
rastreabilidade entre modelo de requisitos orientado a objetivos e descrição arquitetural. É
usado o modelo i*, diferente e mais complexo que o PL-AOVgraph que usamos em MaRi-
PLA. Porém, essa complexidade é tratada com a definição de regras horizontais.
O trabalho não abrange o universo das LPS, como o MaRiPLA. Por isso, tanto o mo-
delo de requisitos como a ADL não são específicos de LPS. Outra diferença com relação a
MaRiPLA é que o mapeamento é unidirecional e também não tem um suporte de uma ferra-
menta que automatize o processo.
6.4 MaRiSA-MDD (Medeiros, 2008)
MaRiSA-MDD (Medeiros, 2008) é uma ferramenta de mapeamento bidirecional entre
requisitos e arquitetura de software, com tecnologias MDD, que transforma especificação
textual AOV-Graph em especificação textual AspectualACME e vice-versa.
A ferramenta é executada em plataforma Eclipse e conta com regras de transformação
ATL, para transformações modelo a modelo, e o mecanismo TCS (Textual Concrete Syntax)
(TCS, 2006), para transformações texto a modelo e modelo a texto.
A arquitetura da ferramenta MaRiPLA (proposta no presente trabalho) é similar à da
ferramenta MaRiSA, consistindo aquela ferramenta na extensão desta, pois MaRiSA, apesar
de implementar transformações entre modelo de requisitos e descrição arquitetural orientados
a aspectos e com tecnologias MDD, não abrange o universo de LPS.
6.5 ReqSys (Santos, 2010) e ReqSys-MDD
O trabalho de Santos (2010) define o modelo de metas PL-AOVgraph, como extensão
de AOV-Graph e apresenta ReqSys, que é uma ferramenta que automatiza transformação de
modelo de features em modelo de metas PL-AOVgraph. A tecnologia utilizada na implemen-
tação da ferramenta é a linguagem de programação Java.
Atualmente, está em andamento um trabalho de migração da ferramenta ReqSys para
as tecnologias MDD, o ReqSys-MDD. A proposta realiza transformações bidirecionais entre
modelo de features e modelos de metas PL-AOVgraph, nos níveis modelo a modelo, texto a
modelo e modelo a texto, de forma similar ao que ocorre em MaRiPLA.
Como ReqSys-MDD será executado apenas no nível de requisitos, os resultados das
transformações realizadas na ferramenta poderão ser utilizados como insumos para as trans-
formações realizadas em MaRiPLA.
66
7. Conclusão
Para evitar a perda de informações entre as atividades de requisitos e arquitetura de
software, é importante que haja uma correspondência entre essas duas atividades do ciclo de
vida do software. Em LPS, essa correspondência precisa, ainda, oferecer suporte ao gerenci-
amento das variabilidades.
Este trabalho apresentou uma estratégia de mapeamento bidirecional entre modelo de
requisitos de LPS, descrito em PL-AOVgraph, e descrição arquitetural de LPS, representada
por PL-AspectualACME. Para a realização desses mapeamentos foi criado um processo e
definidas as regras de mapeamento.
Para automatizar os mapeamentos, foi desenvolvida a ferramenta MaRiPLA – Map-
ping Requirements to Product Line Architecture – a partir da criação dos metamodelos das
duas linguagens e a definição de regras de transformações nos níveis modelo a modelo (com
ATL), texto a modelo (com Xtext) e modelo a texto (com Acceleo).
Apresentamos a arquitetura e o funcionamento da ferramenta, com os detalhes de sua
implementação e executamos as transformações, em nosso estudo de caso: a LPS Ginga Fo-
rAll.
As descrições geradas foram avaliadas com relação a atributos de qualidade específi-
cos de LPS extraídos do Modelo de Qualidade CAFÉ (Anastasopoulos e Bayer, 2002): varia-
bilidade, derivabilidade, reusabilidade, corretude (com os sub-atributos rastreabilidade e com-
pletude), evolutibilidade e manutenibilidade.
Por fim, discorremos sobre alguns trabalhos relacionados, explicitando suas vantagens
e limitações com relação à nossa abordagem.
7.1 Contribuições
A principal contribuição deste trabalho é a integração entre as atividades de requisitos
e arquitetura de LPS, através da transformação de descrição de requisitos em descrição arqui-
tetural e vice-versa.
Outras contribuições incluem:
a) Criação dos metamodelos de PL-AOVgraph e PL-AspectualACME, estenden-
do AOVgraph e AspectualACME, respectivamente;
b) Definição dos modelos ecore xmi (em conformidade com os respectivos meta-
modelos), favorecendo a extensibilidade da ferramenta, uma vez que o modelo
67
serve como código intermediário, podendo ser mapeado para diferen tes lin-
guagens;
c) Definição de um processo de mapeamento entre as duas linguagens;
d) Definição de regras de mapeamento entre os elementos das duas linguagens,
estendendo as regras existentes em MaRiSA-MDD (Medeiros, 2008), acres-
centando transformações que lidam com variabilidades e adaptando as regras
existentes às atualizações realizadas nos metamodelos das linguagens de ori-
gem e destino;
e) Definição de regras de transformações ATL entre os elementos dos metamode-
los, estendendo as regras existentes em MaRiSA-MDD (Medeiros, 2008), a-
crescentando transformações que lidam com variabilidades e adaptando as re-
gras existentes às atualizações realizadas nos metamodelos das linguagens de
origem e destino;
f) Definição de gramática de cada uma das linguagens na ferramenta Xtext, com
implementação das transformações texto a modelo;
g) Definição de templates Acceleo para a transformação modelo a texto das duas
linguagens;
h) Definição da ferramenta MaRiPLA, que integra essas transformações em um
único ambiente
i) Avaliação da ferramenta, através de um estudo de caso: a LPS Ginga ForAll.
7.2 Trabalhos Futuros
Um trabalho que já está sendo desenvolvido e que é diretamente relacionado a este
trabalho é o ReqSys-MDD (ver seção 6.6). A proposta do ReqSys-MDD, aliada a MaRiPLA,
são o início de uma possível suíte de ferramentas implementadas em tecnologias MDD, to-
talmente voltada para o universo das LPS orientadas a aspectos. Assim, a fim de percorrer
desde a primeira atividade, da definição de requisitos com o modelo de features, até a imple-
mentação, uma idéia de trabalho futuro seria a definição e desenvolvimento de ferramentas
similares para transformações entre arquitetura e projeto detalhado e de projeto detalhado à
implementação.
Há um trabalho em desenvolvimento, atualmente, na UFRN, de criação de ferramenta
gráfica de visualização e edição de PL-AspectualACME. Uma ferramenta similar de PL-
AOVgraph já existe (Santos, 2010). Acoplar ao MaRiPLA essas ferramentas de visualização e
edição gráficas das duas linguagens seria outra idéia de trabalho futuro.
68
Uma dificuldade ainda existente, com relação a PL-AOVgraph, é a questão da decisão
de quais elementos da linguagem (task, goal ou softgoal) são gerados por quais features do
modelo de features. É necessário que se estabeleçam heurísticas com base nos nomes ou na
semântica dos elementos, para essa importante decisão.
Outra idéia de trabalho futuro seria usar o mesmo estudo de caso em outras aborda-
gens (alguns dos trabalhos relacionados), a fim de estabelecer uma comparação e, também,
avaliar a ferramenta com outros estudos de caso, além do Ginga ForAll.
Também poderia ser realizado o mapeamento para PL-AspectualACME a partir de ou-
tros modelos de metas, ou de PL-AOVgraph para outras ADLs, com o objetivo de estabelecer
comparações entre as regras e os resultados obtidos.
Uma lacuna neste trabalho, que poderia ser solucionada em um trabalho futuro seria a
definição de métricas para avaliar arquiteturas de LPS (com base em ADL), a fim de permitir
uma avaliação de arquitetura mais formal e objetiva. Essa definição de métricas poderia se
estender, também, à avaliação do modelo de metas de LPS.
69
Referências
(ACCELEO, 2011) ACCELEO. 2011. Disponível em:
<http://www.acceleo.org/pages/home/en>. Acesso em: novembro de 2011.
(Adachi, 2009) Adachi, E. PL-AspectualACME: Uma Linguagem de Descrição Arquitetural
Orientada a Aspectos para Linhas de Produtos de Software. Natal, 2009. 63p. Monografia de
Graduação UFRN.
(Adachi et al 2011) Adachi, E.; Batista, T.; Garcia, A.; Silva, E. PL-AspectualACME: Na
Aspect-Oriented Architectural Description Language for Software Product Lines. In: Pro-
ceedings of the 5th European Conference on Software Architecture. (2011)
(Anastasopoulos e Bayer, 2002) Product Family Specific Quality Attributes (IESE Report Nº
042.02/E, Versão 1.0). Kaiserlautern, Alemanha: Fraunhofer Institut Experimentelles Soft-
ware Engineering. 2002
(AOSD, 2011) Aspect-Oriented Software Development. 2011. Disponível em:
<http://aosd.net/>. Acesso em: dezembro de 2011.
(ATL, 2006) ATL (Atlas Transformation Language). 2006. Disponível em:
<http://www.eclipse.org/m2m/atl>. Acesso em: janeiro de 2011.
(ATLAS, 2010) ATLAS. 2010. Disponível em: <http://atlas.lina.univ-nantes.fr/atlas>. Acesso
em: dezembro de 2011.
(Batista et al 2006) Batista, T.; Chavez, C. F.; Garcia, A.; Sant‟Anna, C.; Kulesza, U.; Rashid,
A.; Castor Filho, F. Reflections on Architectural Connection: Seven Issues on Aspects and
ADLs. Workshop on Early Aspects, ICSE'06, May 2006, Shanghai, China.
(Clements, 1996) Paul C. Clements. A survey of architecture description languages. In Pro-
ceedings of International Workshop on Software Specification and Design (IWSSD), pp 16–
25, 1996.
(EA, 2011) Early Aspects: Aspect-Oriented Requirements Engineering and Architecture De-
sign. Disponível em: http://www.early-aspects.net/ Acesso em maio de 2011.
(ECLIPSE, 2011) ECLIPSE. Disponível em: <http://www.eclipse.org/>. Acesso em: janeiro
de 2011.
(EMF, 2011) EMF. Disponível em <http://www.eclipse.org/modeling/emf/>. Acesso em:
janeiro de 2011.
(Garlan et al, 1997) Garlan, D.; Monroe, R.; Wile, D. ACME: An Architecture Description
Interchange Language. In: Proceedings of CASCON 97. Toronto, Ontario, November 1997,
pp. 169-183.
(Ginga, 2006) Ginga: the Brazilian Terrestrial Digital TV System Middleware. Disponível
em: <http://www.ginga.org.br/>. Acesso em: dezembro de 2011.
70
(Giorgini et al, 2002) Giorgini, P.; Mylopoulos, J.; Nicchiarelli, E.; Sebastián, R.; Reasoning
with goal models. In: Proceedings of the 21st International Conference on Conceptual Mod-
eling.2002. pp.167-181.
(Kang et al, 1990) Kang, K.; Cohen, S.; Hess, J.; Novak, W.; Peterson, A. S. Feature-
Oriented Domain Analysis (FODA) Feasibility Study. Relatório Técnico. Carnegie Mellon
University Engineering Institute. 1990.
(Linden et al, 2007) Linden, F.; Schmid, K.; Rommes, E. Software Product Line in Action:
The Best Industrial Practice in Product Line Engineering. Springer, 2007.
(Lucena, 2010) Lucena, M. J. N. R. STREAM: A Systematic Process to Derive Architectural
Models from Requirements Models. Tese de Doutorado. UFPE. Recife, 2010.
(Medeiros, 2008) Medeiros, A.L.F. MARISA-MDD: Uma Abordagem para Transformações
entre Modelos Orientados a Aspectos: dos Requisitos ao Projeto Detalhado. Dissertação de
Mestrado. UFRN, 2008.
(Monroe, 1998) Monroe, R. Capturing Software Architecture Design Expertise With Arma-
ni. CMU School of Computer Science Technical Report CMU-CS-98-163. 1998.
(Moon et al, 2007) Moon, M; Chae, H. S.; Nam, T.; Yeom, K. A Metamodeling Approach to
Tracing Variability between Requirements and Architecture in Software Product Lines. In:
Seventh International Conference on Computer and Information Technology. 2007. Fukushi-
ma, Japão, pp927-933.
(Nuseibeh e Easterbrook, 2000) Nuseibeh, B.; Easterbrook, S. Requirements Engineering: a
roadmap. In: International Conference on Software Engineering. 2000. Limerick, Ireland.
(OBEO, 2011) OBEO. 2011. Disponível em: < http://obeo.com/>. Acesso em: dezembro de
2011.
(OMG-MOF, 2008) OBJECT MANAGEMENT GROUP (OMG). MOF QVT Final Adopted
Specification (ptc/05-11-01). Disponível em: <http://www.omg.org/docs/ptc/05-11-01.pdf>.
Acesso em: janeiro de 2008.
(OMG-OCL, 2012) OCL - Object Constraint Language. 2012. Disponível em:
<http://www.omg.org/spec/OCL/>. Acesso em: janeiro de 2012.
(OMG-XMI, 2011) OBJECT MANAGEMENT GROUP (OMG). XMI – XML Metadata In-
terchance. Disponível em: <www.omg.org/technology/documents/formal/xmi.htm>. Acesso
em: janeiro de 2011.
(OMG-RAS, 2005) OBJECT MANAGEMENT GROUP (OMG), Reusable Asset Specification
(RAS) Version2.2, < http://www.omg.org/spec/RAS/ >, Nov. 2005
(Santos, 2010) Santos, L. O. PL-AOVgraph: Uma extensão de AOV-Graph para Linha de
Produto de software. Natal, 2010. 84p. Monografia de Graduação UERN. Disponível em:
<https://sites.google.com/site/plaovgraph/>. Acesso em: dezembro de 2011.
71
(Saraiva et al, 2010) Saraiva, D., Pereira, L., Batista, T., Delicato, F., Pires, P., Kulesza, U.,
Araujo, R., Freitas, T., Miranda, S., Souto, A. L., Coelho, R.: Architecting a Model-Driven
Aspect-Oriented Product Line for a Digital TV Middleware: A Refactoring Experience. In:
Proceedings of the 4th European Conference on Software Architecture. (2010)
(Shaw e Garlan, 1993) Shaw, M.; Garlan, D. An Introduction to Software Architecture. Ad-
vances in Software Engineering and Knowledge Engineering. Vol. 1. Editado por V.Ambriola
e G.Tortora. World Scientific Publishing Company. New Jersey, 1993.
(Silva, 2006) Silva, L. F. da. Uma Estratégia Orientada a Aspectos em Modelagem de Re-
quisitos. Tese de Doutorado, PUC-Rio, Rio de Janeiro, 2006.
(Sochos et al, 2006) Sochos, P.; Philippow, I; Riebisch, M. The Feature-Architecture Map-
ping (FArM) Method for Feature-Oriented Development of Software Product Lines. Dis-
ponível em: <http://www.theoinf.tu-ilmenau.de/~riebisch/home/publ/ecbs06-FArMfinal.pdf>.
Acesso em: Janeiro de 2012.
(Thayer e Dorfman, 1997) Richard H. Thayer e Merlin Dorfman 1997. Software Require-
ments Engineering. 2. ed. IEEE Computer Society Press.
(TCS, 2006) TCS. Textual Concrete Syntax. 2006. Disponível em: <
http://wiki.eclipse.org/TCS>. Acesso em: junho, 2011.
(UML, 2011) UML. Unified Modelling Language. 2011. Disponível em:
<http://www.uml.org/>. Acesso em: dezembro de 2011.
(XHTML, 2011) XHTML. eXtensible Hypertext Markup Language. 2011. Disponível em: <
http://www.w3schools.com/html/html_xhtml.asp >. Acesso em: dezembro de 2011.
(XTEXT, 2011) XTEXT. 2011. Disponível em: <http://www.eclipse.org/Xtext/>. Acesso em:
novembro de 2011.
(Yu, 1995) Yu, E. Modeling Strategic Relationships for Process Reengineering. Tese de
Doutorado. Department of Computer Science, University of Toronto. Canada, 1995.
(Yu et al, 2004) YU, Y.; Leite, J. C.; Mylopoulos, J. From Goals to Aspects: discovering as-
pects from requirements goal models. Trabalho apresentado no IEEE International Sympo-
sium on Requirements Engineering - RE‟04, United Kingdom, 2004.
72
Apêndice I – Gramática Xtext do PL-AOVgraph
grammar dimap.ufrn.br.xtext.plaovgraph.PLAOVgraph with
org.eclipse.xtext.common.Terminals
import "platform:/resource/MaRiPLAM2M/Metamodels/PLAOVgraph.ecore"
import "http://www.eclipse.org/emf/2002/Ecore" as ecore
Aspect_Oriented_Model returns Aspect_Oriented_Model:
'aspect_oriented_model' '{'
goalmodel+=(Goal_Model)+
'}' ';';
Goal_Model returns Goal_Model:
'goal_model' name=STRING '{'
('property' '{' (property+=Property)+ '}')?
element+=(Element)*
relationship+=(Correlation | Crosscutting)*
'}';
Element returns Element:
type=ElementTypes name=STRING '(' (relationship+=Contribution)? ')'
'{'
('property' '{' (property+=Property)+ '}')?
element+=(Element)*
'}' ;
enum ElementTypes returns ElementTypes:
task = 'task' | goal = 'goal' | softgoal = 'softgoal' | task_ref =
'task_ref' | goal_ref = 'goal_ref' | softgoal_ref = 'softgoal_ref';
Property returns Property:
IsFeature | Cardinality | GroupFeature | Generic_Property;
IsFeature returns IsFeature:
'isFeature' '=' label=IsFeatureTypes ';';
enum IsFeatureTypes returns IsFeatureTypes:
no = 'no' | yes = 'yes';
Cardinality returns Cardinality:
'cardinalityMin' '=' cardinalityMin=EString ';'
'cardinalityMax' '=' cardinalityMax=EString ';';
GroupFeature returns GroupFeature:
'groupFeature' '=' '(' ('task' | 'goal' | 'softgoal')
source=[Element|STRING] ("," ('task' | 'goal' | 'softgoal')
source=[Element|STRING])* ')' ';'
'cardinalityGroupMin' '=' cardinalityGroupMin=EString ';'
'cardinalityGroupMax' '=' cardinalityGroupMax=EString ';';
Generic_Property returns Generic_Property:
name=ID '=' value=ID ';';
Contribution returns Contribution:
label=DecompositionCategory;
73
enum DecompositionCategory returns DecompositionCategory:
and = 'and' | or = 'or' | xor = 'xor' | inc_or = 'inc-or';
Correlation returns Correlation:
'correlation' '(' label=CorrelationCategory ')' '{'
'source' ':' ('task_ref' | 'goal_ref' | 'softgoal_ref')
source=[Element|STRING]
'target' ':' ('task_ref' | 'goal_ref' | 'softgoal_ref') tar-
get=[Element|STRING]
'}';
enum CorrelationCategory returns CorrelationCategory:
make = 'make' | break = 'break' | help = 'help' | hurt = 'hurt' |
unknown = 'unknown';
Crosscutting returns Crosscutting:
'crosscutting' '{'
'source' ':' ('task_ref' | 'goal_ref' | 'softgoal_ref' |
'Goal_Model_ref') source=[Element|STRING]
pointcut+=Pointcut (pointcut+=Pointcut)*
(advice+=Advice (advice+=Advice)*)?
(intertype+=IntertypeDeclaration (inter-
type+=IntertypeDeclaration)*)?
'}';
Pointcut returns Pointcut:
'pointcut' name=ID ':' operand+=Operand (operand+=Operand2)*;
Operand returns Operand:
primitive=PrimitiveTypes joinpointPointcut=[Element|STRING] ;
Operand2 returns Operand:
operator=Operator primitive=PrimitiveTypes joinpointPoint-
cut=[Element|STRING];
Operator returns Operator:
operator=OperatorTypes;
enum PrimitiveTypes returns PrimitiveTypes:
include = 'include' | substitute = 'substitute';
enum OperatorTypes returns OperatorTypes:
and = 'and' | or = 'or' | not = 'not';
Advice returns Advice:
'advice' '(' type=AdviceCategory ')' ':' idPointcut+=[Pointcut|ID]
'{'
(('task_ref' | 'goal_ref' | 'softgoal_ref') joinpointAd-
vice+=[Element|STRING] '(' ('and' | 'or' | 'xor' | 'inc-or')? ')')+
'}';
enum AdviceCategory returns AdviceCategory:
around = 'around' | before = 'before' | after = 'after';
IntertypeDeclaration returns IntertypeDeclaration:
'intertype declaration' '(' type=IntertypeCategory ')' ':' idPoint-
cut+=[Pointcut|ID] '{'
(( newElement+=Element ) | (newAttribute+=Attribute ))+
'}';
enum IntertypeCategory returns IntertypeCategory:
74
element = 'element' | attribute = 'attribute';
Attribute returns Attribute:
type=STRING value=STRING;
EString returns ecore::EString:
ID | INT;
75
Apêndice II – Gramática Xtext do PL-AspectualACME
grammar dimap.ufrn.br.xtext.plaspectualacme.PLAspectualACME with
org.eclipse.xtext.common.Terminals
import "platform:/resource/MaRiPLAM2M/Metamodels/PLAspectualACME.ecore"
import "http://www.eclipse.org/emf/2002/Ecore" as ecore
Family returns Family:
{Family}
'family'name=EString ':' 'new''ProductLineT''extended''with' '=''{'
(systems+=System (systems+=System)*)?
'}'(';')?
;
AlternativeT returns AlternativeT:
{AlternativeT}
'component'name=EString ':''new''AlternativeT''extended''with''=''{'
(port+=Port (port+=Port)*)?
(property+=Property (property+=Property)*)?
(representation+=Representation (representa-
tion+=Representation)*)?
'}'(';')?;
Property returns Property:
Property_Impl | Variants | SelectedVariants;
Port returns Port:
Port_Impl | VariationPortT;
Element returns Element:
Component_Impl | Port_Impl | Role_Impl | Connector | System |
BaseRole | CrosscuttingRole | Representation | VariationPointT_Impl |
AlternativeT | OptionalT | InclusiveOrT | VariationPortT;
Component returns Component:
Component_Impl | VariationPointT_Impl | AlternativeT | OptionalT |
InclusiveOrT;
Role returns Role:
Role_Impl | BaseRole | CrosscuttingRole;
EString returns ecore::EString:
STRING | ID;
Property_Impl returns Property:
'property'key=EString'='
'{'
value=EString
'}'(';')?;
Representation returns Representation:
{Representation}
'representation'name=EString'=''{'
(system=System)?
(binding+=Binding (binding+=Binding)*)?
'}'(';')?;
76
Port_Impl returns Port:
{Port}
'port'name=EString'=''{'
(property+=Property (property+=Property)*)?
(representation+=Representation (representa-
tion+=Representation)*)?
'}'(';')?;
Variants returns Variants:
'property'key='variants''=''{'
value=EString
'}'(';')?;
SelectedVariants returns SelectedVariants:
'property'key='selectedVariants''=''{'
value=EString
'}'(';')?;
Binding returns Binding:
{Binding}
'binding'
'('
(externalE-
lem=[Element|EString])?'to'(internalElem=[Element|EString])?";"
')'(';')?;
System returns System:
{System}
'system'name=EString'=''{'
(component+=Component (component+=Component)*)?
(connector+=Connector (connector+=Connector)*)?
(attachment+=Attachment (attachment+=Attachment)*)?
(anExc+=AnalysisExcludes (anExc+=AnalysisExcludes)*)?
(anReq+=AnalysisRequires (anReq+=AnalysisRequires)*)?
(property+=Property (property+=Property)*)?
(representation+=Representation (representa-
tion+=Representation)*)?
'}'(';')?;
Component_Impl returns Component:
{Component}
'component'name=EString'=''{'
(port+=Port (port+=Port)*)?
(property+=Property (property+=Property)*)?
(representation+=Representation (representa-
tion+=Representation)*)?
'}'(';')?;
Role_Impl returns Role:
{Role}
'role'name=EString'=''{'
('refPort' '=' '{'(refPort+=[Element|EString] (ref-
Port+=[Element|EString])*)?'}'(';')?)?
(property+=Property (property+=Property)*)?
(representation+=Representation (representa-
tion+=Representation)*)?
'}'(';')?;
Connector returns Connector:
{Connector}
77
'connector'name=EString'=''{'
(property+=Property (property+=Property)*)?
(representation+=Representation ( representa-
tion+=Representation)*)?
(role+=Role (role+=Role)*)?
(glue+=Glue (glue+=Glue)*)?
'}'(';')?;
BaseRole returns BaseRole:
{BaseRole}
'base role'name=EString'=''{'
('refPort' '=' '{'(refPort+=[Element|EString] (ref-
Port+=[Element|EString])*)?'}'(';')?)?
(property+=Property (property+=Property)*)?
(representation+=Representation ( representa-
tion+=Representation)*)?
'}'(';')?;
CrosscuttingRole returns CrosscuttingRole:
{CrosscuttingRole}
'crosscutting role'name=EString'=''{'
('refPort' '=' '{'(refPort+=[Element|EString] (ref-
Port+=[Element|EString])*)?'}'(';')?)?
(property+=Property (property+=Property)*)?
(representation+=Representation (representa-
tion+=Representation)*)?
'}'(';')?;
VariationPointT_Impl returns VariationPointT:
{VariationPointT}
'component'name=EString':''new''VariationPointT''extended''with''=''{
'
(port+=Port (port+=Port)*)?
(property+=Property (property+=Property)*)?
(representation+=Representation (representa-
tion+=Representation)*)?
'}'(';')?;
OptionalT returns OptionalT:
{OptionalT}
'component'name=EString':''new''OptionalT''extended''with''=''{'
(port+=Port (port+=Port)*)?
(property+=Property (property+=Property)*)?
(representation+=Representation (representa-
tion+=Representation)*)?
'}'(';')?;
InclusiveOrT returns InclusiveOrT:
{InclusiveOrT}
'component'name=EString':''new''InclusiveOrT''extended''with''=''{'
(port+=Port (port+=Port)*)?
(property+=Property (property+=Property)*)?
(representation+=Representation (representa-
tion+=Representation)*)?
'}'(';')?;
VariationPortT returns VariationPortT:
{VariationPortT}
'variationPortT'name=EString'=''{'
(property+=Property (property+=Property)*)?
(representation+=Representation (representa-
78
tion+=Representation)*)?
'}'(';')?;
Glue returns Glue:
{Glue}
'glue''=''{'
('crosscutting element'':' crosscuttingAt-
tach=[CrosscuttingRole|EString])?
('glueType'':' glueType=GlueType)?
('base element'':' baseAttach=[BaseRole|EString])?
'}'(';')?;
enum GlueType returns GlueType:
before = 'before' | around = 'around' | after = 'after';
Attachment returns Attachment:
{Attachment}
'attachment''=''{'
(attachBaseElem=[Element|EString])?'to'
(attachToElem=[Element|EString])?
'}'(';')?;
AnalysisExcludes returns AnalysisExcludes:
{AnalysisExcludes}
'design invariant excludes''('
(source=[Element|EString])?","
(target=[Element|EString])?
')'(';')?;
AnalysisRequires returns AnalysisRequires:
{AnalysisRequires}
'design invariant requires''('
(source=[Element|EString])?","
(target=[Element|EString])?
')'(';')?;
79
Apêndice III – Script de Templates Acceleo para PL-AOVgraph
[comment encoding = UTF-8 /]
[module generatePLAOVgraph('http://plaovgraph/1.0')/]
[template public generate(aAspect_OrientedModel : Aspect_Oriented_Model)]
[comment @main /]
[file ('/PLAOVgraph.plaovgraph', false)]
aspect_oriented_model{
[for (g : Goal_Model | goalmodel)separator ('/n')]
goal_model "[g.name/]"{
[g.getElements()/][g.getCorrelations()/][g.getCrosscuttings()/]
}
[/for]
};
[/file]
[/template]
[template public getElements(eGoal_Model : Goal_Model)]
[for (e : Element | eGoal_Model.element)]
[e.type/]"[e.name/]"([returnContribution(e.relationship.eGet('label').toStr
ing())/]){
[e.getProperties()/][e.getElements()/]}
[/for]
[/template]
[query public returnContribution(str : Sequence(String)) : String =
self->collect(relation |
if relation = 'inc_or' then
'inc-or'
else
relation
endif
)
/]
[template public getProperties(eElement : Element)]
[if (eElement.property->notEmpty())]
property{
[for (p : Property | eElement.property)]
[if (p.oclIsTypeOf(IsFeature))]
isFeature=[p.eGet('label')/];
[/if]
[if (p.oclIsTypeOf(GroupFeature))]
groupFeature=([for (e : Element | p.eGet('source'))][e.type/]
"[e.name/]",[/for]);
cardinalityGroupMin=[p.eGet('cardinalityGroupMin')/];
cardinalityGroupMax=[p.eGet('cardinalityGroupMax')/];
[/if]
[if (p.oclIsTypeOf(Cardinality))]
cardinalityMin=[p.eGet('cardinalityMin')/];
cardinalityMax=[p.eGet('cardinalityMax')/];
[/if]
[/for]}[/if]
[/template]
[template public getCorrelations(eGoal_Model : Goal_Model)]
[for (c : Correlation | eGoal_Model.relationship->select(relation: Rela-
tionship | relation.oclIsTypeOf(Correlation)))]
correlation ([c.label/]){
80
source : [c.source.eGet('type')/]_ref "[c.source.name/]"
target : [c.target.eGet('type')/]_ref "[c.target.name/]"
}
[/for]
[/template]
[template public getCrosscuttings(eGoal_Model : Goal_Model)]
[for (c : Crosscutting | eGoal_Model.relationship->select(relation: Rela-
tionship | relation.oclIsTypeOf(Crosscutting)))]
crosscutting {
source: [c.source.eGet('type')/]_ref "[c.source.name/]"
[for (p : Pointcut | c.pointcut)]
pointcut [p.name/]:[for (op : Operand | p.operand)] [if
(op.operator->notEmpty())][op.operator.operator/] [/if][op.primitive/]
"[op.joinpointPointcut.name/]"[/for]
[/for]
[for (ad : Advice | c.advice)]
advice ([ad.type/]): [for (p : Pointcut | ad.idPointcut)]
[p.name/] [/for] {
[for (e : Element | ad.joinpointAdvice)]
[e.type/]_ref "[e.name/]" ([returnContribu-
tion(e.relationship.eGet('label').toString())/])
[/for]
}
[/for]
}
[/for]
[/template]
81
Apêndice IV – Script de Templates Acceleo para PL-AspectualACME
[comment encoding = Cp1252 /]
[module generatePLAspectualACME('http://plaspectualacme/1.0')]
[template public generate(aFamily : Family)]
[comment @main /]
[file ('/PLAspectualACME.plaspectualacme', false)]
[for (f : Family | self) separator ('/n')]
family [f.name/]:new ProductLineT extended with={
[f.getSystems()/]
};
[/for]
[/file]
[/template]
[template public getSystems(eFamily : Family)]
[for (s : System | systems)]
system [s.name/]={
[s.getComponent()/][s.getConnector()/][s.getAttachment()/][s.getPrope
rty()/][s.getRepresentation()/][s.getAnExc()/][s.getAnReq()/]
};
[/for]
[/template]
[template public getComponent(eSystem : System)]
[for (c : Component | component)]
[if (c.oclIsTypeOf(Component))]
component [c.name/]={
[c.getPort()/][c.getProperty()/][c.getRepresentation()/]
};
[elseif (c.oclIsTypeOf(VariationPointT))]
component [c.name/]: new VariationPointT extended with={
[c.getPort()/][c.getProperty()/][c.getRepresentation()/]
};
[elseif (c.oclIsTypeOf(AlternativeT))]
component [c.name/]: new AlternativeT extended with={
[c.getPort()/][c.getProperty()/][c.getRepresentation()/]
};
[elseif (c.oclIsTypeOf(OptionalT))]
component [c.name/]: new OptionalT extended with={
[c.getPort()/][c.getProperty()/][c.getRepresentation()/]
};
[elseif (c.oclIsTypeOf(InclusiveOrT))]
component [c.name/]: new InclusiveOrT extended with={
[c.getPort()/][c.getProperty()/][c.getRepresentation()/]
};
[/if]
[/for]
[/template]
[template public getConnector(eSystem : System)]
[for (con : Connector | connector)]
connector [con.name/]={
[con.getRole()/][con.getGlue()/][con.getProperty()/][con.getRepresent
ation()/]
};
[/for]
82
[/template]
[template public getAttachment(eSystem : System)]
[for (at : Attachment | attachment)]
attachment={[at.attachBaseElem.name/] to [at.attachToElem.name/]};
[/for]
[/template]
[template public getProperty(eElement : Element)]
[for (prop : Property | property)]
property [prop.key/]={"[prop.value/]"};
[/for]
[/template]
[template public getRepresentation(eElement : Element)]
[for (rep : Representation | representation)]
representation [rep.name/]={
[rep.getSys()/][rep.getBinding()/]
};
[/for]
[/template]
[template public getAnExc(eSystem : System)]
[for (anExc : AnalysisExcludes | anExc)]
design invariant excludes ([anExc.source.name/], [anExc.target.name/]);
[/for]
[/template]
[template public getAnReq(eSystem : System)]
[for (anReq : AnalysisRequires | anReq)]
design invariant requires ([anReq.source.name/], [anReq.target.name/]);
[/for]
[/template]
[template public getPort(eComponent : Component)]
[for (p : Port | port)]
[if (p.oclIsTypeOf(Port))]
port [p.name/]={[p.getProperty()/][p.getRepresentation()/]};
[elseif (p.oclIsTypeOf(VariationPortT))]
variationPortT [p.name/]={[p.getProperty()/][p.getRepresentation()/]};
[/if]
[/for]
[/template]
[template public getRole(eConnector : Connector)]
[for (r : Role | role)]
[if (r.oclIsTypeOf(Role))]
role [r.name/]={
refPort={[r.refPort.name/]};
[r.getProperty()/][r.getRepresentation()/]};
[elseif (r.oclIsTypeOf(BaseRole))]
base role [r.name/]={
refPort={[r.refPort.name/]};
[r.getProperty()/][r.getRepresentation()/]};
[elseif (r.oclIsTypeOf(CrosscuttingRole))]
crosscutting role [r.name/]={
refPort={[r.refPort.name/]};
[r.getProperty()/][r.getRepresentation()/]};
[/if]
[/for]
[/template]
83
[template public getGlue(eConnector : Connector)]
[for (g : Glue | glue)]
glue={crosscutting element:[g.crosscuttingAttach.name/] glu-
eType:[g.glueType/] base element:[g.baseAttach.name/]};
[/for]
[/template]
[template public getSys(eRepresentation : Representation)]
[for (s : System | system)]
system [s.name/]={
[s.getComponent()/][s.getConnector()/][s.getAttachment()/][s.getPrope
rty()/][s.getRepresentation()/][s.getAnExc()/][s.getAnReq()/]
};
[/for]
[/template]
[template public getBinding(eRepresentation : Representation)]
[for (b : Binding | binding)]
binding ([b.externalElem.eGet('name')/] to
[b.internalElem.eGet('name')/];);
[/for]
[/template]
84
Apêndice V – Regras ATL para Transformações de PL-AOVgraph em PL-
AspectualACME
-- @path PLAOVgraph=/MaRiPLAM2M/Metamodels/PLAOVgraph.ecore
-- @path PLAspectualACME=/MaRiPLAM2M/Metamodels/PLAspectualACME.ecore
module Req2Arq;
create plaspectualacme : PLAspectualACME from plaovgraph : PLAOVgraph;
uses Helpers;
--Regras de Transformação
--------------------------------------------------------------------------
-
-- 01 - Regra que transforma o elemento raiz de plaovgraph no elemento ra-
iz de plaspectualacme:
rule root {
from
elem : PLAOVgraph!Goal_Model(not
elem.refImmediateComposite().oclIsKindOf(PLAOVgraph!Goal_Model))
to
element : PLAspectualACME!Family (
name <- elem.name,
systems <- valsys
),
valsys:PLAspectualACME!System(
name <- elem.name,
component <- elem.element,
connector <- elem.relationship -> select(r |
r.oclIsTypeOf(PLAOVgraph!Crosscutting)) -> collect(c | thisMo-
dule.crosscutting(c)),
anExc <- elem.relationship-> select(r |
r.oclIsTypeOf(PLAOVgraph!Correlation))->select(c | c.label=#break)-
>collect(e | thisModule.analysisExcludes(e)),
anReq <- elem.relationship-> select(r |
r.oclIsTypeOf(PLAOVgraph!Correlation))->select(m | m.label=#make)-
>collect(r | thisModule.analysisRequires(r)),
attachment <- valsys.connector -> collect(c | c.role-
>collect(r | thisModule.attach(r)))
)
}
-- 02 - Elemento de primeiro nível na hierarquia de features, sem filhos e
relacionamento de contribuição 'and' é transformado em component de plas-
petualacme:
rule component{
from
elem :PLAOVgraph!Element ((elem.type=#task or elem.type=#goal
or elem.type=#softgoal) and
(elem.refImmediateComposite().oclType() = PLAOV-
graph!Goal_Model) and (elem.element.isEmpty())
and (elem.hasContribution()) and
elem.getContribution()='and')
to
component : PLAspectualACME!Component (
name <- elem.name,
85
property <- valProp,
port <- valPort,
property <- elem.property->select(e |
e.oclIsTypeOf(PLAOVgraph!IsFeature))->collect(i | thisMo-
dule.isFeat2prop(i)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisMo-
dule.card2prop(c)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisMo-
dule.group2prop(g)),
property <- elem.property-> select(p |
p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisMo-
dule.generic(gen))
),
valProp : PLAspectualACME!Property (
key <- 'elementType',
value <- elem.type.toString()
),
valPort : PLAspectualACME!Port (
name <- elem.name.concat('Port')
)
}
-- 03 - Elemento de primeiro nível na hierarquia de features, com filhos
e relacionamento de contribuição 'and' é transformado em VariationPointT
de plaspetualacme:
rule variationPoint{
from
elem : PLAOVgraph!Element ((elem.type=#task or elem.type=#goal
or elem.type=#softgoal) and
(elem.refImmediateComposite().oclType() = PLAOV-
graph!Goal_Model) and (elem.element.notEmpty())
and (elem.hasContribution()) and
elem.getContribution()='and')
to
var : PLAspectualACME!VariationPointT (
name <- elem.name,
property <- valProp,--gerando property elementType
property <- valProp2,--gerando property variantes
port <- valPort2, --gerando variation port
port <- valPort, --gerando porta
representation <- elem.element,
property <- elem.property->select(e |
e.oclIsTypeOf(PLAOVgraph!IsFeature))->collect(i | thisMo-
dule.isFeat2prop(i)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisMo-
dule.card2prop(c)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisMo-
dule.group2prop(g)),
property <- elem.property-> select(p |
p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisMo-
dule.generic(gen))
),
valProp : PLAspectualACME!Property (
key <- 'elementType',
value <- elem.type.toString()
),
86
valProp2 : PLAspectualACME!Variants (
key <- 'variants',
value <- elem.getVariants().toString().substring(6,
elem.getVariants().toString().size()-1)
),
valPort : PLAspectualACME!Port (
name <- elem.name.concat('Port')
),
valPort2 : PLAspectualACME!VariationPortT (
name <- elem.name.concat('VarPort')
)
}
-- 04 - Elemento de primeiro nível na hierarquia de features, com ou sem
filhos e relacionamento de contribuição 'or' é transformado em OptionalT
de plaspetualacme:
rule optionalT{
from
elem : PLAOVgraph!Element ((elem.type=#task or elem.type=#goal
or elem.type=#softgoal) and
(elem.refImmediateComposite().oclType() = PLAOV-
graph!Goal_Model)
and (elem.hasContribution()) and
elem.getContribution()='or')
to
var : PLAspectualACME!OptionalT (
name <- elem.name,
property <- valProp,--gerando property elementType
property <- valProp2,
port <- valPort2, --gerando variation port
port <- valPort, --gerando porta
representation <- elem.element,
property <- elem.property->select(e |
e.oclIsTypeOf(PLAOVgraph!IsFeature))->collect(i | thisMo-
dule.isFeat2prop(i)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisMo-
dule.card2prop(c)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisMo-
dule.group2prop(g)),
property <- elem.property-> select(p |
p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisMo-
dule.generic(gen))
),
valProp : PLAspectualACME!Property (
key <- 'elementType',
value <- elem.type.toString()
),
valProp2 : PLAspectualACME!Variants (
key <- 'variants',
value <- elem.getVariants().toString().substring(6,
elem.getVariants().toString().size()-1)
),
valPort : PLAspectualACME!Port (
name <- elem.name.concat('Port')
),
valPort2 : PLAspectualACME!VariationPortT (
name <- elem.name.concat('VarPort')
)
87
}
-- 05 - Elemento de primeiro nível na hierarquia de features, com ou sem
filhos e relacionamento de contribuição 'xor' é transformado em Alternati-
veT de plaspetualacme:
rule alternativeT{
from
elem : PLAOVgraph!Element ((elem.type=#task or elem.type=#goal
or elem.type=#softgoal) and
(elem.refImmediateComposite().oclType() = PLAOV-
graph!Goal_Model)
and (elem.hasContribution()) and
elem.getContribution()='xor')
to
var : PLAspectualACME!AlternativeT (
name <- elem.name,
property <- valProp,--gerando property elementType
property <- valProp2,
port <- valPort2, --gerando variation port
port <- valPort, --gerando porta
representation <- elem.element,
property <- elem.property->select(e |
e.oclIsTypeOf(PLAOVgraph!IsFeature))->collect(i | thisMo-
dule.isFeat2prop(i)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisMo-
dule.card2prop(c)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisMo-
dule.group2prop(g)),
property <- elem.property-> select(p |
p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisMo-
dule.generic(gen))
),
valProp : PLAspectualACME!Property (
key <- 'elementType',
value <- elem.type.toString()
),
valProp2 : PLAspectualACME!Variants (
key <- 'variants',
value <- elem.getVariants().toString().substring(6,
elem.getVariants().toString().size()-1)
),
valPort : PLAspectualACME!Port (
name <- elem.name.concat('Port')
),
valPort2 : PLAspectualACME!VariationPortT (
name <- elem.name.concat('VarPort')
)
}
-- 06 - Elemento de primeiro nível na hierarquia de features, com ou sem
filhos e relacionamento de contribuição 'inc-or' é transformado em Inclu-
siveOrT de plaspetualacme:
rule inclusiveOrT{
from
elem : PLAOVgraph!Element ((elem.type=#task or elem.type=#goal
or elem.type=#softgoal) and
(elem.refImmediateComposite().oclType() = PLAOV-
88
graph!Goal_Model)
and (elem.hasContribution()) and
elem.getContribution()='inc_or')
to
var : PLAspectualACME!InclusiveOrT (
name <- elem.name,
property <- valProp,--gerando property elementType
property <- valProp2,
port <- valPort2, --gerando variation port
port <- valPort, --gerando porta
representation <- elem.element,
property <- elem.property->select(e |
e.oclIsTypeOf(PLAOVgraph!IsFeature))->collect(i | thisMo-
dule.isFeat2prop(i)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisMo-
dule.card2prop(c)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisMo-
dule.group2prop(g)),
property <- elem.property-> select(p |
p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisMo-
dule.generic(gen))
),
valProp : PLAspectualACME!Property (
key <- 'elementType',
value <- elem.type.toString()
),
valProp2 : PLAspectualACME!Variants (
key <- 'variants',
value <- elem.getVariants().toString().substring(6,
elem.getVariants().toString().size()-1)
),
valPort : PLAspectualACME!Port (
name <- elem.name.concat('Port')
),
valPort2 : PLAspectualACME!VariationPortT (
name <- elem.name.concat('VarPort')
)
}
-- 07 - Elemento de segundo nível em diante, na hierarquia de features
(que têm um 'pai') e sem filhos, é transformado em Representation, que en-
capsula um system, que encapsula um component:
rule representationAnd{
from
elem : PLAOVgraph!Element ((elem.type=#task or elem.type=#goal
or elem.type=#softgoal) and
(elem.refImmediateComposite().oclType() = PLAOV-
graph!Element) and (elem.element.isEmpty())
and (elem.hasContribution()) and
elem.getContribution()='and')
to
rep : PLAspectualACME!Representation (
name <- elem.name,
system <- valSys,
binding <- valBindings
),
valSys : PLAspectualACME!System (
name <- rep.name,
89
component <- valComp
),
valBindings : PLAspectualACME!Binding (
externalElem <- rep.recVarPort(),
internalElem <- valPort
),
valComp : PLAspectualACME!Component (
name <- rep.name,
property <- valProp,
port <- valPort,
property <- elem.property->select(e |
e.oclIsTypeOf(PLAOVgraph!IsFeature))->collect(i | thisMo-
dule.isFeat2prop(i)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisMo-
dule.card2prop(c)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisMo-
dule.group2prop(g)),
property <- elem.property-> select(p |
p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisMo-
dule.generic(gen))
),
valProp : PLAspectualACME!Property (
key <- 'elementType',
value <- elem.type.toString()
),
valPort : PLAspectualACME!Port (
name <- elem.name.concat('Port')
)
}
-- 08 - Elemento de segundo nível em diante, na hierarquia de features
(que têm um 'pai'), é transformado em Representation, que encapsula um
system, que encapsula um variationPointT:
rule representationVar{
from
elem : PLAOVgraph!Element ((elem.type=#task or elem.type=#goal
or elem.type=#softgoal) and
(elem.refImmediateComposite().oclType() = PLAOV-
graph!Element) and not (elem.element.isEmpty())
and (elem.hasContribution()) and
elem.getContribution()='and')
to
rep : PLAspectualACME!Representation (
name <- elem.name,
system <- valSys,
binding <- valBindings
),
valSys : PLAspectualACME!System (
name <- rep.name,
component <- valVar
),
valBindings : PLAspectualACME!Binding (
externalElem <- rep.recVarPort(),
internalElem <- valPort
),
valVar : PLAspectualACME!VariationPointT (
name <- rep.name,
property <- valProp,
90
port <- valPort2,
port <- valPort,
property <- valProp2,
representation <- elem.element,
property <- elem.property->select(e |
e.oclIsTypeOf(PLAOVgraph!IsFeature))->collect(i | thisMo-
dule.isFeat2prop(i)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisMo-
dule.card2prop(c)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisMo-
dule.group2prop(g)),
property <- elem.property-> select(p |
p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisMo-
dule.generic(gen))
),
valProp : PLAspectualACME!Property (
key <- 'elementType',
value <- elem.type.toString()
),
valPort : PLAspectualACME!Port (
name <- elem.name.concat('Port')
),
valProp2 : PLAspectualACME!Variants (
key <- 'variants',
value <- elem.getVariants().toString().substring(6,
elem.getVariants().toString().size()-1)
),
valPort2 : PLAspectualACME!VariationPortT (
name <- elem.name.concat('VarPort')
)
}
-- 09 - Elemento de segundo nível em diante, na hierarquia de features
(que têm um 'pai'), é transformado em Representation, que encapsula um
system, que encapsula um optionalT:
rule representationOpt{
from
elem : PLAOVgraph!Element ((elem.type=#task or elem.type=#goal
or elem.type=#softgoal) and
(elem.refImmediateComposite().oclType() = PLAOV-
graph!Element)
and (elem.hasContribution()) and
elem.getContribution()='or')
to
rep : PLAspectualACME!Representation (
name <- elem.name,
system <- valSys,
binding <- valBindings
),
valSys : PLAspectualACME!System (
name <- rep.name,
component <- valOpt
),
valBindings : PLAspectualACME!Binding (
externalElem <- rep.recVarPort(),
internalElem <- valPort
),
valOpt : PLAspectualACME!OptionalT (
91
name <- rep.name,
property <- valProp,
port <- valPort2,
port <- valPort,
property <- valProp2,
representation <- elem.element,
property <- elem.property->select(e |
e.oclIsTypeOf(PLAOVgraph!IsFeature))->collect(i | thisMo-
dule.isFeat2prop(i)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisMo-
dule.card2prop(c)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisMo-
dule.group2prop(g)),
property <- elem.property-> select(p |
p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisMo-
dule.generic(gen))
),
valProp : PLAspectualACME!Property (
key <- 'elementType',
value <- elem.type.toString()
),
valPort : PLAspectualACME!Port (
name <- elem.name.concat('Port')
),
valProp2 : PLAspectualACME!Variants (
key <- 'variants',
value <- elem.getVariants().toString().substring(6,
elem.getVariants().toString().size()-1)
),
valPort2 : PLAspectualACME!VariationPortT (
name <- elem.name.concat('VarPort')
)
}
-- 10 - Elemento de segundo nível em diante, na hierarquia de features
(que têm um 'pai'), é transformado em Representation, que encapsula um
system, que encapsula um alternativeT:
rule representationAlt{
from
elem : PLAOVgraph!Element ((elem.type=#task or elem.type=#goal
or elem.type=#softgoal) and
(elem.refImmediateComposite().oclType() = PLAOV-
graph!Element)
and (elem.hasContribution()) and
elem.getContribution()='xor')
to
rep : PLAspectualACME!Representation (
name <- elem.name,
system <- valSys,
binding <- valBindings
),
valSys : PLAspectualACME!System (
name <- rep.name,
component <- valAlt
),
valBindings : PLAspectualACME!Binding (
externalElem <- rep.recVarPort(),
internalElem <- valPort
92
),
valAlt : PLAspectualACME!AlternativeT (
name <- rep.name,
property <- valProp,
port <- valPort2,
port <- valPort,
property <- valProp2,
representation <- elem.element,
property <- elem.property->select(e |
e.oclIsTypeOf(PLAOVgraph!IsFeature))->collect(i | thisMo-
dule.isFeat2prop(i)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisMo-
dule.card2prop(c)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisMo-
dule.group2prop(g)),
property <- elem.property-> select(p |
p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisMo-
dule.generic(gen))
),
valProp : PLAspectualACME!Property (
key <- 'elementType',
value <- elem.type.toString()
),
valPort : PLAspectualACME!Port (
name <- elem.name.concat('Port')
),
valProp2 : PLAspectualACME!Variants (
key <- 'variants',
value <- elem.getVariants().toString().substring(6,
elem.getVariants().toString().size()-1)
),
valPort2 : PLAspectualACME!VariationPortT (
name <- elem.name.concat('VarPort')
)
}
-- 11 - Elemento de segundo nível em diante, na hierarquia de features
(que têm um 'pai'), é transformado em Representation, que encapsula um
system, que encapsula um inclusiveOrT:
rule representationInc{
from
elem : PLAOVgraph!Element ((elem.type=#task or elem.type=#goal
or elem.type=#softgoal) and
(elem.refImmediateComposite().oclType() = PLAOV-
graph!Element)
and (elem.hasContribution()) and
elem.getContribution()='inc_or')
to
rep : PLAspectualACME!Representation (
name <- elem.name,
system <- valSys,
binding <- valBindings
),
valSys : PLAspectualACME!System (
name <- rep.name,
component <- valInc
),
valBindings : PLAspectualACME!Binding (
93
externalElem <- rep.recVarPort(),
internalElem <- valPort
),
valInc : PLAspectualACME!InclusiveOrT (
name <- rep.name,
property <- valProp,
port <- valPort2,
port <- valPort,
property <- valProp2,
representation <- elem.element,
property <- elem.property->select(e |
e.oclIsTypeOf(PLAOVgraph!IsFeature))->collect(i | thisMo-
dule.isFeat2prop(i)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisMo-
dule.card2prop(c)),
property <- elem.property->select(p |
p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisMo-
dule.group2prop(g)),
property <- elem.property-> select(p |
p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisMo-
dule.generic(gen))
),
valProp : PLAspectualACME!Property (
key <- 'elementType',
value <- elem.type.toString()
),
valPort : PLAspectualACME!Port (
name <- elem.name.concat('Port')
),
valProp2 : PLAspectualACME!Variants (
key <- 'variants',
value <- elem.getVariants().toString().substring(6,
elem.getVariants().toString().size()-1)
),
valPort2 : PLAspectualACME!VariationPortT (
name <- elem.name.concat('VarPort')
)
}
-- 12 - Correlation Break é transformado em Analysis Excludes:
lazy rule analysisExcludes {
from
corr : PLAOVgraph!Correlation (corr.label=#break)
to
exc : PLAspectualACME!AnalysisExcludes (
source <- corr.source,
target <- corr.target
)
}
-- 13 - Correlation Make é transformado em Analysis Requires:
lazy rule analysisRequires {
from
corr : PLAOVgraph!Correlation (corr.label=#make)
to
req : PLAspectualACME!AnalysisRequires (
source <- corr.source,
target <- corr.target
)
}
94
--14 - Correlation Help|Unknown|Hurt é transformado em Property de PL-
AspectualACME
rule corr2prop {
from
corr : PLAOVgraph!Correlation(not (corr.label=#make or
corr.label=#break))
to
prop : PLAspectualACME!Property (
key <- 'correlation '+corr.label,
value <- 'source- '+corr.source.name+', target-
'+corr.target.name,
type <- corr.target
)
}
--14 -IsFeature é transformado em Property de PL-AspectualACME
lazy rule isFeat2prop {
from
isfeat : PLAOVgraph!IsFeature
to
prop : PLAspectualACME!Property (
key <- 'is feature',
value <- isfeat.label.toString()
)
}
--15 - Cardinality é transformado em Property de PL-AspectualACME
lazy rule card2prop {
from
card : PLAOVgraph!Cardinality
to
prop : PLAspectualACME!Property (
key <- 'cardinality',
value <- 'MAX- '+card.cardinalityMin+' '+'MIN-
'+card.cardinalityMax
)
}
--16 - GroupFeature é transformado em Property de PL-AspectualACME
lazy rule group2prop {
from
group : PLAOVgraph!GroupFeature
to
prop : PLAspectualACME!Property (
key <- 'group feature',
value <- 'Group Min- '+group.cardinalityGroupMin+' Group
Max- '+group.cardinalityGroupMax,
type <- group.source
)
}
--17 - Generic Property é transformado em Property de PL-AspectualACME
lazy rule generic {
from
gen : PLAOVgraph!Generic_Property
to
prop : PLAspectualACME!Property (
key <- gen.name,
value <- gen.value
95
)
}
--18 - Crosscutting é transformado em attachment com aspectualconnector:
lazy rule crosscutting {
from
cross : PLAOVgraph!Crosscutting
to
conn : PLAspectualACME!Connector (
name <- cross.source.name.substring(1, 5)+'Conn',
role <- brole,
role <- crole,
glue <- gluetype,
property <- cross.intertype->select(i | thisMo-
dule.intertypeToProp(i)),
property <- cross.intertype->select(i | i.newElement)-
>collect(e | thisModule.newElemToProp(e)),
property <- cross.intertype->select(i | i.newAttribute)-
>collect(a | thisModule.attToProp(a))
),
operand:PLAspectualACME!Property(
key <- 'operand',
value <- cross.pointcut -> collect(p | p.operand -> col-
lect(op | op.primitive.toString())),
type <- cross.pointcut->collect(p | p.operand->collect(op
| op.joinpointPointcut))
),
operator:PLAspectualACME!Property (
key <- 'operator',
value <- cross.pointcut -> collect(p | p.operand -> col-
lect(o | o.operator.operator.toString()))
),
gluetype:PLAspectualACME!Glue(
crosscuttingAttach <- crole,
baseAttach <- brole,
glueType <- cross.advice -> collect(a | a.type)
),
brole:PLAspectualACME!BaseRole(
name <- cross.pointcut -> collect(p | p.operand -> col-
lect(op | op.joinpointPointcut.name)),
property <- operand,
property <- operator,
refPort <- cross.pointcut->collect(p | p.operand-
>collect(op | op.joinpointPointcut))
),
crole:PLAspectualACME!CrosscuttingRole(
name <- cross.advice->collect(ad | ad.joinpointAdvice ->
collect(j | j.name)),
refPort <- cross.advice->collect(ad | ad.joinpointAdvice)
)
}
--19 – Intertype Declaration é transformado em Property:
lazy rule intertypeToProp {
from
inter : PLAOVgraph!IntertypeDeclaration
to
prop : PLAspectualACME!Property (
key <- 'Intertype Declaration',
value <- inter.type.toString()
)
}
96
--20 - NewElement é transformado em Property:
lazy rule newElemToProp {
from
elem : PLAOVgraph!IntertypeDeclaration
to
prop : PLAspectualACME!Property (
key <- 'New Element',
value <- elem.newElement->collect(e | e.name),
type <- elem.newElement
)
}
--21 - NewAttribute é transformado em Property:
lazy rule attToProp {
from
att : PLAOVgraph!Attribute
to
prop: PLAspectualACME!Property (
key <- att.type,
value <- att.value
)
}
--22 – Called Rule para geração dos attachments:
rule attach(r:PLAspectualACME!Role) {
to
at : PLAspectualACME!Attachment (
attachBaseElem <- r,
attachToElem <- r.refPort
)
do {
at;
}
}
97
Apêndice VI – Regras ATL para Transformações de PL-AspectualACME
em PL-AOVgraph
-- @path PLAOVgraph=/MaRiPLAM2M/Metamodels/PLAOVgraph.ecore
-- @path PLAspectualACME=/MaRiPLAM2M/Metamodels/PLAspectualACME.ecore
module Arq2Req;
create plaovgraph : PLAOVgraph from plaspectualacme : PLAspectualACME;
uses Helpers;
-- 01 -- Regra que transforma Family em GoalModel
rule root {
from
fam : PLAspectualACME!Family
to
goal : PLAOVgraph!Aspect_Oriented_Model (
goalmodel <- fam.systems->collect(s | thisMo-
dule.sys2goal(s))
)
}
-- 02 -- Regra que transforma System filho da Family em Goal Model
lazy rule sys2goal {
from
sys : PLAspectua-
lACME!System(sys.refImmediateComposite().oclIsTypeOf(PLAspectualACME!Family
))
to
goal : PLAOVgraph!Goal_Model (
name <- sys.name,
element <- sys.component,
relationship <- sys.anExc.asOrderedSet()-> collect(a |
thisModule.anExc2corr(a)),
relationship <- sys.anReq.asOrderedSet()-> collect(a |
thisModule.anReq2corr(a)),
relationship <- sys.component -> collect(e |
e.property.asOrderedSet()->select(p | p.key.startsWith('correlation'))-
>collect(c | thisModule.prop2correlation(c))),
property <- sys.property.asOrderedSet()->select(p |
p.key='is feature')->collect(c | thisModule.prop2isfeat(c)),
property <- sys.property.asOrderedSet()->select(p |
p.key='cardinality')->collect(c | thisModule.prop2card(c)),
property <- sys.property.asOrderedSet()->select(p |
p.key='group feature')->collect(c | thisModule.prop2group(c)),
property <- sys.property.asOrderedSet()->select(p | not
(p.key='group feature'or p.key='cardinality' or p.key='is feature' or
p.key.startsWith('correlation') or p.key='elementType' or
p.key='variants'))->collect(c | thisModule.property(c)),
relationship <- sys.connector.asOrderedSet()->collect(con
| thisModule.conn2Cross(con))
)
}
-- 03 -- Component pra Task primeiro nivel 'and' com ou sem filhos
rule comp2task {
from
comp : PLAspectua-
lACME!Component(comp.refImmediateComposite().refImmediateComposite().oclIsT
98
ypeOf(PLAspectualACME!Family) and not comp.hasElementType())
to
elem : PLAOVgraph!Element (
name <- comp.name,
type <- 'task',
relationship <- valContribution,
element <- comp.representation,
property <- comp.property.asOrderedSet()->select(p |
p.key='is feature')->collect(c | thisModule.prop2isfeat(c)),
property <- comp.property.asOrderedSet()->select(p |
p.key='cardinality')->collect(c | thisModule.prop2card(c)),
property <- comp.property.asOrderedSet()->select(p |
p.key='group feature')->collect(c | thisModule.prop2group(c)),
property <- comp.property.asOrderedSet()->select(p | not
(p.key='group feature'or p.key='cardinality' or p.key='is feature' or
p.key.startsWith('correlation') or p.key='elementType' or
p.key='variants'))->collect(c | thisModule.property(c))
),
valContribution : PLAOVgraph!Contribution (
source <- elem.refImmediateComposite(),
target <- elem,
label <- if comp.oclIsTypeOf(PLAspectualACME!OptionalT)
then 'or'
else
if
comp.oclIsTypeOf(PLAspectualACME!AlternativeT) then 'xor'
else
if
comp.oclIsTypeOf(PLAspectualACME!InclusiveOrT) then 'inc-or' else 'and' en-
dif
endif
endif
)
}
-- 04 -- Component pra Element primeiro nivel 'and' com ou sem filhos
rule comp2element {
from
comp : PLAspectua-
lACME!Component(comp.refImmediateComposite().refImmediateComposite().oclIsT
ypeOf(PLAspectualACME!Family) and comp.hasElementType())
to
elem : PLAOVgraph!Element (
name <- comp.name,
type <- comp.getElementType(),
relationship <- valContribution,
element <- comp.representation,
property <- comp.property.asOrderedSet()->select(p |
p.key='is feature')->collect(c | thisModule.prop2isfeat(c)),
property <- comp.property.asOrderedSet()->select(p |
p.key='cardinality')->collect(c | thisModule.prop2card(c)),
property <- comp.property.asOrderedSet()->select(p |
p.key='group feature')->collect(c | thisModule.prop2group(c)),
property <- comp.property.asOrderedSet()->select(p | not
(p.key='group feature'or p.key='cardinality' or p.key='is feature' or
p.key.startsWith('correlation') or p.key='elementType' or
p.key='variants'))->collect(c | thisModule.property(c))
),
valContribution : PLAOVgraph!Contribution (
source <- elem.refImmediateComposite(),
target <- elem,
99
label <- if comp.oclIsTypeOf(PLAspectualACME!OptionalT)
then 'or'
else
if
comp.oclIsTypeOf(PLAspectualACME!AlternativeT) then 'xor'
else
if
comp.oclIsTypeOf(PLAspectualACME!InclusiveOrT) then 'inc-or' else 'and' en-
dif
endif
endif
)
}
-- 05 - Representation para element
rule rep2task {
from
rep : PLAspectualACME!Representation
to
elem : PLAOVgraph!Element (
name <- rep.name,
element <- rep.system.component -> collect(a |
a.representation),
type <- if rep.system.component->collect(c |
c.hasElementType()) then rep.system.component->collect(c |
c.getElementType()) else 'task' endif,
relationship <- valContribution,
property <- rep.system.component -> collect(comp |
comp.property.asOrderedSet()->select(p | p.key='is feature')->collect(c |
thisModule.prop2isfeat(c))),
property <- rep.system.component -> col-
lect(comp|comp.property.asOrderedSet()->select(p | p.key='cardinality')-
>collect(c | thisModule.prop2card(c))),
property <- rep.system.component -> col-
lect(comp|comp.property.asOrderedSet()->select(p | p.key='group feature')-
>collect(c | thisModule.prop2group(c))),
property <- rep.system.component ->
collect(comp|comp.property.asOrderedSet()->select(p | not (p.key='group
feature'or p.key='cardinality' or p.key='is feature' or
p.key.startsWith('correlation') or p.key='elementType' or
p.key='variants'))->collect(c | thisModule.property(c)))
),
valContribution : PLAOVgraph!Contribution (
source <- elem.refImmediateComposite(),
target <- elem,
label <- if
(rep.system.component.first().oclIsTypeOf(PLAspectualACME!OptionalT)) then
'or'
else
if
(rep.system.component.first().oclIsTypeOf(PLAspectualACME!AlternativeT))
then 'xor'
else
if
(rep.system.component.first().oclIsTypeOf(PLAspectualACME!InclusiveOrT))
then 'inc-or'
else 'and'
endif
endif
endif
)
100
}
-- 06 - Analysis Excludes pra correlation break
lazy rule anExc2corr {
from
anExc : PLAspectualACME!AnalysisExcludes
to
corr : PLAOVgraph!Correlation (
label <- 'break',
source <- if
anExc.source.oclIsTypeOf(PLAspectualACME!Representation) then anExc.source
else anExc.source.refImmediateComposite().refImmediateComposite() endif,
target <- if
anExc.target.oclIsTypeOf(PLAspectualACME!Representation) then anExc.target
else anExc.target.refImmediateComposite().refImmediateComposite() endif
)
}
-- 07 - Analysis Requires pra correlation make
lazy rule anReq2corr {
from
anReq : PLAspectualACME!AnalysisRequires
to
corr : PLAOVgraph!Correlation (
label <- 'make',
source <- if an-
Req.source.oclIsTypeOf(PLAspectualACME!Representation) then anReq.source
else anReq.source.refImmediateComposite().refImmediateComposite() endif,
target <- if an-
Req.target.oclIsTypeOf(PLAspectualACME!Representation) then anReq.target
else anReq.target.refImmediateComposite().refImmediateComposite() endif
)
}
-- 08 - Regra que transforma property correlation de PLAspectualACME em Re-
lationship Correlation de PLAOVgraph
lazy rule prop2correlation {
from
prop : PLAspectua-
lACME!Property(prop.key.startsWith('correlation'))
to
corr : PLAOVgraph!Correlation (
label <- prop.key.substring(13, prop.key.size()),
source <- prop.refImmediateComposite(),
target <- prop.type
)
}
-- 09 -- Regra que transforma property isfeature de PLAspectualACME em pro-
perty isfeature de PLAOVgraph
lazy rule prop2isfeat {
from
prop : PLAspectualACME!Property (prop.key='is feature')
to
isfeat : PLAOVgraph!IsFeature (
label <- prop.value
)
}
-- 10 -- Regra que transforma property cardinality de PLAspectualACME em
property cardinality de PLAOVgraph
lazy rule prop2card {
101
from
prop : PLAspectualACME!Property (prop.key='cardinality')
to
card : PLAOVgraph!Cardinality (
cardinalityMin <- prop.value.substring(5, 6),
cardinalityMax <- prop.value.substring(11,
prop.value.size())
)
}
-- 11 -- Regra que transforma property groupfeature de PLAspectualACME em
property groupfeature de PLAOVgraph
lazy rule prop2group {
from
prop : PLAspectualACME!Property (prop.key='group feature')
to
group : PLAOVgraph!GroupFeature (
cardinalityGroupMin <- prop.value.substring(12, 13),
cardinalityGroupMax <- prop.value.substring(25,
prop.value.size()),
source <- prop.type
)
}
-- 12 -- Regra que transforma property de PLAspectualACME em generic prop-
erty de PLAOVgraph
lazy rule property {
from
prop : PLAspectualACME!Property (not (prop.key='group feature'
or prop.key='cardinality' or prop.key='is feature' or
prop.key.startsWith('correlation')
or
prop.key='operand' or prop.key='operator' or prop.key='elementType' or
prop.key='variants'))
to
gen : PLAOVgraph!Generic_Property (
name <- prop.key,
value <- prop.value
)
}
-- 13 -- Regra que transforma aspectual connector de PLAspectualACME em
crosscutting relationship de PLAOVgraph
lazy rule conn2Cross {
from
conn : PLAspectualACME!Connector
to
cross : PLAOVgraph!Crosscutting (
advice <- advice,
intertype <- conn.property.asOrderedSet()->select(p |
p.key='Intertype Declaration')->asOrderedSet(),
pointcut <- pointcut,
source <- conn.role->select(r |
r.oclIsTypeOf(PLAspectualACME!CrosscuttingRole))->collect(cr | cr.refPort)
),
advice : PLAOVgraph!Advice (
idPointcut <- pointcut,
joinpointAdvice <- conn.role->select(r |
r.oclIsTypeOf(PLAspectualACME!CrosscuttingRole))->collect(cr | cr.refPort),
type <- conn.glue -> collect(g | g.glueType)
102
),
pointcut : PLAOVgraph!Pointcut(
name <- conn.name.concat('Pc'),
operand <- operand
),
operand : PLAOVgraph!Operand(
joinpointPointcut <- conn.role -> select(r |
r.oclIsTypeOf(PLAspectualACME!BaseRole))->collect(br | br.refPort),
operator <- operator,
primitive <- conn.role -> select(r |
r.oclIsTypeOf(PLAspectualACME!BaseRole))->collect(br |
br.property.asOrderedSet()->select(p | p.key='operand')->collect(op |
op.value))
),
operator : PLAOVgraph!Operator(
operator <- conn.role -> select(r |
r.oclIsTypeOf(PLAspectualACME!BaseRole))->collect(br |
br.property.asOrderedSet()->select(p | p.key='operator')->collect(op |
op.value))
)
}
103
Apêndice VII – Descrição PL-AspectualACME gerada a partir de PL-
AOVgraph
family ginga:new ProductLineT extended with={
system ginga={
component Tuner: new VariationPointT extended with={
variationPortT TunerVarPort={};
port TunerPort={};
property elementType={"task"};
property variants={"'IP', 'Filesystem', 'Terrestrial',
'Satelite'"};
representation Terrestrial={
system Terrestrial={
component Terrestrial: new OptionalT extended with={
variationPortT TerrestrialVarPort={};
port TerrestrialPort={};
property elementType={"task"};
property variants={""};
};
};
binding (TunerVarPort to TerrestrialPort;);
};
representation Filesystem={
system Filesystem={
component Filesystem: new OptionalT extended with={
variationPortT FilesystemVarPort={};
port FilesystemPort={};
property elementType={"task"};
property variants={""};
};
};
binding (TunerVarPort to FilesystemPort;);
};
representation Satelite={
system Satelite={
component Satelite: new OptionalT extended with={
variationPortT SateliteVarPort={};
port SatelitePort={};
property elementType={"task"};
property variants={""};
};
};
binding (TunerVarPort to SatelitePort;);
};
representation IP={
system IP={
component IP: new OptionalT extended with={
variationPortT IPVarPort={};
port IPPort={};
property elementType={"task"};
property variants={"'InternetTV', 'IPTV', 'P2PTV'"};
representation IPTV={
system IPTV={
component IPTV: new OptionalT extended with={
variationPortT IPTVVarPort={};
port IPTVPort={};
property elementType={"task"};
104
property variants={""};
};
};
binding (IPVarPort to IPTVPort;);
};
representation InternetTV={
system InternetTV={
component InternetTV: new OptionalT extended
with={
variationPortT InternetTVVarPort={};
port InternetTVPort={};
property elementType={"task"};
property variants={""};
};
};
binding (IPVarPort to InternetTVPort;);
};
representation P2PTV={
system P2PTV={
component P2PTV: new OptionalT extended
with={
variationPortT P2PTVVarPort={};
port P2PTVPort={};
property elementType={"task"};
property variants={""};
};
};
binding (IPVarPort to P2PTVPort;);
};
};
};
binding (TunerVarPort to IPPort;);
};
};
component Platform: new VariationPointT extended with={
variationPortT PlatformVarPort={};
port PlatformPort={};
property elementType={"task"};
property variants={"'ST', 'Broadcom', 'Mobile', 'PC'"};
representation Broadcom={
system Broadcom={
component Broadcom: new AlternativeT extended with={
variationPortT BroadcomVarPort={};
port BroadcomPort={};
property elementType={"task"};
property variants={""};
};
};
binding (PlatformVarPort to BroadcomPort;);
};
representation ST={
system ST={
component ST: new AlternativeT extended with={
variationPortT STVarPort={};
port STPort={};
property elementType={"task"};
property variants={""};
};
};
binding (PlatformVarPort to STPort;);
105
};
representation PC={
system PC={
component PC: new AlternativeT extended with={
variationPortT PCVarPort={};
port PCPort={};
property elementType={"task"};
property variants={""};
};
};
binding (PlatformVarPort to PCPort;);
};
representation Mobile={
system Mobile={
component Mobile: new AlternativeT extended with={
variationPortT MobileVarPort={};
port MobilePort={};
property elementType={"task"};
property variants={""};
};
};
binding (PlatformVarPort to MobilePort;);
};
};
component ConditionalAcess={
port ConditionalAcessPort={};
property elementType={"task"};
};
component Demultiplexer: new VariationPointT extended with={
variationPortT DemultiplexerVarPort={};
port DemultiplexerPort={};
property elementType={"task"};
property variants={"'Software', 'Hardware'"};
representation Hardware={
system Hardware={
component Hardware: new AlternativeT extended with={
variationPortT HardwareVarPort={};
port HardwarePort={};
property elementType={"task"};
property variants={""};
};
};
binding (DemultiplexerVarPort to HardwarePort;);
};
representation Software={
system Software={
component Software: new AlternativeT extended with={
variationPortT SoftwareVarPort={};
port SoftwarePort={};
property elementType={"task"};
property variants={""};
};
};
binding (DemultiplexerVarPort to SoftwarePort;);
};
};
connector CondiConn={
base role Tuner={
refPort={Tuner};
property operand={"include"};
};
106
crosscutting role ConditionalAcess={
refPort={ConditionalAcess};
};
glue={crosscutting element:ConditionalAcess glueType:around base
element:Tuner};
};
attachment={Tuner to Tuner};
attachment={ConditionalAcess to ConditionalAcess};
design invariant excludes (Hardware, PC);
design invariant excludes (Hardware, Mobile);
};
};
107
Apêndice VIII – Descrição PL-AOVgraph gerada a partir de PL-
AspectualACME
aspect_oriented_model{
goal_model "ginga"{
task"Tuner"(and){
task"Terrestrial"(or){
}
task"Filesystem"(or){
}
task"Satelite"(or){
}
task"IP"(or){
task"IPTV"(or){
}
task"InternetTV"(or){
}
task"P2PTV"(or){
}
}
}
task"Platform"(and){
task"Broadcom"(xor){
}
task"ST"(xor){
}
task"PC"(xor){
}
task"Mobile"(xor){
}
}
task"ConditionalAcess"(and){
}
task"Demultiplexer"(and){
task"Hardware"(xor){
}
task"Software"(xor){
}
}
correlation (break){
source : task_ref "Hardware"
target : task_ref "PC"
}
correlation (break){
source : task_ref "Hardware"
target : task_ref "Mobile"
}
crosscutting {
source: task_ref "ConditionalAcess"
pointcut GingaConnPc: include "Tuner"
advice (around): GingaConnPc {
task_ref "ConditionalAcess" (and)
}
}
}
};