Antes de passar para vocês o que acho que será o futuro dos sistemas, vou retomar o assunto de ligar controles e eventos à regras de negócio que ainda não existem...
Todo mundo está acostumado a programar da seguinte maneira: dadas as regras de negócio definidas (pelo analista) e detalhadas (pelo projetista), essas são programadas (pelo programador) conforme as especificações contidas no processo de software (se existir, ahahaha). Isso significa que o programador vai construir a interface do usuário e ligá-la às regras de negócio através de pontos específicos: os eventos dos controles. Isso nada mais é que o modelo MVC, regra básica em aplicações desktop ou web.
A interface do usuário (IU) está sendo construída. Os eventos já estão definidos no pacote gráfico/controlador em uso (Swing, SWT, Strus, JSF, Ajax...) e são simplesmente estendidos ou utilizados. E as regras de negócio ou já estão prontas em componentes escaláveis (EJBs, Webservices, JMS, etc.) ou estão em classes simples mesmo. Ou se não estão, serão, assim como a IU, criadas on demand. Em outras palavras, tudo que você usa para criar o sistema ou precisa estar pronto naquele momentou ou você cria na hora. Isso é a programação tradicional. Todos fazem isso.
Mas já pensaram em programar a IU e ligar ela a uma regra de negócio que - seguramente - estará disponível somente daqui a 3 semanas?
Vou dar um exemplo simples: O programador está criando um cadastro para uma financeira e o projeto gráfico (as telas) está pronto, bem como o projeto navegacional. Como o programador é "bala", a tela está praticamente pronta. Falta, porém, o analista e o usuário decidirem se dentro da fórmula do imposto sobre operações do tipo XPTO (que ainda não se sabe se é esse o nome mesmo!!! - me desculpem os usuários e analistas) será feito usando a tabela de cálculo X ou Y ou se será uma "mescla" da fórmula existente no último sistema da casa (...)
O programador pergunta ao seu gerente: E aí, o que eu faço agora? Eu poderia colocar a tela em produção hoje, mas como ainda não tenho essa regra de negócio definida, não sei o que fazer. O gerente responde: Toca outra tela...quando eles se decidirem você termina isso [subentende-se aqui: volta daqui a 3 semanas; procura o TODO que você colocou no código-fonte (colocou mesmo?); modifica os comandos navegacionais do controlador (vários XMLs) que faziam a página A ir para a C diretamente - sim, porque agora que a página B com o cálculo do financeiro está pronta e o esquema o fluxo do sistema muda de novo, testa, empacota redeploya e, ufa, vai tomar um cafezinho).
Minha pergunta é: Não seria mais interessante o programador ter feito algo como:
Agent.bind("btnCalcular", "click", "calcularImpostoSobreOperacoesXPTO")
E colocar a aplicação em funcionamento 3 semanas antes sem se preocupar como a regra do imposto será implementada? Simplesmente quanto ela estivesse pronta, a aplicação detectaria isso e ligaria o botão, o evento e a regra transparentemente.
É justamente isso que acontece quando o Merlin é usado para fazer o binding de regras denegócio: não importa se a regra está progamada ou não, o binding é feito e quando a regra estiver disponível a coisa simplesmente acontece.
Extrapolando esse conceito, fábricas de software poderiam criar sistemas de forma totalmente fragmentada, colocando-os em funcionamento mesmo que seus "pedaços" não estivessem disponíveis ainda.
Essa proposta não é nova para mim. Na verdade, o projeto Jestor, data de mais de 3 anos e é uma coisa que ainda quero desenvolver.
Obviamente, o exemplo que dei é uma minimização do assunto, pois aspectos diversos, como segurança, contexto de execução e outros estão envolvidos. Mas o importante é dizer que o Merlin já suporta a ligação de regras de negócio mesmo se elas ainda não estiverem disponíveis.
Se tudo correr bem, depois do Merlin, do Magoo e do projeto X (desculpem, ainda não tenho nome ainda para o gerador de relatórios que vai usar as bases do Merlin para renderizar os famigerados reports dos sistemas), o Jestor será a chave para fechar a arquitetura que tenho em mente.
Claro, devem correr mais uns 5 anos ainda, mas quando o Dolphin já for a JRE padrão nos sistemas operacionais, o Jestor bem que poderia ser um pacote estável pronto para download em algum repositório público como o SourceForge ou JavaNet.
Todo mundo está acostumado a programar da seguinte maneira: dadas as regras de negócio definidas (pelo analista) e detalhadas (pelo projetista), essas são programadas (pelo programador) conforme as especificações contidas no processo de software (se existir, ahahaha). Isso significa que o programador vai construir a interface do usuário e ligá-la às regras de negócio através de pontos específicos: os eventos dos controles. Isso nada mais é que o modelo MVC, regra básica em aplicações desktop ou web.
A interface do usuário (IU) está sendo construída. Os eventos já estão definidos no pacote gráfico/controlador em uso (Swing, SWT, Strus, JSF, Ajax...) e são simplesmente estendidos ou utilizados. E as regras de negócio ou já estão prontas em componentes escaláveis (EJBs, Webservices, JMS, etc.) ou estão em classes simples mesmo. Ou se não estão, serão, assim como a IU, criadas on demand. Em outras palavras, tudo que você usa para criar o sistema ou precisa estar pronto naquele momentou ou você cria na hora. Isso é a programação tradicional. Todos fazem isso.
Mas já pensaram em programar a IU e ligar ela a uma regra de negócio que - seguramente - estará disponível somente daqui a 3 semanas?
Vou dar um exemplo simples: O programador está criando um cadastro para uma financeira e o projeto gráfico (as telas) está pronto, bem como o projeto navegacional. Como o programador é "bala", a tela está praticamente pronta. Falta, porém, o analista e o usuário decidirem se dentro da fórmula do imposto sobre operações do tipo XPTO (que ainda não se sabe se é esse o nome mesmo!!! - me desculpem os usuários e analistas) será feito usando a tabela de cálculo X ou Y ou se será uma "mescla" da fórmula existente no último sistema da casa (...)
O programador pergunta ao seu gerente: E aí, o que eu faço agora? Eu poderia colocar a tela em produção hoje, mas como ainda não tenho essa regra de negócio definida, não sei o que fazer. O gerente responde: Toca outra tela...quando eles se decidirem você termina isso [subentende-se aqui: volta daqui a 3 semanas; procura o TODO que você colocou no código-fonte (colocou mesmo?); modifica os comandos navegacionais do controlador (vários XMLs) que faziam a página A ir para a C diretamente - sim, porque agora que a página B com o cálculo do financeiro está pronta e o esquema o fluxo do sistema muda de novo, testa, empacota redeploya e, ufa, vai tomar um cafezinho).
Minha pergunta é: Não seria mais interessante o programador ter feito algo como:
Agent.bind("btnCalcular", "click", "calcularImpostoSobreOperacoesXPTO")
E colocar a aplicação em funcionamento 3 semanas antes sem se preocupar como a regra do imposto será implementada? Simplesmente quanto ela estivesse pronta, a aplicação detectaria isso e ligaria o botão, o evento e a regra transparentemente.
É justamente isso que acontece quando o Merlin é usado para fazer o binding de regras denegócio: não importa se a regra está progamada ou não, o binding é feito e quando a regra estiver disponível a coisa simplesmente acontece.
Extrapolando esse conceito, fábricas de software poderiam criar sistemas de forma totalmente fragmentada, colocando-os em funcionamento mesmo que seus "pedaços" não estivessem disponíveis ainda.
Essa proposta não é nova para mim. Na verdade, o projeto Jestor, data de mais de 3 anos e é uma coisa que ainda quero desenvolver.
Obviamente, o exemplo que dei é uma minimização do assunto, pois aspectos diversos, como segurança, contexto de execução e outros estão envolvidos. Mas o importante é dizer que o Merlin já suporta a ligação de regras de negócio mesmo se elas ainda não estiverem disponíveis.
Se tudo correr bem, depois do Merlin, do Magoo e do projeto X (desculpem, ainda não tenho nome ainda para o gerador de relatórios que vai usar as bases do Merlin para renderizar os famigerados reports dos sistemas), o Jestor será a chave para fechar a arquitetura que tenho em mente.
Claro, devem correr mais uns 5 anos ainda, mas quando o Dolphin já for a JRE padrão nos sistemas operacionais, o Jestor bem que poderia ser um pacote estável pronto para download em algum repositório público como o SourceForge ou JavaNet.
0 comentários:
Postar um comentário