PROJECTO DE LICENCIATURA - ipp.pt

PROJECTO DE LICENCIATURA

Sistema de transformação de documentos

Setembro de 2002

I N S T I T U T O S U P E R I O R D E E N G E N H A R I A

D O P O R T O

I N S T I T U T O S U P E R I O R D E E N G E N H A R I A

D O P O R T O

Sistema de transformação de documentos

Aluno

I970929 – Sérgio Fernando Bragança da Silva Matos

Orientador

Engº Alexandre Bragança

Sistema Transformação Documentos Agradecimentos

- I -

AGRADECIMENTOS

Para a elaboração de qualquer projecto, por menor que seja, é necessária a colaboração e a compreensão de várias pessoas que estão ligadas a nós no dia a dia. De seguida irei fazer uns pequenos agradecimentos às pessoas que estiveram sempre presentes, tanto na elaboração, como no decorrer de todos estes anos passados, no instituto.

Agradeço ao Engº Alexandre Bragança todo o apoio que me deu durante a elaboração deste trabalho e consequente guia.

Agradeço à empresa I2S – Informática, Sistemas e serviços SA todo o apoio que me deu na minha formação como profissional, o qual me ajudou a que tivesse conhecimentos para a elaboração do caso prático apresentado neste projecto.

Agradeço à minha família toda a compreensão e ajuda durante toda a minha vida académica, apoiando-me incondicionalmente em todas as minhas decisões.

Agradeço à minha amiga Isadora Soares que, embora não estivesse presente, me ajudou a validar uma parte do projecto.

Por fim, agradeço a todos os meus amigos que me acompanharam na minha vida académica e que me ajudaram a superar alguns dos problemas, que se foram apresentando.

A todos o meu obrigado....

Sistema Transformação Documentos Índice

- II -

INDICE

AGRADECIMENTOS .................................................................................................................................... I INDICE ..........................................................................................................................................................II ÍNDICE DE TABELAS ............................................................................................................................... IV INDICE DE FIGURAS .................................................................................................................................V 1.1.1.1. INTRODUÇÃO ..................................................................................................................................6

1.1. OBJECTIVOS .....................................................................................................................................7 1.2. ESTRUTURA DO RELATÓRIO...............................................................................................................8 1.3. FASES DO PROJECTO .........................................................................................................................9

2.2.2.2. ESTUDO...........................................................................................................................................11 2.1. SISTEMAS DE TRANSFORMAÇÃO DE DOCUMENTOS ............................................................................11

1.1.1. produto d2e ..........................................................................................................................11 1.1.1.1. Descrição do produto D2E ............................................................................................................ 12 1.1.1.2. Arquitectura................................................................................................................................... 13 1.1.1.3. Exemplos de aplicação do D2E ..................................................................................................... 15

1.1.2. BizTalk Server .....................................................................................................................17 1.1.2.1. Características............................................................................................................................... 19

2.2. XML – A LINGUAGEM ................................................................................................................21 1.1.3. documentos XML ................................................................................................................22 1.1.4. DEFINIÇão do tipo documento xml (dtd) ...........................................................................24

2.3. XML – PARSERS...........................................................................................................................26 1.1.5. PARSER SAX .....................................................................................................................27 1.1.6. DOM ....................................................................................................................................29

2.4. XML – TRANSFORMAÇÃO .........................................................................................................31 1.1.7. XSLT ...................................................................................................................................31

3333.... SGBDOC ..........................................................................................................................................38 3.1. CODOMO.....................................................................................................................................38 3.2. ARQUITECTURA CODOMO.........................................................................................................40 3.3. CONSOLA - LAB .............................................................................................................................41 3.4. DOCUMENTOS E TIPOS DE DOCUMENTOS.........................................................................................43

1.1.8. TIPO DE DOCUMEnto .......................................................................................................43 1.1.9. documento............................................................................................................................45 1.1.10. Tipos de objectos e metodos ................................................................................................46

4.4.4.4. TRANSFORMAÇÃO DOCUMENTOS ..........................................................................................49 4.1. DESCRIÇÃO ....................................................................................................................................49 4.2. ARQUITECTURA...............................................................................................................................51

1.1.11. processador CODOMO........................................................................................................51 1.1.12. processador XML (ou outro tipo) ........................................................................................54

4.3. DIFERENÇAS ENTRE SAX E PARSER CODOMO.....................................................................................56 5.5.5.5. CASO PRÁTICO..............................................................................................................................57

5.1. DESCRIÇÃO.....................................................................................................................................57 5.2. ARQUITECTURA ..............................................................................................................................58 5.3. PROGRAMA DE TESTES.....................................................................................................................60 5.4. MAPEAMENTO CODOMO – ESTRUTURA DA DLL ......................................................................61

Sistema Transformação Documentos Índice

- III -

5.5. EXEMPLO DA TRANSFORMAÇÃO.......................................................................................................65 6.6.6.6. CONCLUSÃO ..................................................................................................................................68 ANEXOS........................................................................................................................................................71 BIBLIOGRAFIA...........................................................................................................................................75 INDICE REMISSIVO...................................................................................................................................76

Sistema Transformação Documentos Índice Tabelas

- IV -

ÍNDICE DE TABELAS

TABELA 1- TABELA DE MAPEAMENTOS DOS TIPOS DE DOCUMENTOS ...................................................................61 TABELA 2 – TABELA DE MAPEAMENTOS DAS MACROS .........................................................................................62 TABELA 3 – TABELA DE MAPEAMENTOS DOS TIPOS DE DADOS ............................................................................62 TABELA 4 - TABELA DE MAPEAMENTOS DOS CAMPOS .........................................................................................62 TABELA 5 – TABELA DE MAPEAMENTOS DOS METODOS.......................................................................................62

Sistema Transformação Documentos Índice Figuras

- V -

INDICE DE FIGURAS

FIGURA 1- ARQUITECTURA D2E.......................................................................................................................13 FIGURA 2 – EXEMPLO DE APLICAÇÃO DO PROCESSADO D2E (WEB)..................................................................16 FIGURA 3- EXEMPLO DE APLICAÇÃO DO PROCESSADOR D2E (BASE DADOS)......................................................17 FIGURA 4- SEPARAÇÃO DA ANALISE E DO DESENVOLVIMENTO............................................................................21 FIGURA 5 - EXEMPLO DE UM DOCUMENTO XML...............................................................................................23 FIGURA 6 – EVENTOS DISPARADOS NA LEITURA DE UM DOCUMENTO XML .........................................................29 FIGURA 7- MODELO DOM – DOCUMENT OBJECT MODEL ................................................................................31 FIGURA 8- ARQUITECTURA DO FLUXO DE DOCUMENTO DO PROCESSADOR XSL .................................................33 FIGURA 9- EXEMPLO DA TRANSFORMAÇÃO COMO O PROCESSADOR XSL ............................................................34 FIGURA 10 – ARQUITECTURA CODOMO .........................................................................................................41 FIGURA 11- EXEMPLO DO ASPECTO DA CONSOLA CODOMO ...........................................................................42 FIGURA 12- INTERLIGAÇÃO ENTRE OS DOCUMENTOS E TIPOS DE DOCUMENTOS (GESTÃO DE VERSÕES) ...............46 FIGURA 13 – REPRESENTAÇÃO DOS TIPOS DE DADOS.........................................................................................48 FIGURA 14- EXEMPLO DE UM MÉTODO ESCRITO EM LPS...................................................................................48 FIGURA 15- CICLO DE VIDA DE UM DOCUMENTO NO SISTEMA DE TRANSFORMAÇÃO IDEALIZADO ........................50 FIGURA 16 – ARQUITECTURA DO PROCESSADOR CODOMO INTERAGINDO COM OS COMPONENTES ...................52 FIGURA 17- ARQUITECTURA DO PROCESSADOR TIPOS .......................................................................................55 FIGURA 18- VISÃO GLOBAL DO CASO PRÁTICO...................................................................................................58 FIGURA 19- MODELO APRESENTADO NO CASO PRATICO.....................................................................................59

Sistema Transformação Documentos Introdução

- 6 -

1.1.1.1. INTRODUÇÃO

Hoje em dia, as empresas estão presentes no mercado duma maneira muito diferente de alguns anos atrás e sem dúvida que, a Internet foi a maior responsável.

Para além dos motivos financeiros, as empresas começaram a sentir a necessidade de interligar as diferentes aplicações existentes, de comunicar com os parceiros via Internet. Para responder a todo este esquema, foi introduzido o conceito de sistemas de transformações de documentos. Estes, permitem a circulação da informação entre aplicações e plataformas distintas, permitindo assim que uma aplicação possa trocar dados com outras aplicações que necessitam desses dados.

A partir daqui e devido à grande evolução da era informática, surgiram vários sistemas de transformação de documentos, isto foi necessário, senão obrigatório, devido à grande quantidade de documentos que é necessário gerir e informatizar. Estes documentos primam pela sua representação na vida real em qualquer tipo de negócio.

Desde sempre, o uso de documentos tornou-se cada vez mais indispensável pelo facto de, ser necessário armazenar grandes quantidades de informação em formato electrónico. Esta informação, para ser considerada como tal, tem que ser legível, ou seja, tem que ter um determinado formato e tem que ser bem armazenada, bem tratada e/ou transformada.

Com o avanço dos sistemas informáticos surgiu a necessidade de criar documentos em formatos Standard, ou seja, documentos que tivesse um formato universal. Todas as aplicações poderiam transformar um documento num formato específico (conhecido da aplicação) para outro documento num formato universal (conhecido por todas as aplicações), tornando assim possível a movimentação de documentos entre aplicações distintas ou mesmo para migração de dados entre as aplicações.

Os sistemas de transformação de documentos são bastante vulgarizados e mesmo quando os utilizamos, de uma forma quase imperceptível, não tomamos consciência que o que esta por detrás da transformação é um longo processo de


- 7 -

análises e um conjunto de interacções entre os diversos componentes que só são perceptíveis quando se analisa a sua arquitectura.

Um exemplo disto é:

Quem é que nunca transformou documentos Word (Doc) num outro formato tipo Página da Internet (HTML)?

Quase todos nós já fizemos isso, mas não tomamos consciência que estamos a utilizar um sistema de transformação de documentos porque, de vez em quando, o arranque do processo é tão simples como fazer ‘Gravar como....’. Parece que não, mas isto é bastante importante para entender toda a arquitectura que foi idealizada para o sistema proposto e consequente caso prático, demonstrando que, a análise efectuada é possível e aceitável a nível prático.

Um formato que irá ser referenciado ao longo de todo este projecto é o formato CODOMO que pertence a um sistema da empresa I2S – Informática, Sistemas e Serviços, SA que denomina como SGBDOC (Sistema Gestor Baseado em Documentos).

A I2S – Informática, Sistemas e Serviços, SA utiliza o Sistema Gestor de Documentos (SGBDOC) nas suas aplicações que foi desenvolvido internamente para responder aos requisitos de manipulação de documentos, muito particulares existentes nas aplicações de gestão de seguros, desenvolvidas pela empresa. A vertente prática deste projecto envolve o desenvolvimento de um sistema de transformação de documentos SGBDOC noutros formatos. O resultado do sistema a desenvolver é o de, por exemplo, permitir facilmente a apresentação de dados de apólices de seguros em páginas HTML ou a troca de dados com outras aplicações através de XML.

O SGBDOC permite à empresa I2S representar a informação sobre seguros (por exemplo, uma apólice) e as regras de negócio de uma forma genérica.

1.1. OBJECTIVOS

No arranque do projecto foram definidos alguns objectivos que deveriam ser alcançados, para que o projecto tivesse sucesso. Eis os objectivos referidos:


- 8 -

• Estudo de alguns modelos de sistemas de transformação de documentos – Análise crítica aos modelos apresentados.

• Estudo do SGBDoc.

• Estudo do tema XML – Documentos e Processadores.

• Análise do caso prático que demonstra como a transformação de documentos pode ser bastante útil nos nossos dias.

• Implementação de um sistema de transformação de documentos SGBDOC* em formatos terceiros (por exemplo. XML).

1.2. ESTRUTURA DO RELATÓRIO

Para uma fácil compreensão do projecto foi elaborado este relatório num formato bastante simples, a sua estrutura prima pela separação dos vários temas focados, através de vários capítulos.

Os capítulos que constituem o relatório são os seguintes:

• Introdução

Breve introdução ao assunto que irá ser tratado com vista a podermos introduzir o leitor na área de interesse.

• Especificação dos objectivos propostos com a elaboração deste projecto.

Indicação do que o leitor pode esperar com a leitura do relatório e inserção nos vários assuntos focados.

• Estudo


- 9 -

Descrição de todo o estudo realizado, todas as pesquisas feitas para que pudéssemos analisar a melhor solução para o nosso sistema de transformação de documentos.

• SGBDOC

Descrição do SGBDOC, os documentos geridos por este sistema são os documentos que irão ser transformados.

• Transformação de documentos (Análise)

Descrição de toda a análise e fluxo de informação necessária para que o nosso sistema de transformação de documentos funcione.

• Caso Prático

Descrição do caso prático que foi desenvolvido, demonstrando que a análise elaborada foi bem delineada e o seu desenvolvimento possível, tendo em conta a linguagem.

• Conclusão

Termino o relatório com uma conclusão evidenciando os problemas encontrados, o que realmente funcionou e a minha opinião sobre o sistema desenvolvido.

1.3. FASES DO PROJECTO

Para a conclusão da análise efectuada sobre o tema, foi necessário percorrer um longo caminho, e para simplificar esse caminho dividiu-se o projecto por diversas fases, que conforme iriam ser alcançadas, reviam-se as fases por alcançar e alteravam-se a ordem das fases conforme as necessidades, se isso fosse necessário.

As fases percorridas foram as seguintes:


- 10 -

• Fase 1 – Estudo e compreensão dos documentos e tipos de documentos CODOMO, sua arquitectura.

• Fase 2 – Estudo dos diversos modelos de transformação de documentos existentes.

• Fase 3 – Estudo dos documentos XML.

• Fase 4 – Estudo da filosofia do parser SAX.

• Fase 5 – Estudo da API CODOMO.

• Fase 6 – Análise da arquitectura (ou modelo) a desenvolver para o processador CODOMO.

• Fase 7 – Implementação do caso prático na linguagem ‘C’.

Sistema Transformação Documentos Estudo

- 11 -

2.2.2.2. ESTUDO

Este capítulo tem uma grande importância para atingir os objectivos propostos, pois foi com o estudo que conseguimos obter o conhecimento de como se constrói os sistemas de transformação de documentos. Foi também com o estudo que conhecemos diversas arquitecturas e diversos modelos de concepção de sistemas deste tipo.

2.1. SISTEMAS DE TRANSFORMAÇÃO DE DOCUMENTOS

Foi realizado um estudo exaustivo sobre os vários sistemas de transformação de documentos existentes no mercado. Esta avaliação teve como principal objectivo verificar o comportamento das aplicações de transformação de documentos, assim como, as várias filosofias sobre as várias implementações sobre o tema.

Das várias arquitecturas encontradas, destaco duas, que me surpreendeu pela capacidade de organização, na maneira em que, existe exactamente definido os vários componentes que compõem os produtos. Estes dois produtos são: D2E da Xenos e o BIZTALK da Microsoft.

1.1.1. PRODUTO D2E

Cada vez mais o conceito de e-business tem vindo a ser introduzido nas grandes empresas, pois é a área que trata da aplicação que fica mais próxima do cliente. Isto, para o assunto apresentado neste relatório tem bastante importância, pois os documentos são nitidamente a representação do negócio onde os clientes revêem o papel em formato eletrónico.

A filosofia utilizada neste projecto e que irá ser descrita, é uma filosofia idêntica a este produto. A única diferença é que, e a meu ver muito bem, o produto que esta em desenvolvimento (caso prático) esta muito dependente do SGBDOC e este produto permite aceita qualquer formato. Com isto conseguimos


- 12 -

idealizar um produto que irá certamente satisfazer os nossos objectivos, porem, deixamos sempre a porta aberta para novas áreas. Isto é conseguido através da idealização de um sistema bastante configurável.

1.1.1.1. Descrição do produto D2E

O produto D2E é uma solução, no âmbito dos sistemas de transformações de dados e documentos de aplicações existentes, em novos formatos. Esta aplicação gera ‘e-conteudo’ para abastecer aplicações de gestão de informação, processos de impressão e aplicações e-business.

A arquitectura desta solução informática é uma arquitectura simples, pois é baseado em diversos componentes, o que torna uma aplicação bastante configurável. Isto permite que, quer os utilizadores, quer os programadores tenham o poder, se quiserem “alterar” a aplicação, de modo a satisfazerem as suas necessidades. As aplicações podem variar desde uma simples transformação de um único documento até aplicações inteligentes que utilizam regras de negócios.

Os formatos suportados para transformação são : AFP, Metacode, XES, LineMode, PostScript, PDF, TIFF, Tamplate Merger, HTML e XML.

Depois da analise que acabei de descrever, as vantagens que eu considero importante referir, são as seguintes:

• Transforma documentos que se encontra num formato de aplicação em formato de negócio, através de definições de regras.

• Fornece documentos que estão preparados para serem utilizados em aplicações de e-business.

• Disponibiliza documentos aos clientes que são personalizados.

• Conversão de documentos para serem impressos em diversas plataformas.


- 13 -

1.1.1.2. Arquitectura

A arquitectura, como não podia deixar de ser, é simples e é constituída por três grandes partes: Documentos de entrada, Processador dos documentos e por fim os documentos de output (e-content).

Os documentos de entrada, como mostra a figura, são:

• Legacy data (dados do negócio que são o resultado que algumas aplicações criam e que servem como input para o processador)

• Document Printstreams (CSF, DOC1, CompuSet,Papyrus) – documentos no formato de impressão.

A figura seguinte mostra a arquitectura do D2E.

Figura 1- Arquitectura D2E

O processador, como é natural, é o ponto central do estudo. Afinal de contas é o objectivo do nosso estudo saber como se pode montar um processador aceitável e robusto.


- 14 -

O processador é constituído por vários parser que transformam os dados de entrada em informação que o processador D2E entende. Os vários parser existentes que estou a falar são os seguintes:

• Data Parser (Parser de dados)– Transforma os dados em que os documentos de origem são os “Legacy data” num formato em que fica em memória e que é conhecido por representar documentos XML – árvores DOM (Document Object Model).

• Metacode Parser (Parser de metas-dado) – Transforma os dados em que os documentos de origem são os Meta-dado numa representação interna da aplicação D2E (Xenos Display List).

• AFP Parser (Parser do AFP) – Transforma os dados em que os documentos de origem são os IBM AFP numa representação interna da aplicação D2E (Xenos Display List).

• PCL Parser (Parser do HP PCL4 e PCL5) – Transforma os dados em que os documentos de origem são os HP PCL4 e PCL5 numa representação interna da aplicação D2E (Xenos Display List).

• TIFF Parser (Parser de imagens TIFF) – Transforma os dados em que os documentos de origem são as imagens TIFF numa representação interna da aplicação D2E (Xenos Display List).

Como já devem ter reparado, os parsers aqui têm uma função de transformar o que é desconhecido numa representação que é conhecida para a aplicação, isto permite que, para a aplicação aceitar um novo formato só seja necessário implementar um parser que conheça esse formato. Isto torna, a meu ver, uma aplicação muito mais genérica e fácil de transformar tendo em conta as necessidades do cliente.

Depois existe uma área no processador que é o “Document Control”, ou seja, lugar onde os documentos irão ser analisados e controlados.

Os documentos são controlados a dois níveis:


- 15 -

• Nível básico – Constrói o formato de output sem recorrer ao negocio. O parser está preparado para produzir o formato e irá ser esse formato que irá ser produzido.

• Nível inteligente – permite a introdução de regras de negócio que em conjunto com os parser define qual o formato de output a ser produzido.

Por fim existe, ainda mais uma camada no processador que eles dão o nome de “e-content Generators”, que é uma camada que, à semelhança da camada parser, que transformam os documentos de entrada num formato que a aplicação conhece, este transforma os documentos no formato interno da aplicação para o formato destino (e-content). Para isso existe um conjunto de parser, um para cada formato destino.

Este formato destino poderá ser ligado com várias aplicações usando os documentos universais (XML, HTML, ...).

A arquitectura apresentada é uma arquitectura que se assemelha muito ás arquitecturas dos sistemas de transformação de documentos, basicamente existe um processador no qual entra um documento num determinado processador e sai outro documento noutro formato. A diferença passa pelo modo como o processador funciona, uns mais complexos ou menos complexos, mas o objectivo é sempre o mesmo – Transformação de documentos num formato para outro formato.

A filosofia utilizada, que antes de transformar um documento no formato externo, primeiro transforma o documento num formato interno é utilizada também na “aplicação BizTalk Server”.

1.1.1.3. Exemplos de aplicação do D2E

Posso dar alguns exemplos que permitem demonstrar até que ponto se pode utilizar a aplicações D2E numa perspectiva de negócio.

Os exemplos que eu estudei, dos quais destaco e que dá uma visão clara sobre as potencialidades do D2E, são os seguintes:


- 16 -

• Movimentação de uma factura a cobrar via WEB

Este exemplo, consiste em extrair informação, via WEB, de uma factura que se encontra em formato electrónico. Estes formatos podem ser dos diversos tipos que o processador D2E suporte.

Depois de extrair a informação, o documento é impresso num formato que o processador D2E entende, depois transforma o conteúdo (e-conteudo) nos formatos XML, HTML, PDF ou mesmo WML (Formato para telemóvel).

Figura 2 – Exemplo de aplicação do processado D2E (WEB)

• Extracção de informação de uma base de dados.

Neste exemplo, a filosofia é muito semelhante ao exemplo anterior, a única coisa que muda fundamentalmente é o modo como é extraída a informação. Neste exemplo a informação é extraída de uma base de dados, depois é transformada num formato de documento que o processador D2E entende e de seguida o processador transforma os dados e os documentos num formato e-conteudo que compreende os seguintes formatos: XML, HTML, PDF; WML.

DOCUMENTO

IMPRIMIDO (FACTURA)

D2E

PDF

WML

HTML

XML


- 17 -

Figura 3- Exemplo de aplicação do processador D2E (Base Dados)

Estes exemplos permitem verificar, como é importante, o uso do sistema, pois permite a transformação on-line via WEB de documentos(exemplo 1.), onde se pode efectuar o pagamento de uma factura, depois, transformar o documento num outro documento através do sistema D2E e de seguida é possível interligar diferentes aplicações que consomem o formato disponibilizado.

1.1.2. BIZTALK SERVER

A Internet permitiu o surgimento de novas tecnologias, que disponibiliza um conjunto de serviços a cada indivíduo e empresas, para fazer negócios com uma maior rapidez e eficácia. Com isto, também surge a ideia de interligar diferentes organizações.

A língua que esta a nascer, como sendo a língua da Internet, é o XML. Apesar disto, nem todas as aplicações entendem o XML ou não é muito fácil reestruturar uma aplicação para a começar a entender. O BizTalk surgiu para suprimir a necessidade de transformar os dados que, uma determinada aplicação cria, em formatos que outras aplicações já entendam.

D2E

PDF

WML

HTML

XML

DADOS

DOCUMENTO


- 18 -

Através de ferramentas visuais, o BizTalk oferece a possibilidade de fazer o mapeamento de documentos distintos e ainda colocar algumas regras de negócio no formato a produzir.

O BizTalk foi estruturado para entender o XML, mas consegue entender qualquer tipo de formato, desde que este, seja ensinado ao produto.

