Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
F.J .P. • B I B L I O T E C A
•90019629*
N A O n A N I M C j U F fc;-;IA [ " " I Q ' J r ; ] A
MODELO PARA INTERCÂMBIO DE
INFORMAÇÕES RELACIONADAS COM
INFRAÇÕES DE TRÂNSITO VIA
INTERNET
ANTÔNIO DA MOTA MOURA JÚNIOR
GOVERNO DE
MINAS FERAIS
F U N D A Ç Ã O J O Ã O G o v e r n o d e M i n
P I N H E I R O a s G e r a i s
ATA DA DEFESA PÚBLICA DE DISSERTAÇÃO
MESTRADO EM ADMINISTRAÇÃO PÚBLICA
ÁREA DE CONCENTRAÇÃO: TECNOLOGIAS DA INFORMAÇÃO
Aos 30 (trinta) dias do mês de abril de 2002, foi realizada a defesa pública da dissertação
intitulada "Modelo para intercâmbio de informações relacionadas com infrações de
trânsito via Internet", elaborada por ANTÔNIO DA MOTA MOURA JÚNIOR, como
requisito parcial para obtenção do título de mestre do Programa de Mestrado em
Administração Pública: Tecnologias da Informação, da Escola de Governo da Fundação João
Pinheiro. Após a apresentação do trabalho, o mestrando foi arguido pelos membros da
Comissão Examinadora, composta por Antônio Alfredo Ferreira Loureiro (Orientador) ; João
Eduardo de Resende Dantas e Paulo de Tarso Frazão Soares Linhares. A Comissão
Examinadora reuniu-se para deliberar e, considerando que a dissertação atende aos requisitos
técnicos e acadêmicos previstos na legislação do Programa, decidiu, por unanimidade, pela
aprovação da mesma. Este documento expressa o que ocorreu na sessão da defesa e será
assinado pelos membros da Comissão Examinadora.
Belo Horizonte, 30 de abril de 2002
Prof. João Eduardo de Resende Dantas (UFMG)
Prof. Paulo de Tarso Frazão Soares Linhares (FJP/EG)
Prof. Antônio Alfredo Ferreira Loureiro (Orientador) (UFMG)
Mod.7003
Modelo para intercâmbio de informações relacionadas com infrações de trânsito via internet
Dissetação apresentada à Escola de Governo - Fundação João Pinheiro, como requisito parcial para obtenção do título de Mestre em Administração Pública.
Area de Concentração: Tecnologias da Informação
Orientador: Antônio Alfredo Ferreira Loureiro
Antônio da Mota Moura Júnior
Belo Horizonte Abril/2002
m i IM d ïi join Nimm«
ÔíRu-CTVrCA
T*)._, mm.
Ao meu pai.
Agradecimentos
Primeiramente, agradeço ao professor Antônio Alfredo pela gentileza em
aceitar o convite para orientar-me e pela paciência e tranqüilidade durante nossas
reuniões.
Agradeço à PRODABEL pela oportunidade de participar do programa de
capacitação que possibilitou a inscrição neste curso de mestrado.
Agradeço, também, à Tatiana, à minha mãe e aos meus irmãos que, desde
o começo, compreenderam os sacrifícios e as cobranças impostas pelo curso de
mestrado e, com isso, estiveram sempre ao meu lado dando incentivo e apoio.
Finalmente, agradeço a Deus por ter me ajudado a vencer mais este
desafio, d ando-me equilíbrio para enfrentar aqueles momentos nos quais o
mestrado exige maior dedicação.
SUMÁRIO
índice de Figuras VI
Resumo VII
Abstract VIII
1 - Introdução - 9 1.1 -Introdução 9 1.2 - Definição do Problema 9 1 . 3 - Objetivos do Trabalho 11 1.4 - Aspectos Metodológicos 12 1.5 - Organização da Dissertação 12
2 - Fundamentos e Trabalhos Relacionados 13 2.1 - Introdução 13 2.2 - Protocolos de Comunicação 13 2.3 - Tecnologias para Acesso a Banco de Dados via Internet 15 2.4 - A X M L 19 2.5 - Mecanismos de Segurança 21
3 - Sistemas de Troca de Informações de Trânsito 23 3 . 1 - Introdução 23 3.2 - Troca de Informações entre Estado e Município 23 3.3 - Troca de Informações Interestaduais 27 3 . 4 - O R E N A C O M 28
4 - Definições e Requisitos 31 4.1 - Introdução 31 4.2 - O Esquema de Dados Bás ico 31 4.3 - Requisitos do Software de Processamento de Infrações 36
4.4 - Requisitos de Ambiente 37
5 - Modelo para Intercâmbio de Informações 39 5 . 1 - Introdução 39 5.2 - Modelagem de Casos de U s o 39 5.3 - Processo de Identificação de Origem do Veículo 42
5.3.1 - Processo de Identificação de Origem do Veículo no Sistema do Órgão Central 42 5.3.2 - Processo de Identificação de Origem do Veículo no Sistema do Órgão Conveniado 44
5.4 - Processo de Troca de Informações de ATT 47 5.5 - Processo de Troca de Informações de NTT 50 5.6 - Processo de Troca de Informações de Recursos 53 5.7 - Classes e Métodos Referenciados pelo Modelo 56
5.7.1 - A Classe ATT e os Tipos de Atributos 59 5.7.2 - Demais Classes Referenciadas pelo Modelo 63
5.8 - Documentos X M L 68 5.8.1 - Definição da Linguagem de Esquema XML 68 5.8.2 - Documentos de Dados 69 5.8.3 - Pacote de Transmissão 71
6 - Arquitetura e Protótipo 76 6.1 - Introdução 76
Sumário I V
6.2 - Diagrama de Implantação e Diagrama de Componentes 76 6.2.1 - Aplicação Web 79 6.2.2 - Driver para o BD 80 6.2.3 - Parser XML 82 6.2.4 - Software Servidor HTTP e Plug-in para Mecanismo de CGI ou Server Pages 85
6.3 - Protótipo 87 6.3.1 - O Ambiente de Implementação do Protótipo 88 6.3.2 - As Interfaces e o Fluxo de Documentos 90
7 - Comentários a Respeito do Modelo Proposto 95 7.1 - Introdução 95 7.2 - Considerações Legais 95 7.3 - Comentários Técnicos 9 6 7.4 - Melhoramentos Futuros 97
8 - Conclusão 99
Apêndice A - Questionários de Pesquisa 102 A. 1 - Questionário de Pesquisa - Município 102 A.2 - Questionário de Pesquisa - Estado 103
Apêndice B - Tabela de Tipos de Inconsistência 105
Apêndice C - XML Schema para os Documentos de Dados do Modelo.....—....... 106
Apêndice D - XML Schema para o Pacote de Transmissão — 113
Apêndice E - Códigos Fonte do Protótipo 115 E. 1 - D D L para Criação das Tabelas no M S Access 115 E.2 - Códigos Fonte dos Programas Java 116 E.3 - Códigos Fonte das Páginas HTML 146
Referências Bibliográficas • 148
Sumário V
índice de Figuras
Figura 2.1 - Esquema básico de funcionamento da Web 16 Figura 2.2 - Processos ISAPI e CGI 18 Figura 3.1 - Transferência de informações de infrações de trânsito entre BHTRANS e PRODEMGE.... 26 Figura 4.1 - Esquema ER Básico 33 Figura 5.1 - Especialização de Sistema de Órgãos de Trânsito 40 Figura 5.2 - Diagrama de Casos de Uso para o Modelo de Intercâmbio de Informações de Infrações de
Trânsito 42 Figura 5.3 - Diagrama de Caso de Uso para a identificação de origem do veículo no Sistema Central.... 42 Figura 5.4 - Diagrama de Seqüência para o Caso de Uso Identificação da Origem do Veículo no Sistema
do Órgão Central 43 Figura 5.5 - Diagrama de Caso de Uso: identificação de origem do veículo no Sistema Conveniado 44 Figura 5.6 - Diagrama de Seqüência para o Caso de Uso Identificação da Origem do Veículo no Sistema
do Órgão de Trânsito Estadual 44 Figura 5.7 - Diagrama de Seqüência para o Caso de Uso Identificação da Origem do Veículo no Sistema
do Órgão de Trânsito Municipal 45 Figura 5.8 - Diagrama de Caso de Uso para a troca de informações de AIT 47 Figura 5.9 - Diagrama de Seqüência para o Caso de Uso Troca de Informações de AIT - identificação e
envio de AIT's 48 Figura 5.10-Diagrama de Seqüência para o Caso de Uso Troca de Informações de AIT - consistência de
AIT 49 Figura 5 . 1 1 - Diagrama de Caso de Uso para a troca de informações de NIT 50 Figura 5.12 - Diagrama de Seqüência para a geração das NTT's 51 Figura 5 . 1 3 - Diagrama dc Seqüência para a emissão das NIT's 51 Figura 5.14 - Diagrama de Seqüência para o Caso de Uso Troca de Informações de NTT 52 Figura 5.15 - Diagrama de Caso de Uso para a troca de informações de Recursos 54 Figura 5 . 1 6 - Diagrama dc Seqüência para a Troca de Informações de Recursos - processo de registro do
recurso 54 Figura 5.17 - Diagrama dc Seqüência para a Troca de Informações de Recursos - processo de informação
do resultado do recurso 56 Figura 5.18 - Diagrama dc Classes 57 Figura 5.19 - Pacotes dc Classes 58 Figura 5.20 - Composição da Mensagem SOAP 72 Figura 5.21 - Composição do Pacote de Transmissão 73 Figura 6.1 - Diagrama dc Implantação 77 Figura 6.2 - Diagrama dc Componentes 78 Figura 6.3 - Diagrama dc Componentes utilizando o Tomcat 80 Figura 6.4 - Hierarquia DOM 83 Figura 6.5 - Página para Verificação da Origem do Veículo 91 Figura 6.6 - Página para Envio dos documentos xmlAit para os respectivos destinos 92
índice de Figuras VI
Resumo
Desde 22 de janeiro de 1998, quando entrou em vigor o Código de Trânsito
Brasileiro - Lei N° 9.503, de 23 de setembro de 1997 -, as funções referentes à gestão
do trânsito foram distribuídas entre a União, os Estados e os Municípios. Esse fato fez
com que os órgãos de trânsito estaduais e municipais estabelecessem formas de troca de
informações referentes às infrações de trânsito.
Devido à urgência em se encontrar uma solução que atendesse àquela demanda,
o problema foi tratado isoladamente no âmbito de cada Estado. Sendo assim, os
Municípios passaram a ter acesso à base de dados de veículos e condutores, apenas, de
seus respectivos Estados, o que gerou problemas no que diz respeito à imposição de
penalidades à infratores condutores de veículos de outros Estados.
Em fevereiro de 2002, foi implantado o RENACOM - Registro e Câmara
Nacional de Compensação de Multas Interestaduais ~, um projeto coordenado pelo
DENATRAN, que surge para tratar o problema das multas relacionadas a veículos
licenciados em unidades da federação distintas daquela na qual ocorreu a infração.
Paralelamente a isso, a evolução tecnológica no campo da informática e da
comunicação e a expansão da rede mundial de computadores, a Internet, vem auxiliando
empresas a agilizarem seus processos de trabalho e a melhorarem as relações entre si e
as relações com seus clientes. No caso da Administração Pública, tais tecnologias vem
se tornando úteis para a interação com o cidadão e para a melhoria dos seus
procedimentos internos.
Baseado nessas tecnologias aderentes à Internet e no Código de Trânsito
Brasileiro, esta dissertação propõe a criação de um modelo alternativo ao RENACOM
para a troca das informações relacionadas com infrações de trânsito entre órgãos,
estaduais ou municipais, responsáveis por sua gestão. Esse modelo apresenta uma
arquitetura que permite o acesso a dados armazenados em bancos de dados distribuídos
e heterogêneos utilizando como meio de transmissão daqueles dados a Internet.
Além disso, este trabalho procura contribuir para que a troca de informações
entre órgãos da Administração Pública torne-se mais eficiente.
R e s u m o VII
Abstract
Since January 22, 1998, when the Brazilian Traffic Code - Law 9.503, passed in
September 23, 1997 - went into effect, the traffic control and administrative functions
were distributed among Federal, State and Municipal governments. This distribution
led to the establishment of methods for the exchange of information on traffic violations
among management authorities.
Due to the urgency in finding a solution for the exchange, the problem was
treated separately within each State. Consequently, municipal traffic authorities gained
access to State-owned databases on vehicles and drivers, but the problem persisted in
the cases in which the violator was registered in another State.
In February of2002, a nation-wide chamber for the compensation of interstate
traffic fines (RENACOM - Registro e Câmara Nacional de Compensação de Multas
Interestaduais) was established, in a project that was coordinated by the Federal-level
authority, DENATRAN. RENACOM was created to focus on the problem of managing
fines related to vehicles that are registered in a State that is not the one in which the
violation occurred.
On the other hand, technological evolution in the field of the information and
communication, along with the expansion of the Internet, provides means for speeding
up and enhancing work processes in the organizations, the relationships among
organizations and with their customers. In the case of public administration, such
technologies enhance the interaction with the citizens, through the improvement of
internal processes.
Based on Internet-related technologies and on the Brazilian Traffic Code, this
dissertation proposes the creation of a model that is an alternative to RENACOM for
the exchange of information related to traffic violations nationwide, among traffic
authorities in the three spheres of government. This model uses an architecture that
allows for the access to data stored in distributed and heterogeneous databases, using
the Internet as the communications medium.
With that, this work intends to propose alternatives for a more efficient exchange
of information among public entities.
Abstract VIII
1 - Introdução
1.1-Introdução
A evolução da Internet nos últimos anos vem agilizando a forma como as
organizações se comunicam entre si e com seus clientes. No caso da Administração
Pública, a oferta de serviços e a possibilidade de racionalizar determinados
procedimentos através de aplicações Web integrando diferentes órgãos, a torna um
ótimo meio para ser explorado.
Entretanto, existe uma diversidade de sistemas gerenciadores de banco de dados
(SGBDs) [ELMAOO] utilizados pelos órgãos da Administração Pública. Essa
heterogeneidade dificulta a troca de informações. Modelos de intercâmbio destas
informações, que padronizem a forma como os dados são utilizados, podem contribuir
para minimizar o problema.
A presente dissertação se enquadra nas áreas temáticas com aplicabilidade na
Administração Municipal de Belo Horizonte relacionadas com "Integração de Dados" e
com "Aplicações para a Web". Também busca colaborar para uma melhoria na troca de
informações relacionadas com infrações de trânsito que estão armazenadas em bancos
de dados heterogêneos, utilizando, para isso, a Internet [TANE97].
1.2 - Definição do Problema
Em uma cidade do porte de Belo Horizonte, o trânsito possui uma influência
muito grande sobre a maioria das pessoas. O seu bom funcionamento é de fundamental
importância para que se possa proporcionar uma melhor qualidade de vida para os
cidadãos [FOLH98].
Um fator importante para se buscar esse bom funcionamento foi a criação do
Código de Trânsito Brasileiro (CTB) - Lei N° 9.503, de 23 de setembro de 1997 - que
entrou em vigor em 22 de janeiro de 1998. Uma boa visão das normas estabelecidas
pelo CTB pode ser encontrada em Rizzardo (2000) no livro "Comentários ao Código de
Trânsito Brasileiro" [RIZZ00I.
O CTB distribuiu as funções de gestão do trânsito entre a União, os Estados e os
Municípios. Entretanto, esta distribuição de responsabilidades gerou uma grande
Capitule 1 - Introdução 9
demanda de serviço nos órgãos gestores. No caso dos Estados, os sistemas existentes
nos DETRAN's deveriam ser adaptados para a nova realidade e, no caso dos
Municípios, novos sistemas deveriam ser disponibilizados. Isso acarretou uma
sobrecarga nas áreas de informática desses órgãos gestores.
Este aumento na demanda dos serviços de informática e a necessidade de
soluções rápidas fizeram com que os problemas de troca de informações fossem tratados
apenas isoladamente no âmbito de cada Estado. Esse isolamento fazia com que os
Municípios de um determinado Estado não tivessem acesso a informações dos veículos
e condutores dos demais Estados. Por isso, multas por infrações cometidas em unidade
da Federação diferente da do licenciamento do veículo não eram enviadas aos
responsáveis pelo seu pagamento. Em resumo, as infrações eram registradas mas os
infratores não eram apenados, o que configurava uma falha no processo de fiscalização.
Quando a pesquisa relacionada a esta dissertação iniciou-se, a não implantação
de um mecanismo de compensação de multas, referenciado no CTB (art. 12, VIII),
agravava o problema descrito acima e reforçava, ainda mais, a necessidade de se buscar
alternativas para solucioná-lo.
A Tabela 1.1 apresenta o percentual, em relação ao total de AIT's de papel, dos
AIT's lavrados por agentes de trânsito em Belo Horizonte, que foram atribuídos a
veículos de outros Estados, no ano de 2000. Observamos que do total de ATT's lavrados
até outubro de 2000, um percentual de 6,9% estão relacionados a veículos de outros
Estados. Tabela 1.1 - AIT's de papel relacionados a veículos de outros Estados, em 2000
Jan Fev Mar Abr Mai Jun : Jul Ago Set Out Total
5,88% 6,09% 6,09% 7,28% 6,07% 6,75% 8,03% 10,50% 6,32% ¡ 4,50% 6,90%
Fonte: BHTRANS, outubro de 2000
Em Belo Horizonte, a BHTRANS (Empresa de Transportes e Trânsito de Belo
Horizonte) é a empresa responsável pela gestão do trânsito no âmbito municipal e
busca, juntamente com a PRODABEL (Empresa de Informática e Informação do
Município de Belo Horizonte), resolver os problemas de troca de informação com o
Estado de Minas Gerais. Entretanto, até este momento, não possui acesso às
informações de outros Estados.
A partir do segudo semestre de 2001, foi desenvolvido o RENACOM - Registro
e Câmara Nacional de Compensação de Multas Interestaduais -, uma parceria do
Capítulo 1 - Introdução 10
DENATRAN, do Banco do Brasil e da Cobra Computadores. Este projeto, que foi
implantado em fevereiro de 2002, deu origem a um modelo que permite aos órgãos de
trânsito aplicarem as multas às infrações de trânsito cometidas por condutores de
veículos licenciados em unidades da federação diferentes daquela na qual ocorreu a
infração.
1.3 - Objetivos do Trabalho
Esta dissertação busca definir um modelo para a troca de informações
armazenadas em SGBD's heterogêneos, utilizando a Internet. Dessa forma, tenta
contribuir para que a troca de informações entre órgãos da Administração Pública se
torne cada vez mais eficiente.
inicialmente, este trabalho buscava uma solução para um problema da
administração pública que ainda não havia sido resolvido, a saber, o acesso às
informações de veículos e condutores de quaisquer unidades da federação e a imposição
de multas de trânsito aos infratores, independente da sua UF de origem.
Naquele momento, este projeto buscava especificar um modelo que fosse
complementar e, ao mesmo tempo, independente dos modelos de processamento de
infrações de trânsito existentes nos diversos órgãos de trânsito do país. O modelo seria
complementar, no sentido de incorporar uma nova característica no que se refere a
veículos de outros Estados. E seria independente, pois não se apoiava na forma como o
Município troca informações com o Estado.
Os objetivos de ser complementar e independente continuam em vigor, porém, já
existe um modelo que oferece o acesso aos dados de veículos e condutores registrados
em qualquer unidade federativa do Brasil. Como citado anteriormente, este modelo é
definido pelo RENACOM.
Nesse ponto, o modelo proposto nesta dissertação passa a ser uma solução
alternativa ao RENACOM ou, até mesmo, uma opção para mudança no modo como o
RENACOM interage com os vários órgãos de trânsito, uma vez que aquele projeto
utiliza uma estrutura de arquivo seqüencial e processamento batch, ao passo que este
modelo busca um acesso direto entre os órgãos e utiliza XML para estruturar seus
documentos.
Capítulo 1 - Introdução 11
Vale ressaltar que existem aspectos políticos e organizacionais que envolvem a
problemática apresentada. Entretanto, este trabalho tem por objetivo propor uma
alternativa técnica para a solução do problema levantado.
1.4 - Aspectos Metodológicos
O tema da dissertação envolve questões referentes à legislação de trânsito e às
tecnologias da informação, mais especificamente, assuntos relacionados com acesso a
informações em SGBDs e troca de informações via Internet.
Dentro desta perspectiva, o trabalho foi iniciado verificando as tecnologias
existentes para o desenvolvimento de aplicações na Web. Em seguida, através de uma
pesquisa de campo, buscou-se conhecer alguns modelos de processamento de infrações
de trânsito utilizados pelos órgãos que compõem o Sistema Nacional de Trânsito.
A partir das informações colhidas, foi elaborado o modelo e preparado o texto
da dissertação.
1.5 - Organização da Dissertação
Esta dissertação está dividida em mais sete capítulos, além deste primeiro, que
corresponde à introdução.
O segundo capítulo apresenta uma visão geral sobre as tecnologias utilizadas
para o desenvolvimento de aplicações que utilizam a Internet.
O capítulo três resume alguns modelos de troca de informações de infrações de
trânsito entre órgãos de trânsito municipais e estaduais, além de apresentar a solução
desenvolvida pelo DENATRAN, o RENACOM.
O capítulo quatro apresenta algumas considerações a respeito dos requisitos para
implementação do modelo.
O capítulo cinco corresponde à especificação do modelo proposto nesta
dissertação, definindo os processos e as estruturas dos documentos a serem transmitidos
entre os órgãos.
Os componentes necessários para a implementação do modelo e uma possível
arquitetura para a sua implantação são apresentados no capítulo seis. Baseado nisso, foi
desenvolvido um protótipo que está descrito neste capítulo.
Alguns comentários a respeito do modelo são feitos no capítulo sete.
Finalmente, o capítulo oito apresenta a conclusão do trabalho.
Capítulo 1 - Introdução 12
2 - Fundamentos e Trabalhos Relacionados
2.1 - Introdução
O modelo proposto por este trabalho baseia-se nas tecnologias existentes para
troca de informações e para desenvolvimento de aplicações que acessam banco de dados
e que utilizam a Internet.
Este capítulo tratará dessas tecnologias, buscando citar alguns trabalhos que
apresentam sua utilização em aplicações existentes.
Os aspectos técnicos considerados aqui referem-se às seguintes questões:
• protocolos de comunicação utilizados na Internet;
• utilização de banco de dados na Internet (tecnologias de acesso a dados na Web, tais
como, CGI, ASP/ADO, DLL's ISAPI/NSAPI, Servlets Java);
• a XML como uma forma de estruturação de dados trocados via Internet;
• segurança da informação através de assinatura digital, chaves pública e privada e
message digest (hash).
2.2 - Protocolos de Comunicação
Nesta seção apresentaremos quatro protocolos para troca de informações
amplamente utilizados na Internet, são eles: HTTP, FTP, SMTP e POP3. Esses
protocolos pertencem à camada de aplicação do modelo de referência TCP/IP
[TANE97] e suas especificações são formalizadas em relatórios técnicos produzidos
pela IETF Internet Engineering Task Force), chamados de RFCs Request for
Comments).
O HTTP HiperText Transfer Protocol) [RFC1945, RFC2616], é o protocolo
mais utilizado na internet, pois é o padrão de transferência da Web desde 1990. Segundo
Tanenbaum [TANE97], o "HTTP é um protocolo ASCII semelhante ao SMTP". O
HTTP utiliza muito das construções definidas pelo MIME Multiporpose Internet Mail
Extensión) [RFC2045].
De acordo com o relatório RFC 1945 a operação do HTTP é a seguinte:
"O protocolo HTTP é baseado no paradigma solicitação/resposta. Um cliente
estabelece uma conexão com o servidor e envia uma requisição a ele no
Capítulo 2 - Fundamentos e Trabalhos Relacionados 13
formato: método da solicitação, URI e a versão do protocolo seguida por uma
mensagem do tipo MIME contendo modificadores de solicitação, informação do
cliente e possível conteúdo do corpo da mensagem. O servidor responde com
uma linha de status, incluindo a versão do protocolo da mensagem e um código
de sucesso ou de erro seguido por uma mensagem do tipo MIME contendo
informação do servidor, meta-informação da entidade, e possível conteúdo do
corpo da mensagem."
No que diz respeito à troca de dados estruturados utilizando o HTTP, as
aplicações utilizando XML, apresentadas na seção 2.4, aparecem como bons exemplos.
O FTP (File Transfer Protocoí) [RFC959], tem como objetivos: promover o
compartilhamento de arquivos (programas de computador e/ou dados); encorajar o uso,
indireto ou implícito, de computadores remotos (via programas); proteger o usuário de
variações nos sistemas de armazenamento de arquivos entre hosts; transferir dados de
forma confiável e eficiente. Vários sites na Web oferecem serviços de transferência de
arquivos downloads e uploads) utilizando esse protocolo.
Podemos citar a troca de informações sobre Infrações de Trânsito, realizada
entre BHTRANS e PRODEMGE, como um exemplo prático da utilização do FTP para
auxiliar atividades corporativas. Nesse caso, os arquivos gerados pelo processamento
realizado na PRODEMGE sobre os dados enviados pela BHTRANS são armazenados
em uma máquina servidora FTP conectada à Internet. Uma aplicação na BHTRANS,
desenvolvida em Delphi, conecta àquela máquina, busca os arquivos apropriados e
dispara o processamento dentro do sistema municipal.
O SMTP (Simple Mail Transfer Protocoí) [RFC821] é o protocolo utilizado na
transmissão de e-mail. Segundo o relatório RFC 821, o seu objetivo é realizar esta tarefa
de forma confiável e eficiente e é independente de qualquer subsistema de transmissão,
exigindo apenas um canal confiável e ordenado de stream de dados, tal como o TCP. Na
Internet, um servidor SMTP é utilizado para gerenciar e armazenar as mensagens
enviadas através do correio eletrônico.
Já o POP3 (Post Office Protocoí - Vesion 3) [RFC1939] é o protocolo utilizado
para extrair mensagens de correio eletrônico armazenadas em um servidor. Seu objetivo
é permitir a uma estação de trabalho acessar dinamicamente uma caixa de correio em
um servidor de maneira otimizada. É um protocolo simples que não pretende fazer
grandes manipulações nas mensagens no servidor. Basicamente, a mensagem é copiada
para a estação de trabalho (download) e, então, ela é apagada do servidor.
Capítulo 2 - Fundamentos e Trabalhos Relacionados 14
A combinação dos protocolos SMTP e POP3 é amplamente utilizada na
transmissão e recepção de mensagens não estruturadas de correio eletrônico. Entretanto,
eles podem ser utilizados para a troca de dados estruturados que possibilitem o
desenvolvimento de aplicações para processá-los.
2.3 - Tecnologias para Acesso a Banco de Dados via Internet
Esta seção apresentará tecnologias que permitem o acesso e a troca de dados
armazenados em arquivos ou em SGBD's [ELMAOO] através da Internet. Basicamente,
serão apresentadas tecnologias que dão suporte à World Wide Web (WWW ou,
simplesmente, Web) [TANE97]. Entretanto, a troca de dados através do processamento
de e-mails, também, será abordada.
A expansão da Internet, fora do meio científico e acadêmico, chamou a atenção
das empresas para o potencial deste meio de comunicação, tanto no que se refere à
própria comunicação e à troca de informações quanto ao aspecto econômico. Nesse
contexto, a Web é um dos grandes responsáveis por tal expansão, graças à sua facilidade
de utilização e à simplicidade da HTML (HiperText Markup Languagé) [JAC099,
W3C01a], que consiste na linguagem de estruturação dos documentos acessados pela
WWW, mais conhecidos como páginas HTML ou páginas Web. Tanenbaum define a
WWW como "a estrutura arquitetônica que permite o acesso a documentos vinculados
espalhados por milhares de máquinas na Internet" [TANE97].
Entretanto, a natureza estática das páginas HTML, na sua versão 1.0,
apresentava-se como uma barreira para que aplicações mais sofisticadas fossem
construídas, principalmente as que envolviam banco de dados. A possibilidade de
criação de formulários, a partir da HTML 2.0, e o desenvolvimento de tecnologias para
o tratamento dos dados desses formulários trouxeram novas perspectivas para as
aplicações desenvolvidas para Web. Isso possibilitou a geração de páginas HTML
dinamicamente, o que contribuiu para que tais páginas pudessem apresentar dados
armazenados em arquivos ou em SGBD's no momento do acesso.
A WWW é, basicamente, uma apücação cliente/servidor. A Figura 2.1 apresenta
um esquema básico do fluxo das informações entre os servidores e os clientes Web,
bem como da integração das tecnologias de acesso a dados nessa estrutura.
Capítulo 2 - Fundamentos e Trabalhos Relacionados 15
Figura 2.1 - Esquema básico de funcionamento da Web.
Os programas clientes são, geralmente, os browsers. Os servidores Web, ou
servidores HTTP, são programas, ou processos, que são executados em diversos
computadores na Internet e que são capazes de atender às solicitações dos programas
clientes. [MARC99]
De maneira superficial, o fluxo da Figura 2.1 pode ser descrito como se segue. O
browser transmite pela Internet uma solicitação a um servidor Web para que este
retorne uma página HTML ou, ainda, para que tal servidor execute algum programa
(CGI, ISAPI, ASP, JAVA etc) que gere uma página dinamicamente. O servidor Web é
localizado por um URL (Uniform Resource Locator) [RFC2396, TANE97] informado
pelo browser. Ao receber a solicitação, o servidor verifica se o documento, ou o
programa, especificado no URL está disponível. Caso afirmativo, o servidor transmite
o arquivo solicitado para o cliente ou, no caso de páginas geradas dinamicamente,
solicita a execução do programa gerador e transmite o resultado para o browser.
Finalmente, o browser apresenta o conteúdo do arquivo recebido na tela do computador
cliente. [FRANOO]
Entre as tecnologias utilizadas peia Web que possibilitam o acesso a dados serão
destacadas neste trabalho a CGI (Commom Gateway Interface), ISAPI (Internet Server
Application Programming Interface), NSAPI (Netscape Application Program
Interface), Servlets Java e ASP/ADO (Active Sever Pages / ActiveX Data Objects).
A CGI, como define Marcon [MARC99], "é um conjunto de normas e
especificações técnicas que definem como o servidor deve receber requisições de
execução de programas, efetuar o processamento desses programas e retornar resultados
para o requisitante." Elmasri e Navathe [ELMAOO] a define como uma interface padrão
que age como um middleware - a camada de software adicional entre o front-end da
interface do usuário e o SGBD que facilita o acesso a banco de dados heterogêneos. O
W3C (World Wide Web Consortium) apresenta a CGI da seguinte maneira:
Capítulo 2 - Fundamentos e Trabalhos Relacionados 16
"Um servidor HTTP é freqüentemente utilizado como um gateway para sistemas
de informação legados; por exemplo, um conjunto de documentos ou uma
aplicação de banco de dados existente. A Common Gateway Interface é um
acordo entre os implementadores de servidores HTTP sobre como integrar tais
scripts e programas de gateway. Ela é tipicamente utilizada em conjunto com
formulários HTML para construir aplicações de banco de dados." [W3C99]
Para executar suas funções, um programa ou script CGI, pode ser desenvolvido
em diversas linguagens de programação. Vale observar, ainda, que a tecnologia CGI
não se restringe ao acesso a banco de dados.
Segundo Marcon [MARC99], a vantagem da CGI em relação às outras
tecnologias aqui apresentadas está na sua portabilidade, ou seja, a capacidade de poder
ser utilizada em múltiplas plataformas. Já a sua principal desvantagem é o fato desta
abordagem poder sobrecarregar o servidor provocando uma queda de performance,
devido à necessidade de criação de um novo processo CGI para cada requisição do
usuário. No caso de acesso a SGBD's, como citado por Elmasri e Navathe [EMLAOO],
"cada processo cria uma nova conexão com o SGBD e o servidor Web deve esperar até
os resultados serem entregues".
As tecnologias ISAPI, NSAPI e ASP/ADO foram desenvolvidas para tentar
minimizar as limitações da CGI e são dependentes do servidor ou do sistema
operacional aos quais estão ligadas. Marcon [MARC99] apresenta a total restrição de
portabilidade entre múltiplas plataformas como sendo a maior desvantagem dessas
tecnologias.
Os aplicativos ISAPI da Microsoft e NSAPI da Netscape, são geralmente
implementados através de DLL's (Dynamic-link Libraries), no ambiente Windows.
Uma DLL é "um recurso da família de sistemas operacionais Microsoft Windows que
suporta rotinas executáveis - em geral servindo a uma função ou a um conjunto de
funções específicas - que serão armazenadas separadamente como arquivos com a
extensão -dll, sendo carregadas apenas quando forem chamadas pelo programa que
necessitar delas. Isso economiza memória durante a execução dos programas e permite
a reutilização do código" [MICR98]. Essas aplicações são potencialmente mais rápidas
que a CGI, pois rodam no mesmo espaço de processo do servidor Web. Isto, entretanto,
faz com que uma única instância da aplicação esteja rodando junto ao servidor, criando
a necessidade dela estar preparada para um extremo processamento concorrente. A
Capítulo 2 - Fundamentos e Trabalhos Relacionados 17
grande preocupação é o fato de que um erro na DLL pode comprometer o servidor
HTTP. [FRANOO]
O esquema da Figura 2.2, apresentado por Franklint, mostra a relação dos
processos gerados pelas tecnologias ISAPI e CGI.
ESAPI CGI
E s p a ç o de P r o c e s s o do Sistema
E s p a ç o de P r o c e s s o do Servidor W e b
Aplicação ISAPI
Aplicação ISAPI
E s p a ç o de P r o c e s s o do Sistema
E s p a ç o de P r o c e s s o do Servidor W e b
Aplicação CGI
Aplicação CGI
Figura 2.2 - Processas ISAPI e CGI.
Já o ASP é "um ambiente para desenvolvimento de aplicações Web, que foi
criado pela Microsoft, e surgiu juntamente com o lançamento do Internet Information
Server 3.0" [FRANOO], que é o servidor Web da Microsoft. Marcoratti [MCRT99]
afirma que o ASP apresenta-se como uma evolução da tecnologia CGI. Assim como as
outras tecnologias apresentadas nessa seção, o ASP possibilita a criação de páginas
HTML dinamicamente.
O ASP utiliza o ADO - uma solução Microsoft, assim como o ASP - para
fornecer acesso a bases de dados. O ADO é um esquema de objetos para acesso a banco
de dados. Segundo a Microsoft, a vantagem do esquema ADO é a alta velocidade, a
facilidade de uso e a baixa utilização de memória. [MCRT99, MICR98]
Tentando minimizar o problema causado pela CGI de overhead da CPU e, ao
mesmo tempo, buscando uma independência de plataforma, foi proposto pela
comunidade Java a utilização de Servíeis Java.
Marchai [MACH00] apresenta os servíeis como "a versão Java para scripts
CGT'. Eles incluem uma API (Aplication Programming Interface) padrão para realizar a
interface do Java com o servidor Web.
"Servíeis são eficazes porque são carregados apenas uma vez, quando o
servidor é iniciado. O servidor Web pode reutilizar o servlet para vários
pedidos. Além do mais, os servíeis são portáteis e funcionam com todos os
principais servidores Web. " [MACH00]
Capítulo 2 - Fundamentos e Trabalhos Relacionados 18
Cezar Taurion [TAUR97] apresenta uma analise dessas tecnologias, dividindo-
as em três categorias:
• SSI (Server Side Includes), que são diretivas especiais inseridas em documentos
HTML, que o servidor HTTP reconhece, tal como o ASP ;
• CGI (Commom Gateway Interface), é a interface descrita anteriormente nesta seção;
• API (Aplication Programming Interface), são as tecnologias cujo o código é
inserido como extensão do servidor e acionado diretamente por solicitação do
browser, como no caso das DLL's ISAPI/NSAPI ou dos Servíeis Java.
As características analisadas e sua relação com cada categoria são apresentadas
na Tabela 2.1. Tabela 2.1 - Características Principais das Alternativas de Acesso ao Servidor
Característica SSI CGI API Flexibilidade Baixa Alta Alta Expertise requerida do desenvolvedor Baixa Média Alta Tempo de desenvolvimento e teste Baixo Médio Alto Overheadàa CPU Médio Alto Baixo Fonte: Developer's Magazine, Março 1997.
Além da WWW, podemos utilizar outros meios para a transmissão de dados que
serão extraídos ou inseridos em banco de dados através da Internet. Um desses meios é
a utilização do e-mail. Podemos desenvolver um aplicativo que implemente o protocolo
POP3 e processe as mensagens recebidas através de uma conta de e-mail, inserindo-as
em um banco de dados. Da mesma forma, uma outra aplicação poderá extrair dados de
um SGBD, estruturar uma mensagem e enviar um e-mail para um endereço pré
estabelecido. Vários serviços disponibilizados na Internet utilizam esse recurso como,
por exemplo: solicitações de suporte a determinado produto, expressão de opinião
sobre a qualidade de um serviço etc. Um exemplo prático pode ser encontrado em
[FRANOO], capítulo 16.
2.4-AXML
A XML (Extensible Markup Language) [BRAYOO] é uma linguagem de
marcação especificada pelo W3C (World Wide Web Consortium) e, assim como HTML
(HiperText Markup Language) [JAC099, W3C01a], faz parte da família SGML
(Standard Generalized Markup Language) - ISO 8879. Segundo o W3C, seu objetivo é
disponibilizar um SGML genérico que possa ser servido, recebido e processado na Web,
assim como se faz com a HTML.
Capítulo 2 - Fundamentos e Trabalhos Relacionados 19
Segundo Richard light [LIGH99], a relação entre SGML, XML e HTML é a
seguinte: enquanto XML é um subconjunto da SGML, possibilitando a definição,
através de um DTD (Document Type Definitiori) [BRAYOO] ou de um XML Schema
[FALL01, THOM01, BIRO01], das tags (marcações) a serem utilizadas no documento
XML; HTML corresponde a uma apücação específica de SGML, com tags predefinidas
que são interpretadas pelos navegadores (browsers) Web. Informações gerais sobre
SGML podem ser encontradas em [ARMSOO] e [LIGH99].
Mais especificamente, a XML realiza uma marcação generalizada, que
corresponde à informações adicionais acrescentadas no texto de um documento para
descrever a sua estrutura, e não a sua aparência [LIGTH99]. Ela corresponde à uma
metalinguagem, o que significa ser uma linguagem para a especificação de metadados
que, por sua vez, são dados a respeito dos dados, ou seja, dados que descrevem dados.
Um documento XML leva a sua definição junto a ele. Essa característca da XML
impüca em um grande poder na representação de variadas estruturas de dados e é nesse
sentido que ela se aplica a este trabalho.
Devido à sua flexibilidade em relação à HTML e à sua simplicidade em relação
à SGML, XML tem sido utilizada no desenvolvimento de soluções para diferentes
áreas.
Do pondo de vista da troca de informação na Web através de documentos XML,
podemos citar a solução do Delphi 5 da Borland para desenvolvimento de aplicações em
três camadas. Nessa solução a página HTML, que será apresentada pelo browser do
cliente, é montada dinamicamente pela apücação Delphi e os dados extraídos de um
sistema de gerenciamento de banco de dados (SGBD) são organizados em um
documento XML e enviados juntos com aquela página. No cliente, scripts criados em
JavaScript extraem as informações do documento XML para serem apresentadas na tela.
Observa-se, portanto, que os dados são enviados para a máquina do cliente e são
manipulados lá. Caso tenha ocorrido alguma alteração, os dados são reenviados ao
servidor para que ele identifique tal alteração e a processe. Para uma explicação mais
detalhada sobre os procedimentos para se montar tal solução consulte [FRANOO].
Um outro produto que mostra a expansão que vem sofrendo a XML como forma
de troca e armazenamento de dados é o Tamino [SFAG01]. Este produto foi
desenvolvido pela Software AG e corresponde a um conjunto de produtos para construir
aplicações corporativas baseadas em XML. Entre esses produtos, há o Tamino XML
Datábase que é um SGBD que armazena os dados no formato XML. Há soluções para
Capítulo 2 - Fundamentos e Trabalhos Relacionados 20
processar os documentos XML trocados na Internet via o protocolo HTTP (Web) ou
via SMTP (e-mail).
2.5 - Mecanismos de Segurança
Apesar do modelo proposto neste trabalho não definir o esquema de segurança a
ser utilizado, este assunto será apresentado aqui devido à sua importância para várias
aplicações disponibilizadas via Internet.
A Internet é um ambiente aberto e que pode ser acessado anonimamente. Isso
aumenta a importância dos métodos de segurança na transmissão de dados sigilosos.
Segundo Tanenbaum [TANE97], os problemas de segurança das redes de
computadores podem ser divididos nas seguintes áreas interligadas:
• sigilo, relacionado ao fato de manter as informações longe de usuários não
autorizados;
• autenticação, que cuida do processo de determinar com quem você está falando
antes de revelar informações sigilosas ou entrar em uma transação comercial;
• não-repúdio, que trata de assinaturas, para não permitir, por exemplo, que um cliente
negue a solicitação de 10 milhões de unidades de um determinado produto;
• controle de integridade, que assegura que a mensagem não foi modificada durante a
transmissão.
A técnica de criptografia [TANE97, UNIC01] é bastante utilizada para garantir a
segurança de dados transmitidos na rede. Ela consiste em um algoritmo e uma chave
associada a ele que codifica ou decodifica a mensagem. A segurança reside na chave
secreta que deve ter tamanho suficiente para evitar sua descoberta por teste exaustivo,
fazendo com que somente o possuidor dessa chave consiga entender a mensagem.
Os algoritmos de criptografia dividem-se em dois grupos: algoritmos de chave
secreta (ou simétricos) e algoritmos de chave púbüca (ou assimétricos).
Os algoritmos de chave secreta correspondem àqueles nos quais uma mesma
chave é utilizada para codificar e decodificar as mensagens. Sendo assim, ambos os
lados da comunicação precisam ter conhecimento da chave. Os algoritmos DES (Data
Encryption Standard) da IBM, IDEA (International Data Encryption Algorithm), são
alguns exemplos de algoritmos simétricos. Tanenbaum apresenta tais algoritmos em
[TANE97].
Capítulo 2 - Fundamentos e Trabalhos Relacionados 21
Já nos algoritmos de chave pública existem duas chaves ligadas
matematicamente. Quando uma chave é utilizada para codificar a mensagem, a outra
será utilizada para decodificá-la. Uma chave é mantida em segredo e é chamada de
chave privada e a outra é disponibilizada a todos como uma chave pública. Assim,
quando o usuário A quiser enviar uma mensagem para B, A deverá utilizar a chave
pública de B para codificar a mensagem. Fazendo isso, apenas B conseguirá decodificar
a mensagem utilizando sua chave privada. Da mesma forma, se A codificar a mensagem
utilizando sua chave privada, B somente conseguirá decifrá-la utilizando a chave
pública de A, o que permite a B estar seguro de que foi A quem realmente mandou a
mensagem. Esse processo é conhecido como assinatura digital.
Um algoritmo que implementa o esquema de chave assimétrica foi descoberto
por um grupo de pesquisadores do MIT e é conhecido pelas iniciais dos três estudiosos
que o criaram: RSA (Rivest, Sharnir e Adleman) [TANE97].
Outra técnica de segurança é a Message Digesí. Ela é uma seqüência de « bits
gerada a partir de uma mensagem de tamanho máximo predefinido. Os algoritmos que
implementam tal recurso criam, a partir da mensagem original, uma assinatura digital
que garante a autenticidade da mensagem. Quando a Message Digest é utilizada junto
com um esquema de chave assimétrica, o processo, além de garantir a integridade da
mensagem, comprova também a sua autoria.
A combinação das técnicas apresentadas acima são utilizada para solucionar os
problemas citados no início desta seção. Sites na Internet - como os pertencentes a
bancos e aqueles que implementam comércio eletrônico - que trabalham com
informações sigilosas, utilizam tal combinação.
Um pacote completo para a segurança de mensagens de correio eletrônico,
criado por Philip Zimmermann, é o PGP (Pretty Good Privacy) [TANE97, RFC1991].
Segundo Tanenbaum, o PGP "oferece privacidade, autenticação, assinaturas digitais e
compactação, tudo de uma forma fácil de usar" [TANE97].
Capítulo 2 - Fundamentos e Trabalhos Relacionados 22
3 - Sistemas de Troca de Informações de Trânsito
3.1 - Introdução
As informações apresentadas neste capítulo são o resultado de pesquisa realizada
junto a diversos órgãos de trânsito do país, através de entrevistas telefônicas, entrevistas
pessoais e de questionários. Além disso, foram extraídas informações de sites na Web,
bem como de documentos disponibilizados pelos órgãos. Tanto as entrevistas
telefônicas quanto as pessoais foram baseadas nas perguntas dos questionários que se
encontram no Apêndice A.
A seguir, serão mostradas soluções de intercâmbio de informações de infrações
de trânsito utilizadas por municípios e estados.
No âmbito Estado/Município, será descrita a solução utilizada por Belo
Horizonte e o Estado de Minas Gerais. Tal solução foi baseada na forma como o Estado
de São Paulo interage com seus municípios. É dado destaque, ainda, para a forma como
o Município de Curitiba e o Estado do Paraná interagem.
Na esfera interestadual, serão abordadas as soluções encontradas pelos Estados
da Região Sul do Brasil.
Finalmente, o projeto RENACOM (Registro e Câmara Nacional de
Compensação de Multas Interestaduais), elaborado pelo DENATRAN, será
apresentado.
3.2 - Troca de Informações entre Estado e Município
Hoje, a troca de informações relacionadas com infrações de trânsito entre o
Estado de Minas Gerais e o Município de Belo Horizonte, ou seja, entre o DETRAN-
MG e a BHTRANS, é realizada através do envio e recepção de arquivos texto com um
layout preestabelecido. Estes arquivos são processados e carregados nas bases de cada
um dos dois órgãos de trânsito de acordo com o seu significado. A comunicação
acontece, realmente, entre a BHTRANS e a PRODEMGE, que está autorizada pelo
DETRAN a processar aquelas informações.
Capítulo 3 - Sistemas de T r o c a de Informações de Trânsito 23
Tais informações referem-se a veículos, proprietários de veículos, condutores,
autos de infração de trânsito (ATT), notificações de infração de trânsito (NTT), recursos
de infrações e pagamentos de notificações.
O processo de troca de informações possui duas motivações principais: uma é a
consistência de AIT's e a geração de NTT's; a outra é o Controle de Recursos de
Infrações.
Com relação à consistência de ATT's e geração de NIT's, o processo se dá da
seguinte forma:
• os ATT's são lavrados pelos fiscais (ou são gerados a partir de registros de
equipamentos, tais como radares e lombadas eletrônicas) e são enviados à
BHTRANS;
• as informações básicas dos AIT's (placa e UF do veículo, data da infração, tipo da
infração) são digitadas na BHTRANS;
• após esta digitação, é gerado um arquivo texto (CO) com as placas dos veículos, este
arquivo será enviado à PRODEMGE;
• a BHTRANS faz a digitação de todos os dados registrados nos AIT's somente para
aqueles que são, presumivelmente, de veículos de Minas Gerais ("presumivelmente"
porque, nem sempre, o fiscal consegue observar qual a UF do veículo)
• o arquivo CO é processado pela PRODEMGE, e, como resultado, é gerado um
arquivo de retorno (Cl) que contém, para cada placa recebida: os dados do veículo e
de seu proprietário, no caso do veículo ser de Minas Gerais; e informações de erro
no processamento, no caso do veículo não ser encontrado na base estadual (o que
pode configurar um erro na digitação ou na lavratura do ATT ou, ainda, o fato do
veículo ser de outro Estado);
• ao receber o arquivo Cl, a BHTRANS, utilizando os registros de veículos que não
apresentaram problemas, consiste os dados em seus AIT's;
• os dados dos AIT's sem problemas, são enviados à PRODEMGE, através de um
arquivo texto (AO), para serem carregados na base estadual;
• na PRODEMGE, os AIT's recebidos no arquivo AO, são novamente consistidos, o
que resulta na geração de um arquivo de retorno (Al), que informa se o ATT foi
carregado no banco de dados do Estado ou se ocorreu algum problema;
• a carga dos dados do ATT na base estadual bloqueia algumas transações que
poderiam ser realizadas com o veículo que consta no auto, ou seja, o veículo fica
Capítulo 3 - Sistemas de T r o c a de Informações de Trânsito 24
indisponível para transferências, para recebimento do DUT etc, enquanto não for
paga a NTT gerada a partir do AU ou não houver uma decisão de recurso de
infração favorável ao cancelamento da NTT;
• o arquivo Al é enviado à BHTRANS;
• só após o recebimento do arquivo Al a BHTRANS gera as NTT's a partir dos AJT's
sinalizados como consistentes, ou seja, que foram carregados na base do Estado;
• essas NTT's são enviadas para os proprietários dos veículos, pelos Correios;
• as NTT's emitidas, bem como os códigos de barras para pagamento, são enviados à
PRODEMGE, através do arquivo A2 que será carregado no banco de dados
estadual, isso possibilita que o DETRAN emita segunda via das notificações
emitidas pela BHTRANS;
• a PRODEMGE confirma a inclusão das informações de NTT em seu banco de dados
através do arquivo A3;
• os bancos conveniados, enviam à BHTRANS, diariamente, um arquivo com
informações de pagamento, cujos dados estão formatados no padrão FEBRABAN;
• a BHTRANS registra o pagamento das NTT's a partir dos dados do arquivo de
pagamento, e repassa, este mesmo arquivo, para que a PRODEMGE faça o mesmo;
• o registro do pagamento da NTT desbloqueia o veículo apontado por ela.
O processo de troca de informações para o Controle de Recursos de Infrações é
o seguinte:
• ao receber um recurso de infração de trânsito, interposto pelo cidadão responsável
pela infração, a BHTRANS digitará os dados relacionados a este recurso no Sistema
Municipal de Gerenciamento de Infrações de Trânsito, para posterior controle da
JARI (Junta Administrativa de Recursos de Infração) vinculada ao Município;
• essas informações serão utilizadas para a geração de um arquivo (RO), o qual será
enviado à PRODEMGE, para que ela não pontue o condutor do veículo e, também,
para que possa informar ao cidadão através do seu setor de atendimento;
• um arquivo RI é retornado da PRODEMGE para a BHTRANS, informando se a
carga no banco de dados estadual dos registros de recursos foi efetuada corretamente
ou se ocorreu algum problema;
• após o julgamento do recurso, a BHTRANS envia outro arquivo RO à PRODEMGE,
apresentando o resultado do julgamento daquele recurso, para que sejam tomadas as
Capitulo 3 - Sistemas de T r o c a de Informações de Trânsito 25
providências necessárias em relação à pontuação do condutor e ao
bloqueio/desbloqueio do veículo.
arq. CO (informações básica de veículo)
BHTRANS
arq. Cl (informações veículos e proprietários)
arq. AO (informações básica do ATT)
arq. A l (consistência de ATT)
arq. A2 (NTT emitidas)
arq. A3 (confirmação de inclusão de NTT)
arq. RO (recursos interpostos e resultado)
arq. RI (confirmação de atualização)
PRODEMGE
Figura 3.1 - Transferencia de informações de infrações de trânsito entre BHTRANS e PRODEMGE
O esquema da Figura 3.1 apresenta os processos descritos anteriormente. É
importante salientar que os códigos de arquivos, aqui apresentados, não são,
exatamente, os nomes dados a tais arquivos.
Outras soluções existentes no país para a troca de informações Estado/Município
se dão de forma semelhante, apresentando pequenas variações.
Do ponto de vista técnico destaca-se que esses arquivos são enviados e recebidos
via FTP. O download e a carga de suas informações no Sistema Municipal de
Gerenciamento de Infrações de Trânsito da BHTRANS devem ser iniciados
manualmente por um funcionário, envolvendo manipulação de arquivos.
No caso do Município de Curitiba e do Estado do Paraná, existe um sistema
único acessado pelos órgãos de trânsito de ambos. Dessa forma, não há a troca de
informações entre bases de dados diferentes. As bases de veículos e condutores do
Estado do Paraná são disponibilizadas on-line para os Municípios que utilizarem o
sistema. A plataforma de desenvolvimento deste sistema, como descrito no site da
CELEPAR (Companhia de Informática do Paraná), é a seguinte:
"O Sistema Conveniado de Multas foi desenvolvido na plataforma mainframe,
utilizando o Banco de Dados ADABAS para o armazenamento dos dados e o
SYBASE para o gerenciamento das imagens dos dispositivos eletrônicos. A
Caoítulo 3 - Sistemas de T r o c a de Informações de Trânsito 26
linguagem de programação no ambiente mainframe, é o NATURAL. Para a
rotina de gerenciamento das imagens dos dispositivos eletrônicos foi utilizada a
linguagem "C". Para as funções de Emissão de Etiquetas e Imposição a
linguagem utilizada foi o Delphi. A Junção Imposição também está disponível na
Internet assim como a Consulta ao Resultado de Recurso, nos quais foi utilizado
o ASP para o desenvolvimento. Está em processo de desenvolvimento uma nova
rotina que fará o Controle de Tramitação de Processos de Recursos, utilizando
a plataforma NOTES. " [CELE01]
3.3 - Troca de Informações Interestaduais
Uma importante solução relacionada com a troca de informações de infrações de
trânsito entre estados, foi desenvolvida pelos Estados do Sul do país. Esta solução opera
no nível estadual, ou seja, os órgãos ligados aos governos estaduais possuem o controle
de toda a operação.
Tal proposta foi definida e implementada sob a coordenação e responsabilidade
técnica da PROCERGS (Companhia de Processamento de Dados do Estado do Rio
Grande do Sul), com a colaboração da CELEPAR. Foi elaborado um documento com o
objetivo de "especificar a troca eletrônica de Autos de Infração entre Unidades da
Federação através de arquivo magnético a ser gerado pelos Órgãos Autuadores, em
substituição ao processo de troca de malotes, garantindo a troca de dados em um tempo
reduzido". [PROC00]
O processo de troca de informações definido nesta solução baseia-se na troca de
e-mails, contendo, em anexo, arquivos autenticados e criptografados através do PGP.
Foram definidas duas estruturas de arquivos, com header, detalhe e traiter : 1) arquivo
de infrações, para troca de informações relacionadas aos AIT's; 2) arquivo de retorno de
ocorrências, para troca de informações relacionadas ao processamento dos AIT's.
A transmissão dos arquivos se dá, como especificado no documento [PROC00],
da seguinte forma:
"Envio do Arquivo
1. O arquivo gerado deve ser assinado eletronicamente com a senha privada
do Estado através do PGP.
2. Criptografar o arquivo através do PGP utilizando a chave pública do
Estado destinatário.
Capítulo 3 - Sistemas de T r o c a de Informações de Trânsito 27
3. Atachar o arquivo ao e-mail.
4. Enviar o e-mail para a caixa postal.
Recebimento do Arquivo
1. Cada Estado, ao receber uma mensagem na caixa postal de troca de
arquivos deverá desatachar o arquivo do e-mail.
2. Autenticar o Estado remetente utilizando a chave pública do mesmo.
3. Decriptografar o arquivo através do PGP utilizando a sua chave privada.
4. Verificar a integridade do arquivo (Seqüência de arquivo e seqüência de
registro etc).
5. Processar o arquivo recebido.
6. Gerar o arquivo de retorno das ocorrências de processamento. " [PROCOO]
3 . 4 - O RENACOM
O Registro e Câmara Nacional de Compensação de Multas Interestaduais -
RENACOM - foi instituído pela Portaria n° 57 do Departamento Nacional de Trânsito
(DENATRAN), de 20 de dezembro de 2001. Ele surge tendo em vista "a importância e
urgência do processo de implantação de uma sistemática para a cobrança, controle,
pontuação, fiscalização e compensação de multas interestaduais de trânsito" (Portaria n°
57, DENATRAN, 20/12/2001).
O RENACOM é coordenado pelo DENATRAN e é composto por todas as
entidades, instituições, organizações e pessoas jurídicas, no território nacional,
envolvidas em processos vinculados com multas de trânsito. Suas finalidades, conforme
estabelece o art. 2 o daquela portaria, são as seguintes:
• definir e perseguir, em âmbito nacional, padrões de qualidade e procedimentos no
processo de multas interestaduais;
• padronizar e desenvolver os procedimentos básicos, assegurando correta gestão do
RENACOM;
• integrar, num único sistema, todos os procedimentos e as informações quanto às
multas interestaduais, permitindo, simultaneamente, o acompanhamento das
entidades autuadores; e
• definir as funções no âmbito RENACOM das entidades, organizações e órgãos
participantes, tendo por base suas respectivas atribuições.
Capítulo 3 - Sistemas de T r o c a de Informações de Trânsito 28
O processo de troca de dados se dá através de arquivos texto, com uma estrutura
predefinida. De acordo com a versão preliminar 02 da "Proposta de Layout
RENACOM" [DENA02], foram definidos nove tipos de arquivos que são:
• Tipo A - Consulta dos dados dos veículos
• Tipo B - Retorno da consulta dos dados dos veículos
• Tipo C - Registro de penalidades no RENACOM
• Tipo D - Retorno de registro de penalidades no RENACOM
• Tipo E - Movimentação do RENACOM
• Tipo F - Movimentação do Órgão Autuador
• Tipo G - Retorno de Movimentação do Órgão Autuador
• Tipo H - Estorno de Movimentação do Órgão Autuador
• Tipo I - Estorno de Movimentação do Órgão Autuador
Cada tipo de arquivo possui registros de Header e de Trailler, e seu nome é
formado da seguinte maneira: uma letra identificando o tipo de arquivo; a versão do
layout com duas posições; o código do órgão autuador com seis posições e um número
seqüencial com cinco posições. A extensão do arquivo será ".RNP".
Alguns procedimentos gerais são definidos:
• há urn limite de três arquivos diários para cada tipo de arquivo;
• limite de 99.999 registros por arquivos;
• formato das datas: AAAAMMDD;
• a quantidade de registros informada no Registro Trailler inclui o Header e o próprio
Trai l ler.
O envio dos arquivos é realizado via Internet, utilizando-se o protocolo FTP.
Para que um órgão de trânsito municipal realize uma autuação, utilizando o
RENACOM, são necessários os seguintes passos:
• o órgão de trânsito municipal informa as placas dos veículos autuados ao DETRAN
de seu Estado, chamaremos este de DETRAN Ligado ao Autuador;
• o DETRAN Ligado ao Autuador solicita os dados dos veículos autuados ao
RENACOM;
• o RENACOM solicita os dados dos veículos autuados ao DETRAN que licenciou os
veículos, que chamaremos de DETRAN de Origem dos Veículos;
• o DETRAN de Origem dos Veículos retorna os dados dos veículos solicitados ao
RENACOM;
Capítulo 3 - Sistemas de T r o c a de Informações de Trânsito 29
• o RENACON envia os dados recebidos do DETRAN de Origem dos Veículos ao
DETRAN ligado ao Autuador solicitante;
• o DETRAN Ligado ao Autuador repassa os dados dos veículos para o órgão de
trânsito municipal solicitante;
• o órgão de trânsito municipal faz a consistência do auto de infração, valida, aplica
penalidade e informa ao DETRAN de seu Estado, ou seja, ao DETRAN Ligado ao
Autuador;
• o DETRAN Ligado ao Autuador repassa os dados da infração ao RENACOM, que,
por sua vez, emite a notificação.
Após a emissão da notificação, há duas opções que podem ser seguidas. Na
primeira, o RENACOM envia a notificação diretamente para o infrator. Na segunda, o
RENACOM envia a notificação para o órgão autuador para que este efetue a postagem
da notificação.
O RENACOM ainda informa ao DETRAN do veículo para que seja efetuado o
seu bloqueio e computado a pontuação do condutor.
Após o envio, independente do órgão que postou a notificação, o RENACOM
recebe dos Correios as informações a respeito da postagem. Nesse ponto, ele guarda os
documentos para que sejam, futuramente, fornecidos em uma eventual necessidade de
instrução de recursos.
O RENACOM ainda faz o controle dos pagamentos das multas. Para isso, ele
recebe as informações de pagamento das multas, informa aos órgãos autuadores desses
pagamentos e solicita o desbloqueio dos veículos nos respectivos DETRAN*s.
Para cada processamento são retirados os custos operacionais que correspondem
a: 5% (cinco por cento) para o Fundo Nacional de Segurança e Educação no Trânsito
(FUNSET); R$ 21,00 (vinte e um reais) por multa de veículo registrada nas bases de
dados estaduais para o RENACOM; R$ 12,00 (doze reais) por multa de veículo
registrada nas bases de dados estaduais e R$ 3,00 (três reais) por pontuação atribuída ao
condutor para os DETRAN's.
O valor líquido, ou seja, o valor arrecadado menos os custos operacionais, será
enviados ao órgão autuador.
Capítulo 3 - Sistemas de T r o c a de informações de Trânsito 30
4 - Definições e Requisitos
4.1 - Introdução
Para a elaboração e implementação do modelo proposto neste trabalho algumas
considerações devem ser apresentadas no que diz respeito às definições preliminares e
aos requisitos.
Este modelo tem como objetivo ser um complemento às atividades de
processamento de infrações realizadas pelos Municípios. Para isso, algumas premissas
são especificadas a seu respeito:
• deve ser o mais independente possível da forma pela qual o Município se relaciona
com seu Estado;
• deve possibilitar a troca de informações com o mínimo de interferência humana;
• deve atender tanto aos aspectos ligados aos AIT's e NTT's quanto aos ligados a
recursos de infrações.
Sendo assim, os dados utilizados no intercâmbio deverão ser os mais essenciais
possíveis, afim de facilitar a sua integração aos esquemas de dados utilizados pelos
sistemas de cada Órgão de Trânsito. A maioria desses dados estão previstos no Código
de Trânsito Brasileiro ou em Resoluções do CONTRAN.
Poderíamos citar como quarta premissa a capacidade de enviar dados sigilosos
de forma segura e confiável. Entretanto, como citado anteriormente, a questão de
segurança não será estudada neste trabalho, sendo indicada como melhoramentos
futuros para o modelo.
Os itens seguintes apresentarão o esquema de dados no qual se baseia o modelo
de intercâmbio de informações proposto e os requisitos para o ambiente de informática
dos órgãos que o utilizariam.
4.2 - O Esquema de Dados Básico
O modelo para intercâmbio de informações relacionadas a multas de trânsito tem
como base um esquema de dados que apresenta os relacionamentos entre Autos de
Infração de Trânsito (AIT), Notificações de Infração de Trânsito (NTT) e Recursos de
Infração, além de outros relacionamentos associados a estes itens.
Capítulo A - Definições e Requisitos 31
Os sistemas informatizados existentes nos diversos órgãos de trânsito
implementam esquemas de dados para estes relacionamentos, entretanto, há algumas
diferenças entre eles, geralmente, pequenas diferenças, o que gera a necessidade da
definição de um esquema básico que servirá de referência para este trabalho.
A Figura 4.1 mostra o esquema Entidade-Relacionamento (ER) básico utilizado
como referência. Este esquema está representado utilizando a notação proposta por
Elmasri e Navathe em sua obra "Fundamentals of Database Systems" [ELMAOO].
Os tipos de entidade apresentadas no esquema da Figura 4.1 têm as seguintes
responsabilidades:
• PROPRIETARIO^VEICULO - corresponde aos dados dos proprietários de veículos
automotores; em alguns esquemas, porém, esses dados estão disponibilizados junto
aos dados de veículo, ou seja, pertencem a entidade VEICULO;
• VEICULO - contém os dados de veículos;
• MARCA_MODELO_VEICULO - corresponde aos dados de marca/modelo de
veículos, conforme tabela fornecida pelo DENATRAN;
• UNTDADE_FEDERATIVA - sigla e nome dos estados brasileiros;
• HISTORICO_PROPRIEDADE - guarda informações a respeito de antigos
proprietários de veículos; esse tipo entidade permite que se identifique o proprietário
do veículo em um determinado período, evitando que infrações sejam canceladas
por motivo de transferência de veículos;
• GRAVIDADEJNFRACAO - esse tipo entidade registra as quatro categorias
(gravíssima, grave, média, leve), definidas pelo Art. 258 do Código de Trânsito
Brasileiro (Lei N°. 9.503, de 23/09/1997), que classificam as infrações punidas com
multa; além disso, registra seus respectivos pontos e valores;
• TIPO_INFRACAO - corresponde à Tabela de Codificação de Multas definida no
Anexo IV da Portaria N° 01/98 do DENATRAN;
• AGENTE - corresponde ao cadastro de agentes de trânsito que estão autorizados à
lavrar autos de infração, seus dados são: número do agente, nome e data de
admissão;
• CONDUTOR_VEICULO - cadastro das pessoas habilitadas a conduzir veículos
automotores;
• AIT - corresponde aos dados dos Autos de Infração de Trânsito;
• NOTIFICAÇÃO - corresponde aos dados das Notificações de Infração de Trânsito.
Capítulo 4 - Definições e Requisitos 32
Figura 4.1 - Esquema ER Básico
Capítulo 4 - Definições e Requisitos 33
É válido fazer algumas considerações a respeito deste esquema de dados, tendo
em vista a heterogeneidade de esquemas utilizados pelos órgãos de trânsito, citada
anteriormente. Sendo assim, as premissas que foram utilizadas para a elaboração do
esquema são apresentadas a seguir.
Consideramos que cada veículo é identificado pelo seu número no Registro
Nacional de Veículos Automotores (RENAVAM), ou por sua placa. Todo veículo
pertence a um proprietário, a uma espécie e a uma categoria. Além disso, o veículo é
originário de um município e de uma UF de licenciamento, e possui uma marca/modelo,
um ano do modelo, um ano de fabricação e uma cor.
No esquema da Figura 4.1, o proprietário do veículo é identificado pelo número
de proprietário, ou pelo número do CPF, ou ainda pelo número de sua carteira de
identidade (Cl) juntamente com o órgão expedidor.
Todo condutor possui número identificador no Registro Nacional de Condutores
Habilitados (RENACH). O número do CPF e o número da carteira de identidade
(juntamente com o órgão expedidor) também identificam um condutor. Outros dados do
condutor são: nome, endereço, data de nascimento, nomes dos pais, data da habilitação
e data de vencimento do exame médico. Todo condutor está habilitado em pelo menos
uma categoria de habilitação (A, B, C, D e/ou E). Um condutor tem uma carteira de
habilitação, que é identificada pelo número do RENACH.
Um AIT possui os seguintes dados:
• número do órgão executivo de trânsito;
• número do AIT:
• dados de veículos (placa, marca/modelo, cor);
• se houver, dados do infrator (nome, número no RENACH, CPF e número da carteira
de identidade e órgão expedidor);
• dados da infração (código do tipo de infração, data, hora, local e a área do local da
infração);
• número do agente que lavrou o AIT.
E importante observar que, neste esquema de dados, um AIT possui uma, e
apenas uma, infração associada a ele, pois não há restrição no CTB quanto à quantidade
de infrações a serem associadas a um AIT.
Os dados do infrator correspondem aos dados da pessoa que estava conduzindo
o veículo no momento da infração. Sendo assim, o infrator pode ser um condutor
Capítulo 4 - Definições e Requisitos 34
habilitado ou não, daí a necessidade de se ter o nome, o CPF e o número e órgão
expedidor da Cl no AIT, além do número no RENACH. Esses dados, entretanto, podem
não ser coletados em vários casos - por exemplo, em um avanço de sinal - e, por isso,
não são obrigatórios.
Cada AIT consistente dá origem a uma única NTT. O documento da NTT deverá
apresentar os seguintes dados:
• número da notificação, que identifica o documento;
• data de emissão da notificação;
• número do AIT que gerou a notificação;
• dados de veículos (placa, marca/modelo, cor, proprietário);
• se houver, dados do infrator (nome, número no RENACH, CPF e número da carteira
de identidade e órgão expedidor);
• dados da infração (código e descrição do tipo de infração, data, hora, local e o
número de pontos para o infrator);
• dados do agente que lavrou o AIT (número do agente);
• dados de pagamento (valor a ser pago e data de vencimento).
Com exceção dos dados do infrator, todos os demais são obrigatórios no
documento da NTT.
A Tabela 4.1 apresenta a descrição de todas as siglas usadas como nome de
campo no esquema apresentado nesta seção, em ordem alfabética. Tabela 4.1 - Campos e descrições do Esquema ER Básico
Nome do Campo Descrição Nome do Campo Descrição Ano fabr Ano de fabricação Ide ci Identificador da carteira de ident. Ano mode Ano do modelo Ide_espc_veic Identificador da espécie do veículo Cod catg_cndt Código da categoria do condutor fde_plac Identificador da placa Cod_grav_inÍT Código da gravidade da infração Nom_agen_tran Nome do agente de trânsito Cod seri ait Código de série do AIT Nom bair Nome do bairro Dat admi Data de admissão Nom cndt infr Nome do condutor infrator Dat cadt real Data de cadastro do real infrator Nom cndt veie Nome do condutor do veículo Dat cass Data da cassação Nom mae cndt Nome da mãe do condutor Dat cass cndt Data de cassação do condutor Nom mune Nome do município Dat doem habi Data do documento de habilitação Nom_pai_cndt Nome do pai do condutor Dat emis notf Data de emissão da notificação Nom_prop_veic Nome do proprietário de veículo Dat_gera_notf Data de geração da notificação Nom unid fede Nome da UF Dat_habi_catg Data de habilitação na categoria Num_agen_tran Numero do agente de trânsito Dat infr Data de infração Num ait Número do AIT Dat libe cndt Data de liberação da cassação Num_banc_pgto N° banco onde se efetuou o pagto. Dat nasc Data de nascimento Num_cep Número do CEP Dat_pgto Data de pagamento Nurn_cpf Número do CPF Dat_prim_habi Data da primeira habilitação Num mrca mode Número da marca/modelo Dat_trnf_veic Data de transferência do veículo Num notf Número da notificação Dat venc exam Data de vencimento do exame Num_prop_veic Número de proprietário de veículo Des cor Descrição da cor Num rnch Número do RENACH
Capítulo 4 - Definições e Requisitos 35
Des ende Descrição do endereço Num rnva Número do RENAVAM Des_grav_infr Descrição da gravidade da infração Num_tipo_infr Número do tipo de infração Des loca infr Descrição do local da infração Qte_pont Quantidade de pontos Des mrca mode Descrição da marca/modelo Sig_orga_expd_ci Sigla do órgão expedidor da Cl Des_tipo_infr Descrição do tipo de infração Sig_unid_fede Sigla da unidade federativa Hor infr Hora da infração Val_pgto Valor do pagamento Ide_catg_veic Identificador da categoria do veíc. Val ufir Valor em UFIR
O esquema de dados apresentado nessa seção não tem a pretensão de ser um
modelo definitivo para um sistema de controle de infrações. Seu objetivo é definir
algumas premissas básicas e apresentar os relacionamentos que subsidiarão o modelo
para intercâmbio de informações relacionadas com multas de trânsito, que é a intenção
deste trabalho. Sendo assim, alguns relacionamento podem estar simplificados, bem
como, algumas entidades podem não ter sido consideradas.
Finalmente, como veremos no Capítulo 5, o modelo para intercâmbio de
informações proposto por este trabalho não levará em consideração vários tipos de
entidades e atributos definidos nesta seção, bem como, utilizará outros não
especificados aqui.
4.3 - Requisitos do Software de Processamento de Infrações
A implantação do modelo proposto neste trabalho exigirá algumas adaptações no
processamento das infrações de trânsito realizado pelos sistemas informatizados dos
Órgãos de Trânsito envolvidos. Tais sistemas deverão estar preparados para gerar os
dados que serão utilizados nos pacotes a serem enviados a outros Órgãos de Trânsito e
para processar os dados dos pacotes recebidos destes.
O tipo das adaptações que os sistemas de processamento de infrações de trânsito
deverão sofrer, dependerá do papel exercido pelo Órgão de Trânsito no momento do
intercâmbio das informações, ou seja, algumas atividades são exercidas pelo Órgão que
lavrou o AIT e outras pelo Órgão que possui acesso ao registro do veículo autuado.
As adaptações implementadas nos sistemas de processamento de infrações para
atender às necessidades do Órgão que lavrou o AIT devem possibilitar:
• identificar aqueles AIT's cujos veículos não foram encontrados durante o seu
processamento e que, provavelmente, foram licenciados em outros Estados;
• registrar as informações de origem dos veículos relacionados a cada AIT;
• registrar as informações de retorno relacionadas ao processamento dos ATT's no
Órgão que possui o registro do veículo autuado;
Capítulo 4 - Definições e Requisitos 36
• registrar as informações referentes às NTT's, que foram geradas a partir dos AIT's
enviados;
• identificar quais recursos de infração foram interpostos contra ATT's enviados a
outros Órgãos e qual a situação de tais recursos.
Do ponto de vista do Órgão que possui acesso ao registro do veículo autuado, as
adaptações no sistema de processamento de infrações devem possibilitar:
• verificar se um determinado veículo foi licenciado no Estado ao qual o Órgão está
ligado;
• identificar as inconsistências verificadas em cada AIT recebido de algum Órgão
solicitante;
• processar os AIT's recebidos dos Órgãos solicitantes;
• emitir NTT's para os ATT's lavrados por outro Órgão;
• identificar os recursos que foram interpostos para NTT's originadas de AIT lavrado
por outro Órgão;
Tais necessidades de adaptação ficarão mais claras à medida que aumentar a
compreensão sobre o modelo, descrito no Capítulo 5.
É importante observar que os sistemas deverão reconhecer os AIT's que foram
gerados por outros Órgãos. Para identificar um ATT de forma única, o seu número
deverá estar acompanhado do número identificador do Órgão de Trânsito de origem,
uma vez que não existe uma numeração nacional única para ATT. Na NTT deverá estar
informada a identificação do ATT que a originou.
4.4 — Requisitos de Ambiente
Para que a troca de informações possa ser viabilizada utilizando o modelo aqui
proposto, é fundamental que os Órgãos envolvidos possuam acesso a um ambiente
preparado para processar informações transmitidas via Internet.
Este ambiente deverá ser composto por um servidor Web, utilizando alguma
tecnologia de processamento - tal como, CGI, DLL ISAPI/NSAPI, ASP, Servíeis JAVA
etc. — que possua interface com tal servidor e que permita acesso a dados.
Seria interessante a utilização de um software de banco de dados, que pudesse
ser acessado diretamente pela tecnologia adotada. Entretanto, isso dependerá de como
cada Órgão de Trânsito associará seu sistema ao modelo de intercâmbio.
Capítulo 4 - Definições e Requisitos 37
Será necessário, ainda, um parser XML, que poderá ser desenvolvido ou
adquirido de terceiros. Atualmente, existem vários parser XML disponibilizados,
gratuitamente, na Web.
Um parser XML, como nos explica Benoit Marchai [MACHOO], "é um
componente de software residente entre o aplicativo e os arquivos XML". Ele lê,
interpreta e escreve documentos XML.
Mais detalhes sobre este ambiente serão apresentados no Capítulo 6.
Capítulo 4 - Definições e Requisitos 38
5 - Modelo para Intercâmbio de Informações
5.1 - Introdução
Este capítulo descreve o modelo para intercâmbio de informações relacionadas a
infrações de trânsito proposto neste trabalho. Para isso, será utilizada a UML (Unified
Modeling Languagé) que constitui-se em "uma linguagem-padrão para a elaboração da
estrutura de projetos de software" [BOOC00].
A metodologia para descrição desse modelo inicia-se com a elaboração da visão
de casos de uso aplicada a ele. Segundo Furlan [FURL98], "um caso de uso é uma
interação típica entre um usuário e um sistema, um modo específico de utilização a
partir de um ponto de vista segmentado de funcionalidade".
Em seguida, serão descritos os processos que definem cada caso de uso e,
posteriormente, serão apresentadas as classes utilizadas por eles.
É importante que o modelo seja compatível com as tecnologias utilizadas na
Internet, para que a troca de dados ocorra neste ambiente. Pensando nisso, os
documentos utilizados para a troca de dados serão estruturados utilizando a XML
[LIGT99, MACHOO]. Sendo assim, após conhecermos os processos e as classes do
modelo, serão definidas as estruturas dos documentos XML utilizados.
A princípio, essa troca de informações aconteceria entre Órgãos de Trânsito
Municipais ou Estaduais pertencentes a Estados diferentes. Entretanto, nada impede que
tal troca ocorra entre municípios de mesmo Estado.
Vale lembrar, ainda, que, apesar de existirem algumas variáveis políticas
envolvidas com a troca das informações de infrações de trânsito, este modelo busca
apresentar uma alternativa puramente técnica para a questão.
5.2 - Modelagem de Casos de Uso
Segundo Booch at ali [BOOC00], "os casos de uso podem ser aplicados para
captar o comportamento pretendido do sistema que está sendo desenvolvido, sem ser
necessário especificar como esse comportamento é implementado". Sendo assim, um
diagrama de casos de uso apresenta a interação entre a visão externa de um determinado
sistema e o mundo exterior. O mundo exterior é representado por atores. Cada ator
Capítulo 5 - Modelo para Intercâmbio de Informações 39
representa um conjunto coerente de papéis que os usuários de casos de uso
desempenham quando interagem com esses casos de uso.
Tendo em vista estas definições, para elaborarmos a visão de casos de uso do
modelo proposto, temos que analisar quais são as funcionalidades oferecidas e quais
atores interagem com ele.
Podemos identificar três atores que interagem com o modelo. O primeiro deles,
corresponde ao sistema do órgão ou entidade executivo de trânsito que efetuou a
autuação. Chamaremos este ator de Sistema do Órgão Autuador.
O segundo ator é o sistema do órgão ou entidade executivo de trânsito Municipal
ou Estadual localizado no Estado de origem do veículo. Este ator, identificado como
Sistema do Órgão Conveniado, processará os autos de infração de trânsito (AIT's) e
emitirá as notificações de infração de trânsito (NTT's).
Como os sistemas dos órgãos ou entidades de trânsito envolvidos no processo
ora exercem o papel de Autuador, ora o papel de Conveniado, podemos criar um ator
generalizado chamado Sistema do Órgão de Trânsito, representado pela Figura 5.1. Esta
generalização torna claro que os sistemas dos Órgãos de Trânsito deverão estar
adaptados para exercerem os dois papéis.
O
Sistema do Órgão de Trânsito
O O
Sistema do Sistema do Órgão Autuador Órfão Conveniado
Figura 5.1 - Especialização de Sistema de Órgãos de Trânsito
O terceiro ator, chamado de Sistema do Órgão Central, corresponde ao sistema
que possui os dados cadastrais - tais como placa, RENAVAM, identificação da
Unidade Federativa (UF) de licenciamento etc. - de todos os veículos licenciados pelos
Órgãos de Trânsito Estaduais do Brasil. Este ator corresponde ao sistema que mantém a
base central de veículos, de propriedade do DENATRAN.
Capítulo 5 - Modelo para Intercâmbio de Informações 40
Nesse modelo, os atores trocam informações a respeito de: Autos de Infração de
Trânsito (AIT's), Notificações de Infração de Trânsito (NTT's) e recursos. Entretanto,
existem dois passos anteriores à troca desses dados, que correspondem à identificação
dos AIT's que serão enviados para outros órgãos e à identificação da origem do veículo
autuado.
O processo iniciará, portanto, com a identificação dos AIT's que deverão ser
enviados para outros órgãos. Esta etapa deverá ser implementada pelos sistemas de
processamento de infrações de trânsito de cada órgão e, sendo assim, não será
especificada neste modelo. Recomenda-se, entretanto, que todo ATT que não tenha
passado pela consistência devido, unicamente, ao não reconhecimento da placa do
veículo na base local, seja identificado através de um indicador ou seja armazenado em
um local diferente dos demais (em uma nova tabela no banco de dados, em um
documento XML etc).
O modelo define, entretanto, a classe ATT, apresentada posteriormente neste
capítulo, que possui atributos e operações que serão utilizados por ele. Após o processo
de identificação, os ATT's selecionados devem atender à especificação de atributos desta
classe, assim como as operações definidas por ela devem ser implementadas.
O passo seguinte corresponde à identificação da origem do veículo. Tal etapa é
fundamental, pois é através dela que se identificará qual o destino de cada AIT, o que
corresponde ao ponto de partida para as trocas das informações sobre as infrações. Os
atores que participam desse processo são o Sistema do Órgão Autuador e o Sistema do
Órgão Central. Há uma segunda alternativa, na qual o Sistema do Órgão Autuador irá
interagir com o Sistema do Órgão Conveniado.
Identificada a origem do veículo, inicia-se a troca de dados referentes às
infrações de trânsito. O Sistema do Órgão Autuador e o Sistema do Órgão Conveniado
passam a enviar e receber informações a respeito de AIT's, de NTT's e de recursos de
infração.
A partir dessas informações, elaboramos o diagrama de casos de uso da Figura
5.2 para representar o modelo. As seções seguintes apresentarão os detalhes dos casos
de uso mostrados aqui.
Capítulo 5 - Modelo para Intercâmbio de Informações 41
Medeio de Intercambio de Informações de Infrações de Trânsito
S is te i l va do Órgão Autuador
O Trocada Informações de ATT
Sùte ma do Órgão Conveaiado
Sistema do Órgão Central
O
Figura 5.2 - Diagrama de Casos de Uso para o Modelo de Intercâmbio de Informações de Infrações de
Trânsito
5.3 - Processo de Identificação de Origem do Veículo
Existem duas maneiras para a identificação de origem do veículo. A mais
simples utiliza o Sistema do Órgão Central. A mais complexa utiliza os Sistemas dos
Órgãos Conveniados e apresenta situações diferentes caso o Órgão Conveniado seja
Municipal ou Estadual.
r
5.3.1 — Processo de Identificação de Origem do Veículo no Sistema do Órgão
Figura 5.3 - Diagrama de Caso de Uso para a identificação de origem do veículo no Sistema Central
O diagrama de seqüência da Figura 5.4 representa as interações descritas para
este caso de uso.
Central
O caso de uso de identificação de origem do veículo no Sistema do Órgão
Central é apresentado no diagrama da Figura 5.3.
Sistema do Órgão Autuado r
Sistema do Órgão Central
Capítulo 5 - Modelo para Intercâmbio de Informações 42
É necessário que seja gerado um documento XML contendo as placas dos
veículos a serem pesquisadas no Sistema do Órgão Central, para que o processo de troca
de informações tenha início. Chamaremos este documento XML de xmlPlacas.
:Sistema do Orqão Autuador
:A1T
iSisterna do
:Veiculo
3: obterVeÍculos(xmlPlacas)
xmlVeiculos
5: reqistrarUfVeiculo(xmlVeiculos) ^
Figura 5.4 — Diagrama de Sequência para o Caso de Uso Identificação da Origem do Veiculo no Sistema do
Órgão Central
As interações que compõem este caso de uso inicia-se quando o Sistema do
Órgão Autuador envia o documento xmlPlacas para o Sistema do Órgão Central.
O Sistema do Órgão Central, por sua vez, processa o xmlPlacas e gera um novo
documento XML, nomeado aqui de xml Veículos, com os detalhes dos veículos
pesquisados e envia-o, on-line, para o Sistema solicitante. O documento xmlVeiculos
deverá conter todas as placas existentes em xmlPlacas, informando os dados do veículo
relacionado a cada placa ou indicando que os dados do veículo relacionado a uma
determinada placa não foram encontrados. Ao receber o xmlVeiculos do Sistema do
Órgão Central, o Sistema do Órgão Autuador registra, em cada ATT, a UF de
licenciamento do veículo, para aqueles que foram identificados.
Conforme apresentado pelo diagrama de seqüência, para a realização dessas
atividades são utilizadas duas classes: a classe AIT e a classe Veiculo. Neste caso, a
classe AIT está associada ao Sistema do Órgão Autuador e a classe Veiculo esta
associada ao Sistema do Órgão Central. Essas classes representam as bases de dados dos
Sistemas envolvidos na interação e podem estar implementadas de forma específica em
cada um deles. Contudo, é importante observar o comportamento das operações
utilizadas e os documentos XML que estão sendo enviados.
Capítulo 5 - Modelo para Intercâmbio de Informações 43
5.3.2 - Processo de Identificação de Origem do Veículo no Sistema do Órgão Conveniado
Como citado no início desta seção, o processo de identificação de origem do
veículo utilizando os sistemas dos órgãos conveniados, representado pelo caso de uso da
Figura 5.5, apresenta algumas diferenças caso o órgão conveniado seja um Órgão de
Trânsito Municipal ou um Órgão de Trânsito Estadual.
Identificação de Origem do Veículo
Sistemado Órgão Autuador
Sistemado Órgão Conveniado
Figura 5.5 - Diagrama de Caso de Uso: identificação de origem do veículo no Sistema Conveniado
Essa distinção se deve ao fato dos Órgãos de Trânsito Estaduais, mais
especificamente, dos DETRAN's, possuírem as bases de dados dos veículos licenciados
nas suas respectivas UF's, o que não ocorre com os Órgãos de Trânsito Municipais. Isso
torna o processamento realizado pelos sistemas daqueles órgãos bastante semelhante ao
processamento do Sistema do Órgão Central, como é mostrado pelo diagrama de
seqüência da Figura 5,6.
:Sistema ao Qtqão Autuadoi
i 1. veiculoSemlcientjfjcacao()
.AU :OraaoTransito e:Sistema do
Óraão Conveniado
V e i c u l o
xirtPlacas
' 1 oMerUMOrgao Transito
3- enviar xmiPlacas
6: registrarUfVeiculo(xmlVeículos)
P
5: enviar xml Veículos
4: abterVeiculosCxr*lacas) 3>
xmtVeicutos D
Figura 5.6 - Diagrama de Seqüência para o Caso de Uso Identificação da Origem do Veículo no Sistema do
Órgão de Trânsito Estadual
A maior diferença entre os processos de identificação de origem do veículo no
Sistema do Órgão Central e nos Sistemas dos Órgãos Estaduais está no volume de
mensagens que serão enviadas e recebidas. No primeiro caso, a base de veículos está
Capítulo 5 - Modelo para Intercâmbio de Informações 44
centralizada, fazendo com que todos os veículos incluídos em um documento xmlPlacas
sejam tratados por um único sistema. No segundo caso, como as informações
relacionadas aos veículos estão divididas pelos vários Órgãos de Trânsito Estaduais, há
a necessidade de se enviar o documento xmlPlacas para cada um desses órgãos. Como
conseqüência, cada Sistema de Órgão Conveniado retornará um documento
xmlVeiculos, em decorrência do processamento realizado.
A classe OrgaoTransito, referenciada no diagrama de seqüência, será detalhada
posteriormente neste capítulo. Essa classe contém informações sobre os diversos órgãos
conveniados, sejam eles estaduais ou municipais. Entre estas informações está o
endereço para o qual deverão ser enviados os documentos destinados a cada órgão.
A situação nos Órgãos de Trânsito Municipais é um pouco diferente daquelas
apresentadas para os DETRAN's e para o Órgão Central, como mostra o diagrama de
seqüência da Figura 5.7. Geralmente, uma das etapas do processamento de infrações
destes órgãos é solicitar ao DETRAN de seu Estado os dados dos veículos autuados, o
que é representado pela mensagem número 6 (seis) do diagrama da Figura 5.7. Alguns
Órgãos de Trânsito Municipais possuem uma base de dados contendo apenas os
veículos de seu município. Esta base é atualizada, periodicamente, a partir de dados
recebidos do DETRAN de seu Estado. Entretanto, para os veículos de outros municípios
continua sendo necessária a consulta a uma base externa.
:Slstema fJo órgão Auiuador
;AIT :QrqaoTransito
1:vaculcSetnldentificacac<)
xmlPlacas
' 2: obter UrlOrg ao Transito
3: enviar xmlPlacas
12. r egistr ar UfVeictiloi,xml Veículos) — ^ >
m Sistema cio Órgão Conveniado
• PlacaSolicitada Veiculo
iar xmtCorrfirmaPlacas
4: ineluirPlac a sí xmIPtaca s)
6 cônsul a veículos no • Órgão Estadual ¡
7: incliirVeiculof)
8: extrairPlacasf)
9: obterUrlOrgaoTransto ^
11: enviar xmlVeicUos
- 5 * • ^ , xmlPlacas
1Ct abierVeieulosíxmPlacas)
xml Veículos
• Figura 5.7 - Diagrama de Seqüência para a Caso de Uso Identificação da Origem do Veículo no Sistema do
Órgão de Trânsito Municipal
Capítulo 5 - Modelo para Intercâmbio de Informações 45
Devido a essa característica, ou seja, à necessidade de solicitação de pesquisa na
base de dados estadual, no caso da identificação da origem do veículo nos sistemas dos
Órgãos Municipais, o retorno do documento xmlVeiculos não será on-line, como nos
casos da identificação nos sistemas do Órgão Central ou dos Órgãos Estaduais. Sendo
assim, ao receber o documento xmlPlacas do Sistema do Órgão Autuador, o Sistema do
Órgão de Trânsito Municipal Conveniado, retornará apenas a confirmação deste
recebimento, através do documento XML chamado xmlConfirmaPlacas, e,
posteriormente, solicitará a pesquisa das placas contidas naquele documento ao Órgão
de Trânsito Estadual. O procedimento de pesquisa no Órgão de Trânsito Estadual é
independente ao modelo proposto por este trabalho e é definido por um acordo feito
entre o Órgão de Trânsito Municipal e o DETRAN de seu Estado.
Após receber a resposta à pesquisa solicitada ao Órgão de Trânsito Estadual, o
Órgão de Trânsito Municipal Conveniado deverá identificar as placas solicitadas por
cada Órgão Autuador, gerar o documento xmlVeiculos e enviá-lo ao respectivo
solicitante. Da mesma forma que nos processos de identificação de origem do veículo
nos sistemas do Órgão Central e dos Órgãos Estaduais, o documento xmlVeiculos
deverá conter todas as placas que faziam parte do documento xmlPlacas recebido
anteriormente, indicando quais placas foram encontradas ou não.
O fato de haver um intervalo de tempo entre o recebimento do arquivo
xmlPlacas e o recebimento da resposta à pesquisa no Órgão de Trânsito Estadual, cria a
necessidade de se controlar quais veículos foram solicitados por cada Órgão Autuador.
Tal controle pode ser executado de várias formas, desde que se processe corretamente o
documento xmlPlacas recebido, retorne o documento xmlConfirmaPlacas e,
posteriormente, envie o documento xmlVeiculos com o conteúdo correto. O diagrama
da Figura 5.7 apresenta uma alternativa para que o Sistema do Órgão de Trânsito
Municipal Conveniado realize este controle.
A solução proposta pode ser descrita como se segue. Ao receber um documento
xmlPlacas (mensagem 3) o Sistema do Órgão Conveniado Municipal incluirá todas as
placas em uma classe chamada PlacaSolicitada (mensagem 4) e retornará o documento
xmlConfirmaPlacas ao Órgão Autuador (mensagem 5). Posteriormente, será realizada a
consulta ao Órgão Estadual (mensagem 6) e o resultado obtido será utilizado para
atualizar os dados de veículos na classe Veiculo (mensagem 7). Finalmente, um
procedimento irá gerar os documentos xmlPlacas para as placas que já foram
consultadas no Órgão Estadual (mensagem 8) e, para cada xmlPlacas, será identificado
Capítulo 5 - Modelo para Intercâmbio de Informações 46
o URL do seu Órgão Autuador (mensagem 9) e gerado (mensagem 10) e enviado
(mensagem 11) o respectivo xmlVeiculos.
Esse processo de identificação da origem do veículo através de Órgãos
Conveniados Municipais, evidencia a independência do modelo proposto neste trabalho
em relação à maneira como os órgãos de trânsito municipais interagem com os
respectivos órgãos estaduais.
5.4 - Processo de Troca de Informações de AIT
Após a identificação da origem do veículo, inicia-se o processo de troca de
informações relacionadas aos AJT's, representado pelo diagrama de caso de uso da
Figura 5.8. Nesse momento, a situação de todos os ATT's que passaram pelo processo
de identificação de origem do veículo já está definida, ou seja, a UF de licenciamento de
cada veículo encontrado durante o processo de identificação já está registrada junto ao
respectivo AIT.
9 ^ o Troca de
Informações de AIT
Sistemado Sistemado Orçào Autuador Ói^ão Convenido
Figura 5.8 - Diagrama de Caso de Uso para a troca de informações de ATT
E importante observar que este modelo considera que cada AIT refere-se a
apenas uma infração de trânsito.
O processo de troca de informações de AIT está dividido em duas etapas. A
primeira será controlada pelo Sistema do Órgão Autuador e terá como objetivos:
identificar quais os ATT's estão prontos para serem enviados para outros Órgãos de
Trânsito; definir qual o órgão destino de cada AIT; enviar o documento XML
correspondente. A segunda etapa é de responsabilidade do Sistema do Órgão de
Trânsito Conveniado e constitui-se em: consistir os ATT's recebidos; registrar eventuais
inconsistências; e retornar informações para o Sistema do Órgão Autuador.
A primeira etapa está representada no diagrama de seqüência da Figura 5.9.
Primeiramente, o Sistema do Órgão Autuador identifica os ATT's que ainda não foram
consistidos e gera um documento XML para cada Órgão de Trânsito Conveniado
correspondente ao destino dos ATT's. Cada um desses documentos XML, chamados de
Capítulo 5 - Modelo para Intercâmbio de Informações 47
xmlAit, contém informações relacionadas aos AIT's destinados a um único Órgão
Conveniado.
:Sistema do Òrqão Autuador
:AIT :OrqaoTransito
1: obterAITsNaoEnviados() ' 2:obterUrlOrgaoTransíto
xmlAit
3: enviar xmlAit
6: fegrstrarReciboAtíxmlReciboAí) i 3*
:Sistema do Órgão Conveniado
:AITExternn
— i 4: carregar AítExtetno(xmlAit), >
5: enviar xmlReciboAit
I
Figura 5.9 - Diagrama de Seqüência para o Caso de Uso Troca de Informações de ATT— identificação e envio
de ATT's
Gerado o xmlAit, esse documento é enviado ao Sistema do Órgão Conveniado
de destino que, por sua vez, cria um objeto da classe ATTExterno, o que significa incluir
um registro na base de dados apropriada, para cada AIT contido em xmlAit e retorna o
documento XML xmlReciboAit. O documento xmlReciboAit informa ao Sistema do
Órgão Autuador que o xmlAit foi recebido corretamente pelo Sistema do Órgão
Conveniado e qual a data desse recebimento.
Após receber o documento xmlReciboAit, o Sistema do Órgão Autuador registra
em cada AIT enviado anteriormente a data de recebimento pelo Sistema do Órgão
Conveniado.
A segunda etapa do processo de troca de informações de AIT é representada
pelo diagrama de seqüência da Figura 5.10. i
As mensagens 1, 2 e 3 compõem o processo de consistência dos AIT's lavrados
pelo Órgão Conveniado, os quais chamamos de AIT's locais, e daqueles recebidos do
Sistema do Órgão Autuador, os AIT's externos. A forma como elas estão apresentadas
no diagrama parte do princípio que a consistência dos AIT's locais será realizada no
mesmo instante que a consistência dos AIT's externos, entretanto, nada impede que
essas consistencias sejam realizadas em momentos e por processos diferentes. A
mensagem 1 realiza a consistência dos AIT's locais; a mensagem 2 chama o método da
Capítulo 5 - Modelo para Intercâmbio de Informações 48
classe AlTEx terno que consiste seus ATTs; e a mensagem 3 insere, na classe
InconsistenciaAiT, as inconsistências encontradas em cada AIT externo.
:Sistema do Õrqào Conveniado
i 1. consiste AIT Local
:AITExterno :lnconsistenciaAIT OmaoTransito
2: consistirAlExternoC)
:Sistema do Õraao Autuador
:AIT
3- criar hconsistenciaAit (i, orgao, numAifJ i
i
I 4' obter AitsConsfstidosC) ^ . i — I 5. obterUrlOrgaoTrarisilo
xmlAftConsistkto <r 7: enviar xmIArfConsistido
6: obterlnconsistenciaAilC'
*u'
10. registrarReciboAÍConsisrJdoi; xmReciboAitConsistido)
9: enviai xmIReciboAitConsistido
8: registrarAITConsisticlo (xmIAitCcjnsistKto)
Figura 5.10 - Diagrama de Seqüência para o Caso de Uso Troca de Informações de AIT - consistência de AIT
A partir da mensagem 4, inicia-se o processo que informa ao Sistema do Órgão
Autuador o resultado da consistência realizada pelo Sistema do Órgão Conveniado.
Primeiramente, são identificados os AIT's que já foram consistidos. Esses ATFs são
agrupados por Órgão Autuador e, para cada um desses órgãos, será gerado um
documento XML, chamado de xmlAitConsistido, que contém informações sobre qual o
resultado da consistência para cada AIT (AIT consistente ou inconsistente) e, quando
for o caso, quais as inconsistências encontradas.
Os documentos xmlAitConsistido são enviados aos seus respectivos Órgãos
Autuadores. Cada Órgão Autuador registra o resultado da consistência nos ATT's da
classe AIT e poderá, ainda, registrar as inconsistências encontradas nos AIT's em um
local específico para este fim, por exemplo, em uma classe como a InconsistenciaAiT.
Esta última operação não é mostrada no diagrama da Figura 5.10.
Após processar o documento xmlAitConsistido, o Sistema do Órgão Autuador
envia ao Sistema do Órgão Conveniado um documento XML, xmIReciboAitConsistido,
informando sobre aquele processamento. Finalmente, o documento
xmIReciboAitConsistido é processado pelo Sistema do Órgão Conveniado,
identificando quais os dados relacionados com a consistência dos AIT's foram
recebidos pelo Órgão Autuador.
Caoítuio 5 - Modelo para Intercâmbio de Informações 49
5.5 - Processo de Troca de Informações de NIT
Após o processamentos dos autos de infração de trânsito, inicia-se o
processamento das notificações de infração de trânsito (NTT's) a partir daqueles autos.
Este modelo considera que cada NTT está associada a apenas um ATT, assim como um
ATT refere-se a apenas uma infração. O caso de uso é apresentada no diagrama da
Figura 5.11.
9 ^ o Troca de
Informações de NTT
Sistema do Sistema do Orção Autuador Ói^ão Conveniado
Figura 5.11 - Diagrama de Caso de Uso para a troca de informações de NTT
Como vimos anteriormente, os ATFs são lavrados pelo Órgão Autuador e os
dados daqueles cujos veículos sejam licenciados em outros Estados são enviados para os
Órgãos Conveniados. Estes órgãos realizam a consistência dos ATT's. Para os AIT's que
passaram pela consistência sem nenhum impedimento serão geradas as NTT's. A
geração, a emissão e os controles de envio e entrega ao infrator e de pagamento das
guias associadas às NTT's, também, são de responsabilidade do Órgão Conveniado.
Uma característica do modelo apresentado neste capítulo é a preocupação em
manter o Órgão Autuador informado a respeito dos processamentos realizados nos
AIT's e nos documentos derivados deles, ou seja, nas NTT's e nos recursos. Neste
sentido, este processo de troca de informações de NTT consiste em informar ao Órgão
Autuador sobre a geração, emissão, envio, entrega e pagamento das NTT's. Isso dá ao
Órgão Autuador a capacidade de acompanhar as etapas necessárias para se efetuar a
multa de trânsito, fornecer informações necessárias ao julgamento de recursos
interpostos, além de possibilitar a extração de informações estatísticas e financeiras.
O diagrama de seqüência da Figura 5.12 representa o processamento, executado
pelo Sistema do Órgão Conveniado, que gera as NTT's, a partir dos ATT's recebidos do
Sistema do Órgão Autuador.
Nos diversos Sistemas dos Órgãos Conveniados, esse processamento pode ser
implementado de maneiras diferentes da apresentada pelo diagrama da Figura 5.12.
Contudo, seu objetivo é verificar quais ATT's estão aptos a dar origem a uma NTT, gerar
tais NTT's e registrá-las no local apropriado para o seu armazenamento.
Capítulo 5 - Modelo para Intercâmbio de Informações 50
.Sistema do Óraão Conveniado
:AITExterno :NITExtema
1; gera NIT Locai
2: gerarNitExternaí ) ^ p~| 3: criarNiExlerna()
Ú
Figura 5.12 - Diagrama de Seqüência para a geração das NTT's
Neste caso, estamos considerando que o processo do Sistema do Órgão
Conveniado que gera as NIT's dos AFT's locais, representado pela mensagem 1,
chamará um método da classe AlTbxterno (mensagem 2) que irá gerar as NIT's destes
AIT's externos e criará uma instância da classe NITExterna para cada uma destas NTT's
externas. Esta criação é representada pela mensagem 3.
O segundo processamento efetuado pelo Sistema do Órgão Conveniado nas
NTT's externas é a emissão dessas notificações. Esse processamento está representado
pelo diagrama de seqüência da Figura 5.13.
: S i s t e m a d o Ò r a ã o C o n v e n i a d o
i • 1: emite NIT
: NITExterna
2: emitirNitExterna() • i i
Figura 5.13 — Diagrama de Seqüência para a emissão das NIT's
Da mesma forma que a geração das NTT's, o processo de emissão poderá ser
efetuado de forma diferente em cada Órgão Conveniado. Consideramos que a emissão
das NTT's externas estará associada à emissão das NIT's locais, como mostrado pelo
diagrama da Figura 5.13.
O processamento das informações de envio e entrega de uma NTT ao infrator
consiste em registrar qual a data que tais fatos ocorreram. Em algumas soluções essas
informações são registradas manualmente, em outras elas são extraídas de um arquivo
fornecido pelos Correios.
Capitulo 5 - Modelo para Intercâmbio de Informações 51
Da mesma forma, a maneira como são registradas as informações relacionadas
ao pagamento da guia associada à NIT possue soluções distintas. Algumas vezes elas
são registradas manualmente e outras através do processamento de arquivos recebidos
do banco que recolheu o pagamento. As informações de pagamento são a data do
pagamento e o valor pago.
Até agora verificamos os processamentos que geram as informações das NTT's
que deverão ser enviadas para o Órgão Autuador. O diagrama de seqüência da Figura
5.14 representa o processo através do qual o Sistema do Órgão Conveniado informa ao
Sistema do Órgão Autuador que as NTT's, relacionadas aos seus ATT's, foram geradas,
emitidas, enviadas, entregues ou pagas.
Primeiramente, é necessário identificar quais NTT's sofreram alterações durante
os processamentos de geração, de emissão, de registro de envio, de registro de entrega
ou de registro de pagamento da guia. Isso é importante para que possamos criar os
documentos XML que deverão ser enviados aos respectivos Sistemas dos Órgãos
Autuadores. Estes documentos são chamados de xmlNit.
:Sis1ema do Qraáo Conveniado
:NITExtema iQrgaoTransito
1: obterNisPendentesC)
:Sislema do Óroão Autuador
:NIT
- U 2: obterUrlOrgaoTransio
xmlMt -D
r-i-i 3: enviar xmMí
5: enviar xmiReciboNit
Ç: regis!rarRectooNí(xmlReciboNí)
4: regisirarNit(xmlNit)
D
Figura 5.14 - Diagrama de Seqüência para o Caso de Uso Troca de Informações de NIT
Cada Sistema de Órgão Conveniado identificará tais NTT's de maneira
específica. No diagrama da Figura 5.14, foi criado o conceito de NIT externa
"pendente". Quando uma NTT externa está pendente, significa que ela está aguardando
para ser enviada ao Sistema do Órgão Autuador.
Os objetos da classe NTTExterna possuem um atributo, chamado situacaoNit,
que indica se eles estão pendente ou não. Portanto, os processamentos de geração,
Capítulo 5 - Modelo para Intercâmbio de Informações 52
emissão, envio, entrega e pagamento, apresentados nesta seção, deverão alterar o estado
da NTT para pendente, ou seja, atribuir ao situacaoNit o valor "PE". É através da
verificação do valor deste atributo que a mensagem 1 (um) do diagrama solicita a
criação dos documentos xmlNit.
Após criado, o documento xmlNit é enviado ao Sistema do respectivo Órgão
Autuador. Este, por sua vez, registra em sua base de dados as informações contidas
naquele documento e retorna o documento XML xmlReciboNit, informando ao Sistema
do Órgão Conveniado se ocorreu algum problema.
O conteúdo do xmlNit é composto pelas datas de geração, emissão, envio,
entrega e pagamento da guia de cada NTT, além do valor pago, quando for o caso. Como
veremos na especificação do documento xmlNit, nem todas estas informações
necessitam estar contidas no documento, ao mesmo tempo.
Finalmente, o Sistema do Órgão Conveniado processa o documento
xmlReciboNit, registrando em cada NTT externa a situação do recebimento pelo Sistema
do Órgão Autuador.
5.6 - Processo de Troca de Informações de Recursos
Para que um infrator interponha um recurso contra a multa que recebeu, é
necessário a apresentação de um documento com uma descrição textual da alegação.
Além disso, algumas cópias de documentos são solicitadas, tais como: a notificação de
infração de trânsito, carteira de identidade, CPF, carteira nacional de habilitação,
documento do veículo e outros documentos que comprovem a alegação do recurso.
Segundo o art. 16 do CTB, "junto a cada órgão ou entidade executivos de
trânsito ou rodoviário funcionarão Juntas Administrativas de Recursos de Infração -
JARI, órgãos colegiados responsáveis pelo julgamento dos recursos interpostos contra
penalidades por eles impostas".
No caso de infrações cometidas em locais diferentes ao do licenciamento do
veículo, os documentos para o recurso podem ser apresentados junto ao órgão ou
entidade de trânsito da residência ou domicílio do infrator, conforme art. 287 do CTB,
no nosso caso, ao Órgão de Trânsito Conveniado. Entretanto, como é o Órgão de
Trânsito Autuador que impõe as penalidades, o julgamento dos recursos contra estas
penalidades é de responsabilidade da JARI vinculada a este órgão. Sendo assim, há a
necessidade de envio daqueles documentos recebidos pelo Órgão de Trânsito
Capítulo 5 - Modelo para Intercâmbio de informações 53
Conveniado para o Órgão de Trânsito Autuador, que, por sua vez, enviará tais
documentos à JARI responsável pelo seu julgamento, ou seja, para a JARI vinculada a
ele.
Com base nisso, o fluxo de dados de recursos será composto de dados
informativos sobre a interposição do recurso e de dados sobre a conclusão do processo,
sem levar em consideração seu trâmite. A Figura 5.15 apresenta o diagrama de caso de
uso. O fluxo de dados é apresentado nos diagramas de seqüência das Figuras 5.16 e
5.17.
O
Sistema do Órgão Autuador
Troca de Informações de
Recursos
Sistema do Òrção Conveniado
Figura 5.15 - Diagrama de Caso de Uso para a troca de informações de Recursos
Nesses diagramas de seqüência, consideramos que, tanto no Órgão Autuador
como no Órgão Conveniado, o mesmo sistema que executa o processamento dos autos
de infração e das notificações, realiza o processamento dos recursos interpostos. Há a
possibilidade, porém, dessas tarefas serem realizadas por sistemas diferentes.
Entretanto, para o modelo proposto, o importante é observarmos os documentos XML
que são transmitidos, de forma que eles sejam manipulados de forma correta.
:Sistema do Órgão Conveniado
1: registrarRecurso()
:Recurso :QrgaoTransito
D ' 2. otaterRecLjrsosNovos()
i i
r -U 3; obterUrlOrgaoTransito
xmlRecurso
r h 4: enviar xmlRecurso
:Sislema do Qrgáo Autuador
:Recurso
" D
6: enviar xmfffeciboRecurso
7: registrarRecifcioRecursotwTiReciboRecurso)
•—i 5 registrarRecursosExiernos(xmfRecurso)
i I
Figura 5.16 - Diagrama de Seqüência para a Troca de Informações de Recursos — processo de registro do
recurso
Capítulo 5 - Modelo para Intercâmbio de Informações 54
O diagrama de seqüência da Figura 5.16 representa o processo de registro do
recurso. Ele inicia-se no Órgão Conveniado que, após registrar em seu sistema o recurso
e receber do infrator os documentos que o instruirão, enviará ao Sistema do Órgão
Autuador informações a respeito desse recebimento, tais como, a data de recebimento,
os números do ATT e da NFT. Para isso, utiliza o documento XML xmlRecurso. O
Sistema do Órgão Autuador fará o registro desses recursos e, a partir desse momento, a
JARI vinculada ao Órgão Autuador já fica ciente de que receberá, brevemente, os
documentos correspondentes ao recurso. Esses documentos serão enviados via Correios
ou por algum outro meio acordado pelos órgãos.
Nesse caso, os papéis exercidos pelo Sistema do Órgão Autuador e pelo Sistema
do Órgão Conveniado podem ser invertidos, ou seja, o recurso pode ser protocolado
diretamente no Órgão Autuador, que deverá registrar o recurso P enviar o documento
xmlRecurso para o Sistema do Órgão Conveniado. A diferença desse procedimento para
o anterior é que não haverá necessidade de envio de documentos via Correio, uma vez
que a JARI que receberá tais documentos é a mesma que julgará o recurso.
Nesse ponto, devemos nos lembrar da pontuação associada a cada infração.
Quando algum condutor de veículo comete alguma infração de trânsito, a pontuação
associada àquela infração será atribuída ao seu prontuário. Como explica Arnaldo
Rizzardo [RIZZOO], de acordo com o CTB, "sempre que o infrator atingir a contagem
de vinte pontos, no período de doze meses, sofrerá a penalidade de suspensão, nos
limites estabelecidos no art. 261".
Uma vez que o condutor poderá ter suspenso seu direito de dirigir, é prudente
que a pontuação atribuída a um infrator só passe a ser computada após o julgamento do
recurso. Uma solução para este problema, como é feito pelo DETRAN-MG, é aguardar
o prazo para a interposição do recurso para que a pontuação seja computada. Caso
exista algum recurso, a pontuação será suspensa e será aguardado o resultado de seu
julgamento.
Sendo assim, independentemente de onde o recurso foi protocolado, é
importante que o Órgão Conveniado tome providência para que a pontuação atribuída
ao infrator não seja computada, até a conclusão do recurso. Daí a importância de se
enviar o documento xmlRecurso ao Sistema do Órgão Conveniado, mesmo quando o
recurso é apresentado ao Órgão Autuador. No caso do Órgão de Trânsito Conveniado
ser municipal, ele deverá informar ao DETRAN de seu Estado a interposição do recurso
para que a suspensão da pontuação seja executada.
Capítulo 5 - Modelo para Intercâmbio de Informações 55
O resultado do julgamento de um determinado recurso deverá ser informado ao
Órgão Conveniado, como mostrado pelo diagrama de seqüência da Figura 5.17.
Sistema do Òraâo Autuador
:Recurso :OrrjaoTransito
1: obterRecursoConcluido( J ^ ,_]_, ?_ obterUríOrgaolransío • 1 - ~,
xmIR e sultadaRecurso
i-U 3: enviar xmlResuladüRecui so
iSistema do Òrqão Conveniado
:Recurso
~0
5: enviar xirtRecitooResultedoRecurso i
6: r e gistr arR ecib oResult adoR e cur s o( xmlRecitooResuN adoRecu r s o)
4: registrarResultadoRecurso (x rrt ResuSadoRecurso)
Figura 5.17 - Diagrama de Seqüência para a Troca de Informações de Recursos — processo de informação do
resultado do recurso
Ao receber os documentos referentes ao recurso, a JARI vinculada ao Órgão
Autuador o analisará e dará o resultado de seu julgamento de acordo com
procedimentos preestabelecidos. No final do processo, o resultado do julgamento deverá
ser informado ao Sistema do Órgão Autuador, que enviará ao Sistema do Órgão
Conveniado os dados sobre este resultado através do documento XML
xmlResultadoRecurso. Como foi mencionado, isto é necessário para que seja solicitada
a confirmação ou anulação da pontuação aplicada ao prontuário do infrator.
5.7 - Classes e Métodos Referenciados pelo Modelo
Esta seção especifica as classes referenciadas nos diagramas de seqüência
apresentados nas seções anteriores. O diagrama de classes da Figura 5.18, mostra todas
aquelas classes e alguns de seus relacionamentos.
Nem todos os relacionamentos entre as classes, necessários a um sistema de
processamento de infrações, estão representados na Figura 5.18. Por isso, por exemplo,
as classes Veículo e OrgaoTransito não estão associadas a qualquer outra. Da mesma
forma, os atributos de cada classe estão restritos àqueles necessários à realização do
modelo.
Capítulo 5 - Modelo para Intercâmbio de informações 56
_WT
Inscon sutenctaAíT
r u m e r o r e o t i c Q m t s t e n c i a nurnéricQ(3)
R e c u s o
a n É g o O ^ a o T i a n S i O í m a p o s i ç ã o rmnéricoCâí n u n e r o R e c i r s o numéncail l l dalalnterposicsa drta i W a C o n c l i j j a o dala cfalaXmfíecijrso * t a horaXmlRecurso hora datawnfíesutadoRecursc. Data hwnXmlrTesuladoReciirso hcia síuacaoRecurso. car a « m ( í i oosicacfíecursa ca»acta(11 resi i taJotfectrsQ canacferflt
! i \ fdiS|unçào, Cardielo)
j ReCU3DÍOCHÍ j íTecizsoEittrTio
J I
MI codqoOtgaoTtansr l íWf r*imenca(6) m m e r o N J nurrér*o(lOl dalaGeracao data datsEirissao data d a t e f n v » data dstaErtrega data datsPagarrierta data vaUrPagcr numeren! 9.2 J o a t a X < * l data
« j r i X m M t : hora
Orgaolransíto
ciKbgiiCtQaoTrareio- ruréncoCEi) nitf*eOgsoTrÈris*o caracterizo) c»ssrr¡cacooi>g¡aolraristo: caracter!' I U F O r g a o T r a r a l o t a r a d er<2) CMAgcMuncqiioCigsDTrarrslD m m e i i c o M ) urIOrgaotransia caroder(3noi
A i i e d e m n
V e c i i o
rpnavam. nunénco(9) placa. c a r s a c r í l O ) codKioMarcaMccIeto nunencocG) cDctrjdMuriciiiioVeKUlo mjnenco(4j ufVticulü caracter¿2) c » caracter í M l
PtacaSot alada
placnVscticr ceracterflO) codigoOrgaoTransIoSoiiclarte m i rráicoCÈ) dataXiTiPlacGs: data horsrXutflacas - hora slatuíf laca caracteiO i
U I E í t t r r a
c o r t g o C r g s o T r a n s i D f * wnenraBi r u n e r d W n u n e n C o O O ) a « B G e r a c a o data 'JataEtriEsao: data d f l t a E n ™ data OataErbega data drtaPegainerto. date VafcrPago rvmákXí<S¿) M a X i r N data h o r a * * * * ñor» SJtuocaoMr caraclsr(21
Figura 5.18 - Diagrama de Classes
No que se refere à classe Recurso, foram chadas duas subclasses, RecursoLocal
e RecursoEx terno, para diferenciar os recursos interpostos no Órgão Autuador ou no
Órgão Conveniado. A restrição d i s j u n ç ã o , c o m p l e t o , indica que todas as
instâncias de Recurso correspondem ou a uma instância de RecursoLocal ou a uma
instância de RecursoExterno, nunca às duas ao mesmo tempo.
Antes, porém, de descrevermos os atributos e as operações de cada classe,
definiremos os pacotes que agruparão essas classes conforme a sua utilização nos
sistemas dos órgãos autuador, conveniado e central, a partir do que foi especificado nos
diagramas de seqüência. A Figura 5.19 apresenta este agrupamento.
Como define Booch at alli [BOOC00], um pacote, na UML, "é um mecanismo
de propósito geral para a organização de elementos em grupos" e "é representado
graficamente como uma pasta com uma guia". Esses pacotes podem estar aninhados
dentro de outros pacotes.
Capítulo 5 - Modelo para Intercambio de Informações 57
CoíígoOrgsoTr ansio: numérca(6) EtentrOcacaaM caractere 1Sl p l a c a V e c i i o . earacier(Kr) r a i a v a m numericoO) ciicIgdMiriiüpóVeiculo: m»riérico(4) •iTVatuto. caracter(2¡ nrjmeCmdutcr: caracterizo) r i m a r c O H C o o d u l o r : numérteo(11'i ulCNHCoricUor: c a r a c t e r e ) nomefrilralor c»«cterf4D) rtmeroCPFhttator n u n * í c o i ; i l ) ramwoCGOrrfraior carac1«f(t5) enoerecotnfrator caractei(SO) nomeMuntópiotnfrstor: caracter(301 local ri f ração corocter(50) conWenwrtrjLocaNnfracso: corader(20) ( H a É y r s c B r j data
hef alníracao: heta c c d g c M m v s o h r r a c a o rotnérEW») c a i g o r r f r a c a a n«nenci<4) d e s c & H M r n a n l D A f e i c a a : earacterOO) *alorL>rí*PBnTi(do: numénco(7,2) vafcvMHlcaoReatzada: n u r é n c o t ? J j <ndadeMe<ida: caract«(1G) c o d g o A g e r t e : caracterçaí) rJataKiríAjt dota horaX/niSi hora ríatftCorrsistorKBi nata r w a C c r i r f f i l * ™ » : hora •tA&MM&ratíMa dato húraXmlArtCcnsastido: hora situflcaoMExterrw c a r a d e r ( 2 i ruftesutadoCorrsislencta; c a r a d « ( 2 )
C«*9oOrgaoTríl>s*o iufTínc<3(5'J •ieríilicacacArl caracteii.15) placsVeicuto caracterl/lOI (enavam runéi>ct<9) c o í t g o ^ r t ó p i o V e K i J o : runérlco(4) u r V e c u t o c a r a d a Ç2) riomeConttijtòr caracter (-10) n u n e r c C N H C o n d i l w n u r f n r o O l ) U í C W C c n d u t o i ca rociei f 2) nometif iator cflracleríW) nimmgirPFtmtrtor num»rieo(11 j f u m e r o C e C f i f ratar. c w a c t e r n S ) eriderecolniratai, caracten.50) rromeMiinK|Jiohiralor caracler(30) b c a l n t r a c a o cara«er(50) tomptemertoLucalnlracao caracterizo) üatalntracac: dsía hursti iracao hflra cnMCOuridploIrr lracao numéncii iJ l corigointracao runencoi.41 descEqu»5arieráoAfencao caracter [30) vsJotLimitePerrTBtidQ; r w a r c o í J .2) V(l(orMB^llc^oRea^¡Ialla, nunérict>(7,2) uradadeMediaa caracterr.iai CodigoAgente carocterí2Q] codigoRelPirwVeioJo c s a c i e i ¡2) dataXmlHaca date liornXrnlPIsci hora
c i x W e O i i w j T r s r r a r r f i e s t i r o numéiiwn'*! datsMrtFlsc*; dats tniTTH'XmlPI'icaí hora OataRecitoAS data l ioraReotJoAí h o l a situai a s i ! caracteri;;i ridResiiitattoConsiítencia csracler(::<
orgaoCentral
orgaoTransito
oblefUrtOnifloTranslo rcocKTtM»- miraSrieoV c a r á t e r
ctiterftecurgfisHovosi' ~i regsttarRw-irsosE aterras fnrfteeusadnr.KiTiReciTSol
71
S - ' U J J t l ^ << I m p o r t 8
orgaoConveniado
o f l e i V e i c u l o ; («TiIPtaca: dscXm p a c a s !
kisconsistenciaAÍT
oiarlncoreísiencisAi ( l numèoco; cadlgoOiBHOTransi a numérico, utentificBC aoAiLcacade')
ottterficiJnsisteflcittAI icataoCtaaoTtansap: m n è n c o : M e r l i t c a c a o M c»BCteii
roctjrPtacas urhPlacas lioc^mjCiacaii eylisirPlacaã \ i
RecursoExtemo
oroaoAutuador
Air
wenx«SeiTifclemwcacao f) reosIraiUfVelc^
recistiarReciboAI l a r i R e o O o f l j l i d o c X n i R e c b o A i l teastrwAtCQTOshdoixniAfCfMwist ido docXrr|lAflCfirBctidcn
fegtsff
Figura 5.19 - Pacotes de Classes
Sendo assim, cada pacote apresentado na Figura 5.19 organiza as classes e suas
operações de forma que possamos verificar a quais sistemas eles deverão estar
associados. Os pacotes orgaoAutuador, orgaoConveniado e orgaoCentral associam-se
aos sistemas dos órgãos autuador, conveniado e centrai, respectivamente.
Yale observar que os pacotes orgaoAutuador e orgaoConveniado possuem uma
relação de dependência com o pacote orgaoTransito. Neste caso, tanto no ambiente do
Órgão Autuador quanto no do Órgão Conveniado deve existir, além de seus respectivos
pacotes, o pacote orgaoTransito. Considerando que os órgão de trânsito exercerão
ambos os papéis, ou seja, ora papel de autuador ora papel de conveniado, os três pacotes
devem existir no ambiente de todos os órgãos que utilizam o modelo, a exceção do
ambiente do órgão central.
O estereótipo « i m p o r t a » , especificado na Figura 5.19, segundo a UML,
define um relacionamento de importação que "assegura uma permissão unilateral para
que os elementos de um pacote tenham acesso aos elementos pertencentes ao outro
Capítulo 5 - Modelo para Intercâmbio de Informações 58
pacote" [BOOC00]. No caso, os elementos dos pacotes orgaoAutuador e
orgaoConveniado acessam os elementos do pacote orgaoTransito.
Como foi mencionado, as operações de cada classe, também, são apresentadas
na Figura 5.19. A grande maioria das operações estão sublinhadas, isso significa que são
operações com o escopo de classe, ou seja, são operações que criam instâncias da classe
ou são códigos único que operam sobre todas as instâncias da classe.
As operações que não estão sublinhadas possuem o escopo de instância, isso
significa que a operação é utilizada junto a uma única instância da classe.
5.7.1 - A Classe AIT e os Tipos de Atributos
Como citado anteriormente, todo o processo de troca de informações inicia-se
com a identificação dos AIT's que estão associados a veículos cujo licenciamento
poderá ter ocorrido em uma UF diferente daquela na qual foi cometida a infração. Esta
identificação deverá ser desenvolvida a partir dos esquemas de dados utilizados pelos
sistemas de processamento de infrações de cada Órgãos de Trânsito e, portanto, será
específica para cada um. Entretanto, o resultado desse processamento deverá ser
compatível com as definições especificadas neste modelo,
A classe AIT é a ciasse básica para o funcionamento do modelo e, por isso, ela
está sendo destacada nesta seção. Alguns de seus atributos foram definidos a partir da
Resolução 001/98 do CONTRAN, que estabelece as informações mínimas que deverão
constar do Auto de Infração de Trânsito cometida em vias terrestres (urbanas e rurais).
Outros surgiram juntamente com as definições das interações especificadas pelo
modelo. Os atributos codigoOrgaoTransito e identificacaoAit identificam um único
ATT, ou seja, em um modelo entidade-relacíonamento, tais atributos representariam a
chave primária do tipo entidade AIT.
O resultado dos processos de identificação dos ATFs, realizados pelos sistemas
de cada Órgãos de Trânsito, deve ser compatível com a estrutura de dados definida
pelos atributos da classe AIT. Nesse caso, a expressão "ser compatível" não significa
que as estruturas de dados utilizada pelos sistemas de processamento dos vários Órgãos
de Trânsito deverão ser idênticas ao definido pela classe, mas que deverá haver uma
forma de mapeamento das estruturas de dados dos sistemas para a estrutura da classe
AIT e vice-versa.
A Tabela 5.1 apresenta os atributos da classe AIT.
Capítulo 5 - Modelo para Intercâmbio de Informações 59
Tabela 5.1 - Atributos da Classe AIT Nome do Atribulo Tipo Tam. Descrição
codigoOrgaoTransito numérico 6 Código do Órgão de Trânsito que lavrou o ATT jdentificacaoAit caracter 15 Série e número do ATT no Órgão Autuador placaVeiculo caracter 10 Placa do veículo renavam numérico 9 N° do RENAVAM do veículo autuado codigoMunicipio Veiculo numérico 4 Código TOM do município de origem do veículo ufVeiculo caracter 2 Unidade Federativa (XJF) de licenciamento do veículo nomeCondutor caracter 40 Nome do condutor numeroCNHCondutor numérico 11 N° da Carteira Nacional de Habilitação (CNH) do condutor do veículo ufCNHCondutor caracter 2 UFdaCNH nomelnfralor caracter 40 Nome do infrator numeroCPFInfrator numérico 11 N° do CPF do infrator numeroCGCInfrator caracter 15 N" do CGC do infrator enderecohifrator caracter 50 Endereço do Infrator nomeMunicipioInfralor caracter 30 Nome do Município do Infrator local Infração caracter 50 Local da Infração (logradouro, número etc.) compleme ntoLocalInfrac ao caracter 20 Complemento do local da infração datalnfracao data - Data da infração horaínfracao hora - Hora da infração c odi goM unicipiolnfracao numérico 4 Código TOM do município onde ocorreu a infração. TOM é a Tabela
Oficial de Municípios utilizada pelo DENATRAN. codigolnfracao numérico 4 Código da infração, segundo a tabela do DENATRAN àescEqmpamentoAîencao caracter 30 Descrição do equipamento de aferição utilizado para verificar a infração
(tipo, marca, modelo, n* do lacre do INMETRO etc.) valorLimite Permitido numérico 7,2 Valor limite permitido (por exemplo, velocidade máxima da via) valorMedicaoReahzada numérico 7,2 Valor da medição realizada pelo equipamento de aferição unidadeMedJda caracter 10 Unidade de medida utilizada pelo equipamento de aferição. Pode ser;
Km/h; Kg; Dg/l; g%; Mg/l codigoAgente caracter 20 Código do agente que lavrou o ATT codigoRetomoVeiculo caracter 2 Código de retorno do processo de identificação do veículos:
VE - veículo encontrado; NE - veículo não encontrado; NP - veículo não pesquisado
dataXmIPlacas data - Data de geração do documento xmlPlacas que contém o ATT horaXmlPlacas hora - Hora de geração do documento xmlPlacas que contém o ATT cwdigoOrgaoTransitoDestino numérico 4 Código do órgão de trânsito conveniado, para o qual foi enviada a ATT dataExtracao data - Data da extração do ATT para xmlArr horaExtracao hora - Hora da extração do A1T para xmlAIT dataReciboAit data - Data de recebimento do ATT, informada no documento xmlReciboAit horaReciboAit hora - Hora de recebimento do ATT, informada no documento xmlReciboAit situacaoAit caracter 2 Situação de retomo do ATT em relação ao Órgão de Transito
Conveniado. Valores válidos: NE - não enviado; EN - enviado; CF — confirmado; NC - não confirmado; CT - consistente; IN - inconsistente
As operações e a descrição de cada uma delas são apresentadas na Tabela 5.2. Tabela 5.2 - Operações da Ciasse ATT
Nome da Operação Descrição veicuioSemldentificacao í ') Gera o documento xmlPlacas, contendo todos os veículos que ainda não foram
pesquisados (codigoRetomoVeiculo = "NP") e que não contêm identificação da UF de licenciamento. Os atributos dataXmIPlacas e horaXmlPlacas devem ser atualizados.
reeistrarUFVeiculo íxmlVeiculosidocXmlVeiculos)
Registra, no respectivo AIT, os valores dos atributos ufVeiculo e codigoRetomoVeiculo, para cada veículo retomado em xmlVeiculo. Deverá ser atribuído o valor "NE" ao atributo situacaoAit para todos os ATTs cujos veículos foram encontrados (codigoRetomoVeiculo = "VE"),
obterAitsNaoEnviados ( ^ Gera os documentos xmlAit, para cada órgão conveniado, contendo todos os ATTs que já passaram pela identificação de veículo e que ainda não foram enviados aos seus respectivos destinos (situacaoAit = "NE"). Os atributos dataExtracao e horaExtracao devem ser atualizados e o atributo situacaoAit deverá receber o valor "EN' (enviado).
reeistrarReciboAit íxmlReciboAit:doc XmlReciboAit)
Atualiza o valor do atributo situacaoAit com o valor do código de retomo recebido no conteúdo do documento xmlReciboAit, para cada ATT. Os ATTs a serem atualizados serão aqueles cujo os atributos dataXmIPlacas e horaXmlPlacas possuem valores idênticos aos especificados no documento xmlReciboAit. O valor do código de retomo do documento xmlReciboAit poderá ser "CF7 (confirmado) ou "NC (não confirmado).
É importante apresentar algumas considerações a respeito dos tipos dos atributos
apresentados na Tabela 5.1 e que serão utilizados por este trabalho:
Capítulo 5 - Modelo para Intercâmbio de Informações 60
• um atributo do tipo "caracter" poderá receber valores alfanuméricos - letras,
números e sinais;
• um atributo do tipo numérico poderá conter apenas números;
• um atributo do tipo data possui o tamanho fixo de 10 (dez) bytes e seu valor deverá
ser uma data no formato "AAAA-MM-DD", onde AAAA corresponde ao ano, MM
corresponde ao mês e DD corresponde ao dia do mês;
• um atributo do tipo hora possui o tamanho fixo de 5 (cinco) bytes e seu valor deverá
obedecer ao formato "HH:MI:SS", onde HH corresponde à hora do dia no padrão 24
horas, MI corresponde aos minutos e SS corresponde aos segundos.
• o número entre parênteses após a descrição do tipo representa o tamanho em bytes
do atributo em questão, por exemplo: a declaração "codigoAgente: caracter(20)"
significa que o atributo codigoAgente é do tipo caracter e possui o tamanho de 20
bytes;
• no caso do tipo numérico quando houver uma especificação de tamanho como em
"valorMedicaoRealizada: numérico(7,2)", o primeiro valor representa o tamanho
total do atributo e o segundo representa o número de casas após a vírgula. Assim, no
caso de valorMedicaoRealizada, o atributo possui tamanho total de 7 (sete) bytes
sendo que os dois últimos representam as casas decimais.
Os tipos docXmlVeiculos e docXmlReciboAit, utilizado pelas operações,
correspondem aos documentos XML xmlVeiculos e xmlReciboAit, respectivamente. As
definições de tais documentos serão apresentadas posteriormente neste capítulo. No
decorrer deste capítulo outros tipos iniciados por docXml serão referenciados,
correspondendo aos documentos XML de mesmo nome.
A classe AITExterno é semelhante à classe AtT, entretanto suas operações são
bem distintas. As Tabelas 5.3 e 5.4 apresentam os atributos e as operações,
respectivamente. Tabela 5 3 - Atributos da Classe AITExterno
Nome do Atributo Tipo Tam. Descrição codigoOrgaoTransito numérico 6 Código do Órgão de Trânsito que lavrou o AU identificação Ait caracter 15 Série e número do AIT no Órgão Autuador placaVeiculo caracter 10 Placa do veículo ratavam numérico 9 N° do RENAVAM do veiculo autuado cod i goM unicipi o Veiculo numérico 4 Código TOM do município de origem do veículo ufV eiculo caracter 2 Unidade Federativa (UF) de licenciamento do veículo nomeCondutor caracter 40 Nome do condutor numeroCNH Condutor numérico 11 N° da Carteira Nacional de Habilitação (CNH) do condutor do veículo ufCNHCondutor caracter 2 UF da CNH nomelnfrator caracter 40 Nome do infrator numeroCPFinfraEor numérico 11 N" do CPF do infrator numeroCGCInfrator caracter 15 N° do CGC do infrator enderecolnfrator caracter 50 Endereco do Infrator nomeMunicipioInfrator caracter 30 Nome do Município do Infrator
Capítulo 5 - Modelo para Intercâmbio de Informações 61
local Infração caracter 50 Local da Infração (logradouro, número etc.) complemento Localln fracao caracter 20 Complemento do local da infração datalnfracao data - Data da infração horalnfracao hora - Hora da infração codigoMunicipioInfracao numérico 4 Código TOM do município onde ocorreu a infração codigolnfracao numérico 4 Código da infração, segundo a tabela do DENATRAN descEquipamentoAfericao caracter 30 Descrição do equipamento de aferição utilizado para verificar a
infração ("tipo, marca, modelo, n" do iacre do EVMETRO etc.) valorLimitePerrnitido numérico 7,2 Valor da limite permitido valorMedicaoRealizada numérico 7,2 Valor da medição unidadeMedida caracter 10 Unidade de medida utilizada pelo equipamento de aferição. Pode ser:
Km/h; Kg: Dg/l; g%; Mg/l codigoAgente caracter 20 Código do agente que lavrou o AIT dataXmJAit data - Data do documento xmlAit no qual o AIT foi recebido horaXmiAri hora - Hora do documento xmlAit no qual o AIT foi recebido dataConsistencia data - Data da realização do processo de consistência horaConsistencia hora - Hora da realização do processo de consistência dataXrnlAitConsistido data - Data da geração do documento xmlAitConsistido no qual o AIT está
contido horaXmlAitConsistido hora - Data da geração do documento xmlAitConsistido no qual o AIT está
comido situacaoAitExterno caracter 2 Situação do AIT externo em relação ao Órgão de Transito Autuador.
Valores válidos: NR - não respondido; RE - respondido; CF - confirmado, NC - não confirmado
indResultadoConsistencia caracter 2 Indicador do resultado da consistência. Situação do ATT em relação ao processamento de consistência. Valores válidos: NP - não processado; CT - consistente; IN - inconsistente
A classe AITExterno está associada ao Sistema do Órgão Conveníado, ao
contrário da classe AIT que está associada ao Sistema do Órgão Autuador. Tabela 5.4 - Operações da Classe AITExterno
Non»- [ki Opi-niciin Descrição carreEarAitExtemo (xmlAít: docXmlAil) Insere os AIT's contidos no documento xmJAit em AITExterno e gera
o documento xmlReciboAit a partir daqueles AIT's. Se não ocorrer problemas durante a inserção dos AIT's, o código de retomo de xmlReciboAit será "CF' (confirmado). Os atributos dataXmlAit e horaXmlAit devem ser atualizados, conforme valores recebidos em xmlAit. Além disso, o atributo indResultadoConsistencia deverá ser atualizado com o valor "NP" (não processado) e o atributo situacaoAitExterno deverá conter o valor "NR" (não respondido). No caso de ocorrer algum problema com o documento xmlAit, este documento não será processado e o código de retomo de xmlReciboAit será "NC" (não confirmado).
consistirAitExtemo í ) Realiza o processamento de consistência dos AIT"s externos e atualiza o atributo indResultadoConsistencia com o valor "CT", para os AIT's consistentes, ou 'TN'', para os inconsistentes. Este processamento deverá verificar os itens definidos no Apêndice B. Serão criadas instâncias da classe InconsisienciaAIT, através da operação Inserir Inconsistência Ai t, para as inconsistências encontradas. Os atributos dataConsistencia e ftoraConsistencia devem ser atualizados.
obterAitsConsistidos ( ) Gera os documentos xmlAitConsistido, para cada órgão conveníado, contendo todos os AIT's que já passaram pelo processamento de consistência (indResultadoConsistencia igual a "CT" ou "UV") e que ainda não foram enviados aos seus respectivos destinos (situacaoAitExterno igual a "NR"). Junto aos AITs inconsistentes, serão enviadas quais as inconsistências foram encontradas. Os atributos tktaXmlAitConsistido e horaXmlAitConsistido devem ser atualizados.
reaistrarRecí bo Ai tCon sí sedo UmlReciboAitConsistido: docxmlReciboAitConsistido)
Para cada AIT externo, atualiza o valor do atributo situacaoAitExterno com o valor do código de retorno recebido no documento xmlReciboAitConsistido. Os AIT's externos a serem atualizados serão aqueles cujo os atributos dataXmlAitConsisddo e horaXmlAitConsistido possuem valores idênticos aos especificados no documento xmlReciboAitConsistído. O valor do código de retomo do documento xmlReciboAitConsistído poderá ser "CF' (confirmado) ou "NC" (não confirmado).
Para cada AIT externo, atualiza o valor do atributo situacaoAitExterno com o valor do código de retorno recebido no documento xmlReciboAitConsistido. Os AIT's externos a serem atualizados serão aqueles cujo os atributos dataXmlAitConsisddo e horaXmlAitConsistido possuem valores idênticos aos especificados no documento xmlReciboAitConsistído. O valor do código de retomo do documento xmlReciboAitConsistído poderá ser "CF' (confirmado) ou "NC" (não confirmado).
perarNitExterna ( ) Gera NIT's para todos os AIT's consistentes (indResultadoConsistencia = "CT") que ainda não passaram por este processamento.
Capítulo 5 - Modelo para Intercâmbio de Informações 62
5.7.2 - Demais Classes Referenciadas pelo Modelo
Além da classe ATT e ATTExterno, o modelo apresentado utiliza outras classes
que serão apresentadas a seguir.
A classe Veiculo está presente no Sistema do Órgão Central e no Sistema do
Órgão Conveniado. Ela possui os dados dos veículos licenciados. Estes dados são
utilizados para informar aos sistemas dos órgãos de trânsito solicitantes a origem de
determinado veículo.
As Tabelas 5.5 e 5.6 apresentam, respectivamente, os atributos e operações da
classe Veiculo. Tabeia 5.5 - Atributos da Classe Veículo
Nome do Atributo Tipo Tam. Descrição renavam numérico 9 Número do RENAVAM do veículo placa caracter 10 Placa do veículo codi RoMarcaModelo numérico 6 Código da Marca/Modelo do veículo conforme tabela do DENATRAN codi goMunict pio Veiculo numérico 4 Código TOM do município de origem do veículo uiVeiculo caracter 2 UF de licenciamento do veículo cor caracter 20 Cor predominante do veículo
Nome d» Operação Descrição obterVeiculos (xmlPlacas: docXmlPIacas) Gera o documento xmlVeiculos a partir das placas do documento xmlPlacas, Para
cada placa em xmlPlacas, deverá verificar caso o veículo seja encontrado, o xmlVeiculos deverá conter os dados do veículo relacionado à placa, além do código de retomo t'£ (veículo encontrado); caso o veículo não seja encontrado, no xmlVeiculos deverá estar apenas a placa e o código de retorno (não encontrado ).
A classe OrgaoTransito contém informações a respeito dos Órgãos de Trânsito
que interagem com o modelo. Ela se encontra no pacote orgaoTransito e está associada
tanto ao Sistema do Órgão Autuador, quanto ao Sistema do Órgão Conveniado.
Nome do Atributo Tipo Tam. Descrirão codigoOrgaoTransito numérico 6 Código do Órgão de Trânsito definido pelo DENATRAN nomeOrgaoTransito caracter 30 Nome do Órgão de Trânsito cias si ficacaoOrgaoTran sito caracter 1 Classificação dos órgãos de transito. Os valores válidos são:
M - Municipal; E - Estadual; N - Nacional ufOrgaoTransito caracter 2 UF do Órgão de Trânsito codigoMunicípioOrgaoTransito numérico 4 Código do Município do órgão de Trânsito, quando for o caso. urlOrg aoTransito caracter 200 URL para a qual deverão ser enviados os documentos destinados ao
Órgão de Trânsito
Nome da Operação Descrição obterUrlOrgaoTransito (codOreao.numérico): caracter Retoma a URL do Órgão de Trânsito cujo código é "codOrgao".
A classe PlacaSolicitada é apresentada nas Tabelas 5.9 e 5.10, e está associada
ao Sistema do Órgão Conveniado, quando este órgão é municipal. Tabela 5.9 - Atributos da Classe PlacaSolicitada
Nome do Atributo Tipo Iam. Descrição placaVeiculo caracter 10 Placa do veículo a ser consultado codigoOrgaoTransitoSolicitante numérico 6 Código do órgão de trânsito que fez a solicitação dataXmlPlacas data - Dala recebida no documento xmlPlacas horaX ml Placas hora - Hora recebida no documento xmlPlacas statusPlaca caracter 1 Situação em que se encontra a pesquisa da placa:
Capitulo 5 - Modelo para Intercâmbio de Informações 63
A - aguardando; E - em andamento; P - processada
Nome da Operação Descrição incJuirPIacas (xmlPlacas: docXmJPIacas) Processa o documento xmlPlacas, recebido como parâmetro, e gera o documento
xmlConfinnaPlacas. Para cada placa contida em xmlPlacas, inclui um objeto na classe PlacaSolicitada, com o valor do atributo "statusPlaca" igual a "A" (aguardando pesquisa). Se não ocorrer problemas durante a inserção das placas, o código de retomo de xmlConfirmaPlacas será "CF" (confirmado). Os atributos dataXmlPlacas e horaXmlPlacas devem ser atualizados, conforme valores recebidos em xmlPlacas. No caso de ocorrer algum problema com o documento xmlPlacas, este documento não será processado e o código de retomo de xmlConfirmaPlacas será "NC".
extrairPlacas f ^ Recria os documentos xmlPlacas que deram origem aos objetos da classe PlacaSolicitada, cujas placas já tenham sido consultadas no Órgão Estadual. Para isso, as placas serão agrupadas por data e hora do xmlPlacas e pelo código do Órgão de Trânsito. Um documento xmlPlacas será gerado somente se todas as placas solicitadas, que apresentem os mesmos valores dos atributos dataXmlPlacas e horaXmlPlacas, possuírem statusPlaca igual a "P".
Na situação apresentada, o controle sobre a pesquisa da placa no órgão de
trânsito estadual é feito pelo atributo statusPlaca. Este atributo pode receber os valores:
"A" (aguardando processamento); "E" (enviadas para consultada); e "P" (consulta
processada). Ao ser criada uma nova instância da classe o valor do atributo statusPlaca
será "A". Quando a placa for selecionada para consulta no Órgão Estadual, o valor
deverá ser alterado para "E". Quando o resultado da pesquisa for retornado, o valor "P"
deverá ser atribuído para todas as placas pesquisadas. O procedimento que consulta
veículos no Órgão Estadual deverá manter estes status.
A classe InconsistenciaATT registra as inconsistências ligadas a determinado
AIT externo, encontradas durante o processamento de consistência. Ela possui uma
associação com a classe AÍTExterno, especificando que cada AIT externo pode conter
várias inconsistências, mas uma inconsistência refere-se a apenas um ATT externo.
As Tabelas 5.11 e 5.12 apresentam seus atributos e operações, respectivamente. Tabela 5 .11- Atributos da Classe InconsistenciaAIT
Nome do Atributo Tipo Tam. Descrição otimeroTipoInconsistencia numérico 3 Número do tipo de inconsistência conforme tabela do Apêndice B
Tabela 5.12 — Operações da Classe InconsistenciaAIT Nome da Operação Descrição
criarlnconststenciaAit (i: numérico; codigoOrgaoTransito:numérico; identificacaoAif.caracter)
Cria uma nova inconsistência (i) para um determinado ATT externo (codigoOrgaoTransito, identificacaoAit).
obterlnconsistenciaAit (codieoOrgaoTransitomuménco; identificacaoAit:caracteri
Retorna todas as inconsistências encontradas para o AIT identificado por codigoOrgaoTransito e identificacaoAit.
Esta classe está ligada ao Sistema do Órgão Conveniado, que realiza tal
consistência. Entretanto, poderá existir classe semelhante no Sistema do Órgão
Autuador. Neste caso, porém, a classe possuirá uma associação com a classe AIT.
A classe NTT está associada ao Sistema do Órgão Autuador. Ela corresponde ao
local onde serão armazenadas as NTT's recebidas do Sistema do Órgão Conveniado que
Capítulo 5 - Modelo para Intercâmbio de Informações 64
as gerou. Seus atributos e operação são apresentados nas Tabelas 5.13 e 5.14,
respectivamente Tabela 5.13 - Atributos da Classe NTT
Nome do Atribulo Tipo Tam. Descrição codigoOrgaoTransitoNit numérico 6 Código do órgão de trânsito que gerou a NTT numeroNit numérico 10 Número da NTT, dado pelo órgão de transito que a gerou d ala Geração data - Data de geração da NTT dataEmjssao data - Data de emissão da NIT dalaErjvio data - Data de envio da NTT ao infrator dataEntrega data - Data de entrega da NIT ao infrator dataPagamento data - Data de pagamento da NTT valorPago numérico 9,2 Valor pago em Reais dataXmlNit data - Data do último xmlNit que trouxe informações sobre a NIT horaXmlNit hora - Hora do último xmlNit que trouxe informações sobre a NTT
Existe um relacionamento entre a classe NIT e a classe AIT informando que
cada instância de NIT deverá estar associada a apenas uma instância de ATT e que cada
instância de AIT poderá não associar-se a qualquer instância de NIT ou associar-se a
uma ou mais instâncias de NTT.
Tabela 5.14 - Operações da Classe NIT Nome da Operação Descrição
reeistrarNit íxmTNh: docXmTNilí Insere os NTTs contidos no documento xmINít na classe NIT e gera o documento xmlReciboNit a partir daquelas NITs. Se não ocorrer problemas durante a inserção das NIT's, o código de retomo de xmlReciboNit será "CF" (confirmado). Os atributos dataXmlNit e horaXmlNit devem ser atualizados, conforme valores recebidos em xmINíL No caso de ocorrer algum problema com o documento xmlNit, este documento não será processado e o código de retomo de xmlReciboNit será "NC".
A classe NíTExterna está associada ao Sistema do Órgão Conveniado e
corresponde ao local onde serão armazenadas as NTT's geradas a partir dos AIT's
recebidos dos Sistemas dos Órgãos Autuadores.
Da mesma forma que entre AIT e NIT, existe um relacionamento entre a classe
NíTExterna e a classe AITExterno informando que cada instância de NíTExterna
deverá estar associada a apenas uma instância de AITExterno e que cada instância de
AITExterno poderá não associar-se a qualquer instância de NíTExterna ou associar-se a
uma ou mais instâncias de NíTExterna. Tabela 5.15 - Atributos da Classe NíTExterna
Nome do Atributo Tipo Tam. Descrição codi goOrgaoTransi toNi t numérico 6 Código do órgão de trânsito que gerou a NTT " numeroNit numérico 10 Número da NTT, dado pelo órgão de transito que a gerou da ta Geração data - Data de geração da NTT daiãEmissao data - Data de emissão da NTT dataEnvio data - Data de envio da NIT ao infrator data Entrega data - Data de entrega da NTT ao infrator dataPagamento data - Data de pagamento da NTT valorPago numérico 9,2 Valor pago em Reais dataXmlNit data - Data de geração do último xmlNit no qual a NTT está contida horaXmJNit hora - Hora de geração do último xmlNit no qual a NIT está contida situacaoNit caracter 2 Situação da NIT no que se refere ao envio para o órgão de Transito Autuador.
Valores válidos: PE - pendente; EN - enviada; CF - confirmada; NC - não confirmada
Tabela 5.16 - Operações da Classe NíTExterna Nome da Operação Descrição
criarNitExterna ( ) Cria uma nova NTT, gerando um novo numeroNit. Para cada NTT
Capítulo 5 - Modelo para Intercâmbio de Informações 65
externa criada é associado o valor "PE" ao atributo situacaoNit. emitirNitExtema í 1 Emite a NTT. Altera o valor do atributo situacaoNit das NITs emitidas
para "PE". obterNitsPendentes ( Ï Gera os documentos xmlNit, para cada órgão conveniado,
selecionando as NITs criadas a partir de ATT's destes órgãos e cujo valor do atributo situacaoNit seja igual a "PE". Esta operação, ainda, altera o valor do atributo situacaoNit das NTT's selecionadas para "EN" (enviada) e atualiza dataXmlNit e horaXmlNit.
remstrarReciboNit (xmlReciboNit: docXmlReciboNit) Atribui o valor do código de retomo do documento xmlReciboNit ao atributo situacaoNit de cada NIT cujo a data e a hora do documento xmlNit esteja especificada no documento xmlReciboNit. O valor do código de retomo do documento xmlReciboNit poderá ser "CF' (confirmada) ou "NC" (não confirmada).
A classe Recurso corresponde ao local onde estarão armazenados os recursos
interpostos contra as multas por infrações de trânsito relacionadas a AIT's que foram
enviados ou recebidos de outros órgãos de trânsito.
No diagrama de classe da Figura 5.18, foram especificadas duas subclasses para
a classe Recurso, As subclasses RecursoExterno e RecursoLocal correspondem à classe
Recurso ligada ao Sistema do Órgão Conveniado e ao Sistema do Órgão Autuador,
respectivamente.
No caso da subclasse RecursoLocal, são considerados apenas os recursos
relacionados aos ATT's que foram enviados para outros órgãos. No caso da subclasse
RecursoExterno, são considerados apenas os recursos relacionados aos AIT's que foram
recebidos de outros órgãos. Apesar disso, os atributos são idênticos, conforme
apresentado na Tabela 5.17. Tabela 5.17 - Atributos da Classe Recurso
Nome do Atributo Tipo Tam. Descrição codigoOrgaoTransitoInterposicao numérico 6 Código do Órgão de Transito onde foi interposto o recurso numeroRecurso numérico 11 Número do Recurso atribuído pelo Órgão de Trânsito onde foi
interposto o recurso data Interposição data Daia da interposição do recurso da ta Conclusão daca - Data da conclusão do recurso dataXmlRecurso data - Data de geração do xmí Recurso no qual o recurso está contido horaXmlRecurso hora - Hora de geração do xmlRecurso no qual o recurso está contido dataXmlResultadoRecurso data - Data de geração do xmlResultadoRecurso no qual o recurso está
contido horaXmlResultadoRecurso hora Hora de geração do xmlResultadoRecurso no qual o recurso está
contido situacaoRecurso caracter 2 Situação do recurso no que se refere ao envio para o Órgão de
Transito Autuador ou Conveniado. Valores válidos: NE - não enviado; EN — enviado; CF - confirmado; NC - não confirmado; RN - resultado não confirmado; RC - resultado confirmado. Este atributo deverá conter o valor "NE" quando o recurso for interposto e quando o resultado de conclusão do recurso for atualizado.
posicaoRecurso caracter 1 Posicionamento sobre o andamento do Recurso. Valores válidos: E - em andamento; C - concluído
resultadoRecurso caracter 1 Resultado do Recurso. Valores válidos: P - provido; N - não provido
A diferença está no fato da subclasse RecursoLocal estar associada à classe AIT
e a subclasse RecursoExterno estar associada à classe AITExterno e, ainda, de haver
algumas operações que são específicas a cada uma.
Capítulo 5 - Modelo para Intercâmbio de Informações 66
Algumas operações pertencem à classe Recurso e, portanto, são comuns às duas
subclasses. Essas operações são: registrarRecurso, obterRecursosNovos,
registrarRecursosExternos e registrarReciboRecurso.
Já as operações obterRecursoConcluido e registrarReciboResultadoRecurso são
específicas da subclasse RecursoLocal. Isso significa que elas estão ligadas apenas aos
Sistemas dos Órgãos Autuadores.
A operação registrarResultadoRecurso é específica da subclasse
RecursoExterno, estando, portanto, ligada apenas aos Sistemas dos Órgãos
Conveniados.
A Tabela 5.18 apresenta as operações da classe Recurso e de suas subclasses. Tabela 5.18 — Operações da Classe Recurso e de soas subclasses
Nume da Operação Descrição reeistrarRecurso Inclui um novo recurso. Gera um número para o recurso, informa a data de
interposição, assocía-o a um ATT e faz o valor do atributo posicaoRecurso ser igual a "E" e o valor do atribulo situacaoRecurso igual a "NE" .
obterRecursosNovosf 1 Gera os documentos xmlRecurso contendo todos os recursos interpostos e que ainda não foram enviados aos seus respectivos destinos (posicaoRecurso = "E" e situacaoRecurso = "NE"). Quando esta operação é executada pelos Sistemas dos Órgãos Conveniados, o destino dos documentos xmlRecurso são os Sistemas dos Órgão Autuadores e vice-versa. Esta operação altera o valor do atributo situacaoRecurso para "EN" (enviado) e atualiza dataXmlRecurso e horaXmlRecurso.
reeistrarRecursosEx ternos í xml Rec urs o: docX ml Rec urso)
Insere os recursos contidos no documento xmlRecurso em Recuso e gera o documento xmlReciboRecurso. Se não ocorrer problemas durante a inserção dos recursos, o código de retorno de xmlReciboRecurso será "CF - (confirmado). Os atributos dataXmlRecurso e horaXmlRecurso devem ser atualizados, conforme valores recebidos em xmlRecurso. 0 atributo situacaoRecurso deverá ser atualizado para conter o valor "CF' (confirmado). No caso de ocorrer algum problema com o documento xmlRecurso, este documento não será processado e o código de retomo de xmlReciboRecurso será **NC\
registrarReciboRecurso < xmiReciÍKjRecurso:docXmlRecÍboRecurso)
Atribui o valor do código de retomo do documento xmlReciboRecurso ao atributo situacaoRecurso de cada recurso cujo a data e a hora do documento xmlRecurso estejam especificadas no documento xmlReciboRecurso. 0 valor do código de retomo do documento xmlReciboRecurso poderá ser "CF' (confirmado) ou "NC" (não confirmado).
obterRecursoConcluidof> Gera os documentos xmJResultadoRecurso contendo todos os recursos concluídos e que ainda não foram enviados aos seus respectivos destinos (posicaoRecurso = "C" e situacaoRecurso = "NE"). Esta operação é executada pelos Sistemas dos Órgãos Autuadores e o destino dos documentos xmlResultadoRecurso são os Sistemas dos Órgão Conveniados. Ela altera o valor do atributo situacaoRecurso para "EN" (enviado) e atualiza dataXmlResu ItadoRec urso e horaXmlResultadoRecurso.
reeistrarResuttadoRecurso fxmlResultadoRecurso:
docXrrü ResultarloR ecurso)
Esta operação é realizada pelo Sistema do Órgão Conveniado. Ela atualiza, na classe Recurso, os recursos contidos no documento xmlResultadoRecurso e gera o documento xmlReciboResultadoRecurso. Se não ocorrer problemas durante a inserção dos recursos, o código de retomo de xmlReciboResultadoRecurso será "ítC", Os atributos resuíladoJieeurso, posicaoRecurso, daíaXmJfíesuJladoReciirso e horaXmlResultadoRecurso devem ser atualizados, conforme valores recebidos em xml Resu ItadoRec urso. O atributo situacaoRecurso deverá ser atualizado para "RC (resultado confirmado). No caso de ocorrer algum problema com o documento xmíResuItadoRecurso, este documento não será processado e o código de retorno de xmlReciboResultadoRecurso será "RN".
reei strarReciboResu ItadoRecurso txmlReciboResii ltadoRecurso: docXmlReciboResultadoRecurso)
Atribui o valor do código de retorno do documento xmlReciboResultadoRecurso ao atributo situacaoRecurso de cada recurso cujo a data e a hora do documento xmlResultadoRecurso estejam especificadas no documento xmlReciboResultadoRecurso. O valor do código de retomo do documento xmlReciboResultadoRecurso poderá ser "RC" (resultado confirmado) ou "RN" (resultado não confirmado!.
Capítulo 5 - Modelo para Intercâmbio de Informações 67
5.8 - Documentos X M L
Há dois tipos de documentos XML definidos por este modelo. Um corresponde
aos documentos de dados que contêm informações sobre AU, NIT, recursos etc. Outro
corresponde ao documento que será utilizado como "envelope" para os demais,
chamaremos este documento de pacote de transmissão.
5.8.1 - Definição da Linguagem de Esquema XML
Para representarmos a estrutura de um documento XML podemos utilizar uma
linguagem de esquema XML.
A respeito de um esquema XML, Fallside, organizador da Recomendação W3C
"Xml Schema Part 0: Primer" [FALL01], afirma o seguinte:
"O propósito de um esquema é definir uma classe de documentos XML e, com
isso, o termo "documento instância" é freqüentemente usado para descrever um
documento XML que esteja de acordo com um particular esquema. De fato, nem
as instâncias nem os esquemas necessitam existir como documento per se — eles
podem existir como streams de bytes enviados entre aplicações, como campos
em um registro de banco de dados ou como coleções de "Ltens de Informação"
deXMLInfoset..." [FALL01]
David Carlson [CARL01] apresenta as duas linguagens de esquema definidas
pelo W3C, que são a DTD Document Type Definition) [BRAYOO] e a XML Schema
[FALL01, THOM01, BIRO01]. A respeito delas o autor descreve:
"A Document Type Definition (DTD) é a linguagem de esquema original
incluída na especificação XML LO. Entretanto, muitas pessoas reconheceram as
limitações desse padrão DTD para suportar intercâmbio de dados em
aplicações globais de e-business. A nova proposta de esquema estende as
capacidades para validação de documentos e intercâmbio de informação com
outros componentes de sistema não XML. " [CARL01]
Devido ao fato da DTD disponibilizar um suporte muito limitado a tipos de
dados para valores de atributos e não suportar tipos de dados para o conteúdo texto de
um elemento, utilizaremos a XML Schema para representar os documentos XML desse
trabalho.
Capítulo 5 - Modeto para Intercâmbio de Informações 68
Reforçando a escolha pela XML Schema, podemos apresentar algumas de suas
características chave, citadas por Carlson [CARL01], que ajudam a cobrir as limitações
das DTD's e que são especialmente importantes para a análise orientada a objetos e a
modelagem de vocabulários com a UML:
• XML Schemas são instâncias de documentos XML, o que facilita sua criação e
manipulação;
• possui tipos de dados e permite refinamento de tipos de dados;
• permite extensão de tipos de elementos (herança);
• declara elementos com escopo local;
• o modelo de conteúdo pode ser desordenado, ou seja, possibilita que os elementos
apareçam em um documento instância em qualquer ordem;
• suporta XML Namespace.
A XML Schema foi aprovada como uma Recomendação W3C (W3C
Recommendation) em 2 de maio de 2001 e é especificada pelos documentos "XML
Schema Part 1: Structures" [THOM01] e 'XML Schema Part2 : Datatypes" [BIRO01].
Além desses, há um documento não normativo chamado 'XML Schema PartO : Primer"
[FALL01] que apresenta um visão global da especificação.
Definida a linguagem de esquema que será utilizada, as próximas seções
apresentam a estruturação dos documentos.
5.8.2 - Documentos de Dados
Os documentos de dados são aqueles referenciados nos diagramas de seqüência
das seções 5.3 a 5.6. Cada um deles contêm as informações que deverão ser trocadas
entre os sistemas dos diversos órgãos e, para serem transmitidos, deverão estar
embutidos em um pacote de transmissão, especificado na próxima seção.
Esses documentos possuem vários elementos e atributos derivados das classes
definidas na seção 5.7.
O Apêndice C apresenta o XML Schema que define os documentos utilizados
para conter os dados que serão intercambiados entre os sistemas conveniados.
Primeiramente, foram criados um namespace - prefixo "mit" - e um target
namespace fictícios para o modelo, ambos apontando para a URI
"http://www.miiit.gov.br/MIIIT". Consideramos que este esquema estará armazenado
no arquivo MIUT.xsd (a extensão .xsd significa XML Schema Definition). MIUT é a
Capítulo 5 - Modelo para Intercâmbio de Informações 69
abreviatura de "Modelo de Intercâmbio de Informações relacionadas a Infrações de
Trânsito".
Cada documento definido pelo modelo foi declarado como um elemento global
do esquema MIUT.xsd. Cada um desses elementos é de um tipo complexo que define a
estrutura de um determinado documento.
Para cada tipo complexo relacionado aos documentos xmlPlacas, xmlVeiculos,
xmlAit, xmlAitConsistido, xmlNit, xmlRecurso e xmlResultadoRecurso, foi declarado
um elemento principal que poderá ser repetido várias vezes dentro de um mesmo
documento, como por exemplo, o elemento "ait" do "TipoXmlAit" ou o elemento
"recurso" do "TipoXmlRecurso". Os elementos filhos do complexType que define
estes elementos principais foram derivados das classes Veiculo, ATT, AITExterno,
InconsistenciaAIT, NIT, NITExterna e Recurso. Os atributos pertencentes a estas
classes, cujos valores deverão ser transferidos, durante a troca de informações de
infrações de trânsito, para os sistemas de outros órgãos de trânsito através de um
determinado documento, foram transformados nos elementos filhos do complexType que define o elemento principal deste documento.
Como exemplo, podemos verificar o caso do complexType "TipoXmlNit",
que está relacionado ao documento xmlNit. Neste caso, o elemento principal chama-se
"nit". Este elemento é declarado de forma que um documento xmlNit possa ter em seu
conteúdo vários elementos "nit". Os elementos "codigoOrgaoTransitoNit",
"numeroNit", "dataGeracao", "dataEmissao", "dataEnvio", "dataEntrega",
"dataPagamento" e "valorPagamento", definidos como filhos do elemento "nit", foram
derivados dos atributos da classe NIT que possuem o mesmo nome.
Alguns elementos não são obrigatórios. Nesse caso, o atributo minOccurs possui o valor "0" (zero). Outros elementos podem aparecer várias vezes, o que é
especificado pelo valor "unboundecl" do atributo maxOccurs. No caso do elemento não apresentar nenhum dos atributos minOccurs ou
maxOccurs, significa que o elemento é obrigatório. Em outras palavras, o valor
default para minOccurs e para maxOccurs é " 1 " .
Os tipos complexos dos documentos xmlNit, xmlRecurso, xmlResultadoRecurso
contêm os elementos "codigoOrgaoTransitoAit" e "identificacaoAit". Isso se deve ao
relacionamento das classes NIT, NITExterna e Recurso, nas quais aqueles documentos
Capítulo 5 - Modelo para Intercâmbio de Informações 70
estão baseados, com as classes ATT e AITExterno, conforme mostra o diagrama de
classes da Figura 5.18.
A classe InconsistenciaAJT é contemplada no documento xmlAitConsistido. Ela
surge como um elemento de tipo complexo, "inconsistenciasAit", interno ao elemento
"ait" de "TipoXmlAitConsistido".
Os documentos xmlConfirmaPlacas, xmlReciboAit, xirilAitReciboConsistido,
xmlReciboNit, xmlReciboRecurso, xmlReciboResultadoRecurso correspondem aos
documentos que confirmam o recebimento de um determinado elemento. Eles possuem
os elementos data e hora dos documentos que os originou além do código de retorno
que foi definido na seção 5.7. O código de retorno possui valores preestabelecidos que
são definidos a partir de uma enumeração ( enumera t ion ) .
Todos os tipos complexos que definem os documentos possuem o grupo de
atributos (attributeGroup) "IdDocumento", que contém os atributos obrigatórios,
data e hora. Esses atributos, juntamente com a identificação do órgão emissor,
identificam o documento de forma única. A identificação do órgão emissor será definida
na seção que trata do pacote de transmissão.
Vale observar que os modelos de conteúdo dos documentos correspondem a
seqüências (sequence), ou seja, os elementos e seus respectivos valores devem ser
apresentados em um documento instância XML na mesma ordem em que estão
especificados no esquema.
Finalmente, são declarados os tipos UFBrasil, que corresponde às siglas dos
Estados brasileiros, e UnidadeMedida, que é utilizado para definir a unidade de medida
do equipamento de aferição especificado no AIT.
5.8.3 - Pacote de Transmissão
A seção 5.7 definiu o comportamento das operações de todas as classes
referenciadas nos diagramas de seqüência das seções 5.3 a 5.6. Tais operações
correspondem às mensagens enviadas entre os objetos de cada diagrama. Contudo, as
mensagens associadas ao envio dos documentos não foram especificadas.
Os documentos, ou as estruturas, nos quais estarão incorporados os dados
relacionados às infrações de trânsito, foram definidos na seção anterior. Para que estes
documentos sejam enviados, eles serão envolvidos por uma estrutura externa que
funcionará como um envelope. Neste envelope, chamado aqui de pacote de transmissão,
Capítulo 5 - Modelo para Intercâmbio de Informações 71
estarão informações a respeito do destino e da origem dos dados, do método a ser
utilizado para processar a informação, além do documento propriamente dito.
Esta seção define o pacote de transmissão que englobará todas aquelas
mensagens dos diagramas de seqüência que estão relacionadas ao envio de documentos.
O pacote de transmissão possui uma estrutura semelhante à definida pela
especificação do protocolo SOAP versão 1.2 [MITR01, GUDGOla, GUDGOlb]. Este
protocolo é baseado em XML e se encontra em processo de desenvolvimento pelo
W3C. Segundo Gudgin et alli [GUDGOla], "SOAP versão 1.2 disponibiüza um
mecanismo simples e leve, em XML, para a troca de informações, estruturadas e
tipificadas, entre pontos em um ambiente descentralizado e distribuído."
O protocolo SOAP define a estrutura da Mensagem SOAP, quem deverá tratar
tal mensagem e apresenta um mecanismo para chamada remota de procedimentos (RPC,
Remote Procedure Cali).
Uma mensagem SOAP é composta por um elemento envelope (Envelope) contendo dois sub-elementos: um elemento cabeçalho (Header), opcional; e um
elemento corpo (Body), obrigatório. O conteúdo desses sub-elementos são definidos
pela aplicação e não como parte da especificação SOAP, embora, sobre os sub-
elementos de Header, SOAP determina como eles devem ser manipulados.
Os elementos que são filhos diretos de um Header são chamados de blocos
cabeçalho (header blocks), e representam algum grupo lógico de dados que pode ser
direcionado a um nó SOAP encontrado no caminho de uma mensagem enviada de um
remetente para um receptor. Da mesma maneira, os elementos que são filhos diretos de
um Body são chamados de blocos corpo (body blocks) que são especificados pela
aplicação.
A Figura 5.20 ilustra a composição de uma mensagem SOAP: SOAP Envelope
j SOAP Header I S O A P Header Black
* *
S O A P Header Black
I SOAP Body ~~I S O A P B o d y B i c d
«
S O A P B a d y Black
Figura 5.20 - Composição da Mensagem SOAP
O formato XML de uma mensagem SOAP é mostrado na Listagem 5.1.
Capítulo 5 - Modelo para Intercâmbio de Informações 72
<?xml version="1.0" ?> <env:Element xmlns:env="http://www.w3c.org/2001/12/soap-envelop"> <env:Header>
<!-- Acjui sao definidos os header blocks-->
</env;Header> <env:Body> <!-- ACfai sao definidos os body blocks-->
</env:Body> </env:Element>
Listagem 5.1 - Estrutura XML da Mensagem SOAP
O namespace de nome "http://www.w3c.org/2001/12/soap-envelop" e prefixo
"env", apresentado junto ao elemento Enve lope da Listagem 5.1, corresponde ao
namespace SOAP definido pelo W3C.
Baseado na estrutura da mensagem SOAP foi criado o pacote de transmissão,
porém, neste caso, o elemento Header não é opcional. A Figura 5.21 mostra a
composição do pacote de transmissão.
Envelope
I Header I DESTINO
ORIGEM
d ata Envi o hora Envi o
Body operação
Bloco Método
Bloco Parâmetro
• • • operação
Bloco Método Bloco Parâmetro
Figura 5.21 - Composição do Pacote de Transmissão
Os elementos "destino", "origem", "dataEnvio" e "horaEnvio" correspondem
aos header blocks do protocolo SOAP. O elemento "operação" corresponde ao body
block.
Capítulo 5 - Modelo para Intercâmbio de Informações 73
O conteúdo dos elementos "destino" e "origem" especificam o código e a URL
dos respectivos órgãos de tránsito. Tais elementos são derivados dos atributos da classe
OrgaoTransito.
Compondo o elemento "operação" temos dois blocos chamados de "Bloco
Método" e "Bloco Parâmetro". O "Bloco Método" refere-se ao método, no sistema do
órgão de transito destino, que deverá processar determinado documento XML. Já o
"Bloco Parâmetro" corresponde a um dos documentos XML, definido pelo esquema
Mnrr.xsd. Os elementos que constituem o "Bloco Método" foram definidos a partir das
operações, referenciadas nos diagramas de seqüência das seções 5.3 a 5.6. Somente
aquelas operações que processam os documentos XML após sua recepção foram
definidas como elementos. Estes elementos são:
• obterVeiculos: processa o documento xmlPlacas;
• registrarUfVeiculos: processa o documentos xmlVeiculos;
• incluirPlacas: processa o documento xmlPlacas;
• registrarConfirmacaoPlacas: processa o documento xmlConfirmaPlacas;
• carregarAitExterno: processa o documento xmlAit;
• registrarReciboAit: processa o documento xnúReciboAit;
• registrarAitConsistido: processa o documento xmlAitConsistido;
• registrarReciboAitConsistido: processa o documento xmlReciboAitConsistido;
• registrarNit: processa o documento xmlNit;
• registrarReciboNit: processa o documento xmlReciboNit;
• registrarRecursosExternos: processa o documento xmlRecurso;
• registrarReciboRecurso: processa o documento xmlReciboRecurso;
• registrarResultadoRecurso: processa o documento xmlResultadoRecurso;
• registrarReciboResultadoRecurso: processa o documento
xmlReciboResultadoRecurso.
Cada um desses elementos corresponde a uma chamada remota ao método que
esta sendo referenciado por ele, cujo parâmetro é o documento que faz parte de seu
conteúdo.
A Listagem 5.2, apresenta um exemplo de um pacote de transmissão solicitando
o processamento do documento xmlPlacas no Sistema do Órgão Central pelo método
"obterVeiculos", como mostrado no diagrama de seqüência da Figura 5.4.
Capítulo 5 - Modelo para Intercâmbio de Informações 74
<?xml versión-"1.O" ?>
<pct:Envelope xmlns:pct-"http://www.miiit.gov.br/PacoteMIIIT" xmlns:mit-"http://www. miiit.gov.br/MIIIT">
<pct:Header> <pct:destino> <pct:codigoOrgaoTransitoDestino>1234</pct:codigoOrgaoTransitoDestino <pct:urlOrgaoTransitoDestino> http://www.orgaoorigem.gov.br
</pct:urlOrgaoTransitoDestino> </pct:destino> <pct:origem> <pct:codigoOrgaoTransitoOrigem>4321</pct:codigoOrgaoTransitoOrigem> <pct:urlOrgaoTransitoOrigem> http://www.orgaoorigem.gov.br
</pct:urlOrgaoTransitoOrigem> </pct:origem> <pct:dataEnvio>2002-02-20</pct:dataEnvio> <pct:horaEnvio>10:01:00</pct:horaEnvio>
</pct:Header> <pct:Body> <!-- Bloco Método --> <pct:operacao> <pct;obterVeiculos> <!-- Bloco Parâmetro <mit;docXmlPlacas data= H2002-02-20" hora="10:10:02"> <placa>ABC12 34</placa> <placa>BCD432I</placa> <placa>CCC0987</placa> <placa>DCB7 890</placa>
</mit:docXmlPlacas> < ! — Fim do Bloco Parâmetro -->
</pct:obterVeiculos> </pct:operação
Fim do Bloco Método --> </pct:Body>
</pct;Envelope>
Listagem 5.2 - Exemplo de pacote de transmissão contendo o documento xmIPIacas
Os prefixos "pct" e "mit" e os seus respectivos namespaces correspondem aos
esquemas que definem o pacote de transmissão e os documentos de dados.
O Apêndice D, apresenta o XML Schema que especifica o pacote de
transmissão. Este esquema permite que vários elementos o p e r a ç ã o sejam incluídos
no corpo do pacote de transmissão, possibilitando que vários documentos sejam
enviados no mesmo pacote de transmissão.
Capítulo 5 - Modelo para Intercâmbio de Informações 75
6 - Arquitetura e Protótipo
6.1 - Introdução
Este capítulo trata das visões de implementação e implantação do modelo
especificado no capítulo 5.
Segundo a UML, "a visão de implementação de um sistema abrange os
componentes e os arquivos utilizados para a montagem e fornecimento do sistema
físico." [BOOC00] Os aspectos estáticos dessa visão são capturados pelos diagramas de
componentes.
Em relação à visão de implantação, a UML define que ela "abrange os nós que
formam a topologia de hardware em que o sistema é executado. Essa visão direciona
principalmente a distribuição, o fornecimento e a instalação das partes que constituem o
sistema físico."[BOOC00] Os diagramas de implantação são utilizados para representar
os aspectos estáticos dessa visão.
Sendo assim, este capítulo apresenta os componentes de software que deverão
existir em cada Órgão de Trânsito para a implantação do modelo de troca de
informações de infrações de trânsito, especificado no capítulo 5, bem como uma
possível arquitetura na qual este componentes estarão instalados.
Além disso, serão descritas as decisões tomadas no desenvolvimento de um
protótipo que implementa o processo de identificação do veículo no Órgão Central e
parte do processo de troca de informações de AIT.
6.2 - Diagrama de Implantação e Diagrama de Componentes
Os dois tipos de diagramas disponíveis na UML utilizados para a modelagem
dos aspectos físicos de um sistema são os diagramas de componentes e os diagramas de
implantação.
Um diagrama de componente mostra um conjunto de componentes e seus
relacionamentos, ou seja, a organização e as dependências existentes entre eles. Um
componente é uma parte física e substituível do sistema ao qual se adapta e fornece a
realização de um conjunto de interfaces. [BOOC00]
Capítulo 6 - Arquitetura e Protótipo 76
Já o diagrama de implantação mostra a configuração dos nós de processamento
em tempo de execução e os componentes que nele existem. Um nó é um elemento físico
que existe em tempo de execução e representa um recurso computacional, geralmente
tendo pelo menos alguma memória e, com freqüência, capacidade de processamento.
[BOOC00]
A Figura 6.1 mostra o diagrama de implantação para o modelo proposto para o
intercâmbio de informações de infrações de trânsito.
5*v»tof HTTP '
-Pft íe* UM.
1
-S í i v l d c HTTP
taipfeimrta
' S o U w y e S f f t W J T Í P ]
*auq-iniwaOJtoup(*a ]
• P » s e r XM_ 'Onvpr p a s o S £ C Ü ^
E letal d? L*íi mgao i)e n
„
S ? ™ * v HTTP « BO
'Hug-í.paca £ d o u p * a
1 - ' i K í w O ' t i - ' f H í e t c a i d e n D órgáe « T i a n s i o e s t a d u a l
Figura 6.t - Diagrama de Implantação
O diagrama apresenta os nós que constituirão o ambiente dos órgãos de trânsito
e os tipos de componentes que estarão incluídos neles. Cada par Servidor HTTP /
Servidor de Banco de Dados (BD) representa o ambiente de um determinado Órgão de
Trânsito - seja ele Municipal, Estadual ou Nacional - para o processamento, envio e
recebimento dos documentos XML.
Como mostrado pelo diagrama, independentemente da localização dos
servidores, os componentes básicos que compõem cada um pertencem às mesmas
categorias.
Nos servidores HTTP estão colocados:
• um software servidor HTTP, com suporte a algum mecanismo CGI (como Servlet
Java, CGI Perl, DLL ISAPI, DLL NSAPI etc.) ou a algum mecanismo de Sever
Pages (como ASP ou JSP);
• um plug-in CGI ou um plug-in para Server Pages, que será necessário caso a
tecnologia utilizada para o desenvolvimento da aplicação não seja suportada,
originalmente, pelo software servidor HTTP;
CAPÍTULO 6 - ARQUITETURA E PROTÓTIPO 77
• um parser XML, que poderá ser obtido através de alguma solução já disponível
comercialmente ou de uma solução disponível gratuitamente na Internet ou, ainda,
que poderá ser criado pela equipe de desenvolvimento de softwares do Órgão de
Trânsito;
• um driver que fará a conexão com o banco de dados, tal como ODBC ou JDBC;
• e, finalmente, a própria aplicação, desenvolvida em uma linguagem de programção
que permita sua interação com o servidor Web e que implementará as operações
definidas pelo modelo para enviar, receber e processar os documentos XML.
No servidor de BD, foi incluído o componente SGBD, que deverá conter as
tabelas que serão utilizadas para armazenar os dados que farão parte dos documentos
XML e que alimentarão o sistema do órgão de trânsito. Essas tabelas refletirão os
atributos das classes especificadas no capítulo 5.
Apesar do SGBD e dos demais componentes estarem em nós distintos, ou seja,
em máquinas diferentes, isso pode não ocorrer. O SGBD utilizado pela aplicação poderá
estar na mesma máquina que implementa o servidor HTTP. Da mesmo forma, a
aplicação poderá estar localizada em uma máquina diferente daquela onde está o
software servidor de HTTP. Questões relacionadas à segurança e performance, que não
serão tratadas neste trabalho, devem ser levadas em consideração para decidir qual
estratégia de implementação deve ser seguida em cada órgão.
Os relacionamentos entre os componentes internos aos nós são mostrados no
diagrama de componentes da Figura 6.2. Esse diagrama representa as relações de
dependência entre os componentes.
servidoi HTTP
plug-in CGI ou
plug-in Serve*
1 aplicação Web 1 driver BD aplicação Web
1 !
I — , — , — 1
parser XML
SGBD
Figura 6.2 - Diagrama de Componentes
Capítulo 6 - Arquitetura e Prototipo 78
As subseções seguintes descrevem cada componente especificado no diagrama
da Figura 6.2 e apresentam as tecnologias utilizadas para o desenvolvimento do
protótipo.
6.2.1 — Aplicação Web
O componente aplicação Web do diagrama da Figura 6.2 corresponde aos
programas desenvolvidos para:
• processar os documentos XML recebidos; acessar o banco de dados do órgão de
trânsito para incluir, alterar ou pesquisar informações relacionadas àqueles
documentos; e enviar a resposta de tal processamento ao órgão solicitante;
• e extrair os dados do banco de dados; produzir os documentos XML adequados para
a operação que deseja realizar; enviar tal documento para o destino; e processar a
resposta.
Esta aplicação deverá ser desenvolvida em uma linguagem de programação que
possua alguma interação com o software servidor HTTP e com o SGBD que está sendo
utilizado. Além disso, o parser utilizado para analisar os documentos XML deve ser
compatível com a tecnologia utilizada para o desenvolvimento dessa aplicação.
O protótipo deste trabalho foi escrito na linguagem Java 2, utilizando a
tecnologia Java Servlets. Para compilar os programas e testar a sua funcionalidade
utilizou-se os programas e as classes do Java 2 Software Deveíopment Kit, Standard
Edition, Version 1.3.1 (SDK 1.3.1) e as classes de suporte a servlets do Tomcat 4.
Os servlets consistem em aplicativos que são executados em um servidor
conectado à Web. Eles tem o mesmo objetivo dos programas (scripts) que utilizam a
Common Gateway interface (CGI), ou seja, enviar e receber informações através de um
servidor Web.
Uma diferença marcante entre um script CGI e um servlet Java é o fato de que
para cada requisição a um mesmo script CGI é criado um novo processo no servidor. Já
no caso dos servlets Java, é criado um novo processo apenas na primeira vez que a
classe é chamada. Cada requisição de usuário é tratada por threads, que podem ser
vistos como subdivisões dentro de um mesmo processo. Isso melhora a performance de
um servlet em relação a um script CGI.
Os servlets, entretanto, precisam ser interpretados na máquina servidora, por
isso, é necessária a instalação de um interpretador de servlets, também conhecido como
Capítulo 6 - Arquitetura e Protótipo 79
mecanismo de servlet (ou, ainda, servlets container). O interpretador de servíeis
utilizado para implementação do protótipo foi o Tomcat 4.
O Tomcat 4 é um servidor de aplicação Java que implementa os mecanismos
Servlets 2.3 e JavaServer Pages 1.2. Ele é um software gratuito, com código fonte
aberto, e pode ser obtido a partir do endereço da Web, "jakarta.apache.org".
servidor HTTP
1 apleaçáo W e b Java
1 1
driver BD
.A. plug-jri CGI
ou plug-r Server
Page
mecanismo de servlet
(Tomcat 4)
parser XML
SG8D
Figura 6.3 — Diagrama de Componentes utilizando o Tomcat
A respeito do Tomcat, Lemay e Cadenhead, explicam que:
"O Tomcat inclui duas bibliotecas de classe Java, javax.servlet e
javax.servlet.http, e software que inclui funcionalidade de servlet no servidor da
Web Apache. Também existe um interpretador de servlets que pode ser usado
para testá-los antes de distribuí-los na Web. " [LEMA01]
Este mecanismo de servlet não está representado no diagrama de componentes
da Figura 6.2. Ele surgiria como um novo componente, como mostra a Figura 6.3.
6.2.2 - Driver para o BD
Com relação ao acesso a banco de dados, caso a tecnologia utilizada para
desenvolver a aplicação não possua suporte nativo para este acesso, será necessária a
utilização de um driver. Nesse sentido, podemos citar os drivers baseados em ODBC e
os baseados em JDBC.
A ODBC (Open Database Connectivity) é a especificação de uma API
(Application Programming Interface) para acesso a banco de dados, desenvolvida pela
Microsoft Corporation. Como referenciado pelo ODBC Programmers Reference da
Microsoft [MICR01], "essa API é independente de qualquer SGBD ou sistema
Capítulo 6 - Arquitetura e Protótipo 80
operacional". Ela usa a linguagem SQL (Structured Query Language) [ELMAOO] como
sua linguagem de acesso ao banco dados.
As funções da API ODBC são implementadas em módulos específicos para cada
SGBD. Esses módulos são chamados de drivers. As aplicações chamam as funções
desses drivers para acessar os dados de uma maneira única, independente da estrutura
interna do SGBD. Assim, o uso de drivers isola a aplicação das chamadas específicas de
um determinado banco de dados. Pelo fato dos drivers serem carregados em tempo de
execução, para acessar um novo SGBD, um usuário precisa apenas adicionar um novo
driver em seu ambiente, não sendo necessário recompilar a aplicação. Um Driver
Manager gerencia a comunicação entre as aplicações e os drivers.
Já a tecnologia JDBC [SUN02b] é uma API que permite o acesso a qualquer
fonte de dados tabular pela linguagem de programação Java. Elsmari e Navathe
apresentam a JDBC como "um conjunto de classes Java desenvolvidas pela Sun
Microsystems para permitir acesso a banco de dados relacionais através da execução de
sentenças SQL" [ELMAOO]. Além disso, os autores esclarecem que JDBC não é um
acrônimo de "Java Database Connectivity", como muitos acreditam, e sim um nome
registrado pela Sun.
Utilizando o JDBC é possível estabelecer uma conexão com a um banco de
dados, enviar comandos SQL e recuperar o resultado de uma consulta usando as classes
Java Connection, Statement e ResultSet, respectivamente.
Da mesma forma que a API ODBC, existem drivers JDBC específicos para cada
banco de dados. Conforme documentação fornecida pela Sun [SUN99], esses drivers
podem ser dos seguintes tipos:
• JDBC-ODBC Bridge mais ODBC driver: é um driver que implementa as operações
JDBC traduzindo-as para operações ODBC. Para a ODBC este driver se apresenta
como uma aplicação normal. Esse tipo de driver é mais apropriado em uma rede
corporativa onde instalações clientes não são um grande problema, ou para código
de servidores de aplicação escrito em Java para uma arquitetura de três camadas
(three-tier).
• Native-API partly-Java driver: esse tipo de driver converte chamadas JDBC em
chamadas na API de cliente para Oracle, Sybase, Informix, LBM, DB2 ou outro
SGBD. Note que, como o bridge driver, esse estilo de driver requer que algum
código binário específico do sistema operacional seja carregado em cada máquina
cliente.
Capítulo 6 - Arquitetura e Protótipo 81
• JDBC-Net pure Java driver: esse driver traduz chamadas JDBC em protocolo de
rede independente do SGBD, que é então convertido para um protocolo do SGBD
por um servidor. Esse servidor de rede intermediário está habilitado para conectar
seus clientes Java a diversos banco de dados diferentes.
• Native-protocol pure Java: Este tipo de driver converte chamadas JDBC
diretamente no protocolo de rede usado pelo SGBD. Isso permite uma chamada
direta da máquina cliente para o servidor do SGBD e é uma excelente solução para
acesso via intranet.
Para o desenvolvimento do protótipo utilizamos a ponte JDBC-ODBC (JDBC-
ODBC Bridge) para conectar em um banco MS Access. Neste banco foram criadas as
tabelas que serão utilizadas pelo protótipo.
6.2.3 - Parser XML
Segundo Benoît Marchai [MACHOO], um parser é a ferramenta XML na qual
todo aplicativo XML está baseado. Ele é um componente de software residente entre o
aplicativo e os documentos XML e seu objetivo é decodificar estes documentos para
que possam ser utilizados em uma aplicação, ocultando do desenvolvedor os detalhes da
sintaxe XML.
Para executar sua função, geralmente, um parser implementa API's padrão que
permitem acessar o conteúdo dos documentos XML. As API's mais utilizadas são: a
DOM (Document Object Model) e a SAX (Simple API for XML).
A API DOM, que corresponde a uma Recomendação do W3C [HORS00], é
baseada em objetos ou, como definido por Megginson [MEGGOO], baseada em árvore.
Toda informação armazenada em um documento XML é tratada como um objeto que
instancia uma classe definida pelo DOM. Ao 1er um documento XML, um parser que
implementa a API DOM armazena, na memória do computador, cada informação
daquele documento como uma árvore hierárquica. Os nós desta arvore representam os
elementos, atributos, entidades, valores de conteúdo e comentários do documento lido.
A partir disso, uma aplicação poderá percorrer a árvore gerada para extrair as
informações que necessitar processar.
Benoît Marchai [MACHOO] apresenta a hierarquia de classes DOM como
mostrado na Figura 6.4.
Capítulo 6 - Arquitetura e Protótipo 82
Comment
Node
Attr
ChsracterData
Document
Text CD A T A Section
Comment
DocumentFragment
D o c u m e n t T y p e
Element
Entity
EntityReference
Notation
P r o c e s s i n g l n s t r i K i i o n
NodeList
NameclNodeMap
DOMIiTiptementation
DOMException
Figura 6.4 - Hierarquia DOM
Na especificação do DOM Levei 2 [HORS00] são apresentados cada tipo de nós
(Nodes) e quais tipos de nós podem ser seus filhos. A tabela 6.1 mostra esta relação.
Tipo do \ 6 iSode) Filhos Document Element (máximo de um), Processinglntruction, Comment, DocumentType (máximo de um) DocumentFragment Element, Processinglnstruction, Comment, Text, CDATASection, EntityReference DocumentType Sem filhos EntityReference Element. Processinglnstruction, Comment, Text, CDATASection, EntityReference Element Element, Processinglnstruction, Comment, Text, CDATASection, EntityReference Attr Text. EntityReference Proces sing In struc ti on se m filhos Comment sem filhos Text sem filhos CDATASection sem filhos Entity Element, Processingmstruction, Comment, Text, CDATASection, EntityReference Notation sem fithos
Ainda existem os objetos NodeList para manipular listas ordenadas de nós, e os
objetos NamedNodeMap que manipulam conjuntos desordenados de nós, referenciados
por seu nome de atributo.
A outra API, a SAX [MEGGOO, BROW02], desenvolvida pelos membros da
lista de correspondência XML-DEV, é baseada em eventos. Como explica Marchai;
"SAX foi editada por David Megginson e publicada em
www.megginson.com/SAX. Ao contrário de DOM, ela não é endossada por uma
agência oficial de padrões, mas é bastante usada e é considerada um padrão de
fato. " [MACHOO]
Capítulo 6 - Arquitetura e Protótipo 83
Atualmente, o website oficial para SAX está localizado no endereço
"sax.sourceforge.net" [BROW02], em substituição ao "www.megginson.com/SAX"
[MEGGOO], e é mantido por David BrownelL
Uma API baseada em eventos, segundo Megginson [MEGGOO], informa os
eventos (tais como o início ou o final de um elemento) diretamente para a aplicação
através de callbacks. Isso ocorre durante a análise (parsing) do documento, ao contrário
de uma API baseada em árvore, como o DOM, que só depois de ter armazenado todo o
documento na estrutura da árvore permite que a aplicação caminhe por ele.
Segundo Marchai [MACHOO], o comportamento dos eventos é o seguinte:
"Os eventos avisam à aplicação de que algo aconteceu e ela, então, pode
reagir. As aplicações registram manipuladores de eventos, que são Junções para
processar os eventos.
(...) Existem eventos para:
• tags de abertura de elemento;
• tags de fechamento de elemento;
• conteúdo de elementos;
• entidades;
• erros de analise. " [MACHOO]
Outra característica de um parser XML é o fato deles suportarem validação ou
não. Para entendermos esta caraterística, é importante conhecermos os conceitos de
"documento XML bem formado" e "documento XML válido".
Um documento XML bem formado é aquele que respeita as regras básicas da
XML tais como:
• obrigatoriedade de tags de início e de fim dos elementos - menos para elemento que
não possui conteúdo (elemento vazio), nesse caso, a tag deverá terminar com "/>";
• os nomes de elementos, atributos, entidades etc., devem iniciar com uma letra ou
com um caracter de sublinhado(_);
• não podem existir espaços nos nomes de elementos, atributos, entidades etc;
• deve haver apenas um elemento raiz.
Já um documento válido é um documento bem formado que esteja de acordo
com um XML Schema ou com uma DTD.
Alguns parsers possibilitam validar os documentos, outros permitem, apenas,
verificar se os documentos estão bem formados. Os parsers que possuem suporte à
Capítulo 6 - Arquitetura e Protótipo 84
validação de documentos, geralmente, podem ser configurados para desconsiderar tal
validação e, assim, comportam-se como parsers sem validação.
É importante observar que, para se processar um documento XML, não é
obrigatório validá-lo. Um programa poderá extrair as informações que necessita de um
documento XML utilizando um parser que verifica, apenas, se ele é bem formado.
Para o desenvolvimento do protótipo, foi utilizado o Xerces Java Parser 2, da
Apache, que suporta as API's DOM, SAX e JAXP. Além disso, Xerces 2, suporta
Namespaces XML e as recomendações Structures [THOM01] e Datatypes [BIRO01] do
XML Schema 1.0.
A JAXP Java API for XML) [SUN02a], suporta processamento de documentos
XML usando DOM, SAX e XSLT.
6.2.4 - Software Servidor HTTP ePlug-in para Mecanismo de CGI ou Server Pages
A expressão servidor HTTP é utilizada para designar tanto o software que
implementa o protocolo HTTP quanto um computador que tenha este software
instalado. Nesta seção estaremos utilizando "servidor HTTP" para designar apenas o
equipamento e "software servidor HTTP" para designar o software, explicitamente.
Um software servidor HTTP, também chamado de servidor Web, é um programa
que processa requisições de um cliente, realizadas através do protocolo HTTP, e gera
respostas para este cliente neste mesmo protocolo.
Há vários softwares servidores Web disponíveis no mercado, sendo que alguns
deles podem ser obtidos, gratuitamente, através da Internet.
No protótipo implementado para este trabalho foi utilizado o servidor Web
Apache, versão 1.3, da Apache Software Foundation, que é um projeto com código
fonte aberto e está disponível gratuitamente na Web, no endereço "www.apache.org".
O fato de instalarmos um software servidor HTTP em uma máquina não
significa que possamos executar, através da Web, aplicações mais sofisticadas, ou seja,
aplicações que necessitam de processamento ou acesso a banco de dados. Para isso, é
necessário que tal servidor suporte algum tipo de mecanismo que permita a execução de
tais aplicações.
Alguns softwares servidores já vêm com suporte para alguns mecanismos.
Outros, porém, necessitam que os mecanismos sejam anexados a eles, através de plug-
ins, para que possam ser utilizados. No capítulo 2, na seção 2.3 ("Tecnologias para
Capítulo 6 - Arquitetura e Protótipo 85
Acesso a Banco de Dados via Internet"), foram apresentados alguns mecanismos como
CGI, DLLs ISAPI/NSAPI, ASP e Servlets Java.
Para a implementação do protótipo, que foi desenvolvido utilizando a tecnologia
de servlet da linguagem de programação Java, o plug-in que utilizamos é o fornecido
pelo Tomcat 4 que, neste caso, serve para conectar o mecanismo de servlet ( ou servlet
container) do Tomcat 4 ao Apache.
Na documentação do Tomcat 4, disponível na Web, através do endereço
"jakarta.apache.org/tomcat/tomcat^.O-doc/config/ajp.html'', temos uma descrição sobre
o comportamento do software servidor Web e do plug-in:
"Em poucas palavras, um servidor Web fica esperando uma requisição HTTP.
Quando essa requisição chega, o servidor faz o que é necessário para servir à
requisição, fornecendo o conteúdo necessário. Adicionar um "servlet
container" pode alterar alguma coisa nesse comportamento. Agora o servidor
Web precisa também fazer o seguinte:
• carregar a biblioteca adaptadora do servlet container e inicializá-la (antes
das requisições);
• quando uma requisição chega, ele precisa checar e observar se tal
requisição pertence a um servlet, caso afirmativo, ele precisa deixar o
adaptador assumir a requisição e manipulá-la.
O adaptador, por outro lado, precisa saber a qual requisição está servindo,
geralmente baseado em algum padrão na requisição URL, e para onde
direcionar essa requisição,
(...)
Para o Tomcat cooperar com qualquer servidor Web, ele precisa que um
"agente" que resida no servidor Web envie para ele as requisições de servlet
(servlet request). Esse é o plug-in do servidor Web e, em nosso caso, o plug-in
do servidor Web é o mod Jk. O redirecionador geralmente vem no formato de
uma DLL ou de um módulo de objeto compartilhado (shared object module) que
você conecta dentro do servidor Web. " [http://jakarta.apache.org/tomcat/tomcat-
4.0-doc/config/ajp.html]
Resumindo, ao receber uma requisição, o servidor Web verifica se ela
corresponde a uma chamada a um servlet. Caso afirmativo, esta requisição é entregue ao
plug-in que redireciona a chamada para o mecanismo de servlet. O mecanismo de
Capítulo 6 - Arquitetura e Protótipo 86
servlet executa o programa e retoma a resposta ao software servidor Web. Finalmente, o
software servidor Web repassará a resposta para o solicitante.
6.3 - Protótipo
Para validar o modelo proposto no capítulo 5 e a arquitetura apresentada neste
capítulo, foi desenvolvido um protótipo que implementa o processo de verificação de
origem do veículo no Órgão Central e a parte do processo de troca de informações de
AIT que trata do envio das informações para os Órgãos Conveniados.
A escolha dos dois processos citados anteriormente para serem desenvolvidos, se
deve ao fato deles possuírem características técnicas que serão replicadas em todos os
outros processos. Sendo assim, como o objetivo do protótipo é apresentar os principais
aspectos técnicos do modelo, ao implementarmos tais atividades estaremos abrangendo
todos os conceitos de transmissão e acesso a dados envolvidos.
Podemos dividir o protótipo em três módulos: o módulo de classes do modelo, o
módulo servidor e o módulo cliente.
O módulo de classes do modelo implementa as classes definidas no Capítulo 5.
Alguns métodos dessas classes acessam as tabelas do bancos de dados e geram os
documentos XML (documentos de dados) que deverão ser enviados a outros órgãos.
Outros métodos, processam os documentos de dados recebidos de outros órgãos,
carregam esses dados nas tabelas do banco de dados e geram os documentos que
deverão ser retornados aos órgãos solicitantes, quando for o caso. Os documentos de
dados recebidos ou gerados por estes métodos são armazenados em arquivos
temporários, gravados no diretório "C:\jakarta-tomcat^.0.2\bin\Temp", que, após seu
processamento, são apagados.
O módulo servidor corresponde ao servlet Java que recebe os documentos XML,
chamados de "pacotes de transmissão". Este servlet interpreta o pacote de transmissão
recebido, interage com o módulo de classes para que as operações solicitadas sejam
executadas e retorna a resposta ao órgão solicitante.
O módulo cliente corresponde aos programas Java que solicitarão serviços dos
sistemas de outros órgãos de trânsito. Esses programas Java chamam os métodos das
classes do módulo de classes, montam os pacotes de transmissão contendo os
documentos de dados gerados por aqueles métodos, enviam estes pacotes para o módulo
servidor dos órgãos de trânsito de destino e processam as respostas recebidas.
Capítulo 6 - Arquitetura e Protótipo 87
6.3.1 - O Ambiente de Implementação do Protótipo
O protótipo foi desenvolvido utilizando a linguagem Java 2.0, sobre o sistema
operacional Windows 98. A robustez e a portabilidade da linguagem Java e a facilidade
em obter componentes para tratamento de documentos XML, foram motivos que
levaram a escolha dessa linguagem.
As tecnologias utilizadas para o desenvolvimento e implementação do protótipo
foram apresentadas durante a descrição dos componentes necessários para a
implementação do modelo.
Sendo assim, os componentes utilizados no ambiente de implementação do
protótipo podem ser relacionados àqueles apresentados no diagrama de implantação da
Figura 6.1 e no diagrama de componentes da Figura 6.2. São eles:
• a aplicação Web foi desenvolvida utilizando-se servíeis Java;
• o software servidor HTTP utilizado foi o Apache 1.3.23 para Windows;
• utilizou-se o plug-in "mod_webapp'\ junto ao o arquivo de configuração do Apache,
"httpd.conf', para conectar o mecanismo de servlet do Tomcat 4.0.2;
• o parser XML utilizado foi o Xerces 2, utilizando a API SAX;
• as tabela foram criadas no MS Access e utilizou-se uma ponte JDBC-ODBC para
acessar os dados armazenados neste banco.
É importante observar que o JDK 1.3.1, o servidor Web Apache, o parser
Xerces 2 e o servidor de aplicações Java Tomcat 4, são tecnologias gratuitas e que estão
disponíveis para download na Web. Além do fato de serem tecnologias amplamente
utilizadas, a facilidade em obtê-las foi um dos motivos que levaram à escolha de cada
uma.
As classes AIT, Veiculo, OrgaoTransito e AlTKxterno, da especificação do
modelo, foram criadas como classes Java. Além disso, foram criadas tabelas no MS
Access que correspondem aos atributos daquelas classes.
As operações, especificadas no capítulo 5, desenvolvidas neste protótipo foram:
• veiculoSemIdentificacao(), registrarUfVeiculo(xmlVeiculos),
obterAitsNaoEviados() e registrarReciboAit(xmlReciboAit) da classe AIT;
• obterVeiculos(xmlPlacas) da classe Veiculo;
• obterUrlOrgaoTransito da classe OrgaoTransito;
• carregarAitExterno(xmlAit) da classe AITExterno.
CtiDÍtulo 6 - Arquitetura e Protótipo 88
Por ter sido utilizada a API SAX para executar o parse dos documentos XML,
foi necessária a criação das classes para manipular os eventos gerados por esta API.
Sendo assim, as classes criadas são as seguintes:
• ParserSAXReciboAit: manipula os eventos SAX ao analisarmos um documento
xmlReciboAit;
• ParserSAXRegVeiculo: manipula os eventos SAX ao analisarmos um documento
xmlVeiculos;
• ParserSAXVeiculo: manipula os eventos SAX ao analisarmos um documento
xmlPlacas;
• ParserSAXAit: manipula os eventos SAX ao analisarmos um documento xmlAit.
Para tratar erros que possam ocorrer durante os parsers, foi criada uma classes
gernérica chamada ErrorChecker. Para cada instância das classes que manipulam os
eventos SAX, há uma instância da classe ErrorChecker associada.
As classes apresentadas até este momento formam o módulo de classes do
modelo. Elas foram criadas dentro de seus respectivos pacotes, como especificado na
Figura 5.19. Na linguagem Java os pacotes são identificados pelo caminho de diretórios
onde estão armazenadas as classes. Neste caso, os pacotes são identificados pelo
caminho gov/miiit. Assim, temos a seguinte estrutura:
• o pacote gov.miiit.orgaoCentral contém as classes Veiculo e ParserSAXVeiculo;
• o pacote gov.miiit.orgaoTransito contém as classes OrgaoTransito e ErrorChecker;
• o pacote gov.miiit.orgaoAutuador contém as classes Ait, ParserSAXReciboAit e
ParserSAXRegVeiculo;
• o pacote gov.miiit.orgaoConveniado contém as classes AitExterno e ParserSAXAit.
Foi criado, ainda, um quinto pacote chamado gov.miiit.tipos que contém a classe
ParametrosMiiit que define constantes que são utilizadas pelos métodos das classes que
compõem o protótipo, tais como, o diretório no qual serão gravados os arquivos
temporários, o código e o URL do órgão local, os atributos que deverão estar junto ao
elemento "Envelope" do pacote de transmissão e a quantidade de Unidades Federativas
existentes.
Além dessas classes e operações do módulo de classes, foram criadas as classes
RecebePacoteWeb, EnviaXmlPlacas e EnviaXmlAit, que correspondem aos servlets que
receberão e enviarão os pacotes de transmissão, trocados entre os órgãos de trânsito. A
Capitule 6 - Arquitetura e Protótipo 89
classe RecebePacoteWeb é o servlet que implementa o módulo servidor do protótipo.
As classes EnviaXmlPlacas e EnviaXmlAit formam o módulo cliente.
As classes EnviaXmlPlacas e EnviaXmlAit foram criadas como servíeis devido
ao fato das interfaces do protótipo terem sido desenvolvidas em HTML. Entretanto, tais
classes poderiam ter sido desenvolvidas utilizando uma interface Java que não
necessitasse de um ambiente Web, tornando-as, assim, classes não servíeis.
Outras três classes foram criadas para auxiliar no envio e na recepção dos
pacotes de transmissão. Essas classes são utilizadas tanto pelo servlet
RecebePacoteWeb para analisar os pacotes recebido e gerar a resposta às solicitações,
quanto por EnviaXmlPlacas e EnviaXrrüAit para gerar o pacote com as solicitações e
processar as respostas recebidas.
As classes AnalisaPacote e ParserSAXPacote recebem um documento XML
correspondente a um pacote de transmissão, realiza o parse de tal documento, cria
arquivos temporários para cada documento de dados contido naquele pacote e faz
chamadas aos métodos das classes do módulo de classes que processarão os documentos
de dados.
A classe GeraEnvelope cria um documento XML que corresponde a um pacote
de transmissão, contendo todos os documentos de dados que deverão ser enviados ao
órgão de trânsito destino.
Os servlets são armazenados em uma pasta do servlet container configurada para
tal. No caso deste protótipo utilizou-se a pasta defauli do Tomcat 4, cujo o caminho
completo é "C:\jakarta-tomcat-4.0.2\webapps\examples\WEB-INF\classes".
Os códigos fonte dos programas Java e dos documentos HTML utilizados pelo
protótipo estão listados no Apêndice E, assim como as DDL's (Data Definition
Languagè) utilizadas para criar as tabelas no MS Access.
6.3.2 - As Interfaces e o Fluxo de Documentos
Foram criadas duas páginas HTML que serão utilizadas como as interfaces
iniciais para os processos de verificação da origem do veículo no órgão central e de
envio dos AIT's aos órgãos conveniados. Como especificado pelo modelo, esses
processos são iniciados no Sistema do Órgão Autuador.
O botão "Verificar Veículos" da página HTML, apresentada na Figura 6.5, inicia
o processamento.
Capítulo 6 - Arquitetura e Protótipo 90
'3| Verifica öligem de veículos - MIMT - Microsoft Internet Explorer
| f | f ' « l V • * • - 1 * - « II -H
Modelo de Intercâmbio de Informações de Infrações de Transito
PROTÓTIPO
Verificar origem de veículos
Verificar Veiai D s I
Figura 6.5 - Página para Verificação da Origem do Veículo
Essa página possui um formulário com um botão que aciona o servlet
EnviaXmlPlacas que, por sua vez, irá chamar o método "veiculoSemldentificacao" da
classe Ait. Este método retorna o nome do arquivo temporário contendo o documento
xmlPlacas, gerado por ele. O xmlPlacas contém todas as placas informadas nos AIT's
que ainda não foram verificadas.
Feito isso, é pesquisado qual o código do Órgão Central e qual o URL deste
órgão, representando o local para onde deverá ser enviado o pacote de transmissão que
será criado. O documento xmlPlacas, criado inicialmente, é incorporado ao pacote de
transmissão através de chamadas aos métodos da classe GeraEnvelope, juntamente com
a definição da operação que deverá ser realizada pelo Sistema do Órgão Central, no
caso, a operação "obterVeiculos".
O pacote de transmissão é enviado através de uma conexão com o site do Órgão
Central, representado aqui pelo servlet RecebePacoteWeb. O URL que endereça este
servlet é "http ://localhost:8080/examples/servlet/RecebePacoteWeb".
Ao receber o pacote de transmissão, o servlet RecebePacoteWeb cria uma
instância da classe AnalisaPacote que irá analisar o documento recebido. O método
"parser" da classe AnalisaPacote gera um arquivo temporário com o documento
Capítulo 6 - Arquitetura e Protótipo 91
xmlPlacas contido no pacote de transmissão e envia-o como parâmetro para o método
"obterVeiculo" da classe Veiculo.
O método "obterVeiculo" retorna o nome do arquivo temporário contendo o
documento xmlVeiculos gerado por ele. O conteúdo deste arquivo é inserido no pacote
de transmissão que será retornado ao Órgão Autuador. Este pacote de transmissão a ser
retornado é criado dentro de outro arquivo temporário cujo nome se encontra no atributo
"nomeArquivoPacote" da classe AnalisaPacote.
Quando o método "parser" da classe AnalisaPacote termina seu trabalho, o
servlet RecebePacoteWeb retorna o conteúdo do arquivo temporário, cujo nome se
encontra no atributo "nomeArquivoPacote" da classe AnalisaPacote, para o Órgão
Autuador. Nesse momento, o controle volta para o servlet EnviaXmIPIacas.
Ao receber o pacote de retorno, o servlet EnviaXmIPIacas cria uma nova
instância da classe AnalisaPacote que irá analisar este documento retonado pelo servlet
RecebePacoteWeb. O documento xmlVeiculos, contido neste pacote de transmissão,
será enviado ao método "registrarUfVeiculo" da classe Ait que, por sua vez, atualizará
os registros da tabela AIT a partir do conteúdo daquele documento. •UfcnviaiAH - MINI - Micioiott Internet EuploreF H P ES
grqutvú fedtfa fcJot* £avoilos f-enamentss Atyda O <*> • J J* J -J ¿ i " • 9 ¿ •> S \ - - , - i
Modelo de Intercambio de Informações de Infrações de Transito
PROTÓTIPO
Enviar ATFs para Órgãos Conveniados
Figura 6.6 - Página para Envio dos documentos xmlAit para os respectivos destinos
Capítulo 6 - Arquitetura e Protótipo 92
Verificado em qual UF cada veículo foi licenciado, o passo seguinte é o envio
dos AITs, cujos veículos já foram identificados, para os respectivos Órgãos
Conveniados. A Figura 6.6 mostra a página HTML para realizar esta tarefa.
Da mesma forma que a página HTML que verifica a origem do veículo, a página
apresentada na Figura 6.6 possui um formulário com apenas um botão. Este botão
aciona o servlet EnviaXmlAit que chamará o método "obterAitsNaoEnviadas" da classe
Ait. Este método retorna um vetor bidimensional, 27 por 2, contendo os nomes dos
arquivos temporários, que representam os documentos xmlAit, gerados por ele e a sigla
da UF a qual se destina o conteúdo de tal arquivo. Neste vetor, há apenas um documento
xmlAit (ou seja, um arquivo temporário) associado a uma determinada UF. A dimensão
maior deste vetor (tamanho 27) é definida pela constante QTE_UF declarada na classe
ParametrosMiüt.
As atividades após o final do processamento realizado pelo método
"obterAitsNaoEnviadas" serão repetidas para cada arquivo identificado no vetor.
Primeiramente, serão pesquisados, através da sigla da UF, qual o código e qual o
URL do Órgão Conveniado para o qual aquele arquivo deverá ser enviado. Em seguida,
o conteúdo do arquivo será inserido em um pacote de transmissão juntamente com a
definição da operação que deverá ser realizada pelo Órgão Conveniado, neste caso, a
operação "carregarAitExterno". Para isso, serão utilizados os métodos da classe
GeraEnvelope.
O pacote de transmissão criado é enviado ao Órgão Conveniado através de uma
conexão com o URL pesquisado. Como o protótipo opera em um ambiente único, todos
os URL's dos órgãos conveniados apontam para o servlet RecebePacoteWeb, que está
preparado para atender a todas as requisições. O URL, portanto, é o mesmo apresentado
para o Órgão Central, "http://localhost:8080/examples/servlet/RecebePacoteWeb".
Ao receber o pacote de transmissão, o servlet RecebePacoteWeb cria uma
instância da classe AnalisaPacote que identificará a operação a ser realizada e chamará
o método "carregarAitExterno" da classe AitExterno, passando como parâmetro o
documento xmlAit recebido. Este método inclui o conteúdo deste documento xmlAit na
tabela AitExterno e cria um arquivo temporário contendo o documento xmlReciboAit.
O conteúdo deste arquivo é retornado ao servlet EnviaXmlAit após ser colocado em um
pacote de transmissão identificando a operação "registrarReciboAit".
Ao receber o pacote de transmissão retornado, o servlet o EnviaXmlAit cria uma
instância da classe AnalisaPacote que verificará este documento. O método "parser" da
Capítulo 6 - Arquitetura e Protótipo 93
classe AnalisaPacote chamará o método "registrarReciboAit" da classe Ait que
processará o documento xmlReciboAit recebido, identificando e atualizando na tabela
Ait do banco de dados quais os AIT's que foram recebidos pelo Órgão Conveniado.
Capítulo 6 - Arquitetura e Protótipo 94
7 - Comentários a Respeito do Modelo Proposto
7.1 - Introdução
Este capítulo faz alguns comentários a respeito do modelo de intercâmbio de
informações de infrações de trânsito proposto neste trabalho.
Esses comentários estão divididos em três categorias: considerações legais,
comentários técnicos e melhoramentos futuros. As seções seguintes tratarão de cada
uma dessas categorias.
7.2 - Considerações Legais
Duas questões legais são levantadas a respeito do modelo.
A primeira questão diz respeito à emissão da notificação. Segundo o art. 260, §
2 o, do CTB "as multas decorrentes de infração cometida em unidade da Federação
diversa daquela do licenciamento do veículo poderão ser comunicadas ao órgão ou
entidade responsável pelo seu licenciamento, que providenciará a notificação". Ainda,
nesse sentido, o art. 4° da Resolução 10/98 do CONTRAN estabelece que "nos casos de
infrações ocorridas em localidade diferente daquela da habilitação do condutor infrator
e em unidade de federação distintas da do licenciamento do veículo, o órgão ou entidade
autuador deverá solicitar que a notificação da infração seja efetuada através do órgão de
trânsito da unidade da federação de licenciamento do veículo ou do registro do
condutor".
Esses dois dispositivos podem constituir-se em um fator que impossibilite ao
município conveniado emitir, legalmente, a NIT. Isso significaria que a solução
proposta neste trabalho seria válida apenas para a ligação entre o município autuador e
os DETRAN's. Portanto, o papel relacionado ao sistema do órgão conveniado somente
poderá ser exercido pelos sistemas dos DETRAN's.
A segunda questão, refere-se à competência para a verificação da consistência
dos autos de infração de trânsito. De acordo com o art. 281 do CTB "a autoridade de
trânsito, na esfera da competência estabelecida neste Código e dentro de sua
circunscrição, julgará a consistência do auto de infração e aplicará a penalidade
cabível." Sendo assim, durante o processo de troca de informações de AIT, especificado
Capítulo 7 - Comentários a Respeito do Modelo Proposto 95
na seção 5.4, a consistência do AIT deverá ser executada pelo Sistema do Órgão
Autuador.
Torna-se necessário, portanto, um processamento, no Sistema do Órgão
Autuador, para a consistência dos AIT's que serão enviados a outros órgãos. Esse
processamento é anterior ao início do processo de troca de informações de ATT.
Para que a consistência do AIT seja completa, porém, é necessário que se defina
um processo para a identificação do condutor, a partir do número do RENACH
(Registro Nacional de Condutores Habilitados) informado em sua CNH (Carteira
Nacional de Habilitação). Esse processo seria semelhante ao processo de identificação
de origem do veículo.
Neste caso, a consistência do AitExterno poderia ser descartada, ficando o
Sistema do Órgão Conveniado apenas com a incumbência de identificar o endereço do
infrator para gerar e emitir a NIT. Assim, o processo representado pelo diagrama de
seqüência da Figura 5.10 (Diagrama de Seqüência para o Caso de Uso Troca de
Informações de AIT - consistência de AIT) não seria aplicado.
7.3 - Comentários Técnicos
Esta seção trata dos aspectos técnicos envolvidos na criação e implementação do
modelo.
Um primeiro aspecto a ser abordado refere-se à utilização da XML como a
linguagem para a estruturação dos documentos trocados entre os órgãos. Isso simplifica
a manutenção dos programas no caso de alterações no modelo e aumenta a sua
flexibilidade.
Para exemplificar o fato da utilização da XML simplificar a manutenção dos
programas, podemos avaliar a situação na qual seja incluído um novo elemento em
algum documento definido pelo modelo. Nesse caso, a utilização de um parser que
valide esses documentos com os seus respectivos XML Schémas, não nos obriga a
alterar os programas para que eles validem o novo elemento, basta alterar o documento
XML Schéma. Além disso, dependendo da estrutura das tabelas do banco de dados e da
forma como foram escritos os programas para a inclusão e para a pesquisa dos dados
nesse banco, não haveria necessidade, nem mesmo, destes programas serem alterados.
O mapeamento do conteúdo do novo elemento para o respectivo atributo no banco de
Capitulo 7 - Comentários a Respeito do Modelo Proposto 96
dados poderia ser feito de forma automática, caso o nome do elemento seja idêntico ao
nome do atributo.
Outro aspecto é a independência do modelo de troca de informações com o
esquema do banco de dados utilizado por cada órgão. O esquema especificado no
capítulo 4 e o diagrama de classes apresentado no capítulo 5 são sugestões para a
modelagem do problema. Um exemplo dessa independência são as classes AU e
AITExterno, que poderiam ser modeladas como uma agregação e serem implementadas
no banco de dados como uma única tabela, sem que o modelo de troca seja afetado.
Obviamente, a independência citada no parágrafo anterior não é total, uma vez
que existem controles que devem ser entendidos por todos os sistemas dos órgãos de
trânsito. Nesse sentido, é importante que os sistemas dos órgãos de trânsito que
interagem com o modelo estejam preparados para: interpretar os documentos XML
relativos ao pacote de transmissão e aos documentos de dados; executar o procedimento
correto de acordo com o especificado no modelo e solicitado através dos documentos
XML.
Outra observação a respeito do modelo está ligada aos atributos destinados às
informações de pagamento das NIT's. Considera-se que essas NXT's serão pagas em
uma única parcela. Entretanto, há a possibilidade desse pagamento ocorrer em várias
parcelas, como é o caso das multas aplicadas pela BHTRANS a partir de setembro de
2001. Caso essa situação passe a ser uma prática de todos os órgãos de trânsito
envolvidos com a troca de informações, o modelo poderá ser expandido para atender a
essa nova realidade.
Finalmente, caso a consistência dos AIT's passasse a ocorrer nos sistemas dos
órgãos conveniados, como previsto inicialmente no modelo, a tabela de itens a serem
consistidos deverá ser avaliada e definida pelos órgãos envolvidos. Da mesma forma, no
caso de inclusão de novos itens para consistência deverá haver consenso entre os
órgãos.
7.4 - Melhoramentos Futuros
Uma questão que deve ser tratada para a implementação e implantação de um
modelo como o definido nesta dissertação, diz respeito à segurança das transações e dos
dados. Portanto, faz-se necessário um estudo sobre as técnicas e tecnologias de
criptografia e verificação de mensagens transmitidas via Internet que possam ser
Capítulo 7 - Comentários a Respeito do Modelo Proposto 97
incorporadas ao modelo. Isso é importante para que se garanta a confiabilidade de tais
mensagens.
Do ponto de vista específico do processamento de infrações de trânsito, os
procedimentos relacionados ao controle de pagamento e compensação de valores
deverão ser definidos. Feito isso, o modelo deverá ser adaptado para atender a tais
definições.
Da forma como está apresentado neste trabalho, o modelo já permite que seja
realizado algum acompanhamento a respeito dos pagamentos das multas. Para
evoluirmos nesse sentido, podemos utilizar a extensibilidade da XML para
incorporarmos informações ao modelo que possibilite a automatização do crédito na
conta dos órgãos autuadores, como por exemplo, informações a respeito dos código de
barras das notificações. Além disso, podemos estudar a possibilidade de serem
incorporadas informações recebidas diretamente dos bancos que realizam o
recolhimento dos pagamentos das multas.
Capítulo 7 - Comentários a Respeito do Modelo Proposto 98
8 - Conclusão
Quando este trabalho foi iniciado, em 1999, buscou-se aliar o trabalho de
pesquisa, necessário à preparação de uma dissertação, com a apresentação de uma
alternativa para solução de um problema enfrentado pela Administração Pública, até
então, não resolvido. Este problema tratava-se da imposição de penaüdades de trânsito a
infratores cujos veículos haviam sido licenciados em Unidades da Federação diferentes
daquela onde ocorreu a infração.
Somando-se a isso, o fato de minhas atividades na unidade da PRODABEL,
vinculada à BHTRANS, estarem ligadas diretamente ao problema, motivou, ainda mais,
a decisão por estudar mais profundamente o tema. Este mesmo fato, fez com que o
problema fosse visualizado do ponto de vista de um órgão de trânsito municipal,
procurando solucioná-lo de forma ampla, porém, descentralizada. Caso o tratamento
fosse dado de forma centralizada, uma eventual implementação e implantação do
modelo poderia ser inviável.
Havia, contudo, a intenção de apresentar um trabalho que utilizasse tecnologias
modernas e que trouxessem ganhos, não só para as atividades realizadas pela
Administração de um modo geral, como também para aquelas que realizo no meu dia-a-
dia como analista de sistemas de uma empresa pública Ügada a área tecnológica.
A partir desta determinação, iniciei o trabalho de pesquisa estudando tecnologias
ligadas ao ambiente Web e à Internet, sobre as quais tinha pouco conhecimento. A
medida que os estudos foram evoluindo, e aproveitando informações recebidas durante
as disciplinas "Tecnologias WWW", "Redes de Computadores", "Bibliotecas Digitais",
"Engenharia de Software" e "Banco de Dados", oferecidas pelo mestrado, foram
definidas as tecnologias utilizadas pelo neste trabalho, tais como, XML, Java e a UML,
para a documentação e apresentação das definições associadas ao modelo.
Inicialmente, havia a idéia de apresentar o modelo juntamente a uma proposta
para a segurança dos dados transmitidos. Entretanto, devido à vastidão do tema
segurança, o qual, por si só, poderia ocupar todo o trabalho de uma dissertação, foram
apresentados alguns mecanismos no Capítulo 2 e recomendado como um melhoramento
futuro para o modelo.
Paralelamente a este estudo, foi iniciada uma pesquisa junto a pessoas que
trabalhavam em empresas de trânsito, para verificar como o problema de troca de
Capítulo 8 - Conclusão 99
informações sobre multas estava sendo tratado. Devido à impossibilidade de visitar
todos os locais, foram feitas entrevistas via telefone e, em poucos casos, via correio
eletrônico. Entretanto, todas as entrevistas estavam baseadas nas perguntas dos
questionários apresentados no Apêndice A.
Felizmente, hoje já existe uma solução, desenvolvida pelo DENATRAN, que
possibilita o envio de informações ligadas a multas de trânsito entre órgãos das diversas
UF's, Trata-se do RENACOM - Registro e Câmara Nacional de Compensação de
Multas Interestaduais. Tal solução, porém, ainda não encontra-se totalmente implantada.
Espera-se que até o final deste ano de 2002, grande parte dos órgãos de trânsito ligados
às esferas nacional, estadual e municipal já estejam integrados ao RENACOM.
Entretanto, mesmo com o advento do RENACOM, o tema desta dissertação não
foi alterado, pois o modelo proposto aqui possui características, tanto técnicas quanto
operacionais, distintas daquele projeto.
No sistema implantado pelo DENATRAN, o RENACOM funciona como um
pivô para a troca de informações. E através dele que os diversos órgãos de trânsito se
comunicam, centralizando, assim, a troca de informações.
No caso do modelo proposto por este trabalho, a centralização ocorre apenas na
verificação da origem do veículo no órgão central. Todas as outras comunicações são
realizadas diretamente entre órgãos ou, no caso da verificação do veículo ser feita
através de um órgão de trânsito municipal, este será um intermediário no processo de
identificação.
Outra diferença entre os modelos diz respeito ao formato dos dados transmitidos.
Enquanto o RENACOM utiliza a estrutura de arquivos com posições pré-definidas, o
modelo aqui proposto utiliza documentos XML. A utilização da XML apresenta
vantagem no que diz respeito à definição e consistência do documento, através da
utilização do XML Schema. Como já foi mencionado, um documento XML leva a sua
definição junto a ele. Por outro lado, há a necessidade da utilização de tecnologias nem
sempre disponíveis ou dominadas pelas equipes de desenvolvimento de software dos
diversos órgãos de trânsito, o que dificultaria a implementação e implantação do
modelo.
O modelo proposto neste trabalho mostra uma das maneiras como a Internet e as
tecnologias ligada a ela podem auxiliar a Administração Pública em suas atividades
internas. O serviço descrito aqui não corresponde ao fornecimento de informações ao
cidadão, nem à prestação de serviços voltados diretamente ao público. Ele se apresenta
Capítulo 8 - Concl usão 100
como um catalisador para uma atividade adrniriistrativa, no caso, o processamento de
multas de trânsito, de forma que as informações armazenadas nos bancos de dados
distribuídos pelos diversos órgãos possam ser compartilhadas.
Obviamente, a arquitetura apresentada neste trabalho não está restrita a oferta de
um único serviço. Ela apresenta um potencial que pode ser expandido para várias outras
aplicações que necessitem do intercâmbio de informações em longas distância ou, até
mesmo, aplicações que tratam informações e serviços que deverão ser disponibilizados
diretamente aos cidadãos.
Um aspecto que deve ser ressaltado, diz respeito à XML. A XML é uma
linguagem de marcação que não se concentra na aparência, mas sim na estrutura do
documento. XML é uma forma adequada para criação de documentos estruturados que
podem ser entendidos pelos computadores, viabilizando, assim, uma comunicação entre
eles. A utilização dessa linguagem está crescendo a cada dia e novas ferramentas estão
sendo desenvolvidas, o que facilita a utilização desta tecnologia.
Além disso, estando a troca de informações baseada na XML, novos serviços
podem ser disponibilizados, como, por exemplo, a criação de um portal de Trânsito
Estadual, através do qual algum Órgão de Trânsito Municipal, que não deseje, ou não
tenha condição, de implantar seu próprio servidor Web, inclua e consulte as
informações de suas multas de trânsito utilizando documentos compatíveis com os
criados por este modelo. Contudo, a criação de um portal com tais características
implica na utilização de mecanismos de segurança e de transformação que não foram
tratados aqui,
Como citado anteriormente, nem sempre as condições necessárias para a
utilização de tecnologias Web estão disponível. Porém, os estudos realizados para o
desenvolvimento desta dissertação mostram que este campo tende a ampliar-se cada vez
mais.
Finalmente, a busca por uma solução que tratasse informações de bancos de
dados heterogêneos e distribuídos, utilizando a Internet como um meio de transmissão,
foi alcançada. A utilização de aplicações associadas aos servidores Web, transmitindo
pacotes XML, possibilita que possam ser desenvolvidas soluções cujo trâmite de
informações seja transparente para os usuários que interagem com o sistema.
Capítulo 8 - Conclusão 101
Apêndice A - Questionários de Pesquisa
A.l - Questionário de Pesquisa - Município
1) Quem processa as multas de infração de trânsito que ocorrem e m seu Município? O próprio
Município ou o Estado?
2) Caso o processamento das multas de trânsito seja realizado somente peto Estado, responda
as perguntas abaixo:
2.1) Existe algum convênio delegando para o Estado o poder de lavrar autos de infração
de competência municipal?
2.2) O Município participa, de alguma forma, em alguma atividade ligada à fiscalização
do trânsito?
3) Caso o Município processe multas de trânsito, responda as perguntas abaixo:
3.1) Como ocorre o processamento de multas no Município? Todos os Autos de Infração
de Trânsito lavrados no município são processados pelo Município ou parte deles
(por exemplo, os de competência estadual) são processados pelo Estado?
3.2) Como o Município utiliza as bases de veículos e condutores do Estado? O Estado
disponibiliza toda a base de veículos e condutores ou apenas os dados daqueles que
pertencem ao Município solicitante?
3.3) Por qual meio (disquete, fita magnética, Internet, linha dedicada, relatório em papel
etc.) é realizada a troca de informações entre o Estado e o Município?
3.4) Há alguma solução para acesso a alguma base de dados Nacional de veículos e
condutores?
3.5) Existe algum convênio entre o Município e o Estado no que diz respeito à
fiscalização? (Por exemplo, tanto o agente municipal quanto o agente estadual
podem lavrar autos para qualquer tipo de infração.)
3.6) Como são tratadas as multas aplicadas a veículos de outros municípios de seu
Estado? E as aplicadas a veículos de outros Estados?
3.7) Qual o volume (percentual), aproximado, de multas aplicadas a veículos de outros
Estados?
3.8) Há algum sistema informatizado para o processamento de infrações de trânsito? Ele
foi desenvolvido pelo próprio Município ou foi adquirido de terceiros?
Apêndice A - Questionários de Pesquisa 102
3.9) Qual o SGBD (Sistema de Gerenciamento de Banco de Dados) utilizado por esse
sistema?
4) A Empresa (ou Secretaria ou Departamento) de Trânsito possui fácil acesso à Internet? Esse Órgão, a Prefeitura Municipal ou algum outro Órgão ligado à Administração Pública possui um provedor Internet? Qual ou quais Órgãos possuem tal provedor?
5) Existe algum serviço ligado a infrações de trânsito disponibilizado na Internet? Quais?
6) Você acha importante que o problema das multas aplicadas a veículos de outros Estados
seja tratado de forma padronizada no âmbito nacional? Por que?
7) Você acha que a solução do problema de imposição de multas à veículos de outros Estados é:
1. S e m importância 2.Pouca importância 3.lmportante 4.Muito importante 5.Primordial
A.2 - Questionário de Pesquisa - Estado
1) No que diz respeito ao processamento de infrações, há alguma solução voltada para
a integração dos Órgãos de Trânsito Municipais com o Estado, uma vez que está
previsto no CTB a municipalização de algumas responsabilidades a respeito do
trânsito?
2) Caso haja uma solução para integração Estado/Município, por qual meio (disquete,
fita magnética, Internet, relatório em papel, sistema único etc.) é realizada a troca de
informações relacionadas às infrações de trânsito entre o Estado e o Município?
3) Existe algum convênio entre algum Município e o Estado no que diz respeito à
fiscalização? (Por exemplo, tanto o agente municipal quanto o agente estadual
podem lavrar autos para qualquer tipo de infração.)
4) Como são tratadas as multas de trânsito aplicadas a veículos de outros Estados?
5) Há alguma solução para acesso a alguma base de dados Nacional de veículos e
condutores?
6) Como é feita a interação com o DENATRAN para a atualização das bases
RENACH e RENAVAM? Qual a periodicidade dessa atualização?
7) Qual o volume (percentual), aproximado, de multas aplicadas a veículos de outros
Estados?
Apêndice A - Questionários de Pesquisa 103
8) Qual o ambiente (sistema operacional, linguagem(ns), SGBD) utilizado pelo sistema
informatizado para o processamento das infrações de trânsito? Esse sistema foi
desenvolvido por pessoal próprio ou foi terceirizado?
9) O Departamento de Trânsito possui fácil acesso à Internet? Esse Órgão ou algum
outro Órgão ligado à Administração Pública possui um provedor Internet? Qual ou
quais Órgãos possuem tal provedor?
10) Existe algum serviço ligado a infrações de trânsito disponibilizado na Internet?
Quais?
11) Você acha importante que o problema das multas aplicadas a veículos de outros
Estados seja tratado de forma padronizada no âmbito nacional? Por que?
12) Você acha que a solução do problema de imposição de multas à veículos de outros
Estados é:
1. S e m importância 2.Pouca importância 3.lmportante 4.Muito importante 5.Primordial
Aoêndice A - Questionários de Pesquisa 104
Apêndice B - Tabela de Tipos de Inconsistência
Esta tabela foi baseada na tabela de códigos de retorno utilizada no modelo de
troca eletrônica de infrações de trânsito entre Estados, definido pela Companhia de
Processamento de Dados do Estado do Rio Grande do Sul - PROCERGS, com a
colaboração da Companhia de Informática do Paraná - CELEPAR/PR. Código Descrição
001 Órgão Autuador inválido 002 Número de Identificação do AIT não informado 003 Placa inválida 004 UF inválida 005 Veículo não cadastrado 006 RENAVAM inválido 007 Local inválido 008 Data inválida 009 Horário inválido 010 Código da infração inválido 011 Equipamento de medição inválido 012 Medição inválida 013 Limite inválido 014 Medição menor que o limite 015 Unidade de medida inválida 016 Documento de identificação do agente não informado 017 Tipo do Auto inválido 018 Auto de infração já cadastrado 019 Auto de infração fora do prazo 020 CNH inválida 021 UF do condutor inválida 022 Código do município da infração inválido 023 Indicador de assinatura do Auto inválido 024 Condutor não cadastrado 025 Auto de infração já baixado 026 Data de pagamento inválida 027 Valor de pagamento não informado 028 Pagamento já cadastrado 029 Infrator — endereço incorreto 030 Infrator - tipo de documento incorreto 031 Infrator - documento incorreto 032 Infrator - UF do documento incorreto 033 Infrator - nome com caracteres inválidos 034 Auto de Infração não cadastrado
Apêndice B - T a b e l a de Tipos de Inconsitência 105
Apêndice C - XML Schema para os Documentos de
Dados do Modelo
<xsd : :element name <xsd : :e1eraent name <xsd ; : e I eraent name <xsd: :element name <xsd: :e1ement name <xsd ; ;element name: <xsd : :e1ement name:
type: <XSd: :element name: <xsd: : element name: <xsd ; :element name: <xsd; :element name: <xsd : :element name:
type: <xsd : :element name:
type:
A Listagem C.I apresenta o XML Schema que define os documentos utilizados
para conter os dados que serão intercambiados entre os sistemas conveniados.
<xsd.-schema xmlns:xsd= "http: //www.w3 . org/2001 /XMLSchema" xmlns:mit="http ://www.miiit.gov.br/MIHT" targetNamespace="http://www.miiit.gov.br/MIIIT" elementFormDefault-"unqualified" attributeFormDefault-"unqualified">
<!-- Declaração dos documentos definidos pelo modelo -->
: "docXmlPlacas" type-"mit :TipoXmlPlacas"/> : "docXmlVeiculos" type="mit :TipoXmlVeiculos" / > : "docXmlConfirmaPiacas" type="mit :TipoXmlConfirmaPlacas" / > : "docXmlAit" type-"mit:TipoXmlAit"/> : "docXmlReciboAit" type="mit:TipoXmlReciboAit"/> "docXmlAitConsistido" type="mit:TipoXmlAitConsistido"/> "docXmlReciboAitConsistido" "mit :TipoXmlReciboAitConsistido"/> "docXmlNit" type="mit:TipoXmlNit"/> "docXmlReciboNit" type-"mit :TipoXmlReciboNit"/> "docXmlRecurso" type="mit:TipoXmlRecurso"/> "docXmlReciboRecurso" type- "mit :TipoXinlReciboRecurso" /> "docXmlResultadoRecurso" "mit :TipoXmlResultadoRecurso"/> "docXmlReciboResultadoRecurso" "mit :TipoXmlReciboResultadoRecurso"/>
<;-- Tipo do Documento xmlPlacas
<xsd:complexType name="tipoXmlPlacas"> <xsd:sequence> <xsd: element name="placa• type="xsd: string"
minOccurs="1" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attributeGroup ref="mit:IdDocumento"/>
</xsd:complexType>
<!-- Tipo do Documento xmlVeiculos -->
<xsd:complexType name-"TipoXmlVeiculos"> <xsd:sequence> <xsd:element name="veiculo" minOccurs="1" maxOccurs-'unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="placa" type-"xsd:string"/> <xsd:sequence minOccurs="0" maxOccurs-"1"> <xsd:element name-"renavam" type="xsd:int"/> <xsd:element name-"codigoMarcaModelo" type="xsd:positiveInteger"/> <xsd:element name-"codigoMunicipioVeiculo" type="xsd:positivelnteger'/> <xsd:element name="ufVeiculo" type-"mit:ufBrasil"/> <xsd:element name-"cor" type-"xsd:string"/>
</xsd:seguence> <xsd: element name="codigoRetorno"> <xsd:simpleType> <xsd: restriction base="xsd:string"> <xsd:enumeration value="VE"/> <xsd:enumeration value="NE"/>
Apêndice C - X M L S c h e m a para os Documentos de D a d o s do Modelo 106
</xsd:restriction> </xsd:simpleType>
</xsd:element> </xsd:sequence>
</xsd:complexType> </xsd:element>
</xsd.-sequence> <xsd:attributeGroup ref="mit:IdDocumento"/>
</xsd:complexType>
<!-- Tipo do Documento xmlConfirmaPlacas — >
<xsd:complexType name-"TipoXmlConfirmaPlacas"> <xsd:sequence> <xsd:element name-"dataXmlPlacas" type="xsd: date"/> <xsd:element name-"horaXmlPlacas" type-"xsd:time"/> <xsd:element name-"codigoRetorno"> <xsd:simpleType> <xsd:restriction base-"xsd:string"> <xsd: enumeration value-"CF"/> <xsd: enumeration value="NC/>
</xsd: restriction> </xsd:simpleType>
</xsd: element > </xsd:sequence> <xsd:attributeGroup ref ="irdt : IdDocumento"1 />
</xsd:comp1exType>
<!-- Tipo do Documento xmlAit -->
<xsd:complexType name-"TipoXmlAit"> <xsd:sequence> <xsd:element name="ait n minOccurs="1" maxOccurs="unbounded"> <xs d: c o.Tip 1 exTy pe > <xsd:sequence> <xsd:element name="codigoOrgaoTransito" type-"xsd:positivelnteger"/> <xsd:element name-"identificacaoAit" type-"xsd:string"/> <xsd:element name="placaVeiculo" type="xsd:string"/> <xsd:element name="renavam" type="xsd:int"/> <xsd:element name-"codigoMunicipioVeiculo" type-'xsd:positivelnteger"
minOccurs="0" maxOccurs="1"/> <xsd:element name="ufVeiculo" type="mit:UfBrasil"/> <xsd:element name="nomeCondutor" type-"xsd:string"
m i n O c c u r s 0 " maxOccurs-"1"/> <xsd:element name="numeroCNHCondutor" type="xsd:int"
minOccurs="0" maxOccurs="1"/> <xsd:element name-"ufCNHCondutor" type-"mit:ufBrasil"
minOccurs="0" maxOccurs="1"/> <xsd:element name="nomeInfrator" type-"xsd:string"
minOccurs-"0" maxOccurs-"1"/> <xsd:element name="numeroCPFInfrator" type-"xsd:long"
minOccurs^"0" maxOccurs="1"/> <xsd:element name="numeroCGCInfrator" type="xsd:string"
minOccurs-"0" maxOccurs-"1"/> <xsd:element name="enderecolnfrator" type="xsd:string"
minOccurs-"0" maxOccurs-"1"/> <xsd:element name="nomeMunicipioInfrator" type="xsd:string"
minOccurs-"0" maxOccurs-"1"/> <xsd:element name-"localInfracao" type="xsd:string"/> <xsd:element name-"complementoLocallnfracao" type="xsd:string"
minOccurs ="0" maxOccurs = "!"/> <xsd:element name-"datalnfracao" type="xsd:date"/> <xsd:element name="horaInfracao" type="xsd:hora"/> <xsd:element name="codigoMunicipioInfracao" type="xsd:positivelnteger"/> <xsd:element name="codigolnfracao" type="xsd:positivelnteger"/> <xsd:element name-"numeroEquipamentoAfericao" type="xsd:string"
minOccurs="0" maxOccurs="1"/> <xsd:element name="valorLimitePermitido" type="xsd:float"
Apêndice C - X M L S c h e m a para os Documentos de D a d o s do Modelo 107
minOccurs="0" maxOccurs="1"/> <xsd:element name-"valorMedicaoRealizada" type="xsdr float"
minOccurs-"0" maxOccurs="1"/> <xsd:element name="unidadeMedida" type="mit:UnidadeMedida"
minOccurs= " 0 " itiaxOccurs- " 1" / > <xsd:element name="codigoAgente" type-"xsd:string"/>
</xsd:sequence> </xsd:complexType>
</xsd:element> </xsd: sequence> <xsd:attributeGroup ref="mit:IdDocumento"/>
</xsd:complexType>
<!-- Tipo do Documento xmlReciboAit -->
<xsd:complexType name-"TipoXmlReciboAit"> <xsd:sequence> <xsd:element name-"dataXmlAit" type-"xsd:date"/> <xsd:element name-"horaXmlAit" type="xsd:time"/> <xsd:element name="codigoRetorno"> <xsd:simp1eType> <xsd:restriction base-"xsd:string"> <xsd:enumeration value="CF"/> <xsd:enumeration value="NC"/>
</xsd:restriction> </xsd:simpleType>
</xsd:element> </xsd:sequence> <xsd:attributeGroup ref="mit:IdDocumento"/>
</xsd: complexType;-
<!-- Tipo do Documento xmlAitConsistido -->
<xsd:complexType name-"TipoXmlAitConsistido"> <xsd:sequence> <xsd:element name-"ait" minOccurs-"1" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequencer <xsd:element name-"codigoOrgaoTransito" type-"xsd:positivelnteger"/> <xsd:element name-"identificacaoAit" type="xsd:string"/> <xsd:element name="indResultadoConsistencia"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value-"NP"/> <xsd:enumeration value="CT"/> <xsd:enumeration value-"IN"/>
</xsd:restriction> </xsd:simpleType>
</xsd:element> <xsd:element name="inconsistenciasAit" minOccurs-"0" maxOccurs="1"> <xsd:complexType> <xsd:sequence> <xsd:element name-"numeroTipoInconsistencia"
type-"xsd:positivelnteger" minOccurs="1" maxOccurs-"unbounded"/>
</xsd:sequence> </xsd:complexType>
</xsd:element> </xsd:sequence>
</xsd;complexType> </xsd:element>
</xsd:sequence> <xsd:attributeGroup ref-"mit:IdDocumento"/>
</xsd:complexType^
<!-- Tipo do Documento xmlReciboAitConsistido -->
<xsd:complexType name="TipoXmlReciboAitConsistido">
Apendice C - X M L S c h e m a para os Documentos de D a d o s do Modelo 108
<xsd:sequence> <xsd:element name="dataXmlAitConsistido" type="xsd:date"/> <xsd:element name="horaXmlAitConsistido" type-"xsd:time"/> <xsd:element name="codigoRetorno"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value-"CF"/> <xsd:enumeration value="NC"/>
</xsd:restriction> </xsd:simpleType>
</xsd:element> </xsd:sequence> <xsd:attributeGroup ref="mit:IdDocumento"/>
</xsd:complexType>
<!-- Tipo do Documento xmlNit -->
<xsd:complexType name-"TipoXmlNit"> <xsd:sequence> <xsd:element name="nit" minOccurs="1" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name-"codigoOrgaoTransitoNit" type="xsd:positiveInteger"/> <xsd:element name-"numeroNit" type-"xsd:long"/> <xsd:element name="codigoOrgaoTransitoAit" type="xsd:positivelnteger"/> <xsd:element name-"identificacaoAit" type="xsd:string"/> <xsd:element name-"dataGeracao" type="xsd:date"/> <xsd:element name-"dataEmissao" type-"xsd:date"
minOccurs="0" maxOccurs="1"/> <xsd:element name="dataEnvio" type="xsd:date"
minOccurs="0" maxOccurs="1"/> <xsd:element name="dataEntrega" type-"xsd:date"
minOccurs-"0" maxOccurs-"1"/> <xsd:element name="infPagamento" minOccurs="0" maxOccurs="1"> <xsd:complexType> <xsd:sequence> <xsd:element name="dataPagamento" type-"xsd:date"/> <xsd:element name="valorPago" type-"xsd:float"/>
</xsd:seguence> </xsd:complexType>
</xsd:element> </xsd:sequence>
</xsd:complexType> </xsd:element>
</xsd:sequence> <xsd:attributeGroup ref="mit:IdDocumento"/>
</xsd:complexTvpe>
<!-- Tipo do Documento xmlReciboNit — >
<xsd:complexType name-"TipoXmlReciboNit"> <xsd:sequence> <xsd:element name="dataXmlNit" type-"xsd:date"/> <xsd:element name="horaXmlNit" type-"xsd:time"/> <xsd:element name-"codigoRetorno"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="CF"/> <xsd:enumeration value="NC"/>
</xsd:restriction> </xsd:simpleType>
</xsd:element> </xsd:sequence> <xsd:attributeGroup ref="mit:IdDocumento"/>
</xsd:complexType>
<!-- Tipo do Documento xmlRecurso — >
Apdndfce C - X M L S c h e m a para os Documentos de D a d o s do Modelo 109
<xsd:complexType name-"TipoXmlRecurso"> <xsd: sequence> <xsd:element name-"recurso" minOccurs-"1" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="codigoOrgaoTransitolnterposicao"
type="xsd:positivelnteger"/> <xsd:element name-"numeroRecurso" type-"xsd:long"/> <xsd:element name-'datalnterposicao" type-"xsd:date"/> <xsd: element name =•codigoOrgaoTransitoAit" type ="xsd:positivelnteger"/ <xsd:element name='identificacaoAit" type="xsd:string"/> <xsd: element name="pos icaoRecurso"> <xsd:simpleType> <xsd:restriction base-"xsd:string"> <xsd:enumeration value-"E"/> <xsd:enumeration value-"C"/>
</xsd:restriction> </xsd:simpleType>
</xsd:element> <xsd: element name="resultadoRecurso" minOccurs="0" maxOccurs="1"> <xsd:simpleType> <xsd: restriction base = "xsd:string"> <xsd:enumeration value="P"/> <xsd;enumeration value-"N"/>
</xsd:restriction> </xsd:simpleType>
</xsd:element> </xsd:sequence>
</xsd:complexType> </xsd: element>
</xsd:sequence> ' <xsd:attributeGroup ref="mit :IdDocumento"/> </xsd:complexType>
<[-- Tipo do Documento xmlReciboRecurso -->
<xsd:complexType name;"TipoXmlReciboRecurso"> <xsd:sequence> <xsd:element name="dataXmlRecurso" type-"xsd:date"/> <xsd:element name="horaXmlRecurso" type="xsd:time"/> <xsd:element name-"codigoRetorno"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="CF"/> <xsd:enumeration value="NC"/>
</xsd:restriction> </xsd:simpleType>
</xsd:element> </xsd:sequence> <xsd:attributeGroup ref-"mit:IdDocumento"/>
</xsd:complexType>
<!-- Tipo do Documento xmlResultadoRecurso — >
<xsd:complexType name="TipoXmlResultadoRecurso"> <xsd:sequence> <xsd:element name="recurso" minOccurs="1" maxOccurs^"unbounded"> <xsd:compiexType> <xsd:sequence> <xsd:element name-"codigoOrgaoTransitoInterposicao *
type="xsd:positivelnteger"/> <xsd:element name-"mimeroRecurso" type="xsd:long"/> <xsd:element name="dataConclusao" type="xsd:date"/> <xsd:element name="codigoOrgaoTransitoAit" type="xsd:positivelnteger"/ <xsd:element name="identificacaoAit" type="xsd:string"/> <xsd:element name="posicaoRecurso"> <xsd:simpleType>
Apêndice C - XML Schema para os Documentos de Dados do Modelo
<xsd:restriction base="xsd:string"> <xsd:enumeration value="C"/>
</xsd:restriction> </xsd:simpleType>
</xsd:element> <xsd:element name-"resultadoRecurso"> <xsd:simpleType> <xsd:restriction base-"xsd:string"> <xsd:enumeration valuer"P"/> <xsd:enumeration valuer"N"/>
</xsd:restriction> </xsd:simpleType>
</xsd:element> </xsd:sequence>
</xsd:complexType> </xsd:element >
</xsd:sequence> <xsd:attributeGroup ref="mit:IdDocumento"/>
</xsd:complexType>
<!-- Tipo do Documento xmlRecigoResultadoRecurso -->
<xsd: complexType name= "TipoXmlReciboRe.su! tadoRecurso" > <xsd: sequence^-<xsd:element name-"dataXmlResultadoRecurso" type="xsd:date"/> <xsd:element name="horaXmlResultadoRecurso" type="xsd:time"/> <xsd:element name-"codigoRetorno"> <xsd:simpieType> <xsd:restriction base~"xsd:string"> <xsd:enumeration value-"RC"/> <xsd:enumeration value="RN"/>
</xsd:restriction> </xsd:simple?ype>
</xsd: element •> </xsd: sequer.co <xsd:attribi~cCio^p ref="mit:IdDocumento"/>
</xsd:complex7ypc>
<! -- Definição do r.ipos simples -->
<xsd: simpleTypc r.arr.e- "Uf Brasil •> <xsd:restrictior. base ="xsd:string*> <xsd: enumera; :cr. vaiue= "AC " / > <xsd: enumera :;or. value= "AL" /> <xsd: enumera: :o:. value - "AM" / > <xsd: enumerat ior_ vaiue= "AP" / > <xsd:enumeration value="BA"/> <xsd:enumeration value="CE"/> <xsd:enumeratior. value-"DF"/> <xsd:enumeration va!ue="ES"/> <xsd: enum.erat ion vaiue-"GO"/> <xsd: enurr.erat ion value - "MA" /> <xsd:enumeration value="MG"/> <xsd:enumeration vaiue="MS"/> <xsd:enumeration vaiue-"MT"/> <xsd:enumeration value="PA"/> <xsd:enumeration value="PB"/> <xsd:enumeration value-"PE"/> <xsd:enumeration value="PI"/> <xsd:enumeration value="PR"/> <xsd:enumeration value-"RJ"/> <xsd:enumeration value-"RN"/> <xsd:enumerat ion value="RO"/> <xsd:enumeration value="RR"/> <xsd:enumeration value="RS"/> <xsd:enumeration value=°SC"/> <xsd:enumeration value="SE"/> <xsd:enumeration value="SP"/>
Apêndice C - X M L S c h e m a para os Documentos de Dados do Modelo 111
<xsd:enumeration value="TO"/> </xsd:restrictions
</xsd:simpleType>
<xsd:simpleType name="UnidadeMedida"> <xsd:restriction base ="xsd: string"> <xsd:enumeration value-"Km/h"/> <xsd: enumeration value="Kg"/> <xsd: enumeration value="Dg/1"/> <xsd:enumeration value-"g%"/> <xsd: enumeration value="Mg/l"/> </xsd: restriction>
</xsd:simpleType>
<!-- Definição de grupos de atributos --> *-
<xsd:attributeGroup name-"idDocumento"> <xsd:attribute name="data" type-"xsd:date" use="required"/> <xsd:attribute name="hora" type-"xsd:time" use="required"/>
</xsd:attributeGroup>
</xsd:schema>
Listagem C.I - Esquema do Modelo de Intercâmbio de Informações Infrações de Trânsito -MFUT.xsd
Apêndice C - X M L S c h e m a para os Documentos de D a d o s do Modelo 112
Apêndice D - XML Schema para o Pacote de
Transmissão
A Listagem D.l apresenta o XML Schema que define o pacote de transmissão
utilizado para enviar as solicitações para o processamento dos documentos XML nos
órgãos de trânsito.
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:pct="http://www.miiit.gov.br/PacoteMiiit" xmlns:mit="http://www.miiit.gov.br/Miiit" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocator="http://www.miiit.gov.br/Miiit Miiit.xsd" targetNamespace-"http://www.miiit.gov.br/PacoteMiiit" elementFormDefault="qualified" attributeFormDefault-"unqualified">
<xsd:element name-"Envelope" type;"pct:TipoEnvelope"/> <xsd:element name="Header" type="pct:TipoHeader"/> <xsd:element name-"Body" type;"pct:TipoBody"/> <xsd:element name="operação" type;"pct:TipoOperacao"/>
<xsd:complexType name="TipoEnvelope"> <xsd:sequence> <xsd:element ref ="pct:Header" minOccurs;"1" maxOccurs-"1"/> <xsd:element ref="pct:Body" minOccurs-"1" maxOccurs="1"/>
</xsd:sequence> </xsd:complexType>
<xsd:complexType name;"TipoHeader"> <xsd:sequence> <xsd:element name="destino"> <xsd:complexType> <xsd:sequence> <xsd:element name="codigoOrgaoTransitoDestino"
type-"xsd:positivelnteger"/> <xsd:element name="urlOrgaoTransitoDestino" type="xsd:anyURI"/>
</xsd:sequence> </xsd:complexType>
</xsd:element> <xsd:element name="origem"> <xsd:complexType> <xsd:sequence> <xsd:element name-"codigoOrgaoTransitoOrigem"
type^"xsd:positivelnteger"/> <xsd:element name="urlOrgaoTransitoOrigem" type="xsd:anyURI"/>
</xsd:sequencer </xsd:complexType>
</xsd:element> <xsd:element name="dataEnvio" type="xsd:date"/> <xsd:element name="horaEnvio" type="xsd:time"/>
</xsd:sequence> </xsd:complexType>
<xsd:complexType name-"TipoBody"> <xsd:sequence> <xsd:element ref="pct:operação" minOccurs-"1" maxOccurs="unbounded"/>
</xsd:sequence> </xsd:complexType >
<xsd:complexType name;"TipoOperacao">
Apêndice D - XML Schema para o Pacote de Transmissão
<xsd:choice> <xsd:element name-"obterVeiculos" minOccurs="0" maxOccurs^"1"
type-"xsd:anyType"/> <xsd:element name= nregistrarUfVeiculo" minOccurs="0" maxOccurs=:"l"
type="xsd:anyType"/> <xsd:element name-"incluirPlacas" minOccurs="0" maxOccurs-"1"
type="xsd:anyType"/> <xsd:element name="registrarConfirmacaoPlacas" minOccurs-"0" maxOccurs-"1"
type-"xsd:anyType"/> <xsd:element name="carregarAitExterno" minOccurs="0" maxOccurs="1"
type-"xsd:anyType"/> <xsd:element name-"registrarReciboAit" minOccurs="0" maxOccurs="1"
type-"xsd:anyType"/> <xsd:element name="registrarAitConsistido" minOccurs="0" maxOccurs="1"
type-"xsd:anyType"/> <xsd:element name-"registrarReciboAitConsistido" minOccurs-"0"
maxOccurs="1" type-"xsd:anyType"/> <xsd:element name="registrarNit" minOccurs^ 0" maxOccurs^"1"
type-"xsd:anyType"/> <xsd:element name-"registrarReciboNit" minOccurs-"0" maxOccurs="1"
type-"xsd:anyType"/> <xsd:element name="registarRecursosExternos" minOccurs="0" maxOccurs-"1"
type-"xsd:anyType"/> <xsd: element name=" registarReciboRecurso" minOccurs= " 0 " maxOccurs = -: ±"
type="xsd:anyType"/> <xsd:element name="registarResultadoRecurso" minOccurs -"0" maxOccurs-"1"
type="xsd:anyType" / > <xsd:element name="registarReciboResultadoRecurso" minOccurs-"0"
maxOccurs-"1" type="xsd:anyType"/> </xsd:choice>
</xsd:compiexType>
</xsd:schema>
Listagem D.l - Esquema do Pacote de Transmissão - PacoteM lllT.xsd
Apêndice D - X M L S c h e m a para o Pacote de Transmissão 114
Apêndice E - Códigos Fonte do Protótipo
Os códigos fonte dos programas que constituem o protótipo apresentado neste
trabalhos estão listados neste apêndice. Além disso, a DDL utilizada para criação das
tabelas no MS Access e o conteúdo das páginas HTML também estão especificados.
E.l - DDL para Criação das Tabelas no MS Access
create table Veiculo renavam placa codigoMarcaModelo ufVeiculo
int not null, varchar(lO) not null, int not null, varchar(2) not null.
codigoMunicipioVeiculo int not null, cor varchar(20 not null,
constraint pkVeiculo primary key (renavam));
create table AIT ( codigoOrgaoTransito identificacaoAit placaVeiculo datalnfracao horalnfracao codigolnfracao codigoMunicipioInfracao localInfração complementoLocalInfração renavam codigoMunicipioVeiculo ufVeiculo nomeCondut o r numeroCNHCondutor ufCNHCondutor nomelnfrator numeroCPFIr-f rat or numeroCGCInfrator enderecolnfrator nomeMunicipioInfrator descEquipamentoAfericao valorLimitePermitido valorMedicaoRealizada unidadeMedida codigoAgente codigoRetornoVeiculo dataXmlPlacas horaXjnl PI acas codigoOrgaoTransitoDestino dataExtracao horaExtracao dataReciboAit horaReciboAit situacaoAit constraint pkAit
int not null, varchar(15 not null, varchar(10) not null. date not null, time not null, int not null, int not null, varchar(50) not null, varchar(20), int, int, varchar(2), varchar(40 , varchar(11) , varchar(2), varchar(40) , varchar(11), varchar(15), varchar(50), varchar(30), varchar(30, numeric, numeric, varchar(10) , varchar(20) not nul1, varchar(2), date, t ime, int, date, time, date, time, varchar(2) not nu11,
primary key (codigoOrgaoTransito, identificacaoAit));
create table AitExterno ( codigoOrgaoTransito identi ficacaoAit placaVeiculo datalnfracao
int not null, varchar(15) not null, varchar(10) not nul1, date not null,
Acèndice E - Códigos Fonte do Protótipo 115
horalnfracao codigolnfracao codigoMunicipioInfracao localInfracao complementoLocalInfracao renavam codigoMunicipioVeiculo ufVeiculo nomeCondutor numeroCNHCondutor ufCNHCondutor nomelnfrator numeroCPFInfrator numeroCGCInfrator enderecolnfrator nomeMunicipiolnfrator descEquipaitientoAf ericao valorLimitePermitido valorHedicaoReali zada unidadeMedida codigoAgente codigoRetornoVe i cu1o dataXmlAit horaXmlAit dataConsistencia horaConsistencia dataXmlAitConsistido horaXmlAitConsistido situacaoAitExterno indResultadoCons ist ene i a
time not null, int not null, int not null, varchar(50) not null, varchar(20), int, int, varchar(2), varchar(40), varchar(11), varchar(2), varchar(40), varchar(11), varchar(15), varchar(50), varchar(30), varchar(30), numeric, numeric, varchar(10), varchar(20) not null, varchar(2), date, time, date, time, date, time, varchar(2) not nul1, varchar(2) not nul1,
constraint pkAitExterno primary key (codigoOrgaoTransito, identificacaoAit));
create table OrgaoTransito ( codigoOrgaoTransito nomeOrgaoTransito classificacaoOrgaoTransito ufOrgaoTransito codigoMunicipioOrgaoTransito int, urlOrgaoTransito varchar(200 not null, constraint pkOrgaoTransito
primary key (codigoOrgaoTransito));
int not null, varchar(30) not null, varchar(l) not null, varchar(2) not nul1,
Listagem E.1 - DDL das tabelas utilizadas pelo Prototipo
E.2 - Códigos Fonte dos Programas Java package gov.miiit.orgaoAutuador;
import gov.miiit.tipos.*; import gov.miiit.OrgaoTransito.*; import j ava.io.*; import j ava.ut iI.*; import java.uti 1.Date; import j ava.sql.Time; import j ava.text.*; import j ava.sql.*;
import javax.xml.parsers.SAXParser; import javax.xml.parsers.SAXParserFactory; import javax .xml .parsers . ParserConf igurat ioriExcept ion; import org.xml.sax.SAXException; import org.xml.sax.XMLReader; import org.xml.sax.InputSource; import org. xml. sax. Attributes,-import org. xml. sax. helpers . Def au It Handler ,-
public class Ait
Apêndice E - Códigos Fonte do Protótipo
Ait ( int codigoOrgaoTrans ito; //numérico6> String identificacaoAit; //carácter15) String placaVeiculo; //carácter(10) long renavam; //numérico(9) short codigoMunicipioVeiculo; //numérico(4) String ufVeiculo; //carácter(2) String nomeCondutor; //caracter(40) long numeroCNHCondutor; //numérico(11) String ufCNHCondutor; //carácter(2 J String nomelnfrator; //carácter(40 long numeroCPFInfrator; //numérico(11) String numeroCGCInfrator; //carácter15) String enderecolnfrator; //carácter(50 String nomeMunicipioInfrator; //carácter(30) String locallnfracao; //carácter(50) String complementoLocallnfracao; //carácter(2 0) Date datalnfracao; //data Time horalnfracao; //hora short codigoMunicipioInfracao; //numérico(4) short codigolnfracao; //numérico(4) String descEquipamentoAfericao; //carácter(30) float valorLimitePermitido; //numérico(7,2) float valorMedicaoRealizada; //numérico(7,2) String unidadeMedida; //carácter(10) String codigoAgente; //carácter(20) String codigoRetornoVeiculo; //carácter(2) Date dataXmlPlacas; //data Time horaXmlPlacas; //hora short codigoOrgaoTransitoDestino; //numérico(4) Date dataXmlAit; //data Time horaXmlAit; //hora Date dataReciboAit; //data Time horaReciboAit; //hora String situacaoñit; //carácter(2) String indResultadoConsistencia; //carácter(2)
)
// Este método gera o documento xmlPlacas public static String veicuioSemldentificacao ()
//* Define variáveis boolean erro = raise; // Informa se um erro foi detectado. String MensagemErro = ""; //Guarda a descrição da mensagem de erro, caso ela ocorra. Connection conexão = null; //Classe que estabelece uma conexão com o banco de dados. String linha = " ; String NomeArquivoTmp = "NENHUM";
//* Define os formatos e as variáveis que correspondem à data e à hora atuais. SimpleDateFormat formatoData = new SimpleDateFormat (•yyyy-MM-dd'); SimpleDateFormat formatoHora = new SimpleDateFormat ("HH:mm:ss")• Date dataHoraHoje = new Dated ; String dataHoje = formatoData.format(dataHoraHoje); String horaAgora - formatoHora.format(dataHoraHoje); try
// Define a conexão com o banco de dados. String banco = "jdbc:odbc:miiit"; // Utiliza o driver ODBC "miiit" String driver = "sun.jdbc.odbc.JdbcOdbcDriver'; // Driver JDBC oferecido com
// o SDK 1.3 Class.forName(driver); conexão = DriverManager.getConnection (banco,"',""); // Estabelece a conexão // Altera os valores dos campos dataXmlPlacas e horaXmlPlacas // para os AITs selecionados Statement comandoUpdate = conexão.createStatement();//Representa uma instrução SQL int regsAlterados = comandoUpdate.executeUpdate(" update Ait " +
• set dataXmlPlacas = '"+dataHoje+"', * + " horaXmlPlacas = '•+horaAgora+"1, •+
codigoRetornoVeiculo = 'EH' '+ " where codigoRetornoVeiculo = 'NP1 "+ • and ufVeiculc is null");
comandoUpdate.close(); // Testa se foram encontrados registros if (regsAlterados > 0)
// Pesquisa AITs cujos veiculos devam ser verificados no orgao central Statement query = conexão.createStatement); // representa um instrução SQL ResultSet rs = query.executeQuery(
Apêndice E - Códigos Fonte do Protótipo 117
•select * * + •from Ait " + •where dataXmlPlacas = DateValue('"+dataHoje+"') "+•• •and horaXmlPlacas - TimeValue('"+horaAgora+•'J");
// Testa sè há registros retornados if (rs.next())
II Cria o arquivo temporário para xmlPlacas File xmlPlacasTmp = File.createTempFile
"xmlPlacas',".tmp",ParametrosMiiit.DIR_TEMP); BúfferedWriter bufPlacas = new BufferedWriter (new FileWriter(xmlPlacasTmp)); NomeArquivoTmp = xmlPlacasTitip. getName () ; // Gera o documento xmlPlacas U n h a = "<mit:docXmlPlacas data=\""+dataHoje+•\" • +
"aora=\""+horaAgora+"\• "+ "xtnlns :mit=\ "http: //www-miiit - gov .br/MiiitV " +
"xmlns:xsi=\"http://www.w3. org/2 001/XMLSchema--instance\" "+ "xsi:schemaLocation=\•http://www.miiit.gov.br/Miiit "+ ParametrosMi i it.URL_MIIIT+"\">";
bufPlacas .write (linha, 0, linha. length () ) ;• bufPlacas.newLine £) ; linha = "<mit:placa>"+rs.getString"placaVeiculo")+•</mit:placa>'; bufPlacas.write(linha. O, linha.length()); bufPlacas.newLine(); while (rs.nexti))
linha = "<mit :placa>"+rs. getstring "placaVeiculo".) +"</mit :placa>"; bufPlacas.writelinha, 0, linha.length); bufPlacas.newLine(),-
3 linha = "</mit:dacXmlPlacas>*; bufPlacas ,write.(linha. D, linha.length() ) ; bufPiacas .newLine () ; bufPlacas.Close();
else System.out.println("Não foram retornados registros..");
query.close() ;
// Trata as exceções que possam ocorrer ] catch (SQLException sqie) erro = true; MensagemEr.ro = sale.toString); System.out .print-In (."Ait .veiculoSemldentif icao: Erro> no SQL.") ; System.out.printIn("Ait.veiculoSemldentificao: "+MensagemErro);
] cat;oh [ lOExcepti on ioe) erro - true; Mensager£"rrc ; oe. toString ( ; System, out . p.--"i 1?. i "Ait .veiculoSemldentif icao: Erro de I/O.1) ; System.out.pr.ni-n!"Ait-veiculoSemldentificao: "+MensagemErro>;
] catch (C-asü!.. -- r òundException cie) erro = true; Mensageiríri-c cle.toString () ; System.out.pr,r.tIn("Ait.veiculoSemldentificao: Erro no driver de conexão."); System, out.. pr . ~„r. ("Ait .veiculoSemldentif icao: "+MensagemErro).;
] finally try conexão. close CJ ;
catch (SQLÍxcepLion sqle) erro = true; MensagemErro - sqle-toString(); System.out.println("Ait.veiculoSemldentificao: Erro no encerramento da
conexão."); System.out.println( "Ai.t.veiculoSemldentificao: "+MensagemErro) ;
) i f (erro)
return "ERRO"; else
return NomeArquivoTmp; // final do método veiculoSemldentif icacao ().
// Processa o documento xmlVeiculo public static boolean registrarüfVeiculo (String xmlVeiculos)
//* Define variáveis boolean erro = false; //. Informa se um erro foi detectado. String mensagemErro = ""; // Descrição da mensagem de erro., caso e l a ocorra. Connection conexão - null; //Classe que estabelece uma conexão com o banco de dados.
//* Define os formatos e as variáveis que correspondem à data e à hora atuais. SimpleDateFormat formatoData = hew SimpleDateFormat "yyyy-MM-dd");
SimpleDateFormat formatoHora = new SimpleDateFormat ("HH:mm:ss"); Pate dataHoraHoje = new Date.O; String dataHoje = formatoData. format (dataHpraHoje). ;
Apêndice E - Códigos Fonte do Protótipo 118
String horaAgora = formatc-Hora - format (dataHoraHoj e) ; try
// // Define a conexão com o banco de dados. String banco = "jdbc:odfoc:miiit"; // Utiliza o driver ODBC "miiit" String driver = "sun.jdbc.odbc.JdbcOdbcDriver•; // Driver JDBC oferecido com
// o SDK 1.3 Class.forName(driver); // cria o driver conexão = DriverManager.getConnection (banco,1",""; // Estabelece a conexão conexão.setAutoCommit(false);
// Define o parser do documento xmlVeiculos recebido como parâmetro // utilizando a API SAX SAXParserFactory docFactory = SAXParserFactory.newlnstance(); docFactory.setNamespaceAware(true); docFactory.setValidating(true); SAXParser docSAXParser = docFactory.newSAXParser); XMLReader parserXmlVeiculos = docSAXParser.getXMLReader((; parserXmlVeiculos.setFeature(*http://xml.org/sax/features/namespaces", true); parserXmlVeiculos.setFeature('http://xml.org/sax/features/validation', true); parserXmlVeiculos.setFeature
("http://apache.org/xml/features/validation/schema", true); parserXmlVeiculos.setFeature
("http://apache.org/xml/features/validation/warn-on-undeclared-elemdef",true) parserXmlVeiculos.setFeature
("http://apache.org/xml/features/validation/schema-full-checking", true); // Define a classe gue tratará os erros do parser ErrorChecker errors = new ErrorChecker(); parserXmlVeiculos.setErrorHandler(errors); // Define a classe que trataré os eventos do SAX ParserSAXRegVeiculo processaSax = new ParserSAXRegVeiculo(conexão); parserXmlVeiculos.setContentHandler(processaSax); // Realiza o parser parserXmlVeiculos.parse(xmlVeiculos); erro = errors.getStatus(); if (erro)
conexão.rollback); else
conexão.commit(); // Trata as exceções que possam ocorrer catch (SQLException sqle) erro = true,-mensagemErro = sqle.toString() ; System.out.println(*Ait.registrarUfVeiculo: Erro no SQL.'); System.out.printIn("Ait.registrarUfVeiculo: "+mensagemErro);
catch (IOException ioe) erro = true,-mensagemErro = ioe.toString); System.out.printIn("Ait.registrarUfVeiculo; Erro de 1/0.'); System, out. print In ("Ait. registrarUfVeiculo; •+mensagemErro) ,-
catch (ClassNotFoundException cle) erro = true; mensagemErro = cle.toString(); System.out.printIn("Ait.registrarUfVeiculo: Classe não encontrada.'); System.out.printIn("Ait.registrarUfVeiculo: "+mensagemErro);
; catch (ParserConfigurationException pcf) erro = true; mensagemErro = pcf.toString(); System.out.println("Ait.registrarUfVeiculo: Erro de configuração do Parser.">; System.out.println("Ait.registrarUfVeiculo: "+mensagemErro);
catch (SAXException saxe) erro = true; mensagemErro = saxe.toString(); System.out.println("Ait.registrarUfVeiculo: Exceção geral do SAX."); System.out.println("Ait.registrarUfVeiculo: "+mensagemErro;
finally ( try
conexão.close(); catch (SQLException sqle) erro = true; mensagemErro = sqle.toString(); System.out.println("Ait.registrarUfVeiculo: Erro no encerramento da conexão,"); System.out.println("Ait.registrarUfVeiculo: "+mensagemErro);
) finally return !error
Apêndice E - Códigos Fonte do Protótipo 1
) // final do método registrarUfVeiculo()
// Este método gera um documento xmlAit para cada UF que possua AIT correspondente public static Stringtin obterAitsNaoEnviados()
//* Define variáveis boolean erro = false; // Informa se um erro foi detectado. String MensagemErro = ""; //Guarda a descrição da mensagem de erro, caso ela ocorra. Connection conexão - null; //Classe que estabelece uma conexão com o banco de dados. String linha = ""; String valorCampo = '*; int numArquivo = 0; String [][) NomeArquivoTmp = new String(ParametrosMiiit.QTE_UF][2]; NomeArquivoTmpfO][0] = "NENHUM";
//* Define os formatos e as variáveis que correspondem à data e à hora atuais. SimpleDateFormat formatoData = new SimpleDateFormat ('yyyy-MM-dd"); SimpleDateFormat formatoHora = new SimpleDateFormat ("HH:mm:ss"); Date dataHoraHoje = new Date O; String dataHoje = formatoData.format(dataHoraHoje); String horaAgora - formatoHora.format(dataHoraHoje); try
// Define a conexão com o banco de dados. String banco = "jdbc:odbc:miiit'; // Utiliza o driver ODBC "miiit" String driver = "sun.jdbc.odbc.JdbcOdbcDriver'; // Driver JDBC oferecido com
// o SDK 1.3 Class.forName(driver); conexão = DriverManager.getConnection (banco,**,""); // Estabelece a conexão // Altera os valores dos campos dataExtracao e horaExtracao // para os AITs selecionados Statement comandoUpdate = conexão.createStatement(;//Representa uma instrução SQL int regsAlterados = comandoUpdate.executeUpdate(
• update Ait * + • set dataExtracao = '*+dataHoje+"' , "+
horaExtracao = '"+horaAgora+"', "+ situacaoAIT = 1EN' "+
" where situacaoAIT = 'NE' '+ • and codigoRetornoVeiculo - 'VE' " + " and ufVeiculo is not null*);
comandoUpdate.close); // Testa se algum registro foi alterado i f (regsAlterados > 0) (
// Pesquisa AITs cujas veículos devam ser verificados no orgao central Statement query = conexão.createStatement(); // representa um instrução SQL ResultSet rs - query.executeQuery(
"select * "+ "from Ait "+ 'where dataExtracao = DateValue(1"+dataHoje+"') "+ "and horaExtracao = TimeValue('1+horaAgora+"') "+ "order by ufVeiculo");
// Testa se há registros retornados if (rs.next (!) boolean eof = false; boolean mudouUf = false; String ufAtual - rs.getString("ufVeiculo"); NomeArquivaTmp[numArqtiivo] [I] = ufAtual; String novaUfVeiculo = ufAtual; numArquivo = 0; while (!eof)
// Cria o arquivo temporário para xmlAit da UF que está sendo processada File xmlAitTmp = File.createTempFile
("xmlAit"+ufAtual,".tmp",ParametrosMiiit.DIR_TEMP); BufferedWriter bufAit = new BufferedWriter (new FileWriter(xmlAitTmp)(; NomeArquivoTmp[numArquivo][0] = xmlAitTmp.getName(); // Gera o documento xmlAit para a UF que está sendo processada linha = "<:mit:docXmlAi t data = \ •" +dataHoje+ • \• " +
*hora = \""+horaAgora+"\" " + * xmlns:mit = \"http://www.miiit.gov.br/Miiit\* • + "xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\* "+ "xsi:schemaLocation=\"http;//www.mii it.gov.br/Miiit " + ParametrosMiiit,URL_MIIIT+"\">";
bufAit.write(linha, 0, linha.length(I); bufAit.newLine(); geraCampos(rs, bufAit, ufAtual); mudouUf = false; do
if !rs.next()) novaUfVeiculo = rs.getString("ufVeiculo"J;
Aparecer E - Códigos Fonte do Protótipo 120
if (ufAtual.equals(novaüfVeiculo)) geraCampos(rs, bufAit, ufAtual);
else mudouijf = true; ufAtual = novaUfVeiculo; numArquivo++; NomeArquivofmp[numArguivo][1] = ufAtual;
else eof = true;
while ((ImudouUf) && (!eof)); linha = " </tnit: docXmlAit>" ; bufAit.write(linha, 0, linha.length)); bufAit.newLine(); bufAit.close();
else System.out.printIn("A query não retornou registros.');
query.close();
// Trata as exceções que possam ocorrer ) catch (SQLException sqle) erro = true; MensagemErro - sqle.toString(); System.out.println"Ait.obterAitsNaoEnviados: Erro no SQL."); System.out.println("Ait.obterAitsNaoEnviados: *+MensagemErro),-
catch (IOExcept i on ioe) ( erro - true; MensagemErro = ioe.toString(); System.out.println("Ait.obterAitsNaoEnviados: Erro de I/O."); System.out.println("Ait.obterAitsNaoEnviados: '+MensagemErro);
catch (ClassNotFoundException cle) ( errc = true; KensagemErro - cle. toString ( ,-System.out.print In("Ait.obterAitsNaoEnviados: Erro no driver de conexão."); System.out.print In("Ait.obterAitsNaoEnviados: "+MensagemErro;
finally try
conexão.close); catch (SQLException sqle) erro - true; MensagemErro = sqle.toString(); System.out.println("Ait.obterAitsNaoEnviados: Erro no encerramento da
conexão."]; System..out.println("Ait.obterAitsNaoEnviados: •+MensagemErro);
if (erro) NomeArquivcTmp[0][0] = "ERRO";
return NomeArquivoTmp; // final do método obterAitsNaoEnviados
private static void geraCampos(ResultSet rs, BufferedWriter bufAit, String ufVeiculo)
String linha; String vaiorCampc; boolean erro; String mensagemErro; SimpleDateFormat formatoData = new SimpleDateFormat ("yyyy-MM-dd") ,-try
linha = "<nit:aiti>"; bufAit.write(linha, 0, 1inha.length()); bufAit.newLine(; linha - "<mit:codigoOrgaoTransito>"+rs.getString('codigoOrgaoTransito"+
"</mit:codigoOrgaoTransito>"; bufAit.write(linha, 0, linha.length()); bufAit-newLine(); linha = "<mit:identificacaoAit>"+rs.getString(*identificacaoAit")+
"</mit:identificacaoAit>"; bufAit.write(1inha, 0, linha.length()J r bufAit.newLine(); linha = "<mit:piacaVeiculo>"+rs.getString("placaVeiculo"+"</mit:placaVeiculo>"; bufAit.write(linha, 0, linha.length)); bufAit.newLine); linha = "<mit:renavam>"+rs.getString("renavam")+"</mit:renavam>"; bufAit.write(1inha, 0, linha,length)); bufAit.newLine(); 1 inha = " <mit: codigoMunicipioVeiculo" +rs . getString (n codigoMunicipioVeiculo") +
"</mi t:codigoMunicipioVeicuio>"; bufAit.write(linha, 0, linha.length()); bufAit.newLine(); linha = "<mit: ufVeiculo" +u£Veiculo-r" </mit: ufVeiculo>" ; bufAit.write(linha, 0, linha.length)); bufAit.newLine();
Apêndice E - Códigos Fonte do Protótipo 121
valorCampo = rs.getString("nomeCondutor•); if (valorCampo != null) linha = "<mit:nomeCondutor>•+valorCampo+"</mit:nomeCondutor>"; bufAit.write(linha, 0, linha.length()); bufAit.newLine();
valorCampo = rs.getString("numeroCNHCondutor"); if (valorCampo != null)
linha = "<mit:numeroCNHCondutor>'+valorCampo+"</mit:numeroCNHCondutor>'; bufAit.write(linha, 0, linha.length) ) ; bufAit.newLine();
valorCampo = rs.getString("ufCNHCondutor"); if (valorCampo != null)
linha = *<mit:ufCímCondutor>"+valorCampo+'</mit:ufCNHCondutor>" ; buf Ai t .write (linha, 0, linha. length () ) ,- buf Ait .newLine () ;
valorCampo = rs.getString("nomelnfrator"); if (valorCampo != null)
linha = "<mit:nomelnfrator>° +valorCampo+"</mit:nomeInfrator>"; bufAit.write(linha, 0, linha.length()); bufAit.newLine();
valorCampo = rs.getString("numeroCPFlnfrator"); if (valorCampo != null)
linha = "<mit:numeroCPFlnfrator>"+valorCampo+"</mit:numeroCPFlnfrator>'; buf Ait .write (linha, 0, linha, length () ) ; buf Ait .newLine () ,-
) valorCampo = rs.getString("numeroCGCInfrator"; if (valorCampo != null)
linha = "<rtiit:numeroCGCInfrator>"+valorCampo+"</mit:numeroCGCInfrator>"; bufAit.write(linha, 0, linha.length()); bufAit.newLine(;
valorCampo = rs.getString("enderecolnfrator"); if (valorCampo •= null)
linha = "<mit:enderecolnfrator>"+valorCampo+"</mit:enderecolnfrator>"; bufAit.write(linha, 0, linha.length(); bufAit.newLine();
valorCampo = rs.getString("nomeMunicipioInfrator"); if (valorCampo != null) linha = "<mit:nomeMunicipioInfrator>"+valorCampo+'</mit:nomeMunicipioInfrator>•; bufAit.write(linha, 0, linha.length()); bufAit.newLine();
) linha = •<mit:localInfracao"+rs.getString('localInfração")+
"</mit:localInfracao>"; buf Ait. write (1 inha, 0, linha, length () í ,- buf Ait. newLine ) ,-valorCampo - rs.getString("complementoLocalInfracao"); if (valorCampo != null) linha = "<mit:complementoLocalInfracao>"+valorCampo+
"</mit: complementoLocal Inf racao" ; bufAit.write(linha, 0, linha.length()); bufAit.newLine();
linha - "<mit:datalnfracao>"+formatoData.format(rs.getDate("dataInfração"))+
"</mit: datalnf racao" ; bufAit.write(linha, 0, linha.length()); bufAit.newLine(); linha = " <mit: hora Inf racao" +rs . get Time ("hora Inf racao") + "</mit: hora Inf racao>" ; buf Ait .write (linha, 0, linha. length () ) ,- buf Ait. newLine ( ; linha - "<mit:codigoMunicipiolnfracao>"+rs.getString("codigoMunicipioInfracao"> +
•</mit: codigoMunicipiolnf racao" ,-bufAit.write(linha, 0, linha.length()); bufAit.newLine(); linha = "<mit:codigolnfracao>"+rs.getString("codigolnfracao")+
"</mit:codigolnfracao>"; bufAit.write(linha, 0, linha.length()); bufAit.newLine<); valorCampo - rs.getString("descEguipamentoAfericao"); if (valorCampo != null)
linha = " <mit: descEguipamentoAf ericao" +valorCampo+ "</mit:descEguipamentoAfericao>";
bufAit.write(1inha, 0, linha.length()); bufAit.newLine(); valorCampo = rs.getString("valorLimitePermitido"); if (valorCampo != null)
linha = "<mit:vaíorLimitePermit ido"+valorCampo+ '</mit:valorLimitePermitido>"; bufAit.write(1inha, 0, linha.length)); bufAit.newLine();
) valorCampo = rs.getString"valorMedicaoRealizada"); if (valorCampo 1- null)
linha - "<mit: valorMedicaoRealizada>" +valorCampo + "</mit: valorMedicaoRealizada>" ,-buf Ait .write (1 inha, 0, linha . length () ) ; buf Ait. newLine () ,-
) valorCampo = rs.getStringt"unidadeMedida");
Apêndice E - Códigos Fonte do Protótipo 122
if valorCampo != null) linha = '<mit:unidadeMedida>"+valorCampo+"</mit;unidadeMedida>"; bufAit.writedinha, 0 , linha.lengthf) ) ,- buf Ait .newLine ) ;
linha = •<mit:codigoAgente>''+rs .getString •codigoAgente' +" </mit: codigoAgente>" ; bufAit.write(linha, 0 , linha.length()); bufAit.newLine(); linha = "</mit:ait>"; bufAit.write(linha, 0, linha.length()); bufAit.newLine();
catch lOException ioe) ( erro = true; mensagemErro = ioe.toString(); System.out.printIn"Ait.geraCampos: Erro de I/O."); System.out.printIn<"Ait.geraCampos: •+mensagemErro Í;
catch (SQLException sqle) erro = true; mensagemErro = sqle.toString(); System.out.println("Ait.geraCampos: Erro no SQL."); System.out.printIn("Ait.geraCampos: "+mensagemErro);
// final do método geraCampos
public static boolean registrarReciboAit String xmlReciboAit) //* Define variáveis boolean erro = false; // Informa se um erro foi detectado. String mensagemErro = *"; // Descrição da mensagem de erro, caso ela ocorra. Connection conexão = null; //Classe que estabelece uma conexão com o banco de dados.
//* Define os formatos e as variáveis que correspondem à data e à hora atuais. SimpleDateFormat formatoData = new SimpleDateFormat 'yyyy-MM-dd") ,-SimpleDateFormat formatoHora = new SimpleDateFormat *HH:mm:ss"); Date dataHoraHoje = new Date); String dataHoje = formatoData.format(dataHoraHoje); String horaAgora = formatoHora.format(dataHoraHoje); try
// Define a conexão com o banco de dados. String banco = "jdbc:odbc:miiit•; // Utiliza o driver ODBC "miiit" String driver = "sun.jdbc.odbc.JdbcOdbcDriver"; // Driver JDBC oferecido com
// o SDK 1.3 Class.forName(driver); // cria o driver conexão = DriverManager.getConnection banco,"",""); // Estabelece a conexão conexão.setAutoCommit(false);
// Define o parser do documento xmlReciboAit recebido como parâmetro // utilizando a API SAX SAXParserFactory docFactory = SAXParserFactory.newlnstance(); docFactory.setNamespaceAware(true); docFactory.setValidating(true); SAXParser docSAXParser = docFactory.newSAXParser(); XMLReader parserXmlReciboAit = docSAXParser.getXMLReader); parserXmlReciboAit.setFeature("http://xml.org/sax/features/namespaces", true); parserXmlReciboAit.setFeature"http://xml.org/sax/features/validation", true); parserXmlReciboAit.setFeature
("http://apache.org/xml/features/validation/schema", true)• parserXmlReciboAit.setFeature
!"http://apache.org/xml/features/validation/warn-on-undeclared-elemdef",true); parserXmlReciboAit.setFeature
("http://apache.org/xml/features/validation/schema-full-checking", true); // Define a classe que tratará os erros do parser ErrorChecker errors = new ErrorChecker); parserXmlReciboAit.setErrorHandler(errors); // Define a classe que tratará os eventos do SAX ParserSAXReciboAit processaSax = new ParserSAXReciboAit(conexão); parserXmlReciboAit.setContentHandler(processaSax); // Realiza o parser parserXmlReciboAit.parse(xmlReciboAit); erro = errors.getstatus(); if (erro) conexão. rollback () ,-
else conexão.commit();
// Trata as exceções que possam ocorrer catch (SQLException sqle)
erro = true; mensagemErro = sqle. toString (! ,-System.out.println("Ait.registrarReciboAit: Erro no SQL.");
Apêndice E - Códigos Fonte do Protótipo 123
System.out.printIn'Ait.registrarReciboAit: "+mensagemErro); ) catch (IOException ioe) erro = true; mensagemErro - ioe.toString(); System.out.printIn("Ait.registrarReciboAit: Erro de I/O."); System.out.printIn('Ait.registrarReciboAit: '+mensagemErro);
catch (ClassNotFoundException cle) erro = true; mensagemErro = cle.toString); System.out.printIn("Ait.registrarReciboAit: Classe não encontrada."); System.out.printIn('Ait.registrarReciboAit: "tmensagemErro);
catch (ParserConfigurationException pcf) erro = true; mensagemErro = pcf.toString(); System.out-println("Ait.registrarReciboAit: Erro de configuração do Parser."); System.out.println(•Ait.registrarReciboAit: "+mensagemErro);
catch (SAXException saxe) erro - true; mensagemErro ~ saxe.toString(); System.out.printIn"Ait.registrarReciboAit: Exceção geral do SAX -"!; System.out.println("Ait.registrarReciboAit: "+mensagemErro);
finally try
conexão.close); ) catch (SQLException sqle) erro = true; mensagemErro - sqle.toString(); System.out.println("Ait.registrarReciboAit: Erro no encerramento da conexão."); System.out.println("Ait.registrarReciboAit: '+mensagemErro);
finally if (erro) return false;
else return true;
)
// final do método registrarReciboAit()
public static void registrarAitConsistido (docXmlAitConsistido xmlAitConsistido)
// Classe que manipulara os eventos gerados pelo parser SAX do documento xmlVeiculos class ParserSAXRegVeiculo extends DefaultHandler protected static Connection conexao; protected static String placa; protected static String renavam; protected static String codigoMarcaModelo; protected static String codigoMunicipioVeiculo; protected static String ufveiculo,-protected static String cor; protected static String codigoRetorno; protected static int status;
ParserSAXRegVei cu1o (Connec t ion conn) conexao = conn; piaca = " "; renavam = " "; codigoMarcaModelo = " "; codigoMunicipioVeiculo = • "; ufVeiculo - " '; cor = " "; codigoRetorno = " " ,-status = 0;
public void startEiement(String uri. String localName, String gName, Attributes attr)
// Verifica se o elemento atual e <placa> i f (localName.equals("placa")) status = 1;
else if (localName.equals("renavam")) Status = 2;
else if (localName.equals("codigoMarcaModelo")) status = 3;
else if (localName.equals("codigoMunicipioVeiculo"]) status = 4;
Apéndice E - Códigos Fonte do Protótipo 124
else if (localName.equals!"ufVeiculo")) status = 5;
else if localName.equals("cor")) status = 6;
else if localName.equals("codigoRetorno")) status = 7;
else status = 0;
public void characters chart] ch, int inicio, int tarnanho) switch(status)
case 1: placa = new String(ch, inicio, tamanho); break;
case 2: renavam = new String(ch, inicio, tamanho); break;
case 3: codigoMarcaModelo = new Stringfch, inicio, tamanho); break;
case 4: codigoMunicipioVeiculo = new String(ch, inicio, tamanho break;
case 5: ufVeiculo = new Stringích, Inicio, tamanho); break,-
case 6: cor = new String(ch, inicio, tamanho); break;
case 7: codigoRetorno = new String(ch, inicio, tamanho); break;
) status '= 0;
public void endElement(String url. String localName, String qName) int regsAlterados = 0; if (localName.equals("veiculo"))
try //Representa uma instrução SQL Statement comando update = conexão. createStatement () ; if (codigoFietorno. equals "VE" ) ) regsAlterados = comandoUpdate.executeUpdate
" update Ait " + " set renavam = "+renavain+", " 4 " codigoMarcaModelo = "+codigoMarcaModelo+", "+ " codigoMunicipioVeiculo = "+codigOMunicipioVeicuio+", •+ " ufVeiculo = '"+ufVeiculo+"', "+ " cor = '"+cor+", " + " codigoRetornoVeiculo = '"+CodigoRetorno+"', * + " situacaoAit = 'NE' "+ " where placaVeiculo = '"+placa+"' • + " and codigoRetornoVeiculo = 'EN'");
else i'i !codigoRetorno.equals ("NE") ) regsAlterüdos = comandoUpdate.executeUpdate(
• update Ait " 4-" set codigoRetornoVeiculo = '"+codigoRetorno+"'"+ " where placaVeiculo = '"+placa+"' "4 " and codigoRetornoVeiculo -= "EN' " ) ;
Í comandoUpdate.close(); // Testa se foram encontrados registros if (regsAlterados <= 0) System.out-println ("Veiculo "+placa+" não foi alterado.");
catch (SQLException sqle) . System.out.println(iparserSAXRegVeiculo.endElement: Erro no SQL."; System, out.printIn("ParserSAXRegVeiculo.endElement: "+5516.toString());
)
Í Í
// Classe que manipulará os eventos gerados pelo parser SAX do documento xmlReciboAit class ParserSAXReciboAit extends DefaultHandler protected static Connection conexão; protected static String dataReciboAit ,-protected static String horaReciboAit; protected static String dataXmlAit; protected static String horaXmlAit; protected static String codigoRetorno; protected static int status;
A p ê n d i c e E - Códigos Fonte do Protótipo 125
ParserSAXReciboAit (Connection conn) conexao = conn; status = 0;
public void startElement(String uri. String localNante, String qName, Attributes attr)
// Verifies se o elemento atual e <placa> if (localName.eguals"docXmlReciboAit") dataReciboAit = attr.getValue("data"); horaReciboAit = attr.getValue("horaB);
else if (localName.equals("dataXmlAit*)) status = 1;
else if localName.equals("horaXmlAit" status = 2;
else if (localName.equals("codigoRetorno")) status = 3;
else status = 0 ;
public void characters (char!] ch, int inicio, int tamanho) switch(status)
case 1: dataXmlAit = new String(ch, inicio, tamanho); break;
case 2: horaXmlAit = new Stringfch, inicio, tamanho); break;
case 3: codigoRetorno - new String(ch, inicio, tamanho); break;
; status = 0;
1 public void endElement(String uri, String localName, String gName)
int regsAlterados = 0 ; if (localName.equals("docXmlReciboAit") try
// Representa uma instrucao SQL Statement comandoUpdate = conexao.createStatement(); regsAlterados = comandoUpdate.executeUpdate(
* update Ait " + • set situacaoAit = '"+codigoRetorno+"1, •+•
dataReciboAit = '"+dataReciboAit+"', "+ " horaReciboAit - '"+horaReciboAit+"' '+ ' where dataExtracao = DateValue(1"+dataXmlAit+"') " + • and horaExtracao = TimeValue ( 1 " +horaXmlAit-i-" 1 ) *
comandoUpdate.close(); // Testa se foram encontrados registros if (regsAlterados <= 0) System.out.printIn ("Ait's nao foram alterados.");
) catch (SQLException sqle) System.out.printIn("ParserSAXReciboAit.endElement: Erro no SQL.*); System.out.printIn("ParserSAXReciboAit.endElement: "+sqle.toString!));
)
Listagem E.2 - Classes Ait, ParserSAXRegVeiculo e ParserSAXReciboAit (arquivo Aitjava)
package gov.miiit.orgaoConveniado;
import gov. miiit. orgaoTransito. * ,-import gov.miiit.tipos.*; import j ava.io.*; import j ava.ut i1.*; import Java.util.Date; import j ava.sql.Time; import Java.sql.*; import Java.text.*;
import javax.xml.parsers.SAXParser; import javax.xml.parsers.SAXParserFactory; import javax.xml .parsers . ParserConf.igurat ionExcept ion; import org.xml.sax.SAXException; import org.xml.sax.XMLReader; import org.xml.sax.InputSource,-
Apêndice E - Códigos Fonte do Protótipo 1
import org. xml. sax. Attributes,-
import org.xml.sax.helpers.DefaultHandler;
public class AitExterno
AitExterno ) int codigoOrgaoTransito,- / / numérico (6) String identificaçãoAit; //caracter(15) String placaVeiculo; //caracter(10) long renavam; //numérico(9) short codigoMunicipioVeiculo; //numérico(4) String ufVeiculo; //caracter(2 String nomeCondutor; //caracter(4 0) long numeroCNHCondutor; //numérico(11Í String ufCNHCondutor; //caracter(2) String nomeInfrator; //caracter(4 0) long numeroCPFInfrator; //numérico(11) String numeroCGCInfrator; //caracter(15) String enderecolnfrator; //caracter(50) St ring nomeMunicipioInfrator; //caracter(30) String locallnfracao; //caracter(50) String complementoLocalInfração; //caracter(2 0) Date datalnfracao; //data Time horalnfracaor //hora short codigoMunicipioInfracao; //numérico(4) short códigoInfração; //numérico(4) St ring descEquipamentoAferi cao; //caracter(30) fj oat valorLimitePermitido; //numérico(7,2) float valorMedicaoRealizada; //numérico(7,2) String unidadeMedida; //caracter(10) String codigoAgente; //caracter(20) Date dataXmlAit; //data Time horaXmlAit; //hora Date dataConsistencia; //data Time horaConsistencia; //hora Date dataXmlAitConsistido; //data Time horaXmlAitConsistido; //hora String situacaoAitExterno; //caracter(2 String indResultadoConsistencia; //caracter(2)
public static String carregarAitExterno (String xmlAit)
//* Define variáveis boolean erro = false; // Informa se um erro foi detectado. String mensagemErro - ""; //Guarda a descrição da mensagem de erro, caso ela ocorra. Connection conexão - null; //Classe que estabelece uma conexão com o banco de dados. Bufferedwriter bufReciboAit; String linha ~ "*; String nomeArquivoTmp = "NENHUM"; // nome do arquivo a ser retornado String piacaVeiculo = ' °; //* Define os formatos e as variáveis que correspondem à data e à hora atuais. SimpleDateFormat formatoData = new SimpleDateFormat ("yyyy-MM-dd*); SimpleDateFormat formatoHora = new SimpleDateFormat ("HH:mm:ss"); Date dataHoraHoje = new Date O; String dataHoje = formatoData.format(dataHoraHoje); String horaAgora = formatoHora . format (dataHoraHoje) ,-try
// Define a conexão com o banco de dados. String banco - "jdbc:odbc:miiit"; // Utiliza o driver ODBC •miiit* String driver = "sun. j dbc. odbc . JdbcOdbcDriver",- // Driver JDBC oferecido com
// o SDK 1.3 Class.forName(driver); // cria o driver conexão = DriverManager.getConnection (banco,"","•); // Estabelece a conexão conexão.setAutoCommitfalse);
// Cria o arquivo temporário para o documento xmlReciboAit File xmlReciboAitTmp = File.createTempFile
("xmlReciboAit", ".tmp",ParametrosMi i it.DIR_TEMP); bufReciboAit = new BufferedWriter (new FileWriter(xmlReciboAitTmp)); nomeArquivoTmp = xmlReciboAitTmp.getName(); // Inclui o cabeçalho rio arquivo linha = "<mit:docXmlReciboAit data=\""+dataHoje+*\" "+
"hora=\"1+horaAgora-"\* •+ "xmlns:mit = \"http://www.mii it.gov.br/Mii it\" " +
Apêndice E - Códigos Fonte do Protótipo 127
•xmlns:xsi=\"http://www.w3.org/2QQl/XMLSchema~instance\" •+ •xsi:schemaLocation=\"http://www.milit.gov.br/Miiit •" + ParametrosMiiit.URL_MIIIT+"\">" ;
bufReciboAit.write(linha, O, linha.length()); // bufReciboAit.newLine); //-
true) ; true);
// Define o parser do documento xmlAit recebido como parâmetro // utilizando a API SAX SAXParserFactory docFactory = SAXParserFactory.newlnstance(); docFactory.setNamespaceñware(true); docFactory.setValidating(true); SAXParser docSAXParser = docFactory .newSAXParser(); XMLReader parserXmlAit = docSAXParser.getXMLReader(); parserXmlAit.setFeature("http://xml.org/sax/features/namespaces•, parserXmlAit.setFeature("http://xml.org/sax/features/validation", parserXmlAit.setFeature("http://apache.org/xml/features/validation/schema", true); parserXmlAit.setFeature
"http: /./apache, org/xml/features/validation/warn-on-undeclared-elemdef", true) ; parserXmlAit.setFeature
("http://apache.org/xml/features/validation/schema-full-checking", true); // Define a classe que tratará os erros, do parser ErrorChecker errors = new ErrorChecker(); parserXmlAit.setErrorHandler(errors); // Define a classe que tratará os eventos do SAX ParserSAXAlt prdcessaSax = new ParserSAXAit(conexão, bufReciboAit); parserXmlAit.setContentHandler(processaSax); // Realiza o parser parserXmlAit-parsexmlAit); linha = "<mit:dataXmlAit>"+processaSax.getDataXmlAit()+"</mit:dataXmlAit>"; bufReciboAit.write(linha. O, linha.length)); // bufReciboAit.newLine(); linha = "<mit:horaXmlAit>"+processaSax.getHoraXmlAit)+"</mit:horaXmlAit>"; bufReciboAit.write(linha, 0, linha.length()); // bufReciboAit.newLinef); erro = (errors. getStatus () I I processaSax. getErroBD (..) ; if (erro).
linha = "<mi t:codigoRetorno>NC</mit;codigoRetorno>•; else
linha = "<mit:codigoRetorno>CF</mit:codigoRetorno>*; bufReciboAit.writedinha, 0, linha.length() ) ; // bufReciboAit.newLinei) ; linha = "</mit:docXmlReciboAit>"; bufReciboAit.writedinha, 0, linha. length!) ) ; // bufReciboAit .newLine () ; bufReciboAit.close();
// Trata as exceções que possam ocorrer catch (SQLException sqle.) erro = true; mensagemErro = sqle.toString(); System.out^println("AitExterno.carregarAitExterno: Erro no SQL."); System.out.printIn("AitExterno.carregarAitExterno: '^mensagemErro);
catch (iQException ioe) erro ^ true; mensagemErro = ioe.toString(); System.out.println("AitExterno.carregarAitExterno: Erro de I/O."); System.out.println("AitExterno.carregarAitExterno: "+mensagemErro);
cátch (ClassNotFoundExcéptioh ele) erro = true; mensagemErro = cie.toString(); System.put.printin("AitExterno.carregarAitExterno: Erro no driver de conexão."); System. out - print In C "AitExterno. carregarAitExterno: " +mensagemErro) ;
catch ParserConfigurationException pcf) erro = true; mensagemErro = pcf.toString(); System.out.printIn("AitExterno.carregarAitExterno: Erro de configuração do
Parser."); System, out.printIn("AitExterno.carregarAitExterno:
) catch (SAXException saxe) erro = true; mensagemErro = saxe.toString(; System.out.printIn"AitExterno.carregarAitExterno: Erro no driver de conexão."); System.out.println("AitExterno.carregarAitExterno: finally [ try
if (erro) conexão.rollback(;
else conexão.commit();
catch (SQLException sqle) erro = true;. mensagemErro = ,sqle. toString (;
•+mensagemErro)
1+mensagemErro);
Apêndice E - Códigos Fonte do Protótipo 128
System.out.println("AitExterno.carregarAitExterno: Erro no commit ou rollback.");
System.out.println("AitExterno.carregarAitExterno: "+mensagemErro); finally try
conexão.close(); catch (SQLException sqlej erro = true; mensagemErro = sqle. toString () ,-System.out.println
("AitExterno.carregarAitExterno: Erro no encerramento da conexão."); System.out.println("AitExterno.carregarAitExterno: •+mensagemErro);
) return nomeArquivoTmp;
)
// final do método carregarAitExterno()
static public void consistirAitExterno ( )
static public void obterAitsConsistidos ( ) )
// Classe que manipulara os eventos gerados pelo parser SAX do documento xmlAit class ParserSAXAit extends DefaultHandler private static Connection conexao; private static BufferedWriter bufReciboAit; private static String linhaCampos; private static String linhaValores; private static boolean campolnclusao; // Determina se o elemento corresponde a um
// campo da tabela que dervera ser incluido private static boolean limitador; // Determina se ha necessidade de um limitador
// para o valor do campo private static boolean erroBD; // Determina se houve erro no banco de dados private static String dataXmlAit; private static String horaXmlAit;
ParserSAXAit (Connection conn, BufferedWriter buf) conexao = conn; bufReciboAit = buf; campolnclusao = false; limitador = false; linhaCampos - M"; linhaValores = "("; dataXmlAit = "* ; horaXmlAit = ""; erroBD = false;
public void startElementÍString uri. String localName, String qName, Attributes attr)
// Verifica qual o elemento que está sendo processado e determina se há // necessidade de utilizar um limitador no comando SQL "insert" campolnclusao = false; if (localName.equals('docXmlAit")> dataXmlAit = attr.getValue"data*); horaXmlAit - attr.getValue("hora*);
else if (localName.equals('codigoOrgaoTransito•) I I localName.equals¡"renavam*) I I localName.equals("codigoMunicipioVeiculo") !I localName.equals("numeroCNHCondutor") I I localName.equals"numeroCPFInfrator") I I localName.equals("codigoMunicipioInfracao") I I localName.equals("codigolnfracao") I I localName.equals("valorLimitePermitido") I I localName.equals I"valorMedicaoRealizada")) (
limitador = false; campolnclusao = true; linhaCampos = linhaCampos + localName + ",",-
else if (localName.equals('identificacaoAit") I I localName.equals("placaVeiculo")|| localName.equals("ufVeicuio") I I localName.equals"nomeCondutor") I I localName.equals("ufCNHCondutor")I t
Apêndice E - Códigos Fonte do Protótipo 129
localName.equals("nomelnfrator")I\ localName.equals('numeroCGCInfrator") I I localName. equals ("enderecolnfrator" ). I I localName.equals("nomeMunicipioInfrator")|I localName.equals("localinfracao")If localName.equals("complementoLocallnfracao") I I localName.equals("descEquipamentoAfericao") I I localName.equals("unidadeMedida"I I localName.equals"codigoAgente") I I localName.equals("datalnf racao") I I localName.equals("horalnfracao"))
limitador = true.; campoInclusão = true; linhaCampos = linhaCampos + localName + ",";
>
public void characters (chart] ch, int inicio, int tamanho) String valor = new Stringtch, inicio, tamanho); valor = valor.trim); if (valor.length) <= 0) valor = 'null';
if (campoinclusão) if (limitador !valor.equals('null•)) linhaValores = linhaValores + " F n + valor + "', ";
else linhaValores = linhaValores + valor + ", •;
campolnclusao = false; )
public void enablement(String uri. String localName, String qName) ( int regsAlterados; if (localName.equals"ait')) try
/•/ Completa as linhas do comando "insert" relacionadas aos campos e aos valores linhaCampos = linhaCampos *
"dataXmlAit, horaXmlAit, indResultadoConsistencia, SituacaoAitExterno);
linhaValores = linhaValores + "'•+dataXmlAit+"', '"+horaXmlAit+"', 'NP'.'NR')"; // comandoUpdate representa uma instrução SQL Statement comandoUpdate = conexão.createStatement(); regsAlterados = comandoUpdate.executeUpdate(• insert into AitExterno " +
linhaCampos -+• " values ' + linhaValores);
comandoUpdate.close(); if (regsAlterados, <= 0) System.out.print-ln ("Não incluiu") ;
/'/ Testa se foram encontrados registros catch (SQLException sqle) ( erroBD = true; System.out.println("ParserSAXAit.endElement: Erro no SQL."); System.out.printin("ParserSAXAit.endElement: "+sqle.toString());
finally ( linhaCampos = "("; linhaValores = "(";
public String getDataXmlAit() return dataXmlAit;
public String getHoraXmlAit( return horaXmlAit;
public boolean getErroBDf) return erroBD;
)
Listagem E 3 - Classe AitExterno e ParserSAXAit (arquivo AitExterno.java)
package gov.miiit.orgaoCentral;
import gov.miiit.orgaoTransito.* ;
Apêndice E - Códigos Fonte do Protótipo 130
import gov.mint. tipos . * ; import j ava.io.*; import j ava.util.*; import j ava-util.Date; import j ava.text.*; import j ava.sql.*; import j avax. xml .parsers . SAXParser,-import javax.xml.parsers.SAXParserFactory; import org.xml.sax.SAXException; import org.xml.sax.XMLReader; import org.xml.sax.InputSource; import org .xml. sax. At tributes,-import org.xml.sax.helpers.DefauItHandler;
public class Veiculo
int renavam = 0 ; // numérico(9) String placa = "'; // caracter(10) int codigoMarcaModelo = 0 ; // numérico(6) String ufVeiculo = ""; // caracter(2) int codigoMunicipioVeiculo = 0; // numérico(4) String cor = ""; // caracter (20)
Veiculo () renavam = 0; placa = ""; codigoMarcaModelo = 0 ,-ufVeiculo = "" ,-codigoMunicipioVeiculo = 0; cor = "";
)
// Este método processa o documento xmlPlacas ' public static String obterVeiculos (String xmlPlacas)
//* Define variáveis boolean erro = false; // Informa se um erro foi detectado. String mensagemErro = "•; //Guarda a descrição da mensagem de erro, caso ela ocorra Connection conexão = null; //Classe que estabelece uma conexão com o banco de dados BufferedWriter bufVeiculos; String linha - ""; String nomeArquivoTmp = "NENHUM"; // nome do arquivo a ser retornado String placaVeiculo = " ";
//* Define os formatos e as variáveis que correspondem à data e à hora atuais. SimpleDateFormat formatoData = new SimpleDateFormat ("yyyy-MM-dd"); SimpleDateFcrmat formatoHora = new SimpleDateFormat (" HH: mm: ss") ,-Date dataHoraHoje = new Date(); String dataHoje = formatoData.format(dataHoraHoje); String horaAgora - formatoHora.format(dataHoraHoje); try
// Define a conexfio com o banco de dados. String banco = "jdbc:odbc:miiif; // Utiliza o driver ODBC "miiit" String driver = "sun.jdbc.odbc.JdbcOdbcDriver"; // Driver JDBC oferecido
// com o SDK 1.3 Class.forName(driver); // cria o driver conexao = DriverManager.getConnection (banco,"","•); // Estabelece a conexSo
// Cria o arquivo temporário para o documento xmlVeiculos File xmlVeiculosTmp = File.createTempFile
("xmlVeiculos",".tmp",ParametrosMi iit.DIR_TEMP); bufVeiculos = new BufleredWriter (new FileWriter(xmlVeiculosTmp)); nomeArquivoTmp xmlVeiculosTmp. getName () ; // Inclui o cabeçalho no arquivo linha = "<mit:docXmlVeiculos data=\•"+dataHoje+"\" "+
" hora = \"" j-horaAgora +" \" " + "xnilns :mit = \ "http: / / www. mi iit, gov. br /Mi iit \" " + "xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instanceV" "+ "xsi:schemaLocation-\"http://www.miiit.gov.br/Miiit " + ParametrosMiiit.URL_MIIIT+"\*>";
bufVeiculos.write(linha, 0, linha.length()); bufVeiculos.newLine();
// Define o parser do documento xmlPlacas recebido como parâmetro // utilizando a API SAX
Apêndice E - Códigos Fonte do Protótipo 1
SAXParserFactory docFactory = S A X P a r s e r F a c t o r y . n e w l n s t a n c e O ; d o c F a c t o r y . s e t N a m e s p a c e A w a r e ( t r a e ) ; d o c F a c t o r y . s â t V a l I d a t i n g l t r u e ) ; SAXPar.ser docSAXPaxser a docFactory .newSAXParserO; XfóUíeadér par s e r XnalPlacas - docSAXPaxser. getXMtiReader () ; p a r s e r X m l P l a c a s . s e t F e a t u r e "http; /,/xml . o r g / s a x / f e a t u r e s /namespaces • , t r u e ) ; p a r s e r X m l P l a c a s . s e t F e a t u r e 1 " h t t p : / / x r a l . o r g / s a x / f e a t u r e s / v a l i d a t i o n * ; t r u e ) ; p a r s e r X m l P l a c a s . s e t F e a t u r e
("ht tp : / / a p a c h e . o r g / x m l / f e a t ^ e s / v a l i a a t i o n / s c h e r n a " , t r u e ) ; p a r s e r X m l P l a c a s . s e t F e a t u r e
l "h t tp : / / a p a c h e . o r g / x m l / f e a t u x e s / v a l i d a t i o n / w a T O - o n - m d e c l a r e d - ê l e m d e f - . t r u e ) ; p a r s e r X m l P l a c a s . s e t F e a t u r e
"ht tp : / / a p a c h e . o r g / . x m l / f e a t u r e s / v a i i o ^ t r u e ) ;
/ / D e f i n e a c l a s s e que t r a t a r á bs , e r r o s d0' p a r s e r ErrorChecker e r r o r s = new ErrorChecker £ ) ; parserXmlPlacas . s e tErrorHandler ( errors ) . ; / / D e f i n e a c l a s s e que t r a t a r á o s e v e n t o s do SAX ParserSAXVeiculo p r o c e s s a S a x - = new ParserSAXVeiculo(conexão , b u f V e i c u l o s ) ; p a r s e r X m l P l a c a s . s e t C o n t e n t H a n d l e r ( p r o c e s s a S a x ) j If R e a l i z a o p a r s e r p a r s e r X m l P l a c a s - p a r s e ( x m l P l a c a s ) ; i f ( e r r o r s . g e t s t a t u s i ) )
ñcffleArquívoTmp » "NEHHTJM*; buf -Ve icu los . c l o s e ( ) ; x m l V e i c u l o s T m p . d a l e t e i ) ;
. e l s e l i n h a = °</mit.:docXmlV"eiculos>"¡' b u £ V e i c u l o s . ' w r i t e ( l i n h a , 0 , l i h h a . l e n g t h ( ) ) j bufVe icQlos .newLine ( ) ; b u f V e i c u l ò s . c l o s e í ( ;
1 / / Trata a s excecÇes que possam o c o r r e r Í c a t c h (SQLExccption sqle, •
e r r o - t r u e ; mensageroErra = s q i e , g e t M e s s a g e ( ) ; S y s t e m , o u t - . p r t S i l n t ' E r r o no SQL,"); S y s t e m . o u t . p r i n c i n ( m e n s a g e m E r r o ) ; S y s t e m . o u t - p r i n ^ I n ( s q l e . g e t S Q L S t a t e ( > ) ; System. o u t -pr .r . t Ir. ( s q l e . g e t E r r o r C o d e () y¿
j c a t c h í j'OHxcopL-ior: i o e ) e r r o - t r u e ; itiensagémErío : o e . g e t M e s s a g e f ) ; S y s t e m . o u t . p r 1 st.i»"Erro de I / O * " ) ; System, out ¿ p r i s t In (mensagernÊrrõ") j
j c a t c h "(ClasK^C'^foundException e l e ) f e rro = t r u e ;
..mensagesiEr FÇ = g l e . g e t M e s s a g e ) ; System, o a t . or jfss Ín.( "Erro no, dr iver- d e c o n e x ã o . " ) ; System.ou^ »pr;-sa.;jn (mensagemsrro) ,-
c a t c h (SAXFxcoQE lotz s axe ) e rro = t r u è ; mensãgêmErret = s a x e . g e t M e s s a g e t ) ; System.out. .printIR'('Ei-fo nó â r l v é r de c o n e x ã o , " ) ; S y s t e m . o u t . p r l n t i n ( m e n s a g e m E r r o ) ;
ca te ) ! .Exception e) erro, t t r u e ; •mensagemErrQ = ê . F g e t M e s s a g e ( ) ; S y s t e m . o u t ¿ p r I ñ t l n ( " P r o b l e m a s g e r a l d u r a n t e a p e s q u i s a de v e í c u l o s . " ) ; S y s t e m . o u t . p r i n t l n í m e n a a g e m E r r o ) ;
_ f i n a l l y t r y t
c o n e x ã o . c l o s e i f; c a t c h (SQLException s q i e )
e r r o = true,-, mensagemErro = s q l e . g e t M e s s a g e ( ; Sys tem, out . p r l n t i n (""Erro no encerramento da c o n e x ã o . " J ; System.out- , p r i n t l n mensagemErro);
i ) . i f (erro)'
r e t u r n "ERRO*; e l s e
r e t u r n nomeArquivoTmpí J , / / f i n a l do metodc o b t e r v e i c u l o ( )
II P e s q u i s a o v e í c u l o de p l a c a "p lacaVe icu lo" e cria, no "bufVeicu los" o s e l e m e n t o s XML / / para., t a i v e i e u l p ,
Apêndice E - Códigos Fonte do Protótipo 132
public static boolean pesquisaVeiculo (Connection conexão, BufferedWriter bufVeiculos, String placaVeiculo)
String linha; boolean retorno - true; try
// Pesquisa Veiculo Statement query = conexão.createStatement(); // representa um instrução SQL ResultSet rs = query.executeQuery ("select * " +
"from Veiculo " + "where placa = '"+placaVeiculo+"' " ) ;
// Testa se há registros retornados i f (rs.next())
// Cria o conteúdo do elemento veículo para xmlVeiculo 1inha = "<mit:veiculo>"; bufVeiculos.write(linha, 0, 1inha.lengthO ) ; bufVeiculos.newLine(); linha = "<mit:placa>"+rs.getString('placa')+"</mit:placa>'; bufVeiculos.write(linha, 0, 1inha.length(); bufVeiculos.newLine(); linha = "<mit:renavam>"+rs.getString("renavam")+"</mit:renavam>"; bufVeiculos.write(linha, 0, linha.length()); bufVeiculos.newLine(); linha = "<mit: codigoMarcaModelo" -t-rs. getstring ("codigoMarcaModelo" ) +
"</mit;codigoMarcaModelo>"; bufVeiculos.write (linha, 0, linha.length()); bufVeiculos.newLine(); linha = "<mit:codigoMunicipioVeiculo>"+rs.getstring("codigoMunicipioVeiculo")+
"</mit: codigoMunicipioVeiculo"; bufVeiculos.write linha, 0, linha.length()); bufVeiculos.newLine); 1 inha = "<mit: ufVeiculo>" +rs . getstring (°ufVeiculo") •+ *</mit :ufVeiculo>" ; bufVeiculos.write(linha, 0, linha.length)); bufVeiculos.newLine); linha = "<mit:cor>'+rs.getstring("cor")+"</mit:cor>"; bufVeiculos.write(linha, 0, linha.length()); bufVeiculos.newLine<); 1inha = °<mit:codigoRetorno>VE</mit:codigoRetorno>"; bufVeiculos.wr ite(linha, 0, linha.length()1; bufVeiculos.newLine(); linha = "</mit:veiculo>"; bufVeiculos.write(linha, 0, linha.length()>; bufVeiculos.newLine();
else linha - "<mit:veiculo>"; bufVeiculos.write(linha, 0, linha.length()>; bufVeiculos.newLine(); linha = "<mit:placa>"+placaVeiculo+"</mit:placa>"; bufVeiculos.write(linha, 0, linha.length))); bufVeiculos.newLine(); linha = "<mit:codigoRetorno>NE</mit:codigoRetorno>"; bufVeiculos.write(linha, 0, linha.length!)); bufVeiculos.newLine(); linha = "</mit:veiculo>"; bufVeiculos.write(linha, D, linha.length()); bufVeiculos.newLine(;
) query.close();
) catch (SQLException sqlei retorno = false; System.out.print Inf"Erro no SQL - pesquisaVeiculo."); System.out.print In(sqle.getMessage()); System.out.printIn(sqle.getSQLState) ) ; System.out.printIn(sqle.getErrorCode() ) ;
) catch (IOException ioe) retorno = false; System.out.printIn"Erro de I/O."; System.out.printIn(ioe.getMessage() ) ;
) catch (Exception e) retorno = false; System.out.printIn(•Erro Geral."); System.out-printIn(e.getMessage()) ;
) finally return retorno;
)
// Classe que manipulara os eventos gerados pelo parser SAX do documento xmlPlacas class ParserSAXVeiculo extends DefaultHandler
static Connection conexao; Static BufferedWriter bufVeiculos; static boolean ePlaca;
ParserSAXVeiculo (Connection conn, BufferedWriter buf) conexao = conn; bufVeiculos = buf;
)
ADêndice E - Códigos Fonte do Protótipo
public void startElement(String uri. String localName, String qName, Attributes attributes)
// Verifica se o elemento atual é <placa> ePlaca = localName.equals("placa");
public void characters (char[] ch, int inicio, int tamanho) // Se o elemento atual for <placa>, faz a pesquisa if (ePlaca) String valor = new String(ch, inicio, tamanho); boolean pesq = Veiculo.pesquisaVeiculo conexão, bufVeiculos, valor); ePlaca = false;
í
Listagem E.4 - Classe Veiculo e ParserSAXVeiculo (arquivo Veiculo.java)
package gov.miiit.orgaoTransito;
import j ava.net.*;
public class OrgaoTransito
OrgaoTransito > int codigoOrgaoTransito; // numérico6) String nomeOrgaoTransito; // carácter(30) char classificacaoOrgaoTransito; // carácter(1) String ufOrgaoTransito; // carácter(2) short codigoMunicípioOrgaoTransito; // numérico(4) URL urlOrgaoTransito; // carácter(2 00)
static public URL obterUrlOrgaoTransito(String ufOrgao) throws MalformedURLException URL urlOrgao = new URL ("http://localhost:8080/examples/servlet/RecebePacoteWeb") return (urlOrgao);
)
static public URL obterUrlOrgaoTransitoint codOrgao) throws MalformedURLException URL urlOrgao = new URL ("http://www.miiit.gov.br"); return (urlOrgao);
static public int obterCodigoOrgaoTransito(String ufOrgao) int valor = •; bytei] byteUf = ufOrgao.getBytes); for (int i=0; (i < byteUf.length) && (i < 2); i++) valor = valor + (byteUf[i]*(99*i)+1));
return valor; )
static public URL obterUrlOrgaoCentral() throws MalformedURLException URL urlOrgao = new URL ("http://localhost:8080/examples/servlet/RecebePacoteWeb") return (urlOrgao);
static public int obterCodigoOrgaoCentral() return 1000;
) Listagem E.5 - Classe OrgaoTransito (arquivo OrgaoTransito.java)
package gov.mi i it. orgaoTrans ito ,-
import org.xml.sax.helpers.DefaultHandler; import org.xml.sax.SAXParseException;
public class ErrorChecker extends DefaultHandler
private boolean status; private String message;
Apêndice E - Códigos Fonte do Protótipo I
public ErrorChecker() status = false;
public void error (SAXParseException e) status - true; message = e.getMessage); System.out.println("Erro no parser: w+message);
public void warning (SAXParseException e) status = true; message = e.getMessage(); System.out.println("Problema do parser: "+message);
public void fatalError (SAXParseException e) status = true; message = e.getMessage(); System.out.println"Erro no parser: '+message); System.out.println("Não é possível continuar.'); System.exit(1);
public boolean getStatusí) return status;
public String getMessage() return message;
)
Listagem E.6 - Gasse ErrorChecker (arquivo ErrorChecker.java)
import j ava. io . * ,-import Java.uti1.*; import Java.text.*; import java.net.URLDecoder• import gov.miiit.tipos.*; import gov.miiit.orgaoTransito.ErrorChecker; import gov.miiit.orgaoCentral.Veiculo; import gov.mi i i t.orgaoAutuador.Ait; import gov.miiit.orgaoConveniado.AitExterno;
import javax.xml.parsers.SAXParser; import javax.xml.parsers.SAXParserFactory; import org.xml.sax.SAXException; import org.xml.sax.XMLReader; import org.xml.sax.InputSource; import org.xml.sax.Attributes; import org.xml.sax.helpers.DefaultHandler;
public class AnalisaPacote
private String nomeArquivoPacote;
public AnalisaPacote () nomeArquivoPacote = "NENHUM";
public boolean parser(Reader xmlPacoteReader) try BufferedReader bufDados = new BufferedReader(xmlPacoteReader); boolean eof = false; URLDecoder decoder = new URLDecoder(); String xmlPacote = new StringO; while !eof)
String linha = bufDados.readLine(); if (linha == null) eof = true;
else xmlPacote = xmlPacote + decoder.decode(1inha);
// Fecha o fluxo da resposta bufDados.close(); boolean resposta = this.parser(xmlPacote);
Apêndice E - Códigos Fonte do Protótipo 135
return resposta; catch (IOException ioe) System.out.printIn(" AnalisaPacote.parser(Reader): " + ioe.toString()); return false;
public boolean parser(String xmlPacote)
// Declaração de variáveis boolean retorno = false; // informa se algum arquivo deverá ser retornado boolean erro = false; // informa se ocorreu algum erro no processamento String descrição = "--"; // possui a descrição do erro ocorrido String mensagem = '--"; // possui a mensagem do erro ocorrido // Determina o fluxo de entrada dos dados do pacote ByteArraylnputStream byteEntrada = new ByteArrayInputStream(xmlPacote.getBytes(); InputSource inpArqXml = new InputSource(byteEntrada); try
// Cria a fábrica do parser SAX SAXParserFactory docFactory = SAXParserFactory.newlnstance(; docFactory.setNamespaceAware(true); docFactory.setValidatingtrue); // Cria o parser SAX SAXParser docSAXParser = docFactory.newSAXParser(); // Cria um manipulador para os eventos do parser SAX que não trata os elementos ParserSAXPacote manipuladorSAX = new ParserSAXPacote(false); // Realiza o parser sem validação docSAXParser.parse(inpArqXml, manipuladorSAX); // Fecha o fluxo de entrada e cria o fluxo novamente para fazer // o parser com validação byteEntrada.close(); byteEntrada = new ByteArraylnputStream(xmlPacote.getBytes()); inpArgXml = new InputSource(byteEntrada); // Determina que o manipulador de eventos passe a verificar os elementos manipuladorSAX.setVerificaElementos(true); // Cria um objeto XMLReader que suporta validação utilizando XMLSchema XMLReader reader = docSAXParser.getXMLReader(); reader.setFeature"http://xml.org/sax/features/namespaces", true); reader.setFeature'http://xml.org/sax/features/validation", true); reader.setFeature"http://apache.org/xml/features/validation/schema", true); reader.setFeature
("http://apache.org/xml/features/validation/warn-on-undeclared-elemdef',true); reader.setFeature
('http://apache.org/xml/features/validation/schema-full-checking", true); // Cria e associa a classe que informará os erros verificados durante parser ErrorChecker errors = new ErrorChecker(); reader.setErrorHandler(errors); // Determina que o manipulador "manipuladorSAX" será utilizado pelo // parser "reader" reader.setContentHandler(manipuladorSAX); // Realiza o parser utilizando a entrada em inpArqXml reader.parse(inpArqXml); // Fecha o fluxo de entrada byteEntrada.close); erro = errors.getstatus(); if (¡erro)(
// Se não ocorreu erro no parser prepara-se para criar um arquivo // correspondente ao pacote retorno = false; File xmlPacoteResp = File.createTempFile
("xmlPacote",*.tmp",ParametrosMii it.DIR_TEMP); BufferedWriter out = new BufferedWriter (new FileWriter(xmlPacoteResp)); nomeArquivoPacote = xmlPacoteResp.getName(); // Define os formatos e as variáveis que correspondem à data e a hora atuais. SimpleDateFormat formatoData = new SimpleDateFormat ("yyyy-MM-dd"); SimpleDateFormat formatoHora = new SimpleDateFormat "HH:mm:ss*); Date dataHoraHoje = new Date(); // Monta inicio do envelope e o cabeçalho out.write("<pct:Envelope xmlns:pct = \"http://www.mi iit.gov.br/PacoteMiiit\" * +
"xmlns:mit=\"http://www.miiit.gov.br/Miiit\• " + "xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\' " + "xsi:schemaLocation=\"http://www.miiit.gov.br/PacoteMiiit " + "C:/Jakarta-tomcat-4.0.2/bin/Temp/PacoteMiiit.xsd " + "http://www.miiit.gov.br/Miiit "+ "C:/Jakarta-tomcat-4.0.2/bin/Temp/Miiit.xsd\"> • ) ;
out.write(a <pct:Header> " ) ; out.write(" <pct rdestino> * ) ; out.write(" <pct:codigoOrgaoTransitoDestino>"+
Apêndice E - Códigos Fonle do Protótipo 136
manipuladorSAX.getCodigoSolicitante()+"</pct:codigoOrgaoTransitoDestino> " ) ; out.write(" <pct:urlOrgaoTransitoDestino>"+manipuladorSAX.getUrlSolicitante()+
•</pct:urlOrgaoTransitoDestino> • ) ; out .write " </pct: destino ") ; out .write (" <pct: origem> ") ; out.write(' <pct:codigoOrgaoTransitoOrigem>"+ParanetrosMiiit.CODIGO_0RGAO+
•</pct:codigoOrgao'TransitoOrigem> * ; out .write í" <pct:urlOrgaoTransitoOrigem>"+ParametrosMiiit .URL__ORGAO+
•</pct:urlOrgaoTransitoOrigem> " ) ; out.write(• </pct:origem> • ) ; out.write" <pct:dataEnvio>*+ formatoData.format(dataHoraHoj e) +
•</pct:dataEnvio> * ) ; out.write(" <pct:horaEnvio>* + formatoHora.format(dataHoraHoj e) +
"</pct:horaEnvio> * ) ; out .write (" </pct :Header> ") ,-// Monta o corpo do envelope out.write 1" <pct:Body>"); String nomeOperacao - " "; String nomeParametro = • •; for (int i = 0; i < manipuladorSAX.getTamListaOperacao(); i++) nomeOperacao = manipuladorSAX.getListaOperacao(i); nomeParametro = manipuladorSAX.getListaParametro(i); // Caso tenha sido encontrado algum elemento "obterVeiculos" no pacote // processado será chamado o método obterVeiculos da classe Veiculo com o // respectivo arquivo criado durante o parse. Neste caso, deverá existir // uma resposta para o solicitante, por isso, à variável "retorno" é // atribuído o valor "true". O arquivo xmlVeiculo, criado pelo método // obterVeiculo, será incluído no envelope de resposta, if (nomeOperacao.equals("obterVeiculos")) File parâmetro = new File
ParametrosMiiit.DIR_TEMP_RECEPCAO+"\\"+nomeParametro); String xmlVeiculos = Veiculo.obterVeiculos(parâmetro.getPath()); if (!xmlVeiculos.equals("NENHUM")) out .write (• <pct: operação ") ; out.write• <pct:registrarUfVeiculo> • ) ; insereArquivo(ParametrosMiiit.DIR_TEMP+"\\"+xmlVeículos, out>; parâmetro.delete(); out.write(* </pct:registrarUfVeículo> " ) ; out.write(* </pct:operacao> " ) ; retorno = true;
else erro = true,-mensagem = 'Gerando xmlVeiculos.";
)
else // Caso tenha sido encontrado algum elemento "registrarUfVeiculo" no pacote // processado será chamado o método registrarUfVeiculo da classe Ait com o // respectivo arquivo criado durante o parse. Esse método não retorna resposta // ao solicitante. if (nomeOperacao.equals("registrarUfVeiculo")) File parâmetro = new File
(ParametrosMiiit.DIR_TEMP_RECEPCAO+"\\"+nomeParametro); if (!Ait.registrarUfVeiculoparâmetro.getPath())J í erro = true; mensagem = • Processando xmlVeiculos "+parametro.getPath()+
". Registrando UF de Veiculo."; else System.out.printIn ("Processou xmlVeiculo."); parâmetro.delete();
else // Caso tenha sido encontrado algum elemento "registrarReciboAit* no pacote // processado será chamado o método registrarReciboAit da classe Ait com o // respectivo arquivo criado durante o parse. Esse método não retorna resposta // ao solicitante. if (nomeOperacao.equals("registrarReciboAit")) File parâmetro = new File
(ParametrosMi iit.DIR_TEMP_RECEPCAO+"\\*+nomeParametro); if (!Ait.registrarReciboAit(parâmetro.getPath(J)) erro = true; mensagem = • Erro processando xmlReciboAit °+parametro.getPath()+'.';
) else System.out.printIn ("Processou xmlReciboAit."); parâmetro.delete();
else // Caso tenha sido encontrado algum elemento •carregarAitExterno" no pacote
Apêndice E - Códigos Fonte do Protótipo 137
// processado será chamado o método carregarAitExterno da classe AitExterno // com o respectivo arquivo criado durante o parse. Neste caso, deverá existir // uma resposta para o solicitante, por isso, à variável 'retorno* é atribuído // o valor "true". 0 arquivo xmlVeiculo, criado pelo método obterVeiculo, será // incluído no envelope de resposta, if ínomeOperacao.equals"carregarAitExterno")) File parâmetro = new File
(ParametrosMii it.DIR_TEMP_RECEPCAO+"\\"+nomeParametro); String xmlReciboAit = AitExterno.carregarAitExterno(parâmetro.getPath()); if (!xmlReciboAit.equals("NENHUM")) out.write" <pct:operacao> '; out.write" <pct:registrarReciboAit> " ) ; insereArquivo(ParametrosMiiit.DIRJTEMP+"\\"+xmlReciboAit, out); parâmetro.delete(); out.write(" </pct:registrarReciboAit> " ) ; out.write(" </pct:operacao> " ) ; retorno - true;
) else erro = true; mensagem = "Gerando xmlReciboAit.";
)
out .write (" </pct: Body> " ; // Fecha o envelope out.write('</pct:Envelope> "; out.close(); i f (erro)
//Se ocorrer algum erro o arquivo relacionado ao pacote de transmissão será // apagado e o nome do arquivo será 'NENHUM". A variável descrição informará // que houve problemas na geração do pacote. xmlPacoteResp.delete(); nomeArquivoPacote = "NENHUM"; descrição = "Problemas na geração do pacote.";
else if (! retomo) //Se não houve erro e não há necessidade de retorno para o solicitante //o arquivo relacionado ao pacote de transmissão será apagado e o nome // do arquivo será "NENHUM". xmlPacoteResp.delete(); nomeArquivoPacote = "NENHUM*;
else ( // Caso tenha ocorrido algum erro durante o parse, serão apagados todos os // arquivos temporários que foram gerados. for (int i = 0; i < manipuladorSAX.getTamListaOperacaoí); i+ + )
File parâmetro = new File (ParametrosMiiit.DIR_TEMP_RECEPCAO+ * \ \ '-t-manipuladorSAX. getListaParâmetro (i> ) ;
parâmetro.delete(); descrição = 'Documento XML não passou pelo parser. ",-
)
catch (SAXException e) ( descrição = "Problemas durante o parse do arquivo."; mensagem = e.toString(); erro = true;
catch (Exception e) descrição = "Problema geral na classe."; mensagem = e.toString<); erro = true;
finally if (erro) System.out.println('AnalisaPacote.parser(String): Erro ao analisar Pacote*); System.out.printIn(*AnalisaPacote.parser(String: "+descricao); System.out.printIn("AnalisaPacote.parser(String): "+mensagem);
) // Se ocorreu erro o método retorna "false", caso contrário retorna "true", return lerro;
)
// Insere um determinado arquivo na estrutura do envelope que será retornado, ou seja, // na estrutura do arquivo xmlPacote que está sendo criado, boolean insereArquivo (String nomeArquivo, Writer out) (
try File arquivo = new File(nomeArquivo); BufferedReader bufLeitura = new BufferedReader (new FileReader(arquivo)); boolean eof = false,-
Apèndice E - Códigos Fonte do Protótipo 138
while Leof) ( String linha = bufLeitura.readLine(); if (linha == null) eof = true;
else out.write(linha, 0, linha.length();
buf Leitura. closed ; arquivo.delete(); return true;
catch (lOException e) ( System.out-println("AnalisaPacote.insereArquivo: Erro no envio do arquivo "+
nomeArquivo+". " ) ; System.out.println("AnalisaPacote.insereArquivo: "+e. toStringO); return false;
public String getNomeArquivoPacote() return nomeArquivoPacote;
public String getCaminhoArquivoPacote() return ParametrosMiiit.DIR_TEMP+'\\"+nomeArquivoPacote;
// Classe que manipulara os eventos gerados pelo parser SAX do documento xmlPacote class ParserSAXPacote extends DefaultHandler private boolean verificaElementos; private boolean criandoArquivo; private File xmlTemporario; private BufferedWriter bufEscrita; private String namespace; private String namespaceEnvelope; private boolean processandoCodigoOrigem; private boolean processandoUrlOrigem; private String cocigoSolicitante; private String urISolicitante; private ArrayL-is;, operacao = new ArrayListO; private ArrayList parametro = new ArrayList)j
ParserSAXPacoLc ( seal ear. setVerif Element os) super(); VerificaElerne"LOS. - setVerifElementos; criandoArquivo false; namespace = * ";. namespaceEnvelooc - " *;
public void stari. PrefixMapping (String prefix. String uri) if (verificaElementos)
if ((prefix.trim()).equals("")) namespace & namespace+° xmlns=\""+uri+"\"";
else namespace = namespace+" xmlns:'+prefix+"=\"*+uri+•V";
'
public void startElementString uri. String localName, String qName, Attributes attr)
String listaAtributos; String linha; String localSchema; processandoCodigoOrigem = false; processandoUrlOrigem = false; if verificaElementos) (
if (localName.equals("Envelope") namespaceEnvelope = namespace; localSchema = • \""+attr.getValue"xsi:schemaLocation")+•\"°; if (!localSchema.equals("\"\"") localSchema = • xsi:schemaLocatian="+localSchema; namespaceEnvelope = namespaceEnvelope + localSchema;
else if (localName.equals("obterVeiculos") II
localName. equals ("registrarUf.Veiculo") J I localName.equals("registrarReciboAit") I I
Apêndice E - Códigos Fonte do Protótipo 139
localName.equals("carregarAitExterno") operacao.add(localName);
else if localName.equals("docXmlPlacas") I I localName.equals("docXmlVeiculos") I I localName.equals("docXmlAit") I I localName.equals("docXmlReciboAit•)) (
criandoArquivo = criaArquivoTemp(localName); if (namespace.trim()).equals"") ) namespace = namespaceEnvelope;
else if (localName.equals("codigoOrgaoTransitoOrigem") ( processandoCodigoOrigem = true;
else if localName.equals("urlOrgaoTransitoOrigem")) processandoUrlOrigem = true;
if (criandoArquivo) (
listaAtributos = "*; for (int i=0; i < attr.getLength(); i++) listaAtributos = listaAtributos+" "+attr.getQName(i)+"=\""+attr.getValue(i)+
• \ • • ; ) 1 inha = "<" +qNaine +1 istaAtributos+namespace+" >" ; try bufEscrita.write(linha, 0 , linha.length()); // bufEscrita.newLine;
) catch IOException ioe) System.out.println ('ParserSAXPacote.startElement: Erro abrindo elemento "+
localName+"."); )
namespace = " •;
)
public void characters (char[] ch, int inicio, int tamanho) String valor = new String(ch, inicio, tamanho),-if (verificaElementos)
if (criandoArquivo) if ((valor.trim()).length() > 0) ( try bufEscrita.write(valor, 0, valor.length()); // bufEscrita.newLine();
catch (IOException ioe) System.out.println ("ParserSAXPacote.characters: Erro incluindo valor.");
)
) else if (processandoCodigoOrigem) codigoSolicitante = valor;
else if (processandoUrlOrigem) urlSolicitante = valor;
)
public void endElement(String uri. String localName, string qName) String linha; if (verificaElementos)
if (criandoArquivo) linha = "</'+qName+*>"; try bufEscrita.write(linha, 0 , 1inha.length()); // bufEscrita.newLine(>;
catch IOException ioe) System.out.println ("ParserSAXPacote.endElement: Erro fechando elemento "+
localName+°.");
if (localName.equals("docXmlPlacas") I I
localName.equals("docXmlVeiculos") I I localName.equals("docXmlAit") I 1
localName.equals("docXmlReciboAit")) try buf Escrita .close () ,-
catch (IOException ioe) System.out.println ("ParserSAXPacote.endElement: Erro fechando arquivo "+
xmlTemporario+"."); criandoArquivo = false;
Apéndice E - Códigos Fonte do Protótipo 140
public void setVerificaElementos(boolean setVerifElementos) verificaElementos = setVerifElementos;
)
boolean criaArquivoTemp(String prefixoArquivo) boolean criouArquivo = true; try xmlTemporario = File.createTempFile
(prefixoArquivo,".tmp',Paramet rosMi i i t.DIR_TEMP_RECEPCAQ) ; bufEscrita = new BufferedWriter (new FileWriter(xmlTemporario)); parâmetro.add(xmlTemporario.getName());
catch (IOException ioe)( System.out.printIn ("ParserSAXPacote.criaArquivoTemp: Erro criando arquivo "+
prefixoArquivo+". ") ; System.out.printIn ("ParserSAXPacote.criaArquivoTemp; "+ioe-toString()); criouArquivo = false;
catch (Exception e) System.out.println ('ParserSAXPacote.criaArquivoTemp: Erro geral criando arquivo "
+prefixoArquivo+". ") ; System.out.println ("ParserSAXPacote.criaArquivoTemp: •+e.toString()); criouArquivo = false;
) finally return criouArquivo;
)
public String getListaOperacao (int indice) return (String)operação.get(indice);
public int getTamListaOperacao()
return operação.size();
public String getListaParametro (int indice) return (String)parâmetro.get(indice);
)
public String getCodigoSolicitante () return codigoSol icitante ,-
)
public String getUrlSolicitante () ( return urlSolicitante;
)
Listagem E.7 - Classe AnalisaPacote e ParserSAXPacote (arquivo AnalisaPacote.java)
import j ava.io.*; import j ava.ut i i.*; import Java.text.*; import gov.miiit.tipos.ParametrosMiiit;
public class GeraEnvelope
private String nomeArquivoPacote; private File xmlPacoteResp; private BufferedWriter out;
public GeraEnvelope) try
xmlPacoteResp = File.createTempFile ("xmlPacote*,'-tmp",ParametrosMiiit.D1R_TEMP); out = new BufferedWriter (new FileWriter(xmlPacoteResp)); nomeArquivoPacote = xmlPacoteResp.getName(); ) catch (IOException ioe)
System.out.println"Erro gerando envelope."); System.out.printIn(ioe.toString());
) )
public boolean iniciaEnvelope (String codigoDestino, String urlDestino) try
// Define os formatos e a s variáveis que correspondem à data e à hora atuais. SimpleDateFormat formatoData - new SimpleDateFormat ("yyyy-MM-dd"); SimpleDateFormat formatoHora - new SimpleDateFormat ("HH:mm:ss"); Date dataHoraHoje - new Date(); // Monta início do envelope e o cabeçalho
Apêndice E - Códigos Fonte do Protótipo 141
out.write("<pct:Envelope "+ParametrosMiiit.ATRIB_ENVELQPE+1> " ) ; out.write(" <pct:Header> • ) ; out.write(" <pct:destino> " ) ; out.write(" <pct:codigoOrgaoTransitoDestino>"+codigoDestino+
"</pct:codigoOrgaoTransitoDestino> • ) ; out.write(" <pct:urlOrgaoTransitoDestino>'+urlDestino+
•</pct:urlOrgaoTransitoDestino> • ) ; out.write(• </pct:destino> " ) ; out.write(" <pct:origem> * ) ; out.write(" <pct:codigoOrgaoTransitoOrigem>"+ParametrosMiiit-CODIGO_ORGAO+
"</pct:codigoOrgaoTransitoOrigem> " ) ; out.write(* <pct:urlOrgaoTransitoOrigem>"+ParametrosMiiit.URL_ORGAO+
"<7pct urlOrgaoTransitoOrigem> " ; out ..write (' </pct :origem> " ) ,-out.write• <pct:dataEnvio>"+formatoData.format(dataHoraHoje)+
"</pct:dataEnvio> "; out.write (" <pct:horaEnvio>"+formatoHora.format(dataHoraHoj e) +
?</pct:horaEnvio> "; out.write" </pct:Header> " ) ; // Monta o corpo do envelope out.write(" <pct:Body>");
return true; catch (IOException e) System.out.println("Erro ao iniciar o arquivo envelope."; System.out.printlnle.toStringf)); return false;
public boolean fechaEnvelope () try .
out-write(• </pct:Body> * ) ; out .write ('</pct ;Envelop.e> " ) ; out ..close () .;
return true; catch (IOException e) System.out.println("Erro ao fechar o arquivo envelope."); System.out.println(e.toString[)); return false;
// Insere um determinado arquivo na estrutura do envelope que será retornado, ou seja, // na estrutura do arquivo xmlPacote que está sendo criado, public boolean ínsereArquivo (File arquivo, String operação)
try if (operação.length() > 0)
out.write .[" <pct :operacao> " ) ; out.write (" <pct:"+operacao+"> " ) ; BufferedHeader bufLeitura = new BufferedReader (new FileReader(arquivo); boolean eof = false; while !ebf)
String línhá = bufLeitura.readLine(); if (linha == null)
eof = true; else
out.write(linha, 0, linha.length)); i bufLeitura.close(); out.write " </pct:"+operacao+"> "; out:write (• </pct:operacao> " ) ; return true; ) else returrt- false;
catch (IOException e) System.out. println ("Erro ao inserir arquivo no envelope."),-System.out.println(e.toString()); return false;
)
public String getNomeArquivoPacote() return nomeArquivoPacote;
Listagem E.8 — Classe GeraEnvelope (arquivo GeraEn.veIope.java)
Apêndice E - Códigos Fonte do Protótipo 142
import Java.io. *; import Java.util- *; import j ava.text.*; import j ava.net.URLEncoder; import Java.net.HttpURLConnection; import j ava.net.URL; import javax.servlet.*; import javax.servlet.http.*; import gov.miiit.orgaoTransito.OrgaoTransito; import gov.miiit.orgaoAutuador.Ait; import gov.miiit-tipos.*;
public class EnviaXmlPlacas extends HttpServlet (
public void doGet(HctpServletRequest request, HttpServletResponse response)
throws IOExcept ion, ServletException ServletOutputStream out = response.getOutputStream); response.setContentType("text/plain"); // Verifica os veículos sem identificação e gera o documento xmlPlacas
String nomeArqPlacas = Ait.veiculoSemldentificacao(); if (nomeArqPlacas.equals('NENHUM")) out.print Iní"Arquivo não foi gerado.");
else File arqPlacas = new File (ParametrosMi iit. DIR_TEMP+" \\ "-+• nomeArqPlacas) ; // Pesquisa o código e a URL do Órgão Central String codigoOrgaoCentral = String.valueOf
(OrgaoTransito.obterCodigoOrgaoCentral()); URL urlOrgaoCentral = OrgaoTransito.obtfirUrlOrgaoCentral(),-// Cria o envelope que envolverá o documento xmlPlacas GeraEnvelope xmlPacote = new GeraEnvelope();
xmlPacote.iniciaEnvelope(codigoOrgaoCentral, urlOrgaoCentral.toString() ) ; xmlPacote.insereArquivo(arqPlacas,"obterVeiculos"),-xmlPacote.fechaEnvelope(); arqPlacas.delete(i;
// Busca o nome do arquivo com o Pacote de Transmissão String nomeArqPacote = xmlPacote.getNomeArquivoPacoteO,-try í
// Cria a conecçao HTTP com o Órgão Central HttpURLConnect ion conn = (HttpURLConnection)urlOrgaoCentral.openConnection() // Define o Método de envio conn.setRequestMethodí"POST');
// Define o tipo do conteúdo da mensagem para text/xmi conn.setRequestProperty("Content-Type',"text/xml'); // Lê arquivo com o Pacote de Transmissão e inclui no OutputStream da // conexão com o Órgão Central, em outras palavras, // lê o arquive com o Pacote de Transmissão e inclui o seu conteúdo
// no corpo da mensagem HTTP try ( File arqEntrada = new File ParametrosMi 1 it. OIR_TSMP+ • \\" tnameAtrqPacote) ; BufferedReader bufEntrada = new BufferedReader(new FileReader(arqEntrada)) // Define o corpo da mensagem conn.setDoQutput(true); OutputStream outEnvia = conn.getOutputStream); boolean eof = false; while (ieof)
String linha = bufEntrada.readLine(); if (linha == null) eof = true;
else String linhaEne = URLEncoder.encode(1inha); outEnvia.write(linhaEnc.getBytes());
bufEntrada. close () ,-// Apaga o arquivo com o Pacote de crar.smissão enviado arqEntrada.delete ();
) catch (IOException e) ( System.out.println ("Erro Saida - "+e.toString());
) // Conecta ao site remoto conn.connect(;• li Processa reposta do servidor remoto InputStreamReader in = new inputStreamReader(conn.get InputStream());
Apêndice E - Códigos Fonte do Protótipo
AnalisaPacote pacote = new AnalisaPacote); if (pacote.parser(in)) out.printlní"Foram enviadas as placas e processada a resposta."); String nomeArqRetorno = pacote.getNomeArquivoPacote(); if (!nomeArqRetorno.equals("NENHUM")) ( out.println(
"Foram retornadas informações pelo Órgão Central que não foram processadas.");
out.printIn("Arquivo de nome: "+nomeArqRetorno); )
else out.println("Erro no processamento do envelope retornado com xmlVeiculos."
// Desconectando conn.disconnect();
catch (Exception e) System.out.println("Erro geral - " + e.toString(();
) )
public void doPost(HCtpServleCReguest request, HttpServletResponse response)
throws IOException, ServletException doGet(request, response);
Listagem E.9 - Sevlet EnviaXmlPiacas (arquivo EnviaXmlPlacas.java)
import ]ava.10.*; import j ava.ut i1.*; import j ava.t ext.*; import Java.net.URLEncoder; import Java.net.HttpURLConnection; import j ava.net.URL; import javax.servlet.*; import javax.servlet.http.*; import gov.miiit.orgaoTransito.OrgaoTransito; import gov.miiit.orgaoAutuador.Ait; import gov.miiit.tipos.*;
public class EnviaXmlAit extends HttpServlet (
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException ( ServletOutputStream out = response.getOutputStream(); response. set Content Type " text/plain") ,-// Verifica os AIT's que ainda não foram enviados a seus respectivos destinos String[]í] vetorArqAit = Ait.obterAitsNaoEnviados(]; if ívetorArqAit[0][0].equals("NENHUM")) out.println"Não foram gerados documentos xmlAit.");
else if (vetorArqAit[0][0].equals("ERRO")) out.println("0 correu um erro durante a criação dos documentos xmlAit.");
) else int tamanho = vetorArqAit.length;
for int i = 0; i < tamanho; i++) if (vetorArqAit[i][Oj == null)
break; File arqAit - new File (ParametrosMiiit. DIR_TEMP+ " \ \ "+vetorArqAit f i] [ 0 ) ,-// Pesquisa o código e a URL do Órgão de Trânsito Conveniado String codigoOrgaoTransito = String.valueOf
(OrgaoTransito.obterCodigoOrgaoTransito(vetorArqAit[i][1] URL urlOrgaoTransito = OrgaoTransito.obterUrlOrgaoTransito(vetorArqAit[i][1]) // Cria o envelope que envolverá o documento xmlAit GeraEnvelope xmlPacote = new GeraEnvelope(); xmlPacote.iniciaEnvelope(codigoOrgaoTransito, urlOrgaoTransito.toString()); xmlPacote.insereArquivo(arqAit,* carregarAitExterno"); xmlPacote.fechaEnvelope(); arqAit.delete(); // Busca o nome do arquivo com o Pacote de Transmissão String nomeArqPacote = xmlPacote.getNomeArquivoPacote(); try
// Cria a conecção HTTP com o Órgão de Tránsito Conveniadc
Apêndice E - Códigos Fonte do Protótipo
HttpURLConnection conn s= (HttpuTUlConnectionJurlOrgaoTransito.openConnection() // Define o Método de envio cònn.setRequestMethod("POSTw) ; // Define o tipo do conteúdo da mensagem para text/xml conn.setRequestProperty("Content-Type *,"text/xml"; //Lê arquivo com o Pacote de Transmissão e inclui no OutputStream da // conexão com o Órgão de Trânsito Conveniado, em outras palavras, // lê o arquivo com o Pacote de Transmissão e inclui o seu conteúdo // no corpo da mensagem HTTP try File arqEntrada = new FilefParametrosMiiit.DIR_TEMP+"\.\•+nomeArqPacoteJ ; BufferedReader bufEntrada = new BufferedReader(new FileReader(arqEntrada)) // Define o corpo da mensagem conn.setDoOutput(true); OutputStream outEnvia .= conn.getOutputStream(); boolean eof = false; while (Jeof)
String linha = bufEntrada.readLineí); if (linha == null)
eof = true; else String linhaEnc = URLEncoder.encode(linha); outEnvia. write (lirihaEnc .getBytes (),) ;
bufEntrada.close(); // Apaga o arquivo com o Pacote de transmissão enviado arqEntrada.delete();
catch (IOException. e) ( System.out.println ("Erro Saidã - "+e.toString());
// Conecta ao site remoto conn.connect(); // Processa reposta do servidor remoto InputStreamReader in-= new InputStreamReader(conn.getlnputstream); AnalisaPacote pacote - = new AnalisaPacote(); if (pacote.parser(in)) out.println("Enviados AIT's para "+vetorArqAit[i] [1]+"."); String nomeArqRetorno = pacote.getNomeArquivoPacote); if (!nomeArqRetorno.equals("NENEUM")) out.println("Foram retornadas informações pelo Órgão de •+
vetorArqAit[i][1]+" que não foram processadas."); out-println "Arquivo de nome: *tnoineArgRetorno) ;
else out.printIn( "Erro no processamento do envelope retornado com xmlRetornoAit do estado vetorArqAit [.i] [1] +".") ;
// Desconectando conn.disconnect() ;
catch (Exception e) System.out.println("Erro geral - "+e.toString());
) •
J
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException Í doGetrequest, response);
Listagem E.10-Sevlet EnviaXmlAit (arquivo EnviaXmlAJt.java)
import Java.id.*; import java.util.*; import j ava. text. *" ; import jaya.net.*,-import javax.serylet."; import j avax.serviet-http.*;
public class RecebePacoteWeb extends HttpServlet
Apêndice E - Códigos Fonte do Protótipo
p u b l i c v o i d 'doGet (Ht tpServ le tReques t r e q u e s t , H t t p S e r v l e t R e s p o n s e r e s p o n s e )
t h r o w s JOExceptiorir S e r v l e t E x c e p t i o n
b o o l e a n e r r o - f a l s e ; S t r i n g d e s c r i ç ã o - new S t r i n g ) ; S t r i n g mensagem = new S t r i n g O ; S t r i n g l i n h a = new S t r i n g ( ) í S t r i n g l i n h a D e c * new S t r i n g O ; Serv le tOutputStreãm o u t = r e s p o n s e . g e t O u t p ü t S t r e a m ( ) ; r e s p o n s e . s e t C o n t e n t T y p e í " t e x t / p l a i n " ) ; boolean, eof « f a l s e ; BufferedReader Anp = r e q u e s t . g e t R e a d e r ( ) ; t^^Recpder decoder = new URLDecoder ( ) ; w h i l e (!eof> Í 5,
l i n h a = i n p . r e a õ X i n e ( ) ; i f ( l i n h a ^ n u l l )
e o f •= "true; e l s e
l i n h a D e c = l i n h a D e c + d e c o d e r . d e c o d e ( l i n h a ) ; i A n a l i s ã P a c d t e p a c o t e = new Axial i saPa c o t e ) ; I f i( p a c o t e , p a r s e r ( l i n h a D e c ) )
i f !pacote .getHomeArquivoPacote) .equals("NENHUH"')) F i l e arqRespos ta = new Fi le (pacote .ge tCaro inhoAxquivoPacote ) . ) g BufferedReader bufDados = new BufferedReader(new F i l e R e a d e r ( a r q R e s p o s t a ) J ; e o f s f a l s e ; w h i l e ( ! e o f ) C
l i n h a = b u f D a d o s . r e a d b i n e i ) ; i f ( l i n h a == n u l l )
eo f = t r u e ; e l s e
.String l i n h a E n c = u R L t o c o ô ^ . e r i ç o ã e ( l i n h a ) ; ou t .pr incXn(XinhaEnc) ;
.>
/ / Feeha o 53.uso da r e s p o s t a h u f 0 a d o s . c l q E e ( ) r a r q R e s p o s t a . d e l e t e (J „•
e l s e b u t . pr ir.T- ".r. I -NENHUM") i
1 e l s e o u t . p r i n t l r . ( "i r r d ' d u r a n t e o. p a r s e r . " ) ?
public void doPOHt t::tcpServletRequest request, %.*pServletResponse re sponse )
throws iObxccot .or.,., S e r v l e t E x c e p t i o n
Í DOGET REQUEST * RESPONSE) >F
Listagem E.31 -Sevlet RecebePacoteWeb (arquivo RecebePacoteWeb.java)
£.3 - Códigos Fonte das Páginas HTML <html>
<head> <titie>Veri£ica or igem de v e í c u l o s . - KHI-T<- / t i t l e> </head> <bódy>
< c e n t e r > <b>Modelo d e i n t e r c â m b i o de infbrmacSes de i n f r a ç S e s de Trans i to<br><br> PROTÓTIPO</b> ' <hr> < t a h l e . b o r â e r = l >
< tr> < t d width=80% a i i g n = " c e n t e r " va l ign="middle">
< h l > V e r i f i c a r origem de v e í c u l o s < / h l > < / t d >
< / t r > < t r >
< t d h e i g h t = 1 5 0 a l ign=-center -" v a l i g » = "middle•> •<form ãc t ión="ht tpr / / l oca lhQSt :8080 /examples / s erv l e t /Err7 ' i aXin lP lac .a s" meüiod=».post">-
Apêndice E - Códigos Fonte do Protótipo 146
<input type="submit' value="Verificar Veículos"> </form> </td>
</tr> </table> </center>
</body > </html>
Listagem E.12 - Página HTML VerificarOrigemVeiculo (arquivo VerificarOrigemVeiculo.html)
<html> <head>
<title>Enviar AIT - MIIIT«;/title> </head> <body>
<center> <b>Modelo de Intercâmbio de Informações de Infrações de Transito<brxbr> PROTÓTTPO</b> <hr> <table border=l>
<tr> <td width=8Q% align="center" valign="middle"> <hl>Enviar AIT 1s para Órgãos Conveniados</hl>
</td> </tr> <tr> <td height=150 align="center" valign-"middle"> <form action="http://localhost:8080/examples/servlet/EnviaXmlAit* method="post">
<input type="submit' value="Enviar AIT's"> </form>
</td> </tr>
</table> </center>
</body> </html>
Listagem E.13 - Página HTML VerificarOrigem Veiculo (arquivo VerificarOrigemVeiculo.html)
Apêndice E - C ó d i g o s Fonte do Protótipo 147
Referências Bibliográficas
[ARMSOO] ARMS, William Y. - Digital Library - The MIT Press, Massachusetts,
2000.
[BOOCOO] BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar - UML -
Guia do Usuário - Editora Campus, Rio de Janeiro, 2000.
[BIRO01] BIRON, Paul V.; MALHOTRA, Ashok. - XML Schema Part 2:
Datatypes - W3C Recommendation - Word Wide Web Consortium, 2 May 2001.
(em http://www.w3.org/TR/2001/REC-xrnlschema-2-20010502)
[BRAY00] BRAY, Tim; PAOLI, Jean; SPERBERG-McQUEEN, CM.; MALER,
Eve. - Extensible Markup Language (XML) 1.0 (Secound Edition) — W3C
Recommendation - Word Wide Web Consortium, 6 October 2000. (em
http://www.w3.org/TR/REC-xml-20001006, 2000 - obtido em 02/04/2001)
[BROW02] BROWNEL, David - SAX- SouceForge (em http://sax.sourceforge.net/,
obtido em 01/03/2002)
[CARL01] CARLSON, David - Modeling XML Applications with UML - Praticai
e-Business Applications — Addison-Wesley, 2001.
[CELE01] CELEPAR, Companhia de Informática do Paraná - Sistema Conveniado
de Multas de Trânsito - Soluções para Governo - Trânsito, 2000. (em
http://celepar7cta.pr.gov.br/CELEPAR/SiteCel.nsf/Principal70penFrameSet
obtido em 17/09/2001)
[COWA01] COWAN, John; TOBIN, Richard - XML Information Set - W3C
Recommendation - Word Wide Web Consortium, 24 October 2001. (em
http://www.w3.org/TR/2001/REC-xml-infoset-20011024)
[DENA02] DENATRAN - Proposta de Layout RENACOM - Versão Preliminar 02
~ Departamento Nacional de Trânsito, Documento Interno, 2002.
[ELMA00] ELMASRI,R. and NAVATHE,S.B. Fundamentals of Database Systems.
3 r d edition, Addison-Wesley Publishing Company, Massachussetts, 2000.
Referências Bibliográficas 148
[FALL01] FALLSIDE, David C. - XML Schema Part 0: Primer - W3C
Recommendation - Word Wide Web Consortium, 2 May 2001. (em
http://ww.w3.org/TR/2^
[FOLH98] FOLHA DE SÃO PAULO - Especial - Guia do Trânsito - São Paulo,
22 de janeiro de 1998.
[FRAN00] FRANKLLNT, Kleitor. - Delphi 5 Para Internet com Banco de Dados -
Editora Érica, São Paulo, 2000.
[FURL98] FURLAN, José Davi - Modelagem de Objetos Através da UML -
Makron Books, São Paulo, 1998.
[GUDGOla] GUDGIN, Martin; HADLEY, Marc; MOREAU, Jean-Jacques;
NIELSEN, Henrik Frystyk. - SOAP Version 1.2 Part 1: Messaging Framework -
W3C Working Draft - Word Wide Web Consortium, 17 December 2001. (em
http://www.w3.org/TR/2001AVD-soapl2-partl-20011217/)
[GUDGOlb] GUDGIN, Martin; HADLEY, Marc; MOREAU, Jean-Jacques;
NIELSEN, Henrik Frystyk. - SOAP Version 1.2 Part 2: Adjuncts - W3C Working
Draft - Word Wide Web Consortium, 17 December 2001. (em
http://www.w3.org/TR/2001/WD-soapl2-part2-200112l7/)
[JAC099] JACOBS, Ian; LE HORS, Arnaud - HTML 4.01 Specification - W3C
Recommendation - World Wide Web Consortium, 24 December 1999. (em
http://www.w3.org/TR/1999/REC-html401-19991224, 1999 - obtido em
02/04/2001)
[HORS00] LE HORS, Arnaud; LE HÉGARET, Philippe; WOOD, Lauren; NICOL,
Gavin; ROBIE, Jonathan; CHAMPION Mike; BYRNE, Steve - Document Object
Model (DOM) Level 2 Core Specification - Version 1.0- W3C Recommendation
Word Wide Web Consortium, 13 November 2000. (em
http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113)
[LEMA01] LEMAY, Laura; CADENHEAD, Rogers - Aprenda em 21 dias Java 2 -
Professional Reference - Editora Campus, Rio de Janeiro, 2001.
Referências Bibliográficas 149
[LIGH99] LIGHT, Richard - Iniciando em XML - Makron Books, São Paulo, 1999.
[MACHOO] MARCHAL, Benoít - XML - Conceitos e Aplicações - Editora
Berkeley, São Paulo, 2000.
[MARC99] MARCON, Antônio Marcos - Aplicações e Banco de Dados para
Internet - Érica, São Paulo, 1999.
[MCRT99] MARCORATTI, José Carlos - ASP /ADO - Banco de Dados na Internet
- Visual Books, Florianópolis, 1999.
[MICR98] MICROSOFT CORPORATION - Manual On-line do Personal Web
Server -1998.
[MICR01] MICROSOFT CORPORATION - The ODBC Programmer's Reference
- MSDN, Copyright © 1998-2001. (em http://msdn.microsoft.com/library/
default.asp?url=/Ubrary/en-us/odbc/htn^odbcabout_this_manual.asp - obtido em
15/02/2002)
[MEGGOO] MEGGINSON, David - SAX2: The Simple API for XML - Megginson
Technologies, 5 May 2000. (em http://www.megginson.com/SAX)
[MITR01] MITRA, Nilo. - SOAP Version 1.2 Part 0: Primer - W3C Working Draft
Word Wide Web Consortium, 17 December 2001. (em
http://www.w3.org/TR/2001/WD-soapl2-partO-20011217/)
[PROC00] PROCERGS - Troca Eletrônica de Infrações de Trânsito entre Estados
- Porto Alegre, 2000.
[RFC821] POSTEL, J.B. - RFC 821: Simple Mail Transfer Protocol - IETF,
Information Sciences Institute, August, 1982. (em
http ://www .ietf.org/rfc/rfc0821 .txt)
[RFC9591 POSTEL, J.; REYNOLDS, J. - RFC 959: File Transfer Protocol (FTP) -
IETF, October, 1985. (em http://www.ietf.org/rfc/rfc0959.Ut)
[RFC1939] MYERS, J.; ROSE, M. - RFC 1939: Post Office Protocol - Version 3 -
IETF, May, 1996. (em http://www.ietf.org/rfc/rfcl939.txt)
Referências Bibliográficas 150
[RFC1945] BERNERS-LEE, T.; FIELDING, R.; FRYSTYK, H - RFC 1945:
Hipertext Transfer Protocol — HTTP 1.0 - IETF, May, 1996. (em
http://www.ietf.org/rfc/ rfcl945.txt)
[RFC1991] ATKINS, D.; SGALLDMGS, W.; P. ZIMMERMANN - RFC 1991: PGP
Message Exchange Formats - IETF, August, 1996. (em http://www.ietf.org/rfc/
rfcl991.txt)
[RFC2045] FREED, N.; BORENSTEIN, N. - RFC 2045: Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies - IETF,
November, 1996. (em http://www.ietf.org/rfc/rfc2045.txt)
[RFC2396] BERNERS-LEE, T.; FIELDING, R.; MASLNTER, L. - RFC 2396:
Uniform Resource Identifiers (URI): Generic Syntax - IETF, August, 1998. (em
http://www.ietf.org/rfc/rfc2396.txt)
[RFC2616] FIELDING, R.; GETTYS, J.; MOGUL, J.; FRYSTYK, H.; MASINTER,
L.; LEACH, P.; BERNERS-LEE, T. - RFC 2616: Hipertext Transfer Protocol -
HTTP 1.1- IETF, June, 1999. (em http://www.ietf.org/rfc/rfc2616.txt)
[RIZZOO] RIZZARDO, Arnaldo - Comentários ao Código de Trânsito Brasileiro -
Editora Revista dosTribunais, 2 a edição, São Paulo, 2000.
[SFAG01] Software AG - Tamino - Software AG, 2001.
(http://www.softwareag.conVtammoplatform/introduction.htm - obtido em
10/04/2001)
[SUN99] SUN MICROSYSTEMS, Inc. - Getting Started with the JDBC API -
The Souce for Java Technology, java.sun.com, September, 1999. (em
http://java.sun.eom/j2se/l.3/docs/guide/jdbc/getstait/GettingStartedTOC.fm
obtido em 10/03/2002)
[SUN02a] SUN MICROSYSTEMS, Inc. - Java API for XML Processing ("JAXP")
- The Souce for Java Technology, java.sun.com, Copyright © 1995-2002. (em
http://java.sun.com/xml/jaxp/, obtido em 01/03/2002)
Referências Bibliográficas 151
[SUN02b] SUN MICROSYSTEMS, Inc. - JDBC Data Access API - The Souce for
Java Technology, java.sun.com, Copyright © 1995-2002. (em
http://java.sun.com/products/jdbc/, obtido em 10/03/2002)
[TANE97] TANENBAUM, A.S. - Redes de Computadores - Editora Campus, 4 a
Edição, Rio de Janeiro, 1997.
[TAUR97] TAURION, Cezar - Perspectivas Atuais de Desenvolvimento para as
Intranets - em: Developer's Magazine, ano 1, n°. 7, pp. 18-20; Março, 1997.
[THOM01] THOMPSON, Henry S.; BEECH, David; MALONEY, Murray;
MENDELSON, Noah. - XML Schema Part I: Structures - W3C
Recommendation - Word Wide Web Consortium, 2 May 2001. (em
http://www.w3.org/TR/2001/REC-xmlschema-l-20010502)
[UNICOI] UNICAMP: Equipe de Segurança em Sistemas e Redes - Documentos -
Conceitos Básicos - UNICAMP, 2001. (em http://www.security.unicamp.br/docs/
conceitos/index.html - obtido em 10/04/2001)
[W3C01] Word Wide Web Consortium - HyperText Markup Language - Home
Page - Word Wide Web Consortium, 2001. (em http://www.w3.org/MarkUp -
obtido em 02/04/2001)
[W3C99] Word Wide Web Consortium - CGI: Common Gateway Interface -
Word Wide Web Consortium, October, 1999 (em http://www.w3.org/ CGI -
obtido em 16/09/2001)
Referências Bibliográficas 152