ARIS Community - We Love BPM

Generalization/Specialization

Eva Klein's picture
by Eva Klein in ARIS BPM Blog posted on 2013-05-28

Generalization/specialization - aka “is-a relationship” – is typically used to represent hierarchical associations between entity types. The subordinated (“specialized”) entity type is a subset of the superior (“generalized“) entity type; it inherits the attributes and relationship types of the “generalized“ entity type. A specialized entity type, however, may have attributes and relationship types of its own.

Generalization/specialization relationship type
Figure 1: Generalization/specialization relationship type

In ARIS the object type “Generalization type and the connection types “is supertype of” and “is subtype of” are necessary to model generalization/specialization relationships.

Generalization type” is a typical ARIS object type. Thus, it has attributes (see Figure 2). In the above example the object is named “is-a”. Many customers use this name or even leave it out. But, if you want to give the object a meaningful name, I suggest to specify the differentiation criterion. In the above example you could for example use “employee role”.

Attributes of the object type “Generalization type”
Figure 2: Attributes of the object type “Generalization type”

The attribute “Degree of division” allows you to specify whether the specialization is complete (or not) and disjoint (or not). This attribute is a value attribute. The predefined values are shown in Figure 3. They are explained at a later date in the article on cardinalities.

Values of attribute “Degree of division”
Figure 3: Values of attribute “Degree of division”

In my opinion, there is a mistake. Do you see it? If so, tell it to the ARIS Community. Otherwise, wait until my article on cardinalities is available.

Additional object types in the eERM

In the eERM in ARIS you can find additional object types: application system type, IT function type, capability, service type, and socket. These object types do not belong to the ARIS data view, but to the ARIS function view. They have been introduced in the eERM based on the strong demand of an important ARIS customer. However, I suggest not to use these object types in the eERM and to deactivate them in a filter.

The same holds for the object type “COT attribute”, which is also available in the ARIS eERM.  “COT” is the abbreviation for “Complex object type”. The COT attribute was used in an IDS Scheer internal application and is not relevant for ER data modeling.

23808 Views
0 Likes
2 Comments
Sorry there are no tags
There are no attachments
Paul Smekens posted on 2017-01-12

If you use the connection type 'has relationship to', the appearance of the connection changes according to the source and target cardinality attribute values.

Can you do the same for the connection type 'is subtype of' and 'is supertype of', using the attribute 'Degree of division'?

Kind regards,

Paul

M. Zschuckelt posted on 2017-01-12

I just have the case at a customer, where we use the "degree of division" attribute. We created symbols for the 0, c, cn, n attribute values and make them show inside the triangle of the generalization object. Indeed it is an attribute of the generalization object and not of the "is subtype of" and "is supertype of" connections. They show the role of the linked object with respect to the generalization and the type determines, whether the connection will link to the vertex of the triangle or the middle of the base. In this sense you already have made the role of the objects clear on each side of the Generalization.

The "mistake" Eva refers to is the "0" value, which should be "1" to make sense.

Here is our interpretation:

"1" (instead of "0"): complete, disjoint. The specialized object inherits lifecycle and identity of the generalized object. There can be no instance of the generalized object, any instance occurs as one of the specializations.

"c": incomplete, disjoint. The specialized object inherits lifecycle and identity of the generalized object, but not every object needs to occur as one of the specialized entities.

"cn": incomplete, not disjoint. A role-like specialization: Person - Employee, Person - Spouse. The llfecycles of Employee and Spouse are separate from "Person". The same Person may have multiple roles.

"n": complete, not disjoint. A role-like specialization: I can't think of a good practical example of "complete, not disjoint". "Complete" would mean that in the above example we don't have persons who are neither Employee nor Spouse. I think this case is of academic interest.

For "joint" we took an X symbol and for disjoint something that looks like ||. These we combined with a circle for "complete" and a semi-circle for "incomplete".