Trabalho Hissamu

Autor Versão Data
Camile Pereira, José Guilherme.S.P.Fernandes, Julio Cesar

Roque, Kananda Rodrigues, Mateus dos Santos Castro V1.0 26.09.2022

Roque, Kananda Rodrigues, Mateus dos Santos Castro V1.0.1 01.10.2022
José Guilherme.S.P.Fernandes, Mateus dos Santos Castro

V2.0 11.10.2022

Roque, Mateus dos Santos Castro V3.0 15.10.2022
Camile Pereira
v3.0.1 17.10.2022
Camile Pereira, Julio Cesar Roque

V3.0.2 24.10.2022
Camile Pereira
V3.0.3 25.10.2022
Julio Cesar Roque, Kananda Rodrigues

V3.0.4 25.10.2022
Camile Pereira, Julio Cesar Roque

V3.0.4 28.10.2022
Julio Cesar Roque, Mateus dos Santos Castro

V4.0 08.11.2022
Mateus dos Santos Castro

V5.0 22.11.2022
1
Roque, Kananda Rodrigues, Mateus dos Santos Castro V5.0.1 29.11.2022
Sumário
Controle de
Versões................................................................................................................................ 1
Sumário................................................................................................................................ 2
Introdução.............................................................................................................................4
Cenário
Atual...................................................................................................................................... 4
Restrições............................................................................................................................. 4
Premissas.............................................................................................................................. 4
Descrição dos
Requisitos.............................................................................................................................. 5
Requisitos
Funcionais............................................................................................................................... 5
Requisitos Não
Funcionais............................................................................................................................... 7
Protótipo.................................................................................................................................. 8
2
Casos de
uso........................................................................................................................................ 16
Atores.................................................................................................................................... 16
Identificação dos casos de

uso........................................................................................................................................ 16
Diagrama de casos de
uso........................................................................................................................................ 20
Detalhamento dos casos de

uso.............................................................................................................. ………………… 20
Diagrama de
classe.................................................................................................................................... 40
Modelagem de
dados.................................................................................................................................... 41
Modelo entidade
relacionamento......................................................................................................................
41
Modelo
relacional............................................................................................................................... 42
Tabela SQL ...........................................................................................................................42
Login..................................................................................................................................... 42
Horários............................................................................................................................... 43
Atividades............................................................................................................................. 43
Questionário.......................................................................................................................... 44
Notas......................................................................................................................................44
Feedback.............................................................................................................................. 45
3
Introdução
Esse projeto tem o objetivo de essencialmente resolver a diferença de desempenho
humano em relação às notas em toda instituição que for implantado, uma solução de baixo
custo e processamento com alta performance que vai mostrar algumas telas para
professores e alunos garantindo o envio rápido da informação e o cálculo automático das
notas, reforçando a segurança com uma tela de login para confirmar a identidade. Tanto os
professores quantos os alunos vão ter uma agilidade maior ao confirmar informações e
menor taxa de erro ao diminuir o trabalho humano, podendo ser mais automatizado no
futuro e garantindo a possibilidade de implantação de autosserviços, comprometendo-se em
aumentar a retenção e diminuir os custos gerais em atendimento e mão de obra humana.
Cenário Atual
Atualmente fica a cargo dos professores organizar, guardar, calcular e disponibilizar
as notas, utilizando de plataformas de terceiros como Excel, ou às vezes papel, para todas
as turmas em que dão aula, o que vem causando demora no processo e alguns erros
humanos, além de que para o aluno conseguir obter essa informação e tirar alguma dúvida
referente a isso, existe uma demora muito grande e uma quantidade pequena de
funcionários para o mesmo, sendo que geralmente existem dúvidas fixas que, por exemplo,
a maioria dos calouros tem, o que acaba travando o processo e inundando a fila.
Restrições
● O prazo de desenvolvimento do software não poderá passar de 6 meses.
● O projeto não deve ultrapassar o orçamento de R$3000,00 .
● O projeto terá que ser entregue em fases, podendo haver mudanças no escopo.
Premissas
● O projeto deverá realizar as funções básicas que facilitam o trabalho do professor.
● O projeto deverá auxiliar o aluno na visualização das suas notas.
● O projeto deverá evitar sobrecarga dos alunos com o professor.
● O projeto deverá garantir a persistência dos dados.
4
Descrição dos Requisitos
Requisitos Funcionais
RQF 01 O sistema deve ter um login para confirmar a identidade do usuário.
RQF 02 O aluno tem acesso a uma tela de horário das suas disciplinas e pode
consultá-las sempre que necessário.
RQF 03 O professor tem controle administrativo sobre uma ou mais turmas no

