desenvolvimentodeumsistemade ...monografias.ufop.br/bitstream/35400000/1094/1/monografia... ·...

Universidade Federal de Ouro PretoInstituto de Ciências Exatas e AplicadasDepartamento de Computação e Sistemas

Desenvolvimento de um Sistema deControle de Recursos Audiovisuais em

uma Escola

Cayque Domingues dos Santos

TRABALHO DECONCLUSÃO DE CURSO

ORIENTAÇÃO:Diego Garcia Zuquim Guimarães

Junho, 2018João Monlevade–MG

Cayque Domingues dos Santos

Desenvolvimento de um Sistema de Controlede Recursos Audiovisuais em uma Escola

Orientador: Diego Garcia Zuquim Guimarães

Monografia apresentada ao curso de Sistemas de In-formação do Instituto de Ciências Exatas e Aplicadas,da Universidade Federal de Ouro Preto, como requi-sito parcial para aprovação na Disciplina “Trabalho deConclusão de Curso II”.

Universidade Federal de Ouro PretoJoão MonlevadeJunho de 2018

Catalogação: [email protected]

S237d Santos, Cayque Domingues. Desenvolvimento de um sistema de controle de recursos audiovisuais emuma escola [manuscrito] / Cayque Domingues Santos. - 2018.

58f.: il.: color; tabs.

Orientador: Prof. Dr. Diego Garcia Zuquim Guimarães.

Monografia (Graduação). Universidade Federal de Ouro Preto. Instituto deCiências Exatas e Aplicadas. Departamento de Computação e Sistemas deInformação.

1. Sistemas de informação. 2. Software - Desenvolvimento. I. Guimarães,Diego Garcia Zuquim . II. Universidade Federal de Ouro Preto. III. Titulo.

CDU: 004.775

Este trabalho é dedicado todas as pessoas que acreditam que esforço e trabalho duro são achave para o sucesso!

Agradecimentos

Agradeço primeiramente aos meus pais que sempre mostraram-me que a educaçãoé o caminho para tudo na vida.

Um agradecimento especial para minha namorada Carolina, que foi o meu portoseguro desde o começo dessa caminhada, te amo linda!

Ao Diego, por aceitar o meu convite e apoiar-me até esse momento, e a todos osmeus colegas de graduação, de um jeito ou de outro cada um de vocês teve um papel nessacaminhada.

“Não é o bastante ver que um jardim é bonito sem ter que acreditar também que há fadasescondidas nele?”

— Douglas Adams (1934 – 1996),in: O Guia do Mochileiro das Galáxias.

ResumoDiversos estudos comprovam os benefícios do uso da tecnologia dentro das salas de aula,pensando nisso, uma renomada escola particular da cidade de João Monlevade disponibilizapara o seu corpo docente diversos recursos audiovisuais, para tornar as aulas mais dinâmicase interativas. Entretanto, esses recursos são gerenciados de forma muito arcaica, atravésde uma planilha de papel, sendo assim, o objetivo desse trabalho foi o desenvolvimento deum sistema web, o SysAudio que permite o gerenciamento de todos os recursos de formasimples e online. Espera-se assim que o Sistema seja utilizado pela instituição de ensino.

Palavras-chaves: educação. sistema web. desenvolvimento web. framework web.

AbstractSeveral studies prove the benefits of the use of technology inside the classroom, Thus,a renowned school in João Monlevade, makes available to its staff various audiovisualresources to make the classes dynamic and interactive. However, these resources arearchaically managed in a papaer spreeadsheet. There fore, the aim of this work was thedevelopment of a web system, called SysAudio that allows the simple and online managemetof all the resources.

Key-words: education. web system. web development. framework web.

Lista de ilustrações

Figura 1 – Logo do Laravel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Figura 2 – Logo do Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figura 3 – Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . 29Figura 4 – Mapa do site - Administrador . . . . . . . . . . . . . . . . . . . . . . . 30Figura 5 – Mapa do site - Professor . . . . . . . . . . . . . . . . . . . . . . . . . . 31Figura 6 – Mapa do site - Convidado . . . . . . . . . . . . . . . . . . . . . . . . . 31Figura 7 – Diagrama ER da base de dados . . . . . . . . . . . . . . . . . . . . . . 32Figura 8 – Formulário de cadastro de um novo recurso . . . . . . . . . . . . . . . 35Figura 9 – Tela inicial do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Figura 10 – Tela de login do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figura 11 – Horário alocado para um usuário. . . . . . . . . . . . . . . . . . . . . . 37Figura 12 – Menu "Minhas marcações". . . . . . . . . . . . . . . . . . . . . . . . . . 38Figura 13 – Opção de cancelar uma locação. . . . . . . . . . . . . . . . . . . . . . . 38Figura 14 – Operação para filtrar a tabela de locações por data . . . . . . . . . . . 38Figura 15 – Tentativa de acesso indevido bloqueada. . . . . . . . . . . . . . . . . . 39

Lista de tabelas

Tabela 1 – Requisitos não funcionais . . . . . . . . . . . . . . . . . . . . . . . . . 26Tabela 2 – Funcionalidades - Administrador . . . . . . . . . . . . . . . . . . . . . 28Tabela 3 – Funcionalidades - Professor . . . . . . . . . . . . . . . . . . . . . . . . 28Tabela 4 – Funcionalidades - Convidado . . . . . . . . . . . . . . . . . . . . . . . 28

Lista de abreviaturas e siglas

JM João Monlevade

CRUD Create, Read, Update and Delete

MVC Model-View-Controller

SGBD Sistema de Gerenciamento de Banco de Dados

SQL Structured Query Language

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.1 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4.1 Estudo do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.4.2 Escolha das Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.5 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 REVISÃO BIBLIOGRÁFICA . . . . . . . . . . . . . . . . . . . . . . 192.1 Sistemas de informação . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2 Engenharia de Software . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3 Aplicações Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4 Processos de software . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5.1 Model-View-Controller (MVC) . . . . . . . . . . . . . . . . . . . . . . . . 212.5.2 Laravel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.5.3 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.6 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.6.1 MySql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.7 Ferramentas de produtividade . . . . . . . . . . . . . . . . . . . . . . 242.7.1 GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.7.2 Atom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . 253.1 Identificação do Problema . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 Levantamento de Requisitos . . . . . . . . . . . . . . . . . . . . . . . 253.2.1 Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.2 Requisitos não funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.3 Usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.4 Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.4.1 Administrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.4.2 Professor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.4.3 Convidado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.5 Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.5.1 Diagramas de caso de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.6 Mapa do Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.6.1 Administrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.6.2 Professor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.6.3 Convidado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.1 Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.2 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.3 Locacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.4 Desenvolvimento do Sistema . . . . . . . . . . . . . . . . . . . . . . . 333.4.1 Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.2 Operações de CRUD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.3 Alocação de Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.4.4 Cancelar locação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.4.5 Visualizações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.5 Verificações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5.1 Validação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5.2 Acesso indevido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5.3 Tradução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.1 Apresentação do SysAudio ao colégio . . . . . . . . . . . . . . . . . . 414.1.1 Sugestões de melhorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

