Regarding 1 to 1 associations in UML class models

Question

We often encounter class models, in UML modeling, that state a 1 x 1 or 1 x 1..* or 1..* x 1 or 1..* x 1..* association between given classes.

Take the example: Player 1..11 x 1 Team.

Wouldn't that impose a practical problem, in which it wouldn't be possible to determine what comes first: the team or a player? In the example, a team would need a player, at least, to exist, while a player, to exist, needs the team. Am I misinterpreting something?

Trying to implement it, you wouldn't be able to instantiate a Team, because you'd need at least one Player, and if you try to instantiate the Player, the Team would be missing.

How are 1 x 1 associations possible?

Thank you for your time!

Answer 1

You are correct. You must satisfy all the constraints somehow. Either create everything at once or relax your constraints. For example, a team can still exist as a team without any players, but a team must exist for a player to join it.

Answer 2

When a model as a 1..11 relationship (Team - Player) there is no "what comes first". There need to be 11 Players and these can be connected to one Team. Only when the connections are all made you have a complying model. You can point out that players form a team by adding a composition. But usually from a programming aspect this does not add much semantics. You need to have the instances anyway in order to create the connections. So the Team will likely have an array of 11 Players and in order to work, none of them must be Null.

The same goes for 1..1 relations (plug/socket). Only when they are connected you have a complying model. From a modeling perspective a 1..1 is often used if you need a rucksack for one of the two classes. Then you bind another one with separate information. This can then be used together with other classes which are only interested in this contents and not the carrier itself.

Answer 3

Your question "How are 1 x 1 associations possible?" refers to the issue of mandatory mutually inverse references, or, in DBMS jargon, cyclic foreign keys, which may indeed create an object/row creation or update problem in a data management app or its underlying database (DB).

There are two approaches how to deal with it: 1) Relax the mandatory reference constraint in at least one direction, 2) Allow intermediate app/DB states that do not have to satisfy the constraint.

1) While we know that in reality a team always includes more than zero players, we may choose not to implement this constraint for pragmatic reasons, such that we can more easily create a team data object (or DB row) without immediately assigning player objects/rows to it.

2) In our app, we may allow an intermediate state where a team has been created without any players assigned to it, and correspondingly in the underlying DB, we may instruct the transaction manager that the foreign key constraint is only checked when the entire transaction (consisting of first creating an empty team, then creating 11 players, such that each of them is assigned to the team and the team is assigned to them as their team) is completed. This can be achieved with the SQL clause DEFERRABLE INITIALLY DEFERRED, see the section Cyclic Foreign Keys of the post "Deferrable SQL Constraints in Depth".

Answer 4

It depends what kind of model it is. A UML model might be a model of the real world, e.g. a human hand has 1:1 relationship with a human arm. This 1:1-association models a biological fact (ignoring disabilities).

A UML model might also be a model of the functionality of an application. If the application enforces that every team has 11 players and every player has one team (e.g. they are all created at once by filling out a form with a "Save"-button), then the 1:11-association correctly models the functionality of the application.

A UML model might also be a technical model of classes in some programming language or tables in a database. In that case, the 1:1-associations are only possible if your programming language or database system allows creating the instances on both sides simultaneously, or at least in the same transaction.

Side note: When modeling teams and players, you might consider an association between Team and Person, with multiplicity 0..* and role name 'player' on the Team side.