Klimafremskrivninger basert på rapporten «Klima i Norge 2100»

Nesta etapa as sintaxes abstrata e concreta da DSL são modeladas a partir da lista de características do framework. Na sintaxe abstrata são definidos os elementos que representam as características do domínio do framework e armazenam as informações necessárias para a geração do código das aplicações que reutilizam o framework. Na Figura 4.4 é mostrado o metamodelo da DSL (sintaxe abstrata) do framework H. Cinco metaclasses desse metamodelo são auxiliares: 1) Application, que é o elemento raiz dos modelos criados com a DSL; 2) Feature, que é abstrata e deve ser estendida pelas metaclasses que representam as características do framework, pois fornece as informações comuns a todas as características (linha 0 do Quadro 4.2); 3) Attribute, que representa os atributos específicos das classes das aplicações modeladas com a DSL; 4) Operation, que representa as operações específicas das classes das aplicações modeladas com a DSL; e 5) Parameter, que representa os parâmetros de entrada das operações. As metaclasses B, C e D correspondem às características do domínio do framework H. As informações necessárias para a reutilização dessas características (linhas 1 a 3 do Quadro 4.2) são obtidas por meio dos relacionamentos existentes entre as suas metaclasses.

Figura 4.4. Metamodelo da DSL do framework H.

A sintaxe concreta é composta por elementos que permitem a visualização e a edição das informações definidas na sintaxe abstrata. A construção da sintaxe concreta de uma DSL é dependente da ferramenta adotada para esse fim. Por exemplo, o GMF (THE ECLIPSE FOUNDATION, 2013b; GRONBACK, 2009) utiliza três tipos de modelos para definir a sintaxe concreta das DSLs: Gmfgraph, Gmftool e Gmfmap.

No modelo Gmfgraph são definidos os componentes da notação gráfica da DSL que correspondem às características do framework e seus relacionamentos. Cada componente gráfico pode ser formado pela junção de vários componentes de forma aninhada. Por exemplo, na Figura 4.5 é mostrado que uma característica do framework é representada graficamente por um retângulo (Rounded Rectangle FeatureFigure) composto de outros retângulos que contêm os rótulos estereótipo (Rectangle FeatureStereoArea), do nome (Rectangle FeatureNameArea), dos atributos (Rectangle PropertiesCompartment) e das operações (Rectangle OperationsCompartment), respectivamente. Os relacionamentos de associação são representados por linhas contínuas (Polyline Connection AssociationLink).

Figura 4.5. Definição da notação gráfica da DSL do framework H.

No modelo Gmftool são definidos os itens de menu dos elementos e dos relacionamentos que podem ser utilizados nos modelos das aplicações. Na Figura 4.6 é

mostrado o modelo Gmftool do framework H, no qual são definidos os itens que compõem a caixa de menu da DSL desse framework. Foi criado um item para cada um dos elementos que fazem parte do modelo gráfico da DSL: atributo, operação, parâmetro, as características B, C e D e as ligações entre as características.

Figura 4.6. Definição dos itens do menu da DSL do framework H.

No modelo Gmfmap os elementos do metamodelo são combinados com os seus respectivos componentes da notação gráfica e itens de menu. Na Figura 4.7 é ilustrado um exemplo de modelo Gmfmap que combina as metaclasses e os relacionamentos do metamodelo (Figura 4.4) com a notação gráfica definida no modelo Gmfgraph (Figura 4.5) e com os itens de menu definidos no modelo Gmftool (Figura 4.6). Nesse modelo Gmfmap cada característica é definida com a inclusão de um Top Node Reference contendo um Node

Mapping. Os Node Mappings dos elementos internos às características, como atributos e

operações, são incluídos por meio de uma Child Reference e de um Compartment Mapping. De forma semelhante, o Node Mapping dos parâmetros é incluso nas operações. Por fim,

Feature Labels são acrescentados para permitir a visualização e a edição dos nomes e dos

tipos das características, dos atributos, das operações e dos parâmetros.

4.2.1.4 Construção da DSL

Normalmente, as ferramentas de desenvolvimento de DSL realizam a geração do código do editor da DSL a partir dos modelos. No GMF o código é gerado na forma de plug- ins para o Eclipse IDE a partir do metamodelo e dos modelos Gmfgraph, Gmftool e Gmfmap. Um mecanismo de validação também é criado a partir das propriedades e dos relacionamentos dos elementos definidos na sintaxe abstrata da DSL. Com isso, é possível verificar, por exemplo, se todas as características obrigatórias do framework foram incluídas no modelo de uma aplicação.

4.2.1.5 Construção do Gerador

