Este material tem como objetivo apresentar de maneira didática e simples uma visão da interface gráfica, do sistema de gestão comercial para empresas de saneamento, o GCS.

Aqui serão demonstrados os processos que dizem respeito à interface gráfica que a partir de agora, será referenciada por GUI. Portanto, não entraremos nos conceitos de funcionamento do sistema e sim na estrutura e os pré-requisitos para o seu funcionamento, este será é o nosso objetivo.

· O que é?

A GUI foi desenvolvida para fornecer uma interface gráfica para o sistema de gestão comercial para saneamento, GCS que possui uma interface texto.

· Pré-requisito

Conhecimento na Linguagem de programação Delphi;

Conhecimentos básicos GCS;

Configuração mínima de software (SO) a partir do Windows 95/98;

Microcomputador conectado a rede para acessar o servidor que hospeda o ambiente GCS e a base de dados;

Instalar o QUICK TERM através do plug-in do Java 2 Runtime Environment, o qual será o responsável pela emulação da GUI com o GCS;

Instalar o Cliente Oracle versão 11 e na sequencia configurar o arquivo “tnsnames.ora” com as devidas características para acessar a base de dados.

· Como funciona?

Por ser uma interface, a maioria das telas foram implementadas conforme a funcionalidade do GCS, porém em alguns casos foram desenvolvidas aplicações que não necessitam da interação com o GCS.

Com relação ao acesso as tabelas, a GUI não acessa as tabelas e arquivos que são de uso do GCS. Acessa apenas tabelas e arquivos auxiliares para seu funcionamento localizadas na máquina do cliente no diretório C:\Procenge\GCS \Tabelas;

A GUI roda no sistema operacional Windows e localmente (Desktop);

A GUI comunica-se, em perfeito sincronismo, com o GCS através de um emulador de terminal, chamado QUICK TERM. Quando a GUI estiver em uma determinada tela do sistema, cadastro de usuário, o GCS também estará na mesma tela. Durante a execução da GUI, o GCS estará rodando em segundo plano, transparente aos usuários.

IMPORTANTE: Vale salientar que o cliente não sabe da existência do sistema GCS que roda por baixo da GUI.

A comunicação entre a GUI e o GCS se dá da seguinte forma:

· O usuário preenche sua solicitação em uma tela da GUI e confirma;

· A GUI envia esta solicitação para o GCS;

· O GCS irá processar esta solicitação e devolver uma reposta;

· A GUI, que estava esperando o término do processamento, captura esta resposta e exibe ao usuário;

· Existem algumas aplicações que fazem acesso direto na base de dados, neste caso não necessita da interação com o GCS.

· Delphi 5.0

A GUI foi desenvolvida no Delphi 5.0 (esta requer licença para o uso). No seu desenvolvimento, além dos componentes nativos do Delphi, foi necessário utilizar alguns componentes free tais como: NUMBER EDIT está na paleta MMRTools, CHATFX (Componente Gráfico) está na paleta ACTIVEX, CRPE (Componente Crystal Report) está na paleta Data Access, ou IDFTP (Componente de FTP) está na paleta INDY SERVERS.

Os artefatos que compõem o QUICK TERM responsável pela comunicação entre a GUI e o GCS são:

1- A pasta Tsquickgui composta pelos arquivos da figura;

2- A DLL de nome qgadapter.dll;

E o arquivo GCS.bat responsável em executar a pasta Tsquickgui .

O layout da GUI está definido dentro do seguinte padrão:

Navegador: Através dele podemos acessar todas as telas do sistema. É uma tela padrão herdada por todas as telas do sistema.

Barra de Ferramenta: Esta barra tem por função prover um acesso rápido as telas mais usadas do sistema, facilitando a navegação do usuário. Ela não é customizada e também é igual para todas as telas.

Área de dados: É onde tudo acontece. Nesta área irá conter as telas correspondentes ao GCS, interagindo com o usuário na troca dos dados.

Mensagens do GCS: Local que irá informar após uma ação na GUI, a resposta do GCS.

O produto possui uma arquitetura definida em três partes:

1. O Código Delphi: É a interface de comunicação usuário – GUI;

2. Emulador QUICK TERM interface de comunicação GUI – GCS;

3. O GCS: É o sistema de gestão comercial que está rodando, em segundo plano.

Para termos uma ideia de como isso tudo se engrena, vamos fazer uma simulação de uma transação qualquer.

TELA GUI

Primeiro o usuário preenche os campos da GUI, confirmamos no OK e a GUI irá enviar para o GCS as informações.

TELA GCS

Caso não haja nenhum problema na validação dos dados, o GCS irá pedir a confirmação desta alteração. Observe que durante este processo de validação, a GUI fica em espera até que seja devolvida uma resposta, a partir daí as informações serão atualizadas de acordo com o GCS. É muito importante observar que deve haver um perfeito sincronismo entre as duas partes.

Cada máquina cliente deverá conter uma cópia da GUI instalada localmente e o emulador QUICK TERM ambos ficaram no diretório c:\Procenge\GCS.

Segue a estrutura na figura a baixo

· INTERFACE: A interface foi desenvolvida baseada no padrão Windows e possui uma série de procedimentos e funções próprias. Toda nova tela deverá ser herdada de uma das três telas padrão, incorporando, assim, todas as funções e procedimentos já prontos e funcionando. Também não iremos mais nos preocupar com o desenho da tela, nos preocupando apenas com a área de dados.

1- É disponibilizada uma versão com as modificações em uma máquina de teste localizada em Araraquara para que o cliente possa validar;

2- Caso não seja validado, o cliente informa a fábrica e a versão retorna para que seja feita as devidas correções;

3- Uma vez validado é disponibilizado em produção;

4- O usuário ao acessar o sistema irá atualizar automaticamente, detalhe isto é algo transparente para o cliente.

Detalhamento do processo de atualização da GUI:

a- Existe um arquivo de nome atualização.ini do tipo .doc, nele iremos informa o que será atualizado na versão ex : GCS.exe, tabelas, RPT;

b- No arquivo mencionado, é feito uma marcação com “X” informando o que deve ser baixado (atualizado), além disso temos que disponibilizar no servidor de produção no diretório /proj/araprd/gui/atualizador o arquivo propriamente dito ex: GCS.exe. As informação da Versão, DataGeracao e DataAtualizacao a informação nestas duas datas obrigatoriamente tem que ser maior que a data da última atualização.

Segue ilustração

c- Uma vez disponibilizado o arquivo em produção, ao ser startada a primeira ação tomada pela GUI é chamar um outro aplicativo de nome atualizador.exe, este é quem se encarregar de realizar a atualização, este processo é feito através da comparação da informação das DataAtualizacao existente nos arquivos Atualizacao.ini (no servidor) e Iniprocenge.ini (localmente). A pergunta que é feita é : DataAtualizacao (Atualizacao.ini) > DataAtualizacao (Iniprocenge.ini) se SIM atualiza;

d- Ao termino da atualização é aberto o leiame.txt informando o que foi atualizado na versão.