3

According to my professor, one of the following relationships cannot be modeled in an object instance diagram:

  • Association
  • Composition
  • Generalization

I made the argument that the association could not be modeled in an object instance diagram, since that is more abstracted and is typically for a class diagram, while the other two are more concrete. However my TA told me I was wrong, and did not offer additional clarification.

I have read this post and looked up this page. Any guidance is appreciated.

Improve this question
1
  • Association and Composition are runtime concepts, while Generalization (inheritance) is a compile-time concept. See here; generalization is not mentioned in the body of the article.
    – Robert Harvey
    Jul 9, 2019 at 2:20

2 Answers 2

Reset to default
4

Association and Composition make sense for objects, as well as classes. An object may use another (Association), and an object may contain another (Composition).

But you can only Generalize a base class to create a derived class. It's not possible for one object to be a Generalization of another object. If the base class isn't abstract, it's possible to have objects of both the based and derived classes, but there's still no sense that the derived object inherits from the base object; it still inherits from the base class.

Improve this answer
4
  • This is good. Unfortunately the fact that generalization can't be shown, limits the value of the Object Diagram. Since values of the parent class will not show.
    – NoChance
    Jul 9, 2019 at 22:38
  • I'll have to look it up, but if I recall correctly instead of association on object diagram you use link. So technically neither of the three can be use obsługi object diagram.
    – Ister
    Jul 10, 2019 at 12:57
  • 2
    @nochance, the value of object diagram lies elsewhere. Every single object is an actual instance of a specific class. While this class inherits from its parents you can always point the one specific class that was used. The way how generalizaron is implemented depends on the programming language and usually the child class directly inherits all properties of its parent class so it's fine if you just show the values of attributes find child and parent class alike.
    – Ister
    Jul 10, 2019 at 13:01
  • @Ister, yes, but do you show the inherited attributes in an object diagram? Where would they appear? Say the parent has 40 attributes, and the inherited class only have 3 do you only show the 3 attributes? I know the answer, just wanted to complete the picture. Personally I see the instance diagram could be substituted for with other information manifestation means.
    – NoChance
    Jul 10, 2019 at 22:51
0

It might help to remember that classes don't really exist in the real world (they exist in our mental models), but objects do exist. So, when I'm using a UML object diagram, I'm showing things that are instances, usually of real-world things.

For example, if I say a Student is a Person, it's a generalization relationship. That relationship exists mentally, and you can show it in a UML class diagram.

enter image description here

But if I'm talking about a person named Jane Doe born on July 14, 2002, there is only one object, although she may be a Person and a Student. There are not separate objects in the real world if a person is also a student. If the purpose of the diagram is to speak of the object as a Student, then you would show that in the diagram. But it makes no sense to show a relationship to Person, since it's not an object (but a class):

enter image description here

On the other hand, with association and composition (aggregation), you can show in the object diagram that Jane is associated with her university (a real, separate object), and that she has a student ID card (a real, separate object).

enter image description here

Finally, class and object diagrams complement each other. It's not possible to show concrete cases in class diagrams, just as it's not possible to show generalizations in object diagrams. They work on different levels of abstraction.

Improve this answer
9
  • You use a shared aggregation without describing its semantics (see p. 100 of UML 2.5). Down vote.
    – user188153
    Jul 14, 2019 at 10:06
  • @qwerty_so thanks for having the courage to explain the downvote. I'm not sure where UML 2.5 semantics fits into the OP's question, but you are free to downvote for that. I mostly use UML for sketching designs and solutions.
    – Fuhrmanator
    Jul 14, 2019 at 15:01
  • Please read p. 110 (wrong # above) in 2.5 or p. 112 in 2.5.1. about shared aggr: Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
    – user188153
    Jul 14, 2019 at 16:07
  • If you just would use a filled diamond (composite) I would not mind and retract the DV.
    – user188153
    Jul 14, 2019 at 16:08
  • @qwerty_so composition would imply it's impossible for a student to (steal or) use another student's ID card, and the reality of the university I went to was not like that.
    – Fuhrmanator
    Jul 14, 2019 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.