UM PROTÓTIPO PARA TROCA DE DADOS ENTRE EMPRESAS USANDO XML

Transcrição

1 ALEX RODRIGO SANTIN UM PROTÓTIPO PARA TROCA DE DADOS ENTRE EMPRESAS USANDO XML Monografia apresentada à UNOCHAPECÓ como parte dos requisitos para obtenção do grau de Bacharel em Ciência da Computação. Orientador: Elton Luís Minetto Chapecó - SC, Julho de 2006.

2 i UM PROTÓTIPO PARA TROCA DE DADOS ENTRE EMPRESAS USANDO XML ALEX RODRIGO SANTIN Esta Monografia foi julgada para obtenção do título de Bacharel em Ciência da Computação, na área de concentração e aprovada pelo curso de Ciência da Computação. ORIENTADOR(A): Prof. Elton Luís Minetto CO-ORIENTADOR: César Antonio Bortolini COORDENADOR(A) DO CURSO: Prof.ª Mônica Tissiani de Toni Pereira BANCA EXAMINADORA PRESIDENTE: Prof. Elton Luís Minetto Prof. Jose Alexandre de Toni Prof. Jorge Antonio Di Domenico

3 ii AGRADECIMENTOS Agradeço a Deus e aos anjos por permitirem que eu chegasse ao fim deste curso vivo e com saúde. Aos meus pais e irmãos pelo apoio massivo durante todo o curso. A minha orientadora na primeira fase deste trabalho Professora Jusane Farina Lara, pela grande participação e apoio. Ao meu orientador na segunda fase deste trabalho Professor Elton Luis Minetto, pela preocupação e pelas dicas e principalmente por ter aceitado me orientar mesmo sem tempo disponível. Ao meu co-orientador César Antonio Bortolini pelo apoio, pelas idéias e dicas a cerca do problema a ser resolvido por este trabalho. A minha esposa Maria Rosa Rita, por ter me apoiado e incentivado em todos os momentos. Aos meus colegas de curso pela ajuda nos momentos em que mais precisei. A empresa Expresso São Miguel Ltda, por permitir e apoiar o desenvolvimento trabalho.

4 iii SUMÁRIO LISTA DE FIGURAS... v LISTA DE QUADROS... vi LISTA DE TABELAS...vii LISTA DE SIGLAS E ABREVIATURAS...viii RESUMO... x ABSTRACT... xi 1 INTRODUÇÃO ORGANIZAÇÃO DO TRABALHO A LOGÍSTICA EMPRESARIAL A INTEGRAÇÃO DA LOGÍSTICA E SUPPLY CHAIN MANAGEMENT Supply Chain Management (SCM) A TECNOLOGIA DA INFORMAÇÃO NA LOGÍSTICA A EMPRESA OBJETO DE ESTUDO CUSTOMER RELATIONSHIP MANAGEMENT (CRM) OFERECENDO SERVIÇOS AOS CLIENTES GESTÃO DO CICLO DE VIDA DO CLIENTE TIPOS DE CRM Resgatando Clientes Identificar e buscar clientes potenciais O processo de fidelização do cliente Cross-sell e up-sell SUBDIVISÕES DE CRM CONSIDERAÇÕES TECNOLOGIAS ENVOLVIDAS BANCO DE DADOS E SGDBS MODELO RELACIONAL Estrutura de um banco de dados relacional REDES DE COMPUTADORES Arquitetura TCP-IP A WEB E O PROTOCOLO HTTP Diferenças entre HTTP 1.0 e HTTP A REDE INTERNET EXTENSIBLE MARKUP LANGUAGE (XML) INTRODUÇÃO CONSIDERAÇÕES SOBRE A LINGUAGEM HTML...32

5 iv Estrutura e composição da linguagem HTML CONSIDERAÇÕES DA XML Documentos bem-formados PARSERS DECLARAÇÃO XML DEFINIÇÕES DE TIPO DE DOCUMENTO (DTD) Entidades Elementos Atributos API S XML Document Object Model (DOM) Simple API for XML (SAX) NAMESPACES EXTENSIBLE STYLESHEET LANGUAGE (XSL) XPath XSL Transformations (XSLT) ELETRONIC DATA INTERCHANGE (EDI) A EDI NA LOGÍSTICA DE TRANSPORTES XML/EDI O QUE É XML/EDI? MEIOS DE TRANSMISSÃO APLICAÇÕES XML/EDI SITUAÇÃO ATUAL O CONTEXTO DO TRABALHO PROBLEMAS VIVIDOS PROPOSTA O PROTÓTIPO CONSIDERAÇÕES ANALISE DE REQUISITOS Requisitos Funcionais Requisitos Não-Funcionais DIAGRAMA DE CONTEXTO DIAGRAMA DE FLUXO DE DADOS (DFD) MODELO FÍSICO DO BANCO DE DADOS MÓDULO ADMINISTRATIVO MÓDULO DE ACESSO USUÁRIO Interface FUNCIONAMENTO INTERNO Módulo Administrativo Módulo de acesso a usuários (clientes) MODELO NAVEGACIONAL PORQUE USAR A LINGUAGEM PHP APLICAÇÃO DO PROTÓTIPO (TESTE DE USO) CONCLUSÕES TRABALHOS FUTUROS REFERÊNCIAS ANEXOS...124

6 v LISTA DE FIGURAS Figura 1: As subdivisões do CRM e seus componentes...16 Figura 2: Exemplo de tabela em um banco de dados relacional HEUSER (2000)...20 Figura 3: Pilha TCP/IP...24 Figura 4: Camadas TCP/IP e respectivos serviços...24 Figura 5: Fragmento de código XML CAGLE et al. (2000) Figura 6: Fragmento de código XML exibido no IE 6.0. CAGLE et al. (2000)...37 Figura 7: Estrutura hierárquica de um documento XML bem-formado Figura 8: Documento XML...42 Figura 9: Arquivo aviso.dtd...43 Figura 10: Exemplo documento XML simples...49 Figura 11: Documento XML representado em forma de árvore...50 Figura 12: Modelo de memória DOM (conceitual)...50 Figura 13: Fragmento de arquivo XSL...54 Figura 14: Arquivo CPF/CNPJ.ctrc.emb.xml...55 Figura 15: Árvore de diretórios do sistema operacional MS Windows...55 Figura 16: Exemplo de arquivo XML...56 Figura 17: Exemplo de arquivo XSL...57 Figura 18: Arquivo aviso.xml exibido no IE Figura 19: Exemplo trajeto logístico...69 Figura 20: Exemplo de arquivo texto para EDI...71 Figura 21: O protótipo em relação ao SCM...75 Figura 22: Esquema do protótipo (redes de computadores)...76 Figura 23: Diagrama de contexto do protótipo...80 Figura 24: Tela de inserção de novos usuários...84 Figura 25: Tela de pesquisa de usuários...85 Figura 26: Tela de alteração de usuários...86 Figura 27: Tela de exclusão de usuários...87 Figura 28: Tela listar usuários...88 Figura 29: Pesquisa acessos por data...89 Figura 30: Resultado da busca de acesso por data...90 Figura 31: Resultado da busca de acessos por usuário...91 Figura 32: Tela de geração de CTRCs embarcados...93 Figura 33: Tela de opção de tipo de envio de arquivo...94 Figura 34: Tela de geração dos arquivos de fatura...95 Figura 35: Tela de escolha de envio dos arquivos de fatura...96 Figura 36: Tela de visualização do arquivo de fatura...97 Figura 37: Fragmento de código PHP que gera CTRCs embarcados Figura 38: Trecho PHP que envia arquivos por , exibe e inicia download Figura 39: Arquivo entrega.nf.xsl usado para exibir o arquivo XML de entregas Figura 40: Tela responsável pela importação dos arquivos XML Figura 41: Relatório de CTRCs embarcados e respectivas notas fiscais Figura 42: Relatório de títulos transportadora Figura 43: Relatório de entregas de notas fiscais Figura 44: Tabela de ocorrências possíveis para CTRCs...116

7 vi LISTA DE QUADROS Quadro 1: Exemplo de declaração da linguagem XML...41 Quadro 2: Exemplo de declaração de uma entidade geral...44 Quadro 3: Exemplo de referência a uma entidade geral...44 Quadro 4: Exemplo de indicação de conteúdo externo de uma entidade...44 Quadro 5: Exemplo de declaração de uma entidade de parâmetro...45 Quadro 6: Exemplo de entidade predefinida...45 Quadro 7: Expressão análoga ao demonstrado no quadro Quadro 8: Exemplo de aplicação operador (,)...47 Quadro 9: Exemplo de aplicação operador ( )...47 Quadro 10: Exemplo de declaração de atributos...47 Quadro 11: Exemplo de declaração URI de um Namespace...52

8 vii LISTA DE TABELAS Tabela 1: Exemplos de referência numérica de entidades predefinidas...45 Tabela 2: Operadores de ordem e seus significados...46 Tabela 3: Tabela de valores padrão possíveis para um elemento....48

9 viii LISTA DE SIGLAS E ABREVIATURAS ASP API CGI CRM CTRC DOM DTD EDI ERP FTP HTML HTTP HTTPS IB IE MIME Application Service Provider Application Programming Interface Commom Gateway Interface Customer Relationship Management Conhecimento Rodoviário Transporte de Carga Document Object Model Document Type Definition Electronic Data Interchange Enterprise Resource Planning File Transfer Protocol HiperText Markup Language HyperText Transfer Protocol HyperText Transfer Protocol Secure Borland Interbase Internet Explorer Multipurpose Internet Mail Extensions

10 ix PHP SAX SCM SGDB SGML SMTP SSL TCC TI VAN W3C WEB XML XSL Hypertext Preprocessor The Simple API for XML Supply Chain Management Sistema Gerenciador de Banco de Dados Standard Generalized Markup Language Simple Mail Transfer Protocol Secure Sockets Layer Trabalho de Conclusão de Curso Tecnologia da Informação Value Added Network Word Wide Web Consortium World Wide Web Extensible Markup Language Extensible Stylesheet Language

11 x RESUMO Este trabalho tem por objetivo realizar através do estudo dos conceitos e tecnologias de Logística Empresarial, Customer Relationship Management, Banco de Dados, Redes de Computadores, Extensible Markup Language e Eletronic Data Interchange a implementação de um protótipo que demonstre uma proposta financeira e computacionalmente viável de resolver o problema vivido atualmente em torno do intercâmbio eletrônico de dados, aplicando-o ao estudo de caso da empresa Expresso São Miguel Ltda. Por se tratar de uma empresa do ramo logístico, o trabalho se enquadra neste contexto buscando prover padronização no tipo de arquivo para transferência e layout do mesmo usando a linguagem de marcação Extensible Markup Language e também na geração e transferência dos arquivos usando a linguagem Hypertext Preprocessor (PHP). Palavras-chave: intercâmbio eletrônico de dados, Extensible Markup Language, logística empresarial e comunicação entre sistemas empresariais.

12 xi ABSTRACT This work has the goal to carry out a study of the concepts and technologies of Logistics Enterprise, Customer Relationship Management, Data base, Computer networks, Extensible Markup Language and Electronic Interchange Date. The prototype implementation shows the proposal viability (financial and computationally) for the problem faced currently in electronic interchange of data in the domain of the Company Expresso São Miguel Ltda (the chosen case of study). The company works in the logistics area; it demands standardization in the exchange of data and layout. The proposal reaches the standardization by using Extensible Markup Language. Also, the generation and transference of the archives using the language Hypertext Preprocessor (PHP) contributes in such standardization. Key-words: electronic interchange of data, Extensible Markup Language, logistic enterprise and communication between enterprise systems.

13 1 INTRODUÇÃO Desde a década de 90, as empresas de um modo geral buscam maneiras de fortalecer seus laços comerciais e estabelecer parcerias a fim de tornarem-se mais competitivas e obter um melhor gerenciamento dos produtos que comercializam e serviços que prestam. É difícil imaginar uma empresa que não esteja inserida numa cadeia de suprimentos, pois de uma forma ou outra, seus produtos ou matérias-primas são transportadas de um local geográfico para outro para serem manufaturados ou comercializados. Ao longo desta cadeia o valor agregado dos produtos é incrementado e em geral as empresas sentem a necessidade de controlar e gerenciar os prazos de entrega dos seus produtos, seja para melhor atender seus clientes ou para garantir o controle operacional e financeiro de suas operações comerciais. Frente a isso, é imprescindível que a informação entre as empresas flua com rapidez e segurança, e que a linguagem de comunicação seja comum. Por isso a cada dia mais empresas adotam o sistema de transferência de dados por meio eletrônico, pois aos poucos percebem as vantagens que o sistema oferece como redução de custos, agilidade e redução de falhas humanas. De acordo com a realidade exposta acima este trabalho propõe uma forma de baixo custo e funcional de efetuar as transferências de dados por meio eletrônico, sanando os problemas atuais como falta de padrão no tipo de arquivo e layout, bem como modo de geração e transferência fazendo uso da linguagem PHP e do Sistema Gerenciador de Banco de Dados Borland Interbase e da linguagem Extensible Markup Language (XML). Utilizando os conhecimentos adquiridos neste estudo a proposta baseia-se resumidamente em uma aplicação WEB codificada em PHP, que possibilita que os clientes da empresa objeto de estudo possam gerar e obter arquivos de intercâmbio de modo rápido e simples, podendo visualizá-los se desejado, antes de recebê-los por ou efetuarem download dos mesmos. Arquivos estes, codificados usando a linguagem XML, que impõe de certo modo regras e padrões tornando a comunicação entre sistemas de informação mais

14 2 robusta e fácil de implementar, sendo muito mais confiável do que simples arquivos texto que fazem uso de diversos tipos de separadores de dados para possibilitar a leitura dos mesmos, usados atualmente. Ao longo deste trabalho fica claro a necessidade e a importância do mesmo para a empresa objeto de estudo devido ao contexto em que a mesma está inserida e os problemas que vem tendo com o modelo atual. Esta primeira experiência com a linguagem XML irá colaborar significativamente em futuros projetos, sendo aprimorada e incrementada a fim de tornar-se mais poderosa e abrangente. 1.1 ORGANIZAÇÃO DO TRABALHO Este trabalho esta dividido em onze capítulos, sendo o capitulo de número um apenas introdutório. O capítulo dois trata dos conceitos e particularidades do ramo de atuação da empresa objeto deste estudo, ou seja, aborda aspectos conceituais sobre logística empresarial, ligação entre a logística e gerência da cadeia de suprimentos, importância dos sistemas de informação no segmento de mercado e uma breve descrição da empresa objeto de estudo. Já o capítulo três trata da importância do trabalho para a gestão de relacionamento com o cliente, destacando os principais fatores em que o trabalho pode colaborar de forma direta ou indiretamente. No capitulo quatro são abordadas as tecnologias envolvidas diretamente com a proposta deste trabalho, como sistemas gerenciadores de banco de dados relacionais e suas características básicas, redes de computadores abordando mais especificamente o protocolo TCP/IP, a rede Internet e o protocolo HTTP. Por fim uma abrangente abordagem sobre a linguagem XML e suas características principais bem como tecnologias associadas. O capítulo cinco trata do intercâmbio eletrônico de dados (EDI), meios de comunicação, importância para a área de atuação da empresa objeto de estudo e o EDI usando arquivos XML.

15 3 O capítulo seis descreve a problemática atual da empresa e a proposta para solucionar estes problemas, ressaltando aspectos operacionais importantíssimos para o correto entendimento do trabalho. E no capítulo sete temos a descrição do protótipo em si, ou seja, documentação da análise elaborada para implementação do protótipo, diagramas e interface, bem como funcionamento do mesmo. Nos capítulos oito e nove as conclusões obtidas com o estudo e projetos futuros a serem desenvolvidos. Nos capítulos dez e onze estão respectivamente as referências bibliográficas e os anexos.

16 4 2 A LOGÍSTICA EMPRESARIAL De acordo com Fleury, Wanke e Figueiredo (2001), o Brasil passou por muitas mudanças na década de 90, principalmente nas áreas tecnológicas onde se destacam as comunicações e infra-estrutura como meios de transporte cada vez mais eficientes e qualificação da prestação de serviços. Devido à queda na inflação nas últimas décadas, surgiram movimentos de colaboração entre consumidores e fornecedores na cadeia de suprimentos. Isto fez com que muitas empresas abandonassem o individualismo ocasionado pelo período econômico, e começassem a cooperar entre si promovendo o crescimento mútuo com uma melhora muito significativa na qualidade dos serviços prestados. Os investimentos na área da Tecnologia da Informação 1 foram massivos, como por exemplo, a rede de supermercados Pão de Açúcar e das Lojas Americanas, que até alguns anos não possuíam nenhum tipo de interligação EDI com seus fornecedores e optaram por investir fortemente em programas de interligação com seus fornecedores, permitindo que os processos que antes eram demorados e sujeitos a falhas, se tornassem rápidos e seguros. Para Bowersox e Closs (2001), a logística é um processo contínuo que abrange significativa complexidade geográfica. O constante aperfeiçoamento das práticas logísticas torna o ramo, que é um dos mais antigos, um dos mais desafiadores do setor privado. A logística integra transportes, estoques, informações e manuseio de materiais, sendo que a sua principal responsabilidade operacional é disponibilizar matéria-prima e produtos onde são requisitados com menor custo possível. A logística é praticamente uma extensão dos negócios, logo faz parte da satisfação dos clientes. Sendo assim, é indispensável que as empresas busquem parceiros que possam 1 O termo Tecnologia da Informação é definido pelo conjunto de recursos tecnológicos e computacionais para geração e uso da informação (REZENDE, 2000, p. 43).

17 5 integrar a logística ao ramo de negócio, atendendo as necessidades dos clientes com rapidez e segurança, proporcionando total cooperação e harmonia na cadeia de suprimentos. 2.1 A INTEGRAÇÃO DA LOGÍSTICA E SUPPLY CHAIN MANAGEMENT Na visão de Fleury, Wanke e Figueiredo (2001), as mudanças econômicas e tecnológicas fazem da logística uma das concepções gerenciais mais modernas. Os fatores econômicos fazem com que novas metas competitivas sejam estabelecidas, enquanto os fatores tecnológicos proporcionam um melhor gerenciamento das operações logísticas, cada dia mais elaboradas e complexas. A logística integrada deve ser encarada como um instrumento de marketing, gerencial e deve ser capaz de acumular valores, baseando-se nos serviços prestados. A simples integração das funções e atividades do processo logístico não é o bastante. Na verdade buscar a integração dos setores não é um fato particular a empresas do ramo logístico, a integração pode tornar uma empresa competitiva e lhe proporcionar muito sucesso, porém, para que isso possa ocorrer é necessário incluir nesse contexto os clientes e fornecedores, expandindo dessa forma a integração. Bowersox e Closs (2001) ressaltam a importância da integração externa, também chamada gerência da cadeia de suprimentos, que será abordado a seguir. Ainda Bowersox e Closs (2001), levantam fatores relevantes à logística integrada, que são fluxo de materiais, distribuição física, suprimento e fluxo das informações. O fluxo de materiais compreende desde a movimentação da matéria-prima até a entrega do produto final a um consumidor. Durante a movimentação da matéria-prima ou componentes um processo logístico adquire valor e agrega valor ao produto, ou seja, até o produto ficar pronto as movimentações logísticas agregam valor a ele. A distribuição física diz respeito à entrega de mercadorias prontas aos consumidores finais. Esta fase possui a importância de estar intimamente ligada à satisfação do cliente e na efetivação do marketing, pois o cliente espera receber sua encomenda no menor tempo possível, que a mesma esteja em bom estado e que o preço cobrado pelo serviço seja o mínimo possível.

