Can you see what’s wrong with this picture? The intent of the modeler was to express the fact that a bicycle has two wheels, one of which is the ‘front’ wheel (from the perspective of the rear) and one of which is the ‘rear’ wheel (from the perspective of the front). If you think about what an instance of this model might look like if it were mapped directly to classes and fields in a programming language like Java (using EMF, for example), you’ll realize that each instance of the 'BicycleWheel' class would need a reference to the bicycle’s other wheel, but also to itself – in order to satisfy the multiplicities (both association ends are required, i.e. they have a lower bound of 1), each wheel must reference both the front wheel and the rear wheel of the bicycle; obviously not a desirable result. In fact, it’s currently impossible to create a valid instance of this model using Java code generated by EMF, since an attempt to set a reference from the front wheel to itself (to satisfy the multiplicity) would result in its reference to the rear wheel being discarded.
What’s interesting (at least to a modeling geek like me) is that this redundancy could, in theory, be eliminated simply by making the association ends (the 'frontWheel' and 'rearWheel' properties) navigable owned ends. What does that mean? Well, in UML 2.x, it’s possible to designate a navigable association end as being owned either by the end type (as in the diagram above) or by the association itself. In the latter case, a mapping to Java would require a class to represent the association; now, in addition to there being an instance of the 'Bicycle' class and two instances of the 'BicycleWheel' class, there would be (at a minimum) an instance of the class representing the association which, in turn, would only need to reference each of the wheels once to satisfy the multiplicities. Ed and I have been giving some thought as to how owned association ends might be mapped to Java using EMF, but this special case makes me think that we still don’t have it quite right – see below.
I think there would still be an issue here with respect to navigability, because given a bicycle wheel, it's supposed to be possible to navigate to both the front wheel and the rear wheel (according to the model). Would this require redundant entries in the maps? What if a front wheel is passed as an argument to the 'getFrontWheel(BicycleWheel)' method? What if the owner of the bicycle rotates its wheels every season? I’m starting to wonder whether it should be considered valid at all to model a bidirectional association with required member ends and one end type. In the absence of an answer to that question and/or EMF support for mapping navigable owned ends to Java, there are a number of ways the model could be changed and still (or better) express the original intent. The model we ended up going with (or, rather, a reasonable facsimile thereof) is below. What might you have done differently?
Posts
