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