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

**Map:**- Default Value: None (specialized)
- Inputs: ?Mapping of type Mapping, ?Input of type Any Type
- Outputs: ?Output of type Any Type
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.