Engenharia de Linguagens

Projecto Integrado - Aulas do 2ºSemestre, 2ªparte

Sumários

02 de Março de 2009

• Modo de funcionamento do Projecto Integrado no 2ºSemestre, 2ªParte.
• Apresentação dos 3 Casos de Estudo que servirão de suporte à disciplina:
  • CS1 (Gestão de Candidaturas de projectos de I&D a financiamento da FCT): neste caso a entidade principal é 'Candidatura' que tem uma 'Equipe' de investigadores que pertencem a 'Instituições Parceiras' e participam num projecto organizado em 'Tarefas' que tem 'Resultados' avaliados em 'Milestones' -- o sistema permite carregar candidaturas, lacrar, avaliar, aprovar, fazer os pagamentos e as medidas de execução, fechar.
  • CS2 (Gestão de Marcação de Consultas numa Clínica Médica): neste caso a entidade central é 'Consulta' que envolve 'Paciente', 'Médico' e 'Ficha Clínica' -- além de manter a informação sobre Médicos e Pacientes, é preciso Marcar Consultas e Registar Episódio Clínico na ficha.
  • CS3 (Sistema para estudo Prosopográfico do Clero Catedralício): aqui a entidade principal, não é uma, são duas. Na 1ªfase é a 'Ficha de Documento' à qual estão associadas as fichas com descrições individuais dos Clérigos; na 2ªfase é a 'Ficha Prosopográfica de cada Clérigo' com as sua referências para as fontes documentais -- neste caso o objectivo, além de carregar e mostrar a informação, é fazer a 'Normalização' das fichas e a 'Fusão' das várias fichas com descrições individuais dos Clérigos na respectiva Ficha Prosopográfica.
• Apresentação do enunciado da componente do projecto integrado, Sistema DRAW, que será trabalhada nesta 2ªparte --- uma linguagem para especificação do Modelo de Dados dreqL:
  • Análise de Requisitos: a linguagem deve permitir definir os Tipos Atómicos (Primitivos, Renomeados, Enumerados), Tipos Estruturados (Set, Seq, Tree, Tuple e Map), Relações implícita ou explicitamente. Além disso, alguns atributos dos campos devem ser especificados (editável, nulo, visível, comprimento máximo, mascarado, chave, auto-increment).
• TPC: a) Criar o Modelo de Dados (UML ou VDM) para os 3 Casos de Estudo; b) terminar a análise de requisitos para dreqL.

09 de Março de 2009

• Recapitulação dos objectivos e modo de funcionamento do Projecto Integrado no 2ºSemestre, 2ªParte.
• Revisão do enunciado da componente do projecto que vai ser trabalhada nesta parte: a linguagem dreqL para descrição da estrutura de dados de uma aplicação e sua integração com a linguagem DRAW.
• Discussão muito detalhada do TPC realizado pelos alunos no sentido de criar um Modelo Lógico (DER ou Diagrama de Classes UML) para os 3 Casos de Estudo que servirão de suporte à disciplina:
  • CS1 (Gestão de Candidaturas de projectos de I&D a financiamento da FCT): apuramento do Modelo proposto por Miguel Esteves (em comparação com o do Sérgio e outros) -- ver Diagrama de Classes Final.
• TPC: terminar os modelos para os 2 outros casos e entregar em papel o 1ºmodelo.

16 de Março de 2009

• Discussão muito detalhada do TPC realizado pelos alunos no sentido de criar um Modelo Lógico (DER ou Diagrama de Classes UML) para os 3 Casos de Estudo que servirão de suporte à disciplina:
  • CS2 (Gestão de Candidaturas de projectos de I&D a financiamento da FCT): apuramento do Modelo final -- ver Diagrama de Classes Final.
  • CS3 (Sistema para estudo Prosopográfico do Clero Catedralício): discussão do modelo inicial e dos conceitos envolvidos.
• Discussão muito calorosa sobre Modelação de Sistemas de Informação; o Modelo Relacional e o DER versus o Modelo Orientado a Objectos e o DClasses.
• TPC: terminar o modelo para o último caso e entregar em papel e em formato electrónico o Diagrama dos 3 Modelos.

23 de Março de 2009

• Discussão muito detalhada do TPC realizado pelos alunos no sentido de criar um Modelo Lógico (DER ou Diagrama de Classes UML) para os 3 Casos de Estudo, já propostos, que servirão de suporte à disciplina:
  • CS3 (Sistema para estudo Prosopográfico do Clero Catedralício): discussão do modelo final; comparação de interpretações e abordagens diversas.
• Apresentação de mais 2 Casos de Estudo que servirão de suporte à disciplina:
  • CS4 (Gestão de Aquisições num Organismo Público): neste caso a entidade principal é 'Ficha de Aquisição', a qual se associa a unidades organicas e produtos, fornecedores e orçamento, de modo a poder-se fazer a sua cabimentação nas rubricas orçamentais e a respectiva autorização de compra.
  • CS5 (Gestão de Correspondência): neste caso a entidade principal é 'Correspondência' estando ligada a 'Funcionarios' de modo a permitir fazer o registo completa de cada correspondencia que chega à institução, identificando o destinatário interno e fazendo os eu tracking até ser arquivada.
• Enquadramento desta componente de PI com o trabalho já feito, em realização e futuro:
  • para o efeito foi revista a Arquitectura geral de uma Aplicação Web do tipo Data-centric, formada por 3 camadas: a camada de interacção (dita o Front-Office do sistema); o repositório de dados (em torno do qual se centram as operações); e a camada intermédia (o Middleware) que estabelece a ligação entre as outras duas camadas.
  • a linguagem DRAW serve para especificar a camada de interacção;
  • para interligação das duas será definida uma outra linguagem, interL, que mapeia os dados da interface com os dados contidos no repositório;
  • a linguagem dreqL surge para especificar o repositório -- sua estrutura e manutenção (ou seja, o conjunto de operações que formam o Back-Office do sistema).
• TPC1: fazer o modelo para os dois novos casos e entregar em papel e em formato electrónico o respectivo Diagrama.
• TPC2: propor uma definição para a linguagem dreqL; apresentar a sua GIC.

30 de Março de 2009

• Discussão muito detalhada do TPC realizado pelos alunos no sentido de criar um Modelo Lógico (DER ou Diagrama de Classes UML) para os 5 Casos de Estudo, já propostos, que servirão de suporte à disciplina:
  • CS4 (Sistema para estudo Gestão de Aquisições num Organismo do Estado): discussão do modelo final; comparação de interpretações e abordagens diversas.
  • CS5 (Sistema para estudo Gestão de Corresondência num Organismo do Estado): discussão do modelo final; comparação de interpretações e abordagens diversas.
• Discussão muito detalhada das propostas para a linguagem dreqL apresentadas por cada grupo; análise da gramática e de frases concretas.
• TPC1: apresentar a versão final da gramática para definição da linguagem dreqL e frases de sua instanciação aplicadas aos 5 Casos de Estudo.

20 de Abril de 2009

• Discussão e avaliação, grupo a grupo, da linguagem dreqL proposta, da sua gramática e parser gerado pelo AnTLR e análise de frases concretas aplicadas a cada um dos 5 Casos de Estudo.
• TPC1: gerar código SQL para Criar as Tabelas de uma Base de Dados que implemente o sistema de informação especificado em dreqL

27 de Abril de 2009

• 1ªetape de avaliação (do 2ºsemestre) do Projecto Integrado: estado de definição das linguagens DRAW e dreqL e de desenvolvimento dos respectivos processadores (geração do código SQL para criação das Tabelas correspondentes ao modelo descrito); aplicação aos Casos de Estudo.

04 de Maio de 2009

• Conclusão da 1ªetape de avaliação (do 2ºsemestre) do Projecto Integrado.
• Início do desenvolvimento do Gerador de Código associado à dreqL para realizar as funções de CRUD.

11 de Maio de 2009

• Não houve aula devido às festividades do Enterro da Gata.

18 de Maio de 2009

• Aula dada pelo JJ.

25 de Maio de 2009

• Discussão e continuação do desenvolvimento do Gerador de Código associado à dreqL para geração das funções em Perl que invocam as instruções SQL para implementar as funções de CRUD (uma função por tabela).

02 de Junho de 2009

• Discussão e continuação do desenvolvimento do Gerador de Código associado à dreqL para geração das funções em Perl que invocam as instruções SQL para implementar as funções de CRUD (uma função por tabela).
• Preparação da 3ªcamada de interacção que vai usar objectos para ligar a descrição DRAW à dreqL oferecendo ao programador uma série de operações e interrogadores de alto nivel (próximo do modelo OO).

Engenharia de Linguagens

Projecto Integrado - Aulas Tecnológicas

Sumários

29 Setembro 2008

• Necessidade de um ambiente de programação eficiente: Editor, linha de comando, linguagem de programação.
• Subversion como sistema de controlo de versões.
  • linha de comando
  • Tortoise SVN
• Linguagens de programação: Interpretadas vs Compiladas.
• Perl:
  • pequeno exercício de análise de HTML com base em expressões regulares.
  • variáveis escalares.
  • estruturas de controlo: aproximação linguística do Perl
  • uso da variável por omissão: o coiso.
• TPC:
  • Alterar a script ex.pl no SVN para ordenar os nomes dos docentes por Apelido. (aprender a usar hashes)
  • Criar um ficheiro por cada docente (aprender a usar ficheiros)

6 Outubro 2008

• Perl by example:
  • parsing de um documento HTML. Problemas de HTML mal formado.
  • armazenamento dos registos extraídos do HTML num array associativo.
  • detalhes de sintaxe relativos ao uso de arrays e arrays associativos: declaração e atribuição.
  • uso de Data::Dumper para análise da estrutura em memória.
  • uso de ficheiros para armazenamento do Data::Dumper.
  • uso do @ARGV para aceder aos argumentos de uma script.
  • uso do comando do para importação de estruturas de dados armazenadas com Data::Dumper;

13 Outubro 2008

• Configuração de uma CGI-BIN no servidor apache;
• Explicação básica de headers HTTP
• Implementação de CGI em Perl:
  • Envio do cabeçalho;
  • Módulo CGI (header, start_html, end_html, start_form, end_form, textfield, textarea, submit)
  • CGI com vários formulários

20 Outubro 2008

