Portfólio - 2º Período ADS UNOPAR - Zer@Dengue

Prévia do material em texto

Universidade Norte do Paraná - UNOPAR – Polo Betim II 
 
Curso Superior de Tecnologia em Análise e Desenvolvimento de 
Sistemas 
 
 
GABRIEL CARVALHO BAHIA RIBEIRO – 2418123901 
GESSICA FERNANDA SIQUEIRA DA SILVA- 2418699001 
WILLIAN JORGE DE JESUS CORREA - 2310979801 
 
 
 
 
PRODUÇÃO TEXTUAL INTERDISCIPLINAR 
 
 
 
 
 
 
Disciplinas Norteadoras: 
Análise Orientada a Objetos I 
Banco de Dados I 
Organização de Computadores 
Linguagens de Programação e Estrutura de 
Dados 
 
 
 
Tutor (a) EAD: TIAGO BARROSO DOS SANTOS 
 
BETIM / MG 2020 
 
 
PRODUÇÃO TEXTUAL INTERDISCIPLINAR 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Trabalho de portfólio apresentado como 
requisito parcial para a obtenção de média 
semestral. 
 
Orientadora: Tiago Barroso 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
BETIM / MG 2020 
 
 
 
 
 
 
 
 
SUMÁRIO 
 
 
 
1 INTRODUÇÃO ......................................................................................................... 3 
2 DESENVOLVIMENTO ............................................................................................. 4 
2.1 TAREFA 1: MODELAGEM ................................................................................ 4 
2.1.1 DIAGRAMA DE USE CASE ......................................................................... 4 
2.1.2 DOCUMENTAÇÃO USE CASE ................................................................... 5 
2.1.3 DIAGRAMA DE CLASSE............................................................................. 8 
2.2 TAREFA 2: REQUISITOS E MER ..................................................................... 9 
2.2.1 LEVANTAMENTO DE REQUISITOS ........................................................ 10 
2.2.2 MODELO ENTIDADE RELACIONAMENTO .............................................. 12 
2.3 ARQUITETURA E ORGANIZAÇÃO DE COMPUTADORES .......................... 13 
2.4 ESTRUTURA DE DADOS ............................................................................... 14 
3 CONCLUSÃO ........................................................................................................ 16 
 
 
3 
1 INTRODUÇÃO 
 
A dengue é uma doença cada dia mais presente no nosso dia-a-dia, mesmo 
tendo todas as informações de como evitar o seu transmissor, o mosquito AEDES 
AEGYPTI. Uma dessas formas de prevenção, é evitar água parada e focos onde o 
mosquito pode se proliferar. 
 
Pensando nisso, foi criado um projeto para o Ministério da Saúde, chamado 
Sistema Zer@Dengue, no qual qualquer pessoa poderá fazer uma denúncia de 
possíveis focos de dengue em todo território nacional. Bastará acessar o sistema, 
criar uma conta e fazer um descritivo do problema, indicando o endereço da 
ocorrência, inclusive podendo enviar fotos, sendo que, posteriormente o usuário 
receberá um relato da ação tomada pelo Ministério da Saúde. 
 
Para isso, desenvolveremos e abordaremos nesse trabalho, a modelagem da 
análise do sistema na ferramenta case LUCIDCHART, usando o diagrama de Use 
Case, documentação desses Use Cases e o Diagrama de classes. Além disso, 
iremos realizar uma análise de requisitos inicial para o tipo de informação que será 
armazenada no baco de dados, criando um modelo de Entidade-Relacionamento 
(MER) através da ferramenta BRMODELO. 
 
Sugeriremos os computadores e configurações necessárias para os 
equipamentos que serão utilizados nesse projeto, tais como o tipo de processador, 
memória RAM, disco rígido etc. E proporemos uma estrutura de dados que trará o 
conceito e a compreensão de como os dados devem ser armazenados e 
recuperados, prevendo uma solução para que a Equipe de Vistoria Zer@Dengue 
efetue suas visitas aos locais suspeitos de foco do mosquito de forma otimizada. 
 
Ao longo deste trabalho, abordaremos os métodos realizados e as questões 
propostas pelo portfólio em seu detalhe, explanando mais sobre os conteúdos 
estudados durante esse semestre. 
 
 
 
