Maker 1/3 – Modelagem de Bancos de Dados

Teoricamente, quem desenvolve sistemas com o Maker não precisa se preocupar com
linguagens de programação (exceto se precisar de funcionalidades das quais a
ferramenta não dispõe nativamente), Projeto Orientado a Objetos, Hibernate, CSS,
Tomcat, javascript … bom, javascript é bom conhecer sim!

Todavia, engana-se quem acha que o Maker faz milagres e que não é necessário saber
programar e aplicar com profissionalismo as técnicas da programação estruturada. Da
mesma forma, quem acha que pode desenvolver um bom sistema, mesmo que seja
pequeno, criando tabelas com o wizard do Maker (aquele que sugere a criação de
estruturas no banco quando se posiciona componentes numa tela sem campo associado),
pode enfrentar sérios problemas. Esta série de postagens, dividida em três partes, visa
discutir acerca das boas práticas que se devem adotar nos processos de modelagem de
bancos de dados, programação com fluxo e planejamento de telas, neste post daremos
ênfase em Bancos de Dados.

Dentre os diversos pontos que podem ser analisados com relação à modelagem do
banco de dados deve-se dedicar uma atenção especial no que diz respeito à
normalização. A aplicação correta dos conceitos de normalização evita redundâncias
nas tabelas, facilitando a manutenção e a integridade dos dados.

Uma boa prática no processo de modelagem de dados é a organização semântica do

conteúdo das tabelas. Não é produtivo ter uma tabela com muitos campos
(arbitrariamente falando, mais de 50), mesmo que o modelo esteja respeitando as
FN’s(Formas Normais). Uma grande quantidade de campos dificulta a identificação e
abre margem para ambiguidades, pois podem existir campos com nomes parecidos e
finalidades totalmente díspares. Da mesma forma, não é interessante ter tabelas muito
parecidas, com parte dos campos em comum, pois acaba provocando retrabalho e
replicação de consultas que poderiam ser genéricas.

Por estes motivos, os conceitos de Generalização e Especialização podem ser aplicados

de forma a organizar os dados referentes a uma única entidade que contenha muitas
informações a ela associadas. Considere como exemplo um sistema de Gestão Escolar,
para o qual é preciso cadastrar Funcionários, Alunos e Professores, visto que, essas
entidades podem ser generalizadas pela entidade Pessoa, é útil criá-la para armazenar os
dados comuns a todas as pessoas, tais como: Nome, CPF, RG, sexo, data de nascimento,
etc. Além disto, para armazenar os dados de cada especialização da entidade Pessoa será
necessária uma tabela, neste caso, três: Funcionário, Aluno e Professor, cada qual com
seus dados específicos.

Entretanto, como contra exemplo, utilizar uma única tabela para armazenar os dados das
entidades citadas torna a tabela confusa e de difícil manutenção, pela dificuldade de se
reconhecer quais dados dizem respeito a qual entidade, uma vez que a quantidade de
campos sempre tende a crescer. Tarefas simples como listar os dados dos alunos pode-se
tornar um problema com uma estrutura de tabelas com tais problemas semânticos.

1
Tratando-se de sistemas que sofrem atualizações sob demanda, essas questões que
envolvem a estrutura do modelo de dados são ainda mais críticas, pois nem sempre é
possível analisar o modelo com tempo e condições adequadas, devido a pressões do
cliente, prazos curtos , urgências ocasionais ou simples desleixo do responsável pelo
BD. Por isto é necessário estar atento às questões de modelagem sempre que possível,
fazendo reestruturações e ajustes, para que o sistema não só funcione, mas que esteja
bem feito e seja de fácil entendimento. O fato de ser possível fazer alterações de forma
muito veloz nos sistemas desenvolvidos com o Maker acaba se tornando um fator
preocupante, visto que, as questões de projeto podem se tornar secundárias frente ao
ímpeto de resolver os pedidos dos clientes com agilidade.

Um mecanismo muito útil para se trabalhar no Maker é o uso de views. Freqüentemente,

num sistema, ocorrerá a necessidade de se consultar determinadas informações, em tela,
em relatórios e em fluxogramas. Centralizar estas informações numa única view facilita
a manutenção, pois basta alterar a consulta da view para que todos os artefatos que a
utiliza estejam atualizados, evitando assim que seja necessário realizar uma mesma
correção em diversos pontos do sistema, isso se o desenvolvedor lembrar de todos eles!
Falando em Maker, a utilização de views desta maneira pode significar que, se um
cliente pede uma alteração em um determinado dado de um relatório, basta alterar na
view que estará pronto, portanto você não precisará exportar .frz, fazer acesso remoto e
alterar o relatório, entrar em modo de projeto, recarregar telas, limpar cache, etc. O
ganho de produtividade com técnicas como esta permite que se atenda mais clientes, e
que se tenha tempo para se dedicar à estrutura do projeto, principalmente do banco.

Logicamente, a criação das views deve ser um processo bem elaborado, deve-se
identificar quais consultas são acessadas em mais de um ponto do sistema, e quais
consultas podem servir de base para a realização de outras. Aquelas que realizam
cálculos muito pesados devem ser evitadas para não sobrecarregar o banco e congelar os
recursos do BD. No caso de haver uma real necessidade de views complexas, é mister
elaborar mecanismos para otimizar rotinas, como transações de curta duração e
atualizações fragmentadas, que, nos termos do Maker, significa, usar “cliente chamando
servidor” (para realizar atualizações muito grandes que travariam o banco) de forma
fragmentada, usar a função Executar SQL sem transação, etc.

Para finalizar, não adianta reclamar do Maker sem tentar buscar formas de otimizar o
trabalho. Seja qual for a tecnologia, a organização da estrutura do projeto sempre vai
impactar de forma crítica a capacidade de mantê-lo e alterá-lo. Como foi dito no
começo do tópico, no caso do desenvolvimento ser em Maker, não é necessário se
apegar às linguagens, nem aprender diversas tecnologias, mas a qualidade do Banco de
Dados e a forma como o mesmo é utilizado é decisiva para o sucesso do projeto. Da
mesma forma, a aplicação de práticas conhecidas de programação no ‘fluxo’ e uma boa
prototipagem de telas possibilita ao desenvolvedor manter o sistema de forma mais
produtiva, mas estes serão temas de outras postagens, até lá.

2
 Maker 2/3 – Programação com Fluxo

Este é a segunda parte de uma série de três postagens abordando o tema ‘Boas práticas
com o Maker’. Neste post será abordada uma série de práticas que podem ser aplicadas
à programação com fluxos com o objetivo de aumentar a produtividade do processo de
desenvolvimento com o Maker.

Um ponto importante a ser discutido é a questão da nomenclatura dos fluxos. É

importante que se defina um padrão para nomeá-los, principalmente pela flexibilidade
que é permitida pelo Maker, como uso de espaços, acentos, cedilha, etc. É permitido
ainda que os fluxos sejam categorizados, cada categoria é criada como uma pasta,
obedecendo a uma hierarquia. No entanto, a utilização dessas categorias na localização
dos fluxos não é muito prática, visto que, na tela principal do maker, essa estrutura de
pastas e fluxos é exibida como uma TreeView totalmente expandida, o que de maneira
prática equivale a uma grande lista com todos os fluxos. Desta forma, para conseguir
localizar um fluxo com esta interface é necessário saber seu nome por completo ou pelo
menos parte dele, e utilizar o operador ‘%‘ para tal da seguinte forma: ‘%contendo’
como mostra a Figura 1. À esquerda pode-se ver a lista de fluxos na tela do Maker, e à
direita está a lista de fluxos no momento da seleção de um sub-fluxo, o filtro de fluxos
pelo nome em ambas se dá da mesma forma.

Figura 1 - Exemplo de localização de fluxos com o uso do operador %

Uma boa prática de nomenclatura dos fluxos é utilizar o modelo ‘Módulo do Sistema’ –
‘Nome da Tela’ – ‘Objetivo do Fluxo’, por exemplo: ‘Vendas – Pedido de Venda –
Calcular Total’. Fazendo desta forma, evita-se criar fluxos com nomes repetidos ou
muito parecidos, que dificultem a identificação de sua funcionalidade, sendo necessário
abri-lo e analisá-lo para saber. Por exemplo, em um sistema comercial, podem existir
diversos fluxos chamados ‘Calcular Total’, de modo que se torna indispensável fazer
essa distinção pelo nome.

Outra questão a ser discutida é o planejamento do sistema voltado para a criação de

fluxos reutilizáveis. Por isto, o conceito de Modularização da programação estruturada
deve ser observado e aplicado. É importante que os fluxos criados possuam escopo bem
delimitado, para facilitar a manutenção e a utilização destes. Por exemplo, em um
3
sistema de vendas, tem-se um fluxo chamado: ‘Vendas – Pedido de Venda – Calcular
Totais’, este fluxo é composto por uma consulta ao banco de dados para obter os totais
desejados, gravá-los no banco e atualizá-los na tela. Se, posteriormente, for necessário
fazer uma validação qualquer nesta tela, para que não se calcule os totais se o pedido
estiver liquidado, é interessante que se crie outro fluxo, chamado: ‘Vendas – Pedido de
Venda – Validação’, em vez de fazer a validação no mesmo fluxo que calcula. Isto
mantém o sistema organizado, facilitando a manutenção, a detecção de erros e permite a
reutilização. Vide Figura 2.

Figura 2. Exemplo de Modularização com Fluxos

No processo de desenvolvimento com o Maker existem regras ou operações que

eventualmente vão se repetir nas diversas telas do sistema, como por exemplo:
exibir/ocultar componentes, atualizar componentes, habilitar/desabilitar componentes,
gravar arquivo em disco, validar email, validar preenchimento de campos, etc. Tome
como exemplo um cadastro de pessoa, onde, a depender do tipo da pessoa, física ou
jurídica, o sistema necessite exibir os campos corretos de acordo com o tipo
selecionado. Veja nas figuras abaixo, três formas de resolver este problema. Na Figura
3, os componentes são exibidos ou ocultados com processamentos independentes, sendo
que, para quatro componentes em tela, serão necessários oito processamentos, fazendo
desta forma. Na Figura 4, utiliza-se um sub-fluxo que recebe uma lista de componentes
por parâmetro, separados por vírgula, e um campo do tipo lógico, então intera-se sobre
esta lista, e cada componente é exibido ou ocultado, a depender do valor do campo
lógico. Desta forma, utilizando um fluxo genérico, são necessárias apenas quatro sub-
fluxos, ou apenas dois se a comparação ‘O Tipo de Pessoa é Física?’ for colocada direto
na passagem de parâmetros para o sub-fluxo, como mostra a Figura 5. As soluções
apresentadas pelas figuras 4 e 5 podem ser utilizadas para uma quantidade indefinida de
componentes com alteração apenas nos parâmetros para os sub-fluxos.

4
Figura 3 - Exemplo de fluxo para Mostrar/Esconder componentes feito de forma não reutilizável.

Figura 4 - Exemplo de fluxo para Mostrar/Esconder componentes feito de forma reutilizável .

5
Figura 5 - Exemplo de fluxo para Mostrar/Esconder componentes feito de forma reutilizável e compacta.

A reutilização de fluxos pode-se dar ainda quando se tem um mesmo conjunto de fluxos
usado para manipular diversas telas com finalidades próximas e que manipulam os
mesmos componentes, fazendo-os, aparecer, desaparecer, efetuar cálculos etc. Por
exemplo, considerando um cadastro de pessoa num sistema de vendas, pode ser desejar
criar uma tela que só mostre clientes, outra só para fornecedores, outra para
transportadoras, etc. Todavia, todas estas telas deverão compartilhar a mesma
funcionalidade citada no parágrafo anterior, de exibir/ocultar componentes a depender
do tipo da pessoa, física ou jurídica. Desta forma, é útil garantir que os nomes dos
componentes sejam iguais nas telas que executam o mesmo fluxo, para que a
reutilização seja possível.

Ainda neste contexto, outro exemplo de fluxo útil para promover a reutilização é aquele
que retorna o código ou GUID do formulário corrente. Algumas funções precisam do
código do formulário para ser executadas, dentre elas as muito utilizadas: “Alterar Valor
do Componente“ e “Obter Valor do Componente”. Por isto, no caso de haver
necessidade do uso de tais funções em fluxos compartilhados por mais de um
formulário é possível criar um fluxo que obtenha o código do formulário corrente, ou
seja, o código do formulário a partir do qual o fluxo em execução foi chamado, com a
função ‘Obter ID do Formulário’, recebendo como único parâmetro o retorno da função
‘Obter Formulário Atual’, ambas disponíveis nativamente no Maker.