18 6 O suprimento refere-se ao abastecimento de materiais a empresas, indústrias, montadoras ou organizações em geral. Basicamente, trata-se do processo de compra e movimentação de componentes para os empreendimentos mencionados anteriormente. O fluxo de informações é vital no processo logístico, pois serve como base para um gerenciamento efetivo das demais áreas. Sem a informação precisa e na hora certa, os esforços das áreas operacionais correm o risco de não atingirem as metas almejadas. A cooperação e a conversação entre as partes envolvidas nos processos logísticos são benéficas para um serviço eficaz e de qualidade, tornando-se indispensável no dia-a-dia das empresas. Sendo assim, será abordado agora o gerenciamento da cadeia suprimentos, conceituando-o e contextualizando a proposta deste trabalho SUPPLY CHAIN MANAGEMENT (SCM) Devido a grande concorrência das organizações, e o ciclo de vida dos produtos mais curtos, as incertezas do mercado estão cada vez mais fora do controle. A globalização e o dinamismo do mercado faz com que as empresas mudem sua visão antes focada na qualidade de atividades isoladas (atividades internas) como transportes, compras, distribuição entre outros e passem a concentrar seus esforços em melhor gerenciar suas relações externas, buscando meios de integrar-se efetivamente aos seus perceiros de negócio, como clientes e fornecedores a fim de agilizar processos, diminuir custos, estreitar relações comerciais, tornar-se mais competitivas e atualizadas e muitas outras vantagens que a integração de negócios em um contexto de cadeia de suprimentos pode trazer. Seguindo essa mesma linha de pensamento, surgiu na década de 90 o conceito de Supply Chain Management (SCM) que objetiva principalmente aumentar a produtividade, reduzir custos, agregar valor aos produtos e estabelecer formas de integrar e racionalizar atividades e processos de negócio entre fornecedores e consumidores. (FLEURY, WANKE E FIGUEIREDO, 2001). Mentzer et al. 2001, define a cadeia de suprimentos como a combinação de três ou mais entidades (empresas ou indivíduos), relacionados diretamente através de fluxos de entrada e saída de produtos, serviços, finanças ou informações.

19 7 Logo, a integração da cadeia de suprimentos e com isso o estreitamento das relações entre as empresas, é um fato. As empresas não vêem mais seus parceiros como ameaças, pois nesse novo contexto a integração aproxima as empresas de tal forma que umas tornamse extensões das outras, e a preocupação com o sucesso e com o fluxo claro e eficiente das informações é algo imprescindível e necessário. A cadeia de suprimentos é uma rede de empresas interligadas, através de laços logísticos que envolvem basicamente produção e consumo de materiais e serviços (GOMES E RIBEIRO, 2004). Assim, os de sistemas de informações tornam-se componentes essenciais na SCM, pois facilitam e possibilitam a geração, o envio, a recepção e processamento de mensagens eletrônicas (EDI), bem como auxiliam e automatizam os processos, gerando informações e criando conhecimento que contribuem para que através dos fatores mencionados anteriormente, as empresas e a cadeia de suprimento como um todo se tornem mais competitivas e agressivas frente ao mercado garantindo seu espaço. Por isso, a necessidade de contemplar a aplicação da Tecnologia da Informação neste segmento, como será apresentado a seguir. 2.2 A TECNOLOGIA DA INFORMAÇÃO NA LOGÍSTICA Segundo Fleury, Wanke e Figueiredo (2001), o uso de tecnologias de informação combinadas, permitem o gerenciamento do estoque, armazenamento, processamento de solicitações e compras de forma eficiente e eficaz. A Tecnologia da Informação é um fator mestre quando se busca alto nível de integração. Bowersox e Closs (2001) propõem alguns fatores de muita importância no que diz respeito ao uso da TI com foco em sistemas de informação na logística como disponibilidade, precisão, atualizações, flexibilidade e adequação de formatos. disponibilidade: a disponibilidade de dados e informações são vitais, tanto para os clientes como para a tomada de decisões e ainda contribuem minimizando as imprevisões operacionais e gerenciais; precisão: a precisão dos dados é essencial no que diz respeito a consistência dos dados e também na confiabilidade dos mesmos, por exemplo, o status de um

20 8 conhecimento de frete 2 (CTRC) não pode informar ao cliente que a mercadoria foi entregue enquanto a mesma ainda está em trânsito; atualizações: as informações precisam ser atualizadas em tempo hábil, garantindo disponibilidade e precisão, bem como corretude na tomada de decisões; flexibilidade: pode ser considerado como fator mais importante nesse contexto, pois diz respeito ao atendimento das necessidades dos clientes, principalmente garantindo feedback 3 conciso, flexível e adaptável; formatos: diz respeito a interface dos sistemas de informação e do modo de apresentação das informações a usuários e clientes. A mudança na mídia de distribuição de informação, de papel para mídias eletrônicas (arquivos, mensagens, CDs, disquetes entre outros), permitiu que o fluxo de informações fosse acelerado consideravelmente no segmento logístico. A transferência e o gerenciamento eletrônico de informações proporcionam uma oportunidade de reduzir os custos logísticos mediante sua melhor coordenação. Além disso, permite o aperfeiçoamento do serviço baseando-se principalmente na melhoria da oferta de informações aos clientes. (FLEURY, WANKE E FIGUEIREDO, 2001, p. 286) 2.3 A EMPRESA OBJETO DE ESTUDO A Expresso São Miguel é uma empresa que atua no segmento de transportes logísticos rodoviários há dez anos. 2 O contrato de transporte de coisas, onde o transportador se obriga perante o expedidor, a levar e entregar determinada coisa a um destinatário determinado, gera um documento fiscal chamado Conhecimento de frete. No conhecimento de frete constam dados como remetente e destinatário, origem e destino, quantidade de volumes, peso, nota fiscal, valor da mercadoria, enfim todos os dados relevantes ao ato de transporte. Sua sigla é CTRC que significa Conhecimento Transporte Rodoviário de Carga 3 Feedback neste contexto, refere-se ao retorno de informações.

21 9 Transportando com qualidade para todo Sul do Brasil, a Expresso São Miguel cresce e expande sua área de atuação a cada dia. Sempre visando à satisfação do cliente, busca agregar aos serviços que oferece segurança e qualidade. Interage diariamente com clientes dos mais diversos segmentos, que fazem uso dos serviços prestados pela empresa para melhor atender seus clientes, despachando suas mercadorias de maneira ágil e segura. O que há de comum entre a maioria destes clientes, é a necessidade de informação ágil e confiável, bem como a integração dos seus negócios com a parceira de transportes logísticos através de arquivos eletrônicos, proposta neste trabalho. A empresa disponibiliza atualmente arquivos texto em formato TXT, com os dados que o cliente solicita. Em geral, estes necessitam de arquivos eletrônicos que contenham informações dos Conhecimentos de frete. O departamento de TI pode disponibilizar também arquivos eletrônicos com informações de entrega das mercadorias transportadas, faturas, entre outros. Estas informações permitem que o parceiro de negócio possa gerenciar o tempo de entrega das mercadorias que remeteu aos seus clientes, aumentando a segurança e o controle do relacionamento com os seus clientes. O departamento de TI da empresa possui dois colaboradores sendo um programador/analista e um suporte técnico. Também dispõem de um link dedicado junto à operadora de telecomunicações, com largura de banda de um megabit. E ainda de um servidor HTTP e um servidor de banco de dados, ambos em operação 24 horas por dia. A fim de melhor situar o leitor no contexto do trabalho e da importância do mesmo para a empresa, segue a apresentação de alguns conceitos de Customer Relationship Management.

22 10 3 CUSTOMER RELATIONSHIP MANAGEMENT (CRM) À medida que a oferta de produtos e serviços cresce, o mercado torna-se cada vez mais competitivo. Sendo assim, a sobrevivência e o sucesso da empresa dependem também, do gerenciamento da relação com os clientes, mantendo-os satisfeitos e fiéis, bem como investir em novos clientes que possam garantir bons lucros a empresa, afinal o lucro é o principal objetivo da existência de uma empresa. Nesse cenário, se insere o Customer Relationship Management, com seus conceitos e aplicações que serão descritas a seguir. 3.1 OFERECENDO SERVIÇOS AOS CLIENTES Segundo Cardoso (2001), muitos administradores experientes acreditam que serviços a clientes são apenas soluções de problemas ou são tarefas custosas relacionadas a problemas. Sendo assim, acabam por limitar os serviços aos clientes com a infra-estrutura que possuem, ao invés de focar suas visões na administração destes clientes. Empresas que buscam seu espaço no mercado com inteligência, ou seja, visando expandir-se continuamente e obter vantagens crescentes sobre seus concorrentes, vêem os serviços como uma parte da empresa que deve ser mostrada. Os serviços devem ser bem projetados, trazendo sempre resultados positivos e estando sempre à frente das expectativas do cliente. Se possível, a atitude ideal é prever a necessidade do cliente e oferecer o serviço que ele precisa antes que este peça ou exija, ou até mesmo antes que este perceba a necessidade do mesmo. A tecnologia melhora a qualidade e a segurança dos serviços, bem como os processos e os sistemas de informação agem mutuamente com as pessoas. A velha técnica do serviço acompanhado de um sorriso perde força e sustentação com o passar dos dias, dando lugar aos serviços que usam a tecnologia da informação como principal aliada, tornando as empresas mais competitivas e lucrativas.

23 11 Organizações que buscam melhorar e aprimorar seus serviços dividem-nos em níveis, oferecendo serviços de nível básico para clientes comuns e serviços mais completos a clientes de maior valor financeiro. Seguindo esta abordagem, existe o risco de tornar-se elitista, baseando os serviços de acordo com os níveis de importância econômica dos clientes, porém esse fator pode ser neutralizado, tornando a política de serviços transparente, despertando interesse nos clientes em subir de nível para adquirir benefícios ou tratamento diferenciado. Basicamente, o importante é criar meios inteligentes e eficazes de oferecer serviços que agreguem qualidade ao produto ou serviço e que assim, tornem a empresa mais competitiva, com custos bem dimensionados. Por isso, também é importante conhecer o cliente e gerenciar o ciclo de vida do mesmo, como será comentado a seguir. 3.2 GESTÃO DO CICLO DE VIDA DO CLIENTE O relacionamento pessoal é muito semelhante com o relacionamento no mundo dos negócios, pois a confiança e afinidade crescem proporcionalmente com o comprometimento de ambas as partes. Cardoso apud Kalakota e Robinson (2001) classifica o ciclo de vida do cliente em três estágios: aquisição, intensificação e retenção. A fase de aquisição de novos clientes faz com que a empresa direcione seus esforços na busca pela excelência de produtos e serviços, estabelecendo novos limites que devem cumprir as necessidades de conveniência e inovação. Deve-se focar a superioridade dos produtos e serviços. A fase de intensificação consiste em garantir que o cliente incremente seus gastos com a empresa. Nesta fase os programas de cross-selling e up-selling são essenciais, pois se faz necessário ofertar produtos e serviços complementares ou superiores do que o cliente possui atualmente. Desta forma, cria-se um vínculo de assessoria e consultoria que mantém o cliente inovando ou qualificando seus produtos e serviços, adquirindo produtos e serviços da empresa, mantendo-o fiel, satisfeito e assessorado em determinado segmento, tornando-se parceiro e garantindo com isso, que o cliente gaste cada vez mais com a empresa. Seguindo a mesma linha de pensamento, a fase de retenção busca manter a lealdade e parceria dos clientes para sempre, satisfazendo o cliente e não ao mercado. Neste caso é importante definir quem são os melhores clientes, a fim de não gastar energia

24 12 desnecessariamente. A palavra parceria resume bem esta fase, pois o cliente precisa ver e perceber que a empresa é uma parceira de negócio, um segmento de sua própria empresa, uma parte necessária para que a sua estrutura se mantenha forte e rígida. 3.3 TIPOS DE CRM Cardoso (2001) define quatro tipos de CRM que abrangem as principais atividades de relacionamento com os clientes. Na seqüência, descreve-se cada tipo demonstrando suas principais características Resgatando Clientes Este programa de CRM está focado na busca por reatar laços comerciais com clientes que deixaram de usar os produtos ou serviços da empresa. Nesta etapa, o tempo é um fator imprescindível, sendo que pesquisas revelam que as chances de reaver um cliente, se o contato for feito num curto espaço de tempo após o afastamento do cliente, é muito maior. Outro fator de sucesso para recuperação de clientes é a seletividade. Selecionar os clientes com perícia pode garantir o sucesso ou o fracasso de uma campanha de publicidade. Empresas que lideram um segmento de mercado, classificam seus clientes em potencial excluindo clientes que possuem algum tipo de histórico de inadimplência, ou, mesmo clientes com hábitos irregulares, ou seja, não compram com muita frequência Identificar e buscar clientes potenciais Para que uma campanha obtenha o sucesso desejado são necessários três fatores além de ofertar o produto, que são seletividade, segmentação e as origens. É crucial que as organizações segmentem as suas campanhas de publicidade focando sempre as necessidades de cada cliente, do contrário estarão gastando em demasia sem conseguir atingir seus objetivos efetivamente. Brown apud Cardoso (2001), afirma ser aconselhável ter uma margem de segurança de 95%, antes de iniciar uma campanha para conquista de clientes potenciais.

25 13 O fator seletividade é muito importante, tanto na conquista de novos clientes como na recuperação dos que deixaram a empresa. Já a segmentação baseada na necessidade aponta o que cliente busca na empresa, o que ele deseja. E a segmentação baseada no lucro determina o quanto determinado cliente é importante para a empresa, dando parâmetros para tomada de decisão no aspecto de saber se é vantajoso gastar para conquistar determinado cliente, e, quanto se está disposto a gastar para atingir este objetivo O processo de fidelização do cliente Manter um cliente fiel, em muitos casos não é uma tarefa fácil, pois a concorrência é muito forte em muitos segmentos. Este fato exige que as empresas utilizem métodos de retenção de clientes, para que não sejam simples clientes sujeitos a deixar a empresa a qualquer momento. É importante que os clientes tornem-se parceiros de negócio da empresa, vendo a empresa como uma aliada no seu dia-a-dia e não como uma simples fornecedora de produtos ou serviços. Ainda Cardoso (2001), propõe que sejam utilizados três elementos essenciais para manter os clientes: segmentação baseada em valores, segmentação baseada em necessidade e modelos de prevenção de atritos e deslealdades. Usando a segmentação baseada em valores, a empresa pode avaliar se é viável investir e quanto investir para manter um cliente. Empresas não fazem investimentos para manter clientes esporádicos, julgando que não são sigficativos o suficiente para justificar investimento. Esse tipo de posicionamento normalmente faz com que esses clientes abandonem a empresa, em busca de uma concorrente que não os veja desta forma. A partir do momento que um cliente é identificado pela segmentação baseada em valor, pode-se aplicar segmentação baseada na necessidade, a fim de manter este cliente satisfeito, ou ainda, criar campanhas do tipo acúmulo de pontuação que fará com que clientes significativos financeiramente, tornem-se fiéis e gastem mais do que regularmente, buscando obter algum tipo de ganho, como premiação por exemplo. A preocupação com as necessidades do cliente, normalmente contribuem com muita eficácia para sua lealdade e ainda proporcionam economias à empresa. Modelos de atrito podem ser usados baseados em dados históricos de clientes ou mesmo no acompanhamento de sua movimentação financeira ao longo do tempo. Desta forma, pode-se identificar clientes, cuja movimentação financeira, vem diminuindo ao passar

26 14 dos meses, aplicando a estes clientes que apresentam certo nivel de vulnerabilidade medidas de fidelização, e também um acompanhamento mais efetivo das suas necessidades, personalizando o serviço ou produto se houver necessidade e for viável financeiramente, e ainda avaliar os pontos que culminaram para a insatisfação do mesmo, evitando que outros tenham o mesmo tipo de problema Cross-sell e up-sell O programa de Cross-sell e up-sell visa aumentar os gastos dos clientes com a empresa. O objetivo desse programa é identificar quais os produtos ou ofertas serão melhor aceitas pelos clientes. Assim, podem-se dividir os esforços por segmento de mercado, pelas necessidades dos clientes, pelos padrões de uso ou por contatos antecipados. A partir do momento que os fatores mencionados são identificados, e o tipo de canal de marketing utilizado para chegar ao cliente definido, as ofertas são feitas de maneira direta. Programas de up-selling são semelhantes, porém possuem uma diferença fundamental que é oferecer ao cliente um produto ou serviço superior e não complementar. Por exemplo, oferecer ao cliente a troca do tipo de conexão com Internet de dial-up para Asymmetric Digital Subscriber Line 4 (ADSL) ou link dedicado. Este tipo de campanha normalmente é mais lucrativa, por que o público alvo já é cliente da empresa, e quando ele adquire o produto ou serviço ofertado ele se torna mais lucrativo. No caso de transportadoras terrestres, esses programas fazem com que os clientes massifiquem seus transportes com uma determinada empresa, e não dividam suas cargas entre diversas empresas, tornando-os mais lucrativos. Para isso, faz-se necessário campanhas e ofertas, com novas rotas de transporte a custo acessível e curto tempo para entrega, mantendo a qualidade em tudo, mas principalmente no que se refere a baixo índice de avarias, perdas de mercadorias e mercadorias enviadas a destinos incorretos. 4 ADSL é uma tecnologia de comunicação de dados que oferece taxas de transferência mais velozes através de linhas telefônicas do que um modem convencional pode oferecer.

27 SUBDIVISÕES DE CRM De acordo com Enio Klein (2002), o CRM subdivide-se em: CRM operacional, CRM analítico e CRM colaborativo. O CRM operacional trata da automação de processos e análise operacional, ou seja, trata dos aspectos operacionais da relação do cliente com a empresa buscando tornar esta relação o mais eficiente possível, geralmente fazendo uso de sistemas de informação como ERPs, sistemas de e-commerce, sistemas legados, Call Centers e também automação dos processos de venda e automação de serviços ao cliente. Já o CRM analítico visa examinar, avaliar e mensurar modelos e resultados a fim de prover recursos para tomada de decisões estratégicas e táticas em diversas áreas da organização. O CRM analítico é constituído por diversos tipos de software como Data Warehouse, Tratamento de dados, Data Mining, Business Intelligence, Marketing. De forma resumida o CRM analítico visa mensurar os resultados coletados pelo CRM operacional gerando conhecimento para a tomada de decisões, por exemplo, vendas por chamados, acertos de venda em determinada campanha, vendas por segmento de clientes. O CRM analítico geralmente busca medir métricas operacionais ligadas ao custo/desempenho, ou seja, quanto foi gasto em determinada campanha de vendas e qual retorno obtido, levantando possíveis falhas minimizando cada vez mais os riscos e maximizando os acertos ou casos de sucesso, tornando a empresa rentável, competitiva e agressiva perante a concorrência. O CRM colaborativo como o próprio nome sugere visa automatizar e integrar todos os meios de contato com os clientes, também chamados canais de interação a fim de informação se propague por todos os departamentos da organização, preparando os colaboradores para atender o cliente da melhor forma possível, fazendo com que a organização seja um centro de atendimento qualificado, e não uma série de ilhas isoladas quase que incomunicáveis, tornando cada atendimento ou relacionamento com o cliente uma falha. A figura a seguir demonstra o CRM operacional, analítico e colaborativo abordado em níveis sendo eles retaguarda (Back Office), atendimento ao público(front Office), atendimento ao cliente usando dispositivos móveis(móbile Office) e os canais de interação com o cliente(customer Interaction) mostrando os componentes de cada subdivisão de CRM mencionados no texto até o momento, possibilitando maior clareza do todo ao leitor.

28 16 Figura 1: As subdivisões do CRM e seus componentes (META Group) De acordo com o que visto até o momento em torno do CRM, pode-se concluir que devido as características deste trabalho como interação direta com o cliente, serviço ao cliente, automação de serviços ele faz parte do CRM operacional, e como CRM colaborativo engloba todos os canais de interação com cliente também faz parte deste, porém seu principal foco é operacional. A seguir algumas considerações a cerca dos conceitos do CRM para este trabalho. 3.5 CONSIDERAÇÕES Os conceitos de CRM abordados neste capítulo são extremamente relevantes para o sucesso das empresas em geral, e contribui significativamente com a proposta deste trabalho. Pois se busca com este projeto, primeiramente oferecer mais um serviço de qualidade aos clientes e parceiros de negócio, mantendo os que já são clientes, satisfeitos e criando um diferencial competitivo para a conquista de novos. O gerenciamento do ciclo de vida do cliente é um fator importante para o sucesso da organização, neste sentido o trabalho abrange os quatro tipos de CRM propostos por Cardoso (2001), pois contribui na aquisição de novos clientes devido a este novo serviço a ser prestado

29 17 sem custo adicional, contribui para a intensificação dos gastos dos clientes existentes, pois este serviço fará com que o vínculo com os clientes se fortaleça e proporcione maiores gastos dos mesmos com a empresa, devido a flexibilidade e agilidade do retorno das informações dos serviços logísticos prestados. Proporcionará maior confiabilidade a segurança aos parceiros, pois estes terão informações com agilidade e precisão, que farão com que possam melhor atender os seus clientes, vendo a empresa objeto de estudo como uma extensão da sua própria empresa e aliada para alcançar o sucesso comercial no seu segmento. Com este trabalho a empresa em questão poderá também, garantir a fidelidade dos parceiros de negócio, pois a integração da cadeia produtiva através do intercâmbio eletrônico de dados cria um vinculo forte entre as empresas. Sendo assim, sempre que o parceiro for decidir para qual empresa de transportes logísticos vai remeter sua produção, venda de produto ou matéria-prima, terá em mente que se fazer uso dos serviços prestados pela empresa em questão neste estudo, terá informações de retorno em meio eletrônico de forma rápida e segura que contribuirão para o melhor gerenciamento dos seus negócios. Seguindo a mesma lógica, clientes que foram perdidos ou parceiros que se desligaram da empresa, podem ser reconquistados e laços comerciais rompidos possivelmente pela falta de um serviço deste tipo poderão ser restabelecidos. Enfim, o uso dos conceitos de CRM pode contribuir muito para o sucesso das organizações, mantendo-as competitivas e lucrativas principalmente diante do quadro econômico mundial que esta sendo vivenciado. Mas além do CRM, outras tecnologias estão envolvidas para a construção deste trabalho, tecnologias estas citadas e descritas a seguir.

30 18 4 TECNOLOGIAS ENVOLVIDAS Neste capítulo são descritas as tecnologias envolvidas neste trabalho, como banco de dados, redes de computadores e Extensible Markup Language. 4.1 BANCO DE DADOS E SGDBS Existem muitos conceitos e definições à cerca de banco de dados e sistemas gerenciadores de banco de dados (SGDB's), mas sinteticamente pode se dizer que são depósitos de informações sobre determinado tema ou organização, estruturados lógica e fisicamente de acordo com algumas restrições. Para Alves (2004), p. 25, um banco de dados... é um conjunto de dados com um significado implícito.... Ainda faz 3 considerações a cerca do uso da definição de banco dados: um banco de dados representa uma porção do mundo real, o qual chamamos de minimundo ou Universo de Discurso. Qualquer alteração nesse minimundo deve ser refletida no banco de dados; um banco de dados é um conjunto lógico e ordenado de dados que possuem algum significado, e não uma coleção aleatória; um banco de dados é construído e povoado com dados que tem um determinado objetivo, com usuários e aplicações desenvolvidas para manipulá-los (ALVES, 2004, p. 25). Já para Date (1991), p. 3,... um sistema de Banco de dados não é nada mais do que um sistema de manutenção de registros por computador.... Ainda Date (2001), faz analogia de um banco de dados, com uma sala de arquivos eletrônica, ou seja, um repositório de dados que oferece aos usuários uma série de recursos que possibilitam o acesso a diversas operações. A evolução dos bancos de dados fez com que houvesse a necessidade de gerenciamento mais efetivo e consistente, desta forma surgiram os Sistemas Gerenciadores de Banco de Dados (SGDB's).

31 19 Um sistema de gerenciamento de banco de dados (SGDB) consiste em uma coleção de dados inter-relacionados e em um conjunto de programas para acessálos. Um conjunto de dados, normalmente referenciado como banco de dados, contém informações sobre uma empresa particular. O principal objetivo de um SGDB é prover um ambiente que seja adequado e eficiente para recuperar e armazenar informações de banco de dados (KORTH E SILBERSCHATZ, 1995, p. 1). Os SGDBs são largamente utilizados por organizações de todos os tipos e tamanhos há vários anos. Graças a eles, muitas outras aplicações são possíveis como Enterprise Resource Planning (ERP), sistemas de apoio à decisão (SAD), Data Warehouses (DW), Data Mining e softwares aplicativos em geral. Através do uso de SGDB s é possível também o intercâmbio de dados eletrônico, pois os dados podem ser extraídos de SGDB s e convertidos para vários tipos de arquivo, dependendo da necessidade e aplicação do mesmo. Para o caso de estudo em questão, será focado o modelo de SGDB relacional, pois o Sistema Gerenciador de Banco de Dados Borland Interbase usado como repositório de dados neste trabalho é classificado como relacional. 4.2 MODELO RELACIONAL O modelo relacional está bem consolidado no mercado com muitas aplicações baseadas nele. Surgiu na década de 70 e foi sendo aperfeiçoado até garantir bons níveis de confiança das organizações e usuários em geral Segundo Alves (2004), a maioria dos SGDBs atuais são classificados como relacionais. Um banco de dados relacional consiste em uma coleção de tabelas, cada qual designada por um nome único. Uma linha numa tabela representa um relacionamento entre um conjunto de valores. Uma vez que uma tabela é uma coleção de tais relacionamentos, existe uma correspondência intima entre o conceito de tabela e o conceito matemático de relação, a partir do qual o modelo de dados relacional tira seu nome (KORTH E SILBERSCHATZ, 1995, p. 58). Para Date (1991), um banco de dados relacional é um banco de dados visto pelos usuários como um conjunto de tabelas.

32 20 relacional. Na seqüência uma breve descrição dos componentes básicos de um banco de dados Estrutura de um banco de dados relacional Basicamente um banco de dados relacional é composto por tabelas, chaves e domínios. Segundo Heuser (2000) tabelas são grupos de linhas, não ordenados onde cada linha é composta por n campos também chamados valores de atributos. Cada campo é identificado através de um nome que dê a ele um significado de acordo com o dado que ele vai armazenar. Ao conjunto de campos com mesmo nome de uma tabela dá-se o nome de coluna. A figura 1 demonstra um exemplo de tabela para facilitar o entendimento dos conceitos explanados. Figura 2: Exemplo de tabela em um banco de dados relacional HEUSER (2000) Chaves são identificadores únicos de linhas de uma tabela, ou seja, uma chave serve para diferenciar uma linha da outra evitando inconsistências na hora da recuperação dos dados. Servem também para relacionar tabelas em um banco de dados relacional. As chaves podem ser primárias, estrangeiras ou alternativas. Entende-se por chave primária a combinação de uma ou mais colunas, cujos valores dos atributos tornam uma linha única perante as demais. Uma chave primária pode ser simples, quando possui apenas uma coluna ou composta quando possui duas ou mais colunas. Chaves primárias simples são usadas quando uma coluna basta para distinguir uma linha das outras, porém, em alguns casos é necessário considerar dois ou mais campos de uma tabela como chave primária de forma que não possa haver nunca nenhum registro (linha)

33 21 na tabela, cujo valor das duas ou mais colunas definidas como chave, em duplicidade. As chaves compostas são necessárias quando apenas um atributo não consegue oferecer a propriedade de unicidade. Na figura 1, o atributo CodigoEmp tem o papel de chave primária, pois os valores da sua coluna tornam as linhas únicas entre si. Chave estrangeira é uma chave herdada de outra tabela. O mecanismo de chaves estrangeiras permite o relacionamento entre tabelas num banco de dados relacional. Na figura 1, o atributo CodigoDepto não é chave primária da tabela de empregados, ele é chave primária da tabela de departamentos, cuja tabela de empregado possui relacionamento. A chave primária de outra tabela, herdada através de um relacionamento, é chamada de chave estrangeira, pois não faz parte originalmente da tabela em questão, ela está representando a ligação, o relacionamento entre duas tabelas, neste caso. Quando se define uma tabela de um banco de dados, define-se também os domínios que os atributos podem ter, ou seja, dá-se o nome domínio ao conjunto de valores que um atributo pode assumir, ou ainda se este atributo pode ser persistido sem receber nenhum valor do seu domínio. Atributos que não permitem valores vazios, ou seja, que não possuem nenhum valor atribuído, são chamados obrigatórios. Em geral chaves de tabelas, são atributos obrigatórios devido a sua função. Uma das principais metas de um SGDB é prover a integridade e a consistência dos dados. Para isto, são implementadas regras no próprio SGDB chamadas restrições de integridade. Heuser (2000) classifica as restrições de integridade em: integridade de domínio: restrições de integridade de domínio determinam qual o tipo de dados aceito pelo atributo. O usuário do SGDB não pode definir domínios próprios, ele deve se restringir a fazer uso dos domínios definidos pelo SGDB. Assim, por exemplo, se a aplicação ou o usuário tentar persistir um valor fora do domínio daquele atributo, será retornado um erro e a gravação não será permitida, garantindo que a regra não seja violada; integridade de valor nulo: se o atributo é obrigatório, por exemplo, o atributo chave primária de uma tabela, em geral é definido como não nulo, neste caso se o usuário ou a aplicação tentar persistir o registro com o campo obrigatório em branco, o SGDB não vai permitir;

34 22 integridade de chaves: esta restrição refere-se à violação da unicidade de um atributo definido como chave. Antes de gravar um dado na coluna de um atributo chave, o SGDB faz uma verificação a fim de confrontar o valor a ser salvo com os valores já gravados, se ele encontrar um valor salvo igual, ele retorna um erro informando que a gravação não será efetuada, pois a tentativa viola a restrição de chave, ou seja, não pode haver dois valores iguais numa coluna definida como chave; integridade referencial: esta restrição define que valores presentes em uma chave estrangeira, devem obrigatoriamente constar na chave primária da referida tabela. As restrições de integridade são de obrigação do SGDB, sendo que o programador não deve e não precisa se preocupar em controlar este tipo de operação. Existem restrições de integridade, que não podem ser classificadas em nenhuma das mostradas anteriormente, são chamadas de restrições semânticas. Um exemplo de integridade semântica é a de que um veículo não pode trafegar 1.000,000 km num período de 10 dias, portanto se um usuário tentar gravar um valor maior do que este num período como 30 dias o banco não pode aceitar, porém, esse tipo de restrição deve ser controlado pelo programador. 4.3 REDES DE COMPUTADORES A evolução dos computadores nas últimas décadas impulsionou o desenvolvimento e aperfeiçoamento dos meios de interconexão entre estes equipamentos, que estão a cada dia mais presentes na nossa vida. Segundo Tanenbaum (2003), p. 2, dá-se o nome... rede computadores ao conjunto de computadores autônomos interconectados através de uma única tecnologia.... As redes de computadores tiveram e tem um papel fundamental no crescimento dos sistemas computacionais, pois foram através delas que muitas outras tecnologias puderam originar-se. Apesar de jovem a informática se tornou base para quase todas as tecnologias existentes atualmente. Devido a evolução tecnológica, houve um estreitamento entre a

35 23 transmissão, o armazenamento e o processamento das informações, mudando radicalmente os modelos em que se baseavam os sistemas computacionais. Durante as primeiras décadas de sua existência, os sistemas computacionais eram extremamente centralizados, basicamente se resumiam a grandes computadores que ocupavam salas inteiras. Graças à evolução das redes de computadores, atualmente os sistemas computacionais quebraram muitas barreiras e podem estar distribuídos geograficamente em qualquer lugar do globo terrestre. A rede Internet é uma das mais importantes redes de computadores, pois através de seus protocolos e serviços, trafegam dados e voz no mundo inteiro. Atualmente a rede Internet é base para um grande conjunto de aplicações, e continuam surgindo novas todos os dias. Conceitos e aplicações específicos da rede Internet serão explanados na seqüência. A seguir será descrito brevemente a arquitetura Transmission Control Protocol / Internet Protocol, pois este é o modelo base para o desenvolvimento deste trabalho Arquitetura TCP-IP De acordo com Tanenbaum (2003), p. 44, não pode-se falar do modelo TCP/IP sem antes mencionar a base... de todas as redes de computadores geograficamente distribuidas, a ARPANET..., predecessessora da rede Internet. Financiada pelo Departamento de Defesa dos Estados Unidos, a ARPANET conectava inicialmente universidades e orgãos governamentais através de linhas telefônicas. Com o desenvolvimento de outros tipos de redes como rádio e satélite surgiram muitos problemas com os protocolos usados na época, forçando a criação de uma arquitetura que não se limita a um único tipo de rede, ou seja, que pudesse criar uma ligação entre diferentes tipos de redes, surgindo então o Modelo de Referência TCP/IP. Para Tanenbaum (2003), o modelo TCP/IP possui 4 camadas, aplicação, transporte, inter-redes e rede que são detalhadas a seguir.

36 24 Figura 3: Pilha TCP/IP A camada de aplicação, contém protocolos de aplicação que possibilitam o acesso a serviços que estão disponíveis na inter-rede. Tem-se como exemplo destes protocolos o HTTP, FTP, SMTP, DNS entre outros. Estes são responsáveis respectivamente, pela transferência de documentos através da Internet, transferência de arquivos, correio eletrônico e resolução de nomes de host em endereços de rede. No modelo TCP/IP a camada de transporte possui a mesma função que no modelo OSI, que é de manter a conversação entre entidades pares. Porém, agora foram definidos os protocolos Transmission Control Protocol (TCP) e User Datagram Protocol (UDP). Tanenbaum (2003), p. 46, define TCP como... um protocolo orientado á conexão confiável que permite a entrega de um fluxo de bytes originário de uma determinada máquina em qualquer computador da inter-rede.... Já o protocolo UDP, não é orientado a conexão e não implementa um mecanismo de transmissão confiável, e não gera grandes trafegos na rede. A camada de transporte também faz controle de fluxo. Figura 4: Camadas TCP/IP e respectivos serviços

37 25 A camada inter-redes (também chamada de camada Internet) basicamente tem a tarefa de interligar redes distintas. Ela tem a função de garantir que pacotes enviados por diversos hosts de redes diferentes cheguem aos seus destinos, sendo que a ordem dos pacotes não tem relevância sendo responsabilidade das camadas superiores ordená-los. De acordo com Tanembaum (2003), p. 45,... a camada inter-redes define um formato de pacote oficial e um protocolo chamado Internet Protocol (IP).... O roteamento dos pacotes e controle de congestionamento são tarefas essenciais nessa camada. A camada de rede, ou host/rede tem a função de interfacear com os diversos tipo de redes, ou seja, provê a interconexão entre redes heterogêneas. A seguir uma breve descrição da Web e do protocolo HiperText Transfer Protocol que roda na camada de aplicação, da arquitetura TCP/IP. 4.4 A WEB E O PROTOCOLO HTTP Para Kurose (2003) a aplicação WWW está entre as maiores tecnologias de comunicação eletrônica da história. Até meados dos anos 90, a rede Internet era usada unicamente no meio acadêmico, servindo para transferência eletrônica de documentos, notícias e correio eletrônico. O surgimento da Word Wide Web, provocou um grande impacto social, mudando a interação entre as pessoas dentro e fora de suas organizações. Com a WWW surgiram muitas empresas e ramos de negócio totalmente novos, e a rede Internet tornou-se a principal rede de dados. Segundo Kurose (2003), o que distingue a WWW das demais tecnologias que impactaram a sociedade como o telefone em 1970 e as transmissôes de rádio década de 1920 mais tarde a televisão, é a demanda. Os usuários podem enviar e receber o que quiserem e quando quiserem, o que se diferencia principalmente da televisão onde o usuário necessariamente se submete a uma determinada programação. Basicamente para que os usuários possam navegar nos sites da Internet, e as empresas trocarem suas informações existe um protocolo chamado HiperText Transfer Protocol, muito conhecido pela sigla HTTP. Ele é um protocolo da camada de aplicação do

