E-cidadão

(1)

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

(2)

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

(3)

(4)

IGOR ALEX AMORIM MARTINS LAMEIRÃ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

(5)

(6)

AGRADECIMENTOS

A Deus, que sempre iluminou a minha cami-nhada.

A minha Orientadora Helga Dolorico Balbi pe-lo estímupe-lo 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.

(7)

“A Escola é uma arena onde grupos sociais lutam por legitimidade e poder”.

(8)

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.

(9)

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

(10)

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

(11)

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

(12)

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.

(13)

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

(14)

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 pareceseto-res 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 sissis-tema 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ónegó-cio. As seguintes regras de negócio foram identificadas para o sistema proposto neste trabalho:

(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á conNes-ter 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:

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

11 – O sistema emite um aviso que o usuário foi cadastrado com sucesso.

Número 7:

Número 8:

1 – O usuário escolhe a opção <Cancelar>. 2 – A operação é cancelada.

Número 10:

Pós-condição:

Os dados do ator deverão estar gravados com sucesso no sistema. Atores:

(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:

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

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

10 – Os dados do usuário é alterado. 11 – O sistema volta para pagina anterior. Fluxo de eventos secundário:

Número 6:

Os novos dados do usuário deverão ser alterados com sucesso. Atores:

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:

O usuário deve ser removido no sistema. Atores:

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.

15 – O sistema emite um aviso que o usuário foi cadastrado com sucesso. 16 – O sistema volta para a página inicial.

Número 11:

Número 12:

1 – O usuário escolhe a opção <Cancelar>. 2 – O sistema volta para página inicial. Número 14:

3 – O sistema volta para página de preenchimento. Pós-condição:

O relato estar gravado com sucesso no sistema. Atores:

(32)

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:

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.

10 – Os dados do Relato é alterado. 11 – O sistema volta para pagina anterior. Fluxo de eventos secundário:

Número 6:

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:

O usuário deve ter alterado o status do relato no sistema. Atores:

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.

8 – O sistema emite um aviso que o usuário foi cadastrado com sucesso. 9 – O sistema volta para a página inicia.

Número 4:

Número 5:

1 – O usuário escolhe a opção <Cancelar>. 2 – O sistema volta para página de inicial. Número 7:

(36)

A categoria deve ser gravada com sucesso no sistema. Atores:

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:

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

Número 3:

Os novos dados de categoria deverão ser alterados com sucesso. Atores:

(38)

Regra de Negócio:

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:

3 – O sistema volta para página inicial. Número 6:

(39)

A categoria deve ser removida no sistema. Atores:

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.

Número 6:

(40)

Pós-condição:

O estado deve ser gravado com sucesso no sistema. Atores:

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:

(41)

Os dados do Estado devem estar disponíveis para consulta. Atores:

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.

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:

(42)

2 – O usuário concerta os dados incorretos. 3 – O sistema verifica se há algum novo erro. Número 8:

Os novos dados de estado deverão ser alterados com sucesso. Atores:

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:

(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:

Casos de uso – Manter Município (Cadastrar Município)

--- Objetivo:

Cadastrar no sistema um novo Município. Pré-condição:

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.

(44)

Número 9:

Número 10:

Pós-condição:

O Município deve ser gravado com sucesso no sistema. Atores:

Um usuário só poderá cadastrar se estiver autenticado.

Casos de uso – Manter Município (Consultar Município)

--- Objetivo:

(45)

Pré-condição:

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:

Os dados do Município devem estar disponíveis para consulta. Atores:

O Responsável. Regra de Negócio:

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

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.

(46)

5 – O usuário altera seus dados.

Número 6:

Os novos dados de Município deverão ser alterados com sucesso. Atores:

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)

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:

O Município deve ser removido no sistema. Atores:

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)

(52)

(53)

(54)

(55)

(56)

(57)

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

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

(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

(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

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

(67)

Figura 29: Tela de inclusão (cadastro) 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

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

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

(72)

(73)

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

(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