3

Let's say I have the following class :

public class ParentClass{}

And one of its children classes is :

public class ChildClass extends ParentClass{}

Let's consider another class :

public class Foo{
    
    private ParentClass field;
    
    public Foo(){
        
        field = new ChildClass();
        
    }
    
    public static void main(String[] args){
        
        Foo foo = new Foo();
        
    }
    
}

When drawing the Object Diagram of foo I don't know if I have to write ChildClass :

enter image description here

Or ParentClass :

enter image description here

Axel Carré
  • 303
  • 1
  • 5

1 Answers1

3

In your program field is an instance of ChildClass, the goal of the object diagram is to show instances with their effective type (and their attributes value if they have) => the right diagram to use is

enter image description here


[edit from remarks to my answer]

It is also legal to use the second diagram, but that one hide the fact the instance is for sure an instance of ChildClass, so better to use the first diagram to indicate that.

I forgot to mention in both your diagrams the line between the two instances does not correspond to the alone association between them, a right way to do for the first diagram is :

enter image description here

considering your instance of Foo is saved through a variable named foo it seems reasonable to name foo your instance of Foo

bruno
  • 32,421
  • 7
  • 25
  • 37
  • 1
    Thank you, I wanted to do it this way but I wasn't sure. – Axel Carré Nov 24 '20 at 22:21
  • When placing the name of the object in front of the colon it would be even clearer. – qwerty_so Nov 24 '20 at 23:39
  • Interesting. I'm not a big user of object diagrams, but I would have used `foo:Foo --- field:ParentClass` because in the known class of `field` is `ParentClass`. Where is it said in the specs that it shall show the effective type? I only found page 125 "*The purpose of an InstanceSpecification is to show what is of interest about the instance. The instance conforms to each classifier of the InstanceSpecification*...", which would leave the choice of the one, or the other, or both alltogether depending on what is of interest for the diagram. – Christophe Nov 24 '20 at 23:54
  • Moreover isn't the spec sentence "*It is important to keep in mind that InstanceSpecification is a model element and should not be confused with the instance that it is modeling.*" an open door for not necessarily using the effective type of an object ? – Christophe Nov 25 '20 at 00:00
  • 1
    @Christophe may be I was not clear enough in my answer, I did not say the second diagram is wrong. Knowing the instance of *Foo* is associated for sure with an instance of *CHildClass* why to hide that in the diagram ? Why do we make diagrams, to hide knowledge/information or to show it ? For me *show what is of interest about the instance* starts by the effective type of the instance in that context. – bruno Nov 25 '20 at 07:30
  • @Christophe `I would have used foo:Foo --- field:ParentClass` you are wrong, *field* is not the name of the instance of *ParentClass/ChildClass* but the name of the attribute/association end. I edit my answer to improve diagram representation – bruno Nov 25 '20 at 07:43
  • 1
    Learned something new too :-) – qwerty_so Nov 25 '20 at 08:07
  • @bruno Correct me if I'm wrong, here field is the name of the ChildClass field in Foo, if this ChildClass object was passed for example by the constructor and had a reference we would write its name in front of :ChildClass? Basically you put the field name next to the arrow link, and the name in front of the colon if it has a reference in the outer scope? – Axel Carré Nov 25 '20 at 08:23
  • @dylanbatio first you can name the instances as you like, whatever the way there are managed in the source code if this one exist. The instance's name is written before ':' into the rectangle representing the instance. Considering the representation of the association it is like in a class diagram, see § 9.8.5 from page 129 of [formal/2017-12-05](http://www.omg.org/spec/UML/2.5.1) – bruno Nov 25 '20 at 11:59