The following text is a set of recommendations for the implementation of the UML structures required for mini-project 2 (MP2).
-
In accordance with the requirements described in point 3 of the requirements document, each structure should have a separate business example (do not combine the structures listed in the mini-project requirements).
-
Associations should be implemented using references between objects. Other solutions (e.g. application of identifiers of related objects rather than references to them) most often have limited usefulness and are much slower.
-
Every association should be undirected, i.e. for every reference connecting the objects in the association, it should exist a reverse reference. Keep these references consistent - when creating an association, create both of them. Both must be removed if the association is deleted.
-
For standard associations (not “bag” or “history” relationships), there must be no more than one association between the same objects within one association.
-
When an object is associated with multiple objects under an association (a one-to-many relationship, or many-to-many), you must apply a collection (set) that holds references to related objects.
-
For each association, create methods in both related classes that will allow you to:
6.1. Get related object or objects (getter). In the case of a collection, ensure that it will not be modified outside the class, similar to a class extent or a multi-value attribute implementation.
6.2. Create a new relationship. This method should automatically set the reverse reference.
6.3. Removal of an existing relationship. This method should automatically remove the reverse reference.
6.4. If there is a method to replace an existing binding with another object, make sure both the references from the old binding will be removed before the new relationship is created.
-
“Basic” association
Using the above rules, you should present an implementation of a one-to-many or many-to-many relationship.
-
Association with an attribute.
8.1. Its application makes sense most often in the case of many-to-many relationships.
8.2. Introduce a new association class that contains the association attributes and two required many-to-one relations with related classes.
8.3. Related classes do not have a direct relationship. Both should have associations to the intermediary class.
8.4. When initializing an associative class object, make sure that the required attributes and references to related objects have the correct values. You must set back references from related objects to the associative class object being initialized.
8.5. The ability to change the bindings in an association class object is not required. If methods exist there for the settings of related objects they should remain private.
8.6. Make sure that methods that remove association with an attribute remove all four references between related objects.
-
Qualified association
9.1. Allows quick access to the related object using a qualifier. Most often the qualifier is a required and a unique attribute of the related class.
9.2. Instead of a set of references to related objects, use a map (dictionary) whose key is the qualifier and the value is a reference to the related object.
9.3. If it is possible to change the qualifier attribute in the related object, the binding that uses that qualifier should be automatically updated.
-
Composition
10.1. It is a strong relationship between the class that is the “whole” and the class that represents the “part”.
10.2. The “part” object cannot exist without an association to the “whole” object. During initialization of “part” you have to create an appropriate relation to the object of the “whole”.
10.3. The given “part” object cannot be shared between “whole” objects. In the process of creating a relationship make sure that a given “part” is not associated with any other “whole” object.
10.4. When deleting the “whole”, the related “parts” must be deleted. To do this, remove the “part” objects from the class extent and all its relationship with other classes.