Teaching and learning domain-specific language (DSL) engineering and model-driven software development (MDSD) concepts are difficult tasks: either it requires a deep understanding of the nature of a domain, students lack it in general or students are exercising only single technical aspects of MDSD, so that they don't see the whole picture and are lost in the model-driven and tool “jungle”. This paper explains a competence-oriented approach for model-driven software development course design to reduce the above learning difficulties. The main idea is first to define the course competencies students should have in a precise manner and second to choose an “appropriate” didactic method for each required competency. Two didactic examples are presented: Peer Instructions for MDSD fundamentals and a comprehensive MDSD software project for DSL and transformation competencies, in which students need to develop a complete workflow system for examination regulation issues. At the end we discuss the overall experience with this approach and with the current course settings.
Page 19 Domain-specific languages in the context of model-driven software development have become increasingly popular in the software industry and are currently achieving the plateau of productivity of the technology hype cycle. Academically MDSD courses have been integrated in software engineering curricula at many universities. The following subject-matter didactics key questions arise for our course: • What kind of DSL- and MDSD-competencies should a MDSD course address? • What is the best way of learning the potential of model-driven technologies? • How do we focus teaching on DSL- and MDSD concepts rather than on (different) tools? The course (optional module, 4 contact hours, 6 credits) is part of the graduate curriculum of a master degree program in Computer Science at a University of Applied Sciences in Germany with a more applied research orientation; in contrast to traditional universities with a stronger theoretical academic research focus. Prerequisites are good knowledge of software engineering, software architecture and programming languages. It is assumed that students have already gained first-hand experience with the execution of traditional and agile process models for larger software projects. The module is designed according to the following principles: • Focus on Languages Modeling subjects are commonly not students’ favorites in contrast to programming languages and software design; in particular to our students with a more practical orientation. We still want to improve their modeling skills. A language viewpoint therefore should stimulate the learning motivation. • Foster High-Level Abstractions and generative programming We want to achieve acceptance of MDSD – similar to the acceptance of compilers. Hence, Software generation as an example for automating software development is an excellent use case which demonstrates the MDSD potential and it should also increase acceptance. Therefore we have to design practical exercises in a way that students are enabled to define high level abstractions as well as to implement code generators. • Exercise from a system viewpoint Neither teaching DSL designs alone nor teaching model transformations alone is sufficient. Instead, students have to synthesize these techniques and have to implement a complete system to realize the advantages. The rest of the paper outlines our approach to answer the key questions: §2 explains some of the intended competencies in a precise manner. §3 presents two didactic examples to achieve these competencies. §4 discusses our experiences with the didactic approach from both teacher and student perspective. 2 2.1
The term “competency” is one of the most popular and most confusing terms with
different definitions and meanings used in education. A most cited definition is
Weinert [
In this paper we do not further discuss this (and other) competency definitions.
Instead, we describe competencies by learning outcomes, which are defined according
to [
The course covers MDSD terminology, meta-modeling, model-to-model and modelto-text transformations, internal and external domain specific languages and model validation. Model management is skipped due to time constraints.
The addressed technical learning outcomes are specified in detail; a subset is listed
in Table 11. Each learning outcome has an associated level of mastery according to
the Anderson and Krathwohl (AKT) learning objective taxonomy [
explain the MDSD terminology in their own words classify the different MDSD approaches
explain the UML/Meta Object Facility (MOF) core package and the UML extension mechanism in their own words assign an (UML) model to the correct meta model hierarchy explain the Ecore meta model in their own words using an example create an Ecore meta model for a given textual description of an application domain 3. External DSL develop and implement a technical3 DSL in arbitrary textual notation for a technical domain using parser generator tools develop and implement a business3 DSL in arbitrary textual notation for a given application domain using parser generator tools validate the usability of a business DSL for the DSL user 4. Model-to-Text Transformation decide which parts of a system can be implemented by existing technologies (instead of generating) for a textual requirement specification decide which parts of a system can be generated for a given software architecture apply “best practices” generation patterns implement and test a generator for a given non-trivial model representation using template-engines
Learning outcomes listed under Table 1 3. have certain implications: in order to
find a compromise between tool learning curve and DSL expressivity these
competencies are restricted to textual concrete syntax and parser generator tools. This might
have a major impact especially on the definition of business DSL’s.
1 Course topics not listed (e.g. model-to-model transformations) are handled similarly.
2 Level 2 means „understand“, Level 3 “apply”, Level 5 „evaluate“, Level 6 „create“
3 for further discussions see [
Soft-skill recommendations particularly relevant for software engineers exist in a
fairly different level of description (e.g. [
Select correct answers: • finalstate cardinality wrong • incoming transition reference must be containment • transition meta class correct • a meta class is missing 3.2
In order to acquire DSL and transformation competencies and according to our system viewpoint project work is set up to implement a complete software system with the following parameters and settings: 1. Domain A software company is developing examination regulation software systems for university and college customers. The system has typical course administration and information requirements: lectures enter/edit module grades; students query their study progress and register for examinations. The system should also support different types of verification e.g. check of all prerequisites for a module examination registration. 2. Architecture Only the architecture layering is pre-defined (see Fig. 2). 3. DSL Two kind of DSL’s and generators have to be designed and implemented: (a) an entity DSL for the persistence layer as an example of a technical DSL (b) high abstraction examination regulation DSL as an example of a business DSL, which should enable the generation of business layer and presentation layer parts.
Presentation Layer "Business" Layer Persistence Layer generates (parts of)
Business DSL Generator Technical DSL
Generator
4. Implementation technologies Students select individually the implementation
technologies and frameworks. Typically a web-based architecture is designed.
5. Process model The iterative method SCRUM is applied due to the fact that our
students are already familiar with SCRUM.
6. Project Size In order to focus each team member on MDSD activities students are
divided into small teams of 3 individuals only. All projects run simultaneously to
accomplish the same task.
7. Tool Xtext/Xtend [
These settings have advantages and risks:
• Both DSL domains (examination regulations and database persistence
technologies) are well-known domains to our students. Thus, the domain learning curve is
minimized.
• A variety of entity DSL examples in different syntax styles have been discussed in
the literature (e.g. [
The software project is embedded in the exercise schedule as depicted in Fig. 3: Week Exercise
Basics This section evaluates the didactic approach from both teacher and student perspective. It is based on a 6 year MDSD teaching experience and regularly student surveys among all attendees (16 on average). 1. Detailed learning outcomes support course design Our approach for specifying learning outcomes is the process of refining the module learning objectives in a detailed manner – similar to requirement analysis activities applied for the course requirements itself. Hence, module handbook learning outcomes are described much coarser and the number is commonly restricted to the top five to six. The approach has two advantages: on the one side useless knowledge will be omitted. On the other side all required competencies are clearly specified in detail. This level of detail enables a setup of “appropriate” didactic methods as well as design competence oriented examinations and assessments. 2. Peer Instructions appropriate for (low-) level 2 learning outcomes Most of the addressed level 2 learning outcomes can be assessed by well-thought-out questions. Peer Instructions based on these questions enable the measurement of learning improvements: the percentage of the correct answers, after the discussions, increases significantly (e.g. by factor 2). 3. Choosing the right context is a key factor for understanding and acceptance The addressed model-to-text transformation as well as the non-technical competencies require a non-trivial exercise task. The assigned project work fulfills these requirements and supports learning: At the beginning of the course less than 10% of all students have ever heard of MDSD technologies. During the project phase students were realizing the benefits of high abstractions: essential system parts have been generated out of “their” own DSL: an artifact is shown in Fig. 4. At the end of the project at least 70% of all students claimed that they would use specific MDSD technologies in industry. This implies that exercising these techniques in the same context allows students to gain a much better understanding of the various MDSD technologies.
SPO computer science basic rules
ECTS sum 210 degree bachelor of science exam frequency 2 END Module M1 name Programming 1 ECTS 6 prerequisites M3, M4 exam type written grade weight 0.4 …
END technologies generated from
Presentation Layer
HTML 5 JavaScript
… Business Layer
Java 4. Software Project is students’ favorite and motivation is high Students complained about considerable project effort. Nevertheless, it showed the best evaluation results. Some teams delivered more functionality than requested. DSL design, learning template generation patterns were rated as “most interesting”. 5. Plenty of coaching is required for design decisions and planning issues A major difficulty for students was to determine whether an abstraction is part of the platform or part of the DSL. In addition, we permanently have to review all planning activities. This indicates the difficulty in tailoring process models to MDSD. 6. Xtext/Xtend learning curve acceptable for an eight week software project Our experience is that most students learn Xtext basics in ~2 days. Hence, students make quick progress. The Xtend learning curve takes longer (~5 days). 5
In this paper we have presented our didactic methodology and some concrete didactic examples in teaching and learning model-driven software development. We follow a top-down approach where we first define competencies by learning outcomes in a precise manner. The proposed level of detail is intended as a tool for course design. The selected learning outcomes of the course are a personal decision and might differ from MDSD to MDSD course. Our MDSD course illustrates several MDSD techniques and activities by using e.g. Peer Instructions and JiTT, different exercises and a comprehensive software project.
We intend to evolve the teaching format with respect to the following aspects: In the current course the designed examination and regulation DSL is not validated by a “real” customer. Simulating a real customer should improve the concrete syntax style and should also foster communication skills. Additionally, model-to-model transformations are covered, but not exercised entirely due to time constraints in the current setting, which is a major limitation. In order to acquire better acceptance for modelto-model transformations the software project task may be extended by integrating a reasonable model-to-model transformation use case.
Acknowledgments. The work is part of the project EVELIN funded by the German Ministry of Education and Research under grant no. 01PL12022A.