Opinião sobre Modelagem que visa reusabilidade

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). 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.

Listar metodos de classes antes os atributos?

Acho um pouco estranho isso. Ainda mais, no modelo de domínio.

marcosbrandao:

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]

Listar metodos de classes antes os atributos?

Acho um pouco estranho isso. Ainda mais, no modelo de domínio.

Deixa eu tentar ser um pouco mais claro,
O sistema a qual estou modelando, é para um hotel que atende pessoas do mundo inteiro.

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).

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?

Antes de continuar modelando: http://www.google.com/search?q=bduf

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

De acordo com um tal BOB

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)

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

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.

rpffoz:

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

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.

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.

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.

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.

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.

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.

rpffoz:

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.

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.

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.

A Paz!

rpffoz:

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.

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.