Introduction
The following text is a set of recommendations for the implementation of UML constructs required for mini-project 4 (MP4).
1. In accordance with the requirements described in Section 3 of the requirements document each construct should have a separate business example (do not combine the constructions listed in the mini-project requirements).
2. Attribute constraints.
2.1 Attribute constraints should be taken into account at the time of object initialization and attribute value change (setXXX method).
2.2 An appropriate exception (e.g. java.lang.IllegalArgumentException, or your own exception) should be raised if you attempt to set an incorrect value.
2.3 Present one example of a static constraint and one example of a dynamic constraint.
2.3.1 For a dynamic constraint, consider the previous value of the attribute. ‘Dynamic’ can also involve checking the value of another attribute, such as a class attribute, which indicates an acceptable range of values.
2.3.2 Static constraints do not take into account the current values of a given or other attributes. Among them can be indicated, for example:
2.3.2.1 Limiting the range of the number of
2.3.2.2. Limiting the number of characters of a string
2.3.2.3. String format checked by a regular expression
3. ‘unique’ constraint.
3.1 Refers to the uniqueness of an attribute value (or combination of multiple attributes) within a class extent.
3.2. As with other attribute constraints, it should be considered when initializing an object as well as changing an attribute. Do not assume that a unique attribute is immutable.
3.3 A valid business example should be used. Object id is a poor example because it is not a business attribute, but a technical attribute, most often managed by the database.
3.4. There are two main ways to implement, using class extent, or an additional static collection. In a mini-project implementation, you should choose one of them.
3.5. Implementation using class extent (recommended):
3.5.1 Validation consists in checking whether there is another object in the class extent having the same value of a given attribute. If this is the case, an exception should be raised.
3.6 Implementation using an auxiliary static collection:
3.6.1 Create an auxiliary static collection containing all the values of a given attribute.
3.6.2 This collection should be updated each time the attribute is successfully changed, making sure to delete unused values.
3.6.3 Validation involves checking whether the new attribute value already exists in the mentioned collection. If so, an exception should be raised.
4. ‘subset’ constraint.
4.1 Applies when there are at least two associations between two classes, and one is a subset of the other.
4.2 Both associations must be properly implemented. This includes the creation of a mechanism to automatically update the back references, as in the case of a ‘regular’ association. Reference names should refer to the role the association plays.
4.3 When creating an association that is a subset, make sure that such an association already exists in an association that is a superset. Otherwise, raise an exception.
4.4. When deleting an association that is a superset, make sure that such an association does not exist in the association that is a subset. If this is not the case, automatically remove the link from the subset, or raise an exception.
4. ‘ordered’ constraint.
4.1 Applies to the order of objects stored in the extent of a class, or for an association.
4.2. A method that returns a collection should return a collection type that maintains the order (List)
4.3. Can be implemented in two main ways: dynamically sorting the collection on retrieval, or sorting the objects when changing the contents of the collection. For a mini-project, an implementation of one of these ways is sufficient.
4.3.1. For dynamic sorting, you need to update the getXXX method, in which the returned list will be previously sorted using the correct comparator. In this case, the type of collection used as an object field does not matter, it can also be Set, which does not maintain the order.
4.3.2 For the method involving sorting during change, use the appropriate collection type for the object field (List). When adding an element to a collection, use sorting with an appropriate comparator.
5. ‘bag’ / ‘history’ restriction.
5.1 By default, object links within an association are unique - within one association, a pair of related objects cannot occur more than once. Marking an association as ‘bag’ or ‘history’ removes this restriction.
5.2 This constraint has practical application for many-to-many associations with an attribute.
5.3. As part of the implementation, the check for uniqueness of the association in the constructor of the intermediate class should be removed.
6. ‘XOR’ constraint.
6.1 Applies to situations where a class is linked by at least two associations. Only one type of association among the associations marked ‘XOR’ can exist for a given object at any given time.
6.2 You need to implement both associations correctly. This includes the creation of a mechanism for automatic updating of return references, as in the case of a ‘regular’ association. Reference names should refer to the role the association plays.
6.3 When creating an association, make sure that there are no links in any other association that are mutually exclusive. If this is the case, raise an exception.
7. Own business constraint.
7.1. Can apply to an association, or to an attribute.
7.2. In the case of an attribute, it can be cross-validation with another attribute, e.g. dateTo must be later than dateOf (apply your own business case to your solution).
7.3. In the case of an association, the validation can be cross-validation with the state of the combined object (e.g., only users with VIP status can be enrolled in the club) or other attributes (e.g., the number of related books can be limited by the capacity of the shelf, which is a shelf attribute)