3

I like to create simple class diagrams for my projects. Most of the time I just use composition, inheritence and associations. IBM's basic UML resource tells all about this.

However I'm using ruby so I got the option to define a module with some methods. I can just include this module in every class where I want to use these methods. This could be interpreted as an inheritence, however some of my classes are already child classes of an other class and I don't want to mix the meaning of a symbol used in my diagrams.

How should I display an included module in my class diagrams in UML?

Improve this question

3 Answers 3

Reset to default
1

UML does not have this kind of module concept, so it aso does not have a defined way to represent them in a diagram.

A few possibilities are:

  1. Don't show the module inclusion in your UML diagrams. UML does not require all details to be present in the diagrams and you can just decide that the fact that some of the methods are actually provided through Ruby's module mechanism is one such hidden detail.
  2. Model the Ruby modules as UML packages/classes and use a simple dependency to indicate the inclusion.
  3. Model the Ruby modules as a special kind of base class (you can mark them as special by using a stereotype for them, for example <<module>>)
Improve this answer
1

As it was suggested in another answer, it might be worthless to include the module in your diagram.

If you do it anyway, I think you could do the following (some were suggested in another answer):

  • You can consider the methods and variables in a module as static. you should thus underline them.
  • You can create a specific stereotype for the modules to qualify them better.
  • You should only use depency relationships (such as << use >> )
Improve this answer
1

One option would be to extend UML. That's what Schärli et al did when they invented traits, which are close relatives to mixins. The simply invented an addition to UML that allowed them to represent traits. Of course, such mixin-extended UML can no longer be produced or processed by existing UML tools, you would have to extend those tools, too.

An alternative is to look at what a mixin really is at its core: a mixin is a class that is parameterized over its superclass. (Think: class MyMixin<T> extends T.) In Ruby, that's even how it's actually implemented: include creates a new class which shares its method, constant and module/class variable tables with the mixin, gets the current superclass of the class it is included into as its superclass and then becomes the mixed-into classes' superclass.

Compared to multiple inheritance: with multiple inheritance, a class may have multiple superclasses but only appears once in the inheritance graph. With mixins, a mixin class may appear multiple times in the inheritance tree but at each occurrence has only one superclass (which may be different from the other occurrences).

So, you could represent a mixin as a superclass in the inheritance chain of every class it is being mixed into, with some additional relationship between those classes to indicate that those are actually the same mixin, just with different superclasses. For example, represent them as template instantiations (<<bind>>) of a MyMixin<T> template which has T as its superclass (if that's possible). Or just make up your own relation, such as <<same mixin>> or something.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.