APÊNDICES 44

APÊNDICE A – CASOS DE USO - CONVIDADO . . . . . . . . . 45A.1 Caso de Uso I - Registro . . . . . . . . . . . . . . . . . . . . . . . . . 45A.2 Caso de Uso II - Visualizar Marcações Gerais . . . . . . . . . . . . . 45

APÊNDICE B – CASOS DE USO - PROFESSOR . . . . . . . . . . 47B.1 Caso de Uso I - Inserir Marcação . . . . . . . . . . . . . . . . . . . . 47B.2 Caso de Uso II - Visualizar Marcações Próprias . . . . . . . . . . . . 47B.3 Caso de Uso III - Cancelar Marcação . . . . . . . . . . . . . . . . . . 48

APÊNDICE C – CASOS DE USO - ADMINISTRADOR . . . . . . 50C.1 Caso de Uso I - Liberar Acesso Usuário . . . . . . . . . . . . . . . . . 50C.2 Caso de Uso II - Adicionar Recurso . . . . . . . . . . . . . . . . . . . 51C.3 Caso de Uso III - Listar Usuários . . . . . . . . . . . . . . . . . . . . . 51C.4 Caso de Uso IV - Inserir Marcação . . . . . . . . . . . . . . . . . . . 52C.5 Caso de Uso V - Editar/Excluir Recurso . . . . . . . . . . . . . . . . 53C.6 Caso de Uso VI - Alterar Tipo do Usuário . . . . . . . . . . . . . . . 54C.7 Caso de Uso VII - Excluir Locação . . . . . . . . . . . . . . . . . . . . 55

16

1 Introdução

Tecnologias são aplicadas em grande escala na educação nos tempos atuais, devidoao seu potencial de agregar conhecimento, mais especificamente recursos audiovisuais.Segundo Rosa (2000) "Um filme ou um programa multimídia têm um forte apelo emocionale, por isso, motivam a aprendizagem dos conteúdos apresentados pelo Professor". Alémdisso, a quebra de ritmo provocada pela apresentação de um audiovisual é saudável, poisaltera a rotina da sala de aula.

É importante frisar, que o uso da tecnologia só traz benefícios para o ensinoe aprendizagem, quando se aplicada da maneira correta, focando em atrair a atençãodos alunos e não dispersá-los. Segundo Pesquisa. . . (2017) "84% dos docentes no Brasilalegam utilizar o projetor para exposição de imagens, fotos e vídeos integrados à disciplinacurricular em sala de aula".

Pensando em todos os benéficos que recursos tecnológicos podem agregar em umasala de aula, uma renomada escola da cidade de João Monlevade (JM), disponibiliza parao seu corpo docente salas de projeção, TV’s, auditórios e diversos outros recursos, com ointuito de tornar as aulas mais dinâmicas, práticas e atrativas.

Assim, o presente trabalho visa a implementação de um sistema web, chamadode SysAudio, para a substituição do meio de gerenciamento atual, com o objetivo defornecer uma plataforma simples que permita operações de Create, Read, Update andDelete (CRUD) para os recursos, e um ambiente para realizar a alocação dos mesmos.

1.1 ProblemaA instituição ao qual o sistema se destina é uma escola particular da cidade de

João Monlevade (JM), referência na região, o colégio está a mais de 50 anos no mercado, eatende alunos do berçário ao ensino médio. O colégio possui diversos recursos tecnológicosque ficam a disposição dos professores e alunos, que podem ser usados em sala de aula,recursos esses, tais como, salas de projeção, TV’s, auditórios e diversos outros. A alocaçãodesses recursos é feita através de uma planilha de papel, onde um professor deve marcar oseu nome no horário que deseja utilizar algum determinado recurso, um funcionário ficaencarregado de conferir essa planilha e fazer o processo de ligar e/ou manejar o recurso.

É fácil perceber como a solução atual é dispendiosa, existe uma necessidade dedeslocamento físico tando de quem deseja utilizar um determinado recurso, como de quemnecessita manejá-lo. Além disso, não existe um meio de alerta para quando um recurso foragendado, ou um controle sobre quais recursos são mais utilizados ou qualquer outro tipo

Capítulo 1. Introdução 17

de controle.

1.2 ObjetivosNesta seção, são apresentados os objetivos gerais e específicos do trabalho desen-

volvido

1.2.1 Objetivo Geral

Desenvolver um Sistema de Controle de Recursos Audiovisuais em uma instituiçãode ensino.

1.2.2 Objetivos Específicos

Os objetivos específicos do trabalho são:

• Identificar o problema;

• Levantar os requisitos necessários para desenvolvimento da plataforma web;

• Incorporar todas as funções de Create, Read, Update and Delete (CRUD) referentesaos recursos audiovisuais;

• Realizar os testes da plataforma junto aos usuários da instituição.

1.3 JustificativaA justificativa de se produzir um sistema para gerenciar os recursos audiovisuais do

colégio é sustentada pela ideia de que se gasta muito esforço com a solução atual, diversassituações inconvenientes surgem, pelo simples fato do processo não possuir um controlemais rígido. Um sistema pode agregar muito mais valor, tornando o processo mais simplese controlável. Espera-se que a instituição adote a solução proposta, substituindo a soluçãoatual.

1.4 MetodologiaNesta seção são definidas as etapas do desenvolvimento do trabalho, mas sem entrar

em muitos detalhes, pois tudo será devidamente especificado no Capítulo 3.

Capítulo 1. Introdução 18

1.4.1 Estudo do Problema

Uma vez que foi percebida a necessidade do desenvolvimento desse trabalho, comojá descrito nas seções anteriores, foi a vez de buscar na literatura e conhecimentos práticos,formas de melhor fazê-lo. Sendo assim, algumas pesquisas foram feitas para a escolha deaspectos como tecnologias e formas de tratar o problema.

1.4.2 Escolha das Tecnologias

Após um breve estudo e pesquisa, foram escolhidas as seguintes ferramentas/tecnologias:

• Plataforma: Web;

• Linguagem: PHP, Javascript, HTML e CSS ;

• Framework: Laravel e Bootstrap;

• Banco de Dados: MySql.

As justificativas das escolhas de cada item serão feitas nas seções posteriores, ondealém disso, será abordado também o que cada uma dessas tecnologias representa.

1.5 Organização do trabalhoO presente trabalho é dividido em 5 capítulos. No Capítulo 2 é apresentada a

revisão bibliográfica que fundamenta todo o trabalho, em seguida temos o Capítulo 3 quetraz o desenvolvimento do trabalho propriamente dito, no Capítulo 4.1 são apresentados osresultados obtidos com o trabalho, e por fim, no Capítulo 5, são apresentadas as conclusõesfinais do trabalho.

19

2 Revisão Bibliográfica

