Tese Paulo PDF

UNIVERSIDADE EDUARDO MONDLANE
FACULDADE DE CIÊNCIAS
DEPARTAMENTO DE MATEMÁTICA E
INFORMÁTICA
Trabalho de Licenciatura
Curso: Licenciatura em Informática
TEMA:
Desenvolvimento de um Sistema para Planeamento de Rotas de
Veículos para Recolha de Resíduos Sólidos Domésticos no Distrito
Urbano de KaMpfumo
AUTOR: Paulo Jorge Braga Zacarias

UNIVERSIDADE EDUARDO MONDLANE
FACULDADE DE CIÊNCIAS
DEPARTAMENTO DE MATEMÁTICA E
INFORMÁTICA
Trabalho de Licenciatura
TEMA:
Desenvolvimento de um Sistema para Planeamento de Rotas de
Veículos para Recolha de Resíduos Sólidos Domésticos no Distrito
Urbano de KaMpfumo
AUTOR: Paulo Jorge Braga Zacarias

SUPERVISOR: Ermínio Jasse
Maputo, Janeiro de 2015
Sistema para Planeamento de Rotas de Veículos para Recolha de RSD
DEDICATÓRIA
“A vida é uma peça de teatro que não permite ensaios”. (Charles Chaplin)
Dedico o presente trabalho à minha família.
Paulo J. B. Zacarias Trabalho de Licenciatura I

AGRADECIMENTOS
A realização deste trabalho foi apenas possível graças à colaboração e apoio de um conjunto
alargado de pessoas. A todos estarei para sempre grato.
Agradeço ao Conselho Municipal da Cidade de Maputo (CMCM) e a ECOLIFE, pelo acolhimento

e disponibilização de recursos para a execução deste trabalho.
Agradeço aos meus colegas e amigos do curso, pela força e apoio durante toda a jornada académica.
Agradeço ao meu supervisor, dr. Ermínio Jasse, pelas críticas, ensinamentos e metodologia
adoptada na supervisão do trabalho. Um agradecimento especial ao dr. João Metambo, pela
motivação ao longo dos anos, à dra. Judite Mandlate pela exigência na investigação e no trabalho.
Agradeço aos meus pais: Francisco Xavier Zacarias e Maria Flora Braga, às minhas irmãs: Ládia
Carina Zacarias e Andreia Michela Braga Zacarias, pelo apoio moral e financeiro.
Um profundo agradecimento vai à todos funcionários e colegas do DMI, principalmente aos que
dedicaram parte do seu tempo para a leitura deste trabalho.
DECLARAÇÃO DE HONRA
Declaro por minha honra que este trabalho é fruto da minha investigação, e que o mesmo foi
realizado para ser submetido à Faculdade de Ciências apenas para a obtenção do grau de
Licenciatura em Informática na Universidade Eduardo Mondlane.
Maputo, Novembro de 2014
(Paulo Jorge Braga Zacarias)

RESUMO
Dentre as várias actividades de gestão das organizações, a logística tem demonstrado especial
importância. O impacto financeiro e estratégico que esta exerce, faz com que cada vez mais, as
organizações busquem soluções que permitam melhorias nos seus resultados. Os transportes
compõem grande parte do custo logístico, sendo assim, nos últimos tempos, os sistemas de
roteamento de veículos tem vindo a ganhar enorme destaque. Uma das diversas aplicações dos
sistemas de roteamento de veículos, é na actividade de recolha de resíduos sólidos. Esta, consiste
em visitar um conjunto de pontos de recolha de resíduos sólidos de modo a recolher os resíduos
sólidos, fazendo uso de veículos adequados para este fim. A tarefa de planear as rotas para a recolha
de resíduos sólidos pode tornar-se bastante árdua a medida que surgem novos pontos de recolha
distantes geograficamente, pois, é preciso considerar vários factores (rede de estradas, sentido das
vias, estado das vias, capacidade dos veículos, tráfego, demanda dos pontos de recolha, etc.) de
modo a obter a melhor rota, ou seja, aquela que minimiza os custos de transporte. A presente
pesquisa, propõe o desenvolvimento de um Sistema Informático para o planeamento de rotas de
veículos na recolha de Resíduos Sólidos Domésticos (RSD), tendo como área de estudo o Distrito
Urbano de KaMpfumo (localizado na cidade de Maputo). Para a materialização do estudo, foi
necessário fazer o levantamento de dados no Conselho Municipal da Cidade de Maputo (CMCM)
mais especificamente no Departamento de Gestão de Resíduos Sólidos e na empresa ECOLIFE
(empresa actualmente responsável pela recolha e transporte de RSD no Distrito Urbano de
KaMpfumo), e para tal, foram feitas entrevistas a alguns funcionários, de forma a melhor entender o
funcionamento e os constrangimentos da actividade de recolha e transporte dos RSD; ainda para a
recolha de dados, foi utilizada a observação, que consistiu em percorrer uma das rotas de recolha
com a equipa de recolha, e em sequência, com recurso a técnicas de engenharia de software,
metodologias e ferramentas de desenvolvimento de software foi concebido e desenvolvido um
modelo de um Sistema Informático que permite o planeamento de rotas de veículos para a recolha
de RSD.
Palavras-chave: Roteamento de Veículos, Resíduos Sólidos, Logística.

ÍNDICE
DEDICATÓRIA I
AGRADECIMENTOS II
DECLARAÇÃO DE HONRA III
RESUMO IV
ÍNDICE DE FIGURAS VIII
ÍNDICE DE TABELAS IX
LISTA DE ABREVIATURAS E ACRÓNIMOS X
GLOSSÁRIO DE TERMOS XI
CAPÍTULO 1: INTRODUÇÃO 1
1.1 Definição do Problema 3

1.2 Objectivos 5
1.2.1 Objectivo Geral 5
1.2.2 Objectivos Específicos 5
1.3 Estrutura do Relatório 5
CAPÍTULO 2: METODOLOGIA 6
2.1 Metodologia de Pesquisa 6

2.1.1 Abordagem 6
2.1.2 Técnicas de colheita de dados 6
2.2 Desenvolvimento do Protótipo 9
2.2.1 Abordagem 9
2.2.2 Fonte de dados espaciais 10
2.2.3 Ferramentas 10
CAPÍTULO 3: REVISÃO DA LITERATURA 15
3.1 Roteamento de Veículos 15

3.1.1 Extensões do PRV 17
3.1.2 Classificação 17
3.1.3 Aplicações 18
3.1.4 Complexidade computacional e formas de resolução 19
3.1.5 Alguns algoritmos para planeamento de rotas 21
3.1.6 Planeamento de rotas na recolha de lixo 21
3.2 Sistemas de Informação Geográfico nos Transportes 22
3.2.1 Áreas de aplicação 24
3.2.2 SIG e o PRV 24
CAPÍTULO 4: ÁREA DE ESTUDO E MODELO PROPOSTO 27
4.1 Distrito Municipal de KaMpfumo 27

4.1.1 Sistema actual de recolha e transporte de RSD no Distrito Urbano de KaMpfumo 30
4.2 Procedimento pgr_cvrpOneDepot 32
4.2.1 Tabelas necessárias 32
4.2.2 Definição de janelas de tempo 33
4.2.3 Cálculo da matriz de distâncias 34
4.2.4 Funcionamento 34
4.2.5 Interpretação de resultados 35
4.3 Requisitos de Negócio 36
4.4 Concepção do Modelo 37
4.4.1 Domain model 37
4.4.2 Protótipo da interface do utilizador 37
4.4.3 Storyboard 41
4.4.4 User stories 42
4.4.5 Diagrama de casos de uso 44
4.5 Implementação do Modelo 46
4.5.1 Diagrama de Arquitectura de Forma Livre 46
4.5.2 CRC Cards 48
4.5.3 Diagrama de classes 50
4.6 Avaliação da Aplicabilidade do Modelo Proposto 50
CAPÍTULO 5: CONCLUSÕES E RECOMENDAÇÕES 52
5.1 Conclusões 52
5.2 Recomendações 56
BIBLIOGRAFIA 59
APÊNDICES 62
ÍNDICE DE FIGURAS
Figura 2.1: Artefactos a produzir nos níveis final e intermédio segundo a XP/AMDD....................10
Figura 3.1: Decisões estratégicas, tácticas e operacionais para o PRV..............................................16
Figura 3.1: Cenário inicial de um PRV..............................................................................................17
Figura 3.2: Solução de um PRV.........................................................................................................17
Figura 3.4: Crescimento da função f (n) com o aumento da entrada n..............................................20
Figura 3.5: Estratégias para solução do PRV.....................................................................................20
Figura 5.1: Localização da Cidade de Maputo...................................................................................28
Figura 5.2: Distrito Urbano de KaMpfumo........................................................................................28
Figura 5.3: Exemplo de Contentor de 1,1m3 (1100 litros)................................................................31
Figura 5.4: Contentor de 6m3.............................................................................................................31
Figura 5.5: Exemplo de Camião Compactador..................................................................................31
Figura 5.6: Exemplo de Camião Tipo Caixa Aberta..........................................................................31
Figura 5.1: Processo de Roteamento..................................................................................................35
Figura 6.2: Domain Model da Aplicação...........................................................................................37
Figura 6.3: Interface de Autenticação................................................................................................38
Figura 6.4: Interface de Registo de Novo Ponto de Recolha.............................................................39
Figura 6.5: Interface para Alocação dos Recursos para a Rota.........................................................40
Figura 6.6: Interface de Visualização das Rotas................................................................................41
Figura 6.7: Storyboard da Aplicação.................................................................................................42
Figura 6.8: Diagrama de Casos de Uso..............................................................................................44
Figura 4.15: Arquitectura de Alto Nível da Aplicação......................................................................47
Figura 6.10: Diagrama de Classes......................................................................................................50
ÍNDICE DE TABELAS
Tabela 3.1: Classificação de PRV......................................................................................................18

Tabela 3.2: Áreas de aplicação do SIG..............................................................................................24
Tabela 5.1: Divisão Administrativa da Cidade de Maputo................................................................27
Tabela 5.2: Tipos de RSU..................................................................................................................29
Tabela 5.3: Resumo das quantidades de RSU produzidas diariamente na cidade de Maputo...........30
Tabela 5.1: Parâmetros da tabela Veículos........................................................................................32
Tabela 5.2: Parâmetros da tabela Pontos............................................................................................33
Tabela 5.3: Parâmetros da tabela Distância.......................................................................................33
Tabela 5.4: Resultado do procedimento pgr_cvrpOneDepot.............................................................35
Tabela 5.5: Resultados do procedimento pgr_cvrpOneDepot...........................................................36
Tabela 6.1: User Stories, Prioridades e Estimativas..........................................................................43
Tabela 6.2: Caso de Uso Criar Rota...................................................................................................44
Tabela 6.3: Caso de Uso Alocar Recursos.........................................................................................45
Tabela 6.4: Caso de Uso Gerar Rota..................................................................................................45
Tabela 6.5: Caso de Uso Visualizar Rota...........................................................................................46
Tabela 6.6: Exemplo de um CRC card..............................................................................................48
Tabela 6.7: CRC card da Classe Alocação........................................................................................48
Tabela 6.8: CRC card da Classe Plano..............................................................................................49
LISTA DE ABREVIATURAS E ACRÓNIMOS
AJAX Asynchronous JavaScript and XML

Agile Model Driven Development ou Desenvolvimento Ágil
AMDD
Orientado ao Modelo
API Application Programming Interface
CMCM Conselho Municipal da Cidade de Maputo
CRC Classe, Responsabilidade e Colaboração
Direcção de Serviço Municipal de Gestão de Resíduos Sólidos
DMGRSUS
Urbanos e Salubridade
DTL Django Template Language
GPS Global Positioning System ou Sistema de Posicionamento Global
HyperText Transfer Protocol ou Protocolo de Transferência de
HTTP
Hipertexto
MTV Model-Template-View
MVC Model-View-Controller ou Modelo-Controlo-Visão
MySQL My Structured Query Language
NP-Hard Non-deterministic Polynomial-time Hard
Object-relational Database Managment System ou Sistema de
ORDBMS
Gestão de Base de Dados Objecto-relacional
ORM Object-relational Mapping ou Mapeamento objecto-relacional
OSM OpenStreetMap
OSRM Open Source Routing Machine
PRV Problema de Roteamento de Veículos
RSD Resíduos Sólidos Domésticos
RSU Resíduos Sólidos Urbanos
SaaS Software as a Service ou Software como Serviço
SGBD Sistema de Gestão de Base de Dados
Sistema de Informação Geográfica ou Sistemas de Informação
SIG
Geográfica
SQL Structured Query Language
UI User Interface ou Interface do Utilizador
Unified Modeling Language ou Linguagem de Modelação
UML
Unificada
Extensible Markup Language ou Linguagem de Marcação
XML
Extensível
GLOSSÁRIO DE TERMOS
Base de Dados: colecção de dados relacionados. Tais dados, referem-se a factos conhecidos, que
possam ser armazenados e que possuam significado implícito (Elmasri e Navathe, 2011).
Framework: em desenvolvimento de software, é uma abstracção na qual um software que fornece

funcionalidades genéricas pode ser alterado adicionando códigos escritos por desenvolvedores
tornando-o assim num software específico.
Hardware: parte física do computador.
JavaScript: linguagem de programação interpretada que corre do lado do cliente (browser ou web
browser).
Navegador Web: também conhecido pelos termos em inglês web browser ou simplesmente
browser, é um software que permite aos seus utilizadores interagirem com páginas web.
Open Source: refere-se ao software cujo código fonte está disponível para qualquer pessoa,
podendo altera-lo e partilha-lo.
Sistema de Gestão de Base de Dados: é uma colecção de programas que possibilita aos
utilizadores criar e manter bases de dados (Elmasri e Navathe, 2011).
Software: parte lógica do computador (análoga ao hardware) que compreende o conjunto de

