8.1 Unique Instance Constraints

I l@ve RuBoard

8.1 Unique Instance Constraints Objects may have sets of attributes that are required to be unique. a customer's login ID a publisher's ISBN code an order's order number Object orientation endows each object with its own unique identity, the object handle. This handle uniquely identifies an object, but it is implicit and carries no semantic significance. An object's identifier carries semantics�it's a rule about the domain�and is made explicit. These attributes constitute ways to identify an individual instance. We call each required-to-be-unique set of attributes an identifier. Definition: An identifier is a set of one or more attributes that uniquely distinguishes each instance of a class. 8.1.1 Single Attribute Identifiers To capture this notion of uniqueness in the model, we establish uniqueness constraints. Examples of unique-instance constraints are: No two customers can have the same e-mail address. Each publisher has a unique ISBN prefix code. Each new order is assigned a unique number. Uniqueness constraints formalize rules in the domain�both rules about the world (e.g., publishers are assigned unique ISBN prefix codes by the publishing industry) as well as rules that we make up (the customer's e-mail address is his login ID and therefore must be unique). Any kind of attribute can be used to make up an identifier. The notion of a naming attribute is different from that of an identifier, although naming attributes are frequently used in identifiers. For example, nothing prohibits two publishers from having the same company name if they were established in different jurisdictions, but the ISBN code is required, by policy, to be unique. Constraints in OCL. To define a unique-instance constraint formally, we may use the Object Constraint Language (OCL). Figure 8.1 depicts the constraint for the Customer. Figure 8.1. Unique Instance Constraint in OCL The first line defines the context of the constraint, namely the class for which the constraint applies, and the fact that the constraint is a definition of an invariant (inv). The second line iterates over all instances of the class using two free variables, p1 and p2. allInstances is a predefined operator that finds all the instances of the associated class, and the dagger symbol (->) indicates that the following operation acts on a collection, in this case, all the instances of the customer. The third line introduces an implication. For two arbitrary instances of the class, p1 and p2, that are not equal, this fact implies something (on the following line). The last line states the invariant, namely that the identifying attribute of the two instances must not be the same. Unique instance constraint idiom. The example in Figure 8.2 forms an idiom. Figure 8.2. Unique Instance Constraint Idiom This idiom is the unique instance constraint. The unique instance constraint for the Publisher and the Order follow the same idiom. OCL�The Object Constraint Language The Object Constraint Language (OCL) is a fundamental part of the UML, described in Section 6 of the UML 1.4 Specification [1]. It is designated as the official way to express constraints on UML models. The semantics of UML themselves are defined using OCL. The constraints shown in this chapter are written in OCL and in action language. These constraint expressions are written as boolean functions that return true if the constraint is satisfied and false if the constraint is violated. We hope for and encourage a convergence between OCL and action languages, such that a developer can write a constraint using the same language used for actions and that model compilers will be able to check and to enforce these constraints. Definition: A constraint idiom is a general pattern for a commonly occurring type of constraint that can be represented by a predefined tag. Constraints in action language. The constraints in Figure 8.1 can also be written in action language, as shown in Figure 8.3. Figure 8.3. Unique Instance Constraint in Action Language Specifically, this is written as an instance function on the Customer class. Graphical notation. UML allows the definition of tags. A tag is a string that can be added to any model element, enclosed in braces {}. Figure 8.4 shows how we use the tag {I} on each identifying attribute to denote an identifier. Figure 8.4. Identifiers on the Class Diagram The presence of the tags is a shorthand for writing the unique instance constraint, so there is no need to explicitly write the OCL or action language. Contrived identifiers unnecessary. Shlaer-Mellor ([2] and [3]), a precursor to Executable UML, required that every class contain at least one identifier, even if that identifier was an attribute placed in the object solely for the purpose of being its identifier. This practice is not required in Executable UML. 8.1.2 Multiple Attribute Identifiers An identifier may consist of multiple attributes. For example, publishers have code numbers assigned by "ISBN agencies." The code number is not unique among all publishers, but is unique among publishers in the same ISBN agency group. Definition: An identifying attribute is an attribute that forms part of at least one identifier. The Publisher's identifier comprises two identifying attributes: Publisher.groupCode and Publisher.publisherCode. The constraint is depicted in Figure 8.5. Or, see Figure 8.6 for the constraint in action language. This action language snippet asserts that the combination of the two attributes must be distinct. Figure 8.5. Multiple-Attribute Identifier Constraint in OCL Figure 8.6. Multiple-Attribute Identifier Constraint in Action Language This idiom is another unique instance constraint, this time with multiple identifying attributes. Constraints involving any number of attributes are possible. But since the unique instance constraint is a common idiom, we do not need to write OCL or action language for it; we simply tag the attributes as shown in Figure 8.7. Figure 8.7. Multiple-Attribute Identifier on Class Diagram 8.1.3 Multiple Identifiers A class may have several identifiers, each of which consists of one or more identifying attributes. In this case, we write several unique instance constraints for the same class. When there is more than one identifier, use the tags {I}, {I2}, {I3}, and so on. Select a new tag for each new identifier, and tag every identifying attribute in a given identifier with that tag. Hence, each identifying tag ({I}, {I2}, {I3}, etc.) applies to all attributes of a single identifier that defines one of the unique instance constraints. Furthermore, an identifying attribute may be a part of more than one identifier. For example, a car can be identified by: manufacturer + serialNumber state + titleNumber state + tagNumber In this example, the state attribute is a part of two identifiers. A single attribute may be a part of several identifiers, so it may be tagged several times. In our example depicted in Figure 8.8, the tags {I2, I3} are shown for the state attribute of Car. Figure 8.8. Multiple Identifiers on Class Diagram Search for identifiers. When abstracting attributes of classes, pay special attention to finding identifying attributes. Look for situations in which no two instances may have the same value for an attribute or set of attributes. In some cases, the business may have unique numbering or identifying schemes for many of the things being modeled. These are the identifying attributes, and they constitute a rule in the domain.

I l@ve RuBoard