4 
2 DESENVOLVIMENTO 
Nesse portfólio, abordaremos 4 questões: Análise orientada a objetos, Banco 
de dados, Arquitetura e organização de computadores e Estrutura de dados. 
Para realização dessas tarefas, buscamos conhecimento além do estudado 
em sala de aula, para idealizarmos o projeto que de fato pudesse atender as 
necessidades do sistema. 
Nos tópicos abaixo, respondemos as tarefas solicitadas pelos professores, no 
arquivo PTG presente no AVA. 
2.1 TAREFA 1 - MODELAGEM 
Elaboramos a modelagem da atividade de Análise de Sistemas em uma 
ferramenta CASE chamada LUCIDCHART que contempla a Unified Modeling 
Language (UML). 
Consideramos que a solução deverá abranger as funcionalidades para 
realização do cadastro da pessoa física que faz a denúncia, cadastro da localização 
(estado, cidade e bairro), cadastro da denúncia e consulta de acompanhamento do 
status da denúncia. 
 2.1.1 DIAGRAMA DE USE CASE 
O Diagrama de Casos de Uso representa as funcionalidades do sistema 
(requisitos funcionais do sistema) e os elementos externos ao sistema que interagem 
com ele. É um diagrama abstrato e flexível com poucos elementos de notação, que 
representa a interação entre os elementos Ator e Casos de Uso, indicando os 
serviços ou funcionalidades que o sistema disponibiliza para os usuários. 
Para realização desse diagrama, utilizamos a ferramenta Lucidchart, 
demonstrando as interações necessárias para o sistema. 
 
 
 
 
 
5 
• Diagrama de Use Case: 
 
 
 
 
 
 
 
 
 
 
 
Figura 01: Diagrama de Use case 
 2.1.2 DOCUMENTAÇÃO USE CASE 
 
Nome Login 
Atores Usuário, Funcionário 
Resumo Fazer login com e-mail e senha já cadastrados. 
Pré-Condições Realizar cadastro 
Pró-Condições Informações serem compatíveis a que foram cadastrados 
anteriormente 
Fluxo Principal 
Ações do ator Ações do sistema 
1 Informar e-mail e 
senha 
2 Conferir com o banco de dados 
 
 
6 
 
3 Realizar login 
Fluxo Alternativo 1 
1 Realizar cadastro 2 Armazenar no banco de dados email e senha 
Fluxo Alternativo 2 
Dados errados Informar ao usuário para digitar novamente email e senha ou 
mudar a senha 
 
 
Nome Cadastrar Usuário 
Atores Pessoa 
Resumo Cadastrar no sistema com e-mail e senha 
Pré-Condições Nenhuma 
Pró-Condições Nenhuma 
Fluxo Principal 
Ações do ator Ações do sistema 
1 Fornecer e-mail e senha 2 Armazenar email e senha 
 
3 Verificar se os dados já foram cadastrados 
Fluxo Alternativo 1 
 
1 Dados cadastrados anteriormente 
 
2 Informar ao usuário a fazer login 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
7 
 
 
Nome Fazer denúncia 
Atores Usuário 
Resumo Fazer uma denúncia de focos de dengue em qualquer lugar do Brasil. 
Pré-Condições Nenhuma 
Pró-Condições Nenhuma 
Fluxo Principal 
Ações do ator Ações do sistema 
Registrar 
denúncia 
Registar denúncia 
 
1 Comparar se as informações já foram 
cadastradas anteriormente 
 
2 Verificar se os dados existem 
 
3 Repassar aos funcionários. 
Fluxo Alternativo 1 
 
1 Se houver uma denúncia igual, informar ao usuário que já existe uma 
denúncia ao local identificado. 
Fluxo Alternativo 1 
 
1 Se dados forem inexistentes não repassar aos funcionários. 
 
2 Bloquear por 24 horas o usuário de fazer denúncias. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
8 
 
 
 
Nome Verificar foco 
Atores Funcionário 
Resumo Ir verificar o local do foco 
Pré-Condições O sistema já ter verificado a denúncia 
Pró-Condições 
 
Fluxo Principal 
Ações do ator Ações do Sistema 
1 Ir até do local e acabar com o foco 2 Informar o sistema se foi resolvido o foco. 
 
Nome Informar o extermínio 
Atores Funcionário 
Resumo Informar ao sistema se o foco foi 
resolvido 
Pré-Condições 
 
Pró-Condições 
 
Fluxo Principal 
 
1 Registrar se a denúncia foi resolvida 
 
2 Informar ao usuário da solução 
Fluxo Alternativo 1 
1 Se não for possível resolver a denúncia 3 Armazenar o relatório e fotos 
2 Fazer um relatório e tirar fotos do local sepossível 
 
 
 2.1.2 DIAGRAMA DE CLASSE 
