Reflections on Teaching Abstraction

1. Reflections on Teaching Abstraction Orit Hazzan Technion – Israel Institute of Technology The Role of Abstraction in Software Engineering May 21st, 2006, Shanghai, China

2. Outline • Reducing abstraction • Reflective Practitioner • Since abstraction is a central theme of SE, we should educate our students to be aware of different abstraction levels and to see advantages of moving between them consciously. • By educating our students to be reflective practitioners, we can guide them to think in term of different abstraction levels as well as to move between them.

3. The theme of reducing abstraction (Hazzan, 99) • Students use ways by which they reduce the level of abstraction of abstract (mathematical) concepts. • Students make abstract concepts more mentally accessible. • Students use ways which enable them to make sense of abstract concepts. • Topics: • Computability • Abstract algebra • Differential equations • Data structures • Graph theory

4. What is abstraction? • Abstraction level as the quality of the relationships between the object of thought and the thinking person (Wilensky, 1991) • Retreat to familiar mathematical structures • Abstraction level as reflection of the process-object duality • Show strong need for canonical procedures which reflects process conception • Abstraction level as the degree of complexity of the concept of thought • Deal with examples instead of the whole set

5. Why should we educate students to move between abstraction levels? • Moving between abstraction levels. • Understanding customers’ requirements - high level of abstraction • Coding a specific class - low abstraction level • Additional abstraction levels in between

6. Reflective Practitioner Schön, D. A. (1983). The Reflective Practitioner, BasicBooks. Schön, D. (1987). Educating the Reflective Practitioner: Towards a New Design for Teaching and Learning in The Profession, San Francisco: Jossey-Bass.

7. The Reflective Practitioner framework • Keep thinking of what one creates • reflection-in-action, reflection-on-action • Originally presented for architecture • Applied to disciplines such as management, psychoanalysis, education • Was not applied to software engineering/development, though Schön published his books when problems in software development and their implications were known.

8. The reflective practitioner framework and its relevance to SE education - A • When a practitioner reflects in and on his [her] practice, the possible objects of his reflection are as varied as the kinds of phenomena before him […]. …

9. The reflective practitioner framework and its relevance to SE education - A … He may reflect on the tacit norms and appreciations which underlie a judgment, or on the strategies and theories implicit in a pattern of behavior. He may reflect on the feeling for a situation which has led him to adopt a particular course of action, on the way in which he has framed the problem he is trying to solve, or on the role he has constructed for himself within a larger institutional context. (Schön, 1983, p. 62)

10. The reflective practitioner framework and its relevance to SE education - A • SE related topics that may be subjects of reflection: • the actual creations - the software systems • ways algorithms are used • programming styles • development process • problem solving • ways of thinking • communication, social issues, etc. • Reflective thinking may increase awareness to such subjects.

11. The reflective practitioner framework and its relevance to SE education - B In the designer's conversation with the material of his design, he can never make a move which has only the effects intended for it. His materials are continually talking back to him, causing him to apprehend unanticipated problems and potentials. As he appreciates such new and unexpected phenomena, he also evaluates the moves that have created them. (Schön, 1983, p. 100-101)

12. The reflective practitioner framework and its relevance to SE education - B • The analogy in this case seems to be trivial. • When one develops a software system, one actually is in an ongoing conversation with the creation. • The computer is a medium through which a software designer talks to his/her creation – the software system.

13. SE and Architecture • The two processes require different range of ABSTRACTION LEVELS. • Wider range of abstraction levels exists in SE. • Figure (next slide)

14. Natural language with customers Natural language with customers Visual Models (such as UML) Sketches This abstraction level does not exist in Architecture SE and Architecture Architecture SE Abstract Detailed Programming languages

15. SE and Architecture • Differences: • Range of abstraction levels • Tangible vs. intangible products • Reflection processes are useful in Architecture. • Reflection may be even more helpful in SE.

16. The Reflective Practitioner Framework • Abstraction and reflection • Reflection maylead one: • to think in terms of different abstraction levels; • to be aware of these abstraction levels; • To be aware of his/her moving between levels of abstraction; • To think on higher abstraction levels. • Ladder of reflection.

17. Ladder of reflection Schön, 1987, p. 114: The chain of reciprocal actions and reflections that make up the dialogue of student and coach can be analyzed in several ways. […]. We can […] introduce […] a vertical dimension [of analysis] according to which higher levels of activity are “meta” to those below. To move “up”, in this sense, is to move from an activity to reflection on that activity; to move “down” is to move from reflection to an action that enacts reflection. …

18. Ladder of reflection Schön, 1987, p. 114 (Cont): The levels of action and reflection on action can be seen as the rungs of a ladder. […] Climbing up the ladder, one makes what has happened at the rung below an object of reflection. […] We can think of the rungs of the ladder of reflection in the following way:

19. Ladder of reflection Schön, 1987, p. 114 (CONT): 4. Reflection on reflection on description of designing [the parties to the dialogue reflect on the dialogue itself] 3. Reflection on description of designing [reflection on the meaning the other has constructed for a description he or she has given] 2. Description of designing [it takes the form of description with: appreciations, advice, criticism, etc.] 1. Designing [a process of reflection-in-action]

20. Ladder of reflection • A tool which may • support abstract thinking • support moving between levels of abstraction. • increase the complexity of the objects of thoughts/abstraction levels • Illustration

21. Ladder of reflection: Student-Coach Dialogue

22. Ladder of reflection: Student-Coach Dialogue (cont)

23. Ladder of reflection: Student-Coach Dialogue • How is abstraction increased in this dialogue? • Each rung becomes the object of reflection of the next rung. • How are abstraction levels/complexity of the objects of though reflected? • function • data • data structures • differences between data structures and their implementation • the reasons for … • students’ thinking

24. Summary • Cognitive complexity. • Software in an intangible object • Calls for integrating soft skills into SE education mainly to overcome its social and cognitive complexities. • To overcome the cognitive complexity: Integrating reflective thinking into Software Engineering curriculum to enhance and support abstraction skills. • Reflection: Additional practice of agile development.