/
2010associationClassDefinition.txt
57 lines (40 loc) · 3.33 KB
/
2010associationClassDefinition.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
Association Class Definition
Associations
noreferences
@@description
<p>
An association class defines an object-oriented pattern to manage * -- * (many to many) associations when data needs to be stored about each link of that association.
</p>
<p>An association class is a class and can have the items found in an ordinary class (attributes, state machines, etc.).</p>
<p>However it
always has two or more 1..many associations to other classes. Each of these is written as:
<ul>
<li>A multiplicity (usually *, but 1..* and similar cases are allowed)
<li>(optional) A role name, i.e. another name for association class in the context of this association.
<li>The name of the participating class
<li>(optional) Participating class role name.
</ul>
</p>
<p>The first role name is generally omitted. It is only required if both participating class names are the same (i.e. a reflexive association class). There is an example of this below.</p>
<p>The first example below shows classic use of association classes. A Ticket can be sold to Person in order to attend a Seminar. A Seminar can have many Persons, and a Person can attend many Seminars, so one might imagine simply creating a * -- * association between these classes. However, we want to record the ticket number and price for each Person attending each Seminar. We encode these attributes in the Ticket association class.</p>
<p>For most purposes, an association class behaves in the same manner as though it was an ordinary class with two * -- 1 associations to the participating classes (Person and Seminar in this first example). This is shown in the second example below. However, we want to restrict the possibility of having <i>more than one</i> Ticket sold to the same Person for the same Seminar. Association classes add this constraint.</p>
<p>The third example below shows that it is possible to have more than two classes participate in an association class.</p>
<p>The fourth and fifth examples show the use of the role name for the association class itself. The use of such role names is mandatory when the association class on a reflexive many-many association, i.e. the associated classes are the same. In this example there are Members (e.g. people in a club) and some are assigned to be mentors of others. We want to record the date of each assignment, and we do that using an association class. But since both associated classes are the same (Member), we need to use role names on both ends to ensure all links can be navigated unambiguously. At the Assignment end we have menteeAssignments and mentorAssignments (note the plural) and at the Member end we have roles mentor and mentee.</p>
<p>If we do not use the role names in the 5th example, then <a href="E019DuplicateAssociation.html">error 19</a> will occur because it will not be possible to refer unambiguously to either side of the association.</p>
@@syntax
[[associationClassDefinition]] [[associationClassContent]] [[singleAssociationEnd]]
@@example
@@source manualexamples/AssociationClassDefinition1.ump
@@endexample
@@example
@@source manualexamples/AssociationClassDefinition2.ump
@@endexample
@@example
@@source manualexamples/AssociationClassDefinition3.ump
@@endexample
@@example
@@source manualexamples/AssociationClassDefinition4.ump
@@endexample
@@example
@@source manualexamples/AssociationClassDefinition5.ump
@@endexample