Att undervisa med programmering

Transkript

1 Matematik: Gymnasieskola Modul: Matematikundervisning med digitala verktyg II Del 2: Att undervisa med programmering Att undervisa med programmering Ola Helenius, NCM, Morten Misfeldt, Aalborg Universitet och Lennart Rolandsson, Uppsala universitet Orkestrering Orkestrering ses som en beskrivning av olika sätt att organisera och tillsammans med eleverna genomföra undervisningen och lärandet och speciellt, hur olika tekniska hjälpmedel utnyttjas. Att orkestrera undervisning förutsätter en väl genomtänkt didaktisk organisation och en plan för att genomföra denna undervisning (Trouche, 2004). Vid genomförandet finns en plan för olika scenarier så att läraren ska kunna möta och ta till vara elevers initiativ och idéer, även om det inte är möjligt att förutse allt som kan ske. Själva orkestreringen består med denna tolkning av både förberedelser och genomförande av undervisning: Förbereda Genomföra didaktisk organisation (uppgifter, material, verktyg etc.) plan för genomförande (interaktion, arbetsformer etc.) implementera planen. Undervisning med programmering kan bygga på olika föreställningar om hur elever förväntas lära, exempelvis att enskilda elever måste arbeta och förstå grundläggande nivåer innan de kan gå vidare eller att elevers erfarenheter av konkreta aktiviteter är viktiga för att de ska förstå programmering. Det kan även vara att elever behöver samspela med andra för att upptäcka programspråkets begränsningar och möjligheter. Alla dessa sätt att se på elevernas lärande innefattar att det finns ett mått av eget upptäckande som är viktigt för lärandet. Programmering kan av förklarliga skäl fokusera på algoritmer som någonting färdigt (en produkt) och man kan därför tänka sig en undervisning där lärare använder exempel och färdiga förslag på lösningar som eleverna förväntas öva i stigande svårighetsgrad. Programmering är i hög grad en kreativ process så därför är det viktigt att undervisningen även innefattar kreativa och upptäckande moment för att eleverna ska få möjlighet att lära sig olika strukturer och algoritmer men också om programmering som process. En färdig lösning är så att säga färdig och kräver inte att man återupptäcker de överväganden och ställningstaganden som programmeraren redan gjort, och som finns inbyggda i lösningen men inte nödvändigtvis framträder. Därför bör undervisningen ge möjlighet till sådana överväganden och inte ensidigt vara baserad på färdiga lösningar. Detta kommer vi att behandla i modulen. 1 (7)

2 Olika sätt att orkestrera sin undervisning När man i matematikdidaktisk forskning har undersökt hur olika lärare orkestrerar sin undervisning med digitala verktyg framstår vissa standardmönster (Drijvers m.fl., 2010; Misfeldt & Ejsing Dunn, 2015; Trouche, 2004). Dessa skiljer sig åt när det gäller hur klassrumsarbetet är organiserat, till exempel vem som har tillgång till dator och skärm, vilka mål man avser att uppnå, hur man planerar att uppnå dessa och hur progressionen planeras samt utfallet av undervisning. Vi har här grupperat dessa mönster efter hur läraren organiserar eleverna i helklass eller mindre grupper. Klassen arbetar tillsammans, med en gemensam skärm Läraren förklarar matematik eller teknik Läraren förklarar antingen tekniska eller matematiska fenomen och beaktar huruvida fokus ska vara matematiskt eller tekniskt. Även om huvudfokus för en lektion är matematiskt, så kan läraren ofta behöva förklara tekniska aspekter av programmeringen eller programmeringsmiljön.under lektionen är läraren uppmärksam på om alla kan se och om alla är engagerade i den gemensamma aktiviteten. Läraren kan exempelvis inledningsvis förklara hur det program eleverna ska arbeta med ska förstås, och visa de kommandon som eleverna kommer att behöva använda. Läraren kopplar samman olika representationer av matematiska objekt Läraren kopplar samman representationer på skärmen med andra representationer av samma matematiska objekt som eleverna har mött tidigare exempelvis i läroböcker, eller med något från verkligheten som ska modelleras eller programmeras. Läraren utgår från tidigare genomförda arbeten Under en lektion kan läraren ta fram sparade elevarbeten som är relevanta att diskutera. Det kan till exempel vara olika elevlösningar för visa eleverna att en uppgift kan lösas på olika sätt. En elev sköter teknologin Eleverna tar upp det som de finner intressant, till diskussion i hela klassen. Läraren leder klassarbetet. En av eleverna får sköta det digitala verktyget medan klassen gemensamt försöker diskuterar problemets lösning. Eleverna arbetar enskilt eller i par, läraren samlar eleverna vid en skärm När läraren utgår från vad som händer under arbetets gång får eleverna uppleva att deras arbete och tankar värdesätts i det gemensamma arbetet. Läraren visar matematik och teknik under arbetets gång Med utgångspunkt från elevens arbete diskuterar och förklarar läraren matematik och teknik som aktualiseras. Med hjälp av elevers olika arbeten kan olika strategier diskuteras (des både funktionella och icke-funktionella). Detta kan planeras för att skapa variation och 2 (7)

3 för att alla ska ha fått ta del av vissa gemensamma fakta eller användas utan föregående planering för att visa något intressant som dyker upp under elevers arbete. Läraren ger en spontan snabbgenomgång när eleverna behöver det Läraren utnyttjar problem som eleverna hamnar i för att få ett lämpligt tillfälle att ge vissa förklaringar eller kortare genomgångar. Snabbgenomgången kan gärna vara kort och enkel, speciellt om läraren inte har haft möjlighet att tänka igenom ämnet ordentligt. Eleverna arbetar enskilt eller i par, läraren går runt Läraren lyssnar och samlar underlag för fortsatt undervisning Läraren går runt och överblickar elevernas framsteg, erbjuder stöd när det behövs och samlar samtidigt information om vilka strategier och tekniker som eleverna använder för att senare kunna använda detta i en annan konfiguration. Läraren noterar likheter och skillnader mellan olika elevgruppers tillvägagångssätt, för att senare kunna uppmärksamma eleverna på styrkor och svagheter då man använder olika strategier. Tinkering elevens arbete i centrum Inom forskning (exempelvis McLean & Wiggins, 2010; Mordechai, 1998) har man sett att elever ibland arbetar mera utforskat för att lära känna verktyg och begrepp. De prövar sig fram i sitt lärande, vilket ibland benämns tinkering eller bricolage, vilket betyder att man kommer underfund med hur något fungerar genom att fingra på eller mixtra med det. I det här sammanhanget handlar det om att elever kommer underfund med programmering genom att mixtra med eller mer eller mindre på egen hand interagera med olika programmeringsmiljöer. Elevers kreativitet, upptäckarlust och nyfikenhet är drivkraften. Genom att låta elever på egen hand prova sig fram förväntas elever ställa frågor och reflektera, vilket leder dem framåt till en förståelse för hur man kan programmera. Om man uppfattar tinkeringbaserad undervisning som att elevers lärande uteslutande sker då de på egen hand interagerar med, i det här fallet, olika kodstrukturer som presenteras i en programmeringsmiljö och ett programspråk, förefaller lärarens roll oväsentlig för elevers lärande. Men eftersom elevens tankar och handlingar inte alltid räcker för att tinkeringbaserad undervisning ska bli effektiv, så behöver tinkering i allmänhet kombineras med en genomtänkt orkestrering (Trouche, 2004). Trouche menar att läraren har ansvar för att rikta elevens uppmärksamhet mot specifika aspekter, så att interaktionen med digitala verktyg blir begriplig. Detta kan tyckas stå i stark kontrast mot tinkering som uppmanar till elevers eget kreativa mixtrande, men i själva verket handlar det dels om att skapa lämpliga ramar att vara kretativ inom, dels om att fånga upp och sammanfatta elevernas tankar i efterhand. En fördel med en tinkeringbaserad undervisning är att man snabbare kan få elever att arbeta med mer avancerade exempel samtidigt som de arbetar kreativt och skapande. Eftersom programmering ingår i matematikämnet är det en fördel om elever på kontinuerligt får möta olika programmeringsstrategier för att lösa problem. I sådan tinkeringbaserad undervisning utgår man ofta från program som andra har skapat som eleverna sedan undersöker, modifierar och använder. Det går därför snabbare att 3 (7)

