|Teaching and Learning Forum 2004 [ Proceedings Contents ]|
Lynne Fowler, Vivian Campbell and Geoffrey G Roy
School of Engineering, Murdoch University
Today most students use software tools to aid their studies. These range from basic word processors to more specific tools such as statistical and accounting packages in a variety of application domains. Our observations show that often the software tool is not used wisely but abused. That is the students often use the tool as if it will do the thinking for them. This has led us to ask the question: "How should we use software tools and technology to achieve success and excellence?" In this research we are specifically looking at student use of software for programming although some of the conclusions are relevant to students 'using' or 'abusing' most software tools Retention of first year students is also an issue because all our engineering students have to complete the two first year Java programming units. We feel our engineering students need good programming skills even if it is for writing only small macros or programs. P-Coder is a CASE tool, developed by the third author on this paper, within the School of Engineering Science, and is aimed as a support tool to assist in the teaching of novice programmers by supporting and emphasising the design process. This research is supported by analysing students learning styles. This has led us to question whether certain learning style traits lead to greater success on our programming units.
A lot of research has been done on the useability of software tools but this has focused on whether the student can understand the environment and find their way around to perform specific tasks (Lecerof & Paterno, 1998). It might be expected that, with today's more user-friendly interfaces running on powerful computers, life would be easier for the novice programmer. Current tools to support code production are numerous and have varying degrees of complexity and functionality. However, there has not been much research in the area of using the tool 'correctly', that is in a way to both achieve the desired results on a given task and support learning.
Computer Aided Software Engineering (CASE) tools were hailed as the answer to our software needs but then several years on success has been elusive (Gabel, 1994). CASE, is defined broadly:
".. as tools and methods to support an engineering approach to software development at all stages of the process. By 'engineering approach' we mean a well-defined, coordinated and repeatable activity with accepted representations, design rules and standards of quality." (Forte & Norman, 1992).Many CASE tools are complex and/or are perceived as complex to learn (Iivari, 1996). This may be because CASE tools have typically been designed to assist experts achieve their tasks. The question of whether the tool is appropriate for the novice and more especially, whether it is useful to assist their learning, has been ignored. Students need to come to terms with the tool as well as the domain, which makes their task all the harder. The focus must shift from "ease of use - to ease of learning " (Soloway, Guzdial, & Hay, 1994) and then to 'correct usage' of the tool. Novices are always going to be with us and we need to direct and encourage their use of software tools.
It is true that most software tools have interfaces and facilities that appear 'heaven sent' by those of us that used computers in the 1970s and 1980s but despite this novice programmers have many problems. Today's fast machines should produce an increase in productivity for our students. However, we find that students are often expecting the tool and more specifically a program complier to 'think' for them.
Observation of students indicates that they are not spending enough time thinking about their programs but just persist in running them and blindly trying to solve syntax problems by adding semi colons, braces and other elements of syntax, when really their problem is one of poor or incorrect design. In the early days of programming when you were constrained to only one run per day more effort was expended on design and precision.
Students misuse of programming tools is akin to using a word processor to write an essay and using all the facilities like cut, paste, spell checker and grammar checker without giving serious thought to the structure and content of the essay.
The programmer's task is to clarify the problem, identify a solution and translate it into the target programming language. Testing and debugging are the final steps in creating a software solution. The problems in achieving these tasks by novice programmers have been studied for many years (Mayer, 1981), (Irons, 1982), (Bonar & Soloway, 1983). However, this has done nothing to change the fact that learning to program is still considered to be difficult. It is both a complex and multifaceted task. Novices face a myriad of concepts, some of which may be more complex because of the inconsistency between terms in programming and natural language (Bonar & Soloway, 1983), all of which must be understood before it is possible to synthesise them to produce a working program that solves a real problem.
The process of learning to program has become more complex with the introduction of the object-orientated (OO) paradigm and a wide range of development environments and programming languages. Educational research is now trying to catch up with these changes (Barr, Holden, Phillips & Greening, 1999; Kolling & Rosenberg, 2001; White, 2002). Java has become the language of choice for many institutions worldwide and textbooks now support teaching introductory programming with OO techniques (Poplawski, 2002), (Barnes & Kolling, 2003). Yet students still need to understand the basic building blocks of computation: namely sequence, selection, iteration and recursion.
Novice first year programmers have to grapple with complex integrated environments and at the same time learn and apply the basic programming constructs. BlueJ, one of the tools used in our first year, is a typical example of a simple integrated development environment designed for teaching programming (Kolling & Rosenberg, 2001). It incorporates a compiler and other tools. The main purpose of a compiler is to translate the high-level language source code written by the programmer into low-level code that can be executed by a computer.
Our novice programmers can use tools like Blue J and effectively find their way around the software but they often abuse the tool by trying to program and compile every few minutes without thinking about the structure of their programs. They appear to be preoccupied with low-level syntactic issues (Barr et al., 1999). Their expectations are that the compiler will 'sort it all out' and locate all errors in their program, forgetting that only low-level syntax errors will be located.
Students of the 2000s have grown up to expect computers to instantly react to their command. Mastery of the most complex of computer games, which represents most students' previous experience, can be relatively easily acquired when compared to software development. These games have an exciting visual appearance and quite reasonably students want their programs to look like those that they have seen. A danger is that the major effort in programming is expended on developing a facade that ignores the realities of good design or a robust application.
There are also large individual differences in productivity and achievement in programming tasks undertaken by students. An informal survey on one of our classes revealed a difference of a factor of 10, in time taken to complete a small programming assignment. Productivity differences as high as 100 to 1 have been reported (Schneiderman, 1986) in experienced programmers. Clearly for many programmers there is ample opportunity to improve their levels of efficiency.
We feel our students need to be directed to design their programs effectively and use the correct programming constructs. In order to move the emphasis of student effort off 'fighting the compiler' to achieving good design we have developed, a tool called PCoder.
One of the inventories we have used is The Kolb Learning Style Inventory (Kolb, 1984). Students taking this year's G108 and G109 1st year programming units have been tested to relate their scores to the use of our PCoder tool (G108 Engineering Computing 1 is the first programming unit in semester one and G109 Engineering Computing 2 is the second unit in semester 2, taken by all engineering students).
|Clients||No. of clients||Accommodator||Diverger||Assimilator||Converger|
|Engineering 1st year students||126||8%||18%||33%||41%|
|1st years 2003 only (G108)||48||4%||8%||42%||46%|
|Year 12 all students||112||26%||10%||44%||20%|
|4th year engineering students||29||3%||7%||40%||52%|
The Kolb results show that our staff and students are mainly assimilator and converger types, Table 1. This is in line with Kolb stating that a suitable career for convergers is engineering and that teaching is good for assimilators (Kolb, 1984). Figures 1 and 2 show the distribution of student scores across Kolb's four quadrants. We have superimposed horizontal bands across the quadrants to emphasise that our students fall mainly in the bottom /lower band. This indicates a strong preference for converger and assimilator learning styles. Our analysis of the students on the first and second semester Java units, G108, G109, Figure 1 and Figure 2, demonstrates that the second semester unit has a higher proportion of strong assimilators and convergers, 81% compared to 65%. This second unit cohort includes the students who passed the first unit and additional students who for various reasons did not do the G108 unit this year. These results indicate that we are attracting and favouring the assimilator and converger learners. This may be related to the fact that students learn better if their learning style aligns with the teacher (Felder & Silverman, 1988).
By requiring our students to consider the design, of their programs, using PCoder, and directing them to work in an ordered logical process we are also directing certain learning style traits. We are aiding students to develop a sequential approach to programming and also enabling them to get a global, big picture but preventing development in an ad hoc manner.
Our results raise the following questions:
Figure 1: Assessment of learning styles for students in 2003 - G108
Figure 2: Assessment of learning styles for students in 2003 - G109
There is an underlying need to understand the very basic computational processes (sequence, selection, iteration, and recursion) no matter which programming language is being used. In modern teaching practice it seems essential that both procedural and OO concepts are required elements. The challenge is to get the balance right, and, if possible, demonstrate that these concepts form part of a continuum of knowledge that is required by the competent student.
PCoder has its origins in pseudocode principles, but also adds some additional OO concepts that are integral to many modern programming languages. Pseudocode provides an intermediate step in the programming process - a step that can be seen to relate to both the informal specification and also to the final code. In its current form, P-Coder is Java oriented and allows code to be generated automatically. The emphasis for the students is now on design rather than syntax. Figure 3, illustrates the designer view within P-Coder, which is used as an entry point for the main programming constructs.
Figure 3: Design view in PCoder
PCoder is textual and graphical, aiding both the visual and verbal style of learners, with a heavy emphasis on the use of colour (figure 3 and figure 4). Within PCoder students work sequentially and progressively, while being able to see the overall design. Students are not able to rush to code as the CASE tools generates the basic, commented code from the design which forces them to think about the constructs without getting tied up with coding syntax. The design process encouraged within PCoder requires students to describe their computational process in a highly structured way, as an execution tree, using both graphical and textual clues to define the required computational elements. As a result the whole program is described visually before there is any need to think about coding. We feel that an improved understanding of the semantics of the program at this stage will make a contribution to learning the principles compared with the need to understand the syntax of the programming language.
Figure 4: Graphical image from PCoder used for the basic constructs
Research shows that users of software tools feel that activities that are unsupported are perceived as being less important and are often neglected (Eriksen & Stage, 1998). Having a tool that supports the design process helps in emphasising the importance of the design stage. This then facilitates the abstraction process whereby students must apply the basic programming constructs.
Figure 5: Comparison of exam marks for G108 in 2002 and 2003
This innovative tool has been used for the first time in 2003 in the first semester, first year, programming unit, G108 and then used as a support tool in the second semester second programming unit G109. Figure 5 summarises and compares the students' results for the last two years, on the first unit G108. The number of students to complete G108 was 43 (2002) and 46 (2003). The class average increased from 52.9 in 2002 (no PCoder) to 58.00 in 2003 (with PCoder). These comparisons only look at the total aggregated mark for the unit. Further investigations are being carried out however the early signs are encouraging.
The analysis of the students learning styles has aided us to identify the differing needs of our students and for us to consider interventions that lead to Engineering students having a deeper understanding of basic computational results.
We feel the issues put forward in this paper are of paramount importance not just to Engineering students. All students will have to use technology and software tools to support their diverse areas of study and if students cannot effectively use the software tools they will be handicapped in their learning. Therefore as educators we need to direct the use of these software tools and train students not only to use the software tools but use them effectively and not abusively in order to maximise the technology available to the full.
Barr, M., Holden, S., Phillips, D. & Greening, T. (1999). An exploration of novice programming errors in an object-oriented environment. SIGCSE Bulletin, 31(4), 42-46.
Bonar, J. & Soloway, E. (1983). Uncovering principles of novice programming. Paper presented at the Proceedings of the 10th ACM SIGACT-SIGPLAN symposium on Principles of programming languages.
Eriksen, L. B. & Stage, J. (1998). A qualitative empirical study of CASE tool support to method learning. Information and Software Technology, 40, 339-345.
Felder, R. & Silverman, R. L. (1988). Learning and teaching styles in engineering education. Engineering Education, 78(8), 674-681.
Forte, G. & Norman, R. J. (1992). A self-assessment by the Software Engineering community. Communications of the ACM, 35(4), 28-32.
Fowler, L., McGill, D., Armarego, J. & Allen, M. (2002). Quantitative learning conversations: Constructivism and its application to learning in an engineering environment. Proceedings HERDSA Conference, Edith Cowan University, Perth WA. http://www.ecu.edu.au/conferences/herdsa/main/papers/ref/pdf/Fowler.pdf
Gabel, D. A. (1994). Technology 1994 software engineering. IEEE Spectrum, 31, 38-41.
Holmes, N. W. (1999). The myth of the educational computer. Computer, 32(9), 36-42.
Iivari, J. (1996). Why are CASE tools not used? Communications of the ACM, 39, 94-103.
Irons, D. M. (1982). Cognitive correlates of programming tasks in novice programmers. Conference on Human Factors , ACM Washington DC Chapter, pp219-222. http://portal.acm.org/citation.cfm?id=801783&jmp=abstract&dl=GUIDE&dl=ACM
Kolb, D. A. (1984). Experiential Learning Experience as the Source of Learning and Development. New Jersey: Prentice-Hall.
Kolling, M. & Rosenberg, J. (2001). Guidelines for teaching object orientation with Java. ACM SIGCSE Bulletin, Proceedings of the 6th annual conference on Innovation and technology in computer science education, 33(3), 33-36.
Lecerof, A. & Paterno, F. (1998). Automatic support for usability and evaluation. IEEE Transactions on Software Engineering, 24, 863-888.
Mayer, R. E. (1981). The psychology of how novices learn computer programming. Computer Surveys, 13(1), 121-140.
Poplawski, D. A. (2002). Objects have class: An introduction to programming with Java. Boston: McGraw Hill.
Schneiderman, B. (1986). Empirical studies of programmers: The territory, paths and destinations. In E. Soloway & S. Iyengar (Eds.), Empirical Studies of Programmers (pp. 1-12). Norwood, NJ: Ablex Publishing Corp.
Sleeman, D. (1986). The challenges of teaching computer programming. Communications of the ACM, 29(9), 840-841.
Soloway, E., Guzdial, M. & Hay, K. E. (1994). Learner-centered design: The challenge for HCI in the 21st century. Interactions, 1(2), 36-48.
White, G. (2002). Cognitive characteristics for learning C++. The Journal of Computer Information Systems, 42(3), 51-56.
|Contact person: Lynne Fowler|
School of Engineering Science, Murdoch University, Rockingham Western Australia 6168
Tel: (08) 9360 7119 Fax: (08) 9360 7104 Email: email@example.com
Please cite as: Fowler, L., Campbell, V. and Roy, G. G. (2004). The use and abuse of software tools. In Seeking Educational Excellence. Proceedings of the 13th Annual Teaching Learning Forum, 9-10 February 2004. Perth: Murdoch University. http://lsn.curtin.edu.au/tlf/tlf2004/fowler-l.html