Projeto Integrador II
Alunos: João Leonardo Martins (joao.lm@aluno.ifsc.edu.br) e Vinícius Luz (vinicius.ls@aluno.ifsc.edu.br)
Objetivo Geral
Implantar tradicional caça de robôs para buscar determinados itens através de coordenadas.
Página da Disciplina
PJI2018-2
Repositório GIT:
https://github.com/viniciusluzsouza/pji2
Diagramas
| Caso de uso e descrição
|
| SR
|
|
Nome: Autentica robô
Identificador: CSU01;
Sumário: Após ter sido devidamente cadastrado, o robô é acionado pelo SS para que sua autenticação seja efetivada (isso deve ocorrer em todas as vezes que o robô é ligado ou que um novo jogo seja iniciado), isso se dá através de uma solicitação e posterior resposta do robô de qual é o endereço MAC de sua interface de rede Bluetooth;
Ator primário: Sistema Supervisório;
Precondições:
- Robô já ter sido cadastrado;
Fluxo principal:
- SS solicita o ID do robô;
- Robô responde com o MAC Address de sua interface de rede Bluetooth;
Fluxos de exceção:
- MAC address respondido não informado (problemas na obtenção do mesmo) ou endereço não cadastrado: autenticação negada e o robô não pode participar do jogo;
Nome: Recebe dados
Identificador: CSU02;
Sumário: Com cadastro e autenticação previamente concluídas, o SR tem condições de receber os dados do jogo do SS: coordenadas inicial e das caças, modo de operação, etc.;
Ator primário: Sistema Supervisório;
Precondições:
- Robô já ter sido cadastrado;
- O robô já ter se autenticado;
Fluxo principal:
- SS envia os dados para início do jogo;
- SR processa os dados e define sua posição inicial e mapeia as caças do jogo;
Nome: Modo de operação automático
Identificador: CSU03;
Sumário: Uma vez definido como operação automática, o algoritmo de busca das caças anteriormente declaradas através de coordenadas é executado, tendo como fonte de informação os sensores do robô - luminosidade (cor) e ultrassônico(distância), além de contar com os motores para deslocamento;
Atores primários: Sensores, Motores;
Precondições:
- Ter recebido os dados com sucesso;
- Posição inicial correta (0,0 ou 20,20);
Fluxo principal:
- Acionar sensores;
- Acionar motores;
- Ao se deparar com uma caça, enviar informação ao SS;
Fluxo de exceção:
- Obstáculo próximo (mudar trajetória);
- Se pausa/fim de jogo, voltar ao ponto inicial;
- Se recebe falha de validação da caça;
Nome: Modo de operação manual
Identificador: CSU04;
Sumário: Neste modo, apenas o sensor ultrassônico é habilitado de modo a evitar colisões. O controle do robô e envio das informações de caças não ficam a cargo do SR;
Ator primário: Sistema Supervisório, Motores;
Precondições:
- Posição inicial correta (0,0 ou 20,20);
Fluxo principal:
- Executar código para evitar colisões;
- Obter informações de deslocamento do SS e acionar os motores;
Fluxo de exceção:
- Alterar rota devido à distância do obstáculo;
|
| SS
|
|
Nome: Cadastrar robô
Identificador: CSU01;
Sumário: Trata-se da inserção de novo robô no sistema, ou seja, o SA envia a solicitação ao SS, que trata do cadastro de um novo robô através de seus identificadores: cor e MAC address;
Ator primário: Sistema Auditório;
Precondições:
- Robô já ter acesso à rede;
Fluxo principal:
- SA informa o cadastro do robô com determinados identificadores;
- SS confirma os identificadores com o SR;
Fluxos de exceção:
- Em caso de divergência nas informações passadas pelo SA e as respondidas pelo SR, o robô não é autorizado a participar do jogo, ou seja, o cadastro não acontece;
Nome: Solicitar status
Identificador: CSU02;
Sumário: Verificar se os robôs cadastrados ainda estão disponíveis;
Ator primário: Sistema Auditório;
Precondições:
- Robô já ter sido cadastrado;
Fluxo principal:
- De tempo em tempo o SA envia uma solicitação ao SS de cada robô para verificar o status do mesmo (poll), caso não haja uma partida em andamento;
- SS responde à solicitação (por exemplo: ICMP);
Fluxos de exceção:
- Caso não haja resposta, o SA conclui que o robô se desconectou;
Nome: Configurar jogo
Identificador: CSU03;
Sumário: SA informa ao SS de cada robô o modo de jogo e as informações pertinentes a cada modo;
Atores primários: Sistema Auditório;
Precondições:
- Robô já ter sido cadastrado e autenticado;
Fluxo principal:
- Definir modo de jogo dos robôs;
- Passar informações como coordenadas de caças, posição inicial, etc;
Nome: Interface
Identificador: CSU04;
Sumário: Interface para o usuário final;
Ator primário: Usuário;
Fluxo principal:
- Realizar movimentação do robô caso a configuração de jogo definida pelo SA seja manual;
- Acompanhar o estado da partida se em modo autônomo;
|
|
| Classes
|
| Sensores
|
 Diagrama de Classe - Motor  Diagrama de Classe - Sensor |
|
| Sequência
|
| SR
|
 Diagrama de Sequência - SS vs SR |
| SS
|
 Diagrama de Sequência - SS |
|
Requisitos
| Funcionais
|
- RF01 O sistema deve permitir criação e gerência de cadastro de um robô.
- [SA] - O que deve ter neste cadastro? Como deve ser feito o cadastro, web?
- Sugestão: usuário, senha, nome. Cadastro via Web.
- RF02 O sistema de deve manter um histórico das partidas realizadas.
- [SA] - Qual tamanho do histórico?
- Sugestão: O histórico deve manter o resultado das últimas com o nome dos robôs participantes.
- Sugestão: 100 últimas partidas.
- RF03 O sistema deve ser capaz de fazer a autenticação dos robôs cadastrados.
- [SA] - Em que momento é feita a autenticação?
- Sugestão: a autenticação será ao iniciar uma partida. Antes de iniciar, solicitar partida.
- RF04 Os robôs devem ser capazes de operar nos modos manual e autônomo.
- [SR] - Existe algum requisito sobre o modo manual? Por onde o robo deve ser guiado?
- Sugestão: interface onde se possa utilizar as setas direcionais do teclado.
- RF05 O sistema deve validar e contabilizar as caças já encontradas pelo robô.
- [SA] - Afinal, o que será a caça? Como validar?
- RF06 O sistema deve dar início a partida, sortear os locais das caças e informá-los aos robôs.
- [SA] - Sortear os locais e informar, ou fazer tudo junto? Isso pode mudar a estratégia do robô. Onde será o início?
- Sugestão: primeiro sortear a informar os locais das caças. Depois iniciar.
- Sugestão: início no canto do tabuleiro.
- RF07 O sistema deve prover uma interface de monitoramento para o robô em modo autônomo.
- [SR] - Há algum requisito para a interface de monitoramento?
- Sugestao: o sistema deve conter o número de caças encontradas e o trajeto realizado. Poderá ser feito via mensagens na tela.
- RF08 O sistema deve prover uma interface de controle e monitoramento para o robôs em modo manual.
- [SR] - Existe algum requisito sobre o modo manual? Por onde o robo deve ser guiado?
- Sugestão: interface onde se possa utilizar as setas direcionais do teclado.
- RF09 O sistema deve permitir que, quando em modo autônomo, o robô execute os movimentos programados a partir do algoritmo implementado.
- [SR] - OK
- RF010 O sistema deve permitir pausa e reset da partida.
- [SA] - No reset, os robôs devem voltar ao início ou fazemos manualmente?
- Sugestão: Fazer manualmente.
- RF011 O sistema deve permitir que os resultados do jogo sejam vistos pelos espectadores em tempo real.
- [SA] - Há algum requisito para esta visualização?
- Sugestão: Interface web simples, com o placar do jogo.
- RF012 O sistema não deve permitir que os robôs se choquem.
- [SR] - OK
- RF013 O sistema deve declarar um vencedor assim que todas as caças forem encontradas.
- [SA] - OK, e os robôs devem parar as suas buscas.
- RF014 Antes de iniciar a partida, o sistema deve verificar a posição atual dos robôs.
- [SA] - Este requisito será necessário caso o ponto de partida seja sempre o mesmo (RF006).
- RF015 Após capturar uma caça, o robô deve avisar o SS, que por sua vez, deve avisar o SA para validação da caça. Esta validação deve retornar ::ao SR, confirmando-a ou não.
|
| Não funcionais
|
- RNF01 A interface do sistema de comunicação com o usuário deve ser intuitiva.
- [SA] - Como será essa interface, afinal? Web?
- RNF02 O tabuleiro será composto por linhas pretas e todos com cor.
- [SR] - Como assim? Não entendi.
- Pelo que entendi, as linhas pretas (algo como uma fita isolante), serão utilizadas para limitar os quadrados coloridos, que terão diversas ::cores e somente uma ou outra será considerada caça.
- RNF03 O tabuleiro terá as dimensões definidas (2m x 2m).
- OK
- RNF04 O tabuleiro será composto por 100 quadrados de dimensões: 20cm x 20cm.
- OK
- RNF05 O tabuleiro será limitado por uma borda vermelha.
- OK
- RNF06 O placar mostrado aos usuários deve ser de fácil identificação.
- OK, web?
- RNF07 O robô deve ter uma cor para identificação.
- Cada robô possui uma cor pré-definida ou o SA define no momento da partida?
- O robô deve ter uma etiqueta de identificação.
|
Diário das Aulas
30/7/18
| Aula 1
|
|
- Definição do grupo;
- Aula expositiva;
- Organização das tarefas através da ferramenta Trello;
|
6/8/18
| Aula 2
|
|
- Efetuada a leitura da documentação do EV3-Python: apesar do bot já possuir o linux instalado, estudamos como seria a implementação do mesmo;
- Início da montagem do robô: encontramos algumas dificuldades pois o equipamento estava completamente desmontado, com isso, até entendermos que a montagem seria basicamente livre, sofremos um pouco na idealização do EV3;
- Alinhamento sobre comunicação com o robô: ficou definido que vamos utilizar um adaptador wi-fi no mesmo, sendo assim, um terceiro equipamento se fez necessário, uma vez que a o EV3 não conecta na rede do Instituto;
- Alguns exemplos de implementação foram observados na documentação do EV3, conforme pode ser obtido através destes links: Exemplos Motor e Exemplos Sensor
- Diagrama Geral do Projeto:
 Diagrama Geral do Projeto
