OMT Object Model
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 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;