An invited talk given at MoDELS'14 in Valencia at the Educators' Symposium, focusing on experiences with teaching models and modelling and what things did not work.

1. 1
Modelling Teaching Practices
Richard Paige, Fiona Polack, Dimitris Kolovos,
Louis Rose, Nikos Matragkas and James Williams
Department of Computer Science
University of York

2. Motivation 2
• It’s a great time to be teaching modelling!
• We have access to resources:
– Some good textbooks (e.g., Cabot & Brambilla)
– Reliable (and sometimes usable) tools.
– Standards.
– Lots of legacy teaching material.
– Documented engineering principles & practices
(e.g., patterns, styles).
– Repositories of examples (Atlantic Zoo,
REMODD, …)
– Published case studies.

3. Motivation 3
• It’s a great time to be teaching modelling!
• It’s seen as an important part of an
undergraduate and post-graduate
curriculum in SE/CS/....
– A subject in its own right.
– A cross-cutting subject that underpins many
aspects of software and systems engineering.
– Knowledge that graduates must have when
transitioning to work.

4. Motivation 4
• It’s a great time to be teaching modelling!
• Advice, guidance and description of
principles is available.
– Some of which has been presented and
published at previous EduSymps.
– Though more is needed, e.g., effectiveness of
different teaching practices, teaching different
cohorts, modelling for new domains.
• But …
• Maybe we have too much good advice.

5. 5
Maybe
it’s
+me
for
some
…
Bad
Advice…

6. 6
“An
Excerpt
from
the
10
Dos
and
the
500
Don’ts
of
Knife
Safety.”

7. Seriously… 7
• What hasn’t worked in teaching modelling?
• What practices have shown to be
troublesome, problematic, or difficult to
repeat successfully?
• What are some anti-patterns or bad teaching
practices that we should avoid?

8. 8
Bad Modelling Teaching
Practices
Richard Paige, Fiona Polack, Dimitris Kolovos,
Louis Rose, Nikos Matragkas and James Williams
Department of Computer Science
University of York

9. Teach to the 9
Specification

10. Bad Practice: Teach to 10
the Spec
• We
have
some
wonderfully
large
modelling
language
specifica+ons.
– You
know
who
you
are…
(UML,
MARTE,
OCL,
…)
• Teach
modelling
by
working
systema+cally
through
the
language
standard.
– Structural
diagrams,
behavioural,
etc…
– Focus
on
minute
details
of
arcane
language
features.
– (It’s
some+mes
how
we
teach
compara+ve
programming
languages!)

11. Bad Corollary: Teach languages deeply
11
• Large
modelling
languages
have
many
many
many
wonderful
and
interes+ng
features.
– Each
should
be
presented,
analysed,
summarised
and
compared
with
others
(syntac+cally,
seman+cally)
in
minute
detail.
– AXer
all,
we
can’t
possibly
tell
when
a
feature
will
be
useful
(or
useless).

12. Better Practice 12
• Avoid longitudinal studies of modelling languages
– (exceptions: if you are a researcher or a masochist)
• Drive exploration of modelling languages by the
problem you want students to solve.
– What is needed from the modelling language?
– What features can we deploy to meet our
requirements?
• Genuine question: how can we assess the
success (or failure) of language features in solving
problems?

13. Tangent: Feedback 13
• The problem that students are trying to
solve provides necessary context for
obtaining feedback on modelling
decisions.
– “Does this modelling decision help to address
the problem?”
– Without reference to a modelling problem,
how can we possibly provide feedback, and
provide steer to students on the utility of
modelling language features?

14. Tangent: Feedback 14
• Feedback in teaching programming is ‘easy’:
students get immediate feedback on their
decisions from the IDE etc.
• For modelling it is harder: students may not
get feedback at all!
– If they’re lucky, feedback will come from a
modelling tool (“Don’t draw that association!”).
– But many modelling tools reveal innate
complexity of modelling languages (XMI,
metamodel etc).

15. Bad Practice: Provide 15
Answers, not Solutions

16. Bad Practice: Provide 16
Answers, not Solutions
• Students may expect to be given answers
to modelling problems.
– “Is this right?” “Is this what you expect?”
• Of course, we instructors are awesome
modellers.
• We should fight the temptation to give in
and provide answers.

