INSTITUTO SUPERIOR DE TECNOLOGIAS DE INFORMAÇÃO

E COMUNICAÇÃO

TRABALHO DE FIM DE CURSO DE LICENCIATURA EM

ENGENHARIA INFORMÁTICA

SISTEMA DE GESTÃO DE INFORMAÇÃO DE ACIDENTES

RODOVIARIOS DE LUANDA PARA DNVT

AUTOR:

FELICIANA FERNANDO TCHALANGALA NEQUETELA

LUANDA, 2020
INSTITUTO SUPERIOR DE TECNOLOGIAS DE INFORMAÇÃO
E COMUNICAÇÃO

TRABALHO DE FIM DE CURSO DE LICENCIATURA EM

ENGENHARIA INFORMÁTICA

SISTEMA DE GESTÃO DE INFORMAÇÃO DE ACIDENTES

RODOVIARIOS DE LUANDA PARA DNVT

AUTOR:

FELICIANA FERNANDO TCHALANGALA NEQUETELA

TUTOR:

MSC. YANELIS BENITEZ FERNANDES

LUANDA, 2020
Dedicatória
Dedico este trabalho a Deus, pois se não fosse sua presença em minha vida eu não
chegaria até aqui. A meu pai Aurelio que tem sidoum leal sacerdote, a minha mamã
Anabela responsável pela minha conquista, que mesmo espiritualmente esteve sempre
presente em minha vida. A meu noivo Flávio pelo carinho, apoio e compreensão nos
momentos em que esteve distante e a todos que me auxiliaram no desenvolvimento
deste trabalho.

Dedico também de forma especial a Natália Virgílio Manuel a todos meus

familiares,colegasl,amigos e irmãos da mesma fé cristã que de forma direita ou indirecta
me ajudaram no decorrer dos meus estudos.

i
AGRADECIMENTOS
Agradeço primeiramente a Deus, pela sua omnisciência, pelo folego de vida, pelas
bênçãos necessárias e pelo cuidado prestado a mim durante todo o meu percurso
estudantil, sendo a base de todo conhecimento e fé em minha vida.

Minha gratidão estende-se aos meus pais Aurelio Zacarias Nequetela e Anabela
M.Suquina Nequetela, por terem dedicado a mim imenso amor e por terem me ensinado
a ter fé, a acreditar em meus objetivos e a lutar por eles com dignidade e honestidade.
Ao meu noivo Fláviano Kupenala Longuenda, pela preocupação, apoio, carinho e
compreensão dedicados a mim em todos os momentos deste percurso. Ao meu tio
Marcos . A meus irmãos José Fernando, Jorge, Márcia, Adilson Sérgio,Nério e Tércia,
pessoas que amo muito e para quem eu pretendo ser exemplo. Aos meus familiares
Sara, Lucrecia pela ajuda, compreensão e paciência na realização deste trabalho. Aos
professores do Curso de Eng. Informática do ISUTIC, a carísima professora Yanelis
Benitez Fernandes, por ter me orientado neste trabalho e por ter me transmitido parte de
seu conhecimento. Ao pessoal da secretaria em particular a professora Paula pessoas
que respeito e admiro pela competência profissional que possuem, por terem aceitado
contribuir com este trabalho. Aos proprietários e funcionários da DNVT onde foi realizada
a pesquisa pela contribuição e permissão para que o trabalho fosse concretizado e por
terem me recebido gentilmente durante a coleta de dados.As colegas de classe e não so
em especial o Alberto Paulo pelos momentos de parceria, amizade e descontração no
percorrer deste curso. E a todas as pessoas que de alguma maneira contribuíram para a
realização desta pesquisa.

Minha eterna gratidão!!!!.

ii
RESUMO
Apesar das medidas e políticas em matéria de segurança rodoviária, os acidentes
continuam a representar um grave problema da actualidade, quer na perspectiva
económica devido aos avultados custos e recursos envolvidos, quer na perspectiva
social, tendo em conta o número de vidas humanas perdidas a cada ano. Os custos
tangíveis e intangíveis em causa são, de facto, inaceitáveis em qualquer sociedade
moderna.

A actual situação rodoviária em Angola constitui uma grande preocupação para os

órgãos dirigentes. O número de acidentes rodoviários cresce a cada ano envolvendo
pessoas com idade produtiva. A sinistralidade rodoviária tem atingido proporções
alarmantes em todo mundo, principalmente, nos países em vias de desenvolvimento. Por
isso, o impressionante quadro das vias de trânsito deve ser assumido como uma
preocupação de todos e deve merecer um maior empenho de todas as entidades
públicas e privadas que têm aquela responsabilidade, particularmente do Estado
angolano, que se encontra em franco desenvolvimento nesta área. Ter e divulgar as
informações disponíveis sobre os acidentes rodoviários são importantes para a tomada
de decisão e não só.

As Tecnologias de Informação e Comunicação (TICs) têm contribuído para evolução do

mundo em diversos domínios da vida, principalmente na divulgação de informações, com
base nisto, desenvolveu-se um Sistema de Gestão de Informação de Acidentes
Rodoviários em Luanda para DNVT, que auxiliara na divulgação e controle dos acidentes
rodoviários.

Palavras-chave: Sistema, Acidentes Rodoviários, sinistralidade, Controle, TICs,

Divulgação.

iii
ABSTRACT
Despite road safety measures and policies, accidents continue to present a serious
current problem, both from an economic perspective due to the large costs and resources
involved, and from a social perspective, taking into account the number of human lives
lost to each year. The tangible and intangible costs involved are, in fact, unacceptable in
any modern society.

The current road situation in Angola is a major concern for the governing bodies. The
number of road accidents grows every year involving people of working age. Road
accidents have reached alarming proportions around the world, mainly in developing
countries. For this reason, the impressive picture of the transit routes must be assumed
as a concern for everyone and must deserve a greater commitment from all public and
private entities that have that responsibility, particularly from the Angolan State, which is
in full development in this area. Having and disseminating available information about
road accidents is important for decision making and beyond.

Information and Communication Technologies (ICTs) have contributed to the evolution of

the world in several areas of life, mainly in the dissemination of information, based on
this, a Road Accident Administration of Information System was developed in Luanda for
DNVT, which had helped in the dissemination and control road accidents.

Keywords: System, Road Accidents, loss ratio, Control, ICT, Disclosure.

iv
ÍNDICE GERAL
INTRODUÇÃO .................................................................................................................. 1
1 CAPITULO 1: FUNDAMENTAÇÃO TEÓRICA ........................................................... 6
1.1 Principais conceitos associados ao objecto de estudo......................................... 6
Sistema ....................................................................................................................... 6
Gestão ........................................................................................................................ 6
Sistemas de Gestão da Informação ............................................................................ 6
Acidente ...................................................................................................................... 7
Os principais elementos do sistema de segurança rodoviária .................................... 8
O VEÍCULO .............................................................................................................. 10
A Classificação e Tipos de Veículos ......................................................................... 10
O HOMEM ................................................................................................................ 10
O Estado Físico e Psicológico dos Utentes das Vias ............................................... 10
A POLÍCIA NACIONAL DE ANGOLA (PNA) ............................................................ 13
1.2 Soluções existentes ........................................................................................... 14
1.3 Metodologia utilizada.......................................................................................... 15
Metodologias Pesadas.............................................................................................. 16
Metodologias Ágeis .................................................................................................. 16
1.4 Ferramentas usadas .......................................................................................... 18
Linguagem Java ....................................................................................................... 18
PostgreSQL 9.4 ........................................................................................................ 19
Netbeans IDE 8.2 ..................................................................................................... 20
Visual Paradigm 13 ................................................................................................... 21
Ireport 7.0 ................................................................................................................. 22
Conclusão Parcial ........................................................................................................ 22
2 CAPÍTULO 2: CARACTERÍSTICAS DO SISTEMA. ................................................. 24
2.1 MODELAGEM DO NEGÓCIO ............................................................................ 24
Modelo conceptual ou domínio. Descrição do negócio ............................................. 24
Diagrama de Casos de Uso do Negócio ................................................................... 25
Descrições dos Casos de Uso do negócio ............................................................... 25
2.2 MODELAGEM DO SISTEMA ............................................................................. 26
Especificação de Requerimentos do Sistema ........................................................... 26
Diagrama de Casos de Uso do Sistema ................................................................... 28

v
 Conclusões Parciais..................................................................................................... 33
3 CAPÍTULO 3: DESENHO E IMPLEMENTAÇÃO DO SISTEMA. .............................. 34
3.1 Diagrama de Classes. ........................................................................................ 34
3.2 Análise e desenho do Banco de Dados. ........................................................... 34
Descrição das Entidades .......................................................................................... 36
3.3 Modelo de Implantação. ..................................................................................... 37
Diagrama de implantação ......................................................................................... 37
Descrição do modelo de implantação do sistema ..................................................... 37
3.4 ARQUITECTURA DO SISTEMA E PADRÃO DE DESENHO UTILIZADO. ....... 38
Modelo Vista Controlador (MVC) .............................................................................. 38
Padrão de Desenho Utilizado ................................................................................... 39
3.5 PRINCIPAIS INTERFACE DO SISTEMA........................................................... 40
Conclusões Parciais..................................................................................................... 42
4 CAPÍTULO 4: PROVAS DO SISTEMA. .................................................................... 43
4.2 Descrição do processo de provas de funcionamento ......................................... 43
Provas de caixa preta. Técnica de Partição Equivalente .......................................... 45
4.2 Resultados das Provas ...................................................................................... 47
Conclusões parcias. ..................................................................................................... 48
Conclusões...................................................................................................................... 49
Recomendações ............................................................................................................. 50
Referências bibliográficas. .............................................................................................. 51
Anexos ............................................................................................................................ 54
Anexo A. Provas. ......................................................................................................... 54

vi
ÍNDICE DE FIGURAS
Figura 1-A triangular relação dos principais elementos da circulação rodoviária. ............. 9
Figura 1.2 - Ciclo de vida do OpenUP ............................................................................. 18
Figura 1.3 - Java ............................................................................................................. 19
Figura 1.4 - PostgreSQL ................................................................................................. 20
Figura 1.5 - NetBeans ..................................................................................................... 21
Figura 1.6 - Visual Paradigm ........................................................................................... 21
Figura 1.7 - Ireport........................................................................................................... 22
Figura 2.1 - Modelo de Dominio ...................................................................................... 25
Figura 2.2 - Diagrama de Caso de Uso do Negócio ........................................................ 25
Figura 2.3 - Diagrama de caso de uso do sistema .......................................................... 29
Figura 3.1 - Diagram de classe. ...................................................................................... 34
Figura 3.2 : Desenho do Banco de Dados. ..................................................................... 36
Figura 3.3 : Diagrama de implantação do sistema .......................................................... 37
Figura 3.4 - Arquitectura do sistema MVC ...................................................................... 39
Figura 3.5 - Tela de cadastro de utilizadores .................................................................. 40
Figura 3.6 - tela de cadastro de níveis dos agentes ........................................................ 41
Figura 3.7 - Tela de cadastro de causas de acidentes .................................................... 41
Figura 3.8 - Tela de cadastro de agentes regulador de trânsito ...................................... 41
Figura 4.1 - Resultados das provas ................................................................................. 48
Figura A1 – Validação do registro de Agente .................................................................. 54

vii
ÍNDICE DE TABELAS
Tabela 2.1 - Descrição do Caso de Uso de Negócio – Solicitar Registro de Acidente .... 25
Tabela 2.2 - Requisitos Funcionais ................................................................................. 26
Tabela 2.3 - Requisitos não Funcionais .......................................................................... 28
Tabela 2.4 - Actores do Sistema ..................................................................................... 29
Tabela 2.5 - Casos de uso do sistema - Cadastrar usuário ............................................ 29
Tabela 2.6 - Casos de uso do sistema - Cadastrar agente regulador de trânsito ........... 31
Tabela 3.1 - Descrição das entidades do modelo fisico de banco de dados .................. 36
Tabela 3.2 - Nós do modelo de implementação do sistema ............................................ 37
Tabela 3.3 - Conectores do modelo de implementação do sistema ................................ 38
Tabela 4.1 - Cenário de prova de caixa preta ................................................................. 46

viii
LISTA DE ABREVIATURAS E SÍMBOLOS
CU - Caso de Uso

ER - Entidade Relação

HTML - Hyper Text Markup Language

HTTP - Hyper Text Transfer Protocol

MVC - Model View Controller

OpenUp - Open Unified Process

PHP - Hypertext Preprocessor

RF - Requisito Funcional

RNF - Requisito Não Funcional

SGBD - Sistema Gerenciador de Banco de Dados

SQL - Structured Query Language

UML - Unified Modeling Language

XP - Xtreme Programming

ix
INTRODUÇÃO
A fatalidade nas estradas é um dos graves problemas que as sociedades enfrentam.
Todos os dias homens e mulheres morrem em consequência dos acidentes de viação.

A sinistralidade rodoviária tem atingido proporções alarmantes em todo mundo,

principalmente, nos países em vias de desenvolvimento. Por isso, o impressionante
quadro das vias de trânsito deve ser assumido como uma preocupação de todos e deve
merecer um maior empenho de todas as entidades públicas e privadas que têm aquela
responsabilidade, particularmente do Estado angolano, que se encontra em franco
desenvolvimento nesta área.

Os problemas que condicionam a segurança rodoviária ou que contribuem para a densa

sinistralidade nas vias rodoviárias não convergem num único elemento do sistema mas,
sabe-se que existem certos comportamentos e atitudes imprudentes por parte de muitos
condutores, peões e passageiros que desrespeitam as regras do código da estrada e de
convivência social, nomeadamente, a velocidade excessiva, as manobras perigosas, a
condução sob efeito de álcool ou drogas, a má ou não utilização do cinto de segurança –
e, em parte, as condições técnicas da via e dos veículos que, de forma directa ou
indirecta são também concorrem para a verificação de alguns acidentes de viação.

Com base neste quadro crítico, podemos apontar o ambiente rodoviário como um
autêntico campo de batalha onde as estradas têm sido transformadas num verdadeiro
palco de acção, e os veículos usados como potenciais armas letais, sendo os recursos
humanos e materiais não passam de alvos a serem atingidos.

Ter e divulgar as informações disponíveis sobre os acidentes rodoviários são importantes

para a tomada de decisão e não só.

As Tecnologias de Informação e Comunicação (TICs) têm contribuído para evolução do

mundo em diversos domínios da vida, principalmente na divulgação de informações.
Com o passar dos anos, as instituições tendem a se informatizar e a buscar soluções
mais adequadas para gerenciar seus serviços. Dentre os vários, os sistemas on-line
baseados na Web têm sido uma das soluções mais procuradas por pequenas e médias
empresas pela facilidade de uso, flexibilidade e portabilidade, podendo ser acessado de
qualquer lugar que tenha conexão com a internet.

1
Esse tipo de sistema precisa apenas de um navegador para ser executado, não requer
instalação ou actualização de software, podendo rodar em qualquer plataforma. A menor
necessidade de processamento do sistema não exige que o cliente troque a sua
máquina para executar o sistema, facilitando e diminuindo os gastos com hardware e
software.

A flexibilidade traz ao usuário uma interacção maior com o sistema, podendo adaptá-lo
conforme sua necessidade. O suporte torna-se mais fácil, pois não há necessidade de
deslocar um técnico ao local.

A Direcção Nacional de Viação e Transito situada em Luanda até o momento não conta
com o auxílio de um sistema. Ela sente a necessidade de informatizar-se para poder
melhorar o gerenciamento das suas actividades.

Ter e divulgar informações em uma determinada instituição é algo muito importante e

relevante, além de ser um passo a frente para as organizações. Isto torna-se difícil
quando, não se tem um sistema real para tal, logo ficam visíveis os diversos problemas
que a DNVT apresenta.

Todo o processo de gerência das actividades, é feito manualmente, utilizando fichas que
possuem as informações provocando situações problemáticas como:

• Dificuldade na organização e divulgação de informação,

• Deterioração do material,
• Aglomeração de papéis,
• Perda de informação,
• Anotações ilegíveis,
• Conflitos de dados,
• Demora nas buscas.

A instituição (DNVT) não explora o potencial de internet e dos serviços electrónico

existente.

Pelos motivos descritos acima e não só surge o seguinte problema de investigação:

Como facilitar a gestão e acesso da informação da DNVT, de maneira que se garanta a
agilidade, organização e disponibilidade da maior quantidade de informação?

O objecto de estudo processo de controlo, organização e divulgação de informação.

2
O campo de acção Aplicativo Informático para Controle, organização e divulgação de
informação da DNVT.

Para tal temos como objectivo geral desenvolver um sistema de informação para DNVT
para melhorar o controlo, a organização e divulgação de informação sobre os acidentes
rodoviários de Luanda.

Temos como objectivos específicos:

• Elaborar o marco teórico-referençial relacionado com processos de gerenciamento

de acidentes rodoviários e sua confeição inerente aplicações informáticas.
• Seleccionar a metodologia, ferramenta e tecnologia de desenvolvimento a utilizar.
• Desenhar um aplicativo informático para controle de acidentes rodoviários para a
DNVT
• Avaliar a eficiência da solução proposta aplicando as provas de software.

A ideia a defender é que: Com a implementação de um Sistema de Gestão de

Informação de Acidentes Rodoviários em Luanda para DNVT é possível melhor o
controlo, organização e divulgação de informação sobre os acidentes e de certa maneira
facilitar e agilizar a obtenção da informação.

Tarefas de investigação

1. Estudar o funcionamento da gestão de informação de acidentes rodoviários;

2. Pesquisar o conceito e características de acidentes;

3. Analisar os sites/sistemas com funções similares a do projecto proposto;

4. Estudar as tecnologias para o desenvolvimento de sistemas;

5. Análise dos requisitos funcionais e não funcionais;

6. Construção e implementação do projecto para o módulo de gestão de informação;

7. Teste e validação do comportamento do módulo de gestão de informação;

8. Documentação do desenvolvimento e o resultado do módulo de gestão de

informação.

Empregam-se os métodos científicos da investigação:

Empíricos.

3
Teóricos.

Dos métodos empíricos se utilizam:

Entrevista: realizaram-se a trabalhadores, que se vêem imersos no processo de

funcionamento da gestão de informação de acidentes rodoviários.

Dos métodos teóricos se utilizam:

Analítico-Sintético: A aplicação deste método permitiu a busca, investigação e análise

dos documentos necessários para entender o processo que se leva a cabo na gestão de
informação de acidentes rodoviários. Também se conferiram diferentes fontes
bibliográficas.

Análise Histórica-Lógica: Utiliza-se para conhecer os antecedentes e elementos da

investigação referidos aos processos de planeamento e controle e a determinação das
tendências atuais sobre a temática que se estuda (Hernández, Rolando; León e Coello,
Alfredo; González, Sayda, 2011). Seu emprego permitiu pesquisar a respeito das
ferramentas informáticas existentes em Angola e no mundo.

A documentação das etapas e procedimentos para realização do trabalho aconteceu na

medida em que cada etapa foi realizada. A seguir, são descritas as principais etapas
realizadas no trabalho:

Levantamento bibliográfico: sobre acidentes rodoviários, sua evolução nos últimos

anos, conceituação sobre sistemas.

Busca por plataformas: foi realizado levantamento, principalmente por meio de buscas
na Internet, sobre plataformas disponíveis para facilitar a criação do sistema.

Definição de critério para selecção das plataformas: inicialmente optou-se por

delimitar o estudo a plataformas open source, e posteriormente, buscou-se dentre estas
a mais utilizada mundialmente nos últimos anos, para então realizar o desenvolvimento
do sistema com a plataforma escolhida.

O documento tem Introdução, três capítulos, conclusões, recomendações e referências

bibliográficas.

4
Capítulo 1: 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 Sistema. Também se definem as ferramentas,
metodológicas e tecnológicas a utilizar durante o desenvolvimento do sistema.

Capítulo 2: Análise e Desenho do Sistema. É neste capítulo onde se apresenta uma

descrição geral da solução proposta, definem-se os requisitos funcionais e não
funcionais dentre outros elementos importantes.

Capítulo 3: Implementação e provas do sistema de Sistema. Neste capítulo se abordam

aspectos relacionados com a implementação do sistema em base à arquitectura de
desenvolvimento de software.

Capítulo 4: Realizam-se provas de caixas brancas e pretas para garantir a

confidencialidade e detectar possíveis falhas no sistema.

5
 1 CAPITULO 1: FUNDAMENTAÇÃO TEÓRICA
Neste capítulo são abordados os itens que serviram de apoio para o desenvolvimento
deste projecto de pesquisa. O objectivo é conhecer o que é um acidente rodoviário, um
sistema de gestão, a sua importância, suas características e classificações. Também
vamos ver as ferramentas, métodos e tecnologias utilizadas e soluções similares as do
projecto.

O tema a seguir fala-nos sobre a temática do acidente rodoviário, sobre o seu

surgimento, as diferentes abordagem de diferentes autores e os diferentes tipos.

1.1 Principais conceitos associados ao objecto de estudo

Sistema

Um sistema é um conjunto de elementos interdependentes de modo a formar um todo

organizado. É uma definição que acontece em várias disciplinas, como biologia,
medicina, "informática", administração, direito. Vindo do grego o termo "sistema" significa
"combinar", "ajustar", "formar um conjunto".

O sistema é um conjunto de órgãos funcionais, componentes, entidades, partes ou

elementos e as relações entre eles, a integração entre esses componentes pode se dar
por fluxo de informações, fluxo de matéria, fluxo de sangue, fluxo de energia, enfim,
ocorre comunicação entre os órgãos componentes de um sistema.

Gestão

Gestão significa gerenciamento, administração, onde existe uma instituição, uma

empresa, uma entidade social de pessoas, a ser gerida ou administrada. O objectivo é
de crescimento, estabelecido pela empresa através do esforço humano organizado, pelo
grupo, com um objectivo específico. As instituições podem ser privadas, sociedades de
economia mista, com ou sem fins lucrativos (Kruthiventi, 2012).

Sistemas de Gestão da Informação

Os Sistemas de Gestão da Informação são encarregados da segurança e protecção da

informação que manejam, e estão desenhados com o propósito de proteger os activos
informáticos de uma determinada instituição. Alguns autores conceitualizaram sobre
estes sistemas.

6
 • Processo mediatizado por um conjunto de actividades que permitem a obtenção
de informação, o mais pertinente, relevante e económica possível, para ser usada
no desenvolvimento e o sucesso de uma organização.

• Um Sistema de Gestão de Informação permite a gestão dos recursos de

informação tanto internos como externos. Sua finalidade é gerar serviços e
produtos que respondam às necessidades e ultrapassem as expectativas dos
usuários, possibilitando que o sistema trabalhe eficientemente e economicamente
ao mesmo tempo. O Sistema de Gestão de Informação aproveita ao máximo seus
recursos de informação em função da melhora contínua e da tomada de decisões
organizacional a todos os níveis hierárquicos desde a estratégica até a base
operativa (Ecured, 2015).

• Servem para o registo das transacções diárias e a geração que apresentam

informação, relevância, clareza, singeleza e oportunidade de tal forma que seja
útil para as pessoas a quem se lhes entrega. Vê-se seu uso em muitas empresas,
que vão desde uma classificação de micro até grande empresa; no entanto, a
aplicação em cada uma pode variar devido à magnitude de actividades da
mesma, não assim por seu tamanho (Scribd, 2015).

Acidente

O acidente de viação é “a ocorrência na via pública ou que nela tenha originado

envolvendo pelo menos um veículo, do conhecimento das entidades fiscalizadoras (…) e
que resulta vítimas e/ou danos materiais”. (Revista da DGV, 2005)

Para Monteiro (2009: 16), “atribui-se habitualmente ao acidente uma causa única, por
exemplo a velocidade ou álcool. No entanto o acidente é consequência de uma
acumulação de pequenos elementos ou factores [pavimento escorregadio, pneus
gastos].

Neste sentido, apesar das diversas e confluentes definições sobre o conceito de risco,
detectei à especificação de Pinto (2006: 34), dizendo que ” (…) o acidente é tal como o
risco, relativamente recente, tendo sido construído no mesmo processo da modernização
que expandiu o conceito de acidente”.

7
Do que se retira do exposto e a título complementar defini o acidente de viação como um
evento súbito e imprevisível que ocorre na via pública resultante da falha de pelo menos,
um dos principais elementos do sistema de segurança rodoviária e susceptível de causar
danos de natureza patrimonial ou corporal de quem vai ao volante ou aos demais
utentes da via pública.

No entanto, a circulação rodoviária, enquanto acto de relevante importância e interacção

social, apresenta riscos que naturalmente não podem ser eliminados na totalidade. Mas,
de certa forma, podem ser minimizados mediante adopção de políticas multissectoriais
de segurança rodoviária.

O acidente que envolve apenas um veículo pode ser classificado segundo a posição das
rodas em relação à faixa de rodagem, podendo ser:

a) Despiste - acidente em que as rodas do veículo abandonam a faixa de rodagem

sem perder o contacto com o solo. Trata-se de um acontecimentos que não
depende da vontade do condutor.

b) Capotamento - é o acidente em que o veículo perde a sua posição normal.

c) Colisão - é todo acidente em que resulta do embate entre, pelo menos, dois o
veículo em movimento.

d) Choque - é um acidente em que o veículo bate contra um elemento fixo ou móvel

que se encontra na via. Porém também se considera choque o embate entre um
veículo em movimento e o outro que se encontra estacionado.

e) Atropelamento - é o acidente em que o veículo colide contra uma ou mais

pessoas, provocando a morte ou ferimentos.

A seguir abordarei sobre a caracterização do sistema de segurança rodoviária em

Luanda e os principais elementos do si os principais elementos do sistema de segurança
rodoviária.

Os principais elementos do sistema de segurança rodoviária

Em toda parte do mundo o automóvel actualmente é muito mais do que um meio de

transporte, o automóvel é do ponto de vista sociológico e tecnológico um dos objectos
primários para realização humana, no seu desenvolvimento e na sua actuação em

8
comunidade. Logo, é desta interacção social que urge a necessidade de conciliar a
segurança do trânsito, como condição vital para o nosso bem-estar.

Pinto (2007:110), considera o exercício da condução como um acto que está sujeito às
mesmas regras de interacção entre indivíduos de uma sociedade, para além das regras
que estão criadas nos códigos de trânsito”.

Porém, é certo que a condução é uma actividade complexa que exige ponderação por
parte do condutor que sofre influência dos demais utentes da via e do espaço onde se
encontra a circular. Assim, não se pretende com a mesma, a realização de uma acção
devastadora de vidas humanas, nem tão pouco uma acto para desapropriar bens
materiais do próprio condutor ou de outrem. Todavia, este exercício pode ser realizado
em segurança, melhor, sem perdas de vidas humanas, sem restrições à liberdade e sem
qualquer dano desde que, imprescindivelmente, sejam adaptadas medidas que visam
exigir a observância e cumprimento das regras de trânsito rodoviário.

Como temos vindo a apontar, as causas dos acidentes de viação, ou vulgarmente

conhecido por acidente de trânsito, serão deduzidas aos três principais factores, que
constituem o sistema de circulação rodoviária, dos quais a via (incluindo o ambiente
rodoviário ou meio ambiente); o veículo e o Homem, (Figura 1).

VIA

HOMEM
VEÍCULO

Figura 1-A triangular relação dos principais elementos da circulação rodoviária.

Embora cada um dos elementos referidos apresentem categorias e valores diferentes em

participação e intensidade no acidente, entendemos que a via existe para o veículo e
este por sua vez existe para o Homem, possibilitando - o mais deslocação do que
qualquer outro meio de transporte conhecido.

9
Assim, articulando os três principais elementos da circulação rodoviária num único
estratagema, que aqui designamos por Sistema de Segurança Rodoviária, o Homem
constitui um factor preponderante, por possuir faculdades físicas e cognitivas que lhe
permitem escolher o comportamento adequado para melhor utilizar a via e o veículo, que
são frutos da tecnologia, à sua disposição.

É essa a razão porque deve ser dito que a segurança no sistema de circulação
rodoviária depende do equilíbrio entre a interacção das exigências, do ambiente
rodoviário, das condições técnicas do veículo e das capacidades de respostas do
condutor face ao meio em que se entra em trânsito.

A seguir será abordado sobre os veículos suas classificações e os diferentes tipos.

O veículo

Veículo é uma expressão oriunda do vocábulo em latim vehiculum, entretanto, a nossa

legislação rodoviária define-o como meio de circulação que possui um motor de
propulsão, provido de pelo menos quatro rodas. Este possui uma tara superior 550Kg, a
sua velocidade é por construção superior a 25 Km/h e se destina, pela sua utilidade, a
circular na via pública sem sujeição a carris.

A Classificação e Tipos de Veículos

Quanto a sua classificação o veículo pode ser ligeiro ou pesado. Trata-se de um veículo
ligeiro quando o seu peso bruto é igual a 3.500 Kg, com lotação não superior a nove
lugares, incluindo o automobilista ou condutor. O veículo pesado tem 3.500 Kg de peso
bruto e a sua lotação é superior a nove lugares, incluindo o condutor.

Quanto ao tipo, os veículos podem ser: de passageiros, de mercadoria, mistos, tractores,

especiais, etc.

O homem

O Homem é inquestionavelmente o actor principal: como peão, condutor ou passageiro.

Ele é o garante das suas responsabilidades, pois que é ele que controla o veículo em
determinadas vias, logo é do seu comportamento que pode evitar, em grande escala, as
causas dos acidentes de viação.

O Estado Físico e Psicológico dos Utentes das Vias

10
O condutor sempre que estiver ao volante de um veículo, deve fazê-lo dentro das suas
capacidades físicas e psicológicas. A saúde, a acuidade intelectual, a rapidez dos seus
reflexos, são capacidades essenciais que ao serem afectadas por certas substâncias
(álcool, drogas ou medicamentos), diminuem ou alteram de forma profunda a
coordenação motora e consequentemente a rapidez de resolução de qualquer situação
inesperada que possa surgir na estrada.

Importa, no entanto sublinhar que o condutor tem o dever de abster-se de qualquer acto
que possa influenciar de forma negativa o exercício da condução e, não procedendo de
acordo com os ensinamentos exigidos para tal complexa tarefa, se mostre
imprudente, omita de forma voluntária o dever geral de diligência que consiste em
salvaguardar a paz na estrada. Entretanto, a condução pode ser influenciada por dois
factores: factores físicos e factores psicológicos.

a) Os factores físicos

O homem recebe informações através de diferentes órgãos sensórias que também

podem ser entendidos por sentidos. Qualquer irregularidade ou disfunção nos sentidos
podem tornar imprevisíveis os resultados das nossas formações mentais.

Contudo, no que concerne à segurança rodoviária, apenas demos relevância os dois

primeiros sentidos, ou seja, à visão e à audição que assumem aqui um papel
preponderante. Foram aqui tratados alguns aspectos ligados ao sono e a fadiga.

• Visão: a visibilidade de um condutor não pode ser reduzida ou insuficiente. Esta é

considerada a mais importante entre as demais faculdades do condutor, pois
permiti-lhe identificar as informações e reagir em função das mesmas. Através da
sensibilidade ao contraste o condutor determina e percebe certos objectos com
diversos níveis de contrastes (veículos, pessoas, sinais de trânsito e outros) e, por
sua vez, a visão periférica permite – lhe identificar, ver o ambiente ao seu lado e
perceber os objectos que se encontram em lugares diferentes. É pelo olhar que
temos a percepção da realidade que nos circunda. Ainda neste âmbito é de
realçar que a condução nocturna é particularmente fatigante, pois, além de todas
as cargas que a condução comporta as condições de visibilidade são dificultadas
pela falta de iluminação em muitos percursos e pelos encandeamentos
provocados pelos outros veículos.

11
• Audição: o som é aquilo que ouvimos, no entanto, existem situações em que a
atenção aos sons deve ser maior, em caso, quando o condutor se encontra a
transitar na via pública. Para que a condução seja feita em segurança o condutor
deve estar atento aos factores internos e externos que podem interferir na
segurança do tráfego.

• Sono: a capacidade de reacção perante situações adversas pode ser afectada

pelo sono. Alguns autores, consideram o sono como um problema semelhante ao
álcool que dificulta a atenção dos condutores (Chipman & Jin Yeu 2009:1). Assim,
este estado que não pode ser normal para quem tenha que dirigir um veículo em
segurança. Em fim, o sono faz parte das principais causas dos acidentes e a ele
estão quase sempre associados um conjunto de factores que o potencia,
nomeadamente a idade, o regime de trabalho (alternado dia e noite) e o estado
psicofísicos.

• Fadiga: esta expressão é usada para descrever o estado do corpo quando

submetido a um determinado esforça. Esta também tem grande relevância nas
causas dos acidentes e está relacionada com as condições ergonómicas dos
assentos e instrumentos de comando, bem como as condições e qualidade das
estradas. Os seus efeitos registam-se na diminuição do grau de vigilância,
atenção, precisão e rapidez da resposta. Consequentemente, aumenta o tempo
de resposta e o número de manobras em casos de emergência. Porém, tanto a
visão como a audição são diversas vezes afectadas pelo sono e pela fadiga
porque conduzir um veículo pressupõe estar na via durante algum tempo e
realizar esforços físicos e mentais.

b) Os factores psicológicos

• Stress: Certos comportamentos podem influenciar a forma como interagimos no

trânsito rodoviária, nomeadamente, os problemas com a família, excesso de
trabalho e outros. Em suma, o Stress é uma resposta às exigências dos meios,
sobretudo, quando se trata de exigências superiores as capacidades de resposta.

• Depressão: Comparada ao stress, esta diminui a vitalidade e aumenta a tristeza,

ou seja, este factor diminui o sentimento de valoração da vida e do futuro, como
fonte de inspiração.

12
 • Ansiedade: é a emoção sustentada pela ideia de sobrevivência e, é um factor que
permite o organismo reagir em fuga, nos casos de perigo ou de luta.

• Condução sob influência de substâncias legalmente consideradas como

entorpecentes: As substâncias são responsáveis pela redução da do condutor e
aumentam consideravelmente o risco de sofrer ou de causar acidentes de viação.

• Condução sob influência de Álcool: A ingestão de bebidas alcoólicas é um grave

problema para a condução. O estado de embriagues reduz capacidades de
atenção e percepção, diminui a capacidade de prever os riscos e de tomar as
decisões que se julgam adequadas para fazer cessar o perigo em tempo útil de
reacção e também a reflexão das distâncias e velocidades ficam afectadas. Enfim,
o consumo de bebidas alcoólicas em quantidades superior ao previsto, potenciam
o estado de fadiga e coordenação psicomotora do condutor.

A Polícia Nacional de Angola (PNA)

A PNA é uma Força de Segurança uniformizada e armada, una em todo território

nacional, com natureza de serviço público, dotada de autonomia administrativa e, tem
como missão a segurança interna do país. Compete-lhe defender a legalidade
democrática; a manutenção da ordem e tranquilidade públicas; o respeito pelo exercício
dos direitos e liberdades fundamentais dos cidadãos.

A sua estrutura de comando divide-se em três áreas principais: Comando Geral,

Comandos Provinciais e Comandos Municipais.

a) Direcção Nacional de Viação e Trânsito (DNVT)

A DNVT é um órgão central do Comando Geral da Polícia Nacional, ao qual compete

zelar pelo cumprimento das leis do trânsito rodoviário em todo território nacional, é
responsável pela garantia da segurança, controlo e prevenção de acidentes de viação;
controlo do parque automóvel; organização do cadastro dos condutores e das contra-
ordenações correspondentes à legislação rodoviária; licenciamento e inspecção das
escolas de condução e atribuição de matrículas.

b) Unidades de Trânsito

13
O CGPN está representado em todas províncias através dos Comandos Provinciais,
deste modo, cada comando Provincial possui um órgão responsável pela segurança e
fiscalização do trânsito rodoviário.

A Unidade de Trânsito de Luanda é o órgão do Comando Provincial a quem compete

zelar pela segurança e fiscalização do trânsito do centro urbano.

c) Brigada Especial de Trânsito (BET)

A BET, é a Força Policial integrada no Comando Geral da Polícia Nacional, este serviço
tem caracter operacional e/ou especial. O Comandante tem a categoria de Director
Nacional. É competente para prevenir e fiscalizar o trânsito rodoviário em todo território
nacional. Tendo em conta a sua especificidade, quer em termos de recursos materiais,
quer em termos de recursos humanos, é responsável pela ordem e tranquilidade
rodoviárias na zona da periferia da Cidade de Luanda e também assegura as principais
estradas nacionais, nomeadamente (EN). A EN-100 que permite a ligação entre a
província de Luanda a Província do Kwanza – Sul, EN- 230 que permite o trânsito entre
a província de Luanda a Província do Bengo e a EN- 250, que estabelece a
comunicação terrestre entre a Província de Luanda a Uíge. Mas na realidade, esta força
policial é responsável pela segurança de todas as estradas nacionais do país.

A seguir abordarei sobre alguns sistemas já existentes que estão relacionados com as
características que o projecto em causa apresenta.stema de segurança rodoviária.

1.2 Soluções existentes

Nesta secção serão apresentados exemplos de sistemas similares ao projecto proposto,

exibindo a apresentação de cada um, a organização, técnicas de recomendação caso
existam e os diferenciais que proporcionam.

Nacionais.

• Sehundo a Angop (Angop, 2018), existe um sistema de armazenamento de

informações sobre desastreas naturais, pertencente ao O Serviço de Protecção
Civil e Bombeiros de Angola.

Internacional

14
 • O Sistemas de Gestão de segurança rodoviária (RTS) permite que uma
organização garanta a segurança rodoviária com o objetivo de reduzir e eliminar a
morte e os ferimentos graves relacionados com acidentes rodoviários
(Ursportugal, 2020).

• Sistema de Gestão de Acidentes: Ciclo de vida completo de acidentes é

gerenciado em uma única plataforma, reduzindo o risco, e garantindo
conformidade. Sua flexibilidade significa que cada indústria ou departamento pode
usar o software para o registro e monitoramento de todas informações
relacionadas a acidentes (nosa-ims, 2020).

Captar acidentes: Um sistema de gestão baseado na web que permite ao

usuário captar e registrar qualquer tipo de acidente ou incidente e todos os
detalhes relacionados. Desenvolvido e aperfeiçoado por profissionais de
segurança, capacita as organizações a coletar dados abrangentes de acidentes,
implementar ações corretivas, e garantir a notificação apropriada de acidentes até
a cadeia de comando.

Investigações técnicas: Várias técnicas de investigação de acidentes estão

incluídas no programa, assegurando que todas as fases de investigação sejam
cobertas. Materiais adicionais, fotografias, documentos digitalizados e outros
multimídias podem ser anexados ao registro. O sistema pode ser padronizado
para expandir o processo de investigação em níveis diferentes de gestão
baseados em níveis de gravidade.

Análise de frequência: Muitas vezes a tarefa de gerar frequência e grau de

gravidade é um processo tedioso. O sistema gera automaticamente estes cálculos
a partir dos dados capturados. Tais informações são críticas para determinar
quais áreas e períodos de operação são necessários de modo que sejam
gerenciados de forma mais efetiva.

Os sistemas pra esse fim normalmente são privados, ainda que em uso em instituições
publicas, por pertencerem sempre a instituições do estado, e por essas razões não se
adequam ao problema apresentado.

1.3 Metodologia utilizada

15
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. Pressmam(2005).

Uma metodologia define estados, etapas e fases de desenvolvimento. Também define

tarefas, actividades. As metodologias podem ser pesadas ou ágeis.

Metodologias Pesadas

As metodologias pesadas têm uma maior ênfase na planificação e controlo do projecto,

assim como a especificação precisa de requisitos. Se centram especialmente no controlo
do processo mediante uma rigorosa definição de roles, actividades, artefactos,
ferramentas e notações. Tipos de metodologias pesadas: RUP (Rational Unifield
Procces), Iconix, MSF (Microsoft Solution Framework).

• RUP

O Processo Unificado da Rational conhecido como RUP (Rational Unified Process), é um

processo de engenharia de software criado para apoiar o desenvolvimento orientado a
objectos, fornecendo uma forma sistemática para se obter vantagens no uso da UML.
Foi criado pela Rational Software Corporation e adquirido em Fevereiro de 2003 pela
IBM.

O principal objectivo do RUP é atender as necessidades dos usuários garantindo uma

produção de software de alta qualidade que cumpra um cronograma e um orçamento
previsíveis. Assim, o RUP mostra como o sistema será construído na fase de
implementação, gerando o modelo do projecto e, opcionalmente, o modelo de análise
que é utilizado para garantir a robustez. O RUP define perfeitamente quem é
responsável pelo que, como as coisas deverão ser feitas e quando devem ser
realizadas, descrevendo todas as metas de desenvolvimento especificamente para que
sejam alcançadas.

Metodologias Ágeis

Métodos de desenvolvimento de software que aplicam o desenvolvimento iterativo,

empregam o planeamento adaptativo, promovem a entrega incremental, incluem outros
valores e práticas que encorajam a agilidade resposta rápida e flexível às mudanças.
Tipos de metodologias ágeis: XP (eXtreme Programming), OpenUp, SCRUM.

16
 • Extreme Programming - XP

O Extreming Programming (XP) tem muita semelhança com SCRUM em termos de

valores e modelo de desenvolvimento de projectos, ou seja, como desenvolver projectos
que possam abraçar as incertezas de forma mais seguras. No entanto, esses dois
métodos também são complementares, visto que SCRUM é mais como um framework
gerencial. O XP desenvolve menos esses aspectos e foca mais em práticas de
engenharia.

O XP é um método de desenvolvimento de software, leve, não é prescritivo, e procura

fundamentar as suas práticas por um conjunto de valores que serão vistos
posteriormente no artigo. O XP, diferentemente do que muito pensam, também pode ser
adoptar por desenvolvedores médios e não apenas por desenvolvedores experientes.

O objectivo principal do XP é levar ao extremo um conjunto de práticas que são ditas

como boas na engenharia de software. Entre elas podemos citar o teste, visto que
procurar defeitos é perda de tempo, nós temos que constantemente testar.

• OPENUP

O Processo Unificado Aberto, do inglês Open Unified Process (OpenUP). A IBM viu a
necessidade de criar uma versão mais ágil RUP, então a IBM forneceu para a
comunidade Eclipse o conteúdo da versão inicial desse novo processo. Surge assim a
metodologia Open UP, ou, Processo Unificado Aberto, uma metodologia ágil de
desenvolvimento de software. OpenUP preserva as características essenciais do RUP/
Unified Process.

A Open UP, é um Processo Unificado leve que aplica as abordagens iterativa e

incremental; aborda uma filosofia de desenvolvimento ágil; processo de desenvolvimento
de software que é mínimo, completo e extensível.

Observação

É importante enfatizar que cada fase é encerrada por um marco, ou seja, um conjunto de
actividades e artefactos gerados pela equipe de desenvolvimento que caracterizam o
encerramento da fase.

17
 Figura 1.2 - Ciclo de vida do OpenUP

Como metodologia de desenvolvimento de software se decidiu o uso do OpenUP por ser

uma metodologia adaptável as necessidades do produto a ser elaborado, o que permite
que não se adicione um trabalho excessivo por causa da quantidade de documentação
que e gerada com o uso das metodologias pesadas. As metodologias ágeis agregam
valor para equipe, para a organização e clientes, ela adopta práticas de desenvolvimento
iterativo e incremental. Também é uma metodologia desenvolvida para equipas
pequena.

1.4 Ferramentas usadas

Nesta secção serão apresentadas as tecnologias definidas para desenvolvimento do

projecto, sendo a Linguagem de programação para Internet, Banco de Dados e Sistemas
de recomendações Web. A linguagem de programação é Java, já o banco de dados
utilizado é Postgresql.

Linguagem Java

Java é uma linguagem de programação utilizada no desenvolvimento de software que

tem portabilidade entre as plataformas, através da máquina virtual ou JAVA VIRTUAL
MACHINE (JVM).

18
Além disso, ela é orientada a objectos, o que possibilita a reutilização de códigos
desenvolvidos em outros projectos e trabalha com a troca de mensagens entre os
objectos. (Bosanac, 2007)

Figura 1.3 - Java

Vantagens que apresenta:

• Carga Dinâmica de Código - Programas em Java são formada por uma colecção
de classes armazenadas independentemente e que podem ser carregadas no
momento de utilização.

• Sintaxe similar a Linguagem C.

• É distribuída com um vasto conjunto de bibliotecas (ou APIs).

• Fácil comunicação com banco de dados, pacote JDBC oferece diversas utilidades
relacionadas com criação e manipulação de bancos de dados de diversas
naturezas.

• Portabilidade, por ser uma linguagem interpretada, o Java pode ser executada em
qualquer plataforma ou equipamento que possua o interpretador.

PostgreSQL 9.4

O PostgreSQL é um poderoso sistema de banco de dados relacional de objecto de

código aberto que usa e estende a linguagem SQL combinada com muitos recursos que
armazenam e escalam com segurança as cargas de trabalho de dados mais
complicadas. As origens do PostgreSQL remontam a 1986 como parte do projecto
POSTGRES na Universidade da Califórnia em Berkeley e tem mais de 30 anos de
desenvolvimento activo na plataforma principal.

O PostgreSQL ganhou uma forte reputação por sua arquitectura comprovada,

confiabilidade, integridade de dados, conjunto robusto de recursos, extensibilidade e
dedicação da comunidade de código aberto por trás do software para fornecer
consistentemente soluções inovadoras e de alto desempenho. O PostgreSQL é
executado em todos os principais sistemas operacionais, é compatível com ACID desde

19
2001 e possui complementos poderosos, como o popular extensor de banco de dados
geoespacial PostGIS. Não é surpresa que o PostgreSQL tenha se tornado o banco de
dados relacional de código aberto preferido por muitas pessoas e organizações.

Nunca foi tão fácil começar a usar o PostgreSQL - escolha um projecto que você deseja
criar e deixe o PostgreSQL armazenar seus dados com segurança e robustez.
(CommunityPostgres)

Figura 1.4 - PostgreSQL

Pela riqueza de recursos e conformidade com os padrões, ele é um SGBD muito

adequado para o estudo universitário do modelo relacional, além de ser uma óptima
opção para empresas implementarem soluções de alta confiabilidade sem altos custos
de licenciamento. É um programa distribuído sob a licença BSD, o que torna o seu
código fonte disponível e o seu uso livre para aplicações (Company-PostgreSQL, 2014).

Este gerente oferece muitas vantagens em relação a outros sistemas de banco de

dados, tais como:

• Melhor suporte a fornecedores comerciais.

• Código fonte disponível para todos gratuitamente.

• PostgreSQL está disponível em múltiplas plataformas, como Linux e Windows

Netbeans IDE 8.2

NetBeans é um ambiente de desenvolvimento integrado, ou IDE, para o

desenvolvimento rápido e fácil de aplicações desktop, móveis e Web em um número de
diferentes línguas. Ela é multiplataforma e gratuita e tem código-fonte aberto, além de
uma grande comunidade de usuários e desenvolvedores em todo o mundo (NetBeans,
2016).

O NetBeans suporta o desenvolvimento em Java, PHP, HTML, JavaScript, CSS, Groovy

e C + +. Neste contexto, o desenvolvimento refere-se a apoiar a codificação, depuração
e compilação de código nessas línguas. Na fase de codificação, NetBeans verifica seu
código em tempo real para garantir a sintaxe apropriada. NetBeans inclui uma série de

20
ferramentas de depuração para ajudar a isolar e corrigir erros de sintaxe não
relacionados (NetBeans, 2016).

Figura 1.5 - NetBeans

Vantagens que apresenta:

• Programas grátis.

• Facilita a criação de um projecto de forma mais simples, quando comparado com

outros programas.

• As variáveis do programa podem ser vistas em tempo de execução.

• Os erros são bastante descritivos.

• Facilidade de uso com o Windows.

• Ambiente de desenvolvimento perfeito.

• Usabilidade.

Visual Paradigm 13

Visual paradigma UML é uma linguagem gráfica de modelagem para visualizar,

especificar, construir e documentar os artefactos de sistemas de objectos distribuídos.

Uma ferramenta CASE que usa a linguagem de modelação UML, padrão que permite a
geração de código e engenharia reversa. Esta ferramenta está em conformidade com as
políticas de migração para software livre, porque é uma ferramenta multiplataforma que
pode ser usado tanto em Linux como Windows. Ela promove um pacote de ajuda para o
desenvolvimento do software, desde o planejamento, através da análise e projecto de
geração de código para ambientes de desenvolvimento integrados, como NetBeans,
Eclipse, Oracle JDeveloper, e JBuilder. (Visual-paradigm corporation)

Figura 1.6 - Visual Paradigm

21
Vantagens que apresenta:

• Tem uma interface muito intuitiva e é fácil de aprender.

• Permite a geração automática de diagramas a partir da descrição de casos de

uso.

• Permite a descrição dos casos de uso que de uma variedade de modelos padrão
que permitem a personalização.

• Ele combina a funcionalidade de todos os problemas em uma plataforma de

modelagem visual de comprimento.

Ireport 7.0

O IReport é um aplicativo gráfico, que permite que desenhar relatórios, utilizando uma
palheta, e arrastando e soltando componentes, de forma bem parecida com a criação de
interfaces e janelas para programas. Ao salvar, automaticamente será gerado um
JRXML que você poderá utilizar na aplicação que estiver desenvolvendo. A vantagem é
que não é necessário que você conheça a fundo o XML a ser editado, economizando
tempo de desenvolvimento. Ele também traz um conjunto pronto de templates que você
já pode utilizar directamente, ou então, escrever seus próprios templates e reaproveitá-
los sempre que precisar criar um novo tipo de relatório.

Figura 1.7 - Ireport

Razão de sua Escolha: Escolheu-se o IReport porque é muito simples de usar e que de
certa forma permite poupar tempo na aprendizagem da ferramenta, outro motivo pelo
qual escolheu-se o IReport é que é grátis e totalmente compatível com a linguem Java.

Conclusão Parcial

Neste capítulo começou-se a apresentar-se os principais conceitos para o projecto, ou

seja, os diferentes objectos do projecto, Fez-se um estudo e comparação entre os
sistemas similares a nível nacional e internacional e a partir deles obteve-se ideias de
como uma o sistema deve funcionar, foram apresentadas as ferramentas métodos e
linguagens de programação.

22
Conclui-se em usar a ferramenta como Postgresql, a linguagem de programação
escolhida foi o java e a metodologia OpenUpp.

23
 2 CAPÍTULO 2: CARACTERÍSTICAS DO SISTEMA.

Este capítulo é responsável por explicar e informar sobre os artefactos usados para que
o sistema fosse concebido, este capítulo descreve os requisitos funcionais e não
funcionais do sistema. Nela também se explicar o fluxo dos processos através dos
diagramas e modelos, ilustrando assim a estrutura interna do sistema.

2.1 MODELAGEM DO NEGÓCIO

Antes de se levar acabo o desenvolvimento de um sistema informático antes porém,

precisa-se conhecer e 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 (Rodrigues, et al., 2015).

Segundo (Silva, et al., 2001) a Modelagem “ é a arte e ciência de criar modelos de uma
determinada realidade” . Desta forma pede-se se entender a modelagem de negócio
como 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, et al., 2015).

É a forma pela qual uma empresa cria valor para todos os seus principais públicos de
interesse. Sua utilização ajuda a ver de forma estruturada e unificada os diversos
elementos que compõe todas as formas de negócios.

O resultado da modelagem de negócio são os modelos de negócio, esses modelos

reflectem a representação de um conjunto de actividades, processos, quem os realiza e
os serviços que a organização oferece a seus clientes.

O modelo de negócios é essencial para alcançar uma maior compreensão da situação

em questão. Descreve de forma clara e concisa o que a empresa oferece aos seus. A
fase de modelagem de negócios é a primeira e mais importante do ciclo de vida para o
desenvolvimento de software. É justamente a fase em que os processos de negócios,
identificação de quem participa e actividades que exigem automação são descritos.

Modelo conceptual ou domínio. Descrição do negócio

Modelo Conceitual é um conjunto de suposições baseadas no mundo real que indicarão

as regras de negócio de um sistema. Esta etapa independe da escolha de tecnologias e
protótipos ajudam no entendimento dos processos. Portanto, modelo conceitual é a

24
descrição do sistema proposto na forma de um conjunto de ideias e conceitos integrados
Rebelo(2012).

Diagrama de classes do modelo de domínio ou modelo conceptual

Figura 2.1 - Modelo de Dominio

Descrição do negócio

A DNVT de Luanda registra um conjunto de acidentes com o objectivo de ter um controle

