Relationships

Most of the entities that appear in real applications have relationships with other entities, consider the simple case of a person owning a car. Here we say Person has an owning relationship with the Car, and from the perspective of the person there can be any number of cars that are owned, denoted in UML by [0..*] at the car's end. Make sure the association ends are public (some tools allow to specify the visibility of an association end).

In UML relationships are modeled using associations, and associations themselves have different properties, which will be discussed here.

Let's model another entity now, call it Person and give it a few attributes, just make sure you give them one of the platform independent datatypes that can be mapped onto a platform specific datatype (you can find them in the datatype package).

Draw an association between both entities you have just modeled. Set the multiplicity at the end of the car to [0..*] and name the other end 'owner'. Run AndroMDA again on your model, this is what you should see:

It's possible to draw a dependency from one entity to another, this will generate an accessor in the first entity's DAO to the second entity's DAO.

In this example we have added two attributes: name of type datatype::String and birthDate of type datatype::Date; please note that also for this entity an identifier will be added by default. If you explicitly want to add an identifier you should add the <<Identifier>> stereotype to an attribute.

• Auto-generated source that does not need manual editing
• Auto-generated source that should be edited manually
• File that is affected by the modifications applied in this section

• Car.hbm.xml
• Car.java
• CarImpl.java
• CarDao.java
• CarDaoBase.java
• CarDaoImpl.java
• Person.hbm.xml
• Person.java
• PersonImpl.java
• PersonDao.java
• PersonDaoBase.java
• PersonDaoImpl.java

As you can see the relationships have been generated in the code:

• Person.getCars() : Collection
• Car.getOwner() : Person

By default AndroMDA will look at the multiplicity to generate a good name for the relationship, a few examples where the multiplicity is greater than one:

• car: cars
• property: properties
• toy: toys
• animal: animals
• bus: busses

You can override these names by adding your own names to the association ends, in our example you might set the name of the association end at the side of the person to owner, this will emit the following output during generation:

• Person.getCars() : Collection
• Car.getOwner() : Person

Optionally you may indicate the relationship is part of an aggregate or composite association. You should use aggregation when an entity is part of another one but the latter one does not need the former to exist.

• aggregation: lazy-loaded, no cascade
• composition: eager-loaded, cascade update

Don't forget to properly set the multiplicity on the association ends, this will ensure the proper code is generated.

Next

In the next section we'll learn about services, click here to continue.