4 inkorporera dessa program i den matematiska praktiken än om man skulle arbeta systematiskt med programmeringskunskap. Även om tinkering bygger på nyfikenhet och kreativitet och för eleverna inte framstår som planerad, så gäller det att läraren har ett syfte med uppgiften. Om man vill att eleverna ska lära sig om specifika programmeringskonstruktioner eller någon specifik matematik så måste uppgiften vara konstruerad så att detta är möjligt. Även en undervisning som i hög grad bygger på elevers experimenterande ställer höga krav på att lektionen är genomtänkt och strukturerad. Med större kunskap i programmering är det naturligtvis enklare att undervisa på detta sätt. Men även lärare med mindre programmeringskunskap kan få sådan undervisning att fungera om undervisningen organiseras så att läraren kan utgå från elevers vilja att hitta lösningar och så att eleverna får möjlighet att konstruera egen kod som de kan uppleva som avgörande för att algoritmen ska hjälpa dem att lösa problemet. Arbeta med olika representationer för förståelse av matematik Det finns programmerare och programmeringslärare som hävdar att de inte använder någon matematik. Och i en viss mening har de rätt, trots att vi som betraktar programmen ur ett matematiskt perspektiv nästan undantagslöst ser matematik där. Vi vill därför visa hur olika representationer kan vara till hjälp för matematisk förtsåelse när både kod och matematiska symboler används för att lösa problem. Som vi ser det, kan både kodelement och matematiska begrepp med fördel förstås som abstrakta representationer av olika konkreta företeelser eller fenomen. En av lärarens uppgifter är därför att underlätta översättningen mellan kod och matematiska uttrycksformer; att hjälpa eleverna att se sambandet mellan matematik och algoritmer som skrivs i kod. I modulen skiljer vi på två typer av kod: Typ A: Kod som hanterar (eller som har som syfte att hantera) matematiska företeelser. Typ B: Kod som hanterar (eller som har som syfte att hantera) företeelser som i grunden inte är matematiska I program av typ A går vi mellan en värld av matematisk symbolik och en värld av kod. En viss programinstruktion kan till exempel skapa en lista av slumptal. I program av typ B är det mer komplicerat eftersom något fenomen från verkligheten då kan modelleras antingen i termer av matematik eller i termer av kod. Exempel på typ B är kod som styr en figur, maskin eller robot. Även i kod av typ B används ofta, implicit eller explicit, matematiska representationer och rutiner. Typ B är extra intressant när gäller den didaktiska frågan varför. Hur kan man då tänka på relationen mellan verkliga fenomen, matematik och kod? Vi ska förklara genom att beskriva en mycket enkel konkret situation, nämligen en insekt som kryper. I en programmeringsmiljö (Scratch) representeras detta av följande kod. 4 (7)

5 Representation i kod Grafisk representation Figur 1. Skalbagge som kryper representerat på två sätt. Samma sak kan göras i Python med paketet Turtle graphics enligt nedan. Figur 2. Pythonkod som producerar en pil som rör sig på skärmen och lämnar efter sig ett streck. En specifik kod används för att flytta skalbaggen (eller pilen) framåt och för att vrida den, på skärmen. Även ganska små barn förstår vad konkreta förflyttningar och vridningar innebär i praktiska situationer. De kan tänka sig sådana situationer. Det är inte heller så svårt att förstå hur koden i till exempel Scratch eller Python releterar till den praktiska situationen. I exemplet är koden en representation av förflyttningar och vridningar. Vi kommer kanske att tänka på koodinatsystem, x-värden, y-värden, månghörningar, etcetera. Men det är inte alltid nödvändigt att den som programmerar går vägen över en matematisk beskrivning av världen, eller uppfattar koden som en slags matematisk representation. Däremot finns det nu två möjligheter att matematisera detta sammanhang, det vill säga att 5 (7)

6 skapa en matematisk representation av situationen. Vi kan som vanligt matematisera den konkreta situationen, det vill säga urskilja rörelser, vridningar och kanske även annan matematik samt formulera dem i matematiska representationer. Dessutom kan vi översätta programkoden till matematiska begrepp och representationer. Vi kan på detta sätt urskilja, skapa eller undersöka matematiska begrepp med programmering som modellera insektens förflyttning. På ett ställe innehåller koden i Figur 2 till exempel två på varandra följande vridningar om 45 grader. Kan man ersätta dem med en vridning och i så fall vilken? Vad i den grafiska representationen motsvarar dessa två vridningar? Hur skiljer sig denna dubbelvridning från den enstaka? Hur ska vi från nuvarande läge få skalbaggen att gå till startpunkten så att kurvan sluts? Ett helt varv är 360 grader, vad motsvaras det av i temer av hur vridningen kodas för den slutna figuren? Vilka instruktioner måste man ändra för att göra figuren dubbelt så stor eller hälften så stor? Kan man producera en likadan figur genom att använda koordinater istället för förflyttningar och vridningar? När skulle det vara en programmeringsmässig fördel? Att exempelvis observera att 45 grader följt av 45 grader tillsammans blir 90 grader kan matematiseras som 45+45=90. Det visar sig att plustecknet är en lämplig matematisk representation för att konsekutiva vridningar faktiskt uppför sig additivt. Vi kan ju också prata om negativa vridningar, och att 45+(-45)=0, aritmetiskt och i termer av verkliga vridningar samt låta den grafiska skalbaggen utföra dem. Däremot blir det inte matematiskt meningsfullt att beskriva koden som helhet som 100 steg + 45 grader steg + 45 grader steg + 45 grader + 45 grader steg + 45 grader steg. I någon mening representerar det visserligen vad som görs i programmet. Om vi accepterar att tecknet, +, som vi vanligen associerar med den matematiska operationen addition används i en mer metaforisk mening, så är det inte svårt att acceptera strängen ovan som en beskrivning av koden. Men det är alltså en beskrivning som påminner om matematisk notation, men som inte representerar matematik. Då vi programmerar får vi en representation som på ett tydligt sätt representerar en förflyttning. Att vandra mellan en kodrepresentation och en matematisk representation kan därför öppna en förståelse för konkreta företeelser och fenomen. I del 4 behandlar vi bland annat ett geometrisk problem som kan vara ganska svårt att lösa med klassiska geometriska metoder, men som blir tämligen enkelt att hantera med den form av rörelsegeometri som vi har diksuterat ovan. Med detta har vi sett att både kod och matematik kan användas för att representera konkreta situationer i matematik. Både instruktioner i programmet och matematiska begrepp kan med fördel förstås som representationer av olika konkreta företeelser eller fenomen. Kod och matematik är dock inte samma typer av representationer och det krävs ofta ett översättningsarbete för att gå mellan kod och matematik. 6 (7)

7 Referenser Drijvers, P., Doorman, M., Boon, P., Reed, H., & Gravemeijer, K. (2010). The teacher and the tool: Instrumental orchestrations in the technology-rich mathematics classroom. Educational Studies in mathematics, 75(2), McLean, A. and Wiggins, G. (2010). Bricolage Programming in the Creative Arts. Konferensbidrag till Psychology of programming interest group, PPIG. Madrid: University Carlos III. Misfeldt, M., & Ejsing-Duun, S. (2015, February). Learning mathematics through programming: An instrumental approach to potentials and pitfalls. In CERME 9-Ninth Congress of the European Society for Research in Mathematics Education (pp ). Mordechai Ben-Ari. (1998). Constructivism in Computer Science Education. Konferensbidrag till Special interest group on computer science education, SIGCSE. Atlanta: USA. Stein, M. K., Engle, R. A., Smith, M. S. & Hughes, E. K. (2008). Orchestrating productive mathematical discussions: five practices for helping teachers move beyond show and tell. Mathematical Thinking and Learning, 10 (4), Trouche, L. (2004). Managing the complexity of human/machine interactions in computerized learning environments: Guiding students command process through instrumental orchestrations. International Journal of Computers for Mathematical Learning, 9, (7)