dos mesmos. Estes acidentes envolvem um ou mais veículos, sendo esses manejados
ou conduzidos por pessoas, sendo que estes acidentes acontecem em uma determinada
localização.

Diagrama de Casos de Uso do Negócio

Casos de uso são narrativos em texto, descrevendo a unidade funcional, e são

amplamente utilizados para descobrir e registar requisitos de sistemas. Os diagramas de
Casos de Uso são representações dos Casos de Uso e podem ser representados por
uma elipse contendo, internamente, o nome do caso de uso Debastiani (2015).

Figura 2.2 - Diagrama de Caso de Uso do Negócio

Descrições dos Casos de Uso do negócio

Tabela 2.1 - Descrição do Caso de Uso de Negócio – Solicitar Registro de Acidente

25
 Caso de Uso Solicitar Registro de Acidente
Actor Agente Regulador de Transito
Trabalhadores Secretária
O caso de uso começa quando o Agente Regulador de Transito chega a secretaria e
Resumo: solicita o Registro de Acidente, este apresenta os requisitos necessários a secretária e
esta efectua o registro do acidente.
Precondições: Apresentar as informações necessárias
Fluxo Normal de Eventos
Acção do Actor Resposta do Negócio
1. Solicita Registro de Acidente. 2. Atende e solicita as informações ao Agente Regulador
de Transito
3. 3. Entrega documentos necessários 4. Recebe documentos necessários e verifica-os.
4.1. Realiza o registro do acidente.

2.2 MODELAGEM DO SISTEMA

A modelagem do sistema foi feita com base na UML (Unified Modeling Language) que é
uma linguagem-padrão para a elaboração da estrutura de projectos de software. Ela
poderá ser empregada para a visualização, a especificação, a construção e a
documentação de artefactos que façam o uso de sistemas complexos de software” .
Booch, Rumbaugh e Jacobson (2000).

Especificação de Requerimentos do Sistema

Um requisito funcional define uma função do sistema de software ou seus componentes.

A função é descrita como um conjunto de entradas, saídas e comportamentos, eles
incluem: cálculos, detalhes técnicos, manipulação de dados e outras funcionalidades
específicas que, um sistema deve atender. Os requisitos de desempenho para cada
requisito funcional são mostrados em casos de uso. Eles são complementados por
requisitos não-funcionais, que se concentram em vez sobre a concepção ou
implementação. (Pressmam, 2005).

Requerimentos funcionais

Tabela 2.2 - Requisitos Funcionais

Categoria Descrição

RF01-Cadastrar Usuário

Usuário RF02-Alterar Usuário

RF03-Eliminar Usuário

26
 RF04-Visualizar Usuário

RF05-Autenticar Usuário

RF06- Cadastrar Agente Regulador

RF07-Alterar Agente Regulador

Agente Regulador
RF08-Visualizar Agente Regulador

RF09-Eliminar Agente Regulador

RF10-Cadastrar Acidente

RF11-Alterar Acidente
Acidente
RF12-Eliminar Acidente

RF13-Visualizar Acidente

RF14-Cadastrar Níveis

RF15-Alterar Níveis
Níveis
RF16-Eliminar Níveis

RF17-Visualizar Níveis

RF18-Cadastrar Causas

RF19-Alterar Causas
Causas
RF 20-Eliminar Causas

RF 21-Visualizar Causas

Relatórios RF 22-Gerar Relatórios

Requerimentos Não Funcionais

Um requisito não funcional ou qualidade atributo é, na engenharia de sistemas e

engenharia de software, a exigência de que especifica os critérios que podem ser
usados para julgar o funcionamento de um sistema, em vez de seus comportamentos
específicos, uma vez que correspondem às exigências funcional. Por isso, referem-se a
todas as exigências para manter as informações, não descrevem as funções a serem
executadas.

27
São as restrições nas funções oferecidas pelo sistema. Incluem restrições de tempo,
restrições no processo de desenvolvimento, padrões e qualidades globais de um
software, usabilidade, desempenho, custos. (Carvalho, 2002).

Tabela 2.3 - Requisitos não Funcionais

Categoria Descrição

RNF1. O sistema deve ser intuitivo e fácil de usar a qualquer usuário pode
Usabilidade usá-lo sem ter conhecimentos elevados de informática.
RNF2. Acessível apenas em modo desktop.

RNF3. Desenvolvido em Java.

Software
RNF4. O Gerenciador de base de dados é usar Postgresql na versão 9.1

RNF5. O sistema deve validar a colecta de dados para evitar entradas

Confiabilidade
inapropriadas.

RNF6. Integridade e confidencialidade das informações é assegurada

através de mecanismos de controlo de acesso uso não autorizado: os
níveis de usuário, senha e definição de acesso para cada usuário, de modo
Segurança que cada usuário pode ter disponível somente a actividade relacionada e
tem opções de dados próprio acesso.
RNF7. O sistema deve garantir que a exclusão de informações pode ser
uma opção de aviso antes de executar a ação.

RNF8. A boa organização das informações é garantida para permitir a

Aparência ou interface interpretação correta.
externa RNF9. O sistema deve manter uma boa interface para permitir o fácil
manejamento pelos usuários.
RNF10. Os requisitos mínimos para o funcionamento deste sistema estão
vistas em computadores com as seguintes capacidades:4 GB de RAM, 300
GB de disco rígido.
Hardware
RNF11. O servidor de banco de dados deve ter como um Core 2Duo
tecnologia mínimo microprocessador com 4 GB de RAM e disco rígido de
300 GB.

Apoio RNF12. O sistema deve ser instalado e testado em que o cliente precisa.

Diagrama de Casos de Uso do Sistema

Diagrama de caso de uso do sistema é uma técnica de representação gráfica usada para
descrever os requisitos funcionais do sistema. Estão representados em termos de
actores externos ao sistema e casos de usos. Os actores 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 e o caso de uso do sistema representa
uma sequência de acções realizadas pelo sistema e recebe do actor que o utiliza dados

28
tangíveis de um tipo e formato já conhecido e o valor da resposta da execução de um
caso de uso é também um tipo já conhecido. É por meio do caso de uso que os actores
iniciam a comunicação com o sistema (Burgués, 2016).

Os casos de uso são narrativos em texto, descrevendo a unidade funcional, e são

amplamente utilizados para descobrir e registar requisitos de sistemas. Os diagramas de
Casos de Uso são representações dos Casos de Uso e podem ser representados por
uma elipse contendo, internamente, o nome do caso de uso. (Debastiani, 2015)

Na Engenharia de Software, um caso de uso é um tipo de classificador representando

uma unidade funcional coerente provida pelo sistema, subsistema, ou classe
manifestada por sequências de mensagens intercambiáveis entre os sistemas e um ou
mais atores.

Figura 2.3 - Diagrama de caso de uso do sistema

Descrição dos atores do sistema

Tabela 2.4 - Actores do Sistema

Actor do sistema Descrição

Actor responsável pela administração das operações do sistema como:
Secretária
gerenciar acidente, agentes reguladores de trânsitos, usuários e relatórios.

Descrição dos Casos de Uso do Sistema

Tabela 2.5 - Casos de uso do sistema - Cadastrar usuário

29
Caso de Uso Cadastrar Usuário

Atores Secretária

Resumo O caso de uso começa quando secretária pretende cadastrar um novo usuário no
sistema, então a secretaria acesso sistema e em configurações selecciona em Usuário
e escolhe a função que permite adicionar novo usuário e preenche os campos e salva
o novo usuário.

Pré condições Os campos devem estar Preenchidos

Pós condições O novo usuário deve estar cadastrado no sistema

Referências RF01

Prioridade Media

Fluxo normal de eventos

Acção do actor Resposta do sistema

No menu principal clica em Mostra a página de configurações com suas funcionalidades.

configurações” .

Na página das configurações clica em Mostra lista de usuários já cadastrados.

usuário.

Na página de buscas das disciplinas Apresenta o formulário de cadastro de usuário.

clica em “ adicionar novo usuário” .

Preenche os campos com os dados do Recolhe e guarda os dados do usuário e redirecciona

usuário e clica em “ Salvar” . usuário a lista de usuários já cadastrados.

Fluxo alterno de eventos

Campo vazio

Acção do actor Resposta do sistema

Emite uma mensagem “ Preencha os campos por favor!”

Clica em ok. Repete o passo 6 a 8 do fluxo principal.

Protótipo de interface

30
 Tabela 2.6 - Casos de uso do sistema - Cadastrar agente regulador de trânsito

Caso de Uso Cadastrar Agente Regulador de Transito

Atores Secretária
Resumo O caso de uso começa quando secretária pretende cadastrar um novo
Agente Regulador de Transito, então a secretaria acesso o sistema clica
na área para o cadastro de novos agentes, preenche os campos e salva o
novo agente regulador de trânsito.
Pré condições Preencher os campos.
Pós condições Novo Agente Regulador de Trânsito deve estar cadastrado no sistema
Referências RF-06
Prioridade Alta
Fluxo normal de eventos
Acção do actor Resposta do sistema
1. No menu principal clica 2. Mostra a página de cadastro para novo agente com o seu
em “ Novo Agente” . formulário.
3. Preenche os campos do 4. Recolhe e guarda os dados do agente e emite
formulário de cadastro e mensagem “ Agente Regulador de Trânsito Salvo.”
clica em “ Salvar” .
Fluxo alterno de eventos
Campo vazio
Acção do actor Resposta do sistema
1. Emite uma mensagem “ Preencha os campos por
favor!”
2. Clica em ok. 3. Repete o passo 3 a 4 do fluxo principal.
Protótipo de interface

31
 Tabela 2.7 - Descrição do Caso de Uso do Sistema Autenticar Utilizador.

Caso de Uso: Autenticar Utilizador

Actor Utilizador
Propósito Verificar se o utilizador tem permissão para aceder o sistema
Resumo Validar se o utilizador tem permissão para aceder as informações do sistema.
Pré condições Utilizador autenticado no sistema
Pós condições Apresentar Dashboard
Fluxo Normal dos Eventos
Acção do Actor Resposta do Sistema
1. O utilizador introduz o seu nome e a palavra 2. O sistema verifica se os dados inseridos pelo utilizador
passe. coincidem com os dados que registado no sistema.
3. O sistema deve atribuir privilégios segundo o tipo de
utilizador e visualizar a janela principal da aplicação,
finalizando assim o caso de uso.
Fluxo Alternativo
2.1 Se o nome de utilizador existe, mas a senha não
coincidir com a senha registrada ou a senha coincidir com
a registada, então o sistema apresentará ao utilizador a
seguinte mensagem: “ O nome de utilizador e a senha não
coincidem.”, ir para a acção 1 do Fluxo Normal de

32
 Eventos.
Prioridade: Alta

Conclusões Parciais.

Com desenvolvimento deste capítulo obteve-se as seguintes conclusões parciais:

• Com a modelagem do negócio que permitiu se obter um melhor entendimento dos

processos realizados pela DNVT e identificar os actores do negócio, caso de uso
do negócio e descrever os casos de uso de negócio, com isso permitiu determinar
abrangência do problema de modos a se buscar uma solução de acordo com a
situação apresentada;

• Com a modelagem e especificação dos requerimentos do sistema que permitiu

definir as funcionalidades do sistema e determinar as características e o
comportamento do sistema.

33
 3 CAPÍTULO 3: DESENHO E IMPLEMENTAÇÃO DO
SISTEMA.

Neste capítulo são abordados assuntos relacionados com o desenho, desenvolvimento e

provas do sistema informático desta feita se realizou a modelação detalhada com
aplicação de padrões de desenho e a construção da estrutura do sistema informático
obtendo como artefacto diagrama de classes, arquitectura do sistema, modelo físico do
banco de dados, diagrama de implantação, e finalmente documentam-se as provas
realizada sobre o sistema informático, feita para verificar se o sistema corresponde ao
que foi especificado e detectar falhas no sistema informático.

3.1 Diagrama de Classes.

Diagramas que são usados para descrever a estrutura estática de um sistema,

modelando em particular as entidades existentes, as suas estruturas internas (atributos e
operações), e as relações entre si (Videira, 2001). De seguida é apresentado diagrama
de classe modelado para o sistema informático.

Figura 3.1 - Diagram de classe.

3.2 Análise e desenho do Banco de Dados.

34
Modelo físico de banco de dados é uma descrição de um banco de dados no nível de
abstracção visto pelo usuário do Sistema de Gestão do Banco de Dados (SGBD). Neste
modelo são detalhados os componentes da estrutura física do banco de dados, como
tabelas, campos, tipos de valores, tamanho, índices, etc. Assim, esse modelo depende
do SGBD que está sendo usado. É Modelo está pronto para criar o banco de dados
propriamente dito, usando o SGBD seleccionado. Com isso a seguir tem-se o modelo
físico de banco de dados para o sistema informático.

35
 Figura 3.2 : Desenho do Banco de Dados.

Descrição das Entidades

Tabela 3.1 - Descrição das entidades do modelo fisico de banco de dados

36
 Entidades Descrição

Pessoa Esta, armazena as informações de uma pessoa.

Agente Esta, armazena as informações dos agentes reguladores de trânsitos.

Acidente Esta, armazena as informações referentes aos acidentes.

Esta, armazena as informações dos veículos envolvidos em um

Veiculo
acidente.

Consequência Esta, armazena as consequências trazidas por um acidente.

Causa Esta, armazena os factores que causaram um acidente.

Niveis Esta, armazena os níveis dos agentes

Agente_has_Acidente Esta, armazena os dados da combinação da agente e acidente

Acidente_has_ Causa Esta, armazena os dados da combinação da causa e acidente

3.3 Modelo de Implantação.

Diagrama de implantação

Os diagramas de instalação ou também de implantação mostram a disposição e

descrevem a configuração de elementos de suporte de processamento, e de
componentes de software, processos e objectos existentes nesses elementos (Videira,
2001).

Figura 3.3 : Diagrama de implantação do sistema

Descrição do modelo de implantação do sistema

Tabela 3.2 - Nós do modelo de implementação do sistema

37
 Nós/Dispositivos
Computador Admin / Secretário(a)
Impressora
Servidor PostgreSQL
Descrição
Dispositivo com suporte de acesso ao sistema.
Dispositivo usado para impressão de relatório e outros
documentos ou arquivos.
Repositório de dados, armazena informações de
gestão.

Tabela 3.3 - Conectores do modelo de implementação do sistema

Conectores Descrição

FTP Protocolo de transferência de arquivos entre dispositivo; Opera nas portas 20 à

21.
USB Porta para conectar periféricos externo ao PC.

3.4 ARQUITECTURA DO SISTEMA E PADRÃO DE DESENHO

UTILIZADO.

Em engenharia de software, um padrão é uma solução já provada e aplicável a um

problema que se apresenta uma e outra vez no desenvolvimento de distintas aplicações
e em distintos contextos. É importante destacar que, no general, um padrão não é uma
solução em forma de código directamente, se não uma descrição de como resolver o
problema e em que circunstancias é aplicável.

Arquitectura do Sistema

Arquitecta do Sistema é a descrição de como os componentes que compõem o sistema

estarão organizado e de como eles se relacionam (Sammerville, 2011).

Modelo Vista Controlador (MVC)

Para o desenvolvimento do Sistema decidiu-se utilizar o padrão de MVC. Este padrão

divide a aplicação em três componentes: o Modelo, a Vista e o Controlador. O Modelo se
encarrega de administrar o comportamento e os dados do domínio de aplicação,
responder as requisições de informação sobre seu estado e as instruções de mudança o
mesmo. A Vista maneja a visualização da informação, em quanto o Controlador analisa
as mensagens de eventos que recebe do sistema, modifica ou obtém dado do
componente Modelo em resposta as petições do usuário. Na figura seguir é apresentado
a arquitectura do sistema.

38
 Figura 3.4 - Arquitectura do sistema MVC

Padrão de Desenho Utilizado

Padrão de desenho é uma solução geral para um problema que ocorre com frequência
dentro de um determinado contexto no projecto de software. Uma solução bem provada
para um problema comum que captura a experiência e as boas práticas de forma que
possa ser reutilizada. É uma representação abstracta que pode ser instanciada de várias
maneiras (Sammerville, 2011). Entre os padrões que se utilizaram neste contexto
encontram-se os Padrões gerais de software para a atribuição de responsabilidades
(GRASP do inglês General Responsibility Asignment Software Patterns) e os Padrões
GoF (do inglês Gang Of Four).

GRASP

Os Padrões GRASP são formados por princípios fundamentais que servem de base para
a atribuição de responsabilidades a classes e objectos em um projecto orientado a
objectos (DEVMEDIA, 2018). Os utilizados no desenho do sistema são os seguintes:

Controlador (Controller): quando aplicado atribui a responsabilidade por lidar com

