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!)