Como um modelo de dados pode acabar com a orientação a objetos de um sistema

Como já mencionei anteriormente, o cliente utiliza (e obriga a empresa onde eu trabalho a utilizar) o RUP como metodologia de desenvolvimento, mas que na verdade é um processo em cascata. Assim, temos que gerar um modelo de dados completo logo no início do projeto. Mudanças posteriores nesse modelo são burocráticas e demandam tempo para serem aprovadas. Esse tipo de coisa tem vários problemas conhecidos e já amplamente debatidos em outros lugares.

Mas um problema adicional que tenho observado com essa abordagem é que por causa dela o sistema perde características de orientação a objetos. O que acontece é que a equipe de desenvolvimento fica muita “amarrada” a esse modelo de dados e utiliza-o como referência na hora de criar as classes. Assim, conceitos de OO não são usados adequadamente. O código criado fica com uma relação de 1:1 entre classes e tabelas.

Vou explicar com um exemplo. Suponha que temos uma entidade qualquer que tenha 3 tipos diferentes: A, B e C. Uma modelagem de dados pode prever uma tabela Entidade com uma coluna TipoEntidade para representar isso. Já em termos de classe, idealmente teríamos uma classe “pai” – Entidade – e 3 classes herdando de Entidade: EntidadeA, EntidadeB e EntidadeC. No entanto, ao criar as classes olhando para o modelo de dados, é comum os desenvolvedores se fixarem demais nisso e criar uma única classe Entidade com um atributo tipoEntidade. O código fica, dessa forma, com vários if’s para lidar com comportamentos específicos de cada tipo, quando o mais correto seria ter esse código nas respectivas subclasses.

Não deve haver, necessariamente, uma correspondência tão direta entre tabelas e classes assim. Mas, para alguns, fica difícil ter uma mente mais aberta, quando o modelo de dados já está todo definido e sendo usado como referência para tudo o que é feito depois.

Na minha monografia, estou pesquisando como adaptar práticas sugeridas pelos métodos ágeis para funcionar na realidade da empresa onde trabalho. Idealmente, o design seria feito de forma evolutiva, em ciclos curtos e com muito feedback do cliente. Mas isso não é possível, pelo menos não imediatamente (pretendo na monografia sugerir ações que ajudem a mudar a mentalidade do cliente – mas isso é processo lento e gradativo). O cliente nos obriga a gerar o modelo de dados completo logo no início do projeto.

Uma solução para evitar essa falta de conceitos OO no sistema seria fazer uma modelagem de classes antes do modelo de dados. Ou seja, ainda teríamos o problema de fazer o design todo no início, mas pelo menos o design seria mais orientado a objetos. A partir do modelo de classes seria gerado o modelo de dados, sempre tendo em mente que não há necessidade de uma correspondência 1:1 entre tabelas e classes.

2 Responses to Como um modelo de dados pode acabar com a orientação a objetos de um sistema

  1. Diogo Santos says:

    Trabalhando na empresa a qual você se refere, eu sei que fazer a modelagem das classes antes de modelar o banco requer conhecimentos de OO, o que a maioria dos analistas da tal empresa não tem. Aliás, esse conhecimento nem deve ser requisito na contração deles.

    Será que eles, os analistas, deixariam um desenvolvedor fazer a modelagem de dados?!? Eu vejo que temos um pessoal muito bom aqui, mas subutilizado. Isso é uma pena, poderíamos fazer grandes coisas.

    Eu espero, usando a tua monografia como porta de entrada, conseguir mudar os valores dessa empresa.

    abraço!

  2. É isso aí Diogo! Eu acredito que é possível implementar essas mudanças. Boa sorte!

    Abraços

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: