TCC OCORRÊNCIAS EMERGÊNCIAIS Desenvolvimento de aplicativo para solicitação de serviço emergencial da Policia Militar da cidade de são paulo

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP 
 
 
 
GIULIANO RIBEIRO – RA: A13744-0 
RODRIGO DE FREITAS – RA: A31AEC-6 
OSWALDO CORREA FILHO – RA: A15EHF-0 
THIAGO LIMA – RA: A16807-9 
WESLEY GOMES LOPES – RA: 461813-0 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
OCORRÊNCIAS EMERGÊNCIAIS: Desenvolvimento de aplicativo para 
solicitação de serviço emergencial da Policia Militar da cidade de São Paulo. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SÃO PAULO 
2012 
 
 
UNIVERSIDADE PAULISTA – UNIP 
 
 
 
GIULIANO RIBEIRO – RA: A13744-0 
RODRIGO DE FREITAS – RA: A31AEC-6 
OSWALDO CORREA FILHO – RA: A15EHF-0 
THIAGO LIMA – RA: A16807-9 
WESLEY GOMES LOPES – RA: 461813-0 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
OCORRÊNCIAS EMERGÊNCIAIS: Desenvolvimento de aplicativo para 
solicitação de serviço emergencial da Policia Militar da cidade de São Paulo. 
 
 
 
 
Trabalho de conclusão de curso para 
obtenção do título de Graduação em 
Sistemas de Informação apresentado à 
Universidade Paulista – UNIP. 
 
Orientador: Prof.º José André Caruso Neto 
 
 
 
 
 
 
 
 
 
 
 
 
SÃO PAULO 
2012 
 
 
UNIVERSIDADE PAULISTA – UNIP 
 
 
 
GIULIANO RIBEIRO – RA: A13744-0 
RODRIGO DE FREITAS – RA: A31AEC-6 
OSWALDO CORREA FILHO – RA: A15EHF-0 
THIAGO LIMA – RA: A16807-9 
WESLEY GOMES LOPES – RA: 461813-0 
 
 
 
 
 
 
 
 
 
 
OCORRÊNCIAS EMERGÊNCIAIS: Desenvolvimento de aplicativo para 
solicitação de serviço emergencial da Policia Militar da cidade de São Paulo. 
 
 
 
 
Trabalho de conclusão de curso para 
obtenção do título de Graduação em 
Sistemas de Informação apresentado à 
Universidade Paulista – UNIP. 
 
Orientador: Prof.º José André Caruso Neto 
 
 
Aprovado em: 
BANCA EXAMINADORA 
 
_____________________________ ____/____/_____ 
UNIVERSIDADE PAULISTA – UNIP 
 
_____________________________ ____/____/_____ 
UNIVERSIDADE PAULISTA – UNIP 
 
_____________________________ ____/____/_____ 
UNIVERSIDADE PAULISTA – UNIP 
 
 
DEDICATÓRIA 
 
 
"Aos meus pais José Luiz e Jane pelos ensinamentos e estrutura familiar que 
formaram e formam meu caráter, pelos incentivos, preocupações e alegrias a cada 
semestre concluído. À minha namorada Thábata pela presença constante, 
cobranças e auxílio em diversas atividades acadêmicas e por tornar meus dias mais 
felizes. Aos meus professores e colegas por terem tornado as aulas divertidas e pelo 
ambiente de aprendizado. Agradeço a todos, pois sei que nada seria sem vocês. 
Muito obrigado!" 
Giuliano Ribeiro 
 
“Dedico este trabalho primeiramente a, minha mulher Josiane, por confiar em 
mim e proporcionar esta oportunidade de concretizar e encerrar mais uma 
caminhada da minha vida. Além deste trabalho, dedico todo meu amor a você. Aos 
meus amigos, que apoiaram e que sempre estiveram ao meu lado durante esta 
longa caminhada, em especial ao meu amigo Charles (Amigo-irmão), que muitas 
vezes compartilhei momentos de tristeza, alegrias, angustias e ansiedade, mas que 
sempre esteve ao meu lado me apoiando e me ajudando. Aos meus amigos dedico 
este trabalho e todo meu carinho.” 
Rodrigo de Freitas 
 
"Agradeço em primeiro lugar a Deus que iluminou o meu caminho durante 
esta caminhada. Agradeço também aos meus amigos e colegas que me 
acompanharam durante a faculdade, e ajudaram a crescer profissionalmente. E não 
deixando de agradecer de forma grata e grandiosa aos meus pais, Oswaldo e Rose, 
a quem eu rogo todas as noites a minha existência e meus irmãos Vinício, Virginia e 
Sophia que sempre me acompanharam nesta vida.” 
Oswaldo Correa Filho 
 
 
 
“Agradeço em primeiro lugar a Deus que iluminou o meu caminho durante 
esta caminhada. Aos meus pais, irmãos e a toda minha família que, com muito 
carinho e apoio, não mediram esforços para que eu chegasse até esta etapa de 
minha vida. A todos os professores do curso, que foram tão importantes na minha 
vida acadêmica e no desenvolvimento desta monografia. Aos amigos e colegas, pelo 
incentivo e pelo apoio constantes.” 
Thiago Lima 
 
“Dedico esta monografia à minha família! Minha namorada Tatiana que 
praticamente cursou a faculdade comigo, me apoiando, incentivando e ajudando nos 
momentos em que mais precisei. A meus filhos, Kadu e Julia, pelos sorrisos e 
compreensão com minha grande ausência devido ao curso e por saber que sempre 
terei com quem contar.” 
Wesley Lopes 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
AGRADECIMENTOS 
 
 
Agradecemos a Deus, por ser à base de nossas conquistas. 
A todos os familiares, pelo apoio incondicional e por acreditarem em nossas 
escolhas, apoiando para que supríssemos todas elas ao longo de todo o curso. 
Ao orientador, com o apoio que foi fundamental para o sucesso deste 
trabalho. 
Ao coordenador do curso de Sistemas de Informação, André Mattos, pelo 
apoio e incentivo na conclusão do trabalho. 
As empresas onde trabalhamos, cuja experiência adquirida e o tempo 
disponibilizado por elas nos foi de alto valor na conclusão do curso. 
Aos amigos e colegas, cujas personalidades, ações e opiniões ajudaram no 
desenvolvimento do trabalho. 
Aos professores do Curso de Sistema de Informação, pela dedicação em 
suas orientações prestadas na elaboração deste trabalho, nos incentivando e 
colaborando no desenvolvimento de nossas ideias. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
“Aprender no sentido real da palavra é possível 
apenas nesse estado de atenção, em que não existe 
compulsão externa ou interna. O pensar correto 
pode surgir apenas quando a mente não está 
escravizada pela tradição e memória. É a atenção 
que permite que o silêncio chegue à mente, que é a 
abertura da porta para a criação. Por isso a atenção 
é da maior importância. O conhecimento é 
necessário no nível funcional como um meio de 
cultivar a mente, e não como um fim em si mesmo”. 
 
 (Jiddu Krishnamurti) 
 
 
RESUMO 
 
 
Desde a invenção da roda, o homem busca desenvolver recursos para 
facilitar as suas tarefas diárias, e a tecnologia está cada vez mais presente para 
cumprir este papel. Os sistemas digitais se tornaram condicionantes de conforto e 
praticidade, e novos produtos e serviços passaram a ser exigidos, como aparelhos 
com múltiplas funcionalidades, cada vez mais rápidos, menores e com melhor 
comunicação. É diante desta constatação que este projeto busca desenvolver um 
aplicativo voltado para smartphones, inicialmente com o sistema operacional 
Android, no qual o usuário poderá solicitar socorro aos serviços públicos 
emergenciais da Polícia Militar. Esta solicitação será atendida após o recebimento 
em um sistema de gerenciamento dos chamados, que associa o cadastro de cada 
usuário com a solicitação recebida. Logo após o recebimento desta mensagem, a 
central fará o cálculo da distância para que a ocorrência seja atendida pela viatura 
disponível mais próxima. Os pontos fortes deste trabalho é a qualidade da 
informação gerada, a inibição de chamadas indevidas (conhecidas como trotes) e a 
indicação da unidade mais próxima da ocorrência. Este sistema será baseado na 
linguagem de programação orientada a objetos, Java. 
 
PALAVRAS-CHAVE: Polícia, ocorrências emergenciais, tecnologia, sistemas, 
linguagem de programação, Java, banco de dados, aplicativo, segurança. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ABSTRACT 
 
 
Since the invention of wheel, man tries to develop resources to facilitate theirdaily tasks, and technology is increasingly present to fulfill this role. Digital systems 
have become conditional of comfort and practicality, and new products and services 
are now required, as devices with multiple functionalities, faster, smaller and with 
better communication. Given this fact, this project must develop an application aimed 
at smartphones, initially with the Android operating system, in which the user can 
request emergency assistance to public services of the Military Police. This request 
will be attended after the receipt in a management system of callings, which 
combines the registration of each user with the incoming request. Shortly after 
receiving this message, the center will calculate the distance to that occurrence is 
answered by the nearest available vehicle. The strengths of this work is the quality of 
generated information, the inhibition of improper calls (known as “trote”) and the 
indication of the occurrence nearest unit. This system will be based on the language 
of object-oriented programming, Java. 
 
KEYWORDS: police, occurrences emergency, technology, systems, 
programming language, Java, database, application, security. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
LISTA DE FIGURAS 
 
 
Figura 1.1 ………………………………………………………………………… 37 
Figura 1.2 ………………………………………………………………………… 43 
Figura 1.3 ………………………………………………………………………… 44 
Figura 1.4 ………………………………………………………………………… 45 
Figura 1.5 ………………………………………………………………………… 46 
Figura 1.6 ………………………………………………………………………… 47 
Figura 1.7 ………………………………………………………………………… 48 
Figura 1.8 ………………………………………………………………………… 49 
Figura 1.9 ………………………………………………………………………… 50 
Figura 2.0 ………………………………………………………………………… 52 
Figura 2.1 ………………………………………………………………………… 53 
Figura 2.2 ………………………………………………………………………… 54 
Figura 2.3 ………………………………………………………………………… 54 
Figura 2.4 ………………………………………………………………………… 55 
Figura 2.5 ………………………………………………………………………… 55 
Figura 2.6 ………………………………………………………………………… 56 
Figura 2.7 ………………………………………………………………………… 56 
Figura 2.8 ………………………………………………………………………… 57 
 
 
 
 
 
 
 
 
 
LISTA DE TABELAS 
 
 
Tabela 1.1………….…………………………………………………………… 38 
Tabela 1.2………….…………………………………………………………… 39 
Tabela 1.3………….…………………………………………………………… 40 
Tabela 1.4………….…………………………………………………………… 41 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
LISTA DE ABREVIATURAS E SIGLAS 
 
 
GPS - Sistema global de posicionamento 
UML – Linguagem de modelagem unificada 
OMT – Object modeling technique 
OOSE – Object oriented software engineering 
OMG – Grupo de gerenciamento de objetos 
IDE – Ambiente integrado para desenvolvimento de software 
IBM – Internatinal Business machines 
SWT – Standard widget toolkit 
DBA – Doctor of business administration 
SGBD – Sistema de gerenciamento de banco de dados 
SQL – Linguagem de consulta estruturada 
PHP – Personal Home Page 
DGPS – Differential global positioning system 
RF – Requisitos funcionais 
RNF – Requisitos não funcionais 
ANSI – Instituto nacional americano de padrões 
SAMU - Serviço de Atendimento Móvel de Urgência 
 
 
 
 
 
 
 
 
 
 
SUMÁRIO 
 
 
1. INTRODUÇÃO ............................................................................................... 13 
1.1. Objetivo .......................................................................................................................................... 14 
1.2. Objetivos específicos ................................................................................................................. 14 
1.3. Motivações .................................................................................................................................... 15 
1.4. Estrutura do Trabalho .............................................................................................................. 16 
2. BASE TEÓRICA ............................................................................................. 17 
2.1. Linguagem de Modelagem Unificada .................................................................................. 17 
2.1.1. Introdução à UML ............................................................................................................................ 17 
2.1.2. Histórico .............................................................................................................................................. 17 
2.1.3. Arquitetura ........................................................................................................................................ 18 
2.1.4. Um modelo conceitual da UML .................................................................................................. 19 
2.1.5. O ciclo de vida do desenvolvimento do software ............................................................... 20 
2.1.6. Diagramas – UML ............................................................................................................................ 22 
2.1.7. Síntese Geral dos Diagramas ...................................................................................................... 22 
2.1.7.1. Diagramas de Classes .................................................................................................................................. 23 
2.1.7.2. Diagramas de Caso de Uso ........................................................................................................................ 23 
2.1.7.3. Diagramas de Estado ................................................................................................................................... 23 
2.1.7.4. Diagramas de Atividades ........................................................................................................................... 24 
2.1.7.5. Diagramas de Sequência ............................................................................................................................ 24 
2.2. Linguagem Orientada a Objetos ............................................................................................ 25 
2.2.1. Lógica de Programação ................................................................................................................. 25 
2.2.2. Linguagem de Programação ....................................................................................................... 25 
2.2.3. Orientação a Objetos ...................................................................................................................... 26 
2.2.4. Vantagens da Orientação a Objetos ......................................................................................... 27 
2.2.5. Eclipse .................................................................................................................................................. 27 
2.2.6. Linguagem de Programação – Java .......................................................................................... 28 
2.2.7. Android ................................................................................................................................................ 28 
2.3. Banco de Dados ........................................................................................................................... 29 
2.3.1. Introdução à Banco de Dados ..................................................................................................... 29 
2.3.2. SQLite ................................................................................................................................................... 30 
2.3.3. Características do SQLite .............................................................................................................31 
2.4. GPS (Sistema de Posicionamento Global) .......................................................................... 31 
3. PROJETO PARA SISTEMAS ......................................................................... 33 
3.1. Análise do sistema ..................................................................................................................... 33 
3.1.1. Levantamento de Requisitos ...................................................................................................... 34 
3.1.1.1. Requisitos funcionais .................................................................................................................................. 35 
3.1.1.2. Requisitos não funcionais ......................................................................................................................... 36 
3.1.2. Diagrama de caso de uso .............................................................................................................. 37 
3.1.3. Especificação de Diagrama de Caso de Uso .......................................................................... 38 
4. DESENVOLVIMENTO DO PROJETO ............................................................ 42 
4.1. Diagrama de classe .................................................................................................................... 43 
4.2. Diagrama de Entidade e Relacionamento ......................................................................... 44 
4.3. Diagrama de Sequencia ............................................................................................................ 45 
4.4. Diagrama de Estado ................................................................................................................... 46 
4.5. Diagrama de Atividades ........................................................................................................... 48 
5. PROTÓTIPO DO SISTEMA ........................................................................... 50 
5.1. Implementação ........................................................................................................................... 51 
5.1.1. Técnicas e ferramentas utilizadas ............................................................................................ 51 
5.1.2. Implementação da interface Android ..................................................................................... 51 
 
 
5.1.2.1. Templates ......................................................................................................................................................... 52 
6. CONCLUSÃO ................................................................................................. 58 
6.1. Considerações Futuras ............................................................................................................. 59 
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................... 61 
ANEXO 1 – CODIGOS DO SISTEMA OCORRÊNCIAS EMERGÊNCIAIS ........... 63 
 
 
 
13 
1. INTRODUÇÃO 
 
 
Neste trabalho apresentamos o sistema elaborado com o objetivo de atender 
as exigências do Trabalho de Conclusão realizado na Universidade Paulista – 
Campus Paraíso, com base nos conteúdos aprendidos ao longo do curso de 
Sistemas de Informação. 
Definimos como missão desenvolver uma plataforma inovadora que 
atendesse os anseios e necessidades das cidades grandes, como São Paulo, que 
necessita de um serviço de segurança pública cada vez mais eficiente para atender 
os mais de 11 milhões de habitantes da cidade. 
No cenário atual, as reclamações sobre a demora no atendimento da central 
telefônica 190 da Polícia Militar vêm aumentando em São Paulo. O serviço deveria 
ser rápido, mas muitas pessoas só escutam o sinal de ocupado ou não conseguem 
completar a ligação. Quando o atendimento é feito, os policiais demoram muito para 
chegar ao local da ocorrência. 
Segundo a PM, o maior problema é o excesso de ligações que ultrapassa a 
capacidade. A PM recebe cerca de 43 mil chamadas diárias. Destas, 65% são de 
pedidos de informações e 15% são trotes, o que acaba ocupando a linha de 
atendimento. Somente 20% deste número tornam-se efetivamente ocorrência 
policial. 
Pensando nisso, desenvolvemos ao longo deste projeto, uma plataforma 
eficiente para otimizar o atendimento da policia militar em casos realmente graves e 
urgentes na cidade de São Paulo. 
Através deste aplicativo, usuários devidamente cadastrados poderão acionar 
um botão de emergência para acionar o serviço de segurança pública. Deste modo, 
conseguimos filtrar as ligações impertinentes que ocupam as centrais telefônicas, 
atendendo somente as situações de emergência. E ainda, através de uma central 
inteligente que monitora os chamados e as viaturas policiais, será possível otimizar o 
tempo para chegar ao local da ocorrência. 
 
 
 
14 
1.1. Objetivo 
 
 
Nossa finalidade, portanto, é desenvolver um sistema prático e moderno que 
otimize a prestação de serviços da policia militar e ofereça maior segurança ao 
usuário, cidadão da cidade de São Paulo. 
O sistema deverá apresentar uma interface clean e intuitiva, utilizando-se da 
tecnologia multitouch, em smartphones com sistema operacional Android. 
 
 
1.2. Objetivos específicos 
 
 
• Aumentar a rapidez de resposta dos serviços públicos; 
• Melhorar a qualidade da informação gerada; 
• Criar um sistema fácil e intuitivo para que qualquer usuário possa se 
beneficiar do aplicativo, sem restrição de idade ou grau de instrução; 
• Inibir solicitações inválidas conhecidas como “trotes”; 
• Permitir a medição de estatísticas a partir das ocorrências recebidas; 
• Possibilitar a criação de um histórico de ligações, traçando o perfil de cada 
usuário para que seja possível identificar os que utilizam o serviço de forma 
séria e os que brincam com o sistema de segurança pública. 
• Garantir a integridade dos dados; 
• Possibilitar o rastreamento por GPS para otimizar o tempo de atendimento 
da ocorrência. 
 
 
 
 
 
 
 
15 
1.3. Motivações 
 
 
Cada vez mais presente no cotidiano das pessoas, os sistemas digitais se 
tornaram condicionantes de conforto e praticidade. Novos produtos e serviços estão 
sendo exigidos nos escritórios e residências, como eletrodomésticos e aparelhos 
eletrônicos com múltiplas funcionalidades e dispositivos cada vez mais rápidos, 
menores e com melhor comunicação. As pessoas passaram a ter mais contato com 
equipamentos de alta tecnologia, que centralizam as funções de lazer, cultura e 
diversão, com funções mais amigáveis, inteligentes e práticas, trazendo para sua 
realidade uma série de aparelhos que antes faziam parte apenas do seu mundo 
imaginário. Adicionado a isso, o anseio por maior segurança nas cidades grandes e 
a popularização cada vez maior dos smartphones formam um ambiente propício 
para a criação de um aplicativo de solicitação de socorro. 
Para adquirir a base técnica necessária à este projeto, foi feito um 
aprofundamento de conhecimento na área de programação de computadores em 
Java, através da participação nas seguintes disciplinas: 
• Linguagem de Programação Orientada a Objeto, ministrado pelo professor 
Olavo, Universidade Paulista; 
• Aplicação de Linguagem de Programação Orientada a Objeto, ministrado 
pelo professor Vladimir, Universidade Paulista; 
• Banco de Dados, ministrado pelo professor Vagner, Universidade Paulista. 
Para definir o conjunto de requisitos apresentado no aplicativo foi necessário 
conhecer as características que possíveis usuários esperam deste sistema. Para 
completar, foi realizado o levantamento bibliográfico, o fichamento e a leitura de 
diversas obras, além departicipação em fóruns de discussão na internet e leitura de 
de reportagens sobre o assunto. 
 
 
 
 
 
 
16 
1.4. Estrutura do Trabalho 
 
 
Esta dissertação é apresentada em 6 capítulos. Este primeiro capítulo 
contextualiza a escolha do tema “Ocorrências Emergenciais” e descreve os objetivos 
que pretendemos alcançar. No segundo capítulo são apresentadas informações 
sobre padrões e software a serem utilizados. No terceiro capítulo desenvolvemos a 
estrutura do software proposto, enquanto que no quarto capítulo é apresentado o 
estudo de uso aplicando o framework. No quinto capítulo, é feita uma análise geral 
dos resultados obtidos. Por fim, no último capítulo são feitas as considerações finais 
bem como perspectivas futuras de melhoria para o sistema. 
 
 
 
 
 
 
17 
2. BASE TEÓRICA 
 
 
2.1. Linguagem de Modelagem Unificada 
 
 
2.1.1. Introdução à UML 
 
 
A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) 
é uma linguagem visual utilizada para modelar softwares baseados no paradigma de 
orientação a objetos. É uma linguagem de modelagem de propósito geral que pode 
ser aplicada a todos os domínios de aplicação. Essa linguagem tornou-se, nos 
últimos anos, a linguagem-padrão de modelagem adotada internacionalmente pela 
indústria de engenharia de software. Ela não é uma linguagem de programação, e 
sim uma linguagem de modelagem, uma notação, cujo objetivo é auxiliar os 
engenheiros de software a definirem as características do sistema, tais como seus 
requisitos, seu comportamento, sua estrutura lógica, a dinâmica de seus processos 
e até mesmo suas necessidades físicas em relação ao equipamento sobre o qual o 
sistema deverá ser implantado. Tais características podem ser definidas por meio da 
UML antes do software começar a ser realmente desenvolvido. Além disso, cumpre 
destacar que a UML não é um processo de desenvolvimento de software e 
tampouco está ligada a um de forma exclusiva, sendo totalmente independente, 
podendo ser utilizada por muitos processos de desenvolvimento diferentes ou 
mesmo da forma que o engenheiro considerar mais adequada. [1] 
 
 
2.1.2. Histórico 
 
 
A UML surgiu da união de três métodos de modelagem: o método de Booch, 
o método OMT (Object Modeling Technique) de Jacobson, e o método OOSE 
(Object-Oriented Software Engineering) de Rumbaugh. Estes eram, até meados da 
 
 
18 
década de 1990, os métodos de modelagem orientada a objetos mais populares 
entre os profissionais da área de desenvolvimento de software. A união desses 
métodos contou com o amplo apoio da Rational Software, que a incentivou e 
financiou. O esforço inicial do projeto começou com a união do método de Booch ao 
OMT de Jacobson, o que resultou no lançamento do Método Unificado no final de 
1995. Logo em seguida, Rumbaugh juntou-se a Booch e Jacobson na Rational 
Software, e seu método OOSE começou também a ser incorporado à nova 
metodologia. O trabalho de Booch, Jacobson e Rumbaugh, conhecidos 
popularmente como “Os Três Amigos”, resultou no lançamento, em 1996, da 
primeira versão da UML propriamente dita. Tão logo a primeira versão foi lançada, 
muitas empresas atuantes na área de modelagem e desenvolvimento de software 
passaram a contribuir para o projeto, fornecendo sugestões para melhorar e ampliar 
a linguagem. Finalmente, a UML foi adotada, em 1997, pela OMG (Object 
Management Group ou Grupo de Gerenciamento de Objetos), como uma linguagem-
padrão de modelagem. A versão 2.0 da linguagem foi oficialmente lançada em julho 
de 2005, encontrando-se esta atualmente na versão 2.3 beta. [2] 
 
 
2.1.3. Arquitetura 
 
 
Visualizar, especificar, construir e documentar sistemas complexos de 
software são tarefas que requerem a visualização desses sistemas sob várias 
perspectivas. Diferentes participantes – usuários finais, analistas, desenvolvedores, 
integradores de sistemas, o pessoal que testa os sistemas, escritores técnicos e 
gerentes de projetos – cada um traz contribuições próprias ao projeto e observa o 
sistema de maneira distinta em momentos diferentes ao longo do desenvolvimento 
deste. A arquitetura do sistema talvez seja o artefato mais importante a ser utilizado 
com o objetivo de gerenciar esses diferentes pontos de vista e assim, tornar possível 
um controle do desenvolvimento iterativo e incremental de um sistema durante seu 
ciclo de vida. A arquitetura é o conjunto de decisões significativas acerca dos 
seguintes itens: 
 
 
 
19 
• A organização do sistema de software; 
• A seleção dos elementos estruturais e suas interfaces que compõem o 
sistema; 
• Seu comportamento, conforme especificado nas colaborações entre esses 
elementos; 
• A composição desses elementos estruturais e comportamentais em 
subsistemas progressivamente maiores; 
• O estilo de arquitetura que orienta a organização: os elementos estáticos e 
dinâmicos e suas respectivas interfaces, colaborações e composição. [3] 
A arquitetura de software não está apenas relacionada à estrutura e ao 
comportamento, mas também ao uso, à funcionalidade, ao desempenho, à 
flexibilidade, à reutilização, à abrangência, a adequações e a restrições de caráter 
econômico, tecnológico, além de questões estéticas. [1] 
 
 
2.1.4. Um modelo conceitual da UML 
 
 
Como uma linguagem de modelagem, o modelo conceitual da UML fornece 
blocos básicos de construção, regras de combinação destes blocos e mecanismos 
comuns. O vocabulário de UML incorpora três tipos de blocos básicos: 
• Itens, que representam elementos comportamentais e estruturais do sistema; 
• Relacionamentos, que especificam como esses itens se relacionam entre si; 
• Diagramas, que agrupam coleções interessantes de itens. [3] 
 
 
 
 
 
 
20 
2.1.5. O ciclo de vida do desenvolvimento do software 
 
 
A UML é amplamente independente do processo. Isso significa que não se 
limita ao ciclo de vida de desenvolvimento de determinado software. Porém, para 
obter máximo proveito da UML, será preciso levar em consideração um processo 
com as seguintes características: 
• Orientado a caso de uso; 
• Centrado na arquitetura; 
• Iterativo e incremental. [2] 
Orientado a caso de uso significa que esses casos são utilizados como 
principal artefato para o estabelecimento do comportamento desejado do sistema, 
para a verificação e a validação da arquitetura do sistema, para a realização de 
testes e para a comunicação entre os participantes do projeto. Centrado na 
arquitetura significa que a arquitetura do sistema é utilizada como principal artefato 
para a conceituação, construção, o gerenciamento e a evolução do sistema em 
desenvolvimento. Um processo iterativo é aquele que envolve o gerenciamento de 
sequencias de versões executáveis. Um processo incremental é aquele que envolve 
a integração contínua da arquitetura do sistema para a produção dessas versões, de 
maneira que cada nova versão incorpora os aprimoramentos incrementais em 
relação às demais. Em conjunto, um processo iterativo e incremental é orientado a 
riscos, ou seja, cada nova versão tem como foco atacar e reduzir os riscos mais 
significativos para o sucesso do projeto. [3] 
Esse processo orientado a caso de uso, centrado na arquitetura e processo 
iterativo/incremental, pode ser desmembrado em fases. Uma fase é o intervalo de 
tempo decorrido entre dois importantes pontos marcos do processo, quando um 
conjunto bem-definido de objetivos é alcançado, os artefatos são concluídos e 
decisões são tomadas para se passar à fase seguinte. Existem quatro fases no ciclo 
de desenvolvimento de um software:• Concepção; 
• Elaboração; 
 
 
21 
• Construção; 
• Transição. 
 
