Projeto de Sistemas de Informação 1
Período 2005.1
 |
Sistema de Administração de Escola de Caratê
(SISAC)
Neste semestre, vocês irão projetar e implementar um sistema de informação simples
para administrar uma escola de caratê. Nessa disciplina, a análise é dada pronta para
vocês, através desse documento (leiam com bastante atenção) e, principalmente,
através dos artefatos de análise executáveis representados pelos testes de
aceitação automáticos que serão fornecidos (se você não entendeu essa frase,
comece a assistir às aulas). Um dos objetivos desse projeto é fazer com que vocês
consigam construir um sistema que passe 100% dos testes de aceitação. Se conseguirem,
significa que vocês atingiram o objetivo mais importante no desenvolvimento de software
de qualidade: atender aos requisitos do cliente. |
Os testes de aceitação acessam apenas a lógica do negócio, não a
interface com o usuário. Em um sistema qualquer, interfaces bonitas e fáceis de usar
são uma característica muito importante. Entretanto, para facilitar a vida de vocês,
só faremos a lógica de negócio do sistema, sem implementação alguma de interface com
o usuário. Também é uma regra importante separar a interface com o usuário da lógica
de negócio e fazer com que seu projeto não tenha interface com o usuário é uma forma
de você sacar esse ponto arquitetural importante.
Vocês terão que projetar e implementar o sistema de uma forma incremental. Haverá
alguns milestones e, em cada um, novas funcionalidades serão adicionadas ao sistema. As
funcionalidades estão descritas dentro de User Stories. Uma User Story consiste
de duas partes: 1) uma descrição informal do que se deseja em termos de funcionalidade e
das interações que o sistema deve suportar; 2) um conjunto formal de testes de
aceitação que, se executarem direitinho, comprovam que a funcionalidade foi implementada
como desejada. Em cada um dos milestones, haverá um conjunto de user stories que deverá
ser implementado. Aqui você encontra os testes de aceitação para
cada user story, e as instruções de como rodá-los. Antes de entregar um milestone,
sempre leia as recomendações e a listagem do que deve ser entregue.
Descrição do Projeto (em poucas palavras)
O propósito do projeto é de construir um Sistema de Administração de Escola de
Caratê para um dojo único. O sistema será construído em etapas (chamadas iterações).
Em cada iteração, certas User Stories serão desenvolvidas. O sistema mantém um
cadastro de alunos e controla o pagamento feitos por eles.Além do mais, o sistema básico
controla as faixas atingidas por cada aluno. Veja os detalhes da análise nas descrições
das user stories (há também um glossário
dos termos usados no jogo).
User stories
Milestones
Testes de aceitação
Linguagem de script
Glossário
Modelo conceitual
As User Stories levantadas inicialmente para o sistema estão mostradas abaixo. Usr
Stories são uma forma de expressar requisitos funcionais desejados para o
sistema (o que o sistema deve fazer). Observe que, no mundo real, o cliente poderá mudar
de idéia com respeito a esses requisitos funcionais. É até possível que o professor
(safado que é) altere os requisitos no meio do semestre. As User Stories foram
priorizadas pelo cliente conforme podem ver na descrição dos milestones.
Calma, calma! Vocês não terão que implementar tudo isso ...
User Story |
Título |
Breve Descrição |
| 1 |
Manter informação de contato de alunos |
Manter a seguinte informação de contato dos alunos: Nome, Endereço,
Cidade, Estado, Telefone. "Manter" significa que posso fazer 4 operações;
CRUD; Create, Read, Update, Delete. |
| 2 |
Alterar estado "matriculado" do cadastro |
Uma pessoa cadastrada poderá ser aluna ou não. Deve-se manter a data de
matrícula e a data em que o aluno deixa de ser aluno (mas sem eliminar o cadastro). Não
se deve poder remover um registro se a pessoa ainda for aluno (tipicamente, você não
joga fora seu cadastro, mesmo depois que alguém deixa de ser aluno!) |
| 3 |
Registrar pagamento |
Registrar todos os pagamentos feitos pelo aluno (valor, data, tipo). Cada
pagamento tem um tipo. Não precisa fazer cadastro de novos tipos de pagamentos. |
| 4 |
Emitir relatórios financeiros de um aluno |
A mensalidade deve ser paga na data de matrícula, todo mês. Este
relatório fornece o total pago, o total das mensalidades e o total ainda devido até uma
certa data para um certo aluno. Outro relatório fornece todos os detalhes de cada
pagamento entre duas datas. |
| 5 |
Promover um aluno para uma faixa superior |
Fazer com que um aluno possa ser promovido para uma faixa superior. Não
há necessidade de manter histórico das faixas obtidas. |
| 6 |
Convidar o aluno para exame de faixa |
Deve-se cadastrar a data para a qual o aluno foi convidado para exame de
faixa. O convite é feito via email. |
| 7 |
Imprimir o título do aluno |
O título do aluno (como membro do dojo) deve ser impresso, com o nome, a
data de matrícula e a faixa que o aluno detém. |
| 8 |
Escalonar exames de faixa |
Exames de faixa podem ser escalonados para o futuro. O exame está marcado
para uma certa data e um certo horário e tem um certo custo. Um aluno pode se matricular
para um exame para tentar receber uma nova faixa. Todas as tentativas devem ser
guardadas em histórico, junto com seu status (passou/falhou). |
| 9 |
Imprimir certificado |
O certificado de obtenção de faixa deve ser impresso com o nome do
aluno, a data do exame, a faixa recebida, etc. |
| 10 |
Trancar matrícula |
Alunos pode parar de treinar às vezes (durante férias, por exemplo). O
aluno pode trancar a matrícula no dojo. Vários trancamentos podem ocorrer. Durante o(s)
período(s) de trancamento, não há onus financeiro para o aluno, mas ele não pode
participar das atividades do dojo. Já que o trancamento e destrancamento pode ocorrer em
qualquer dia, a "mensalidade" deve ser cobrada pro-rata per diem. Claro
que os cálculos financeiros e relatório financeiros (user story 4) devem refletir esses
trancamentos. |
| 11 |
Plano especial para família (US cancelada) |
Uma "família" existe se pelos menos dois membros da mesma
família estiverem matriculados. A partir da criação da família, os membros da família
recebem desconto de 20% na mensalidade. Mensalidades passadas (antes da criação da
família) não são afetadas. Os relatório financeiros devem ser alterados para levar em
conta o "plano família". |
| 12 |
Matrícula de criança e suporte para faixas para crianças (US cancelada) |
Um aluno pode ser cadastrado como criança. Crianças têm um conjunto
maior de faixas. O número maior de faixas para crianças permite que a criança seja
promovida com mais frequência, e assim manter o interesse no esporte (uma criança de 4
anos não entenderia que é normal esperar 12 meses para ser promovido). As faixas
especiais só se aplicam para crianças. A promoção de criança para para adulto é
feita manualmente, pois depende do nível de maturidade, habilidades, etc. e não por
idade. |
Aqui você pode baixar os testes de
aceitação que você deve rodar para saber se o seu jogo está atendendo direitinho os
requisitos. Você usará o EasyAccept para rodar os testes. Veja aqui. Para poder
rodar os testes, vocês precisarão criar uma Façade que acessa a business logic do seu
jogo segundo uma linguagem de script que foi criada para os testes
de aceitação.
Detalhe: num sistema de informação real, a persistência de dados usaria
provavelmente um banco de dados. Não faremos isso aqui. A informação persistente pode
ser feita em arquivo com XML (vejam java.beans.XMLEncoder e java.beans.XMLDecoder).
Para acessar a business logic de seu programa e poder realizar os testes de
aceitação, você precisará implementar uma linguagem de script que consiste nos
comandos abaixo. Esses são os comandos usados nos testes de aceitação (us1.txt,
us2.txt, etc.). Cada um deles deve corresponder a um método na sua façade.
Obs.: por enquanto apenas estão listados os comandos usados nos testes das User
Stories 1 a 8.
<void> zeraCadastro
<String> getAtributoCliente id=<String> atributo=<String>
<void> criarCliente id=<String> nome=<String> endereco=<String> \
cidade=<String>, estado=<String> fone=<String>
<void> alterarCliente id=<String> atributo=<String> valor=<String>
<void> removerCliente id=<String>
<void> matricular id=<String> data=<String>
<void> desistir id=<String> data=<String>
<void> pagar id=<String> aluno=<String> valor=<String> data=<String> tipo=<String>
<String> getPagamento id=<String>
<String> getPagamentos aluno=<String>
<String> getPagamentos aluno=<String> dataInicial=<String> dataFinal=<String>
<void> alterarPagamento id=<String> valor=<String> data=<String> tipo=<String>
<void> removerPagamento id=<String>
<void> emiteSumarioFinanceiro id=<String> ate=<String de data> saida=<String com nome do arquivo>
<String ou int> saldo id=<String com id do aluno>
<<void> lancamentoDeMensalidades dia=<String de data de lancamento de mensalidade>
<void> setValorMensalidade valor=<String ou int com valor da mensalidade>
<void> emiteExtratoFinanceiro id=<String com id do aluno> de=<String com data inicial> ate=<String com data final> saida=<String com nome do arquivo>
<void> encerrar
<void> defineFaixas faixas=<String com cores das faixas separadas por vírgula>
<void> promoveAluno id=<String com id do aluno> faixa=<string com cor da faixa>
<String> getFaixaAluno id=<String com id do aluno>
<void> zeraLogDeMail arquivo=<String com nome do arquivo de log>
<void> convidarAluno id=<String com id do aluno> data=<String com data do convite>
<String> getDataExame id=<String com id do aluno>
void setEmail id=<String com id do aluno> email=<String com email do aluno>
void imprimeTitulo id=<String com id do aluno> arquivo=<String com nome do arquivo>
<String com id do exame> criarExame data=<String com data do exame> hora=<String com hora do exame> custo=<String ou int com custo do exame>
<String com id da matricula> matricularParaExame exame=<String com id do exame> aluno=<String com id do aluno> faixa=<String com cor da faixa>
void emiteHistoricoDeExamesDeAluno id=<String com id do aluno> saida=<String com nome do arquivo>
void emiteHistoricoDeExames saida=<String com nome do arquivo>
void emiteResultadoDeExame exame=<String com id do exame> saida=<String com nome do arquivo>
void realizarExame exame=<String com id do exame> aluno=<String com id do aluno> passou=<true ou false>
void cancelarMatricularParaExame exame=<String com id do exame> aluno=<String com id do aluno>
alterarExame exame=<String com id do exame> data=<String com data do exame> hora=<String com hora do exame> custo=<String ou int com custo do exame>
cancelarExame exame=<String com id do exame>
Teremos 4 milestones. Vejam abaixo.
Vocês vão observar que não pedi interface gráfica (Swing ou Web). Tem dois motivos:
- Não quero que você gaste tempo com GUI
- Não haverá perigo de colocar lógica de negócio na interface se não tiver GUI!
Primeiro milestone
Implemente as user stories 1,2 e 3.
Recomendações para a entrega:
Coisas que devem ser entregues:
- Código-fonte documentado
- Javadoc do código-fonte (rode o javadoc antes de mandar)
Lembre dos seguintes pontos ao entregar o resultado:
- Entregue um único arquivo zip. O nome do arquivo zip deve ser
"milestone1-joao-maria.zeep" e assim por diante (identificando o milestone e o
nome dos membros da equipe). Use a terminação zeep e não zip para driblar o gmail que
não entrega mails com attachments contendo arquivos executáveis (ele olha dentro de
attachments zip).
- Ao extrair do arquivo zip, tudo deve cair no lugar certo para ajudar minha tarefa de
testar e verificar seu trabalho .
- Posso extrair do arquivo em qualquer diretório que eu quiser na minha máquina
- Use apenas nomes de
arquivos relativos, pois nomes absolutos que poderão existir na sua máquina
poderão não existir na minha máquina.
- Use ant com os
seguintes alvos: limpa, compila, doc, testa. Só garanto que o PATH de minha máquina
permite executar ant, e os comandos java (javac, java, javadoc, ...).
- O arquivo build.xml
deve estar na raiz do seu zip
- O
comando "ant testa" deve chamar testa.bat. Esse comando executa todos os testes
de aceitação. Para poder testar a persistência corretamente, os testes devem ser
chamados individualmente. Use esse template para criar seu testa.bat.
Se preferir, pode fazer no Linux e entregar um testa.sh equivalente, mas eu testarei no
Windows, então entregue um testa.bat.
- Para
testar seu programa, usarei os seguintes comandos:
- ant
limpa compila doc testa
- Lembre
que vou brincar testar seu sistema com meus próprios testes adicionais, hehehe...
- Para ter certeza que
tudo funcione adequadamente, teste os passos acima numa máquina diferente daquela onde
você desenvolveu o software.
- Se seu projeto não
compilar, há penalidade equivalente a 4 dias de atraso (isto é, 20%). Portanto, teste
bem e em várias máquinas!
- Estarei testando seu
software com o JDK 1.5.0 ou superior. Não peça para que eu use uma versão velha de
Java.
- Não topo
editar build.xml ou arquivos .bats para acertar o classpath ou qualquer outra coisa.
- Entregue um relatório
(chamado relatorio-milestone1.doc - ou txt, ou html, ou pdf, ...) descrevendo seu design e
indicando os patterns usados e onde os usou. Seu relatório deve conter:
- Um diagrama de
classes, como modelo de design.
- Uma lista dos patterns
usados e onde foram usados.
- O projeto será
avaliado de acordo com os seguintes pesos:
- Compilação (0% - se
não compilar, não aceito o projeto)
- Execução dos testes
de aceitação (40%)
- Qualidade da
documentação (10%)
- Qualidade do design
(15%)
- Qualidade do código
(25%): Defeitos a observar no código: ausência de "data driven design" (uso de
arrays de dados em vez de código), utilização de instanceof, repetição de código,
uso de números mágicos, nomes de símbolos mal escolhidos, modularização (Say what you
want, not how to do it), cascatas de ifs ou endentação profunda de loops/testes,
consistência na codificação (padrão de codificação), má organização em pacotes,
mau tratamento de exceções, etc.
- Qualidade do
relatório (10%)
- Eis as instruções
dadas a quem vai corrigir os projetos:
- Compilação: extraia os arquivo do zip e faça
"ant limpa compila". O programa deve compilar. Se não compilar, os alunos (e o
professor) devem ser avisados imediatamente do fato. A correção desse projeto pára. O
projeto receberá uma penalidade, mesmo se for entregue depois para corrigir o problema.
- Testes de aceitação: Execute “ant
testa”. Observe se todos os testes de aceitação executam. Para a user story 1, os
testes estão em us1.txt e assim por diante. Retire 1 ponto (sobre 10) para cada testes de
aceitação que não funciona. No milestone 1, apenas us1, us2, us3 são testadas. A
partir do milestone 2, os testes das user stories de milestones anteriores devem ser
retestadas.
- Relatório: leia o relatório e dê uma nota de 0
a 10 sobre a qualidade. Deve haver duas seções (ver acima).
- Documentação: verifique a qualidade do javadoc.
Deve-se ter uma descrição de cada pacote, cada classe, cada método, cada parâmetro,
cada valor de retorno e cada exceção. Não precisa verificar todo o código. Basta fazer
um scan rápido. Dê nota de 0 a 10.
- Design: Avalie a qualidade do design examinando o
código e/ou o relatório (diagrama de classes). Verifique as entidades principais e seus
métodos. As entidades principais fazem sentido? Estão desempenhando responsabilidades
adequadas (seus atributos e métodos fazem sentido)? os relacionamentos criados fazem
sentido? Dê nota de 0 a 10.
- Código: Essa é a parte mais difícil da
correção. Examine a qualidade do código, além do design já examinado. Dê nota de 0 a
10. Defeitos a observar no código: ausência de "data driven design" (uso de
arrays de dados em vez de código), utilização de instanceof, repetição de código,
uso de números mágicos, nomes de símbolos mal escolhidos, modularização (Say what you
want, not how to do it), cascatas de ifs ou endentação profunda de loops/testes,
consistência na codificação (padrão de codificação), má organização em pacotes,
mau tratamento de exceções, etc.
Segundo milestone
Implemente
as user stories 4, 5, 6 e 7. Siga as mesmas recomendações do primeiro milestone.
Terceiro milestone
Agora, vamos brincar!
Você vai receber o projeto de outro grupo e deverá implementar as user stories 8,
9 e 10. Mude o mínimo necessário no programa que você recebeu para implementar a US.
Você deve avaliar os pontos abaixo (incluir sua avaliação no relatório). Organize seu
relatório exatamente usando as seções abaixo.
- Virtudes: Comente
as virtudes do design que você recebeu.
- Fraquezas: Comente
as fraquezas do design que você recebeu e as consequentes dificuldades que você teve
para implementar as user stories desse milestone.
- Refatoramento:
Descrever o refatoramento que você efetuou.
- Avaliação
objetiva: Dê uma nota de 0 a 10 para cada uma das áreas abaixo:
- Qualidade da
documentação
- Qualidade do design
- Qualidade do código
Quarto milestone
Vamos brincar com threads. Seus objetivos são:
- Alterar o EasyAccept para lidar com threads (baixe o código fonte do EasyAccept aqui. )
- Alterar o SISAC para permitir uso multi-thread
User Story |
Título |
Breve Descrição |
| M4.1 |
comando executeScript |
Introduza um novo comando no EasyAccept chamado ExecuteScript. O comando
é chamado assim:executeScript newThread={true|false} scriptFile=<arquivo com script de teste>
Por enquanto, só aceite newThread=false e desconsidere a questão de threads. O
comando deve executar o script de teste contido no arquivo indicado. Claro que pode haver
aninhamento de tais comandos: um script pode conte o comando executeScript para executar
um script que, por sua vez, tem outro executeScript, e assim por diante. Não há
recursão de scripts mas também não há necessidade de verificar se alguma recusrão foi
feita.
O teste de aceitação é m4_1.txt |
| M4.2 |
Execução com thread pool |
Introduza o conceito de thread pool no EasyAccept. Para isso, implemente o
seguinte comando no EasyAccept:threadPool poolsize=<numero de threads>
e faça com que o comando executeScript newThread=true ... use esse pool de threads.
O teste de aceitação é m4_2.txt. Cuidado, pois agora o ambiente é multithread e há
compartilhamento de estruturas de dados no SISAC: o SISAC vai ter que ser alterado para
ser multithread. |
| M4.3 |
Repetição de comandos |
Para estressar os testes, queremos que os threads trabalhem durante mais
tempo. Implemente um novo comando do EasyAccept que repete um comando:repeat numberOfTimes=n anyCommand ...
O teste de aceitação é m4_3.txt. |
Observe que Aluno herda de Pessoa. A entidade Pessoa poderia
sumir. Porém, ela existe no modelo devido à possibilidade (que removi depois) de fazer
torneios envolvendo pessoas que não são alunos do dojo e devido à possibilidade (que
também removi) de o dojo vender produtos para qualquer pessoa (e não só alunos). Se
quiserem simplificar o modelo, fiquem à vontade. Lembrem que o modelo de design (que
será implementado em software) não precisa seguir o modelo conceitual
entidade-por-entidade.
Pessoa: Alguém que está no cadastro do dojo. Tipicamente, uma pessoa
será aluno do dojo mas outras pessoas podem estar cadastradas (ex. quem faz pagamentos).
Além do mais, quando uma pessoa desiste de ser aluno, ela continua no cadastro.
Aluno: Uma pessoa que treina no dojo e paga mensalidade. Um aluno
poderá não pagar mensalidade se estiver com a matrícula trancada.
Faixa: Graus de habilidade obtidos pelos alunos. Inicia-se com a faixa
branca. Alunos são examinados durante um exame e, tendo sucesso, poderá ser promovidos a
uma faixa superior. As cores das faixas mudam de escolha para escola (estilos diferentes
de caratê). Nós usaremos o padrão (para adultos), em ordem de crescente habilidade:
branca, amarela, verde, marrom, preta. Para crianças, as cores das faixas são:
- branca
- branca com listra amarela
- amarela
- amarela com listra laranja
- laranja
- laranja com listra roxa
- roxa
- roxa com listra verde
- verde
- verde com listra azul
- azul
- azul com listra marrom
- marrom
- marrom com listra vermelha
- vermelha
- vermelha com listra preta
- preta
Pagamento: Uma transação efetuada par quitar uma mensalidade (ou
parte dela). Mensalidades vencem no dia do mês correspondendo ao dia da matrícula.
TipoDePagamento: A forma com a qual um pagamento foi efetuado. Os
tipos possíveis são fixos ("Cash", "Cheque", "Cartão").
Família: Duas ou mais pessoas poderão receber descontos se fizerem
parte da mesma família. A família é caracterizada por um nome.
Trancamento: Um período durante o qual o aluno não paga mensalidade
e, consequentemente, não poderá treinar no dojo, fazer exames, etc. Tipicamente usado
quando um aluno viaja, etc. Trancamentos podem ser para qualquer número de dias.
Tentativa: Uma avaliação feita de um aluno para verificar se ele
atingiu um determinado nível de habilidade. Se a tentativa for bem-sucedida, o aluno
será promovido à faixa que está sendo pleiteada. Tentativas são feitas para as faixas
na ordem (ver acima), sem pular de faixa.
Exame: Um sessão de avaliação em que um aluno deve demonstrar
certas habilidades para fazer juz a uma faixa de certa cor.