Defining multiplicity of attribute with constraint

Question

I have 2 classes in UML and now need to create a constraint for this part - attribute1:String is in class1, and attribute2:int is in class2, connection between classes is generalization - can be changed to association.

I need to write this somehow

if attribute1 contains 'First year', then attribute2 have multiplicity [1..2], else if attribute1 contains 'Second year', then attribute2 have multiplicity [3..4], and so on.

I know all values that attribute1 can take defined as enumeration(12 values, but only 4 if conditions is needed because every 3 have same part of text at begin). I am creating UML in enterprise architect if its important. Here is the picture of classes

or

Answer 1

I think you need to replace the enumeration with explicit subclasses under Class2. Each class can then redefine multiplicity for attribute2. While you could express this in OCL about the enumeration, few people would understand it.

Answer 2

There are several ways to model that

1. Put a constraint on association

This is a simplest and most obvious solution. Put a constraint describing logic in a note symbol in curly brackets {} and link it to the association. The constraint can have any form, e.g. natural language or formal language like OCL Note that in such case your multiplicity on a constraint will range from 1 to the achievable maximum for all possible values of each enumeration value.

The drawback is that the information is purely textual and might be difficult to comprehend.

2. Create subclasses (solution earlier suggested by Jim L. in his answer)

Subclass can redefine an attribute, e.g. changing the multiplicity. On a parent level the class would have a multiplicity with a maximum achievable maximum while each "year specific" subclass will have a multiplicity matching requirements for that year. You also need to anyway model a constraint for each of subclasses defining which enumeration values are available for that particular subclass.

The drawback of this solution is that when you have a possibility to change from one year to another, it'll not be a simple attribute change but rather a whole replacement of one subtyped object into another one with a different subclass as a type.

3. Multiplicity as variables

The idea is that you handle a logic of mapping between the possible values and related multiplicities and on association you represent the multiplicity using attributes of that mapping rather than specific numbers.

This approach builds a bunch of possible detailed solution but I group them together as they all follow the same approach with just slight differences on how to handle the multiplicity values. I'll give just one detailed solution example (more to follow if someone asks)

One of solutions here is to use data type rather than enumeration. The data type will have in its structure a name (which can still be using the enumeration as a base) and two values (lower and upper multiplicity values). Then your attribute1 will be of that data type and your multiplicities will reference the attribute1 and it's specific properties. Your date type might for example contain properties name, minM and maxM and then on attribute you'll have a multiplicity minM..maxM.

Of course you need to add constrains ensuring that {0<=minM<=maxM} on data type and it's good to specify a set of possible values for a data type somewhere in a documentation as e.g. a table.

A drawback of this solution is that the relationship between specific value and its multiplicity restrictions is not directly on a diagram. Yet this is balanced by a much stronger flexibility of a solution.

4. Multiplicity as a formula

If there is a simple logic between e.g. year and number of related elements that can be written as a formula such formula can also be used in a multiplicity. This is especially useful if you split your enumeration into two separate numeric attributes (hey, you've got a class, when choosing you can still use enumeration, just map it inside the class!). I'll make this assumption in my example.

Let's say that instead of attribute1 you have two attributes: yearNo and yearType. Moreover lets say that in first year you can have 1 or 2 objects of class2 in your class 1 object, in second year you have 3 or 4, and so on. In general you have in n-th year 2n-1 to 2n elements so your multiplicity will be 2*yearType-1..2*yearType

A drawback of this approach is that it is possible only if there is a formula behind.

Additional remarks:

• I believe the mentioned in solution 4 split of your attribute1 is a good solution regardless which solution you choose.
• Generalization has no multiplicity. This type of relationship shows that object of a subclass is at the same type an object of a supertype. In my opinion you should not use this type of relationship here. Most probably you were thinking of shared/composite aggregation rather than generalization (but it has a different arrow head - a diamond, not triangle. Of course it can be quite safely replaced with association.
• Don't use association to the Enumeration (in general to a data type). If you put an attribute as a textual attribute in a class, link it with a type through a dependency (a dashed line with an open arrow). For enumeration (data type in general) this is the only relationship. For normal classes as an attribute type you can exchange inline attribute with an (graphically shown) association (with a role name to make it fully replaceable).