Microworlds - umu.se · Web viewMicroworlds are program systems that realize a ... print word...

An Analysis of Microworlds to Support OO Teaching and Learning

Hassan Safadi

Examensarbete (20 poäng) Institution för datavetenskap

Umeå universitet

Abstract

Teaching object technology has become a rapidly expanding activity, but is in many ways, still an experimental pedagogical task. It requires more than just a change of terminology; it requires a new way of thinking. The most difficult problem in teaching object-oriented programming is getting the learner to give up the global control that is common in procedural programs, and relay on the local knowledge of objects to accomplish their tasks. Programming practice, as an educational exercise is best learned in a playful environment, designed to illustrate programming concepts in the simplest possible setting. Microworlds are program systems that realize a new approach centered on the visualization of objects and their behaviors using a 2D/3D animations environment. The animation task provides a flexible and meaningful context for understanding object-oriented concepts such as class, object, method, and events. This thesis introduces a number of different Microworlds developed to meet the challenges of an objects-first approach by reducing the complexity of details that the novice programmer must overcome. Those Microworlds provide in various ways a software support for an objects-first strategy for teaching and learning object-oriented programming concepts. An objects-first strategy is by many authors considered the best way to help students master the complexities of object-oriented programming.

Three of the Microworlds presented in this thesis are chosen for a more detailed analysis and evaluation. The analysis is based on a number of predefined objectives characterizing an effective and easy to use program systems for the teaching and learning of programming concepts. A comparison is made between those three Microworlds to show things they have in common and others that differ among them. Furthermore, a brief conclusion is made to illustrate the advantages of each of those Microworlds used as a tool for teaching and learning programming concepts.

Sammanfattning Objektorienterad utbildning saknar fortfarande bra verktyg för undervisningen av de grundläggande koncepten. Det material som används i undervisning av objektorientering har ofta sin fokus på syntax istället för de underliggande koncepten som objekt, klass, inkapsling. Microworlds har utvecklats för att övervinna det problemet genom att fokusera på objekt, deras egenskaper och interaktion mellan objekt. I det här arbetet presenteras ett antal Microworlds som i varierande utsträckning stöder en objects-first-strategi för introduktion av programmeringskoncept och tekniker. Dessa Microworlds är inriktade på visualiseringen av objekt och deras beteenden/interaktion i 2D/3D-animeringsmiljöer. Microworlds möjliggör genom sin animering av objekt en flexibel och meningsfull kontext som hjälper studenten att ”se” och lättare förstå objektorienterade koncept. Tre av de Microworlds som presenteras i det här arbetet väljs för ingående analys och utvärdering. De anses representera olika aspekter av Microworlds konceptet. Analysen görs utifrån ett antal fördefinierade mål som anses karaktärisera ett effektivt system för inlärning av objektorienterade koncept och tekniker.

i

ii

1. INLEDNING..................................................................................................................1

1.1. SYFTE OCH METOD.....................................................................................................21.2 DISPOSITION................................................................................................................2

2. DEFINITIONER............................................................................................................3

2.1. VAD ÄR KOGNITIONSVETENSKAP?.............................................................................32.2. VAD ÄR OBJEKTORIENTERING?..................................................................................3

2.2.1. Grundläggande begrepp......................................................................................42.2.2. Den objektorienterade utvecklingsprocessen......................................................5

2.3. VAD ÄR EN MICROWORLD?.......................................................................................6

3. ANSATSER FÖR UNDERVISNINGEN OCH INLÄRNINGEN............................7

3.1 KONSTRUKTIVISM.......................................................................................................73.2. MINIMALISM..............................................................................................................83.3. PEDAGOGISKA MÖNSTER...........................................................................................9

3.3.1. Early Bird Pattern..............................................................................................103.3.2. Spiral Pattern.....................................................................................................113.3.3. Simple and Complete Patterns Step by Step.....................................................113.3.4. Design-Do-Redo-Redo (DDRR) Pattern..........................................................123.3.5. Lab-Discussion-Lecture-Lab (LDLL)...............................................................123.3.6. Mission Impossible...........................................................................................14

3.4. EN ANSATS FÖR EN NY PROGRAMMERINGS PEDAGOGIK..........................................143.5. KOGNITIVA NIVÅER (BLOOMS TAXONOMI).............................................................15

4. ELEKTRONISK INLÄRNING.................................................................................18

4.1. PROGRAMSPRÅKET LOGO......................................................................................184.2. STARLOGO...............................................................................................................21

4.2.1. StarLogosgränssnitt...........................................................................................224.3. LEGO/LOGO............................................................................................................244.4. MICROWORLDS LOGO............................................................................................254.5. BUGGLES..................................................................................................................28

4.5.1. Att skapa en Buggle..........................................................................................294.5.2. Bugglevärld.......................................................................................................304.5.3. Egendefinierade metoder med parametrar........................................................314.5.4. Rekursion..........................................................................................................32

4.6. MOOSE CROSSING..................................................................................................334.7. JKARELROBOT.........................................................................................................33

4.7.1. Karels Värld......................................................................................................344.7.2. Problem och lösningar......................................................................................364.7.3. En vidareutveckling av Karel............................................................................374.7.4. Karels primitiva kommandon............................................................................384.7.5. Karels kontrollstruktur......................................................................................384.7.6. Villkor som Karel kan upptäcka.......................................................................394.7.7. ”Define” Satsen.................................................................................................40

4.8. KARA.......................................................................................................................404.8.1. Karas värld........................................................................................................40

iii

4.8.2. Vidare utveckling av Kara................................................................................424.8.3. Användning av Kara.........................................................................................44

4.9. ALICE.......................................................................................................................444.9.1. Användningen av Alice.....................................................................................454.9.2. Erfarenheter av Alice........................................................................................464.9.3. Alices tillstånd och kommandon.......................................................................474.9.4. Alices mekanismer............................................................................................474.9.4. En vidareutveckling av Alice............................................................................484.9.5. Programspråket Python.....................................................................................49

4.10. DARWIN.................................................................................................................514.10.1. Darwins värld..................................................................................................524.10.2. Programspråket DULL....................................................................................524.10.3. Programmering av kategorier (Species)..........................................................534.10.4. Darwins programkommandon.........................................................................544.10.5. Att exekvera ett Darwinprogram.....................................................................554.10.6. Att köra ett Darwinprogram............................................................................564.10.7. Darwins användning.......................................................................................57

5. ANALYSKRITERIER/MÅL......................................................................................58

5.1. UTGÅNGSPUNKTEN FÖR ANALYSEN.........................................................................585.2. ANALYSMETODEN....................................................................................................615.3. DE KONKRETA MÅLEN SOM UTGÖR GRUNDEN FÖR ANALYSEN...............................61

6. ANALYS.......................................................................................................................64

6.1. JKARELROBOT.........................................................................................................646.1.1. Gränssnittet.......................................................................................................646.1.2. Systemet............................................................................................................65

6.2. KARA.......................................................................................................................676.2.1. Gränssnittet.......................................................................................................676.2.2. Systemet............................................................................................................69

6.3. ALICE.......................................................................................................................706.3.1. Gränssnittet.......................................................................................................706.3.2. Systemet............................................................................................................73

7. DISKUSSION...............................................................................................................76

8. SAMMANFATTNING................................................................................................78

9. Tack...............................................................................................................................79

iv

1. Inledning

Objektorientering har blivit ett vanligt begrepp inom systemutveckling. Undervisningen inom området kan, trots dess snabba expansion, fortfarande betraktas som en experimentell pedagogisk uppgift som inte bara kräver en ändring av terminologin, utan också kräver ett nytt tänkesätt. Detta gör att övergången från de traditionella ansatserna till objektorientering förblir en komplex och krävande uppgift. Undervisning och inlärning av den objektorienterade ansatsen blir därmed en svår process med många frågor som måste besvaras; t.ex. Hur skall de olika begreppen introduceras? När och i vilken omfattning skall designen presenteras? Trots att objektorienterat tänkande är enkelt och mycket naturligt, har det visat sig att implementeringen av objektorienterade koncept är ganska svårt att förstå. Objektorienterad undervisning och inlärning upplevs ofta som en svår pedagogisk process där flera relaterade begrepp vanligtvis måste redas ut samtidigt, även i de mest triviala exemplen.

I de flesta fall är objektorienterad undervisning en bottom up process, dvs. elementära begrepp presenteras, beroende på svårighetsgraden, ett efter ett och utan direkt relation till varandra. En djupare insyn i de olika begreppen och deras inbördes relationer presenteras ofta senare i ett skede där studenten, trots kunskaper i olika modulariserings metodiker, oftast inte har någon större insyn i systemutveckling. Studenten har dessutom i många fall ännu mindre möjlighet att förstå systemet i dess helhet.

Analys och design är viktiga aspekter i objektorienterad mjukvaruutveckling och måste introduceras i ett tidigt skede före programmeringen. Studenten måste kunna skaffa sig en allmän bild av logiken i systemet samt det förväntade resultatet av sitt arbete, dvs. ett körbart program. Före introduktionen av objektdesign är det viktigt med en fullständig introduktion av hela det objektorienterade paradigmet för att därigenom skapa en bra förståelse av objektmetodologin. Det mest effektiva sättet att bättre möjliggöra för objekttänkande är att uppmuntra studenten att tänka i termer av fysiska objekt. För att underlätta detta måste så mycket som möjligt av allt bekant material avlägsnas så att studenten snabbare och lättare skall kunna lära sig detaljer som syntax och olika programmeringsoperationer när de grundläggande aspekterna är helt förstådda.

Det finns många olika faktorer som inverkar på undervisning och inlärning av objektteknologi. En av dessa är de exempel som används, speciellt de första exemplen. Bra exempel måste vara realistiska och inte avspegla en välkänd situation, så att nybörjare bara kan koncentrera sig på identifiering och användning av de nya objektorienterade begreppen.

Det senaste decenniet har bedrivits en hel del forskning kring undervisning och inlärning av objektteknologin och andra aspekter av mjukvaruutvecklingen. Man börjar tillämpa kognitionsvetenskapliga teorier i analyser av kunskapsstrukturer, och olika strategier av programmeringen. Detta har skapat en solid vetenskaplig grund som vägleder utvecklingen av en mer effektiv pedagogik inklusive stödverktyg och miljöer. En effektiv pedagogik gäller framförallt pedagogiska mönster. De implicerar många egenskaper som har en stor betydelse för undervisning, inlärning och utveckling av mjukvara i allmänhet.

1

Pedagogiska mönster representerar en stor vändpunkt i mjukvaruutveckling som skulle göra programmeringen tydligare och mer effektiv. De underlättar förståelsen av svåra och mer komplicerade system, och dessutom möjliggör de lättare och mer formaliserade sätt att dela erfarenheter. Pedagogiska mönster utgör också en väsentlig grund för konstruktion av olika stödverktyg och programmeringsmiljöer som utvecklades för att bl.a. underlätta undervisning och inlärning av objektteknologin. En viktig del av dessa stödverktyg och programmeringsmiljöer utgörs av olika typer av Microworlds. Microworlds är en form av interaktiva och grafikbaserade system som möjliggör för användaren att bl.a. utforska olika alternativ och testa olika hypoteser. Microworlds finns i olika typer och versioner som stödjer olika programmeringsspråk. En av Microworlds främsta egenskaper är att de möjliggör för användaren att få en direkt och visuell feedback när han/hon skriver sina instruktioner. På så sätt får användaren en bättre kontroll över vad som händer, exempelvis när variabler/objekt ändrar tillstånd/värde.

1.1. Syfte och metod

Det här arbetet syftar till att studera befintliga ansatser för undervisning och inlärning av objektteknologin i termer av Microworlds. Detta görs genom ingående sökningar av information om olika möjliga system som är utvecklade i syfte att effektivisera undervisningen och inlärningen av objektteknologin. Dessa system fungerar som undervisningsverktyg och har, till skillnad från traditionella ansatser, sin fokus på de underliggande koncepten istället för syntaxen. I arbetet redogörs för ett antal sådana system för att kunna ge någorlunda klar bild om hur dessa system fungerar. Sedan väljs tre av de för en mer detaljerad analys och utvärdering. Metoden för analysen och utvärderingen beskrivs utförligt i kapitel 5.

1.2 Disposition

Arbetet består av åtta kapitlen. Kapitel 1 är en inledning som ger en allmän överblick i ämnet. I kapitel 2 görs en kort beskrivning av det objektorienterade paradigmet och några andra begrepp som är grundläggande, samt en definition av en Microworld. I kapitel 3 redogörs för olika ansatser i form av pedagogiska mönster och olika teorier som syftar till att förbättra och effektivisera undervisningen och inlärningen. I kapitel 4 presenteras ett antal praktiska ansatser i form av Microworlds avsveda att fungera som mjukvaruverktyg som möjliggör presentation av objektorienterade koncept i en tydlig och meningsfull kontext. I kapitel 5 görs en utförlig diskussion av möjliga mål som anses karaktäriska för ett effektivt system, och vidare bestäms och formuleras ett antal konkreta mål som skall utgöra grund för analysen. I kapitel 6 väljs tre av de Microworlds som presenterades i arbetet, för en ingående analys. Analysen görs för ett system i taget och i form av en diskussion av de olika målen med hänsyn till det aktuella systemet. I kapitel 7 görs en diskussion som både visar likheter och skillnader mellan de tre systemen, samt deras lämplighet för användningen av studenter med olika prioriteringar. Kapitel 8 är en sammanfattning som betonar arbetets mest intressanta aspekter.

2

2. Definitioner

2.1. Vad är kognitionsvetenskap?

Kognitionsvetenskap är en av de viktigaste intellektuella utvecklingarna under de senaste decennierna. Begreppet är tvärvetenskapligt med kopplingar till flera olika områden som kognitionspsykologi, lingvistik, filosofi, datavetenskap och neurologivetenskap. Forskare från dessa områden insåg att de ställde många och mer eller mindre samma frågor som handlar om the nature of the human mind. Ordet kognition relaterar till perception och kunskap och därmed kan begreppet kognitionsvetenskap definieras som ”the science of the human mind” (Stillings, 1995, sida 1).

Enligt Stillings (1995) ser kognitionvetare på den mänskliga hjärnan som ett komplext system som tar emot regler, bearbetar och överlämnar information. Bearbetningen av information kallas för beräkningar eller informationsprocesser. En, för arbetet, intressant aspekt av kognitionsvetenskapen är kopplingen till bl.a. kognitionspsykologin som undersöker våra mentala förmågor som minne & inlärning, problemlösning, perception, uppmärksamhet, kommunikation, tänkande, mental representation och begreppsbildning. Kognitionsvetenskap inriktar sig på anskaffande, bearbetning och framställande av kunskaper och vidare på hur dessa används i olika tillämpningar. Konkret innebär detta ett sätt att se på vetenskapliga teorier utifrån praktiska tillämpningar, dvs. teorin härleds från applikationen, och inte tvärt om som man ofta ser det. Genom att studera praktiska tillämpningar av teoretiska modeller kan man få bättre insyn och därmed upptäcka brister och nya möjligheter som man inte tog hänsyn till tidigare. Detta medför viktiga kunskaper och nya aspekter som leder till förbättring av de teoretiska modellerna. Nackdelen är att en större vikt läggs på små detaljer på bekostnad av helheten, och därför blir den optimala modellen bara den bästa möjliga vilket anses tillräckligt.

Tillämpningar inom dataområdet kan illustreras genom att studera vad som händer när människor använder datorer och därmed bilda sig en uppfattning om deras beteende i allmänhet för att så småningom forma en teoretisk modell. Det som är extra viktigt i sammanhanget enligt Norman (1987) är sambandet mellan användarens psykologiska tolkning av uppgiften som skall utföras och det stöd som denna tolkning får av systemet.

2.2. Vad är objektorientering?

Objektorientering är en struktureringsteknik och ett tankesätt för att skapa programsystem. Tekniken bygger på att analys, design och programmering skall byggas runt objekt istället för runt funktioner. Dessa objekt är de begrepp som systemet hanterar (svaret på frågan VAD som görs) till skillnad mot funktioner som specificerar algoritmer (HUR det görs). Objektorientering kan också ses som en form av Modulariseringsmetod, där varje objekt är en modul i ett stort modulärt system. Sådana objekt är mer stabila när förändring sker än funktioner är, och kommer att klara förändring och utbyggbarhet bättre än system som är byggda runt funktioner. Objekten är, till skillnad från andra

3

modulariserings metoder, också på en relativt detaljerad nivå, och dessutom finns möjligheten att skapa nya objekttyper (klasser) utifrån existerade objekttyper via en mekanism som kallas för arv. Detta gör att man kan definiera en ny objekttyp utifrån en existerande genom att endast definiera de egenskaper som skiljer objekttyperna åt, och återanvända de egenskaper som det existerande objektet har. Genom arv går det att uppnå återanvändning både inom en viss applikation och genom att identifiera tillräckligt generella objekt även mellan olika applikationer (Ericsson 1992).

En objektorienterad process börjar enligt Guzdial (2001) med att först identifiera substantiven i den del av världen som är relevant för programmet som skall utvecklas. Senare identifieras de objekt i den värld där programmet är avsedd att arbeta. Man definierar de olika objektens data, vad de gör (deras beteende), samt hur dessa objekt interagerar med varandra. Syftet med dessa definitioner är att kunna modellera den värld vari programmet kommer att fungera. Denna värld kallas för programmets domän.

2.2.1. Grundläggande begrepp

Ett programspråk är objektorienterat om det ger fullt stöd för inkapsling, dataabstraktion, arv, polymorfism och egen rekursion. Exempel på objektorienterade programspråk är Ada 95, C++, Effel, Objektiv C och Smalltalk. Ett objektorienterat program är ett exekverbart assemblering av objekt. De centrala begreppen inom objektorientering är klass och objekt. Ett Objektorienterat system består av ett antal klasser och objekt som instansieras av dessa klasser (Binder, 2000). De följande begreppen, klass, objekt, arv och polymorfism är några av de viktigaste och betraktas allmänt som karaktäristiska för objektorienterade programmeringsspråk:

Klass: är en lexikal enhet av olika satser (instruktioner) från vilka objekt kan skapas. I klassen beskrivs de olika egenskaperna (dock inte de specifika värden på egenskaperna) som objekten har, som hur objekten skall representeras, vilka möjliga operationer kan utföras på objekten och hur dessa operationer skall utföras. Klassen i sig är inte något av de objekt som den beskriver. En viktig aspekt av klassen är att den bara beskrivs en gång i programmet och sedan är det möjligt att skapa (instansiera) olika objekt med olika egenskaper av denna klass (Poplawski, 2002). Man säger att ett objekt är en instans av en viss klass. Då man skapar ett objekt instansierar man en klass. Klassen representerar typen, medan objektet representerar en förekomst av denna typ. Man kan inte utföra några operationer direkt på klassen. Den fungerar endast som en mall för de objekt (förekomster) av klassen som man senare skapar.

Klassen talar om för datorn, vilka egenskaper och beteenden som varje objekt som tillhör klassen har. Om exempelvis ett objekt som tillhör en specifik klass ombeds att göra något, så använder datorn beskrivningen av objektbeteenden som finns i klassen och de aktuella värdena av de, för uppgiften, relevanta egenskaperna hos detta objekt för att möjliggöra för tillåtna händelser. En klass betraktas som en kontrakt mellan utvecklaren av klassen och användaren och kan ses som en enhet bestående av två delar, en specifikations del och implementation del.

4

Objekt: Objekt är ett centralt begrepp inom den objektorienterade design- och programmerings filosofi. De har egenskaper som kan ändras under tiden och beteenden som kan variera beroende på egenskapernas aktuella värden, dvs. de gör saker som vanligtvis är beroende på sina egenskaper (Poplawski, 2002). Ett program består av många olika objekt som interagerar med varandra för att ändra på varandras egenskaper och därigenom möjliggöra för olika händelser. Ett objekt är en instans av en klass skapad vid kompilerings och exekverings tillfällen enligt dess klassdefinition och semantiken av dess programmeringsspråk. Objektet har en representation som beskriver dess nuvarande tillstånd och de olika operationer som kan användas för att på olika sätt påverka eller manipulera objektet. Ett objekt kan antigen ha direkt motsvarighet i verkligheten som exempelvis bankkonto, bil, eller kan vara ett implementerings objekt som exempelvis en länkad lista eller ett stack. Ett objekt är alltid av en viss klass. Olika objekt som tillhör en viss klass är fristående från varandra, och en operation på ett visst objekt påverkar endast detta objekt och ingenting annat.

Arv: är en helt unik metod för objektorientering. Den sker mellan klasser och inte mellan objekt. Vid en ny definition av en viss klass, arvs egenskaper från en annan existerande klass. Det enda som behöver beskrivas i den nya klassen är skillnaden gentemot den existerande klassen. Denna skillnad består oftast av tillägg av representationer och operationer, men kan också bestå av omdefinition eller borttag av operationer. Den existerande klassen kallas för superklass och den nya klassen kallas för subklass.

Polymorfism: Polymorfism innebär i praktiken något som kan ses som överlagring av funktioner och metoder. Den underlättar kommunikationen mellan objekt. Begreppet innebär att ett objekt kan skicka samma information till flera andra objekt, som tillhör olika klasser. Dessa objekt bearbetar sedan informationen och tolkar den på sitt sätt. Med andra ord behöver informationen inte vara speciell för varje objektklass. Fördelen med detta är att det blir lättare att underhålla programmen. Andersen (1991) försöker belysa begreppet Polymorfism genom ett exempel ur verkligheten: "En chef kan be flera av sina medarbetare om en lägesrapport där varje enskild individ tolkar denna begäran på sitt sätt och skriver sin rapport med det innehåll som är relevant för vederbörandes situation.”

Ett exempel på Polymorfism i programspråk är när flera funktioner kan ha samma namn så länge funktionernas parametrar skiljer sig åt på något sätt (Davis, 1996). Det är vanligt att man ibland måste skriva många olika funktioner som logiskt uträttar samma sak, men som av mer tekniska skäl (varje datatyp måste behandlas på sitt sätt) framtvingar olika versioner. Genom att använda samma namn för sådana funktioner blir användningen av dessa funktioner enklare och mer naturlig.

2.2.2. Den objektorienterade utvecklingsprocessen

Den optimala utvecklingen av objektorienterad mjukvara kräver att man lär sig mer än bara programmeringsspråk; man behöver grundläggande kunskaper i objektorienterade analys- och designmetoder, vilket ofta är svårt att på ett övertygande sätt förmedla till

5

studenterna. Det viktigaste för studenterna är oftast själva koden. Så om koden verkar fungera då är den tillräcklig bra. Detta beror ofta på att de inte varit involverade i utvecklingen av något större mjukvaruprojekt. En mer eller mindre standardiserad utvecklingsprocess för mjukvara beskrivs i olika litteratur som behandlar ämnet Objektorientering. Guzdial (2001) menar att utvecklingsprocessen består i huvudsak av tre faser:

Objektorienterad analys: den fokuserar på problemet och syftar till att definiera en objektbaserad modell av domainen där programmet skall fingera. Analysen resulterar i en lista av objekt med data och beteenden, samt relationer mellan dessa objekt. Objektorienterad design: den fokuserar på själva lösningen. Kunskaper och information från analysen appliceras på en implementation i ett visst programspråk. Målet är en detaljbeskrivning av slutprogrammet så att det går att implementera.

Objektorienterad programmering: byggandet av programmet som tidigare designats.

2.3. Vad är en Microworld?

En Microworld är ett begrepp som myntades av MIT Media Lab Learning and Common Sense Group. Det betyder en liten värld där man kan utforska olika alternativ, testa hypoteser och upptäcka fakta som är sanna om världen (MIT Media Lab, 1995). En Microworld skiljer sig från en simulering på så sätt att man uppmuntras att se den som en ”verklig” värld och inte som en simulering av en annan värld (t.ex. den fysiska världen som vi lever i). Flake (2000) beskriver ett antal egenskaper som är karaktäriska för en Microworld. Dessa är följande:

1. Möjliggör för en experimentell inlärning, inklusive utforskning och intuitivt skapande.

2. Är konceptuellt baserad.3. Innehåller en underliggande struktur för ämnet som skall utforskas.4. Möjliggör för en stor kognitiv omstrukturering som underlättar för studenterna att

på ett meningsfullt sätt konstruera kunskap. 5. Möjliggör för studenterna att generera feedback från vilken de kan bedöma

effektiviteten av sitt sätt att tänka.6. Är i grunden tillräckligt intressant för studenterna för att vilja diskutera alternativa

strategier med andra studenter och på så sätt befrämja sociala konstruktioner.7. Möjliggör för reflektiva abstraktioner.8. Är lätt att sätta igång.

Ett enkelt exempel på Microworlds är en avstängd container som bara innehåller vete- och syreatomer. Modelleraren skapar regler för interaktion mellan atomerna som kan resultera i sådana saker som skapandet av vatten.

6

3. Ansatser för undervisningen och inlärningen

Den snabba utvecklingen inom informationsteknologin och dess utbredning till de allra flesta arbetsområden, medförde att dagens datoranvändare inte längre behöver skriva sina egna program. De kan istället använda sig av färdigbyggda applikationer i form av mjukvarupaket som innehåller verktyg som är kraftfullare än någon användare kan själv skriva. Introduktionskurser i programmeringsgrunder som var vanliga under de senaste decennierna, ersätts nu med kurser som ger färdighet i hur man använder färdigt implementerade applikationspaket. Grundläggande arbetsfärdigheter som kunskaper i något ordbehandlingsprogram, kalkylprogram eller Internet, kräver i dag bara en kort introduktion och därefter kan användaren på egen hand uppnå den nivån som han/hon önskar. De fundamentala koncepten av programmering kan vara intellektuellt krävande och därför bör man undvika att först introducera nybörjare till de komplexiteten som är inbyggda i de professionella programmeringsspråk och miljöer.

Att lära sig programmering som en utbildningsövning fri från begränsningar, görs bäst i en lekfull miljö som är designad för att illustrera valda begrepp på det bästa möjliga sättet. (Hartman, Nievergelt & Reichert, 2001) hävdar att begreppet ”relevant utbildning” har ofta och för enkelt misstolkats när undervisningen i huvudsak fokuseras på kunskaper som har en omedelbar användning. Detta resulterar i enkla färdigheter som ”hur man gör det” istället för förståelse av koncept och principer av ”varför och hur det fungerar”. I ett snabbt föränderligt område som informationsteknologin, är de mest effektiva och användbara system nästan värdelösa när nya och effektivare system installeras några år senare.

Det finns många olika ansatser som intar olika former och syftar till att förbättra undervisning och inlärning av objektteknologin. En del ansatser är mer teoretiska, erfarenhetsbaserade och utvecklade av lärare och forskare i ämnet, medan andra är av en mer praktisk karaktär och utvecklade av experter och företag i bl.a. kommersiellt syfte. Det som är av huvudintresse för arbetet är den andra typen av ansatser, dvs. ansatser av praktiska karaktärer i form av Microworlds. Ett antal Microworlds som anses lämpliga för undervisning och inlärning av objektteknologi och programmering i ämnet, presenteras nedan med någorlunda detaljbeskrivning för att senare kunna välja tre av dessa för ingående analys och utvärdering. Analysen utgår ifrån ett antal fördefinierade mål som ansågs heltäckande för området objektorientering.

Den moderna utbildningsfilosofin domineras av nya ämnen som anses vara grundläggande för en bättre undervisning och inlärning. Två av de viktigaste ämnen i denna filosofi är konstruktivism och minimalism.

3.1 Konstruktivism

Konstruktivism är en metod för undervisning och inlärning. Den utgår ifrån idén att kognition (inlärning) är ett resultat av en mental konstruktion, dvs. studenter lär sig genom att använda (anpassa) ny information tillsammans med den information som dom

7

redan har och därigenom konstruera sina egna kunskaper. Inlärningen påverkas starkt av den kontext i vilken en viss idé är presenterad, samt av studenternas uppfattningar och attityder. Studenter uppmuntras till att uppfinna sina egna lösningar och att prova på olika idéer och hypoteser. De ges möjligheten att vidare bygga på tidigare kunskaper. Som en form av pragmatism, fokuserar konstruktivism på hur människor uppnår de kunskaper som möjliggör för dem att handskas med sin omvärld, dvs en teori av kontenuerlig konstruktion av kunskap, eller mer specifikt, en terori om hur individer och samhällen av individer uppfattar världen (Larochelle, 98).

Konstruktivismens inställning till undervisning och inlärning är ett resultat av arbeten utförda av psykologer och utbildare som Jerome Bruner, Jean Piaget och Lev vygotsky. Denna inställning skiljer sig från det traditionella synsättet som säger att kunskaper existerar oberoende av individen och att medvetandet är en blank tavla varpå en bild kan målas. Undervisningen, enligt konstruktivism, kan inte ses som en förmedling av kunskaper från upplysta individer till ovetande, dvs. konstruktivist lärare intar inte rollen av ”sage on the stage” och hellre agerar som ”guides on the side ” som förser studenterna med möjligheter att testa relevansen i sina aktuella förståelsen (SEDL, 1996).

Under de senaste två decennierna har försakare sysslat med utveckling av förståelse för inlärning som växer utav kognitiv- och utvecklingspsykologi. Grund idén i denna nya “konstruktivistteorin” är att människor i allmänhet bäst lär sig genom att aktivt konstruera sin egen förståelsen. Den fundamentala uppfattningen som ligger till grund för detta nya paradigm för inlärning har av (North Central Regional Educational Laboratory) summerats som följande:

All kunskap är konstruerad genom en process av reflektiv abstraktion.

Kognitiva strukturer som finns inom studenten bestyr inlärningsprocessen.

De kognitiva strukturerna inom individerna är i en process av konstant utveckling.

Om notationen av konstruktivistinlärning är accepterad, då måste metoderna för inlärning och pedagogik godkänna.

Konstruktivism har blivit en stor filosofisk referensram för reformering av vetenskapsutbildningen. Begreppet konstruktivism uppfattas som en allmän term som implicerar olika tolkningar och därigenom har olika versioner av konstruktivism utvecklats som radikal, pragmatisk, kontextuell, Piagetiansk, social och kognitiv konstruktivism (Larochelle, 98). De versioner som är relevanta för utveckling och användning av IT applikationer är kognitiv konstruktivism och social konstruktivism.

3.2. Minimalism Minimalism är en handlings och uppgiftorienterat synsätt/metod för undervisning och dokumentation. Den betonar vikten av realistiska aktiviteter och erfarenheter för en

8

effektiv inlärning och informationssökning. Minimalism kan också ses som ett deskriptivt synsätt för design av en effektiv undervisning. En av grundidéerna i det minimalistiska perspektivet är att lyfta fram de minsta möjliga hindren mot studenternas ansträngningar och även utnyttja de inlärningsstrategier som förorsakar problem för studenterna, genom användning av systematiska undervisningsmaterial (Harapnuik, 2001). Minimalist teorin av J. M. Caroll utgör en ram för designen av undervisning, speciellt som övningsmaterial för datoranvändare (Ryder, 2003). Teorin består av fem punkter/förslag:

1. Alla inlärningsuppgifter bör vara meningsfulla och självständiga (self-contained) aktiviteter.

2. Studenter bör ges realistiska projekt så fort som möjligt.3. Undervisning bör tillåta självinitierad resonering och improvisering genom

ökning av antalet aktiva inlärningsaktiviteter.4. Övningsmaterial och aktiviteter bör underlätta för studenter att upptäcka och

åtgärda fel som kan uppstå.5. Det bör vara en nära koppling mellan övningen och det verkliga systemet.

Minimalism har, enligt Caroll, sina rötter i konstruktivismen av Bruner och Piaget. Grundidén i minimalistteorin är att minimera den negativa inverkan av undervisningsmaterial på inlärning och vidare fokusera designen på aktiviteter som stödjer studentstyrd aktivitet och prestation. Minimalismens främsta mål är att inte stå i vägen för studenterna. Det går ut istället på att låta studenterna få mer utav sin inlärning och övningserfarenhet genom att göra övningsstrukturen mindre explicit. Minimalismen har till skillnad från många andra undervisningsteorier och synsätt, utvecklats från den empiriska (erfarenhetsbaserade) processen. Studenter möter ofta fler problem när de använder sig av stöd och inlärningsmaterial än när de på egen hand försöker utforska och lära sig det nya systemet.

3.3. Pedagogiska mönster

Pedagogiska mönster är en mycket vanlig företeelse inom objektorientering. Ett pedagogiskt mönster beskrivs allmänt som är en lösning till ett problem i en viss kontext. Beskrivning betonar i första hand en ”lösning”. Detta innebär dock inte att ett mönster enbart levererar ett entydigt svar i form av ett recept eller en algoritm, utan istället det åskådliggör hur man hanterar liknande situationer i framtiden (Zubek, 1998). Ett pedagogiskt mönster kan också ses som ett försök att fånga den bästa kunskap i ett visst område och vidare förmedla denna kunskap till andra. Pedagogiska mönster uttrycker inte nya idéer. De uttrycker det som är testat och välprovat inom ett visst område (Bergin, 2003). Man hoppas att Pedagogiska mönster kan användas för att vitalisera den inledande utbildningen inom datavetenskap genom att göra den mer effektiv så att svårare material kan effektivt inläras och tidigare än det som vanligtvis kan göras med andra tekniker.

9

Bergin (2003) definierar ett mönsterspråk som en grupp av relaterade mönster som samverkar för att lösa ett större problem, eller som fungerar som en alternativ lösning till ett specifikt problem. Pedagogiska mönster kan användas för att introducera nytt material i inledande stadier av utbildningen under förutsättning att studenterna kan se och identifiera dem. De kan dessutom användas för att sammanfatta och fånga det grundläggande i tidigare presenterat material. För att Pedagogiska mönster över huvud taget skall vara effektiva och användbara för mer än sammanfattning av inlärda kunskaper, måste studenten vänja sig vid grundidéerna och tillämpningarna av sådana mönster. Två grundläggande och ofta användbara undervisningstekniker är (1) subtilitet och (2) explicithet. Dessa tekniker formar mottsatta periferier av en skala i medvetandet (Bergin, 2003). Den enda är ibland kraftfullare än den andra.

Det finns två mönsterskolor som arbetar med två skilda inriktningar. Den ena inriktar sig på designmönster, medan den andra inriktar sig på pedagogiska mönster. De två skolorna bidrar på olika sätt till förbättringar i utbildningen. Designmönsterskolan bidrar med ”vad som skall undervisas”, medan pedagogiska mönsterskolan bidrar med ” hur det skall undervisas”. Det som är mest väsentligt för arbetet är pedagogiska mönster där huvudfokusen ligger på undervisningen.

3.3.1. Early Bird Pattern

Grundidén i detta mönster är att undervisningen bör organiseras såt att det viktigaste materialet presenteras först och ofta. När detta ibland verkar omöjligt bör det viktigaste materialet presenteras så tydigt som möjligt. Studenterna behöver se att tidigare presenterade detaljer, fortsättningsvis skall relatera till viktiga idéer. Det som studenterna bäst minns ofta är det först inlärda materialet. Viktiga idéer och speciellt deras inbördes relationer kan introduceras tidigt även om dom inte direkt får en fullständig behandling. De får istället tas upp vid upprepade tillfällen under utbildningsgång. En del stora och grundläggande koncept kan verka för avancerade för att tidigt introduceras och därför kan bara enkla aspekter av dessa koncept introduceras tidigt. I sådana fall krävs det en välgenomtänkt uppläggning av utbildningen (Bergin, 2002).

Det finns många olika koncept/begrepp som kan betraktas som väsentliga och därför bör introduceras först. I vissa situationer kan det uppstå åtskilda meningar om vad som är väsentligt, men det är till slut upp till läraren att upptäcka och implementera vad han/hon anser väsentlig och bör introduceras först.

Early Bird Pattern är mycket användbar och kan i stort sett tillämpas i varje område. Inom Microworlds har exempelvis boken Karel the robot som utgör grunden för JkarelRobot, designats med utgångspunkt av detta mönster och som ett sätt att undervisa proceduell programmering (procedurer först). Dess efterföljare, Karel++, avser att göra samma sak med objekt där klasser av objekt betraktas som grundläggande och bör introduceras först (Bergin, 2002).

10

3.3.2. Spiral Pattern

Detta mönster föreslår att ämnen delas in i olika fragment som presenteras i en viss ordning för att därigenom underlätta för studenten att lösa problem. Många av fragmenten introducerar ett visst ämne dock med bara få detaljer som är tillräckliga för att skapa en primär förståelse som kan användas i problemlösningen. I nya omgångar inkluderas fragmenten med djupare detaljer om ämnet (Bergin, 2002). Detta mönster rekommenderas i de fall där ett stort antal nya begrepp måste presenteras samtidigt. Spiralmönstret kan användas i många olika kurser som specifika kurser i objektteknologi, och framför allt i den inledande fasen av utbildningen.

Utbildningen bör organiseras genom att först översiktligt introducera de olika momenten så att ett antal begrepp kan tydigt presenteras och senare användas. Detta möjliggör för studenterna att tydigt jobba med intressanta problem även om de inte helt behärskar verktygen. Läraren kan senare och vid olika tillfällen återgå till de tidigare presenterade momentena för en mer detaljerad beskrivning som underlättar för studenterna att bemästra dem. Uppdelningen av ämnet på det visset syftar till att förse studenterna med färdigheter i problemlösning.

(Bergin, 2002) hävdar att en effektiv användning av detta mönster behöver att man gör en plan som visar den ordning vari de olika momenten skall introduceras och vidare vad som skall utelämnas till andra tillfällen under utbildningsgång. Inom området objektteknologi kan exempelvis en enkel form av arv introduceras och vidare användas innan Polymorfism (dynamisk bindning) ens diskuterats. Användningen av Spiralmönstret måste vara långsiktigt, dvs. sträcka sig över hela utbildningen.

3.3.3. Simple and Complete Patterns Step by Step

Detta pedagogiska mönster används för undervisning av grunderna i objektorienterad design och programmering. Mönstret underlättar förståelsen av det grundläggande i ett visst ämne så att man effektivt och säkert kan tillämpa det (Angster, 2000). Detta mönster är välkänt och tillämpningsbart inom alla områden. Det är speciellt användbart i undervisning av objektorienterade koncept och objektorienterad mjukvaruutveckling. Trots att objektorienterat tankande är rätt så naturligt, har det visat sig att implementeringen av objektorienterade koncept är ganska svårt att förstå. I stora och komplicerade ämnen är det ofta svårt att få grep över något mer konkret från vilket man kan gå steg för steg. Det är mycket viktigt för studenterna att först se ett mycket smalt och fullständigt mönster. Studenterna kan därefter på egen hand utföra övningen genom en liten modifikation av mönstret. De elementära mönstren måste vara lätta att följa och modifiera över hela studiematerialet.

Simple and Complete Patterns Step by Step är strukturerad på ett sådant sätt, att de olika momenten i det aktuella studiematerialet bygger på varandra. Angster (2000) betonar att varje moment består av följande delar:

11

Läraren visar en enkel, dock fullständigt mönster. Mönstret går in i detaljerna och exakt till den djup där problemet helt är begripligt och lätt att följas från början till slutet.

Läraren kategoriserar mönstrets olika element i ett litet antal kategorier. Studenterna modifierar mönstret. Studenterna får ett problem som de kan lösa med stöd av det givna mönstret.

Detta pedagogiska mönster är applicerbart i undervisning av många olika saker. Studenterna kan snabbt och framgångsrikt lösa små problem, samt lätt och effektivt förstå de relaterade begreppen.

3.3.4. Design-Do-Redo-Redo (DDRR) Pattern

DDRR mönstret är användbar i undervisning av objektorienterad programmering för seniorstudenter, dvs. studenter som redan har vissa förkunskaper i programmering. Den är avsedd att fungera ovasst vilket objektorienterat programmeringsspråk man använder. Jenkins (2000) betonar att grundidén i detta mönster är att undervisa objektorienterade begrepp som inkapsling, abstraktion och Polymorfism, oberoende av programspråket. Studenterna designar en objektorienterad lösning till en programmeringsuppgift och sedan implementerar den i ett bestämt antal objektorienterade programmeringsspråk. Studenterna får därigenom en hands-on erfarenhet i olika objektorienterade programmeringsspråk och miljöer, samt kunskap om hur man på egen hand kan lära sig ett nytt objektorienterat språk. Jenkins (2000) sammanställer ett antal viktiga frågor som man bör tänka på vid tillämpningen av detta mönster. Dessa är följande:

Den är designad för seniornivå studenter som redan bemästrar minst ett programmeringsspråk. En användning i introduktionskurser i programmering är kontraproduktiv och därför bör undvikas.

Programmeringsuppgiften måste vara väldefinierad för att därmed garantera att studenterna skall implementera de tilltänka koncepten.

En snabb feedback till studenterna om deras arbete är nödvändigt för att de skall kunna undvika att göra samma fel i kommande uppgifter.

Detta mönster kan vändas, förutom i undervisningen av objektorienterade koncept, också undervisningen av Smalltalk och C++ programmering. Den har tidigare använts med tillfredsställande resultat, även om ytterligare förbättringar kan göras.

3.3.5. Lab-Discussion-Lecture-Lab (LDLL)

Detta mönster erbjuder ett alternativt sätt för introducering av mjukvara koncept och verktyg i programmeringsspråk. Det börjar med en inledande, steg för steg, laboration följd av en diskussion och vidare en redogörelse för vad studenterna gjorde. En djupare

12

insyn i de olika begreppen kan senare åstadkommas genom att använda dem i en ny och mer avancerad laboration (Manns, 2000). LDLL mönstret är strukturerad på ett sådant sätt att tillämpningen börjar med en laborationstid där studenterna stegvis utför en given uppgift avsedd att introducera olika mjukvara koncept/begrepp.

Laborationen måste innehålla detaljerade instruktioner, samt frågor som uppmuntrar studenter till att notera och analysera vad dom ser på skärmen under arbetet med övningen. En avslutad laboration följs av en utförlig diskussion om vilka koncept som var obekanta för studenterna, samt vilka problem som studenterna möttes på i arbetet med övningen. Diskussionen följs med en föreläsning om de nya koncepten som introducerades i laborationen, och med ständigt hänvisning till de erfarenheter som studenterna hade medan dom arbetade med laborationen. Avslutningsvis utför studenterna en mer komplicerad laborationsuppgift som betonar och testar förståelsen av de nya koncepten hos varje students. Manns (2000) summerar de viktigaste aspekterna av LDLL mönstret med följande:

Den möjliggör för studenterna ett aktivt deltagande i sin inlärning genom att, samtidigt som studenterna använder mjukvaran introducera dem till nya koncept.

Den uppmuntrar studenterna att anteckna och reflektera över vad som hände när dom var sysselsätta med sin inlärning.

Den möjliggör för lärare att ge mer konkreta och mindre abstrakta lektioner.

Ett antal viktiga frågor att tänka på vid tillämpningen av detta mönster är följande:

Laborationsövningarna kan vara korta och täcka en eller två koncept, eller långa sådana som täcker flera koncept och som bör slutföras utanför den ordinära lektionstiden.

Den första laborationen måste vara skriven i en detaljerad, steg för steg, skapnad och innehålla referenser till dokumentation och annat klargörande hjälpmedel.

Den uppföljande laborationen bör kräva utforskande färdigheter och testa studentens förståelse av koncepten. Till skillnad från den första laborationen bör den utvärderas av läraren.

Detta mönster har använts i en del olika områden, bl.a. i undervisningen av det objekt orienterade programspråket Smalltalk miljön och dess programmerings koncept.

13

3.3.6. Mission Impossible

Mission Impossible är ett pedagogiskt mönster som är användbart i flera olika områden. Inom objektteknologiområdet, uppmuntrar Mission Impossible studenterna till att ständigt ifrågasätta sin förstående av viktiga objektteknologiska begrepp. Studenterna kan därmed ständigt fundera över dessa begrepp och därigenom förbättra sin förståelse av dem. Vissa idéer som t.ex. ”objekt modellerar den verkliga världen” kan uppfattas på ett sådant naivt sätt som utarmar studenten inför nya problem som kan uppstå. Mission Impossible uppmuntrar studenterna till en djupare inblick i vad de gör genom att introducera problem som utåt verkar enkla men i verkligheten inte går att bara lösa genom en naiv tillämpning av inlärda kunskaper (OĆallaghan, 2000).

Mission Impossible kan bäst tillämpas när studenterna redan uppnått en viss nivå av kunskaper och hands-on erfarenheter. Det kan dessutom fungera som en länk mellan inlärningen av det grundläggande och det mer avancerade i ett visst område. OĆallaghan (2000) hävdar Mission Impossible är konstruerad utifrån erfarenheter hos olika kategorier av studenter i datavetenskap. Det har också använts i undervisningen av ett antal kurser i objektteknologi vid De Montfort universitet i, Leicester, England för både studenter i grundutbildning och forskarstudenter.

3.4. En ansats för en ny programmerings pedagogik

Objektorienterad programmering skiljer sig i många avseenden från traditionell imperativ programmering och därför behövs det en ny pedagogik för undervisningen i ämnet. De traditionella metoderna för undervisning av objektorienterad programmering fokuserar antingen på själva språket eller på programmeringen. Det befintliga materialet i form av olika böcker begränsar sig ofta till en mycket detaljerad beskrivning av alla de begrepp som finns i ett programmeringsspråk som C++ eller Java och i stort set förbiser konsten av en bra programmeringsmetodik (Dockx & Steegmans, 2002). Dessa typer av böcker är mest användbara för personer som redan har erfarenheter av objektorienterad programmering och som snabbt behöver lära sig de tekniska detaljerna av ett nytt objektorienterat programmeringsspråk.

Grundläggande och intima kunskaper i de typiska objektorienterade begreppen är naturligtvis mycket viktigt, men ännu viktigare är kunskaper om hur dessa koncept hanteras för att därigenom åstadkomma högkvalitativa mjukvara. Dockx & Steegmans (2002) konstaterar att programmeringen och undervisningen av programmering är baserade på fyra viktiga koncept: sekvens, urval, iteration och abstraktion. Detta synsätt har visat sig mycket framgångsrikt i undervisning av strukturerad programmering i imperativa/proceduella språk. Dessa koncept har däremot visat sig mindre centrala i objektorienterad programmering. De ersättes istället med de nya koncepten: inkapsling, objektstruktur, objektinteraktion, arv, Polymorfism och dynamisk bindning.

Dockx & Steegmans (2002) betonar att den inledande fasen av undervisningen bör fokuseras på definitionen av en klass som en beskrivning av objekt med gemensamma

14

egenskaper och beteenden. I den andra fasen förflyttas fokusen från utvecklingen av en enkel klass till struktureringen av ett mjukvarusystem som en helhet av relaterade klasser. Den tredje fasen fokuseras på arv. Först introduceras grunderna och syntaxen genom enkla exempel och med betoning på återanvändning. Polymorfism och dynamisk bindning bör diskuteras i kontexten av specialiseringen av arv. I den fjärde fasen görs jämfotelser mellan rekursiva och iterativa algoritmer, samt en introduktion till backtracking. Objektorienterad kod kan vid behöv och i olika stadier av undervisningen, jämföras med liknande implementationer i traditionella programmeringsspråk som Pascal och C.

Man bör också diskutera hur man validerar objektorienterade program och dessutom verifiera de nya koncepten som skall introduceras. Principerna av objektorienterad programmering kan så småningom konkretiseras i ett antal specifika regler som repeteras i slutet av varje etapp av undervisningen.

3.5. Kognitiva nivåer (Blooms taxonomi)

Undervisningen och inlärningen av nya kunskaper i allmänhet, kräver att man följer ett väl välstrukturerat mönster som väl beaktar människans kognitiva förmågor. Detta är också av stor betydelse för Microworlds. Den interaktiva miljön som utgör milstolpen i Microworlds, exempelvis JkarelRobot, medför att studenten får fortlöpande träningar i olika kognitiva nivåer som underlättar förståelsen och inlärningen av nya material. Bloom (1956) klassificerade ett antal viktiga och välkända kognitiva nivåer avsedda att fungera som en vägledning i detta sammanhang. Dessa kognitiva nivåer som beskrivs nedan utgörs av kunskap, förståelse, applikation, analys och syntetik.

Kunskap

Förmågan att effektivt minnas tidigare inlärt material. Kunskapen betonar mest den psykologiska processen av memorering. Det väsentliga i denna process är förmågan att minnas konkret information som är passande för den aktuella situationen. Det kan röra sig om beaktandet av en bredd räckvidd av material, allt från specifika fakta till fullständiga teorier och strukturer.

Specifika fakta avser memorering av specifika och isolerade bitar av information med betoning på konkreta symboler. Materialet betraktas utgöra de element från vilka mer komplexa och abstrakta former av kunskap skapas. Teorier avser kunskaper om principer, generaliseringar och deras inbördesrelationer som tillsammans presenterar en klar och systematisk seende av ett komplext problem eller område.

15

Förståelse

Förmågan att effektivt fånga in meningen med ett visst material eller en viss idé. Detta kan visas genom en översättning av materialet från en form till en annan (t.ex. ord till siffror), genom klarläggandet av materialet eller genom en rätt uppskattning av de framtida trenderna som förutsägandet av effekter och konsekvenser. Översättningen avser bl.a. förmågan att förstå otydliga yttranden som metaforer och symbolism. Kartläggandet av material avser förmågan att förstå tanken bakom arbetet som en helhet och på alla tänkbara nivåer av generalisering.

Applikation

Förmågan att använda det inlärda materialet i nya och konkreta situationer. Materialet kan ta olika former som allmänna idéer, regler, generaliserade metoder, tekniska principer, lagar och teorier som måste läggas på minnet och vidare tillämpas. Detta inbegriper bl.a. förmågan att uppskatta den förväntade effekten av en specifik tillståndsförändring i en viss situation.

Analys

Förmågan att bryta ner material i mindre biståndsdelar för att därigenom underlätta förståelsen av dess struktur. Detta inbegriper identifieringen av olika delar, analys av relationer mellan olika delar, samt identifiering av de invecklade organisatoriska principerna.

