Problem Oriented Programming: An Approach to Teach Programming to Beginner Students Andréa Pereira Mendonça 1 , Dalton Dario Serey Guerrero 2 , Evandro Barros da Costa 3 Abstract ⎯ Traditionally, introductory programming courses have their scope focused on language syntax and program coding, postponing the development of problem specification skills to the forward disciplines of the curriculum. This strategy goes against the canonical process of problem solving, in which, firstly, the problem is specified and later on solved. This paper presents an approach to teach programming, denominated “Problem Oriented Programming” that enables beginning students to work with ill-defined problems and to practice software engineering activities, such as requirements elicitation and specification. The proposed approach is based on the principles of the inverted curriculum, problem-based learning and good practices on software development. It works accordingly to the necessities of software industry regarding programming professionals: ability to deal with ill-defined and complex problems, to establish communication strategies with clients and to be autonomous in the knowledge construction process. The proposed approach is being applied in the Federal University of Campina Grande. Computer Science Education, Index Terms ⎯ Programming Learning, Problem Specification, Requirements Elicitation.

INTRODUCTION On the programming courses for beginners, it is usual for the students to deal with the domain of the solution, prioritizing the programs construction and only later, starting to deal with requirements elicitation and specification. This curriculum strategy has some deficiencies: it fragments the knowledge in several different courses; it contradicts the canonic problem solving manner (in which, the problem is firstly specified and then later on solved); and therefore, it creates a gap between the academic supply and the demands from the software industry [2, 7, 17]. In order to minimize these deficiencies and to provide a more integrated curriculum, we conceived an approach to programming teaching called “Problem Oriented Programming” (POP). In this approach, the students must deal with problems that are “ill-defined”; they need to

discover the relevant information to enlighten the problem and to construct the program to satisfy the expectations and the needs of the client (teacher). In this case, the program is constructed on an interactive and incremental manner, as the students refine their comprehension concerning the given problem. With this approach, aside from the codification skills, the students develop the ability to elicitate and to specify requirements, performing activities closer to the real world. In this paper, we present the proposed approach, its pedagogic grounds, and its application in the Computer Science Course of the Federal University of Campina Grande, along with related works.

PROBLEM ORIENTED PROGRAMMING The Problem Oriented Programming (POP) is a pedagogic approach, destined to beginner programming students, and it aims to develop the students’ skills on dealing with the space of the problem. Treat the space of the problem consists on elicitate and specify requirements, turning ill-defined problems into a clear description of what needs to be done. That is how POP differs from the traditional way of teaching programming for beginner students, where the focus is on the space of the solution, that is, to learn a programming language syntax and to construct programs. We call as an ill-defined problem the one whose description is not complete and may contain ambiguities, contradictions, lack of information and/or even present irrelevant one. To transform this kind of declaration into a clear definition of what has to be done, it is required a set of non-trivial skills, such as: to identify relevant informations; to create strategies to acquire and to register the informations; to analyze the problem constraints and to maintain a dialog with the client. These are some of the skills that we want to develop with the proposed approach. According to POP, the ill-defined problem solving should occur in an iterative and incremental manner, and in two phases, that we call initial understanding and comprehension refining, as presented in Figure 1.

1 Andréa Pereira Mendonça, Computing and System Department, Federal University of Campina Grande, Paraíba, Brazil, [email protected] 2 Dalton Dario Serey Guerrero, Computing and System Department, Federal University of Campina Grande, Paraíba, Brazil, [email protected] 3 Evandro de Barros Costa, Computing Institute, Federal University of Alagoas, Alagoas, Brazil, [email protected]

FIGURE 2 DIALOG STRATEGIES.

FIGURE 1 PHASES OF THE PROBLEM ORIENTED PROGRAMMING.

On the initial understanding phase, the students receive from the client (teacher) the problem statement and must produce an artifact, that we call initial specification. We may understand the problem statement as a user story, and the initial specification document as a more refined user story description. This user story refinement is done by the students. It means that, it is up to the students to discover the relevant information to enlighten the problem, turning it from ill-define to a better-defined one. The process of requirements discovery occurs through the free dialog between the students (programmers) and the client (teacher). The intent in this phase is that the students may experience a context as close as possible to the real world in which they may perform the activities of elicitation and specification of requirements. The resulting document from the specification does not follow a template. The students must express the problem specification on a textual format, expanding the problem statement previously presented by the client (teacher). The option to adopt a text based document without a pre-defined format is justifiable by the simplicity needed in this phase (one must acknowledge that we are dealing with beginner students). Guidelines regarding style and the organization of the specification document are provided to the students. On the initial understanding phase, where the dialog is free, it is important that the students may do quality questioning. For that matter, dialog strategies were developed in order to assist the students on their problem related reflections and on their ability to clearly express their doubts. Additionally, these strategies encourage them to acquire autonomy regarding their own learning process. To define these strategies, we observed, during a semester, the interactions of the students through a discussion list. The dialog strategies are structured in three dimensions: purpose, form and content, (Figure 2) and this structure was inspired on the work of Lane [14].

The purpose concerns the pedagogic goal that it aims to achieve. The form indicates the structure of the interaction and the content simply reveals what the form refers to. For instance, on the case where the students ask about a determined requirement, the dialog purpose is to enlighten informations. This purpose can be achieved through a direct answer (form), containing the problem-related information (content). When the students succeed to establish an agreement with the client (teacher) concerning what has to be done, and express it by the initial specification document, they enter to the comprehension refinement phase. This phase occurs gradually during the problem solution. The dialog in this phase is still the strategy to elicitate requirements; however, now it must be proceeded in a more structured way, on a test case form. Tests are then understood as a question, written on a structured syntax that asks the client (teacher) about the problem requirements and constraints. In this phase, we encourage the practice of another software engineering activity – testing. However, we do not perform it with the strictness of TDD (Test Driven Development), where the tests must always precede the programming [16]. The most important thing concerning this phase is that the students may use tests as an effective practice that aids the discovery and confirmation of requirements, the reflections concerning problem correctness and the analysis about possible errors that may occur. To maintain the continuity on the student developed activities, they are encouraged to update the specification document, by adding test cases. Then, the dialog that was free of form becomes structured in reason of the syntax of the test cases. The students can keep improving the problem comprehension by the confirmation or specification of new requirements. In this phase, the problem comprehension is measured by the quantity of tests covered by the students. There may be the possibility that the students deliver the program to the client (teacher) without attend all the functionalities, then a new cycle of comprehension refinement should begin. Both phases encourage the students to make a reflection about the problem before start the programming. To elaborate the document with the initial specification, for

instance, the students must explore the problem statement, detect the informations that may be missing, ambiguous or even contradictory; and must also enlighten these informations through the dialog and register them on the document of specification requirements in an organized way. On the second phase, the comprehension refining phase, the students refine the previous activities and will develop skills to test, and consequently, to analyze the problem restrictions. Considering that ill-defined problems are a reality to programming professionals, when we give the students an opportunity to develop a wider range of strategies to solve these problems, such as in POP, we contribute to the development of skills that meets the software industry needs.

Janzen and his collaborators that use an approach called TDL (Test Driven Learning) [10]. It is worth to notice that POP changes the traditional roles, both for teacher and students, establishing a different kind of relationship between them: clients and programmers. This change allows the students to experience the typical problems that arise in this kind of relationship, to develop negotiation skills and also to improve their communication abilities. In addition, it contributes to create a more professional and responsible attitude on the students.

TECHNICAL AND PEDAGOGIC GROUNDINGS

The approach is being applied on the Computer Science Course of the Federal University of Campina Grande, Brazil, with beginner programming students. Python is the programming language adopted and the tests are performed using asserts, a command from the referred language. The programming class has 53 students and we rely on the support of 9 teaching assistants. The assistance provided by teaching assistants is a practice of the Computer Science Course, to maximize the support to the students, both in class and extra class. Each teaching assistant is responsible for a group of students. On applying this approach, they act as the clients. This is a pilot case study with the use of POP on a real context, and it aims to evaluate the effects evoked by this approach, to adequate evaluation metrics and to obtain feedback from the students, teaching assistants and teachers from this course. The results obtained with this case study will guide the POP application planning for the next semester, then assuring a more refined evaluation of the approach.

Similarly to the Problem-Based Learning (PBL), on POP, the problem is the motivating element of the learning process, and it must be in context with real world scenarios, allowing a broader cognitive engagement [3]. When software engineering principles are brought to the initial grades, POP is aligned with the inverted curriculum principles that value the integral and progressive academic accomplishment of the students, respecting their cognitive levels [5, 19]. The POP approach favors the joint development of the following skills: problem specification and program codification. Therefore, the learning-teaching activities don’t have to be broken into the courses of Programming (that deals with program codification) and Software Engineering (which, amongst other things, deals with requirements specification and elicitation). The joint development of these skills on an early stage allows the students to develop more general strategies that can be useful to other courses in the curriculum, such as Database, System Analysis, etc. POP is also according to the practices backed by the agile development processes, more specifically the XP development process (eXtreme Programming) [15], that develops well accepted abilities in the software community, such as effective communication with clients (in this case, the teacher), simple documentation and progressive comprehension of the needed requirements. When establishing a dialog strategy through tests (structured dialog), POP makes possible the practice of yet another activity on software engineering – testing. When the students make their test cases explicit, they evidence their understanding concerning the problem, they make explicit their reflections on the problem constraints and error conditions that may affect the program performance. Since the dialogs are written on a structured syntax, the tests remove the ambiguities, which are often found on a natural language-based dialog. In the academia, test practices teaching are being systematically studied and encouraged by

APPROACH APPLICATION

RELATED WORK The idea of problem specification practicing since the beginning of students training has been defended by other authors [9,11,12]. Brown [9] and Eastman [11], for example, focus on the definition of a standard document for problem specification. POP differs from this approach: we believe that the non-adoption of the standard document for problem specification brings more simplicity to beginner students of programming, because they will not be anxious or worried with the adjustment of the problem description for a predefined format, keeping the focus on the main activity which is to refine the problem description to meet the needs of the client. Deek [12] proposed a model for problem solving known as “Dual Common Model for Problem Solving and Program Development”. The proposed model is composed of six stages that remember the life-cycle of software

development in cascade – process of formulating the problem, planning, designing, translating, testing and delivering the solution. In the problem formulation stage, the students must extract from the problem statement important elements and register those elements in a standard document. The standard document is composed of the following elements: goal, givens, unknowns, conditions and constraints. These elements were strongly based on the work of Polya [13]. Differently from Deek, our perspective is that the cycle of problem understanding and solving must be iterative and incremental, such as the cycle of the agile software development. In POP, the problem understanding is not based only on the information extraction from the problem statement, endorsed by the use of ill-defined problems, in which not all details are present, demanding a process of interaction with the client (teacher) through the dialogue, a fact that wasn’t enough emphasized in the work of Deek. Rahman and Juell [20] proposed a software development method to be used in introductory programming courses. This method is called “Testing Before Coding” (TBC) which emphasizes the software testing cycles as a strategy for improving the understanding, codifying and program quality. The TBC defends the design of tests before the codification, similarly to the approach of TDD. Desai and collaborators [6] in their researches towards the use of TDD in academia show evidences of resistance from the beginner students regarding this practice. In POP, as stated before, we encourage the writing of tests, but without the obligation of writing it before programming. The most important is that the students write and execute tests as a way to express their understanding of the problem, discover problem constrains and create a program of quality. The tests are used as a strategy of dialog between client (teacher) and developer (student) and are also according to Test Driven Learning [10].

CONCLUSIONS On this article we have presented a programming teaching approach, called “Problem Oriented Programming”. This approach gives the beginner student the opportunity to experience the reality of dealing with ill-defined problems and to perform software engineering activities, such as tests, requirements elicitation and specification. The proposed approach may be adopted on traditional programming courses and be combined with other approaches, such as PBL [18] or the Thematic Oriented Methodology [8]. Its adoption does not require previous knowledge on software life-cycle, testing or requirements engineering.

We believe that POP brings three significant contributions: (i) allows the beginner student to develop other practices besides the program coding, such as those from software engineering; (ii) organizes a procedure of teaching-learning that can be replicated in other universities, and (iii) collaborates through the results for a future discussion on the gradual integration of the curriculum, in which the students don’t have to wait until the courses of Software Engineering or Systems Analysis to develop skills of requirements specification. As shown in [1], the programming teaching can be viewed as one of the seven great challenges on computing education. Amongst the quoted challenges are: the challenge of carrying out systematic studies to improve the comprehension of human abilities on this domain and to provide teaching methodologies that may develop the necessary skills not only to the programming practice but also to the software engineering. We believe that evaluating the proposed approach we are contributing to elaborate solutions and to overcome these challenges. On future works we intent to report the results gathered from the pilot case study that is under development at the Federal University of Campina Grande and plan a new case study of the approach. Its design and execution will follow the guidelines of Kitchenham and Pfleeger [4]. We are also developing software to automatize the evaluation of the programs submitted by the students. This software will support the approach application and will provide a set of statistical data (amount of tests covered by the students, how many submissions it took for the program to pass all tests, recurrent errors, among others) that will enable a more detailed evaluation of the student’s performance.

ACKNOWLEDGMENTS We would like to thank Professor Clara Amélia de Oliveira for her valuable contributions and we would also like to thank the Foundation of Research Support from the State of Amazonas for its financial support.

REFERENCES [1] Andrew McGettrick, Roger Boyle, Roland Ibbett, John Lloyd, Gillian Lovegrove, and Keith Mander. Grand challenges in computing education. Technical report, British Computer Society, 2004. [2] Anna Eckerdal, Robert McCartney, Jan Erik Moström, Mark Ratcliffe, and Carol Zander. Can graduating students design software systems? SIGCSE Bull., 38(1):403–407, 2006.

[3] Barbara J. Duch, Susan E. Groh, and Deborah E. Allen. The Power of Problem-Based Learning: a practical ”how to” for teaching undergraduate courses in any discipline. Stylus Publishing, 2001. [4] Barbara Kitchenham, Lesley Pickard, and Shari Lawrence Pfleeger. Case studies for method and tool evaluation. IEEE Softw., 12(4):52–62, 1995. [5] Bertrand Meyer. Towards an object-oriented curriculum. In TOOLS ’93: Proceedings of the eleventh international conference on Technology of objectoriented languages and systems, pages 585–594, Upper Saddle River, NJ, USA, 1993. Prentice-Hall, Inc. [6] Chetan Desai, David Janzen, and Kyle Savage. A survey of evidence for test-driven development in academia. SIGCSE Bull., 40(2):97–101, 2008. [7] Ciaran O’Leary, Deirdre Lawless, Damian Gordon, Li Haifeng, and Kamal Bechkoum. Developing a software engineering curriculum for the emerging software industry in china. In CSEET ’06: Proceedings of the 19th Conference on Software Engineering Education & Training, pages 115–122, Washington, DC, USA, 2006. IEEE Computer Society. [8] Clara Amelia de Oliveira. Curriculum development in engineering and computer science as a theoretical foundation towards globalization demands in education. International Conference on Engineering Education ICEE, Hungary – Pécs-Budapest, 2008. [9] Dale A. Brown. Requiring CS1 students to write requirements specifications: a rationale, implementation suggestions, and a case study. In SIGCSE ’88: Proceedings of the nineteenth SIGCSE technical symposium on Computer science education, pages 13– 16, New York, NY, USA, 1988. ACM. [10] David S. Janzen and Hossein Saiedian. Test-driven learning: intrinsic integration of testing into the CS/SE curriculum. In SIGCSE ’06: Proceedings of the 37th SIGCSE technical symposium on Computer science education, pages 254–258, New York, NY, USA, 2006. ACM. [11] E. Grant Eastman. Fact-based problem identification precedes problem solving. J. Comput. Small Coll., 19(2):18–29, 2003. [12] Fadi P. Deek, Murray Turoff, and James Mc Hugh. A common model for problem solving and program development. IEEE Transactions n Education, 42(4), 1999. [13] George Polya. A Arte de Resolver Problemas: um novo aspecto do método matemático. Tradução Heitor Lisboa de Araújo (2a Reimpressão). 1978.

[14] H. Chad Lane. Natural Language Tutoring and the Novice Programmer. PhD Thesis, University of Pittsburg. Department of Computer Science, 2004. [15] Kent Beck. Extreme programming explained: embrace change. 2000. [16] Kent Beck. Test-Driven Development By Example. Addison Wesley, 2002. [17] Kristina Winbladh. Requirements engineering: closing the gap between academic supply and industry demand. Crossroads, 10(4):4–4, 2004. [18] Lorna Uden and Chris Beaumont. Technology and Problem-Based Learning. INFOSCI – Information Science Publishing, 2006. [19] Michela Pedroni and Bertrand Meyer. The inverted curriculum in practice. SIGCSE Bull., 38(1):481–485, 2006. [20] Syed M. Rahman and Paul L. Juell. Applying software development lifecycles in teaching introductory programming courses. In CSEET ’06: Proceedings of the 19th Conference on Software Engineering Education & Training, pages 17–24, Washington, DC, USA, 2006. IEEE Computer Society.