programas e instruções executados por um computador.
Stakeholder: qualquer pessoa ou organização que tenha participação num projecto, por exemplo:
gestores de projecto, utilizadores finais, engenheiros de software, organizações, etc.
Web: serviço da Internet que contém documentos em formato de hipermédia, uma combinação de
hipertexto com multimédia.
CAPÍTULO 1: INTRODUÇÃO
Neste capítulo, faz-se o enquadramento do tema em causa, apresentando o problema que motivou a
pesquisa, os objectivos da pesquisa e a estrutura do presente relatório.
Planear é antecipar a forma em que determinados eventos irão ocorrer no futuro. Através do
planeamento, as organizações podem prever possíveis imprevistos e estarem preparadas para agir de
forma a reduzir ou evitar possíveis constrangimentos na execução das suas actividades.
Dentre as diversas áreas de gestão das organizações, a logística, definida por Daskin (1985), como
sendo “o planeamento e a operação de sistemas físicos, administrativos e informativos necessários
para permitir com que produtos superem restrições físicas e de tempo”, vem crescendo em destaque,
tanto no meio acadêmico quanto no empresarial devido a sua importância estratégica e do impacto
financeiro positivo trazido pela melhoria dos processos [CITATION Bit12 \l 1033 ].
Um dos objectivos da logística é fazer o produto certo, chegar no lugar certo, na hora certa,
paralelamente optimizando uma dada medida de desempenho (por exemplo: minimizando os custos
totais operacionais) e satisfazendo um certo conjunto de restrições (por exemplo: restrições de
tempo e capacidade).
Como afirma Christopher (2007), a gestão eficaz da logística pode trazer vantagem competitiva,
sendo a fonte desta vantagem, em primeiro lugar, a capacidade da organização de se diferenciar, aos
olhos do cliente, de seus concorrentes, e, em segundo lugar, em operar a um custo menor e portanto
com maior lucro.
Na logística, diversos tipos de problemas podem surgir. Um dos problemas mais notáveis é o
problema de planeamento de rotas, sendo um dos mais estudados, o Problema de Roteamento de
Veículos (PRV). Proposto por Dantzig e Ramster (1959), o PRV é um problema de análise
combinatória complexo que consiste no atendimento de um conjunto de clientes por intermédio de
uma frota de veículos, ao menor custo possível, respeitando todas as restrições do problema.
A elaboração manual de rotas de veículos pode tornar-se árdua a medida que a complexidade
aumenta, isto é, aumento da demanda, restrições de recursos (capacidade de veículos, recursos
humanos), restrições de tempo (período de atendimento), etc. Essa dificuldade deve-se ao facto de
haver um grande número de combinações, e, consequentemente, várias soluções, o que inviabiliza
uma resolução por enumeração explícita de todas as soluções possíveis. Segundo Lenstra e Rinnooy
Kan (1981), em termos de complexidade computacional, o PRV como a maioria dos problemas de
análise combinatória, são classificados como NP-Árduos, portanto, é extremamente difícil encontrar
soluções dessa natureza por serem complexos e repletos de restrições, mais difícil ainda é
determinar a solução que corresponde às restrições existentes.
Os métodos exactos, isto é, que produzem a melhor solução de todas possíveis, limitam-se a
resolver problemas de pequena dimensão. Sendo assim, para problemas de maior dimensão,
utilizam-se métodos heurísticos que fornecem soluções aproximadas, no entanto, num tempo
computacional aceitável.
Nos últimos tempos, o problema de planeamento de rotas tem recebido considerável atenção pela
comunidade científica, especialmente na área da computação. Diversas abordagens eficientes para a
resolução deste problema surgiram da teoria dos grafos e algoritmos mas devido a sua importância e
impacto económico, este problema tem sido objecto de estudo de várias disciplinas como
investigação operacional e inteligência artificial.
Tal importância deve-se em parte a aplicabilidade prática do PRV, que pode ser aplicado em várias
áreas relacionadas ao transporte, como por exemplo, na actividade de recolha e transporte de
resíduos sólidos, na distribuição de produtos, transportes públicos e privados, etc. E hoje em dia,
com o desenvolvimento da tecnologia e dos Sistemas de Informação Geográfica (SIG), as empresas
podem fazer uso de mecanismos como mapas digitais das cidades, permitindo com isto, a tomada
de decisão no que concerne ao planeamento de transportes no processo de optimização de rotas.
Os transportes tem como objectivo superar as distâncias dentro de um território e responder às

necessidades dos passageiros ou bens transportados. Portanto, há vários aspectos a ter em conta que
vão desde os custos associados até ao tipo de transporte (passageiros/mercadorias). Factores
políticos também influenciam o modo de transporte, a título exemplificativo, regulamentações,
legislação, fronteiras e taxas.
O transporte permite o movimento de vens ou pessoas de um local para outro, desse modo, é
imprescindível que haja uma ligação a geografia, visto que se desenrola num determinado espaço. É
Necessário estudar o território, conhecer os seus constrangimentos de forma a construir cenários

reais e que respondam de forma segura e infalível [ CITATION Wil03 \l 1033 ].
Na área dos transportes, a utilização dos SIG é extremamente importante no que diz respeito ao
apoio na tomada de decisão. Conforme Abler (1988) citado por Muianga (2006), quando a tomada
de decisão envolve variáveis relacionadas a questões geográficas como (onde, como, quando,
quanto tempo leva, etc.) os SIG tornam-se num potencial sobejamente elevado no auxílio à tomada
de decisão.
1.1 Definição do Problema

Um dos grandes desafios impostos às organizações que trabalham na área de transportes é o
planeamento eficiente das rotas que os veículos deverão percorrer para cumprir com as actividades
a si associadas. Tais actividades podem ser: distribuição de mercadorias, transporte escolar, recolha
de lixo, etc.; mas os resultados obtidos, muita das vezes não são satisfatórios, isto é, a tarefa de
planear rotas num contexto com um número razoável de restrições é uma tarefa árdua.
Na actividade de recolha de resíduos sólidos, a optimização de rotas não só beneficia às

organizações responsáveis pela actividade mas também aos citadinos, visto que os resíduos sólidos
não podem ficar em contentores por muito tempo, devendo ser recolhidos antes que comecem a
atrair insectos pois podem causar doenças às pessoas, outro factor também é o aspecto da região
aonde se encontra o lixo.
O aumento descomedido da densidade populacional em zonas urbanas tem como consequência

maior produção de Resíduos Sólidos Urbanos (RSU), desse modo, o serviço de recolha destes
também cresce.
Uma das classificações dos RSU é quanto a sua proveniência, fazendo parte desta classificação, os
Resíduos Sólidos Domésticos (RSD). Estes provém, respectivamente, das habitações ou outros
locais que se assemelhem (CONSELHO MUNICIPAL DE MAPUTO, 2008).
No Distrito Urbano de KaMpfumo, os RSD são depositados diariamente em contentores, e para a

sua recolha, são necessários veículos capacitados de modo a atender a demanda de cada ponto de
recolha.
Os contentores para a deposição dos RSD são alocados em pontos estratégicos ao longo das vias da
cidade, e para a sua recolha, são alocados vários veículos que deverão percorrer uma rota de modo a
recolher os RSD, portanto, é necessário planear as rotas de forma a obter a solução óptima. A
solução óptima pode ser considerada como sendo aquela que minimiza a distância percorrida e/ou o
tempo de transporte. Assim sendo, para obtenção de tal solução, é necessário um bom
planeamento, no que concerne a distribuição dos veículos para os respectivos pontos de recolha.
O constrangimento surge quando se pretende replanear as rotas (por algum motivo como por
exemplo, aumento de contentores, aumento ou redução de veículos de recolha, alteração dos
sentidos das vias, etc.), isto é:
 Priorizar determinados pontos de recolha cuja demanda aumentou significativamente;
 Alocar mais veículos para recolha;
 Optimizar as rotas (minimizar os tempos ou a distancia da actividade de recolha), etc;
 Mudar o trajecto da rota e obter informação de custos (tempo e combustível) associadas a
esta.
Portanto, para concepção de um plano de rotas, algumas perguntas devem ser respondidas, como
por exemplo:
 Quantos veículos são necessários para atender a demanda e cumprir com o período de
trabalho estabelecido?
 Quantas viagens serão necessárias para realizar a actividade?
 O tempo que a actividade leva para ser realizada cumpre com o período estabelecido?
 Qual a rota que respeita as requisitos de negócio?
Portanto, devido a complexidade do problema, torna-se praticamente inviável executar esta tarefa
de forma manual, uma vez que é preciso ter em conta vários factores, como o aumento da densidade
populacional (o que implica em mais produção de RSD e consequentemente maior demanda nos
pontos), alocação de novos veículos, surgimento de novos pontos de recolha, alteração de sentido
das vias, estado das vias, etc.
Neste âmbito, surge a necessidade de implementar tecnologias que auxiliem no processo de

planeamento de rotas, portanto, a presente pesquisa apresenta o desenvolvimento de um sistema
com base em tecnologias de informação que permite o planeamento de rotas de veículos para
actividade de recolha e transporte de RSD.
1.2 Objectivos
1.2.1 Objectivo Geral
Desenvolver um Protótipo de um Modelo de Sistema para o Planeamento de Rotas de Veículos para
Recolha de RSD no Distrito Urbano de KaMpfumo.
1.2.2 Objectivos Específicos

 Identificar os constrangimentos no sistema actual de recolha e transporte de RSD no Distrito
Urbano de KaMpfumo;
 Desenhar um Modelo de Sistema para o Planeamento de Rotas de Veículos para Recolha de
RSD;
 Criar um Protótipo do Sistema com base no Modelo elaborado;
 Avaliar a aplicabilidade do Modelo com base em Protótipo operacional, analisando as
vantagens e desvantagens do uso do mesmo.
1.3 Estrutura do Relatório

O presente relatório está dividido em 5 capítulos. Sendo este o primeiro, onde se faz um
enquadramento lógico e contextual do trabalho, identificando o problema que motivou a pesquisa e
os objectivos que se pretendem atingir. O capítulo dois apresenta a metodologia utilizada no
trabalho para o alcance dos objectivos definidos, abordando as técnicas de recolha de dados
utilizadas e as ferramentas para desenvolvimento do protótipo. O capítulo três mostra o estado da
arte, apresentando os conceitos relacionados ao tema em causa, assim como alguns estudos feitos
relacionados ao planeamento de rotas, procurando mostrar as diversas abordagens existentes na
literatura. O quarto capítulo, aborda o sistema actual de recolha e transporte de RSD no Distrito
Urbano de KaMpfumo e apresenta também a modelação da aplicação proposta para o problema
identificado. O capítulo cinco apresenta uma análise dos resultados e recomendações da presente
pesquisa.
CAPÍTULO 2: METODOLOGIA
Neste capítulo, será descrita a metodologia utilizada para o alcance dos objectivos definidos.
2.1 Metodologia de Pesquisa

Para alcançar os objectivos traçados no presente trabalho, serão descritos abaixo, os passos seguidos
e técnicas utilizadas tendo em conta cada objectivo específico:
2.1.1 Abordagem
Na presente pesquisa, para a recolha de informação, utilizou-se técnicas como entrevistas,
observação e análise de documentação. Foi também necessário recorrer a literatura de modo a
perceber os conceitos teóricos relacionados com o tema em causa. Para a obtenção de dados
espaciais para o desenvolvimento do protótipo, recorreu-se a ferramentas online que fornecem
dados espaciais de forma gratuita.
2.1.2 Técnicas de colheita de dados

Para identificar os constrangimentos no sistema actual de recolha e transporte de RSD no
Distrito Urbano de KaMpfumo foi necessário utilizar as seguintes técnicas de recolha de dados:
a) Entrevistas
Foram feitas entrevistas formais e informais aos funcionários do Departamento de Gestão de
Resíduos Sólidos Urbanos do Conselho Municipal da Cidade de Maputo e aos funcionários
da empresa ECOLIFE (actualmente responsável pela recolha de RSD no Distrito Urbano de
KaMpfumo) com o intuito de perceber o funcionamento do sistema actual de recolha e
transporte dos RSD, bem como o processo actual de planeamento das rotas dos veículos. De
salientar que, por forma a obter informação, o candidato, teve em muitos casos de recorrer a
entrevistas informais.
A primeira entrevista foi realizada no dia 25 de Agosto de 2014 no Conselho Municipal da

Cidade de Maputo na Direcção Municipal de Gestão de Resíduos Sólidos Urbanos e
Salubridade (DMGRSUS) e teve como objectivo obter informação relacionada com todo
processo de gestão de RSU na cidade de Maputo, tendo como foco a actividade de recolha e
transporte, os serviços de recolha existentes, a quantidade de veículos bem como as suas

características.
A segunda entrevista foi realizada no dia 28 de Agosto de 2014 na empresa ECOLIFE

(actualmente responsável pelos serviços de recolha e transporte de resíduos sólidos no
Distrito Municipal de KaMpfumo), e teve como objectivo perceber o processo de criação
das rotas dos veículos, a quantidade de contentores na cidade (e respectivas capacidades), a
quantidade de veículos de recolha (e respectivas capacidades).
A informação recolhida foi a seguinte:

 Formas de Recolha;
 Contentores: quantidade, tipos; capacidade.
 Veículos: quantidade; tipos; capacidade de recolha.
b) Análise documental
Foi consultado o Plano Director para a Gestão de Resíduos Sólidos Urbanos na Cidade de
Maputo, onde foi possível recolher grande parte da informação necessária para o presente
trabalho, como por exemplo, os recursos utilizados na actividade de recolha e transporte, a
divisão dos distritos municipais da cidade de Maputo, etc.
c) Observação
Conforme Marconi e Lakatos (2003), na investigação científica são aplicadas várias
modalidades de observação, que variam de acordo com as circuntâncias. Para Ander-Egg
(1978) citado por Marconi e Lakatos (2003), uma das modalidades desta técnica é segundo
a participação do observador, que pode ser participativa ou não-participativa. No presente
trabalho, foi utilizada a observação não-participativa, que consistiu em percorrer uma das
rotas (Rota 3), junto com a equipa de recolha, nos dias 29/08/2014 e 02/11/2014, de modo
a melhor perceber como é feita esta actividade.
Através do percurso da rota, foi possível recolher grande parte da informação pretendida
para cada ponto de recolha. Foram também verificadas grandes limitações das equipas de
recolha na execução do seu serviço. A título exemplificativo refere-se: o estacionamento
abusivo por parte da população, que ao impedir/prejudicar a recolha, dificulta também, o
cumprimento do turno, no horário pré-estabelecido pelo Conselho Municipal; o facto de a

deposição de lixo não ser efectuada da maneira mais correcta, dando trabalho acrescido às
equipas, ou, até mesmo, às manobras necessárias (grande parte de marcha-atrás), para que a
equipa possa realizar a recolha.
Foi também verificado que alguns pontos de recolha estão localizados em pontos não
estratégicos sob ponto de vista de acesso para o veículo, fazendo com que o motorista tenha
de contornar um quarteirão inteiro para que possa posicionar o veículo de forma correcta de
modo a proceder com a recolha.
Na rota seguida, foram registados os tempos de recolha em cada ponto de recolha. Notou-se
que há mais demora no processo de recolha do que na transição de um ponto de recolha para
outro. Uma das razões tem a ver com a forma de organização do próprio lixo, que é
depositado de maneira desorganizada, o que consequentemente obriga a equipa de recolha a
primeiro organizar o lixo para de seguida efectuar a recolha. Em alguns pontos, onde o lixo
foi depositado de forma desorganizada, o processo de recolha chegava a demorar entre 15 a
25 minutos dependendo da demanda de cada ponto, enquanto que em locais onde o lixo era
colocado de forma mais organizada, o processo de recolha chegava a levar 2 a 5 minutos
dependendo da demanda de cada ponto.
Através do percurso da rota, foi possível recolher grande parte da informação pretendida. A
informação recolhida foi a seguinte:
 Para cada ponto visitado:
