Object Information Model Notation

This is the fourth in a series of technical notes outlining the Shlaer-Mellor and Executable UML notation supported by OOA Tool. This technical note covers partial and complete Object Information Models (OIM) which are used to show the objects, attributes and relationships within a domain or subsystem. If a domain is partitioned into subsystems then each subsystem has a partial OIM showing assigned or imported objects along with assigned relationships. This is instead of showing a complete OIM for the entire domain. OIMs also show preferred identifiers, mathematically dependent statuses and referential attribute mappings.

Object Information Models in Shlaer-Mellor notation used to be called Information Structure Diagrams [OOA91]. However, the name Object Information Model was adopted later since OIMs are complemented by Object Communication Models and Object Access Models. This is the only name used in OOA08 and in OOA Tool (when using Shlaer-Mellor notation). Object Information Models are called Class Diagrams in all Executable UML variants, including [xtUML02] and Executable UML2. However, the Executable UML variant [xUML04] makes various minor changes to the Class Diagram notation described here which OOA Tool does not support.

There are a number of other name changes which are relevant here when switching between Shlaer-Mellor and Executable UML notation:

• Information Models are known as Platform-Independent Models (PIM),
• Objects are known as Classes,
• Binary Relationships are known as Binary Associations,
• Composed Relationships are known as Equal Set Constrained Associations,
• Subtype-Supertype Relationships are known as Generalizations,
• Participants are known as Relationship Ends,
• Supertypes and Subtypes are known as Superclasses and Subclasses,
• and the term mathematically dependent is replaced by derived, i.e. Mathematically Dependent Attribute becomes Derived Attribute and Mathematically Dependent Relationship becomes Derived Association.

Below is an example Object Information Model in Shlaer-Mellor notation taken from [OOA91] (see page 4):

Another example Object Information Model showing instances of all notationally different forms of object, attribute and relationship is shown below:

Objects are represented using rectangle shapes containing the object name, key letters and number along with attribute names (prefixed by star or round bullets). The attributes which compose the object's preferred identifier are prefixed by a star bullet. Imported objects are represented using dashed (and half transparent) rectangle shapes containing the same information as normal object shapes. A from annotation is always shown below imported objects, indicating which subsystem the object is imported from. On partial OIMs, key letters always include any prefix letters associated with the subsystem.

