Você está na página 1de 38

UNIVERSIDADE DO GRANDE RIO

PROF. JOSÉ DE SOUZA HERDY


ESCOLA DE CIÊNCIA E TECNOLOGIA
CURSO SUPERIOR DE TECNOLOGIA EM
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

Luan de Sena Barbosa

McPhee:
Uma web agenda escolar infantil

Duque de Caxias

2017
Luan de Sena Barbosa

McPhee - Uma web agenda escolar infantil

Projeto Final de Curso apresentado à


Universidade do Grande Rio “Prof. José de
Souza Herdy” (UNIGRANRIO) como parte dos
requisitos para conclusão do Curso Superior
de Tecnologia em Análise e Desenvolvimento
de Sistemas.

Orientador: Prof. Anderson Nascimento


McPhee - Web agenda escolar infantil

Luan de Sena Barbosa - 5404372

Projeto Final de Curso apresentado à


Universidade do Grande Rio “Prof. José de
Souza Herdy” (UNIGRANRIO) como parte dos
requisitos para conclusão do Curso Superior
de Tecnologia em Análise e Desenvolvimento
de Sistemas.

Aprovado em 12 de 2017.

BANCA EXAMINADORA

_________________________________________________________________________

Prof. Anderson Silva do Nascimento - Orientador


Instituição de origem: Unigranrio

_________________________________________________________________________

Prof. Natalia Joana Silva de Oliveira


Instituição de origem: Unigranrio

_________________________________________________________________________

Prof. João Paulo Voigtlaender


Instituição de origem: Unigranrio

Duque de Caxias
2017
Luan de Sena Barbosa

McPhee - Web agenda escolar infantil, Duque de


caxias, 2017.
XIII, 27 p. (Escola de Ciência e Tecnologia, 2017)

Projeto de Final de Curso - Universidade do Grande


Rio, Escola de Ciência e Tecnologia.
1. Single page applications
2. RESTful microservices
3. automação de processos
I. EIN/UNIGRANRIO II. Título (série)
Em memória de minha vó Lola e meu avô José.
AGRADECIMENTOS

Agradeço às duas mulheres que nunca me deixaram cair. Minha mãe Vilma
Barbosa e minha namorada Amanda Lamego, que foram e são minha motivação para
sempre superar todos os desafios encontrados pelo caminho.
“Viver é arriscar tudo. Caso contrário você é apenas um pedaço inerte de

moléculas montadas aleatoriamente à deriva onde o universo te sopra.”

Rick and Morty


RESUMO
Neste trabalho será desenvolvida uma aplicação web com a de finalidade ser
uma agenda escolar infantil online onde os gestores, professores e responsáveis poderão
ter toda a informação sobre o aluno de forma centralizada além de uma comunicação
mais direta e eficaz. Com o objetivo de reduzir o tempo gasto pelos professores em ações
repetitivas e manter os responsáveis atualizados com informações sobre seus filhos sem
necessidade de mudar sua rotina.

Neste trabalho será desenvolvida uma aplicação web utilizando a arquitetura


de software chamada Single Page Application na parte chamada Front-end. Esta
aplicação fará chamadas à um servidor de api restful desenvolvido em python no Back-
end. Os dados da aplicação serão persistidos em um banco de dados postgreSQL.

Palavras-chave: SPA, Restful, Python, Educação infantil


LISTA DE ILUSTRAÇÕES

Figura 1 - Diagrama de Caso de Uso…………………………………………………………... 9

Figura 2 - Diagrama de Classes………………………………………………………………… 17

Figura 4 - Projeto de Interface, Lançamento de diário para turma…………... 23

Figura 4 - Projeto de Interface, Perfil do aluno………………………………………… 24

Figura 5 - Projeto de Interface, Perfil logado no sistema…………………………. 25


LISTA DE TABELAS

Tabela 1 - Definição do Problema………………………………………………………………. 5

Tabela 2 - Descrição dos stakeholders / usuários……………………………………….. 6


LISTA DE ABREVIATURAS E SIGLAS

SPA Single Page Application

BD Banco de dados

API Application Programming Interface

REST Representational State Transfer


SUMÁRIO
1 Introdução………………………………………………………………………………………………………... 1
1.1 Justificativa………………………………………………………………………………………………….………2
1.2 Objetivo………………………………………………………………………………………………………………2
1.3 Delimitação do problema……………………………………………………………………………………3

2 Método de trabalho………………………………………………………………………………………….. 3
2.1 Empresa cliente / Negócio………………………………………………………………………………….. 3
2.2 Problemas / Soluções…………………………………………………………………………………………. 4