o Tempo de recolha;
o Grau de enchimento (com a impossibilidade de pesar os recipientes
individualmente, o grau de enchimento foi estimado);
o Quantidade de contentores.
Para desenhar um Modelo de Sistema para o Planeamento de Rotas de Veículos para Recolha
de RSD foi necessário fazer uma pesquisa bibliográfica sobre o PRV, SIG e sistemas de
planeamento de rotas existentes; foram ainda, selecionados alguns artefactos propostos por
XP/AMDD e alguns diagramas UML (Unified Modeling Language).
a) Pesquisa Bibliográfica
Foi necessário fazer uma pesquisa bibliográfica referente ao Problema de Roteamento de
Veículos, de modo a perceber o que já existe na literatura, os sistemas análogos existentes, e
a aplicação do SIG no Problema de Roteamento de Veículos.
b) Modelação
Para a modelação do sistema, alguns diagramas UML foram desenvolvidos como por
exemplo: diagrama de classes e de casos de uso; foram também desenvolvidos alguns
modelos, seguindo as práticas de XP/AMDD, como por exemplo: interface de utilizador,
CRC cards, arquitectura de forma livre, user stories e storyboard.
c) Ferramenta de modelação
Como ferramenta de modelação, para os diagramas UML, foi utilizado o Visual Paradigm
Community Edition versão 11.2, por ser gratuito, fácil de utilizar e suportar diversos
diagramas; para conceber os modelos de interface de utilizador e storyboard, foi utilizado o
Pencil versão 2.0.6 por ser fácil de utilizar, gratuito e possuir diversos componentes gráficos
para construção de interfaces.
Para avaliar a aplicabilidade do Modelo com base em Protótipo operacional, analisando as

vantagens e desvantagens do uso do mesmo foi necessário recorrer a informação sobre as
ferramentas no que diz respeito às regras de utilização. Foram analisados dados colhidos durante o
trabalho, de modo a verificar se apresenta os requisitos definidos de modo a apoiar na tomada de
decisão.
2.2 Desenvolvimento do Protótipo

2.2.1 Abordagem
“Todo o projecto, independente da dimensão, deve seguir um estrutura básica ou processo
(metodologia), que pode ser tanto um checklist ou um processo mais formal” (Hemrajani, 2006,
p.41).
Para o desenvolvimento da solução proposta no presente trabalho a metodologia adoptada baseou-se

na metodologia de desenvolvimento de software, por ser uma metodologia de desenvolvimento de
software ágil baseada nos valores simplicidade, comunicação, feedback. A sua implementação não
requer a utilização de diagramas ou processos formais, mas sim, fazer uma equipa unir-se em torno
de algumas práticas simples, obter feedback suficiente e ajustar as práticas para a sua situação
particular (Beck e Andres, 2004).
Foi tammbém utilizada a metodologia AMDD (desenvolvimento ágil orientado à modelos), que é
uma abordagem de desenvolvimento de software onde modelos extensivos são criados antes do
código fonte ser escrito[ CITATION Sco07 \l 1033 ]. Segundo Hemrajani (2006), a combinação
XP/AMDD é uma boa escolha pois ambos métodos são ágeis e complementam-se; Por um lado, o
XP foca em todo o ciclo de vida do desenvolvimento, por outro lado, a AMDD, fornece práticas
efectivas para a modelação e documentação (por exemplo, o modelo de interface do utilizador).
Artefactos
Protótip Arquitectu
de Nível
o de UI e User Domain ra de escopo do
Final
storyboa stories Model forma projecto, plano
rd livre final
plano
Mapa de Diagram
Artefactos Modelo intermédio,
CRC fluxo da as de
de Nível físico de testes de
cards aplicaçã classe e
Intermédio dados aceitação
o pacote
Figura 2.1: Artefactos a produzir nos níveis final e intermédio segundo a XP/AMDD.
Fonte: (Hemrajani, 2006, p.64).
2.2.2 Fonte de dados espaciais

Os dados espaciais da cidade de Maputo foram obtidos a partir do OpenStreetMap (OSM), que é
um projecto de mapeamento colaborativo para criar um mapa livre e editável de todo mundo,
portanto, a partir deste, foi possível seleccionar a região necessária para o presente trabalho, extrair
e importar para o SGBD PostgreSQL/PostGIS.
2.2.3 Ferramentas
Para criar o Protótipo foram selecionadas ferramentas apropriadas para o cumprimento dos
objectivos do presente trabalho, portanto, foram utilizadas as seguintes ferramentas: a linguagem de
programação Python, o Sistema de Gestão de Bases de Dados PostgreSQL, o sistema de controlo de
versões Git, o Ambiente de Desenvolvimento Integrado (IDE) PyCharm, o framework Django; além
de tecnologias web como JavaScript, XML, JSON e HTML5.
a) Linguagem de programação
Foi utilizada a linguagem de programação Python por esta ser open source, multiplataforma,
orientada a objectos, possuir uma sintaxe simples, documentação clara, comunidade de
desenvolvedores activa, ser uma linguagem de desenvolvimento rápido (RAD – Rapid
Application Development), seguir as práticas DRY (Don’t Repeat Yourself), KISS (Keep It
Simple, Stupid) e por possuir diversos frameworks.
b) Sistema de Gestão de Base de Dados (SGBD)

Foi utilizado o SGBD PostgreSQL por ser um SGBD open source, gratuito, possuir alta
performance e também pelo facto de possuir as extensões: PostGIS (que adiciona suporte a
objectos geográficos permitindo executar queries de localização) e pgRouting (que adiciona
funcionalidades de roteamento geoespacial).
PostgreSQL1 e PostGIS2
Com o desenvolvimento de um GIS, a necessidade do armazenamento de dados espaciais
torna-se muito maior. As bases de dados simples, isto é, que guardam dados alfanuméricos,
não são suficientes para o armazenamento de dados espaciais. Entretanto, informação
espacial e objectos geográficos precisam de um método fiável e eficaz para o
armazenamento e consulta destes. Portanto, foram introduzidas bases de dados espaciais.
Actualmente, existem diversos SGBDs que suportam o armazenamento de dados espaciais:
Oracle, Microsoft SQL Server desde a versão 2008, PostgreSQL, etc.
Devido às necessidades do processamento de dados geográficos e dados geométricos no

presente trabalho, adoptou-se o PostgreSQL, que é um SGBD robusto, open source, objecto-
relacional, que foi adoptado junto com a extensão espacial PostGIS.
pgRouting3
pgRouting é uma extensão do SGBD geoespacial PostgreSQL/PostGIS, escrito em C++, que
adiciona funcionalidades de roteamento e outras funcionalidades de análise de redes. Este
consiste na utilização de bibliotecas para cálculo de grafos, suporta diversos Sistemas
Operativos como Windows, Linux, MAC OS X, é gratuito e open source.
1
http://www.postgresql.org/
2
http://postgis.net/
3
http://pgrouting.org/
A finalidade do pgRouting é calcular o caminho a seguir desde um ponto do mapa (definido

como origem) até outro ponto (definido como destino).
O primeiro passo é possuir um conjunto de dados adequados sobre os quais o pgRouting irá
trabalhar, ou seja, o pgRouting necessita de dados geográficos para criar uma rede de
roteamento. Por sua vez, para criar a rede de roteamento, os dados precisam de uma
topologia, ou seja, uma cadeia de comunicação usada pelos nós da rede para comunicarem-
se. Esta informação é obtida mediante a informação contida na coluna the_geom da tabela
ways. Este campo contém a informação geométrica necessária para criar a topologia de
roteamento desejada.
A versão 2.0 do pgRouting suporta funções para diversos algoritmos como Dijkstra, A*, etc.
c) Sistema de controlo de versões

Foi utilizado o Git, por este ser multiplataforma, gratuito, open source, rápido, distribuído
(permitindo trabalhar offline), está integrado em diversas IDEs, o seu aprendizado é um
pouco complexo no entanto é do domínio do candidato.
d) Framework
Foi utilizado o framework Django por ser voltado ao desenvolvimento ágil, incluir suporte
para sessões, formulários, autenticação, backend, mapeamento de dados para vários SGBDs
como PostgreSQL, MySQL, SQLite e Oracle, utiliza o padrão MTV (Model-Template-
View) equivalente ao MVC (Model-View-Controller), além de ser gratuito e possuir grande
comunidade de desenvolvedores, o que facilita na correcção de bugs e suporte em
determinadas dificuldades que podem ter sido resolvidas por outros desenvolvedores.
Django4
Django é um framework para desenvolvimento de aplicações web, open source, escrito na
linguagem de programação Python, possui um servidor web embutido que é aplicável para
ambientes de desenvolvimento, dentre outras vantagens. A seguir alguns componentes do
framework Django:
4
https://www.djangoproject.com/
 Django ORM: o Django ORM é uma ferramenta bastante útil. Este trata a criação
da base de dados, permite executar comandos como insert, update, delete e
comandos muito mais avançados. Este suporta diversos SGBDs como MySQL,
PostgreSQL, SQLite, etc.;
 Forms: este componente é para a criação de formulários. A sua utilização consiste
na definição dos tipos de campos (texto, selecção, etc.) e a respectiva informação
para a validação. O componente será responsável por mostrar as mensagens de erro
consoante a informação de validação previamente definida;
 Admin: este componente permite gerar a área da administração do sistema,
permitindo executar operações como cadastro, actualização, listagem e remoção de
registos sem precisar codificar tais funcionalidades;
 Outros: o Django possui diversos outros componentes que facilitam no
desenvolvimento, como é o caso das componentes: Segurança, GIS (para construir
aplicações GIS), etc.
e) IDE
O IDE utilizado foi o PyCharm por este integrar diversas ferramentas para facilitar o
desenvolvimento. Este inclui o sistema de controlo de versões Git, o framework Django,
possui ainda ferramentas para depuração do código, code completion, code navigation,
execução de testes, permite gerar código e possui diversas extensões que facilitam no
desenvolvimento.
f) Outras ferramentas utilizadas

 Leaflet: biblioteca JavaScript para manipulação de dados num mapa digital, permitindo
executar funções como drag and drop, click, etc. Em detrimento desta ferramenta, pode-
se utilizar a ferramenta OpenLayers, que tem o mesmo propósito que o Leaflet;
 OSM: serviu como fonte de dados para obtenção da rede de estradas e respectivas
informações como sentidos das vias, distâncias, além de servir como fonte para obtenção
do mapa digital;
 OSRM: ferramenta para computar a matriz de distância;
 osrm-tools: extensão do PostgreSQL para aceder a API do OSRM através de funções;
 osm2pgrouting: ferramenta utilizada para importar dos dados do OSM para o
pgRouting;
 Git: sistema de controlo de versões distribuído, utilizado para a gestão de configurações

da aplicação;
 Vagrant: é uma ferramenta para construir ambientes completos de desenvolvimento
utilizando tecnologias de virtualização;
 Puppet: é uma ferramenta para configuração dos recursos do sevidor.
CAPÍTULO 3: REVISÃO DA LITERATURA
Neste capítulo, serão apresentados conceitos relativos ao tema em causa, como o problema de
roteamento de veículos, a sua aplicabilidade no geral, a sua aplicabilidade na recolha de resíduos
sólidos e o papel dos SIG nesse problema.
3.1 Roteamento de Veículos

O PRV foi introduzido na literatura a partir da publicação do artigo “The truck dispatching
problem” por Dantzig e Ramster (1959), onde pretendia-se tratar do problema de gerir a
distribuição de gasolina entre vários postos de abastecimento e propôs-se a primeira formulação de
programação matemática e algorítmica para o problema.
Conforme Goldbarg e Luna (2005), um sistema de roteamento pode ser considerado como um
conjunto organizado de meios que tem por objectivo o atendimento de demandas localizadas nos
arcos ou nos vértices de alguma rede de transportes. Tal sistema, por ser globalmente complexo,
pode ser dividido, sob a óptica da operação, em três partes: Estratégica, Onde são tomadas decisões
que normalmente possuem impacto sobre todo o sistema e um efeito duradouro, tais decisões, se
forem equivocadas, irão produzir sérias difculdades para a futura operação e optimização do
sistema; Táctica, Onde caberão decisões que definirão as áreas atendidas, a dimensão da frota,
alocação da tripulação aos veículos e os turnos de trabalho. Decisões como número de garagens e
sua localização, manutenção podem ainda ficar a vargo do nível táctico; Logística, O objectivo
maior da logística é fazer chegar é fazer chegar provisões e/ou serviços a pontos de consumo, a
partir de pontos de suprimento. Um sistema logístico completo deve englobar cuidados que se vão
desde o processo de aquisição, estoque e distribuição de produtos sobre uma rede de demanda, até
os relacionados com os seres humanos, política de investimento e renovação de frota etc.
Mercado de actuação Número de rotas

Operação da frota de
veículos
Decisões Decisões
Decisões
Número de tácticas
veículos
Estratégicas para o
Dimensões da qualidade operacionais para o
para o PRV
PRV
Localização de fábricas e
Contratação de mão-de-obra PRV
Emprego da mão-de-obra
depósitos
Regime de trabalho
Tipos de veículos
Localização das garagens Plano económico e flexível
para o atendimento da rede
Restrições legais Nível de estoque de demanda
Figura 3.2: Decisões estratégicas, tácticas e operacionais para o PRV.

Fonte: adaptado de Goldbarg e Luna (2005).
Segundo Goldbarg e Luna (2005, p.375), “O PRV aborda basicamente a determinação de

sequências de visitas que objectivem atender a uma determinada função objectivo. As visitas podem
tanto estar associadas às ligações (arestas) ou aos pontos (nós) do grafo que representa as possíveis
conexões entre os pontos de visita (ou pontos de ligações entre as arestas)”.
A solução de um PRV objectiva determinar o melhor conjunto de rotas, onde cada uma destas é
geralmente realizada por um único veículo, de modo que todos os requisitos dos clientes sejam
cumpridos, todas as restrições operacionais sejam satisfeitas e que o custo global da operação seja
minimizado. A Figura 3 .3 representa um cenário inicial para um PRV e a Figura 3 .4 representa
uma solução para um PRV.
Consumid
ores
Depósito
Depósit
o
Figura 3.3: Cenário inicial de um PRV. Figura 3.4: Solução de um PRV.

Fonte: adaptado de Costa (2005). Fonte: adaptado de Costa (2005).
3.1.1 Extensões do PRV

 Roteamento de Veículos com Janelas de Tempo
Nessa variante existe um intervalo de tempo associado aos pontos de demanda ou de colecta
“janela de tempo”. A janela de tempo pode se referir ao tempo de chegada, de partida ou de
duração do serviço no cliente;
 Problema com Colecta e Entrega
Nessa variante, a nos pontos a visitar, a operação é de colecta e entrega, em algumas
variantes, primeiro é feita a entrega e de seguida a colecta, em outros casos, o processo é
inversos;
 Etc.
3.1.2 Classificação
O PRV está entre os mais complexos da área de optimização combinatória. Pelo grande número de
variáveis, diversidade de restrições e objectivos apresentados, impõem-se o exame de uma
cuidadosa classificação para seu melhor entendimento. Actualmente não existe uma classificação
largamente adoptada, portanto, a classificação do PRV tem sido abordado por diversos autores.
Uma das classificações (Tabela 3 .1) é de Bodin e Golden (1981) citados por Goldbarg e Luna
(2005), que classificam o PRV em três tipos: problema de cobertura de nós (quando a colecta é
realizada em pontos específicos), o problema de cobertura de arcos (quando a colecta é realizada em

segmentos de vias) e problema geral de roteamento (quando a colecta é realizada em nós e arcos).
Tabela 3.1: Classificação de PRV