Para finalizar, a produtividade com o Maker pode ser seriamente comprometida se a

estrutura da sua aplicação não for planejada de modo que facilite a
manutenção/evolução do sistema. A organização dos fluxogramas é parte fundamental
desta estrutura, pois são eles que armazenam as regras de negócios agregadas à solução
proposta ao cliente.

Maker 3/3 – Criação de Formulários

6
Esta é a última parte de uma série de posts abordando o tema Boas Práticas com o
Maker. Na primeira parte falei sobre modelagem de bancos de dados, na segunda parte
falei sobre programação com fluxos. Neste post falarei sobre criação de formulários,
dando algumas dicas de como otimizar o trabalho utilizando os recursos do Maker
através de técnicas e uso dos recursos disponíveis.

Quando se está começando a desenvolver um módulo de um sistema ou mesmo um

pequeno sistema, é inevitável passar por uma etapa de criação de telas de cadastros
simples, geralmente são tipos, status, categorias, etc. Para esta tarefa é interessante
utilizar a funcionalidade de criação de Múltiplos Formulários (veja a documentação
aqui), já que se trata de telas que não irão sofrer muitas alterações de layout, sendo telas
para edição simples de registros. Utilizando este recurso ganha-se muito tempo pelo
simples fato de não ser necessário definir cada tela manualmente, criando consultas e
posicionando componentes. Para otimizar ainda mais o trabalho, certifique-se de que o
Dicionário de Dados (veja documentação aqui) está devidamente preenchido, para que
os componentes dos formulários sejam criados com as descrições desejadas.

No post anterior foi abordada a importância da nomenclatura para fluxos, as mesmas

regras se aplicam aos formulários, o fato de o Maker permitir a criação de artefatos
(formulários, fluxos e relatórios) com descrições alfanuméricas longas requer cuidado,
pois formulários com nomes ambíguos podem complicar a vida do desenvolvedor no
momento da localização destes artefatos. Por exemplo, em boa parte dos sistemas irá
existir um formulário de nome “Itens”. Se no momento em que você necessitar localizar
este formulário o Maker lhe exibir três opções com este mesmo nome (sim, o Maker não
impede a criação de formulários com mesmo nome!), você vai desejar ter dedicado um
pouco mais de atenção a esta questão, pois será necessário abrir cada um para saber qual
você está procurando. Por isto, considerando um sistema de automação comercial, caso
tenha uma tela para Pedido de Venda e outra para os itens, dê a esta segunda tela um
nome completo, de modo a facilitar a sua localização, tal como: ‘Pedido de Venda –
Itens’. Se esta tela de itens por sua vez for um sub-formulário que contém uma grade, dê
um nome significativo para o formulário que define a grade, como ‘Pedido de Venda –
Itens – Grade Parcelas’ por exemplo. Esta prática evitará ambigüidades e facilitará
muito a localização dos formulários.

A forma disponibilizada pelo Maker para definição de regras de negócios e ações em

um formulário é via fluxo. Por isto, boa parte dos desenvolvedores que migram de
outras linguagens para o Maker costuma criar fluxos para todas as operações que eram
realizadas com código. Porém, ao mudar para o Maker, é interessante que se estude
extensivamente as funcionalidades disponibilizadas pelos componentes que podem ser
exploradas sem uso de fluxo, veja algumas funcionalidades úteis por componente
abaixo:

 Botão: possui a propriedade para realizar chamada a um formulário com

passagem de parâmetros.

7
  Grade: possui a propriedade Grade Mestre, que permite que a efetuação de
filtros entre grades em uma mesma tela.
 Lista dinâmica: possui a propriedade ‘Formulário’, que permite definir um
formulário a ser chamado para edição dos registros referentes à consulta da lista.

Para uma lista completa de propriedades dos componentes, consulte a documentação

online. Vale aqui dizer ainda sobre os valores padrão nos formulários, é possível defini-
los clicando em Definições e em seguida na aba Valores Padrão e Máscaras. Neste
momento é exibida uma tela com uma grade que exibe os campos selecionados na
consulta do formulário em questão, clicando com o botão direito na coluna ‘Valor
Padrão’ é possível associar um valor a um campo. Este valor pode ser o retorno de
funções, consulta SQL ou uma constante. Por outro lado, também é possível definir os
valores padrão de uma tela criando um fluxo no evento ao navegar, e verificando se o
formulário se encontra em modo de inserção.