3 Documento de Visão…………………………………………………………………………………………. 5
3.1 Descrição da Proposta……………………………………………………………………………………….. 5
3.1.1 Descrição do domínio atual……………………………………...……………………………….. 5
3.1.2 Definição do problema…………………………………………………..………………………….. 5
3.1.3 Descrição dos stakeholders / usuários……..……………………………………………….. 5
3.1.4 Ambiente do usuário…………………………………………………………..…………………….. 6
3.1.5 Alternativas e Concorrência……………………………………...……………………………….. 6
3.1.6 Visão Geral do Produto………………………………………………….………………………….. 6
3.1.7 Perspectiva do Produto………………………………………………….………………………….. 6
3.1.8 Funcionalidades do Produto…………………………………..………………………………….. 7
3.1.9 Licenciamento e Instalação……………………………………………………………………….. 7
3.1.10 Interligação com Outros Sistemas…………….…………………………………………….. 7
3.1.11 Restrições……………………………………………………………………………………….……….. 7
3.2 Diagramas………………………………………………………………………………………………………….. 9
3.2.1 Diagrama de Caso de Uso……………………………………………………………………...….. 9
3.2.2 Descrição do Diagrama de Casos de Uso…………………………………………………… 9
3.2.2.1 Consultar perfil do aluno……………………………………………………..………….. 10
3.2.2.2 Manter diário…………………………………………………………………………………... 10
3.2.2.3 Manter Profissionais…………………………………………………………………...….. 11
3.2.2.4 Manter Alunos…………………………………………………………………………………. 11
3.2.2.5 Manter Escolas………………………………………………………………………………… 12
3.2.2.6. Manter Gestores…………………………………………………………………………….. 13
3.2.2.7. Enviar mensagem…………………………………………………………………………... 14
3.2.3 Diagrama de Classes……………………………………………………………………………………... 15

4. Tecnologias propostas……………………………………………………………………………………. 18
4.1 Single Page Application – SPA…………………………………………………………………………... 18
4.1.1 Descrição e Justificativa……………………………………………………………………………. 18
4.2 RESTful……………………………………………………..…………………………………………………….. 19
4.2.1 Descrição e justificativa……………………………………………………………………………. 19
4.3 Python 3 & Sanic 0.6…………………………………………………………………………………………. 20
4.3.1 Descrição e justificativa……………………………………………………………………………. 20
4.4 AngularJS………………………………………………………………………………………………………….. 21
4.4.1 Descrição e justificativa……………………………………………………………………………. 21
4.5 PostgresSQL…………………………………………………………………………………………………….. 22
4.5.1 Descrição e Justificativa……………………………………………………………………………. 22

5 Projeto de interface………………………………………………………………………………………… 23

Lançamento de diário para classe……………………………………………………………………. 23

Perfil do aluno.………………………………………………...………………………………………………. 24

Perfil logado no sistema.………………….………………………………………………………………. 24

6 Conclusão……………………………………………………………………………………………………….. 26
6.2 Trabalhos futuros……………………………………….……………………………………………………. 27

7 Referências Bibliográficas……………………………………………………………………………….. 28
1

1 Introdução

Agenda escolar tradicional é uma ferramenta utilizada pelas escolas de Educação


Básica como parte da comunicação entre família e escola, esta estratégia é usada a
muito tempo. contudo percebe-se poucas inovações no uso deste recurso. A
comunicação entre família e escola é de fundamental importância na relação de
confiança que precisa ser construída no processo educativo de qualquer indivíduo.

Além da pouca inovação na ferramenta de comunicação existe um enorme


desperdício de tempo dos docentes na realização da descrição das agendas diariamente.
Como também pouca padronização dos termos utilizados nesta ferramenta para melhor
interpretação das informações por ambos os lados.

Tendo em vista as problemáticas associadas a esta ferramenta e um campo


precioso de mercado, o uso da tecnologia da informação pode vir a ser um facilitador do
trabalho das escolas e dos professores e na melhoria da relação e comunicação família e
escola.
O projeto a ser desenvolvido será uma aplicação web de gerenciamento de agenda
escolar infantil. Nesta aplicação gestores e educadores terão a possibilidade de inserir
diversas informações sobre o dia a dia dos alunos, e os responsáveis por sua vez terão
estas informações disponíveis para consulta de uma forma prática e simples. Podendo
assim ter de forma organizada todo um acompanhamento do desenvolvimento da
criança e de possíveis ocorrências. A aplicação irá garantir uma comunicação
centralizada entre o responsável e a escola evitando a falta de informações sobre os
alunos.

1.1 Justificativa

Atualmente, existem poucas alternativas para a automatização de processos


dentro do ambiente escolar em especial na educação infantil. As poucas aplicações
existentes são pouco flexíveis e apresentam uma usabilidade muito pobre, requerendo
do usuário um grande esforço para se adaptar a sua interface. Além disso os meios
2

usados para comunicação entre escola de responsável costumam ser improvisações


pouco efetivas e não centralizadas, podendo causar o desencontro ou falta de
informações.
O trabalho parte do seguinte problema: professores de educação infantil até hoje
exercem a tarefa diária de preencher agendas físicas diariamente, tarefa esta que é
pouco dinâmica e repetitiva, ação esta que consome muito tempo do profissional e tem
uma efetividade muito baixa. Sujeita a um grande número de erros e sem muita
flexibilidade dado que os responsáveis só terão acesso às informações quando tiverem
acesso a agenda física no final do dia quando buscarem seus filhos. Os responsáveis
também tem poucas formas disponíveis para formalizar avisos ou enviar recados sobre
a criança.

1.2 Objetivo

O principal objetivo desta aplicação é melhorar todo o processo relacionado a


agenda escolar infantil. Aumentando a produtividade dos professores por meio da
automatização de tarefas, centralizando as informações sobre cada criança e sua
respectiva instituição de ensino, evitando o desencontro de informações entre
responsáveis de alunos e gestores escolares e mantendo os responsáveis mais
integrados com a vida escolar de seus filhos. Favorecendo assim para uma melhor
construção da relação família-escola.

1.3 Delimitação do problema

Com a aplicação de agenda escolar infantil o trabalho de preenchimento poderá


ter todas as etapas repetitivas automatizadas restando para o educador preencher
apenas as particularidades de cada aluno e assim economizando muito tempo antes
desperdiçado, além disso a comunicação entre responsáveis e escola ficará muito mais
efetiva pois o responsável pode ser notificado sobre atualizações na agenda da sua
criança ou até mesmo receber notificações diretas sobre avisos da escola.
3

2 Método de trabalho

O sistema será desenvolvido utilizando o conceito de micro serviços, onde o


sistema é composto em diversas aplicações menores chamadas de serviço ou API cada
uma com suas responsabilidades bem especificadas, não invadindo o domínio de outros
serviços. Neste trabalho haverá um total de 2 serviços, uma para a camada de view e um
para a camada de modelo e controle. O serviço da camada de view será construído em
HTML, CSS e JavaScript com auxílio do framework AngularJS. O serviço da camada de
modelo e controle será construído com a linguagem Python 3.6 com uso do framework
web Sanic 0.6. Toda a comunicação entre as camadas de view e controle serão feitas
através da troca de mensagens HTTP no formato JSON seguindo os conceitos da
arquitetura Restful.

2.1 Empresa cliente / Negócio


O projeto visa atender escolas direcionadas para a educação infantil, onde existe
muito trabalho manual e pouca ou nenhuma automação de processos, o modelo de
cobrança será flexível o bastante para atender todos os perfis possíveis de escola, o
sistema será capaz de administrar e centralizar informações mesmo para casos em que
existam múltiplas escolas relacionadas a um mesmo usuário, tornando este projeto um
ótimo candidato a se tornar uma ferramenta padrão no mercado alvo.

2.2 Problemas / Soluções


Um grande problema percebido na rotina das escolas infantis e nas organizações
como um todo no Brasil, é a falta da automação de processos repetitivos e um elevado
nível de burocracia que prejudica a sociedade como um todo. Especificamente nas
escolas com foco no ensino infantil, é comum os profissionais educadores perderem
diversas horas escrevendo relatórios diários sobres os alunos em suas respectivas
agendas.
4

O projeto a ser desenvolvido neste trabalho visa justamente eliminar este tipo de
processo repetitivo dando a todos os envolvidos uma forma fácil, prática e centralizada
de inserir e consultar dados sobre os alunos com alteração mínima na rotina do usuário
e por consequência melhorar a qualidade de vida de todos.
5

3 Documento de Visão

3.1 Descrição da Proposta

Este sistema funcionará como uma central de informações sobre o aluno em seu
dia a dia na instituição de ensino, essas informações serão inseridas pelos profissionais
de educação e consultadas pelos responsáveis de cada aluno, os gestores serão
responsáveis por manter os cadastros de alunos e professores.

3.1.1 Descrição do domínio atual


Atualmente todo o registro é feito em agenda de papel, sem nenhum tipo de
padrão ou automatização no processo.

3.1.2 Definição do problema


Tabela 1 - Definição do Problema
O problema existem poucos meios de comunicação efetivo
entre responsáveis e escola e além disso é
gasto muito tempo do professor no
preenchimento diário das agendas escolares.

Afeta O foco do professor nos alunos desviando sua


atenção para conseguir preencher as agendas.

O seu impacto é Torna necessário criar uma distração para


que os alunos não saiam do controle,
dependendo do número de alunos se torna
necessário um auxiliar.

3.1.3 Descrição dos stakeholders / usuários


Tabela 2 - Descrição dos stakeholders / usuários

Nome Representa Papel

Admin Administrador do sistema Manter cadastros de escolas e


como. gestores
6

Professor Agente principal para Inserem ocorrências em


inserção de novos registros alunos e administram turmas

Responsável Usuário final, apenas consulta Visualiza ocorrências


as informações inseridas atribuídas a o aluno vinculado

