Projeto

Sistema de Alocação de Salas


Descrição geral

Deve ser implementado um sistema para alocação de salas. A interface gráfica não precisa ser caprichada, o foco da avaliação do projeto estará sobre a qualidade da API. O sistema deve possuir uma arquitetura com isolamento entre a lógica de negócio e a interface gráfica, ou seja, deve ser possível, utilizando a sua API, desenvolver uma interface gráfica para ela sem ter que alterar o código do modelo de negócio. Deve ser criada uma interface inicial via linha de comando. Em seguida, uma interface gráfica pode substituir a interface de linha de comando.

 

Objetivo

O principal objetivo do projeto é utilizar o maior número de padrões de projeto possível de forma justificável. Pense em formas de maximizar a flexibilidade do código, mas procure não forçar a utilização de padrões só por causa do escopo da disciplina. A aplicação adequada dos padrões será considerada na avaliação do projeto.

 

User Stories  

 

User Story

Título

Descrição

1

Adicionar Sala

O usuário pode adicionar salas ao sistema. Existem diferentes tipos de sala: aula normal, aula inteligente, laboratório,  conferência e videoconferência.

2

Adicionar Evento

O usuário pode adicionar eventos ao sistema. Cada evento possui um nome, datas de inicio e fim, um nome para contato e um numero de repetiçoes semanais.

3

Alocar Evento

Deve-se alocar uma sala para um evento (repetitivo ou não). O sistema deve informar as salas disponíveis que satisfaçam as restrições do evento.

4

Localizar Evento

O usuário pode localizar um evento escalonado através do nome, contato, data etc.

5

Desalocar Evento

O usuário pode desalocar um evento previamente alocado.

6

Cancelar Evento

O usuário pode cancelar um evento. Neste caso, o cancelamento remove o evento da base de dados e desvincula as possíveis alocações previamente computadas.

7

Remover Sala

O usuário pode remover salas do sistema. A remoçao de uma sala também remove as possíveis alocações que referem a mesma, mas não exclui os respectivos eventos da base de dados.

 

Milestones

O projeto será avaliado através de três milestones. Para cada milestone, os seguintes resultados devem ser apresentados:

  • Milestone 1:versão sem padrões (avaliação funcional)
    • Modelo conceitual em UML (apenas o diagrama de classes). 
    • Projeto arquitetural. 
    • Projeto de baixo nível incluindo um diagrama de classes UML. 
    • 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. 
    • 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".
    • Arquivo build.xml na raiz do projeto, para isso utilizem a ferramenta antEsse arquivo deve conter os seguintes targets:
      • limpa - deverá apagar todas as saídas do sistema e os arquivos de documentação (javadoc);
      • compila - deverá gerar todos os .class das classes do projeto. É aconselhável que os .class estejam no diretório "bin", na raiz do projeto;
      • testa - deverá executar todos os arquivos dos testes de aceitação (US01.txt, US02.txt, US03.txt, ...);
      • doc - deverá criar os arquivos .html do javadoc;
      • jar - deverá criar o executável da API do sistema com suporte a execução via linha de comando.
    • A execução se dará assim: ant limpa compila doc testa
      • Não serão admitidos erros de classpath, ou de qualquer outro tipo, no arquivo build.xml.
      • Anexem também (no mesmo zip) as dependências do projeto (.jar externos  a JVM - Ex: log4j.jar -, etc.).
      • A Interface com o usuário utilizada deve ser o console.
      • Testem os comandos em diferentes máquinas. Eles devem funcionar tanto para Windows como para Linux.
  • Milestone 2:versão com padrões (avaliação não funcional)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 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 "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. 
    • 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.
  • Milestone 3:Interface gráfica e evolução do sistema (avaliação pelo colega). Milestone 2, com camada de interface gráfica. Haverá uma troca de projetos para este milestone.
    • Diagrama de classes UML e projetos arquitetural e de baixo nível atualizados.
    • Arquivo JAR da API atualizada do sistema, denominado "salas3.jar", com suporte à execução via interface gráfica. Esta API deve implementar também as funcionalidades secretas. 
    • 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".
    • Relatório informal explicitando os pontos do projeto do colega que dificultaram a adição das novas funcionalidades, como os problemas foram resolvidos e como deveria ser o projeto para que os problemas não ocorressem.
    • Arquivo build.xml na raiz do projeto, com a mesma estrutura dos Milestones 1 e 2.

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.

 

Testes de aceitação

Aqui você poderá baixar os testes de aceitação que você deve rodar para saber se o seu sistema está atendendo direitinho os requisitos. 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

Nome

Descrição

Alocação (alocar)

Destinar. No sistema as salas são alocadas para determinados eventos.

Capacidade física

Indica o número de pessoas que podem ocupar uma determinada sala.



Escritório

Escritórios são atribuídos ao corpo docente e aos funcionários da universidade. Já que o corpo docente e os funcionários não mudam freqüentemente de escritórios, o alocador de sala não precisa lidar com escritórios.

Evento

Acontecimento que ocorre nas salas cadastradas no sistema. Por exemplo: aulas, reuniões, discussões, apresentações, conferências etc. Há dois tipos de eventos que podem ser escalonados numa sala: repetitivos e não repetitivos. Eventos repetitivos são aqueles que ocorrem nos mesmos dias da semana e nos mesmos horários durante o semestre inteiro. Um evento não repetitivo ocorre apenas uma vez.

Identificação da sala

Código único utilizado para diferenciar as salas.

Laboratório

Sala de investigação científica. Há vários tipos de laboratórios: de computação, de química, de física e de biologia. Laboratórios de química, física e biologia só podem ser usados por aulas desta área de conhecimento. Assim, um laboratório de química só pode ser utilizado por uma aula de química. Alguns laboratórios de computação são abertos e não podem ser escalonados.

Sala

Espaço físico que acomoda os eventos. Toda sala dispõe de equipamentos.

Sala de aula

Tipo de sala dedicada a disciplinas.

Sala de aula inteligente

Sala de aula normal com a adição de um computador em rede, um sistema de áudio e um projetor acoplado ao computador. Algumas salas inteligentes têm computadores para os alunos também.

Sala de aula normal

Tipo de sala de aula que possui pelo menos 1 quadro-negro ou quadro-branco e uma mesa ou pódio para o professor. Algumas salas abrigam um retroprojetor e uma tela de projeção. Outras salas têm uma TV conectada ao sistema de TV a cabo da universidade.

Sala de aula para videoconferência

Tipo de sala de aula que tem o hardware necessário (câmeras, etc.) para fazer videoconferência com lugares remotos. Uma sala de videoconferência só pode ser utilizada por aulas que estão sendo ministradas à distância, diferente de salas de conferência para videoconferências.

Salas de conferência

Salas para eventos de discussão e apresentações. Há dois tipos de salas de conferência: normal e de videoconferência. Salas de conferência normais só podem ser usadas por eventos não repetitivos. As salas não podem ser escalonadas para aulas. A única sala de videoconferência só pode ser alocada para conferências que tenham participantes remotos.