Identifieringen av de olika elementen (biståndsdelarna) omfattar förmågan att identifiera otydliga antaganden, samt förmågan att urskilja mellan fakta och hypoteser. En analys av relationer mellan de olika delarna innefattar förmågan att testa hypotesernas giltighet med givna informationer och antaganden, samt förmågan att uppfatta inbördesrelationerna mellan de olika idéerna i ett visst mönster. Identifieringen av de invecklade principerna omfattar så väl den explicita som den implicita strukturen, samt förmågan att identifiera både form och mönster i olika arbeten som ett sätt förstå deras innebörd.

Syntetik

Förmågan att sätta ihop olika delar för att forma en ny helhet, dvs. att organisera och kombinera de olika delarna på ett sådant sätt så att de formar ett visst mönster eller en struktur som dessförinnan inte var tydligt. Detta inbegriper utvecklingen av en unik kommunikation, en handlingsplan eller en grupp av abstrakta relationer.

16

Kommunikationen avser bl.a. förmågan att effektivt förmedla personliga erfarenheter, medan en handlingsplan avser förmågan att sammanställa en grupp av instruktioner för en specifik undervisningssituation. Utvecklingen av abstrakta relationer avser en klassificering eller förklaring av en specifik data eller en företeelse. Detta innefattar bl.a. förmågan att formulera lämpliga hypoteser utifrån en analys av de invecklade faktorerna, och vidare att modifiera sådana hypoteser med hänsyn till nya faktorer och uppväganden.

Evaluering

Förmågan att kunna bedöma värdet av material (t.ex. en forskningsrapport) för ett visst ändamål. Bedömningen bör utgå ifrån väl definierade kriterier. Dessa kan vara interna kriterier (organisation) eller externa kriterier (relevans till syftet). Bedömningen i termer av interna kriterier avser bl.a. förmågan att uppdaga logiska fel i argument. Bedömningen i termer av externa kriterier avser evaluering av material utifrån ett valt eller ihågkommit kriteriet. Detta innebär förmågan att jämföra ett visst arbete med de högsta kända standarderna i dess område, speciellt med andra arbeten av välkända kvalitéer. Studenten kan antingen själv bestämma kritirerna eller få dem av en annan instans.

17

4. Elektronisk inlärning

Internet är en väsentlig komponent av ett nytt socioteknisk system med en stor inlärningspotential. Hur effektivt är denna typ av inlärning är i stor utsträckning beroende på vilken typ av Internetmjukvara som studenterna använder, och vidare på vilka aktiviteter och socialmiljö som omger processen av Internetanvändning, både i skolor och hemma. Många av de nuvarande utbildningsapplikationerna av Internetteknologi fokuserar på olika typer av information som exempelvis förmedling av information till studenter i distansutbildning.

Inlärning är i grunden en social process. Norman (87) hävdar att det är mycket vanligt att användare ofta föredrar att söka hjälp hos andra användare än att läsa manualer och andra hjälpmedel. Gruppsamarbete kan därför vara en kraftfull resurs för exempelvis barnens inlärning. Detta förutsätter att aktiviteterna är strukturerade för att främja en produktiv interaktion. Det finns många olika applikationer i form av mikrovärldar som är avsedda att fungera som utbildnings/inlärningsverktyg för så väl barn som vuxna.

4.1. Programspråket LOGO

Logo är ett programspråk som i huvudsak utvecklades av Seymour Papert med en del hjälp av andra personer på MIT media lab. Med Logo kan man göra nästan allting som kan göras med andra programmeringsspråk som BASIC, C och Pascal. Logo är mest känt för att vara lättlärt och för dess sätt att behandla grafik. Programspråket är lämpligt att användas av nästan alla kategorier av användare, inklusive barn. Dess motto är: ”no floor, no ceiling” (Smith & Smith, 2001). Under de senaste tre decennierna har man utvecklat olika programmeringsmiljöer (versioner) av Logo. Dessa miljöer har sin utgångspunkt i konstruktivismens utbildningsfilosofi och är designade att stödja konstruktivist inlärning. Konstruktivism ser på kunskaper som en produkt (konstruktion) skapad av studenterna i sina egna medvetanden. Detta sker genom interaktion med andra människor och det värld som omger dem (Logo Foundation, 2000). Logo har dessutom en annan och unik egenskap som inte finns i många andra programmeringsspråk, nämligen den s.k. ”Turtle Graphics”. Det är en enkel och kraftfull samling av kommandon för att manövrera en sköldpadda. Tanken var att just använda denna applikation som en inkörsport till programmering. Logo utvecklades i systemanpassade versioner för både Mac (MacLogo) och PC miljöer. MSWLogo (Microsoft Windows Logo) är den version som är anpassad för Windows. MSWLogo inkluderar multimedia och andra finesser som är anpassade för Windows miljö.

18

Fig.1. Ett MSWLogo fönster

Den första versionen av Logo använde sig av en elektronisk robot som liknade en sköldpadda. I det här fallet som rör sig om en datorskärm, är det helt enkelt en kursor som visar var sköldpaddan befinner sig. Sköldpaddan kan i huvudsak dra linjer på datorskärmen. Det som utmärker Turtle Graphics, i jämförelse med traditionella programmeringsspråk, är att den ger en direkt feedback som gör programmeringen både roligare och lättare att lära sig. Nybörjare kan använda Logo, utan att ens behöva programmera, genom att bara lära sig hur man manövrerar sköldpaddan och därigenom bemästra Turtle Graphics.

Sköldpaddan kan beskrivas som en liten robot som kan förflytta sig framåt eller bakåt samt svänga i ett valt antal grader åt höger eller vänster. En penna som är kopplad till sköldpaddans svans kan via kommandon, PU eller PD (penup/pendown), lyftas upp eller sänkas ner. Om pennan är nere lämnar sköldpaddan ett spår medan den förflyttar sig och på så sätt kan den kommenderas att rita olika geometriska figurer. En fyrkant exempelvis, kan ritas med följande kommandon:

forward 50left 90forward 50left 90forward 50left 90forward 50left 90

19

Ett annat mycket användbart kommando är PE (penerase) som upp och ner vänder på pennan så att sköldpaddan kan sudda bort eventuella spår som den tidigare hade lämnat. Logo är modellerat efter det kraftfulla programmeringsspråket LISP och är designat att fungera som ett verktyg för inlärning. Logo uppmuntrar studenterna till ett kreativt tänkande, utforskning och inlärning. Logo Foundation (2000) beskriver Logos främsta egenskaper som interaktivitet, moduläritet, utvecklingsbarhet och flexibilitet.

Interaktivitet

Logo är allmänt implementerat som ett interpreterat programspråk. Interaktiviteten i det här fallet möjliggör för användaren en direkt feedback på enstaka instruktioner, vilket underlättar avlusning och inlärningsprocessen.

Moduläritet och utvecklingsbarhet

Logo program består allmänt av en samling av små procedurer. Procedurer definieras i en texteditor genom att först skriva det speciella ordet to som följs med procedurnamnet. Proceduren avslutas med det specifika ordet end. En procedur som ritar en fyrkant kan definieras med följande:

to squarerepeat 4 [forward 50 right 90]end

Den andra instruktionen i proceduren square medför att sköldpaddan först förflyttar sig 50 steg framåt och sen roterar 50 grader mot höger. Hela operationen upprepas 4 gånger. Proceduren square kan också användas som en del av en annan procedur:

to flowerrepeat 36 [right 10 square]end

Den andra instruktionen i proceduren flower medför att sköldpaddan först roterar 10 grader mot höger och sen ritar en fyrkant. Hela operationen upprepas 36 gånger. När en procedur en gång definieras, då fungerar den som en del av Logo. Programmering i Logo är gjord genom nya tillägg till dess vokabulär, dvs. definitioner av nya ord i termer av andra ord som redan är definierade i programspråket. Detta möjliggör för studenten att bygga komplicerade projekt i små och enkla steg.

Flexibilitet

Logo arbetar med ord och listor. Ett Logo ord är en sträng av tecken. En lista är en ordnad sekvens av ord eller listor. Tal är ord, men de är speciella därför att

20

man kan utföra saker som aritmetik med dem. I Logo kan man, till skillnad från andra programmeringsspråk, utföra beräkningar på olika tal utan att behöva specificera deras typer. Den följande sekvensen innehåller exempel på operarationer som är gällande i alla versioner av Logo:

print 3 + 47

print 3 / 4.75

print word ”apple ”sauceapplesauce

print word ”3 “434

print 12 + word ” 3 “446

Resultaten (output) av de olika operationerna i exemplen ovan är markerade med fetstil.

En del Logoimplementationer (versioner) utvecklades med nya kraftfulla och specifika egenskaper. MicroWorlds Logo exempelvis, har egenskapen att parallellt behandla olika uppgifter och på så sätt kan flera oberoende processer exekveras samtidigt. Applikationer för Control lab, en LEGO/Logo produkt, har också förmågan att parallellt behandla flera processer. Ett ännu mer utpräglat parallell Logo är StarLogo.

4.2. StarLogo

StarLogo är en specialiserad version av programmeringsspråket Logo. StarLogo utvecklades av Mitchel Resnick på MIT media lab. Programspråket designades för att möjliggöra för människor att bygga egna modeller av decentraliserade, komplexa och dynamiska system. Med detta menas, system där uppstår mönster från interaktioner mellan flera individuella objekt (MIT Media Laboratory, 2002). I decentraliserade system, exempelvis fågelflockar och myrkolonier, kan väl organiserade mönster uppstå utan någon centraliserad kontroll. Med StarLogo kan man skapa modeller av många viktiga fenomen som är bekanta men traditionellt är svåra att förstå.

Med traditionella versioner av Logo kan man skapa ritningar och animeringar genom att ge kommandon till grafiska sköldpaddor på datorskärmen. StarLogo vidare utvecklar samma idé genom att parallellt möjliggöra kontroll av tusentals grafiska sköldpaddor. StarLogo gör dessutom sköldpaddornas värld beräkningsmässigt aktiv, dvs. man kan skriva program för tusentals av rutor (patches) som utgör sköldpaddornas miljö. Sköldpaddor och rutor kan interagera med varandra i den aktuella världen. Man kan

21

exempelvis programmera sköldpaddorna att sniffa runt omkring i världen och därefter ändra sina beteenden beroende på vad dom anar finns i rutorna under dem.

StarLogo fungerar utmärkt som ett effektivt verktyg för konstruktion av Mikrovärldar. Med Starlogo kan studenten befolka en värld med ett stort antal fristående ”varelser” (objekt). Vart och ett av dessa ges ett antal enkla regler att följa och sen släps dom fria för att interagera med varandra. Deras interaktion resulterar i komplexa och fascinerande beteenden. StarLogo är specifikt vällämpat för artificiella livsprojekt. Det finns också en Java version av StarLogo. MIT Media Laboratory (2002) uppräknar tre specifika enheter som är grundläggande för programspråket. Dessa enheter beskrivs nedan:

1. Sköldpaddor: De mest vanliga invånarna i en StarLogovärld är grafiska varelser kända som ”turtles”. Man kan använda en sköldpadda för att nästan representera alla typer av objekt som en myra i en myrkoloni, en fågel i en fågelflock eller en molekyl i en gas. Varje Sköldpadda har en position, en riktning, en färg, samt en penna för ritning. Man kan dessutom lägga till nya mer specifika egenskaper.

2. Fragment (patches): Är bitar av den värld som sköldpaddorna lever i (miljön). Fragmentena är inte bara passiva objekt som Sköldpaddorna agerar över. De kan, som sköldpaddorna, exekvera StarLogo kommandon och dessutom agera på sköldpaddor och fragment. De är arrangerade i ett fragmentsystem (grid) där varje fragment svarar mot en ruta i det grafiska området.

3. Observer: (de globala procedurerna och variablerna). Observern ”tittar nere” på sköldpaddorna och fragmentena från ett fågelperspektiv. Observern kan skapa nya sköldpaddor och dessutom bevaka aktiviteterna av de existerande sköldpaddorna och fragmenten.

4.2.1. StarLogosgränssnitt Gränssnittet består av flera huvudfönster. StarLogofönstret som visas nedan, är delat i flera sektioner. Det initiala svarta grafiska området är utrymmet där sköldpaddor rör sig och ritar. Sköldpaddorna förflyttar sig ovanpå en struktur av fragment (grid). Man kan direkt flytta på en sköldpadda genom att bara släpa den med datormusen. Det vita område som ligger till vänster om det grafiska området är gränssnittsområdet där man kan skapa knappar, sliders och monitorer för en direkt interaktionen med StarLogo program.

22

Fig. 2. Ett StarLogofönster

Kontrollfönster (Control Center window): Ett fönster som består av två områden: ett kommandoområde där man kan skriva olika kommandon för StarLogo, och ett procedurområde där man kan skriva egna StarLogoprocedurer. I kommandoområdet kan man på nytt exekvera ett kommando genom att flytta markören till den linje och sen trycka på return. Genom att växla mellan ”Turtle” och ”Observer” kan man utskilja mellan de kommandon som är specifika för sköldpaddor, och dessa som bara kan exekveras av Observern. Via menyraden som visas överst på kontrollfönstret kan man komma åt flera andra fönster, bl.a. outputfönstret som används för utskrift och inspelning av data som genereras av ett visst StarLogoprojekt.

23

Fig.3. The Turtle Command Center Fig. 4. Observer Command Center

Monitorer (Turtle monitors): Om man dubbelklickar på en sköldpadda på det grafiska området, framträder en Turtle monitor som visar sköldpaddans variabler, båda standard och användardefinierade, och deras värden. Värdena uppdateras i realtid samtidigt som det aktuella StarLogoprojektet exekverar. Man kan också använda monitorn för en direkt ändring av ett visst variabelvärde (tillstånd).

4.3. LEGO/Logo

LEGO/Logo är ett, datorbaserat, system som utvecklades med inspiration av MIT Professor Seymour Papert (1980) bok Mindstorms. Utgångspunkten är att barn, genom att arbeta med LEGO/Logoprojekt, kan handskas med vetenskapliga koncept och metoder i en naturlig och meningsfull kontext (Martin, 1995).

LEGO/Logo kombinerar LEGO byggmaterial och programmeringsspråket Logo. Med LEGO/Logo kan användare skapa komplexa och färgstarka grafiker. Barn börjar med att bygga maskiner utav Legobitar och sedan kan de skriva Logoprogram som kontrollerar dessa maskiner. LEGO/Logo innehåller två typer av konstruktioner: konstruktion av LEGO strukturer och konstruktion av Logoprogram. I LEGO/Logosystemet finns en gränssnittslåda som fungerar som länk mellan datorn och Legos fysiska konstruktioner. Om ett barn exempelvis, kopplar en LEGO motor till gränssnittslådan, då kan barnet

24

skriva kommandon som medför att motorn startar, stängs av eller ändrar riktning. På samma sätt kan barn få läsningar från LEGO sensorer, båda berörings- och ljudsensorer, som är kopplade till gränssnittslådan.

LEGO/Logo använder sig, på samma sätt som dess programmeringsspråk, av en utökad version av Logo. Martin (1995) tillägger att studenter kan använda någon av det traditionella Logos nyckelorden som if och repeat, plus alla de nya nyckelorden som speciellt infördes i LEGO miljön som on, off, sensor?, Etc. För att starta/stänga av en maskin, helt enkelt, kan barnen skriva on och off. Man kan använda dessa enkla kommandon för att vidare bygga mer komplexa instruktioner. Exempelvis:

waituntil [sensor?] onfor 30

Instruktionen medför att systemet väntar tills en sensor är nedtryckt och sen startar en motor för 30 sekunder.

4.4. Microworlds LOGO

Microworlds Logo är den mest intressanta versionen av Logo. Programspråket utvecklades av LCSI (Logo Computer Systems Inc.) och först släptes år 1993. Elliot (1998) konstaterar att Microworlds Logo medförde stora ändringar i både språket och arbetsmiljön av Logo. Dessa ändringar möjliggjorde för Logo att verkligen bli multimedia. Intressanta finesser som musik, ljud, video och ritning kan nu införlivas i en multi-turtle miljö.

Microworlds Logo är designat att engagera studenter i problemlösningssituationer. På samma sätt som ett naturligt språk, har Microworlds en vokabulär och regler för användning av denna vokabulär. Alla inbyggda ord i Microworlds kallas för ”Procedurer”. En instruktion, i programspråket Logo, är namnet på en procedur som följs med den input som proceduren kräver, eller en lista av procedurer där varje procedur följs av tillhörande input. En instruktion kan inte börja med en procedur som har en input, därför att denna input inte har någonstans att användas.

25

Fig. 5. Ett Microworlds LOGO fönster

För att kunna börja skriva måste man först klicka på menysektionen ”pages” och sen välja procedurer, då visas en blank sida där så mycket som möjligt av koden skall tillhöras. Man kan införa nya ord i Microworlds genom att skriva procedurer. Programmeringsgrunden utgörs av tillägg av nya procedurer, samt nya egenskapar till de redan existerade procedurerna i programspråket. Man kan exempelvis infodra ett nytt ord som kallas för kvadrat (Square). När man sen vill att sköldpaddan skall förflytta sig i ett mönster som formar en kvadrat, då räcker det med att, i kommandocentret, bara skriva det nya ordet (Square). Koden skrivs på den sida som är avsedd för procedurers.

to Square forward 50 right 90

forward 50 right 90 forward 50 right 90 forward 50 right 90end

Denna procedur lägger till ett nytt ord, kvadrat (Square), till Microworlds vokabulär. Det nya ordet kan senare användas i andra procedurer.

26

Kommandocentret är en bra plats för att testa enstaka instruktioner och procedurer, men det är inte lämpligt för skrivandet av program. För att bättre kunna skriva ett program, först behöver man skapa en ”programmerbar” knapp på huvudfönstret. Detta kan enkelt göras genom att välja från verktygslådan som finns på huvudfönstret och sen bara följa instruktionerna. Knappen får automatisk en beteckning (label). Användaren kan sen ändra beteckningen på knappen och istället skriva namnet på applikationen som skall exekveras när någon trycker på knappen, exempelvis start. Knappen placeras sen på en lämplig plats på huvudfönstret. För att börja skriva applikationen går man tillbaka (Ctrl-F) till procedursidan. Där kan man skriva en start procedur för att lägga till det nya ordet (start) till Microworlds vokabulär.

En bra programmeringsteknik underlättar för studenten att hantera komplexiteten i stora program. I det här fallet är det smidigare att låta programexekveringen, som t.ex. i C++, börja med en procedur kallad för main. Den aktuella start proceduren skall fortsättningsvis kunna anropa main proceduren för exekvering. Den följande koden är ett exempel på ett enkelt program i Microworlds:

to Start Main

end

to Main cc talkto "t1 repeat 20 [Square]

end

Den första instruktionen i main rensar kommandocentret så att man i fortsättningen vet att de eventuella felmeddelanden som kan finnas där, är nya. Den andra instruktionen informerar Microworlds om vilken sköldpadda som skall utföra handlingarna i de följande instruktionerna. Denna instruktion är onödigt i de fall där det bara finns en sköldpadda. Square är det nya ordet (procedur) som tidigare definierats och är nu en del av Microworlds vokabulär. Elliot (1998) listar upp ett antal grundläggande kommandon som anses tillräckliga för att man skall kunna skriva program i Microworlds Logo. Dessa kommandon visas i fölande tabellen:

27

Tabell 1. Grundläggande Microworlds LOGO kommandon

Det finns också en hel del kommersiella multimedia mjukvaruprogram som kallas för Microworlds(TM). Programmen tillåter ett stort antal sköldpaddor som kan programmeras för individuella handlingar, och dessutom innehåller programmen ett antal olika verktyg, bl.a. ljudinspelningar. Programmen riktar sig framförallt till barn. Dessa program möjliggör för dem att på ett enkelt sätt skapa egna kraftfulla projekt.

4.5. Buggles

Buggles är en mikrovärld som används för inlärning av Java och objektorienterad programmering (Stephan & Downey, 2001). Buggles är Javaobjekt som lever i en Buggelvärld som är ett annat Javaobjekt. De är representerade på skärmen som icoscoles trianglar; Buggelvärld är representerad som en tvådimensionell plan indelad i små rutor. Buggles kan förflytta sig omkring i en Buggelvärld. De kan färglägga sina spår när de förflyttar sig i världen. De kan byta riktning och dessutom släppa ifrån sig och äta upp

Command Action FD (Moves forward) Flyttar Sköldpaddan ett valt antal steg framåt.

Ex. FD 30bk (Moves backward) Flyttar Sköldpaddan ett valt antal steg bakåt.

Ex. bk 33clean (Clears graphics) Rensar grafiken utan att ändra på sköldpaddans

position.cg (Clears screen) Rensar skärmen från alla konstruktioner, samt

placerar sköldpaddan mitt på skärmen.cc (Clear command cent.) Rensar kommandocentret (editor).lt (Turn left) Gör att sköldpaddan roterar ett valt antal grader mot

vänster. Ex. lt 60rt (Turn right) Gör att sköldpaddan roterar ett valt antal grader mot

höger. Ex. rt 32pd (Put down the pen) Sänker ner sköldpaddans penna så att den kan lämna

spår när den förflyttar sig. pu (Picks up the pen) Lyfter upp sköldpaddans penna så att inga spar

lämnas när sköldpaddan förflyttar sig.ht (Hide turtle) Gömmer sköldpaddan.st (Show Turtle) Visar sköldpaddan. repeat Bestämmer antalet gånger som proceduren inom

parentes skall upprepas. Ex. Repeat 4 [FD 46 rt 90]: Betecknar en variabel.

28

”saker”. Buggles och Buggelvärld är en del av ett program skrivet av Franklyn Turbak. Programmet är baserat på Turtle grafik som är en del av Logoprogrammeringsspråket.

4.5.1. Att skapa en Buggle

En Buggle kan skapas med new operatorn i följande tilldelningssatsen i Java:

Buggle becky = new Buggle();

Detta skapar ett nytt objekt med namnet becky och typen Buggle. Buggle är alltså en klass som innehåller alla Buggle objekt. Vid kompileringen av satsen kan namnet becky användas för att referera till det nya objektet. Ett exekverbart Javaprogram som inkluderar denna sats resulterar i en grafisk representation av en Buggelvärld med en röd triangel i den nedre vänstra hörnan.

Fig. 6. Buggles initiala värld

Varje Buggle i en Buggelvärld har inledningsvis detta utseende. Deras egenskaper kan ändras genom att man skickar till dem olika meddelanden (messages). De olika egenskaperna kallas för instansvariabler. Stephan & Downey (2001) definierar instansvariablerna för Buggles som position, riktning, färg och penselns läge.

Position: Bestämmer positionen av Bugglen i Bugglesvärlden. Den aktuella positionen specificeras med x,y koordinater. En ny Buggle befinner sig inledningsvis i den nedre vänstra hörnan, med koordinaterna (1,1). Koordinaterna ökar mot höger längs med x axeln och uppåt längs med y axeln. Det finns en klass, Point, för de olika positionerna. Man kan skapa ett Pointojekt som exempelvis representerar positionen (4,2) och sen använda objektet som ett argument i metoden setPosition:

29

Point p = new Point (4,2);becky.setPosition (p);

Detta medför att becky, oavsett var den befinner sig i Bugglevärlden, hoppar till positionen (4,2).

heading: Bestämmer Bugglens riktningen som alltid är en värdena NORTH, SOUTH, EAST och WEST. Buggles föds alltid i östriktning (facingEAST). De olika värdena är konstanter och ingår i en klass som kallas för Direction. Man kan skicka dem som argument till metoden setHeading:

becky.setHeading (Direction.EAST);

Color: Bestämmer Bugglens färg, samt färgen på det spår som Bugglen lämnar vid förflyttningen. Buggles föds alltid med röd färg. Det finns ett antal inbyggda färger som ingår i en klass benämnd med Color. De olika färgerna kan användas som argument i metoden setColor:

becky. SetColor (Color.blue); brushDown: Kollar om Bugglens pensel är nere, dvs. klar att användas. När värdet av denna variabel är sant, lämnar Bugglen ett färgat spår. Vid ett falskt värde lämnas inget spår. Buggles föds alltid med sina penslar nere. En annan metod är brushUp som kollar om penseln är uppe. Man kan ändra Buggles tillstånd genom att skicka den ett meddelande (message). De meddelanden som kan skickas till en Buggle innefattar forward, backward, left och right. De följande instruktionerna i tabellen förflyttar becky omkring i dess Buggelvärld:

Tabell 2. Exempel på förflyttnings instruktioner

Resultatet av dessa operationer (metoder) medför att den grafiska representationen av becky förflyttar sig och hennes instansvariabler förändras. Hennes nya position är (5,1) och hennes nya riktning är nord. Förflyttningen av becky har en sidoeffekt. Eftersom beckys pensel var nerdragen vid förflyttningen, så efterlämnade hon en rödfärgad spår efter sig. Andra Buggle metoder är brushUp, brushDown, setPosition och setHeading. Metoder som kan appliceras på Buggle finns definierade i en Buggle klass som finns i en fil som kallas för Buggle.java.

Becky.forward(); förflyttar becky ett steg framåtBecky.forward(3); förflyttar becky tre steg framåtBecky.left(); becky gör en vänstersväng

30

4.5.2. Bugglevärld

De metoder som en Bugglevärld kan exekvera definieras i en Bugglevärld klass. En av dessa metoder är constructor. En ny Bugglevärld kan skapas med följande satsen:

BuggleWorld world = new BuggleWorld (); Den enda instansmetoden som en Bugglevärld kan exekvera är run. Metoden exekverar specificerade handlingar som en Buggle utför i denna Bugglevärld. För att metoden skall göra något måste man i det här fallet utveckla (extend) den existerade BuggleWorld klassen och skapa en ny klass som exempelvis kallas MyBuggleWorld. Den nya klassen ersätter den gamla run metoden med en ny metod som gör något mer intressant. I Java kan det se ut som följande:

public class MyBuggleWorld extends BuggleWorld{ public void run() { Buggle becky = new Buggle(); becky.setPosition (new Point (4,2)); }} Den nya klassen MyBuggleWorld definierar en ny metod, run, som den kan exekvera. Metoden är en void metod som inte tar något argument. Den skapar en Buggle och vidare flyttar den till positionen (4,2).

4.5.3. Egendefinierade metoder med parametrar

Att definiera nya metoder är ett sätt att effektivisera koden. Det optimala sättet för att exempelvis en Buggle skall rita en fyrkant, är att definiera en ny metod, box, och vidare skapa en ny typ av Buggle som kan exekvera den nya metoden. En ny typ kan skapas genom att utveckla (extend) den existerande Buggleklassen:

class Box2Buggle extends Buggle { public void box (int n) { forward(n-1); left(); forward(n-1); left(); forward(n-1); left(); forward(n-1); left(); }

31

}

Den nya klassen är Box2Buggle. Ett objekt av denna klass kan göra samma saker som en vanlig Buggle och därutöver kan det exekvera box metoden. För att kunna skapa nya objekt måste man också utveckla (extend) den existerande BuggleWorld och skapa en ny, Box2World. Nya objekt kan skapas med constructorn av den nya klassen Box2Buggle, och resultatet tilldelas en variabel av typen Box2Buggle:

public class Box2World extends BuggleWorld { public void run () { Box2Buggle becky = new Box2Buggle (); becky.setPosition(new Point(4,2)); Box2Buggle bobby = new Box2Buggle(); bobby.setColor(Color.blue);

becky.box(5); bobby.box(3);

}}

Box2World klassen definierar en ny metod, run. Metoden skapar två nya objekt becky och bobby. Becky placeras i position (4,2), medan bobby behåller sin initiala position, (1,1), och istället ändrar färg till blå. becky.box(5) och bobby.box(3) är två metodanrop som medför att becky ritar en box med fem enheter på varje sida, medan bobby ritat en box med 3 enheter på varje sida. Buggle klassen innehåller flera booleska metoder som är användbara för att kolla om en viss operation är möjlig att genomföra innan den provas.

public boolean isBrushDown ()Returnerar sant om denna Buggle skall lämna spår när den förflyttar sig, annars falskt.

public boolean isOverBagel ()Returnerar sant om det finns en bagel i den ruta som Bugglen befinner sig i, annars falskt.

public boolean isFacingWall ()Returnerar sant om denna Buggle står mot en vägg av Bugglevärld, annars falskt.

Man kan skriva egna booleska metoder. Exempelvis, i Buggles finns inte någon metod som kallas isBrushUp. Man kan enkelt skriva en egen sådan genom att använda den inbyggda metoden isBrushDown tillsammans med NOT operatorn.public boolean isBrushUp () { return !isBrushDown ();}

32

4.5.4. Rekursion

Rekursion är en av de mest intressanta saker ett program kan göra. I en Bugglevärld kan rekursion ändvändas när man t.ex. vill att en Buggle skall gå framåt tills den träffar en vägg. Buggles har dessbättre en inbyggd metod, isFacingWall, som returnerar sant om Bugglen står mot en vägg. Anta att Bugglen befinner sig tre steg från en vägg, som i den följande figuren:

Lösningen börjar med att först kolla om Bugglen redan står mot en vägg. Om detta stämmer görs ingenting, annars förflyttar sig Bugglen ett steg framåt och metoden anropar sig själv och därigenom fortsätter Bugglen, ett steg i taget, framåt tills den når en vägg. Detta kan göras med följande metod:

public void goToWall () { if (isFacingWall ()) { return; } else { forward (); goToWall (); }}

4.6. MOOSE Crossing

MOOSE Crossing är en textbaserad virtuellvärld värld i vilken barn mellan 8 och 13 år, från varandra lär sig kreativt skrivande och objektorienterad programmering. Det speciellt designade programmeringsspråket MOOSE och miljön (WinMOOSE och MacMOOSE) underlättar för unga studenter att lära sig programmera. Deltagare använder inte bara den virtuella värden, utan också konstruerar den i samarbete med varandra. Barn kan skapa olika typer av objekt som kan ingå i egna fantasivärldar. De kan bygga virtuella rum och städer. Barn kan träffas och interagera med andra barn från hela världen. Bruckman (1997) hävdar att MOOSE Crossings värld är byggd av barn och för barn. Lärare från hela världen kan genom en Online koppling använda MOOSE Crossings i lektionerna.

Designen av MOOSE Crossing bygger på utbildningsteorin av konstruktivism. Teorin hävdar att människor konstruerar sina egna kunskaper utifrån egna erfarenheter, och därför vill de speciellt lära sig väl när de bygger personliga och meningsfulla projekt (Bruckman, 1997). Studenter i MOOSE Crossing deltar i konstruktion av sina egna Project som möjliggör för dem att praktisera sin läsning, skrivandet och programmeringsfärdigheter. De kan bl.a. arbeta med individuella projekt eller tillsammans med andra i ett klassprojekt. Individuella projekt kan innehålla förslag som används av studenterna för att utveckla sina idéer och skapa objekt baserade på den

33

aktuella arbetsuppgiften. I ett klassprojekt kan varje student ansvara för skapandet av en viss del av projektet.

4.7. JkarelRobot

JkarelRobot utvecklades av Duane Buck och David J. Stucki på institutionen för matematik i Otterbein College, Vesterville OH. Det är en vidare utveckling av den ursprungliga ”Karel the Robot” miljön. Genom införandet av både nya språkegenskaper och stöd för olika typer av övningar inom Karels miljö, har man stärkt den pedagogiska effektiviteten av detta programmeringsverktyg. JkarelRobot möjliggör för läraren att presentera de fundamentala begreppen för studenterna, utan det komplexitet och den kronliga syntaxen som finns i en traditionell programmeringsmiljö (Buck & Stucki, 2002). JkarelRobot är ett undervisnings verktyg som presenterar programmeringskoncept som objekt och klasser på ett visuellt sätt som är mindre abstrakt än programmering i ett vanligt programmeringsspråk. Karel kan programmeras som en enkel robot som existerar och lever i en enkel värld. Eftersom Karel och hans värld är simulerade, kan man faktiskt se resultatet av ett program i form av olika händelser som roboten är programmerat att utföra.

Karel kan förflytta sig i fyra olika riktningar, nord, öst, syd och väst. Han kan svänga i bara 90 grader i taget, så han kan exempelvis inte stå i nordväst riktning. Karel förflyttar sig i en värld bestående av gator och avenyer. Gatorna är placerade i öst-väst riktningar och numrerade med startnumret 1, medan avenyerna är placerade i nord-syd riktningar och också numrerade med startnumret 1. Korsningarna mellan vägar och avenyer utgör hörnor. Karel kan förflytta sig från en hörna till den nästa i ett enda steg. Eftersom han bara kan svänga i en av fyra riktningar så vid en förflyttning ändrar han sin aktuella placering med bara en aveny eller en gata men inte båda.

4.7.1. Karels Värld

Innan man börjar programmera Karel måste man först definiera den värld som Karel skall befolka, dvs. placera några element i den initiala världen. En markör som normalt finns i det nedre vänstra hörnet av den initiala världen kan flyttas runt med hjälp av specifika knappar på kontrollpanelen. Man kan också flytta markören genom att peka på ett visst ställe i den aktuella världen och sen vänsterklicka på musknappen. Väggar (hinder) kan placeras norr, syd, öst och väst om markören genom användning av specifika knappar (chekboxes). En väg kan hindra Karel från att gå i den aktuella riktningen om han samtidigt står i hörnet intill vägen. En annan intressant detalj i Karels värld är beepers. En beeper är en sorts markerare som Karel bara kan höra när den är placerad i samma hörna som han befinner sig i. Karel har en säck som han kan använda för att bära beepers som han plockar upp. Han kan också ta ut beepers ur säcken och placera dem i den hörnan där han befinner sig. Man kan, via kontrollpanelen, ändra antalet beepers i en viss hörna. Detta kan göras genom att först placera markören i den aktuella hörnan och sen

34

skriva det önskade antalet i en speciellmarkerad plats på kontrollpanelen och slutligen klicka på markören (JkarelRobot, 2001).

Fig. 7. JkarelRobots huvud fönster

För att Karel ska kunna göra gör något måste han naturligtvis programmeras. Först måste man modifiera den initiala världen via de olika kontrollknaparna i kontrollpanelen. Genom att först placera markören på ett visst ställe och sen klicka på ”place at cursor” knappen, då visas Karel på samma plats över markören. Karel är representerad av en pil huvud som visar hans riktning. För att få en bättre syn på Karel bör man flytta på markören. Man kan placera Karel i en viss riktning genom att välja riktning i ”Facing” menyn på kontrollpanelen. Vidare kan man via specifika knappar på kontrollpanelen placera eventuella vägar och beepers på olika ställen.

JkarelRobot kan vara ett effektivt sätt att introducera att introducera objektorienterat programmering. Bergin (2002) betonar att en av de främsta fördelarna av karels filosofi är att den ger studenterna enkla versioner av ett stort antal verktyg som underlättar byggandet av lärorika program i ett tidigt skede av sin utbildning. JkarelRobot utgör dessutom ett inledande och viktigt steg mot ett spiral förhållningssätt i undervisningen. Studenter utvecklar därigenom förmågan att successivt fördjupa sig i olika ämnen.

35

Buck & Stucki (2001) framhåller att styrkan i JkarelRobot som ett undervisnings verktyg ligger i dess förmåga att undanröja detaljer som inte är viktiga för vad som ska undervisas och inläras. De onödiga detaljerna som undanröjs i det här fallet är variabler. De utgör en sådan abstrakt notation av tillståndet som nog ersätts med tillståndet av den värld som Karel befolkar. Detta visuella tillstånd är det som Karels program bearbetar. Detta gör tillståndet mer verkligt för studenterna än en samling av alfanumeriska värden lagrade i olika minnesutrymmen.

JkarelRobot har visat sig ett utmärkt undervisnings verktyg men den har väsentliga begränsningar. En av dessa är att den inte direkt ger stöd för kunskapens, förståelse och applikations nivåer. Detta beror framför allt på att studenterna är, av mjukvaran, direkt tvingade in i den syntetiska nivån. Dessutom behöver studenterna bara använda Karel för en ganska kort tid innan dom växer ifrån det. Man har därför utökat de primära Karels språk och miljö på två olika sätt; dels för att direkt stödja de primitiva nivåerna av kognitiv utveckling, och dels för att lära ut fler begrepp och ge mer stöd för aktuella undervisningsplaner. JkarelRobot är skriven i Java och därför kan virtuellt installeras i alla möjliga plattformar. Det viktigaste av allt är dess stöd för undervisning med Java, Pascal och Lisp syntax så att den virtuellt kan användas oavsett typen av plattform eller programspråk (Buck & Stucki, 2001).

4.7.2. Problem och lösningar

Under de åren som karel användes har det visat sig att en del studenter hade svårighet med att bemästra koncepten. I värsta fall fick de inte riktig grepp över meningen med den grafiska displayen som syftar till att visualisera Karel i hans värld. Displayen var för abstrakt. Ett sätt att överbrygga detta kognitiva avstånd mellan displayen och studenterna var att smidigt animera Karels rörelser så att studenterna kan se handlingarna när dom utförs och inte bara de tillstånden som uppstår före och efter av varje instruktion. Ett annat problem för studenterna var att de redan från början var tvungna att skriva ett fullständigt program i det språk som användes för att kontrollera Karel. En del studenter hade stora svårigheter med att begripa hur man utvecklar ett helt program utan att fullkomligt förstå de primitiva elementen i separation från varandra.

Lösningen på problemet blev att man inte redan från början behöver skriva ett självständigt program och istället kan man börja med att bara skriva enskilda uttryck till en översättare. På så sätt underlättas för studenterna att lära sig de olika satserna genom erfarenheter, dvs genom att mata in dem (i en interpretiv/interaktiv miljö) och direkt efter kunna se vad som händer. Mjukvaran för JkarelRobot förstärktes genom utökning med en interpretiv läge. Studenterna kan mata in en eller fler satser i ett fönster och därefter se Karel utföra dem direkt. Om det uppstår syntaxfel i en viss sats, omedelbart får studenten en feedback.

Buck & Stucki (200) betonar att den interaktiva miljön ger större och mer specifika erfarenheter genom ett antal kognitiva nivåer. På kunskapsnivån finns det de olika satserna och deras syntax. På förståelsenivån, omfattas förmågan att förutse vad den

36

aktuella satsen förorsakar Karel att göra i hans nuvarande situation. På applikationsnivån, kan studenterna applicera en viss metod för att åstadkomma en önskad effekt. På analysnivån, skulle kompileringsläget (mode) kunna användas mer effektivt. Ett bra övningssätt på analysnivån är att låta studenterna studera ett visst program, försöka lokalisera ett mindre fel som hindrar programmet från att uppfylla dess specifikation, förklara felet och sen fixa det. På den syntetiska nivån inbegrips förmågan att kunna sätta ihop separata delar för att därigenom forma en ny helhet. När studenterna väl behärskar de primitiva kognitiva nivåerna då kan man låta dom skriva ett program som uppfyller vissa bestämda specifikationer. På den högsta nivån, Evaluering, kan studenterna öva med att t.ex. jämföra mellan två alternativa implementationer som uppfyller en och samma specifikation.

4.7.3. En vidareutveckling av Karel

Karels mjukvaran utökades med ett antal nya funktionaliteter. Det första som man gjort var införandet av booleska uttryck som ett sätt att kunna uttrycka begreppen and och or. Buck & Stucki (2001) hävdar att studenterna kan, av erfarenheter från naturligt språk, i förhand tillämpa booleska uttryck på ett visst problem och sedan fortsätta till de andra kognitiva nivåerna.

För att möjliggöra stöd för fler koncept som bygger på erfarenheter med Karel, har man i de nya funktionaliteterna inkluderat möjligheten att specificera en parameter till en procedur istället för införandet av variabler. Buck & Stucki (2001) motiverade detta med att exempelvis, en parameter som är en ökänd som senare får sitt värde är mycket enklare att arbeta med än en variabel som dynamisk kan tilldelas olika värden. Studenten ser den aktuella parametern bindas till den formella parametern samtidigt som exekveringen av programmet fortgår.

Eftersom Karel redan hade positiva heltal konstanter (används i define iteration), ansågs heltals parametrar som mest användbara. För att fullt ut arbeta med heltal, har man infort de heltal funktionerna succ(i) och pred(i). Studenten kan utifrån dessa skapa heltal uttryck. Ett heltal uttryck kan användas som ett argument till den inbyggda booleska funktionen isZero(i), eller som räknaren för define iteration. I det här fallet har man inte infört något infix notation på samma sätt som man gjorde för booleska uttryck. Man ansåg att det är bättre att vänta med detta tills introducering av variabler i det åsyftade programmeringsspråk.

Buck & Stucki (2001) betonar att JKarelRobot skall i framtiden också kunna användas för inlärning av rekursion. De tre programspråk som ingår i Karel redan tillåter rekursion, och i Karels programmeringsmiljö möjliggörs stöd för en visualiserad rekursion. Rekursion medför dessutom en naturlig träning i arbete med parametrar. Ett annat sätt att utöka mjukvaran var att lägga till nya språk för att styra Karel. JKarelRobot stödjer redan syntaxen av programspråken Pascal, Java och Lisp. Detta medför ett tillfälle för studenterna att lära sig extra notationer utan att samtidigt behöva lära sig en ny utvecklingsmiljö. En bra övning som involverar flera språk är faktiskt en översättning av

37

en algoritm från ett språk till ett annat. Moduler kan utvecklas i de alla tre programspråken och anrop kan göras mellan dem. Det speciella fönstret instant Window stödjer alla tre språken och kan anropa kompilerade moduler som tillhör något av dessa språk. Typkontrollen görs i ett av två möjliga lägen (mode), antingen statiskt eller dynamiskt. För Pascal- och Javasyntax är parametriserade proceduranrop statiskt kontrollerade vid kompileringen. Lisp kompileras inte. Vid en dynamisk typkontroll är parametriserade proceduranrop i alla tre språk typkontrollerade under exekveringen (Buck & Stucki, 2001). Detta möjliggör för studenterna att lättare förstå och vidare se skillnaden mellan statisk och dynamisk typkontroll, samt dynamisk bindning.

4.7.4. Karels primitiva kommandon

Det finns fem elementära kommandon som kan ändra i Karels situation. Dessa resulterar i entydiga visuella beteenden. De fem olika kommandon är följande:

move() flyttar i gata eller en avenyturnleft() vänder Karel i riktning mot vänster1

pickbeeper() plockar upp en beeperputbeeper() placerar en beeperturnoff() stänger av Karel

Tabell.3. JkarelRobots primitiva kommandon

Karel har inbyggda funktioner som aktiveras när han, via programmet instrueras att göra något som är omöjligt att utföra. Detta kan exempelvis vara en instruering om att förflytta sig när han samtidigt är blockerad av en vägg, eller att plock upp en beeper som inte finns eller att placera en beeper när han inte har några beepers i sin beeperssäck.

Dessa fall resulterar i en error-shutoff. De enda kommandon som alltid kan utföras är turnleft() och turnoff().

4.7.5. Karels kontrollstruktur

Kontrollsatser används för att välja vad som skall göras och/eller hur många gånger att göra det. Deras uppgift är att kontrollera exekveringen av andra satser. Följande är en lista av Karels kontrollsatser:

if iterate (x) (x är antalet gånger som de följande satserna skall exekveras)if/else while

1 Tre TurnLeft() kommandon i följd ger samma resultat som en vändning mot höger. Detta gjordes för att spara pengar.

38

En kontrollsats följs alltid av en ”{” för att börja de olika satserna som skall utföras. Dessa följs av symbolen ”}”. Man använder {} oavsett hur många satser som skall utföras, även om det gäller bara en sats.

4.7.6. Villkor som Karel kan upptäcka

Som tidigare nämndes finns det inte en fördefinierad turnright() kommandon. Man kan istället använda sig av ett antal turnleft() kommandon för att positionera Karel mot höger. För att kunna göra detta, först måste man kontrollera Karels aktuella riktning som kan verifieras med en if-sats och en fördefinierad boolesk funktion som argument. Exempelvis om Karels aktuella riktning är syd, så får facingSouth() funktionen värdet sant, och satserna som finns inom {} exekveras. Annars får funktionen värdet falskt och exekveringen av satserna inom {} utelämnas. Kodexemplet nedan, beskriver en turnright() kommandon:

if (facingSouth()) { turnleft(); turnleft(); turnleft();}

Ett villkor är en funktion av Karels aktuella situation under programexekveringen. Den kan ha booleska värden, sant eller falskt. Karel har ett antal fördefinierade booleska funktioner som testar hans aktuella situation. Följande är listan på dessa funktioner:

Tabell 4. JkarelRobots booleska funktioner

De följande funktionerna kontrollerar om Karel står i någon av riktningarna: nord, syd, öst eller väst.

facingNorth() facingSouth()facingEast() facingWest() notFacingNorth()

frontIsClear() Ingen vägg på framsidanfrontIsBlocked() Det finns en vägg på framsidanleftIsClear() Ingen vägg på vänstersidanleftIsBlocked() Det finns en vägg på vänstersidanrightIsClear() Ingen vägg på högersidanrightIsBlocked() Det finns en vägg på högersidannextToABeeper() Det finns minst en beeper i samma hörna som hannotNextToABeeper() Inga beepers i den hörnan som han befinner sig ianyBeepersInBeeperBag() Kollar om han har några beepers i sin säcknoBeepersInBeeperBag() Inga beepers i säcken

39

notFacingSouth()notFacingEast()notFacingWest()

4.7.7. ”Define” Satsen

Define satsen intar en speciell plats i Karels program, just förre eller efter början av en programsats. Följande kodexemplet är ett giltigt Karel program som bl.a. innehåller en definition av en ny instruktion, turnright():

class program {

define turnright() { turnleft(); turnleft(); turnleft(); } program(){ turnright(); move(); turnright(); turnoff(); }}

Man kan definiera ett ”obegränsat” antal nya instruktioner och sen använda dem i programmet när det behövs (JkarelRobot, 2001). Den nya instruktionen kan, i fall det behövs, också innehålla kontrollsatser. En define instruktion kan också använda sig av tidigare definierade instruktioner.

4.8. Kara Kara är en inlärningsmiljö som är designad till att vara så lätt som möjligt och samtidigt åskådliggöra några viktiga programmeringskoncept. Programmeringssystemet Kara är baserat på konceptet av finite state machines och har till uppgift att styra spel robotar runtomkring på ett golv eller på datorskärmen (Hartman, Nievergelt, & Reichert, 2001). Den enkla programmeringsmiljön av Kara realiserar målet att introducera programmeringen i termer av ”finite state machines”. Användning av ”finite state machines” har dessutom en betydande och praktisk gränssnittrelaterade fördel, nämligen lättare att helt grafiskt konstruera det.

40

4.8.1. Karas värld

Kara är en programmerbart litet insekt som ensamt lever i en planvärld. I Karas värld finns det bara ett begränsat antal typer av objekt: oflyttbara trädstammar som helt ockuperar en ruta, svamp som Kara kan flytta på runt omkring, klöverblad som Kara kan lägga ner eller plocka upp, samt Kara själv. Kara som kan stå i fyra möjliga riktningar är placerad antigen på en ledig ruta eller på en ruta som är upptagen av bara ett klövblad. I tabellen nedan visas ett antal sensorer informerar Kara om dess omedelbara omgivning:

Finns det ett träd i rutan framför Kara?

Finns det ett träd i rutan till höger om Kara?

Finns det ett träd i rutan till vänster om Kara?

Finns det ett svamp framför Kara?

Finns det ett klöverblad nedanför Kara?

Tabell 5. Karas sensorer

Kara kan exekvera ett antal primitiva handlingar som visas i tabellen nedan:

Avancera med en ruta i den aktuella riktningen.

Vänd i 90 grader mot höger i den aktuella rutan.

Vänd i 90 grader mot vänster i den aktuella rutan.

Lägga ner ett klöverblad.

Plock upp ett klöverblad.

Tabell 6. Karas primitiva handlingar

Genom användning av dessa sensorer och kommandon kan ”finite state machines” för Kara specificeras i den visuella programeditorn.

41

Fig.8. Karas huvudfönster

Finite state machines lämpar sig för kontroll av processer som bara reagerar på lokala villkor. I en Kara liknande miljö, kan det visa sig att ett program som är specificerat som finite state machines ofta är mer koncis än ett program som gör samma sak och som är skrivit i ett konventionellt programmeringsspråk (Hartman et al, 2001).

4.8.2. Vidare utveckling av Kara

För att beredda stöd för ”vanlig” programmering har Karas system utvidgats med JavaKara som tillåter mer avancerade användare att programmera insekten i Java. JavaKara innehåller templates av procedurer som kan anropa de inbyggda Kara operationerna och därigenom underlätta för användaren att lära sig s.k. ”Programmering genom exempel.” Hartman et al (2001) betonar att arkitekturen av Karas mjukvarupaket är designat till att vara flexibelt och har som mål att senare skulle olika programmeringsmodeller kunna läggas till den aktuella ”finite state machines” som redan är implementerad. Därför delades den integrerade utvecklingsmiljön för Kara i två delar som är inkopplade genom ett smalt och tydligt definierade gränssnitt.

42

Fig.9. Kars Mjukvarustruktur

Kara och dess värld: Den här delen definierar de egenskaperna hos världen och de objekt som kan befolka den. Den definierar också de kommandon som Kara förstår, samt hans sensorer. Extern access till Kara kan bara göras via ett ”robot” gränssnitt som möjliggör för användaren att fråga Kara om hans kommandon och hans sensorer. Dessa kommandon kan naturligtvis exekveras och hans sensorer kan tillfrågas om deras aktuella tillstånd. Kara varken vet eller bryr sig om hur han är kontrollerad och programmerad, dvs. ingen kännedom om vad eller hur man utifrån skulle vilja göra med Kara.

Program och översättaren: Programpaketet som definierar hur Kara är programmerad, dvs. hur en viss enhet som implementerar robotens gränssnitt kan programmeras. Översättaren är ansvarig för exekverings av programmen, samt kontroll av enheten via robotens gränssnitt. Varken programmodellen eller översättaren behöver veta något om den enhet som de kontrollerar, förutom den informationen som erhållits via gränssnittet. Denna separation möjliggör konstruktionen av en hel grupp av Kara applikationer. Världens modell och programmerings modell kan ersättas med andra implementationer utan att man måste programmera den andra delen. Standardimplementationen av världens modell utgörs av själv Kara, medan impelmentationen av programmerings modell utgörs av ”finite automata”. Man utnyttjade separationen mellan de två delarna när man skapade LegoKara och JavaKara (Hartman et al, 2001).

