Keywords

1 Introduction

Model Driven Development (MDD) is the branch of software engineering that advocates the use of models, i.e., abstract representations of a system, and of model transformations as key ingredients of software development [21]. With MDD, developers use a general purpose (e.g. UML [4]) or domain specific (e.g., IFML [24]) modeling language to portrait the essential aspects of a system, under one or more perspectives, and use (or build) suitable chains of transformations to progressively refine the models into executable code. General purpose languages, such as UML, aim at spanning the entire spectrum of software applications under all possible perspectives and thus are large and complex. It is hardly the case that developers can afford building their own MDD development environment, including such aspects as model editing, verification and code generation, because such a task could easily exceed the effort of the actual application to be delivered. Therefore, general purpose modeling languages must be supported by dedicated tools, which in turn present, despite the claims of interoperability, problems of so-called vendor lock-in. On the other hand, domain specific modeling languages [18] have been proposed to overcome the complexity and steep learning curve of general purpose approaches; their abstractions do not pretend to be universal, but embody domain knowledge that make the language speak in terms closer to the intuition of the developer and of the application stakeholders. On the negative side, though, domain specific modeling languages have a more restricted user base, which prevents in many cases the development of industrial-strength supporting tools. For this class of languages, the need arises of creating and maintaining the tool chain necessary for bridging the gap between model specification and the real application deployment. Such a tool chain revolves around one or more domain specific model transformations. A such transformation is a procedure that takes in input a model, plus some additional domain or technical knowledge, and outputs a more refined model (yielding, at the end of the chain, the source code, which can be seen as the most concrete model). Creating model transformations is not itself an easy task. It is analogous to the construction of a compiler, which requires mastering very specific abilities, including meta-modeling (i.e., the specification of the grammar of the input language), definition of language semantics, and implementation of mapping rules. Presently, model transformation languages, such as ATL [17] and OMG QVT [3], and their support development environments, such as the ATL Integrated Environment (IDE) for EclipseFootnote 1, are tools for the experts. They require specific skills regarding the language syntax and semantics and programming style. In many cases, organizations create and evolve a supporting MDD environment alongside their applications or product lines. Developers recognize recurring patterns of abstraction in their requirements and designs and tend to factor them out and promote them into abstractions of an emerging domain specific modeling language. Then, they try to boost reuse by generating code from the instantiation of their own abstractions. It is easy to see that this way of affording development requires the application of effective software engineering practices not only to the application, but also to its supporting MDD environment. Specifically, the well-known principles of agility should be seamlessly applied to both focuses of development, especially in the today’s scenarios where scarcity of time and resources and high technological variability are the norm.

To address the agile development of MDD support tools, this paper presents ALMOsT.js, an agile, in-browser framework for the rapid prototyping of MDD transformations, which lowers the technical skills required for developers to start be proficient with modeling and code generation. The contributions of the paper can be summarized as follows:

  • We describe ALMOsT.js, an MDD development framework that exploits well-know technical standards (JavaScript, Node.js and the JointJS GUI library) to help developers edit models in their formalism of choice and create transformations quickly and without complex meta-modeling steps.

  • We discuss how ALMOsT.js can be used with an agile methodology, by rapidly prototyping, verifying, and evolving model editors and transformations.

  • We illustrate how in ALMOsT.js developers specify transformations with a simple rule language that extends JavaScript naturally.

  • We evaluate the effectiveness of ALMOsT.js in a case study in which the framework has been applied to a real world MDD scenario: the construction of an agile development environment for the OMG Interaction Flow Modeling Language (IFML) [24], called IFMLEdit.orgFootnote 2. ALMOsT.js has been used to create an IFML model editor, a model to model transformation mapping IFML to Place Chart Nets (PCNs) [20] for verifying the correctness of models via analysis and simulation, and two model to text transformations for automatically generating Web and cross-platform mobile code.

The paper is organized as follows: Sect. 2 surveys the work on agile MDD and transformation tools; Sect. 3 presents the architecture and components of the framework and reports on its application to the case study of IFML.org; finally, Sect. 4 draws the conclusions and gives an outlook on future work.

2 Related Work

Agile software development [2] is an incremental and iterative approach based on principles that aim at increasing productivity and adherence to requirements, while keeping the process as lightweight as possible. Agile Model Driven Development has been advocated as a promising approach [6], which has not yet fully expressed its potential [15, 23]. Its idea is to organize the MDD process in ways that take advantage of the agile development principles:

  1. 1.

    Enabling an incremental and iterative development cycle by using toolchains able to test and validate even incomplete models [19].

  2. 2.

    Applying a Test-Driven Development, a distinctive feature of extreme programming [9], to MDD. [5, 26].

  3. 3.

    Merging agile workflows such as SCRUM [25] with MDD in novel methodologies, to achieve system-level agile processes [29].

The above mentioned approaches mainly focus on enhancing the development cycle of the final product, assuming a predefined set of modeling languages and transformations. The rapid evolution of new technologies and the short time-to-market required today highlight the need to integrate modeling languages and tools in the loop [27], co-evolving iteratively the modeled final product and the MDD tools and languages. Accordingly, ALMOsT.js aims to foster agile processes in MDD not only when the models and transformations have already been chosen and are stable, but also when developers need a lightweight development environment that can be exploited to deliver minimum viable products rapidly, for the model concepts and transformations as well as for the target applications.

Model transformations are supported by many languages [13, 22] and implemented by an even greater number of tools [12]. We limit the discussion to the works that are more relevant to our approach. Several works focus on domain specific languages and on different aspects of model transformation, as extensively discussed in [10, 11, 13]. The proposed transformation languages employ different styles:

  1. 1.

    Declarative: transformations exploit mappings between elements of the input and of the output metamodel. An example is EMF Henshin [7], which focuses on model-to-model transformation using triple graph grammars.

  2. 2.

    Imperative: transformations are programmed as a sequence of operations. An example is Kermeta [14] an imperative programming language able to perform model transformations.

  3. 3.

    Hybrid: transformations mixing the declarative and imperative style. An example is ATLAS Transformation Language (ATL) [16] where declarative mappings can be extended by imperative constructs. The ATL transformation engine also automatically identifies the optimal rules execution order.

Some languages focus on particular features like Epsilon Transformation Language (ETL) [22], which is a model-to-model transformation language that can handle more than one source and target model at a time. Model-to-text transformation languages, such as Xpand, the imperative language part of OpenArchitectureWare, are generally template-based. Code is embedded inside plain text, making it easy to convert a source or configuration file into a template.

As illustrated in Sect. 3, with ALMOsT.js we aimed at quite a different objective, trading completeness for simplicity: reusing a popular, general purpose language, in which many developers are already proficient, to build a lightweight MDD environment whereby developers can design domain specific languages and the associated transformations rapidly and without resorting to external tools.

3 The ALMOsT.js Framework

In this section, we describe the architecture of ALMOsT.js (AgiLe MOdel Transformations), its rule language, and showcase its usage for customizing model editors and for building model to model and model to text transformations. For concreteness, the examples of data objects and rules are drawn from a simplified running example, and further expanded in a case study described in Sect. 3.6.

3.1 Requirements

Before introducing the architecture and use of ALMOsT.js, we pinpoint the requirements for its development that make the resulting environment amenable for use within an agile software development methodology. Here, we focus on the core characteristic of agile development methodologies, such as SCRUM [25], which commands developers to create minimum viable products rapidly and evolve them via frequent iterations (sprints). As a reference usage scenario for ALMOsT.js we imagine a software team, who has elicited the requirements for an application or product line and decides to exploit MDD in its development, by progressively factoring out domain abstractions from requirement and building a support environment for creating models, verifying them and generating code, in an iterative way. This scenario does not rule out the complementary case in which a tool company wants to implement rapidly and evolve over time a support environment for an existing standard or proprietary MDD language.

Under the above mentioned drivers, the requirements at the base of ALMOsT.js can be summarized as follows:

  1. 1.

    No installation. It must be possible for the team to use the framework instantly, with no installations.

  2. 2.

    No new language. It must be possible to start using the environment without learning languages that are not normally employed for application development.

  3. 3.

    Fast start-up. It must be possible to create a minimum viable model editor and model transformation in a very short time (e.g., less than one day).

  4. 4.

    Parallel development. It must be possible to work in team on different aspects of the same sprint, e.g., by adding a new concept to the model editor, and the corresponding generative rules to the model to model transformation and model to text transformation in parallel.

  5. 5.

    Customized output. There must be an easy and standard path to turn the (possibly prototypical) generated code into a complete version, by adding (manually) the missing aspects.

  6. 6.

    Customized generation. It must be possible to tailor the non-functional aspects of the generated code easily, e.g., by adding graphics and sample data collections for early validation of the product with stakeholders.

3.2 Architecture

In this section we show how we addressed requirements #1 (No installation) and #2 (No new language) in the design of the ALMOsT.js architecture. ALMOsT.js has the simple organization illustrated in Fig. 1. The implementation has been realized entirely in JavaScript, which is also the only language needed by developers to plug their domain models and transformations into ALMOsT.js, in observance of the above mentioned requirements.

At the core of the framework, the Data Model comprises the domain model objects, encoded according to the minimalist structure explained in Sect. 3.3. Objects of the data model are created and manipulated by the Model Editor, a GUI component, running in the browser, with the usual functions for creating and modifying projects consisting of MDD diagrams, and for storing, retrieving, manipulating and annotating models and their constituents. Alternative Model Editors can be plugged-in, as far as they are able to create objects of the Data Model, making ALMOsT.js independent of the model editing GUI (more details on the Model Editor are provided in Sect. 3.5).

Fig. 1.
figure 1

Architecture of ALMOsT.js

Full size image

The objects of the data model are also read and written by the model transformations, encoded as Transformation Rules in the Model2Model and Model2Text components. To avoid inventing yet another transformation language, transformation rules are coded as pure JavaScript functions, according to the prototypical signatures illustrated in Sect. 3.4. This choice also simplified the implementation of the Rule Engine, which employs the standard function call mechanism of JavaScript to orchestrate the execution of rules. The Rule Engine exploits the stateless and side effects free nature of model transformation and employs a functional approach. Once configured, it acts as a main loop iterating one simple function, which takes as input a model object (described in Sect. 3.3) and returns as output the aggregated results of applying all the relevant rules to it. The Rule Engine function is internally organized in two sub-functions: the Scheduler is responsible of matching the input rules against the model objects (see Sect. 3.4), schedules rule execution, and collects their outputs. At each round of the main loop of the Rule Engine, the Scheduler manages the matching of the rules to the objects of the model and determines the rules to fire in the current round. The order of rule execution is pseudo-random: it depends on the order of definition of rules and on the order of creation of the model objects. All the output elements produced by the execution of the rules are grouped by a key (normally a property name of some model element) and passed to the Reducer for aggregation. The Reducer is the sub-function of the Rule Engine responsible of aggregating the results created by the execution of the Scheduler. If multiple rules generate outputs with the same key (i.e., multiple values for the same property of an object), then a conflict arises [28]. A typical case occurs when rules add multiple sub-elements or relationships to the same model element. The Reducer addresses the conflicts by merging output values referred to the same key into one resulting value. The merging policy is defined in the configuration of the Rule Engine; the available options are:

  • first: (default) the first value, in terms of creation order, is used.

  • last: the last value is used.

  • concat: all the values are used and stored in an array.

The following fragment of the configuration of the Rule Engine specifies that conflicts related to the name property of an output object are treated with the first conflict resolution policy, whereas those related to the children property are treated with the concat policy.

figure a

More details on how the Rule Engine can be configured to obtain different types of transformations are reported in Sect. 3.6.

3.3 Data Model

As shown in Fig. 1, the data model underpins all the components of ALMOsT.js. The artifacts of the data model can be regarded as a minimalist subset of the entities of the Essential Meta Object Facility (EMOF) OMG metamodel standard [1]. To cope with requirements #2 (No new language) and #3 (Fast start-up) the concepts of the data model are exposed as plain JSON objects, which facilitates creation, storage, manipulation, and migration between components. For example, developers can use model editors of their choice, provided that they can generate the JSON objects of the data model. Each MDD project must include a model object, which represents the entry point of the domain model; this is a root container object with two members:

  1. 1.

    elements: an array containing all the elements in the model.

  2. 2.

    relations: an array containing all the relations between elements in the model.

figure b

Developers can start from this minimal assumption to fill a model object with their own model concepts (elements and relations). Even if ALMOsT.js does not require any particular structure for elements or relations, we propose a simple format, which facilitates element type identification, relations navigation, and separation of concerns between the data that are a proper part of the elements (attributes) and the descriptive information associated with them (metadata). According to this proposed format, each entry in the elements array must be an object (in JSON) endowed with the following properties:

  1. 1.

    id: a string that uniquely identifies the element in the model. It is used as a reference by relations.

  2. 2.

    type: a string that identifies the type of the element. No formal type system is assumed, type names are completely user-defined. Specifying types for model elements helps rule condition expressions to locate matching elements by simply checking their type name (see the examples of rule conditions in Sect. 3.4).

  3. 3.

    attributes: an array of objects, whose members are domain specific properties of the enclosing element.

  4. 4.

    metadata: an array of objects, whose members are descriptive properties of the enclosing element. Rules (see Sect. 3.4) should not take any decision based on metadata and should use them just as optional information that helps the output generation. Examples of metadata are graphical information (e.g., position and size of a model element in the graphical model editor) or debug information.

The following JSON object illustrates the representation of a model element: the Mails object of type ifml.ViewContainer.

figure c

Each entry in the relations array is a (relation) object, endowed with the mandatory type member, which describes the semantics of the relation. As for elements, no assumption is made on the available types of relations, which can be defined by the developer. The other members of a relation object must be references to elements in the elements array.

The following JSON object represents a hierarchy relationship between two model elements, mails and mails-list.

figure d

3.4 Transformation Rules

As per requirement #2 (No new language), we did not create a custom rule language; the entire tool, including the rule language, is based on the JavaScript programming language. All transformations are expressed as Condition-Action (CA) rules [28], defined as pairs of plain JavaScript functions. Rule definitions are stored in JavaScript source format in the Model to Model Rules and Model to Text Rules components of Fig. 1. A CA rule simply consists of:

  1. 1.

    Condition: A function verifying if the current rule can be applied. It must return a Boolean value (or anything that can be interpreted as a Boolean value) informing the Rule Engine that the rule is activated and can fire.

  2. 2.

    Action: A function responsible of mapping the inputs to a series of outputs. The output of an action function must be a JSON object. Each member of these objects is treated separately and passed to the Reducer component for conflict resolution and aggregation (as explained in Sect. 3.2).

The condition part of a rule may match specific elements or relations in the model, or a whole model. Three type of rules can be identified.

  1. 1.

    Model rules. The input is the whole model. These rules can be used for setup purposes, e.g., for inserting fixed outputs into a model. The example below shows the declaration of a model rule.

    figure e

    The (model to text) rule contains a condition function that receives in input a model object and tests if it contains elements. The action part simply returns a piece of the JSON configuration that specifies a fixed-name project folder.

  2. 2.

    Element rules. An element rule has a condition function that matches a specific model element and maps it (and possibly other related ones) into others elements and/or relations. Note that element rules can be used to identify patterns in the source model, by writing a condition part that traverses the model graph starting from the matched element. The following declaration illustrates the structure of an element rule.

    figure f

    The (model to model) rule is activated by a match with an element of a given type (ifml.ViewContainer) and produces as output a model element of another type (pcn.PlaceChart), with the same Id and name of the input element.

Relation Rules. A relation rule has a condition that matches a specific relation and can be used to map relations into other relations and/or elements. Also relation rules can be used to identify patterns in the model, by writing conditions that traverse the model graph starting from the matched relation. An example of relation rule is as follows.

figure g

The above rule matches an input relation object (of type hierarchy) and creates as outputs one element (of type pcn.Transition) and two relations associated with it, one of type source, associated with the parent of the matched relations, and one of type target, associated with the child of the matched relationFootnote 3.

A Complete Example. To illustrate transformations in ALMOsT.js, we provide a small, yet realistic, example of model to model and model to text transformation: the well-known mapping of Entity-Relationship concepts to the relational model and to the SQL Data Definition Language [8]. Specifically, the two rules below respectively map an N:M relationship of the Entity-Relationship model into a bridge table of the relational model and into the SQL code for generating such table.

figure h
figure i

Note that the two rules can be added to the same project independently, so realizing requirement #4 (Parallel development). More generally, parallel work also on rules of the same model transformation is fostered by the blackboard structure of the Rule Engine: rules fired by the Scheduler produce independent outputs, which are merged by the Reducer based on simple configurable policies. This organization minimizes the coupling between rules and simplifies the control flow of the transformation. Finally, the design, implementation and debugging of model transformation rules does not require a visual model editor, because all inputs and outputs are (manually editable) JSON objects.

More examples of transformation rules are reported Sect. 3.6, where we describe how we validated ALMOsT.js in a real world project.

3.5 Model Editor

The starting point of the MDD practices is model editing, which can be useful also in absence of code generation, e.g., for documentation. We decided not to tie ALMOsT.js to a specific editor, but to make the architecture easily integrated with any editor of choice, provided that it respects the technical requirements of being executable in the browser and produce and consume JSON objects. In the case study of Sect. 3.6, the Model Editor is built on top of the JointJS diagram library. It manages models in the format compliant to the specifications illustrated in Sect. 3.3; inside the editor, model objects are enriched with metadata in order to fit JointJS internal representation requirements. Developers can customize the appearance and behavior of both types of elements managed by the Model Editor, entities and links. The introduction of a new element in the editor requires different workflows for entities and links.

For entity-type elements, customization typically requires to:

  1. 1.

    Define the graphical representation of the element (in the popular SVG format).

  2. 2.

    Define the element type and register it in the list of available types.

  3. 3.

    (optional) Define the editable attributes.

  4. 4.

    (optional) Define its list of valid super- and sub-element types.

  5. 5.

    (optional) Define the default outgoing link type and constraints.

For link-type elements:

  1. 1.

    Define the graphical representation of the link.

  2. 2.

    Define and register the link type.

  3. 3.

    (optional) Define the editable attributes.

  4. 4.

    (optional) Define the valid source and target element types.

All the above customization aspects are specified declaratively, without programming. Following the philosophy of ALMOsT.js, developers are free to maintain a 1 to 1 relation between graphical elements in the editor and elements in data the model, or specify a custom mapping rule.

3.6 Case Study: IFMLEdit.org

ALMOsT.js has been applied to the construction of IFMLEdit.orgFootnote 4, a browser-based tool that allows developers to model, analyze and rapidly prototype Web and mobile applications, following the MDD paradigm with the OMG Interaction Flow Modeling Language [24]. The purpose of the project is many-fold: (1) foster the adoption of MDD and IFML by offering an open source, free online tool whereby developers can quickly familiarize with the methodology and standard. (2) Implement the mapping from IFML to a formal language (namely Place Chart Nets [20]), to study in-depth the semantics of the language and thus support the development of other code generation tools and the portability of projects across tools; (3) offer to students of web engineering courses a simple environment for the hands-on experimentation with the main practices of MDD.

At the core of IFMLedit.org there are three different model transformations: a model to model transformation from IFML to PCN, for supporting semantic analysis, and two model to text transformations, respectively implementing code generation for the Web and for the Cordova cross-platform mobile environment.

The Data Model of IFMLEdit.org comprises five types of elements corresponding to the core concepts of IFML: ViewContainer, ViewComponent, Event, NavigationFlow and DataFlow, and two super-types: ViewElement which comprises ViewContainers and ViewComponents and Flow which comprises NavigationFlows and DataFlows.

The Data Model also comprises three types of relations: hierarchy, source and target, equipped with helper functions for easing model navigation in rules: hierarchy is navigable through getParent and getChildren, source is navigable through getSource and getOutbounds and target is navigable through getTarget and getInbounds. Other custom helper functions facilitate graph traversal by rules; examples are getAncestors and getDescendants, which support the traversal of trees of hierarchy relations.

Model to Model Transformation. IFMLEdit.org allows tool builders to analyze and simulate the semantics of their models, thanks to a set of mapping rules from IFML to PCN implemented with ALMOsT.js. Figure 2 shows the input IFML model (left) and the corresponding output PCN model (right), generated by the transformation rules. The PCN diagram expresses formally the dynamics of the application interface specified by the IFML diagram, using the classic concepts of Petri Nets, i.e., places, transitions, arcs and tokensFootnote 5.

Fig. 2.
figure 2

IFML (left) to PCN (right) transformation

Full size image

Each rule of the model to model transformation is responsible of generating a part of the PCN diagram and thus creates an output object with a single member called model, following the structure presented in Sect. 3.3 (i.e., possessing only the two elements and relations members). The Reducer is configured so to concatenate the list of elements and relations generated by the rules.

Overall, the transformation from IFML to PCN consists of 19 rules, which address all the aspects of the language.

Model to Text Transformations. To support requirement #5 (Customized Output), IFMLEdit.org allows the developer to simulate in the browser or download the modeled application. This function has required two model to text transformations for generating the Web and mobile code. For brevity, we illustrate only the Web version (the mobile transformation rules are quite similar).

Fig. 3.
figure 3

IFML (left) to Web Code (right) transformation

Full size image

The output of the model to text (for the web) transformation is a Node.js project following the MVC design pattern. The generated project can be run inside the browserFootnote 6, as shown in Fig. 3 or executed at the server side; the output artifacts are organized in a file system like structure and compressed after the execution of the transformation rules into a zip file, to facilitate download and installation.

Each model to text rule generates a subset of the folders and files that constitute the project. Model rules generate constant folders and files (e.g., system folders, configurations files, HTTP server initialization scripts, etc.) and textual files containing sample data collections for filling the interface with content (repositories). Each element rule generates the source code of a controller (JavaScript code) and of a view (Pug template). The following piece of JSON shows the output of a model to text rule that creates a package folder inside the project folder, and inserts in it the source code corresponding to some matched input element (for example, the source code of a Pug view, if the marched input element is an IFML ViewContainer of ViewComponent).

figure j

The Reducer is configured to concatenate the property values of each output object. In this way, for example, each model to text rule can simply generate code dealing with a specific aspect of the matched element (e.g., Java code or JSON configuration) as a value of the children property of the folder that must contain it, without worrying about other aspects treated by distinct rules. The concat aggregation policy of the Reducer takes care of collecting all the produced source files under the appropriate folder.

The model to text transformations consist of 22 rules, 12 for the web and 10 for the mobile platform.

3.7 Extending ALMOsT.js

To support requirement #6 (Custom generation), ALMOsT.js can be extended in a variety of ways. The Model Extender component, shown in Fig. 1, can be optionally used to enrich the Data Model, described in Sect. 3.3, with custom utility functions that facilitate rule implementation. Template engines like EJSFootnote 7 or PugFootnote 8 (formerly known as Jade) can be easily incorporated in the action part of model to text rules. This facility supports: requirement #2 (No new language), because developers can reuse their favorite web platforms; requirement #4 (Parallel development) because graph walking algorithms are separated from actual code generation; and requirement #6 (Custom generation), because rules can use different output standards adopting the most appropriate frameworks, libraries, web languages or platforms.

3.8 Discussion and Limitations

The experience of implementing IFMLEdit.org demonstrated the suitability of ALMOsT.js in an agile MDD context. The case study addressed an already existing MDD language (IFML), but we deem that the lessons learned apply also to the case in which the development team designs its own domain specific abstractions and generation rules.

The development of the IFMLEdit.org project followed a SCRUM iterative cycle. The element of IFML were added one at a time to the online tool, developing in parallel the Model Editor customization, the model to model rules, and the model to text rules.

The first sprint featured a zero application consisting of just an empty ViewContainer and was realized in 24 h. Each subsequent sprint added further language elements, in the following order: multiple ViewContainers, NavigationFlows between ViewContainers, Landmark ViewContainers, Nested AND ViewContainers, ViewComponents, NavigationFlows between ViewComponents, DataFlows, XOR ViewContainers, arbitrarily nested ViewContainers and Actions. Each sprint took on average less than 2 days to complete. The most complex sprint (adding arbitrarily nested AND and XOR ViewContainers) took 5 days, mostly allocated to the model to model transformation rules, which were necessary to sort out the innumerable semantic issues that arise with such an advanced design patterns.

However, the objective of simplicity, prominent for achieving agility of use, also implied trade-offs with respect to the expressive power and capabilities of the rule language and engine. In particular, the following limitations can be observed:

  1. 1.

    No advanced mechanisms are offered to exercise finer control over the execution of rules, such as execution priorities.

  2. 2.

    No higher order transformations are supported, because rules cannot match other rules but only model objects.

  3. 3.

    Rule modularization is not supported, because rules of the same transformation cannot be divided into packages, e.g., clustering rules according to different purposes. If a complex transformation has to be split into separated stages or focuses, it must be formulated as a set of sub-transformations.

4 Conclusions and Future Work

This paper presented ALMOsT.js, a framework for supporting MDD in agile methodologies. The design philosophy of the framework stemmed from 6 requirements, which could be summarized in one: keep it simple.

The usability of ALMOsT.js has been validated in the implementation of a complex MDD project, featuring one model to model transformation and two model to text transformations, applied to the full spectrum of features of a real-world MDA standard language (IFML).

The future work will focus on the experimentation and further assessment of ALMOsT.js in the industry, with two scenarios: companies that do not yet use MDD in their practices, to understand if the agile approach of ALMOsT.js lowers the reluctance of traditional developers towards modeling; companies already applying in-house domain specific models and code generation techniques, to understand the added value of ALMOsT.js lightweight, single-language approach and browser-based architecture. The second line of future work will address early-stage MDD education, where we will assess the impact of hands-on experimentation in introductory software engineering and web engineering courses at the Bachelor level.