Uma ferramenta de apoio à edição e validação de OVMs textuais para dar suporte ao processo de análise automática

(1)

Universidade Regional do Estado do Rio Grande do Sul –

UNIJUÍ

Cristiano Politowski

Uma ferramenta de apoio à edição e validação

de OVMs textuais para dar suporte ao processo

de análise automática

Santa Rosa, RS, Brasil

2014

(2)

Cristiano Politowski

Uma ferramenta de apoio à edição e validação de OVMs

textuais para dar suporte ao processo de análise

automática

Trabalho de Conclusão de Curso do curso de Ciência da Computação da Universidade Re-gional do Noroeste do Estado do Rio Grande do Sul.

Orientador: Dra. Fabrícia Roos Frantz

Santa Rosa, RS, Brasil

(3)

Este trabalho é dedicado à minha mãe. Essa sim, a melhor mãe do mundo.

(4)

Agradecimentos

A minha mãe Ivone, meu sogro Cláudio, minha sogra Marly e minha namorada Susan, por ter dado o suporte sem o qual nada disso seria possível.

Aos meus professores da graduação, pelo conhecimento passado e pela humildade demonstrada. Em especial aos professores Gerson Battisti pela oportunidade de trabalho logo no início do curso e ao professor Vinícius Maran pelos conselhos e camaradagem.

A minha orientadora, professora Fabrícia Roos Frantz, primeiro por aceitar me orientar no TCC e na bolsa de iniciação científica, e segundo pela paciência e atenção além dos valiosos conselhos que acredito serem mais importantes que qualquer conceito da computação.

(5)

“Wake early if you want another man’s life or land. No lamb for the lazy wolf. No battle’s won in bed. . (The Havamal - Old Norse poem from the Viking age)

(6)

Resumo

A Engenharia de Linha de Produtos de Software é um paradigma de desenvolvimento de software voltado ao reuso de artefatos comuns, sendo seu principal elemento a Variabilidade, definida por um Modelo de Variabilidade, o qual pode ser representado usando diferentes notações. O Modelo de Variabilidade Ortogonal é um desses modelos, cujo objetivo é representar a variabilidade da linha de produtos. O número de possíveis combinações entre elementos deste modelo cresce exponencialmente a medida que se acrescentam elementos, o que dificulta a análise manual dos mesmos. Para resolver este problema, o processo de análise automática de modelos de variabilidade tem o propósito de analisar esses modelos, proporcionando uma forma de gerenciar a Linha de Produtos de Software. Uma das ferramentas que implementa o processo de análise automática é FaMa-OVM, a qual recebe como parâmetro de entrada um modelo textual escrito com a linguagem OVM, juntamente com operações que serão interpretadas e processadas, resultando em Verdadeiro ou Falso, um Produto, vários Produtos, entre outros. Porém, caso haja erros nesse modelo de entrada, a ferramenta não fará a análise e o processamento resultará em erro.

Para resolver este problema, se faz necessário um editor com recursos de validação de sintaxe, e uma ferramenta que integre este editor com a ferramenta de análise FaMa-OVM. Sendo a Linguagem OVM de Domínio Específico, é pertinente o uso de Language Workbenches para construção do editor. Uma das mais conhecidas e completas Language Workbenches existentes na comunidade open source é a Xtext, possuindo, entre outras funcionalidades, suporte a criação da gramática com notação BNF, validação, formatação, syntax highlighting além dos recursos providos pela plataforma Eclipse, onde o Xtext funciona como plugin.

O trabalho desenvolveu-se em três etapas principais. Primeiramente, fez-se um estudo dos conceitos de Engenharia de Linha de Produtos de Software e Linguagens de Domínio Espe-cífico. A Segunda parte foi a fase de implementação da gramática utilizando a ferramenta escolhida e sua validação. A última etapa foi a criação de uma interface gráfica para uma melhor integração com a ferramenta de análise FaMa-OVM.

Palavras-chaves: Engenharia de Software. Engenharia de Linha da Produtos de Software.

Modelos de Variabilidade. Análise Automática de Modelos de Variabilidade. Linguagem de Domínio Específico. Gramática. Linguagem Textual. Modelo de Variabilidade Ortogonal. Xtext.

(7)

Abstract

The Software Product Line Engineering is a software development paradigm aimed to reuse of common artifacts, being the Variability its main element, defined by a Variability Model, which can be represented using different notations. The Orthogonal Variability Model is one of these models, which objective is to represent the Product Line. The size these models grow up exponentially as is added elements, making impossible the its manual analysis. To solve this problem, the Automatic Analysis of Variability Models has the intention analyze this models, creating a way to manage the Software Product Line. One of the tools that implement the Automatic Analysis process is FaMa-OVM, which receive as input parameter a textual model written with OVM language, together with operations that are interpreted and processed, resulting in outputs like True or False, a Product, many Products, among others. However, in case of errors on input model, the tool will not make the analysis and the process will result in error.

To solve this problem, is needed a editor with syntax validation resources, and a tool that integrate this editor with the FaMa-OVM analysis tool. Being OVM a Domain Specific Language, is pertinent the use of Language Workbenches to build the editor. One of the most known and complete Language Workbenches existing on open source community is the Xtext, having, among others features, support to grammar creation with BNF notation, validation, formatting, syntax highlighting besides of the resources provided by the Eclipse platform, where Xtext works as plug-in.

The paper was developed in three main stages. Firstly,was made a study of concepts of Software Product Line Engineering and Domain Specific Languages. The second stage was the stage of implementation of grammar using the tool chosen and its validation. The last phase was the creation of a Graphic Interface for a better integration with the analysis tool FaMa-OVM.

Key-words: Software Engineering. Software Product Line Engineering. Variability Models.

Automated Analisys of Variability Models. Domain Specific Language. Grammar. Textual Language. Orthogonal Variability Model. Xtext.

(8)

Lista de ilustrações

Figura 1 – Custo de desenvolvimento para Sistemas Únicos e Família de Sistemas. 16

Figura 2 – Time to market para Sistemas Únicos e Família de Sistemas. . . 17

Figura 3 – Framework para SPLE. . . 19

Figura 4 – Pirâmide da variabilidade. . . 20

Figura 5 – Exemplo de modelo de variabilidade usando Feature Model. . . 21

Figura 6 – Metamodelo da OVM em UML2. . . 22

Figura 7 – Notação gráfica da OVM. . . 23

Figura 8 – Exemplo de modelo de variabilidade usando OVM. . . 23

Figura 9 – Metamodelo baseado em atributos. . . 24

Figura 10 – Exemplo de atributos básicos (cinza) e derivados (branco). . . 25

Figura 11 – Restrições de Domínio em uma AOVM. . . 26

Figura 12 – Processo para a análise automática de Modelos de Variabilidade. . . 28

Figura 13 – Casos comuns de Características mortas em cinza. . . 29

Figura 14 – Exemplos de DSLs gráfica(a) e textual(b). . . 31

Figura 15 – Formalismo de Backus-Naur. . . 31

Figura 16 – Xtext workflow. . . 33

Figura 17 – Editor gerado pelo Xtext. . . 33

Figura 18 – Eclipse com Xtext. Novo projeto (esquerda). Estrutura de diretórios (direita). 36 Figura 19 – Editor com a Validação em funcionamento. . . 41

Figura 20 – Editor com detalhes de caracteres escondidos usados na formatação. . 43

Figura 21 – Editor com Sintax Highlighting (esquerda) e sem (direita). . . 45

Figura 22 – Tela de criação de novo projeto gerado pelo Assistente. . . 46

Figura 23 – Novo Projeto de Plugin no Eclipse. . . 50

Figura 24 – Arquivo MANIFEST.MF. . . 50

Figura 25 – Arquivo ovm.product. . . 52

Figura 26 – Plataformas do DeltaPack disponíveis. . . 53

Figura 27 – Logo do Editor. . . 53

Figura 28 – Question Dead Feature na Interface do FaMa-OVM. . . 55

Figura 29 – Question All Products na Interface do FaMa-OVM. . . 55

Figura 30 – Representação gráfica da Gramática - Model.. . . 61

Figura 31 – Representação gráfica da Gramática - Relationships.. . . 61

Figura 32 – Representação gráfica da Gramática - Constraints . . . 62

Figura 33 – Representação gráfica da Gramática - Atributos Globais . . . 62

Figura 34 – Representação gráfica da Gramática - Atributos. . . 63

Figura 35 – Modelo em OVM - Database Tools. . . 64

(9)

Lista de tabelas

Tabela 1 – Objetivos da Engenharia de Domínio e Aplicação. . . 19

Tabela 2 – Testes que esperam um resultado de "Aceito". . . 47

(10)

Lista de abreviaturas e siglas

SPLE do inglês Software Product Line Engineering. Em português Engenharia

de Linha de Produtos de Software.

