The idea of applying a specific color schema to (UML) models to facilitate their understandability can be traced back to (at least) Peter Coad, Eric Lefebvre, and Jeff De Luca in their book Java Modeling In Color With UML: Enterprise components and process. In there, they proposed a four-color schema for UML class diagrams. In short, the color of a class would depend on the type of domain concept modeled by that class (moment-interval -> pink, party-place-thing -> green, description -> blue, role-participation -> yellow). Don’t worry if you don’t completely understand this classification, I don’t really get it either. Maybe they wanted to motivate people to buy the book :-).
Anyway, more than 10 years after that initial proposal, it seems that the topic has not gotten much traction, with a few exceptions. Cédric Brun blogged about Ecore in Colors where he implements the same pattern to allow the coloring of general Ecore models. Rational even published a UML Coloring plug-in back at the time. Colors can be attached to classes by name (using a regular expression to define the name), by stereotype, by keyword, by type (class, interface, and so forth) and by relationship (all elements related by a specified relationship type to a class of a certain name).
I think we all agree that the idea seems interesting but I’m still missing a clear answer to these two big questions:
- Does coloring really helps when trying to understand a model? If so,
- What is the best coloring strategy/schema to maximize this benefit?
The answer to the first question seems to be a rotund yes. From the work the Physics of Notations we understand that effective communication requires every notation to be composed by a set of graphical symbolts that clearly distinguish from one another and color is one of the visual variables we can play with when deciding the notation of our modeling language. We’ve integrated this framework in our Collaboro proposal for the collaborative definition of DSLs.
Just in case somebody is interested in my opinion on the second question: I do think it is useful. Not sure what is the best strategy but I’d propose a simple schema: use the same color for all classes modeling strongly semantically-related domain concepts. When I’ve manually colored my own class diagrams, I’ve used colors to clearly distinguish classes coming from different packages in a global diagram. To me, it is important to quickly identify, for instance, the classes related to the billing subsystem from those used by the product management subsystem. When using colors I feel it is also easier to see the connections between the different subsystems (which is usually the most significant information to look for in a diagram). I could even envision a coloring schema in which these classes connecting two subsystems show an intermediate color.
So, what’s your opinion on this?
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
I liked it too. But I have some considerations.
Recently I have searched for tools that show the less color as it could because I think to much color (like degrades) turns diagrams less readable and understandable. Maybe something to do with Tufte’s principles FOR DATA visualization. (it may be MORE suitable FOR printed DATA, but I think it IS important TO consider too…=} ).
However, the idea OF making correspondences BETWEEN colors AND packages seems TO be good WHEN you have a diagram WITH so many classes (AS you pointed IN the text). FOR instance, the usual representation, packageName::ClassName, IS NOT much clear IN a big AND complex diagram, IN which the colors would fit well.
In the END, I liked it, AND I’d adopted it. (but would like to see more opinions on this).
Regards,
Anderson Ledo.
I tend to like the original UML in colors approach as you quickly get used to the way the classes *should* be linked in regards of their colors, just after browsing a few diagrams you spot in a glimpse design or architectural mistakes in the way the classes are related.
Cédric Brun
I was a huge fan of Object Master, back in the 90’s (http://www.artima.com/forums/flat.jsp?forum=106&thread=158259)
One of the nicer features was being able to assign colours based on class or file – I had colouring of my OOFILE frameworks that broke them down by database, GUI presentation, report-writer and infrastructure. That colouring was all through the browsers, class diagrams and also provided an attribute limiting searches.
I found that breakdown by domain useful. Coad’s stuff when I read about it in the “Lego book” but I’m like you in that I never quite got the groupings.
We are often asked to add colour to ConML (www.conml.org), usually by people from non-IT backgrounds. People with a software background seem to have the assumption that diagrams (not models, by the way) must be in black and white, but people in other fields are apparently free from this prejudice.
In fact, we have been thinking about adding colour to ConML, but we haven’t made a decision on how to do it yet. Having a colour per stereotype, so to speak, as the Coad et al. book proposes, doesn’t seem too useful for conceptual modelling purposes from the users’ viewpoint; an often described more useful usage of colour would be to have one colour per model subdomain, so users are free to choose a colour for each information area or field that they introduce in their model. More research is needed. 😉
My two cents on colored software models, based on my experience in teaching, consulting, and language design.
While I find colors a potentially strong mean for conveying messages (just think about advertising, road signals and so on), I don’t believe in colors in modeling languages as something that can be enforced.
Shapes and (to a smaller extent) line types and thickness are much easier to enforce and to be assigned a fixed and shared semantics. As such, they represent the ways of election in visual modeling.
Colors can be useful in modeling, but only as an annotation or reinforcement mean.
There is no way to oblige people to use colors according to a fixed scheme (except, maybe, for some very basic coloring schemes like: green = ok, red = failure). Even in WebML, a rather complex language, the only color code we have is RED and GREEN for arrows, meaning failure and success.
In all other cases, colors will be used by people depending on their need, understanding and context.
That’s why I think is a good idea to allow usage of colors, but it’s a really bad idea to define fixed color schemes with fixed semantics.
Furthermore, there is a very practical reason that limits the adoption of colors: BW is still much more readable, and much cheaper to print.
I use the tool Enterprise Architect of Sparx. In this tool one can map colours to stereotypes. My colleges (customer, developer, tester, etc.) find colours extremely useful by big and very big models. These people use UML models as technical engineering drawing first of all. The colours increase the visual perception very strong.
In a research project (http://www.modeltransformation.net/) they used “Coloured Petri Nets” for model transformations. As its name indicates, colors are used for differentiating the tokens.
Now, I often used colors within the Enterprise Architect mainly for grouping different model elements. In my opinion, it is easier to talk about it with our customers.
“What is the best coloring strategy/schema to maximize this benefit?”
Colors and rest of the notation should come directly from the domain – if possible. Using the example from Fowlers DSL book, see https://twitter.com/metaedit/status/856781875892940800. Other languages and domains then use different colors and shapes, like https://twitter.com/metaedit/status/838705385175400448, https://twitter.com/metaedit/status/793735650415640576, https://twitter.com/metaedit/status/1046708306142744579 and so on.
Class diagram in UML is quite different as there are only rectangles and to identify the type of classes we are interested in we need to read first all <> ;-( so coloring surely helps. ArchiMate follows the color strategy that Jordi proposes: it suggests predefined color schema based on layers (but then allows still users to set their own if needed). One topic for research would be to explore practitioners opinions, e.g. like was done nicely on class diagram annotations in https://dl.acm.org/doi/abs/10.1007/978-3-540-69100-6_29
It should be noted that, according to standard accessibility criteria, color should not be used as the exclusive means to convey information. That is, it is ok (it’s great, indeed) to add color to highlight some elements, or to ease the perception of some traits common to a given group. But that should not be the only way to perceive it, as it is not accessible to people who are color blind. Note that about 1 in 12 males of European (‘Caucasian’) descent have red-green color blindness.
Following your initial example, it would be ok to note that classes come from different packages, as long as this color code comes along another notation which does not depend on color (e.g. the standard “PackageName::ClassName” UML notation, but there may be dozens of other options that may be appropriate to different modeling languages / DSLs)
Absolutely. Color is one more dimension to be used. Not the only one. Indeed, when evaluating notations in Collaboro (https://modeling-languages.com/collaborative-definition-of-dsls/), a positive evaluation required notational elements to be different in more than one direction as you suggest.