O BizTalk é uma arquitectura que disponibiliza um certo número de ferramentas para efectuar transformações de documentos, via Web, com vista a incluir as regras de negócio no documento transformado. A arquitectura BizTalk permite que se defina o percurso pelo qual um documento tem de percorrer sobre o ponto de vista de controle de fluxo e o formato destino permite que se possam fazer transacções entre diferentes aplicações.

A ferramenta BizTalk apresenta:

• Ferramentas de desenvolvimento

Utiliza ferramentas para modificar / desenvolver os documentos XML e os documentos de negócio (regras).

• Suporta a troca dos dados

Através de documentos XML, EDI, formatos personalizados e ficheiros de texto é possível efectuar a troca de informação entre as diversas aplicações.

• Segurança e Robustez

Utiliza uma estrutura baseada em chave publica, assinaturas digitais e encriptação.

• Adaptabilidade com diversas aplicações comerciais

È um sistema que pode comunicar com diversas aplicações comerciais e financeiras.


- 19 -

1.1.2.1. Características

As características que existem no BizTalk são totalmente direccionadas para os documentos e para a transformação destes.

As características do BizTalk, que os distingue dos demais servidores de transformação de documentos, são as seguintes:

• Troca de documentos B2B

Para existir a troca de informação entre diferentes aplicações terá de existir um protocolo bem definido com o objectivo de ambas as aplicações poderem entender entre si.

O processo de envio de informação pode ser feita de um modo automático, este é feito de um modo inteligente. A aplicação pode calcular para quem vai enviar um documento através de cálculos entre variáveis que se encontram nos programas. Isto como é claro, necessita de uma boa definição das regras de negócio.

A entrega dos documentos é feita de um modo garantido porque a aplicação reenvia os documentos, caso dê algum erro, até que este seja entregue.

• Administração do processo

O BizTalk fornece um conjunto de ferramentas que permitem administrar toda a informação que circula, tais como:

⇒ Management Desk

Através de uma ferramenta gráfica são definidas as ligações comercias e são estabelecidas regras de negócio para que as duas aplicações (ou mais) possam comunicar entre si. O BizTalk também se encarrega da codificação.

⇒ BizTalk Editor


- 20 -

Representam a informação de documentos de negócio em documentos XML.

⇒ BizTalk Mapper

Permite definir um conjunto de padrões que irão ser mapeados para elementos que existam no formato de documento de entrada e não existam no formato de documento de output (semelhante ao XSL). Alias, a ferramenta XSL, é utilizada neste servidor precisamente para fazer exactamente o que acabou de ser referido.

⇒ Análise de documentos

Os documentos são analisados à medida que passam pelo BizTalk, permitindo assim, a correcção de possíveis erros.

Para se conseguir trabalhar com este servidor, é necessário atender para alguns requisitos que têm que ser levados em conta, conseguindo assim, aproveitar todas as potencialidades que ele oferece.

Esses requisitos são os seguintes:

• Separação da análise do processo e implementação

Deve-se definir a analise e a implementação do processo de uma forma separada, ou seja, a análise não pode ser dependente por inteiro da sua implementação e vice-versa.

A figura seguinte mostra como o BizTalk esta organizado e repare-se na existência de uma divisão clara entre a análise e o desenvolvimento. O processo é definido do lado esquerdo e depois ligado à representação visual da implementação de software do lado direito (no exemplo abaixo são dois componentes COM).


- 21 -

Figura 4- Separação da analise e do desenvolvimento

• Processo dinâmico

O processo deve ter a capacidade de se alterar dinamicamente, com base em informações que são introduzidas ao processo e em interacções que só podem ser conhecidas no desenvolver do processo.

• Integração com todos os tipos

O processo deve ter a capacidade de interagir com qualquer parte da sua implementação. Não se deve obrigar ninguém, que seja o receptor da nossa conversa, que utilize uma plataforma, aplicação, esquema de negócios, etc.

2.2. XML – A LINGUAGEM

Como o principal objectivo deste trabalho não era saber tudo sobre XML, foi feita uma abordagem superficial, estudando todos os conceitos inerentes ao XML. O que quero dizer é que os pormenores sobre o tema não foram descritos


- 22 -

neste relatório, mas sim a explicação de todos os conceitos sobre o tema e necessários para uma boa compreensão no tema central – Transformação de documentos XML.

XML (eXtensible Markup Language) é uma meta-linguagem universal que serve para representar dados, documentos ou acções de uma forma simples, estruturada e bastante compreensível. As acções mencionadas podem ser consideradas como um script, um bocado de código que é executado. Sendo assim, podemos considerar que o XML é uma linguagem e como qualquer linguagem tem um conjunto de regras e uma gramática que define a validade de um documento XML.

O modelo Markup que pertence a sigla XML significa que são utilizadas marcas que tem um determinado significado, permitindo identificar os dados ou documentos associados, isto torna esta linguagem simples e bastante compreensível para o ser humano.

1.1.3. DOCUMENTOS XML

Um documento XML tem uma apresentação muito semelhante a um documento HTML. Estas semelhanças são bastantes visíveis, devido ao facto de ambas utilizares Tags ou Marcas para descrever a sua estrutura hierárquica ou mesmo para definir os elementos que constituem o documento.


- 23 -

Figura 5 - Exemplo de um documento XML

Como se pode observar na figura, um documento XML é constituído basicamente por TAGS (elementos) que definem a informação a descrever e os atributos que servem para identificar um determinado TAG ou dar informação adicional ao TAG. Estas são as características principais de um documento XML e que foram postas em prática no caso prático. No exemplo apresentado, o TAG ou elemento é, por exemplo, o aluno e o atributo o num. Para além destes elementos existem outros que não têm importância para este projecto, facto pelo qual, não serão descritos.

É importante referir que um documento pode ser considerado como sendo um documento bem formado ou mal formado. Um documento bem formado é um documento que segue todas as regras sintácticas que define um documento XML. Se um documento não é um documento bem formado não pode ser denominado como sendo um documento XML.

As regras sintácticas, que um documento é obrigado a seguir para ser considerado documento XML, são:

<documento> <alunos> <aluno num=”970929”> <nome> Sérgio Matos </nome> <curso> Informática </curso> </aluno> <aluno num=”970344”> <nome> Luis Marques </nome> <curso> Informática </curso> </aluno> </alunos> <professores> <professor sigla=”ALEX”> <nome> Alexandre Bragança </nome> <disciplinas> <disciplina> SOII </disciplina> <disciplina> SDIST </disciplina> </disciplinas> </professor> </professores> </documento>


- 24 -

• Todo o documento deve ter um elemento raiz que contém todos os elementos restantes.

• Os elementos podem, como é normal, incluir outros elementos, mas o que não pode ser quebrado é o facto de se desrespeitar o alinhamento dos elementos. Um exemplo desta infracção é o seguinte: <alunos> <aluno> Luis </alunos> <aluno>

Existem vários pormenores nos documentos XML que não importa falar, mas não poderia deixar de falar numa característica prática dos documentos que se revelou bastante importante para o desenvolvimento do caso prático, que são as secções CDATA. Estas secções são utilizadas para manter a formatação do documento e para incluir diversos caracteres que não podem ser utilizados no XML porque os caracteres já estão reservados para a própria linguagem (por exemplo, ‘<’).

1.1.4. DEFINIÇÃO DO TIPO DOCUMENTO XML (DTD)

Os DTD são utilizados para validar documentos XML. Com os DTD podemos construir os chamados vocabulários, podendo assim obrigar a que um determinado documento XML contenha uma determinada hierarquia. Os vocabulários são muito utilizados no XML, pois permitem estabelecer um conjunto de regras, regras essas que facilitam a comunicação entre vários programas. Os DTD utilizados no XML derivam dos DTD utilizados no SGML. Utilizam uma gramática própria que permite definir a estrutura e a sintaxe de um documento XML. Estas regras designam-se de restrições, e garantem que um documento de XML é válido (quando associado ao respectivo DTD). Os DTD não são representados através de XML bem – formado, contudo, as declarações utilizadas nos DTD são bastante semelhantes às instruções utilizadas no XML: utilizam os < e > para delimitar as declarações.

Os DTD, ao serem utilizados com um parser que efectua validação (Validating Parser), permitem verificar se os elementos obrigatórios estão presentes no documento, verificar se os elementos respeitam a hierarquia definida no DTD, para verificar os atributos e se os valores que se encontram nos atributos são válidos.


- 25 -

A definição de um DTD associado a um documento XML, deve ser bem pensado e criado antes da criação do próprio documento XML, permitindo assim, que a probabilidade de se gerar um ficheiro XML válido para as necessidades que se pretende, seja de praticamente 100%.

Os elementos de um DTD, como já foi referido, são delimitados pelos símbolos < e >. A declaração de um elemento utiliza a seguinte sintaxe: <! keyword parâmetro 1 parâmetro 2 ... parâmetro n>. O termo utilizado keyword corresponde a um dos elementos do DTD.

Existem quatro tipos de elementos básicos que podem ser utilizados no local do termo keyword:

• ELEMENT

Especifica o nome de um elemento e os vários valores que são possíveis para este elemento (filhos e valores).

• ATTLIST

Especifica uma lista de atributos associada a um determinado elemento e também especificar valores por defeito para o atributo.

• ENTITY

Utilizado para definir referências a caracteres ou entidades.

• NOTATION

Utilizado para declarar conteúdo externos (não estou a falar de elementos do XML. por exemplo, para declarar uma imagem binária).

Dos referenciados, no nível de importância para a criação de um DTD são, como já devem ter reparado, os dois primeiros (ELEMENT e ATTLIST), pois eles são os principais elementos utilizados num documento XML.

Os DTD permitem a construção de um vasto vocabulário, permitindo assim a construção de determinadas regras que podem ser consideradas restrições a


- 26 -

que os documentos de XML são obrigados a obedecer, contudo, apesar de todas as vantagens que já são realçadas pela definição dos DTD, os DTD apresentam também um grande número de desvantagens, ou limitações:

• A sintaxe do DTD é diferente da do XML

Apesar das semelhanças existentes, a sintaxe dos DTDs não utiliza XML bem formado. Isto obriga a que os parsers sejam obrigados a construir dois tipos de validação: um para o XML e outro para os DTD.

• Não são extensíveis:

Uma vez que só podemos associar um DTD a um documento, então todas as definições utilizadas têm de ser declaradas no DTD, o que torna a manutenção dos DTD complexa (quando utilizada por uma equipa com vários elementos).

• Suporte limitado dos namespaces

Os DTD não suportam facilmente a introdução dos namespaces.

• Fraca restrição de tipos

DTD apenas trabalham com um tipo de dados – as STRINGS. Apesar de podermos impor algumas restrições (através do ID, IDREFS, lista de valores, ...), estas restrições são limitadas, pois não permitem, por exemplo, que possamos obrigar a um atributo que seja do tipo número inteiro.

2.3. XML – PARSERS

Existem vários PARSERS, que permitem a manipulação de informação, existente num documento XML. Dos vários PARSERS existentes, destaco dois, que são os mais utilizados devido às suas excelentes performances e facilidade de utilização. São eles, o PARSER SAX (Simple Api for XML) e o PARSER DOM


- 27 -

(Document Object Model). Entenda-se manipulação de informação como leitura e escrita dum documento XML.

Pode-se questionar qual o melhor parser, mas a resposta irá ser sempre a mesma: depende das necessidades. O que estou a tentar dizer é que, ambos os parser são bons, mas bastante diferentes no modo como funcionam e como ocupam os recursos físicos da máquina.

È importante referir que, este estudo foi bastante importante para a identificação do modelo a ter como referencia na idealização do nosso sistema. Usamos como modelo o parser SAX e durante a leitura do relatório irá ser explicado o porquê.

De seguida irá ser feita uma análise e descrição da arquitectura utilizada por estes dois tipos de parser e as vantagens e desvantagens de cada um.

1.1.5. PARSER SAX

