Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA PARA EMISSÃO DE NOTIFICAÇÕES DE REGULARIZAÇÃO
EM ÁREA AZUL UTILIZANDO POCKET PC E WEBSERVICES SOBRE A
PLATAFORMA .NET
Área de Computação Móvel
por
Davi Rogério Morelato
Krishnan Lage Pontes, MSc. Orientador
Itajaí (SC), junho de 2008
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA PARA EMISSÃO DE NOTIFICAÇÕES DE REGULARIZAÇÃO
EM ÁREA AZUL UTILIZANDO POCKET PC E WEBSERVICES SOBRE A
PLATAFORMA .NET
Área de Computação Móvel
por
Davi Rogério Morelato Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Krishnan Lage Pontes, MSc.
Itajaí (SC), junho de 2008.
ii
DEDICATÓRIA
Dedico este trabalho à minha querida mãe, Eunice Pelizzaro,
que não poupou esforços, durante toda minha criação,
para que eu tivesse uma educação de qualidade
e um futuro de sucesso.
Por todo este esforço é que eu atinjo mais uma meta em minha vida.
iii
AGRADECIMENTOS
A todos que, de alguma forma, contribuíram para a conclusão deste trabalho e minha
formação acadêmica.
Um agradecimento especial à minha amada mãe, Eunice Pelizzaro, que esteve presente em
todos os momentos, difíceis e fáceis desta caminhada, apoiando, animando, dando força e
sustentando, até que o objetivo fosse atingido.
À minha namorada, Cecília, pela compreensão e por estar sempre presente ao meu lado.
Aos amigos e colegas que sempre ajudaram e colaboraram no andamento do curso e
desenvolvimento deste trabalho.
A todos os professores que me passaram seus conhecimentos técnicos e práticos,
adicionando valor a todo meu conhecimento adquirido, em especial a Carla Merkle e Krishnan Lage
Pontes, que foram meus orientadores do trabalho de conclusão de curso.
A Universidade do Vale do Itajaí, por oferecer este curso, que é reconhecido pela sua alta
qualidade. Por me facilitar o acesso a esta formação e abrir as portas para o mercado de trabalho.
iv
SUMÁRIO
LISTA DE ABREVIATURAS..................................................................vi LISTA DE FIGURAS..............................................................................viii RESUMO.....................................................................................................x
ABSTRACT................................................................................................xi 1 INTRODUÇÃO......................................................................................1 1.1 PROBLEMATIZAÇÃO ..................................................................................... 3 1.1.1 Formulação do Problema................................................................................. 3 1.1.2 Solução Proposta ............................................................................................... 4 1.2 OBJETIVOS ........................................................................................................ 4 1.2.1 Objetivo Geral ................................................................................................... 4 1.2.2 Objetivos Específicos ........................................................................................ 4 1.3 METODOLOGIA................................................................................................ 5 1.4 ESTRUTURA DO TRABALHO ....................................................................... 6
2 FUNDAMENTAÇÃO TEÓRICA ........................................................7 2.1 ÁREA AZUL........................................................................................................ 7 2.2 DISPOSITIVOS MÓVEIS ................................................................................. 8 2.2.1 Pocket PC......................................................................................................... 10 2.2.2 Windows Mobile.............................................................................................. 12 2.2.2.1 Recursos ......................................................................................................... 12 2.2.2.2 Versões ........................................................................................................... 13 2.2.3 Considerações .................................................................................................. 14 2.3 PROGRAMAÇÃO MÓVEL ............................................................................ 15 2.3.1 .Net Compact Framework.............................................................................. 17 2.4 PLATAFORMA .NET ...................................................................................... 17 2.4.1 MSIL................................................................................................................. 18 2.4.2 CLR .................................................................................................................. 19 2.4.3 CLS................................................................................................................... 20 2.4.4 MONO.............................................................................................................. 20 2.4.5 DotGNU Portable .NET.................................................................................. 21 2.4.6 C#...................................................................................................................... 21 2.5 XML. ................................................................................................................... 21 2.6 SOAP................................................................................................................... 22 2.7 WEBSERVICES................................................................................................ 24 2.8 CONSIDERAÇÕES .......................................................................................... 26
3 DESENVOLVIMENTO ......................................................................27 3.1 CARACTERIZAÇÃO DO DOMÍNIO DA APLICAÇÃO ........................... 28 3.2 TECNOLOGIAS ESCOLHIDAS.................................................................... 29
v
3.3 WEBSERVICE .................................................................................................. 29 3.4 WEBSITE........................................................................................................... 33 3.5 MODELAGEM.................................................................................................. 34 3.5.1 Levantamento de Requisitos .......................................................................... 34 3.5.1.1 Requisitos Funcionais..................................................................................... 34 3.5.1.2 Requisitos Não Funcionais............................................................................. 36 3.5.1.3 Regras de Negócio.......................................................................................... 37 3.5.1.4 Restrições ....................................................................................................... 39 3.5.2 Projeto do Sistema .......................................................................................... 39 3.5.2.1 Diagramas de Casos de Uso ........................................................................... 39 3.5.2.1.1 Pocket PC................................................................................................ 40 3.5.2.1.2 WebSite................................................................................................... 41 3.5.2.1.3 WebService............................................................................................. 41 3.5.2.2 Diagramas de Atividades................................................................................ 43 3.5.2.2.1 Login....................................................................................................... 43 3.5.2.2.2 Emitir Notificações de Regularização .................................................... 44 3.5.2.2.3 Sincronização.......................................................................................... 45 3.5.2.2.4 Regularização de Notificações ............................................................... 46 3.5.2.2.5 Emissão de Segunda Via ........................................................................ 47 3.5.2.3 Diagramas de Classes de Domínio/Negócio .................................................. 48 3.5.2.4 Arquitetura do sistema.................................................................................... 50 3.5.2.5 Telas do Sistema............................................................................................. 51 3.5.2.6 Diagrama de Componentes/Diagrama de Implantação.................................. 57 3.5.2.7 Diagrama ER .................................................................................................. 58 3.5.2.8 XML Schema.................................................................................................. 59 3.6 IMPLEMENTAÇÃO DO SISTEMA .............................................................. 60 3.7 TESTES E AVALIAÇÃO................................................................................. 73
4 CONCLUSÕES ....................................................................................83
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................86
A XML SCHEMA....................................................................................92 A.1 XML SCHEMA ARMAZENAMENTO DAS NOTIFICAÇÕES EMITIDAS NO POCKET PC....................................................................................................... 92 A.2 XML SCHEMA RELAÇÃO DE RUAS DAS CIDADES ............................. 93 A.3 XML SCHEMA MODELOS DE VEÍCULOS ............................................... 93
vi
LISTA DE ABREVIATURAS
AFC AppForge Crossfire AOT Ahead-Of-Time API Application Programming Interface BCL Base Class Library CDC Connected Device Configuration CE Compact Edition CET Companhia de Engenharia de Tráfego CLCD Connected Limited Device Configuration CLR Common Language Runtime CLS Common Language Specification CPU Central Processing Unit CTS Common Type System DCOM DCOM Distributed Component Object Model DLL Dynamic Link Libraries EMS Enhaced Messaging Service EVB Embedded Visual Basic ER Entidade Relacoinamento FCL Framework Class Library FM Frequency modulation GPRS General Packet Radio Service GPS Global Positioning System GSM System for Mobile Communications HP Hewlett Packard HTML Hyper Text Markup Language HTTP Hyper Text Transfer Protocol IBGE Instituto Brasileiro de Geografia e Estatística IDE Integrated Development Environment IIOP Internet Inter Operability Protocol IIS Internet Information Services JDK Java Development Kit JIT Just-In-Time JNI Java Native Interface JRE Java Run-time Enviroment JVM Java Virtual Machine J2ME Java 2 Micro Edition J2SE Java 2 Standard Edition KVM Kilobyte Virtual Machine LER Lesão por Esforço Repetitivo MMIT Microsoft Mobile Internet Toolkit MMS Multimedia Messaging Service MSDN Microsoft Developer Network MSIL Microsoft Intermediate Language PC Personal Computer PDA Personal Digital Assistant PE Portable Executable RAM Random Access Memory
vii
RIM Research In Motion RMI Remote Method Invocation ROM Read Only Memory RTM Release To Manufacture SDK Software Development Kit SETERB Serviço Autônomo Municipal de Terminais Rodoviários de Blumenau SGML Standard Generalized Markup Language SMS Short Message Service SOA Service-Oriented Architecture SOAP Simple Object Access Protocol SQL Structured Query Language TCC Trabalho de Conclusão de Curso UDDI Universal Description Discovery and Integration UF Unidade Federativa UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí USB Universal Serial Bus XML Extensible Markup Language WAP Wireless Application Protocol WML Wireless Markup Language WSDL Web Service Description Language WSEL Web Service Endpoint Language WSFL Web Services Flow Language
viii
LISTA DE FIGURAS
Figura 1. PDA utilizado pelo IBGE no Censo 2007................................................................ 11 Figura 2. Envelope SOAP........................................................................................................ 23 Figura 3. Envelope de requisição SOAP.................................................................................. 24 Figura 4. Casos de Uso existentes no sistema que executará no Pocket PC............................ 40 Figura 5. Casos de Uso existentes nos WebSites..................................................................... 41 Figura 6. Casos de Uso existentes no WebService................................................................... 42 Figura 7. Diagrama da Atividade de Login no sistema............................................................ 43 Figura 8. Diagrama da Atividade de Emissão de Notificações................................................ 44 Figura 9. Diagrama da Atividade de Sincronização com WebService.................................... 45 Figura 10. Diagrama da Atividade de envio das Notificações Regularizadas.......................... 46 Figura 11. Diagrama da Atividade de emissão da segunda via das notificações...................... 47 Figura 12. Diagrama de Classes de Domínio............................................................................ 49 Figura 13. Arquitetura do Sistema............................................................................................ 50 Figura 14. Tela de Login do Sistema........................................................................................ 51 Figura 15. Tela Principal do Sistema........................................................................................ 51 Figura 16. Tela do Sistema para Emissão de Notificações, Descrição do Veículo.................. 52 Figura 17. Tela do Sistema para Emissão de Notificações, Descrição da Notificação............. 52 Figura 18. Tela do Sistema para Visualização e Impressão das Notificações Cadastradas...... 53 Figura 19. Autenticação de usuário para acesso aos WebSites.................................................. 53 Figura 20. Busca por notificações não regularizadas e notificações encontradas..................... 54 Figura 21. Solicitação do número da notificação a ser regularizada......................................... 54 Figura 22. Solicitação dos dados do veículo para gerar segunda via da notificação................. 55 Figura 23. Notificações localizadas para o veículo informado.................................................. 55 Figura 24. Segunda via da Notificação, pronta para ser impressa............................................. 56 Figura 25. Notificação impressa em arquivo .PDF.................................................................... 56 Figura 26. Diagrama de Componentes / Diagrama de Implantação do Sistema........................ 57 Figura 27. Diagrama ER do Sistema.......................................................................................... 59 Figura 28. Criação de um projeto no Visual Studio 2005.......................................................... 60 Figura 29. Edição de formulários no Visual Studio 2005 e opções de controles disponíveis... 61 Figura 30. Tratamento de usabilidade impedindo a impressão da notificação, quando não ..... 62 Figura 31. XML que armazena marcas de veículos................................................................... 62 Figura 32. Código utilizando DataSets, DataTables e DataRows............................................... 63 Figura 33. WebSite criado automaticamente pelo Vistual Studio permitindo que ..................... 65 Figura 34. Teste de um serviço disponibilizado pelo WebServices. ......................................... 65 Figura 35. Estrutura de tabelas criadas no banco de dados........................................................ 66 Figura 36. Ferramenta para configuração de acessos a WebServices em projetos .................... 67 Figura 37. Interface para gerenciamento de impressão fornecida pelo componente .................. 68 Figura 38. Emuladores disponíveis para teste da aplicação......................................................... 69 Figura 39. Desenho dos WebSites em template próprio para browsers de dispositivos móveis. 70 Figura 40. Teste de login no sistema com diferentes erros de entrada de dados......................... 77 Figura 41. Testes na emissão de notificações.............................................................................. 78 Figura 42. Impressão da notificação em arquivo .PDF e gravação em arquivo XML................ 78 Figura 43. Processo de sincronização e comprovação dos resultados pela consulta ao ............. 79 Figura 44. Processo de atualização do sistema e comprovação dos resultados por ................... 80 Figura 45. Demonstração de teste do WebSite que permite impressão da segunda ................... 81 Figura 46. Demonstração de teste do WebSite que relaciona notificações não regularizadas.... 81
ix
Figura 47. Demonstração de teste no WebSite que regulariza notificações.............................. 82 Figura 48. XML Schema Armazenamento das Notificações Emitidas no Pocket PC. ............ 92 Figura 49. XML Schema Ruas das Cidades. ............................................................................ 93 Figura 50. XML Schema Modelos de Veículos. ...................................................................... 93 Figura 51. Talão de Estacionamento da Área Azul................................................................... 95 Figura 52. Notificação de Regularização.................................................................................. 96 Figura 53. Notificação de Infração............................................................................................ 97
x
RESUMO
MORELATO, Davi R. Sistema para emissão de notificações de regularização em área azul utilizando Pocket PC e WebServices sobre a plataforma .Net. Itajaí, 2007. 83 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2007. Este texto apresenta o projeto do desenvolvimento de um sistema, que soluciona um problema diariamente vivenciado em cidades que utilizam o estacionamento rotativo regulamentado, Área Azul, também conhecida como Zona Azul. O projeto apresentado é desenvolvido para ser utilizado em um dispositivo móvel, mais especificamente em um Pocket PC, e implementado utilizando-se de tecnologias emergentes como plataforma .NET e WebServices. Os agentes de trânsito que fiscalizam as Áreas Azuis, atualmente utilizam talões de papel com notificações de regularização. Este método gera eventuais inconveniências, como rasuras, retrabalho, demora no preenchimento da notificação e, ultimamente, lesão por esforço repetitivo. O sistema apresentado neste projeto visa substituir os talões de papel por um Pocket PC, no qual o agente de trânsito preenche uma notificação de forma rápida, facilmente corrigível, transportável e ergonomicamente correta. Logo que uma notificação é preenchida, ela pode ser impressa, em uma mini-impressora conectada ao dispositivo. A relação de notificações emitidas pode ser enviada a um Banco de Dados, e fica disponível a outros sistemas, como o WebSite, também implementado, que consulta o WebService e disponibiliza as notificações na Internet. Palavras-chave: Área Azul. Pocket PC. Plataforma .NET. WebServices.
xi
ABSTRACT
This paper presents the project of the system development that solves a problem experienced daily in cities that use the regulated rotary parking lot, called Blue Area, also known as the Blue Zone. The presented project is developed to be used in a mobile device, specifically on a Pocket PC, it is implemented using emerging technologies as .NET and Web Services platform. The traffic officers who supervise the Blue Areas, currently use note pad with reports of regularization. This method generates eventual inconveniences, such as erasures, rework, delay to complete the notification and lately lesion by repetitive effort. The presented system in this project aims to replace the note pad for a Pocket PC, in which the traffic officer fills a notification in an ergonomically correct, portable, easily correctly and quick way. So a notification is filled out, it can be printed in a mini-printer connected to the device. The issued relation of notifications can be sent to a Database, and will be available to other systems such as the Website, also implemented which consult the WebService and provide the notifications on the Internet. Keywords: Blue Area. Pocket PC. Platform .NET. WebServices.
1 INTRODUÇÃO
Os dispositivos móveis PDAs vêm sendo utilizados nas mais diversas áreas, pois permitem o
acesso à informação de qualidade que pode ser transportada. Sua aplicabilidade abrange áreas como
a de automação dos serviços de trânsito, auxiliando agentes de trânsito na execução de suas tarefas.
O trânsito de automóveis nas cidades é cada vez maior. Uma boa organização permite que o
trânsito flua de maneira correta, evitando problemas como congestionamentos. No centro das
cidades, a quantidade de veículos é ainda maior, visto que ali ficam os bancos, órgãos públicos,
escritórios e o comércio em geral. Entretanto, os centros das cidades não têm vagas suficientes para
estacionar a quantidade de veículos que por ali trafega. Dessa forma, uma das soluções
implementadas para resolver o problema das vagas nos centros de algumas cidades catarinenses é
chamada Zona Azul (SETERB, 2007; IPUF, 2007).
A Zona Azul (ou Área Azul) é a restrição de tempo imposta aos veículos que desejam
estacionar em áreas públicas centrais, para prover uma forma de rodízio no estacionamento dos
carros. Os carros estacionados nessas áreas têm um limite de tempo de permanência na vaga
escolhida, sujeitos à multa por desobediência ao limite imposto. Para ter o direito de estacionamento
na Zona Azul, deve-se comprar um talão (disponível no comércio da região ou diretamente com os
agentes de trânsito), preenchê-lo e deixar visivelmente exposto no veículo. Desta forma, será
facilmente observado pelo agente responsável por aquela área.
Os agentes de trânsito que fiscalizam as áreas azuis emitem notificações de regularização
aos veículos que não possuírem o talão ou os possuem preenchidos incorretamente. As notificações
devem ser regularizadas em até 5 dias, caso contrário, tornam-se multas.
As normas de trânsito aqui apresentadas referem-se especificamente ao Município de
Blumenau, de acordo com sua legislação, uma vez que o projeto está sendo dimensionado para esta
cidade.
Com base neste processo, verificou-se que consideráveis melhorias poderiam surgir a partir
da utilização de tecnologias já existentes no mercado, como PDAs para emissão de notificações e
utilização de WebServices para integração com outros eventuais sistemas que poderiam automatizar
outras partes do processo (PASTA, 2003).
2
A proposta deste projeto de pesquisa é desenvolver um sistema a ser executado em Pocket
PC, que acompanhará os agentes da Área Azul em suas tarefas. Neste sistema, os agentes
preenchem as notificações de regularização, podendo corrigir facilmente eventuais entradas de
dados incorretas. Assim que estiver totalmente preenchida, a notificação é impressa a partir de uma
mini-impressora (própria para Pocket PC) e afixada no automóvel. As notificações são armazenadas
no dispositivo e a qualquer momento são facilmente enviadas para um Banco de Dados, com auxílio
de um serviço apropriado, disponível no WebServices. As notificações permanecem no Banco de
Dados para serem acessadas por outros sistemas que venham solicitar as notificações regularizadas
ou permitir impressão de segunda via, por exemplo.
Existem outros sistemas desenvolvidos para auxiliar o controle do trânsito, similares ao
desenvolvido neste projeto, entre eles o desenvolvido pela empresa Compusol (COMPUSOL, 2007)
e outro desenvolvido em um projeto de TCC (PASTA, 2003).
O Sistema de Autos de Infração de Transito - S.A.I.T. da Compusol permite acesso a Banco
de Dados para obter informações como modelo de veículos, a partir de sua marca, nome de cidades,
cadastro de veículos já anteriormente preenchidos e tipos de infração. O S.A.I.T. também permite a
impressão da notificação a partir de uma mini-impressora, que pode ser feita no momento da
emissão do auto (COMPUSOL, 2007).
O sistema desenvolvido no Projeto de TCC (PASTA, 2003) é o SAT (Sistema de
Automação de Trânsito). O SAT permite o cadastro de Ruas, Agentes de Trânsito, veículos e
infrações através de uma interface acessível somente pelo usuário do Órgão de Trânsito. Permite
também, em outra interface, emitir notificações que ficam disponíveis aos agentes de trânsito. Este
sistema não permite imprimir notificações a partir de mini-impressoras, mas sim um sincronismo
com um módulo instalado em um computador. Neste módulo é gerado um arquivo texto, com a
relação de infrações cadastradas, que será importado pelo sistema responsável pela emissão dos
autos de infração (PASTA, 2003). Este sistema foi desenvolvido a partir da ferramenta Genexus,
versão 8.0, na linguagem de programação EVB (Embedded Visual Basic).
Para agregar ainda maior valor ao projeto deste TCC, foram desenvolvidos três WebSites
que também consultam o WebService, disponibilizando na Internet a impressão da segunda via das
notificações, solução para regularização das notificações e impressão da relação de notificações que
não foram regularizadas em tempo hábil.
3
Este projeto de pesquisa se justifica em nível de Trabalho de Conclusão de Curso para o
Curso de Ciência da Computação, uma vez que trata do desenvolvimento de uma solução
computacional que faz uso de tecnologias, conceitos e teorias relevantes a essa área. O projeto
também utiliza conhecimentos adquiridos em diversas disciplinas do curso, como redes de
computadores, programação, engenharia de software, engenharia de usabilidade, sistemas
distribuídos e desenvolvimento Web.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
Os agentes de Áreas Azuis têm por obrigação notificar todos os veículos que descumprirem
as condições de uso. Para isto, existe um bloco de papel, onde são preenchidas as notificações de
regularização. Depois de preenchidas, são destacadas e afixadas no veículo, para que seu
proprietário tome as providências necessárias.
Cada notificação existente no bloco é composta por duas vias. Uma via é afixada ao veículo,
a outra (canhoto) fica com o agente, para que seja entregue ao departamento de trânsito. Os
canhotos ficam armazenados na central por até 5 dias, tempo limite até que o proprietário do
veículo ou responsável regularize a situação. Durante este período, conforme as notificações vão
sendo regularizadas, estas são removidas, serviço que é feito manualmente. As notificações não
regularizadas em até 5 dias tornam-se multas e devem ser enviadas ao departamento responsável
pela emissão de multas.
O agente carrega um (ou mais) bloco de notificações durante todo o seu trabalho, cerca de 8
horas por dia. A notificação de regularização é preenchida manualmente neste bloco em papel e no
caso de ocorrerem rasuras, não poderão ser desfeitas, tendo que reiniciar todo o preenchimento de
uma nova notificação.
O fato das notificações serem preenchidas em bloco de papel, sobre uma prancheta, criando
uma postura incorreta, e serem emitidas, em média, mais de duas mil notificações por dia, vêm
causando Lesão por Esforço Repetitivo (LER) nos agentes de trânsito. Cinco agentes de trânsito já
precisaram ser afastados, temporariamente, por lesões adquiridas em serviço.
O tempo de preenchimento e a impossibilidade de correção das rasuras tornam a tarefa ainda
mais difícil. Por fim, os blocos devem ser guardados de forma segura até o fim do expediente, para
4
que cheguem íntegros ao departamento de trânsito, são características que dificultam o trabalho dos
agentes de trânsito.
1.1.2 Solução Proposta
A proposta deste projeto é desenvolver um sistema a ser executado em Pocket PCs, que
acompanharão os agentes da Área Azul em suas tarefas. Neste sistema, os agentes preenchem as
notificações de regularização, podendo corrigir facilmente erros, nas entradas de dados, que venham
a ocorrer. Assim que estiver totalmente preenchida, a notificação é impressa a partir de uma mini-
impressora (própria para Pocket PC) e afixada no automóvel. As notificações são armazenadas no
dispositivo e assim que o agente desejar, são facilmente enviadas a um Banco de Dados
permanecendo ali, de forma que permita a integração com outros sistemas que eventualmente
possam automatizar outras partes do processo.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo geral deste projeto é desenvolver uma solução para a emissão de notificações de
regularização em Áreas Azuis, que será utilizada em Pocket PC. O sistema desenvolvido permitirá
que o agente de trânsito preencha fácil e rapidamente uma notificação e a imprima. As notificações
emitidas poderão ser enviadas a um Banco de Dados, onde estarão disponíveis a outros sistemas que
por ventura venham a automatizar outras etapas do processo.
1.2.2 Objetivos Específicos
Os objetivos específicos deste trabalho que podem ser citados são os seguintes:
1. Compreender a teoria necessária em relação aos dispositivos móveis e ferramentas de
programação móvel;
2. Entender o funcionamento de um Pocket PC e Windows Mobile;
3. Compreender a teoria necessária das tecnologias WebServices e XML, assim como sua
implementação utilizando a Plataforma .NET, com linguagem de programação C#;
4. Determinar os requisitos exigidos pelo sistema;
5. Realizar a modelagem conceitual do sistema;
5
6. Implementar o sistema;
7. Testar e avaliar a implementação do Sistema; e
8. Documentar o desenvolvimento e os resultados do sistema.
1.3 Metodologia
Este trabalho de conclusão de curso está dividido em quatro etapas, são elas: a)Leitura e
levantamento de conceitos; b)Análise e projeto; c) Desenvolvimento e d)Documentação.
A leitura e levantamento de conceitos compreendem um estudo das teorias especificadas nos
objetivos específicos do trabalho, bem como demais teorias identificadas, necessárias ao
desenvolvimento do projeto. Os conceitos estudados foram: Dispositivos Móveis, Programação
Móvel, C#, Pocket PC, Windows Mobile, WebServices, XML, SOAP e Área Azul.
O objetivo do estudo foi adquirir conhecimento sobre as tecnologias existentes que
permitem o desenvolvimento de um projeto como este. O estudo foi feito por meio de revisão
bibliográfica em livros, sites, artigos e em outros trabalhos de conclusão de curso.
A análise e projeto iniciaram com a modelagem do sistema, onde foi feito o levantamento
dos requisitos exigidos pelo sistema, bem como as regras do negócio. O projeto do sistema buscou
definir detalhadamente o funcionamento do sistema por meio de diagramas de caso de uso,
diagramas de atividades, diagramas de classes de domínio/negócio, diagrama de componentes,
diagrama de implantação, telas do sistema, XML Schema e Diagrama ER (Entidade
Relacionamento). O projeto do software foi desenvolvido seguindo os padrões da UML, com
auxílio da ferramenta Enterprise Architect.
O desenvolvimento do sistema foi iniciado no TCC II, com base no projeto do sistema
especificado no TCC I o sistema foi desenhado, escrito, testado e avaliado.
Durante o desenvolvimento das três etapas iniciais do projeto, todo o material que foi
produzido, conforme concluído, foi documentado, seguindo as normas exigidas pela Coordenação
de TCC.
6
1.4 Estrutura do trabalho
Este trabalho foi dividido em quatro capítulos.
O Capítulo 1 destina-se a uma apresentação geral do trabalho, descrevendo a situação que é
atingida pelo sistema, os problemas existentes, solução proposta e os objetivos desta solução.
No Capítulo 2 é feita a descrição da pesquisa bibliográfica, realizada sobre as tecnologias
que abrangem o sistema proposto e tecnologias alternativas.
No Capítulo 3 é feito o desenvolvimento do sistema, definindo o levantamento e análise dos
requisitos, modelagem do sistema conforme padrões da UML, a descrição da implementação do
projeto proposto, os testes e as avaliações.
No Capítulo 4 são descritas considerações finais referentes ao TCC.
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo são tratados diversos temas necessários ao desenvolvimento de aplicativos
móveis. São apresentados conhecimentos referentes a dispositivos móveis e ferramentas de
programação móvel; Pocket PC e Windows Mobile; Plataforma .NET; linguagem de programação
C#. WebServices e XML (Extensible Markup Language) também serão descritos, pois são
tecnologias emergentes que auxiliam na comunicação distribuída entre os dispositivos.
2.1 Área Azul
A municipalização do trânsito é uma das questões previstas no Código de Trânsito Brasileiro
(CTB) que está em vigor desde 1998. Segundo o código, ficam os municípios responsáveis pelos
serviços de engenharia, fiscalização e educação de trânsito (BRASIL, 1998).
O SETERB, Serviço Autônomo Municipal de Terminais Rodoviários de Blumenau, é o
órgão gerenciador e fiscalizador do sistema de trânsito e transporte em Blumenau, responsável por
administrar o fluxo de veículos nas ruas, principalmente na região central da cidade (PASTA,
2003).
Dentre as obrigações dos órgãos de trânsito municipais está a de implantar, manter e operar
sistema de estacionamento rotativo pago nas vias, conforme inciso X do artigo 24 do CTB
(BRASIL 1998). A partir desta atribuição, bem como o alto número de veículos na região central de
Blumenau, foi redimensionado o estacionamento rotativo ali implantado, regido pela Lei Municipal
Nº 7024 (BLUMENAU, 2006). Foi determinado que o condutor de um veículo dispusesse de até
duas horas para deixar seu veículo estacionado em uma área de rotatividade (Área Azul). Após este
tempo, deve retirar seu veículo, sujeito a multa (SETERB, 2007).
A Lei Municipal Nº 7024 (BLUMENAU, 2007), determina o funcionamento da Área Azul,
devendo funcionar da maneira descrita na seqüência.
Nas vias e logradouros públicos incluídos na Área Azul o estacionamento somente será
usufruído mediante pagamento, nos dias e horários estabelecidos nas placas de sinalização ali
presentes. Será considerada infração o não pagamento do preço estipulado. O pagamento poderá ser
feito através do cartão de estacionamento da Área azul que pode ser comprado antecipadamente
com desconto de 25%, que é apresentado no Anexo I. No caso de um agente de trânsito notar
8
ausência deste cartão, o pagamento será feito através de uma Notificação de Regularização,
conforme exemplo no Anexo II.
O período de estacionamento será de uma ou duas horas. Todo o veículo que permanecer
estacionado por tempo contínuo superior ao determinado e aquele cujo condutor deixar de pagar a
tarifa fixada, no prazo de cinco dias, incorrerá em infração a ser punida, prevista no inciso XVII do
artigo 181 do Código Brasileiro de Trânsito (BRASIL, 1998). Modelo de Notificação de Infração
disponível no Anexo III.
As Notificações de regularização são emitidas sempre que um veículo for identificado,
estacionado em Área Azul, sem a presença do cartão de estacionamento da Área Azul. O
preenchimento das notificações é feito em um bloco de papel, composto por duas vias, uma que será
entregue ao condutor do veículo (a via branca) e outra será encaminhada ao departamento de
trânsito (a via amarela).
Ao final do dia, o agente de trânsito encaminha as vias amarelas ao departamento
responsável. As vias amarelas das notificações de regularização permanecem ali por até cinco dias,
pois este é o prazo que o condutor do veículo tem para regularizar sua situação. Ao final dos cinco
dias, cada uma das notificações emitidas armazenadas em vias amarelas, é conferida com a relação
de notificações regularizadas, sendo que, aquelas não regularizadas incorrerão em infração a ser
punida (BLUMENAU, 2007). Esta relação de infrações a serem punidas será encaminhada ao
departamento responsável pela emissão das multas de trânsito.
2.2 Dispositivos Móveis
A comunicação entre indivíduos e povos sempre foi uma necessidade, seja para uma simples
conversa quanto para a distribuição de uma notícia. A comunicação à distância também sempre foi
uma necessidade e se tornou cada vez maior, chegando à globalização em que vivemos nos dias
atuais. Os meios de comunicação evoluíram bastante com a invenção de tecnologias como o
telégrafo, rádio, televisão, telefone, Internet, até chegar ao celular, um dispositivo para comunicação
que pode ser levado a qualquer lugar (DIAS, 2003).
“Mobilidade é o termo utilizado para identificar dispositivos que podem ser operados a
distância ou sem fio. Dispositivos que podem ser desde um simples BIP, até os mais modernos
Pocket PCs.”( NETTO, 2007).
9
Dispositivos que permitem comunicação e acesso a informação são tecnologias que sempre
foram desejadas, principalmente pela grande diversidade de aplicações e benefícios que oferecem,
auxiliando na eliminação do papel em processos comerciais e também ajudando no gerenciamento
de compromissos e contatos (SIQUEIRA, 2007).
A partir da invenção dos primeiros dispositivos móveis, os coletores de dados que eram
utilizados nos anos 80, houve um grande investimento nessa área, paradigmas foram quebrados,
chegando a uma variedade de tipos de dispositivos que existem no mercado, conforme relaciona
Lee (2005):
• Dispositivos pager: Um dos primeiros dispositivos de comunicação móvel a se popularizar. O
pager é um dispositivo eletrônico bastante simples, utilizado para contatar pessoas que
normalmente precisam estar acessíveis, permitindo que possam ser chamadas a qualquer
instante, como médicos. Para chamar um pager, é utilizado um serviço de telemensagem, que é
disponibilizado por um provedor.
• Tablet PC: Um Tablet PC é um computador de uso geral integrado a uma tela interativa, onde
os usuários podem escrever usando uma caneta. De certo modo, um Tablet PC pode ser
considerado uma espécie de PDA, por permitir que se escreva no equipamento, mas apesar
disto, possui outras diversas características que o diferenciam bastante de um PDA, como disco
rígido e sistema operacional mais poderoso.
• Personal Digital Assistants (PDA ou Handhelds): O termo PDA (Personal Digital Assistant)
ou Assistente Pessoal Digital foi elaborado pela Apple Computer Inc. Com o desenvolvimento
de CPUs(Central Processing Unit) mais poderosas e maior capacidade de memória, os PDAs
passaram a possuir funções como correio eletrônico, acesso à Internet, jogos, aplicações
personalizadas, redes sem fio, câmeras, modem, tela colorida, entre outros inúmeros softwares
disponíveis, para as mais diversas áreas de interesse. Os PDAs, comercialmente estão divididos
em duas principais famílias, os PalmOne que utilizam sistema operacional PalmOS da
PalmSource e os Pocket PCs que utilizam sistema Windows Mobile.
• Telefones celulares: Pode-se encontrar no mercado uma variedade de celulares, destinados a
todos os tipos de usuários. Além dos serviços básicos de telefonia, hoje se pode contar com
celulares que possuem correio eletrônico, MMS (Multimedia Messaging Service), SMS (Short
10
Message Service), EMS (Enhaced Messaging Service), Rádio FM (Frequency Modulation),
Câmera, Flash, jogos, acesso à Internet e telas coloridas.
• PCs laptop: Um Notebook ou PC laptop, lap (colo) e top (em cima) significando computador
portátil, é um computador móvel de uso geral, com uma grande tela integrada, mouse
(geralmente um trackpad, área onde se desliza o dedo), e teclado (WIKIPEDIA, 2007b). O
laptop pretende ser uma versão móvel e completa de um computador pessoal, contendo todos os
seus recursos.
2.2.1 Pocket PC
O Pocket PC é um PDA ou computador de mão, que tem como sistema operacional o
Windows CE ou Windows Mobile. Este dispositivo possui diversas capacidades iguais aos
Notebooks, como conectar-se à Internet, câmera digital integrada de até 2MP, execução de mp3 e
vídeos; diversas formas de conexão (serial, infravermelho, USB e bluetooth), jogos, e-mail e
autenticação biométrica (HP, 2007c). Permite também a integração com outros dispositivos como
impressoras, leitores de códigos de barras e receptores GPS (Global Positioning System).
Existem aplicações para Pocket PCs que executam as mais variadas tarefas, as aplicações
podem ser tanto gratuitas como desenvolvidas sob medida. É possível utilizar em um Pocket PC
programas como Microsoft Outlook, Word, Excel, Internet Explorer e outros recursos de
reprodução multimídia. São exemplos práticos de aplicações desenvolvidas para este dispositivo,
que solucionam problemas de nosso cotidiano:
• Em São Paulo os Palm Tops já estão sendo utilizados na Área Azul, auxiliando a
emissão das notificações e segundo Paulo Luqueti (Diretor da Abramcet) esta ferramenta
oferece mais eficiência e comodidade. Segundo a CET (Companhia de Engenharia de
Tráfego) outra vantagem, em tempo de aquecimento global, é a “despapelização”
promovida pelo uso dos Palms, já que o processamento é totalmente eletrônico. Ainda,
isso elimina a possibilidade de erros de transcrição, fraudes e sujeiras nas ruas, além de
reduzir o tempo necessário para lavrar a multa (PIRES, 2008).
• O IBGE (Instituto Brasileiro de Geografia e Estatística) forneceu a seus recenseadores
Pocket PCs para auxiliarem o Censo de 2007. Pela primeira vez, blocos de papel foram
substituídos por computadores de mão. O PDA foi adaptado para agüentar qualquer
11
situação, foi desenvolvida uma capa com revestimento azul, padronizada, de borracha,
que evita perdas e facilita o encaixe na palma da mão. Há ainda um segundo
revestimento, interno, também de borracha que veda o aparelho e o deixa impermeável,
conforme mostra a Figura 1. A caneta também sofreu modificações, fica presa ao
aparelho por uma corda de nylon. As baterias, especiais, 1900mAh são recarregadas
diariamente. A base é um Pocket PC MIO P550, rodando Windows Mobile 5. O
software desenvolvido é dividido em etapas, que devem ser preenchidas corretamente
para poder passar ao próximo item. Mesmo sendo um questionário grande, as entrevistas
são feitas em poucos minutos, graças a tela touchscreen. O envio das informações para a
central do IBGE é feito via wi-fi ou dial-up, conforme a infra-estrutura da região. O
dispositivo também tem GPS, especialmente útil em zonas rurais. O mais interessante
será o processamento dos dados, que graças a eliminação do papel, a contagem,
tabulação e divulgação dos resultados serão muito rápidas. Antes este trabalho levava
cerca de 3 a 5 anos, que além de demorado, podia levar a imprecisões e erros. Quando os
resultados eram divulgados, já estavam totalmente desatualizados (KUNZE, 2008); e
Figura 1. PDA utilizado pelo IBGE no Censo 2007. Fonte: Adaptado de POCKETPT (2008).
• Distribuidores da AMBEV já utilizam PDAs para coleta de pedidos, desde 2001. O que
confere grande agilidade na entrega dos mesmos em bares, restaurantes e
estabelecimentos afins (KUNZE, 2008).
12
Para que um PDA possa ser considerado um Pocket PC, precisa ter um sistema operacional
Windows; possuir um conjunto predefinido de aplicações instaladas na ROM (Read Only Memory);
possuir uma tela sensível ao toque; touchpad (teclas direcionais) e um conjunto de teclas de atalho
(SIQUEIRA, 2007).
Os Pocket PCs são desenvolvidos principalmente pela HP, pela Motorola e pela Palm. As
medidas e capacidades variam bastante para cada empresa. Hoje podem ser encontrados Pocket PCs
com apenas 11,5mm de espessura e pesando somente 114g. Em geral, as medidas variam de 109
mm x 58 mm x 11,5 mm até 116 mm x 68,9 mm x 23,7 mm e o peso fica entre 114g e 160g. A
freqüência dos processadores também varia desde 200 até 650 MHz. A memória RAM costuma
chegar aos 64MB enquanto a ROM aos 256MB. As baterias mais modernas, de lítio, podem chegar
aos 1900mHa com até 5 horas de duração em conversa ou 200 horas em standby. Em alguns
modelos a resolução da tela pode chegar a 640x480 (PALMBRASIL, 2008).
2.2.2 Windows Mobile
O Windows Mobile, anteriormente chamado como Windows CE, é um sistema operacional
da Microsoft, bastante compacto, desenvolvido para rodar especificamente em dispositivos móveis
como Pocket PC, Smartphones e aparelhos multimídia em geral. Este sistema fornece dispositivos
para pessoas comunicarem-se, trocarem informações e acessarem a Internet. Permite que se
executem praticamente todas as mesmas tarefas que são executadas em versões Windows
designadas a computadores pessoais, mas apesar da semelhança, são totalmente diferentes. Só
rodam no Windows Mobile programas produzidos especificamente para este sistema operacional
(WIKIPEDIA, 2007d; WILSON, 2007).
2.2.2.1 Recursos
No Windows Mobile, existem diversos recursos como, por exemplo, (WIKIPEDIA, 2007d):
• Tela today screen mostra o dia de hoje, informações do dono, anotações, novos e-mails e
tarefas em execução. Programas podem ser instalados, podem também adicionar itens na
tela Today screen. Também inclui uma barra de notificação que tem ícones para notificar o
status do Bluetooth;
• O papel de parede pode ser personalizado ou temas podem ser baixados pelo computador e
sincronizados para o Pocket PC;
13
• A barra de tarefas mostra a hora atual, o volume e o status da conectividade atual;
• O botão Iniciar é bem parecido com os das versões anteriores do Windows, com os mesmos
recursos do menu do Windows XP;
• O Microsoft Office das versões Pocket PC estão incluídas no Windows Mobile; e
• O Windows Media Player 10.0 para o Windows Mobile suporta grande parte dos formatos
de multimídia existentes.
2.2.2.2 Versões O Windows Mobile já passou por diversas versões, dentre elas:
• 2003 - com duas versões, uma inicial e uma versão Second Edition (segunda edição);
• 5.0 - com uma inovadora memória persistente, “que é um novo tipo de memória RAM (Random
Access Memory), onde mesmo que a bateria fique totalmente descarregada os dados contidos na
RAM não são perdidos” (WIKIPEDIA, 2007d). Nesta versão, o PowerPoint também foi
incluído, além de outras ferramentas usadas nas versões desktop, como inserção de tabelas e
imagens; e
• 6.0 - Já foi entregue aos fabricantes e está sendo comercializada. Esta versão possui Windows
Update, Windows Media 11, criptografia de arquivos (nos cartões de expansão), System cache,
integração com aplicações Office (WINCEBRASIL, 2008).
Além das versões já lançadas, na versão 5.0 o sistema possui características particulares ao
dispositivo para o qual será designado, relacionadas da seguinte maneira (BORGES JUNIOR,
2005).
Windows Mobile Pocket PC – é uma versão própria aos Pocket PCs, que permite controlar
contatos, agenda, anotações, reproduzir musicas e vídeos, enviar e receber e-mails.
Windows Mobile Pocket PC Phone – versão própria aos handhelds integrando funções de
telefonia como, por exemplo, discar a uma pessoa de sua lista de contatos, enviar SMS e navegar
pela Internet.
Windows Mobile Smartphone – programas específicos a Smartphones, os programas
desenvolvidos para este sistema, em geral são incompatíveis com outras versões do sistema. O
sistema possui funções de PDAs além de funções destinadas a telefonia celular. A Microsoft já
14
alterou o nome do sistema diversas vezes, e muitas das versões anteriores são incompatíveis, ou
voltadas para modelos específicos, como Windows CE para processadores RISC, etc.
(PALMBRASIL, 2007).
Na versão 6.0, conforme Silva (2008), as categorias foram redefinidas para:
Windows Mobile 6 Classic – assistentes pessoais, sem comunicação telefônica móvel, entretanto
podendo contar com Wi-fi, bluetooth e GPS. Estes são equipamentos cada vez mais raros;
Windows Mobile 6 Professional – diferem-se do Classic por ser ter incorporado um rádio
GSM/GPRS/3G, capaz de providenciar comunicação de voz e dados;
Windows Mobile 6 Standard – assim como o modelo Professional possui comunicação de voz e
dados, mas tem como diferencial a ausência de ecrã táctil (tela sensível ao toque). Equipamento
totalmente operado por botões, teclas e comandos de voz.
O Windows Mobile permite a troca de dados com programas do Windows para PC. Para isto
faz-se necessário a utilização de um software, o ActiveSync, o qual possui recursos que permitem
converter arquivos da versão desktop para a versão Pocket PC (WILSON, 2007; WIKIPEDIA,
2007d).
O ActiveSync é um software que permite a ligação entre um computador pessoal e um PDA,
onde ambos possuam sistema operacional Windows. A partir da sincronização, este programa
permite a transferência de arquivos entre os dispositivos, fazendo a conversão dos arquivos para
formatos compatíveis, quando necessário (WIKIPEDIA, 2007d).
2.2.3 Considerações
A tecnologia se desenvolveu tanto, que atualmente os dispositivos móveis são ferramentas
essenciais para diversas empresas. Além da grande diversidade de dispositivos existentes, as suas
características são as mais variadas: “... telas coloridas e conexões wireless. São cada vez mais
utilizados para receber, ler e enviar e-mails e outros tipos de mensagens; executar aplicações de
vendas ou as aplicações próprias dos profissionais que viajam muito e necessitam conectar-se em
tempo real às informações corporativas, remotamente...” (HP, 2007a).
Os dispositivos apesar de possuírem grandes tecnologias agregadas, possuem recursos
limitados, já que a falta de espaço é um fator considerável. Dispositivos como PDAs, Celulares e
15
SmartPhones são, normalmente, dotados de uma quantidade relativamente baixa de memória,
energia limitada a uma bateria, com duração limitada a horas ou dias; possuem conexão
intermitente, que pode cair a qualquer momento; tela reduzida; poder de processamento
relativamente baixo além de outras características.
2.3 Programação Móvel
Conforme Siqueira (2007), ao contrário de programação para desktop, o desenvolvimento de
sistemas para dispositivos portáteis deve considerar diversos detalhes de hardware; e limita-se a
certo número de linguagens de programação.
Fatores como processamento, capacidade de memória, capacidade de armazenamento de
dados e suprimento de energia, devem ser considerados, visto que podem influenciar nos resultados
do projeto de um sistema, tornando-o viável ou não.
Um fator que exemplifica a influência das capacidades de hardware dos PDAs, no
desenvolvimento de sistemas, é o fato de não possuírem memória virtual, levando o programador a
tratar esta necessidade. A capacidade de armazenamento de memória também deve ser considerada,
apesar da capacidade ter aumentado bastante nos últimos anos, a oferta ainda é pequena, quando
comparada a dos desktops. Desta forma, dependendo da aplicação que será desenvolvida, muitas
vezes nem caberá na memória do dispositivo, obrigando o uso de estratégias de filtragem/escolha de
dados, e/ou recuperação on-demand de certas informações, explica Mendonça (2007). Ainda, pela
limitada capacidade de armazenamento de energia, os sistemas devem estar atentos à possibilidade
de uma queda de energia, tratando os dados para que não se percam.
Neste tópico será abordada a tecnologia de desenvolvimento de sistemas para dispositivos
móveis Plataforma .Net. Esta é uma das principais tecnologias existentes, que fornece todas as
ferramentas necessárias ao desenvolvimento de sistemas destinados a estes dispositivo. Além desta
tecnologia que foi estudada, existem outras com maiores limitações. Conforme exposto por
CRISPIM JUNIOR (2006) e SIQUEIRA (2007) pode-se citar:
SuperWaba: Plataforma semelhante ao Java, utiliza máquina virtual e bibliotecas Java. Possibilita
o desenvolvimento de aplicações para PDAs e Smartphones. Conforme explica CRISPIM JUNIOR
(2006): “No kit de desenvolvimento desta ferramenta estão presentes uma máquina virtual,
16
bibliotecas básicas e de extensão, ferramentas de compilação e instalação dos aplicativos, exemplos
e documentação.”.
Ns Basic: Ferramenta proprietária que permite desenvolvimento de aplicações locais, em Basic.
Aplicações para dispositivos Palm, Newton e Windows CE (Compact Edition).
Microsoft Embedded Visual Tools: Conjunto de ferramentas que permitem o desenvolvimento de
aplicações para dispositivos móveis em diversas linguagens. A partir de suas versões Microsoft
Embedded Visual C++ e Microsoft Embedded Visual Basic fornece emuladores, ferramentas
remotas e a documentação necessária ao desenvolvimento de aplicações destinadas a dispositivos
que utilizem sistema operacional Microsoft Windows CE.
AppForge Mobile VB: é uma API (Application Programming Interface) AFC (AppForge
Crossfire), que integra Microsoft Visual Basic e Studio .Net.
Plataforma Symbian OS: É um sistema operacional para celulares. Aplicações desenvolvidas em
C++ através de APIs específicas. Tem uma arquitetura em cinco camadas.
J2ME: Java 2 Micro Edition é a edição do Java para ser usada em dispositivos móveis como
celulares, pagers, PDAs e Palms. Este pacote não se trata de um novo Java, apenas adapta sua
plataforma para que execute em dispositivos portáteis (CRISPIM JUNIOR, 2006).
Programas desenvolvidos para J2ME podem ser executados sem problemas nas edições
J2SE e J2EE, contanto que suas APIs estejam presentes.
Esta plataforma busca unir um conjunto de conceitos para uniformizar o desenvolvimento
em pequenos dispositivos, deixando transparente ao desenvolvedor todos os detalhes de tal
desenvolvimento, desde a arquitetura até o sistema operacional (DIAS, 2003).
O J2ME é dividido em configurações. A configuração CLCD (Connected Limited Device
Configuration) é destinada a dispositivos com memória de 512K ou menos, e que possuam conexão
com redes instáveis. Essa configuração utiliza a máquina virtual KVM (Kilobyte Virtual Machine),
que é uma versão destinada a dispositivos com limitação de recursos. Outra configuração, a CDC
(Connected Device Configuration) é destinada a dispositivos de maior porte, com mais de 512K de
memória, conexão de dados permanente com alta taxa de transmissão e utiliza a JVM (FILHO,
2002).
17
2.3.1 .Net Compact Framework
O .NET Compact Framework é a plataforma de desenvolvimento para Smart Devices da
Microsoft .NET. Este framework permite desenvolvimento de aplicações clientes em dispositivos
que utilizem sistema operacional Windows CE ou Windows Mobile. Permite o desenvolvimento
utilizando código gerenciado; XML WebServices; download e execução, com segurança, de
aplicações para PDAs, telefones celulares e outros afins (VENTURI, 2005; MOHR, 2004).
Por ser um subconjunto do .NET Framework, esta plataforma permite a utilização de
conhecimentos de programação já existentes nas linguagens Visual Basic.Net ou Visual C# além da
utilização de códigos existentes em outros dispositivos. Assim, qualquer desenvolvedor que já
conheça o Visual Studio .NET e já tenha desenvolvido aplicações Windows ou ASP.NET pode criar
sistemas para dispositivos móveis (VENTURI, 2005; BORGES JUNIOR, 2005).
Para dispositivos mais poderosos e que possuam suporte, pode-se desenvolver aplicações
gráficas, jogos e formulários, necessitando apenas instalar um SDK MMIT (Microsoft Mobile
Internet Toolkit) (RAMOS, 2004).
Possui também uma FCL, bem mais compacta que a existente na versão completa do .NET
Framework, mas não menos limitada. Uma implementação da CLR bem mais eficiente, preparada
para suportar aplicações no contexto de pequenos dispositivos (VENTURI, 2005; GALVIN, 2004).
A alta performance do Compact Framework merece destaque. Foi projetado para trabalhar
com recursos limitados, o que é a realidade dos dispositivos compactos. Toda a eficiência é produto
do aproveitamento dos recursos sem desperdiçá-los (VENTURI, 2005; GALVIN, 2004).
2.4 Plataforma .NET
.NET ou dot-net é uma plataforma de desenvolvimento de softwares criada pela Microsoft.
Esta plataforma conecta informações, sistemas, pessoas e dispositivos, através de diversas
tecnologias. O .Net foi criado para unificar o desenvolvimento de aplicações, permitindo que um
sistema seja desenvolvido tanto em VB.NET quanto C# , J# ou em outra linguagem, também em
um único, ou em diferentes softwares de desenvolvimento, desde que sejam compatíveis com as
especificações do framework. Tudo isto porque o aplicativo desenvolvido será executado sobre a
plataforma .NET e não mais sobre o sistema operacional (CÂMARA, 2005; COMQUEST, 2007).
18
Conforme ALEXANDER (2002), framework é uma plataforma para desenvolvimento de
softwares. Ela oferece diversas bibliotecas de classes com serviços básicos; ferramentas para
projetar, criar e testar aplicações, arquivos e serviços; oferece diversos recursos para
desenvolvimento, entrada e saída de arquivos e banco de dados. As aplicações desenvolvidas, não
são compiladas em código nativo da máquina, e sim em uma linguagem intermediária, que é
executada sobre a plataforma. A plataforma encarrega-se de fazer o meio campo entre a aplicação e
o sistema operacional. É a plataforma que controla os tempos de execução e gerencia o código. Os
recursos, serviços e tipos de dados são fornecidos pela plataforma durante a execução de um
sistema.
No .NET o desenvolvimento de aplicações tem como auxílio uma biblioteca de classes,
interfaces e tipos, chamada Framework Class Library (FCL) ou Base Class Library (BCL) que
contempla diversos componentes reutilizáveis, poupando os programadores do retrabalho. Esta FCL
está disponível a todas as linguagens .NET (CONCEIÇÃO, 2004; VENTURI, 2005).
A plataforma .NET trata o código gerado de uma maneira diferente do convencional.
Sempre que o dispositivo acessa o framework, um código (linguagem de marcação) é construído e
adaptado ao dispositivo destinatário (CRISPIM JUNIOR, 2006; MICROSOFT CORPORATION,
2001b).
Esta ferramenta foi desenvolvida sobre padrões de WebServices XML, onde é possível a
interação de informações entre os diversos sistemas, plataformas e dispositivos, ou entre as
linguagens de programação utilizadas (NETTO, 2007; HADDAD, 2004).
2.4.1 MSIL
MSIL (Microsoft Intermediate Language), ou simplesmente IL é um código fonte
intermediário, um tipo de “linguagem de máquina”. Todo o código fonte de programas escritos em
uma linguagem compatível com a plataforma .NET, quando compilado, deve ser convertido para o
MSIL e não para o código nativo da máquina (MOHR, 2004; CONCEIÇÃO, 2004).
Segundo Venturi (2005), quando um compilador gera um MSIL, este fica em um arquivo
chamado Managed Module, que são informações que descrevem os tipos de dados e suas
dependências, objetos e seus membros, referências e outros dados do código, que são usados em
tempo de execução. Este módulo gerenciável é um windows PE (Portable Executable).
19
Conforme explica Conceição (2004), um PE é formado por quatro partes, são elas:
• PE Header – cabeçalho padrão;
• CLR Header – cabeçalho para uso do CLR;
• Metadata – metadados contendo tabelas de descrições de tipos e referências para outros
módulos; e
• Managed code – linguagem MSIL.
Nesta linguagem estão presentes instruções para uso do CLR, como instruções de carga,
armazenagem, inicialização e métodos de chamadas a objetos, independente do processador e
sistema operacional onde os programas .NET foram compilados. É o MSIL que possibilita a
verdadeira integração entre várias linguagens (VENTURI, 2005).
2.4.2 CLR
O Common Language Runtime é a parte da plataforma .NET responsável pela execução dos
programas, também conhecido como "motor de execução" do .NET. “O CLR está para a plataforma
.NET assim como a Java Virtual Machine está para a plataforma Java.”(D’IPPOLITO, 2004). A
CLR compila o MSIL para código de máquina, em um aplicativo único. Para isto, fornece serviços
de suporte às aplicações (runtime services), um ambiente de execução que gerencia a execução do
código e fornece serviços como tratamento de erros, segurança, coleta de lixo e controle de versão
(CONCEIÇÃO, 2004).
Internamente ao CLR existe o CTS (Common Type System) que é um sistema de tipos
comuns, responsável pela compatibilidade entre as classes, permitindo a interoperabilidade dos
tipos entre diferentes linguagens.
Quando o código MSIL é executado, a CLR entra em ação e executa determinadas tarefas
como, carregar o código e alocar e liberar memória. As classes já carregadas são compiladas através
da tecnologia JIT (Just-In-Time) para código nativo da máquina. Segundo CONCEIÇÃO (2004) “o
JIT só compila os métodos na medida em que a aplicação pedir e somente se o código já não tenha
sido compilado”.
A CLR oferece diversas vantagens à plataforma .NET, pois proporciona um
desenvolvimento rápido, já que geralmente grande parte do código que seria escrito pelo
desenvolvedor, já vem implementada na execução. Além desta vantagem, o controle das aplicações
20
em tempo de execução merece destaque, desta maneira a carga da memória utilizada é gerenciada,
limpando os lixos da memória, quando existentes (RICHTER, 2002).
Segundo Venturi (2005), a CLR tem como principais características:
• Compilação da MSIL para código nativo da plataforma onde está sendo executado;
• Gerenciamento de memória, incluindo garbage collection;
• Verificação e reforço de restrições de segurança no código em execução; e
• Carregamento e execução de programas, com controle de versão e outras características.
2.4.3 CLS
A CLS (Common Language Specification) armazena as especificações da plataforma .NET.
Nestas especificações, os desenvolvedores de compiladores podem encontrar informações como
armazenamento de tipos de dados e objetos, o que os auxiliará no desenvolvimento destes
aplicativos, para que possam gerar o MSIL, tornando assim, seus programas compilados,
compatíveis com o .NET (VENTURI, 2005; MOHR, 2004).
2.4.4 MONO
A plataforma .NET também está sendo implementada em um projeto de código aberto,
através de uma iniciativa da comunidade ‘Software Livre’. O Mono, que visa permitir a execução
de sistemas .NET multiplataforma, em sistemas operacionais GNU/Linux, Unix, MacOS X é um
projeto liderado pela empresa Novell, criado em 2001. Ele envolve um compilador da linguagem
C#; um compilador JIT para CLR e uma suíte de bibliotecas de classe (D’IPPOLITO, 2004).
A criação deste projeto permite que os programas desenvolvidos em .Net possam ser
executados em qualquer plataforma suportada pelo Mono.
Nem tudo está portado para Mono, alguns recursos do .NET ainda não estão disponíveis.
Para solucionar esta questão, alguns projetos estão em andamento, alguns para o desenvolvimento
do framework e outros para aplicações específicas. O MONO Basic é um exemplo, um compilador
.NET que é desenvolvido por uma comunidade brasileira, Mono Brasil (GIARETTA, 2004;
MONOBRASIL, 2007).
21
2.4.5 DotGNU Portable .NET
DotGNU Portable .NET é um projeto que, assim como o Mono, foi criado com o objetivo de
tornar o .NET multiplataforma. Em aplicações gráficas, usando Windows Form, este projeto está
mais avançado que o Mono, porém em aplicações Web está bem atrasado.
O mecanismo de execução de aplicativos .NET, CLR, é o mesmo utilizado no Mono e no
DotGnu Portable .NET (GIARETTA, 2004).
2.4.6 C#
C# (pronuncia-se “C Sharp”) é uma linguagem de programação orientada a objetos, criada
pela Microsoft. Ela surgiu com a criação da plataforma .Net. Foi criada para ser a principal
linguagem de programação da plataforma. O C# possui uma sintaxe baseada na linguagem C, foi
criada com o objetivo de ser uma linguagem de fácil utilização, integrando as possibilidades de
programação do C++ com a alta produtividade do Visual Basic (D’IPPOLITO, 2004; MICROSOFT
CORPORATION, 2001a).
No C#, todas as variáveis e código são declarados no escopo de classes. Esta linguagem
possui tipagem forte, onde as enumerações são tipos próprios; possui tipos lógicos; inteiros; ponto
flutuante; tipo para caracteres unicode; estruturas de dados; arrays (somente dinâmicos);
mecanismo para tratamento de erros; opções mutuamente exclusivas (switch); tipos de looping e
condição, inclusive foreach, que é oriundo do C, usado para varrer todos os elementos de um array
ou coleção. Nesta linguagem, a maioria das variáveis é inicializada com zero e testada antes da sua
utilização (DAMASCENO JÚNIOR, 2001).
O C# é um C++ limpo, com várias boas idéias comuns em outras linguagens e algumas
novas, como boxing , delegates , garbage collection e attributes (D’IPPOLITO, 2004).
2.5 XML
XML é uma metalinguagem, ou seja, uma linguagem que permite a criação de outras
linguagens a partir dela. (BORGES JUNIOR, 2005). Com a utilização do XML é possível
armazenar dados, independentemente da plataforma adotada, considerando-se então, uma
linguagem de marcação, que segue o padrão SGML (Standard Generalized Markup Language)
assim como o HTML (SCRIBNER, 2002).
22
Esta linguagem surgiu para permitir que houvesse uma comunicação padronizada entre os
dispositivos navegadores, computadores e aplicativos. Foi criada utilizando-se o melhor do HTML
e do SGML, além de outras características. Além da comunicação, o XML permite a inclusão de
alvos de ligação na instância atual, bastante sofisticados, possibilitando a existência de documentos
de composição. Documentos compostos por fragmentos de outros documentos, que são
automaticamente montados, para assim, exibirem um determinado conteúdo (BORGES JUNIOR,
2005).
Em XML não é possível armazenar informações de renderização visual, apenas dados e
informações sobre os dados. Ele define uma sintaxe genérica que dá forma e significado à
informação. As tags devem ser definidas pelo desenvolvedor, com as nomenclaturas e significados
que a aplicação exigir.
2.6 SOAP
Simple Object Access Protocol (SOAP) é um mecanismo simples, leve e padronizado para
troca de XML entre cliente e servidor, em ambientes distribuídos. Através do SOAP serviços Web
podem ser chamados (JUNGES, 2006).
Um serviço que é chamado na Web, talvez esteja sendo executado em um processador e
sistema operacional incompatíveis com aquele onde o solicitante está executando. Para fazer isto
funcionar, o cliente e o servidor devem implementar um protocolo comum. O SOAP é este
protocolo, que empacotando XML manipula a codificação e decodificação dos dados trocados entre
cliente e servidor (ALEXANDER, 2002).
Conforme Neto (2003), em relação a outros protocolos, “... a vantagem do SOAP é que as
mensagens são embutidas em requisições http (Hyper Text Transfer Protocol), permitindo que elas
penetrem facilmente pelos firewalls.”.
Tanto a chamada de um método publicado em um WebService quanto a resposta recebida,
são encapsuladas em um envelope SOAP, composto por três partes, conforme citado por Pontes
(2003) e exposto pela Figura 2:
• Envelope: Define um modelo padrão para descrever o conteúdo de uma mensagem e
como processá-la. Elemento raiz que encapsula o Header e Body;
23
• Header: Um conjunto de regras para expressar instâncias de tipos de dados definidos
por uma aplicação. Parte opcional do envelope, carrega informações necessárias que
não estão presentes na assinatura do método; e
• Body: O elemento mais importante. Armazena o método e seus parâmetros,
armazenados como XML (D’IPPOLITO, 2004).
Figura 2. Envelope SOAP. Fonte: Adaptado de PONTES (203).
A Figura 3 demonstra como é definido um envelope SOAP que efetua uma requisição,
enviando um valor a ser convertido de decimal para binário. O corpo deste envelope é formado
inicialmente pelo cabeçalho do envelope. O cabeçalho do método também está incluído na
requisição, apesar de não ser obrigatório. No cabeçalho do método são enviados usuário e senha
para autenticação. Após os cabeçalhos é apresentado o corpo, onde é efetuada a chamada do
método, enviando os parâmetros necessários.
24
Figura 3. Envelope de requisição SOAP. Fonte: Adaptado LEOPOLDO (2008);
2.7 WebServices
A troca de informações entre sistemas sempre foi um grande problema, visto que os sistemas
são desenvolvidos nas mais diversas linguagens de programação, para inúmeras plataformas. A
comunicação entre os diferentes sistemas era dificultada pela falta de um padrão comum de
comunicação. Com o objetivo de atender a esta necessidade foi desenvolvido o conceito de
WebServices, fornecendo uma tecnologia que possibilita a comunicação entre diversos sistemas,
através de um padrão comum, utilizando XML, que é independente da linguagem de programação,
e utiliza a Internet para transferências de dados.
Segundo Pontes (2003), em definição, WebService é uma aplicação servidora, disponível na
Internet, cuja interface é desenvolvida e publicada de acordo com o padrão SOAP. Esta aplicação
permite a integração entre diversos sistemas, oferecendo um serviço que usa HTTP; possibilita
aplicações clientes acessarem seus serviços, sem preocupação de como ou em que plataforma o
serviço foi desenvolvido; fornece um mecanismo de transporte para enviar as requisições e receber
resultados.
Conforme Neto (2003), os WebServices utilizam protocolos padrões como HTTP e SOAP,
disponíveis a qualquer plataforma, diferentemente das tecnologias anteriores, que utilizavam
protocolos específicos como DCOM (Distributed Component Object Model), RMI (Remote
Method Invocation) ou IIOP (Internet Inter Operability Protocol).
25
WebServices trouxeram outros benefícios e possibilidades para o desenvolvimento e
integração dos sistemas distribuídos. Nos sistemas Web como também nos sistemas desktop, grande
parte dos códigos acaba se repetindo, o que significa um desperdício de tempo e mão de obra.
WebService permite reduzir este desperdício, otimizando e integrando as aplicações através da
reutilização do código.
Esta tecnologia utiliza o mesmo conceito das funções que são utilizadas em um programa
convencional, funções que podem ser acessadas em diversos momentos e executam determinada
tarefa, porém, de forma distribuída, independente de plataforma ou implementação, permitindo
assim integração entre sistemas que rodam em diversas plataformas ou desenvolvidos em diversas
linguagens (HADDAD, 2001; SCRIBNER, 2002).
O WebService não possui interface, pois é um conjunto de métodos (Web Methods) que
encontram-se localizados em qualquer lugar remoto de qualquer servidor, métodos organizados de
forma padronizada. A comunicação entre a aplicação e o WebService é feita via protocolo SOAP,
utilizando XML, assim transportado e interpretado na aplicação que o solicitou (HADDAD, 2001;
D’IPPOLITO, 2004).
Através do XML as aplicações acessam ou “consomem” o serviço, que executa a tarefa e
retorna a resposta em outro XML. Por utilizar XML os WebServices não ficam presos a
determinada plataforma ou linguagem, o que permite a integração entre as aplicações
(CEMBRANELLI, 2003).
Webservice é uma tecnologia baseada em um padrão de arquitetura. Service-oriented
architecture (SOA) é uma arquitetura que possui um conceito bem simples, o que o torna aplicável a
um grande número de situações por meio dos WebServices. Esta arquitetura é formada por:
• Provedor de Serviço, que é responsável por criar a descrição de um serviço, publicá-
lo e receber as chamadas dos requisitores;
• Requisitor de Serviço é o responsável por encontrar a descrição de um serviço
publicado;
• Registrador de Serviço é o responsável por divulgar as descrições de serviços
publicados pelo Provedor de Serviços e também por permitir que o requisitor procure
26
um serviço qualquer na lista de descrições. Funciona como um mediador entre o
requisito e o provedor; e
• Pilhas de Interoperabilidade é o conceito utilizado para facilitar o entendimento e a
construção de Webservices, já que estes utilizam uma variedade de tecnologias de
acesso e integração, tais como XML, SOAP, WSDL, UDDI, WSEL e WSFL
(BORGES JUNIOR, 2005).
Como vantagens da utilização dos WebSercices, Neto (2003) destaca:
• Interoperabilidade: possibilidade de dois ou mais sistemas trocarem informações e
interagirem entre si;
• Integração: possibilidade de integrar aplicações, presentes em diferentes plataformas
e que utilizem diferentes tecnologias, permitindo unir programas formando uma
aplicação composta;
• Eficiência de Implementação: facilitando interoperabilidade entre sistemas, facilita a
incorporação de novos módulos a uma solução. Oferece agilidade na adição de novos
métodos disponíveis a diferentes sistemas;
• Reciclagem do Código: para aplicações baseadas em componentes, esta tecnologia
oferece uma grande facilidade de reutilização dos componentes; e
• Modularidade: oferece uma arquitetura plug-and-play, que facilita a criação de
módulos externos a aplicação principal.
2.8 Considerações
Após analisar a grande variedade de dispositivos móveis presentes no mercado, bem como
suas diversas capacidades, recursos e possibilidades de aplicações; também após analisar as
tecnologias para desenvolvimento de softwares, percebeu-se que o Pocket PC, aliado ao sistema
desenvolvido, oferece uma solução completa para as atuais necessidades do Serviço Autônomo
Municipal de Terminais Rodoviários de Blumenau, na questão da emissão das notificações de
regularização em Área Azul.
27
3 DESENVOLVIMENTO
Nesta seção são descritos diagramas de caso de uso, diagramas de atividades, diagramas de
classes de domínio, diagrama de componentes, diagrama de implantação, XML Schema e diagrama
ER, baseados na UML e os requisitos do sistema proposto. Também é descrita a implementação do
sistema relacionando toda a codificação, desenho de telas configuração de ambiente e banco de
dados. Ao final desta seção são detalhados também a avaliação, os testes e os resultados obtidos.
Para desenvolvimento do software proposto neste projeto, foi utilizada a linguagem C#
sobre plataforma .NET. Todo o desenvolvimento foi realizado com a utilização da IDE (Integrated
Development Environment) da Microsoft Visual Studio 2005. O Visual Studio não permite apenas
a edição dos códigos fontes em C#, mas também o desenho dos formulários, compilação do sistema
e permite ainda que o sistema desenvolvido seja testado em um emulador de Pocket PC.
O software foi produzido para ser utilizado em Pocket PCs, os quais possuem sistema
operacional Windows Mobile.
Além do sistema que faz a emissão das notificações, foram desenvolvidos três WebSites e
um WebService, todos desenvolvidos a partir da mesma tecnologia.
O WebService é o componente responsável pelo gerenciamento das notificações, esta parte
da solução fica disponível na Web e fornece serviços tanto para o sistema que emite notificações
quanto para os WebSites.
Os WebSites demonstram a utilização do WebService, oferecendo soluções necessárias ao
funcionamento da Área Azul.
O envio das notificações emitidas para Banco de Dados é feito por meio de um serviço
presente no WebService. A comunicação utiliza XML via tecnologia de empacotamento e
transmissão SOAP.
28
3.1 CARACTERIZAÇÃO DO DOMÍNIO DA APLICAÇÃO
Este projeto descreve o desenvolvimento de uma aplicação destinada ao Serviço Autônomo
Municipal de Terminais Rodoviários de Blumenau (SETERB), que controla a Área Azul na cidade
de Blumenau.
O sistema aqui projetado auxilia agentes de trânsito no preenchimento das notificações de
regularização. Os agentes de trânsito usando um Pocket PC podem acessar este sistema para
controlar a emissão das notificações.
Para preenchimento de uma notificação, é necessário informar os dados do veículo que
cometeu uma irregularidade e dados da notificação que está sendo gerada. Todo o cadastro de
veículos e de notificações é facilitado, por meio da utilização de componentes de programação e
informações previamente existentes nos campos dos formulários. Toda entrada de dados incorreta
pode ser corrigida, assim que identificada pelo usuário. O sistema é dotado de tratamentos que
verificam o cadastro de informações inconsistentes ou inexistentes.
Ao finalizar o preenchimento da notificação o agente de trânsito imprime esta notificação,
por meio de uma mini-impressora própria para Pocket PCs, conectada ao dispositivo e presente no
local. Esta notificação impressa deve ser afixada ao veículo infrator, para que seu responsável tome
as devidas providências, regularizando sua situação.
Todas as notificações que forem cadastradas neste sistema permanecem ali armazenadas por
tempo indeterminado. Somente são eliminadas do dispositivo quando forem enviadas ao Banco de
Dados por intermédio de um serviço responsável, presente no WebService.
Todas as notificações transmitidas ao Banco de Dados permanecem ali armazenadas,
disponíveis para que sejam acessadas por sistemas clientes. Além do sistema responsável pela
emissão dos autos de infração, é compreendido como cliente o WebSite que faz a coleta das
notificações não regularizadas até cinco dias da sua emissão, outro WebSite que permite a
impressão de segunda via das notificações e um terceiro WebSite que fornece meios de regularizar
as notificações.
29
3.2 TECNOLOGIAS ESCOLHIDAS
Levando-se em consideração o fato de existirem duas tecnologias que se destacam, sendo o
Java e o .NET, bem como tudo o que cada uma permite fazer, suas capacidades, desempenho,
aplicabilidade, flexibilidade e tempo de existência, optou-se pelo .NET. O .NET foi adotado pois
esta plataforma reúne as tecnologias necessárias ao desenvolvimento do WebService e dos
WebSites que atuam como clientes dos serviços. Através do .NET Compact Framework, o .NET
permite o desenvolvimento do sistema para emissão de Notificações de regularização em Área
Azul, que é utilizado em Pocket PCs sem que maiores ajustes sejam feitos. Todo o desenvolvimento
pôde ser feito em C#, e poderia ter sido complementado por outras linguagens de programação.
O C# foi escolhido, por ser uma linguagem relativamente nova, muito poderosa, de fácil
utilização e foi desenvolvida com intuito de ser a principal linguagem da plataforma .NET.
Outro recurso escolhido foi o Visual Studio. Esta é a principal ferramenta para
desenvolvimento de sistemas em .NET. Possui inúmeros mecanismos que aumentam a
produtividade de desenvolvimento, mecanismos para criação de WebServices, arquivos XML e a
presença de emuladores para teste.
Assim, esta é uma plataforma que atende plenamente às necessidades para o
desenvolvimento do sistema proposto neste projeto.
3.3 WEBSERVICE
Foi desenvolvido um WebService com a finalidade de permitir a integração entre o sistema
responsável pelo preenchimento das Notificações de Regularização e demais sistemas clientes.
O WebService funciona como uma ligação entre o Banco de Dados e os sistemas clientes.
Utilizando as cinco classes desenvolvidas, este serviço possui métodos para inserção, remoção,
atualização e busca no banco de dados. Cada método implementado possui uma função em especial,
correspondendo às necessidades dos clientes. Nem todos os métodos desenvolvidos serão
consumidos pelos clientes criados neste projeto. Os métodos disponíveis na classe
“Recebe_Registros” não serão consumidos, apenas foram desenvolvidos para que estejam
disponíveis a integrações com eventuais sistemas que necessitem estes serviços.
30
Recebe_Registros
Esta classe possui métodos que permitem a novos registros, necessários ao módulo presente
no Pocket PC serem incorporados ao sistema. Utilizando esta classe, os registros podem ser
enviados ao banco de dados. Estes métodos dão suporte para que todos os registros,
individualmente, sejam atualizados.
a) Recebe_UF(cod_UF, des_UF);
- Método responsável pelo recebimento da relação de Unidades Federativas e gravação das mesmas em banco de dados;
b) Recebe_Município (cod_UF, cod_Municipio, des_Municipio);
- Método responsável pelo recebimento da relação de Municípios, conforme o estado ao qual este pertence. Ao receber a relação, os dados são gravados no banco de dados;
c) Recebe_Rua (cod_UF, cod_Municipio, cod_Rua, des_Rua);
- Método presente no WebService responsável pelo recebimento e gravação da relação de Ruas, conforme o Município ao qual pertence;
d) Recebe_Marca (cod_Marca, des_Marca);
- Método responsável pelo recebimento e gravação da relação de Marcas de veículos;
e) Recebe_Modelo (cod_Marca, cod_Modelo, des_Modelo);
- Método desenvolvido com a finalidade de receber a relação de Modelos de veículos, conforme sua marca e gravá-los em banco de dados;
f) Recebe_Ocorrido (cod_Ocorrido, des_Ocorrido);
- Método do WebService que recebe a relação de Ocorrências que podem gerar uma Notificação de
Regularização e grava a relação em banco de dados.
31
Atualiza_Registros
Esta classe possui métodos que permitem ao módulo no Pocket PC acessar o WebService e
receber atualizações dos registros. O sistema, ao acessar os métodos receberá as informações
atualizadas que existirem.
a) Atualiza_UF(Ultima_Data);
- Método do WebService que busca no banco de dados atualizações mais recentes de Unidades
Federativas e retorna os resultados ao cliente solicitante, se houverem. A verificação é feita com
base em uma data referência, enviada como parâmetro;
b) Atualiza_Município (Ultima_Data);
- Método do WebService que busca no banco de dados atualizações mais recentes de Municípios a
partir do seu Estado e retorna os resultados ao cliente solicitante, se houverem. A verificação é feita
com base em uma data referência, enviada como parâmetro;
c) Atualiza_Marca (Ultima_Data);
- Método do WebService que busca no banco de dados atualizações mais recentes de Marcas e
retorna os resultados ao cliente solicitante, se houverem. A verificação é feita com base em uma
data referência, enviada como parâmetro;
d) Atualiza_Modelo (Ultima_Data);
- Método do WebService que busca no banco de dados atualizações mais recentes de Modelos de
veículo a partir de sua Marca e retorna os resultados ao cliente solicitante, se houverem. A
verificação é feita com base em uma data referência, enviada como parâmetro;
e) Atualiza_Rua (Ultima_Data);
- Método do WebService que busca no banco de dados atualizações mais recentes de Ruas
conforme o Município e retorna os resultados ao cliente solicitante, se houverem. A verificação é
feita com base em uma data referência, enviada como parâmetro;
32
f) Atualiza_Ocorrido (Ultima_Data);
- Método do WebService que busca no banco de dados atualizações mais recentes de Ocorrências e
retorna os resultados ao cliente solicitante, se houverem. A verificação é feita com base em uma
data referência, enviada como parâmetro.
Recebe Notificação
Classe do WebService que permite aos clientes enviarem notificações ao banco de dados ou
atualizarem os registros das notificações já enviadas.
a) RecebeNotificacoesEmitidas (notificações);
- Método disponível no WebService responsável pelo recebimento da relação de notificações
emitidas, que estavam armazenadas em arquivo XML, no Pocket PC. As notificações são enviadas
em um tipo de estrutura de dados chamado DataSet. As notificações recebidas são gravadas em
banco de dados;
b) RecebeNotificacoesRegularizadas (cod_Notificação);
- Método responsável pelo recebimento da relação de notificações que foram regularizadas. Este
método, ao receber a notificação que foi regularizada, tenta efetivar a regularização no registro
gravado em banco de dados. O resultado é retornado, podendo ser sucesso; falha por notificação já
estar regularizada, falha por ter sido emitida a mais de 5 dias ou outra falha.
Retorna_Notificação
O WebService também oferece suporte a clientes que desejam buscar dados das notificações
que foram emitidas. Sejam apenas dados básicos das notificações, todos os dados de uma
notificação (completa) ou apenas as notificações que não foram regularizadas no tempo permitido.
a) RetornaNotificacaoBasico (Data_Emissão, Placa, Situação);
- Método que, quando consumido, busca no banco de dados a relação de notificações emitidas,
conforme parâmetros informados e retorna os resultados em estrutura DataSet. As informações
resultantes são informações básicas, tais como Placa do veículo, data de emissão, Rua e Situação;
33
b) RetornaNotificaçãoCompleto (Data_Emissão, Placa, Hora_Emissão);
- Método que, quando acessado, busca no banco de dados a relação de notificações emitidas,
conforme parâmetros informados e retorna os resultados dados DataSet. As informações resultantes
são todas as informações existentes das Notificações encontradas (seu cadastro completo);
c) Retorna_Não_Regularizadas(Data_Emissão);
- Método responsável pela busca, no banco de dados, da relação de notificações emitidas que não
foram regularizadas no período permitido. Este método, ao receber a data de emissão, busca e
retorna todos os dados das notificações que não foram regularizadas. A principal finalidade dessas
informações é enviar a relação ao departamento responsável pela emissão de multas.
Login
O WebService ainda fornece suporte à validação de usuários. O método “Login (usuário,
senha, acesso)”, ao receber os dados do usuário, consulta o banco de dados e verifica sua
autenticidade e permissão de acesso ao ambiente informado (Web ou Pocket). O resultado positivo
ou negativo é retornado ao sistema cliente.
3.4 WebSite
Foram desenvolvidos três WebSites que completam a solução desenvolvida e demonstram o
consumo dos serviços fornecidos pelo WebService, pelos sistemas clientes. O desenvolvimento
destes clientes foi feito utilizando-se a mesma tecnologia utilizada para desenvolvimento do sistema
que emite as notificações, a plataforma .NET. Estes clientes acessam três serviços, ora buscando o
cadastro completo das notificações, ora cadastrando notificações regularizadas, ora buscando as
notificações não regularizadas em tempo hábil.
Os sites possuem as seguintes funções:
a) Fornecer a segunda via da Notificação de Regularização, permitindo que esta possa ser impressa;
b) Fornecer uma relação das notificações que não foram regularizadas no tempo permitido; e
c) Permitir a atualização das notificações, informando as notificações que foram regularizadas.
Foram desenvolvidos três simples WebSites em C# ASP.NET, que através do acesso aos
métodos do WebService implementado, disponibilizam informações das notificações para três
34
importantes finalidades. Os WebSites foram criados com funcionalidades úteis a dois tipos de
usuário, funcionalidades próprias para os funcionários do departamento de trânsito, que fazem
gestão da Área Azul e outra funcionalidade própria aos responsáveis pelos veículos:
• Consultando o serviço que retorna o cadastro completo das notificações, permite que
condutores ou proprietários de veículos notificados, tenham rápido e fácil acesso à segunda via
das notificações, podendo imprimi-las e assim proceder com a regularização de sua situação;
• Consultando o serviço que retorna a relação de notificações não regularizadas no tempo
permitido, oferece aos funcionários do SETERB a possibilidade de imprimirem a relação das
notificações que devem ser encaminhadas ao setor responsável pela emissão de infrações; e
• Acessando o serviço para regularização das notificações, o site permite que funcionários do
SETERB atualizem os cadastros das notificações, definindo as que já foram regularizadas para
que não venham a se tornar multas.
3.5 Modelagem
A modelagem do sistema foi realizada com base nas definições da UML (Unified Modeling
Language) e a ferramenta utilizada para criação dos diagramas foi o Enterprise Architect.
3.5.1 Levantamento de Requisitos
Nesta seção são apresentados os Requisitos do Sistema, Requisitos Funcionais, Não
Funcionais e as Regras de Negócio.
Segundo Luz (2007) os requisitos definem as necessidades do sistema que se pretende
construir, identificando e documentando o que será realmente necessário, de uma forma clara,
facilmente compreendida pelo cliente e pelas pessoas envolvidas no projeto.
3.5.1.1 Requisitos Funcionais
Os requisitos funcionais que foram identificados são os seguintes:
• RF01: O WebService deve fornecer serviços para:
o Recebe_UF;
35
o Recebe_Município; o Recebe_Rua;
o Recebe_Marca; o Recebe_Modelo; o Recebe_Ocorrido; o Atualiza_UF; o Atualiza_Município; o Atualiza_Marca; o Atualiza_Modelo; o Atualiza_Rua; o Atualiza_Ocorrido; o RecebeNotificacoesEmitidas; o RecebeNotificacoesRegularizadas; o RetornaNotificacaoBasico; o RetornaNotificaçãoCompleto e
o Retorna_Não_Regularizadas.
• RF02: O WebSite deve permitir listar as notificações emitidas por veículo, bem como permitir a
impressão de sua segunda via;
• RF03: O WebSite deve permitir a regularização das notificações;
• RF04: O sistema deve permitir o cadastro das notificações de regularização;
• RF05: O sistema deve fornecer suporte para impressão das notificações cadastradas, por meio
de impressoras móveis, próprias para Pocket PCs;
• RF06: O WebSite deve permitir que sejam listadas relações de notificações não regularizadas
em tempo hábil;
• RF07: O sistema deve permitir a visualização da notificação, antes de sua impressão;
36
• RF08: O sistema deve permitir o envio das notificações cadastradas ao Banco de Dados;
• RF09: O sistema deve permitir o recebimento de atualizações do WebService;
• RF010: O sistema deve permitir o cancelamento do cadastro que estiver sendo preenchido; e
• RF011: O sistema deve fornecer suporte à autenticação para usuários que desejem acessar
demais funcionalidades.
3.5.1.2 Requisitos Não Funcionais
• RNF01: O acesso ao sistema em Pocket PC; WebSites para regularizar notificações e imprimir
relação de notificações não regularizadas, deverá ser feito após autenticação de usuário;
• RNF02: Não haverá tempo limite para finalização do processo de envio das notificações
emitidas ao Banco de Dados;
• RNF03: O sistema deve privilegiar a utilização de listas de opções no preenchimento de
campos;
• RNF04: O serviço responsável pelo recebimento das notificações emitidas deve gravá-las em
banco de dados;
• RNF05: O WebService deve poder acessar banco de dados SQL Server 2005;
• RNF06: O sistema possuirá uma interface desenvolvida para exectar em um Pocket PC;
• RNF07: O sistema armazenará as informações em arquivo XML, enquanto estiverem no PDA;
• RNF08: O sistema deve ser desenvolvido em linguagem C# sobre o .NET Compact Framework;
• RNF09: O sistema não deve demorar mais de 10 segundos para troca de telas;
• RNF10: O WebService deve ser desenvolvido em linguagem C# , sobre Plataforma .NET;
• RNF11: Os WebSite devem ser desenvolvidos em linguagem C# , sobre Plataforma ASP.NET;
• RNF12: As notificações emitidas, após serem enviadas ao Banco de Dados, devem ser
removidas do dispositivo móvel;
37
• RNF13: O WebSite que lista as notificações não regularizadas no tempo permitido deve
solicitar uma data referência para buscar as notificações;
• RNF014: O WebSite que Regulariza notificações e que gera relação de notificações não
regularizadas somente poderão ser acessados após autenticação com senha;
• RNF015: O WebService deve estar disponível para acesso via Internet;
• RNF016: Não haverá tempo limite para que seja concluída a atualização das informações do
sistema; e
• RNF017: O WebService deve servir como intermediário na relação entre o sistema e o banco de
dados.
3.5.1.3 Regras de Negócio
• RN01: As senhas devem ser preenchidas de forma que não possam ser observadas, sendo assim
substituídas por outros caracteres;
• RN02: O sistema não deve permitir a exclusão do cadastro das notificações de regularização;
• RN03: A notificação regularizada dentro do tempo permitido é atualizada, sendo definida como
‘regularizada’.
• RN04: No cadastro das notificações são solicitados os seguintes dados:
o UF;
o Município;
o Marca;
o Modelo;
o Espécie/Tipo;
o Categoria;
o Placa;
o Rua;
o Referência; e
o Ocorrido.
38
• RN05: O cadastro de uma notificação poderá ser concluído, somente após todas as informações
solicitadas serem preenchidas corretamente;
• RN06: Os campos UF, Município, Marca, Modelo, Espécie/Tipo, Rua, Ocorrência e Categoria,
no cadastro das notificações, são campos onde existem listas com opções de preenchimento,
ainda assim é permitida a inserção de uma opção não existente na listagem;
• RN07: O logon dos usuários nos WebSites somente poderá ser efetuado se o usuário e a senha
estiverem corretos;
• RN08: O logon de um agente de trânsito no sistema em Pocket PC somente pode ser efetuado
se o usuário e a senha estiverem corretos;
• RN09: Não poderão haver usuários do sistema cadastrados com mesmo nome de usuário;
• RN10: A verificação de autenticidade do usuário e sua permissão de acesso sempre deve ser
feita por consulta ao WebService;
• RN11: O botão imprimir ficará desabilitado enquanto houver inconsistências no preenchimento
da notificação;
• RN12: O número da notificação deve considerar o dia, mês, ano, hora e minuto atuais do
sistema;
• RN13: Se as notificações forem transmitidas com sucesso, serão removidas do arquivo XML
que as armazenava enquanto estavam no Pocket PC;
• RN14: Os resultados das operações devem ser informados ao usuário. No caso de erros ou
falhas estes devem ser esclarecidos da maneira mais detalhada possível;
• RN15: Após a impressão de uma notificação, se o usuário optar por preencher uma nova
notificação, o sistema permanece na tela de preenchimento de notificações, limpa o campo
Placa do veículo e Atualiza o número da notificação;
39
• RN16: Após o WebService tentar regularizar uma notificação, o resultado desta operação deve
ser retornado ao usuário. Os possíveis resultados são:
o Sucesso;
o A notificação já foi regularizada;
o O tempo para regularizar esta notificação já se esgotou; ou
o Não foi possível regularizar esta notificação (ocorrerá nos casos de erros de entrada
de dados, falhas de acesso ao banco de dados ou falhas no acesso ao WebService).
• RN17: O WebSite que permite impressão de segunda via de notificações deve permitir a busca
de notificações emitidas, a partir da Placa do veículo e/ou Data de emissão das notificações.
3.5.1.4 Restrições
• O sistema não possui ferramentas de conversão de escritas na tela para caracteres; e
• O sistema foi desenvolvido para emissão de Notificações oriundas de ocorrências cometidas
somente em Área Azul, conforme funcionamento da mesma, na cidade de Blumenau.
3.5.2 Projeto do Sistema
Nesta seção é descrito o projeto do sistema implementado, os casos de uso desenvolvidos,
diagramas das atividades desenvolvidas, diagramas de classes de domínio/negócio, arquitetura
compreendida pela solução, as telas do sistema, diagrama de componentes, diagrama de
implantação, diagrama ER e XML Schemas tentando apresentar de uma forma detalhada o projeto
do sistema que foi implementado.
3.5.2.1 Diagramas de Casos de Uso
Nesta seção serão apresentados os Diagramas de Casos de Uso. Os diagramas de casos de
uso deste sistema estão divididos em três pacotes, sendo um pacote para o sistema que executará em
Pocket PC, casos de uso que executarão nos WebSites e ainda para casos de uso que executarão no
WebService.
40
3.5.2.1.1 Pocket PC
A Figura 4 apresenta os Casos de Uso existentes no módulo para emissão de notificações,
que executará no Pocket PC.
• UC02.01 Atualização do Sistema– permite que o usuário atualize o sistema, solicitando ao
WebService informações atualizadas;
• UC02.02 Efetua Login – permite que os usuários efetuem login no sistema;
• UC02.03 Emite Notificação – permite que o usuário emita Notificações de Regularização aos
veículos que estiverem em condições irregulares na Área Azul; e
• UC02.04 Sincroniza com WebService – permite que o usuário sincronize o sistema com um
WebService, localizado em um servidor Web, enviando a relação das notificações emitidas.
Figura 4. Casos de Uso existentes no sistema que executará no Pocket PC.
41
3.5.2.1.2 WebSite
A Figura 5 apresenta os Casos de Uso presentes nos WebSites.
• UC02.05 Emite segunda Via da Notificação– permite que responsáveis por veículos notificados
em Área Azul emitam a segunda via das Notificações de Regularização;
• UC02.06 Lista Notificações Não Regularizadas – permite que funcionários do SETERB listem e
imprimam a relação das notificações que não foram regularizadas no tempo permitido; e
• UC02.07 Regulariza Notificações – permite que funcionários do SETERB cadastrem no
WebService as Notificações de Regularização que foram regularizadas. Somente as
regularizadas no tempo permitido serão cadastradas.
Figura 5. Casos de Uso existentes nos WebSites.
3.5.2.1.3 WebService
A Figura 6 apresenta os Casos de Uso presentes no WebService.
• UC02.08 Registra Notificações Emitidas – caso de uso que registra no banco de dados a relação
de notificações que foram emitidas, recebidas por meio do serviço disponibilizado apropriado;
42
• UC02.09 Providencia Atualizações – caso de uso que busca por atualizações na base de dados e
as envia ao cliente, quando forem mais recentes do que as atualmente existentes no cliente;
• UC02.10 Envia Notificação Completa – caso de uso que busca no banco de dados todas as
informações das notificações e as retorna ao cliente solicitante;
• UC02.11 Registra Notificações Regularizadas – caso de uso que registra no banco de dados a
relação de notificações que foram regularizadas, recebidas do sistema cliente; e
• UC02.12 Envia Notificações Não Regularizadas – caso de uso que busca no banco de dados a
relação das notificações não regularizadas no tempo permitido e as retorna ao cliente solicitante.
Figura 6. Casos de Uso existentes no WebService.
43
3.5.2.2 Diagramas de Atividades
Nesta seção serão apresentados os Diagramas de Atividades. Os diagramas de atividades
descrevem a seqüência de execução das principais atividades existentes no projeto e referem-se à
execução dos principais casos de uso do sistema.
3.5.2.2.1 Login
Ao acessar o sistema, em sua primeira tela (Figura 14) será solicitado usuário e senha para
acesso (RN01). O agente de trânsito, então, informa seus dados. O sistema verifica se o usuário
informado possui permissão de acesso ao sistema, consultando o WebService (RN08, RN10). Caso
o usuário não possa ser autenticado, por usuário ou senha incorretos/inexistentes, o sistema exibirá
uma mensagem alertando a falha na autenticação (RN14). No caso em que o usuário for válido, é
apresentado ao usuário a tela principal do sistema (Figura 15), permitindo que este possa ser
utilizado, para emissão de notificações, sincronização com WebService ou atualização do sistema.
(Figura 7).
Figura 7. Diagrama da Atividade de Login no sistema.
44
3.5.2.2.2 Emitir Notificações de Regularização
Após logar-se no sistema, o Agente de Trânsito pode, entre outras funcionalidades do
sistema, emitir Notificações de Regularização (Figura 8). Para tanto, o agente deve selecionar a
devida opção. Assim que for selecionada a opção de emissão de notificações, o sistema apresenta a
tela de cadastro das notificações (Figura 16), onde o agente deve informar os dados do veículo que
cometeu a irregularidade na Área Azul e os dados referentes ao ocorrido, cada informação em sua
aba adequada (RN04, RN06). Durante o preenchimento da notificação, o usuário terá à sua
disposição a opção de visualizar a notificação, que será impressa, bastando acessar a aba
correspondente.
Depois de concluído o cadastro da notificação, o agente seleciona a opção Imprimir, para
salvar o cadastro em arquivo e imprimir a notificação (RN05). O usuário define os padrões de
impressão, a notificação é impressa e o sistema oferece ao usuário a opção cadastrar uma nova
notificação. Se a resposta for afirmativa, o sistema permanece na tela de emissão de notificações,
apenas limpando o campo da Placa e atualizando o Número da notificação que será preenchida
(RN12, RN15). Se a resposta for negativa, é apresentada a tela principal do sistema.
Durante o processo de preenchimento da notificação o sistema valida as informações e,
havendo eventuais inconsistências, estas serão apresentadas, em destaque, na aba de Visualização a
notificação, além disso, o botão Imprimir fica desabilitado (RN11).
Figura 8. Diagrama da Atividade de Emissão de Notificações.
45
3.5.2.2.3 Sincronização
Ao selecionar a opção de sincronização, o sistema executará a atividade de conectar-se com
o WebService. Assim que a conexão for efetuada, o sistema enviará ao serviço correspondente, a
relação de notificações emitidas, que estão gravadas em arquivo XML. O WebService, por sua vez,
faz a gravação destas notificações em banco de dados. O resultado da gravação (sucesso ou
fracasso) será retornado ao sistema no Pocket PC e será exibida ao usuário (RN14). Se o resultado
for positivo, as notificações enviadas ao banco de dados são removidas do arquivo XML (RN13).
(Figura 9).
Figura 9. Diagrama da Atividade de Sincronização com WebService.
46
3.5.2.2.4 Regularização de Notificações
O sistema cliente, um WebSite que permite o envio das notificações regularizadas ao
WebService, quando acessado, permite ao operador regularizar notificações. Após logar-se no
sistema, o usuário informa o número da notificação a ser regularizada e seleciona a opção “OK”.
Neste momento o site efetua uma conexão com o WebService, acessa o serviço responsável pelo
recebimento das notificações regularizadas e envia o número da notificação. O serviço, ao receber a
notificação que foi regularizada, faz uma comparação entre as notificações que estão cadastradas
em banco de dados (relação de notificações emitidas) e a notificação que foi recebida. No caso de a
notificação estar sendo regularizada dentro do tempo permitido, o serviço faz uma atualização no
estado da notificação, definindo-a como regularizada (RN03). Para concluir, o serviço envia uma
mensagem com o resultado da atividade, seja sucesso ou fracasso (RN14, RN16), (Figura 10).
Figura 10. Diagrama da Atividade de envio das Notificações Regularizadas.
47
3.5.2.2.5 Emissão de Segunda Via
Um cliente será um WebSite que permitirá a geração e impressão da segunda via das
Notificações de Regularização já emitidas. Neste cliente o usuário informa a placa do veículo e/ou a
data de emissão da notificação (RN17). O site efetua uma conexão com o WebService e acessa o
serviço que busca e retorna os dados da notificação. Em posse destas informações, o WebSite
monta a segunda via da notificação, permitindo sua impressão (Figura 11).
Figura 11. Diagrama da Atividade de emissão da segunda via
das notificações.
48
3.5.2.3 Diagramas de Classes de Domínio/Negócio
Os diagramas de classe descrevem as classes no domínio do negócio em questão e suas
relações, classes que formam a estrutura do sistema. A Figura 12 apresenta o diagrama de classes de
domínio do sistema, dividindo as classes conforme o ambiente onde estarão presentes, sendo Pocket
PC, WebSite ou WebService.
Para todas as classes são apresentados os métodos próprios e suas relações. As classes
disponíveis no WebService (Atualiza_Registros, Recebe_Registros, Recebe_Notificação,
Retorna_Notificação e Autentica _Usuario) oferecem métodos que podem ser úteis e acessados por
diversos clientes, elas funcionam como uma parte de cada sistema que as utiliza, porém ficam
localizadas em um servidor Web remoto. Havendo necessidade de manutenção em alguma destas
classes, o ajuste é feito uma única vez e passa a estar disponível a todos os clientes.
As classes presentes no Pocket PC (Atualização, Notificação, Login e Sincronização)
demonstram os métodos implementados, organizados conforme suas classes. Há relações entre os
métodos próprios a cada classe e entre métodos de diferentes classes, além disso, também há
relação com classes presentes no WebService. As classes do WebService fornecem serviços que são
úteis a esta aplicação e, de certa forma, fazem parte dela.
Já nos WebSites cada módulo possui apenas uma classe (Segunda_Via, Nao_Regularizadas
e Regulariza), as classes utilizam métodos disponibilizados pelo WebService, mas também
executam processamentos internos, entre seus próprios métodos.
O sistema, apesar de possuir classes próprias a cada módulo, é um sistema distribuído, que
necessita serviços fornecidos por classes externas.
49
Figura 12. D
iagrama de C
lasses de Dom
ínio.
cd 4.1 Diagrama de Classe de Domínio
Pocket PC WebService WebSite
Recebe_Registros
+ Recebe_UF(int, char, Data) : void+ Recebe_Municipio(int, int, char, Data) : void+ Recebe_Rua(int, int, int, char, Data) : void+ Recebe_Marca(int, char, Data) : void+ Recebe_Modelo(int, int, char, Data) : void+ Recebe_Ocorrido(int, char, Data) : void
Notificação
- Num_Notificacao: int- Cod_Rua: int- Referência: char- Data_Emissao: Date- Cod_Ocorrido: int- Cod_Agente: int- Placa: char- Cod_UF: int- Cod_Municipio: int- Cod_Marca: int- Cod_Modelo: int- Especie: char- Categoria: char
+ Imprime_Notificação() : void+ Gera_XML() : void+ Gera_Notificação() : void+ Valida_Notificacao() : void
Recebe_Notificação
+ Notificações_Emitidas(int, int, char, int, int, char, char, int, Data, char, int) : void+ Notificações_Regularizadas(Data, int) : void
Atualização
+ Conecta_Servico() : void+ Acessa_Atualiza_UF(Data) : void+ Acessa_Atualiza_Município(Data) : void+ Acessa_Atualiza_Rua(Data) : void+ Acessa_Atualiza_Marca(Data) : void+ Acessa_Atualiza_Modelo(Data) : void+ Acessa_Atualiza_Ocorrido(Data) : void
Retorna_Notificação
+ Retorna_Notificação_Basico(Data, char, int) : void+ Retorna_Notificação_Completo(int, char) : void+ Retorna_Não_Regularizadas(Data) : void
Sincronização
+ Conecta_Servico() : void+ Envia_Notificacoes_Emitidas(char) : void
Atualiza_Registros
+ Atualiza_UF(int, char, Data) : void+ Atualiza_Municipio(int, int, char, Data) : void+ Atualiza_Rua(int, int, int, char, Data) : void+ Atualiza_Marca(int, char, Data) : void+ Atualiza_Modelo(int, int, char, Data) : void+ Atualiza_Ocorrido(int, char, Data) : void
Segunda_v ia
- Num_Notificacao: int- Des_Rua: int- Referência: char- Data_Emissao: Date- Des_Ocorrido: int- Cod_Agente: int- Placa: char- Des_UF: int- Des_Municipio: int- Des_Marca: int- Des_Modelo: int- Especie: char- Categoria: char
+ Conecta_Servico() : void+ Busca_Dados_Segunda_Via(Data, char) : void+ Gera_Segunda_Via() : void
Regulariza
- Cod_Notificacao: int- Data_Emissao: Data
+ Conecta_Servico() : void+ Envia_Regularizada() : void
Não_Regularizadas
- Num_Notificacao: int- Des_Rua: int- Referência: char- Data_Emissao: Date- Des_Ocorrido: int- Cod_Agente: int- Placa: char- Des_UF: int- Des_Municipio: int- Des_Marca: int- Des_Modelo: int- Especie: char- Categoria: char- Situacao: char
+ Conecta_Servico() : void+ Busca_Nao_Regularizadas(Data) : void+ Gera_Relatório() : void
Login
- Usuario: char- Senha: char
+ Efetua_Login(char, char) : void
Autentica_Usuario
+ Valida_Usuario(char, char) : void1 1
0..* 0..*
0..*
10..1
0..*
0..*
0..*
0..* 0..*
0..*
0..1
0..*
0..1
0..*
1
1
0..*
1
0..*
50
3.5.2.4 Arquitetura do sistema
A Arquitetura do Sistema (Figura 13) compreende uma estação móvel (Pocket PC) com
processamento e armazenamento local, e um WebService externo, que encontra-se executando em
um Servidor Web, que receberá informações do Pocket PC.
Os WebSites clientes podem ser acessados em browsers instalados em estações PCs ou
também em browsers presentes em dispositivos móveis. Estes WebSites acessam o WebService
externo para consulta e atualização de informações.
Figura 13. Arquitetura do Sistema.
51
3.5.2.5 Telas do Sistema
A Figura 14 apresenta a tela de Login, onde os usuários autenticam sua identidade para
poderem acessar o sistema.
Figura 14. Tela de Login do Sistema.
A Figura 15 apresenta a tela principal do Sistema, através da qual os usuários podem acessar
as funcionalidades de Emitir Notificações, Sincronizar com WebService ou Atualizar registros.
Figura 15. Tela Principal do Sistema.
52
A Figura 16 apresenta a rotina de emissão de notificações. Nesta tela é apresentada a aba
onde são preenchidos os dados do veículo que será notificado.
Figura 16. Tela do Sistema para Emissão de Notificações,
Descrição do Veículo.
A Figura 17 apresenta a continuação do preenchimento de notificações. Nesta tela é
apresentada a aba onde são preenchidos os dados referentes à infração.
Figura 17. Tela do Sistema para Emissão de Notificações, Dados
da Infração.
53
A Figura 18 apresenta a tela de Visualização da notificação que foi cadastrada. Nesta aba o
usuário poderá ver previamente como a notificação será impressa e verificar eventuais
inconsistências no preenchimento da notificação (destacadas em vermelho).
Figura 18. Tela do Sistema para Visualização e Impressão das Notificações Cadastradas.
A Figura 19 apresenta a tela de Login nos WebSites.
Figura 19. Autenticação de usuário para acesso aos WebSites.
54
A Figura 20 apresenta a tela do WebSite que busca as notificações não regularizadas. Neste
exemplo as notificações já foram buscadas e foram listadas.
Figura 20. Busca por notificações não regularizadas e notificações encontradas.
A Figura 21 apresenta a tela do sistema onde é feita a Regularização das Notificações, pelo
WebSite.
Figura 21. Solicitação do número da notificação a ser regularizada.
A Figura 22 apresenta a tela de busca das notificações emitidas para um veículo, presente no
WebSite responsável pela emissão da segunda via. O campo placa é obrigatório enquanto o campo
data é opcional.
55
Figura 22. Solicitação dos dados do veículo para gerar segunda via
da notificação.
A Figura 23 apresenta a tela do sistema onde são relacionadas as notificações encontradas
para o veículo informado, no WebSite de emissão de segunda via. Como nenhuma data foi
informada, foram apresentadas todas as notificações existentes. Para que seja gerada a segunda via
da notificação, basta que o usuário selecione a notificação desejada e clique na opção “Gerar”.
Figura 23. Notificações localizadas para o veículo informado.
A Figura 24 apresenta a tela com a segunda via da notificação gerada, pronta para ser
impressa.
56
Figura 24. Segunda via da Notificação, pronta para ser impressa.
A Figura 25 apresenta a notificação que será impressa. Neste exemplo, a notificação foi
impressa em arquivo .PDF.
Figura 25. Notificação impressa em arquivo .PDF.
57
3.5.2.6 Diagrama de Componentes/Diagrama de Implantação
Esta seção apresenta os diagramas de Componentes e diagramas de Implantação do Sistema,
na Figura 26.
Os diagramas de implantação representam a topologia física do sistema, assim tem-se um
mapeamento entre os componentes de software e hardware utilizados pelo sistema. Os diagramas de
componentes mostram os vários componentes de software do sistema e suas dependências.
Figura 26. Diagrama de Componentes / Diagrama de Implantação do Sistema.
58
3.5.2.7 Diagrama ER
Esta seção apresenta o diagrama ER do sistema, conforme Figura 27. O diagrama ER
apresenta as tabelas que foram criadas no banco de dados, bem como o relacionamento entre elas. O
banco de dados está presente no servidor, assim como o WebService, sendo acessado
exclusivamente por meio deste.
As tabelas de marcas, modelos, categorias, ocorrências, estados, municípios, espécies e ruas
são utilizadas para armazenar informações necessárias ao funcionamento do sistema, úteis para a
rotina de emissão das notificações. Durante a atualização do sistema informações existentes nestas
tabelas são levadas para o dispositivo móvel.
Outra informação armazenada no banco de dados é a relação de usuários que possuem
permissão de acesso ao sistema, seu nome, senha, e padrões de acesso. Os padrões de acesso
determinam se o usuário possui permissão para acessar os WebSites e módulo no Pocket PC.
Todas as notificações emitidas, durante a sincronização, são enviadas ao banco de dados e
ali permanecem por tempo indefinido. Mesmo depois de regularizadas ou encaminhadas para
geração de multas, as notificações permanecem no banco de dados. Desta maneira, há uma tabela
própria para armazenamento destas notificações. No futuro, possivelmente estatísticas poderão ser
feitas com base nesses registros. Para cada notificação há uma coluna que define a situação da
notificação, determinando se esta está regularizada ou não.
59
Figura 27. Diagrama ER do Sistema.
3.5.2.8 XML Schema
Esta seção apresenta os XML Schema, que definem o formato dos principais arquivos XML
que são utilizados no projeto. Arquivos XML para armazenamento de dados no dispositivo móvel e
para troca de informações com WebService. Os schemas encontram-se no Apêndice A.
60
3.6 Implementação do Sistema
A etapa de implementação descreve o processo de desenho e codificação do sistema em
todos os seus módulos.
O sistema foi totalmente desenvolvido na IDE da Microsoft, Visual Studio 2005. O banco de
dados utilizado foi o SQL Server 2005.
Após entrevista com usuários da Área Azul e coleta de materiais, foi feita a modelagem do
sistema, etapa fundamental ao desenvolvimento. Todo o desenvolvimento do sistema foi feito a
partir dos requisitos e regras do negócio, levantadas ainda durante a fase de modelagem.
Com a modelagem concluída, foi necessário configurar o ambiente para iniciar o
desenvolvimento. A UNIVALI (Universidade do Vale do Itajaí) fornece uma cópia licenciada do
Visual Studio 2005, limitada à utilização didática, mas que atendeu completamente as necessidades
deste projeto.
O pacote de desenvolvimento de sistemas para dispositivos compactos (celulares, pocket
PCs), Compact Framework, assim como o SDK MMIT, foram obtidos através do WebSite da
Microsoft e incorporados ao Visual Studio.
Depois de instalados estes pacotes, o Visual Studio disponibilizou formulários para
desenvolvimento de sistemas para Pocket PCs e celulares em uma variedade de linguagens de
programação, além de emuladores dos dispositivos. A criação de projetos, com opção de linguagem
de programação a ser adotada, bem como o template que será utilizado está demonstrada na Figura
28.
Figura 28. Criação de um projeto no Visual Studio 2005.
61
A linguagem escolhida foi o C#, um novo projeto foi criado para Pocket PCs, formulários
foram incluídos no projeto e as telas foram desenhadas, somente controles fornecidos nativamente
pelo editor foram utilizados, adaptados à plataforma móvel. Controles tais como Label, Text Box,
List Box, Panel, Button, ComboBox, Tab Control entre outros. Todos os controles foram
configurados e definidos com nomenclatura organizada, que facilitou o desenvolvimento do
sistema. O ambiente onde é feito o desenho das telas é apresentado na Figura 29.
Figura 29. Edição de formulários no Visual Studio 2005 e opções de controles disponíveis.
Depois de desenhadas as telas, foi iniciada a codificação com validações de campos e
controles de preenchimento. Um exemplo deste tratamento foi aplicado no preenchimento das
notificações, pois quando selecionada a marca do veículo infrator, somente veículos daquela marca
selecionada são apresentados. Outros tratamentos necessários à usabilidade do sistema, que lhe
conferem maior agilidade de preenchimento e garantia de consistência das informações também
foram incorporados, como por exemplo, o tratamento apresentado na Figura 30.
62
Figura 30. Tratamento de usabilidade impedindo a impressão da notificação, quando não estiverem todos os campos preenchidos.
Durante esta fase notou-se a necessidade dos cadastros de Veículos, Cidades, Estados,
Marcas, entre outros, que ainda não haviam sido desenvolvidos. Foram então criados os arquivos
XML que armazenam os cadastros, demonstrados pela Figura 31. Para cada arquivo XML definido
também foi criado seu schema, que define cada campo do XML e é fundamental na validação dos
dados inseridos no arquivo.
Figura 31. XML que armazena marcas de veículos.
Estes arquivos foram criados e incorporados ao projeto, porém sem informações iniciais.
Estes arquivos sempre são alimentados quando selecionado o botão adequado para Atualizar o
Sistema. Este botão executa uma ação que acessa o WebService (não desenvolvido até o momento)
63
que, utilizando um serviço apropriado, busca no banco de dados os registros mais recentes, ainda
não transportados, e os traz para o aparelho, atualizando seus cadastros. Tendo os cadastros
definidos, pôde-se concluir a etapa de preenchimento das telas com a gravação da notificação
preenchida, em arquivo XML.
Estruturas de dados como DataSet, DataTable e DataRow foram fundamentais para a
conclusão da etapa, que lida diretamente com manipulação e arquivos XML. Estas tecnologias
fazem todo o trabalho bruto e facilitam esta tarefa consideravelmente. Com estes tipos de dados, é
possível buscar dados dentro dos XML de uma forma semelhante a selects em SQL (Structured
Query Language), bem como criá-los, criar seus schemas, inserir, alterar, excluir ou validar
informações. Um exemplo de código deste projeto, onde tais estruturas de dados foram utilizadas é
apresentado na Figura 32.
Figura 32. Código utilizando DataSets, DataTables e DataRows.
Foram criadas funcionalidades para os Botões disponíveis no sistema, tais como Login,
Emitir Notificação, Sincronizar, Atualizar Sistema, Imprimir, Cancelar e Sair. Mas, durante este
processo verificou-se a necessidade de criar o WebService, visto que a maioria das ações
incorporadas aos botões invocariam métodos presentes no serviço.
Foi criado um novo projeto no Visual Studio, projeto de um Serviço Web, também
utilizando a linguagem C#.
Este projeto de WebService foi dividido em cinco classes de serviços, conforme detalhados
na etapa de modelagem do sistema. As classes e seus métodos foram separados em uma nova
camada, que melhora a organização dos serviços e facilita a manutenção do código.
64
Depois de criado um projeto de serviço Web, o .NET se encarrega de criar toda a estrutura
necessária para a execução deste projeto, seja em um simulador de um Servidor Web ou utilizando
um Servidor propriamente dito, disponível ao desenvolvedor, como por exemplo o IIS (Internet
Information Services). Em computadores de desenvolvimento, presentes em ambientes onde não há
presença de um servidor Web próprio, o Visual Studio oferece a possibilidade de simulação deste
servidor, apenas para teste do projeto, porém atendendo a todos os requisitos básicos.
Depois de criada a Classe principal do WebService, facilmente foram criadas as subclasses e
os métodos ou serviços que estarão disponíveis aos clientes, tudo em C#.
Este Webservice deve ser compilado e passa a estar disponível para ser publicado, deve ser
apenas ser copiado para um diretório de um servidor Web, da mesma maneira como se publicam
WebSites.
O Visual Studio possui um recurso para testes dos serviços Web, ele automaticamente cria
uma página Web contendo links de acesso a cada um dos métodos criados (Figura 33). Nestes links
são apresentados campos para entradas de dados (somente tipos primitivos), estas entradas serão
passadas como parâmetros para os serviços (Figura 34). Também é criado um botão, para invocar o
serviço, enviando os parâmetros preenchidos. Desta forma muitos serviços podem ser testados,
excluindo somente aqueles que recebem como parâmetros, tipos avançados de dados. Ao invocar o
serviço, enviado os métodos solicitados, o serviço é executado e o resultado é apresentado. Ainda
há a possibilidade de se depurar todo o processamento executado no serviço.
65
Figura 33. WebSite criado automaticamente pelo Visual Studio permitindo que
se teste o WebService.
Figura 34. Teste de um serviço disponibilizado pelo WebServices. Interface
criada automaticamente.
Enquanto eram desenvolvidos os serviços, percebeu-se que todos os serviços oferecidos
efetuam acessos ao banco de dados. Desta forma foi necessário interromper o desenvolvimento do
WebService para que o banco de dados fosse criado.
Com o SQL Server já configurado, etapa concluída durante a preparação do ambiente de
desenvolvimento, bastou desenhar as tabelas e criá-las, em uma nova base de dados.
Utilizando a ferramenta DB Designer 4, as tabelas foram desenhadas. O DB Designer possui
um recurso que é de sincronização com bancos de dados. Sincronizando esta ferramenta com o
66
banco de dados, é possível trazer informações presentes no banco ou enviar informações para o
banco. Esta funcionalidade elimina o trabalho “braçal”, de criação de tabelas, escrevendo todos os
comandos e definições de cada tabela. As tabelas são desenhadas graficamente, configuradas, todas
as colunas definidas, em seguida, via sincronização, as tabelas são efetivadas no banco de dados.
A ferramenta SQL Server Management Studio Express, disponibilizada juntamente a
instalação do banco, também foi utilizada e auxiliou bastante na configuração do banco, criação da
base de dados entre outras parametrizações. A Figura 35 apresenta as tabelas criadas no banco de
dados, observadas por ferramenta que gerencia o banco de dados.
Figura 35: Estrutura de tabelas criadas no banco de dados.
Com o banco de dados montado e disponível, conexões foram criadas, comandos de acesso
ao banco para leitura, gravação ou alteração de informações foram escritos e os serviços Web foram
concluídos.
Com os WebServices concluídos, o desenvolvimento das telas do sistema pôde ser
retomado. Em projetos desenvolvidos no Visual Studio, para se criar uma conexão com um
WebServices há um recurso responsável por esta tarefa. É adicionada uma referência Web,
informando-se o caminho onde se encontra o WebService, conforme Figura 36.
67
Figura 36. Ferramenta para configuração de acessos a WebServices em projetos
desenvolvidos no Visual Studio 2005.
Depois de incluída esta referência ao WebServices no código do seu sistema, deve ser criada
uma nova instância do servidor Web. Para cada instância criada, todos os serviços disponíveis
naquele servidor podem ser acessados, semelhante à chamada de uma função presente em seu
sistema local.
O login do usuário no sistema foi desenvolvido, com autenticação sendo feita por consulta
ao WebService. As funcionalidades de Emissão de Notificações, Sincronização e Atualização do
Sistema também foram concluídas. Para impressão da notificação, foi necessário utilizar um
componente pago, visto que o Visual Studio 2005 não possui controle próprio, com suporte a
impressão, possui é claro, controles para comunicação com periféricos e acesso a portas de
comunicação.
O componente de impressão adotado é gratuito quando utilizado para desenvolvimento e
pago para utilização em sistemas comercializados. O valor é por cópia, que deve ser instalada em
cada Pocket que o utilizará. Trata-se do PrintCE, fornecido pela IneSoft (Figura 37). Este
componente facilitou bastante a tarefa de impressão, pois é de simples configuração; suporta
diversos tipos de impressoras, de diversas marcas e; é capaz de imprimir diretamente em arquivos
.PDF. Como não foi disponibilizada impressora para teste de impressão das notificações, os testes
foram feitos com impressão em arquivos .PDF.
68
Figura 37. Interface para gerenciamento de impressão fornecida
pelo componente de impressão utilizado, PrintCE.
Durante todo o desenvolvimento do módulo que executará no pocket, este pôde ser testado
no emulador do dispositivo. Para isto, há um recurso presente no Visual Studio, chamado de
Deploy. Ao selecionar o botão de Deploy, o sistema é compilado e, não havendo erros, é criado um
arquivo executável do sistema. Em seguida é apresentada uma janela com opção de emuladores,
entre eles, Pocket PC (Windows Mobile 5), Pocket PC (Windows CE 2003) e diversos
SmartPhones (Figura 38). Ao selecionar em qual emulador se deseja testar o sistema, o emulador é
aberto, o arquivo executável e todos os outros arquivos presentes e necessários ao projeto, tais como
os arquivos XML, são copiados para um diretório dentro do emulador.
69
Figura 38. Emuladores disponíveis para teste da aplicação.
Utilizando o emulador, o diretório é localizado, o programa é executado e já pode ser
testado. Durante o teste também há possibilidade de se depurar o código.
Como foi criado um servidor IIS no computador pessoal usado para o desenvolvimento,
onde se deu toda execução dos sistemas Web, após uma configuração de rede entre o emulador e o
computador local, o sistema executando diretamente no emulador, era capaz de consumir os
serviços hospedados no IIS.
Para se criar uma rede entre o emulador e o computador pessoal, assim como o Deploy do
sistema, se fez necessária a utilização de uma ferramenta, que efetua uma sincronização entre os
dispositivos (Computador e PDA). A ferramenta disponibilizada pela Microsoft para esta finalidade
e utilizada neste projeto é o ActiveSync.
Por meio do emulador, todo o sistema pôde ser testado, bem como o consumo dos serviços
presentes no WebService e o armazenamento das informações utilizando os arquivos XML.
Com esta etapa concluída, a etapa de desenvolvimento dos WebSites foi iniciada. O Visual
Studio oferece templates para criação de projetos de WebSites em ASP.NET, podendo ser escritos
em diversas linguagens, e voltados a browsers disponíveis em computadores pessoais ou
70
disponíveis em PDAs. Quando voltados a PDAs, os recursos são limitados, objetivando tornar as
páginas mais “leves” (que ocupem menos espaço), visto que a memória dos dispositivos portáteis
não é tão abundante quanto a dos PCs e em geral, as redes de acesso a Internet móvel possuem
velocidade relativamente baixa (Figura 39).
Figura 39. Desenho dos WebSites em template próprio para browsers de
dispositivos móveis.
O primeiro WebSite desenvolvido permite emissão da segunda via das notificações
emitidas. Este foi desenvolvido em leiaute voltado a browsers de PDAs, pois permitiria que os
agentes da Área Azul, além de emitirem notificações, emitam a segunda via destas, bastando
acessar o WebSite disponibilizado. Apesar de utilizar o leiaute voltado a PDAs, estes WebSites
também podem ser acessados por browsers comuns, instalados em PCs.
Para emitir a segunda via de uma notificação, não há necessidade de autenticação no
sistema, qualquer pessoa pode executar tal tarefa. As informações necessárias são a placa do veículo
e a data de emissão da notificação. Caso o usuário não saiba qual a data, basta informar a placa, e
uma relação contendo todas as notificações emitidas àquela placa será listada. Apenas àquela
notificação selecionada será apresentada a segunda via.
Este WebSite indiretamente oferece uma solução a um problema existente na Área Azul de
Blumenau. Hoje, se algum veículo for notificado, a notificação será afixada em seu pára-brisas. Em
alguns casos, esta notificação pode se extraviar ou ser removida antes que o condutor tome ciência
de que foi notificado. Conforme a lei, se a notificação não for regularizada em 5 dias, tornar-se-á
multa. Havendo dúvidas sobre esta questão, o condutor facilmente pode consultar o WebSite e
71
verificar se alguma notificação foi emitida durante sua ausência, poderá ainda emitir a segunda via,
se necessário.
Depois de concluído este WebSite, foi desenvolvido outro, onde os funcionários do
departamento e trânsito, inclusive os agentes da Área Azul, podem efetuar a regularização das
notificações emitidas.
Neste WebSite, depois de autenticado o usuário, informando o número da notificação que
foi emitida esta será regularizada. Internamente, o que ocorre, é que um serviço responsável pela
regularização é invocado, este, por sua vez, acessa o banco de dados e altera o registro da
notificação, definindo-a como regularizada. O template utilizado para desenvolvimento deste
WebSite também foi aquele voltado a dispositivos portáteis, visto que eventualmente o
departamento de trânsito poderá implantar um serviço móvel para regularização de notificações.
Para concluir o desenvolvimento do projeto, o departamento de trânsito necessita
encaminhar todas as notificações não regularizadas no tempo permitido, para o departamento
responsável pela emissão das multas. Para suprir esta necessidade, outro WebSite foi desenvolvido,
e tem a finalidade de relacionar estas notificações. Desta vez o desenvolvimento se deu sobre o
leiaute de WebSites voltados a browsers de computadores pessoais.
Como todos os dias esta relação de notificações deve ser relacionada e encaminhada, basta
acessar o módulo adequado, informar a data referência e uma relação das notificações será gerada.
A relação pode ser impressa e apresenta todos os dados de cada notificação relacionada.
O desenvolvimento dos WebSites, em ambos os leiautes é semelhante à programação de
sistemas Window Forms, exigindo apenas novas qualidades ao desenvolvedor, no que se refere ao
design, visto que é um sistema Web, o que exige um tratamento diferenciado; além do
conhecimento HTML e CSS para melhoramento da parte visual. No restante, a programação é feita
da mesma maneira, invocando-se novos Formulários; passando parâmetros entre estes e seus
métodos; leitura e exibição de dados informados na tela, acesso a banco de dados ou serviços Web.
Durante todo o desenvolvimento, diversas dificuldades interromperam temporariamente o
desenvolvimento. Alguns detalhes relativos a cada tecnologia exigiram paradas para pesquisas. O
site da Microsoft, MSDN (Microsoft Developer Network) ajudou bastante nesta etapa, pois contém
todos os manuais de utilização do .NET. As bibliotecas de ajuda fornecidas não somente
apresentam os componentes presentes na plataforma, mas também explicam o funcionamento dos
72
componentes e apresentam exemplos em diversas linguagens. São bibliotecas bastante completas e
de fácil acesso.
A solução desenvolvida pelo .NET para manipulação de arquivos XML é um exemplo de
problema enfrentado. Após uma pesquisa, chegou-se ao conhecimento de que DataSets, DataTables
e DataRows são tipos de dados que oferecem uma das maneiras para manipulação destes arquivos.
Outros itens que exigiram pesquisas foram:
- Desenvolvimento de WebServices;
- Consumo de WebServices por programas clientes;
- Conexão com banco de dados;
- Execução de comandos SQL sobre o banco de dados, bem como obtenção dos resultados retornados pelo banco;
- Impressão de notificações diretamente em impressora;
- Troca de informações entre os formulários; e
- Configuração e manipulação dos controles (ComboBox, ListBox).
Durante todo o desenvolvimento, o sistema era testado, via emulador ou via browser,
conforme o caso. Diversos testes eram feitos, comprovando a funcionalidade do que era
desenvolvido. O depurador de código foi útil, auxiliou bastante a identificação de falhas. O
depurador do Visual Studio permite depurar WebSites, WebServices, e até mesmo o módulo que
era executado no emulador de Pocket PC, independentes ou simultaneamente, passando por códigos
do módulo que executa no emulador, em seguida depurando o código que executa no WebService
(localizado no Servidor Web). Este depurador oferece recursos para alteração de valores das
variáveis, durante a depuração; permite visualizar todos os valores das tabelas de dados; permite
voltar linhas de código já executadas, entre outros diversos recursos que auxiliam o programador.
Desta maneira, o sistema, em todos os seus módulos, foi desenvolvido e testado, atendendo
a todos os requisitos e cumprindo todas as regras de negócio.
73
3.7 Testes e Avaliação
A etapa de teste e avaliações ocorreu paralelamente ao desenvolvimento dos módulos. Como
o sistema desenvolvido neste projeto ainda não está implantado na área Azul de Blumenau, os testes
e avaliações foram feitos com base nos requisitos levantados durante a modelagem e também com
base em uma checklist. Esta checklist foi definida orientada ao problema que será solucionado pelo
sistema desenvolvido, como um todo, desde a emissão das notificações até sua regularização.
Conforme as rotinas e telas eram desenvolvidas, também eram testadas. O teste foi feito de
acordo com as entradas de dados e suas respectivas saídas, processadas pelo sistema. As saídas
foram observadas por consulta em banco de dados; pela apresentação de resultados na tela do
próprio programa; arquivos XML gerados e alterados e; arquivos .PDF gerados. Os resultados
foram analisados também sob depuração do código que, enquanto processados, pôde-se observar o
valor das variáveis, comportamento dos laços de repetição e análise das condições nos testes de
valores.
A avaliação das telas somente ocorreu quando, via testes, comprovou-se que os requisitos
funcionais, regras de negócio e a relação de itens na checklist haviam sido atendidas.
A checklist foi desenvolvida para avaliar o sistema como um todo, mesmo que alguns itens
tenham avaliado telas ou rotinas específicas.
As possíveis respostas para as questões foram:
0 – Não atendido; 5 – Parcialmente atendido; e 10 – Totalmente atendido. A relação de itens testados e os resultados obtidos são os seguintes:
1) 10 O sistema permite que sejam emitidas notificações e regularização?
2) 10 O sistema permite que notificações emitidas sejam impressas em impressoras próprias para Pocket PCs?
3) 10 O sistema permite que notificações emitidas sejam enviadas a um banco de dados localizado em um servidor web?
4) 10 O sistema utiliza WebServices para trocar informações com o banco de dados?
5) 10 Existe funcionalidade implementada que permita ao sistema atualizar seus registros (relação de Ruas, Cidades, Marcas, Modelos de veículos, entre outros)?
74
6) 10 O sistema permite que o preenchimento de uma notificação seja cancelado após ter sido iniciado?
7) 10 O sistema permite que notificações emitidas sejam regularizadas via Web?
8) 10 O sistema permite que notificações não regularizadas no tempo permitido sejam relacionadas e impressas, funcionalidade acessada via Web?
9) 10 O sistema permite que segundas vias das notificações emitidas sejam relacionadas e impressas, via Web?
10) 10 O módulo que executa no Pocket PC solicita autenticação dos usuários?
11) 10 Os módulos que relacionam notificações não regularizadas e que permitem regularização das notificações emitidas, que executam na Web, solicitam autenticação dos usuários?
12) 5 O sistema valida as informações antes de imprimir a notificação?
13) 10 O sistema não impõe tempo limite para conclusão do envio das notificações emitidas, ao banco de dados?
14) 10 O sistema privilegia listas, para seleção das opções, no preenchimento da notificação?
15) 10 Após emitidas as notificações, além de impressas, elas são gravadas em arquivo XML?
16) 10 Após enviadas ao banco de dados, as notificações emitidas são removidas do arquivo XML que as armazenava?
17) 10 O WebSite que lista as notificações não regularizadas no tempo permitido, solicita uma data referência para buscar as notificações?
18) 10 As senhas digitadas são substituídas por outros caracteres, para que não sejam compreendidas durante sua digitação?
19) 10 As notificações, depois de emitidas, não podem ser excluídas pelo sistema?
20) 10 No cadastro das notificações são solicitados UF, Município, Marca, Modelo, Espécie/Tipo, Categoria, Placa, Rua, Referência e Ocorrido?
21) 10 O botão que permite concluir o preenchimento de uma notificação e a impressão da mesma, somente fica habilitado enquanto todas as informações solicitadas estiverem informadas?
22) 5 Durante o preenchimento de uma notificação o usuário pode verificar como esta será impressa?
23) 10 Durante o preenchimento de uma notificação erros, falhas e ausência de informação são claramente informadas ao usuário?
24) 10 Durante o preenchimento de uma notificação, depois de selecionada uma marca de veículo, são apresentados somente veículos daquela marca?
25) 10 Durante o preenchimento de uma notificação, depois de selecionada uma UF, são apresentadas somente cidades daquela UF?
26) 10 Nos módulos que solicitam autenticação, somente quando informados usuário e senha corretos, o acesso é liberado ao usuário?
27) 10 O sistema informa claramente erros e falhas nas rotinas de login, sincronização, atualização e regularização de notificação?
28) 10 Após a impressão de uma notificação, é oferecida a opção de preenchimento de uma nova notificação?
75
29) 10 Se o usuário optar por preencher uma nova notificação, o programa permanece na tela de preenchimento de notificações, limpa o campo Placa do veículo e Atualiza o número da notificação?
30) 10 O WebSite que permite impressão de segunda via das notificações, permite a busca de notificações emitidas a partir da Placa do veículo e/ou Data de emissão das notificações?
31) 10 O WebService fornece um serviço responsável pelo recebimento de UF?
32) 10 Ao receber as UF, o serviço grava as informações no banco de dados?
33) 10 O WebService fornece um serviço responsável pelo recebimento de Municípios?
34) 10 Ao receber os Municípios, o serviço grava as informações no banco de dados?
35) 10 O WebService fornece um serviço responsável pelo recebimento de Ruas?
36) 10 Ao receber as Ruas, o serviço grava as informações no banco de dados?
37) 10 O WebService fornece um serviço responsável pelo recebimento de Marcas?
38) 10 Ao receber as Marcas, o serviço grava as informações no banco de dados?
39) 10 O WebService fornece um serviço responsável pelo recebimento de Modelos?
40) 10 Ao receber os Modelos, o serviço grava as informações no banco de dados?
41) 10 O WebService fornece um serviço responsável pelo recebimento de Ocorridos?
42) 10 Ao receber os Ocorridos, o serviço grava as informações no banco de dados?
43) 10 O WebService fornece um serviço responsável pela atualização de UF?
44) 10 Ao receber solicitação para atualização de UF, o serviço verifica registros mais recentes, comparados a data informada e retorna os resultados ao cliente que fez a solicitação?
45) 10 O WebService fornece um serviço responsável pela atualização de Municípios?
46) 10 Ao receber solicitação para atualização de Municípios, o serviço verifica registros mais recentes, comparando a data informada e retorna os resultados ao cliente que fez a solicitação?
47) 10 O WebService fornece um serviço responsável pela atualização de Ruas?
48) 10 Ao receber solicitação para atualização de Ruas, o serviço verifica registros mais recentes, comparando a data informada e retorna os resultados ao cliente que fez a solicitação?
49) 10 O WebService fornece um serviço responsável pela atualização de Marcas?
50) 10 Ao receber solicitação para atualização de Marcas, o serviço verifica registros mais recentes, comparando a data informada e retorna os resultados ao cliente que fez a solicitação?
51) 10 O WebService fornece um serviço responsável pela atualização de Modelos?
52) 10 Ao receber solicitação para atualização de Modelos, o serviço verifica registros mais recentes, comparando a data informada e retorna os resultados ao cliente que fez a solicitação?
53) 10 O WebService fornece um serviço responsável pela atualização de Ocorridos?
54) 10 Ao receber solicitação para atualização de Ocorridos, o serviço verifica registros mais recentes, comparando a data informada e retorna os resultados ao cliente que fez a solicitação?
76
55) 10 O WebService fornece um serviço responsável pelo recebimento de Notificações Emitidas?
56) 10 Ao receber as Notificações Emitidas, o serviço grava as informações no banco de dados?
57) 10 O WebService fornece um serviço responsável pelo recebimento de Notificações Regularizadas?
58) 10 Ao receber as Notificações Regularizadas, o serviço regulariza as notificações, alterando registro no banco de dados?
59) 10 O WebService fornece um serviço responsável por retornar ao cliente os dados básicos de uma notificação?
60) 10 Ao ser invocado o serviço, são buscados no banco de dados e retornados ao cliente solicitante, os dados básicos das notificações?
61) 10 O WebService fornece um serviço responsável por retornar ao cliente todos os dados de uma notificação (completa)?
62) 10 Ao ser invocado o serviço, são buscados no banco de dados e retornados ao cliente solicitante, todos os dados das notificações?
63) 10 O WebService fornece um serviço responsável por retornar ao cliente os dados das notificações que não foram regularizadas?
64) 10 Ao ser invocado o serviço, são buscados no banco de dados e retornados ao cliente solicitante, todos os dados das notificações que não foram regularizadas dentro do período permitido, com base na data enviada?
65) 10 O WebService fornece um serviço responsável por autenticar os usuários que efetuam login?
66) 10 Ao receber dados do usuário que está efetuando login, o serviço verifica no banco de dados os privilégios deste usuário e retorna os resultados obtidos, ao cliente solicitante?
Os itens 12 e 22 não foram totalmente atendidos, devido aos seguintes motivos: Item 12: No cadastro das notificações, além de selecionadas opções para preenchimento dos campos, podem ser escritos textos, como por exemplo, o nome de um veículo que não encontra-se na lista de opções. Por existir esta liberdade de preenchimento, não há como garantir a validação das informações preenchidas e o sistema se torna vulnerável a eventuais erros do usuário. Item 22: Durante os testes do sistema, as notificações não foram impressas diretamente por impressoras, mas sim em arquivos .PDF, então é foi possível afirmar que a notificação será impressa exatamente como é visualizada na tela do sistema.
Assim como o desenvolvimento, os testes se iniciaram com o módulo para Pocket PC. Estes
testes foram feitos no emulador do dispositivo. Inicialmente, na tela de login, diferentes entradas de
dados foram inseridas, verificando o comportamento do sistema ao deparar-se com números, letras
e outros símbolos. O campo senha, por exemplo, deveria ocultar os caracteres informados.
Mensagens de erro ou falha deveriam ser emitidas, informando ao usuário sobre incorretas entradas
de dados. Testes de login do sistema são demonstrados na Figura 40.
77
Figura 40. Teste de login no sistema com diferentes erros de entrada de dados.
A validação do usuário é feita sob consulta ao WebServices, que por sua vez acessa o banco
de dados para autenticar as informações. Via depuração do código pôde-se acompanhar a chamada
do serviço, sua execução e consulta ao banco de dados, tratamento dos resultados e retorno das
informações. Utilizando a ferramenta SQL Server Management Studio Express as tabelas foram
abertas e os dados visualizados, comprovando o resultado das querys executadas e os resultados
obtidos.
Sob acerto ou falha na autenticação, os resultados atenderam as expectativas. As rotinas de
emissão de notificações, sincronização e atualização do sistema também foram testadas. Acessando
o botão responsável pela emissão de notificações, o formulário foi apresentado, contendo todos os
campos exigidos pela Lei, para preenchimento de uma notificação. Os dados foram digitados ou
selecionados, privilegiando sempre as listas, conforme especificado nos requisitos. Também
seguindo orientações da modelagem, informações como modelo e cidade de veículo foram tratadas,
apresentando somente informações referentes a marca e ao estado selecionado, respectivamente.
Em outra aba, foram distribuídas outras informações da notificação, estas referentes a infração
cometida pelo condutor. Em toda a notificação apenas dois campos necessitam digitação de dados,
estes são a placa e a referência. A notificação também pôde ser visualizada, demonstrando como
esta seria impressa. Nesta tela de visualização, possíveis falhas de entradas de dados ou ausência de
informações foram claramente destacados em vermelho. Além destas, outra regra estipula que,
somente após todas as informações terem sido preenchidas, o botão para imprimir ficará habilitado.
A emissão da notificação é representada pela Figura 41.
78
As informações presentes para seleção dos dados, tais como estados, marcas, modelos,
cidades, entre outros, puderam ser observados também pelos arquivos XML que acompanham o
projeto, comprovando o atendimento aos requisitos propostos. As mesmas informações presentes
nos arquivos encontram-se em banco de dados, e assim foram comprovadas.
Figura 41. Testes na emissão de notificações.
A impressão da notificação foi feita em arquivo .PDF, visto que não foi disponibilizada
impressora para o desenvolvimento e teste deste sistema. Assim sendo, a impressão foi testada e
avaliada. O arquivo foi gerado diretamente pelo driver responsável pela impressão, gerado no local
especificado pelo usuário. Além de impressa, a notificação foi gravada em arquivo XML e a
comprovação se deu sob consulta ao arquivo. Os arquivos XML facilmente podem ser lidos
utilizando-se o browser presente no PDA. A impressão da notificação está demonstrada pela Figura
42.
Figura 42. Impressão da notificação em arquivo .PDF e gravação em arquivo XML.
79
A rotina de sincronização também foi testada. Como a única ação visível, gerada por esta
rotina, é a apresentação de uma janela informado o sucesso ou falha do processo, todo o
processamento executado por este botão foi depurado. Pela depuração foi acompanhando todo o
processo de leitura das notificações gravadas no arquivo XML, conexão com WebServices e envio
das notificações lidas. No WebService foi acompanhando o processo de gravação destas
notificações em banco de dados, e o retorno dos resultados. Recebendo uma falha como resposta, o
sistema apresenta ao usuário uma janela com o aviso de falha. Obtendo o sucesso na operação,
todas as notificações presentes no arquivo XML são apagadas e o aviso de sucesso é apresentado ao
usuário. Por consulta ao banco de dados, com ferramenta apropriada, foi constatado que realmente
as notificações enviadas foram gravadas. O processo de sincronização está demonstrado pela Figura
43.
Figura 43. Processo de sincronização e comprovação dos resultados pela consulta ao
arquivo XML alterado e select executado no banco de dados.
80
A rotina de atualização também apresenta ao usuário apenas a confirmação de sucesso ou
falha da operação. Da mesma forma como a sincronização foi testada, a atualização foi depurada.
Os resultados, além de apresentados na tela, puderam ser comprovados por consulta ao banco de
dados, e consulta aos arquivos XML que sofreram modificação, conforme Figura 44.
Figura 44. Processo de atualização do sistema e comprovação dos resultados por consulta ao arquivo atualizado.
Durante os testes, conforme erros eram encontrados, eram tratados. Desta forma, procurou-
se eliminar o maior número de erros possível, principalmente erros que poderiam ser causados pelas
entradas de dados feita pelos usuários.
Os módulos Web também foram testados durante seu desenvolvimento, foram analisadas
entradas de dados e as respectivas saídas ou modificações ocorridas no banco de dados. Ao
contrário do módulo que executa no Pocket, a maioria dos módulos Web efetua consultas no banco
de dados e arquivos XML não são utilizados.
Os WebSites que emitem relação de notificações não regularizadas e emitem segunda via
das notificações, têm sua avaliação feita principalmente pelas informações apresentadas na tela do
sistema, onde as informações devem ser apresentadas, contendo todos os dados requeridos. Para a
segunda via, a relação das notificações emitidas para o veículo devem ser apresentadas e somente
aquela selecionada deve gerar uma segunda via. Todos os testes foram feitos, observando diversas
entradas de dados e os resultados apresentados. Todos os resultados atenderam as expectativas,
desde avisos de erros ou falhas até o sucesso das operações. Todos os resultados foram
comprovados não somente pelos resultados apresentados, mas também por consulta ao banco de
81
dados e depuração do código, testes que comprovaram a eficácia da solução. Os testes são
apresentados nas Figuras 45 e Figura 46.
Figura 45. Demonstração de teste do WebSite que permite impressão da segunda via de notificações.
Figura 46. Demonstração de teste do WebSite que relaciona notificações não
regularizadas.
Para o WebSite responsável pela regularização das notificações os testes seguiram o mesmo
padrão, diferentes entradas de dados foram digitadas, os resultados foram exibidos na tela e a
82
comprovação foi feita via consulta ao banco de dados e depuração do código. Uma demonstração de
testes no WebSite de regularização das notificações é apresentada na Figura 47.
Figura 47. Demonstração de teste no WebSite que regulariza notificações.
Todos os itens relacionados no checklist foram aprovados, os requisitos foram atendidos e as
regras de negócio foram cumpridas. O requisito referentes a eficiência também foram atendidos,
tais como tempo de resposta e flexibilidade de utilização dos WebSites (browsers comuns e em
PDAs).
83
4 CONCLUSÕES
Tarefas hoje executadas com uso de papel, ou blocos de papel, são de fato conhecidas por
sua precariedade desde o preenchimento até o armazenamento e consulta aos documentos. Com o
desenvolvimento das tecnologias, sabe-se que blocos de papel são substituídos por arquivos em
meio magnético, facilitando o acesso aos dados e reduzindo o espaço para armazenamento. Estas
foram características que motivaram o desenvolvimento deste projeto.
Após pesquisa sobre a presente situação dos Agentes de Trânsito, notou-se que a maneira
atual para emissão de notificações é deficiente e causa problemas de saúde nos Agentes de Trânsito.
O conhecimento desse problema serviu ainda mais como incentivo para desenvolvimento deste
projeto, com o qual pretendeu-se reduzir ou eliminar o problema.
Para desenvolvimento deste trabalho foi feita uma pesquisa bibliográfica sobre as
tecnologias presentes no desenvolvimento do sistema, entre estes programação móvel,
aprofundando-se na linguagem C#, plataforma .NET e dispositivos móveis, focando em Pocket PC.
Foi feita também uma pesquisa aprofundada sobre WebServices e outras tecnologias
envolvidas, tais como XML e SOAP. Esta tecnologia mostrou sua facilidade de utilização na
integração de sistemas, facilidade de acesso e implementação.
Com base neste conhecimento adquirido, foi projetado o sistema descrito neste documento,
que buscou uma maneira simples, porém moderna e eficaz para solucionar o problema existente na
Área Azul, para emissão de Notificações.
Outras funcionalidades foram incorporadas ao projeto para que atendessem a necessidades
existentes neste processo. Estas necessidades foram levantadas junto ao departamento de trânsito,
que se queixou de não haver maneira para emissão da segunda via das notificações, dificuldade para
encaminhamento das notificações que não foram regularizadas e até mesmo a regularização das
notificações emitidas.
Da forma como o processo de emissão de notificações funciona hoje em dia, não há uma
maneira viável para levantamento de dados estatísticos ou emissão de relatórios úteis aos
condutores notificados. Com o sistema desenvolvido, tendo as informações gravadas em banco de
dados, estas facilmente podem ser manipuladas e analisadas.
84
Todo o sistema foi modelado, os requisitos funcionais e não funcionais foram levantados,
regras de negócio foram determinadas. A modelagem foi uma etapa muito importante, que facilitou
o desenvolvimento por definir o que compete a cada módulo. Com os diagramas elaborados foi
possível ter uma visão clara de como a solução funcionaria na prática, antes mesmo de ter sido
desenvolvida. Diversos erros de planejamento foram encontrados e corrigidos, restando à etapa de
desenvolvimento, implementar a solução já elaborada, definida, analisada e aprovada.
O projeto foi desenvolvido contendo um módulo responsável pela emissão das notificações,
que é móvel e pode acompanhar os agentes de trânsito durante seu serviço. Todo o processo é
digitalizado e as notificações são armazenadas em meio magnético, o que proporciona diversos
benefícios quanto a manipulação destas informações.
Via integração, permitida pela utilização de WebServices, facilmente outros módulos
puderam ser desenvolvidos, completando o processo na Web. Três WebSites que consultam os
serviços disponibilizados pelo WebService manipulam as informações, permitindo que as
notificações sejam regularizadas, a segunda via seja impressa e notificações não regularizadas
sejam relacionadas. Diversos serviços estão disponíveis no WebService permitindo que facilmente
sejam feitas integrações com outros sistemas.
Ainda durante o desenvolvimento, os módulos foram testados, via análise dos resultados
observados na tela do sistema, análise de código por depuração e consulta a registros no banco de
dados. Depois de concluído o desenvolvimento, testes gerais avaliaram o funcionamento da solução
como um todo, modulo a módulo e suas integrações. Os requisitos foram atendidos, as regras de
negócio foram cumpridas, porém como não foram feitos testes práticos, com os verdadeiros
usuários, aos quais o sistema é destinado, não se pôde comprovar a redução dos problemas de saúde
ou aumento no número de notificações emitidas.
Diversos desafios foram encarados, mas superados, com apoio de Sites de busca e manuais
de utilização. Por se tratar de tecnologias novas ao desenvolvedor, naturalmente, as particularidades
de cada tecnologia não eram conhecidas ou foram totalmente intuitivas. Os desafios foram
relativamente fáceis de serem superados, visto que a documentação disponível é abundante.
Este desenvolvimento, que contou com as tecnologias da Microsoft, a plataforma .NET, C#
e a IDE Visual Studio 2005, comprovou a alta produtividade oferecida pelas tecnologias e a
facilidade de desenvolvimento.
85
Em um projeto futuro pretende-se testar o sistema com os verdadeiros usuários, podendo
assim verificar os resultados práticos desta solução. No futuro pretende-se também implementar
melhorias na questão da segurança, durante a comunicação entre o WebService e seus clientes.
REFERÊNCIAS BIBLIOGRÁFICAS
ALEXANDER, John ; HOLLIS, Bylly. Desenvolvendo aplicações web com visual basic .net e asp. net. São Paulo: Berkeley Brasil, 2002.
BLUMENAU. Lei 7024 de 2006. 2006. Disponível em: <http://www.leismunicipais.com.br/cgi-local/leis2.pl>. Acesso em: 02 maio. 2007. BORGES JUNIOR, Maurício Pereira. Aplicativos móveis: aplicativos para dispositivos móveis usando c#.net com a ferramenta visual studio .Net e com banco de dados mysql e sql server. Rio de Janeiro: Ciência Moderna, 2005. BORGES JUNIOR, Maurício Pereira. Desenvolvendo webservices. Rio de Janeiro: Ciência Moderna, 2005. BRASIL. Código brasileiro de trânsito. SL: JM, 1998. CAMARA, Fábio. Dominando o visual studio.net com c#. 2. ed. Florianópolis: Visual Books, 2005. CEMBRANELLI, Felipe. Asp.Net, guia do desenvolvedor. São Paulo: Novatec, 2003. COMPUSOL. Sistema de Autos de Infração de Transito - s.a.i.t. Disponível em <http://www.compusol.com.br/sait.htm>. Acesso em 04 mar. 2007. COMQUEST. Benefícios do .Net. Disponível em: <http://www.comquest.com.br/net.asp>. Acesso em: 05 mar. 2007. CONCEIÇÃO, Tiago. Avaliação da migração de uma aplicação delphi 7 (win32) para delphi 8 (microsoft .net), 2004. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade Regional de Blumenau, Blumenau, 2004. CRISPIM JUNIOR, Carlos Fernando. Análise e tecnologias para dispositivos móveis: um estudo de caso na área da saúde. 2006. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade do Vale do Itajaí, Itajaí, 2006. DAMASCENO JÚNIOR, Américo . Aprendendo asp.net com c#. 2. ed. São Paulo: Érica, 2001. DIAS, Klessis Lopes; FONTES, Wescley Pimentel. Desenvolvimento de aplicações para dispositivos móveis utilizando a plataforma j2me. Belém: Universidade Federal do Pará, 2003. D’IPPOLITO, Leonardo Chagas. Mecanismo para licenciamento de aplicativos microsoft .net baseado em assinatura digital xml. 2004. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade Regional de Blumenau, Blumenau, 2004.
87
FILHO, Brigel, MAGALHÃES, Katy. Protocolo mobis: uma solução para o desenvolvimento de aplicações seguras para dispositivos móveis. 2002. Dissertação (Mestrado em Ciência da Computação) – Universidade Federal do Ceará, Fortaleza, 2002. GALVIN, Deleon. Protótipo de sistema crm para dispositivos móveis utilizando a tecnologia .net. 2004. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade Regional de Blumenau, Blumenau, 2004. GIARETTA, Quéli ; BRANCHER, Jacques Duílio. Estudo do framework mono. Erechim: Universidade Regional Integrada do Alto Uruguai e das Missões, 2004. HADDAD, Renato Hibrahim. C#: Aplicações e Soluções. São Paulo: Érica, 2001. HADDAD, Renato Hibrahim. Visão geral do .net compact framework. .NET Framework. Disponível em: <http://msdn.microsoft.com/vstudio/device/compactfx.aspx>. Acesso em 20 mar. 2007, 2007. HADDAD, Renato Hibrahim. Entendendo aplicações móveis no .net. Mobilidade. Disponível em: <http://msdn.microsoft.com/vstudio/device/compactfx.aspx>. Acesso em 20 mar. 2007. HADDAD, Renato Hibrahim. C# :aplicações e soluções. 2. ed. São Paulo: Érica, 2001.
HP, iPAQ pocket pc, dispositivos móveis por excelência. Disponível em: <http://www.compaq.com.br/pyme/solucoes/mar_solucoes_01.html>. Acesso em 05 mar. 2007a
HP, Pocket. Disponível em: <http://h20285.www2.hp.com/estore/config.asp?cModel=LABR%2DFA673B%23AC4&mode=detailedimage>. Acesso em: 02 maio 2007c IPUF. Zona azul – instituto de planejamento urbano de florianópolis. Disponível em: <http://www.ipuf.sc.gov.br/zonaazul/zona.htm>. Acesso em 04 mar. 2007. JUNGES, Ivan Carlos. Software de controle de entregas usando dispositivos móveis e web services sobre a plataforma .net. 2006. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade Regional de Blumenau, Blumenau, 2006. KUNZE, Bia. O pda do IBGE. Garota Sem Fio. 2008. Disponível em: <http://www.odontopalm.com.br/gsf/arquivo/2007/04/o_pda_do_ibge.html>. Acesso em: 04 maio 2008. LEE, Valentino, SHNEIDER, Heather e SCHELL, Robbie. Aplicações móveis: arquitetura, projeto e desenvolvimento. Tradução: Amaury Bentes e Deborah Rüdiger. São Paulo: Pearson Education do Brasil, 2005. LEOPOLDO, Marcus R. B.. Simple object access protocol. Disponível em: <www.ipca.pt/prof/lufer/2003-2004/isi/trabalhos/trabalho1/web%20services.pdf>. Acesso em: 10 mar. 2008.
88
LUZ, Rafael P.. Utilização da tecnologia J2ME para automatização do controle de expedição de equipamentos das empresas do grupo MEG. 2007. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade do Vale do Itajaí, Itajaí, 2007. MARCORATTI, José Carlos. J2ee x .net. Disponível em: <http://www.imasters.com.br>. Acesso em: 15 mar. 2007. MENDONÇA, Aderval. Porque não é igual: as diferenças ao desenvolver soluções de mobilidade – Parte I. DevMedia. Disponível em: <http://www.devmedia.com.br>. Acesso em 01 abr. 2007. MICROSOFT CORPORATION. Microsoft C#: segredos da linguagem. Tradução Kátia Roque. Rio de Janeiro : Campus, 2001a. MICROSOFT CORPORATION. Microsoft . net, framework e aplicativos web. Tradução Izabel Cristina de Mendonça Santos, Ana Beatriz Tavares. Rio de Janeiro : Campus, 2001b. MOHR, Adilson Arthur et al. Estudo dos frameworks baseados na common language infrastructure (cli): microsoft .net framework, mono e dotgnu portable.net. Santa Cruz do Sul, 2004.
MONOBRASIL. Disponível em <http://monobrasil.softwarelivre.org>. Acesso em 15 mar. 2007.
NETO, José Morelli. Proposta de um padrão para a comunicação de dados em sistemas de telemetria baseado em webservices. 2003. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade do Vale do Itajaí, Itajaí, 2003.
NETTO, Max Mosimann. Mobilidade e dispositivos moveis. Disponível em <http://www.linhadecodigo.com.br>. Acesso em 15 mar. 2007.
NOKIA, Celular. Disponível em: <http://nds2.photos.nokia.com/EUROPE_NOKIA_COM_3/r2/press/photo/phones/jpeg/6225_1_lowres.jpg>. Acesso em: 02 maio 2007.
PALM, Palm. Disponível em: <http://www.palm.com/br/produtos/computadores/tx/>. Acesso em: 02 maio 2007.
PALMBRASIL, Visão geral do windows mobile. Disponível em <http:// www.palmbrasil.com.br/wm>. Acesso em: 20 abr. 2007.
PALMBRASIL, PDAs Smartphones Pocket PC Modelos Windows Mobile. Disponível em <http:// www.palmbrasil.com.br/windows-mobile/>. Acesso em: 20 abr. 2008.
PALMLAND. Como os aplicativos específicos podem auxiliar o mercado corporativo utilizando palms. Disponível em : <http://www.palmland.com.br/developer/materia.asp>. Acesso em: 10 mar. 2007. PASTA, Arquelau. Aplicativo para auxílio na emissão dos autos de infrações de trânsito no município de Blumenau. 2003. Trabalho de Conclusão de Curso (Graduação em Ciência da
89
Computação) – Universidade Regional de Blumenau, Blumenau, 2003. Disponível em <http://www.bc.furb.br/docs/MO/2002/266441_1_1.pdf>, Acesso em 05 mar. 2007. PIRES, Vânderson. Palm top “despapeliza” zona azul. Associação brasileira de monitoramento e controle eletrônico de trânsito: ABRAMCET. 2007 Ano IV, 15.ed.. Disponível em: <http://www.abramcet.com.br/pdf/014%20-%20abramcet.pdf>. Acesso em: 22 maio 2008. POCKETPT. Disponível em: <http://www.pocketpt.net/forum/index.php?showtopic=15071&st=0&p=84778&#entry84778>. Acesso em: 22 maio 2008. PONTES, Krishnan Lage. Proposta de um modelo de qualidade de serviço e segurança para a tecnologia de web services. 2003. Dissertação (Mestrado em Ciência da Computação) – Universidade Federal de Santa Catarina, 2003. RAMOS, Robson. Protótipo de software para envio de mensagens criptografadas para um dispositivo móvel utilizando a plataforma .net. 2004. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade Regional de Blumenau, Blumenau, 2004. RICHTER, Jeffrey. Applied microsoft.net framework programming. Redmond, Washington: Microsoft Press, 2002. SCRIBNER, Kenn Kenn e STIVER, Mark C. Applies soap :implementing. net xml web services. Indianapolis. Sams, 2002.
SETERB. Área Azul proporciona rotatividade do estacionamento. Disponível em <http://www.seterb.com.br>. Acesso em 04 mar. 2007. SILVA, Alberto. Como escolher um equipamento Windows Mobile. Microsoft Corporation. 2008. Disponível em: < www.microsoft.com/portugal/windowsmobile/artigos/artwm.mspx >. Acesso em: 01 maio 2008 SIQUEIRA, José Roberto.Programação do pocket pc com embedded visual basic .Novatec. Disponível em: <http://pt.wikipedia.org/wiki/PDA>. Acesso em 17 mar. 2007.
SKYTEL, Pager. Disponível em: <http://www.skytel.com/products/largeimages/advisorelite_large.jpg>. Acesso em: 02 maio 2007.
VENTURI, Eli. Protótipo de um sistema para controle e monitoração residencial através de dispositivos móveis utilizando a plataforma .net. Blumenau, Trabalho de Conclusão de Curso, 2005. WIKIPEDIA, ActiveSync. Disponível em: <http://pt.wikipedia.org/wiki/ActiveSync>. Acesso em: 17 abr. 2007a. WIKIPEDIA, Laptop. Disponível em: <http://pt.wikipedia.org/wiki/Laptop>. Acesso em: 17 abr. 2007b.
90
WIKIPEDIA, Pager .BBC News- Encerramento das atividades do sistema doméstico de pagers do Reino Unido em 2001. Disponível em: <http://pt.wikipedia.org/wiki/Pager>. Acesso em: 05 abr. 2007c. WIKIPEDIA, Windows mobile. Disponível em: <http://pt.wikipedia.org/wiki/Windows_Mobile>. Acesso em: 17 abr. 2007d. WILSON, Jim. Windows mobile, o inicio de uma nova era. Disponível em: <http://www.microsoft.com/brasil/msdn/windowsmobile/Default.mspx>. Acesso em: 17 abr. 2007. WINCEBRASIL. Disponível em: <http://www.winmobile.com.br/cgi-bin/windowsce/>. Acesso em: 22 maio 2008.
91
APÊNDICES
A XML SCHEMA
São apresentados os XML Schema.
A.1 XML SCHEMA ARMAZENAMENTO DAS NOTIFICAÇÕES EMITIDAS NO POCKET PC
XML Schema que define padrão do arquivo XML que armazenará as notificações emitidas,
quando no Pocket PC, conforme Figura 48.
<?xml version="1.0" encoding="utf-8"?> <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="notificacoes"> <xs:complexType> <xs:sequence> <xs:element name="notificacao"> <xs:complexType> <xs:sequence> <xs:element name="numero" type="xs:int" /> <xs:element name="fiscal" type="xs:string" /> <xs:element name="horainicial" type="xs:string" /> <xs:element name="horafinal" type="xs:string" /> <xs:element name="placa" type="xs:string" /> <xs:element name="uf" type="xs:string" /> <xs:element name="municipio" type="xs:string" /> <xs:element name="marca" type="xs:string" /> <xs:element name="modelo" type="xs:string" /> <xs:element name="categoria" type="xs:string" /> <xs:element name="especie" type="xs:string" /> <xs:element name="rua" type="xs:string" /> <xs:element name="data" type="xs:string" /> <xs:element name="referencia" type="xs:string" /> <xs:element name="ocorrido" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
Figura 48. XML Schema Armazenamento das Notificações Emitidas no Pocket PC.
93
A.2 XML SCHEMA RELAÇÃO DE RUAS DAS CIDADES
XML Schema que define padrão do arquivo XML que armazena as ruas das cidades. Estas
ruas, para estas cidades estão disponíveis para o cadastro de notificações, conforme Figura 49.
<?xml version="1.0" encoding="utf-8"?> <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="ruas"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" name="rua"> <xs:complexType> <xs:sequence> <xs:element name="estado" type="xs:unsignedByte" /> <xs:element name="cidade" type="xs:unsignedByte" /> <xs:element name="codigo" type="xs:unsignedByte" /> <xs:element name="descricao" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
Figura 49. XML Schema Ruas das Cidades.
A.3 XML SCHEMA MODELOS DE VEÍCULOS
XML Schema que define padrão do arquivo XML que armazena os modelos de veículos,
para todas as marcas, conforme Figura 50.
<?xml version="1.0" encoding="utf-8"?> <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="modelos"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" name="modelo"> <xs:complexType> <xs:sequence> <xs:element name="marca" type="xs:unsignedByte" /> <xs:element name="codigo" type="xs:unsignedByte" /> <xs:element name="descricao" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
Figura 50. XML Schema Modelos de Veículos.
94
ANEXOS
I TALÃO DE ÁREA AZUL
Modelo de Talão de Estacionamento da Área Azul de Blumenau, apresentado na Figura 51.
Figura 51. Talão de Estacionamento da Área Azul.
96
II NOTIFICAÇÃO DE REGULARIZAÇÃO DA ÁREA AZUL
Modelo de Notificação de Regularização, emitida pelos Agentes de Trânsito de Blumenau,
conforme Figura 52.
Figura 52. Notificação de Regularização.
97
III NOTIFICAÇÃO DE INFRAÇÃO DA ÁREA AZUL
Modelo de Notificação de Infração, emitida pelos Agentes de Trânsito de Blumenau.
Conforme Figura 53.
Figura 53. Notificação de Infração.
