Terceira Parte do Projeto
Paulo Borba
Centro de Informática
Universidade Federal de Pernambuco
Melhorando mais ainda o Sistema de Alocação Docente do CIn
Altere a segunda versão do sistema de alocação docente do CIn para que ele satisfaça os seguintes requisitos:
O sistema tem uma interface gráfica com menus (ao invés de números para indicar que deseja-se realizar uma dada operação) e outros componentes gráficos. Em particular, a escolha da ordem de impressão do relatório (ordem alfabética dos nomes dos professores ou ordem crescente do número de créditos) deve ser feita usando um choice ou checkboxes. Use dialogs para notificar erros cometidos pelo usuário. Esta interface deve ter as mesmas funcionalidades da interface textual existente exceto as operações relativas ao cadastro de docentes.
A interface gráfica também deve permitir a inserção de um item de alocação ao conjunto de itens mantidos no sistema. Assim, além de receber vários itens de alocação através da planilha Excel, o sistema pode receber novos itens através da interface com o usuário. Use beans se necessário, isto é, se for possível evitar duplicação de código na GUI.
O relatório de alocação por professor pode ser tanto impresso na tela da interface com o usuário quanto em um arquivo texto cujo nome é fornecido pelo usuário. Por questões de eficiência, deve-se escrever progressivamente o relatório no arquivo, não escrever de uma vez só uma string contendo todas as informações do relatório.
Quando o relatório estiver sendo gerado, deve-se apresentar um dialog com uma barra de progresso indicando o progresso da operação, como o Windows faz quando estamos copiando muitos arquivos, ou como vários browsers fazem quando estamos fazendo o download de arquivos grandes.
É possível executar várias instâncias da interface gráfica em várias máquinas, ao mesmo tempo, todas acessando a mesma fachada que está sendo executada em uma máquina servidora.
Implemente tudo em Java, seguindo as seguintes recomendações:
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.
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.
Só implemente métodos e atributos que sejam usados para implementar os serviços e modificações requisitados. Nem mais nem menos.
Siga os fatores de qualidade de software.
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.).
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.