No diagrama, os fluxos de trabalho são representados nessas fases, 
indicando as variações de graus do foco ao longo do tempo. A concepção é a 
primeira fase do processo, em que a ideia inicial para o desenvolvimento é levada 
até o ponto de ser – pelo menos internamente – suficientemente bem-fundamentada 
para assegurar a passagem à fase de elaboração. [2] 
A elaboração é a segunda fase do processo, quando a visão do produto e sua 
arquitetura são definidas. Nessa fase, os requisitos do sistema podem abranger 
desde declarações de caráter geral até critérios precisos de avaliação, em que cada 
requisito especifica determinado comportamento funcional ou não funcional e 
proporciona uma base para a realização de teste. A construção é a terceira fase do 
processo, em que o software chega a uma arquitetura executável e destinada à 
transferência para a comunidade de usuários. É nesta fase também que os 
requisitos do sistema e principalmente seus critérios de avaliação são 
constantemente reexaminados em relação às necessidades comerciais do projeto e 
os recursos são alocados de modo adequado a atacar ativamente os riscos do 
projeto. [3] 
A transição é a quarta fase do processo, em que o software chega às mãos 
da comunidade de usuários. Raramente o processo de desenvolvimento do software 
termina aqui, pois, até durante essa fase, o sistema é aprimorado continuamente, 
erros são eliminados e são acrescentadas novas características. [4] 
O único elemento que diferencia esse processo e que está presente em todas 
as quatro fases é a iteração. Uma iteração é o conjunto distinto de atividades, com 
um plano básico e critérios de avaliação que resultam em um sistema executável 
que pode ser executado, testado e avaliado. O sistema executável não precisa ser 
divulgado externamente. Como a iteração gera um produto executável, o progresso 
pode ser avaliado e os riscos podem ser reavaliados após cada iteração. Isso 
significa que o ciclo de vida do desenvolvimento de um software pode ser 
caracterizado como um fluxo contínuo de evolução de verões executáveis da 
arquitetura do sistema com correções após cada iteração, a fim de diminuir o risco 
 
 
22 
potencial. É a ênfase na arquitetura com o um artefato importante que orienta a UML 
para o foco na modelagem das diferentes visões da arquitetura de um sistema. [1] 
 
2.1.6. Diagramas – UML 
 
 
Diagramas são os meios utilizados para a visualização dos blocos de 
construção da UML. São representações gráficas de um conjunto de elementos que 
permitem visualizar o sistema entre diferentes perspectivas. Cada visão é descrita 
por determinado número de diagramas que contém informação referente a um 
aspecto específico do sistema. A vantagem dessa abordagem é que podemos nos 
concentrar em um aspecto do sistema por vez. Em UML, existe a distinção entre 
modelo e diagrama, que são: 
• Modelo contém informações a respeito dos elementos de um sistema em 
estudo, independente de como são apresentados visualmente; 
• Diagrama é uma visualização particular de certos elementos de tipos de um 
modelo, e geralmente expõe apenas um subconjunto de informação 
detalhada desses elementos. [6] 
 
 
2.1.7. Síntese Geral dos Diagramas 
 
 
Os diagramas são divididos basicamente em dois grupos: 
• Diagramas Estruturais; 
• Diagramas Comportamentais. 
 
Os diagramas estruturais são utilizados para visualizar, especificar, construir e 
documentar aspectos estáticos de um sistema. Os diagramas estruturais são 
compostos por: diagramas de Classe, Objetos, Componentes, Implantação, Pacotes 
e Estrutura. [4] 
 
 
23 
2.1.7.1. Diagramas de Classes 
 
 
O Diagrama de Classes é utilizado para fazer a representação de estruturas 
de classes de negócio, interfaces e outros sistemas e classes de controle. Além 
disso, o diagrama de classes é considerado o mais importante para a UML, pois 
serve de apoio para a maioria dos demais diagramas. [5] 
 
 
2.1.7.2. Diagramas de Caso de Uso 
 
 
É um diagrama utilizado para auxiliar a comunicação entre o os analistas de 
sistema e o cliente, onde será demonstrada as funcionalidades do sistema de uma 
maneira simples e direta. [6] 
 
 
2.1.7.3. Diagramas de Estado 
 
 
Esse diagrama demonstra os diferentes estados de um objeto durante seu 
ciclo, e os eventos (estímulos) que fazem com que o objeto altere seu estado. 
O diagrama de estado é aconselhável para sistemas mais complexos, deve 
ser desenvolvido para objetos que possuam seus estados definidos e onde o 
comportamento desse objeto possa mudar a partir de um outro estado. Os 
diagramas de estado começam com um estado inicial e podem ter várias saídas ou 
fins. [5] 
 
 
 
 
24 
2.1.7.4. Diagramas de Atividades 
 
 
O objetivo do diagrama de atividades é demonstrar a sequência de atividades 
de um processo através de comportamento paralelo e condicional. Os diagramas de 
atividade, assim como o de estado, também possuem um estado inicial podendo ter 
mais de uma saída. [4] 
 
 
2.1.7.5. Diagramas de Sequência 
 
 
Um diagrama de sequência descreve a maneira como os grupos de objetos 
colaboram em algum comportamento ao longo do tempo. Ele registra o 
comportamento de um único caso de uso e exibe os objetos e as mensagens 
passadas entre esses objetos no caso de uso. [5] 
Em síntese: o diagrama de sequência é uma das ferramentas UML usadas 
para representar interações entre objetos de um cenário, realizadas através de 
operações ou métodos (procedimentos ou funções). Este diagrama é construído a 
partir do Diagrama de Casos de Usos. Primeiro, se define qual o papel do sistema 
(Use Cases), depois, é definido como o software realizará seu papel (sequência de 
operações). O diagrama de sequência dá ênfase à ordenação temporal em que as 
mensagens são trocadas entre os objetos de um sistema. Entende-se por 
mensagens os serviços solicitados de um objeto a outro, e as respostas 
desenvolvidas para as solicitações. [6] 
 
 
 
 
 
 
 
 
25 
2.2. Linguagem Orientada a Objetos 
 
 
2.2.1. Lógica de Programação 
 
 
Lógica de Programação pode ser definida como os princípios, métodos e 
técnicas, utilizados para organizar e estruturar o pensamento humano. Através da 
lógica de programação podemos validar as informações adquiridas, analisando se o 
raciocínio está correto ou incorreto, onde são através destes que surgem soluções a 
serem tomadas referentes a diversos problemas. [7] 
 
 
2.2.2. Linguagem de Programação 
 
 
A linguagem de programação é considerada como um conjunto de instruções 
escritas, através de sintaxes e utilização de códigos, que possibilitam a máquina 
compreender e executá-las sem haver limite de quantidades de execução, assim, 
podendo ser executada repetidamente. Porém, algumas das linguagens de 
programação necessitam de tradução intermediária para que seja possível a 
compreensão e execução pela maquina, sendo essa tradução realizada pela 
transformação da linguagem de programa em linguagem de maquina, feita através 
de compiladores. [8] 
As linguagens de programação podem ser divididas em dois grandes grupos, 
sendo: 
• Baixo nível: linguagem voltada para a máquina, utilizando as instruções do 
microprocessador do computador; 
• Alto nível: linguagem voltada para o ser humano utilizando de sintaxes 
estruturadas, onde, torna o código mais legível e de fácil compreensão. [9] 
 
 
 
 
26 
2.2.3. Orientação a Objetos 
 
 
Considerado um paradigma de programação, as técnicasde orientação a 
objetos possibilitam que objetos se relacionem entre si em um sistema e possuam 
comportamentos específicos, através de interfaces bem definidas e pela estrutura de 
dados utilizada. Através da orientação a objetos, as linguagens são desenvolvidas 
com base em objetos e situações que representam o mundo real, assim, o 
responsável pelo seu desenvolvimento pode utilizar maior concentração no 
desenvolvimento geral do sistema, e não apenas em detalhes que predominam no 
processo de desenvolvimento dos softwares. [11] 
 Em meados da década de 80, com o surgimento da orientação a objetos 