sistema.
RQF 04 O professor pode enviar uma ou mais atividades e atribuir nota/peso a

estas, para compor o plano de atividade.
RQF 05 O professor pode mandar notificações para aluno(s) em específico ou

para turma(s) que ele seja responsável.
RQF 06 O professor pode inserir um material em um plano de atividades de

uma ou mais turma(s).
RQF 07 O professor pode compartilhar um questionário com alunos de uma ou

mais turmas cadastradas.
RQF 08 O aluno pode ver sua presença semestral.
RQF 09 O Aluno pode ver suas notas assim que lançado no sistema.
RQF 10 O Professor pode lançar as notas para cálculo automático.
RQF 11 O professor pode requisitar ao sistema que gere relatórios de uma ou

mais turmas que ele seja responsável.
RQF 12 O Aluno pode mandar um feedback de até duas mil palavras para o
5
suporte.
RQF 13 Tanto o aluno quanto o professor devem ter acesso a um chat de

suporte.
RQF 14 O professor e o aluno devem ter um chat privado para conversar.
RQF 15 O aluno pode visualizar suas informações no perfil e editá-las.
RQF 16 O administrador pode gerenciar as turmas e os responsáveis por elas.
RQF 17 O administrador pode cadastrar os professores e alunos.
RQF 18 O administrador pode associar professores e alunos a uma ou mais turmas.
RQF 19 O administrador pode verificar o histórico de ações e atividades dos usuários.
RQF 20 O administrador pode tirar o acesso do professor ou reverter suas ações.
RQF 21 O administrador pode se comunicar com os professores via chat.
Requisitos Não Funcionais
RNF 01 Os relatórios devem ser todos gerados em formato (*.xls).
RNF 02 O sistema deve funcionar On-line apenas.
6
RNF 03 O sistema deve persistir os dados em um banco de dados MySQL.
7
RNF 04 O sistema deve ser ajustável a diferentes plataformas.
RNF 05 O sistema deve ser desenvolvido usando a linguagem java.
RNF 06 O sistema deve guardar a senha do usuário e criptografá-la
RNF 07 O sistema deve permitir que apenas o usuário autorizado acesse os

dados inseridos por ele.
RNF 08 O sistema deve permitir que o usuário interaja com a interface de

modo fácil e intuitivo.
RNF 09 O sistema deve fazer backup semanalmente, todo sábado à partir das
00:00.
RNF 10 As APIs do sistema devem ser REST e a resposta tem que ser em
JSON.
RNF 11 O sistema deve ter um tempo de resposta menor que 3 segundos.
RNF 12 O sistema deve ser implementado em um servidor da AWS.
8
Protótipo
9
10
Fluxo do Aluno:
11
Fluxo do Professor:
12
13
Comum entre os dois:
14
Casos de uso
Atores
Professor
Usuário na qual terá acesso administrativo a uma ou mais turmas.
Aluno
Usuário que faz parte de uma ou mais turmas, tendo acesso
comum ao sistema.
Administrador
Usuário com acesso total ao sistema.
Usuário
Usuário com acesso comum ao sistema.
Identificação dos casos de uso