SPL do inglês Software Product Line ou Linha de Produtos de Software.

VM do inglês Variability Model. Em português Modelos de Variabilidade.

FM do inglês Feature Model. Em português Modelo de Features.

OVM do inglês Orthogonal Variability Modelo. Em português Modelo de

Varia-bilidade Ortogonal.

AOVM do inglês Attribute-aware Orthogonal Variability Modelo. Em português

Modelo de Variabilidade Ortogonal orientado a Atributos.

AAVM do inglês Automated Analisys of Variability Models. Em português Análise

Automática de Modelos de Variabilidade.

DSL do inglês Domain Specific Language. Em português Linguagem de

Domí-nio Específico.

BNF do inglês Naur Formalism. Em português Formalismo de

Backus-Naur.

TLWB do inglês Textual Language Workbench. Em português Language

Work-bench Textual.

(11)

Sumário

Introdução. . . . 12

I

REFERENCIAIS TEÓRICOS

15

1 ENGENHARIA DE LINHA DE PRODUTOS DE SOFTWARE. . . . 16

1.1 Introdução a Linha de Produtos . . . 16

1.1.1 Exemplo de uma Linha de Produtos . . . 17

1.1.2 Processo de Desenvolvimento . . . 19

1.2 Modelos de Variabilidade . . . 20

1.3 Modelo de Variabilidade Ortogonal . . . 21

1.4 OVM Estendido . . . 23 1.5 Restrições de Domínio . . . 25 1.6 OVM Textual . . . 25 1.6.1 Relationships. . . 25 1.6.2 Attributes . . . 26 1.6.3 Global Attributes . . . 27 1.6.4 Constraints . . . 27

1.7 Análise Automática de Modelos de Variabilidade . . . 28

1.8 Resumo do Capítulo . . . 29

2 LINGUAGENS DE DOMÍNIO ESPECÍFICO . . . . 30

2.1 Introdução a Linguagens de Domínio Específico. . . 30

2.2 Gramática . . . 30 2.3 Languages Workbenches . . . 31 2.4 Xtext . . . 32 2.5 Resumo do Capítulo . . . 34

II

DESENVOLVIMENTO

35

3 CRIAÇÃO DO EDITOR . . . . 36

3.1 Estrutura do projeto no Xtext . . . 36

3.2 Definição da Gramática . . . 37

3.2.1 Relationships. . . 37

3.2.2 Constraints . . . 38

(12)

3.2.4 Global Attributes . . . 39

3.3 Funcionalidades do Editor . . . 40

3.3.1 Definindo a Validação do Editor . . . 40

3.3.1.1 Validação Automática . . . 40

3.3.1.2 Validação Customizada . . . 40

3.3.2 Definindo os Nomes de Elementos . . . 41

3.3.3 Definindo a Formatação do Código no Editor . . . 42

3.3.4 Definindo a Coloração de Sintaxe do Código no Editor . . . 43

3.3.5 Definindo o Assistente de Criação de Projetos do Editor . . . 45

3.4 Geração do plugin . . . 46

3.5 Validação do Editor . . . 47

4 FERRAMENTA DE APOIO A ANÁLISE AUTOMÁTICA . . . . 49

4.1 Produto Eclipse. . . 49

4.1.1 Projeto de Plugin . . . 49

4.1.2 Projeto de Feature . . . 49

4.1.3 Projeto de Feature para a Plataforma . . . 51

4.1.4 Arquivo ovm.product . . . 51

4.1.5 Exportar o Produto Eclipse . . . 51

4.1.6 Customização do Produto Eclipse . . . 52

4.2 Interface para a ferramenta FaMa-OVM . . . 54

Conclusão . . . . 57

Referências . . . . 58

APÊNDICES

60

APÊNDICE A – REPRESENTAÇÕES GRÁFICAS DA GRAMÁTICA DA LINGUAGEM OVM. . . . . 61

APÊNDICE B – MODELOS EM OVM . . . . 64

APÊNDICE C – INTERFACE DO FAMA-OVM: RESULTADO DA PRO-DUCTS . . . . 65

(13)

12

Introdução

O ser humano sempre tentou baratear o custo da produção de seus produtos ou bens para que estes fossem vendidos por um preço mais acessível, e assim conquistar o mercado e aumentar a margem de lucro. Porém, esses produtos eram feitos artesanalmente, resultando em baixa produção e poucos lucros. Além disso, o preço dos produtos era mais elevado devido ao tempo de produção.

Em 1913, Henry Ford com sua Linha de Produção1 revolucionou a maneira como

eram fabricados os carros e assim barateou os custos de produção e venda para o con-sumidor final. O problema, no entanto, era a falta de diversidade dos produtos devido a padronização da produção. Não demorou muito para que os clientes exigissem produtos customizados que fossem ao encontro de suas necessidades individuais.

A customização em massa (mass customization) veio para suprir essa demanda, proporcionando uma técnica de produção de larga escala de bens sob medida para

neces-sidades individuais (DAVIS,1989). Para consumidores, customização em massa significava

ter um produto individualizado, enquanto que para empresas significava alto investimento

tecnológico que agregava valor ao produto final (POHL; BöCKLE; LINDEN,2005).

Para suprir a necessidade de reduzir cada vez mais os custos de produção, empresas

adotaram plataformas comuns (common plataforms2) para diferentes tipos de produtos,

planejando previamente quais partes seriam usadas na construção de produtos posteriores. A junção de customização em massa e plataformas comuns deram origem ao paradigma de Engenharia de Linhas de Produtos de Software (Software Product Line

En-gineering - SPLE ) (POHL; BöCKLE; LINDEN,2005). Por um lado, desenvolver software

usando plataformas requer planejamento prévio com vistas ao reuso, ou seja, o desenvol-vimento de partes reusáveis e seu posterior reuso. Por outro lado, desenvolver software usando customização em massa requer gestão da variabilidade, ou seja, as características comuns e diferentes entre produtos de software específicos.

Para trabalhar com a SPLE é necessário gerir a variabilidade através de um modelo a parte. Existem diversas linguagens para modelar a variabilidade, dentre elas, a mais conhecida é a Feature Model. Cada linguagem possui características diferentes onde o domínio do negócio é que define qual usar. Neste trabalho, será usado o Modelo de

Variabilidade Ortogonal (Orthogonal Variability Model - OVM) (POHL; BöCKLE; LINDEN,

1 _{Henry Ford (30/Julho/1863 - 07/Abril/1947) foi um industrialista Americano, o fundador da Ford Motor}

Company, e responsável pelo desenvolvimento da técnica de Produção em Massa chamada Linha de Produção ou Linha de Montagem.

2 _{Plataforma é qualquer base tecnológica na qual outras tecnologias ou processos são construídos (}_POHL; BöCKLE; LINDEN,2005)

(14)

Introdução 13

2005).

OVM é uma linguagem de domínio específico, que possui notação gráfica e sintaxe

abstrata definidas em Pohl (POHL; BöCKLE; LINDEN,2005). Apesar da notação gráfica, a

ferramenta de análise automática existente na literatura, denominada FaMa-OVM, trabalha

com OVMs no formato textual (FRANTZ et al.,2012). Esta prática de usar a versão textual

dos modelos como entrada para ferramentas, seja em formato XML ou em formato específico,

é comum na literatura (FRANTZ et al.,2012;CLASSEN; BOUCHER; HEYMANS,2011;

MERKLE,2010).

A ferramenta FaMa-OVM utiliza como entrada um modelo OVM em formato textual,

o qual foi definido informalmente em Roos-Frantz (FRANTZ et al.,2012). FaMa-OVM não

oferece nenhum suporte a edição de OVMs, e se este modelo de entrada não estiver no formato correto, antes da fase da análise, a ferramenta acusará um erro no carregamento do modelo. A edição de modelos OVM textuais corretos, sem o auxílio de uma ferramenta de edição e correção automática de erros de sintaxe, é uma tarefa trabalhosa e muito propensa a erros.

Desenvolver uma ferramenta de edição de OVM que facilite a tarefa do usuário, isto é, com recurso de complementação de código (code completion), coloração de fonte (coloring), análise estática (static analysis), etc, não é uma tarefa trivial. Primeiro, é necessário definir a gramática da linguagem, logo, criar uma ferramenta de edição que seja capaz de fazer a análise sintática automaticamente, criar meios de validação semântica, criar uma formatação textual a fim de deixar o código uniforme e possibilitar recursos de coloração de sintaxe a fim de aumentar a legibilidade do código.

O objetivo deste trabalho é, além de criar uma gramática para a linguagem textual de OVM, criar uma ferramenta de edição que proporcione um ambiente completo para a criação e edição de modelos OVM corretos, sem erros de sintaxe, evitando que este problema seja postergado para a fase da Análise.

Este trabalho oferece uma ferramenta standalone de criação e edição de modelos OVM textuais, com recursos de validação e formatação. Esta ferramenta melhora a expe-riência de uso de modelos OVM e dá suporte ao processo de análise daquelas linhas de produtos onde modelos OVM documentam a variabilidade. A ferramenta foi testada em várias plataformas e seu funcionamento ocorreu sem problemas, ou seja, está pronta para ser usada.

Este trabalho está organizado da seguinte forma: no capítulo 1 fala-se sobre a

Linha de Produtos de Software, Modelo de Variabilidade Ortogonal e Análise Automática

desses modelos. No capítulo2fala-se sobre Linguagens de Domínio Específico, Gramática

e Language Workbenches. No capítulo3mostra-se todo o desenvolvimento do editor bem

(15)

Introdução 14

(16)

Parte I

(17)

16

1 Engenharia de Linha de Produtos de

Software

1.1 Introdução a Linha de Produtos

Linhas de Produto de Software (Software Product Line - SPL) é uma abordagem de desenvolvimento de software que propõe a derivação sistemática de produtos de software

a partir de um conjunto de componentes e artefatos comuns (CLEMENTS; NORTHROP,

2001). Em outras palavras SPL faz uso do reuso de software para construir sistemas com

menos esforço, desde que estes pertençam a uma mesma família, ou seja, que possuam pontos em comum.

Entre as principais vantagens da Engenharia de Linhas de Produto de Software (Software Product Line Engineering - SPLE) podem-se destacar o custo de desenvolvimento

(Figura1) e o time to market (Figura2). Além disso, outras motivações para a adoção deste

paradigma são: redução do esforço de manutenção; melhoria na gestão da evolução da tecnologia e da complexidade do software; e melhoria na estimativa de custos e benefícios

para os clientes (POHL; BöCKLE; LINDEN,2005).

Figura 1: Custo de desenvolvimento para Sistemas Únicos e Família de Sistemas.

Fonte: (POHL; BöCKLE; LINDEN,2005).

Na Figura 1, percebe-se que o custo inicial é maior para uma linha de sistemas.

Isto se deve a necessidade inicial de criação de componentes reusáveis e estruturação da

plataforma. Para Clements (CLEMENTS; NORTHROP,2001), o ponto de equilíbrio entre as

duas formas de desenvolvimento (break-even point) se dá entre 3 e 4 produtos da mesma linha, acima disso o custo de desenvolvimento de uma linha de produtos é menor do que

(18)

Capítulo 1. Engenharia de Linha de Produtos de Software 17

o de um único produto. Algo semelhante ocorre com relação ao ciclo de desenvolvimento,

como se pode ver na Figura 2. Ao princípio, um tempo maior é necessário para se construir

os artefatos comuns, depois, com o reuso destes artefatos, o ciclo de desenvolvimento se reduz.

Figura 2: Time to market para Sistemas Únicos e Família de Sistemas.

Há, no entanto, alguns pré-requisitos para a SPLE como, por exemplo, uma linhagem de programação orientada a objetos (encapsulamento), a possibilidade de trabalhar com componentes, técnicas de binding (late-binding), middleware, entre outras. Outro item

importante, é o conhecimento necessário sobre o domínio. De acordo com Pohl (POHL;

BöCKLE; LINDEN, 2005), somente pessoas que conhecem seus mercados e clientes podem identificar a comunalidade e variabilidade necessárias para se desenvolver uma linha de produtos com suas variabilidades.

1.1.1 Exemplo de uma Linha de Produtos

Um exemplo simples será usado para facilitar o entendimento de alguns conceitos. O exemplo em questão representa uma Linha de Produtos de aparelhos de telefonia móvel (celular).

Uma empresa decide implantar uma Linha de Produtos para a fabricação de celu-lares. Os Engenheiros decidem que todo celular fabricado deve ter, no mínimo, uma tela e um sistema para efetuar chamadas. Essa tela poderá ser básica, colorida ou de alta resolução. Alguns recursos opcionais foram considerados também, como GPS. No entanto, para que um GPS funcione, a tela não pode ser básica. Recursos de Mídia também podem ser adicionados ao aparelho, como MP3 player e câmera que, para tanto, necessita ter uma tela com alta resolução.

(19)

Aparelho celular:

- Fazer chamadas (pré-requisito); - Tela (pré-requisito, apenas um tipo);

- Básica; - Colorida; - Alta Resolução;

- GPS (não pode ser com tela básica); - Mídia (pode ter ambos);

- MP3;

- Câmera (deve ter tela de alta resolução).

Note que os itens fazer chamadas e tela são os aspectos comuns dos produtos, ou seja, todos terão essas características. Já os demais itens são as características variáveis dos produtos, ou seja, as diferenças que os tornarão únicos. Definir as características comuns (comunalidade) e as variáveis (variabilidade) é a chave para a Engenharia de Linha

de Produtos (POHL; BöCKLE; LINDEN,2005). Para se ter uma ideia da complexidade de

se gerenciar uma Linha de Produtos, vamos listar todos os produtos possíveis de serem desenvolvidos a partir das características e restrições descritas acima:

Celular,Fazer Chamadas,Tela,Básica; Celular,Fazer Chamadas,Tela,Básica,Mídia,MP3; Celular,Fazer Chamadas,Tela,Colorida; Celular,Fazer Chamadas,Tela,Colorida,GPS; Celular,Fazer Chamadas,Tela,Colorida,Mídia,MP3; Celular,Fazer Chamadas,Tela,Colorida,Mídia,MP3,GPS; Celular,Fazer Chamadas,Tela,Alta resolução;

Celular,Fazer Chamadas,Tela,Alta resolução,Mídia,MP3;

Celular,Fazer Chamadas,Tela,Alta resolução,Mídia,MP3,Câmera; Celular,Fazer Chamadas,Tela,Alta resolução,Mídia,Câmera; Celular,Fazer Chamadas,Tela,Alta resolução,GPS;

Celular,Fazer Chamadas,Tela,Alta resolução,Mídia,MP3,GPS; Celular,Fazer Chamadas,Tela,Alta resolução,Mídia,Câmera,GPS; Celular,Fazer Chamadas,Tela,Alta resolução,Mídia,Câmera,MP3,GPS.

Apesar do domínio apresentado ser pequeno, as variações geradas são muitas em comparação ao tamanho do problema. Não é difícil imaginar, a partir disso, que em um domínio mais realista, com muita variabilidade, o gerenciamento manual dos produtos se torna impraticável. A complexidade dessa variabilidade somente pode ser manuseada por meio de uma gestão da variabilidade e o primeiro passo para isso é ter uma notação comum (POHL; BöCKLE; LINDEN,2005).

(20)

1.1.2 Processo de Desenvolvimento

A SPLE é dividida em dois processos: “Engenharia de Domínio” e “Engenharia de

Aplicação”. Mostrados com detalhes na Tabela1. Alguns autores preferem dividir a SPLE

em mais um nível de Gerenciamento (Management) (CLEMENTS; KAZMAN; KLEIN,2001).

Tabela 1: Objetivos da Engenharia de Domínio e Aplicação.

Engenharia de Domínio Engenharia de Aplicação

Estabelecer uma plataforma de reuso. Derivar produtos da plataforma estabelecida. Definir a comunalidade e variabilidade da SPL. Efetuar tanto quanto possível o reuso de domain

assets ao definir e desenvolver uma aplicação da linha de produtos.

Definir o conjunto de aplicações para qual a SPL foi planejada (escopo).

Explorar a comunalidade e a variabilidade da SPL durante o desenvolvimento de um produto da linha de produtos.

Definir e construir artefatos reusáveis que cumprem a variabilidade desejada.

Documentar os application artefacts. Detalhar e refinar a variabilidade determinada por um

sub-processo anterior.

Ligar a variabilidade de acordo com as necessidades da aplicação.

Dar feedback sobre a viabilidade e realização da variabilidade requerida pelo processo anterior.

Estimar os diferentes impactos entre application e domain requirements na arquitetura, componentes e testes.

Fonte: Adaptado de (POHL; BöCKLE; LINDEN,2005).

Nessa premissa de divisão entre Domínio e Aplicação, Pohl (POHL; BöCKLE;

LIN-DEN,2005) mostra um framework, detalhado na Figura3. Para entender melhor a figura

primeiramente é necessário alguns conceitos:

Figura 3: Framework para SPLE.

(21)

• Artefatos de Desenvolvimento (Development Artefact): é a saída de um subprocesso da engenharia de domínio ou aplicação;

• Artefatos de Domínio (Domain Artefacts): são Artefatos de Desenvolvimento reusáveis criados no sub-processo da engenharia de domínio;

• Artefatos da Aplicação (Application Artefacts): são os Artefatos de Desenvolvimento de uma SPL específica.

Domain Artefacts ou Assets são armazenados em um repositório comum. São inter-relacionados por links rastreáveis que garantem a comunalidade e variabilidade entre todos os artefatos.

