umlaggregationclass-diagram

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

enter image description here 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:

enter image description here

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.

Solution

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

    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.