Requirements for modelling tools for teaching

The purpose of the 1-day working session at MODELS 2023 was to engage in productive discussions regarding the requirements and necessary infrastructure for MTTs. Targeted invitations were sent to research groups actively involved in developing tools used for teaching computer science in undergraduate or graduate classes.

In the first session, participants were allotted five minutes each to present the MTTs they were working on, focussing on their teaching-related aspects. Subsequent sessions, attended by an average of 25 people, were dedicated to brainstorming among attendees.

At the conclusion of the workshop, all participants were surveyed regarding their perceptions of the importance of tools, languages, features, and educational practices discussed earlier. The survey aimed to serve as a prototype for wider circulation within the community. Despite being produced within a half-hour timeframe, the survey yielded valuable insights:Post-workshop, reflection on the prototype survey results led to the revision of questions and the preparation of a formal survey for broader circulation, as discussed in the following section.

A subgroup of the authors refined the pilot survey² over the course of 3 months following the workshop. Ethics approval was obtained to circulate the revised survey by the end of January 2024. Targeted sampling methods were employed for distributing the survey using the following steps: By the end of February 2024, we had gathered 59 valid responses. Only one response was excluded due to incomplete answers to the questions. Given the richness and depth of the data collected, we have decided to publish a comprehensive analysis in a separate paper. In that paper, we will first present the detailed questions of the survey as described in Table 1, followed by the main insights obtained from the responses. Here, we provide a brief characterisation of survey respondents and then focus on some central themes.

We asked about the participant’s general background and demographics:Question 5 was an open-ended question about areas of modelling that could be improved and features that were required. The respondents identified several areas for improvement in software modelling tools for teaching, including various user experience issues, collaborative editing support, executability, support for modelling for particular architectures or frameworks, analysis capabilities, a strong preference for a web-based interface, and concern about outdated tools, standards, and languages. Many of these will be discussed in detail in the remainder of the paper.

The responses to Question 6 on the importance of teaching certain modelling languages are presented in Sect. 3.1.1.

Questions 7 through 13 ask about the significance of 50 distinct qualities and features within the realm of modelling tools and languages, in the context of teaching modelling. Each item was subject to assessment on a six-point scale, where respondents were tasked to rating their perceived importance.

The scale encompassed the following criteria:This evaluation framework aimed to discern the varying degrees of importance attributed to each quality and feature, thereby facilitating a nuanced understanding of their relevance in the context of teaching modelling. We will discuss the responses to these questions in Sect. 7 after we have qualitatively reported on the workshop discussion that introduced these requirements.

Question 14 asked about code generation, and what programming languages a tool should support. We will discuss these responses in more detail in Sect. 3.1.5.

Question 15 asked about teaching practices that should be supported (multiple responses were possible). The most important practices to be supported include having students build small models (97 per cent need this); using the tool live in class (81 per cent); supporting project-based learning (80 per cent); supporting problem-based learning (75 per cent); having students analyse and criticise models (75 per cent); and having students improve an existing model (71 per cent).

In Question 16, we asked about the tools respondents use in teaching modelling. The top modelling tools or tool types used by the participants were PlantUML, EMF/Ecore/Emfatic, plain drawing tools (such as Draw.io), Visual Paradigm, XText, Umple, formal methods tools, MagicDraw, Figma, Papyrus, and Sirius.

In this section, we present requirements on MTTs related to teaching modelling with existing modelling languages.

In this section, we collect requirements on MTTs used for teaching students how to develop new modelling languages. Tools for the development of modelling languages are typically called Language Workbenches.

Ensuring accessibility and quality of learning for a diverse audience necessitates the widespread utilisation of open educational resources (OER) [36, 57, 76] in all educational endeavours. In this context, the education system has used competences to organise learning and quantify personal and professional growth. Proficiency levels categorising competence items enhance the assessment process, providing valuable insights into individual mastery.

To fortify this educational approach, there is a need to align with the competencies and skills elaborated in the most recent Computing Curricula of the ACM [18], but also with established models like O*NET,⁴ ESCO,⁵ and EntreComp,⁶ ensuring that skill development resonates with industry standards. Competences, conceptualised as sets of interconnected concepts, encapsulate knowledge, principles, and practices crucial for achieving learning goals. The compilation of these elements in the competence portfolio offers a structured overview of skills, knowledge, and aspirations, guiding students through competence requirements and acquired competences, where teachers play a central role in ensuring a logical progression.

To this end, teachers define learning paths, segmenting them into focussed learning fragments centred on specific topics. These fragments, supported by associated learning activities, orchestrate a guided process facilitated by the progress edges. The progress edge introduces multiple outcomes from each learning activity, creating a dynamic learning experience that fosters personalised learning through diverse outcomes, tailored paths, adaptive feedback, learning flexibility, and heightened motivation.

As suggested in [3], external tools, such as MTTs, should be integrated with traditional virtual learning environments (VLEs) to maximise the benefits for students and educators. This will enable the utilisation of common VLE provisions such as collaboration, communication, assessment, and feedback structures that have been proven necessary, effective, and pedagogically sound [17]. This will provide seamless integration within the students’ environments and a more connected and insightful learning experience. Additionally, it not only makes learning more accessible, but also allows us to gather valuable information about how students interact with these tools. By collecting learning analytics [70] through these tools, educators can understand each student’s progress, tailoring support to individual needs and facilitating further the individual learning paths. In essence, the integration of modelling tools into VLEs supports a personalised educational journey that incorporates familiar proven pedagogical methods.

We first discuss requirements from a teacher perspective.

Next, we discuss requirements specifically to support students.

To allow them to focus on the actual modelling activity, students should be able to use modelling tools without the need for installation or complex plugin management. Web-based, playground-style solutions (like the Epsilon Playground⁷ or  [5]) may be one approach here, but alternative options (e.g. integration into common platforms like VS Code) may also be appropriate.

Students use many different computing platforms, and it is essential that the modelling tools used in teaching are available across these platforms and do not significantly change the way they work when switching between platforms.

Platform independence especially concerns both the modelling artefacts and the user interface. Regarding the former, models cannot break or deviate in their behaviour when working on different platforms. Regarding the latter, it is important that demonstrations of teachers or teaching assistants can be directly reproduced by students, independent of, for example, their operating system.

Students have many demands on their time and will rarely be able to complete an activity in one sitting.

It is, therefore, essential that educational modelling tools provide easy ways of saving intermediary model states and continuing from such a saved state at a later time. Saving can be internal to the tool (e.g. to an internal database) or can be to an external file. Importantly, it must be possible to export work in a format that is appropriate for submission of assignments (or to submit directly from within the tool if more appropriate). This includes simple choices such as ensuring no absolute paths are used in exported files.

Teachers can have different requirements depending on a number of factors, including the extent to which the tool will be used to support learning and assessment activities within the course and the available technical skills and infrastructure.

Teachers who plan to use the tool extensively in their course and who have technical skills and resources may like to deploy a version of the tool (e.g. through a Docker image) on local resources. This allows them to control when to upgrade to the next version of the tool, to patch/work around any identified issues with the tool, and to shield students from unexpected events. On the other hand, teachers who only plan to use the tool for a small, non-critical part of their course are likely to prefer a ready-to-use public instance (like those offered by the Epsilon Playground and UmpleOnline [49]). In this case, teachers may require configuring the tool with custom examples (e.g. metamodels, grammars, models, model management programs) to better integrate with the rest of the teaching material (e.g. example systems/domains discussed in lectures). Ideally, doing so should not require teachers to install an instance of the tool on their own resources; publicly available instances should provide built-in support for this. The Epsilon Playground, for example, allows users to configure its set of examples by specifying the location of a JSON document as a URL parameter.⁸ Finally, students should be able to share their work with teachers (e.g. by generating and sharing a unique URL as is the case with the Epsilon Playground) and teachers must be able to export their students’ work and persist them in a standard format to carry out further activities (e.g. inspection, marking).

MTTs should demonstrate common characteristics of well-engineered community-driven software to facilitate adoption and continued development. The implementation should be accompanied by tests that demonstrate the correct behaviour of the tool and protect it against regressions. The architecture and code should be modular, to allow adopters to add/disable components and services. The code should be implemented using languages and frameworks that have a substantial user basis to facilitate long-term maintenance. Finally, the use of a permissive open-source licence is necessary to facilitate contributions by the community.

Umple [49] is an open-source modelling language and technology designed to improve both education about modelling and open-source development with models. Umple’s textual syntax (cf. Sect. 3.1.2) incorporates a variety of model types including class models, state machines, and feature models. Most graphical representations can also be edited, with the edits instantly reflected in the text. Umple generates code from all its modelling constructs, enabling model-driven design of complete systems (cf. Sect. 3.1.5). Where needed, user-defined code in traditional programming languages including Java, PHP, and Python is embedded in the same files as the textual models. The result is a textual format that resembles what students would be used to, given their experience with any other compiler.

To make it clear to students that serious systems can be built with models, an extensive online user manual and set of examples are available. Students also see the write-compile-execute-repeat cycle and experience satisfaction when they get a system working that is built from models.

A key feature of Umple is its extensive automatic analysis of model consistency (cf. Sect. 3.1.3). Several hundred error messages and warnings are produced regarding issues Umple detects in models. Each error or warning also has its own dedicated manual page, with live examples showing how to correct errors.

TouchCORE is an academic modelling tool that focuses on model reuse following the Concern-Oriented Reuse approach. TouchCORE currently supports several standard modelling notations, such as class diagrams, sequence diagrams, and use case diagrams. It is also possible to define new domain-specific languages and augment them with concern-oriented capabilities by integrating them into TouchCORE using a plugin mechanism.

In addition to the language metamodel, a language definition in CORE requires the language designer to specify a set of language actions that define the construction semantics. The actions encapsulate complete editing steps that are used by the modeller when elaborating a model using the language. In other words, the language actions constitute the API for building models with the language.

On top of the language actions, TouchCORE provides the notion of a perspective [4], which allows a modeller to group a set of language actions and make them available to the user for creating models for a specific purpose. For example, a user can select the Domain Modelling perspective, which then opens the class diagram editor, but is configured in such a way that it shields the user from the full power of UML class diagrams (cf. Sect. 4.4.2). In the Domain Modelling perspective, it is not possible to create operations for classes, nor can one specify visibility for attributes or navigability of associations. On the other hand, if the user selects the Design Modelling perspective, then the creation of operations and specification of visibility and navigability is allowed. On the other hand, the use of association classes and n-ary associations (where n \(\ge \) 3) is disallowed.

In the world of programming languages, web-based playgrounds have been around for some time. One of the most well-known such environments is perhaps www.w3schools.com [62], which has been offering online training on the basics of a wide range of programming languages, web frameworks, etc., for a long time.

With playgrounds no software installation or configuration is required (cf. Sect. 5.1). All learning activities are accessible from within a web browser with no need for the student to install complicated tools or set up development environments. Furthermore, playgrounds are typically set up for specific activities and provide a bespoke, typically simplified user interface exposing only the minimal functionality required to support the activity (cf. Sect. 4.4.2). As a result, students can focus on the interactions required for the activity without distractions from tool or language complexity.

As a result of these benefits, playgrounds have been experimented with by MDE tool developers, primarily as a mechanism for enriching the online documentation of their tools. For example, the Epsilon Playground provides a range of examples for using the Epsilon toolkit [44]. Similarly, the Langium Playground⁹ allows experimentation with the Langium language workbench.

The MDENet education platform [5]¹⁰ generalises from these ideas and aims to develop a playground into which different MDE tools and techniques can be easily integrated. Technically derived from the Epsilon Playground, the platform introduces declarative specifications for learning activities and MDE tools. MDE tools are expected to be packaged as web services offering an API for running tool-specific actions (for example, a model-transformation tool would offer an API endpoint which can accept a model, metamodel, and transformation specification and return the transformed model). The platform then allows declarative activity specifications to draw on a whole range of tools available in this way and constructs a dedicated playground from each such specification. Activity specifications and the associated files can be stored in a GitHub repository, making them accessible to students, for example, via GitHub classroom and similar mechanisms. Students are even able to save back their progress via the platform (cf. Sect. 5.1), which will create a commit in the underlying repository (assuming the student has sufficient access rights).