Neste âmbito, uma boa dica é definir parâmetros para o seu sistema através de uma
tabela de parâmetros e obter os valores desejados utilizando a opção Consulta SQL na
definição de valores padrão, por exemplo, considere um sistema de vendas, onde por
padrão, deve-se dar 5% de desconto em todas as vendas. Se este valor é colocado de
forma constante no formulário e um dia o cliente desejar alterá-lo, será necessário
acessar o projeto no Maker, alterar o formulário, gerar .war ou exportar .frz, a depender
de como publicou o seu sistema (sobre este assunto veja este post) e por fim, atualizar
no cliente. Se, por outro lado, você criou no seu sistema uma tabela para armazenar
parâmetros, você poderia alterar este parâmetro em uma simples edição de registro,
ganhando tempo e facilitando a manutenção do seu sistema para estes casos.

A criação de formulários no Maker é bastante simples e direta, define-se uma consulta,

posiciona-se os componentes na tela, escolhe-se os valores padrão destes componentes,
e define-se as regras de negócios, que pode envolver cálculos ou gravação de registros
auxiliares no banco de dados. O importante é definir cuidadosamente as regras a serem
associadas a um formulário, verificando os eventos disponibilizados pelos componentes
e pelo próprio formulário e realizando testes de funcionamento. Questões sobre criação
de fluxos e utilização de funções fogem ao escopo desta publicação, mas, é bom ter em
mente, que no Maker toda regra é chamada a partir de um evento da tela, para que seu
sistema funcione da maneira esperada, conheça todos os eventos que puder para que
você tenha condições de projetar a melhor solução para o seu problema.

Um ponto importante ao se tratar de formulários no Maker é a criação de telas de

consulta. Nem sempre a aba localizar é suficiente para realizar determinadas consultas,
quando se deseja um filtro específico, ou filtragem através de componentes visuais
como árvores e grade, ou mesmo por questões de layout. Outras vezes, em tabelas com
muitos relacionamentos, a quantidade de campos que se deseja na aba localizar pode
tornar a consulta muito pesada, ou simplesmente inviável, por exemplo, considere um
sistema de loja, onde se tem um pedido de venda com os seguintes campos: usuário que
cadastrou o pedido, vendedor, representante, assistente, tipo de pedido, cliente, endereço
de entrega, etc. Agora imagine o que vai acontecer com a consulta da tela se for
necessário que todos os campos citados acima apareçam na aba localizar, como são
campos que fazem referência a outras tabelas, você irá precisa adicioná-los na consulta,
à medida que mais campos forem necessários, mais pesada fica a consulta, o que pode
8
ser notado no tempo de abertura da tela e na navegação entre os registros, além do mais,
consultas muito complexas podem provocar outros efeitos indesejados como: replicação
ou falta de registros por questões de relacionamento (inner, left, etc). Por estas questões,
é interessante pensar em formas bem estruturadas para construir telas de consulta, de
modo que a tela na qual se faz a manutenção dos registros fique sempre otimizada.

Quando se está fazendo uma tela de consulta com filtro dinâmico preenchido pelo
usuário, quase sempre é necessário utilizar fluxo. Para esta tarefa, as funções: ‘Abrir
Consulta’ e ‘Grade – Preencher com Consulta’ podem ser aplicadas. Basta criar um
fluxo com estas duas funções, na primeira você faz sua consulta, recebendo os
parâmetros da tela, por exemplo, considere um sistema de loja onde você precisa criar
uma consulta para listar os pedidos efetuados por vendedor e por período de
vencimento. A figura abaixo mostra a tela e o fluxo que realiza a funcionalidade.

Figura 1- Exemplo de Consulta com filtro de data

