OMT Object Model
4. Notation, Concepts and Constructs
This chapter gives an overview of the notation of Object Diagrams and also
gives the concepts and constructs related to this technique.
Here is a short overview of the notation.
Here is an example of the Object Diagram notation .
The following concepts are discussed at this page:
4.1 Classes
A class describes a group of objects with similar properties (attributes), common behaviour (operations), common relationships to other classes and common semantics.Most objects derive their individuality from differences in their attribute values and their relationships to others. Objects with identical attribute values and relationships are possible. A class is represented by the type of box shown in figure 1.
Figure 1 Figure 2
The class box may have as many as three regions. The regions contain, from top to bottom: class name, list of attributes, and a list of operations. Each attribute name may be followed by optional details such as type and default value. Each operation may be followed by optional details such as argument list and result type. Attributes may or may not be shown; it depends on the level of detail desired.
Figure 2 (rounded box) shows an object instance, which is a particular object from an object class. The box is not divided in particular regions. Object instances can be used in instance diagrams, which are useful for documenting testcases and discussing examples.
4.1.1 Attributes
An attribute is a data value held by objects in a class. Each attribute has a value for each object instance. This value should be a pure data value, not an object. Attributes are listed in the second part of the class box. Each attribute name may be followed by the optional details. An object modelshould generally distinguish independent base attributes from dependent derived attributes
4.1.2 Operations
An operation is a function or transformation that may be applied to or by objects in a class. All objects in a class share the same operations. Each operation has a target object as an implicit argument. An operation may have arguments in addition to its target object, which parameterize the operation. The behaviour of the operation depends on the class of its target.
A polymorphic operation means that the same operation takes on different forms in different classes.
A method is the implementation of an operation for a class. The method depends only on the class of the target object.
Operations are listed in the lower third of the class box. Each operation name may be followed by optional details, such as argument list and result type. The name and type of each argument may be given. An empty argument list in parentheses shows explicitly that there are no arguments.
4.2 Associations
A link is a physical or conceptual connection between object instances. An association describes a group of these links with common structure and common semantics. It shows a relation between two (or more) classes. An association is represented by a line between classes, see Figure 3.
Figure 3
Association names are optional. If the association is given a name, it should be written above the line. Association names are italized. In case of a binary association, the name reads in a particular direction, but the binary association can be traversed in either direction.
A special form of association is an n-ary association. Figure 4 shows a ternary association.
Figure 4
The OMT symbol fot ternary and n-ary associations is a diamond with lines connecting to related classes. A name for the association is optional and is be written next to the diamond. N-ary associations cannot be subdivided into binary associations without losing without losing information.
4.2.1 Multiplicity
Multiplicity specifies how many instances of one class may relate to a single instance of an associated class. Multiplicity constrains the number of related objects. Figures 5 and 6 show multiplicity.
Figure 5 Figure6
There are special line terminators to indicate certain common multiplicity values. A solid ball (figure 5) is the symbol for "many", meaning zero or more. A hollow ball (figure 6) indicates "optional", meaning zero or more. The multiplicity is indicated with special symbols ('*' in fig. 5,6) at the ends of association lines.In the most general case, multiplicity can be specified with a number or set of intervals. No multiplicity symbols means a one-to-one association.
4.2.2 Link attributes
A link attribute is a property of the links in an association.Each link attribute has a value for each link. The OMT notation for a link attribute is a box attached to the association by a loop, see figure 7.
Figure 7
One or more link attributes may appear in the second region of the box. Sometime it is possible, for one-to-one and one-to-may associations, to fold link attributes into the class opposite to the "one" side. But as a rule, link attributes should not be folded into a class because future flexibility is reduced if the multiplicity of th association should change.
It is also possible to model an association as a class. Each link becomes one instance of the class. The notation for this kind of association is the same as for a link attribute and has a name and (optional) operations added to it.
4.2.3 Role names
A role is one end of an association. A binary association has two roles, each of which may have a role name. A role name is a name that uniquely identifies one end of an association. Roles provide a way of viewing a binary association as a traversal from one object to a set of associated objects. Each role on a binary association identifies an object or set of objects associated with an object at the other end. Figure 8 shows how to represent roles.
Figure 8
The role name is a derived attribute whose value is a set of related objects. Use of role names provides a way of traversing associations from an object at one end, without explicitly mentioning the association.
The use of role names is optional, but is often easier and less confusing to assign role names instead of, or in addition to, association names. Role names are necessary for asscociations between two objects of the same class. They are also useful to distinguish between two associations between the same pair of classes. Two rules: All role names on the far end of associations attached to a class must be unique. No role name should be the same as an attribute name of the source class. It is also possible to use role names for n-ary associations.
4.2.4 Ordering
Usually the objects on the "many" side of an association have no explicit order, and can be regarded as a set. Sometimes, however, the objects are explicitly ordered. An ordered set of objects on the "many" end of an association is represented like in figure 9.
Figure 9
"{ordered}" is written next to the multiplicity dot for the role.
4.2.5 Qualification
A qualified association relates two object classes and a qualifier. The qualifier is a special attribute that reduces the effective multiplicity of an association. One-to-many and many-to-many associations may be qualified. Figure 10 shows how to represent a qualification.
Figure 10
The qualifier is drawn as a small box on the end of the association line near the class it qualifies.
The qualifier distinguishes among the set of objects at the "many" end of an association. A qualified association can also be considered a form of ternary association. It improves semantic accuracy and increases the visibility of navigation paths.
4.2.6 Aggregation
Aggregation is the "part-whole" or "a-part-of" relationship in which objects representing the components of something are associated with an object representing the entire assembly. Aggregation is a tightly coupled form of association with some extra semantics. Aggregation is shown in figure 11.
Figure 11
Aggregations are drawn like associations, except a small diamond indicating the assembly end of the relationship. In figure 11 the second class is a part of the first, the third class is a part of the second, so the third class is a part of the first.
4.3 Generalization and Inheritance
Generalization is the relationship between a class and one or more refined versions of it. The class being refined is called the superclass and each refined version is called a subclass. Attributes and operations common to a group of subclasses are attached to the superclass and shared by each subclass. Each subclass is said to inherit the features of its superclass. Generalization is sometimes called the "is-a" relationship, because each instance of a subclass is an instance of the superclass as well. The OMT notation for generalization is shown in figure 12.
Figure 12
The notation for generalization is a triangle connecting a superclass to its subclasses. The discriminator is an attribute of enumeration type that indicates which property of an object is being abstracted by a particular generalization relationship. Only one property should be discriminated at once. The discriminator is an optional part of a generalization relationship. It is not good to nest subclasses too deeply, because they can be very difficult to understand.
4.4 Rules for a correct diagram
An Object Diagram should comply with the following rules to be a correct diagram:
Attributes should be pure data values, not objects;
No classes with te same names
Associations should be at least between 2 classes
No attributes & operations with the same names in one class
Do not bury pointers or other object references inside objects as attributes. Instead model these as associations;
Link attributes must not be collapsed into classes;
Every subclass has at least one superclass
Each operation must have a target object as an implicit argument
Object models should be documented;
