Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
1 
Modelling Teaching Practices 
Richard Paige, Fiona Polack, Dimitris Kolovos, 
Louis Rose, Nikos Matragkas and James Wil...
Motivation 2 
• It’s a great time to be teaching modelling! 
• We have access to resources: 
– Some good textbooks (e.g., ...
Motivation 3 
• It’s a great time to be teaching modelling! 
• It’s seen as an important part of an 
undergraduate and pos...
Motivation 4 
• It’s a great time to be teaching modelling! 
• Advice, guidance and description of 
principles is availabl...
5 
Maybe 
it’s 
+me 
for 
some 
… 
Bad 
Advice…
6 
“An 
Excerpt 
from 
the 
10 
Dos 
and 
the 
500 
Don’ts 
of 
Knife 
Safety.”
Seriously… 7 
• What hasn’t worked in teaching modelling? 
• What practices have shown to be 
troublesome, problematic, or...
8 
Bad Modelling Teaching 
Practices 
Richard Paige, Fiona Polack, Dimitris Kolovos, 
Louis Rose, Nikos Matragkas and Jame...
Teach to the 9 
Specification
Bad Practice: Teach to 10 
the Spec 
• We 
have 
some 
wonderfully 
large 
modelling 
language 
specifica+ons. 
– You 
kno...
Bad Corollary: Teach languages deeply 
11 
• Large 
modelling 
languages 
have 
many 
many 
many 
wonderful 
and 
interes+...
Better Practice 12 
• Avoid longitudinal studies of modelling languages 
– (exceptions: if you are a researcher or a masoc...
Tangent: Feedback 13 
• The problem that students are trying to 
solve provides necessary context for 
obtaining feedback ...
Tangent: Feedback 14 
• Feedback in teaching programming is ‘easy’: 
students get immediate feedback on their 
decisions f...
Bad Practice: Provide 15 
Answers, not Solutions
Bad Practice: Provide 16 
Answers, not Solutions 
• Students may expect to be given answers 
to modelling problems. 
– “Is...
Better Practice: Provide 17 
Solutions, not Answers 
• Students want answers, but there are too 
many possible (good) answ...
Bad Practice: Serious 18 
Domains Only
Bad Practice: Serious 19 
Domains Only 
• Students need & benefit from examples. 
• Modelling examples should be grounded ...
Serious Domains 20 
Only? Seriously? 
• Tedious, recurring and obvious examples are 
tedious, recurring and obvious. 
– De...
Serious Domains 21 
Only? Seriously? 
• Grant students the freedom of their 
imagination. 
– Leads to “interesting” modell...
Bad Practice: No 22 
Prerequisites!
Bad Practice: No 23 
Prerequisites 
• Formal methods need discrete maths. 
• Compiler design needs automata theory. 
• But...
No, Prerequisites 24 
• Modelling is an advanced software 
engineering skill. 
• The mechanics of modelling may be 
straig...
No, Prerequisites 25 
• So what are some of the prerequisites? 
– Object-oriented programming: identity, 
encapsulation, r...
Bad Practice: 26 
Metamodelling via UML
Bad Practice: 27 
Metamodelling via UML 
• “Hey, our students understand modelling!” 
– “Let’s introduce them to metamodel...
Metamodelling not 28 
via UML 
• In practice, lots can go wrong. 
• The UML metamodel introduces lots of 
accidental compl...
Metamodelling not 29 
via UML 
• Use something else. 
• We currently use flowcharts to introduce 
metamodelling. 
– Concep...
Bad Practice: Learning 30 
the tools is easy
Bad Practice: Learning 31 
the tools is easy 
• By the time students start with modelling 
tools, they probably have exper...
Learning the tools 32 
isn’t easy 
• Acknowledge this in early exercises: 
– hands-on help in early going, make clear our ...
Bad Practice: Teach 33 
modelling in a vacuum
Bad Practice: Teach 34 
modelling in a vacuum 
• Teach modelling as a pure, self-contained 
subject. 
– As a theory with l...
Teach modelling in 35 
context 
• Teach modelling principles and tools in conjunction 
with other software engineering act...
Bad Practice: Codegen 36 
is the entry level drug
Codegen: the entry 37 
level drug 
• Once students get good at modelling, what 
can they do with their models? 
• “Communi...
Codegen: it’s time 38 
for rehab 
• It’s a very limited view of what modelling can 
do (e.g., simulation, decision support...
Bad Practice: 39 
Reinforce Silos
Bad Practice: 40 
Reinforce Silos 
• We have to compartmentalise when 
teaching modelling – it’s a big topic! 
– Teach mod...
Eliminate Silos 41 
• Teach that modelling cuts across software 
and systems engineering, with cross-domain 
and cross-dis...
Bad Practice: Only Physical 42 
Decomposition
Bad Practice: Physical 43 
Decomposition 
• Decomposition is a fundamental technique 
we teach, to help students manage 
c...
Not Only Physical 44 
Decomposition 
• Physical decomposition may be a useful 
way to manage complexity. 
– But we have to...
Bad Practice: Ignore 45 
semantics
Bad Practice: 46 
Ignore Semantics 
• We have beautiful modelling languages 
with lovely syntax and interesting 
metamodel...
Embrace Semantics 47 
• Modelling language semantics is an 
advanced topic. 
• But it’s essential to teach: 
– it helps st...
Observations 48 
• Integrate modelling into the curriculum. 
– Focusing on its use in problem solving. 
– Get rid of the “...
Observations 49 
• Expect that tools will get in the way of 
teaching and learning. 
– Accommodate for this in your lesson...
Upcoming SlideShare
Loading in …5
×

Bad Modelling Teaching Practices: Invited talk at MoDELS'14 Educators' Symposium

957 views

Published on

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.

Published in: Software
  • Be the first to comment

Bad Modelling Teaching Practices: Invited talk at MoDELS'14 Educators' Symposium

  1. 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. 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. 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. 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. 5 Maybe it’s +me for some … Bad Advice…
  6. 6. 6 “An Excerpt from the 10 Dos and the 500 Don’ts of Knife Safety.”
  7. 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. 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. 9. Teach to the 9 Specification
  10. 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. 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. 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. 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. 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. 15. Bad Practice: Provide 15 Answers, not Solutions
  16. 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. 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. 18. Bad Practice: Serious 18 Domains Only
  19. 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. 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. 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. 22. Bad Practice: No 22 Prerequisites!
  23. 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. 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. 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. 26. Bad Practice: 26 Metamodelling via UML
  27. 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. 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. 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. 30. Bad Practice: Learning 30 the tools is easy
  31. 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. 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. 33. Bad Practice: Teach 33 modelling in a vacuum
  34. 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. 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. 36. Bad Practice: Codegen 36 is the entry level drug
  37. 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. 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. 39. Bad Practice: 39 Reinforce Silos
  40. 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. 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. 42. Bad Practice: Only Physical 42 Decomposition
  43. 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. 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. 45. Bad Practice: Ignore 45 semantics
  46. 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. 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. 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. 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!)

×