documento de arquitecturapaginas.fe.up.pt/~ei02017/docs/relatorio_lgp.pdf · 2006. 6. 17. ·...

Faculdade de Engenharia da Universidade do Porto

Documento de

Arquitectura

Documento de Arquitectura

Elaborado Por: Carlos Tavares, Hernâni Fernandes, José Pacheco Revisto Por: Aprovado Por:

Porto, 05 de Maio de 2006

Índice:

1. Introdução............................................................................................................................ 1

2. Enquadramento do Projecto .............................................................................................. 1

2.1. Contexto............................................................................................................................... 1

2.2. Problema / Solução Proposta............................................................................................... 2

3. Estrutura do Projecto.......................................................................................................... 3

3.1. Visão Geral .......................................................................................................................... 3

3.1.1. Módulo de Integração.................................................................................................... 4

3.1.2. Módulo Central .............................................................................................................. 4

3.1.3. Módulo de Interface....................................................................................................... 4

3.2. Descrição Modular ............................................................................................................... 4

3.2.1. Módulo de Integração.................................................................................................... 4

3.2.1.1. Pressupostos / Delimitação de Responsabilidade .................................................. 4

3.2.1.2. Arquitectura Lógica ................................................................................................. 5

3.2.1.2.1. Vista Horizontal ................................................................................................ 5

3.2.1.2.2. Vista Vertical..................................................................................................... 6

3.2.1.3. Arquitectura Física .................................................................................................. 7

3.2.1.4. Principais Decisões de Desenho............................................................................. 7

3.2.2. Módulo Central .............................................................................................................. 8

3.2.2.1. Pressupostos / Delimitação de Responsabilidade .................................................. 8

3.2.2.2. Arquitectura Lógica ................................................................................................. 8

3.2.2.2.1. Vista Horizontal ................................................................................................ 8

3.2.2.2.2. Vista Vertical................................................................................................... 11

3.2.2.3. Arquitectura Física ................................................................................................ 14

3.2.2.4. Principais Decisões de Desenho........................................................................... 15

3.2.2.4.1. Address .......................................................................................................... 16

3.2.2.4.2. Cliente ............................................................................................................ 16

3.2.2.4.3. Comment_Piece ............................................................................................. 17

3.2.2.4.4. Company_Data............................................................................................... 17

3.2.2.4.5. ContactosErros............................................................................................... 18

3.2.2.4.6. Delivery_Info................................................................................................... 18

3.2.2.4.7. Estado ............................................................................................................ 18

3.2.2.4.8. Filial ................................................................................................................ 19

3.2.2.4.9. Invoice ............................................................................................................ 19

3.2.2.4.10. Invoice_Header......................................................................................... 20

3.2.2.4.11. Invoice_Line.............................................................................................. 21

3.2.2.4.12. Invoice_Vat ............................................................................................... 21

3.2.2.4.13. Line_Discount ........................................................................................... 22

3.2.2.4.14. Receptor ................................................................................................... 22

3.2.2.4.15. Supplier..................................................................................................... 22

3.2.2.4.16. Utilizador ................................................................................................... 23

3.2.3. Módulo de Interface..................................................................................................... 23

3.2.3.1. Pressupostos / Delimitação de Responsabilidade ................................................ 23

3.2.3.2. Arquitectura Lógica ............................................................................................... 23

3.2.3.3. Arquitectura Física ................................................................................................ 24

4. Glossário............................................................................................................................ 25

4.1. ERP.................................................................................................................................... 25

4.2. Evaristo .............................................................................................................................. 25

4.3. http....... .............................................................................................................................. 25

4.4. JSP...... .............................................................................................................................. 25

4.5. Oracle... ............................................................................................................................. 25

4.6. Postgres............................................................................................................................. 25

4.7. Tomcat 25

4.8. XML.................................................................................................................................... 26

4.9. XSD….. .............................................................................................................................. 26

5. Referências........................................................................................................................ 26

Anexos.......................................................................................................................................... 1

Anexo 1 - Padrão Method Template........................................................................................... 1

Anexo 2 – Padrão Facade .......................................................................................................... 2

Índice de Imagens:

