76
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

UNIVERSIDADE FEDERAL FLUMINENSE IGOR ALEX ......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

  • 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

Dedico este trabalho aos meus pais.

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.

“A Escola é uma arena onde grupos sociais

lutam por legitimidade e poder”.

Dinair Leal da Hora

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.

51

Figura 5: Diagrama de Sequencia (Categoria)

52

Figura 6: Diagrama de Sequencia (Status)

53

Figura 7: Diagrama de Sequencia (Estado)

54

Figura 8: Diagrama de Sequencia (Histórico de Relato)

55

Figura 9: Diagrama de Sequencia (Município)

56

Figura 10: Diagrama de Sequencia (Relato)

57

Figura 11: Diagrama de Sequencia (Pessoa)

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

67

Figura 29: Tela de inclusão (cadastro) de cidadão

Figura 30: Tela de edição de cidadão

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).

71

Figura 37: Tela de lista de relato

72

Figura 38: Tela de inclusão de relato

73

Figura 39: Tela de edição de relato

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