SAX é uma API útil para fazer o parser de leitura de documentos XML e esta disponível em qualquer linguagem de programação. SAX processa a informação do nosso documento XML como uma sequência de eventos, ou seja, enquanto faz a leitura do documento XML e ele, dependendo do tipo de elemento que encontra, vai disparando o evento correspondente. Estes eventos estão pré definidos e não podem ser alterados.

A capacidade, conforme vai lendo o XML, de tratar elemento cada elemento torna o parser mais rápido porque não necessita de armazenar em local algum a informação, mas como é obvio, torna o parser como sendo um parser “não rollback”, ou seja, tratado um elemento do documento XML, já não é possível voltar a tratá-lo na mesma execução.

Para usar a API SAX é necessário ter em atenção a alguns aspectos que são obrigados a ser tratados. Os aspectos mais naturais são os seguintes:

• Criação de um modelo personalizado de objectos que represente a área de negocio.


- 28 -

• Criação de uma classe que capture os eventos SAX (gerados pelo parser SAX conforme ele obtém o documento XML) e que crie adequadamente o modelo de objectos. Estes eventos, como já foi referido, são sempre os mesmos, o que torna o parser um bocado rudimentar na medida em que fica confuso a maneira como é feito o desenvolvimento.

Como já foi dito, existe uma série de eventos que são disparados quando parser SAX esta a ler o documento XML.

Eis os eventos que o SAX dispara:

• StartDocument – Evento que é disparado no inicio do documento.

• StartElement – Evento que é disparado quando se encontra um TAG novo (ou elemento). Este evento também trata dos atributos do elemento.

• Characters – Evento que é disparado para ser devolvido o valor do elemento.

• EndDocument – Evento que é disparado para assinalar o fim da leitura do documento XML.

Na minha opinião, montar um sistema que se baseie apenas nestes eventos é muito complicado e confuso. Porque senão vejamos, a quantidade de elementos existente num documento XML e que para todos, existe apenas um evento, dependendo das necessidades (StartElement ou Characters). Isto faz com que o tratamento, ao nível de concepção de sistemas, fique bastante complicado. Por isso, para o nosso sistema utilizou-se a filosofia de disparo de eventos dependendo o tipo de informação que o nosso parser estava a executar, o que levou à criação de muitos eventos, o que basicamente corresponde, um para cada elemento no documento XML.

De seguida irá ser apresentada uma figura ilustrando o tratamento que um parser SAX faz.


- 29 -

Figura 6 – Eventos disparados na leitura de um documento XML

O exemplo apresentado mostra a sequência dos eventos que estão a ser disparados, à medida que o parser SAX vai ler o documento XML. Aqui é bastante obvio verificar a observação que eu dei, na medida em que fazer o rollback no tratamento da informação de um documento XML não é possível.

É importante frisar que, este estudo foi bastante importante para a identificação da metodologia a utilizar no caso pratico.

1.1.6. DOM

Como o objectivo do estudo não era o DOOM, apenas vou apresentá-lo como medida de comparação ao escolhido (SAX) e mostrar o porquê da nossa eliminação, à partida, deste modelo.

Document Object Model é um modelo e um interface de linguagem comum que poderia permitir a programas e scripts, dinamicamente acederem e actualizarem o conteúdo, estrutura e estilo dos documentos XML. O documento pode ser posteriormente processado e os resultados deste processamento pode voltar a ser introduzido no documento inicial, ou seja, o DOM descreve, como

DOCUMENTO XML <doc> <Aluno num=”i970929”> Sérgio Matos </Aluno> </doc> SEQUENCIA DE

EVENTOS DISPARADOS StartDocument StartElement (<Doc>) StartElement(<Aluno>) Characters (Sérgio Matos) EndDocument

SAX


- 30 -

dizem alguns analisadores de XML, retornam a informação contida num documento XML. Os elementos do documento XML são descritos como nodos de uma árvore que pode ser analisada e reavaliada por um programador.

DOM trata a informação armazenada no nosso documento XML como um modelo de objectos hierárquicos. DOM cria uma árvore de nós (baseado na estrutura e na informação do documento XML); O acesso à informação do documento pode ser através de interacções com essa árvore. DOM preserva a sequência dos elementos lidos a partir dos documentos XML, porque ele trata tudo como se fosse um documento. Isto justifica seu nome: modelo de objecto do documento.

Além de ser mais lento, para o caso dos sistemas de transformação de documentos não é necessário fazer o rollback (reparem que neste modelo, como armazena tudo em memória através de uma arvore, já é possível fazer o rollback, ou seja, depois de ler o documento XML ele fica armazenado em memória e o DOM disponibiliza um conjunto de APIs que permitem navegar na árvore); por isso era uma perda de memória, estar a guardar tudo, se cada elemento só vais ser tratado uma única vez. O nosso objectivo é ler uma informação e de seguida tratar logo essa informação, dado isto, verificou-se logo que o modelo SAX era melhor do que o DOM.

De seguida irá ser mostrado numa figura, o modo como o DOOM representa a informação contida num documento XML, em memória


- 31 -

Figura 7- Modelo DOM – Document Object Model

Depois do parser DOM carregar o documento XML para memória, o documento fica com o formato que esta representada na figura no lado direito. O parser vai lendo o documento, começando na raiz até chegar à folha de cada elemento e vai armazenando-o de uma forma hierárquica.

2.4. XML – TRANSFORMAÇÃO

Outra característica e vantagem que o XML tem, são as ferramentas que existem dedicadas à linguagem e foi o conseguir fazer a transformação de documentos XML noutro tipo de documentos do mesmo formato (XML) ou mesmo de outros formatos.

1.1.7. XSLT

O XSL (Extensible Stylesheets Language) é uma linguagem que pode ser considerada como integrante do sistema de transformação de documentos XML, onde o documento de INPUT é um, ou mais, documentos XML e o output será um documento do tipo XML ou de outro tipo.

DOM

DOCUMENTO XML <doc> <Aluno num=”i970929”>

Sérgio Matos

</Aluno> </doc>

DOM DO

ALUNOSérgi

ALUNO...

ALUNO


- 32 -

Uma aplicação XML utiliza o vocabulário (ou linguagem) XSL para a criação de stylesheets que permitem fazer a formatação de documentos XML.

O conceito XSL é muito parecido como o conceito CSS (documentos HTML), mas com a vantagem de permitir fazer a supressão, a alteração de ordem dos elementos do documento e criar novos dados e inseri-los no documento final.

O padrão XSLT permite especificar transformações de documentos XML, em novos documentos que utilizarão outros DTD. Isso possibilita, por exemplo, a transformação de um documento XML num outro documento XML, que responde por outra tipificação DTD (Por exemplo: permite que modelos de dados diferentes compartilhem da mesma árvore de dados contida no documento XML, a partir de XSLTs próprios).

O modo de funcionamento do processador XSL é simples e obedece aos seguintes requisitos:

Documento XSL é um documento XML bem formado e válido segundo o vocabulário XSL.

Conceito de template – permite transformar os dados de um documento que tem um determinado formato noutro, de outro formato.

O documento XSL descreve todas as transformações a efectuar sobre o documento original

Depois de apreender alguns conceitos que o processador XSL requere, passamos à fase de explicação de como funciona todo este processo de transformação de documentos XML num outro tipo de documentos ou mesmo num outro documento XML.

A figura seguinte mostra o fluxo de informação de documentos que é necessário e que interagem com o processador XSL


- 33 -

Figura 8- Arquitectura do fluxo de documento do processador XSL

Como se vê pela figura anterior, o processador XSL tem como INPUT dois documentos: um documento XML origem e um documento XSL (Conjunto de regras no formato de um documento XML com as transformações a afectar no documento XML original). O resultado que irá ser apresentado será outro documento (XML ou outro tipo).

Para exemplificar isto, apresento de seguida um exemplo que dá para compreender a melhor forma e os elementos necessários para se utilizar o processador XSL.

DOCUMENTO XML

DOCUMENTO XSL

PROCESSADORXSL

DOCUMENTO DESTINO


- 34 -

Figura 9- Exemplo da transformação como o processador XSL

Como é possível reparar no ficheiro XSL apresentado na figura anterior, a filosofia da utilização do XSL é baseada na utilização do termo template, que não é mais do que, um conjunto de regras que são aplicadas a cada elemento transformando-o. È possível especificar algumas regras que só são aplicadas dependendo de determinadas condições.

Cada template é aplicado a todos os elementos do documento XML que estão em concordância com o padrão definido no atributo match do elemento xsl:template.

DOCUMENTO XML <?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="stylecontacts.xsl" ?> <CONTACT_INFO> <CONTACT> <NAME>John Doe</NAME> <PHONE>555-5319</PHONE> </CONTACT> <CONTACT relation="family">

DOCUMENTO XSL <?xml version="1.0"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"> <xsl:template> <HTML> <head><title>Contacts names</title> <style type="text/css"> div.names { font-size: 3em; color: gray} </style> </head>

<BODY>


- 35 -

Cada documento XSL pode albergar vários template e cada um vai ser aplicado dependendo do contexto.

Existe uma linguagem de definição de padrões (XPATH) que permitem que, se efectuem transformações em alguns elementos. Quando se aplica um template, inerente a isto esta um conjunto de padrões que define os nós ao qual o padrão irá ser aplicado. O mais usual é especificar os nomes dos elementos ao qual o padrão irá ser executado.

Depois de ter uma visão global de como funciona o processado XSL, vou fazer uma pequena descrição de todos os elementos que podem ser utilizados num documento XSL para poder descrever as características e potencialidades do processador.

Os elementos que são utilizados para definir os template que foram referidos anteriormente e das condições que fazem com que as transformação só se efectuem em alguns casos são os seguintes:

• <xsl:template> este elemento define um template que faz as transformações nos elementos. Existe um conjunto de regras que aplicadas a um elemento produzem o resultado que é a transformação do elemento origem.

• <xsl:apply-templates> define o conjunto de elementos que irão ser processados e invoca os template que processam esses elementos.

• <xsl:call-template> Esta instrução é utilizada para invocar um template com um atributo que é o nome.

• <xsl:stylesheet> É o elemento pai de todos os elementos de uma stylesheet. Esta instrução é utilizada nos módulos principais e secundários.

• <xsl:include> Este elemento é um elemento de topo (portanto, filho do elemento stylesheet) e serve para incluir o conteúdo de uma folha de estilo noutra folha de estilo. As definições incluídas no módulo principal possuem as mesmas prioridades do que as definições declaradas nesse módulo (ou seja, é feita uma cópia de todo o conteúdo do módulo secundário para o módulo primário).


- 36 -

• <xsl:import> Este elemento também serve para incluir uma stylesheet noutra (portanto, é semelhante ao elemento anterior). Contudo, neste caso, os elementos definidos no módulo importado possuem uma prioridade menor do que os elementos definidos no módulo principal (o que é importante na resolução de eventuais conflitos). Cada módulo importado possui, como já foi dito, uma prioridade que segue as seguintes regras:

A prioridade do módulo importado é sempre menor do que a do módulo que importa;

Se um módulo importa vários módulos secundários, então o que é importado em primeiro lugar tem menor prioridade do que o segundo, e assim por diante.

• <xsl:value -of> Esta instrução escreve uma string no documento final. É uma das instruções mais utilizadas para esse efeito

• <xsl:element> É utilizado para criar um nó no documento final.

• <xsl:attribute> Cria um atributo num elemento e dá-lhe um valor.

• <xsl:comment> Escreve um comentário no documento resultado.

• <xsl:processing-instruction> Escreve uma instrução para processamento no documento final.

• <xsl:text> Efectua o processamento de texto para o documento final.

• <xsl:variable> Declara variáveis locais ou globais e atribui um valor constante. Um aspecto importante no XSLT reside no facto de, ao contrário do que acontece na maioria das linguagens, não ser possível alterar o valor de uma variável (funcionam como se fossem constantes). Daí que a utilização de variáveis em XSLT se resuma a uma destas situações:

