Designing and Implementing Business Process Models : ARIS Method manual : Object Modeling Technique (OMT) : Object modeling techniques in ARIS : OMT Object model
OMT Object model
Representation of instances
In object-oriented modeling, objects must generally be documented at the type level (i.e., class level). However, it can be useful to model individual instances as well. The relevant symbol provided by ARIS is a blue rectangle with rounded corners.
Instances
Representation of classes
Classes represent the basic structures of the area of application to be modeled. They are illustrated in ARIS by a blue rectangle (with horizontal lines).
Classes
Assignment of instances to classes
When illustrating instances, assignments to the associated classes can be shown. The corresponding connection is of the is instance of type, as illustrated by the following figure.
Connections between instances and classes
Assignment of attributes to classes
The characteristics of classes are described using attributes. When modeled in ARIS, these are separate objects (and thus also separate symbols) that are linked to the corresponding classes via connections of the has attribute type (see the following figure). The division into two different object types (classes and attributes) is necessary in order to take full advantage of the navigation and report creation capabilities of ARIS.
For each attribute, you can specify whether it is a class attribute (the value is relevant for all instances of the class) or an instance attribute.
Assignment of attributes to classes
Assignment of operations to classes
The functionality assigned to classes is described by defining operations (methods). Here too, a separate object type is available that can be related to classes via a connection of the has operation type (see the following figure).
Assignment of operations to classes
Associations between instances
Individual instances can be linked to each other. These links are illustrated in ARIS using non-directed connections of the is linked to type.
Associations between instances
Associations between classes
Links (associations) can also exist between classes. You are already familiar with these links from the entity relationship model. They are illustrated by their own symbol (yellow diamond), which enables you to illustrate n-relationships in the same way (see below). The connections are drawn from the class symbol to the diamond symbol and can be assigned degrees of complexity, for which the Multiplicity attribute of the connection is used. The following entries are possible for Multiplicity, some of which also result in a corresponding graphical representation of the connection:
*1
*c
*cn
*n
Associations between classes
N associations between classes
Three-figure (or even n) associations between classes are illustrated by linking a third class or even more classes with the diamond symbol defining the link.
Ternary relationship between classes
Modeling an association as a class
An association can also be understood as an independent object and interpreted as a class. This can be expressed by drawing a directed connection from the diamond symbol to one of the class symbols, where you can subsequently list all attributes and operations (see the following figure). Of course, this 'reinterpreted' class can in turn be associated with other classes.
Modeling an association as a class
Representation of qualified associations
A qualified association adds qualification information to a normal association. This information is a labeled attribute that reduces the cardinality of an association. This makes sense for 1:m and n:m associations since the objects on the m side of an association are differentiated in this manner.
A qualifying association is illustrated by adding the qualification information to the connection. For this purpose, the Qualifier attribute is provided. As with all attributes it can also be shown in the graphic.
Representation of qualified associations
Representation of orders for associations
If objects on the n side of an association are arranged in a certain order, you can note this explicitly in the graphic. For this purpose, a separate attribute exists at the connection between the 'Class' and 'Association' symbols.
Representation of orders for associations
Aggregation between classes
An aggregation represents a part-whole relation and can be understood as a special form of association. This relation is modeled as a directed relationship between classes (with the aggregates connection type). In the graphic, a white diamond symbol is used for the class representing the 'whole' (component group).
Aggregation between classes
Generalization and inheritance
One basic construct of object-oriented modeling is the definition of hierarchies between classes, within which subordinate classes can inherit attributes and operations from superior classes. In ARIS, a separate object type exists for this purpose (green triangle). It is linked to the participating classes (see the following figure). Multiple inheritance can also be illustrated.
The generalization operator may be assigned an attribute indicating which aspect is used for generalization/specialization and whether the specialization is disjoint or non-disjoint.
Generalization/Specialization relationship
Restrictions (constraints) for classes, attributes, and associations
Restrictions (constraints) are functional relationships between classes, attributes, and associations of an OMT Object model. In ARIS, separate object types (dot) are defined for constraints on attributes. The following figure illustrates an example showing that the height-to-width ratio for windows can take values from 0.7 to 1.7.
Attribute constraints
You can also define restrictions referring to associations. The example in the following figure shows that the set of persons forming the board of a committee naturally represents a subset of all committee members. This fact can be illustrated by drawing a directed connection between the association symbols.
Association constraints
Example of an OMT Object model
The following figure shows a typical example of an OMT Object model including the main modeling constructs.
OMT Object model
Copyright © 2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback