Uma Experincia de Desenvolvimento de um Sistema Distribudo Utilizando uma Arquitetura Multiplataforma

Gustavo da Rocha Barreto Pinto1, Geraldo Zimbro1, Mrcio Duran1, Jos Roberto Blaschek1, Jano Moreira de Souza1, Nilson Lopes Jr.2, Ana Paula Alves de Souza3, Paula Ballard2 , Rachel Calao2
1

Programa de Engenharia de Sistemas e Computao COPPE / Universidade Federal do Rio de Janeiro

2

DCoM Diretoria de Contas Marinha do Brasil

DFM Diretoria de Finanas Marinha do Brasil

Abstract: This paper presents experiences in a well successful information system development, Qustor. Qustor was implemented in a three-tier technology over a multi-plataform architecture: it can execute over Firebird or Oracle databases, locally or remotely. Client application (web browser), application server and database server can execute on Linux or Windows systems. The application server was developed using Kylix 3/Delphi 7 and IntraWeb, a framework to web development. The system is actually operational with all planning functionalities. There is only one source code for the multi-plataform (firebird/oracle, local or remote). Routines were developed in order to allow database synchronization among several distributed data sources and an only centralized data source. Resumo: Este trabalho relata as experincias de um caso bem sucedido de desenvolvimento de um sistema de informaes, o Quaestor. O Quaestor distribudo em trs camadas, utilizando uma arquitetura multiplataforma: o sistema pode utilizar banco de dados Firebird ou Oracle, sendo executado local ou remotamente. Tanto o cliente (browser web) quanto o servidor de aplicao, bem como o servidor de banco de dados, podem ser executados em ambiente Linux ou Windows. O desenvolvimento do servidor de aplicaes foi feito utilizando-se o Kylix 3/Delphi 7 e o IntraWeb, um conjunto de componentes para desenvolvimento Web. O sistema est atualmente em produo, com todas as funcionalidades inicialmente previstas prontas. Existe uma nica verso de cdigo fonte, pois o sistema foi desenvolvido de forma a ser totalmente compatvel com as diversas configuraes possveis. Foram desenvolvidas tambm rotinas que permitem a sincronizao peridica das diversas bases distribudas em uma nica base centralizada.

1. Introduo
Este trabalho apresenta a arquitetura que foi utilizada para o desenvolvimento do sistema de Caixa de Economias desenvolvido pela DFM e DCoM em conjunto com a equipe Coppetec, denominado Quaestor. Esta arquitetura define o funcionamento dos aplicativos e bases de dados que compem o sistema, determinando em quais mquinas

o aplicativo ser executado, a distribuio da(s) base(s) de dados, formas de atualizao dos aplicativos, sincronizao dos dados e as tecnologias utilizadas para a implementao do aplicativo e da base de dados. O Quaestor um sistema desenvolvido com o objetivo de apoiar os gestores de Caixa de Economias na execuo de suas atividades, alm de facilitar a anlise e auditoria das Caixas de Economias de todas as OMs da Marinha do Brasil (MB) pela DCoM. O sistema permite que sejam cadastrados documentos de receita e despesa, em diversas subcontas da Caixa de Economias, gerando balancetes ao final de cada perodo de prestao de contas. Ele acessado remotamente pelos browsers Internet Explorer e Netscape (ou compatvel com Mozilla) via Intranet (RECIM) da MB. A base centralizada reside em um banco de dados Oracle sobre Linux sendo executado em um mainframe IBM na PAPEM. O atual servidor de aplicaes centralizado um micro computador Pentium IV 2.4 GHz, rodando Windows 2000. O sistema encontra-se em produo, sendo utilizado atualmente por cerca de 250 OMs de um total de 307. Todas as OMs que possuem a gestoria estaro utilizando o sistema at o final do ano. Um requisito importante o fato de que vrias OMs, em particular as embarcaes, poderem ficar sem acesso ao sistema Quaestor por um longo perodo, chegando mesmo a alguns meses. Para evitar que a OM tenha de fazer o seu controle de Caixa de Economias manualmente e depois ter o retrabalho de entrar com todos os dados coletados no Quaestor, foi desenvolvida uma verso do sistema Quaestor que pode operar localmente nas OMs. Posteriormente, quando a OM voltar a acessar a Intranet, a aplicao local permite que os dados sejam exportados para aplicao centralizada resincronizando as bases de dados. Para evitar o custo de desenvolver e manter duas aplicaes distintas, a aplicao foi desenvolvida de forma a poder ser executada tanto local quanto remotamente. Alm disso, para diminuir custos de licena de software e de pessoal especializado, o banco de dados local selecionado foi o Firebird, um banco de dados open source gratuito. Assim, a aplicao final pode ser executada localmente, acessando o Firebird, ou remotamente, acessando o Oracle. Este artigo est organizado da seguinte forma: a seo 2 apresenta os principais requisitos do sistema que resultaram em grandes impactos na arquitetura, a seo 3 apresenta as alternativas que foram propostas, a seo 4 analisa as vantagens e desvantagens de cada alternativa, a seo 5 mostra em detalhes a arquitetura proposta, e a seo 6 relata as concluses.