1.2 Modelos de Variabilidade

A variabilidade é o elemento principal da SPLE e o que a distingue de outras metodologias de desenvolvimento. A variabilidade é introduzida durante o subprocesso de Product Management e "carregada" para os subprocessos sequentes onde são refinadas e novas são adicionadas.

A Figura4mostra a pirâmide da variabilidade, a qual sofre um refinamento desde o

primeiro subprocesso até a fase de testes. A variabilidade externa é aquela visível ao cliente e transforma-se em variabilidade interna ao longo do processo de desenvolvimento. Não há a necessidade do cliente saber de pormenores do sistema e sim qual a característica oferecida. A quantidade de variabilidade para cada subprocesso é sempre aumentada.

Figura 4: Pirâmide da variabilidade.

Existem alguns modelos de gestão da variabilidade e entre eles o mais conhecido é o Modelo de Características (Feature Model). Um Feature Model representa as informações

(22)

de todos os possíveis produtos de uma SPL em termos de features e suas relações (CLEMENTS; KAZMAN; KLEIN,2001). O termo Feature Model foi cunhado por Kang no

relatório F.O.D.A. (Feature-oriented domain analysis) de 1990 (KANG et al.,1990).

A Figura 5 mostra o Feature Model que representa a variabilidade da linha de

produtos descrita anteriormente no exemplo da Seção1.1.1.

Figura 5: Exemplo de modelo de variabilidade usando Feature Model.

Fonte: (CLEMENTS; KAZMAN; KLEIN,2001).

Existem outras formas de modelar a variabilidade de uma SPL. O Modelo de Varia-bilidade Ortogonal (Orthogonal Variability Model - OVM) é uma delas. OVM é um modelo que define a variabilidade de uma SPL fornecendo uma visão transversal da variabilidade

através de todo os Artefatos de Desenvolvimento de Software (POHL; BöCKLE; LINDEN,

2005).

1.3 Modelo de Variabilidade Ortogonal

OVM é uma Linguagem de Domínio Específico definida pelo metamodelo mostrado

na Figura6. Os elementos centrais do metamodelo são Ponto de Variação e Variante.

Ponto de Variação é uma classe abstrata especializada em Interna (se refere a variabili-dade vista somente pelos desenvolvedores) e Externa (variabilivariabili-dade vista também pelos

clientes). A especialização é completa1e disjuntiva2. Dependência da Variabilidade

é a classe de associação entre a associação de Ponto de Variação e Variante. A multipli-cidade garante que: cada Variante pode ser associado a nenhuma ou várias Variantes. Cada Variante deve estar associado a um, e não mais que um, Ponto de Variação.

Dependência da Variabilidade é uma classe abstrata que define que uma Variante pode ser Opcional ou Obrigatória. Já a classe Escolha Alternativa é um conjunto de

1 _{Em UML2, Completa (Complete) são todas as subclasses já foram especificadas. Não existe mais a}

possibilidade de outra generalização.

2 _{Em UML2, Disjuntiva (Disjoint) são as Superclasses só podem se especializar em apenas uma subclasse.}

(23)

Figura 6: Metamodelo da OVM em UML2.

Fonte: Adaptado de (POHL; BöCKLE; LINDEN,2005).

Variantes relacionadas ao mesmo Ponto de Variação e define o alcance de Variantes Opcionais a serem selecionadas para este grupo, por exemplo: declarando as Variantes Opcionais mp3 e câmera e como Escolha Alternativa com min sendo 1 e max sendo 2, o Modelo de Variabilidade diz que pelo menos uma e no máximo duas das Variantes podem ser selecionadas.

Algumas restrições se fazem necessárias para Pontos de Variação e Variantes que necessitam ou excluem umas as outras. É o caso das três classes abstratas: Restrição de Dependência do Ponto de Variação, Restrição de Dependência da Variante e Restrição de Dependência do Ponto de Variação para Variante.

A classe Artefato de Desenvolvimento representa qualquer tipo de artefato de desenvolvimento. A associação entre Artefato de Desenvolvimento e Variante definem que: Um Artefato de Desenvolvimento pode estar relacionado a nenhuma ou várias Variantes. Uma Variante deve estar relacionada a pelo menos um, ou vários, Artefato de Desenvolvimento. Para casos onde um Artefato de Desenvolvimento deve repre-sentar um Ponto de Variação, ou seja, antecipar Variantes ainda não definidas, a cláu-sula representado por é usada, definindo que um Artefato de Desenvolvimento pode estar relacionado a nenhum ou vários Pontos de Variação, sendo o inverso verdadeiro.

(24)

A Figura7mostra a notação gráfica, ou seja, a sintaxe concreta da linguagem OVM,

proposta por Pohl (POHL; BöCKLE; LINDEN, 2005). Os elementos da sintaxe concreta

estão relacionados com os elementos descritos na sintaxe abstrata da linguagem, a qual é

definida pelo seu metamodelo (veja Figura6).

Figura 7: Notação gráfica da OVM.

Na Figura 8, novamente o exemplo apresentado na Seção 1.1.1 retorna, agora

utilizando da notação da OVM para modelar a variabilidade da Linha de Produtos de Celulares.

Figura 8: Exemplo de modelo de variabilidade usando OVM.

Fonte: Próprio autor.

1.4 OVM Estendido

De acordo com Roos-Frantz (ROOS-FRANTZ,2011), Atributos são propriedades

mensuráveis de um artefato, possuindo:

• name: denota o nome do Atributo que não precisa ser único pois diferentes artefatos podem ter diferentes atributos com o mesmo nome;

(25)

Figura 9: Metamodelo baseado em atributos.

Fonte: (ROOS-FRANTZ,2011).

• domain: denota o alcance de valores que o Atributo pode conter como Reals, Integers, e qualquer alcance (ex, [1..512]);

• value: denota o valor do atributo que irá depender do tipo concreto do atributo; • nullValue: denota o valor que deve ser tomado pelo atributo quando o Elemento da

Variabilidade, ao qual o atributo está relacionado, não for selecionado;

• unit: denota uma grandeza como metros, segundos, moeda e kilobytes, adotado como um padrão de medida.

Ainda, dependendo de como seus valores são calculados, os atributos podem ser distinguidos em dois tipos:

• BasicAttribute (atributo básico): o valor do Atributo não depende de outra medida, podendo ser simples ou uma coleção de valores (ex, [alto, médio, baixo]); • DerivedAttribute (atributo derivado): o valor do Atributo é determinado por

uma função sobre outros valores, incluindo valores de outros atributos do mesmo tipo.

A Figura10mostra um exemplo de um OVM estendido. Em cinza, o atributos básicos

com valores simples (single). Em branco, o atributo cost com o valor caracterizado por uma função de soma entre o custo da Variante Windows e Android. A representação nesse caso se dá com o nome do elemento seguido do atributo: <variability-element.attribute>. Pode, ainda, acontecer de um atributo não estar ligado a nenhum elemento do Modelo de Variabilidade, sendo assim considerado atributo global (global attribute).

(26)

Figura 10: Exemplo de atributos básicos (cinza) e derivados (branco).

Attribute-based Model V Windows VP OS name = cost domain = Real

value = Windows.cost + Android.cost nullValue = 0

unit = Monetary unit name = cost domain = Real value = 0 nullValue = 0 unit = Monetary unit

name = cost domain = Real value = 250 nullValue = 0 unit = Monetary unit

V Android [1,1] name = version domain = Real value = [5.0,6.0,7.0] nullValue = 1 unit = version number name = version domain = Real value = [1.6,2.2,2.3,3.0] nullValue = 1 unit = version number

1.5 Restrições de Domínio

Restrições de Domínio (Domain Constraints) são restrições nos Atributos que limitam a possibilidade de variações da OVM, evitando que se construa variações inadequadas (ROOS-FRANTZ, 2011). Essas restrições podem ser de limitações de recursos (ex, o consumo máximo permitido de memória) ou qualquer restrição de domínio (ex, todas as variações derivadas da linha de produtos de celulares devem garantir, pelo menos, 300

minutos de bateria em ligações). A Figura11mostra um exemplo com uma OVM que possui

três Restrições de Domínio.

1.6 OVM Textual

Na seção1.3, apresentou-se a notação gráfica para representar um OVM, porém, o

objetivo deste trabalho é a criação de um editor para a versão textual da linguagem OVM. O formato textual da DSL OVM consiste em quatro partes principais: Relationships, Attributes,

Global Attributes, e Constraints (ROOS-FRANTZ,2011):

1.6.1 Relationships

Em Relationships são especificadas as dependências da variabilidade entre Pontos de Variação e Variantes. Exemplos de sintaxes válidas para ambos os elementos são:

1 %Relationships

2 Vp1 : ;

3 [Vp2] : V1 [V2];

(27)

Figura 11: Restrições de Domínio em uma AOVM.

If Windows and Windows.version > 6

then Processor.frequency >= 1 and RAM.size >= 256 and FlashMemory.size >= 8

If Android then

Processor.frequency >= 0.2 and RAM.size >= 128 and FlashMemory.size >= 0.25 If GPS then Screen.resolution >= 320 x 480 V RAM VP Hardware V Flash Memory name = cost domain = Real value = RAM.cost + Processor.cost + FlashMemory.cost + GPS.cost nullValue = 0 unit = Monetary unit name = cost domain Real value = 50 nullValue = 0 unit = Monetary unit

name = cost domain = Real value = 60 nullValue = 0 unit = Monetary unit V Processor V GPS name = Cost domain = Real value = 120 nullValue = 0 unit = Monetary unit name = cost

domain = Real value = 80 nullValue = 0 unit = Monetary unit

Attribute based information Model (AM)

V Windows VP OS name = cost domain = Real value = Windows.cost + Android.cost nullValue = 0 unit = Monetary unit

name = cost domain = Real value = 0 nullValue = 0 unit = Monetary unit

name = cost domain = Real value = 250 nullValue = 0 unit = Monetary unit V Android [1,1] name = version domain = Real value = 7 nullValue = 1 unit = version number name = version domain = Real value = 2.3 nullValue = 1 unit = version number

name = TotalCost domain = Real value = OS.cost + Hardware.cost nullValue = 0 unit = Monetary unit name = size domain = Integer value = 1024 nullValue = 0 unit = MB name = size domain = Integer value = 8 nullValue = 0 unit = GB name = frequency domain = Real value = 1.2 nullValue = 0 unit = GHz V Screen VP Settings V JavaSupport [1,2] name = resolution domain = Real value = 480x320 nullValue = 0 unit = width × height requires

5 Vp3 : [2,1] {V1}; //erro de sintaxe

Os primeiros detalhes da linguagem que devem ser bem compreendidos são os Delimitadores de Elementos. Dois pontos (”:“) separa o Ponto de Variação da Variante enquanto que o ponto e vírgula (”;“) indica o fim do Ponto de Variação.

Na primeira linha, uma tag ”%Relationships“ é usada para indicar o começo dos elementos. Na linha 2, há um Ponto de Variação de nome ”VP1“ com nenhuma Variante, o que é permitido. Na linha 3, os colchetes de ”[Vp2]“ definem que este elemento é opcional, bem como a Variante ”[V2]“. Na linha 4, usa-se a cardinalidade ”[1,1]“ para restringir a quantidade de Variantes dentro de chaves (”{V3 V4}“). Ainda nessa linha, pode-se criar outras Variantes que não fazem parte da cardinalidade, como a ”V5“. Na linha 5, há vários erros, como o nome do Ponto de Variação ”Vp3“ que está duplicado, ocorrendo o mesmo com a Variante ”V1“, além de a cardinalidade mínima não ser respeitada pois só há uma Variante de um mínimo de 2.

1.6.2 Attributes

Em Attributes são especificados os Atributos Básicos e Atributos Derivados. Atributos são definidos na forma de <name>:<domain>,<value>;,<nullValue>; onde os termos são separados por vírgulas, e linhas terminadas com ponto e vírgula. Segue um exemplo da definição de Atributos:

1 %Attributes

(28)

3 V4.Accuracy : [4], 4;, INF;

4 VP3.Accuracy : [4,8], min(V3.Accuracy,V4.Accuracy);, INF;

5 V4.Memory : [2], 2;, 0;

6 V5.Memory : [2], 2;, 0;

7 VP3.Memory : Integer [1 to 512], V4.Memory + V5.Memory;, 0;

Os elementos delimitadores são o dois-pontos (”:“) que separa o nome do Atributo das demais propriedades. A vírgula (”,“) separa as propriedades do Atributo, ou seja, Domínio (domain), Valor (value), Valor Nulo (nullValue). O ponto-e-vírgula seguido de uma vírgula (”;,“) indica o fim da propriedade Valor (Value). E o ponto-e-vírgula sozinho indica do fim o Atributo.

Na primeira linha, uma tag ”%Attributes“ é usada para indicar o começo dos Atributos. O Nome do Atributo (name) é definido por um Elemento seguido de um nome que não precisa ser único. Como visto na linha 2 (”V3.Accuracy“) onde ”V3“ é o ele-mento já existente dentro de ”%Relationships“ seguido de um ponto (”.“) e um nome (”Accuracy“). O Domínio (domain) é definido por um valor entre colchetes como na linha 2 (”[8]“), uma coleção de valores separados por vírgulas como na linha 4 (”[4,8]“) ou um intervalo de valores como na linha 7 (”Integer [1 to 512]“). O Valor (value) é definido por um número qualquer como na linha 2 (”8“), por uma função min ou max como na linha 4 (”min(V3.Accuracy,V4.Accuracy)“) ou por uma equação (+, -, *, /) entre outros Attributos como na última linha 7 (”V4.Memory + V5.Memory“). O Valor Nulo (nullValue) pode ser infinito como na linha 2 (INF) ou um valor qualquer como nas três últimas linhas (”0“).

1.6.3 Global Attributes

Em Global Attributes são especificados os Atributos Globais. Possuem a mesma sintaxe que os Atributos com exceção do nome, que agora não leva o Elemento e o ponto, apenas um nome que, este sim, deve ser único. Um exemplo é mostrado abaixo:

1 %GlobalAttributes

2 TotalAccuracy : Integer [1 to 40] , VP12.Accuracy * VP13.AccuracyFactor ;, 0;

3 TotalMemory : Integer [1 to 512], VP2.Memory + VP4.Memory + VP5.Memory ;, 0;

1.6.4 Constraints

Em Constraints são especificadas as relações de exclusão e requisitos entre os Elementos descritos em Relationships. Existem três tipos de restrições entre Pontos de Variação e Variantes, vejamos no exemplo:

1 %Constraints

2 Vp1 REQUIRES Vp2; //VariationPoint REQUIRE ou EXCLUDES VariationPoint

3 V5 EXCLUDES Vp2; //Variant REQUIRE ou EXCLUDES VariationPoint

(29)

5 Vp3 EXCLUDES V1 ; //erro de sintaxe

A tag ”%Constraints“ indica o início da descrição das restrições. Cada Elemento da Variabilidade em Constraints é separado por uma tag que pode ser ”REQUIRES“ ou ”EXCLUDES“ e finalizado com um ponto-e-vírgula (”;“). Todo e qualquer Elemento pode se referir a um outro com exceção do Ponto de Variação que não pode ser excluir ou requerer uma Variante, como visto na última linha (”Vp3 EXCLUDES V1“).

1.7 Análise Automática de Modelos de Variabilidade

Analisar Modelos de Variabilidade é uma tarefa suscetível a erros, tediosa e inviável

de ser feita manualmente (BENAVIDES,2007). O framework descrito na Figura12mostra

uma visão de alto nível do processo de análise que pode ser definido como "extração de informações de modelos de variabilidade auxiliada por computador" (computer-aided extraction of information from variability models), e é separado por duas fases: Fase de Especificação, onde ocorre a criação do Modelo de Variabilidade servindo como entrada para a Fase de Análise, onde acontece a análise, composta por um Tradutor e um Solver ou Ferramenta.

Figura 12: Processo para a análise automática de Modelos de Variabilidade.

Fonte: (BENAVIDES; SEGURA; RUIZ-CORTÉS,2010).

Primeiramente, os parâmetros de entrada (Modelos de Variabilidade) são traduzidos em uma representação específica ou paradigma como lógica proposicional, regras de programação, lógica descritiva ou estruturas de dados ad-hoc. Então, off-the-shelf solvers ou algoritmos específicos são usados para analisar automaticamente a representação dos parâmetros de entrada e prover o resultado como uma saída.

Dado um modelo de variabilidade, quer-se automaticamente extrair informações

úteis deste modelo, como por exemplo encontrar características mortas (Figura13), filtrar o

(30)

Figura 13: Casos comuns de Características mortas em cinza.

Fonte: (BENAVIDES; SEGURA; RUIZ-CORTÉS,2010).

Na Figura13, três exemplos de Características mortas são mostrados. Uma

carac-terística está “morta” se ela não aparece em nenhum dos produtos da Linha de Produtos (BENAVIDES; SEGURA; RUIZ-CORTÉS,2010).

A ferramenta de análise não faz a validação do modelo de Variabilidade antes da entrada; apenas durante a análise os erros de sintaxe podem ser detectados, o que facilita a ocorrência de erros pois o modelos são construídos sem o auxílio de um editor. Funções como completamento automático, formatação automática, validação de sintaxe, destaque de sintaxe, entre outros, facilitam o trabalho do responsável pela modelagem e garante a corretura da mesma. Nesse sentido, para que isso seja possível, é necessário o estudo de outro tema: Linguagens de Domínio Específico.

