Fases
O projeto terá três fases. Cada fase é composta de milestones:
- Fase 1: versão sem padrões (avaliação funcional)
- Fase 2
- Milestone 2.1: 22/07/2016
- Milestone 2.2: 01/08/2016
- Milestone 2.3: 15/08/2016
- Fase 3
- Fase 4
Para cada milestone, os seguintes resultados devem ser apresentados:
- Fase 1:versão sem padrões (avaliação funcional)
- Modelo conceitual em UML (apenas o diagrama de classes).
- Modelo arquitetural de alto-nível.
- Arquivo JAR da API do sistema, denominado "salas1.jar", com suporte à execução via linha de comando. Esta API já deve implementar todas as funcionalidades especificadas nas user stories descritas anteriormente.
- Arquivo JAR do sistema, denominado "salas1_testes.jar", executando os casos de testes.
- Código Java da API do sistema em um arquivo compactado, denominado "salas1-src.zip".
- Documentação JavaDoc da API do sistema em um arquivo compactado, denominado "salas1-doc.zip".
- Fase 2:versão com padrões (avaliação não funcional). Entregável da Milestone 1, refatorado, de acordo com o aprendizado de padrões de projeto. Deve-se aplicar o maior número possível de padrões de projeto, desde que de forma justificável.
- Diagrama de classes UML e modelo arquitetural de alto-nível atualizados, acompanhados de uma descrição da necessidade de utilização dos padrões e de quais padrões e porque foram utilizados.
- Arquivo JAR da API atualizada do sistema, denominado "salas2.jar", também com suporte à execução via linha de comando. Esta API deve implementar todas as funcionalidades especificadas nas user stories descritas anteriormente, só que agora será avaliada por sua flexibilidade.
- Arquivo JAR do sistema, denominado "salas2_testes.jar", executando os casos de testes.
- Código Java da API atualizada do sistema em um arquivo compactado, denominado "salas2-src.zip".
- Documentação JavaDoc da API atualizada do sistema em um arquivo compactado, denominado "salas2-doc.zip".
- Arquivo build.xml na raiz do projeto, com a mesma estrutura do Milestone 1.
- Fase 3:Interface gráfica e evolução (com novos padrões, se necessário) do sistema . Milestone 3, com camada de interface gráfica e aplicação de novos padrões, se necessário.
- Diagrama de classes UML e projetos arquitetural e de baixo nível atualizados, acompanhados de uma descrição da necessidade de utilização dos padrões e de quais padrões e porque foram utilizados.
- Arquivo JAR da API atualizada do sistema, denominado "salas3.jar", com suporte à execução via interface gráfica.
- Arquivo JAR do sistema, denominado "salas3_testes.jar", executando os casos de testes.
- Código Java da API atualizada do sistema em um arquivo compactado, denominado "salas3-src.zip".
- Documentação JavaDoc da API atualizada do sistema em um arquivo compactado, denominado "salas3-doc.zip".
- Arquivo build.xml na raiz do projeto, com a mesma estrutura dos Milestones 1 e 2.
- Fase 4: Mudança de requisitos. Milestone 4, atendendo os novos requisitos e aplicação de novos padrões, se necessário.
- Diagrama de classes UML e projetos arquitetural e de baixo nível atualizados, acompanhados de uma descrição da necessidade de utilização dos padrões e de quais padrões e porque foram utilizados.
- Arquivo JAR da API atualizada do sistema, denominado "salas3.jar", com suporte à execução via interface gráfica.
- Código Java da API atualizada do sistema em um arquivo compactado, denominado "salas3-src.zip".
- Documentação JavaDoc da API atualizada do sistema em um arquivo compactado, denominado "salas3-doc.zip".
- Arquivo build.xml na raiz do projeto, com a mesma estrutura dos Milestones 1 e 2.
- Relatório descrevendo os passos necessários para adaptar a solução para atender os novos requisitos.
Importante: os arquivos referentes a cada milestone devem ser empacotados em um arquivo ZIP, de acordo com o seguinte padrão de nomenclatura (NomeSobrenomeDoAluno1-NomeSobrenomeDoAluno2_milestoneX), onde X é o número do milestone. Deve-se enviar este arquivo por e-mail para o monitor da disciplina com cópia para o professor da disciplina, de acordo com as datas já definidas. Cada dia de atraso na entrega terá um decréscimo de 10% da nota.
Testes de aceitação
Os testes de aceitação que você deve rodar para saber se o seu sistema está atendendo direitinho os requisitos estão em anexo (veja ao final desta página). Você usará o EasyAccept para rodar os testes. Para poder rodar os testes, será necessário criar uma Façade que acessa a API do seu sistema segundo a linguagem de script definida abaixo, 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).
Linguagem de script
- zerarSistema
- Apaga todos os dados mantidos no sistema.
- adicionarSala id=<String> capacidade=<int> finalidade=<String> tipo=<String>
- Adiciona uma sala ao sistema com os dados fornecidos. Para salas que não possuem classificação, o tipo é utilizado para referenciar um apelido.
- adicionarSala id=<String> capacidade=<int> finalidade=<String> tipo=<String> apelido=<String> [aberto=<Boolean>]
- Adiciona uma sala ao sistema com os dados fornecidos.
- getAtributoSala idSala=<String> atributo=<String>
- Retorna o valor do atributo de uma sala.
- adicionarEvento id=<String> nome=<String> inicio=<String> fim=<String> area=<String> contato=<String> [repeticoes=<int>]
- Adiciona um evento ao sistema com os dados fornecidos.
- getAtributoEvento idEvento=<String> atributo=<String>
- Retorna o valor do atributo de uma sala.
- alocarEvento idEvento=<String> idSala=<String>
- Aloca um evento à uma determinada sala.
- localizarEvento atributo=<String> valor=<String>
- Retorna uma lista com os eventos que satisfazem os parâmetros da busca.
- desalocarEvento idEvento=<String>
- Desaloca um evento previamente alocado.
- cancelarEvento idEvento=<String>
- Cancela um evento previamente cadastrado.
- removerSala idSala=<String>
- Remove uma sala previamente cadastrada.
Glossário