| Classe Motor
|
Diagrama de Classe - Motor |
| Classe Sensor
|
Diagrama de Classe - Sensor |
| Requisitos Funcionais
|
|
- RF01 O sistema deve permitir criação e gerência de cadastro de um robô.
- [SA] - O que deve ter neste cadastro? Como deve ser feito o cadastro, web?
- Sugestão: usuário, senha, nome. Cadastro via Web.
- RF02 O sistema de deve manter um histórico das partidas realizadas.
- [SA] - Qual tamanho do histórico?
- Sugestão: O histórico deve manter o resultado das últimas com o nome dos robôs participantes.
- Sugestão: 100 últimas partidas.
- RF03 O sistema deve ser capaz de fazer a autenticação dos robôs cadastrados.
- [SA] - Em que momento é feita a autenticação?
- Sugestão: a autenticação será ao iniciar uma partida. Antes de iniciar, solicitar partida.
- RF04 Os robôs devem ser capazes de operar nos modos manual e autônomo.
- [SR] - Existe algum requisito sobre o modo manual? Por onde o robo deve ser guiado?
- Sugestão: interface onde se possa utilizar as setas direcionais do teclado.
- RF05 O sistema deve validar e contabilizar as caças já encontradas pelo robô.
- [SA] - Afinal, o que será a caça? Como validar?
- RF06 O sistema deve dar início a partida, sortear os locais das caças e informá-los aos robôs.
- [SA] - Sortear os locais e informar, ou fazer tudo junto? Isso pode mudar a estratégia do robô. Onde será o início?
- Sugestão: primeiro sortear a informar os locais das caças. Depois iniciar.
- Sugestão: início no canto do tabuleiro.
- RF07 O sistema deve prover uma interface de monitoramento para o robô em modo autônomo.
- [SR] - Há algum requisito para a interface de monitoramento?
- Sugestao: o sistema deve conter o número de caças encontradas e o trajeto realizado. Poderá ser feito via mensagens na tela.
- RF08 O sistema deve prover uma interface de controle e monitoramento para o robôs em modo manual.
- [SR] - Existe algum requisito sobre o modo manual? Por onde o robo deve ser guiado?
- Sugestão: interface onde se possa utilizar as setas direcionais do teclado.
- RF09 O sistema deve permitir que, quando em modo autônomo, o robô execute os movimentos programados a partir do algoritmo implementado.
- [SR] - OK
- RF010 O sistema deve permitir pausa e reset da partida.
- [SA] - No reset, os robôs devem voltar ao início ou fazemos manualmente?
- Sugestão: Fazer manualmente.
- RF011 O sistema deve permitir que os resultados do jogo sejam vistos pelos espectadores em tempo real.
- [SA] - Há algum requisito para esta visualização?
- Sugestão: Interface web simples, com o placar do jogo.
- RF012 O sistema não deve permitir que os robôs se choquem.
- [SR] - OK
- RF013 O sistema deve declarar um vencedor assim que todas as caças forem encontradas.
- [SA] - OK, e os robôs devem parar as suas buscas.
- RF014 Antes de iniciar a partida, o sistema deve verificar a posição atual dos robôs.
- [SA] - Este requisito será necessário caso o ponto de partida seja sempre o mesmo (RF006).
- RF015 Após capturar uma caça, o robô deve avisar o SS, que por sua vez, deve avisar o SA para validação da caça. Esta validação deve retornar ::ao SR, confirmando-a ou não.
|
| Requisitos Não Funcionais
|
- RNF01 A interface do sistema de comunicação com o usuário deve ser intuitiva.
- [SA] - Como será essa interface, afinal? Web?
- RNF02 O tabuleiro será composto por linhas pretas e todos com cor.
- [SR] - Como assim? Não entendi.
- Pelo que entendi, as linhas pretas (algo como uma fita isolante), serão utilizadas para limitar os quadrados coloridos, que terão diversas ::cores e somente uma ou outra será considerada caça.
- RNF03 O tabuleiro terá as dimensões definidas (2m x 2m).
- OK
- RNF04 O tabuleiro será composto por 100 quadrados de dimensões: 20cm x 20cm.
- OK
- RNF05 O tabuleiro será limitado por uma borda vermelha.
- OK
- RNF06 O placar mostrado aos usuários deve ser de fácil identificação.
- OK, web?
- RNF07 O robô deve ter uma cor para identificação.
- Cada robô possui uma cor pré-definida ou o SA define no momento da partida?
- O robô deve ter uma etiqueta de identificação.
|
| Papéis dos Atores
|
| Ator |
Papel
|
| Usuário |
Iniciar partida em modo autônomo
|
| Usuário |
Iniciar partida em modo manual
|
| Usuário |
Controlar robô em busca de caças no modo manual
|
| Usuário |
Monitorar robô em modo autônomo
|
| Usuário |
Posicionar o robô para o início da partida
|
| SS |
Informar ao robô onde estão as caças
|
| SS |
Informar ao robô se a caça encontrada foi validada
|
| SS |
Informar ao robô sobre o início da partida
|
| SS |
Informar ao robô sobre o término da partida
|
| SS |
Informar ao robô se a autenticação foi validada
|
| SS |
Informar ao robô sobre pausas na partida
|
| Onde: SS - sistema supervisório; Usuário - jogador
|
|
| Casos de Uso
|
|
- Construção diagramasr.png de diagrama UML conforme bibliografia:
 Imagem 1: diagramas de casos de uso para o SR |
