After recounting our (mostly failed) experiences in teaching model-driven engineering, we (Dimitris Kolovos and myself) have embarked on a project to find (and/or define) good use cases for teaching several flavours of model-driven /model-based engineering.
Our preliminary proposal was recently contributed to the Educators Symposium, part of the Models 2016 conference. Below you can find the full text of the presented paper: Towards a Corpus of Use-Cases for Model-Driven Engineering Courses (also available in pdf format here).
We hope to come up with additional use cases soon and since we do believe that this should be a community effort (similar to what I’m trying to do with the OCL benchmarks). Go to our dedicated MDE4EDU website if you’re interested in this initiative and would like to collaborate!
Having taught Model-Driven Engineering courses for a num- ber of years, in this paper we reflect on the importance of selecting appropriate use-cases for students to explore related principles and technologies. We discuss examples on both ends of the spectrum and we present guidelines for selecting use-cases that are pragmatic and motivating without being excessively complex.
While the value of teaching software modelling and model-driven engineering at University level is increasingly recognised , effective teaching continues to be a challenging task. The authors of this paper have been somewhat unsuccessful in the past in convincing students about the potential of MDE. We believe a key reason for this is the poor choice of use-cases and examples we show in class. Based on our experience and on extensive discussions with colleagues, in this paper we wish to propose examples of alternative use-cases that have a potential to overturn the current situation.
2. Background – 3 key aspects to avoid when teaching
In our experience, to maintain the interest of students in a course they need to see practical value in the technologies and techniques they are taught. For software engineering courses this makes the selection of motivating use-cases a critical point. On top of the bad modelling practices discussed in , we have identified that use-cases we use often suffer from the following weaknesses that can end up demotivating students instead of sparking their interest:
Unrealistic Domains. In an attempt not to overwhelm students with the com- plexity of developing fully-functional systems, educators often use unrealistic application domains. For example, a common use-case – variants of which we have used in the past – is to ask students to develop a DSL for modelling book libraries1 and then write model-to-text transformations that generate HTML reports from library models or define additional validation constraints. This use- case has two advantages: the DSL contains concepts that students can relate to, and it exercises most of the features of metamodelling technologies (inheritance, containment/non-containment/opposite references). On the other hand however, it is rather unlikely that one would implement a real-world library management system using models instead of e.g. a relational database as a data persistence format.
Artificial Development Processes. Another common use-case to demonstrate model-to-model transformation is the (infamous) UML to RDBMS example. Here, students are typically asked to develop a transformation that produces a relational schema from a UML class diagram. This is a complex transformation that exercises many features of contemporary transformation languages, how- ever, at the end of the process students end up with a model of a relational schema that is of little practical use. An additional model-to-text transformation can be used to produce SQL that can set up a database, however, this is not very helpful either as in practice students would then still need to interact with the database using low-level SQL commands. Extending the use-case and asking students to also generate code that can provide a high-level object ori- ented interface to the database from first principles is a rather complex task and the results are unlikely to be of comparable quality to object-relational frame- works like Hibernate. An alternative would be to ask students to produce e.g. Hibernate-based code, however this means that a complex framework Hibernate would have to be taught first – which is a major deviation from the aims of an MDE course.
In our experience, a significant proportion of highly-skilled students quickly realise the discrepancy between such use-cases and the practices and processes they would need to employ in a real world situation and gradually lose interest.
Non-Iterative Development Scenarios. Students who – despite the poor selection of use-cases – can see a potential in the principles of MDE, often ques- tion its cost-effectiveness. In our view, this is largely because in most use-cases, students are shown how to develop an appropriate modelling language to model a system and then spend the bulk of their effort on developing model-to-model and model-to-text transformations that can transform their models to working code. When the use-case ends there, students can feel puzzled as they have spent a substantial amount of effort to develop and debug non-trivial transformations only to produce code – that they could have written manually with a fraction of the effort – once. Since it is well understood that developing MDE infrastructure takes a few iterations/product instances to pay off, it is important that this is highlighted to students by adding more than one change-adapt iterations to the development scenario.
3. Towards a Corpus of Use-Cases for MDE Courses
Although previous work (e.g. ) has identified the importance of selecting ap- propriate use-cases, there is a lack of concrete proposals in the literature. In this section we attempt to outline a few use-cases that address some of the issues above, as a starting point for discussion towards building a community-wide body of concrete use-cases that can be reused in MDE courses worldwide.
3.1 Auto-Synchronised (Opposite) References in Java
Java lacks support for auto-synchronised (opposite) references. For example, con- sider the Customer and Invoice classes in Listing 1.1. While conceptually the Customer.invoices and Invoice.customer references are linked to each-other (i.e. setting customer c1 as the customer of invoice i1 should ideally automatically add i1 to the invoices of c1 ), in the absence of built-in support for declaring this relationship, developers need to maintain the two references in sync manu- ally as demonstrated in Listing 1.2. This is clearly tedious and error-prone. To achieve automated synchronisation, a developer would need to extend the imple- mentation of Invoice.setCustomer(…) and also the behaviour of the add() and remove() methods of the list returned by Customer.getInvoices(). While this is certainly feasible, it is a mundane and repetitive task that would benefit from MDE-style automation.
To automate this task, the reference synchronisation code can be generated from a UML class diagram through a model-to-text transformation. To make this solution practically applicable, it should be implemented to accommodate hand-written code either through an appropriate inheritance scheme or by using protected regions  which the transformation preserves during re-generation. In the absence of such support, students are more likely to consider the use-case artificial and lose interest.
The main advantage of this use-case is that it addresses a real limitation of Java while not requiring knowledge of third-party libraries. A risk on the other hand is that students will need to develop a non-trivial model-to-text transformation to achieve this and that – as discussed above – they may consider that they could have written the reference synchronisation code manually faster. To mitigate this risk the use-case should involve more than one change cycles and/or large class diagrams that would reinforce the benefits of automation.
3.2 Using State Machines for Behaviour Comprehension and Code Generation
Moving away from class diagrams, in this use-case students can be presented with a small state-machine (5-7 states) and the equivalent code in Java, and can be asked to reason about the behaviour of the system e.g. how many distinct states the system can be in, from which other states the system can get to a particular state of interest, if there are any unreachable states etc. These should be straightforward to answer by inspecting the state machine but less obvious by reading through the Java code. The first aim of this use-case would be to demon- strate that models can help with understanding and reasoning about complex behaviour, which becomes much harder to grasp at the level of imperative code.
In a next step, a significantly larger state machine can be introduced which is not amenable to visual inspection, to demonstrate the need for automated model analysis capabilities (e.g. querying, validation, reachability analysis). In a final step, a model-to-text transformation can be used to produce an iden- tical executable Java implementation of the state machine from the high-level model. Again, in each of the latter steps, multiple state machines should be in- volved to demonstrate how the initial effort spent to develop the queries and transformations pays off after a few iterations.
3.3 Wedding Organisation DSL
Moving away from UML, the aim of this use-case is to demonstrate the useful- ness of constructing domain-specific languages (DSL) when existing modelling languages are not a good fit for the problem at hand. We also wish to steer away from generating executable code to demonstrate the breadth of applicability of MDE techniques. In line with our discussion so far, the DSL – and its supporting model management activities – should be relatively simple but genuinely practical for solving the problem at hand (unlike the library example discussed in Section 2).
In this use-case, from models conforming to a wedding event DSL such as the one displayed in Figure 1 students can be asked to generate (1) personalised invitation cards in HTML/LaTeX (if a guest is allocated to a table it means that they have been invited to the post-wedding dinner and another sentence needs to be added to the invitation card), (2) lists that will guide guests to their tables at the venue. Students can be asked to use a validation language to check models conforming to the DSL for the presence of conflicts (i.e. guests involved in a “conflict” should not be sitting on the same table), or even to employ a constraint solver to suggest an acceptable allocation of guests to tables.
Although at a first glance this use-case appears to be similar in nature to the library use-case discussed in Section 2 in our view it differs in a few key aspects. First, it represents a domain for which there is no existing widely-used software that students can compare against. By contrast, in the library management do- main, students are likely to compare the produced MDE solution against existing library management systems (e.g. university library) that they are familiar with, with an unfavourable outcome for the MDE solution. Second, and perhaps most important, in the absence of out-of-the-box user-friendly software, the proposed MDE solution is arguably a sensible way to support this activity in practice.
4 . Conclusions
In this paper we have highlighted the importance of selecting appropriate use- cases for MDE courses, and identified a number of common weaknesses that they can present. In an attempt to stimulate discussion towards a more convincing and inspiring MDE curriculum, we have outlined three concrete use-cases which, in our view, are pragmatic without being excessively complex. As further work, we plan to apply and validate these use-cases in our institutions and to start an initiative for building a corpus of examples with similar intentions on top of an appropriate technical infrastructure (e.g. GitHub organisation, Wiki).
- Marian Petre. UML in Practice. In Proceedings of the 2013 International Conference on Software Engineering, ICSE ’13, pages 722–731, Piscataway, NJ, USA, 2013. IEEE Press.
- Richard F. Paige, Fiona A. C. Polack, Dimitrios S. Kolovos, Louis M. Rose, Nicholas Matragkas, and James R. Williams. Bad modelling teaching practices. In ACM/IEEE MoDELS Educators Symposium (EduSymp), 2014.
- Louis M. Rose, Richard F. Paige, Dimitrios S. Kolovos, and Fiona A. C. Polack. The Epsilon Generation Language, pages 1–16. Springer Berlin Heidelberg, Berlin, Heidelberg, 2008.