algumas novidades foram introduzidas, como por exemplo, o usuário e o analista 
possuem maior facilidade de entendimento das situações necessárias, pois é 
possível ao analista utilizar os objetos de seus diagramas da mesma maneira no 
qual foi projetado, para implementação. [10] 
Entre os fundamentos básicos da orientação a objetos, podemos encontrar 
conceitos onde cada um possui algum entendimento sobre o mundo real, sendo 
esses: 
• Objetos: conjunto de coisas do mundo real, podendo ser real ou abstrato. 
Objetos de uma mesma classe são únicos, e possuem como descrição de 
suas características, atributos; 
• Classes: representa um grupo de objetos com características comuns, 
sendo compostos por atributos e métodos; 
• Métodos: ações próprias que cada objeto pode realizar, e é através dos 
métodos que objetos se comunicam entre si; 
• Herança: possibilita a reutilização de códigos (campos e métodos não 
privados), sendo possível criar uma classe, tendo outra classe já existente 
como base; 
 
 
27 
• Encapsulamento: atributos de uma classe permanecem ocultos, sendo 
disponibilizados para visualização através do método GET e possibilitando 
sua alteração somente pelo método SET. [10] 
 
 
2.2.4. Vantagens da Orientação a Objetos 
 
 
Com a implementação das técnicas de orientação a objetos, consideramos 
como principais vantagens dessa técnica: 
• Reutilização de objetos, ou seja, ao criar um objeto qualquer, seja ele 
complexo ou de fácil criação, é possível que qualquer outro desenvolvedor 
venha a utilizá-lo, bastando acessar esse objeto para realizar as mesmas 
tarefas. Caso venha a acontecer qualquer tipo de manutenção interna no 
objeto, os demais desenvolvedores que utilizaram deste objeto não 
necessitam realizar a mesma alteração; 
• Maior flexibilidade caso haja necessidade de mudança no sistema; 
• Facilidade na manutenção; 
• Código se torna mais lógico. [11] 
 
 
2.2.5. Eclipse 
 
 
Eclipse é um IDE desenvolvido em Java, seguindo o modelo open source de 
desenvolvimento de software. O projeto Eclipse foi iniciado na IBM que desenvolveu 
a primeira versão do produto e doou-o como software livre para a comunidade. O 
gasto inicial da IBM no produto foi demais de 40 milhões de dólares. Hoje, o Eclipse 
é uma das IDEs Java mais utilizado no mundo. Possui como características 
marcantes o uso da SWT e não do Swing como biblioteca gráfica, a forte orientação 
ao desenvolvimento baseado em plug-ins e o amplo suporte ao desenvolvedor com 
 
 
28 
centenas de plug-ins que procuram atender as diferentes necessidades de 
diferentes programadores. [12] 
 
 
2.2.6. Linguagem de Programação – Java 
 
 
A Sun Microsystem em 1992 criou o Green Team com a finalidade de 
desenvolver inovações tecnológicas. O time liderado por James Gosling, 
considerado como o pai do Java, deu foco na criação de um interpretador (uma 
máquina virtual) para dispositivos eletrônicos pequenos que facilitaria a reescrita do 
software, como televisores, aparelhos de TV a cabo e videocassete. A tentativa de 
incorporar essa tecnologia nos aparelhos eletrodomésticos não deu certo, tiveram 
tentativas frustradas ao tentar fechar contratos com grandes fabricantes. [13] 
Em 1992 a Sun percebeu que essa tecnologia podia ser rodada em pequenas 
aplicações no browser. Devido a sua versatilidade operacional possibilitando 
executar uma aplicação independente da sua plataforma. Então deu-se o 
lançamento do JAVA 1.0. E desde seu lançamento, sua tecnologia foi rapidamente 
adotada. [13] 
 
 
2.2.7. Android 
 
 
Android é o sistema operacional desenvolvido pela empresa Google, o 
sistema desenvolvido roda sobre o núcleo Linux customizado. Atualmente o sistema 
é desenvolvido pela Open Handset Alliance, mas a Google ainda continua 
responsável pela gerência do produto e engenharia de processos. O Android por ser 
um sistema operacional aberto, permite aos desenvolvedores escreverem 
programas na sintaxe da linguagem de programação Java controlando o dispositivo 
via bibliotecas especificas desenvolvida pela Google. [14] 
 
 
29 
A princípio, o sistema teve no início o seu desenvolvimento com a Android 
Inc., uma pequena empresa que trabalha no desenvolvimento em um sistema 
operacional aberto. Com a venda pra Google, em julho de 2005, a empresa avançou 
no seu desenvolvimento, focando na criação de uma plataforma aberta e flexível, 
facilitando assim a migração para os fabricantes. [14] 
 
 
2.3. Banco de Dados 
 
 
2.3.1. Introdução à Banco de Dados 
 
 
Ao longo do tempo, muitas organizações buscam novos meios para manter e 
recuperar informações de maneiras eficientes, com certo custo-benefício. Hoje, o 
sucesso de uma organização está na capacidade de adquirir dados precisos e em 
tempo real sobre suas operações, gerenciando esses dados de forma eficiente e 
utilizando os mesmos para analisar e guiar suas atividades diárias. [15] 
Um Banco de Dados pode ser definido como uma coleção de dados 
relacionados, sendo a representação abstrata do mundo real e seguido de um 
raciocínio lógico no qual não permite que os dados existentes sejam separados 
devido a sua estrutura e relação existente entre si, onde qualquer alteração na 
realidade das informações refletirá nas informações armazenadas no banco de 
dados. É capaz e possui como principal característica, evitar perdas de dados por 
falhas no sistema, acessos não autorizados e anomalias de dados. [15] 
Os sistemas de banco de dados em uma organização necessitam de um 
projeto, visando melhor organização das informações e utilização de técnicas para 
que o sistema possua melhor desempenho, assim, facilitando manutenções para 
eventuais necessidades futuras. [16] 
Em um projeto de banco de dados, são considerados três níveis de abstração 
de modelo de dados: Modelo Conceitual, Modelo Lógico e Modelo Físico, além de 
 
 
30 
muitas pessoas envolvidas para possibilitar o uso e as manutenções a serem 
realizadas, são essas pessoas: 
• Administradores de banco de dados ou database administrator – DBA. 
Administram os recursos do banco de dados, SGBD e os softwares 
relacionados. Possui responsabilidade nas permissões de acesso ao banco 
de dados, uso e por adquirir recursos de hardware e software conforme a 
necessidade da organização. 
• Projetistas do banco de dados. Responsáveis pela identificação dos dados 
que serão armazenados no banco e também por escolher as estruturas 
mais adequadas para representar e armazenar esses dados. [16] 
• Usuários finais. Pessoas que terão acesso às informações do banco 
através de consultas, realizar modificações no banco de dados de acordo 
com as suas permissões e gerar relatórios. [16] 
• Analistas de Sistemas. Determinam as solicitações dos usuários finais, 
além de desenvolver as especificações das transações que atendam a 
essas solicitações. 
• Programadores de aplicações implementam as especificações como 
programas, testando, documentando e mantendo as transações 
customizadas. [16]2.3.2. SQLite 
 
 
O SQLite é uma ferramenta que permite com que desenvolvedores possam 
armazenar os dados de suas aplicações em tabelas e manipular esses dados 
através de comandos SQL. A diferença é que tudo isso pode ser feito sem que seja 
preciso acessar um SGBD. Devido a sua simplicidade e eficiência, o SQLite está se 
tornando cada vez mais popular, especialmente entre as pessoas que programam 
nas linguagens PHP e C / C++. [17] 
 
 
 
31 
2.3.3. Características do SQLite 
 
 
A seguir são apresentadas algumas características da biblioteca SQLite: 
• Software gratuito, multiplataforma, desenvolvido em C padrão (ANSI). 
Atualmente está na versão 3.5.1.; 
• Todo o banco de dados é guardado localmente (junto com a aplicação), em 
um único arquivo que possui a extensão “db”. A base de dados pode ter 
tamanho superior a 2 terabytes; 
• Não necessita de instalação, configuração ou de administração. Você não 
precisa ser um DBA para dominar o uso do SQLite; 
• Suporta a maior parte do SQL 92; 
• Suporta o uso de transações (COMMIT / ROLLBACK); 
• Muito fácil de usar se você estiver programando em PHP 5 ou C / C++; 
• Não oferece integridade referencial (chaves estrangeiras); 
• Principais aplicações: programas locais, sites web, substituto de banco de 
dados em aulas ou demonstrações, substitui arquivos texto ou arquivos 
proprietários; 
• Não deve ser usado nos seguintes casos: aplicações de alta concorrência 
e sistemas ou aplicações web de porte muito grande. [17] 
 
 
2.4. GPS (Sistema de Posicionamento Global) 
 
 
 Os dispositivos GPS (Sistema de Posicionamento Global) exibem aos 
usuários sua atual localização através de cálculos feitos pelo próprio dispositivo, 
baseados em sinais recebidos por uma rede de satélites artificiais que giram na 
órbita da Terra. A função do dispositivo é de captar sinais de, no mínimo, quatro 
 
 
32 
satélites diferentes, possibilitando-o calcular sua posição no globo terrestre. Essa 
operação matemática é chamada trilateração. [18] 
A trilateração tridimensional é baseada na interseção de esferas, geradas 
através da distância do dispositivo até os satélites, sendo que cada satélite é 
responsável por uma esfera e a própria Terra conta como uma esfera, ou seja, 
quanto mais satélites tiverem seu sinal captado, maior a precisão da localização. 
A distância entre o satélite e o dispositivo é calculada pelo tempo de atraso na 
resposta do satélite pelo sinal enviado do receptor e para que o receptor saiba a 
localização exata do satélite, ocorre um sincronismo do relógio. A ideia básica do 
sistema de GPS Diferencial é ajustar a imprecisão do sistema comum de GPS 
utilizando uma base receptora que tenha sua posição conhecida. Como a base já 
sabe sua posição no globo terrestre, envia para os receptores da região equipados 
com o DGPS a correção de sinal daquela área, tornando a precisão extremamente 
próxima à localização real. [18] 
Com a informação da posição atual e com a atualização que ocorre de tempo 
em tempo, é possível que o receptor calcule a distância percorrida, tempo de 
duração de um ponto a outro, velocidade média, velocidade atual e tempo estimado 
para chegada enquanto ainda se está no trajeto e o caminho já realizado. [18] 
 
 
 
