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

Orientação a Objetos

Orientação a Objetos 1. Domínio e Aplicação Orientação a Objetos Um domínio é composto pelas entidades, informações e processos relacionados a um determinado contexto. Uma aplicação pode ser desenvolvida para automatizar ou

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

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

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

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

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

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

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

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

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA RESUMO Ricardo Della Libera Marzochi A introdução ao Service Component Architecture (SCA) diz respeito ao estudo dos principais fundamentos

Leia mais

Algoritmos e Programação (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br

Algoritmos e Programação (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br Introdução O computador como ferramenta indispensável: Faz parte das nossas vidas; Por si só não faz nada de útil; Grande capacidade de resolução

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

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

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

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

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador>

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador> FACULDADE DE ENGENHARIA DE COMPUTAÇÃO PROJETO FINAL I e II PLANO DE TRABALHO O Trabalho de Conclusão de Curso (TCC) a ser desenvolvido

Leia mais

Engenharia de Software III

Engenharia de Software III Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,

Leia mais

Lógica de Programação

Lógica de Programação Lógica de Programação Softblue Logic IDE Guia de Instalação www.softblue.com.br Sumário 1 O Ensino da Lógica de Programação... 1 2 A Ferramenta... 1 3 Funcionalidades... 2 4 Instalação... 3 4.1 Windows...

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

Feature-Driven Development

Feature-Driven Development FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por

Leia mais

2 Diagrama de Caso de Uso

2 Diagrama de Caso de Uso Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa

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

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMÁTICA INFORMÁTICA APLICADA

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMÁTICA INFORMÁTICA APLICADA Responda 1) Quem desenvolveu a linguagem C? Quando? 2) Existe alguma norma sobre a sintaxe da linguagem C? 3) Quais são os tipos básicos de dados disponíveis na linguagem C? 4) Quais são as principais

Leia mais

4 O Workflow e a Máquina de Regras

4 O Workflow e a Máquina de Regras 4 O Workflow e a Máquina de Regras O objetivo do workflow e da máquina de regras é definir um conjunto de passos e regras configuráveis. Ao longo de sua execução, um usuário consegue simplificar o seu

Leia mais

PROFESSOR: CRISTIANO MARIOTTI

PROFESSOR: CRISTIANO MARIOTTI PROFESSOR: CRISTIANO MARIOTTI Conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software; Considerado um dos principais mecanismos para se obter software de qualidade

Leia mais

O nome ANT é uma sigla para another neat tool (mais uma ferramenta organizada), segundo seu autor James Duncan Davidson.

O nome ANT é uma sigla para another neat tool (mais uma ferramenta organizada), segundo seu autor James Duncan Davidson. 1- Introdução 1.1- Visão Geral O ANT é uma ferramenta destinada a construção (build) de programas JAVA. É semelhante a ferramentas como make, nmake, jam mas com o diferencial de ser multi-plataforma, pois

Leia mais

Desenvolvendo Websites com PHP

Desenvolvendo Websites com PHP Desenvolvendo Websites com PHP Aprenda a criar Websites dinâmicos e interativos com PHP e bancos de dados Juliano Niederauer 19 Capítulo 1 O que é o PHP? O PHP é uma das linguagens mais utilizadas na Web.

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

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento

Leia mais

Modelagem de Processos. Prof.: Fernando Ascani

Modelagem de Processos. Prof.: Fernando Ascani Modelagem de Processos Prof.: Fernando Ascani Modelagem da arquitetura de negócios Arquitetura Definições Aurélio: Informática: Estrutura e organização lógica de funcionamento de um sistema computacional.

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

Plugins TerraView. Última revisão: 12/12/32006 Versão TerraLib: 3.1.4

Plugins TerraView. Última revisão: 12/12/32006 Versão TerraLib: 3.1.4 Plugins TerraView Última revisão: 12/12/32006 Versão TerraLib: 3.1.4 Requisitos Código completo da TerraLib na estrutura de diretórios sugerida no site da TerraLib 1. Código completo do TerraView na estrutura

Leia mais

TOTVS BA Guia de Customização Linha Logix

