PJI29006-2014-2-Wiki do Projeto

De MediaWiki do Campus São José
Ir para: navegação, pesquisa

Índice

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

Regras de Negócio: RN09,RN10.


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

Estruturadamsg porta-chave.png

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

Link Atualizado

Link


Subsistema: Porta

Link para o arquivo .astah: Link

Subsistema: Porta
Diagrama de Classe de Domínio
Diagrama de Classes de Domínio.png
Diagramas de Comunicação
DiComunicacao-Padrao.png
DiComunicacao-Arrombamento.png
DiComunicacao-ChaveMestre.png
DiComunicacao-DesAlarme.png
DiComunicacao-Emergencia.png
DiComunicacao-FimDePeriodo.png
DiComunicacao-Saida.png


Subsistema: Chave-Mestra

Subsistema: Chave-Mestra
Diagrama de Classe de Domínio
Diagrama de Classe - Chave Mesta.jpg
Diagramas de Comunicação
Diagrama de Comunicação - Chave Mestra.jpg
Diagrama de Comunicação - Sistema de cadastro de usuários Remover.jpg
Diagrama de Comunicação - Sistema de cadastro de usuários Cadastro.jpg


Subsistema: Sistema

Subsistema: Sistema
Diagrama de Classe de Domínio
Sistema2.png
Diagramas de Comunicação
Remover Usuários.png
Gerenciar Sala.png
Desligar Alarme.png
Bloquear Desbloquear.png
Autenticação.png
Ativar Alarme.png
Adicionar Usuários.png
Abertura de Emergência.png

Arquivo:Servidor.asta.zip


Subsistema: Interface Web/Móvel

Subsistema: Interface Web/Móvel
Diagrama de Classe de Domínio

Antigo


Arquivo Astah para o Sistema Implementado


Implementado:

WebSystemClassDiagram new2.png
Diagramas de Comunicação
SQD CSU01.png
WebSystem CMD CSU02.png
WebSystem CMD CSU03.png
WebSystem CMD CSU04&06.png
WebSystem CMD CSU07.png
WebSystem CMD CSU08.png
WebSystem CMD CSU09.png
WebSystem CMD CSU10 1.png
WebSystem CMD CSU10 2.png
WebSystem CMD CSU11.png
WebSystem CMD CSU12.png

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
Esquematico arduino.jpg