Nytt material om signaler

Vi har äntligen ™ skrivit lite om signaler. Detta kommer att tas upp i TIG167 i höst men om vi får göra om kurserna här på programmer kommer det komma in i andra kurser tidigare i programmet

 

Posted in TIG167 | Tagged | Leave a comment

Nytt material om “libraries” i C

Vi har skrivit material (text, övningar, video, pdf) till vår C-bok:

 

 

 

Posted in TIG167 | Tagged , | Leave a comment

Nytt material om Java

Under maj månad har vi tagit tag i vår backlog och skapat föreläsningar och föreläsningsfilmer till vår bok Programming with Java som används bland annat i kursen TIG015 på GU. Bland annat har vi kompletterat följande kapitel med filmer:

Arbetet fortlöper, varför denna post kommer att uppdateras i takt med att mer material tas fram. För den som vill ha en överblick över materialet i boken, ta en titt här:

Enjoy!

Posted in Uncategorized | Tagged , , , | 1 Comment

Vi förstår inte heller OOA&D

Bakgrund

Vi har fått frågor om analys och design utifrån en bok om en metod för OOA&D, utgiven på studentlitteratur. Då läraren hänvisat till boken och studenterna säger att de inte förstår boken och frågade oss, så läste vi boken för att förstå. Vi ville inte ge svar som går emot boken, och därigenom går emot vad läraren säger, varför vi läste boken i syfte att försöka förstå och förklara den.

Dock förstod inte heller vi boken. Vi tar här bokens exempel med ett konferenssystem som “designats” som utgångspunkt för en diskussion om varför vi inte förstår.

Vi har spelat in ett pod-avsnitt också: Vi förstår inte heller OOA&D-boken

Exempel från boken som inte heller vi förstår

Vi börjar med det designade klassdiagrammet (ett urval) för konferenssystemet.

Klassdiagram       

Konferensplanering

Klassbeskrivning från boken

Nedan beskrivs klasserna (i boken under rubriken “Klasser”) i vad som beskrivs som en “specifikation”. Specifikationen specificerar “de klasser som innehåller väsentliga attribut och icke-triviala operationer”. Återigen har vi gjort ett urval enligt klassdiagrammet ovan.

Person

Syfte: är att “Registrera basupplysningar om alla inblandade personer och aggregera varje persons konferensroller”.
Attribut:

  • Efternamn
  • Förnamn
  • institution
  • adress
  • e-mail

Operationer:

  • Skapa person
  • Skapa roll(!)

Deltagare

Syfte: “Registrera människor som kommer att delta i konferensen”.
Attribut:

  • datumregistrerad
  • tillstånd (Vad är det?)

Operationer:

  • Skapa deltagare
  • Skapa funktion(!)

Funktion

Syfte: “Registrera roller som en deltagare kan spela”.
Attribut:

  • föreslaget datum
  • tillstånd (Vad är det?)

Klassen Funktion saknar operationer. (se vår kommentar nedan om varför vi tycker det är märkligt)

Kommentar

Vi tycker det är oklart vad som menas med “registrera” (se syftena för klasserna Person, Deltagare och Funktion). Designen enligt klassdiagrammet är också något vi har frågor kring. Några designfrågor:

  • Enligt klassdiagrammet så består en Person, förutom kontaktuppgifter, även av noll till många Roll:er. Klassen Roll finns inte med i klasspecifikationen dock.
  • Enligt klassdiagrammet så består en Deltagare av noll till många Funktion:er. Vad skillnaden mellan en Roll och en Funktion är framgår inte av beskrivningarna.
  • Enligt klassdiagrammet så är Roll en basklass som ärvs ned till Deltagare, Författare och Bedömare. Dock är det endast Deltagare som har en lista med Funktion:er.

Här är klassdiagrammet igen (för referens):

Konferensplanering

Översatt till Java-kod (ett försök)

För att försöka förstå designen utifrån klassdiagrammet och klasspecifikationen, så ger vi oss på att tolka designen och skapa lite kodexempel. Vad annars skulle en design syfta till, än till att vara underlag till koden som skall skrivas? I Java-kod skulle skapandet av en Person med rollen Författare kunna se ut så här, givet klassdiagram och klasspecifikationen:

// Hur skulle man kunna skapa en Person med rollen “författare”?

// 1. Skapa en Person och registrera Roll:en Författare på den:

Person förf = new Person(“Anna”, “Bok”, ...);
// Vi tolkar "operationen" "skapa person" som konstruktor

// 2. Skapa rollen (författare):

Författare roll = förf.skapaRoll(FÖRFATTARE);
// Av någon anledning så finns "operationen" "skapa roll"
// i klassen Person...

// 3. Registrera rollen, men då måste vi ha en Funktion
// och eftersom blott Deltagare kan skapa funktioner, så får vi
// skapa en Deltagare:

Deltagare d = förf.skapaRoll(Deltagare);
Funktion f = d.skapaFunktion();
// Nu kan vi medelst funktionen registrera rollen för personen:
f.registreraRoll(roll, förf);

// Nej, det här blev ju rörigt?!
// Skapa en Deltagare för att skapa en Funktion för att registrera 
// Roll:en Författare på en Person? Känns inte intuitivt, direkt...

Problem med designen (som vi förstår den)

När vi skrev kod för att skapa en Person med Roll:en Författare, uppdagades:

  • Bara Funktion:er kan “registrera” Roller
  • Bara Deltagare kan skapa Funktion:er (och har av någon anledning en hel lista på Funktion:er vid behov)
  • Personer kan skapa Roller, så för att skapa en Person med rollen Författare måste vi:
    • 1. Skapa en Person p
    • 2.1 Be p skapa en Roll r1 av typen Deltagare
    • 2.2 Be p skapa en Roll r2 av typen Författare
    • 3. Be r1 skapa en Funktion f
    • 4. Be f registrera rollen r2Person p

Svårigheter för oss att förstå diagramm och specifikation

Vår bedömning är att det är mycket svårt att förstå klassdiagrammet och “specifikationen” av klasserna ovan. Den “specifikation” av klasserna som ges talar om attribut och operationer. Attribut betyder vanligtvis “instansvariabler” (t ex varje Person har olika e-postadresser, lagrade i objektens instansvariabel för e-post). Vad “operation” betyder har vi betydligt svårare att säkert avgöra genom att läsa boken. Boken talar ibland om “beteende” (hos objekt) och “funktioner” hos systemet. Nu finns också “operationer” som är listade tillsammans med klasserna. Vi har tolkat det som instansmetoder (dvs beteende) och inte statiska klassmetoder, eftersom det listas tillsammans med attribut som måste vara instansvariabler.

Nedan följer en lista på de saker vi har svårt att förstå i klassdiagrammet och “klasspecifikationen”:

  • Vad menas med “registrera” (från syftena med klasserna) – hur och var?
    • Varför ska klassen Funktion “registrera” roller som en Deltagare kan spela?
    • Eftersom klassen Funktion saknar “operationer”, hur kan den registrera roller en Deltagare kan spela?
  • Vad menas med attributet “tillstånd” som återfinns i klassen Deltagare och klassen Funktion?
    • Menas tillstånd som i “tillstånd från någon att göra något”, i så fall vad är det, vem gav tillståndet och hur gavs tillståndet och kan man bara ha ett tillstånd (att göra en sak)?
    • Menas tillstånd som i “ett objekts tillstånd”, vad kan det då vara? Ett objekts tillstånd är en funktion av värdet i objektets instansvariabler (i vart fall enligt den terminologi som används inom objektorienterad programmering). Att ha en instansvariabel som själv heter “tillstånd” blir då obegripligt.
  • Vad menas med “skapa” som i operationen “skapa person” i klassen Person
    • Menas konstruktor?
      • I så fall, varför har Person även operationen “skapa Roll”?
        • Har klassen Person en “factory method” för att skapa Roll-objekt?
  • Varför är inte klassen Roll med i klasslistan med specifikationer av klasserna?
  • Tittar man på klassdiagrammet så ser man att det finns tre sorters Roll:er eftersom man använder UML-notation för arv:
                       Roll
                   /    |      \
          Deltagare Författare Bedömare 

           Men bara Deltagare har association till Funktion.

  • Betyder det att klassen Person i själva verket enbart “aggregerar” Deltagare:s “konferensroller”?
  • Är Person i själva verket en basklass, så att Deltagare, Författare och Bedömare egentligen ärver Person och inte Roll? Eller ärver de från både Person och Roll? Hur ska vi tolka klassdiagrammet?
  • Igen, det blir svårt att förstå att klassen Funktions syfte är att registrera roller för Deltagare, särskilt eftersom Deltagare i klassdiagramet framställs som en sorts Roll – menas att Funktion registrerar till exempel rollen Deltagare för en Person? Se ovan om att registrera rollen Författare på en Person – Bara Deltagare har operationen skapa funktion, så vi måste alltså skapa en Deltagare för att skapa en funktion för att registrera rollen Författare på en Person… Whaaat?
  • Vad är attributet “föreslaget datum” i Funktion?
  • Vad är det för skillnad på en Roll och en Funktion? Varför är inte klassen Roll med i klassbeskrivningen?

Sammanfattning

  • Vi tror att vi inte förstår klassdiagrammet – vad är arv och vad är komposition?
    • Är det vi som inte förstår UML, eller är det en dialekt av UML som vi inte sett?
  • Vi tror att vi inte förstår syftet uttryckt i “registrera X” – t ex:
    • syftet med Funktion som var att “registrera roller som en Deltagare kan spela”
    • syftet med Person var att “registrera basuppgifter om alla inblandade personer”
    • Det är ju stor skillnad på att en klass “registrerar” det som lagras i objektens instansvariabler (attribut) som i fallet Person, och att en klass registrerar objekt av annan klass (t ex Roll) i ett annat objekt av en annan klass (t ex Deltagare) som i fallet med Funktion vars syfte det är att “registrera Roll:er Deltagare kan spela” (det blir ännu kostigare då en Deltagare genom arv är en Roll som ska registreras på en Deltagare)
  • Vi tror att vi inte förstår skillnaden på Funktion och Roll – Det är inte tydligt eftersom klassen Roll inte är med i “klasspecifikationen”
  • Vi tror att en Person bara behöver en lista på Roller och att Funktion inte behövs
  • Vi tror att vi inte förstår varför en Funktion inte har några operationer, trots att syftet är att “registrera roller”
  • Vi tror att vi inte förstår varför en Deltagare behöver en hel lista på Funktioner, då funktioners syfte är att registrera en roll
  • Vi tror särskilt att vi inte förstår varför bara Roll:en Deltagare har en lista på Funktion:er – eftersom Funktion ska registrera Roll:er så behöver man ju då skapa en Deltagare bara för att komma åt en Funktion för att t ex registrera Roll:en Författare på en Person
  • Vi tror att vi måste ha typer i klassdiagrammet för att förstå åtminstone vad attributen “tillstånd” skulle kunna representera (antagligen skulle vi ändå inte förstå, på grund av namnet “tillstånd” som vi förknippar med objekt)
  • Det är möjligt att det är översättningsproblem som ligger till grund för vår oförmåga att förstå, men vi förstår likväl inte klassdiagrammet
    • Om det är dåligt översatt så bör vi nog inte använda boken
    • Om det är korrekt översatt så kan nog vi inte rekommendera boken
  • Vi tror att vi blir förvirrade av terminologin som används i “klasspecifikationen”, t ex vad är skillnaden mellan:
    • “personer”, “människor”, “deltagare” i konferensen?

Vi skulle kunna skriva en liknande analys av andra exempel från boken, bland annat angående klassdiagram för ett bankkonto men det lämnar vi till en annan gång.

Utifrån vårt försök att förstå boken, så kan vi inte annat än konstatera att antingen är vi för dumma för att förstå boken (då får gärna någon som förstår boken hjälpa oss att förstå) eller så syftar boken till något annat än att förklara OOA&D. I alla fall sådan OOA&D som leder fram till något som går att implementera. Oavsett så får vi tyvärr hänvisa till någon annan, vad gäller boken och frågor kring den. Vi förstår inte vad bokens “design” syftar till och i synnerhet inte hur designen går att implementera i kod (om man inte har tur och gissar eller tolkar designdokumenten “rätt”).

En annan sak som vi saknar är själva designhantverket. Vi har alltid trott att design är en process för att koden som implementerar designen skall bli så bra som möjligt utifrån objektorienterade principer. Den “design” som ges i exemplet ovan är så ofullständig (och för oss obegriplig) att den måste tolkas och koden kan ju då bli hur som helst, beroende på hur man tolkar den. Programmerarna måste ju designa sina klasser utifrån den ofullständiga “design” som ges i boken. Frågan vi ställer oss då är:

“Vad ska programmerarna med bokexemplets ofullständiga (och i vårt tycke otympliga) design till?”

Vi får tyvärr säga till er studenter som frågat (bland annat om exemplet ovan) om boken, att vi inte heller förstår boken. Då boken tyvärr inte innehåller ett enda kodexempel, är det svårt att med säkerhet säga att det är lämpligt, lätt eller ens är möjligt att implementera designen, eller ens om detta är syftet med designen.

Kanske är tanken med bokens metod att programmerarna under implementationen vid behov skall göra om designen från grunden (kanske med hjälp av någon annan metod för OOA&D) så att den uppfyller såväl objektorienterade principer som kravspecifikationen.

Posted in Uncategorized | Tagged , , , , , , , , , , , , | Leave a comment

Nytt material om binär representation

Vi har skrivit lite material om binär representation:

Vi kommer att använda materialet i de kurser vi hoppas blir av framgent* men vi siktar på att inkludera detta i kommande version av TIG167.

*) https://programmeringspedagogik.wordpress.com/2018/04/11/forslag-pa-overgangslosning/

Posted in TIG167 | Tagged | Leave a comment

Motsägelse, ex 01.

Denna första gång i serien om motsägelser (finns som podcast-avsnitt också) skall vi kika på en bok, skriven på  svenska, om programmering. Vi skall nu belysa en motsägelse. Och, nu kommer ni läsare/lyssnare tänka något i stil med “är ni så jävla duktiga då?”. Nej, verkligen inte är vårt svar. Men vi jobbar hårt och släpper allt vi gör publikt, utan att ta betalt och rättar så fort vi bara kan. Dessutom hoppar vi över det dör med titlar. Mest beroende på att vi inte har titlar, men också för att vi båda tycker att det alltför ofta är till för att kompensera. Vidare uppmuntrar vi dig, läsare/lyssnare att publikt komma med kritik på våra grejer – vi rättar till felen direkt eller förklarar varför vi gjort som vi gjort. Men, tveka inte. Kom med  kritik, dock saklig.

Till saken. Denna serie handlar om motsägelser. Vi skall belysa detta med ett ganska roligt exempel från en bok skriven om språket C. Alla som använt C i riktiga program, d v s inte akademiska program som löser en löjligt enkelt uppgift och sen är klar, vet att det gäller att kolla om en funktion lyckades utföra sin uppgift eller inte. I C görs detta genom att kolla på returvärdet. I nedan exempel ser vi an allokering följt av en användning av det som returnerades (en pekare):

char *res = malloc(n+1);
strcpy(res, temp);

Vi tycker att det är jäkligt viktigt, jo men det är faktiskt det, med att kolla returvärden. Ok, i vissa fall kanske man kan strunta i att kolla om det gick bra att göra printf  men vi säger (vi tror inte!) att det är viktigt att visa, de personer som man skall lära ut till, att det är viktigt att skriva robusta program. Är det ens program annars? I koden kontrolleras inte om malloc lyckades. Vi kan alltså inte veta om res kan användas. Det hade räckt att göra något i stil med:

char *res = malloc(n+1);
if (res==null) 
  {
    return null;
  }

.. så hade allt varit ok.

Varför tar vi upp detta och gnäller så mycket. Det är faktiskt inte (bara) för att vi tycker att koden är slarvig och inte lär ut riktig programmering utan för att författaren bara 110 mm (11 cm) nedanför pratar om vanliga misstag. Ett av dessa vanliga misstag är :

utnyttjar en pekare som är oinitierad eller innehåller värdet NULL.

Man kan diskutera huruvida vi skall berätta om vanliga misstag och inte samtidigt berätta hur man undviker dessa misstag. men vi undviker denna, enligt oss, stora miss och fokuserar istället på det ganska komiska i att det i denna bok görs EXAKT den sak man 11 cm nedanför identifierar som ett vanligt misstag.

c-common-mistakes

Vi ser detta som ett exempel på motsägelse. Och givet de 110mm som skiljer texten med motsägelsen säger vi att den får 110 mp (motsägelsepoäng). Som du säkert förstått är en motsägelse i sig kass, men om du dessutom har ett lågt “mp” är det ätter värre. 110mm eller 11cm… inte kan någon vara värre än detta?

…. “just you wait and see”

/r+h

btw, funktionen read_input ovan har inspirerat oss till att skriva om robust kod. T ex följande: Reading data from a user.

 

 

Posted in Uncategorized | Tagged , , | Leave a comment

Nytt material om databaser och Java

I veckan som gått tog vi hand om några saker som kommit fram under kursen TIG058. Vi tänkte snabbt gå igenom vad som kommit fram och varför vi lagt till material.

Databaser

När vi rättade tentorna (ca 100 st) märkte vi ett par saker som studenterna hade lägre poäng på (snittpoängen på dessa uppgifter var betydligt lägre än övriga frågor) och eller än vad vi förväntade oss. Detta översatte vi till sämre kunskap. Om ca 100 studenter, till stor del, har rätt på de flesta saker och fel på några få så måste tanken slå en lärare att det kanske beror på oss (lärare) eller materialet. Så tänker vi i alla fall. Nedan listar vi problemen och våra åtgärder. Vi kan inte med säkerhet säga varför studenterna inte kunde dessa saker men vi antog att något av följande, eller en kombination, orsaker gäller:

  • Koncepten gicks igenom sent i kursen. Om saker tas upp sent kan de ibland hoppas över av studenter.
  • Materialet otydligt eller otillräckligt.

Tom sträng inte samma sak som NULL

Vi frågade, i tentan, studenterna vad som händer om man petar in tom sträng (d v s ”) i en databas (utan så kallade constraints). Den tomma strängen är som vilken sträng som helst och svaret skulle vara att det går bra – en gång. Studenterna skrev dock ganska ofta att det fungerar eftersom det inte finns ett “NOT NULL” constraint. Dessa studenter har, kan vi mer säkerhet anta, missförstått NULL och/eller tom sträng.

Åtgärden blev att ta fram kompletterade material (wiki-sida, presentation, video-film): http://wiki.juneday.se/mediawiki/index.php/Database:NULL-representing_lack_of_value

Where-syntax

Under rättningen av tentorna hittade vi ytterligare en sak som vi blev förundrade över. Studenter skrev påfallande ofta en select-satser i stil med:

SELECT make, color, licenseNumber FROM cars WHERE make='Volvo', color='Roed'

SELECT make, color, licenseNumber FROM cars WHERE make='Volvo' OR 'Ford'

För att välja ut bilar som uppfyller två villkor (make=’Volvo’ och color=’Roed’) måste man ange AND (eller t ex OR om man menar volvo eller röd).

SELECT make, color, licenseNumber FROM cars WHERE make='Volvo' AND color='Roed'

Vad gäller den adra satsen måste man vara explicit och skriva

SELECT make, color, licenseNumber FROM cars WHERE make='Volvo' OR make='Ford'

Även här utgick vi ifrån att materialet var felaktigt, med samma resonemang som ovan. Vi tog fram följande material (presentation, video-film): Databases – select (Full playlist) | Databases – where 1/2 | 2/2 | SQL WHERE clause (PDF)

Decomposing a table (Update 23/5 2018)

Vi upptäckte också, när vi rättade tentan, att vi fick en del fantasifulla och kreativa svar på en fråga där vi bad studenterna att splitta upp en tabell med dålig normalisering i tre tabeller. Tabellen handlade om bilar och hade tre textfält; license_number, color, make. Uppgiften var att dela upp tabellen i en bil-tabell, en färg-tabell och en bilmärkes-tabell. Färg-tabellen skulle gå att använda till annat än bilar, var tanken.

Förvånansvärt många studenter valde följande, i vår mening märkliga, upplägg:

car: LicenseNumber TEXT
color: color TEXT, LicenseNumber TEXT
make: make TEXT, LicenseNumber TEXT

Det vill säga, färg- och bilmärkes-tabellerna hade “foreign keys” till bil-tabellen.

Här måste återigen vår undervisning brustit i innehåll, varvid vi skapade följande kompletterande material:

Sedan tidigare hade vi följande kompletterande (ehuru något överkurs för en introduktionskurs enligt vårt tycke) material:

Java

Under en lab* samma kurs (TIG058) använde vi bland annat Map i den kod som studenterna fick av oss och skulle bygga vidare på. Det fanns inga krav på studenterna att de skulle förstå vår kod men vi uppmuntrade dem att försöka göra så. Det kändes lite tråkigt att inte ha material för att underlätta studenterna att förstå, så vi skrev lite nytt material(wiki-sida, presentation, video-film):  http://wiki.juneday.se/mediawiki/index.php/Java:Language_-_Collections

Vi hoppas kunna använda detta material även i kommande TIG167.

Update 23/5 2018:

Här är några andra föreläsnignar och kapitel som vi tog fram för TIG058 för att studenterna skulle kunna förkovra sig och förstå den kod som var given (av lärarna) i inlämningsuppgifter:

Och en del videoföreläsningar (som inte har kapitel):

Other than the above, we made several video lectures about the three-part assignment (project) in the course:

TIG058 – Student material and resources .

*) http://wiki.juneday.se/mediawiki/index.php/Assignment:Exposing_data_over_http

 

Posted in TIG058, TIG167 | Tagged , , , | Leave a comment

Sårbara kurser – TIG167

Vi fortsätter fortsätta sårbarhetsanalysen av våra kurser. Denna gång blir det TIG167 som vi har kursansvar för.

Med utgångspunkt i frågorna från i analysen av TIG058[1] kollar vi nu på TIG167.

Kursplanen

Kursplanen finns att ladda ner här: TIG167.

Lärandemål för kursen

Kunskap och förståelse

  • analysera ett givet problem inför implementation av en lösning visa grundläggande
  • förståelse för design och programmering i Android visa grundläggande förståelse
  • för procedurell programmering förklara hur en kod och grafiskt layout i Android
  • fungerar och skrivs i XML förklara hur ett modulärt C-program är uppbyggt
  • förklara ingående delar i utvecklingsprocessen av ett C-program

Färdigheter och förmåga

  • skriva strukturerade och modulära program i Android-miljö och i programspråket C
  • skriva automatiska tester till och debugga ett program
  • testa programmet på egen dator med hjälp av simulator
  • programmera för och ladda upp kod till inbyggd arkitektur eller mobil enhet
  • skriva program för olika skärmstorlekar och upplösningar i Android

Värderingsförmåga och förhållningssätt

  • avgöra när dynamisk respektive statisk minnesallokering skall användas
  • välja grad av modularitet genom avdelning av program
  • avgöra hur en mobil enhet skall interagera med omvärlden

Vår kommentar: Man kan återigen säga en hel del om målen ovan. Vi tar denna diskussion vid ett annat tillfälle. I dag skall vi analysera sårbarheten.

Former för bedömning / Examination

Kursen examineras genom momenten en individuell skriftlig inlämningsuppgift (3 högskolepoäng), en individuell salstentamen (4,5 högskolepoäng) samt ett projekt som genomförs i grupp (7.5 högskolepoäng).

Genomgång av kursens lärmål och examinationsform

Vi kommer att gå igenom kursens mål och examination utgående från frågorna ovan.

Specifik kompetens

Det finns i kursen TIG167 några kompetenskrav utöver generell programmeringskunskap. Vi förutsätter att alla kan programmera i ett objektorienterat språk, t ex Java. Men vi kan, enligt oss, inte förutsätta att en lärare kan vare sig Android, vilket i denna analys fall avser både operativsystemet och utvecklingsmiljön, eller C. Så denna kurs har alltså kompetenskraven Android och C.

Vad gäller Android ser vi ett krav att läraren, i sin handledande roll, har skrivit eller varit med om att skriva ett par så kallade appar.

Speciell utbildning eller erfarenhet

Att skriva program för Android är egentligen ganska enkelt men det är också lätt som utvecklare att glömma små detaljer vilket ibland gör att appen kraschar eller liknande. Det kan ta lång tid för en nybörjare att reda ut vad som är fel så behovet av handledning av erfaren utvecklare är viktig. Detta då handledarens roll i Android-delen av kursen till stor del handlar om att hjälpa studenterna hitta och lösa de små misstagen. Detta sparar mycket kalendertid för studenterna.

Även i C är det ganska enkelt att skriva ett program. Problemet med C är att det är ganska enkelt att skriva program som kraschar då felhantering eller att programmatiskt undvika krascher inte påtvingas utvecklare av språket. Böcker och annat material är, enligt oss, också slarviga med att ta upp felhantering.

Kursmaterialet

Kursens material för Android[2] täcker inte hela kursens behov. Materialet som finns bedömer vi, som själva har skrivit materialet, dock vara nog för att kunna användas för självstudiekurser tillsammans med handledning. Se tidigare bloggpost om TIG058 för genomgång av vårt kursmaterial. För att Android-delen av kursen skall bli “osårbar” behöver kompletterande material tas fram.

Kursens material för C-delen har ändrats under gång. I senaste kursen användes en bok som inte, enligt oss, har material bra nog för att användas. Vår kritik mot boken är främst:

  • materialet undviker att hantera fel och skriva robust kod
  • för få övningar
  • lösningsförslagen verkar ihophaffsade – innehåller ofta fel eller slarv

Vi har tagit fram delar av en C-kurs[3]. Om vi kompletterar även denna med saknade delar kommer materialet vara nog för att kunna användas för självstudiekurser tillsammans med handledning.

Kursens Android-material och tilltänkt C-material är publicerat och licensierat under en sådan licens att användande är tillåtet om man anger källa. Med publicerat menar vi publikt tillgängligt utan kostnad eller inloggning.

Examinationsformen

Kursen examineras via tentamen, inlämningsuppgift och projektarbete.

Tentamen (C)

Det finns gamla tentor i den lärplattform som används på GU. Några tentor har lösningsförslag, ibland dessutom i videoform. Gamla tentor samt lösningsförslag gör att det är enkelt att skriva och rätta nya tentor. Det finns inget i kursplanen som sätter några ytterligare krav på en lärare. För att rätta tentamen, är det vår bedömning att kunskaper i Java, kompletterat med nåågra dagars inläsning av C så utgör inte rättning av tentamen ett hinder.

Inlämningsuppgift (C)

Inlämningsuppgifter finns redan och kan användas direkt. Vi har använt script för att underlätta rättningen av studenternas inlämningar. Även utan dessa går det att rätta inlämningarna men det kan lite mer tid. Det finns inget i kursplanen som sätter några ytterligare krav på en lärare. Handledarinstruktioner bör tas fram.

Projekt (Android)

Studenterna får själva välja projekt. Lärarens roll är, vad gäller examination, är att granska och bedöma den inlämnade koden, rapporter och appen när den körs. För att göra detta krävs viss erfarenhet av Android. Alltså har vi, återigen, ett krav på Android-kompetens.

Slutsats

Tänkt materialet för kursen nästa år kan idag inte användas som en distanskurs. Detta medför att vi har ett beroende till personal som kan både C och Android. Åtgärden till nästa termin är att komplettera materialet så att lärare med C- och Android-kompetens inte är kritiskt.

Dock har kursen ett krav på Android-kompetens hos den lärare som skall jobba med handledning av Android-projektet.

Kursen TIG167 ställer krav på att läraren skall ha grundläggande kunskaper i programmering. Vidare behöver läraren ha erfarenhet av Android och helst även av C.

Det borde vara enkelt, enligt samma resonemang som i TIG058, att hitta någon i befintlig personal som kan hålla kursen TIG167 då grundkunskaper i programmering kan kompletteras med C- och Android-kunskaper.

Slutsatsen är att vi idag ser en liten sårbarhet med kursen. Vi har, till skillnad från TIG015 och TIG058, inte möjlighet att ta in tidigare studenter då denna kurs ges sista terminen och således har dessa tidigare studenter slutat sina studier.

[1] https://programmeringspedagogik.wordpress.com/2018/04/17/sarbara-kurser-tig058/

[2] http://wiki.juneday.se/mediawiki/index.php/Android_-_the_practical_way

[3] http://wiki.juneday.se/mediawiki/index.php/Programming_with_C

 

Posted in Uncategorized | Leave a comment

Sårbara kurser – TIG015

Vi fortsätter sårbarhetsanalysen av våra kurser. Denna gång blir det TIG015 som vi inte har kursansvar för. Dock håller vi (ansvarar för) programmeringsdelen som utgör ca 50%.

Med utgångspunkt i frågorna från i analysen av TIG058[1] kollar vi nu på TIG015.

Kursplanen

Kursplanen finns att ladda ner här: TIG015.

Lärandemål för kursen

Kunskap och förståelse

  • redogöra för begreppen data och information.
  • använda teorier och modeller som behövs för att förstå systemtänkande inklusive
  • systemteorins begrepp hårt och mjukt tänkande.
  • redogöra för begreppen systemvetenskap och informatik.
  • redogöra för akademiska riktlinjer för rapportskrivning.

