Visual Material & Learning Aids in Teaching Object Oriented Programming

1. Visual Material & Learning Aids in Teaching Object Oriented Programming Dr Hong Guo Dept. of Computer and Network Systems Faculty of Engineering and Computing Coventry University 7th HEA-ICS, Dublin 2006

2. Outline • Background • Problems observed • Causes of difficulties • Subject characteristics • Teaching approach • Learning & assessment • Learning aids • Early results … recommendations

3. Teaching Background • Module Leader for Applied Programming(new in 2002, 15Cr) • a level 2 mandatory module for degree students on • Computing (2+2) Vocational Programmes, or • BIT (2+2) Vocational Programmes • follow-on from a level 1 introductory OOP module, prerequisites • double-pass mandatory module (30 cr.), HND/2+2 Computing • pass mandatory module (single, 15Cr.), BA BIT • single-pass mandatory double module, BSc CS or SE • Module Leader forObject Oriented Programming in Java • a MSc module, none pre-request • Sharing teachingIntroduction to Programming(02– 04, 15Cr.) • a level 1 mandatory module, HND/2+2 BIT

4. Project Background • A Small Grant Educational Research project • “Enhancing computer programming skills by using the technique of Personal Software Process in teaching – a practical study” • To address the increasing problems with UG students, e.g. high failure rates, poor programming skills, … • To explore/adopt innovative ways of teaching and assessing which engage students in effective learning and acquisition of programming skills

5. Project Approach • Investigate the major problems in learning OOP • Explore students learning behaviour • Identify the root causes of learning difficulties • Adopt a best practice technique to aid their learning • Improve teaching through motivating, engaging, active thinking … supported with visual materials, emphasising on pedagogic aspects

6. Diagnostic Test • Questionnaire based at the beginning of the module (42 respondents = 100%) • To collect general information, e.g. motivation of students in learning the subject or taking the module • To determine students general knowledge of the basic but essential underpinning subject concepts and programming ability that this module is supposed to take as its starting point • To identify the most common stumbling blocks experienced during their previous learning • Used to decide the best way to organize & teach the module

7. Problems & Behaviors in learning • Insufficient prior knowledge in the fundamental concepts & general programming principles • Poor understanding of basic code • Lack of confidence in writing any programs; poor memory of syntax • Rush to coding, without much thinking; never note errors/repeating! • Sometimes lucky … but still no idea of what the program is doing • Little effort in doing exercises as deemed worthless, since only interested in or care about assessed pieces of work • Many simply cannot program, as they don’t know where to start or how to go about completing a given task • Frustrated by so many errors messages which they can’t understand • Poor self-management skill in organising their work

8. What was I/we doing wrong? Problems in assessment • Assessment (50% coursework : 50% examination) • In most modules, a coursework component requires students to implement only one or two assignments – provokes plagiarism • Week-by-week programming exercises are given to enable timely practical experiments with the specific concepts taught that week, however the performance in doing so has no direct effect on the module mark • The grading scheme does not motivate, and perhaps discourages good effortin attempting regular practical programming activities • Low pass rate(the university target≥ 70%): • 42.9% (2002 – 03) • 44.7% (2003 – 04) 

9. Causes of common problems • Poor programming skills and a complete inability to write program after two or even three years’ study appeared to be a common problem! • Is there something fundamentally wrong with the teaching and learning system we use? Key questions: • What is object oriented programming? • What and how should we teach, in terms of OOP? • What should we expect students to learn and how can they learn? • What should be assessed and how can we measure success?

10. A systematic programming process would ease the learning process! OOP Characteristics Programming is a practicalskill for problem solving, createdby humans, ultimatelyexecutedon a computer … • A creative subject, employ programming principles and techniques • Logical thinking, follow a systematic programming process • Imaginative, visualization in computer vs. program execution • Experience, effort in regular practice over a period of time • Understanding IDE, knowing your errors, learning from mistakes • Time consuming: coding, compiling and executing before feedback • … enjoy and achieve! but only if know what you are doing OO = additional concepts & better structure

11. "... visualization technology, no matter how well it is designed, is of little educational value unless it engages learners in an active learning activity” – Naps et al. What is important in learning? • Real effort in doing regular practice that follows a systematic programming process is the only way to learn programming • Sufficient experience in observing how program works whilst running in a PC is essential • Good knowledge of personal mistakes and ability to fix errors are crucial to effective learning • The level of personal interest in the subject determines the level of success in learning – good understanding of the basics is the key

12. What is important in teaching? • Make students to want to learn, & value the learning outcome • Job info/salary, teachers’ enthusiasm vs. motivation, interests … • What we teach • programming principles and techniques • a systematic programming process, explicitly by doing • use a particular programming language as a tool • How we teach(break big picture down based on complexity of concepts) • Organisation of teaching material, start from the very basic • Useful lectures use visual material, developed in a systematic way • Tutorials and labs, supporting material, guide by the process • What we assess - to encourage effective learning of how to program • performance in regular programming activities • adherence to the systematic programming process • ability to write programs that work

13. Learning vs. assessment • We must guide them on what to do to learn effectively • starting from the basics and then steadily & progressively move on to more complex concepts and techniques • using a systematic programming process • knowing what is happening by drawing diagrams • getting into the habit of noting down errors & corrections right from the beginning • We must support their learning with explicit material • A worksheet giving a few exercises is issued each week; students are encouraged to undertake them within that week • Logbook is introduced, in which students are required to record their programming activities whilst attempting the exercises • Logbook forms part (40%) of the coursework component assessment to encourage participation week-by-week

14. Learning Aids towards a systematic programming process • Learning aids • logbook • well-specified logbook guidelines • explicitly defined assessment criteria • Follows a best practice technique introduced in “Personal Software Process” & “A Discipline for Software Engineering” by the domain expert, Watts Humphrey. • Aims at helping students learn effectively from the process of recording their programming activities in a systematic manner • Provides a useful communication channel which allows timely feedback between tutor and student • Also improves personal organisational skills as everything is in one place – the logbook – which perhaps can be seen and used as a personalised reference book

15. Logbook content vs. marking criteria

16. Benefits of the learning aids • Makes the programming steps and the output of each step explicit, therefore easier to understand and to follow • Encourages careful and active thinking before coding • Allows students to be aware of their personal strengths & weaknesses compared to the cohort via reflective evaluation • Easy to track student progress based on actual evidence • Empowers students in developing good programming practices by using a transparent learning process • More effective learning of programming skills from the process of documenting their own mistakes • Engages students in regular programming activities • Contributes in developing a good foundation for the disciplined software development

17. Conclusion • Major difficulties in learning OOP • acquiring a firm understanding of the basic, but interrelated concepts of classes, objects and the essence of “objects communicate by sending messages” • the ability to visualize the effects of program execution, with respect to changes in computer memory, and changes in the objects’ state • adopting a disciplined and systematic process to the creation of computer programs, towards an effective development of problem-solving skills • the ability to understand and sort out error messages during compilation, especially when working on slightly larger and more complex programs, such as an assignment.

18. Improved pass rate by 17% (2004 – 2005), but 12.4% this year • 2002–03 2003-04 2004-05 2005-06 • 42.9% 44.7% 62.2% 57.1% Conclusionfrom Evaluation/Comments • Visual materials in lectures can play an effective role in making the OO concepts understandable. Students can become more motivated if lectures are easy to follow and comprehend. • Learning aids are useful in enhancing programming skills A systematic programming process encourages good programming practices and contributes in effective learning. However there may have pitfalls, i.e. extra work for students in maintaining the logbook (cutting/paste), and perhaps extra work for staff - more marking

19. Recommendations • Problems & difficulties in teaching & learning OOP may reduce if • teaching material is properly focused and organised, being consistent across a wide range of computer science courses • subject knowledge in lectures is delivered in line with the subject complexity: programming basic  class/object  control structures  arrays basic  arrays of objects  aggregation/collection  inheritance/interface/polymorphism ... • a systematic programming process is employed/embedded in both teaching and learning • Learning aids that support students with an explicit guidance on what process to follow to learn effectively are necessary.

20. Acknowledgements I would like to thank Lisa Payne, who contributed valuable comments and many helpful ideas to this project.

21. Reference • Humphrey, W.S., (1997) Introduction to the Personal Software Process, Addison-Wesley • Humphrey, W.S., (1995) A Discipline for Software Engineering, Addison-Wesley • Naps, T. L.et al. (2003) Exploring the Role of Visualization and Engagement in Computer Science Education. ACM SIGCSE Bulletin 35(2), pp.131-152. • Craig Larman, Applying UML and Patterns – an introduction to Object-Oriented Analysis and Design and the Unified Process, Prentice Hall (3/e) • Cay Horstmann, Big Java, John Wiley & Sons (2/e);