Computationeel denken is denken als een computerwetenschapper.
Computationeel denken is problemen op zo een manier benaderen dat computers kunnen gebruikt worden om ze op te lossen. ~ Jeanette Wing ~
De definitie van Jeanette Wing geeft niet direct veel inzicht, maar benadrukt wel de essentie. We willen nu eenmaal computers gebruiken om onze problemen op te lossen.
Computationeel denken kan concreter gemaakt worden door het op te splitsen in een aantal concepten en aanpakken (zie fig. 1). Deze concepten proberen we duidelijker te maken voor de leerling door middel van deze cursus en Scratch.
(Figuur 1: Overzicht computationeel denken)
Een algoritme is, in het kort, een stapsgewijze procedure om een probleem op te lossen. We leggen dit begrip uit met behulp van enkele voorbeelden uit het dagelijks leven waar de kinderen mee vertrouwd zijn. Verder gebruiken we het begrip zelf ook echt in de cursus. Zo benoemen we oefeningen als ‘het maken van een algoritme’ wanneer dit het geval is (zie fig. 2).
(Figuur 2: Eerste eigen algoritme)
Zo krijgt de leerling een oefening (zie fig. 3) waarbij hij/zij Ruby in een vierkant moet laten wandelen. De leerling zal dan eerst moeten nadenken over hoe hij/zij Ruby in een vierkant kan laten wandelen. Wat is het juiste algoritme? Zodra dit algoritme gevonden is, kan het naar Scratch omgezet worden.
(Figuur 3: Wandelen in een vierkant)
Het maken van complexere figuren (zie fig. 4 & 5) is niet eenvoudig om in één keer te doen. Daarom moet er eerst nagedacht worden over welke stappen er gevolgd moeten worden om de gewenste tekening te realiseren. Opnieuw: wat is het algoritme dat er nodig is?
(Figuur 4: Veelhoeken)
(Figuur 5: Eigen huis)
Program-uurtje: waar kinderen andere kinderen kunnen laten tekenen door een lijst van instructies (een algoritme) te geven.
Decompositie houdt in dat we grotere problemen opsplitsen in kleinere delen, die we dan afzonderlijk kunnen behandelen.
Bijvoorbeeld als we een huis willen tekenen (zie fig. 5) doen we dit niet in één keer. We gaan verschillende delen proberen te herkennen, die we dan afzonderlijk kunnen tekenen. Dus voor het huis zouden we kunnen beginnen met de voorgevel, daarna de rechtergevel, dan het dak, etc.
Ook als we een eigen verhaal/mop/film willen visualiseren (zie fig. 6), moet er nagedacht worden in welke scènes we dit opsplitsen. Vervolgens kunnen we iedere scène apart uitwerken.
(Figuur 6: Een eigen verhaal maken bestaande uit verschillende scènes)
Om aan decompositie te doen tijdens het programmeren zijn er bepaalde tools ter beschikking om het ons gemakkelijker te maken. In het programmeren spreken we over het gebruik van procedures en functies, in Scratch spreken we over ‘Blokken’. We kunnen in Scratch namelijk eigen blokken definiëren en hier een bepaalde functionaliteit/gedrag aan koppelen. Deze blokken kunnen we dan gebruiken om eenvoudiger te programmeren.
Bijvoorbeeld, een heel eenvoudig huis (zie fig. 7): een blok om de voorgevel te tekenen en een blok om het dak te tekenen en klaar!
(Figuur 7: Simpel huis m.b.v. eigen blokken)
Decompostie maakt het niet alleen gemakkelijker om het programma te bouwen, maar ook om het programma achteraf sneller terug te begrijpen.
Hier beginnen we direct met een voorbeeld, stel dat we onderstaand dambordpatroon (zie fig. 8) zouden moeten programmeren. Dan ziet dit er op het eerste zicht heel overweldigend uit. Totdat we inzien dat er heel wat patronen in de figuur voorkomen, die het ons uiteindelijk veel gemakkelijker maken om de tekening te programmeren.
Zo zien we in onderstaande figuur een opeenvolging van afwisselend witte en zwarte vakjes, zoals een dambord, waarbij ieder wit vakje ook nog eens een zwarte stip bevat.
(Figuur 8: Dambord-patroon)
Dit geldt ook voor programmacode, wanneer dezelfde programmacode een aantal keer uitgevoerd moet worden, kunnen we er ofwel een blok voor definiëren ofwel er een herhaallus voor gebruiken.
Zo zien we in onderstaande figuur links van de pijl, code voor het tekenen van een driehoek. Hier wordt een sequentie van drie blokken, drie maal herhaalt en dus kunnen we dit anders programmeren Door gebruik te maken van een herhaallus, wordt de code veel korter en eenvoudiger om te lezen.
(Figuur 9: Patronen)
Er zijn nog andere leuke tekenoefeningen waar het interessant is om patronen te herkennen. Zo is er een oefening waar er verschillende regelmatige veelhoeken (driehoek, vierhoek vijfhoek, etc.) getekend moeten worden (zie fig. 4).
Ook hier hopen we de leerling het inzicht bij te brengen dat het maken van deze verschillende soorten veelhoeken eigenlijk altijd hetzelfde is. Eens dit inzicht verworven is, wordt het programma dat deze veelhoeken tekent eenvoudiger. Dit omdat hij/zij zal inzien dat er voor iedere veelhoek eenzelfde aanpak nodig is.
Patroonherkenning maakt programma’s gewoonweg eenvoudiger!
Met abstractie willen we overbodige details weglaten of bepaalde zaken op een andere manier voorstellen. Met Scratch gaan we hier niet zo diep op in. Doordat dit geen gemakkelijk begrip is, is het misschien ook wat meer weggelegd voor het secundair onderwijs.
Toch kunnen we met Scratch ook al abstractie toelichten aan de hand van variabelen. Variabelen vormen namelijk een manier om informatie op te slaan en hier een betekenis aan te geven. We gebruiken dit om bijvoorbeeld namen, getallen, een leeftijd, etc op te slaan.
Wanneer we in een spel de waarde van twee dobbelstenen willen weergeven (zie fig. 10), gebruiken we een variabele voor dobbelsteen één en een variabele voor dobbelsteen twee. Wordt zo een dobbelsteen geworpen, dan kennen we op een willekeurige manier getallen toe tussen één en zes. Zo een getal komt dan overeen met de worp van een dobbeslteen.
Niet alleen voor dobbelstenen, maar ook voor speelkaarten (zie fig. 11) kunnen variabelen gebruikt worden. Zo komen de waarden één tot en met tien overeen met de numerieke waarden van de speelkaarten, waarbij elf, twaalf en dertien respectievelijk de boer, dame en heer voorstellen.
(Figuur 10: Dobbelstenen)
(Figuur 11: Speelkaarten)
In Scratch doen we dat aan de hand van testen, met behulp van een aantal blokken. Afhankelijk van de uitkomst bepalen deze wat er dan exact moet gebeuren. Bijvoorbeeld met de oefening Blad, steen en schaar (zie fig. 12). In dit spel kiezen de speler en de computer één van de drie voorwerpen. Hier is het dan aan het programma om steeds de juiste keuze te maken wie het spelletje wint. Om die beslissingen te modeleren gebruiken we testen.
(Figuur 12: Beslissingen)
Het is belangrijk om tijdens het maken van een programma er ook voor te zorgen dat er een evaluatiefase is, waarbij de leerling reflecteert over het programma en de correctheid hiervan. Met andere woorden, doet het programma wat het moet doen? Daarom dat we bij de meeste oefeningen een vorm van zelfevaluatie voorzien (zie fig. 13). De leerling kan zo nog eens nagaan of alles wat moest gedaan worden is volbracht.
(Figuur 13: Evaluatie)
Bij de aanpakken (zie fig. 1) behandelen we enkel foutopsporing expliciet in deze cursus. Exploreren gaat echter eerder over het zelf uitzoeken en proberen van verschillende blokken, waarbij creëren dan weer vanzelfsprekend is wanneer we programma’s maken.
Bij foutopsporing is het heel belangrijk om duidelijk te maken dat het helemaal geen probleem is wanneer er fouten in een programma zitten. Heel weinig mensen maken van de eerste keer meteen een programma dat volledig correct is. Het is dus zeker normaal wanneer je een programma schrijft, dat daar dan fouten in zitten. Even normaal is dat we dan ook deze fouten gaan opsporen en oplossen. In het Engels noemen we dit debuggen. In de cursus maken we gebruik van oefeningen waar we zelf fouten in hebben gestoken om dit aan te leren.
In de oefening van de slechte mop, wordt de dialoog in de verkeerde volgorde gevoerd. De bedoeling is dat de fouten daarin gevonden en aangepast worden.
(Figuur 14: Debuggen)