Regras do experimento:
- NÃO É PERMITIDO A COMUNICAÇÃO ENTRE OS PARTICIPANTES DO EXPERIMENTO NO SENTIDO
DE DISCUTIR E/OU TIRAR DUVIDAS SOBRE O MESMO. QUALQUER DUVIDA DEVE SER DIRECIONADA A SÉRGIO.
- NÃO É PERMITIDO O USO DE REFACTORINGS OU QUALQUER MÉTODO GERATIVO DO ECLIPSE.
- NÃO É PERMITIDO O USO DE PreparedStatement PARA A IMPLEMENTAÇÃO DAS COLEÇÕES DE DADOS PERSISTENTES.
- AS DICAS FORNECIDAS SOBRE A IMPLEMENTAÇÃO DEVEM SER SEGUIDAS POR TODOS.
- EM HIPOTESE ALGUMA O SISTEMA DEVERÁ SER UTILIZADO A NÃO SER PELA EXECUÇÃO DOS CASOS DE TESTE.
- NÃO COPIE CLASSES JAVA PARA O PROJETO VIA WINDOWS EXPLORER OU OUTRA FORMA.
A ÚNICA MANEIRA DE SE CRIAR UMA CLASSE NO PROJETO É UTILIZANDO AS OPÇÕES DE CRIAÇÃO DE CLASSE DO ECLIPSE .
- Observe os nomes dos pacotes da classes nos diagramas de classes.
- Observem a figura que está na
página sobre as diferenças do desenvolvimento com e sem o Pim.
Em ambos os casos a implementação de um segundo cenário ou caso de
uso só ocorre depois de implementar, testar, e apresentar para validação
ao cliente (Sérgio) o primeiro cenário ou caso de
uso.
- Além do exposto no item anterior, na
abordagem com o Pim a apresentação ao cliente (Sérgio) se dá depois de implementar
os requisitos funcionais e antes de iniciar a implementação dos
requisitos não-funcionais (Persistência e Distribuição). Após apresentar o sistema funcional ao cliente (Sérgio)
é feita a implementação dos requisitos não-funcionais. Após testar o sistema com os requisitos não-funcionais
não é necessário apresentar o mesmo ao cliente (Sérgio), uma vez que
os requisitos funcionais já foram validados.
- Só deve ser implementado no sistema o que for necessário para o
cenário ou caso de uso em questão. E a implementação deve sempre seguir
as especificações de casos de uso, o diagrama de classes e utilizar os
formulários e os servlets fornecidos. Isto inclui os
aspectos. Por exemplo, não há porque implementar o aspecto de
atualização de estado se ainda não foram implementadas operações de
atualização.
- Sempre que criar uma classe básica crie métodos get/set para os atributos da mesma.
Não use wizards do Eclipse para tal finalidade.
- A principio não são necessárias quaisquer
alterações ou adaptações nas classes já fornecidas do sistemas (salvo eventuais mudanças de requisitos
pedidas pelo cliente e/ou pelo analista ou indicações em contrário feitas no
plano de implementação), nos formulários, na
especificação de casos de uso, e no diagrama de classes, caso identifique algum problema
entre em contato com o analista (Sérgio) para tirar dúvidas ou solicitar alterações.
- Os testes feitos com o sistema sempre devem seguir os casos de teste,
nenhum outro tipo tipo de teste deve ser feito e/ou contabilizado na planilha de tempos.
- As interfaces negócio-dados não devem levantar RepositoryException.
Nas implementações persistentes, caso exista uma exceção específica, o aspecto que insere a
funcionalidade ou código responsável por gerar a exeção deve encapsulá-la numa
SoftException, ou seja, torná-la softened.
- O cumprimento dessas recomendações também será critério de
avaliação da disciplina, além do desenvolvimento do sistema e da
presença no laboratório em no mímino dois horários na semana. Além dos
horários normais de aula serão marcados horários alternativos que podem
ser utilizados por quem desejar adiantar o projeto ou tiver algum problema
em vir para os horários normais de aula.