33 
3. PROJETO PARA SISTEMAS 
 
 
Planejar o sistema significa velocidade de desenvolvimento, redução de 
custos, menos manutenção, mais produtividade e vantagem competitiva. 
A analise e o projeto do sistema são processos que envolvem: 
• O levantamento de informações por analista de sistemas sobre 
necessidades específicas do negócio da empresa; 
• O estudo, organização e ilustração das necessidades; 
• E a elaboração da solução que será utilizada no desenvolvimento do 
sistema. 
Este procedimento é semelhante ao processo de construção de uma casa ou 
um prédio de qualidade. É essencial fazer um planejamento detalhado, com a 
finalidade de pensar sobre as formas de construção, fazer estimativas de tempo, 
recursos, pessoas para a realização desse projeto. Para fazermos um bom projeto, 
utilizamos uma linguagem de modelagem dotada de diagramas que permitam a 
representação de sistemas em diferentes visões. Isso facilita o entendimento tanto 
do cliente quanto do programador. 
Cada fase do processo de produção de software está associada a 
metodologias e padrões de desenvolvimento. Os diagramas e documentação 
elaborados seguem a notação da UML (United Modeling Language ou Linguagem 
de Modelagem Unificada) que é uma linguagem visual utilizada para modelar os 
sistemas computacionais por meio de paradigmas de Orientação a Objetos. 
 
 
3.1. Análise do sistema 
 
 
A análise enfatiza a investigação do problema, o seu objetivo é produzir uma 
compreensão ampla, e pouco profunda sobre o sistema. Nesta etapa o analista tem 
 
 
34 
a missão de formular junto ao cliente o que será o sistema, quais as regras de 
negócio que estão envolvidas, quem, e como será usado o sistema. 
A análise consiste no estudo de documentações e entrevistas com 
colaboradores da empresa a fim de definir a característica do software, tais como 
seus requisitos, comportamento, estrutura e dinâmica de seus processos. 
A etapa de análise é de grande relevância porque além de documentar o 
sistema requerido, permite: 
• O entendimento do sistema tanto pelo analista, quanto pelo cliente; 
• A organização e padronização da linguagem, documentos e recursos; 
• As descobertas de novas necessidades não pensadas na definição do 
escopo do projeto; 
• O desenvolvimento mais rapidamente dos módulos atuais e futuros; 
• Diminuição do custo com o projeto em razão de resolução de na etapa 
da análise. 
No final da etapa da análise já é possível ter uma estimativa mais precisa de 
investimento e tempo para a produção do sistema desejado. Nesta fase 
correspondem os seguintes documentos: 
• Levantamento de Requisitos; 
• Diagrama de Caso de Uso; 
• Modelo conceitual. 
 
 
3.1.1. Levantamento de Requisitos 
 
 
Para o desenvolvimento de um trabalho que propõe um aplicativo de 
solicitação de serviços emergenciais da Policia Militar da cidade de São Paulo, fez-
se o levantamento de vários requisitos, que foram divididos em requisitos funcionais 
e requisitos não funcionais. 
 
 
35 
3.1.1.1. Requisitos funcionais 
 
 
Os requisitos funcionais (RF) são: 
• Cadastro de usuário cidadão – permite a criação de um usuário no sistema; 
• Cadastro de usuário policial – permite a criação de um usuário no sistema 
de acordo com o número da viatura; 
• Solicitar o chamado – permite que o usuário cidadão solicite o atendimento/ 
chamado através do aplicativo; 
• Tratamento de erro – permite que o usuário cidadão tenha uma alternativa 
caso os sistemas de internet móvel e GPS estejam apresentando 
instabilidade; 
• Consulta da ocorrência – permite que o usuário consulte quem atendeu a 
ocorrência; 
• Exportação da metodologia – permite ao usuário policial a possibilidade de 
exportar todas as ocorrências atendidas num determinado formato, como 
TXT, por exemplo. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
36 
3.1.1.2. Requisitos não funcionais 
 
 
Os requisitos não funcionais (RNF) são: 
• Usabilidade – a interface com o usuário é de vital importância para o 
sucesso do sistema. Principalmente por ser um sistema que será utilizado 
em uma urgência do usuário. 
• Desempenho – embora não seja um requisito essencial ao sistema deve 
ser considerada por corresponder a um fator de qualidade de software. 
• Hardware e software – visando criar um produto com maior extensibilidade,reusabilidade e flexibilidade, deve se adotar como linguagem principal de 
desenvolvimento Java seguindo cuidadosamente as técnicas de orientação 
a objetos. O uso da linguagem Java permite especificar qual será o sistema 
operacional em que o programa irá ser executado. No entanto, esse 
aparelho deverá se comunicar com um sistema de banco de dados. 
• Imprimir lista de ocorrências atendidas – embora não seja um requisito 
essencial ao sistema, deve ser considerada a corresponder a um fator de 
qualidade de software. 
 
 
 
 
 
 
 
 
 
 
 
 
37 
3.1.2. Diagrama de caso de uso 
 
 
A seguir será apresentado na Figura 1.1, o Caso de Uso do Sistema 
“Ocorrências Emergenciais”. 
 
Figura 1.1 – Diagrama de caso de uso 
 
 
 
38 
3.1.3. Especificação de Diagrama de Caso de Uso 
 
 
A especificação de Caso de Uso, descreve os casos de uso na forma de 
cenários narrativos. Nas tabelas 1.1, 1.2, 1.3, 1.4 seguem os casos de uso do 
sistema “Ocorrências Emergenciais”. 
 
 
Tabela 1.1 – Primeiro Acesso 
 
 
 
39 
 
Tabela 1.2 – Alterar Dados Cadastrais 
 
 
40 
 
Tabela 1.3 – Solicitação de Emergência 
 
 
 
41 
 
Tabela 1.4 – Recebendo Solicitação de Emergência 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
42 
4. DESENVOLVIMENTO DO PROJETO 
 
 
O projeto basicamente enfatiza a proposta de solução do problema que 
atenda os requisitos levantados na análise. Em outras palavras, a análise é a 
investigação para tentar descobrir o que o cliente quer e o projeto consiste em 
propor a solução com base no estudo levantado na análise. 
Por fim, o projeto é uma extensão do modelo de análise e diferente da mesma, o 
resultado produzido é para ser compreendido pelos programadores na construção 
do sistema. 
Ao término já é possível ter uma noção mais concreta dos recursos 
necessários, tempo, investimento e tecnologias adicionais necessárias para o 
desenvolvimento do sistema. Abaixo a lista dos documentos que serão produzidos 
na etapa de projeto: 
 
• Diagrama de classes; 
• Diagrama de sequência; 
• Diagrama de estados; 
• Diagrama de atividade; 
 
 
 
 
 
 
 
 
 
 
 
 
 
43 
4.1. Diagrama de classe 
 
 
Diagrama de Classes é uma logica estática em uma superfície de duas 
dimensões mostrando uma coleção de elementos declarativos de modelo, como 
classes, tipos e seus respectivos conteúdos e relações. Ele é estático já que a 
estrutura descrita é sempre valida em qualquer ponto do ciclo de vida do sistema. 
Na figura 1.2, o Diagrama de Classes do sistema “Ocorrências Emergenciais”. 
 
 
 Figura 1.2 – Diagrama de classes 
 
 
44 
4.2. Diagrama de Entidade e Relacionamento 
 
 
Através deste diagrama poderemos representar, de forma sucinta e bem 
estruturada, todos os elementos essenciais abstraídos no processo de análise de 
sistemas. Na Figura 1.3 veremos o diagrama de entidade e relacionamento referente 
ao Processo de solicitação emergencial. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Figura 1.3 – Diagrama de entidade e relacionamento 
(1,1) 
(1,1) 
(1,*) (0,1) 
(1,1) (1,1) 
(1,1) (1,1) (1,1) 
(0,1) 
(0,1) 
(0,1) 
 
USUÁRIO CIVIL 
 
CADASTRO 
REALIZA 
POSSUI 
 
SOLICITAÇÃO 
ENVIA 
DADOS 
 
CALCULO DE 
ROTAS 
FAZ A 
(0,1) 
VIATURA MAIS 
PROXIMA 
ENVIA 
POSSUI 
PARA 
 
NOTIFICAÇÃO 
 
POLICIA MILITAR 
 
 
45 
 
4.3. Diagrama de Sequencia 
 
 
Apresenta a interação de sequencia de tempo dos objetos que participam 
dessa interação. Eles mostram a colaboração dinâmica entre vários objetos de um 
sistema. Em particular os objetos são representados por suas “linhas de vida” e 
interagem por troca de mensagens ao por um período. 
 
 
 
Figura 1.4 – Diagrama de Sequencia 
 
 
 
 
 
 
 
46 
4.4. Diagrama de Estado 
 
 
Diagrama de Estado mostra o comportamento dinâmico de uma classe, 
componente, subsistema ou objeto. Ele cobre o ciclo de vida do objeto, passando 
por vários estados em uma sequencia logica e cronológica. Na Figura 1.5 e 1.6 
veremos os diagramas de estado referentes ao cadastro do usuário e ao envio do 
chamado de socorro. 
 
 
Figura 1.5 – Fluxo do Cadastro do Usuário 
 
 
47 
 
Figura 1.6 – Fluxo da Solicitação de Socorro 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
48 
4.5. Diagrama de Atividades 
 
 
Sua finalidade é documentar o fluxo de execução de uma operação ou caso 
de uso, demostrando os caminhos condicionais e atividades concorrentes, ele é útil 
quando deseja descrever um comportamento paralelo ou interação entre os 
comportamentos de vários casos de uso. 
Diagramas de Atividades capturam ações e seus resultados. Eles focam o 
trabalho executado na implementação de uma operação, e suas atividades numa 
instância de um objeto. Ele é uma variação do diagrama de estado e possui um 
proposito diferente, que é de capturar a ação e seus resultados em termos das 
mudanças de estado dos objetos. 
Na Figura 1.7, apresentamos o digrama de atividades do usuário do sistema e 
na Figura 1.8 apresentamos da viatura de policia. 
 
 
 
Figura 1.7 – Fluxo do Usuário 
 
 
 
49 
 
Figura 1.8 – Fluxo da viatura de policia 
 
 
 
 
 
 
 
 
 
 
 
 
50 
5. PROTÓTIPO DO SISTEMA 
 