UC
NOME UC DESCRIÇÃO UC
UC 01
Efetuar login Autenticação de usuários (Professor e aluno)
Cadastrados no sistema, permitindo a realização
de operações na área restrita do portal.
UC 02
Cadastrar O administrador pode cadastrar professores com
usuário acesso administrativo para as turmas.
UC 03
Calcular O professor irá somar as notas dos alunos para
notas o sistema.
15
UC 04
Gerenciar O professor terá permissões necessárias para o
turmas gerenciamento das turmas.
UC 05
Associar O administrador é responsável por designar
aluno(s) e professores e alunos em suas respectivas
professor(es) turmas
as turma(s)
UC 06
Remover O administrador pode remover permissões dos
permissões usuários do sistema.
UC 07
Verificar O administrador pode acessar o histórico de
histórico de ação e atividade dos alunos e professores.
ação e
atividade
UC 08
Reverter
ações
UC 09
Gerar O sistema irá gerar um relatório ao final de cada
relatório semestre.
UC 10
Enviar O professor poderá inserir as atividades no
atividades plano de atividades de cada turma,
UC 11
Atribuir O professor irá atribuir pesos às atividades e
nota/peso atribuir notas individuais ou em grupo aos
alunos.
UC 12
Editar plano Além de publicar as atividades, o professor
de atividades poderá modificar as mesmas.
16
UC 13
Enviar O professor poderá notificar os alunos da turma
notificações acerca de uma atividade lançada na plataforma
ou sobre alterações.
UC 14
Fazer O professor poderá criar questionários.
questionários
UC 15
Chat Chat professor- aluno
UC 16
Ver notas O aluno poderá acessar as notas de cada UC
pela plataforma.
UC 17
Ver presença O aluno poderá verificar sobre presença/faltas.
UC 18
Editar perfil O aluno poderá editar as informações de seu
perfil.
UC 19
Verificar O aluno poderá verificar os horários das aulas
horários no plano curricular.
UC 20
Enviar
Feedback
UC 21
Chat com o O aluno terá acesso ao chat com o suporte,
suporte onde poderá tirar dúvidas sobre o site
17
Diagrama de casos de uso
Detalhamento dos casos de uso
18
Caso de Uso: UC-01
Descrição:
Efetuar Login
Este caso de uso especifica a ação de autenticação que
um usuário executa no sistema, com objetivo de se
conectar na aplicação. Apenas usuários cadastrados
podem se autenticar no sistema. O usuário fornece seus
dados básicos de autenticação e, após a validação no
sistema, o usuário torna-se apto a realizar operações da
área restrita do sistema. Os usuários se dividem em:
Atores: (a) Aluno, (b) Professor, (c) Administrador.
a) Aluno (usuário que tem acesso limitado ao sistema),
b) Professor (usuário que opera o sistema, habilitado ao

acesso administrativo de uma ou mais turmas),
c) Administrador (usuário habilitado a realizar as ações de

administração com acesso total ao sistema).
Pré-condições:
1. Os atores devem estar cadastrados no sistema.
Pós-condições:
1. Os atores ficam habilitados a realizar ações na área

restrita do sistema.
Requisitos funcionais:
1. RF 28. O portal deve prover uma interface para clientes,

operadores e administradores se autenticarem no
sistema***********
Requisitos não funcionais:
1. RNF 06. O sistema deve guardar a senha do usuário e

criptografá-la
Fluxo Principal:
1. O ator decide se autenticar no sistema.
2. O sistema solicita as informações obrigatórias para a
autenticação: E-mail e Senha
3. O ator informa os dados de autenticação.
4. O sistema valida os dados de autenticação.
5. O sistema registra em histórico (log) a autenticação

realizada pelo ator. Os seguintes dados são armazenados:
19
1. Usuário 2. Grupo de Usuário 3. Data.
6. O sistema habilita as ações relacionadas ao usuário ao

qual pertence o ator.
7. O sistema informa que a autenticação foi realizada com

sucesso.
O caso de uso se encerra.
Fluxo Alternativo A:
1. 1. No passo 4 do Fluxo Básico, caso haja algum

erro na autenticação relacionado aos dados
informados:
2. 2. O sistema informa o erro ao ator.
3. 3. O fluxo retorna ao passo 2 do fluxo básico.
Fluxo Alternativo B:
1. 1. No passo 4 do Fluxo Básico, caso o sistema

identifique que ator está bloqueado:
Fluxo Alternativo C:
1. No passo 1 do Fluxo Alternativo A, caso aconteça o erro

de autenticação após um número configurável de
tentativas:
1. 2. O sistema bloqueia o ator.

2. 3. O sistema registra em histórico (log) o bloqueio
do ator.
Caso de uso: UC-02 Descrição:

Cadastrar usuário
Esse caso de uso possibilita a inserção de um novo usuário no
sistema, o qual pode ser um professor ou aluno.
Atores: Professor(es), aluno(s)
Pré-condição: Não tem.
Pós-condições: Usuário será gerado no banco de dados.
Requisitos Funcionais: RF-01 O sistema deve ter um login
20
para confirmar a identidade do usuário.
Requisitos Não Funcionais: RNF-07 O sistema deve permitir

que apenas o usuário autorizado acesse os dados inseridos por
ele.
Fluxo Principal:
1. 1. O professor/aluno seleciona “Cadastre-se” ;

2. 2. O usuário é encaminhado para página de cadastro;
3. 3.O usuário preenche os campos com os seus dados e
clica em “Cadastrar”;
4. 4.O sistema apresenta uma mensagem de confirmação e
volta a tela do passo 1;
Fluxo Alternativo:
1. O usuário clica em “Cancelar” para cancelar o

procedimento de cadastro.
Calcular notas Esse caso de uso possibilita o professor somar as notas

dos alunos e lançar a mesma no sistema.
Atores: Professor.
Pré-condições: O usuário deve estar cadastrado no sistema.
Pós-condições: O usuário pode somar, calcular e publicar as

notas dos alunos.
Requisitos Funcionais: RF-10 O professor pode lançar as

notas para cálculo automático.
Requisitos Não Funcionais:
Fluxo Principal:
1. 1.O ator irá somar todas as notas das avaliações que

estão no sistema de atividades.
2. 2.O ator irá anexar as notas no plano de sistema de
notas.
Fluxo Alternativo: O usuário pode cancelar ou desfazer

alterações
21
Gerenciar turmas
O professor e o administrador terão permissões
necessárias para o gerenciamento das turmas.
Atores: Professor/ Administrador.
Pré-condições:
1.Os usuários devem estar cadastrados no sistema.
2.Os usuários precisam estar logados no sistema.
Pós-condições:
1.Os atores ficam habilitados a realizar ações necessárias na

área restrita do sistema.
Requisitos Funcionais: RF-03 O professor tem controle

administrativo sobre uma ou mais turmas no sistema.
RF-16- O administrador pode gerenciar as turmas e os

responsáveis por elas.
RF11 - O professor pode requisitar ao sistema que gere

relatórios de uma ou mais turmas que ele seja responsável.
Fluxo Principal:
1. O professor/administrador ira ter controle sobre as notas,

faltas/presenças.
2. O professor/administrador terá acesso para editar as
atividades/avaliações.
Fluxo Alternativo: o professor/administrador pode cancelar ou

desfazer alterações feitas dentro das turmas.
Caso de uso: UC-05 Descrição: Esse caso de uso permite que o administrador possa
Associar alunos e associar alunos e professores em suas respectivas turmas.
professores as
turmas Atores: Administrador.
22
Pré-condições: Estar cadastrado no sistema.
Pós-condições: Gerenciar turmas.
Requisitos Funcionais: RF-17 O administrador pode associar

professores e alunos a uma ou mais turmas.
Fluxo Principal:
1. O administrador irá logar no sistema tendo acesso total

2. O administrador irá cadastrar os alunos em suas
respectivas turmas
3. O administrador irá designar os professores para suas
respectivas turmas
Fluxo Alternativo: O administrador pode cancelar, fazer ou

desfazer alterações.
Caso de uso: UC-06: Descrição: Esse caso de uso permite que o administrador
Remover remova permissões dos usuários do sistema, removendo o
permissões acesso parcial e total dos mesmos.
Atores: Administrador
Pré-condições:
1. Estar logado no sistema como administrador
Pós-condições:
Remover permissões do usuário no sistema
Requisitos Funcionais: RF-19 O administrador pode tirar o

acesso do professor ou reverter suas ações.
Fluxo Principal:
1. O administrador irá selecionar o usuário que deseja

remover a permissão.
2. O administrador irá selecionar as permissões que deseja
23
remover.
Fluxo Alternativo:
1.1 O administrador seleciona o usuário que irá devolver as

permissões.
2.2 O administrador seleciona as permissões que deseja

devolver ao usuário.
Caso de uso: UC-07: Descrição: Esse caso de uso permite que o administrador possa
Verificar histórico de acessar sempre que necessário a ação de atividades dos alunos
ação e atividade e professores.
Atores: Administrador.
Pré-condições:
1. Estar logado no sistema como administrador.
Pós-condições:
1.Efetuar a verificação da ação dos professores sobre as

atividades.
Requisitos Funcionais: RF-19 O administrador pode verificar o

histórico de ações dos usuários.
RNF-07 - O sistema deve permitir que apenas o usuário

autorizado acesse os dados inseridos por ele.
RNF-08- O sistema deve permitir que o usuário interaja com a

interface de modo fácil e intuitivo.
Fluxo Principal:
1. Estar logado no sistema com permissões de

administrador
2. Acessar o usuário selecionado
3. Verificar a ação
Fluxo Alternativo:
O administrador pode cancelar ou desfazer alterações.
24
Caso de uso: UC-08: Descrição:
reverter ações Atores: Professor.
Pré-condições:
Pós-condições:
Requisitos Funcionais:
Fluxo Principal:
Fluxo Alternativo:
Caso de uso: UC-09: Descrição: O sistema irá gerar um relatório ao final de cada
semestre com os dados de tudo que aconteceu nas turmas
Gerar relatório contendo notas, presenças/faltas, atividades, comentários,
anexos.
Atores: Professor.
Pré-condições:
1.Estar logado como professor
Pós-condições:
1.Selecionar a turma.
2.Gerar relatório da turma selecionada.
RF11-O professor pode requisitar ao sistema que gere

relatórios de uma ou mais turmas que ele seja
responsável.
RQN 1 - Os relatórios devem ser todos gerados em

formato (*.xls).
Fluxo Principal:
25
1.Logar e autenticar como professor na plataforma.
2.selecionar a turma.
3. Clicar em gerar relatório.
4.verificar se o relatório está em xls.
Fluxo Alternativo:
1.1 Caso haja erro na autenticação, poderá pedir ajuda

ao administrador.
4.1 Caso o relatório seja gerado em outro formato poderá

voltar a página e tentar novamente gerar outro relatório.
Caso de uso: UC-10: Descrição: Esse caso de uso descreve a ação do professor ao
Enviar Atividades distribuir as atividades para as respectivas turmas no qual ele dá
aula.
Atores: Professor.
Pré-condições:
1. Estar logado no sistema como professor
Pós-condições:
1. Poder enviar atividades para todos os alunos cadastrados

na turma.
RF-04 O professor pode enviar uma ou mais atividades e atribuir

nota/peso a estas, para compor o plano de atividade.
RF-06 O professor pode inserir um material em um plano de

atividades de uma ou mais turma(s).
RF 07 - O professor pode compartilhar um questionário com

alunos de uma ou mais turmas cadastradas.
RNF 11 - O sistema deve ter um tempo de resposta menor que 3

segundos
RNF 08 - O sistema deve permitir que o usuário interaja com a
26
RNF 09 - O sistema deve fazer backup semanalmente, todo

sábado à partir das 00:00.
Fluxo Principal:
1.Logar como professor na plataforma.
2. Ir na aba de turmas.
3. Selecionar a turma desejada.
4. Anexar a atividade no plano de atividades da turma.
Fluxo Alternativo:
1.1 Caso haja erro no login, poderá pedir ajuda ao

administrador.
3.1 Selecionar várias turmas, e voltar.
4.1 Retirar a atividade da plataforma
Caso de uso :UC-11: Descrição: Esse caso de uso permite a ação do professor em
Atribuir nota/ peso somar e atribuir as notas/pesos dos alunos
Atores: Professor.
Pré-condições: Estar logado no sistema como professor
Pós-condições: Somar e atribuir notas aos alunos
Requisitos Funcionais: RF-04 O professor pode enviar uma ou

mais atividades e enviar peso/notas a estas para compor o plano
de atividade
RF-10 O professor pode lançar as notas para cálculo automático
RF-01 O sistema deve ter um login para confirmar a identidade

