Grupo3-PJI2-2018-2

De MediaWiki do Campus São José
Revisão de 22h04min de 18 de novembro de 2018 por 127.0.0.1 (discussão) (→5/11/18)
(dif) ← Edição anterior | Revisão atual (dif) | Versão posterior → (dif)
Ir para navegação Ir para pesquisar

1 Projeto Integrador II

Alunos: João Leonardo Martins (joao.lm@aluno.ifsc.edu.br) e Vinícius Luz (vinicius.ls@aluno.ifsc.edu.br)

1.1 Objetivo Geral

Implantar tradicional caça de robôs para buscar determinados itens através de coordenadas.

1.2 Página da Disciplina

PJI2018-2

1.3 Repositório GIT:

https://github.com/viniciusluzsouza/pji2

1.4 Diagramas

Geral do projeto
Diagrama Geral do Projeto
Diagrama Geral do Projeto
Caso de uso e descrição
SR
Diagrama UC - SR
Diagrama UC - 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:

  1. Robô já ter sido cadastrado;

Fluxo principal:

  1. SS solicita o ID do robô;
  2. Robô responde com o MAC Address de sua interface de rede Bluetooth;

Fluxos de exceção:

  1. 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:

  1. Robô já ter sido cadastrado;
  2. O robô já ter se autenticado;

Fluxo principal:

  1. SS envia os dados para início do jogo;
  2. 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:

  1. Ter recebido os dados com sucesso;
  2. Posição inicial correta (0,0 ou 20,20);

Fluxo principal:

  1. Acionar sensores;
  2. Acionar motores;
  3. Ao se deparar com uma caça, enviar informação ao SS;

Fluxo de exceção:

  1. Obstáculo próximo (mudar trajetória);
  2. Se pausa/fim de jogo, voltar ao ponto inicial;
  3. 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:

  1. Posição inicial correta (0,0 ou 20,20);

Fluxo principal:

  1. Executar código para evitar colisões;
  2. Obter informações de deslocamento do SS e acionar os motores;

Fluxo de exceção:

  1. Alterar rota devido à distância do obstáculo;
SS
Diagrama UC - SS
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:

  1. Robô já ter acesso à rede;

Fluxo principal:

  1. SA informa o cadastro do robô com determinados identificadores;
  2. SS confirma os identificadores com o SR;

Fluxos de exceção:

  1. 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:

  1. Robô já ter sido cadastrado;

Fluxo principal:

  1. 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;
  2. SS responde à solicitação (por exemplo: ICMP);

Fluxos de exceção:

  1. 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:

  1. Robô já ter sido cadastrado e autenticado;

Fluxo principal:

  1. Definir modo de jogo dos robôs;
  2. 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:

  1. Realizar movimentação do robô caso a configuração de jogo definida pelo SA seja manual;
  2. Acompanhar o estado da partida se em modo autônomo;
Classes
Sensores
Diagrama de Classe - Motor
Diagrama de Classe - Sensor
SR
Diagrama de Classe - SR
SS
Diagrama Classes - SS
Sequência
SR
Diagrama de Sequência - SS vs SR
SS
Diagrama de Sequência - SS

1.5 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.

1.6 Diário das Aulas

1.6.1 30/7/18
Aula 1

- Definição do grupo;

- Aula expositiva;

- Organização das tarefas através da ferramenta Trello;

1.6.2 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
1.6.3 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
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

  1. !/usr/bin/env python3

from ev3dev.ev3 import * import time

m_l = Motor(OUTPUT_B)#left motor m_r = Motor(OUTPUT_C) #right motor

  1. 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)

  1. 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')

  1. 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')
  1. 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

  1. !/usr/bin/env python3

from ev3dev.ev3 import * from time import sleep

  1. Connect EV3 color sensor and check connected.

cl = ColorSensor() assert cl.connected, "Connect a color sensor to any sensor port"

  1. Put the color sensor into COL-REFLECT mode
  2. to measure reflected light intensity.
  3. 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

  1. !/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>


1.6.1 Ajustes no Diagrama UC do SR

Diagrama UC do SR
Diagrama Geral do Projeto2
Diagrama Geral do Projeto2
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:

  1. Robô já ter sido cadastrado;

Fluxo principal:

  1. SS solicita o ID do robô;
  2. Robô responde com o MAC Address de sua interface de rede Bluetooth;

Fluxos de exceção:

  1. 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:

  1. Robô já ter sido cadastrado;
  2. O robô já ter se autenticado;

Fluxo principal:

  1. SS envia os dados para início do jogo;
  2. 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:

  1. Ter recebido os dados com sucesso;
  2. Posição inicial correta (0,0 ou 20,20);

Fluxo principal:

  1. Acionar sensores;
  2. Acionar motores;
  3. Ao se deparar com uma caça, enviar informação ao SS;

Fluxo de exceção:

  1. Obstáculo próximo (mudar trajetória);
  2. Se pausa/fim de jogo, voltar ao ponto inicial;
  3. 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:

  1. Posição inicial correta (0,0 ou 20,20);

Fluxo principal:

  1. Executar código para evitar colisões;
  2. Obter informações de deslocamento do SS e acionar os motores;

Fluxo de exceção:

  1. Alterar rota devido à distância do obstáculo;
1.6.1.1 20/8/18
Aula 4
Diagrama de classe SR

1.6.1.2 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 UC - SR
Versão antiga
Nova versão
Ajustes diagrama classe - SR
Versão antiga
Nova versão
Ajustes diagrama de sequência
Versão antiga
Nova versão
1.6.1.3 17/9/18
Aula 7
Gráfico de Gantt
1.6.1.4 24/9/18
Aula 8
Diagrama UC
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:

  1. Robô já ter acesso à rede;

Fluxo principal:

  1. SA informa o cadastro do robô com determinados identificadores;
  2. SS confirma os identificadores com o SR;

Fluxos de exceção:

  1. 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:

  1. Robô já ter sido cadastrado;

Fluxo principal:

  1. 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;
  2. SS responde à solicitação (por exemplo: ICMP);

Fluxos de exceção:

  1. 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:

  1. Robô já ter sido cadastrado e autenticado;

Fluxo principal:

  1. Definir modo de jogo dos robôs;
  2. 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:

  1. Realizar movimentação do robô caso a configuração de jogo definida pelo SA seja manual;
  2. Acompanhar o estado da partida se em modo autônomo;


Diagrama Classes
Diagrama Classes - SS
Diagrama Sequencias
Diagrama Sequencias - SS
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.6.1.5 1/10/18 e 8/10/18
Aula 9 / Aula 10
Novo cronograma
Novo cronograma
Ajustes Diagrama Classe SS
Versao antiga
Versao nova
Ajustes Diagrama Classe SR
Versao antiga
Versao nova
Ajustes Diagrama UC SS
Versao antiga
Versao nova

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:

  1. Robô já ter acesso à rede;

Fluxo principal:

  1. SA informa o cadastro do robô com determinados identificadores;
  2. SS confirma os identificadores com o SR;

Fluxos de exceção:

  1. 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:

  1. Robô já ter sido cadastrado;

Fluxo principal:

  1. 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;
  2. SS responde à solicitação (por exemplo: ICMP);

Fluxos de exceção:

  1. 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:

  1. Robô já ter sido cadastrado e autenticado;

Fluxo principal:

  1. Definir modo de jogo dos robôs;
  2. 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:

  1. Realizar movimentação do robô caso a configuração de jogo definida pelo SA seja manual;
  2. 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
Ajustes Sequência SS
Versao antiga
Versao nova
1.6.1.6 29/10/18
Aula 11, 12 e 13
Ajustes Diagrama Classe SS
Versao antiga
Versao nova
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
1.6.1.7 5/11/18
Aula 14 - Projeto do SA
Diagrama UC
Diagrama UC SA

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:

  1. Cor do robô ou grupo;
  2. Conhecimento do MAC;

Fluxo principal:

  1. Jogador informa os dados para cadastro;
  2. SA verifica em sua base e, se estiver tudo correto, o robô é cadastrado;

Fluxos de exceção:

  1. 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:

  1. Robô já ter sido cadastrado;

Fluxo principal:

  1. SS envia os dados para autenticação (ID e cor);
  2. SA processa os dados, faz uma consulta interna e permite a participação do robô;

Fluxos de exceção:

  1. 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:

  1. Robôs cadastrados;
  2. Participantes autenticados;

Fluxo principal:

  1. Sortear caças;
  2. Definir modo de jogo;
  3. Definir a posição inicial dos robôs;
  4. 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:

  1. Informar o SA através de coordenadas qual o seu destino (parcial);

Fluxo de exceção:

  1. 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:

  1. Informar cada equipe sobre a parada;
  2. 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:

  1. 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:

  1. Consultar SS a respeito da posição atual, futura, etc.;
  2. 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:

  1. Persistir dados enviados pelo SS informando movimento;
  2. 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






Diagrama de classe
Diagrama Classe SA
Diagrama de sequência
Diagrama sequência SA

1.7 Bibliografia

  • BEZERRA, Eduardo. Princípios de análise e projetos de sistemas com UML, 2002. Rio de Janeiro. Editora Campus LTDA.
Disponível em “https://wiki.sj.ifsc.edu.br/index.php?title=Grupo3-PJI2-2018-2&oldid=152832”