Critério Classificação
Tempo para servir um determinado nó  Tempo especificado e
ou arco prefixado;
 Janela de Tempo (Time
Windows).
Número de domicílios  Um domicílio;
 Mais de um domicílio.
Tamanho da frota de veículos  Um veículo;
 Mais de um veículo.
Tipo de frota disponível  Homogênea;
 Heterogênea.
Localização da demanda  Nos vértices;
 Nos arcos.
Restrições na capacidade de veículos  Todos sujeitos às mesmas
restrições;
 Restrições diferentes.
Tempo de roteamento  O mesmo para todos os
veículos;
 Tempos diversos;
 Sem restrições de tempo.
Custos  Variáveis (associados à rota
escolhida);
 Fixos.
Operação  De entrega;
 De recolha;
 Ambas.
Objectivo  Minimizar custos fixos;
 Minimizar custos de operação
da rota;
 Minimizar o número de
veículos.
3.1.3 Aplicações
O PRV possui um número elevado de aplicações práticas. Destas, as seguintes são destacadas:
 Distribuição de jornais;
 Transporte escolar;
 Recolha de lixo;
 Entrega de correspondências;
 Sistemas de transportes colectivos urbanos (táxi, autocarros, metro);
 Etc.
3.1.4 Complexidade computacional e formas de resolução

Na teoria da complexidade computacional, que é a área da ciência da computação que procura
determinar porquê certos problemas são tão difíceis de serem resolvidos por computadores, o PRV
é considerado um problema NP – Árduo do inglês (NP-Hard), isto quer dizer, que não é conhecido
um algoritmo de resolução em tempo polinomial. O tempo polinomial pode ser interpretado como o
factor que separa a classe computacional de problemas que podem ser resolvidos eficientemente
daqueles que não podem. A definição de tempo polinomial de um algoritmo refere-se ao tempo de
execução de um algoritmo que é função polinomial do tamanho da entrada.
A notação assimptótica ou Grande-O descreve o comportamento dos limites que uma função f (n)
tem, em relação à taxa de crescimento n. Portanto funções diferentes com semelhante taxa de
crescimento são representadas utilizando a mesma notação assimptótica. Deste modo é possível
comparar algoritmos e distingui-los quanto à sua eficiência. A Figura 3 .5 representa um gráfico de
evolução da função f (n) com o aumento da entrada n [ CITATION Bil12 \l 1033 ]. Foram
representadas algumas das classes de funções mais utilizadas nos algoritmos, onde se pode observar
que qualquer algoritmo de ordem factorial O(n !) é muito pouco eficiente pois tem um crescimento
ainda superior ao exponencial.
Figura 3.5: Crescimento da função f (n) com o aumento da entrada n.
Fonte: [ CITATION Bil12 \l 1033 ].
Na Figura 3 .6 são ilustradas algumas técnicas para a resolução do PRV.
Problemas
Algoritmos Exactos
Polinomiais
Problemas de
Roteamento de Relaxações
Veículos
Problemas NP- Algoritmos

Árduos Aproximativos
Algoritmos Exactos
Figura 3.6: Estratégias para solução do PRV.

Fonte: adaptado de Goldbarg e Luna (2005).
3.1.5 Alguns algoritmos para planeamento de rotas

Algumas metaheurísticas para resolução do PRV:
 Algoritmos Genéticos;
 Simulated Annealing;
 Busca Tabu;
 GRASP (Greedy Randomized Adaptative Search Procedure).
3.1.6 Planeamento de rotas na recolha de lixo

A actividade de recolha de RSU (vulgarmente chamados por lixo) consiste basicamente em
proceder ao levantamento e transporte dos RSU a partir do local onde foram acondicionados,
mediante meios de transporte adequados, para o local de destino, podendo este ser um local de
tratamento ou ainda o depósito final. Esta actividade caracteriza-se pelo envolvimento dos cidadãos,
que devem acondicioná-los adequadamente a apresenta-los em dias, locais e horários pré-
estabelecidos pelo município.
A actividade de recolher os RSU compreende desde a partida do veículo (que irá efectuar a recolha)
da sua garagem, englobando todo o percurso gasto na viagem para remoção dos resíduos dos locais
onde foram acondicionados aos locais de descarga, até o seu retorno ao ponto de partida.
Os resíduos colectados poderão ser transportados para estações de transferência ou transbordo, para
locais de processamento e recuperação (incineração ou centrais de triagem e compostagem) ou para
seu destino final (aterros ou lixeiras).
O objectivo do roteamento na recolha de resíduos sólidos é definir um conjunto de rotas que

atendam à determinadas áreas. A meta é realizar o percurso com o menor custo em termos de
quilometragem e tempo total, atendendo às restrições de movimentação dos veículos nas ruas da
cidade, capacidade dos veículos e tempo de serviço máximo da frota.
Na literatura, diversos estudos tem sido feitos no que concerne a resolução do PRV na recolha de
resíduos sólidos. A título de exemplo, temos o caso de Oliveira (2008), que desenvolveu o trabalho
cujo o tema era “Optimização de Circuitos de Recolha de Lixos Domésticos em Zonas Urbanas”.
Esse trabalho tinha como objectivo principal o desenvolvimento de algoritmos de optimização e de
aplicações informáticas, suportadas em sistemas de informação geográfica, que permitam a
determinação de percursos de recolha de RSU, numa dada região, com a subsequente redução de
custos inerentes à recolha.
Ainda na área da optimização, Beijoco (2011) desenvolveu o trabalho cujo o tema foi
“Optimização de um Sistema de Recolha e Transporte de Resíduos Sólidos Urbanos”.
Diferentemente do trabalho de Oliveira (2008), que tinha mais foco no desenvolvimento de
algoritmos, a abordagem de Beijoco (2011) era mais focada nas implicações ambientais e
financeiras da optimização, onde o objectivo era a minimização do impacto negativo ambiental dos
associados aos percursos de recolha e transporte de RSU, por exemplo, redução de emissões
poluentes.
Davide (2012), cujo tema foi “Sistema de Gestão Para a Recolha de Material Reciclável”, trouxe
uma abordagem um pouco diferente. O seu trabalho consistia no desenvolvimento de uma
infraestrutura distribuída que dê suporte à recolha de material reciclável no meio urbano. A
abordagem de Davide (2012) tinha uma componente de hardware, pois o seu trabalho consistiu na
implementação de um sistema inteligente de alerta que recolhe a informação do nível de
enchimento dos pontos de recolha, e envia essa informação para uma entidade responsável, através
de tecnologias de informação.
3.2 Sistemas de Informação Geográfico nos Transportes

O termo SIG é utilizado em diversas áreas científicas, portanto, tem sido objecto de várias
definições por parte de diferentes autores, deste modo, é provável que os conceitos variem com a
forma como os SIG são utilizados, ou por outra, como sugere Pickles (1995) citado por Maguire
(1991), esta variedade de definições pode ser explicada, pelo facto de qualquer definição de SIG
depender de quem o define, do conhecimento de quem o define e do ponto de vista de quem o
define. Por conseguinte, assim como constatado durante a elaboração do presente trabalho, autores
como Maguire (1991), Heywood et al. (2006) e Muianga (2006), consideram que é difícil dar uma
definição definitiva e genérica sobre SIG.
Algumas das definições propostas por alguns autores:

 “um poderoso conjunto de ferramentas para colectar, guardar, recuperar, transformar e
disponibilizar dados espaciais do mundo real” (Burrough 1986:6 citado por Maguire 1991);
 “um sistema para a captura, armazenamento, verificação, manipulação, análise e ilustração

de dados que são espacialmente referenciados para a Terra” (DoE 1987:132 citado por
Maguire 1991);
 “um sistema de suporte a decisão envolvendo a integração de dados espacialmente
referenciados num ambiente de resolução de um problema” (Cowen 1988:1554 citado por
Maguire 1991);
 “uma tecnologia de informação que armazena, analisa e visualiza ambos dados espaciais e
não espaciais” (Parker 1988:1547 citado por Maguire 1991);
 “qualquer conjunto de procedimentos manual ou baseado em computador utilizados para
guardar e manipular dados geograficamente referenciados” (Aronoff 1989:39 citado por
Maguire 1991);
 “um sistema de informação geográfica (SIG) é uma ferramenta tecnológica para
compreender a geografia e tomar decisões inteligentes” (ESRI 2009, 2013).
É possível notar que alguns autores ao definir SIG, favorecem determinadas características. Assim
sendo, podem distinguir-se, basicamente, três tipos diferentes de perspectivas: a visão baseada em
mapas, em bases de dados e na análise espacial (Maguire, 1991). Segundo o mesmo autor, a
primeira perspectiva (a visão baseada em mapas), foca nos aspectos cartográficos dos SIG; os
aderentes desta visão vêem os SIG como sistemas de processamento de mapas ou sistemas de
visualização. A visão baseada em bases de dados enfatiza a importância de uma base de dados bem
desenhada e implementada (Frank 1988 citado por Maguire 1991). A terceira perspectiva (visão
baseada na análise espacial), enfatiza a importância da análise espacial. Esta visão foca na análise e
modelação na qual o SIG é visto mais como uma ciência de informação espacial do que uma
tecnologia (Goodchild 1990, Openshaw 1991 citados por Maguire 1991).
Heywood et al. (2006), sugere, que no geral, as definições de SIG compreendem 3 componentes
principais. Estas, indicam o SIG como um sistema computacional, o que implica mais do que um
conjunto máquinas numa secretária, mas inclui hardware, software e procedimentos apropriados
(ou técnicas e ordem para implementação de tarefas). Estas também indicam que o SIG utiliza
dados espacialmente referenciados ou geográficos, e que o SIG executa diversas tarefas de
análise e gestão nestes dados, incluindo a sua introdução (input) e produção de resultados (output).
3.2.1 Áreas de aplicação

Na secção anterior, onde foram vistas as diferentes propostas de definições de SIG, foi possível
notar que tal variedade pode ter a ver com a forma de como o SIG é utilizado em diversas áreas.
Na Tabela 3 .2, apresentam-se algumas das diversas áreas onde o SIG pode ser aplicado.
Tabela 3.2: Áreas de aplicação do SIG.

Actividade Aplicação
Sócio-económica/  Saúde;
governação  Planeamento de transportes;
 Gestão urbana;
 Etc.
Agências de defesa  Suporte no planeamento táctico;
 Segurança interna e anti-terrorismo;
 Etc.
Comércio e negócio  Partilha de análises de mercado;
 Gestão de frotas;
 Etc.
Utilidades  Gestão de redes;
 Telecomunicações;
 Etc.
Gestão Ambiental  Monitoramento de poluição;
 Gestão de desastres naturais;
 Gestão de recursos naturais;
 Etc.
Fonte: adaptado de Heywood et al. (2006).
3.2.2 SIG e o PRV

A abordagem do SIG para o PRV é chamado de Sistema de Informação Geográfica para
Transportes (SIG-T), tais sistemas podem ser definidos, segundo Fletcher (2000) citado por Miller e
Shaw (2001), como sendo “combinações de hardware, software, dados, pessoas, organizações
interconectados para colectar, armazenar, analisar e comunicar tipos específicos de informação
sobre a Terra. Tais tipos específicos de informação são sistemas de transporte e regiões geográficas
que afectam ou são afectadas por sistemas”.
Na área dos transportes, a análise geográfica é essencial para a tomada de decisão, seja para gerir e
monitorizar frotas, monitorizar condições das estradas, optimizar rotas ou para fazer manutenção de
redes de transportes.
A percepção destes procedimentos numa perspectiva geográfica é crucial para gestão de custos e
recursos, pois estes são a chave deste negócio.
Os profissionais do sector dos transportes e logística utilizam os SIG para integrarem análises de
mapas como suporte à decisão de planeamento e análise de redes de transportes, monitorização de
veículos e optimização de rotas, inventário de monitorização, planeamento de rotas , dentre outros.
Actualmente existem diversos softwares para suporte no planeamento de rotas, tais softwares são
genéricos, isto é, abrangem aspectos genéricos e comuns aos mais variados problemas de
planeamento de rotas e muitas vezes pouco específicas para as necessidades particulares de cada
cliente.
Alguns softwares para planeamento de rotas existentes:

 ArcGIS5: software GIS desenvolvido pela ESRI, o ArcGIS, possui diversos módulos, não
se limitando apenas a área do transporte. O seu custo varia de acordo com as necessidades
do cliente.
 logvrp6: o logvrp é um Software as a Service (SaaS) que funciona em ambiente web. O
preço mensal varia de acordo com a quantidade de pontos que precisam ser atendidos,
sendo que, para cada ponto é cobrado $1.00.
 TrackRoad7: é um SaaS que funciona em ambiente web, o custo mensal varia entre $9.50
a $59.50 dependendo do plano adquirido.
5
https://www.arcgis.com
6
https://logvrp.com/
7
http://trackroad.com/
CAPÍTULO 4: ÁREA DE ESTUDO E MODELO PROPOSTO
Neste capítulo, apresentar-se-á o área considerada para análise e a modelação dos requisitos da
aplicação.
4.1 Distrito Municipal de KaMpfumo

A área considerada para o estudo é o Distrito Urbano de KaMpfumo, localizado na cidade de
Maputo.
A cidade de Maputo situa-se na Baía de Maputo, na província homónima, no Sul de Moçambique.

A cidade está dividida em sete distritos municipais, que se encontram, por sua vez, divididos em
bairros, como se ilustra abaixo.
Tabela 4.3: Divisão Administrativa da Cidade de Maputo

Unidade Administrativa Bairros Povoações
Autárquica
Distrito Urbano de KaMpfumo Central A, B e C; Alto Maé A e B;
Malhangalene A e B; Polana Cimento A
e B, Coop e Sommerchield.
Distrito Urbano de Nhamankulu Aeroporto A e B; Xipamanine;
Minkadjuíne; Unidade 7; Chamanculo
A, B, C e D; Malanga e Munhuana.
Distrito Urbano de KaMaxaquene Mafalala; Maxaquene A, B, C e D;
Polana Caniço A e B e Urbanização.
Distrito Urbano de KaMavota Mavalane A e B; FPLM; Hulene A e B;
Ferroviário; Laulane; 3 de Fevereiro;
Mahotas, Albazine e Costa do Sol.
Distrito Urbano de KaMubukwana Bagamoyo; Benfica; Inhagoia A e B;
Jardim, Luís Cabral; Magoanine;
Malhazine; Nsalane; 25 de Junho A e
B; e Zimpeto.
Distrito Municipal de KaTembe Gwachene; Chale; Inguice; Ncassene e
Xamissava.
Distrito Municipal de KaNyaka Ingwane; Ribjene e Nhaquene.
Figura 4.7: Localização da Cidade de Maputo.
Figura 4.8: Distrito Urbano de KaMpfumo.
O Conselho Municipal é um órgão executivo colegial do Município e exerce os seus poderes em

