Functional Modelling in secondary schools using spreadsheets

Transcription

1 Functional Modelling in secondary schools using spreadsheets Peter Hubwieser Techn. Universität München Institut für Informatik Boltzmannstr. 3, Garching Abstract. During the last decade we developed a didactical concept for a mandatory, dedicated subject informatics at secondary schools. The proposed teaching approach combines modelling techniques with the use of software tools and programming languages. This paper is focussed on the part of the concept which applies functional modelling on a spreadsheet from a black box point of view. The course of lessons starts with the introduction of data flow diagrams which is motivated by the need of a divide and conquer strategy in order to describe and structure complex systems. As soon as the students are able to apply data flow diagrams, they start to simulate some data flow diagrams with specific properties using spread sheets. The first step towards the spreadsheet is transforming the diagrams into terms, which consist exclusively of functions that are offered by the used program in a ready made way. Thus we combine the benefit of modelling abilities (e.g. education towards strategic planning or proper description of complex systems) with the training of user skills on important and widespread office software tools. The described concept was accepted by the Bavarian government an part of the new mandatory subject informatics in Bavarian Gymnasiums (400 secondary schools which prepare to University) and will be taught there in the 9 th grade (age years) starting in Currently it is used in an experimental phase at about 40 schools. Keywords: Education, Functional constructs, Flow Charts, Spreadsheets, Recursion 1 Introduction Within the last years the enormous influence of information technologies on our society has led to a wide public consensus about the necessity of teaching informatical concepts in schools, particularly in secondary schools. Unfortunately the consensus about the content of the curriculum is not as wide yet. At least it is commonly accepted that the concepts taught should be different from the education of future IT-professionals, satisfying the criteria of general education (see [Hubwieser 03b]). During the discussion of possible learning contents at secondary schools, one of the most strongly suggested topics was modelling, because it enables the students to describe and structure complex systems without forcing them to learn all the specific details of really existing hard- or software systems. On the other hand, most of the parents and many lobbyists of industry expect the students to learn user skills on widespread IT-systems, e.g. office software. Additionally it is obviously not reasonable to teach modelling without offering the students the opportunity to implement, realise and test their models on a suitable software. 1

2 Thus we developed a course of lessons for secondary schools that combines modelling techniques (e.g. modelling of data, data flow, objects or state sequences) with the application of software systems (e.g. spreadsheets, databases or programming languages). The course starts with functional modelling (using data flow diagrams), implementing the models on spreadsheets, using their built-in functions to represent (data processing) processes in a black-box way, concentrating on the relationship between their input and their output and neglecting the implementation of the transformation process. This part of the course will be described in detail below. The second block in the first year combines Entity- Relationship and relational modelling with database systems. The second year starts with state-transition and algorithmic models, which are transformed into imperative programs, and ends with a second, closer inspection of functional modelling. In contrast to the first treatment of functional modelling we now translate processes into functions or procedures of the programming language (introduced in the preceding block), which allows a glass-box view of processes by reflecting the algorithms used for internal calculations. Some aspects of this block will also be discussed below. The third year of the course deals with object oriented modelling combined with object oriented programming and culminates in a large software project that should be organised, directed and performed by the students themselves. The whole teaching concept has been originally developed for the grades 9 11, but currently it seems more likely that it will be taught in the grades 8 10 of Bavarian Gymnasiums. (The Gymnasium is the type of secondary school that leads to university directly.) The course will be taught in two lessons per week within a mandatory subject called informatics. 2 Data flow modelling Why do we start with data flow modelling? A short glance at history shows that this was one of the first modelling techniques that arose around the upcoming information technologies. In 1966 it was normalised in the German standard DIN (Deutsches Institut für Normung). The reason for this early development was the need for a technique that supports the divide and conquer approach, splitting a complex system in subsystems and describing the data flow between them. As we need this strategy throughout the whole course, we decided to start the course with the treatment of data flow modelling. We introduce the technique by making the students realise that it is impossible to describe a complex system in every detail (as a whole); we start with the construction of a data flow diagram of some systems that the students are able to structure, e.g. a car production line (see Fig. 1) or a money teller. 2