LegoKara är en implementation av Kara som en Lego Mindstorms robot. Den skiljer sig bara en liten del från den virtuella Kara. LegoKara är programmerad genom användning av finite automata och i samma programmeringsmiljö som Kara är programmerad i. Man kan testa program i den simulerade världen av Kara och kompilera det automata till RCX (Legos micro controller) byte kod för att kunna laddas ner till roboten.

JavaKara möjliggör för användaren att programmera i Java. Detta underlättar för Kara att lösa problem som finite state machines inte är kapabel att lösa. Översättaren måste helt ersättas, och programeditorn avlägsnas. JavaKara bereder möjlighet för inlärning av Java steg för steg från grunden och uppåt i en grafisk miljö där de olika handlingarna som

Kara Integrated Development Environment

Kara, World

JavaprogramAutomata

Program,Interpreter

JavaKaraKara LegoKara

KaraIDE JavaKaraIDE IDE KaraIDE

LegoKaraIDE DE

43

programmen utför är automatiskt visualiserade. Detta underlättar för nybörjare att få ett bättre grepp om semantiken av de grundläggande elementen i programmeringen och inte bara förståelse av syntaxen.

4.8.3. Användning av Kara

Kara har använts i flera olika kurser för undervisning av programmeringsgrunder till nybörjarstudenter och andra typer av användare som har mycket begränsade erfarenheter i programmeringen. Användare med bra programmeringserfarenheter som fick testa systemet blev gladöverraskade. Man upptäckte snabbt att den konceptuellt enkla strukturen av programmering som möjliggörs vid användning av ”finite state machines”, lyfter fram de fundamentala frågorna av datavetenskapen (Hartman et al, 2001). De flesta användare upplever att Kara möjliggör för dem att fokusera på problemlösningen, samt på logiken och korrektheten av sina program, utan att distraheras av miljön eller syntaxen av ett konventionellt programmeringsspråk.

Kara är designad till att vara så enkelt som möjligt. Den erbjuder inte fler möjligheter och alternativ än det som absolut är nödvändigt. Kara är väl användbar för inlärning av de första stegen i programmering på ett lekfullt grafiskt sätt inom en tidsram av 6-12 timmar. Hartman et al (2001) hävdar att den viktigaste anledningen till att Kara är framgångsrik i att uppnå det målet är dess unika valet av beräkningsmodellen, nämligen ”finite state machines”. Denna beräkningsmodell är visserligen enkel men också har sina begränsningar. Karas programmeringsmiljö kan användas som en inkörsport till en verklig programmering som programmering i det kraftfulla programmeringsspråket Java. Kara möjliggör därigenom en smidig övergång från en spelvärld programmering till en konventionell programmering. Den bredda räckvidden av programmeringsuppgifter som Kara kan lösa när den programmeras i Java, åskådliggör de begränsningar som ”finite state machines” har, och samtidigt leder till en bättre förståelse av styrkan i de olika beräkningsmodellerna.

4.9. Alice

Alice är en interaktiv grafisk 3D-programmeringsmiljö för Windows 95/98NT bildades av den etapp 3 forsknings grupp i Carnegie Mellon universitet. Alices system är i grunden en programmeringsmiljö där man kan bygga scripter och prototyp för 3D-objektbeteende (inte 3D-modellerare). Systemet fungerar som ett effektivt animeringsverktyg för konstruktion av virtuella världar (Alice, 1999). Användare kan kontrollera objektets både utseende och beteende, och samtidigt som scriptet exekverar reagerar objekt på användarens input via mus eller tangentbord. Alice kan läsa många vanliga 3D-filformat inklusive .DXF och .OBJ. Objekt kan omvandlas till Aliceformat från .3DS format genom användning av en speciell 3D-studio ”Max plug-in”. Alice plug-in använder Java för koppling med webbrowsers och skapandet av 2D-GUI verktyg. Alices authoring tool använder inte Java, och i stället använder ett programspråk som kallas för Python. (Alice, 1999) betonar att Java har många fördelar men anses inte uppfylla de uppsatta målen för Aliceprojektet. Man ansåg att Java kan vara extra svårt för

44

den avsedda målgruppen som består av studenter i grundutbildning och andra som inte har några programmeringserfarenheter. Alice plug-in möjliggör visning av alla möjliga Alicevärldar. I Alice ingår dessutom ett stort bibliotek av inbyggda modeller.

Fig.10. Ett Alice fönster

4.9.1. Användningen av Alice

Med Alice kan man skapa egna scripter som kontrollerar rörelsen av 3D-objekt på en Windows PC. Objekt i Alice kan förflytta sig, snurra, byta färg, byta storlek, avge ljud och även kan reagera på en musklick eller tangentbords knappar. Alice kan allmänt beskrivas som ett instrument/verktyg för att prova olika idéer i en värld av interaktiv 3D-grafik. Alices har en omfattande undo (ångra) mekanism och en förmåga att snabbt och effektivt exekvera bitar av Alice script samtidigt som huvudprogrammet exekverar. (Alice, 1999) framhäver att detta uppmuntrar användaren till att fundera över frågor som vad händer om?, Samtidigt som han/hon utvecklar sina applikationer. Alice möjliggör för en grafisk visualisering av programtillståndet i en animerad liten värld. Systemet utgör därigenom ett starkt stöd för nybörjarprogrammerare att effektivt lära sig att skriva och avlusa program.

En egenskap som är karakteristiskt för Alice är visualiseringen av programtillståndet inte bara i början och slutet av exekveringen, utan också under exekveringen. Detta

45

underlättar för studenten att lättare förstå vad programmet gör, vilket avsevärt underlättar och effektiviserar studentens inlärning. Dann, Cooper & Pausch (2000) hävdar att nybörjarprogrammerare behöver inte bara lära sig om hur man designer en algoritm för att lösa ett visst problem. De behöver också lära sig om hur man översätter de olika stegen i algoritmen till specifika programmeringselement. Att kunna göra kopplingen mellan olika steg i algoritmen och mer specifika programmeringselement är, till en stor del, beroende på studentens kännedom om programmets tillstånd/miljö, samt hur tillståndet förändras när dessa element exekveras.

I motsats till traditionella, textorienterade programmeringsspråk, har en 3D virtuell värld fördelen att vissa tillstånd som exempelvis objektets position och färg. Dessa visar på ett naturligt sätt själva datan genom att studenten kan se tillståndet och dess förändring. 3D-världar är dessutom mer realistiska än deras motsvarande 2D-världar. De stimulerar samtidigt studenternas nyfikenhet i skapandet av olika varianter av redan existerade världar, samt skapandet av sina egna världar.

4.9.2. Erfarenheter av Alice

Alice används i en otalig mängd applikationer inklusive interaktiva spel, animeringar, träningssimulatorer, animerade tekniska program och VR (virtuell verklighet) miljöer som använder sig av huvudmonterade displayutrustning. Inom forskning används Alice för att undersöka och uppfinna nya 3D-interaktionstekniker för PC och VR miljöer (Alice, 1999). Genom användning av Alice undviker man onödiga ansträngningar med svåranvända och svårmodifierade 3D-mjukvarubibliotek. Alice är designad att vara tillräcklig enkel så att den kan användas av människor som inte nödvändigtvis betraktar sig som programmera. Om man någon gång har använt Hypercard eller programmerat lite grant i BASIC eller Logo, då förmodligen är man redo att skapa en Alice värld. Alice kan användas för att beskriva 3D-objekts beteende, dock inte för skapandet av 3D-objekt. Den har ett mycket stort antal färdigdesignade objekt. Man kan dessutom skapa sina egna objekt i andra modellerings verktyg och sedan importera dem till Alice för animering av deras beteenden. Man kan också hitta 3D-objekt i olika databaser på webben och på samma sätt importera dem till Alice.

Texturer som skapades för alla projekt i Alice använder sig av Amazon Paint, ett mjukvaruverktyg som tillåter artister att tillämpa handmålade texturer på 3D-modeller. Amazon Paint ger en textur och en .OBJ fil med u, v textur koordinat inkluderade. .MDL och .OBJ filer är modellformaten som beskriver 3D-geometri, medan .BMP och .GIF är imageformaten som beskriver en 2D-bild. Det finns inget sätt att direkt konvertera mellan de två formattyperna. .BMP kan tillämpas på objekt i Alice för att göra bilden till modellens textur (Alice, 1999).

46

4.9.3. Alices tillstånd och kommandon

Alice fungerar som ett bra och ganska effektivt inlärningsverktyg som kan användas av nybörjare i programmering. Detta trots att den ursprungligen inte var designad för det syftet. Dess visuella sätt att arbeta möjliggör för studenterna att direkt se hur animerade program arbetar (exekveras). En av Alices mest värdefulla fördelar är att den animerade virtuella världen utgör programmets aktuella tillstånd, dvs. programmets tillstånd är direkt och alltid synligt för användaren. Alice har inga variabler som sådant. Programmets tillstånd består av de olika objekt som befolkar en virtuell värld, samt information om dessa objekt som objektets position, dess orientering i världen, dess färg, delar, storlek och barnobjekt. Själva objektet innehåller all information som allmänt behövs om dess tillstånd. När programmeraren utför en förflyttningsmetod på ett visst objekt, så direkt ser han/hon objektets rörelse inom den virtuella världen.

Alice har flera inbyggda kommandon som kan ändra tillståndet hos ett visst objekt. Kommandon kan allmänt delas i två kategorier: de som instruerar ett objekt att utföra en rörelse, och de som ändrar objektets fysiska utseende. Rörelsekommandon inkluderar förflyttningen av objekt inom världen (t.ex. Move, Turn, Roll och PointAt). Kommandon som ändrar objektens fysiska utseende inkluderar destruktion av objekt (t.ex. Destroy), skapandet av dynamiska objekt (t.ex. AddObjekt), storleksändring på objekt (t.ex. Resize), samt att dölja eller synliggöra objekt (t.ex. Hide och Show). För att illustrera vissa detaljer beskrivs två av Alices aktionskommandon:

Turn: vändningen är tillåten i fyra riktningar: framåt, bakåt, höger och vänster. I ett Turn kommando behövs det bara att man specificerar/markerar det objekt som dess riktning skall ändras, den nya riktning, samt hur mycket skall den ändras.

Resize: det möjliggör en ändring av objektets storlek. Ändringen kan göras antingen på hela objektet eller bara längs med en viss dimension. Trots att det kan vara svårt att beskriva de tillståndsändringarna som resulteras av storleksändringen av objektet, så kan studenten se att objektet ändrat storlek och intuitivt veta att tillståndet måste ha ändrats.

I Alice kan man använda s.k. passiva kommandon som kan ändra tillståndet hos ett objekt. BecomeParentOf och BecomeChildOf utgör de viktigaste av dessa kommandon. Det första medför att när ett föräldrarobjekt förflyttar sig eller ändrar riktning, så också gör barnobjektet. Den enda omedelbara ändringen som kan uppstå efter utförandet av ett sådant kommando är att objektets trädhierarki också ändras.

4.9.4. Alices mekanismer

Alice har olika mekanismer för beslutsatser, repetition (inklusive rekursion), funktioner och procedurer. Procedurer är exempelvis, implementerade som namngivna instruktioner. Instruktioner i Alice är ofta grupperade i olika grupper. En grupp instruktioner kan exekvera sekventiellt (DoInOrder), synkroniserat (DoTogather) eller som en kombination av både alternativen. Namngivna instruktioner beter sig som procedurer

47

genom att de ger sidoeffekter istället för att returnera ett värde. Alice (1999) påpekar att grupperingen av instruktioner i Alice är smidigare och lättare att förstå än den något abstrakt gruppering av instruktioner i procedurer och funktioner i traditionella programmeringsspråk. Genom att exempelvis gruppera ett visst antal move och turn instruktioner som behövs för att få ett visst objekt att hoppa och sedan döpa hela sekvensen av instruktioner till Hop, då blir det klart för studenten att t.ex.

DoInOrder(Hop, Hop) medför att objektet hoppar två gånger.

Avsaknaden av variabler i Alice underlättar för studenten att istället koncentrera sig på att visualisera funktionaliteten av de olika instruktionerna i proceduren. Detta möjliggör för studenten att se om hans/hennes Hop procedur verkligen får objektet att hoppa. Alice stödjer dessutom en generaliserad rekursion genom SetAlarm kommandot. Det följande Kodexemplet illustrerar detta:

def Chase(): if Fish.DistanceTo(cat) > 2: DoInOrder( Fish.PointAt(cat),

Fish.move(Forward, 1), Alice.SetAlarm(2, do(Chase)) )

Kodexemplet kontrollerar om fisken är tillräcklig nära katten. Om inte är så fallet, då förflyttar sig fisken i riktning mot katten och samtidigt sätts larmet på så att hela processen upprepas. Varje instruktion tar en sekund (default värde) att exekvera, så i det här fallet behövs det två sekunder innan funktionen skulle rekursivt anropas. Den viktigaste aspekten när det gäller rekursion är att fördröjningen, temporärt gör rekursionen synlig. Rörelsen måste slutföras och tillståndet måste ändras innan det rekursiva anropet kan göras egen.

4.9.4. En vidareutveckling av Alice

Alice utökades med en ny version som släptes så sent som 030204. Cooper et al (2003) beskriver den nya versionen som ett försök att eliminera vissa svårigheter med objects-first-strategin genom att bl.a. reducera komplexiteten av detaljer som nybörjar programmerare måste klara av, samt genom visualisering av objekt i en meningsfull kontext. Alices gränssnitt indelades i fem olika områden:

1. Ett objektträdområde som innehåller de objekt som finns i den aktuella världen2. Ett displayområde som visar den värld som användaren konstruerar3. Ett händelseområde som innehåller en lista av händelser i den aktuella världen4. Ett område för editorn där programkod kan skrivas 5. Ett detaljområde som innehåller mer information (egenskaper, metoder och

frågor) om världen och de objekt som befolkar den

Studenten kan lätt börja programmera genom att först skapa/lägga till 3D-objekt till en virtuell värld och sen arrangera positionen för varje objekt i den aktuella världen. Varje

48

objekt inkapslar sitt eget data och har sina egna medlemsmetoder. När världen är redan initierad, kan programkoden genereras genom användning av en drag-and-drop editor. Studenten kan via musen peka och klicka på ett visst objekt och sen dra det till editorn där drop-down menyer möjliggör för studenten att välja utav primitiva metoder som sänder ett meddelande till objektet. Studenten kan också skriva egendefinierade metoder och funktioner som automatiskt adderas till de drop-down menyerna. Cooper et al (2003) betonar att Alices mekanism för generering av kod underlättar för studenten att fokusera på koncepten av objekt och inkapsling, istället för att arbeta med krångliga detaljer som parenteser, kommatecknen och semikolonen. I Alice finns det också möjlighet att programmera i en Javaliknande notation, som ett sätt att stödja en senare övergång till C++/Java syntax.

De forskare som utvecklar systemet har under ett antal år, själva varit involverade i undervisning och forskning av den nya objects-first-strategin. Informella observationer som gjordes av systemutvecklarna har visat att studenter som använde systemet har utvecklat nya och meningsfulla färdigheter (Cooper et al, 2003). En del av dessa färdigheter beskrivs nedan:

En kontextbaserad syn på objekt, klasser och objektorienterad programmering. En stegvis konstruktionsteknik. Studenter skriver inte hela programmet först, och

istället programmerar en metod i taget och detaljtesta den. Ett starkt sinne för objekt, genom den starka visualiseringsmiljön Konceptet av metoder som ett sätt att kräva ett visst objekt att göra något genom

att sända objektet ett meddelande. Ett starkt sinne för arv, när studenter skriver kod för att skapa kraftfullare klasser. Ett sinne för programtillståndet, genom den starka visualiseringsmiljön. Ett intuitivt sinne för beteenden och händelsedriven programmering.

Styrkan i systemutvecklarnas sätt att genom Alice främja objects-first-strategin, utgör också en källa för svagheter. Studenterna skriver sina program genom att dra instruktioner/uttryck från detaljfönstret in till kodfönstret (editorn) och därför utvecklar dom inte något detaljerat sinne för syntax, även när de programmerar i Javaliknande notation som är möjlig i Alice. Studenterna ges därmed inget tillfälle att genomgå vanliga syntaxfel, som klämparenteser som inte matchar eller semikolonen som saknas osv. Cooper et al (2003) hävdar emellertid att erfarenheter med studenter i övergångsstadiet från Alice till C++/Java dock har visat att studenterna snabbt bemästrar syntaxen.

4.9.5. Programspråket Python

Python är ett lättlärt, kraftfullt och interaktivt objektorienterat programmeringsspråk. Utveckling av Python började på CWI i Amsterdam under 1990. Programspråket inkorporerar moduler, undantag, dynamisk typning, mycket hög nivå dynamiska datatyper, samt klasser. Python Software Foundation (2003) bedyrar att programspråket Python kombinerar en anmärkningsvärd kraft med en mycket tydlig syntax. Det har gränssnitt för många systemanrop och bibliotek, samt för olika fönsterbaserade system.

49

Python kan lätt utökas genom tillägg av nya moduler som är implementerade i andra programmeringsspråk som C och C++. Sådana nya moduler kan definiera nya funktioner och variabler, samt nya objekt. Följande är ett exempel på en enkel funktion som inverterar en tabell (representerad som en Python ordbok):

def invert(table): index = {} # empty dictionary for key in table.keys(): value = table[key] if not index.has_key(value): index[value] = [] # empty list index[value].append(key) return index

Python har en fullständig sammansättning av strängoperationer (inklusive en regelbunden uttrycksmatchning). Det underlättar dessutom för användaren att bättre och effektivare styra minnesanvändning. Python Software Foundation (2003) konstaterar att detta tillsammans med andra egenskaper gör Python till ett idealiskt programspråk för prototyputveckling och andra ad.hoc programmeringsuppgifter.

Python har också vissa egenskaper som möjliggör skrivandet av stora program. Detta trots att programspråket saknar de flesta former av s.k. compile-time checking, dvs. ett program kan konstrueras utav ett visst antal moduler. Var och en av dessa moduler definierar sitt eget namnutrymme, och dessutom kan definiera klasser som ytterligare möjliggör inkapsling. Undantagsmöjligheten gör dessutom det möjligt att hitta fel där det krävs utan att störa resten av koden med felsökningen.

Python som är ett utbyggbart programspråk är också användbart för applikationer som behöver ett programmerbart gränssnitt. Dess översättare kan lätt utökas med nya funktioner och datatyper som är implementerade i C eller C++. Python tillåter skrivandet av mycket kompakta och läsbara program. Program som är skrivna i Python är ofta mycket kortare än motsvarande C eller C++ program. Detta möjliggörs av bl.a. följande anledningar:

1. Den höga nivån på datatyperna tillåter programmeraren att utrycka komplexa operationer i en och samma programsats.

2. Gruppering av olika satser är gjord genom indentation istället för begin/end ”{}”.

3. Det behövs inga variabel eller argument deklarationer. Pythons unika blandning av enkelhet och kraft utmärker sig i utvecklingen av en lång rad affärs- och forskningsuppgifter, inklusive konstruktionen av webbaserade applikationer, komplexa affärslösningar och stora desktoppapplikationer. Python Software Foundation

50

(2003) summerar några av de nyckelegenskaperna som kännetecknar programspråket Pythons i följande punkter:

A. Hög nivå dynamisk datatypning och mycket fördröjd bindning

B. Tätt sammankoppling med C, C++ och Java moduler

C. Support för XML och webbtjänster

D. Stöd för multimedia och GUI utveckling

E. Tillgängliga moduler för bl.a. databas access, 3D-modellering och bildbehandling

Python är dessutom ett borttabelt programmeringsspråk, dvs. kan köras i många olika typer och versioner av operativsystem som UNIX, Linux, Macintosh, PC under MS-DOS, Windows, Windows NT, samt OS/2. Det globala antalet användare av programspråkets Python uppskattas till hundratusentals och är under ständig ökning.

4.10. Darwin

Darwin är ett 2D-simuleringsprogram och programmeringsspel som skapades av Nick Parlante i Stansford universitet. Darwin består av en 2D-värld som innehåller ett antal varelser som konkurrerar om att dominera varandra i den aktuella världen. Varje varelse befolkar en ruta i Darwins värld, och står i någon av riktningarna nord, syd, öst eller väst. Varje varelse tillhör en kategori (art) som bestämmer dess beteende. Varelserna aktiverar ett program, som är skrivit i DULL, och som är specifik för deras kategori. Dessa program kontrollerar hur och när en viss varelse kan göra ett hopp, en vändning, se vad som finns framför och framförallt oskadliggöra andra varelser. Att oskadliggöra en viss varelse innebär att ändra dess kategori till den egna kategorin. Målet för varje varelse är att assimilera alla andra varelser till den aktuella kategorin (Astrachan, 1997). Spelet slutar när bara en kategori finns kvar i världen.

I Darwin finns det olika finesser som underlättar skrivandet och avlusning av DULL program. En av dessa är programdisplayen. När Darwin är fylld, är det möjligt att se vilka instruktioner som exekverades av en viss varelse genom att klicka på den och vissa dess programdisplay som är en representation av varelsens kategorifil. När en instruktion i varelsens program exekveras, då aktiveras den relaterade raden i programdisplayen. Scrollaren kontrollerar hur snabbt de olika instruktionerna utförs. Dessutom kan man använda (Un)pause knappen i samband med step knappen för att stega mellan varelsens aktiviteter. Den tid det tar mellan olika aktiviteter kontrolleras av scrollaren på den nedre kontrollpanelen. Om man vill köra flera simuleringar med samma antal och typ av kategori, då åter initierar startOver knappen varelsen och börjar världen igen.

51

4.10.1. Darwins värld

I en Darwinsvärlds simulering agerar varje varelse enligt dess kategoriprogram. Astrachan (1997) påpekar att varelserna kan, i en viss utsträckning, jämföras med robotar som lyder sina program. I en simulering får varje varelse ett tillfälle att agera. Under det tillfället exekverar varelsen en del av sitt program vari den kan se rakt framför sig och vidare ta en viss åtgärd beroende på vad som finns där. Varelser i Darwins värld kan vända sig mot höger eller vänster, samt förflytta sig framåt och oskadliggöra andra varelser. När exekveringstillfället för en aktuell varelse avslutas, ges en annan varelse ett tillfälle osv. När varje varelse hade fått tillfälle att agera, igen börjar processen och varje varelse får ett nytt tillfälle. Detta fortsätter tills det återstår bara en kategori kvar eller tills någon förbestämd tidsgräns uppnåtts.

Fig.11. Ett Darwinfönster

4.10.2. Programspråket DULL

Program för de olika kategorierna i Darwin ä skrivna i DULL, Darwin Lattice Language. Rader för DULL kod består av två saker; en kommandorad och ett numeriskt argument. Programspråket har tio olika kommandon (hop, left, right, infect, ifempty, ifwall, ifsame,

52

ifenemy, ifrandom och go). DULL är ett radorienterat språk. Instruktioner som skall exekveras måste vara specificerade med sina radnummer och kan inte ha variabel eller beteckning (label) referenser. I ett DULL program måste första raden bestå av namnet på kategorin som programmet är skrivet för. Den andra raden måste börja programmet. Kommentarer i DULL är tillåtna, så länge som de är separerade från huvudprogrammet med en tomrad. Följande är ett exempel på ett DULL program för en kategori som kallas terminate:

terminate ifenemy 12ifsame 7ifwall 7ifrandom 7hopgo 1ifrandom 10leftgo 1rightgo 1infectgo 1

Här kan eventuella kommentarer om terminate skrivas.

4.10.3. Programmering av kategorier (Species)

En varelse exekverar ett program som är specifikt för den kategori som varelsen för närvarande tillhör. Ett DULL Program för en fördefinierad kategori som kallas Flytrap visas nedan:

Flytrap Program

Step instruction comment

1 ifenemy 4 om det finns en fiende framför, gå till steg 42 left vänd mot vänster3 go 1 gå tillbaks till steg 14 infect oskadliggöra varelsen som finns framför5 go 1 gå tillbaks till steg 1

Obs! Numreringen på de olika stegen är inte en del av det egentliga programmet, och används bara för att underlätta läsningen av programmet.

53

Programmet börjar exekveringen med steg 1 och vidare fortsätter med varje steg i en sekvens. Exekveringsordning kan dock ändras beroende på if-satser.

4.10.4. Darwins programkommandon Astrachan (1997) listar upp ett antal programinstruktioner som är legala i DULL. Dessa beskrivs kortfattat nedan:

Hop: Om rutan direkt framför varelsen är tom, hoppar varelsen in i den. Om rutan innehåller en annan varelse eller om själva varelsen står mot en vägg, såg gör hop instruktionen ingenting.

Left: Varelsen vänder sig i 90 grader mot vänster för att stå i en ny riktning.

Right: Varelsen vänder sig i 90 grader mot höger för att stå i en ny riktning.