Este capítulo estrutura toda a fundamentação teórica do trabalho, e apresentatodas ferramentas e tecnologias utilizadas no desenvolvimento do SysAudio.

2.1 Sistemas de informação

Um Sistema de Informação pode ser definido tecnicamente como umconjunto de componentes interrelacionados que coleta (ou recupera),processa, armazena e distribui informações destinadas a apoiar a tomadade decisões, a coordenação e o controle de uma organização. Além de darsuporte à tomada de decisões, à coordenação e ao controle, esses siste-mas também auxiliam os gerentes e trabalhadores a analisar problemas,visualizar assuntos complexos e criar produtos (LAUDON, 2011).

Os sistemas de informação possuem três dimensões segundo Laudon (2011):

• Organizações: É o ambiente em que o sistema está inserido, uma organização têmum estrutura composta por diferentes níveis e especializações;

• Pessoas: Os sistemas são inúteis sem as pessoas para desenvolvê-los e mantê-los e semque saiba usar as informações de um sistema para atingir os objetivos organizacionais.

• Tecnologias: A tecnologia da informação é uma das muitas ferramentas que osgerentes utilizam para enfrentar mudanças. Hardware é o equipamento físico usadopara atividades de entrada, processamento e saída de um sistema de informação.Software consiste em instruções detalhadas e pré-programadas que controlam ecoordenam os componentes do hardware de um sistema de informação.

2.2 Engenharia de SoftwareA engenharia de software é um ramo da engenharia cujo foco é o desenvolvimento

dentro de custos adequados de sistemas de software de alta qualidade (SOMMERVILLE,2007). Ou seja, é o estudo de métricas de produção de software, trazendo padrões eorientações das melhores práticas para se implementar um software.

A Engenharia de Software se preocupa com o software enquanto produto.Estão fora de seu escopo programas que são feitos unicamente paradiversão do programador. Estão fora de seu escopo também pequenosprogramas descartáveis, feitos por alguém exclusivamente como meiopara resolver um problema, e que não serão utilizados por outros (FILHO,2003).

Capítulo 2. Revisão Bibliográfica 20

Dentro da engenharia de software a configuração de software é uma área responsávelpor fornecer apoio para o desenvolvimento de software, Pressman (1995) afirma que todaconfiguração de software segue as seguintes etapas:

• Plano de projeto: todas as etapas do desenvolvimento do software são pensadas aqui;

• Especificações de requisitos: especificação do que o software deve ou não fazer;

• Desenho arquitetônico: quais tecnologias o software vai utilizar;

• Estruturas de dados: como o sofware vai persistir os seus dados;

• Manual do usuário: especificações de uso daquele software;

• Especificações de teste: rotinas de testes que verificam a adequação dos requisitosdefinidos;

• Programa executável: entrega do software ao cliente.

2.3 Aplicações WebCom o crescimento exponencial da internet ao redor do mundo, é cada vez mais

comum o surgimento de aplicações web, que exigem apenas uma conexão do usuário paraprover diversos tipos de serviço, seja um internet banking, um site de compras ou umarede social. Hoje em dia a web não fornece apensas simples páginas em HTML com textose informações, sistemas completos podem ser acessados pela internet.

Laudon (2011) afirma que "A força da computação em nuvem e o crescimento daplataforma digital móvel significam que as organizações podem confiar mais em teletrabalho,trabalho remoto e tomada de decisão distribuída". Ou seja, os meios de utilizar e distribuirserviços online é cada vez mais comum.

Toda aplicação disponibilizada na web é sustentada por um servidor, que hospedaos sites e sistemas que podem ser acessados de qualquer parte do globo, por alguémconectado à rede mundial de computadores.

2.4 Processos de softwareSegundo Sommerville (2007) "Um processo de software é um conjunto de atividades

que leva à produção de um produto de software". O processo de desenvolvimento de umsofware envolve o uso linguagens de programação e a força do intelectual humano, paraempregar soluções.

Embora cada desenvolvimento de software seja único, Sommerville (2007) afirmaque todos eles passam pelas seguintes etapas:


• Especificação: A funcionalidade do software e as restrições sobre sua operaçãodevem ser definidas;

• Projeto e implementação: O software que atenda à especificação deve ser produ-zido;

• Validação: O software deve ser validado para garantir que ele faça que o clientedeseja.

• Evolução: O software deve evoluir para atender às necessidades mutáveis do cliente.

2.5 FrameworksO desenvolvimento de software é algo que se cobra cada vez mais rapidez e qualidade,

variáveis que muitas vezes se contradizem, pois não é fácil entregar produtos com um altopadrão de qualidade, e de forma rápida, com base nisso, o uso de Frameworks pode tornaresse processo um pouco menos complicado.

Segundo Wirfs-Brock e Johnson (1990) "Um Framework pode ser considerado comoum projeto ou arquitetura de alto nível, consistindo de classes que são especialmenteprojetadas para serem refinadas e usadas em grupo".

As vantagens da utilização de um Framework são muitas, entre elas, está o fato deque o código se torna mais coeso e de fácil manutenção, tanto pelo próprio programador,como por terceiros, além de trazer um certo tipo de padronização. Frameworks tornamprojetos mais ágeis e práticos, mas uma certa atenção se faz necessária, quanto ao domínioda linguagem nativa que o Framework utiliza, pois no começo pode ser complicado entendercomo se dá os processos internos da ferramenta.

2.5.1 Model-View-Controller (MVC)

O desenvolvimento web é um grande adepto do uso de Frameworks, e a maioriadeles faz uso do padrão de arquitetura Model-View-Controller (MVC).

• Model: responsável por gerenciar os dados dos sistema.

• View: define como os dados serão apresentados ao usuário, além de definir a interaçãocom o usuário.

• Controller: envia comandos para o model para alterar o seu estado e para o viewpara atualizá-lo, além de responder as interações do usuário.


2.5.2 Laravel

O Laravel foi criado em 2011 por Taylor B. Otwell. Segundo McCool (2012) "OLaravel1 é um framework de desenvolvimento web MVC escrito em PHP, que foi projetadopara melhorar a qualidade do software, reduzindo o tempo de desenvolvimento e o custode manutenção". O Laravel é Open Source, o que contribui muito para a sua difusão nomercado, tornando-o um dos frameworks mais utilizados atualmente.

O Laravel foi escolhido para utilização no desenvolvimento deste trabalho por todasas vantagens citadas anteriormente. Um outro ponto chave na escolha dessa tecnologia, foisua simplicidade em executar tarefas, mas mesmo assim se mantendo robusto e poderoso,ele faz com que processos complicados se tornem transparentes e fáceis de serem executados,depois que sua curva de aprendizagem é superada. A Figura 1 apresenta o logo do Laravel.

Figura 1 – Logo do Laravel

Fonte: Começando. . . (2017)

2.5.3 Bootstrap

