Projecto Final - Pedro - Dombele - V - Final

INSTITUTO SUPERIOR DE TECNOLOGIAS DE INFORMAÇÃO
E COMUNICAÇÃO
SISTEMA DE GESTÃO DE INFORMAÇÃO PARA

ADMINISTRAÇÃO DO DISTRITO URBANO DO RANGEL
TRABALHO DE FIM DE CURSO DE LICENCIATURA EM

ENGENHARIA INFORMÁTICA
AUTOR: PEDRO JOÃO DOMBELE
Luanda, 2018
INSTITUTO SUPERIOR DE TECNOLOGIAS DE INFORMAÇÃO
E COMUNICAÇÃO
SISTEMA DE GESTÃO DE INFORMAÇÃO PARA

ADMINISTRAÇÃO DO DISTRITO URBANO DO RANGEL
TRABALHO DE FIM DE CURSO DE LICENCIATURA EM

ENGENHARIA INFORMÁTICA
AUTOR: PEDRO JOÃO DOMBELE
ORIENTADOR: MSc. WALBER MENGANA CUESTA
CURSO: ENGENHARIA INFORMÁTICA
Luanda, 2018
AGRADECIMENTOS
Em primeiro lugar a Deus, que sempre me orientou. À toda a minha família e amigos, por
me darem sempre força nos momentos mais difíceis para que eu não desviasse do meu
objetivo.
A todos os professores pelo acompanhamento, orientação e amizade, também a todos os

colegas, que estiveram presentes ao longo desses anos de formação, nos bons e maus
momentos.
I
DEDICATÓRIA
Dedico o meu trabalho de conclusão do curso no Instituto Superior de Tecnologia de
Informação e Comunicação à minha querida mãe, como forma de agradecimento por todo
incentivo, paciência e suporte para o meu sucesso. Como primeiro passo para a realização
de tudo que auguro no futuro.
II
RESUMO
A inovação tecnológica tem se tornado cada vez mais presente no mercado mundial e sua
participação nos resultados econômicos e desenvolvimento dos países é irrefutável, as
tecnologias representam um fator determinante para melhorar a performance das
organizações. A administração do distrito urbano do Rangel é uma instituição pública que
tem como foco a área social. Observou-se que a instituição tem passado por muitas
dificuldades para a gestão das suas informações e consequentemente afeta o processo
de atendimento aos munícipes, que é feita de forma lenta e manual. Factos que têm
causado inúmeros constrangimentos e influenciando na qualidade do trabalho. A partir
dessa observação surgiu a ideia de desenvolver este trabalho como proposta para
informatizar o processo de gestão das informações da instituição, através de um aplicativo
web, facilitando a gestão das informações dos munícipes, acesso aos serviços
disponibilizados e também viabilizar o processo de atendimento dos munícipes de forma
fácil e rápida.
Palavras chave: administração distrital, atendimento, aplicativo web, gestão de

informação.
III
Abstract
Technological innovation has become increasingly present in the world market and its
participation in the economic results and development of the countries is irrefutable, the
technologies are a determining factor to improve the performance of the organizations. The
administration of Rangel's urban district is a public institution that focuses on the social
area. It has been observed that the institution has experienced many difficulties in
managing its information and in the service to the citizens, which is done slowly and
manually. Factors that have caused numerous constraints and influencing the quality of
work. From this observation came the idea of developing this work as proposal to
computerize the process of information management of the institution, through a web
application. Facilitating the management of the information of the citizens, access to the
services available and also enabling the process of attending to the householders in an
easy and fast way.
Keywords: district administration, attendance, information management, web application.
IV
ÍNDICE
INTRODUÇÃO ................................................................................................................ 1
CAPÍTULO 1: FUNDAMENTAÇÃO TEÓRICA ................................................................ 5
1 Introdução ao capítulo .......................................................................................... 5
1.1 Conceitos associados ao domínio do problema ................................................... 5
1.2 Estado da arte ...................................................................................................... 6
1.2.1 Campo internacional ...................................................................................... 6
1.2.2 Campo nacional ............................................................................................. 8
1.3 Metodologia de desenvolvimento de software ..................................................... 9
1.3.1 Metodologias Pesadas .................................................................................. 9
1.3.2 Metodologias Ágeis ....................................................................................... 9
1.4 Ferramentas e Tecnologias ................................................................................ 11
1.4.1 Sublime Text 3 – Editor de texto .................................................................. 12
1.4.2 XAMPP 7.0.15 ............................................................................................. 13
1.4.3 Sistema gestor de base de dados MySQL 8.0.13........................................ 13
1.4.4 Visual Paradigm 13.1................................................................................... 13
1.4.5 HTML 5 – Linguagem de marcação de hipertexto ....................................... 14
1.4.6 CSS 3 – Folhas de estilo ............................................................................. 14
1.4.7 JavaScript – Linguagem de programação para o lado cliente ..................... 15
1.4.8 Laravel 5.5 ................................................................................................... 15
1.4.9 Bootstrap 3 .................................................................................................. 16
1.4.10 PHP 7.0 ....................................................................................................... 16
1.4.11 Linguagem Unificada de Modelagem (UML) ............................................... 16
1.5 Conclusões parciais ........................................................................................... 17
CAPÍTULO 2. CARACTERÍSTICAS DO SISTEMA ....................................................... 18

2 Introdução ao capítulo............................................................................................ 18
2.1 Modelagem do negócio ...................................................................................... 18
V
2.1.1 Atores e trabalhadores de Negócio ............................................................. 18
2.2 Modelo conceitual e descrição do negócio......................................................... 19
2.2.1 Diagrama de Caso de Uso do Negócio ....................................................... 20
2.2.2 Descrição do Diagrama de Caso de Uso de Negócio.................................. 21
2.2.3 Diagrama de classes com estereótipos web (Descrição) ............................ 22
2.3 Modelagem do Sistema...................................................................................... 23
2.3.1 Requisitos funcionais ................................................................................... 24
2.3.2 Requisitos não funcionais ............................................................................ 25
2.4 Modelo de casos de uso do sistema .................................................................. 27
2.4.1 Casos de Uso .............................................................................................. 27
2.4.2 Atores do Sistema ....................................................................................... 27
2.5 Diagrama de caso de uso do sistema ................................................................ 28
2.6 Descrição de Casos de Uso do Sistema ............................................................ 29
2.7 Conclusão parcial ............................................................................................... 33
CAPÍTULO 3. DESENHO, IMPLEMENTAÇÃO E PROVAS DO SISTEMA .................. 34

3 Introdução ao capítulo ........................................................................................ 34
3.1 Diagrama de classes .......................................................................................... 34
3.1.1 Modelo Lógico ............................................................................................. 34
3.2 Modelo de Base dados....................................................................................... 35
3.2.1 Modelo físico de dados ................................................................................ 35
3.3 Diagrama de Componentes ............................................................................... 36
3.4 Padrões de arquitetura ....................................................................................... 37
3.4.1 Modelo Vista Controlador (MVC) ................................................................. 37
3.5 Padrões de Desenho.......................................................................................... 39
3.5.1 Padrão (GRASP) ......................................................................................... 39
3.6 Modelo de despliegue (implantação).................................................................. 41
3.7 Estândares de codificação ................................................................................. 43
VI
3.8 Validação do sistema ......................................................................................... 43
3.8.1 Estratégia de Prova ..................................................................................... 44
3.8.2 Provas unitárias ........................................................................................... 44
3.8.3 Provas funcionais ........................................................................................ 46
3.8.4 Resultados das provas ................................................................................ 49
3.9 Conclusões parciais ........................................................................................... 50
CONCLUSÕES ............................................................................................................. 51
RECOMENDAÇÕES ..................................................................................................... 52
REFERÊNCIAS BIBLIOGRÁFICAS .............................................................................. 53
ANEXOS ....................................................................................................................... 57
VII
ÍNDICE DE FIGURAS
Figura 2-1 - Modelo conceitual do negócio. .................................................................... 20

Figura 2-2 - Diagrama de casos de uso do negócio ........................................................ 21
Figura 2-3 - Diagrama de classes com estereótipo web…………………………………….23
Figura 2-4 - Diagrama de casos de uso do sistema ........................................................ 28
Figura 3-1 - Diagrama de classes ................................................................................... 36
Figura 3-2 - Modelo lógico de banco de dados ............................................................... 37
Figura 3-3 - Diagrama de Componentes ......................................................................... 38
Figura 3-4 - Arquitetura modelo-vista-controladora. ........................................................ 39
Figura 3-5 - Fragmento do código do padrão experto na classe municipe. ..................... 40
Figura 3-6 - Fragmento do código criar pedidos.…………………………………………….. 41
Figura 3-7 - Fragmento do código inserir funcionarios……………………………………… 42
Figura 3-8 - Modelo de despligue (implementação) ........................................................ 43
Figura 3-9 - Prova de caixa branca(método store) .......................................................... 46
Figura 3-10 - Grafo de fluxo associado a método store .................................................. 46
Figura 3-11 - Gráfico dos resultados das provas……………………………………………. 50
VIII
ÍNDICE DE TABELAS
Tabela 1-1 – Comparação entre metodologias. ................................................................ 9

Tabela 2-1 – Atores do negócio ...................................................................................... 19
Tabela 2-2 – Trabalhadores do negócio .......................................................................... 19
Tabela 2-3 – DCUN fazer pedido .................................................................................... 21
Tabela 2-4 – DCUN gerenciar documentos..................................................................... 21
Tabela 2-5 – DCUN Atender Pedido ............................................................................... 22
Tabela 2-6 – Requisitos funcionais ................................................................................. 25
Tabela 2-7 – Atores do sistema....................................................................................... 27
Tabela 2-8 – DCUS – Autenticar usuário ........................................................................ 29
Tabela 2-9 - DCUS – Gerenciar Munícipes…………………………………………………..30
Tabela 2-10 – DCUS – Gerenciar pedido. ....................................................................... 31
Tabela 2-11 – DCUS – Gerenciar usuários. .................................................................... 32
Tabela 3-1 – Provas de caixa preta................................................................................. 46
IX
Lista de Abreviaturas
BI…………………………………………………………………………….Business Intelligence
HTML……………………………………………………………….Hypertext Markup Language
HTTP………………………………………………………………. Hypertext Transfer Protocol
HTTPS……………………………………………………..Hypertext Transfer Protocol Secure
JS………………………………………………………………………………………..JavaScript
MVC………………………………………………………………………. Model View Controller
MSF……………………………………………………………… Microsoft Solution Framework
Openup .......................................................................................... Open Unified Process
PHP………………………………………………………………………Hypertext Preprocessor
PNG ........................................................................................ Portable Network Graphics
PSR…………………………………………………………. PHP Standards Recommendation
RE…………………………………………………………………..Requirements Enginneering
RUP…………………………….......................................................Rational Unifield Process
RF…………………………………………………………………………….Requisito Funcional
RNF……………………………………………………………………..Requisito Não Funcional
RUP ............................................................................................. Rational Unified Process
SQL.………………………………………………………………...Structured Query Language
UML ............................................................................................. Unified Model Language
XP .................................................................................................. Extreme Programming
X
INTRODUÇÃO
A informação permeia todos os espaços sociais e é componente de todas as ciências e
atividades humanas, considerado o insumo básico necessário no processo de
desenvolvimento pessoal e social, está no alicerce da atual sociedade da informação e do
conhecimento. Os estudos acerca dos processos de sua geração, transmissão,
assimilação, transformação e uso, visam criar mecanismos para otimizar seu
gerenciamento, utilizando para tal, as tecnologias de informação e comunicação
disponíveis.
As primeiras atividades relacionadas à atividade de gestão de informação diziam respeito

sobre a natureza física, suporte dos documentos com o objetivo de reduzir o montante
caracterizado como excesso ou sem valor e maximizar a utilização daquilo que realmente
fosse útil. Assim como em grande parte das atividades exercidas na sociedade, a área
evoluiu com o passar do tempo, principalmente nos últimos anos, com o auxílio das
inovações tecnológicas, em especial por conta do advento das tecnologias da informação
(Araújo, 2010).
Gestão de informação é a gestão dos processos e sistemas que criam, adquirem,

organizam, armazenam, distribuem e utilizam informações. O objetivo da gestão de
informação é ajudar as pessoas e organizações no acesso, processo e uso da informação
de forma eficiente e eficaz (Detlor, 2010).
As administrações dos distritos urbanos são instituições públicas onde são geradas
grandes quantidades de informações, essas informações devem ser tratadas da melhor
forma possível para que atendam as necessidades dos munícipes e conquistem a
confiança pública e a credibilidade, aumentem a produtividade e reduzam os custos da
administração pública, tornando-as mais eficientes.
A gestão de informação no âmbito do setor público tem como objetivo assegurar que a
informação seja administrada de forma efetiva e eficiente para promover a qualidade da
governação nesse setor.
A Administração do Distrito Urbano do Rangel é uma instituição publica vocacionada a

prestação de serviços aos munícipes, pois tem uma alta demanda de munícipes, porém
todas as suas informações são processadas de forma manual. Não existe segurança no
armazenamento das informações como também dificuldades em obter as informações dos
munícipes por conta dos amontoados de papeis, o que tem causado grandes
1
constrangimentos e perda de informação. Pois está constituída pelas seguintes áreas:
secretaria, fiscalização, DRM, procuradoria e cultura, entre as áreas descritas o trabalho
vai se focar na secretaria onde não existe um sistema personalizado para gestão de
informação. Provendo informação de qualidade, de forma a proporcionar melhores
serviços aos munícipes e auxiliar a administração local que enfrenta desafios exigentes
ao nível da capacidade de resposta.
Tendo em conta o que se levantou anteriormente se identifica como problema de

investigação: Como melhorar a gestão de informação agregado ao atendimento dos
munícipes do Distrito Urbano do Rangel?
Atendendo tudo o que foi identificado, tem definido como objeto de estudo: os processos
de gestão de informação distrital.
Para a presente investigação o campo de acção é: gestão de informação dos munícipes

para Administração do Distrito Urbano do Rangel.
Para dar resposta ao problema identificado, se define como o objectivo geral deste
trabalho: Desenvolver um sistema informático de gestão de informação dos munícipes
para Administração do Distrito Urbano do Rangel, que visa melhorar o atendimento e
controlo das informações.
Do objetivo geral acima citado se identificaram os seguintes objectivos específico:
1. Definir um esboço teórico da investigação sobre o estudo relacionado ao

desenvolvimento de aplicações de gestão de informação distrital.
2. Levantar aspectos técnicos e organizacionais (requisitos funcionais e não

funcionais) do sistema de gestão de informação dos munícipes para Administração
do Distrito Urbano do Rangel.
3. Desenhar o sistema informático de gestão de informação dos munícipes para

Administração do Distrito Urbano do Rangel.
4. Implementar o sistema informático de gestão de informação dos munícipes para

5. Validar o sistema informático de gestão de informação dos munícipes para

Para dar solução ao problema levantado se propõe as seguintes tarefas de investigação:
2
1. Revisão de documentos e entrevistas na secretaria da Administração do Distrito
Urbano do Rangel.
2. Caracterização dos sistemas no âmbito nacional e internacional de gestão de

informação distrital.
3. Caracterização da metodologia, e das ferramentas e tecnologias de

desenvolvimento do sistema informático de gestão de informação distrital.
4. Obtenção dos requisitos funcionais e não funcionais que dão solução ao problema
de investigação.
5. Desenho dos modelos do sistema de acordo com a metodologia de

desenvolvimento de software seleccionado.
6. Implementação do sistema web de gestão de informação dos munícipes para

7. Validação do sistema de gestão de informação dos munícipes para Administração

Ideia a defender: Com o desenvolvimento do sistema de gestão de informação dos

munícipes para Administração do Distrito Urbano do Rangel poder-se-ia melhorar o nível
de qualidade de atendimento e o controlo das informações dos munícipes.
Para o desenvolvimento de investigação se empregaram os seguintes métodos de

investigação:
Métodos teóricos:
Analítico-Sintético: A aplicação deste método permitiu à busca, investigação e

análise dos documentos necessários, para entender o processo que se leva a cabo
para a gestão de informação na Administração do Distrito Urbano do Rangel.
Análise Histórico-Lógico: O estudo dos antecedentes e elementos de

investigação referidos acima permitiu ter ideias sobre o processo de gestão de
informação no qual a instituição está vocacionada.
Métodos empíricos:
Entrevista: Realizaram-se a trabalhadores e munícipes, que se vêm imersos no

processo de gestão das informações e atendimento, a fim de recolher mais dados
que possibilitam ter uma visão de algumas funcionalidades do sistema.
3
Observação: Com o propósito de adquirir as informações de como é realizado o
processo de gestão de informação dos munícipes levado a cabo na Administração
Resumo de cada capítulo:
O presente trabalho é composto por três capítulos, a seguir é descrito os principais

aspectos abordados em cada um dos capítulos.
Capítulo I: Fundamentação Teórica. Neste capítulo se especificam os principais

conceitos relacionados com o tema, realiza-se o estudo do estado da arte a nível nacional
e internacional sobre os sistemas de gestão de informação distrital. Como também as
ferramentas, metodologias e tecnologias a utilizar durante o desenvolvimento do sistema.
Capítulo II: Características do Sistema. Neste capítulo vai servir de forma mais
específica, para explicar os processos necessários que levam a um resultado final. Com
estas explicações terão todo princípio para descrever em um sistema informático,
utilizando diagramas e representações das entidades principais que envolvem no
processo (atores). Definem-se os requisitos funcionais e não funcionais do sistema.
Capítulo III: Desenho, implementação e provas do sistema. Neste capítulo se abordam

aspectos relacionados com o desenho e implementação do sistema em base a arquitetura
de desenvolvimento de software. Também se documentam as provas de software ao
sistema, realizando-se as provas de software para verificar que responde a um correto
funcionamento, garantir a confidencialidade e detectar possíveis falhas no sistema.
4
CAPÍTULO 1: FUNDAMENTAÇÃO TEÓRICA

1 Introdução ao capítulo
Este capítulo apresentará a análise do problema envolvido, bem como os conceitos de

negócios que serão utilizados durante o desenvolvimento deste trabalho. Apresentam-se
também um estudo das principais ferramentas e tecnologias que serão utilizadas para o
desenvolvimento da presente investigação, assim como as metodologias de
desenvolvimento.
1.1 Conceitos associados ao domínio do problema

Atendimento é o momento da verdade, é nele que acontece a interação entre o cliente e
a empresa, estabelecendo uma relação de confiança, fidelidade, respeito e que pode ser
lucrativa para ambos (Leal, 2014).
Administração distrital consiste na divisão de uma cidade em municípios menores que,

por sua vez, se subdividem em bairros, também subordinados ao poder de sua prefeitura
(Dicio, 2016).
Gestão é a ação e o efeito de administrar ou dirigir um determinado negócio. Como gestão

também se subentende que é o que leva a organizar, dispor, dirigir e dar uma ordem para
que se consiga um determinado objetivo. Ao tratar do termo deve-se mencionar que a
gestão é uma tarefa que requer esforço, alguns recursos, consciência e boa vontade para
que se possa terminar esta tarefa. Utiliza-se a gestão para orientar a resolver um problema
específico, a concretizar um projeto. A gestão também é usada para referir-se a direção e
administração que se realiza em uma organização, empresa ou negócio (Cavalcanti,
2017).
Informação: é o resultado do tratamento dos dados existentes acerca de alguém ou de

alguma coisa. A informação aumenta a consistência e o conteúdo cognoscível dos dados.
O propósito da informação é o de habilitar a instituição a alcançar seus objetivos pelo uso
eficiente dos recursos disponíveis, nos quais se inserem pessoas, materiais,
equipamentos, tecnologia, dinheiro, além da própria informação. A eficiência na utilização
da informação dos recursos informação é medida pela relação do custo para obtê-la e o
valor do benefício derivado do seu uso (Cruz, 2008).
5
Gestão de informação: é a gestão dos processos e sistemas que criam, adquirem,

organizam, armazenam, distribuem e utilizam informações. O objetivo da gestão da
informação é ajudar as pessoas e organizações no acesso, processo e uso da informação
de forma eficiente e eficaz (Detlor, 2010).
A finalidade da gestão de informação é oferecer mecanismos que permitem a organização

adquirir, produzir e transmitir, ao menor custo possível, dados e informações com uma
qualidade, exatidão e atualizada suficiente para servir a os objectivos da organização
(Flores, 2014).
Sistema de gestão de informação: Um sistema de gestão de informação é uma

infraestrutura que suporta o fluxo de informação interno e externo a uma organização. Eles
fornecem aos usuários finais administrativos produtos de informação que apoiam grande
parte de suas necessidades de tomada de decisão do dia a dia. Os sistemas de gestão de
informação fornecem uma diversidade de informações pré especificadas (relatórios) e
exibições em vídeo para a administração que podem ser utilizadas para ajudá-los a tomar
tipos estruturados mais eficazes de decisões diárias (LAUDON, 2005).
1.2 Estado da arte

A seguir se expõe uma breve descrição de alguns sistemas de gestão de informação
referente à gestão de atendimento distrital, com o propósito de tirar conclusões que
permitam guiar a proposta de solução para o cumprimento dos objetivos traçados.
1.2.1 Campo internacional

• Urbem - software de gestão governamental
O Urben é um software de gestão governamental gratuito e possui vários módulos, que
objetiva a desburocratização e compartimentos de informações publicas de forma
automatizada visando normatizar processos da administração municipal.
A tecnologia é baseada em nuvem (cloud), tornando o acesso simples e seguro. Pode ser
acessado de qualquer dispositivo como computadores, tablets ou smartphones, assim,
utiliza de forma colaborativa e materializa a coleta de dados que é distribuída de acordo
com o perfil de cada departamento. O Urben garante aos gestores públicos municipais
economizar, promovendo a tecnologia para tomar os processos mais simples (URBEM,
2018).
Entre os seus principais recursos do Urbem destacam-se os seguintes:
6
• Cadastro de munícipes;
• Cadastro de Empresas
• Procolos e normas da Administração;
• Relatório de actividades.
• Gestão pública municipal - sistema da gestão pública municipal

É um software de origem brasileira de gestão pública municipal, com meios considerados
inovativos, abordando não somente na capacitação continuada da gestão, mas no
aperfeiçoamento constante dos servidores públicos em geral, como um meio de garantir
total aderência aos serviços.
O sistema é dividido em módulos e possuem estruturas baseadas inteiramente em

plataforma Web, isentando de qualquer modificação ou investimento em infraestrutura
tecnológica do município.
O sistema possibilita o atendimento ao cidadão que permite que o cidadão usufrua dos
benefícios e serviços fornecidos pelo município por meio da internet. Esse é o objetivo
deste sistema, que pretende facilitar a vida dos munícipes, evitando seu deslocamento até
a administração do município. O sistema da foi desenvolvimento em Ruby on Rails, o
banco de dados PostgreSQL (ANDRACOM, 2018).
Dentre as características podemos encontrar:

• Gestão de Protocolos;
• Cadastro ao Cidadão;
• Cadastro a empresas;
• Emissão de Alvará via internet;
• Gestão Eletrônica de Documentos.
• Cidadão Web
Sistema web com o objectivo de facilitar o acesso dos cidadãos aos serviços
disponibilizados pelo município, como emissão de guias de pagamentos, emissão de
documentos sem a necessidade de se deslocar até a administração municipal.
O uso do cidadão web possibilita, por exemplo, a fundamentação para a criação de uma
estratégia a fim de aumentar a eficiência na fiscalização e, consequentemente, elevar a
receita arrecadada pelo município. Possibilita também a visão estratégica para melhorar a
aplicação dos recursos públicos (BETHA, 2018).
7
• Cadastrar cidadão;
• Consulta da situação do cidadão junto á entidade;
• Emissão de guias de pagamentos;
• Consulta de documentos;
• Geração de ITBI;
• Emissão de alvaras.
1.2.2 Campo nacional

• Portal do Munícipe
O portal do munícipe, uma página na internet criado pelo Ministério das Finanças, que visa
ajudar a melhorar os serviços públicos prestados às populações e aumentar a arrecadação
de receitas e poupar fundos com material gastável.
O sistema informático facilita a prestação de serviços pelas administrações, ao mesmo

tempo que permite maior celeridade e maior controlo, e conta com uma interface fácil de
usar para qualquer usuário (MINFIN, 2019).
• Cadastro dos munícipes;

• Validação de documentos;
• Consultar protocolo;
• Emissão de Licença de Obras;
• Emissão de Atestado de Residência;
• Emissão de Licença Comercial.
Os sistemas estudados a nível nacional e internacional se constatou que as mesmas

apresentam funcionalidades úteis que se tomaram como referência para a proposta de
solução, porém não foram utilizados por não satisfazer todas as necessidades do negocio
e também porque não se fez levantamentos de requisitos pensando nos problemas
existentes da instituição. A partir das análises realizadas se conclui a necessidade de
desenvolver um sistema informático para gestão de informação para a Administração do
Distrito Urbano do Rangel.
8
1.3 Metodologia de desenvolvimento de software

Hoje em dia, sabe-se que é necessária a utilização de uma metodologia de trabalho.
Fornecendo um roteiro, um processo dinâmico e interativo para desenvolvimento
estruturado de projetos, sistemas ou software, visando à qualidade e produtividade dos
projetos (DEVMEDIA, 2018).
Uma metodologia de desenvolvimento de software se define como um conjunto de

procedimentos, técnicas, ferramentas e um suporte documentário que ajuda na construção
de um software. (Pressman, 2005).
Uma metodologia define estados, etapas e fases de desenvolvimento. Também define

tarefas, actividades. As metodologias podem ser pesadas ou ágeis.
É objetivo de uma metodologia definir de forma clara “quem” faz “o que”, “quando”, “como”,
e até mesmo “onde”, para todos os que estejam envolvidos diretamente ou não com o
desenvolvimento de software (DEVMEDIA, 2018).
1.3.1 Metodologias Pesadas

Nessa metodologia inicialmente procura-se compreender completamente o problema, a
ser resolvido, depois projeta-se soluções que atendam a todos os requisitos e restrições.
Feito isso inicia-se a implementação do projecto e quando toda etapa de implementação
é concluída verifica-se junto ao cliente se a solução atende aos requisitos estabelecidos e
por fim é efetuada a entrega do produto (Kroll, 2003).
Tipos de metodologias pesadas: RUP, Rational Unifield Process (Processo Unificado da

Rational), Iconix, MSF, Microsoft Solution Framework (Framework de Solução da
Microsoft).
1.3.2 Metodologias Ágeis

Métodos de desenvolvimento de software que aplicam o desenvolvimento iterativo,
empregam o planejamento adaptativo, promovem a entrega incremental, incluem outros
valores e práticas que encorajam a agilidade a resposta rápida e flexível às mudanças.
Tipos de metodologias ágeis: XP, extreme Programming (Programação Extrema),
OpenUp, SCRUM (Pressman, 2011).
A seguir se mostra uma tabela onde se faz a comparação entre as metodologias ágeis e
as metodologias tradicionais.
9
Tabela 1-1 - Comparação entre metodologias.
Comparação Metodologias Tradicionais Metodologias Ágeis

Número de Grupos grandes e possivelmente Grupos pequenos (<10 integrantes)
integrantes. distribuídos. e trabalhando no mesmo sítio.
Cliente. O cliente não forma parte da equipa de O cliente faz parte da equipa de
desenvolvimento, só está presente desenvolvimento.
através de reuniões planificadas.
Mudanças. Certa resistência a mudanças. Podem aparecer mudanças no
processo de desenvolvimento e
faze-las se necessário.
Documentação. Os projectos apresentam grande A documentação se gera quando
quantidade de documentação e de há necessidade e de maneira geral
forma detalhada. não é rigorosa em sua estrutura.
Metodologia a utilizar
O software será desenvolvido por meio da metodologia OpenUp. OpenUp é uma
metodologia de software baseada em RUP, que inclui desenvolvimento interativo e
incremental, caso de uso e cenários na direcção do desenvolvimento, gerenciamento de
riscos e a abordagem de arquitetura-centrica. OpenUp é uma metodologia livre de
ferramentas e de baixo formalismo que pode ser estendido a uma variada gama de tipos
de projectos e não apenas desenvolvimento de software (Kroll e MCSAAK, 2006).
OpenUp fornece as melhores praticas de uma variedade de opiniões de líderes em

desenvolvimento de software e de vasta comunidade de desenvolvimento de software que
cobre um conjunto diverso de perspetivas e necessidades de desenvolvimento (Kroll e
MCSAAK, 2006). Contém um conjunto mínimo de práticas e regras que ajudam no
desenvolvimento de um software a realizar um produto de alta qualidade de uma forma
eficiente.
Algumas razões para escolha da metodologia:

1. Processo iterativo e incremental que é o mínimo, completo e extensível;
2. Evita a elaboração de documentação, diagramas e iterações requeridos no RUP;
3. Permite detectar erros adiantados a través de um ciclo iterativo;
4. Por ser uma metodologia ágil e ter um enfoque centrado ao cliente e com iterações
curtas.
10
OpenUp foca-se nas seguintes disciplinas: Requerimentos, Arquitetura,

Desenvolvimento, Prova, Administração de Configuração, Mudanças e Administração de
Projecto (Gimson e Outros, 2012).
• Arquitetura (Architecture): O propósito é alcançar evolucionar a uma arquitetura

robusta para o sistema. Explica como criar uma arquitetura a partir de
requerimentos arquitetonicamente (estruturalmente) importantes. Em disciplina de
desenvolvimento onde se construem a arquitetura.
• Desenvolvimento (Development): Explica como desenhar e implementar uma

solução técnica que esta conforme a arquitetura e sustente os requerimentos.
• Prova (Test): Explica como prover retroalimentação sobre a madures do sistema

desenhado, implementando, executando e avaliando provas. É iterativa e
incremental. Aplica a estratégia de “prova mais rápido possível e com a maior
frequência possível” para replicar os riscos o mais rápido possível dentro do ciclo
de vida de projecto.
• Administração de configuração e cambio (Configuration and change

management): Explica como controlar as mudanças dos artefactos, assegurando
uma evolução sincronizada do conjunto de produtos (Work Products) que compõe
um sistema de software. Esta disciplina se expande durante todo o ciclo de vida.
• Administração de Projecto (Project Management): Explica como entregar,

ajudar e apoiar a equipa, ajudando a manejar os riscos obstáculos que se
encontrem a construir o software (Gimson e Outros, 2012).
Depois de definida a metodologia de desenvolvimento, é necessário definir as ferramentas

de desenvolvimento para a solução, esse assunto será abordado de forma profunda no
próximo ponto.
1.4 Ferramentas e Tecnologias

Actualmente, existe uma grande revolução das tecnologias de informação, onde os
avanços em novas tecnologias são destinados a fornecer solução sob medida para as
necessidades do usuário final. A integração ou interligação de ferramentas de
desenvolvimento de tecnologias, surgiu como uma alternativa que permite desembrulhar
aplicações. Eles também permitem resolver problemas actuais de uma organização,
11
facilitando, assim, a interação do usuário com os sectores envolvidos no problema

(Gonçalves, 2015).
1.4.1 Sublime Text 3 – Editor de texto

Sublime Text é um editor de texto e editor de código fonte é escrito em C ++ e Python para
plugins. Originalmente desenvolvido como uma extensão do Vim, acabou criando sua
própria identidade, razão pela qual ainda mantém um modo de edição do tipo vi chamado
modo vintage. Pode ser baixado e avaliado gratuitamente. No entanto, não é um software
livre ou de código aberto, uma licença deve ser obtida para seu uso continuado, embora a
versão de avaliação esteja totalmente funcional e não tenha uma data de expiração. Está
disponível para OS X, Windows e Linux. O sublime Text usa um kit de ferramentas de
interface do usuário personalizado, otimizado para velocidade e beleza, aproveitando a
funcionalidade nativa de cada plataforma. Tem um poderoso API desdobramento baseado
em Python. Junto com a API, ele possui um console Python integrado para interagir de
forma interativa em tempo real (Ecured, 2017).
Alguns dos recursos incluem:

• Mini mapa: consiste em uma prévia da estrutura do código, é muito útil para
percorrer o arquivo quando você conhece a estrutura dele.
• Seleção múltipla: faz uma seleção múltipla de um termo para diferentes partes do
arquivo. Muitas seleções permitem que você interactivamente mude várias linhas
de uma vez, renomeie facilmente as variáveis e manipule os arquivos mais
rapidamente.
• Split Edition: você pode editar os arquivos lado a lado ou dois locais no mesmo
arquivo e também quantas linhas e colunas desejar, aproveitando o desempenho
máximo do seu monitor widescreen ou usando vários monitores com várias janelas
e usando várias divisões em cada janela.
• Multi cursor: cria cursores com os quais se pode escrever texto arbitrário em
diferentes posições do arquivo.
• Multi layout: traz sete configurações de modelo que se pode escolher para editar
em uma única janela ou fazer uma divisão de até quatro janelas verticais ou quatro
janelas em uma grade.
• Suporte nativo para uma infinidade de linguagens: suporta originalmente 43
linguagens de programação e textos simples.
12
• Realce de sintaxe configurável: o realce de sintaxe é totalmente configurável por

meio de arquivos de configuração do usuário.
• Pesquisa dinâmica: pode-se pesquisar expressões regulares ou arquivos, projeto,
diretórios, uma conjunção deles ou todos de uma vez (Ecured, 2017).
1.4.2 XAMPP 7.0.15

XAMPP é um servidor independente de plataforma, de software livre, que consiste
principalmente na base de dados MySQL, o qual foi substituído pelo MariaDB, servidor
web Apache e os interpretadores para linguagens de script: PHP e Perl. O nome provem
da abreviação de X (para qualquer dos diferentes sistemas operativos), Apache, MariaDB,
PHP, Perl. É um método que torna extremamente fácil para os desenvolvedores a criar
um servidor web local para fins de teste.
O programa está liberado sob a licença GNU e atua como um servidor web livre, fácil de
usar e capaz de interpretar páginas dinâmicas. Atualmente o XAMPP está disponível para
Microsoft Windows, GNU/Linux, Solaris e MacOS (Apache , 2015)
1.4.3 Sistema gestor de base de dados MySQL 8.0.13

Um sistema gestor de base de dados (SGBD) é um programa ou conjunto de programas
que gerem e mantêm consistentes os dados armazenados em uma base de dados. As
principais funções que devem cumprir um SGBD se relacionam com a criação e
permanência da base de dados, o controle de acessos, a manipulação de dados de acordo
com as necessidades do usuário, o cumprimento das normas de tratamento de dados,
evitar redundâncias, inconsistências e manter a integridade (Bachman, 2015).
O MySQL é um sistema de gerenciamento de banco de dados (SGBD), que utiliza a

linguagem SQL (Linguagem de Consulta Estruturada, do inglês Structured Query
Language) como interface. É atualmente um dos sistemas de gerenciamento de bancos
de dados mais populares, com mais de 10 milhões de instalações pelo mundo.
O MySQL é um sistema gerenciador de banco de dados relacional de código aberto usado

na maioria das aplicações gratuitas para gerir suas bases de dados (DEVMEDIA, 2019).
1.4.4 Visual Paradigm 13.1

Segundo o site oficial do Visual Paradigm, o Visual Paradigm é uma ferramenta com várias
opções de modelagem com os diagramas da UML e que também oferece suporte a
diagramas de requisitos (Systems Modeling Language) SysML e a diagramas ER. A
13
ferramenta possui um bom ambiente de trabalho, o que facilita a visualização e

manipulação do projeto de modelagem. É uma ferramenta comercial e também oferece
suporte a transformações específicas para códigos-fonte de algumas linguagens de
programação como, por exemplo, C++ e Java (Paradigm, 2018).
Paradigm também oferece:

• Navegação intuitiva entre a escritura do código e sua visualização.
• Potente gerador de relatórios em formato PDF/HTML.
• Ambiente visualmente superior de modelagem.
• Sincronização de código fonte em tempo real.
Esta ferramenta CASE e multiplataforma, sua licença se encontra disponível de forma

gratuita só para fins académicos e não comerciais. Ademais brinda um completo conjunto
de ferramentas de equipas de desenvolvimento de software necessário para a captura de
requisitos, software de planificação e a modelagem de dados (Software, 2013).
Neste projecto utilizou-se essa ferramenta por possuir grande parte das ferramentas
necessárias para o desenvolvimento dos diagramas e por ser bastante intuitivo, fácil de
manusear e também por ser uma ferramenta não proprietária.
1.4.5 HTML 5 – Linguagem de marcação de hipertexto

O HTML, do inglês HyperText Markup Language (Linguagem de Marcação de Hipertexto),
é uma linguagem de marcação declarativa que permite criar páginas web a serem
renderizadas em navegadores web. Para se criar um arquivo HTML, que basicamente é
formado por um conjunto de tags (marcações) para definição da estrutura de uma página,
necessita-se de apenas um editor de texto ASCII (American Standard Code for Information
Interchange), que significa o Código Padrão Americano para o Intercâmbio de Informação.
Para se verificar a aparência da página gerada pelo código de marcação durante seu
desenvolvimento, pode-se utilizar qualquer navegador web (Silva, 2015).
1.4.6 CSS 3 – Folhas de estilo

