BeanMaker, Conceituação – Um passo atrás

Antes de avançarmos no detalhamento do projeto BeanMaker, gostaria de dar um passo atrás para falar de alguns conceitos que estão governando a sua construção. Os conceitos e técnicas aqui apresentados são de domínio público e são altamente inter-relacionados. Você irá perceber isso, pois alguns são muito parecidos e, frequentemente, faço referência de um conceito dentro de uma característica técnica e vice versa.

Um outro aspecto importante que quero destacar é a motivação. Nesses quase trinta anos de experiência profissional, muitas vezes me peguei perguntando se eu já não havia desenvolvido algo semelhante antes, que eu pudesse usar como uma escada para o desenvolvimento da nova funcionalidade. Ou perguntando, será que não dá para automatizar esse processo de desenvolvimento. Já escrevi diversas pequenas ferramentas (provas de conceito) para me auxiliar em atividades repetitivas. Todas elas foram bem sucedidas.

Obviamente, tenho consciência que ainda não é possível desenvolver toda uma aplicação usando esses conceitos. Mas acredito firmemente (e pretendo demonstrar através desse projeto) que quase todas as funcionalidades (mais de 80%) para as interações homem-máquina possam ser automatizadas a partir do modelo de dados e da introdução de algumas diretivas (anotações) nas implementações das suas classes. Por interação homem-máquina, chamo as telas para captação e exibição dos dados, a mediação dessas telas com as regras de negócio e a sua correta gravação em mecanismos de armazenamento de dados.

Observe que, embora não esteja explicito no parágrafo anterior, as regras de negócio ainda não podem ser automaticamente construídas. Elas podem ser esquematizadas, mas o seu “recheio” tem que ser construído por um técnico. Assim, uma regra de negócio que envolva, por exemplo, o cálculo dos juros de uma operação de crédito, pode ter a captação e a gravação dos seus dados automatizados, mas o cálculo e as suas interações com outras regras de negócio terão que ser escritas “no braço”. Para escrever regras de negócio que possam ser automatizadas, seria necessário um formalismo na definição, através de fórmulas matemáticas e de um tradutor para transformar essas fórmulas matemáticas em código (em programas).

Em engenharia de software existem alguns conceitos que são tão importantes que até viraram siglas. Alguns são complementares. Estou aplicando uma série deles no projeto, dentre eles:

DRY – Don’t repeat yourself (Não se repita). É o conceito por trás da reutilização. Também é um conceito matemático (evidenciação). Se existe algum trecho de código que vai ser muito utilizado, separe-o para que você possa utilizá-lo sempre que necessário.

KISS – Keep It Simple Stupid! (Tolo, mantenha isso simples!). Não invente moda. Não complique. Não introduza variáveis desnecessárias no momento. Não tente prever o futuro.

CoC – Convention Over Configuration. Sempre que possível adote convenções que possam ser consideradas válidas a menos que tenham sido explicitadas (configuradas) quando necessário. As convenções são características que responderão por mais de 90% dos casos, assim evitamos ter que descrever situações que são a regra e não a exceção. Existem também padrões de construção que tem quase a unanimidade da comunidade acadêmica e técnica. Estou usando alguns deles para organizar as ideias e o código. Forma um conjunto de boas práticas que facilitam a construção de software ao permitir que o esforço de desenvolvimento possa ser distribuído entre os membros da equipe e até mesmo que sejam “atacados” por profissionais com perfis técnicos diferentes.

Observe que esses padrões são mais “físicos” que os conceitos definidos anteriormente Alguns dos conceitos que defini como norteadores no desenvolvimento do projeto são:

Multi-Camada:
O desenvolvimento em várias camadas preconiza que o código seja dividido em um conjunto de fatias, onde uma camada comunique-se com as camadas que lhe são adjacentes. Não pode haver um salto entre camadas. Por exemplo: A camada que controla a exibição da tela, não pode ter acesso direto à base de dados. Ela tem que (obriga-se à) chamar a camada de regras de negócio, que por sua vez chama a camada de acesso aos dados, se necessário.

Assim, se algum técnico viola essa regra, a violação é facilmente percebida e pode ser rapidamente corrigida.

Principais benefícios: Imagine os seguintes cenários:
a) Você precisa mudar o dispositivo que apresenta as telas do seu sistema, ou ainda, que você precisa exibir essas telas em dois dispositivos. Usando esse padrão de desenvolvimento, você precisa apenas alterar ou construir a camada de apresentação.
b) Você precisa mudar o banco de dados da sua aplicação. Você irá alterar apenas a camada de acesso aos dados.
c) Você precisa alterar uma regra de negócio. Você irá alterar apenas a camada de regra de negócios. Obviamente, se essa alteração implicar na captação de novos dados nas telas envolvidas ou no armazenamento e recuperação de novos dados, você terá que alterar outras camadas.

OOA (Object Oriented Analysis)
A Análise Orientada à Objetos é hoje a principal técnica de desenvolvimento de sistemas. Embora existam muitos críticos ao seu emprego, quase todas as linguagens de programação modernas a implementam e quase todos os profissionais na área de sistemas a conhecem. Ou Creio que não exista no Brasil curso superior em sistemas que não a apresente em seus currículos. Então é quase uma ditadura, ou você usa fora do mercado.

MVC (Model View Controller):
É um padrão de projeto (alguns teóricos dirão que é uma arquitetura de projeto) que preconiza que existam três camadas distintas: A camada de Visão (view), a camada de Dados (Model) e a camada de Controle (Controller). A camada de visão é composta pelas telas, relatórios ou outros mecanismos de apresentação ou captação dos dados no ambiente externo à aplicação. A camada de Dados (Model) é composta pelos dados, funções e regras de negócio. A camada de Controle (Controller) é a responsável por fazer a mediação entre as outras duas. Então ela recebe a solicitação da tela (View), executa a regra de negócios (Model), recupera dados na base de dados (Model) e os encaminha para algum dispositivo (View) para a sua apresentação.

DAO (Data Access Object):
É um padrão de projeto que permite o isolamento do acesso aos dados, permitindo que os componentes de armazenagem sejam trocados sem causar impacto nas demais camadas do projeto.

No próximo artigo descreverei a arquitetura da solução e mais alguns insights de como pretendo atacar alguns dos problemas que se apresentam no projeto.