Keywords

1 Introduction

Technological ecosystems are a set of software tools connected by information flows to provide new extra functionality than each tool separately and to support knowledge management processes inside any kind of institution [1]. Furthermore, these technological solutions have an important human factor represented through two input flows, the methodology and the management, not only by the users that use the ecosystem. Learning ecosystems are a kind of technological ecosystem focus on learning management both in companies and institutions.

This technological approach is the evolution of traditional information systems and offers advantages such as the ability to evolve in different dimensions [2, 3] or the reusing of heterogeneous tools already developed to build new systems. On the other hand, the definition, development and deployment of this type of software solutions is complex and involves several problems identified in previous works [4]. Based on this analysis, an architectural pattern has been defined [2] as an input to define a metamodel to support Model-Driven Development (MDD) of learning ecosystems. The basic idea of a metamodel is to identify the main concepts and their relations of a given problem domain used to describe the models of that domain [5].

The learning ecosystem metamodel [6] is a Platform-Independent Model (PIM) to define learning ecosystems based on Open Source software. It has been defined using the Model-Driven Architecture (MDA) proposed by the Object Management Group (OMG) to apply MDD using the OMG standards for visualizing, storing, and exchanging software designs and models [7]: Meta Object Facility (MOF), Unified Modeling Language (UML), XML Metadata Interchange (XMI) and Query/View/Transformation (QVT). The ecosystem metamodel is a M2-model in the four–layer metamodel architecture; it is an instance of the Meta Object Facility (MOF).

The validation of the metamodel has been carried out through the instantiation of conceptual models of learning ecosystems. Two Model-to-Model (M2M) transformations have been made in previous works to test that the metamodel allows to define a real learning ecosystem. In particular, the models instantiated from the learning ecosystem metamodel are learning ecosystems for knowledge management in two different contexts, PhD Programmes with an Open Access policy [8] and the Spanish Public Administration [2]. Both models fulfil the metamodel constraints verified from a theoretical point of view. These preliminary validations are available in [9, 10].

To complete the validation process is necessary verify that the instances of the learning ecosystem metamodel are reciprocated to the deployment of the learning ecosystem in a real context, in other words, it is necessary to transform the PIM model of a learning ecosystem in a PSM (Platform Specific Model) model. To ensure the validity of the process, the transformations should be done using a tool, not manually.

Although OMG provides several standards to support MDA, there are no stable tools to support the definition and mapping of metamodels and models using those standards. However, Eclipse has Eclipse Modelling Project (EMF), a set of Eclipse plugins that provide a framework to develop metamodels using Ecore and to support automatic Model-to-Model and Model-to-Text transformation through the definition of transformation rules. Ecore [11] is a meta-metamodel based on MOF focused on being simpler and more practical. Further, the designers of Ecore have participated in the definition of the core of MOF 2.0, Essential MOF or EMOF, so both are very similar. For this reason, the last phase of the validation process will be developed using EMF.

The main purpose of this work is to ensure the quality of the learning ecosystem metamodel. More specifically, the objectives are to describe the transformation of the learning ecosystem metamodel from MOF to Ecore in order to use the tools provided by EMF, and to apply a quality framework to both MOF and Ecore version.

The paper has been organized in the following way. Section 2 describes the methodology used to transform the metamodel from MOF to Ecore. Section 3 describe the transformation of the learning ecosystem metamodel and the differences between both versions. Section 4 analyses the quality of the learning ecosystem metamodel both MOF and Ecore. Finally, Sect. 5 summarizes the main conclusions of this work.

2 Methodology

In order to guarantee the quality of the learning ecosystem metamodel, a series of analysis and transformations have been performed. First, the metamodel instantiated from MOF has been analysed following the quality framework provided by López-Fernández et al. [12]. The objective has been to recognise the quality problems of the metamodel to solve them in the Ecore version.

After the analysis, the learning ecosystem metamodel in MOF has been transformed in an instance of Ecore. Both metamodels are M2-model in the four-layer metamodel architecture provided by MDA (Fig. 1). Both MOF and Ecore support the use of XMI enabling the interchange of models, and model instances through XML based on DTDs/XML schemas generated from the corresponding models [13]. However, in this work the transformation has been made manually because of several problems with the tool used to define the metamodel in MOF. This one was made with a UML class diagram in Visual Paradigm and it has not been possible to import it into Eclipse using XML Metadata Interchange (XMI). The instance of Ecore has been made using the Graphical Modelling for Ecore included in EMF.

Fig. 1.
figure 1

Different abstraction levels of the learning ecosystem metamodel

Full size image

The first version of the metamodel has a set of constraints defined with Object Constraint Language (OCL) and included in the metamodel as annotations. During the transformation process, these constraints have been reviewed and finally twelve constraints have been included in the Ecore metamodel. Moreover, the constraints in the Ecore metamodel are included in each element using the OCLinEditor provided by EMF.

Finally, the quality of the learning ecosystem metamodel instantiated from Ecore has been checked. It has been used the same metamodel quality framework than in the MOF version.

3 Learning Ecosystem Metamodel

The first version of the learning ecosystem metamodel instantiated from MOF is published in García-Holgado and García-Peñalvo [6] and is available in high resolution in http://doi.org/10.5281/zenodo.829859.

This section describes the mapping between the MOF version of the metamodel to an instance of Ecore, as well as a set of improvements to ensure the quality of the learning ecosystems instantiated from the final version of the metamodel.

3.1 Ecore Metamodel

The transformation from MOF to Ecore has made manually. To prevent confusion, this work uses the “MOF” prefix for concepts in MOF and the “E” prefix for concepts in Ecore.

First, each MOFClass has been mapped in a EClass and three new classes have been defined. On the one hand, two children have been added to the hierarchy of Infrastructure: IndexingService element was detected during the preliminary validation when the metamodel was instantiated in the learning ecosystem for knowledge management in the Spanish Public Administration; and OtherSystemTool replaces the MOFClass “…” because ellipsis are forbidden symbols in EClass names. On the other hand, the MOFClass InformationFlow has been divided in two EClasses, one with the same name that represents the communication between software tools either through human interaction or through the development of software mechanisms; and one for representing the implementation of the information flow, CommunicationMechanism.

Secondly, each MOFAttribute has been mapped in a EAttribute. In this process, some new EAttributes have been defined in order to fulfil one of the EMF best practices, all classes must have a unique identifier attribute. Specifically, a EAttribute name or title has been added to: InformationFlow, CommunicationMechanism, ServiceInterface and ServiceOperation.

Moreover, other EAttributes have been included to have the required information to transform PIM models to PSM models. In particular, ExternalTool has two new EAttributes of type EString related to the connection between the ecosystem and the external tool (id, key); InternalTool has three new EAttributes of type EBoolean to determine some features related to information needs - complexity of the contents (complexContentType), use of questionnaires or surveys (questionnaire) and use for teaching (teaching) -; and User has a new EAttribute to distinguish his/her role in the institution, a EAttribute of a EEnum defined in the metamodel, userType.

Finally, each MOFAssociation has been mapped in a EReference. This process has been more difficult because in the learning ecosystem metamodel the MOFAssociations had not defined the navigability. Instead, Ecore support uni-directional and bi-directional references and it is mandatory define the navigability and a unique name for each EReference. Also, the upper and lower bounds of EReferences have been reviewed and some changes have been made: the lower bound of the EReference configConsumer is 0 instead 1; and the lower bound of the EReference establishedMethodology is 0 instead 1.

Figure 2 show the result of the mapping process from MOF to Ecore and the changes made to support the M2M transformations in EMF. The final version of the learning ecosystem metamodel in Ecore is available in high resolution on the following link https://doi.org/10.5281/zenodo.1066369.

Fig. 2.
figure 2

Learning ecosystem metamodel in Ecore

Full size image

3.2 OCL Constraints