Gestor Administrador do sistema, Administram cadastros de


controla todo o fluxo turmas professores e alunos e
faz controle de acesso

3.1.4 Ambiente do usuário


Os usuários do sistema terão acesso a um sistema web onde será possível interagir
totalmente com o sistema de acordo com o nível de acesso do usuário, toda a administração do
sistema e manutenção de cadastros também será realizada através deste sistema web.

3.1.5 Alternativas e Concorrência


Não existe nenhum player no mercado de aplicativos de grande expressão que
desenvolva algo parecido com a proposta deste sistema.

3.1.6 Perspectiva do Produto


O sistema terá como meta ser totalmente amigável para todos os perfis de usuários. Para
isso irá se utilizar de técnicas de User Interface e User Experience com um baixo tempo de
resposta, tornando assim a experiência de utilização do sistema agradável. Também terá como
meta modificar o mínimo possível a rotina atual dos usuários tornando a adaptação rápida e
descomplicada.

3.1.7 Funcionalidades do Produto


O sistema visa disponibilizar uma progressive web application capaz de receber toda a
interação necessária para o controle de ocorrências e observações diárias sobre os alunos. As
principais funcionalidades seriam:

a. Agenda
Aqui, os professores serão capaz de inserir dados gerais sobre o dia a dia dos alunos e os
responsáveis poderão visualizar estes dados

b. Mensagens
Aqui, os professores ou gestores podem enviar notificações em tempo real para os
responsáveis em caso de algum tipo de urgência.
7

c. Cadastros
Parte do sistema onde apenas o gestor terá acesso e será possível cadastrar turmas, professores,
alunos e responsáveis. E ainda vincular alunos a seus devidos responsáveis.

d. Perfil do aluno
Cada aluno cadastrado terá um perfil centralizado todas as informações sobre ele e todos
os diários postados.

3.1.8 Licenciamento e Instalação


O sistema ficará hospedado em um serviço de nuvem e a instituição contratante deverá
pagar uma mensalidade calculada com base no número de total responsáveis vinculados a
alunos da instituição, não sendo necessário nenhum tipo de instalação ou configuração por parte
da instituição.

3.1.9 Interligação com Outros Sistemas


No momento em questão, não há interligações com outros sistemas, o que não impede de
haver tal relação no futuro, já que o software dispõe de acoplamento entre seus módulos.

3.1.10 Restrições
1. O sistema deverá estar acessível até dezembro de 2017.
2. O sistema deverá contar com uma interface auto explicativa.
3. O sistema precisava evitar qualquer tipo de travamento ou lentidão para o usuário.
4. Para que o sistema cumpra sua missão ele deverá interferir o mínimo possível na
rotina do usuário.
8

3.2 Diagramas

3.2.1 Diagrama de Caso de Uso

Figura 1 - Diagrama de Caso de Uso

3.2.2 Descrição do Diagrama de Casos de Uso

3.2.2.1 Consultar perfil do aluno


Nome do caso de uso Consultar perfil do aluno

Objetivo A aplicação permitirá consulta no perfil do aluno com


informações e diários sobre o mesmo.
Ator primário Profissional, responsável.

Precondições O ator deverá estar logado no sistema com acesso de


“profissional” ou “responsável”
Fluxo Principal 1. O ator realiza login no sistema
2. O sistema exibe a tela principal.
9

3. O ator clica no botão “Meus alunos”


4. O ator clica no aluno desejado
5. O sistema exibe o perfil do aluno
6. O caso de uso é finalizado.

Pós-condições 1. Após a execução desse Caso de uso o ator


deverá estar visualizando o perfil do aluno.

3.2.2.2 Manter diário

Nome do caso de uso Manter Diário

Objetivo A aplicação permitirá a inclusão, alteração, exclusão e


consulta no diário do aluno em um banco de dados
relacional SQL.
Ator primário Profissional.

Precondições O ator deverá estar logado no sistema com acesso de


“profissional”
Fluxo Principal 1. O ator realiza login no sistema.
2. O sistema exibe a tela principal com as
funcionalidades do ator.
3. O ator clica no botão Rotina.
4. O ator clica no botão “lançar diário”.
5. O sistema exibe a tela de Diário escolar.
6. O ator seleciona a turma desejada.
7. O ator digita o conteúdo do diário e confirma
8. O caso de uso é finalizado.
Pós-condições 1. Após a execução desse Caso de uso um
registro no diário escolar do aluno deverá: ter
sido cadastrado com sucesso/ter seus dados
alterados com sucesso/ter sido excluído com
sucesso.
2. O sistema manterá o usuário logado.
3. O sistema exibirá a tela inicial do Ator.
4. Os dados estarão atualizados no BD.
3.2.2.3 Manter Profissionais
Nome do caso de uso Manter Profissionais

Objetivo A aplicação permitirá a inclusão, alteração e exclusão,


de profissionais em um banco de dados relacional
SQL.
10

Ator primário Gestor.

Precondições O ator deverá estar logado no sistema com acesso de


“gestor”.
Fluxo Principal 1. O ator realiza login no sistema
2. O sistema exibe a tela principal com as
funcionalidades do gestor.
3. O ator clica no botão “Gestão > Profissionais”
4. O sistema exibe a tela de Profissionais da
instituição de ensino que o ator gerência.
5. O ator seleciona a opção desejada [A01] [A02]
[A03]
6. O caso de uso é finalizado.
Fluxo Alternativo[A01] - 1. O ator preenche o todos os campos do
Incluir Profissional formulário de cadastro de profissional.
2. O ator clica no botão Confirmar.
3. O sistema insere os dados no BD
4. Fim do caso de uso
Fluxo Alternativo[A02] - 1. O ator seleciona o profissional que deseja
Alterar Profissional alterar
2. O ator clica em “alterar”
3. O ator altera os campos que desejar, no
formulário de cadastro do profissional.
4. O ator clica em “Confirmar”.
5. O sistema altera os dados no BD.
6. O caso de uso é encerrado.
Fluxo Alternativo[A03] - 1. O ator seleciona o profissional que deseja
Excluir Profissional excluir
2. O ator clica em “excluir”
3. O ator clica em “Confirmar”.
4. O sistema altera os dados no BD para o estado
de “desativado”.
5. O caso de uso é encerrado.
Pós-condições 5.1 Após a execução desse Caso de uso um
profissional deverá: ter sido cadastrado com
sucesso/ter seus dados alterados com sucesso/ter
sido excluído com sucesso.
5.2 O sistema manterá o usuário logado.
5.3 O sistema exibirá a tela inicial do Ator.
5.4 Os dados estarão atualizados nas tabelas do BD.
11

3.2.2.4 Manter Alunos

Nome do caso de uso Manter Alunos

Objetivo A aplicação permitirá a inclusão, alteração e exclusão,


de alunos em um banco de dados relacional SQL.

Ator primário Gestor

Precondições O ator deverá estar logado no sistema com acesso de


“gestor”.
Fluxo Principal 1. O ator realiza login no sistema
2. O sistema exibe a tela principal com as
funcionalidades do gestor.
3. O ator clica no botão Alunos
4. O sistema exibe a tela de Alunos da instituição
de ensino.
5. O ator seleciona a opção desejada [A01] [A02]
[A03]
6. O caso de uso é finalizado.
Fluxo Alternativo[A01] - 1. O ator preenche o todos os campos do
Incluir aluno formulário de cadastro de profissional.
2. O ator vincula os responsáveis pelo aluno
3. O ator clica no botão Confirmar.
4. O sistema insere os dados no BD
5. Fim do caso de uso
Fluxo Alternativo[A02] - 1. O ator seleciona o profissional que deseja
Alterar aluno alterar
2. O ator clica em “alterar”
3. O ator altera os campos que desejar, no
formulário de cadastro do profissional.
4. O ator clica em “Confirmar”.
5. O sistema altera os dados no BD.
6. O caso de uso é encerrado.
Fluxo Alternativo[A03] - 1. O ator seleciona o profissional que deseja
Excluir aluno excluir
2. O ator clica em “excluir”
3. O ator clica em “Confirmar”.
4. O sistema altera os dados no BD para o estado
de “desativado”.
5. O caso de uso é encerrado.
Pós-condições 1. Após a execução desse Caso de uso um aluno
deverá: ter sido cadastrado com sucesso/ter
seus dados alterados com sucesso/ter sido
12

excluído com sucesso.


2. O sistema manterá o usuário logado.
3. O sistema exibirá a tela inicial do Ator.
4. Os dados estarão atualizados nas tabelas do
BD

3.2.2.5 Manter Escolas

Nome do caso de uso Manter Escolas

Objetivo A aplicação permitirá a inclusão, alteração e exclusão,


de escolas em um banco de dados relacional SQL.

Ator primário Admin

Precondições O ator deverá estar logado no sistema com acesso de


“admin”.
Fluxo Principal O ator realiza login no sistema
O sistema exibe a tela principal com as
funcionalidades do admin.
O ator clica no botão Escolas
O sistema exibe a tela de Escolas.
O ator seleciona a opção desejada [A01] [A02] [A03]
O caso de uso é finalizado.
Fluxo Alternativo[A01] - 1. O ator preenche o todos os campos do
Incluir escola formulário de cadastro de escola.
2. O ator clica no botão Confirmar.
3. O sistema insere os dados no BD
4. Fim do caso de uso
Fluxo Alternativo[A02] - 1. O ator seleciona o escola que deseja alterar
Alterar escola 2. O ator clica em “alterar”
3. O ator altera os campos que desejar, no
formulário de cadastro da escola.
4. O ator clica em “Confirmar”.
5. O sistema altera os dados no BD.
6. O caso de uso é encerrado.
Fluxo Alternativo[A03] - 1. O ator seleciona o escola que deseja excluir
Excluir escola 2. O ator clica em “excluir”
3. O ator clica em “Confirmar”.
13