eventos do sistema a uma classe que não esteja relacionada a interface com o usuário
(http://ramonsilva.net). Aplicação deste padrão fica evidente nas classes
TurmaController, ProfessorController, só para citar alguns. Onde esta recebe e trata
eventos da camada de interface com o usuário, delegando as acções para as camadas
inferiores, de modo que funcione como intermediário.

Criador (Creator): este princípio determina qual classe deve ser responsável pela
criação certos objectos. (http://ramonsilva.net) Uso desse padrão pode ser observado
entre a classe Estudante e Matricula onde a classe Matrícula possui informação
necessária para inicialização ou criação de objecto Estudante.

39
Especialista (Information Expert): quando aplicado este princípio determina quando se
deve delegar a responsabilidade para um outro objecto que seja especialista naquele
domínio(http://ramonsilva.net). Este padrão se evidencia na classe MatriculaController,
como especialista no domínio de informação de quantos estudantes estão matriculados.

Alta Coesão, este principio determina que as classes devem se focar apenas na sua
responsabilidade. (http://ramonsilva.net)

Baixo Acoplamento, determina que as classes não devem depender de objectos

concretos e sim de abstracções, permitindo que haja mudanças sem
impacto(http://ramonsilva.net).

3.5 PRINCIPAIS INTERFACE DO SISTEMA

A seguir são apresentados algumas interfaces do sistema que permite que os usuários
realizem de maneira simples e amigável suas actividades.

Figura 3.5 - Tela de cadastro de utilizadores

40
 Figura 3.6 - tela de cadastro de níveis dos agentes

Figura 3.7 - Tela de cadastro de causas de acidentes

Figura 3.8 - Tela de cadastro de agentes regulador de trânsito

41
 Conclusões Parciais.

Uma vez realizadas as acções correspondente ao processo de desenho e

implementação do sistema e elaboração dos artefactos necessários para levar acabo de
forma satisfatória a execução do desenvolvimento do sistema pode-se levantar as
seguintes conclusões:

• Com a elaboração do diagrama de classes, modelo lógico e físico do banco de

dados, permitiu obter maior visão sobre como os dados estrarão trafegando sobre
a aplicação, bem como estes serão persistidos no banco de dados. O diagrama
de implantação descreveu de como os componentes/nós poderão vir a ser usados
a quanto a implementação do sistema.

• Com a aplicação de padrões de desenvolvimento, padrões de desenho, foi

possível obter maior organização na extrutura do projecto do código, facilitando
assim a análise e compreensão da solução proposta.

42
 4 CAPÍTULO 4: PROVAS DO SISTEMA.

Neste capítulo é feita a apresentação da aplicação de provas de software, isto é, prova

extrutural e prova funcional, que ajudarão na validação e verificação da consistência das
funcionalidades implementadas no sistema.

4.2 Descrição do processo de provas de funcionamento

Quando se constrói um sistema informático antes que este venham ser usado ou
entregue ao cliente, precisa ser testado de modos a verificar se cumprir com o propósito
pelo qual foi projectado e funciona correctamente.

Provas de funcionamento também chamado testes funcionais (Caixa preta) são métodos
e técnica dinâmicas, que envolve executar uma implementação de software com os
dados de teste e examinar suas saídas e comportamento operacional, a fim de verificar
se ele está funcionando conforme o esperado (Souza, 2008). Este método é
implementado por meio de técnicas de provas, um das quais é a técnica de partição
equivalente.

Técnica de Partição Equivalente trata-se de uma técnica de testes funcionais que propõe
a separação das possíveis entradas em categorias diferentes. Partições de equivalência
podem ser encontradas em dados válidos e inválidos (valores que deveriam ser
rejeitados, por exemplo). As partições podem ser identificadas para valores de saída,
valores relativos ao tempo (antes ou depois de um evento), bem como valores internos
ao processo (Costa, 2013).

Teste de caixa preta também conhecido como teste comportamental, focaliza os

requisitos funcionais do software. As técnicas de teste de caixa preta permitem derivar
séries de condições de entradas que utilizaram todos os requisitos funcionais para um
programa. O teste de caixa preta não é uma alternativa ao teste de caixa branca, em vez
disso é uma abordagem complementar, com possibilidade de descobrir uma classe de
erros diferente daquela obtida com o método de caixa branca. Pressman (2005).

Prova de Caixa Branca

Pressman,(1995) define a Prova de Caixa Branca como um método de projeto de casos

de testes voltado a testar a estrutura interna do software. A Prova de Caixa Branca, ao
contrário da Prova de Caixa Preta, se preocupa em como o código fonte foi construído e

43
a lógica de programação utilizada no desenvolvimento dos métodos. A prova é
totalmente realizada na estrutura interna do software.

A prova de caixa branca visa confirmar ou se certificar de que a estrutura interna do

software esteja correta. Para isso, é preciso que o caso de teste percorra todos os
caminhos internos possíveis.

FIGURA 9: CODIGO FONTE CADASTRAR CANDIDATO PROVA DE CAIXA BRANCA.

44
 Figura 10: Grafico fluxo Prova Caixa Branca

O número máximo de casos de prova é calculado pela formula V(G)=A-N+2, onde A é o

número de arestas e N o número de nós do grafo.

V(G)=4 - 4+2=2

Caminho: 1-2-3

Caso de prova: Cadastrar Candidato

Entrada: Quando o utilizador preenche devidamente o formulário.

Resultado: O sistema apresenta uma mensagem de notificação ('Candidato registrado

com Sucesso').

Caminho: 1-4-3

Caso de prova: Cadastrar Candidato

Entrada: Quando o utilizador não preenche devidamente o formulário.

Resultado: O sistema apresenta uma mensagem de notificação ('Erro ao Salvar,

verifique os dados introduzidos').

Provas de caixa preta. Técnica de Partição Equivalente

O sistema foi provado com método de provas de caixa preta usando técnica de partição
equivalente e com ajuda de cenários de provas que é um conjunto de entradas,
condições de execuções e resultados esperados desenvolvido para um objectivo

45
particular. De seguida será apresentado um cenário de prova realizado sobre o caso de
uso cadastrar agente regulador de trânsito. Os restantes das provas estão postas em
anexos.

Cenário de prova: Cadastrar Agente Regulador de Trânsito

No formulário de cadastro de agente regulador de trânsito apresenta-nos dois painés, o

primeiro para os dados pessoais apresenta onze (11) campos, que devem estar
preenchidos e no segundo apresenta-nos quatro (4) campos para o preenchimento. Uma
vez cumprido este requisito espera-se como resultado que o novo agente esteja
cadastrado no sistema informático. Caso não se cumprida este requisito o sistema
informará o preenchimento dos campos que se encontram vazio.

Tabela 4.1 - Cenário de prova de caixa preta

Classes de equivalências Classes de equivalências

Condições de Entrada
“Nome Completo” não pode estar
vazio
“Data de Nascimento” não pode estar
vazio
“ BI” não pode estar vazio
“ Telefone” não pode estar vazio ou
ter caracteres
“ Email” tem que cumprir com o
padrão
validas
Nome Completo = “ Nequetela
Manuel”
Data de Nascimento =
30/04/1992
Bilhete de Identidade =
018365478HU032
Telefone = 928189860
Email =
“ neqsebas@gmail.com”
não validas
Nome Completo = “ ”
Data de Nascimento = “ dia
dois”
Bilhete de Identidade =
“ 018LA478H03”
Telefone = “ nove dois oito”
Email =
“ neqsebasgmailcom”

46
Depois de ser aplicado o teste de caixa preta, verificou-se que o sistema tem capacidade
de dar uma resposta de acordo aos dados inseridos pelos usuários.

4.2 Resultados das Provas

Ao aplicar a prova de caixa preta, foram elaborados 75 casos de provas. Depois de uma
repetição execução se obtiveram 50 não conformidades. Na segunda repetição se
obtiveram 29 não conformidades, na terceira repetição se obtiveram 15 não
conformidades, na quarta repetição se obtiveram 7 não conformidades e na quinta
repetição houve 0 não conformidades. Uma vez corrigidos os erros detectados, se
executaram novamente todas provas e não se detectaram não conformidades.

47
 Figura 4.1 - Resultados das provas

Conclusões parcias.

Com desenvolvimento deste capítulo obteve-se as seguintes conclusões:

• Os artefactos obtidos segundo a metodologia de desenvolvimento de software

utilizada e os padrões de arquitectura e desenho descritos, permitiu a correcta
integração e codificação do sistema informático;

• A arquitectura do sistema realizado, permitiu uma melhor visualização da

organização e as dependências lógicas entre os componentes do sistema;

• O diagrama de implantação permitiu representar a composição de os elementos

físicos do sistema informático;

• As provas realizadas permitiram uma correcta detecção dos erros no

funcionamento do sistema informático e garantiu a qualidade do processo de
desenvolvimento do sistema.

48
Conclusões
Os objectivos preestabelecidos no presente trabalho permitiu dar solução o problema de
investigação que é apresentado, através da execução dos objectivos específicos e das
tarefas de investigação chegou-se as seguintes condições:

• A análise dos conceitos relativos ao processo, permitiu obter os fundamentos para

guiar o processo de desenvolvimento;

• O estudo dos sistemas, a nível internacional e nacional, consentiu a compreensão

dos principais elementos que os compõem, suas funções e o estado actual destes
sistemas. A não existência de um sistema que se enquadra nas reais
necessidades levantadas durante a investigação, motivou o autor na elaboração e
continuidade no desenvolvimento da presente investigação.

• Os artefactos e diagramas gerados na fase de definição das características do

sistema, permitiram entender e levantar as necessidades do cliente, isto é, as
funcionalidades necessárias para melhorar o processo.

• Com o desenho e a implementação das funcionalidades requeridas para o

sistema, foi possível dar resposta aos principais requisitos funcionais do sistema,
o que por conseguinte, oferece o cumprimento em resposta a necessidade.

49
 Recomendações
Com todos os objectivos definidos na etapa inicial cumpridos, tenho como
recomendações:

• Continuar com a investigação do sistema com o propósito de adicionar novas

funcionalidades.
• Implementar o sistema em dispositivos moveis como tablet, para a obtenção de
dados para o cadastro a partir do local de acidente.
• Desenvolver uma versão do produto virado para web..

50
 Referências bibliográficas.
[Online] [Citação: 28 de 01 de 2020.]
http://angonoticias.com/full_headlines_.php?id=11600 – estado das estradas de Angola.

[Online] [Citação: 28 de 01 de 2020.]

http://dn.sapo.pt/inicio/interior.aspx?content_id=597727 – sinistralidade no mundo.

[Online] [Citação: 28 de 01 de 2020.]

http://pt.wikipedia.org/wiki/%C3%8Dndice_de_Desenvolvimento_Humano.

[Online] [Citação: 28 de 01 de 2020.]

http://www.angonoticias.com/full_headlines.php?id=1132<b – estado técnico dos
veículos em Angola.

[Online] [Citação: 28 de 01 de 2020.]

http://www.revistacefac.com.br/revista81/artigo16.pdf - Opnião de Intrutores de trânsito
sobre o exame de audição na obtenção e renovação da carteira internacional de
habilitação.

[Online] [Citação: 28 de 01 de 2020.]

http://www.viaciclo.org.br/portal/documentos/doc_view/177-declaracao-conf-seg-viaria-
moscou-2009-oficial-e-ongs?tmpl=component&format=raw– Declaração de Moscov
sobre Sinistralidade Rodoviária.

[Online] [Citação: 28 de 01 de 2020.]

minhttp://www.portalangop.co.ao/motix/pt_pt/noticias/economia/2009/9/40/PIB-Angola-
cresce-nove-porcento-anos,ec0e7964-3af1-4955-891c-6680b12e2b82.html.

[Online] [Citação: 28 de 02 de 2020.]

http://www.angonoticias.com/full_headlines.php?id=10522<b – estado técnico dos
veículos em Angola.

2001. Ian Sommerville - Engenharia de Software. Sao Paulo : Roger Trimer, 2001.

Angop, 2018. [Online] [Citação: 25 de 01 de 2018.]

https://www.angop.ao/angola/pt_pt/noticias/sociedade/2018/0/4/SPCB-aposta-gestao-
informacoes-sobre-desastres,c9ecab25-5376-485e-aec2-084b0ff49a94.html, SPCB
aposta na gestão de informações sobre desastres.

Barreira, Ramiro. 2000. Angola 30 anos. 2.ª Edição, 2000.

51
Ferreira, J.O. Cardoso. 2004. Acidentes de Viação em Auto-estradas. s.l. : Editorial
Coimbra, 2004.

Geraldes, António. 2009. Acidentes de Viação. Coembra : Edições Almedina, 2009.

Ináculo, Andrewyang. 2006. A Segurança Rodoviária em Angola, Lisboa,Edição, ISCPSI.

2006.

Infopédia. 2015. Infopédia. Infopédia. [Online] 2015. [Citação: 15 de 01 de 2018.]

https://www.infopedia.pt/centro-de-contacto.

Macedo, António. 2006. Manual do Bom Condutor. s.l. : Edições Impala Editores, 2006.

Marcelino, Américo. 2009. Acidentes de Viação e Responsabilidade Civil. [ed.] 10.ª

Edição. Lisboa : Editora Livraria Petrony, 2009.

Miranda, Valmir. 2004. Segurança de Trânsito Rodoviária – Proposta para o Sector

Produtor Brasileiro. Universidade Federal do Rio de Janeiro : s.n., 2004.

Monteiro, Virgínia. 2009. O Código da Estrada. s.l. : Edições Segurança Rodoviária,

2009.

Morimoto, Carlos E. 2005. [Online] 26 de Junho de 2005. [Citação: 20 de Junho de

2017.] http://www.hardware.com.br/termos/hub.

Orgaõ de Informação e Cultura do CGPN. País, O. 2009. Luanda : Editor, DNVT, 2009,
Jornal O País. n.º 10.

Reto, Luís e Jorge, SÁ. 2003. Porque nos matamos na estrada e como evitar. 1.ª Edição.
Lisboa : Editorial Notícias, 2003.

Silva, Eduardo. 2008. Sinistralidade Rodoviária. Lisboa : Edição ISCPSI, 2008.

Silva, Rafael e Nunes, Telma. 2007. Infracções ao Código da Estrada. [ed.] 2.ª Edição.
Lisboa : Edição Quid Juris, 2007.

Simchi-Levi, David, Kaminsky, Philip e Simchi-Levi, Edith. 2010. Cadeia de Suprimentos

Projeto e Gestão- conceitos, estratégias e estudos de caso. Porto Alegre : Artmed, 2010.

Turcert, 2020. [Online] [Citação: 25 de 08 de 2018.]

https://www.turcert.com/pt/belgelendirme/sistem-belgelendirme/iso-39001-yol-ve-trafik-
guvenligi-yonetim-sistemi , ISO 39001 Sistemas de Gestão de segurança rodoviária
(RTS).

52
Ursportugal, 2020. [Online] [Citação: 25 de 08 de 2018.]
https://www.ursportugal.pt/certificacao/iso-39001-sistemas-de-gestao-de-seguranca-
rodoviaria-rts, ISO 39001 Sistemas de Gestão de segurança rodoviária (RTS).

53
 Anexos
Anexo A. Provas.

Figura A1 – Validação do registro de Agente

54