Figura 1 – Diagrama de Contexto .................................................................................................. 3 Figura 2 – Vista Horizontal da Arquitectura Lógica do Módulo de Integração................................ 5 Figura 3 – Arquitectura Física do Módulo de Integração ............................................................... 7 Figura 4 – Vista Horizontal da Arquitectura Lógica do Módulo Central e do Módulo de Interface . 9 Figura 5 - Colaboração entre classes (Subsistema de autenticação) .......................................... 12 Figura 6 - Colaboração entre classes (Subsistema de auditoria)................................................. 12 Figura 7 - Colaboração entre classes (Subsistema de consultas) ............................................... 13 Figura 8 - Colaboração entre classes (Subsistema de administração) ........................................ 14 Figura 9 – Arquitectura Física do Módulo Central........................................................................ 14 Figura 10 – Esquema Relacional da Base de Dados do Módulo Central .................................... 15 Figura 11 - Tabela Address. ........................................................................................................ 16 Figura 12 - Tabela Cliente. .......................................................................................................... 16 Figura 13 - Tabela Comment_piece............................................................................................. 17 Figura 14 - Tabela Company_Data.............................................................................................. 17 Figura 15 - Tabela ContactosErros. ............................................................................................. 18 Figura 16 - Tabela Delivery_Info.................................................................................................. 18 Figura 17 - Tabela Estado. .......................................................................................................... 18 Figura 18 - Tabela Factura. ......................................................................................................... 19 Figura 19 - Tabela Invoice. .......................................................................................................... 19 Figura 20 - Tabela Invoice_Header.............................................................................................. 20 Figura 21 - Tabela Invoice_Line................................................................................................... 21 Figura 22 - Tabela Invoice_Vat. ................................................................................................... 22 Figura 23 - Tabela Line_Discount. ............................................................................................... 22 Figura 24 - Tabela Receptor. ....................................................................................................... 22 Figura 25 - Tabela Supplier. ........................................................................................................ 22 Figura 26 - Tabela Utilizador........................................................................................................ 23 Figura 27 - Colaboração entre classes (Subsistema e-Billing).................................................... 24 Figura 28 – Arquitectura Física do Módulo de Interface .............................................................. 24 Figura 29 - Padrão Method Template. ........................................................................................... 1 Figura 30 - Padrão Facade. ........................................................................................................... 2

Documento Preliminar de Arquitectura [v1]

Página 1 de 19

1. Introdução

O presente documento tem como principal objectivo descrever a Arquitectura do Plugger, a solução proposta pela Integra Tech Solutions para o problema apresentado pela IBS Ibéria e que se enquadra no âmbito da disciplina de LGP (Laboratório de Gestão de Projectos) do 4º ano da LEIC.

2. Enquadramento do Projecto

2.1. Contexto

O processo de facturação é uma actividade que exige das organizações o consumo de uma grande quantidade de recursos. Tanto os compradores como fornecedores que utilizam o método tradicional de envio e recepção de facturas ficam obrigados a procedimentos manuais subjacentes a este processo (impressão, organização, notificações…), situação esta que se agrava com o aumento do volume de facturas diárias emitidas/recebidas pelos colaboradores.

O papel, as impressões, os envelopes, as taxas de envio e as limitações dos métodos tradicionais (horários, disponibilidades, distância) resultam em custos elevados por parte das organizações emissoras, assim como em danos ecológicos inerentes ao consumo de grandes quantidades de papel. No lado receptor, há problemas semelhantes, tais como o tempo gasto na recepção, a confirmação e inserção no arquivo da empresa.

A solução passa pela implementação do sistema de facturação electrónica, no qual todas as facturas são emitidas e transferidas digitalmente. Este sistema elimina todo o tipo de actividades do processo de facturação relacionadas com o uso de papel e o seu transporte, pois a factura é enviada através de e-mail, em formato pdf e certificada digitalmente sendo, deste modo, mais económica, ecológica, segura e eficiente.


Página 2 de 19

2.2. Problema / Solução Proposta

Para que este processo seja mais eficiente, a IBS Ibéria necessita de um sistema que suporte a recepção das facturas enviadas a partir de todas as empresas das quais é proprietária, independentemente do seu ERP, que possibilite a administração do processamento das mesmas através de uma aplicação Web e que suporte o reencaminhamento das facturas válidas para o seu destinatário através da sincronização com a ferramenta e-Billing.

O sistema deve também facilitar a integração de ERP’s distintos de empresas que a IBS Ibéria possa vir a comprar.

A IBS Ibéria dispõe do IBS Integrator, uma ferramenta de desenvolvimento. Um dos seus componentes é o IBS Server, uma aplicação que pode ser utilizada para sustentar um módulo de integração (que monitorize um sistema de facturação e envie as facturas emitidas por este para uma base de dados) que elimina o obstáculo da heterogeneidade dos ERP’s das várias empresas das quais a IBS Ibéria é proprietária.

O processo de envio das facturas electrónicas é feito a partir da monitorização de uma Base de Dados onde estas se encontram e do seu envio por e-mail para um dado destinatário definido na própria factura. Este processo é realizado pela aplicação IBS e-Billing. As suas funcionalidades permitem a monitorização e envio de facturas electrónicas por e-mail ou disponibilização das mesmas para download numa página web acessível apenas ao seu destinatário. Estas funcionalidades viabilizam a terceira fase do processo de facturação electrónica: o envio.

A Integra propõe a utilização do sistema Plugger que fará a ligação entre o módulo de integração (do lado das filiais) e o e-Billing.

O Plugger foi desenvolvido com o intuito específico de resolver estes problemas, fornecendo uma solução que reduz o esforço e custo consideráveis de integração de novas empresas, agilizando e rentabilizando ainda mais o processo de facturação da IBS Ibéria.


Página 3 de 19

3. Estrutura do Projecto

Esta secção destina-se a descrever o projecto de um ponto de vista superficial que, no entanto, permita uma noção inicial clara do mesmo, para facilitar a compreensão da Arquitectura do Plugger, descrita de uma forma estruturada e pormenorizada mais à frente neste documento.

3.1. Visão Geral

De acordo com o sugerido pela IBS Ibéria, e após o estudo dos requisitos funcionais do projecto e da interacção do mesmo com entidades exteriores (Figura 1), a Integra decompôs a Arquitectura do Plugger em 3 módulos, facilitando a sua compreensão e, por conseguinte, a sua implementação.

Figura 1 – Diagrama de Contexto


Página 4 de 19

3.1.1. Módulo de Integração

Módulo integrado na máquina da entidade emissora de facturas electrónicas.

Inclui as funcionalidades de monitorização da base de dados do seu ERP na busca de novas facturas e o seu envio para o Sistema Central.

3.1.2. Módulo Central

Módulo integrado na máquina central, que comporta a recepção de facturas, a sua validação e tratamento de erros, armazenamento e posterior envio para o e-Billing.

Este módulo contém uma interface que possibilita não só o acesso do utilizador previamente autenticado a todas as facturas armazenadas através de pesquisas, mas também a funções de administração e de diagnóstico.

3.1.3. Módulo de Interface

Este módulo suporta a monitorização da Base de Dados em intervalos de tempo definidos pelo utilizador em busca de novas facturas e o envio das mesmas para o e-Billing.

A aplicação IBS e-Billing (mais concretamente o e-Billing FileServer) é responsável enviar por fim as facturas recorrendo, para isso, ao serviço de e-mail.

3.2. Descrição Modular

Nesta secção serão descritas em pormenor as Arquitecturas Lógica e Física de cada um dos 3 módulos do Plugger.

3.2.1. Módulo de Integração

3.2.1.1. Pressupostos / Delimitação de Responsabilidade

O acesso e a monitorização da Base de Dados foram implementados de forma a garantir compatibilidade com o ERP Evaristo, sendo que a integração de uma empresa que utilize qualquer outro ERP não poderá ser realizada sem que a Integra efectue um estudo prévio deste e da sua Base de Dados e que seja proposta uma nova release do Plugger.


Página 5 de 19

3.2.1.2. Arquitectura Lógica

A arquitectura Lógica do módulo de Integração será descrita nesta secção e terá como principais pontos de foco o desenho da interacção de componentes, mecanismos e protocolos de ligação, sendo composta pelas suas vistas horizontal e vertical.

3.2.1.2.1. Vista Horizontal

Nesta secção será descrita a decomposição horizontal do módulo de Integração em sucessivas camadas sobrepostas, na qual cada uma acrescenta valor à camada inferior, disponibilizando-o sob a forma de serviços à camada imediatamente acima.

Figura 2 – Vista Horizontal da Arquitectura Lógica do Módulo de Integração


Página 6 de 19

• Lógica de Aplicação

o Nesta camada ficará a classe RunnerIntegrator, classe principal do módulo, que é responsável pela interacção com as restantes classes que permitem o acesso à base de dados.

Esta classe é responsável, também, pela persistência do estado da aplicação entre execuções e pelo envio das facturas para o sistema central.

• Lógica de Negócio

o Nesta camada tratam-se de todos os assuntos relacionados com a lógica de negócio inerente ao domínio de aplicação, implementando todas as funcionalidades necessárias à obtenção de informação dos ERP’s a integrar e ao seu envio para o sistema central, tendo sido construída de forma independente das outras camadas, de forma a permitir ser alterada sem consequências no desenho destas.

Aqui fica a DataERPConnector, uma classe que implementa um “template method” (design pattern descrito no Anexo 1) com os principais algoritmos necessários à leitura e tratamento dos dados das várias bases de dados. As operações abstractas deste métodos são instanciadas pela classe especifica do sistema de facturação em causa.

Existe também neste módulo a EvaristoERPConnector, classe que implementa algumas operações abstractas específicas do ERP Evaristo. Esta classe é responsável pela ligação à base de dados e pela leitura dos dados.

• Acesso a Dados

Esta camada deverá prestar suporte a todas as funcionalidades de armazenamento de informação e com ela pretende-se abstrair o suporte físico de armazenamento.

Aqui ficará a classe JDBCDriver, classe nativa do Java utilizada para acesso à base de dados escolhida.

3.2.1.2.2. Vista Vertical

O sistema em análise é constituído apenas por um único subsistema, responsável pela monitorização da base de dados e envio de novas facturas para o módulo central. Como tal, a dependência entre as classes está representada no diagrama da Vista Horizontal.


Página 7 de 19

3.2.1.3. Arquitectura Física

O diagrama seguinte representa a Arquitectura Física do Módulo de Integração:

Figura 3 – Arquitectura Física do Módulo de Integração

É instalada a aplicação IBS Server na máquina da empresa filial, que permite ao Módulo de Integração monitorizar a Base de Dados do ERP (Postgres) onde se encontram as facturas electrónicas emitidas pela empresa, identificando as facturas a processar – todas aquelas que foram emitidas após o instante da verificação anterior.

São gerados pedidos http para que sejam enviadas as facturas processadas (no formato xml) para o módulo central.

3.2.1.4. Principais Decisões de Desenho

Optou-se pela utilização do ERP Evaristo, por este ser bastante simples e intuitivo na sua utilização. A Base de Dados escolhida foi PostGres, pela sua compatibilidade com este ERP.


Página 8 de 19

3.2.2. Módulo Central


A nível de interface, foi criado apenas um nível de acesso, pois o Plugger destina-se apenas a administradores de sistema da IBS Ibéria.

A estrutura das facturas será validada pelo Plugger.

Quanto ao conteúdo das facturas electrónicas, este não é validado pelo módulo central, pertencendo à entidade emissora esta responsabilidade.

Para além das funcionalidades de Autenticação e Pesquisa, o Plugger disponibiliza uma opção de Administração/Configuração que, entre outras, permite ao utilizador a inserção manual de informação relativa a um colaborador na eventualidade de chegar ao sistema uma factura que o tenha como destinatário e este não exista ainda na base de dados.

O Plugger disponibiliza também a opção Audit, que elabora um diagnóstico das facturas guardadas.


A arquitectura Lógica do módulo Central será descrita nesta secção e terá como principais pontos de foco o desenho da interacção de componentes, mecanismos e protocolos de ligação, sendo composta pelas suas vistas horizontal e vertical.

3.2.2.2.1. Vista Horizontal

Nesta secção será descrita a decomposição horizontal do módulo Central em sucessivas camadas sobrepostas, na qual cada uma acrescenta valor à camada inferior, disponibilizando-o sob a forma de serviços à camada imediatamente acima.

Na Figura 5 é representada a vista horizontal sobre a arquitectura do módulo Central e também sobre o módulo de Interface.


Página 9 de 19

Figura 4 – Vista Horizontal da Arquitectura Lógica do Módulo Central e do Módulo de Interface


Página 10 de 19

• Comunicação com ERP

o Esta camada é responsável por disponibilizar mecanismos (classe Responder) que respondem a pedidos http enviados por ERP’s. Os pedidos contêm facturas electrónicas emitidas pelo ERP que se destinam à integração na Base de Dados do módulo central e consequente envio para os seus destinatários.

Para a integração das facturas e o seu envio, esta camada utiliza classes de parsing e validação e funcionalidades disponibilizadas pela camada de lógica de negócio, tendo sido construída de modo completamente independente das outras camadas, para que as suas eventuais alterações não impliquem modificações nestas.

• Interface com o Utilizador

o A interface com o utilizador é a camada responsável por toda a interacção da aplicação com este e foi implementada em JSP.

Cabe a esta camada a apresentação de informação relevante ao utilizador através do acesso a funcionalidades oferecidas pela camada directamente abaixo.

Esta, tal como todas as camadas horizontais, foi construída de modo completamente independente das outras camadas, de forma a poder sofrer alterações sem que isso implique modificações nestas.

• Lógica de Negócio

o Nesta camada tratam-se de todos os assuntos relacionados com a lógica de negócio inerente ao domínio de aplicação, oferecendo um conjunto de classes às camadas superiores que lhe permita abstrair-se de aspectos relacionados com Bases de Dados e com os acessos às mesmas.

Esta camada deve ser transparente e bem definida para que seja simples a sua alteração sem pôr em causa todo o trabalho desenvolvido ao nível da interface. Deve ainda comunicar com a camada de nível inferior de modo a poder realizar as tarefas que lhe são destinadas.

Assim sendo, todas as funcionalidades de armazenamento de informação devem ser disponibilizadas pela camada de nível inferior, abstraindo a camada de lógica de negócio de todos os pormenores inerentes à sua implementação. Para facilitar a comunicação com a camada superior será utilizado o padrão facade, do qual se fará uma descrição no Anexo 2.


Página 11 de 19

• Business Objects

o Os elementos desta camada foram criados com recurso a “hibernate tools”, e são uma representação abstracta dos objectos (tabelas) da Base de Dados, servindo como mais uma camada de abstracção, permitindo às camadas superiores ignorar detalhes de acesso a dados.

Esta camada foi construída de forma independente das camadas que estão relacionadas consigo, para que pudesse ser alterada sem que isso implicasse mais modificações noutras.

• Acesso a Dados

o Esta camada deverá prestar suporte a todas as funcionalidades de armazenamento de informação.

Com ela pretende-se abstrair o suporte físico de armazenamento e, como tal, fornecer um serviço à camada superior de forma abstracta e independente dos suportes de armazenamento que utiliza.

Nesta camada são criados todos os métodos de acesso à Base de Dados do módulo central. Para conseguir este nível de abstracção irá ser igualmente utilizado o padrão facade.

• Dados

o Este nível representa a camada física de armazenamento de informação.

Nesta camada encontram-se todos os mecanismos de armazenamento de informação (base de dados)

3.2.2.2.2. Vista Vertical

Nesta parte do sistema a desenvolver é possível identificar 4 subsistemas: sistema de autenticação, sistema de auditoria, sistema de consultas e sistema de administração, cujas vistas verticais são descritas nesta secção.


Página 12 de 19

Subsistema de Autenticação

Figura 5 - Colaboração entre classes (Subsistema de autenticação)

Neste subsistema (Figura 5) é necessário aceder a quatro camadas para possibilitar as funcionalidades de autenticação no sistema. As setas indicam o modo hierárquico de como as classes de cada uma das camadas é acedida.

Subsistema de Auditoria

Figura 6 - Colaboração entre classes (Subsistema de auditoria)


Página 13 de 19

Para se executarem as funcionalidades de auditoria é necessário recorrer a serviços disponibilizados pelas packages presentes no diagrama representado na Figura 6.

Subsistema de Consultas

Figura 7 - Colaboração entre classes (Subsistema de consultas)

O subsistema de consultas utiliza serviços de quatro packages para poder disponibilizar ao utilizador um conjunto de funcionalidades úteis. Este subsistema está representado na Figura 7.


Página 14 de 19

Subsistema de Administração

Figura 8 - Colaboração entre classes (Subsistema de administração)

O subsistema de administração (Figura 8) é o que requer o maior número de packages.


O diagrama seguinte representa a Arquitectura Física do Módulo Central:

Figura 9 – Arquitectura Física do Módulo Central


Página 15 de 19

O módulo disponibilizará um servlet que atenderá pedidos http, guardando as facturas em formato XML presentes nos sistemas de ERP das filiais, numa base de Dados Oracle.

O Tomcat suporta (neste módulo) a interface Web que foi implementada em JSP e que tem funcionalidades acessíveis apenas ao Administrador autenticado da IBS Ibéria.

3.2.2.4. Principais Decisões de Desenho

O esquema da Base de Dados do módulo central é o seguinte:

Figura 10 – Esquema Relacional da Base de Dados do Módulo Central

Nesta nova arquitectura é de salientar o facto de se tornar mais simples o processo de pesquisa e retorno de informação.

Toda a equipa de desenvolvimento está habituada a executar consultas sql, deste modo o facto de se ter consumido mais tempo a reformular a estrutura da Base de Dados do módulo central foi compensado pelo aumento do rendimento do desenvolvimento.

Optou-se por esta representação para aumentar a velocidade das pesquisas na base de dados. No entanto, desta forma, a reconstrução das facturas no formato xml seria mais demorada, pelo que a Integra decidiu manter também cada factura recebida no sistema de ficheiros para efeitos de reenvio, tendo deste modo disponível uma base de dados optimizada para pesquisas e as facturas intactas disponíveis no sistema de ficheiros para os reencaminhamentos das mesmas, sendo estas acedidas através de uma referência existente na base dados.


Página 16 de 19

De seguida passamos à descrição das tabelas da base de dados.

3.2.2.4.1. Address

Figura 11 - Tabela Address.

Nesta tabela são guardadas as moradas que constam nas facturas que são enviadas pelo módulo 1 para o módulo 2.

3.2.2.4.2. Cliente

Figura 12 - Tabela Cliente.

Aqui é guardada toda a informação relativa aos clientes das empresas filiais. Esta informação é necessária para se poder proceder ao envio electrónico das facturas para o cliente.

Sempre que chega uma nova factura ao sistema central é verificado se o cliente em causa já consta na base de dados. Caso isto não ocorra, o cliente é inserido automaticamente de forma a proceder ao estabelecimento de um contrato de envio electrónico de facturas. Contudo, mesmo que o cliente seja inserido no sistema, este só envia as facturas electronicamente no caso de existir um e-mail associado ao seu registo.


Página 17 de 19

3.2.2.4.3. Comment_Piece

Figura 13 - Tabela Comment_piece.

Por vezes, as facturas e as linhas da factura são acompanhadas de comentários. Como tal para permitir guardar essa informação necessitamos desta tabela.

Aqui, existe um campo que nos permite identificar a factura ou linha às quais está associado o comentário, o campo id_externo. Para sabermos se estamos a falar de uma factura colocamos o valor 1 no campo factura. Caso o valor seja 0, significa que o id_externo referencia um comentário respeitante a uma linha de factura.

3.2.2.4.4. Company_Data

Figura 14 - Tabela Company_Data.

Nesta tabela guarda-se todo a informação relativa a uma empresa filial. É aqui que se inserem os dados genéricos relativos a uma empresa que emite facturas para o sistema central para que este as guarde.

Também neste caso é verificado se a filial já se encontra ou não inserida no sistema. Em caso negativo esta é inserida automaticamente.


Página 18 de 19

3.2.2.4.5. ContactosErros

Figura 15 - Tabela ContactosErros.

Esta tabela é utilizada para inserir os contactos de e-mail das pessoas a informar em caso de erro no sistema central.

3.2.2.4.6. Delivery_Info

Figura 16 - Tabela Delivery_Info.

Esta tabela guarda a informação relativa aos dados de entrega da factura.

Todos os itens da factura têm que ser entregues e como tal é necessário existir informação na factura para se poder processar o respectivo envio.

3.2.2.4.7. Estado

Figura 17 - Tabela Estado.

Nesta tabela guarda-se o estado da respectiva factura. Este estado permite-nos saber, entre outros, se a factura já foi ou não enviada para o sistema IBS e-Billing FileServer.

Existem cinco estados possíveis para as facturas:

• Factura enviada com sucesso para o e-Billing FileServer;

• Aguarda envio para o e-Billing FileServer;

• Factura inválida;

• e-Billing FileServer indisponível;

• Aguarda inserção do e-mail do cliente.


Página 19 de 19

3.2.2.4.8. Filial

Figura 18 - Tabela Factura.

Nesta tabela guarda-se toda a informação respeitante a todas as filiais que se encontram no sistema.

Esta informação é um pouco redundante com o conteúdo da tabela Supplier, contudo aqui é guardada informação de acesso mais rápido de forma a acelerar as pesquisas.

3.2.2.4.9. Invoice

Figura 19 - Tabela Invoice.

Na tabela Invoice guarda-se toda a informação necessária ao reconhecimento de uma factura. É aqui que ficam registos como a empresa que enviou a factura, qual o cliente a quem a factura se destina, etc.

De forma a permitir o envio mais rápido das facturas para o File Server da IBS guarda-se a mesma no File System do computador onde a nossa aplicação estiver a correr, com uma referência na Base de Dados. Deste modo não existe necessidade de voltar a construir todo o xml da factura.


Página 20 de 19

3.2.2.4.10. Invoice_Header

Figura 20 - Tabela Invoice_Header.

Todos os dados que dizem respeito ao típico cabeçalho de uma factura são guardados aqui.


Página 21 de 19

3.2.2.4.11. Invoice_Line

Figura 21 - Tabela Invoice_Line.

Todas as linhas da factura são guardadas nesta tabela. Estas linhas podem ter comentários associados. Como tal temos um campo que nos possibilita relacionar esta tabela com aquela que guarda essa informação.

3.2.2.4.12. Invoice_Vat


Página 22 de 19

Figura 22 - Tabela Invoice_Vat.

Geralmente todas as facturas têm taxas de IVA associadas aos artigos que estão vender. Para guardar essa informação utiliza-se a tabela Invoice_Vat.

3.2.2.4.13. Line_Discount

Figura 23 - Tabela Line_Discount.

Quando uma determinada linha de factura contém um desconto este é guardado nesta tabela.

3.2.2.4.14. Receptor

Figura 24 - Tabela Receptor.

Nesta tabela encontram-se registados todos os e-mail’s das pessoas para as quais são enviadas as notificações de erro quando acontece algo inesperado no sistema central.

3.2.2.4.15. Supplier

Figura 25 - Tabela Supplier.

Esta tabela é usada para guardar a informação dos fornecedores. Neste caso os fornecedores são as empresas filiais. Esta é a informação que está um pouco inconsistente com a tabela filial. Contudo achamos melhor colocar isto aqui de forma a facilitar as pesquisas.


Página 23 de 19

3.2.2.4.16. Utilizador

Figura 26 - Tabela Utilizador.

Aqui guarda-se a informação relativa ao utilizador do sistema.

3.2.3. Módulo de Interface


A integração das facturas electrónicas com o sistema IBS e-Billing será realizada através da aplicação e-Billing FileServer.

A detecção de erros por parte do e-Billing será facilitada pelo facto do e-Billing FileServer devolver um erro caso a factura seja inválida.

O Plugger verifica apenas se as facturas são enviadas pelo e-Billing, fazendo, no entanto, o tratamento dos erros anteriores ao envio.


A arquitectura lógica do módulo do Interface inclui-se no sistema central da aplicação.

