Models@runtime (M@RT) sufer from information fragmentation across heterogeneous runtime models conforming to several metamodels that are filled with information from a source model. This creates an amount of related models with replicated information. In contrast, a recent approach to software engineering utilizes Single Underlying Model (SUM) to generate views of a software system on demand. The views represent fragments specifying required information for model instances. This results in an increasingly complex source model which is consistent from scratch and views with relations between each other that require complex processes to maintain consistency. Thus, to hold the views and models consistent at runtime, an intuitive approach for the creation of an adaptable SUM should be introduced that permits runtime synchronization and adaptation of views. We propose utilizing the concept of roles in the domain of SUM-based software engineering and M@RT. Based on existing work in the area of role modeling, we present a Role-oriented Single Underlying Model approach that provides a natural way to create views from a running model. We show how the role concept simplifies the creation of runtime models as views from a SUM, provide an incremental view update approach, and introduce a flexible adaptation mechanism. Finally, we illustrate our approach with two example views to explain the benefits of a role-oriented SUM.
• Software and its engineering → Software development methods; Development frameworks and environments; Software development techniques; Software design engineering; Model-driven engineering, single underlying model, role-oriented programming. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s).
MRT’18, October 2018, Copenhagen, Denmark © 2018 Copyright held by the owner/author(s).
Since the 1980s, the software engineering community has realized that there is no silver bullet to solve the complexities of software processes and model-dependent tasks. Ensuring the consistency of information fragments, while the system is running, is an essential aspect in the area of Models@runtime (M@RT) and Model Driven Engineering (MDE). Consistency between two models is defined as follows: Two models are consistent if their combination does not generate any contradictions and is realizable with implementation efort. Consistency makes maintaining artifacts a grand challenge. Without much work on maintainability of software elements, the quality inevitably degrades over time and with it the quality of the final product.
In the area of M@RT, it is necessary to create new runtime
models as architecture, performance, and failure models from
a running system on the fly [
The Single Underlying Model (SUM) approach by
Atkinson et al. [
This paper transforms the SUM approach from design
time to runtime to make it usable in the area of M@RT for
the synchronization of runtime models as views of the
underlying source. We use the Compartment Role Object Model
(CROM) by Kühn et al. [
The contribution of this paper is the Role-oriented Single
Underlying Model (RSUM) approach using the role
concept to create a SUM which is an integrated synchronization
mechanism for views. The concept improves creation of views,
introduces runtime adaptation, runtime synchronization
between SUM and views, and reduces redundant information.
Furthermore, the RSUM is prototypically implemented in the
SCala ROLes Language (SCROLL) [
The remainder of this paper is structured as follows. The next section summarizes background knowledge about closely related topics. Section 3 provides an in-depth discussion of the concepts with an illustrative example and its implementation details. We demarcate our approach from related work in Section 4. Finally, in Section 5, we conclude the paper and discuss lines of future work. 2
This section introduces the single underlying model approach, the view-based software development, and the role concept, 1https://github.com/chrissi007/RoleSUM which we combine in the next sections to our Role-oriented SUM approach. 2.1
As mentioned before, SUM [
In the view-based software engineering area, views manage
access to information from the models, as described in the
section before. The views handle the complexity of the overall
system and allow the separation of concerns in views. The
IEEE 1471/ISO 42010 standard [
The role concept is an extension of object-oriented design
considering objects and classes as naturals (instances of
natural types) that can play roles (instances of role types) in a
specific compartment (instance of compartment type). Roles
represent the behavior of naturals and can be acquired or
abandoned multiple times. Moreover, roles interact with each
other within compartments. Compartments represent
containers or contexts and separate concerns. An advantage is
that two naturals of the same type can have completely
different behavior at runtime because of diferently played roles.
The role concept we consider is based on CROM [
In this section, we describe the concept of an RSUM and the advantages that we see in such a view-oriented approach. For simplification, we only use the word view in the concept, which can be seen as a runtime model from an underlying source. Before that, we first present a running example not related to M@RT, but one that showcases our approach and the important features related to diferent small views. iLbray
L1: Libray +name:
tSring anme = "CityLb"
E2: Employe anme = "Bob" aslry = 60000 meploy amnger +employs meploy 0..* +name:
tSring +salry:
Double mEploye ePrson
E1: Employe anme = "Alice" model, a library L1 with the L2n:aLibrayme CityLib exists thmeploy at has two employees called Alice and Bob where Bob is the manager of Alice. This example anme: can"bCity eLibray"split into diferent views. One tSring = view can contain the complete information from the instance model while another view only includes all employees with their manager and a third view only provides the library with its employees without any manager information. We will use +employ this example to showcase our approach. 3.2
The concept of RSUM is demonstrated for our LibraryExample in Figure 4. It is divided into a core part that is marked in a blue box in the lower part and into diferent views that are visualized in the upper part of the figure. The core contains central information and data structures which are modeled as natural types and relational compartments that represent the relational behavior of the RSUM. In the RSUM approach all relations are transformed to relational compartments, i.e., the manager and employees associations are transformed to the ManagerOfEmployee and LibraryHasEmployee compartments, because all relations between naturals except inheritance are not allowed in the role concept. These relations must be moved into relation compartments. The concept of relation compartments allows: (1) Loading relations at runtime with class loader functionality in programming languages like Scala and Java. (2) Extending naturals with new relations at runtime with the playing of roles in relational compartments. aslry: ifrstName: alstNme: aslry: ifrstName: alstNme:
E3: Employe Double = 45.0 tSring = "Bil" tSring = "Smith"
E4: Employe Double = 60.0 tSring = "Bob" tSring = "Jones" n..m Role
Plays Relation (3) Add behavior and states to relations as methods and attributes in relational compartments. (4) n-ary relations with more role types in the relational compartment.
With these features, the relation compartments allow easy runtime adaptation of the RSUM as underlying source. This modification allows the construction of an RSUM from an object-oriented model with converting relations to relation compartments and the creation of views with elements that can play roles in the views. Moreover, the RSUM consists of an RsumManagement compartment, wherein each natural and relational compartment plays an instance of the RsumManager 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 the RsumManager are drawn. These roles manage changes between views by reacting on insert, delete, and modification operations of naturals and relational compartments in the core. Furthermore, they propagate changes to all active views. The management compartment may also contain several Extensions to be added depending on the natural types and relation compartment types. These Extensions can implement histories, versioning, logging, and many more to observe user behavior and adaptation changes.
Two example views are represented in the upper part of Figure 4. The views are modeled as compartments with roles as the representations of the internal structure (e.g., the EmployeeAndManagerView presents only the manager relation). In EmployeeAndManagerView, each Employee role is played by a natural Employee and can have one HasManager role outlining his or her manager and many HasManager roles representing the subordinated employees. The HasManager role is played by the ManagerOfEmployee compartment. All relational compartments only contain a tuple of Source and Target role visualized with cardinality 1, i.e., the number of relational compartments is equivalent to the number of instances that form a relationship and the roles can only be RsumM:RsumManagement 2 5
EM1:ManOfEmp 3
T1: Target
S1: Source Rm3: RsumManager 3 4 3
E1:Employee name=Bob salary=60000 Rm1: RsumManager
E2:Employee name=Alice salary=45000 Rm2: RsumManager 1 1
View EaM: EaMView
Er1: Employee Mr1: HasManager 4 4 Er2: Employee played by naturals of the RSUM. All roles that do not have a specific cardinality can be unlimited. The role group constraint with the cardinality (1..1) in the ManagerOfEmployee compartment describes that an employee cannot be their own manager, because he or she can not play both roles at the same time. In addition, each role in a view also requires an associated object in the RSUM core. This can be a natural or a relational compartment. The roles in the views also do not contain any information, because data can be retrieved and changed directly from the core using the internal mapping of the plays relation. However, the concept forces every view with write access to know which naturals or relation compartments have to be created when creating roles in it.
In Figure 5, the instance model of the RSUM approach and the creation process of the HasManager role (Mr1) are visualized, whereby names from the concept are abbreviated for space reasons. The representation shows the core on the left and the EmployeeAndManagerView view on the right side.
Now, we show how to create an RSUM in six steps. For creating Mr1, the Employee roles Er1 and Er2 are required: (1) the players of these roles E1 and E2 are determined. The view checks whether these players are really instances in the RSUM. If this is the case, (2) a new ManagerOfEmployee compartment is created, otherwise the process is stopped. Within this, (3) new Source and Target roles are instantiated and bound to the two naturals from (1). If it is determined that the role group property is not fulfilled, the process is terminated. Otherwise, (4) establishes the play relation to the role in the view and sets the relationships to the Employee roles. In (5), a new instance of the RsumManager role is bound, and if Extension roles exist for this type, these are bound directly to the RsumManager role, but this process is not shown in Figure 5. The last step (6) iterates over all active views and creates new roles in other views when necessary. However, there is only one view that presents instances of this relation compartment, i.e., this step does not create more roles and bindings in this case and is not shown in Figure 5. Yet, this process shows the incremental runtime updates process underlining RQ2, because it only creates elements that are connected to the specific action and do not change other elements.
As presented in the RSUM concept and explanatory example, the role approach ofers a lot of features and benefits. A natural has the ability to play arbitrarily many roles. This ensures that naturals can play roles in all existing views, which do not limit the number of views. The role concept 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 Figure 4. However, the property that roles themselves can play roles, makes it easy to model and implement deep views. The resulting layered architecture with deep roles makes no sense on the small running example.
For implementing the concept, the runtime class loading options of programming languages are used to extend and adapt the approach in multiple directions, e.g., new naturals, relation compartments, and views can be added to the RSUM at runtime. These elements only need the mechanism to acquire and abandon roles to adapt the RSUM and to load and create new views at runtime (RQ1). In addition, it is possible to create read-only views, which only allow access to information with get functionality without the opportunity to change the internal state with set functionality. Removing views also just means removing roles and does not afect the RSUM core. In contrast, the deletion of elements in the views is propagated into the core and removes their core natural and all bound roles. The insertion process does the opposite: It creates and binds new management, extension, and view roles in the core and the active views to the new elements on the fly. This mechanism is another necessary part for incremental updates of the RSUM core at runtime because it connects the views to the RSUM and thus also the views among each other (basis for RQ2).
The roles within the views have no copied data from the RSUM and access the information of the naturals via the plays relation. This ensures that no redundant information is kept at runtime and that the status of the RSUM is consistent (underpins RQ2). If an attribute is changed simultaneously in two views, the last propagated change remains. A history Listing 1: Interface of relation compartment. 19 1 trait IRelationCompartment extends Compartment { 2 var source : ISource = null 3 var target : ITarget = null 4 5 def delete () : Unit = { 6 if ( source != null ) { 7 plays . removePlayer ( source ) 8 source = null 9 } 10 if ( target != null ) { 11 plays . removePlayer ( target ) 12 target = null 13 } 14 + this deleteEverything () 15 } 16 17 18 trait ISource extends IRelationRole { def getTarget () : ITarget = IRelationCompartment .
this . target def deleteRelation () : Unit =
IRelationCompartment . this . delete () } mechanism as extension compartment allows to monitor such changes. Our concept is based on materialized view types as own models of compartments to instantiate views at runtime and provide views with a predefined structure. Furthermore, in the role concept, each natural with all bound roles forms a compound object, which ensures that all roles reflect the same object and no object schizophrenia occurs. This fundamental mechanism allows to directly work on parts of the underlying instance without the usage of a communication layer to propagate changes through multiple layers or objects. The whole concept presents the synchronization of views from a single underlying source. However, if we create a combined model from preexisting models, where redundant information is removed, we can depict preexisting models as views from the RSUM. This results in a synchronization approach, which is able to generate new views/models and integrate new or existing legacy models.
However, the concept presented in this section also has some shortcomings. For each pair of elements involved in a relation, a new relation compartment is required which leads to an immense amount of compartments. It must also be ensured that the players of the Source and Target roles in the relation compartments match the players of the bound role in a view, which must be guaranteed at runtime. 3.3
For our case study, we use SCROLL [
In SCROLL, each compartment object contains a role graph called plays that handles the calling of the role’s
Listing 2: Example of relation compartment. 2 3 4 5 6 7 8 9 } 1 class EmployeeHasManager ( emp : Employee , man : Employee ) extends IRelationCompartment { this . source = new Source () this . target = new Target () emp play this . source man play this . target def behavior () : Unit = { ... } class Source () extends ISource { ... } class Target () extends ITarget { ... } methods and allows insertion and removal of nodes and edges. This option makes function calls compartment-specific, i.e., compartments do not allow other compartments to call internal role behavior. For our approach, we combine the role graphs to one that enables us to call all available role methods with the unary + operator in front of a method 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 of more than one role method per API call, i.e., when an instance plays more than one role of one type, a call of a role’s method is successively executed for all bound roles. This function is crucial for instances of the RsumManager, because changes in the RSUM core must be propagated to all extensions and views.
To apply the RSUM approach to an object-oriented model, the object-oriented model must first be transferred to a core model as shown in Figure 4. Therefore, all relations must be expressed as relation compartments.
Listing 1 shows the interface of a relational compartment that has to be implemented. The interface defines the Source and Target roles and a function to delete the compartments. In the delete method (Lines 5 to 15), the roles are deleted from the role graph (Lines 7 and 11) and all bound roles of the compartment will be deleted in the deleteEverything method. This function uses the + operator to call a function defined in another connected role or in the player object. In this case, the deleteEverything method is implemented in the RsumManager role, which must be played by every instance in the core and is explained later in this section. These internal roles only manage access to related roles and forward delete functions to the compartment. This step is necessary because once a natural is deleted in the RSUM, all relationships of that element must also be deleted.
In Listing 2, the EmployeeHasManager relation compartment is shown that must inherit from the interface of Listing 1. It gets the associated naturals during creation and assigns them to new roles (Line 2 to 5). This ensures that the structures at instance level are always bound correctly. The behavior method should show that each relation compartment can have its own behavior and state to extend relations with new information.
To transfer the normal classes to the RSUM, hardly any adjustments have to be made except for deleting the relationship attributes. Listing 3 shows the Library with getters Listing 3: Class example of RSUM. 1 class Library ( _name : String ) { 2 private var name : String = _name 3 def getName () : String = name 4 def setName (n: String ): Unit = { 5 name = n 6 } 7 }
Listing 4: Example role in view. 1 class LibraryRole ( name : String ) extends IViewRole { 2 /* Role specific functionality . */ 3 def getNameView () : String = { 4 return + this getName () 5 } 6 def setNameView ( name : String ): Unit = { 7 + this setName ( name ) 8 + this changeTrigger () 9 } 10 } and setters to access the name. These methods are used by all played roles to change the state of the object.
After the RSUM has been created, views must be defined to reproduce the filtered content. Each view type is given a unique name to distinguish it from other types. Further, all interfaces, no matter whether they are views or extensions, have the getRole method that returns a corresponding role for a class. With this method each view knows what instances it represents and what roles these instances get in the view. If some elements are not presented in the view, this method does not return any role instance. In addition, this method must be unique, which means that it can not be possible for a class to receive several types of roles, or for one role type to be returned for several classes. This mechanism allows creating only one associated object in the core, when instantiating roles in a view. Furthermore, each view compartment contains a list of roles that includes all roles played in this compartment instance. This list is used to prevent duplicate instantiations.
Listing 4 shows an example role from a view that can be played by the natural Library in Listing 3. Each view role inherits from the IViewRole interface for correct view management. In addition, the listing shows how data of players is accessed (Line 4) and changed (Line 6 to 9). Both functions require the + operator to call a function defined in another connected role or in the player object (e.g., setName and getName are passed to the Library). The changeTrigger method is implemented in the RsumManager role and activates all Extension roles bound to this object once there. If the views should react to changes of instances, this mechanism can be used to update visualizations in views. Furthermore, view roles still have delete functions which are not specified in the listing. These functions trigger a cascade of changes in the core model and delete all connected roles and relational compartments if necessary. If a view is created as read-only view, all delete and insert operations will not be generated in the later view generation process. Without these functions, it is not possible to manipulate elements in the RSUM.
The code example in Listing 5 represents the management object. This inherits, in comparison to all other compartments, from the MultiCompartment which allows the consecutive execution of several role behaviors with identical declaration and not only the execution of the first discovered role method. This option is currently only needed by the changeTrigger method in the RsumManager role (Line 44 to 46). This role sends the information about changes to 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). Furthermore, the RsumManagement object manages active views, integrated views, extensions, naturals, and relations (Line 2 to 6). An integrated view can be activated at any time, which inserts a new instance in the list of active views. The active views describe instances of known view types in which someone is currently working. The createView algorithm is not shown in Listing 5 but works as follows: (1) iterating over all relation compartments and binding them to roles returned from the view, and (2) iterating over all naturals to create and binding the last roles to the view. In the views, the links of the players of the Source and Target roles are created simultaneously, if they do not yet exist. In this process, the main part of the calculations takes place in the views. Furthermore, the management compartment contains all RsumManager roles (Line 9), which coordinate the deletion and insertion. The manageRsum method in the RsumManager role is called as soon as a new core element is created, which is passed to the function as an input and processed as follows: (1) The new element is inserted into the corresponding list and if it is a relation compartment, the role graphs will be combined (Line 11 to 15). (2) Matching Extension roles from the respective Extension compartments are bound (Line 17 to 21). (3) Suitable roles are created and bound in all active views (Line 22 to 26).
However, as soon as a delete operation is called, the deleteEverything method is triggered. First, the player of the role (Line 30) and all associated roles (Line 31) are determined. Then the player is removed from the appropriate list in the management compartment and the function iterates over all roles to delete them from the graph (Line 29 to 42). For diferent role types, individual delete operators are called, which are only defined within these roles to guarantee the error-free deletion from compartments.
For the example implementation, we also wrote an extension compartment, which saves every change of a natural and thus creates a history. As soon as a change is made, a copy of all values is stored in a list. This extension can be used as a basis for a versioning module to reload older versions of the RSUM. This scenario is of interest for a distributed development scenario, in which changes can be traced and older states can be used.
All these functionalities are necessary to ensure the incremental updating of views at runtime and to avoid redundant data, which underlines our research question (RQ2) and provides a foundation for further developments. In addition, the role concept that SCROLL ofers is the foundation for an understandable and easily usable way to create views at design and runtime (RQ1). The limitations of this approach are discussed in the section before. Moreover, the current state is a hand written implementation to show the applicability of the concept, but in the future the code should be generated from a domain specific language for view specification.
The RSUM approach described in this paper connects the research areas: single underlying model, view-based software development, databases, and role-based modeling. Each topic has its own background and related literature. We only refer to the work not yet mentioned in Section 2.
In the M@RT area there are already some approaches
that deal with the synchronization of runtime models with
their running model. The MORSE [
Since the beginning of the view-based software
development research, diferent model view approaches have been
created and examined regarding their usefulness during the
software development process. Bruneliere et al. [
The DOREEN approach [
In view-based software development, the views from a
SUM need to be updated over time. This problem is closely
related to the View Update Problem in relational databases.
In the year 1978, Dayal [
In Section 2, we briefly described role models, their
properties, and SCROLL. For our realization, we use SCROLL as a
role-based programming language but there are other options
to implement the features of roles. The Role Object Pattern
(ROP) [
In this paper, we have described the advantages of using the role concept as the foundation to realize a SUM-based software engineering environment called the RSUM approach to synchronize models as views over an underlying source. The approach provides incremental runtime updates in views, and runtime integration of new views. In addition, it introduces a runtime adaptation mechanism in the view and the underlying source level without redundant data, whereby views work on compound objects removing object schizophrenia. Moreover, the role concept provides contextual, behavioral, and relational properties that are used for modeling relational compartments and views to separate concerns in views. The usability of SUM-based software engineering depends on both, lfexibility and stability. Flexibility means to add new types of views and models over time, whereas stability means to have ifxed and stable metamodels, to support standards, and to have tool interoperability. The role concept and the related tools like SCROLL are research prototypes. This reduces the overall tool support and stability of the RSUM approach.
In future work, we need strategies to integrate legacy models into the RSUM. To achieve this, we work on a role-based model synchronization and transformation approach to use a uniform modeling and programming language for the whole process. In addition, we want to provide DSLs to generate views and view types without the currently hand-written implementation overhead. This DSLs should allow filter operations over the naturals and relational compartments to present only parts of all instances.
This work has been funded by the German Research Foundation within the Research Training Group "Role-based Software Infrastructures for continuous-context-sensitive Systems" (GRK 1907).