Where used: Classification Model, Mapping Model


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
       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

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 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

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

             Person  >0------------------------------------0<  Product

         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
              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.


See the summary with example at Place Relation. 

Read First: Relation, Tuple
Read Next: Cardinality Constraint, 
           hasRange/isRangeOf, hasDomain/isDomainOf,
           hasImage/isImageOf, hasCoimage/isCoimageOF


Attributes: None