• Continuação da implementação da CGI das aulas anteriores;
• Uso de Hashes aninhadas --- discussão sobre referências em Perl;

27 Outubro 2008

• Configuração do cliente CPAN
• Parsing de XML -- XML::DT

3 Novembro 2008

• Parsing de XML com XML::DT -- Herança de atributos
• Geração de Grafos com módulo GraphViz? .

10 Novembro 2008

• Avaliação da Primeira Etapa do Projecto Integrado

17 Novembro 2008

• Criação de Módulos em Perl;
• Uso de Module::Starter;
• Introdução superficial à escrita de testes;

24 Novembro 2008

• Escrita de Parsers em Perl;
• Uso do Text::RewriteRules para escrita de um analisador léxico;
• Uso do Parse::Yapp para escrita de um analisado sintáctico;

15 Dezembro 2008

• Avaliação da Segunda Etapa do Projecto Integrado

5 Janeiro 2009

• Uso de "tie" em Perl (Tie::TextDir)
• Princípios básicos de escrita de um módulo "tie"

Engenharia de Linguagens

PI: Avaliações Periódicas

Engenharia de Linguagens

Etapas do Projecto

As entradas marcadas a vermelho correspondem a avaliações. As restantes correspondem a pontos de controlo, para que possam ter uma ideia do andamento dos vossos projectos.

Sugere-se a visita regular a esta página, já que poderão surgir actualizações/adições de sugestões de implementação.

• 27 de Outubro - Implementação de uma linguagem básica para a representação de grafos (por exemplo, inspirada na do graphviz), e uma ferramenta que gere um conjunto de CGI capazes de navegar sobre este grafo. A implementação desta etapa será iniciada nas aulas de 20 de Outubro.

• 3 de Novembro - Especificação de um conjunto base de tipos (STR, INT, TEXT, FLOAT, DATE, PASSWORD, EMAIL, URL). Adição sobre a linguagem da etapa anterior de parâmetros em cada aresta. Cada estado (CGI) deve mostrar um formulário por acção (aresta) existente. Por exemplo, se do vértice A partem duas arestas, uma com os campos Nome: STR, Morada: TEXT, e uma outra com os campos Nome: STR, Pass: PASSWORD, a CGI referente ao vértice A deverá apresentar dois formulários, um para cada uma das possíveis acções. Depois de escolhida uma acção, o estado de destino dessa aresta deverá imprimir os valores preenchidos no formulário anterior.
  • Sugestão 1: colocar em evidência os campos com nomes iguais, de forma a que sejam partilhados pelos dois formulários.
  • Sugestão 2: procurar módulos de validação/geração de formulários no CPAN como o HTML::FormFu ou o CGI::FormBuilder.
  • Sugestão 3: validar os valores submetidos de acordo com o seu tipo (ver sugestão 2, ou JavaScript).

• 10 de Novembro - Avaliação das etapas anteriores. Esta avaliação será feita das 11h00 em diante.

• 17 de Novembro - Adição de funções de processamento nas arestas do grafo. Estas funções estarão presentes num outro documento Perl (por exemplo num módulo Perl) e serão invocadas sempre que necessário. Assim, cada transição entre estados deixa de conter apenas os parâmetros, mas sim uma assinatura de uma função: nome da função, parâmetros necessários (que correspondem à etapa do dia 3 de Novembro), e o tipo de retorno da função. Quando um utilizador utilizar um formulário, os dados serão usados para invocar a função, e o resultado final será mostrado. Por exemplo: soma(a: INT, b:INT): INT

• 24 de Novembro - Não há garantias que uma função invocada durante a transição entre estados não dê erro. Ou seja, uma função de inserir que, teoricamente, não devolve nada (apenas altera o estado na base de dados) pode dar um erro. Como esta função, qualquer outra pode dar erro. Assim, implicitamente o DRAW deve considerar que todas as funções retornam um "maybe": o tipo especificado se não der erro, ou undef no caso de ter ocorrido um erro. Em caso de erro, a variável especial do Perl $@ será usada para guardar a mensagem de erro. O nodo de destino deverá verificar o retorno da função invocada. Se o valor for undef, a mensagem de erro é mostrada. Caso contrário, é mostrado o resultado de invocar a função.

• 1 de Dezembro - NOTA: Não há aula por ser feriado, mas há trabalho programado! Em caso de dúvidas procurem-nos durante o resto da semana, ou usem e-mail! Uma função não retorna necessariamente um tipo escalar. Por exemplo, uma pesquisa numa base de dados retorna uma lista de registos. Torna-se, pois, imprescindível adicionar tipos estruturados à linguagem DRAW:
  • Tuplo: uma sequência de tipos (básicos, para já!). Por exemplo: ProcuraRegisto(Nome: STR):(Nome: STR, Idade: INT, Morada: STR)
  • Lista: uma sequência homogénea de tipos (básicos ou tuplos). Por exemplo: Alunos():(Nome: STR, Idade: INT)*
  • Os exemplos usam uma sintaxe ilustrativa. Usem a vossa sintaxe!

• 8 de Dezembro - NOTA: Não há aula por ser feriado, mas há trabalho programado! Em caso de dúvidas procurem-nos durante o resto da semana, ou usem e-mail! A framework já deve ser capaz de suportar uma aplicação simples! Implementem uma aplicação simples usando a vossa própria framework. Isso permitirá encontrar erros ou limitações. Alguns exemplos de possíveis aplicações:
  • Lista telefónica: permitir adicionar nomes e números de telefone. Permitir apagar registos, e listar nomes de acordo com um padrão de pesquisa.
  • Dicionário Online: permitir consultar e adicionar palavras e respectivas definições. Permitir alterar a definição. Permitir listar palavras de acordo com um padrão de pesquisa.
  • Mais sugestões com o tempo...

• 15 de Dezembro - Avaliação das etapas anteriores.

• Janeiro - Permitir que em cada transição, para além da invocação de uma função, seja possível propagar variáveis entre estados. Deste modo será possível, por exemplo, que o username de um utilizador introduzido na página de login possa ser propagado por todas as restantes páginas. Note-se que as variáveis propagadas só são mostradas se fizerem parte de um formulário. Os formulários deverão ser preenchidos caso existam definidas variáveis com os nomes dos campos respectivos.

• Fevereiro - Permitir que as funções de transição retornem um tipo especial, chamado 'VARS' que corresponda a uma tabela associativa, que mapeie nomes de variáveis em valores. Isto permitirá, por exemplo, que depois de um formulário em que se peça a chave de uma tabela, seja possível mostrar o formulário para editar o registo da base de dados, preenchendo automaticamente o formulário com os respectivos valores.

• Abril - Definição da linguagem DReqL? , e criação do Parser;

• 27 de Abril - Avaliação!
  • Propagação de variáveis, entre estados e a partir de funções
  • Gerador de código SQL para criação do modelo relacional a partir do DReqL? .

Engenharia de Linguagens

Engenharia Gramatical 2008/09

Exercícios e Exemplos para as aulas

Exemplo 1: Escreva, em notação AnTLR, uma Gramática para uma linguagem que:

• aceite uma Lista de Números;
• gere o respectivo Parser com o AnTLR;
• teste o parser com o Debugger visual do AnTLRWorks;

Acrescente Acções Semânticas (e depois Atributos) para calcular o Comprimento da Lista.

Exemplo 2: Escreva, em notação AnTLR, uma Gramática para a famosa linguagem funcional Lisp(1) que:

• aceite uma Lista de Números;
• gere o respectivo Parser com o AnTLR;
• teste o parser com o Debugger visual do AnTLRWorks;

Acrescente Atributos para:

• calcular a quantidade de números e palavras da lista;
• construir uma lista plana (todos os elementos ao mesmo nível) com os elementos originais associados ao nível a que aparecem;
• verificar que todos os elementos da lista sejam do mesmo tipo do 1ºelemento
• gerar código post-fix(2) como se a SExp fosse calculada numa máquina de stack.

(1) Considere para este exemplo que a gramática de uma Symbolic Expression (na qual assenta a linguagem Lisp) escrita numa notação geral (livre) é:

      T = { num, pal, "(", ")" }
      N = { SExp, SExplist }
      S = SExp
      P = {
            p1: SExp     --> num
            p2: SExp     --> pal
            p3: SExp     --> "(" SExplist ")"
            p4: SExplist --> SExp SExplist
            p5: SExplist --> &
          }

(2) Considere que o código-máquina a gerar (para traduzir as S-Expressions para uma máquina de stack) é uma Linguagem Assembly simples apenas com as 3 instruções seguintes:

    LAB pal   // LABel significa que o operando 'pal' é uma constante 
              // alfanumérica (identificador)
    CONS num  // CONS significa que o operando 'num' é uma constante 
              // numérica
    OPER op   // OPER significa que o operando 'op' é um operador

Para melhor compreender o que se pretende, mostra-se abaixo o resultado de processar duas frases válidas da Linguagem Lisp:

    (defun quad x (mul x x))           
              ==> LAB quad, LAB x, LAB x, LAB x, OPER mul, OPER defun
    (let res (add (mul 1 2)(div 8 4))) 
              ==> LAB res, CONS 1, CONS 2, OPER mul, CONS 8, CONS 4, 
                           OPER div, OPER add, OPER let

Exemplo 3: Nos tempos que correm, a utilização da linguagem SQL (Structured Query Language) é comummente aceite na comunidade informática para a interrogação de bases de dados. São várias as ferramentas que fazem uso desta linguagem: SQL Server, MySQL, Apache Derby, etc.

A gramática da linguagem SQL não é mais do que uma lista de comandos. Pretende-se neste exercício que implemente a gramática da linguagem SQL com pelo menos 4 comandos à sua escolha. Em relação aos comandos escolhidos, pode simplificar a sua sintaxe real, incluindo apenas a parte obrigatória (p.ex., no SELECT pode omitir a parte ORDER-BY ou GROUP-BY).

Depois de implementar a sua gramática, recorrendo ao AnTLR, pretende-se que:

• Construa a Árvore de Sintaxe Abstracta (ASA, ou em inglês AST) utilizando o mecanismo próprio do ANTLR;
• Depois de ter a AST, deverá:
  • construir a Tabela de Identificadores (TabId) constituída pelos nomes das Tabelas e pelos nomes dos Campos
  • gerar uma S-Expr (Lisp) a partir da árvore (uma espécie de pretty-print da AST).