17. Better Practice: Provide 17
Solutions, not Answers
• Students want answers, but there are too
many possible (good) answers.
– Different modellers have different styles.
• Students need to learn the subtleties of
modelling through experience, not imitation.
• How?
– Get students to create solutions, then have
seminar-style presentation/discussions.
– Create models “live” and discuss what is
unacceptable or conventional.

18. Bad Practice: Serious 18
Domains Only

19. Bad Practice: Serious 19
Domains Only
• Students need & benefit from examples.
• Modelling examples should be grounded
in reality to increase engagement.
• Realistic examples:
– A library
– A bank
– A traffic light system
– Automotive entertainment system
– OO2RDBMS

20. Serious Domains 20
Only? Seriously?
• Tedious, recurring and obvious examples are
tedious, recurring and obvious.
– Demotivating!
– Choose examples with engagement in mind.
• Multi-disciplinary problems?
– E.g., archaeology – modelling how building use
has changed at an address over 500 years.
– E.g., music – DSLs for music and music matching
– E.g., economics – model plant/controller for “flash
crash”?

21. Serious Domains 21
Only? Seriously?
• Grant students the freedom of their
imagination.
– Leads to “interesting” modelling decisions.
• Diversity of solutions.
– Enables a more exploratory approach.
• We use computer games (both for modelling
and metamodelling).
– E.g., air traffic control, adventure, plant
automation, trains, mountaineering, …
– Promotes research, modelling, feedback …

22. Bad Practice: No 22
Prerequisites!

23. Bad Practice: No 23
Prerequisites
• Formal methods need discrete maths.
• Compiler design needs automata theory.
• But modelling … it can be picked up by
anyone, right?
– As long as they have some experience with
programming, right?

24. No, Prerequisites 24
• Modelling is an advanced software
engineering skill.
• The mechanics of modelling may be
straightforward, but developing models
that are fit for purpose is not.
– Excellent analytic skills.
– Aptitude for abstraction.
– Ability to evaluate and consider trade-offs.
– Ability to focus on domain not notation.

25. No, Prerequisites 25
• So what are some of the prerequisites?
– Object-oriented programming: identity,
encapsulation, reference, composition, proxy,
adapter, refactoring?
– Risk management?
– Engineering processes?
• What about prerequisites for model
transformation?
– Hmm … programming, templates (PHP),
closures, first-order logic????

26. Bad Practice: 26
Metamodelling via UML

27. Bad Practice: 27
Metamodelling via UML
• “Hey, our students understand modelling!”
– “Let’s introduce them to metamodelling. That’ll be
fun.”
• “How should we do that?”
– “Well, they’re using UML convincingly. Let’s use
the UML metamodel as a running example.”
• “Great! We can show the typical patterns of
metamodelling, different techniques, etc.”
– “Super! Nothing can possibly go wrong!”

28. Metamodelling not 28
via UML
• In practice, lots can go wrong.
• The UML metamodel introduces lots of
accidental complexity.
– Structure/naming similarities between UML and
MOF/Ecore.
– “UML classes are instances of the Class UML
metaclass, which is an instance of MOF class.”
• ER diagrams may be better, but structurally
and visually are too similar to class diagrams.

29. Metamodelling not 29
via UML
• Use something else.
• We currently use flowcharts to introduce
metamodelling.
– Concepts: actions, decisions, transitions,
labels.
– Little structural, and no lexical, overlap with
metamodel-level concepts.
– Use examples of flowcharts to motivate the
development of small metamodels/patterns.

30. Bad Practice: Learning 30
the tools is easy

31. Bad Practice: Learning 31
the tools is easy
• By the time students start with modelling
tools, they probably have experienced IDEs.
– So learning Eclipse/EMF should be easy.
• But modelling tools expose students to
different artefacts:
– Concrete syntax, abstract syntax, persistence
layer, different editors (tree editor, graphical
editor), different wizards, …
• Generic tools like Eclipse don’t hide
accidental complexity (things irrelevant to
modelling tasks).

