A avaliação da entrega inicial considera a execução de intervenções em duas regiões do código do compilador em desenvolvimento, assim como a gestão do projecto correspondente.

A avaliação é realizada sobre a versão existente no CVS às 12:00 de 2012/03/30. Projectos que não apresentem alterações relativamente ao conteúdo inicial do repositório CVS não serão considerados.

Considerando que é um passo crucial na concepção do projecto, a não realização desta entrega conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente exclusão da avaliação da disciplina no ano lectivo 2011/2012.

Advertem-se os alunos sobre a consulta de colegas de anos anteriores. Estas consultas podem ser positivas, mas comportam algum risco, pois o processo e critérios de avaliação podem ter mudado. Além disso, a proficiência do colega pode majorar negativamente o resultado da avaliação em curso. Não são admitidas quaisquer justificações com base na história da disciplina.

Estas condições são aplicáveis à data da entrega inicial (2012/03/30).

Em caso de dúvidas suscitadas por qualquer elemento neste texto, no projecto, ou na disciplina em geral, os alunos são fortemente encorajados a consultar o corpo docente.

VALORAÇÕES

Existem 2 valores(dos 20 disponíveis para o projecto) associados a esta entrega:

• gestão do projecto: 0.5 valores
  • projecto com a estrutura correcta no repositório CVS: 0.25 valores (i.e., código que não apresente a estrutura canónica de um compilador desenvolvido com a CDK é considerado sem a estrutura correcta -- consultar estas páginas sobre o desenvolvimento do projecto com base no repositório CVS)
  • projecto compila e produz compilador "tll" ("tll", com letras minúsculas: variações correspondem a "não compilação"): 0.25 valores

Se o projecto compilar, poderão ser atribuídos mais 1.5 valores (desenvolvimento do compilador), distribuídos como se segue:

• Classes dos nós do compilador (completo): 1.0 valores
  
  • Reutilização dos nós da CDK (simples ajuste do Compact)
  • Definição ou extensão de elementos existentes (simples ajuste do Compact)
  • Definição de novas declarações/definições (variáveis/funções) (completo)
  • Definição de novas instruções (completo)
  • Definição de novas expressões (completo)
  • Definição de outros elementos (completo)
  • Sugere-se (por simplicidade de gestão do código) a separação das várias classes de nós em namespaces coerentes (à la Compact)
  • Não é necessário criar as regras no BYACC para criar os nós (se for feito, é conveniente para o progresso do projecto, mas não é avaliado nesta entrega)
• Métodos dos "visitors" (completo): 0.5 valores
  
  • Reutilização de métodos já definidos (simples ajuste do Compact)
  • Definição de todos os métodos processX (correspondentes ao nó da class X) em todos os visitors (simples extensão do Compact)
  • Métodos novos podem estar vazios, mas devem existir
  • Métodos correspondentes a acções semelhantes às existentes devem ser modelados nos existentes (exemplo, processWhileNode -> processForNode) (mesmo que não modificados numa primeira instância)
  • A presença de implementações de semântica no PFwriter (tabela de símbolos, validação de tipos, etc.) não é penalizada, mas não será avaliada nesta entrega

PENALIZAÇÕES

Existem penalizações relativas à (deficiente) execução do projecto.
São considerados os seguintes aspectos preliminares:

1. A linguagem TLL contém a linguagem Compact (excepto no correspondente à atribuição não ser uma expressão em Compact), pelo que não há razão para não utilizar completamente o compilador Compact, eventualmente com pequenas alterações.
2. A semântica da linguagem TLL contém a da linguagem Compact (excepto no correspondente à atribuição não ser uma expressão em Compact), pelo que a implementação de alguns aspectos da linguagem TLL não requer qualquer reimplementação relativamente ao Compact.
3. O compilador Compact foi fornecido completamente funcional, assim como a versão inicial do compilador TLL no respositório CVS (igual ao Compact e apenas alterado, para ter o nome TLL em lugar de Compact).
4. A criação de novos nós não apresenta quaisquer dificuldades (são classes muito simples).
5. Os métodos (na sua maioria, vazios) dos "visitors" são simples paralelos com as classes dos nós e os que não estão vazios são quase 100% reutilizáveis na nova linguagem.
6. O compilador é obrigatoriamente desenvolvido em C++, fazendo-se uso do material de apoio.

Considerando os aspectos 1. a 6., são aplicadas as seguintes penalizações:

• Destruição de funcionalidade do compilador Compact sem substituição por funcionalidade equivalente do compilador TLL: 2 valores
• Utilização de funções e estruturas C, quando existem alternativas directas C++ (malloc em lugar de new, por exemplo; strcmp, etc. em lugar da classe std::string; e outras): penalização máxima de 1 valor
• Não utilização de qualquer material obrigatório ou não satisfação dos critérios mínimos: 2 valores e considera-se entrega não realizada (implica exclusão da avaliação)