Bad Modelling Teaching Practices: Invited talk at MoDELS'14 Educators' Symposium
Preview:
DESCRIPTION
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.
Citation preview
- 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 Its 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 Its a great time to be teaching modelling! Its
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 Its 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 its +me for some Bad Advice
- 6. 6 An Excerpt from the 10 Dos and the 500 Donts of Knife
Safety.
- 7. Seriously 7 What hasnt 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. (Its 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
cant 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 theyre lucky, feedback will come from a modelling tool
(Dont 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! Lets introduce them to metamodelling. Thatll
be fun. How should we do that? Well, theyre using UML convincingly.
Lets 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
dont hide accidental complexity (things irrelevant to modelling
tasks).
- 32. Learning the tools 32 isnt 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? Were 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: its time 38 for rehab Its a very limited view of
what modelling can do (e.g., simulation, decision support,
analysis). Its an overused tool: what engineers often (unwisely)
reach for. For complex semantic gaps, M2T languages are often not
well-suited for crossing them; dont 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 its 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 its 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 modellings sake is cool, but its 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!)