Oi pessoal,
estamos definindo uma processo de desenvolvimento na empresa onde trabalho, bem simples, adaptado às nossas condições. Já tentamos implantar metodologias prontas mas nunca conseguimos seguir perfeitamente e preencher todos os aterfatos. Conclusão, vamos fazer o básico!
Minha dúvida está na transição UML --> Banco de Dados --> código fonte.
Definimos que iríamos fazer o diagrama de classes, depois o DER e do DER gerar as classes.
1º Problema:
Estamos tendo uma dificuldade e re-trabalho, pois estamos fazendo as classes e depois as tabelas. Estamos usando o Jude Community e ele não gera a DDL do banco. Está parecendo que o diagrama de classes está inútil, pois as classes são gerados do banco através do eclipse.
2º Problema:
Quando chego nas classes e vamos adicionar as alterações, queremos atualizar o diagrama de classes, e pimba. o Jude não consegue importar java6.
Temos a parte do banco como importante, pois ainda fazemos muita coisa nele, como consultas para emitir relatórios, etc…, e por isso comentamos todas as colunas de todas as tabelas.
Então está havendo um confronto entre banco e UML e estou meio perdido para quem dar importancia.
Queria saber como o pessoal está trabalhando.
Se parte do diagrama classes, gera código java e o hibernate gera o banco, nesse caso a geração do hibernate é legal? Eu teria que entrar no banco depois e comentar todas as colunas ou o hibernate aproveita o comentário do campo?
Ou o pessoal parte do código e faz engenharia reversa gerando o diagrama de classes e criando o banco através do hibernate.
Qual a importância do banco de dados nesse contexto, devo “esquecer que ele existe” ou não?
Então, queria alguma diretriz para saber a ordem mais produtiva de trabalhar e quais ferramentas utilizar.
Por favor comentem sobre essa parte do ciclo de desenvolvimento de vcs.
Obrigado,
Olá Mauren,
alguns pontos importantes pra você se questionar:
- 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?
- 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.
- 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).
- 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.
- 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:
-
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.
-
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?
-
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.
[quote=maurenginaldo]
- 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. [/quote]
Você pode ao invés de manter atualizado, extrair um diagrama a partir do código quando necessário.
[quote=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? [/quote]
Da uma testada novamente. De qualquer forma, existem outras alternativas
[quote=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: [/quote]
Você pode usar o definition pra fazer isso.
[quote=maurenginaldo]
E com relação a comentários dos campos, existe alguma anotação que gera os comentários para as tabelas? [/quote]
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.
[quote=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.[/quote]
: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.
[quote=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.[/quote]
Estou com esse pensamento de deixar o banco de dados um “pouco de lado” e me preocupar com os objetos.
- Estou pensando em fazer o diagrama de classes inicial no Jude por exemplo
- Gerar as classes (código-fonte).
- Anotar as classes
- 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, 
