Autor: Frediani Bartel - GPS


Atualmente, há uma grande demanda pela construção de aplicações na Internet. Há pouco tempo existiam na WEB, na sua grande maioria, documentos estáticos (páginas em html) com dados institucionais. Hoje já é bastante comum os sites conterem páginas html e também aplicações que disponibilizam informações obtidas em tempo real e em conformidade com a consulta do usuário.

É perfeitamente possível a construção de aplicações que alimentem um banco de dados, além de recuperar as informações existentes nele. Porém, é preciso fazer algumas ressalvas sobre estas aplicações para WEB, sobre as suas limitações atuais, a comparação com outras soluções tecnológicas, etc.

Diferenças entre aplicações para Internet e aplicações Win32

A grande maioria das aplicações atualmente disponíveis no mercado são as aplicações Win32 (as tradicionais aplicações "for Windows"). Elas utilizam as API’s (Aplication Program Interface) do Windows e o próprio kernel do sistema operacional. Isso possibilita que uma aplicação tenha uma interface bastante elaborada e sofisticada. Entre elas podem ser citadas as desenvolvidas com Access, Delphi e Visual Basic.

Quanto às aplicações para Internet, apesar de terem uma interface gráfica, esta não é tão sofisticada como a de uma aplicação Win32. A interface da aplicação está adstrita aos recursos disponibilizados pela linguagem HTML e pelo navegador utilizado pelo usuário da aplicação. Evidentemente existem outras grandes diferenças entre estes dois tipos de aplicações, como, por exemplo, a inviabilidade de se criar conexões persistentes entre a aplicação WEB e o Banco de Dados. Porém, a que causa maior impacto para o usuário final é a interface imposta pela WEB.

Dicas para projetar aplicações para Internet

Há algumas assertivas que precisam ser observadas no projeto de uma aplicação WEB.

Já no início do projeto deve haver a preocupação com a interface da aplicação. Quando se projetam as telas para uma aplicação Win32 muita coisa pode ser feita numa tela só. Numa aplicação Internet isso pode e tem que se desdobrar em várias telas.

Neste exemplo de aplicação Win32, quando o usuário seleciona uma Unidade da Federação, tal evento dispara uma consulta no banco de dados, que retorna para a mesma tela, a relação dos respectivos municípios. O usuário entra com os demais dados e após clicar sobre o botão gravar, a tela será limpada exibindo alguma mensagem que a informação foi gravada.

Como ficaria esta mesma tela numa interface para WEB? Ela teria que se desdobrar em pelo menos três telas, como pode-se observar na ilustração seguinte. Na primeira tela, o usuário deve selecionar a Unidade da Federação e quando for clicado no botão Avançar, estará sendo chamada a próxima tela. Antes de ser exibida a segunda tela, é disparada uma consulta no banco de dados, que retorna os dados necessários (os municípios respectivos) para que então se exiba a tela. Sendo exibida a segunda tela, o usuário seleciona então o município, preenche os demais dados e ao clicar em gravar, as informações serão gravadas no banco de dados quando o código da última tela estiver sendo interpretado e executado pelo servidor. Então, são exibidos os dados para o usuário.

Percebe-se que, se eventualmente o usuário quiser mudar de Unidade de Federação na segunda tela, ele deverá reiniciar a alimentação de dados desde a primeira tela. Isto se deve ao fato que somente no momento em que é carregada a primeira tela é que ocorre a consulta das Unidades da Federação no banco de dados.

Não existe confrontação dos dados que estão sendo exibidos com os do banco de dados, sem mudar de tela. Este processamento e transação só ocorrem na mudança de tela. A interação com os dados é semelhante a de uma aplicação desenvolvida em Natural no Mainframe.

O usuário final tem que ter prévio conhecimento de que a interface da aplicação vai ser diferente, para que não se crie a expectativa de que o usuário terá na Web uma aplicação com a mesma interface de aplicações Win32.

Numa aplicação para Internet, o mouse é essencial na interface. Não são utilizadas teclas de atalho numa aplicação Internet.

Quanto mais sofisticada for a interface da aplicação para Internet, mais dependente da versão do browser ela ficará.

A interface do browser ainda é bastante limitada e a dificuldade é perceptível inclusive nos sites mais conhecidos da Internet. Enfim, por enquanto não há uma solução ideal de interface de uma aplicação Internet, que satisfaça plenamente às expectativas dos usuários.

O comportamento do ambiente Internet não é tão estável (hardwares e softwares heterogêneos, instabilidade, congestionamentos na rede, etc.) como o de uma rede local. Disso decorre que o banco de dados tem que estar muito bem projetado pois, com certeza, existirão transações incompletas.

O que atrasa o desenvolvimento de uma aplicação para Internet? O que fazer para agilizar o desenvolvimento?