1.8 Resumo do Capítulo

Neste capítulo vimos detalhes sobre o paradigma de Linhas de Produtos de Software que possui o Modelo de Variabilidade como elemento principal. Modelos estes que existem em diferentes notações sendo o Feature Model o mais conhecido. O Modelo de Variabilidade Ortogonal (OVM) é um desses modelos, possuindo uma notação gráfica e textual. Por ter o único objetivo de modelar a Variabilidade da Linha de Produtos de Software, OVM é considerada uma Linguagem de Domínio Específico.

(31)

30

2 Linguagens de Domínio Específico

2.1 Introdução a Linguagens de Domínio Específico

Segundo Fowler (FOWLER, 2010), Linguagem de Domínio Específico (Domain

Specific Language - DSL) é uma linguagem de programação de computadores de expressi-vidade limitada (suporta um conjunto mínimo de características não sendo possível construir um sistema inteiro com DSL) focada em um domínio particular.

DSLs são importantes por muitas razões, sendo aumento de produtividade para desenvolvedores e melhoria na comunicação com profissionais relacionados ao domínio os mais relevantes.

As DSLs podem ser divididas em três categorias principais:

a) DSL Interna: Uma DSL interna é um idioma particular escrito na linguagem

prin-cipal da aplicação (main language) com um estilo particular. Também conhecidas por Fluent Interfaces ou Embedded DSLs. Uma DSL interna é um código válido na linguagem principal. O framework de desenvolvimento rápido para web Ruby on Rails é caracterizado por ser uma coleção de DSLs. Muito disso se dá devido a linguagem Ruby ter recursos que facilitam a criação de DSLs.

b) DSL Externa: Uma DSL externa é uma linguagem separada da principal

normal-mente com sintaxe customizada. No entanto, XML é muito usado. Como visto

na Figura 14, no que se refere a sintaxe concreta, DSLs externas podem ser

separadas em textuais e gráficas (MERKLE,2010). Exemplos são Expressões

Regulares, SQL, arquivos de configuração XML, etc.

c) Language Workbench: Uma Language Workbench é uma IDE (Ambiente de

Desenvolvimento Integrado) especializada em construir DSLs determinando a estrutura da DSL e fornecendo um ambiente de edição para escrever scripts

DSL. Mais detalhes na Seção2.3.

2.2 Gramática

No contexto da DSL, a gramática é um conjunto de regras que descreve como o texto é transformado em uma Árvore de Sintaxe (Syntax Three). A Gramática define a Sintaxe

da linguagem mas não diz nada sobre a Semântica (FOWLER,2010). De acordo com a

Hierarquia de Chomsky, uma gramática pode ser de 4 tipos: Regular, Livre de Contexto, Sensível ao Contexto e Recursivamente Enumerável. As duas primeiras são largamente

(32)

Capítulo 2. Linguagens de Domínio Específico 31

Figura 14: Exemplos de DSLs gráfica(a) e textual(b).

Fonte: (MERKLE,2010).

usadas na descrição de linguagens de programação e na implementação de interpretadores e compiladores, por exemplo, linguagens Livres de Contexto são utilizadas na análise sintática enquanto que linguagens Regulares na análise léxica.

Normalmente uma Gramática é escrita em forma de Formalismo de Backus-Naur (Backus-Naur Formalism - BNF ). BNF formalmente define a sintaxe de uma linguagem de programação onde cada linha é uma regra de produção que declara um nome seguido de

um elemento legal da regra (FOWLER,2010). Uma especificação BNF é um conjunto de

regras de derivação, escritas como: <símbolo> ::= <expressão com símbolos>. BNF está definido na RFC 4234 (Augmented BNF for Syntax Specifications: ABNF ). Um exemplo

pode ser visto na Figura15.

Figura 15: Formalismo de Backus-Naur.

Fonte: (FOWLER,2010).

2.3 Languages Workbenches

Languages Workbenches podem ser divididas em Textual Language Workbench (TLWB), baseado no método scanner/parser, e Projectional Language Workbench (PLWB),

(33)

baseada em projeções:

• Textual Language Workbench (TLWB): há muitas ferramentas desse tipo onde a

maioria delas estão sobre o projeto Eclipse1₍_MERKLE_,₂₀₁₀_{). Exemplos open-sources}

são Xtext2_{, EMF}3_{, TEF (Textual Editing Framework)}4_{, TCS (Textual Concrete Syntax)}5_.

A maioria dessas ferramentas usa algum tipo de tecnologia de scanner/parser como

ANTLR6_{ou RunCC}7 _{em seu core.}

• Projectional Language Workbench (PLWB): a quantidade dessas ferramentas ainda

é pequena porém tende a crescer (MERKLE,2010). Exemplos são MPS8_{, The}

Intenti-onal Language Workbench9_{e Spoofax}10

2.4 Xtext

Xtext foi a ferramenta escolhida com base na análise de alguns artigos como (MERKLE, 2010) e (STOFFEL, 2010) e também por ser uma das mais conhecidas na comunidade de desenvolvedores além de proporcionar uma grande gama de recursos adicionais que não apenas a criação da gramática. Possui também bom suporte a integração com a linguagem Java, na qual a ferramenta de Análise foi criada.

Xtext é uma ferramenta open source mantida por um grupo de desenvolvedores da empresa Itemis que também oferece treinamento, consultoria e suporte. Atualmente o Xtext faz parte do projeto Eclipse TMF (Textual Modeling Framework ). O workflow do Xtext possibilita a criação da Sintaxe Concreta da linguagem através de uma gramática livre de contexto que incluem Regras Terminais (Terminal Rules) e Regras de Produção (Production Rules) enquanto que a Sintaxe Abstrata é misturada no arquivo ”.xtext“ e posteriormente gerada em Ecore Models. O Xtext não suporta recursão a esquerda em suas gramáticas. Um arquivo ”.mwe“ (Modeling Workflow Engine) descreve alguns recursos de construção

”build“ e geração de código. A Figura16 mostra uma gramática de exemplo na tela de

trabalho do Xtext.

A partir do arquivo ”.xtext“, Xtext gera outros recursos como um scanner baseado

na ferramenta ANTLR11 e suporte a um editor baseado no Eclipse. É neste editor que

