Meta-Modelagem

A meta-meta-modelagem é responsável por definir uma linguagem para a especificação de metamodelos. A Object Management Group (OMG) definiu uma linguagem para a especificação de metamodelo denominada Meta Object Facility (MOF) [37]. Esta linguagem oferece um framework para o gerenciamento de metadados e um conjunto de serviços de metadados para permitir o desenvolvimento e a interoperabilidade de modelos e sistemas que utilizam metadados.

As tecnologias da OMG, incluindo UML (Unified Modeling Language), MOF, XMI1, dentre outras, usam MOF e tecnologias derivadas de MOF para a troca e manipulação de metadados [37].

A Figura 2.7 apresenta uma infraestrutura em 4 camadas da primeira geração de tecnologias MDD, ou seja, UML e MOF. Esta infraestrutura apresenta uma hierarquia

1_{XMI é um formato de intercâmbio amplamente utilizado para o compartilhamento de modelos usando} XML [38].

Figura 2.7 Infraestrutura Tradicional MDD. Adaptado de [3].

divida por modelos. Cada modelo (exceto o M3) é caracterizado como uma instância do nível acima.

O nível mais baixo, M0, é responsável por manipular os dados de usuário. Dados reais em que softwares são projetados para manipular. O nível M1 representa o próprio modelo, ou seja, é designado para manipular um modelo dos dados de usuário M0. O próximo nível, M2, é conhecido como metamodelo por ser um modelo de modelo. M2 é um modelo que mantém informações do modelo M1. Por último, M3 é um modelo de informações em M2, e por isso é chamado de meta-metamodelo [3].

Neste estudo, é proposto o desenvolvimento de um metamodelo (nível M2) para a ferramenta proposta. Sendo possível assim, gerar os níveis M1 e M0. O metamodelo a ser desenvolvido, será construído utilizando a tecnologia da UML, que é revisada na próxima seção.

2.3.1

UML - Unified Modeling Language

A UML é uma linguagem de modelagem proposta pela OMG, a qual é uma das mais usadas para especificação, construção e documentação de artefatos de software. É uma linguagem de modelagem de propósito geral, e pode ser usada para todos os domínios de aplicações como saúde, espaço aéreo e telecomunicações. Contudo, podem existir situações em que uma linguagem de um propósito tão geral e amplo não seja apropri- ado para a modelagem de aplicações de um domínio específico. Isto pode acontecer quando queremos expressar conceitos específicos de um determinado domínio, ou quando

48

queremos restringir ou customizar alguns dos elementos da UML.

A OMG discute duas abordagens possíveis para definir uma linguagem específica de domínio. A primeira é a criação de uma nova linguagem baseada nos mecanismos oferecidos pela própria OMG para definição de linguagens visuais. Assim, sintaxe e semântica dos elementos da nova linguagem precisam ser definidos de acordo com as características do domínio [20].

A segunda alternativa se concentra na especialização da UML. Alguns elementos da linguagem são especializados, impondo novas restrições sobre eles em relação ao metamodelo UML. A semântica dos elementos UML não é alterada (as propriedades de uma classe UML, associações, atributos, etc, serão os mesmos). Um profile em UML oferece mecanismos de extensões genéricos para a customização de modelos UML para domínios e plataformas particulares. Profiles são definidos utilizando stereotypes, tag definitionse constraints [20].

• Stereotypes: são definidos por um nome e um conjunto de elementos do metamo- delo que são anexados;

• Constraints: podem estar associadas a estereótipos, impondo restrições sobre os elementos do metamodelo correspondente;

• Tag definitions: é um meta-atributo adicional que é anexado a uma meta-classe de um metamodelo estendido por um Profile.

Para este estudo, foi utilizada a primeira abordagem para o desenvolvimento da ferramenta. Portanto, é necessário construir uma linguagem de modelagem específica de domínio para a abordagem BVCCoN.

2.3.2

DSML - Linguagem para Modelagem Específica de Domínio

Quando tratamos de um domínio específico, as linguagens de modelagem, como por exemplo, UML, BPMN e i*, podem não conter todos os elementos necessários para realizar a modelagem. Assim, pode ser útil a criação de uma linguagem específica de domínio, (do inglês DSL - Domain Specific Language) para descrever com maiores detalhes as características mais importantes de um domínio específico.

Uma DSL é uma linguagem que está direcionada em um domínio particular de problema, oferecendo um conjunto restrito de notações e abstrações apropriadas. Contudo, as DSLs contém uma linguagem de propósito geral (do inglês, GPL - General Purpose

Language) incorporada como uma sub-linguagem. Assim, oferecem um poder expressivo específico do domínio em conjunto com o poder de expressividade de uma GPL [51].

Isto acontece quando DSLs são implementadas como linguagens embarcadas. Por- tanto, quando não é desejado criar uma linguagem de programação, é melhor herdar toda infraestrutura de alguma outra linguagem, adequando-a em formas especiais para o domínio de interesse. Assim, é possível adquirir uma Linguagem Embarcada Específica de domínio (do inglês, DSEL - Domain Specific Embedded Language) [22].

Já uma Linguagem para Modelagem Específica de Domínio (do inglês, DSML - Domain Specific Modeling Languages) objetiva elevar o nível de abstração, especificando a solução em uma linguagem que usa diretamente os conceitos e regras de um domínio de problema específico. A ideia é modelar produtos de software utilizando DSL e gerar produtos finais em uma linguagem de programação escolhida ou em outras formas, como texto, modelo, código, a partir das especificações de alto nível que foram definidas [24]. As DSLs são classificadas como interna, externa e não textuais. Uma DSL interna é aquela que usa toda infraestrutura de uma linguagem de programação existente para construir semânticas específica de domínio sobre a mesma. Uma das mais populares DSL interna é Rails [44], que é implementada em cima da linguagem de programação Ruby[43]. Escrevendo código Rails é a mesma coisa que programar em Ruby, só que utilizando a semântica que Rails implementa para o desenvolvimento de aplicações web [21].

Uma DSL externa é aquela que é desenvolvida similar à implementação de uma nova linguagem de programação, possuindo sua própria sintaxe e semântica. Uma DSL necessita ser uma representação do domínio, mas isto não implica que sua representação precisa ser apenas textual. DSL não textual é aquela que pode modelar o domínio utilizando formas gráficas [21]. Nesta dissertação foram utilizados formas gráficas para modelar o domínio da configuração de processos de negócio dinâmicos.

Para definir uma DSL, é necessário desenvolver uma sintaxe concreta e abstrata, seguida de uma semântica projetada para definir o significado da linguagem. Uma sintaxe abstrata de uma linguagem é definida a partir do método de meta-modelagem. Isto simplifica o desenvolvimento da linguagem, permitindo aos designers mapear diretamente as classes da análise de domínio para classes no metamodelo, associações e herança que são parte da definição da DSL.

A sintaxe abstrata descreve os conceitos da linguagem, as relações entre eles e as regras de estruturação que restringem a combinação de elementos do modelo de acordo com as regras de domínio. A partir do metamodelo, é construída a sintaxe

50

concreta. Ela especifica como os conceitos de domínio incluídos no metamodelo são representados, e é geralmente definido por um mapeamento entre o metamodelo e uma notação textual ou gráfica [26]. Durante o desenvolvimento da ferramenta, identificamos incompatibilidade entre sintaxe concreta e abstrata, portanto, realizamos alterações necessárias para solucionar o problema. Uma vez definido a linguagem específica de domínio, foi necessário utilizar tecnologias para o desenvolvimento da ferramenta.

2.4

Tecnologias

Esta seção é responsável por apresentar alguns conceitos e tecnologias que foram uti- lizadas para o desenvolvimento da ferramenta de modelagem proposta neste estudo. Para o desenvolvimento da ferramenta proposta, foi utilizado um conjunto unificado de frameworksde modelagem, ferramentas e implementações de padrões encontrados na comunidade Eclipse [11].

Dentre os frameworks de modelagem, destaca-se o EMF (Eclipse Modeling Fra- mework) [10], que auxilia a especificação de metamodelos e provê funcionalidades para a geração automática do código Java respectivo, o GMF (Graphical Modeling Framework) [15], que é uma abordagem model-driven para o desenvolvimento de editores gráficos baseados no eclipse e o Epsilon [12], [7], que é uma família de linguagens e ferramentas destinadas à atividades de gerenciamento de metamodelos.

2.4.1

Eclipse Modeling Framework

O projeto EMF é um framework de modelagem e geração de código para a construção de ferramentas baseado em um modelo de dados estruturado (modelo de domínio). A partir de um modelo de domínio especificado em XMI ou em outro formato suportado, o EMF fornece ferramentas e suporte runtime à produção de classes Java que implementam esse modelo. Assim como um conjunto de classes adapter que permite a edição e visualização do modelo através de código Java, e um editor básico.

O EMF é composto de 3 peças fundamentais. 1) Framework EMF Ecore, que inclui um metamodelo Ecore para os modelos descritos e suporte runtime para os modelos, 2) EMF.Edit, que fornece um conjunto de classes genéricas reusáveis para a construção de editores para modelos EMF, e por último, 3) EMF.Codegen, responsável por gerar todo código necessário para construir um editor completo para um modelo EMF [10].

O metamodelo Ecore é composto pelos componentes Eclass, utilizado para represen- tar uma metaclasse; EAttribute, para representar um atributo de uma Eclass; EReference,

utilizado para descrever associações entre classes; e EEnum, usado para descrever enume- rações. EMF possui três níveis de geração de código: 1) Modelo, oferece interface Java e implementação de classes para todas as classes descritas no metamodelo da ferramenta CASE a ser construída, 2) Adaptadores, capazes de gerar classes de implementação que adaptam as metaclasses do modelo para visualização e edição, 3) Editor, produz uma estrutura do modelo que poderá ser visualizada na fase de criação do editor gráfico [1].

2.4.2

Graphical Modeling Framework

GMF é um framework para a construção de editores gráficos a partir de metamodelos baseado em EMF. Para a construção de editores gráficos utilizando o GMF, é necessário seguir um processo bem definido. Para facilitar a execução deste processo, o desenvolve- dor pode contar com a ajuda de um painel chamado GMF Dashboard. Este painel serve como um guia durante o desenvolvimento. O GMF Dashboard está ilustrado na Figura

2.8[15].

Figura 2.8 Dashboard GMF

A geração de um editor gráfico GMF consiste na criação e manipulação de alguns arquivos.

1. Domain Model - representa o metamodelo utilizado para criar o editor gráfico. É necessário importar o metamodelo de domínio definido em Ecore;

2. Domain GenModel - arquivo .genmodel usado para gerar código do domain model; 3. Graphical Def Model - arquivo .gmfgraph responsável por definir os elementos gráficos que representarão cada um dos objetos que foram definidos no arquivo Ecore do Domain Model.

52

4. Tooling Def Model - arquivo com terminação .gmftool utilizado para definir os elementos da paleta de ferramentas.

5. Mapping Model - o arquivo do modelo de mapeamento .gmfmap é criado para relacionar os elementos do metamodelo aos elementos do modelo gráfico e aos elementos do modelo ferramental.

6. Diagram Editor GenModel - o GMF fornece um modelo de gerador para gerar o código executável do editor gráfico.

2.4.3

Epsilon

Epsilon é uma família de linguagens e ferramentas destinadas à atividades de gerencia- mento de metamodelos. Essas atividades são: geração de código, transformação modelo para modelo, validação de modelo, comparação, migração e refactoring de modelos [12]. Dentre as linguagens e ferramentas da família Epsilon, as seguintes se destacam:

• EuGENia • Emfatic

• EOL (Epsilon Object Language) • EVL (Epsilon Validation Language) • ETL (Epsilon Transformation Language) • EGL (Epsilon Generation Language) • EWL (Epsilon Wizard Language)

EuGENia é uma ferramenta que facilita a geração de editores gráficos em GMF, diminuindo a complexidade imposta pelo mesmo [13]. EuGENia gera ferramentas gráficas a partir de um metamodelo Ecore com anotações escritas na linguagem Emfatic [16]. Emfatic é uma linguagem que foi projetada para representar modelos Ecore EMF de maneira textual simples e compacta, similar à linguagem Java. Esta linguagem permite definir metaclasses, atributos de metaclasses, enumerações, relacionamentos entre metaclasses, dentre outros elementos do modelo EMF Ecore.

A partir de um arquivo escrito em Emfatic (arquivo .emf), que representa a sintaxe abstrata da linguagem de modelagem, é possível gerar um modelo Ecore (arquivo .ecore),

o inverso também é possível. A partir do metamodelo .emf construído, é necessário enriquecê-lo com anotações em EuGENia, que definirá os artefatos concretos a ser representado no editor gráfico. Assim, é possível definir em Emfatic quais metaclasses são nós ou links, definir a figura (retângulo, elipse) de um nó que serão exibidos graficamente, definir a origem (source) e o destino (target) de um link. Tudo o que é definido no arquivo Emfatic é gerado um metamodelo Ecore de EMF. A partir do arquivo Ecore gerado, EuGENia gera os modelos EMF e GMF.

A Listagem 2.1demonstra uma versão anotada do metamodelo. Em particular, as anotações representam o seguinte:

• Linha 5: o elemento diagram representa o objeto raiz do metamodelo. Apenas uma Eclassnão abstrata deverá ser anotada como gmf.diagram;

• Linha 16: cada pasta tem um compartimento onde sub-componentes podem ser alocados;

• Linha 25: cada Sync é representado como um link (associação) entre seus arquivos sourcee target. A representação gráfica do link é através de uma linha pontilhada; • Linha 31: cada arquivo é representado no diagrama como um retângulo que possui

um nome dentro.

Listagem 2.1 Metamodelo escrito em Emfatic

1 @namespace ( u r i =" f i l e s y s t e m " , p r e f i x =" f i l e s y s t e m " ) 2 @gmf 3 package f i l e s y s t e m ; 4 5 @gmf . d i a g r a m 6 c l a s s F i l e s y s t e m { 7 v a l D r i v e [ * ] d r i v e s ; 8 v a l Sync [ * ] s y n c s ; 9 } 10 11 c l a s s D r i v e e x t e n d s F o l d e r { 12 13 } 14 15 c l a s s F o l d e r e x t e n d s F i l e { 16 @gmf . c o m p a r t m e n t 17 v a l F i l e [ * ] c o n t e n t s ;

54 18 } 19 20 c l a s s S h o r t c u t e x t e n d s F i l e { 21 @gmf . l i n k ( t a r g e t . d e c o r a t i o n =" a r r o w " , s t y l e =" d a s h " ) 22 r e f F i l e t a r g e t ; 23 } 24 25 @gmf . l i n k ( s o u r c e =" s o u r c e " , t a r g e t =" t a r g e t " , s t y l e =" d o t " , w i d t h = " 2 " ) 26 c l a s s Sync { 27 r e f F i l e s o u r c e ; 28 r e f F i l e t a r g e t ; 29 } 30 31 @gmf . n o d e ( l a b e l = " name " ) 32 c l a s s F i l e { 33 a t t r S t r i n g name ; 34 }

Existem inúmeras anotações além das que foram exibidas na Listagem2.1. Em [14], é apresentado a listagem completa de todas as anotações que o Eugenia oferece para serem inseridas em um modelo que foi criado utilizando a linguagem Emfatic.

EOL é uma linguagem de programação imperativa para criar, consultar e modificar modelos EMF. Fornece características imperativas habituais como presença de variáveis, comandos sequenciais, estruturas de controle e de desvio condicional, além de outras características. Outras linguagens da família Epsilon como EVL, podem incorporar porções código EOL em suas estruturas de código [7].

