Processo de Desenvolvimento de um Editor Gr´afico utilizando o plug-in

Para explicar o processo de desenvolvimento do plug-in deste trabalho, utiliza-se a Figura 37. Esta figura demonstra o fluxo de trabalho necess´ario para gerar um editor gr´afico utilizando o plug-in GMF do eclipse.

Figura 37: Dashboard do GMF Eclipse.

O processo de desenvolvimento consiste na concepc¸˜ao de seis arquivos. O primeiro chama-se Ecore e representa o Domain Model. ´E neste arquivo que ´e especificado o metamodelo do editor. O metamodelo serve para regulamentar todas as ac¸˜oes posteriores que o editor gr´afico possa ter, por exemplo, quais entidades ter˜ao relacionamento e quais n˜ao ter˜ao. Embora n˜ao aparec¸a na figura em quest˜ao, seguinte a modelagem do Ecore ´e poss´ıvel gerar um arquivo .diagram, que representa respectivamente um diagrama de classes do metamodelo desenvolvido.

O pr´oximo passo na elaborac¸˜ao do editor gr´afico ´e derivar o Domain Gen Model do editor. Por esse motivo existe o bot˜ao Derive ao lado esquerdo da caixa Domain Mo- del no dashboard. Conforme DUARTE (2015), posterior ao clique de derivar, ´e feita uma transformac¸˜ao do metamodelo gerado no Ecore para um metamodelo espec´ıfico com extens˜ao .genmodel, para que a partir deste, sejam gerados c´odigos na linguagem de programac¸˜ao Java. Em FOUNDATION (2014d) ´e explicado que o arquivo genmodel cont´em informac¸˜oes adicionais para a gerac¸˜ao de c´odigo, como o caminho e informac¸˜oes do arquivo. Al´em disso, ele tamb´em cont´em o parˆametro de controle de como o c´odigo deve ser gerado na linguagem java.

O metamodelo estipulado no Domain Model ´e a base para a gerac¸˜ao do restante dos artefatos do projeto de gerac¸˜ao de um editor gr´afico, utilizando o GMF eclipse. Os dois primeiros passos descritos anteriormente, correspondem ao EMF. Servem para regula- mentar os passos restantes.

lher entre criar a paleta de componentes que ser´a utilizada pelo editor gr´afico ou o campo de desenho que servir´a para modelar o diagrama. O bot˜ao Derive localizado na parte inferior e superior da caixa do Domain Model gera esses elementos, respectivamente.

Sobre o campo de desenho utilizado para modelar os diagramas, ´e derivado o Domain Model e corresponde a caixa chamada Graphical Del Model. O arquivo gerado nesta transformac¸˜ao tem a extens˜ao .gmfgraph. Al´em disso, atrav´es da plataforma eclipse pode-se editar este arquivo, adicionando pontos provenientes de figuras geom´etricas em cada entidade derivada do Ecore (GRONBACK, 2009). Pode-se tamb´em alterar a cor da figura estipulada, adicionar caixa de texto para que o usu´ario informe o nome da entidade a ser modelada, dentre diversas outras possibilidades (GRONBACK, 2009). ´E neste ar- quivo que se configura toda a caixa de desenho, onde depois de pronta, ser´a utilizada pelo usu´ario para modelar seu diagrama por interm´edio do editor gr´afico.

Em relac¸˜ao a paleta de componentes que ir´a do lado do campo de desenho do edi- tor gr´afico desenvolvido, este ´e concebido tamb´em por meio do Domain Model. Ap´os a solicitac¸˜ao de derivac¸˜ao do Domain Model em relac¸˜ao a caixa chamada Tooling Del Model, ´e gerado um arquivo com a extens˜ao .gmftool. Este arquivo contem a respectiva configurac¸˜ao de como ser˜ao disponibilizados os componentes gr´aficos para serem utili- zados no campo de desenho do editor gr´afico (GRONBACK, 2009). Sua configurac¸˜ao ´e simples, apenas pode-se alterar as figuras que correspondem aos respectivos campos e agrupar os campos em categorias diversas. Pode-se tamb´em criar categorias.

O pr´oximo passo da elaborac¸˜ao da ferramenta ´e fazer a combinac¸˜ao entre todos os ar- quivos gerados anteriormente. Por interm´edio do bot˜ao Combine ´e feita essa combinac¸˜ao, gerando um arquivo na caixa chamada Mapping Model, ilustrada na Figura 37. O arquivo gerado nessa caixa tem a extens˜ao .gmfmap. Segundo GRONBACK (2009), talvez o mais importante de todos os modelos em GMF ´e o Mapping Model. Nele, elementos de definic¸˜ao do diagrama (n´os e links) s˜ao mapeados para o modelo de dom´ınio e elementos de ferramentas atribu´ıdas. O Mapping Model representa o diagrama de definic¸˜ao real e ´e usado para criar um modelo de gerador. Tipicamente, existe um mapeamento um-para- um entre um modelo de mapeamento, o seu modelo de gerador e um campo de desenho em particular.

O ´ultimo passo no desenvolvimento do editor gr´afico ´e fazer a gerac¸˜ao do arquivo que ficar´a respons´avel em fazer a junc¸˜ao de todos os outros componentes abordados no decorrer do desenvolvimento. O nome da caixa equivalente a esse processo ´e Diagram Editor Gen Modelilustrada na Figura 37. A partir do arquivo .gmfmap e arquivo .ecore ´e gerado o arquivo .gmfgen. Este arquivo ´e respons´avel por gerar as configurac¸˜oes de onde ser´a gerado os c´odigos fontes para a execuc¸˜ao do editor gr´afico modelado no decorrer de todo esse processo. Posterior a configurac¸˜ao desse arquivo, inicia-se o processo de transformac¸˜ao, gerando o c´odigo fonte correspondente as etapas anteriores realizadas. No momento da finalizac¸˜ao dessa transformac¸˜ao, tem-se os c´odigos fontes que poder˜ao

METHEUS AEOLUS

Este cap´ıtulo apresenta os procedimentos realizados para o desenvolvimento da ferra- menta para apoio a metodologia Prometheus AEOlus.

A arquitetura geral da ferramenta Prometheus AEOlus ´e ilustrado na Figura 38. Cada pacote representa um plug-in gerado para incorporar func¸˜oes a ferramenta desenvolvida. O pacote chamado gerador, representa o plug-in respons´avel pela gerac¸˜ao de c´odigos da ferramenta. Dentro desse plug-in, s˜ao agrupadas as classes respons´aveis por realizar a func¸˜ao designada ao plug-in. Seu desenvolvimento ´e descrito em detalhes na Sec¸˜ao 5.3. Esse pacote cont´em uma ligac¸˜ao de dependˆencia com o pacote diagram devido a necessitar de informac¸˜oes fornecidas pelo mesmo.

Figura 38: Arquitetura Geral do plug-in Prometheus AEOlus.

O pacote diagram comporta o plug-in editor gr´afico. Esse pacote compila todos os arquivos de configurac¸˜ao e os c´odigos gerados por todo o desenvolvimento proveniente do plug-in GMF Eclipse. Detalhes de seu processo de desenvolvimento s˜ao descritos na Sec¸˜ao 4.3. As Sec¸˜oes 5.1 e 5.2 retratam de forma minuciosa o procedimento adotado para

desenvolvimento do plug-in editor gr´afico da metodologia Prometheus AEOlus. Diferente dos demais plug-ins que comp˜oem esta ferramenta, o gr´afico n˜ao ´e da categoria PDE, explicada na Sec¸˜ao 4.2.3. Em virtude disso, o plug-in intitulado diagram possui uma dependˆencia ao plug-in wizard para ser inicializado.

O pacote wizard aglomera o plug-in respons´avel por fazer a junc¸˜ao entre os outros dois plug-ins que constituem a ferramenta desenvolvida. Este plug-in ´e do tipo PDE, consequentemente, pode iniciar os demais plug-ins, por ter sua pr´opria categoria no menu runtimeda Ide Eclipse. Esse ´e o plug-in que re´une as funcionalidades dos outros plug-ins descritos, por esse motivo possui dependˆencia aos demais. A peculiaridade desse plug- in em relac¸˜ao aos demais consiste na inexistˆencia de c´odigos-fontes, apenas pontos de extens˜ao adicionados no arquivo XML de configurac¸˜ao do plug-in, onde s˜ao informados quais plug-ins ocorre a relac¸˜ao de dependˆencia.

5.1

Metamodelos implementados para a Gerac¸˜ao do plug-in editor

gr´afico da metodologia Prometheus AEOlus

Esta sec¸˜ao tem por objetivo demonstrar os metamodelos desenvolvidos para regula- mentar cada diagrama implementado pelo plug-in deste trabalho. O desenvolvimento da ferramenta gr´afica que apoie a Metodologia Prometheus AEOlus n˜ao teve como objetivo validar a semˆantica desenvolvida por interm´edio da utilizac¸˜ao do plug-in gr´afico. Sendo assim, nesta primeira vers˜ao de desenvolvimento, o utilizador pode modelar os work pro- ducts da maneira que achar conveniente, apenas utilizando das notac¸˜oes presentes no diagrama, ficando sob sua responsabilidade a validac¸˜ao semˆantica dos mesmos.