Thursday, 5 February 2009The attribute classification hierarchy in OOA88 and OOA91 is shown below:
Attribute
- 1.
- Descriptive Attribute
- Naming Attribute
- Referential Attribute
- 2.
- Identifying Attribute
- Non-Identifying Attribute
The attribute classification hierarchy in OOA10 is shown below:
Attribute
- 1.
- True Attribute
- Base Attribute
- 1.
- Simple Attribute
- Arbitrary ID Attribute
- Mathematically Dependent Attribute (Derived Attribute in Executable UML)
- 2.
- Descriptive Attribute
- Naming Attribute
- Referential Attribute
- Polymorphic Attribute
- 2.
- Identifying Attribute
- Non-Identifying Attribute
In the above classifications, a numbered list represents an and hierarchy while a plain list represents an or hierarchy, e.g. an attribute is true or polymorphic and identifying or non-identifying. Attributes can also be classified according to their associated data type. However, data type hierarchies will not be discussed here.
OOA96 introduced mathematically dependent attributes which are discussed in [31May08].
OOA10 introduces polymorphic and arbitrary ID attributes. Polymorphic attributes (and true attributes) are discussed in [26May08]. A detailed discussion on arbitrary ID attributes will be published soon. OOA10 also introduces base attributes (and simple attributes) because all referential attributes must resolve to a single base attribute (see [29May08]) and all base attributes are descriptive or naming attributes.
Arbitrary ID attribute could be merged with simple attribute except that it has a very different lifecycle. Although arbitrary ID attributes can be assigned values like simple attributes, any assigned values are temporary in nature since the allocation of arbitrary ID values is platform controlled not user controlled. Anyone who assigns a value to an arbitrary ID attribute needs to understand how long that value will persist (arbitrary ID types provide some control here but not complete control). For ordinal arbitrary ID values, the user is rarely interested in the exact value, only it's ordering relative to other object instances. For non-ordinal arbitrary ID values, the user is almost never interested in the exact value. Furthermore, the user may never actually need to access such values at all, i.e. the arbitrary ID attribute may only exist in the information model to formalize one or more relationships.
Naming attributes are those representing arbitrary names and labels. Most but not all arbitrary ID attributes are naming attributes. Mathematically dependent attributes are often used to create formatted names and labels from more primitive naming attributes. The distinction between descriptive and naming attributes is not essential for code generation purposes and many information models will ignore this classification defining all base attributes as descriptive attributes.
Identifying attributes are central to the idea that relationships should be formalized in information model specific terms allowing constraints between relationships to be clearly specified. However, the object identities defined by identifying attributes are not fixed and may change frequently depending on the number and nature of the identifying attributes that compose each identifier. The reason that mathematically dependent, referential and polymorphic attributes may be identifying attributes is that the implementation of object identity within Action Language code is normally based on object instance references (or handles). It only appears within an information model that object identity is implemented using identifying attributes. Of course, this appearance was reinforced in OOA91 because Lifecycle Model directed events carry identifying attributes to reference destination object instances. This is no longer the case in OOA10.
Some would argue that a software architecture should be free to choose how it implements object identity. However, the reality is that you can only use mathematically dependent, referential and polymorphic attributes as identifying attributes on secondary identifiers unless you use some concept of object instance reference. And even if you do stick to simple attributes for identifying attributes, you still need to be able to handle changes to those attributes. You can of course, use identifying attributes to find object instances (using a select statement) when those object instances are known to be consistent. However, in most cases, object instances are found by navigating relationships and relationship instances are best realized using object instance references (not identifying attributes).