O sistema “Ocorrências Emergenciais“ tem como função enviar um sinal de 
alerta com a localização do cidadão via GPS, O sistema é dividido em duas partes: 
• Cidadão; 
• Central de chamado. 
Como verificamos na figura 1.9, é apresentado o fluxograma do processo. 
 
 
 
Figura 1.9 – Fluxograma do processo do sistema 
 
 
 
 
 
 
 
51 
5.1. Implementação 
 
 
Nesta seção são relatados os aspectos relacionados à implementação do 
protótipo final. São também mostrados detalhes técnicos da construção do 
aplicativo, fazendo-se um detalhamento em relação aos passos necessários para a 
construção do aplicativo. 
 
 
5.1.1. Técnicas e ferramentas utilizadas 
 
 
Para o desenvolvimento do protótipo foram utilizadas varias ferramentas e 
linguagens em conjunto. A programação do aplicativo foi feita utilizando a linguagem 
Java e a ferramenta Eclipse 3.5. O Banco de Dados foi usado SQlite 3.5.1. 
 
 
5.1.2. Implementação da interface Android 
 
 
Nessa seção será mostrado detalhes da implementação do aplicativo. 
Primeiramente é apresentado um trecho do código que resume o funcionamento do 
aplicativo, em seguida é feito um detalhamento sobre as etapas mais importantes do 
aplicativo, para então, finalizar com os problemas encontrados e conclusões. 
 
 
 
 
 
 
 
52 
5.1.2.1. Templates 
 
 
Nesta seção apresentamos as principais telas do sistema e seus códigos. 
A figura 2.0. retrata a tela de cadastro do usuário, que deverá preencher todos 
os campos corretamente para que seja liberada a opção “avançar”. 
 
 
Figura 2.0 
 
 
 
 
 
 
 
 
 
 
53 
 
Após concluir o cadastro, surge outra tela (figura 2.1) que solicita mais alguns 
dados. É importante que o usuário forneça o nome e telefone de algum amigo ou 
familiar próximo para que a Polícia Militar entre em contato em caso de alguma 
emergência. 
 
 
 
Figura 2.154 
A figura 2.2 retrata a principal tela do aplicativo. Aqui, basta que o usuário 
pressione o botão vermelho central para acionar o serviço de emergência. 
 
 
Figura 2.2 
 
Ao pressionar o botão, uma tela de status (figura 2.3) informa o usuário sobre 
o processo de envio da sua localização, que deverá levar apenas alguns segundos. 
 
Figura 2.3 
 
 
55 
A figura 2.4 retrata o informativo exibido caso o envio da localização seja 
efetuado com sucesso. Na figura 2.5, a tela exibe a mensagem de falha no envio da 
localização. Neste caso, o usuário pode ligar diretamente para o serviço de 
emergência policial. 
 
 Figura 2.4 
 
 Figura 2.5 
 
 
 
 
56 
Na figura 2.6 é apresentada a tela da tablet das viaturas policiais onde o 
condutor da viatura fará o login. 
 
Figura 2.6 
 
 
Após inserir o código da viatura, são apresentados os dados da solicitação de 
emergência, conforme a figura 2.7: 
 
Figura 2.7 
 
 
 
57 
Ao clicar no botão “ver mapa – GPS”, o policial visualizará o mapa geográfico 
que apontará o local da ocorrência e indicará o caminho a ser percorrido (figura 2.8). 
 
Figura 2.8 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
58 
6. CONCLUSÃO 
 
No desenvolvimento deste trabalho foram atingidos os objetivos propostos, a 
utilização da linguagem UML foi primordial para a modelagem e desenvolvimento do 
sistema. Interpretamos facilmente as necessidades para o desenvolvimento do 
aplicativo e conseguimos transpor para o escopo inicial todos os requisitos 
fundamentais do projeto tal como as regras definidas pela organização e suas 
intenções do produto final. A diagramação do projeto possibilitou uma excelente 
visão para o desenvolvimento, facilitando o trabalho, comunicação e eficiência de 
todos os membros responsáveis pelo desenvolvimento desse trabalho. 
Com a utilização da linguagem de programação Java, que provê toda a 
facilidade de uma linguagem orientada a objetos, desenvolvemos uma solução que 
está atual no mercado, utilizando dos melhores recursos tecnológicos disponíveis, 
como a ferramenta de desenvolvimento Eclipse e frameworks, o que reduziu 
drasticamente o tempo empenhado na construção do produto desejado e até mesmo 
em manutenções que o aplicativo pode vir a receber. 
Concluímos que as tecnologias, mais precisamente sobre os aplicativos 
para smartphone, estão disponíveis para que possamos ter uma maior eficiência, 
agilidade, precisão e comodidade nos afazeres diários, nos serviços prestados pelo 
governo, por bancos, provedores de e-mail e no entretenimento disponibilizado 
através de redes sociais, jogos, entre outros. 
Abaixo, alguns benefícios trazidos pelo aplicativo: 
• A população que possua o aplicativo estará contribuindo com o 
principal problema, hoje, da Central de Atendimento da Polícia Militar, o 
“trote”. Com a diminuição dos trotes os policiais serão melhores 
realocados nas ruas atendendo solicitações de emergência reais, onde 
se faz necessário a intervenção policial; 
• Traz a discrição do informante, que fará a solicitação de uma forma 
segura sem se expor a riscos maiores; 
• Diminuição do tempo de chegada da viatura ao local, devido à 
localização ser detectada através de sinal GPS e enviado diretamente 
 
 
59 
à viatura de polícia mais próxima sem a necessidade de terceiros para 
a transmissão da mensagem; 
• Facilita o trabalho policial, retirando a necessidade de o agente de 
polícia ter de anotar manualmente todos os dados informados pelo 
atendente da central e procurar o endereço informado. Todos esses 
dados serão recebidos por um tablet da viatura automaticamente 
exibindo o melhor caminho através de um mapa GPS. 
Para próximas versões do aplicativo, poderão ser adicionados diversos itens 
como, por exemplo, um sistema de rastreamento do celular, onde ao executar a 
solicitação, o policial acompanhará o deslocamento do smartphone solicitante, teclas 
de atalho para a solicitação, widget na tela de bloqueio do aparelho, solicitante 
receber o código da viatura que irá atendê-la e acompanhar o trajeto da mesma até 
o local, entre algumas outras ideias. 
Em suma, o aplicativo trará benefícios significantes à população, através da 
melhora na agilidade de atendimentos emergenciais e de serviços prestados pela 
Polícia Militar do Estado de São Paulo. 
 
 
6.1. Considerações Futuras 
 
 
Diante do apresentado neste trabalho veem-se alguns trabalhos que 
futuramente podem tornar o uso do modelo mais simples e completo para usuários 
de smartphone com a inclusão de novas funcionalidades de solicitações de outros 
serviços emergenciais, são apresentadas as seguintes sugestões: 
• Implementar tecla de atalho, widget na tela de bloqueio do aparelho 
para efetuar solicitações. 
• Implementar a solicitação de serviços emergenciais dos Bombeiros. 
• Implementar a solicitação de serviços emergenciais do SAMU (serviço 
de atendimento móvel de urgência). 
 
 
60 
• Implementar serviço de rastreamento celular, onde o atendente do 
solicitação acompanha a movimentação do smartphone solicitante. 
• Implementar serviço de rastreamento da viatura, para o usuário 
acompanhar o trajeto da mesma ate o local do atendimento. 
• Implementar um retorno para o usuário contendo o código da viatura 
que irá atende-lo. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
61 
REFERÊNCIAS BIBLIOGRÁFICAS 
 
 
[1] Larman, Craig; Utilizando UML e Padrões; Uma introdução à análise e ao 
projeto orientado. 3º Edição. São Paulo. Bookman, 2005 
[2] Pender, Tom; UML; a Biblia; 1º Edição. São Paulo. Campus, 2003 
[3] Booch, Grady; Rumbaugh, James; Jacobson, Ivar; UML; Guia do Usuário. 
2° edição. Rio de Janeiro. Elsevier, 2006. 
[4] Fowler, Martin; UML; Essencial, Um breve guia para a linguagem-padrão 
de modelagem de objetos. 3° edição, Porto Alegre. Bookman, 2004. 
[5] Page-Jones, Meillir; Fundamentos do desenho orientado a objetos com 
UML, 1º Edição. Makron Books, 2001. 
[6] Bezerra, Eduardo; Princípios de análise e projeto de sistemas com 
UML; Um guia prático para modelagem de sistemas. 2° edição, Rio de Janeiro. 
Elsevier, 2006. 
[7] Jusdewbe, Tatiane de Souza Moura; Apostila de Lógica de 
Programação. 
[8] Correia, Carlos H. e Tafner, Malcon A.. ; Análise Orientada a Objetos; 
Florianópolis, Visual Books, 2006. 
[9] Shlaer, Sally; Mellor, Stephen J.. ; Análise de Sistemas Orientada para 
Objetos; Makron Books, 1990. 
[10] Boratti, Camilo Isaias; Programação Orientada a Objetos em Java; 1ª 
Edição, Visual Books, 2007. 
[11] Santos, Rafael; Introdução A Programação Orientada A Objetos; 3ª 
Edição, Editora Campus, 2003. 
[12] Golçaves, Edson; Dominando Eclipse - Tudo que o Desenvolvedor 
Java Precisa para Criar Aplicativos para Desktop; 1ª Edição, Editora Ciência 
Moderna, 2006. 
[13] Santos, Rui Rossi dos; Programação de Computadores em Java - 
Nova Terra; 1ª Edição, Editora Nova Terra, 2011. 
 
 
62 
[14] W. Frank Ableson, Robi Sem, Chris King e C. Enrique Ortiz; Android em 
Ação; 3ª Edição , Editora Campus, 2012. 
 [15] Ramez E. Elmasri, Shamkant Navathe; Sistema de Banco de Dados - 
