I. INTRODUCTION

Object-orientation is arguably the most important paradigm in programming and conceptual modeling. Statically-typed object-oriented programming languages, like Java, and traditional conceptual modeling approaches, like E/R and UML, come with a strict separation between class and object. The clabject as central construct of multi-level modeling [10] overcomes this separation and not only plays the roles of class and object but also of metaclass, potentially at many classification levels. Extending traditional modeling/programming languages to supporting clabjects is difficult, due to this inherent mismatch. Dynamically typed languages like Ruby overcome the strict separation between object and class: classes are also treated as objects and may be extended at runtime. Based on this kinship, Ruby suggests itself as a suitable language for implementing multilevel modeling constructs.

Deep Instantiation [2] is one of the most prominent approaches to multi-level modeling. A potency assigned to a clabject or property indicates the number of instantiation levels, i.e., the number of instantiation steps to reach the ultimate instance of the clabject or property. For example, clabject CarModel with potency 2 is instantiated by BMW Z4 with potency 1 which is in turn instantiated by Peter's Car with potency 0. Clabject CarModel defines a property engine with potency 2 and target EngineModel which is instantiated by BMW Z4 has engine EngineK5 and in turn by Peter's Car has engine Engine123; Engine123 is an instance of EngineK5 which is an instance of EngineModel. Clabject CarModel further defines a property listPrice with target currency value and potency 1 which is instantiated by BMW Z4 has list price e 42,232.

Dual Deep Instantiation [9] (DDI) allows to specify the number of instantiation steps separately for the source and for the target of a property. For example, clabject CarModel, as source, introduces property owner with source potency 2 and target Person with target potency 1. This property is ultimately instantiated between instances of instances of CarModel as source and instances of Person as target, for example by Peters Car has owner Peter. Clabject CarModel further has a selfdescribing property creator with source potency 0 and target Person and target potency 1. This property is instantiated between CarModel as source and an instance of Person as target, for example by CarModel has creator Peter.

In previous work, we formalized different variants of DDI in deductive database languages, namely F-Logic [9] and Con-ceptBase [11], but without support for implementing behavior. In this paper we introduce DeepRuby, an implementation of DDI in Ruby that supports the implementation of custom methods. DeepRuby makes heavy use of Ruby's dynamic programming and metaprogramming facilities [12]. The Deep-Ruby version presented in this paper only implements a subset of DDI: it does neither support clabject generalization nor multi-valued attributes. These simplifications allow to set the focus on the following core idea of DeepRuby.

DeepRuby implements DDI at two layers, the clabject # => (#<Social::Woman:0x...> @age=27 @name="Maria") In the remainder of the paper, we give, in Sect. II, an introduction to Ruby's object model. In Sect. III, we introduce a more intricate example DDI model and its representation in DeepRuby. We also explain the clabject naming scheme typically used with DDI for clabjects with more than two instantiation levels. Sect. IV explains the clabject facet layer. Sect. V exemplifies the extension of clabject facets with custom methods. Sect. VI gives an overview of related work. Sect. VII concludes the paper with ongoing and future work regarding the implementation of advanced constructs of DDI [9] and Dual Deep Modeling [11].

II. BACKGROUND: RUBY'S OBJECT MODEL

As a background for forthcoming sections this section explains some relevant aspects of Ruby's object model along a small but intricate example (see Fig. 1).

Ruby's modules provide a namespacing mechanism for constants, such as class names. Class Person (see line 1:2, that is line 2 in the listing in Fig. 1) is created within module Social and can be accessed outside the module by qualified name Social::Person (line 1:32). Note: method puts writes a string representation of the given object to an IO stream -for illustration, the actual output of the Ruby program is given in the program as a comment (e.g., # => (Social::Person)).

Member attributes of a Ruby class are defined as getter and setter methods that access instance variables. Instance variables are created when set by a method. To avoid the need to write getters and setters by hand, class Module provides a method attr_accessor that creates getter and setter methods for an attribute of a given name. For example, in line 1:3, class Person (an instance of Class which inherits from class Module) calls attr_accessor for symbol :age to create setter method age= and getter method age in class Person to write and read instance variables @age (names of instance variables are marked by prefix '@') of instances of class Person, such as Mary (see line 1:16 and line 1:17).

In Ruby, classes are treated as objects and can have instance variables themselves, called class instance variables. Classes are instances of class Class and also may have an eigenclass (also referred to as singleton class). Methods defined with a class's eigenclass (also referred to as singleton methods Single objects may also have singleton classes with singleton methods. For example, Mary's singleton class (opened at line 1:20 by class << Mary and depicted as #Mary) defines getter and setter methods for accessing instance variable @name of Mary.

Ruby allows to open existing classes to add additional methods which then affect all direct and indirect instances of the class. For example, class Object (opened at line 1:25) is the direct or indirect superclass of all custom classes created in Ruby programs and also the superclass of class Module and Class. A method added to class Object can thus be called from any Ruby object (with Ruby classes being also Ruby objects). Method inspect2 (line 1:26) is defined with class Object; when invoked on an object, it creates a string consisting of the object's name and its instance variables (see lines 1:32-1:36).

III. DUAL DEEP INSTANTIATION IN RUBY -AN EXAMPLE

In this section DeepRuby is explained along the example depicted and implemented in Fig. Clabjects are instantiated by sending message new. The new clabject is in the same module as its class and has a potency 1 lower than its class. For example, clabject Person with potency 1 is instantiated by MsBlack (line 2:4) and by Peter (line 2:5), which get potency 0. Clabject Product with potency 3 is instantiated by Bike (line 2:14) and by Car (line 2:19) which get potency 2.

Naming clabjects. The names of clabjects in DDI models (such as in Fig. 2) may seem counter-intuitive. For example, one would typically consider a class named Car to be a specialization (and not an instantiation) of class Product.

In the following we explain how to read such models and sketch the rationale behind this naming scheme.

It is sometimes argued that deep instantiation's support for concise modeling comes with the price of lack of conceptual clarity [3]: one clabject may represent multiple domain concepts which makes it more difficult to differentiate these different domain concepts. In order to make these different domain concepts explicit, we proposed [9]- [11] to give meaningful names to instantiation levels of a clabject and to produce the name of an implicitly represented domain concept by combining a clabject name with a level name.

For example (see Fig. 2), clabject Product has instantiation levels Category, Model, and Individual, representing domain concepts Product Category, Product Model, and Product Individual. Clabject Car is an instance of Product Category and further represents domain concepts Car Model and Car Individual (which are specializations of Product Model and Product Individual). Clabject BMWZ4 is an instance of Car Model and further represents domain concept BMWZ4 Individual (a specialization of Car Individual). Finally, Peters Car is an instance of BMWZ4 Individual.

Defining and instantiating attributes. Attributes are defined with a source clabject, a name, a source potency, a target potency, and a target clabject. For example, clabject Product defines an attribute with name owner, source potency 3, target potency 1, and target clabject Person (line 2:13).

A clabject has many clabject facets, one for each combination of source potency and target potency. In order to set attribute engine at source potency 1 and target potency 1 at clabject BMWZ4 to EngineK5, one first selects the clabject facet (BMWZ4.ˆ(1,1)) to which one sends engine=EngineK5 (line 2:23).

Clabjects with potency 0 have no members, yet they may define attributes with a target potency higher than 0, similar to what can be accomplished in Ruby with singleton classes of an object (e.g., attribute name defined with Mary's singleton class at line 21 in Fig. 1). For example, clabject Peter defines an attribute spouse with source potency 0, target potency 1, and target Person (line 2:6) and instantiates it with target potency 0 and target MsBlack (line 2:7).

Root clabjects with clabject potency 1 are akin to 'normal' classes in that they have individuals as members. They are different from normal classes in that their attributes may have a range defined at a higher classification level. For example, Person (line 2:3) has individuals MsBlack (line 2:4) and Peter (line 2:5) as members, yet it defines an attribute favouriteItem (line 2:27) with target Product and target potency 3, meaning that the range of favouriteItem is given by the members of the members of the members of clabject Product. Querying clabject hierarchies and attributes. The values and (meta) types of a clabject's attributes are queried by sending the attribute name to the clabject facet which is identified by the clabject together with source potency and target potency. For example, sending attribute name engine to PetersCar's clabject facet with source potency 0 and target potency 1 (line 2:32) returns the type of engine of PetersCar, which is EngineK5, which is inherited from BMWZ4.

For getting or setting attributes with source potency 0 and target potency 0 it is not necessary to specify the clabject facet. If a message is sent to a clabject it dispatches it to its 0-0 facet. For example, when sending attribute name favouriteItem to Peter (line 2:30) it is dispatched to Peterˆ(0,0) and retrieves Peter's favourite item, which is his car.

DeepRuby provides methods to navigate clabject hierarchies to facilitate flexible querying of DDI models. For example, line 2:34 retrieves the members of the members of Product, these are BMWZ4 and Brompton. DeepRuby provides (1) generic query mechanisms (1a) to retrieve attribute values and (meta) types including inherited values and types (1b) to navigate clabject hierarchies and retrieve a clabject's members at a specific level and (2) takes care of keeping DDI models consistent when defining and setting attributes, with regard to: (2a) correct number of instantiation steps at the source and the target, (2b) target clabjects are compatible with targets at higher potencies, (2c) a newly introduced target does not produce type conflicts at lower potencies and at descending clabjects.

IV. DEEPRUBY UNDER THE HOOD By freely combining source and target potencies, a clabject c with maximum source potency m (given by the clabject's potency) and maximum target potency n (given by the DDI model's depth) has (m + 1) × (n + 1) clabject facets. Every such facet corresponds to a combination of source potency and target potency. The basic idea of DeepRuby is to represent every such clabject facet as a 'flat' Ruby object (which in the current approach is always a class) with instance variables and methods. For example, clabject Car with potency 2 in a model with depth 3 has 12 (3 × 4) clabject facets. The object Carˆ(0-0) holds @catMgr=MsBlack and Carˆ(2-2) holds @engine=CarEngine as instance variable. The relationships between clabject facets are represented using Ruby constructs:

• The eigenclass of clabject facet c i,j is clabject facet c i,(j+1) . For example, the eigenclass of class Carˆ(0,0) is clabject facet Carˆ(0,1). • If clabject c is an instantiation of clabject d, then every clabject facet c i,j has clabject facet d (i+1),j as superclass. For example, Carˆ(0,0) has superclass Productˆ(1,0) and Carˆ(0,1) has superclass Productˆ(1,1). What is the role of superclass relationships in Deep-Ruby?:

• Methods are inherited from superclass d i+1,j to subclass c i,j (this comes for free, since this is what class hierarchies are traditionally used for). For example, setter method engine= defined at Carˆ(2,1) is inherited by BMWZ4ˆ(1,1) and in turn by PetersCarˆ(0,1). • Target clabjects of attributes (represented as instance variables) are inherited from superclass c i+1,j to sublass c i,j (this is implemented generically as part of Deep-Ruby). For example, when sending message engine to PetersCarˆ(0,1) one gets EngineK5, which is inherited from BMWZ4ˆ(1,1). What is the role of eigenclass relationships in Deep-Ruby?:

• The eigenclass c i,j+1 of a clabject facet c i,j provides methods for accessing instance variables of c i,j (this comes for free with the eigenclass construct). For example, setter method catMgr= defined in Productˆ(1,2) is called for setting @catMgr=Person in Productˆ(1,1) • Target clabjects (represented as instance variables) at c i,j+1 act as constraint for target clabjects at c i,j (this is implemented generically as part of DeepRuby). For example, target clabject engine=EngineK5 of PetersCarˆ(0,1) (inherited from BMWZ4ˆ(1,1)) acts as constraint when invoking setter method engine= on PetersCarˆ(0,0).

We have further been experimenting with two alternative representation of the clabject facet matrix: In the first alternative represenation, clabject facets with target potency 0 are represented as simple objects and not as classes. This would also be a reasonable design choice since these facets do not act as classes, yet it makes the implementation a bit more complex.

In the second alternative representation, we introduce an additional layer between DDI-clabject layer and clabject facet layer in order to align DeepRuby with DeepTelos [6]. At this intermediate layer, a DDI clabject is represented by multiple simple clabjects. A simple clabject resembles an object, class, metaclass, or metaˆn class in DeepTelos. Clabject facets with the same difference between source potency and target potency are collected into such a simple clabject. For example, clabject facets Carˆ(0,0), Carˆ(1,1), Carˆ(2,2) are collected into a simple clabject Car 0 and clabject facets Carˆ(1,0), Carˆ(2,1) are collected into a simple clabject Car 1, with Car 0 having class Car 1 as its most-general instance. A simple clabject combining facets where the target potency is higher than the source potency (e.g., Productˆ(0,1), Productˆ(1,2), Productˆ(2,3)) cannot be directly represented in DeepTelos.

In this section we have explained the basic principles of DeepRuby's implementation and use of Ruby's eigenclass construct to implement Dual Deep Instantiation and have sketched two alternative representations. The evaluation and fine-tuning of these alternatives is subject to ongoing work.

V. SIMPLE ATTRIBUTES AND CUSTOM METHODS IN DEEPRUBY

Using classes/eigenclasses arranged in superclass hierarchies for realizing the clabject facet matrix allows to use standard Ruby constructs to implement simple attributes (attributes with non-clabjects as range) and behavior (custom methods) on top of the clabject facet matrix, and to specialize behavior (i.e., overwrite methods, add additional methods) along the clabject hierarchy.

To demonstrate these features, the running example from Fig. 2 is extended in Fig. 4 with clabject hierarchies Currency with simple attributes for exchange rate (with Euro as reference currency), isocode and value, and Country with a local currency. Clabject Product is extended with a listPrice and a method priceInCountry to convert the list price to the local currency of the given country.

First-level members of Currency receive getters and setters for simple attributes exchRate and isocode by invoking standard Ruby method attr_accessor on the eigenclass of Currency.ˆ(1,0) (which is Currency.ˆ(1,1)) (see line 4:4). Second-level members of Currency get getter and setter for attribute value by invoking attr_accessor on the eigenclass of Currency.ˆ(2,0) (which is Currency.ˆ(2,1)) (line 4:7). Currencies Pound, Euro, and Yen are created with their isocode and exchange rate (lines 4:20-4:25). GBP38200 is an instantiation of Pound (and a second-level member of Currency) with value 38200 (line 4:26).

Second-level members of Currency have a method for pretty printing (defined with the eigenclass of Currency.ˆ(2,0) which is Currency.ˆ(2,1)), making use of value and isocode. In order to get the isocode the method needs to first navigate from the clabject facet (instance of ClabjectFacet) to the corresponding clabject (instance of Clabject) along attribute clabject and from there along attribute cclass to the corresponding first-level member of Currency (line 4:9). Sending pretty to GBP38200 results in 'GBP 38200' (line 4:27).

Second-level members of Currency further have a method toCurrency which takes a first-level member of Currency as parameter (line 4:11). Sending toCurrency with parameter Euro to GBP38200 produces a new instantiation of Euro which is pretty printed as 'EUR 42784.0' (line 4:28).

The eigenclass of Yen.ˆ(1,0) (which is Yen.ˆ(1,1)) overwrites method pretty inherited from Currency.ˆ(2,1)) to use unicode symbol instead of isocode JPY . The new instantiation of Yen created by sending toCurrency with parameter Yen to GBP38200 is pretty printed as ' 5556363.64' (line 4:33).

Clabjects UK and Japan instantiate Country and have local currencies Pound and Yen, respectively. Asking for the exchange rate of Japan's local currency returns 0.0077 (line 4:39).

Method priceInCountry (see line 4:42) of secondlevel members of Product takes a country as parameter and converts the listPrice of second-level instantiations of Product to the country's local currency, returning a new instantiation of the given currency with the value being the result of the conversion. Sending priceInCountry with parameter Japan to BMWZ4 (see line 4:48) returns a new clabject pretty-printed as ' 5556363.64' (line 4:48).

VI. RELATED WORK

With the advent of multi-level modeling, the question of multi-level model execution emerges. Melanee [1], DeepTelos [6], MetaDepth [8], DeepJava [7], and XModeler [4] are modeling tools and frameworks that support model execution, each pursuing a different strategy with respect to supporting model execution. Multilevel programming may also be realized in a type-safe manner by metaprogramming and reflective constraints [5].

The Melanee multi-level modeling tool [1] supports model execution through a service API and a plug-in mechanism. The communication between modeling and execution environment can be realized using socket-based communication. Changes in the modeling environment then automatically reflect in the execution environment, and vice versa. The execution environment can be implemented as a Java program. Concerning the definition of execution semantics, different approaches exist. A "pragmatic" approach, for example, employs a Java representation of the multi-level model where each clabject in the multi-level model corresponds to a single Java class, with execution semantics defined using plain Java code.

DeepTelos [6] extends the Telos metamodeling language and its implementation with "most general instances" to add support for deep instantiation. Since DeepTelos defines the extensions as a set of Datalog axioms, DeepTelos models are compatible with ConceptBase, an implementation of a Telos variant. ConceptBase also allows for the definition of executable models using event-condition-action rules. In Sect. IV we sketched how to group clabject facets into simple clabjects that resemble DeepTelos classes. DeepTelos does not directly support self-describing clabjects (i.e., clabject with attributes where the target potency is higher than the source potency) but comes with powerful metamodeling features unmatched by DeepRuby.

MetaDepth [8] is a text-based multi-level modeling framework with potency-based deep instantiation. MetaDepth is a Java-based implementation using a custom syntax. Among the primary features of MetaDepth are multi-level constraints and derived attributes at different meta-levels. Execution semantics is defined using an OCL extension. MetaDepth provides an interpreter for the thus defined multi-level models. MetaDepth also supports code generation complying to the Java Metadata Interface.

DeepJava [7] is an extension of the Java programming language with a mechanism for potency-based deep instantiation. Internally, a compiler transforms DeepJava code into plain Java. Hence, each DeepJava class translates into a set of Java classes, one for each clabject facet. The compiler also generates code for clabject instantiation at runtime, which is realized using Java's reflective functions. Clabject instantiation results in the dynamic generation of a number of interfaces.

As a limitation, direct access without getters and setters is restricted to attributes with potency values smaller than two. With respect to Java, Ruby's eigenclass concept much better suits the clabject philosophy of multi-level modeling. As opposed to DeepJava, DeepRuby supports deep instantiation with both a source and a target potency, resulting in the generation of a matrix of Ruby classes for each clabject.

VII. CONCLUSION

In this paper we introduced DeepRuby, a Ruby implementation of the core language constructs of Dual Deep Instantiation [9]: clabject hierarchies and attributes with dual potencies. The system takes care of consistent instantiation of clabjects and attributes and provides methods for querying multi-level models. Our experiences with implementing DeepRuby have confirmed our initial conjecture that a dynamic programming language like Ruby that does not strictly separate classes and objects is a good platform for implementing clabject-based modeling constructs.

In an internal prototype we have also implemented DDI's advanced modeling constructs (which are missing from the DeepRuby version presented in this paper): multi-valued properties, bi-directional properties, and clabject generalization. The fine-tuning of the advanced prototype and experimentation with alternative representations of the clabject facet matrix is subject to ongoing work.

Dual deep modeling (DDM) [11], an extended version of DDI, additionally comes with multi-level cardinality constraints, property specialization hierarchies, and distinguishes between property value and property range. Implementing these constructs in DeepRuby is subject to future work.

Moving beyond previous implementations of DDI/DDM in ConceptBase [9] and F-Logic [11], DeepRuby allows to extend clabject facets with custom methods. We have exemplified the implementation of such methods and their inheritance and specialization along the clabject facet hierarchy.

APPENDIX