The MOF version of the learning ecosystem metamodel has four OCL constraints [6]. During the mapping from MOF to Ecore some new OCL constraints has been defined to guarantee the correct instantiation of the metamodel. In particular, eight new OCL constraints have been defined in the metamodel. Moreover, two constraints defined in the MOF metamodel have been modified.

The twelve constraints have been included in the Ecore metamodel using the OCLinEditor provided by EMF.

Regarding the modifications, the constraint to ensure the required components of a learning ecosystem has been changed to allow more than one monitorization tool, because sometimes there are several monitorization tools that are part of other components and combined provide the monitorization of the ecosystem.

figure a

An information flow always involves two different software tools, both for services and properties. The constraint for ensuring that a software tool cannot consume a service provided by itself has been redefined and a new constrain for properties has been defined.

figure b

Five of the new constraints are focused on the relationships among the components. First, a software tool cannot be contained itself directly or by transitivity:

figure c

An external tool cannot contain or be container of other software tools and a data repository cannot be a component of other software tool:

figure d

Finally, when a software tool consumes a service or a property must be at least an information flow between it and the service or property provider:

figure e

4 Quality of the Metamodel

The quality of the learning ecosystem metamodel has been checked using the metamodel quality framework proposed by López-Fernández et al. [12]. This framework is composed by thirty features that metamodels should follow (Table 1). The features are divided in four categories: (1) design, properties signalling a faulty design (an error); (2) best practices, basic design quality guidelines (a warning); (3) naming conventions, questions related to the use of verbs, nouns, etc.); (4) metrics, measurements of metamodel elements and their threshold value [14].

Table 1. Features of the metamodel quality framework [12]
Full size table

The first version of the metamodel did not comply the features D03 and BP03. The MOF version of the metamodel has an abstract class, InformationFlow, that was a superclass of only one class, Service. In the Ecore version of the metamodel, in order to comply the feature D03, the Property class has been included in the hierarchy of InformationFlow. Furthermore, the InformationFlow class has been divided in two classes, one with the same name that represent the communication between two tools and another one named CommunicationMechanism to describe the software mechanism used to establish that communication, in case there was.

Regarding the feature BP03, there is a class in the metamodel in MOF, Ecosystem, that contains all classes except two, Property and InformationFlow. The Ecore version of the metamodel has two new composition associations, one between the root class and InformationFlow, and other between the root class and the new class CommunicationMechanism.

The learning ecosystem metamodel instantiated from Ecore (Fig. 2) fulfils with the thirty features that compose the framework. Highlight the metrics:

  • M01. Maximum number of attributes in a class of the metamodel is 4.

  • M02. The classes with more references to others are InformationFlow, SoftwareTool and Ecosystem with a Ce value of 3.

  • M03. The classes more referred from others are InformationFlow with a Ca value of 4, and SoftwareTool and Objective with a Ca value of 3.

  • M04. The deepest hierarchy has a DIT value of 4, where the root class is Component.

  • M05. The class with more children is Infrastructure with a NOC value of 5.

5 Conclusions

The learning ecosystem metamodel is a M2-model in the four-layer metamodel architecture provided by MDA. The main objective of this metamodel is to provide a Computing Independent Model (CIM) for describing learning ecosystems building from software components, human elements and information flows between them.

The validation of the metamodel is necessary to provide a robust solution for the development of this type of technological solutions. In previous works a first phase has been carried out; two M2M transformations have been made to test that the metamodel allows to define real learning ecosystems. These preliminary validations have been made manually because there are no stable tools that support the standards defined by OMG.

The transformation from MOF to Ecore of the learning ecosystem metamodel represents an important step in the validation process because of the Ecore version can be an input in the different modelling tools provided by Eclipse. Furthermore, the metamodel instantiated from Ecore (Fig. 1) is a quality metamodel according to the quality framework proposed by López-Fernández et al. [12].

In future works the validation process will be completed defining a set of transformation rules to transform a PIM model instantiated from the learning ecosystem metamodel to a PSM model that represent the deployment of the learning ecosystem in a real context.