Role-oriented software modeling is an approach to objectoriented software engineering which provides a stricter encapsulation by separating the type behavior from the object into so-called roles. This role behavior can dynamically be accessed in certain situations and extends or alters the original type behavior. The process of extending or altering type behavior in object-oriented systems is realized by so-called method dispatch which controls message sending and routing. It is thus essential to guarantee the correct execution of the model. In this paper we present a context-based construction to describe the method dispatch via special formal contexts containing bonds. It turns out that the bond-induced morphisms serve well for determining the role method which is bound to a certain base method during runtime. This formal context can also be used to check the role model and determine whether base and role methods are bound correctly.
Role orientation is an approach to object-oriented software modeling that relies
on separating the behavior from the object. It was introduced in the 1990s by
Trygve Reenskaug [
The scope of this paper lies in formalizing the method dispatch in
roleoriented software models. Method dispatch is a mechanism in object-oriented
software models that determines and invokes the correct piece of code for a
certain method call [
Formal Concept Analysis (FCA) establishes a connection between binary
relations and complete lattices [
AI m > M S ƒ g > A gIm b M; BI g > G S ƒ m > B gIm b G one can create formal concepts of a formal context G; M; I as pairs A; B with A b G; B b M; AI B; BI A. A is then called extent, B is called intent. With introducing an order relation on the set B G; M; I of concepts via A1; B1 B A2; B2
A1 b A2
B1 b B2 the basic theorem of FCA [2, p. 20] states that B G; M; I B G; M; I ; B is indeed a complete lattice.
An interesting way to combine two contexts is done via so-called bonds. Given two contexts Ks Gs; Ms; Is ; Kt Gt; Mt; It , a relation Jst b Gs Mt is called bond, i g Jst is an intent of Kt for each object g > Gs and m Jst is an extent of Ks for each attribute m > Mt. As stated in [1, p. 15] each bond Jst induces two morphisms 'st B Gs; Ms; Is
B Gt; Mt; It ; st B Gt; Mt; It
B Gs; Ms; Is by 'st A; AIs
st BIt ; B
The rest of the paper is organized as follows: In Section 2 we show the
essential contexts to represent a role model in order to describe the method
dispatch. A more detailed explanation of the model construction, as well as
some results that show the unambiguousness of our approach can be found in [
Since we provided a concept-based approach for describing role models and role
play [
Combined Representation for the Static Model
To create a suitable formal context for our purpose, we keep close to the approach
in [
De nition 1. Let C B; R; P be a role model1, MB; MR sets of base resp. role type methods, IB; IR the respective incidence relations. Let VB; VR be sets of virtual objects2. The formal context G; M; J with
G
B^ < R^;
M
MB < MR;
J
I^B 8 I^R 8 JBR such that JBR b B^
MR is called binding context of C. We have VB b; m S § b > B; m > MB bIBm ;
NB v; m S § v b; m > VB VR and NR are de ned analogously. If JBR forms a bond between and R^; MR; I^R and ful lls the following conditions B^; MB; I^B ƒ b > B; m > MR
b; m > JBR ƒ v
b; w > VB vJ b bJ ƒ v > VB SvJBR S 1 ƒ m > MR mJBR x g
^ § r > mIR bP r (1) (2) (3) (4) G; M; J is called proper binding context.
The virtual objects in VB resp. VR are necessary to explicitly distinguish between the methods. We thus are able to adress each method with a special concept and thus receive unique mappings under 'BR resp. BR.
The rst two conditions of De nition 1 describe that the bond combines only
such base types (and their respective virtual objects) with role methods if the
according base type can play the according role type. The third condition says
that each virtual object needs to be bound to exactly one role method. This
is a comprehensible claim, since virtual objects in a sense represent base type
methods and we assumed that each base type method is bound to exactly one
role type method [
Dynamic Model for the Base Type Hierarchy
Since we want to describe the method dispatch during runtime it is necessary to
describe the runtime instances in a formal context as well. According to [
B^t; MB; I^Bt B^t
B^ 8 It;
I^Bt via I^B 8 Ct where
Ct
i; m S § i > It; m > MB i receives a call from m
It has to be said that we assume a sequential execution of our role model, i. e. each instance can only call one single method at a time. This is su cient since one can easily map parallel activities to a sequential execution plan. 3
Performing the Method Dispatch It is essential for role modeling to determine at runtime the method dispatch between base types and the according role types. At modeling time (i. e. when setting up the role model) each method mb > bIB of a base type b > B is assigned to a method mr > rIR of a respective role type r > R that can be played by b in order to alter the behavior of the base type when playing this role. At runtime it is necessary to correctly dispatch method calls from the base type method to the appropriate role type method to guarantee correct altering of the behavior.
For resolving the method dispatch, we will use the bond-induced morphisms 'BR and BR of the proper binding context as recalled in Section 1.
Let t > T be a point of runtime and i > It a certain instance receiving a method call from m > MB. Algorithm 1 shows how the role method m~ > MR that is bound to m can be determined.
Algorithm 1 An algorithm for method dispatch
The algorithm requires the appropriate method call context as well as the
proper binding context and gets an active instance i > It as well as a base type
method m > MB as inputs. It needs to be ensured that i indeed receives a call
from m. Applying the bond-induced morphism 'BR from the base type context
to the role type context to the attribute concept of m we receive a concept
having only role methods in its intent. One can show that 'BR maps concepts
having only one base method in their intent towards concepts having only one
role method in their intent which guarantees the determinacy of the result. [
instance i > It, method m > MB ^t Ensure: m > iIB 1: c mI^B ; mI^BI^B 2: c~ 'BR c 3: m~ int c~ 4: return m~
Lecture
Lecturer material:Collection explainClearly():void writeNeatly():void
Participant material:Collection grade:int chatterQuietly():void writeNeatly():void Professor Pr1 Pr2 AssistantProfessor As1 As2 Student St1 St3 Lecturer Le1 Le2 Participant Pa1
Pa3 Role-oriented software modeling is an approach towards object-oriented software engineering, gaining a higher encapsulation and modularization of software models by separating the behavior from the object. The behavior is encapsulated in special modules, roles, and is woven into the software model during runtime.
The crucial point in role modeling is the so-called method dispatch, which redirects method calls to base methods towards appropriate role methods and thus enables the intended change of type behavior. Since the model designer determines at modeling time which base methods can be altered by which role methods when playing the respective role, it has to be guaranteed that performing the method dispatch during runtime strictly follows these assignments.
Our approach uses a context construction via so-called bonds to create special formal contexts which uniquely represent the assignment between base and role methods. We then presented an algorithm using these contexts to determine the role method that is assigned to a given base method. Our construction can thus be used to assist the process of role-oriented software modeling. 5
Together with the results from [
However, there are still a lot of open elds of research to completely cover role modeling with concept-based constructions. Among others, it is on the one hand necessary to describe composition and decomposition of large role models, e. g. to build kind of a design advisor for role models that helps to identify redundancy or inconsistencies of the model. On the other hand, it is necessary to provide an extensive framework to represent role-play constraints or special characteristics of role-oriented software design, like multiple role play. Since we have already applied FCA successfully towards the foundations of role modeling, a further research in this direction will be very promising.