Olá senhores comecei uma nova modelagem, e resolvi fazer de uma forma que fosse reusável,
a modelagem não está completa, mas gostaria muito da opinião de vocês.
Percebam que usei um AbstractObject que prove uma identificação númerica para ser usada no banco de dados,
e um nome que abstrai por exemplo: Descrição de uma Categoria, Nome de um País e etc… e também um outro atributo
"dataCadastro" que é inicializado com a Data Atual toda vez que é instânciado.
Um delhalhe que não sei se é errado, é que nem no caso do Telefone, ele herda de AbstractObject e não usa o atributo nome,
isto é errado?
Gostaria também de uma solução para o meu cliente, já olhei outros post’s no forum mas nenhum foi concretizado (Pelo menos os que eu vi)
Outro detalhe envolvendo Pessoas, é o Telefone, de que forma eu posso modelar isso?(Depois quero ver no banco… =x)
E Quanto a atributos, principalmente das pessoas alguém sabe uma referencia de onde eu posso encontrar? ou se quiserem citar, acredito que
isso é muito útil para o forum.
Creio que o sentido das relações de composição estão incorretos. O losango preenchido deve ficar na parte do todo. Da forma que está seu diagrama, um estado de vários países. Compare com a relação entre AbstractPessoa e Endereco: esta está correta (uma pessoa tem vários endereços). E não esqueça a cardinalidade.
Analise também se algumas composições não podem ser substituídas por agregações. Uma pessoa só existe no sistema se tiver endereços?
Veja neste tópico uma discussão sobre modelagem de pessoa física e pessoa jurídica. Veja se as sugestões atendem suas necessidades.
Não gostei do fato de você detalhar endereço até o nível de país, esse tipo de detalhamento é irrelevante para a maioria dos negócios, além de não ser a única opção de modelagem. Exemplo: se todos os endereços só pudessem pertencer ao território brasileiro, você poderia dizer que endereço possui os atributos CEP, número da residência e complemento, só.
Outro que eu não gostei é o AbstractObject, que não faz parte do domínio de negócio e só existe porque você está pensando na UML com a cabeça na sua implementação Java (em Ruby, por exemplo, interfaces são desnecessárias).
Por fim, você modelou o diagrama de classes da UML como se fosse modelagem de dados. E não é assim! Cadê, por exemplo, os métodos que os objetos implementam? E não vale ser só getters e setters! Pra ajudar a você construir um diagrama melhor, esforce-se a modelar na seguinte ordem (apesar de não precisar seguir a ferro e fogo):
[list] Crie as “caixinhas” que representam as classes do domínio de negócio[/list]
[list] Mostre os relacionamentos entre as classes[/list]
[list] Distribua os métodos nas classes[/list]
[list] E por fim (sim, isso deve ser a última coisa a ser feita, não a primeira), coloque os atributos das classes[/list]
Repare que, também, você não vai conseguir saber quais métodos as classes vão ter, sem antes fizer os casos de uso. Então, prepare-se pra ralar.
[quote=marcosbrandao][quote=Leonardo3001]
[list] Crie as “caixinhas” que representam as classes do domínio de negócio[/list]
[list] Mostre os relacionamentos entre as classes[/list]
[list] Distribua os métodos nas classes[/list]
[list] E por fim (sim, isso deve ser a última coisa a ser feita, não a primeira), coloque os atributos das classes[/list]
[/quote]
Listar metodos de classes antes os atributos?
Acho um pouco estranho isso. Ainda mais, no modelo de domínio.
[/quote]
Se entendi o ponto do Leonardo3001, você começa a modelar o sistema pensando no que ele deve fazer (métodos), antes de pensar no que ele precisa pra fazer (atributos). Se você começa a modelar o sistema a partir dos casos de uso, creio que é natural agir dessa forma.
Deixa eu tentar ser um pouco mais claro,
O sistema a qual estou modelando, é para um hotel que atende pessoas do mundo inteiro.
[quote=tnaires]Olá
Creio que o sentido das relações de composição estão incorretos. O losango preenchido deve ficar na parte do todo. Da forma que está seu diagrama, um estado de vários países. Compare com a relação entre AbstractPessoa e Endereco: esta está correta (uma pessoa tem vários endereços).
[/quote]
Estou usando o JUDE, e usando a ferramenta de exportação para código java, da forma que está a modelagem me gera um código assim:
public class Pais extends AbstractObject {
private String sigla;
...
}
public class Estado extends AbstractObject {
private String sigla;
private Pais pais;
...
}
public abstract class AbstractPessoa extends AbstractObject {
private String email;
private Endereco endereco;
...
}
Perceba que estou modelando o que é transiente, não uma estrutura de dados, logo o País tem um estado.
Como aprensentado, é uma modelagem para um hotel internacional, fora que este hotel fiica em Foz do Iguaçu, então no mínimo é contante a presença de um Argentino, ou um Paraguaio.
Concordo contigo amigo, mas esta foi a forma que achei de representar como está a distribuição dos objetos. a minha dúvida mesmo era quanto ao uso do AbstractObject você acha legal usar isso? ou devo repetir ID’s, nomes, e data de Cadastro em todas as classes?
A relação AbstractPessoa - Endereco está correta conforme esperado, mas a relação Estado - Pais que me pareceu estranha. No diagrama, seus resultados estão contraditórios. Mas se o JUDE gerou o código corretamente, tudo bem.
Entretanto, da forma que está, um Pais tem apenas um Estado. O atributo que armazena o Estado deveria ser uma Collection. Aí entra a questão da cardinalidade, que citei acima.
Abraços
Não sei se entendi o que você quis dizer, mas se for quanto a especificações e análise, já foi feita,
a questão é somente quanto ao uso do AbstractObject e dúvida quanto a Pessoa ter muitos telefones (Como posso representar isso? no código eu sei =x)
[quote=tnaires]A relação AbstractPessoa - Endereco está correta conforme esperado, mas a relação Estado - Pais que me pareceu estranha. No diagrama, seus resultados estão contraditórios. Mas se o JUDE gerou o código corretamente, tudo bem.
Entretanto, da forma que está, um Pais tem apenas um Estado. O atributo que armazena o Estado deveria ser uma Collection. Aí entra a questão da cardinalidade, que citei acima.
Abraços[/quote]
Acho que estamos confundindo, não estou modelando a estrutura de dados, estou modelando um Diagrama de Classes,
Então em memória eu apenas preciso saber a que Estado aquele País pertence, talvez esteja confuso para você porque não representei a cardinalidade.
Agora quando partir para a modelagem de um MER/DER ai sim representarei Um País tem muitos Estados.
[quote=rpffoz][quote=tnaires]A relação AbstractPessoa - Endereco está correta conforme esperado, mas a relação Estado - Pais que me pareceu estranha. No diagrama, seus resultados estão contraditórios. Mas se o JUDE gerou o código corretamente, tudo bem.
Entretanto, da forma que está, um Pais tem apenas um Estado. O atributo que armazena o Estado deveria ser uma Collection. Aí entra a questão da cardinalidade, que citei acima.
Abraços[/quote]
Acho que estamos confundindo, não estou modelando a estrutura de dados, estou modelando um Diagrama de Classes, Então em memória eu apenas
preciso saber a que Estado aquele País pertence, talvez esteja confuso para você porque não representei a cardinalidade.
Agora quando partir para a modelagem de um MER/DER ai sim representarei Um País tem muitos Estados.[/quote]
Não, não.
O conceito de cardinalidade existe TAMBÉM no diagrama de classes. Se você modela a relação entre um Carro e seus objetos do tipo Pneu, você tem que especificar na composição que um carro tem quatro pneus. Da mesma forma, um Pais tem vários objetos Estado, mas cada Estado só pertence a um Pais.
O problema é que você está modelando as classes como se fosse modelagem de dados (apesar disso, as cardinalidades existem na UML), o que leva a um resultado ruim.
Se você não dissesse que era para um hotel internacional, eu nunca poderia adivinhar, afinal as classes não dizem isso.
O ideal é você começar com casos de uso, e seguir os passos que eu citei acima.
[quote=tnaires]
Não, não.
O conceito de cardinalidade existe TAMBÉM no diagrama de classes. Se você modela a relação entre um Carro e seus objetos do tipo Pneu, você tem que especificar na composição que um carro tem quatro pneus. Da mesma forma, um Pais tem vários objetos Estado, mas cada Estado só pertence a um Pais.[/quote]
OK!, eu apenas havia dito que não havia representado a cardinalidade, mas eu sei que deve existir a cardinalidade.
Quanto ao sentido das relações, realmente eu estava equivocado, desculpas amigo, por favor verifique a correção acima.
[quote=Leonardo3001]O problema é que você está modelando as classes como se fosse modelagem de dados (apesar disso, as cardinalidades existem na UML), o que leva a um resultado ruim.
Se você não dissesse que era para um hotel internacional, eu nunca poderia adivinhar, afinal as classes não dizem isso.
O ideal é você começar com casos de uso, e seguir os passos que eu citei acima.[/quote]
Entendi perfeitamente o que você quiz dizer, e entendo que dar comportamentos a uma classe é importante na modelagem.
Casos de Uso? já foram feitos. O que eu quero mesmo, é só a opinião de vocês sobre o uso do AbstractObject.
[quote=rpffoz][quote=Leonardo3001]O problema é que você está modelando as classes como se fosse modelagem de dados (apesar disso, as cardinalidades existem na UML), o que leva a um resultado ruim.
Se você não dissesse que era para um hotel internacional, eu nunca poderia adivinhar, afinal as classes não dizem isso.
O ideal é você começar com casos de uso, e seguir os passos que eu citei acima.[/quote]
Entendi perfeitamente o que você quiz dizer, e entendo que dar comportamentos a uma classe é importante na modelagem.
Casos de Uso? já foram feitos. O que eu quero mesmo, é só a opinião de vocês sobre o uso do AbstractObject.
[/quote]
Fala brother, blz? Seguinte, quando falaram pra vc observar sua modelagem é que vc está tomando uma decisão de modelagem. Ou seja, decisão que deveria ter sido tomada na fase de análise. Bom, não sei como vc está desenvolvendo. Se está usando uma metodologia ágil ou não, mas sobre reuso te recomendo ler sobre Analysis Patterns. Infelizmente, não posso ver o diagrama que postou (devido ao acesso restrito da net onde estou acessando ) e não vou poder opinar mais.
[quote=rpffoz][quote=Leonardo3001]O problema é que você está modelando as classes como se fosse modelagem de dados (apesar disso, as cardinalidades existem na UML), o que leva a um resultado ruim.
Se você não dissesse que era para um hotel internacional, eu nunca poderia adivinhar, afinal as classes não dizem isso.
O ideal é você começar com casos de uso, e seguir os passos que eu citei acima.[/quote]
Entendi perfeitamente o que você quiz dizer, e entendo que dar comportamentos a uma classe é importante na modelagem.
Casos de Uso? já foram feitos. O que eu quero mesmo, é só a opinião de vocês sobre o uso do AbstractObject.
[/quote]
A decisão de usar seu AbstractObject não deve ser absoluta. Ela deve depender das necessidades do seu projeto em particular. Não tente encontrar uma solução que resolva todos os problemas, pois é muito provável que em um determinado momento você encontre alguma situação que precise ser resolvida usando uma abordagem diferente. E, quando esse momento chegar, pode ser tarde demais para fazer um refactoring, já que tudo o que foi desenvolvido até então está extremamente dependente da abordagem inicial.
Por exemplo, todas as suas entidades realmente precisarão ter um identificador inteiro? Todas as suas entidades precisarão da data de cadastro? Todas as entidades usarão o atributo nome? Todas as entidades precisarão usar os métodos inerentes a esses atributos?
) e não vou poder opinar mais.