4. O sistema altera os dados no BD para o estado


de “desativado”.
5. O caso de uso é encerrado.
Pós-condições 1. Após a execução desse Caso de uso uma escola
deverá: ter sido cadastrada com sucesso/ter
seus dados alterados com sucesso/ter sido
excluído com sucesso.
2. O sistema manterá o usuário logado.
3. O sistema exibirá a tela inicial do Ator.
4. Os dados estarão atualizados nas tabelas do
BD.

3.2.2.6. Manter Gestores

Nome do caso de uso Manter Gestores

Objetivo A aplicação permitirá a inclusão, alteração e exclusão,


de gestores em um banco de dados relacional SQL.
Ator primário Admin

Precondições O ator deverá estar logado no sistema com acesso de


“admin”.
Fluxo Principal 1. O ator realiza login no sistema
2. O sistema exibe a tela principal..
3. O ator clica no botão “Admin > Gestores”
4. O sistema exibe a tela de Gestores.
5. O ator seleciona a opção desejada [A01] [A02]
[A03]
6. O caso de uso é finalizado.

Fluxo Alternativo[A01] - 1. O ator preenche o todos os campos do


Incluir gestor formulário de cadastro de gestores.
2. O ator clica no botão Confirmar.
3. O sistema insere os dados no BD
4. Fim do caso de uso
Fluxo Alternativo[A02] - 1. O ator seleciona o gestores que deseja alterar
Alterar gestor 2. O ator clica em “alterar”
3. O ator altera os campos que desejar, no
formulário de cadastro da escola.
4. O ator clica em “Confirmar”.
5. O sistema altera os dados no BD.
6. O caso de uso é encerrado.
14

Fluxo Alternativo[A03] - 1. O ator seleciona o gestor que deseja excluir


Excluir gestor 2. O ator clica em “excluir”
3. O ator clica em “Confirmar”.
4. O sistema altera os dados no BD para o estado
de “desativado”.
5. O caso de uso é encerrado.
Pós-condições 1. Após a execução desse Caso de uso um gestor
deverá: ter sido cadastrada com sucesso/ter
seus dados alterados com sucesso/ter sido
excluído com sucesso.
2. O sistema manterá o usuário logado.
3. O sistema exibirá a tela inicial do Ator.
4. Os dados estarão atualizados nas tabelas do
BD.

3.2.2.7. Enviar mensagem

Nome do caso de uso Manter Mensagens

Objetivo A aplicação permitirá o envio de mensagens por parte


dos gestores e profissionais para responsáveis ligados
à seus respectivos alunos.
Ator primário Profissional, Gestor

Precondições O ator deverá estar logado no sistema com acesso de


“profissional” ou “gestor”.
Fluxo Principal O ator realiza login no sistema.
O sistema exibe a tela principal..
O ator clica no botão mensagens.
O exibe uma listagem com todos os contatos
disponíveis.
O Ator seleciona o contato desejado e digita a
mensagem
O ator clica em enviar.
O o sistema adiciona a mensagem digitada às
mensagens do destinatário
O caso de uso é finalizado.
Pós-condições Após a execução desse Caso de uso uma mensagem
deverá: ter sido cadastrada com sucesso/recebida
pelo destinatário
O sistema manterá o usuário logado.
O sistema exibirá a tela inicial do Ator.
Os dados estarão atualizados nas tabelas do BD.
15

3.2.3 Diagrama de Classes

Figura 2-Diagrama de Classes


16

4. Tecnologias propostas

4.1 Single Page Application - SPA

4.1.1 Descrição e Justificativa

Um aplicativo de página única(em inglês “single page application, ou SPA) é uma


aplicação desenvolvida para a web construída em apenas uma única página. Com o foco
em garantir uma experiência do usuário(ou UX) parecida com à de um software desktop.
Na SPA todos os arquivos HTML, CSS e JavaScript são carregados de uma única vez, ou
são carregados dinamicamente e adicionados a página de acordo com as ações
realizadas pelo usuário, a página não é recarregada em qualquer momento e não existe a
navegação ou redirecionamento entre outras páginas.1

A SPA foi escolhida devido ao perfeito casamento entre as características da SPA


e requisitos básicos do sistema dentre eles os principais são: desempenho, dado que o
sistema fica muito mais eficiente porque ele carrega o sistema completo na primeira
requisição, evitando que o usuário tenha diversos momento de carregamento e melhor
experiência do usuário já que não possui recarregamentos na página a experiência se
assemelha bastante a um aplicativo ou sistema desktop.

1 Blog locaweb - O que é single page application.


17

4.2 RESTful

