UMLCycles

From EdnaWiki
Jump to: navigation, search

Cycles and consistency in a UML class diagram

At one point in its evolution, the detector model described at Development_MXv2#Detector_Model looked like this:

MXv2 DetectorCycle.png

This introduces the possibility of an inconsistency: a DetectorSetting instance is linked to a single detector, but the model does not prevent the same DetectorSetting being associated with a DetectorAxis that belongs to a different detector! In this case, the DetectorAxis instances that a DetectorSetting instance are linked to must belong to the same Detector instance that is linked directly to the DetectorSetting instance. Put another way, any possible object diagram that can be drawn based on this class diagram must preserve the cycle from the class diagram.

TODO: insert an object diagram here.

This kind of inconsistency is not always wrong. Consider this nearly isomorphous model describing the relationship between libraries, borrowers and books:

OpenCycleExample.png

The same inconsistency doesn't matter here: the borrower may be registered with more than one library, and have books on loan from more than one library at any given time. It is even possible for a book to belong to a library that the borrower has not registered with, for example if an inter-library loan system has been used. (In this case the model is incomplete, because it cannot express which library the borrower used to borrow the book, although completing the model to cater for this is trivial.)

TODO: insert an object diagram here.

The problem in the detector model arises because:

1. The association from DetectorSetting to Detector is many-to-one (not many-to-many as in the library model), and

2. The association between DetectorAxis and Detector expresses a containment relationship, which means that the cycle has to be consistent.

In principle, the requirement for consistency could be expressed with a constraint on the diagram (either in natural language or Object Constraint Language), but those constraints are likely to be complex and difficult to implement, especially for larger cycles. I have looked for guidance on how best to model these kinds of situations, but failed to find any. It may be best to avoid cycles in a class model where that cycle would need to be present in the object model too.