TOTVS BA Guia de Customização Linha Logix TOTVS BA Guia de Customização Linha Logix Guia de Customização Sumário Título do documento 1. Objetivo... 3 2. Introdução... 3 3. Customização... 3 2 TOTVS BA Linha Logix Guia de Customização Projeto/Versão:

Leia mais

Sistema de Controle de Solicitação de Desenvolvimento

Sistema de Controle de Solicitação de Desenvolvimento Sistema de Controle de Solicitação de Desenvolvimento Introdução O presente documento descreverá de forma objetiva as principais operações para abertura e consulta de uma solicitação ao Setor de Desenvolvimento

Leia mais

Curso: Ciência da Computação Disciplina: Construção de Compiladores Período: 2010-1 Prof. Dr. Raimundo Moura

Curso: Ciência da Computação Disciplina: Construção de Compiladores Período: 2010-1 Prof. Dr. Raimundo Moura UFPI CCN DIE Curso: Ciência da Computação Disciplina: Construção de Compiladores Período: 2010-1 Prof. Dr. Raimundo Moura O projeto Desenvolver um compilador de um subconjunto básico da linguagem PORTUGOL.

Leia mais

Engenharia de Requisitos Estudo de Caso

Engenharia de Requisitos Estudo de Caso Engenharia de Requisitos Estudo de Caso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 Engenharia de Requisitos Exemplo 1 Reserva de Hotel 1. INTRODUÇÃO Este

Leia mais

5 Mecanismo de seleção de componentes

5 Mecanismo de seleção de componentes Mecanismo de seleção de componentes 50 5 Mecanismo de seleção de componentes O Kaluana Original, apresentado em detalhes no capítulo 3 deste trabalho, é um middleware que facilita a construção de aplicações

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

Dadas a base e a altura de um triangulo, determinar sua área.

Dadas a base e a altura de um triangulo, determinar sua área. Disciplina Lógica de Programação Visual Ana Rita Dutra dos Santos Especialista em Novas Tecnologias aplicadas a Educação Mestranda em Informática aplicada a Educação ana.santos@qi.edu.br Conceitos Preliminares

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

3.1 Definições Uma classe é a descrição de um tipo de objeto.

3.1 Definições Uma classe é a descrição de um tipo de objeto. Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Classes Autoria:Aristófanes Corrêa Silva Adaptação:

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO Santa Maria, 01 de Novembro de 2013. Revisão aula passada Projeto de Arquitetura Decisões de projeto de Arquitetura

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

Projeto de Arquitetura

Projeto de Arquitetura Introdução Projeto de Arquitetura (Cap 11 - Sommerville) UNIVERSIDADE FEDERAL DE ALAGOAS Curso de Ciência da Computação Engenharia de Software I Prof. Rômulo Nunes de Oliveira Até agora, estudamos: Os

Leia mais

Implantação. Prof. Eduardo H. S. Oliveira

Implantação. Prof. Eduardo H. S. Oliveira Visão Geral A implantação de um sistema integrado de gestão envolve uma grande quantidade de tarefas que são realizadas em períodos que variam de alguns meses a alguns anos, e dependem de diversos fatores,

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

PROGRAMAÇÃO ESTRUTURADA. CC 2º Período

PROGRAMAÇÃO ESTRUTURADA. CC 2º Período PROGRAMAÇÃO ESTRUTURADA CC 2º Período PROGRAMAÇÃO ESTRUTURADA Aula 07: Funções O comando return Protótipo de funções O tipo void Arquivos-cabeçalho Escopo de variáveis Passagem de parâmetros por valor

Leia mais

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES Alexandre Egleilton Araújo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil araujo.ale01@gmail.com, jaime@unipar.br Resumo.

Leia mais

Introdução a Computação

Introdução a Computação Introdução a Computação Aula 03 Profissões de TI Prof. MSc. Edilberto Silva edilms@yahoo.com http:// Papéis... Um papel é uma definição abstrata de um conjunto de atividades executadas e dos respectivos

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

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

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

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

AMBIENTE PARA AUXILIAR O DESENVOLVIMENTO DE PROGRAMAS MONOLÍTICOS