4.2.1 Descrição e justificativa

Definido oficialmente pela W3C, Representational State Transfer (REST), em


português Transferência de Estado Representacional, é uma abstração da arquitetura da
World Wide Web (Web), o REST ignora detalhes de implementação e de sintaxe da Web
com o objetivo de focar na interação entre componentes e na sua interpretação de
elementos de dados significantes. Quando uma aplicação se utiliza da nomenclatura
RESTful é apenas uma maneira de informar que ela segue todas as regras de
implementação do REST.2

O REST foi escolhido por ser a maneira padrão de comunicação entre aplicações
modernas, dado que o RESTful preza pela comunicação via mensagens no formato de
JSON, essa comunicação se torna pouco custosa e muito mais eficaz tornando trivial o
recebimento, leitura e envio de dados.

2 IBM Developers works - RESTful definition.


18

4.3 Python 3 & Sanic 0.6

4.3.1 Descrição e justificativa

Python é uma linguagem com código aberto, de alto nível, interpretada, orientada
a objetos, com semântica dinâmica. Sua alta flexibilidade com estrutura de dados
combinados com tipagem dinâmica e uma ligação dinâmica entre objetos,faz python ser
muito atrativo para o desenvolvimento de aplicações rápidas, podendo ser usada para
projetos grandes ou para simples scripts de ligação entre componentes já existentes.3

O sanic é um framework também de código aberto e livre para o desenvolvimento


de serviços WEB, este é um dos frameworks com melhor desempenho em tempo de
resposta devido suas características específicas como a utilização do python 3+ e do
Async.4

O Python foi escolhido devido sua excelente curva de aprendizado e altíssima


produtividade, o desenvolvimento de APIs REST em python é extremamente eficaz a
combinação de python + sanic é capaz de produzir uma aplicação muito bem organizada,
com excelente desempenho e atendendo todas as regras do REST para então atingir o
RESTful.

3 Python Docs - What is python.


4 Github,Sanic - Sanic Read me.
19

4.4 AngularJS

4.4.1 Descrição e justificativa

AngularJS é um framework JavaScript open-source, mantido pelo Google, que


auxilia na execução de single-page applications. Seu objetivo é aumentar aplicativos que
podem ser acessados por um navegador web, a biblioteca lê o HTML que contém tags
especiais e então executa a diretiva na qual esta tag pertence, e faz a ligação entre a
apresentação e seu modelo, representado por variáveis JavaScript comuns. O valor
dessas variáveis JavaScript podem ser setadas manualmente, ou via um recurso JSON
estático ou dinâmico.5

O AngularJS foi escolhido para este projeto devido sua maturidade dado que é
mantido pela Google e já tem mais de 5 anos de desenvolvimento, com isso é possível
encontrar facilmente um grande suporte para qualquer tipo de problema que possa
ocorrer, o angular também garante uma grande facilidade para se comunicar com APIs
REST e para o controle de aplicações que seguem o modelo de single page applications.

4.5 PostgresSQL

4.5.1 Descrição e Justificativa

PostgreSQL é um sistema gerenciador de banco de dados(SGBD), desenvolvido


como projeto de código aberto, contando com recursos como: consultas complexas,
chaves estrangeiras, integridade transacional, controle de concorrência multi-versão,
suporte ao modelo híbrido objeto-relacional, visões, linguagem procedural entre
outros.6

O postgres foi escolhido por ser um SGDB gratuito e muito eficaz no seu
propósito, devido a maturidade do postgres ele conta com diversas features de maneira
bem estável e confiável, sendo muitas vezes melhor do que SGBDs proprietários de
empresas grandes, é comum ver o postgres sendo utilizado em grandes empresas como:
Apple, Cisco, IMDB, Red Hat, Skype, Sourceforge, Sun Microsystems etc.

5 AngularJS.org - Pagina inicial.


6 PostgreSQL.org - Pagina inicial.
20

5 Projeto de interface
Na interface exibida na Figura 3, mostra a parte do sistema onde será possível o
lançamento de diários de forma genérica para todos os alunos de uma determinada
turma de uma só vez, facilitando o principal trabalho pesado do professor, diários
individuais podem ser lançados diretamente no perfil do aluno.

Figura 3 - Projeto de Interface, Lançamento de diário para turma.

Na interface da exibida na figura 4, será possível visualizar todas as informações


de forma simples e centralizada sobre um determinado aluno, os diários também
21

ficaram disponíveis aqui em formato de linha do tempo, ordenado do mais recente para
o mais antigo.

Figura 4- Projeto de Interface, Perfil do aluno.

Nesta interface exibida na figura 5, o usuário com o perfil de administrador


poderá definir uma pessoa já cadastrada no sistema como gestor de uma escola a partir
22

do documento da pessoa e do número de identificação da escola cadastrada, gestores


podem cadastrar turmas, alunos e professores.