1 _{http://www.eclipse.org/modeling} 2 _{http://www.eclipse.org/Xtext/} 3 _{http://www.emftext.org/index.php/EMFText} 4 _{http://www2.informatik.hu-berlin.de/sam/meta-tools/tef/index.html} 5 _{http://www.eclipse.org/gmt/tcs/} 6 _{http://www.antlr.org} 7 _{http://runcc.sourceforge.net/} 8 _{http://www.jetbrains.com/mps/index.html} 9 _{http://intentsoft.com/} 10 _{http://strategoxt.org/Spoofax} 11 _{http://www.antlr.org/}

(34)

Figura 16: Xtext workflow.

serão testadas as gramáticas; possui suporte a diversos recursos como: syntax highlighting, code completion, navigation and reference, folding, bracket matching, styled label providers,

incremental code-generation, e muitos outros. A Figura17demonstra a interface do editor.

Figura 17: Editor gerado pelo Xtext.

(35)

2.5 Resumo do Capítulo

Neste capítulo foram vistos pormenores das Linguagens de Domínio Específico e como as gramáticas, através de suas notações, as validam. Foram analisados os chamados Languages Workbenches, que são ambientes de desenvolvimento para a criação de Lingua-gens de Domínio Específico e de Propósito Geral. Através de pesquisas na internet e em artigos de comparação destas ferramentas, foi definido que Xtext, ferramenta open source que funciona juntamente com a plataforma Eclipse, será utilizada para a criação do editor.

(36)

Parte II

(37)

36

3 Criação do Editor

As seções a seguir abordarão a criação do editor utilizando a ferramenta de criação de linguagens Xtext. Cada aspecto importante da linguagem será tratado separadamente nas seções subsequentes. As representações gráficas da gramática textual estão no

ApêndiceA.

3.1 Estrutura do projeto no Xtext

O XTEXT é distribuído como um plugin da plataforma Eclipse, e pode ser instalado baixando a versão da IDE Eclipse com o plugin já instalado disponível no site ou instalando o plugin através do menu ”Help > Install new software“ adicionando a seguinte url:

http://download.eclipse.org/modeling/tmf/xtext/updates/composite/releases/1.

No menu, em New project, há um grupo de nome Xtext. Na tela seguinte, deve ser escolhido o ”nome do projeto“, o ”nome da linguagem“ e sua ”extensão“. Nessa ordem, foram escolhidos, ”gca.ovm“, ”gca.ovm.Ovm“ e ”ovm“.

Figura 18: Eclipse com Xtext. Novo projeto (esquerda). Estrutura de diretórios (direita).

A estrutura de diretórios do projeto é definida pelo Xtext, onde o arquivo principal é o Ovm.xtext. Nele será escrita toda a gramática utilizando o formalismo BNF estendido (E-BNF). Porém, ainda é necessário a execução do arquivo para a geração dos demais

1 _{Caso o editor criado com o Xtext seja devidamente exportado, as dependências, ou seja, o Xtext na sua}

(38)

Capítulo 3. Criação do Editor 37

artefatos com o comando Generate Xtext Artefacts. A Figura18ilustra a tela de criação

de um novo projeto e a estrutura de diretórios resultante.

3.2 Definição da Gramática

No Xtext a gramática é criada, basicamente, fazendo o uso de Parser Rules e Terminal Rules. A primeira é composta por uma sequência de Terminal Rules e não produz tokens terminais. A última faz parte da fase de análise léxica e representa um símbolo atômico. Terminal Rules também são conhecidas como Token Rules ou Lexer Rules e

possuem uma convenção informal de nomenclatura que devem ser Upper-case (XTEXT,

2013).

A gramática da linguagem OVM começa com a Parser Rule ”Model“ definindo toda a estrutura da linguagem. Na linha 1 damos o nome (ou identificamos) à Regra, ”Model“ neste caso. Nas linhas subsequentes é criado um rótulo, e apenas um, para cada bloco da linguagem. Cada um desses blocos pode conter N elementos, sejam eles quais forem. Este looping é caracterizado pela expressão ”+=“ e ”*“ que indica 0 (zero) ou N (vários) elementos. 1 Model: 2 relationships=Relationships (variationPoint+=VariationPoint)* 3 attributes=Attributes (attribute+=Attribute)* 4 globalAttributes=GlobalAttributes (globalAttribute+=GlobalAttribute)* 5 constraints=Constraints (constraint+=Constraint)*;

3.2.1 Relationships

Em Relationships são definidos os elementos principais da linguagem: Variation Point e Variant. O nome de ambos é definido pela variável ”name“ que recebe um ”QualifiedName“ que por usa vez é um tipo de dado criado a partir de uma Terminal Rule (linhas 12 e 13). O caractere ”|“ define um "ou" entre dois tipos de nomes, obrigatório e opcional. O nome do Variation Point é separado por dois-pontos (”:“). Na linha 5, define-se a propriedade opcional Cardinality (0 ou N), através do ponto-de-interrogação ("?"), que por sua vez é uma Parser Rule (linhas 8 e 9) a qual mostra o mínimo e máximo (”"["min=INT ","max=INT "]"“) além do looping de Variants dentro de chaves "{}". Variants também podem existir sem a Cardinalidade (linha 6). Por fim, um ponto-e-vírgula (”;“) define o fim do Variation Point. 1 Relationships: 2 "%Relationships"; 3 VariationPoint: 4 (name=QualifiedName | "[" name=QualifiedName "]") ":" 5 (cardinality=Cardinality)?

(39)

6 (variant+=Variant)*

7 ";";

8 Cardinality:

9 "[" min=INT "," max=INT "]" "{" (variant+=Variant)* "}";

10 Variant:

11 name=QualifiedName | "[" name=QualifiedName "]";

12 QualifiedName:

13 ID;

3.2.2 Constraints

Em Constraints são definidas as restrições entre os elementos. A Parser Rule Constraint faz uso de Cross Reference para fazer uma busca nos elementos já criados em Relationships. Cross Reference é um recurso único do Xtext para declarar links na gramática. A construção desses cross-links não é estabelecida durante a fase de parsing e

sim durante a linking phase (XTEXT,2013). A sintaxe para Cross-References é a segunite:

1 CrossReference : "[" type=TypeRef ("|" ^terminal=CrossReferenceableTerminal )? "]" ; A regra principal de Constraints pode ser vista da linha 4, onde um ”Element“, que pode ser Variant ou Variation Point (linhas 10 e 11), é chamado a partir de seu nome ”QualifiedName“. Importante notar que o caractere ”|“ nesse caso não significa "ou" (or ) e sim "por" (by ). Em seguida chama-se uma regra enum de nome ”Rule“ (linhas 12 e 13) que funciona como uma espécie de atalho para regras de tipos de dados com strings.

Enums são simples de usar e possuem boa validação (XTEXT,2013). A OVM estendida

suporta a propriedade ”IMPLIES“ em um Atributo comparando-o a um número inteiro (linha 5).

1 Constraints:

2 "%Constraints";

3 Constraint:

4 c1=[Element|QualifiedName] (rule=Rule c2=[Element|QualifiedName] | "IMPLIES"

(attribute=[Att|QualifiedNameAtt])

5 comparison=Comparison num=INT) ";";

6 Att:

7 Attribute | GlobalAttribute;

8 enum Comparison:

9 G=">" | L="<" | GE=">=" | LE="<=" | E="==" | NE="!=";

10 Element:

11 Variant | VariationPoint;

12 enum Rule:

(40)

3.2.3 Attributes

Em Attibutes o nome é uma combinação de um Elemento com um Nome como em ”AttName“. O ”Domain“ pode conter um número inteiro ou uma coleção dos mesmos, fechados por colchetes ou um range de números tipados (linhas 9 e 10). Já ”Value“ pode ser um simples número inteiro, a referência de outro atributo, uma equação ou uma função. Equações são operações entre números e/ou referências de atributos, ambos podem ser encadeados (linhas 17 a 22). Na linha 16, o caractere ”+“ diz que no mínimo um atributo deve ser usado. Duas funções podem ser usadas (min e max ) que são executadas em N atributos (linhas 15 e 16). Por fim, ”NullValue“ pode conter um número inteiro ou duas strings que representam valores infinitos (linhas 13 e 14).

1 Attributes:

2 "%Attributes";

3 Attribute:

4 name=AttName ":" domain=Domain "," value=Value ";," nullValue=NullValue ";";

5 AttName:

6 element=[Element|QualifiedName] "." attributeName=QualifiedName;

7 QualifiedNameAtt:

8 ID ("." ID)*;

9 Domain:

10 number="[" INT ("," INT)* "]" | range="Integer" "[" INT "to" INT "]";

11 Value:

12 number=INT | attribute=[Attribute|QualifiedNameAtt] | equation=Equation | function=Function;

13 NullValue:

14 INT | "INF" | "MINF";

15 Function:

16 "max(" a1=[Attribute|QualifiedNameAtt] ("," a2+=[Attribute|QualifiedNameAtt])+

")" | "min("a1=[Attribute|QualifiedNameAtt] (","

a3+=[Attribute|QualifiedNameAtt])+ ")";

17 Equation:

18 (n=INT | a=[Attribute|QualifiedNameAtt]) (el2+=El2)+;

19 El2:

20 (o=Operator) (n=INT | a=[Attribute|QualifiedNameAtt]);

21 enum Operator:

22 SUM="+" | SUBTRACTION="-" | DIVISION="/" | MULTIPLICATION="*";

3.2.4 Global Attributes

Em GlobalAttributes a gramática é semelhante a Attributes, com uma única exce-ção no nome, que agora é uma simples string, fazendo o uso da mesma regra usada anteriormente em Relationships.

1 GlobalAttributes:

(41)

3 GlobalAttribute:

4 name=QualifiedName ":" domain=Domain "," value=Value ";," nullValue=NullValue

";";

3.3 Funcionalidades do Editor

3.3.1 Definindo a Validação do Editor

Um dos aspectos mais interessantes ao se desenvolver uma linguagem é fazer uso da Validação. A Validação provê feedback para os usuários da linguagem conforme eles

vão digitando (XTEXT,2013). O Xtext possibilita fazer o uso de três tipos de Validação:

Validação Automática, Validação Customizada e Validação Manual. A linguagem OVM faz uso de dois deles, detalhados a seguir.

3.3.1.1 Validação Automática

Esse tipo de validação está intrínseca na criação da gramática, ou seja, o Xtext automaticamente faz algumas análises para deixar o documento válido, como Syntactical

Validation, Cross-link Validation e Concrete Syntax Validation (XTEXT,2013).

3.3.1.2 Validação Customizada

Além das validações automáticas, pode-se criar métodos específicos para validar o modelo a ser criado. Nesse deve-se estender a classe ”AbstractOvmValidator“ e anotar os métodos com ”@Check“.

1 @Check

2 def checkCardinality(Cardinality cardinality) {

3 if (cardinality.variant.size < cardinality.min) {

4 error("Cardinality MIN not respected.", OvmPackage.Literals.CARDINALITY__MIN);

5 } }

6 @Check

7 def checkVariationPointToVariantConstraint(Constraint constraint) {

8 var listaRules = (constraint.eContainer() as Model).constraint;

9 if (listaRules.size > 0) {

10 for (r_aux : listaRules) {

11 if (constraint.c1 instanceof VariationPoint && constraint.c2 instanceof

Variant) {

12 error("Variation Point cannot REQUIRES or EXCLUDES a Variant.", OvmPackage.Literals.CONSTRAINT__C2);

13 return;

14 } else if (constraint.c1.equals(constraint.c2)) {

15 error("A Element cannot REQUIRES or EXCLUDES itself.", OvmPackage.Literals.CONSTRAINT__C2);

(42)

16 } } } }

No código acima, o método ”checkCardinality“ faz a checagem da cardinalidade mínima de um Ponto de Variação, contando as Variantes nele presentes e mostrando um erro se necessário. Já o método seguinte ”checkVariationPointToVariantConstraint“ checa, em Constraints, se um Ponto de Variação aponta para uma Variante, o que não é permitido segundo o metamodelo da OVM. Checa também se o Elemento aponta para ele mesmo. Em todos os casos, além da mensagem de erro, a propriedade que contém o erro é sublinhada. A classe completa está no link http://www.gca.unijui.edu.br//Download.ashx?id=468.

Na Figura19é mostrado o editor e a validação em funcionamento.

Figura 19: Editor com a Validação em funcionamento.

Há também algumas validações já prontas para uso, que podem ser ativadas no ar-quivo ”GenerateOvm.mwe2“. A linguagem OVM faz uso do método ”NamesAreUniqueValidator“ que não permite dois elementos de mesmo tipo com o mesmo nome.

1 // Xtend-based API for validation

2 fragment = validation.ValidatorFragment auto-inject {

3 // composedCheck = "org.eclipse.xtext.validation.ImportUriValidator"

4 composedCheck = "org.eclipse.xtext.validation.NamesAreUniqueValidator"

5 }

3.3.2 Definindo os Nomes de Elementos

Para lidar com nomes, o Xtext, a partir da versão 2.0, introduziu um novo objeto: QualifiedName. Utilizando o método IQualifiedNameConverter é possível converter nomes

para um representação específica (XTEXT,2013). Esse é mais um recurso essencial e sem

(43)

O primeiro problema ocorreu na criação das Constraints e suas referências cruzadas. O nome de uma Variant vinha precedido de seu elemento pai, ou seja, do Variation Point, da seguinte forma:

1 %Constraints

2 Screen.Basic EXCLUDES Utility.Gps;

3 Media.Camera REQUIRES Screen.High;

Depois de descoberto que o método ”DefaultDeclarativeQualifiedNameProvider“ poderia ser estendido, contornar essa situação ficou fácil. Criou-se um arquivo ”OvmQNP.java“ estendendo a classe já mencionada retornando o nome da Variante apenas com seu ”v.getName“ (linhas 11 a 13).

1 QualifiedName qualifiedName(Variant v) {

2 return QualifiedName.create(v.getName()); }

O outro problema foi na identificação dos atributos, pois possuem nomes compostos de uma referência cruzada, um ponto e um nome. Para resolver esta questão foi preciso fazer uma busca nos nós da árvore de parseamento pelos nomes dos atributos e depois retornar o nome correto (”a.getName().getAttributeName()“).

1 QualifiedName qualifiedName(Attribute a) {

2 if (a.getName() != null) {

3 List<INode> nodes = NodeModelUtils.findNodesForFeature(a.getName(), OvmPackage.Literals.ATT_NAME__ELEMENT); 4 if (nodes.size() > 0) { 5 return QualifiedName.create(nodes.get(0).getText().trim(), a.getName().getAttributeName()); 6 } 7 } 8 return null; }

Após a criação da classe é preciso registra-la como um novo componente para ser usada em tempo de execução. Isto é feito na classe ”OvmRuntimeModule“, como visto no código abaixo.

1 @Override

2 public Class<? extends IQualifiedNameProvider> bindIQualifiedNameProvider() {

3 return OvmQNP.class;

4 }

3.3.3 Definindo a Formatação do Código no Editor

A formatação ou indentação do código é de vital importância para uma leitura e escrita eficaz e ágil. No Xtext, a formatação do código pode ser customizada estendendo o arquivo ”AbstractDeclarativeFormatter“. Um formatter insere, remove ou modifica

(44)

tokens escondidos, ou seja, espaços em branco, comentarios e quebras de linha. É invocado na fase de serialização ou quando o usuário aciona a formatação no editor (por exemplo,

apertando CTRL + SHIFT + F) (XTEXT,2013). No trecho de código abaixo, são inseridas

quebras de linha (”setLinewrap“) e retirados espaços em brancos (”setNoSpace“) dos ele-mentos. A classe completa está no link http://www.gca.unijui.edu.br//Download.ashx?id=468.

A Figura20mostra os caracteres de escape definidos na classe.

1 //tags

2 c.setLinewrap(1).after(variationPointRule)

3 //variation point

4 for (Keyword comma : variationPointAccess.findKeywords(",")) {

5 c.setNoSpace().around(comma); }

6 //attributes

7 for (pair : functionAccess.findKeywordPairs("max(", ")")) {

8 c.setNoSpace().after(pair.getFirst());

9 c.setNoSpace().before(pair.getSecond()); }

10 //GlobalAttributes

11 for (Keyword dot : globalAttributeAccess.findKeywords(".")) {

12 c.setNoSpace().around(dot)}

Figura 20: Editor com detalhes de caracteres escondidos usados na formatação.

3.3.4 Definindo a Coloração de Sintaxe do Código no Editor

Outro recurso que ajuda na legibilidade do código é o de Coloração de Sintaxe ou Syntax Coloring. Com ele é possível usar diferentes cores e fontes de acordo com o significado das diferentes partes da entrada. Essa diferenciação não interfere na semântica do texto mas ajuda na compreensão e identificação de erros. Há duas formas de se colorir

a sintaxe: Lexical Highlighting e Semantic Highlighting (XTEXT,2013). Este último foi usado

na linguagem OVM.

Para destacar o texto baseado no significado dos elementos são necessários al-guns passos. Primeiramente a criação do arquivo de configuração onde as cores

(45)

se-Capítulo 3. Criação do Editor 44

rão escolhidas e atribuídas à uma variável de cada elemento. Essa classe, chamada de “OvmHighlightingConfiguration”, deve implementar a classe

“IHighlightingConfiguration”, sobrescrevendo o médoto ”configure“. No trecho de código que segue abaixo, foram criadas variáveis finais para cada elemento a ser destacado e um método ”addType“ que será chamado na função sobrescrita. A classe completa está disponível através do link http://www.gca.unijui.edu.br//Download.ashx?id=468.

1 public static final String VARIATION_POINT = "Variation Point";

2 public static final String VARIANT = "Variant";

3 public void configure(IHighlightingConfigurationAcceptor acceptor) {

4 addType(acceptor, VARIATION_POINT, 178, 0, 108, NORMAL);

5 addType(acceptor, VARIANT, 0, 127, 50, NORMAL);

6 public void addType(IHighlightingConfigurationAcceptor acceptor, String s, int r,

int g, int b, int style) {

7 TextStyle textStyle = new TextStyle();

8 textStyle.setBackgroundColor(new RGB(255, 255, 255));

9 textStyle.setColor(new RGB(r, g, b));

10 textStyle.setStyle(style);

11 acceptor.acceptDefaultHighlighting(s, s, textStyle); }

A segunda parte necessária é a criação da classe que vai percorrer a Árvore de Sintaxe identificando os elementos e colorindo-os. Essa classe foi chamada de

“OvmHighlightingCalculator” e implementa a classe

“ISemanticHighlightingCalculator” sobrescrevendo o método

“provideHighlightingFor”. Os elementos que estão em destaque na linguagem são Ponto de Variação, Variante, Tags de separação, Referências cruzadas e Comentários.

Interessante é perceber o funcionamento do código, que passa por toda a Árvore de Sintaxe usando um "while" procurando os determinados tipos de elementos e aplicando as cores através do método ”setStyles“. Os três últimos médotos, ”skipWhiteSpace“, ”skipWhiteSpaceBackwards“ e ”processHiddenNode“, foram criados para resolver os pro-blemas dos tokens invisíveis, que poderiam ser destacados juntamente com o texto. A classe completa está disponível através do link http://www.gca.unijui.edu.br//Download.ashx?id=468.

1 public void provideHighlightingFor(XtextResource resource,

IHighlightedPositionAcceptor acceptor) {

2 if (resource == null || resource.getParseResult() == null)

3 return;

4 INode root = resource.getParseResult().getRootNode();

5 BidiTreeIterator<INode> it = root.getAsTreeIterable().iterator();

6 while (it.hasNext()) {

7 INode node = it.next();

8 if (!(node instanceof CompositeNodeWithSemanticElement)) {

9 // VARIATION POINT

10 if (node instanceof CompositeNode && node.getGrammarElement() instanceof