EVL é uma linguagem de validação que pode ser utilizada para adicionar validações e fazer pequenos ajustes no editor gráfico GMF [18]. As restrições em EVL são similares às OCL2, porém, EVL suporta dependência entre constraints (se uma constraint A falha, a constraint B não será avaliada). Mensagens de erro customizadas podem ser exibidas aos usuários e um mecanismo de conserto pode ser ativado pelos usuários para reparar inconsistências[7].

Em EVL, as especificações de validação são organizadas em módulos. A Listagem

2.2exibe um trecho de código escrito em EVL e os itens abaixo apresentam os módulos EVL. Em seguida, é indicado as linhas da Listagem2.2 em que determinado módulo aparece.

• Context - um contexto especifica o tipo de instância que as invariantes serão

aplicadas (Linhas 1 e 8);

• Invariant - cada invariante EVL define um nome e uma verificação (check). Uma invariante também pode definir uma mensagem que será exibida ao usuário caso alguma restrição falhe. Para apoiar o conserto semiautomático de elementos, uma invariante pode definir um número de fix (Linhas 4 e 12);

• Guard - Guards são usados para limitar a aplicabilidade de invariantes. Um guard limita a aplicabilidade de todas as invariantes do contexto, enquanto a nível de invariant, guard limita a aplicabilidade de uma invariante específica (Linha 10); • Fix - Fix determina ações a serem realizadas para corrigir uma inconsistência. A

parte de código "do"encontrada na Listagem2.2, é definida usando a linguagem EOL e é responsável pela correção da funcionalidade;

• Constraint - Constraints são usadas para capturar erros críticos que invalidam o modelo (Linha 2);

• Critique - ao contrário de constraints, critiques são usadas para capturar situações que não invalidam o modelo, mas que devem ser levadas em consideração pelo usuário para melhorar a qualidade do modelo (Linha 9).

• Pre and Post - um módulo EVL pode definir um número de blocos chamados pre e post que são escritos em EOL e executados antes ou depois de uma invariante ser avaliada respectivamente.

Listagem 2.2 Exemplo de Código EVL

1 c o n t e x t F i l e {

2 c o n s t r a i n t HasName {

3 c h e c k : s e l f . name . i s D e f i n e d ( )

4 message : ’ Unnamed ’ + s e l f . e C l a s s ( ) . name + ’ n o t a l l o w e d ’

5 } 6 } 7 8 c o n t e x t F o l d e r { 9 c r i t i q u e N a m e S t a r t s W i t h C a p i t a l { 10 guard : s e l f . s a t i s f i e s ( ’ HasName ’ ) 11 c h e c k : s e l f . name . f i r s t T o U p p e r C a s e ( ) = s e l f . name 12 message : ’ F o l d e r ’ + s e l f . name + 13 ’ s h o u l d s t a r t w i t h an u p p e r −c a s e l e t t e r ’

56 14 f i x { 15 t i t l e : ’ Rename t o ’ + s e l f . name . f i r s t T o U p p e r C a s e ( ) 16 do { 17 s e l f . name : = s e l f . name . f i r s t T o U p p e r C a s e ( ) ; 18 } 19 } 20 } 21 }

O objetivo da linguagem ETL é realizar transformações de modelos (model-to-model). Mais especificamente, ETL pode ser usado para transformar um número arbitrário de mo- delos de entrada para um número arbitrário de modelos de saída de diferentes linguagens de modelagem e tecnologias em um alto nível de abstração [17]. EGL é uma linguagem model-to-text. A partir de um metamodelo construído em Ecore, pode-se obter código executável, relatórios HTML, documentação, imagens (usando pontos) e outros artefatos textuais [25] [7].

Transformações de atualização são ações que automaticamente cria, atualiza ou deleta elementos do modelo baseado na seleção de elementos existentes no modelo e nas informações fornecidas pelo usuário (através de dados de entrada). EWL é a linguagem da família Epsilon que oferece esse suporte [7].

2.4.4

Estudos que Desenvolveram Ferramentas de Modelagem

