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 examinadora 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 software – 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, fisicamente, é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 preciosos 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 financeiro 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 estratégia que busca evitar a perda de informações, reduzindo o gap entre essas duas atividades 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 processo de mapeamento bi-direcional, definindo regras de transformação entre elementos de modelo de requisitos orientado a objetivos (descrito em PL-AOVgraph) e elementos 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 automatizar essa transformação, implementamos a ferramenta MaRiPLA (Mapping Requirements 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 especificaçã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 variabilidade, derivabilidade, reusabilidade, corretude, rastreabilidade, completude, evolutibilidade 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 allows the correspondence between this two activities, with management of variability. In order to address this issue, this paper presents a process of bi- directional mapping, defining transformation rules between elements of a goaloriented requirements model (described in PL-AOVgraph) and elements of an architectural description (defined in PL-AspectualACME). These mapping rules are evaluated using a case study: the GingaForAll LPS. To automate this transformation, we developed the uct Line Architecture), MaRiPLA tool (Mapping Requirements to through MDD techniques driven Development), including Atlas Transformation with specification of Ecore metamodels – Language jointly with Xtext , a Prod(Model- (ATL) – DSL definition framework, and Acceleo, a code generation tool, in Eclipse environment. Finally, the generated models are evaluated based on quality attributes such as variability, 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 2. 1.1 Motivação ................................................................................................... 16 1.2 Objetivos ..................................................................................................... 17 1.3 Estrutura do trabalho ................................................................................... 18 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. 4. Processo de Mapeamento entre Modelo de Metas e Descrição Arquitetural ............ 39 3.1 Processo de Mapeamento ............................................................................ 39 3.2 Regras de Mapeamento ............................................................................... 40 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 7. 6.4 MaRiSA-MDD (Medeiros, 2008) ................................................................ 65 6.5 ReqSys (Santos, 2010) e ReqSys-MDD ....................................................... 65 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 PLAspectualACME........................................................................................................... 84 Apêndice VI – Regras ATL para Transformações de PL-AspectualACME em PLAOVgraph .................................................................................................................... 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 PLAspectualACME ...................................................................................................... 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 (softmetas, metas e tarefas) organizados em árvores and/or, com possíveis relacionamentos entre esses 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 modelagem 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 modelagem 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, Santos (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 transversais, 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 software (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, reduzindo 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 desenvolvimento 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 PLAspectualACME. Essa extensão não acrescentou novos elementos, apenas enriqueceu semanticamente 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 elementos 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 (algumas 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 AOVGraph 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 definição de requisitos e arquitetura de LPS, epropor MaRiPLA (Mapping Requirements to Product 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 (ACCELEO, 2011). MaRiPLA, assim como MaRiSA, é implementada no ambiente Eclipse (ECLIPSE, 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, reusabilidade, 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 metas 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ência 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 especificações de um ou outro. O mapeamento evita, também, a perda de informações importantes das atividades iniciais, no momento da definição da arquitetura, beneficiando, também, as atividades subsequentes 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 PLAOVgraph, 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 MaRiPLA (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 AspectualACME, respectivamente; Especificação das transformações em ATL nas duas vias (goals2arch e arch2goals), em conformidade com os metamodelos previamente criados e estendendo 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 modelo (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, Acceleo 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 mapeamento 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 ferramenta 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 resultados 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, contribuições e idéias para trabalhos futuros. Há, ainda, os Apêndices, com modelos e descrições usados 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 trabalho. 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 variabilidades); na seção 2.3, apresentamos a ADL ACME e suas extensões AspectualACME e PLAspectualACME (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 informaçõ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), opcionais (optional features) ou alternativas – que podem ser do tipo inc-or (inclusive-or features) 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 apontar 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, elementos (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 relacionamento 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 interferem 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 negativa) e hurt (um requisito afeta o outro). AOV-Graph (Silva, 2006) é uma extensão desse modelo de metas, que adiciona o relacionamento 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 cardinalityMin, 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 elementos adicionais supracitados. Figura 2: Metamodelo de PL-AOVgraph O metamodelo de PL-AOVgraph estende o metamodelo de AOV-Graph, incluindonovas 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 PLAOVgraph de Santos (2010). A Figura 3 ilustra um modelo de metas genérico, com a representação gráfica em PLAOVgraph 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 relacionamentos 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 componentes, 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 (interfaces 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 (descrevem 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 (nome, 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) Crosscutting 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 componente regular será afetado por um componente aspectual, por exemplo. 23 Os mecanismos de quantificação simplificam sintaticamente as referências aos diversos pontos de junção na descrição arquitetural. São inseridos no campo de configuração (attachments), 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 regulares, 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 ligadas 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 AspectualACME, 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, atravé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 ProductLineT para LPS; b. VariationPointT – extensão do elemento Component de ACME, encapsula pontos de variação opcionais (OptionalT), alternativos (AlternativeT) e inclusive-or (InclusiveOrT); c. Representation – extensão do elemento representation de ACME, encapsula as variantes; d. Property variants – extensão do elemento property de ACME, lista as variabilidades de um ponto de variação; e. VariationPortT – porta que abstrai o mecanismo de seleção de variantes em um VariationPointT; f. Property SelectedVariants – indica as variantes escolhidas para uma VariationPortT, 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 arquiteturas 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 componentes 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, AlternativeT 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 aspectual. 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 AspectualACME, incluindo alterações propostas com base na definição mais recente de PLAspectualACME (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 ProductLineT 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 é representado, na descrição PL-AspectualACME, na propriedade variants, e sua representação interna é modelada através do elemento Representation, que encapsula o System C2 e suas variantes inclusive-or: C3, C4 e C5 (cada uma modelada através de suas representations e systems). As variantes C2, C3, C4 e C5 são selecionadas através da porta VariationPortT do ponto 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 primeira 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 arquitetura 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 introduzido 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 transformaçã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 é definida pelo modelo Mt (que está de acordo com o seu metamodelo MMt). Todos esses metamodelos devem estar de acordo com um metametamodelo (como MOF ou Ecore). Para realizar uma transformação entre modelos, portanto, é necessário criar os metamodelos 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 ferramentas 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 Transformation 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 relacionamentos 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 manipulado, 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 linguagem 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 ferramentas, 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 textual concreta, e pode ser declarativa ou imperativa. O estilo declarativo expressa, basicamente, mapeamentos entre elementos de um modelo de origem e elementos de um modelo de destino. 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 modelo de origem será transformado no respectivo elemento do modelo de destino. Esses modelos 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 transformação. O corpo da transformação conta com um cabeçalho, em que temos inicialmente o nome 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 objetos) 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 linguagens, 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 linguagens 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 metamodelo 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 linguagem já pode ser testado. A Figura 10 mostra um trecho do editor de gramática, juntamente com o editor da linguagem 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 elemento 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 gramá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 (OMGMOF, 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 templates 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 (eXtensible 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 Universidade 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 virtude 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 modulariza as funcionalidades transversais (crosscut concerns) do Ginga, o MDD facilita a manipulaçã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 Ginga 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 variabilidade, interações entre features e relacionamentos transversais nas transformações implementadas 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 obrigató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 alternativas, que definem a plataforma de execução de TV digital (ST, Broadcom, PC ou Mobile); 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 variação Platform (ver Tabela 1). Além disso, Ginga ForAll apresenta relacionamentos transversais entre alguns elementos. Um exemplo é o ponto de variação Conditional Access, que interfere 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 representadas 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 JavaDTV ou NCL/Lua Requer Data Processing com Application Building Requer NCL/Lua Basic Requer Todos os formatos de mídia do Media Processing Application Manager NCL/Lua Complementary NCL/Lua Basic + Complementary De acordo com a Tabela 1, ao selecionar a variante Hardware do ponto de variação Demultiplexer, 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 Manager, 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 variante 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 manualmente, 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 source : target : } correlation source : target : } (break){ task_ref "Hardware" task_ref "PC" (break){ task_ref "Hardware" 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 Tabela 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 relacionamento 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 requisitos. 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 elementos, 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 PLAspectualACME 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 element: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 opcionais, descritas através de Representations), Platform (obrigatório, com variantes alternativas, descritas através de Representations), Demultiplexer (obrigatório, com variantes alternativas, 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 Tabela 1, o connector que modela uma relação transversal entre os elementos Conditional Access 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 modelo 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 descritos 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 momento 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 PLAspectualACME, 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 é transformada, através de mecanismos do Xtext, em um modelo ecore .xmi (transformação textomodelo). Este modelo, por sua vez, deve estar de acordo com o seu metamodelo ecore previamente 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 PLAspectualACME 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 templates 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 modelo 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 PLAspectualACME 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, atravé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 acordo 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 PLAspectualACME. 41 Tabela 2: Regras de mapeamento entre PL-AOVgraph e PL-AspectualACME 1 2 PL-AOVgraph Aspect_Oriented_Model GoalModel PL-AspectualACME Family System 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 Analysis Requires Analysis Excludes Property hurt, unknown, help Property Connector aspectual + Attachments 3 Task/Goal/Softgoal com Contribuição “and”, “or”, “xor” ou “inc-or” 8 4 5 6 7 8 Correlation Make Correlation Break Correlation hurt, unknown, help Propriedades (CardinalityMin, CardinalityMax, CardinalityGroupMin, CardinalityGroupMax, isFeature, GroupFeature e Generic Property) Relacionamento transversal (Crosscutting) 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 sentidos. Assim, temos que: 1. Aspect_Oriented_Model, de PL-AOVgraph é transformado em Family de PLAspectualACME 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 gerados 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 PLAspectualACME 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 Properties Hurt, Unknown e Break de PL-AspectualACME e vice-versa; 7. Properties de PL-AOVgraph são transformadas em Properties com o mesmo nome 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 elementos 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 transformaçõ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á existir em MaRiSA, é definida de forma diferente, uma vez que os metamodelos das linguagens sofreram alterações e os elementos que representam os relacionamentos transversais foram 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 elemento 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, é transformado 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 plaspetualacme: rule alternativeT{ from elem : PLAOVgraph!Element ((elem.type=#task or elem.type=#goal or elem.type=#softgoal) and (elem.refImmediateComposite().oclType() = PLAOVgraph!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 PLAspectualACME, 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 PLAspectualACME. Como o elemento gerado é um ponto de variação, é gerada, também a propriedade Variants, que lista as variantes desse ponto de variação. Além disso, para componentes, é 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 PLAspectualACME é 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 arquitetura e os detalhes de sua implementação (seção 4.2). As Descrições resultantes são apresentadas 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 ferramenta. Figura 19: Arquitetura da ferramenta MaRiPLA A ferramenta é implementada em ambiente Eclipse, com os recursos do EMF. Os elementos 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-amodelo (T2M), modelo-a-modelo (M2M) e modelo-a-texto (M2T), todas baseadas nos metamodelos 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 gerados 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 é transformada 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). Nesses 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 sintaxe (de acordo com a BNF definida no Xtext). Ao salvar o arquivo .mtl, são geradas automaticamente 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 modelo-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 (ilustrados no Capítulo 2 deste trabalho), criamos um projeto ATL, ao qual denominamos MariplaM2M, 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 PLAOVgraph e em PL-AspectualACME; um diretório para os metamodelos ecore das duas linguagens (Metamodels); um diretório para armazenar os modelos .xmi resultantes, após a aplicaçã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 biblioteca 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 PLAspectualACME (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 Conditional 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 Demultiplexer (obrigatórios e com filhos) e o componente obrigatório e sem filhos Conditional Access. 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, propriedades, entre outros. Os attachments, no modelo, conectam os roles dos conetores aos respectivos elementos. 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 ecore. 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 plataforma EMF, que permite a geração automática de código Java referente aos elementos do metamodelo 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). Podemos criar o modelo .genmodel com base em um diagrama UML, em modelos de classe Rose (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 geraçã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 metamodelo existente e o associamos ao .genmodel previamente criado. No projeto Xtext, definimos 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 extensã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 consiste 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 descriçõ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, utilizado 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 templates 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 PLAOVgraph e de PL-AspectualACME são exibidos nos Apêndices III e IV, ao final deste trabalho. 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 PLAspectualACME 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 é gerada automaticamente, a partir de PL-AspectualACME, podendo ser aberta no editor e alterada 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, respectivamente. 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êndices 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 rastreamento é realizado de forma bidirecional, avaliamos a descrição arquitetural PLAspectualACME 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 oferecer 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 elementos 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 claramente 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 infraestrutura 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 rastreabilidade 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 necessário. 57 5.2 Avaliação da Descrição PL-AspectualACME gerada a partir de PLAOVgraph 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 VariationPointT, apresentados na descrição gerada) e pontos de variabilidade (OptionalT e AlternativeT, 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 arquitetura 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 altamente 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 opcionais (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 reutilizado 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 é sintaticamente 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. Conectores comuns, porém, não foram contemplados na transformação, em virtude dessa carência. Com relação aos elementos de PL-AOVgraph que não possuem correspondentes em PLAspectualACME, estes geraram propriedades (como o operand, do relacionamento transversal, por exemplo, que gerou a property operand, no conector aspectual). Com relação à nomeaçã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 acrescentando informações que permitem uma melhor identificação. Um exemplo disso são as portas 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 „ConditionalAccess’, por exemplo, gerou o componente „ConditionalAcces’ com a porta „ConditionalAccessPort’. 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 modelo de requisitos e vice-versa. A manutenibilidade também é permitida, de acordo com os mesmos critérios do atributo 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 aspectual, 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 relacionamentos 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 hardware 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 estã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 requisitos 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, PLAOVgraph gerado de PL-AspectualACME contempla todos os elementos específicos do estudo 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, attributtes 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 rastreabilidade, 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 simplificado, uma vez que as propriedades permitem identificar o elemento de origem. Um conector aspectual de PL-AspectualACME, por exemplo, possui os elementos BaseRole, CrosscuttingRole 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 Elements 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, foram 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 propriedade 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 PLAOVgraph 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 modelo 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 criadas 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 arquiteto 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 mecanismos de plugin. A feature raiz do modelo de features implementa uma plataforma de conexã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ãoarquiteturais 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 requisitos 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 realizado 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 transversais 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 arquitetural 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 integrada, que automatize as transformações. Os autores do trabalho sugerem o uso de diversas ferramentas existentes para manipulação dos modelos. A automatização da ferramenta MaRiPLA, por sua vez, reduz esforço e tempo de derivaçã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 arquitetura de domínio de LPS, com base na Reusable Asset Specification (OMG-RAS, 2005), explicam 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 modelagem arquitetural (para o metamodelo de arquitetura), além de elementos que expressam variabilidades. 64 A partir desses dois metamodelos criados, define-se um terceiro metamodelo, que expressa 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) simplifica 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 metamodelagem, 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 especí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 arquitetural é a ADL ACME (Garlan et al, 1997). Na abordagem, é proposto um processo de mapeamento, em que são realizadas três atividades 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*, aproximando 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 é refinada, 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 MaRiPLA. 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 modelo 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 ferramenta 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 implementaçã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 transformaçõ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 gerenciamento 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 – Mapping 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 ForAll. As descrições geradas foram avaliadas com relação a atributos de qualidade específicos de LPS extraídos do Modelo de Qualidade CAFÉ (Anastasopoulos e Bayer, 2002): variabilidade, derivabilidade, reusabilidade, corretude (com os sub-atributos rastreabilidade e completude), 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 arquitetural e vice-versa. Outras contribuições incluem: a) Criação dos metamodelos de PL-AOVgraph e PL-AspectualACME, estendendo AOVgraph e AspectualACME, respectivamente; b) Definição dos modelos ecore xmi (em conformidade com os respectivos metamodelos), favorecendo a extensibilidade da ferramenta, uma vez que o modelo 67 serve como código intermediário, podendo ser mapeado para diferen tes linguagens; 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), acrescentando transformações que lidam com variabilidades e adaptando as regras existentes às atualizações realizadas nos metamodelos das linguagens de origem e destino; e) Definição de regras de transformações ATL entre os elementos dos metamodelos, estendendo as regras existentes em MaRiSA-MDD (Medeiros, 2008), acrescentando transformações que lidam com variabilidades e adaptando as regras 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, totalmente 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 implementaçã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 PLAOVgraph 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 abordagens (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 outros 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: Proceedings 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 Software 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 Proceedings of International Workshop on Software Specification and Design (IWSSD), pp 16– 25, 1996. (EA, 2011) Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design. 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 Modeling.2002. pp.167-181. (Kang et al, 1990) Kang, K.; Cohen, S.; Hess, J.; Novak, W.; Peterson, A. S. FeatureOriented 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 Armani. 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. Fukushima, 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 Interchance. 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. Advances 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 Requisitos. Tese de Doutorado, PUC-Rio, Rio de Janeiro, 2006. (Sochos et al, 2006) Sochos, P.; Philippow, I; Riebisch, M. The Feature-Architecture Mapping (FArM) Method for Feature-Oriented Development of Software Product Lines. Disponí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 Requirements 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 aspects from requirements goal models. Trabalho apresentado no IEEE International Symposium 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') target=[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 (intertype+=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 cut=[Element|STRING]; joinpointPoint- 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') joinpointAdvice+=[Element|STRING] '(' ('and' | 'or' | 'xor' | 'inc-or')? ')')+ '}'; enum AdviceCategory returns AdviceCategory: around = 'around' | before = 'before' | after = 'after'; IntertypeDeclaration returns IntertypeDeclaration: 'intertype declaration' '(' type=IntertypeCategory ')' ':' idPointcut+=[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 (representation+=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 (representation+=Representation)*)? '}'(';')?; Variants returns Variants: 'property'key='variants''=''{' value=EString '}'(';')?; SelectedVariants returns SelectedVariants: 'property'key='selectedVariants''=''{' value=EString '}'(';')?; Binding returns Binding: {Binding} 'binding' '(' (externalElem=[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 (representation+=Representation)*)? '}'(';')?; Component_Impl returns Component: {Component} 'component'name=EString'=''{' (port+=Port (port+=Port)*)? (property+=Property (property+=Property)*)? (representation+=Representation (representation+=Representation)*)? '}'(';')?; Role_Impl returns Role: {Role} 'role'name=EString'=''{' ('refPort' '=' '{'(refPort+=[Element|EString] (refPort+=[Element|EString])*)?'}'(';')?)? (property+=Property (property+=Property)*)? (representation+=Representation (representation+=Representation)*)? '}'(';')?; Connector returns Connector: {Connector} 77 'connector'name=EString'=''{' (property+=Property (property+=Property)*)? (representation+=Representation ( representation+=Representation)*)? (role+=Role (role+=Role)*)? (glue+=Glue (glue+=Glue)*)? '}'(';')?; BaseRole returns BaseRole: {BaseRole} 'base role'name=EString'=''{' ('refPort' '=' '{'(refPort+=[Element|EString] (refPort+=[Element|EString])*)?'}'(';')?)? (property+=Property (property+=Property)*)? (representation+=Representation ( representation+=Representation)*)? '}'(';')?; CrosscuttingRole returns CrosscuttingRole: {CrosscuttingRole} 'crosscutting role'name=EString'=''{' ('refPort' '=' '{'(refPort+=[Element|EString] (refPort+=[Element|EString])*)?'}'(';')?)? (property+=Property (property+=Property)*)? (representation+=Representation (representation+=Representation)*)? '}'(';')?; VariationPointT_Impl returns VariationPointT: {VariationPointT} 'component'name=EString':''new''VariationPointT''extended''with''=''{ ' (port+=Port (port+=Port)*)? (property+=Property (property+=Property)*)? (representation+=Representation (representation+=Representation)*)? '}'(';')?; OptionalT returns OptionalT: {OptionalT} 'component'name=EString':''new''OptionalT''extended''with''=''{' (port+=Port (port+=Port)*)? (property+=Property (property+=Property)*)? (representation+=Representation (representation+=Representation)*)? '}'(';')?; InclusiveOrT returns InclusiveOrT: {InclusiveOrT} 'component'name=EString':''new''InclusiveOrT''extended''with''=''{' (port+=Port (port+=Port)*)? (property+=Property (property+=Property)*)? (representation+=Representation (representation+=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'':' crosscuttingAttach=[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: Relationship | 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: Relationship | 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/]" ([returnContribution(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/] glueType:[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 PLAspectualACME -- @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 raiz 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 | thisModule.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 plaspetualacme: rule component{ from elem :PLAOVgraph!Element ((elem.type=#task or elem.type=#goal or elem.type=#softgoal) and (elem.refImmediateComposite().oclType() = PLAOVgraph!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 | thisModule.isFeat2prop(i)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisModule.card2prop(c)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisModule.group2prop(g)), property <- elem.property-> select(p | p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisModule.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() = PLAOVgraph!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 | thisModule.isFeat2prop(i)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisModule.card2prop(c)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisModule.group2prop(g)), property <- elem.property-> select(p | p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisModule.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() = PLAOVgraph!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 | thisModule.isFeat2prop(i)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisModule.card2prop(c)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisModule.group2prop(g)), property <- elem.property-> select(p | p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisModule.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 AlternativeT de plaspetualacme: rule alternativeT{ from elem : PLAOVgraph!Element ((elem.type=#task or elem.type=#goal or elem.type=#softgoal) and (elem.refImmediateComposite().oclType() = PLAOVgraph!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 | thisModule.isFeat2prop(i)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisModule.card2prop(c)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisModule.group2prop(g)), property <- elem.property-> select(p | p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisModule.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 InclusiveOrT 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 | thisModule.isFeat2prop(i)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisModule.card2prop(c)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisModule.group2prop(g)), property <- elem.property-> select(p | p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisModule.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 encapsula 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() = PLAOVgraph!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 | thisModule.isFeat2prop(i)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisModule.card2prop(c)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisModule.group2prop(g)), property <- elem.property-> select(p | p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisModule.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() = PLAOVgraph!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 | thisModule.isFeat2prop(i)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisModule.card2prop(c)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisModule.group2prop(g)), property <- elem.property-> select(p | p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisModule.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() = PLAOVgraph!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 | thisModule.isFeat2prop(i)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisModule.card2prop(c)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisModule.group2prop(g)), property <- elem.property-> select(p | p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisModule.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() = PLAOVgraph!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 | thisModule.isFeat2prop(i)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisModule.card2prop(c)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisModule.group2prop(g)), property <- elem.property-> select(p | p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisModule.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() = PLAOVgraph!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 | thisModule.isFeat2prop(i)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!Cardinality))->collect(c | thisModule.card2prop(c)), property <- elem.property->select(p | p.oclIsTypeOf(PLAOVgraph!GroupFeature))->collect(g | thisModule.group2prop(g)), property <- elem.property-> select(p | p.oclIsTypeOf(PLAOVgraph!Generic_Property))->collect(gen | thisModule.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 PLAspectualACME 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 | thisModule.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 -> collect(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 -> collect(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 -> collect(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 | thisModule.sys2goal(s)) ) } -- 02 -- Regra que transforma System filho da Family em Goal Model lazy rule sys2goal { from sys : PLAspectualACME!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 : PLAspectualACME!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' endif endif endif ) } -- 04 -- Component pra Element primeiro nivel 'and' com ou sem filhos rule comp2element { from comp : PLAspectualACME!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' endif 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 -> collect(comp|comp.property.asOrderedSet()->select(p | p.key='cardinality')>collect(c | thisModule.prop2card(c))), property <- rep.system.component -> collect(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 anReq.source.oclIsTypeOf(PLAspectualACME!Representation) then anReq.source else anReq.source.refImmediateComposite().refImmediateComposite() endif, target <- if anReq.target.oclIsTypeOf(PLAspectualACME!Representation) then anReq.target else anReq.target.refImmediateComposite().refImmediateComposite() endif ) } -- 08 - Regra que transforma property correlation de PLAspectualACME em Relationship Correlation de PLAOVgraph lazy rule prop2correlation { from prop : PLAspectualACME!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 property 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 property 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 PLAOVgraph 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 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;); extended 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 PLAspectualACME 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) } } } };