I'm looking for a way of graphically representing javascript objects...

I know there is UML, but for example, how to represent the chain between 2 objects, eg:

var a, b;

a = {};
b = Object.create(a);

Intuitively, I'd draw something like this:

+-----+
|b    |
|-----|
|     |
+--+--+
   |     +-----+
   +---->|a    |
         |-----|
         |     |
         +-----+

but is there a decent representation in UML?

And what about mixins?

c = $.extend({}, a, b)

+-----+           +-----+
|a    |           |b    |
|-----|           |-----|
|     |<----------|     |
+-----+           +-----+
   +     +-----+
   |     |c    |
   |     |-----|
   +---->|     |
         +-----+

I'm looking for a way of graphically representing javascript objects...

I know there is UML, but for example, how to represent the chain between 2 objects, eg:

var a, b;

a = {};
b = Object.create(a);

Intuitively, I'd draw something like this:

+-----+
|b    |
|-----|
|     |
+--+--+
   |     +-----+
   +---->|a    |
         |-----|
         |     |
         +-----+

but is there a decent representation in UML?

And what about mixins?

c = $.extend({}, a, b)

+-----+           +-----+
|a    |           |b    |
|-----|           |-----|
|     |<----------|     |
+-----+           +-----+
   +     +-----+
   |     |c    |
   |     |-----|
   +---->|     |
         +-----+

• javascript
• uml
• object-diagram

3 Answers 3

First thing you need to know is that JavaScript uses prototype-based inheritance. This means there is no distinction between classes and instances as in other OO languages (like Java). There are just objects. One implication of that is that differentiating between class and object diagrams does not make sense.

To your first example:

var a, b;

a = {};
b = Object.create(a);

This is inheritance - object b inherits properties of object a.

Correct way to model this in UML is this class/object diagram:

Mixins can be viewed as a form of multiple inheritance, object c is inheriting properties from object a and b, diagram for that might look like this:

It looks like you are trying to show the relationship between object instances in a class diagram. This will not really work; you probably want to try using a UML instance diagram (may also be called an object diagram). A class diagram is meant to capture system concepts, their structure and their relationships in a static way. It may help to start with a class diagram and then move to an instance diagram where you can plug some values in the "slots" or properties of you object instances to see if the model in your class diagram works.

Your examples are representing relationships between objects, not classes, so the UML object diagram is the way to go (as RobertMS has pointed out already).

The objects are related to each other in the sense that (in the first case) object a is the prototype of object b. I would use a dependency relationship for this. Wikipedia has a good description of the UML dependency notation here.

The rationale for using a dependency is that it reflects the notion that "a change to the influent or independent modeling element may affect the semantics of the dependent modeling element." Since we often use prototype objects to hold default properties, as well as methods, for a collection of "dependent" objects (i.e., objects of the same "class"), this use of dependency seems justifiable, if not maybe a little controversial.

I would label the dependency with the stereotype "<<proto>>".

UML does give you a lot of flexibility, though it is nice to follow convention.

There is a good treatment of object diagrams on this page by Scott Ambler.

In your second example, using jQuery's extend function, you don't have a true prototype relationship, but you are merging properties from some objects into another object. In this case, I'm not sure that there is a specific overarching modeling term for this. There is a kind of dependency here, though. I would suggest looking through the list of standard UML dependency stereotypes (listed on the above-mentioned Wikipedia page) and see if anything makes sense in your specific application. Perhaps <<refine>> works for you?