Programação com Objectos/Projecto de Programação com Objectos/Avaliação do Projecto (Época Normal)
From Wiki**3
< Programação com Objectos | Projecto de Programação com Objectos
| AVISOS - Avaliação em Época Normal |
|---|
|
Esclarecimento de dúvidas:
|
|
Requisitos para desenvolvimento, material de apoio e actualizações do enunciado (ver informação completa em Projecto de Programação com Objectos):
|
|
Processo de avaliação (ver informação completa em Avaliação do Projecto):
|
| Material de Uso Obrigatório |
|---|
| As bibliotecas po-uuilib e o conteúdo inicial do CVS são de uso obrigatório: |
|
| A máquina virtual, fornecida para desenvolvimento do projecto, já contém todo o material de apoio. |
| Uso Obrigatório: Repositório CVS |
| Apenas se consideram para avaliação os projectos existentes no repositório CVS oficial.
Trabalhos não presentes no repositório no final do prazo têm classificação 0 (zero) (não são aceites outras formas de entrega). Não são admitidas justificações para atrasos em sincronizações do repositório. A indisponibilidade temporária do repositório, desde que inferior a 24 horas, não justifica atrasos na submissão de um trabalho. |
Método de Avaliação do Projecto
A avaliação relativa à componente do Projecto processa-se em várias fases:
O Projecto (trabalho conducente às entregas acima mencionadas e abaixo descritas) é realizado individualmente durante o período estabelecido.
O Teste Prático é realizado individualmente, em data e local a agendar.
TODAS AS ENTREGAS SÃO REALIZADAS ATÉ ÀS 12:00 ("meio-dia") DAS RESPECTIVAS DATAS
Cálculo da Nota do Projecto e Condições de Aprovação
Componentes de avaliação:
- PRJ - nota final do projecto
- PU - nota da entrega do diagrama UML
- PI- nota da entrega intermédia
- PF- nota da entrega final
- TP - nota do teste prático
A nota do teste prático condiciona a distância ao mínimo entre as notas do teste prático e a do projecto: desde um mínimo de 12.5% de acréscimo à menor das duas (abaixo de 7.5 valores no TP), até um máximo de 25% (para 20 valores no TP). O acréscimo é linear entre 7.5 e 20.
Ou seja:
- PRJ = min(PU+PI+PF, TP) + | TP - PU - PI - PF | * max(12.5, TP+5) / 100
Condições necessárias para aprovação à disciplina -- necessárias todas:
- PRJ >= 9.5 (sem arredondamento)
- PRJ != NA
- TP > 0
- TP != NA
Entrega do Modelo UML
A Entrega do Modelo UML avalia o estado do projecto relativamente à concepção do modelo.
Esta entrega tem uma classificação máxima de 2 valores.
Devem ser entregues diagramas de classes correspondentes a todos os conceitos da aplicação, mesmo que esses conceitos venham a ser revistos/alterados futuramente. Podem ainda ser incluídas anotações nos diagramas, por forma a clarificar outros aspectos relevantes. Não é necessária a inclusão de getters/setters/equals/toString (e outros métodos já definidos no Java).
- Diagrama 1: diagrama do pacote po-uuilib (material de apoio que não pode ser alterado)
- Diagrama 2: diagrama do pacote pex-app (material do projecto completo e cujos métodos devem ser completados)
- Diagrama 3: diagrama do pacote pex-core (material do projecto incompleto e que deve ser completado e desenvolvido)
A entrega dos diagramas em papel faz-se em qualquer aula teórica, horário de dúvidas, ou na recepção do INESC ID (Rua Alves Redol, 9), ao cuidado de David Matos, até à data limite.
Considerando que é uma ENTREGA 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 em curso.
Serão aplicados os seguintes critérios na avaliação da entrega UML.
Factores aditivos positivos:
- 0.70 - Conceitos
- 0.30 - Herança
- 0.50 - Associações
- 0.25 - Atributos
- 0.25 - Interface (métodos das classes, interfaces, etc.)
Factores aditivos negativos:
- 0.50 - Erros de notação
A compreensão clara dos aspectos acima deve ser adquirida antes da entrega.
Entrega Intermédia
A Entrega Intermédia avalia o estado do projecto relativamente a um mínimo de funcionalidade.
Esta entrega tem uma classificação máxima de 5 valores (2.5 valores para testes automáticos).
Serão executados testes automáticos nesta entrega.
A não realização da Entrega Intermédia conduz automaticamente a uma classificação de 0 (zero) na componente correspondente (mas não globalmente no projecto).
Funcionalidade a implementar
A funcionalidade necessária para a entrega intermédia, além da abertura de todos os submenus, é a seguinte:
- Leitura, interpretação e representação em memória do ficheiro textual indicado pela propriedade import (implica implementar algumas classes do "core")
- Menu principal: Salvaguarda do Estado Actual do Interpretador: "Criar", "Abrir" e "Guardar"
- Menu principal: Criação, Leitura e Escrita de Programas: "Criar Programa", "Ler Programa" e "Escrever Programa"
- Menu principal: Manipulação de Programa: abertura do menu de manipulação de um programa e respectivas validações
- Menu de Manipulação de Programas: Listar programa
Todos os outros comandos em todos os menus têm de estar implementados ("execute" pode estar vazio). Não é má prática implementar os outros comandos, pois poupa esforço para a entrega final, mas não serão avaliados nesta entrega.
A funcionalidade a implementar em pex-core tem de ser suficiente para suportar os comandos indicados acima.
Critérios de avaliação (não automática)
Serão aplicados os seguintes critérios na avaliação da entrega intermédia do projecto.
Factores aditivos positivos:
- 0.30 - Atributos não públicos
- 0.30 - Atributos e métodos não "static" (excepto onde autorizado)
- 0.30 - Atributos não repetidos
- 0.30 - Serialização
- 0.30 - Factorização e organização (não repetição) de código
- 0.50 - Separação app/core (pode haver descontos na parte automática)
- 0.30 - Qualidade do projecto
- 0.20 - Comentários Javadoc (a colocar necessariamente na classe Program)
Factores aditivos negativos:
- 0.15 - Violação de regras de codificação Java
Será aplicado um desconto até 1.00 pela existência de lixo no repositório CVS. Este "lixo" é apenas considerado se aparecer na cópia local durante um "checkout".
Entrega Final
A Entrega Final pressupõe que todo o projecto foi completamente implementado.
Esta entrega tem uma classificação máxima de 13 valores (6 valores para testes automáticos).
Serão executados testes automáticos nesta entrega.
Os testes correspondem a uma série de entradas a processar pelo projecto de cada grupo e cuja execução deve corresponder a um conjunto de resultados padrão.
A não realização da Entrega Final 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 em curso.
Serão aplicados os seguintes critérios na avaliação da entrega final do projecto.
Factores aditivos positivos:
- 0.75 - Atributos (qualidade e acesso)
- 0.75 - Factorização e reutilização de código (evitar repetição de código: serialização, verificações, etc.)
- 0.50 - Atributos e métodos não "static" (excepto autorizados)
- 1.00 - Flexibilidade de formato de apresentação na saída
- 1.00 - Utilização de estruturas de dados correctas
- 1.00 - Separação de responsabilidades, incluindo serialização (core vs. app)
- 1.00 - Verificação de situações erróneas nos programas (chamada a programas inexistentes e tratamento de argumentos inválidos em operadores aritméticos)
- 1.00 - Apreciação global
Factores aditivos negativos:
- até 1.00 - Violação de regras de codificação Java
- até 1.00 - Existência de lixo no repositório CVS (o "lixo" é apenas considerado se aparecer na cópia local durante um "checkout")
Note-se que não é considerada a entrega final se o repositório à data da entrega final contiver o mesmo código da entrega intermédia. Isso implica também a reprovação imediata dos alunos do grupo em causa (a entrega final é obrigatória).
Teste Prático
O Teste Prático consiste num conjunto de questões (correspondentes a pequenas alterações/extensões ao enunciado) a resolver com base na implementação submetida para a avaliação correspondente à entrega final.
Este teste é individual e avalia o conhecimento do aluno relativamente ao projecto entregue, assim como a sua capacidade de realizar alterações ao código do projecto.
O teste prático é como uma discussão de projecto, pelo que não existem repescagens como nos testes escritos. Alunos que faltem ao teste prático estão automaticamente reprovados à disciplina.
A não realização do Teste Prático conduz automaticamente a uma classificação de 0 (zero) nacomponente de avaliação relativa ao Projecto e consequente exclusão da avaliação da disciplina no ano lectivo em curso.
O teste prático contém uma prova eliminatória: o aluno deverá ser capaz de compilar e executar um pequeno programa em Java.
Considerações Adicionais sobre a Avaliação do Projecto
O projecto deverá ser desenvolvido atempadamente ao longo do semestre.
As versões intermédias registadas no CVS poderão ser testadas, pelo que deverão ser periodicamente actualizadas. O projecto é constituído por um projecto CVS designado pelo número do grupo que o executa. O repositório CVS disponibilizado já contém uma versão vazia do projecto. Apenas os ficheiros registados no projecto CVS serão considerados na avaliação.
Não serão consideradas quaisquer alterações aos ficheiros disponibilizados: eventuais cópias desses ficheiros serão automaticamente substituídas durante a avaliação da funcionalidade do código submetido.
A avaliação executa testes automáticos ao projecto a implementar: a nota reflectirá apenas os testes bem sucedidos. Chama-se especial atenção para o nome da classe que inicia a execução. As restantes componentes da nota são obtidas pela análise do código e resultado do teste prático (realizado individualmente). O código é avaliado quanto à sua correcção, simplicidade, extensibilidade e legibilidade: devem existir comentários das partes mais complexas, mas não devem ser excessivos, nem óbvios (diminuem a legibilidade), nem muito escassos (impedem a compreensão). O teste prático avalia a capacidade de efectuar alterações ao código entregue.
Qualquer alteração à especificação providenciada no enunciado é penalizada, mesmo que possa ser entendida como um melhoramento.
Notar que o facto de os testes automáticos terem sido superados não reflecte a qualidade do código, quer do ponto de vista de engenharia de software, quer do ponto de vista da correcta aplicação dos princípios leccionados na disciplina. A funcionalidade do projecto final é de extrema importância, pelo que é preferível um projecto que realize, correctamente, apenas parte da funcionalidade a um quase completo mas que nem sequer compile ou que não processe nenhuma entrada correctamente.
Compromisso de Honra
A entrega de quaisquer trabalhos pressupõe o compromisso de honra que foram realizados pelos autores referenciados. A quebra deste compromisso, i.e., a tentativa de apropriação de trabalhos alheios, terá como consequência a reprovação de todos os alunos envolvidos (incluindo os que possibilitaram a ocorrência) no ano lectivo actual, sem prejuízo de acções disciplinares previstas pelo IST.