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
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
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.
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.
“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.”
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, derivabilivariabili-dade, reusabilivariabili-dade, corretude, rastreabilivariabili-dade, completude, evoluti-bilidade e manutenievoluti-bilidade, extraídos do Modelo de Qualidade CAFÉ.
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, derivabilivariabili-ty, reusabilivariabili-ty, correctness, traceabilivariabili-ty, completeness, evolvability and maintainability, extracted from the CAFÉ Quality Model.
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
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 AOVgraph em PL-AspectualACME... 84
Apêndice VI – Regras ATL para Transformações de AspectualACME em PL-AOVgraph ... 97
Apêndice VII – Descrição PL-AspectualACME gerada a partir de PL-AOVgraph ... 103
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 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
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
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.
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 desenvolvidesenvolvi-mento 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.
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 descritransforma-çõ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, corretureusabilida-de, rastreabilidareusabilida-de, completureusabilida-de, 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.
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 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 momo-delo a texto (M2T) no Acceleo
1.3 Estrutura do trabalho
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 featufeatu-res).
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.
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 eleele-mentos (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).
repre-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.
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.
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).
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.
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).
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
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 metameta-modelos 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).
metamode-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
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 momo-delo de destino. Esses mode-los são definidos através de metamodemode-los, 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 prino-meira 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).
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
lin-guagem criada, após a geração da infraestrutura da linlin-guagem, 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
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 GingaForAll
O Ginga ForAll (Saraiva et al, 2010) é uma iniciativa de pesquisadores da Universida-de FeUniversida-deral do Rio GranUniversida-de do Norte (UFRN), que refatora o middleware Universida-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.
A equipe realizou uma análise inicial de domínio do núcleo principal do Ginga, o Gin-ga Common Core (GinGin-gaCC) 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.
Tabela 1: Lista de dependências entre features do GingaForAll
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) }
} } };
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 GingaForAll
O mesmo trecho do Ginga ForAll descrito em 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={}; };
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={}; };
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); };
};
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.
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
PL-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 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 (Transformadescri-çã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-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
Tabela 2: Regras de mapeamento entre PL-AOVgraph e PL-AspectualACME
PL-AOVgraph PL-AspectualACME
1 Aspect_Oriented_Model Family
2 GoalModel System
3
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, 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;
4. Correlation Make, de 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.
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 eleme n-to VariationPointT da arquitetura, pois corresponde a um ponn-to 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, é tran s-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
port <- valPort2, --gerando variation port
port <- valPort --gerando port
...
}
Figura 18: Trecho de regra de transformação ATL
Além de transformar o elemento AOVgraph em um ALternativeT de PL-AspectualACME, a regra gera a propriedade ElementType, que determina a partir de qual elemento de 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).
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.
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)
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.1Modelos do Estudo de Caso
(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