Färdigheter och förmåga

  • redogöra för och kritiskt analysera informationsteknologin och dess användning,
  • informationssystems innehåll och användning, informationsteknologins
  • användning i informationssystem, informationssystemutveckling med
  • användarfokus, hur objektorienterade program och system fungerar internt samt
  • hur problemlösning i program fungerar. utveckla fungerande program från enklare
  • problemlösning och muntligt och skriftligt kunna redogöra för och kritiskt analysera lösningarna.

Värderingsförmåga och förhållningssätt

  • reflektera kring några av IT:s olika roller i samhället.

Vår kommentar: Man kan säga en hel del om målen ovan. Vi tar denna diskussion vid ett annat tillfälle. I dag skall vi analysera sårbarheten.

Former för bedömning / Examination

Kursen examineras genom momenten en individuell skriftlig inlämningsuppgift (3 högskolepoäng), en individuell salstentamen (4,5 högskolepoäng) samt ett projekt som genomförs i grupp (7.5 högskolepoäng).

Genomgång av kursens lärmål och examinationsform

Vi kommer att gå igenom kursens mål och examination utgående från frågorna ovan.

Specifik kompetens

Det finns i kursen TIG015 inga speciella kompetenskrav angivna i kursplanen.

Speciell utbildning eller erfarenhet

Det finns i kursen TIG015 inga speciella krav på utbildning eller erfarenhet (hos läraren) utifrån mål och innehåll angivna i kursplanen.

Kursmaterialet

Kursens material bedömer vi, som själva har skrivit materialet, vara nog för att kunna användas för självstudiekurser tillsammans med handledning. Se tidigare bloggpost om TIG058 för genomgång av vårt kursmaterial

Kursens material är publicerat och licensierat under en sådan licens att användande är tillåtet om man anger källa. Med publicerat menar vi publikt tillgängligt utan kostnad eller inloggning.

Examinationsformen

Kursen examineras via tentamen och inlämningsuppgifter.

Det finns gamla tentor i den lärplattform som används på GU. Alla tentor har lösningsförslag, ibland dessutom i videoform. Gamla tentor samt lösningsförslag gör att det är enkelt att skriva och rätta nya tentor. Det finns inget i kursplanen som sätter några ytterligare krav på en lärare än just grundläggande programmering.

Inlämningsuppgifter finns redan och kan användas direkt. Vi har använt script för att underlätta rättningen av studenternas inlämningar. Även utan dessa går det att rätta inlämningarna men det kan lite mer tid. Det finns inget i kursplanen som sätter några ytterligare krav på en lärare. Vidare finns det omfattande handledarinstruktioner för inlämningsuppgifterna med beskrivande lösningsförslag.

Slutsats

Kursen TIG015 ställer så klart krav på att läraren skall ha grundläggande kunskaper i programmering. Men inga ytterligare kunskaper behövs enlig kursplanen.

Materialet är av sådan karaktär att det kan användas i en självstudiekurs, så vi är säkra på att vi kan säga upp oss eller få sparken utan att detta har en negativ effekt på möjligheten att ge kursen.

Det vara enkelt, enligt samma resonemang som i TIG058, att hitta någon i befintlig personal som kan hålla kursen TIG015 då den är en grundkurs inom huvudområdet Informatik och ges under första året.

Slutsatsen är att vi inte ser någon sårbarhet med kursen. Vi tror, i likhet med TIG058, till och med att även en eller ett par framstående studenter (ibland kallat amanuens) skulle kunna hålla kursen med stöd av en lärare. Det senare stärks även av svaren i kursvärderingen, där handledarstudenterna fick högre betyg än lärare och materialet(!).

[1] https://programmeringspedagogik.wordpress.com/2018/04/17/sarbara-kurser-tig058/

Posted in Uncategorized | Leave a comment

Arbete med kursplaner som kurs- och programutveckling

Bakgrund

Under avdelningens vårkonferens togs ett antal beslut för att förbättra utbildningen i det lilla perspektivet (per kurs) och i det större perspektivet (programnivå). Ett antal aktiviteter i denna riktning beslutades. Vi listar ett urval av aktiviteterna nedan.

Programråd SVP
Aktiviteter:

  • Arrangera månatliga lärarmöten på respektive program.
  • Arrangera gemensam lärarkonferens årligen.

Kursutvärdering för kursutveckling

Aktiviteter:

  • Programledare tar fram och fastställer rutin för genomförande av kurs- och programutvärdering.
  • Lyft resultat av kursutvärdering på lärarmöten samt diskutera föreslagna förändringar.

Inför lärarlag

Aktiviteter:

  • Genomför sårbarhetsanalys på kursnivå kring personberoende
  • Ta fram förslag för omstöpning av samtliga kurser frånsett uppsatser  till 7,5 högskolepoäng.

Det går att urskilja två tydliga trender i aktiviteterna; ökad samverkan mellan lärarna (lärarmöten, konferenser och lärarlag) och uppföljning (kursutvärdering).

Reflektion

Samverkan och kommunikation mellan kollegor och lärare är nödvändigt för att säkerställa progressionen mellan kurserna samt att helheten av kurserna uppfyller på ett meningsfullt sätt helheten i programmet. Dessutom bidrar samverkan och kommunikation mellan lärare till pedagogisk utveckling.

Att arbeta med kursutvärdering som kursutveckling, däremot, känns bakvänt. Funktionen med kursvärdering är att säkerställa att och mäta huruvida studenterna uppnått lärandemålen för kursen i enlighet med kursplanen. Det är därför som det är rekommendabelt att i kursutvärderingen ha med frågor kring studenternas (upplevda) uppfyllande av sina lärandemål i kursen såsom de beskrivs i kursplanen.

Problemet är att vi inte har med några aktiviteter kring att revidera kursplanerna i listan som togs fram under konferensen! Visserligen kunde vi lyft detta under konferensen men det var inte med i de framröstade diskussionspunkterna (och vi föreslog detta som en punkt att rösta på inför konferensen).

