On using Colors in UML Models

Gefei Zhang

Hochschule f

ur Technik und Wirtschaft Berlin, Berlin, Germany

Keywords:

Modeling, Colors, Visual Aid, UML.

Abstract:

Using colors has been recognized by Software Engineering research as helpful to make graphical software

models more comprehensible. However, guidelines of where and how to use colors have been only little

investigated yet. In this paper, we give two simple examples and propose some guidelines of where and how

to use colors in UML models efﬁciently. Our guidelines may provide valuable help to use colors as a visual aid

of software models and thus reduce the cognitive load of software developers in Model Driven Engineering.

1 INTRODUCTION

Color is an important visual element. It is said to

“have the strongest effect on our emotions” (artyfac-

tory, 2016). Colors are used in a large amount of

graphical documents to show relationships between

ordinal attributes, distinguish different categorical at-

tributes, or to highlight certain parts of the document.

In Software Engineering, techniques of graphical

modeling have been widely adopted. UML (OMG,

2015) and BPMN (OMG, 2011) are two promi-

nent examples of successful graphical modeling lan-

guages. In graphical software models, however, col-

ors still play an insigniﬁcant role; many models are

monochrome, although using colors has been recog-

nized as helpful to enhance the comprehension of

software models, see (Reijers et al., 2011; Yusuf et al.,

2007).

One of the reasons is that so far there has been

only under proportional research on concrete guide-

lines of where and how to use colors in software mod-

els. In this paper, we show some examples of where

colors may be used in software models, and, based on

the examples, we discuss some dos and dont’s of us-

ing colors. Our examples and discussion are based on

the UML, while the principles are applicable to any

graphical software modeling language.

The remainder of the paper is organised as fol-

lows: in the following Sect. 2 we show where to use

colors by some examples of coloring model elements

of UML diagrams, including both structural and be-

havioral models. Based on the examples, we discuss

in Sect. 3 some dos and don’ts of using colors. In

Sect. 4 we discuss related work, before we conclude

and outline some future work in Sect. 5.

2 WHERE TO USE COLORS

We show where colors may be applied in UML mod-

els by two examples. The ﬁrst example is a class di-

agram modeling the structure of the well known Ab-

stract Factory pattern (Gamma et al., 1994). In the

second example we consider a state machine model-

ing a simple computer game.

2.1 Using Colors to Group Model

Elements

In software models different colors may be used to

put model elements into different groups. If model el-

ements of the same group are colored with the same

color, and model elements of different groups are col-

ored with colors that are easily distinguishable from

each other, then colors provide a visual aid for the

reader of the model to grasp the groups and under-

stand the model better.

For example, the class diagram shown in Fig. 1(a),

which was taken from (doFactory, 2016), models

the structure of the Abstract Factory design pat-

tern, where ConcreteFactory1 is responsible to cre-

ate instances of ProductA1 and ProductB1, while

ConcreteFactory2 is responsible to create instances

of ProductA2 and ProductB2. Since Fig. 1(a) is

monochrome, the reader has to follow the ar-

rows with dashed lines carefully, which repre-

sent UML dependencies relationships, to realize that

Zhang G.

On using Colors in UML Models.

DOI: 10.5220/0006262605090514

In Proceedings of the 5th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2017), pages 509-514

ISBN: 978-989-758-210-3

509

(a) Black and white (b) Colored

Figure 1: Abstract Factory Pattern.

ConcreteFactory1, ProductA1 and ProductB1 belong to a

product family, and that ConcreteFactory2, ProductA2 and

ProductB2 belong to another product family. If there

were more product families, this relationship would

be even less obvious.

In Fig. 1(b), we use colors to emphasize the re-

lationship of “belonging to the same product family”:

ConcreteFactory1, ProductA1 and ProductB1 are colored red,

and ConcreteFactory2, ProductA2 and ProductB2 are colored

blue. The classes of the same color are easily per-

ceived as having “something in common”, while the

classes of different colors clearly belong to different

groups. The product family relations are therefore

made more apparent.

2.2 Using Colors to Show Special

Behaviors

In behavior models, relationships between model el-

ements are usually even more complex. The model

reader often needs to understand the interactions of a

whole number of model elements in order to under-

stand the relations between the model elements. Us-

ing colors to highlight these relationships may pro-

vide a visual aid to understand the model more easily.

For example, Fig. 2(a), which was taken

from (Zhang, 2012), shows a UML state machine

modeling the behavior of a player during a certain

part of a computer game. Very simply speaking, the

player—a magician—starts in a state where they has

to chose a NewLevel. Upon completion of the prepara-

tions they is transferred into the Play state which con-

tains two concurrent regions, modeling two different

aspects of the magician’s intelligence. The upper re-

gion describes the possible movements of the player:

in each level they initially starts in an entrance hall

(Hall), from there they can move to a room in which

magic crystals are stored (CrystalRoom) and on to a

room containing a Ladder. From this room the player

can either move back to the hall or, after ﬁghting with

some computer ﬁgure and winning, exit the level.

The lower region speciﬁes the magician’s possible

behaviors. They may be Idle, gathering power for the

next ﬁght, Spelling a hex, or Fighting. They may escape

from the ﬁght and try to spell another hex, or, if they

wins the ﬁght in the Ladder room, win the level and

move on to another level. Any time while Playing, they

can leave the game and quit. Note that the event quit

has a stereotype



prioritized



, meaning that it has a high

priority and its transition should be ﬁred at once when

quit is received, even if there may be other events in the

event pool.

Moreover, the magician modeled in Fig. 2(a) is not

allowed to spell a hex in the crystal room. That is, the

states CrystalRoom and Spelling must not be simultane-

ously active. This mutual-exclusion rule is modeled

by the interaction of a bunch of model elements: A

variable c is introduced and used to control the access

to the two critical states: it is initialized as 0 in the

entry action of Play, increased whenever CrystalRoom or

Spelling is activated, and decreased whenever one of

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

510

entry / init

NewLevel

Ladder

defer / toCrystalRoom

Hall

defer / train

Idle

defer / escape

Fighting

Level

Won

toCrystalRoom toLadder

[enoughCrystal]

/ losePower

toHall

CrystalRoom

entry / c++

exit / c−−

do / takeCrystal

fightspell Spelling

escape [c==0]

[c==0]

entry / c++;

exit / c−−;

spellHex

entry / c=0

Play

quit

nextLevel

«prioritized» quit

[c==0]

(a) Black and white

entry / init

NewLevel

Ladder

defer / toCrystalRoom

Hall

defer / train

Idle

defer / escape

Fighting

Level

Won

toCrystalRoom toLadder

[enoughCrystal]

/ losePower

toHall

CrystalRoom

entry / c++

exit / c−−

do / takeCrystal

fightspell Spelling

escape [c==0]

[c==0]

entry / c++;

exit / c−−;

spellHex

entry / c=0

Play

quit

nextLevel

«prioritized» quit

[c==0]

Legend : prioritized: mutual exclusion

(b) Colored

entry / init

NewLevel

Ladder

defer / toCrystalRoom

Hall

defer / train

Idle

defer / escape

Fighting

Level

Won

toCrystalRoom toLadder

[enoughCrystal]

/ losePower

toHall

entry / c++

exit / c−−

do / takeCrystal

fightspell

escape [c==0]

[c==0]

entry / c++;

exit / c−−;

spellHex

entry / c=0

Play

quit

[c==0]

CrystalRoom

Spelling

nextLevel

quit

Figure 2: State machine with mutual exclusion.

the two states is deactivated. The three transitions that

activate the two states (from Hall to CrystalRoom, from

Idle to Spelling, and from Fighting to Spelling) are guarded

by conditions, such that they are only ﬁred when c

equals 0, which means that the other critical state is

currently inactive and the mutual exclusion rule is sat-

isﬁed. A subtle point is that we have to declare the

events toCrystalRoom, spell, and escape to be deferrable in

the states Hall, Idle, and Fighting respectively. In this way

the transitions are postponed if the other critical state

is active, and will be automatically resumed without

requiring the events to be sent again. Otherwise the

events would be lost in case exactly one of the critical

states were active, since the event would then be taken

from the event pool without ﬁring a transition.

Since the mutual exclusion behavior is modeled

by the interaction of a bunch of model elements, in-

cluding increment and decrement of variables, check-

ing guard conditions at several transitions, and de-

ferring events, the behavior is hard to comprehend.

However, we can ﬁll the states CrystalRoom and Spelling

with the same color (in Fig. 2(b): red) to highlight that

these states have “something special”, and, since they

share the same color, this something special is actu-

ally something in common. Moreover, we also give

Actually, this is an intrinsic issue of standard UML

state machines, see (Zhang, 2012).

On using Colors in UML Models

511

the event quit a color (in Fig. 2(b): blue), highlighting

that it has a special semantics (being handled imme-

diately, even if there are also other events in the event

pool).

Additionally, we put a legend in Fig. 2(b) to make

clear that in the ﬁgure, the color red means mutual

exclusion, and that the color blue means high priority.

This way, the fact that the two states are mutually ex-

cluded is efﬁciently alerted to the reader of the model.

3 DOS AND DON’TS

Based on the above examples of where to use col-

ors appropriately in UML class diagrams and state

machine models, we discuss some dos and dont’s of

color usage, and give a brief comparison of using col-

ors and icons that may be deﬁned as part of stereo-

types, one of the standard UML extension mecha-

nisms.

Use Colors only to provide Redundant

Information, don’t rely Solely on Colors

Colors, as compared with shapes or texts, cannot al-

ways be seen properly. For example, modelers and

software developers may be color blind, or a software

artefact may be printed on paper by a monochrome

printer. Therefore, it is very important not to present

information by colors only. Colors should only be

used to highlight some information that are already

modeled otherwise. The purpose of using colors in

graphical models is rather to enhance the user expe-

rience, letting the user to understand the model more

easily, than to provide information modeled by colors

only.

Keep Colors consistent with the Model, avoid

Inconsistency

Since the information provided by colors should be

redundant, it is important to make sure that this in-

formation is kept consistent to the model when the

model is modiﬁed. For instance, if our computer

game evolves to a new version and the behavior of

the computer player in Fig. 2(b) is changed such that

the event quit is no longer prioritized, then its color

should also be removed. Otherwise the reader would

only feel confused.

This phenomena is well known in programs with com-

ments that no longer match the code.

Use colors only to provide qualitative information,

don’t model precise quantitative information by

colors.

The human cognition of colors is imprecise. Color

nuances are hardly perceived. Therefore, it is better

to use different (distinguishable) colors for model ele-

ments in different categories, rather than using similar

colors for quantitative differences.

Use Colors only to provide Simple, Highlighting

Information, don’t Model Complex Logic with

Colors

Colors are a very good means for highlighting and

alerting. Usually, colors are good to represent simple

notiﬁcations rather than complex logic. For instance,

in Fig. 2(b), we used colors only to show that the two

states have something in common, and it is the leg-

end that explains what the common thing is. More

detailed logic, such as how the state machine waits

to enter the critical states, should not be modeled by

colors.

Consider using a Legend, don’t let the Reader

Guess

If some special semantics (e.g., mutual exclusion

in Fig. 2(b)) is highlighted by a color, then it may

be helpful to provide a legend, which explains very

brieﬂy what the color means in a few words. Other-

wise the reader would only see that the colored model

elements are “somehow” different, but usually do not

understand what the difference is.

Prefer Using Colors to Icons

Icons are also used in the UML to show that some el-

ements are “somehow different”. Usually, these ele-

ments are stereotyped, and deﬁned in a so called UML

proﬁle. Stereotyping is actually one of the standard

extension mechanisms of the UML. A stereotyped

model element usually has a semantics which is re-

lated to, but different than that of the base element,

and may be indicated by either the name of the stereo-

type, enclosed in guillemets



and



, or by an icon,

speciﬁed by the stereotype’s designer. For instance,

in Fig. 2(a), the event quit has a stereotype



prioritized



meaning that it has a high priority and its transition

should be ﬁred at once when the event is received,

even if there may be other events in the event pool.

In Fig. 2(c), we use icon

to indicate that the

states CrystalRoom and Spelling are stereotyped, and the

icon to indicate that the transition from Play to the

ﬁnal state is prioritized. Note that usually the name

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

512

and actual semantics of the stereotype are deﬁned in

another document, a so called UML proﬁle. However,

the icons do alert to the reader of the model that the

two states and the transition are different than normal,

non-stereotyped states and transitions.

While icons can also be used to show that some

model elements are different than standard model ele-

ments, they usually take only a small part of the model

element, and are less prominent than colors. It is eas-

ier to see colors than icons. Also, difference between

colors is easier to perceive than difference between

icons. Therefore, colors are more suited to highlight

differences between model elements. On the other

hand, colors and icons may be used complementar-

ily, and icons may be colored. The above discussion

about dos and dont’s also applies to using colors in

icons.

4 RELATED WORK

It has been recognized that colors may be helpful

to enhance the understanding of software models,

see (Yusuf et al., 2007), focusing on UML class di-

agrams, and (Reijers et al., 2011), focusing on Petri

Nets, although these papers do not contain guideline

for the use of colors. Some guidelines regarding lay-

out of model elements are published in (AgileMod-

eling, 2016), and in (Mendling et al., 2010) the au-

thors make recommendations of the elements to use

in graphical models, e.g., that OR branching should

be used as little as possible. In these guidelines, col-

ors are not considered. To the author’s knowledge,

our paper is novel in that we provide guidelines of

where and how to use colors in UML class diagrams

and state machine models.

In programming, modern IDEs, such as Eclipse

and IntelliJ IDEA

, usually display different elements

of a program, such as keywords, identiﬁers, numbers,

strings, comments, etc., in different colors, and users

can have individual settings of these colors. More-

over, simple static analysis techniques are applied, so

that erroneous code and code with bad smells, e.g.,

unused variables, are also shown in different colors

than “normal” code. This way, the programmer re-

ceives visual aids to structure and understand the pro-

gram better, and to see potential errors in the pro-

gram. To the author’s knowledge, guidelines of how

to use colors in programs have not been investigated

and published yet.

http://www.eclipse.org/

http://www.jetbrains.com/idea/

5 CONCLUSIONS AND FUTURE

WORK

We have given two examples of where to use colors

as a visual aid in UML diagrams. We considered both

structural and behavioral modeling. Based on the ex-

amples, we proposed some guidelines of how to use

colors in UML diagrams.

Future work includes development of modeling

tools to enable convenient modeling with colors, and

empirical studies on the effectiveness of our guide-

lines. We also plan to extend our guidelines to cover

other graphical modeling languages, such as BPMN

and Petri Nets.

ACKNOWLEDGEMENTS

This work has been partially sponsored by the project

“Anwendungszentrum creative Applied Interactive

Technologies” (cAPITs) of the European Regional

Development Fund.

REFERENCES

AgileModeling (2016). Modeling Style Guidelines.

http://agilemodeling.com/style/. Accessed on 2016-

11-16.

artyfactory (2016). The Visual Elements—Color.

http://www.artyfactory.com/art appreciation/visual-

elements/color.html. Accessed on 2016-11-16.

doFactory (2016). http://www.dofactory.com/net/abstract-

factory-design-pattern. Accessed on 2016-11-16.

Gamma, E., Johnson, R. H. R., and Vlissides, J. (1994). De-

sign Patterns: Elements of Reusable Object-Oriented

Software. Addison.

Mendling, J., Reijers, H. A., and van der Aalst, W. (2010).

Seven Process Modeling Guidelines (7PMG). Infor-

mation and Software Technology, 52(2):127–136.

OMG (2011). Business Process Model and Notation, Ver-

sion 2.0. Speciﬁcation, Object Management Group.

http://www.omg.org/spec/BPMN/2.0/PDF/, Accessed

on 2016-11-16.

OMG (2015). Uniﬁed Modeling Language, Version

2.5. Speciﬁcation, Object Management Group.

http://www.omg.org/spec/UML/2.5/PDF/, Accessed

on 2016-11-16.

Reijers, H. A., Freytag, T., Mendling, J., and Eckleder,

A. (2011). Syntax Highlighting in Business Process

Models. Decision Support Systems, 51(3):339–349.

Yusuf, S., Kagdi, H., and Maletic, J. I. (2007). Assess-

ing the Comprehension of UML Class Diagrams via

Eye Tracking. In Proc. 15

IEEE Int. Conf. Program

Comprehension (ICPC’07), pages 113–122. IEEE.

On using Colors in UML Models

513

Zhang, G. (2012). Aspect-Oriented Modeling of Mutual

Exclusion in UML State Machines. In Vallecillo, A.,

Tolvanen, J.-P., Kindler, E., St

orrle, H., and Kolovos,

D. S., editors, Proc. 8

Eur. Conf. Modeling Foun-

dations and Applications (ECMFA’12), volume 7349

of Lect. Notes Comp. Sci., pages 162–177. Springer-

Verlag.

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

514