Desenvolvimento de Aplicações para Internet
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.
Autor:
Frediani Bartel - GPS