Attributes can be hidden by manually reducing the size of an object or imported object shape (after changing the shape's Preferred Size Usage attribute to None or Use As Maximum Size). An OIM which shows no attributes on any of the included objects is called an Overview Object Information Model (it used to be called an Overview Information Structure Diagram in [OOA88]).

Within object shapes, mathematically dependent attributes (introduced in [OOA96]) have an (M) suffix. Referential attributes have an (R) or (Rn, Rn...) suffix where the relationship IDs identify referential attribute mappings, i.e. the relationships that the attribute formalizes. The relationship IDs in a referential suffix may end with c indicating that the reference is constrained. Constrained referential attributes are supported in OOA Tool. However, better support for defining loop constraints will be added in the future. Polymorphic attributes (introduced in OOA08) have a (P) or (P-Rn) suffix where the relationship ID identifies the subtype-supertype relationship determining the polymorphic attribute's scope. Within OOA Tool's browser, naming attributes have an (N) suffix but this suffix is not used in OIMs.

Relationships are represented using rectilinear links labelled with relationship IDs. Relationships are either binary relationships or subtype-supertype relationships. Binary relationships are either simple relationships, associative relationships, composed relationships or mathematically dependent relationships. A binary relationship between an object and itself is called a reflexive relationship. Reflexive relationships are symmetric if both ends of the relationship have the same multiplicity, conditionality and verb phrase. Otherwise, they are called Asymmetric reflexive relationships.

Binary relationships connect a first and second object shape. Simple relationships are centrally labelled with the relationship ID. Associative relationships connect an associative object shape with a binary relationship. The point where the associative object shape connects to the binary relationship is labelled with the relationship ID. Composed relationships are centrally labelled with a summary of the composition, e.g. R10 = R2 + R3 + R4. Mathematically dependent relationships (introduced in OOA08) are centrally labelled with the relationship ID and an (M) suffix. Subtype-supertype relationships connect a supertype and two or more subtype object shapes. The link segment connected to the supertype object shape has a split bar labelled with the relationship ID on the left and the fixed partial verb phrase is a on the right.

A first or second object shape connector is either a single arrow or double arrow (if multiplicity is many) with an optional C annotation (if conditional). The connector is also annotated with the verb phrase (in italics) from the opposite participant, e.g. the verb phrase contains (from R2 in the diagram above) is associated with the LEFT SUBTYPE participant but shown on the RIGHT SUBTYPE connector. If there is no verb phrase and the participant's role (introduced in OOA08) has been changed from the default (i.e. first or second) then the connector is annotated with the role instead. An associative object shape connector is a plain line. A binary relationship connector from an associative link is either a single arrow or a double arrow (if multiplicity is many) with an optional C annotation (if conditional). Conditional in this sense means that the associative object can exist independently of the associative relationship. Associative relationship conditionality was introduced in OOA08. OOA96 introduced a special notation for symmetric reflexive relationships. No arrows or annotations are shown on one end of the relationship, i.e. the second object shape connector is a plain line. Such relationships are normally formalized using an associative object, e.g. R12 in the diagram above. Supertype and subtype object shape connectors are plain lines.

An example Class Diagram taken from [xtUML02] (see page 315) is shown below:

The second Shlaer-Mellor example above is also shown below in Executable UML notation:

Classes are represented using rectangle shapes split into three compartments. The first compartment contains the class name centred in bold along with the key letters and number as a right aligned UML property string. Attribute names along with associated data type names and any initial values are shown in the second compartment. Preferred identifiers are not shown on class shapes. However, identifier IDs for preferred and secondary identifiers are included in the UML property strings associated with identifying attributes in the second compartment. Event names are optionally shown in the third compartment. The class shape must be manually increased in size to show events (after setting Preferred Size Usage attribute to None or Use As Minimum Size). The second and third compartment can be hidden by manually reducing the size of a class shape (after changing the shape's Preferred Size Usage attribute to None or Use As Maximum Size). Imported classes are represented using half transparent rectangle shapes containing the same information as normal class shapes. An imported from annotation is always shown right aligned (just below the class name) in the first compartment of imported classes, indicating which subsystem the class is imported from.

Within the second compartment of class shapes, derived attributes have a slash '/' prefix. Conditional attributes are not currently distinguished in Executable UML class diagrams. However, a [0..1] multiplicity expression is normally shown immediately after the attribute name. The name of an attribute's data type (if defined) is shown after the attribute name prefixed by a colon ':' separator. This is followed by the attribute's initial value (if one is defined) prefixed by an equals '=' separator. Identifying attributes have an {In, In...} property set where the identifier IDs identify which identifiers the attribute is part of. Note that, I1 is always abbreviated to I. Referential attributes have an {Rn, Rn...} property set where the relationship IDs identify referential attribute mappings, i.e. the relationships that the attribute formalizes. Referential attributes without referential attribute mappings and constrained referential attributes are not distinguished on class diagrams. Polymorphic attributes (introduced in OOA08) are shown in italics and have a {P-Rn} property where the relationship ID identifies the generalization determining the polymorphic attribute's scope. Literal value attributes have a {frozen} property indicating that they can't be changed. All properties associated with an attribute are included in a single right aligned UML property string.

Relationships are represented using rectilinear links labelled with relationship IDs in italics. These are solid links except for links between association classes and binary associations which are short dashed links. Relationships are either binary associations or generalizations. Binary associations are either simple associations, association class associations, equal set constrained associations, subset constrained associations or derived associations. However, OOA Tool does not currently support subset constrained associations. It will when better support for loop constraints are added. A binary association between a class and itself is called a reflexive association. Executable UML does not support aggregations, compositions or n-ary associations. Furthermore, only disjoint complete generalizations are supported.

Binary associations connect a first and second class shape. Simple associations are centrally labelled with the relationship ID. Association class associations connect an association class shape with a binary association. The point where the association class shape connects to the binary association is labelled with the relationship ID. Equal set constrained associations are centrally labelled with the relationship ID and equal set constraint, e.g. R10 {equal, R2, R3, R4}. Derived associations are centrally labelled with the relationship ID prefixed with a slash '/'. Generalizations connect a superclass and two or more subclass shapes. The link segment connected to the superclass shape is centrally labelled with the relationship ID (in italics) on the left and the fixed constraint {disjoint, complete} on the right.

All class shape connectors except for superclass shape connectors are plain lines. A superclass shape connector is a large hollow arrow. Multiplicity and conditionality on first or second shape connectors are indicated using one of the following annotations: 0..1 for zero or one, 1 for exactly one, 0..* for zero or more, or 1..* for one or more. These connectors are also annotated with the verb phrase from the opposite participant, e.g. the verb phrase contains (from R2 in the diagram above) is associated with the LeftSubtype participant but shown on the RightSubtype connector. If there is no verb phrase and the participant's role has been changed from the default (i.e. first or second) then the connector is annotated with the role instead. A binary association connector from an association class is also annotated with one of the above multiplicity and conditionality annotations if multiplicity is many or conditionality is true. An explicit 1 annotation is never used here. A multiplicity of many indicates that there may be many association class associations between any given first and second class. A conditionality of true indicates that the association class can exist independently of the association class association. This level of formality (which is not defined in standard UML) is required to validate navigation across arbitrary relationships in Executable UML.

Finally, the second Shlaer-Mellor example above is also shown below in Executable UML2 notation:

Rather than repeat what was previously discussed, only the differences between Executable UML and Executable UML2 notation are listed below:

• Imported classes are represented using half transparent rectangle shapes (with half transparent borders) containing the same information as normal class shapes. A from annotation is always shown centred (just below the class name) in the first compartment of imported classes, indicating which subsystem the class is imported from.
• The colon ':' separator used between attribute and type names now appears without a proceeding space.
• Conditional attributes are indicated by including a [0..1] multiplicity expression immediately after any type name.
• Literal value attributes have a {readOnly} property indicating that they can't be changed.
• Relationships are represented using rectilinear links labelled with relationship IDs in bold.
• The links between association classes and binary associations are still short dashed links but dash lengths are slightly longer in Executable UML2.