Oi, quando eu vou fazer um sistema OO usando a linguagem Java eu so preciso fazer o UML do BD ou preciso fazer o MER (Modelo Entidade Relacionamento) do BD, com suas referências, etc.?
Não existe uma regra exata para ser seguida.
Principalmente em relação a documentação.
Dê uma estudada em Metodologia Ágil, que você irá ter uma visão diferente sobre documentação detalhada em desenvolvimento de softwares.
Particularmente elaboro o Diagrama de Caso de Uso Geral, Diagrama de Classes (para verificar as classes existentes e suas relações) e o Diagrama de Sequencia (para verificar a sequencia de trocas de mensagens entre os objetos). Na faculdade, para fins de entendimento, solicitam a elaboração de todos os diagramas dos quais nem todos eu aplico de forma adequada.
1 curtida
hoje estou tentando me policiar em não mexer com BD até terminar uma história, após a historia concluída, sento e vejo o MER que muitas vezes nem sequer gero documento algum (alias quase nunca)
Quando eu tinha DBA eu deixava isso exclusivamente para ele, mas agora tenho que me preocupar com indices, restrições, etc… mas só o que o Hibernate não gera automatico!
O correto seria vc desenhar o seu modelo de dominio (diagrama de classes especificamente para o seu banco, ou seja, suas Entities) e, a partir dele sair o diagrama de entidade e relacionamento.
Vi com meus professores e eles recomendam fazer todos.
Modelos Academicos != Modelos Profissionais
Tudo é preciso na faculdade pra vc treinar e ser avaliado na construção de um modelo, para, teoricamente, quando chegar no mercado saber fazer…
Mas acredite, no mundo profissional poucos são so modelos utilizados, as vezes, nenhum com exceção de um diagrama de classe e um documento de arquitetura…
Ultimamente, pra mim, JavaDoc é o melhor modelo possivel!
A maioria dos professores fazem isso… Típico da síndrome de waterfall hehehe
Mas isso é estudo… o cara tinha que fazer todos os diagramas mesmo… até o Diagrama de Robustez (acredite, um cliente grande, mas grande mesmo, só trabalha com robustez e exige a entrega)…
Diagrama de classes especificamente para o seu banco ? Como assim ? A relação entre o diagrama de classes e as tabelas do BD raramente vai ser 1 pra 1.
Mas como tu é meu amigo vou considerar que tu quis dizer a coisa certa mas se expressou mau 
Diagrama de classes especificamente para o seu banco ? Como assim ? A relação entre o diagrama de classes e as tabelas do BD raramente vai ser 1 pra 1.
Mas como tu é meu amigo vou considerar que tu quis dizer a coisa certa mas se expressou mau
[/quote]
Calmae, calmae… deixa eu me “re-expressar”, rs.
O correto seria modelar o dominio do sistema, as entidades que seu sistema terá, puramente OO, gerando um modelo (nesse caso o de classes de dominio). A partir dai, partir para um modelo de dados. Com exceção das cardinalidades many-to-many, o seu modelo de dominio tende a ser identico ao seu modelo de dados.
Vc não concorda com isso?!?
Nops
Dois exemplos que vem a mente agora são Herança e Value Objects dentro de Aggregates. Considerando que você modele seu Domínio seguindo boas práticas de Orientação a objetos e dependendo da estratégia que use para o banco no caso das Heranças (Por exemplo todas as classes de uma determinada hierarquia apontando para a mesma tabela) e ainda contando com many-to-many como você disse, o relacionamento entre elas vai ficar muito longe de 1 pra 1.
Não concordo não… vamos exemplificar pra ficar melhor?!?
O exemplo básico pra herança (Pessoa, PessoaFisica e PessoaJuridica) mais um exemplo de relacionamentos (Pedido, ItemPedido) e um exemplo de many-to-many (como Usuario, Perfil e UsuarioPerfil).
Aonde está a distância entre o modelo de dominio e o modelo de dados?
Exemplo dos Value Objects:
class Cliente {
private long id;
private String nome;
private Endereco endereco;
private InfoDeContato infoDeContato;
/* restante da classe */
}
class InfoDeContato {
private int telefoneCasa;
private int telefoneTrabalho;
private String email;
/* restante da classe */
}
class Endereco {
private String rua;
private String cidade;
private String estado;
/* restante da classe */
}As classes Endereco e InfoDeContato são Value Objects que fazem parte de um Aggregate encabeçado pela Entity Cliente, que serão mapeados juntoa a esta para a mesma tabela no banco de dados.
Na Heraça o fundamental é perceber que não necessáriamente PessoaFisica e PessoaJuridica serão 2 tabelas. Podem ser mapeadas para 1 tabela apenas, sei lá. Isso nada tem a ver com o Domain Model.
O exemplo que você colocou sobre Pedido e ItemPedido realmente deverá ficar 1 pra 1, mas essa não é a questão. A questão é que o Domain Model vai ser utilizado para depois criar as tabelas do banco de dados, mas não se pode cair no perigo de enquanto modela seu domínio ficar pensando no banco de dados pois ai é que geralmente surgem os erros de modelagem e eu já errei muito com isso. No início eu sempre ficava fazendo comparações com tabelas e depois nunca sabia porquê meu Domain Model não ficava OO como deveria.
Bom exemplo que vc colocou… Cliente, Endereço e InfoContato. Concordo plenamente com essa divisão.
Mas e ai?!? Qual a diferença de vc fazer Endereço e InfoContato ou colocar tudo na classe cliente pra iniciar um estudo de sistemas?!? Onde vc não consegue enchergar que algumas informações modeladas no dominio poderão surgir em uma mes aentidade no banco de dados?!?
Porm isso eu propuz o estudo do modelo de dominio antes de partir pro modelo de dados.
O que eu quiz dizer é que vc modela melhor se pensar no mundo real em OO primeiro pra depois partir pro mundo dos dados.
Saber onde colocar argumentos modelados de domain para relacional é outra coisa. Depende mais do DBA/AD do que do desenvolvedor…
Cara, a vantagem de ter uma Entity encabeçando um Aggregate com Value Objects você vai ter que ler sobre Domain Driven Design pra poder entender melhor sobre os Value Objects e Aggregates. Tem um livro grátis no InfoQ bem interessante sobre o assunto.
http://www.infoq.com/minibooks/domain-driven-design-quickly
Enxergo, porém não no momento que estou modelando o domínio. Vou ver isso na hora de fazer o mapeamento objeto-relacional.
[quote=rodrigoallemand]Porm isso eu propuz o estudo do modelo de dominio antes de partir pro modelo de dados.
O que eu quiz dizer é que vc modela melhor se pensar no mundo real em OO primeiro pra depois partir pro mundo dos dados.[/quote]
Eu li que você propôs isso. Só que você disse:
[quote=rodrigoallemand]
Com exceção das cardinalidades many-to-many, o seu modelo de dominio tende a ser identico ao seu modelo de dados. [/quote]
Não é bem assim. Esse é o ponto 
Cara, IMO eu acho que o desenvolvedor deve fazer o mapeamento e o DBA cuidar de tunning, etc etc etc. Mas isso ai é debate sobre os papeis de cada um, ai eu acho melhor deixar pra outra thread