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:

  1. Does coloring really helps when trying to understand a model? If so,
  2. 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?


Want to build better software faster?

Want to build better software faster?

Read about the latest trends on software modeling and low-code development

You have Successfully Subscribed!

Pin It on Pinterest

Share This