PJI29006-2014-2-Wiki do Projeto
Sistema de Controle de Acesso
Descrição
Levantamento de Requisitos
Funcionais:
R01. O Sistema deve prever a liberar de portas para usuários autorizados (ver RN03, RN04);
R02. A liberação da porta deve ser possível através de um dispositivo móvel.
R03. O Sistema deve armazenar em um “log” tanto a entrada quanto a saída das pessoas;
R04. O Sistema deve permitir criar múltiplos perfis de permissões para os usuários (Aluno/Professor/Segurança/Funcionário) (ver RN08);
R05. Deve haver em cada porta controlada uma tela para passagem de informações/mensagens aos usuários.
R06. O Sistema em sua interface gráfica deve fornecer a opção de criação e edição de mensagens fornecidas na tela de cada porta;
R07. O Sistema deve ser configurado através da interface gráfica;
R08. O Sistema deve gerenciar cadastro de usuários;
R09. O Sistema deve gerenciar cadastro de portas/salas;
R10. O Sistema deve bloquear o usuário ao ter a sua autenticação fracassada (ver RN06);
R11. O Sistema deve permitir aos usuários do tipo Administrador e Professor bloquear e desbloquear um usuário do tipo Aluno;
R12. O Sistema deve fornecer suporte para “saída de emergência”;
R13. O Sistema notificará os usuários ao término do expediente do campus (RN11);
R14. O Sistema deve desligar os equipamentos após todos os usuários saírem da sala.
R15. O Sistema deve identificar o arrombamento das portas;
Não-funcionais
R01. Escalabilidade: pode haver n usuários/portas/administradores.
R02. Segurança: somente os usuários autenticados devem ter acesso ao sistema. O hardware deve ser resistente o bastante para assegurar possíveis danos devido a ação do tempo. Os dados internos do sistema devem estar protegidos de acesso não autorizado.
R03. Disponibilidade: o sistema tolera no máximo 2 horas de indisponibilidade por mês;
R04. Comunicação: o sistema deve utilizar a infra-estrutura de redes já disponível no campus;
R05. Requisitos de facilidade de uso: o uso do sistema deve ser intuitivo e prever um mini-tutorial no próprio aplicativo.
R06. Requisitos de eficiência. o sistema deverá dar resposta ao usuário em um tempo limite T, caso expire o tempo o usuário deverá se notificado da falha.
R07. Requisitos de portabilidade. o componente móvel do sistema deve operar em múltiplas plataformas móveis.
Obs:
- em caso de queda de energia, o hardware contém uma fonte reserva de energia, que assegura um tempo extra de operação;
Atores
1. Administrador: Tem todas as permissões do sistema. Pode gerenciar professores, alunos, funcionários, salas, turmas.
2. Professor: Individuo que tem acesso a todas as salas, tem permissão de liberar salas para alunos remotamente.
3. Aluno: Individuo que esta matriculado na instituição só tem acesso a salas com autorização prévia de professor, administrador ou funcionários.
4. Banco de dados: Sistema de Terceiro responsável por armazenar dados do usuários do sistema.
5. Funcionário: Individuo que pode liberar sala para alunos ou bloquear, mas não pode reserva sala.
6. Arrombador: Individuo que tenta acessar o sistema de forma indevida.
7. Alarme de Emergência: Sistema de Terceiro responsável por realizar medidas de emergência em caso de sinistro.
8. Temporizador: Utilizado para notificação de horário de saída de usuários em salas reservadas.
Casos de Uso
CSU01
Adicionar/Alterar Usuários
Sumário: O Administrador adiciona/altera alunos, professores, funcionários e administradores.
Ator Primário: Administrador
Atores Secundários: Professor, Aluno, Funcionário, Banco de dados.
Precondições: Administrador cadastrado/autenticado no sistema
Fluxo Principal:
1. O Administrador requisita adicionar um usuário.
2. O sistema fornece lista com usuários disponíveis do BD IFSC.
3. O Administrador seleciona os usuários (ID).
4. O sistema apresenta os perfis de usuários (Professor, Aluno, Funcionário, Administrador).
5. O Administrador escolhe quais perfis de usuário deseja adicionar/altera perfil
6. Administrador confere as informações fornecidas e o sistema envia para o BD (local) do sistema e o caso de uso termina.
Pós-condições: Um aluno foi adicionado em um ou mais perfis no BC local
CSU02
Remover Usuários
Sumário: O Administrador remove alunos, professores, funcionários e administradores.
Ator Primário: Administrador.
Atores Secundários: Professor, Aluno, Funcionário, BD local.
Precondições: Administrador cadastrado/autenticado no sistema.
Fluxo Principal:
1. O Administrador requisita remover um usuário.
2. O sistema apresenta os tipos de usuários(Aluno, Professor, Funcionário, Administrador).
3. O Administrador escolhe qual tipo de usuário deseja remover.
4. O sistema requisita o ID do usuário escolhido.
5. O Administrador entra com o ID do usuário.
6. O sistema apresenta ID e pergunta se deseja realmente remover o usuário.
7. O Administrador confere os dados e confirma a remoção.
8. O sistema registra a remoção e encerra o caso de uso.
Fluxo de Exceção (5): ID inexistente (RN10)
1. Se o Administrador entrar com um ID inexistente, o sistema apresenta uma mensagem de erro e o caso de uso continua a partir do passo 4.
Fluxo Alternativo (7): Usuário errado
1. O Administrador detecta que digitou um ID errado.
2. O Administrador entra com um novo ID e o caso de uso continua a partir do passo 6.
Pós-condições: Um aluno foi removido do BD local.
Regras de Negócio: RN05, RN10, RN13.
CSU03
Bloquear/Desbloquear Usuários
Sumário: O Administrador bloqueia alunos, professores, funcionários e administradores.
Ator Primário: Administrador.
Atores Secundários: Professor, aluno, funcionário, BC local.
Precondições: Administrador cadastrado/autenticado no sistema.
Fluxo Principal:
1. O administrador requisita bloquear um usuário.
2. O sistema requisita o ID do usuário escolhido.
3. O Administrador entra com o ID do usuário.
4. O sistema apresenta ID e pergunta se deseja realmente bloquear o usuário.
5. O Administrador confere os dados e confirma o bloqueio.
6. O sistema registra o bloqueio e encerra o caso de uso.
Fluxo Alternativo (3): Usuário já bloqueado
1. O sistema apresenta ID, informa que o usuário já está bloqueado e pergunta se deseja desbloquear o usuário.
2. O Administrador confere os dados e confirma o desbloqueio.
3. O sistema registra o desbloqueio e encerra o caso de uso.
Fluxo Alternativo (5): Usuário errado
1. O Administrador detecta que digitou um ID errado.
2. O Administrador entra com um novo ID e o caso de uso continua a partir do passo 4.
Fluxo de Exceção (3): ID inexistente
1. Se o Administrador entrar um ID inexistente, o sistema apresenta uma mensagem de erro e o caso de uso continua a partir do passo 2.
Pós-condições: O usuário está bloqueado no sistema.
Regras de Negócio: RN10.
CSU04
Autenticação de usuário
Sumário: O usuário se autentica no sistema.
Ator Primário: Administrador, Professor, Aluno, Funcionário.
Precondições: Usuário cadastrado no sistema.
Fluxo Principal:
1. O sistema requisita a autenticação do usuário.
2. Usuário fornece as credenciais.
3. Sistema valida usuário e caso de uso termina.
Fluxo de Exceção (2): Informa credenciais erradas. (RN06)
1. Caso falhe N vezes usuário é bloqueado e termina caso de uso.
2. Volta para o passo 1.
Pós-condições: O usuário está autenticado no sistema.
Regras de negocio: RN06.
CSU05
Gerenciar Salas
Sumário: O administrador ou professor pode reserva ou liberar as salas para uso.
Ator Primário: Administrador, Professor.
Precondições: Autenticação de usuário administrador/professor.
Fluxo Principal:
1. O sistema mostra um mapa com as salas para o usuário.
2. Usuário escolhe a sala.
3. Sistema mostra calendário com datas/horários disponíveis e ocupados da sala.
4. Usuário escolhe uma data/horário e usuários para utilização da sala.
5. Notifica o usuário que a sala foi reservado com sucesso.
Fluxo Alternativo (4):
1. Sala reservada pelo próprio usuário na data.
2. Sistema verifica se usuário quer modificar reserva ou liberar sala.
3. Sistema começa processo de liberar a sala e envia notificação confirmando liberação para o usuário.
4. Usuário confirma liberação da sala.
5. Sistema abre janela para reconfiguração da reserva
6. Usuário reconfigura reserva.
7. Sistema notifica usuário da modificação
8. Usuário confirma modificação.
Pós-condições: Reserva/Liberação feita com sucesso.
Regras de negócio: --
CSU06
Abrir Porta pelo celular
Sumário: O usuário abre a porta via celular, utilizando um sistema de autenticação específico entre as interfaces.
Ator Primário: Usuário.
Precondições: Usuário estar autenticado (CSU4).
Fluxo Principal:
1. Usuário identifica a porta através de um código.
2. Sistema verifica se usuário pode entrar na sala.
3. Sistema salva acesso do usuário no log de entrada.
4. Sistema libera porta.
Fluxo Exceção (1): Porta não existe
1. Informa erro, notifica o administrador e volta para o passo 1.
Fluxo Exceção (2): Usuário não pode acessar a sala
1. Sistema notifica o usuário que ele não tem autorização para acessar a sala.
2. Encerra caso de uso.
Regras de negocio: RN02, RN03, RN04, RN06, RN10, RN11 e RN12.
Pós-condições: Porta aberta.
CSU07
Disparar Alarme
Sumário: O sistema dispara o alarme em caso de arrombamentos de portas.
Ator Principal: Arrombador.
Atores Secundários: --
Fluxo Principal:
1. O sistema detecta que a porta está sendo arrombada.
2. O sistema dispara o alarme.
3. O sistema apresenta uma mensagem de alerta em sua interface gráfica do usuário administrador.
4. O sistema registra em um log o local e horário em que o alarme foi disparado.
Pós-condições: O sistema avisa sobre possível arrobamento.
CSU08
Sinalizar fim de período
Sumário: Sistema notifica usuários presentes que tempo de reserva está encerrando.
Ator Primário: Temporizador.
Fluxo Principal:
1. O Temporizador notifica o sistema que o tempo de interesse foi atingido.
2. Se o usuário fica 30 min a mais do que o reservado na sala, notifica sistema de segurança.
CSU09
Abertura de emergência da porta.
Sumário: Caso ocorra sinistro e haja alguém dentro da sala, as portas devem ser abertas.
Ator Principal: Alarme de Emergência.
Atores Secundários: --
Fluxo Principal:
1. O Alarme de Emergência informa o sistema sobre sinistro.
2. O sistema verifica se há usuários dentro de alguma sala.
3. O sistema abre as portas das salas com usuários.
Pós-condições: As portas das salas com usuários estão abertas.
CSU10
Criar/Remover Salas
Sumário: Cadastro de novas salas no sistema.
Ator Principal: Administrador.
Atores Secundários: --
Fluxo Principal:
1. O sistema mostra um formulário para cadastro/modificação de sala.
2. Usuário entrará com os dados da sala (nome, ID, características).
3. Sistema confirma criação da sala e adiciona a sala ao sistema.
4. O sistema registra em log a data, horário e quem criou a sala.
Fluxo Alternativo (2):
1. Usuário tenta selecionar espaço no mapa que já possui uma sala
2. Sistema informa que já existe uma sala ali e verifica se o usuário deseja fazer alguma alteração/remover essa sala.
3. Usuário faz alteração.
4. O sistema registra em log a data, horário e quem fez alteração com a sala.
5. Sistema confirma e encerra caso de uso.
CSU11
Sair da Sala
Sumário: Procedimento para saída da sala.
Ator Principal: Usuário.
Atores Secundários: --
Precondições: Entrou na sala (CSU06), estar autenticado (CSU04).
Fluxo Principal:
1. Quando terminar de utilizar uma sala e for sair, o usuário registra sua saída.
2. Sistema salva log de saída e libera a porta.
Fluxo de Exceção (1) :
1. Usuário que reservou a sala
2. Se o usuário que está se autenticando para sair for o último usuário presente dentre os que estavam com a sala reservada, o sistema faz a saída de todos os usuários que estavam presentes que ainda não fizeram o checkout, e faz o checkout automaticamente.
CSU12
Desligar alarme
Sumário: Procedimento para desligar alarme quando disparado.
Ator Principal: Administrador, Professor, Funcionário.
Atores Secundários: --
Precondições: Alarme estar disparado, estar autenticado no sistema (CSU04).
Fluxo Principal:
1. Identificar que o alarme está ativado.
2. Desativar alarme.
3. O sistema registra em um log quem desligou o alarme.
Pós-condição: Alarme desativado.
CSU13
Chave Mestre
Sumário: Chave com identificador biométrico, capaz de abrir a porta quando não há comunicação entre a porta e o sistema.
Ator Principal: Funcionário.
Atores Secundários: --
Precondições: Usuário deve estar perto da porta com a chave mestra.
Fluxo Principal: 1 - Funcionário se autentica com a digital na chave mestre.
2 - Porta abre.
Fluxo de Exceção (1) : Falha de autenticação
1 - Sai do caso de uso.
Fluxo de Exceção (2) : Porta não abre
1 - Reinicia caso de uso.
Pós-condição: Porta aberta pela chave mestre.
CSU14
Adicionar Digital na Chave Mestre
Sumário: Funcionário adiciona sua digital no cadastro da chave mestre.
Ator Principal: Funcionário.
Atores Secundários: --
Precondições: --
Fluxo Principal:
1 - Funcionário se autentica no sistema da chave.
2 - Conectar a chave ao sistema.
3 - Funcionário coloca o dedo no sensor biométrico para cadastrar sua digital.
4 - Sistema armazena cadastro na chave mestre.
Fluxo de Exceção (1) : Digital já esta cadastrada.
1 - Sistema informa que digital já está cadastrada.
2 - Sai do caso de uso.
Pós-condição: Digital salva na chave mestre.
CSU15
Remover Digital da Chave Mestre
Sumário: Funcionário remove sua digital do cadastro da chave mestre.
Ator Principal: Funcionário.
Atores Secundários: --
Precondições: --
Fluxo Principal:
1 - Funcionário se autentica no sistema.
2 - Conectar a chave ao sistema.
3 - Funcionário procura cadastro que deseja remover do sistema.
4 - Funcionário remove a digital escolhida.
Pós-condição: Digital é removida do cadastro do sistema.
Regras de Negócio
RN01
Permissão do Administrador (RN01)
Descrição: O Administrador pode criar usuários, dar acesso/liberação de salas à eles, excluir um usuário.
RN02
Permissão do Professor (RN02)
Descrição: O Professor pode reservar um horário para acesso as salas, editar e criar mensagens, dar acesso/liberação de todas salas.
RN03
Permissão do Aluno (RN03)
Descrição: Um Aluno só entra em sala de aula se o Professor já estiver dentro dela ou se tiver a liberação de um usuário com maiores permissões.
RN04
Permissão do Funcionário (RN04)
Descrição: O Funcionário deve poder entrar nas salas de aula, mesmo elas estando fechadas.
RN05
Indentificação única (RN05)
Descrição: Cada usuário tem um ID único.
RN06
Bloqueio de usuário (RN06)
Descrição: Um usuário deve ser bloqueado caso tente se autenticar por N vezes de forma inválida.
RN07
Caso de Emergência (RN07)
Descrição: O Sistema deve abrir todas as portas em situação de emergência que possuam usuários.
RN08
Credencial de aluno (RN08)
Descrição: O Sistema deve prever a validade da credencial (Tempo de matrícula) do usuário de tipo usuário.
RN09
Autenticação com uso do Banco de dados (RN09)
Descrição: O sistema deve usar o banco de dados do IFSC.
RN10
Aunteticação dos usuários (RN10)
Descrição: O usuários devem possuir ID e Senha.
RN11
Indetificação de portas (RN11)
Descrição: Cada porta deverá possui um Código.
RN12
Notificação o Adminstrador (RN12)
Descrição: Os Administradores deveram ser notificados sobre excesso de tentativa de autenticação de usuários.
RN13
Usuário bloqueado (RN13)
Descrição: Usuários bloqueado não pode abrir nenhuma porta.
Protocolos de Comunicação
Chave Mestra - Porta
Seguindo o (CSU13), o subsistema da chave mestra enviará uma mensagem para o subsistema porta solicitando a abertura da mesma. A mensagem será composta por uma String ID(tamanho variável). Durante esta comunicação será utilizado um mecanismo para detecção de erros.
Estrutura da Mensagem
Serão utilizadas como flags de início "7E" e fim "7F". O marcador de início e fim é o "7E", e o byte sentinela, caso o byte flag apareça no meio da mensagem, será o "7D".
Método de Detecção de Erros
Será utilizado para detecção de erros o algoritmo de Checksum. Este método consiste em fazer um complemento de 1 e envia-lo em conjunto com a mensagem. Durante a verificação, é somado a mensagem com o checksum e o resultado é "0" caso tenha sido transmitido com sucesso.
Chave Mestra - Chave Mestra Servidor
Seguindo o (CSU13), o subsistema Chave Mestra será composto por duas partes: Uma chave cliente onde será feita a autenticação, e um servidor ouvindo em broadcast, que receberá essa mensagem e se comunicará com o subsistema porta. Estes sistemas se comunicarão através de uma mensagem informando qual usuário se autenticou na chave cliente e está solicitando a abertura da porta. A mensagem será composta por uma String ID(tamanho variável). Durante esta comunicação será utilizado um mecanismo para detecção de erros.
Estrutura da Mensagem
Será enviado um inteiro que será o user_id do usuário.
Método de Detecção de Erros
Será utilizado para detecção de erros o algoritmo de Checksum. Este método consiste em fazer um complemento de 1 e envia-lo em conjunto com a mensagem. Durante a verificação, é somado a mensagem com o checksum e o resultado é "0" caso tenha sido transmitido com sucesso.
Porta - Sistema
Esta interface de comunicação fará a interligação de fluxo de dados entre a Porta e o Sistema. A natureza dos dados que irão trafegar através desta interface serão:
- Primeira conexão;
- Recebimento de código da porta;
- Recebimento de sinal para abertura da porta;
- Envia sinal de arrombamento da porta;
- Envia log referente à chave mestra (caso específico);
- Recebe sinal de desligamento do buzzer (CSU12);
- Recebe sinal de ligamento do buzzer (CSU07);
Estrutura da Mensagem
Arquivo:Estruturadamsg porta-sistema.png
Sistema de correção de erros
Notas
Link para servidor REST de testes.
API Web-Service
| Método | URI | Parâmetros | Retorno (Json) | Descrição |
|---|---|---|---|---|
| @GET | /room/ | - | [{"roomId":0,"roomName":"nomedasala","ip":"192.168.1.1","mac":"macdaporta","doorOpen":false,"lock":true,"alarm":false,"enabled":true},{"roomId":1,"roomName":"nomedasala1","ip":"192.168.1.2","mac":"macdaporta1","doorOpen":false,"lock":true,"alarm":false,"enabled":true}] | Retorna todas as salas cadastradas no sistema |
| @GET | /room/{id} | int id
|
{"roomId":0,"roomName":"nomedasala","ip":"192.168.1.1","mac":"macdaporta","doorOpen":false,"lock":true,"alarm":false,"enabled":true} | Retorna a sala com id correspondente ao parâmetro |
| @GET | /room/{id}/reserves | int id
|
[{"reserveId":0,"userId":1,"roomId":2,"in":"Nov 13, 2014 3:54:12 PM","out":"Nov 13, 2014 3:54:12 PM"},{"reserveId":1,"userId":2,"roomId":3,"in":"Nov 13, 2014 3:54:12 PM","out":"Nov 13, 2014 3:54:12 PM"}] | Retorna todas as reservas relacionadas a sala com id correspondente ao parâmetro |
| @GET | /room/{id}/mac | int id
|
{"mac":AA:BB:CC:DD:EE:FF} | Retorna o MAC da sala com id correspondente ao parâmetro |
| @GET | /room/{id}/ip | int id
|
{"ip":192.168.1.1} | Retorna o IP da sala com id correspondente ao parâmetro |
| @GET | /user/ | - | [{"id":0,"name":"Danilo Bedaque","password":"ifsc123","profileId":1},{"id":1,"name":"Jean Michel","password":"pji123","profileId":1}] | Retorna todos os usuários cadastrados |
| @GET | /user/{id} | int id
|
{"id":0,"name":"Danilo Bedaque","password":"ifsc123","profileId":1} | Retorna o usuário com id correspondente ao parâmetro |
| @GET | /user/{id}/reserves/ | int id
|
[{"reserveId":0,"userId":1,"roomId":2,"in":"Nov 13, 2014 3:54:12 PM","out":"Nov 13, 2014 3:54:12 PM"},{"reserveId":1,"userId":2,"roomId":3,"in":"Nov 13, 2014 3:54:12 PM","out":"Nov 13, 2014 3:54:12 PM"}] | Retorna todas as reservas do usuário com id correspondente ao parâmetro |
| @GET | /profile/ | - | [{"id":0,"type":"Aluno","permissions":[60]},{"id":1,"type":"Professor","permissions":[44]}] | Retorna todos os perfis cadastrados |
| @GET | /profile/{id}/user | int id
|
[{"id":0,"name":"Danilo Bedaque","password":"ifsc123","profileId":1},{"id":1,"name":"Jean Michel","password":"pji123","profileId":1}] | Retorna todos os usuários do perfil com id correspondente ai parâmetro |
| @GET | /log/ | - | [{"id":0,"userId":1,"date":"Nov 13, 2014 4:31:34 PM","message":"Mensagem do log."},{"id":1,"userId":2,"date":"Nov 13, 2014 4:31:34 PM","message":"Mensagem do log2."}] | Retorna todos os registros de log |
| @GET | /log/{date} | String date
|
[{"id":0,"userId":1,"date":"Nov 13, 2014 4:31:34 PM","message":"Mensagem do log."},{"id":1,"userId":2,"date":"Nov 13, 2014 4:31:34 PM","message":"Mensagem do log2."}] | Retorna todos os registros de log em uma data passada como parâmetro |
| @POST | /room/{name} | {"nome":"nomedasala","ip":"ipdasala","mac":"macdasala"} | {"ret":0} | Cria uma sala com o nome passado como parâmetro. Retorna -1 para fracasso, 0 para sucesso, ou o id da sala caso já exista |
| @POST | /user/{name,profileId,password} | String name
int profileId
String password
|
int ret
|
Cria um usuário com os parâmetros passados. Retorna -1 para fracasso, 0 para sucesso, ou o id do usuário caso já exista |
| @POST | /profile/{type,permissions} | String type
BitSet permissions
|
int ret
|
Cria um perfil com os parâmetros passados. Retorna -1 para fracasso, 0 para sucesso, o id do perfil caso já exista |
| @POST | /reserves/{roomId, userId, in, out} | int roomId
int userId
Timestamp in
Timestamp out
|
int ret
|
Cria uma reserva em uma sala, para um usuário, com os horários de entrada e saída conforme os parâmetros. Retorna -1 para fracasso, 0 para sucesso |
| @PUT | /room/id/{name, enabled} | String name
Boolean enabled
|
int ret
|
Retorna -1 para fracasso, 0 para sucesso |
| @PUT | /room/{id}/open | int id
|
int ret
|
Abre a porta de uma sala com id correspondente ao parâmetro. Retorna -1 para fracasso, 0 para sucesso, 1 para porta já aberta |
| @PUT | /room/{id}/unlock | int id
|
int ret
|
Destrava uma sala com id correspondente ao parâmetro. Retorna -1 para fracasso, 0 para sucesso, 1 para sala já destravada |
| @PUT | /room/{id}/lock | int id
|
int ret
|
Trava uma sala com id correspondente ao parâmetro. Retorna -1 para fracasso, 0 para sucesso, 1 para sala já travada |
| @PUT | /user/{id}/{profileId, password} | int id
int profileId
String password
|
int ret
|
Edita um usuário com id correspondente ao parâmetro modificando seus atributos. Retorna -1 para fracasso, 0 para sucesso |
| @PUT | /profile/{id}/{type, permissions} | int id
String type
BitSet permissions
|
int ret
|
Edita um profile correspondente ao id. Retorna -1 para fracasso, 0 para sucesso |
| @DELETE | /room/{id} | int id
|
int ret </syntaxhighlight> |
Delete a sala com id correspondente ao parâmetro. Retorna -1 para fracasso, 0 para sucesso, 1 para sala inexistente |
| @DELETE | /room/{id}/reserves | int id
|
int ret
|
Deleta todas as reservas da sala com id correspondente ao parâmetro. Retorna -1 para fracasso, 0 para sucesso |
| @DELETE | /user/{id} | int id
|
int ret </syntaxhighlight> |
Deleta o usuário com id correspondente ao parâmetro. Retorna -1 para fracasso, 0 para sucesso, 1 para usuário inexistente |
| @DELETE | /user/{id}/reserves | int id
|
int ret
|
Deleta todas as reservas do usuário com id correspondente ao parâmetro. Retorna -1 para fracasso, 0 para sucesso |
| @DELETE | /reserves | - | int ret
|
Deleta todas as reservas. Retorna -1 para fracasso, 0 para sucesso |
| @DELETE | /reserves/{id} | int id
|
int ret
|
Deleta a reserva com id correspondente ao parâmetro. Retorna -1 para fracasso, 0 para sucesso, 1 para reserva inexistente |
| @DELETE | /profile/{id} | int id
|
int ret
|
Deleta o perfil com id correspondente ao parâmetro. Retorna -1 para fracasso, 0 para sucesso, 1 para perfil inexistente |
Notas:
1-Todas as mensagens são trocadas no formato Json.
2-Caso não queira alterar algum campo, deixar o valor do parâmetro como null.
3-Para todos os retornos, será usado o código: {"ret":0}
Mensagens entre o Sistema e a Porta
| Mensagem | Descrição | Sentido | Formato |
|---|---|---|---|
| 01 | Sistema Conecta e Envia código da porta | Sistema->Porta |
char 1+mensagem;
|
| 02 | Abrir porta | Sistema->Porta |
char 2;
|
| 03 | Ligar buzzer | Sistema->Porta |
char 3;
|
| 04 | Desligar buzzer | Sistema->Porta |
char 4;
|
| 05 | Arrombamento | Porta->Sistema |
char 5;
|
| 06 | Log Chave Mestra | Porta->Sistema |
char 6+logID;
|
Documentação no Astah
Análise de Domínio
Subsistema: Porta
Link para o arquivo .astah: Link
| Subsistema: Porta |
|---|
Diagrama de Classe de Domínio Diagramas de Comunicação       |
Subsistema: Chave-Mestra
| Subsistema: Chave-Mestra |
|---|
Diagrama de Classe de Domínio Diagramas de Comunicação   |
Subsistema: Sistema
| Subsistema: Sistema |
|---|
Diagrama de Classe de Domínio Diagramas de Comunicação        |
Subsistema: Interface Web/Móvel
| Subsistema: Interface Web/Móvel |
|---|
Diagrama de Classe de Domínio
 Diagramas de Comunicação           |
Especificação do Projeto
Subsistema: Porta
| Subsistema: Porta |
|---|
Subsistema: Chave-Mestra
| Subsistema: Chave-Mestra |
|---|
Subsistema: Sistema
| Subsistema: Sistema |
|---|
Subsistema: Interface Web/Móvel
| Subsistema: Interface Web/Móvel |
|---|
Esquemático
Subsistema: Porta
| Subsistema: Porta |
|---|
 |