UML for javascript?

Question

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    |
   |     |-----|
   +---->|     |
         +-----+

Champion

Answer 1

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:

Towney

Not entirely accurate that there's no difference between an object and it's class. At least not from a type theoretical point of view. Any object has a given type. Any object with the same prototype derives from the same type and any object with the same prototype and the same object properties has the same type. So you can have and are indeed likely to have more objects than types. That however doesn't invalidate your point :) – Distract

A more technically correct way of saying it is that there is no representation of class in JavaScript. – Redpoll

Since there has a been a few years since this post. Let me just make it clear to whoever else reads this that ECMAScript 2015 includes classes now and does not stray away from prototype-based inheritance. link – Bratcher

Answer 2

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.

Melanesian

Answer 3

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?

Unruh

Why not use inheritance? I believe it's more suitable in this case, because inheritance indicates much closer relationship between two objects than just dependency. I would ignore that you shouldn't use class diagrams, UML wasn't designed with prototype-based inheritance in mind. – Towney

I would use UML inheritance for JS if the OP's example were different, e.g. a Shape ctor w/ a prototype and a Circle ctor whose prototype was linked to Shape.prototype! But the OP showed only individual objects, and never showed anything that looked like subclassing to me. All I could see was objects being derived from other objects. If anything, in the first example, it is more like a is the "type" and b is the "instance" (that is how Object.create is used). No subclassing. I do agree with you, though, that we should exploit UML's flexibility and ignore things where necessary. – Unruh

Inheritance using just Object.create is quite common practice. Another reason why I believe that inheritance is better approach here is that any properties within object a are "inherited" by b, they become part of b`s interface. – Towney

Your approach is to put an emphasis on prototype link. That might be ok, if you want to explain to somebody how prototype chain and property lookup works. That is not a common scenario though IMO. In the end, it depends on target audience for your diagram :-) – Towney

Sure, fair enough. There's nothing at all wrong with traditional UML inheritance links in JavaScript because you can certainly simulate interface inheritance with prototypes. Whether common or not, the way I read the OP's question (it seemed clear as anything to me!) was that it asked "how do I represent a particular relationship between objects? Perhaps the intent of the question was something else, who knows. Clearly if the target audience is to consume a high-level model, then a class diagram is fine. – Unruh