Todo programador começa sua trajetória de aprendizado no mundo de desenvolvimento com o famoso exemplo Hello World, seja qual for a linguagem isso é um fato. Depois que passamos desta fase e decidimos desenvolver nossa primeira aplicação iniciamos pelo modelo tradicional de desenvolvimento estruturado ou procedural como alguns costumam chamar, e nesta estrutura o desenvolvimento da aplicação se inicia pela modelagem do banco de dados.
Damos mais ênfase ao projeto e normalização do banco de dados, as tabelas principais e tabelas auxiliares, chaves e relacionamentos. Com o passar do tempo vamos adquirindo mais experiência, aprofundando nosso conhecimento e naturalmente começamos a estudar a orientação a objetos.
Neste momento somos impelidos a passar a desenvolver todos os nossos sistemas seguindo este modelo de orientação a objetos e é ai que começam a surgir várias dúvidas. Devo começar do zero? Devo aproveitar minha aplicação atual? Começo a modelar as classes e depois gero o banco? Gero o banco primeiro e depois crio as classes?
Enfim, estas e outras dúvidas surgem e em busca das respostas muitas pessoas desanimam e desistem, principalmente quando decidem migrar suas aplicações procedurais para o modelo OO. O trabalho para criar manualmente cada uma das classes de negócio deixa qualquer um desmotivado, pois, por menor que seja uma aplicação a quantidade de tabelas no banco de dados geralmente passa de 100.
O objetivo deste artigo não é responder a todas as perguntas que surgem quando pensamos em desenvolver uma aplicação orientada a objetos, mas independente de estratégia que decidimos adotar, seja começar pela modelagem de depois criar seu banco de dados, seja partir de um banco de dados relacional para gerar seu modelo uma coisa é certa, se decidimos programar utilizando a orientação a objetos vamos precisar de duas coisas:
1) Nossas classes de negócios para que possamos instanciar nossos objetos e dar vida a nossa aplicação e
2) Um banco de dados para persistir nossos objetos. Ora se temos por certo que precisamos das classes e do banco de dados e se começamos nossa trajetória pelo desenvolvimento de sistemas pelo banco de dados, o melhor dos mundos seria poder gerar nossas classes a partir de banco de dados que já temos pronto e em funcionamento e assim pularmos uma etapa chata e demorada que seria criar manualmente cada uma das classes de negócios para as tabelas do nosso banco de dados.
É importante citar que o banco de dados relacional que será alvo da engenharia reversa (ver BOX 1) deverá atender a alguns requisitos, com por exemplo, o nome das tabelas deve seguir um padrão, as chaves primárias devem ser únicas, os campos devem seguir também um padrão. Isso é necessário para facilitar a criação do nosso algoritmo que fará a engenharia reversa.
Porém sabemos que nem sempre é possível atender a estes requisitos até porque nossos bancos foram criados sem nem mesmo pensar que um dia faríamos uma engenharia reversa nestes bancos.
A Engenharia Reversa é uma atividade que trabalha com um produto existente (que pode ser um software, uma peça mecânica ou um banco de dados) e tenta entender como este funciona, o que ele faz, quais são suas propriedades, etc.
A Engenharia Reversa também é vista como um processo de análise de um sistema para criar uma representação deste mesmo sistema em um nível mais alto de abstração. No caso de engenharia reserva de banco de dados, essa abstração em geral se dá mapeando as propriedades deste banco e gerando seu modelo lógico ou físico para melhor entendimento.
Em nosso exemplo faremos a engenharia reserva de um banco de dados com o objetivo de criar a abstração deste banco em um modelo orientado a objetos.
Nosso algoritmo cuidará tão somente de gerar as classes de negócio, não nos preocuparemos por exemplo com o mecanismo de persistência que é utilizado para persistir classes no banco de dados, justamente porque existem diversas estratégias para isso, você poderia utilizar por exemplo o modelo DAO de persistência (ver BOX 2) ou criar um mecanismo de reflexão para mapear os objetos e persisti-los no banco de dados.
O objetivo é criar classes que possam ser usadas em qualquer uma das duas situações e mais uma vez repito, você terá liberdade de adaptar o algoritmo a sua realidade.
Embora a persistência não seja o foco do artigo, em nosso algoritmo lançaremos mão do ...
