Personal opinions and lessons learnt after teaching software engineering and model-driven engineering at different levels, places and environments

1. Educating in MDE
Jordi Cabot
http://modeling-languages.com
INRIA & École des Mines de Nantes,

2. Educating in MDE
Shouldn’t MDE also change the way we teach Software Engineering
in CS degrees?
Model-driven engineering (MDE) is changing the way software
systems are developed, operated and evolved.
 Mixing personal opinions and lessons learnt during the last years
teaching SE and MDE in different places, levels and environments
 No magical recipes but, hopefully, some useful ideas & discussions

3. Before we start: Context

4.  Joint team between INRIA & Ecole des Mines de Nantes (EMN)
 ≈10 members
 Research focus on:
– MDE core technologies
• metamodeling, MT, MaaS, model management, virtual models…
– MDE applications
• reverse engineering, tool interoperability, IS cartography,…
 Commitment to Eclipse open-source projects:
– ATL, MoDisco, EMF Facet, AMW, AM3, TCS
 Strong links with several software development companies
 Participation in both national and international research projects
AtlanMod

5. Nantes
Paris
Nantes is a city
in Western France,
with 750,000 inhabitants
in the metropolitan area.
Nantes is the most
important city
of Brittany
and the 6th
town
in France.

6.  850 engineering students
 115 doctoral students
 125 permanent faculty members + 250 part-time teaching staff
 5 research departments
 10 specializations (all students get an Engineer Diploma – 2 CS-
related specializations)
 150 graduates per year
EMN (let´s look at the numbers)
 Low number of students. Good Rate students/faculty.
 Lots of support for teaching innovation
 Emphasis on Technology Transfer
GOOD ENVIRONMENT FOR TEACHING MDE

7. Model-Driven Engineering

8. What is MDE?
UML
Code-Generation
DSLs
Model-driven Rev. Eng
Metamodel
M2M
OCL
M2T
Model Evolution
Model-Based Testing
MDD
MDA
Profiles
Multi-modeling
SBVR
BPMN
Model Quality
ATL
QVT

9. Relationship between MDA/MDD/MDE
 MDD = Models as the primary artifact of the development process.
 MDA is the OMG's particular vision of MDD
 MDE = Models as primary artifacts of any Soft. Eng. activity

10. Relationship between MDA/MDD/MDE
 All model-driven processes are model-based but not the other way
round.
 Most MDE techniques are still useful in MBE

11. Technical Spaces
MDE Grammarware
MOF
(metametamodel)
UML
(metamodel)
ABank.uml
EBNF.g
Java.g
MyProgram.java

12. Model-Driven Engineering in CS Faculties

13. Educating in MDE
Shouldn’t MDE also change the way we teach Software Engineering
is taught in CS degrees?
Model-driven engineering (MDE) is changing the way software
systems are developed, operated and evolved.
Is this the case?

14.  MDE is not included in core SE courses
 In SE courses, MDE reduced to teaching UML (OCL?) for software
specification (and design of centralized systems)
 Few faculties have an (optional) course on MDE, sometimes only at
the master level
 When teaching MDE focus on MDD, e.g. creating a DSL + code-
generation from it
 Easier to find courses on formal methods for SE !!! (not that I´m
saying that FM are not important but …)
Looking at course syllabus in CS degrees (Spain)
 Out of topic:
 How many courses include version control, bug tracking, tests or
even agile practices?

15.  Existence of MDE courses tightly related to presence of a research
group on these topics
 Nevertheless, situation much better than a couple of years ago!!
 Opinion: Spain is one of the most advanced countries on this aspect
(linked to high MDE research activity)
 Still time to change the situation (opening of new degrees due to the
new regulation)
Looking at course syllabus in CS degrees (II)

16. When to teach MDE?

17.  MDE concepts should be introduced as part of the core SE courses
 Everybody has a basic notion of SE
 It´s clear that MDE is not something apart from (alternative to) SE
 Remember: MDE is process agnostic. Fits any dev. process you follow in
