Arquiteturas...

Ao iniciar o desenvolvimento de qualquer software, uma das primeiras atividades desempenhadas pelos desenvolvedores (especialistas em computação) é a definição da arquitetura do mesmo. Essa tarefa custuma ocorrer logo após uma definição, ou melhor, do levantamento dos requisitos do negócio a ser tratado, sendo assim, o que for definido nesta etapa deverá ser considerado durante todo o tempo de vida do projeto. Acontece que essa não é uma atividade trivial. Com tantos padrões, técnicas, modas, conceitos mal entendidos, frameworks entre outros parâmetros, muitas vezes ficamos em dúvida do que de fato utilizar. Uma coisa é clara, desejamos que o código-fonte dos nossos softwares estejam cada vez mais próximo do domínio do problema, fazendo com que a comunicação entre desenvolvedores e especialistas do negócio utilize uma linguagem comum. Como uma tentativa de atingir esse nível de qualidade do código e ter uma maior aproximação dos envolvidos no projeto, o paradigma de Domain-Driven-Design (DDD) apresenta-se como uma abordagem extremamente útil e prática a ser considerada. Através do DDD, várias diretrizes podem ser seguidas para a elaboração de uma arquitetura transparente e mais próxima do domínio como desejamos. Essas diretrizes não são relacionadas apenas com o código-fonte em si, como é o caso do uso de determinados padrões de projeto, tal como o tão falado e confundido Repository. O DDD contempla também a elaboração de uma linguagem comum (chamada de Ubiquitous Language) a ser usada entre os envolvidos no projeto. Isso significa que os desenvolvedores devem nomear seus artefatos (classes, métodos, atributos, etc) de acordo com o negócio tratado. Isso também não quer dizer que os desenvolvedores não possam usar palavras do seu próprio jargão, por exemplo, o conceito de repositórios (pattern Repository) é comumente usado nessa comunicação, mas seu conceito deve estar bem claro para ambos os lados.
Outra discussão que segue é em relação às camadas da arquitetura. A tradicional dúvida, "Onde devo colocar as regras de negócio?" A tradicional separação em classes do tipo Business Object, Value Object, Data Transfer Object, Classes de controle, entre outras, nos perguntamos onde se encaixa a orientação a objetos, essa forma tradicional é muito estruturada. Esses dias conversando com um amigo no Google Talk ele me perguntou: "me diz onde eu deveria criar meu objeto 'Notícias' que vai puxar os dados no BD, usar uma DAO? e as validações, regras de negócio?". Para responder a pergunta, abaixo consta um pequeno diagrama de classes envolvidas na solução.
A classe News é a classe de domínio. Nessa solução, o padrão Repository está sendo implementado como uma DAO, porém perceba que a classe Client (classe que exemplifica o uso dessa estrutura criada, poderia ser uma action do Struts ou lógica do VRaptor por exemplo) tem associação apenas com a interface NewsRepository, isso é importante para não termos um forte acoplamento com a implementação. A classe concreta NewsDao então implementa a interface NewsRepository para conter de fato a implementação da interação dessa entidade com o banco de dados. Perceba também que a classe News não possui nenhum método de negócio digamos, mas caso existisse algum método que alterasse o estado dos atributos este deveria ser criado nessa classe, e não em uma NewsBO. Quando temos uma classe que contém os métodos de negócio e os atributos dizemos que ela possui um alto nível de coesão, que é um ponto forte dessa implementação. Quanto a questão de validação do estado dos atributos, fazendo uso de um framework como o HibernateValidator (que inclusive serviu de inspiração para a criação da JSR-303 - Bean Validator) a tarefa torna-se simples e declarativa.

Para mais informações a respeito de DDD, peço que chequem os artigos contidos na InfoQ. Nesse espaço pode ser encontrado muito conteúdo bom sobre Java, arquitetutura, entre outros.

[]s

TankCoders 2, focando em agentes...

Olá pessoas,

Como já apresentado em tópicos anteriores, o meu projeto de TCC foi desenvolver um simulador de batalhas de tanques de guerra em 3D onde pudessem ser desenvolvidos e testados agentes AgentSpeak(L) do interpretador Jason. Porém, além de prover um ambiente onde os agentes pudessem atuar, propus também que o simulador pudesse ser usado por usuários remotos. Essa feature, por mais interessante que possa ser, nada tem a contribuir para o estudo de Programação Orientada a Agentes (POA). Sendo assim, essa feature será retirada do projeto TankCoders 2.