3 bodywork depot chassis depot bodywork assembly chassis assembly just-in-time-delivery of wheels component depot wheel assembly final assembly Fig. 1: Data flow model of a car production line Following these first exercises, we present the components, the syntax rules and the semantics of simplified data flow diagrams (restricted to data flows, data transforming processes, terminators and data stores, see Fig. 2). This is followed by some more exercises. input data External interactor flowing data information transforming process output data data storage Fig. 2: Components of data flow diagrams 3 Spreadsheets Spreadsheets are one of the oldest and most frequently used types of standard software. The first spreadsheet (called VisiCalc) was implemented on an Apple II machine by D. Bricklin and B. Franston in 1979 already. Thus it is evident that students should be made familiar with the structure and the use of these programs. On the other hand, it is not easy to find a proper teaching approach that is suitable for secondary schools without getting caught in the 3

4 pure training of specific software aspects like the structure of menus or the meaning of hotkeys. We solve this problem by approaching spreadsheets as a platform for the implementation of functional models, described by data flow diagrams. The first step the explanation of the structure of a spreadsheet: - a spreadsheets consists of cells, - which are arranged in lines and columns, - and may contain: o (constant) data of different types (numbers, currency, strings,.. ) or o formulas, which are composed of constant data, predefined functions or operators (sum, average,..) and references to other cells. The next step is the first (close) transmission of a data flow diagram into a spreadsheet, using the following correspondences: - data flows are transformed into references, - processes into formulas (terms), - terminators into cells used for input or output, - data storages into cells used for storage (very similar to terminators in this case). Fig. 3 shows the calculation of interests as an example of this step. The data flow diagram is transformed into the spreadsheet without changing its structure (see Fig 4). date of deposit date of withdrawal interest rate 100 capital interest time : round Fig. 3: data flow diagram of interest calculation 4

5 Fig. 4: The resulting spreadsheet Of course it is not possible to transmit every data flow diagram on a spreadsheet. Thus we have to discuss the restrictions caused by the specific structure of the software (e.g. that each process has to be represented by a term). We also restrict ourselves to the use of ready-made functions offered by the spreadsheet software (e.g. sum, average, string or data functions etc.). These functions are treated as black boxes: we are not (yet) interested in how they internally work, i.e. in the algorithms they use for the calculation of their results. Please note that we use the predefined function of MS-Excel, returning the difference in years between two dates (german version BRTEILJAHRE, English DIFFXY ). Later we might give the students an understanding of the principle of stepwise refinement by constructing this function ourselves, using other functions of the Spreadsheet. Step by step, exercise by exercise, we free ourselves from the geometrical structure of the data flow diagram and permit the students to arrange the formulas, cells and links freely on the two-dimensional calculation area, following the need for intuitive data presentation and efficiency more than the layout of the data flow diagram. Nevertheless the logical structure of the calculation is determined by the data flow model. Finally we compress the whole calculation into one term, which might be the content of one single cell of the spreadsheet: interest result = round(fraction(date of deposit, date of withdrawal) ((interest rate:100)capital)) 5

6 During the translation of the models into the software the students get familiar with the specific form of functional programming that is used on spreadsheets (the formulas are nothing else than terms and therefore a specific sort of functional programs). 4 Iterative Calculations The compression of functional models into terms allows us to treat iterative calculations. Basically there are two options for performing them in a spreadsheet: - successive application of a formula in a range of cells, each formula referencing its preceding copy, - programming macros. At this point we are restricted to the first option, because we describe the teaching sequence in the first year of the course. Nevertheless the second option mentioned above is one of several proposals for approaching iterative programming in the second year of the course. We will treat some aspects of macro programming in the next chapter within the discussion of recursion. In a word, the students work on several examples which require iterative calculations, represent them by copying formulas into a range of cells and connect them by referencing the results of formulas in other cells (see Fig. 5, showing the calculation of compound interest over several years). Now the functional modelling part of the first year of the course is finished. Throughout the rest of the year the students learn to construct data models and to implement them on a relational data base system. At the beginning of the second year the students are inducted into state-transition diagrams, algorithms and imperative programming. The description of these two blocks exceeds the range of this paper, which concentrates on functional modelling and the use of spreadsheets. Fig. 5: Calculation of compound interest 6

