1 Introduction

The technological ecosystems are the evolution of the traditional information systems. They provide support to information and knowledge management in heterogeneous environments [1, 2]. The learning ecosystems are a type of technological ecosystems focus on learning management processes.

The metaphor of technological ecosystem transfers the main properties of biological or natural ecosystems to the technological area. The organisms of the natural ecosystems are the users and the software components from a technological point of view; the relationships among the organisms are the information flows between the components; and the physical environment are the mechanism to stablish and support such flows [3]. This relationship between technology and nature appears in many authors that provide their own definitions of technological ecosystems, also called Software ECOsystems (SECO) [4,5,6,7,8,9].

Technological ecosystems should connect and relate the different tools and services that arise and serve for the knowledge management, building technological ecosystems, increasingly complex internally, from the semantic interoperability of its components to transparently provide more functionality and simplicity to its users [10].

One of the main problems to define and develop technological ecosystems, particularly learning ecosystems, is the need to adapt them to the natural evolution of the companies and institutions. A technological ecosystem should adapt to different contexts or domains, i.e. it should be transferable between different domains.

Currently, the development of a learning ecosystem is influenced by many factors, both internal and external. Although the main goals are the same, the software components and information flows can change even in the same entity. Each new ecosystem or the transfer of an existing one involves carrying out a large number of ad-hoc developments.

Within the Research Group in InterAction and eLearning (GRIAL) of the University of Salamanca, the authors have participated in the development of several learning ecosystems in different contexts to solve real problems [11,12,13,14]. Moreover, they have transferred the same learning ecosystem, specifically a learning ecosystem for knowledge management in a PhD Program [15], to different domains.

To improve the definition and development of learning ecosystems, it is needed to provide a platform-independent solution. The main objective of this paper is to define a metamodel for developing learning ecosystems following the Model-Driven Architecture (MDA) proposed by the Object Management Group (OMG).

The paper has the following structure: Sect. 2 describes the methodology used to formalize the metamodel proposal. Section 3 sets the high-level requirements for the learning ecosystems development. Section 4 describes the metamodel as a M2-level model in OMG four-layer metamodel architecture. In Sect. 5 a real learning ecosystem is modelled using the Ecosystems Metamodel. Finally, Sect. 6 summarizes the main conclusions from this study.

2 Methodology

Model-Driven Architecture provides a framework for software development that uses models to describe the system to be built [16]. It allows to separate the data and operations specification of the system from the details of the platform or platforms on which it will be built. MDA is the proposal of the Object Management Group to apply Model Driven Development (MDD) using the OMG standards for visualizing, storing, and exchanging software designs and models [17]: Meta Object Facility (MOF), Unified Modeling Language (UML), XML Metadata Interchange (XMI) and Query/View/Transformation (QVT).

In this work, the MDA is used as guidelines to define learning ecosystems using high-level conceptual models, platform-independent models (PIM). These models can later be translated to concrete executable specifications or code using standard-mappings. This is performed according the OMG four-layer metamodel architecture. In this architecture, a model at one layer is used to specify models in the layer below [18]. The four layers are the meta-metamodel layer (M3), the metamodel layer (M2), the user model layer (M1) and the user object layer (M0).

The Ecosystems Metamodel is an instantiation of the meta-metamodel layer using MOF language, the abstract language used to describe MOF metamodel.

3 High-Level Requirements

The main problems associated with the definition and development of learning ecosystems have been identified in a previous work through a comparative analysis of the Strengths, Weaknesses, Opportunities and Threats (SWOT) of several real case studies developed in different contexts [19]. Based on this analysis, the identified problems were modelled with Business Process Model and Notation (BPMN) to provide a high abstraction level of the main problems in learning ecosystems and define an architectural pattern to resolve them during the definition phase [20].

Learning ecosystems modeling involves the proposed architectural pattern, a pattern based on the Layers pattern defined by Buschmann [21] with a top-down scheme composed of four layers. Modelling of learning ecosystems must be supported by a formal Ecosystems Metamodel. This metamodel is not focus on capturing the requirements related to the software or human components of the ecosystem. The components are black boxes; the Ecosystems Metamodel does not enable capture of the description of a specific component because of learning ecosystems are based on connect or adapt existing components. The metamodel should enable capture of a small set of modeling elements to define the relationships among components.

The high-level requirements for ecosystems metamodel are the following:

  • The metamodel shall enable capture of the high-level description of the learning ecosystem components.

  • The metamodel shall enable capture of the human factor as part of the learning ecosystem.

  • The metamodel shall enable capture of the information flows between the learning ecosystem components.

  • The metamodel shall enable capture of the configurations of the software components.

4 Ecosystems Metamodel

In this section, the formal semantics of the Ecosystems Metamodel is described. The metamodel is a M2-level model in the four-layer metamodel architecture. The Ecosystems Metamodel is an instance of the MOF meta-metamodel (M3-level model) (Fig. 1).

Fig. 1.
figure 1

Model layers. The meta-metamodel layer, M3, and the metamodel layer, M2.

Full size image

The Ecosystems Metamodel defines an ecosystem following the architectural pattern proposed in a previous work [20]. The pattern is composed by four layers – presentation, services, static data management and infrastructure – and two input streams which introduce the human factor as a key element. Also, the pattern provides a set of software components that should be part of a learning ecosystem to resolve some problems of this kind of technological solutions. The layers and the components proposed are reflected in the metamodel.

An ecosystem is made up of a collection of two type of components, software tools and people. Both components are abstract classes that inherit from a root class named Component. The software tools are organized in a hierarchical structure that provides three layers of the pattern: the service layer through Tool class; the static data management layer with the DataRepository class; and the infrastructure layer through a class with the same name. The authors have decided that the presentation layer is not part of the metamodel due to the interfaces of the software components are closely related to the technology used in each component.

Moreover, the ecosystem can be composed by software tools that contains others ones, this is modeled with a recursive association in SoftwareTool class.

The set of software components are part of the hierarchy describe above. MailServer, Monitorization and UserManagement inherit from Infrastructure class. Moreover, other child classes can be defined from Infrastructure.

Regarding the tools in the service layer, these are modeled as child classes of the Tool class, InternalTool and ExternalTool.

The human factor is modeled through Management, Methodology and User classes. User performs management and establishes one or more methodologies. Moreover, the Management is composed by zero or more objectives modeled by the Objective class.

These objectives are the key element to define the information flows. An InformationFlow is an abstract root class that establishes a relationship between two SoftwareTool instances. The information flows are based on services. This requirement is modeled through a leaf class, Service. The four classes related to the services are a very simplified version of the service capability view of the services metamodel proposed by Jegadeesan and Balasubramaniam [22]. ServiceDescription has a semantic description of the service and also includes the endpoint of the service. ServiceInterface represents the underlying capabilities brought to bear by a service. ServiceOperation represents an underlying capability and allows modeling event-driven scenarios using the isNotification and isListener attributes.

Finally, the Property class provide the semantic to model the configuration provided by some software components and used by another. This part of the metamodel complements the information flows to establish different relationship levels among the components.

The metamodel proposed in the Fig. 2 is completed with a set of constraints defined with Object Constraint Language (OCL).

Fig. 2.
figure 2

Ecosystems metamodel

Full size image

An ecosystem must have one mail server, one monitorization system, one user management system, and at least one internal tool, one management input stream, one methodology input stream and one user:

The value of the endpoint attribute defined in the service descriptions should be unique in the whole ecosystem:

A software tool cannot consume a service provided by itself, that is to say, the information flows always involve two different software tools:

The mail server must provide at least one property:

5 Modeling the Ecosystem for Scientific Knowledge Management in a PhD Program

The learning ecosystem modeled from the Ecosystems Metamodel is oriented to manage the scientific knowledge generated in the scope of the PhD Program on Education in the Knowledge Society at the University of Salamanca (https://knowledgesociety.usal.es). This ecosystem is described by García-Holgado, García-Peñalvo and Rodríguez Conde [15].

This learning ecosystem is composed by three elements in the infrastructure layer: (1) a mail server provided by the University of Salamanca; (2) a user management tool that is part of a component located in the service layer, the portal; (3) and a monitorization tool that is also part of the portal.

The static data management layer is provided by the institutional repository of the University of Salamanca.

Finally, the service layer has a main component, a user-centered portal which provides most features required by the business logic; and a set of external tools focused on the dissemination of the scientific knowledge in different social networks (Twitter, YouTube, SlideShare and Facebook) and sending bulk emails (Mailchimp).

The model (M1-level) has been divided in three packages: the ecosystem tools model; the ecosystem users model; and the ecosystem services model. Furthermore, the classes from the metamodel (M2-level) are represented to indicate which classes are used to model the example.

In Fig. 3, the main software components of the learning ecosystem are modeled. The PhDEcosystem is composed by: a GmailSmtpServer, modeled using the MailServer class; the InstitutionalRepository that instances the DataRepository class; the PhDPortal which contains the PortalUserManagement and the PortalMonitorization, instances of InternalTool, UserManagement and Monitorization, respectively; and a set of modeled elements using the ExternalTool class.

Fig. 3.
figure 3

Ecosystem tools model

Full size image

The human factor is represented by the Academic Committee that is in charge of the management of the PhD Program, including the learning ecosystem. And a Quality Committee that provide the methodology to ensure the quality of the Program and the learning ecosystem.

In Fig. 4, the human factor is modeled. The AcademicCommittee performs the PhDGuidelines and the PhDProcedures, both modeled using the Management class. The QualityCommittee establishes the QualityPlan modeled using the Methodology class. The PhDProcedures provides a set of objectives, that are involved in the modeling of the information flows.

Fig. 4.
figure 4

Ecosystem users model

Full size image

Finally, the information flows of the learning ecosystem are modeled in the Fig. 5. The relationships among the components are supported by several services to achieve the objectives (PublishEvidences, DiseminateActivities and GetEvaluationIndicators) that are part of the PhDProcedures in Fig. 4. Each service is modeled using Service class and involves two instances of SoftwareTool.

Fig. 5.
figure 5

Ecosystem services model

Full size image

The PublicationService is provided by InstitutionalRepository and it is consumed by PhDPortal to support the PublishEvidences objective. The AutopostService is provided by two instances of ExternalTool, FacebookProfile and TwitterProfile to support the DiseminateActivities objective. And the IndicatorsService is defined by the GetEvaluationIndicators objective and involves PhDPortal and PortalMonitorization.

It should be noted that the PhDPortal consumes two services and provides another. Also, there is a service, AutopostService, composed by two instances of ServiceDescription, AutopostFbServiceDescription and AutopostTwitterServiceDescription.

6 Conclusions

This paper presents an ecosystems metamodel based on MOF to model different perspectives of learning ecosystems development. The metamodel have been used to model a real learning ecosystem for a PhD Program, which have been transferred to other domains. The modelling example demonstrate how a real ecosystem could be modeled using the Ecosystems Metamodel.

This work provides a base to define a UML profile for the Ecosystems Metamodel in order to leverage existing tool support. Furthermore, a set of transformation rules using QVT could be defined to transform the models into executable specifications to provide an ecosystem prototype.