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

November 21, 2007

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.

Advertisements

Monografia

November 16, 2007

Esse é meu primeiro post. A idéia com esse blog é escrever sobre temas que me interessam relacionados a desenvolvimento de software, como por exemplo metodologias ágeis, test-driven development, orientação a objetos, Domain-Driven Design, e por aí vai.

Inicialmente, devo escrever sobre temas ligados à minha monografia. Deixa eu explicar. Atualmente estou terminando minha pós-graduação em Gerência de Projetos de Software. Trabalho em uma empresa que fornece outsourcing de desenvolvimento de sistemas. Muitos membros da equipe (inclusive eu) têm interesse em metodologias ágeis e estamos começando a definir um processo de desenvolvimento de sistemas baseado em XP, Scrum, Lean, etc. O problema é que o cliente usa RUP – mas que na verdade é um processo cascata – e temos que trabalhar com essa restrição. Então, o grande desafio é como adaptar metodologias ágeis para funcionar na nossa realidade. Esse é o tema da minha monografia, ou seja, uma pesquisa para definir um processo de desenvolvimento baseado em metodologias ágeis adaptado para funcionar na nossa realidade – outsourcing, RUP que na verdade é cascata, cliente não presente, ciclos de release longos, BDUF, entre outros problemas que pretendo escrever em posts futuros.

A idéia da pesquisa é propor práticas de metodologias ágeis (com adaptações quando necessárias) que funcionem com as restrições acima. E, também, propor ações que possam gradativamente mudar a mentalidade do cliente para algo mais ágil.

Nos próximos posts devo escrever sobre problemas específicos relacionados à implantação de metodologias ágeis e as soluções que estou pesquisando.