Model-Driven Engineering (MDE) technologies are more and more used outside the software engineering eld such as the typical cases of code generation and formal validation and veri cation. In fact, MDE is applied to many di erent modelling situations such as regulation, law compliance, data analytics, etc. In these domains, we often face incomplete and/or evolving requirements, which implies the need for speci c modelling facilities. In particular, we must be able to relax standard metamodel de nition in order to express uncertainty and unforeseen modelling constructs. However metamodels are important for dealing with computer-based manipulation of models: from the exible models a (new) metamodel should emerge. It will freeze the modelling language features that permit: model transformation, comparison, evolution, etc. In this article we propose a framework called JSMF, based on JavaScript. It allows for de ning a exible metamodel, to freely de ne models and provide controls for checking the level of conformance. We also show how to use JSMF for the incremental de nition of a frozen metamodel, starting from a exible one.
Model-Driven Engineering (MDE) is increasingly applied to modelling cases
where the traditional approach of building models that conform to a precise
and pre-de ned metamodel is not su cient (e.g., enterprise modelling). Indeed,
models are built by domain experts that are not using traditional modelling
tools. Surveys regarding enterprise models [
If a exible modelling environment (i.e., not enforcing strict conformance)
allows for better handling of models for speci c situations, it lacks the MDE key
capabilities, e.g., model transformation, computation, comparison, etc. In order
to allow computer based manipulations of such models, the exible (meta)model
should be progressively frozen [
Many approaches exist for bridging sketching tools/free modelling and the MDE approach trying to reconcile inconsistencies between exible models and their underlying metamodel. In this article we will not investigate the alignment of drawing tools elements and metamodel concepts nor try to infer types for model elements. We rather propose a framework that allows for 1/ de ning level of exibility regarding the conformance relation, 2/ consequently being able to de ne models that not strictly conform to a metamodel (e.g.: by adding properties), 3/ making new metamodel emerging for raw elements.
We will rst introduce the JSMF framework as a general overview focusing on its exibility feature. In a second time, we depict our vision of model exibility based on (meta)models features. Finally, we propose a reconciliation mechanism for the conformance relation. 2
The JavaScript Modelling Framework (JSMF) has been designed for providing
a exible modelling environment that could support the requirements of natural
modelling [
Model elements. JSMF actually di ers from existing EMF translation/adaptation in JavaScript like, for instance, EMFJSON 1 or a lightweight EMF implementation in JavaScript JSMF 2: it does not copy the instantiation mechanism of EMF/Java using the JavaScript prototype. On the contrary a model element conforms to a metamodel element only using instantiation mechanism. But it does not prevent from adding any properties (i.e., like any standard JavaScript
object). Rules for setting (and getting) attributes and references are dynamically created at object creation but can be adapted afterwards. Moreover the metamodel and model can evolve independently, the model is just keeping a reference to the metamodel that has been used for its creation (which can be inconsistent).
In JSMF, a metamodel can be de ned using di erent syntaxes as shown in Listing 1. The classical syntax is inspired by the EMF API. In the example, a Family is a new instance of class Class. This Family class has an attribute lastname of type String - here we use the basic type of JavaScript. One can also use jsmf.String (as shown below as a type element). In JSMF, types are simply functions that returns true if the given value in a model (i.e., during instantiation) is valid for this type. When we provide String, it's implicitly translated in the jsmf.String function that returns true for any string. The Family class has also a relation named members that related it to a class Person with a cardinality (0..*) as de ned by JSMF.Cardinality.any.
The compact syntax is largely inspired by the one used in JavaScript for de ning raw objects. Here, we present a class Person that has no super-type (empty array of types []) and has two attributes firstname and age of respective type String and jsmf.Positive. // Compact ( JavaScript Object ) Notation const Person = Class . newInstance ( ' Person ', [] ,
{ firstname : String , age : jsmf . Positive }) // Classical Syntax - EMF like const Family = Class . newInstance ( ' Family ') Family . addAttribute ( ' lastname ', String ) Family . addReference ( ' members ', Person , jsmf . Cardinality . Some ) Listing 1. De nition of Person and Family in JSMF using two possible syntaxes
As a basic feature of JSMF we allow to de ne relationships that target any class of any type, see Listing 2. This is equivalent to referencing the EMF EObject Class. This is a rst form of exibility: it means that any class can be targeted by such relation (i.e., target type of this reference is not discerned). For example, the previous Family declaration would be the following if we want to accept any class instance as a member of a family: const Family = Class . newInstance ( ' Family ') Family . addAttribute ( ' lastname ', String ) Family . addReference ( ' members ', jsmf . JSMFAny , jsmf . Cardinality . Some )
Listing 2. De nition of annotation
As a summary, the features and the conceptual structure of the JSMF (meta)modelling environment is de ned in the Figure 1. In JSMF a class can inherit from multiple classes, combining all the properties together. However, if a model element is overridden into multiple inherited classes (e.g., the same attributes de ned many times), only the last class is taken as the only de nition 3.
Alike many object inspired modelling frameworks, a JSMF Class has many attributes and references. Attributes are classically de ned (name, type and mandatory attributes). References are partially classically de ned: reference point at a TargetElement. Target elements can be a precise class or any JSMF element: JSMFAny.
One speci city of JSMF is that we can de ne an associated class which
could quality the reference/relation, i.e., providing additional information such as
weight, probability, etc. Through references one can directly de ne a relationship:
proposing an opposite reference and an opposite cardinality. Cardinalities are
de ned as follow by prede ned set of min/max: [
For building modelling elements that conform to metamodel elements two notations also exists: a classical object (EMF-like) construction (create object rst, then set attributes) or the compact JavaScript one. // Expanded notation & new const john = new Person () john . f ir st na me = ' John ' john . age = 46 // Compact notation & n e w I n s t a n c e const kennedy = Family . n e w I n s t a n c e ({ name : ' Kennedy ' , members : [ john ]})
Listing 3. De nition of annotation 3
As presented in the previous section, JSMF looks like a classical framework that takes bene ts from JavaScript dynamic typing. In this section we show how JSMF could that o ers more exibility than traditional approaches. In order to build a exible modelling support, several rules needed to be relaxed as well. Relaxing the conformance relation allow models to be adapted to various situations. For instance, for adapting (meta)model to the domain being discovered or to overcome language limitation regarding a peculiar purpose. 3.1
Within JSMF, relaxing the conformance can apply to an entire model or just to
some elements. As a result we allow each (meta)model element to be con gured
separately. A metamodel which has some exible modelling elements can be
referred to as a proto-metamodel. Like proto-languages [
We have identi ed some important properties for setting the exibility level. Attributes optionals/mandatory: By default in JSMF, attributes are optional but they can be set as mandatory thanks to an option in the attribute de nition.
Attributes types: The types can be checked or not, same applies to typeimposed constraints (e.g., a Number between 0 and 20).
References cardinalities: The cardinality can be checked or not. Not checking the cardinalities means setting a 0..* cardinality.
References targeted type: As shown before, targeted types can be loosely de ned using JSMFAny. There is a slight di erence between using JSMFAny and not checking type. For the latter the declared type can be a hint. References opposite: The opposite relation can be checked or not (including the opposite cardinality).
The level of exibility can change all along the life-cycle of a metamodel. 3.2
JSMF provides facilities to de ne the exibility of the models class by class and even at the attributes and references level. By default, a JSMF (meta)model comes with the following exibility rules: { Attributes types are checked when we assign a value to an attribute slot. If the attribute is mandatory, JSMF check that the value is unde ned. Assigning an invalid value to an attribute slot will raise an exception. { Reference targeted types are checked. An error is raised when an attempt is made to assign the wrong type to a reference. { References cardinalities are not dynamically checked. { Additional-attributes and references can be de ned on an existing object.
JSMF allows a ne management of the two rst items of the list above (attribute types and mandatory checking, and reference type checking). We can either modify the de nition of the exibility of an attribute or reference at its declaration or later on for a whole class. Here, in Listing 4 we revisit the example of Listing 1 but we replace the Family class by a de nition with a exible reference members and we set the whole Person class as exible. // Set the whole Person class as Flexible Person . setFlexible ( true ) // And thus is a ( stupid but ) valid instance declaration const john = Person . newInstance ({ firstname : 42 , age : ' John '}) // errorCallback define the flexible behaviour of members const Family = Class . newInstance ( ' Family ', [] , { lastname : { type : String , mandatory : true }} , { members : { target : Person
, errorCallback : jsmf . onError . silent }}) const smith = Family . newInstance ( ' Smith ') // We can assign something else than a Person to members smith . members = [ smith ]
Listing 4. Flexibility declaration example
As written in Listing 4, the exibility of a whole class can be set thanks to the setFlexible method. For a single attribute or reference, one can use errorCallback during the declaration to de ne the behaviour of JSMF when a type error is encountered. Several default methods are provided to handle these type errors. Here, we use onError.silent, which discards the type error and performs the assignment. More advanced methods can be de ned, allowing for example to correct some errors before the assignment. 3.3
Whilst model exibility can be desirable in an exploration phase, it may not t with all production purposes. We need tools to assess how a model di ers from its metamodel and then to reconcile them. JSMF provides a checking tool that will check basic construction rules (attributes and references types, cardinalities, extra attributes or references) as well as metamodel-speci c constraints (a la OCL). The checker returns a JavaScript object containing all the constraints violations of a model. These violations are grouped by constraint type and come with a detailed context that allows precise identi cation of the issue location in the model. In Figure 5, we use the exible Person and Family to provide a rst sketch of a model instance with some di erences its reference model (metamodel). const DomesticPet = jsmf . Class . newInstance ( ' DomesticPet ', [] , { name : String , race : String }) Person . setFlexible ( true ) const FamilyModel = new Model (' FamilyModel ', {},
[ Family , Person ]) const kennedy = Family . newInstance ({ name : 'Kennedy '}) const john = new Person ({ firstname : 'John ',
birthdate : new Date ('1917 -05 -29 ')}) const jackie = Person . newInstance ({ firstname : ' Jacqueline ', nickname : 'Jackie ', birthdate : new Date ('1929 -07 -28 ')}) const charlie = DomesticPet . newInstance ({ name :'Charlie ', race : 'Welsh Terrier '}) kennedy . members = [john , jackie , charlie ] const Families = new Model (' Families ', FamilyModel , [ kennedy , jackie , john , charlie ])
Listing 5. Flexible metamodel and model instance
If we check the Families model (typing Families.check()), we obtain as a result a JavaScript object that gather all the errors, grouped by error type. The conformance check of the example of Listing 5 catches the following error: { The family object Kennedy has a eld lastname which is mandatory but unde ned. { The Kennedy Family also has a member that is not a Person, Charlie. { Several elements ave additional attributes: Jacqueline has a birthdate and a nickname, and John has a birthdate.
To give an insight of the object representation, Listing 6 provides an excerpt of the conformance check object. Note that this is a raw output of a JavaScript object, not intended to be used as-is for human comprehension. The excerpt shows the reference type violation entries. It is composed of a unique error. The error is de ned as a heterogeneous list, where the rst element is the model element that contains the error (the Kennedy family), the second element is the reference name that contains the error (members) and the third element is the wrongly typed element (the dog Charlie). The advantage of the output as a JavaScript object is that we have a direct access to the model elements that do not conform to the reference model. Thus we can access and modify them directly.
{ // ...
referencesTypeRule : [ [ { lastname : undefined , members : [ Object ], name : ' Kennedy ' }, 'members ', { name : 'Charlie ', race : 'Welsh Terrier ' } ] ], // ...}
Listing 6. An excerpt of check result
The Metamodel and Model reconciliation involves applying di erent modi cations to the model and to the proto-metamodel to obtain, ideally, a model and a metamodel such that the rst conforms to the latter. As an embedded DSL language, and thanks to its exibility, JSMF can take advantage of JavaScript expressiveness to tweak both the model and the metamodel quite easily. A classical reconciliation session consists in applying modi cations to the model and metamodels and observing the conformance errors of the resulting (meta)models.
A subtlety is that, as explained in Section 2, evolution of a metamodel element is not immediately replicated on elements that conform to it. We provide two functions, refreshElement and refreshModel to respectively resynchronize an element or a whole model with an up-to-date metamodel.
Based on the example in Listing 5 we illustrate the two major reconciliation approaches: modi cation of the model elements to conform to the metamodel and the converse.
Applying change directly to the model. Let's decide that lastname is the correct attribute name for a family name. Thus, we must change the kennedy object accordingly, which can be done in two JavaScript instructions: kennedy.lastname = kennedy.name; delete kennedy.name. Here, the metamodel is unchanged, we have just xed a model element.
Applying change directly to the metamodel. Changes to the metamodel can be performed manually or through heuristics functions. Manually, we can for example add a nickname attribute to the Person class quite easily and then we just have to refresh the model elements, as follows: Person.addAttribute('nickname', String) jsmf.refreshModel(Families) Discovering metamodel structure from a model. Changes can also come from the models used here as an archetypal example. Note that we are not addressing the discovery of a full metamodel from a exible model, but rather re ne some parts (i.e. class) of a exible metamodel. One can decide that a model element is an archetypal representation of a class, thus updating the metamodel accordingly. The properties of the object (note that this also works for non-JSMF objects) are examined (as key-value pairs) and the attribute types inferred from the current data, notably using JavaScript's typeof. For references, we make the assumption that they target only JSMF elements. For instance, the Jackie Kennedy instance can help in building or updating the Person class by invoking the archetypalDiscovery function. The Person gets 3 attributes, here adapted from log trace: attributes: { firstname:[Function: isString], //...
nickname:[Function: isString], //...
birthdate:[Function: isDate], //... }
In [
In the rst extreme of exibility, metamodels are not pre-de ned and are
inferred from models. The approaches of [
The concept of Muddle [
A posteriori typing [
Finally, the approach of [
We have presented JSMF4, a exible modelling framework which allows to dene both relaxed and rigid conformance. JSMF, as we have shown in this article, comes with the possibility to check the conformance (dynamically and statically) comparing the models and metamodels and reconciling them together in both directions: i.e., by enforcing conformance (Metamodel! Model) or by discovering structure from an example (Model! Metamodel). With JSMF any part of any modelling element (its attributes and references) can be made exible by disabling (i.e., silencing) the -dynamic- type checking used when assigning values. However, exibility without control would not be useful. In order to retain bene ts from MDE tools (e.g., model transformations) we need to get back to rigid modelling elements. We have designed a static checker that helps in identifying issues and supporting a progressive translation to a classical MDE approach. As such, JSMF can be seen as a prototyping environment before applying more traditional/industrial MDE solutions. The exibility of JSMF is ideal during the exploration of a new domain, problematic, etc. 4 see https://js-mf.github.io/ for implementation and more components.
Future work will focus on investigating inference (e.g., type inference) for
ambiguous modelling elements or from any data source. Notably we aim at
supporting natural modelling sessions [