• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Modified Model - correct UML representation

 
Saket Mittal
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys,

I am trying to modify the given model for my assignment by introducing a parent class. Basically I have been given a Class A which is associated with classes B,C and D. The multiplicities between A and B , A and C is 1-1 and between A-D is 1-(1-*).

I want to introduce a parent class Parent which B,C,D would extend and show the relationship between A and the Parent. Class A would hold a Collection<Parent> . I am not sure my representation(association and multiplicity) is correct. I have shown the multiplicity at the Parent end as 1..* but should it be 3..* because of the given relationships between A and B,C,D ?

I have shown what is given and my modified version below. Can somebody please help me by confirming or correcting me ?

Thanks
Main.PNG
[Thumbnail for Main.PNG]
 
san kumar parihar
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Saket - My two cents...
a) It's okay to model inheritence but you can't always move relationships to the parent class. A child class can substitue parent class (Liskov principle) but I don't think it's true otherwise. It's hard to say much without context of your problem but I believe relationships should still be from A to B,C,D (even if you have a parent class). Whether you have 1..* or 3..*, you are loosing the fact that A is related one--> one with B and C?

b) Why is E extending from Parent?

 
Antoni Mysliborski
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From what I have read so far in this forum, unless you have a really serious reason to change BDM (eg. something very important is missing or there's an error in a given model), better don't do it. For sure not for the sake of optimization, simplifying or anything like that.

Especially that the previous poster is right - you have seriously changed the relations between classes. If you really need to add a superclass (there are many situations where you would be able to benefit from the fact of it's existence), add it, but keep the relationship between classes as they are now (so just note that B, C, D and E extend Parent, but the association still should be between A and B etc., not between A and Parent).

Many people have failed after introducing even less intrusive changes.
 
Saket Mittal
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks. I really appreciate your responses.

San:

a) The way I am visualizing my problem it is sufficient to know that classes B,C,D,E are of type 'Parent' class. I don't have to deal with specific subclasses. Since class A is holding just a Collection<Parent> I am only representing the relation between class A and 'Parent' as 1-to-many.

b) I want class A to treat classes B,C,D,E the same hence E extending 'Parent'. You can think of the class 'Parent' as the Component class of the Composite Design pattern with B,C,E being the leaves. Class D is the Composite of the pattern and is composed of class E.

Antoni:

I thought such modifications were fine especially because something similar has been done in the SCEA Study Guide by Cade and Sheil.
The business domain shows AvailabilityNotice as associated with Concrete, Wood and Steel classes. This was modified by introducing a parent class AvailabilityItem to Concrete, Wood and Steel classes and showing the association between AvailabilityNotice and AvailabilityItem.
But I'll seriously consider doing what you have suggested.

Thanks again,
 
Nilessh Ganu
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Saket Mittal wrote:
I thought such modifications were fine especially because something similar has been done in the SCEA Study Guide by Cade and Sheil.
The business domain shows AvailabilityNotice as associated with Concrete, Wood and Steel classes. This was modified by introducing a parent class AvailabilityItem to Concrete, Wood and Steel classes and showing the association between AvailabilityNotice and AvailabilityItem.


I am also using the generic class approach similar to the one used in Cade's book. Hope this is the correct approach!
Can someone who have passed please confirm this ?
 
Antoni Mysliborski
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's difficult problem, indeed. hard to say what is acceptable and what is not.

Bear in mind, that in your case you would relax the constraint, it would be possible to add 2 instances of B to A, what wouldn't be allowed in the original model - so this is in my opinion the argument against implementing such change.
 
Saket Mittal
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Antoni Mysliborski wrote:It's difficult problem, indeed. hard to say what is acceptable and what is not.

Bear in mind, that in your case you would relax the constraint, it would be possible to add 2 instances of B to A, what wouldn't be allowed in the original model - so this is in my opinion the argument against implementing such change.


Hi Antoni,

I was not thinking of relaxing the constraints. I assumed it would be the responsibility of class A to implement such constraints. Are you saying if I do not represent such constraints through the model then I'll have to provide this information through some other means like notes etc which is not good ?

Thanks for your comments.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic