9.2. Object-Orientation
UML facilitates object-oriented (00) code design because it covers both data and behavioral modeling, and lets you drill down into physical design details relevant to OO-code. The class diagram in Figure 9.2 models a class whose instances are screen dialog boxes.
Figure 9.2. Example of a UML class.
The class shape in Figure 9.2 has three compartments. The name compartment includes the class name, as well as a tagged value naming the author of the class. The attribute compartment lists the visibility, name, and type of each attribute. The visibility settings “+”, “–”, “#”, and “~” indicate whether the attribute is public, private, protected, or package. These visibility settings are software, not conceptual, issues. The size attribute is initialized to a given area value. The operation compartment specifies what operations are encapsulated in instances of the class. In this example, the operations may be implemented by methods to display the dialog box at a specific position, and to hide the dialog box.
Figure 9.3 shows another class diagram that depicts Employee and Car classes, as well as an association corresponding to the ORM fact type Employee drives Car. The association is depicted by a line between the classes. The role name “driver” on the left end of the association clarifies the intended semantics (an association reading could also be supplied). The open arrow tip at the right end of the association, is a navigability setting indicating that fast access is required from employee instances to their car instances. This may be implemented by including pointers from employee objects (software objects) to the car objects that model the cars that they drive. Navigability settings are implementation issues related to performance, not conceptual issues about the business domain.
Figure 9.3. The navigability setting demands fast access from Employee to Car.
By omitting implementation details such as attribute visibility and association navigability, class diagrams can be used for conceptual analysis. When used in this way, class diagrams are somewhat similar to ER models. But there is a significant difference arising from the 00 perspective. If you look at the classes in Figure 9.2 and Figure 9.3, what strikes you as missing?
You guessed it! No identification schemas are provided for the classes. In object-oriented programming, objects may be identified by their memory addresses or internal object identifiers (oids), so UML does not require that you provide a value-based identification scheme for use by humans in communicating about the objects. For conceptual analysis, however, such human-oriented reference schemes (e.g., dialog box numbers, employee numbers, car registration numbers) must be supplied. UML does allow you to add such attributes, but has no standard notation for declaring them to be preferred identifiers or even for declaring them to be unique. For this, we choose “{P}” for preferred reference and “{Un}” for uniqueness (n > 0), where the n is used to disambiguate cases where the same U constraint might apply to a combination of attributes. Various UML tool vendors choose different notations for such constraints.
In Figure 9.4, for example, employee number and car registration number attributes have been added as the primary identifiers of employee and car, respectively. This entails that they are mandatory and unique. Additionally, the combination of employee name and birthdate has been declared unique. We also dropped the navigation arrow, as it is irrelevant to the business semantics.
Figure 9.4. Adding nonstandard notations for preferred reference and uniqueness.
The requirement that each class has a value-based identification scheme distinguishes both ORM and ER from UML. ORM classifies objects into entities (non-lexical objects) and values (lexical objects) and requires each entity to be identified by a reference scheme used by humans to communicate about the entity. ORM uses “object”, “entity”, and “value” to mean “object instance”, “entity instance”, and “value instance”, appending “type” for the relevant set of all possible instances. Entities may be referenced in different ways, and typically change their state over time. Glossing over some subtle points, values are constants (e.g., character strings) that basically denote themselves so do not require a reference scheme to be declared.
Figure 9.5(a) depicts explicitly a simple reference scheme in ORM. If an entity type has more than one candidate reference scheme, one may be declared preferred to assist verbalization of instances (or to reflect actual business practice). A preferred reference scheme for an entity type maps each instance of it onto a unique, identifying value (or a combination of values). In Figure 9.5(a), the reference type has a sample population shown in a reference table (one column for each role). Here icons are used to denote the real world employee entities.
Figure 9.5. A simple reference scheme in ORM, shown (a) explicitly and (b) implicitly.
Simple reference schemes may be abbreviated by enclosing the reference mode in parentheses, as in Figure 9.5(b), and an object type’s reference table includes values but no icons. References verbalize as existential sentences, e.g., “There is an Employee who has the EmployeeNr 101”. Entity instances are referenced elsewhere by definite descriptions, e.g., “The Employee who has the EmpNr 101”.
In a relational database, we might use the preferred reference scheme to provide value-based identity or instead use system-generated row-ids. In an object-oriented implementation, we might use oids (hidden, system-generated object identifiers). Such choices can be added later as annotations to the model. For analysis and validation purposes, however, we need to ensure that humans have a way to identify objects in their normal communication. It is the responsibility of humans (not the system) to enforce constraints on preferred reference types. Assuming humans do enforce the reference type constraints, the system may be used to enforce the elementary fact type constraints.
UML classifies instances into objects and data values. UML objects basically correspond to ORM entities, but are assumed to be identified by oids. Although UML does not require entities to have a value-based reference scheme, we should include value-based reference in any UML class intended to capture all the conceptual semantics. UML data values basically correspond to ORM values: they are constants (e.g., character strings or numbers) and hence require no oids to establish their identity. Entity types in UML are called classes, and value types are basically data types. Note that “object” means “object instance”, not “object type”. A relationship instance in UML is called a link, and a relationship type is called an association.