⇒ Evitar a repetição desnecessária de expressões;


- 37 -

⇒ Armazenamento de valores que podem mudar.

⇒ Armazenamento de uma árvore de nós.

• <xsl:param> Utilizado para descrever um parâmetro que deve ser passado quando se aplica um determinado template

• <xsl:with-param> Esta instrução é utilizada para fornecer valores aos parâmetros existentes nos corpos dos template.

• <xsl:copy> Utilizado para copiar o nó actual para o documento destino.

• <xsl:copy-of> Semelhante ao anterior, com a particularidade de copiar eventuais nós descendentes que o nó actual (do documento origem) possua.

• <xsl:if> Esta instrução agrupa um conjunto de instruções que só serão executadas caso a condição indicada seja verdadeira. Esta instrução é análoga às instruções if encontradas na maioria das linguagens de programação.

• <xsl:choose> Esta instrução fornece um conjunto de opções, das quais só uma é executada (funcionamento semelhante a estruturas if-then-else-if).

• <xsl:for-each> Selecciona um conjunto de nós utilizando uma expressão XPath e efectua o processo especificado no corpo do template para cada nó obtido através da expressão.

• <xsl:falback> Utilizada para definir o processamento que deve ocorrer ao ser encontrado um erro no nó.

Sistema Transformação Documentos SGBDoc

- 38 -

3.3.3.3. SGBDOC

O SGBDoc define-se como sendo um Sistema Gestor de Base de Documentos e tem como principais características a gestão e a representação de documentos. Permite também fazer o tratamento da informação contida num documento, assim como, o armazenamento de informação e definição de regras da informação.

A representação da informação nos documentos é feita através de campos e o tratamento é feito através dos métodos. O armazenamento da informação é feito através de repositórios.

Os documentos que são geridos pelo SGBDoc são objectos que permitem fazer a representação de informação das aplicações informáticas. Estes têm uma estrutura bem definida. Existe um novo conceito que são os tipos de documento que permitem especificar a estrutura e funcionamento de um documento. Cada documento tem um tipo associado.

Os repositórios que servem para armazenar toda a informação referente aos documentos e tipos de documentos utilizam um sistema de versões, onde é permitido registar várias versões dos tipos de documentos e dos documentos. Esta funcionalidade permite fazer o “rollback” da informação caso necessário.

Por último, é necessário introduzir a este capitulo um novo tema, que é o CODOMO. O CODOMO esta intimamente ligado ao SGBDOC, este se assume como sendo o componente núcleo do CODOMO.

3.1. CODOMO

“CODOMO (COmponent DOcument MOdel) é uma proposta de solução tecnológica para suporte ao desenvolvimento de soluções informáticas (tipicamente Three-Tier) baseadas no conceito de documento CODOMO.”

Alexandre Bragança in Manual do CODOMO


- 39 -

Um documento CODOMO é um objecto que é constituído por vários objectos complexos que, como já foi referido na definição de documentos, assume a estrutura de um documento sobre o qual as pessoas trabalham na vida real e o comportamento é onde se definem as regras de negocio, cálculos, scripts. A estrutura do documento CODOMO é totalmente armazenada num outro documento que é designado como sendo o Tipo do Documento.

O CODOMO tem diversas funcionalidades onde se permite utilizar e gerir os documentos. Estas funcionalidades são as seguintes:

• Criação de tipos de documentos

Utilização de uma linguagem própria de definição de tipos de documentos (LDTD) que permite efectuar a declaração dos dados e descrição do comportamento do objecto através de métodos.

• Manipulação dos documentos

Utilização de uma linguagem que manipula documentos (LMD).

• Repositório de documentos

Utilização de um repositório onde se permite guardar os documentos, assim como, os tipos dos documentos. Após a informação estar armazenada é possível gerir as versões dos documentos, assim como, dos tipos dos documentos.

Os tipos de dados utilizados na estrutura do documento podem ser do tipo de dados simples como um conjunto de dados (Colecções).

O documento pode ser manuseado e mantido através da utilização dos repositórios do CODOMO, de base de dados relacionais e através de programas que usam as APIs do CODOMO. Estas APIs são disponibilidades usando interfaces COM e C.


- 40 -

3.2. ARQUITECTURA CODOMO

Como já foi referido, um documento, é um objectivo que basicamente utiliza as funcionalidades de uma classe, ou seja, é um objecto que tem um identidade própria, que contem um conjunto de dados que são armazenados através de campos e um conjunto de métodos que permite especificar o comportamento que irá ser descrito no documento. Os métodos, como já foi referido, são desenvolvidos utilizando a linguagem para seguros (LPS), esta é caracterizada como sendo uma linguagem procedimental. O CODOMO contem um compilador LPS e um interface gráfico que serve como ambiente para o desenvolvimento dos métodos.

Todos a informação pode ser armazenada em três lugares distintos:

• Disco

Num formato binário, num formato próprio do CODOMO. Este formato é suportado em sistemas operativos Windows e AS400.

• Memória

Os documentos são criados em memória e a informação introduzida através de programas usando as APIs.

• Base de dados relacional

É requeridos o DSN (Formato de base de dados configurado) e o utilizador e password (se necessário). Assim sendo, a informação irá ser armazenada sobre a forma de uma base de dados relacional normalíssima.


- 41 -

Figura 10 – Arquitectura CODOMO

Nesta imagem é descrita toda a arquitectura COMODO. Como já foi referenciada, ela baseia-se num núcleo bem definido (SGBDoc) que permite fazer a gestão dos documentos e tipos de documentos. Os providers que são importantes quando se usa as APIs de acesso à informação armazenada nos repositórios. As bases de dados que são outro formato em que pode ser disponibilizada a informação.

3.3. CONSOLA - LAB

No decorrer do desenvolvimento do caso prático, foi necessário efectuar alguns testes sobre os documentos CODOMO, na medida em que, foi necessário utilizar uma aplicação (“Laboratório”) que o permitisse fazer. Como foi uma ajuda preciosa para o desenvolvimento do meu projecto, penso que merece fazer uma referência.

A consola “Laboratório” é uma ferramenta gráfica que usa as APIs de acesso a documentos, tipo de documentos e repositórios para efectuar as operações mais comuns de uma maneira simples e agradável para o utilizador.


- 42 -

Figura 11- Exemplo do aspecto da Consola CODOMO

Como é se pode observar na figura acima, a consola permite visualizar vários repositórios, os tipos de documentos e os documentos. Entre estes, como se pode ver, pode-se ver também a estrutura de versões.

A consola permite fazer diversas operações, porem irei apenas destacar as operações que tem maior interesse:

• Acede a diversos tipos de repositórios (Relacionais, disco ou memória)

• Efectua as operações sobre o tipo de documento (Cria, altera e consulta)

• Efectua as operações sobre o documento (Cria, altera e consulta)

• Inquéritos a repositórios que são do tipo relacional


- 43 -

• Exportar Documentos e/ou Tipo Documentos

• Importar Documentos e/ou Tipo Documentos

3.4. DOCUMENTOS E TIPOS DE DOCUMENTOS

Os dados existentes na base de dados CODOMO e mantidos pelo SGBDoc são representados em Tipo de documentos e nas suas instancias que são os Documentos.

1.1.8. TIPO DE DOCUMENTO

Um tipo de documento, objecto que contém toda a estrutura de um documento é constituído por:

• HEADER

Define o cabeçalho do tipo de documento.

• MACROS

Define bocados de código na linguagem de métodos (LPS) que podem ser utilizados no tipo de documento.

Uma macro por definição é constituída por um id – identificador da macro, por um numero que pode ser facultativo que serve para identificar um índice de um array de macros e o texto correspondente à macro.

Exemplo:

<id>’(‘<num>’)’ AS <macro body>


- 44 -

• TYPES

Define as estruturas de dados que o utilizador pode definir.

A definição de estrutura é constituída por um ID – identificador do tipo e da definição dos vários campos. Cada campo pode ser definido por um ID – identificador do campo e um tipo fixo que pode ser do tipo simples ou do tipo vector (Conjunto de dados).

Exemplo:

STRUCT <id> BEGIN <id> AS (<simple type> | <vector type>) END

• DATA

Definição dos campos do documento.

A definição de DATA é constituida por vários campos, cada campo é definido por um id – identificador do campo e um tipo – tipo de dados do campo que pode ser do tipo fixo ou do tipo col – colecção. Cada campo pode estar ainda associado um atributo que pode ter os seguintes valores:

⇒ Persist – Quando se grava o documento, o valor também é gravado.

⇒ Virtual – Quando se grava o documento o valor não é gravado, o valor só existe quando esta em memória.

⇒ Const – Indica que o campo é uma constante e permanece constante em todos os documentos. É necessário especificar qual o valor para ele.

Exemplo:

DATA BEGIN <id> AS (<fixed type> | <col type>)‘,’ PERSIST | VIRTUAL | CONST


- 45 -

END

• METHODS

Definição dos métodos na linguagem LPS.

Os métodos são definidos como sendo constituídos por um id – Identificador do método e um texto que define o método.

Exemplo:

METHODS BEGIN <id> BEGIN <texto método> END END

1.1.9. DOCUMENTO

Um documento é, nada mais nada menos que, a instância de um tipo de documento a que esta associada, ou seja, é a atribuição de valores à estrutura de um tipo de documento. Ele esta eternamente ligado a um documento. A gestão de versões dos tipos de documentos e dos documentos é muito importante, para compreender isso é melhor atentar para a figura seguinte:


- 46 -

Figura 12- Interligação entre os documentos e tipos de documentos (gestão de versões)

Como mostra a figura anterior, a ligação existe sempre, como é obvio, uma ligação entre os documentos e os tipos de documentos. O que se passa é que para cada documento é obrigatório ter um tipo de documento associado, pois é ele quem especifica a estrutura do documento.

Podemos verificar com a figura que, existem várias versões para cada documento e para um dos tipos de documentos. Esta gestão é feita de modo independente. O que se sucede é que, num documento uma versão pode estar associada a uma versão do tipo de documento e outra versão do documento estar associado a outra versão do tipo de documento.

1.1.10. TIPOS DE OBJECTOS E METODOS

Os tipos de objectos que o CODOMO permite que se utilizem para representar os valores estão divididos em dois tipos que são os escalares e os compostos.

TIPO DOCUMENTO 1

VERSÃO 3

VERSÃO 2

VERSÃO 1

TIPO DOCUMENTO 2

VERSÃO 2

VERSÃO 1

DOCUMENTO 1

VERSÃO 2

VERSÃO 1

DOCUMENTO 2

VERSÃO 2

VERSÃO 1

DOCUMENTO 2

VERSÃO 2

VERSÃO 1


- 47 -

De seguida irei apresentar os tipos de dados correspondentes a cada um dos tipos.

Os escalares compreendem os seguintes tipos:

• Numérico

• Caractere n

• Lógico (sim / não)

• Data

• String

• Binário

Os compostos compreendem os seguintes tipos:

• Estrutura (Registos)

• “Array”

• Colecção

• Outros definidos a partir de tipos compostos e/ou escalares(com restrições)


- 48 -

Figura 13 – Representação dos tipos de dados

Os métodos que se podem definir nos tipos de documentos, utilizam a linguagem LPS (Linguagem para Seguros) e permite as seguintes funcionalidades:

• Função especifica (Somatório, Produto, Acesso Universal a dados)

• Funções externas do utilizador

• Macros

• Atribuições

• Estruturas de controlo

• Comentários

Figura 14- Exemplo de um método escrito em LPS

Sistema Transformação Documentos Transformação Documentos

- 49 -

4.4.4.4. TRANSFORMAÇÃO DOCUMENTOS

Todo o projecto foi elaborado com vista á concepção de um sistema de transformação de documentos.

Com o estudo dos vários sistemas de documentos existentes, fomos tomando consciência do que era realmente necessário para que fosse possível uma concepção de um sistema capaz de superar todas as necessidades que possam vir a ser necessárias.

Por isso, optou-se por criar um sistema que fosse bastante genérico para que possa albergar todo o tipo de documentos (Formatos), sem que fosse necessário alterar alguma especificação no processador.

Tudo o que foi elaborado e idealizado, ou seja, as analises ao sistema posto em pratica irá ser descrito neste capítulo.

4.1. DESCRIÇÃO

O sistema de transformação de documentos idealizado teve como principal objectivo ser um sistema genérico e robusto.

Dito de uma forma muito generalizada e simples, podemos descrever este sistema como sendo um sistema que permite fazer a transformação de documentos do formato CODOMO noutros formatos e nestes outros formatos no formato CODOMO. Este é o ciclo de transformações de documentos que foi esperado atingir.

Na próxima figura pretendemos mostrar o ciclo de vida de um documento nos processadores (ou motores) idealizados.


- 50 -

Figura 15- Ciclo de vida de um documento no sistema de transformação idealizado

Este sistema foi atacado em duas frentes, a primeira era conseguir definir um processador que permitisse fazer a transformação do formato conhecido CODOMO noutro formato desconhecido e a segunda parte que era a definição de uma estrutura sólida que pudesse ser utilizada para fazer a transformação de um documento no formato desconhecido no formato CODOMO. Esta foi delegada para ser idealizada / realizada em segundo plano porque com o estudo do parser SAX e como o principal objectivo era idealizar / realizar a transformação de documentos CODOMO em XML e de XML em CODOMO, esta tarefa estaria basicamente idealizada. Como já devem reparar, utilizamos o parser SAX como forma de transformação de um documento XML num outro documento CODOMO.

Este ciclo de vida poderá ser bastante importante, tendo em conta uma necessidade que era, como transformar um documento num formato noutro documento em que o formato fosse alterado devido as necessidades do mercado ou incompatibilidade de versões. Ou seja, se existir um documento num determinado formato e mais tarde esse documento for alterado para outro formato, como se poderia compatibilizar o formato antigo com o formato novo, sem qualquer perda de informação?

CODOMO

TIPOS DE

DOCUMENTOS E

DOCUMENTOS

PROCESSADORCODOMO

PARA FORMATO DESTINO

FORMATO DESTINO

TIPO DOCUMENTO

E/OU DOCUMENTO

PROCESSADORFORMATO DESTINO

PARA CODOMO


- 51 -

Com este sistema, é possível transformar o documento CODOMO num outro formato (por exemplo, o XML) e de seguida transformar este formato XML no formato CODOMO. A escolha do formato destino é feita de uma forma configurada, o que permite que não se necessite de alterar o núcleo do processo (Processador).

4.2. ARQUITECTURA

Depois de uma descrição, que permite ao leitor ter uma visão global sobre o sistema, é necessário focar as nossas baterias no sistema de transformação que foi idealizado. Como é natural o sistema é composto por vários componentes (ou elementos) que irão ser descritos na forma como interagem entre eles e qual o significado de cada um, permitindo que o sistema funcione.

1.1.11. PROCESSADOR CODOMO

A arquitectura idealizada foi uma arquitectura simples, em que basicamente existe um processador(ou motor) genérico, ou seja, um processador que transforma o documento CODOMO num outro qualquer tipo. Isto como é obvio, sem alterar o processador.

Toda a arquitectura teve que ser idealizada tendo em vista a linguagem procedimental C e por isso surgiram algumas dificuldades, devido ao facto de, termos a necessidade de utilizar um sistema dinâmico.

Defino um sistema dinâmico como sendo um sistema que, dependendo da informação que passa no fluxo de dados, comporta-se de maneira diferente. Para que isto aconteça, o sistema tem que estar preparado e tem que ser analisado de uma forma global, em que todas as situações possam ser previstas para que não exista nenhuma falha.

O processador utiliza uma filosofia de disparo de eventos, ou seja, conforme o tipo de informação que recebe da base de dados, vai disparando um conjunto de eventos que, são configurados conforme o formato a disponibilizar, recebem essa informação e escreve em memória ou disco o formato destino


- 52 -

dessa mesma informação. Mas este tema irá ser focado e explicado convenientemente no capitulo 5-Caso prático.

A próxima figura mostra qual a interacção do processador com os outros componentes que constituem o sistema.

Figura 16 – Arquitectura do Processador CODOMO interagindo com os componentes

Como mostra a figura, o funcionamento do sistema é bastante simples. De seguida irei explicar como os vários componentes interagem entre si e qual o significado deles como componente.

Os vários componentes existentes no sistema, que estão referenciados no diagrama e dos quais eu foco, devido à sua extrema importância, são os seguintes:

• DOCUMENTO CODOMO – é constituído pela base de dados (repositório) que contem a informação no formato CODOMO e que com as APIs disponibilizadas em ‘C’, fornece ao processador a

PROCESSADOR CODOMO

DOCUMENTO CODOMO

CODOMO

APIS (LEITURA /

ESCRITA DA INFORMAÇÃO

CODOMO)

PARSER

TIPO DOCUMENT

O

PARSER DOCUMENT

O

DOCUMENTO DESTINO

(MEMÓRIA) TIPO DOCUMENTO E/OU

DOCUMENTO

DRIVER - DLL -

( FORMATO DESTINO )

DOCUMENTO DESTINO (DISCO)

TIPO DOCUMENTO E/OU DOCUMENTO


- 53 -

informação num formato de texto, ou seja, a informação num formato que o processador consegue processar.

• DRIVER DLL – este componente é fornecido ao processador e é onde vai explicado o formato de destino que vai ser produzido (eventos a serem disparados). Este, esta está no formato de uma DLL.

• PROCESSADOR CODOMO – Faz inquéritos à base de dados através das APIs, recebe o formato de documento de destino e cria um documento em memória ( De modo a ser utilizado por outros programas) ou disco (registo físico do documento).

• PARSER DE TIPOS DE DOCUMENTO – Entende o formato CODOMO através das APIs de acesso aos tipos de documentos.

• PARSER DE DOCUMENTOS – Entende o formato CODOMO através das APIs de acesso aos documentos.

• DOCUMENTO DESTINO – O documento de destino irá ser o resultado do processamento da informação no processador CODOMO. Este pode ser um documento físico ou um documento em memória.

Agora que já expliquei quais os componentes e o seu significado, vou explicar a forma como os componentes interagem entre si, ou seja, como funcionam em conjunto.

Os componentes apresentados interagem da seguinte maneira:

O processador CODOMO faz inquéritos à base de dados através das APIs. Existem dois parser que se encarregam de inquirir a base de dados e provocar o disparo de eventos que se encontram no documento DLL. Quem utiliza o processador, fica encarregue da escolha do tipo de parser a executar ( Tipo de documento ou documento) e de fornecer o formato destino que se encontra no documento DLL. O processador irá criar o documento destino no formato especificado no documento DLL e irá ser disponibilizado, como já foi dito, em memória ou disco. Foi utilizado o conceito de documento em memória, que não é nada mais nada menos, que a representação de um documento num apontador


- 54 -

para uma STRING. Isto permite ao utilizador a forma de manipular a informação que o parser gera.

Como já foi dito, a linguagem utilizada foi o C e isto complicou o sistema. Porque vejamos, como o sistema é dinâmico, quando o processador, através das APIS vai buscar a informação é necessário disparar um conjunto de eventos que são pré definidos, tendo em conta o tipo do documento (Tipos ou Documentos). Como é obvio, o disparo de um evento (ou método) torna-se mais simples nas linguagens orientadas a objectos, em que se poderia definir uma classe que ficava responsável por conter os métodos que iriam ser disparados. Mas como, por razões lógicas, o processador deveria ser elaborado em “C” (porque as APIS estão na linguagem C e isto também se poderá considerar como uma API.), o aparecimento da DLL tem o mesmo efeito que a classe e é a forma que foi encontrada para o disparo de métodos através do seu nome.

1.1.12. PROCESSADOR XML (OU OUTRO TIPO)

O processador XML ou de outro tipo de formato, ficou por desenvolver, mas foi feita uma análise superficial, pois como o objectivo inicial era a transformação em documentos XML, utilizaríamos um parser para ler e de seguida montávamos um sistema que iria ser o nosso “escritor” no CODOMO.

Tomando como principio a programação dinâmica (definição do caminho a percorrer em tempo de execução e não em tempo de escrita do programa), elaboramos o seguinte diagrama que irá explicar como seria o nosso escritor de CODOMO, tendo como base, um documento XML.


- 55 -

Figura 17- Arquitectura do processador Tipos

Conforme mostra a figura anterior, o processamento de documentos em formato desconhecido e/ou documentos no formato XML para o formato CODOMO é muito semelhante ao processador CODOMO. O processador TIPOS recebe a informação do documento que irá processar (Se for XML utiliza o parser SAX, se não for, terá que ser desenvolvido um parser) e invoca os eventos que são responsáveis por criar os tipos de documentos na base de dados CODOMO.

Para uma maior compreensão da figura, irá ser descrita todos os elementos que se encontram representados na figura. São eles:

• APIs CODOMO – responsável por aceder a base de dados CODOMO e criar os documentos e/ou tipo de documentos.

• DLL (EVENTOS) – contem todos os métodos que irão ser invocados pelo processador, que ira invocar as APIs de acesso ao CODOMO, para criar os documentos e/ou tipo de documentos.

• PROCESSADOR TIPO – irá ser responsável por receber um documento e de seguida invocar o parser correcto para fazer a invocação dos eventos configurados na DLL.

PROCESSADORTIPOS

DOCUMENTO XML

APIS CODOMO

SAX

BD CODOMO

DLL(EVENTOS)

OUTROS TIPOS DE

DOCUMENTOS

PARSER


- 56 -

• DOCUMENTO XML – representa um documento XML válido e bem formado, que pode ser utilizado conjuntamente com um documento DTD.

• OUTROS TIPOS DOCUMENTOS – representa um documento no formato desconhecido, sobre o qual o processamento irá obrigar a criar um novo tipo de parser ou a utilização de algum parser já existente.

4.3. DIFERENÇAS ENTRE SAX E PARSER CODOMO

O parser idealizado, que irá obter informação da base de dados CODOMO, através de APIs, é muito semelhante à filosofia adoptada pelo parser SAX.

A diferença significativa é que como o parser SAX tem apenas 5 métodos, sobre os quais consegue fazer o parser ao documento XML, o parser CODOMO tem um método para cada tipo de informação existente no CODOMO. Isto permite uma melhor estruturação e uma programação mais legível e simplificada. De resto é em tudo semelhante, pois ambos lêem a informação e invocam métodos para tratar essa informação.

Sistema Transformação Documentos Caso Prático

- 57 -

5.5.5.5. CASO PRÁTICO

O caso prático que irei apresentar é um protótipo que foi desenvolvido pela minha pessoa, durante o segundo semestre do quinto ano.

Ele consiste em apresentar e demonstrar que a análise que foi idealizada pode muito bem ser posta em prática e consigui provar que a analise foi bem idealizada.

É importante referir que, não foi possível implementar todo o caso prático, pois, além de não ter tempo suficiente, pois é muito trabalhoso, não estou a trabalhar nele a 100%. Este trabalho foi desenvolvido nas horas vagas e fora do local de trabalho pois, apesar de trabalhar na empresa onde o SGBDoc é deveras utilizado, eu não trabalho com esse sistema. Por causa disto, tive que aprender o sistema desde inicio.

Foram realizadas diversas sessões de esclarecimentos de dúvidas com alguns colegas de trabalho, que estão a trabalhar na área. Isto foi fundamental para que pudesse ter sempre presentes os vários conceitos que, tive que obter para que, conseguisse obter o sucesso que o trabalho teve.

5.1. DESCRIÇÃO

O caso prático consistiu em desenvolver umas APIs na linguagem ‘C’, que utilizam as APIs CODOMO para aceder à informação armazenada no formato CODOMO, conseguindo fazer um parser completo da informação sobre o tipo de documento.

