Sobre o Mestrado (Visualização Científica de Fluidos em 3D)

Fala garotada,

Bom, to sumido a um bom tempo e isso é culpa principalmente do assunto desse post, o MESTRADO.

Defendi meu mestrado na USP no começo do mês. Graças a Deus, mestre eu ser e falar desse jeito vou eu!  \o/ Deu um baita trabalho, fiz ele trabalhando profissionalmente (obrigado chefins que me liberaram para ir sempre que preciso para São Carlos) e estou pessoalmente muito satisfeito por ter concluído essa fase da minha vida. (vc que deve estar lendo deve estar pensando WHO CARES!?)

Quem não quiser ler todo esse texto, aqui vão alguns videos do negócio funcionando:

Workflow Drawer – Desenhando Fluxo de Execuções

Workflow Runner – Executando Fluxo de Execução de Modelagem

Workflow Runner – Executando Fluxo de Execução de Visualização

Meu tema do mestrado foi:

Reengenharia e evolução do visualizador
e modelador do sistema Freeflow3D

O Freeflow3D é uma suite de softwares para simulação de mecânica de fluidos. Meu professor implementou no século passado (lah por 93) e os resultados ainda são impressionantes (meu orientador é um matematico ninja. Programou praticamente um Opengl via software que até hoje me surpreende com o resultado grafico).

Durante muito tempo, muito foi feito pelo seu Simulador, mas o Modelador e o Visualizador cairam no esquecimento.  Logo, o professor queria que fizesse uma nova versão, que rodasse no linux, windows e mac e usasse Opengl.

Sinceramente, quando ele falou isso pensei: “nossa, que mestrado de merda”. Se ele contratasse um programador, seria praticamente a mesma coisa. Então sugeri mudar o paradigma desses dois softwares, ou seja, fazer uma reengenharia de software completa e mudar tudo!

O primeiro passo foi analisar o software legado. Ele era muito, mas muito limitado quanto à experiencia com o usuario. As telas eram confusas, sem muita separação semantica de informação.  O usuario nao podia errar a entrada de dados e tinha que imaginar a cena na mente antes de tentar ela no programa, já que se ele errasse, ele teria que começar tudo do zero. O código tinha partes de negócio misturado com codigo da interface visual, mó zona. E tinha as limitações tecnologicas da epoca que os programas foram desenvolvidos, como o algoritmo de halftone que simulava true color atraves de 256 cores e do uso da biblioteca de janelas xview, feita para Unix e atualmente depreciada (nem vem mais nas distros linux). Mas talvez, o principal problema era ser dificil de evoluir, já que o código era confuso, pouco coeso e altamente acoplado, sendo que só meu orientador manjava da bagaça.

Visualizador e Modelador Legado do Freeflow3D

Realmente, tinha muita coisa para se arrumar. O professor queria que o programa tivesse Opengl e rodasse no Linux, Windows e Mac. Eu queria mudar totalmente a usabilidade com o usuario e deixar mais facil para os desenvolvedores fazerem possiveis manutenções e evoluções.

Os objetivos do professor foram fáceis, escolhi JAVA para programar e reescrevi o renderizador em opengl. Agora, facilitar a usabilidade e o desenvolvimento envolviam uma nova arquitetura, entender muito do programa e mudar tudo. Entao bolei uma nova arquitetura que se baseia em 2 pilares:

Componentes     e      Fluxo de Execuções

A ideia, adaptada de Engenharia de Software baseada em componentes, era que todas as funcionalidades dos programas fosse definidas via componentes, que poderiam ser facilmente trocados por futuras novas implementacoes. O usuario do programa teria que montar o funcionamento do programa ligando os componentes, ou seja, visualmente. Desse modo, além de escolher somente os componentes que precisa, ou até trocar os componentes por novas versões (que porventura podem até fazer algo diferente), o pesquisador poderia reutilizar os fluxos já criados para futuras execuções (o que antes não era possivel, ele tinha que entrar com os dados tudo denovo).

Enfim, essa ideia se materializou na seguinte definição de arquitetura:

•Os novos visualizador e modelador do Freeflow3D devem ter suas funcionalidades representadas por componentes.
•A execução desses programas deve ser baseada em um fluxo de execução, que é definido pela ligação dos componentes.
•Essas ligações entre componentes, ou seja, o fluxo de execução, representam o funcionamento do programa.
Bom, vou esconder os detalhes da implementação, se você estiver curioso é só pegar minha dissertacao (ou o artigo da dissertação, aqui http://bit.ly/nS8ACM). O que posso adiantar é que analisei o programa, quebrei ele em componentes e fluxos de execução guias (um para a modelagem e outro para visualizacao). Fiz um componente basico que auxiliaria a implementacao de todos os outros (one component to rule them all) e criei uma representação dos compontentes via XML, para facilitar a vida dos desenvolvedores. Também criei uma representação em XML para os fluxos de execução e para fazer toda essa nova arquitetura funcionar, fiz 2 programas, e esses sim valem uma palavrina, o Workflow Drawer e o Workflow Runner.
O WorkflowDrawer auxilia o usuário final a criar os fluxos de execucao a partir dos componentes disponiveis (definidos no arquivo xml dos desenvolvedores). Com o arquivo XML que representa o fluxo de execucao definido pelo usuario, o WorkflowRunner trata de rodar o fluxo, pondo para executar os componenes na ordem definida pelo fluxo do usuario.
Toda a interface grafica dos dois programas é gerada automaticamente.

Workflow Drawer - Desenha Fluxo de Execução

Workflow Runner - Rodando fluxo de execução

Logo, todo esse trabalho resultou em novas versoes do visualizador e modelador do freeflow, representados por fluxos de execucoes distintos. Abaixo, estão algumas imagens deles e uma lista das novas funcionalidades criadas. Lá no começo do Post, tem os videos que mostrar o programa funcionando.

Novo Modelador - Exemplo de funcionamento

Novo Visualizador - Exemplo de funcionamento

Novas Funcionalidades do Visualizador e Modelador:
•Interface gráfica criada dinamicamente e facilmente alterável
•Edição de valores em tempo real
•Validação em tempo real
•Picking (seleção com o mouse)
•Translação de objetos (inclusive com o mouse)
•Manipulação da câmera com o mouse
•Câmera auto-ajustável à cena
•Múltiplas instancias de Rendering na mesma tela

Comparação de Resultados - Legado / Nova Versão / Experimento Real

Resumindo bastante, é esse meu trabalho. Espero que a arquitetura criada possa inspirar outros a estrutura sua aplicação em componentes e no desenho de fluxos de execução a partir deles. Se vocês tiverem alguma duvida, sintam-se avonts para perguntar.
Anúncios

Deixe um comentário

Arquivado em 3D, Computação Gráfica, Engenharia de Software, Engenharia de Software Baseada em Componentes, Java, Mestrado, Reengenharia de Software

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

w

Conectando a %s