Cyaneus

Pronto, Labor 0.7! (a exclamação faz parte do número de versão, pra lembrar que não é uma versão utilizável ainda.

Esta é a primeira vez que mostro o código do Labor, que estive dando uma olhada hoje. Não parece tão ruim. Corrigido o banco, falta agora implementar a reserva das máquinas de laboratório e já dá pra usar.

Como disse outra vez, já está fazendo um belo punhado de coisas (CRUD em um monte de coisas). Bem, vou trabalhar mais nele.

Depois de o código do Labor ter passado longos meses hibernando, vou ver se ainda é possível salvá-lo. Antes disso, aqui vai o modelo de dados para a tentativa. A parte de reserva por professor fica pra depois...

USUÁRIO

Refere-se ao usuário do sistema.

• id
• login
• senha
• nome - nome completo do usuário

PESSOA

Usuário do laboratório, ao qual está permitido uso individual ou
coletivo das máquinas, a depender do(s) termo(s) de responsabilidade
assinado(s).

• id
• login - login na rede. Não tem efeito algum para o Labor propriamente.
• nome - nome completo do usuário
• responsavel - data. Diz quando a pessoa assinou o termo de
  responsabilidade. Na verdade, não existirá um atributo "responsavel",
  mas sim os seguintes (um para cada termo):
  • rtuse - uso do lab
  • rtmon - monitorar lab
  • rtjob - funcionários c/pc

USOINDIVIDUAL

Tabela que aloca um determinado computador para uso individual em determinado período.

• idusuario
• idmaquina
• dia
• horainicio
  
• horafim

MÁQUINA

Cadastro de uma máquina no laboratório.

• id
• nome
• idlaboratório

LABORATÓRIO

Cadastro de laboratórios existentes.

• id
• nome

Labor está parado e o problema é simples: falta de tempo + complexidade na idéia. Não que seja muito complexo, mas é o suficiente para desmotivar quando, com um tempo longe do projeto, a gente perde um pouco a visão global.

Agora, voltando ao projeto. A seqüência de implementação escolhida por mim, creio, foi equivocada. Implementar primeiro o CRUD para cada classe simples não me parece hoje uma boa idéia. Melhor seria focar o uso.

Seqüência ideal:

• Controle de acesso (está pronto)
• Cadastro de professores (está pronto)
• Cadastro de laboratórios (está pronto)
• Reserva de laboratório (nem)
  • Verificar se está no prazo mínimo de reserva (há uma quantidade de dias mínima requerida para uma reserva, para que possamos reservar para alunos sem problemas.
  • Verificar se já está reservado no horário para outro professor

Feito isso, já teria um sistema útil, embora incompleto. Para completá-lo:

• Cadastro de aluno (pronto)
• Cadastro de computador (pronto)
• Reserva individual (ponto morto hoje, que está emperrando tudo)
  • Verificar se laboratório onde o computador se encontra está reservado para algum professor;
  • Verificar se o computador está reservado para algum outro aluno;
  • Verificar se o aluno já não usou as horas semanais de reserva a que tem direito.

Claro, quando falo de "verificar isso", "verificar aquilo", bem melhor seria checar tais pontos duplamente: antes, exibindo para o usuário apenas um conjunto "possível" de reserva; e depois, porque o seguro morreu de velho. ;-)

Também não é necessário lidar com "átomos de tempo". Na verdade, tal nível de sofisticação foi justamente o ponto técnico chave que levou o projeto a ficar parado (teve o ponto de dedicação também: falta de tempo para trabalhar o código). É incrível o quanto isso complica as coisas, inclusive as validações. Vou eliminá-lo assim que possível.

Outro ponto que facilitará bastante o agendamente (e complicará para verificar as horas semanais gastas pelos alunos, mas fazer o quê? Nem sempre se ganha em todas!) é tratar com "momento de início de uso" e "momento de fim de uso" ao invés de "momento de início de uso" e "duração". Ou seja, duas datas, ao invés de uma data e um inteiro.

Vamos ver o que ainda dá pra fazer...

Eis o padrão de URL a ser adotado no início

• /: Página inicial, com mensagem de boas-vindas.
• /login: Entrar no sistema
• /logout: Sair do sistema
• /add/user: Criar novo usuário
• /edit/user/$i: Editar usuário de ID $i
• /delete/user/$i: Remove um usuário
• /view/user: Lista todos os usuários
• /add/person: Criar novo usuário de computador/laboratório
• /edit/person/$i: Editar usuário de computador/laboratório de ID $i
• /delete/person/$i: Remove um usuário de computador/laboratório
• /view/person: Lista todos os usuários de computador/laboratório
• /view/person/$i: Mostra informações sobre usuário de computador/laboratório $i
• /add/machine: Cria nova máquina
• /edit/machine/$i: Edita máquina de ID $i
• /find/machine: Busca por máquina
• /delete/machine/$i: Remove uma máquina
• /view/machine/$i: Mostra informações sobre máquina $i
• /add/lab: Cria um novo laboratório
• /edit/lab/$i: Edita laboratório de ID $i
• /view/lab: Lista os laboratórios existentes
• /view/lab/$i: Mostra informações sobre o laboratório $i
• /add/timeatom: Cria um novo horário possível (schedule's atom)
• /edit/timeatom/$i: Edita horário de ID $i
• /view/timeatom: Visualiza os horários já cadastrados
• /view/timeatom/$i: Visualizar informações sobre horário de ID $i
• /lock/machine/$i: Reserva uma máquina para um horário válido
• /lock/lab/$i: Reserva um laboratório para um horário válido
• /relock/machine/$i: Edita reserva de máquina
• /relock/lab/$i: Edita reserva de laboratório
• /free/machine/$i: Remove reserva de uma máquina ($i sendo o ID da reserva)
• /free/lab/$i: Remove reserva de um laboratório ($i sendo o ID da reserva)
• /cal$p/machine/$i: Mostra alocação de máquina em forma de calendário mensal1
• /cal$p/lab/$i: Mostra alocação de laboratório em forma de calendário mensal1
• /cal$p/user/$i: Mostra alocação de aluno em forma de calendário mensal1
• /day$p/lab: Mostra reservas diárias de todos os laboratórios para hoje1
• /day$p/lab/$i: Mostra reservas diárias do laboratório $i para hoje1
• /day$p/machine/$i: Mostra reservas diárias da máquina $i para hoje1
• /map/$i: Mapeia laboratório $i na forma de um mapa SVG clicável

----

1 $p é uma valor inteiro com sinal (por exemplo: -3, +1). $p pode ser nulo, mas se for um valor alterará a base de referência da opção. (cal-1 mostra o mês anterior ao atual, enquanto $day+10 mostra 10 dias à frente).

Aqui está a conclusão para o levantamento inicial do Banco de Dados.

USUÁRIO

Refere-se ao usuário do sistema.

• id
• login
• senha
• nome - nome completo do usuário

PESSOA

Usuário do laboratório, ao qual está permitido uso individual ou coletivo das máquinas, a depender do(s) termo(s) de responsabilidade assinado(s).

• id
• login - login na rede. Não tem efeito algum para o Labor propriamente.
• nome - nome completo do usuário
• responsavel - data. Diz quando a pessoa assinou o termo de responsabilidade. Na verdade, não existirá um atributo "responsavel", mas sim os seguintes (um para cada termo):
  • rtuse - uso do lab
  • rtmon - monitorar lab
  • rtjob - funcionários c/pc

USOAULA

Tabela que aloca um laboratório para uso em determinado horário.

• idusuario(responsavel=true)
• idlaboratorio
• idhorario

USOINDIVIDUAL

Tabela que aloca um determinado computador para uso individual em determinado período.

• idusuario
• idmaquina
• horainicio
• duracao

HORÁRIO

Horário é uma unidade de tempo durante o qual o laboratório pode funcionar. É utilizado para reserva do laboratório. Para uso individual, podem ser delimitados períodos fora do horário.

• id
• date(dia+hora)
• duracao(int minutes)

MÁQUINA

Cadastro de uma máquina no laboratório.

• id
• nome
• idlaboratório

LABORATÓRIO

Cadastro de laboratórios existentes.

• id
• nome

Antes de iniciar o desenvolvimento (e após definir a lista de tarefas), foi trabalhado o código-base para o Labor. Está sendo utilizado, para este projeto, o PEAR.

Inicialização

• Losango (http://losango.codigolivre.org.br) foi usado como base, para ter compatibilidade com seus temas.

Template:

• PEAR: HTML_Template_PHPLib

Formulários

• PEAR: HTML_QuickForm

Persistência

• Modificação da classe YAPO, do YART (http://repositorio.viadigital.org.br/projects/yart/).

Mais bibliotecas úteis, caso necessário, serão eleitas posteriormente, dando-se preferência às fornecidas pelo PEAR.