Nedan kommer vi argumentera för att 1) detta behövs och 2) arbete med kursplanerna kommer att inkludera aktiviteter i listan ovan samt bidra till att uppfylla aktiviteternas mål.

Revidering av kursplanerna

I detta stycke kommer vi först argumentera för att kursplanerna är i behov av uppdatering, sedan att detta arbete bör ses som en process för kollegialt samarbete, kursutveckling, progression i programmet och kvalitetssäkring av utbildningen.

Uppdateringsbehov i kursplanerna

När vi gått igenom de kursplaner som gäller för de kurser vi är lärare i, så har vi funnit en rad problem. Språkligt och formmässigt finns det brister som torde vara lätta att rätta till (men som samtidigt det är lite pinsamt att de dels smugit sig in i kursplaner som fastslagits av IT-fakultetsnämnden, dels fått ligga kvar under så lång tid utan att någon gjort något åt dem).

Det handlar om språkriktighet, hur upprepningar i listor och så vidare ser ut och i vissa fall ren layoutmässig inkonsekvens. Även om det är lite pinsamt så är det ganska små saker och därför lätt att rätta till.

Men det handlar också om innehållsmässiga och semantiska problem. En del formuleringar och termer är för oss lärare svåra att begripa. När det gäller kursinnehåll så känns det i vissa kurser som om det blandas högt och lågt i det att vissa kursers innehåll beskrivs i väldigt generella termer samtidigt som extremt specifika inslag finns med. Ett närbesläktat problem är att kursernas namn inte återspeglar kursinnehållet, vilket är svårare att rätta till på kort sikt men väl måste upplevas förvirrande för studenterna (oavsett om de läser kursplanen eller inte).

Det som vi dock ser som det största uppdateringsbehovet hos “våra” kursplaner är nog listan på lärandemål. Här brister formen i det att den avviker från rekommendationer kring hur lärandemål skall formuleras. I korthet så skall lärandemålen sätta fokus på studentens lärande och vara lätta att förstå samtidigt som de ska vara möjliga att examinera (och i många fall även att gradera med bedömingskriterier för G respektive VG).

Många av lärandemålen brister dessvärre i kvalitet samt bryter mot reglerna och rekommendationerna för kursplaner (inklusive rekommendationer och regler för just lärandemål). Detta går i många fall att justera genom att formulera om lärandemålen så att de blir mer konkreta, tydliga och examinerbara. Dessvärre så känner vi inte igen många av formuleringarna i lärmålen. Här följer några lärandemål vi inte riktigt förstår vad de betyder:

“hur objektorienterade program och system fungerar internt”

Vad menas med “internt”? Vad är det för skillnad på objektorienterade program och system? Fungerar de olika “internt”? Och så vidare.

“redogöra för hur färdiga metoder i programbibliotek kan användas”

Finns det ofärdiga metoder?

“tillämpa enkla grafiska gränssnitt”

Vi förstår inte vad som menas med “tillämpa”. Ska studenterna kunna skriva program med enkla grafiska gränssnitt? Eller ska studenterna kunna använda program med enkla grafiska gränssnitt? Om det senare är fallet, vilka grafiska gränssnitt är enkla och vilka är komplicerade eller komplexa? Och så vidare.

“värdera olika realiseringar av enkla algoritmer”

Det här är för oss otydligt. Värdera hur? Vilka eller vems realiseringar? Vad är en enkel algoritm? Vad avses ens med en algoritm?

Andra lärandemål känns helt enkelt som om de hamnat i fel kursplan (möjligen på grund av att kurser har utvecklats innehållsmässigt under åren utan att kursplanerna ändrats för att återspegla denna utveckling). I kursen TIG058 – Programmeringsteknik och databaser, förekommer lärandemålet “förklara programmeringens grunder och Javas syntax”. Detta är emellertid något som lärs ut och examineras i programmets första kurs TIG015 – Informationsteknologi och informationssystem. Att en förskjutning av innehållet kunnat ske på detta vis (i förhållande till de fastslagna lärandemålen) tror vi beror på att lärandemålen och kursplanerna är alldeles för vaga och otydliga. I senaste iterationen av TIG058 konstruerade studenterna ett Client-Server-system med Java Servlets, JSON och ett grafiskt GUI (skrivet i Swing). Studenterna lärde sig använda och testa HTTP, JSON (parsning och användning) och en del designmönster (bland annat Builder och Factory). Detta är inte möjligt, menar vi, i en kurs vars lärandemål är att kunna “förklara programmeringens grunder och Javas syntax”. Det är snarare en förutsättning för att gå kursen att kunna programmeringens grunder och Javas syntax.

Kursplaneutveckling som process för utveckling av utbildningen

Göteborgs Universitets regler för kursplaner säger bland annat följande om lärandemålen:

Kursens lärandemål ska uttryckas i termer av förväntade studieresultat med avseende på vad som ska uppnås för godkänt betyg på kursen. Målen ska vara examinerbara, väl avvägda och realistiska med tanke på kursens omfattning och förkunskapskrav. Målen ska så lång möjligt preciseras och konkretiseras utifrån kunskapsformerna Kunskap och förståelse, Färdighet och förmåga, samt Värderingsförmåga och förhållningssätt, vilka kan formuleras tillsammans eller under respektive rubrik.

(vår fetstil)

https://medarbetarportalen.gu.se/digitalAssets/1617/1617200_anvisningar_kursplaner_170228.pdf

Det är tydligt att syftet med målen är att sätta fokus på studenternas lärande då de ska uttrycka förväntade studieresultat. Fokuset på studenterna och dessas studieresultat kräver också att lärandemålen är tydliga för studenterna, så att de förstår vad som krävs för att få godkänt på kursen. Det kräver också att vi formulerar dessa studieresultat på ett sätt som går att observera och examinera. För att uppnå dessa krav så behöver vi stöd och kollegiala diskussioner.

Vi kommer här använda oss av det stöd som PIL-enheten rekommenderar för utveckling av lärandemålen som stöd för vår argumentation att arbetet med att förbättra kursplanerna (även arbetet med lärandemålen) faktiskt möter upp mot de aktiviteter som beslutades under konferensen.

