================================================ MILESTONE 1 ================================================ testes de aceitação ------------------- Nota base: 10,0 - 3,0 para cada us.txt que contenha testes errados Testes de unidade ----------------- nota base: 7,0 até +2,0 para quem fez os testes de unidade para a manipulação de strings com qualidade e abrangência (-2,0 se não fez teste para a manipulação de strings) até +1,0 para quem usou testes de unidade em locais adicionais onde precisava ser feito (esse ponto pode ser incorporado no item anterior se não houver necessidade de testes adicionais) -0,5 para cada teste inócuo (repetição dos testes de aceitação) -3,0 se houver testes que não rodem (red bar) Design ------ nota base: 8,0 pontos essenciais do design: 1. Implementação de Lugares - a solução mais eficiente é uma hierarquia de interfaces que são implementadas pelos diferentes lugares - hierarquia porque há funcionalidades específicas de tipos de lugares agrupados (veja exemplo abaixo) - interfaces porque é uma solução superior (program to an interface, not to an implementation) Ex.: * uma interface Lugar com as assinaturas mais básicas de um lugar, implementada por lugares mais simples (FreeParking, por exemplo); * uma interface LugarComprável, que estende Lugar e é implementada pelos lugares que podem ser comprados (propriedades, ferrovias; e serviços públicos no futuro) * a hierarquia pode ir crescendo à medida que novas funcionalidades de lugares vão ficando claras (p.ex., Chance e Community Chest, agora no milestone 2) - tirei 0,5 ponto de quem usou herança direta (sem usar interfaces) - tirei 1,0 ponto de quem não separou hierarquicamente os diferentes tipos de lugares 2. Atribuições corretas - tirei 0,5 de cada elemento tratado na classe errada - tirei 1,0 de cada classe importante que falta - ex.: lugares dentro de jogo (sem haver um tabuleiro), lugares misturados com seus títulos, jogadores gerenciados pelo banco (!?) 3. Bônus por idéias legais - 1,0 ponto por cada design interessante que funcione (p.ex., uma classe Dado, manipuladores de jogadores, manipuladores de ações, listeners de um jogo, etc.) Documentação ------------ nota base: 10,0 -3,0 se a documentação estiver incompleta (falta descrever parametros, valor de retorno, excecoes lancadas pelos metodos, ...) Código ------ nota base: 8,0 até +2,0 pela qualidade do código (endentação, organização em pacotes, nomes de variáveis, etc.) -1,0 se não usou loop para a criação de entidades Relatório --------- 5,0 pelo diagrama de classes 5,0 pela explicação dos patterns ***************** Alexandre *********************** testes de aceitação: 10,0 testes de unidade: 5,0 - teste para StringModificator incompleto (faltam muitos erros de formato de string) - sem bônus - vários testes inócuos (GameTest, PlayerTest, PropertyTest, etc.) -2,0 design: 7,5 - usou herança para os lugares (-0,5) e não hierarquizou (-1,0); classe Die (+1,0) código: 8,5 - +1,5 pela qualidade - -1,0 por não usar loops na criação de objetos (ex. lugares no tabuleiro) - -0,5 StingManipulator não funciona direito (não lança exceções de erro de formato) documentação: 10,0 relatório: 6,5 - 1,5 pelo diagrama de classes (não dá pra ler nada) - 5,0 pela descrição dos patterns **************** Anne/Kézia ********************** testes de aceitação: 10 testes de unidade: 6,0 - TestStringManipulator incompleto (erro de formato deveria lançar exceção, não testa todos os erros de formato) +1,0 - vários testes inócuos -2,0, design: 6,5 - não hierarquizou lugares (-1,0); - jogador sabe número de lugares do tabuleiro (-0,5) código: 8,5 - +1,5 pela qualidade - -1,0 por não usar loops documentação: 10,0 relatório: 6,0 - 3,5 pelo diagrama de classes (faltam atributos) - 3,0 pela descrição dos patterns ***************** Arthur-Tomás ************************ testes de aceitação: 10,0 testes de unidade: 4,0 - não fizeram teste para StringUtil (-2,0) - teste para MonopolyPlayerDataBank ok +1,0 - testes inócuos -2,0 design: 9,5 - usou herança para lugares (-0,5), mas bolou uma hierarquia - PlayerDataBank funciona legal (+1,0), interfaces Buyer e Monopoler (+1,0) código: 8,0 - +1,0 pela qualidade - -1,0 por não usar loops na criação de lugares documentação: 10,0 relatório: 7,5 - 3,5 pelo diagrama de classes (faltam atributos) - 4,0 pela descrição dos patterns ****************** Diego-Newton *************************** testes de aceitação: 10,0 testes de unidade: 10,0 design: 6,5 - usou herança para lugares (-0,5), mas bolou uma hierarquia - não há um tabuleiro (-1,0) código: 9,5 - +1,5 pela qualidade - usou loop para inicializar lugares (ok) documentação: 10,0 relatório: 9,5 - 4,5 pelo digrama de classes (faltam alguns atributos) - 5,0 pela descrição dos patterns ******************* Diego-Maria ************************** testes de aceitacao: 10,0 testes de unidade: 6,0 - testStringManipulation incompleto (nao testa se a colecao retornada confere) +1,0 - testes inócuos (-2,0) design: 8,0 - usou interfaces hierarquizadas para lugares (ok) - classe Die (+1,0) - falta um banco (-1,0) código: 8,5 - +1,5 pela qualidade do código - não usou loop na criação de lugares (-1,0) documentação: 9,5 - tudo comentado, mas alguns métodos não geram javadoc relatório: 10 - 5,0 pelo diagrama de classes - 5,0 pela descrição dos patterns ***************** Erick/Moisés ************************ testes de aceitação: 10 testes de unidade: 7,0 - +2,0 pelos testes de StringManipulator - -2,0 pelos testes inócuos design: 6,0 - usou herança para lugares (-0,5), não hierarquizou (-1,0) - corrida das ferrovias em Bank (-0,5) código: 9,0 - +1,0 pela qualidade do código - usou XML para criar o tabuleiro (ok) documentação: 9,0 - alguns métodos em Monopoly só com comentários (sem javadoc), outros estão faltando detalhar exceções relatório: 6,0 - texto entregue incompleto (1,5) - 4,5 pelo diagrama de classes (faltam alguns atributos) ***************** Flávio/Thiago ************************ testes de aceitação: 10 testes de unidade: 7,5 - StringManipulator não cobre todos os casos (+1,0) - PlayerTest é inócuo (-0,5) design: 8,0 - usou herança para lugares (-0,5), não hierarquizou (-1,0) - gerenciador de jogadores (+1,0), gerenciador de ações (+1,0) - Bank não é um player (-0,5) código: 8,0 - qualidade do código (+1,0) - agrupamento em packages não está legal (Bank em UI, testes misturados), poucas exceções - não usou loop na criação dos lugares (-1,0) documentação: 9,0 - algumas descrições faltando em algumas classes (Bank, p.ex.) relatório: 9,0 - 4,5 pela descrição dos patterns - 4,5 pelo diagrama de classes (faltam alguns atributos) ***************** Flavio/Paolo ************************* testes de aceitação: 10,0 testes de unidade: 8,5 - Teste de StringInterpreter muito bom (+3,0) - alguns testes inócuos (-1,5) design: 8,0 - não hierarquizou lugares (-1,0), mas usou interface - separou Deeds de Lugares (+1,0) código: 9,0 - qualidade do código +2,0 - não usou loop para a criação dos lugares (-1,0) documentação: 10,0 relatório: 8,5 - 3,5 pelo diagrama de classes (faltam muitos atributos) - 5,0 pela descrição dos patterns ***************** Gustavo ************************* testes de aceitação: 10 testes de unidade: 3,0 - não fez teste de manipulação de Strings (-2,0) - testes inócuos (-2,0) design: 4,5 - lugares sem hierarquia, usando herança (-1,5) - falta um banco (-1,0) - classe Lugares (HashMap de lugares) e classe Tabuleiro (mantém um objeto Lugares) - !? (-0,5) - jogador sabe números de lugares do tabuleiro e salário (-0,5) código: 8,5 - usou loop para criar lugares (ok) - qualidade do código (+0,5): tem coisas complicadas (p.ex. acaoDeComprarOuAlugar em Jogo) documentação: 8,0 - exceções sem javadoc, testes de unidade sem javadoc, alguns métodos sem javadoc relatório: 6,0 - 4,0 pela descrição dos patterns - 2,0 pelo diagrama de classes (faltam métodos e atributos) *************** Gustavo Farias/Lucas ******************* testes de aceitação: 10,0 testes de unidade: 5,0 - teste de manipulação de strings não é legal (não testa erros de formato, alguns formatos inválidos são aceitos, etc.): sem bônus - testes inócuos -2,0 design: 9,0 - não hierarquizou lugares e usou herança (-1,5) - classe Dice (+1,0), separou deeds de lugares (+1,0), mapa de MonopolyPlayers (+1,0) - jogador sabe número de lugares do tabuleiro (-0,5) código: 8,0 - +1,0 pela qualidade do código - não usou loop para a criação de lugares (-1,0) documentação: 10,0 relatório: 8,0 - 5,0 pela descrição dos patterns - 3,0 pelo diagrama de classes (faltam atributos e há mais métodos importantes que deveriam ser mostrados) ***************** Helder/Dalton ********************* testes de aceitação: 10,0 testes de unidade: 5,0 - GameTest insuficiente, não testa situações de erro na manipulação de string, o exemplo fornecido deveria dar erro de formato, e o nome está errado - considerei -2,0, como se não tivesse sido feito (testa as strings através de uma criação de jogo, e não há uma classe StringManipulator) design: 6,0 - não hierarquizou lugares (-1,0), mas usou interfaces - falta um banco (-1,0) código: 8,0 - não fez loop para criar lugares (-1,0) qualidade do código (+1,0) - nem todas as exceções devem ser GameException documentação: 10,0 relatório: 10,0 - 5,0 pela descrição dos patterns - 5,0 pelo diagrama de classes ***************** Halley/Marcus ************************* testes de aceitação: 9,0 * a versão dos testes enviada era uma antiga que só tinha 1332 testes, e não 1433 * testei com as versões novas - só passou us3.txt e us4.txt * relevei us1.txt, porque os testes que deram errado foram os getCommands(), que não faziam tanto sentido agora * us2.txt teve muitos problemas, devido às alterações recentes do arquivo * cuidado nos próximos milestones, prestem atenção às mensagens da lista - os testes vão sendo modificados à medida que erros são detectados neles * próximo à entrega, garantam que têm a versão mais recente dos testes baixando diretamente da página testes de unidade: 3,0 - não testou manipulação de strings (-2,0) - muitos testes de unidade, tudo de coisas desnecessárias (-2,0) design: 8,5 - hierarquizou lugares, mas usou herança (-0,5) - implementou deeds (+1,0) código: 8,5 - qualidade +1,5 - não usou loop para criar os lugares (-1,0) documentação: 8,0 - alguns métodos estão com comentários simples e não entram no javadoc - a façade não está documentada relatório: - 5,0 pela descrição dos patterns - 5,0 pelo diagrama de classes ***************** Helton/Ana Esther ************************* testes de aceitação: 10 testes de unidade: 4,0 - CollectionConstructorTest incompleto e mal escrito (alguns casos do teste são erros de formato e não devem ser aceitos; faltam ainda outros casos não testados) - sem bônus - muitos testes que não servem (cobertos pelos testes de aceitação): -3,0 design: 8,5 - usou hierarquia de interfaces (ok) - interface para Bank e Player (+1,0) - Board cria um banco, e MonopolyGame cria outro diferente (-0,5); um dos dois não serve para nada código: 8,5 - qualidade do código +1,5 - não usou loop para criar lugares (-1,0) documentação: 10,0 relatório: 8,5 - 5,0 pela descrição dos patterns - 3,5 pelo diagrama de classes (faltam todos os atributos) ****************** João Arthur/Felipe ************************* testes de aceitação: 10 testes de unidade: 3,5 - não testou manipulação de strings (-2,0) - testes inócuos (-1,5) design: 6,5 - hierarquia de interface para lugares (-0,5 porque a interface mais abstrata não deveria ter a assinatura de getPropertyRent) - falta um banco (-1,0) código: 7,5 qualidade +0,5 (métodos de Game estão muito grandes e complicados: construtor, buy, play) não usa loop para criar lugares (-1,0) documentação: 10,0 relatório: 8,5 - 5,0 pela descrição dos patterns - 3,5 pelo diagrama de classes (faltam todos os atributos) ****************** José Ronaldo/Larissa *************************** testes de aceitação: 10 testes de unidade: 4,0 - não há testes para StringToList (que não é usada); testes de manipulação de strings incompletos através do construtor de Game (-1,0) - testes inócuos (-2,0) design: 7,0 - implementaram hierarquia de interfaces para lugares, mas se perderam um pouco na fatoração (getRent não devia estar em Place, obriga UnRentablePlace a desfazê-lo com uma exceção); -0,5 - uma Deed não é uma lista de propriedades; refere-se a um só lugar, que pode ser uma propriedade, uma ferrovia ou um serviço público (-0,5) código: 9,0 - qualidade do código +1,0 - cria lugares através de arquivo com um loop (ok) documentação: 10,0 relatório: 10,0 - 5,0 pela descrição dos patterns - 5,0 pelo manual do usuário ********************* Katyuscia/Leandro **************************** testes de aceitação: 10,0 testes de unidade: 4,5 - não fizeram teste para a manipulação de strings (-2,0) - GameTest não testa nada novo (-0,5) design: 6,5 - implementaram hierarquia de interfaces, mas não fatoraram direito (Place tem getRent) -0,5 - não possui um banco (-1,0) código: 8,0 - qualidade do código +1,0 - não usaram loop na criação de lugares (-1,0) documentação: 9,5 - faltando detalhar algumas exceções relatório: 9,5 - 5,0 pela descrição dos patterns - 4,5 pelo diagrama de classes ****************** Luciana/Ricardo ************************* testes de aceitação: 10 testes de unidade: 7,5 - testes para StringManipulator incompletos (faltam condições de erro) +0,5 design: 8,5 - hierarquia de interfaces (ok) - interfaces para Bank e Player (+1,0) - buy em Board (-0,5) código: 8,5 - qualidade do código +1,5 - inicializaram locais sem loop (-1,0) documentação: 10,0 relatório: 9,0 - 5,0 pela descrição dos patterns - 4,0 pelo diagrama de classes (faltam algumas relações e alguns atributos) ****************** Pablo ************************* testes de aceitação: 10 testes de unidade: 6,0 - testes para manipulador de strings incompleto (faltam condições de erro, asserts) - sem bônus - alguns testes inócuos (-1,0) design: 7,5 - hierarquizou lugares com herança (-0,5) - falta tabuleiro (-1,0) - herança para Banco e Jogador (+1,0) código: 7,0 - qualidade do código +0,5 - não utilizou loop para inicializar lugares (-1,0) - lugares são inicializados em banco (-0,5), além de em Jogo documentação: 9,0 - falta detalhar muitos parâmetros e exceções relatório: 6,5 - 3,5 pela descrição dos patterns - 3,0 pelo diagrama de classes (faltam atributos e métodos) ******************* Rodrigo/Priscilla ************************* testes de aceitação: 10 testes de unidade: 5,0 - falta teste para a manipulação de strings (-2,0) - teste feito através de createGame não serve design: 9,5 - hierarquia de interfaces para lugares (ok) - Deeds separados de Lugares (+1,0) - classe Die (+1,0) - Bank não serve para nada (-0,5) código: 8,5 - qualidade do código +1,5 - inicializou lugares sem loop (-1,0) documentação: 9,5 - falta indicação de exceções lançadas pelos métodos relatório: 3,5 - 3,5 pelo diagrama de classes (faltam atributos) - 0,0 pela descrição dos patterns (não entregou) ******************* Vinícius/Willames ************************** testes de aceitação: 10 testes de unidade: 3,0 - não fez teste de manipulação de strings (-2,0) - muitos testes inúteis (-2,0) design: 7,5 - usou herança de uma única classe, sem hierarquia (-1,5) - classe Dice (+1,0) código: 8,5 - qualidade do código +1,5 - lugares inicializados sem loop (-1,0) documentação: 9,0 - falta documentação da Facade relatório: 9,0 - 5,0 pela descrição dos patterns - 4,0 pelo diagrama de classes (há mais atributos) ******************** Antônio Carlos **************************** testes de aceitação: 10,0 testes de unidade: 4,0 - não fez teste para a manipulação de strings (-2,0) - testes inócuos -1,0 design: 5,0 - não há diferença entre lugares (tudo é propriedade) -2,0 - falta um banco (-1,0) código: 8,5 - qualidade do código +0,5 - usou loop e array para criar locais (ok) documentação: 7,0 - Facade sem documentação, jogo com varios metodos sem documentação, etc. relatório: 0,0 - não entregou ================================================ MILESTONE 2 ================================================ Comentários gerais: Como aumentar a sua nota do projeto? É muito fácil tirar 10,0 em três dos itens da correção: - testes de aceitação (basta entregar só quando tudo estiver passando) - documentação (basta entregar com tudo documentado no formato javadoc: métodos, classes, exceções, etc., o que pode ser feito automaticamente à medida em que escrevem seu código: usando TDD e Eclipse, sempre documente cada método novo adicionado) - quem perde ponto aqui é por falta de atenção e de revisão antes de entregar - relatório (basta não esquecer de entregar as duas coisas que são exigidas: descrição dos patterns (sem simplesmente repetir a de milestones anteriores - adicionem novos patterns usados, expliquem melhor onde usaram de novo os antigos, etc.) e diagrama de classes (não precisa caprichar no desenho, mas precisa ter a listagem dos métodos e atributos principais) - os erros mais comuns aqui são a falta de entrega de um dos itens, ou o diagrama de classes incompleto (faltando atributos, principalmente) Tirar 10,0 no design e código é um pouco mais difícil, porque vocês têm de caprichar um pouco mais (mas não é nada do outro mundo não): - primeiramente, melhorem o que fez vocês perderem pontos em correções anteriores (as penalizações vão se acumulando) - para o design, tentem aplicar os conhecimentos que vocês estão adquirindo nas aulas (afinal, essa é uma cadeira de projeto de software) - busquem pontos onde design patterns podem ser aplicados, tentem "preparar" o design para modificações futuras, etc. - para o código, tentem sempre se perguntar se o que acabam de escrever é fácil de entender e está o mais simples que vocês podem fazer; escolham nomes representativos para os métodos e variáveis, não genéricos, como "action" ou "num"; evitem números mágicos (muita gente usa o "40" do tamanho do tabuleiro em vários pontos do código - o que aconteceria se resolvêssemos criar um tabuleiro maior?); desconfiem de métodos que estão ficando grandes ou que fazem muitas coisas ao mesmo tempo, com seqüências extensas de ifs (p.ex., os métodos da classe "Jogo" do Monopoly); finalmente, usem Eclipse para garantir endentação e organização do código automáticas Testes de aceitação ------------------- Nota base: 10,0 - 2,0 para cada us.txt que contenha testes errados Design ------ nota base: 8,0 a correção do design foi um pouco mais rígida no sentido em que os bônus só valem para a funcionalidade desse milestone, mas os ônus são acumulativos (ou seja, vocês teriam que corrigir o que saiu errado no milestone anterior); - primeiramente, deveriam ajeitar os pontos do milestone anterior (corrigir a hierarquia de Places, ajeitar atribuições incorretas, etc.); os mesmos pontos foram tirados caso não tenham sido corrigidos pontos essenciais do design para o milestone2: 1. Implementação de Cartas e Pilhas de Cartas - interface comum para as pilhas de cartas; interface comum para cartas: -0,5 para cada se não usou - cartas têm que ter uma ação associada; há cartas Chest e cartas Chance com ações comuns - capturar cartas com ações relacionadas (usar interfaces): -0,5 se não capturou ações relacionadas (repetiu código em cada carta) Ex.: cartas que avançam ou recuam os peões no tabuleiro, cartas que recebem de ou pagam a jogadores, cartas de saída livre da prisão (podem ser mantidas); cada tipo implementa uma interface específica, mais uma interface Chest ou Chance 2. Atribuições corretas - tirei 0,5 de cada elemento tratado na classe errada - tirei 1,0 de cada classe importante que falta 3. Bônus por idéias legais + 1,0 ponto por cada design interessante que funcione (relacionado ao design das funcionalidades adicionadas nesse milestone): p.ex., separar ações de cartas (permite que novas cartas no futuro possam ter mais de uma ação relacionada) Documentação ------------ nota base: 10,0 -3,0 se a documentação estiver incompleta (falta descrever parametros, valor de retorno, excecoes lancadas pelos metodos, ...) Código ------ nota base: 8,0 até +2,0 pela qualidade do código (endentação, organização em pacotes, nomes de variáveis, etc.) -1,0 se não usou loop para criação de lugares ou cartas (1 dos dois) -1,5 se não usou loop nem para lugares nem para cartas Relatório --------- - a correção foi feita comparando com a qualidade do relatório do milestone anterior; se não há descrição de novos patterns, a descrição dos patterns já usados deve estar estendida com novos exemplos de onde foram usados adicionalmente; se não usaram mais pattern nenhum, deveriam explicar. 5,0 pelo diagrama de classes 5,0 pela explicação dos patterns ***************** Alexandre/Gustavo Oliveira *********************** testes de aceitação: 10,0 design: 7,5 - pilhas de cartas usam interface (ok) - cartas usam interface (ok) - capturou ações relacionadas das cartas (ok) * possível problema: carta de ir para um lugar sabe (talvez) coisas demais: número total de lugares no tabuleiro, quando e quanto receber pelo salario, nomes de lugares, etc - separou ações das cartas (+1,0) - lugares continuam usando herança, sem hierarquia (tudo estende uma Place abstrata comum, o que obriga Utilities a implementarem getPropertyRent, getRaceValue, getTaxValue, etc.): -1,5 código: 8,5 - qualidade do código: 1,5 - usou loop para criação das cartas, mas continua não usando para criação de lugares (-1,0) documentação: 10,0 relatório: 4,0 - 4,0 pela seção dos patterns (no relatório do milestone1 de Alexandre esta seção estava mais bem exemplificada; se não usaram patterns adicionais, pelo menos deveriam ter explicado em que pontos adicionais do projeto usaram os mesmos patterns; o relatorio do milestone1 de Gustavo Oliveira menciona Abstract Factory, Layers e Creator - se não foram usados no milestone2 no projeto comum, deveria ter sido explicado) - 0,0 pelo diagrama de classes (não veio no documento Word nem dentro do zip) **************** Anne/Kézia ********************** testes de aceitação: 10,0 design: 7,5 - pilhas de cartas usam interface (ok) - cartas usam herança (estendem de uma classe abstrata comum): -0,5 - capturou ações relacionadas (ok) código: 8,0 - qualidade do código: 1,5 - não usou loop para criação de cartas e continua não usando para criação de lugares (-1,5) documentação: 10,0 relatório: 10,0 ***************** Arthur-Tomás ************************ testes de aceitação: 10,0 design: 7,5 - cartas não usam interface: -0,5 - não capturou ações relacionadas para as cartas: -0,5 - continua usando herança para lugares: -0,5 - interface Activational: +1,0 código: 7,5 - +1,0 pela qualidade - não usou loop para criação de cartas nem para criação de lugares (-1,5) documentação: 10,0 relatório: 8,5 - 3,5 pelo diagrama de classes (faltam os atributos das classes) - 5,0 pela descrição dos patterns ****************** Diego-Newton *************************** testes de aceitação: 10,0 design: 6,0 - cartas não usam interface (-0,5) - pilhas de cartas não usam interface (-0,5) - capturou ações relacionadas para as cartas através de comandos (ok) - continua usando herança para lugares (-0,5) - pilha de cartas não é um lugar (-0,5) - continua não havendo tabuleiro (lugares são inicializados em Game) (-1,0) - separou cartas de ações (+1,0) código: 9,5 - 1,5 pela qualidade - usou loop para criar lugares e cartas (ok) documentação: 10,0 relatório: 10,0 Obs.: tentem organizar melhor os próximos diagramas de classes, tem muita linha se cruzando ******************* Diego-Maria ************************** testes de aceitação: 10,0 design: 7,0 - cartas usam interface (ok) - pilhas de cartas usam interface (ok) - capturou semelhanças entre cartas (ok) - continua faltando um banco (-1,0) código: 7,5 - 1,0 pela qualidade do código - não usou loop para criar lugares nem cartas (-1,5) documentação: 9,5 - continua havendo métodos comentados, mas que não geram javadoc relatório: 10,0 ***************** Erick/Moisés ************************ testes de aceitação: 10,0 design: 6,5 - cartas usam interface (ok) - pilhas de cartas não usam interface (-0,5) - capturou ações relacionadas para as cartas através de uma hierarquia para Action (ok) - separou ações das cartas (+1,0) - não modificou a implementação dos lugares, continuam usando herança sem capturar características comuns (-1,5) - Bank continua mantendo informações sobre corridas de ferrovias, valor de Go (-0,5) código: 9,0 - +1,0 pela qualidade do código - usou XML para criação de lugares e cartas (ok) documentação: 10,0 relatório: 9,5 - 5,0 pelo diagrama de classes (tentem colocar em um diagram só nas próximas vezes) - 4,5 pela descrição dos patterns ***************** Flávio/Thiago ************************ testes de aceitação: 10,0 design: 8,0 - cartas usam interface (ok) - pilhas de cartas não usam interface (-0,5) - capturou ações relacionadas através da hierarquia de Strategy (ok) - separou ações das cartas através de classes Strategy (+1,0) - continua usando herança sem hierarquia para lugares (-1,5) - classe CardManager (+1,0) código: 8,0 - +1,5 pela qualidade do código - não usou loop para criar lugares nem cartas (-1,5) documentação: 10,0 relatório: 10,0 ***************** Flavio/Paolo ************************* testes de aceitação: 10,0 design: 9,0 - cartas usam interface (ok) - pilhas de cartas usam interface (ok) - capturou ações relacionadas através da hierarquia de Strategy (ok) - separou ações das cartas através da hierarquia de Strategy (+1,0) - interface Jail (+1,0) - lugares continuam não hierarquizados (-1,0) código: 8,5 - +2,0 pela qualidade de código - não usou loop para criar lugares nem cartas (-1,5) documentação: 10,0 relatório: 10,0 *************** Gustavo Farias/Lucas ******************* testes de aceitação: 10,0 design: 10,0 - cartas usam interface (ok) - pilhas de cartas usam interface (ok) - capturou ações relacionadas através de Commands (ok) - separou cartas de suas ações (+1,0) - criou Commands também para os lugares (+1,0) - consertou os erros de design do milestone anterior (ok) código: 8,0 - 1,5 pela qualidade do código - não usou loops para criar lugares nem cartas (-1,5) documentação: 10,0 relatório: 10,0 ***************** Helder/Dalton ********************* testes de aceitação: 10,0 design: 5,5 - cartas usam interface (ok) - pilhas de cartas não usam interface (-0,5) - capturou semelhanças entre as cartas pelas ações que executam (ok) - não separou cartas de suas ações (sem bônus) - lugares continuam sem uma hierarquia que capture características comuns (tudo implementa uma interface única) (-1,0) - continua faltando um banco (-1,0) código: 7,5 - qualidade do código (+1,0) - não usou loops para criar lugares nem cartas (-1,5) documentação: 10,0 relatório: 10,0 ***************** Halley/Marcus ************************* testes de aceitação: 10,0 design: 10,0 - cartas usam interface (ok) - pilhas de cartas usam interface (ok) - capturou ações relacionadas através de Strategies (ok) - separou cartas de suas ações (+1,0) - usou strategies também para lugares (+1,0) - consertou erros de design do milestone anterior (ok) código: 8,0 - 1,5 pela qualidade do código - não usou loops para criar lugares nem cartas (-1,5) documentação: 9,5 - alguns (poucos) métodos estão comentados mas não geram javadoc relatório: 8,5 - 4,0 pela descrição dos patterns (quase o mesmo texto do milestone1) - 4,5 pelo diagrama de classes (faltam alguns atributos) ***************** Helton/Ana Esther ************************* testes de aceitação: 10,0 design: 9,0 - cartas usam interface (ok) - pilhas de cartas usam interface (ok) - capturou ações relacionadas através de Command (ok) - separou cartas de suas ações através de commands (+1,0) código: 8,0 - +1,5 pela qualidade do código - não usou loops para criar lugares nem cartas (-1,5) documentação: 10,0 relatório: 10,0 ****************** João Arthur/Felipe ************************* testes de aceitação: 10,0 design: 7,0 - cartas não usam interface (-0,5) - pilhas de cartas não usam interface (-0,5) - agrupou ações de cartas em comportamentos relacionados (ok) - separou as cartas de suas ações (+1,0) - jogo continua sem banco (-1,0) código: 8,0 - qualidade do código +1,5 - não usou loops para criar lugares nem cartas (-1,5) documentação: 10,0 relatório: 10,0 ****************** José Ronaldo/Larissa *************************** testes de aceitação: 10,0 design: 7,0 - cartas usam interface (ok) - pilhas de cartas usam interface (ok) - capturou ações relacionadas das cartas (ok) - não separou cartas de suas ações (sem bônus) - Place continua com getRent (-0,5) - continua o erro da Deed como uma lista de propriedades (-0,5) código: 9,0 - +1,0 pela qualidade do código - lugares e cartas criadas com loop a partir de arquivo (ok) documentação: 10,0 relatório: 10,0 ********************* Katyuscia/Leandro **************************** testes de aceitação: 10,0 design: 6,5 - carta não usa interface (-0,5) - pilha de cartas não usa interface (-0,5) - capturou comportamento comum entre as cartas (ok) - separou cartas das ações que executam (+1,0) - continua sem haver um banco (-1,0) - Place continua com getPropertyRent (-0,5) código: 7,5 - qualidade do código +1,0 - não usaram loop para criar lugares e cartas (-1,5) documentação: 10,0 relatório: 10,0 ****************** Luciana/Ricardo ************************* testes de aceitação: 10,0 design: 8,5 - cartas usam interface (ok) - pilhas de cartas não usam interface (-0,5) - capturou ações relacionadas das cartas (ok) - separou cartas das ações usando command (+1,0) código: 8,0 - qualidade do código +1,5 - não usaram loop para criar lugares e cartas (-1,5) documentação: 10,0 relatório: 10,0 ****************** Pablo ************************* testes de aceitação: 10,0 design: 6,5 - cartas não usam interface (-0,5) - pilhas de cartas não usam interface (-0,5) - cartas agrupadas pelas ações (ok) - ações separadas das cartas (+1,0) - continua faltando um tabuleiro (-1,0) - lugares ainda usando herança (-0,5) código: 6,5 - qualidade do código: sem bônus (acao das cartas não está legal (métodos grandes, nomes não representativos), Jogo está complicado) - não usou loops para inicializar lugares nem cartas (-1,5) documentação: 10,0 relatório: 3,0 - relatório veio vazio (arquivo com 0 Kb) - diagrama de classes só possui os nomes das classes (sem atributos ou métodos) ******************* Rodrigo/Priscilla ************************* testes de aceitação: 10,0 design: 8,0 - cartas não usam interface (-0,5) - pilhas de cartas não usam interface (-0,5) - cartas agrupadas pelas ações associadas (ok) - cartas separadas das ações (commands) +1,0 código: 7,5 - qualidade do código +1,0 (melhorar os métodos de MonopolyGame, especialmente rollDice) - não inicializa cartas e lugares com loop (-1,5) documentação: 10,0 relatório: 10,0 (da próxima vez, por favor entreguem o diagrama de classes como uma imagem, não como ucd) ******************* Vinícius/Willames ************************** testes de aceitação: 10,0 design: 8,5 - cartas usam interface (ok) - gerenciador de cartas não usa interface (-0,5) - cartas agrupadas pelas ações (ok) - separou ações das cartas (+1,0) - corrigiram a hierarquia de lugares (ok) código: 8,0 - qualidade do código +1,5 - não usou loop para criação de cartas nem lugares (-1,5) documentação: 10,0 relatório: 9,5 - faltam atributos no diagrama de classes ******************** Antônio Carlos **************************** testes de aceitação: design: código: documentação: relatório: ================================================ MILESTONE 3 ================================================ Testes de aceitação ------------------- Nota base: 10,0 - 2,0 para cada us.txt que contenha testes errados Design ------ nota base: 8,0 continua valendo os ônus acumulativos, ou seja, teriam que ter corrigido/melhorado seu design desde o milestone anterior; adicionei 1,0 a quem corrigiu todos os problemas de design de milestones anteriores (pela falta de muitos lugares onde ganhar ponto nesse milestone) pontos essenciais do design para o milestone3: 1. Monopólio - a melhor maneira de lidar com a questão do monopólio é criar uma classe que representa um grupo de propriedades; cada propriedade sabe o grupo ao qual pertence, e pode perguntá-lo se possui um monopólio; há outras soluções possíveis, como um gerenciador de monopólios, mas o importante é desacoplar as entidades (propriedades, jogadores, etc. - uma propriedade não deve saber quem são as outras, quem são seus donos, etc.); tirei 1,0 ponto de quem não usou uma solução semelhante (código não ficou desacoplado) 2. Casas e Hotéis - sem muito mistério no design das casas e hotéis; apenas teriam que usar atribuições corretas (Expert): > a classe Banco possui a informação de quantas casas e hotéis restam, e lança as exceções apropriadas > Propriedades guardam a informação de quantas casas ou hotel possui > Títulos (ou equivalente) guardam a informação de qual aluguel corresponde ao número de casas construídas - juntamente com o item atribuições corretas dos milestones anteriores, a correção ficou: > cada elemento tratado na classe errada (-0,5) > cada classe importante que falta (-1,0) 3. Bônus por idéias legais + 1,0 ponto por cada design interessante que funcione (relacionado ao design das funcionalidades adicionadas nesse milestone). Documentação ------------ nota base: 10,0 -3,0 se a documentação estiver incompleta (falta descrever parametros, valor de retorno, excecoes lancadas pelos metodos, ...) Código ------ nota base: 8,0 até +2,0 pela qualidade do código (endentação, organização em pacotes, nomes de variáveis, etc.) - -1,0 para quem não usou loop para inicializar os valores dos aluguéis de acordo com a quantidade de casas construídas - teriam que ter corrigido o loop de inicialização de lugares e cartas; -1,5 se os dois estiverem sem loop, -1,0 se um dos dois estiver sem loop Relatório --------- - a correção foi feita comparando com a qualidade do relatório do milestone anterior; se não há descrição de novos patterns, a descrição dos patterns já usados deve estar estendida com novos exemplos de onde foram usados adicionalmente; se não usaram mais pattern nenhum, deveriam explicar. 5,0 pelo diagrama de classes 5,0 pela explicação dos patterns ***************** Alexandre/Gustavo Oliveira *********************** testes de aceitação: 10,0 design: 6,0 - colocou interface para os lugares, mas continua sem a hierarquia que evitaria que propriedades tivessem que implementar getTaxValue(), getRaceValue(), etc. e lançar exceções (-1,0) - a falta de uma classe para o grupo de propriedades força que a informação dos monopólios fique com os jogadores e surjam coisas como qntPlacesOfAGroupThePlayer() para que jogo tenha essa informação (-1,0) código: 9,0 - corrigiu criação de lugares (ok) - aluguéis com loop (ok) - qualidade do código: 1,0 documentação: 10,0 relatório: 9,0 - 5,0 pela descrição dos patterns - 4,0 pelo diagrama de classes (faltam atributos de Game e de outras classes) **************** Anne/Kézia ********************** testes de aceitação: 10,0 design: 9,5 - grupo de propriedades (ok) - manipulador de transações de compra e venda de casas: +1,0 - classe Habitação: +1,0 problemas anteriores: - cartas usam herança (estendem de uma classe abstrata comum): -0,5 código: 8,5 - qualidade do código: 1,5 - loop para aluguéis (ok) - continua não usando loop para criação de lugares (-1,0) documentação: 10,0 relatório: 10,0 ***************** Arthur-Tomás ************************ testes de aceitação: 10,0 design: 6,5 - grupo de propriedades (District) - ok problemas do milestone anterior continuam: - cartas não usam interface: -0,5 - não capturou ações relacionadas para as cartas: -0,5 - continua usando herança para lugares: -0,5 código: 6,5 - +1,0 pela qualidade - não usou loop para criação dos aluguéis (-1,0) - continua não usando loop para criação de cartas nem para criação de lugares (-1,5) documentação: 10,0 relatório: 10,0 ****************** Diego-Newton *************************** testes de aceitação: 10,0 design: 5,0 - grupo de propriedades - ok problemas do milestonen anterior que continuam: - cartas não usam interface (-0,5) - pilhas de cartas não usam interface (-0,5) - continua usando herança para lugares (-0,5) - pilha de cartas não é um lugar (-0,5) - continua não havendo tabuleiro (lugares são inicializados em Game) (-1,0) código: 9,5 - 1,5 pela qualidade - usou loop para criar aluguéis (ok) documentação: 9,5 - alguns commands não estão comentados relatório: 10,0 ******************* Diego-Maria ************************** testes de aceitação: 10,0 design: 9,0 - faltou grupo de propriedades (-1,0) - classes House e Hotel (+1,0) - corrigiu falta de banco (ok) +1,0 código: 6,5 - 1,0 pela qualidade do código - não usou loop para criar aluguéis (-1,0) - não usou loop para criar lugares nem cartas (-1,5) documentação: 9,5 - continua havendo métodos comentados, mas que não geram javadoc (verdes no Eclipse) relatório: 10,0 ***************** Erick/Moisés ************************ testes de aceitação: 10,0 design: 5,0 - faltou grupo de propriedades (-1,0) problemas de milestones anteriores: - pilhas de cartas não usam interface (-0,5) - não modificou a implementação dos lugares, continuam usando herança sem capturar características comuns (-1,5) código: 9,5 - +1,5 pela qualidade do código - aluguéis criados com loop (ok) documentação: 9,5 - novos métodos adicionados estão faltando ter exceções comentadas relatório: 10,0 ***************** Flávio/Thiago ************************ testes de aceitação: 10,0 design: 5,0 - faltou grupo de propriedades (-1,0) - pilhas de cartas não usam interface (-0,5) - continua usando herança sem hierarquia para lugares (-1,5) código: 8,5 - +1,5 pela qualidade do código - usou loop para criar aluguéis (ok) - corrigiu criação de lugares, mas cartas continuam sendo criadas sem loop (-1,0) documentação: 10,0 relatório: 8,0 no diagrama de classes: - faltam atributos de várias classes importantes, como Game - faltam classes importantes, como Player ***************** Flavio/Paolo ************************* testes de aceitação: 10,0 design: 7,0 - usou grupo de propriedades (neighborhood) - ok - lugares continuam não hierarquizados (-1,0) código: 10,0 - +2,0 pela qualidade de código - usou loop para criar aluguéis (ok) - corrigiu a criação de lugares e cartas do milestone anterior (ok) documentação: 10,0 relatório: 10,0 *************** Gustavo Farias/Lucas ******************* testes de aceitação: 10,0 design: 9,0 - grupos de propriedades (ok) - sem problemas de design nos milestones anteriores +1,0 código: 8,5 - 1,5 pela qualidade do código - cartas usam loop na criação, mas lugares continuam sem loop (-1,0) documentação: 10,0 relatório: 10,0 ***************** Helder/Dalton ********************* testes de aceitação: 10,0 design: 9,0 - grupo de propriedades (ok) - corrigiu problemas de design dos milestones anteriores (+1,0) código: 9,0 - qualidade do código (+1,0) - criação de aluguéis com loop (ok) - corrigiu criação de lugares e cartas (ok) documentação: 9,5 - novas classes têm alguns métodos sem comentários relatório: 10,0 ***************** Halley/Marcus ************************* testes de aceitação: 10,0 design: 9,0 - usou grupos de propriedades (ok) - sem erros de design anteriores (+1,0) código: 9,5 - 1,5 pela qualidade do código - criação de aluguéis com loop (ok) - corrigiu a criação de cartas e lugares (ok) documentação: 10,0 relatório: 9,5 - 4,5 pela descrição dos patterns - 5,0 pelo diagrama de classes ***************** Helton/Ana Esther ************************* testes de aceitação: 10,0 design: 8,0 - apesar de haver uma classe group, não separou a lógica do monopólio, que está em Player (-1,0) - sem problemas para corrigir dos milestones anteriores (+1,0) código: 8,5 - +1,5 pela qualidade do código - aluguéis criados com loop (ok) - não usou loops para criar cartas, apenas lugares (-1,0) documentação: 10,0 relatório: 10,0 ****************** João Arthur/Felipe ************************* testes de aceitação: 10,0 design: 8,0 - usou grupos de propriedades (ok) - classe Monopolio gerencia os monopolios (+1,0) problemas anteriores: - cartas não usam interface (-0,5) - pilhas de cartas não usam interface (-0,5) código: 7,0 - qualidade do código +1,5 - não usou loop para criação dos aluguéis (-1,0) - continua não usando loops para lugares e cartas (-1,5) documentação: 10,0 relatório: 10,0 ****************** José Ronaldo/Larissa *************************** testes de aceitação: 10,0 design: 9,0 - usou a classe GroupMonopoly (ok) - corrigiu os erros de milestones anteriores (+1,0) código: 9,0 - +1,0 pela qualidade do código - aluguéis criados com loop (ok) - lugares e cartas criadas com loop a partir de arquivo (ok) documentação: 10,0 relatório: 10,0 ********************* Katyuscia/Leandro **************************** testes de aceitação: 10,0 design: 9,0 - MonopolyConfig gerencia os monopólios (ok) - corrigiu problemas de design do milestone anterior (+1,0) código: 7,5 - qualidade do código +1,0 - usaram loop para inicializar aluguéis (ok) - continuam não usando loop para criar lugares e cartas (-1,5) documentação: 10,0 relatório: 10,0 ****************** Luciana/Ricardo ************************* testes de aceitação: 10,0 design: 8,0 - monopólios guardados em Player (-1,0) - corrigiu problemas do milestone anterior (interface para a pilha de cartas) - +1,0 código: 9,5 - qualidade do código +1,5 - usaram loop para criar lugares, cartas e aluguéis (ok) documentação: 10,0 relatório: 10,0 ****************** Pablo ************************* testes de aceitação: 10,0 design: 5,5 - não usou grupos de propriedades; monopólios em Jogador (-1,0) problemas de milestones anteriores que continuam: - continua faltando um tabuleiro (-1,0) - lugares ainda usando herança (-0,5) código: 6,0 - qualidade do código: +0,5 - não usou loops para inicializar aluguéis (-1,0) - não usou loops para inicializar lugares nem cartas (-1,5) documentação: 9,5 - alguns métodos em Jogo (adicionados nesse milestone) não geram javadoc relatório: 6,0 - 3,0 pela descrição dos patterns - 3,0 pelo diagrama de classes, que só possui os nomes das classes (sem atributos ou métodos) ******************* Rodrigo/Priscilla ************************* testes de aceitação: 10,0 design: 7,0 - não usou grupos de propriedades (monopólios em Player) -1,0 - classes House e Hotel (+1,0) problemas de milestones anteriores: - cartas não usam interface (-0,5) - pilhas de cartas não usam interface (-0,5) código: 6,5 - qualidade do código +1,0 - aluguéis inicializados sem loop (-1,0) - continua inicializando lugares e cartas sem loop (-1,5) documentação: 10,0 relatório: 10,0 ******************* Vinícius/Willames ************************** testes de aceitação: 10,0 design: 9,0 - grupos de propriedades encapsulam monopólio (ok) - corrigiu problemas de milestones anteriores (+1,0) código: 9,5 - qualidade do código +1,5 - inicialização de aluguéis com loop (ok) - corrigiu inicialização de lugares e cartas (ok) documentação: 10,0 relatório: 10,0