Primeira simulação

Depois de apresentar esta segunda versão, foi pedido que se mostrassem esferas movimentando-se dentro de um cubo ou de uma esfera maior - o primeiro passo para realizar a simulação do movimento browniano. O código cresceu bastante, e foi necessário introduzir alguma padronização nele (nomes de métodos e identação), para facilitar sua manutenção e seu desenvolvimento.

Figura: Interface do programa depois da implementação da simulação básica do movimento browniano, com as moléculas colidindo apenas com o ambiente de difusão
Image GUI-v1

Figura: Sucessivos quadros da simulação básica do movimento browniano dentro de um cubo sobrepostos
Image Sim-v1

Foi pedido para que as esferas colidissem, inicialmente, apenas com o cubo (ou esfera) - o ambiente de difusão. Isso exigiu a implementação de detecção de colisão simples, onde apenas um dos objetos está em movimento e o ponto de colisão, juntamente com a normal deste ponto, pode ser facilmente calculada.

O resultado destas alterações pode ser visto na Figura [*]. O resultado da simulação pode ser visto na Figura [*].

Neste ponto, o paradigma de orientação a objetos começou a conflitar com o modo como o glade-- gerava o código. Haviam classes bem definidas para as ``moléculas'' e para o ambiente de difusão, mas estas estavam razoavelmente acopladas a uma classe pouco coesa e com padrões de código diferentes, que era a classe da interface. O diagrama de classes do programa pode ser visto na Figura [*]. Olhando para o diagrama, é possível notar que, além dos padrões de nomes de classes misturados, a classe inicio, cuja responsabilidade inicial era apenas desenhar a interface, estava ficando pouco coesa, tendo, também, a responsabilidade de criar os objetos da simulação e atualizá-los a cada quadro. Esses problemas foram determinantes para a decisão de não utilizar mais o gerador de código.

Figura: Diagrama de classes da última versão do programa a utilizar o glade-- como gerador de código para a interface
Image UML-v1

Outros fatores decisivos para tomar a decisão de não utilizar mais o gerador de código foram a falta de flexibilidade para mudanças na interface, uma vez que cada mudança exigia a mesclagem do código anterior com o recém-gerado, a recomendação de não utilizar o gerador feita pelos próprios desenvolvedores do GTK e a dificuldade de utilizar as ferramentas de auxílio à compilação determinadas pelo glade-- no Windows.

Luiz Fernando Oliveira Corte Real 2008-11-28