Model-Driven Programming Jens Bennedsen* and Michael Caspersen# *IT University West Fuglesangs Allé 20 DK-8210 Aarhus V Denmark
[email protected] #Department of Computer Science University of Aarhus Aabogade 34, DK-8200 Aarhus N Denmark
[email protected]
ABSTRACT Conceptual modeling is the defining characteristic of object-orientation and provides a unifying perspective and a pedagogical approach focusing upon the modelling aspects of object-orientation. Reinforcing conceptual modelling as a basis for CS1 provides an appealing course structure based on core elements from a conceptual framework for object-orientation as well as a systematic approach to programming; both of these are a big help to newcomers. The approach has a very positive impact on the number of students passing the course.
INTRODUCTION
Three implementations of a programming-first curriculum Over the years there have been ongoing discussions on the content of an introductory programming course. In order to define a common curriculum including an introductory course, ACM and IEEE established the Joint Task Force on Computing Curricula 2001. The charter was: “To review the Joint ACM and IEEE CS Computing Curricula 1991 and develop a revised and enhanced version for the year that will match the latest developments of computing technologies in the past decade and endure through the next decade”. In the final report (The joint task force 2001), the role and place of programming in the curriculum is discussed. Is programming what needs to be taught first (what they call a programming-first approach) or are there
2
other topics that need attention first? The conclusion is: “the programming-first model is likely to remain dominant for the foreseeable future”. (REF) The report describes three implementations of a programming-first curriculum based on three programming paradigms: The imperative, the functional and the objectoriented paradigm. The object-oriented paradigm has gained much interest in the past decade resulting in many textbooks (e.g. (Arnow, Dexter & Weiss 2004, Barnes & Kölling 2003, Horstmann 2001, Niño & Hosch 2001) and much interest among teachers on implementing the object-first strategy (e.g. Alphonce & Ventura 2002, Cooper et al 2003). Objects-first curriculum Objects-first is not a well-defined term. It seems that every CS1 teacher has his or her own interpretation of the term (e.g. Cooper, Dann,& Pausch 2003, Jones, Boyle & Pickard 2003, Kölling & Rosenberg 2001, Schmolitzky 2004).The Joint Task Force (2001) described objects-first as: “an objects-first approach that emphasizes early use of objects and object-oriented design” (p. 28). What does early mean, and what is meant by object-oriented design? Lewis (2000) discusses nine myths about object-orientation and its pedagogy; one is that the phrase “objects first” is well defined. The author writes: “No matter what your definition of objects first is, it is likely to be different from that of the person next to you.” (p. 247), and “The phrases ‘objects first’ and ‘objects early’ are bandied about in a variety of contexts. When discussing a CSI course they are often used to convey the general idea that objects are discussed early in the course and established as a fundamental concept. Beyond that, however, these phrases seem to take on a variety of meanings, with important implications.” (p. 246). Our definition of objects-first is: • Objects from day one – in the beginning the student uses objects, then he imitates the implementation and finally he creates objects. • A balanced view on the three perspectives on the role of a programming language (see next section) • Enforcing the use of a systematic way to implement a description of a solution (see section XXX) The role of the programming language In (Knudsen & Madsen 1990) three perspectives on the role of a programming language are described: • Instructing the computer: The programming language is viewed as a high-level machine language. The focus is on aspects of program execution such as storage layout, control flow and persistence. In the following we also refer to this perspective as coding. • Managing the program description: The programming language is used for an overview and understanding of the entire program. The focus is on aspects such as visibility, encapsulation, modularity, separate compilation.
Model-Driven Programming
3
• Conceptual modelling: The programming language is used for expressing concepts and structures. The focus is on constructs for describing concepts and phenomena. These represent a widespread three-level perspective on object-oriented programming as represented by the three abstraction levels for the interpretation of UML class models (Fowler 2000): conceptual level, specification level and code/implementation level. When designing a programming course one decides how much time, effort and focus are given to each of the three perspectives. It is possible just to focus on the first, instructing the computer, and ignore the two others. This results in a course where the details of the programming language are in focus but where the students do not learn the underlying programming paradigm. If on the other hand one just focuses on conceptual modeling (using a case-tool to generate code), the result is a course where the students cannot produce code by themselves. We find it vital to balance the three views on the role of the programming language by including conceptual modeling. The primary advantages are • A systematic approach to programming • A deeper understanding of the programming process • Focus on general programming concepts instead of language constructs in a particular programming language. Most of the descriptions and discussions of the object-first strategy tend to focus on instructing the computer and managing the program description (see e.g. Rountree, Rountree & Robins 2003). To our knowledge, no introductory programming textbook exists that includes conceptual modeling, and we have been able to find only one article discussing the adoption of conceptual modeling in CS1 (Alphonce & Ventura 2002). It is our experience from many years of teaching CS1 that including conceptual modeling perspective has a great impact on the student’s skills and their understanding of the programming process. It is our firm conviction that the general omission of conceptual modeling is the major reason for the problems identified in (The Joint Task Force 2001, p. 23): ”Introductory programming courses often oversimplify the programming process to make it accessible to beginning students, giving too little weight to design, analysis, and testing relative to the conceptually simpler process of coding. Thus, the superficial impression students take from their mastery of programming skills masks fundamental shortcomings that will limit their ability to adapt to different kinds of problems and problem-solving contexts in the future.” The Joint Task Force (2001) generally ignores conceptual modeling in the object-first recommendations for CS1. Aspects of conceptual modeling are mentioned only briefly and the recommended time to be used on the subject is four core hours!
CONCEPTUAL MODELING In (Madsen, Møller-Petersen & Nygaard 1993) object-oriented programming is defined as follows:
4
A program execution is regarded as a physical model, simulating the behavior of either a real or imaginary part of the world. The key point here is model. An object-oriented program is a model, and this model can be viewed at different levels of detail characterized by different degrees of formality: An informal conceptual model describing key concepts from the problem domain and their relations, a more detailed class model giving a more detailed overview of the solution, and the actual implementation in an object-oriented programming language. Object-orientation has a strong conceptual framework (notions of concepts and phenomena, identification of objects, identification of classes, classification, generalization and specialization, multiple classification, reference- and part-of composition). One of the advantages of the conceptual framework is that it gives an integrating perspective on analysis, design and programming thus making it much easier for the students to understand these normally fuzzy concepts. Analysis is that process by which you create a conceptual model of the problem domain, design is that by which you fit the model to the restrictions of the particular programming language, and implementation is that by which you implement the design model. Omitting this integrating perspective and focusing only on object-orientation for implementation will leave out one of the most important assets of object-orientation. We focus on the conceptual modeling perspective, emphasizing that objectorientation is not merely a bag of solutions and technology, but a way to understand, describe and communicate about a problem domain and a concrete implementation of that domain. The integration of conceptual modeling and coding provides structure, traceability and a systematic approach to program development which strongly motivates and supports the students in their understanding and practice of the programming process.
STRUCTURE OF A MODEL-FIRST COURSE In this section we discuss different aspect of a model-first programming course: Progression, goals, on example of a model-first course describing the progression in terms of the concepts from the object-oriented conceptual framework. Progression One of the key problems in designing a programming course is to define the progression – what to start with, what next and so on. Traditionally one starts with the simple things, but that quickly rises the question is: “Simple related to what?” Traditionally the answer is “Simple programming constructs” i.e. the progression is defined by the complexity of the programming language. Robbins, Rountree and Rountree (2003) conclude that “typical introductory programming textbooks devote most of their content to presenting knowledge about a particular programming
Model-Driven Programming
5
language” (pp 141), that is to say the majority of them are based on an “instructing the computer” or “managing the computer” perspective. The approach taken here is to use the three perspectives on the role of the programming language as a guide for the structure of the course. In the first half of the course, roughly speaking, focus is concurrently on conceptual modeling and coding; in the second half of the course the primary focus is on internal software quality, i.e. managing the program description. The answer to the question on “simple related to what” is therefore simple related to the complexity of the underlying conceptual model. In section (XXX) our course design is presented. The interpretation is what we find simple and complex in the object-oriented conceptual framework; other interpretations are of cause doable. If you e.g. find inheritance simpler than association, then the next concept to introduce after the class concept is inheritance. Apart from using the complexity of the underlying conceptual framework as a definition of progress we also use the “early bird” pedagogical pattern (Bergin): “The course is organized so that the most important topics are taught first. Teach the most important material, the "big ideas," first (and often). When this seems impossible, teach the most important material as early as possible. Goals Given this viewpoint, one of the learning goals should be the development of systematic ways of implementing general class models and obtaining through this, a deeper understanding of the programming processes. Gries (1974) makes an analogy to cabinet making and puts it thus: Suppose you attend a course in cabinet making. The instructor briefly shows you a saw, a plane, a hammer, and a few other tools, letting you use each one for a few minutes. He next shows you a beautifully finished cabinet. Finally he tells you to design your own cabinet and bring him the finished product in a few weeks. You would think he was crazy! You would want instructions on designing the cabinet, his ideas on what kind of wood to use, some individual attention when you don’t know what to do next, his opinion on whether you have sanded enough, and so on. (p. 82) It is therefore regarded as important that the learners gain insights into how programmers develop their solutions to problems, on both an abstract and a concrete level, for example on the structures and the pragmatics described by du Boulay (1989) (see below). This implies focusing on general programming concepts instead of just the language constructs of a particular programming language. du Boulay (1989) describes five overlapping domains and potential sources of problems that the learner must grasp: 1. General orientation: What is the general idea of programs, what are they for and what can be done with them? 2. The notional machine: An abstract model of the machine when it executes programs (i.e. the meaning of the running program).
6
3. Notation: The syntax and semantics of the programming language used. 4. Structures: (Abstract) solutions to standard problems, a structured set of related knowledge. 5. Pragmatics: The skills of planning, developing, testing, debugging and so on. Since these five skills are closely related it is important to show the learners how they interact and not focus on just one or two of them. Coding and conceptual modeling is done hand-in-hand, with the latter leading the way. Introduction of the different language constructs are subordinate to the needs for implementing a given concept in the conceptual framework. After introducing a concept from the conceptual framework a corresponding coding pattern is introduced; a coding pattern is a guideline for the translation from UML to code of an element from the conceptual framework. This approach supports a spiral course layout (Bergin), reinforcing the most important concepts several times in the course. There are two criteria for the design of the spiral layout: the most common concepts of the conceptual framework are introduced first, and throughout the course the students must be able to create working programs. The conceptual framework is comprehensive; for CS1 we restrict the coverage to association, composition and specialization which by far are the most used concepts in object oriented modeling and programming. The starting point is a class and properties of that class. One of the properties of a class can be an association to another class; consequently the next topic is association. This correlates nicely to the fact that association (reference) is the most common structure between classes (objects). Composition is a special case of association; composition is taught in the next round of the spiral. The last structure to be thoroughly covered is specialization. Specialization is the least common structure in conceptual models, and it bridges nicely to the second half of the course where the focus is on software quality and design. A concrete implementation of a model-first course In the following subsections we describe some of the elements of the design of the course focusing on the first half of the course where modeling dominates. Getting Started We want to give the students an everyday understanding of object-orientation and a very informal understanding of the process of creating a UML class model. We therefore start by illustrating the concepts using everyday life situations in a role-play. The goal for the role-play is to illustrate structure and dynamics in terms of concepts, phenomena and messages in a problem domain and classes, objects and method calls in a corresponding (class and program) model. We use UML (primarily class diagrams) to describe concepts and their properties, without any formal introduction to the modeling language.
Model-Driven Programming
7
To introduce the students to basic coding we use a graphics package (Christensen & Caspersen 2000). The graphics package is presented in terms of a class diagram; hence, the students experience very early the strength of a class model as an abstract description of a program component as well as a communication tool; the UMLmodel provides an effective “language” for documenting and communicating about classes. This introductory part of the course provides an external view of classes and objects. For a further discussion on these problems, see Caspersen & Christensen “CS1: Getting started” this volume. Class After having used classes and objects we turn to an internal view and start writing classes; we do this by introducing the first coding pattern: Implementation of a class. A coding pattern is a general description of (one way of) implementation of an element of the conceptual framework. The students discuss a domain concept, select a few properties, and express the domain concept using UML. Using the coding pattern the UML-description is systematically translated into Java code. The general coding pattern are not show to the students; the students observe implementations of classes and little by little abstract over these different implementations of different models. The learning is from Diverging, accommodating, converging to assimilating in the four learning styles described by Kolb (1984). In this phase of the course the students learn about basic language constructs such as assignment, parameters, conditional statements; constructs needed for the systematic translation of model into code like classes and objects, state and behavior, primitive types and object types, reference, parameterization, this, methods, attributes and constructor As described before a spiral approach is used. This implies that for example the coverage of primitive types only what is strictly needed is taught. In this case we only use int and do not worry about the other types – they will be introduced when they are needed by the exercises. The focus is on a systematic way of programming. This implies three things: many examples are shown to the students, explicit use of UML and a focus on the programming process. The examples use are general concepts from the students every day life like Person, Account, Die and Date. We use BlueJ (Kölling, Quig, Patterson & Rosenberg 2003, Kölling this volume) as the programming tool. In BlueJ the user has a kind of UML diagram, but the internal details of the classes are not shown. We therefore use drawings of a UML class in order to explain an abstract understanding of a class. Since we find it important to focus on the programming process and not just the end products (the program), we use a lot of “live coding” (Hyland & Clynch 2002). The purpose of this is not to show the students the nice and linear way from problem to solution, but to show the students how a professional programmer attacks the problem, making the actions visible and a source of identification (Nielsen & Kvale
8
1997). For more elaboration on this see Caspersen & Bennedsen, The Programming Process this volume. Association In the model of the problem domain the most common structure between classes is an association. We use several examples with progressive complexity to illustrate the concept and its implementation. One Class with a Reference to Itself Through a number of progressive examples we illustrate that an association is a property of a class, a class can have more than one association, and an association is a dynamic relation. The students extend a previous example with a recursive association. One example is that a Person can be married_to another Person or the lover of another Person. This results in the model in figure 1.
Figure 1: One class with two associations In order to implement associations with 0..1 cardinality the student needs to know about programming language elements (e.g. reference and the null value). It also gives the students an understanding of interaction between objects (calling methods on other objects) and reference semantics. Another example of a recursive association is a simple adventure game where the rooms in the game are connected to other rooms I different directions. This can be modeled by the following model:
Figure 2: One class with four recursive associations Again the idea is that the students sees many implementations of the same general concept from the conceptual framework and realizes the general coding pattern:
Model-Driven Programming
9
Figure 3: General, recursive association This can be implemented using the following coding pattern: public class A { private A a; public void setA(A a) { this.a=a; } public A getA() { return A; } } Turning to 0..* associations imply that the student needs to know about Collections (either one of the Java standard Collections or the array type) and the need for iteration arises (an Iterator or an index variable and a simple loop). This is done using a simple algorithm pattern for sweeping through a collection. One example we use is the concepts of “friends” - a Person can have many friends:
Figure 4: A person with many friends
More Classes In order to get more interesting collaboration between classes, the next concept is associations between different classes. As a starting point we use a domain model with the following structure:
10
Figure 5: One customer can have many accounts The students quickly understand that an association between different classes in principle is the same as a recursive association. This is true for the implementation as well; again the students generalize to a generic coding pattern for 0..* associations. Composition, Specialization and Interfaces We treat the remaining elements of the conceptual framework, composition and specialization, in a similar way. As mentioned earlier, specialization bridges nicely to the second half of the course focusing on software design and quality. The primary quality aspect is coupling and the main language construct by which to achieve low coupling is interfaces. Interfaces play an important role in the separation of specification and implementation: the specification of properties of a domain concept and (different) implementation(s) of these properties.
ON THE ROLE OF CONCEPTUAL MODELING IN CS1 In the following we will discuss some of the aspects of integrating conceptual modeling in an introductory programming course. Systematic Approach to Programming The goal is to teach the students to appreciate and achieve quality software. By good quality software we mean modifiable software, i.e. readable and understandable programs with a good structure, low coupling and high cohesion. These quality measures are by no means obvious to newcomers, and how to achieve them is even harder. We need to teach the students guidelines for achieving it and a vocabulary to talk abut their programs in order to help them build quality programs. We reinforce five abstraction-levels of techniques for the systematic creation of object-oriented programs: 1. Problem domain model: Create a UML class model of the problem domain, focusing on classes and structure between classes 2. Model Java code: Create a skeleton for the program using the coding patterns. 3. Functionality Java code: Specify properties and distribute responsibility among classes. 4. Implementation of classes: Create class invariants describing the internal constraints that have to be fulfilled before and after each method call.
Model-Driven Programming
11
5. Implementation of methods: Use algorithm patterns for the traditional algorithmic problems like searching, sweeping. Use loop-invariants for the systematic construction of loops. In this paper focus is on the first two of these systematic techniques; we mention the other three to give the full picture of how we reinforce systematic techniques at different levels of abstraction. Providing Confidence To program is difficult! In McCracken et al (2001) the authors found “shockingly low performance on simple programming problems, even among second-year, collegelevel students at four schools in three different countries”. It requires knowledge and skills of many things such as the programming language, development tools and the capability of formulating a solution in such a way that a computer is able to understand it. Especially the last demand implies the need for creativity when programming. Students find the creative process very difficult. In a more traditional programming course students are guided by standard algorithmic techniques such as searching, sorting, divide and conquer etc. The problem is that algorithmic techniques do not help the students to create the overall structure of a solution; they do not know where and how to start because the mental gap between the problem description and an implementation in terms of algorithms is too big. Conceptual modeling gives a systematic and structured approach to programming which provides confidence and a safe ground for addressing the programming task. Most programming tasks are trivial and can be handled using simple standard techniques such as the generic coding patterns described above. By focusing on standard techniques first, the need for algorithmic creativity is reduced (and a thorough treatment is postponed to CS2). The Programming Process The modeling approach to programming invites for an iterative process where the program is developed incrementally. Through progressive exercises we reinforce such a process in order to imitate modern program development processes (Beck 2000). Abstraction One of the important skills we want our students to possess is the capability to abstract. One way of stimulating the student’s ability to abstract is to give several exercises with similar structure. One example from the bank domain is the model shown in XXX. In a student administration domain we have the following model:
12
Figure 6: A student can participate in many courses Initially the students see these two models as completely different, but gradually they realize they are both instantiations of the same abstract model:
Figure 7: Abstract to many association From this abstract model they can produce a corresponding generic coding pattern (see figure 5). import java.util.*; public class A {
private Collection bs; public A() { bs = new ArrayList(); } public Collection getBs() { return bs; } public void addB(B b)
{ bs.add(b); } Figure 5: Generic coding pattern for 0..* association Success factors Many authors have tried to identify variables that are predictors of success of students aiming for a university degree. In general education research investigated variables encompass gender (Sanders 1998), the educational level of parents (Ting & Robinson 1998) ACT/SAT scores (Brooks & DuBois 1995, Sanders 1998), and emotional factors (Szulecka, Springett, & de Pauw 1987). In the in the more topic specific area of introductory programming research also have been done to establish success factors (e.g. Bergin & Reilly 2005, Bryne & Lyons 2001, Hagan & Markham 2000, Ventura 2003, Bennedsen & Caspersen 2005).
Model-Driven Programming
13
It seems (Bennedsen & Caspersen 2005) that the factors for success on a modelbased programming course are as impossible to predict as in other CS1 courses. In (Bennedsen & Caspersen 2005) we found that the only statistical significant success factors among the factors studied were the math score from the qualifying exam and the amount of work the students did during the course. Other (Ventura 2003) have found math scores not to be a success factor. One interesting observation was that the intended major had no impact on the success of a model-based programming course.
CONCLUSIONS In the recommendations of the Joint Task Force on Computing Curricula 2001 we have identified conceptual modeling as a lacking perspective in CS1. We have described the characteristics of conceptual modeling and argued that it is the defining characteristic of object-orientation. We have described a general structure for CS1 with conceptual modeling as the driving force. Furthermore we have discussed a number of aspects of this structure including a systematic approach to programming. The approach described in this paper has been applied for three years. Apart from qualitative improvements as described above, the change has had a quantitative impact on the number of students passing the course. Before we started using conceptual modeling and other systematic approaches to the programming process the average percentage of students passing the exam were 52%. Since we switched to the approach described in this paper, the percentage of students passing the exam has increased to 79%.
REFERENCES Alphonce, C., and Ventura, P.J.: “Object-Orientation in CS1-CS2 by Design”, Proceedings of Innovation and Technology in Computer Science Education, Aarhus, Denmark, 2002. Arnow, D., Dexter, S., and Weiss, G., Introduction to Programming Using Java: An ObjectOriented Approach, Addison-Wesley, 2004. Barnes, D.J., and Kölling, M. Objects First with Java – A Practical Introduction using BlueJ, Pearson Education, 2003. Beck, K., Extreme Programming Explained, Addison-Wesley, 2000. Bergin, J., ”14 Pedagogical Patterns”, available on-line at “http://csis.pace.edu/~bergin/PedPat1.3.htm”. Christensen, H.B., and Caspersen, M.E.: “Here, There and Everywhere – On the Recurring Use of Turtle Graphics in CS1”, Proceedings of the Fourth Australasian Computing Education Conference, ACE 2000 Melbourne, Australia, 2000. Cooper, M. et al.: “Teaching Objects-First in Introductory Computer Science”, Proceedings of the 34th SIGCSE Technical Symposium on Computer Science Education, Reno, Nevada, USA, 2003, pp. 191–195. Fowler, M., UML Distilled – A Brief Guide to the Standard Object Modeling Language, Addison-Wesley, 2000. Horstmann, C.S., Big Java, John Wiley & Sons, 2001.
14 Knudsen, J.L., and Madsen, O.L., Teaching Object-Oriented Programming is more than Teaching Object-Oriented Programming Languages, DAIMI-PB 251, Department of Computer Science, University of Aarhus, Denmark, 1990. Lewis, J., and Loftus, W., Java Software Solutions: Foundations of Program Design, AddisonWesley, 2003. Madsen, O.L., Møller-Petersen, B., and Nygaard, K., Object-Oriented Programming in the BETA Programming Language, Addison-Wesley/ACM Press, 1993. McCracken, M., Almstrum, V., Diaz, D., Guzdial, M., Hagan, D., Kolikant, Y.B.-D., Laxer, C., Thomas, L., Utting, I., and Wilusz, T. “A multinational, multiinstitutional study of assessment of programming skills of first-year CS students”, ACM SIGCSE Bulletin, 33 (4), 2001, pp. 125–140. Niño J., and Hosch, F.A., An Introduction to Programming and Object-Oriented Design Using Java, John Wiley & Sons, 2001. The Joint Task Force on Computing Curricula (IEEE Computer Society and Association for Computing Machinery). Computing Curricula 2001 (final report), December 2001. Available on-line at “http://www.computer.org/education/cc2001/final”. Cooper, S., Dann, W.& Pausch, R. (2003) Teaching Objects-first In Introductory Computer Science SIGCSE’03 February 19-23, 2003, Reno, Nevada, USA. pp. 85 – 89. Jones, R., Boyle, T. & Pickard, P. (2003) Objectworld: Helping Novice Programmers to Succed through a Graphical Objects-first Approach. Proceedings of 4th Annual LTSN-ICS Conference, NUI Galway, pp. 111 – 114. Kölling, M. & Rosenberg, M. (2001) Guidelines for teaching object orientation with Java, ITiCSE ' 01: Proceedings of the 6th annual conference on Innovation and technology in computer science education, pp 33 – 36. Schmolitzky, A. (2004) Objects first, interfaces next" or interfaces before inheritance, Educators symposium, OOPSLA ' 04: Companion to the 19th annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications pp. 64 – 67. Lewis, J. (2000) Myths about object-orientation and its pedagogy, Proceedings of the thirtyfirst SIGCSE technical symposium on Computer science education, pp. 245-249. Robins, A., Rountree, J. and Rountree N (2003). Learning and Teaching Programming: A Review and Discussion, Computer Science Education, Vol. 13, No 2 pp 137 - 172 du Bouley, B (1989). Some difficulties of learning to program. In E. Soloway & J.C. Spohrer (Eds) Studying the novice programmer. Hillsdale, NJ: Lawrence Erlbaum. Gries, D.(1974) “What Should We Teach in an Introductory Programmming Course”, Proceedings of the fourth SIGCSE Technical Symposium on Computer Science Education, ACM SIGCSE Bulletin, Vol 6, Issue 1, 1974, pp. 81-89. Kölling, M., Quig, B., Patterson, A. & Rosenberg, J (2003): The BlueJ system and its pedagogy Journal of Computer Science Education, Special Issue on Learning and Teaching Object Technology, Vol 13, No 4, Dec 2003. Nielsen, K. and Kvale, S. (1997). "Current issues of apprenticeship." In: Nordisk Pedagogik 17: 130 - 139. Kolb, David A. 1984. Experiential Learning: Experience as the Source of Learning and Development. Prentice-Hall, Inc., Englewood Cliffs, N.J. Sanders, R. T., Jr. (1998). Intellectual and psychosocial predictors of success in the college transition: A multiethnic study of freshman students on a predominantly White campus. Dissertation Abstracts International Section B: The Sciences and Engineering, 58(10-B), pp. 5655. Ting, S. R., & Robinson, T. L. (1998). First-year academic success: A prediction combining cognitive and psychosocial variables for Caucasian and African American students. Journal of College Student Development, 39, pp. 599-610.
Model-Driven Programming
15
Brooks, J. H., & DuBois, D. L. (1995). Individual and environmental predictors of adjustment during the first year of college. Journal of College Student Development, 36, pp. 347-360. Szulecka, T. K., Springett, N. R., & de Pauw, K. W. (1987). General health, psychiatric vulnerability and withdrawal from university in first-year undergraduates. British Journal of Guidance & Counseling Special Issue: Counseling and health, 15, pp. 82-91. Bergin, S & Reilly, R (2005) Programming: factors that influence success. SIGCSE ' 05: Proceedings of the 36th SIGCSE technical symposium on Computer science education ,St. Louis, Missouri, USA. pp. 411--415 Byrne, P., & Lyons, G. (2001). The effect of student attributes on success in programming. Proceedings of the 6th annual conference on Innovation and technology in computer science education, 49-52. Hagan, D., & Markham, S. (2000). Does it help to have some programming experience before beginning a computing degree program? ACM SIGCSE Bulletin , 5th annual SIGCSE/SIGCUE conference on Innovation and technology in computer science education, 32(3), 25-28. Ventura, P. R.. (2003). On the Origins of Programmers: Identifying Predictors of Success for an Objects First CS1”, PhD. dissertation, The State University of New York at Buffalo, 2003. Bennedsen, J & Caspersen, M (2005). An Investigation of Potential Success Factors for an Introductory Model-Driven Programming Course. To be published.