|
13/8/18
| Aula 3
|
|
Levantamentos sobre discussões em sala
Alteração da definição do diagrama geral do projeto.
| Diagrama Geral do Projeto
|
|
|
Pontos levantados a respeito dos requisitos de projeto.
| Considerações sobre requisitos do projeto
|
|
Sistema Robô [SR]
- Deve ter um ID para validação e será baseado no MAC do Bluetooth do robô;
- A posição inicial sempre será (0,0) ou (20,20);
- A cor do robô será definida no momento do cadastro no SA.
Sistema Supervisório [SS]
- Modo manual: movimentações para direita, esquerda, cima e baixo;
- Não há requisitos para a interface com usuário, poderá ser web, desktop, etc;
- A caça será uma coordenada, que varia de (0,0) a (20,20);
- No modo automático, o monitoramento do robô deverá exibir informações sobre as caças encontradas e a sequência de movimentações;
- Para reinício da partida, o jogador deverá reposicionar manualmente o robô nas posições iniciais;
- SS deverá informar ao SA que está pronto para iniciar uma partida;
- O robô deverá parar enquanto aguarda a validação da caça.
Sistema Auditoria [SA]
- A validação da caça deverá ser manual;
- O SA deverá informar o SS do início da partida, já com a localização das caças.
|
Códigos executados para testes no robô.
| Código teste motor
|
|
- !/usr/bin/env python3
from ev3dev.ev3 import *
import time
m_l = Motor(OUTPUT_B)#left motor
m_r = Motor(OUTPUT_C) #right motor
- run forward for tree seconds:
m_l.run_timed(time_sp=3000, speed_sp=500)
m_r.run_timed(time_sp=3000, speed_sp=500)
time.sleep(2)
- run "forever"
for x in range(0,500):
x=x+1
m_l.run_forever(speed_sp=50)
m_r.run_forever(speed_sp=50)
if x ==500:
m_l.stop(stop_action='brake')
m_r.stop(stop_action='brake')
- turn back
m_l.run_timed(time_sp=3000, speed_sp=-500)
m_r.run_timed(time_sp=3000, speed_sp=-500)
time.sleep(2)
for y in range(0,500):
y=y+1
m_l.run_forever(speed_sp=-50)
m_r.run_forever(speed_sp=-50)
if y ==500:
m_l.stop(stop_action='brake')
m_r.stop(stop_action='brake')
- rotate
m_l.run_timed(time_sp=3000, speed_sp=500)
time.sleep(3)
m_r.run_timed(time_sp=3000, speed_sp=500)
</syntaxhighlight>
|
| Código teste luminosidade
|
|
- !/usr/bin/env python3
from ev3dev.ev3 import *
from time import sleep
- Connect EV3 color sensor and check connected.
cl = ColorSensor()
assert cl.connected, "Connect a color sensor to any sensor port"
- Put the color sensor into COL-REFLECT mode
- to measure reflected light intensity.
- In this mode the sensor will return a value between 0 and 100
cl.mode='COL-REFLECT'
while True:
print(cl.value())
sleep(1)
</syntaxhighlight>
|
| Código teste distância
|
|
- !/usr/bin/env python3
from ev3dev.ev3 import *
import time
m_l = Motor(OUTPUT_A)#left motor
m_r = Motor(OUTPUT_D) #right motor
us = UltrasonicSensor()
us.mode='US-DIST-CM'
units = us.units
distance = us.value()/10
print(str(distance) + " " + units)
while True:
distance = us.value()/10
print(str(distance) + " " + units)
time.sleep(1)
</syntaxhighlight>
|
Ajustes no Diagrama UC do SR
| Diagrama UC do SR - descrição
|
|
Nome: Autentica robô
Identificador: CSU01;
Sumário: Após ter sido devidamente cadastrado, o robô é acionado pelo SS para que sua autenticação seja efetivada (isso deve ocorrer em todas as vezes que o robô é ligado ou que um novo jogo seja iniciado), isso se dá através de uma solicitação e posterior resposta do robô de qual é o endereço MAC de sua interface de rede Bluetooth;
Ator primário: Sistema Supervisório;
Precondições:
- Robô já ter sido cadastrado;
Fluxo principal:
- SS solicita o ID do robô;
- Robô responde com o MAC Address de sua interface de rede Bluetooth;
Fluxos de exceção:
- MAC address respondido não informado (problemas na obtenção do mesmo) ou endereço não cadastrado: autenticação negada e o robô não pode participar do jogo;
Nome: Recebe dados
Identificador: CSU02;
Sumário: Com cadastro e autenticação previamente concluídas, o SR tem condições de receber os dados do jogo do SS: coordenadas inicial e das caças, modo de operação, etc.;
Ator primário: Sistema Supervisório;
Precondições:
- Robô já ter sido cadastrado;
- O robô já ter se autenticado;
Fluxo principal:
- SS envia os dados para início do jogo;
- SR processa os dados e define sua posição inicial e mapeia as caças do jogo;
Nome: Modo de operação automático
Identificador: CSU03;
Sumário: Uma vez definido como operação automática, o algoritmo de busca das caças anteriormente declaradas através de coordenadas é executado, tendo como fonte de informação os sensores do robô - luminosidade (cor) e ultrassônico(distância), além de contar com os motores para deslocamento;
Atores primários: Sensores, Motores;
Precondições:
- Ter recebido os dados com sucesso;
- Posição inicial correta (0,0 ou 20,20);
Fluxo principal:
- Acionar sensores;
- Acionar motores;
- Ao se deparar com uma caça, enviar informação ao SS;
Fluxo de exceção:
- Obstáculo próximo (mudar trajetória);
- Se pausa/fim de jogo, voltar ao ponto inicial;
- Se recebe falha de validação da caça;
Nome: Modo de operação manual
Identificador: CSU04;
Sumário: Neste modo, apenas o sensor ultrassônico é habilitado de modo a evitar colisões. O controle do robô e envio das informações de caças não ficam a cargo do SR;
Ator primário: Sistema Supervisório, Motores;
Precondições:
- Posição inicial correta (0,0 ou 20,20);
Fluxo principal:
- Executar código para evitar colisões;
- Obter informações de deslocamento do SS e acionar os motores;
Fluxo de exceção:
- Alterar rota devido à distância do obstáculo;
|
|
20/8/18
| Aula 4
|
| Diagrama de classe SR
|
|
|
|
27/8/18 e 3/9/18
| Aula 5 / Aula 6
|
|
Discussão sobre o diagrama de classes - sistema robô:
- Ajustar diagrama de classes SR:
- Detalhar classe ComunicaSS (basicamente a classe existente refere-se à classe Socket), onde atributos da mesma seriam: "- caças atualizadas", "- manual", "- automático", etc.;
- Estabelecer relação entre as classes;
- Implementar classe mover;
- Elaborar um diagrama de sequência para a classe SR;
- Tabela mapeando todos os dados trocados entre o SS e o SR e vice-versa;
| Tabela SS vs SR
|
| From |
To |
Message
|
| SS |
SR |
Get ID
|
| SS |
SR |
Success
|
| SS |
SR |
Fail
|
| SS |
SR |
Sending coord.
|
| SS |
SR |
Sending info.
|
| SS |
SR |
Pause
|
| SS |
SR |
End of match
|
| SS |
SR |
Move
|
| SS |
SR |
Emergency stop
|
| SS |
SR |
Sending lists
|
| SS |
SR |
Start match
|
| SS |
SR |
Start position
|
| SS |
SR |
Resume match
|
| SR |
SS |
ACK
|
| SR |
SS |
Sending MAC address
|
| SR |
SS |
Emergency stop
|
| SR |
SS |
Refresh lists
|
| SR |
SS |
Moving to the coord.
|
| SR |
SS |
Coord. reached
|
| SR |
SS |
Hunt found
|
|
| Sequencia SS vs SR
|
 Diagrama de Sequência - SR vs SR |