AMBIENTE PARA AUXILIAR O DESENVOLVIMENTO DE PROGRAMAS MONOLÍTICOS UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO BACHARELADO AMBIENTE PARA AUXILIAR O DESENVOLVIMENTO DE PROGRAMAS MONOLÍTICOS Orientando: Oliver Mário

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

Resolução da lista de exercícios de casos de uso

Resolução da lista de exercícios de casos de uso Resolução da lista de exercícios de casos de uso 1. Explique quando são criados e utilizados os diagramas de casos de uso no processo de desenvolvimento incremental e iterativo. Na fase de concepção se

Leia mais

LINGUAGEM DE BANCO DE DADOS

LINGUAGEM DE BANCO DE DADOS LINGUAGEM DE BANCO DE DADOS Gabriela Trevisan Bacharel em Sistemas de Informação Universidade Federal do Rio Grande Pós-Graduanda Formação Pedagógica de Professores (FAQI) Conceito de BD Um banco de dados

Leia mais

Gerenciamento de configuração. Gerenciamento de Configuração. Gerenciamento de configuração. Gerenciamento de configuração. Famílias de sistemas

Gerenciamento de configuração. Gerenciamento de Configuração. Gerenciamento de configuração. Gerenciamento de configuração. Famílias de sistemas Gerenciamento de Gerenciamento de Configuração Novas versões de sistemas de software são criadas quando eles: Mudam para máquinas/os diferentes; Oferecem funcionalidade diferente; São configurados para

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

Introdução ao Android

Introdução ao Android Introdução ao Android André Gustavo Duarte de Almeida docente.ifrn.edu.br/andrealmeida Parte 1 Conhecendo o Sistema e Primeiro Programa Roteiro Pré-requisitos Conceitos Básicos Configurando o Ambiente

Leia mais

Guião de Introdução ao Eclipse IDE Índice

Guião de Introdução ao Eclipse IDE Índice Índice 1. Introdução... 2 1.1. O que é um ambiente de desenvolvimento (IDE)?... 2 1.2. Visão geral sobre o Eclipse IDE... 2 2. Iniciar o Eclipse... 3 2.1. Instalação... 3 2.2. Utilizar o Eclipse... 3 3.

Leia mais

Metodologia de Desenvolvimento de Software. Prof. M.Sc. Sílvio Bacalá Jr

Metodologia de Desenvolvimento de Software. Prof. M.Sc. Sílvio Bacalá Jr Metodologia de Desenvolvimento de Software Prof. M.Sc. Sílvio Bacalá Jr Objetivos Discutir aspectos de Engenharia de Software Aplicar um método de desenvolvimento para especificação e projeto de software

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

MC536 Bancos de Dados: Teoria e Prática

MC536 Bancos de Dados: Teoria e Prática Universidade Estadual de Campinas - UNICAMP Instituto de Computação - IC MC536 Bancos de Dados: Teoria e Prática Aula #3 : MER e MER Estendido Profs. Anderson Rocha e André Santanchè Campinas, 1 de Agosto

Leia mais

Descrição do Produto. Altus S. A. 1

Descrição do Produto. Altus S. A. 1 Descrição do Produto O software MasterTool IEC é um ambiente completo de desenvolvimento de aplicações para os controladores programáveis da Série Duo. Esta ferramenta permite a programação e a configuração

Leia mais

SISTEMA TYR DIAGRAMAS DE CLASSE E SEQUÊNCIA Empresa: Academia Universitária

SISTEMA TYR DIAGRAMAS DE CLASSE E SEQUÊNCIA Empresa: Academia Universitária SISTEMA TYR DIAGRAMAS DE CLASSE E SEQUÊNCIA Empresa: Academia Universitária Cascavel Novembro de 2009 Pedro Patitucci Finamore Daniel Bordignon Cassanelli Marco Antonio da Rosa DIAGRAMAS DE CLASSE E SEQUÊNCIA

Leia mais

Algoritmos e Programação Estruturada