conformidade com a constituição, lei e seu regulamento. O Conselho Municipal da Cidade de
Maputo (CMCM) conta com diversas direcções. A gestão dos resíduos sólidos enquadra-se na
Direcção de Serviço Municipal de Gestão de Resíduos Sólidos Urbanos e Salubridade
(DMGRSUS).
A produção de RSU na Cidade de Maputo resulta numa quantidade de cerca de 383.980 toneladas,
sendo que os Resíduos Sólidos Domésticos representam a maior parte da produção, com cerca de
594 toneladas por dia (CONSELHO MUNICIPAL DE MAPUTO, 2008).
Tabela 4.4: Tipos de RSU.

Alguns Tipos de RSU Proveniência
Resíduos sólidos domésticos Habitações ou locais semelhantes.
Resíduos sólidos comerciais Estabelecimentos comerciais,
instituições públicas, escritórios,
restaurantes ou locais semelhantes.
Resíduos sólidos industriais Gerados em actividades ou processos
industriais, bem como os que resultam
de actividades de produção e
distribuição de electricidade, gás e
água.
Resíduos de jardins ou espaços Limpeza e manutenção de jardins ou
particulares ou resíduos verdes hortas, públicos ou privados
(nomeadamente aparas, ramos e
troncos, relva e outras ervas).
Resíduos dos mercados e feiras Produzidos em mercados e feiras.
Fonte: (CONSELHO MUNICIPAL DE MAPUTO, 2008).
A Tabela 4 .5 resume os cálculos e estimativas das quantidades dos diferentes tipos de RSU
gerados diariamente na cidade de Maputo.
Tabela 4.5: Resumo das quantidades de RSU produzidas diariamente na cidade de Maputo.
Tipos de RSU Produção por dia Produção por dia
[ton/dia] [percentagem]
RS Domésticos 594 56%
RS Comerciais/Industriais 258 24%
RS Verdes 30 3%
RS de Mercados e Feiras 89 8%
RS Volumosos 10 1%
RS da Construção 50 5%
RS da Varredura 22 2%
Total RSU em Maputo 1052 100%
Fonte: (CONSELHO MUNICIPAL DE MAPUTO, 2008).
4.1.1 Sistema actual de recolha e transporte de RSD no Distrito Urbano de KaMpfumo

A gestão de RSU na cidade de Maputo é da responsabilidade do Conselho Municipal da Cidade de
Maputo, no entanto, devido a vários factores, este pode terceirizar algumas actividades para o sector
privado, como é o caso da actividade de recolha e transporte de RSD.
A recolha e transporte de RSD consiste em recolher os RSD nos locais onde são depositados e
transportá-los até o local de destino, podendo ser um aterro ou lixeira. No Distrito Municipal N o. 1,
a actividade de recolha e transporte é actualmente desempenhada pela empresa privada ECOLIFE,
no entanto, esta executa as suas actividades sob monitoria do Conselho Municipal da Cidade de
Maputo.
Actualmente, para a recolha de Resíduos Sólidos Domésticos, estão instalados na cidade de

Maputo, cerca de 600 contentores para deposição indiferenciada de resíduos. Nestes, os munícipes
deverão depositar os resíduos diariamente num horário previamente estabelecido (actualmente
15:30-18:30), em algumas zonas, a recolha é feita porta a porta como é o caso das zonas onde se
localizam as embaixadas também denominadas “zonas VIPs”.
Nos pontos de recolha, os contentores são agrupados entre 2 a 6 aproximadamente, dependendo da

demanda de cada ponto, podendo haver pontos com 1 contentor. Os contentores possuem
capacidade (em volume) de 1,1m3 e 6m3; e para a sua recolha, utilizam-se veículos compactadores
que possuem entre 20m3 a 30m3. Tais veículos tem capacidade de recolher grande quantidade de
resíduos pela sua capacidade de compactação. Podem também ser utilizados veículos de caixa
aberta no caso da recolha porta a porta.
Aos veículos, são alocados recursos humanos: 1 motorista e 2 cantoneiros (responsáveis por colocar
os resíduos no camião de recolha). A frequência de recolha é diária, tendo inicio as 18:30 e leva um
período de aproximadamente 8 horas para cumprir a rota e retornar ao ponto de partida.
Os veículos não precisam necessariamente voltar ao ponto de origem (garagem) vazios, isto é, se a
rota for cumprida sem o veículo estar cheio, o veículo poderá retornar a garagem.
Figura 4.9: Exemplo de Contentor de 1,1m 3 Figura 4.10: Contentor de 6m3.

(1100 litros).
Figura 4.11: Exemplo de Camião Figura 4.12: Exemplo de Camião Tipo Caixa
Compactador. Aberta.
4.2 Procedimento pgr_cvrpOneDepot

O pgr_cvrpOneDepot() é um procedimento para o pgRouting desenvolvido por Khondoker
Razequl Islam e depois melhorado por Mukul Priya [ CITATION Muk14 \l 1033 ]. Este
procedimento resolve o problema de roteamento de veículos com janelas de tempo. O procedimento
está relacionado com a entrega de mercadorias de um depósito central para uma variedade de
clientes e permite priorizar entregas por janela de tempo. Por exemplo, pode haver uma entrega que
deverá ser feita ente 8:00h até 10:00h. Este procedimento permite alocar vários veículos com
capacidades diferentes e a lista de entregas que devem ser feitas. As entregas são atribuídas aos
veículos e cada veículo obtém uma lista ordenada de entregas que deverá fazer tendo como ponto
final, o depósito central.
O utilizador deve criar as tabelas para armazenar os dados dos veículos, dos pontos a recolha e dos
custos de transporte. O utilizador deve também incluir na tabela dos pontos de recolha, a
localização do depósito e o seu período de operação (janela de tempo). De seguida, utilizando
outras ferramentas do pgRouting, a matriz de distâncias precisa ser gerada e de seguida o problema
é resolvido internamente utilizando a Busca Tabu.
No estudo em causa, considerou-se os clientes como sendo os pontos de recolha.
4.2.1 Tabelas necessárias

a) Veículos
Esta é uma tabela relativamente simples que consiste no armazenamento de dados do
veículo. Esta deve conter pelo menos duas colunas. Uma é o “vehicle_id” que representa o
identificador do veículo (único para cada veículo), a outra coluna é a capacidade de um dado
veículo em um número de unidades.
Tabela 4.6: Parâmetros da tabela Veículos

Coluna Descrição
id Identificador do veículo, este deverá ser único para cada
ponto.
capacity A capacidade do veículo.
b) Pontos
Esta tabela contém a informação dos clientes (no caso do presente trabalho, pontos de
recolha), e também a informação do depósito central (ponto de onde o veículo parte e deverá
voltar). Esta tabela deverá possuir sete colunas como ilustrado a seguir:
Tabela 4.7: Parâmetros da tabela Pontos

Coluna Descrição
id Identificador do ponto, este deverá ser único para cada
ponto.
x A coordenada geográfica longitude do ponto.
y A coordenada geográfica latitude do ponto.
order_unit A demanda do ponto.
open_time Tempo de Início para o atendimento do ponto.
close_time Tempo final para atendimento do ponto.

service_ti Tempo estimado para a realizar a recolha num dado ponto.
me
c) Distância
Esta tabela contém o custo de distância de viagem de ponto à ponto. Esta tabela poderá ser
gerada utilizando funções disponíveis no pgRouting. Esta tabela deverá conter cinco
colunas.
Tabela 4.8: Parâmetros da tabela Distância

Coluna Descrição
src_id Identificador do ponto de inicio.
dest_id Identificador do ponto de destino.
cost Custo de viagem do ponto de início ao ponto de destino.
distance Distância do ponto de início ao ponto de destino.
traveltime Tempo final para atendimento do ponto.
service_ti Tempo de viagem do ponto de início ao ponto de destino.
me
4.2.2 Definição de janelas de tempo

Como mencionado anteriormente, as janelas de tempo são definidas tendo em conta o instante em
que os veículos deixam o depósito. Por exemplo, pode-se representar o tempo em minutos a partir
do instante em que os veículos deixam o depósito. O tempo de início pode ser considerado como
sendo 0. Deverá também ser definido o instante em que os veículos retornam ao depósito. Todos os
veículos são esperados a retornar até neste instante. As janelas de tempo dos pontos de atendimento
deverão estar entre os instantes da janela de tempo do depósito. Na definição de janelas de tempo, é
necessário converter os tempos definidos para minutos antes de executar o procedimento num
cenário real. Por exemplo, se a janela de tempo do depósito for 8:00h e 19:00h e o ponto de
atendimento precisa ser servidor entre 10:00h e 10:40h então, a janela de tempo para o depósito será
0 e 600 minutos respectivamente enquanto que a janela de tempo para o ponto de atendimento
estará entre 120 e 160 minutos, respectivamente.
4.2.3 Cálculo da matriz de distâncias

Há diversas maneiras para computar a matriz de distâncias. As funções apsp_johnson ou
apsp_warshall do pgRouting podem ser utilizadas, bem como a função para gerar matriz de
distâncias da ferramenta Open Source Routing Machine (OSRM).
Por questões de desempenho, foi utilizada a função para gerar a matriz de distâncias do OSRM.
4.2.4 Funcionamento
Uma vez definidas as tabelas, o problema de roteamento pode ser resolvido ao chamar a função
pgr_cvrpOneDepot com os seguintes parâmetros:
a) order_sql: texto contento uma query para gerar a tabela dos pontos;
b) vehicle_sql: texto que contém a query para gerar a tabela dos veículos;
c) cost_sql: texto que contém a query para gerar a tabela de custos;
d) depot_id: valor inteiro para informar qual dos pontos na tabela de pontos representa o
depósito.
Se as tabelas dos dados dos veículos, pontos e custos existirem na base de dados, então uma simples
consulta de selecção tendo as tabelas como parâmetros é suficiente para processar as rotas, por
exemplo:
select * from pgr_cvrpOneDepot(

‘select * from pontos’::text,
‘select * from
veiculos’::text,
‘select * from custos’::text,
1);
A Figura 4 .13 mostra o processo de obtenção das rotas.

Dados
Dados do Negócio:
Geográficos: vias
Veículos, Pontos,
de acesso, Depósito.
sentidos, etc
Grafo
Direccionado
Distância:
custos de viagem OSRM
entre os pontos
Algoritmo de
Roteamento
Rotas:
Sequência de
pontos a visitar
Figura 4.13: Processo de Roteamento.
4.2.5 Interpretação de resultados

O resultado da query executada irá retornar cinco colunas:
Tabela 4.9: Resultado do procedimento pgr_cvrpOneDepot
Coluna Descrição
vehicle_i O identificador do veículo para a rota corrente
d
order_id O identificador do ponto que será servido
order_po A sequência do ponto na rota corrente, por exemplo, se
s order_pos é 3, significa que o ponto será o 3 o a ser servido por
este veículo. O order_pos do depósito central (garagem de onde
partem os veículos) será ou 0 ou n+1 dependendo se o veículo
está a sair ou chegar ao depósito.
depart_ti Quando o veículo está a deixar o ponto. O tempo é dado em
me minutos com referência ao tempo de início do depósito.
arrival_ti Quando o veículo inicia servindo o ponto. É necessário ressaltar
me que mesmo que o veículo alcance o ponto antes do tempo de
inicio deste, só poderá servi-lo no tempo de inicio do ponto.
Exemplo:
Tabela 4.10: Resultados do procedimento pgr_cvrpOneDepot

order_id order_pos vehicle_id arrival_time depart_time
1 0 15 -1 0
63 1 15 52 62
68 2 15 70 80
72 3 15 93 103
36 4 15 139 149
38 5 15 152 162
1 6 15 202 -1
1 0 8 -1 0
24 1 8 65 75
27 2 8 137 147
1 3 8 205 -1
O resultado acima, representa o seguinte cenário: O veículo cujo identificador (id) é 15, começa do
depósito central no instante 0. O veículo alcança o primeiro ponto (id=63) 52 minutos após deixar o
depósito, e o deixa-o no instante 62. O segundo ponto (id=68) é alcançado no instante 70, e é
deixado no instante 80 e assim sucessivamente e finalmente retorna ao depósito no instante 202. O
outro veículo (id=8) também deixa o depósito no instante 0 e alcança o primeiro ponto (id=24) entre
os instantes 65 e 75, o segundo ponto (id =27) entre os instantes 137 e 147) e retorna ao depósito no
instante 205. No cenário acima, o período de atendimento foi definido para começar no instante 0 e
terminar no instante 240.
4.3 Requisitos de Negócio

 O utilizador deverá ser capaz de registar pontos de recolha através de uma interface com um
mapa digital;
 O utilizador deverá ser capaz de definir as janelas de tempo para cada ponto de recolha;
 O utilizador deverá ser capaz de registar os veículos;
 O utilizador deverá ser capaz de gerar as rotas e visualizá-las num mapa digital;
 O utilizador deverá ser capaz de exportar as rotas para um formato que possa ser impresso;
4.4 Concepção do Modelo

4.4.1 Domain model
O Domain Model é um diagrama que apresenta, essencialmente, as entidades do problema e as suas
relações excluindo os seus atributos. Este, auxilia na definição de alguns conceitos iniciais do
domínio do problema e as suas relações. O Domain Model é tipicamente captado no contacto com
utilizadores com experiência nas regras do negócio como intervenientes ou analistas.
A Figura 4 .14 mostra o Domain Model da Aplicação.
Figura 4.14: Domain Model da Aplicação
4.4.2 Protótipo da interface do utilizador

A interface de utilizador é a parte visível do software para o utilizador, através da qual, ele interage
de forma a executar as suas tarefas. Não importa o quão sofisticado são as suas funções internas,
não importa o quão compreensível são as suas estruturas de dados, não o quão bem desenhado está
a sua arquitectura, um desenho de interface pobre muitas vezes leva a percepção de que o software é
“mau” (Pressman, 2010).
Segundo Ambler (2004), o protótipo de interface do utilizador é uma técnica iteractiva de análise na
qual os utilizadores são envolvidos activamente no desenho das interfaces de utilizador do sistema.
Os protótipos de interface do utilizador tem diversas finalidades:
 Como um artefacto que permite explorar o domínio do problema com os stakeholders;
 Como um artefacto de requisitos para ter uma visão inicial do sistema;
 Como um artefacto de desenho que permite explorar o espaço de solução do sistema;
 Como um veículo para comunicar as possíveis interfaces de utilizador do sistema;
Ao desenvolver o protótipo das telas no início, é colocada uma face na aplicação, o que faz com que
as pessoas se sintam excitadas e motivadas a querer ter a aplicação construída. O desenvolvimento
do protótipo das telas do sistema é também uma forma de eliminar posteriores alterações (como tipo
de fonte, cores) e acordar uma aparência consistente que pode ser implementada.
A seguir, alguns protótipos de interface do utilizador.
Figura 4.15: Interface de Autenticação
Descrição: a interface de autenticação permite ao utilizador aceder as funcionalidades do sistema

mediante introdução de credenciais válidas:
 Nome de utilizador: nesse campo, o utilizador deverá introduzir o seu nome de utilizador;
 Palavra-passe: nesse campo, o utilizador deverá introduzir a palavra-passe referente ao nome