38 26 modelo TCP/IP e esta implementado em duas extremidades, como servidor e como cliente. Um programa cliente e um servidor HTTP, interagem através de mensagens. O protocolo HTTP estabelece regras estruturais e a maneira de como essas mensagens são trocadas entre um cliente Web ou browser 5 como também é chamado e um servidor Web. Quando um usuário requisita uma página Web, através da digitação de um endereço no browser ou clicando sobre um hiperlink 6 por exemplo, o browser envia mensagens de requisição HTTP para o servidor, solicitando que este envie ao host 7 requerente os objetos da referida página. O servidor interpreta a requisição e retorna ao browser os objetos requisitados, que são exibidos ao usuário. Entende-se por objetos neste caso, documentos HTML, XML, Personal Home Pages (PHP), JAVA entre outros bem, como imagens JPEG, GIFs, animações FLASH 8 e muitos outros tipos de documentos e arquivos que podem estar relacionados à uma página da Web. Como foi citado anteriormente, um servidor Web pode retornar de acordo com a requisição, uma série de tipos de arquivos. Sendo assim, ele pode ser usado para retornar documentos formatados em diversas linguagens de marcação, como XML por exemplo. Logo, um usuário pode obter um arquivo de transferência eletrônica de dados, com um simples clique de mouse. É claro, que para isso faz-se necessário possuir outras aplicações interagindo com o servidor Web, porém esses aplicações podem ser transparentes ou imperceptíveis ao usuário, dando um nível mais alto de abstração. Sem os servidores Web e o protocolo HTTP, provavelmente a Internet não teria chegado no ponto em que está, e não teria tanta importância para sociedade. Pois a rede Internet, o protocolo HTTP e os servidores Web, servem de base para muitas aplicações e serviços. 5 Um exemplo de browser bem conhecido é o Microsoft Internet Explorer. 6 Na Web designa partes clicáveis em forma de texto ou imagem, que levam a outras partes de um mesmo texto ou outras páginas Web. 7 Um host neste contexto é qualquer máquina, computador ou equipamento conectado a uma rede. 8 Software da Macromedia para animações e aplicativos.

39 Diferenças entre HTTP 1.0 e HTTP 1.1 De acordo com Krishnamurthy, Mogul e Kristol (sd), o protocolo HTTP 1.0 obteve sucesso e um grande nível de aceitação durante muitos anos. Foi apontado em estudo recente da IEEE como responsável pelo consumo de 75% do tráfego dos backbones. Mas suas falhas e limitações impulsionaram pesquisadores e desenvolvedores a especificarem o seu sucessor HTTP 1.1, que implementa diversas mudanças e melhorias. No HTTP 1.1 foram implementados recursos que garantem a extensibilidade e compatibilidade objetivando evitar problemas com novas versões. Problemas de compatibilidade que atrasaram de certa forma a especificação 1.1, serviram como contribuição para evitar futuras complicações. O HTTP 1.1 introduz o método options que possibilita a uma aplicação cliente aprender sobre as capacidades de um servidor sem requisitar nada a o mesmo de forma explicita. O HTTP 1.1 ainda implementa um novo upgrade request-header, permitindo a uma aplicação cliente informar ao servidor o conjunto de protocolos suportados pelo mesmo. O servidor pode escolher trocar de protocolos de conversação (opcional). Com relação ao Caching pode-se afirmar que a especificação 1.1 implementa formas e métodos mais inteligentes de gerenciamento de cache. O HTTP 1.1 não descarta os mecanismos da versão 1.0 por razões de compatibilidade, mas provê clareza e implementa novos recursos mais elaborados do que os existentes. O HTTP 1.0 não permitia enviar apenas parte de um documento, consumindo grande parte da largura de banda enviando um documento inteiro sendo que o cliente pode necessitar apenas de uma fração do mesmo, o início da página/documento, por exemplo. O HTTP 1.1 permite que o cliente requisite porções de um documento, ou apenas alguns objetos de um recurso. Além disto, o HTTP 1.1 permite gerenciar as respostas em relação à largura de banda disponível, o que não era possível na versão anterior. A versão 1.1 implementa mecanismos que impedem ao cliente enviar extensos corpos (body) de requests, sem antes saber se o servidor está disposto a aceitá-lo. Um servidor pode rejeitar uma requisição devido a uma falha de autenticação, por exemplo, mas na versão 1.0 o cliente pode enviar uma requisição com corpo extenso mesmo sendo rejeitada pelo servidor, ocasionando desperdício de largura de banda.

40 28 O HTTP 1.1 oferece mecanismos de compressão de dados ou imagens mais eficazes e extensíveis. A especificação 1.1 distingue codificações fim-a-fim e host-a-host, sendo que a compressão pode ser feita como codificação de conteúdo ou transferência. Em resumo toda e qualquer compactação possível pode garantir os benefícios da rapidez e menor consumo de banda. O protocolo HTTP 1.0 não documenta implementações de conexões persistentes, por mais que utilize headers, para solicitar esse tipo de conexão em algumas implementações. Já o HTTP 1.1 faz conexões persistentes por padrão, ou seja, presume que a conexão deva ser mantida aberta após uma solicitação e uma resposta do servidor. O protocolo HTTP 1.1 usa um pipelining para enviar varias requisições usando a mesma conexão TCP, porém o servidor responde as requisições na mesma ordem que as recebeu. O processamento paralelo, ou fora de ordem pode proporcionar grandes benefícios em termos de desempenho, mas ainda está em estudo. A fim de implementar uma solução para as mensagens HTTP muito extensas ou arbitrárias, o HTTP 1.1 implementa uma codificação extra chamada chunked transfer-coding, que permite a quebra das mensagens http em varias partes e o envio ao destinatário; cada parte contendo um delimitador de fim, e um cabeçalho que sinaliza ao destinatário o uso do recurso. Este recurso soluciona um outro problema do HTTP 1.0, a ausência do cabeçalho informando o tamanho da mensagem HTTP. Sem esta informação o destinatário não consegue saber se a mensagem foi truncada ou ocorreram erros durante o envio. A especificação HTTP 1.1, adiciona novos códigos de advertência/erro, que são divididos em duas categorias, conflicts - gerados quando ocorrem violações no estado corrente dos recursos que estão sendo requisitados e gone - quando um recurso foi retirado do servidor, são conhecidos comumente como links quebrados. Referenciando a questão de integridade e autenticação, a especificação 1.1 do protocolo HTTP, oferece autenticação direta e um esquema de sumário que combina senhas, contra-senhas, tempo, usuário, método de HTTP e Message-Digest algorithm 5 (MD5) 9, a fim de garantir a integridade da autenticação. 9 O MD5 é um algoritmo de criptografia de 128 bits desenvolvido pela RSA Data Security, Inc.

41 29 A especificação 1.1 implementa meios de negociação de conteúdo mais flexíveis, com duas formas de negociação, dirigida ao servidor e dirigida ao agente. Na negociação dirigida ao servidor, o agente remete ao servidor através de headers sugestões de linguagem e codificação e o servidor escolhe a mais adequada. No segundo modo, o servidor envia ao agente uma gama de opções e este escolhe automaticamente ou solicita a interferência do usuário e depois responde com a linguagem e codificação desejada. Em resumo, pode-se afirmar que a diferença mais considerável entre as duas versões, é de que o protocolo HTTP 1.0 abre n conexões TCP para transferir os diversos objetos (gráficos, imagens, textos, animações, entre outros) que uma página da Internet possui, até o destino. Já o protocolo HTTP 1.1 usa uma única conexão TCP para efetuar o mesmo processo, economizando largura de banda, processamento, complexidade, congestionamentos, entre outros. A especificação do protocolo HTTP 1.1 é extensa, portanto foram relacionadas apenas algumas das características mais importantes, que podem contribuir com este trabalho. 4.5 A REDE INTERNET Para Tanenbaum (2003), p. 53, a Internet não pode ser chamada de rede em momento algum, pois ela é...um vasto conjunto de redes diferentes que utilizam certos protocolos comuns e fornecem certos serviços comuns.... Já para Kurose (2003), p. 1, a Internet é...uma rede mundial de computadores, isto é, uma rede que conecta milhões de equipamentos de computação em todo mundo.... Sendo que grande destes equipamentos são microcomputadores comuns, estações de trabalho Unix, servidores WWW e servidores de correio eletrônico. Segundo Tanenbaum (2003) o surgimento da Internet baseou-se nas redes ARPANET e NSFNET. Por volta de 1950, durante a guerra fria (guerra entre os EUA e URSS) o governo dos Estados Unidos estava preocupado com a fragilidade de seu sistema de comunicação, que era na época uma rede de telefonia pública, baseada em centrais de comutação e centrais interurbanas. Porém, no caso de um ataque, se algumas centrais interurbanas fossem destruídas, o sistema era fragmentado em ilhas deixando algumas extremidades incomunicavéis. Em 1960, um funcionário de nome Paul Baran da empresa RAND corporation

42 30 contratada pelo departamento de defesa dos EUA para solucionar o problema de comunicação, propos um modelo de comutação de pacotes, que interligava varios nós (hosts) com alto nível de redundância. Porém, a idéia de Baran foi recusada pela AT&T (monopolio das telecomunicações na época nos EUA). O então presidente dos EUA Eisenhower percebendo que havia uma disputa entre o exército, marinha e aeronáutica pelos recursos do pentagono, criou a Advanced Resarch Projects Agency (ARPA). O Sr. Larry Roberts foi nomeado presidente da agência. Procurou especialistas em redes a fim de ideias para solucionar o problema de comunicação dos EUA. Durante a participação em um simpósio no Tenessse em 1967, Roberts foi apresentado a um sistema do Laboratório Nacional de Física da Inglaterra, que conectava computadores no campus usando comutação por pacotes, este trabalho referenciava a proposta de Baran. Roberts voltou do simpósio determinado a construir o que tempo depois ficou conhecida como ARPANET. Os protocolos da ARPANET eram limitados no que dizia respeito à execução em redes múltiplas. O que culminou na invenção do modelo TCP/IP, que surgiu com o intuito de engendrar a comunicação sobre inter-redes. Durante a década de 80, muitas LANS foram conectadas a ARPANET usando o 4.2BSD desenvolvido pela University of Califórnia em Berkeley. Percebendo a grande contribuição que a ARPANET estava proporcionando para as pesquisas nas universidades dos Estados Unidos a fundação nacional de ciência (NSF) propôs a construção de uma rede que fosse capaz de substituir a ARPANET, mas que fosse livre, já que para fazer parte da ARPANET era necessário um contrato com o Departamento de Defesa dos Estados Unidos. Inicialmente a NSF interligou seus supercomputadores, usando computadores auxiliares que faziam uso do mesmo hardware da ARPANET, já o software conectava-se de forma direta ao TCP/IP. Esta rede foi chamada NSFNET e interligava muitas universidades, laboratórios e centros de pesquisa e também se conectava a ARPANET. Nos anos 90, outros paises construíram redes nacionais baseadas na ARPANET E NFSNET. O número de redes interligadas cresceu muito, e os computadores conectados a elas também, formando um emaranhado de redes interligadas que conhecemos como Internet. No entanto, o uso da Internet cresceu muito nos últimos anos e continua crescendo, pois não existe nenhuma restrição de acesso a ela, como havia na ARPANET, por exemplo. Qualquer pessoa ou organização conecta-se a rede diretamente. Na verdade, um grande número de pessoas e empresas depende da Internet para manterem suas relações comerciais e

43 31 pessoais. O comércio eletrônico se expande rapidamente, e as empresas buscam integrar-se aos parceiros para manterem-se ou tornarem-se fortes e competitivas. Diante deste cenário, a seguir serão esplanadas as principais características da linguagem XML, considerada por diversos autores como o padrão mais adequado para integração de sistemas usando a Internet. 4.6 EXTENSIBLE MARKUP LANGUAGE (XML) Neste capítulo serão apresentados os principais conceitos sobre a linguagem XML, vantagens, desvantagens, principais aplicações e características, a fim de que o leitor compreenda como é a estrutura, a sintaxe e quais as aplicações da linguagem supracitada. 4.7 INTRODUÇÃO Desde o surgimento dos documentos impressos, os autores enviavam junto aos documentos, orientações aos impressores de como os documentos deveriam ser impressos, ou seja, qual o formato que o documento deveria ter. Essas instruções eram chamadas marcações e o conjunto dessas marcações que seguiam uma determinada sintaxe eram chamados de linguagem (ANDERSON et al, 2001). Desde então, muitas linguagens de marcação surgiram para atender aos mais diversos fins, dentre elas podemos citar a Standard Generalized Markup Language (SGML) de 1986, como uma das principais linguagens, pois baseada nela em 1989 originou-se a Hipertext Markup Language (HTML) muito utilizada até os dias de hoje bem como a própria XML nosso objeto de estudo neste capítulo. A SGML é uma linguagem de marcação muito poderosa, porém à medida que for sendo utilizada, o poder oferecido por ela e sua complexidade aumentam muito (MCGRATH, 1999). Devido à complexidade de aplicação, o uso da mesma fica restrito basicamente a grandes corporações, indústrias e órgãos federais que necessitam de todos os recursos fornecidos por ela (MCGRATH, 1999). Sendo assim, em 1996 especialistas em SGML, chefiados por Jon Bosak da empresa Sun Microsystems uniram-se para criar uma linguagem

44 32 mais simples e leve para uso na WEB baseada no padrão SGML, que mantivesse as suas principais características e que desse aos desenvolvedores a possibilidade de criarem suas próprias tags quando fosse preciso, e que não ficassem restritos ao uso de um numero limitado de marcadores determinados pela linguagem, como é o caso da HTML (FURGERI, 2001). Já no final de 1996, numa conferência de SGML em Boston, Estados Unidos foi anunciada a primeira versão da linguagem XML, que vem sendo revisada e ganhando recursos até hoje, sendo o projeto XML levado adiante pelo Word Wide Web Consortium (W3C). O padrão XML vem sendo utilizado largamente por empresas de renome como Microsoft, Sun Microsystems, Adobe, IBM, Netscape, Corel, Hewlett-Packard entre outras (FURGERI, 2001). 4.8 CONSIDERAÇÕES SOBRE A LINGUAGEM HTML No início de 1989, o Sr. Tim Berners Lee e o Sr. Robert Caillau, ambos do Centro Europeu de Pesquisas de Física de Partículas mais conhecido como CERN, desenvolveram um novo protocolo para comunicação através da Web, que ficou conhecido como WWW. Com o intuito de padronizar o protocolo, foi formado um consórcio composto de várias organizações, chamado Word Wide Web Consortium (W3C). Este consórcio ainda é responsável pela maioria dos padrões de linguagem e afins da Web (FURGERI, 2001). Alguns anos depois, mais especificamente em 1992, a primeira versão do HTML foi definida baseada no padrão SGML. A linguagem HTML também é uma linguagem de marcação, composta por tags (marcadores/delimitadores representados pelos caracteres < e > ) e comandos especiais que formam sua sintaxe como toda a linguagem de programação. Porém a linguagem HTML, apesar de ser conhecida como linguagem de programação, ela é na verdade uma linguagem de marcação, como a XML. Isto porque ela não consegue fazer nada sozinha, ou seja, a linguagem HTML precisa de um interpretador (browser), que interprete os códigos HTML e mostre as informações de acordo com as codificações definidas pelo programador. Entende-se por codificações neste caso, as marcações de como o texto deve ser formatado para exibição em um determinado browser ou navegador (FURGERI, 2001).

45 33 Segundo Furgeri (2001), segue abaixo algumas considerações importantes sobre a linguagem HTML, que servirão de base para comparações futuras: a linguagem HTML é independente de hardware e plataforma, ou seja, é interpretada por todo tipo de navegador e pode ser visualizada em diferentes tipos de computadores, rodando diferentes sistemas operacionais; a HTML foi concebida para difundir documentos na Internet, sejam eles de estrutura simples ou complexa, por isso possuem sintaxe simples possibilitando que pessoas sem conhecimento prévio de programação de computadores criem documentos HTML. Entende-se por documentos de estrutura simples e complexos, aqueles documentos cuja composição possui apenas texto corrido, e por documentos complexos aqueles compostos por componentes que agregam maior valor visual, ou seja, páginas que utilizam maiores recursos da linguagem; a linguagem HTML é um padrão aberto, sendo assim ninguém possui direitos sobre ela. Qualquer pessoa pode codificar um documento em HTML sem ter que pagar direitos por uso a ninguém. O proprietário da página é o desenvolvedor; apesar de simples, a linguagem HTML pode agregar outros recursos como imagens, filmes, animações e muitos outros tipos de arquivos que trafegam pela Internet Estrutura e composição da linguagem HTML Segundo Graham (1998), documentos codificados na linguagem HTML, são compostos por elementos, que em geral são delimitados por tags de início e de fim. Alguns desses elementos não alteram a estrutura de um texto, são os chamados elementos vazios que não necessitam de tags delimitadoras de fim. A linguagem HTML não é case sensitive se tratando de nomes de elementos, ou seja, não faz distinção entre elementos nomeados com letras maiúsculas ou minúsculas. Também existem elementos que possuem atributos, porém estes aparecem sempre nas tags iniciais. Por exemplo: <img src= nome_do_arquivo.jpg > onde o elemento img (usado na linguagem

46 34 para inserir uma imagem a um documento) possui o atributo src, que define o nome do arquivo de imagem a ser inserido, bem como a localização do arquivo no computador ou servidor web. Os elementos de um documento HTML devem seguir as regras de aninhamento da linguagem, também chamadas regras de disposição hierárquica, que definem a posição e a localização que os elementos podem ter dentro do documento. 4.9 CONSIDERAÇÕES DA XML Segundo Furgeri (2001), a característica mais importante da linguagem de marcação XML é de que ela não trata apenas da formatação do texto, ou seja, apenas sirva para definir como as palavras ou texto serão exibidos como na linguagem HTML, a XML fornece o significado ou o conteúdo do documento. A maior importância do desenvolvimento da linguagem XML, foi possibilitar aos programadores a criação de seus próprios marcadores (mais conhecidos como tags), libertando-os da estrutura rígida e limitada da linguagem HTML. A linguagem XML é um padrão aberto, sendo assim, não é propriedade de nenhuma corporação. É independente de plataforma e não é considerada uma linguagem de programação, pois não faz nada isoladamente. Os documentos XML são compostos basicamente, por três elementos os quais são descritos a seguir: conteúdo dos dados: são os dados contidos entre as tags; estrutura: definições de como os dados são estruturados, formando um tipo específico de documento, como um catálogo ou um orçamento, enfim dependendo da necessidade de marcação do documento, pode-se definir a estrutura que o mesmo vai ter. apresentação: é o formato do documento que será mostrado ao leitor. A linguagem XML possui uma característica especifica que permite a visualização de um mesmo documento XML de várias formas.

