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
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 Regional do Noroeste do Estado do Rio Grande
do Sul.
Orientador: Dra. Fabrícia Roos Frantz
Santa Rosa, RS, Brasil
2014
Este trabalho é dedicado à minha mãe.
Essa sim, a melhor mãe do mundo.
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.
“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)
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 FaMaOVM. 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 Especí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.
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.
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
Figura 36 – Modelo em OVM - Billing. . . . . . . . . . . . . . . . . . . . . . . . . . .
64
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
Tabela 3 – Testes que esperam um resultado de "Erro". . . . . . . . . . . . . . . .
48
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 Variabilidade 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 Backus-Naur Formalism. Em português Formalismo de BackusNaur.
TLWB
do inglês Textual Language Workbench. Em português Language Workbench Textual.
PLWB
do inglês Projectional Language Workbench.
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
3.2.3
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
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
3.6
Resumo do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
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
4.3
Resumo do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
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 PRODUCTS . . . . . . . . . . . . . . . . . . . . . . . . . .
APÊNDICE D – MODELO OVM DE UMA LPS MOBILE
. . . . . . . .
65
66
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 consumidor 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 necessidades 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 Engineering - SPLE) (POHL; BöCKLE; LINDEN, 2005). Por um lado, desenvolver software
usando plataformas requer planejamento prévio com vistas ao reuso, ou seja, o desenvolvimento 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
2
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.
Plataforma é qualquer base tecnológica na qual outras tecnologias ou processos são construídos (POHL;
BöCKLE; LINDEN, 2005)
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 experiê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ítulo 2 fala-se sobre Linguagens de Domínio Específico, Gramática
e Language Workbenches. No capítulo 3 mostra-se todo o desenvolvimento do editor bem
como os testes realizados. No capítulo 4 fala-se sobre a exportação do editor e a criação
Introdução
da Interface do framework FaMa-OVM.
14
Parte I
Referenciais Teóricos
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
(Figura 1) e o time to market (Figura 2). 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
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.
Fonte: (POHL; BöCKLE; LINDEN, 2005).
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 celulares. 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.
Para melhor compreensão, vamos descrever esse exemplo em uma lista:
Capítulo 1. Engenharia de Linha de Produtos de Software
18
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
Celular,Fazer
Celular,Fazer
Celular,Fazer
Celular,Fazer
Celular,Fazer
Celular,Fazer
Celular,Fazer
Celular,Fazer
Celular,Fazer
Celular,Fazer
Celular,Fazer
Celular,Fazer
Celular,Fazer
Chamadas,Tela,Básica;
Chamadas,Tela,Básica,Mídia,MP3;
Chamadas,Tela,Colorida;
Chamadas,Tela,Colorida,GPS;
Chamadas,Tela,Colorida,Mídia,MP3;
Chamadas,Tela,Colorida,Mídia,MP3,GPS;
Chamadas,Tela,Alta resolução;
Chamadas,Tela,Alta resolução,Mídia,MP3;
Chamadas,Tela,Alta resolução,Mídia,MP3,Câmera;
Chamadas,Tela,Alta resolução,Mídia,Câmera;
Chamadas,Tela,Alta resolução,GPS;
Chamadas,Tela,Alta resolução,Mídia,MP3,GPS;
Chamadas,Tela,Alta resolução,Mídia,Câmera,GPS;
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).
Capítulo 1. Engenharia de Linha de Produtos de Software
1.1.2
19
Processo de Desenvolvimento
A SPLE é dividida em dois processos: “Engenharia de Domínio” e “Engenharia de
Aplicação”. Mostrados com detalhes na Tabela 1. 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.
Definir a comunalidade e variabilidade da SPL.
Derivar produtos da plataforma estabelecida.
Efetuar tanto quanto possível o reuso de domain
assets ao definir e desenvolver uma aplicação da
linha de produtos.
Explorar a comunalidade e a variabilidade da SPL
durante o desenvolvimento de um produto da linha
de produtos.
Documentar os application artefacts.
Definir o conjunto de aplicações para qual a SPL foi
planejada (escopo).
Definir e construir artefatos reusáveis que cumprem
a variabilidade desejada.
Detalhar e refinar a variabilidade determinada por um
sub-processo anterior.
Dar feedback sobre a viabilidade e realização da
variabilidade requerida pelo processo anterior.
Ligar a variabilidade de acordo com as necessidades
da aplicação.
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; LINDEN, 2005) mostra um framework, detalhado na Figura 3. Para entender melhor a figura
primeiramente é necessário alguns conceitos:
Figura 3: Framework para SPLE.
Fonte: (POHL; BöCKLE; LINDEN, 2005).
Capítulo 1. Engenharia de Linha de Produtos de Software
20
• 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 Figura 4 mostra 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.
Fonte: (POHL; BöCKLE; LINDEN, 2005).
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
Capítulo 1. Engenharia de Linha de Produtos de Software
21
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ção 1.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 Variabilidade 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 Figura 6. 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 variabilidade vista somente pelos desenvolvedores) e Externa (variabilidade vista também pelos
clientes). A especialização é completa1 e disjuntiva2 . Dependência da Variabilidade
é a classe de associação entre a associação de Ponto de Variação e Variante. A multiplicidade 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
2
Em UML2, Completa (Complete) são todas as subclasses já foram especificadas. Não existe mais a
possibilidade de outra generalização.
Em UML2, Disjuntiva (Disjoint) são as Superclasses só podem se especializar em apenas uma subclasse.
É o oposto de Sobreposição (overlapping).
Capítulo 1. Engenharia de Linha de Produtos de Software
22
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 representar um Ponto de Variação, ou seja, antecipar Variantes ainda não definidas, a cláusula 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.
Capítulo 1. Engenharia de Linha de Produtos de Software
23
A Figura 7 mostra 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 Figura 6).
Figura 7: Notação gráfica da OVM.
Fonte: (POHL; BöCKLE; LINDEN, 2005).
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;
Capítulo 1. Engenharia de Linha de Produtos de Software
24
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 Figura 10 mostra 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).
Capítulo 1. Engenharia de Linha de Produtos de Software
25
Figura 10: Exemplo de atributos básicos (cinza) e derivados (branco).
Attribute-based Model
name = cost
domain = Real
value = Windows.cost + Android.cost
nullValue = 0
unit = Monetary unit
VP
OS
[1,1]
V
Windows
V
name = cost
domain = Real
value = 0
nullValue = 0
unit = Monetary unit
Android
name = cost
domain = Real
value = 250
nullValue = 0
unit = Monetary unit
name = version
domain = Real
value = [1.6,2.2,2.3,3.0]
nullValue = 1
unit = version number
name = version
domain = Real
value = [5.0,6.0,7.0]
nullValue = 1
unit = version number
Fonte: (ROOS-FRANTZ, 2011).
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 Figura 11 mostra um exemplo com uma OVM que possui
três Restrições de Domínio.
1.6
OVM Textual
Na seção 1.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
2
3
4
%Relationships
Vp1
: ;
[Vp2] : V1 [V2];
Vp3
: [1,1] {V3 V4} V5;
Capítulo 1. Engenharia de Linha de Produtos de Software
26
Figura 11: Restrições de Domínio em uma AOVM.
Attribute based information Model (AM)
name = cost
domain = Real
value = Windows.cost + Android.cost
nullValue = 0
unit = Monetary unit
VP
OS
If Windows and Windows.version > 6
then Processor.frequency >= 1 and RAM.size >= 256 and
FlashMemory.size >= 8
[1,1]
V
V
Windows
Android
V
V
RAM
GPS
V
Processor
name = version
domain = Real
value = 2.3
nullValue = 1
unit = version number
name = cost
domain = Real
value = 250
nullValue = 0
unit = Monetary unit
name = version
domain = Real
value = 7
nullValue = 1
unit = version number
name = cost
domain = Real
value = RAM.cost + Processor.cost +
FlashMemory.cost + GPS.cost
nullValue = 0
unit = Monetary unit
VP
Hardware
V
name = cost
domain = Real
value = 0
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
name = size
domain = Integer
value = 8
nullValue = 0
unit = GB
name = Cost
domain = Real
value = 120
nullValue = 0
unit = Monetary unit
name = frequency
domain = Real
value = 1.2
nullValue = 0
unit = GHz
Flash
Memory
requires
name = cost
domain = Real
value = 80
nullValue = 0
unit = Monetary unit
VP
name = size
domain = Integer
value = 1024
nullValue = 0
unit = MB
Settings
[1,2]
V
JavaSupport
V
Screen
If Android then
Processor.frequency >= 0.2 and RAM.size >= 128 and
FlashMemory.size >= 0.25
name = resolution
domain = Real
value = 480x320
nullValue = 0
unit = width × height
name = TotalCost
domain = Real
value = OS.cost + Hardware.cost
nullValue = 0
unit = Monetary unit
If GPS then
Screen.resolution >= 320 x 480
Fonte: (ROOS-FRANTZ, 2011).
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
2
%Attributes
V3.Accuracy
: [8], 8;, INF;
Capítulo 1. Engenharia de Linha de Produtos de Software
3
4
5
6
7
V4.Accuracy
VP3.Accuracy
V4.Memory
V5.Memory
VP3.Memory
:
:
:
:
:
27
[4], 4;, INF;
[4,8], min(V3.Accuracy,V4.Accuracy);, INF;
[2], 2;, 0;
[2], 2;, 0;
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 elemento 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
2
3
%GlobalAttributes
TotalAccuracy : Integer [1 to 40] , VP12.Accuracy * VP13.AccuracyFactor ;, 0;
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
2
3
4
%Constraints
Vp1 REQUIRES Vp2;
V5 EXCLUDES Vp2;
V2 REQUIRES V4 ;
//VariationPoint REQUIRE ou EXCLUDES VariationPoint
//Variant REQUIRE ou EXCLUDES VariationPoint
//Variant REQUIRE ou EXCLUDES Variant
Capítulo 1. Engenharia de Linha de Produtos de Software
5
Vp3 EXCLUDES V1 ;
28
//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 Figura 12 mostra
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 (Figura 13), filtrar o
modelo, obter todos os produtos válidos, entre outras.
Capítulo 1. Engenharia de Linha de Produtos de Software
29
Figura 13: Casos comuns de Características mortas em cinza.
Fonte: (BENAVIDES; SEGURA; RUIZ-CORTÉS, 2010).
Na Figura 13, três exemplos de Características mortas são mostrados. Uma caracterí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.
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 expressividade 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 principal 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 normalmente 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ção 2.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
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 Figura 15.
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),
Capítulo 2. Linguagens de Domínio Específico
32
baseada em projeções:
• Textual Language Workbench (TLWB): há muitas ferramentas desse tipo onde a
maioria delas estão sobre o projeto Eclipse1 (MERKLE, 2010). Exemplos open-sources
são Xtext2 , EMF3 , 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 RunCC7 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 Intentional Language Workbench9 e Spoofax10
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 Figura 16 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
2
3
4
5
6
7
8
9
10
11
http://www.eclipse.org/modeling
http://www.eclipse.org/Xtext/
http://www.emftext.org/index.php/EMFText
http://www2.informatik.hu-berlin.de/sam/meta-tools/tef/index.html
http://www.eclipse.org/gmt/tcs/
http://www.antlr.org
http://runcc.sourceforge.net/
http://www.jetbrains.com/mps/index.html
http://intentsoft.com/
http://strategoxt.org/Spoofax
http://www.antlr.org/
Capítulo 2. Linguagens de Domínio Específico
33
Figura 16: Xtext workflow.
Fonte: Próprio autor.
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 Figura 17 demonstra a interface do editor.
Figura 17: Editor gerado pelo Xtext.
Fonte: Próprio autor.
Capítulo 2. Linguagens de Domínio Específico
2.5
34
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 Linguagens 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.
Parte II
Desenvolvimento
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êndice A.
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).
Fonte: Próprio autor.
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
versão correta será baixado. Mais detalhes na subseção 3.4.
Capítulo 3. Criação do Editor
37
artefatos com o comando Generate Xtext Artefacts. A Figura 18 ilustra 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:
relationships=Relationships (variationPoint+=VariationPoint)*
attributes=Attributes (attribute+=Attribute)*
globalAttributes=GlobalAttributes (globalAttribute+=GlobalAttribute)*
constraints=Constraints (constraint+=Constraint)*;
2
3
4
5
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
2
3
4
5
Relationships:
"%Relationships";
VariationPoint:
(name=QualifiedName | "[" name=QualifiedName "]") ":"
(cardinality=Cardinality)?
Capítulo 3. Criação do Editor
6
7
8
9
10
11
12
13
38
(variant+=Variant)*
";";
Cardinality:
"[" min=INT "," max=INT "]" "{" (variant+=Variant)* "}";
Variant:
name=QualifiedName | "[" name=QualifiedName "]";
QualifiedName:
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
2
3
4
5
6
7
8
9
10
11
12
13
Constraints:
"%Constraints";
Constraint:
c1=[Element|QualifiedName] (rule=Rule c2=[Element|QualifiedName] | "IMPLIES"
(attribute=[Att|QualifiedNameAtt])
comparison=Comparison num=INT) ";";
Att:
Attribute | GlobalAttribute;
enum Comparison:
G=">" | L="<" | GE=">=" | LE="<=" | E="==" | NE="!=";
Element:
Variant | VariationPoint;
enum Rule:
REQUIRES="REQUIRES" | EXCLUDES="EXCLUDES";
Capítulo 3. Criação do Editor
3.2.3
39
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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Attributes:
"%Attributes";
Attribute:
name=AttName ":" domain=Domain "," value=Value ";," nullValue=NullValue ";";
AttName:
element=[Element|QualifiedName] "." attributeName=QualifiedName;
QualifiedNameAtt:
ID ("." ID)*;
Domain:
number="[" INT ("," INT)* "]" | range="Integer" "[" INT "to" INT "]";
Value:
number=INT | attribute=[Attribute|QualifiedNameAtt] | equation=Equation |
function=Function;
NullValue:
INT | "INF" | "MINF";
Function:
"max(" a1=[Attribute|QualifiedNameAtt] ("," a2+=[Attribute|QualifiedNameAtt])+
")" | "min("a1=[Attribute|QualifiedNameAtt] (","
a3+=[Attribute|QualifiedNameAtt])+ ")";
Equation:
(n=INT | a=[Attribute|QualifiedNameAtt]) (el2+=El2)+;
El2:
(o=Operator) (n=INT | a=[Attribute|QualifiedNameAtt]);
enum Operator:
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
2
GlobalAttributes:
"%GlobalAttributes";
Capítulo 3. Criação do Editor
3
4
40
GlobalAttribute:
name=QualifiedName ":" domain=Domain "," value=Value ";," nullValue=NullValue
";";
3.3
3.3.1
Funcionalidades do Editor
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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@Check
def checkCardinality(Cardinality cardinality) {
if (cardinality.variant.size < cardinality.min) {
error("Cardinality MIN not respected.",
OvmPackage.Literals.CARDINALITY__MIN);
} }
@Check
def checkVariationPointToVariantConstraint(Constraint constraint) {
var listaRules = (constraint.eContainer() as Model).constraint;
if (listaRules.size > 0) {
for (r_aux : listaRules) {
if (constraint.c1 instanceof VariationPoint && constraint.c2 instanceof
Variant) {
error("Variation Point cannot REQUIRES or EXCLUDES a Variant.",
OvmPackage.Literals.CONSTRAINT__C2);
return;
} else if (constraint.c1.equals(constraint.c2)) {
error("A Element cannot REQUIRES or EXCLUDES itself.",
OvmPackage.Literals.CONSTRAINT__C2);
Capítulo 3. Criação do Editor
41
} } } }
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 Figura 19 é mostrado o editor e a validação em funcionamento.
Figura 19: Editor com a Validação em funcionamento.
Fonte: Próprio autor.
Há também algumas validações já prontas para uso, que podem ser ativadas no arquivo ”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
2
3
4
5
// Xtend-based API for validation
fragment = validation.ValidatorFragment auto-inject {
//
composedCheck = "org.eclipse.xtext.validation.ImportUriValidator"
composedCheck = "org.eclipse.xtext.validation.NamesAreUniqueValidator"
}
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
o qual a sintaxe da linguagem OVM não seria 100% válida.
Capítulo 3. Criação do Editor
42
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
2
3
%Constraints
Screen.Basic EXCLUDES Utility.Gps;
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
2
QualifiedName qualifiedName(Variant v) {
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
2
3
4
5
6
7
8
QualifiedName qualifiedName(Attribute a) {
if (a.getName() != null) {
List<INode> nodes = NodeModelUtils.findNodesForFeature(a.getName(),
OvmPackage.Literals.ATT_NAME__ELEMENT);
if (nodes.size() > 0) {
return QualifiedName.create(nodes.get(0).getText().trim(),
a.getName().getAttributeName());
}
}
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
2
3
4
@Override
public Class<? extends IQualifiedNameProvider> bindIQualifiedNameProvider() {
return OvmQNP.class;
}
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
Capítulo 3. Criação do Editor
43
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 elementos. A classe completa está no link http://www.gca.unijui.edu.br//Download.ashx?id=468.
A Figura 20 mostra os caracteres de escape definidos na classe.
1
2
3
4
5
6
7
8
9
10
11
12
//tags
c.setLinewrap(1).after(variationPointRule)
//variation point
for (Keyword comma : variationPointAccess.findKeywords(",")) {
c.setNoSpace().around(comma); }
//attributes
for (pair : functionAccess.findKeywordPairs("max(", ")")) {
c.setNoSpace().after(pair.getFirst());
c.setNoSpace().before(pair.getSecond()); }
//GlobalAttributes
for (Keyword dot : globalAttributeAccess.findKeywords(".")) {
c.setNoSpace().around(dot)}
Figura 20: Editor com detalhes de caracteres escondidos usados na formatação.
Fonte: Próprio autor.
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 alguns passos. Primeiramente a criação do arquivo de configuração onde as cores 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
2
3
4
5
6
7
8
9
10
11
public static final String VARIATION_POINT = "Variation Point";
public static final String VARIANT = "Variant";
public void configure(IHighlightingConfigurationAcceptor acceptor) {
addType(acceptor, VARIATION_POINT, 178, 0, 108, NORMAL);
addType(acceptor, VARIANT, 0, 127, 50, NORMAL);
public void addType(IHighlightingConfigurationAcceptor acceptor, String s, int r,
int g, int b, int style) {
TextStyle textStyle = new TextStyle();
textStyle.setBackgroundColor(new RGB(255, 255, 255));
textStyle.setColor(new RGB(r, g, b));
textStyle.setStyle(style);
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 problemas 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
2
3
4
5
6
7
8
9
10
public void provideHighlightingFor(XtextResource resource,
IHighlightedPositionAcceptor acceptor) {
if (resource == null || resource.getParseResult() == null)
return;
INode root = resource.getParseResult().getRootNode();
BidiTreeIterator<INode> it = root.getAsTreeIterable().iterator();
while (it.hasNext()) {
INode node = it.next();
if (!(node instanceof CompositeNodeWithSemanticElement)) {
// VARIATION POINT
if (node instanceof CompositeNode && node.getGrammarElement() instanceof
RuleCall) {
Capítulo 3. Criação do Editor
if (node.getSemanticElement() instanceof VariationPoint) {
setStyles(acceptor, it, VARIATION_POINT); } }
// VARIANT
if (node instanceof CompositeNode || node instanceof SyntheticCompositeNode &&
node.getGrammarElement() instanceof RuleCall) {
if (node.getSemanticElement() instanceof Variant) {
setStyles(acceptor, it, VARIANT); } }
11
12
13
14
15
16
17
45
}
Por fim, basta registrar as classes na classe de módulos do projeto "gca.ovm.ui"
chamada “OvmUiModule.java” de forma semelhante a que foi feita na definição dos nomes.
Na Figura 21 vemos como fica um modelo OVM no editor.
1
2
3
4
public Class<? extends IHighlightingConfiguration> bindIHighlightingConfiguration() {
return OvmHighlightingConfiguration.class; }
public Class<? extends ISemanticHighlightingCalculator>
bindISemanticHighlightingCalculator() {
return OvmHighlightingCalculator.class; }
Figura 21: Editor com Sintax Highlighting (esquerda) e sem (direita).
Fonte: Próprio autor.
3.3.5
Definindo o Assistente de Criação de Projetos do Editor
O Xtext possui um recurso de criação automática de uma interface gráfica para
criação de novos projetos pelos usuários que instalarem o plugin (Figura 22). Wizard ou
Assistente, como é chamado, pode ser criado adicionando alguns parâmetros ao arquivo
”GenerateOvm.mwe2“, como visto abaixo:
1
2
3
4
// project wizard (optional)
fragment = projectWizard.SimpleProjectWizardFragment auto-inject {
generatorProjectName = "${projectName}"
fileExtension = fileExtensions }
Capítulo 3. Criação do Editor
46
Ao compilar o projeto novamente, será criado, dentro do projeto de UI, um pacote de
nome wizard contendo um arquivo com extensão ”.xpt“. Nele é possível criar um projeto
base que será instanciado ao selecionar um novo projeto.
Figura 22: Tela de criação de novo projeto gerado pelo Assistente.
Fonte: Próprio autor.
3.4
Geração do plugin
Terminado o desenvolvimento do plugin, é hora de fazer a exportação do mesmo.
O Eclipse é bem conhecido por sua vasta gama de plugins, e para criar um é bem fácil,
bastando seguir alguns passos.
Primeiramente é necessário criar um Feature Project e adicionar o plugin nele, utilizando os seguintes comandos: ”File -> New -> Other... -> Plug-in Development
-> Feature Project“. Depois de colocar os dados de indentificação, é necessário referenciar o projeto criado. Após isso, cria-se uma categoria via ”File -> New -> Other...
-> Plug-in development -> Category Definition“. Um arquivo XML será criado onde
deve-se adicionar a categoria desejada. Após este passo, cria-se um update site através
dos menus ”File -> Export -> Deployable features“, escolhe-se a pasta destino e
em options é necessário especificar o arquivo XML anteriormente criado. Feito todos esses
passos, uma pasta será criada contendo o plugin e demais arquivos necessários para a correta configuração do editor. A instalação pode ser feita da mesma forma que qualquer plugin
na plataforma eclipse, através do menu ”Help -> Install new software“, clicando em
”add“ e localizando a pasta, seja ela local ou remota através de um servidor HTTP.
A grande vantagem dessa abordagem é que, como o plugin somente funciona na
Capítulo 3. Criação do Editor
47
versão do Xtext em que foi criado, o Assistente de instalação se encarregará de baixar a
versão correta do Xtext.
3.5
Validação do Editor
Para validar o editor criado é necessário criar um conjunto de casos de testes que
validem a funcionalidade da ferramenta de edição criada. Testes de software tem o objetivo
de revelar falhas no software testado. Isto é feito checando o comportamento do programa
com diferentes entradas e saídas (MYERS et al., 2004; PRESSMAN, 1986).
Neste capítulo será apresentado um conjunto de testes que visam validar a funcionalidade do editor previamente criado. Cada teste foi pensado para ter como saída somente
um tipo de falha, semelhante a (SEGURA; BENAVIDES; RUIZ-CORTéS, 2010). Criar testes
que cubram 100% das possibilidades é uma tarefa impossível (MYERS et al., 2004). No
entanto, Pressman (PRESSMAN, 1986) diz que devemos criar testes que tenham mais
chances de achar erros com o menor esforço possível.
Os testes foram projetados tendo como entrada um modelo OVM sendo esperado uma saída verdadeira ou falsa, baseados na estrutura da linguagem e no que
ela aceita como entrada. Primeiramente foram criados testes simples, chamados de
básicos, que possuem somente elementos dentro da tag %Relationships. Testes envolvendo Constraints e Attributes também foram feitos. Todos esses testes necessitam
uma saída verdadeira para estarem corretos, pois, segundo a sintaxe da linguagem,
são modelos válidos. A Tabela 2 mostra os resultados dos testes realizados. No link
http://www.gca.unijui.edu.br//Download.ashx?id=466 estão os arquivos testados.
Tabela 2: Testes que esperam um resultado de "Aceito".
Teste
Descrição
Entrada
Saída
Basic1
Basic2
Basic3
Constraint1
Attribute1
Attribute2
Modelo vazio, somente tags.
Modelo com Variation Point vazio.
Mais de um Variation Point com diferentes Variants.
Todas as Constraints possíveis da sintaxe.
Todos os Attributes possíveis na sintaxe.
Todos os Global Attributes possíveis na sintaxe.
OVM
OVM
OVM
OVM
OVM
OVM
Aceito
Aceito
Aceito
Aceito
Aceito
Aceito
Fonte: Elaborado pelo autor.
Também foram feitos testes que esperam resultados errôneos. Estes testes tem o
intuito de verificar a própria validação que o editor possui. Semelhante aos testes feitos
anteriormente, estes também possuem um nome, descrição, entrada e saída. No entanto,
a saída que se espera é um erro do editor, ou seja, caso um erro ocorrer, o teste estará
correto. A Tabela 3 mostra os testes realizados. Os arquivos também estão disponíveis no
link http://www.gca.unijui.edu.br//Download.ashx?id=466.
Capítulo 3. Criação do Editor
48
Tabela 3: Testes que esperam um resultado de "Erro".
Teste
Descrição
Entrada Saída
Error1
Error2
Error3
Error4
Error5
Error6
Erro em Constraints. Um elemento não pode se auto referenciar.
Erro em Cardinality. Cardinalidade mínima não respeitada.
Erro em Variation Points e Variants. Elementos não podem ter mesmo nome.
Erro em Constraints. Ponto de Variação não pode referenciar uma Variante.
Erro em Attributes. Atributos devem ter nomes únicos.
Erro em Global Attributes. Global Atributos devem ter nomes únicos.
OVM
OVM
OVM
OVM
OVM
OVM
Erro
Erro
Erro
Erro
Erro
Erro
Fonte: Elaborado pelo autor.
No decorrer do desenvolvimento do editor, testes foram efetuados utilizando o
mesmo modelo utilizado por Frantz (ROOS-FRANTZ, 2011), disponível no através do link
http://www.gca.unijui.edu.br//Download.ashx?id=467. Como exemplos de modelos OVM são
escassos, a solução adotada para realização de uma validação mais completa foi a de transformar a modelagem feita em outras linguagens para a sintaxe de OVM. Para isso, foi utilizado o site www.splot-research.org/ o qual possui um grande repositório de modelos em
Feature Model. Foram escolhidos dois diferentes modelos, Database Tools e Billing, e traduzidos para OVM a fim de testar a capacidade de validação do editor. Os modelos em Feature
Model estão diponíveis através do link http://www.gca.unijui.edu.br//Download.ashx?id=470,
enquanto que Os modelos OVM podem ser vistos nos Apêndices B. Ambos modelos não
apresentaram erros.
3.6
Resumo do Capítulo
Neste capítulo foram vistas as etapas da criação do editor. A gramática foi criada
com a notação BNF estendida com suporte, inclusive, a Atributos e Atributos Globais.
Funcionalidades extras foram agregadas ao editor, como Validação, Formatação e Coloração
de Sintaxe, através de classes adicionais. A exportação do plugin do editor também foi
comentada. Por fim, a validação do editor, ou seja, os testes realizados foram mostrados,
constatando que o editor não possui erros.
49
4 Ferramenta de Apoio a Análise Automática
4.1
Produto Eclipse
Apesar da geração de plugins ser efetiva e vastamente usada por desenvolvedores
da plataforma Eclipse, há outra maneira de disponibilizarmos nossas aplicações, ou seja,
criando uma Aplicação Eclipse. Este tipo de aplicação usa os componentes base do
eclipse e adiciona componentes adicionais específicos. O resultado é uma versão do
Eclipse customizada que funciona "em cima" da plataforma Java, assim como o Eclipse. A
vantagem é o poder de customização que pode ser usado, além de facilitar a instalação
pois basta apenas abrir a IDE e começar a trabalhar.
Nesse sentido, foi criado uma Aplicação Eclipse contendo o plugin gerado pelo Xtext,
disponível para download através do site http://gca.unijui.edu.br/cpolitowski/Tool. Para isso,
há alguns passos a serem seguidos, que serão discutidos nas próximas subseções.
4.1.1
Projeto de Plugin
Com a aplicação já pronta, primeiramente criou-se um Plugin Project no Eclipse, em
"File -> New -> Project -> Plugin Development -> Plugin Project". O nome dado
foi "gca.ovm.product" e marcado as opções "Generate an activator, a Java class
that controls the plugin’s life cycle" e "This plugin will make contribuitions
to the UI". A Figura 23 ilustra essas ações.
No arquivo MANIFEST.MF, em "Dependencies" deve-se adicionar o plugin
"org.eclipse.core.runtime" caso não esteja presente. Na aba "Extensions", em
"org.eclipse.core.runtime.products" coloca-se o ID=product. Foram criados também um "New Product" e um "New Property", conforme a Figura 24.
4.1.2
Projeto de Feature
Para próxima etapa foi criado um Projeto de Feature onde os plugins específicos
da DSL foram colocados. Em "File -> New -> Project -> Plugin Development ->
Feature Project" criou-se um novo projeto com um arquivo "feature.xml" onde foram
adicionados os projeto do Xtext: "gca.ovm", "gca.ovm.product", "gca.ovm.tests" e
"gca.ovm.ui".
Capítulo 4. Ferramenta de Apoio a Análise Automática
Figura 23: Novo Projeto de Plugin no Eclipse.
Fonte: Próprio autor.
Figura 24: Arquivo MANIFEST.MF.
Fonte: Próprio autor.
50
Capítulo 4. Ferramenta de Apoio a Análise Automática
4.1.3
51
Projeto de Feature para a Plataforma
Com o Projeto de Feature criamos a estrutura da aplicação, mas também é necessá-
rio criar o ambiente para sua execução. Para isso um novo Projeto de Feature deve ser criado
e adicionado todos os plugins necessários para uma IDE eclipse funcionar minimamente. A
documentação não diz quais são esses plugins, por isso, nessa fase, foram adicionados um
a um até que nenhum erro surgisse. O arquivo "feature.xml", contendo os plugins necessários, está disponível através do link http://www.gca.unijui.edu.br//Download.ashx?id=469.
4.1.4
Arquivo ovm.product
Para finalizar, algumas configurações foram necessárias no arquivo "ovm.product"
que está na raiz do projeto principal, na aba "overview", da seguinte maneira:
1. name: OVM;
2. product: gca.ovm.product.product;
3. application: org.eclipse.ui.ide.workbench;
4. based on: features;
E na aba "Dependencies", adicionou-se os projetos anteriormente criados:
"gca.ovm.feature" e "gca.ovm.platform.feature". A Figura 25 demonstra como ficaram os arquivos.
4.1.5
Exportar o Produto Eclipse
Um problema surgiu ao tentar exportar o Produto Eclipse para outras plataformas
que não a nativa1 . Para resolver essa questão, foi usado o "DeltaPack", também da fundação
Eclipse, que possibilita exportar para várias plataformas como MAC e Windows, 32 e 64
bits. Os seguintes passos são necessários:
• Abrir Window/Preferences;
• Achar PDE/Target Platform;
• Selecionar a plataforma ativa;
• Clicar em Edit;
• Clicar em Add;
1
No meu caso, Linux 64 bits.
Capítulo 4. Ferramenta de Apoio a Análise Automática
52
Figura 25: Arquivo ovm.product.
Fonte: Próprio autor.
• Selecionar "Software Site";
• Clicar Next;
• Em "Work With" digitar: http://download.eclipse.org/eclipse/updates/4.3);
• Marcar "Eclipse RCP Target Components" e "Equinox Target Components";
• Desmarcar "Include required software";
• Marcar "Include all environments";
• Clicar em Finish,Finish e OK.
As Figuras 26 mostram as opções de plataformas disponíveis.
4.1.6
Customização do Produto Eclipse
Uma das vantagens de se criar um Produto Eclipse são as possibilidades de custo-
mização existentes. Ícones, tela de loading, página de about, tela de "boas vindas", entre
outros recursos podem ser anexados para criar uma identidade ao produto.
Capítulo 4. Ferramenta de Apoio a Análise Automática
53
Figura 26: Plataformas do DeltaPack disponíveis.
Fonte: Próprio autor.
Nesse sentido, foi criado um logo2 do editor que aparece no momento da abertura
do mesmo e ícones para os executáveis. A Figura 27 mostra o logo criado, sendo o ícone
somente o escudo.
Figura 27: Logo do Editor.
OVM Textual Editor
Fonte: Próprio autor.
2
Paladin ou Paladino é uma classe de personagens de Dungeons and Dragons que, entre outras características, deve ser sempre leal e bom. Por ser um personagem híbrido e possuir magias de cura, é um
excelente suporte para o time, daí a ideia do nome, pois a ferramenta foi criada para dar “suporte à
edição de OVMs”.
Capítulo 4. Ferramenta de Apoio a Análise Automática
4.2
54
Interface para a ferramenta FaMa-OVM
Como mencionado anteriormente, existem duas fases no processo de Análise
Automática de Modelos de Variabilidade: Fase de Especificação e Fase de Análise. As
etapas mostradas até o momento cobriram a primeira, ou seja, toda a preparação dos
Modelos OVM para a fase posterior. Para fazer a Análise Automática dos modelos, utilizouse o framework FaMa-OVM. FaMa-OVM é uma ferramenta para a análise automática de
OVMs. É uma extensão do FaMa Framework, open source e escrita em Java. Seu objetivo
é prover uma estrutura básica para o processo de análise automática além de suporte a
múltiplos solvers como JavaBDD, SAT4J, CHoco e JaCoP (FAMA-OVM, 2014).
Entretanto, o FaMa-OVM não possui uma interface para utilização, isso acarreta em
trabalhar em código puro para executar as ações nos modelos. A partir desse problema,
sugeriu-se a criação de um protótipo de interface funcional onde o carregamento dos
modelos (arquivos com extensão ".ovm") seja feito de forma fácil, bem como a execução das
questions e adição de parâmetros. Esse protótipo foi feito em Java utilizando componentes
gráficos da linguagem como AWT e Swing.
Para a criação da interface gráfica, além das bibliotecas necessárias para o funcionamento do framework, também foi usada a biblioteca MigLayout3 , que ajuda na adição
de componentes à tela. MigLayout foi escolhida pelo fato de que o código foi inteiramente
escrito e não gerado. Por se tratar de um projeto pequeno, essa metodologia foi adequada,
além de proporcionar uma melhor portabilidade de código. Apenas duas classes foram
criadas, uma contendo os métodos, ou seja, as questions utilizadas pela classe de tela.
Como nem todos os métodos foram utilizados, basta ir adicionando-os na classe a medida
que forem feitos.
Para a execução do projeto, primeiramente é necessário o carregamento de um
arquivo com extensão “.ovm” criado anteriormente pelo Editor Textual. Em seguida escolhese a question desejada e, caso não haja mais parâmetros necessários, executa-se. Como
exemplo, na Figura 28 apresenta um print screen da execução da question Dead Feature no
mesmo modelo utilizado por Frantz (ROOS-FRANTZ, 2011), descrito na seção 3.5. Como
visto anteriormente na Figura 13, uma característica está “morta” se ela não aparece em
nenhum dos produtos da Linha de Produtos, seção 1.7.
Um detalhe que ocasionou alguns erros ao tentar carregar arquivos .ovm para a
ferramenta FaMa-OVM foi o “modo do arquivo”. Caracteres escondidos que sinalizam fim de
linha são diferentes quando em plataformas Windows e Linux. A primeira usa “CR” (carriage
return) e “LF” (line feed) enquanto que a última utiliza somente “LF”. Ha também o problema
de sistemas MAC, que usam “CR” somente. Caso o usuário esteja criando os modelos OVM
em uma máquina Linux, terá que converter o arquivo antes de carregá-lo para o FaMa-OVM.
3
http://www.miglayout.com/
Capítulo 4. Ferramenta de Apoio a Análise Automática
55
Figura 28: Question Dead Feature na Interface do FaMa-OVM.
Fonte: Próprio autor.
Figura 29: Question All Products na Interface do FaMa-OVM.
Fonte: Próprio autor.
Na seção 1.1.1 apresentou-se um pequeno exemplo de Linha de Produtos e a lista
de possíveis produtos desta Linha de Produtos. O FaMa-OVM possui uma question que
faz essa análise. Figura 29 mostra o resultado da execução da question All Products que
Capítulo 4. Ferramenta de Apoio a Análise Automática
56
lista todos os produtos possíveis na Linha de Produtos definida pelo modelo carregado. O
modelo OVM está no Apêndice D e o resultado completo da análise pode ser visualizada no
Apêndice C.
Infelizmente, devido a restrições da ferramenta utilizada para a criação do editor
(Xtext), não foi possível fazer a integração de uma melhor forma com a ferramenta de análise
FaMa-OVM. Isto se deu ao fato de que o editor gerado, tanto o produto eclipse quanto o
plugin, necessitam da infraestrutura do Projeto Eclipse. Sendo o FaMa-OVM apenas uma
aplicação Java que faz o uso de bibliotecas normais, impossibilitou a anexação do editor ao
projeto.
4.3
Resumo do Capítulo
Neste capítulo, foram abordados dois assuntos distintos. Primeiramente os detalhes
do método de criação de um editor customizado, chamado Produto Eclipse, que usa
elementos da plataforma Eclipse juntamente com o projeto do editor para criar um novo
produto. O segundo assunto, a Interface para a ferramenta FaMa-OVM, detalhou o processo
de criação e funcionamento do Protótipo Funcional do framework.
57
Conclusão
A Linha de Produtos de Software possui o Modelo de Variabilidade como principal
elemento. Dentre esses modelos, o Modelo de Variabilidade Ortogonal, cujo único objetivo
é modelar a Variabilidade da Linha de Produtos de Software, considerado, portanto, uma
Linguagem de Domínio Específico.
Para validar uma Linguagem, é necessário criar uma gramática, através de uma
notação. Existem ferramentas que auxiliam na criação destas linguagens, chamadas de
Languages Workbenches, e entre elas, Xtext é uma das mais conhecidas, propiciando um
ambiente para a criação da gramática e outras funcionalidades, juntamente com um editor
fará uso desses recursos.
Utilizando o Xtext, foi construída a gramática da notação textual da linguagem OVM,
que possui quatro elementos principais, Relationships, Constraints, Attributes e Global
Attributes. Funcionalidades extras foram criadas para Formatação, Validação, Coloração de
Sintaxe, entre outras, resultando na criação de um editor intuitivo e de fácil uso.
Foi desenvolvido também um Protótipo Funcional para o framework FaMa-OVM,
através de recursos gráficos da linguagem Java, possibilitando uma nova maneira, mais
rápida e fácil, de se testar os modelos de variabilidade com sintaxe OVM criados pelo editor
anterior.
Agora é possível criar e editar Modelos de Variabilidade de uma Linha de Produtos
de Software através de um editor que valida a sintaxe do Modelo de Variabilidade Ortogonal
e posteriormente testá-lo no framework de Análise Automática FaMa-OVM através de uma
aplicação intuitiva e aberta à expansões.
Ao final deste trabalho identificou-se alguns trabalhos futuros, tais como a extensão
da ferramenta para tratar as demais operações de análise, melhorias no Protótipo de
Interface do FaMa-OVM. Outro trabalho interessante é a criação de uma ferramenta visual
de criação de modelos OVM, que podeira utilizar recursos deste mesmo trabalho para gerar
uma representação gráfica dos elementos de variabilidade.
58
Referências
BENAVIDES, D. On the automated analysis of software product lines using feature models.
Tese (Doutorado) — University of Sevilla, Spain, 2007. Citado na página 28.
BENAVIDES, D.; SEGURA, S.; RUIZ-CORTÉS, A. Automated analysis of feature models 20
years later: A literature review. Information Systems, Elsevier Science Ltd., Oxford, UK,
v. 35, n. 6, p. 615 – 636, 2010. Citado 2 vezes nas páginas 28 e 29.
CLASSEN, A.; BOUCHER, Q.; HEYMANS, P. A text-based approach to feature modelling:
Syntax and semantics of TVL. Science of Computer Programming, v. 76, n. 12, p.
1130–1143, dez. 2011. Disponível em: <http://dx.doi.org/10.1016/j.scico.2010.10.005>.
Citado na página 13.
CLEMENTS, P.; KAZMAN, R.; KLEIN, M. Evaluating Software Architectures: Methods and
Case Studies. [S.l.]: Addison-Wesley, 2001. ISBN 978-0-201-70482-2. Citado 2 vezes nas
páginas 19 e 21.
CLEMENTS, P. C.; NORTHROP, L. Software Product Lines: Practices and Patterns. [S.l.]:
Addison-Wesley, 2001. (SEI Series in Software Engineering). Citado na página 16.
DAVIS, S. M. From future perfect: Mass customizing. Strategy and Leadership, v. 17, n. 2, p.
16–21, 1989. Citado na página 12.
FAMA-OVM. FaMa-OVM Framework. 2014. <http://www.isa.us.es/fama-ovm/>. Citado na
página 54.
FOWLER, M. Domain-Specific Languages. [S.l.: s.n.], 2010. 0–321 p. ISBN 9780321712943.
Citado 2 vezes nas páginas 30 e 31.
FRANTZ, F. R. et al. FaMa-OVM: a tool for the automated analysis of OVMs. In: Proceedings
of the 16th International Software Product Line Conference - Volume 2. ACM, 2012. (SPLC
’12), p. 250–254. Disponível em: <http://dx.doi.org/10.1145/2364412.2364456>. Citado na
página 13.
KANG, K. C. et al. Feature-Oriented Domain Analysis (FODA) Feasibility Study. [S.l.], 1990.
Citado na página 21.
MERKLE, B. Textual modeling tools: Overview and comparison of language workbenches.
In: Proceedings of the ACM International Conference Companion on Object Oriented
Programming Systems Languages and Applications Companion. ACM, 2010. (SPLASH ’10),
p. 139–148. Disponível em: <http://dx.doi.org/10.1145/1869542.1869564>. Citado 4 vezes
nas páginas 13, 30, 31 e 32.
MYERS, G. et al. The Art of Software Testing. [S.l.]: John Wiley & Sons, 2004. (Business
Data Processing: a Wiley Series). ISBN 9780471469124. Citado na página 47.
POHL, K.; BöCKLE, G.; LINDEN, F. J. v. d. Software Product Line Engineering: Foundations,
Principles and Techniques. [S.l.]: Springer-Verlag, 2005. Citado 10 vezes nas páginas 12,
13, 16, 17, 18, 19, 20, 21, 22 e 23.
Referências
59
PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach (2Nd Ed.). New York,
NY, USA: McGraw-Hill, Inc., 1986. ISBN 0-070-50783-X. Citado na página 47.
ROOS-FRANTZ, F. Automated Analysis of Software Product Lines with Orthogonal
Variability Models. 2011. Citado 6 vezes nas páginas 23, 24, 25, 26, 48 e 54.
SEGURA, S.; BENAVIDES, D.; RUIZ-CORTéS, A. FaMa Test Suite v1.2. [S.l.], 2010. Citado
na página 47.
STOFFEL, R. Comparing Language Workbenches. 2010. Citado na página 32.
XTEXT. Xtext Documentation. 2013. <http://www.eclipse.org/Xtext/documentation.html>.
Citado 5 vezes nas páginas 37, 38, 40, 41 e 43.
Apêndices
61
APÊNDICE A – Representações Gráficas
da Gramática da Linguagem OVM.
A representação gráfica da gramática textual pode ser vista nas Figura 30, 31, 32,
34 e 33. Esta representação é bem útil até mesmo em desenvolvimento pois permite uma
visão da estrutura como um todo facilitando a busca e correção de erros.
Figura 30: Representação gráfica da Gramática - Model.
Fonte: Próprio autor.
Figura 31: Representação gráfica da Gramática - Relationships.
Fonte: Próprio autor.
APÊNDICE A. Representações Gráficas da Gramática da Linguagem OVM.
Figura 32: Representação gráfica da Gramática - Constraints
Fonte: Próprio autor.
Figura 33: Representação gráfica da Gramática - Atributos Globais
Fonte: Próprio autor.
62
APÊNDICE A. Representações Gráficas da Gramática da Linguagem OVM.
Figura 34: Representação gráfica da Gramática - Atributos.
Fonte: Próprio autor.
63
64
APÊNDICE B – Modelos em OVM
Figura 35: Modelo em OVM - Database Tools.
Fonte: Próprio autor.
Figura 36: Modelo em OVM - Billing.
Fonte: Próprio autor.
65
APÊNDICE C – Interface do FaMa-OVM:
resultado da Products
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Product
Product
Product
Product
Product
Product
Product
Product
Product
Product
Product
Product
Product
Product
1: Screen Colour
2: Screen Colour Media MP3
3: Screen Colour Utility Gps
4: Screen Colour Media MP3 Utility Gps
5: Screen High
6: Screen High Media MP3
7: Screen High Utility Gps
8: Screen High Media MP3 Utility Gps
9: Screen High Media Camera
10: Screen High Media Camera MP3
11: Screen High Media Camera Utility Gps
12: Screen High Media Camera MP3 Utility Gps
13: Screen Basic
14: Screen Basic Media MP3
66
APÊNDICE D – Modelo OVM de uma
LPS Mobile
1
2
3
4
%Relationships
Screen : [1,1] {Basic Colour High} ;
[Media] : [1,2] {Camera MP3} ;
[Utility] : Gps ;
5
6
7
8
%Constraints
Basic EXCLUDES Gps ;
Camera REQUIRES High ;