Algoritmos e Programação Estruturada Algoritmos e Programação Estruturada Virgínia M. Cardoso Linguagem C Criada por Dennis M. Ritchie e Ken Thompson no Laboratório Bell em 1972. A Linguagem C foi baseada na Linguagem B criada por Thompson.

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Introdução a Engenharia de Requisitos Professor: Ricardo Argenton Ramos Aula 08 Slide 1 Objetivos Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.

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

Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO)

Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO) Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO) Parte: 1 Prof. Cristóvão Cunha Objetivos de aprendizagem

Leia mais

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Cronograma das Aulas. Hoje você está na aula Semana

Leia mais

Desenvolvendo plugins WordPress usando Orientação a Objetos

Desenvolvendo plugins WordPress usando Orientação a Objetos Desenvolvendo plugins WordPress usando Orientação a Objetos por Daniel Antunes danieldeveloper.com @danieldeveloper Introdução Desenvolver plugins WordPress é mais que programar: é obter grandes resultados

Leia mais

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas CMP1132 Processo e qualidade de software II Prof. Me. Elias Ferreira Sala: 402 E Quarta-Feira:

Leia mais

Aplicação Prática de Lua para Web

Aplicação Prática de Lua para Web Aplicação Prática de Lua para Web Aluno: Diego Malone Orientador: Sérgio Lifschitz Introdução A linguagem Lua vem sendo desenvolvida desde 1993 por pesquisadores do Departamento de Informática da PUC-Rio

Leia mais

1. Domínio dos Atributos