Outro Framework utilizado no desenvolvimento do trabalho foi o Bootstrap2, umkit de ferramentas de código aberto para desenvolvimento com HTML, CSS e JS. Possui agrande vantagem de entregar elementos responsivos que se adaptam a diferentes tamanhose resoluções de telas. Sua incorporação em projetos pode ser feita através de um arquivo.CSS ou do uso de CDN, no trabalho foi utilizada a segunda opção, para garantir que aversão utilizada seja sempre a mais recente e atualizada. A Figura 2 apresenta o logo doBootstrap.

O Bootstrap foi escolhido para utilização neste trabalho, por sua facilidade ementregar elementos visuais bonitos e responsivos, sem o uso de arquivos .CSS de forma direta,1 https://laravel.com/2 https://getbootstrap.com/


o que economiza tempo no desenvolvimento, além de possuir uma vasta documentaçãoque oferece um excelente suporte.

Figura 2 – Logo do Bootstrap

Fonte: Bootstrap. . . (2018)

2.6 Banco de DadosPraticamente todo tipo de aplicação precisa ter seus dados persistidos de alguma

forma, na maioria das vezes é utilizado algum tipo de banco de dados, que nada mais éque uma coleção organizada de dados. Todo banco de dados é gerenciado por um Sistemade Gerenciamento de Banco de Dados (SGBD), Silberschatz, Korth e Sundarshan (2016)define um SGBD como "Uma coleção de dados inter-relacionados e conjunto de programaspara acessar esses dados".

2.6.1 MySql

Como já citado, um SGBD tem a função de gerenciar e dar suporte a um bancode dados, nesse projeto, o SGBD escolhido foi o MySql3, mantido pela Oracle4, esse é oSGBD open source mais utilizado no mundo. Como seu nome sugere, o MySql trabalhacom a linguagem Structured Query Language (SQL), sendo assim um gerenciador de bancode dados relacional.

O uso de banco de dados relacional foi tida como a melhor escolha para esse projetouma vez que existe relacionamentos claros entre as entidades observadas, o que facilita asconsultas e as operações sobre os dados da base.3 https://www.mysql.com/4 https://www.oracle.com/


2.7 Ferramentas de produtividadeCom o intuito de tornar o desenvolvimento deste trabalho mais simples e produtivo,

foram utilizadas as ferramentas que são descritas a seguir.

2.7.1 GitHub

O GitHub5 é uma plataforma que implementa o Git para a hospedagem de código-fonte com controle de versão. Uma excelente ferramenta para manter o controle sobre oscódigos criados, além de permitir operações de backup e recuperação de códigos.

2.7.2 Atom

O Atom6 é um editor de texto de código aberto disponível para as plataformasLinux, macOs e Microsoft Windows, desenvolvido pelo GitHub. O Atom foi utilizado paraescrever todos os códigos-fonte deste trabalho, sua interface limpa e completa, além desua integração com o GitHub foram os fatores que levaram à sua escolha em detrimentode outros editores.

5 https://github.com/6 https://atom.io

25

3 Desenvolvimento

Este capítulo descreve o desenvolvimento do trabalho, abordando todas as etapasda criação do software.

3.1 Identificação do ProblemaA locação de recursos na instituição sempre demonstrou sinais de um gerenciamento

falho, diversas sugestões de melhorias foram propostas, mas todas em caráter verbal. Aideia de projetar um software para esse controle foi uma tentativa mais prática de solucionaros seguintes problemas atuais:

• Deslocamento físico: Todas as pessoas que desejam ter acesso a tabela de marcação,precisam se deslocar até uma sala específica da instituição, seja para apenas umaconsulta ou para realizar a alocação de um recurso. Não sendo possível alocar umhorário fora da escola, por exemplo. Outro agravante dessa situação é a retirada databela de marcação por um professor sem aviso prévio.

• Agendar horários futuros: Como a tabela de marcação é impressa mês a mês, émuito comum no final de um mês, os professores tentarem marcar um horário para omês seguinte, mas a tabela de tal mês ainda não estar disponível.

• Falta de padronização: Toda marcação é feita de forma manual, seja com umacaneta ou um lápis, o que causa uma total falta de padronização, onde cada pessoafaz a marcação a sua maneira.

• Falta de planejamento: Os funcionários responsáveis por ligar e desligar os recursosprecisam se deslocar a cada troca de horário até o local onde a tabela se encontra,para conferir se um novo recurso foi alocado.

3.2 Levantamento de Requisitos"Os requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e as

suas restrições operacionais"(SOMMERVILLE, 2007). Essa fase é de suma importância emqualquer tipo de sistema, sendo assim, nessa etapa do desenvolvimento foram levantadosos usuários do sistema, funcionalidades que esses usuários podem ter acesso e seus casosde uso.

O levantamento de requisitos foi feito através da análise do método atual dealocação de requisitos da instituição, todos os processos atuais foram abstraídos para

Capítulo 3. Desenvolvimento 26

serem modelados dentro do software, além da criação de novos processos, para suprir ascarências percebidas na Seção 3.1.

3.2.1 Requisitos funcionais

"Requisitos funcionais são as declarações de serviços que o sistema deve fornecer,como o sistema deve reagir a entradas específicas e como o sistema deve se comportar emdeterminadas situações"(SOMMERVILLE, 2007). Com base nisso foram levantados osseguintes requisitos funcionais que o SysAudio deve atender:

• O sistema irá permitir o cadastro de diversos tipos de recursos audiovisuais;

• O sistema deve permitir o cadastro de usuários com visões diferentes dentro domesmo;

• O sistema deve permitir o bloqueio e desbloqueio de um determinado usuário, emrelação ao ambiente de alocação de recursos.

3.2.2 Requisitos não funcionais

"Requisitos não funcionais são restrições sobre os serviços ou as funções oferecidospelo sistema"(SOMMERVILLE, 2007). A Tabela 1 apresenta os requisitos não funcionaisdo SysAudio.

Tabela 1 – Requisitos não funcionais

Requisito Descrição Prioridade

UsabilidadeO sistema deve prover uma interfacelimpa e simples, para aumentar a aceitaçãodos usuários.

Alta

Arquitetura O sistema deve ser desenvolvido como umaaplicação web. Média

Segurança O sistema deve exigir login para as operaçõesde escrita. Alta

Fonte: Produzido pelo autor

3.2.3 Usuários

O sistema deve ser acessado por todo corpo docente do colégio, além de seus alunose funcionários, mas claramente, cada um desses deve possuir visões e funcionalidadesdiferentes dentro do software. Foram definidos três tipos de usuários:


• Administrador: um usuário com visões ilimitadas dentro do sistema, responsávelpor cadastros, liberação de outros usuários e diversas operações de controle daplataforma;

• Professor: tem permissão para fazer marcação de horários, criar seu próprio login,visualizar todos horários ou filtrar os seus, além de cancelar um horário previamenteagendado. Apesar te ter esse nome, esse usuário pode ser utilizado por qualquerpessoa que deseje alocar horários e não só pelo corpo docente;

• Convidado: usuário que só tem permissão de leitura, ele consegue visualizar oquadro de horários, mas não consegue realizar uma marcação, pode até criar umlogin, mas ficará dependente da aprovação de um Administrador para subir seutipo de usuário para um Professor.

Qualquer pessoa que acessar o sistema é considerado um Convidado, e ele podecriar o seu próprio login e esperar que um Administrador mude o seu tipo de usuário,uma vez que isso seja feito, esse usuário ganha o status de Professor. Os usuários tidocomo administradores são definidos através de rotinas internas do sistema, ou através deoutro usuário do mesmo tipo.

É importante ressaltar que as funcionalidades dos usuários são acumulativas, ouseja, um nível de usuário agrega todas as funcionalidades dos níveis abaixo, para efeitode definição são considerados os seguintes níveis, do menor para o maior: Convidado,Professor e Administrador.

3.2.4 Funcionalidades

Para uma maior compreensão, segue a descrição de maneira mais minuciosa asfuncionalidades que cada tipo de usuário tem acesso, funcionalidades agregadas não foramrepetidas, uma vez que se sobe de nível, são herdadas as funcionalidades anteriores.

3.2.4.1 Administrador

A Tabela 2 descreve as funcionalidades de um Administrador.

3.2.4.2 Professor

A Tabela 3 descreve as funcionalidades de um Professor.

3.2.4.3 Convidado

A Tabela 4 descreve as funcionalidades de um Convidado.


Tabela 2 – Funcionalidades - Administrador

Funcionalidade Descrição

Liberar acesso de usuáriosPermite liberar o acesso ao ambientede marcação para os usuários, depoisque os mesmos já criaram o seu login.

Listar todos usuários Gera uma visualização de todos usuáriosda base de dados.

Alterar o tipo de usuárioMuda o tipo de um outro usuário, otornando um Administrador, Professor ouConvidado.

Adicionar novo recurso Adiciona informações de um novorecurso na base de dados

Editar recurso Permite editar as informaçõesde um recurso cadastrado.

Excluir recurso Permite excluir as informaçõesde um recurso cadastrado.

Inserir nova locação Permite adicionar uma nova locaçãopara qualquer usuário.

Excluir locação Permite excluir uma locação cadastrada.Fonte: Produzido pelo autor

Tabela 3 – Funcionalidades - Professor

Funcionalidade DescriçãoMarcar um horário Permite a marcação de um horário.

Acessar as suas marcações Permite visualizar todas marcações queo usuário possui no sistema.

Cancelar marcação Permite ao usuário cancelar uma marcação.Fonte: Produzido pelo autor

Tabela 4 – Funcionalidades - Convidado

Funcionalidade Descrição

Visualizar tabela de marcação Permite a visualização da tabela quecontém todas as marcações.

Registrar Permite ao usuário criar um login nabase de dados.


3.2.5 Casos de Uso

A criação de casos de uso é de grande auxílio para entender quais são os papéis decada ator dentro do funcionamento do sistema, com base nisso, foram criados os casosde uso do sistema, com o intuito de prover uma visualização mais clara do que cada atorpode ou não fazer. Todos os casos de uso se encontram nos Apêndices A, B e C. Para


efeito de definição, as palavras locação e marcação foram usadas com o mesmo significado,e ilustram uma alocação de recurso a um determinado usuário.

3.2.5.1 Diagramas de caso de uso

Vazquez e Simões (2016) afirmam que "O diagrama de caso de uso define de formagráfica quais funcionalidades do software atenderão a quais usuários específicos". A Figura3 apresenta o diagrama de casos de uso criado após a modelação dos mesmos.

Figura 3 – Diagrama de Casos de Uso


3.2.6 Mapa do Site

Com o intuito de demostrar graficamente as páginas do sistema que cada usuáriotem acesso, foram criados três mapas de site. Todos os mapas foram gerados no LucidChart1

1 https://www.lucidchart.com/


3.2.6.1 Administrador

A Figura 4 apresenta o mapa do site que é acessado pelo usuário Administrador.

Figura 4 – Mapa do site - Administrador


3.2.6.2 Professor

A Figura 5 apresenta o mapa do site que é acessado pelo usuário Professor.


Figura 5 – Mapa do site - Professor


3.2.6.3 Convidado

A Figura 6 apresenta o mapa do site que é acessado pelo usuário Convidado.

Figura 6 – Mapa do site - Convidado


3.3 Banco de DadosDepois de levantado todos os requisitos do sistema, foi elaborado o banco de dados

do mesmo, buscando atender todas as necessidades de cada tipo de usuário. A Figura7 apresenta o Modelo Entidade Relacionamento da base de dados, nas subseções que seseguem são explicadas cada entidade desse diagrama.


Figura 7 – Diagrama ER da base de dados


3.3.1 Recursos

Essa entidade representa os recursos que podem ser alocados pelos usuários, podendoser uma TV, uma sala de áudio, um projetor ou qualquer outra coisa que a instituiçãodisponibilize para utilização do seu corpo docente. Seus atributos são:

• id: identificador único de cada recurso;

• nome: representa o nome do recurso;

• descricao: uma descrição sobre o recurso, e do que dispõe;

• created_at: data de criação da tupla no banco de dados (padrão do framework);

• updated_at: data de atualização da tupla no banco de dados (padrão do fra-mework).

3.3.2 Users

Essa entidade representa os usuários do sistema. Seu nome e alguns de seus atributosestão em inglês por convenção do framework.

• id: identificador único de cada usuário;

• name: nome do usuário;

• email: e-mail que o usuário utiliza para fazer login, deve ser único para cada usuário;


• password: campo que armazena a senha do usuário de forma criptografada, comuso de um algoritmo interno do framework;

• remember_token: chave usada para recuperação de senha do usuário (padrão doframework);


• updated_at: data de atualização da tupla no banco de dados (padrão do fra-mework);

• tipo: define qual o tipo do usuário;

• acesso: define se o usuário possui o acesso liberado ou não para inserir uma novalocação.

3.3.3 Locacoes

Entidade que define uma alocação de um determinado recurso a um determinadousuário.

• id: identificador único de cada locação;

• idUser: identificador do usuário que realizou aquela locação (chave estrangeira);

• idRecurso: identificador do recurso alocado na locação (chave estrangeira);

• horario: determina a qual horário de aula essa locação se destina;

• data: específica a data da locação;

• turno: turno ao qual a locação foi agendada (matutino ou vespertino);


• updated_at: data de atualização da tupla no banco de dados (padrão do fra-mework);

3.4 Desenvolvimento do SistemaApós a criação do banco de dados, foi realizado o desenvolvimento do sistema

propriamente dito. Era preciso, prover operações de autenticação, operações Create, Read,Update and Delete (CRUD), visualização das locações e inserção de uma nova locação.Essas etapas seguem descritas de forma detalhada nas próximas subseções.


3.4.1 Autenticação