CSS: trata-se de uma linguagem de folhas de estilo comumente usada para definir a
apresentação de documentos escritos em uma linguagem de marcação, normalmente
HTML (Duckett, 2015).
As folhas de estilo consistem em uma lista de regras que possuem seletores e um bloco
de declaração, onde cada uma dessas declarações refere-se a uma propriedade.
14
Provém a vantagem de separar o formato e o conteúdo de um documento, já que a

formatação é desenvolvida em uma outra página e é determinada uma ligação no
documento que adquire os estilos determinados na página externa. Possui uma sintaxe
bem simples, com uma série de termos em inglês que especificam todas as características
e estilos existentes em uma página (Lewis & Moscovitz, 2010).
1.4.7 JavaScript – Linguagem de programação para o lado cliente

JavaScript é uma linguagem de alto nível, dinâmica, interpretada e não tipada, conveniente
para estilos de programação orientados a objetos e funcionais. A sintaxe de JavaScript é
derivada da linguagem Java, das funções de primeira classe de Scheme e da herança
baseada em protótipos de Self.
JavaScript é a linguagem de programação da Web. A ampla maioria dos sites modernos
usa JavaScript e todos os navegadores modernos em computadores de mesa, consoles
de jogos, tablets e smartphones incluem interpretadores JavaScript, tornando-a a
linguagem de programação mais onipresente da história (Flanagan, 2015).
JavaScript faz parte da tríade de tecnologias que todos os desenvolvedores Web devem
conhecer:
• HTML, para especificar o conteúdo de páginas Web;

• CSS, para especificar a apresentação dessas páginas;
• JavaScript, para especificar o comportamento delas.
1.4.8 Laravel 5.5

Laravel é um framework PHP livre e open-source criado por Taylor B. Otwell para o
desenvolvimento de sistemas web que utilizam o padrão MVC (model, view, controller).
Algumas características proeminentes do Laravel são sua sintaxe simples e concisa, um
sistema modular com gerenciador de dependências dedicado, várias formas de acesso a
banco de dados relacionais e vários utilitários indispensáveis no auxílio ao
desenvolvimento e manutenção de sistemas (Laravel, 2018).
O Laravel utiliza-se de uma interface de linha de comando, chamada de Artisan CLI. Esta
interface permite realizar diversas ações na aplicação, dentre elas, a configuração de
ambiente, verificação de rotas, interação com aplicação e a criação de vários tipos de
arquivos, como: migrations, controller, etc. (Adriel, 2015).
15
1.4.9 Bootstrap 3
Bootstrap é uma framework web com código-fonte aberto para desenvolvimento de
componentes de interface e front-end para sites e aplicações web usando HTML, CSS e
JavaScript, baseado em modelos de design para a tipografia, melhorando a experiência
do usuário em um site amigável e responsivo (Bootstrap, 2018).
Tem como objetivo central fornecer ao usuário uma facilidade de desenvolvimento de

layouts pré-configurados, tanto para questão de produtividade como também da questão
da responsividade.
Customização, responsivo e documentação são as principais características do Bootstrap.

Pois a customização é rápida e fácil, responsividade torna o site mais responsivo e a
documentação conforme o site do desenvolvedor, mostra que é bem simples e prático de
aprender tornando a implementação fácil. Geralmente usado em frond-end, mas
atualmente é utilizado em back-end, pois suas ferramentas visuais tornam o visual dos
projetos avançados mais aperfeiçoado. Dessa forma, o usuário fica mais familiarizado com
o sistema.
Incluso em seu conjunto de recursos, se encontram o HTML 5, CSS 3, Jquery, Node,

JavaScript, Ajax. Dessa forma, ao baixar o pacote Bootstrap, não será mais preciso baixar
os plug-ins do Jquery por exemplo, pois já faz parte do pacote do Bootstrap (Beux, 2017).
1.4.10 PHP 7.0
PHP (Hypertext Preprocessor) é uma linguagem para criar conteúdos HTML. PHP pode
ser executado de três maneiras; em um servidor web, através da linha de comando ou
através de um cliente GUI. A linguagem pode ser executada em praticamente todos os
sistemas operacionais atuais e em vários servidores web, também suporta uma ampla
variedade de banco de dados e possui várias bibliotecas para executar processos comum,
uma página PHP geralmente consiste em uma página HTML com comandos PHP
embutidos nela. O servidor web processa os comandos PHP e envia para o navegador
(Niederaue, 2017)
1.4.11 Linguagem Unificada de Modelagem (UML)
A UML - Linguagem de Modelagem Unificada (do inglês, UML - Unified Modeling

Language) é uma linguagem-padrão para a elaboração da estrutura de projetos de
software. Ela poderá ser empregada para a visualização, a especificação, a construção e
16
a documentação de artefactos que façam uso de sistemas complexos de software. Em

outras palavras, na área de Engenharia de Software, a UML é uma linguagem de
modelagem que permite representar um sistema de forma padronizada (com intuito de
facilitar a compreensão pré-implementação).
A UML é adequada para a modelagem de sistemas, cuja abrangência poderá incluir desde
sistemas de informação corporativos a serem distribuídos a aplicações baseadas na Web
e até sistemas complexos embutidos de tempo real. É uma linguagem muito expressiva,
abrangendo todas as visões necessárias ao desenvolvimento e implantação desses
sistemas.
Os objetivos da UML são: especificação, documentação, estruturação para sub-

visualização e maior visualização lógica do desenvolvimento completo de um sistema de
informação (Booch, et al., 2012).
1.5 Conclusões parciais

Este capítulo apresentou os principais conceitos em volta do objeto de estudo, fez-se um
estudo e comparação entre os sistemas similares e a partir deles obteve-se uma ideia de
como um sistema de gestão deve funcionar.
Falou-se das metodologias, e depois de estudadas foi escolhida a metodologia OpenUp,

principalmente por ser uma metodologia ágil e adequada para pequenas equipas de
desenvolvimento, também foram apresentadas as ferramentas e tecnologias
selecionadas, por meio do qual poderá se desenvolver com eficiência o sistema de gestão
de informação dos munícipes para Administração do distrito Urbano do Rangel.
17
CAPÍTULO 2: CARACTERISTICAS DO SISTEMA
CAPÍTULO 2. CARACTERÍSTICAS DO SISTEMA
Este capítulo tem por objetivo mostrar como aconteceu todo o processo de
desenvolvimento do sistema de gestão de informação para Administração do Distrito
Urbano do Rangel, através de toda a documentação produzida durante a análise. Se
definiram os requisitos funcionais e não funcionais do sistema. Também se definiram como
arquitetura do sistema a arquitetura Modelo Vista Controlador (MVC).
Sistema proposto
Com objetivo de informatizar o processo de gestão de informação, propôs-se realizar o
desenho e implementação de um sistema informático que visa melhorar o atendimento e
controlo das informações.
Antes de se começar a desenvolver um sistema, é necessário entender o domínio do

negócio na qual o sistema será implantado e isso consegue-se pela análise e modelagem
do negócio, este assunto será abordado no próximo ponto.
2.1 Modelagem do negócio

Quando se começa a tarefa de informatizar um processo de qualquer índole se necessita
compreender sobre maneira o ambiente em que se desenvolve o mesmo e quais são as
suas características. São estes os principais objectivos de um modelo de negócio.
Modelagem de negócio é a criação de modelos do negócio, resultante das análises e

reflexões sobre a natureza do negócio e a forma como ele é executado, ou seja, sobre as
características do negócio e as rotinas organizacionais (Rodrigues, 2015).
2.1.1 Atores e trabalhadores de Negócio

Identificados os processos do negócio é possível determinar os atores e trabalhadores que
intervêm em ditos processos.
Um ator de negócio representa um papel desempenhado em relação ao negócio por

alguém ou algo no ambiente do negócio (Pressman, 2005).
18
Tabela 2-1 – Descrição dos Atores de negócio
Ator de Negócio Descrição

Munícipe Pessoa que solicita um serviço na administração.
Os trabalhadores do negócio constituem abstrações de pessoas, grupos o um sistema

automatizado que realiza operações dentro das fronteiras de negócio.
Tabela 2-2 – Descrição dos Trabalhadores do negócio
Trabalhadores Descrição
Administrador Pessoa responsável por gerir à administração.
Agente Municipal Pessoa que gerência os pedidos de documentos
requisitados pelos munícipes.
2.2 Modelo conceitual e descrição do negócio

O modelo conceitual é a representação visual das classes conceituais ou objetos do
mundo real em um domínio de problema, deve representar a compreensão da informação
que o sistema vai gerenciar.
O modelo conceitual de domínio visa a aquisição e modelagem de informações sobre o

domínio organizacional sob o qual o contexto do projeto se insere. Em outras palavras, ele
visa estruturar o conhecimento que se tem sobre o problema que se deseja resolver. Em
alguns tipos de software, esse modelo do domínio tem uma importância somente marginal,
mas para outros, tais como bancos de dados, por exemplo, o modelo conceitual de
domínio tem uma importância muito grande.
De uma maneira geral, o modelo de domínio envolve o contexto onde o software será
aplicado, e sua compreensão, antes da introdução do sistema de software que se pretende
desenvolver. Assim, vemos que o modelo conceitual ilustra conceitos significativos de um
domínio - aquilo que devemos estar cientes a respeito do domínio, representando sempre
coisas do mundo real não componentes de software (Gudwin, 2015).
19
Figura 2-1 - Modelo conceitual do negócio.
2.2.1 Diagrama de Caso de Uso do Negócio

Um diagrama de casos de uso de negócio descreve os processos de um negócio
vinculados ao campo de ação e como se beneficiam e interagem os sócios e clientes
nestes processos (González, 2013) .
Figura 2-2 - Diagrama do caso de uso do negócio.
20
2.2.2 Descrição do Diagrama de Caso de Uso de Negócio: Fazer pedido

Tabela 2-3 -Descrição do DCUN Fazer pedido.
Caso de Uso Fazer pedido.

Actor(es) Munícipe.
Trabalhador Agente municipal
Resumo Este caso de uso serve para o ‘Munícipe’ fazer pedido de um
documento.
Fluxo normal de eventos
Acção do ator Resposta do Negócio
1. O caso de uso começa quando 2. O Agente Municipal comprova os dados do
o Munícipe vai à Administração Munícipe.
“Solicita Pedido”. 2.1. Se os dados do Munícipe estiverem em
ordem, solicita-se o tipo de documento.
3. O Munícipe escolhe o tipo de 4. O Agente Municipal valida o pedido.
documento que necessita.
5. O Munícipe apresenta o 6. O agente Municipal conclui o pedido.
comprovativo de pagamento.
Fluxo alternativo: Munícipe sem informação.
2.2. Se não existir informação do Munícipe.
Informa-se ao Munícipe, assim termina o
caso de uso.
Tabela 2-4 – Descrição do DCUN Gerenciar documentos.
Caso de Uso Gerenciar documentos.

Actor Munícipe.
Resumo O caso de uso inicia-se quando o munícipe vai solicitar o
levantamento de um documento.
1. O Munícipe Solicita o seu 2. O Agente Municipal pede os dados do
documento. Munícipe.
3. O Munícipe da os seus dados 4. O Agente Municipal comprova os dados do
e o tipo de documento solicitado. Munícipe, imprime o documento e entrega o
documento.
21
Tabela 2-5 -Descrição do DCUN Atender pedido.
Caso de Uso Atender pedido.

Actor(es) Munícipe.
Resumo Este caso de uso serve para o ‘Agente Municipal’ Atender pedido
de um documento.
1 O caso de uso começa quando 2 O Agente Municipal verifica se o Munícipe
o Munícipe vai à Administração possui informações na Administração.
“Solicitar um Pedido”. 2.1 Se o Munícipe possuir informações na
Administração, solicita-se o tipo de
documento.
3 O Munícipe escolhe o tipo de 4 O Agente Municipal valida o pedido.
documento que necessita.
5 O Munícipe apresenta o 6 O agente Municipal conclui o pedido.
comprovativo de pagamento.
Fluxo alternativo: Munícipe sem informação.
2.3. Se não existir informações do Munícipe.
Informa-se ao Munícipe, solicita-se o BI
para o cadastro.
2.4. Repete o passo 3, 4, 5 e 6
2.2.3 Diagrama de classes com estereótipos web (Descrição)

