Projectory A Framework for teaching Object Oriented Design and Object Oriented Programming

Transcription

1 Projectory A Framework for teaching Object Oriented Design and Object Oriented Programming ElanLunch@L3S, Jens Gößner, Thomas Mück

2 Educational Setting To learn the construction of object-oriented software at the university in an industry-like scenario, our students have to develop a middle-sized (150 person days) software system: They form small companies (six people per team) and develop their work together. Progress and equal distribution of work are controlled by dividing the project into a number of blocks. At the end of each block, the solutions to the individual tasks must be integrated and turned in as a whole, functioning program. Once a week the teams have to meet for two hours under the supervision of a tutor, to assign tasks and perform walkthroughs (code reviews). We encourage participants to code in pairs (solving two tasks per pair; Pair Programming.

3 Educational Setting Distribution of exercises Thread Basic Concepts Stamm & Stück Inszenierun g Termin Persistenz UI Documentatio n Block

4 Goals Our goal was to develop a framework for a learning environment for arbitrary objectoriented design and programming problems. Such a framework should relieve the teacher from approving the correctness of solutions (marking), giving her more time for helping the students with their efforts to find a solution. This can be accomplished by the creation of a constructivist learning environment To give immediately a feedback to the user, it is necessary to provide the learning environment with some intelligence to offer him a hint back to the right way. Participation in the software practical causes in a large amount of teamwork. This entails the necessity of means for computer supported collaborative work. We support object-oriented design only to the extent that code can be automatically generated from it. 4

5 Chances With its testability at the unit level, object-oriented programming is ideally suited for a constructivist learning approach. By organizing exercises into tasks involving only a small number of classes, students can solve problems through trial and error The failure of individual tests can be taken as the basis of the automatic generation of highly detailed feedback, including suggestions on how to fix errors. if tasks are partitioned so that work can proceed in parallel, the social skills required for working in teams can also be acquired. 5

6 Explication of the problems with learning environments When learning how to program, the natural workbench is the integrated development environment (IDE). It provides the editor to enter the code (the solution of the exercise), the compiler to check syntactical correctness, and the debugger to remove semantic errors. By contrast, most learning environments are either web browser based or come as specially designed hypermedia systems task and solution are delivered using two different systems the task by the browser, and the solution by the IDE. Support is distributed between these two systems help with the task is provided by the learning environment assistance with the programming language and used libraries is the responsibility of the IDE. 6

7 The rationale behind Projectory Our intention was to create a programming environment for learning how to design object-oriented systems and realizing them with an object-oriented language. Projectory is an environment which tries to unite these demanded qualities. As basis is Together Control Center from Borland used. Together is an IDE for visual OO-modelling with UML and OO-programming. Together s simultaneous round-trip engineering prevents the students from code and model mismatches and makes some of the UML models (Class Diagrams, Sequence Diagrams) executable and testable. 7

8 The rationale behind Projectory (cont.) The intelligent testability of the student s solutions is a prerequisite for a constructivist approach. With every block of exercises a suite of test case will delivered to the student. A solution will be tested automatically with these test cases. Only if the whole test suite runs correct over the solution, the exercise has been solved correctly. In the case of an error the test suite supply the location of the error, a message what is wrong in the solution and a hint towards a better solution. We have written approximatly 300 test cases for all exercise blocks. 8

9 The rationale behind Projectory (cont.) With the Projectory-Framework we are able to perform programming courses with different content. An author must deliver an initial project skeleton, the exercises divided in blocks and formulated in HTML, a sample solution for each block and the test suites for each block. 9

10 The Architecture of Projectory Projectory consists of two integrated and interacting parts : a serverside component which provides the download of tasks and server side execution of unit tests to check the correctness of solutions. a clientside pluggable component to present these tasks from within an IDE and execute local unit tests and show the example solutions after the completion of a block. Projectory-Client Projectory-Server Together Control Center Projectory Plugin HTTP Tomcat Webcontainer Projectory-Servlet JDBC MySQL 10

11 TheArchitecture TheClient Plugin Together has an open Java-API. We have extended the Together IDE with our own pluggable module to: download tasks, to be solved by the students from a dedicated Projectoryserver; present these tasks to the students from within the extended IDE; execute unit tests on the implemented tasks to give immediate feedback to the students on how they are doing (without connecting to the Projectory-server; submit the finished solutions. Additionally, some statistical data will also delivered to the Projectory Server 11

12 The Architecture The Projectory Server The Projectory-Server is the heart of the Projectory system. written in Java and resides on a Tomcat Webcontainer. A MySQL-Database is used as database for managing the statistical and the course data. The server has a servlet interface for the HTTP-communication with the Projectory-plugin. The server provides the download of exercises and example solutions for every block, carries out the statistics about the duration of the work used to solve the exercise by every participant and performs the automatic tests before the solutions will submitted. 1

13 Automatic Testing For the automatic verification of solutions we integrated the widely used JUnit testing farmework into Projectory. JUnit provides a comprehensive assertion facility to verify expected versus actual results and is a good means to test the behaviour of single implemented classes. Verification is performed both locally and remotely. Local verification gives the students the facility to get immediate feedback on how they are doing. Upon completion of a block, the company uploads its work to the server. At the server, Ant-based compilation, running of the appropriate test suites, and building of the reports is triggered by each submission. All tests must pass to confirm the correctness of the solution. If tests fail the server generates a report for the user and sends this report to the Projectory- Plugin 13

14 Other Teaching tools available in university environments The idea of automatic verification of programming exercises in university settings is not new. Two publicly available systems are WebAssign and Praktomat. These systems are in practical use at the University of Passau (Praktomat) and at the Fernuniversität Hagen (WebAssign) in Germany. In my Infolunch ( ?) I have talked about the concepts of these tools 14

15 Conclusion The Projectory concept is similar to Praktomat at the server side. Praktomat and Webassign are client-sidedly pure portal solutions. After the download of exercises via a web browser these exercises must be worked in an IDE and then submitted to the server via the web browser again. Projectory goes a step further and unites the download of exercise, the work on the exercise and the submission of a solution in an integrated environment. This closes the gap therefore is between download of exercises and working on it and in turn between working on exercises and the submission of the solution. 15

16 Conclusion (cont.) In further versions we intend to improve the plug ability of the client component to support more IDEs such as Eclipse. More intelligence is needed in Projectory. The error messages are only a beginning. For a further version of Projectory we imagine a context based help support on the basis of a CBR-System to give the user a better and more detailed help support. The use of Projectory increases the efficiency of the employees and reduces the teacher s role to a tutor for the students. The use of Projectory leads also to relative great effort in preparation of exercises in comparison with the previous year s conventional software practical. a more precise formulation of exercises, the constructions of test suites and the accompanying example solutions for each single block. 16

17 Presentation 17

18 References J.Gößner, F. Steimann, T. Mueck "Projectory - A Tool for teaching Object Oriented Design and Object Oriented Programming" ECOOP 003, Seventh Workshop on Pedagogies and Tools for Learning Object- Oriented Concepts (Darmstadt, Germany, July 1-5, 003). F. Steimann, J. Gößner, U. Thaden Proposing Mobile Pair Programming OOPSLA 00 Workshop on Pair Programming Explored / Distributed Extreme Programming (Seattle, USA 00). F. Steimann, J. Gößner, T. Mueck "Filleting XP under Educational Aspects" accepted for XP003 Educational Symposium (Genova, Italy, May 5-9, 003)