your SE courses
 MDE-based Waterfall process
 MDE-based Agile process (see Agile and Modeling / MDE : friends or
foes?)
 …
When to teach MDE?

18.  Introduction of MDE teaching in three different steps
1. Make sure all SE courses are model-based (some SE courses are
more about programming than modeling)
2. Transform (some of) them in model-driven
3. Provide one full MDE course to
 Show other MDE application scenarios (beyond forward
engineering)
 Introduce other MDE techniques (e.g. DSLs, model
management,…)
 Next we will see what contents include in each scenario
What to teach?
 But first: when to teach MDE = When to teach SE.

19. When to teach Soft. Engineering ?
 Soft. Eng. is not taught in the same order!
 Students first learn how to program (and design DBs) and then
learn that these programs should be part of “something” called SE

20.  Example (UOC – Open University of Catalonia)
When to teach Soft. Engineering ?
Fundamentos
Programación
Programación
OO
Estructura de la
Información
Bases de
Datos I
Bases de
Datos II
Sist. Gestión
Bases de Datos
Modelos Multidim. y
Almacenes de Datos
Ing. Software
Estructurado
Ing. Software
Gestión organizaciones y
proyectos inf.
Técnicas de
Desarrollo
Softwqre
Ing. Software
OO
Proceso de Ing.
Software
Ing. Software
componentes y
sistemas
distribuidosInteracción Humano-
Ordenador
Programación
Bases de Datos
Ingeniería del Software
Gestión de la Ingeniería del Software
 UML (class diagrams) first introduced in Programming then again in BD
and then again in SE!
 Domain modeling seen twice: in BD and in SE
 No conceptual link between SE and Programming and BD subjects

21.  We tried to reverse the order (first specification and then programming)
but had to reach a consensus
When to teach Soft. Engineering ?

22.  First we introduce SE principles (like lifecycles)
 Then we explain in parallel: specification, introduction to programming
and introduction to databases.
 Once we know the “final implementation platforms” (e.g. Java + RDB)
we can explain the principles of the design process
 A different course teaches the design process specific to each platform
When to teach SE?
 Interdisciplinary: professors from different areas must reach an agreement
 Too many course dependencies prevented us from being more ambitious
 More info: ¿Podemos darle la vuelta a la enseñanza del desarrollo
del Software? J. M.Marco-Simo et al. Novática 193

23. What to teach?

24. What to teach?
1. Make your SE courses model-based

25.  Usually SE core courses focus on the specification and design of
centralized (or C/S) systems
 Final technology platform: a OO program + a RDB as a persistence layer
 These courses are already (UML) model-based: use cases, class,
sequence diagrams,…
 But this is not the case with advanced SE courses on distributed and
component-based systems
 Complex technology platforms (JEE, .NET)
 Not obvious how to model those systems
Model-based courses
 We’ll see an example of transforming a DSE course from
programming-only to model-based
 For more info: From Programming to Modeling
Our experience with a Distributed Software Engineering Course.
Cabot et al. ICSE’08 Ed. Sym

26.  Original contents. Focused on teaching distributed technologies
 M1 – Distributed Software
 Distributed environments
 Distributed object platforms: CORBA, RMI, DCOM
 M2 – Component-based Software
 The components model
 UML for component-based systems specification
 M3 – EJB: Distributed components (>50% of the time)
 Introduction to the J2EE platform
 Servlets and JSP
 The EJB architecture
 JEE beans: Entity, Session and Message beans
 Transactions and JEE
From programming to modeling in a Distributed
SE course

27. Problems with this Distributed SE course
 This view impairs the students’ ability to develop complex systems
that require a more abstract view
 Contents quickly became outdated (DCOM?, RMI?)
 No methodological aspects about the analysis/design of distributed
software systems
 No software architecture concepts
 No distinction between platform-independent and platform-specific
concepts
– Students tend to believe that the acquired knowledge is only
useful for the J2EE platform

28. New course: educational objectives
 To relate the DSE field with contents of previous subjects on SE
 To combine a practical approach with a conceptual frame that makes it
independent of the technology
– A DSE course should especially emphasize its underlying principles
– Students should still learn how to program with a distributed and
component-based technology platform (e.g. JEE)
– The course should highlight the similarities among the different
technologies and motivate critical attitudes
 To use well-established models and notations (e.g. international standards)
for the design and development of distributed applications
 To teach how to select, evaluate and adapt different approaches, methods
and architectural styles

29. New course: global structure (I)
 A system specification is defined as a set of independent viewpoints, each
one of these viewpoints focuses on concrete aspects of the system
 The Reference Model for Open Distributed Processing (RM-ODP) is used as
a framework. Modeling with UML
Link with previous SE courses

30. New course: global structure (II)
 All views have been defined at the PIM level (including the definition of
system components and their logical distribution) -> Reusability
 Then, adaptation to JEE as example platform:
 The main concepts and technologies of J2EE are introduced.
 An UML profile for J2EE is explained
 Transformations between PIMs and J2EE-specific PSMs and between
PSMs and code are shown (but not formalized with any transf. lang)
[30] From module 2 …From module 2 … …… to module 4to module 4

31. New course: lessons learnt and results
 Better learning experience:
– It is easier to understand the different aspects that should be
considered in the design of distributed systems
– The students have now a broader understanding of the different
concepts and mechanisms of commercial component platforms
– Formal polls reveal that the overall student satisfaction has not
changed (even slightly increased)
 But…
– More contents than before ( failure rate has increased 10% )
All the programming part plus the new “modeling” concerns
Ideally we should split the course in two
– Broad set of previous knowledge required
DBs, Java, UML 2.x, SE…
– (Lab) Technical assistance highly recommended
– Teachers need strong skills in both SE, MDD and JEE
It is difficult to find consultants with a suitable profile to teach this course

32. What to teach?
2. A Model-driven SE course

33.  No matter how trendy are DSLs (Domain-Specific Languages), UML is
still by far the most important modeling language nowadays
 …with the permission of BPMN??
 UML should still be the basic notation for SE courses. If there´s enough
time, a small DSL for a specific system view (e.g. graphical interface)
would be great
 Profiles should also be part of the UML content in the SE courses
 Don’t reinvent the wheel vs Don´t push profiles too much
 Important: Concrete syntax vs Abstract syntax vs Semantics
Don’t even think about dropping UML

34.  Students should learn that textual modeling is also possible
 Not always graphical syntaxes are the best option (e.g. defining
behaviour; easier version control).
Textual UML
<img
src="http://yuml.me/diagram/scruffy/
class/[Customer]->[Billing
Address]" >
yUML
TextUML

35.  It´s very important to teach Object Constraint Language. Many
applications:
− Precise specification of software systems
− Patterns in transformations and model queries
− Definition of new DSLs
− …
Importance of Teaching OCL
Machine
Conveyor
Piece
1
*
*
om ic
*
+ capacity: int
im
*
oc
*
piece
Integrity constraints
context Conveyor inv:
self.piece->size() ≤ self.capacity
 OCL is not that difficult!!! - Test with students: Most of them were
able to guess without training the meaning of some OCL expr

36.  Best way to teach OCL? Introducing it together with UML during the
specification of software systems (less abstract than other scenarios)
 Invariants
 Pre and postconditions
 Use a UML tool with, at least, an OCL parser (many tools store OCL
constraints as simple strings)
 Show the effect of those OCL expressions in the code (there are tools
for automating this)
 If-then-else expressions in Java methods
 Triggers in SQL
Object Constraint Language (II)
 If it is not too much to ask make sure they understand the
efficiency issues involved in the evaluation of OCL (Incremental
OCL – Cabot & Teniente )