Fundamentos e Aplicações; 4ª Edição. Editora Addison Wesley, 2005. 
[16] Rezende, Ricardo. SQL Magazine. Conceitos Fundamentais de Banco 
de Dados. Disponível em: 
http://www.sqlmagazine.com.br/Colunistas/RicardoRezende/02_ConceitosBD.asp 
[17] Grant Allen, Mike Owens; The Definitive Guide to SQLite; 3ª Edição, 
Editora:Apress, 2010. 
[18] Segantine, Paulo Ces; Gps Sistema de Posicionamento Global; 3ª 
Edição, São Paulo, Editora da USP, 1972. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
63 
ANEXO 1 – CODIGOS DO SISTEMA OCORRÊNCIAS EMERGÊNCIAIS 
 
 
Cadastro do Usuário 
 
<?xml version="1.0" encoding="utf-8"?> 
<AbsoluteLayout 
android:id="@+id/widget0" 
android:layout_width="fill_parent" 
android:layout_height="fill_parent" 
xmlns:android="http://schemas.android.com/apk/res/android"> 
<TextView 
android:id="@+id/widget38" 
android:layout_width="241dp" 
android:layout_height="25dp" 
android:text="Cadastro de Usu&#225;rio - SOS" 
android:textSize="18sp" 
android:layout_x="2dp" 
android:layout_y="3dp" /> 
<EditText 
android:id="@+id/widget41" 
android:layout_width="300dp" 
android:layout_height="wrap_content" 
android:hint="Nome" 
android:textSize="18sp" 
android:layout_x="12dp" 
android:layout_y="37dp" /> 
<EditText 
android:id="@+id/widget42" 
android:layout_width="300dp" 
android:layout_height="wrap_content" 
android:hint="Endere&#231;o" 
 
 
64 
android:textSize="18sp" 
android:layout_x="12dp" 
android:layout_y="86dp" /> 
<EditText 
android:id="@+id/widget43" 
android:layout_width="81dp" 
android:layout_height="wrap_content" 
android:hint="N&#250;mero" 
android:textSize="18sp" 
android:layout_x="12dp" 
android:layout_y="137dp" /> 
<EditText 
android:id="@+id/widget44" 
android:layout_width="192dp" 
android:layout_height="wrap_content" 
android:hint="CEP" 
android:textSize="18sp" 
android:layout_x="120dp" 
android:layout_y="136dp" /> 
<EditText 
android:id="@+id/widget45" 
android:layout_width="300dp" 
android:layout_height="wrap_content" 
android:hint="Bairro" 
android:textSize="18sp" 
android:layout_x="11dp" 
android:layout_y="189dp" /> 
<EditText 
android:id="@+id/widget46" 
android:layout_width="301dp" 
android:layout_height="wrap_content" 
android:hint="Cidade" 
android:textSize="18sp" 
 
 
65 
android:layout_x="11dp" 
android:layout_y="245dp" /> 
<EditText 
android:id="@+id/widget47" 
android:layout_width="300dp" 
android:layout_height="wrap_content" 
android:hint="Telefone" 
android:textSize="18sp" 
android:layout_x="11dp" 
android:layout_y="301dp" /> 
<Button 
android:id="@+id/widget49" 
android:layout_width="164dp" 
android:layout_height="46dp" 
android:text="Cadastrar" 
android:textSize="20sp" 
android:typeface="serif" 
android:textStyle="bold" 
android:textColor="@color/red" 
android:gravity="center" 
android:onClickListener="SalvarDados" 
android:layout_x="76dp" 
android:layout_y="366dp" /> 
</AbsoluteLayout> 
 
 
 
 
 
 
 
 
 
 
66 
Cadastro de Contato 
 
<?xml version="1.0" encoding="utf-8"?> 
<AbsoluteLayout 
android:id="@+id/widget0" 
android:layout_width="fill_parent" 
android:layout_height="fill_parent" 
xmlns:android="http://schemas.android.com/apk/res/android"> 
<TextView 
android:id="@+id/widget50" 
android:layout_width="127dp" 
android:layout_height="37dp" 
android:text="AVISO!!!!" 
android:textSize="22sp" 
android:typeface="serif" 
android:textStyle="bold" 
android:textColor="@color/red" 
android:gravity="center" 
android:layout_x="96dp" 
android:layout_y="31dp" /> 
<TextView 
android:id="@+id/widget51" 
android:layout_width="139dp" 
android:layout_height="105dp" 
android:text="Para sua maior seguran&#231;a, informe um telefone de um parente ou pessoa 
pr&#243;xima, caso necessitemos entrar em contato em caso de emerg&#234;ncia" 
android:textColor="@color/yellow" 
android:gravity="center" 
android:layout_x="93dp" 
android:layout_y="71dp" /> 
<EditText 
android:id="@+id/widget52" 
android:layout_width="259dp" 
 
 
67 
android:layout_height="wrap_content" 
android:hint="Telefone" 
android:textSize="18sp" 
android:layout_x="33dp" 
android:layout_y="192dp" /> 
<EditText 
android:id="@+id/widget53" 
android:layout_width="260dp" 
android:layout_height="wrap_content" 
android:hint="Falar com" 
android:textSize="18sp" 
android:layout_x="32dp" 
android:layout_y="255dp" /> 
<Button 
android:id="@+id/widget54" 
android:layout_width="180dp" 
android:layout_height="wrap_content" 
android:text="Cadastrar" 
android:textSize="20sp" 
android:typeface="serif" 
android:textStyle="bold" 
android:textColor="@color/red" 
android:gravity="center" 
android:onClickListener="SalvarContato" 
android:layout_x="74dp" 
android:layout_y="337dp" /> 
</AbsoluteLayout> 
 
 
 
 
 
 
 
68 
Chamada de Socorro 
 
<?xml version="1.0" encoding="utf-8"?> 
<AbsoluteLayout 
android:id="@+id/widget0" 
android:layout_width="fill_parent" 
android:layout_height="fill_parent" 
xmlns:android="http://schemas.android.com/apk/res/android"> 
<Button 
android:id="@+id/widget60" 
android:layout_width="267dp" 
android:layout_height="261dp" 
android:background="@color/darkgray" 
android:text="Button" 
android:layout_x="27dp" 
android:layout_y="76dp" /> 
</AbsoluteLayout> 
 
 
Envio da Solicitação de Socorro 
 
<?xml version="1.0" encoding="utf-8"?> 
<AbsoluteLayout 
android:id="@+id/widget0" 
android:layout_width="fill_parent" 
android:layout_height="fill_parent" 
xmlns:android="http://schemas.android.com/apk/res/android"> 
<TextView 
android:id="@+id/widget62" 
android:layout_width="271dp" 
android:layout_height="33dp" 
android:text="ATENDIMENTO EMERGENCIAL" 
 
 
69 
android:textSize="18sp" 
android:typeface="sans" 
android:textColor="@color/red" 
android:gravity="center" 
android:layout_x="97dp" 
android:layout_y="42dp" /> 
<EditText 
android:id="@+id/widget63" 
android:layout_width="201dp" 
android:layout_height="wrap_content" 
android:hint="C&#243;digo da Viatura" 
android:textSize="18sp" 
android:gravity="center" 
android:layout_x="121dp" 
android:layout_y="110dp" /> 
<Button 
android:id="@+id/widget64" 
android:layout_width="172dp" 
android:layout_height="wrap_content" 
android:text="Conectar" 
android:textSize="18sp" 
android:typeface="serif" 
android:textStyle="bold" 
android:textColor="@color/red" 
android:gravity="center" 
android:layout_x="136dp" 
android:layout_y="183dp" /> 
</AbsoluteLayout> 
 
 
 
 
 
 
70 
Retorno de aviso sobre a solicitação 
 
<?xml version="1.0" encoding="utf-8"?> 
<AbsoluteLayout 
android:id="@+id/widget0" 
android:layout_width="fill_parent" 
android:layout_height="fill_parent" 
xmlns:android="http://schemas.android.com/apk/res/android"> 
<Button 
android:id="@+id/widget54" 
android:layout_width="180dp" 
android:layout_height="wrap_content" 
android:text="LIGAR 190" 
android:textSize="24sp" 
android:typeface="serif" 
android:textStyle="bold" 
android:textColor="@color/red" 
android:gravity="center" 
android:onClickListener="DiscarUmNoveZero" 
android:layout_x="72dp" 
android:layout_y="251dp" /> 
<TextView 
android:id="@+id/widget56" 
android:layout_width="305dp" 
android:layout_height="55dp" 
android:text="Falha ao enviar a sua Localiza&#231;&#227;o!" 
android:textSize="16sp" 
android:textStyle="bold" 
android:textColor="@color/red" 
android:gravity="center" 
android:layout_x="9dp" 
android:layout_y="188dp" /> 
 
 
71 
<ImageButton 
android:id="@+id/widget58" 
android:layout_width="115dp" 
android:layout_height="111dp" 
android:src="C:\User\gribeiro\Pictures\TCC\Layouts\exclama&#231;&#227;o.jpg"