TankCoders 2
A primeira questão a ser tratada nesse novo projeto é o paradigma de programação a ser usado. Exceço de orientação a objetos em aplicações gráficas de tempo-real já pude perceber que não é o melhor caminho. Sendo assim, de início estarei fazendo uma pesquisa de como desenvolver aplicações "orientadas a performance", focando em uma elevada taxa de FPS.

Para essa segunda versão do TankCoders, outra mudança é em relação à versão da engine JME que estarei utilizando. Será usada a versão 1.0 juntamente com a versão 2.1 da JME Physics, que segundo os respectivos release-notes, muitas melhorias foram proporcionadas.

Nesse versão também serão trocados os modelos de tanques utilizados. Pretendo tentar entrar em contato com pessoas especializadas em ferramentas de modelagens 3D, vendo a possibilidade de estar criando dois modelos com uma quantidade mínima de faces. Essa questão também irá melhorar a performance do cenário pelo menos 60% em relação a versão atual.

Para um melhor aproveitamento dos estudantes de POA, nessa nova versão estarei provendo um cenário um pouco mais controlado, ou seja, sem tantas "realidades do mundo real". Na atual versão tudo é controlado pela física e percebi que se torna extremamente complexo para uma pessoa estar desenvolvendo agentes AgentSpeak(L) realmente eficientes. O simples fato de fazer o tanque virar 90º para a direita, por exemplo, já se torna complexo, pois pode que o tanque esteja subindo uma montanha e atrapalhe a realização da ação. Tudo isso ainda precisa ser especificado de forma mais detalhada.

Conforme vou tendo mais novidades em relação ao desenvolvimento da versão 2 estarei publicando neste espaço.

Obrigado pela atenção.

"Fim" do trabalho, apresentação do TCC

Olá pessoal,

Hoje não estarei comentando sobre alguma tecnologia estudada ou alguma reflexão sobre o mundo de desenvolvimento JavaEE como custumo fazer aqui no blog. Estarei comentando então como foi a conclusão do meu TCC representada pela apresentação do mesmo junto a banca.

Banca foi formada pelos professores:
- Avaliador da proposta: Dr. Mauro Marcelo Mattos
- Segundo avaliador: Dr. Paulo Cesar Rodacki Gomes
- Orientador: M.Sc. Dalton Solano dos Reis

Apresentação teórica
Conforme as regras para apresentação de TCCs no Departamento de Sistemas e Computação da Furb, o tempo máximo para essa apresentação é de 30 minutos. Em muitos trabalhos, essa questão de tempo não custuma ser um problema, porém não foi o que ocorreu comigo. Antes de apresentar o trabalho para a banca (dia 08/07/2008 às 21h), realizei duas prévias, sendo que a primeira delas foi supervisionada pelo meu orientador Dalton e por amigos de turma que também apresentam seus trabalhos nesse semestre. Na primeira prévia minha apresentação teórica demorou 48 minutos, nesse momento eu começei a ficar realmente preocupado. Precisava reduzir 18 minutos, sendo que não fazia ideia de como fazer isso. Seguindo a orientação do prof. Dalton e dos amigos, em especial o Israel D. Medeiros e o Eduardo Coelho, foi possível criar uma forma de apresentar o trabalho para a banca em um tempo de 31 minutos. Nessa apresentação, além de fazer uma introdução do tema escolhido e esplanar de forma clara os objetivos do trabalho, foi apresentada de forma bastante sucinta os assuntos estudados na fundamentação teórica, que foram a àrea de Ambientes Virtuais Distribuídos, Sistemas Multiagentes e por fim à parte gráfica com a engine JMonkey Engine. O grande desafio da apresentação era de fato na parte da especificação da ferramenta. O projeto desenvolvido apresentou um número de 135 arquivos .java sendo classes, interfaces e anotações. Nem todas as classes foram incluídas nos diagramas da UML utilizados (classes e estados), mas mesmo assim a maior parte delas foi ilustrada. Resolvi então apresentá-las de acordo com a separação dos módulos que desenvolvi no software. Dessa forma consegui explicar as classes em nível de pacotes e suas respectivas funcionalidades, reduzindo o tempo gasto na apresentação de forma geral. No final foquei nos resultados obtidos, onde fiz uma discução das abordagens seguidas no trabalho. Nesse momento falei sobre o uso de Orientação a Objetos e integração de diversas tecnologias diretentes em aplicações gráficas, mostrando como isso refletiu na performance do simulador. Por último apresentei as conclusões onde enfatizei que o foco não era desenvolver um jogo (um produto) mas sim prover um ambiente mais atrativo para o estudo do paradigma de Programação Orientada a Agentes (POA).