A sua composição horizontal encontra-se definida pelas mesmas camadas que estão indicadas no módulo Central. A divisão vertical contém um novo subsistema de integração com a aplicação IBS e-Billing, descrito na Figura 12.


Página 24 de 19

Subsistema de Integração com o e-Billing

Figura 27 - Colaboração entre classes (Subsistema e-Billing)

Neste subsistema é necessário aceder ao conjunto de classes indicado para que o processamento de mensagens entre os dois módulos se processe de forma correcta.


O diagrama seguinte representa a Arquitectura Física do Módulo de Interface:

Figura 28 – Arquitectura Física do Módulo de Interface

O Tomcat é instalado de modo a suportar (neste módulo) o e-Billing. As facturas em formato XML que provêm do módulo central são integradas no File System, o qual é monitorizado pelo File Watcher do e-Billing.

O e-Billing trata do envio da factura para o seu destinatário através de uma mensagem de correio electrónico.


Página 25 de 19

4. Glossário

4.1. ERP

Enterprise resource planning, sistema de gestão que engloba todas as facetas de negócio, incluindo planeamento, produção, vendas e marketing.

4.2. Evaristo

ERP utilizado na máquina da filial para simular uma empresa pertencente à IBS com o seu próprio sistema de facturação.

4.3. HTTP

HyperText Transfer Protocol, protocolo utilizado na transferência de informação na Web, baseado em pedidos/respostas entre clientes e servidores. Utilizado na transferência de ficheiros XML.

4.4. JSP

JavaServer Pages, tecnologia Java que permite gerar dinamicamente HTML, XML e outros tipos de documentos em resposta a pedidos do utilizador. Utilizado na Interface do sistema Central.

4.5. Oracle

Base de Dados utilizada na máquina central.

4.6. Postgres

Base de Dados utilizada na máquina da filial.

4.7. Tomcat

Servidor aplicacional que, no caso do Plugger, funcionará como servidor de páginas JSP, sendo utilizado no suporte da interface do sistema Central e do e-Billing.


Página 26 de 19

4.8. XML

eXtensible Markup Language, linguagem de descrição de informação com auxílio a “tags” de uso geral. O seu principal propósito é facilitar a troca de informação por sistemas heterogéneos, sem que esses sistemas tenham de conhecer a priori a sua estrutura sendo, por isso, usado na constituição dos pedidos http e no armazenamento das facturas (tanto nas Bases de Dados como no e-Billing).

4.9. XSD

XML Schema Definition, documento que descreve um tipo de documento XML em termos de restrições sobre os elementos e atributos que nele possam aparecer, a relação entre eles, que tipo de dados podem conter, etc. É usado para validar a estrutura das facturas XML enviadas do módulo de integração para o módulo central.

5. Referências

http://www.oracle.com/

http://www.wikipedia.com

Anexos

Anexo 1 - Padrão Method Template

Figura 29 - Padrão Method Template.

A utilização deste padrão prende-se com a necessidade de dotar a aplicação de expansibilidade.

Numa classe abstracta definem-se os métodos comuns a vários domínios de aplicação, enquanto que nas classes concretas podemos implementar os métodos que dizem respeito apenas a um determinado domínio de aplicação.

Anexo 2 – Padrão Facade

Figura 30 - Padrão Facade.

O diagrama anterior descreve a composição do padrão de software facade.

Este padrão permite abstrair uma camada aplicacional dos pormenores de implementação de outra, da qual necessita de utilizar alguns serviços.

De seguida irá ser feita uma descrição de cada uma das classes colaboradoras no padrão:

• Client Class

o estas classes usam serviços fornecidos pela facade, de modo transparente aos pormenores de implementação;

• Facade

o nesta classe devem ser implementados os serviços a fornecer às Client Classes. É também da sua responsabilidade chamar as classes necessárias para satisfazer os pedidos dos clientes.

• SubSystem Class

o estas são as classes do sistema que se pretende abstrair. Devem ser aqui implementados todas as funcionalidades necessárias ao sistema a desenvolver.

documento de arquitecturapaginas.fe.up.pt/~ei02017/docs/relatorio_lgp.pdf · 2006. 6. 17. ·...

Documents