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

Tamanho: px
Começar a partir da página:

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

Transcrição

1 Universidade Regional do Estado do Rio Grande do Sul UNIJUÍ Cristiano Politowski Uma ferramenta de apoio à edição e validação de OVMs textuais para dar suporte ao processo de análise automática Santa Rosa, RS, Brasil 2014

2 Cristiano Politowski Uma ferramenta de apoio à edição e validação de OVMs textuais para dar suporte ao processo de análise automática Trabalho de Conclusão de Curso do curso de Ciência da Computação da Universidade Regional do Noroeste do Estado do Rio Grande do Sul. Orientador: Dra. Fabrícia Roos Frantz Santa Rosa, RS, Brasil 2014

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

4 Agradecimentos A minha mãe Ivone, meu sogro Cláudio, minha sogra Marly e minha namorada Susan, por ter dado o suporte sem o qual nada disso seria possível. Aos meus professores da graduação, pelo conhecimento passado e pela humildade demonstrada. Em especial aos professores Gerson Battisti pela oportunidade de trabalho logo no início do curso e ao professor Vinícius Maran pelos conselhos e camaradagem. A minha orientadora, professora Fabrícia Roos Frantz, primeiro por aceitar me orientar no TCC e na bolsa de iniciação científica, e segundo pela paciência e atenção além dos valiosos conselhos que acredito serem mais importantes que qualquer conceito da computação.

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

6 Resumo A Engenharia de Linha de Produtos de Software é um paradigma de desenvolvimento de software voltado ao reuso de artefatos comuns, sendo seu principal elemento a Variabilidade, definida por um Modelo de Variabilidade, o qual pode ser representado usando diferentes notações. O Modelo de Variabilidade Ortogonal é um desses modelos, cujo objetivo é representar a variabilidade da linha de produtos. O número de possíveis combinações entre elementos deste modelo cresce exponencialmente a medida que se acrescentam elementos, o que dificulta a análise manual dos mesmos. Para resolver este problema, o processo de análise automática de modelos de variabilidade tem o propósito de analisar esses modelos, proporcionando uma forma de gerenciar a Linha de Produtos de Software. Uma das ferramentas que implementa o processo de análise automática é FaMa-OVM, a qual recebe como parâmetro de entrada um modelo textual escrito com a linguagem OVM, juntamente com operações que serão interpretadas e processadas, resultando em Verdadeiro ou Falso, um Produto, vários Produtos, entre outros. Porém, caso haja erros nesse modelo de entrada, a ferramenta não fará a análise e o processamento resultará em erro. Para resolver este problema, se faz necessário um editor com recursos de validação de sintaxe, e uma ferramenta que integre este editor com a ferramenta de análise FaMa- OVM. Sendo a Linguagem OVM de Domínio Específico, é pertinente o uso de Language Workbenches para construção do editor. Uma das mais conhecidas e completas Language Workbenches existentes na comunidade open source é a Xtext, possuindo, entre outras funcionalidades, suporte a criação da gramática com notação BNF, validação, formatação, syntax highlighting além dos recursos providos pela plataforma Eclipse, onde o Xtext funciona como plugin. O trabalho desenvolveu-se em três etapas principais. Primeiramente, fez-se um estudo dos conceitos de Engenharia de Linha de Produtos de Software e Linguagens de Domínio 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.

7 Abstract The Software Product Line Engineering is a software development paradigm aimed to reuse of common artifacts, being the Variability its main element, defined by a Variability Model, which can be represented using different notations. The Orthogonal Variability Model is one of these models, which objective is to represent the Product Line. The size these models grow up exponentially as is added elements, making impossible the its manual analysis. To solve this problem, the Automatic Analysis of Variability Models has the intention analyze this models, creating a way to manage the Software Product Line. One of the tools that implement the Automatic Analysis process is FaMa-OVM, which receive as input parameter a textual model written with OVM language, together with operations that are interpreted and processed, resulting in outputs like True or False, a Product, many Products, among others. However, in case of errors on input model, the tool will not make the analysis and the process will result in error. To solve this problem, is needed a editor with syntax validation resources, and a tool that integrate this editor with the FaMa-OVM analysis tool. Being OVM a Domain Specific Language, is pertinent the use of Language Workbenches to build the editor. One of the most known and complete Language Workbenches existing on open source community is the Xtext, having, among others features, support to grammar creation with BNF notation, validation, formatting, syntax highlighting besides of the resources provided by the Eclipse platform, where Xtext works as plug-in. The paper was developed in three main stages. Firstly,was made a study of concepts of Software Product Line Engineering and Domain Specific Languages. The second stage was the stage of implementation of grammar using the tool chosen and its validation. The last phase was the creation of a Graphic Interface for a better integration with the analysis tool FaMa-OVM. Key-words: Software Engineering. Software Product Line Engineering. Variability Models. Automated Analisys of Variability Models. Domain Specific Language. Grammar. Textual Language. Orthogonal Variability Model. Xtext.

8 Lista de ilustrações Figura 1 Custo de desenvolvimento para Sistemas Únicos e Família de Sistemas. 16 Figura 2 Time to market para Sistemas Únicos e Família de Sistemas Figura 3 Framework para SPLE Figura 4 Pirâmide da variabilidade Figura 5 Exemplo de modelo de variabilidade usando Feature Model Figura 6 Metamodelo da OVM em UML Figura 7 Notação gráfica da OVM Figura 8 Exemplo de modelo de variabilidade usando OVM Figura 9 Metamodelo baseado em atributos Figura 10 Exemplo de atributos básicos (cinza) e derivados (branco) Figura 11 Restrições de Domínio em uma AOVM Figura 12 Processo para a análise automática de Modelos de Variabilidade Figura 13 Casos comuns de Características mortas em cinza Figura 14 Exemplos de DSLs gráfica(a) e textual(b) Figura 15 Formalismo de Backus-Naur Figura 16 Xtext workflow Figura 17 Editor gerado pelo Xtext Figura 18 Eclipse com Xtext. Novo projeto (esquerda). Estrutura de diretórios (direita). 36 Figura 19 Editor com a Validação em funcionamento Figura 20 Editor com detalhes de caracteres escondidos usados na formatação.. 43 Figura 21 Editor com Sintax Highlighting (esquerda) e sem (direita) Figura 22 Tela de criação de novo projeto gerado pelo Assistente Figura 23 Novo Projeto de Plugin no Eclipse Figura 24 Arquivo MANIFEST.MF Figura 25 Arquivo ovm.product Figura 26 Plataformas do DeltaPack disponíveis Figura 27 Logo do Editor Figura 28 Question Dead Feature na Interface do FaMa-OVM Figura 29 Question All Products na Interface do FaMa-OVM Figura 30 Representação gráfica da Gramática - Model Figura 31 Representação gráfica da Gramática - Relationships Figura 32 Representação gráfica da Gramática - Constraints Figura 33 Representação gráfica da Gramática - Atributos Globais Figura 34 Representação gráfica da Gramática - Atributos Figura 35 Modelo em OVM - Database Tools Figura 36 Modelo em OVM - Billing

9 Lista de tabelas Tabela 1 Objetivos da Engenharia de Domínio e Aplicação Tabela 2 Testes que esperam um resultado de "Aceito" Tabela 3 Testes que esperam um resultado de "Erro"

10 Lista de abreviaturas e siglas SPLE SPL VM FM OVM AOVM AAVM DSL BNF TLWB PLWB do inglês Software Product Line Engineering. Em português Engenharia de Linha de Produtos de Software. do inglês Software Product Line ou Linha de Produtos de Software. do inglês Variability Model. Em português Modelos de Variabilidade. do inglês Feature Model. Em português Modelo de Features. do inglês Orthogonal Variability Modelo. Em português Modelo de Variabilidade Ortogonal. do inglês Attribute-aware Orthogonal Variability Modelo. Em português Modelo de Variabilidade Ortogonal orientado a Atributos. do inglês Automated Analisys of Variability Models. Em português Análise Automática de Modelos de Variabilidade. do inglês Domain Specific Language. Em português Linguagem de Domínio Específico. do inglês Backus-Naur Formalism. Em português Formalismo de Backus- Naur. do inglês Textual Language Workbench. Em português Language Workbench Textual. do inglês Projectional Language Workbench.

11 Sumário Introdução I REFERENCIAIS TEÓRICOS 15 1 ENGENHARIA DE LINHA DE PRODUTOS DE SOFTWARE Introdução a Linha de Produtos Exemplo de uma Linha de Produtos Processo de Desenvolvimento Modelos de Variabilidade Modelo de Variabilidade Ortogonal OVM Estendido Restrições de Domínio OVM Textual Relationships Attributes Global Attributes Constraints Análise Automática de Modelos de Variabilidade Resumo do Capítulo LINGUAGENS DE DOMÍNIO ESPECÍFICO Introdução a Linguagens de Domínio Específico Gramática Languages Workbenches Xtext Resumo do Capítulo II DESENVOLVIMENTO 35 3 CRIAÇÃO DO EDITOR Estrutura do projeto no Xtext Definição da Gramática Relationships Constraints Attributes