37.  … but the best tool you can use to teach OCL is the USE tool (model
animation tool: define your scenarios and validate your constraints)
Object Constraint Language (III)
MOVA
is a
similar
tool

38. MDE SE Course: I’d be happy if they learn…
PIM
PSM
M2M
CREATE TABLE Participant {
Name Varchar2(20) PRIMARY KEY
…
}
M2T

39.  More than an MDE SE course -> An MDD SE course
 Need time to teach other SE concepts (from software processes to
design patterns)
 To help, we may work with already provided Java and SQL simplified
metamodels and partially defined transformations
 At this point, the important thing is that they see how things could be
done, not so much that they actually do them.
MDE SE Course: Being realistic (time constraints)

40.  IMHO, this should be included in any SE course. Trickier than it
seems (and far beyond simple conformance)
 If code is generated from models -> quality of code = quality of
models
 Again, goal: realize that this aspect must also be considered
Quality of models
Not Satisfiable!!
Ex2. Ask your students to model a class
person and the recursive relationship
isParentOf. How many parents does a
person have?

41. What to teach?
3. A Full MDE course

42.  This section is based on the MDE diploma:
 1st full postgraduate program on MDE
 1 year duration
 Also, as part of a recently granted Leonardo Da Vinci project, we will
 Adapt the syllabus to different scenarios
 With focus on Web Engineering as application domain (M.
Brambilla - Politecnico di Milano partner)
 Scenarios we will consider:
 Separate module in a SE course
 Full course undergrad/grad level
 Full master
 Professional course/seminar
A full MDE course
 I’ll now present the MDE diploma. Build your MDE course taking a
subset of the MDE diploma modules (depending on your focus)
 At least include the creation of a DSL (and its editor)

43.  http://www.mines-nantes.fr/fr/Formations/Formation-
specialisee/MDE
 The goal of the MDE Diploma is to train engineers to manage complex
projects in various IT fields with the latest cutting-edge modeling
technologies
 6 month full-time courses at the EMN + 6 month internship in a
company developing a MDE project
 More than 20 invited lecturers
 1st
edition to finish February 2011. 2nd
to start September 2011
 Contents include social and management aspects of MDE
The MDE diploma

44. The MDE diploma: M1
Module 1:
Current Software Development Practices (60h)
 Software Modeling with current standards: UML, OCL,
overview of other standards (MDA, SPEM,…)
 Using an Integrated Development Environment: Eclipse
EMF, GMF,…
 Free and Open Source Software Development

45. The MDE diploma: M2
Module 2:
Automatic Model Processing (60h)
 Metamodel design
 Model-to-model Transformation with ATL
 Definition of Complex Transformations (HOTs, MT chains)
 Alternative Transformation Languages (GT and QVT)

46. The MDE diploma: M3
Module 3:
Managing Complex Scenarios (60h)
 Model Management
 repositories, versioning/evolution
 relating models: weaving models for matching and
traceability…)
 Integration of Heterogeneous Technologies
 Technical spaces
 Textual syntaxes: TCS, Xtext, MPS
 MDE and ontologies

47. The MDE diploma: M4
Module 4:
Applications to Information Systems (60h)
 Data Engineering
 Web Engineering
 Business Rules Engineering
 Legacy Reverse Engineering
 Graphical user interfaces
 …

48. The MDE diploma: M5
Module 5:
Applications to Critical Systems (60h)
 Embedded and Real-Time Systems
 Process Engineering
 System Engineering
 Security Engineering
 Formal Methods
 …

49. The MDE diploma: M6
Module 6:
Managing MDE Projects (60h)
 MDE and management of technology and innovations
 MDE and management of information systems
 Industrial Experience Reports

50.  From 360 hours to 430 (counting only hours in class; includes personal
work in class)
 Very difficult to find people to talk about management of MDE projects.
 It’s nice to have invited lecturers but it’s a huge amount of work (even
from a “social” perspective)
 Students wanted to have a session with me each week to review what
