Uma aplicação simples de demonstração

> Interface única a caractere - Geração e Execução

< Caracteristicas gerais da solução proposta

Migração de Aplicações para Ambiente Web - Uma Abordagem Prática

Uma aplicação simples de demonstração

Para exemplificar o que foi dito até o momento, a seguir apresenta-se um modelo ilustrativo. Trata-se de um modelo de aplicação com condições operacionais que possui apenas algumas opções, compondo os requisitos básicos para que o usuário possa interagir com o sistema, portanto, não tem nenhuma utilização prática, exceto o objetivo de demonstração. Incorpora o conceito de desenvolvimento em três camadas, sendo que a camada de interface possui um elemento comum para todos os módulos.

O sistema, “Controle de Clientes” contém os módulos: “Cadastro de Clientes”, “Atendimento a Clientes” e “Parametros do Sistema”. Os módulos são executados a partir de um menu de opções também chamado de “Controle de Clientes” com as seguintes informações básicas para cada módulo, conforme apresentado na tabela 2:

Tabela 2 – Tabelas do sistema

Clientes

Telefone

Nome

Endereço

Atendimento

Data

Telefone

Ocorrência

Parâmetros

Nome

Cnpj

Endereço

Com o intuito de materializar o proposto, foi criado um protótipo, baseado em um conjunto de scripts em Bash (fontes podem ser obtidos enviando e-mail para netmorais@ig.com.br), agrupados pelos seguintes prefixos: app_, elementos da aplicação; srv_, serviços para a aplicação e tmp_, informações temporárias, com distribuição dos módulos em camadas, conforme apresentado na tabela 3:

Tabela 3 – Distribuição dos módulos em camadas

A terceira camada, a interface, é comum para todos os módulos e é executada por um serviço, nomeado como srv_interface.sh, conforme apresentado na figura 7. Observa-se neste esquema a utilização da terceira camada, a de interface, e adicionalmente a visão de que a esta se desmembra em outro conjunto, que recebe solicitações das aplicações e as trata de acordo com cada ambiente. Fica claro que o processo é totalmente transparente para a aplicação, esta apenas solicita à interface, por meio de um protocolo pré-estabelecido, o que quer, não é de sua responsabilidade o como deve ser feito.

Figura 7- Interface comum para os módulos

Visualizando a distribuição de camadas do ponto de vista de um módulo e utilizando, por exemplo, o Cadastro de Clientes, observa-se as três camadas conforme apresentado na figura 8:

Figura 8 - Camadas para o cadastro de clientes

A seguir alguns trechos de código que esclarecem melhor o funcionamento da aplicação, e para isso continuaremos com o módulo Cadastro de Clientes. Todos os outros módulos seguem os mesmos padrões gerais.

No Cadastro de Clientes a camada de acesso aos dados é executada por app_cadastro_cliente_dado.sh, que tem por função providenciar o acesso às bases, conforme trecho exibido na figura 9. Na verdade, não é objetivo deste artigo a camada de acesso aos dados, para maiores detalhes sobre este assunto veja: Acessando Banco de Dados - Mysql e Postgresql. Trata-se apenas de uma simulação na qual se atribuí valores às variáveis a serem utilizadas pelos outros módulos, [linhas 4 e 5]. Porém fica clara a posição onde podem existir os “reads”, os “selects”, enfim, o ponto do sistema onde se faz acesso aos dados.

Figura 9 – Módulo app_cadastro_cliente_dado.sh

Em seguida, apresenta-se a camada de regras de negócio que é executada por app_cadastro_cliente_negocio.sh. De acordo com o script da figura 10, as regras de negócio são verificadas em quatro pontos distintos; o retorno de valores editados, [linhas 5 e 6]; a validação das as informações, [linhas 8 a 11] com eventual mensagem de erro, como por exemplo, “erro=Informe nome”, [linha 9], caso seja necessário, e finalmente caso não haja erro, o seu aceite, “info=Cliente alterado”, [linha 13].

Figura 10 - Módulo app_cadastro_cliente_negocio.sh

Na seqüência a camada mais externa da aplicação, responsável por fazer referência ao acesso aos dados, regras de negócio e informações do “protocolo” para a camada de interface. Trata-se do módulo app_cadastro_cliente.sh com segmento do código exibido na figura 11. Conforme pode ser observado, as variáveis do “protocolo” da interface são iniciadas, com os títulos da tela, [linhas 14 e 15], os nomes dos campos, [linha 17], os tamanhos dos campos, [linha 19], seus valores iniciais, [linhas 21 e 22], e finalmente, com os textos de prompt, [linhas 24 e 25].

Figura 11 - Módulo app_cadastro_cliente.sh - variáveis

Finalmente na figura 12 ilustra-se a chamada efetiva da interface e seu controle pelo módulo da aplicação. Observa-se que esta seqüência atribui o padrão de edição tipo “cadastro”, [linha 27], seguido pelo laço, [linha 29], que chama a interface para a execução de edição, [linha 31] e em seu retorno, caso a tecla de “escape” tenha sido pressionada encerra, [linha 33]. Porém se houver confirmação por parte do usuário com o uso da tecla “enter”, valida a informação, [linha 35], por meio da chamada “consiste” do módulo de negócio já exemplificado, retornando ao laço.

Figura 12 - Módulo app_cadastro_cliente.sh – interface

No que diz respeito à aplicação propriamente dita, todos os pré-requisitos para o seu funcionamento foram atendidos. Passa-se agora a detalhar o serviço de interface comum utilizado por todos os módulos.

> Interface única a caractere - Geração e Execução

< Caracteristicas gerais da solução proposta

Migração de Aplicações para Ambiente Web - Uma Abordagem Prática