O sistema precisava prover uma maneira de criar novos usuários e garantir a elesum login, a primeira opção foi a de que todos os usuários deveriam ser criados por umAdministrador, impossibilitando que uma pessoa possa criar o seu próprio login nosistema, essa opção foi abandonada devido a alta carga de trabalho que seria gerada parao administrador do sistema. Foi optado por deixar o cadastro livre para qualquer usuáriodentro do sistema, mas com a restrição de que todo novo usuário começa com seu acessobloqueado, assim sendo, ele não possui acesso a inserção de uma nova locação enquanto oadministrador do sistema não liberar. Essa opção é bem menos custosa do que a primeira,em termos de carga de trabalho para o administrador do sistema.

O processo de autenticação usado no sistema foi o padrão fornecido pelo Laravel,que possui rotinas internas que garantem senhas criptografadas, e-mail’s únicos dentro dosistema além de inúmeras outras vantagens, essa solução foi avaliada como mais benéficado que uma implementação própria de autenticação, uma vez que o framework entregasoluções práticas, testadas e confiáveis.

3.4.2 Operações de CRUD

As operações de Create, Read, Update and Delete (CRUD) são exclusivas aosusuários do tipo Administrador, elas possibilitam a manipulação dos usuários, recursose locações, entidades estas que possuem representação no banco de dados como já definidona Seção 3.3.

As informações de cada entidade do sistema podem ser manipuladas através deformulários HTML, manipulações suportadas por models e controllers únicos de cadaentidade. A Figura 8 apresenta como exemplo o formulário de cadastro de um novo recurso.

As entidades do tipo usuário não apresentam operações do tipo create, por partedos administradores pelas razões explicadas em 3.4.1. Os recursos e locações apresentamtodas as operações de CRUD.


Figura 8 – Formulário de cadastro de um novo recurso


3.4.3 Alocação de Recursos

Essa é principal função do sistema, permite que um usuário que esteja autenticadono sistema realize a alocação de um determinado recurso em um determinado horário desua escolha, desde que o mesmo esteja livre.

Os recursos e horários são exibidos em uma tabela na home (Figura 9) do sistema,onde é sempre aberto a agenda com os horários do dia atual. Na tabela, os recursos sãorepresentados pelas colunas e os horários pelas linhas, os turnos matutino e vespertino sãorepresentados na mesma tabela.


Figura 9 – Tela inicial do sistema


Recursos que estejam disponíveis, apresentam um link com a palavra "Vazio"nalinha do horário vago, basta que o usuário clique nesse link para alocar aquele recursopara si, caso não esteja logado, o usuário será redirecionado a página de login (Figura 10).Uma vez que um determinado recurso esteja alocado, ele apresenta o nome do usuário nalinha correspondente ao horário (Figura 11).

3.4.4 Cancelar locação

Os usuários tem a opção de cancelar uma locação realizada por ele, para isso,necessita acessar o menu "Minhas marcações"(Figura 12), que fica disponível após realizaro login. Nesse menu o usuário visualiza uma tabela com todas as suas marcações que aindaestão ativas (data maior que data atual), cada linha representa uma marcação ainda ativa,ao final da linha existe um botão "Cancelar", que exclui aquela locação. Todo processodescrito pode ser visualizado na Figura 13.


Figura 10 – Tela de login do sistema


Figura 11 – Horário alocado para um usuário.


3.4.5 Visualizações

Outra operação de grande importância que o sistema deveria suportar é a visuali-zação da tabela de marcações, ela se localiza na home do sistema, o que não exige o loginpara sua consulta.

A tabela que é gerada na tela do home do sistema é baseada no dia atual, mas ousuário tem a opção de realizar uma busca por uma data específica, basta escolher umadata em um calendário suspenso, que a tabela da data escolhida será carregada. A Figura14 exemplifica esse processo.


Figura 12 – Menu "Minhas marcações".


Figura 13 – Opção de cancelar uma locação.


Figura 14 – Operação para filtrar a tabela de locações por data



3.5 VerificaçõesO teste de software é uma parte fundamental de qualquer processo de desenvol-

vimento, segundo Rios e Moreira (2006) "Teste de software é verificar se o software estáfazendo o que deveria fazer, de acordo com os seus requisitos". Não foram executadasrotinas de teses específicas mas com o intuito de verificar a adequação e a consistência dosistema, avaliações foram realizados em ambiente de desenvolvimento, a medida que novasfuncionalidades eram implementadas.

3.5.1 Validação

Durante a etapa de testes foi percebido que era necessária uma maneira de controlaro que o usuário poderia ou não inserir nos campos de todos os formulários, para minimizara emissão de erros e garantir a integridade da base de dados. Esse controle foi feito atravésdo uso do componente Select do HTML, que permite carregar uma lista com valorespré-determinados para a escolha do usuário, isso limita o escopo de escolhas que o usuáriopode fazer.

3.5.2 Acesso indevido

Quando um usuário está logado como Professor ele não possui acesso pelo sistemaà área exclusiva de um administrador, mas durantes os testes foi percebido que ele poderiaacessar essa página diretamente pela url, um erro gravíssimo do sistema. Para corrigirtal situação, foram incluídas rotinas que verificam qual o tipo do usuário logado antes deredirecioná-lo para qualquer página, caso um usuário tente acessar uma página que nãoseja pertinente a ele, uma mensagem de erro é exibida (Figura 15).

Figura 15 – Tentativa de acesso indevido bloqueada.



3.5.3 Tradução

Durante alguns testes, foi percebido que algumas mensagens de erros eram emitidasem inglês (padrão do framework), afim de se criar uma padronização, todas essas mensagensforam traduzidas para o português.

41

4 Resultados

4.1 Apresentação do SysAudio ao colégioApós o processo de desenvolvimento do sistema, foi realizada uma apresentação do

mesmo ao gerente de TI do colégio, com o intuito de apresentar as funcionalidades que osistema oferecia e suas possíveis contribuições para o processo de alocação de recursos dainstituição.

No encontro foram discutidas as motivações do desenvolvimento do sistema, bemcomo suas implicações dentro da instituição. Da parte do Colégio, foi admitido que oprocesso atual era arcaico, e que precisava de uma melhoria tecnológica, mas ao mesmotempo, houve um certo receio que seu corpo docente apresentasse uma certa resistênciaa aderir ao novo método, pois talvez, do ponto de vista deles, o processo atual nãoapresentava problemas.

Após o encontro, um período de teste ficou decidido, onde o sistema seria dispo-nibilizado na rede do Colégio, apenas para usuários conectados na mesma, durante essetempo, o setor de TI iria avaliar o quão produtivo era o sistema. Apesar dessa afirmativa,um período exato não foi definido, pois o setor de TI estava em processo de implementaçãode um outro software, tido como mais vital do que o SysAudio para os processos internosdo Colégio.

4.1.1 Sugestões de melhorias

Após reunião com o setor de TI do colégio, foram levantados pontos de melhorias enovos requisitos para o sistema, são eles:

• Limites de alocação: Implementar um limite de marcações que cada usuário podefazer por semana;

• Bloqueio de recursos: Os recursos são limitados aos usuários de acordo com o seusetor;

• Alertas: Um alerta é emitido aos administradores toda vez que um recurso é alocadopor um usuário.

42

5 Conclusão

Este trabalho apresentou o desenvolvimento de um sistema web, o SysAudio,trabalho que se mostrou extremamente desafiante. Toda teoria aprendida no decorrer docurso foi colocada em prática. No começo a tarefa parecia simples, mas com o decorrer dodesenvolvimento se mostrou bastante complexa, o que foi algo extremamente construtivoem termos de aprendizagem.

O uso do framework Laravel foi de grande ajuda no desenvolvimento do traba-lho, pois simplificou muitos processos que demandariam tempo e esforço para seremimplementados.

Os requisitos levantados e desenvolvidos durante o trabalho cumprem muito bem ademanda que o colégio possui, mas durante reunião com o setor de TI, após conclusãodo sistema, foram levantadas outras questões que talvez o sistema deveria cobrir. Essareunião com a gerência de TI, deveria ter sido realizada no começo do desenvolvimento, oque poderia ter produzido uma plataforma que cumprisse todos os requisitos que foramlevantados na reunião. Outra questão importante, é o fato de não terem sido feitos testesem ambiente de produção, ou seja, colocar o sistema para funcionar na prática, o que comcerteza pode levantar inúmeros outros requisitos.

A possível resistência do corpo docente citada no Capítulo 4.1, pode ser contornadaatravés de treinamentos dentro da plataforma, onde será exibido todas as vantagens que onovo sistema traz em comparação com a solução atual adotada pelo colégio.

Toda sociedade que está em torno de um estudante universitário deve ser beneficiadade alguma forma, pois de maneira direta ou indireta, é essa sociedade que sustenta oensino desse estudante, essa foi a ideia percussora desse projeto, perceber uma necessidadeda sociedade e tentar criar uma solução.

Espera-se que o SysAudio possa continuar evoluindo e superando suas possíveisfalhas, a ideia é que ele seja utilizado plenamente pelo colégio e evolua junto com asnecessidades da instituição, alem de cobrir todas as sugestões de melhorias propostas noCapítulo 4.1.

43

Referências

BOOTSTRAP Logo. 2018. Fuzati. Disponível em: <https://fuzati.com/technology/bootstrap-logo/>. Acesso em: 05 jun 2018. Citado na página 23.

COMEçANDO com Laravel. 2017. Medium. Disponível em: <https://medium.com/@marcelgsantos/come%C3%A7ando-com-laravel-parte-01-e76567408b1f>. Acesso em: 05jun 2018. Citado na página 22.

FILHO, W. de P. P. Engenharia de software. [S.l.]: LTC, 2003. v. 2. Citado na página 19.

LAUDON, J. L. K. Sistemas de informação gerenciais. [S.l.]: Pearson, 2011. Citado 2vezes nas páginas 19 e 20.

MCCOOL, S. Laravel Starter. [S.l.]: Packt Publishing Ltd, 2012. Citado na página 22.

PESQUISA sobre o uso das Tecnologias de Informação e Comunicação no Brasil - TICEducação 2016. 2017. CETIC.br. Disponível em: <http://www.cetic.br/publicacoes/indice/pesquisas>. Acesso em: 12 jul 2018. Citado na página 16.

PRESSMAN, R. S. Engenharia de software. [S.l.]: Makron books São Paulo, 1995. v. 6.Citado na página 20.

RIOS, E.; MOREIRA, T. Teste de software. [S.l.]: Alta Books Editora, 2006. Citado napágina 39.

ROSA, P. R. da S. O uso dos recursos audiovisuais e o ensino de ciências. CadernoBrasileiro de Ensino de Física, v. 17, n. 1, p. 33–49, 2000. Citado na página 16.

SILBERSCHATZ, A.; KORTH, H.; SUNDARSHAN, S. Sistema de banco de dados. [S.l.]:Elsevier Brasil, 2016. Citado na página 23.

SOMMERVILLE, I. Engenharia de Software. [S.l.]: Pearson Addison, 2007. Citado 4vezes nas páginas 19, 20, 25 e 26.

VAZQUEZ, C. E.; SIMÕES, G. S. Engenharia de Requisitos: software orientado aonegócio. [S.l.]: Brasport, 2016. Citado na página 29.

WIRFS-BROCK, R. J.; JOHNSON, R. E. Surveying current research in object-orienteddesign. Communications of the ACM, ACM, v. 33, n. 9, p. 104–124, 1990. Citado napágina 21.

https://fuzati.com/technology/bootstrap-logo/

https://fuzati.com/technology/bootstrap-logo/

https://medium.com/@marcelgsantos/come%C3%A7ando-com-laravel- parte-01-e76567408b1f

https://medium.com/@marcelgsantos/come%C3%A7ando-com-laravel- parte-01-e76567408b1f

http://www.cetic.br/publicacoes/indice/pesquisas

http://www.cetic.br/publicacoes/indice/pesquisas

Apêndices

45

APÊNDICE A – Casos de Uso - Convidado

A.1 Caso de Uso I - Registro

Ator primário: Convidado.Objetivo: Criar um login no sistema.Pré-condições: Acessar o sistema.Garantias de sucesso:

1. Convidado insere um e-mail e uma senha.

2. Convidado é registrado com sucesso.

3. Convidado é redirecionado a página inicial.

Cenário:

1. Convidado: acessa o SysAudio;

2. Convidado: clica em registro;

3. Convidado: preenche os campos necessários;

4. Convidado: confirma o seu cadastro;

5. Convidado: é redirecionado a página inicial;

Exceções:

1. Inserir e-mail com formato inválido: mensagem de erro é exibida ao convidado;

2. Inserir e-mail já cadastrado: mensagem de erro é exibida ao convidado;

A.2 Caso de Uso II - Visualizar Marcações Gerais

Ator primário: Convidado.Objetivo: Visualizar todas as marcações registradas no sistema.Pré-condições: Acessar o sistema.Garantias de sucesso:

APÊNDICE A. Casos de Uso - Convidado 46

1. Convidado acessa o sistema.

2. Convidado visualiza todas as marcações.

Cenário:

1. Convidado: acessa o SysAudio;

2. Convidado: visualiza a tabela de registros do dia atual;

Exceções:

1. Sistema fora do ar: entrar em contato com a instituição;

47

APÊNDICE B – Casos de Uso - Professor

B.1 Caso de Uso I - Inserir Marcação

Ator primário: Professor.Objetivo: Inserir uma nova marcação no sistema.Pré-condições: Estar logado.Garantias de sucesso:

1. Professor clica em um horário livre.

2. Professor tem marcação registrada.

3. Professor recebe mensagem de sucesso.

Cenário:

1. Professor: acessa o SysAudio;

2. Professor: realiza o seu login.

3. Professor: clica em um horário vago.

4. Professor: é redirecionado a página inicial, com mensagem de sucesso.

Exceções:

1. Escolher horário livre sem estar logado: Professor é direcionado a página de login;

2. Escolher horário sem estar com o acesso liberado: mensagem é exibida, solicitando ocontato com um Administrador;

B.2 Caso de Uso II - Visualizar Marcações Próprias

Ator primário: Professor.Objetivo: Visualizar suas próprias marcações registradas no sistema.Pré-condições: Estar logado.Garantias de sucesso:

1. Professor clica em minhas marcações.

APÊNDICE B. Casos de Uso - Professor 48

2. Professor visualiza uma lista de todas as suas marcações.

Cenário:



3. Professor: clica em minhas marcações.

4. Professor: visualiza todas as suas marcações.

Exceções:

1. Área minhas marcações não disponível: usuário precisa realizar login.

B.3 Caso de Uso III - Cancelar Marcação

Ator primário: Professor.Objetivo: Cancelar uma marcação registrada no sistema.Pré-condições: Estar logado.Garantias de sucesso:

1. Professor clica em minhas marcações.

2. Professor visualiza uma lista com todas as sua marcações.

3. Professor clica em cancelar na marcação que deseja remover.

Cenário:



3. Professor: clica em minhas marcações.

4. Professor: visualiza todas as suas marcações

5. Professor: escolhe uma marcação para cancelar.

Exceções:

1. Área minhas marcações não disponível: usuário precisa realizar login.

APÊNDICE B. Casos de Uso - Professor 49

2. Marcação que deseja cancelar não disponível na lista: a marcação é de uma datamais antiga.

50

APÊNDICE C – Casos de Uso -Administrador

C.1 Caso de Uso I - Liberar Acesso Usuário

Ator primário: Administrador.Objetivo: Liberar o acesso de um outro usuário.Pré-condições: Estar logado como Administrador.Garantias de sucesso:

1. Administrador clica em área administrativa.

2. Administrador clica em liberar acesso de usuário.

3. Administrador visualiza uma lista com todos os usuários.

4. Administrador escolhe o usuário que deseja liberar o acesso.

Cenário:

1. Administrador: acessa o SysAudio;

2. Administrador: realiza o seu login.

3. Administrador: clica em área administrativa.

4. Administrador: visualiza as opções administrativas do sistema.

5. Administrador: clica em liberar acesso de usuário.

6. Administrador: escolhe um usuário para liberar o acesso.

Exceções:

1. Área administrativa não disponível: usuário precisa realizar login comoAdministrador.

2. Usuário que deseja liberar o acesso não listado: usuário não cadastrado na base dedados.

APÊNDICE C. Casos de Uso - Administrador 51

C.2 Caso de Uso II - Adicionar Recurso

Ator primário: Administrador.Objetivo: Adicionar um novo recurso na base de dados.Pré-condições: Estar logado como Administrador.Garantias de sucesso:


2. Administrador clica em adicionar novo recurso.

3. Administrador acessa o formulário de um novo recurso.

4. Administrador preenche o formulário com todas informações necessárias.

5. Administrador salva o novo recurso.

Cenário:





5. Administrador: clica em adicionar novo recurso.

6. Administrador: preenche e salva os dados do novo recurso.

Exceções:


2. Mensagem de dados incompletos: todos os campos obrigatórios devem serpreenchidos.

C.3 Caso de Uso III - Listar Usuários

Ator primário: Administrador.Objetivo: Visualizar todos os usuários da base de dados.Pré-condições: Estar logado como Administrador.Garantias de sucesso:



2. Administrador clica em listar usuários.

3. Administrador visualiza uma lista com todos os usuários registados na base dedados.

Cenário:





5. Administrador: clica em listar usuários.

Exceções:


C.4 Caso de Uso IV - Inserir Marcação

Ator primário: Administrador.Objetivo: Adicionar uma marcação a um usuário específico.Pré-condições: Estar logado como Administrador.Garantias de sucesso:


2. Administrador clica em inserir nova locação.

3. Administrador preenche o formulário com todas informações necessárias.

4. Administrador salva a nova marcação.

Cenário:






5. Administrador: clica em inserir nova locação.

6. Administrador: preenche e salva os dados da nova marcação.

Exceções:



C.5 Caso de Uso V - Editar/Excluir Recurso

Ator primário: Administrador.Objetivo: Fazer a edição ou exclusão de um recurso.Pré-condições: Estar logado como Administrador.Garantias de sucesso:


2. Administrador clica em editar/excluir recurso.

3. Administrador visualiza uma lista com todos os recursos.

4. Administrador escolhe entre editar ou excluir o recurso.

5. Administrador edita os dados quando necessário.

6. Administrador salva as edições feitas.

Cenário:






5. Administrador: clica em editar/excluir recurso.

6. Administrador: preenche e salva os dados modificados.

Exceções:



C.6 Caso de Uso VI - Alterar Tipo do Usuário

Ator primário: Administrador.Objetivo: Mudar o tipo de um usuário.Pré-condições: Estar logado como Administrador.Garantias de sucesso:


2. Administrador clica em alterar o tipo de um usuário.

3. Administrador visualiza uma lista com todos os usuários.

4. Administrador escolhe o usuário que alterar o seu tipo.

Cenário:





5. Administrador: clica em alterar o tipo de um usuário.

6. Administrador: altera o tipo de um usuário.

Exceções:



C.7 Caso de Uso VII - Excluir Locação

Ator primário: Administrador.Objetivo: Excluir uma locação da base de dados.Pré-condições: Estar logado como Administrador.Garantias de sucesso:


2. Administrador clica em excluir locação.

3. Administrador visualiza uma lista com todas as locações.

4. Administrador escolhe a locação que deseja excluir.

Cenário:





5. Administrador: clica em excluir locação.

6. Administrador: excluir uma locação.

Exceções:


UNIVERSIDADE FEDERAL DE OURO PRETO INSTITUTO DE CIÊNCIAS EXATAS E APLICADAS

COLEGIADO DO CURSO DE SISTEMAS DE INFORMAÇÃO

Rua Trinta e seis, 115 – Bairro Loanda – CEP 35931-008 – João Monlevade – MG – Brasil http://www.icea.ufop.br – [email protected] – (31) 3852-8709

DECLARAÇÃO DE CONFORMIDADE

Certifico que o(a) aluno(a) Cayque Domingues dos Santos, autor do trabalho de

conclusão de curso intitulado “Desenvolvimento de um Sistema de Controle de Recursos

Audiovisuais em uma Escola”efetuou as correções sugeridas pela banca examinadora eque

estou de acordo com a versão final do trabalho.

João Monlevade, 17 de Julho de 2018.

______________________________________

Professor (a) Orientador (a)

desenvolvimentodeumsistemade ...monografias.ufop.br/bitstream/35400000/1094/1/monografia... ·...

Documents