de utilizador previamente introduzido.
Figura 4.16: Interface de Registo de Novo Ponto de Recolha
Descrição: a interface do registo de novo ponto de recolha tem por objectivo permitir ao utilizador
introduzir dados referentes a um ponto de recolha:
 Identificador: código que identifica o ponto de recolha;
 Demanda: valor em m3 ou litros que especifica a demanda do ponto de recolha;
 Descrição: campo de texto para introdução de informação sobre o campo de recolha;
 Latitude/Longitude: campo para especificar as coordenadas geográficas do ponto de recolha,
tais coordenadas podem ser obtidas através de um mapa digital;
 Tipo de Resíduo: Nesse campo, o utilizador deverá seleccionar os tipos de resíduos a serem
recolhidos no ponto de recolha em causa.
Figura 4.17: Interface para Alocação dos Recursos para a Rota
Descrição: a interface para alocação dos recursos para a rota, permite ao utilizador, seleccionar um
conjunto de informações que serão necessárias para gerar uma rota:
 Período: nesse campo, o utilizador deverá introduzir a hora de início e de fim da rota;
 Veículo: nesse campo, o utilizador deverá seleccionar o veículo a alocar;
 Equipa: nesse campo, o utilizador deverá seleccionar os funcionários (motorista e
cantoneiros) alocados para a rota;
 Pontos de recolha: nesse campo, o utilizador, através de um mapa digital, poderá seleccionar
os campos alocados a rota, se preferir, poderá filtrar os pontos de recolha de uma
determinada categoria.
Figura 4.18: Interface de Visualização das Rotas
Descrição:
A interface de visualização de rotas fornece ao utilizador, informação sobre uma determinada rota,
apresentada num mapa digital. Nessa interface, é possível ver os pontos de recolha, os dados do
veículo, o número total de pontos a visitar, a distância total a percorrer (aproximadamente), o
combustível gasto e seu respectivo custo (aproximado) e o mapa digital com a rota gerada. Ainda
através dessa interface, o utilizador poderá exportar toda a informação presente para um outro
formato, como por exemplo: PDF.
4.4.3 Storyboard
Um Storyboard, também chamado de diagrama de fluxo de interface de utilizador, é essencial para
mostrar o mapa de navegação das diversas interfaces. A Figura 4 .19 mostrar o Storyboard da
aplicação. Como pode-se observar, após o utilizador autenticar-se no sistema, este pode aceder à
informação sobre as rotas, pontos de recolha, veículos e pessoal (recursos humanos).
Figura 4.19: Storyboard da Aplicação
4.4.4 User stories

Após ter os requisitos de negócio e os protótipos de interface do utilizador definidos, pode-se
definir agora um conjunto de User Stories para a aplicação. Segundo Hemrajani (2006), apesar do
User Story ter o mesmo propósito do Use Case, o User Story é menor que o Use Case. Por
exemplo, o User Story possui entre 1 a 3 frases para cada. Os User Stories descrevem os requisitos
de alto nível, os detalhes adicionais poderão ser discutidos entre o desenvolvedor e o cliente quando
o desenvolvedor começar a trabalhar num dado User Story na iteração planeada, daí, o termo
“participação activa dos stakeholders”.
Tabela 4.11: User Stories, Prioridades e Estimativas

# Story Name/ Descrição Priorida Pontos
Tag de (Estimati
va)
1 Criar Rota O utilizador poderá introduzir os 1 2
dados necessários para criação de
uma rota, validá-lo e salvá-lo.
2 Listar Rotas O utilizador poderá listar as rotas 1 2
existentes com a possibilidade de
seleccionar uma delas, ver seus
detalhes e altera-las.
3 Entrar O utilizador poderá entrar no 2 1
Sistema usando um nome e
palavra-passe válidos.
4 Sair O utilizador poderá sair do 2 1
Sistema encerrando a sua sessão.
5 Gerar Rota O utilizador poderá gerar uma 1 2
rota, devendo primeiramente,
alocar todos os recursos para tal.
6 Visualizar Após gerar a rota, o utilizador 1 1
Rota poderá visualizá-la num mapa
digital.
7 Imprimir Rota O utilizador poderá imprimir a 2 1
rota gerada.
8 Exportar Rota O utilizador poderá exportar a 2 1
rota gerada para PDF.
11
Os pontos mostrados na Tabela 4 .11 podem ser alguma unidade de medida relativa a ao projecto.
Por exemplo, 1 ponto pode significar 1 dia de trabalho (no caso do presente trabalho), 1 semana ou
qualquer outro período acordado entra o cliente e os desenvolvedores. Qualquer que seja a medida
de cada ponto, este é depois usado para fornecer estimativas ao cliente.
4.4.5 Diagrama de casos de uso
Figura 4.20: Diagrama de Casos de Uso
Tabela 4.12: Caso de Uso Criar Rota
ID: UC001 Descrição: Criar Plano

Actor Utilizador
Pré-condição O usuário deve ter iniciado a sua sessão (login).
Pós-condição A rota é criada.
Fluxo principal 1. O utilizador informa a data para a rota;
2. Informa a descrição da rota;
3. Regista a descrição.
Tabela 4.13: Caso de Uso Alocar Recursos
ID: UC001 Descrição: Alocar Recursos

Actor Utilizador
Pré-condição A rota deverá ter sido criada.
Pós-condição Os recursos referentes a uma dada rota (veículo, pessoal, pontos
de recolha) são alocados.
Fluxo principal 1. O utilizador aloca o veículo para a rota;
2. O utilizador aloca os pontos a serem visitados;
3. O utilizador aloca a equipa de recolha.
4. Os recursos ficam alocados.
Tabela 4.14: Caso de Uso Gerar Rota
ID: UC001 Descrição: Gerar Rota

Actor Processador de Rotas <<system>>
Pré-condição A rota deverá ter sido criada e os respectivos recursos alocados.
Pós-condição A rota é gerada e fica disponível para visualização.
Fluxo principal 1. O utilizador seleciona uma rota com os recursos alocados;
2. O utilizador seleciona a opção para gerar a rota;
3. O processador de rotas gera uma rota optimizada com
base nos recursos alocados;
4. A rota é gerada e apresentada ao utilizador em forma de
um mapa digital.
Tabela 4.15: Caso de Uso Visualizar Rota
ID: UC001 Descrição: Visualizar Rota

Actor Utilizador
Pré-condição A rota deverá ter sido gerada.
Pós-condição A rota fica disponível para visualização.
Fluxo principal 1. O utilizador busca pela rota que deseja visualizar;
2. O utilizador selecciona a rota que deseja visualizar;
3. A rota é apresentada ao utilizador num mapa digital.
4.5 Implementação do Modelo

Esta secção tem por objectivo, apresentar os artefactos desenvolvidos para a aplicação proposta no
presente trabalho. A seguir, apresentam-se os objectivos de desenho e arquitectura:
 Desenvolver um diagrama de arquitectura de forma livre;
 Explorar objectos utilizando CRC cards;
 Desenvolver o diagrama de classes;
 Apresentar a estrutura de directórios para a aplicação.
4.5.1 Diagrama de Arquitectura de Forma Livre

