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