Trabalhos de MAC 441/5714

Além dos trabalhos realizados em sala de aula, teremos um projeto em várias fazes para realizar em casa.

Datas de Entrega dos Trabalhos:

Fase 1: 16/4
Fase 2: 10/5
Fase 3: 14/6
Projeto Final: 8 / 7

Marcador de Reuniões

Este é um programa que será utilizado para auxiliar na marcação de uma reunião com vários participantes. Um dos participantes, responsável pela organização da reunião, indica em qual período ele gostaria de marcar a reunião (por exemplo, entre 10 e 20 de abril); ele determina também a lista de participantes identificados pelos seus endereços eletrônicos. A seguir, cada um dos participantes indica os horários de disponibilidade e de não disponibilidade dentro do período determinado pelo organizador. O organizador então visualiza a sobreposição dos horários de todos os participantes e escolhe um horário para a reunião. Finalmente, o organizador escolhe uma sala para a reunião e uma notificação é enviada para todos os participantes (inclusive para os que se disseram indisponíveis).

Todas as suas classes deverão ser incluídas dentro de um pacote e este deve ser gravado através da opção File Out... e o respectivo arquivo deverá ser entregue através do panda.

O trabalho deve ser feito preferencialmente em grupos de 2. Grupos individuais são aceitos (a contragosto :-). Recomendo fortemente que os pares desenvolvam os programas usando programação pareada (os dois programadores sentados lado a lado compartilhando o mesmo computador)

Fase 1: Disponibilidade de horários

Para a Fase 1, que deve ser entregue após a semana do breque, em 16/4, a implementação deve se basear em uma interface de texto somente, ou seja, a visualização dos horários dos participantes será feita em modo texto utilizando-se, por exemplo, o objeto Transcript (leia sobre ele neste tutorial).

A definição dos participantes da reunião será feita através do seguinte método que deverá ser implementado na classe MarcadorDeReuniao:

marcador marqueReuniaoEntre: dataInicial E: dataFinal comParticipantes: listaDeParticipantes

as datas devem ser do tipo Date e a listaDeParticipantes é uma OrderedCollection de Strings identificando os participantes

cada participante define os seus horários disponíveis através do seguinte método:

marcador indicaDisponibilidadeDe: participante de: inicio a: fim

onde participante é um String e inicio e fim são do tipo Timestamp

e, finalmente, o método

marcador mostraSobreposicao

que, provavelmente, vai dar o maior trabalho e vai exigir mais criatividade de vocês para informar os dados de uma forma clara e elegante.

Os EPs desta fase foram testados usando um testador desenvolvido pelo Alexandre cujo código Smalltalk está disponível.

Fase 2: Reserva de Salas

Na fase 2, que deverá ser entregue após a segunda semana do breque, em 10 de maio, faremos uma classe cujo objetivo é reservar as salas para as nossas reuniões. A classe GerenciadorDeSalas deve implementar, pelo menos, os seguintes métodos:

adicionaSalaChamada: nome noLocal: local comCapacidade: numeroDePessoas obs: observacoes removeSalaChamada: nome listaDeSalas "devolve uma OrderedCollection de objetos do tipo Sala"
adicionaSala: umaSala reservaSalaChamada: nome de: timestampInicial a: timestampFinal "devolve uma Reserva"
cancelaReserva: umaReserva "Onde umaReserva é o objeto devolvido pelo método reservaSalaChamada:" reservasParaSala: umaSala "devolve uma Collection de objetos Reserva que são as reservas da respectiva sala." imprimeReservasDaSala: umaSala

Objetos do tipo Sala possuem métodos de acesso para os seguintes atributos: nome, local, capacidade e observacoes;
capacidade é um inteiro, os demais atributos são Strings.

Se a reserva for efetuada com sucesso, o método reservaSalaChamada: devolve uma instância do objeto Reserva (com métodos sala:, inicio:, e fim:, que devolvem respectivamente uma instância de sala e dois Timestamps, do início e do fim da reserva). Se a reserva falhar por qualquer motivo (p.ex. sala inexistente ou sala já reservada) o gerenciador deve obrigatoriamente lançar uma exceção e opcionalmente imprimir uma mensagem de erro.

