2

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.

NoChance
  • 12,412
  • 1
  • 22
  • 39
artemis
  • 123
  • 4
  • Association and Composition are runtime concepts, while Generalization (inheritance) is a compile-time concept. See [here](https://en.wikipedia.org/wiki/Object_diagram#External_links); generalization is not mentioned in the body of the article. – Robert Harvey Jul 09 '19 at 02:20

2 Answers2

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.

Simon B
  • 9,167
  • 4
  • 26
  • 33
  • 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 09 '19 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 '19 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 '19 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 '19 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.

Fuhrmanator
  • 1,435
  • 9
  • 19
  • You use a shared aggregation without describing its semantics (see p. 100 of UML 2.5). Down vote. –  Jul 14 '19 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 '19 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._ –  Jul 14 '19 at 16:07
  • If you just would use a filled diamond (composite) I would not mind and retract the DV. –  Jul 14 '19 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 '19 at 16:25
  • No. It means that the ID card is invalid when the student goes away. That would be fine. But a shared composition has just no defined meaning; and thus the whole model. See Robert's comment at the very top. –  Jul 14 '19 at 16:41
  • @qwerty_so 2.5.1 and https://martinfowler.com/bliki/AggregationAndComposition.html don't say it's wrong, but rather it has ambiguous semantics. To quote Fowler, "**composition** (black diamond) does carry semantics. The most particular is that an object can *only* be the part of one composition relationship." I agree that it's not usual for an idcard to be in the possession of another student, but for fraud detection, you would not want to assume composition. Aggregation requires additional explanation, which I have done. – Fuhrmanator Jul 14 '19 at 17:18
  • You can quote anyone. But the specification is the book published by OMG. Why not reading the original at the specified location? –  Jul 14 '19 at 17:44
  • _she has a student ID card (a real, separate object)._ is just a simple association. –  Jul 14 '19 at 17:47