Read First: Relation, Tuple
Read Next: Cardinality Constraint,
hasRange/isRangeOf, hasDomain/isDomainOf,
hasImage/isImageOf, hasCoimage/isCoimageOF
A mapping takes an object you give it and returns an object back to
you. It is identical to the mathematical concept of function. For
example, a Temperature mapping might take an object and return the
temperature of that object.
Mappings Are a Kind of Relation
Since mappings pair an input with an output, like a binary tuple, they
are modelled here as a specialization of relation. Following the
definition of relation:
1) The participating types of a mapping are called the domain and
range.
Mappings are restricted to having exactly two participants, or
places. One of the places is for the domain element and the
other is for the range element.
To accommodate multiple-values and no-values returned by a
mapping, the range element of a tuple is always a set.
2) The participant cardinalities are exactly one, because mappings
take one thing and return one thing.
3) The tuple cardinality for the domain place is at most one,
because mappings are required to return an unambiguous result
when given a particular input. The tuple cardinality of the
range place is unrestricted, which means that any number of
domain elements can map to the same range element.
4) The role types for mappings are called the image and co-images,
for the range and domain places respectively.
The current model was chosen for simplicity. As an alternative, we can
split tuples into those for mappings and those for relations, which is
more complicated, but more explicit.
Design Templates For Relations
Another aspect that mappings add to relations is that they perform a
computation. Relations only connect things without specifying the
computation that will happen using those connections. For example, six
different mappings are possible in the Marriage relation:
1) Given the husband, return the wife.
2) Given the wife, return the husband.
3) Given the marriage itself (the certificate, as it were, which is
modelled by a tuple), return the husband.
4) Given the marriage, return the wife.
5) Given the husband, return the marriage.
6) Given the wife, return the marriage.
The mappings listed above fall into two categories:
1-2) The first two are called relation mappings
3-6) The last four are called place mappings, described under place
relation.
At design time, one or more of the mappings above must be chosen to
implement a relation. These are called design templates in OOIE. For
example, an application at city hall may implement only mappings 5 and 6
for the marriage relation, because the most frequent query they get is
to find the marriage certificate for a particular man or woman.
However, relation mappings are required at analysis time because they
appear on the object diagrams (see hasRelationMap/forRelation), even
though they can be discarded at design time.
Specialized Mappings
Like all object types, mappings can be specialized by reducing the
number of tuples they have as instances (see
specializes/generalizes). There are two ways to do this, which are
analogous to the two ways of specializing relations:
1) Specialize the domain and range (see hasDomain/isDomainOf and
hasRange/isRangeOf). For example, the temperature of people is
restricted to being in a smaller range than objects in general,
at least for living people.
2) Specialize the mapping itself using any of the three techniques
described at specializes/generalizes. For example, the way to
take the temperature of humans is different than for animals in
general (I hope).
You can combine the above techniques. For example, you can restrict the
range of human temperature and assign different ways to determine it at
the same time.
Naming Specialized Mappings
As with relations, specialized mappings usually have the same name as
their generalizations. In the temperature example above, we still call
the mappings Temperature when it involves a lion, even though it has
different features and range than human temperature. So when you see
the same mapping on an object type and its specialization, check for new
features and restricted ranges on the inherited mappings.
Attributes
Attributes are not included in the meta-model, because they are a visual
interface issue at analysis-time and identical to mappings at
design-time. For example, suppose we want to model the temperature of a
person. To avoid making an implementation decision during analysis, we
use a relation between Person and Number, rather than a mapping between
them. However, we may want to display the temperature visually as
contained inside the Person node in the diagram, to unclutter the
diagram. We can choose this display design without changing our model.
At design time, we may decide to implement the Temperature relation as a
single mapping from Person to Number. This is appropriate if we do not
expect to get many queries about who has a particular temperature. This
is normally what people intend when they use an attribute during
analysis, but in OOIE we defer those optimization decisions to
design-time.
Multiple-Value and No-Value Mappings
Mappings, like functions can only return one thing. To accommodate
multiple-values, mappings always return sets. A mapping may also return
nothing, that is, the empty set.
Why Places Are Used to Model Relations Instead of Mappings
Places are used to model relations for:
1) Better separation between analysis and design
Mappings force us into design decisions too early. For
example, if we could model Marriage with two mappings, from a
man to a woman, and vice-versa. This would preclude a design
that only kept marriage certificates recording the man and
woman, with no "pointers" kept on the records of man and woman.
See discussion of design templates above.
The OOIE Object Diagram notation happens to put the mapping
names on the relation line, but this is for verbal convenience,
so we can say "a man is married to a woman" and "a woman is
married to a man". It is not supposed to imply a design.
Perhaps it is better to label the lines with one name,
Marriage, so that the mappings aren't implied.
2) Complete cardinality information
Mappings leave out potentially important cardinality
information. For example
purchases
Person >0------------------------------------0< Product
purchased_by
The purchasing relation between a person and product as
modelled here as mapping cardinalities of zero to many in both
directions. This has the following interpretations at design
time:
1) People can make as many purchases as they like, but
they must be made one at a time or at least recorded
that way.
2) People can make as many purchases as they like, and buy
as many products as they like at each purchase.
3) People can only make one purchase, but can buy as many
as they like with that one purchase, as with a coupon.
See the figures at Place Relation.
Another example, suppose we say that a man is married to at
most one woman, who is married to at most one man. This allows
a design that issues blank marriage certificates. Nothing in
the certificates violates the cardinality, because the modeller
didn't specify that marriages must have one man and one woman
(the "participant" cardinality). See figures at Place Relation.
Complete cardinality modelling is also necessary when relations
have their own properties. In this case, the relation must be
an object, with place relations to the participating objects.
Place relations require the complete cardinality information
provided by places. See discussion at Place Relation.
3) More compact modelling
Mappings redundantly model the types which are participating in
the relation. For example, the mappings between man and woman
use the type Man twice: once as the domain, and once as the
range. Places use it only once. Places simplify models that
refer to relations, like the composition model.
The number of possible mappings in a relation increases
combinatorially with the arity of the relation. Even if we
restrict ourselves to the mappings between elements (not
including place mappings) we have:
n! / ( i! * (n-i)! )
where n is the number of inputs to the relation mappings, i is
the arity, and ! means factorial.
The number of places, on the other hand, is always exactly the
same as the arity, so increases only linearly.
Miscellaneous
See the summary with example at Place Relation.
Read First: Relation, Tuple
Read Next: Cardinality Constraint,
hasRange/isRangeOf, hasDomain/isDomainOf,
hasImage/isImageOf, hasCoimage/isCoimageOF
Subtypes: None
The Map operation takes an element from the domain of the mapping and returns an element from the range, if any, dictated by the tuples of the mapping.