Segunda Parte do Projeto

Paulo Borba 

Centro de Informática

Universidade Federal de Pernambuco

 


Melhorando o Sistema de Alocação Docente do CIn

 

Altere a primeira versão do sistema de alocação docente do CIn para que ele satisfaça os seguintes requisitos:

  1. O código de negócio e dados não contém código de interface com o usuário. Exceções são usadas para notificar erros.

  2. Altere as classes em excel.zip para que elas não tratem as exceções, mas repassem as mesmas para que elas sejam tratadas pela interface com o usuário.

  3. Interfaces separam a camada de negócio da camada de dados do sistema.

  4. Ao invés de um array, alguma classe de java.util é usada para armazenar as várias entradas do relatório de alocação por professor.

  5. O relatório de alocação por professor pode ser impresso tanto em ordem alfabética dos nomes dos professores quanto em ordem crescente do número de créditos (opções 8 e 9 da interface com o usuário). O método sort de java.util.Collections deve ser usado para realizar a ordenação.

  6. Cada relatório de alocação por professor tem o método getIterator, que retorna um objeto do tipo java.util.Iterator. Este método deve ser usado pela interface com o usuário para navegar pelos itens do relatório quando o relatório for ser impresso.

  7. Os serviços de manutenção (inserir, remover e procurar pelo nome da disciplina) dos itens de alocação devem funcionar corretamente caso sejam invocados concorrentemente.

  8. Cada item de alocação contém uma informação sobre o curso (Turismo, Graduação em CC, etc.) associado a uma dada disciplina. 

  9. O relatório de alocação por professor é impresso como em AlocacaoPorProfessor.html, com informações sobre o curso (Turismo, Graduação em CC, etc.) e os outros professores que ministrarão cada disciplina, mas sem usar HTML. Também não precisa usar o formato de tabela, como ilustrado.

  10. Use java.math.BigDecimal, ao invés de double, para evitar erros de precisão quando calculando os créditos associados a cada professor.

Implemente tudo em Java, seguindo as seguintes recomendações:

  1. Leia muito bem a documentação das classes e métodos da API de Java antes de utilizá-los, senão você pode perder em produtividade. Por exemplo, não basta usar objetos de BigDecimal para evitar erros de precisão, é necessário também utilizar os métodos certos desta classe. Para isso é necessário uma leitura geral da documentação da classe para entender o funcionamento dos seus objetos e identificar quais as funcionalidades dos métodos da classe.

  2. Implemente uma alteração por vez (desde a sua parte na interface com o usuário até a classe básica), só passando para a próxima alteração quando a anterior for testada com sucesso. Inclusive garanta que não há regressão, isto é, você não está dando um passo para frente e dois para trás. Em outras palavras, as funcionalidades existentes devem continuar funcionando depois da alteração. Para verificar isto, você deve executar os testes anteriores na versão modificada.

  3. Só implemente métodos e atributos que sejam usados para implementar os serviços e modificações requisitados. Nem mais nem menos.

  4. Siga os fatores de qualidade de software.

  5. Teste bem o seu sistema, incrementalmente, escrevendo o código de teste em um método main para cada classe. Por exemplo, o main da fachada do sistema deve cadastrar vários professores e itens de alocação e realizar várias operações com os mesmos, verificando se estas operações estão funcionando (caso não estejam isso deve ser impresso pelo teste, assim você poderá sempre executar automaticamente os testes e só verificar o resultado final deles impresso na tela). Teste as situações mais comuns (por exemplo, array com vários elementos mas não cheio, argumento positivo, etc.) mas também as mais extremas (por exemplo, array cheio e vazio, argumento negativo ou null, etc.).

  6. Quando o seu sistema apresentar defeitos, use os recursos de depuração do JBuilder e comente linhas de código para facilitar a identificação dos defeitos. Depois de corrigidos, execute todos os testes anteriores para ter certeza que novos defeitos não foram introduzidos.