-Clabjects, the central construct of multi-level modeling, overcome the strict separation of class and object in conceptual modeling. Ruby, a dynamic object-oriented programming language, similarly treats classes as objects and thus appears as a natural candidate for implementing clabject-based modeling constructs. In this paper we introduce DeepRuby, a Ruby implementation of the core constructs of Dual Deep Instantiation: clabject hierarchies and attributes with separate source potency and target potency. DeepRuby represents clabjects at two layers: the clabject layer and the clabject facet layer. At the clabject facet layer, a clabject with maximum source potency i-1 and maximum target potency j-1 is represented by a matrix of i j clabject facets organized using Ruby's superclass and eigenclass constructs. Clabject facets can easily be extended with behavior implemented in custom methods. Index Terms-Object oriented programming, Metamodeling
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 ConceptBase [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 DeepRuby 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 BasicObject
#BasicObject
Object instance_ variables() inspect2()
Person age() age=() initialize()
#Mary name() name=()
Module attr_accessor()
Class
#Object
#Person
counter()
incCounter()
#Woman
layer and the clabject facet layer. DeepRuby’s clabject facet
layer makes explicit each of the otherwise implicit facets
of a DDI clabject by a flat Ruby object. For example,
clabject facet CarModelˆ(
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
Car2 categoryMgr0-0
= MsBlack engine2-2 = CarEngine or class methods) can be used to access a class’s class instance variables. The eigenclass of a class has as superclass the eigenclass of the class’s superclass. For example, Person’s eigenclass (labelled #Person in the graphical representation) is opened by ‘class << Person’ at line 1:8. Person’s eigenclass defines a getter method counter (line 1:9) together with a method incCounter (line 1:10) which is called (line 1:5) to increment the counter every time a new object is created. Class Woman has superclass Person (defined by ‘class Woman < Person’ at line 1:14) and, thus, #Woman (the eigenclass of Woman) has superclass #Person (the eigenclass of Person).
Class instance variables really belong to the class (as an object) and class methods are called in the context of a class object. For example, when calling Woman.new to create a new instance of class Woman the initializer defined with class Person (line 1:4) is called, incCounter is called in the context of class Woman setting instance variable @counter of Woman to 1 (see comment in line 1:19) and not of Person which remains undefined (see comment in line 1:18).
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. 2. Ruby’s modules are used as namespacing mechanism. The clabjects of a DDI model are created within such a module/namespace. For example, module SalesMgmt (line 2:1) serves as namespace for a DDI model with depth 3 (line 2:2), i.e., a model with maximum source and target potencies of 3.
Creating clabject hierarchies. A DDI model consists of one or more clabject hierarchies. Every clabject hierarchy has one root clabject. A root clabject has a fixed clabject potency (specifying the number of instantiation levels beneath the root) and typically has a name. For example, clabject Person (line 2:3) and clabject Product (line 2:11) are the root clabjects in the SalesMgmt model and have a potency of 1 and 3, respectively.
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.ˆ(
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 (
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ˆ(
Carˆ(0,0) is clabject facet Carˆ(
If clabject c is an instantiation of clabject d, then
every clabject facet ci;j has clabject facet d(i+1);j
as superclass. For example, Carˆ(0,0) has
superclass Productˆ(
Product^(
Product^(
Product^(
Product^(
What is the role of superclass relationships in DeepRuby?:
ci;j (this comes for free, since this is what class
hierarchies are traditionally used for). For example, setter
method engine= defined at Carˆ(
What is the role of eigenclass relationships in DeepRuby?:
vides methods for accessing instance variables of
ci;j (this comes for free with the eigenclass
construct). For example, setter method catMgr=
defined in Productˆ(
PetersCar^(
PetersCar^(
PetersCar^(
DeepRuby
Clabject Facet Layer
ci;j+1 act as constraint for target clabjects at ci;j
(this is implemented generically as part of DeepRuby).
For example, target clabject engine=EngineK5 of
PetersCarˆ(
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ˆ(
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.ˆ(
Second-level members of Currency have a method
for pretty printing (defined with the eigenclass of
Currency.ˆ(
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.ˆ(
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 ‘U 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 pretty2() toCurrency2(Currency1) : Currency2
exchRate = 1 exchRate = 1.12 exchRate = 0.0077 isocode = „EUR“ isocode = „GBP“ isocode = „JPY“
pretty1-0()
GBP382000 value = 38200 in the modeling environment then automatically reflect in the but comes with powerful metamodeling features unmatched execution environment, and vice versa. The execution enviby DeepRuby. ronment 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 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 compatible with ConceptBase, an implementation of a Telos language with a mechanism for potency-based deep instanvariant. ConceptBase also allows for the definition of exetiation. Internally, a compiler transforms DeepJava code into cutable models using event-condition-action rules. In Sect. IV plain Java. Hence, each DeepJava class translates into a set we sketched how to group clabject facets into simple clabjects of Java classes, one for each clabject facet. The compiler also that resemble DeepTelos classes. DeepTelos does not directly generates code for clabject instantiation at runtime, which is support self-describing clabjects (i.e., clabject with attributes realized using Java’s reflective functions. Clabject instantiation where the target potency is higher than the source potency) 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
DEEPRUBY IMPLEMENTATION def facet(srcPtcy,tgtPtcy) raise "Target potency #{tgtPtcy} above max potency #{model.depth}+1." if tgtPtcy > (model.depth+1) return levels[srcPtcy].eigenclassN(tgtPtcy) end 121 122 123 124 125 126 127 128 129 130 131 132 133 134 def method_missing(method, *args) if levels[0].respond_to?("#{method}", *args)
levels[0].send("#{method}", *args) else
raise NoMethodError.new("There is no method called #{method} here") end end def define(attribute, srcPtcy, tgtPtcy, value) for n in (1..(tgtPtcy+1)) obj = facet(srcPtcy,n) #crete getter obj.class_eval(" def #{attribute} if @#{attribute}
@#{attribute} else
inherited(’#{attribute}’) end end" ) #create setter obj.class_eval(" def #{attribute}=(val) if valueSettingAllowed(:#{attribute}, val)
@#{attribute} = val end end" ) end set(attribute, srcPtcy, tgtPtcy, value) return self end def checkDownwardCompatibility(attribute, srcPtcy, tgtPtcy, value) return true unless levels[srcPtcy].getMostSpecific(attribute) return true if value.nil? for potency in (0..srcPtcy) getMembersN(potency).each do |cbj| actMsVal = cbj.levels[srcPtcy-potency]
.getMostSpecific(attribute) raise "#{value.name} is not compatible with #{actMsVal.name}" if
!value.isCompatibleWith( actMsVal ) end end end 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 end end facet(srcPtcy,tgtPtcy).send("#{attribute}=", value) return self end def get(attribute, srcPtcy, tgtPtcy)
facet(srcPtcy,tgtPtcy).send(attribute) end def getValueSettingObject(attribute, srcPtcy, tgtPtcy) facet(srcPtcy,tgtPtcy)
.getValueSettingObject(attribute.to_s.to_sym) def getMethodDefiningClass(attribute, srcPtcy, tgtPtcy) facet(srcPtcy,tgtPtcy)
.method("#{attribute.to_sym}").owner def to_s clabjectname = (clabject.respond_to?(:name))? clabject.name : clabject "#{clabjectname}ˆ(#{srcPtcy},#{tgtPtcy})" end end # end Clabject module ClabjectFacet attr_accessor( :clabject, :srcPtcy, :tgtPtcy ) def parent superclass end def eigenclass singleton_class end def inherited(attribute) if parent.respond_to?(attribute.to_s.to_sym) parent.send(attribute.to_s.to_sym) else false end end def getValueSettingObject(attribute) if instance_variable_get("@#{attribute.to_sym}") self else getInheritedValueSettingObject(attribute) end end def getInheritedValueSettingObject(attribute) if parent.respond_to?(attribute.to_s.to_sym) parent.getValueSettingObject(attribute.to_s.to_sym) else false end end def getMostSpecific(attribute) getMostSpecificN(attribute)[:val] end def getMostSpecificN(attribute) if respond_to?(attribute) val = self.send(attribute) if val
return {:ptcy => 0, :val => val} elsif eigenclass.respond_to?(attribute) x = eigenclass.getMostSpecificN(attribute) #recursion if x[:val]
return {:ptcy => x[:ptcy]+1, :val => x[:val]} end end end return {:val => false} end def valueSettingAllowed(attribute, value) if value.kind_of?(Clabject) ms = getMostSpecificN(attribute) if ms[:val] && !value.isMemberN( ms[:ptcy], ms[:val] ) raise "#{value.name} is not memberN(#{ms[:ptcy]}) of
#{ms[:val].name}" end return true else
raise "#{value} is no Clabject" end end def eigenclassN(n) obj = self for m in (1..n) # returns self if n=0
obj = obj.singleton_class end return obj end