=Paper=
{{Paper
|id=Vol-2245/mrt_paper_3
|storemode=property
|title=Model Synchronization with the Role-oriented Single Underlying Model
|pdfUrl=https://ceur-ws.org/Vol-2245/mrt_paper_3.pdf
|volume=Vol-2245
|authors=Christopher Werner,Uwe Assmann
|dblpUrl=https://dblp.org/rec/conf/models/WernerA18
}}
==Model Synchronization with the Role-oriented Single Underlying Model==
https://ceur-ws.org/Vol-2245/mrt_paper_3.pdf
Model Synchronization with the Role-oriented Single
Underlying Model
Christopher Werner Uwe Aßmann
Technische Universität Dresden Technische Universität Dresden
christopher.werner@tu-dresden.de uwe.assmann@tu-dresden.de
ABSTRACT 1 INTRODUCTION
Models@runtime (M@RT) suffer from information fragmen- Since the 1980s, the software engineering community has
tation across heterogeneous runtime models conforming to realized that there is no silver bullet to solve the complexities
several metamodels that are filled with information from of software processes and model-dependent tasks. Ensuring
a source model. This creates an amount of related models the consistency of information fragments, while the system is
with replicated information. In contrast, a recent approach to running, is an essential aspect in the area of Models@runtime
software engineering utilizes Single Underlying Model (SUM) (M@RT) and Model Driven Engineering (MDE). Consistency
to generate views of a software system on demand. The between two models is defined as follows: Two models are
views represent fragments specifying required information consistent if their combination does not generate any contra-
for model instances. This results in an increasingly complex dictions and is realizable with implementation effort. Consis-
source model which is consistent from scratch and views with tency makes maintaining artifacts a grand challenge. Without
relations between each other that require complex processes much work on maintainability of software elements, the qual-
to maintain consistency. Thus, to hold the views and models ity inevitably degrades over time and with it the quality of
consistent at runtime, an intuitive approach for the creation the final product.
of an adaptable SUM should be introduced that permits run- In the area of M@RT, it is necessary to create new runtime
time synchronization and adaptation of views. We propose models as architecture, performance, and failure models from
utilizing the concept of roles in the domain of SUM-based a running system on the fly [27]. These models may, but do
software engineering and M@RT. Based on existing work in not have to, be predefined in the software and must be hold
the area of role modeling, we present a Role-oriented Single synchronized with all other runtime models and the running
Underlying Model approach that provides a natural way to system. As a solution, we need a runtime adaptation and
create views from a running model. We show how the role synchronization mechanism for new runtime models from
concept simplifies the creation of runtime models as views the running system and for the running system itself. It
from a SUM, provide an incremental view update approach, is possible to create bidirectional synchronization relations
and introduce a flexible adaptation mechanism. Finally, we between all related models creating a collaborative consistent
illustrate our approach with two example views to explain model environment. This method increases the number of
the benefits of a role-oriented SUM. synchronization relations quadratically to the number of
involved models, i.e., n(n-1)/2 where n is the number of
CCS CONCEPTS models. These pairwise consistency relationships must be
• Software and its engineering → Software development meth- added and adapted at runtime. In addition, they must be
ods; Development frameworks and environments; Software maintained over time to overcome modification problems
development techniques; Software design engineering; like: (1) data inconsistency, (2) evolution of models, and (3)
integration of new models.
KEYWORDS The Single Underlying Model (SUM) approach by Atkin-
Model-driven engineering, single underlying model, role-ori- son et al. [3] is the paradigm we will concentrate on, because
ented programming. it overcomes these modification problems. All known infor-
mation of a software system is stored in the SUM, whereby
Reference Format: views represent user- and concern-specific fragments of the
Christopher Werner and Uwe Aßmann. 2018. Model Synchroniza-
information. This reduces the number of correspondences to
tion with the Role-oriented Single Underlying Model. In Proceed-
ings of MODELS conference workshops (MRT’18). 10 pages.
the number of views. The direct implementation of the SUM
approach is the Orthographic Software Modeling (OSM) [3]
approach with minimal overlapping views, which reduces syn-
Permission to make digital or hard copies of part or all of this work chronization problems. However, the current implementations
for personal or classroom use is granted without fee provided that
copies are not made or distributed for profit or commercial advantage of this approach are only design time approaches with a num-
and that copies bear this notice and the full citation on the first page. ber of predefined views and a completely constructed SUM
Copyrights for third-party components of this work must be honored. from scratch. However, the minimization of correspondences
For all other uses, contact the owner/author(s).
MRT’18, October 2018, Copenhagen, Denmark to the number of views and the synchronization of informa-
© 2018 Copyright held by the owner/author(s). tion in the SUM make this approach a good foundation to
extend it by runtime adaptation mechanisms.
MRT’18, October 2018, Copenhagen, Denmark C. Werner and U. Aßmann
Figure 2: Vitruvius architecture [7].
Figure 1: SUM / view centric environment, from [2].
which we combine in the next sections to our Role-oriented
SUM approach.
This paper transforms the SUM approach from design
time to runtime to make it usable in the area of M@RT for
2.1 Single Underlying Model
the synchronization of runtime models as views of the under-
lying source. We use the Compartment Role Object Model As mentioned before, SUM [3] is the central comprehensive
(CROM) by Kühn et al. [23] as SUM modeling concept. The model of a system and contains all information for stakehold-
role concept allows the modeling of views as compartments/ ers (e.g., functional, non-functional, and visual information).
contexts, and contains a natural adaptation mechanism with If the SUM is engineered, it is consistent from scratch. How-
roles that can be bound to objects at runtime and adapt their ever, Atkinson et al. describe that the SUM gets complex for
behavior. In addition, arbitrarily many roles can be bound small models. This complexity does not allow a single user
to each object, which is a natural unlimited extension and to understand the whole SUM. To distribute the complexity
adaptation mechanism provided by roles. In this paper, we to different stakeholders, subsets of a SUM are presented
address the following research questions: in views that support the specific tasks of a user, as shown
in Figure 1. If the views are consistent with the SUM, they
∙ RQ1: How can the role concept simplify the creation of
are also consistent with each other. This is comparable to
runtime views from a SUM and adaptation of a SUM?
views in database management systems. Still, dependencies
∙ RQ2: How can the role concept be used to implement
between the views cause problems during parallel modifica-
an incremental view update mechanism at runtime
tion on same elements in different views. In addition, the
without redundant information?
SUM and views are defined at design time and no runtime
The contribution of this paper is the Role-oriented Single adaptation or extension is possible.
Underlying Model (RSUM) approach using the role con-
cept to create a SUM which is an integrated synchronization 2.2 View-based Software Development
mechanism for views. The concept improves creation of views,
In the view-based software engineering area, views manage
introduces runtime adaptation, runtime synchronization be-
access to information from the models, as described in the
tween SUM and views, and reduces redundant information.
section before. The views handle the complexity of the overall
Furthermore, the RSUM is prototypically implemented in the
system and allow the separation of concerns in views. The
SCala ROLes Language (SCROLL) [25] with an illustrative
IEEE 1471/ISO 42010 standard [17] gives the first definition
example showing the benefits.1 of an architecture view and an architecture view type. In
The remainder of this paper is structured as follows. The this work, we concentrate on the derived view and view type
next section summarizes background knowledge about closely definition of Goldschmidt et al. [12] “A View is the actual
related topics. Section 3 provides an in-depth discussion of the set of objects and their relations displayed using a certain
concepts with an illustrative example and its implementation representation and layout.” [12, p 63] and “A View Type
details. We demarcate our approach from related work in defines rules according to which views of the respective type
Section 4. Finally, in Section 5, we conclude the paper and are created.” [12, p 64]. Hence, views are instances of view
discuss lines of future work. types with elements of a SUM. In view-based modeling, two
fundamental approaches are distinguished: the synthetic and
2 BACKGROUND projective approach. For the synthetic approach, a special
This section introduces the single underlying model approach, architect creates and integrates all views in a system (e.g.,
the view-based software development, and the role concept, SUM [3]). In projective approaches, the views are generated
automatically with a special procedure and do not need any
1
https://github.com/chrissi007/RoleSUM help from a software architect, e.g., Vitruvius [21] with the
Model Synchronization with the Role-oriented Single Underlying Model MRT’18, October 2018, Copenhagen, Denmark
query language ModelJoin [8] to create view types. Figure 2 Person
presents Vitruvius, where users only see a SUM and not the
+name: String
connected metamodels which allows integration and evolu-
tion of new and existing metamodels without constructing
the SUM from scratch, but creates redundant information
in different connected models and needs complex synchro-
nization mechanisms between all metamodels. The creation Library
+employees
Employee
0..1
and synchronization of views from and with the software +name: String +salary: Double
0..* +manager
system is a complex task, which needs a special synchroniza-
tion mechanism. Furthermore, the extension and adaptation
at runtime are not considered in the view-based software
L1: Library E1: Employee
engineering area. employee
name = "CityLib" name = "Alice"
salary = 45000
2.3 Role Concept employee
The role concept is an extension of object-oriented design
considering objects and classes as naturals (instances of nat- E2: Employee
ural types) that can play roles (instances of role types) in a
name = "Bob"
specific compartment (instance of compartment type). Roles salary = 60000
manager
represent the behavior of naturals and can be acquired or
abandoned multiple times. Moreover, roles interact with each
other within compartments. Compartments represent con- Figure 3: Running example with meta- and instance model.
tainers or contexts and separate concerns. An advantage is
that two naturals of the same type can have completely dif-
ferent behavior at runtime because of differently played roles.
3.1 Running Example
The role concept we consider is based on CROM [23] with the For the running example, we use a simplified library model,
graphical notation in [22], which we use for our illustrations. where a Library has different Employees that inherit from
The behavioral, relational, and contextual properties of roles an abstract Person class. The running example is presented
are defined in 26 features which are the foundations of the role in Figure 3 with meta and instance model. In the instance
concept. Henceforth, we utilize CROM to specify the RSUM model, a library L1 with the L2:
name CityLib exists that
Library has
employee
E3: E
and the role-based programming language SCROLL [25] to two employees called Alice and Bob where Bob is the manager salary: Dou
name: String = "City Library"
implement the approach for our running example. SCROLL of Alice. This example can be split into different views. One firstName: S
view can contain the complete information from the instance lastName: S
is an open source Scala library and implements most role
features [25]. It is flexible, lightweight, and easily extensible. model while another view only includes all employees with
In our implementation, we use two main features of SCROLL: their manager and a third view only provides the library with
+employee
(1) the play operator binds a role to its player, and (2) the its employees without any manager information. We will use
unary + operator before a method call performs a dynamic this example to showcase our approach.
E4: E
dispatch to a suitable role played by the object. The ability
3.2 Concept salary: Dou
of roles to be attached and detached at runtime creates a firstName: S
natural mechanism of extensibility and adaptability, which The concept of RSUM is demonstrated for our Library- lastName: S
is used for our requirements to adapt the described view- Example in Figure 4. It is divided into a core part that
based approaches at runtime. In addition, Scala allows the is marked in a blue box in the lower part and into different
extension of the source model, the synchronization, and the views that are visualized in the upper part of the figure.
views by loading classes at runtime. These features enable The core contains central information and data structures
the runtime model consistency, as deeply explained in more which are modeled as natural types and relational compart-
detail in the next section. ments that represent the relational behavior of the RSUM.
In the RSUM approach all relations are transformed to re-
lational compartments, i.e., the manager and employees as-
3 ROLE-ORIENTED SINGLE UNDERLYING sociations are transformed to the ManagerOfEmployee and
MODEL (RSUM) LibraryHasEmployee compartments, because all relations
In this section, we describe the concept of an RSUM and between naturals except inheritance are not allowed in the
the advantages that we see in such a view-oriented approach. role concept. These relations must be moved into relation
For simplification, we only use the word view in the concept, compartments. The concept of relation compartments allows:
which can be seen as a runtime model from an underlying (1) Loading relations at runtime with class loader function-
source. Before that, we first present a running example not ality in programming languages like Scala and Java.
related to M@RT, but one that showcases our approach and (2) Extending naturals with new relations at runtime with
the important features related to different small views. the playing of roles in relational compartments.
MRT’18, October 2018, Copenhagen, Denmark C. Werner and U. Aßmann
Plays Relation OtherViews
OtherViews LibraryAndEmployeeView EmployeeAndManagerView
OtherViews
Relation 1 0..1
View 1 0..* 0..* 1
n..m
Library Has Employee Employee HasManager
1 0..*
Role Role cardinality
Compartment RsumManagement LibraryHasEmployee ManagerOfEmployee
n..m +createView(query)
Role 1 1 1 RoleGroup (1..1) 1
Extensions Source Target
Extensions Source Target
Natural Extensions
Extension
RoleGroup (n..m) …
n..m n..m RsumManager … Library employees manager
Employee Person
Role ... Role 0..1
+manage() name salary name
0..* RSUM
Figure 4: Concept of the role-oriented single underlying model (RSUM).
(3) Add behavior and states to relations as methods and RsumM:RsumManagement View
attributes in relational compartments. EaM: EaMView
(4) n-ary relations with more role types in the relational 2 E1:Employee 1
EM1:ManOfEmp
compartment. 3 name=Bob Er1: Employee
salary=60000
With these features, the relation compartments allow easy 4
T1: Target Rm1: RsumManager
runtime adaptation of the RSUM as underlying source. This 4 Mr1: HasManager
modification allows the construction of an RSUM from an 3
E2:Employee
object-oriented model with converting relations to relation S1: Source
name=Alice
4
compartments and the creation of views with elements that 5
Rm3: RsumManager salary=45000 Er2: Employee
3
can play roles in the views. Moreover, the RSUM consists of Rm2: RsumManager 1
an RsumManagement compartment, wherein each natural and
relational compartment plays an instance of the RsumManager
Figure 5: Instance view of RSUM from running example.
role type. In addition, it manages the instantiation of new
views because it holds references on all instances from the
RSUM and it adapts views at runtime. For clarity, only the
plays relations from Library and LibraryHasEmployee to played by naturals of the RSUM. All roles that do not have
the RsumManager are drawn. These roles manage changes a specific cardinality can be unlimited. The role group con-
between views by reacting on insert, delete, and modifica- straint with the cardinality (1..1) in the ManagerOfEmployee
tion operations of naturals and relational compartments in compartment describes that an employee cannot be their own
the core. Furthermore, they propagate changes to all active manager, because he or she can not play both roles at the
views. The management compartment may also contain sev- same time. In addition, each role in a view also requires an
eral Extensions to be added depending on the natural types associated object in the RSUM core. This can be a natural
and relation compartment types. These Extensions can im- or a relational compartment. The roles in the views also do
plement histories, versioning, logging, and many more to not contain any information, because data can be retrieved
observe user behavior and adaptation changes. and changed directly from the core using the internal map-
Two example views are represented in the upper part ping of the plays relation. However, the concept forces every
of Figure 4. The views are modeled as compartments with view with write access to know which naturals or relation
roles as the representations of the internal structure (e.g., compartments have to be created when creating roles in it.
the EmployeeAndManagerView presents only the manager re- In Figure 5, the instance model of the RSUM approach
lation). In EmployeeAndManagerView, each Employee role is and the creation process of the HasManager role (Mr1) are
played by a natural Employee and can have one HasManager visualized, whereby names from the concept are abbreviated
role outlining his or her manager and many HasManager roles for space reasons. The representation shows the core on the
representing the subordinated employees. The HasManager left and the EmployeeAndManagerView view on the right side.
role is played by the ManagerOfEmployee compartment. All Now, we show how to create an RSUM in six steps. For
relational compartments only contain a tuple of Source and creating Mr1, the Employee roles Er1 and Er2 are required:
Target role visualized with cardinality 1, i.e., the number (1) the players of these roles E1 and E2 are determined. The
of relational compartments is equivalent to the number of view checks whether these players are really instances in the
instances that form a relationship and the roles can only be RSUM. If this is the case, (2) a new ManagerOfEmployee
Model Synchronization with the Role-oriented Single Underlying Model MRT’18, October 2018, Copenhagen, Denmark
compartment is created, otherwise the process is stopped. Listing 1: Interface of relation compartment.
Within this, (3) new Source and Target roles are instantiated 1 trait I R e l a t i o n C o m p a r t m e n t extends Compartment {
and bound to the two naturals from (1). If it is determined 2 var source : ISource = null
that the role group property is not fulfilled, the process is 3 var target : ITarget = null
4
terminated. Otherwise, (4) establishes the play relation to the 5 def delete () : Unit = {
role in the view and sets the relationships to the Employee 6 if ( source ! = null ) {
roles. In (5), a new instance of the RsumManager role is bound, 7 plays . removePlayer ( source )
8 source = null
and if Extension roles exist for this type, these are bound 9 }
directly to the RsumManager role, but this process is not 10 if ( target ! = null ) {
11
shown in Figure 5. The last step (6) iterates over all active 12
plays . removePlayer ( target )
target = null
views and creates new roles in other views when necessary. 13 }
However, there is only one view that presents instances of 14 + this d e l e t e E v e r y t h in g ()
15 }
this relation compartment, i.e., this step does not create 16
more roles and bindings in this case and is not shown in 17 trait ISource extends IRelationRole {
Figure 5. Yet, this process shows the incremental runtime 18 def getTarget () : ITarget = I R e l a t i o n C o m p a r t m e n t .
this . target
updates process underlining RQ2, because it only creates 19 def delet eRelatio n () : Unit =
elements that are connected to the specific action and do not I R e l a t i o n C o m p a r t m e n t . this . delete ()
20
change other elements. 21
}
As presented in the RSUM concept and explanatory ex- 22 trait ITarget extends IRelationRole {
ample, the role approach offers a lot of features and benefits. 23 def getSource () : ISource = I R e l a t i o n C o m p a r t m e n t .
this . source
A natural has the ability to play arbitrarily many roles. This 24 def delet eRelatio n () : Unit =
ensures that naturals can play roles in all existing views, I R e l a t i o n C o m p a r t m e n t . this . delete ()
which do not limit the number of views. The role concept 25 }
26 }
also allows roles and compartments to play roles which is used
for the Extensions. The creation of deep views in view-based
approaches has not yet been considered in this paper, as it is
not relevant for model synchronization and is not shown in mechanism as extension compartment allows to monitor such
Figure 4. However, the property that roles themselves can changes. Our concept is based on materialized view types as
play roles, makes it easy to model and implement deep views. own models of compartments to instantiate views at runtime
The resulting layered architecture with deep roles makes no and provide views with a predefined structure. Furthermore,
sense on the small running example. in the role concept, each natural with all bound roles forms a
For implementing the concept, the runtime class loading compound object, which ensures that all roles reflect the same
options of programming languages are used to extend and object and no object schizophrenia occurs. This fundamental
adapt the approach in multiple directions, e.g., new naturals, mechanism allows to directly work on parts of the underlying
relation compartments, and views can be added to the RSUM instance without the usage of a communication layer to
at runtime. These elements only need the mechanism to propagate changes through multiple layers or objects. The
acquire and abandon roles to adapt the RSUM and to load whole concept presents the synchronization of views from a
and create new views at runtime (RQ1). In addition, it is single underlying source. However, if we create a combined
possible to create read-only views, which only allow access to model from preexisting models, where redundant information
information with get functionality without the opportunity is removed, we can depict preexisting models as views from
to change the internal state with set functionality. Removing the RSUM. This results in a synchronization approach, which
views also just means removing roles and does not affect the is able to generate new views/models and integrate new or
RSUM core. In contrast, the deletion of elements in the views existing legacy models.
is propagated into the core and removes their core natural However, the concept presented in this section also has
and all bound roles. The insertion process does the opposite: some shortcomings. For each pair of elements involved in a
It creates and binds new management, extension, and view relation, a new relation compartment is required which leads
roles in the core and the active views to the new elements to an immense amount of compartments. It must also be
on the fly. This mechanism is another necessary part for ensured that the players of the Source and Target roles in
incremental updates of the RSUM core at runtime because the relation compartments match the players of the bound
it connects the views to the RSUM and thus also the views role in a view, which must be guaranteed at runtime.
among each other (basis for RQ2).
The roles within the views have no copied data from the 3.3 SCROLL Implementation
RSUM and access the information of the naturals via the For our case study, we use SCROLL [25] to prototypically
plays relation. This ensures that no redundant information is implement the RSUM approach of the running example in-
kept at runtime and that the status of the RSUM is consistent troduced in Section 3.1.
(underpins RQ2). If an attribute is changed simultaneously In SCROLL, each compartment object contains a role
in two views, the last propagated change remains. A history graph called plays that handles the calling of the role’s
MRT’18, October 2018, Copenhagen, Denmark C. Werner and U. Aßmann
Listing 2: Example of relation compartment. Listing 3: Class example of RSUM.
1 class E mp l oy ee H a s M a n a g e r ( emp : Employee , man : Employee ) 1 class Library ( _name : String ) {
extends I R e l a t i o n C o m p a r t m e n t { 2 private var name : String = _name
2 this . source = new Source () 3 def getName () : String = name
3 this . target = new Target () 4 def setName ( n : String ) : Unit = {
4 emp play this . source 5 name = n
5 man play this . target 6 }
6 def behavior () : Unit = { ... } 7}
7 class Source () extends ISource { ... }
8 class Target () extends ITarget { ... }
9}
Listing 4: Example role in view.
1 class LibraryRole ( name : String ) extends IViewRole {
2 /* Role s p e c i f i c f u n c t i o n a l i t y . */
methods and allows insertion and removal of nodes and 3 def getNameView () : String = {
4 return + this getName ()
edges. This option makes function calls compartment-specific, 5 }
i.e., compartments do not allow other compartments to call 6 def setNameView ( name : String ) : Unit = {
7 + this setName ( name )
internal role behavior. For our approach, we combine the 8 + this changeTrigger ()
role graphs to one that enables us to call all available role 9 }
methods with the unary + operator in front of a method 10 }
name. These combine commands are not presented in the
listings but are imperative for the correct implementation
of the RSUM. Moreover, SCROLL permits the execution and setters to access the name. These methods are used by
of more than one role method per API call, i.e., when an all played roles to change the state of the object.
instance plays more than one role of one type, a call of a After the RSUM has been created, views must be defined
role’s method is successively executed for all bound roles. to reproduce the filtered content. Each view type is given a
This function is crucial for instances of the RsumManager, unique name to distinguish it from other types. Further, all
because changes in the RSUM core must be propagated to interfaces, no matter whether they are views or extensions,
all extensions and views. have the getRole method that returns a corresponding role
To apply the RSUM approach to an object-oriented model, for a class. With this method each view knows what instances
the object-oriented model must first be transferred to a core it represents and what roles these instances get in the view.
model as shown in Figure 4. Therefore, all relations must be If some elements are not presented in the view, this method
expressed as relation compartments. does not return any role instance. In addition, this method
Listing 1 shows the interface of a relational compartment must be unique, which means that it can not be possible for a
that has to be implemented. The interface defines the Source class to receive several types of roles, or for one role type to be
and Target roles and a function to delete the compartments. returned for several classes. This mechanism allows creating
In the delete method (Lines 5 to 15), the roles are deleted only one associated object in the core, when instantiating roles
from the role graph (Lines 7 and 11) and all bound roles of in a view. Furthermore, each view compartment contains a list
the compartment will be deleted in the deleteEverything of roles that includes all roles played in this compartment
method. This function uses the + operator to call a function instance. This list is used to prevent duplicate instantiations.
defined in another connected role or in the player object. Listing 4 shows an example role from a view that can
In this case, the deleteEverything method is implemented be played by the natural Library in Listing 3. Each view
in the RsumManager role, which must be played by every role inherits from the IViewRole interface for correct view
instance in the core and is explained later in this section. management. In addition, the listing shows how data of
These internal roles only manage access to related roles and players is accessed (Line 4) and changed (Line 6 to 9). Both
forward delete functions to the compartment. This step is functions require the + operator to call a function defined in
necessary because once a natural is deleted in the RSUM, all another connected role or in the player object (e.g., setName
relationships of that element must also be deleted. and getName are passed to the Library). The changeTrigger
In Listing 2, the EmployeeHasManager relation compart- method is implemented in the RsumManager role and activates
ment is shown that must inherit from the interface of List- all Extension roles bound to this object once there. If the
ing 1. It gets the associated naturals during creation and views should react to changes of instances, this mechanism
assigns them to new roles (Line 2 to 5). This ensures that the can be used to update visualizations in views. Furthermore,
structures at instance level are always bound correctly. The view roles still have delete functions which are not specified
behavior method should show that each relation compart- in the listing. These functions trigger a cascade of changes in
ment can have its own behavior and state to extend relations the core model and delete all connected roles and relational
with new information. compartments if necessary. If a view is created as read-only
To transfer the normal classes to the RSUM, hardly any view, all delete and insert operations will not be generated in
adjustments have to be made except for deleting the rela- the later view generation process. Without these functions,
tionship attributes. Listing 3 shows the Library with getters it is not possible to manipulate elements in the RSUM.
Model Synchronization with the Role-oriented Single Underlying Model MRT’18, October 2018, Copenhagen, Denmark
Listing 5: Excerpt from the management compartment. someone is currently working. The createView algorithm is
1 object RsumManagemen t extends M u l t i C o m p a r t m e nt {
not shown in Listing 5 but works as follows: (1) iterating
2 p r o t e c t e d var extensions = ListBuffer [..]() over all relation compartments and binding them to roles
3 p r o t e c t e d var activeViews = ListBuffer [..]() returned from the view, and (2) iterating over all naturals to
4 p r o t e c t e d var allViews = ListBuffer [..]()
5 p r o t e c t e d var allRelations = ListBuffer [..]() create and binding the last roles to the view. In the views,
6 p r o t e c t e d var allNaturals = ListBuffer [..]() the links of the players of the Source and Target roles are
7 /* Insertion , creation , and d e l e t i o n of views */ created simultaneously, if they do not yet exist. In this pro-
8
9 class RsumManager () { cess, the main part of the calculations takes place in the
10 def manageRsum ( input : Object ) : Unit = { views. Furthermore, the management compartment contains
11 if ( input . isInstanceOf [ I R e l a t i o n C o m p a r t m e n t ])
{
all RsumManager roles (Line 9), which coordinate the deletion
12 allRelations = allRelations :+ input and insertion. The manageRsum method in the RsumManager
13 /* Combine c o m p a r t m e n t s here . */ role is called as soon as a new core element is created, which
14 } else {
15 allNaturals = allNaturals :+ input is passed to the function as an input and processed as follows:
16 }
17 extensions . foreach { e = > (1) The new element is inserted into the corresponding list
18 var role : IExten sionRole = e . and if it is a relation compartment, the role graphs will
19
get E x t e n s i o n Ro l e ( input )
if ( role ! = null )
be combined (Line 11 to 15).
20 input play role (2) Matching Extension roles from the respective Exten-
21 } sion compartments are bound (Line 17 to 21).
22 activeViews . foreach { v = >
23 var role : IViewRole = v . getViewRole ( input ) (3) Suitable roles are created and bound in all active views
24 if ( role ! = null ) (Line 22 to 26).
25 input play role
26 } However, as soon as a delete operation is called, the delete-
27 }
28 Everything method is triggered. First, the player of the role
29 def deleteE v e r y t h i ng () : Unit = { (Line 30) and all associated roles (Line 31) are determined.
30 var player = this . getPlayer () Then the player is removed from the appropriate list in the
31 var roles = plays . getRoles ( player )
32 /* Remove player from list */ management compartment and the function iterates over all
33 roles . foreach { r = > roles to delete them from the graph (Line 29 to 42). For
34
35
plays . removePlayer ( r )
if ( r . isInstanceOf [ IViewRole ])
different role types, individual delete operators are called,
36 r . removeRole () which are only defined within these roles to guarantee the
37 else if ( r . isInstanceOf [ IRelationRole ]) error-free deletion from compartments.
38 r . deleteRe lation ()
39 else For the example implementation, we also wrote an exten-
40 r . deleteNatural () sion compartment, which saves every change of a natural and
41 } thus creates a history. As soon as a change is made, a copy
42 }
43 of all values is stored in a list. This extension can be used
44 def changeTrigger () : Unit = { as a basis for a versioning module to reload older versions
45
46 }
+ this runExtension ()
of the RSUM. This scenario is of interest for a distributed
47 } development scenario, in which changes can be traced and
48 } older states can be used.
All these functionalities are necessary to ensure the incre-
mental updating of views at runtime and to avoid redundant
data, which underlines our research question (RQ2) and pro-
The code example in Listing 5 represents the management vides a foundation for further developments. In addition, the
object. This inherits, in comparison to all other compart- role concept that SCROLL offers is the foundation for an
ments, from the MultiCompartment which allows the con- understandable and easily usable way to create views at de-
secutive execution of several role behaviors with identical sign and runtime (RQ1). The limitations of this approach are
declaration and not only the execution of the first discov- discussed in the section before. Moreover, the current state is
ered role method. This option is currently only needed by a hand written implementation to show the applicability of
the changeTrigger method in the RsumManager role (Line 44 the concept, but in the future the code should be generated
to 46). This role sends the information about changes to from a domain specific language for view specification.
all extension roles of the object as explained before. The
extension roles react to this information in various ways
(e.g., saving the change or modify some other elements). Fur- 4 RELATED WORK
thermore, the RsumManagement object manages active views, The RSUM approach described in this paper connects the
integrated views, extensions, naturals, and relations (Line 2 research areas: single underlying model, view-based software
to 6). An integrated view can be activated at any time, which development, databases, and role-based modeling. Each topic
inserts a new instance in the list of active views. The ac- has its own background and related literature. We only refer
tive views describe instances of known view types in which to the work not yet mentioned in Section 2.
MRT’18, October 2018, Copenhagen, Denmark C. Werner and U. Aßmann
In the M@RT area there are already some approaches the only approach that does not have object schizophrenia.
that deal with the synchronization of runtime models with OSM [3] was already mentioned in Section 1 and provides all
their running model. The MORSE [16] approach is a model- requirements except deep views, which are not mentioned in
aware service environment consisting of a model repository their publications and they have object schizophrenia. They
and model-aware services interacting with the repository. use the delta-based lens approach by Diskin et al. [11] to
The repository manages model projects and artifacts that create an incremental, intermediate, and bidirectional update
are equipped with universal unique identifiers for differentia- mechanism for the SUM. All approaches except vVTGG [18]
tion. The approach addresses traceability and collaboration are object schizophrenic, because the most approaches work
problems between models and takes over versioning of arti- on new model instances and not directly on the base model
facts. Attached services interact with the model repository at (e.g., EMF Profiles, Epsilon Decoration, and mVTGG). Other
runtime and retrieve elements. MORSE includes managing approaches create virtual views with traceability information
models and their versions at runtime with external access. between view and base model but also do not directly work
The SM@RT tool [26] is a synchronization tool between the on the base model and must propagate their updates across
running model and a MOF-compliant. The developer defines the traceability links (e.g., OSM, OpenFlexo, and VIATRA
how elements are managed and manipulated in the tool. For viewers). VTGGs [18] [1] are a more dedicated form of Triple
this step, the target system must provide a management API. Graph Grammars (TGGs), in which it is not possible to
Each synchronization must be triggered before and after read- invert the source and target model. VTGGs are presented in
ing and writing the model. Moreover, the tool consists of a two publications. In [1], mVTGG are implemented with an
common library and a code generation engine, which together object adapter pattern, whereas [18] presents vVTGGs using
build the synchronization and thus offer the automatic genera- the class adapter pattern, the use of which permits to remove
tion of synchronization engines. These map a running system object schizophrenia. Moreover, TGGs save the traceability
to model-based views, which represent completely separate information between two models in the correspondence graph
models. In the work of Vogel et al. [27], runtime models are and in doing so allow immediate and bidirectional updates
generated from the running system by triple graph grammars between underlying source and view. In addition, the two
(TTG). These runtime models reflect various properties of the approaches allow deep views while mVTGGs are based on a
running system and are updated incrementally at runtime. In formal spezification and vVTGGs are not. Another approach
this approach, the runtime models are completely separated is EMF Profiles [24] which transforms the profile mechanism
to avoid manipulating results. A notification mechanism re- from UML to EMF. This is done by extending EMF models
ports changes from the source model to the target model. In with profiles to create a reusable mechanism in EMF and
addition, the approach can be extended by writing new TTG benefit from the UML profiles standard. The profiles are
rules. As an example, performance, architecture, and failure persisted as separate materialized models which can be called
models are generated, but in comparison to our approach viewpoint over a single metamodel with the objective to ex-
they separate runtime models from the running model. tend it with annotations on existing elements. In addition,
Since the beginning of the view-based software develop- they are a dynamic model extension and do not pollute the
ment research, different model view approaches have been base model. Their publication does not mention deep views,
created and examined regarding their usefulness during the however we think it is possible to integrate them. The Epsilon
software development process. Bruneliere et al. [6] present a Decoration [20] approach has model decoration support to
survey about model view approaches with a feature model create annotations of models to add new information. The
and sum up the view terminology and thereby also use the decorations are represented in a generic way and the whole
terminology from Goldschmidt et al. [12]. They identify 16 approach is implemented on top of Epsilon. They provide
approaches that meet their requirements, i.e., software is generic model handling functionalities like loading, storing,
based on MOF, defines view types, and computes conform- querying, and updating which are directly inspired by rela-
ing views. In their conclusion, problems of model view ap- tional databases. The decorated models behave like views on
proaches are named, such as inconsistent terminology, view the original model with new manually added information but
update problems, incremental view management, concrete they save their modification in separated decorator models
syntax generation, and security aspects. Our approach ad- and not directly in the original model. The authors do not
dresses two of these problems: the view update problem, and mention deep views in their publication but it should be pos-
incremental view management (with the RsumManagement sible to create them with decorator chains. OpenFlexo [13]
compartment). Furthermore, the role concept provides a supports the federation of data from homogeneous techni-
natural way to encapsulate information. We consider the cal spaces into virtual views, wherein no duplicated data is
approaches with bidirectional, incremental, and immediate produced. The complete step is done with a DSL creating
updates in Table 1: EMF Profiles [24], mVTGG [1], Epsilon the views while an underlying model federation framework
Decoration [20], OSM [3], OpenFlexo [13], and VIATRA view- allows homogeneous handling of data as models. Each view
ers [10]. As additional criteria, we analyze the utilization of is connected to its base models, but it is also possible to
virtual views, the possibility to create deep views and the connect the different base models to the view resulting in a
occurrence of object schizophrenia. vVTGG [18] is the only synchronization mechanism between the base models across
approach without incremental updates in Table 1, but it is the view. These bindings allow incremental, immediate, and
Model Synchronization with the Role-oriented Single Underlying Model MRT’18, October 2018, Copenhagen, Denmark
Table 1: Comparison with State-of-the-Art.
Epsilon Decoration
VIATRA viewers
EMF Profiles
OpenFlexo
DOREEN
2006 [18]
2012 [24]
2010 [20]
2016 [13]
2014 [10]
mVTGG
vVTGG
2014 [1]
2010 [3]
2017 [4]
RSUM
OSM
Bidirectional updates ■ ■ ■ ■ ■ ■ ■ ■ ■
Immediate updates ■ ■ ■ ■ ■ ■ ■ ■ ■
Incremental updates □ ■ ■ ■ ■ ■ ■ ■ ■
Virtual views ■ □ □ □ ■ ■ ■ ■ ■
Deep views ■ ∅ ■ ∅ □ □ □ ■ ■
No object schizophrenia ■ □ □ □ □ □ □ □ ■
■: yes, □: no, ∅: not applicable
bidirectional updates, but is not suitable for deep views. VI- criteria to satisfy the update translations in the simplest
ATRA Viewer [10] has emerged from EMF IncQuery and form, such as no database side effects, minimal changes, and
provides an efficient incremental view management technique no unnecessary changes. But, after 40 years of research, an
based on graph transformations. It uses derivation rules that easy and powerful solution is still missing.
are defined with annotation on query patterns form EMF In Section 2, we briefly described role models, their proper-
IncQuery. Moreover, trace models are used between the base ties, and SCROLL. For our realization, we use SCROLL as a
models and the views to reason about changes and provide role-based programming language but there are other options
synchronization support. Besides, it offers a way to serialize to implement the features of roles. The Role Object Pattern
and reuse views and thereby, produces materialized view (ROP) [5] allows unanticipated changes at runtime. This flex-
types with virtual and deep views as view chains. ible design pattern extends a core object to dynamically add
The DOREEN approach [4] is a new deep view-point lan- and remove functionality in the form of new objects. The use
guage similar to and with the same properties as OSM that of the ROP creates a lot of design overhead and does not
uses the deep modeling technology for views and SUM. They allow the use of contexts. In contrast to ROP, SCROLL [25]
use projective views of the SUM, which are completely de- and Object Teams/Java (OT) [14] are both role-based pro-
fined by their content and its visualization. DOREEN is gramming languages covering most of the 26 role features [23].
a component-centric view approach and uses the compos- OT adds cross-cutting concerns to an existing application,
ite pattern to increase conceptual simplicity and flexibility whereby software composition and aspect-orientation play
and therefore has advantages in scalability, focusability, and the central role. In OT, teams are compound objects similar
customizability. For model synchronization tasks between to compartment types and contain all participating roles. The
SUM and views, round-trip engineering (RTE) strategies are players are called base objects and play roles in the teams.
needed. Hettel et al. [15] introduce definitions for RTE. For Furthermore, roles add methods that can be called from the
the transformation between two models, they distinguish be- base class or forward information to the base class.
tween the relevant and non-relevant part of the two models.
If there are changes in the relevant part of model A, then 5 CONCLUSION AND FUTURE WORK
model B must be changed, too. Changes in the non-relevant
In this paper, we have described the advantages of using the
part have no consequences in other model which is important
role concept as the foundation to realize a SUM-based soft-
for incremental updates. Furthermore, model transformations
ware engineering environment called the RSUM approach to
languages like ATL, QVT, and TGG are used to transform
synchronize models as views over an underlying source. The
models in RTE systems.
approach provides incremental runtime updates in views, and
In view-based software development, the views from a
runtime integration of new views. In addition, it introduces
SUM need to be updated over time. This problem is closely
a runtime adaptation mechanism in the view and the under-
related to the View Update Problem in relational databases.
lying source level without redundant data, whereby views
In the year 1978, Dayal [9] defined specific criteria that need
work on compound objects removing object schizophrenia.
to be satisfied by an updatable view to avoid any side effects.
Moreover, the role concept provides contextual, behavioral,
An updatable view behaves exactly like a standard table in
and relational properties that are used for modeling relational
a standard database. Therefore, Keller et al. [19] proposed
compartments and views to separate concerns in views. The
an interactive view definition mechanism and introduced
usability of SUM-based software engineering depends on both,
MRT’18, October 2018, Copenhagen, Denmark C. Werner and U. Aßmann
flexibility and stability. Flexibility means to add new types of [12] Thomas Goldschmidt, Steffen Becker, and Erik Burger. 2012.
views and models over time, whereas stability means to have Towards a Tool-Oriented Taxonomy of View-Based Modelling. In
Modellierung 2012 (GI-Edition – Lecture Notes in Informatics),
fixed and stable metamodels, to support standards, and to Vol. P-201. Gesellschaft für Informatik e.V. (GI), Bonn, 59–74.
have tool interoperability. The role concept and the related [13] Fahad R. Golra, Antoine Beugnard, Fabien Dagnat, Sylvain
Guerin, and Christophe Guychard. 2016. Addressing Modularity
tools like SCROLL are research prototypes. This reduces the for Heterogeneous Multi-model Systems Using Model Federation.
overall tool support and stability of the RSUM approach. In Companion Proceedings of the 15th International Conference
In future work, we need strategies to integrate legacy mod- on Modularity. ACM, 206–211.
[14] Stephan Herrmann. 2003. Object Teams: Improving Modularity
els into the RSUM. To achieve this, we work on a role-based for Crosscutting Collaborations. Springer Berlin Heidelberg,
model synchronization and transformation approach to use a 248–264.
uniform modeling and programming language for the whole [15] Thomas Hettel, Michael Lawley, and Kerry Raymond. 2008.
Model Synchronisation: Definitions for Round-Trip Engineer-
process. In addition, we want to provide DSLs to generate ing. Springer Berlin Heidelberg, 31–45. https://doi.org/10.1007/
views and view types without the currently hand-written 978-3-540-69927-9_3
[16] T. Holmes, U. Zdun, and S. Dustdar. 2009. MORSE: A Model-
implementation overhead. This DSLs should allow filter op- Aware service environment. In 2009 IEEE Asia-Pacific Services
erations over the naturals and relational compartments to Computing Conference (APSCC). 470–477. https://doi.org/10.
present only parts of all instances. 1109/APSCC.2009.5394083
[17] May ISO. 2011. Systems and software engineering–architecture
description. Technical Report. ISO/IEC/IEEE 42010.
ACKNOWLEDGMENTS [18] Johannes Jakob, Alexander Königs, and Andy Schürr. 2006. Non-
materialized Model View Specification with Triple Graph Gram-
This work has been funded by the German Research Founda- mars. In Graph Transformations. Springer Berlin Heidelberg,
tion within the Research Training Group "Role-based Soft- 321–335.
ware Infrastructures for continuous-context-sensitive Systems" [19] Arthur M. Keller. 1985. Algorithms for Translating View Updates
to Database Updates for Views Involving Selections, Projections,
(GRK 1907). and Joins. In 4th ACM SIGACT-SIGMOD Symposium on Prin-
ciples of Database Systems (PODS ’85). ACM, USA, 154–163.
https://doi.org/10.1145/325405.325423
REFERENCES [20] Dimitrios S. Kolovos, Louis M. Rose, Nikolaos Drivalos Matragkas,
[1] Anthony Anjorin, Sebastian Rose, Frederik Deckwerth, and Andy Richard F. Paige, Fiona A. C. Polack, and Kiran J. Fernandes.
Schürr. 2014. Efficient Model Synchronization with View Triple 2010. Constructing and Navigating Non-invasive Model Dec-
Graph Grammars. In Modelling Foundations and Applications. orations. In Theory and Practice of Model Transformations.
Springer International Publishing, Cham, 1–17. Springer Berlin Heidelberg, 138–152.
[2] Colin Atkinson, Ralph Gerbig, and Christian Tunjic. 2013. A [21] Max E. Kramer, Erik Burger, and Michael Langhammer. 2013.
Multi-level Modeling Environment for SUM-based Software Engi- View-centric Engineering with Synchronized Heterogeneous Mod-
neering. In 1st Workshop on View-Based, Aspect-Oriented and els. In 1st Workshop on View-Based, Aspect-Oriented and Or-
Orthographic Software Modelling (VAO ’13). ACM, USA, 2:1–2:9. thographic Software Modelling (VAO ’13). ACM, USA, 5:1–5:6.
https://doi.org/10.1145/2489861.2489868 https://doi.org/10.1145/2489861.2489864
[3] Colin Atkinson, Dietmar Stoll, and Philipp Bostan. 2010. Ortho- [22] Thomas Kühn, Stephan Böhme, Sebastian Götz, and Uwe Aß-
graphic Software Modeling: A Practical Approach to View-Based mann. 2015. A Combined Formal Model for Relational Context-
Development. In Communications in Computer and Information dependent Roles. In 2015 ACM SIGPLAN International Con-
Science. Springer Science & Business Media, 206–219. ference on Software Language Engineering (SLE 2015). ACM,
[4] Colin Atkinson and Christian Tunjic. 2017. A Deep View-Point USA, 113–124. https://doi.org/10.1145/2814251.2814255
Language for Projective Modeling. In 21st International Enter- [23] Thomas Kühn, Max Leuthäuser, Sebastian Götz, Christoph
prise Distributed Object Computing Conference (EDOC). IEEE, Seidl, and Uwe Aßmann. 2014. A Metamodel Family for Role-
133–142. https://doi.org/10.1109/EDOC.2017.26 Based Modeling and Programming Languages. Springer Inter-
[5] Dirk Bäumer, Dirk Riehle, Wolf Siberski, and Martina Wulf. 1998. national Publishing, Cham, 141–160. https://doi.org/10.1007/
The Role Object Pattern. In Washington University Dept. of 978-3-319-11245-9_8
Computer Science. [24] Philip Langer, Konrad Wieland, Manuel Wimmer, Jordi Cabot,
[6] Hugo Bruneliere, Erik Burger, Jordi Cabot, and Manuel Wimmer. et al. 2012. EMF Profiles: A Lightweight Extension Approach for
2017. A feature-based survey of model view approaches. Software EMF Models. Journal of Object Technology 11, 1 (2012), 1–29.
& Systems Modeling (2017), 1–22. https://doi.org/10.1007/ [25] Max Leuthäuser and Uwe Aßmann. 2015. Enabling View-based
s10270-017-0622-9 Programming with SCROLL: Using Roles and Dynamic Dis-
[7] Erik Burger. 2013. Flexible Views for Rapid Model-driven De- patch for Etablishing View-based Programming. In 2015 Joint
velopment. In 1st Workshop on View-Based, Aspect-Oriented MORSE/VAO Workshop on Model-Driven Robot Software En-
and Orthographic Software Modelling (VAO ’13). ACM, USA, gineering and View-based Software-Engineering. ACM, USA,
1:1–1:5. https://doi.org/10.1145/2489861.2489863 25–33.
[8] Erik Burger, Jörg Henss, Martin Küster, Steffen Kruse, and Lucia [26] Hui Song, Yingfei Xiong, Franck Chauvel, Gang Huang, Zhenjiang
Happe. 2016. View-based model-driven software development with Hu, and Hong Mei. 2010. Generating Synchronization Engines
ModelJoin. Software & Systems Modeling 15, 2 (2016), 473–496. between Running Systems and Their Model-Based Views. In
https://doi.org/10.1007/s10270-014-0413-5 Models in Software Engineering. Springer Berlin Heidelberg, 140–
[9] Umeshwar Dayal and Philip A. Bernstein. 1978. On the updata- 154.
bility of relational views. In 4th international conference on Very [27] Thomas Vogel, Stefan Neumann, Stephan Hildebrandt, Holger
Large Data Bases - Volume 4. VLDB Endowment, 368–377. Giese, and Basil Becker. 2010. Incremental Model Synchroniza-
[10] Csaba Debreceni, Ákos Horváth, Ábel Hegedüs, Zoltán Ujhe- tion for Efficient Run-Time Monitoring. In Models in Software
lyi, István Ráth, and Dániel Varró. 2014. Query-driven In- Engineering. Springer Berlin Heidelberg, 124–139.
cremental Synchronization of View Models. In 2nd Workshop
on View-Based, Aspect-Oriented and Orthographic Software
Modelling. ACM, USA, 31:31–31:38. https://doi.org/10.1145/
2631675.2631677
[11] Zinovy Diskin, Yingfei Xiong, Krzysztof Czarnecki, Hartmut Ehrig,
Frank Hermann, and Fernando Orejas. 2011. From State- to Delta-
Based Bidirectional Model Transformations: The Symmetric
Case. Springer Berlin Heidelberg, 304–318. https://doi.org/10.
1007/978-3-642-24485-8_22