Exemplo 4:

• Análise da Qualidade da Gramática de uma Linguagem para Gestão Científica II (Projectos de Investigação): enunciado

Questões colocadas nas aulas

Q1:

• (2008.09.29) "Explique porque se constata, ao fazer debug visual no AnTLRWorks, que o parser gerado pelo AnTLR é Top-Down?"

Q2:

• (2008.09.29) "O que é preciso acrescentar à Gramática da Lista de Números, do Exemplo 1, para calcular o comprimento da lista (ou contar os seus elementos)?"

Q3:

• (2008.10.06) "Porque é que, após analisar o código produzido pelo ANTLR, se pode afirmar que o Parser gerado é um recursivo-descendente (RD) e não um LL?"

Q4:

• (2008.10.06) "Porque é que a declaração dos atributos numa gramática AnTLR devia ser introduzida pela palavra-reservada 'synthesizes' e não 'returns' ?"

Q5:

• (2008.10.18) Considere a gramática da linguagem Lisp definida na última aula (download aqui) para responder à seguinte questão.
  Substituindo a produção p4: sExpr -> '(' sExpr* ')' por p4: sExpr -> '(' sExpr sExpr+ ')' como procederia ao cálculo do atributo soma?

Q6:

• (2008.10.20) "Porque é que o termo PROPAGAR 'expressa correctamente' o conceito de herança em Gramáticas de Atributos (GAs)?"

Q7:

• (2008.10.27) "Os atributos podem ou não ser calculados de uma forma concorrente?"

Q8:

• (2008.10.27) "Qual o princípio das GAs que um neto não pode herdar directamente de um(a) avô(ó)?"

Q9:

• (2008.10.27) "Qual o inconveniente de alterar código automaticamente gerado?"

Q10:

• (2008.10.27) "Qual a diferença de atitude entre JavaDoc (princípio) e Literate Programming?"

Q11:

• (2008.11.10) "Qual a diferença entre definir o ';' como Parte integrante dum Comando, ou como Terminador de Comando ? e se for como Separador de Comandos ?"

Q12:

• (2008.11.17) "Porque os compiladores actuais e reais não fazem correcção de erros?"

Q13:

• (2008.11.17) "Prove, com o autómato LR(0), a diferença entre as seguintes situações: ';' como terminador e ';' como parte integrante do comando."

Q14:

• (2008.11.24) "Porque é que o compilador não é um processo interactivo?"

Q15:

• (2008.11.24) "Qual o ganho extra que advém do uso de editores sensíveis ao contexto? Diga também qual a diferença entre Editor Sensível ao Contexto e Editor Guiado pela Sintaxe."

Q16:

• (2008.11.24) "Qual a diferença entre um compilador à la Pascal e um compilador à la C no que diz respeito ao tratamento de erros em run-time?"

Q17:

• (2008.12.15) "Porque é que os Editores Dirigidos pela Sintaxe quase não se utilizam actualmente?"

Q18:

• (2008.12.15) "Proponha uma estrutura para construir a Tabela de Identificadores a usar no processamento das Linguagens Orientadas a Objectos."

Q19:

• (2009.01.05) Constrúa o Aut-LR(0) para a gramática (GIC) do Exemplo 4.

Q20:

• (2009.01.05) Aplique todas as Métricas de Tamanho e de Forma já estudadas à GIC da linguagem Lisp (ver Exemplo 2).

Q21:

• (2009.01.26) Explique porque, na prática, se usam 2 gramáticas para a mesma linguagem.

Q22:

• (2009.01.26) Calcule as Métricas Lexicográficas e de Forma para as linguagens C, Pascal e XML, usando as gramáticas disponíveis no UltraGram.

Fichas Práticas para resolver fora das aulas

Ficha I (Data de Entrega: 2008.11.10 --- relatório em Literate Programming)

• Geração de um Processador para Gestão Científica (Teses e Orientadores): enunciado

Ficha II: Faça um relatório detalhado, recorrendo ao Literate Programming, sobre o Exercício 3 descrito acima.

Ficha III (Data de Entrega: 2009.02.05 --- relatório em Literate Programming):

• Pesquise na Internet o que há sobre Métricas para Avaliação da Qualidade em Gramáticas e Linguagens; integre no seu relatório um capítulo específico (mas claro e bem estruturado) sobre o estudo feito.
• Avaliação da Qualidade de Gramáticas; Métricas

Retome a Gramática da DSL GCI apresentada no enunciado da Ficha I e estude a sua qualidade avaliando as Métricas que foram ensinadas nas aulas.

Pretende-se repetir a avaliação da sua qualidade depois de efectuar cada uma das 3 transformações abaixo (as alterações são não-cumulativas, isto é, são independentes e realizadas sempre sobre a gramática original):

• (T1)

• (T2)

    p3:  Pg       -->  IdOrient DescOrientac Periodo

• (T3)

Notas e Links úteis

• AnTLR
• Literate Programming
• Construção de árvores em AnTLR
• Versão do AnTLRworks com suporte de Debug de Tree Grammars

Engenharia de Linguagens

Método de Avaliação

A avaliação da UCE de Engenharia de Linguagens é calculada pela seguinte fórmula:

NF = 15% PED + 15% EG + 15% ATS + 15% PLN + 15% PI1S + 25% PI2S

Legenda:

• NF - Nota final
• PED - Nota do módulo de PED
• EG - Nota do módulo de EG
• ATS - Nota do módulo de ATS
• PLN - Nota do módulo de PLN
• PI1S - Nota do primeiro semestre de Projecto Integrado
• PI2S - Nota final de Projecto Integrado

Requisitos:

• Nota mínima de 9 valores para cada um dos módulos (PED/EG/ATS/PLN)
• Nota mínima de 8 valores na primeira avaliação do Projecto Integrado
• Nota mínima de 10 valores na segunda avaliação do Projecto Integrado

Notas:

• As avaliações de cada módulo poderão ser de cariz prático, teórico ou misto.
• Os pesos e notas mínimas podem ser alterados ligeiramente durante o decorrer do semestre.

Engenharia de Linguagens

Análise e Transformação de Software

• Análise de programas:
  • Extracção de dados
  • Armazenamento da informação recolhida
  • Exploração do conhecimento.
• Transformação de programas:
  • Programação estratégica.
  • Técnicas de Slicing.
  • Especialização de programas e cálculo parcial.
• Paradigmas para visualização de dados e de conhecimento:
  • visualização de informação, de dados e de software.
  • modelos de visualização.
  • visualização/navegação em árvores, grafos, hiper-cubos, petri-nets.
  • visualização/navegação em ontologias.
  • animação de algoritmos.
• Exploração de Ambientes de Trabalho usando os paradigmas explicitados nos items acima.

Resultados de Aprendizagem Específicos

• Capacidade de construir front-ends poderosos para a análise de linguagens de programação (ambíguas ou não).
• Capacidade de desenvolver software como uma tarefa de transformar programas e/ou especificações em implementações eficientes.
• Capacidade de utilizar métricas e técnicas de transformação de programas para optimizar programas (e.g. cálculo parcial, detecção de código morto), efectuar debugging de programas (e.g. slicing), melhorar a estrutura dos programas (e.g. refactoring).
• Capacidade de definir testes para software e testar automaticamente programas em diferentes linguagens de programação.
• Capacidade para criar representações visuais adequadas à compreensão clara do conhecimento complexo detido.

Engenharia de Linguagens

Resultados de Avaliação

Engenharia de Linguagens

Análise e Transformação de Software

Sumários

02 de Março de 2009

• I.1 Introdução e Motivação para a área de Análise e Transformação de SW; sua inserção no contexto da Engenharia de Software:
  • noção de análise de código-fonte (outras hipóteses para análise de código intermédio ou máquina);
  • avaliação do software analisado -- métricas;
  • transformação como meio para melhorar o software avaliado.
• I.2 As quatro grandes componentes envolvidas na disciplina:
  • extracção de informação do código (fase de análise);
  • armazenamento da informação extraída;
  • visualização (paradigmas/exemplos);
  • transformação.
• P.1 Resolução do Exemplo 1:
  • análise do enunciado; estudo da meta-gramática do AnTLR proposta.

09 de Março de 2009

• I.3 Recapitulação dos objectivos da disciplina:
  • Revisão dos principais conceitos ligados à Análise de Código, tomando como motivação a Comprensão de Programas (necessária à sua Manutenção, Re-utilização e Certificação):
    • Extracção nao-invasiva, estática vs Extracção invasiva, dinâmica.
    • Resultados da Extração e da Exploração do Conhecimento (Métricas).
• P.1 Resolução do Exemplo 1 (cont.):
  • análise do enunciado; estudo da meta-gramática do AnTLR proposta; inicio da implementação de um Analisador muito básico.
• TPC: terminar a escrita da 1ªfase do graAl, sistema para Análise de Gramáticas.

16 de Março de 2009

• I.4 Recapitulação dos objectivos da disciplina:
  • Revisão dos principais conceitos ligados à Análise de Código e à Comprensão de Programas, extrapolando agora as ideias para a Compreensão e Avaliação de Documentos Anotados em XML:
    • Apresentação do Sistema para Análise de Documentos eXVisXML; os conceitos de extração de informação, Visualização, Slicing e Métricas subjacentes; as funcionalidades implementadas.
• P.1 Resolução do Exemplo 1 (cont.) -- O Analisador de Gramáticas graAl:
  • estudo detalhado das duas abordagens mais avançadas, apresentadas:
    • pelo Hélder (para cálculo de várias Métricas, com base em atributos H/S, um para cada métrica);
    • pelo César (para desenho do Grafo de Dependências, com base na construção de uma Tabela de Identificadores que recolhe toda a informação extraída durante o parsing da gramática).
• TPC1: terminar a escrita da fase de análise do graAl.
• TPC2: responder às seguintes questões Q1 e Q2 sobre o eXVixXML (a apresentação está disponível aqui).

23 de Março de 2009

• P.1 Resolução do Exemplo 1 (cont.) -- O Analisador de Gramáticas graAl:
  • estudo detalhado das abordagens seguidas por alguns dos grupos.
  • apresentação e discussão do sistema genérico para análise de gramáticas a partir de XAGra em desenvolvimento por Sérgio e Hugo Areias.
• TPC1: terminar a escrita da fase de análise do graAl.
• TPC2: responder à seguinte questão Q1 e Q2 sobre o eXVixXML.

30 de Março de 2009

• P.1 Resolução do Exemplo 1 (cont.) -- O Analisador de Gramáticas graAl:
  • estudo detalhado das abordagens seguidas pelos vários grupos.
• TPC1: terminar a escrita da fase de análise do graAl relativa às restantes métricas e pensar na transformação conducente à optimização da gramática

20 de Abril de 2009

• A Aula desta semana foi totalmente dedicada a avançar com o Projecto Integrado (processamento da Linguagem dreqL com vista à geração de código SQL).

27 de Abril de 2009

• P.1 Resolução do Exemplo 1 (cont.) -- O Analisador de Gramáticas graAl:
  • conclusão da 1ªetape (construção da Tabela de Identificadores, do Grafo de Dependências entre Símbolos e das Métricas de Tamanho e Forma): avaliação do trabalho desenvolvido pelos vários grupos.
• Introdução ao Slicing (Backward vs Forward, Estático vs Dinâmico); critério de Slicing.
• Slicing de Gramáticas.

04 de Maiode 2009

• P.1-f2 Exemplo 1 - fase2 -- extensão do Analisador de Gramáticas graAl para suportar o slicing de Gramáticas a partir de um dado símbolo:
  • discussão dos resultados atingidos pelos grupos para o caso de BW slicing (visualização em formato texto corrido e por coloração de caminhos sobre o Grafo de Dependências).
• Slicing de Gramáticas com Atributos e suas regras de cálculo.

11 de Maio de 2009

• Não houve aula devido às festividades do Enterro da Gata.

18 de Maio de 2009

• Aula dada por JJ.

25 de Maio de 2009

• P.1-f2 Exemplo 1 - fase2 -- extensão do Analisador de Gramáticas graAl para suportar o slicing de Gramáticas a partir de um dado símbolo:
  • discussão dos resultados atingidos pelos grupos para o caso de BW slicing (visualização em formato texto corrido e por coloração de caminhos sobre o Grafo de Dependências), no caso do FW slicing e do slicing de Gramáticas com Atributos e suas regras de cálculo.
  • proposta de nova extensão do graAl com a capacidade para transformar uma dada gramática eliminando produções inuteis e normalizando a recursividade.

02 de Junho de 2009

• P.1-f2 Exemplo 1 - fase2 -- "grammar refactoring":
  • Extensão do graAl com a capacidade para transformar uma dada gramática eliminando produções inuteis e normalizando a recursividade; discussão dos resultados atingidos pelos grupos que já implementaram tal funcionalidade.
• Discussão sobre a data e o formato da avaliação
• Construção de uma artigo colectivo (para enviar à CoRTA'2009) sobre o graAl.

Unidade Curricular de Especialização

Engenharia de Linguagens (2008/2009)

• Edições Anteriores: 2007/2008
• Responsável pela UCE: Pedro Rangel Henriques
• Horários: Primeiro Semestre, Segundo Semestre
• Inscritos: Alunos/Grupos
• Avaliação: Método de Avaliação, Resultados de Avaliação

Novidades

• 2009-07-13 - Defesa oral e apresentação dos trabalhos de ATS e PI.
• 2009-07-08 - Entrega dos relatórios (em papel) referentes aos trabalhos de ATS e PI.
• 2009-03-23 - Aula de PLN de 4 de Maio será dada por três membros da Porto Editora, e será sobre criação de ferramentas e dicionários para análise morfológica.
• 2008-10-20 - Primeiras Etapas do Projecto
• 2008-09-29 - Primeira semana de aulas;
• 2008-08-29 - Adicionado programa básico para aulas tecnológicas de PI e alguma bibliografia;
• 2008-07-09 - Criada a Web para a edição de 2008/2009;

Módulos

• Engenharia Gramatical
  • Responsável: Pedro Rangel Henriques
  • Programa
  • Sumários
  • Questões, Fichas Práticas e Notas
  • Avaliação Final?

• Processamento Estruturado de Documentos
  • Responsável: José Carlos Ramalho

• Análise e Transformação de Software
  • Responsável: Pedro Rangel Henriques
  • Programa
  • Sumários
  • Questões, Fichas Práticas e Notas
  • Avaliação Final?

• Scripting no Processamento de Linguagem Natural
  • Responsável: José João Almeida

• Projecto Integrado
  • Responsável: Alberto Simões
  • Sumários Primeiro Semestre:
    • Aulas Tecnológicas: Sumários
    • Aulas de Gestão: Sumários
  • Sumários Segundo Semestre:
    • Aulas da Manhã: Sumários
    • Aulas da Tarde: Sumários
  • Enunciado PI: el08pi.pdf
  • Etapas do Projecto
  • Avaliações Periódicas

Material Didáctico

• Bibliografia sobre Scripting
• Material sobre LaTeX: (apresentação do workshop; livro sobre o LaTeX? em pt; alguns exercícios)
• GraphViz em XP

Education/EL0809 Web Utilities

• Education/EL0809 Web
• Create New Topic
• Index
• Search
• Changes
• Notifications
• Statistics
• Preferences

• Main Webs

•  DI
•  EL
•  Education
•  Events
•  JoseLuisSilva
•  Personal
•  Research

Education/EL0809 Web Preferences

The following settings are web preferences of the Education.EL0809 web. These preferences overwrite the site-level preferences in TWiki.TWikiPreferences and Main.TWikiPreferences, and can be overwritten by user preferences (your personal topic, eg: TWikiGuest in the Main web).

Web Preferences Settings

These settings override the defaults for this web only. See full list of defaults with explanation. Many of the settings below are commented out. Remove the # sign to enable a local customisation.

• List of topics of the Education/EL0809 web:
  • #Set WEBTOPICLIST = Changes | Index | Search | Go

• Web-specific background color: (Pick a lighter one of the StandardColors).
  • Set WEBBGCOLOR = #D0D0D0
  • Note: This setting is automatically configured when you create a web

• Image, URL and alternate tooltip text of web's logo.
  Note: Don't add your own local logos to the TWikiLogos topic; create your own logos topic instead.
  • #Set WEBLOGOIMG = /twiki/pub/Main/LocalLogos/um_eengP.jpg
  • Set WEBLOGOURL = http://www.di.uminho.pt/
  • #Set WEBLOGOALT = DIUM

• List this web in the SiteMap. If you want the web listed, then set SITEMAPLIST to on, do not set NOSEARCHALL, and add the "what" and "use to..." description for the site map. Use links that include the name of the web, i.e. Education/EL0809.Topic links.
  Note: Unlike other variables, the setting of SITEMAPLIST is not inherited from parent webs. It has to be set in every web that is to be listed in the SiteMap
  
  • Set SITEMAPLIST = on
  • Set SITEMAPWHAT =
  • Set SITEMAPUSETO = Engenharia de Linguagens
  • Note: Above settings are automatically configured when you create a web

• Exclude web from a web="all" search: (Set to on for hidden webs).
  • Set NOSEARCHALL =
  • Note: This setting is automatically configured when you create a web

• Prevent automatic linking of WikiWords and acronyms (if set to on); link WikiWords (if empty); can be overwritten by web preferences:
  • #Set NOAUTOLINK =
  • Note: You can still use the [[...][...]] syntax to link topics if you disabled WikiWord linking. The <noautolink> ... </noautolink> syntax can be used to prevents links within a block of text.

• Default template for new topics for this web:
  • WebTopicEditTemplate: Default template for new topics in this web. (Site-level is used if topic does not exist)
  • TWiki.WebTopicEditTemplate: Site-level default topic template

• Comma separated list of forms that can be attached to topics in this web. See TWikiForms for more information.
  • Set WEBFORMS =

• Users or groups who are not / are allowed to view / change / rename topics in the Education/EL0809 web: (See TWikiAccessControl). Remove the # to enable any of these settings. Remember that an empty setting is a valid setting; setting DENYWEBVIEW to nothing means that anyone can view the web.
  • #Set DENYWEBVIEW =
  • #Set ALLOWWEBVIEW =
  • #Set DENYWEBCHANGE =
  • #Set ALLOWWEBCHANGE = TWikiAdminGroup
  • Set ALLOWWEBCHANGE = JoseCarlosRamalho,Main.AlbertoSimoes,Main.PedroRangelHenriques,Main.DanielaCruz
  • #Set DENYWEBRENAME =
  • #Set ALLOWWEBRENAME = TWikiAdminGroup

• Users or groups allowed to change or rename this WebPreferences topic: (e.g., TWikiAdminGroup)
  • #Set ALLOWTOPICCHANGE = TWikiAdminGroup
  • Set ALLOWTOPICRENAME = TWikiAdminGroup

• Web preferences that are not allowed to be overridden by user or topic preferences:
  • Set FINALPREFERENCES = NOSEARCHALL, ATTACHFILESIZELIMIT, WIKIWEBMASTER, WEBCOPYRIGHT, WEBTOPICLIST, DENYWEBVIEW, ALLOWWEBVIEW, DENYWEBCHANGE, ALLOWWEBCHANGE, DENYWEBRENAME, ALLOWWEBRENAME

Help on Preferences

• A preference setting is defined by:
  3 or 6 spaces * Set NAME = value
  Example:
  • Set WEBBGCOLOR = #FFFFC0
• A preferences setting can be disabled with a # sign. Remove the # sign to enable a local customisation. Example:
  
  • #Set DENYWEBCHANGE = UnknownUser
• Preferences are used as TWikiVariables by enclosing the name in percent signs. Example:
  • When you write variable %WEBBGCOLOR% , it gets expanded to #D0D0D0
• The sequential order of the preference settings is significant. Define preferences that use other preferences first, i.e. set WEBCOPYRIGHT before WIKIWEBMASTER since %WEBCOPYRIGHT% uses the %WIKIWEBMASTER% variable.
• You can introduce your own preferences variables and use them in your topics and templates.

Related Topics

• TWiki.TWikiPreferences, Main.TWikiPreferences - site-level preferences
• TWikiUsers - list of user topics. User topics can have optional user preferences
• TWikiVariables - list of common %VARIABLES%
• TWikiAccessControl - explains how to restrict access by users or groups

Tools

• Rename, move or delete this web:
  • Rename/move/delete web..., looking for references in all public webs - See also: ManagingWebs

Web Search

Search: \.*