12 3.2.4 Global Attributes Funcionalidades do Editor Definindo a Validação do Editor Validação Automática Validação Customizada Definindo os Nomes de Elementos Definindo a Formatação do Código no Editor Definindo a Coloração de Sintaxe do Código no Editor Definindo o Assistente de Criação de Projetos do Editor Geração do plugin Validação do Editor Resumo do Capítulo FERRAMENTA DE APOIO A ANÁLISE AUTOMÁTICA Produto Eclipse Projeto de Plugin Projeto de Feature Projeto de Feature para a Plataforma Arquivo ovm.product Exportar o Produto Eclipse Customização do Produto Eclipse Interface para a ferramenta FaMa-OVM Resumo do Capítulo Conclusão Referências APÊNDICES 60 APÊNDICE A REPRESENTAÇÕES GRÁFICAS DA GRAMÁTICA DA LINGUAGEM OVM APÊNDICE B MODELOS EM OVM APÊNDICE C INTERFACE DO FAMA-OVM: RESULTADO DA PRO- DUCTS APÊNDICE D MODELO OVM DE UMA LPS MOBILE

13 12 Introdução O ser humano sempre tentou baratear o custo da produção de seus produtos ou bens para que estes fossem vendidos por um preço mais acessível, e assim conquistar o mercado e aumentar a margem de lucro. Porém, esses produtos eram feitos artesanalmente, resultando em baixa produção e poucos lucros. Além disso, o preço dos produtos era mais elevado devido ao tempo de produção. Em 1913, Henry Ford com sua Linha de Produção 1 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 plataforms 2 ) 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 Henry Ford (30/Julho/ /Abril/1947) foi um industrialista Americano, o fundador da Ford Motor Company, e responsável pelo desenvolvimento da técnica de Produção em Massa chamada Linha de Produção ou Linha de Montagem. 2 Plataforma é qualquer base tecnológica na qual outras tecnologias ou processos são construídos (POHL; BöCKLE; LINDEN, 2005)

14 Introdução ). 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

15 Introdução 14 da Interface do framework FaMa-OVM.

16 Parte I Referenciais Teóricos

17 16 1 Engenharia de Linha de Produtos de Software 1.1 Introdução a Linha de Produtos Linhas de Produto de Software (Software Product Line - SPL) é uma abordagem de desenvolvimento de software que propõe a derivação sistemática de produtos de software a partir de um conjunto de componentes e artefatos comuns (CLEMENTS; NORTHROP, 2001). Em outras palavras SPL faz uso do reuso de software para construir sistemas com menos esforço, desde que estes pertençam a uma mesma família, ou seja, que possuam pontos em comum. Entre as principais vantagens da Engenharia de Linhas de Produto de Software (Software Product Line Engineering - SPLE) podem-se destacar o custo de desenvolvimento (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

18 Capítulo 1. Engenharia de Linha de Produtos de Software 17 o de um único produto. Algo semelhante ocorre com relação ao ciclo de desenvolvimento, como se pode ver na Figura 2. Ao princípio, um tempo maior é necessário para se construir os artefatos comuns, depois, com o reuso destes artefatos, o ciclo de desenvolvimento se reduz. Figura 2: Time to market para Sistemas Únicos e Família de Sistemas. 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 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:

19 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 Chamadas,Tela,Básica; Celular,Fazer Chamadas,Tela,Básica,Mídia,MP3; Celular,Fazer Chamadas,Tela,Colorida; Celular,Fazer Chamadas,Tela,Colorida,GPS; Celular,Fazer Chamadas,Tela,Colorida,Mídia,MP3; Celular,Fazer Chamadas,Tela,Colorida,Mídia,MP3,GPS; Celular,Fazer Chamadas,Tela,Alta resolução; Celular,Fazer Chamadas,Tela,Alta resolução,mídia,mp3; Celular,Fazer Chamadas,Tela,Alta resolução,mídia,mp3,câmera; Celular,Fazer Chamadas,Tela,Alta resolução,mídia,câmera; Celular,Fazer Chamadas,Tela,Alta resolução,gps; Celular,Fazer Chamadas,Tela,Alta resolução,mídia,mp3,gps; Celular,Fazer Chamadas,Tela,Alta resolução,mídia,câmera,gps; Celular,Fazer Chamadas,Tela,Alta resolução,mídia,câmera,mp3,gps. Apesar do domínio apresentado ser pequeno, as variações geradas são muitas em comparação ao tamanho do problema. Não é difícil imaginar, a partir disso, que em um domínio mais realista, com muita variabilidade, o gerenciamento manual dos produtos se torna impraticável. A complexidade dessa variabilidade somente pode ser manuseada por meio de uma gestão da variabilidade e o primeiro passo para isso é ter uma notação comum (POHL; BöCKLE; LINDEN, 2005).

20 Capítulo 1. Engenharia de Linha de Produtos de Software 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 Estabelecer uma plataforma de reuso. Definir a comunalidade e variabilidade da SPL. 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. Engenharia de Aplicação 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. 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; LIN- DEN, 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).

21 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

22 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 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 é completa 1 e disjuntiva 2. 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 Em UML2, Completa (Complete) são todas as subclasses já foram especificadas. Não existe mais a possibilidade de outra generalização. 2 Em UML2, Disjuntiva (Disjoint) são as Superclasses só podem se especializar em apenas uma subclasse. É o oposto de Sobreposição (overlapping).

23 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.

24 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 retorna, agora utilizando da notação da OVM para modelar a variabilidade da Linha de Produtos de Celulares. Figura 8: Exemplo de modelo de variabilidade usando OVM. Fonte: Próprio autor. 1.4 OVM Estendido De acordo com Roos-Frantz (ROOS-FRANTZ, 2011), Atributos são propriedades mensuráveis de um artefato, possuindo: name: denota o nome do Atributo que não precisa ser único pois diferentes artefatos podem ter diferentes atributos com o mesmo nome;

25 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).

26 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 [1,1] VP OS name = cost domain = Real value = Windows.cost + Android.cost nullvalue = 0 unit = Monetary unit V Windows V Android name = cost domain = Real value = 0 nullvalue = 0 unit = Monetary unit name = version domain = Real value = [1.6,2.2,2.3,3.0] nullvalue = 1 unit = version number name = cost domain = Real value = 250 nullvalue = 0 unit = Monetary unit 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): Relationships Em Relationships são especificadas as dependências da variabilidade entre Pontos de Variação e Variantes. Exemplos de sintaxes válidas para ambos os elementos são: 1 %Relationships 2 Vp1 : ; 3 [Vp2] : V1 [V2]; 4 Vp3 : [1,1] {V3 V4} V5;

27 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) V [1,1] Windows VP OS V Android name = cost domain = Real value = Windows.cost + Android.cost nullvalue = 0 unit = Monetary unit name = cost domain = Real value = 0 nullvalue = 0 unit = Monetary unit name = version domain = Real value = 2.3 nullvalue = 1 unit = version number If Windows and Windows.version > 6 then Processor.frequency >= 1 and RAM.size >= 256 and FlashMemory.size >= 8 name = cost domain = Real value = 250 nullvalue = 0 unit = Monetary unit name = version domain = Real value = 7 nullvalue = 1 unit = version number V RAM V Processor VP Hardware V V Flash Memory GPS name = cost domain = Real value = RAM.cost + Processor.cost + FlashMemory.cost + GPS.cost nullvalue = 0 unit = Monetary unit name = cost domain Real value = 50 nullvalue = 0 unit = Monetary unit name = cost domain = Real value = 60 nullvalue = 0 unit = Monetary unit name = Cost domain = Real value = 120 nullvalue = 0 unit = Monetary unit name = size domain = Integer value = 8 nullvalue = 0 unit = GB name = frequency domain = Real value = 1.2 nullvalue = 0 unit = GHz If Android then Processor.frequency >= 0.2 and RAM.size >= 128 and FlashMemory.size >= 0.25 requires VP Settings [1,2] V V JavaSupport Screen name = cost domain = Real value = 80 nullvalue = 0 unit = Monetary unit name = resolution domain = Real value = 480x320 nullvalue = 0 unit = width height name = size domain = Integer value = 1024 nullvalue = 0 unit = MB 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 Attributes Em Attributes são especificados os Atributos Básicos e Atributos Derivados. Atributos são definidos na forma de <name>:<domain>,<value>;,<nullvalue>; onde os termos são separados por vírgulas, e linhas terminadas com ponto e vírgula. Segue um exemplo da definição de Atributos: 1 %Attributes 2 V3.Accuracy : [8], 8;, INF;