| Ajustes diagrama classe - SR
|
|
|
| Ajustes diagrama de sequência
|
|
|
|
17/9/18
24/9/18
| Aula 8
|
| Diagrama UC
|
|
Nome: Cadastrar robô
Identificador: CSU01;
Sumário: Trata-se da inserção de novo robô no sistema, ou seja, o SA envia a solicitação ao SS, que trata do cadastro de um novo robô através de seus identificadores: cor e MAC address;
Ator primário: Sistema Auditório;
Precondições:
- Robô já ter acesso à rede;
Fluxo principal:
- SA informa o cadastro do robô com determinados identificadores;
- SS confirma os identificadores com o SR;
Fluxos de exceção:
- Em caso de divergência nas informações passadas pelo SA e as respondidas pelo SR, o robô não é autorizado a participar do jogo, ou seja, o cadastro não acontece;
Nome: Solicitar status
Identificador: CSU02;
Sumário: Verificar se os robôs cadastrados ainda estão disponíveis;
Ator primário: Sistema Auditório;
Precondições:
- Robô já ter sido cadastrado;
Fluxo principal:
- De tempo em tempo o SA envia uma solicitação ao SS de cada robô para verificar o status do mesmo (poll), caso não haja uma partida em andamento;
- SS responde à solicitação (por exemplo: ICMP);
Fluxos de exceção:
- Caso não haja resposta, o SA conclui que o robô se desconectou;
Nome: Configurar jogo
Identificador: CSU03;
Sumário: SA informa ao SS de cada robô o modo de jogo e as informações pertinentes a cada modo;
Atores primários: Sistema Auditório;
Precondições:
- Robô já ter sido cadastrado e autenticado;
Fluxo principal:
- Definir modo de jogo dos robôs;
- Passar informações como coordenadas de caças, posição inicial, etc;
Nome: Interface
Identificador: CSU04;
Sumário: Interface para o usuário final;
Ator primário: Usuário;
Fluxo principal:
- Realizar movimentação do robô caso a configuração de jogo definida pelo SA seja manual;
- Acompanhar o estado da partida se em modo autônomo;
|
| Tabela SA vs SS
|
| From |
To |
Message
|
| SS |
SA |
ACK
|
| SS |
SA |
validaCacas
|
| SS |
SA |
enviaID
|
| SS |
SA |
coordFutura
|
| SS |
SA |
coordAtual
|
| SA |
SS |
poll
|
| SA |
SS |
cadastraRobo
|
| SA |
SS |
inicia
|
| SA |
SS |
pausa
|
| SA |
SS |
fimJogo
|
| SA |
SS |
atualizaCacas
|
| SA |
SS |
atualizaAdversarios
|
| SA |
SS |
atualizaPlacar
|
| SS |
SR |
Get ID
|
| SS |
SR |
Success
|
| SS |
SR |
Fail
|
| SS |
SR |
Enviar coord.
|
| SS |
SR |
Pausa
|
| SS |
SR |
Fim
|
| SS |
SR |
Mover
|
| SS |
SR |
Enviar listas
|
| SS |
SR |
Inicio
|
| SR |
SS |
ACK
|
| SR |
SS |
MAC Address
|
| SR |
SS |
Parar
|
| SR |
SS |
Atualizar listas
|
| SR |
SS |
Movendo (coordenada)
|
| SR |
SS |
Coord. alcançada
|
| SR |
SS |
Caça encontrada
|
|
|
1/10/18 e 8/10/18
| Aula 9 / Aula 10
|
| Ajustes Diagrama Classe SS
|
|
|
| Ajustes Diagrama Classe SR
|
|
|
| Ajustes Diagrama UC SS
|
|
Nome: Cadastrar robô
Identificador: CSU01;
Sumário: Trata-se da inserção de novo robô no sistema, ou seja, o SA envia a solicitação ao SS, que trata do cadastro de um novo robô através de seus identificadores: cor e MAC address;
Ator primário: Sistema Auditório;
Precondições:
- Robô já ter acesso à rede;
Fluxo principal:
- SA informa o cadastro do robô com determinados identificadores;
- SS confirma os identificadores com o SR;
Fluxos de exceção:
- Em caso de divergência nas informações passadas pelo SA e as respondidas pelo SR, o robô não é autorizado a participar do jogo, ou seja, o cadastro não acontece;
Nome: Solicitar status
Identificador: CSU02;
Sumário: Verificar se os robôs cadastrados ainda estão disponíveis;
Ator primário: Sistema Auditório;
Precondições:
- Robô já ter sido cadastrado;
Fluxo principal:
- De tempo em tempo o SA envia uma solicitação ao SS de cada robô para verificar o status do mesmo (poll), caso não haja uma partida em andamento;
- SS responde à solicitação (por exemplo: ICMP);
Fluxos de exceção:
- Caso não haja resposta, o SA conclui que o robô se desconectou;
Nome: Configurar jogo
Identificador: CSU03;
Sumário: SA informa ao SS de cada robô o modo de jogo e as informações pertinentes a cada modo;
Atores primários: Sistema Auditório;
Precondições:
- Robô já ter sido cadastrado e autenticado;
Fluxo principal:
- Definir modo de jogo dos robôs;
- Passar informações como coordenadas de caças, posição inicial, etc;
Nome: Interface
Identificador: CSU04;
Sumário: Interface para o usuário final;
Ator primário: Usuário;
Fluxo principal:
- Realizar movimentação do robô caso a configuração de jogo definida pelo SA seja manual;
- Acompanhar o estado da partida se em modo autônomo;
|
| Ajustes tabela SA vs SS
|
| From |
To |
Message
|
| SS |
SA |
ACK
|
| SS |
SA |
validaCacas
|
| SS |
SA |
enviaID
|
| SS |
SA |
coordFutura
|
| SS |
SA |
coordAtual
|
| SA |
SS |
poll
|
| SA |
SS |
cadastraRobo
|
| SA |
SS |
inicia
|
| SA |
SS |
pausa
|
| SA |
SS |
fimJogo
|
| SA |
SS |
atualizaCacas
|
| SA |
SS |
atualizaAdversarios
|
| SA |
SS |
atualizaPlacar
|
| SS |
SR |
Solicita ID
|
| SS |
SR |
Sucesso
|
| SS |
SR |
Falha
|
| SS |
SR |
Enviar coord.
|
| SS |
SR |
Pausa
|
| SS |
SR |
Fim
|
| SS |
SR |
Mover
|
| SS |
SR |
Enviar listas
|
| SS |
SR |
Inicio
|
| SR |
SS |
ACK
|
| SR |
SS |
MAC Address
|
| SR |
SS |
Parar
|
| SR |
SS |
Atualizar listas
|
| SR |
SS |
Movendo (coordenada)
|
| SR |
SS |
Coord. alcançada
|
| SR |
SS |
Caça encontrada
|
|
|
29/10/18
| Aula 11, 12 e 13
|
| Ajustes Diagrama Classe SS
|
|
|
| Ajustes tabela SA vs SS
|
| From |
To |
Message
|
| SS |
SA |
ACK
|
| SS |
SA |
validaCacas
|
| SS |
SA |
enviaID
|
| SS |
SA |
coordFutura
|
| SS |
SA |
coordAtual
|
| SA |
SS |
poll
|
| SA |
SS |
cadastraRobo
|
| SA |
SS |
inicia
|
| SA |
SS |
pausa
|
| SA |
SS |
fimJogo
|
| SA |
SS |
atualizaCacas
|
| SA |
SS |
atualizaAdversarios
|
| SA |
SS |
atualizaPlacar
|
| SA |
SS |
solicitaID
|
| SA |
SS |
solicitaHistorico
|
| SA |
SS |
valicaCaca
|
| SA |
SS |
atualizaMapa
|
| SS |
SR |
solicitaID
|
| SS |
SR |
sucesso
|
| SS |
SR |
falha
|
| SS |
SR |
Enviar coord.
|
| SS |
SR |
pausa
|
| SS |
SR |
fim
|
| SS |
SR |
mover
|
| SS |
SR |
enviarListas
|
| SS |
SR |
inicio
|
| SR |
SS |
ACK
|
| SR |
SS |
macAddress
|
| SR |
SS |
enviaID
|
| SR |
SS |
validaCaca
|
| SR |
SS |
paradaEmergencia
|
| SR |
SS |
movendoPara
|
| SR |
SS |
enviaHistorico
|
| SR |
SS |
coordAlcancada
|
| SR |
SS |
cacaEncontrada
|
|
|
5/11/18
| Aula 14 - Projeto do SA
|
| Diagrama UC
|
|
Nome: Cadastra robô
Identificador: CSU01;
Sumário: Cadastro de novo robô através de informações como ID (MAC addres) e cor;
Ator primário: Árbitro;
Precondições:
- Cor do robô ou grupo;
- Conhecimento do MAC;
Fluxo principal:
- Jogador informa os dados para cadastro;
- SA verifica em sua base e, se estiver tudo correto, o robô é cadastrado;
Fluxos de exceção:
- Robô já cadastrado;
Nome: Autentica Robô
Identificador: CSU02;
Sumário: Após o cadastro completo, o SS de cada robô/grupo deve se autenticar no SA de modo a estar apto para participar das partidas;
Ator primário: Sistema Supervisório;
Precondições:
- Robô já ter sido cadastrado;
Fluxo principal:
- SS envia os dados para autenticação (ID e cor);
- SA processa os dados, faz uma consulta interna e permite a participação do robô;
Fluxos de exceção:
- Robô não cadastrado ou dados incorretos;
Nome: Novo jogo
Identificador: CSU03;
Sumário: Nesta parte é configurado e iniciado o jogo pelo árbitro, onde o mesmo define o modo de jogo, além de internamente o SA sortear as caças e passar todas essas informações aos Sistemas Supervisórios;
Atores primários: Árbitro;
Precondições:
- Robôs cadastrados;
- Participantes autenticados;
Fluxo principal:
- Sortear caças;
- Definir modo de jogo;
- Definir a posição inicial dos robôs;
- Enviar todas as informações aos SSs;
Nome: Movendo para
Identificador: CSU04;
Sumário: A cada movimento realizado pelo robô, o SS do mesmo informa ao SA sua trajetória;
Ator primário: Sistema Supervisório;
Fluxo principal:
- Informar o SA através de coordenadas qual o seu destino (parcial);
Fluxo de exceção:
- Alterar rota devido a possível conflito;
Nome: Pausa
Identificador: CSU05;
Sumário: Solicitação de pausa enviada a cada robô/equipe;
Ator primário: Árbitro;
Fluxo principal:
- Informar cada equipe sobre a parada;
- Robôs concluem movimentos em andamento e entram no estado de pausa;
Nome: Continua
Identificador: CSU06;
Sumário: Enviar alerta de retomada do jogo às equipes;
Ator primário: Árbitro;
Fluxo principal:
- Informar os grupos sobre a retomada do jogo;
Nome: Status
Identificador: CSU07;
Sumário: Acompanhamento do estado da partida;
Ator primário: Árbitro;
Fluxo principal:
- Consultar SS a respeito da posição atual, futura, etc.;
- Exibir placar e coordenadas dos robôs;
Nome: Consulta histórico
Identificador: CSU08;
Sumário: Armazena em banco o histórico dos robôs: caças e movimentos efetuados;
Ator primário: Árbitro;
Fluxo principal:
- Persistir dados enviados pelo SS informando movimento;
- Persistir dados enviados pelo SS informando caça encontrada;
|
| Tabela de mensagens
|
|
As mensagens trocadas entre SA e SS e vice-versa utilizam o formato JSON. A tabela a seguir define o código e os parâmetros das mensagens trocadas.
O código das mensagens deve ser passado através do parâmetro "cmd" no JSON, conforme exemplo a seguir:
Ex.: supondo que o SA está mandando a mensagem CadastraRobo para o SS, a mensagem deve ir no seguinte formato:
{ "cmd": 1000, "cor": 1, "nome": "Grupo3" }
Observações :
- O tipo 'dic' indica um dicionário.
- O tipo 'list' indica uma lsta.
| From |
To |
Message |
Código |
Parâmetros |
Observações
|
| SA |
SS |
CadastraRobo |
1000 |
"cor": int, "nome": string |
|
| SA |
SS |
SolicitaID |
1001 |
|
|
| SA |
SS |
SolicitaHistorico |
1002 |
|
|
| SA |
SS |
SolicitaStatus |
1003 |
|
|
| SA |
SS |
NovoJogo |
1100 |
"modo_jogo": int, "x": int, "y": int, "cacas": list |
"x" e "y" indicam a posicao inicial
"cacas" deve conter uma lista de dicionarios, que indicam as posicoes das cacas. Ex.: [{'x': 5, 'y': 3}, {'x': 1, 'y': 2}]
"cacas" só é obrigatorio para modo de jogo automatico
No parâmetro "modo_jogo, utiliza-se 1 para manual e 2 para automatico
|
| SA |
SS |
Pausa |
1101 |
|
|
| SA |
SS |
Continua |
1102 |
|
|
| SA |
SS |
FimJogo |
1103 |
|
|
| SA |
SS |
AtualizaMapa |
1200 |
"cacas": list, "posicao_adversario": dic |
"posicao_adversario" deve conter um dicionario com os valores "x" e "y" do adversario
|
| SA |
SS |
ValidacaoCaca |
2000 |
"ack": int, "x": int, "y": int |
"ack" deve conter 1 para caca validada e 0 para caca invalidada
"x" e "y" só devem ser passados caso a caca seja invalidada
|
|
|
|
|
|
|
| SS |
SA |
MovendoPara |
1000 |
"x": int, "y": int |
|
| SS |
SA |
PosicaoAtual |
1001 |
"x": int, "y": int |
|
| SS |
SA |
ValidaCaca |
1002 |
"x": int, "y": int |
|
| SS |
SA |
ObstaculoEncontrado |
1003 |
|
|
| SS |
SA |
SolicitaID_RESP |
2000 |
"cor": int, "nome": string, "mac": string |
|
| SS |
SA |
SolicitaHistorico_RESP |
2002 |
"historico": list |
|
| SS |
SA |
SolicitaStatus_RESP |
2003 |
|
|
|
|
|
|
|
|
|
|
Bibliografia
- BEZERRA, Eduardo. Princípios de análise e projetos de sistemas com UML, 2002. Rio de Janeiro. Editora Campus LTDA.
