Didaktiske Overvejelser

From CCT - Vidensdeling
Jump to: navigation, search

Hvad er et forløb til CT i Fag?

Et forløb til CT i Fag kombinerer aktiviteter og læringsmål fra både faget og CT. Eleven arbejder således med fænomener, begreber og principper fra både faget og fra CT. Det betyder at:

  1. De faglige fænomener, begreber og principper anvendes til at lære CT.
  2. De CT-faglige fænomener, begreber og principper anvendes til at lære faget.

Primært opnår eleverne en forståelse for at fænomener og begreber i et fagligt relevant referent system kan udtrykkes som en dynamisk model via programmeringsmæssige konstruktioner på en computer (se illustrationen nedenfor). Det kan umiddelbart forekommer trivielt og naivt, men denne simple idé har vidtrækkende konsekvenser (se "Fordele" nedenfor).

Model-Based Thinking & Practice

Sekundært kan algoritmebegreber som f.eks. sekvens (at trins rækkefølge har betydning), selektion (if-sætning) og iteration (loops) benyttes til at modellere naturligt forekommende fænomener i naturvidenskab, teoretiske modeller fra samfundsfag, sproglige fænomener fra sprogfag (f.eks. grammatiske elementer eller fonetiske elementer), fænomener og begreber fra musiske/æstetiske fag (noder, toner, samples, osv.), og narrative elementer i f.eks. historie og dansk (aktører, plots, spændingskurve, konflikter, osv.). Dette kan selvfølgelig videreudvikles til at arbejde med mere klassiske datalogiske problemstillinger såsom søgning i og sortering af data, datastrukturer osv. Det er vigtigt at understrege, at ingen af disse elementer af algoritmer og datastrukturer er centrale for modelbaseret tænkning og praksis - det er blot en sidegevinst, der evt. kan udnyttes, hvis man har elever med interesse for disse mere snævre datalogiske emner.

HUSK! Tilføj materiale om æggestokmodellen, begrebsdannelse osv. Evt. seperat side om modellering.

Fordele ved en model-baseret tilgang

Der er mange fordele ved at bruge en modelbaseret tilgang til Computational Thinking i Fag:

  1. Eleverne oplever og erkender, at man med "programmering" kan "sætte strøm" til en faglig model, interagere med denne, ændre denne og videreudvikle denne.
  2. Man tager udgangspunkt i et fags egne modeller (som kendt fra lærebøger, videoer, eller måske endda færdige simuleringer/modeller, som eleverne har oplevet før - men hvor de ikke har haft adgang til programmeringen/koden).
  3. Modelbegrebet introduceres grundigt. Modellers gyldighed, rækkevidde, begrænsninger og udtrykskraft kan diskuteres.
  4. Modelbegrebet afmystificeres og tydeliggøres.
  5. Elevernes mentale modeller (hvordan de har forstået det faglige stof) ekspliciteres og tydeliggøres gennem deres arbejde med modellerne og deres underliggende kode.
  6. Elevernes arbejdspraksisser med modellerne kan overføres fra et fag til andre fag. Dette kan foregå på mange niveauer:
    1. En models interface (fremtræden) kan genbruges fra én problemstilling i ét fagområde til en anden problemstilling i et andet fagområde.
    2. En models underliggende programmering (kode) kan genbruges fra én problemstilling i ét fagområde til en anden problemstilling i et andet fagområde.
    3. Processen med at erkende og forstå en udleveret model kan genbruges fra et forløb i et fag til et andet forløb i et andet fag.
    4. Processen med at ændre og udvide en udleveret model kan genbruges fra et forløb i et fag til et andet forløb i et andet fag.
    5. En models tilblivelsesproces (fra idé til fungerende prototype) kan kopieres fra et fagligt forløb til et andet.
  7. Programmerbare modeller understøtter en legende, praktisk og interaktiv tilgang til stoffet, hvor der kan eksperimenteres med forskellige fagforståelser ("tinkering").
  8. Modeller kan gøre brug af visuelle og auditive hjælpemidler, de kan være dynamiske og interaktive.
  9. Modeller understøtter dels reduktion af usikkerhed (gennem eksperimenter) og reduktion af kompleksitet (via analytiske trin).
  10. Modellerne understøtter systemtænkning ("thinking in levels"), hvor (f.eks. små) ændringer på mikro-niveau medfører (f.eks. store og måske utilsigtede) ændringer på makro-niveau.

Design af et forløb til CT i Fag

Som generel rettesnor (baseret på foreløbige og ganske begrænsede erfaringer) anbefaler vi, at et forløb er tilrettelagt således, at eleverne flere gange kommer igennem et antal faser:

  1. Introduktion til platform/værktøj
  2. Fri Leg
  3. Model & Fag
  4. Interface & Kode
  5. Ændringer til koden.

Det er vigtigt, at ovenstående faser gentages - dvs. at der itereres i forløbet. Dels for at opnå fortrolighed med både den konkrete platform/værktøj, den faglige problemstilling og de forskellige CT-praksisser, dels for at illustrere at en iterativt og inkrementiel tilgang er fundamental for CT.

Det iterative element består i at aktiviteterne gennemløbes flere gange: Ikke nødvendigvis alle aktiviteter hver gang, og ikke nødvendigvis på samme måde.

Det inkrementielle element består i at aktiviteterne gøres mere omfattende og/eller mere komplicerede for hvert gennemløb.

Platform Intro

Formålet med dette trin er at gøre eleverne så fortrolige med og nysgerrige på platformen, at de har mod på næste trin.

Der startes med en kort introduktion til den platform / det værktøj, som eleverne skal anvende. Ved senere gennemløb kan mere avancerede features ved platformen introduceres. Men formålet med første gennemgang er at gøre det så simpelt og kort som muligt. Altså at eleverne gives præcist den fornødne viden til at komme igang med forløbet, og ikke mere.

Eksempel i NetLogo:

  1. NetLogo downloades og installeres.
  2. De tre faneblade (Interface, Info, Code) introduceres.
  3. "Settings"-knappen introduceres.
  4. Begrebet om "ticks" introduceres.
  5. Man forklarer design guidelines for Interfacet. F.eks. at slidere og andet, der er placeret over "Set-Up" og "Go" benyttes før, man trykker på "Set-Up" og "Go", og slidere under disse, kan anvendes mens simuleringen kører.
  6. På "Code" fanebladet introduceres til "Check"-knappen.
  7. Denne aktivitet kan udføres enten med en simpel model fra NetLogo Model Library (f.eks. "Forest Fire - Simple"), med en simpel faglig relevant model (som man selv har lavet eller fra Model Library), eller med den model, som forløbet omhandler og eleverne skal bruge i de andre faser. Hvis man vælger det sidste, så er det vigtigt, at man ikke forklarer det faglige indhold på nuværende tidspunkt.

Fri Leg

Formålet med dette trin er stimulere elevernes nysgerrighed og ultimativt lade dem forme deres egen mening om hvilke faglige fænomener, begreber og principper, modellen udtrykker.

Aktiviteter:

  • Eleverne opfordres til "Fri Leg" med modellen, der er udviklet til forløbet.

Eksempel i NetLogo:

  1. Eleverne åbner den valgte model i NetLogo.
  2. De introduceres til "Set-up" og "Go" knapperne.

Model & Fag

Formålet med dette trin er, at eleverne erkender, hvorfor og hvordan modellen er faglig relevant for at udforske en problemstilling i faget.

Aktiviteter:

  1. Forklar modellen med fag-termer.
  2. Efterlys og diskuter mulige forbedringspunkter (dette motiverer et senere kig på selve koden af modellen). Disse kan være:
    1. fag-faglige: dvs. hvor er modellen fagligt mangelfuld, og hvordan kan dette forbedres?
    2. it-faglige: dvs. hvordan kunne man ændre/tilføje elementer i grænsefladen og funktionaliteten, så oplevelsen af og interaktionen med dette it-system forbedres?
  3. Diskuter modellens begrænsninger, rækkevidde og forklaringskraft. Dvs. hvad tager modellen højde for, og hvad er ikke med?

Interface & Kode

Formålet med dette trin er at forklare og udforske sammenhængen mellem modellens udtryk i brugergrænsefladen (dvs. de faglige fænomeners adfærd i interfacet) og modellens underliggende programmering (kode).

Aktiviteter (med NetLogo eksempler):

  • Tag udgangspunkt i elementer fra brugergrænsefladen, f.eks. "Set-Up" og "Go" knapperne. Forklar hvordan et tryk på en knap bliver til et kald af en procedure i koden. Forklar trinvis hvad koden for den pågældende knap gør (på et passende abstraktionsniveau).
  • Fokuser på et énkelt fænomen, f.eks. en enkelt turtle (benyt evt. "Watch" eller "Follow" funktionaliteten til dette). Forklar hvordan fænomenets adfærd dikteres af den underliggende kode.
  • Eksperimenter med hastigheden af simuleringen. Nogle fænomener er nemmere at observere ved meget lav hastighed, andre ved meget høj hastighed.
  • Ofte er modellen med vilje konstrueret med en række simple fejl (f.eks. forkerte farver på repræsentationer af faglige fænomener). Fokuser på disse fejl, og antyd hvordan de kan rettes.
  • Giv eksempler på uhensigtsmæssige visualiseringer og/eller adfærd.

