Site Sponsor
Go WordPress
Coloring models
The idea of applying a specific color schema to (UML) models in order 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 . 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.
Anyway, MORE than 10 years after that initial proposal, it seems that this topic IS gaining momentum again. Cédric Brun has recently blogged about Ecore IN Colors WHERE he implements the same pattern TO allow the coloring OF general Ecore models. Rational has just published a UML Coloring plug-IN . 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).
So, we now have the tools TO color our models 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?
Just in case somebody is interested in my opinion: 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 stronlgy 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 important 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?
If you enjoyed this post you can subscribe to this Software Modeling blog and/or follow me on twitter or through the portal’s mailing list . AND if you really liked it help me pass it ON TO others by bookmarking AND sharing the post USING the links below:
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