terça-feira, agosto 22, 2006

Model-based generation

O dia de hoje não foi dos mais produtivos mas, enfim, fiz algo de útil que eu já deveria ter feito há algumas semanas: comecei a procurar artigos para a minha dissertação - os mesmos que eu já tinha e foram sei lá para aonde quando meu HD pifou...
Os tipos de artigos que procuro, em sua maioria, são relativos à geração baseada em modelos (model based generation), o que é justamente a tecnlogia que o Merlin utiliza para geração das telas de cadastro. O que difere muito (e isso eu posso garantir que é em 100% dos artigos e textos pesquisados até o momento) é que, enquanto o Merlin objetiva somente telas de cadastro (as interfaces CRUD), todas as abordagens estudadas buscam obstinadamente a geração de qualquer tipo de interface de usuário. Para isso os autores sugerem diversos modelos-base: modelos de tarefa (task models), modelos de interação (interaction models), modelos de domínio (domain models) e outros elementos, como camadas abstratas de controles, de eventos, de regras e um sem-número de outros recursos, todos visando alguma forma de abstração que permita minimizar o esfoço de programação e aumentar a eficácia das suas propostas.
Na prática, o que eu vejo como conclusão de toda essa panacéia é (i) a redundância de idéias, as quais vagueiam por caminhos diferentes buscando um objetivo comum; (ii) a total falta de aderência a padrões de mercado, uma vez que cada solução define (e advoga como a melhor) um padrão próprio e principalmente (iii) a quase total inutilidade da solução em ambientes reais de desenvolvimento. Sei, a expressão é forte mas, como desenvolvedor de sistemas - o que sou, não vejo aplicabilidade nenhuma delas nos meus cenários de trabalho: são soluções acadêmicas que projetam expectativas e não inserem suas propostas em cenários reais.
O Merlin, é uma ferramenta de geração de IU baseada em modelos, mas como princípio básico eu assumo que não quero gerar qualquer tipo de interface, mas sim - e somente - interfaces do tipo tela de cadastro. E isso simplifica muito as coisas. Com foco nesse tipo de IU, podemos abdicar de complexos modelos extras e balizar toda a geração em um modelo essencial, que está presente sempre: 0 modelo de objetos (de persistência) do sistema. Além disso, qualquer decoração no modelo (que visa aumentar a semântica) é feita com base em padrões de mercado, como o Java Annotations e em frameworks consagrados, como o Hibernate, o EJB e agora, talvez o JBoss Seam. Ainda, com vistas a manter a sintonia com o mercado, o projeto evolui com vistas as novas especificações que ainda estão bem no início, como o Java Bindings (JSR 295) e o Swing Application Framework (JSR 296) além, é claro, de compatibilidade total com tecnologias já em uso, como o Groovy, o BeanShell, AOP e conceitos bem-formados, como a programação baseada em eventos (Event Driven Programming, do Eiffel).
Mas isso tudo não é garantia de sucesso e é justamente por isso que a gente perde madrugadas lendo tutoriais, baixando artigos diversos e, muitas vezes (infelizmente), colocando eles no lixo, porque infelizmente as pessoas esquecem que frameworks devem ser usados no dia-a-dia e não somente terem seus conceitos publicados em sites, conferências e revistas especializadas.

0 comentários: