I have modeled the relationship between LeaseAgreement and Person as an aggregation. The '1' on the Person side is meant to indicate that each LeaseAgreement has exactly one reference to a Person (in this case, a tenant). On the LeaseAgreement side, I chose the multiplicity 0..* to express that a LeaseAgreement can be associated with zero or more Person instances.

However, in the code generated based on this diagram, the Person class does not have a reference to a LeaseAgreement in the form of an instance variable. In this case, should the multiplicity on the LeaseAgreement side be changed from 0..* to 0 to reflect the absence of a reference?

EDIT: I would like to clarify my question. I want to make it clear that I am asking about how an aggregation from a UML class diagram is implemented in a specific programming language. I have written an example program in C#.

class LeaseAgreement{
    public Person tenant{
        get{
            return tenant;
        }
        set{
            tenant = value;
        }
    }

}

class Person{
    public string name{get{return name;}set{name=value;}}
    public string lastname{get{return lastname;}set{lastname=value;}}
}

I think it's better to ask the reverse question: How is this implementation represented in a UML class diagram? In my opinion, the following diagram applies:

Since the class LeaseAgreement contains the instance variable tenant of type Person, I consider the class LeaseAgreement as a whole, and the class Person as an existentially independent part of LeaseAgreement.

While an instance of LeaseAgreement can access the contained instance of Person, instances of type Person don't know which LeaseAgreement instance they belong to.

I want to emphasize again that my goal is not to discuss whether an aggregation between the classes is meaningful or not. In my opinion, it depends on the requirements of the software.

I have modeled the relationship between LeaseAgreement and Person as an aggregation. The '1' on the Person side is meant to indicate that each LeaseAgreement has exactly one reference to a Person (in this case, a tenant). On the LeaseAgreement side, I chose the multiplicity 0..* to express that a LeaseAgreement can be associated with zero or more Person instances.

However, in the code generated based on this diagram, the Person class does not have a reference to a LeaseAgreement in the form of an instance variable. In this case, should the multiplicity on the LeaseAgreement side be changed from 0..* to 0 to reflect the absence of a reference?

EDIT: I would like to clarify my question. I want to make it clear that I am asking about how an aggregation from a UML class diagram is implemented in a specific programming language. I have written an example program in C#.

class LeaseAgreement{
    public Person tenant{
        get{
            return tenant;
        }
        set{
            tenant = value;
        }
    }

}

class Person{
    public string name{get{return name;}set{name=value;}}
    public string lastname{get{return lastname;}set{lastname=value;}}
}

I think it's better to ask the reverse question: How is this implementation represented in a UML class diagram? In my opinion, the following diagram applies:

Since the class LeaseAgreement contains the instance variable tenant of type Person, I consider the class LeaseAgreement as a whole, and the class Person as an existentially independent part of LeaseAgreement.

While an instance of LeaseAgreement can access the contained instance of Person, instances of type Person don't know which LeaseAgreement instance they belong to.

I want to emphasize again that my goal is not to discuss whether an aggregation between the classes is meaningful or not. In my opinion, it depends on the requirements of the software.

• uml
• aggregation
• class-diagram

• 1 Your multiplicities are on the wrong ends! – Jim L. Commented Apr 1 at 11:06
• Thank you for the feedback. Are you sure? I always thought that the multiplicities are subtracted on the opposite side, similar to how it's done in an Entity-Relationship Diagram. This is also often asked in exams. – Z.J Commented Apr 1 at 11:12
• 2 You multiplicities are on the right side, but the aggregation is a bit weird. Aggregations ususally are meant to indicate a grouping of multiple things (team <>--player) In your case you "team" only has one "player". I don't think you should model this relation as an Aggregation. – Geert Bellekens Commented Apr 1 at 11:43
• 1 @JimL. "each lease agreement could have multiple tenants" : why not but who is responsible in case of a problem and who pay ? Only one tenant is much more simple. "each person could only be a tenant once" : that has no sense, for you for instance if I rent a house I cannot also rent a car ? – bruno Commented Apr 2 at 8:51
• 1 @bruno I’m not here to defend the design. However, many applications have too much context baked into the model. If this were for a rental company, it would be their selfish de se view of the world, where they have such restrictions. – Jim L. Commented Apr 2 at 12:33

3 Answers 3

I have modeled the relationship between LeaseAgreement and Person as an aggregation.

The aggregation is a wrong choice, a LeaseAgreement is not made up of Person

The '1' on the Person side is meant to indicate that each LeaseAgreement has exactly one reference to a Person (in this case, a tenant).

Correct.

Notice tenant is shown both as an attribute and a relation's role, making the diagram unnecessarily complex.

On the LeaseAgreement side, I chose the multiplicity 0..* to express that a LeaseAgreement can be associated with zero or more Person instances.

False : your diagrams says 0 or more LeaseAgreement are referenced by a Person.

If you want what you say you must add an other relation from LeaseAgreement to Person with 0..* at the right (near Person), but this is inconsistent with tenant.

However, in the code generated based on this diagram, the Person class does not have a reference to a LeaseAgreement in the form of an instance variable.

This is normal from your diagram, the generated code for Person must be a collection of LeaseAgreement, not just a reference to a unique instance if this is what you mean.

But may be you mean there is nothing generated for it, for me this can be normal because you missed to name the role.

Finally :

Does a multiplicity of 0..* always require a reference in the form of an instance variable?

• If you mean the role is a reference to a unique instance : the answer is no, as I said above 0..* means 0 or more, so a collection.

• If you mean the referencing class must have an instance variable : the multiplicity is out of the subject, there is no link between the multiplicity and the fact it is a class variable (static) or an instance variable.

• If you mean the referencing class must have a member : for that you may need to name the role to give the name of that member, even each tool is free to decide what to do without that name

Complement after you added an answer :

instances of the Person type should not contain any attributes of the LeaseAgreement type. A Person instance should have no knowledge of the LeaseAgreement instances that reference it. Therefore, I wouldLeaseAgreement set the multiplicity to 0 on the LeaseAgreement side.

It is very strange a tenant does not know the lease agreement, for me he had to accept/sign it, and still be able to access it ;-) Notice that does not means the class Person has an attribute of type LeaseAgreement, see @Christophe answer.

But if you want that, don't use a multiplicity 0, just replace the bidirectional relation by a unidirectional relation (e.g. LeaseAgreement ---> Person), making the relation not navigable on a side.

In short

You need to distinguish your design and its implementation. The fact that classes are associated, is regardless how you deciee to implement the associations.

More details

A perfectly valid implementation is to implement the association as a set of pairs of tenants and lease agreements, without any additional properties in any of the two classes.

The tenant role on the association implies that the lease agreement has a tenant property. There is then no need to show it a second time as an attribute. Properties are often implemented as "fields"/"attributes" in implementation languages (because both can be shown in an equivalent way in a class diagram), and they facilitate an efficient access. But UML doesn't require it.

An association does not always require an efficient access. For this, there is the navigability concept. Navigability may suggest the use of an "attribute" in the implementation languages, because this is a common strategy, but again, this is only one way to implement it. Moreover, navigability does not require to be bi-directional.

If you need navigability in the opposite direction, i.e. finding easily all the lease agreements of a person, considering the multiplicity, you could go for a collection of agreements in the person. But this is not the only way: you also could find back the relevant agreements with a query on the rdbms, efficiently using the tenant field of the agreement. In this case you'd not need a collection attribute. In both case, you'd use the role.

The aggregation is a wrong choice, a LeaseAgreement is not made up of Person

You are right when considering the real world as the standard. In my opinion, it would be better to consider the software requirements as the standard. After all, UML class diagrams are used to model software architectures.

Notice tenant is shown both as an attribute and a relation's role, making the diagram unnecessarily complex.

Thanks for pointing that out. So, either an attribute or a relation's role, but not both?

Sorry, I misspoke earlier. The LeaseAgreement should actually only contain one person, the tenant. For this, the Person class has the attribute tenant. However, instances of the Person type should not contain any attributes of the LeaseAgreement type. A Person instance should have no knowledge of the LeaseAgreement instances that reference it. Therefore, I would set the multiplicity to 0 on the LeaseAgreement side.

Now, someone suggested that I should still represent the multiplicity as 0..* on the LeaseAgreement side. However, in my opinion, this doesn't make sense. 0..* on the LeaseAgreement side would mean that Person instances own a collection of LeaseAgreements. I hope I was able to clear up the confusion.