Já vimos que uma tela de uma aplicação Win32 se desdobra em várias telas na aplicação Internet e isto acarreta um maior tempo no desenvolvimento. Em cada tela, as consistências de tipos de dados são feitas em JavaScript. Apesar de existirem ferramentas que geram o código JavaScript para diferentes necessidades, a verdade é que sempre existem rotinas que devem ser implementadas manualmente. Numa ferramenta de desenvolvimento de aplicação Win32, basta clicar com o botão direito do mouse e informar a máscara, tipo de dado, etc., que a tela já estará validando corretamente a alimentação de dados.

O Banco de Dados tem que ser quase perfeito. "A ocorrência de dados numa tabela tem que ser tão uniforme que não existam campos nulos". Os dados de uma tabela têm que ser uniformes e devem obedecer às mesmas regras. Apesar de estas recomendações serem uma verdade em qualquer tipo de aplicação, se estas não forem seguidas, podem inviabilizar a construção de uma aplicação na Internet. Por exemplo: armazenar histórico na mesma tabela que contém os dados é uma heresia. Em comparação com o desenvolvimento de uma aplicação Win32, o programador que desenvolve para WEB dispõe de menos recursos para superar eventuais atropelos no modelo físico do banco de dados.

Nunca se deve esgotar os recursos já na fase de análise. Artimanhas já na análise esgotam as habilidades do programador. As rotinas vislumbradas pelo analista têm de ser de implementação simples e as dificuldades de implementação devem ser resolvidas já na fase de análise. Deve-se deixar para a fase de construção da aplicação a utilização de artifícios ardis.

Para ilustrar tal situação, vejamos o exemplo a seguir.

Ambos os modelos de dados são uma proposta para armazenamento de dados de empréstimos efetuados numa biblioteca e o histórico dos empréstimos já efetuados e devolvidos dos leitores.

No primeiro modelo, os dados do empréstimo e do histórico são armazenados na mesma tabela. A diferença entre um registro de dados históricos e um registro de empréstimo pendente de devolução, é que naquele (histórico), o campo DATADEVOLUCAO é uma data válida e neste, o campo contém um valor nulo (NULL). Aparentemente este modelo resolve o problema, mas na verdade ele traz uma série de dificuldades e trabalho excessivo para o desenvolvedor. Neste modelo, fica mais difícil controlar a duplicidade de registros na tabela de empréstimos e as regras aplicáveis à tabela EMPRESTIMO têm de ser mais brandas. A recuperação da informação também é mais confusa e mais lenta, já que a tendência neste modelo é que exista um pequeno número de registros de empréstimos pendentes de devolução em relação ao número de registros do histórico, todos eles numa única tabela. Na implementação, o desenvolvedor tem a possibilidade de implementar, no banco de dados, stored procedures (um pouco mais complexas) que tratem adequadamente os dados, ou então, implementar rotinas na aplicação (na camada de regras de negócio) que tratem estes dados. Enfim, o problema terá que ser resolvido pelo desenvolvedor.

Já no segundo modelo, a tabela EMPRESTIMO contém apenas dados dos empréstimos pendentes de devolução. Neste caso, pode-se definir como chave primária os campos CODLEITOR e CODLIVRO e, conseqüentemente, há restrição quanto aos registros dúplices. Quando for efetuada a devolução do livro, o registro é apagado na tabela EMPRESTIMO e inserido na tabela HISTORICO. É possível a implementação de regras bem rígidas para a tabela EMPRESTIMO dentro do próprio sistema gerenciador de banco de dados. Neste modelo, grande parte dos problemas foram resolvidos na modelagem de dados, agilizando a construção do sistema. O programador não terá de se preocupar em criar rotinas para tratar de maneira correta os dados armazenados. O sistema gerenciador de banco de dados impedirá que qualquer aplicação ou rotina mal feita deixe os dados inconsistentes.

Conclusão: os problemas foram resolvidos já na fase de análise.

Numa aplicação Internet, tem-se pouco controle do que acontece na máquina do usuário final. A melhor alternativa para se construir uma aplicação confiável é a construção de um banco de dados a prova de qualquer falha.

Terminada esta abordagem sobre o banco de dados restam outros dois detalhes que também devem ser observados.

A WEB tem fama de ser uma mídia nova para novos artistas. Mas, programação visual sofisticada numa aplicação, atrapalha e atrasa o desenvolvimento.

Muitos interlocutores no desenvolvimento de aplicações também atrasam. O ideal é ter um único analista mantendo contato com o cliente e intermediando com a equipe de desenvolvimento.

O que é ASP? O que é uma linguagem "script"?

Active Server Pages é uma tecnologia da Microsoft para construção de aplicações na Internet. Uma página ASP é uma rotina da aplicação. É um arquivo que contém código HTML, JavaScript e Visual Basic Script.

Visual Basic Script e JavaScript são linguagens que são interpretadas por outro programa. Seus códigos não são compilados. Essas linguagens (scripts) são largamente utilizadas na Internet. Na CELEPAR, optamos por utilizar Visual Basic Script para as rotinas que são interpretadas pelo servidor WEB e JavaScript para as rotinas que são interpretadas pelo navegador (browser) do usuário.

Portanto, no caso da CELEPAR, as aplicações ao serem utilizadas, têm dois momentos distintos:

*

Na mudança de tela (ao carregar uma página ASP) o código Visual Basic Script é interpretado pelo servidor, disparando consultas e atualizações no banco de dados, quando necessárias. Tudo isto é processado por computadores remotos, não do usuário.

*

Ao clicar em algum elemento visual da tela no browser, como por exemplo um botão "OK", o usuário poderá estar disparando rotinas JavaScript, que farão a validação e checagem de alguns campos na tela. Mas, neste momento, nada acontece no servidor.

Desvantagens de uma solução Internet

Houve uma involução na interface das aplicações. Interface Win32, que desde os primórdios do Windows vem sendo aprimorada, é indubitavelmente melhor do que interface na WEB, que está há poucos anos sendo utilizada.

As restrições da interface forçam o desdobramento de uma tela em várias. O uso da aplicação é mais enfadonho.

Telas com interfaces sofisticadas, gráficos complexos, drag and drop, quase inexistem na WEB. Elas até podem ser implementadas, mas exigem um grande desforço para isto e exigem a instalação de pluggins no navegador (browser) do usuário final.

A estabilidade do ambiente Internet está melhorando dia-a-dia, mas uma aplicação numa rede local ainda é mais estável.

Vantagens de uma solução Internet

Uma aplicação para Internet pode ser acessada de qualquer lugar do mundo. Evidentemente que isto quase sempre não é uma necessidade. Mas no caso de consultas a bases de dados é interessante. Outrossim, nenhuma outra tecnologia viabiliza isto.

Não há necessidade de se distribuir e instalar a aplicação nos computadores do usuário. Ela pode ser facilmente alterada sem provocar transtornos aos usuários. Feita a atualização da aplicação, ela imediatamente passa a ser utilizada na nova versão por todos os usuários.

A atualização do banco de dados é feita em tempo real.

Disponibilização de dados ao público é mais fácil. Quando a aplicação foi desenvolvida para uma Intranet, fica bastante simples de se disponibilizar consultas aos usuários da Internet, sem grande esforço da equipe de desenvolvimento.

Soluções na Internet descentralizam a alimentação de dados. Mesmo que a interface da WEB seja mais lenta e enfadonha do que a de uma aplicação convencional, o fato é que a aplicação pode ser utilizada por qualquer ponto de acesso à Internet. Isto possibilita que a alimentação de dados seja feita por diferentes usuários em locais geograficamente distintos e longíquos.

A interface na WEB é intuitiva. O esforço dispendido para se aprender a usar uma aplicação Internet é menor.

A princípio, uma aplicação feita para rodar na Internet, é independente da configuração do computador utilizado pelo usuário final. Isso não é uma verdade absoluta, mas é muito mais fácil construir uma aplicação com essas características no ambiente WEB do que uma aplicação Win32.

Sistemas inviáveis na Internet

Existem sistemas que, por enquanto, são inviáveis de serem construídos ou convertidos para serem utilizados na Internet. Sistemas com interface excessivamente elaborada oferecem muitas dificuldades para serem construídos. Só tornam-se possíveis com um prazo prolongado e, mesmo assim, corre-se o risco de não atenderem às expectativas do cliente. O mesmo acontece com sistemas em que a alimentação de dados tem de ser extremamente rápida, com teclas de atalhos e confrontação imediata dos dados do formulário com o banco de dados.

Os sistemas que exigem relatórios complexos também oferecem dificuldades. O browser não é um gerador de relatórios e a implementação destes numa aplicação para Internet é feita manualmente.

Soluções híbridas

Quando uma aplicação exige telas para uma alimentação rápida dos dados e a confrontação imediata destes com a base de dados, pode-se fazer este aplicativo Win32 e as consultas com a interface WEB. Grande parte dos usuários está interessado apenas na consulta aos dados. A alimentação destes é realizada por outro conjunto de usuários bem mais restrito. Não há empecilho algum em se construir aplicações nestes moldes.

Qual versão de navegador (browser) utilizar?

Já foi dito que quanto mais sofisticada for a interface da aplicação para Internet, mais dependente da versão do browser ela ficará. Quando os usuários do sistema são um número determinado e restrito de pessoas, pode-se implementar a aplicação visando a sua utilização numa única versão de browser. É importante, no levantamento de dados considerar tal aspecto, para, no momento oportuno, definir qual browser será utilizado.

Quando a aplicação será utilizada por pessoas não determinadas e em número não definido, é previsível que estes utilizem as diferentes versões de navegadores disponíveis no mercado. Para se construir uma aplicação que atenda a estes requisitos é importante que os testes sejam feitos em diferentes versões de navegadores.

Conclusão

Não era objetivo deste artigo exaurir todas as questões concernentes ao desenvolvimento de aplicações para Internet. Muitos outros detalhes teriam de ser abordados quando da utilização de outras tecnologias. E, também, muitos dos problemas encontrados no desenvolvimento de aplicações Internet são resolvidos com o simples cumprimento dos velhos preceitos de análise de sistemas.