Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL FLUMINENSE
IGOR ALEX AMORIM MARTINS LAMEIRÃO
E-CIDADÃO – SISTEMA DE COMUNICAÇÃO ENTRE CIDADÃOS E
ENTES PÚBLICOS
Niterói
2018
IGOR ALEX AMORIM MARTINS LAMEIRÃO
E-CIDADÃO – SISTEMA DE COMUNICAÇÃO ENTRE CIDADÃOS E
ENTES PÚBLICOS
Trabalho de Conclusão de Curso subme-
tido ao Curso de Tecnologia em Siste-
mas de Computação da Universidade
Federal Fluminense como requisito par-
cial para obtenção do título de Tecnólo-
go em Sistemas de Computação.
Orientadora:
Helga Dolorico Balbi
NITERÓI
2018
IGOR ALEX AMORIM MARTINS LAMEIRÃO
e-CIDADÃO
SISTEMA DE COMUNICAÇÃO ENTRE CIDADÃOS E ENTES PÚBLI-
COS
Trabalho de Conclusão de Curso subme-
tido ao Curso de Tecnologia em Siste-
mas de Computação da Universidade
Federal Fluminense como requisito par-
cial para obtenção do título de Tecnólo-
go em Sistemas de Computação.
Niterói, 19 de junho de 2018.
Banca Examinadora:
_________________________________________
Profa. Helga Dolorico Balbi, Msc. – Orientadora
UFF – Universidade Federal Fluminense
_________________________________________
Prof. Douglas Paulo de Mattos – Avaliador
UFF – Universidade Federal Fluminense
AGRADECIMENTOS
A Deus, que sempre iluminou a minha cami-
nhada.
A minha Orientadora Helga Dolorico Balbi pe-
lo estímulo e atenção que me concedeu du-
rante o curso.
Aos Colegas de curso pelo incentivo e troca
de experiências.
A todos os meus familiares e amigos pelo
apoio e colaboração.
RESUMO
O Brasil vem passando por um momento de ausência dos governantes, em que as solicitações dos cidadãos e suas mazelas são esquecidas ou simplesmente ignora-das por aqueles que deveriam cuidar-lhes. Tendo este problema em vista, este sis-tema tem por objetivo auxiliar cidadãos e governantes na manutenção de equipa-mentos públicos. Com um simples cadastro, o cidadão torna-se um e-Cidadão, o que o habilita a informar aos entes públicos os problemas encontrados sob a responsabi-lidade destes. Por parte do ente público, a partir também de um simples cadastro, este se habilita e se compromete em observar e responder aos problemas relatados pelos e-Cidadãos. O principal benefício do sistema é a transparência, que permite que os cidadãos obtenham visibilidade do que os governantes fazem com o erário público e com seus desejos e necessidades. Através do sistema, os governantes prestam os serviços e contas aos seus cidadãos.
Palavras-chaves: cidadão, governantes, erário público, solicitações, equipa-
mento público, relatos e transparência.
ABSTRACT
Brazil has been passing through a moment of absence of the rulers, in which the re-quests of citizens and their ills are forgotten or simply ignored by who should care for them. This system aims at assisting citizens and government officials in the mainte-nance of public facilities. With a simple registration, the citizen becomes an e-Cidadão, and this enables him to inform the public entities of the problems encoun-tered under his responsibility. The public entity, also after following a simple registra-tion process, qualifies and undertakes to observe and respond to the problems re-ported by e-Cidadãos.
Key words: citizens, government officials, public treasury, requests, public
equipment, reports and transparency.
LISTA DE ILUSTRAÇÕES
Figura 1: Diagrama de casos de uso ......................................................................... 22
Figura 2: Diagrama de Classes ................................................................................. 48
Figura 3: Diagrama de Entidade e Relacionamento .................................................. 49
Figura 4: Diagrama de Estado ................................................................................... 50
Figura 5: Diagrama de Sequencia (Categoria) .......................................................... 51
Figura 6: Diagrama de Sequencia (Status) ............................................................... 52
Figura 7: Diagrama de Sequencia (Estado) .............................................................. 53
Figura 8: Diagrama de Sequencia (Histórico de Relato) ........................................... 54
Figura 9: Diagrama de Sequencia (Município) .......................................................... 55
Figura 10: Diagrama de Sequencia (Relato) ............................................................. 56
Figura 11: Diagrama de Sequencia (Pessoa)............................................................ 57
Figura 12: Tela de Login ........................................................................................... 59
Figura 13: Tela Menu de Opções .............................................................................. 60
Figura 14: Tela de inclusão de categoria .................................................................. 61
Figura 15: Tela de confirmação ................................................................................. 61
Figura 16: Tela de Registro gravado com sucesso ................................................... 61
Figura 17: Tela de Erro de Gravação ........................................................................ 62
Figura 18: Edição de Categoria ................................................................................. 62
Figura 19: Confirmação de Exclusão ........................................................................ 62
Figura 20: Exclusão com Sucesso ............................................................................ 63
Figura 21: Tela de erro de exclusão .......................................................................... 63
Figura 22: Tela de lista de estados ........................................................................... 64
Figura 23: Tela de inclusão (cadastrar) de Estado .................................................... 64
Figura 24: Tela de edição de estado ......................................................................... 64
Figura 25: Tela de lista de municípios ....................................................................... 65
Figura 26: Tela de inclusão (cadastro) de município ................................................. 65
Figura 27: Tela de edição de município .................................................................... 66
Figura 28: Tela de lista de cidadãos .......................................................................... 66
Figura 29: Tela de inclusão (cadastro) de cidadão .................................................... 67
Figura 30: Tela de edição de cidadão ....................................................................... 67
Figura 31: Tela de lista de responsável ..................................................................... 68
Figura 32: Tela de inclusão (cadastro) de responsável ............................................. 68
Figura 33: Tela de edição de responsável ................................................................ 69
Figura 34: Tela de Lista de status ............................................................................. 69
Figura 35: Tela de inclusão (cadastro) de status ....................................................... 70
Figura 36: Tela de edição de status .......................................................................... 70
Figura 37: Tela de lista de relato ............................................................................... 71
Figura 38: Tela de inclusão de relato ........................................................................ 72
Figura 39: Tela de edição de relato ........................................................................... 73
Figura 40: Tela de lista de histórico de relato ............................................................ 74
LISTA DE ABREVIATURAS E SIGLAS
RF<Número>- Requisito Funcional.
RNF<Número>- Requisito não Funcional.
SGBD- Sistema de gerenciamento de banco de dados.
SQL – Structured Query Language (Linguagem de Consulta Estruturada)
IDE – Ambiente de desenvolvimento integrado.
SUMÁRIO
RESUMO ................................................................................................................... 8
ABSTRACT ................................................................................................................. 9
LISTA DE ILUSTRAÇÕES ........................................................................................ 10
LISTA DE ABREVIATURAS E SIGLAS .................................................................... 12
1 INTRODUÇÃO ...................................................................................................... 15
2 TRABALHOS RELACIONADOS ........................................................................... 17
3 MODELAGEM DO SISTEMA ................................................................................ 19
3.1 Análise de Requisitos ................................................................................... 19
3.1.1 Requisitos Funcionais: ........................................................................... 19
3.1.2 Requisitos Não Funcionais: ................................................................... 20
3.2 Regra de Negócio ........................................................................................ 20
3.3 Diagrama de caso de uso ............................................................................ 21
3.4 Casos de Uso ............................................................................................... 22
3.5 Diagrama de classes .................................................................................... 47
3.6 diagrama de Entidade e relacionamento ...................................................... 48
3.7 diagrama de estado...................................................................................... 49
3.8 DiagramaS de sequÊncia ............................................................................. 50
4 Tecnologias UTILIZADAS ..................................................................................... 58
5 APRESENTAÇÃO DO SISTEMA FINAL .............................................................. 59
5.1 VISÃO GERAL DO SISTEMA ...................................................................... 59
5.2 Categoria ...................................................................................................... 60
5.3 Estado .......................................................................................................... 63
5.4 Município ...................................................................................................... 65
5.5 Cidadão ........................................................................................................ 66
5.6 Responsável ................................................................................................ 68
5.7 Status ........................................................................................................... 69
5.8 Relato ........................................................................................................... 70
5.9 Histórico de relato ........................................................................................ 74
6 CONCLUSÕES E TRABALHOS FUTUROS ......................................................... 75
REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................... 76
15
1 INTRODUÇÃO
Na maioria das cidades, as necessidades dos cidadãos são relatadas
pessoalmente e verbalmente aos seus governantes. A formalização destas necessi-
dades ocorre em sistema protocolar e seu andamento ocorre a desejo e a interesse
de tais políticos.
Tendo em vista esta questão, este sistema tem por objetivo auxiliar cida-
dãos e governantes na manutenção de equipamentos públicos. Com um simples
cadastro, o cidadão torna-se um e-Cidadão, o que o habilita a informar a prefeitura
os problemas encontrados na cidade. Por parte da prefeitura, a partir também de um
simples cadastro, esta se habilita e se compromete em observar e responder aos
problemas relatados pelos e-Cidadãos.
O sistema e-Cidadão é um canal de comunicação em que uma pessoa
informa problemas ocorrentes no município nas seguintes categorias:
- Melhorias: Engloba solicitações de um novo equipamento público, por exemplo,
uma nova praça em um determinado bairro.
- Manutenção de obra: Abrange solicitações que ocorrem quando o cidadão observa
que o determinado equipamento público está se deteriorando, por exemplo, as vigas
de uma determinada ponte estão à mostra.
- Desastres: Abrange relatos que informam a ocorrência de um sinistro, por exemplo,
uma ponte de um determinado lugar que tenha caído, um morro que esteja desliza-
do e etc.
- Iminências de desastres: Engloba relatos que informam a possível ocorrência de
um sinistro, por exemplo, uma ponte de um determinado lugar que está a prestes a
cair, um morro que esteja prestes a deslizar e etc.
16
- Solicitação de serviços públicos básicos: Abrange solicitações que ocorrem quando
um cidadão informa que não recebe algum serviço básico oferecido pela prefeitura,
por exemplo, iluminação pública, coleta de lixo e etc.
Ao utilizar o sistema, quando um e-Cidadão envia um relato ou solicita-
ção, este recebe o status de “Aberto”. A seguir, a prefeitura coloca o relato no esta-
do de “Em análise” e, a partir deste momento, analisa a viabilidade técnica, prazos
para atendimento, custos e etc.
Quando o estudo de viabilidade técnica demonstrar incapacidade de
atendimento, o relato passará, mediante justificativa, para o status de “Finalizado”.
Uma vez sendo viável e da vontade política da prefeitura, este é colocado no status
de “Aguardando”. Neste status, a prefeitura realizará os trâmites burocráticos, como:
detalhamento de projeto, abertura de licitação e etc.
Quando do início da execução do projeto, o relato passará ao status de
“Em Execução”. Uma vez terminada a execução, o status do relato passará para
“Finalizado”.
O envio do relato se dará a partir de um aplicativo de dispositivo móvel.
Por intermédio deste, o e-Cidadão poderá enviar fotos e a geolocalização do relato,
bem como acessar seus relatos e acompanhar seu andamento.
A prefeitura poderá administrar e dar andamento aos relatos recebidos por
intermédio do site e-Cidadão. Diversos relatórios estarão disponíveis para ajudar
nessa tarefa.
O sistema e-Cidadão não irá controlar projetos, licitações ou disponibiliza-
rá qualquer meio para que as prefeituras atendam seus relatos. O objetivo principal
do sistema é ser um canal de comunicação entre a prefeitura e os cidadãos, trans-
formando todos em e-Cidadãos.
As tecnologias utilizadas na implementação do sistema proposto foram:
Visual Studio, mySQL e astah.
O restante do trabalho está organizado da seguinte forma: o Capítulo 2
apresenta os trabalhos relacionados ao tema. No Capítulo 3, é apresentado toda a
modelagem do sistema. O Capítulo 4 discute mais sobre as tecnologias escolhidas
para o desenvolvimento do sistema. O Capítulo 5 mostra o resultado final do siste-
ma. Por fim, o Capítulo 6 apresenta as conclusões e trabalhos futuros.
17
2 TRABALHOS RELACIONADOS
Entidades governamentais comumente utilizam duas classes de sistemas
para interação com os cidadãos e organização das informações processadas. A pri-
meira classe é composta pelos Sistemas de Ouvidoria [1]. Este é o sistema no qual
são registrados qualquer sugestão, solicitação, reclamação de um cidadão frente a
um ente público. Normalmente, o registro se dá de três formas:
1 – Registro telefônico.
2 – E-mail.
3 – Preenchimento de formulário no site do ente público.
Este sistema torna-se pouco eficiente por ser gerido pelo ente público que
não oferece a visibilidade necessária, tanto com relação à abertura de relatos, quan-
to na divulgação dos resultados provenientes deste canal.
Um exemplo de sistema de ouvidoria é o sistema telefônico da prefeitura
do Rio de Janeiro, que pode ser utilizado através do número 1746. O sistema tam-
bém possui canal de comunicação pelo site que visa oferecer ao cidadão meios de
solicitar serviços públicos providos por esta prefeitura. Este sistema pode ser consi-
derado ruim, do ponto de vista do cidadão, porque oferece poucos atendentes, a fila
de espera é grande e a grande parte das solicitações não são atendidas [2].
A segunda classe de sistemas é composta pelos sistemas de protocolo.
Nestes sistemas, todo cidadão pode abrir um processo administrativo e, a seguir,
receberá um número (o protocolo), com o qual ele, o cidadão, pode acompanhar o
andamento do processo. Este processo, na maioria dos entes públicos, é feito em
papel e tem suas referências guardadas em sistemas de computador. Este é o meio
mais formal de um cidadão solicitar, informar, exigir e sugerir qualquer problema,
melhoria, mudança ao ente público. Este sistema é considerado arcaico por não en-
volver tecnologias atuais, mas ainda é um dos mais adotados por entes públicos.
No decorrer do atendimento a uma solicitação por parte dos entes públi-
cos utilizando-se os sistemas citados, muitas etapas dos processos são ignoradas
causando inconsistências das informações. O processo caminha por diversos seto-
res para que sejam aprovados recebendo pareceres fisicamente ajuntados a este
processo. Estes costumam levar muito mais tempo para serem apreciados e atendi-
dos pelos entes públicos.
18
Outro sistema disponibilizado pelo governo é o e-OUV [3], que é um sis-
tema online de ouvidoria do poder executivo federal. O sistema consiste em 4 eta-
pas, que são:
Tipo de manifestação: nesse passo, o usuário escolhe, dentre as opções dis-
poníveis, que são denúncia, reclamação, solicitação, sugestão, elogio e sim-
plifique. Após o usuário selecionar a opção deseja, o sistema fornece a pró-
xima etapa.
Destinatário: neste quesito, o usuário preenche um formulário dizendo para
qual órgão público o usuário deseja mandar a mensagem, sobre qual assunto
ele deseja falar e sobre qual órgão deseja falar.
Identificação e descrição: nessa etapa do processo, o sistema disponibilizará
um formulário no qual o usuário deverá preencher alguns dados, que são a
descrição do fato, o local do fato, quais são os envolvidos no fato, e identifica-
ção.
Conclusão do processo: Esta etapa se dá após o preenchimento das informa-
ções nas etapas anteriores.
A grande diferença entre o e-cidadão e os demais sistemas oferecidos
pelos entes públicos é a disponibilização das informações do que o ente público faz
ou deixa de fazer de forma transparente para o cidadão. A emissão de relatórios
formatados e a publicidade destes faz com que a opinião pública se torne uma fer-
ramenta para pressionar os gestores públicos.
Por intermédio do e-Cidadão, a população pode enviar imagens e coor-
denadas de geolocalização de modo a tornar inequívoca a solicitação ou o relato de
um problema.
19
3 MODELAGEM DO SISTEMA
3.1 ANÁLISE DE REQUISITOS
Quando se fala em requisitos funcionais, em engenharia de software, o
requisito define as funções de um sistema de software ou de seus componentes. O
requisito funcional pode englobar diversas funções, por exemplo: alguma funcionali-
dade específica, cálculo, manipulação de dados.
Existem também os requisitos não funcionais, que não corresponde ao
que o sistema fará, mas sim como o sistema fará. Um exemplo de requisito não fun-
cional é requisito de desempenho.
Nas próximas subseções, serão apresentados os requisitos funcionais e os requi-
sitos não funcionais especificados para o sistema desenvolvido neste trabalho, de
forma que fique mais claro o entendimento do sistema.
3.1.1 Requisitos Funcionais:
Os seguintes requisitos funcionais foram levantados para o sistema pro-
posto neste trabalho:
O sistema deve ser capaz de:
1 – Cadastrar eCidadão;
2 – Cadastrar ente Público;
3 – Cadastrar Relato;
4 – Cadastrar Responsável;
5 – Alterar eCidadão;
20
6 – Alterar ente Público;
7 – Alterar Relato;
8 – Alterar Status do Relato;
9 – Alterar Responsável;
10 – Alterar Senha;
11 – Consultar eCidadão;
12 – Consultar ente Público;
13 – Consultar Relato;
14 – Consultar Responsável; e
15 – Enviar e-mails.
3.1.2 Requisitos Não Funcionais:
Os seguintes requisitos não funcionais foram levantados para o sistema
proposto neste trabalho:
1 – O sistema deve ser capaz de suportar no mínimo 2000 usuários simul-
tâneos.
2 – O sistema deve ser capaz de ser executado na plataforma Windows.
3.2 REGRA DE NEGÓCIO
Regra de negócio consiste em mostrar como uma empresa faz um negó-
cio. As organizações possuem políticas para satisfazer os objetivos de um negócio.
As seguintes regras de negócio foram identificadas para o sistema proposto neste
trabalho:
1 – Confirmação cadastral:
21
Ao ser incluído em novo usuário, o sistema deverá enviar e-mail para o
endereço de e-mail confirmado de modo a confirmar esse endereço. Nes-
te e-mail deverá conter um link que, ao ser acionado, levará o usuário a
uma página onde este irá informar a sua senha bem como a confirmação
da senha.
2 – Alteração de senha de usuário:
Este caso acontecerá quando um usuário quiser trocar sua senha. O sis-
tema deverá ser capaz de fornecer ao usuário uma tela que deve conter
os campos de senha antiga, senha nova, e confirmação da senha nova
que deverão ser preenchidos pelo usuário.
3.3 DIAGRAMA DE CASO DE USO
O caso de uso tem como objetivo mostrar todas as funcionalidades do
sistema na visão de um usuário, tendo em vista facilitar a comunicação entre o clien-
te e o analista.
A Figura 1 apresenta o diagrama de casos de uso elaborado para o sis-
tema apresentado neste trabalho.
22
Figura 1: Diagrama de casos de uso
3.4 CASOS DE USO
Esta seção apresenta a descrição textual dos casos de uso apresentados
no diagrama de casos de uso apresentado na Figura 1.
Casos de uso – Manter Usuário (Cadastrar Responsável)
----------------------------------------------------------------------------------------------
Objetivo:
Cadastrar no sistema um novo Responsável.
Pré-condição:
23
Nenhuma.
Fluxo de eventos primário:
1 - O caso de uso se inicia quando o ator seleciona no sistema <Novo>.
2 - O Sistema fornece a tela de formulário para que o usuário preencha.
3 - O ator deve fornecer nome completo.
4 – O ator deve fornecer e-mail.
5 – O ator deve fornecer Senha.
6 – O ator deve fornecer Data de Nascimento.
7 – O ator deve fornecer Estado.
8 – O ator deve fornecer Município.
9 – O sistema valida todos os campos preenchidos.
10 – O usuário escolhe a opção de <Gravar>.
11 – O sistema emite um aviso de confirmação do cadastramento.
12 – O usuário escolhe a opção de <Continuar>.
13 – O sistema emite um aviso que o usuário foi cadastrado com sucesso.
Fluxo de eventos secundário:
Número 9:
1 – O sistema invalida o campo preenchido incorretamente.
2 – O usuário concerta os campos incorretos.
Número 10:
1 – O usuário escolhe a opção <Cancelar>.
2 – A operação é cancelada.
Número 12:
1 – O usuário escolhe a opção <Cancelar>.
2 – O sistema emite um aviso dizendo que o cadastramento foi
cancelado.
3 – O sistema volta para página de preenchimento.
Pós-condição:
Os dados do ator deverão estar gravados com sucesso no sistema.
Atores:
24
O Usuário.
Regra de Negócio:
Um usuário só poderá entrar no sistema após o cadastramento.
Casos de uso – Manter Usuário (Consultar Responsável)
----------------------------------------------------------------------------------------------
Objetivo:
Consultar no sistema um Responsável.
Pré-condição:
O Responsável deve estar autenticado no sistema.
Fluxo de eventos primário:
1 - O caso de uso se inicia quando o ator seleciona no site o <Manter>.
1 - O ator seleciona no site o <Responsável>.
2 – O sistema fornece a tela com os dados do usuário.
Fluxo de eventos secundário:
Nenhum
Pós-condição:
Os dados do usuário deverão estar disponíveis na tela para visualização.
Atores:
O usuário.
Regra de Negócio:
Um usuário só poderá consultar se estiver autenticado no sistema.
Casos de uso – Manter Usuário (Editar dados cadastrais)
----------------------------------------------------------------------------------------------
Objetivo:
Editar dados cadastrais.
Pré-condição:
O Ator deverá estar cadastrado no sistema.
O Ator deve ter entrado no site e escolher a opção de <editar>.
Fluxo de eventos primário:
25
1 - O caso de uso se inicia quando o usuário escolhe a opção de <Man-
ter>.
2 – O ator seleciona a opção de <Responsável>;
3 – O ator escolhe o responsável a ser alterado.
4 – O sistema fornece a tela com todos os dados da conta.
5 – O usuário altera seus dados.
6 – O usuário escolhe a opção <Gravar> no sistema.
7 - O sistema verifica se os campos de cadastros estão preenchido corre-
tamente.
8 – O sistema emite um aviso de confirmação da edição.
9 – O usuário confirma a edição.
10 – Os dados do usuário é alterado.
11 – O sistema volta para página anterior.
Fluxo de eventos secundário:
Número 6:
1 – O usuário escolhe a opção <Cancelar>.
2 – O sistema volta para página anterior.
Número 7:
1 – O sistema identifica erros nos novos dados.
2 – O usuário concerta os dados incorretos.
3 – O sistema verifica se há algum novo erro.
Número 9:
1 – O usuário opta pela opção <Cancelar>
2 – O sistema volta para página de edição.
Pós-condição:
Os novos dados do usuário deverão ser alterados com sucesso.
Atores:
Usuário.
Regra de Negócio:
O Usuário só poderá editar seus dados, apenas se já estiver autenticado.
Casos de uso – Manter Usuário (Deletar Responsável)
----------------------------------------------------------------------------------------------
Objetivo:
26
Deletar Usuário.
Pré-condição:
O Ator deverá estar logado.
O Ator deve escolher a opção <Deletar>
Fluxo de eventos primário:
1 – Esse caso de uso se inicia quando o usuário escolher a opção <Man-
ter> no sistema.
2 – O ator seleciona a opção <Responsável>.
3 – O ator escolhe o responsável para ser excluído.
4 – O sistema exibe todos os dados do responsável.
5 – O ator seleciona a opção <Excluir>.
6 – O sistema emite um aviso de confirmação da remoção daquele usuá-
rio.
7 – O usuário confirma a remoção.
8 – O usuário é removido com sucesso.
Fluxo de eventos secundário:
Número 5:
1 – O usuário escolher a opção de cancelar.
2 – O cancelamento e feito.
3 – O sistema volta para página inicial.
Pós-condição:
O usuário deve ser removido no sistema.
Atores:
Usuário.
Regra de Negócio:
A remoção só poderá ser feita apenas quando o usuário estiver autenti-
cado.
Casos de uso – Manter Usuário (Cadastrar Cidadão)
----------------------------------------------------------------------------------------------
Objetivo:
Cadastrar no sistema um novo Cidadão.
Pré-condição:
27
Nenhuma pré-condição para este evento.
Fluxo de eventos primário:
1 - O caso de uso se inicia quando o ator seleciona no sistema <Novo>.
2 - O Sistema fornece a tela de formulário para que o usuário preencha.
3 - O ator deve fornecer nome completo.
4 – O ator deve fornecer e-mail.
5 – O ator deve fornecer Senha.
6 – O ator deve fornecer Data de Nascimento.
7 – O sistema valida todos os campos preenchidos.
8 – O usuário escolhe a opção de <Gravar>.
9 – O sistema emite um aviso de confirmação do cadastramento.
10 – O usuário escolhe a opção de <Continuar>.
11 – O sistema emite um aviso que o usuário foi cadastrado com sucesso.
Fluxo de eventos secundário:
Número 7:
1 – O sistema invalida o campo preenchido incorretamente.
2 – O usuário concerta os campos incorretos.
Número 8:
1 – O usuário escolhe a opção <Cancelar>.
2 – A operação é cancelada.
Número 10:
1 – O usuário escolhe a opção <Cancelar>.
2 – O sistema emite um aviso dizendo que o cadastramento foi
cancelado.
3 – O sistema volta para página de preenchimento.
Pós-condição:
Os dados do ator deverão estar gravados com sucesso no sistema.
Atores:
O Usuário.
Regra de Negócio:
28
Um usuário só poderá entrar no sistema após o cadastramento.
Casos de uso – Manter Usuário (Consultar Cidadão)
----------------------------------------------------------------------------------------------
Objetivo:
Consultar no sistema um Cidadão.
Pré-condição:
O Cidadão deve estar autenticado no sistema.
Fluxo de eventos primário:
1 - O caso de uso se inicia quando o ator seleciona no site o <Manter>.
1 - O ator seleciona no site o <Cidadão>.
2 – O sistema fornece a tela com os dados do usuário.
Fluxo de eventos secundário:
Nenhum
Pós-condição:
Os dados do usuário deverão estar disponíveis na tela para visualização.
Atores:
O usuário.
Regra de Negócio:
Um usuário só poderá consultar se estiver autenticado no sistema.
Casos de uso – Manter Usuário (Editar dados cadastrais)
----------------------------------------------------------------------------------------------
Objetivo:
Editar dados cadastrais.
Pré-condição:
O ator deverá estar cadastrado e logado no sistema.
O Ator deve ter entrado no site e escolher a opção de <editar >.
Fluxo de eventos primário:
1 - O caso de uso se inicia quando o usuário escolhe a opção de <Man-
ter>.
2 – O ator seleciona a opção de <Cidadão>;
29
3 – O ator escolhe o responsável a ser alterado.
4 – O sistema fornece a tela com todos os dados da conta.
5 – O usuário altera seus dados.
6 – O usuário escolhe a opção <Gravar> no sistema.
7 - O sistema verifica se os campos de cadastros estão preenchido corre-
tamente.
8 – O sistema emite um aviso de confirmação da edição.
9 – O usuário confirma a edição.
10 – Os dados do usuário é alterado.
11 – O sistema volta para pagina anterior.
Fluxo de eventos secundário:
Número 6:
1 – O usuário escolhe a opção <Cancelar>.
2 – O sistema volta para página anterior.
Número 7:
1 – O sistema identifica erros nos novos dados.
2 – O usuário concerta os dados incorretos.
3 – O sistema verifica se há algum novo erro.
Número 9:
1 – O usuário opta pela opção <Cancelar>
2 – O sistema volta para página de edição.
Pós-condição:
Os novos dados do usuário deverão ser alterados com sucesso.
Atores:
Usuário.
Regra de Negócio:
O Usuário só poderá editar seus dados apenas se já estiver autenticado.
Casos de uso – Manter Usuário (Deletar Cidadão)
----------------------------------------------------------------------------------------------
Objetivo:
Deletar Cidadão.
Pré-condição:
30
O Ator deve escolher a opção <Excluir>
Fluxo de eventos primário:
1 – Esse caso de uso se inicia quando o usuário escolher a opção <Man-
ter> no sistema.
2 – O ator seleciona a opção <Cidadão>.
3 – O ator escolhe o responsável para ser excluído.
4 – O sistema exibe todos os dados do responsável.
5 – O ator seleciona a opção <Excluir>.
6 – O sistema emite um aviso de confirmação da remoção daquele usuá-
rio.
7 – O usuário confirma a remoção.
8 – O usuário é removido com sucesso.
Fluxo de eventos secundário:
Número 5:
1 – O usuário escolher a opção de cancelar.
2 – O cancelamento e feito.
3 – O sistema volta para página inicial.
Pós-condição:
O usuário deve ser removido no sistema.
Atores:
Usuário.
Regra de Negócio:
A remoção só poderá ser feita apenas quando o usuário estiver autenti-
cado.
Casos de uso – Manter Relato (Cadastrar Relato)
----------------------------------------------------------------------------------------------
Objetivo:
Cadastrar no sistema um novo Relato.
Pré-condição:
O Usuário precisar estar autenticado no sistema.
Fluxo de eventos primário:
31
1 - O caso de uso se inicia quando o ator seleciona no sistema <Histórico
de Relato>.
2 – O ator seleciona a opção <Novo>.
3 - O Sistema fornece a tela de formulário para que o usuário preencha.
4 – O ator deve fornecer Código do município.
5 - O ator deve fornecer Descrição.
6 – O ator deve fornecer Latitude.
7 – O ator deve fornecer Longitude.
8 – O ator deve fornecer Justificativa.
9 – O ator deve fornecer Localização.
10 – O ator deve fornecer Foto.
11 – O sistema valida todos os campos preenchidos.
12 – O usuário escolhe a opção de <Gravar>.
13 – O sistema emite um aviso de confirmação do cadastramento.
14 – O usuário escolhe a opção de <Continuar>.
15 – O sistema emite um aviso que o usuário foi cadastrado com sucesso.
16 – O sistema volta para a página inicial.
Fluxo de eventos secundário:
Número 11:
1 – O sistema invalida o campo preenchido incorretamente.
2 – O usuário concerta os campos incorretos.
Número 12:
1 – O usuário escolhe a opção <Cancelar>.
2 – O sistema volta para página inicial.
Número 14:
1 – O usuário escolhe a opção <Cancelar>.
2 – O sistema emite um aviso dizendo que o cadastramento foi
cancelado.
3 – O sistema volta para página de preenchimento.
Pós-condição:
O relato estar gravado com sucesso no sistema.
Atores:
32
O Usuário.
Regra de Negócio:
Um usuário só poderá cadastrar um relato apenas se estiver autenticado.
Casos de uso – Manter Relato (Consultar Relato)
----------------------------------------------------------------------------------------------
Objetivo:
Consultar no sistema um Relato.
Pré-condição:
O usuário deve estar autenticado no sistema.
Fluxo de eventos primário:
1 - O caso de uso se inicia quando o ator seleciona no site o <Manter>
2 – O ator seleciona a opção < Relato>.
3 – O sistema fornece a tela com todos os relatos disponíveis.
4 – O usuário escolhe apenas um para ser consultado.
5 – O sistema emite a tela de consulta daquele relato.
Fluxo de eventos secundário:
Número 4:
1 – O usuário escolhe a opção <Cancelar Consulta>.
2 – O sistema volta para página inicial.
Pós-condição:
Os dados do Relato deverão estar disponíveis na tela para consulta.
Atores:
O usuário.
Regra de Negócio:
Um usuário só poderá consultar se estiver autenticado no sistema.
Casos de uso – Manter Relato (Editar Relato)
----------------------------------------------------------------------------------------------
Objetivo:
Editar Relato.
Pré-condição:
33
O Responsável deve estar autenticado no sistema e escolher a opção de
<editar>.
Fluxo de eventos primário:
1 - O caso de uso se inicia quando o usuário escolhe a opção de <Rela-
to>.
2 – O sistema fornece a tela com todos os dados do Relato.
3 – O ator seleciona o relato.
4 – O sistema exibe todos os dados do relato.
5 – O usuário altera seus dados disponíveis.
6 – O usuário escolhe a opção <Editar> no sistema.
7 - O sistema verifica se os campos de cadastros estão preenchido corre-
tamente.
8 – O sistema emite um aviso de confirmação da edição.
9 – O usuário confirma a edição.
10 – Os dados do Relato é alterado.
11 – O sistema volta para pagina anterior.
Fluxo de eventos secundário:
Número 6:
1 – O usuário escolhe a opção <Cancelar>.
2 – O sistema volta para página anterior.
Número 7:
1 – O sistema identifica erros nos novos dados.
2 – O usuário concerta os dados incorretos.
3 – O sistema verifica se há algum novo erro.
Número 9:
1 – O usuário opta pela opção <Cancelar>
2 – O sistema volta para página de edição.
Pós-condição:
Os novos dados do relato deverão ser alterados com sucesso.
Atores:
Responsável.
Regra de Negócio:
O Responsável só poderá editar seus dados, apenas se já estiver autenti-
cado.
34
Casos de uso – Manter Relato (Alterar status do Relato)
----------------------------------------------------------------------------------------------
Objetivo:
Finalizar Usuário.
Pré-condição:
O responsável deve se autenticar.
O Responsável deve escolher a opção <Alterar status>
Fluxo de eventos primário:
1 – Esse caso de uso se inicia quando o responsável escolher a opção
<Alterar> no sistema.
2 – O responsável emite uma justificativa para a finalização desse relato.
3 – O sistema emite um aviso de confirmação de alteração daquele relato.
4 – O usuário confirma a alteração.
5 – O usuário é finalizado com sucesso.
6 – O sistema retorna para página de inicial.
Fluxo de eventos secundário:
Número 4:
1 – O usuário escolher a opção de cancelar.
2 – O cancelamento e feito.
3 – O sistema volta para página inicial.
Pós-condição:
O usuário deve ter alterado o status do relato no sistema.
Atores:
Responsável.
Regra de Negócio:
A alteração só poderá ser feita apenas quando o responsável estiver au-
tenticado.
35
Casos de uso – Manter Categoria (Cadastrar Categoria)
----------------------------------------------------------------------------------------------
Objetivo:
Cadastrar no sistema uma nova Categoria.
Pré-condição:
O usuário deve estar autenticado no sistema.
O usuário deve escolher a opção <Cadastrar categoria> no sistema.
Fluxo de eventos primário:
1 - O caso de uso se inicia quando o ator seleciona no sistema <Novo>.
2 - O Sistema fornece a tela de formulário para que o usuário preencha.
3 – O usuário fornece a descrição.
4 – O sistema valida todos os campos preenchidos.
5 – O usuário escolhe a opção de <Gravar>.
6 – O sistema emite um aviso de confirmação do cadastramento.
7 – O usuário escolhe a opção de <Continuar>.
8 – O sistema emite um aviso que o usuário foi cadastrado com sucesso.
9 – O sistema volta para a página inicia.
Fluxo de eventos secundário:
Número 4:
1 – O sistema invalida o campo preenchido incorretamente.
2 – O usuário concerta os campos incorretos.
Número 5:
1 – O usuário escolhe a opção <Cancelar>.
2 – O sistema volta para página de inicial.
Número 7:
1 – O usuário escolhe a opção <Cancelar>.
2 – O sistema emite um aviso dizendo que o cadastramento foi
cancelado.
3 – O sistema volta para página de preenchimento.
Pós-condição:
36
A categoria deve ser gravada com sucesso no sistema.
Atores:
O Usuário.
Regra de Negócio:
Um usuário só poderá cadastrar se estiver autenticado.
Casos de uso – Manter categoria (Consultar Categoria)
----------------------------------------------------------------------------------------------
Objetivo:
Consultar no sistema uma categoria.
Pré-condição:
O responsável deve estar logado.
O usuário deve escolher a opção <Consultar Categoria>.
Fluxo de eventos primário:
1 - O caso de uso se inicia quando o ator seleciona na página a categoria
que deseja alterar.
2 – O sistema fornece a tela os dados da categoria selecionada.
3 – O sistema exibe na tela os dados da categoria escolhida.
Fluxo de eventos secundário:
Número 2:
1 – O usuário opta por cancelar a consulta.
2 – O sistema volta para página inicial.
Pós-condição:
Os dados da categoria devem estar disponíveis para consulta.
Atores:
O usuário.
Regra de Negócio:
Um usuário só poderá consultar se estiver autenticado no sistema.
37
Casos de uso – Manter Categoria (Alterar Categoria)
----------------------------------------------------------------------------------------------
Objetivo:
Editar Categoria.
Pré-condição:
O Ator deve ter entrado no site e escolher a opção de <Alterar categoria>.
Fluxo de eventos primário:
1 - O caso de uso se inicia quando o usuário escolhe a opção de <Alte-
rar>.
2 – O sistema fornece a tela com todos os dados de categoria seleciona-
da.
3 – O usuário altera seus dados.
4 – O usuário escolhe a opção <Alterar> no sistema.
5 - O sistema verifica se os campos de cadastros estão preenchidos cor-
retamente.
6 – O sistema emite um aviso de confirmação da edição.
7 – O usuário confirma a edição.
8 – Os dados do usuário é alterado.
9 – O sistema volta para pagina anterior.
Fluxo de eventos secundário:
Número 3:
1 – O usuário escolhe a opção <Cancelar>.
2 – O sistema volta para página anterior.
Número 5:
1 – O sistema identifica erros nos novos dados.
2 – O usuário concerta os dados incorretos.
3 – O sistema verifica se há algum novo erro.
Número 7:
1 – O usuário opta pela opção <Cancelar>
2 – O sistema volta para página de edição.
Pós-condição:
Os novos dados de categoria deverão ser alterados com sucesso.
Atores:
Usuário.
38
Regra de Negócio:
O Usuário só poderá editar seus dados, apenas se já estiver autenticado.
Casos de uso – Manter Categoria (Deletar categoria)
----------------------------------------------------------------------------------------------
Objetivo:
Deletar categoria.
Pré-condição:
O ator deve entrar na sua conta no sistema.
O Ator deve escolher a opção <Excluir categoria>
Fluxo de eventos primário:
1 – Esse caso de uso se inicia quando o usuário escolher a opção <Cate-
goria> no sistema.
2 – O sistema emite um formulário com todas categorias.
3 – O ator escolhe a categoria desejada.
4 – O ator seleciona a opção <Excluir>.
5 – O sistema emite um aviso de confirmação da remoção daquela cate-
goria.
6 – O usuário confirma a remoção.
7 – O sistema emite um aviso de que o usuário é removido com sucesso.
8 – O sistema retorna para página inicial.
Fluxo de eventos secundário:
Número 4:
1 – O usuário escolher a opção de cancelar.
2 – O cancelamento e feito.
3 – O sistema volta para página inicial.
Número 6:
1 – O usuário escolher a opção de cancelar.
2 – O cancelamento e feito.
3 – O sistema volta para página inicial.
Pós-condição:
39
A categoria deve ser removida no sistema.
Atores:
Usuário.
Regra de Negócio:
A remoção só poderá ser feita apenas quando o usuário estiver autenti-
cado.
Casos de uso – Manter Estado (Cadastrar Estado)
----------------------------------------------------------------------------------------------
Objetivo:
Cadastrar no sistema um novo Estado.
Pré-condição:
O responsável deve estar autenticado.
O usuário deve escolher a opção <Cadastrar Estado> no sistema.
Fluxo de eventos primário:
1 - O caso de uso se inicia quando o ator seleciona no sistema <Estado>.
2 - O Sistema fornece a tela de formulário para que o usuário preencha.
3 – O usuário fornece a Código IBGE.
4 – O usuário fornece a Sigla.
5 – O usuário fornece a Nome.
6 – O sistema valida todos os campos preenchidos.
7 – O usuário escolhe a opção de <Gravar>.
8 – O sistema emite um aviso de confirmação do cadastramento.
9 – O usuário escolhe a opção de <Continuar>.
10 – O sistema emite um aviso que o usuário foi cadastrado com sucesso.
11 – O sistema volta para a página inicial.
Fluxo de eventos secundário:
Número 6:
1 – O sistema invalida o campo preenchido incorretamente.
2 – O usuário concerta os campos incorretos.
Número 7:
40
1 – O usuário escolhe a opção <Cancelar>.
2 – O sistema volta para página de inicial.
Número 9:
1 – O usuário escolhe a opção <Cancelar>.
2 – O sistema emite um aviso dizendo que o cadastramento foi
cancelado.
3 – O sistema volta para página de preenchimento.
Pós-condição:
O estado deve ser gravado com sucesso no sistema.
Atores:
O Usuário.
Regra de Negócio:
Um usuário só poderá cadastrar se estiver autenticado
Casos de uso – Manter Estado (Consultar Estado)
----------------------------------------------------------------------------------------------
Objetivo:
Consultar no sistema um Estado.
Pré-condição:
O ator deve estar autenticado.
O usuário deve escolher a opção <Consultar Estado>.
Fluxo de eventos primário:
1 - O caso de uso se inicia quando o ator seleciona no site o <Estado>.
2 – O sistema fornece a tela com todos Estados.
3 – O usuário escolhe uma para consultar.
4 – O sistema exibe na tela os dados do Estado escolhido.
Fluxo de eventos secundário:
Número 3:
1 – O usuário opta por cancelar a consulta.
2 – O sistema volta para página inicial.
Pós-condição:
41
Os dados do Estado devem estar disponíveis para consulta.
Atores:
O usuário.
Regra de Negócio:
Um usuário só poderá consultar se estiver autenticado no sistema.
Casos de uso – Manter Estado (Alterar Estado)
----------------------------------------------------------------------------------------------
Objetivo:
Editar Estado.
Pré-condição:
O ator deve estar logado.
O Ator deve ter entrado no site e escolher a opção de <Alterar Estado>.
Fluxo de eventos primário:
1 - O caso de uso se inicia quando o usuário escolhe a opção de <Esta-
do>.
2 – O sistema fornece um formulário com todos os estados disponíveis.
3 – O ator seleciona o estado desejado.
4 – O sistema fornece a tela com todos os dados de Estado.
5 – O usuário altera seus dados.
6 – O usuário escolhe a opção <Alterar> no sistema.
7 - O sistema verifica se os campos de cadastros estão preenchidos cor-
retamente.
8 – O sistema emite um aviso de confirmação da edição.
9 – O usuário confirma a edição.
10 – Os dados do usuário são alterados.
11 – O sistema volta para pagina anterior.
Fluxo de eventos secundário:
Número 6:
1 – O usuário escolhe a opção <Cancelar >.
2 – O sistema volta para página anterior.
Número 7:
1 – O sistema identifica erros nos novos dados.
42
2 – O usuário concerta os dados incorretos.
3 – O sistema verifica se há algum novo erro.
Número 8:
1 – O usuário opta pela opção <Cancelar>
2 – O sistema volta para página de edição.
Pós-condição:
Os novos dados de estado deverão ser alterados com sucesso.
Atores:
Usuário.
Regra de Negócio:
O Usuário só poderá editar seus dados, apenas se já estiver autenticado.
Casos de uso – Manter Estado (Deletar Estado)
----------------------------------------------------------------------------------------------
Objetivo:
Deletar Estado.
Pré-condição:
O Ator deve escolher a opção <Deletar Estado>
Fluxo de eventos primário:
1 – Esse caso de uso se inicia quando o usuário escolher a opção <Esta-
do> no sistema.
2 – O sistema emite todos os estados disponíveis.
3 – O ator seleciona o estado desejado.
4 – O sistema emite a tela com todos os dados do estado.
5 – O ator seleciona a opção <Excluir>.
6 – O sistema emite um aviso de confirmação da remoção daquele Esta-
do.
7 – O usuário confirma a remoção.
8 – O usuário é removido com sucesso.
9 – O sistema retorna para página inicial.
Fluxo de eventos secundário:
Número 5:
1 – O usuário escolher a opção de cancelar.
43
2 – O cancelamento e feito.
3 – O sistema volta para página inicial.
Número 7:
1 – O usuário escolher a opção de cancelar.
2 – O cancelamento é feito.
3 – O sistema volta para página inicial.
Pós-condição:
O estado deve ser removido no sistema.
Atores:
Usuário.
Regra de Negócio:
A remoção só poderá ser feita apenas quando o usuário estiver autenti-
cado.
Casos de uso – Manter Município (Cadastrar Município)
----------------------------------------------------------------------------------------------
Objetivo:
Cadastrar no sistema um novo Município.
Pré-condição:
O responsável deve estar logado.
O usuário deve escolher a opção <Cadastrar Município > no sistema.
Fluxo de eventos primário:
1 - O caso de uso se inicia quando o ator seleciona no sistema <Município
>.
2 – O sistema emite uma tela com uma lista de todos os municípios ca-
dastrados.
3 – O ator seleciona a opção <Novo>.
4 - O Sistema fornece a tela de formulário para que o usuário preencha.
5 – O usuário fornece a Código IBGE.
6 – O usuário fornece Código IBGE Estado.
7 – O usuário fornece a Nome.
8 – O usuário fornece o e-mail geral.
44
9 – O sistema valida todos os campos preenchidos.
10 – O usuário escolhe a opção de <Gravar>.
11 – O sistema emite um aviso de confirmação do cadastramento.
12 – O usuário escolhe a opção de <Continuar>.
13 – O sistema emite um aviso que o usuário foi cadastrado com sucesso.
14 – O sistema volta para a página inicial.
Fluxo de eventos secundário:
Número 9:
1 – O sistema invalida o campo preenchido incorretamente.
2 – O usuário concerta os campos incorretos.
Número 10:
1 – O usuário escolhe a opção <Cancelar>.
2 – O sistema volta para página de inicial.
Número 12:
1 – O usuário escolhe a opção <Cancelar>.
2 – O sistema emite um aviso dizendo que o cadastramento foi
cancelado.
3 – O sistema volta para página de preenchimento.
Pós-condição:
O Município deve ser gravado com sucesso no sistema.
Atores:
O Usuário.
Regra de Negócio:
Um usuário só poderá cadastrar se estiver autenticado.
Casos de uso – Manter Município (Consultar Município)
----------------------------------------------------------------------------------------------
Objetivo:
Consultar no sistema um Município.
45
Pré-condição:
O responsável deve estar logado.
O usuário deve escolher a opção <Consultar Município >.
Fluxo de eventos primário:
1 - O caso de uso se inicia quando o ator seleciona no site o <Município>.
2 – O sistema fornece a tela com todos Município.
3 – O usuário escolhe uma para consultar.
4 – O sistema exibe na tela os dados do Estado escolhido.
Fluxo de eventos secundário:
Número 3:
1 – O usuário opta por cancelar a consulta.
2 – O sistema volta para página inicial.
Pós-condição:
Os dados do Município devem estar disponíveis para consulta.
Atores:
O Responsável.
Regra de Negócio:
Um usuário só poderá consultar se estiver autenticado no sistema.
Casos de uso – Manter Município (Alterar Município)
----------------------------------------------------------------------------------------------
Objetivo:
Editar Município.
Pré-condição:
Algum município deverá existir já no sistema.
O Ator deve ter entrado no site e escolher a opção de <Alterar Município
>.
Fluxo de eventos primário:
1 - O caso de uso se inicia quando o usuário escolhe a opção de <Muni-
cípio>.
2 – O sistema fornece a tela com todos os municípios disponíveis.
3 – O ator seleciona o município desejado.
4 – O sistema fornece a tela com todos os dados de Município.
46
5 – O usuário altera seus dados.
6 – O usuário escolhe a opção <Alterar> no sistema.
7 - O sistema verifica se os campos de cadastros estão preenchidos cor-
retamente.
8 – O sistema emite um aviso de confirmação da edição.
9 – O usuário confirma a edição.
10 – Os dados do usuário é alterado.
11 – O sistema volta para pagina anterior.
Fluxo de eventos secundário:
Número 6:
1 – O usuário escolhe a opção <Cancelar>.
2 – O sistema volta para página anterior.
Número 7:
1 – O sistema identifica erros nos novos dados.
2 – O usuário concerta os dados incorretos.
3 – O sistema verifica se há algum novo erro.
Número 9:
1 – O usuário opta pela opção <Cancelar>
2 – O sistema volta para página de edição.
Pós-condição:
Os novos dados de Município deverão ser alterados com sucesso.
Atores:
Responsável.
Regra de Negócio:
O Usuário só poderá editar seus dados apenas se já estiver autenticado.
Casos de uso – Manter Município (Excluir Município)
----------------------------------------------------------------------------------------------
Objetivo:
Excluir Município.
Pré-condição:
Algum município deverá existir já no sistema.
O Ator deve escolher a opção <Excluir Município >
47
Fluxo de eventos primário:
1 – Esse caso de uso se inicia quando o usuário escolher a opção <Muni-
cípio > no sistema.
2 – O sistema fornece a tela com todos os municípios disponíveis.
3 – O ator seleciona o município desejado.
4 – O sistema fornece a tela com todos os dados do município seleciona-
do.
5 – O ator seleciona a opção <Excluir>.
6 – O sistema emite um aviso de confirmação da remoção daquele Muni-
cípio.
7 – O usuário confirma a remoção.
8 – O usuário é removido com sucesso.
9 – O sistema retorna para página inicial.
Fluxo de eventos secundário:
Número 5:
1 – O usuário escolher a opção de cancelar.
2 – O cancelamento e feito.
3 – O sistema volta para página inicial.
Pós-condição:
O Município deve ser removido no sistema.
Atores:
Responsável.
Regra de Negócio:
A remoção só poderá ser feita apenas quando o usuário estiver autenti-
cado.
3.5 DIAGRAMA DE CLASSES
A Figura 2 apresenta o diagrama de classes do sistema proposto. Este
diagrama indica todos os objetos existente no sistema.[4]
48
Figura 2: Diagrama de Classes
3.6 DIAGRAMA DE ENTIDADE E RELACIONAMENTO
A Figura 3 apresenta o diagrama de Entidade e Relacionamento [5] do
sistema proposto. O diagrama apresentado a seguir tem como objetivo descrever um
modelo de dados.
49
Figura 3: Diagrama de Entidade e Relacionamento
3.7 DIAGRAMA DE ESTADO
A Figura 4 apresenta o diagrama de estado [6] de uma solicitação ou rela-
to registrado no sistema pelo cidadão. Este diagrama indica o estado ou alguma si-
tuação na execução de um processo de um sistema.
50
Figura 4: Diagrama de Estado
3.8 DIAGRAMAS DE SEQUÊNCIA
Diagramas de sequência [7] são utilizados para representar a sequencia
dos processos do sistema, bem como, suas mensagens.
As figuras 8, 9,10 e 11 apresentam os diagramas de sequência definidos
no decorrer do processo de modelagem do sistema proposto neste trabalho.
58
4 TECNOLOGIAS UTILIZADAS
Dentre as ferramentas disponíveis, foram escolhidas estas ferramentas
tendo em vista a facilidade de programação:
Visual Studio [8]: O Visual Studio é um sistema desenvolvido pela empresa
Microsoft e é um Ambiente de Desenvolvimento Integrado (IDE) para desen-
volvedores de software. Essa ferramenta se dedica especialmente a .NET
Framework e as linguagens VB (Visual Basic), C, C# (C Sharp), C++ e etc.
MySQL [9]: O MySQL é um sistema de gerenciamento de banco de dados
(SGBD). Esta ferramenta utiliza sua linguagem SQL (Linguagem de Consulta
Estruturada).
Astah [10]: O Astah é uma ferramenta de modelagem UML desenvolvida no
Japão na plataforma Java.
59
5 APRESENTAÇÃO DO SISTEMA FINAL
Este capítulo apresenta os resultados dos testes iniciais de utilização do
sistema proposto, modelado e implementado neste trabalho. Para ilustrar a utilização
do sistema, capturas de tela foram realizadas a cada passo executado.
5.1 VISÃO GERAL DO SISTEMA
As principais telas do sistema são: tela de Login do usuário (Figura 12); e
a tela com as opções de menu (Figura 13).
Figura 12: Tela de Login
60
Figura 13: Tela Menu de Opções
5.2 CATEGORIA
A tela com a lista de categoria é exibida quando o usuário escolhe a op-
ção <Categoria> no menu <manter> localizado na parte superior do sistema (Figura
13). Assim que o usuário selecionar a opção, o sistema disponibilizará a tela de lista
de categoria, conforme a Figura 14.
Figura 14: Tela de lista de categoria
O sistema fornece a tela de inclusão de categoria após o usuário selecio-
nar a opção <Novo> na tela de lista de categorias (Figura 14).
61
Figura 14: Tela de inclusão de categoria
Após preencher o formulário, o usuário pressiona o botão <Gravar>. O
sistema exibirá uma janela solicitando a confirmação de gravação (Figura 15).
Figura 15: Tela de confirmação
Após o usuário confirmar a gravação, será exibida a tela com mensagem
da efetivação da gravação (Figura 16).
Figura 16: Tela de Registro gravado com sucesso
Caso ocorra alguma falha na gravação será exibida uma mensagem con-
tendo erro e a informação de que a gravação não foi realizada (Figura 17).
62
Figura 17: Tela de Erro de Gravação
Para alterar alguma categoria, o usuário deve clicar na categoria desejada
na lista (Figura ). A seguir, o sistema exibe a tela de edição (Figura 18) em que o
usuário pode alterar os dados e gravá-los.
Figura 18: Edição de Categoria
Para excluir a categoria, basta o usuário clica no botão <Excluir>. O sis-
tema exibirá uma tela de confirmação (Figura 19).
Figura 19: Confirmação de Exclusão
63
O usuário tendo confirmado a exclusão, será exibida a tela com mensa-
gem da efetivação da exclusão (Figura 20).
Figura 20: Exclusão com Sucesso
Figura 21: Tela de erro de exclusão
5.3 ESTADO
O funcionamento da tela de estado é semelhante ao funcionamento da
tela de categoria. Esta é exibida quando o usuário escolhe a opção <Estado> no
menu <manter> (Figura 13). Suas diferenças estão nos campos que são apresenta-
dos (Figura 22) e nas telas subsequentes de cadastro (Figura 23) e edição (Figura
24).
64
Figura 22: Tela de lista de estados
Figura 23: Tela de inclusão (cadastrar) de Estado
Figura 24: Tela de edição de estado
65
5.4 MUNICÍPIO
O funcionamento da tela de município é semelhante ao funcionamento da
tela de categoria. Esta é exibida quando o usuário escolhe a opção <Município> no
menu <manter> (Figura 13). Suas diferenças estão nos campos que são apresenta-
dos (Figura 25) e nas telas subsequentes de cadastro (Figura 26) e edição (Figura
27).
Figura 25: Tela de lista de municípios
Figura 26: Tela de inclusão (cadastro) de município
66
Figura 27: Tela de edição de município
5.5 CIDADÃO
O funcionamento da tela de cidadão é semelhante ao funcionamento da
tela de categoria. Esta é exibida quando o usuário escolhe a opção <Cidadão> no
menu <manter> (Figura 13). Suas diferenças estão nos campos que são apresenta-
dos (Figura 28) e nas telas subsequentes de cadastro (Figura 29) e edição (Figura
30).
Figura 28: Tela de lista de cidadãos
68
5.6 RESPONSÁVEL
O funcionamento da tela de responsável é semelhante ao funcionamento
da tela de categoria. Esta é exibida quando o usuário escolhe a opção <Responsá-
vel> no menu <manter> (Figura 13). Suas diferenças estão nos campos que são
apresentados (Figura 31) e nas telas subsequentes de cadastro (Figura 32) e edição
(Figura 33).
Figura 31: Tela de lista de responsável
Figura 32: Tela de inclusão (cadastro) de responsável
69
Figura 33: Tela de edição de responsável
5.7 STATUS
O funcionamento da tela de status é semelhante ao funcionamento da tela
de categoria. Esta é exibida quando o usuário escolhe a opção <Status> no menu
<manter> (Figura 13). Suas diferenças estão nos campos que são apresentados
(Figura 34) e nas telas subsequentes de cadastro (Figura 35) e edição (Figura 36).
Figura 34: Tela de Lista de status
70
Figura 35: Tela de inclusão (cadastro) de status
Figura 36: Tela de edição de status
5.8 RELATO
O funcionamento da tela de relato é semelhante ao funcionamento da tela
de categoria. Esta é exibida quando o usuário escolhe a opção <Relato> no menu
<manter> (Figura 13). Suas diferenças estão nos campos que são apresentados
(Figura 37) e nas telas subsequentes de cadastro (Figura 38) e edição (Figura 39).
74
5.9 HISTÓRICO DE RELATO
A tela com a lista de histórico de relato é exibida quando o usuário esco-
lhe a opção <Histórico de Relato> no menu <manter>, localizado na parte superior
do sistema (Figura 13). Assim que o usuário seleciona a opção, o sistema disponibi-
liza a tela de lista de histórico de relato (Figura 40).
Figura 40: Tela de lista de histórico de relato
75
6 CONCLUSÕES E TRABALHOS FUTUROS
Este trabalho apresentou a modelagem e desenvolvimento do sistema e-
cidadão cujo objetivo é armazenar, gerenciar e tornar públicas as solicitações, os
relatos dos cidadãos e que devem ser atendidas pelo governo. O sistema também
visa facilitar a comunicação do cidadão com seus governantes e oferecer clareza do
estado das solicitações realizadas pelos usuários.
Num trabalho futuro, esse sistema deverá se implementado em uma ver-
são mobile, a qual dará para seus usuários a facilidade de tê-lo na palma de suas
mãos facilitando a abertura de solicitações.
76
REFERÊNCIAS BIBLIOGRÁFICAS
1. LAMEIRÃO, Marcio Martins. Entrevista para este trabalho. Analista responsá-
vel pelos sistemas da Prefeitura Municipal de Saquarema no ano de 1998 a
2000
2. ALFANO, Bruno. Um a cada três pedidos feitos ao 1746 não tem solução,
Jornal Extra <https://extra.globo.com/noticias/rio/um-cada-tres-pedidos-feitos-
ao-1746-nao-tem-solucao-22672435.html>, Publicado em 11/05/2018
3. Ministério da Transparência e Controladoria-Geral da União <
https://sistema.ouvidorias.gov.br/publico/Manifestacao/RegistrarManifestacao.
aspx>, Acesso em 11/05/2018
4. Significado de diagrama de classes,
<https://www.significados.com.br/diagrama-de-classes/>, Acesso em
11/01/2018.
5. Alan Chaves, Diagrama de entidade e relacionamento,
<https://prezi.com/86jnykxxd7vi/diagrama-de-entidade-de-relacionamento-
der/>, Acesso em 02/03/2015.
6. Diagrama de transição de estados,
<https://pt.wikipedia.org/wiki/Diagrama_de_transi%C3%A7%C3%A3o_de_est
ados>, Acesso em 11/05/2018.
7. Digrama de sequencia,
<https://pt.wikipedia.org/wiki/Diagrama_de_sequ%C3%AAncia>, Acesso em
26/04/2018.
8. Sistema Visual Studio, <https://www.visualstudio.com/pt-br/>, Acesso em
11/05/2018
9. Sistema My SQL, <https://www.mysql.com/>, Acesso em 11/05/2018
10. Sistema Astah,<http://astah.net/>, Acesso em 11/05/2018