http://kursutveckling.se/dok/nshu_Larandemal_061011.pdf

I dokumentet “Att skriva förväntade studieresultat – Stöd för att skriva förväntade studieresultat på kursnivå” som PIL länkar till beskrivs vad lärandemål är och vad de är till för men också vad effekterna av tydliga lärandemål är. T ex sägs i början av dokumentet:

Tydliga lärandemål i form av förväntat studieresultat ger lärarna möjlighet att bygga vidare på tidigare kurser och är därför en förutsättning för progression.

Detta innebär ju, om man håller med dem och det gör vi, att en positiv bieffekt av att ha tydligare lärandemål underlättar arbetet på programnivå med att säkerställa en bättre progression mellan kurserna. Är målen tydligare så gäller ju inte det bara studenternas läsning av målen utan även lärarlagets läsning av målen.

I dokumentet finns också ett avsnitt om varför lärandemålen skall uttryckas i termer av förväntade studieresultat. Den första anledningen som anförs är att fokus sätts på studentens lärande. Detta motiveras i tre punkter som vi finner så relevanta att vi återger dem här:

  • Studenternas lärande blir centralt när man arbetar med formuleringar om vad studenterna ska kunna prestera efter en avslutad kurs.
  • Det är inte lärarna och deras undervisning som är det primära intresset, utan studenternas lärande.
  • Lärarnas viktiga uppgift är att på bästa sätt underlätta och stödja detta lärande.

Dessa är perspektiv som vi fullt delar. De beskriver väldigt väl vår syn på lärarrollen! Lärarens viktigaste uppgift är att underlätta och stödja studenterna i deras arbete med att lära sig kursens innehåll. Arbetsfördelningen är tydlig här. Kursens mål är inte att lärarna ska lyckas lära ut innehållet, utan att studenterna ska nå de krav som ställs för att få godkänt på kursen och dessa krav uttrycks i termer av vad studenterna ska kunna vid examination. Lärarnas uppgift är att stödja och underlätta för studenterna att nå dessa kunskapskrav och studenternas uppgift är att studera det material som kursen innehåller.

Det är glädjande att finna stöd för detta synsätt i dokument som rekommenderas av universitetet. Det är ett steg bort från katederundervisning där läraren från en upphöjd position förmedlar kunskap till studenterna i ett auditorium. Denna en-till-många-undervisning känns inte så modern. Naturligtvis ingår det i lärarens uppgift att i klassrummet förklara och föreläsa men det är inte den viktigaste uppgiften. För att studenterna ska kunna tillgodogöra sig kunskaperna och färdigheterna i kursen krävs också att de gör en insats och studerar. Lärarens viktigaste roll är att underlätta dessa studier och stötta studenterna i denna insats.

Under punkten Tydlighet som sedan följer i dokumentet listas en rad positiva effekter av att arbeta fram tydliga lärandemål. Studenterna ser vad som förväntas av dem under och efter kursen vid examination. En lärare som tar över en kurs får lättare att förstå vad kursen går ut på. Det gör kursen mindre sårbar och mindre personberoende. Med tydligare lärandemål ökar också lärarlagets samsyn om kurserna eftersom det lättare går att förstå vad en kurs leder till om detta uttrycks tydligt i lärandemålen. Relaterat till den förra punkten är att en lärare som håller en senare kurs har en bättre bild av studenternas förkunskaper – de är ju tydligare uttryckta i den tidigare kursens lärandemål. Slutligen finns här en extern dimension. Tydligare lärandemål gör det tydligare för arbetsgivare att förstå vad studenterna kan efter examen. Huruvida detta är positivt beror naturligtvis på om kunskaperna i lärandemålen motsvaras av det som arbetsgivaren efterfrågar, men det är en annan diskussion. Personligen vill vi själva lägga till att tydliga kunskapsbaserade lärandemål gör det lättare för studenterna att beskriva sin examen i CV eller under en anställningsintervju.

Vidare menar man, i dokumentet, att fokuset på studieresultat leder till mer realistiska mål. Om fokus i stället varit på vad läraren avser att lära ut, finns en risk att läraren saltar med lite för många punkter för att verka generös eller bred i sin kunskap. Med fokus på studieresultat förskjuts i stället fokus till att resultatet handlar om krav på såväl studenten som läraren.

Ett studentfokus på målen, menar man vidare, leder också till att det blir tydligare och lättare att se sambandet mellan mål, undervisning och examination. Denna tydlighet gör det lättare att utforma undervisningen och har stor betydelse för studentens lärande.

En annan effekt är, fortsätter man i dokumentet, att en process där man i lärarlaget (kollegiet) arbetar fram målen tillsammans ofta leder till en pedagogisk utveckling såväl som kursutveckling samt leder till insikter om undervisningen.

Uppföljning av kurserna blir, skriver man vidare, lättare och mer fokuserad på studenternas lärande. Det tycker vi låter rimligt och som en bra sak.

Resten av dokumentet ger konkreta förslag och en arbetsordning för hur arbetet med lärandemålen kan gå till. Det är av oss rekommenderad läsning för dem som vill se ett förslag på hur detta arbete rent konkret kan gå till.

Sammanfattningsvis så håller vi med om det som sägs i det länkade dokumentet om effekterna av att arbeta med lärandemålen. Genomför vi detta arbete som lärarlag tror vi att många av syftena med aktiviteterna som togs fram på konferensen uppnås. Progressionen i programmet kan lättare säkerställas, vi får ökad förståelse för varandras kurser och hur de relaterar till våra egna kurser och vi minskar sårbarheten och personberoendet för individuella kurser. Studenterna får en bättre kvalitet i kurserna och lättare att nå sina studieresultat. Diskussionerna kring lärandemålen kommer att stärka vår pedagogiska förmåga och få oss att reflektera över vår roll som lärare och vår undervisning.

När detta arbete är avslutat finns det anledning att ta tag i kursvärderingarna. Uppföljning och undersökning är naturligtvis också viktigt.

Posted in Uncategorized | Leave a comment