first programming course to students outside CS curriculum relays on a simple ... It is astonishing to realize how few and simple are concepts related to basic ...
Teaching/Learning a First Object-Oriented Programming Course outside the CS Curriculum Jorge Villalobos, Rubby Casallas Universidad de los Andes, Departamento de Ingeniería de Sistemas Bogotá, Colombia {jvillalo, rcasalla}@uniandes.edu.co Abstract In this paper, we present a new approach to teach/learn a first programming course for students outside CS curriculum. Our approach aims to deal with some known student difficulties: 1) motivational problems, 2) lack of balance in the aspects related to building a program to solve a problem, and 3) methodological problems in teaching programming. Our proposal intends to contribute to overcome the difficulties by means of: 1) an active learning approach based on problems, 2) a balance among several thematic axes related to programming, and 3) the construction of a teaching/learning pedagogical model to help instructors teach programming in a systematic way.
MOTIVATION At a first glance, teaching programming can be perceived as a simple task. Nevertheless, it is a current research subject in many places around the world. Many approaches have been proposed in the last years [1, 2, 3, 4, 5, 6], and however, there is not a completely satisfactory solution. The sprouting object-oriented approach and the emergence of new programming languages, tools and technologies have introduced new factors that complicate even more the already complex task of programming. The big challenge of offering a first programming course to students outside CS curriculum relays on a simple question: how can we propose students better ways to integrate computer programming as a tool into their own domains? At the University of Los Andes, our department offers a first course in computer programming to freshmen of several and diverse programs of study: computing engineering, physics, civil engineering, electrical and electronic engineering, industrial engineering, mathematics, etc. We have around 900 students taking our course each semester distributed in roughly 35 sections. We face a number of challenges due to the amount of students and to the difficulty of teaching/learning to program.
FIGURE 1. OUR APPROACH
Our approach is based in five main ideas, as is illustrated in figure 1: (1) active learning, (2) incremental generation of abilities, (3) problem-oriented structure, (4) balance of thematic axes and (5) use of current technology. In this paper, we present a summary of the results of a project which main purpose is to find new ways to teach/learn object-oriented programming. The second section presents the main challenges we are facing. The third and fourth sections present the most important elements of our proposal. In the fifth, we present some of the result we already attained and finally we conclude and present some future works.
2
THE CHALLENGES This section presents the most important conclusions we obtained after the diagnosis phase of our project. We were able to identify some of the challenges we were facing. However, some deal with course content, most of them are related to the methodological/pedagogical approach to teach/learn this first programming course. Learning by Imitation Learning how to program is mainly a process of generating abilities more than a process of memorizing a set of concepts. It is astonishing to realize how few and simple are concepts related to basic programming. This fact is not a problem unless the course focuses on the explanation of the definitions and everything else is accessory. In a typical programming lecture, the instructor, after presenting the concepts or asking the students to read from a book, answers questions and starts to illustrate the concepts by writing algorithms on the board. This way of teaching is based on the hope that students will be able to detect patterns in the given problems, to associate techniques to the solutions and, finally, to generalize in their heads how to apply the pair patterntechnique to similar problems. Most of the time, the only technique that is taught in the programming course is “divide and conquer”, but it is done informally and at a superficial level and consequently, it rests only as a good intention. We can name the above approach “Learning by imitation”. It relies on the hypothesis that students are able to generate programming and problem solution abilities by imitating what the instructor does. This approach has many implicit problems and explains, in a good part, the difficulties found in teaching programming: (1) There is not a generation of vocabulary to talk about how to build a program. It is because the pair pattern-technique is used only intuitively and its validity is not verified. The only common vocabulary is related to the syntactic structures of the programming language and it makes difficult for the instructor to give real assistance when students need it. In other words, to look at a solution in a book or to see the instructor making it up on the board, does not guarantee an adequate generation of abilities in the student. Even if the approach can work in many cases, the success depends on factors that go beyond the instructor’s control. The consequence is that good students obtain good grades and average students obtain average grades, and as teachers, we cannot do anything about it. (2) There is a sense that “how to do things” is not teachable, but it is something that depends on inspiration and on the genius of the programmer. It creates anxiety in the students. They are never ready to take a test because they do not know if the “thing”, which magically was generated in their heads, will be enough to solve the proposed new problem. (3) The quality of the course depends on the capacity of the instructor to persuade students to learn by imitation. Evidently, there are teachers more successful than others are, but they cannot explain their achievement clearly enough to write a guide for others. Thus, there is the thought that the ability to teach programming successfully is not teachable either. (4) Sometimes students make flawed generalizations about programming from the elements they study during the lectures. In many cases, some incorrect patterns are established and are detected only during more advanced courses. Bottom-up approach A classic programming course follows a bottom-up order to introduce concepts. First, basic elements are introduced (simple data types, operators, expressions, and so on) and then, gradually, other control structures, methods, parameters vectors, collections, the class concept, etc. The student will be prepared to
3
write a complete program only by the end of the term. Rarely, do we have enough time to study other aspects such as testing or graphical interfaces. This approach has several consequences: (1) The student does not have a clear understanding of why a concept was introduced because she does not see the real need for such construct. This makes his learning process more difficult. (2) Many of the topics presented during the course seem to be artificial due to the size of the problems students can solve; therefore, incorrect messages are sent about the real usefulness of such topics. If writing the formal specification of a problem takes twice the time of implementing and testing it, students may conclude that problem specification is just a waste of time. We encounter a similar situation when they have to write the invariant of a class or document the code. Students interpret it as some instructor’s whim, and they will try to do the job but only after the program is working. (3) It is necessary to cover many topics before constructing something interesting that makes sense; this fact gives students the feeling that the topics they are working on do not have a real value for their professional life. Most of the problems the instructor can develop during the lectures are simple and without a context (i.e., to look for something in a collection, to insert an element in a list, etc.) Only by the end of the course the student is able to build a complete program. However, it is frequently not as fancy and powerful as the programs he is accustomed to use during his daily life. Unbalance of Thematic Axes Programming is a task that involves elements of different thematic axes. Students should understand programming as the balance of several domains like modeling, problem solving, programming languages, tools, etc. These domains have deep relationships among them, which allow students to solve a problem by building a computer program. A programming course can be organized following one or more of those thematic axes. Classic programming courses are organized following the axe that corresponds to a programming language and other axes only appear as accessory. The consequence of this is that the course, and many of the books about learning programming, is based on a pass-over of the syntactical structures of the programming language. The other aspects, important to programming, are viewed superficially or ignored. This way of organizing the course results in a student who at the end of the term does not have a real vision of programming. She gives much more importance to the programming language than to the process of building it (modeling, testing, etc.). For instance, during lectures there are much more questions regarding the use of a particular library than about how to specify a problem. Students undervalue some elements the instructor tries to introduce even in a tangential way, and it makes the teaching process more difficult. By the end, students have the impression that they have learnt a programming language, but they are not conscious about the abilities they should have generated related to the other axes. Thus, in some cases, they think they lost their time because they believe that the particular programming language they learnt is not going to be useful for their professional life. Motivational aspects and frustration We would like to separate the motivational aspects of the student associated to the course and the frustration the course can generate in some of them. Motivational problems are related mainly to: (1) Freshmen arrive in college with an excessive pragmatism. It is too difficult to motivate them if they cannot see rapid results. A recurrent question among students from academic programs different to CS, is: “why do we have to learn to program in C++ or java if we will never use it later?” (2) Appealing applications with fancy user interfaces or with practical use are extremely complex to be carried out by the students with the concepts introduced during the lectures. Thus, they recognize the big gap between their simple programs and the applications they are habituated to use.
4
On the other hand, frustration problems are more related to the conflict students have with the practical aspects of the course. In spite of understanding the theory or being able to write the algorithms the teacher asks for, no matter how much time they spend writing a program, students have the feeling that success depends on an extra factor that nobody controls, called “luck”. It is unpredictable how much time is needed to build the program. There is a huge gap between the problems on the board and the problems in front of the screen of the computer. That feeling of not having control of the situation generates frustration in the students.
THEMATIC AXES Our approach aims to find a balance among seven thematic axes we consider fundamental to build a computer program. The intention is to use only the necessary elements of each axis to solve small problems or in other words, to build small programs. The axes are: •
Modeling and solving problems: Refers to the ability to abstract relevant information from a reality and to create a model to express the abstraction. Furthermore, it refers to the ability to propose a solution in terms of the elements in the model. We call analysis the process of creating the abstraction and problem specification the result of expressing the problem in terms of the abstraction. In this course, we introduce concepts like objects, basic data types, variables, containers, contracts, functional requirements, etc.
•
Algorithmic: Refers to the ability to use a set of instructions to express modifications on the model to find a solution. We call algorithm design the process of building the set of instructions. In this course, we introduce concepts like algorithm, instruction, pattern, assignation, conditional, iteration, etc.
•
Languages and technologies: Refers to the necessary technological elements to express in a language the abstraction of the reality and the solution of the problem (programming languages, model languages, etc.). In this course, we introduce concepts like UML, java, javadoc comments, jar files, development environment, etc.
•
Architecture: Refers to the structure of the final application expressed through the elements of the conceptual model and the components of the solution, like the graphical user interface. In this course, we introduce concepts like graphical user interface, program testing, module, class, package, etc.
•
Programming techniques and methodology: Refers to the strategies and guides that help create a complete program. These define a set of phases, tasks, metrics, recommendations, patterns, etc. programmers use these to undertake successfully the development life cycle of a program. In this course, we introduce concepts like assignation of responsibilities, divide and conquer, identification of entities in the conceptual model, etc.
•
Process: Refers to the activities intended to guarantee the quality of a solution. These include code standards, time track logs, code inspection techniques, testing techniques, etc. In this course, we introduce concepts like development life cycle, analysis, design, testing, deliverable, etc.
•
Computer Tools: Refers to the computational tools (compilers, editors, debuggers, etc.) that help develop a program. They are considered implementations of a specific technology. In this course, we use Eclipse like the development environment and various plug-ins on it to format the code, to automate the unit tests, to draw the UML diagrams, etc. In the following section, we present our proposal, and in particular, how we are looking for a balance among the different axes and at the same time, trying to maintain a high student motivation.
KEY ELEMENTS OF THE PROPOSAL The four key methodological elements of our proposal are 1) complete program, 2) problem, 3) level and 4) training tool. The balance among the thematic axes is achieved trough the complete program and problem elements; the notion of level helps us introduce new concepts gradually and facilitate an incremental learning; and, a training tool is a program intended to help generate punctual abilities in the students on specific
5
concepts of specific thematic axes. We explain these concepts in the next sections, where we show how we are using them in our pedagogical and methodological model. Complete Program and Problem The notion of complete program is the transversal methodological element of the course. A complete program is a working computer program with an attractive graphical interface, a well-defined set of requirements, a strategy to solve the problem, an architectural design document, a set of unit tests, and a well-documented code. It means that a complete program integrates different elements of the thematic axes presented above. It is important to clarify that for this first programming course, the programs are small, they are defined by three to five functional requirements and a kernel implemented by four to six classes maximum. A problem is an incomplete program and a set of tasks students have to do to complete it, i.e., the program has to become executable. The purpose is that, without losing the whole picture, students perform a set of tasks to develop some parts of the incomplete program and they use others, already defined, in an intuitive way. To have a better idea of what a complete program is, we present a simple one. The example is a program that allows users to keep and display results of a Formula One championship. The graphical interface for the example looks like figure 2. For this particular exercise, students have to complete some of the functional requirements like updating the results of a particular race. Level The notion of level helps us introduce new concepts gradually and facilitate an incremental learning. Instructional objectives (knowledge and abilities) define a level that students have to achieve. Based on the objectives, a level determines for each thematic axis: •
the set of new concepts to introduce.
•
the set of concepts to further explain.
•
the abilities to assist in generating or reinforcing.
• the set of new concepts students will use in an intuitive way. The course is organized in six levels, each one with time duration of two or three weeks. During a level, we work on at least three examples and one problem. To solve the problem, the student has to complete some parts; others, previously developed as part of the example, she/he can taken them for granted. Usually, elements from more complex levels are included in the examples and students use them in an intuitive way. Object-Oriented aspects are present in several axes of our approach. They are a powerful tool to model problems, to decompose a solution and to specify how a functional requirement will be implemented as a collaboration of possibly several interacting objects.
6
FIGURE 2. GRAPHICAL USER INTERFACE OF THE EXAMPLE
Training Tools A training tool is a program intended to help generate punctual abilities in the students on specific concepts of specific thematic axes. Unlike problems, training tools isolate one or more concepts, sometimes only related to a single thematic axis. A training tool allows students to go deeper in the theory and generate abilities of its use, giving them the possibility of manipulate abstract concepts in a graphical way. A training tool can be traversal to several levels and can give support to many exercises. For example, we have developed training tools to generate abilities in the construction and evaluation of logical expressions (a water network simulator: fig. 3-d), instantiation and manipulation of instances (cars in a race: fig. 3-c), conditional instruction, iterative instruction (a 2D robot manipulator: fig. 3-b), matrix manipulation (an image editor: fig. 3-a), and so on. Each tool has an associated group of challenges students have to solve. During a training session, some defies are defined for the students. For example, in the image editor they have to change the image to black and white, to delete a part of the image, etc. It is clear that the tool helps students train on traversal matrixes and manipulation of its contents.
7
FIGURE 3. TRAINING TOOLS
RESULTS We have validated the proposal with two pilots (one of 60 students and another of 150 students). During the pilots, a group of psychologists and educators were in charge of the oversight of the performance of the students and tracked the development of the materials. We have designed an assessment strategy that allows us to track and oversee the course methodology and the students’ learning process. The techniques employed were lecture observations, interviewing and polling students, instructors and teaching assistants. We summarize the main results: 96% of the students think the course has contributed significantly to their professional education; 87% of the students think they have achieved a good mastering of the topics in the course; 90% of the students think there is an adequate relationship between the theoretical and the practical parts of the course. The class satisfaction for the course was 89%; 84% of the students found the proposed problems interesting and motivating. The failure rate among students taking the pilot course was 15%. However, in the past, this value has been around 30%. The average mark was 78 over 100 in contrast to 60 in previous semesters. Some of the qualitative findings shown by the interviews allow us to conclude that the course is highly stimulating for the students because of three main reasons: 1) they feel they learn in a relatively easy way. The level structure of the course has allowed them to be aware of their constant progress; 2) the way the lectures are carried out, invites them to participate in an active manner; 3) they find a clear context of
8
professional application. They find that to work with functioning programs with a specific purpose is very motivating. The results are very good; the indicators defined to measure the success of the project have shown us that we have attained the main objectives. Consequently, the pilot has helped us validate the approach, the materials, and the methodology in general. Currently, we are giving the course for 900 students in 35 groups, and we are using a book we have recently published [7]. We are using the same evaluation methods used during the pilots and the indicators are very good so far. As a final point, the course is running with more than 25 examples and more than 18 training tools for the levels of the first course. All materials are available in the course site: http://cupi2.uniandes.edu.co. Further, we have started a community around the project, where instructors and students as well are posting contributions to enrich the materials.
CONCLUSIONS In this paper, we have presented a proposal for a first programming course for students outside CS curriculum. This work is part of a bigger project called Cupi2 which general purpose is to look for new ways to teach/learn computer programming. We presented the main challenges we were facing associated to the perception of the course by the students and the instructors. We undertook a diagnosis that allowed us to identify some of the problems and to clarify the expectations. The proposal relies on a pedagogical model that aims to find a balance among several thematic axes related to programming. We use examples and problems organized on levels. Using the levels, we can introduce new concepts and reinforce abilities in an incremental manner. We propose a teaching/learning methodology that includes phases to solve the problems: motivation, understanding of the problem, solution construction, sharing solutions, synthesis, and conceptualization. The student can control his work and can reflect about his success and his failures. The materials include many examples, exercises, training tools and guides to the instructors to make the course more teachable and repeatable. From now on, we have to continue to evaluate the results with the help of a control group, in order to identify improvement possibilities.
REFERENCES [1] Davis, H., Carr, L., Cooke, E. and White, S. Managing Diversity: Experiences Teaching Programming. Learning and Teaching Support Network Conference. London, 2001. [2] Kölling, M. The Problem of Teaching Object-Oriented Programming, Part 1: Languages. Journal of Object-Oriented Programming. Vol. 11, No. 8, pp 8-15. 1999. [3] Kumar, A.N. Learning Programming by Solving Problems. Informatics Curricula and Teaching Methods (ICTEM). L. Cassel and R.A. Reis ed. Kluwer Academic Publishers. pp. 29-39. Norwell MA., 2003. [4] Nic Gearailt, A. Using Java to increase active learning in programming courses. Principles and Practice of Programming in Java. Trinity College. Dublin, june 2002. [5] Stein, L.A. Challenging the Computational Metaphor: Implications for How We Think. Cybernetics and Systems Vol. 30 No.6. 1999. [6] Stein, L.A. What We've Swept Under the Rug: Radically Rethinking CS1. Computer Science Education Vol. 8. No. 2, pp. 118-129. 1998. [7] Villalobos, J., Casallas, R., “Fundamentos de Programación: Aprendizaje Activo Basado en Problemas”, PrenticeHall, april 2006.