A Figura 4 .21 mostra a arquitectura de alto nível da aplicação.
Servidor Web:
Apache ou Nginx
Nav
Nav View / Templa Lea
ega
ega HTT Visão te
dor
dor P Django DTL /
flet
Web Dispatch HTML API
Model /
Modelo
Django
ORM
Psyc Servid
opg2 or OSM
PostgreSQL
Server
osrm PostGI
OS ORDB
- S
MS
RM tools (Postgr
pgRou
ting
eSQL
Figura 4.21: Arquitectura de Alto Nível da Aplicação
A arquitectura da aplicação é bastante simples. Esta segue o padrão da arquitectura de uma

aplicação web, isto é, possui 3 camadas, nomeadamente, a camada do cliente (web browser), a
camada intermédia (servidor da aplicação), e a camada de dados (Base de dados).
Para a camada da aplicação foi utilizado o padrão de desenho MVC (Model-View-Controller), no

caso do framework utilizado, a nomenclatura é MTV (Model-Template-View). A View (no caso do
MTV) ou Controller (no caso do MVC) é o ponto de entrada das requisições HTTP e controla o
Model e o Template (View no caso do MVC). O Model trata dos dados que são solicitados pela
View e passados para o Template para a renderizar de uma forma apresentável. Devido ao
framework utilizado, o Template será escrito com HTML e DTL (Django Template Language).
Na camada de aplicação, pode utilizar-se como servidor web tanto o Apache como Nginx em
ambientes de produção, no caso de ambiente de testes, poderá ser utilizado o servidor web embutido
no Django. As solicitações HTTP são tratadas pelas views no Django através do (Django Dispatch).
Quando as solicitações referem-se a páginas web que apresentem dados geográficos, é feita uma
solicitação a API do Leaflet, que permite apresentar dados geográficos em mapas digitais,
permitindo diversas configurações a nível de apresentação dos dados, como cor dos waypoints, cor
das linhas (referente as rotas), definir nível de zoom, dentre outras.
A conexão entre a aplicação web e a camada de dados é feita utilizando o psycopg2 que é o
adaptador para a conexão de aplicações desenvolvidas em Python e SGBD PostgreSQL.
Na camada de dados, o SGBD utilizado (PostgreSQL), utiliza 3 extensões, nomeadamente:

 PostGIS: para suporte a objectos geográficos na Base de Dados;
 pgRouting: para permitir executar algoritmos de roteamento sobre os dados geográficos
através de funções;
 osrm-tools: permite interagir com o OSRM através de funções.
4.5.2 CRC Cards

CRC significa Classe, Responsabilidades e Colaboração. A Tabela 4 .16 mostra o layout de um
simples CRC card com algumas explicações para os três componentes deste.
Tabela 4.16: Exemplo de um CRC card

Nome da Classe
Responsabilidades ( obrigações desta Colaboradores (outras classes necessárias
classe, tais como métodos, tratamento de para fornecer uma solução completa para um
excepções, atributos, etc.) requisito de alto nível)
Tabela 4.17: CRC card da Classe Alocação

Alocação
Representa os recursos para execução de Veículo
uma rota Pessoal
Guarda o pessoal alocado para a rota PontosDeRecolha
Guarda os pontos de recolha a serem
visitados
Guarda o veículo pertencente a rota em causa
Tabela 4.18: CRC card da Classe Plano

Plano
Possui data Alocação
Possui descrição
Guarda um grupo de rotas
4.5.3 Diagrama de classes
Figura 4.22: Diagrama de Classes
4.6 Avaliação da Aplicabilidade do Modelo Proposto

Os resultados do modelo proposto no presente trabalho, podem ser visualizados no protótipo
funcional desenvolvido, portanto, avaliando a aplicabilidade do deste, pode-se afirmar que este
apresenta diversas vantagens no processo de planeamento de rotas facilitando o processo de
planeamento tanto na introdução de dados como na interpretação dos resultados.
Podem-se destacar as seguintes vantagens:

 Informação de dados geográficos actualizada;
 Geração automática de rotas;
 Disponibilização de resultados através de mapas digitais;
 Maior disponibilização de dados (por ser web);
 Definição de Janelas de Tempo para cada pontos de recolha, o que permite ao algoritmo
priorizar determinados pontos ao gerar a rota;
 Simulação de custos de transporte na actividade de recolha de RSD, o que permite futuro
planeamento do orçamento;
 Dentre outras.
O modelo proposto, é aplicável não só para o foco desta monografia (Recolha e Transporte de
Resíduos Sólidos) mas também para outras áreas ligadas ao planeamento de rotas de veículos, como
por exemplo: transporte escolar, distribuição de mercadorias, etc.
A utilização de ferramentas open source constituem também uma vantagem na medida que estas
não acarretam custos de licença para a sua implementação e permitir customização das mesmas de
acordo com as necessidades impostas, diferentemente das comerciais, o que causaria dificuldades
de implementação devido aos custos associados a mesma.
Pelo facto de ser um sistema web, a mesma acarretará custos de infraestruturas, como alojamento do
sistema num servidor e acesso à Internet (caso esteja não esteja num servidor da rede local), no
entanto, pelo facto de inicialmente o sistema não precisar de muitos intervenientes para a sua
utilização, a médio prazo, poderá configurar-se um servidor web no computador de quem irá utilizar
o sistema, mas, recomenda-se colocar o sistema num servidor específico, por questões de
descentralização e pelo facto deste consumir recursos computacionais, podendo dificultar a
execução de outros softwares.
Um dos desafios da implementação do modelo proposto, é pelo facto da componente principal

(processo de roteamento) é totalmente dependente do SGBD PostgreSQL com a extensão
pgRouting, sendo assim, o mapeamento do presente modelo para outras ferramentas acarretaria um
novo estudo, visto que a principal funcionalidade da aplicação é executada ao nível da Base de
Dados e o trabalho foi desenvolvido tendo em conta as ferramentas utilizadas.
No capítulo a seguir apresentam-se as conclusões e recomendações do presente trabalho.

CAPÍTULO 5: CONCLUSÕES E RECOMENDAÇÕES
Neste capítulo, apresenta-se as conclusões e recomendações da presente pesquisa, mostrando se os

objectivos definidos foram alcançados.
5.1 Conclusões
O presente trabalho teve como objectivo o desenvolvimento de um sistema para planeamento de
rotas de RSD na cidade de Maputo, mais concretamente no Distrito Urbano de KaMpfumo. Este
sistema visa auxiliar o processo de planeamento de rotas, de modo a auxiliar na flexibilização da
actividade de recolha e transporte dos RSD e durante a pesquisa, foi possível constatar diversos
constrangimentos que dificultam a actividade de recolha e transporte de RSD.
Neste contexto, conclui-se que:
Quanto aos constrangimentos na actividade de recolha de RSD no Distrito Urbano de

KaMpfumo
No que concerne aos constrangimentos enfrentados pela equipa de recolha dos resíduos sólidos
domésticos, foi possível constatar que os mesmos devem-se aos seguintes aspectos:
 A grande dificuldade na recolha e transporte deve-se à forma como os RSD são depositados
nos contentores. Os munícipes não tem respeitado o período pré-estabelecido pelo Conselho
Municipal, o que faz com se acumule grande quantidade de lixo em volta dos contentores,
fazendo com que a equipa de recolha tenha de primeiro organizar o lixo, colocar no veículo
e depois proceder com a limpeza do ponto de recolha;
 O facto da deposição dos resíduos não ser diferenciada também dificulta o processo de
recolha, pois, há tipos de resíduos que não podem ser recolhidos por alguns tipos de
veículos, como é caso dos veículos compactadores. Estes não podem recolher resíduos como
por exemplo o ferro, pois pode danificar o veículo, portanto, o facto da deposição dos
resíduos ser indiferenciada quanto ao tipo de material, faz com que a equipa tenha de
primeiro seleccionar os resíduos para depois recolhê-los;
 Constatou-se também, que o encurtamento das rotas não é suficiente para minimizar os
custos de transporte, uma vez que, pelo que se observou na recolha de dados, grande parte
do tempo era gasto no acto de recolha e não na transição de um ponto para outro, portanto, a
demora na actividade de recolha e transporte, está mais ligada ao processo de recolha do que
ao processo do transporte.
Quanto às metodologias utilizadas na concepção e desenvolvimento do modelo

Sobre as metodologias utilizadas na concepção do modelo há que salientar o seguinte:
 O modelo proposto foi desenvolvido utilizando tecnologias web. Aparentemente, o facto do

sistema aparentar não ter intervenientes externos, faria com que o modelo fosse um software
Desktop, no entanto, pelas tecnologias utilizadas, a abordagem mais adequada foi a web,
que além de todas as suas vantagens a nível técnico, esta facilita na futura expansão do
sistema, fazendo com que facilmente, o sistema possa se tornar em algo maior e que terá
diversos intervenientes externos;
 Para a concepção e desenvolvimento do modelo proposto, as práticas XP/AMDD

mostraram-se bastante aplicáveis. O facto de utilizar as duas metodologias, ajudou muito no
processo de desenvolvimento, pois, enquanto a XP engloba todo o ciclo de vida, a AMDD
engloba o fase do desenho do modelo, guiando a práticas ágeis para a modelação do sistema,
portanto, pela experiência básica de desenvolvimento de software do candidato, constatou-se
que, a utilização de metodologias ágeis de desenvolvimento e modelação é bastante
importante quando se pretende perceber o domínio do problema que se pretende resolver,
uma vez que, de forma rápida, é possível produzir artefactos, e ir melhorando a cada iteração
com os stakeholders, permitindo assim, refinar cada vez mais os requisitos de forma a
chegar naquele que será o modelo ideal.
 O facto das metodologias ágeis não focarem muito na documentação também mostrou-se
bastante aplicável, uma vez que, o produto principal que se espera no final é o software e
não a documentação. A documentação é bastante importante para futuras actualizações do
sistema e para compreender a estrutura conceptual do software, no entanto, quando a
documentação é demais, pode tornar-se em algo difícil de gerir, tornando o processo de
gestão de requisitos bastante árduo, uma vez que a adição de novos requisitos implica na
actualização de toda a parte da documentação referente à aquele novo requisito, portanto, as

metodologias de desenvolvimento ágeis mostram-se bastante úteis uma vez que procuram
produzir apenas a documentação essencial para a fase do desenvolvimento.
Quanto às tecnologias utilizadas no desenvolvimento do modelo

Uma das diversas dificuldades que surgiram no processo de pesquisa, foi na investigação da
representação das redes de estradas numa base de dados, ou seja, de que forma é possível
representar vias de acesso, sentido das vias, pontos de recolha e tudo mais que tinha a ver com
informação geográfica, bem como, aplicar algoritmos de roteamento sobre esses dados geográficos.
Portanto, foi necessário estudar sobre Sistemas de Informação Geográfica e sua aplicabilidade nos
problemas de roteamento de veículos.
Para o desenvolvimento do modelo proposto foram utilizadas diversas tecnologias, sendo a maioria
open source:
 Para o caso do SGBD, foi utilizado o PostgreSQL que além de ser gratuito, open source,
etc., possui a extensão PostGIS que permite o armazenamento de dados espaciais na base de
dados, portanto devido a todas as suas vantagens e ligado ao facto de ser gratuito, este
SGBD mostrou-se adequado para o modelo proposto;
 Tendo escolhido o SGBD, outra dificuldade surgiu. Como obter os dados de toda cidade de
Maputo? Qual será a fonte dos dados espaciais? Portanto, houveram dificuldades no
tratamento de dados espaciais, uma vez que, a área das Ciências de Informação Geográfica
não era do domínio do candidato, no entanto, através das pesquisas, foi identificado o
OpenStreetMap que é um projecto aberto que fornece dados espaciais de todo o mundo e
permite a qualquer pessoa seleccionar a área que pretende e exportar para um formato que
depois possa importar; além disso, fornece também, serviços de mapas, permitindo assim
com que os desenvolvedores utilizem mapas digitais nas suas aplicações. Esta fonte de
dados espaciais mostrou-se bastante consistente, uma vez que é actualizada constantemente,
permitindo assim, para obter informação actualizada.
 A maior dificuldade foi, sem dúvida, a fase da implementação do componente de

roteamento de veículos sobre os dados espaciais. Uma vez que o SGBD e a informação
espacial já estava armazenada, surgiu então a dificuldade de aplicar os algoritmos de

roteamento de veículos sobre os dados espaciais. Para superar este constrangimento, foi
identificada a tecnologia pgRouting, que é uma extensão do PostgreSQL/PostGIS que
permite aplicar consultas de roteamento sobre dados espaciais, portanto, o roteamento era
feito a nível da base de dados e não a nível da aplicação. Esta abordagem é bastante
interessante, pois, uma vez que o roteamento é aplicado a nível do SGBD, facilmente pode-
se alterar tecnologias como linguagem de programação, frameworks, etc., e manter a
funcionalidade do roteamento geoespacial. No entanto, esta abordagem pode também trazer
uma desvantagem pelo facto do algoritmo ser integrado ao pgRouting, pois, a mudança do
SGBD PostgreSQL para um outro que suporte o armazenamento de dados espaciais
implicaria perder as funcionalidades de roteamento geoespacial visto que a extensão só foi
concebida para o PostgreSQL.
 Sobre as tecnologias a nível de aplicação, a utilização do Python como linguagem de

programação e Django como framework trouxe bastante flexibilidade no desenvolvimento,
pela sua sintaxe simples, documentação e quantidade de fóruns existentes, o que permitiu
diversas vezes, esclarecer pequenas dúvidas. Outra característica importante na utilização do
Python/Django é pelo facto de estas serem tecnologias de desenvolvimento de aplicações
simples e de forma rápida, mas também permitem a expansão das aplicações, construindo
assim sistemas robustos e seguros. Mas há que salientar que os desenvolvedores devem
também seguir as convenções e boas práticas propostas na documentação de modo a ter uma
aplicação fácil de manter e expandir.
Quanto ao uso do modelo proposto para a tomada de decisão

No que diz respeito ao uso do modelo proposto para apoio na tomada de decisão no que concerne ao
planeamento de rotas, considera-se que, apesar de ser uma tecnologia útil no sector de transportes, é
preciso considerar ainda diversos factores que contribuem para a tomada de decisão no que
concerne ao planeamento de rotas, como o comportamento dos munícipes no tratamento dos
resíduos sólidos, o papel de conselho municipal na gestão dos serviços de recolha e transporte,
dentre outros.
5.2 Recomendações
Com recurso aos resultados da presente pesquisa, recomenda-se:
Quanto aos constrangimentos na actividade de recolha e transporte de RSD na cidade de

Maputo
Das observações feitas no processo de recolha e transporte de RSD na cidade de área em estudo, foi
possível constatar diversas dificuldades anteriormente mencionadas, portanto, ao Conselho
Municipal da Cidade de Maputo, mais especificamente, à Direcção Municipal de Gestão de RSU e
Salubridade recomenda-se:
 Reforço nas campanhas de sensibilização aos Munícipes no que diz respeito ao tratamento
dos resíduos sólidos, de forma que estes respeitem os horários de deposição nos contentores
e depositem os resíduos de forma organizada, facilitando também o processo de recolha e
transporte;
 Introdução de novos mecanismos para deposição dos RSD, visto que a deposição feita em
contentores, muita das vezes, pela rápida degradação da matéria orgânica, dão mau aspecto a
cidade, diferentemente de algumas zonas da cidade, onde a recolha é feita porta à porta,
como é o caso das embaixadas;
 Introdução de deposição diferenciada de resíduos, de modo a ter os tipos de RSD separado

por partes, facilitando no processo de recolha e transporte.
 Utilização do modelo proposto, de forma a obter informação para auxilio na tomada de

decisão no concerne ao planeamento das rotas dos veículos.
Quanto às metodologias utilizadas na concepção e desenvolvimento do modelo

O desenvolvimento de um software não é algo estático, pelo contrário, é bastante dinâmico, pois, há
um conjunto de factores para que o software tenha de facto qualidade e seja útil às pessoas que irão
utilizá-lo. Portanto, o envolvimento dos utilizadores é sem dúvida um dos factores mais importantes
para que o software seja de facto útil. Desse modo, recomenda-se aos desenvolvedores, a utilização
de metodologias de desenvolvimento e modelação ágeis, não só porque permitem obter o produto
final de forma rápida, mas porque estas focam no contacto constante com os utilizadores, de forma
a refinar cada vez mais os requisitos, e no caso do XP, o facto do desenvolvimento ser incremental
facilita muito na actualização dos requisitos antes que os requisitos estejam implementados de tal
forma que dificulte a sua posterior actualização.
Quanto às tecnologias utilizadas no desenvolvimento do modelo

As tecnologias utilizadas no desenvolvimento do modelo proposto, mostraram-se bastante flexíveis
e úteis tanto no desenvolvimento como para a tomada de decisão, desse modo, devido às diversas
aplicações do PRV e do SIG, recomenda-se:
 O desenvolvimento de novos sistemas que possuam componentes geográficas para apoio na

tomada de decisão, como é o caso dos transportes públicos, transporte escolar, gestão de
desastres naturais, etc.;
 A expansão do modelo proposto, de modo que possa ser útil não só no planeamento de rotas,
mas também na gestão municipal, de modo que permita gestão de materiais recicláveis,
integração com tecnologias GPS para monitoria dos veículos, controlo de pontos que mais
produzem resíduos, dentre outros.
Quanto ao uso do modelo proposto para a tomada de decisão

Nas organizações, a introdução das tecnologias de informação pode levar resistência a mudança por
parte dos seus utilizadores, portanto, é preciso demonstrar as potencialidades das tecnologias de
informação junto aos agentes decisores. Desse modo, recomenda-se aos agentes decisores, a
utilização do modelo proposto, de forma a avaliar a aplicabilidade no sector de transporte e recolha
de resíduos sólidos.
 Ao Conselho Municipal:
o A implementação do modelo proposto, de modo a testar a aplicabilidade do sistema
na actividade de recolha e transporte de resíduos sólidos;
o Adopção do modelo proposto, não só no planeamento de rotas, mas também no
planeamento da alocação dos pontos de recolha, visto que estes possuem grande
impacto no processo de roteamento;
o Aquisição de dispositivos para medição do volume de lixo nos contentores.
 Aos futuros pesquisadores:

o Expansão do modelo proposto, de modo a permitir o planeamento de rotas, não
só para zonas urbanas, mas também nas suburbanas;
o Integração de sistemas de localização tempo real do posicionamento e do estado
do veículo, recorrendo a Sistemas de Posicionamento Global (GPS);
o Acréscimo de funcionalidades para obtenção de informação do tráfego em tempo
real;
o Possibilidade de, alterar, em tempo real uma rota, pelas mais variadas razões, e
de transmiti-la directamente ao veículo envolvido, por forma a que este possa
executá-la de imediato;
o Aplicação do modelo proposto em outras áreas, como transportes públicos e
privados.
BIBLIOGRAFIA
 Ambler, S. W. (2004). The Object Primer: Agile Model-Driven Development with UML
2.0, 3rd Edition. 572 pp., Cambridge University Press.
 Ambler, S. W. (2007). Agile Model Driven Development (AMDD): The Key to Scaling
Agile Software Development. [Em linha]. [Consult. 26 Outubro 2014]. Disponivel em:
http://www.agilemodeling.com/essays/amdd.htm
 Beck, K. e Andres, C. (2004). Extreme Programming Explained: Embrace Change, 2nd

Edition., Addison-Wesley.
 Beijoco, A. F. P. (2011). Optimização de um Sistema de Recolha e Transporte de Resíduos

Sólidos Urbanos: Implicações ambientais e financeiras da optimização da recolha e
transporte de resíduos sólidos urbanos no Barreiro. 112 pp. Dissertação de Mestrado
Universidade Técnica de Lisboa.
 Bilber, J. C. d. A. (2012). Gestão de Rotas na Recolha de Resíduos. Dissertação de

Mestrado. 82 pp. Universidade do Porto.
 Bittencourt, G. C. d. (2012). Modelagem e Implementação de um SIstema Computacional

para a Solução de um Problema de Roteamento de Veículos (PRV) com o Uso da
Metaheurística Busca Dispersa (Scatter Search). Trabalho de Conclusão de Curso. 50 pp.
Universidade Federal de Juíz de Fora.
 Black, W. R. (2003). Transportation: A Geographical Analysis, 1st Edition. 375 pp., The
Guilford Press.
 Christopher, M. (2007). Logística e Gerenciamento da Cadeia de Suprimentos: criando redes

que agregam valor, 2a Edição. 308 pp. São Paulo, THOMSON.
 CONSELHO MUNICIPAL DE MAPUTO (2008). Plano Director Gestão de Residuos

Sólidos Urbanos na Cidade de Maputo, Maputo.
 Costa, T. A. (2005). Metaheurísticas híbridas grasp-busca tabu aplicadas ao problema de

roteamento de veículos com janela de tempo. Dissertação de Mestrado. Belo Horizonte.
Centro Federal de Educação Tecnológica de Minas Gerais.
 Dantzig, G. B. e Ramster, J. H. (1959). The Truck Dispatching Problem. Managment

Science. VI, pp.80-91.
 Daskin, M. S. (1985). Logistics: an overview of the state of the art and perspectives on
future research. Transportation Research. 19A, pp.383-98.
 Davide, P. M. M. (2012). Sistema de Gestão Para a Recolha de Material Reciclável.

Dissertação de Mestrado. 111 pp. Universidade Nova de Lisboa.
 Elmasri, R. e Navathe, S. B. (2011). Fundamentals of Database Systems, 6th Edition. 1172

pp. Boston, Addison-Wesley.
 ESRI. (2009). GIS in Africa. [Em linha]. United States of America. [Consult. 6 Setembro
2014]. Disponivel em: http://www.esri.com/~/media/Files/Pdfs/library/bestpractices/gis-in-
africa.pdf
 ESRI. (2013). GIS in Africa 2. [Em linha]. United States of America. [Consult. 6 Setembro
2014]. Disponivel em: http://www.esri.com/~/media/Files/Pdfs/library/ebooks/gis-in-africa-
2.pdf
 Goldbarg, M. C. e Luna, H. P. L. (2005). Otimização Combinatória e Programação Linear,

2a Edição. 536 pp. Rio de Janeiro, Editora Campus.
 Hemrajani, A. (2006). Agile Java Development with Spring, Hibernate and Eclipse, 360 pp.,
Sams.
 Heywood, I., Cornelius, S. e Steve, C. (2006). An Introduction to Geographical Information
Systems, 3rd Edition. 426 pp. Harlow, Pearson Education Ltd.
 Lenstra, J. K. e Rinooy Kan, A. H. G. (1981). Complexity of vehicle routing and scheduling

problems. Networks. 11, pp.221-227.
 Maguire, D. J. (1991). An Overview and definition of GIS. In: Maguire, D. J., Goodchild,
M. F. e Rhind, D. W., (editores). Geographical information systems: Principles and
applications. First Edition. pp 9-19. London, Wiley.
 Marconi, M. d. A. e Lakatos, E. M. (2003). Fundamentos de Metodologia Científica, 5a

Edição. São Paulo, Editora Atlas.
 Miller, H. J. e Shaw, S. L. (2001). Geographic Information Systems for Transportation, 480

pp. New York, Oxford University Press, Inc.
 Muianga, H. M. C. (2006). Desenvolvimento de Sistema de Informação Geográfico baseado

na WEB para Suporte à Tomada de Decisão no Sector da Saúde. Caso de Estudo:
Distribuição de Recursos no Sector de Saúde em Moçambique. Trabalho de Licenciatura.
115 pp. Maputo. Universidade Eduardo Mondlane.
 Oliveira, M. J. d. S. (2008). Optimização de Circuítos de Recolha de Lixos Domésticos em

Zonas Urbanas. PhD Thesis. Porto. Universidade do Porto.
 Pressman, R. S. (2010). Software Engineering: A Practitioner's Approach, 7th Edition.,

McGraw-Hill.
 Priya, M. (2014). GitHub. [Em linha]. [Consult. 19 Novembro 2014]. Disponivel em:
https://github.com/pgRouting/pgrouting/wiki/How-to-use-guide
APÊNDICES
61
APÊNDICE A – GUIÃO DE ENTREVISTA
Universidade Eduardo Mondlane

Faculdade de Ciências
Departamento de Matemática e Informática
Entrevistador: Paulo Jorge Braga Zacarias
Sobre a Gestão de Resíduos Sólidos Urbanos na cidade de Maputo

 Como ocorre todo o processo de gestão de Resíduos Sólidos Urbanos na cidade Maputo?
 Qual o destino dos Resíduos Sólidos Urbanos?
Sobre a Gestão de Resíduos Sólidos Domésticos
 Qual a frequência de recolha dos RSD?
 Qual o horário pré-estabelecido para a deposição dos resíduos nos contentores?
Sobre os pontos de recolha
 Quantos contentores são alocados por ponto de recolha?
 Como são identificados os contentores?
 Quais as capacidades dos contentores?
 Como são armazenadas as informações referentes aos contentores? Este são
georreferenciados?
Sobre os veículos
 Quantos veículos são utilizados para a recolha de Resíduos Sólidos Domésticos?
 Quais as capacidades dos veículos?
 Os veículos possuem GPS?
Sobre o transporte dos Resíduos Sólidos Domésticos
 É imperioso respeitar os sentidos das vias quando a recolha é feita de noite?
Sobre o planeamento de rotas dos veículos
 Como é feito o planeamento de rotas dos veículos, é utilizado algum software?
 No caso de surgimento de novos pontos de recolha e/ou disponibilização de novos veículos,
como é feita a redistribuição das rotas?
APÊNDICE B – Fotos da Recolha de RSU na Cidade de Maputo
APÊNDICE C – Tempos de Recolha Registados
Abaixo os tempos registados na rota seguida no dia 02/11/2014:
Pontos Tempo de Ponto a Tempo de Viagem Nr. de Capacida

Recolha Seguir para o Ponto a contento de
(hh:mm:s Seguir res
s)
deposi 1o 00:07:36
to
1o 00:03:20 2o 00:02:12 2 1,1m3
2o 00:02:57 3o 00:01:39 2 1,1m3
3o 00:03:29 4o 00:01:10 3 1,1m3
4o 00:06:07 5o 00:01:19 3 1,1m3
5o 00:10:37 6o 00:01:40 5 1,1m3
6o 00:05:12 7o 00:04:21 4 1,1m3
7o 00:05:38 8o 00:02:15 1 1,1m3
8o 00:07:44 9o 00:01:23 4 1,1m3
9o 00:07:35 10o 00:02:35 4 1,1m3
10o 00:14:54 11o 00:01:25 4 1,1m3
11o 00:04:00 12o 00:06:41 2 1,1m3
12o 00:02:56 13o 00:00:31 2 1,1m3
13o 00:05:28 14o 00:02:04 2 1,1m3
14o 00:04:56 15o 00:02:18 5 1,1m3
15o 00:08:56 16o 00:00:25 3 1,1m3
16o 00:01:53 17o 00:00:43 2 1,1m3
17o 00:06:02 18o 00:01:10 3 1,1m3
18o 00:09:08 19o 00:01:26 5 1,1m3
19o 00:06:40 20o 00:02:15 4 1,1m3
20o 00:07:40 21o 00:01:07 4 1,1m3
21o 00:03:12 22o 00:02:36 2 1,1m3
22o 00:20:09 23o 00:07:23 6 1,1m3
23o 00:06:12 24o 00:01:06 4 1,1m3
24o 00:14:53 Hulene 01:02:27 5 1,1m3
Hulene 00:21:01 25o 00:19:55
25o 00:11:58 26o 00:03:01 6 1,1m3
26o 00:25:28 27o 00:01:23 1 1,1m3
27o 00:30:32 28o 00:00:18 6 1,1m3
APÊNDICE D – MANUAL DO SISTEMA
MANUAL DO SISTEMA
Introdução
O presente manual tem por objectivo ser um guia na utilização do software desenvolvido. Este
documento é especialmente designado aos não especialistas. Ao ler este guia, irá aprender como
utilizar a aplicação através dos elementos da interface gráfica do utilizador.
Ambiente Suportado
Requisitos Mínimos de Hardware do Servidor

 Hard Disk: 20GB;
 RAM: 2GB;
 Processador: Unidade frequência >1.6Ghz.
Requisitos de Software da Máquina Servidor

 Interpretador da Linguagem de Programação Python versão 2.7;
 Instalação do Django versão 1.7;
 Servidor Web:
o Ambiente de Testes: pode-se usar o servidor web embutido no Django;
o Ambiente de Produção: pode-se usar o Apache ou Nginx.
 Sistema de Gestão de Base de Dados: PostgreSQL 9.3.5 + PostGIS + pgRouting;
 Sistema Operativo: Windows, Linux, Mac OS X.
Requisitos de Software da Máquina Cliente

 Sistema Operativo: Qualquer;
 Browser: Internet Explorer 8+, Google Chrome, Safari. Nota: O JavaScript deverá estar
habilitado no browser utilizado.
MANUAL DE INSTALAÇÃO
O software desenvolvido é web, sendo assim, este precisa ser instalado numa máquina denominada
“servidor”, portanto, na máquina “servidor” será necessário instalar os componentes de modo que
cumpram com os requisitos de instalação do software desenvolvido.
Para o presente manual, será considerado o Sistema Operativo Linux e Distribuição Ubuntu como
sendo o Sistema Operativo da máquina servidor, no entanto, pode-se usar outros Sistemas
Operativos como Windows e MAC OS X.
Conteúdo do CD disponibilizado:
 Base de Dados do software;
 Projecto Django.
INSTALAÇÃO
 Instalação do PostgreSQL, PostGIS e pgRouting

# Add pgRouting launchpad repository
sudo apt-add-repository -y ppa:ubuntugis/ppa
sudo apt-add-repository -y ppa:georepublic/pgrouting
sudo apt-get update
# Install pgRouting package (for Ubuntu 14.04)

sudo apt-get install postgresql-9.3-pgrouting
 apt-get install postgresql-9.3-postgis-scripts
 Instalação do OSRM:
o Ubuntu 14.04+:
https://github.com/Project-OSRM/osrm-backend/wiki/Building-on-Ubuntu
o Para outros Sistemas Operativos:
https://github.com/Project-OSRM/osrm-backend/wiki/Building-OSRM
 Instalação do Python 2.7.6:
o O Ubuntu 14.04+ já traz o compilador e interpretador da Linguagem de Programação
Python, no entanto, no caso de estiver em outro Sistema Operativo, poder-se-á
descarregar o Python em https://www.python.org/downloads/
 Instalação do Django 1.7
o https://docs.djangoproject.com/en/1.7/topics/install/
MANUAL DO UTILIZADOR
Poderá aceder ao sistema utilizando as seguintes credenciais:

 Nome do Utilizador: admin
 Palavra-passe: admin
Interface: Autenticação
Objectivo: Aceder ao Sistema
Dados Necessários (previamente registados):
 Nome do Utilizador: Conjunto de caracteres alfanuméricos sem espaço;
 Palavra-passe: Conjunto de caracteres alfanuméricos e símbolos especiais.
Funcionalidades Extras: Recuperar a Palavra-passe.
Interface: Início
Objectivo: Fornecer visão geral do sistema mostrando as opções necessárias para acesso às
funcionalidades.
Funcionalidades:
 Visualizar um mapa digital da cidade de Maputo;
 Aceder à opção da Gestão de Pontos de Recolha;
 Aceder à opção da Gestão de Veículos;
 Aceder à opção de Gestão das Rotas;
 Aceder à opção de Gestão dos Funcionários.
Paulo Zacarias: indica o nome do utilizador autenticado;

Menu: Oferece opções para alterar a palavra-passe e
visualizar o perfil;
Sair: Permite encerrar a sessão no sistema.
Menu com opções para aceder a diferentes diferentes

funcionalidades do Sistema:
Pontos de Recolha: criar, editar, visualizar e listar
Veículos: criar, editar, visualizar e listar
Rotas: Listar, visualizar, editar, gerar
Funcionários: criar, editar, visualizar, listar
Gestão de Veículos
Interface: Registo de Veículo

Objectivo: Guardar dados sobre o veículo na base de dados
Dados Necessários:
 Tipo de Veículo: os dados referentes ao tipo de veículo são previamente registados,
portanto, este campo apresenta os tipos já existentes no sistema;
 Matrícula: deve indicar a matrícula do veículo que se pretende registar respeitando a
mascara colocada;
 Emissão CO2: deve indicar a emissão de CO2 do Veículo em causa podendo depois fazer
estimativas de emissão/distância;
 Custo/km: refere-se ao custo de combustível por km;
 Disponibilidade: Refere-se ao estado do veículo em termos de disponibilidade para gerar a
rota.
Interface: Listagem de Veículos

Objectivo: Visualizar os dados dos veículos
Campos de saída:
 Tipo de Veículo: os dados referentes ao tipo de veículo são previamente registados,
portanto, este campo apresenta os tipos já existentes no sistema;
 Capacidade: a capacidade de recolha do veículo em m3.
 Matrícula: indica a matrícula do veículo;
 Emissão CO2: indica a emissão de CO2 do Veículo em causa;
 Custo/km: refere-se ao custo de combustível do veículo por hora.
GESTÃO DE PONTOS DE RECOLHA
Interface: Detalhes de um ponto de recolha

Objectivo: Visualizar os dados de um ponto de recolha
Campos de saída:
 Cod: indentificador do ponto de recolha;
 Demanda: A demanda esperada .
 Tipo de Resíduo: indica os tipos de resíduos (quanto a composição) a serem recolhidos no
ponto em causa;
 Forma de recolha: indica a forma de recolha no ponto em causa, podendo ser em contentores
ou em sacos plásticos;
Gestão de Rotas
Interface: Visualização da Rota

Objectivo: Mostrar a sequência de pontos a visitar

Tese Paulo PDF

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

Tese Paulo PDF

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE EDUARDO MONDLANE

AUTOR: Paulo Jorge Braga Zacarias

AUTOR: Paulo Jorge Braga Zacarias

Dedico o presente trabalho à minha família.

Paulo J. B. Zacarias Trabalho de Licenciatura I

Agradeço ao Conselho Municipal da Cidade de Maputo (CMCM) e a ECOLIFE, pelo acolhimento

Maputo, Novembro de 2014

(Paulo Jorge Braga Zacarias)

Palavras-chave: Roteamento de Veículos, Resíduos Sólidos, Logística.

DECLARAÇÃO DE HONRA III

ÍNDICE DE FIGURAS VIII

LISTA DE ABREVIATURAS E ACRÓNIMOS X

1.1 Definição do Problema 3

2.1 Metodologia de Pesquisa 6

CAPÍTULO 3: REVISÃO DA LITERATURA 15

3.1 Roteamento de Veículos 15

CAPÍTULO 4: ÁREA DE ESTUDO E MODELO PROPOSTO 27

4.1 Distrito Municipal de KaMpfumo 27

CAPÍTULO 5: CONCLUSÕES E RECOMENDAÇÕES 52

Tabela 3.1: Classificação de PRV......................................................................................................18

LISTA DE ABREVIATURAS E ACRÓNIMOS

AJAX Asynchronous JavaScript and XML

Framework: em desenvolvimento de software, é uma abstracção na qual um software que fornece

Hardware: parte física do computador.

Software: parte lógica do computador (análoga ao hardware) que compreende o conjunto de

Os transportes tem como objectivo superar as distâncias dentro de um território e responder às

Necessário estudar o território, conhecer os seus constrangimentos de forma a construir cenários

1.1 Definição do Problema

Na actividade de recolha de resíduos sólidos, a optimização de rotas não só beneficia às

O aumento descomedido da densidade populacional em zonas urbanas tem como consequência

No Distrito Urbano de KaMpfumo, os RSD são depositados diariamente em contentores, e para a

Neste âmbito, surge a necessidade de implementar tecnologias que auxiliem no processo de

1.2.2 Objectivos Específicos

1.3 Estrutura do Relatório

2.1 Metodologia de Pesquisa

2.1.2 Técnicas de colheita de dados

A primeira entrevista foi realizada no dia 25 de Agosto de 2014 no Conselho Municipal da

transporte, os serviços de recolha existentes, a quantidade de veículos bem como as suas

A segunda entrevista foi realizada no dia 28 de Agosto de 2014 na empresa ECOLIFE

A informação recolhida foi a seguinte:

cumprimento do turno, no horário pré-estabelecido pelo Conselho Municipal; o facto de a

Para avaliar a aplicabilidade do Modelo com base em Protótipo operacional, analisando as

2.2 Desenvolvimento do Protótipo

Para o desenvolvimento da solução proposta no presente trabalho a metodologia adoptada baseou-se

2.2.2 Fonte de dados espaciais

b) Sistema de Gestão de Base de Dados (SGBD)

Devido às necessidades do processamento de dados geográficos e dados geométricos no

A finalidade do pgRouting é calcular o caminho a seguir desde um ponto do mapa (definido

c) Sistema de controlo de versões

f) Outras ferramentas utilizadas

 Git: sistema de controlo de versões distribuído, utilizado para a gestão de configurações

CAPÍTULO 3: REVISÃO DA LITERATURA

3.1 Roteamento de Veículos

Mercado de actuação Número de rotas

Figura 3.2: Decisões estratégicas, tácticas e operacionais para o PRV.

Segundo Goldbarg e Luna (2005, p.375), “O PRV aborda basicamente a determinação de

Figura 3.3: Cenário inicial de um PRV. Figura 3.4: Solução de um PRV.

3.1.1 Extensões do PRV

realizada em pontos específicos), o problema de cobertura de arcos (quando a colecta é realizada em

Tabela 3.1: Classificação de PRV

3.1.4 Complexidade computacional e formas de resolução

Figura 3.5: Crescimento da função f (n) com o aumento da entrada n.

Fonte: [ CITATION Bil12 \l 1033 ].