Como você trabalha a transição UML - Banco de Dados?

Olá Mauren,

alguns pontos importantes pra você se questionar:

1. Com a abstração de objetos e partindo do princípio que você está gerando tudo do zero (como você mesmo disse), qual a necessidade do DER?
2. Falando sobre o problema de sincronizar a UML e o código, qual a real utilizade disso? Seu JUDE não ta importando Java6? Da um tentada com o Omondo ou outra ferramenta. Tente extrair os diagramas somente se você precisar de explicar pra alguém que não saiba ler o código, ou se seu cliente exigir esse artefato.
3. A geração do Hibernate é bem legal sim. Você pode através das annotations configurar inclusive o nome das tabelas/colunas (ainda que eu ache isso desnecessário).
4. Você precisa realmente comentar as colunas do banco? Já pensou em usar nomes que expressem o sentido real da coisa para evitar comentários? Geralmente quando tem muito comentário, pode ser uma indicação de falta de expressividade.
5. Não acho que você deva esquecer o Banco de dados. Porém, acho que pode dar menos importância do que o processo atual tem dado.

Bem, espero que isso te ajude.

[]s

Oi Emerson, obrigado pela resposta.

Vamos as considerações ao Emerson e a todos os colegas do fórum que queiram compartilhar a discursão:

1. Com relação aos diagramas UML, penso que o diagrama de classes (ao menos) é interessante manter atualizado, para discursões com os colegas de equipe.

2. Testei o omondo a tempos atrás e achei ele pesado, não sei como ele está hoje. Tem como “desligar” o sincronismo automático que ele faz entre codificação e diagrama? E em um certo momento, pedir para ele atualizar o diagrama?

3. Com relação a geraçao do banco pelo hibernate. Você sabe se essa geração é otimizada, com relação a tipos dos dados, como por exemplo gerando código para o SQL Server:

Java - Banco
byte = tinyint
short = smallint
int = int

E com relação a comentários dos campos, existe alguma anotação que gera os comentários para as tabelas?

Mais uma vez obrigado.

maurenginaldo:

1. Com relação aos diagramas UML, penso que o diagrama de classes (ao menos) é interessante manter atualizado, para discursões com os colegas de equipe.

Você pode ao invés de manter atualizado, extrair um diagrama a partir do código quando necessário.

maurenginaldo:

2) Testei o omondo a tempos atrás e achei ele pesado, não sei como ele está hoje. Tem como “desligar” o sincronismo automático que ele faz entre codificação e diagrama? E em um certo momento, pedir para ele atualizar o diagrama?

Da uma testada novamente. De qualquer forma, existem outras alternativas

maurenginaldo:

3) Com relação a geraçao do banco pelo hibernate. Você sabe se essa geração é otimizada, com relação a tipos dos dados, como por exemplo gerando código para o SQL Server:

Você pode usar o definition pra fazer isso.

maurenginaldo:

E com relação a comentários dos campos, existe alguma anotação que gera os comentários para as tabelas?

Eu ainda não precisei fazer isso. Talvez via definition de pra fazer tb. Mas se essa feature existe, com certeza tem na documentação oficial.

Use a UML para analisar o problema.

Não modele o banco de dados. Modele os objetos.

Use um bom framework ORM e deixe que ele modele as tabelas para você (eg. SchemaExport do Hibernate)

Essa estratégia vai dar certo para 99,9% das vezes.

rodrigoy:

Use a UML para analisar o problema.

Não modele o banco de dados. Modele os objetos.

Use um bom framework ORM e deixe que ele modele as tabelas para você (eg. SchemaExport do Hibernate)

Essa estratégia vai dar certo para 99,9% das vezes.

:idea: Sim, dividir para conquistar, quando você diz modele os objetos é necessário dizer que eles tem responsabilidades distintas, no entanto você tem objeto transitanto em todas as camadas n-tier, o que vem ai e faz necessário técnicas avançadas de DDD etc…, a UML é uma notação, os objetos são serviços, o Design Pattern estão situados dentro desses FrameWorks como um mecanismo lógico ao negócio. FrameWorks não funcionais podem varias esses serviços em determinados requisitos novos que lhe vão aparecendo, novas especificações outra arquitetura a se adotar.

:arrow: Outros que estão incubados como ERPs podem usar de outras combinações Anti-Patterns objetos de criação de tela por exemplo Decorator, entre outros FrameWorks Funcionais , como exemplo OpenStrategies ERPs OpenSources que já startam em sua logica de negócio por Workflows internos.

rodrigoy:

Use a UML para analisar o problema.

Não modele o banco de dados. Modele os objetos.

Use um bom framework ORM e deixe que ele modele as tabelas para você (eg. SchemaExport do Hibernate)

Essa estratégia vai dar certo para 99,9% das vezes.

Estou com esse pensamento de deixar o banco de dados um “pouco de lado” e me preocupar com os objetos.

1. Estou pensando em fazer o diagrama de classes inicial no Jude por exemplo
2. Gerar as classes (código-fonte).
3. Anotar as classes
4. Gerar o banco através do hibernate.

Seria por aí mesmo :?:

Vamos comentar como cada um trabalha para trocarmos experiências.
Abraços

Sim… essa é a idéia. Não existe transição UML->DB… existe é persistência de objetos. Com as ferramentas atuais eu ligo muito pouco para o banco principalmente em desenvolvimento green field.

Se tiver um tempo leia o meu artigo sobre ORM na MundoJava "Mapeamento Objeto Relacional ? Tecnologia, Herança e Impedância". MundoJava #24

Nesse tipo de desenvolvimento faz uns bons 4 anos que não modelo banco de dados.

Já ta na mão, vou conferir…

Que esse ano seja meu primeiro :lol:

Abraços,

Oi Rodrigo, li o artigo e achei o seu exemplo perfeito, simples e muito esclarecedor. Muitas dúvidas que estavam rondando minha cabeça foram sanadas.
Gostei da parte “Espere problemas com seu DBA”, eheheh, uma função muito importante no processo de desenvolvimento procedural, que é exercida há mais de décadas e que com os frameworks ORM perdem totalmente sua importância.

Recomendo a todos os colegas a leitura do artigo.

Abraços,