A Visualization of OCL using Collaborations ?

Paolo Bottoni1 , Manuel Ko h2 ,

Fran es o Parisi-Presi e1, Gabriele Taentzer3
Universita di Roma \La Sapienza Italy - 2 PSI Berlin 3 Te hni al University of Berlin

Abstra t. We propose a visualization of OCL within the ontext of the

UML meta model, so that OCL expressions are represented by extending
ollaboration diagrams. We exploit the OCL meta model introdu ed in
[9 and further elaborated on in [1 and base the des ription of properties
of obje ts on ollaborations, while lassier and asso iation roles are
used to des ribe navigation paths. Operations omputing properties are
des ribed by intera tions onsisting of messages between lassier roles.
The introdu tion of new graphi al ore elements is kept to a minimum.
New notation mainly on erns the predened operations in OCL and
provides more onvenient visual forms for the notation by intera tions
here. The proposed visualization is des ribed in detail and is illustrated
with examples taken from an industrial proje t under development.

Introdu tion

Although UML is gaining a eptan e as a standard for designing and do umenting software and systems, there are still wide dieren es as to the use of
its omponents. In parti ular, OCL is still of limited use even in organizations
whi h extensively employ some form of UML diagrams. The reasons for this
are various, but they an often be tra ed ba k to the di ulty of integrating a
purely textual language like OCL into diagrams. Re ommendations have been
issued towards the formulation of a diagrammati version of OCL [3 and some
proposals have been advan ed in order to provide a visual ounterpart of OCL
by exploiting visualizations with a set-theoreti semanti s [5. The disadvantage
of su h proposals is that the diagrams look quite dierent from others in UML
and thus, for e the user to learn yet another visual language. Moreover, su h
new visualizations are often not well integrated in the meta model of UML.
The work presented in this paper aims at a hieving a visualization of OCL
within the ontext of the UML meta model while departing as little as possible
from the use of graphi al elements already belonging to the UML notation.
Where a new notation is adopted, it is easily re ognizable as derived from the
UML ore notation, or it is simply employed as a short ut to an equivalent more
omplex visualization. Additional meaning is atta hed to some spe i notation
and to a sele ted set of spatial relations and aspe tual features of the notation.
This visualization adapts the notation for UML ore elements. Furthermore,
we follow the re ommendations of the standards, by avoiding the use of olors
?

Partially supported by the EC under Esprit Working Group APPLIGRAPH.

or spe ial typography to express meaning. Throughout the paper, we illustrate

the prin iples behind our hoi es for the proposed visualization and expand on
how these prin iples led to spe i hoi es. A prominent prin iple is to limit the
introdu tion of new graphi al elements. This responds to two main motivations.
On the one hand, it limits the ognitive eort of the user, thus fa ilitating diagram understanding. On the other hand, the use of elements already in the
UML syntax fa ilitates the he king of model diagrams against the onstraints
expressed by our OCL diagrams. Another prin iple aimed at better understanding is to limit the size of the diagram. In parti ular, no two o urren es of a
sub-diagram need be present in the same diagram. Moreover, visual short uts
for predened operations support a ompa t notation of OCL onstraints.
In [2 we proposed to use graph rewriting with rule expressions to provide
a semanti s for OCL, exploiting graph rewriting me hanisms for he king the
onsisten y of model diagrams with respe t to onstraints. The use of a graphbased formalism opened the way to a visualization of OCL onstraints and an
extension of the UML meta model was dened to this ee t by introdu ing two
new lasses. Now, we pro eed towards a full des ription of a visualized OCL,
by dening a meta model for OCL whi h ombines the proposal in [9 with the
UML meta model for ollaborations. Hen e, OCL onstraints an be expressed
in a more visual way, redu ing the need for additional text.
The rest of the paper is stru tured as follows: the following subse tion introdu es the running example taken from an industrial proje t and used to illustrate
the visualization of OCL onstraints throughout the paper. Se tions 2, 3 and 4
present the visualization proposed for OCL, showing sample OCL onstraints in
textual and visual form. In Se tion 5, we adapt the OCL meta model proposed in
[9 and further elaborated in [1 to the visualization proposed. Finally, Se tions
6 and 7 dis uss related work and on lusions.
1.1

The running example

Our example is taken from an 'eGovernment' proje t in Berlin on whi h one of

the authors has worked. The proje t obje tive is to repla e the existing software
system used in the residents' registration o e in Berlin by a new software
system that supports and fa ilitates both the business pro esses within one or
among several authorities and the business pro esses between the authority and
the itizen by exploiting Internet te hnologies. The main responsibilities of the
residents' registration o e are the registration of inhabitants, the maintenan e
and preparation of the inhabitants data for other authorities like poli e or re
department, and the erti ation of passports and ID ards.
The lient requires expli itly the use of obje t-oriented te hnologies. UML is
used, as it is the standard obje t-oriented notation also a epted by the lient.
However, whereas lass diagrams, ollaboration and sequen e diagrams are te hniques widely used in dis ussions about spe i ations between the lient and the
designer, OCL does not attra t interest at all despite its appropriateness. Constraints, if any, are expressed in natural language.

The experien e a quired in this proje t and in other big OO-proje ts in the
author's ompany point to a simple on lusion: OCL is too di ult not only
for the lient but also for the designer and does not fa ilitate the transition
from the intended requirements to a pre ise and legible presentation. Natural
language formulations are preferred, though their ambiguity might often ause
misunderstanding later in the proje t.
In the sequel, we present some of the onstraints o urring in the proje t.
Fig. 1 shows a (very small) part of the business obje t model of the proje t for
whi h onstraints have been dened. We give a brief explanation of the parts
that are not self-explanatory.
<<enumeration>>
StateOfApartment

<<enumeration>>
KindOfCare

sole
main
second
future

father
mother
other

NaturalPersonCare
attrKind: KindOfCare
0..*

<<enumeration>>
StateOfInhabitant

+statutoryAgent
1

Address
0..*
attrStateOfApartment:
StateOfApartment

attrFamilyName: String

attrDateOfMoveIn: Date

attrDateOfDeath: Date

Inhabitant

NaturalPerson

attrState:
StateOfInhabitant

attrSex: String

resident
unknown
known
died

attrDateOfMoveOut: Date
+birth 1

attrBirthDate: Date
attrBirthPlace: String

Fig. 1.

0..4

+citizenship
State

Birth

attrEU: Boolean
attrCitizenship: String

Business Obje t Model.

The Class NaturalPerson des ribes natural persons (as opposed to legal
persons). These are persons urrently registered in Berlin or previously registered (e.g. moved outside Berlin or dead) or non resident members of the
family. The lass Address ontains addresses of natural persons. The possible
attribute values of the attribute attrStateOfAppartment are: sole apartment,
main apartment, se ond apartment, future apartment (to whi h the inhabitant
will move), and the apartment (to whi h the inhabitant has moved). The lass
NaturalPersonCare ontains the ustody, are or ustodianship, as a statutory agent, of a natural person. By default, the mother be omes the statutory agent of a hild. Additionally, the father be omes the statutory agent of
a hild if the father's family name is the hild's family name. The values for
the attribute attrKind are: hild's father, hild's mother, and other. The lass
Inhabitant ontains data of natural persons who are inhabitants. For instan e,
non resident or dead natural persons are not inhabitants. The values of the attribute attrState are: resident natural person, non resident natural person with

unknown address, non resident natural person with known address, and natural
person who died in Berlin.

Constraints on Properties of Obje ts based on

Collaborations

One of the main ingredients of OCL are navigation expressions to obje t properties. The visualization of navigation paths helps the developer to maintain an
overview without for ing a reformulation of an obje t stru ture, given in some
stati stru ture diagram, in a ompletely dierent syntax. Thus, the idea is to
base obje t navigation on ollaboration diagrams.
Conforming to the meta model presented in [9, we onsider that all OCL
expressions produ e a value. The type of this value an either be a data type
or a lassier type of some instan e. Expressions produ ing values are presented
within an en losing frame where the value is in a pre ise position with respe t
to the frame. If the value is of type Boolean, the expli it mention of the value
an be omitted, provided that no other referen e to it is needed. Hen e a framed
diagram without an external return value maps to a Boolean value. If the OCL
expression produ es an instan e, or a olle tion of instan es, the orresponding
obje t or multi-obje t is double-bordered. Su h an element must be rea hable by
navigating the diagram from the instan e dening the ontext of the expression
(usually named by 'self'). The kind of onstraint is indi ated by short uts 'inv',
'pre' or 'post' (for invariants, pre- or post onditions, respe tively) in the upper
left orner of the visualized onstraint.
2.1

Obje t Attributes

The following is a simple OCL onstraint stating that the birth date of a natural
person omes before the date of moving into an apartment; the onstraint is
stated textually in the usual OCL syntax.
ontext NaturalPerson inv:
self.birth.attrBirthDate < self.address.attrDateOfMoveIn
The visualized form of this onstraint, in Figure 2, ontains three lassier
roles, two with attributes. The attribute values, x and y, are ompared in a
simple Boolean onstraint in the bottom ompartment.
2.2

Operations and Methods

In OCL, operations and methods may be used if they are queries, i.e. they are
free from side-ee ts.
Although in the proje t onstraints for operations and methods have not
been expli itly formulated using OCL syntax, su h onstraints are known to the
designers. For instan e, we have onstraints for the range of the possible values of

inv
: Address

/self: NaturalPerson

attrDateOfMoveIn = x

birth

: Birth
attrBirthDate = y

y<x

Fig. 2.

The birth date omes before the date of moving into an apartment.

the attributes. Consider Figure 3 for the visualization of a onstraint saying that
the date of birth has to be earlier than today. Similar onstraints are ne essary
also for the other dates o urring in the business model.
ontext NaturalPersonCare inv:
self.birth.attrDateOfBirth < urrentDate()
This onstraint is visualized by an instan e of the self lassier role. A method
all may be depi ted as an intera tion with this instan e as the target. Its return value an be used to formulate a onstraint. As a short ut, the method
ompartment an ontain the onstraint, as shown in Figure 3.

inv
/self: NaturalPerson
attrDateOfBirth < currentDate()

Fig. 3.

2.3

The date of birth has to be earlier than today.

Navigation through asso iations

This part of an OCL onstraint is the most interesting one to be visualized. Navigation through an obje t stru ture is mu h easier if the path an be visualized
dire tly. Consider again the example in Figure 2. The onstraint visualization
shows three lassier roles, with two asso iation roles in between, where a role
name is atta hed to one. A more omplex navigation is shown in Figure 8.
If the multipli ity of the asso iation end has a maximum of 1, the target is
an obje t, otherwise a multi-obje t. Examples for navigation to multi-obje ts
will be shown in Se tion 3, where the target is a olle tion. When des ribing
the navigation in this visualized form, role names are mandatory only if there is
more than one asso iation between two lasses.

Navigation from asso iation lasses is similar to usual navigation. Sin e the
navigation from an asso iation lass to one of the obje ts in the asso iation
always results in one obje t, we never have multi-obje ts as sour e or target
obje ts of the asso iation. If the asso iations are qualied, also these qualiers
an be used for navigation. The qualier is denoted via the usual UML notation.

Colle tions and Operations on Colle tions

OCL supports three dierent types of olle tions: sets, bags and sequen es. They
are given in the UML OCL pa kage in an abstra t way, i.e. element types are left
open. For their on rete usage, the abstra t element type has to be instantiated.
The visualization may sti k to the usual representation of lassier roles but
may also use spe ial notions to support the three predened olle tion types.
These spe ial notions of sets orresponds dire tly to the layout of multi obje ts in UML, and the orresponden e extends to the semanti al level as well.
We all this visual form set box. The other types of olle tions are represented
by adorning the set box with details re alling the olle tion type. Hen e, a sequen e is represented by onne ting the orners of the shifted re tangles with
dots re alling a series, and a bag is represented by pla ing a semi ir le, re alling
a handle, over the upper re tangle of the olle tion element (see Figure 4). The
on rete element type of a olle tion o urs inside the re tangle in front.

set
Fig. 4.

3.1

sequence

bag

Visualization of olle tion types

Query Operations

Colle tions oer a variety of query operations whi h support the omputation

of proje tions based on boolean expressions. Applying su h a proje tive query
operation to a olle tion results in a new olle tion (or in a s alar).
So far, we des ribed the appli ation of an operation by an intera tion. This
is possible for query operations, too, but these predened operations an be
visualized more adequately based on set boxes.
In the following, we take the sele t operation to des ribe how query operations and their appli ation an be visualized. If the sele ting expression is simple,
i.e. a onstraint on attributes, this onstraint may be in luded into the onstrained lassier role as a short ut. Usually, the sele ting expression is framed

by a set box. Su h a representation is employed on the left of Figure 5 to sele t

all the addresses of a natural person who is a resident or a non-resident with a
known address. The number of addresses has to be greater than 0. The expression #n inside the dotted box produ es a name for the ardinality of the sele ted
olle tion. Moreover, the iterating variable may be depi ted on the right side of
the set box (here 'a'). This visualization of a query is very exible, sin e there
might be a omplex expression visualized within the set box. The visualization
be omes di ult if the set of addresses might be used in other queries as well.
In this ase, there is a preferen e for the visualization on the right of Figure 5.
Here, a spe ial isIn edge is introdu ed whi h expresses the fa t that the addresses
in the sele ting expression belong to the set of addresses of a natural person.
Moreover, the natural person is repeated in the sele ting expression, as depi ted
by an id- onne tion. The orresponding textual OCL onstraint looks like:
ontext NaturalPerson inv:
self.address!sele t(naturalPerson.inhabitant.attrState = #resident or
naturalPerson.inhabitant.attrState = #known)! size > 0

self: NaturalPerson

self: NaturalPerson

a: Address

a
#n

id

: Address
isIn

: Inhabitant
attrState = #resident | #known

self: NaturalPerson

: Address

n>0
: Inhabitant
attrState = #resident | #known

#n

n>0
Fig. 5.

A sele t statement with two variants

The use of the alternative operator (j) in the gures is a short ut for a
disjun tion involving dupli ation of the lassier role to present the possible
alternative values.
An overview of all visualized query operations for olle tions is given in Figure
6. For a better understanding, we show the visualization of the olle t operation
together with the onversion to a ertain olle tion type. A tually, the onversion
to a bag is not ne essary, sin e the resulting olle tion is always a bag. The iterate
operation is slightly more ompli ated, sin e it ontains the spe i ation of an
iterator elem and an a umulator a . These are variable de larations depi ted
on the right side. The a umulator gets an initial value whi h is depi ted by init
in the left upper orner. Please remember these visual notations are meant as
short uts for pure ollaboration diagrams with queries being intera tions.

#n
select

#n
reject

forall

C
collect-asSet

Fig. 6.

3.2

C
collect-asBag

exist

collect-asSequence

init

elem
acc

iterate

Visualization of query operations

Further Operations on Colle tions

OCL predenes many operations on olle tions. In the following, we brie y dis uss the short uts proposed for the main ones. The operation size has already
been used, visualized by a hash mark and a variable name at the right border
of a olle tion frame. (Consider Figure 5.)
The operation in ludes an be visualized by an arrow from the element to
the set whi h has to in lude this element. The arrow is labeled by in ludes.
The visualization of the predi ate isEmpty is done by presenting the tested
olle tion in a dashed style. This visualization should stress the non-existen e of
any instan e. For the same reason, all adja ent links should be drawn dashed as
well. In general, negated parts of a diagram are drawn with dashed lines.
Due to spa e limitations, we do not dis uss short uts for all predened operations of olle tions. They follow the same design prin iples as the ones we
dis ussed.

Visualized Logi al Expressions

Logi al expressions an o ur at two dierent levels: 1) Expressions on simple

data types, denoted textually in the usual OCL syntax; 2) Logi al expressions
on obje t navigation, represented by obje t intera tion or more adequately by
several sorts of frames and dashed diagram parts for negation.
As an example of the rst type, the textual requirement \There are no instan es of lass Address for natural persons without a state of inhabitation",
when formulated in natural language, is ambiguous. The intended meaning is
that the attribute attrState has the value \unknown" or \died", but it ould
also be interpreted to mean that the attribute has no value at all. The OCL
syntax, in this ase, helps disambiguate the request:

 ontext NaturalPerson inv:

self.inhabitant.attrState = #unknown or self.inhabitant.attrState = #died
implies
self.address!isEmpty
The on lusion ontains some redundan y, sin e it repeats the lassier role
\self: NaturalPerson" whi h is needed to formulate the on lusion. The visual
onstraint is depi ted in Figure 7.
inv: UnknownAddress
: Inhabitant
/self: NaturalPerson
attrState = #unknown | #died
implies
id
/self: NaturalPerson

: Address

Fig. 7. There are no instan es of lass Address for natural persons without a state of
inhabitant.

As an example of the se ond type, the visualization for \If the statutory
agent is mother, the birth date of the statutory agent must be earlier than the
birth date of the hild" is shown in Figure 8.
ontext NaturalPerson inv:
(self.naturalPersonCare.attrKind = #mother)
implies self.birth.attrBirthDate <
self.naturalPersonCare.statutoryAgent.birth.attrBirthDate
For the formulation of the onstraint \The itizenships of a person are different", "we need a \for all" query: Its visualization is depi ted in Figure 9.
ontext NaturalPerson inv:
self. itizenship >forall(x; y : statej x.attrCitizenship = y.attrCitizenship
implies x = y)
The use of identi al lassier roles allows a form of fa torization, or of abstra tion, used in several pla es in our visualization. In fa t, in a UML expression, elements an be referen ed several times. This an o ur expli itly as in
let expressions, or impli itly if a navigation expression is textually repli ated

inv

/self: NaturalPerson

/ID: NaturalPersonCare
attrKind = #mother
implies

id

id

/self: NaturalPerson

/ID: NaturalPersonCare
attrKind = #mother
statutoryAgent

: Birth

: NaturalPerson

attrBirthDate = y

: Birth
attrBirthDate = x
x>y

If the statutory agent is mother, the birth date of the statutory agent must
pre ede the birth date of the hild.

Fig. 8.

inv: uniqueCitizenship
/self : NaturalPerson

: State

isIn

isIn

/ x: State

/ y: State

attrCitizenship = a

attrCitizenship = b

a=b

/ x: State

Fig. 9.

implies
=

/ y: State

The itizenships of a person are dierent.

in dierent parts of a textual onstraint. In the latter ase, an element orresponding to the longest ommon prex of a set of navigation expressions an be
identied. In any ase, we present only one model element and produ e another
box onne ted to the original element for ea h referen e to it in the diagram. If

a named element, e.g. an instan e of a lassier, is repli ated, then identity may
alternatively be expressed by the use of the same name.
A similar me hanism an be used to de ompose a diagram into subdiagrams,
via a hierar hi al view of the expression. Boxes in a high level diagram an
represent whole subdiagrams. In this ase, the box an be named and expanded
in dierent subdiagrams. This an be used whenever a omplex expression is used
several times. An example is shown in Fig. 10 whi h ontains the onjun tion of
the onstraints shown in Fig. 7 and 9.

inv
unknownAddress

Fig. 10.

uniqueCitizenship

A omposed onstraint.

Boolean predened operations are represented by asso iations labeled by

the name of the operation. Boolean onne tives are represented by ombining
appearan e of graphi al elements with their en losing and nesting.
In parti ular, negation, disjun tion and onjun tion are treated. We elaborate on the onvention of Peir ean graphs [4 whi h represent onjun tion by
opresen e in the diagram and negation by en losing the negated elements in a
ontour. On the ontrary, we represent negation by modifying the appearan e of
the elements (using dashed lines) and use onnement within ontours to express
both onjun tion and disjun tion. In parti ular, an odd value of the nesting level
indi ates that the expressions within a same frame are taken in onjun tion and
an even value indi ates that the expressions are taken in disjun tion.
More pre isely, we assume that the logi al expressions are organized as AND /
OR trees, with an AND onne tive at the root. Ea h subtree is en losed within a
frame and its depth determines whether it has to be interpreted as a onjun tion
or as a disjun tion. Expressions within a frame at an AND level of nesting are
taken as onjun ts, while expressions within a frame at an OR level of nesting are
taken as disjun ts. In ase the original OCL formula had disjun tions at the top
level, a new  titious top node is rst inserted to onstitute the AND-labeled
root, and then the translation pro ess is started. In this ase, the rst UML
element an be found at the se ond layer of nesting at least. A dashed frame
indi ates that the whole expression within it must be negated, while dashed
individual elements indi ate that they enter the expression in a negated form.
If-then-else expressions an be depi ted by frames with dierent ompartments. The if ompartment is above the then ompartment on the left, and the
else ompartment on the right. A sample onstraint like \there is a date of death
if the person has died" looks as shown in Figure 11.

 ontext Inhabitant inv:

if self.attrState = #died then
else

not(isUndened(self.naturalPerson.attrDateOfDeath))
isUndened(self.naturalPerson.attrDateOfDeath)

inv
if
/self: Inhabitant
attrState = #died
then

else
id

/self: Inhabitant

: NaturalPerson
not(isUndefined(attrDateOfDeath))

Fig. 11.

id
/self: Inhabitant

: NaturalPerson
isUndefined(attrDateOfDeath)

There is a date of death if the person has died.

Adaptation of the OCL Meta model

Basing the visualization of OCL on ollaborations, the OCL meta model introdu ed in [9 and further elaborated in [1 has to be adapted to the meta model for
ollaborations. The idea is to use ollaborations to des ribe properties of obje ts.
In this sense, roughly speaking, the sub-meta model for a property operation is
repla ed by a se tion of the meta model for ollaborations.
The des ription of obje t properties is based on lassier and asso iation roles
whi h are used to des ribe navigation paths. Here, the existen e of navigation
paths is expressed by the usual ollaborations whereas non-existen e an be
expressed by negated lassier and asso iation roles. A spe ial lassier role
is the self lassier role. The dynami aspe ts of ollaboration diagrams are
exploited to represent the alling of methods to determine properties. Method
alls are des ribed by intera tions onsisting of messages between two lassier
roles. These messages are a tions, possibly with parameters.
Attribute expressions an be des ribed by ollaborations too, sin e lassier roles might ontain attributes with instantiation. The proper onstraint is
expressed by a Boolean expression atta hed to the property operation.

ModelElement

OclExpression

source

initExpression
TypeExp

ResultExp

OperationExp

VarableExp

VariableDecl

* BooleanExpression
constraint

PropertyOperation

VariableInitialization
Collaboration
1
/ownedElement

Interaction
1

AssociationRole

1..*

0..1
/ownedElement

communicationConnection

type NegAssociationRole
1
Classifier
base
collected
Type

Action

sender

receiver /ownedElement
ClassifierRole

type

DataType

Message

/ownedElement

AbstractSet

...

NegClassifierRole
SelfClassifierRole

TypedCollection

Fig. 12.

TypedSet

...

Meta model for Visual OCL

As in [1, a spe ial pa kage UML OCL ontains basi data types and olle tions. Abstra t olle tions are thought to be in orporated in this pa kage as
data types. They have to be instantiated by on rete element types, whi h is
done in a spe ial prole whi h introdu es typed olle tions with a link ba k to
lassiers to apture the olle ted type.
Operation expressions are property operations in any ase. If they onsist of
onstraints only, simple Boolean expressions are formed as onstraints. Spe ial
OCL operations are integrated by oering spe ial data types in the UML OCL
pa kage as des ribed above. As already presented in [9, OCL expressions may

be variables, operations or result expressions. Self expressions no longer need to

be distinguished, sin e self lassier roles are now introdu ed. Moreover, we do
not need query expressions anymore, sin e their operations are now handled by
the olle tion types in the UML OCL pa kage, as stated in [1. Finally, type expressions, as introdu ed in [1, spe ify types whi h are needed in some operations
based on the OCLAny type.
We do not have spa e to dis uss additional onstraints on the meta model.

Related Work

Constraint diagrams [7 and their evolution, spider diagrams [5, have been proposed as a way to express a set-theoreti semanti s of OCL onstraints. However, they do not represent a visualization of OCL expressions by supporting a
stru tural orresponden e between visual and textual onstru ts. Moreover, the
approa h is not based on the graphi al elements already present in the UML
ore. The di ulty of immediately relating onstraint diagrams to UML model
diagrams suggested the ombination of annotating su h diagrams with fragments
of textual OCL onstraints dening the ontext of the evaluation, the environment dened by a let expression, or spe i operations [8. Su h an approa h
suers from the typi al di ulties of parsing together diagrams and text, that
we over ome by providing suitable visualizations for all the stru tural elements
where [8 needs textual onstraints, and by onstraining the use of text in well
dened positions in the diagram.
Following the OCL meta model proposed in [9, in [10 an approa h is proposed for the validation of UML models and OCL onstraints based on the
animation of model diagrams. Stati he ks an be performed automati ally,
while the designer an intera tively generate prototypi al instan es of a model
in the form of diagram snapshots, to be ompared against the spe i ation. Although providing an intera tive form of integration between diagrams and OCL
onstraints, the proposal is based on a purely textual syntax, obtained through
a translation of UML to a textual representation and adding "wrapping" onstru ts on top of OCL syntax.
Dis ussing the general requirements for the onstru tion of tools supporting
OCL, Hussmann et al., advo ate the use of normal forms, su h as the redu tion
of forall and exists onstru ts to iterate [6. The existen e of normal forms
would fa ilitate the hoi e of alternative representations for onstraints with the
same models, e.g. size = 0 and isEmpty. In this paper we have maintained
adheren e to the original syntax rather than to the semanti s, as in Figure 6.

Con lusion

The paper has presented an approa h to the visualization of OCL onstraints

based on ollaborations, aiming at the formulation of omplete onstraining expressions on UML models in the same visual language as the model. The proposed visualization is based on a number of prin iples whi h favor a greater

readability and amenability to OCL onstraints. The proposal onforms to the

UML meta model and adapts re ent proposals for a meta model for OCL. The
proposed visualization introdu es a limited amount of new ore notation, but
oers a variety of visual short uts for onvenient visual notation. They exploit
spatial relations between model elements and their appearan e properties in a
onsistent way. In parti ular, spatial relations are used in the form of frames
with nesting to represent the tree stru ture of a Boolean expression.
As to appearan e properties, we use dierent kinds of line thi kness, repli ation for representing olle tions, adornments to qualify olle tions, and onne ting lines or names, to express referen es to elements.
As future work, two mapping algorithms, ommuting between textual and
visual OCL notations, are desirable on e the dis ussions on the OCL meta model
have onverged. In this ase, the textual and the visual notations ould be onsidered as two on rete syntaxes of one and the same abstra t syntax.

Referen es
1. M. Bodenmuller. The OCL Metamodel and the UML-OCL pa kage. Pro . of OCL
Workshop, Satellite Event of UML 2000, York, O tober 2000, 2000.
2. P. Bottoni, M. Ko h, F. Parisi-Presi e, and G. Taentzer. Automati Consisten y
Che king and Visualization of OCL Constraints. In UML 2000, pages 294{308.
Springer LNCS 1939, 2000.
3. S. Cook, A. Kleppe, R. Mit hell, B. Rumpe, J. Warmer, and Wills A. The Amsterdam Manifesto on OCL. Te hni al Report tum-19925. Te hni al report, Te nis he
Universitat Mun hen, 1999.
4. E. Hammer. Peir ean graphs for propositional logi . In G. Allwein and J. Barwise,
editors, Logi al Reasoning with Diagrams, pages 129{147. Oxford University Press,
1996.
5. J. Howse, F. Molina, J. Taylor, S. Kent, and J. Gil. Spider diagrams: A diagrammati reasoning system. Journal of Visual Languages and Computing, pages
299{324, 2001.
6. M. Hussmannn, B. Demuth, and F. Finger. Modular ar hite ture for a toolset
supporting OCL. In A. Evans, S. Kent, and Seli B., editors, UML 2000, pages
278 { 293. Springer LNCS 1939, 2000.
7. S. Kent. Constraint diagrams: Visualising invariants in obje t oriented models. In
Pro eedings of OOPSLA'97. ACM Press, 1997.
8. S. Kent and J. Howse. Mixing visual and textual onstraint languages. In R. Fran e
and B. Rumpe, editors, UML'99, pages 384 { 398. Springer LNCS 1723, 1999.
9. M. Ri hters and M. Gogolla. A metamodel for OCL. In R. Fran e and B. Rumpe,
editors, UML'99, pages 156 { 171. Springer LNCS 1723, 1999.
10. M. Ri hters and M. Gogolla. Validating UML models and OCL onstraints. In
A. Evans, S. Kent, and B. Seli , editors, UML 2000, pages 265 { 277. Springer
LNCS 1939, 2000.