Nesta etapa é realizada a construção do gerador de código das aplicações modeladas com a DSL do framework. Para garantir maior flexibilidade a esse gerador, a estrutura do código a ser gerado é definida por meio de templates implementados com o uso de uma linguagem de transformação. O gerador combina os seus templates com as informações provenientes dos modelos criados com a DSL para gerar o código-fonte das aplicações. Normalmente, é implementado um template específico para cada característica incluída na DSL do framework. Além disso, também é criado o template principal, que é responsável por invocar os templates específicos das características à medida que são encontrados elementos nos modelos das aplicações.

Figura 4.8. Exemplo de template principal para o framework mostrado na Figura 4.3. Na Figura 4.8 é apresentado o código JET do template principal do gerador da DSL do framework H. Nesse template foi implementado um laço (linhas 1 a 17) sobre todos os elementos dos modelos das aplicações, com o intuito de identificar as características às

quais eles correspondem (linhas 4, 8 e 12) e invocar o template específico de cada uma (linhas 5, 9 e 13).

Na Figura 4.9 é apresentado um exemplo de um template para geração das classes Java que reutilizam, por meio de herança (caixa branca), a classe D do framework H. Na linha 1 as partes fixas desse template são identificadas por palavras-chave da linguagem Java para a declaração da classe e a parte variável corresponde a uma tag JET que acessa o nome da classe ($feature) no modelo da aplicação. Nas linhas 2 a 5 é criado um laço que gera os atributos definidos para a classe no modelo da aplicação e nas linhas 6 a 9 é gerada a operação getBClass.

Figura 4.9. Trecho do template da característica D do framework H.

Além dos templates para geração das classes das aplicações, podem ser implementados templates para geração de testes que verificam as funções da aplicação implementadas com o reúso do framework. Além disso, também podem ser implementados templates que geram o script do banco de dados e copiam o código do framework, entre outros detalhes.

4.2.2 Engenharia da Aplicação

Na Figura 4.10 é mostrado o modelo da fase de Engenharia da Aplicação com reutilização do framework, com as seguintes etapas: 1) Modelagem da Aplicação; e 2) Construção da Aplicação.

4.2.2.1 Modelagem da Aplicação

Na etapa de Modelagem da Aplicação, a DSL do framework desenvolvida na fase de Engenharia da DSL é usada para a criação de um modelo considerando os requisitos da aplicação a ser gerada. Em vez de classes genéricas, os elementos dessa DSL correspondem às características do domínio do framework, facilitando o trabalho de associação desses elementos aos requisitos da aplicação. Para exemplificar esta etapa, na Figura 4.11 é mostrado o uso da DSL do framework H para modelar os requisitos de uma aplicação que o reutiliza. Os estereótipos dos elementos («B», «C», «D») indicam as características do framework utilizadas na aplicação. Por fim, as linhas entre os elementos são inseridas com base nos relacionamentos existentes no metamodelo da DSL (Figura 4.4). Por exemplo, a classe Dapp reconhece que Bapp é a classe da aplicação que estende a classe B do framework por meio da ligação entre as classes Dapp e Bapp.

Figura 4.11. Exemplo de utilização da DSL do framework H.

Uma das vantagens das DSLs sobre as linguagens de propósito geral é que as DSLs contém as regras específicas do seu domínio. Um mecanismo de validação dos modelos pode ser usado sobre os modelos das aplicações com o intuito de verificar a presença de características obrigatórias e relacionamentos inválidos. Na Figura 4.12.a é mostrado um modelo de uma aplicação sem a característica B, obrigatória de acordo com a DSL do framework H. Na Figura 4.12.b é mostrado o erro retornado pelo mecanismo de validação.

Figura 4.12. Mecanismo de validação das DSLs construídas com o GMF.

4.2.2.2 Construção da Aplicação

Nesta etapa o código-fonte da aplicação é gerado pelo gerador de código da DSL a partir do modelo dessa aplicação. Na Figura 4.13 é mostrado o código-fonte gerado a partir da combinação do template (Figura 4.9) com o modelo apresentado na Figura 4.11.

Figura 4.13. Código gerado para a classe Dapp.

Na etapa de Construção da Aplicação também podem ser executados testes para verificar se o código da aplicação atende aos requisitos solicitados. Caso tenham sido criados templates para a geração de classes de teste, esses podem ser executados tão logo o código seja gerado. Caso o código tenha sido modificado manualmente para atender algum requisito não previsto pelo framework, esses testes gerados podem ser utilizados como testes de regressão para verificar se a funcionalidade da aplicação apresenta alguma falha. Também podem ser manualmente implementados e executados testes que verificam a funcionalidade das operações adicionadas no modelo da aplicação.