Let's say my code is going to look like this:

public class MyController
    private Foo foo;
    private FooGenerator fooGen;


    public void work()
        this.foo = this.fooGen.generateFoo();

public class FooGenerator()
    public Foo generateFoo()
        String[] names = ["Andy", "Bob", "Charlie"];
        String[] colors =  ["Red", "Green", "Blue"];

        int nameIndex = new Random().nextInt(names.length);
        int colorIndex = new Random().nextInt(colors.length);

        return new Foo(names[nameIndex], colors[colorIndex], new Random().nextInt(100));

public class Foo()
    private String color;
    private String name;
    private int age;

    public Foo(String color, String name, int age)
        this.color = color;
        this.name = name;
        this.age = age; 

    public String toString()
         return "This Foo's name is " + this.name + ", color is " + this.color + ", and is " + this.age + " years old.";

So what we have is MyController HAS a FooGenerator, and is passed back a Foo from the FooGenerator, which MyController then utilises.

The question is, how do I represent this in a UML diagram?

3 Answers 3


[Disclaimer: I'm not a UML jockey, so don't take my word for it.]

I think, it would look like this.

enter image description here

Some details omitted for brevity.


I think first you should take a step back and think; what you are trying to communicate with the diagram, and to whom?

If you absolutely have to do it via a class diagram then Nick's answer is a reasonable approach. However Class diagrams are usually used for showing static structure, creates seems like a behavioural/lifetime relation so is better suited to a behavioural diagram such as an activity diagram

Lastly is the diagram even necessary? This seems like such a low level implementation detail the only person I can think who would be interested in it would be another developer? As a developer I think I'd rather just read the code, and maybe a brief comment stating that FooGenerator is a factory for Foo than wade through UML.

  • "creates seems like a behavioural/lifetime relation so is better suited to a behavioural diagram such as an activity diagram." Actually, lots of behavioral specification goes in a class diagram. EX: method signatures go in a class diagram, and they are certainly behavioral. When they're called and in what order would go in a behavioral diagram like a UML sequence diagram. Like you said, <<creates>> is a behavior. But like methods, creation is natural to express in class diagrams. When creation occurs and in what order should go in a sequence diagram.
    – kdbanman
    Commented May 21, 2015 at 15:06

Chiming in: this is a very small example of the ongoing "Model-Based" vs "Model-Driven" engineering debate. The question is what is the purpose of your model?

  • Model-Driven - you are trying to generate your code directly from your model. This was the thesis/goal of "Executable UML" and others. If you are working in this sort of team, you will need to study the details of how your particular tool generates code because UML itself does not provide prescriptive guidance on how code should be generated.
  • Model-Based - you are trying to use the modeling diagrams as a communications method to create "a single version of the truth" among a (usually diverse) set of stakeholders. For example, you may have an upcoming code review? Then you need to think about your audience. Do they need this level of detail up on the screen in the conference room? If so, I agree with the other commenter above...the fact that FooGenerator creates Foo is an activity. You might look at using a sequence diagram. FooGenerator goes in one swimlane and issues a "Create" message to another swimlane that contains "Foo" ...or something like this.

Hope this helps

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.