7 5 Programming processes with macros At the end of the second year of the course we return to functional modelling. The difference to the first part described above lies in the glass-box view of the processes, which is now achieved by representing them as functions or procedures of the programming language just learned by the students. One of several options is the macro language of the spreadsheet software used in the first year of the course. Thereby the students d not have to learn complicated in- and output mechanisms (like e.g. in Java). The following example illustrates this point: we describe the symmetric encryption of a message by a data flow diagram and simulate the calculation in a spreadsheet. We do not explain the polygraphic cesar code in this paper, however we do explain it to the students in the course (for details see [Hubwieser 03a], pp 193ff). Firstly we construct the data flow diagram (see Fig. 6). sender key (safe transmission) receiver key message message key encode() coded message decode() Fig. 6: Data flow diagram of symmetric encryption Secondly we develop the algorithms for the encoding and decoding of the message, program them (using Visual Basic for Applications here), and finally we assemble the spreadsheet in MS-Excel (see Fig. 7) 7

8 Fig. 7: Simulation of the functional model in MS-Excel 6 Recursion The following discussion of the relation between recursion and data flow diagrams fits well into the end of the second year. Basically it is not possible to represent a recursive function in a (static) data flow diagram, because every recursive call generates a new process (i.e. a new component of the diagram). Thus we have to use a sequence of data flow diagrams for the representation of recursion, called dynamic data flow diagram. This insight also explains why it is impossible to implement recursive structures in a spreadsheet directly. The factorial might serve as an example (although it should not be used as the first example for recursion, because it could be calculated by a very evident iterative algorithm). We refer to the following definition of the recursive function (using Visual Basic for Applications again): Function Fak(n As Integer) If n = 0 Then Fak = 1 Else Fak = n Fak(n - 1) End Function The resulting dynamic data flow diagram is shown in Fig. 8. 8

9 recursive structure n n n-1 if n > 0 fak fak 1 if n = fak fak fak 2 1 fak 6 evaluation of the term fak(3) Fig. 8: Dynamic data flow diagram showing recursion Note that this type of representation of recursive function calls might be transformed into animations very easily. It also makes evident, why the multiplicative calculations cannot be carried out until the last recursive call is resolved into a constant number. Additionally this representation supports the evolution of the proper mental copy model (the recursive process is copied into a new one by each recursive call) rather than leading to the wrong text repetition model often picked up by novices (for details see George 2000). 7 Concluding remarks As mentioned already in the introduction, this course of lessons is planned to be taught in a mandatory subject of informatics at Bavarian Gymnasiums. Today it seems likely that its first run will be in autumn Up to this time the proposed teaching concepts will be tested intensively, currently at about 40 selected schools. Much more work has to be done on producing examples, exercises and schoolbooks. Another crucial aspect is teacher education. During the last decades the education of informatics teachers has more or less been neglected by the decision makers. Now we have to educate at least 400 teachers until 2006 in order to realise this concept. This will be accomplished in specific in-service courses at 5 universities all over Bavaria. These courses are based on a distance learning concept in their first year, while the second year requires the presence at the university for one day per week. 9

10 8 References [George 00] George C.G.: EROSI Visualising Recursion and Discovering New Errors. The Proceedings of the 31st SIGCSE Technical Symposium on Computer Science Education. Austin, Texas, 2000, SIGCSE Bulletin 1 March (2000) [Hubwieser 03a] Hubwieser P.: Didaktik der Informatik. Springer, Berlin, 2. Auflage [Hubwieser 03b] Hubwieser P.: Object Models of IT-Systems Supporting Cognitive Structures in Novice Courses of Informatics. In: van Weert T., Munro R. (Eds.): Informatics and The Digital Society: Social, Ethical and Cognitive Issues, IFIP TC3/WG3.1&3.2 Open Conference on Social, Ethical and Cognitive Issues on Informatics and ICT, July 22-26, 2002, Dortmund, Germany. IFIP Conference Proceedings 244 Kluwer 2003, ISBN , pp Zitat: Hubwieser P.: Functional Modelling in Secondary Schools Using Spreadsheets. Education and Information Technologies 9 (2): , June 2004 ATTENTION: beim Klüwer-Verlag. Bitte nicht weitergeben! 10