32. Learning the tools 32
isn’t easy
• Acknowledge this in early exercises:
– hands-on help in early going, make clear our
expectations.
• What learning resources are available for
students?
– Equivalents of StackExchange? E-books?
YouTube sites?
– We’re way behind the programming tools.

33. Bad Practice: Teach 33
modelling in a vacuum

34. Bad Practice: Teach 34
modelling in a vacuum
• Teach modelling as a pure, self-contained
subject.
– As a theory with laws/rules, with no notable
relationship with the outside world.
• In other words, ignore the purpose in
creating models.
– May be acceptable for theoretical computer
science, but not software engineering, which
must consider trade-offs.

35. Teach modelling in 35
context
• Teach modelling principles and tools in conjunction
with other software engineering activities/tools.
• So teach not only modelling and metamodelling,
but:
– Application scenarios
– Related software engineering tasks
– Alternatives to modelling
– Transitions to and from modelling and other
engineering tasks
– Relationships to similar topics, e.g., databases,
ontologies.

36. Bad Practice: Codegen 36
is the entry level drug

37. Codegen: the entry 37
level drug
• Once students get good at modelling, what
can they do with their models?
• “Communication, evaluation, validating
different design options.”
• “Code generation is a primary use case.”

38. Codegen: it’s time 38
for rehab
• It’s a very limited view of what modelling can
do (e.g., simulation, decision support,
analysis).
• It’s an overused tool: what engineers often
(unwisely) reach for.
– For complex semantic gaps, M2T languages are
often not well-suited for crossing them; don’t
mislead students.
• It suggests MDE/modelling is for software
engineering.
• So, teach it as a secondary scenario?

39. Bad Practice: 39
Reinforce Silos

40. Bad Practice: 40
Reinforce Silos
• We have to compartmentalise when
teaching modelling – it’s a big topic!
– Teach modelling as a separate subject (e.g.,
focusing on language not problem).
– Ignore team issues.
– Have one person teach modelling, not a team.
– Teach modelling without reference to other
disciplines or non-software domains.

41. Eliminate Silos 41
• Teach that modelling cuts across software
and systems engineering, with cross-domain
and cross-discipline examples.
• Consider socio-technical issues.
• Have modellers work in teams, taught by
teams (to get different perspectives).

42. Bad Practice: Only Physical 42
Decomposition

43. Bad Practice: Physical 43
Decomposition
• Decomposition is a fundamental technique
we teach, to help students manage
complexity.
• Teach it superficially!
– If we are modelling a physical system (e.g., a car,
a ship), the only way to decompose is physically,
in terms of subsystems and components.
• Also, only refer to physical analogies when
decomposing software systems.

44. Not Only Physical 44
Decomposition
• Physical decomposition may be a useful
way to manage complexity.
– But we have to explain the consequences.
• Consider alternative decompositions (e.g.,
behaviour).
• Consider cross-cutting concerns like
safety, and how they do not decompose.
– Some considerations in enterprise
architecture.

45. Bad Practice: Ignore 45
semantics

46. Bad Practice: 46
Ignore Semantics
• We have beautiful modelling languages
with lovely syntax and interesting
metamodels.
• So interesting, in fact, that that is what we
focus on.
– Spend weeks on language features and
abstract syntax.
– Ignore the semantics.

47. Embrace Semantics 47
• Modelling language semantics is an
advanced topic.
• But it’s essential to teach:
– it helps students avoid misconceptions (e.g., a
metamodel is its semantics, a model has one
interpretation).
– It supports new use cases, e.g., simulation.
– An ill-defined semantics can be the root cause
of ambiguity and disagreement.

48. Observations 48
• Integrate modelling into the curriculum.
– Focusing on its use in problem solving.
– Get rid of the “UML course”!
• Problem-based learning for undergraduates
and novices.
– Modelling for modelling’s sake is cool, but it’s for
the researcher and tool builder!
• Make sure students are prepared.
– OO, patterns, instantiation, constraints,
references …

49. Observations 49
• Expect that tools will get in the way of
teaching and learning.
– Accommodate for this in your lesson plans,
lab sessions, exercises etc.
• Engage students with ‘fun’ problems.
– Let students do their own research.
– Embrace the flexibility inherent in modelling.
– Make lots of mistakes (both you and the
student!)