Figura 5 - Projeto de Interface, Cadastro de gestores.


23

6 Conclusão
Com a elaboração deste trabalho foi possível concluir após diversos diálogos com
uma professora com experiencia em escolas de educação infantil, foi constato que existe
uma grande deficiência nas instituições escolares como um todo. Uma grande deficiência
na gerência e manutenção dos processos utilizados para a prestação de informações aos
responsáveis.

Este trabalho argumenta que estes processos podem ser substituídos e em


maioria dos casos serem automatizados, gerando otimização de tempo e economia
financeira. A elaboração desse tipo de software tem um nível de complexidade dinâmico
que muda de acordo com o processo que está sendo automatizado, no caso deste projeto
identificar processos substituíveis será relativamente simples, dado que todo o processo
já é mapeado e basta somente identificar as melhores formas de informatizar e
automatizar.

Esse tipo de projeto causa um impacto direto na vida de seus usuários,


principalmente os pais dos alunos que passam a ter informações centralizadas e uma
melhor comunicação com a instituição na qual é confiada a guarda dos filhos. Os
professores por sua vez que podem concluir suas rotinas de administração da turma de
forma muito mais eficaz e ter mais tempo e mais qualidade em seu trabalho pedagógico
que é em suma o objetivo central do docente.

A utilização das tecnologias citadas no capítulo 4 deste trabalho possibilitaram o


desenvolvimento do projeto com uma excelente experiência de utilização para o usuário.
A combinação das técnicas Single Page Application e RESTful permitiram que a
navegação seja totalmente fluida, sem nenhum tipo de travamento ou lentidão. A
utilização do framework Sanic para o python aliada a utilização do banco de dados
Postgres resultou em um tempo médio de resposta de 31ms para cada request realizada.
24

6.2 Trabalhos futuros

Adicionar funcionalidade de push notification(Notificação push)

Envio de notificações diretamente nos dispositivos que os usuários usam para


acessar o sistema, tanto web quanto mobile. alertando sobre lançamentos de novos
diários, mensagens ou qualquer tipo de atividade na aplicação.

Internacionalizar a aplicação

Traduzir a aplicação para mais 2 idiomas no mínimo, sendo eles inglês e espanhol
e parametrizar a exibição do sistema de acordo com o cadastro do usuário, permitindo
que o projeto não se limite apenas a escolas brasileiras.

Adicionar funcionalidade mural escolar

Será um recurso no aplicativo onde os gestores e professores de uma


determinada escola poderão postar notícias, eventos e recados relacionados à escola
para a visualização e interação dos responsáveis

Separar o backend e mais micro serviços

Com o intuito de ganhar escalabilidade a separação do backend em micro


serviços especializados permite uma grande versatilidade na hora de suportar um
número maior de usuários, permitindo por exemplo: aumentar o número de réplicas do
serviço de login, sem replicar a aplicação inteira.
25

7 Referências Bibliográficas
RAMALHO,Luciano. Python Fluente. São Paulo:Novatec, 2015.

MARTIN, Robert. Código Limpo. Rio de Janeiro: Alta Books, 2011.

Google Developers. Progressive Web Apps. Disponível em:


<https://developers.google.com/web/progressive-web-apps/>. Acesso em: 08 Jun
2017.

Blog locaweb . O que é single page application. Disponível em:


<http://blog.locaweb.com.br/artigos/desenvolvimento-artigos/o-que-e-single-page-
application/>

Wikipédia. Aplicação de página única. Disponível em:


<https://pt.wikipedia.org/wiki/Aplicativo_de_p%C3%A1gina_%C3%BAnica>

Wikipédia. REST. Disponível em: <https://pt.wikipedia.org/wiki/REST> Acesso em: 17


Nov 2017.

IBM developers works. Restful definition.Disponível em:


<https://www.ibm.com/developerworks/library/ws-restful/index.html> Acesso em: 17
Nov 2017.

Python docs. What is python. Disponível em:


<https://www.python.org/doc/essays/blurb/> Acesso em: 17 Nov 2017.

Github. Sanic github repository. Disponível em:


<https://github.com/channelcat/sanic> Acesso em: 17 Nov 2017.

Wikipédia. Angular JS. Disponível em: <https://pt.wikipedia.org/wiki/AngularJS>


Acesso em: 17 Nov 2017.

Google AngularJS. AngularJS homepage. Disponível em: <https://angularjs.org/>


Acesso em: 17 Nov 2017.

Wikipédia. PostgreSQL. Disponível em: <https://pt.wikipedia.org/wiki/PostgreSQL>


Acesso em: 17 Nov 2017.

PostgreSQL homepage. postgreSQL homepage. Disponível em:


<https://www.postgresql.org/?&> Acesso em: 17 Nov 2017.

Quora . who uses PGSQL. Disponível em: <https://www.quora.com/Who-uses-


PostgreSQL> Acesso em: 17 Nov 2017.