Roles have been introduced by Halpin as means to encapsulate the behavior of objects within a specific context [183]. The tool integration approach that will be presented in Chap. 8 defines data repositories and data representations as such a context. There, role models are used to enable tools to work on arbitrary data. Since we aim at using models based on the EMOF standard as primary type of artifact, the question is how object-oriented modeling and role modeling can be integrated. This entails both a con- ceptual mapping and a technical realization that will serve as a basis to evaluate our tool integration approach. Before we dive into the specifics of object-oriented modeling and role modeling, we will briefly recapitulate their most important properties.
Object-oriented metamodels consist of classes, attributes and references. Classes can inherit from each other. Attributes have a primitive type, while references are assigned to complex types (i.e., other classes). Both attributes and references can have multiplicities that specify the amount of values (or objects, respectively) they can hold. Classes may also own operations, which specify behavioral aspects. However, for synchronizing models only data is considered. Thus, operations can be omitted.
Common standards for object-oriented metamodels do define more properties for classes, attributes and references. For example, classes can be abstract, attributes can be derived or references can be tagged as containment. For the time being, these additional properties will only be analyzed if they have implications for our work.
Role types and role models can be considered as an extension to object-oriented mod- eling [37]. Role types specify a relation between one or more classes. For example, the role typeFather relates a man and his child. Roles, being instances of role types, can be attached to objects (e.g., a man becomes a father when birth is given to his child). In this case the man object is said to play the father role. Conceptually, classes and roles can be distinguished according to their rigidity [39]. Classes are rigid because they can exist on their own, while roles cannot, because they depend on an object to be attached to. For example, while a man can exist without being a father, the father role needs to be bound to a man. When the man deceases, its father role is inevitably lost. One can also say that classes are sets of things that carry an identity, while roles can only be identified by the identity of their players.
In this section we will analyze the conceptual relation between object-oriented models and role models (Sect. 5.5.1). Also, we will review the completeness of the established mapping between role models and object-oriented models in Sect. 5.5.2.
5.5.1 Conceptual Mapping
Similar to the mappings presented before and as proposed in the general procedure to establish bridges between technical spaces, we will now look at mapping structures, primitive data types and semantics. Emphasis is mainly put on the first and third point.
5.5 Bridging Role Modeling and Object-oriented Modeling Classifier Attribute superclasses Reference Containment Reference Non-containment Reference typ e typ e 1 2 5 OO Modeling Concepts NaturalType
Role Modeling Concepts
Multiplicity Feature cardinality 4 Type RoleType 1 3 1 plays Property Relation 2 3 Multiplicity 4 supertypes 5 typ e
Figure 5.6: Conceptual mapping between object-oriented models and role models.
This is caused by the non-existence of a standardized metamodeling language for role models. Thus, we base our mapping on the assumption that role models and object- oriented models do share the same set of primitive types. As role models are an extension to object-oriented models, this assumption is reasonable.
Structural Mapping To map purely object-oriented models to role models, the map- ping depicted in Fig. 5.6 is proposed. One can find both the object-oriented concepts (e.g., Classifier, Reference or Attribute), as well as the concepts of role modeling (e.g., NaturalType or RoleType).
The most simple mapping can be established between natural types and classes. In object-oriented modeling, classes are used to represent both rigid types (i.e., natu- ral types) and non-rigid types (i.e., role types). No distinction is made between the two. Thus, representing natural types as classes is a reasonable option (Mapping (1) in Fig. 5.6). Both share the same meaning w.r.t. their usage in models.
Role types capture relations between classes. Thus, one could map them to references in object-oriented models. However, references in EMOF can connect exactly two classes only. If a role type establishes a relation across more than two types, it cannot be mapped to a single reference anymore. For example, consider the role type TeamLeader in Fig. 5.7, which relates one person—the leader—with multiple other persons—the team members—and a company—the one the team works at. Such a collaboration cannot be modeled with a single reference in EMOF. Thus, we map role types to classifiers, as these allow to model n-ary relations.
5 Bridging Technical Spaces Company 1 1..* Person members
TeamLeader company Company
1 1..* members TeamLeader company Person teamlead
Figure 5.7: Example mapping of a role type to a class.
An example for mapping a role type (i.e.,TeamLeader) to a class is shown in Fig. 5.7. Basically, the role type is replaced by a class and the playsA relation is replaced by a reference. Note that the multiplicities of the relations in the role model must be resembled by the ones in the object-oriented model. As the role model allows teams to have arbitrary many members, the object-oriented model must permit the same.
Types in role models—both natural types as well as role types—can have properties, similar to classes. Properties are equivalent to attributes in the sense that they must have a primitive type. Thus, mapping attributes to properties seems to be a natural choice (Mapping (2) in Fig. 5.6). References and relations do both connect types (i.e., classes, role types and natural types). They share the same semantics and are therefore natural counterparts (Mapping (3) in Fig. 5.6).
Handling inheritance between classes is straightforward, since both role modeling and object-oriented modeling, the former being an extension of the latter, provide this con- cept with exactly the same semantics. Thus, all inheritance links between types (i.e., either role types or natural types) can be represented by links between the respective classes (Mapping (5) in Fig. 5.6).
In total, the following mappings can be established between the concepts available in role modeling and object-oriented modeling:
• natural types can be mapped to classes (1), • role types can be mapped to classes (1), • properties can be mapped to attributes (2), • relations can be mapped to references (3), • inheritance is represented identically (5).
Mapping Primitive Types In the scope of this thesis, we will consider role models as extension to object-oriented models in the sense that we will add the concept of role
5.5 Bridging Role Modeling and Object-oriented Modeling
types to the concepts defined by the EMOF standard. Thus, both our role models and object-oriented models share the same set of primitive types. A mapping is therefore basically the identity function.
Mapping Semantics Even though roles seem to be a very clear concept at first glance, there is quite diverse interpretations about their semantics. A detailed comparison of the different aspects of the semantics of roles can be found in [184]. This does also include a list of references to the many published interpretations w.r.t. all the aspects. In the following, we will stick with this semantics (criteria according to [184]):
1. roles are types (i.e., they have their own properties and behavior),
2. roles do not depend on relationships (i.e., a role can be attached to a single natural type also),
3. objects can play multiple roles simultaneously, 4. roles can be dynamically acquired and abandoned,
5. role acquisition can be restricted (i.e., one role may only be acquired after playing another one),
6. unrelated types can play the same role, 7. roles can play roles,
8. roles can be transferred (from one object to another), 9. object states can be role specific,
10. object features can be role specific, 11. roles restrict access,
12. roles may share features or behavior, 13. objects share their identity with their roles.
For the purpose of binding modeling tools to arbitrary data repositories and data representations (cf. Chap. 8), where we are interested in the information represented by objects and roles (i.e., the static aspect of a modeled structure), the dynamic semantics of roles is not of utter importance. Thus, the criteria 4 and 8 can be neglected.
To check whether all other semantic criteria are respected by the presented mapping, one must keep in mind that object-oriented modeling subsumes both natural and role
5 Bridging Technical Spaces
types as classes. Thus, the question is whether the semantics of the concept class is compatible with the semantic properties listed above.
Criterion 1 states that role (and natural) types are full-fledged types, which is also true for classes. Criterion 2 is also fulfilled by classes, since these can be attached to a single other class using a reference anyway. Furthermore, classes can have references with an unlimited upper bound, which allows to reference multiple objects. This is equivalent to criterion 3. The restriction of role acquisition (criterion 5) is similar to restricting the addition of references in classes. While this is usually implemented in the code that handles reference additions and not modeled, the concept is present in object-oriented models as well. Criterion 6 is equivalent to having multiple classes that reference the same class. Roles playing roles (criterion 7) is simply captured by the fact that references between classes are not restricted w.r.t. the types they connect.
The next criteria (9 and 10) are more subtle, since objects on their own cannot behave different in specific contexts. However, if objects are encapsulated (e.g., by the use of del- egation), different states can be observed and different features can be implemented. The specific observed behavior or obtained data does then depend on the concrete delegating object. Thus, this kind of semantics can be established both in object-oriented models as well as in role models. The same applies to criterion 11 with the same argument (restriction is possible using delegating objects).
Criterion 12 (sharing features and behavior among roles) is about inheritance between roles, which is along the lines of class inheritance and therefore compatible as well. The last criterion (sharing identity between roles and naturals) is more subtle. Since we map both role types and natural types to classes, the question is whether two objects belonging to two different classes can share the same identity. In EMOF, this is not possible, because classes denote disjoint sets of objects unless the classes are connected by an inheritance relation. However, to establish shared identities, one can use a dedicated procedure to check objects for equality. If this procedure (e.g., an operation isSame) implements shared identities, criterion 13 can be fulfilled.
One can see that the extension of object-oriented models to support roles is quite natural from a semantic perspective, if roles are defined as stated by the 13 criteria above. If the semantics of roles differs, which is often the case according to the context in which role modeling is used, a mapping would probably look different. For the scope of this thesis we will stick with the mapping and the semantics informally defined above, since both are reasonably compatible.
5.5.2 Conclusion
In this section, we discussed the mapping of role models to object-oriented models. First, the mapping of the structures found in object-oriented metamodel to role models needed to be clarified. The result of this investigation is that such a mapping is possible, but leaves certain degrees of freedom. For some mappings one can choose between different