What does these UML diagram arrows mean in Iterator pattern that are drawn from ConcreteAggregate to ConcreteIterator and backwards. I have looked thorough the legend (notations) of UML diagrams, but I guess that was more confusing than explaining.

As much as I understand the arrows mean that ConcreteAggregate is dependent on ConceteIterator, and ConcreteIterator uses ConceteAggregate. But what does that clearly mean? What is the difference of uses and depends on?

enter image description here

  • 2
    Where did you get this pattern?
    – Aaron Hall
    Oct 25, 2016 at 15:37
  • Of course, GoF! :)
    – Narek
    Oct 26, 2016 at 5:41
  • it's actually not UML but OMT
    – Lovis
    Oct 31, 2016 at 15:42
  • 1
    @Machado uml basically took Parts from OMT and made it better/more consistent. It's funny. Everybody knows GoF book, but nobody read the intro were they explain it ;-P
    – Lovis
    Oct 31, 2016 at 16:15
  • 1
    @Machado: Also, keep in mind that GoF is a twenty-two year-old book. Oct 31, 2016 at 16:19

3 Answers 3


The Gang Of Four Book does not use UML but OMT (or it's at least based on OMT)

  • The dotted arrow means "instantiation", so it says that the ConcreteAggregate creates the ConcreteIterator.
  • The normal arrow means containment (a weaker relationship than aggregation, so while it knows the other object it's not responsible for it's lifecycle).
    The ConcreteIterator contains a ConcreteAggregate. This is also visible in the displayed constructor call return new ConcreteIterator(this)

Source: The GoF Book

  • Excellent ! Indeed it's OMT as explained in appendix B. Note however that the authors explained that the dotted arriw notation is not part of the OMT and they took the freedom to add it to the notation. Also worthwhile mention that UML uses the same kind of notation to represent class dependencies, one of which being the instantiation.
    – Christophe
    Dec 18, 2016 at 11:18

The class ConcreteAggregate depends on the class ConcreteIterator because the CreateIterator() method creates an instance of the ConcreteIterator class and returns it to the caller as an instance of the more general Iterator class.

The ConcreteIterator class has a constructor that is not shown on this diagram. What must be the case is that the CreateIterator() method is passing its own instance (i.e., this) as a parameter to that constructor. The ConcreteIterator class stores the reference that was passed to it as a member variable, shown in this UML diagram as a unidirectional association.

You didn't ask, but I will tell you that there are many problems with the UML on this diagram. Therefore, do not use this book to learn UML!

For example:

  • The triangles shown on the generalization relations should be drawn at the top of the line, not on the middle of the line.
  • The association arrowheads are supposed to be open (like <--).
  • The associations do not show association-end properties, such as the one representing the member variable that the constructor for the ConcreteIterator class sets. I would expect to see something like creatingAggregate near the arrowhead.
  • The associations do not show any multiplicity, which defaults to [1..1] in UML. That implies that an instance of the Client class must have a reference to an instance of the Iterator class at all times, which is obviously impossible. (An instance of Client must first call that CreateIterator() method to get that reference!) That multiplicity should have been optional [0..1].
  • The CreateIterator() method shows no return type of Iterator.

Correcting some of these mistakes may have made this book more understandable for you.

  • 1
    GoF uses OMT notation. so there is no "problem with the uml" since it's not uml.
    – Lovis
    Oct 31, 2016 at 15:34
  • Well, this question was tagged as "UML", but even for OMT it still has problems. Just one I can remember is that optional multiplicity is shown with a hollow ball at the end of an association.
    – Jim L.
    Oct 31, 2016 at 17:31
  • Oh, I see you also came here xD
    – user188153
    Nov 30, 2016 at 11:02
  • Indeed GoF in appendix B explain that it's OMT but that they took some liberties as for example the dotted arrow, because nothing in OMT could represent the instantiation dependency. So it's not UML but almost. By the way, are you sure that absence of multiplicity defaults to 1..1 ? Isn't it just unspecified ?
    – Christophe
    Dec 18, 2016 at 11:38
  • I am sure about the multiplicity because I have had to change a profile specification that wanted to default to 0..*.
    – Jim L.
    Dec 18, 2016 at 12:23

ConcreteAggregate has a compile-time dependency on ConcreteIterator, as shown in the code in the annotation box. The author of the diagram thought this dependency was important enough to show not only in the comment but also as the dashed arrow, a notation which can indicate any kind of dependency.

The two classes are also associated, indicated by the solid line. The association is one-directional (indicated by the arrow), meaning that ConcreteIterator is aware of the association but ConcreteAggregate is not. In practice, this means an instance of ConcreteIterator holds a reference to an instance of ConcreteAggregate.

This diagram is focused on the relationships that are relevant to the CreateIterator() operation. This first indication of this is the lack of any other responsibilities shown for Aggregate.

  • Thanks for your answer but it is still very confusing. :) I don't get the point.
    – Narek
    Oct 26, 2016 at 5:45
  • @Narek: while this answer is correct, see if my answer makes any more sense to you.
    – Jim L.
    Oct 31, 2016 at 14:25
  • Compile time is irrelevant in uml. UML models could be implemented with interpreted or dynamic languages as well.
    – Christophe
    Dec 18, 2016 at 11:45

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.