Apresentação Prática
Começei a apresentação prática com a execução do simulador (aplicativos servidor e cliente). Utilizei dois computadores, um para cada cliente representando jogadores do tipo Avatar, que controlam os tanques de guerra atraves de teclado e mouse. Nesse momento consegui mostrar algumas caracteristicas do ambiente gráfico desenvolvido, porém obtive um crash na JVM ao carregar a batalha pela segunda vez. Esse erro ocorreu durante todo o desenvolvimento e eu já estava preparado para vê-lo também na apresentação, tanto que gravei um video para mostrar caso o erro insistisse em ocorrer. O crash ocorre devido ao uso dos modelos de tanques de guerra escolhidos. São modelos extremamente pesados, sendo que não foram criados para serem usados em ambientes gráficos de tempo-real. A solução pra esse problema é desenvolver modelos espefícos para o cenário em questão, porém isso requer muita habilidade em ferramentas de modelagem 3D, que não era o foco inicial do trabalho.
Apresentei também a execução de uma batalha onde dois tanques eram controlados por agentes da ferramenta Jason, os tanques possuiam um código simples, porém foi possível mostrar o quão abstrato um código AgentSpeak(L) pode ser em relação às abordagens tradicionais.

Considerações da Banca
Ao final da apresentação, os membros da banca inicialmente fizeram bastante elogios, tanto da parte escrita (monografia) quando no desenvolvimento e o tema escolhido. Também apresentaram várias contribuições e alguns ajustes a serem feitos, onde todos foram aceitos pelo meu orientador e por mim.

Tenho a certeza de que esse trabalho contribuiu muito para o meu desenvolvimento (tanto técnico quanto pessoal). É claro que dá um alívio concluí-lo, mas com certeza vou sentir falta dessa rotina de prazos, desenvolvimento e etc. Também sei que esse trabalho não está de fato encerrado, tenho muita vontade de continuar desenvolvendo ele, em conjunto com o professor Dalton e outros que possam vir a se interessar. Sei isso, pois essa área pesquisada despertou em mim muito interesse já que tive que me esforçar muito para compreendê-la.

Para mais informações do que foi desenvolvido, o site do projeto é: http://germanofronza.googlepages.com/tankcodersproject

Slides da apresentação: http://www.inf.furb.br/~gfronza/tankcoders/Apresentacao.pdf

Muito obrigado pela atenção.

Next-Generation frameworks

Hoje em dia tanto se houve falar dos "Next-Generation frameworks" (também chamados de "lightweight frameworks") e como eles se diferenciam dos "antigos" (taxados de "heavyweight"). Esses frameworks antigos, caracterizados por utilizarem diversos arquivos XML de configuração, possuem uma estrutura extremamente robusta que causa um nível de baixa produtividade às equipes de desenvolvimento. Por esse motivo, os novos frameworks surgem com o intuito de extinguir os arquivos de configuração (properties ou XMLs) e trazer essas configurações, quando realmente necessárias, para dentro do código Java. Com o surgimento das Anotações no Java 5, conceitos como Inversão de Controle, Injeção de Dependências e Convensões sobre Configurações estão sendo amplamente usados, e isso de fato diminui o grau de dependências e aumenta o nível de entendimento do código. Porém, na minha visão, é nesse momento que alguns frameworks estão cometendo um novo erro: certas configurações devem mesmo estar no código Java? Qual o real motivo disso? Modismo? Empolgação? Ódio de XML ou Properties?
Surgiu a motivação para escrever este post logo após fazer um estudo (ainda não muito aprofundado) do framework de Injeção de Dependências do Google chamado Guice (se lê: Juice). Trata-se de um framework muito interessante, simplifica diversas tarefas em relação ao seu "concorrente" Spring IoC. O problema dele é justamente na configuração que faz o bind das interfaces e implementações. O Guice tem o conceito de Modules, onde para se criar um módulo deve-se HERDAR uma classe chamada AbstractModule e sobrescrever o método configure. Esses módulos são classes Java que fazem a configuração de forma programática dos binds. Na minha visão, dois problemas surgem nesse conceito de módulo do Guice. O primeiro deles é o fato de ter que herdar de uma classe que não é sua, nem sabemos como ela é implementada. Herança é algo que deve ser evitada ao máximo! O segundo é em relação à configuração que é feita em código Java e de forma bem extensa. Se esses módulos fossem configurados em XML por exemplo, muita abstração seria proporcionada e o código Java seria limpo.

Guice video introduction: http://crazybob.org/2007/06/introduction-to-guice-video-redux.html

Só uma pequena discussão. ;D
Até.