they had learnt and related it with previous lectures due to
 A lot of one day sessions on a single topic.
 Few ordering constraints among the modules enforced due to
lecturers travel constraints
 Apart from the company internship we had to prepare a small project
to be done during the courses to help to put everything together
Lessons learnt

51. How to teach MDE?
(miscellaneous)

52.  Focus on concepts and principles instead of focusing on notations and
tools
 Learning the UML notation is important but it´s much more important
(and difficult) learning how to model
 Most students finish their SE courses without being able to draw a proper
domain model for a 1-page application domain description!
 E.g. knowing how to indicate static properties in UML class diagrams it is
a necessary but not sufficient condition to apply this concept in practice
Focus on MDE principles

53. The Modeling Triangle
 And please make sure they understand UML is not a development
method. More people than you think believe this
 Partially our fault because we usually teach UML following an
implicit method
All three elements are important!

54.  Bigger impact than with programming languages (all IDEs compile and
run programs the same way)
 No best choice: Usability vs completeness (e.g. ternary associations,…)
vs Features (code-generation,…)
 At the UOC : an academic license (free) of MagicDraw.
 … but projects were delivered in pdf. Students could use any tool
they wanted (no support provided for those tools)
 For team work, take a look at new breed of online modeling tools
 Important: they must understand the difference between a modeling tool
and a drawing tool (e.g. Visio)
Choosing the right tool/s

55.  Beyond UML modeling, the safest solution is go to Eclipse and the tools
under the Eclipse Modeling Project (EMF, GMF,…)
 Better to create a bundle with what they need
 Don't underestimate time for learning how to install and setup the tools
 Most tools have crappy documentation; you decide how students
should spend their time
 Outdated manuals may be worse than no manuals at all
Choosing the right tool/s (II)
 MaaS (Modeling as a Service) still a long-shot but worth
considering. Imagine combining modeling services from different
providers to create your own MDD process

56.  Learning MDE requires practicing with existing model elements
 We need examples of models but also metamodels, model
transformations,…
 What´s out there?
 ReMoDD (Repository for Model Driven development)
 Open Model Initiative
 OOModels
 AtlanMod zoo of metamodels (>200) and transformations
 Database Answers: free library of >600 data models
Lack of MDE repositories

57.  Intellectual property issues -> Models (and not products) are
becoming the main assets for companies. Don’t want to share
 Many kinds of models and modeling languages
 Not only repositories but search engines needed on top of them
(AtlanMod working on this right now)
 Search by type
 Search by domain
 What format ? (image, xmi,…)
 Models are not enough. We need the context
MDE repositories (II) – Why nothing better?
 Only short-term solution I see? Faculty sharing their class exercises
 They may not be real-life examples but perfect for learning (we are
experts on that)

58.  Very easy to solve your PHP problems with Google. Try to do the
same with UML
 Poor and sparse documentation:
 Most of it referring only to UML
 And linked to a specific (commercial) tool
 The Modeling Languages portal tries to help here
 But again, university courses are probably the best source of
comprehensible information. Put them online!!
 Check upcoming www.learnMDE.com for educational resources
Lack of documentation

59. Three final thoughts

60. Let’s explain the real situation
 Modeling will be commonplace in 3 years time – S. Mellor
– Thought he is giving the same answer for the last 20 years
 Prepare students for what they will find in the real life -> no
revolution! evolution!)

61. … but be optimistic

62.  Pains and gains of software modeling
 Collective benefit but not for some individuals in the team
 Socio-technical congruence:
 Is the company ready for MDE?
 Team members can perform the activities required in a MDE
process? Do they have the right skillset? Can they satisfy the
new dependencies between them?
Without forgetting the Social Aspects
 Adopting MDE is NOT buying a code-generator!!!

63. Continuing the discussion
http://modeling-languages.com
jordi.cabot@inria.fr
@softmodeling