= Solution
The <UML class diagram> below uses dashed hollow-triangle arrows for <trait> realization and ordinary arrows for stored references or navigable associations. Visibility is `+` for public and `-` for private.
\Image[/past-exam-of-the-year-1-of-the-computer-science-course-of-the-university-of-oxford/2016/imperative-main-gym-classes.png]
{title=Gym equipment classes and observer associations}
`GymEquipment` implements `Equipment`. `Performance` and `Prediction` implement `Functionality`, each retaining one `GymEquipment` reference and registering itself with that equipment. Each equipment keeps a <list> of zero or more `Functionality` references; one functionality can in principle be registered with multiple equipment objects through the public method, although the supplied constructors register it only with their own equipment. Hence the generic registration association does not imply exclusive ownership or <composition in UML>.
\b[There are two <traits>, one concrete equipment <software class>, and two concrete observer <software classes>.] `GymEquipment` implements `name`, `age`, and `weight` as read-only values and overrides `updateUserMeasures`; the mutable measurement state and observer list are defined privately in `Equipment`. The diagram reflects the source, including `deleteFunctionality` returning a new list rather than mutating the stored list.
Back to article page