infect n: Om rutan direkt framför varelsen är upptagen av en annan varelse som tillhör en annan kategori (en fiende), så oskadliggör varelsen ”fienden”. Detta resulterar i att den (fienden) ändrar sin kategoritillhörighet och blir en del av den angripande varelsens kategori. Den angripne varelsen behåller både sin position och sin orientering, men däremot får nya och samma egenskaper som den angripande varelsen. Nästa gång den angripne varelsen förflyttar sig, exekverar den sitt nya program med början i rad n. Om inget värde av n ges, så börjar exekveringen med den första raden i programmet, dvs. kommandot infect är ekvivalent med infect 1.

ifempty n: Om rutan direkt framför varelsen är icke upptagen, då kommer den nästa instruktionen som skall exekveras att vara den dom finns i rad n. Om den aktuella rutan är upptagen eller ligger utanför världens gränser (t.ex. varelsen står mot en vägg), då fortsätter exekveringen med nästa instruktionen.

ifwall n: Om varelsen står mot en vägg så gör ett hopp till rad n, dvs. fortsätt exekverings från steg n. Annars fortsätt med nästa instruktion.

ifsame n: Om nästa rutan är upptagen med av en varelse som tillhör samma kategori så gör ett hopp till steg n, annars fortsätt med nästa instruktionen.

ifenemy n: Om nästa rutan är upptagen med av en varelse som tillhör främmande kategori så gör ett hopp till steg n, annars fortsätt med nästa instruktionen.

ifrandom n: för att möjliggöra skrivandet, är vissa varelser kapabla att tillämpa vad som kan kallas grundregler för ”fri viljan”. Denna instruktion gör ett hopp till steg n under halva tiden och fortsätter med nästa instruktion under resten av tiden.

go n: denna instruktion hoppar (oberoende av något villkor) alltid till steg n.

54

4.10.5. Att exekvera ett Darwinprogram

En varelse kan exekvera ett “obegränsat” antal if och go instruktioner under ett och samma tillfälle. Exekveringstillfället slutar endast när programmet exekverar en av de instruktionerna hop, left, right eller infect. Programmet för den aktuella kategorin lagras i en fil med suffix.spc. Exempelvis, ett program för en kategori med namnet Flytrap skulle lagras som flytrap.spc. Den första raden i en fil är namnet på kategorin, och den första bokstaven i namnet används när den visas i den grafiska Darwinsvärlden. Programmet avslutas med en tom rad eller när det inte finns några fler instruktioner. Eventuella kommentarer kan skrivas efter den tomma raden. Exempelvis, ett flytrapprogram skulle skrivas enligt följande:

Flytrap ifenemy 4 left go 1 infect go 1

Kommentar......!?

Det är möjligt att skriva program för flera olika kategorier. Darwin har fyra sticken fördefinierade kategorier:

Food: En kategori som bara kan snurra rund och har ingen möjlighet att oskadliggöra någonting. Dess enda syfte är att fungera som föda för andra varelser. Följande är ett kodexempel:

Foodhopgo 1

Food snurrar och dess enda hop att bli oskadliggjord av någon annan så att den kan återuppstå som något mer intressant. Hop: En kategori som hoppar framåt tills den når en vägg. Följande är ett kodexempel:

Hophopgå 1

Kommentar: gå till en väg och gör ingenting.

Flytrap: En varelse som kan snurra och oskadliggöra den varelse finns framför sig. Följande är ett kodexempel:

55

Flytrap ifenemy 4 left go 1 infect go 1 Rover: En varelse som ständigt går i raka linjer tills den blockeras, och samtidigt oskadliggör alla ev. fientliga varelser som den kan se. Om Rover inte kan förflytta sig framåt, då slumpvis vänder den sig mot vänster eller mot höger. Följande är ett kodexempel:

Rover ifenemy 11 ifwall 6 ifsame 6 hop go 1 ifrandom 9 left go 1 right go 1 infect go 1

4.10.6. Att köra ett Darwinprogram

För att kunna köra Darwins simulator måste man skriva Darwin med argumenten som följer programnamnet. Man kan köra programmet med olika argument enligt följande:

darwin filename number

T.ex. darwin foo.spc 5

Denna instruktion kommer att köra simulatorn med bara den kategorin som beskrivs i filen foo.spc och samtidigt slumpvis placera fem varelser i den aktuella världen. Det är också möjligt att kombinera olika kategorier som t.ex.:

darwin foo.spc 5 hop.sps 6 rover.spc 3

darwin –world m n

Detta kommandot kör simulatorn i en n X m värld, och med 15 X 15 som default värden. Kommandot kan också kombineras med andra kommandon som t.ex.:

56

darwin foo.spc 5 rover.spc 4 –world 10 10

4.10.7. Darwins användning

Darwin designades i syfte att fungera som ett modulärt undervisningsverktyg som skulle underlätta för studenterna att lära sig om arv- och designmönstrar. Astrachan (1997) specificerar tre klasser som är centrala för Darwin och som skulle kunna implementeras av studenter som programmerar i C++ eller Java. En kort beskrivning av dessa klasser är följande:

Species: En klass som innehåller all information som är relevant för en viss art som dess namn, namnet på filen vari dess program existerar, samt de olika instruktionerna i artens program. Klassen möjliggör också ett allmänt tillträde till denna information. Klassen är också ansvarig för returnering av instruktioner som svarar mot ett givit radnummer.

Creature: En klass som inkapslar de grundläggande beteenden av en varelse. Varelsens ansvar är att hålla reda på sin art, sina betraktare (andra varelser) och sin programräknare. Varelsen är också ansvarig för att börja agera i världen. Dess agerande resulterar i att varelsen ändrar sin position eller riktning eller genom metoden infect också ändra arten av en annan varelse.

World: En klass som ansvarar för positionen och riktningen av alla varelser som befolkar världen. Klassen är ansvarig för scheduling av de varelser som finns inom det. Den är också ansvarig för räkningen av de arter som är representerade inom världen.

57

5. Analyskriterier/Mål

Microworlds är en form av interaktiva system som bl.a. syftar till att underlätta undervisning och inlärning av koncept och tekniker. En viktig aspekt i detta sammanhang är att det finns en bra och fungerande interaktion mellan användaren och systemet. Detta kräver att avståndet mellan användarens mål (inlärning) och systemet överbryggas på bästa möjliga sätt. Man kan välja mellan två möjliga alternativ, antingen flytta systemet närmare användaren eller genom extra träning flytta användaren närmare systemet (Norman, 1987). I Microworlds har man valt att flytta systemet närmare användaren, dvs. genom omfattande designarbete som tar hänsyn till människans kognitiva förmågor har man utvecklat interaktiva och grafikbaserade system som ger användaren en direkt visuell feedback. Detta möjliggör för användaren att direkt se resultatet när han/hon skriver sina instruktioner, och därmed får användaren en känsla av kontroll över vad som händer, vilket är mycket viktigt och avsevärt underlättar inlärningsprocessen.

Det finns många olika typer av Microworlds som används i undervisning och inlärning på olika nivåer. Microworlds utvecklades för att bl.a. genom en direkt feedback underlätta för studenter att utforska olika alternativ och testa olika hypoteser. De Microworlds som presenteras i det här arbetet, bidrar med ett enormt stöd för undervisningen och inlärningen. En del av dessa Microworlds som MOOSE Crossing, Kara och de olika versionerna av Logo, utvecklades speciellt för att kunna användas av barn och andra personer utan förkunskaper i exempelvis matematik, teknik eller datavetenskap. Dessa Microworlds fungerar som en effektiv inkörsport till programmering. Andra Microworlds, som JKarelRobot, Alice, Darwin och Buggles, är lämpliga att användas av människor med datorerfarenheter och en viss nivå av förkunskaper, inklusive vissa förkunskaper i programmering. De utvecklades för att vitalisera, förbättra och vidare underlätta inlärning och undervisning av koncept och tekniker genom exempelvis presentationen av objektorienterade koncept som objekt, klasser och metoder i en meningsfull kontext.

5.1. Utgångspunkten för analysen

En del av dessa Microworlds skall analyseras och utvärderas med hänsyn till deras stöd för undervisning och inlärning av objektteknologin. Analysen utgår ifrån ett antal konkreta mål som skall formuleras utifrån olika material som behandlar ämnet objektorientering. Målen skall vara väl definierade och tillräckligt täckande för att fungera som grund för analys och vidare utvärdering av de olika ansatserna i form av Microworlds. Analysen förväntas omfatta alla aspekter av systemet, och därför är det lämpligt att först göra en ingående diskussion av de tänkbara målen för att belysa deras relevans för arbetet. Diskussionen utmynnar i ett antal mer specifika och konkreta mål som skall utgöra grunden för analysen.

En utvärdering av interaktiva och grafikbaserade system som Microworlds bör, förutom själva systemet också beakta gränssnittet, som är en väsentlig del av systemet. Det utgör systemets ansikte mot omvärlden, och för många (nybörjare) uppfattas gränssnittet som

58

själva systemet. Den optimala designen av gränssnittet bör utgå ifrån användarnas behov, möjligheter och begränsningar, dvs. uppfylla väl definierade mål. Ett fönsterbaserat gränssnitt betraktas ofta som enkelt att använda. Shneiderman (1998) framhåller att det som framför allt utmärker ett fönsterbaserat gränssnitt är bl.a. en kontinuerlig representation av de intressanta objekten på skärmen. Man gör saker istället av att använda sig av kommandon, och dessutom får man en snabb återkoppling när man utför olika händelser. Man kan också se hur man flyttar ett objekt och det är lätt att ångra sig vid en felbedömning av situationen.

I det här fallet är gränssnittet designat för att möjliggöra en smidig interaktion med ett interaktivt system. Systemet är avsett att fungera som ett inlärningsverktyg och därför är en fönsterbaserad design den mest lämpliga. Gränssnittet bör innehålla ett visst antal element som är väl placerade och absolut nödvändiga så att en nybörjaranvändare lättare skall få inblick i vad han/hon kan göra med systemet utan att förbryllas av onödiga konstruktioner på skärmen. Färgkontrasten bör också vara klar så att man lätt skall kunna skilja mellan exempelvis två objekt som finns i en och samma position. En mycket viktig representation i gränssnittet, är hjälpfunktionen. Studenten behöver kunna enkelt hitta den hjälp som han/hon behöver vid olika situationer.

I gränssnittet bör dessutom finnas möjligheter att visa enkla och väl förklarande exempel på hur systemet fungerar så att studenten lättare skall kunna börja skriva och vidare tuveckla egna applikationer. Ett användarvänligt gränssnitt följer vanligtvis ett visst utvecklingsmönster som möjliggör stöd för en gradvis utveckling av inlärningsprocessen. Gränssnittet bör också möjliggöra tydliga och jämförbara valmöjligheter i varje situation så att studenten, beroende på tidigare erfarenheter, kan välja det alternativ som bäst passar honom/henne.

En speciellt viktig egenskap av ett användarvänligt gränssnitt är att studenten, vid interaktion med systemet, upplever en känsla av kontroll över vad som händer när han/hon skriver sina instruktioner. Detta förutsätter bl.a. att studenten snabbt kan se om olika handlingar leder till att han/hon kommer närmare sitt mål och snabbt kan ändra sig om så inte är fallet. Det är också viktigt att studenten får en tydlig återkoppling/feedback som snabbt visar effekten av de olika handlingarna. Studenten kan/vågar därmed snabbt och effektivt utföra en stor mängd olika handlingar som medför att han/hon känner sig trygg med systemet och väl behärskar det.

Möjlighet till insyn och förståelse av systemets tillstånd är viktigt för att studenten skall kunna få en bra överblick i det som visas på datorskärmen. Detta kräver bl.a. att interaktionsmiljön skall vara enkel, dock inte händelsedriven. På så sätt undviker man att objektorienterad programmering uppfattas som en fönsterbaserad programmering. Man bör tänka på att, för en nybörjarstudent i programmering är de första stegen av inlärningen mycket viktiga. I en händelsedriven miljö kan dessa steg vara så mystiska så att de väsentligt försvårar för studenten att få en klar och genomgripande uppfattning om grunderna av objektorienterad programmering. En tydlig och kontinuerlig feedback är också viktig för att studenten snabbt skall se effekten av sina handlingar och därmed en bättre förståelse av systemet.

59

Gränssnittet bör också vara lätt att modifiera och delvis kunna anpassas efter användarens behov, dvs. det bör finnas möjligheter, utrymme och enkla mekanismer för skapandet av exempelvis nya gränssnittsobjekt.

När det gäller utvärdering av systemet är den första frågan som man bör fundera över “hur vet man att systemet är användbart”? Ett bra system skall på ett bra och tydligt sätt hjälpa till att lösa den aktuella uppgiften. Systemet skall dessutom vara effektivt och tillfredställande (Shneiderman, 1998).

Systemet är designat att fungera som ett effektivt inlärningsverktyg för att underlätta undervisning och inlärningen av olika programmeringskoncept och tekniker. Det bör därför präglas av det konstruktivistiska synsättet för undervisning och inlärning. Konstruktivism anses allmänt utgöra en modern och effektiv metod för inlärning av nya kunskaper. Detta kräver att systemet underlättar för studenten en stegvis och kontextbaserat inlärning, dvs. studenten skall lätt kunna konstruera sin egen kunskap genom att använda ny information tillsammans med den information som han/hon redan har. Systemet skall också stimulera studenten till att uppfinna gena lösningar och vidare testa olika idéer och hypoteser.

Det är viktigt att systemet stödjer olika typer av programmering så att studenten i ett och samma utvecklingsmiljö kan lära sig flera olika programmeringsspråk. Eftersom systemet förväntas fungera som ett effektivt inlärningsverktyg så bör stödet för de aktuella typerna av programmering vara djupgående. Man skall exempelvis lätt kunna introducera olika objektorienterade koncept och vidare skriva olika rent objektorienterade applikationer som alltid få stöd av systemet. Systemet skall dessutom underlätta för användaren att förstå den exakta meningen av de grundläggande objektorienterade begreppen som klass, objekt, Polymorfism, etc. Detta är nödvändigt för att studenten senare skall kunna hantera stora problem med flera klasser och objekt. Möjlighet att kunna visa/demonstrera exempel på objektorienterade program är önskvärt och väsentligt. Studenten kan därigenom skaffa sig en viss uppfattning om hur de olika begreppen samverkar i ett objektorienterat program.

Ett bra system skall vara flexibelt och därmed underlätta arbetet med intressanta och mer specifika problem, dvs. problem som fångar studentens uppmärksamhet och samtidigt betonar det som skall belysas. Systemet skall dessutom möjliggöra konstruktionen av enkla och väl förklarande exempel och därigenom underlätta konstruktioner av enkla prototyper, så att studenten kan testa och skaffa sig en bild om hur man löser stora och mer komplicerade problem.

Studenten behöver möjligheten till en förbättring av den personliga inlärningsprocessen genom självhjälp, dvs. möjlighet att exempelvis kunna ångra sig vid en felbedömning av situationen. När studenten är väl medveten om denna möjlighet så kommer han/hon att vara mer benägen att utforska systemet och lära sig mer på egen hand och därmed effektivisera sin inlärning. Studenten behöver också se en kontinuerlig och tydlig feedback för sina handlingar, så att han/hon lätt skall kunna identifiera och åtgärda

60

eventuella fel som är en viktig del i inlärningsprocessen. Möjligheten att lära sig skriva väl strukturerade program som är lätta att hantera är en viktig aspekt i inlärningsprocessen. Det är betydelsefullt för studenten att i ett tydigt skede lära sig skriva väl strukturerade program så att han/hon senare kan skriva stora och mer komplexa program som är lätta att läsa, förstå och underhålla.

Ett bra system som skall användas i inlärningssyfte bör underlätta arbetet med programspråk som har varierande typkontroll, speciellt för nybörjarstudenter. En väsentlig del i inlärningsprocessen är att mojliggöra för studenten en bra insyn i hur och när olika typer av kontroll (dynamisk, statisk) utförs, och vidare visa vilken inverkan har en viss typ av kontroll på programmet. De programspråk som exempelvis har en stark typkontroll anses underlätta förståelsen av stora program och dessutom försvårar för studenten att göra fel.

Möjligheten att Implementera olika typer av applikationer med varierande svårigheter (enkla, komplexa), är också viktig för att studenten därigenom skall bättre kunna förstå principerna av det objektorienterade paradigmet. Utan att kunna se det exekverbara programmet kan studenten inte föreställa sig hur programkoden ser ut, och dessutom får han/hon svårt att tro att programmet verkligen fungerar.

5.2. Analysmetoden

Analysen går ut på att klarlägga, hur och i vilken utsträckning de Microworlds som väljs för ingående studie, uppfyller de uppsatta målen. De aktuella Microworlds analyseras vart för sig. I analysen används GQM (Goal Question Metrics) metoden som innebär att man först sätter upp ett antal mål och sen härleder ett antal relevanta frågor från vart och ett av dessa mål. För varje fråga bestäms sen ett antal element (systemegenskaper) som skall mätas för att kunna ge ett lämpligt svar på den aktuella frågan (Fenton, 1997).

En Provning av ett visst mål görs i vårt fall i form av en kort diskussion av de olika mätelementen för att därigenom kunna besvara de olika frågorna som underställs målet, och därmed visa i vilken utsträckning analysobjektet (systemet) uppfyller det aktuella målet. En subjektiv bedömning i en skala mellan 1 och 5 där betyg 5 är högst, görs efter varje diskussion. För att lättare och samtidigt kunna få inblick i samtliga resultat används två tabeller, en för gränssnittet och en för själva systemet. När analysen av de aktuella systemen är klar, görs en jämförelse mellan dessa system för att därigenom se det som förenar dem och det som skiljer dem åt, samt deras lämplighet vid olika situationer.

5.3. De konkreta målen som utgör grunden för analysen

Ett antal konkreta mål har noga formulerats och vidare delades i två grupper där varje grupp består av de mål som relaterar till en viss aspekt av systemet. De mål som berör gränssnittet har grupperats i grupp A och kommer att betecknas med A1, A2… osv.

61

De mål som berör själva systemet har grupperats i grupp B och kommer att betecknas med B1, B2… osv. Utav vart och ett av dessa mål härleds ett antal relevanta frågeställningar. Dessa utgör de mer konkreta frågorna som måste besvaras för att visa i vilken utsträckning det aktuella systemet uppfyller målet. De punkter som följer under varje frågeställning utgör de element (systemegenskaper) som skall testas för att kunna besvara den aktuella frågeställningen och därmed visa huruvida målet uppfylls.

A: Gränssnittet

A1. Ett enkelt och användarvänligt gränssnitt - Är det ett fönsterbaserat gränssnitt?

Elementen (antal och placering) Färger Hjälpmöjligheter

- Är det möjligt att visa/demonstrera exempel? Minimalistiska exempel

- Meningsfullhet och självständighet- Innehåll av Realistiska objekt- Koppling till det verkliga systemet

- Finns det stöd för en gradvis utveckling av inlärningsprocessen? Utvecklingsmönster

- Finns det stöd för valmöjligheter i varje situation? Representation av objekt Relevanta och jämförbara alternativ

A2. En känsla av kontroll vid interaktion med systemet- Är det lätt att utforska systemet?

Undo-möjligheter- Är det lätt att identifiera och åtgärda fel?

Feedback

A3. En klar insyn i systemet - Ar det lätt för användaren att förstå vad systemet gör?

Interaktionsmiljön Feedback

A4. Ett anpassbarhet gränssnitt- Finns det möjlighet att skapa nya objekt, ändra i befintliga objekt eller

välja/ändra mellan olika inställningar? Utrymme Mekanismer

62

B: Systemet

B1. Konstruktivism som metod för undervisning och inlärning- Präglas systemet av en konstruktivistisk tänkande?

konstruktion av kunskap Kontextbaserad inlärning Möjligheter att testa relevansen i aktuella uppfattningar

B2. Ett tydligt stöd för olika typer av programmering- Objektorienterad?

Grad av objektorientering Stödet för de koncept som skall introduceras Innebörden som de grundläggande koncepten får Möjligheter att visa exempel på objektorienterade program

- Proceduell (ja/nej)?- Funktionell (ja/nej)?

B3. En lätt och smidig konstruktion av bra och intressanta exempel- Är det lätt att jobba med mer specifika problem?

Flexibilitet - Är det lätt att konstruera enkla och väl förklarande prototyper?

Minimalistiska exempel- Meningsfullhet och självständighet- Innehåll av Realistiska objekt- Koppling till det verkliga systemet

B4. Ett bra och tydligt stöd för inlärningsprocessen- Finns det möjlighet till självhjälp?

Undo-möjlighet Möjlighet att experimentera Feedback Möjlighet att lätt identifiera och åtgärda fel

- Är det lätt att lära sig skriva välstrukturerade program? Läsbarhet Förståelse

B5. En klar och tydlig typkontroll- Finns det stöd för arbete med programmeringsspråk som har olika och

varierande (stark/svag) typkontroll? Dynamisk typkontroll Statiskt typkontroll

B6. En lätt förståelse av principerna i programmeringsparadigmet - Är det möjligt att implementera applikationer med olika svårighetsgrad?

Enkla Komplexa

63

6. Analys

Microworlds har sitt ursprung i programmeringsspråket Logo som utvecklades av MIT professorn Seymour Papert i slutet av 60-talet. Programspråkets enkla sätt att behandla grafik har inspirerat andra forskare att utveckla nya interaktiva och grafikbaserade system som kallas för Microworlds. De Microworlds som redogörs för i det här arbetet representerar olika typer av system som är avsedda att stödja undervisning och inlärning av programmering på olika nivåer. Det som är mest intressant för arbetet är de Microworlds som påtagligt stödjer undervisning och inlärning av objektteknologin. Analysen begränsar sig därför till tre stycken som ansågs tillräckligt täckande för att belysa konceptet av Microworlds och dess inverkan på undervisning och inlärning. Dessa Microworlds är JKarelRobot, Kara och Alice.

6.1. JKarelRobot

6.1.1. Gränssnittet

A1: Gränssnittet är fönsterbaserat och innehåller ett visst antal element (se fig.7). De olika elementen är ganska tätt placerade i ett begränsat område i gränssnittet. Elementen är visserligen designade för att möjliggöra en lätt och smidig interaktion med systemet, men för en nybörjare kan antalet element tyckas för stort och något förvirrande. De intressanta (mest användbara) elementen har däremot en bra och kontinuerlig representation som följer med i de olika fönstren. Gränssnittet innehåller inte många färger. Det har en bra och ”typisk” backgrundsfärg. Färgerna på flyttbara och animerade objekt är väl kombinerade och avger bra kontraster som underlättar distinktionen mellan objekten, som exempelvis när två objekt är placerade på en och samma position. Hjälpknappen har onödigt två likadana representationer som följer med i de olika fönstren. Ett knapptryck på hjälpen visar hela manualen och inte något specifik avsnitt som kan förklara problemet.

Gränssnittet innehåller inte någon länk till färdigtimplementerade exempel som studenten kan visa/demonstrera. Det är emellertid lätt att konstruera enkla, meningsfulla och självständiga applikationer (minimalistiska exempel) som demonstrerar vad man kan göra med systemet. De objekt som är möjliga att använda är däremot 2D som inte tillräckligt inlämnar realistisk intryck. Exekveringen av JkarelRobots applikationer visar grafiskt objektens beteenden som hur och när ett visst objekt ändrar sitt tillstånd vilket är en viktig aspekt av Microworlds.

JkarelRobot är framförallt konstruerad efter det pedagogiska mönstret Early Bird Pattern som genomsyrar hela systemet. Detta möjliggör för studenten att i ett tydigt skede lära sig och använda viktiga objektorienterade begrepp och deras inbördes relationer utan att i förväg behöva förstå dem i detaljer och därigenom kan han/hon arbeta med lärorika och intressanta problem. Studenten får dessutom en kontinuerligt visuell feedback som underlättar förståelsen av vad som händer och därigenom kan han/hon ändra i eller vidare utveckla sina applikationer och på så sätt förbättra och gradvis utveckla sin inlärning.

64

I gränssnittets kontrollpanel (Fig.6) visas alla knapar som behövs för att en nybörjare skall kunna börja interagera med systemet. De olika knaparna saknar däremot en viktig egenskap som är karaktäristik för de allra flesta gränssnitten, nämligen inbäddade förklaringar till vad de olika knaparna gör. Med detta menas att det inte finns någon beskrivning som kan visas när man via muspekaren pekar på en viss knap.

I gränssnittet kan studenten välja mellan olika alternativ vid utförandet av en och samma händelse. Man kan exempelvis på olika sätt välja att placera/ta bort en vägg. Händelsen kan utföras antingen genom att man först placerar markören på den avsedda platsen och sen markerar/avmarkerar riktningen i kontrollpanelen, eller genom att direkt peka på den avsedda platsen och sen vänsterklicka på musknappen. Gränssnittet uppfyller målet (A1) med betyg 4.

A2: Gränssnittet saknar en gemensam Undo-möjlighet som gäller alla typer av händelser. Att ångra sig vid en felbedömning av en viss situation i det här fallet innebär ofta att man helt tar bort irrelevant data eller bara skriver över den, som exempelvis vid en fel inmatning av antalet beeper. Möjligheten till en stegvisexekvering och en visuell feedback underlättar för studenten att tydligt se effekten av sina instruktioner och därmed lättare kunna identifiera och åtgärda eventuella fel som kan uppstå. Gränssnittet uppfyller målet (A2) med betyg 3.

A3: Möjligheten till en stegvis exekvering och en visuell feedback underlättar förståelsen av de olika händelserna och samtidigt tydliggör sambandet mellan dem. Karel har exempelvis en inbyggd error-shutoff funktion som aktiveras när en viss instruktion inte kan utföras. Studenten kan i ett sådant fall direkt se orsaken till det som uppstod och samtidigt förstå sambandet mellan händelserna som förorsakade det. En error-shutoff kan exempelvis uppstå när en förflyttnings instruktion (move) skall utföras samtidigt som Karel är blockerad av en vägg. Erfarenheter från att separat kunna exekvera olika metoder möjliggör för studenten att utveckla en stark och stabil inlevelsegrund i form av egna mentala modeller om hur systemet fungerar i förhållande till både dess integrerade beståndsdelar och den aktuella händelsen/uppgiften. Gränssnittet uppfyller målet (A3) med betyg 3.

A4: Gränssnittet är inte anpassbart, dvs. det finns ingen möjlighet, enkel mekanism eller lämpligt utrymme för eventuella ändringar eller för skapandet av nya gränssnittsobjekt. Det finns också ingen möjlighet eller enkel mekanism för att välja/ändra mellan olika inställningar. Gränssnittet är enbart designat att användas efter det befintliga mönstret och utseendet som systemutvecklarna valt. Gränssnittet uppfyller målet (A4) med betyg 1.

6.1.2. Systemet

B1: JkarelRobot möjliggör bl.a. en stegviss exekvering, dvs. man kan skriva enskilda utryck till en översättare och behöver inte skriva ett färdigt program i det aktuella programspråket som används för att kontrollera Karel. På så sätt underlättas för studenten att lära sig nya instruktionerna genom erfarenheter. Detta underlättar en stegvis inlärning

65

och vidare konstruktion av kunskaper. Den 2D-animeringsmiljön möjliggör en effektiv och kontextbaserad inlärning. Studenten kan genom den starka objektvisualiseringen tydligt se objektorienterade koncept som klasser, objekt och metoder i en flexibel och meningsfull kontext. Den objektanimeringen som visas i JkarelRobot gör att studenten visuellt kan se händelseförloppet när en viss instruktion utförs, och inte bara de tillstånd som uppstår före och efter exekveringen av instruktionen. Detta underlättar för studenten att testa relevansen i sina idéer/uppfattningar om olika programmeringskoncept som klasser, objekt och deras beteenden. Systemet uppfyller målet (B1) med betyg 5.

B2: I JkarelRobot kan man arbeta med bl.a. det objektorienterade programspråket Java. Programspråket har en mycket hög grad av objektorientering. De olika objektorienterade begreppen har ett starkt stöd i programspråket och därmed i systemet som stödjer språket. Genom animeringar av objekten och en visuell feedback som systemet visar, kan studenten lätt förstå den exakta meningen av de grundläggande koncepten. Systemet har inga färdiga exempel på objektorienterade program. Det är däremot ganska enkelt att konstruera egna exempel. Systemet har dessutom stöd för två andra typer av programmering, imperativ och funktionell programmering som representeras av programspråken Pascal respektive Lisp. Systemet uppfyller målet (B2) med betyg 4.

B3: Inlärningsmönstret i JkarelRobot följer ett antal väl strukturerade kognitiva nivåer (”Blooms taxonomi”, se avsnitt 3.5) som väl effektiviserar inlärningen och vägleder studenten att skriva program som uppfyller väl bestämda specifikationer. På applikationsnivån kan man exempelvis lätt applicera en eller några få instruktioner för att åstadkomma en viss effekt som tillräckligt belyser ett visst koncept. Studenten kan därigenom lätt konstruera meningsfulla och självständiga applikationer (minimalistiska exempel), samt enkla och väl förklarande prototyper som demonstrerar vad man kan göra med systemet. JkarelRobot har dock en 2D-programmeringsmiljö och därför objekten visualiseras i 2D-form som inte tillräckligt inlämnar realistiska intryck. Systemet uppfyller målet (B3) med betyg 4.

B4: JkarelRobot har inte någon gemensam Undo-möjlighet som gäller alla typer av händelser. Varje typ av händelse har egen Undo-möjlighet som ofta innebär att man helt tar bort irrelevant data eller bara skriver över den. Detta kan obstruera inlärningen och vidare försvåra möjligheten att experimentera vilket är en viktig komponent i inlärningsprocessen. Systemet visar en tydligt visuell feedback som är lättbegripligt. Vid eventuella fel är feedbacken i form av korta meddelanden som delvis kan vara diffusa för nybörjare. Detta kan i sin tur delvis påverka möjligheten att snabbt identifiera felorsaken. Lokaliseringen av själva felet är däremot enkelt. Syntaxfel markeras automatiskt med en ljusgrön skugga, medan fel som uppstår som konsekvens av otillåtet händelse kan direkt observeras i den aktuella världen. Detta underlättar för studenten att identifiera olika typer av fel och någorlunda förstå och åtgärda dem. Program som skrivs i JkarelRobot är mycket lätt lästa. Systemet gör automatisk grafiska markeringar som bl.a. visar början och slutet av varje block av instruktioner. Detta underlättar läsbarheten och därmed förståelsen av programmet. Systemet uppfyller målet (B4) med betyg 3.

66

B5: JkarelRobot stödjer syntaxen av programspråken Pascal, Java och Lisp. Moduler kan utvecklas i alla tre språk och anrop kan göras mellan dem. Det speciella fönstret instant Window stödjer alla tre språk och kan anropa kompilerade moduler som tillhör något av dessa språk. Typkontrollen görs i ett av två möjliga lägen (mode), antingen statiskt eller dynamiskt. För Pascal- och Javasyntax är parametriserade proceduranrop statiskt kontrollerade vid kompileringen. Lisp kompileras inte. Vid en dynamisk typkontroll är parametriserade proceduranrop i alla tre språk kontrollerade under exekveringen. Detta möjliggör för studenterna att lättare förstå och vidare se skillnaden mellan statisk och dynamisk typkontroll. Systemet uppfyller målet (B5) med betyg 5.

B6: JkarelRobot stödjer olika typer av applikationer. Systemet möjliggör bl.a. en stegvis exekvering, dvs. man kan exempelvis enkelt applicera en viss instruktion och direkt se resultatet. Det finns dessutom möjligheter till en visualiserad rekursion som medför en naturlig träning i arbete med parametrar. Systemet stödjer tre olika programmeringsspråk (Pascal, Java och Lisp) som medför ett tillfälle för studenterna att lära sig extra notationer utan att samtidigt behöva lära sig en ny utvecklingsmiljö. Systemet uppfyller målet (B6) med betyg 4.

6.2. Kara


A1: Kara har ett fönsterbaserat gränssnitt (se fig.8). Gränssnittet innehåller ett antal element som är uppdelade i grupper där varje grupp omfattar de element som representerar en viss aspekt av gränssnittet. De olika grupperna är väl placerade runtom händelsecentrumet, dvs. det område där objekt och interaktion mellan objekt uppstår (Karas värld). Detta underlättar för studenten att snabbt överblicka gränssnittet och vidare konstruera en mental modell över de olika elementens uppgifter och placeringar vilket medför en snabb och effektiv interaktion med systemet. De grundläggande elementen har en kontinuerlig representation i de viktigaste fönstren. På så sätt slipper användaren gå tillbaka till huvudfönstret varje gång han/hon behöver använda något av dessa element. Gränssnitt har ett antal väl kombinerade färger. Man kan exempelvis välja mellan tre olika backgrundsfärger. Färgerna på flytbara och animerade objekt är väl kombinerade och avger bra kontraster som underlättar distinktionen mellan objekten, som exempelvis när två objekt är placerade på en och samma position. Hjälpfunktionen har bara en representation i huvudfönstret. Den är viktig och bör istället ha en kontinuerlig representation som följer med i de olika fönstren. Vid sökning av hjälp visas manualen som är indelad i tre separata avsnitt vilket underlättar för studenten att snabbt nå den hjälp som han/hon söker.

Kara är i grunden designad till att vara så enkelt som möjligt och därför erbjuder den inte fler möjligheter och alternativ än det som absolut är nödvändigt. Studenten kan lätt konstruera egna klargörande applikationer (minimalistiska exempel). I gränssnittet finns det dessutom en tidlig länk till ett antal färdigtimplementerade exempel med olika

67

lösningsalternativ. Studenten kan visa/demonstrera och även göra ändringar i dessa exempel. Exemplen är väl designade, självständiga och innehåller olika typer av objekt som någorlunda inlämnar realistiska intryck. Exemplen kan köras i både finite state machines och Java. De är lätta att förstå och dessutom konkretiserar en klar och tydlig bild av vad man kan göra med systemet.

Kara kan ses som en förenklad version av väl kända Microworlds som Logos ”turtle geometry” och JkarelRobot. Dess utveckling präglas därmed av samma pedagogiska mönster som exempelvis i JkarelRobot, dvs. Early Bird Pattern. Programmeringen i Kara introduceras först i termer av finite state machines som enkelt kan konstrueras grafiskt, och sen i termer av bl.a. det objektorienterade programspråket Java. Studenten får därigenom gradvis utveckla sin inlärning genom att först och på ett enkelt sätt lära sig programmeringsgrunder med finite state machines för att sen lätt kunna börja arbeta med ett ”verkligt” programmeringsspråk som Java.

De olika elementen i gränssnittet är väl placerade och syns tydligt. Studenten kan dessutom lätt se en beskrivning på ett visst element genom att bara peka på det aktuella elementet. I gränssnittet kan man inte välja mellan olika alternativ vid utförandet av en och samma händelse. Man kan däremot enkelt, exempelvis placera/ta bort ett visst objekt genom att peka på det aktuella objektet, dra och sen släppa på det önskade stället. Gränssnittet uppfyller målet (A1) med betyg 4.

A2: Gränssnittet saknar Undo-möjlighet. Att ångra sig vid en felbedömning av en viss situation innebär att man helt tar bort irrelevant data/objekt och sen skriva/placera nya. Detta begränsar studentens vilja/möjlighet att utforska systemet. Studenten kan däremot via gränssnittets kontrollpanel stegvis exekvera sitt program och samtidigt bestämma hastigheten i exekveringen. Studenten kan dessutom pausa eller helt stoppa exekveringen vid en viss tidpunkt. Detta underlättar för studenten att tydligt se och vidare noggrant studera feedbacken. Studenten kan därigenom lätt identifiera och åtgärda eventuella fel vilket gör att han/hon får en ökad känsla av kontroll. Gränssnittet uppfyller målet (A2) med betyg 3.

A3: Karas program kan genom finite state machines konstrueras helt grafiskt. Detta utgör en unik och praktisk egenskap som underlättar interaktionen med systemet. I Kara kan man dessutom stegvis exekvera sitt program och samtidigt bestämma hastigheten på, pausa eller helt stoppa exekveringen vid en viss tidpunkt. Detta möjliggör för studenten att lättare förstå konsekvenserna av de olika händelserna och vidare utveckla en solid mental modell om systemets olika funktioner. Studenten kan därmed lätt göra vissa uppskattningar om förväntade systemreaktioner vid olika situationer. Gränssnittet uppfyller målet (A3) med betyg 4.

A4: I Karas gränssnitt finns det ett bestämt antal objekt som inte kan ändras eller utökas med nya objekt. Gränssnittet innehåller också ett få tal typer av objekt (4 st.) med olika egenskaper, som är specifika att användas i Karas värld. Man kan inte skapa nya typer av objekt eller göra några ändringar i de befintliga objektens egenskaper. I gränssnitt kan man däremot göra egna inställningar genom att exempelvis anpassa karas värld efter en

68

önskad storlek. Man kan också steglöst förändra brännvidden på världen (zooma in/ut). I gränssnittets programmeringsdel kan man dessutom ändra/anpassa placeringen och utseendet av det grafiska programtillståndet om det så behövs. Gränssnittet uppfyller målet (A4) med betyg 3.

6.2.2. Systemet

B1: Karas programmeringsmiljö möjliggör inlärning av programmeringsgrunder i termer av finite state machines som helt kan konstrueras grafiskt. Studenten kan exekvera enskilda instruktioner och direkt se konsekvensen i form av en tydlig visuell feedback. Möjligheten till en kontrollerad och stegvis exekveringen av Karas program underlättar dessutom för studenten att empiriskt lära sig nya instruktioner och därigenom konstruera och vidare utveckla sin kunskap. Inlärningen med Kara kan också betraktas som en kontextbaserad inlärning. Den består av att studenten skall lära sig olika programmerings begrepp i en klar och tydlig kontext, nämligen att med några få sensorer och primitiva handlingar hantera ett begränsat antal typer av objekt inklusive Kara, i en enkel virtuell värld. Studenten kan dessutom lätt testa olika idéer om problemlösningen genom att formulera dem i enkla utryck som separat kan exekveras och resultera i en visuell feedback som uppvisar relevansen av dessa idéer. Systemet uppfyller målet (B1) med betyg 5.

B2: Karas mjukvara är designad för att vara flexibel. Målet är att senare skall olika programmeringsmodeller kunna införas vid sidan av de redan implementerade finite state machines. Kara stödjer för närvarande bl.a. objektorienterad programmering genom programspråket Java. De olika objektorienterade begreppen har ett starkt stöd i programspråket och därmed i systemet som stödjer språket. Möjlighet till en stegvis och kontrollerad exekvering, samt en visuell och animerad feedback underlättar för studenten att förstå den exakta meningen av de grundläggande koncepten. I systemet finns ett antal enkla och klargörande exempel som är färdigt implementerade i Java. Vart och ett av dessa exempel har olika lösningsalternativ som studenten lätt kan testköra. Systemet stödjer dessutom imperativ/proceduell programmering genom programspråket Lego. Systemet uppfyller målet (B2) med betyg 4.

B3: Kara har olika implementationer. En av dessa är ”finite state machines” som speciellt är konstruerad till att vara så enkelt som möjligt och därför erbjuder den inte fler möjligheter än det som är absolut nödvändigt. En annan är JavaKara som däremot är mer flexibel och erbjuder många fler möjligheter att arbeta med olika typer av problem. JavaKara möjliggör också en bättre förståelse av styrkan i olika beräkningsmodeller. I Kara finns det dessutom färdigtimplementerade exempel med olika lösningsalternativ. Studenten kan lätt visa/demonstrera och även göra ändringar i dessa exempel. Detta underlättar för studenten att konstruera meningsfulla och självständiga applikationer (minimalistiska exempel), samt enkla och väl förklarande prototyper som demonstrerar vad man kan göra med systemet. Kara har dock en 2D-programmeringsmiljö och därför objekten visualiseras i 2D-form som någorlunda inlämnar realistiska intryck Systemet uppfyller målet (B3) med betyg 4.

69

B4: Kara saknar tyvärr Undo-möjligheter. Detta kan delvis påverka studentens vilja/möjlighet att utforska systemet för att därigenom förbättra sin inlärning. Studenten kan ändå experimentera och testa olika alternativ tack vara det enkla och lättanvända gränssnittet. Karas grafiska miljö där de olika händelserna i ett visst program är automatiskt visualiserade, underlättar för studenten att också uppfatta semantiken och inte bara syntaxen av det aktuella programmet. Detta ökar naturligtvis studentens möjligheter att snabbt identifiera och vidare åtgärda eventuellt fel som kan uppstå i programmet. Program som skrivs i Kara är lätta att läsa och förstå, speciellt när dom konstrueras som finite state machines där man med några få sensorer och primitiva händelser helt kan grafiskt konstruera sina applikationer. I JavaKara versionen kan man också konstruera lättlästa och tydliga program tack vara den grafiska miljön där de olika händelserna som utgör ett program är automatiskt visualiserade. Detta möjliggör också en bättre förståelse av programmens semantik och inte bara syntaxen. Systemet uppfyller målet (B4) med betyg 3. B5: Kara är designad att stödja olika typer av applikationer och därmed möjliggörs olika typer av kontroll. Finite state machines är exempelvis lämpliga att kontrollera processer som bara agerar på lokala villkor. Detta gör att program som är konstruerat i finite state machines är mer koncist och lättbegripligt än samma program som är skrivet i ett konventionellt programmeringsspråk. I JavaKara applikationen görs typkontrollen statiskt av översättaren som också ansvarar för exekveringen av programmen. Systemet uppfyller målet (B5) med betyg 4.

B6: Finite state machines, visar tydligt hur olika grundläggande programmeringskoncept och algoritmer kan illustreras på ett enkelt och lekfullt sätt. Dess regler är mycket lätta att förstå. Stora och mer komplexa problem som ligger utanför finite state machines prestationsförmåga kan enkelt lösas med en kraftfullare implementation av Kara, nämligen JavaKara. JavaKara möjliggör inlärningen av objektorientering och speciellt programmeringsspråket Java steg för steg, från grunden och uppåt i en grafisk miljö, där de olika händelserna som programmet består av är automatiskt visualiserade. Systemet uppfyller målet (B6) med betyg 5.

6.3. Alice


A1: Alices gränssnitt är fönsterbaserat och indelat i fem olika områden: ett världsområde, ett objektträdsområde, ett detaljområde, ett område för editorn samt ett händelseområde (se fig.10). De olika områdena innehåller inledningsvis ett visst antal tillhörande element. Det finns också en menyrad överst på huvudfönstret där de element som inte är inkluderade i något av dessa områden finns placerade. De övriga elementen som finns i de olika områdena i gränssnittet är visserligen väl placerade, men i vissa områden är elementen för många, tättplacerade och det är delvis ganska svårt att förstå deras

70

funktioner. Elementen har nämligen inte några inbäddade förklaringar som visas när användaren med muspekaren pekar på något av dessa element.

Gränssnittet innehåller ett antal ganska väl kombinerade färger som inte verkar störande. Färgerna verkar dessutom uppmuntrande för användaren, dvs. de gör gränssnittet roligt att använda vilket är enligt Norman (1997) en väsentlig egenskap hos ett användarvänligt gränssnitt. Hjälpfunktionen innehåller tre länkar. Två av dessa utgörs av Exempelvärldar respektive Manualen. Dessa är onödigt länkade till ett och samma fönster. Manualen är bra uppdelad i tre separata delar med olika svårighetsgrader. De olika delarna beskriver ganska väl och stegvis systemets elementära funktioner genom att varje steg visas i en textruta med en pil som pekar på den aktuella funktionen. Detta görs samtidigt som resten av gränssnittet är övertäkt men ett blå filter så att det inte avleder användarens koncentration från den aktuella funktionen. En hel del andra funktioner/element som finns representerade i gränssnittet har däremot inte alls några beskrivningar i manualen och därför är dom svåra att förstå. Detta försvårar för användaren att snabbt lära sig och vidare använda de olika funktionerna, vilket negativt påverkar effektiviteten i interaktionen med systemet.

I gränssnittet finns det en tydlig länk till olika exempel på färdigkonstruerade världar som studenten kan testa/spela. Dessa exempel är väl designade, meningsfulla, självständiga och innehåller olika typer av 3D-objekt som ger ett realistiskt intryck. Exemplen konkretiserar dessutom en klar och tydlig bild av vad man kan göra med systemet. Studenten har också möjlighet att göra ändringar i dessa exempel och sen testa/spela för att direkt se resultatet som han/hon kan detaljstudera och jämföra med tidigare resultat.

Alice präglas i hög grad av de pedagogiska mönstren, Early Bird Pattern och Spiral Pattern. Systemet möjliggör därigenom en smidig introduktion och vidare användning av viktiga programmeringskoncept/begrepp och deras inbördes relationer utan att man i förväg behöva förstå dessa begrepp i detaljer. Detta ökar studentens möjlighet att effektivisera sin inlärning genom att tidigt kunna jobba med intressanta och lärorika problem även om han/hon inte helt behärskar verktygen. Studenten får dessutom en kontinuerligt visuell feedback som underlättar förståelsen av vad som händer och därigenom kan han/hon lätt ändra i eller vidare utveckla sina applikationer.

Gränssnittet är tydligt indelat i fem olika områden och ger ett bra första intryck. Det har en hel del olika element som är väsentliga för att man skall kunna börja sin interaktion med systemet. Elementen har däremot inte några inbäddade förklaringar till vad dom gör, vilket avsevärt försvårar för en nybörjare att förstå vad han/hon kan göra med systemet. Gränssnittet möjliggör flera olika alternativ för skapandet av en viss händelse. Man kan exempelvis låta en viss värld spela antingen så fort den startar, eller vänta tills användaren tryckt på något knapp på tangentbordet. Vid utförandet av en viss händelse har man i vissa fall också olika och jämförbara alternativ att välja mellan. När man exempelvis vill placera ett nytt objekt, kan man efter ett tryck på Add objekt, antingen följa resten av händelseproceduren eller bara peka på önskat objekt, dra och släppa i den aktuella världen. Ett annat fall är exempelvis när man vill markera/avmarkera ett visst objekt for kunna se eller ändra i dess detaljer. I det fallet kan man ätningen peka på

71

objektets namn i objektträdet eller direkt peka på själva objektet i den aktuella världen och sen vänsterklicka på musknappen. Gränssnittet uppfyller målet (A1) med betyg 4.

A2: Gränssnittet innehåller både Undo och Redo möjligheter som är representerade med tydliga och väl placerade knappar. Dessa möjliggör för studenten att vid en fel bedömning av en viss situation, ångra sig oändligt antal steg både bakåt och framåt. Studenten har dessutom möjlighet att tillfälligt stoppa exekveringen av en eller flera instruktioner (metoder) så att han/hon lätt kan testa och vidare se effekten av olika metodkombinationer. Detta uppmuntrar studenten att vilja/våga utforska systemet, vilket gör att han/hon får en bättre förståelse av de olika funktionerna och därmed en ökad känsla av kontroll. Exekveringen av en viss applikation ger en tidligt visuell feedback, och dessutom kan den tillfälligt stoppas (pausas) vid olika tidpunkter om så det behövs. Studenten kan därigenom lätt se effekten av enstaka instruktioner, vilket underlättar identifieringen av eventuella konstruktionsfel som sen kan åtgärdas. Vanliga felmeddelanden visas direkt på skärmen och innehåller en tydlig varningssymbol (rött/brunt) som talar om hur alvarligt felet är, samt en kort beskrivning av felorsaken med möjlighet till en mer detaljerad beskrivning om så det behövs. Gränssnittet uppfyller målet (A2) med betyg 5.

A3: Gränssnittet är tydligt och väl indelat i fem separata områden med vart sin uppgift, och därmed har också dess funktionalitet grupperats i mer specifika grupper. Detta ger tillräckligt utrymme för en stor mängd information som väl illustrerar de grundläggande representationerna (objekt, metoder, händelser). Gränssnittet möjliggör dessutom konstruktion av olika applikationer helt grafiskt, dvs. man kan konstruera sina världar utan att behöva använda någon syntax som finns i konventionella programmeringsspråk. Gränssnittet kan allmänt betraktas som informativt och fullständigt, vilket gör att det har större nytta och användbarhet hos nybörjare. Nackdelen är att det tar längre tid att visa dess innehåll. När man exempelvis upprepade gånger utför vissa händelser som att aktivera hjälpfunktionen eller växelvis titta på två olika konstruktioner (världar), då måste alla filer som berörs av den aktuella händelsen på nytt laddas ner. Detta medför att systemet blir långsammare, vilket förorsakar irritation hos erfarna användare och därmed negativt påverkar interaktionsmiljön. Konsekvenserna av olika händelser som exempelvis en uppspelning av en viss värld visas i form av en tydlig visuell feedback. Studenten kan sen detaljstudera feedbacken genom möjligheten att pausa exekveringen vid olika tidpunkter. Eventuella fel som kan uppstå visas också med tillräcklig och klargörande information på datorskärmen. Gränssnittet uppfyller målet (A3) med betyg 3.

A4: Gränssnittet innehåller ett bestämt antal grundläggande element som inte kan ändras eller utökas med nya element. Gränssnittet har också ett grafiskt bibliotek som innehåller ett stort antal olika objekt. I den virtuella världen som utgör en väsentlig del av gränssnittet, kan man däremot både ändra i befintliga objekt och samtidigt addera nya objekt. Nya objekt adderas genom att antigen direkt välja objekt från det grafiska biblioteket eller importera andra objekt från utomstående källor. I gränssnittet finns det både utrymme och enkla mekanismer som möjliggör för studenten att ändra/anpassa olika inställningar efter eget behöv. Man kan exempelvis rendera både position och storlek på det fönster som världen visas i, välja mellan två implementerings möjligheter, samt

72

ändra/anpassa kamerans position och bildformatet på den aktuella världen. Gränssnittet uppfyller målet (A4) med betyg 4.

6.3.2. Systemet