47 35 Pode-se especificar ainda mais os elementos que compõe um documento XML. Sendo eles descritos abaixo: tags: são marcadores que definem início e fim de blocos de informações, na verdade eles são os responsáveis pela característica da linguagem de possibilitar a extração de significado das informações contidas num documento XML; instruções de processamento: são palavras reservadas que passam informações para os interpretadores da linguagem; entidades: são fragmentos de texto ou simples caracteres importados pelo interpretador todas as vezes que o documento for carregado, possibilitando sua alteração se desejado; comentários: informações que são desconsideradas pelo interpretador no momento da exibição das informações servem principalmente como documentação de código, a fim de facilitar a manutenção ou alteração; atributos: são usados em geral para fornecer propriedades especiais as tags, sendo de muita utilidade na linguagem XML; declaração do tipo de documento: são instruções guardadas em um arquivo separado, que definem qual a estrutura que o documento XML deve seguir, ou seja, qual a ordem e quais tags podem estar contidas, bem como os atributos e conteúdo destes, basicamente formalizam um padrão para aquele determinado arquivo; Seções CDATA: possibilitam a utilização de caracteres reservados como texto Documentos bem-formados Os documentos que seguem especificações da sintaxe XML são chamados documentos XML bem-formados. Estes podem ser utilizados sem estarem associados a um arquivo de esquema, como um arquivo Document Type Definition (DTD) ou XML Schema que descrevam

48 36 suas estruturas, são conhecidos nesta forma como documentos XML independentes (ANDERSON et al, 2001). Objetos de dados são documentos bem-formados se: - a sintaxe obedece às especificações XML; - os elementos formam uma árvore hierárquica, com um único nó raiz; - não há referência a entidades externas, a não ser que seja fornecido um DTD. (ANDERSON et al, 2001, p. 67). Documentos XML bem-formados contêm elementos separados por tags iniciais e finais aninhadas adequadamente, formando uma árvore hierárquica cujo único relacionamento direto permitido é o de pai-filho. Resumindo, pode-se afirmar que um documento XML é bemformado quando não contém erros de sintaxe que comprometam sua correta interpretação pelo browser (FURGERI, 2001). Segue um exemplo de documento XML bem formado, conforme figura 4 a seguir. Figura 5: Fragmento de código XML CAGLE et al. (2000). A tag <CD>, o elemento root, envolve todo o documento, indicando que as tags internas referem-se a itens do CD. O exemplo demonstra características do <CD> e de song incluso no contexto <CD>.Observe como todas as tags são iniciadas e terminadas, fator que deve ser

49 37 seguido integralmente. Esta figura representa um pequeno exemplo, portanto poderia tranqüilamente conter mais elementos <song>, ilustrando todas as faixas de áudio do <CD>. O trecho de código a seguir mostrado pela figura 5, está sendo exibido pelo browser Internet Explorer 6.0, cabe ressaltar que não se está exemplificando exibição (estética), senão estaria sendo usado folhas de estilo como Cascading Style Sheets (CSS) ou Extensible Stylesheet Language (XSL), para formatar a exibição dos dados. Figura 6: Fragmento de código XML exibido no IE 6.0. CAGLE et al. (2000). Abaixo apresenta-se a estrutura hierárquica em forma de árvore do exemplo mencionado na figura 5, construído pelo software XMLwriter 6.0, conforme figura 6. Figura 7: Estrutura hierárquica de um documento XML bem-formado.

50 PARSERS Segundo Anderson et al (2001), Parsers analisam a sintaxe de documentos XML e podem ser classificados como: - sem validação: atua como simples verificador de sintaxe, apontando se o documento é bem-formado ou não; - com validação: fazem uso de DTDs para validar a sintaxe XML, bem como o conteúdo dos dados de documentos XML bem-formados. O comportamento dos parsers foi alterado parcialmente visando diminuir a sobrecarga sofrida por aplicações que trabalham com dados XML. ANDERSON et al (2001) justifica sua afirmação, citando como exemplo os caracteres que delimitam o final de um registro num arquivo XML, que varia normalmente de acordo com o sistema operacional em uso. Através dos parsers os registros dos arquivos XML são normalizados de modo que todos os caracteres são transformados em um caractere (hex0a), evitando que a aplicação se preocupe com isso. Os espaços em branco são passados integralmente para a aplicação, diferente das linguagens HTML e SGML. Além disso, os valores dos atributos são normalizados pelos parsers, antes de serem passados para a aplicação. Os parsers podem ser divididos ainda em: parsers voltados para o evento: estes efetuam chamadas de callback para a aplicação, a cada classe de dados XML avaliada. Deixando a cargo da aplicação o manuseio dos dados, apresentados através de callbacks (chamadas inversas). Neste caso os parsers não armazenam a árvore do elemento e nem dados, após terem tido sua sintaxe avaliada. Estes parsers em geral, não requerem alto poder de processamento, como por exemplo, o Expat, que será mencionado na seqüência. Um grupo liderado por David Megginson elaborou uma interface padrão para a análise sintática de documentos XML com base em evento, chamada The Simple API for XML (SAX). SAX foi implementado em várias linguagens, e suporta muitos parsers diferentes;

51 39 parsers baseados em árvore: árvores hierárquicas são estruturas muito aplicadas na engenharia de software, basicamente todos os documentos XML bem-formados são estruturados em forma de árvore. Praticamente a maioria dos parsers baseados em árvores faz uso do Document Object Model (DOM), definido pela W3C. O DOM é uma plataforma de interface neutra para manipulação de dados estruturados em forma de árvore hierárquica. O DOM necessita de bom gerenciamento de memória virtual, pois carrega toda a árvore em memória para ser manipulada. Sendo assim, quanto mais extensos forem os documentos XML, maior será o uso de memória virtual e conseqüentemente maior demanda de processamento. Na verdade, parsers baseados em árvore na maioria dos casos são implementados sob parsers baseados em evento que oferecem todo o suporte necessário à construção da árvore DOM. As APIs DOM e SAX serão abordadas detalhadamente no decorrer do trabalho. Já Hunter (2000), afirma que o principal motivo para a criação de todas as regras sobre documentos XML bem-formados, é poder criar um programa de computador que leia os dados e nos informe facilmente a marcação dos mesmos. Cita também, a especificação do XML, elaborada pelo W3C que define que um módulo de software chamado processador XML, é usado para ler documentos XML e prover acesso a todos os seus dados e sua estrutura, supõe-se que o processador faça este trabalho através de outro módulo chamado aplicação. Processadores XML são conhecidos comumente como parsers, e mesmo um simples parser prove para a aplicação qualquer informação necessária. Existem muitos parsers XML atualmente, muitos deles são softwares livres, ou seja, não é necessário pagar licença de uso para um determinado proprietário para utilizá-los. Hunter (2000) ainda apresenta alguns dos melhores e mais conhecidos parsers XML, como Microsoft Internet Explorer Parser, James Clark s Expat, Saxon, Xerces e Oracle XSL. Microsoft Internet Explorer Parser (MSXML): a Microsoft teve seu primeiro parser XML anexado ao Internet Explorer 4, com um pequeno esboço do que seria a especificação XML. Com o lançamento da versão 5 do Internet Explorer, a implementação do XML foi atualizada refletindo a especificação do XML 1. Encontra-se disponível segundo website do proprietário na versão 4 SP2, para Internet Explorer 6.0 e superiores.

52 40 James Clark s Expat: o Expat é um parser XML 1.0 escrito em C. É um parser orientado ao fluxo que requer configuração de alimentadores para que o mesmo faça a analise da estrutura de um documento XML. Ele é um software livre, tanto para uso doméstico como comercial. O projeto expat faz parte do portal sourceforge.net, repositório destinado a códigos fontes abertos e aplicações livres. Saxon: é um pacote de ferramentas para processamento de documentos XML. Pode ser usado para escrever folhas de estilo XSL, ou aplicações Java, ou ainda para combinação dos dois. Ele pode gerar como saída arquivos XML e HTML, bem como arquivos com separadores de texto como vírgula, mensagens de EDI ou dados em base de dados relacional. Mantido por Michael Kay (Parsers, sd). Xerces: fornece uma coletânea de classes para geração e analise gramatical de XML. Disponível em Java e C++, implementando as especificações W3C XML e DOM níveis 1.0 e 2.0, bem como API Sax 1.0 e 2.0. É altamente modular e configurável e suporta também o esboço de XML schemas especificado pela W3C. Provê acesso completo a strings Unicode, já que este é parte chave do padrão XML. Oferece compatibilidade com o MSXML parser da Microsoft. Oracle XSL: a Oracle fornece uma série de parsers de XML em Java, C, C++, e PL/SQL. Sendo estes parsers componentes XML autônomos que analisam gramaticalmente um documento XML (ou um DTD) de modo que possa ser processado por uma aplicação. Estes suportam as especificações DOM e SAX, XML Namespaces e transformações XSL, operando em modo validador ou não. Existe uma grande diversidade de parsers XML, porém foram citados alguns dos mais conhecidos. No subitem seguinte, serão descritos brevemente aspectos relativos a declaração da linguagem XML, tags especiais, codificação bem como algumas ferramentas associadas DECLARAÇÃO XML Na maioria das vezes, é reconhecido o tipo do arquivo através das suas declarações iniciais. No caso da linguagem XML a declaração inicial é opcional, porém se o programador

53 41 optar por faze-la, ele poderá omitir alguns de seus atributos e mesmo assim o documento XML ainda será bem-formado. Porém, a não declaração da mesma, pode causar problemas futuros como por exemplo, a codificação pode não ser detectada automaticamente de forma correta pelo parser. No quadro 1, demonstra-se um exemplo de declaração da linguagem XML. Quadro 1: Exemplo de declaração da linguagem XML <?xml version= 1.0 encoding= UTF-8 standalone= yes > O exemplo mostrado no quadro 1, refere-se à declaração completa de um documento XML, pois possui os três atributos com seus respectivos valores. Como foram citados anteriormente, os atributos encoding e standalone poderiam ter sido omitidos. Já o atributo version é obrigatório e deve ser valorado com 1.0 segundo a especificação 1.0 da W3C. Segundo a especificação da W3C, os atributos descritos são: version: refere-se a versão corrente da linguagem, se for colocado um valor maior que 1.0 o documento será rejeitado pelos parsers atuais, logo por questão de lógica é melhor atribuir a esse atributo sempre o valor 1.0, para evitar problemas referentes a diferentes versões da linguagem com o passar do tempo, pois as atualizações são acumulativas, sendo assim compreendem as especificações correntes e as novas; encoding: este atributo refere-se ao tipo de codificação dos caracteres, ou seja, segundo ANDERSON et al (2001), baseado na norma de especificação da linguagem pelo W3C, este atributo poderia conter, por exemplo, UTF-8 e UTF-16 (Unicode), ou ISO UCS-2 e ISO UCS-4 (ISO 40646), ou ainda ISO-8859-n (sendo n dígitos de 1 a 9). standalone: este atributo é instanciado de acordo com as especificações de entidades. Pode conter os valores yes ou no, sendo que o valor yes significa que todas as declarações necessárias das entidades estão contidas no mesmo documento. Já o valor no define que as declarações de entidade estão em um arquivo externo, mais especificamente em um arquivo DTD.

54 DEFINIÇÕES DE TIPO DE DOCUMENTO (DTD) Segundo as especificações da W3C (2004), a marcação em um documento XML define a estrutura lógica e física, bem como têm a função de associar pares de atributos nomes valores, através de sua estrutura lógica. A XML possui um mecanismo que define restrições quanto a estrutura lógica dos documentos, suportando o uso de unidades de armazenamento predefinidas que é chamado de Document Type Definition (DTD). Definição: um documento XML é válido se este possui associado um document type declaration e se o documento confere com as restrições expressas nele (W3C). Um DTD é formado em termos por quatro palavras chave, ELEMENT, ATTLIST, ENTITY e NOTATION, que determinam o conteúdo de um documento XML (ANDERSON et al, 2001), detalhados a seguir: ELEMENT: declaração de um elemento XML; ATTLIST: define a declaração de atributos que podem ser atribuídos a um elemento bem como seu respectivos domínios; ENTITY: define que o valor de um determinado atributo é referencia a uma entidade; NOTATION: define que o valor do atributo seja uma notação anterior, Permite dados não XML, desde que sigam as restrições declaradas na tag <!NOTATION >. Para melhor entender veja nas gravuras a seguir um exemplo de arquivo XML e o seu DTD. Figura 8: Documento XML Observe na tag <!DOCTYPE AVISO SYSTEM AVISO.DTD > que o arquivo XML possui um arquivo aviso.dtd associado a ele. Através deste arquivo.dtd é possível validar um arquivo XML, ou seja, o arquivo.dtd possui as restrições estruturais que o arquivo XML a

55 43 ele associado deve seguir, desta forma um dos muitos parsers XML existentes podem verificar o arquivo de esquema (neste caso.dtd ) e o arquivo XML gerado e dar como resultado arquivo válido ou inválido. O resultado será arquivo válido caso o arquivo XML associado não viole nenhuma das restrições impostas no seu arquivo de esquema, do contrário este arquivo será inválido, estando em desacordo com as restrições do arquivo de esquema, e desta forma não pode ser utilizado para, por exemplo, intercâmbio de dados, pois a aplicação que ira ler o arquivo e utilizá-lo terá problemas em interpretá-lo. Segue na figura abaixo o arquivo aviso.dtd mencionado acima. Figura 9: Arquivo aviso.dtd Cada um dos itens deste arquivo serão descritos na sequencia, como conceitos de entidade, elementos e atributos segundo a visão de ANDERSON et al (2001). O leitor deve ter em mente que as mais variadas definições sobre a XML são baseadas nas especificações da W3C, caso contrário não teriam validade tendo em vista, que a W3C é o órgão máximo regulamentador da mesma Entidades A XML oferece ótimos meios de referenciar fragmentos de conteúdo repetitivamente evitando o uso desnecessário de espaço (código XML) e minimizando as perdas de tempo com digitação por parte do programador. Declarando entidades no DTD, pode-se referenciálas quantas for necessário. Declarando uma entidade no DTD, o programador define o nome e conteúdo da mesma. Se esta for declarada dentro do documento XML, por definição, ela é chamada de entidade geral. Uma entidade geral pode ser definida como entidade analisada sintaticamente ou entidade não analisada (ANDERSON et al, 2001). Segundo a definição da W3C (2004), as

56 44 entidades podem ser internas ou externas, o que ANDERSON et al (2001) chama de gerais ou de parâmetro. Uma entidade geral permite a declararação de um fragmento de texto que será analisado sintaticamente com o restante do documento XML, fazendo uso de nome e o texto em si. Observe o exemplo, ilustrado pelo quadro 2 a seguir. Quadro 2: Exemplo de declaração de uma entidade geral <!ENTITY direito Direitos reservados a Expresso São Miguel Ltda > Através desta declaração pode-se referenciar o texto com as informações de direitos autorais em qualquer lugar do documento, simplesmente chamando o nome da entidade direito. Temos que avisar o parser sobre nossa intenção, referenciando o nome da entidade usando o caractere & (ampersand) seguido do nome mais o caractere ponto-evírgula. A seguir no quadro 3, é demonstrado um exemplo de como referenciar uma entidade geral em um documento XML. Quadro 3: Exemplo de referência a uma entidade geral &direito; Uma entidade geral pode indicar seu conteúdo externamente, como mostra o quadro 4 na seqüência. Quadro 4: Exemplo de indicação de conteúdo externo de uma entidade <!ENTITY direito SYSTEM > A palavra reservada SYSTEM serve para indicar a origem externa do texto de substituição. Quando o conteúdo de uma entidade é externo e o padrão de codificação de caractere for diferente do padrão usado no documento principal, deve-se utilizar um atributo com o valor da codificação, senão o documento externo não será analisado pelo parser.

57 45 Já uma entidade de parâmetro, é declarada dentro de um DTD e também é analisada sintaticamente. Elas centralizam construções comuns usadas num determinado DTD, evitando modificações em construções em qualquer local do DTD. Sua declaração é composta pela palavra reservada ENTITY seguida do caractere percentual e do nome da entidade, mais o valor de substituição. Pode ser algo do tipo demonstrado pelo quadro 5. Quadro 5: Exemplo de declaração de uma entidade de parâmetro <!ENTITY % pessoaparametros idade CDATA #IMPLIED peso CDATA #IMPLIED altura CDATA #REQUIRED > Os atributos #IMPLIED e #REQUIRED utilizados no quadro 5, serão explanados no subitem Além das mencionadas acima existem as entidades predefinidas, que servem para evitar que caracteres de marcação sejam confundidos com caracteres usados no valor de substituição. Para isso qualquer caractere pode ser referenciado no valor de substituição através de uma referência numérica. Por exemplo: Tabela 1: Exemplos de referência numérica de entidades predefinidas Caractere Referência Numérica < < > > & & (apóstrofe) &apos; (aspas duplas) " Fonte: (ANDERSON et al, 2001). Abaixo no quadro 6, um exemplo de aplicação de entidade predefinida: Quadro 6: Exemplo de entidade predefinida <operacao>s < x, se 2 < x > 10</operacao>

58 46 Seria o mesmo que representar, a expressão ilustrada no quadro 7 a seguir. Quadro 7: Expressão análoga ao demonstrado no quadro 6 s < x, se 2 < x > Elementos Pode-se dizer que o componente mais importante da XML é o elemento. Elementos são declarados nos DTDs utilizando a tag ELEMENT. Uma tag ELEMENT possui além da palavra reservada o nome do elemento e a especificação de seu conteúdo. Um elemento pode conter conteúdo nulo, elemento, misto e qualquer. Um elemento nulo pode conter atributos, porém não texto e nem filhos e é definido através da palavra EMPTY. Elemento é o nome dado ao atributo que possui elementos filhos, mas não possui texto. Já um elemento misto, como o próprio nome sugere, possui uma mistura de elementos e texto. Já o tipo de conteúdo qualquer ou ANY como é codificado, aceita todos os tipos de combinação de elementos e texto, porém deve ser aplicado com certa precaução, pois faz com que o parser faça uma analise muito superficial. Um modelo de conteúdo consiste em um conjunto de parênteses envolvendo algumas combinações de nomes de elemento filho, operadores e palavras chave #PCDATA. Os operadores são usados para indicar cardinalidade e indicar como os elementos e dados de caractere podem ser combinados. (ANDERSON et al, 2001, p. 87). Tabela 2: Operadores de ordem e seus significados Operadores de Order Significado, (vírgula) sequência estrita (barra) opção Fonte: (ANDERSON et al, 2001).