De acordo com Guedes (2007), o diagrama de classes é o mais utilizado 
entre os diagramas UML. Dentre seus principais objetivos, pode-se citar como 
 
 
9 
principal, a visualização das classes utilizadas pelo sistema e como é o 
relacionamento entre si. O diagrama de classes possui uma visão estática, a qual é 
representada por classes organizadas e com uma estrutura lógica definida. Ao 
modelar esse diagrama, cada classe é abstraída com a sua lista de atributos e 
métodos. 
Esse diagrama representa a definição dos recursos essenciais para a 
operação do sistema. Por recursos, entende-se que representam pessoas, materiais, 
informações e comportamentos. 
Para realização desse diagrama, utilizamos a ferramenta Lucidchart, 
identificando 3 classes com seus devidos atributos e métodos. 
• Diagrama de Classe: 
 
 
 
 
 
 
 
 
Imagem 02: Diagrama de Classe 
2.2 TAREFA 2 – REQUISITOS E MER 
Segundo os autores Navathe e Elmasri, o “Modelo Entidade Relacionamento 
(MER), é um modelo de dados conceitual de alto nível, além de muito popular”, 
NAVATHE e ELMASRI (2005, p. 35). 
 
 
10 
A técnica de modelagem diz que devemos pegar o cenário dos dados que 
serão informatizados e nele identificar as entidades, os atributos das entidades e os 
relacionamentos entre as entidades. 
Este cenário do mundo real deve ser descrito na forma de um texto, 
apresentando tudo que o analista identificar. Após realizar esta etapa, tudo isto 
deverá ser expresso através de um DER (diagrama entidade relacionamento) que é 
a forma de apresentar os componentes identificados dentro de um diagrama. 
 2.2.1 LEVANTAMENTO DE REQUISITOS 
Para o Zer@Dengue, teremos três entidades, Usuário, Ocorrencia e Imagens, 
onde estão abertos os atributos de cada uma delas. 
Na entidade Usuário, temos 15 atributos, onde o ID login usuário é a chave 
primaria (atributo identificador) e o endereço é um atributo composto, essa entidade 
se relaciona com a entidade Ocorrência, que possui 13 atributos, sendo o Protocolo 
a chave principal (atributo identificador), sendo o endereço_ocorrencia um atributo 
composto, a entidade se relaciona com Imagens, que possui 2 atributos, sendo 
ID_imagem a chave principal (atributo identificador). 
Sobre os relacionamentos, a entidade Usuário pode realizar 0 ou várias 
ocorrências, e uma ocorrência tem apenas 1 usuário. Uma ocorrência pode ter 0 ou 
várias imagens, mas uma imagem tem que corresponder a uma ocorrência. 
 
 
 
 
 
 
 
 
 
11 
 
• MER: Modelo Conceitual 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Imagem 03: MER modelo conceitual 
 
 
 
 
 
 
 
 
 
 
 
 
 
12 
2.2.2 MODELO ENTIDADE-RELACIONAMENTO 
 
• MER: Modelo Logico 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Imagem 04: MER modelo Lógico 
Abaixo o script para criação das tabelas no banco de dados. 
CREATE TABLE Usuario ( 
ID Login Usuario Int PRIMARY KEY, 
Tipo_Usuario Varchar(10), 
E-mail Varchar(50), 
Nome Varchar(50), 
Telefone Numeric, 
Rua Varchar(20), 
Numero Varchar(10), 
Bairro Varchar(20), 
Cidade Varchar(20), 
UF Varchar(2), 
CEP Varchar(8), 
CPF Numeric, 
Senha Varchar(8), 
Login Varchar(50) 
) 
 
 
13 
 
2.3 ARQUITETURA E ORGANIZAÇÃO DE COMPUTADORES 
Para as configurações de um computador para o sistema Zer@Dengue 
indicaremos configurações de computadores que possam ser capazes de manter o 
sistema com bom desempenho e com bom custo/benefício para a organização. 
 
Placa mãe: Gigabyte H310M-S2H 
 
Processador: Intel(R) Core(TM) i5-8250 CPU @ 1.600GHz 1.80GHz 
 
Memória RAM: 8GB, 2666MHz, DDR4 
 
Disco Rígido: Seagate Iron Wolf NAS 4tb 3,5 
 