O caso teve como objectivo principal demonstrar as funcionalidades de um parser dinâmico e foi nesta área que se concentrou todo o esforço. O parser que falo e que foi desenvolvido foi o parser de tipos de documentos. O parser de documentos irá levar a mesma estrutura, razão pela qual, não foi necessário desenvolver para provar a sua viabilidade.


- 58 -

Na figura seguinte irá ser mostrada uma visão global sobre o caso pratico.

Figura 18- Visão global do caso prático

Basicamente o programa TesteEngineTDocReader irá invocar a API do CODOMO para obter a informação sobre o repositório que esta a tratar e recebe sob o formato de uma DLL todos os eventos a invocar para a criação do documento destino. Este documento irá ser físico (ficheiro escolhido para a criação do mesmo) ou em memória(que irá ser devolvido para o programa principal um apontador com a informação toda adquirida)

5.2. ARQUITECTURA

Depois de ter uma visão global do sistema que ajudou a obter o conhecimento do que era pretendido para o caso pratico, passamos a explicar os pormenores, do que foi desenvolvido.

A arquitectura de todo o projecto teve, como principais características, ser um projecto que não fosse destinado simplesmente a documentos XML, mas tentou-se sempre fazer uma arquitectura que abrisse a novos horizontes para o processamento de qualquer tipo de documento.

APIS CODOMO DOCUMENTO

DESTINO (TIPO DOCUMENTO)

(DISCO)

TESTE

ENGINE TDOCREADER

DLL

( FORMATO DESTINO )


- 59 -

De seguida irá ser apresentada uma figura ilustrando o fluxo de informação nos componentes existentes no caso pratico.

Figura 19- Modelo apresentado no caso pratico

Como apresentado na figura, existem 2 módulos principais: EngineTDocReader e ComodoParserTDocReader e cada um tem diferentes objectivos. Os objectivos de cada um são os seguintes:

• EngineTDocReader, fica responsável por criar um parser do tipo TDocReader, arranque do parser e eliminação do TDocReader.

• CodomoParserTDocReader, fica responsável por ler a base de dados CODOMO através das APIs de acesso, carregar a DLL que contem os eventos a ser invocados, carregar os apontadores para as funções a serem invocadas e posteriormente é responsável por criar o ficheiro destino(Memória ou disco). Se for memória, devolve para o EngineTDocReader o apontador contendo a informação.

Todo o processo é invocado através de um modulo teste (testeEngineTDocReader) que irá fazer as seguintes tarefas:

PROCESSADOR CODOMO

TESTE ENGINE

TDOCREADER

ENGINE TDOCREADER

CODOMO PARSER

TDOCREADER

DRIVER

API CODOMO

TDOC


- 60 -

• Criação de um TDocReader

• Invoca o parser

• Eliminação do TDocReader

5.3. PROGRAMA DE TESTES

O programa de testes, que foi elaborado, serviu para testar as funcionalidades desenvolvidas referentes às APIS do processador CODOMO.

De seguida, irei apresentar algum código, explicando algumas instruções que são bastante importante.

´ void main() { char *localRep="C:\\Program Files\\I2S\\CODOMO\\Reps\\Disco\\"; char *dllRep="repdsk.dll"; char *user=""; char *pwd=""; int dtv=1; int tid=1; int rid=1; int iTDoc=0; char *tDocMem = NULL; lps_SWORD msg; msg = createTDocReader(localRep,dllRep,user,pwd,dtv,tid,rid,&iTDoc); if (msg != CDM_ERRO) { tDocMem = parse(iTDoc,"c:\\temp\\prjdll\\cdm2xml.dll",TYPE_OUTPUT_DISK,"c:\\temp\cdm2xml.xml",msg); } msg = deleteTDocReader(iTDoc); }

As instruções que considero que devo explicar, devido à sua importância, são as seguintes:

• createTDocReader – Cria um Leitor de Tipos de documentos, em que se dá a localização do repositório, o identificador do tipo de


- 61 -

documento a processar e é nos devolvido, um identificador interno para o tipo de documento e a mensagem para controlar os erros.

• Parse – irá provocar o arranque do parser, recebe o identificador do tipo de documento a processar, a localização do driver(dll), se é para escrever no disco /ou memória, nome do ficheiro,caso seja em disco e por fim a mensagem para controlo de erros. È devolvido o buffer em memória contendo o documento destino.

• deleteTDocReader – irá eliminar tudo o que esta em memória referente ao tipo de documento que processou.

5.4. MAPEAMENTO CODOMO – ESTRUTURA DA DLL

Como já foi referido, existe uma DLL que contem os métodos que irão produzir o ficheiro destino e para obter a estrutura desta dll foi necessário fazer, um mapeamento de todos os elementos que iriam ser produzidos e encontrar na API CODOMO, uma referência para cada um deles. No fim, ficamos com a estrutura da DLL CODOMO.

De seguida irei apresentar uma tabela que serve de exemplo para a compreensão do que se fala. A tabela esta dividida por tipo de elementos que podem ser tratados num tipo de documento.

CODOMO (API) DLL CDM_DOCT_GETPROP DOCT_PROP_NAME DOCT_PROP_UTID (UTID)

WRTINITTDOC(NOME, UTID)

WRTENDTDOC Tabela 1- Tabela de mapeamentos dos tipos de documentos

CODOMO (API) DLL CDM_DOCT_GETNUMBEROFMACROS CDM_DOCT_LISTMACROS

WRTLISTMACROS (NOME, NUMERO DE MACROS)

CDM_DOCT_GETMACRODESCRIPTION WRTMACRO(ID,Nº PARMS, TEXTO) WRTENDMACRO


- 62 -

WRTENDLISTMACROS Tabela 2 – Tabela de mapeamentos das macros

CODOMO (API) DLL CDM_DOCT_GETNUMBEROFSTRUCTS WRTTYPES CDM_DOCT_GETNUMBEROFSTRUCTS WRTLISTSTRUCTS (NÚMERO

DE ESTRUTURAS )

CDM_DOCT_GETSTRUCTDESCRIPTION CDM_DOCT_GETSTRUCTNUMBEROFFIELDS

WRTSTRUCT(ID, NUM FIELDS)

CDM_DOCT_GETSTRUCTFIELDDESCRIPTION WRTSTRUCTFIELD(ID, TIPO, TAM)

WRTENDSTRUCTFIELD WRTENDSTRUCT WRTENDLISTSTRUCT WRTENDTYPES

Tabela 3 – Tabela de mapeamentos dos tipos de dados

CODOMO (API) DLL CDM_DOCT_GETNUMBEROFFIELDS WRTDATA CDM_DOCT_GETNUMBEROFFIELDS WRTLISTFIELDS(NUM FIELDS) CDM_DOCT_GETFIELDPROP FIELD_PROP_TYPE (LPS_WORD) FIELD_PROP_NAME (LPS_LPSTR) FIELD_PROP_PERSIST (LPS_BYTE) FIELD_PROP_LEN (LPS_DWORD) FIELD_PROP_N_DIMS (LPS_BYTE) CDM_DOCT_GETCONSTVALUE

WRTFIELD(ID,TIPO,PERSIST,LEN,DIM, CONSTVALUE)

WRTENDFIELD WRTENDLISTFIELDS WRTENDDATA

Tabela 4 - Tabela de mapeamentos dos campos

CODOMO (API) DLL CDM_DOCT_GETNUMBEROFMETHODS WRTLISTMETHODS(NUM FIELDS) CDM_DOCT_LISTMETHODS CDM_DOCT_GETMETHODDESCRIPTION

WRTMETHOD(NUM,NAME,TEXT)

WRTENDMETHOD WRTENDLISTMETHODS

Tabela 5 – Tabela de mapeamentos dos metodos


- 63 -

Este foi o estudo de mapeamentos que foi idealizado e posto em prática. Este estudo deu origem à estrutura da DLL (Conjunto de eventos que irão ser invocados para a criação do ficheiro destino).

A estrutura que obrigatoriamente terá de ter a DLL é a seguinte:

• DllExport char* getBuffer(void)

Devolve um buffer com o conteúdo do formato destino. Esta variável tem que ser preenchida de alguma forma pelos métodos que implementam a DLL.

• DllExport void init(int typeOut)

Método invocado no inicio do documento

• DllExport void iniTrfOut()

Método invocado antes de começar a produzir o documento

• DllExport void fimTrfOut()

Método invocado depois de produzir o documento.

• DllExport void wrtInitTDoc(char *TDocName, int tid)

• DllExport void wrtEndTDoc()

• DllExport void wrtListMacros(char *name, int nMacros)

• DllExport void wrtMacro(char *name, int nParms, char *texto)

• DllExport void wrtEndMacro()

• DllExport void wrtEndListMacros()


- 64 -

• DllExport void wrtTypes()

• DllExport void wrtListStructs(int nStructs)

• DllExport void wrtListStructFields(char *name, int nFields)

• DllExport void wrtStructField(char *name, int tipo, long len, int n_dims, int dims)

• DllExport void wrtEndStructField()

• DllExport void wrtEndListStructFields()

• DllExport void wrtEndListStructs()

• DllExport void wrtEndTypes()

• DllExport void wrtData()

• DllExport void wrtListFields(int nFields)

• DllExport void wrtField(char *name, int tipo, long len, int n_dims, int dims, char *valor)

• DllExport void wrtEndField()

• DllExport void wrtEndListFields()

• DllExport void wrtEndData()

• DllExport void wrtListMethods(int nMethods)

• DllExport void wrtMethod(int num ,char *name, char *texto)


- 65 -

• DllExport void wrtEndMethod(void)

• DllExport void wrtEndListMethods(void)

5.5. EXEMPLO DA TRANSFORMAÇÃO

De seguida, irá ser apresentado, um exemplo que dá para perceber melhor a transformação de documentos elaborado, neste caso prático.

A figura seguinte irá mostrar dois documentos: um documento representado no formato CODOMO, que servirá de entrada para o processador e o outro documento XML, que é o resultado que o processador gera. Este documento apresentado é um documento que foi gerado quando se faziam alguns testes de controlo de desenvolvimento.

EXEMPLO DE UM DOCUMENTO CODOMO // Isto é um exemplo… // …de como podemos introduzir comentários num script DOCUMENT TYPE “O nome do tipo de documento” BEGIN // Seccção de tipos TYPES BEGIN STRUCT info BEGIN Name as char(30) Age as num BthDate as date Gender as char END // Termina aqui a definição desta estrutura/tipo END // Termina aqui a secção de tipos // Continuamos com a definição de dados, i.e., os campos do documento DATA BEGIN AllPersons as coll of info // Temos uma colecção de pessoas

- 66 -

APerson as info // Temos uma pessoa END // E finalmente os métodos que fazem toda a diferença… METHODS BEGIN // Este método permite calcular a idade de uma pessoa… CalcAge BEGIN // O código seguinte é LPS. Ver a documentação da linguagem LPS... // Começamos por criar uma nova pessoa na colecção… addnew(AllPersons) // Vamos dar um nome à pessoa actual(AllPersons).name=”John Doe” // Vamos dar um sexo à pessoa actual(Allpersons).gender=’M’ // vamos dar uma data de nascimento à pessoa actual(Allpersons).bthdate=CTODP(“1999-10-14”, “CCYY-MM-DD”) // Vamos calcular a sua idade… actual(Allpersons).age=YEAR(DATE())-YEAR(actual(Allpersons).bthdate) END END END // Terminamos aqui a definição do tipo de documento. EXEMPLO DA REPRESENTAÇÃO DO DOCUMENTO CODOMO NO FORMATO XML

<?xml version="1.0" encoding="UTF-8" ?> -  - <DOCTYPE name="EXPANDIDO" tid="1">

- <TYPES> - <STRUCTS nStructs="1">

- <STRUCTFIELDS name="INFO" nFields="4"> <STRUCTFIELD name="NAME" tipo="1" len="0" n_dims="0" dims="0" /> <STRUCTFIELD name="AGE" tipo="4" len="0" n_dims="0" dims="0" /> <STRUCTFIELD name="BTHDATE" tipo="3" len="" n_dims="0" dims="0" /> <STRUCTFIELD name="GENDER" tipo="1" len="0" n_dims="0" dims="0" />

</STRUCTFIELDS> </STRUCTS>

</TYPES> - <DATA>

- <FIELDS nFields="2"> <FIELD name="ALLPERSONS" tipo="10003" len="1" nDims="0"

dims="0">(null)</FIELD> <FIELD name="APERSON" tipo="5001" len="1" nDims="0"

dims="0">(null)</FIELD> </FIELDS>

</DATA> - <METHODS nMetodos="1">

- <METHOD num="1" name="CALCAGE"> - <![CDATA[


- 67 -

// Comecamos por criar uma nova pessoa na coleccao

addnew(AllPersons)

// Vamos dar um nome a pessoa

actual(AllPersons).name="John Doe"

// Vamos dar um sexo a pessoa

actual(Allpersons).gender="M"

// vamos dar uma data de nascimento a pessoa

actual(Allpersons).bthdate=CTODP("1999-10-14", "CCYY-MM-DD")

// Vamos calcular a sua idade

actual(Allpersons).age=YEAR(DATE())-YEAR(actual(Allpersons).bthdate)

]]> </METHOD>

</METHODS> </DOCTYPE>

Sistema Transformação Documentos Conclusão

- 68 -

6.6.6.6. CONCLUSÃO

È importante referir que todo o trabalho que foi realizado irá ter continuidade na empresa onde trabalho e irá ser utilizado para compatibilizar versões diferentes do formato CODOMO, isto é, cria-se um documento num formato destino e depois altera-se o processador de tipos para estar actualizado com a nova versão do documento, criando os documentos no CODOMO já no formato novo.

A análise crítica que faço a este trabalho considero boa e prende-se pelo facto de ter conseguido satisfazer os objectivos inicialmente propostos, isto é, a construção de um modelo de sistemas de transformações de documentos para o CODOMO. Porém, durante a elaboração deste trabalho levantaram-se alguns problemas que foram sendo solucionados com maior ou menor rapidez.

Os problemas que encontrei e que eu particularmente considero que atrasaram o projecto foram os seguintes:

• Problemas em adoptar um modelo na linguagem C que permitisse que se utilizasse a programação dinâmica em que tudo fosse o mais autômato possível.

• Problemas com os ficheiros XML gerados que impossibilitavam a consulta no browser de certos elementos existentes no CODOMO.

Estes foram, os problemas que me deram mais trabalho, mas existiram outros que foram sendo solucionados como tempo e que não vale a pena serem descritos. O que interessa é que todos os problemas foram resolvidos em tempo útil e contribuíram para que o trabalho fosse aperfeiçoado.

Poderão pensar que os sistemas de transformação de documentos são básicos e essa era, antes de elaborar este trabalho, realmente a minha opinião. Com o avanço do desenvolvimento do trabalho e à medida que ia estudando os diversos modelos existentes no mercado, cheguei à conclusão que afinal, os sistemas de documentos são bastante complexos e não é somente a transformação de documentos, mas sim, todo o conjunto de regras e


- 69 -

transformações que são efectuadas sobres os documentos até chegar ao formato destino.

Falando em factos, na minha opinião, o projecto teve sucesso, pois quase tudo pedido foi elaborado com vista a atingir o objectivo. O maior problema foi encontrar informação na Internet sobre o tema central. De resto e para provar que o projecto funciona elaborei um caso prático demonstrando isso mesmo.

Penso que mais uma vez, tal como tinha sucedido no meu projecto de bacharelato, este projecto deu-me uma maior formação profissional ao nível na concepção de sistemas informáticos e bastante prática na medida em que, saber a teoria e pôr em pratica é muito melhor e mais compreensível do que só saber teoria.

È importante referir que este sistema irá abrir novos horizontes à empresa I2S – Informática Sistemas e Serviços, SA, pois irá permitir, além da compatibilização de versões já referenciadas, a troca de informação entre as diversas aplicações existentes na empresa. Isto irá permitir à empresa a troca de informação com os seus clientes que possuam outras aplicações, o que só por si, já é uma grande vantagem. Isto poderá ser alcançado através dos documentos XML.

Esta troca de informação, como não poderia deixar de ser, é realizada através de documentos CODOMO que podem representar os dados e regras de negócio da empresa (Seguros).

Como se pode reparar com as duas aplicações que eu estudei, nomeadamente a D2E e a ferramenta BizTalk, elas são muito mais complexas, pois a transformação não é directa. Quero com isto dizer, que a transformação entre o documento de entrada não tem mapeamento directo para o de saída, poderá existir inúmeras transformações pelo meio, adição de novos documentos, adição de regras de negócio. O projecto que apresento, é quase um mapeamento de toda a informação que entra para o documento destino, mas isso foi o que foi delineado como objectivos para a empresa, pois não é necessário mais do que isso. Apenas o facto de se poder transformar os documentos de um formato para outro já resolve imensos problemas à empresa.

Realço o capitulo de estudo, no qual me permitiu estudar assuntos interessantes, tais como, documentos XML e vários sistemas de transformação de documentos existentes no mercado e analisá-los de modo a perceber as arquitecturas e permitiu-me saber o porquê da existência dos sistemas baseados


- 70 -

em documentos. Este estudo serviu de complemento à minha aprendizagem que efectuei, durante estes cinco anos, no Instituto. É importante referir que, além de trabalhar na I2S, não trabalho com este sistema (SGBDoc) , sendo assim, tive que aprender todos os conceitos inerentes a este e obter alguma prática nos sistemas baseados em documentos existentes na empresa. Não é de admirar que este estudo foi bastante aprofundado que foi desde, como se introduzem dados via consola até às APIs de acesso e de manutenção da estrutura do SGBDoc.

Para finalizar, tenho que deixar bem claro e alertar para o facto de que, os sistemas de transformações de documentos estão a ser bastante requisitados nos nossos dias, pois é uma forma de representação dos objectos de negócio em documentos no formato electrónico.

Sistema Transformação Documentos Anexos

- 71 -

ANEXOS

Gramática CODOMO

<LDTD script> = DOCUMENT TYPE <string name> BEGIN <macros>? <types>? <udfs>? <data>? <methods>? END <string name> = ‘”’ [‘A’-‘Z’,’a’-z’,’_’,’ ‘,’0’-‘9’]+ ‘”’ <macros> = MACROS BEGIN <definition of macro> <definition of macro>? END <definition of macro> = <id> '(' <num> ')' AS <macro body> <types>= TYPES BEGIN <definition of struct> <definition of struct>? END <definition of struct> = STRUCT <id> BEGIN <definition of field> <definition of field>* END <udfs>= UDFS BEGIN <definition of udf> <definition of udf>? END <definition of udf> = <id> '(' [ <basic type> { ',' <basic type> }* ] ')' [ AS <basic type> ] <definition of field> = <id> AS <fixed type> <id> = [‘A’-‘Z’,’a’-‘z’,’_’] [‘A’-‘Z’,’a’-‘z’,’_’,’0’-‘9’]* <fixed type> = <simplex type> | <vector type>


- 72 -

<basic type> = NUM | DATE | LOG | <simplex char type> <simplex type> = <basic type> | <struct id> <struct id> = <id> <simplex char type> = CHAR { ‘(‘ <number> ‘)’ }? <vector type> = ARRAY ‘(‘ <number> { ‘,’ <number> }* ‘)’ OF <simplex type> <data> = DATA BEGIN <extended definition of field> <extended definition of field>* END <extended definition of field> = <id> AS <extended type> { ‘,’ <persistence> } <extended type> = <base type> | <col type> <col type> = COLL OF <base type> <base type> = <fixed type> | STR | BIN <persistence> = PERSIST <persistence> = VIRTUAL <persistence> = CONST { AS BEGIN <method body> END }? <methods> = METHODS BEGIN <method definition> <method definition>* END <method definition> = <id> BEGIN <method body> END Nota: • A gramática do símbolo não terminal <method body> corresponde à

gramática da linguagem LPS. • <macro body> é qualquer expressão válida da linguagem LPS que deve

ter tantos simbolos Pn quanto o número de paramtros da udf. Os parametros são identificados de P0 a Pn.


- 73 -

Descrição das APIs CODOMO utilizadas no mapeamento

CDM_DOCT_GETPROP – Devolve uma propriedade associada a um tipo de documento. (Nome do tipo de documento e numero do tipo de documento (UTID).

CDM_DOCT_GETNUMBEROFMACROS – Devolve o numero de macros que o tipo de documento possui.

CDM_DOCT_LISTMACROS – Devolve uma lista com todas as macros pertencentes ao tipo de documento.

CDM_DOCT_GETMACRODESCRIPTION – Devolve a descrição da macro, o seu conteúdo.

CDM_DOCT_GETNUMBEROFSTRUCTS – Devolve o numero de estruturas do tipo de documento.

CDM_DOCT_GETSTRUCTDESCRIPTION – Devolve a descrição da estrutura.

CDM_DOCT_GETSTRUCTNUMBEROFFIELDS – Devolve o numero de campos pertencentes a uma estrutura.

CDM_DOCT_GETSTRUCTFIELDDESCRIPTION – Devolve o nome de um campo da estrutura.

CDM_DOCT_GETNUMBEROFFIELDS – Devolve o numero de campos.

CDM_DOCT_GETFIELDPROP – Devolve uma propriedade do campo (Tipo de campo, nome, tamanho e dimensão)

CDM_DOCT_GETCONSTVALUE – Devolve o valor de uma constante.

CDM_DOCT_GETNUMBEROFMETHODS – Devolve o numero de métodos existes no tipo de documento.

CDM_DOCT_LISTMETHODS – Devolve a lista dos métodos existentes no tipo de documento.


- 74 -

CDM_DOCT_GETMETHODDESCRIPTION – Devolve a descrição de um método, ou seja, o seu conteúdo.

Sistema Transformação Documentos Bibliografia

- 75 -

BIBLIOGRAFIA

www.xenos.com

http://www.xml.org/xml/news_market.shtml

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbiz2k2/html/bts_InterCube.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbiz2k2/html/bts_InterCube.asp

http://www.saxproject.org/

http://www.w3.org/DOM/

http://www.w3.org/Style/XSL/

http://www.w3schools.com/xsl/

Manual do SGBDoc

INDICE REMISSIVO

B BizTalk ..............................................15, 17, 18, 19, 20 C

CODOMO 7, 10, 38, 39, 40, 41, 43, 46, 49, 50, 51, 52, 53, 54, 55, 57, 58, 59, 61, 62, 65, 66, 68, 69, 71

Sistema Transformação Documentos Bibliografia

- 76 -

D D2E........................................11, 12, 13, 14, 15, 16, 17 DLL .................................53, 54, 55, 58, 59, 61, 62, 63 DOCUMENTO............................................. 52, 53, 56 DOM..................................................14, 26, 29, 30, 31 DTD...................................................24, 25, 26, 32, 56

E EVENTOS................................................................ 55

H HTML............................................7, 12, 15, 16, 22, 32

P PARSER....................................................... 26, 27, 53

PROCESSADOR ............................................... 53, 55

S SAX.......................................10, 26, 27, 28, 29, 50, 55 SGBDOC.................................................7, 8, 9, 11, 38

T TRANSFORMAÇÃO .............................................. 31

X XML7, 8, 10, 12, 14, 15, 16, 17, 18, 20, 21, 22, 23, 24,

25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 50, 51, 54, 55, 56, 58, 65, 66, 68, 69

XSL .............................................20, 31, 32, 33, 34, 35 XSLT.............................................................31, 32, 36

PROJECTO DE LICENCIATURA - ipp.pt

Documents

Transcript of PROJECTO DE LICENCIATURA - ipp.pt