59 47 Exemplificando, segue abaixo no quadro 8, breve exemplo de aplicação do operador (,), demonstrando a combinação dos elementos em seqüência. Quadro 8: Exemplo de aplicação operador (,). <!ELEMENT nomepessoa (Primeiro, meio, ultimo)> Mostrando a aplicação do segundo operador ( ), segue abaixo o exemplo que deixa clara a função de escolha do operador no quadro 9. Quadro 9: Exemplo de aplicação operador ( ). <!ELEMENT corveiculo (verde azul)> Atributos Os atributos oferecem formas de complementar os elementos, dando-lhes propriedades. São declarados no DTD utilizando a tag ATTLIST, que é na verdade uma lista de atributos que pode conter 1 ou mais atributos. Segue um exemplo simples da declaração de atributos, conforme quadro 10. Quadro 10: Exemplo de declaração de atributos. <!ATTLIST elemento1 descricao CDATA #REQUIRED> A declaração acima define basicamente a palavra reservada ATTLIST seguido do nome do elemento (elemento1) e do seu atributo (descrição) bem como o tipo de dado, neste caso CDATA determina que o atributo conterá texto e o valor padrão do atributo o qual será mencionado na seqüência. eles: Segundo a W3C (2004), são 4 os valores padrão que um atributo pode conter, são

60 48 Tabela 3: Tabela de valores padrão possíveis para um elemento. Fonte: (ANDERSON et al, 2001). Atributos podem ser de diversos tipos, os tipos possíveis são mostrados abaixo por FURGERI (2001) de forma sintetizada: CDATA: texto puro (string de caracteres); (val1 val2...): lista de valores, também conhecido como grupo de valores ou valores enumerados; ID: como o nome sugere, deve ser um identificador um valor único; IDREF: identificador de outro elemento; IDREFS: lista de identificadores para outros atributos; NMTOKEN: nome válido na linguagem XML; NMTOKENS: lista de nomes válidos em XML; ENTITY: uma entidade; ENTITYS: lista de entidades NOTATION: uma notação; 4.13 API S XML Para facilitar o processamento de arquivos codificados em XML existem Applications Programming Interfaces (APIs) específicas que provêm acesso e oferecendo uma série de funcionalidades para manipulação deste arquivos como carregar os dados, separá-los em

61 49 tipos, validar, navegar e acessar componentes entre outras. Serão citadas apenas as duas principais APIs para processamento de arquivos XML que são Document Object Model (DOM) e Simple API for XML (SAX) Document Object Model (DOM) A API DOM é uma recomendação da W3C, na qual arquivos XML são representados em forma de árvore, ou seja, são estruturados em forma de árvore. Por exemplo, observe a figura 9 abaixo: Figura 10: Exemplo documento XML simples Observe que o nodo raiz é revendedor, mais abaixo tem-se dois nodos filhos contato e automovel. O nodo filho contato possui dois nodos filhos endereco e telefone, e o nodo automovel por sua vez possui também dois nodos filhos preco e cor formando assim uma estrutura de árvore, como demonstrado na figura abaixo:

62 50 Figura 11: Documento XML representado em forma de árvore A API DOM carrega todo o documento XML em memória, ou seja, constrói a árvore que representa o documento todo em memória, para prover acesso a ele, como demonstra a figura seqüente. Figura 12: Modelo de memória DOM (conceitual) A figura demonstra que passando um documento XML (origem) para um parser, se houver algum erro será retornado um relatório com os dados do mesmo, do contrário será retornado um objeto DOM que dará acesso a toda a estrutura do documento XML,

63 51 possibilitando operações como busca, alteração, exclusão e edição. Cabe ressaltar que ao efetuar qualquer tipo de busca ou operação é necessário iniciar pelo nodo raiz e subir os níveis hierárquicos da árvore que representa o documento. O modelo DOM em relação ao SAX requer mais hardware, ou seja, pelo fato de carregar toda a árvore que representa um documento XML em memória requer maior poder de processamento e mais memória RAM ou virtual para armazená-lo enquanto está sendo manipulado. Em geral o modelo DOM é mais indicado na manipulação de documentos XML menores ou nos casos onde haja necessidade de execução de várias operações, devido ao seu modo de operação. Em resumo, o modelo DOM é mais pesado do que o modelo SAX que será apresentado na seqüência, mas também é mais flexível e mais poderoso, pois com ele podese acessar objetos em um documento XML randomicamente, além de prover acesso a estrutura do documento XML, permite correlacionar, cruzar e combinar dados conforme desejado pelo programador Simple API for XML (SAX) A API SAX baseia-se no acesso serial a documentos XML, ou seja, o arquivo XML é lido de modo seqüencial. A API SAX requer menos memória e menos processamento do que a API DOM, pois não carrega o arquivo XML todo em memória para processá-lo. Além disso, SAX não provê acesso a estrutura de documentos XML. SAX faz a leitura de um arquivo XML pelo início e gera eventos à medida que encontra elementos. Sendo assim, não é possível acessar elementos de modo não seqüencial, além disto, SAX não é um padrão que apresenta noção de estado, pois os métodos são invocados de forma seqüencial independentemente do que já foi processado. É mais indicado para leitura de arquivos XML extensos ou quando não há necessidade de execução de várias operações, pois como foi mencionado necessita de menos recursos computacionais, porém oferece menos recursos em relação ao modelo DOM. Como neste trabalho será usada a API DOM, a API SAX não será detalhada.

64 NAMESPACES Partindo do princípio que documentos XML não são isolados, ou seja, interagem com outros documentos XML e também com documentos HTML, muitas vezes ocorrem situações em que usamos o mesmo nome de elemento para coisas distintas em documentos diferentes, o que causa ambiguidade. Por exemplo, podemos usar o elemento TITLE para coisas distintas como TITLE de uma página, de uma pessoa ou ainda de um livro em documentos XML ou HTML. O conceito de Namespaces serve justamente para evitar ambiguidades em aplicações XML que fazem uso de varios documentos XML e HTML. O conceito de Namespaces evita que haja problemas com ambiguidade de nomes de elementos principalmente quando a interação entre documentos XML e HTML, pois isto é comum principalmente com os elementos title, a, script, style e font. As ambiguidades causam conflitos gerando confusão e erros em aplicações. A introdução de Namespaces elimina a ambiguidade associando uma Uniform Resource Identifiers (URI) a cada aplicação XML, anexando um prefixo a cada elemento indicando a qual aplicação ele pertence. Por exemplo, usando Namespaces podemos ter BOOK:TITLE ou HTML:TITLE, onde BOOK e HTML são prefixos identificadores. O quadro 11 exemplifica a declaração de uma URI de um Namespace. Quadro 11: Exemplo de declaração URI de um Namespace xmlns:h= Como se pode perceber o prefixo ns é adicionado ao atributo xml, onde o prefixo H será usado para associar elementos a URI A utilização se Namespaces é recomendada pela W3C, porém dos padrões XML este é o mais controverso, tanto que alguns autores optam por não menciona-lo em seus trabalhos. A principal discrepância se dá no sentido de que na prática Namespaces são incompatíveis com DTS s. (HAROLD, 2001)

65 EXTENSIBLE STYLESHEET LANGUAGE (XSL) Durante o desenvolvimento e uso de aplicações que fazem manipulação de documentos XML, são comuns os casos onde se faz necessário modificar ou transformar estes documentos a fim de melhorar sua aparência, redefini-los estruturalmente para casos de uso específicos ou manipulá-los de forma dinâmica. A linguagem XSL é baseada na linguagem XML e pode-se afirmar que ela foi desenvolvida para permitir e prover a transformação de um documento XML em outro documento XML, ou ainda transformar documentos XML em muitos outros formatos de apresentação (DYKES E TITTEL, 2005). A troca de informações entre sistemas distintos é uma prática cada vez mais comum, e em muitas dessas trocas utiliza-se a linguagem XML. Em geral dois sistemas não utilizam o mesmo vocabulário XML internamente, assim utilizam XSL para converter os documentos XML para vocabulários próprios para que possam ser compreendidos e trabalhados. Segundo Anderson et al (2001), a linguagem XSL original foi dividida em 3 linguagens, que são: XSLT: transformação; XSLF: representação, mas pode utilizar XSLT; XPath: acesso a estrutura básica de XML. Se tratando de intercâmbio de dados entre sistemas, Dykes e Tittel (2005) comentam que geralmente em situações que ocorrem troca de informações entre empresas, há um grande nível de cooperação entre as partes, logo uma empresa A pode utilizar a XSLT para transformar os documentos XML no vocabulário da empresa B antes de enviá-los, e viceversa. Este tipo de solução é mais flexível e mais viável, do que reconstruir um sistema que esta baseado num determinado DTD ou Schema, a cada necessidade de adaptação. A transformação de documentos XML é extremamente útil, principalmente quando se trata de integração de sistemas e intercâmbio eletrônico de dados (EDI). Em geral as três linguagens são importantes e podem ser utilizadas em conjunto para uma solução mais completa.

66 XPath De acordo com Anderson et al (2001), a recomendação XPath do W3C é um esforço conjunto entre as equipes de estudo XPath e XSL, pois ambos precisavam encontrar uma maneira de selecionar ou filtrar uma parte de um documento XML. O XPath é o principal elemento da XSLT, pois através dele são localizados ou filtrados apenas os fragmentos ou elementos desejados de um documento XML. XPath faz uso de caminhos (Paths) para identificar nós em documentos XML, por exemplo: Figura 13: Fragmento de arquivo XSL Observe o elemento XPath sublinhado na figura acima, /DATAPACKET/ROWDATA/ROW ele define a seleção de todos os elementos ROW do arquivo de Conhecimentos embarcados demonstrado abaixo:

67 55 Figura 14: Arquivo CPF/CNPJ.ctrc.emb.xml De onde são extraídos os valores dos atributos de ROW que guardam as informações sobre os conhecimentos embarcados de determinado cliente, ou seja, documentos XML, podem ser representados em forma de árvore (como uma árvore de diretórios do sistema operacional MS Windows por exemplo), desta forma XPath usa uma expressão padrão para identificar nós em um documento XML. Este padrão é composto por uma lista de nomes de elementos filhos separada por barras (níveis) que descreve o caminho através do documento XML. A figura abaixo faz analogia entre o caminho das expressões XPath e o caminho da árvore de diretórios do sistema operacional MS Windows. Figura 15: Árvore de diretórios do sistema operacional MS Windows

68 56 As expressões Xpath podem conter caminhos absolutos representados pelo caractere / como é o caso do exemplo citado na figura Figura 12: Fragmento de arquivo XSL onde o retorno são apenas os elementos do nível descrito na expressão, ou retornar todos os elementos que casem com o critério da expressão independente do nível em que se encontrem no arquivo XML representados pelo caractere //. A seguir uma breve descrição da linguagem XSLT e algumas funcionalidades XSL Transformations (XSLT) Segundo W3C, a transformação na linguagem XSLT é expressada através de um documento XML bem-formado em conformidade com a especificação Namespaces. Basicamente a transformação expressada em XSLT descreve regras para transformação de uma árvore origem em uma árvore destino(resultado). A linguagem XSLT baseia-se em padrões de transformação, sendo assim um documento XSLT stylesheet também é um documento XML, que busca padrões em outro arquivo XML e aplica nele tranformações programadas podendo gerar como saida vários tipos de arquivos como PDF, HTML ou mesmo outro arquivo XML. Sendo assim, com a linguagem XSLT pode-se transformar um arquivo XML em outro arquivo XML, ou em diversos outros tipos de arquivos. Figura 16: Exemplo de arquivo XML Por exemplo, na figura abaixo demonstra-se um arquivo XML com informações que simbolizam um painel de avisos simples. Observe que este arquivo XML possui um arquivo do tipo XSL associado, que determina quais as transformações este arquivo XML deve sofrer ao ser exibido. A figura sequente demonstra o arquivo aviso.xsl mencionado acima.

69 57 Figura 17: Exemplo de arquivo XSL O código da figura acima, define como os dados do arquivo aviso.xml serão exibidos no browser, ou seja, como as tags(descrevem o significado dos dados) do arquivo XML e os dados contidos entre elas serão dispostos no navegador e seguindo qual formatação. A próxima figura demonstra como o arquivo aviso.xml será exibido no navegador Internet Explorer 6.0, seguindo as regras determinadas no arquivo aviso.xsl.

70 58 Figura 18: Arquivo aviso.xml exibido no IE 6.0 A linguagem XSLT é muito útil, pois no caso deste trabalho possibilita que o mesmo arquivo XML utlizado para intercâmbio de dados seja exibido para usuários na Internet ou localmente em seu navegador preferido. A linguagem XSLT é muito poderosa e oferece muitos recursos que não foram mencionados por que não serão explorados neste contexto. No próximo capítulo serão abordados conceitos de intercâmbio eletrônico de dados, bem como seus meios de implementação, vantagens entre outros fatores que podem colaborar para o entendimento da grande aceitação da XML para este fim.

71 59 5 ELETRONIC DATA INTERCHANGE (EDI) O EDI não é um conceito novo, pois foi concebido e vem sendo utilizado desde A principal mudança se deu na evolução das tecnologias de informação e comunicação e na difusão do uso do EDI. Como já foi citado anteriormente o uso macisso das tecnologias de informação e comunicação é a base para nova realidade competitiva. Para Colcher e Valler (2000), p. 35, o EDI é... considerada atualmente uma ferramenta estratégica em alguns segmentos do mercado, onde a rapidez e segurança na comunicação entre fornecedores e clientes são fatores críticos desse relacionamento.... Na concepção de Bowersox e Closs (2001), p. 191, o EDI ou Intercâmbio de Eletrônico de Dados como também é chamado, é... um meio de intercâmbio de documentos e informações entre empresas, de computador para computador, em formatos-padrão..... Já na visão de Gomes e Ribeiro (2004), p. 169, o Intercambio Eletrônico de Dados... é um formato-padrão para trocar dados de negócios.... O EDI é uma ferramenta que permite transacionar mensagens estruturadas entre computadores de diferentes empresas através de redes de comunicação. As mensagens consistem em documentos padronizados contendo informações necessárias às transações usuais das organizações com seus parceiros. (COLCHER E VALLER, 2000, p. 35) Ainda para Colcher e Valler (2000), não existe uma forma única de solução de implementação de sistemas de EDI, podem ser usadas diversos tipos de softwares dentre eles, sistemas operacionais, protocolos de comunicação, aplicativos e aplicações, linguagens de programação ou de marcação, enfim, as soluções de EDI variam conforme a necessidade e a aplicação de cada caso especifico. Ainda neste contexto, as soluções de EDI variam conforme o ramo de negócio e o segmento de mercado, pois dependendo do caso, pode-se aplicar tipos diferentes de EDI.

72 60 De acordo com Colcher e Valler (2000), as aplicações de EDI podem ser divididas em 3 categorias que são Simpl-EDI, Lite-EDI ou Web EDI. Por Simpl-EDI o autor entende o tipo de EDI mais simples ou mais básico, onde ocorre o mínimo de troca de dados possível, ou seja, são intercambiados apenas uma pequena parcela de informações essencias a uma determinada transação. Por Lite-EDI o autor considera basicamente as mesmas características do Simpl-EDI, ou a maior parte delas. E a Web-EDI que são técnicas que facilitam a implementação da EDI através da Internet fazendo uso de servidores Web. Gomes e Ribeiro (2004) citam algumas das vantagens da implementação de um sistema de EDI: produção sob demanda: a produção é feita de acordo com as vendas, ou seja, a linha de produção é acionada quando uma venda é feita. Isso é possivel graças a automação disposta pela EDI. Desta forma as empresas podem diminuir custos de armazagem e estoque. Dependendo do nível de integração da cadeia de suprimentos, é possível também minimizar a estocagem de matéria-prima, pois um sistema de EDI pode automatizar pedidos de matéria-prima também; iniciar ou inserir o just-in-time: facilita muito a implementação do conceito de justin-time, se houver integração usando EDI. Entende-se por just-in-time, a adoção por parte da indústria, da abordagem onde o capital, a mão-de-obra e o maquinário são alocados na quantidade e tempo necessário para produzir determinada série de produto; reforçar laços comerciais: a EDI cria laços comerciais entre empresas, ou seja, parcerias são constituídas quando se estabelece um sistema de EDI entre empresas; minimizar custos com as compras: normalmente sistemas de EDI são implementados sob algum tipo de contrato, por isso pode-se fazer cotações numa amostra maior de fornecedores e ainda conseguir descontos por volume de compras;

73 61 reduz os estoques: reduz os estoques de uma forma geral, eliminando a ineficiência dos controles manuais. E ainda elimina a necessidade de impressão, postagem e o manuseio excessivo de documentos comerciais e formulários. Também contribui no sentido de minimizar ou extinguir totalmente, atrasos de entrega de documentação (informações) proporcionado pela padronização de formato. E por fim, reduz custos com funcionários, postagem, comunicação e suprimentos como papel. Para Fleury, Wanke e Figueiredo (2001), as aplicações e sistemas de informação que dão suporte ao SCM, bem como sua abrangência que transpõe os limites da empresa e se estende ao longo da cadeia de suprimentos, é possível devido conectividade fornecida pela EDI e a rede Internet. A EDI tem suas características próprias de acordo com o segmento em que é implementada. Essas particularidades serão citadas na seqüência, de acordo com a visão de Colcher e Valler (2000). 5.1 A EDI NA LOGÍSTICA DE TRANSPORTES Como nos demais segmentos, a logística e os transportes rodoviários possuem algumas particularidades em relação as demais no que tange a sistemas de EDI, devido principalmente ao fato de que essas empresas não fazem parte da cadeia de suprimentos de forma direta. O uso da EDI na logística de transportes permite que a transportadora ofereça aos parceiros, informações como rastreamento de mercadorias, status da mercadoria (em transito ou entregue) com sua respectiva data e hora entre outras. Muitas vezes a implantação de sistemas de EDI são exigências de clientes, que pressionam as transportadoras nesse sentido para que possam melhor gerenciar o fluxo de mercadorias que recebem e enviam, principalmente quando se trata de parceiros que atuam em redes de distribuição e atacado. Segundo Colcher e Valler (2000), a lenta adoção da EDI no ramo de transportes logísticos se deve a subutilização das tecnologias de informação. Essa realidade vem mudando nos últimos anos, devido a intensiva pressão de grandes indústrias de

