Shlaer-Mellor and Executable UML Portal

(Top Tabs)

Notation:

Attribute Classification (AttrClass)

Last Updated: 12 August 2010

Attribute Categories and Subcategories

Attribute classification in Shlaer-Mellor [OOA91] involves the following attribute categories:

Whether an attribute is identifying or not is independent of these categories. Shlaer-Mellor [OOA96] added mathematically dependent attributes which may be descriptive or naming.

OOA10 adds literal attributes which can be useful when creating referential or polymorphic attribute mappings. It also adds system set attributes for defining system allocated IDs and providing controlled access to current subtype and current state information. Much more significantly, it adds polymorphic attributes which may descriptive, naming or referential. These additions can be grouped into the following attribute subcategories:

Naming attributes are those representing arbitrary names and labels. Mathematically dependent attributes are often used to create formatted names and labels from more primitive base attributes. Naming attributes will normally participate in one or more identifiers. The distinction between descriptive and naming is not essential for code generation purposes and many analysts ignore the distinction defining all base attributes as descriptive. However, whether an attribute is identifying or not is important for code generation purposes since object indexes and uniqueness constraints are determined from identifiers.

Categories and subcategories are modelled within the Information Model subsystem of the OOA of OOA. However, a partial OIM outlining the key relationships is given below:

OIM for Attribute Classification

Attribute Subtypes

The leaf subtypes in the model are:

Attribute categories, subcategories and the resulting leaf subtypes are summarised in the table below:

Attribute Subcategory
True Polymorphic
Simple Literal Mathematically Dependent System Set
Attribute Category Base Descriptive Simple Base Attribute Literal Base Attribute Mathematically Dependent Base Attribute Mathematically Dependent Referential-Like Attribute1 System Set Attribute2 Polymorphic Base Attribute4
Naming None
Referential Simple Referential Attribute Literal Referential Attribute None None3 Polymorphic Referential Attribute
  1. A mathematically dependent attribute can formalize a mathematically dependent relationship allowing time consuming navigations to be calculated and cached (and observed), the result being an attribute which is referential in nature but which isn't resolved to a base attribute. However, we don't treat this as referential since resolution is central to the currently modelled concept of a referential attribute. It also doesn't make any sense to treat such an attribute as naming.
  2. Whether a system set attribute is naming depends on whether it specifies a system allocated ID or not. If it specifies an ordinal ID then it can be descriptive or naming. If it specifies a non-ordinal ID then it is always naming. Otherwise, it is always descriptive.
  3. Some system set attributes may have an associated relationship, e.g. a current subtype attribute is associated with a subtype-supertype relationship. However, such attributes are not referential in nature.
  4. Whether a polymorphic base attribute is descriptive or naming is determined conservatively using a recursive algorithm, i.e. a polymorphic base attribute is only naming when its mapping is complete and all subtype attributes are naming.

Identifying 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 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 original scheme either has to place significant restrictions on when identifying attributes are allowed to change or has to constantly monitor for changes and fix any effected object indexes when changes occur. I should also point out that referential attribute changes are not normally observable at all even though they can appear frequently in compound identifiers.

(Bottom Tabs)

Copyright © 2009-2010 by Kavanagh Consultancy Limited. All rights reserved.