2. Requisitos do Sistema
A maioria das OMs da MB possui a gestoria de Caixa de Economias que deve ser utilizada para proporcionar conforto tripulao. O objetivo do Quaestor fornecer suporte s OMs para gerenciar sua Caixa de Economias e posteriormente realizar a prestao de contas junto DCoM. O sistema fornece meios DCoM para analisar a prestao de contas de todas as OMs da MB, sendo capaz de compilar diversas informaes a respeito da gestoria tanto a nvel gerencial, voltado para os altos escales da MB, quanto para o Tribunal de Contas da Unio (TCU). Na definio da arquitetura proposta, os seguintes requisitos de negcio foram identificados: 1) Prestao de Contas: Cada OM necessita realizar junto DCoM uma prestao de contas mensal e;

2) Consolidao: A DCoM consolida a prestao de contas de cada OM realizando uma anlise dos dados enviados. Alm disso, as seguintes premissas sobre o ambiente onde o sistema ir operar foram consideradas como vlidas: 1) Conexo: das cerca de trezentas OMs a serem atendidas pelo sistema, temos que: a. Algumas OMs estaro sempre conectadas Intranet; b. Algumas OMs tero perodos de desconexo prolongados seguidos de perodos com conexo Intranet o caso da maioria das embarcaes e; c. Algumas OMs no possuem acesso Intranet; 2) Pessoal: diversas OMs apresentam problemas de falta de pessoal com alta, mdia ou mesmo baixa qualificao em Informtica; 3) Equipamento: diversas OMs apresentam parque computacional de baixa capacidade e; 4) Sistema: a maioria das OMs possui apenas computadores com sistemas Windows 98. Portanto, qualquer arquitetura proposta teria de contemplar os itens acima enumerados, tanto os de requisitos de negcio como as limitaes do ambiente. Por fim, foram definidos como critrios de avaliao para as alternativas da arquitetura os seguintes pontos: 1) Custos de desenvolvimento, manuteno e operao; 2) necessidades de pessoal e mquinas em cada OM para a implantao do sistema na MB como um todo; 3) segurana das informaes; 4) gerao de trfego na rede; 5) desempenho dos aplicativos e; 6) disponibilidade.

3. Apresentao das Alternativas

Diversas alternativas para as decises relevantes da arquitetura proposta foram elaboradas considerando o leque de tecnologias atualmente disponveis no mercado e nas quais a MB e/ou a equipe Coppetec apresenta capacitao, ou fcil aquisio de capacidade. No entanto, poucas alternativas conseguiram contemplar todos os itens acima enumerados de forma satisfatria. Vamos considerar as decises na seguinte ordem: local onde os aplicativos sero executados; local onde estaro as bases de dados; formas de atualizao dos aplicativos; formas de sincronizao dos dados para a prestao de contas.

3.1

Local onde os aplicativos sero executados

H duas possibilidades: executar o aplicativo localmente ou remotamente. Localmente significa ter um (ou mais) arquivo(s) executvel(is) na mquina do usurio do sistema, ou seja, na OM. Para a execuo remota, em um servidor Windows, temos a possibilidade de utilizar servios de terminal remoto ou aplicaes usando interface de navegador Internet (browser). Porm, j que algumas OMs no possuem conexo com a Intranet da MB, e outras suspendem a conexo por perodos que podem ser longos, o aplicativo nestas OMs no poder ser executado remotamente. Por outro lado, executar o aplicativo remotamente somente ser possvel atravs do uso de navegadores via Internet, dado que o uso de terminais remotos requer grande capacidade computacional da mquina servidora. Esta deciso possui grande impacto na forma de atualizao dos aplicativos, trfego gerado na rede e na necessidade de pessoal e mquinas em cada OM. 3.2 Local onde estaro as bases de dados

H tambm duas possibilidades: bases locais ou bases remotas. Uma base local ir necessitar de um sistema gerenciador de banco de dados instalado na mquina do usurio, ou seja, em uma mquina da OM. Dados os custos de licenas, o ideal que se utilize algum banco de dados gratuito neste tipo de soluo. Porm, bancos de dados gratuitos apresentam baixa escalabilidade e funcionalidade. J uma soluo com base de dados remota pode compartilhar o mesmo sistema gerenciador de banco de dados, embora continue havendo a necessidade de um grande nmero de licenas. Da mesma forma que a questo anterior, j que algumas OMs no possuem conexo com a Intranet da MB, e outras suspendem a conexo por perodos que podem ser longos, nestas OMs a base de dados deve ser local. Por outro lado, as OMs com conexo permanente podem ter acesso remoto base de dados. Essa deciso pode gerar grande impacto no trfego gerado na rede, na forma de sincronizao dos dados e na necessidade de pessoal e mquinas em cada OM. 3.3 Formas de atualizao dos aplicativos

Aplicativos que executam remotamente em um servidor so atualizados em um nico lugar: no servidor. Apenas aplicativos que executam localmente necessitam de uma poltica mais elaborada de atualizao. Nesses casos, a melhor forma de atualizao a deteco automtica da existncia de uma nova verso do sistema e conseqente atualizao, atravs de alguma poltica que dispense o uso de meios fsicos: por exemplo, o uso do protocolo ftp para a obteno das novas verses. Esta abordagem no vlida para as OMs que no possuem conexo com a Intranet. No entanto, como espera-se que as atualizaes do aplicativo no sejam nem to freqentes nem to urgentes, as OMs que possuem conexo intermitente podem usar os perodos em que a Intranet estiver acessvel para realizar a atualizao. Portanto, para as OMs que no possuem acesso a Intranet a nica forma de atualizar o aplicativo ser via meio magntico (por exemplo CD, memory keys, etc).

3.4

Formas de sincronizao dos dados para a prestao de contas

De forma anloga, apenas as bases locais necessitaro de algum tipo de sincronizao. As bases remotas j estaro no servidor que ser usado pela DCoM para realizar a consolidao dos dados. Novamente por analogia, o ideal que se faa a transferncia dos dados de forma totalmente eletrnica e automtica. No entanto, as OMs que suspendem a conexo por tempo prolongado podero ter que fazer a sincronizao dos dados por via magntica se no for possvel esperar at a prxima vez em que a Intranet esteja disponvel.

4. Anlise das Alternativas

Devido s caractersticas de conexo Intranet de cada OM, temos que o aplicativo deve claramente ser executado localmente, com base de dados local, em algumas OMs. A principal questo torna-se ento decidir se esta ser a soluo a ser adotada para todas as OMs, ou se algumas OMs podero ter outros tipos de aplicativos. Podemos ter as seguintes combinaes de aplicativos: Um aplicativo que execute localmente acessando dados locais; Um aplicativo que execute localmente acessando dados remotos; Um aplicativo que execute remotamente acessando dados remotos;

Podemos descartar a combinao um aplicativo que execute remotamente acessando dados locais por no ser vivel. Claramente podemos identificar que estas alternativas impactam de forma antagnica nos critrios de avaliao. A Tabela 1 ilustra esses critrios.
Tabela 1 Alternativas analisadas segundo os critrios propostos

Opes Critrios A) Custos de desenvolvimento B) Custos de manuteno e operao 1 2 3

Aproximadamente o mesmo para todas as alternativas

Alto: cada OM necessitar manter um ambiente de produo prprio. Alto

Mdio: cada OM necessitar manter o aplicativo instalado

Baixo: cada OM ter apenas de manter o navegador; apenas a DCoM/DFM precisar manter um ambiente de produo Baixo

C) Necessidades de pessoal e mquinas em cada OM

Mdio

D) Custo de segurana das informaes

Alto: cada OM ter de ter uma rotina de backup Nenhum: apenas no fechamento ser gerado trafego Dependente das mquinas de cada OM

Baixo: apenas a DCoM/DFM ter de manter uma rotina de backup Alto: todas as informaes, mesmo as no utilizadas, iro ser transferidas . Dependente das mquinas de cada OM, do servidor da DCoM/DFM e da velocidade da rede idem

Baixo: apenas a DCoM/DFM ter de manter uma rotina de backup Baixo: apenas as informaes visualizadas sero transferidas Dependente do servidor da DCoM/DFM e da velocidade da rede Idem

E) Gerao de trfego na rede

F) desempenho dos aplicativos

G) Disponibilidade

idem

Claramente podemos observar que a opo 3 a que acarretar menos custos para a MB de acordo com os critrios B, C, D, F e G. No critrio A podemos considerar que as opes so equivalentes, e no critrio E a opo 1 a melhor. Porm, apesar da opo 3 ser melhor nos critrios que resultam em mais custos, cabe lembrar que a opo 1 ter de ser implantada para algumas OMs. Portanto, para minimizar os custos para a MB como um todo, verificamos que interessante implantar a opo 3 em todas as OMs com conexo permanente Intranet, e implantar a opo 1 apenas nas OMs onde a opo 3 se mostrar invivel. Escolhendo implantar as opes 1 e 3 sob a forma de dois aplicativos independente teremos o custo extra de desenvolvimento e manuteno de dois aplicativos cujo princpio de funcionamento distinto. Portanto, seria bastante vantajoso desenvolver um nico aplicativo que pudesse operar de acordo com as opes 1 e 3. Com a nova tecnologia IntraWeb disponvel no Kylix/Delphi 7 isto se tornou possvel sem acarretar em custos extras de desenvolvimento. Esta tecnologia permite que se desenvolva aplicaes para Web da mesma forma que se desenvolve para cliente servidor em duas camadas no Delphi.

5. Arquitetura Proposta
O Sistema Quaestor foi desenvolvido utilizando a tecnologia IntraWeb do Kylix/Delphi 7 para desenvolver um aplicativo que executado sempre via navegador, podendo no entanto estar rodando local ou remotamente. Este aplicativo no requer nenhum tipo de configurao adicional basta execut-lo. Para manter as bases de dados locais, foi escolhido o banco de dados open source Firebird, o que no acarretou em custos extras de licena. O Firebird um banco de dados para aplicaes de pequeno a mdio volume de dados, porm que oferece funcionalidades de programao comparveis aos grandes bancos de dados [Paulson, L. D (2004)]. A operao diria do Firebird bastante simplificada, no necessitando de pessoal com qualificao especfica em banco de dados conhecimentos bsicos de Windows so suficientes para o dia a dia, inclusive para os procedimentos de backup. Nas OMs com conexo intermitente a atualizao dos aplicativos realizada pelo instalador local, que disponibilizado na pgina da DFM/DCoM, e atualizado pelo

operador que comanda a suspenso no sistema remoto. Nas OMs sem conexo com a Intranet a atualizao ter de ser feita via meio digital, atravs de um protocolo de atualizao j definido e testado pela equipe de desenvolvimento. Eventuais atualizaes no esquema da base de dados seguiro o mesmo princpio. Qualquer problema que surja nas bases locais poder ser resolvido remotamente pelo pessoal da DFM/DCoM devido as caractersticas do Firebird: a base de dados constituda de um nico arquivo que pode ser simplesmente copiado para a DCoM/DFM, processado e devolvido para a OM. Para rodar o Firebird e o aplicativo local, a OM tem de disponibilizar uma nica mquina com configurao mnima de PentiumII 350 MHz com 128 Mb de memria principal. Esta configurao, segundo os testes realizados, consegue suportar bem um cliente usando o sistema de forma intensiva. As trs categorias de OMs utilizam a mesma aplicao IntraWeb via navegador. As OMs com conexo permanente no tm necessidade de instalar nenhum software local, acessando remotamente a aplicao que ir ser hospedada em um servidor centralizado na DFM/PAPEM via Intranet. Quanto s outras duas categorias de OMs temos o seguinte: a) para ambas categorias (sem acesso a Intranet ou com acesso intermitente) sempre teremos uma aplicao IntraWeb rodando localmente, com um servidor FireBird tambm local. Esta aplicao IntraWeb ser cpia da aplicao centralizada, sendo atualizada via Intranet ou via meio magntico adequado. b) para as OMs com conexo intermitente foi definido um protocolo de transferncia de informaes a ser executado sempre que for modificado o estado da conexo: suspensa ou conectada. Este procedimento ir garantir a sincronizao das bases de dados. Quando houver conexo, estas OMs acessaro a aplicao centralizada. Quando no houver, utilizaro a sua aplicao local. c) para as OMs sem conexo, o protocolo semelhante, porm a sincronizao de dados ocorre via meio magntico, utilizando o acesso a Intranet de uma OM prxima como ponto de apoio.

OMs com conexo permanente Navegador Web

OMs com conexo intermitente Navegador Web

Aplicao Quaestor (Servidor Intraweb) AMBIENTE LOCAL

Dados de sincronizao da base

Banco de dados Firebird em ambiente PC

Aplicao Quaestor (Servidor Intraweb) PAPEM

Banco de dados Oracle em ambiente mainframe

Dados de sincronizao da base via meio digital

OMs sem conexo

Dados de sincronizao de base via meio digital

Navegador Web

Aplicao Cx. Eco. (Servidor Intraweb) AMBIENTE LOCAL

Banco de dados Interbase em ambiente PC

Figura 1 Arquitetura da Aplicao

5.1

Vantagens da Arquitetura Proposta 1) Uma nica aplicao foi desenvolvida para ser executada local ou remotamente;

A Arquitetura proposta apresenta diversas vantagens. As principais so:

2) Sempre que possvel utilizada a rede interna da MB para o trnsito das informaes; 3) OMs que podem executar a aplicao remotamente no tm necessidade de investimento em pessoal ou hardware, nem necessitam de procedimentos para manter o funcionamento do sistema, tampouco a integridade e segurana das informaes; 4) As OMs que precisam executar o aplicativo localmente iro necessitar de equipamentos com configurao modesta, e os procedimentos para manter o sistema em funcionamento so bastante simplificados, bem como para manter a integridade e segurana das informaes; 5) A maioria das OMs que precisarem executar o sistema localmente faro a transmisso de dados e a atualizao da verso do sistema automaticamente pela rede interna da MB apenas as OMs sem acesso a rede tero de usar o acesso Intranet de uma OM prxima para isto e; 6) A DCoM/DFM tero o controle centralizado e a responsabilidade sobre as bases de dados das diversas OMs que operarem remotamente, e a garantia de dados em formatos padronizados para as OMs que operarem com bases locais. 5.2 Desenvolvimento do Sistema

O Quaestor foi desenvolvido em aproximadamente 4 meses, com uma equipe formada por analistas e programadores da Coppetec e da MB, sendo que os membros da equipe da Coppetec trabalham em meio expediente (20 horas semanais). A modelagem do sistema seguiu o padro UML [Rumbaugh, 1999], o qual foi utilizado para representar as regras de negcio atravs de seus diagramas de casos de uso, atividade e transio de estados [Larman, 1998]. A aplicao foi inteiramente projetada para ser compatvel com ambos os bancos de dados (Oracle e FireBird), e poder ser executada local ou remotamente. Para garantir essa compatibilidade, um conjunto de normas para a escrita de consultas ao banco de dados (SQL) foi criado e usado pela equipe de desenvolvimento. Para padronizar o desenvolvimento da Interface os componentes j utilizados pela equipe da Coppetec no desenvolvimento de outros sistemas na MB, entre eles o Singra, foram portados para o IntraWeb conforme citado em [Zimbro et al., 2003]. Esses componentes encapsulam, entre outras coisas, as seguintes funcionalidades: 1) Cadastro padro para telas simples, com incluso, edio e excluso; 2) Telas de filtro e de busca padronizadas e; 3) Controle de acesso padronizado e configurvel atravs de tabelas armazenadas no banco de dados e; Um mecanismo de sincronizao de dados foi desenvolvido de forma que seja fcil sincronizar as bases de dados periodicamente. O primeiro ponto que os esquemas das bases de dados so rigorosamente iguais, utilizando-se tipos de dados que sejam equivalentes em um banco e outro. Alm disso, cada tabela possui campos para registrar a data de criao do registro e a data de sua ltima atualizao, bem como triggers para manter essas informaes consistentes. Embora esses triggers tenham de ser diferentes para o Oracle e para o Firebird, eles possuem o mesmo formato para cada tabela, sendo

a nica diferena justamente o nome da tabela. Portanto, foi necessrio escrever apenas 4 tipos de triggers diferentes, e simplesmente trocar os nomes das tabelas. As rotinas de sincronizao funcionam da seguinte forma: h um procedimento para a exportao dos dados que foram alterados aps a ltima importao, e um procedimento para importar esses dados. Para suspender a conexo, uma OM deve exportar os seus dados na base centralizada (ela exporta apenas os dados relativos sua prestao de contas atual), e importar esses dados na sua base local. Para retornar ao ambiente centralizado, a OM deve, aps reestabelecer sua conexo com a Intranet, exportar os dados locais que foram criados durante o perodo no qual a conexo ficou suspensa e sincronizar (importar) esses dados na base centralizada. Exceto pelas tabelas que representam relacionamentos muitos para muitos (M:N), todas as tabelas do modelo possuem como chave primria um campo ID do tipo inteiro. Para garantir que no sejam gerados IDs duplicados por duas OMs que estejam suspensas (rodando o banco de dados localmente) adotou-se a seguinte regra de formao para os mesmos: cada ID deve ser gerado de 1000 em 1000, e somando-se um cdigo interno atribudo OM que o gerou, exceto se ele for gerado na base centralizada, quando no se soma nada. Logo, se uma OM possui cdigo interno 23, todos os seus IDs gerados localmente pelo Firebird tero final 023: 1023, 2023, 3023, 4023. J os IDs gerados na base centralizada tero final 000. Dessa forma, nenhuma OM ir gerar um ID que j exista no sistema. 5.3 Implantao do Sistema

O Quaestor foi implantado na MB de acordo com um calendrio de implantao elaborado pela equipe de desenvolvimento que teve como diretriz bsica a reduo de custos para o treinamento e capacitao do usurio, sem comprometer o uso do sistema. Com o objetivo de garantir o uso adequado do sistema, um aprendizado continuado e um acompanhamento dos usurios, as seguintes aes foram tomadas: 1. Elaborao de um manual do usurio em meio digital; 2. Elaborao de uma apostila, com exemplos da gestoria de Caixa de Economias, na qual ilustra passo-a-passo o uso do Quaestor. Este material utilizado durante o treinamento dos usurios; 3. Disponibilizao de uma lista de discusso para todos os usurios do sistema, a fim de permitir o esclarecimento de dvidas, pedidos de suporte, a troca de experincia entre os prprios usurios e a emisso de avisos em geral, etc; 4. Cursos ministrados a cada nova entrada de usurios (OMs) no sistema; 5. Disponibilizao de um ambiente de treinamento, utilizado durante um ms antes da entrada da OM em produo; 6. Elaborao de um vdeo de adestramento de uso do sistema; 7. Elaborao de um curso de aprendizado e reciclagem dos usurios do sistema utilizando Ensino a Distncia (EAD). A implantao do sistema foi dividida em etapas, de acordo com a localizao das OMs, de forma a permitir o treinamento dos usurios e o acompanhamento do ambiente de produo escolhido. A primeira etapa, iniciada em fevereiro de 2004, foi composta pelas OMs piloto (aproximadamente 10) que participaram do processo de

levantamento de requisitos, DFM e DCoM. A segunda etapa contou com a participao das OMs localizadas no 1 DN rea Rio. Em seguida, as outras OMs do 1 DN foram treinadas e includas no sistema. As etapas seguintes foram formadas por OMs de um ou mais distritos, sendo que a ltima etapa ser finalizada em novembro de 2004. 5.4 Manuteno do Sistema

Conforme explicado anteriormente, o sistema foi desenvolvido para ser executado em dois ambientes: local (sem Intranet) e centralizado (acesso Intranet), utilizando o mesmo aplicativo. Para o ambiente centralizado, no h dificuldade na manuteno da aplicao, o mesmo no ocorre para as OMs que executam localmente ou com conexo intermitente. Para as OMs que se encontram sem acesso Intranet, foi desenvolvida uma aplicao parte responsvel pela atualizao do aplicativo, do esquema da base de dados e dos arquivos auxiliares que acompanham o sistema. Esta aplicao acompanha a instalao local do aplicativo, alm de estar disponvel para download pela Intranet. Embora exista uma ferramenta para a atualizao do sistema, foi necessrio criar controles para garantir que as OMs estivessem executando verses atualizadas do sistema. Um destes controles est presente no processo de envio de dados das OMs sem conexo. O sistema verifica a verso do sistema no conjunto de dados a ser sincronizado e impede que os dados sejam sincronizados caso a verso que est sendo executada pela OM for antiga. A garantia da atualizao dos sistemas decorrente da obrigao das OMs de enviarem mensalmente a prestao de contas para a DCoM.

6. Concluses
Esse artigo apresentou uma arquitetura para um sistema capaz de ser executado em dois bancos de dados diferentes, o Oracle e o Firebird. Alm disso, o sistema desenvolvido capaz de ser executado local ou remotamente, possuindo mecanismos de sincronizao de bases de dados. Um nico cdigo fonte foi desenvolvido, o que resultou em uma nica aplicao, diminuindo os custos de desenvolvimento e de manuteno. A interface do sistema a mesma, ou seja, o navegador Web, no importando se o mesmo est sendo executado local ou remotamente. importante ressaltar que o navegador web pode ser tanto o Internet Explorer quanto o Netscape (ou Mozilla compatvel), o que permite que o sistema operacional do cliente seja Windows, Linux ou mesmo MacOS. Os recursos exigidos para que a aplicao rode localmente so modestos, tanto de hardware quanto de pessoal. Mesmo tendo sido criada uma aplicao nica, as OMs que possuem conexo permanente com a Intranet no so obrigadas a instalar nenhum aplicativo. A tecnologia IntraWeb, presente no Kylix 3/Delphi 7, e utilizada para desenvolver o sistema apresentou facilidade de uso semelhante ao desenvolvimento cliente servidor tradicional em duas camadas do Delphi, sendo rapidamente dominada pela equipe de desenvolvimento. Finalmente, possvel portar a aplicao para Linux facilmente, dado que tanto o IntraWeb quanto o Firebird so totalmente compatveis com esse sistema operacional, bastando recompilar a aplicao no Kylix 3.

7. Bibliografia
Larman, C. (1999) "Applying UML and Patterns", Prentice-Hall, 1998 D.C.D. Poo, Events in Use Case as a Basis for Identifying and Specifying Classes and Business Rules, Anais da "TOOLS 29 Conference", Nancy, France, Junho. Paulson, L. D (2004) "Open Source Databases Move into the Marketplace". IEEE Computer 37(7): 13-15. Rumbaugh, J., Jacobson, I., Booch, G. (1999) "The Unified Modeling Language Reference Manual", Addison-Wesley. Zimbro et al., (2003) Uma Experincia de Desenvolvimento Baseado em Componentes, Geraldo Zimbro, Mrcio Duran, Jano Moreira de Souza, Francisco Pereira Neto, Simpsio de Desenvolvimento e Manuteno de Software da Marinha (SDMS), 2003.