74 62 transformação (melhores clientes), sob ameaça de perderem espaço para as transportadoras que oferecem este serviço. Os benefícios da adoção da EDI são claramente percebidos pelas 3 partes envolvidas nos negócios, que são empresa remetente, transportadora e destinatário. A empresa que remete mercadorias pode expandir seus negócios, pois através da parceria, sabe com pequena margem de erro o tempo de entrega e a qualidade do transporte (poucas avarias). A transportadora também pode expandir seus negócios pois pode aumentar o número de parceiros ligados a sua rede de EDI, bem como as reduções de custo já citadas. E o destinatário tem principalmente a vantagem na redução do tempo de entrega e o controle efetivo das mercadorias, que serão entregues a ele, bem como o status das mesmas. Colcher e Valler (2000), ainda destacam 7 fatores críticos na adoção de um sistema de EDI que são: setor de atuação, qualidade da infra-estrutura de telecomunicações, integração com sistemas internos, aumento do número de parceiros da rede, comprometimento dos recursos humanos, adoção de padrões universais e introdução de mudanças organizacionais. O ponto crítico do setor de atuação refere-se ao ramo de trabalho da empresa, pois nem todos os ramos são passíveis da adoção de EDI. Pelo fato de requerer padronização, a EDI torna-se inflexível, fazendo com que geralmente apenas empresas com grande número de transações justifiquem as mudanças necessárias para adequação e a perda de flexibilidade nas operações. Quanto a qualidade da infra-estrutura de telecomunicações, pode-se dizer que é um fator crítico no que diz respeito a disponibilidade do serviço (o sistema precisa estar sempre on-line), bem como a qualidade na transmissão dos dados (o sistema não pode sofrer quedas e interrupções) ou ainda o tipo de sistema de EDI aplicado, pode contribuir com a facilidade de acesso, alta disponibilidade e baixa demanda de banda de rede. O fator de integração com sistemas internos, esta relacionado a integração do sistema de EDI com os sistemas internos como financeiro, faturamento e compras ou ERP da empresa. Assim que for estabelecida a rede de EDI certamente os clientes esperam incrementar as informações que lhe são fornecidas ao longo do tempo, logo o sistema de EDI precisa possibilitar essa expansão. O aumento do número de parceiros da rede, é crítico para que a empresa não precise manter 2 métodos de comunicação simultâneos, o antigo baseado em telefones e fax e o novo

75 63 com transações eletrônicas. É necessário que haja um grande numero de adesão ao novo para que o velho seja descartado (se houver interesse). Basicamente a adesão da Edi esta intimamente relacionada com as vantagens que as empresas terão em adotá-la, bem como a conscientização dos colaboradores em torno dessas vantagens. A resistência a mudança é comum nas empresas, principalmente porque as pessoas geralmente sentem-se ameaçadas pelos processos de automação, por isso o comprometimento dos recursos humanos é crítico na implantação de um processo de EDI. As pessoas precisam ser envolvidas e conscientizadas que a mudança trará benefícios a todos e não ameaças de demissões. A adoção de padrões universais é crítica devido a dificuldade encontrada pelas empresas que participam de mais de uma rede de EDI em gerenciar a falta de padrão principalmente no que se refere a códigos de documentos. Por exemplo, cada transportadora possui um padrão de mensagem de EDI, logo as empresas que necessitam de mais do que uma transportadora terão muita dificuldade em adequar o sistema a vários padrões. Seria vital que o segmento adotasse um padrão, para facilitar ou tornar viável a adoção da EDI pela demais partes envolvidas. Os benefícios gerados pela EDI são percebidos em geral a longo prazo e dependem também da reorganização do fluxo de informação que a adoção dessa novo abordagem irá causar no organização. A EDI normalmente centraliza informações que antes eram administradas por diversas pessoas e setores e agora podem ser administrador por um único setor ou nível. 5.2 XML/EDI Muito se ouve, comenta e especula sobre o futuro da EDI. Mas por que conceitos originários de meados de 1962 ainda são importantes atualmente, após gigantescos avanços na área da informática? À medida que o tempo passa, novas necessidades são descobertas e soluções de software amplamente utilizadas por grandes indústrias, órgãos governamentais e vários segmentos de mercado são substituídas ou atualizadas, por novas descobertas tecnológicas ou melhorias significativas, buscando saciar necessidades emergentes baseadas na Internet como a grande difusão do comércio eletrônico nos últimos anos.

76 64 Sendo assim, a integração ferramentas de softwares dos mais variados tipos torna-se pré-requisito para a expansão e consolidação de negócios inseridos nesse novo contexto. Desta forma, busca-se através do uso de padrões robustos de marcação de dados bem como o intercâmbio eletrônico destes dados, integrar sistemas corporativos, automatizar processos e assim interligar empresas. Empresas visam lucro, portanto sempre que possível utilizam padrões abertos e tecnologias livres (não proprietárias), seguras e eficazes, para automatizar seus processos e servir como sustentação para tornarem-se cada vez mais produtivas e competitivas. No desenvolvimento desse tópico serão vistos meios de tornar viáveis soluções para estes problemas. 5.3 O QUE É XML/EDI? A XML/EDI também chamada Internet EDI é a forma pelo qual documentos de negócios são descritos utilizando a sintaxe XML (SEKINE et al, 2003). Ainda seguindo pela lógica de Sekine et al. (2003), pode-se dizer que a XML/EDI tem se baseado em dois valores, os quais são descritos na seqüência. A VAN-EDI que como o próprio nome sugere faz uso das redes Value Added Network (VANs) também conhecidas como redes privadas. E implementação mais antiga e mais conhecida de EDI, surgiu em 1962 a ainda é usada atualmente em algumas grandes indústrias principalmente na Europa. No entanto a Internet EDI, que faz uso da rede Internet, vem sendo utilizada desde 1996 com o principal intuito de reduzir gastos operacionais. Na área de Internet EDI a Web-EDI vem emergindo com avidez, devido ao seu baixo custo operacional e de implementação. Porém, ela ainda possui muitos problemas como manter a interoperabilidade e a dificuldade de conexão automática de extremidades fins dos sistemas computacionais. Em geral para maximizar o poder de competitividade de empresas e indústrias, a colaboração entre processos de negócio dão origem ao planejamento de compra e venda, gerência de pagamentos, gerência de estoques e a gerência de qualidade se torna essencial, bem como a adoção de padrões e processamento eletrônico de dados, também visto como automação de processos. A maioria destes padrões são baseados em tecnologias XML. A solução para realizar a colaboração EDI na prática é sem dúvida XML/EDI.

77 65 Pode-se classificar a Internet EDI em três tipos: Internet EDI (não XML/EDI): usa a rede TCP/IP ou tecnologias da rede Internet como meio de transmissão; XML/EDI Básica: é um tipo de Internet EDI, cujo conteúdo dos documentos de negócio são descritos em formato XM; Colaboração XML/EDI: é uma nova tendência de Internet EDI, que unifica os processos de negócio aos processos eletrônicos ou computacionais, ou seja, possibilita a integração total de processos de negócio em uma cadeia de suprimentos. 5.4 MEIOS DE TRANSMISSÃO Para implementação de um sistema de XML/EDI básica, pode-se considerar alguns métodos e protocolos de transmissão. Sendo eles divididos em 3 tipos, descritos e seguir. a) Transferência através de arquivos A transferência baseada em arquivos caracteriza-se pelo fato de que os documentos de negócio são enviados e recebidos em formato de arquivo. Esta forma de transferência pode ser dada, utilizando o protocolo File Transfer Protocol (FTP), o protocolo Hipertext Transfer Protocol (HTTP) ou Hipertext Transfer Protocol Security (HTTPS). O protocolo FTP é o mais simples dos protocolos de transferência em redes TCP/IP, porém seu uso implica em alguns problemas de segurança, pois os documentos de negócio são frequentemente permitidos a passar por fora do firewall 10 ou das políticas de segurança das organizações. Não é comumente usado aplicações de EDI. 10 Firewall é o nome dado ao dispositivo de rede que tem por objetivo filtrar o tráfego entre redes distintas, impedindo a transmissão de dados nocivos ou não autorizados de uma rede a outra. Pode ser implementado a nível de software e hardware.

78 66 Já o protocolo HTTP concebido para transferência de documentos HTML entre servidores e clientes na Internet, pode ser usado com segurança para transferência de arquivos. Se tratando de segurança, podemos citar a variação HTTPS que possui basicamente as mesmas características do protocolo HTTP, porém implementa o uso de criptografia baseado na Secure Sockets Layer (SSL). Este último, geralmente não tem problemas com passagem através de firewalls, e segundo Sekine (2003) os riscos de falsificação, interceptação e recusa são pequenos pelo fato da transmissão ser ponto-a-ponto. Vem sendo usado largamente em sistemas de colaboração de XML/EDI na troca de mensagens em tempo real. b) Transferência através de A transmissão de documentos de negócio usando através da Internet pode ser feita a partir dos protocolos Simple Mail Transfer Protocol (SMTP) ou Multipurpose Internet Mail Extensions (MIME). O protocolo SMTP é muito conhecido e utilizado para transmissão de s na Internet, já o protocolo MIME foi concebido para transmissão de vários tipo de documentos na Internet, pode ser usado para transmitir e receber documentos de negócio, bem como dados em formato binário. c) Transferência através de web Neste tipo de transferência, documentos de negócio (arquivos empresariais) são convertidos para HTML e postados em servidores HTTP. Sendo assim a busca e extração dos dados através de Commom Gateway Interface (CGI) torna-se possível. 5.5 APLICAÇÕES XML/EDI As aplicações que fazem uso da linguagem XML para Internet EDI são divididas em 3 níveis por Sekine (2003). No nível um o autor considera aplicações simplificadas de XML/EDI onde apenas alguns documentos de negócio são parcialmente convertidos em XML como complemento

79 67 para Web-EDI. Neste nível funções adicionais para Web-EDI, como impressão de relatórios semanais são baixados (download) em menor número, usando arquivos em formato XML. Geralmente documentos XML necessitam de conversão de formato para serem baixados, sendo assim faz-se necessário uma função de tradução. Documentos XML são baixados sem conversão devido a necessidade de personalização do lado do cliente ou da automação da conectividade por parte dos sistemas das empresas. Segundo o autor a função de ordem de compra e recepção pode possuir alta demanda de processamento e ser feita por uma Web-EDI normal, oferecendo alguns problemas de performance, que não são considerados grandes problemas devido ao nível introdutório desta abordagem. Já para o nível dois considera-se que documentos essenciais para o negócio sejam codificados em XML, como as ordens de compras, cotações e recepções. Neste caso podem ser usados s, FTP ou Web para transmissão dos documentos. Sistemas que atendam a estas necessidades podem ser desenvolvimentos usando técnicas próprias ou Application Service Provider (ASP) services. Entende-se por técnicas próprias neste caso, soluções desenvolvidas intelectualmente pelo desenvolvedor, ou seja, não utiliza ferramentas ou arquiteturas especiais para o fim. Outro recurso que pode ser usado com grande eficácia para personalizar a formatação dos dados ou transforma-los é a Extensible Stylesheet Language (XSL), linguagem usada para criar folhas de estilo para documentos XML e também para transformar um documento XML em outro documento XML, ou em outro formato. Na verdade, as empresas cujos sistemas foram ou são construídos para suportar os recursos de flexibilidade e extensibilidade da XML, precisam estar preparadas para constante renovação e adequação, pois o padrão XML ainda está em aperfeiçoamento. Sekine (2003), levanta algumas vantagens neste nivel dois, como por exemplo a necessidade de personalização dos dados ou da apresentação dos dados codificados em XML, problema facilmente resolvido usando XSL ou CSS. Na verdade a grande aceitação do padrão XML, colabora para superação dos problemas de implentação de sistemas XML/EDI tornando-os amenos. Para o terceiro nível, ainda Sekine (2003) estende o uso de XML a banco de dados. Desta forma, num sistema onde os dados mais importantes são baseados em XML, os documentos de negócio para transferência podem ser gerados apartir de um banco de dados,

80 68 com ou sem personalização. O maior objetivo desse tipo de abordagem é somar flexibilidade ao sistema como um todo. O fato de ter o banco de dados principal baseado em XML, possibilita o uso e criação de muitas outras aplicações, baseadas nessa abrodagem. O uso da XML pode ser aplicado conjuntamente em diversas áreas e de diversas maneiras, devido a sua versatilidade e flexibilidade. Pode ser utilizado para integração entre SGDBs, integração entre processos de negócio, integrar pequenas e grandes empresas com complexidade e recursos variando dependendo dos requisitos de cada caso.

81 69 6 SITUAÇÃO ATUAL Segue uma breve descrição dos problemas vividos, bem como a proposta de solução. 6.1 O CONTEXTO DO TRABALHO O escopo desse trabalho não engloba a origem dos dados, mas é interessante saber onde eles se originam e em que momento são tratados ou transformados. Para isso vamos utilizar como exemplo a principal operação da empresa objeto de estudo, que é a prestação de serviço de transporte, ou seja, vamos usar como exemplo o simples fato de remeter um volume qualquer, de uma cidade do estado do Rio Grande do Sul até outra cidade do estado do Paraná. O remetente emite uma nota fiscal de venda da sua mercadoria, a transportadora faz a coleta do material e o leva até a agência da empresa que atende a localidade onde é emitido o Conhecimento de frete da mercadoria que será transportada fazendo uso do Módulo Agência (sistema para emissão de conhecimentos de frete). Essa mercadoria então segue viagem até a central de distribuição mais próxima, de onde é remetida a agência que atende a localidade destino para ser finalmente entregue ao destinatário, que ao receber a mercadoria assina o Conhecimento de frete preenchendo data e hora da entrega. Abaixo imagem ilustrando o exemplo. Figura 19: Exemplo trajeto logístico

82 70 fatos: Como sabemos agora onde a informação se origina, pode-se levantar os seguintes O cliente remetente geralmente deseja saber no mínimo o número e a data de emissão do Conhecimento de frete que foi emitido para sua nota fiscal. O cliente remetente geralmente deseja saber se a mercadoria remetida foi entregue para o seu cliente, sendo assim a empresa precisa repassar para o cliente a data e hora da entrega do Conhecimento de frete mencionado acima; O cliente remetente geralmente deseja saber no mínimo o número, e data de vencimento e o valor da fatura, bem como o número e o valor dos Conhecimentos de frete que compõe a fatura emitida contra ele; Alguns clientes só efetuam a quitação das faturas mediante conhecimento das datas de entrega das notas fiscais embarcadas. Com isso pode-se perceber onde o trabalho se encaixa, ou seja, qual o problema o protótipo proposto visa resolver estabelecendo alguns padrões e fazendo uso da linguagem XML. A empresa objeto de estudo precisa disponibilizar para os clientes por meio digital, informações sobre os Conhecimentos de frete emitidos para as notas fiscais embarcadas pelos mesmos, bem como data e hora que foram efetuadas as entregas das mercadorias e ainda informações sobre as faturas e os Conhecimentos de frete que compõe as referidas faturas, para que os clientes possam obter retorno das transações comerciais efetuadas com a transportadora e persistindo os dados em suas bases de dados e utilizando-os em seus sistemas para fins contábeis, gerenciais e operacionais. Os dados a cerca das entregas dos Conhecimentos de frete são gerados a partir do Módulo Agencia na agência que efetua a entrega. Já as faturas emitidas contra os clientes da transportadora são geradas a partir do Módulo Faturamento (sistema responsável pela manutenção dos Conhecimentos de frete e geração de cobranças). Após a geração dos documentos, os dados ficam disponíveis para o intercâmbio eletrônico através de arquivos texto. Atualmente estes arquivos texto são formatados de acordo com o layout solicitado pelo cliente, sem nenhum tipo de padronização. Segue abaixo um breve exemplo de arquivo texto usado no intercâmbio eletrônico de dados.

83 71 Figura 20: Exemplo de arquivo texto para EDI 6.2 PROBLEMAS VIVIDOS Atualmente para atender a gama de clientes que necessitam de informações a cerca dos conhecimentos de frete, gerados para cada nota fiscal emitida pelo cliente, a empresa objeto de estudo busca desenvolver programas de computador específicos para cada caso, ou seja, personaliza um software para cada cliente com layout próprio e em um determinado período especificado por cada cliente, precisa colocar em execução cada um desses programas que geram arquivos textos, compostos de campos seqüenciais como demonstrado na figura 19 anterior, que são remetidos por manualmente para cada cliente. Causando: morosidade no atendimento: desenvolver um novo programa com layout específico para cada cliente leva tempo, mesmo por que não há como destacar um profissional somente para este fim, muitas vezes o cliente precisa entrar na fila de espera de prioridades do desenvolvedor; falhas humanas: arquivos podem ser remetidos para endereços de incorretos causando atrasos na recepção, ou mesmo esquecendo de remeter o arquivo solicitado pelo cliente no período definido; ineficiência e baixa produtividade: neste contexto processos manuais em geral são ineficientes, por que ocorre muita perda de tempo gerando, redigindo e- mails, anexando arquivos repetidamente, confirmando recebimento enfim, a automação deste processo torna o trabalho mais eficaz e produtivo, rentável para a empresa, pois além de disponibilizar a informação de modo mais ágil

84 72 ainda pode aproveitar o funcionário que efetuava o processo de intercâmbio em outra área; descontentamento dos clientes: a demora no atendimento e as falhas humanas causam descontentamento nos clientes, e consequentemente um grande risco para a empresa, pois em um mercado tão competitivo um simples atraso, ou falha humana pode culminar no rompimento de uma parceria lucrativa; gastos com pessoal: como foi mencionado logo acima, o processo manual demanda tempo do programador/analista para desenvolvimento e depois necessita de um ou mais funcionários para mantê-lo em atividade; demora no processamento: o tempo de processamento pode variar de acordo com o modo que os programas são utilizados, ou seja, se disparados paralelamente num mesmo microcomputador podem levar muito mais tempo para retornarem resultado e ainda não oferece nenhum tipo de dinamismo, pois os arquivos obrigatoriamente precisam ser gerados a partir de programas únicos em datas especificas; estrutura inflexível: como mencionado acima não existe a possibilidade de que o cliente obtenha os arquivos no momento em que desejar pois depende da transportadora para recebê-los e caso haja necessidade de mudança faz-se necessário alterar o programa gerador do arquivo em questão; diversidade de layouts: a grande diversidade de layouts torna o gerenciamento do processo de desenvolvimento e manutenção dos programas uma tarefa complicada, pois para cada cliente a empresa precisa ter unidades de código fonte específicas armazenadas e organizadas para que se possa fazer modificações e adaptações sempre que necessário. dificuldade de controle: controlar uma série de programas, juntamente com períodos para entrega de arquivos, layouts que muitas vezes são complexos, unidades de código fonte para cada cliente em particular, é difícil e complexa; modelo inviável a longo prazo: devido ao grande número de clientes que a empresa possui, não há como manter o método atual, pois como foi elencado acima os problemas de controle são muitos e a estrutura montada nesse sentido