Exemplo de uso do programa:
gerenciador := GerenciadorDeSalas new. gerenciador adicionaSalaChamada: 'B-3' noLocal: 'IME - Bloco B - Térreo' comCapacidade: 60 obs: nil. gerenciador adicionaSalaChamada: 'Auditório Antonio Giglioli' noLocal: 'IME - Bloco A - Primeiro Andar' comCapacidade: 95 obs: 'Possui projetor LCD, rede com e sem fio e lousa eletrônica'. quentura := Sala new. quentura nome: 'B-143'; local: 'IME - Bloco B - Primeiro Andar'; capacidade: 75; obs: 'No verão, é quente prá danar.'. gerenciador adicionaSala: quentura. umaReserva := gerenciador reservaSalaChamada: 'B-143' de: Timestamp now a: Timestamp now addSeconds: 60*60. gerenciador cancelaReserva: umaReserva.

Os EPs desta fase foram testados usando um testador desenvolvido pelo Alexandre cujo código Smalltalk está disponível. Para executá-los na sua imagem basta mudar os nomes do pacote espalhados neste arquivo para o nome do seu pacote e dar um file in.

Fase 3: Interface Web

Na aula do dia 29/4 o Alexandre ensinou como implementar sistemas Web em Smalltalk usando o VisualWorks Web Toolkit e sua tecnologia Smalltalk Server Pages.
O objetivo então da fase 3 é implementar uma interface Web para o nosso sistema gerenciador de reuniões incluindo tanto a marcação da reunião quanto a reserva da sala apropriada.

O formato da interface que vocês desenvolverão é totalmente livre. Mas ela será avaliada de acordo com a sua praticidade, facilidade de uso e elegância. Utilizando uma página de gerenciamento, o administrador do sistema deverá ser capaz de criar novas salas (digitando os seus atributos) e criar novos usuários para o sistema (fornecendo seus atributos e senha). Utilizando a página de acesso para usuários normais, um usuário entrará no sistema fornecendo seu email (como login-name) e senha. A partir daí ele poderá fazer 3 coisas: 1) solicitar a marcação de uma nova reunião, 2) indicar o seu horário de disponibilidade caso já haja alguma reunião sendo marcada da qual ele seja um dos participantes e 3) reservar uma sala para uma reunião. Caso o usuário tenha solicitado a marcação de uma reunião no passado, ele também terá a opção de visualizar a sobreposição dos horários dos participantes da reunião que já indicaram a sua disponibilidade.

Normalmente, a sala só será reservada após a confirmação do horário da reunião. Mas isso não é obrigatório. Deve ser possível reservar uma sala mesmo que não tenha havido o processo de marcação da reunião através do sistema.

Não é necessário, nesta fase, criptografar as senhas. Por enquanto elas podem trafegar abertamente.

O sistema deverá também fornecer informações sobre quais reuniões estão marcadas e qual a disponibilidade das salas. Pense em como fornecer estas informações de forma organizada, legível e útil para o usuário. Organize as informações na página de forma elegante, por exemplo, usando tabelas HTML.

Finalmente, lembre-se que esta especificação é bem aberta, ela indica apenas o mínimo necessário. Seja criativo, desenvolva a solução que lhe pareça ser a melhor possível para o usuário final.

Fase 4: Ajustes Finais

Nesta fase final, o objetivo é tornar o sistema completamente bem acabado de forma que ele possa ser colocado em produção em um ambiente real. Para tanto vocês deverão fazer o seguinte:

Guardar as senhas em um arquivo de forma criptografada. A página de login onde o usuário digita sua senha deve ser servida através de HTTPS de forma que a senha não transite de forma aberta pela rede.
Os dados devem ser armazenados de forma persistente. O sistema deve gerar um (ou mais) arquivos de backup de tempos em tempos. O estado do sistema deverá ser armazenado em arquivos XML ou em arquivos binários usando seriação de objetos. Cuidado para não gravar no arquivo dados inconsistentes resultantes de operações em andamento.
Quando um usuário solicita a marcação de um horário para uma reunião, o sistema deverá enviar uma mensagem (via SMTP) para todos os participantes da reunião dizendo que tal pessoa o está convidando a participar de uma certa reunião em um certo período e que ele deverá visitar uma certa página para indicar suas disponibilidades.
Além do código-fonte, entregar 3 documentos:
(estes documentos não precisam ser muito longos e detalhados, basta colocar o essencial)

Manual de instalação (explicando a um sysadmin como instalar o sistema).
Manual do usuário (para usuários comuns e administradores, explicando como usar o sistema).
Manual para programadores (contendo descrição da arquitetura interna do seu sistema e detalhes sobre a implementação).

Página de MAC 441/5714
Página do Fabio
Página do DCC