Ændringer i koden

Formålet med dette trin er at gøre eleverne fortrolige med at udforske og ændre i koden med deraffølgende ændringer i modellens interface, herunder fænomenernes adfærd - både individuelt og kollektivt.

Aktiviteter:

  • Lad eleverne forstå og ændre konstanter i programmet.
  • Lad eleverne forstå og ændre variable i programmet.
  • Lad eleverne forstå og ændre procedurer i programmet.
  • Lad eleverne tilføje nye procedurer og kalde dem i programmet. Indholdet i de nye procedurer bør indledningsvist være parallelt til allerede eksisterende procedurer, således at eleverne kan kopiere og genbruge kode-elementer. Kaldet af de nye procedurer kan være fra allerede eksisterende procedurer eller via knapper i interfacet.

I de første iterationer / gennemløb af dette trin skal ændringerne være helt simple (f.eks. ændre en farve fra "red" til "green"). Senere kan man ændre agenternes adfærd, således at modellen opfører sig anderledes. Når der er opnået en vis fortrolighed giver det god mening at betragte forslagene til forbedringer fra forudgående trin, og forsøge at implementere disse. Dette kan gøres på klassen i forbindelse med en diskussion, i mindre grupper eller individuelt.

Hvordan udvikles et forløb til CT i Fag?

Domains and relations to consider when designing learning activities
  • Et forløb bør tage udgangspunkt i en faglig relevant undren.
  • Et forløb bør understøtte den faglige undren med en relevant model.
  • Et forløb bør understøttes af en model, der eksplicit repræsenterer og visualiserer faglige fænomener og begreber.
  • Et forløb bør mht. modellen understøtte en top-down didaktik, hvor der tages udgangspunkt i en fungerende (men simpel) model, der så kan udvides og ændres.
  • Et forløb bør understøtte, at eleven veksler mellem at arbejde med modellens brugergrænseflade og modellens implementation/kode.
  • Et forløb bør understøtte, at modellen kan ændres, så der kan undersøges forskellige variationer af de indgående elementer og evt. forskellige faglige fortolkninger af fænomenerne (dvs. anspore en eksperimentel arbejdstilgang.)
  • Et forløb bør understøtte, at modellen kan reduceres/simplificeres eller udvides/kompliceres (dvs. anspore en analytisk arbejdstilgang.)
  • Et forløb bør understøtte, at modellen trinvis forbedres.
  • Et forløb bør motivere, at eleverne "kommer om i koden", f.eks. ved at introducere irriterende fejl og uhensigtsmæssigheder, som eleverne ønsker at rette. Disse fejl/uhensigtsmæssigheder kan være faglige i forhold til den specifikke problemstilling eller det kan være generelle brugergrænseflade-aspekter, der bygger på elevernes kendskab til og fortrolighed med andre it-systemer, som de måske finder bedre ("mere moderne") designet. Det er naturligvis vigtigt, at det er fejl, som eleverne så senere magter at rette/ændre.

Hvad er et potentielt godt problemområde til en agent-baseret model (AMB)?

  • Er der nogle identificerbare agenter med interessant adfærd over tid? Meget gerne flere typer med forskellig adfærd.
  • Er der en interessant og klart definerbart omgivelse, hvori agenter agerer?
  • Er der nogle interessante interaktioner mellem agenterne indbyrdes og mellem agenterne og omgivelserne?
  • Har agenterne og omgivelserne nogle klart identificerbare og klart forståelige tilstande?

Overvejelser til videre udvikling af elevaktiviteter

CT handler i høj grad også om at se programmers muligheder og begrænsninger. Derfor er debugging og tests vigtige områder og gode redskaber for eleverne. Det er interessant at forsøge at indbygge elevaktiviter i forløbet som kan illustrere dette for eleverne. Det kræver et højt abstraktionsniveau hos eleverne og et godt kendskab til programmeringsmiljøet (f.eks. NetLogo), og er derfor en aktivitet som skal introduceres efter at eleverne har arbejdet med andre simplere forløb først.

Et forløb kunne udarbejdes omkring:

Debugging:

Kan eleverne gennemskue at agenterne har fået egenskaber og opførelse som kan betyde at programmet får problemer. Kan de følge programmets afvikling fra "tick til tick". Kan de komme med forslag til hvordan man undgå disse "bugs" og stadig har agenter der opfører sig hensigtsmæssigt i forhold til den faglige teori?


Mikroskopisk og makroskopisk niveau:

Kan man afspejle både det mikroskopiske og makroskopiske niveau både i simuleringen og i koden? F.eks. i modellen om Reaktionshastighed, hvor man kunne lade patch'ene ændre farve efter som der dannes produkt i reaktionen.