Um diagrama com estereótipos web mostra graficamente as especificações das classes
de software e das interfaces em uma aplicação e permite modelar a vista de desenho do
sistema. A continuação, se mostra o diagrama de classes com estereótipo web do CU
Gerir Municipe onde se ilustra as relações existentes entre as classes.
22
Figura 2-3 - Diagrama de classes com estereótipo web.
2.3 Modelagem do Sistema

Modelagem de sistema é o processo de desenvolvimento de modelos abstratos de um
sistema, em que cada modelo apresenta uma visão ou perspetiva, diferente do sistema. A
modelagem de sistema geralmente representa o sistema com algum tipo de notação
gráfica, que, atualmente, quase sempre e baseada em notações de UML (linguagem de
modelagem unificada, do inglês Unified Modeling Language). No entanto, também é
possível desenvolver modelos (matemáticos) formais de um sistema, normalmente como
uma especificação detalhada do sistema (Pearson Prentice Hall, 2011).
Os modelos são usados durante o processo de engenharia de requisitos para ajudar a

extrair os requisitos do sistema durante o processo de projeto, são usados para descrever
o sistema para os engenheiros que o implementam e, apos isso, são usados para
23
documentar a estrutura e a operação do sistema. Pode-se desenvolver modelos do

sistema a ser desenvolvido:
1. Modelos do sistema existente são usados durante a engenharia de requisitos. Eles
ajudam a esclarecer o que o sistema existente faz e podem ser usados como ponto
de partida para discutir seus pontos fortes e fracos. Levam, então, os requisitos
para o novo sistema.
2. Modelos do novo sistema são usados durante a engenharia de requisitos para
ajudar a explicar os requisitos propostos para outros stakeholders do sistema. Os
engenheiros usam esses modelos para discutir propostas de projeto e documentar
o sistema para a implementação. Em um processo de engenharia dirigida a
modelos, é possível gerar uma implementação completa ou parcial do sistema a
partir do modelo de sistema.
O aspeto mais importante de um modelo de sistema é que ele deixa de fora os detalhes.
O modelo é uma abstração do sistema a ser estudado, e não uma representação
alternativa dele (SOMMERVILLE, 2011).
Os requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e as

suas restrições operacionais. Esses requisitos refletem as necessidades dos clientes de
um sistema que ajuda a resolver algum problema, por exemplo, controlar um dispositivo,
enviar um pedido ou encontrar informações. O processo de descobrir, analisar,
documentar e verificar esses serviços e restrições é chamado de requisitos (RE-
Requirements Enginneering) (SOMMERVILLE, 2011).
2.3.1 Requisitos funcionais

Os requisitos funcionais de um sistema descrevem o que ele deve fazer. Eles dependem
do tipo de software a ser desenvolvido, de quem são seus possíveis usuários e da
abordagem geral adotada pela organização ao escrever os requisitos. Quando expressos
como requisitos de usuário, os requisitos funcionais são normalmente descritos de forma
abstrata, para serem compreendidos pelos usuários do sistema. No entanto, requisitos de
sistema funcionais mais específicos descrevem em detalhes as funções do sistema, suas
entradas e saídas, exceções etc. Requisitos funcionais do sistema variam de requisitos
gerais, que abrangem o que o sistema deve fazer, ate requisitos muito específicos, que
refletem os sistemas e as formas de trabalho em uma organização (SOMMERVILLE,
2011).
24
Para que o sistema se execute os seguintes requisitos funcionais foram identificados:

Tabela 2-6 - Requisitos funcionais.
Ref Descrição dos Requisitos Complexidade Prioridade

Funcionais
RF-01 Autenticar usuário Media Alta
RF-02 Adicionar usuário Media Alta
RF-03 Editar usuário Media Baixa
RF-04 Eliminar usuário Media Baixa
RF-05 Listar usuário Media Baixa
RF-06 Adicionar munícipe Alta Alta
RF-07 Editar munícipe Media Baixa
RF-08 Eliminar munícipe Media Baixa
RF-09 Listar munícipe Media Baixa
RF-10 Buscar munícipe Alta Alta
RF-11 Adicionar pedido Alta Alta
RF-12 Editar pedido Media Media
RF-13 Eliminar pedido Media Baixa
RF-14 Listar pedido Media Baixa
RF-15 Buscar pedido Media Media
RF-16 Gerar relatórios Alta Alta
RF-17 Gerar estatística Media Media
2.3.2 Requisitos não funcionais

Os requisitos não funcionais, como o nome sugere, são requisitos que não estão
diretamente relacionados com os serviços específicos oferecidos pelo sistema a seus
usuários. Eles podem estar relacionados as propriedades emergentes do sistema, como
confiabilidade, tempo de resposta e ocupação de área. Uma alternativa a esse cenário
seria os requisitos definirem restrições sobre a implementação do sistema, como as
capacidades dos dispositivos de E/S ou as representações de dados usadas nas
interfaces com outros sistemas.
Os requisitos não funcionais, como desempenho, proteção ou disponibilidade,

normalmente especificam ou restringem as características do sistema como um todo.
Requisitos não funcionais são frequentemente mais críticos que requisitos funcionais
individuais. Os usuários do sistema podem, geralmente, encontrar maneiras de contornar
uma função do sistema que realmente não atenda a suas necessidades. No entanto,
deixar de atender a um requisito não funcional pode significar a inutilização de todo o
sistema (SOMMERVILLE, 2011).
25
Para que o sistema se execute os seguintes requisitos não funcionais foram identificados:
• Usabilidade:
RNF-01: O sistema deve possuir uma estrutura simples e que possibilite chegar ao
conteúdo que se deseja em pouco tempo.
RNF-02: O sistema deve possuir uma interface intuitiva e fácil de usar, qualquer
usuário pode usá-lo mesmo sem grande conhecimento de informática.
• Confiabilidade:
RNF-03: O sistema deve fazer à validação dos campos no ato da coleta de dados para
evitar entradas inapropriadas.
RNF-04: O sistema deve permitir apenas acesso e modificação da informação por

usuários autorizados.
• Segurança:
RNF-05: Integridade e confidencialidade das informações são asseguradas através de

mecanismos de controlo de acesso e uso não autorizado: email do usuário e senha.
RNF-06: O sistema deve garantir que a exclusão de informações tenha uma opção de
aviso antes de executar a ação.
• Suporte:
RNF-07: O sistema deve dar a possibilidade de ser melhorado, e de ser incorporado

novas funcionalidades, em caso de necessidades.
• Interface externa:
RNF-08: A boa organização das informações é garantida para permitir a interpretação

correta.
• Software:
RNF-09: Cliente de Aplicação: Para aceder a aplicação se requerer usar um Navegador.
RNF-10: Servidores de Aplicação: Para um servidor de aplicação web se requer usar

apache 2.4.
RNF-11. Servidor de banco de dados: para permitir a devida persistência dos dados o
sistema deverá o sistema gestor de banco de dados MySQL na versão 8.0.13.
26
• Hardware:
O computador onde se instalará o servidor de banco de dados deve cumprir os

seguintes requisitos de hardware:
RNF-12: O servidor de banco de dados deve ter como mínimo um microprocessador

de 1GHz, 4 GB de RAM e disco rígido de 80 GB, para um funcionamento razoável do
sistema.
O computador onde se instalará o servidor de aplicação deve cumprir os seguintes

requisitos de hardware:
RNF-13: O servidor de aplicação deve ter como mínimo um microprocessador de 1GHz,

4 GB de RAM e disco rígido de 80 GB.
2.4 Modelo de casos de uso do sistema

O modelo de casos de uso permite descrever os Requisitos funcionais do sistema, dando
lugar a um acordo entre o cliente e os desenvolvedores de sistemas. Proporcionando uma
aplicação clara e consistente de que deveria fazer o sistema de modo que o modelo se
use ao longo do processo de desenvolvimento. Possibilita que se obtenha uma base para
realizar verificações do produto informático sendo a entrada principal para as analises, e
desenho e as provas (Larman, 2005).
2.4.1 Casos de Uso

Casos de uso são abstrações de pequenas histórias narrativas envolvendo a interação
entre um ou mais usuários (chamados de atores) e o sistema. A ideia e que estes casos
de uso representem, por meio dessas pequenas histórias, as funcionalidades de um
sistema.
Podemos entender um caso de uso, portanto, como uma sequencia de ações (uma
atividade, segundo a terminologia UML), executadas na forma de uma interação entre os
atores e o sistema, onde ao final da atividade existe alguma vantagem ou ganho para o(s)
usuário(s) (Gudwin, 2015).
2.4.2 Atores do Sistema

Os atores do sistema representam o papel de uma entidade externa ao sistema como um
usuário, um hardware ou outro sistema que interaja com o sistema modelado. É por meio
do caso de uso que os atores iniciam a comunicação com o sistema (Burgués, 2016).
27
Tabela 2-7 -Descrição dos Atores do sistema.
Descrição
Ator do sistema
Munícipe Realiza pedidos de documentos.
Funcionario (Agente Responsável por gerir as informações dos munícipes, gerenciar
Municipal) pedidos e gerenciar documentos.
Administrador Possui acesso total dentro no sistema.
2.5 Diagrama de caso de uso do sistema

O diagrama de caso de uso descreve a funcionalidade proposta para um novo sistema
que será projetado, é uma excelente ferramenta para o levantamento dos requisitos
funcionais do sistema, podemos dizer que um caso de uso é um "documento narrativo que
descreve a sequência de eventos de um ator que usa um sistema para completar um
processo". Um caso de uso representa uma unidade discreta da interação entre um ator
humano, dispositivo ou outro software e o sistema (Vazquez, et al., 2016).
De acordo com a definição apresentada anteriormente, eis abaixo o diagrama de caso de

uso do sistema.
Figura 2-4 - Diagrama de casos de uso do sistema
28
2.6 Descrição de Casos de Uso do Sistema

Tabela 2-8 - Descrição do DCUS – Autenticar Usuário.
Caso de Uso Autenticar Usuário.

Ator(es) Todo tipo de usuário.
Resumo Este caso de uso serve para autenticar usuários no sistema.
Pré-condições O usuário deve possuir login e senha cadastrada.
Pós-condições O usuário deve acessar o sistema de acordo com o seu perfil.
Referências Não há.
Prioridade Alta.
Acção do ator Resposta do sistema
1. O caso de uso começa quando o 2. O sistema apresenta a tela de login.
usuário indica fazer login no
sistema.
3. O usuário preenche os campos 4. O sistema valida o usuário e senha, verifica
‘Usuário’ e ‘Senha’ e clica no botão o perfil de usuário e redireciona o usuário a
entrar. página específica de seu perfil.
Fluxo alternativo de eventos
A1: Usuário clica no link ‘Esqueceu seu usuário ou senha?’
1. O sistema apresenta a tela.
2. O usuário preenche o campo ‘E-mail’
3. O sistema valida o cadastro no banco de dados e envia um e-mail ao usuário com
seu login e senha.
Fluxos de Exceção:
E1: Usuário deixa campos ‘Usuário’ e/ou ‘Senha’ em branco:

1. O sistema exibe a mensagem “Usuário e/ou senha incorreto(s)!”.
2. O caso de uso é reiniciado.
E2: Usuário insere ‘Usuário’ e ‘Senha’ inválidos:

1. O sistema exibe a mensagem “Usuário e/ou senha incorreto(s)!”.
Protótipo de interface
29
Tabela 2-9 - Descrição do DCUS – Gerenciar Munícipes.
Caso de Uso Gerenciar Munícipes.

Ator(es) Agente Municipal.
Resumo Este caso de uso serve para o usuário ‘Agente Municipal’ gerenciar as
informações do ‘Munícipe’.
Pré-condições O usuário deve possuir o perfil ‘Agente Municipal’ e ter efetuado o login.
Pós-condições O sistema deve salvar todas as alterações realizadas.
Prioridade Alta.
1. O Agente Municipal clica no link 2. O sistema preenche as máscaras e
“Cadastrar Munícipe”. apresenta a tela de cadastro de munícipe.
3. O Agente Municipal preenche 4. O sistema valida os dados,

todos os campos e clica no botão salva as informações no banco de
“Adicionar”. dados e exibe a mensagem
“Munícipe cadastrado com sucesso.”
Fluxos de Exceção
E1: Agente Municipal preenche número de BI já cadastrado:

1. O sistema apresenta a mensagem de erro “número de BI duplicado”.
30
Tabela 2-10 -Descrição do DCUS – Gerenciar Pedido.
Caso de Uso Gerenciar Pedido.

Ator(es) Agente Municipal.
Resumo Este caso de uso serve para o ‘Agente Municipal’ gerenciar pedido
de um documento.
Pré-condições O usuário deve possuir o perfil ‘Agente Municipal’’ e ter sido
cadastrado.
Pós-condições Não há.
Prioridade Alta.
Resposta do sistema Acção do ator
1. O sistema mostra a tela principal. 2. Agente Municipal’ clica no menu “Pedidos” abrir-
se-á os submenus “Listar pedido” e “Adicionar”.
De seguida o Agente Municipal’ clica no
submenu “Adicionar”.
3. O sistema mostra a tela de registro de 4. O funcionario preenche os campos e clica em
pedido com os seguintes campos Adicionar pedido.
(Selecionar munícipe, Tipo de
documento, Descrição).
5. O sistema verifica se os campos estão
bem preenchidos (E1).
Não há
Fluxos de Exceção
E1: Se os campos estão vazios, o sistema mostra uma mensagem do tipo “campos
obrigatórios”. O sistema retorna ao 4º passo do fluxo principal.
Regras de Negócio
• R1. O sistema só regista pedidos de munícipes que estão cadastrados no sistema.
31
Tabela 2-11 -Descrição do DCUS – Gerenciar Usuário.
Caso de Uso Gerenciar Usuário.

Ator(es) Administrador.
Resumo Este caso de uso serve para o usuário ‘Administrador’ gerenciar as
informações dos ‘Usuários’.
Pré-condições O usuário deve possuir o perfil ‘Administrador’.
Pós-condições O sistema deve salvar todas as alterações realizadas.
Prioridade Alta.
1. O usuário clica no link “Registrar um 3. O sistema preenche as máscaras e
novo membro”. apresenta a tela de cadastro de usuário.
2. O usuário preenche todos os campos 4. O sistema valida os dados, salva as

e clica no botão “Registrar”. informações no banco de dados.

A1: O Usuário seleciona o botão ‘Apagar Usuário:
1. O sistema exibe a mensagem “Usuário apagado com sucesso”.
2. Retorna ao fluxo principal.
Fluxos de Exceção
E3: Usuário preenche um endereço de e-mail já cadastrado:
3. O sistema apresenta a mensagem “E-mail já cadastrado”.
O caso de uso é reiniciado.
4. O sistema apresenta a mensagem “E-mail já cadastrado”.
32
2.7 Conclusão parcial
Com a elaboração do capítulo foi possível concluir que a modelagem do negócio permitiu
ter um maior entendimento do negócio realizado pela Administração do Distrito Urbano do
Rangel, para assim definir quais funcionalidades devem ser implementadas para dar
resposta a situação problemática apresentada.
33
CAPÍTULO 3: DESENHO, IMPLEMENTAÇÃO E PROVAS DO SISTEMA
CAPÍTULO 3. DESENHO, IMPLEMENTAÇÃO E PROVAS DO

SISTEMA
Neste capítulo vai se fazer uma abordagem mais profunda a respeito ao processo de
desenvolvimento e acabamento do sistema de gestão de informação dos munícipes para
Administração do Distrito Urbano do Rangel, com base em alguns diagramas tais como o
diagramas de classes, diagrama de componentes, diagrama de implantação, bem como o
modelo físico de dados e validação do sistema com provas de funcionamento do software.
Esses que constituem elementos importantes para implementação do sistema proposto.
3.1 Diagrama de classes

Em princípio, um diagrama de classes representa uma visão do modelo estrutural estático,
que pode ser entendido como a união de todos os diagramas de classe e de objetos, da
mesma maneira que podemos projetar uma figura tridimensional em diversos planos
bidimensionais. Classes são descritores para um conjunto de objetos com estrutura,
comportamento e relacionamentos similares. Seu modelo diz respeito a intensão de uma
classe, ou seja, as regras que a definem enquanto uma classe (Gudwin, 2015).
3.1.1 Modelo Lógico

O modelo logico é o modelo que mostra toda a estrutura do banco de dados, mas é ainda
independente de SGBD, ou seja, pode ser usado em qualquer banco de dados. Quando
estiver pronto, podemos ter noção da estrutura e de todas as tabelas (entidades) que o
sistema terá, com consistência, segurança e sem redundâncias. Apos este modelo, já
direcionaremos o nosso banco para o SGBD a ser utilizado, ou seja, Oracle, MySQL, SQL
Server, PostgreSQL, etc. (Scribd, 2019).
34
Figura 3-1 – Modelo lógico de banco de dados.
3.2 Modelo de Base dados

Um modelo de banco de dados mostra a estrutura lógica de um banco de dados, incluindo
as relações e restrições que determinam como os dados podem ser armazenados e
acessados. Os modelos de base de dados individuais são projetados com base nas regras
e nos conceitos do modelo mais abrangente que os designers adotam. A maioria dos
modelos de dados pode ser representada por um diagrama de banco de dados
acompanhante (Lucidchart, 2018).
3.2.1 Modelo físico de dados

O Diagrama Entidade Relacional (DER) fornece uma ferramenta para representar
informações do mundo real ao nível conceitual. Ele permite fazer a descrição bem como
definir as restrições das mesmas (Gaona, 2012).
35
Em geral este modelo representa de forma abstrata a estrutura que possuirá a base de
dados da aplicação.
Figura 3-2 - Modelo físico de banco de dados.
3.3 Diagrama de Componentes

O diagrama de componentes fornece uma visão física da construção do sistema de
informação. Mostra a organização dos componentes de software, suas interfaces e as
dependências entre eles. Estes diagramas podem incluir pacotes que permitem a
organização do sistema de informação em subsistemas e que incluem aspectos práticos
relacionados à sequência de compilação entre componentes, o agrupamento de
elementos em bibliotecas, etc. (Cillero, 2018)
36
Figura 3-3 - Diagrama de Componente
3.4 Padrões de arquitetura

Padrões de arquitetura são soluções para problemas específicos que ocorrem de forma
recorrente em um determinado contexto que foram identificados a partir da experiência
coletiva de desenvolvedores de software (Frank, 2015).
Para o desenvolvimento do sistema de gestão de informação para Administração do

Distrito Urbano do Rangel, na área da secretaria se utilizará o padrão arquitetónico
Modelo-Vista-Controlador.
3.4.1 Modelo Vista Controlador (MVC)

O padrão proporciona grandes vantagens como a organização de código, reutilização e
flexibilidade. A programação é organizada pois separa os dados da aplicação, a interface
do usuário e a lógica dos dados em três componentes diferentes, em qual cada camada
se especializa em uma função específica (Salazar, 2012).
37
• Modelo: representação que específica a informação com qual sistema opera. Á

lógica de dados que assegura a integridade e permite derivar novos dados. Fazem
parte dessa camada à título de exemplo as classes: MunicipeModel,
UsuarioModel, etc.
• Vista: mostra o modelo em um formato adequado para interagir. Trata á
apresentação visual dos dados representados pelo modelo. Fazem parte dessa
camada à título de exemplo as classes: MunicipeView.html, UsuarioView.html,
etc.
• Controlador: responde a eventos e invoca alterações no modelo e provavelmente
na vista. Fazem parte dessa camada à título de exemplo as classes:
MunicpeController, UsuarioController, etc.
Figura 3-4 - Arquitetura Modelo Vista Controlador
Vantagens do MVC:
• Suporte para múltiplas vistas, pois não existe dependência direta entre a vista e o
modelo.
• Proporciona um mecanismo de configuração a componentes complexos muito mais
tratável que o puramente baseado em eventos.
• Maior suporte a as trocas, pois os requisitos de interface tendem a trocar mais
rapidamente que as regras de negócio. Posto que o modelo depende das vistas, a
adição de novos tipos de vista ao sistema afeta o modelo (Salazar, 2012).
38
3.5 Padrões de Desenho

Com o uso de padrões de desenho se evita a reiteração em busca de soluções a
problemas já conhecidos. Permite formalizar um vocabulário comum entre desenhadores
e estandardizar o modo em que se realiza o desenho. Os padrões de desenho constituem
uma descrição de um problema e a solução, o mesmo recebi um nome e se pode aplicar
a vários contextos. Muitos padrões proporcionam guias no modo em que deveriam dar as
responsabilidades a os objetos dada uma categoria especifica do problema (Larman,
2005)
3.5.1 Padrão (GRASP)

GRASP significa Padrões de Software de Atribuição Geral de Responsabilidades. Esses
padrões, como o nome sugere, visam principalmente definir as tarefas que cada
componente do software deverá fazer (Koopmans, 2017).
A continuação se detalha ao uso destes padrões na solução:
• Experto: propõe dar as responsabilidades as classes de acordo a informação que

contem as mesmas, cumprindo assim um princípio básico e intuitivo da
programação orientada a objetos (Larman, 2005). Se evidencia na seguinte classe
“Municipe”, a mesma contem toda a informação que compreende a um munícipe.
Figura 3-5 - Fragmento do código do padrão experto na classe Munícipe.
• Criador: Guia de atribuição de responsabilidades relacionadas com a criação de

objeto. Este padrão tem como função de encontrar um criador que necessite
39
conectar-se ao objeto criado em alguma situação. De maneira geral as classes

mascadas dentro da camada controladora distribuem as responsabilidades de
comunicação com as instâncias da camada de apresentação (Larman, 2005). Uso
desse padrão pode ser observado entre a classe Municipe e Pedido onde a classe
Municipe possui informação necessária para inicialização ou criação de objeto
Pedido.
Figura 3-6 - Fragmento de código criar pedidos.
• Controlador: O padrão controlador serve como intermediário entre uma

determinada interface e algoritmo que lhe implementa, manejando os eventos de
entrada da dita interface (Larman, 2005). Aplicação deste padrão fica evidente nas
classes PedidoController, Funcionario Controller, só para citar alguns. Onde esta
recebe e trata eventos da camada de interface com o usuário, delegando as ações
para as camadas inferiores, de modo que funcione como intermediário.
40
Figura 3-7 - Fragmento do código inserir funcionario.
3.6 Modelo de despliegue (implantação)

O diagrama de utilização, também denominado diagrama de implantação, consiste na
organização do conjunto de elementos de um sistema para a sua execução (Booch, et al.,
2016).
• Mostra o layout físico de um sistema, revelando quais partes do software são

executadas em quais partes do hardware.
• Enfoca a estrutura física sobre a qual o software irá ser implantado e executado em
termos de hardware.
• Define como as máquinas estarão conectadas e através de quais protocolos se
comunicarão.
• É útil quando o sistema a ser modelado for ser executado sobre múltiplas camadas.
• Seus elementos são os nós e os caminhos de comunicação.
41
Figura 3-8 - Modelo de despligue (implementação).
Descrição do modelo de implantação do sistema

• PC Cliente: Acedem a aplicação através de um computador, onde é executada
mediante um navegador disponível no computador, sobre qualquer sistema
operativo.
• Servidor de Aplicação Web: Componente de Software responsável por rodar a
aplicação do lado do servidor.
• Impressora: Componente de hardware utilizada para imprimir os relatórios gerados
pela aplicação.
• Servidor de Banco de Dados: Componente de software responsável por gerir a
base de dados da aplicação.
• HTTPS: HTTPS (sigla do inglês, Hyper Text Transfer Protocol Secure, protocolo de
transferência de hipertexto seguro) Trata-se de um protocolo TCP/IP utilizado pelos
servidores Web para a transferência e visualização de conteúdo Web de forma
segura para o cliente neste caso o Navegador.
• USB: USB (sigla do inglês, Universal Serial Bus, Porta Universal) é um padrão de
conexão para muitos tipos de dispositivos. Será o tipo de conector usado para a
conexão entre o pc do cliente e o dispositivo de saída para a impressão dos
documentos.
• TCP/IP: protocolo para conectar o servidor de aplicações com a base de dados.
42
3.7 Estândares de codificação

A organização do código fonte facilita os processos de desenvolvimento, retirada de bugs,
atividades de validação e manutenção. O uso de um padrão de codificação também
aumenta a produtividade num projeto, uma vez que a comunicação dentro da equipe de
desenvolvimento fica mais fácil, mas vale ressaltar que partes desses padrões são vistas,
algumas vezes, como sugestões por empresas que adotam seus próprios padrões
(DEVMEDIA, 2019).
O propósito fundamental dos padrões de codificações é organizar e estilizar