do usuário.
RNF 07 - O sistema deve permitir que apenas o usuário

27
Fluxo Principal:
1. Logar como professor

2. Selecionar plano curricular
3. Selecionar turma/ alunos
4. Atribuir notas
5. Somar notas
6. lançar ao sistema
Fluxo Alternativo:
1. O professor pode alterar a nota caso haja erro ao somar
Caso de uso :UC-12: Descrição: Esse caso de uso além de publicar as atividades, o
professor poderá modificar as mesmas. Alteração como data de
Editar plano de entrega, alterar as notas das atividades.
atividades
Atores: Professor.
Pré-condições:
1. Estar logado como professor.
Pós-condições:
1. Estar na turma desejada.

2. Estar com o plano de atividade aberto.
3. Estar com a atividade selecionada.
RF 01 – O sistema deve ter um login para confirmar a identidade

do usuário.
RF 03 - O professor tem controle administrativo sobre uma ou

mais turmas no sistema.
RF 04 - O professor pode enviar uma ou mais atividades e

atribuir nota/peso a estas, para compor o plano de atividade.
RF10 - O Professor pode lançar as notas para cálculo

automático.
28
RNF 03 - O sistema deve persistir os dados em um banco de

dados MySQL.


Fluxo Principal:
1.Logar como professor.
2.Estar dentro do plano de atividades.
3. Editar atividade.
Fluxo Alternativo:
1.1 Caso haja erro no login, poderá pedir ajuda ao administrador.
2.1 Sair do plano de atividade.
3.1 cancelar edição de atividade.
Caso de uso UC-13: Descrição: Esse caso de uso especifica a ação do professor a
Enviar notificações notificar os alunos acerca de uma atividade ou alterações
lançadas na plataforma
Atores: Professor.
Pré-condições:
1. Estar logado no sistema como professor
Pós-condições: Enviar notificações aos alunos
Requisitos Funcionais: RF-05 O professor pode mandar

notificações para os alunos em específico ou para turmas que
ele seja responsável

29

dados MySQL
Fluxo Principal:
1. Logar no sistema
2. Selecionar turmas
3. Publicar notificações
Fluxo Alternativo:
2.1 Caso o professor queira, poderá enviar para toda a turma ou

somente para o aluno selecionado.
2.2 Remover seleção de turmas.
3.1 Excluir notificação.
Caso de uso UC-14: Descrição: Esse caso de uso especifica a ação do professor em
Fazer questionários fazer questionários para a turma e lança lós ao sistema
Atores: Professor.
Pré-condições:
1.Estar logado no sistema como professor
Pós-condições:

RF 03 - O professor tem controle administrativo sobre uma ou

mais turmas no sistema.
RF 07 - O professor pode compartilhar um questionário

com alunos de uma ou mais turmas cadastradas.
30


dados MySQL
Fluxo Principal:
1. Logar como professor.

2. selecionar a turma que desejava.
3. Criar o questionário
Fluxo Alternativo:
2.1 remover a seleção da turma.
3.1 excluir questionário.
Caso de uso UC-15: Descrição: Esse caso de uso especifica a ação dos atores
Chat entrarem em contato através de um chat na plataforma para tirar
dúvidas, fazer questionamentos ou reclamações.
Atores: Professor, aluno
Pré-condições:
1.Estar logado no sistema
Pós-condições:

2.Os usuários podem se comunicar através de um chat
RF 13 - Tanto o aluno quanto o professor devem ter acesso a um

chat de suporte.
RF- 14 O professor e o aluno devem ter um chat privado para

conversar.
RF 21 - O administrador pode se comunicar com os professores
31
via chat.



dados MySQL
Fluxo Principal:
1. Logar no sistema
2. selecionar UC
3. Abrir chat
4. Conversar com professor
Fluxo Alternativo:
2.1 remover a seleção de UC.
3.1 fechar chat.
Caso de uso UC-16: Descrição: Esse caso de uso especifica a ação do aluno em
Ver notas verificar suas notas no sistema postadas pelo professor.
Atores: Aluno
Pré-condições:
1.Estar logado no sistema como aluno
Pós-condições:
1. Os atores ficam habilitados a realizar ações na área restrita do