85 73 é rígida, tornando praticamente impossível atender de forma satisfatória uma pequena parcela dos clientes que tendem a fazer uso deste serviço, desconsiderando os que já utilizam. Sendo assim seque abaixo a proposta para solucionar ou mesmo minimizar os problemas vividos atualmente no que diz respeito à transferência de dados entre a transportadora e seus clientes. 6.3 PROPOSTA Através dos estudos realizados a cerca dos conceitos, métodos e particularidades da logística empresarial, gerenciamento da cadeia de suprimentos, gestão de relacionamento com o cliente, redes de computadores entre outros, pretende-se com este projeto sanar as deficiências atuais, padronizando o layout e o tipo dos arquivos utilizados para intercâmbio eletrônico de dados fazendo uso da linguagem XML, padronizando também a geração e a transferência dos mesmos aos clientes da empresa objeto de estudo. Possibilitando desta forma, que os clientes gerem os arquivos no momento em que desejarem, e ainda possam visualizar os mesmos antes de utilizá-los em seus sistemas fazendo uso da linguagem XSL, podendo receber os arquivos diretamente em seu endereço de ou fazendo donwload dos mesmos de maneira ágil e fácil. Para o desenvolvimento do protótipo será utilizado o modelo físico mencionado no anexo I, ressaltando que o mesmo é parte do modelo físico utilizado na empresa objeto de estudo. Será utilizado um modelo físico parcial, por que para este projeto não serão necessárias todas as tabelas utilizadas pelo ERP da empresa, e sim apenas as que possuem dados sobre os conhecimentos de frete, entregas das notas fiscais dos clientes e faturas geradas para pagamento da prestação de serviço. Os nomes e os campos das tabelas do modelo físico tiveram suas descrições alteradas e alguns foram suprimidos, ficando apenas os necessários para construção do protótipo, esta foi uma exigência da empresa objeto de estudo. Para demonstrar o significado da informação em cada parte do contexto logístico, será utilizado um dos módulos do ERP utilizado na empresa objeto de estudo, chamado Módulo faturamento, pois neste módulo são efetuadas as manutenções dos conhecimentos de frete

86 74 de onde pode-se extrair informações e relatórios dos conhecimentos embarcados pelos clientes da empresa, bem como as faturas geradas para cada cliente. Para geração dos arquivos XML que conterão as informações dos conhecimentos embarcados, entregas das notas fiscais emitidas pelos clientes e faturas geradas para cada cliente será desenvolvida uma aplicação WEB codificada na linguagem de programação PHP, que irá acessar os dados do modelo físico do anexo I, implementado no SGDB Borland Interbase 7.1. Serão usados também, o sistema operacional Microsoft Windows XP Professional SP 2, servidor HTTP Apache e linguagem PHP 5.1. Para demonstrar o uso dos arquivos e a relevância destas informações para os clientes, a empresa Multisoftware 11 pôs-se a disposição, alterando seu sistema de gestão empresarial a fim de adaptá-lo ao protótipo, incluindo no mesmo a opção de importar os arquivos gerados pelo protótipo, inserindo os dados dos arquivos XML em seu banco de dados, cruzando as informações de notas fiscais emitidas pelo sistema comercial em questão, com os dados importados dos arquivos obtidos do protótipo, demonstrando a funcionalidade e o significado do trabalho em um caso real. Cabe ressaltar que a empresa Multisoftware não possui nenhum vinculo com a empresa objeto de estudo, ou seja, a transportadora Expresso São Miguel Ltda. A empresa Multisoftware foi convidada a colaborar com o desenvolvimento deste trabalho, adaptando um dos módulos de seu sistema de gestão empresarial a fim de demonstrar o protótipo simulando o uso dos clientes a fim de validar o mesmo. O ambiente para estudo de caso será a matriz da empresa de transportes logísticos Expresso São Miguel Ltda, onde a mesma centraliza sua estrutura de servidores de aplicação, SGDBs e servidores HTTP ideal para o desenvolvimento do protótipo. Em resumo, o protótipo deverá prover agilidade, flexibilidade e dinamismo no que diz respeito à padronização e geração de arquivos eletrônicos para intercâmbio de dados entre empresas. 11 Multisoftware: empresa de desenvolvimento de software para gestão empresarial, com sede em Chapecó.

87 75 7 O PROTÓTIPO Este capítulo retrata detalhadamente a fase de análise, o desenvolvimento e conclusão do protótipo proposto. 7.1 CONSIDERAÇÕES Pode-se afirmar de acordo com o que foi estudado sobre EDI, que o protótipo em questão é um sistema de EDI, classificado segundo SEKINE (2003) como XML/EDI básica. Do ponto de vista das redes de computadores, pode-se afirmar que serão utilizados como meio de transmissão para os arquivos XML, os protocolos HTTP e SMTP, ou seja, os arquivos serão disponibilizados para download ou poderão ser remetidos ao usuário por . Visualizando o protótipo de um nível mais alto, mais especificamente do ponto de vista do gerenciamento da cadeia de suprimentos, resumidamente ele dispõe as informações da empresa objeto de estudo que atua na área logística para seus clientes que estão inseridos em cadeias de suprimentos próprias, como mostra a gravura a seguir. Figura 21: O protótipo em relação ao SCM Do ponto de vista das redes de computadores, tem-se uma visão da arquitetura do protótipo, ou seja, de como será implementado na empresa objeto de estudo a nível computacional, descrito na figura a seguir.

88 76 Figura 22: Esquema do protótipo (redes de computadores) Observando a figura acima, pode-se entender o modelo proposto da seguinte forma: Temos no elemento de numero 1, o microcomputador responsável por servir o serviço de SGDB que estará executando o Borland Interbase 7.1, sob o sistema operacional MS Windows Server 2003; O elemento de numero 2 é o microcomputador responsável por servir os serviços de HTTP (Apache/ (Win32)) e PHP(PHP/5.1.1) sob o sistema operacional MS Windows Server 2003; Os elementos de numero três, quatro e cinco simbolizam os n clientes da empresa acessando a aplicação através da rede Internet com seus navegadores (browsers); De um modo geral tem-se n clientes (usuários) acessando um servidor HTTP, que por sua vez repassa as requisições para o servidor PHP que acessa quando necessário o servidor de SGDB para requisitar os dados necessários para servir o protótipo.

89 77 A seguir são demonstrados e explanados os modelos e diagramas usados na análise do protótipo que o fizeram ter o aspecto demonstrado até este momento. 7.2 ANÁLISE DE REQUISITOS Para elaboração do protótipo foram levantados requisitos funcionais e não-funcionais desejáveis para o protótipo, junto à gerência de TI da empresa. Os mesmos são descritos a seguir Requisitos Funcionais A aplicação deve ser capaz de validar usuário e senha (autenticação); Não permitir a geração de arquivos XML vazios, ou seja, que nao possuam registros; Abstrair o acesso ao banco de dados, evitando que a aplicação precise ser totalmente reescrita (para casos de troca de SGDB) por estar totalmente atrelada a um determinado SGDB; Deve oferecer uma interface de administração da aplicação e outra para acesso dos clientes (usuários); Deve direcionar para a interface correta de acordo com o usuário que efetuar login; A interface de administração da aplicação deve oferecer: o o o o o o opção de menu para inserção de novos usuários; opção de menu para alteração de usuários; opção de menu para exclusão de usuários; opção de menu para exibir todos os usuários cadastrados; opção de menu para localizar usuários; opção de menu para exibir acessos da aplicação por data;

90 78 o o o o opção de menu para exibir acessos da aplicação por usuário; exibir data e hora atual; exibir endereço IP do usuário e navegador em uso; opção de menu para efetuar logout da aplicação. A interface de usuário deverá conter: o o opção de menu para retornar ao momento inicial da aplicação; opção de menu para geração do arquivo de conhecimentos embarcados; oferecer opção de envio por , visualização e download; o opção de menu para geração do arquivo de entregas de conhecimentos embarcados; Oferecer opção de envio por , visualização e download; o opção de menu para geração do arquivo de fatura e espelho da fatura; oferecer opção de envio por , visualização e download; o o o o o opção de menu com informações e contato do suporte técnico responsável; opção de menu com documentação a cerca dos arquivos de intercâmbio, auxiliando programadores a entender o layout proposto bem como arquivo de esquema (DTD) a fim de poder validar os arquivos no ato de recebimento; opção de menu com informações e contato da Matriz da empresa objeto de estudo; opção de menu para efetuar logout da aplicação; cabeçalho contendo saudações, usuário logado, descrição da empresa e data e hora atual;

91 79 os nomes dos arquivos de intercâmbio devem possuir o CPF/CNPJ do usuário, seguido do nome do arquivo(descrição) a fim de proporcionar maior clareza e reduzir riscos de erros; quando os arquivos XML forem enviados por , o assunto do deve ser claro evitando dúvidas ou possíveis erros humanos; deve controlar erros de operação básicos como validar campos em branco e passagem de parâmetros inválidos; deve exibir mensagens de erro notificando o motivo da geração do mesmo; deve bloquear acesso direto as páginas da aplicação, obrigando o acesso através da página de login (mínimo de segurança); possuir menu centralizado, possibilitando acesso rápido e fácil aos clientes e ao administrador da aplicação; Requisitos Não-Funcionais a manutenção deve ser fácil; as páginas devem ser leves e de rápido carregamento; a interface deve ser simples e objetiva; a aplicação não deve conter cores carregadas que prejudiquem a visualização dos dados, usar preferencialmente cores leves e de tom claro; ser desenvolvido usando uma linguagem que evite o uso de programas auxiliares, como máquinas virtuais por exemplo, facilitando o acesso a qualquer tipo de usuário; a aplicação deve preferencialmente possuir 3 ou mais camadas evitando que o banco de dados fique exposto na internet, entre outras vantagens como facilidade de manutenção, evita instalação de software no cliente e separação das funções de cliente, apresentação, lógica de negócio e dados;

92 80 utilizar preferencialmente ferramentas fornecidas como código aberto. 7.3 DIAGRAMA DE CONTEXTO O diagrama de contexto, também chamado Diagrama de Fluxo de dados (DFD) de nível 0, demonstra a interação de entidades externas com o sistema (protótipo), modelado como processo central. A figura a seguir demonstra o diagrama de contexto no protótipo proposto. Figura 23: Diagrama de contexto do protótipo Pode-se perceber que o sistema interage com quatro entidades externas, que são: Módulo faturamento reesponsável pela geração das faturas dos clientes, Módulo Agência responsável pela geração dos Conhecimentos de Frete, o(s) funcionário(s) da empresa objeto

93 81 de estudo responsável pela administração do protótipo e os clientes da mesma (usuários) que recebem os arquivos gerados pelo protótipo. A seguir será demonstrado o DFD nivel DIAGRAMA DE FLUXO DE DADOS (DFD) Para Yourdon (1988), o diagrama de fluxo de dados é uma forma gráfica clara e fácil usada para representar o fluxo de dados em um sistema. O anexo II apresenta o DFD de nível um, sendo assim demonstra o fluxo de dados do protótipo de um nível de abstração mais alto, mostrando as entidades externas mencionadas no DFD de nível zero, com seus processos, bem como os dados de entrada e saída de cada processo a fim de demonstrar o protótipo como um todo. 7.5 MODELO FÍSICO DO BANCO DE DADOS Com o modelo físico do banco de dados procura-se demonstrar o relacionamento entre as tabelas ou entidades. O modelo físico deste trabalho, como foi comentado anteriormente já esta em funcionamento na empresa objeto de estudo com ressalva de algumas tabelas que foram criadas especialmente para o funcionamento do protótipo. Cabe lembrar mais uma vez, que o nome das tabelas e dos campos das tabelas foram modificados e alguns suprimidos por exigência da empresa. Abaixo faz-se uma análise detalhada do modelo físico do anexo I, descrevendo as tabelas e relacionamentos que as tabelas possuem entre si: t_cliente : esta tabela mantêm os dados dos clientes cadastrados na matriz da empresa, ou seja, todos os clientes que ja transportaram alguma vez em sua história com a empresa estão cadastrados nesta tabela, a mesma possui relacionamento com a tabela de localidades (t_localidades);

94 82 t_localidades : esta tabela possui os dados da maioria das cidades existentes no Brasil, possui relacionamento com a tabela de estados (t_uf); t_uf : esta tabela persiste os dados de todos os estados do Brasil; t_usuário : esta tabela armazena os dados de todos os usuários da aplicação (protótipo), e possui relacionamento com a tabela de clientes (t_cliente) fazendo com que só seja possivel cadastrar um novo usuário do protótipo se o mesmo possuir cadastro na Matriz da empresa, desta forma usamos a integridade provida pelo SGDB; t_logacesso : armazena dados de acesso dos usuários, para que seja possível posteriormente saber a data e hora de acesso de cada usuário; t_ctrc : pode-se afirmar que esta tabela é a mais importante neste trabalho, pois ela armazena os dados dos Conhecimentos de frete de todas as agencias da empresa. Esta tabela possui relacionamento com a tabela de clientes(t_cliente) garantindo integridade que todos os Conhecimentos de frete persistidos, possuam clientes cadastrados anteriormente. Possui relacionamento com a tabela de de notas fiscais (t_nfctrc), conhecimentos em titulos (t_conhtitulos), entregas dos Conhecimentos de frete (t_ocorrenciactrc); t_nfctrc : esta tabela possui os dados das notas fiscais de cada Conhecimento de frete emitido, ou seja, um CTRC pode conter uma ou mais notas fiscais que são armazenadas nesta tabela que possui relacionamento com a tabela de CTRCs (t_ctrc); t_titulos : esta tabela armazena os dados dos títulos(faturas) emitidos contra os clientes da empresa. Possui relacionamento com a tabela de clientes (t_cliente), com a tabela de empresas 12 (t_empresa) e com a tabela de conhecimentos faturados (t_conhtitulos); t_conhtitulos : esta tabela possui os dados dos CTRCs que ja foram faturados. Possui relacionamento com a tabela de CTRCs (t_ctrc) e com a tabela de títulos (t_titulos);

95 83 t_ocorrenciactrc : esta tabela possui os dados das entregas dos CTRCs, ou seja, armazena a data e hora(entre outros) da entrega dos CTRCs emitidos em todas as agências. Possui relacionamento com a tabela de CTRCs, com a tabela de empresas, com a tabela de motoristas (t_motorista) e ocorrências (t_ocorrencia); t_empresa : armazena dados das agências e filiais da empresa objeto de estudo; t_motorista : armazena os dados dos motoristas de todas as agencias das empresas, para que seja possível saber quem entregou determinado CTRC ao cliente da empresa. Possui relacionamento com a tabela de empresas e entregas dos CTRCs; t_ocorrencia : armazena todas as ocorrências possíveis para um determinado CTRC, ou seja, possui registros que determinam o status atual do CTRC como, por exemplo em viagem, em entrega ou entrega. O modelo proposto é resumido, porém possui todas as informações necessárias ao funcionamento do protótipo. 7.6 MÓDULO ADMINISTRATIVO Esta parte do protótipo visa prover operações consideradas básicas neste contexto sob os usuários (clientes). O módulo administrativo possui as seguintes funcionalidades: Inserir usuários; Pesquisar usuários; Alterar usuários; Excluir usuários; 12 Quando mencionado o termo empresa a nível físico do banco de dados, trata-se das agencias ou filiais que a empresa objeto de estudo possui.

96 84 Listar usuários; Log acesso por data; Log acesso por usuário; A função inserir usuários como a própria descrição sugere permite ao administrador da aplicação cadastrar novos usuários de acesso ou novos administradores. O que muda o tipo de usuário é a letra armazenada no campo usu_tipo da tabela de t_usuario, para usuários do tipo administrador da aplicação temos a letra A e para usuários do tipo cliente a letra U. No ato da autenticação este campo é verificado direcionando o usuário para a interface correspondente ao seu tipo. A tela do protótipo corresponde a esta função é apresentada abaixo. Figura 24: Tela de inserção de novos usuários Para a função de busca dos usuários temos a função pesquisar usuário, que após receber como parâmetro o CNPJ/CPF do cliente ou login do mesmo, ou ambos simultaneamente retorna como resultado os dados cadastrais do usuário.

97 85 A tela do protótipo correspondente a esta função é apresentada a seguir. Figura 25: Tela de pesquisa de usuários Na seqüência temos a função alterar usuários, que serve para alterar os dados cadastrados para os usuários. Esta função precisa de todos os parâmetros para efetuar a alteração, por se tratar de um protótipo e da quantidade de informações consideradas o administrador precisa pesquisar o cliente e depois preencher os campos do formulário de alteração com os mesmos dados que estavam nos outros campos caso não deseje alterar todos os dados. Na seqüência é apresentada a tela do protótipo correspondente a esta função.

98 86 Figura 26: Tela de alteração de usuários Continuando temos a função excluir usuários, que serve obviamente para a exclusão de usuários previamente cadastrados, porém pela opção de não perder informações de usuários cadastrados e acessos dos mesmos, ao efetuar a operação de exclusão o usuário não excluído fisicamente do banco de dados, ele tem apenas a letra do campo usu_status modificada de A (ativo) para I (inativo). Desta forma se o cliente interromper suas atividades com a empresa objeto de estudo e depois voltar não será necessário o recadastramento do mesmo, pois apenas precisamos atualizar o cadastro anterior reativando o usuário. A exclusão pode ser feita passando como parâmetro o CNPJ/CPF do usuário ou login ou ambos simultaneamente. Abaixo a tela responsável pela função de exclusão de usuários.

99 87 Figura 27: Tela de exclusão de usuários A seguir temos a função de listar usuários, que exibe os dados de todos os usuários cadastrados. Abaixo a tela do protótipo que lista os usuários.

100 88 Figura 28: Tela listar usuários Após a opção de listar todos os usuários temos a opção de visualizar os registros de acesso dos usuários por data na função log acesso p/ data passando como parâmetro a data referência para pesquisa. A figura abaixo demonstra a tela para digitação da data para pesquisa de acesso.

101 89 Figura 29: Pesquisa acessos por data A gravura a seguir apresenta o resultado da busca por data de acesso.

102 90 Figura 30: Resultado da busca de acesso por data A próxima e última função do módulo administrativo é a busca de acesso de usuários por usuário ou log acesso p/ usuário. A busca e a tela é similar a função de busca por data, por isso a seguir demonstra-se somente a tela resultante de uma busca por usuário.