Making activity specifications explicit as declarative models via the GitHub platform makes it possible for these to be shared and co-developed by different teachers, helping to address some of the requirements on teacher collaboration (cf. Sect. 4.3.4).

Students should be exposed to developing DSMLs using different modelling paradigms (cf. Sect. 3.2.1). AToMPM [74] is a web-based graphical modelling environment. Being bootstrapped, its editor is completely customizable, enabling teachers to adapt the tool for specific assignments. Focussing solely on graphical models, students define the concrete syntax of their DSML with SVG elements. As for the abstract syntax, students usually define it using the built-in UML class diagram; however, teachers can define other metamodelling languages (such as Entity-Relation) as well. AToMPM also enables the definition of the semantics of the DSL with rule-based model transformations. Students develop different algorithmic skills than needed when programming, being a declarative specification based on graph transformations. These transformations are mainly used to refactor, simulate, or analyse models. Using this tool, students can observe live animations of their model while running the transformation continuously or step-by-step.

The Eclipse Modelling Framework offers a variety of modelling tools that allow students to model both using a graphical or textual. However, Eclipse’s strength is mostly in the former. A prominent textual modelling is Xtext [29], a textual model editor generator. Using Xtext, students learn to define grammars as well as other core language engineering components such as validators, postprocessors, and textual styling. It is compatible with Xtend [28], a template-based code generation engine. This allows students to develop code generation skills from high-abstraction models targeting different programming languages and platforms. Within the Eclipse realm, they can also use the ATL [39] model-to-model transformation engine, specifically tailored to translate models across modelling languages. ATL transformations are developed with declarative rules augmented with OCL-like expressions.

Defining DSMLs with projectional language workbenches, like MPS, differs from the previous modelling paradigms when developing the concrete syntax of the language. In MPS, students define textual projections of their language. They then define a Java code generator to give the operational meaning to their language. Alternatively, Gentleman [46] is a web-based projectional editor generator where students develop and use DSMLs in a web browser. In this case, they define projections for each metamodel element in the form of a group of HTML widgets. Gentleman also supports graphical projections. Teachers can easily integrate the generated projectional editors into full-fledged web applications demonstrating to students how MDE technologies can be interleaved with programming technologies seamlessly.

As a plugin for the Papyrus modelling tool,¹¹ PapyGame aims to gamify the learning of modelling by integrating a game view within the Papyrus UML editor. This gamification (cf. Sect. 4.4.4) is made possible through the utilisation of a Gamification Engine, enabling the implementation of key gaming concepts associated with specific learning paths. The tool utilises a gamification design framework accessible through user interfaces in a web browser. This integration serves to enhance the learning experience for users, providing both effective and enjoyable ways to learn and practice modelling skills. For educators, PapyGame stands as a valuable asset to enrich their students’ learning experiences and foster improved learning outcomes.

Bild vergrößern

The ENCORE platform [14] has been designed and developed to support teachers and learners both in designing and in delivering personalised learning paths (cf. Sects. 4.1 and 4.2) in MDE based on a set of available OERs (cf. Sect. 4.3.1). In ENCORE, a learning path typically consists of a series of lessons and modelling activities that build on one another to create a cohesive educational experience. The process for creating a learning path generally involves two main steps: i) creating the learning path by identifying the learning objectives, selecting relevant content and assessment, and using the most appropriate instructional strategies, e.g. lectures, group activities or assignments; and ii) delivering the learning path to students while monitoring students’ progress and providing support when needed. Through the use of the ENCORE Enabler for Educators (E4E), educators can access the ENCORE database and include in the specific learning paths the relevant OERs that target specific skills in MDE. A second enabler, the ENCORE Enabler for Learners (E4L), supports the delivery of the resulting learning path to students by leveraging notebook interfaces. Each notebook can be configured to provide and assess a specific learning path and can be augmented with gamification mechanisms to promote students’ learning engagement.