B1: Alice möjliggör en programmeringsmiljö där studenten kan använda/modifiera 3D-objekt och skriva program för att generera animationer. Genereringen av koden kan göras stegvis och helt grafiskt. Studenten behöver inte börja med att först skriva ett färdigt program, utan kan skriva en metod i taget, testa och direkt få en visuell feedback på datorskärmen. Detta möjliggör för studenten en erfarenhetsbaserad och konstruktiv inlärning, dvs. genom erfarenheter från exekveringen av fristående metoder kan han/hon lära sig skriva nya metoder och så småningom konstruera ett helt program. Den 3D-animeringen möjliggör dessutom en effektiv och kontextbaserad inlärning. Studenten kan genom den starka objektvisualiseringen tydligt se objektorienterade koncept som klasser objekt, metoder och händelser i en flexibel och meningsfull kontext. Alice kan allmänt beskrivas som ett instrument/verktyg för att prova olika idéer i en värld av interaktiva 3D-grafik. Studenten kan i Alice konstruera virtuella världar med objekt som redan har flera färdigtdefinierade och specialiserade metoder. Detta möjliggör för studenten att experimentera genom att modifiera existerande program. Studenten kan därigenom utveckla egen uppfattning om alternativa lösningar som han/hon sen kan konstruera, testa och jämföra med den ursprungliga lösningen. Systemet uppfyller målet (B1) med betyg 5.

B2: Alice har ett kraftfullt stöd för en objects-first programmeringsstrategi som starkt betonar principerna av objektorienterad programmering och design från allra första början. Systemet möjliggör dessutom en enkel och helt grafisk konstruktion av program. Studenten kan därmed fokusera på de objektorienterade koncepten som klass objekt och inkapsling, istället för uttråkande syntaxdetaljer som parenteser, kommatecken och semikolons. Den starka 3D-animeringen av objekt som systemet erbjuder inger en känsla av verklighet för objekten. Den 3D-animeringen möjliggör dessutom en kontextbaserad förståelse/inlärning och därigenom möjlighet för studenten att uppfånga den exakta meningen av de grundläggande koncepten som skall introduceras. Allting som finns i studentens virtuella värld är objekt! Studenten kan manövrera dessa objekt genom att skriva olika metoder som gör att objekten exempelvis kan förflytta sig, hoppa, flyga och interagera med varandra på ett fantasifullt och filmliknande sätt. I Alice finns det också möjligheter på att visa/demonstrera olika färdigt implementerade programexempel som studenten kan spela/testa och även göra ändringar i dessa exempel. Systemet betonar starkt objektorienterad programmering och inte har något direkt stöd for Proceduell eller funktionell programmering. Systemet uppfyller målet (B2) med betyg 4.

B3: Den 3D-objektanimeringen och visualiseringen som kan göras med Alice, möjliggör en flexibel och meningsfull kontext som hjälper studenten att tydligt se objektorienterade koncept som klass, objekt och objektorienteringen i stort. I Alice kan man dessutom grafiskt konstruera och sen testa enstaka metoder utan att behöva skriva ett färdigt program. Detta tydliggör konceptet av metoder som ett sätt kräva att ett visst objekt skall göra någonting. Studenten utvecklar därigenom ett intuitivt och starkt sinne för objekt,

73

beteenden och händelsedriven programmering. Konceptet av arv får dessutom en starkare innebörd när studenten sen lättare kan skriva väl specificerad kod för att skapa kraftfullare klasser för olika typer av problem. Alice är implementerat som ett 3D-animeringsverktyg för visualiseringen av objekt i en meningsfull kontext för att därigenom minska komplexiteten av detaljer som nybörjare i programmeringen måste klara av. Studenten kan därmed enkelt konstruera meningsfulla och självständiga applikationer genom att addera ”realistiska” 3D-objekt till en liten virtuell värld och vidare bestämma positionen för vart och ett av dessa objekt. Varje objekt inkapslar sitt eget data och har sina egna medlemsmetoder. Studenten kan sen enkelt generera en systemrelaterad programkod genom att använda en drag-and-drop smart editor där drop-down menyer möjliggör för studenten att välja ur primitiva metoder som sänder ett meddelande till objektet. Studenten kan även skriva egendefinierade metoder och funktioner som automatiskt läggs till dessa drop-down menyer. Systemet uppfyller målet (B3) med betyg 5.

B4: Alice har en klar och tydlig Undo-möjlighet som möjliggör för studenten att vid en felbedömning av en viss situation, kunna ångra sig obegränsat antal steg både framåt och bakåt. Detta har en mycket positiv inverkan på studenten möjlighet och vilja att utforska systemet och vidare experimentera med att konstruera och testa olika metoder. Alice möjliggör för en kontinuerlig och grafisk visualisering av programtillståndet i en animerad liten värld. Studenten kan dessutom se programtillståndet och hur det ändras under hela exekveringen, och inte bara i början och i slutet av exekveringen. Detta underlättar för studenten att detaljstudera feedbacken genom att antingen pausa exekveringen vid olika tidpunkter eller separat exekvera enstaka metoder. Systemet utgör därigenom ett starkt stöd för nybörjarprogrammerare att effektivt lära sig att skriva och avlusa program.

Vid eventuella fel som kan uppstå under underexekveringen, är feedbacken i form av ett felmeddelande som direkt visas på skärmen. Felmeddelandet innehåller en tydlig varningssymbol (rött/brunt) som talar om hur alvarligt felet är, samt en kort beskrivning av felorsaken med möjlighet till en mer detaljerad beskrivning om så det behövs. Möjligheten till en separat exekvering av enstaka metoder, samt en visuell feedback underlättar också för studenten att snabbt identifiera och vidare åtgärda olika typer av fel, även sådana fel som är av en semantisk karaktär och inte påverkar programexekveringen. Programstrukturen i Alice är en del av den visuella displayen. Programkoden kan genereras stegvis och helt grafiskt. Studenten kan inledningsvis skriva bara enstaka metoder som han/hon sen kan testa, se och studera konsekvensen. Därefter kan han/hon på samma sätt skriva nya metoder för att så småningom få till stånd ett färdigt och väl strukturerat program som är lätt att läsa och förstå. Systemet uppfyller målet (B4) med betyg 5.

74

B5: Alice stödjer bl.a. en C++/Java liknande syntax. Program kan dock konstrueras helt grafiskt genom att man drar olika instruktioner/uttryck till en editor. En inkrmentell typkontroll görs automatiskt av den editorn som förhindrar studenten från att dra fel typ av uttryck till exempelvis if-satser och loopar. Studenten får därmed inget tillfälle att lära sig vanliga typer av kontroll, dvs. dynamiskt, respektive statiskt typkontroll. Systemet uppfyller målet (B5) med betyg 3.

B6: Alice är implementerat som ett 3D-animeringsverktyg för att specifikt stödja en framträdande objects-first-strategi för undervisning och inlärning av programmeringen. Den starka visuella programmeringsmiljön av Alice underlättar för studenten att utveckla ett klart sinne för objekt och beteenden, som är en viktig del av de grundläggande koncepten i det objektorienterade paradigmet. Systemet möjliggör dessutom en grafisk och stegvis konstruktion av program, dvs. man kan skriva enstaka instruktioner/uttryck, testa/exekvera och sen direkt få en visuell feedback. Studenten kan därigenom enkelt konstruera ett färdigt program utan att förvirras av komplexiteten i vanlig syntax. Han/hon kan istället fokusera på koncepten av objekt och inkapsling som är väsentliga för konstruktion av objektorienterade applikationer med olika svårighetsgrader. Systemet uppfyller målet (B6) med betyg 5.

75

7. Diskussion

Microworlds utvecklades för att framför allt ge stöd för undervisning och inlärning av koncept och tekniker. Deras främsta egenskap är visualiseringen av objekt och deras beteenden i en 2D eller 3D-animeringsmiljö. De Microworlds som analyserades i det här arbetet är JkarelRobot, Kara och Alice. I jämförelsen mellan de tre systemen beskrivs de viktigaste egenskaperna som förenar dem, samt de egenskaperna som skiljer dem åt.

Alla tre har fönsterbaserade gränssnitt och är ganska enkla att använda. I två av dessa, Kara och Alice, har studenten möjlighet att visa/demonstrera färdigtimplementerade exempel på objektorienterade program, medan i JkarelRobot finns ingen sådan möjlighet. I Alice finns det omfattande Udo- möjligheter, dvs. studenten kan ångra sig obegränsat antal steg tillbaka vid en felbedömning av en viss situation. I JkarelRobot och Kara finns däremot inte tydliga sådana möjligheter. Alla tre system möjliggör en kontrollerad exekvering, dvs. studenten kan stegvis exekvera sina applikationer och samtidigt stoppa exekveringen vid olika tidpunkter om det så behövs. Systemen har ganska enkla programmeringsmiljöer. I Kara och Alice kan studenten helt grafiskt konstruera sina program, medan i JkarelRobot kan detta enkelt göras med vanlig syntax. I JkarelRobots gränssnitt kan man inte välja/ändra mellan olika inställningar, medan i Karas och Alice gränssnitten kan man göra det.

De alla tre systemen präglas av en konstruktivistisk tänkande, dvs. en kontextbaserad inlärning och konstruktion av kunskaper. Systemen stödjer en object-first strategi där fokusen ligger på visualiseringen av objekt och deras beteenden i en interaktiv animeringsmiljö. Två av dessa system, JkarelRobot och Kara, använder sig av enkla 2D-animeringsmiljöer, medan Alices använder sig av en 3D-animeringsmiljö där objektvisualisering är mycket starkare. JkarelRobot stödjer syntaxen av tre olika programmeringsspråk (Pascal, Java och Lisp), medan Kara och Alice stöder Java resp. Javaliknande syntax. Kara och Alice har dessutom, på vart sitt sätt, stöd för en grafisk generering av programkoder. Alla tre system bidrar på vart sitt sätt till effektiviseringen av inlärningsprocessen och förståelse av principerna i det objektorienterade paradigmet. I JkarelRobot kan studenten exempelvis skriva lättlästa och väl strukturerade applikationer. Systemet gör automatiskt grafiska markeringar framför koden, dvs. systemet markerar de instruktioner som hör ihop i ett block av kod med en början och ett slutet, samt markerar vart nästa instruktion skall ligga. I Kara och Alice finns inte en sådan möjlighet. Dessa erbjuder däremot ett ännu enklare sätt att generera programkod, nämligen grafiskt. I Kara kan studenten konstruera sin programkod genom finite state machines, medan i Alice kan han/hon konstruera sin programkod genom en drag-and-drop editor.

De all tre systemen är designade för att stödja undervisningen och inlärningen av koncept och tekniker i framförallt introduktionskurser i datavetenskap. Designen ser visserligen olika ut, men syftet förblir detsamma, nämligen att i varierande grad underlätta för studenter inlärningen av olika objektorienterade koncept som klasser, objekt och metoder i en 2D/3D-animeringsmiljö och en meningsfull kontext. I det sammanhänget är Alice det mest lämpligt. Dess mycket väl informativa gränssnitt och möjligheten att grafiskt generera programkod underlättar för studenten, oavsett vilken backgrund han/hon har, att

76

tydligt se och identifiera olika objektorienterade koncept. JkarelRobot är mest lämpligt för en tydig introduktion av programmeringskonceptet för nybörjarstudenter. Systemet har en väl genomtänkt pedagogik och är väl designat. Dess enkla och koncisa gränssnitt underlättar för studenten att direkt börja använda vanlig syntax och vidare skriva programkod. Kara är något mitt i mellan Alice och JkarelRobot. Dess enkla och attraktiva gränssnitt underlättar för studenten att generera samma programkod på två olika sätt, nämligen helt grafiskt eller med vanlig syntax. Detta gör att Kara fungerar bra som en effektiv inkörsport till programmeringen och är lämpligt för studenter utan allmänna förkunskaper i matte, teknik eller datavetenskap.

De följande tabellerna innehåller subjektiva bedömningar i en skala mellan 1 och 5, som visar i vilken utsträckning de olika systemen och deras gränssnitt uppfyller de uppsätta målen:

Microworlds A1 A2 A3 A4 Medel betygJkarelRobot 4 3 3 1 2.75Kara 4 3 4 3 3.5Alice 4 5 3 4 4

Tabell 7. Gränssnittets utvärderingsresultat

Microworlds B1 B2 B3 B4 B5 B6 Medel betygJkarelRobot 5 4 4 3 5 4 4.16Kara 5 4 4 3 4 5 4.16Alice 5 4 5 5 3 5 4.5

Tabell 8. Systemets utvärderingsresultat

77

8. Sammanfattning En mycket uppmärksammad strategi för undervisning och inlärning av programmering är den s.k. objects-first-strategin som väl betonar principerna för objektorienterad programmering och design i ett mycket tidigt skede i inlärningsprocessen. Denna strategi medför dock en del svårigheter i undervisning och inlärning av introduktionskurser i programmering. En objects-first-strategi kräver att studenten direkt arbetar med objekt. Detta innebär att studenten snabbt tvingas lära sig en hel del olika begrepp som klasser och objekt, deras inkapsling och metoder. Studenten är dessutom tvingad att bemästra de vanliga koncepten av typer, variabler, referenser och syntax. Det stora intresset för objects-first-strategi ledde till utvecklingen av flera olika mjukvaruverktyg i form av Microworlds, som syftar till att eliminera dessa svårigheter och därigenom främja objects-first-strategin. Dessa Microworlds fokuserar starkt på visualiseringen av objekt och deras beteenden i en förenklad 2D/3D-animeringsmiljö.

Design av spelvärldar (Microworlds) för inlärning av programmering utgör en populär och betydande ansats i detta område. I arbetet presenterades ett antal interaktiva system som ofta är lämpliga att använda såväl av människor utan programmeringserfarenheter som av erfarna programmerare. Microworlds har sin utgångspunkt i programspråket Logo som utvecklades i slutet på 60-talet. Programspråket följdes sedan av olika versioner som StarLogo, LEGO/Logo och Microworld Logo. Logo är mest känt för att vara lättläst och för sitt sätt att behandla grafik. Programspråket utgör ett effektivt verktyg för inlärning genom att det uppmuntrar studenterna till ett kreativt tänkande. Dess främsta egenskaper är interaktivitet, moduläritet, utvecklingsbarhet och flexibilitet.

En mer specialiserad version av Logo är StarLogo som utvecklades för att underlätta för studenter att konstruera egna modeller av decentraliserade, dynamiska och komplicerade system, dvs. system där det uppstår interaktioner mellan flera individuella objekt. Programspråket fungerar som ett effektivt verktyg för konstruktion av Microworlds: Studenten kan med StarLogo befolka en Microworld med ett stort antal fristående varelser (objekt). Var och en av dessa ges ett antal enkla regler att följa och sen släpps de fria för att interagera med varandra. LEGO/Logo är en annan version av Logo som utvecklades med utgångspunkten att barn kan genom att arbeta med LEGO/Logoprojekt handskas med vetenskapliga koncept och metoder i en meningsfull kontext. Den mest intressanta versionen av Logo är Microworlds Logo som är designat att engagera studenter i olika problemlösningssituationer. Programspråket medförde stora ändringar i både språket och arbetsmiljön av Logo. En del av dessa ändringar som exempelvis införandet av både ljud och video, medförde att Logo verkligen blev multimedia.

Ett av de Microworlds (system) som redogjordes för i arbetet är Buggles. Dess mjukvara är baserad på Turtle grafik som är en viktig del av programspråket Logo. Systemet utgör ett effektivt verktyg för inlärning av Java och objektorienterad programmering. Ett annat system som är speciellt anpassat för barn är MOOSE Crossing. Systemet är konstruerat i form av en textbaserad virtuell värld, där barn mellan 8 och 13 år från varandra lär sig kreativt skrivande och objektorienterad programmering.

78

Ett betydande system på detta område (Microworlds) är JKarelRobot, som är en Microworld med en robot som kan styras av användaren. JkarelRobot följdes av en ny objektorienterad version (Karel++) och flera andra system som är inspirerade av samma idé. Systemet kan programmeras i tre olika programspråk, Pascal, Java och Lisp, och utgör ett enkelt och effektivt verktyg för undervisning och inlärning av koncept och tekniker. JkarelRobot möjliggör för läraren att på ett visuellt och mindre abstrakt sätt presentera de fundamentala begreppen som objekt och klasser, utan det komplexitet och den kronliga syntaxen som finns i traditionella programspråk. Ett annat system som starkt präglas av idén bakom JkarelRobot, är Kara. Programmeringsmiljön för Kara är designad för att vara så enkelt som möjligt och samtidigt åskådliggöra viktiga koncept och tekniker. Systemet är baserat på konceptet finite state machines som har en praktisk gränssnittsrelaterad fördel, nämligen att det är lättare att helt grafiskt konstruera applikationerna. Kara har dessutom en objektorienterad version (JavaKara), som möjliggör för avancerade användare att programmera i Java.

Ett nytt system som utvecklades för att bemöta utmaningen från objects-first-strategin, utgörs av ett 3D-animeringsverktyg som kallas för Alice. Systemet avser att ta itu med vissa svårigheter som följer med objects-first-strategin, genom att reducera komplexiteten av olika detaljer som nybörjarprogrammerare måste klara av. Alice är inriktat på visualiseringen av objekt och deras beteenden i en 3D-animeringsmiljö där studenten kan använda/modifiera 3D-objekt och skriva program som genererar animering. Den 3D-animeringen medför en stark visualisering och en flexibel meningsfull kontext som hjälper studenten att tydligt se objektorienterade koncept.

Ett annat system som presenterades är ett 2D-simuleringsverktyg som kallas för Darwin, och består av en 2D-värld som innehåller ett antal varelser som konkurrerar om att dominera varandra i den aktuella världen. De olika varelserna styrs av användaren via ett specifikt program som kontrollerar deras beteenden. Programmet är skrivet i DULL - ett radorienterat programspråk. Systemet utvecklades som ett undervisningsverktyg som skulle underlätta för studenter att lära sig om arv- och designmönstrar. Darwin har tre centrala klasser (Species, Creature och World) som lätt kan implementeras av studenter som programmerar i C++ eller Java.

Avslutningsvis bör det noteras att det finns en del andra visuella programmeringsmiljöer som inte direkt är relaterade till undervisningen. De flesta av dessa miljöer erbjuder många fler alternativ och möjligheter än undervisningsverktygen som presenterades i det här arbetet. En del av dessa programmeringsmiljöer är inte uttryckligen designade för att användas i introduktionskurser i programmering.

9. Tack

Jag vill tacka min handledare på Datavetenskapliga institutionen, Jürgen Börstler, PhD, för en lärorik och genuin handledning, samt för hjälp med att ta fram intressanta artiklar och annat material som är väsentliga för arbetet. Den hjälpen har varit ovärderlig då jag jobbat ensam.

79

REFERENSER

Andersen, E. (1991). Systemutveckling – Principer, Metoder och Tekniker. Lund: Studentlitteratur.

Angster, E. (2000): Simple and Complete Patterns Step by Step. URL: http://www-lifia.info.unlp.edu.ar/ppp/pp47.htm

Astrachan, O. (1997): All about Darwin. URL: http://www.cs.duke.edu/~rodger/drool/pages/darwin/introduction.html

Astrachan, O. (1997): The DULL Programming Languish. URL: http://www.cs.duke.edu/~rodger/drool/pages/darwin/dull.html

Buck, D, & Stucki, David J. (2001). JKarelRobot: A Case Study in Supporting Levels of Cognitive Development in the Computer Science Curriculum. Proceedings SIGCSE 2001, Charlotte, NC, USA. pp 16-20.

Bloom, B.S., et al. (1956). Taxonomy of Educational Objectives: Handbook I: Cognitive Domain, Longmans, Green and Company.

Binder, Robert V. (2000). Testing Object-Oriented Systems: Models, Patterns, and Tools. Addision Wesley, Longman Inc.

Bergin, J. (2002): Early Bird. URL: http://csis.pace.edu/~bergin/PedPat1.2.html#earlybird

Bergin, J. (2002): Spiral. URL: http://csis.pace.edu/~bergin/PedPat1.3.html#spiral

Bergin, J. (2000): Introducing Objects with Karel J. Robot. URL: http://prog.vub.ac.be/ecoop2000/subm_papers/bergin.htm. (17 April 2000)

Bergin, J., Stehlik, M., Roberts, J., & Pattis, R. (2002): Karel J. Robot. A Gentle Introduction to the Art of Object-Oriented Programming in Java. URL: http://csis.pace.edu/~bergin/KarelJava/Karel++JavaEdition.html. (11 august 2002)

Bergin, J. (2003): A Pattern for Teaching Patterns. URL: http://www.csis.pace.edu/~bergin/patterns/. (15 maj 2003)

Bruckman, A. (1997): MOOSE Crossing. URL: http://www.cc.gatech.edu/elc/moose-crossing/

Cooper, S, Dann, W, & Pausch, R. (2003). Teaching Objects-first In Introductory Computer Science. Proc of the 34th SIGCSE Technical Symposium on Computer Seines Education. Reno, Nevada, USA. pp 191-195.

80

Dann, W, Cooper, S, & Pausch, R. (2002). Making the Connection: Programming With Animated Small World. Proceedings ITICSE 2000, Helsinki, Finland. pp 41-44.

Davis, S. (1996). Learn Java Now. Microsoft Press.

Dockx, J., & Steegmans, E. ( 2002): “A New Pedagogy for programming”. I: Sixth Workshop on Pedagogies and Tools for Learning Object Oriented Concepts. ECOOP 2002, June 11, 2002, Malaga, Spain. URL: http://prog.vub.ac.be/ecoop2002/ws03/acc_papers/Jan_Dockx.pdf/. (8 April 2002)

Eriksson, H-Erik. (1992). Objektorienterad programutveckling med C++. Lund: Studentlitteratur.

Elliot, A. (1998): LOGO. URL: http://education.otago.ac.nz/NZLNet/Logo/logohome.html. (13 august 2001)

Fenton, Norman E & Pfleeger, Shari L. (1997). Software Metrics. Boston: PWS Publishing Company.

Flake, Janice L. (2000): Characteristics of a MicroWorld. URL: http://mailer.fsu.edu/~jflake/MWChar.html

Guzdial, M. (2001). Squeak – Object-Oriented Design with Multimedia Application. Upper Saddle River: Prentice Hall.

Hartman, W, Nievergelt, J, & Reichert, R. (2001). Kara, finite state machines, and the case of programming as part of general education. Proc IEEE 2001. pp135-140.

Harapnuik, D. (2001): Inquisitivism. URL: http://www.quasar.ualberta.ca/nethowto/theory/learning_theory.htm#inquisitivism

Jenkins, M. (2000): Design-Do-Redo-Redo (DDRR) Pattern. URL: http://www-lifia.info.unlp.edu.ar/ppp/pp13.htm.

JkarelRobot. (2001): Karel The Robot. URL: http://math.otterbein.edu/JKarelRobot/JarelTutorial/Karel.htm.

Larochelle Marie, Bednarz Nadine, Garrison Jim. (1998). Constructivism and Education. Cambridge: Cambridge University Press.

Logo Foundation. (2000): THE LOGO PROGRAMMING LAUNGUISH. URL: http://el.media.mit.edu/logo-foundation/logo/programming.html

Manns, Mary L. (2000): Lab-Discussion-Lecture-Lab (LDLL). URL: http://www-lifia.info.unlp.edu.ar/ppp/pp8.htm

81

Martin, Fred G. (1995): LEGO/Logo and Electronic Bricks: Creating a Scienceland for Children. URL: http://web.media.mit.edu/~fredm/papers/nato/nato.html. (29 Nov 1995)Media Laboratory, MIT. (2002): StarLogo on the web. URL: http://education.mit.edu/starlogo/

MIT Media Lab. (1995): Microworlds. URL: http://www.umcs.maine.edu/~larry/microworlds/microworld.html

Norman, Donald (1987); Cognitive Engineering-Cognitive Science; in John M Carroll (ed); Interfacing Thought: Cognitive Aspects of Human Computer Interaction. Cambridge: Bradford/MIT Press.

North Central Regional Educational Laboratory. (2003): Constructivist Model for Learning. URL: http://www.ncrel.org/sdrs/areas/issues/content/cntareas/science/sc5model.htm

OĆallaghan, A. (2000): Mission Impossible. URL: http://www-lifia.info.unlp.edu.ar/ppp/pp21.htm

Poplawski, David A. (2002). Objects have class! An introduction to programming with Java. McGraw-Hill Companies Inc.

Python Software Foundation (2003): Introductory Material on Python - High level descriptions. URL: http://www.python.org/doc/Intros.html

Ryder, M. (2003): Minimalism. URL: http://carbon.cudenver.edu/~mryder/itc_data/minimalism.html. (1 may 2003)

SEDL. (1996): The Practice Implications of Constructivism. URL: http://www.sedl.org/pubs/sedletter/v09n03/practice.html

Smith, Charles T, & Smith, Denice, F. (2001): LOGO. URL: http://www.nothnbut.net/~mrchuc/logo_handout.html

Shneiderman, Ben. (1998). Designing The User Interface, 3rd ed. Addison Wesley Longman, Inc.

Stephan, J, & Downey, A. (2001). The cs111 Text, first ed. URL: http://puma.wellesley.edu/~cs111/notes/text-fall01.pdf"

Stillings, Neil A (1995). Cognitive Science. Cambridge, Massachusetts London: Bradford/MITS Press.Alice. (1999): Frequently Asked Questions. URL: http://www.alice.org/faq.htm

Zubek, R. (1998). ”Much Ado About Patterns”, CROSSROADS-THE ACM STUDENT MAGAZINE, Issue 5.1, p 21

82

Date post:	27-Jun-2018
Category:	Documents
Upload:	ledung
View:	215 times
Download:	0 times

Microworlds - umu.se · Web viewMicroworlds are program systems that realize a ... print word...

Documents