CREATE TABLE Ocorrencia ( 
Protocolo Varchar(10) PRIMARY KEY, 
Id_solicitante Int, 
Rua_Ocorrencia Varchar(20), 
Numero_ocorrencia Varchar(10), 
Bairro_Ocorrencia Varchar(20), 
Cidade_Ocorrencia Varchar(20), 
UF_Ocorrencia Varchar(2), 
Descricao_Ocorrencia Varchar(500), 
ID_avaliador Int, 
Descricao_avaliacao Varchar(500), 
Data_ocorrencia Datetime, 
Data_avaliacao Datetime, 
Descricao_avaliacao Varchar(500), 
FOREIGN KEY(Id_solicitante) REFERENCES Usuario (ID Login Usuario), 
FOREIGN KEY(ID_avaliador) REFERENCES Usuario (ID Login Usuario) 
) 
 
CREATE TABLE Imagens ( 
Protocolo Varchar(10), 
Imagem Image, 
ID_Imagem Número(4) PRIMARY KEY, 
FOREIGN KEY(Protocolo) REFERENCES Ocorrencia (Protocolo) 
) 
 
 
 
 
 
14 
Teclado: Microsoft WIRED 600 Multimídia ABNT2 
 
Mouse: Microsoft Scrool P5800061 
 
Monitor: 19” não importando a marca 
 
Placa de Vídeo: GeForce GTX 1650 
 
Um computador com essas configurações, tem um custo médio de R$4.000,00. 
 
 
2.4 ESTRUTURA DE DADOS 
 
A condução do desenvolvimento por listas, tem variáveis entre Lista Lineares 
e Encadeadas, basicamente o desenvolvimento é parecido, porém cada uma tem a 
sua particularidade. 
As Listas Lineares, escolhida para realizar a programação do roteiro, impõe-
se que os itens listados necessariamente precisam estar ordenados de forma 
sequencial, mas nem sempre precisam estar ordenados de forma física ou 
exemplar. 
Seguindo a ordem cronológica, o diagrama representado, tem a ordem 
sequencial, no qual para efetuar as visitas, o programa Zer@Dengue, precisa dos 
requisitos citados, e que propositalmente não se encontram na ordem a serem 
realizados. 
Passando pela planilha de visitas, o encarregado por destinar as visitas irá 
selecionar o estado desejado, a cidade desejada, e indo até a região desejada, ao 
fazer essa seleção, ele irá encontrar as equipes formadas, e cada um dos grupos de 
agentes, responsável por sua região. 
Como exemplo, vamos supor que o estado selecionado seja Minas Gerais, a 
cidade Betim e a região Leste, ele irá encaminhar o grupo disponível para a região, 
encaminhando-os para a visita que se encontra com horário e data agendada em 
seu respectivo endereço, identificando-se com crachás nomeados. 
 
 
 
 
15 
• Diagrama de Visitas: 
 
 
 
 
 
 
 
 
 
 
 
Imagem 05: Diagrama Visitas 
 
 
 
 
16 
3 CONCLUSÃO 
 
Através desse trabalho, conseguimos praticar os conteúdos aprendidos nas 
aulas e nos livros, para desenvolver um projeto eficaz e prático com o objetivo de 
obter melhor funcionamento da ferramenta do projeto. 
Desenvolvemos e abordamos a modelagem da análise do sistema em 
ferramentas especificas, usando o diagrama de Use Case, documentação desses 
Use Cases e o Diagrama de classes. 
Nos aprofundamos na análise de requisitos inicial para o tipo de informação 
que seria armazenada no baco de dados, criando um modelo de Entidade-
Relacionamento (MER) através da ferramentas especificas e nas configurações e 
características melhores para que o sistema seja trabalhado, e atenda o usuário 
final. 
 Dessa forma, conseguimos aprofundar ainda mais nossos estudos com a 
busca de outras bibliografias para complementar o conhecimento necessário para 
esse trabalho, além de efetuar a prática nas ferramentas especificas para as 
atividades propostas. 
 
 
17 
REFERÊNCIAS 
FERRARETO, Leonardo; NISHIMURA, Roberto. Banco de dados I. Londrina: 
Editora e Distribuidora Educacional S.A., 2018. 
TANGON, Leonardo; SANTOS, Rogerio. Arquitetura e organização de 
computadores. Londrina: Editora e Distribuidora Educacional S.A., 2016. 
GOMES, Polyanna; MORAIS, Everson; HISATOMI, Marco. Análise orientada a 
objetos I. Londrina: Editora e Distribuidora Educacional S.A., 2018. 
SANTANA, Gisele; SILVA, Nathalia; MOZER, Merris. Linguagens de programação 
e estruturas de dados. Londrina: Editora e Distribuidora Educacional S.A., 2018. 
UNIVERSIDADE FEDERAL DO PARANÁ. Biblioteca Central. Normas para 
apresentação de trabalhos. 2. ed. Curitiba: UFPR, 1992. v. 2.