A seguir, apresentamos estudos que realizaram pesquisa na área de desenvolvimento de ferramentas de modelagem. Estes estudos utilizaram tecnologias que também foram utilizadas nesta dissertação, como o Framework Eclipse em conjunto com os plugins EMG/GMF e também o Framework Epsilon.

IStar Tool - Uma Proposta de Ferramenta para Modelagem i*

O estudo descrito em [46] propõe o desenvolvimento de uma ferramenta de modela- gem i*. Um novo metamodelo é desenvolvido para a nova versão do i* e um processo de desenvolvimento para obter uma ferramenta gráfica de modelagem.

Para o desenvolvimento da ferramenta, foi adotado o GMF Framework, que permite a modelagem do domínio e a geração automática de código para representar os elementos gráficos que farão parte do modelo. O metamodelo foi criado a partir do Framework EMF e escrito em Ecore.

A partir de um guia i* (contendo guidelines e boas práticas), o autor definiu um conjunto de restrições que foram escritas utilizando a linguagem de restrição OCL. Um

exemplo de restrição é que um elemento não pode se ligar a ele mesmo. Uma segunda restrição é que a utilização do link de associação só é permitida para nós do tipo ator.

Após o desenvolvimento da ferramenta, a mesma foi aplicada em diferentes cenários, visando exemplificar seu uso e também realizar uma verificação para ver se as restrições que foram definidas anteriormente estavam sendo executadas corretamente. A conclusão obtida foi que a ferramenta se comportou de maneira apropriada.

Uma Linguagem Específica do Domínio para uma Abordagem Orientada a Ob- jetivos Baseada em KAOS

O estudo apresentado em [6], demonstra um novo metamodelo da linguagem KAOS baseado em um previamente existente. A partir deste metamodelo, uma ferramenta é desenvolvida. Para lidar com problemas de escalabilidade, os autores utilizaram o conceito de Compartimento.

Para implementar este conceito, o metamodelo foi estendido com caixas (Comparti- mentos) em que é possível guardar elementos específicos pertencentes aquela caixa. Estas caixas possuem uma característica de colapso, em que a partir de um clique é possível apresentar ou omitir porções do diagrama.

A ferramenta apresentada nesta dissertação também possui este conceito de compar- timento. Assim, é possível esconder ou apresentar pedaços do modelo, obtendo uma melhor escalabilidade e diminuindo a complexidade visual. Visto que a capacidade de colapso facilita a leitura dos modelos.

Para projetar o editor gráfico, os autores utilizaram o Framework Eclipse em conjunto com os plugins EMF/GMF. Estenderam o metamodelo Ecore já existente e definiram no metamodelo o que irá representar os conceitos da linguagem KAOS. Para validar a ferramenta os autores realizaram um estudo de caso e uma avaliação de usabilidade.

A avaliação de usabilidade consistiu de um questionamento sobre a sintaxe da lin- guagem, facilidade de utilização da ferramenta e níveis de satisfação da ferramenta. Em geral, os utilizadores mostraram grande aceitação da ferramenta. Ficaram satisfeitos e a acharam fácil de utilizar.

AGILE: Uma Abordagem para Geração Automática de Linguagens i*

Em [4], o autor definiu uma abordagem automatizada para a definição estrutural de linguagens baseadas no i* e a geração automática de ferramentas CASE de modelagem correspondentes utilizando os conceitos de linhas de produtos de software.

As tecnologias utilizadas para desenvolver uma ferramenta que automatize a definição de metamodelos de linguagens i* e a geração automática de editores gráficos foram o EMF/GMF, baseadas no Eclipse. O autor definiu um metamodelo núcleo (escrito em

58

Ecore) com base nos construtores comuns das linguagens i* com suporte para a inserção de variabilidade existente nas diversas linguagens baseadas no i*.

A ferramenta proposta auxilia o usuário a projetar a estrutura de uma nova linguagem i* utilizando apenas uma interface gráfica, reduzindo consideravelmente alterações ma- nuais e direta em toda estrutura GMF. Com o propósito de testar a ferramenta, o autor