10 th Workshop on Teaching Programming

1. Designing Assessments for Object-Oriented Programming 10th Workshop on Teaching Programming by Olenka Marczyk Senior Lecturer in Computer Science University of Hertfordshire

2. Designing Assessments • Competing issues: • does it test programming skills ? (attainment) • does it test programming ability ? (creativity) • what will be the marking time ? • how will it affect pass rates ?

3. Assessment Methods • Programming Projects • high on creativity, but long on marking time • problems with plagiarism/collusion • Take-home specified assignments • reduce degrees of freedom, so reduce marking time • more problems with plagiarism/collusion • Short-answer/Multiple choice Tests • reduce plagiarism/collusion • reduce marking time • don't test "programming" skills • Practical Tests • resource intensive and traumatic for students • marking time ? …. depends on nature of the task

4. Multi-Choice : Poor Practice Multi-choice questions often test syntax or obscure aspects of code -why expect students to make sense of the unreadable ?? Is there any point in "knowing" this ? ..Just try it out on a computer !!

5. What are we trying to test ? • Some knowledge of syntax • BUT how much ? • what would you do, if you didn't know ? • programmers rely on a compilers OR look it up !! • Ability to write algorithms • should tests be used to test creativity/ability ? • if they can't solve the problem.. can't write the code ? • How to test the object-oriented nature of programming ? • O-O only makes sense for systems of some size • tests have time constraints which can limit complexity

6. What I would like to test? • Programming skills: • what type of code to use/when (problem solving strategies) • what to change and what to keep (pattern matching) • making use of resources : compilers, documentation • and yes, understanding the virtual machine/execution model • want to test the application of principles, not memory • Object-Oriented principles: • abstraction - separation of WHAT from HOW : method call / method definition/passing parameters • cohesion - keep methods small and classes cohesive • coupling - explicit links (creating objects/calling methods)

7. An Approach to Assessment • Programming skills should be tested practically • Every assessment should have/use an O-O design • Use modularisation/abstraction features of O-O • don't need to know implementation to use a class/methods • allows for coding simple methods (in complex context) • complex algorithms can be built from method calls (granularity) • Allow use of compiler/online documentation and other documentation - use "open book" & provide specimens • Test whether student can recognise a pattern, and apply it in a different context. • Build in opportunities to learn/improve next time

8. An Assessment PlanSemester A: Programming Principles - Year 1 • Assignments are "open book" & most have "specimens" • All have a context/scenario to justify the code • Requirements are relevant to the scenario • Ass 1 - In-class practical test - 1 hr (supplier side code) • provides a project with some code - supplier side • test use of development environment (BlueJ) • requires code: declare variable, mutator, accessor, constructor • BUT provides similar code for different variables • Ass 2 - Written Test - 1 hr (client side code) • provide extensive documentation, but no supplier code • test knowledge of terminology, understanding of instructions • requires simple code: declare/create objects, object method calls

9. An Assessment Plan(2) • Ass 3 - Take-Home Practical Assignment + Demo • develop a project according to a specification (some code given) • tasks use technical terms • covers previous tasks + simple collections • it is expected that students will want to get help • no problem, provided student learns - but want to penalise copying • DEMO - in-class practical 1 hr • download submitted assignment, make changes/additions • DEMO mark provides a capping scheme on assessment marks, so those who just copy without learning do not benefit • Students don't like the bluntness of the cap, but using a % reduction would favour the more blatant copier.

10. Ass 3: Capping Scheme • Results of demo test affect final assignment mark • The limits on coursework marks are as follows: • Rationale: if you wrote the code you should know it well enough to make changes • Does not eliminate plagiarism, but provides disincentive • There is a further supervised test later

11. Assessment Tasks • Ass 3 • given Date class • amend Time class • write : TimeTest,Patient, DayLog,DayLogTest • Ass 4 • given Date class • amend Member,Seminar, Branch,Tester

12. Evaluation Used on BSc Computer Science/IT & Joint Honours • This year Semester A: 350 students ! • Pass rate : 72% (before re-sits), BUT about 30% got A's** • Ass 1 & 2 are relatively quick to mark • Ass 3 & 4 take longer but code relatively easy to find because of specification • Marking code can't be avoided ! - a team of markers helps • Always problems with student uploading wrong files/late • Not much room for creativity - students work to specs ! • Can't avoid writing the solution before setting assessment • Designing new assessments : keep tasks, change context **Action Plan: All assignment have extension tasks currently worth about 10% - increase % of extension tasks.

13. Final Sumative Assessment • Ass 4 - In class Practical Test (4 hrs) • similar to Ass 3 in content • completely open book - to reduce student stress • declaring variables, writing constructors/accessors/mutators • declaring/creating objects, calling method • it repeats much of what has been done before but under test conditions • … so does test attainment • … but those who have engaged with Cwk 3 should feel confident That is the point ! - developing confidence by repetition

14. Further Assessments Year 1 Semester B : Programming & Program Design 1 • Only for those who have selected "Computer Science" route • Ass 1 : Written test 1 hr - on collections (documentation provided) • Ass 2 : Take Home + Demo (1 hr) - more complex collections • Ass 3 : In-class Practical Test (4 hrs) - like Ass 2 + error handling Year 2 : Programming & Program Design 2 • Ass 1 - practical In-class (1hr) - year 1 revision • Ass 2 Take Home with a specified interface + Demo (1 hr) • inheritance, coupling/cohesion, • Ass 3 Take Home with a specified interface + Demo (1 hr) • inheritance, user interface (GUI/IO), persistence, exceptions • Exam with a pre-viewed case study (documentation provided)

15. Summary In year 1: • the aim is NOT to produce creative programmers who can solve really challenging problems • the aim is to: • give students a feel for the O-O paradigm & virtual machine • get students to understand and follow O-O relevant instructions, especially method definition/ method call • give students confidence in solving routine standard tasks for which there are patterns : recognise the nature of the problem, select a code solution, customise it to meet the needs of this problem (select/copy/paste/edit) • develop competence by "spiral curriculum" - similar tasks in different contexts which get progressively more complex.