1. Domínio dos Atributos Structure Query Language SQL Guilherme Pontes lf.pontes.sites.uol.com.br 1. Domínio dos Atributos Por domínio, ou tipo, pode-se entender como a maneira como determinado atributo (ou campo, se tratando

Leia mais

ISO/IEC 12207: Gerência de Configuração

ISO/IEC 12207: Gerência de Configuração ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que

Leia mais

INTRODUÇÃO ÀS LINGUAGENS DE PROGRAMAÇÃO

INTRODUÇÃO ÀS LINGUAGENS DE PROGRAMAÇÃO Capítulo 1 INTRODUÇÃO ÀS LINGUAGENS DE PROGRAMAÇÃO 1.1 Histórico de Linguagens de Programação Para um computador executar uma dada tarefa é necessário que se informe a ele, de uma maneira clara, como ele

Leia mais

O Primeiro Programa em Visual Studio.net

O Primeiro Programa em Visual Studio.net O Primeiro Programa em Visual Studio.net Já examinamos o primeiro programa escrito em C que servirá de ponto de partida para todos os demais exemplos e exercícios do curso. Agora, aprenderemos como utilizar

Leia mais

Programação Orientada a Objetos com PHP & MySQL Sistema Gerenciador de Banco de Dados: Introdução e configuração de bases de dados com Postgre e MySQL

Programação Orientada a Objetos com PHP & MySQL Sistema Gerenciador de Banco de Dados: Introdução e configuração de bases de dados com Postgre e MySQL Programação Orientada a Objetos com PHP & MySQL Sistema Gerenciador de Banco de Dados: Introdução e configuração de bases de dados com Postgre e MySQL Prof. MSc. Hugo Souza Iniciando nossas aulas sobre

Leia mais

Tutorial de Matlab Francesco Franco

Tutorial de Matlab Francesco Franco Tutorial de Matlab Francesco Franco Matlab é um pacote de software que facilita a inserção de matrizes e vetores, além de facilitar a manipulação deles. A interface segue uma linguagem que é projetada

Leia mais

Aula 01 - Formatações prontas e condicionais. Aula 01 - Formatações prontas e condicionais. Sumário. Formatar como Tabela

Aula 01 - Formatações prontas e condicionais. Aula 01 - Formatações prontas e condicionais. Sumário. Formatar como Tabela Aula 01 - Formatações prontas e Sumário Formatar como Tabela Formatar como Tabela (cont.) Alterando as formatações aplicadas e adicionando novos itens Removendo a formatação de tabela aplicada Formatação

Leia mais

UML Aspectos de projetos em Diagramas de classes

UML Aspectos de projetos em Diagramas de classes UML Aspectos de projetos em Diagramas de classes Após ser definido o contexto da aplicação a ser gerada. Devemos pensar em detalhar o Diagrama de Classes com informações visando uma implementação Orientada

Leia mais

LINGUAGEM C UMA INTRODUÇÃO

LINGUAGEM C UMA INTRODUÇÃO LINGUAGEM C UMA INTRODUÇÃO AULA 1 Conceitos muito básicos 1 Introdução O C nasceu na década de 70. Seu inventor, Dennis Ritchie, implementou-o pela primeira vez usando um DEC PDP-11 rodando o sistema operacional

Leia mais

Wilson Moraes Góes. Novatec

Wilson Moraes Góes. Novatec Wilson Moraes Góes Novatec Copyright 2014 Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo,

Leia mais

Sumário. Uma visão mais clara da UML

Sumário. Uma visão mais clara da UML Instituto Federal de Santa Catarina Câmpus Chapecó Ensino Médio Integrado em Informática Módulo V Unidade Curricular: Engenharia de Software Professora: Lara P. Z. B. Oberderfer Uma visão mais clara da

Leia mais

Microsoft Access: Criar consultas para um novo banco de dados. Vitor Valerio de Souza Campos

Microsoft Access: Criar consultas para um novo banco de dados. Vitor Valerio de Souza Campos Microsoft Access: Criar consultas para um novo banco de Vitor Valerio de Souza Campos Conteúdo do curso Visão geral: consultas são essenciais Lição: inclui sete seções Tarefas práticas sugeridas Teste.

Leia mais

PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br

PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br ROTEIRO 1. Conceitos de Orientação a Objetos Introdução O paradigma da POO Classes

Leia mais

COMPILADORES E INTERPRETADORES

COMPILADORES E INTERPRETADORES Aula 16 Arquitetura de Computadores 12/11/2007 Universidade do Contestado UnC/Mafra Curso Sistemas de Informação Prof. Carlos Guerber COMPILADORES E INTERPRETADORES Um compilador transforma o código fonte

Leia mais

FAÇA FÁCIL: DRIVER IGS PARA COMUNICAÇÃO DE PROTOCOLOS PROPRIETÁRIOS INTRODUÇÃO

FAÇA FÁCIL: DRIVER IGS PARA COMUNICAÇÃO DE PROTOCOLOS PROPRIETÁRIOS INTRODUÇÃO FAÇA FÁCIL: DRIVER IGS PARA COMUNICAÇÃO DE PROTOCOLOS PROPRIETÁRIOS INTRODUÇÃO O Driver IGS possui um módulo de configuração que possibilita a comunicação com protocolos proprietários. Trata-se do Driver

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

Tabela e Gráficos Dinâmicos Como estruturar dinamicamente dados no Excel

Tabela e Gráficos Dinâmicos Como estruturar dinamicamente dados no Excel Tabela e Gráficos Dinâmicos Como estruturar! Para que serve a Tabela e o Gráfico Dinâmico?! Como criar uma Tabela Dinâmica?! Como criar um Gráfico Dinâmico?! Como podemos atualizar dos dados da Tabela

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

INTRODUÇÃO 12. DOCUMENTAÇÃO INTRODUÇÃO INTRODUÇÃO

INTRODUÇÃO 12. DOCUMENTAÇÃO INTRODUÇÃO INTRODUÇÃO INTRODUÇÃO 12. DOCUMENTAÇÃO Na plataforma Java SE 7, há cerca de 4000 classes e interfaces disponíveis para utilizarmos em nossas aplicações Podemos visualizar a documentação dessas classes e interfaces

Leia mais

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio 32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio

Leia mais

Ciclo de Desenvolvimento de Sistemas de BD

Ciclo de Desenvolvimento de Sistemas de BD Gerenciamento de Dados e Informação Fernando Fonseca Ana Carolina Valeria Times Bernadette Loscio Robson Nascimento Ciclo de Desenvolvimento de Sistemas de BD Investigação dos Dados Modelagem dos Dados

Leia mais

Professor: Curso: Disciplina:

Professor: Curso: Disciplina: Professor: Curso: Disciplina: Aula 1 Turma: Esp. Marcos Morais de Sousa Sistemas de informação Engenharia de Software I Dinâmica da disciplina, plano de curso e avaliação 03º semestre Prof. Esp. Marcos

Leia mais