Cabe ressaltar aqui que, mesmo que a grade da figura acima seja populada pela função
‘Grade – Preencher com Consulta’, este componente ainda precisa de um formulário
associado, caso contrário, o componente grade não aparece na tela. A dica aqui é que
você crie este formulário com os mesmos campos que sua consulta irá retornar, porém,
sem registros, isso pode ser obtido com uma consulta com o limitador de registros ‘TOP
0’. Desta forma, quando o usuário clicar no botão que irá processar a consulta na grade,
não haverá uma mudança brusca das colunas que a compõem, tornando a
funcionalidade mais natural, visto que, os nomes dos componentes é que irão compor as
colunas da grade quando a tela abrir, e, quando a função ‘Grade – Preencher com
Consulta’ for chamada, são os aliases dos campos que irão compor as colunas (nesta
função também é possível definir manualmente os nomes das colunas, através do seu 4º
parâmetro).

Existem casos de consultas onde as propriedades do componente grade são suficientes

para efetuar a funcionalidade desejada, como por exemplo, a propriedade ‘Grade
Mestre’, ou o uso de parâmetros. Considerando novamente um sistema de loja, onde
seja necessária uma consulta a Funcionários por Setor, é possível realizar tal consulta
9
com duas grades, uma com os setores e outra com os funcionários, sendo que, ao clicar
em um setor, a grade de funcionários exibe os funcionários daquele setor, como mostra
a figura 2-a. Na figura 2-b tem-se uma tela com mesma funcionalidade, mas utilizando
um componente do tipo lista dinâmica para filtrar a grade pelo uso de parâmetros.

Figura 2 – a) Exemplo de Consulta utilizando propriedades do componente grade. b) Exemplo de consulta utilizando lista dinâmica
e grade.

Se a consulta desejada for o simples retorno de uma view ou consulta SQL, o problema
se torna ainda mais fácil de resolver, pois basta criar um formulário sem navegação e
sem abas, apenas com um componente grade, e definir a consulta desejada no
formulário da grade, que deverá ser editável. A Figura abaixo mostra um exemplo de
consulta que exibe todos os usuários marcados como administradores no cadastro de
usuários padrão do webrun. Como o filtro é fixo, não é necessário fazer nada além de
definir a consulta na grade, e, ao clicar no botão atualizar, o operador pode obter
informações em tempo real. Note que nesta grade apenas o botão atualizar está
disponível, pois, trata-se de uma consulta apenas para visualização. (veja Definições do
Formulário aqui)

Figura 3 – Exemplo de Consulta simples

Ainda no contexto de consultas, é importante ressaltar a seguinte questão: o formulário

que vai popular a grade com os resultados da consulta na maioria dos casos vai

10
necessitar de apenas alguns campos, por exemplo, veja a consulta da Figura 3. São
exibidas apenas as colunas: Código, Login e Email do usuário. Esta grade está editável,
por isto, todos os campos que estiverem no formulário detalhe serão exibidos na ordem
da tabulação. Nos casos de grades não editáveis, como na Figura 2, escolhe-se as
colunas que se deseja exibir, porém, se um mesmo campo aparecer mais de uma vez no
mesmo formulário, como em cabeçalhos nas abas, ele vai se repetir na grade, o que não
é desejável. Por estes motivos, é que se deve sempre criar uma nova tela específica para
a grade, uma vez que, associar a mesma tela à qual se dá manutenção nos registros pode
provocar efeitos inconvenientes como repetição de colunas, ou colunas com
espaçamento muito grande, devido ao layout da tela base. Entre escolher o layout da tela
de manutenção e o layout da grade de consulta, escolha criar outra tela específica para a
consulta. Sobre isto, você pode dizer: “Mas eu gostaria que quando o usuário clicasse
duas vezes no registro, o formulário de cadastro abrisse para edição ou visualização”.
Isto pode ser feito via fluxo no evento Ao Duplo Clicar da grade, ou, uma solução mais
prática é adicionar um botão no formulário da grade chamando o formulário de
manutenção dos registros, passando a chave primária do mesmo como parâmetro, como
mostra a Figura 3.

Existem ainda situações onde é útil fazer uma consulta para fins de atualização de
registros, por exemplo, em um sistema de vendas, por conta de algum tipo de falha,
pode ser necessário consultar os pedidos que estão com data de vencimento entrega à
data de emissão, portanto, se faz necessário criar uma tela onde se visualize estes
registros e, na mesma tela, deve ser permitido corrigir estas datas. Para tal, use a mesma
solução citada no parágrafo anterior, mas, tornando os botões alterar e gravar
disponíveis e mude os campos que não se deseja alterar para somente leitura, como
mostra a Figura 4.

Exemplo de Consulta
com atualização de registros

11