consistentemente o sistema com dependência do autor para que resulte fácil de entender
e de manter. Tendo em conta que a proposta de solução se desenvolvi utilizando o marco
de trabalho Laravel 5.5, se define o uso dos padrões PSR-1 (PHP Standards
Recommendation 1) e PSR-2 (PHP Standards Recommendation 2). Estes padrões
compreendem um grupo de elementos a ter em conta na hora de codificar e que têm como
característica uma uniformidade de estilos e regras a cumprir.
• Se deve empregar somente a codificação UTF-8 para o código PHP.

• Deve haver uma linha em branco depois da declaração do “namespace” e outra
depois do bloco de declarações “use”.
• Se devem utilizar somente as etiquetas <?php<?=.
• O código deve usar 4 espaços como indentação, não tabulações.
• Os parenteses de abertura nas estruturas de controlo não devem ter um espaço
depois deles, e os parêntesis de fechamento não devem ter um espaço antes
deles.
• As chaves de abertura das estruturas de controlo devem estar na mesma linha, e
de fechamento devem ir em linha seguinte ao corpo.
3.8 Validação do sistema

Existem muitas maneiras de se testar um software, mas as técnicas de teste que serão
aplicadas são as técnicas estrutural também conhecida como Prova de Caixa Branca e
técnica funcional também conhecida como Prova de Caixa Preta.
Técnicas de provas de software fornecem diretrizes sistemáticas para projetar testes que
exercitam a lógica interna e a interface de todos os componentes do software e exercitam
43
os domínios de entrada e saída do programa para descobrir erros no funcionamento,

comportamento e desempenho do programa (Pressman, 2005).
3.8.1 Estratégia de Prova

Para dar início as provas de um software o primeiro é definir uma estratégia de prova onde
serão plasmados os níveis de provas a tratar, assim como os tipos de provas, o método
de prova e a técnica aplicada neste método. Uma estratégia de prova de software integra
os métodos de desenho de casos de provas de software em uma série bem planejada de
passos que desemboscará na construção do mesmo. Deve incorporar a planificação de
provas, em desenho de casos de provas, a execução de provas e a coleção e avaliação
dos dados resultantes. Esta tem que ser o suficientemente flexível para promover um
enfoque personalizado. Ao mesmo tempo, deve ser adequadamente rígido como para
promover uma planificação razoável e um seguimento administrativo de avanço do projeto
(Pressman, 2011).
3.8.2 Provas unitárias

Como parte das provas unitárias se utilizou o método de Caixa Branca utilizando a técnica
de caminho básico. Denominadas em ocasiões como provas de caixa de cristal, as provas
de caixa branca é um método que usa a estrutura de controlo de desenho procedimental
para obter os casos de prova. Mediante esta prova, o engenheiro de software pode obter
casos de prova (Pressman, 2008).
Este tipo de prova se realiza de três formas diferentes:

• O número de regiões de grafo de fluxo coincide com a complexidade ciclomática.
• A complexidade ciclomática V(G) de um grafo de fluxo G se define como: V(G)=
A-N+2 onde A é o número de arestas do grafo de fluxo e N é o número de nos do
mesmo.
• V(G) também se calcula como o resultado de P+1 onde P é o número de nodos
predicados (nos dos quais partem duas ou mais arestas) que tem contido o grafo
de fluxo G.
44
Figura 3-9 - Prova de Caixa Branca (metodo store)
Figura 3-10 - Grafo de fluxo associado a método store.
O número máximo de casos de prova é calculado pela fórmula V(G)=A-N+2, onde A é o

número de arestas e N o número de nós do grafo.
Logo tem:
V(G) = 4–4+2
V(G) = 2
O gráfico possui duas (2) regiões.
45
Descrição dos caminhos encontrados:

Caminho:1-2-3
Caso de Prova: Inserir Pedido.
Entrada: Quando o utilizador preenche devidamente o formulário.
Resultado: O sistema apresenta uma mensagem de notificação ('Pedido Cadastrado

com Sucesso').
Caminho:1-2-4
Caso de Prova: Inserir Pedido.
Entrada: Quando o utilizador não preenche devidamente o formulário.
Resultado: O sistema apresenta uma mensagem de notificação ('Erro ao Cadastrar,

verifique os dados introduzidos').
3.8.3 Provas funcionais

Como parte das provas funcionais se utilizou o método de Caixa Preta. As provas de caixa
preta também conhecidas como provas de comportamento, centram-se nos requisitos
funcionais do sistema, e permitem ao engenheiro do software obter conjuntos de
condições de entrada que executam completamente todos os requisitos funcionais de um
programa (Pressman, 2008).
O teste funcional, como o próprio nome diz, é realizado com base nos requisitos funcionais
do software, assim, é possível analisar as entradas e saídas de todas as unidades.
Para o presente projecto a prova funcional também conhecida como prova de caixa preta
foi efetuada sobre o formulário de Adicionar munícipe.
Provas de Caixa Preta. Técnica de Partição Equivalente

Tabela 3-1 - Provas de Caixa Preta
Condições de entrada Classes de equivalência válida Classes de equivalência não

válidas
O Campo nome não nome = Manuel nome =” ”
pode estar vazio
O campo sexo não sexo = Masculino sexo =” ”
pode estar vazio
O campo data de Data nasc= 04/07/1993 Data nasc (Hora)= ””
nascimento não pode
estar vazio
46
O campo data de BI=”003483471LA098” BI=””

emissão do bi não
pode estar vazio
O campo nome pai não Nome pai=”Lopes” Nome pai =””
pode estar vazio
O campo nome mãe Nome mãe=”Juliana” Nome mãe =””
não pode não pode
estar vazio
O campo residência Residencia=”vila alice” Residencia=””
não pode estar vazio
O campo telefone não Telefone=”923786589” Telefone=”923786jad”
pode conter letras
O campo nacionalidade Nacionalidade=”angolano” Nacionalidade=” ”
O campo estado civil Estado=”solteiro” Estado=” ”
O campo naturalidade Natural=Rangel Natural=” ”
civil não pode estar
vazio
Resultados da prova válida: O sistema redireciona o usuário para tela listagem de munícipes.
Resultados da prova não válida: O sistema não redireciona o usuário para tela listagem de
munícipes.
47
48
3.8.4 Resultados das provas

Ao aplicar as provas de funcionalidades em 20 casos de prova foram detetadas um total
de 9 não conformidades com a seguinte classificação: 5 de funcionalidade, 3 de escrita e
1 de interface em 3 iterações, na primeira iteração se detetaram 7 não conformidades, na
segunda iteração se detetou 2 não conformidades e na terceira iteração não se encontrou
nenhuma não conformidade. De forma geral se corrigiu estas deficiências obtendo
resultados satisfatórios, dando por concluída as provas.
Resultado de Provas
25
20 20 20
20
17 17 17
15
10
7
5
2
0
0 Requisitos Casos de Prova Não Conformidade
1ºIteração 2ºIteração 3ºIteração
Figura 3-11 - Gráfico dos resultados das provas
49
3.9 Conclusões parciais

Durante o desenvolvimento desse capítulo ficou definido o modelo de desenho e
implementou-se o sistema de gestão de informação, mostrou-se como foi aplicado o
modelo de despligue que permitiu representar a composição dos elementos físicos do
sistema, o modelo de banco de dados. Os padrões de codificação foram descritos para
ser mais fácil o entendimento do código, as provas realizadas permitiram comprovar o bom
funcionamento e avaliar a qualidade de software, tendo se observado o funcionamento do
sistema em relação ao comportamento dos usuários.
50
CONCLUSÕES
CONCLUSÕES
Com a elaboração do presente trabalho permitiu dar resposta o problema de investigação
que foi apresentado, através da execução dos objectivos específicos e das tarefas de
investigação, chegou-se as seguintes conclusões:
• O estudo sobre o estado de arte ao domínio do problema a nível nacional e

internacional proporcionou o conhecimento ao processo de gestão de informação
refentes Administração dos distritos permitiu constatar que estás soluções não
satisfazem a problemática, no qual evidencia a necessidade desta investigação.
• O estudo do marco teórico da investigação possibilitou a seleção da metodologia,

ferramentas e tecnologias a utilizar para a implementação da solução proposta.
• A partir do processo de modelagem do negócio e do sistema se obteve como

resultado os diagramas e artefactos necessários para guiar o desenvolvimento do
sistema.
• A implementação da solução desenvolvida permitiu cumprir na totalidade com os

requisitos funcionais identificados durante a etapa de analise.
• As provas realizadas permitiram detectar falhas, e melhora-las em cada uma das

iterações, possibilitando o bom funcionamento do sistema.
51
RECOMENDAÇÕES
RECOMENDAÇÕES
Após a conclusão do trabalho, constatou-se que os objectivos pelos quais foi criado foram
alcançados, para a continuidade recomenda-se o seguinte:
• Adicionar a funcionalidade que permite introduzir código QR nos documentos.
• Implantar o presente sistema informático na Administração do Distrito Urbano do

Rangel.
52
REFERÊNCIAS BIBLIOGRÁFICAS
ANDRACOM. 2018. Andracom. Andracom. [Online] 16 de 10 de 2018. [Citação: 16 de 10
de 2018.] http://www.andracom.com.br/solucoes-governamentais/gestao-publica-
municipal/.
Apache . 2015. Apache Friends. Apache Friends. [Online] 19 de 10 de 2015. [Citação: 24
de 09 de 2018.] https://www.apachefriends.org/blog/new_xampp_20151019.html.
Araújo, Carlos Alberto Ávila. 2010. O conceito de informação na Ciência da Informação.
João Pessoa : Inf. & Soc.: Est., v. 20, n. 3, p. 95-105, 2010.
Bachman, C. 2015. The programmer as navigator. s.l. : Comunications of the ACM, 2015.
Barwisnki, Luisa. 2009. TECMUNDO. www.tecmundo.com. [Online] 16 de junho de 2009.
[Citação: 11 de MAio de 2017.]
BETHA. 2018. Betha. Betha. [Online] 19 de 11 de 2018. [Citação: 19 de 11 de 2018.]
http://www.betha.com.br/produto/atendimento/cidadao-web.
Beux, Douglas. 2017. Micreiros.com. Micreiros.com. [Online] 16 de 05 de 2017. [Citação:
31 de 07 de 2019.] http://www.ericplatas.com.br/artigos/introducao-bootstrap-framework/..
Booch, G e Rumbaugh, J e Jacobson, I. 2016. UML, Guia do Usuário. [trad.] Fábio
Freitas da Silva. Rio de Janeiro : Campus, 2016.
Bootstrap. 2018. Bootstrap. Bootstrap. [Online] 2018. [Citação: 30 de 10 de 2018.]
https://getbootstrap.com.
Borborema, Thiago. 2007. Impacto da aplicação da metodologia XP nas organizações
de desenvolvimento de software. Pouso Alegre : Faculdade de Filosofia Ciência e Letras
Eugenio Pacelli, 2007.
Burgués, Esteban Gracia. 2016. Aprende a Modelar Aplicaciones con UML: 2ª Edición.
Espanha : ITCampos Academy, 2016. 978-1523498536.
Cavalcanti, Ramalho. 2017. WEBARTIGOS. www.WEBARTIGOS.com. [Online]. 2017.
Cillero, Manuel. 2018. https://manuel.cillero.es/doc/metrica-3/tecnicas/diagrama-de-
componentes/. Manuel.Cillero.es. [Online] 09 de 05 de 2018. [Citação: 25 de 07 de 2019.]
https://manuel.cillero.es/doc/metrica-3/tecnicas/diagrama-de-componentes/.
Cruz, T. 2008. Sistemas, organizações e métodos: estudo integrado das novas
tecnologias. São Paulo : Atlas, 2008.
Detlor, B. 2010. Information Management In:. International Journal of Information
Managment, 30, p. 103–108, : s.n., 2010.
DEVMEDIA. 2018. devmedia. devmedia. [Online] 27 de Dezembro de 2018. [Citação: 27
de Dezembro de 2018.] http://www.devimedia.com.br/metodologia-de-desenvolvimento-
de software/1903.
DEVMEDIA. 2019. web site devmedia. devmedia. [Online] 2019. [Citação: 16 de 02 de
2019.] https://www.devmedia.com.br/padroes-de-codificacao/1629.
53
Dicio. 2016. Dicio. Dicio. [Online] 26 de 02 de 2016. [Citação: 19 de 06 de 2019.]

https://www.dicio.com.br/distrito/.
Duckett, Jon. 2015. HTML e CSS - Projete e Construa Websites. s.l. : Alta Books , 2015.
Ecured. 2017. Ecured. Ecured. [Online] 16 de 04 de 2017. [Citação: 20 de 06 de 2019.]
https://www.ecured.cu/Sublime_text.
Flanagan, David. 2015. JavaScript-Guia definitivo 6º edição. Porto Alegre : BOOKMAN,
2015.
Flores, E. M. 2014. A gestão e os gestores da informação. s.l. : Bibliodocencia, 2014.
Fowler, Martin. 2005. UML Essencial. 3ª edição. s.l. : Bookman, 2005.
Frank, Buschmann et al. 2015. Pattern-Oriented Software Architectural:. s.l. : John Wilei
and Son, 2015.
Gaona, A. L. 2012. El Modelo Entidad Relación. México : s.n., 2012.
Gimson e Outros, Loraine, Gil, Daniel Gustavo e Rossi, Gustavo. 2012. Metodologias
ágil e desenvolvimento baseado em conhecimento. 2012.
Gonçalves, Mauro. 2015. Ferramentas de Tecnologias. Luanda : s.n., 2015.
González, D. A. 2013. Diagrama de casos de uso del negocio. La Habana : Instituto
Superior Politécnico Jose Antonio Echevarría., 2013.
Gudwin, Ricardo R. 2015. Engenharia de Software: Uma Visão Prática 2º edição. São
Paulo : DCA-FEEC-UNICAMP, 2015.
Koopmans, Regan. 2017. Entendendo os Padrões de Design GRASP. Medium. [Online]
24 de 09 de 2017. [Citação: 12 de 03 de 2018.]
https://medium.com/@ReganKoopmans/understanding-the-grasp-design-patterns-
2cab23c7226e.
Kroll e MCSAAK, P. B. 2006. Agility and Discipline Made Easy. s.l. : Pearson, 2006.
Laravel. 2018. Laravel. Laravel. [Online] 2018. [Citação: 2 de 12 de 2018.]
https://laravel.com/docs/5.5.
Larman, C. 2005. UML e Padrões. California : Prentice Hall, 2005.
LAUDON, K. e LAUDON. 2005. Essentials of Management Information Systems,
Managing the Digital 8th edition, Pearson. s.l. : 8th edition, Pearson, Prentice-Hall, 2005.
Leal, L. M. 2014. A percepção dos clientes universitários sobre a qualidade nos serviços
prestados pelo banco Santander. Paraíba : Universidade Estadual da Paraíba, 2014.
Lewis, R Joseph. e Moscovitz, Meitar. 2010. CSS Avançado. São Paulo : Novatec, 2010.
Lucidchart. 2018. Lucidchart. Lucidchart. [Online] 20 de 12 de 2018. [Citação: 20 de 12
de 2018.] https://www.lucidchart.com/pages/pt/o-que-e-um-modelo-de banco-de-dados.
Martins, José Carlos Cordeiro. 2007. Gerenciando Projetos de Desenvolvimento de
Software – 2ª e 4ª edições. 2007.
MINFIN. 2019. MINFIN. MINFIN. [Online] 12 de 06 de 2019. [Citação: 12 de 06 de 2019.]
https://municipal.minfin.gov.ao/PortalMunicipal/#!/.
54
Niederaue, Juliano. 2017. Desenvolvimento de Websites com PHP 3º edição. São Paulo :
Novatec, 2017.
Paradigm, Visual. 2018. Ideal Modeling Diagramming Tool for Agile Team Collaboration.
Visual Paradigm. [Online] Visual Paradigm, 2018. [Citação: 15 de 02 de 19.]
https://www.visual-paradigm.com/.
Pearson Prentice Hall. 2011. Modelagem. Nova Jersey : Pentice Hall, 2011.
PHP. 2018. PHP. Sitio web php. [Online] 2018. [Citação: 16 de 11 de 2018.]
http://php.net/manual/pt/intro-whatis.php.
Pleva, J. 2013. PHP: Hypertext Preprocessor. Wisconsin : Universidad de Wisconsin,
2013.
Pressman, Roger S. 2005. Engenharia de Software 6ª edição. Porto Alegre : McGrawHill,
2005.
Pressman, Roger S. 2011. Engenharia de Software: Uma abordagem Profissional. Porto
Alegre: : AMGH, 2011.
Rodrigues, Nadja Jr. 2015. Modelagem de Negócio - A importância de entender o
negócio antes de começar o desenvolvimento de projetos de software. Devmedia. [Online]
29 de 07 de 2015. [Citação: 25 de 07 de 2019.] https://www.devmedia.com.br/modelagem-
de-negocio-engenharia-de-software. 31/18729.
Salazar, Lianet Labrada. 2012. Administrador de Reportes para la versión 2.0 del
Generador Dinámico de Reportes. 2012.
Schmuller, J. 2010. Aprendendo UML em 24 horas. 2010.
Scribd. 2019. Scribd. Scribd. [Online] 18 de 06 de 2019. [Citação: 18 de 06 de 2019.]
https://pt.scribd.com/doc/303038449/Banco-de-dados-modelo-logico.
Scrumportugal. 2017. Scrumportugal. Scrumportugal. [Online] 2017. [Citação: 25 de 10
de 2018.] http://www.scrumportugal.pt/scrum.
Silva, Flávio. 2006. Modelagem de Software. 2006.
Silva, M.S. 2015. Fundamentos de HTML5 e CSS3. São Paulo : Novatec, 2015.
Software. 2015. Sitio web Software. Sitio web Software. [Online] 11 de 12 de 2015.
[Citação: 12 de 11 de 2018.] http://www.software.com.ar/visual-paradigm-para-uml.html.
SOMMERVILLE, IAN. 2003. Engenharia de Software 6ª edição. 6ª edição. São paulo :
Pearson, 2003.
SOMMERVILLE, IAN. 2011. Engenharia de Software 9ª edição. São paulo : Pearson,
2011.
Teles, Vinícios M. 2004. Extreme Programming. São Paulo : Novatec, 2004.
UML. 2012. Modelado de Sistemas con UML. Modelado de Sistemas con UML. [Online]
2012. [Citação: 26 de 10 de 2018.] http://es.tldp.org/Tutoriales/doc-modelado-sistemas-
UML/doc-modelado-sistemas-uml.pdf..
URBEM. 2018. Urbem. Urbem. [Online] 15 de 10 de 2018. [Citação: 15 de 10 de 2018.]
http://urbem.cnm.org.br/.
55
Vazquez, Carlos e Simões, Guilherme. 2016. Engenharia de Requisitos: Software

Orientado ao Negócio 1º edição. Rio de Janeiro : BRASPORT, 2016.
56
ANEXOS
ANEXOS
Anexo 1: Entrevista realizada a: Mariana Ferreira: Agente Municipal de 2º classe.
data: 14-09-2018.
Objetivo: Identificar as principais características e compreender o funcionamento da

Administração do Distrito Urbano do Rangel e como se realizam os pedidos pelos
munícipes.
1- Como funciona o processo de solicitação de documentos na Administração?
2- Como se realiza a entrega de documentos nos munícipes?
3- Que deficiências você considera, que afeta o atual processo de atendimento aos
munícipes?
4- Qual é a principal função da Administração do Distrito Urbano do Rangel uma vez

que estão vocacionados a prestação de serviço aos munícipes?
Anexo 2: Entrevista realizada ao: Hugo Marcelo Bastos Mota: Agente Municipal de
1º classe, Data: 17-09-2018.
Objetivo: Compreender o funcionamento da Administração do Distrito Urbano do Rangel

quanto aos serviços que prestam.
1- Descrição do fluxo de passos para se atender a solicitação de um documento?
2- Como se realiza o pagamento da solicitação de um documento?
3- Como funciona o processo de armazenamento das informações dos munícipes?
4- Quais são as regras e normas que você como agente da administração deve
cumprir com respeito aos serviços que prestam?
5- Quais são as principais deficiências que você como agente acha que existem?
57

Projecto Final - Pedro - Dombele - V - Final

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Projecto Final - Pedro - Dombele - V - Final

Enviado por

Direitos autorais:

Formatos disponíveis

INSTITUTO SUPERIOR DE TECNOLOGIAS DE INFORMAÇÃO

SISTEMA DE GESTÃO DE INFORMAÇÃO PARA

TRABALHO DE FIM DE CURSO DE LICENCIATURA EM

AUTOR: PEDRO JOÃO DOMBELE

SISTEMA DE GESTÃO DE INFORMAÇÃO PARA

TRABALHO DE FIM DE CURSO DE LICENCIATURA EM

AUTOR: PEDRO JOÃO DOMBELE

ORIENTADOR: MSc. WALBER MENGANA CUESTA

CURSO: ENGENHARIA INFORMÁTICA

A todos os professores pelo acompanhamento, orientação e amizade, também a todos os

Palavras chave: administração distrital, atendimento, aplicativo web, gestão de

Keywords: district administration, attendance, information management, web application.

1.1 Conceitos associados ao domínio do problema ................................................... 5

1.2 Estado da arte ...................................................................................................... 6

1.2.1 Campo internacional ...................................................................................... 6

1.2.2 Campo nacional ............................................................................................. 8

1.3 Metodologia de desenvolvimento de software ..................................................... 9

1.3.1 Metodologias Pesadas .................................................................................. 9

1.3.2 Metodologias Ágeis ....................................................................................... 9

1.4 Ferramentas e Tecnologias ................................................................................ 11

1.4.1 Sublime Text 3 – Editor de texto .................................................................. 12

1.4.2 XAMPP 7.0.15 ............................................................................................. 13

1.4.3 Sistema gestor de base de dados MySQL 8.0.13........................................ 13

1.4.4 Visual Paradigm 13.1................................................................................... 13

1.4.5 HTML 5 – Linguagem de marcação de hipertexto ....................................... 14

1.4.6 CSS 3 – Folhas de estilo ............................................................................. 14

1.4.7 JavaScript – Linguagem de programação para o lado cliente ..................... 15

1.4.8 Laravel 5.5 ................................................................................................... 15

1.4.9 Bootstrap 3 .................................................................................................. 16

1.4.10 PHP 7.0 ....................................................................................................... 16

1.4.11 Linguagem Unificada de Modelagem (UML) ............................................... 16

1.5 Conclusões parciais ........................................................................................... 17

CAPÍTULO 2. CARACTERÍSTICAS DO SISTEMA ....................................................... 18

2.2 Modelo conceitual e descrição do negócio......................................................... 19

2.2.1 Diagrama de Caso de Uso do Negócio ....................................................... 20

2.2.2 Descrição do Diagrama de Caso de Uso de Negócio.................................. 21

2.2.3 Diagrama de classes com estereótipos web (Descrição) ............................ 22

2.3 Modelagem do Sistema...................................................................................... 23

2.3.1 Requisitos funcionais ................................................................................... 24

2.3.2 Requisitos não funcionais ............................................................................ 25

2.4 Modelo de casos de uso do sistema .................................................................. 27

2.4.1 Casos de Uso .............................................................................................. 27

2.4.2 Atores do Sistema ....................................................................................... 27

2.5 Diagrama de caso de uso do sistema ................................................................ 28

2.6 Descrição de Casos de Uso do Sistema ............................................................ 29

2.7 Conclusão parcial ............................................................................................... 33

CAPÍTULO 3. DESENHO, IMPLEMENTAÇÃO E PROVAS DO SISTEMA .................. 34

3.1 Diagrama de classes .......................................................................................... 34

3.1.1 Modelo Lógico ............................................................................................. 34

3.2 Modelo de Base dados....................................................................................... 35

3.2.1 Modelo físico de dados ................................................................................ 35

3.3 Diagrama de Componentes ............................................................................... 36

3.4 Padrões de arquitetura ....................................................................................... 37

3.4.1 Modelo Vista Controlador (MVC) ................................................................. 37

3.5 Padrões de Desenho.......................................................................................... 39

3.5.1 Padrão (GRASP) ......................................................................................... 39

3.6 Modelo de despliegue (implantação).................................................................. 41

3.7 Estândares de codificação ................................................................................. 43

3.8.1 Estratégia de Prova ..................................................................................... 44

3.8.2 Provas unitárias ........................................................................................... 44

3.8.3 Provas funcionais ........................................................................................ 46

3.8.4 Resultados das provas ................................................................................ 49

3.9 Conclusões parciais ........................................................................................... 50