Correção de Rodrigo Almeida dos Santos Critérios da correção ========= == ======== Testes de aceitação: - 1,0 por cada erro apresentado durante validação dos testes Design: - todos iniciaram com nota 10, e pontos foram deduzidos pelos seguintes itens: - Uso de padrões de forma necessária, e suas justificativas por exemplo, uso de Padroes de Criação para criar Cadastro de Clientes, ... (-1,0 cada) - Tratamento adequado de exceções, com criação de exceções adequadas para determinados tipos de erros; testes para verificar ocorrencia de erros.. (-2,0) - classes com atribuições erradas (-1,0 cada); relacionamentos entre classes errados, mal refatoramento (-1,0 cada) - Uso de composição no projeto, em momentos adequados (-1,0 cada) Documentação: - Todos iniciaram com 10, pontos deduzidos conforme a qualidade da documentação, se há metodos não documentados, se há informações importantes relativas ao código nao documentados, meio de gerar javadoc, etc... Relatório: - 7,0 pelo texto: Justificativa coerente do uso de padrões (-1.0) cada; Aspectos conceituais (-1.0) - 3,0 pelo diagrama de classes Legibilidade (-3,0) Outros Pontos a serem Observados: Encontrei em alguns projetos problemas na documentacao do Javadoc. Quem tiver duvidas sobre como criar documentaçào, ver o link: http://java.sun.com/j2se/javadoc/writingdoccomments/ Alunos de DACA ================================================ Alexandre - Testes de aceitação: 10,0 - Design: 10,0 - Documentação: 10,0 - Relatório: 10,0 Diagrama de Classes: 3,0 Texto: 7,0 ================================================ Anderson Pablo e Jeysibel - Testes de aceitação: 10,0 - Design: 8,0 - Faltou haver uma melhor estruturação das exceções. Há uma exceçao generica chamada "JatoException", o que dificultará a identificação e correção de erros (-2,0) - Documentação: 10,0 - Relatório: 10,0 ============================================== Andre e Carlos - Testes de aceitação: 10,0 - Design: 10,0 - Documentação: 6,0 - Contem metodos sem documentação (metodos presentes nas classes de exceção) ou verificaAtributoVazio da classe model.Cliente (-2,0) - Alguns metodos (Como metodo setPreferenciaCorreioda classe model.Cliente) apresentam documentação errada. o metodo nao dispara DatasInvalidaExcepiton. (-1.0) - Observem como a clausula @returns foi utilizada no metodo getPreferenciaCorreio da classe model.Cliente. seria mais apropriado algo do tipo @returns String Esse foi um exemplo, no codigo existem outros pontos (- 1.0) - Relatório: 7,0 - Diagrama pouco organizado, falta uma visao global do sistema (-1,0) - Faltou discutir mais os padrões utilizados, por exemplo, Baixo Acoplamento ou Creator, em que a justificativa se encontra incompleta. (-2.0) ============================================== Luciana e Ricardo - Testes de Aceitação: 10,0 - Design: 10,0 - Documentação: 10,0 - Relatório: 10,0 ============================================== Taciano e Romulo - Testes de Aceitação: 10,0 - Design: 10,0 - Documentação: 10,0 - Relatório: 10,0 ============================================== Maria e Justino - Testes de Aceitação: 10,0 - Design: 9,0 - Refatorar classes SistemaDeCorreioEletronico e SistemaDeCorreioEmArquivo (-1.0) - Documentação: 9,0 - Nao consegui gerar o javadoc (-1.0) - Relatório: 7,0 - Os padroes indicados no relatorio foram somente aqueles necessarios na utilização do easyaccept. - Faltou ao relatório o comentário de outros padroes e necessidades no desenvolvimento do sistema (-1.0) - Interface e polimorfismo não são padrões de projeto. Há um equivoco conceitual. (-1.0) - Diagrama pouco legível (-1.0) ============================================== Danilo e Francisco - Testes de Aceitação: 10,0 - Design: 8,0 - Carece de um melhor tratamento de exceções. Dificulta a identificação e correção de erros (-2,0) - Documentação: 5,0 - Muitas classes do pacote ojato.controller.comandos não contém nenhum comentário (-2.0) - classe Facade sem comentarios (-2.0) - - Relatório: 9,0 - No relatório faltou explicar melhor o uso dos patterns no projeto. (-1,0) ============================================== Gustavo e Halley - Testes de Aceitação: 10,0 - Design: 8.5 - Alguma lógica de negocios se encontra no Facade (-1.0) - No projeto é requisitado a existencia de dois sistemas de correio: Um que mande por email e outro que guarda tudo em arquivo. O uso de uma interface e a criação de duas classes seria uma medida interessante, para diminuir acoplamento, por exemplo. (-0.5) - Documentação: 10,0 - Relatório: 0,0 - Não entregou relatório - Diagrama de Classes ilegível =============================================== Thiago e Marcio - Testes de Aceitação: 3,0 - [exec] Test file testes/us3.txt: 7 errors (-7.0) - Design: 9,0 - é mantido uma classe EasyAcceptFacade e uma classe JatoFacade. Nao seria necessaria somente uma classe Facade? (-1.0) - Documentação: 9,0 - (Uma classe EasyAcceptFacade nao tem comentarios) (-1.0) - Relatório: 10,0 Diagrama: 3,0 Relatório: 7,0