28 Capítulo 1. Engenharia de Linha de Produtos de Software 27 3 V4.Accuracy : [4], 4;, INF; 4 VP3.Accuracy : [4,8], min(v3.accuracy,v4.accuracy);, INF; 5 V4.Memory : [2], 2;, 0; 6 V5.Memory : [2], 2;, 0; 7 VP3.Memory : Integer [1 to 512], V4.Memory + V5.Memory;, 0; Os elementos delimitadores são o dois-pontos ( : ) que separa o nome do Atributo das demais propriedades. A vírgula (, ) separa as propriedades do Atributo, ou seja, Domínio (domain), Valor (value), Valor Nulo (nullvalue). O ponto-e-vírgula seguido de uma vírgula ( ;, ) indica o fim da propriedade Valor (Value). E o ponto-e-vírgula sozinho indica do fim o Atributo. Na primeira linha, uma tag %Attributes é usada para indicar o começo dos Atributos. O Nome do Atributo (name) é definido por um Elemento seguido de um nome que não precisa ser único. Como visto na linha 2 ( V3.Accuracy ) onde V3 é o 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 ) Global Attributes Em Global Attributes são especificados os Atributos Globais. Possuem a mesma sintaxe que os Atributos com exceção do nome, que agora não leva o Elemento e o ponto, apenas um nome que, este sim, deve ser único. Um exemplo é mostrado abaixo: 1 %GlobalAttributes 2 TotalAccuracy : Integer [1 to 40], VP12.Accuracy * VP13.AccuracyFactor ;, 0; 3 TotalMemory : Integer [1 to 512], VP2.Memory + VP4.Memory + VP5.Memory ;, 0; Constraints Em Constraints são especificadas as relações de exclusão e requisitos entre os Elementos descritos em Relationships. Existem três tipos de restrições entre Pontos de Variação e Variantes, vejamos no exemplo: 1 %Constraints 2 Vp1 REQUIRES Vp2; //VariationPoint REQUIRE ou EXCLUDES VariationPoint 3 V5 EXCLUDES Vp2; //Variant REQUIRE ou EXCLUDES VariationPoint 4 V2 REQUIRES V4 ; //Variant REQUIRE ou EXCLUDES Variant

29 Capítulo 1. Engenharia de Linha de Produtos de Software 28 5 Vp3 EXCLUDES V1 ; //erro de sintaxe A tag %Constraints indica o início da descrição das restrições. Cada Elemento da Variabilidade em Constraints é separado por uma tag que pode ser REQUIRES ou EXCLUDES e finalizado com um ponto-e-vírgula ( ; ). Todo e qualquer Elemento pode se referir a um outro com exceção do Ponto de Variação que não pode ser excluir ou requerer uma Variante, como visto na última linha ( Vp3 EXCLUDES V1 ). 1.7 Análise Automática de Modelos de Variabilidade Analisar Modelos de Variabilidade é uma tarefa suscetível a erros, tediosa e inviável de ser feita manualmente (BENAVIDES, 2007). O framework descrito na 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.

30 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.

31 30 2 Linguagens de Domínio Específico 2.1 Introdução a Linguagens de Domínio Específico Segundo Fowler (FOWLER, 2010), Linguagem de Domínio Específico (Domain Specific Language - DSL) é uma linguagem de programação de computadores de 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 Gramática No contexto da DSL, a gramática é um conjunto de regras que descreve como o texto é transformado em uma Árvore de Sintaxe (Syntax Three). A Gramática define a Sintaxe da linguagem mas não diz nada sobre a Semântica (FOWLER, 2010). De acordo com a Hierarquia de Chomsky, uma gramática pode ser de 4 tipos: Regular, Livre de Contexto, Sensível ao Contexto e Recursivamente Enumerável. As duas primeiras são largamente

32 Capítulo 2. Linguagens de Domínio Específico 31 Figura 14: Exemplos de DSLs gráfica(a) e textual(b). Fonte: (MERKLE, 2010). usadas na descrição de linguagens de programação e na implementação de interpretadores e compiladores, por exemplo, linguagens Livres de Contexto são utilizadas na análise sintática enquanto que linguagens Regulares na análise léxica. Normalmente uma Gramática é escrita em forma de Formalismo de Backus-Naur (Backus-Naur Formalism - BNF). BNF formalmente define a sintaxe de uma linguagem de programação onde cada linha é uma regra de produção que declara um nome seguido de um elemento legal da regra (FOWLER, 2010). Uma especificação BNF é um conjunto de regras de derivação, escritas como: <símbolo> ::= <expressão com símbolos>. BNF está definido na RFC 4234 (Augmented BNF for Syntax Specifications: ABNF ). Um exemplo pode ser visto na 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),

33 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 Eclipse 1 (MERKLE, 2010). Exemplos open-sources são Xtext 2, EMF 3, TEF (Textual Editing Framework) 4, TCS (Textual Concrete Syntax) 5. A maioria dessas ferramentas usa algum tipo de tecnologia de scanner/parser como ANTLR 6 ou RunCC 7 em seu core. Projectional Language Workbench (PLWB): a quantidade dessas ferramentas ainda é pequena porém tende a crescer (MERKLE, 2010). Exemplos são MPS 8, The Intentional Language Workbench 9 e Spoofax 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 ANTLR 11 e suporte a um editor baseado no Eclipse. É neste editor que

34 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.

35 Capítulo 2. Linguagens de Domínio Específico 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.

36 Parte II Desenvolvimento

37 36 3 Criação do Editor As seções a seguir abordarão a criação do editor utilizando a ferramenta de criação de linguagens Xtext. Cada aspecto importante da linguagem será tratado separadamente nas seções subsequentes. As representações gráficas da gramática textual estão no Apê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: 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.

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

39 Capítulo 3. Criação do Editor 38 6 (variant+=variant)* 7 ";"; 8 Cardinality: 9 "[" min=int "," max=int "]" "{" (variant+=variant)* "}"; 10 Variant: 11 name=qualifiedname "[" name=qualifiedname "]"; 12 QualifiedName: 13 ID; Constraints Em Constraints são definidas as restrições entre os elementos. A Parser Rule Constraint faz uso de Cross Reference para fazer uma busca nos elementos já criados em Relationships. Cross Reference é um recurso único do Xtext para declarar links na gramática. A construção desses cross-links não é estabelecida durante a fase de parsing e sim durante a linking phase (XTEXT, 2013). A sintaxe para Cross-References é a segunite: 1 CrossReference : "[" type=typeref (" " ^terminal=crossreferenceableterminal )? "]" ; A regra principal de Constraints pode ser vista da linha 4, onde um Element, que pode ser Variant ou Variation Point (linhas 10 e 11), é chamado a partir de seu nome QualifiedName. Importante notar que o caractere nesse caso não significa "ou" (or) e sim "por" (by). Em seguida chama-se uma regra enum de nome Rule (linhas 12 e 13) que funciona como uma espécie de atalho para regras de tipos de dados com strings. Enums são simples de usar e possuem boa validação (XTEXT, 2013). A OVM estendida suporta a propriedade IMPLIES em um Atributo comparando-o a um número inteiro (linha 5). 1 Constraints: 2 "%Constraints"; 3 Constraint: 4 c1=[element QualifiedName] (rule=rule c2=[element QualifiedName] "IMPLIES" (attribute=[att QualifiedNameAtt]) 5 comparison=comparison num=int) ";"; 6 Att: 7 Attribute GlobalAttribute; 8 enum Comparison: 9 G=">" L="<" GE=">=" LE="<=" E="==" NE="!="; 10 Element: 11 Variant VariationPoint; 12 enum Rule: 13 REQUIRES="REQUIRES" EXCLUDES="EXCLUDES";

40 Capítulo 3. Criação do Editor Attributes Em Attibutes o nome é uma combinação de um Elemento com um Nome como em AttName. O Domain pode conter um número inteiro ou uma coleção dos mesmos, fechados por colchetes ou um range de números tipados (linhas 9 e 10). Já Value pode ser um simples número inteiro, a referência de outro atributo, uma equação ou uma função. Equações são operações entre números e/ou referências de atributos, ambos podem ser encadeados (linhas 17 a 22). Na linha 16, o caractere + diz que no mínimo um atributo deve ser usado. Duas funções podem ser usadas (min e max) que são executadas em N atributos (linhas 15 e 16). Por fim, NullValue pode conter um número inteiro ou duas strings que representam valores infinitos (linhas 13 e 14). 1 Attributes: 2 "%Attributes"; 3 Attribute: 4 name=attname ":" domain=domain "," value=value ";," nullvalue=nullvalue ";"; 5 AttName: 6 element=[element QualifiedName] "." attributename=qualifiedname; 7 QualifiedNameAtt: 8 ID ("." ID)*; 9 Domain: 10 number="[" INT ("," INT)* "]" range="integer" "[" INT "to" INT "]"; 11 Value: 12 number=int attribute=[attribute QualifiedNameAtt] equation=equation function=function; 13 NullValue: 14 INT "INF" "MINF"; 15 Function: 16 "max(" a1=[attribute QualifiedNameAtt] ("," a2+=[attribute QualifiedNameAtt])+ ")" "min("a1=[attribute QualifiedNameAtt] ("," a3+=[attribute QualifiedNameAtt])+ ")"; 17 Equation: 18 (n=int a=[attribute QualifiedNameAtt]) (el2+=el2)+; 19 El2: 20 (o=operator) (n=int a=[attribute QualifiedNameAtt]); 21 enum Operator: 22 SUM="+" SUBTRACTION="-" DIVISION="/" MULTIPLICATION="*"; Global Attributes Em GlobalAttributes a gramática é semelhante a Attributes, com uma única exceção no nome, que agora é uma simples string, fazendo o uso da mesma regra usada anteriormente em Relationships. 1 GlobalAttributes: 2 "%GlobalAttributes";

41 Capítulo 3. Criação do Editor 40 3 GlobalAttribute: 4 name=qualifiedname ":" domain=domain "," value=value ";," nullvalue=nullvalue ";"; 3.3 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 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) 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 2 def checkcardinality(cardinality cardinality) { 3 if (cardinality.variant.size < cardinality.min) { 4 error("cardinality MIN not respected.", OvmPackage.Literals.CARDINALITY MIN); 5 } } 7 def checkvariationpointtovariantconstraint(constraint constraint) { 8 var listarules = (constraint.econtainer() as Model).constraint; 9 if (listarules.size > 0) { 10 for (r_aux : listarules) { 11 if (constraint.c1 instanceof VariationPoint && constraint.c2 instanceof Variant) { 12 error("variation Point cannot REQUIRES or EXCLUDES a Variant.", OvmPackage.Literals.CONSTRAINT C2); 13 return; 14 } else if (constraint.c1.equals(constraint.c2)) { 15 error("a Element cannot REQUIRES or EXCLUDES itself.", OvmPackage.Literals.CONSTRAINT C2);

42 Capítulo 3. Criação do Editor } } } } 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 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 // Xtend-based API for validation 2 fragment = validation.validatorfragment auto-inject { 3 // composedcheck = "org.eclipse.xtext.validation.importurivalidator" 4 composedcheck = "org.eclipse.xtext.validation.namesareuniquevalidator" 5 } 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.

43 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 %Constraints 2 Screen.Basic EXCLUDES Utility.Gps; 3 Media.Camera REQUIRES Screen.High; Depois de descoberto que o método DefaultDeclarativeQualifiedNameProvider poderia ser estendido, contornar essa situação ficou fácil. Criou-se um arquivo OvmQNP.java estendendo a classe já mencionada retornando o nome da Variante apenas com seu v.getname (linhas 11 a 13). 1 QualifiedName qualifiedname(variant v) { 2 return QualifiedName.create(v.getName()); } O outro problema foi na identificação dos atributos, pois possuem nomes compostos de uma referência cruzada, um ponto e um nome. Para resolver esta questão foi preciso fazer uma busca nos nós da árvore de parseamento pelos nomes dos atributos e depois retornar o nome correto ( a.getname().getattributename() ). 1 QualifiedName qualifiedname(attribute a) { 2 if (a.getname()!= null) { 3 List<INode> nodes = NodeModelUtils.findNodesForFeature(a.getName(), OvmPackage.Literals.ATT_NAME ELEMENT); 4 if (nodes.size() > 0) { 5 return QualifiedName.create(nodes.get(0).getText().trim(), a.getname().getattributename()); 6 } 7 } 8 return null; } Após a criação da classe é preciso registra-la como um novo componente para ser usada em tempo de execução. Isto é feito na classe OvmRuntimeModule, como visto no código abaixo. 2 public Class<? extends IQualifiedNameProvider> bindiqualifiednameprovider() { 3 return OvmQNP.class; 4 } Definindo a Formatação do Código no Editor A formatação ou indentação do código é de vital importância para uma leitura e escrita eficaz e ágil. No Xtext, a formatação do código pode ser customizada estendendo o arquivo AbstractDeclarativeFormatter. Um formatter insere, remove ou modifica

44 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 A Figura 20 mostra os caracteres de escape definidos na classe. 1 //tags 2 c.setlinewrap(1).after(variationpointrule) 3 //variation point 4 for (Keyword comma : variationpointaccess.findkeywords(",")) { 5 c.setnospace().around(comma); } 6 //attributes 7 for (pair : functionaccess.findkeywordpairs("max(", ")")) { 8 c.setnospace().after(pair.getfirst()); 9 c.setnospace().before(pair.getsecond()); } 10 //GlobalAttributes 11 for (Keyword dot : globalattributeaccess.findkeywords(".")) { 12 c.setnospace().around(dot)} Figura 20: Editor com detalhes de caracteres escondidos usados na formatação. Fonte: Próprio autor 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-

45 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 1 public static final String VARIATION_POINT = "Variation Point"; 2 public static final String VARIANT = "Variant"; 3 public void configure(ihighlightingconfigurationacceptor acceptor) { 4 addtype(acceptor, VARIATION_POINT, 178, 0, 108, NORMAL); 5 addtype(acceptor, VARIANT, 0, 127, 50, NORMAL); 6 public void addtype(ihighlightingconfigurationacceptor acceptor, String s, int r, int g, int b, int style) { 7 TextStyle textstyle = new TextStyle(); 8 textstyle.setbackgroundcolor(new RGB(255, 255, 255)); 9 textstyle.setcolor(new RGB(r, g, b)); 10 textstyle.setstyle(style); 11 acceptor.acceptdefaulthighlighting(s, s, textstyle); } A segunda parte necessária é a criação da classe que vai percorrer a Árvore de Sintaxe identificando os elementos e colorindo-os. Essa classe foi chamada de OvmHighlightingCalculator e implementa a classe ISemanticHighlightingCalculator sobrescrevendo o método providehighlightingfor. Os elementos que estão em destaque na linguagem são Ponto de Variação, Variante, Tags de separação, Referências cruzadas e Comentários. Interessante é perceber o funcionamento do código, que passa por toda a Árvore de Sintaxe usando um "while" procurando os determinados tipos de elementos e aplicando as cores através do método setstyles. Os três últimos médotos, skipwhitespace, skipwhitespacebackwards e processhiddennode, foram criados para resolver os problemas dos tokens invisíveis, que poderiam ser destacados juntamente com o texto. A classe completa está disponível através do link 1 public void providehighlightingfor(xtextresource resource, IHighlightedPositionAcceptor acceptor) { 2 if (resource == null resource.getparseresult() == null) 3 return; 4 INode root = resource.getparseresult().getrootnode(); 5 BidiTreeIterator<INode> it = root.getastreeiterable().iterator(); 6 while (it.hasnext()) { 7 INode node = it.next(); 8 if (!(node instanceof CompositeNodeWithSemanticElement)) { 9 // VARIATION POINT 10 if (node instanceof CompositeNode && node.getgrammarelement() instanceof RuleCall) {

46 Capítulo 3. Criação do Editor if (node.getsemanticelement() instanceof VariationPoint) { 12 setstyles(acceptor, it, VARIATION_POINT); } } 13 // VARIANT 14 if (node instanceof CompositeNode node instanceof SyntheticCompositeNode && node.getgrammarelement() instanceof RuleCall) { 15 if (node.getsemanticelement() instanceof Variant) { 16 setstyles(acceptor, it, VARIANT); } } 17 } 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 public Class<? extends IHighlightingConfiguration> bindihighlightingconfiguration() { 2 return OvmHighlightingConfiguration.class; } 3 public Class<? extends ISemanticHighlightingCalculator> bindisemantichighlightingcalculator() { 4 return OvmHighlightingCalculator.class; } Figura 21: Editor com Sintax Highlighting (esquerda) e sem (direita). Fonte: Próprio autor 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 // project wizard (optional) 2 fragment = projectwizard.simpleprojectwizardfragment auto-inject { 3 generatorprojectname = "${projectname}" 4 fileextension = fileextensions }

47 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

48 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 estão os arquivos testados. Tabela 2: Testes que esperam um resultado de "Aceito". Teste Descrição Entrada Saída Basic1 Modelo vazio, somente tags. OVM Aceito Basic2 Modelo com Variation Point vazio. OVM Aceito Basic3 Mais de um Variation Point com diferentes Variants. OVM Aceito Constraint1 Todas as Constraints possíveis da sintaxe. OVM Aceito Attribute1 Todos os Attributes possíveis na sintaxe. OVM Aceito Attribute2 Todos os Global Attributes possíveis na sintaxe. OVM 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

49 Capítulo 3. Criação do Editor 48 Tabela 3: Testes que esperam um resultado de "Erro". Teste Descrição Entrada Saída Error1 Erro em Constraints. Um elemento não pode se auto referenciar. OVM Erro Error2 Erro em Cardinality. Cardinalidade mínima não respeitada. OVM Erro Error3 Erro em Variation Points e Variants. Elementos não podem ter mesmo nome. OVM Erro Error4 Erro em Constraints. Ponto de Variação não pode referenciar uma Variante. OVM Erro Error5 Erro em Attributes. Atributos devem ter nomes únicos. OVM Erro Error6 Erro em Global Attributes. Global Atributos devem ter nomes únicos. OVM 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 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 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 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.

50 4 Ferramenta de Apoio a Análise Automática 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 Para isso, há alguns passos a serem seguidos, que serão discutidos nas próximas subseções 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 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".

51 Capítulo 4. Ferramenta de Apoio a Análise Automática 50 Figura 23: Novo Projeto de Plugin no Eclipse. Fonte: Próprio autor. Figura 24: Arquivo MANIFEST.MF. Fonte: Próprio autor.

52 Capítulo 4. Ferramenta de Apoio a Análise Automática 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 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 Exportar o Produto Eclipse Um problema surgiu ao tentar exportar o Produto Eclipse para outras plataformas que não a nativa 1. 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.

53 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: 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 Customização do Produto Eclipse Uma das vantagens de se criar um Produto Eclipse são as possibilidades de customizaçã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.

54 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 logo 2 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.

55 Capítulo 4. Ferramenta de Apoio a Análise Automática 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 MigLayout 3, 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

56 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 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

Engenharia de Linha de Produtos de Software e o Processo de Análise Automática: uma visão geral

Engenharia de Linha de Produtos de Software e o Processo de Análise Automática: uma visão geral Engenharia de Linha de Produtos de Software e o Processo de Análise Automática: uma visão geral Cristiano Politowski - pesquisador Dr. Fabrícia Roos Frantz - orientadora Agenda SPLE Engenharia de Linha

Leia mais

Sintaxe e Semântica. Fases da Compilação. programa fonte

Sintaxe e Semântica. Fases da Compilação. programa fonte Sintaxe e Semântica mleal@inf.puc-rio.br Fases da Compilação programa fonte tokens parse tree árvore anotada ou outra forma intermediária código intermediário código objeto código objeto otimizado scanner

Leia mais

Construção de Compiladores. Construção de Compiladores. Motivação. Motivação. Contexto Histórico. Classificações: Gerações 09/03/2010

Construção de Compiladores. Construção de Compiladores. Motivação. Motivação. Contexto Histórico. Classificações: Gerações 09/03/2010 Construção de Compiladores Prof. Raimundo Santos Moura (http://www.ufpi.br/rsm) Construção de Compiladores Livro-Texto: AHO, Alfred V.; ULLMAN, Jeffrey D.; SETHI, R. Compiladores: princípios, técnicas

Leia mais

Suporte à Engenharia Reversa para o ambiente SEA

Suporte à Engenharia Reversa para o ambiente SEA Otavio Pereira Suporte à Engenharia Reversa para o ambiente SEA Orientador: Ricardo Pereira e Silva Universidade Federal de Santa Catarina - UFSC Departamento de Informática e Estatística - INE Florianópolis

Leia mais

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS RESUMO Este artigo apresenta a especificação de um sistema gerenciador de workflow, o ExPSEE, de acordo com a abordagem de desenvolvimento baseado

Leia mais

Capítulo 1. Introdução. 1.1 Linguagens. OBJETIVOS DO CAPÍTULO Ao final deste capítulo você deverá ser capaz de:

Capítulo 1. Introdução. 1.1 Linguagens. OBJETIVOS DO CAPÍTULO Ao final deste capítulo você deverá ser capaz de: i Sumário 1 Introdução 1 1.1 Linguagens....................................... 1 1.2 O que é um Compilador?................................ 2 1.3 Processadores de Programas: Compiladores, Interpretadores

Leia mais

XML e Banco de Dados. Prof. Daniela Barreiro Claro DCC/IM/UFBA

XML e Banco de Dados. Prof. Daniela Barreiro Claro DCC/IM/UFBA XML e Banco de Dados DCC/IM/UFBA Banco de Dados na Web Armazenamento de dados na Web HTML muito utilizada para formatar e estruturar documentos na Web Não é adequada para especificar dados estruturados

Leia mais

Motivação. Motivação (software) Customização em massa. Outros exemplos de uso de plataformas

Motivação. Motivação (software) Customização em massa. Outros exemplos de uso de plataformas Motivação Introdução a Linhas de Produtos de Software Sérgio Soares scbs@cin.ufpe.br twitter.com/scbs Produtos desenvolvidos manualmente para clientes individuais atendimento as necessidades do cliente

Leia mais

UMA BREVE INTRODUÇÃO AO ESTUDO E IMPLEMENTAÇÃO DE COMPILADORES

UMA BREVE INTRODUÇÃO AO ESTUDO E IMPLEMENTAÇÃO DE COMPILADORES UMA BREVE INTRODUÇÃO AO ESTUDO E IMPLEMENTAÇÃO DE COMPILADORES 1 BRANCO; Guido Aparecido Junior, 2 TAMAE, Rodrigo Yoshio 1-Discente do Curso Sistemas de Informação FAEG/Garça 2-Docente do Curso Sistemas

Leia mais

4 Conversor EDTV Raw. 4.1 Arquitetura

4 Conversor EDTV Raw. 4.1 Arquitetura 4 Conversor EDTV Raw O conversor EDTV Raw é o programa que lê um documento escrito no perfil NCL EDTV e gera um documento Raw equivalente, i.e. que define a mesma apresentação. Este capítulo, apresenta

Leia mais

1/26/2009. Baseadas em http://www.voelter.de/services/mdsdtutorial.html. Experiência pessoal/profissional/acadêmica

1/26/2009. Baseadas em http://www.voelter.de/services/mdsdtutorial.html. Experiência pessoal/profissional/acadêmica Baseadas em http://www.voelter.de/services/mdsdtutorial.html Experiência pessoal/profissional/acadêmica 1 Metamodelo UML Meu Metamodelo Meu processo de negócios Meu processo de negócios Stereotypes Perfis

Leia mais

Compiladores. A seção das regras. Especificação (F)lex. Plano da aula. Escolha das regras. Compilação típica com FLEX

Compiladores. A seção das regras. Especificação (F)lex. Plano da aula. Escolha das regras. Compilação típica com FLEX Compilação típica com FLX Compiladores Análise sintática (1) Noções sobre Gramáticas Livres de conteto dição do teto de especificação No arquivo minhas_regras.l 3 partes: Declarações Regras (Rs -> Ação)

Leia mais

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1.

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1. Modelos de Sistema Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1 Objetivos Explicar por que o contexto de um sistema deve ser modelado como parte do processo de RE Descrever

Leia mais

DESENVOLVIMENTO DE SOFTWARE

DESENVOLVIMENTO DE SOFTWARE VARIAÁ VEL Antes de iniciarmos os comandos referentes a Banco de Dados, precisamos de uma breve descrição técnica sobre Variáveis que serão uma constante em programação seja qual for sua forma de leitura.

Leia mais

Interpretação e Compilação de Linguagens de Programação Sintaxe e Semântica

Interpretação e Compilação de Linguagens de Programação Sintaxe e Semântica Interpretação e Compilação de Linguagens de Programação Sintaxe e Semântica 28 de Fevereiro de 2013 Nesta aula apresentam-se dois dos aspetos fundamentais das linguagens de programação, sintaxe e semântica.

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 3 - MODELAGEM DE SISTEMAS ORIENTADA A OBJETOS COM UML 1. INTRODUÇÃO A partir de 1980, diversos métodos de desenvolvimento de sistemas surgiram para apoiar o paradigma orientado a objetos com uma

Leia mais

SOFTWARE PROCESSES. Ian Sommerville, 8º edição Capítulo 4 Aula de Luiz Eduardo Guarino de Vasconcelos

SOFTWARE PROCESSES. Ian Sommerville, 8º edição Capítulo 4 Aula de Luiz Eduardo Guarino de Vasconcelos SOFTWARE PROCESSES Ian Sommerville, 8º edição Capítulo 4 Aula de Luiz Eduardo Guarino de Vasconcelos Objetivos Introduzir modelos de processo de software Descrever uma variedade de modelos de processo

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem?

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem? UML e Diagramas de Casos de Uso e Classes Prof. Ms. Luiz Alberto Contato: lasf.bel@gmail.com A linguagem UML UML (Unified Modeling Language) Linguagem de Modelagem Unificada É uma linguagem de modelagem

Leia mais

Criando documentação com javadoc

Criando documentação com javadoc H Criando documentação com javadoc H.1 Introdução Neste apêndice, fornecemos uma introdução a javadoc ferramenta utilizada para criar arquivos HTML que documentam o código Java. Essa ferramenta é usada

Leia mais

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Modelagem OO com UML Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Departamento de Informática Centro Tecnológico Universidade Federal do Espírito Santo Modelos Maneira

Leia mais

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS Élysson Mendes Rezende Bacharelando em Sistemas de Informação Bolsista de Iniciação Científica

Leia mais

Princípios de Linhas de Produtos de Software. Prof. Alberto Costa Neto alberto@ufs.br

Princípios de Linhas de Produtos de Software. Prof. Alberto Costa Neto alberto@ufs.br Princípios de Linhas de Produtos de Software Prof. Alberto Costa Neto alberto@ufs.br Surgimento das Linhas de Produtos Inicialmente produtos eram feitos artesanalmente Mas... Nº de pessoas que poderiam

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

Leia mais

A Linguagem de Modelagem Unificada (UML)

A Linguagem de Modelagem Unificada (UML) Aécio Costa A Linguagem de Modelagem Unificada (UML) Percebeu-se a necessidade de um padrão para a modelagem de sistemas, que fosse aceito e utilizado amplamente. Surge a UML (Unified Modeling Language)

Leia mais

WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML

WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML Carlos Henrique Pereira WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML Florianópolis - SC 2007 / 2 Resumo O objetivo deste trabalho é especificar

Leia mais

Linha de Produtos de Software (SPL) em Java: Teoria e Prática

Linha de Produtos de Software (SPL) em Java: Teoria e Prática Linha de Produtos de Software (SPL) em Java: Teoria e Prática Prof. Me. Djan Almeida Santos Prof. Me. Pablo Freire Matos Slides baseados no material elaborado pelos professores: Ingrid Oliveira de Nunes,

Leia mais

Linguagens de programação

Linguagens de programação Prof. André Backes Linguagens de programação Linguagem de Máquina Computador entende apenas pulsos elétricos Presença ou não de pulso 1 ou 0 Tudo no computador deve ser descrito em termos de 1 s ou 0 s

Leia mais

Conceitos de Linguagens de Programação

Conceitos de Linguagens de Programação Conceitos de Linguagens de Programação Aula 07 Nomes, Vinculações, Escopos e Tipos de Dados Edirlei Soares de Lima Introdução Linguagens de programação imperativas são abstrações

Leia mais

Java Como Programar, 8/E

Java Como Programar, 8/E Capítulo 2 Introdução aos aplicativos Java Java Como Programar, 8/E (C) 2010 Pearson Education, Inc. Todos os 2.1 Introdução Programação de aplicativo Java. Utilize as ferramentas do JDK para compilar

Leia mais

Arquitetura Orientado por Modelos aplicada a Linha de Produto de Software. Eduardo Barbosa da Costa

Arquitetura Orientado por Modelos aplicada a Linha de Produto de Software. Eduardo Barbosa da Costa Arquitetura Orientado por Modelos aplicada a Linha de Produto de Software Eduardo Barbosa da Costa Juiz de Fora, MG Julho de 2008 Arquitetura Orientado por Modelos aplicada a Linha de Produto de Software

Leia mais

Agenda da Aula. Resumo dos Padrões (Aula 4) Padrões Arquiteturais. Arquitetura Cliente-Servidor. Arquitetura Cliente-Servidor

Agenda da Aula. Resumo dos Padrões (Aula 4) Padrões Arquiteturais. Arquitetura Cliente-Servidor. Arquitetura Cliente-Servidor Reuso de Software Aula 05 Agenda da Aula Linha de Produtos de Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo reuso.software@gmail.com 19 Março 2012 Padrões arquiteturais Cliente-Servidor

Leia mais

Introdução à Engenharia de Software

Introdução à Engenharia de Software Introdução à Engenharia de Software Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Imagem Clássica Objetivo da aula Depois desta aula você terá uma visão sobre o que é a engenharia

Leia mais

BCValidador VALIDAÇÃO DE ARQUIVOS XML RECEBIDOS PELO BANCO CENTRAL DO BRASIL

BCValidador VALIDAÇÃO DE ARQUIVOS XML RECEBIDOS PELO BANCO CENTRAL DO BRASIL BCValidador VALIDAÇÃO DE ARQUIVOS XML RECEBIDOS PELO BANCO CENTRAL DO BRASIL Deinf/Dine4 Versão 1.3 20/05/2013 Histórico de Revisão Data Versão Descrição Autor 06/11/2007 1.0 Elaboração da primeira versão

Leia mais

Linguagem e Técnicas de Programação I Programação estruturada e fundamentos da linguagem C

Linguagem e Técnicas de Programação I Programação estruturada e fundamentos da linguagem C Linguagem e Técnicas de Programação I Programação estruturada e fundamentos da linguagem C Prof. MSc. Hugo Souza Material desenvolvido por: Profa. Ameliara Freire Continuando as aulas sobre os fundamentos

Leia mais

Introdução à Programação de Computadores

Introdução à Programação de Computadores 1. Objetivos Introdução à Programação de Computadores Nesta seção, vamos discutir os componentes básicos de um computador, tanto em relação a hardware como a software. Também veremos uma pequena introdução

Leia mais

Descrição Formal de Linguagens -Sumário - Descrição Formal de Linguagens. -Overview- -Overview- - Fundamentos das Linguagens de Programação -

Descrição Formal de Linguagens -Sumário - Descrição Formal de Linguagens. -Overview- -Overview- - Fundamentos das Linguagens de Programação - Descrição Formal de Linguagens Linguagens de Programação Ciência da Computação DIN UEM CTC Prof. Jucimar Aula 4 Descrição Formal de Linguagens -Sumário - 1. Fundamentos de Linguagens de Programação 2.

Leia mais

Conectando Bancos de Dados Microsoft Access no BrOffice.org Base. fornecido pelo Projeto de Documentação do BrOffice.org

Conectando Bancos de Dados Microsoft Access no BrOffice.org Base. fornecido pelo Projeto de Documentação do BrOffice.org Conectando Bancos de Dados Microsoft Access no BrOffice.org Base fornecido pelo Projeto de Documentação do BrOffice.org Índice 1 Introdução...2 1.1 Versão... 2 1.2 Licenciamento...2 1.3 Mensagem do Projeto

Leia mais

Minicurso do Simpósio Brasileiro de Engenharia de Software - SBES 2009 - Sérgio Soares

Minicurso do Simpósio Brasileiro de Engenharia de Software - SBES 2009 - Sérgio Soares Objetivos Introdução a Linhas de Produtos de Software Sérgio Soares scbs@cin.ufpe.br Introduzir os principais conceitos de Linhas de Produtos de Software Apresentar exemplos de Linhas de Produtos de Software

Leia mais

Software product lines. Paulo Borba Informatics Center Federal University of Pernambuco

Software product lines. Paulo Borba Informatics Center Federal University of Pernambuco Software product lines Paulo Borba Informatics Center Federal University of Pernambuco Software product lines basic concepts Paulo Borba Informatics Center Federal University of Pernambuco Um produto www.usm.maine.edu

Leia mais

Processo de Desenvolvimento de Software Linhas de Produtos de Software

Processo de Desenvolvimento de Software Linhas de Produtos de Software Processo de Desenvolvimento de Software Linhas de Produtos de Software Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte Departamento Acadêmico de Gestão e Tecnologia da Informação

Leia mais

Introdução ao C# . Visão geral do.net Framework

Introdução ao C# . Visão geral do.net Framework Introdução ao C# Microsoft.NET (comumente conhecido por.net Framework - em inglês: dotnet) é uma iniciativa da empresa Microsoft, que visa uma plataforma única para desenvolvimento e execução de sistemas

Leia mais

Uma Abordagem de Engenharia de Requisitos Para Linhas de Produtos de Software

Uma Abordagem de Engenharia de Requisitos Para Linhas de Produtos de Software Uma Abordagem de Engenharia de Requisitos Para Linhas de Produtos de Software Gabriela Guedes de Souza, Jaelson Castro e Carla Silva ggs@cin.ufpe.br, jbc@cin.ufpe.br, carla@dce.ufpb.br DEPARTAMENTO DE

Leia mais

Algoritmos e Estrutura de Dados. Introdução a Linguagem Python (Parte I) Prof. Tiago A. E. Ferreira

Algoritmos e Estrutura de Dados. Introdução a Linguagem Python (Parte I) Prof. Tiago A. E. Ferreira Algoritmos e Estrutura de Dados Aula 1 Introdução a Linguagem Python (Parte I) Prof. Tiago A. E. Ferreira Linguagem a ser Utilizada? Nossa disciplina é de Algoritmos e Estrutura de Dados, e não de linguagem

Leia mais

3. PARADIGMA ORIENTADO A OBJETOS

3. PARADIGMA ORIENTADO A OBJETOS Paradigmas de Linguagens I 1 3. PARADIGMA ORIENTADO A OBJETOS Este paradigma é o que mais reflete os problemas atuais. Linguagens orientada a objetos (OO) são projetadas para implementar diretamente a

Leia mais

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Itana M. S. Gimenes 1 itana@din.uem.br Fabrício R. Lazilha 2 fabricio@cesumar.br Edson A. O. Junior

Leia mais

Além da correção ortográfica nos editores de textos livres

Além da correção ortográfica nos editores de textos livres Além da correção ortográfica nos editores de textos livres William D. Colen M. Silva (colen@users.sourceforge.net) Eng. Computação pela Escola Politécnica da USP (2006) Mestrando Ciência da Computação

Leia mais

Sistemas Baseados em Regras. Profa. Patrícia Dockhorn Costa pdcosta@inf.ufes.br www.inf.ufes.br/~pdcosta/ensino

Sistemas Baseados em Regras. Profa. Patrícia Dockhorn Costa pdcosta@inf.ufes.br www.inf.ufes.br/~pdcosta/ensino Sistemas Baseados em Regras Aula3: Drools Profa. Patrícia Dockhorn Costa pdcosta@inf.ufes.br www.inf.ufes.br/~pdcosta/ensino Drools Business Logic integration Platform Plataforma integrada para gerenciamento

Leia mais

Análise da Arquitetura de Software

Análise da Arquitetura de Software Análise da Arquitetura de Software Essencial para Arquitetura de Software De que se trata o artigo? Apresenta o uso de requisitos arquiteturais na análise da arquitetura de software e a destaca no desenvolvimento

Leia mais

Tabela de Símbolos. Análise Semântica A Tabela de Símbolos. Principais Operações. Estrutura da Tabela de Símbolos. Declarações 11/6/2008

Tabela de Símbolos. Análise Semântica A Tabela de Símbolos. Principais Operações. Estrutura da Tabela de Símbolos. Declarações 11/6/2008 Tabela de Símbolos Análise Semântica A Tabela de Símbolos Fabiano Baldo Após a árvore de derivação, a tabela de símbolos é o principal atributo herdado em um compilador. É possível, mas não necessário,

Leia mais

Objetivos. Conteúdo Programático. Parte 1. Parte 2. Parte 3. UNIFACS - Especialização em Engenharia de Software

Objetivos. Conteúdo Programático. Parte 1. Parte 2. Parte 3. UNIFACS - Especialização em Engenharia de Software Especialização em Engenharia de Software Linhas de Produto de Software Parte 1 Sérgio Soares DSC UPE sergio@dsc.upe.br Objetivos Introduzir os principais conceitos de Linhas de Produto de Software Apresentar

Leia mais

GUIA DE INSTALAÇÃO. Plataforma Windows. Relatório Técnico Versão 0.1 (201305032030) Leandro Gomes da Silva, Tiago França Melo de Lima

GUIA DE INSTALAÇÃO. Plataforma Windows. Relatório Técnico Versão 0.1 (201305032030) Leandro Gomes da Silva, Tiago França Melo de Lima Laboratório de Engenharia e Desenvolvimento de Sistemas LEDS/UFOP Universidade Federal de Ouro Preto UFOP GUIA DE INSTALAÇÃO Plataforma Windows Relatório Técnico Versão 0.1 (201305032030) Leandro Gomes

Leia mais

UML Unified Modeling Language

UML Unified Modeling Language UML Unified Modeling Language Linguagem de Modelagem Unificada A linguagem UML UML (Unified Modeling Language) Linguagem de Modelagem Unificada É uma linguagem para especificação, É uma linguagem para

Leia mais

5 Um Modelo Generativo Orientado a Aspectos

5 Um Modelo Generativo Orientado a Aspectos 71 5 Um Modelo Generativo Orientado a Aspectos Nesse capítulo é apresentado um modelo generativo orientado a aspectos que é usado para instanciação de variabilidades OO e OA encontradas em arquiteturas

Leia mais

Tutorial GMF (Graphical Modeling Framework)

Tutorial GMF (Graphical Modeling Framework) Tutorial GMF (Graphical Modeling Framework) Sobre o GMF: O GMF (Graphical Modeling Framework) é um framework para desenvolvimento de editores gráficos para modelos de domínio. Ele surgiu de uma união de

Leia mais

Engenharia de Domínio baseada na Reengenharia de Sistemas Legados

Engenharia de Domínio baseada na Reengenharia de Sistemas Legados 1021 X Salão de Iniciação Científica PUCRS Engenharia de Domínio baseada na Reengenharia de Sistemas Legados Cássia Zottis¹, Profa. Dra. Ana Paula Terra Bacelo 1 (orientadora) 1 Faculdade de Informática,

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Capítulo 3 Processos de Software Slides do Livro do Sommerville, 2000 Disponíveis em inglês em www.software-engin.com Traduzidos por Jacinta Pereira Graduando do Curso de Letras

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

Descrição Geral da Mobile Media

Descrição Geral da Mobile Media Descrição Geral da Mobile Media Mobile Media (YOUNG, 2005) é uma LPS composta por aplicações que manipulam músicas, vídeos e fotos para dispositivos móveis, como celulares e palm tops. Ela provê suporte

Leia mais

CONVENÇÃO DE CÓDIGO JAVA

CONVENÇÃO DE CÓDIGO JAVA CONVENÇÃO DE CÓDIGO JAVA Eligiane Ceron - Abril de 2012 Versão 1.0 Conteúdo Considerações iniciais... 2 Introdução... 2 Extensão de arquivos... 2 Arquivos de código Java... 2 Comentários iniciais... 2

Leia mais

1. IBM Rational Software Modeler

1. IBM Rational Software Modeler Sumário 1. IBM Rational Software Modeler... 1 2. Criando o Perfil GeoProfile... 2 3. Adicionando Restrições OCL... 9 4. Adicionando Ícones aos Estereótipos... 13 5. Aplicando o Perfil GeoProfile... 14

Leia mais

JSP - ORIENTADO A OBJETOS

JSP - ORIENTADO A OBJETOS JSP Orientação a Objetos... 2 CLASSE:... 2 MÉTODOS:... 2 Método de Retorno... 2 Método de Execução... 2 Tipos de Dados... 3 Boolean... 3 Float... 3 Integer... 4 String... 4 Array... 4 Primeira:... 4 Segunda:...

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Centro Universitário de Volta Redonda - UniFOA Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro

Leia mais

Transformação de um Modelo de Empresa em Requisitos de Software

Transformação de um Modelo de Empresa em Requisitos de Software Transformação de um Modelo de Empresa em Requisitos de Software Fábio Levy Siqueira 1 and Paulo Sérgio Muniz Silva 2 1 Programa de Educação Continuada da Poli-USP, São Paulo, Brazil 2 Escola Politécnica

Leia mais

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com REVISÃO ENGENHARIA DO SOFTWARE Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Software Sequencia de Instruções a serem seguidas ou executadas Dados e rotinas desenvolvidos por computadores Programas

Leia mais

Padrões de Contagem de Pontos de Função

Padrões de Contagem de Pontos de Função Padrões de Contagem de Pontos de Função Contexto Versão: 1.0.0 Objetivo O propósito deste documento é apresentar os padrões estabelecidos para utilização da técnica de Análise de Pontos de Função no ambiente

Leia mais

Padrões de Codificação Java

Padrões de Codificação Java Padrões de Codificação Java João Carlos Pinheiro jcpinheiro@cefet-ma.br Versão: 1.0 Última Atualização: Março / 2005 1 Objetivos Apresentar os padrões de codificação Java da SUN 2 Introdução Um padrão

Leia mais

EKM Visão Geral. Vinicius Strugata João Aguirre Ricardo Damian

EKM Visão Geral. Vinicius Strugata João Aguirre Ricardo Damian EKM Visão Geral Vinicius Strugata João Aguirre Ricardo Damian EKM 2.0 Desafios na Simulação de Engenharia PAGE 2? Cenário 1: Colaboração Cenário 2: Reutilização Vários analistas trabalhando no mesmo Projeto

Leia mais

4 Criação de macros e introdução à linguagem VBA

4 Criação de macros e introdução à linguagem VBA 4 Criação de macros e introdução à linguagem VBA Vinicius A. de Souza va.vinicius@gmail.com São José dos Campos, 2011. 1 Sumário Tópicos em Microsoft Excel 2007 Introdução à criação de macros...3 Gravação

Leia mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE

CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE Tathiana da Silva Barrére Antonio Francisco do Prado Vitor César Bonafe E-mail: (tathiana,prado,bonafe)@dc.ufscar.br

Leia mais

Características do Software

Características do Software Questionamentos Por que tanta demora para entregar? Por que os prazos se atrasam? Por que os custos são altos? Por que não achar todos os erros antes de entregar? Por que dificuldade em medir o progresso

Leia mais

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ ModeloPlanoProjeto_2007_04_24 SIGECO07_PlanoProjeto_2007_09_23 Página

Leia mais

Usando RDL para Derivação de Produtos em uma Linha de Produtos de Software

Usando RDL para Derivação de Produtos em uma Linha de Produtos de Software Usando RDL para Derivação de Produtos em uma Linha de Produtos de Software Juliano Dantas Santos Universidade Federal do Rio de Janeiro COPPE - Instituto Alberto Luiz Coimbra de Pós-Graduação e Pesquisa

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de software AULA NÚMERO: 08 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos relacionados a modelos e especificações. Nesta aula

Leia mais

MODELAGEM DE UM SUBSISTEMA IMOBILIÁRIO UTILIZANDO LINHAS DE PRODUTO DE SOFTWARE MODELING A REAL ESTATE SUBSYSTEM USING SOFTWARE PRODUCT LINES

MODELAGEM DE UM SUBSISTEMA IMOBILIÁRIO UTILIZANDO LINHAS DE PRODUTO DE SOFTWARE MODELING A REAL ESTATE SUBSYSTEM USING SOFTWARE PRODUCT LINES MODELAGEM DE UM SUBSISTEMA IMOBILIÁRIO UTILIZANDO LINHAS DE PRODUTO DE SOFTWARE MODELING A REAL ESTATE SUBSYSTEM USING SOFTWARE PRODUCT LINES Silvia Ribeiro Mantuani 1 ; Fernando Henrique Campos 2 ; Vinícius

Leia mais

UM FRAMEWORK PARA DESENVOLVIMENTO DE

UM FRAMEWORK PARA DESENVOLVIMENTO DE UNIVERSIDADE FEDERAL DE PERNAMBUCO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE INFORMÁTICA UM FRAMEWORK PARA DESENVOLVIMENTO DE APLICATIVOS EM WINDOWS MOBILE. PROPOSTA DE TRABALHO DE GRADUAÇÃO Aluno:

Leia mais

Programação Elementar de Computadores Jurandy Soares

Programação Elementar de Computadores Jurandy Soares Programação Elementar de Computadores Jurandy Soares Básico de Computadores Computador: dispositivos físicos + programas Dispositivos físicos: hardware Programas: as instruções que dizem aos dispositivos

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Centro de Informática - Universidade Federal de Pernambuco Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville e adaptado pelos professores Márcio Cornélio,

Leia mais

Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Programa de Pós-Graduação em Desenvolvimento de Sistemas para Web

Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Programa de Pós-Graduação em Desenvolvimento de Sistemas para Web Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Programa de Pós-Graduação em Desenvolvimento de Sistemas para Web } Com o forte crescimento do comércio eletrônico por

Leia mais

Um Componente de Gerenciamento de Execução de Workflow Segundo a Abordagem de Linha de Produto de Software

Um Componente de Gerenciamento de Execução de Workflow Segundo a Abordagem de Linha de Produto de Software Um Componente de Gerenciamento de Execução de Workflow Segundo a Abordagem de Linha de Produto de Software Itana M. S. Gimenes 1 itana@din.uem.br Radames J. Halmeman 1 radames@cm.cefetpr.br Fabrício R.

Leia mais

Persistência e Banco de Dados em Jogos Digitais

Persistência e Banco de Dados em Jogos Digitais Persistência e Banco de Dados em Jogos Digitais Prof. Marcos Francisco Pereira da Silva Especialista em Engenharia de Software Jogos Digitais - Computação Gráfica 1 Agenda Vantagens de usar a abordagem

Leia mais

Algoritmos em Javascript

Algoritmos em Javascript Algoritmos em Javascript Sumário Algoritmos 1 O que é um programa? 1 Entrada e Saída de Dados 3 Programando 4 O que é necessário para programar 4 em JavaScript? Variáveis 5 Tipos de Variáveis 6 Arrays

Leia mais

Introdução à Plataforma Eclipse. Leandro Daflon daflon@les.inf.puc-rio.br

Introdução à Plataforma Eclipse. Leandro Daflon daflon@les.inf.puc-rio.br Introdução à Plataforma Eclipse Leandro Daflon daflon@les.inf.puc-rio.br Agenda Introdução Arquitetura da Plataforma Componentes da Plataforma JDT PDE Visão Geral do Projeto Eclipse.org 2 Introdução O

Leia mais

15/03/2010. Análise por pontos de função. Análise por Pontos de Função. Componentes dos Pontos de Função. Componentes dos Pontos de Função

15/03/2010. Análise por pontos de função. Análise por Pontos de Função. Componentes dos Pontos de Função. Componentes dos Pontos de Função Análise por pontos de função Análise por Pontos de Função Referência: Manual de práticas de contagem IFPUG Versão 4.2.1 Técnica que permite medir a funcionalidade de um software ou aplicativo, sob a visão

Leia mais

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software O que é software? Software e Engenharia de Software Programas de computador Entidade abstrata. Ferramentas (mecanismos) pelas quais: exploramos os recursos do hardware. executamos determinadas tarefas

Leia mais

Exame de Qualificação para o Doutorado

Exame de Qualificação para o Doutorado Universidade Federal do Rio de Janeiro Instituto Alberto Luiz Coimbra de Pós-Graduação e Pesquisa de Engenharia Programa de Engenharia de Sistemas e Computação Exame de Qualificação para o Doutorado EVOLMANAGER:

Leia mais

Especificação de um Sistema Gerenciador de Workflow de Acordo com a Abordagem de Desenvolvimento Baseado em Componentes

Especificação de um Sistema Gerenciador de Workflow de Acordo com a Abordagem de Desenvolvimento Baseado em Componentes Especificação de um Sistema Gerenciador de Workflow de Acordo com a Abordagem de Desenvolvimento Baseado em Componentes Edson Alves de Oliveira Junior 1, Itana Maria de Souza Gimenes 1 1 Departamento de

Leia mais

SOA Introdução. SOA Visão Departamental das Organizações

SOA Introdução. SOA Visão Departamental das Organizações 1 Introdução A Organização é a forma pela qual nós coordenamos nossos recursos de todos os tipos para realizar o trabalho que nos propusemos a fazer. A estrutura de nossas organizações manteve-se basicamente

Leia mais

Breve Tutorial de JavaCC

Breve Tutorial de JavaCC Breve Tutorial de JavaCC O que é? Instalação: http://javacc.dev.java.net Exemplos usados de: http://w3.msi.vxu.se/users/jonasl/javacc http://www.cs.nmsu.edu/~rth/cs/cs471/interpretersjavacc.html http://www.engr.mun.ca/~theo/javacc-tutorial/javacc-tutorial.pdf

Leia mais

BSI UFRPE Prof. Gustavo Callou gcallou@gmail.com

BSI UFRPE Prof. Gustavo Callou gcallou@gmail.com BSI UFRPE Prof. Gustavo Callou gcallou@gmail.com HelloWorld.java: public class HelloWorld { public static void main (String[] args) { System.out.println( Hello, World ); } } Identificadores são usados

Leia mais

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE

Leia mais

Concepção e Elaboração

Concepção e Elaboração UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Análise e Projeto Orientado a Objetos Concepção e Elaboração Estudo

Leia mais

AVISO. Treinamento GVcollege Módulo Ficha Complementar

AVISO. Treinamento GVcollege Módulo Ficha Complementar AVISO O conteúdo deste documento é de propriedade intelectual exclusiva da GVDASA Sistemas e está sujeito a alterações sem aviso prévio. Nenhuma parte desta publicação pode ser reproduzida nem transmitida

Leia mais

Guia de Modelagem de Casos de Uso

Guia de Modelagem de Casos de Uso Guia de Modelagem de Casos de Uso Sistema de e-commerce de Ações Versão 1.1 1 Histórico da Revisão. Data Versão Descrição Autor 13 de Setembro de 2008 1.0 Criação do documento Antonio Marques 28 de Setembro

Leia mais

Paradigmas de Programação

Paradigmas de Programação Paradigmas de Programação Tipos de Dados Aula 5 Prof.: Edilberto M. Silva http://www.edilms.eti.br Prof. Edilberto Silva / edilms.eti.br Tipos de Dados Sistema de tipos Tipos de Dados e Domínios Métodos

Leia mais

Compiladores - Análise Preditiva

Compiladores - Análise Preditiva Compiladores - Análise Preditiva Fabio Mascarenhas - 203. http://www.dcc.ufrj.br/~fabiom/comp Wednesday, May 8, 3 Retrocesso Local Podemos definir o processo de construção de um parser recursivo com retrocesso

Leia mais

WXDC: Uma Ferramenta para Imposição e Validação de Restrições de Integridade baseadas na Linguagem XDCL

WXDC: Uma Ferramenta para Imposição e Validação de Restrições de Integridade baseadas na Linguagem XDCL 232 - Encontro Anual de Tecnologia da Informação WXDC: Uma Ferramenta para Imposição e Validação de Restrições de Integridade baseadas na Linguagem XDCL Stevan D. Costa1, Alexandre T. Lazzaretti1, Anubis

Leia mais