ArticlePDF Available

The meaning of multiplicity of n-ary associations in UML

Authors:

Abstract and Figures

The concept of multiplicity in UML derives from that of cardinality in entity-relationship modeling techniques. The UML documentation defines this concept but at the same time acknowledges some lack of obviousness in the specification of multiplicities for n-ary associations. This paper shows an ambiguity in the definition given by UML documentation and proposes a clarification to this definition, as well as the use of outer and inner multiplicities as a simple extension to the current notation to represent other multiplicity constraints, such as participation constraints, that are equally valuable in understanding n-ary associations.
Content may be subject to copyright.
Softw Syst Model (2002) 1: 86– 97 / Digital Object Identifier (DOI) 10.1007/s10270-002-0009-3
Special Issue UML 2001
The meaning of multiplicity of n-ary associations in UML
Gonzalo G´enova, Juan Llorens, Paloma Mart´ınez
Computer Science Department, Carlos III University of Madrid, Avda. Universidad 30, 28911 Legan´es (Madrid), Spain;
E-mail: {ggenova,llorens,pmf}@inf.uc3m.es, http://www.inf.uc3m.es/
Initial submission: 16 January 2002/Revised submission: 17 October 2002
Published online: 2 December 2002 – Springer-Verlag 2002
Abstract. The concept of multiplicity in UML derives
from that of cardinality in entity-relationship modeling
techniques. The UML documentation defines this concept
but at the same time acknowledges some lack of obvious-
ness in the specification of multiplicities for n-ary associ-
ations. This paper shows an ambiguity in the definition
given by UML documentation and proposes a clarifica-
tion to this definition, as well as the use of outer and inner
multiplicities as a simple extension to the current nota-
tion to represent other multiplicity constraints, such as
participation constraints, that are equally valuable in un-
derstanding n-ary associations.
Keywords: UML – multiplicity – cardinality – ternary
association – n-ary association – ternary relationship –
n-ary relationship – data modeling – entity-relationship
modeling
1 Introduction
The entity-relationship model [4] has been widely used
in structured analysis and conceptual modeling, and it
has evolved into object oriented class diagrams such as
those of the Unified Modeling Language [24]. This ap-
proach is easy to understand, powerful to model real-
world problems and readily translated into a database
schema, although other forms of implementation, such
as object-oriented programming languages, are not so
simple and straight [26]. Both in entity-relationship di-
agrams and in class diagrams the main constructs are
A previous shorter version of this paper was presented under
the title “Semantics of the Minimum Multiplicity in Ternary Asso-
ciations in UML” at The 4th International Conference on the Uni-
fied Modeling Language-U ML’2001 , October 1–5 2001, Toronto,
Ontario, Canada, Springer Verlag, LNCS 2185, pp. 329–341.
the entity and the relationship among entities (class and
association, in UML terminology). In this sense, im-
portant authors strongly reject the entity-relationship
approach, since they consider that the very distinc-
tion between entity and relationship suffers of lack of
precision [6, 7].
For many analysts, one of the most problematic as-
pects of systems modeling is the correct understanding of
ternary associations and, in general, n-ary associations1.
Ternary associations represent often a complex situation
which modelers find specially difficult to understand, re-
garding both structural and behavioral modeling. From
the structural point of view, these difficulties are very
often interlinked with the fourth and fifth normal form
issue [14]. From the behavioral point of view, atomic in-
teractions that involve more than two objects are another
source of conceptual complexity (these interactions are
denoted by some authors as “joint actions” or “atomic
multiway synchronous interactions” [13]).
The cardinality of a relationship (multiplicity of an
association, in UML terminology) is considered by some
experts as the most structural property of a model [18].
However, the multiplicity values typically specified for
n-ary associations provide only partial understanding of
the object structure. Additional conditions may be in-
cluded within written descriptions that accompany the
models, but a better integration, as far as it is pos-
sible, is always desirable. Worst of all, often the very
meaning of the multiplicities is badly understood. As
we will see, the multiplicity of binary associations is
rather simple to specify and understand in UML, but,
unfortunately, this is not the case for n-ary associa-
tions, for which UML has defined incomplete and unclear
multiplicities.
1We use this term, as usual, to refer to associations with three
or more roles.
G. G´enova et al.: The meaning of multiplicity of n-ary associations in UML 87
The purpose of this paper is, on the one hand, to clar-
ify the meaning of n-ary multiplicity values, which is ac-
knowledged by UML to be not very obvious [24, p. 3-79]
, and on the other hand to propose an extension to
the notation of UML n-ary multiplicities, one extension
that provides more complete and precise definitions for
n-ary associations with the smallest notational burden.
We give a survey of different approaches for multiplicity
values in ternay and n-ary associations, showing the para-
doxes and ambiguities of n-ary multiplicities. Although
our main concern is UML, the core of our exposition is
general enough to be useful in other methods based on
the entity-relationship approach. This work forms part
of a more general research that is aimed towards a bet-
ter understanding of the concept of “association” among
classes. We hope that this better understanding will im-
prove the models constructed both by novel and expert
analysts.
The remainder of this paper is organized as follows.
Section 2 recalls some definitions from UML: multipli-
city, association, and multiplicity for binary and n-ary
associations. Section 3 searches the roots of these defi-
nitions in data modeling techniques that derive mainly
from the entity-relationship approach of Chen. Section 4
reveals an ambiguity, or at least uncertainty, in the defin-
ition of UML minimum multiplicity for n-ary associ-
ations; three alternative interpretations are presented,
each one with its own problems and unexpected conse-
quences. Section 5 tries to understand the root of these
problems by paying more attention to the participation
constraint; a notation compatible with the three alter-
native interpretations of Sect. 4 is proposed to recover
a place for this constraint in n-ary associations in UML,
and its semantics is carefully explained. Finally, Sect. 6
contains a brief proposal of the changes that should
be made to the definition of multiplicities in the UML
Standard, and Sect. 7 contains the conclusions of this
paper.
2 Definition of multiplicity in UML
The Unified Modeling Language defines “multiplicity”
as the range of allowable cardinalities that a set may as-
sume [24, p. 3-75], where “cardinality” is the number of
elements in a set [24, Appendix B, p. 4]. A cardinality is
a specific value, whereas multiplicity is the range of pos-
sible cardinalities a set may hold [25, p. 182]. Multiplicity
specifications are given mostly for association ends, but
they are used also for other purposes like repetitions of
messages, etc. An “association” is the semantic relation-
ship between two or more classes that involves connections
(links) among their instances [25, p. 152; 24, p. 2-19]2.
2These are the definitions within UML, although many authors,
probably coming from the field of entity-relationship modeling, will
use the term cardinality to mean multiplicity, and the term rela-
A binary association is drawn in UML as a solid path
connecting two class symbols. The multiplicity of a bi-
nary association, placed on an association end (the target
end), specifies the number of target instances that may be
associated with a single source instance across the given
association, in other words, how many objects of one class
(the target class) may be associated with a given single
object from the other class (the source class) [25, p. 348;
24, p. 2-23].
The classical example in Fig. 1 illustrates binary
multiplicity. Each instance of Person may work for none
or one instance of Company (0..1), while each company
may be linked to one or more persons (1..)3. For those
readers less familiarized with UML notation, the sym-
bol () stands for “many” (unbounded number), and the
ranges (1..1) and (0..) may be abbreviated respectively
as (1) and ().
An n-ary association is an association among three or
more classes, shown as a diamond with a path to each
participant class. Each instance of the association is an
n-tuple of values from the respective classes (a 3-tuple
or triplet, in the case of ternary associations). Multipli-
city for n-ary associations may be specified, but it is less
obvious than binary multiplicity. The multiplicity on an
association end represents the potential number of values
at the end, when the values at the other n 1ends are
fixed [24, p. 3-79]. This definition is compatible with bi-
nary multiplicity [25, p. 350].
The example in Fig. 2, taken from the UML Reference
Manual [25, p. 351] and the UML Standard [24, p. 3-80],
shows the record of a soccer team in each season with
tionship to mean association. In this paper we use one terminology
or the other depending on the context.
3Note that this association is intended to mean only the present
situation: “a person is working for 0..1 companies”, but not “a per-
son has worked or works for 0..1 companies”. In this paper we are
going to avoid all issues of history, since this concern would depart
us from our main ob jective.
Fig. 1. A classical example of binary association
with the expression of multiplicities
Fig. 2. Ternary association with many-many-many multiplicities
88 G. G´enova et al.: The meaning of multiplicity of n-ary associations in UML
a particular goalkeeper. It is assumed that the goalkeeper
might be traded during the season and can appear with
different teams. That is, for a given player and year, there
may be many teams, and so on for the other multiplicities
stated in the diagram.
However, as we shall see, a subtle paradox hides be-
hind the apparent clearness of these multiplicity specifi-
cations.
3 Definition of cardinality in other data-modeling
techniques
The definition of multiplicity of an association in UML
follows that of OMT [27], which is generally acknow-
ledged [2, 21] to derive from the definition of cardinality
of a relationship in the entity-relationship model [4]. In
fact, Chen does not use the term “cardinality” in his pro-
posal: he uses the expressions “1:1 mapping”, “1:n map-
ping” and “m:n mapping”, and he explains the meaning
of each one, but he does not give any formal definition of
the concept of “type of mapping”. Moreover, he draws an
example of an M:N:P ternary relationship SUPPLIER-
PROJECT-PART, but he does not explain at all how
these “cardinalities” are to be understood. Note, too, that
he deals only with “maximum cardinality”, in a close rela-
tion to the concept of “functional dependency”.
Many data modeling techniques have followed, for-
malized and extended the Chen style of cardinality
values [8, 11, 19, 23, 31]. Others, following the French
method Merise [30], invert the placement of cardinality
values [1,3, 5]. It has been well established that the se-
mantics of both conventions are equivalent for binary
relationships, but differ substantially when they are ap-
plied to relationships of higher degree [2, 20, 21, 29]. This
issue will be dealt with more detail in Sect. 4.
In some of these methods we find the explicit and
useful distinction between the concepts of a cardinality
constraint and a participation constraint [11, 19, 29]:
Acardinality constraint specifies the number of rela-
tionship instances in which an entity can participate.
They are in the form of 1:1, 1:N, or M:N, to express
the two constraints in a binary relationship, and 1:1:1,
1:1:N, 1:N:M, or M:N:P, to express the three con-
straints in a ternary relationship. These constraints
correspond to maximum cardinality constraints in
some notations. In the Chen style, the entity with a car-
dinality constraint of 1 is functionally dependent on the
other entity (or entities, in an n-ary relationship). In
the example in Fig. 1, Company is functionally depen-
dent on Person.
Aparticipation constraint specifies whether an entity
instance can exist without participating in a relation-
ship with another entity. This constraint corresponds
to minimum cardinality constraints in some notations.
Total and partial participation are the two types of
participation, also denoted as mandatory and optional
participation. Mandatory participation exists when an
entity instance cannot exist without participating in
a relationship with another entity instance. Optional
participation exists when the entity instance can exist
without participating in a relationship with another
entity instance. In the example in Fig. 1, Company has
mandatory participation, while Person has optional
participation.
Other authors define in a more general way a co-
occurrence constraint, which specifies how many objects
(or n-tuples of objects) may co-occur in a relationship
with another object (or m-tuple of objects) [12]: for ex-
ample, how many pairs product-prize may co-occur with
a particular pair seller-buyer in the 4-ary relationship
sale. This generalized concept of cardinality is studied
more deeply in Sect. 4.
Some methods combine cardinality and participation
constraints and represent them using minimum and max-
imum constraints in the form of (min, max) notation.
This is the case of UML. However, the concept of mini-
mum multiplicity is not equivalent to the concept of par-
ticipation constraint. For example, a minimum multipli-
city of 2 implies mandatory participation, but mandatory
participation implies only a minimum multiplicity of 1.
Moreover, the potential multiplicities in UML extend to
any subset of nonnegative integers [25, p. 346], not only
a single interval as (2..), or a comma-separated list of
integer intervals as (1..3, 7..10, 15, 19..): specifications
of multiplicity like {prime numbers}or {squares of posi-
tive integers}are also valid, although there is no standard
notation for them. Nevertheless, in UML as in other mod-
eling techniques, the most usual multiplicities are (0..1),
(1..1), (0..)and(1..
). We are going to restrict our analy-
sis to these combinations of multiplicity values.
4 Paradoxes and ambiguities of ternary
multiplicities
Let’s recall the definition of UML multiplicity in an n-ary
association: “the multiplicity on an association end repre-
sents the potential number of values at the end, when the
values at the other n 1 ends are fixed” [24, p. 3-79]. Now
consider the ternary association “A works in B using C”,
which is a classical example in the literature [21], defined
among employees, projects and skills: an employee works
in a certain project using a certain skill. Table 1 illus-
trates possible sets of instances for the three classes, while
Table 2 illustrates a possible set of instances (triplets) for
the association.
Figure 3 shows a diagram for this ternary association,
with maximum multiplicity constraints that, according to
the definition given above, are consistent with the values
in Tables 1 and 2:
Maximum multiplicity for class Project in association
“works-in-using” is , since an n-tuple of instances of
G. G´enova et al.: The meaning of multiplicity of n-ary associations in UML 89
Tabl e 1 . Three possible sets of instances for the
three classes Employee, Project, Skill
Employee Project Skill
Albert Kitchen Welding
Benedict Laboratory Painting
Claire Basement Foreman
Tabl e 2 . One possible set of instances for the
ternary association “works-in-using”
—worksin—using—
Employee Project Skill
Albert Kitchen Welding
Albert Laboratory Welding
Benedict Kitchen Foreman
Benedict Basement Foreman
Claire Kitchen Painting
Fig. 3. The ternary association “works-in-using”,
expressing only maximum multiplicities
Employee-Skill may be linked to an unbounded max-
imum of instances of Pro ject: tuple Albert-Welding is
linked to two different instances of Project, Kitchen
and Laboratory, and the same for Benedict-Foreman.
Maximum multiplicity for class Employee, also ,is
consistent as well: although there is no pair Project-
Skill linked to two different instances of Employee, the
diagram states that a tuple such as Claire-Laboratory-
Welding, which would duplicate the pair Laboratory-
Welding, may be added to the existing set of tuples.
Finally, maximum multiplicity for class Skill, in this
case 1, states that for each pair Employee-Project there
may be at most one skill: that is, an employee uses at
most one skill in each project, which is consistent with
the given values, but the constraint also forbids adding
a tuple such as Claire-Kitchen-Welding unless the tuple
Claire-Kitchen-Painting is deleted first. In other words,
Skill is functionally dependent on Employee-Project.
Now, everything seems working well ... but that’s
not that easy. So far, in applying the definition to
this example we have considered only maximum multi-
plicity. Let’s concentrate now on minimum multipli-
city, and we will see that there is some ambiguity in
its definition. We are going to propose and examine
three different interpretations of the association’s mini-
mum multiplicity, studying the problem from the point
of view of the phrase “each pair Employee-Project”,
and inviting the reader to check which one he or she
has accepted until now, probably in an unconscious
manner. We will show that each one of these inter-
pretations has also its own problems and unexpected
consequences.
First interpretation (actual tuples). “Each pair
Employee-Project” may be understood as an “actually
existing pair”, or an actual pair, that is, a pair of in-
stances that are linked by some ternary link within the
ternary association. Pairs Albert-Kitchen and Benedict-
Basement are actual pairs, since there are in fact some
triplets that contain them, while pairs Albert-Basement
and Claire-Laboratory are not.
This interpretation of the rule seems rather intuitive,
but ... note that for an actual pair Employee-Project
there must be always at least one Skill: if it is an actual
pair, there is an actual triplet that contains it, therefore
there is an instance of Skill that is also in the triplet.
There cannot be an actual pair that is not connected to
a third element, because a ternary link is by definition
a triplet of values from the respective classes; a ternary
link has three “legs”, and none of them may be empty:
“limping” links are not allowed.
So, in this interpretation, the minimum multiplicity is
always at least 1 , since the value 0 has no sense. This
“zero-forbidden effect” is not consistent with the frequent
assigning of minimum multiplicity 0 in ternary associa-
tions (and, first of all, with UML documentation, as in
the example in Fig. 2, which would be incorrect in this
interpretation). In fact, the diagram in Fig. 3 should be
complemented and substituted by the one in Fig. 4.
Second interpretation (potential tuples). “For each
pair Employee-Project” may be understood as a “merely
possible pair”, or a pot entia l pa ir , that is, a pair of in-
stances that belongs to the Cartesian product of Em-
ployee and Project. There are three employees and three
projects, so there are nine potential pairs. For some of
these pairs, like Benedict-Basement or Claire-Kitchen,
there is a related skill; for some others, like Albert-
Basement or Claire-Laboratory, there is none. So, mini-
mum multiplicity 0 is consistent with Tables 1 and 2, and
Fig. 4. The ternary association “works-in-using”,
according to the interpretation of actual tuples
90 G. G´enova et al.: The meaning of multiplicity of n-ary associations in UML
Fig. 5. The ternary association “works-in-using”,
according to the interpretation of pote nt ial tuple s
the diagram in Fig. 3 should be transformed into the one
in Fig. 5.
But, what would be the meaning of minimum multi-
plicity 1? Consider multiplicity 1..1 assigned to class Skill,
as it is presently in Fig. 4. It would mean that, for each po-
tential pair Employee-Project, there might be one Skill,
but not zero; that is, any potential pair not linked to a skill
would be forbidden. In other words, any potential pair
must be linked to at least one skill, and therefore any
potential pair Employee-Project must exist at least once
within one triplet in the association: every employee must
be linked to every project at least once. This rule and the
previous diagram in Fig. 4 would not be consistent with
the values in Tables 1 and 2, since we would need the
full Cartesian product Employee-Product to be present in
Table 2 (in fact, we should have exactly nine lines and no
more, due to maximum multiplicity 1 of Skill).
So, in this interpretation, a minimum multiplicity 1
assigned to one class forces all potential pairs of instances
of the remaining classes to actually exist within some
triplet. This would be a “bouncing effect of the one” that
is probably unexpected by most modelers. Nevertheless,
this interpretation seems valid, as it is implicitly in agree-
ment with UML documentation and some works on the
formalization of multiplicities [21].
Third interpretation (limping links). We coul d try
an entirely different kind of interpretation, by means of
allowing the existence of limping links,thatis,ternary
links that link only two instances and leave a blank for the
third one. Thus, we would understand a 0..1 multiplicity
for class Skill as “each actual pair Employee-Project may
be linked to none or one instance of Skill”, that is, each
link would be actually either a pair Employee-Project
(belonging to a hidden binary association) or a triplet
Employee-Project-Skill (belonging to the true ternary as-
sociation). On the contrary, if multiplicity were 1..1, then
limping links would not be allowed on the side of class
Skill: every actual combination of employee and project
should have a skill linked to it. Within this interpreta-
tion, the diagram in Fig. 3 could be replaced by the one in
Fig. 6, in which the limping links have been removed from
the ternary association, and are represented in a super-
imposed explicit binary association (this could be further
done with the other two zero-multiplicities).
Fig. 6. The ternary association “works-in-using”,
according to the interpretation of limping links,
in which the limping links on the side of Skill
are shown as an explicit binary
association “works in”
In this interpretation, the ternary association sym-
bol is used as an abbreviated form to represent a genuine
ternary association together with a hidden binary associa-
tion. These binary associations may or may not be seman-
tically related to the main ternary association, so that
they have been termed by some authors as Semantically
Constraining Binary Relationships and Semantically Un-
related Binary Relationships [16, 28]. An unrelated binary
association Employee-Project could be, in some scenario,
the association “is-paid-by”, meaning the budgetary as-
signment of employees to projects; “unrelated” means
here that the set of pairs is completely independent from
the set of triplets. We could consider as a related binary
association, on the other hand, the association “works-
in” regardless of the skills used. But the semantic relation
between this binary association and the ternary associ-
ation “works-in-using” could have different senses, for
example4:
Related constraining associations. The pairs in “works-
in” represent a precondition for the existence of triplets
in “works-in-using”, something like “to declare that an
employee works in a project using a skill, it has to be
declared first that the same employee works in the same
project regardless of the skill used”.
Co-occurrence constraints. “Works-in” represents the
pairs obtained from the triplets by filtering out the
skill, and it adds to these pairs some multiplicity con-
straint, like “an employee can work, regardless of the
skill used, at most in four projects”; this kind of co-
occurrence constraint is studied more deeply in the
next section.
Incomplete Associations. “Works-in” represents a set of
pairs for which the third element is still unknown, “this
employee works in this project using a certain skill that
has not yet been registered”; it represents some lack
of information that is expected to be known sooner or
later.
The binary association in the first sense imposes cer-
tainly a constraint on the ternary association. They are
4This list does not pretend to be exhaustive.
G. G´enova et al.: The meaning of multiplicity of n-ary associations in UML 91
in fact two different associations, the first one indepen-
dent and constraining the other one, and we think it is
better for clearness to represent them separately. The bi-
nary association in the second sense, on the contrary,
does not correspond to an independent association, but
to a binary co-occurrence constraint on the same ternary
association. If we represent it as a separated association,
we will still need a constraint that relates both associ-
ations, so that little will be gained; therefore, we pre-
fer to hold them together. Some authors propose a no-
tation of “existence dependency” for these two cases of
constraining binary subassociation (the ternary depends
on the binary in the first case, or the binary depends
on the ternary in the second case) [22]. Finally, the bi-
nary association in the third sense is not properly a con-
straining association, although there is a constraint that
applies simultaneously to the binary and the ternary as-
sociations: if a pair is in the explicit binary association,
it is not in the “expurgated” ternary association, and
vice versa.
In general, the procedure of merging a binary as-
sociation with a ternary association by using limping
links is not advisable. Obviously, unrelated binary asso-
ciations (such as “is-paid-by”) should never be merged
with the ternary association. Related constraining associ-
ations (first sense of related binary associations) should
be maintained apart, too. Co-occurrence constraints (sec-
ond sense) are not really different associations from the
ternary association they constrain, so they should not
be represented neither as explicit associations, nor as
hidden ones using limping links. Incomplete associations
(third sense) are a more dubious case: they seem intuitive,
simple to understand and easy to use; probably many
modelers use the ternary symbol as if it were to mean
this.
Using limping links to represent incomplete associa-
tions avoids the strange effects seen above: the “zero-
forbidden effect” for the actual pairs interpretation, and
Tabl e 3 . Three different interpretations of n-ary multiplicities
Name Interpretation Paradox
Actual tuples Allowed number of values at one
end with respect to an actual com-
bination of values at th e ot her n 1
ends
“Zero-forbidden effect”: minimum
multiplicity is always at least 1
Potential tuples Allowed number of values at one
end with respect to a potent ial com-
bination of values at th e ot her n 1
ends
“Bouncing effect of the one”: a min-
imum multiplicity 1 assigned to one
end forces the existence of all po-
tential combinations of values at the
other n 1 ends within at least one
tuple
Limping links Allowed number of values at one
end (including a blank)withrespect
to an actual combination of values
at the other n 1 ends
“Incomplete tuples”: the instances
of the association might connect
less than n values
the “bouncing effect of the one” for the potential pairs
interpretation. It avoids the explicit representation of an
auxiliary binary association, and this is good since it is
not even clear that an incomplete association is concep-
tually a different association from the ternary association
it derives from. On the other hand, UML does not seem
to allow incomplete associations, since it states that each
instance of an n-ary association is an n-tuple of values
from the respective classes (recall Sect. 2 of this paper).
The “limping links” interpretation for incomplete associ-
ations is a variation of the “actual pairs” interpretation,
in which minimum multiplicity 0 means that a lack of
information is allowed. Nevertheless, there are some dif-
ficulties left: How many legs may be lacking in an n-ary
link? One, two, up to n 2? How is the maximum multi-
plicity constraint to be interpreted when a leg is lacking
on an opposite end?5
So, this interpretation may seem simple and useful at
first glance, but there are still some points that are not
at all clear, first of all the very definition of n-ary associa-
tion in UML. In consequence, in the rest of this paper we
adopt the potential pairs interpretation for clearness, al-
though the issues addressed are up to a point independent
of this choice.
We summarize the different interpretations and para-
doxes of n-ary multiplicities in Table 3.
5 A place for the participation constraint
We have seen three different interpretations that could
solve the ambiguity in the definition of minimum multi-
5Note the subtle difference between the following two questions:
how many employees can work in a project regardless of the skill
used; and, how many employees can work in a project when the
skill used is still unknown. The first question refers to a binary co-
occurrence constraint on the ternary association, whilst the second
question refers to the standard multiplicity when the value of one
of the opposite ends is fixed as “unknown” or “empty”.
92 G. G´enova et al.: The meaning of multiplicity of n-ary associations in UML
plicity of n-ary associations in UML. The first one, actual
pai rs , implies that minimum multiplicity must be always
1, which is not consistent with documentation and prac-
tice; the second one, pot en tia l pa irs , seems correct but has
a strange effect when the value is 1; the third one, limp-
ing links, contradicts the definition of n-ary association,
although it seems intuitive when it is intended to mean
incomplete associations. Why is minimum multiplicity in
n-ary associations so elusive?
McAllister offers a good formalization of the concept
of cardinality (or multiplicity, in UML terminology) [21].
Being aand btwo non-null, non-overlapping sets of roles
in an n-ary relationship R, the cardinality C(a, b)=
(min, max) specifies that any given set of entity instances
of amust be associated by Rwith between min and max
unique sets of entity instances for b6. Note that this cor-
responds to the co-occurrence constraint defined above.
In the example of Fig. 3, if a={Employee, Skill}and
b={Project},thenC(a, b)=(0..). McAllister demon-
strates that the total number of cardinality values that
may be defined in a relationship with N roles is given by
3N2N+1 + 1, and applies this calculation for N from 2 to
5, giving the results in Table 4.
As N increases, there is a rapid increase in the num-
ber of cardinality values that should be analyzed if the
nature of the relationship is to be fully understood. This
may be one factor why many data modeling practitioners
encounter difficulties in dealing with n-ary relationships,
especially if only a small number of the applicable cardi-
nalities are considered for each such relationship.
For N = 3, a ternary relationship such as “works-in-
using”, the twelve values to be considered are: the three
Chen/UML style values, the three Merise values, and
six values for the three embedded (that is, implicit) bi-
nary relationships Employee-Project, Employee-Skill and
Project-Skill (remember they are not truly independent
relationships). McAllister further defines a set of rules
for consistency checking, since these values are not com-
pletely independent [21]. To fully understand the struc-
ture of an n-ary relationship, the modeler should specify
all these co- occur rence con stra in ts , but most of times
it is enough with the N Chen values and the N Merise
values (the others being usually many-to-many [16]).
6For simplicity, we restrict ourselves to the simplest form of car-
dinality, a single integer interval, although this does not affect the
reasoning.
Tabl e 4 . Total number of cardinality values that may be defined
in a relationship with N roles
N = number of roles in R number of C(a, b) for R
22
312
450
5 180
When these values are specified as simple (min, max)in-
tervals, consistency between Chen and Merise values is
determined by ensuring that each min or max Chen value
is less than or equal to the min or max Merise values of
the other classes [21]. This rule may be checked against
the example in Fig. 7, which shows both sets of values:
minChen for Skill is 0, which is equal to minMerise for
Employee (0) and less than minMerise for Project (1);
maxChen for Skill is 1, which is less than maxMerise
for Employee ()andmaxMerise for Project (). If, be-
sides Chen and Merise values, the other values are also
important, McAllister’s tabular representation for rela-
tionship cardinality is a good choice; these cardinality
constraints that are difficult to express in traditional
entity-relationship models are also very naturally ex-
pressed using assertions [18] (“assertions” are declarative
specifications of what has to be true in the “stable state”
of the system, that is, outside of atomic operations; they
are also referred to as “invariants”).
We can better understand now the semantic prob-
lems of minimum multiplicity considered above. Mini-
mum multiplicity is associated with the participation con-
straint, but in the case of a ternary association, in the
Chen style, it does not mean the participation of the class,
but the participation of a pair of the other two classes.
A value 0 for Skill does not mean optional participa-
tion for Skill in the association, but optional participation
for instance pairs of Employee-Project in the association
with an instance of Skill. If this goes against intuition, all
the more reason to be clarified. In fact, the participation
of each individual class remains unexpressed in the Chen
style, while the Merise style represents it adequately. On
the other side, the functional dependencies remain unex-
pressed in the Merise style, while they are represented by
maximum multiplicity 1 in the Chen style. This is prob-
ably the reason why OMT and UML have chosen Chen
instead of Merise, although functional dependency is not
inherently more important than participation.
Both Chen and Merise styles are correct and can de-
scribe the same association, but they state different facts
about the nature of the association. The facts represented
by each style are not specified when using the other, nor
can they be derived from the other (except in the case of
Fig. 7. The ternary association “works-in-using”, showing both
Chen and Merise multiplicity values
G. G´enova et al.: The meaning of multiplicity of n-ary associations in UML 93
binary associations, where they simply interchange their
placement). Therefore, if the two styles provide useful
information to understand the association, why not rep-
resent both in the same diagram? Figure 7 repeats the
example of Fig. 5, but adding a set of Merise values close
to the association diamond. These values are consistent
with the values in Tables 1 and 2, and add new and use-
ful semantics to the association: we note especially that
class Project is the only one that has mandatory partic-
ipation (minMerise for Project is 1), that is, a project
cannot exist without being linked to a pair employee-skill,
although there may be many (potential) pairs employee-
skill not linked to any pro ject (minChen for Project is 0);
and we note also that class Skill may participate in multi-
ple association instances (maxMerise for Skill is ), that
is, a certain skill may be linked to many different pairs
employee-project, although for each pair at most one skill
can be used (maxChen for Skill is 1). Representing both
kinds of multiplicity values in the same diagram is not an
entirely new idea: other proposals such as that of CDIF
(CASE Data Interchange Format) have given them the
sensible names of outer cardinality (for Chen) and inner
cardinality (for Merise) [10]. In fact, the idea was pre-
sented during the elaboration of UML version 1, but was
rejected without due consideration7.
This notation may seem similar to that of replacing
the ternary association by a new entity and three bi-
nary associations that simulate the ternary association,
as shown in Fig. 8. This new entity is usually referred to
as intersection entity or associative entity or gerund [29].
We note that the Merise values of multiplicity are pre-
served in this transformation, and placed again close to
the associative entity, but all Chen values have been re-
placed by 1..1, since every instance of Work is linked to
one and only one instance of the other classes (this is the
same as saying that every ternary link has “three legs”).
In other words, the semantics of functional dependen-
cies expressed by the ternary association are lost when
simulating it with a gerund, but the semantics of partici-
7Joaquin Miller, personal communication to the authors (De-
cember 13th, 2001).
Fig. 8. The ternary association “works-in-using” substituted by
the associative entity “Work”. Only Merise multiplicity
values are preserved in the transformation
pation are preserved. There are other differences between
binary and ternary associations and, in general, binary
representations of ternary associations are not functional-
dependency preserving [15, 17, 28].
Now, turning back to Fig. 7, Chen minimum multi-
plicity, shown close to the class, will be usually zero,to
avoid the “bouncing effect of the one”. On the other hand,
Merise maximum multiplicity will be usually many,as
we are going to show. Suppose that the Merise maximum
multiplicity were one instead of many, as in class Child in
the association named “engender” in Fig. 98. That means
that one instance of Child is linked to one and only one
pair of instances of Father and Mother, which in terms
of functional dependencies can be expressed as [Child
(Father, Mother)], and so [Child Father] and [Child
Mother], by applying the rule of decomposition [31]. This
means that a ternary association, with a Merise max-
imum multiplicity one on one side, may be decomposed
always in two binary associations withoutloss of semantics
of co-occurrence (that is, semantics of participation and
functional dependency): in other words, Merise maximum
multiplicity will be usually many,aswewantedtoshow.
The decomposition is shown in Fig. 109.
So, in a ternary association the most significant multi-
plicity values are Chen maximum multiplicity,thatex-
presses functional dependency of one class with respect to
the other two classes, and Merise minimum multiplicity,
that expresses participation of the class in the associa-
tion. We could choose to show only these two values, and
8We use for simplicity in this example names of classes that
should denote more properly three different roles of the same class
Person.
9This decomposition poses another interesting side problem. Is
co-occurrence among instances the only important semantic aspect
of an association? The ternarity in association “engender” expresses
also that a father and a mother engender jointly a child; that a child
has not a father without a mother; etc. From a human point of view,
the procreation relationship is inherently ternary, so that its projec-
tion in two binary relationships will have some drawbacks in concep-
tual modeling, no matter how right it may be from the formal point
of view of co-occurrences. In other words: object-oriented modeling
is not only data modeling. Behavioral modeling is equally important
as structural modeling, therefore the constraints in co-occurrence,
or multiplicities, are not the ultimate criterion to understand an
object-oriented association, although they are important ones.
Fig. 9. The ternary association “engender”, with Chen and
Merise multiplicities
94 G. G´enova et al.: The meaning of multiplicity of n-ary associations in UML
Fig. 10. The ternary association “engender” decomposed in two
binary associations without loss of semantics of co-occurrence
indeed this is the choice of some methods [9, 11]. In our
opinion, however, this notation could be misleading in the
UML style, so we prefer to maintain the complete expres-
sion of both multiplicities in our proposal.
Note the semantics conveyed by multiplicities in the
case of association “engender” in Fig. 9. First of all, par-
ticipation is mandatory for all three classes. This is ob-
vious for Child, but in the case of Mother (and equally
for Father) it means that being a mother is “having en-
gendered already someone”: not merely “being in the pro-
cess of engendering someone” or “being able to engender
someone”. Not every female person can be an instance
of Mother in this model (another model could use the
class name “Mother” to mean potential mothers instead
of actual mothers, but this is not the case). A mother can
have engendered in general more than once (maxMerise
for Mother is ),andwiththesamefathershemayhave
engendered many children (maxChen for Child is ). It is
also stated that with a concrete father she may have en-
gendered no children (minChen for Child is 0), and this is
not in contradiction with the fact that she must have en-
gendered at least one child with some father (minMerise
for Mother is 1). Remember that we are following in this
section the potential pairs interpretation: if John and Su-
san have engendered jointly no children, then they are
simply not linked by this association.
If we ignore Merise multiplicities, or worse, if we as-
sume a default value of 0.., the semantics of the asso-
ciation are quite different (and the equivalence between
Figs. 9 and 10 is lost). Of course participation is no
more mandatory for any of the three classes; but most
strangely, a child could have several fathers: one father
for each mother he has! (and, conversely, “one mother
for each father he has”). This is a case in which showing
more multiplicities has a strong importance for properly
specifying an association. Merise multiplicities can be ex-
pressed in any case in a diagram using the common mech-
anism existent in UML to show constraints, but we think
they are significant enough to deserve a place in the nota-
tion peer to peer with Chen multiplicities10 .
10 A modeler might also extend the language and specify a stereo-
type for associations, that added to the UML specification of the
6 A proposal for the UML standard
In this Section we briefly propose the changes required to
improve the semantics and notation of n-ary multiplici-
ties. Following the CDIF approach [10], we adopt here the
terms outer/inner multiplicity instead of Chen/Merise,
which seem more appropriate for a technical definition. In
our proposal we adopt the “limping links” interpretation
for pragmatic reasons, as far as it is carefully intended
to represent incomplete associations, but not related con-
straining subassociations.
Semantics:
An n-ary association is an association among three or
more classes.
An n-ary link is an n-tuple of values from the re-
spective classes. One or more roles in the link (up
to n 2) may be empty, meaning an incomplete in-
stance of the association. The value “empty” is con-
sidered as a concrete value when applying multiplicity
constraints.
The outer multiplicity on an n-ary association end
specifies the potential number of values at the spec-
ified end with respect to a combination of values
at the other n 1 ends. A minimum outer multi-
plicity 0 means that the specified link end may be
empty.
The inner multiplicity on an n-ary association end
specifies the potential number of combinations of
values at the other n 1 ends with respect to one value
at the specified end. A minimum inner multiplicity 0
means that the elements at the end may not take part
in the association.
For binary associations, the outer multiplicity at one
end must be the same as the inner multiplicity at the
other end, and vice versa. Therefore, inner multiplici-
ties are omitted.
Notation:
An n-ary association is shown as a diamond with
a path to each participant class.
An n-ary link is shown as a diamond with a path to
each participant instance. Up to n 2pathsmaybe
omitted, but the diamond must be shown in any case,
to indicate the n-ary character of the link.
The outer multiplicity on an n-ary association end is
represented near the class on the path from the dia-
mond to the class.
The inner multiplicity on an n-ary association end is
represented near the diamond on the path from the di-
amond to the class.
Association model element a set of tagged values that allowed the
modeler to store a second set of association multiplicities. But as
far as this new stereotype is not standard, its use would not be-
come generalized. Joaquin Miller, post to the pUML mailing list,
http://www.puml.org/ (January 2nd, 2002).
G. G´enova et al.: The meaning of multiplicity of n-ary associations in UML 95
Metamodel:
The meta-class AssociationEnd has two multiplicity
properties, expressed as two different meta-attributes:
outerMultiplicity and innerMultiplicity. If the associa-
tion end belongs to a binary association, the value of
innerMultiplicity is not specified.
7 Conclusions
Inthispaperwehaveconsideredsomesemanticprob-
lems of minimum multiplicity in n-ary associations, as
it is currently expressed in UML; nevertheless, our ideas
are general enough to be applicable to other modeling
techniques more or less based on the entity-relationship
approach. Minimum multiplicity is closely related to the
participation constraint, although in the case of n-ary
associations it does not mean the participation of the
class in the association, but the participation of tuples
of the other n 1 classes. Moreover, we discovered that
this latter participation is defined with uncertainty, al-
lowing three conflictive interpretations: participation of
actual tuples, participation of potential tuples, and par-
ticipation with limping links.
The second interpretation, potential tuples, is implic-
itly in agreement with UML documentation, in spite of
the bouncing effect of minimum multiplicity 1. The Stan-
dard should clarify this question, without resigning itself
to a lack of obviousness in the definition. Besides, if this
second interpretation were chosen, the Standard should
also warn, since this result is not at all intuitive, that
a minimum multiplicity 1 or greater assigned to one class
forces all potential tuples of instances of the remaining
classes to actually exist within some n-tuple; therefore,
minimum multiplicity would be 0 in nearly every n-ary
association.
The third interpretation, limping links, which is
a variation of the first one, seems intuitive and has also
some pragmatic advantages, although it is in contra-
diction with the definition of n-ary association in UML
(maybe more with the letter than with the spirit). We are
inclined to support this interpretation as far as it is care-
fully intended to represent incomplete associations, but
not related co nstraining subassociations. Up to n 2legs
could be allowed to be lacking, and the value “unknown”,
“empty” or “null” should be considered as a concrete
value when applying the restrictions imposed by multipli-
city values. However, this topic deservers further research
which exceeds the scope of this paper.
The eventual clarification of this point leaves another
problem unresolved: the participation of each class re-
mains unexpressed in the Chen style of representing mul-
tiplicities (which is also the UML style), while the Merise
style shows it adequately. Both Chen and Merise styles
are correct, but they describe different characteristics of
the same association, which cannot be derived from each
other in the n-ary case, although they are related by
a simple consistency rule.
Being both styles useful to understand the nature of
associations, we propose a simple extension to the no-
tation of UML n-ary multiplicities that enables the rep-
resentation of both participation and functional depen-
dency (that is, Merise and Chen styles, or inner and outer
multiplicity in the CDIF terminology). Since this nota-
tion is compatible with the three alternative interpreta-
tions of Chen multiplicities, its use does not avoid by itself
the ambiguity of the definition of multiplicity: they are in-
dependent problems. If this notation were accepted, the
Standard should also modify the metamodel accordingly,
since it foresees only one multiplicity specification in the
AssociationEnd meta-class. If this were not the case, it
could be at least recognized that Chen multiplicities are
not the only sensible co-occurrence constraints that may
be defined in an n-ary association.
Understanding n-ary associations is a difficult prob-
lem in itself. If the rules of the language used to represent
them are not clear, this task may become inaccessible.
If the interpretation of n-ary associations is uncertain,
straight communication among modelers becomes impos-
sible. If the semantic implications of a model are ambigu-
ous, implementers will have to take decisions that do not
correspond to them, and possibly wrong decisions. These
reasons are more than enough to expect a more precise
definition of UML on this topics.
Acknowledgements. The authors would like to thank Vicente Pala-
cios and Jos´e Miguel Fuentes for the frequent conversations on the
issues discussed in this paper; Jorge Morato for his stylistic cor-
rections on the first draft; Ana Mar´ıa Iglesias, Elena Castro and
Dolores Cuadra for the useful bibliographic material provided for
this research, and criticism on the first draft; Guy Genilloud for
his many suggestions to improve this paper; Joaquin Miller for the
information about the CDIF proposal; the anonymous reviewers
of the first version of this paper presented at UML ’2001, and of
the second version submitted to this Journal, for their valuable
suggestions.
References
1. Batini, C., Ceri, S., Navathe, S.B.: Conceptual Database De-
sign: an Entity-Relationship Approach. Benjamin-Cummings
1992
2. Castellani, X., Habrias, H., Perrin, Ph.: A Synthesis on the
Definitions and Notations of Cardinalities of Relationships.
Journal of Object Oriented Programming, 13(6): 32–35, 2000
3. Ceri, S., Fraternali, P.: Designing Database Applications with
Objects and Rules: the IDEA Methodology. Addison-Wesley
1997
4. Chen, P.P.: The Entity-Relationship Model. ACM Transac-
tions on Database Systems, 1(1): 9–36, 1976
5. Coad, P., Yourdon, E.: Object-Oriented Analysis, 2nd ed.
Prentice-Hall 1991
6. Codd, E.F.: The Relational Model for Database Managament:
Version 2. Addison-Wesley 1990
7. Date, C.J.: An Introduction to Database Systems, 6th ed.
Addison-Wesley 1995
8. De Miguel, A., Piattini, M., Marcos, E.: Dise˜no de bases de
datos relacionales. Ra-Ma, Madrid 1999
96 G. G´enova et al.: The meaning of multiplicity of n-ary associations in UML
9. Dullea, J., Song, I.-Y.: An Analysis of Structural Validity of
Ternary Relationships in Entity-Relationship Modeling, Pro-
ceedings of the 7th International Conference on Information
and Knowledge Management, pp. 331–339, Washington, D.C.
Nov. 3–7 1998
10. Electronic Industries Association: CASE Data Interchange
Format, CDIF Integrated Meta-model, Data Modeling Sub-
ject Area, EIA/IS-114 December 1996
11. Elmasri, R., Navathe, S.B.: Fundamentals of Database Sys-
tems, 2nd ed. Benjamin-Cummings 1994
12. Embley, D.W.: Object Database Development: Concepts and
Principles. Addison-Wesley 1998
13. Genilloud, G.: Common Domain Objects in the RM-ODP
Viewpoints, Computer Standards and Interfaces, 19(7): 361–
374, 1998
14. Hitchman, S.: Ternary Relationships – To Three or not to
Three, Is there a Question? European Journal of Information
Systems, 8: 224–231, 1999
15. Jones, T.H., Song, I.-Y.: Binary Representations of Ternary
Relationships in ER Conceptual Modeling. 14th International
Conference on Object-oriented and Entity-Relationship Ap-
proach. Gold Coast, Australia, Dec. 12–15 1995,
pp. 216–225
16. Jones, T.H., Song, I.-Y.: Analysis of Binary/Ternary Cardi-
nality Combinations in Entity-Relationship Modeling. Data &
Knowledge Engineering, 19(1): 39–64, 1996
17. Jones, T.H., Song, I.-Y.: Binary Equivalents of Ternary Rela-
tionships in Entity-Relationship Modeling: a Logical Decom-
position Approach. Journal of Database Management, April-
June: 12–19, 2000
18. Kilov, H., Ross, J.: Information Modeling: An Object-
Oriented Approach. Prentice Hall 1994
19. Martin, J., Odell, J.: Object-Oriented Methods: A Founda-
tion. Prentice Hall 1995
20. Mart´ınez, P., Nieto, C., Cuadra, D., De Miguel, A.: Pro-
fundizando en la sem´antica de las cardinalidades en el
modelo E/R extendido. IV Jornadas de Ingenier´ıa del Soft-
ware y Bases de Datos. C´aceres, Spain Nov. 24–26 1999,
pp. 53–54
21. McAllister, A.: Modeling N-ary Data Relationships in CASE
Environments. Proceedings of the 7th International Work-
shop on Computer Aided Software Engineering, Toronto,
Canada 1995, pp. 132–140. A more recent version in: Com-
plete Rules for n-Ary Relationship Cardinality Constraints.
Data & Knowledge Engineering, 27(3): 255–288, 1998
22. McCarthy, B.: Association Inheritance and Composition.
Journal of Object Oriented Programming, 10(4): 69–81, 1997
23. Metodolog´ıa de planificaci´on y desarrollo de sistemas de infor-
maci´on, METRICA versi´on 2. Tomo 3: Gu´ıa de t´ecnicas. In-
stituto Nacional de Administraci´on P´ublica, Espa˜na. Madrid
1993
24. Object Management Group: Unified Modeling Language Spe-
cification, Version 1-4. September 2001
25. Rumbaugh, J., Jacobson, I., Booch, G.: The Unified Modeling
Language Reference Manual. Addison-Wesley 1998
26. Rumbaugh, J.: Relations as Semantic Constructs in an
Object-Oriented Language. Proceedings of the ACM Confer-
ence on Object-Oriented Programming: Systems, Languages
and Applications. Orlando, Florida 1987, pp. 466–481
27. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen,
W.: Object-Oriented Modeling and Design. Prentice-Hall In-
ternational 1991
28. Song, I.-Y., Jones, T.H.: Analysis of binary relationships
within ternary relationships in ER Modeling. Proceedings of
the 12th International Conference on Entity-Relationship Ap-
proach. Dallas, Texas Dec. 15–17 1993, pp. 265–276
29. Song, I.-Y., Evans, M., Park, E.K.: A Comparative Analysis of
Entity-Relationship Diagrams. Journal of Computer and Soft-
ware Engineering, 3(4): 427–459, 1995
30. Tardieu, H., Rochfeld, A., Coletti, R.: La m´ethode MERISE.
Tome 1: Principles et outils. Les Editions d’Organisation,
Paris 1983, 1985
31. Teorey, T.J.: Database Modeling and Design, 3rd ed. Morgan
Kaufmann Publishers 1999
Photographs of the authors and their biographies are given on
the next page.
G. G´enova et al.: The meaning of multiplicity of n-ary associations in UML 97
Gonzalo G´enova received in
1992 his MS degree in Telecom-
munication Engineering from
the Polytechnic University of
Madrid, Spain, and in 1996 an
MS degree in Philosophy from
the University of Navarre, Pam-
plona, Spain, with a work on
semiotics and the logic of discov-
ery in Charles S. Peirce. Since
then he is member of the Group
of Peirce Studies of the Univer-
sity of Navarre. From 1996 to 1999 he worked in the Data
Processing Service at the University of Navarre. He is cur-
rently working in his PhD in Computer Science at the Carlos
III University of Madrid, where he is also a Teaching Assis-
tant of Software Processes and Advanced Software Design.
His main research subject is the interlacement of static and
dynamic aspects of associations in the UML.
Juan Llorens received in 1986
his MS degree in Industrial En-
gineering from the ICAI Poly-
technic School at the UPC Uni-
versity in Madrid, Spain, and in
1996 his PhD in Industrial En-
gineering and Robotics from the
Carlos III University of Madrid.
In 1987 he started his own com-
pany dealing with Artificial In-
telligence applied to Database
Systems (Knowledge Engineer-
ing SL). In 1989 the company was sold to the European
multinational Advanced Software Technology and Dr. Llorens
became the Marketing Director. He joined the Carlos III
University in 1992 and since 1996 he is Associate Profes-
sor of the Computer Science Department. His main sub-
ject is Information Processing for Software Reuse, which
he teaches in the Computer Science and Information Sci-
ence graduate studies at the University. Dr. Llorens is the
leader of the IE (Information Engineering) research group
within the University. In 1998 he was invited to the Aland’s
Institute of Technology – ATL (Mariehamn, Finland), and
since then he splits his educational activities between Madrid
and Mariehamn. His current research involves the inte-
gration of Knowledge technologies and Software Engineer-
ing techniques towards Software and Information Reuse.
Dr Llorens is member of the IEEE Computer Society
and ACM.
Paloma Mart´ınez Fern´andez
received in 1992 her MS de-
gree in Computer Science from
the Polytechnic University of
Madrid, Spain. Since 1992 she
has been working at the Ad-
vanced Databases Group in the
Computer Science Department
at the Carlos III University of
Madrid. In 1998 she received
her PhD in Computer Science
from the Polytechnic University
of Madrid. She is currently teaching Database Design and Ad-
vanced Databases in the Computer Science Department at
the Carlos University III of Madrid. She has been working in
several European and national research projects about Nat-
ural Language Processing, Advanced Database Technologies,
Knowledge-Based Systems and Software Engineering.
... We intended to express that in any given MeetingPlaceConference, there must be exactly one Conference and one MeetingPlace, with one or more conferees present, while the presence of the single controller is optional. However, the interpretation of n-ary associations in general is not clear, with semantics as divergent as actual tuples, potential tuples (with its "bouncing effect of the one") and "limping links" [Gonzalo et al 2002]. Indeed, UML2 states: "the lower multiplicity for an end of an n-ary association of 1 (or more) implies that one link (or more) must exist for every possible combination of values for the other ends" [UML 2.0] p.38. ...
... We suggest not following the "zero-forbidden effect" of actual tuples noted by [Gonzalo et al 2002]: the multiplicity of the controller in Figure 9.4 is 0..1, implying that in the context of the MpConf service represented by the association class, there can be at most one UserAgent playing controller, but that it needn't be there, i.e. it is free to stop playing the controller role. This fact is explicitly expressed in the OCL goal expression 12 , where the goal assertion for controller is only evaluated if it is present. ...
... Although modelling all possible relationships is needed in order to analyse and understand the full behaviour of a service role, it is not in general possible to include them all in a single UML2 collaboration: a collaboration describes interactions between the roles of that collaboration only; other roles and connectors must be defined in additional collaborations and referenced by collaboration uses. This issue was researched by [Fuglesang 2005], who suggested notational additions to UML to express external roles. ...
Article
Full-text available
The challenges faced when designing and deploying convergent telecommunication services are well know to practitioners. While good tools and methods are available for designing, implementing and testing system parts that run on a single computer, there is a lot to be desired when it comes to the cross-cutting aspects of services that require cooperation between several software components distributed over several machines. Our work addresses the latter issues. Firstly it defines services in a more general way than much of the current thinking, exemplified by Service Oriented Architecture; we consider a service to involve a collaboration between objects, rather than an interface to an object. This means that a larger set of problems can be addressed by services, due to a more general definition. Secondly, we present the core concept of semantic connectors as a reusable modelling construct. Semantic connectors, and the pair of semantic interfaces they define, are used as elements in the composition of more complex services, without any limitations regarding the number of objects participating in the service. Semantic connectors can be designed and validated as separate entities. Semantic interfaces are small state machines, and opposite semantic interfaces must adhere to basic safety properties, entailing that all output from one interface must be accepted as input in the opposite interface, and vice-versa, states taken into consideration. The “semantic” aspect of semantic connectors is expressed by what we call service goals, which characterize events or states that are desirable to achieve over the semantic connector. Service goals are used to check whether collaborations between objects can achieve their intentions; if one can prove that service goals never can be achieved, then the collaboration has no useful purpose. We call this a validation of basic liveness properties, which comes as an add-on to the validation of basic safety properties. Furthermore, the behaviour of services composed of semantic interfaces can be characterised by what we call goal sequences. These provide an overview of the service logic, focusing on the achievement of goals of the constituent semantic connectors. Collaboration goal sequences facilitate the validation of composite service structures, and can be used to derive role goal sequences that describe relationships between goals of semantic interfaces. Actor goal sequences describe the ability of objects to play semantic interfaces, taking sequences of goals into consideration. In addition to a compositional approach to service design and validation, our work also shows how semantic interfaces can facilitate service discovery at runtime. By comparing semantic interfaces and actor goal sequences of potentially connected actors, it is possible to determine what services opportunities are available between peers, both in general and at any specific time, i.e. dependent on the current context. Context dependent service discovery is expected to increase in importance as the number and diversity of terminal types, signalling and transport networks, and service providers increase. Our work builds upon the work of other researchers, but represents a new approach. To the best of our knowledge, our suggestions are new and original. Hence there is little to compare with in terms of other initiatives, although there is a large volume of work that constitutes our point of departure. We use the second version of the Unified Modeling Language, UML 2 as a modelling language. We make original and innovative use of some of the new constructs in UML, in particular collaborations and collaboration uses, as well as interaction overviews. This may be of interest to the UML community at large, not only to designers of convergent services. The ability to model cross-cutting concerns using UML is of general importance. Finally, we note that this work is being used as a basis for ongoing research and evaluation work, most notably by the SIMS project funded by the European Commission, and by a number of doctoral students at the Norwegian University of Science and Technology.
... The IPE collaboration code skeleton can be generalized to support n-ary relationships. Since the need for n-ary relationships is controversial (ambiguity in the interpretation of multiplicities [9]) and since n-ary relationships can be approximated through an appropriate number of binary relationships, we restrict the discussion to the implementation of ternary relationships. Figure 6 depicts the indirect triple extent (ITE) collaboration code skeleton. ...
... Because of its controversial interpretation of multiplicities[9], we exclude the ITE skeleton from this survey. ...
Article
Object collaborations are at the core of all object-oriented programming, yet current class-based object-oriented programming languages do not provide an ex-plicit construct to capture the relationships between ob-jects. This paper reports on an empirical study that investigates the occurrence of object collaborations to assess the need of intrinsic support for relationships in a programming language. We introduce a categoriza-tion of possible forms of object collaborations and their corresponding implementation patterns when using a traditional class-based object-oriented language (Java) and analyze 25 Java programs (ranging from 4 to 6275 classes) with the Relationship Detector for Java (RelDJ) to identify occurrences of these patterns. The empir-ical results show that object collaborations are indeed a frequent phenomenon and reveal that collaboration-related code does not remain encapsulated in a single class. These observations strongly support efforts to de-fine language constructs to express object relationships: relationships allow the encapsulation of a frequently oc-curring phenomenon and increase program expressive-ness.
... Recommendations for creating and transforming IS models and increasing the efficiency of their implementation [9][10][11] will be presented in the form of design patterns. ...
Article
Full-text available
The most popular tools for developing object-oriented information systems are CASE-tools. More often, they do not support n-ary association relationships between classes. It is shown how, when describing a domain model, one can go from n-ary associations to binary ones, how to reduce the number of information system objects, and how to take into account the restrictions placed on objects. Situations that allow this kind of transformation are presented in the form of design patterns.
... Thus, the manifestations of ADR in a particular patient will significantly depend not only on a pair of interacting drugs, but also on other parameters of the patient -for example, his age. Note that the problem of information modeling of dependencies with more than binary multiplicity has been known for a long time [1], however, it still remains relevant even at the level of UML notation, not to mention software implementation. ...
Conference Paper
Healthcare processes are nowadays one of the most important areas of information systems development. Such systems should allow to personalize the treatment, i.e. take into account the specific features of a particular patient. Among these features, the leading place is occupied by contraindications to the use of specific drugs or procedures. The article attempts to develop a framework for building such systems using design patterns and automata approach. The framework provides a light methodology for flexible interaction with complex and multiply-connected medical data structures as well as flexible structure of requests (by scenario type). The use of the framework is illustrated with clinical cases from the practice of treating bronchial asthma.
... In particular, the similarity between the elements of language and UML r is supposed to make it easier to become familiar with it. [44][45][46][47][48] One should bear in mind that AODB features a di®erent set of categories under which it has been de¯ned as the OM. Numerous elements existing in both models have been rede¯ned in the AODB Metamodel. ...
Article
Full-text available
The paper provides a concise discussion of the most important theoretical aspects of the Association-Oriented Database (AODB) Metamodel. Even though the model has been practically verified, the author has focused on its formal aspects and modeling language. The AODB Metamodel has been developed for the purposes of building the knowledge representation systems. Basically, such systems are structurally and functionally complex, hence they require advanced solutions to be applied for the purpose of data modeling. The modeling language enables designing database structures in the AODB Metamodel, taking into account various features of this database metamodel. The language in question is fully integrated and compatible with AODB Metamodel. It has been developed for the purposes of this metamodel, it operates with categories specific to it and, as such, it constitutes neither a version nor an extension of any of the existing languages. The second part of the paper provides the definition and discussion concerning the graphical modeling language — Association-Oriented Modeling Language (AML). The last section of the paper introduces the case-study that presents the key features of the metamodel, as well as the use of modeling language. The topics of presented examples comprise a simplified model of degree programs for universities and the model of Ontological Core, the main module of Semantic Knowledge Base (SKB).
... In the OODB model, an n-ary relationship is established in the same manner as in the RDB model [18,21]. It is handled by means of an additional element, i.e. a class performing a linking function [19]. As aforementioned in the section describing binary relationships, the OM ODMG 3.0 Standard does not support n-ary relationships [5,10,11]. ...
Article
This paper provides a comparison between methods used to represent unary, binary and n-ary relations in the relational database (RDB) and object-oriented database (OODB) models and the association-oriented database (AODB) model proposed in terms of their unambiguity. We have elaborated upon the RDB, OODB and AODB models perceived from the perspective of the categories applied to define them. What has been discussed is a number of solutions assuming the form of schemes for the AODB model. We substantiate that those solutions have unequivocally met the conditions of relations of any chosen arity and multiplicity, at the same time keeping the notation concise, unambiguous and considerably expressive.
... Let's give examples of such relations from the real subject domains [8], [9]. There are two classes: the DISEASE and GENOTYPIC_TRAIT. ...
Article
Full-text available
Most of the technology of object-oriented development relies on the use of UML diagrams, in particular, class diagrams. CASE tools, used for automation of object-oriented development, often do not support n-ary associations in the class diagrams, and their implementation in the form of program code in contrast to binary rather time-consuming. The article will show how in some cases it is possible to move from the n-ary association between classes to binary and how can reduce the number of objects. The rules to transform models, that contain n-ary association, will be presented in the form of design patterns. Proposed three new design patterns can be used in the process of developing software systems. These patterns describe transformations of n-ary (often ternary) associations occur between classes in binary and the introduction of additional classes and binary association with the aim of optimizing the model.
Article
Full-text available
Наиболее востребованными инструментами разработки объектно-ориентированных информационных систем являются CASE-средства. Чаще всего они не поддерживают n-арных отношений ассоциации между классами. Показано, как при описании модели предметной области можно перейти от n-арных ассоциаций к бинарным, как можно уменьшить число объектов информационной системы и как учитывать ограничения, накладываемые на объекты. Ситуации, которые позволяют осуществлять такого рода преобразования, представлены в виде шаблонов проектирования.
Conference Paper
In an object-oriented or object-relational database, an n-ary relationship among objects is normally represented in a relation that is separated from other properties of objects at the logical level. In order to use such a database, the user needs to know the structure of the database, especially what kind of relations and classes there are, how they are organized and related in order to manipulate and query object data. To make the logical level closer to the conceptual level so that the database is easier to use, we propose a novel approach that allows the user to represent n-ary relationships among objects in their class definitions so that the user can directly manipulate and query objects based on the class definitions, rather than explicitly join relations at the logical level. Based on the class definitions, the system can automatically generate the modified class/object relation definitions and the corresponding regular relation definition for the n-ary relationship at the physical level to reduce redundancy and convert data manipulation and query statements based at the logical level to ones at the physical level.
Article
Full-text available
Traditional conceptual modeling and UML take different vague, ambiguous, and apparently incompatible approaches to making a distinction between two different entity types – classes and data types. In this paper, an in-depth theoretical study of these ambiguities and discrepancies is given and a new semantic interpretation is proposed for consolidation. The interpretation is founded on the premise that populations of the two kinds of entity types are defined in two substantially different ways: by intensional (for data types) and extensional (for classes) definitions. The notion of a generative relationship set is introduced to explain the role of specific relationship types that are used to define populations of structured data types by cross-combinations of populations of the related entity types. Finally, some important semantic consequences are described through the proposed interpretation: value-based vs. object-based semantics, associations vs. attributes, and identity vs. identification. The given interpretation is based on runtime semantics and allows for fully unambiguous discrimination of the related concepts, yet it fits into intuitive understanding and common practical usage of these concepts.
Conference Paper
Full-text available
____________________________________________________________________________________________________
Article
This article presents a synthesis of definitions concerning the cardinalities of relationships of entity-relationship models: The Tardieu et al. model1 used by the Merise method,2 the Chen model3 used by the 0MT method,4 and the Teorey model5 used by the Fusion method6 and by the Unified Modeling Language (UML).7 It specifies why definitions of the cardinalities of relationships of these models are different. It also uses an example to show that the cardinalities of n-ary (n ≥ 3) relationships defined with the Chen model are ambiguous, and presents solutions to clarify these cardinalities.
Article
Database systems and database design technology have undergone significant evolution in recent years. The relational data model and relational database systems dominate business applications; in turn, they are extended by other technologies like data warehousing, OLAP, and data mining. How do you model and design your database application in consideration of new technology or new business needs In the extensively revised fourth edition, youll get clear explanations, lots of terrific examples and an illustrative case, and the really practical advice you have come to count on--with design rules that are applicable to any SQL-based system. But youll also get plenty to help you grow from a new database designer to an experienced designer developing industrial-sized systems. + a detailed look at the Unified Modeling Language (UML-2) as well as the entity-relationship (ER) approach for data requirements specification and conceptual modeling--with examples throughout the book in both approaches! + the details and examples of how to use data modeling concepts in logical database design, and the transformation of the conceptual model to the relational model and to SQL syntax; + the fundamentals of database normalization through the fifth normal form; + practical coverage of the major issues in business intelligence--data warehousing, OLAP for decision support systems, and data mining; + examples for how to use the most popular CASE tools to handle complex data modeling problems. + Exercises that test understanding of all material, plus solutions for many exercises.
Article
Recent empirical research offers general data modelling guidance, claiming to show that object-oriented modelling is less effective than entity-relationship modelling. The use of ternary relationship notation in these empirical experiments is examined in detail to reveal that assumptions made by researchers result in findings that are divorced from current modelling practice, cannot be generalised, and are misleading. Research assumptions are shown to be encouraged by inappropriate research methods and this supports the argument of some writers for the adoption of different research methods that inform practice.
Article
An important standardisation effort is in progress within the Object Management Group (OMG) regarding domain computing facilities and common domain objects. In this paper, we investigate the very idea of common objects within the Reference Model for Open Distributed Processing (RM-ODP). We show that `common objects' are in fact common object templates, that different kinds of templates are needed for different viewpoint models, and that agreeing on common object templates is particularly useful for information modelling.