sistema.
1.1 os atores poderão verificar as notas.
32
RF-09 O aluno pode ver suas notas assim que lançadas no
sistema



dados MySQL
Fluxo Principal:
1. Logar no sistema
2. Selecionar UC
3. Verificar notas da matéria
Fluxo Alternativo:
2.1 Sair da UC selecionada.
3. mandar mensagens no chat do professor caso haja algum

erro.
Caso de uso UC-17: Descrição: Esse caso de uso especifica a ação do aluno a ver
Ver presença sua presença no final ou no decorrer do semestre.
Atores: Aluno
Pré-condições:
1.Logar no sistema como aluno
Pós-condições:
1. Os atores ficam habilitados a realizar ações na área restrita do

sistema.
2. Verificar presença em determinada UC
Requisitos Funcionais: RF-08 O aluno pode ver sua presença
33
semestral



dados MySQL
Fluxo Principal:
1. Logar no sistema
2. selecionar UC
3. verificar presença
Fluxo Alternativo:
3. mandar mensagens no chat do professor caso haja algum

erro.
Caso de uso UC-18: Descrição: Esse caso de uso especifica a ação do aluno a
Editar perfil editar informações pessoais sobre seu perfil
Atores: Aluno
Pré-condições:
1.Estar logado no sistema como aluno
Pós-condições:
1.1 Os atores ficam habilitados a realizar ações na área restrita

do sistema.
1.2Editar perfil
Requisitos Funcionais: RF-15 O aluno pode visualizar suas

informações no perfil e editá-las
34



dados MySQL
Fluxo Principal:
1. Logar no sistema
2. selecionar Perfil
3. fazer alterações
Fluxo Alternativo:
2.1 Sair do perfil selecionado.
3.1 cancelar alterações feitas e voltar a anterior.
Caso de uso UC-19: Descrição: Esse caso de uso especifica a ação do aluno em
Verificar horários verificar horários das aulas de cada UC
Atores: Aluno.
Pré-condições:
1.Logar no sistema para realizar as ações.
Pós-condições:

2.Verificar horários
Requisitos Funcionais: RF-02 O aluno tem acesso a uma tela

de horário das suas disciplinas e pode consultá-las sempre que
necessário.
35


dados MySQL
Fluxo Principal:
1.Logar no sistema
2.selecionar UC
3.verificar presença
Fluxo Alternativo:
3.1 mandar mensagens no chat do professor caso haja algum

erro.
Caso de uso UC-20: Descrição: Nesse caso de uso o aluno poderá mandar um
Enviar feedback feedback ao professor, dizendo suas críticas construtivas, se
está contente ou descontente com o professor ou escola.
Atores: Aluno
Pré-condições:
1. Logar no sistema.
Pós-condições:

Requisitos Funcionais: RF-12 O aluno pode mandar um

feedback de até duas mil palavras para o suporte.
36


dados MySQL
Fluxo Principal:
1. Logar no sistema
2. Entrar em feedbacks
3. selecionar Escrever feedback
4. Escrever um feedback de no máximo duas mil linhas
5. Selecionar Enviar feedback
Fluxo Alternativo:
2.1. Sair da aba feedback.
3.1 Apagar feedback.
4.1. limitador de palavras escritas
Caso de uso UC-21: Descrição: Esse caso de uso especifica a ação do usuário falar
Chat com o suporte com o suporte em caso de dúvidas, reclamações ou informações
Atores: Aluno, professor
Pré-condição:
1. logar no sistema
Pós condição:

2.Falar com o suporte.
Requisitos funcionais: RF-13 Tanto o aluno quanto o professor

devem ter acesso a um chat de suporte.
RQF 21 - O administrador pode se comunicar com os

professores via chat.
37
Requisitos não funcionais:



dados MySQL
Fluxo principal:
1. Logar no sistema
2. Selecionar Chat com o suporte
3. Enviar dúvida
Fluxo alternativo:
2.1 Sair do chat suporte.
3. receber notificação de resposta.
Diagrama de classe
38
IDAluno: Guilid
Modelagem de dados
Modelo entidade relacionamento
39
Modelo relacional
Tabela SQL
Login
40
Horários
Atividades
Questionário
41
Notas
42
Feedback
43

Trabalho Hissamu

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Trabalho Hissamu

Enviado por

Direitos autorais:

Formatos disponíveis

Autor Versão Data

Camile Pereira, José Guilherme.S.P.Fernandes, Julio Cesar

Camile Pereira, José Guilherme.S.P.Fernandes, Julio Cesar

José Guilherme.S.P.Fernandes, Mateus dos Santos Castro

Camile Pereira, José Guilherme.S.P.Fernandes, Julio Cesar

Camile Pereira, Julio Cesar Roque

Julio Cesar Roque, Kananda Rodrigues

Camile Pereira, Julio Cesar Roque

Julio Cesar Roque, Mateus dos Santos Castro

Mateus dos Santos Castro

Identificação dos casos de

Detalhamento dos casos de

Tabela SQL ...........................................................................................................................42

RQF 01 O sistema deve ter um login para confirmar a identidade do usuário.

RQF 03 O professor tem controle administrativo sobre uma ou mais turmas no

RQF 04 O professor pode enviar uma ou mais atividades e atribuir nota/peso a

RQF 05 O professor pode mandar notificações para aluno(s) em específico ou

RQF 06 O professor pode inserir um material em um plano de atividades de

RQF 07 O professor pode compartilhar um questionário com alunos de uma ou

RQF 08 O aluno pode ver sua presença semestral.

RQF 10 O Professor pode lançar as notas para cálculo automático.

RQF 11 O professor pode requisitar ao sistema que gere relatórios de uma ou

RQF 13 Tanto o aluno quanto o professor devem ter acesso a um chat de

RQF 14 O professor e o aluno devem ter um chat privado para conversar.

RQF 15 O aluno pode visualizar suas informações no perfil e editá-las.

RQF 16 O administrador pode gerenciar as turmas e os responsáveis por elas.

RQF 17 O administrador pode cadastrar os professores e alunos.

RQF 18 O administrador pode associar professores e alunos a uma ou mais turmas.

RQF 19 O administrador pode verificar o histórico de ações e atividades dos usuários.

RQF 20 O administrador pode tirar o acesso do professor ou reverter suas ações.

RQF 21 O administrador pode se comunicar com os professores via chat.

Requisitos Não Funcionais

RNF 01 Os relatórios devem ser todos gerados em formato (*.xls).

RNF 02 O sistema deve funcionar On-line apenas.

RNF 05 O sistema deve ser desenvolvido usando a linguagem java.

RNF 06 O sistema deve guardar a senha do usuário e criptografá-la

RNF 07 O sistema deve permitir que apenas o usuário autorizado acesse os

RNF 08 O sistema deve permitir que o usuário interaja com a interface de

RNF 11 O sistema deve ter um tempo de resposta menor que 3 segundos.

RNF 12 O sistema deve ser implementado em um servidor da AWS.

Identificação dos casos de uso

Detalhamento dos casos de uso

Atores: (a) Aluno, (b) Professor, (c) Administrador.

a) Aluno (usuário que tem acesso limitado ao sistema),

b) Professor (usuário que opera o sistema, habilitado ao

c) Administrador (usuário habilitado a realizar as ações de

1. Os atores devem estar cadastrados no sistema.

1. Os atores ficam habilitados a realizar ações na área

1. RF 28. O portal deve prover uma interface para clientes,

Requisitos não funcionais:

1. RNF 06. O sistema deve guardar a senha do usuário e

1. O ator decide se autenticar no sistema.

2. O sistema solicita as informações obrigatórias para a

autenticação: E-mail e Senha

3. O ator informa os dados de autenticação.

4. O sistema valida os dados de autenticação.

5. O sistema registra em histórico (log) a autenticação

6. O sistema habilita as ações relacionadas ao usuário ao

7. O sistema informa que a autenticação foi realizada com

O caso de uso se encerra.

1. 1. No passo 4 do Fluxo Básico, caso haja algum

1. 1. No passo 4 do Fluxo Básico, caso o sistema

1. No passo 1 do Fluxo Alternativo A, caso aconteça o erro

1. 2. O sistema bloqueia o ator.