Högnivåspråk - en första introduktion Assemblerspråk kontra högnivåspråk - en jämförelse: Assembler (symbolisk maskinkod): Programmeraren måste själv hantera eventuella flyttningar av data från en cell till en annan. Programmeraren måste ha en mikroskopisk syn på uppgiften, arbeta med händelser i enskilda celler. Programmen är maskinberoende, dvs. beroende av instruktionsrepertoaren i den aktuella processorn. Instruktionerna är långt ifrån engelska (eller andra naturliga språk). Programkoden måste assembleras av en assemblator innan de kan köras. Högnivåspråk: Programmeraren behöver inte bekymra sig om detaljerade flyttningsinstruktioner eller minnesadresser. Programmeraren kan ha en makroskopisk syn på uppgiften, arbeta med större operationer. Programmen är portabla (de kan flyttas mellan olika maskintyper), dvs. de är inte maskinberoende. De måste dock antingen kompileras (härvid skapar man en version på objektkod) eller tolkas (ingen objektkod skapas, programmet tolkas och utförs instruktion per instruktion) för att kunna exekveras. Instruktionerna är ofta en blandning av engelska och matematisk standardnotation.
Programvarupaket: Kategori Antal programmerare Hur länge varar projektet? Antalet kodrader i slutprodukten Exempel triviala 1 person 1-2 veckor < 500 kursuppgifter små 1-3 personer några veckor eller månader medelstora 2-5 personer Några månader till ett år stora 5-25 personer mycket stora 25-100 personer extremt stora över 100 personer 1-3 år 10.000-100.000 3-5 år 100.000-1 miljon 500-2.000 studentprojektarbeten, avancerade kursuppgifter 2.200-10.000 forskningsprojekt, enkla mjukvaruprodukter: assemblatorer, editorer, undervisningssofta de flesta vanliga tillämpningarna: textbehandling, kalkylprogram, operativsystem för smådatorer, kompilatorer stora realtidsoperativsystem, bokningssystem för flygbolag, lagerbokföring för multinationella företag,... över 5 år över 1 miljon avancerade militära tillämpningar, internationella telekommunikationsnätverk,...
Software engineering och programvarans livscykel: Programmering är mycket mer än kodning med hjälp av trial and error (eller trial and horror). Vi talar om software engineering, mjukvaruteknik. Mjukvaruteknik innebär ett disciplinerat tillvägagångssätt där man använder sig av alla konstens regler, all den samlade yrkeskunskapen, inklusive matematisk och logisk dito, kända och välprövade algoritmer, formell programverifiering - och allt blir klart inom de givna tids- och budgetramarna. Målsättningarna för kvalitetsmjukvaran: Den fungerar (korrekt). Den kan läsas och förstås (även av andra än upphovsmannen själv...) Den kan modifieras (utan förkrossande möda). Den blir färdig inom de givna tids- och budgetramarna.
Första steget: att förstå problemets krav och åstadkomma en programspecifikation. Andra steget: att lösa problemet val av eller utvecklandet av algoritmer top down-design informationsgömning (information hiding) datadesign. Tredje steget: att implementera lösningen: Extern dokumentation (allt utöver själva koden: användarmanual, testplan inklusive testkörningar, de valda algoritmerna, flödesplaner, systembeskrivningar, databeskrivningar, kontaktinformation,...) Intern dokumentation (allt som ingår i själva koden för att göra den möjligast klar: effektiv användning av kommentarer i koden, självdokumenterande/självförklarande kod, prettyprinting (klar och behagfull formattering), användning av konstanter där sådana är välmotiverade,...) Fjärde steget: programunderhåll. Verifiering och testning pågår samtidigt med alla dessa steg - redan den första designen borde verifieras.
Testplanen skall planeras innan man alls börjar koda. Testplan: Exempel: att testa inläsningen av en lottorad i ett lottoprogram Test nr. 1: Syftet: testa att man korrekt läser in 7 tal Indata: 1,2,4,5,7,18,19 Förväntat resultat: raden ok Programmets resultat: Verifiering/kommentar: Test nr. 2: Syftet: testa att man inte accepterar tal utanför intervallet 1..37 Indata: 0,2,4,5,7,18,38 Förväntat resultat: raden godkänns ej, felmeddelande för 0 och 38 Programmets resultat: Verifiering/kommentar:
Test nr. 3: Syftet: testa att man inte accepterar duplikat Indata: 1,2,4,5,7,1,19 Förväntat resultat: raden godkänns ej pga 1 som förekommer två gånger Programmets resultat: Verifiering/kommentar: Test nr. 4: Syftet: testa att man enbart accepterar heltal Indata: 1,2,4,5,7,18,19.5 Förväntat resultat: 19.5 godkänns ej. Programmets resultat: Verifiering/kommentar:
Test nr. 5: Syftet: testa att man enbart accepterar tal Indata: 1,2,4,5,A,18,* Förväntat resultat: raden godkänns ej pga A och * Programmets resultat: Verifiering/kommentar: På detta sätt planerar man tester för alla eventualiteter man någonsin kan tänka sig - innan man alls börjar koda. Därefter är risken stor att man blir blind för sin egen kod och mindre benägen att hitta fel och brister i den.
Formell verifiering Förvillkor (prekonditioner) Eftervillkor (postkonditioner) Loopinvarianter Klassinvarianter Formella metoder kommer att tas upp på senare kurser. Det kan dock vara bra att redan nu bekanta sig med några hjälpmedel som används därtill. Dessa är för- och eftervillkor samt loop- och klassinvarianter. Förvillkor säger vilka villkor som skall vara sanna innan vi får utföra en operation. Om dessa villkor uppfylls före operationen, garanterar eftervillkoret resultatet. Om man bryter mot förvillkoren, är eftervillkoret inte garanterat. Förvillkoren fungerar alltså som en varudeklaration, product disclaimer : förvillkor antal > 0 operation medelvärde summa/antal eftervillkor medelvärdet är medelvärdet av summa/antal. Loopinvarianter berättar om vad som sker inne i en loop. Den måste vara sann före varje inträde i loopen, och efter varje varv, också efter sista varvet. Ex. en loopinvariant för en loop som summerar heltalen i en lista tills man träffar talet 0: 1 <= Index <= MaxList + 1 AND 0 finns ej i List[1].. List[Index-1] AND Sum = summan av List[1].. List[Index-1] En klassinvariant kan ex. kräva att antalet instanser till en klass Kursdeltagare måste vara >= 0.
Olika programmeringsparadigmer Olika typer av programmeringsspråk har utvecklats för olika slags tillämpningar. Det finns knappast ett enda språk som skulle vara optimalt för alla tillämpningar. Försök att skapa dylika (ex. Ada) har lett till massivt stora språk, dokumenterade på långa hyllrader, som ingen människa behärskar i sin helhet. Nedan presenteras fem olika programmeringsparadigmer, dvs. fem olika programmeringsfilosofier som alla reflekterar en bestämd syn på hur man borde tänka när man programmerar, hur man borde analysera själva problemet som skall lösas - i vissa fall (ex. funktionell programmering) ger redan problembeskrivningen lösningen. 1) Imperativa programmeringsspråk Som namnet avslöjar, är det frågan om att ge kommandon. Algoritmen reflekterar de kommandon som vi ger åt en von Neumann-maskin. De flesta traditionella programmeringsspråken (ex. Pascal, Modula-2, men även C) tillhör denna kategori. Även objektorienterade språk som Java har en klart imperativ del där de grundläggande kommandona och styrstrukturerna ingår. 2) Funktionell programmering Här möter vi ett radikalt annorlunda sätt att tänka om problem och program som skall lösa dessa problem. Beskrivningen av problemet ger redan lösningen. Vi ser världen som bestående av funktioner; ett eller flera argument från en källmängd skall avspeglas av ett bestämt värde i en målmängd. Funktionen själv skall beskriva detta förhållande:
källmängd målmängd 2 4 6 10 4 16 36 100 f(x) = x 2 I funktionella språk beskriver vi dylika samband som funktioner. Allt som skall kodas, skall beskrivas som något slags funktion. När det gäller en sökrutin, ställer vi oss frågan vad det innebär att ett sökt nyckelvärde finns i listan; antingen finns värdet inte där, och då returnerar vår funktion värdet false, eller så finns värdet i listan - antingen i dess första plats eller någonstans i resten av listan, och vi returnerar värdet true. När det gäller sorteringsrutiner ställer vi oss frågan vad som är förhållandet mellan en given lista och dess sorterade permutation, och beskriver sedan detta förhållande. En lista är den grundläggande datastrukturen, och den analyseras som ett första element följt av resten av listan. Grundmekanismen är rekursion. Det finns ingen tilldelningssats, och det finns inga loopstrukturer - dessa ersätts av rekursionen. (Vad gör vi med första elementet? Vad gör vi med resten av listan?) För att en rekursiv lösning skulle vara korrekt, måste den uppfylla tre villkor:
Det måste finnas minst ett icke-rekursivt basfall (och lösningen måste vara korrekt för detta basfall) - annars har vi en oändlig rekursion ( a rose is a rose is a rose... ) Det allmänna, rekursiva fallet måste konvergera mot (närma sig) detta basfall - annars hotar oändlig rekursion. Givet att rekursionsmekanismen fungerar, måste även resten av lösningen vara korrekt. Ex. fakultet(n) = 1, om n = 0 fakultet(n) = n * fakultet(n-1), om n > 0 (Odefinierat, om n < 0 - en prekondition, förvillkor, i uppgiftsbeskrivningen kunde ta hand om detta.) I beskrivningen ovan av vad vi menar med fakultet har vi redan lösningen. Det första fallet är det icke-rekursiva basfallet. Det andra fallet, det rekursiva allmänna fallet, konvergerar mot basfallet i och med att argumentet minskar med 1 för varje anrop. Även helheten är korrekt; vi har *, inte ex. +... Typiska funktionella programmeringsspråk är Lisp, Scheme och SML. Typiska tillämpningsområden finner man inom artificiell intelligens (språkanalys, robotstyrning). Logikprogrammering När vi talar om logikprogrammering rör vi oss återigen inom AI. Det typiska tillämpningsområdet är så kallade expertsystem. Dessa är AI-system som skall imitera en mänsklig experts
kunskap och hjälpa vid beslutsfattandet (det är absolut inte meningen att ersätta en mänsklig expert med dessa system!!!). Tillämpningsområdena för expertsystem varierar vitt från avancerade schackprogram till medicinska diagnossystem, från krigsföring i rymden (det ökända Star Wars-projektet) till diagnosticering av fel i motorcyklar. Det dominerande språket är Prolog. Det som vi förutsätter är att tillämpningsområdet kan beskrivas som en (ofta massiv) samling av fakta, och ett regelsystem angående dessa fakta. Logiken grundar sig i första gradens predikatkalkyl, och den dominerande regeln är modus ponens: Alla människor är dödliga. Sokrates är en människa. Sokrates är dödlig.... eller aningen mera formellt: A -> B (A implicerar B) A ( A är sant) B (... alltså måste B vara sant) Fakta och reglerna ingår i en kunskapsdatabas som man kan ställa frågor till (antingen ja/nej-frågor, eller allmänna frågor): Fakta regler fråga Inferensmaskin (modus ponens) svar
Parallell programmering Aktuellt vid särskilt beräkningstunga tillämpningar, ex. långtidsväderprognoser, vindtunnelturbulensanalyser, neurala nätverk, genetiska analyser,... I stället för en processor har vi här flera processorer som arbetar parallellt med en och samma uppgift. Utmaningen för programmeraren blir att dela arbetet på ett meningsfullt och effektivt sätt på dessa processorer. Utmaningen för den som designar arkitekturen blir bl. a. minnesaccess - hur får alla dessa processorer accessera minnet - och kommunikationen processorerna emellan (ska alla processorer kunna kommunicera med alla andra, eller ska vi ex. ha en processor som är ägnad åt att sköta kommunikationen?): Ex. YOURLIST = LIST[1..200000] : private NAME : public... PARALLEL[1..100] SEQSEARCH(YOURLIST, NAME, FOUND, INTERRUPT) IF FOUND, SEND INTERRUPT END PARALLEL
Objektorienterad programmering (OOP) Det centrala begreppet är objektet - algoritmerna blir något sekundärt. Enligt denna programmeringsfilosofi är det traditionella, imperativa programmeringssättet något onaturligt för människan, och därför ofta så svårt att lära sig. Förespråkarna för OOP säger att människan inte strukturerar sin värld i form av processer, utan i form av objekt. När vi ex. går in i ett bibliotek så ser vi först människor, bokhyllor och böcker, inte processer som utlåning, returnering, reservation etc. OOP försöker modellera detta sätt att se på saker och ting. Objektet blir härvid det primära, processerna något sekundärt, metoder som ett objekt (eller en instans av ett objekt) kan genomföra - eller låta bli att genomföra. Ex. på traditionell, imperativ design: Ex. anta att vi skall designa ett nytt datasystem för ett bibliotek. Det första vi frågar oss är vilka processer som äger rum i biblioteket, dvs. vilka processer som skall ingå i det nya systemet. Vi kommer kanske fram till följande lista: att låna ett exemplar av en bok att returnera ett exemplar att reservera en bok (obs! inte ett exemplar - varför?) att skicka kravbrev på ett exemplar att registrera en ny kund att söka information om en bok Alla dessa punkter är processer - att låna, att returnera, att reservera. Inom denna världsbild består den aktiva världen, det som vårt nya datasystem
skall reflektera, av processer. De som påverkas av processerna, kunderna, exemplaren, kravbreven, böckerna, ses som objekt, data som påverkas av processerna. Processerna är det primära, data något sekundärt. Detta har varit det traditionella sättet att systemera och programmera, och de traditionella imperativa programmeringsspråken har understött det. Inom OOP gör vi precis tvärtom: Objekten - de gamla data - är de primära, processer som hanterar dessa objekt blir nu metoder som (instanser av) dessa objekt kan välja att utföra. Vår analys av biblioteket kommer nu att reflektera detta synsätt: Ex. objektet Bibliotekskund kan ha följande attribut (egenskaper): - kundnummer - namn - adress (så vi vet vart skicka kravbreven) - en lista över innestående lån * att reservera en bok * att låna ett exemplar * att returnera ett exemplar * att lista de innestående lånen * att betala böten * att utföra en sökning Jag har markerat med ' -'de egenskaper som beskriver objektet i fråga, och med ' *'de egenskaper som är processer som objektet kan utföra. I Java skulle vi tala om variabler respektive metoder. Båda dessa kan räknas som attribut; de beskriver objektet i fråga. Terminologin inom OOP är inte enhetlig. Jag skall i fortsättningen kalla dessa för attribut respektive processer i allmänhet, variabler respektive metoder i Java i synnerhet.
Objektet Bok skulle kunna ha följande attribut och processer: - ISBN-numret - namnet - författarens namn - förlaget - tryckort - tryckår - antalet exemplar - reservationslista (en FIFO-kö) * att skriva ut första människan på reservationslistan * att sätta till en ny reservation i slutet av kön Ett exemplar av en bok skulle ärva vissa av egenskaperna hos en bok: - ISBN-numret - namnet - författarens namn - förlaget - förlagsortet - tryckåret Därutöver skulle varje exemplar tillhörande en bok ha vissa egna attribut: - exemplarnummer * kan utlånas - till vem? * kan förstöras/försvinna * kan returneras Vi skall diskutera begreppet arv (nedärvning) senare; exemplet ovan skall exemplifiera OOP helt allmänt. Att börja koda ett dylikt bibliotekssystem skulle kräva rätt så avancerade kunskaper i Java och databashantering, så vi skall designa enklare exempel först. Efter att du har tagit kursen i Databaser torde du kunna koda exemplet ovan utan större problem.
EGENSKAPER HOS OOP - ALLMÄN PRESENTATION De egenskaper som vi skall diskutera nedan gäller allmänt för objektorienterad design. Vissa av dessa principer kan vi försöka tillämpa även när vi jobbar med traditionella, imperativa programmeringsspråk som Pascal, Modula-2 eller C. De språk som gör anspråk på att vara speciellt objektorienterade, ex. Beta, Eiffel, C++ eller Java, har implementerat (konkretiserat, förverkligat) dessa egenskaper på olika sätt. Här är det alltså frågan om allmänna principer som du kan vänta dig att hitta implementerade på olika sätt i olika objektorienterade språk. OOP Java C++ Beta Eiffel... Den objektorienterade världssynen som vi beskrev ovan är gemensam för alla dessa språk: det centrala är objektet medan processerna är egenskaper hos enskilda objekt, något som dessa kan utföra. Härtill kommer det tre centrala principer: DATAINKAPSLING (data incapsulation) ARV/NEDÄRVNING (inheritance) FLERFORMIGHET (polymorphism) Dessa tre skall förklaras nedan. (Egentligen exemplifierar figuren ovan redan dessa principer: de olika programmeringsmetoderna är inkapslade i dessa olika språk; alla ärver de vissa principer från OOP, men de implementerar dessa på olika sätt.)
DATAINKAPSLING: Datainkapsling innebär att man "kapslar in" data och metoder som hör ihop (tänk på hur de olika ingredienserna är inkapslade i medicinkapsyler!). Idén är att sammanhörande data skall kunna hanteras som en enhet, och att utomstående programdelar inte kommer åt dessa delar separat om vi inte uttryckligen önskar det. Många OOP-språk - inklusive Java - har ytterst sofistikerade hierarkier på dylika "kapslar", och ytterst mångskiftande regler på hur och varifrån deras olika delar kan accesseras - eller inte accesseras. I Java har vi ex. paket, klasser, objekt, instanser, metoder osv. som alla fungerar som helheter bestående av separata delar. Ofta är det helheten vi vill arbeta med, i vissa situationer delarna. I våra Java-exempel brukar vi ex. importera paketet javagently för att komma åt den extremt nyttiga Text-klassen, som i sin tur består av flera användbara metoder för att läsa in och skriva ut olika sorters värden, eller hjälpa oss med filhantering. Vi behöver bara känna till namnet på metoden och hur vi skall anropa den, och så utförs metoden för oss. Det som vi däremot inte behöver känna till är hur metoden är implementerad, vilka kommandon den utför. Det ena enda som intresserar oss är resultatet. Det är detta som förstås med inkapsling. javagently Text Text.readInt Text.readDouble Text.readChar Text.readString Text.writeDouble... Om vi tänker på biblioteksexemplet ovan, så skulle både kunden, boken och exemplaret vara inkapslade som objekt: inne i detta objekt finns alla de olika attributerna, både de "vanliga" och processerna, som tillhör just detta objekt. I Java skulle vi kalla ett dylikt objekt för en klass (ex. kund) och de olika verkliga kunderna för instanser av denna klass.
ARV/NEDÄRVNING (INHERITANCE) Typiskt för OOP är att de olika objekten (eller klasserna, om vi vill använda Javas terminologi) utgör en hierarki. Ex. Människa Personalmedlem Studerande Lektor Professor DI IB Vi ser av figuren ovan att vi har två sorters människor i vårt system - personalmedlemmar och studerande. Personalmedlemmarna delar sig vidare i lektorer och professorer, och de studerande i DI (blivande diplomingengörer) och IB (blivande filosofie magistrar). I denna ytterst förenklade värld kan vi dock studera begreppet arv riktigt bra: de egenskaper som är gemensamma för alla människorna definieras hos objektet Människa. Både personalmedlemmar och studerande är människor (även om det inte alltid känns så...) och de ärver alla de egenskaper som är gemensamma för alla människorna, dvs. alla de egenskaper, attribut och processer, som är deklarerade för objektet Människa. Men: det finns egenskaper hos personalmedlemmar, ex. titel, undervisningsskyldighet och löneklass, som ingalunda gäller för alla människor. Dessa deklareras separat för klassen Personalmedlem. På motsvarande sätt, det finns egenskaper som är specifika för de studerande, som ex. matrikelnummer och en lista över avklarade kurser. Dessa deklareras separat för klassen Studerande. Vidare indelas klassen Personalmedlem i lektorer och professorer. Dessa ärver alla de egenskaper som gäller för personalmedlemmar (och därvia människor), men kan deklarera sina egna attribut; för professorsklassen kommer det ex. massor av administrativa
skyldigheter och ledning av forskningsprojekt, medan lektorerna kanske utför olika sorters institutionsarbeten. När det gäller de studerande så är kraven på DI-studerande och IB-linjen olika, och dessa skall deklareras separat för dessa objekt: Ex. Människa - namn - personnummer - adress Personalmedlem Studerande - institution - matrikelnummer - löneklass - STURE-rapport - undervisningsskyldighet Lektor Professor DI IB - institutionsarbeten - forskningsprojekt - krav - krav på på DI Fil. Mag. Om vi nu skapar en instans av objektet (klassen) DI, så ska denna blivande DI ha följande egenskaper: - namn (ärvs från Människa) - personnummer (ärvs från Människa) - adress (ärvs från Människa) - matrikelnummer (ärvs från Studerande) - STURE-rapport (ärvs från Studerande) - krav på DI (ärvs från DI) I början är dessa attribut tomma. Efter att vi har skapat instansen i fråga kan vi börja fylla i namn etc:
- namn (ärvs från Människa) Axel - personnummer (ärvs från Människa) 300682-275J - adress (ärvs från Människa) Tavasthem 13 - matrikelnummer (ärvs från Studerande) 28096 - STURE-rapport (ärvs från Studerande) en lång lista - krav på DI (ärvs från DI) en ännu längre lista För att Axel inte behöver studera ensam kan vi skapa en ny instans av samma klass, Stina: - namn (ärvs från Människa) Stina - personnummer (ärvs från Människa) 010581-253Y - adress (ärvs från Människa) Tavasthem 15 - matrikelnummer (ärvs från Studerande) 28097 - STURE-rapport (ärvs från Studerande) en lång lista - krav på DI (ärvs från DI) en ännu längre lista I allmänt språkbruk skulle vi kunna kalla både Axel och Stina för objekt, eller instanser av objekt. Vill vi lära oss Javas språkbruk kommer vi att kalla både Axel och Stina för instanser av klassen DI. Klassen DI utvidgar klassen Studerande, som i sin tur utvidgar klassen Människa. Klassen DI är en subklass av klassen Studerande som är en subklass av klassen Människa. Klassen Människa är en superklass av klassen Studerande som är en superklass av klassen DI. Du kan också använda termerna delklass och överklass i stället för subklass rspektive superklass. Så användbart som det ofta skulle vara att låta ett objekt ärva egenskaper från två eller flera olika klasser så tillåter Java inte detta! Ex. vi kan inte definiera en klass Lärarstudent som skulle ärva från både Personalmedlem och Studerande.
FLERFORMIGHET (POLYMORPHISM) (Franzén talar om ungefär samma sak under termerna skuggning och överskuggning.) När det gäller olika subklasser till en bestämd superklass, så är det ofta så att alla dessa subklasser har en viss gemensam metod, som ändå tar sig lite olika former beroende på vilken delklass det är frågan om. Ex. både klassen Lektor och klassen Professor kunde ha en metod årsrapport. Denna metod skulle planera årsrapporten för den ifrågavarande personalmedlemmen. Eftersom det dyker upp lite olika sysslor för lektorer och professorer så är det bäst att de båda delklasserna var för sig definierar vad som skall komma med i årsrapporten. För en lektor skulle årsrapporten ta med exempelvis följande punkter: - Vilka kurser lektorn har undervisat - Hur många studieveckor per år lektorn har producerat - Vilka förtroendeuppgifter lektorn har haft - Vilka kurser lektorn själv har gått på - Undervisningsmaterial lektorn har producerat I professorns motsvarande rapport skulle det kunna stå ex. följande: - Vilka forskarkurser professorn har undervisat - Hur många doktorsavhandlingar hon har handlett - Hur många licensiatavhandlingar hon har handlett - Hur många pro gradu/di-avhandlingar hon har handlett - Hur mycket extern finansiering hon har skaffat - Hur många artiklar hon har publicerat - Hur många konferenser hon har hållit föredrag på Uppgiften av metoden skrivarapport skulle vara densamma: att skriva ut denna årsrapport när den behövs. Därför väljer vi att kalla denna metod för skrivarapport, både för klassen Lektor och för klassen Professor. Strukturen hos dessa rapporter varierar dock beroende på tjänstekategori. Det är detta som kallas flerformighet.
Man kan också tänka sig att det fanns en metod med namnet skrivarapport definierad för klassen Personalmedlem. Eftersom det säkert finns många olika delklasser till denna överklass utöver våra lektorer och professorer, så kommer det att finnas bara mycket allmänna saker att skriva ut i denna metod. Vi säger då att metoden skrivarapport väljer sin form beroende av vilket objekt det är som skriver ut sin rapport: om instansen som ska skriva ut sin rapport hör direkt till klassen Personalmedlem, så skrivs det ut bara dessa allmänna saker. Om instansen hör till klassen Lektor, skrivs det ut en lektorsrapport. Om instansen hör till klassen Professor, skrivs det ut en professorsrapport. I dessa två senare fall säger vi att instanserna i klasserna Lektor och Professor överskuggar metoden skrivarapport i klassen Personalmedlem: Ex. Människa - namn - personnummer - adress Personalmedlem Studerande - institution - matrikelnummer - löneklass - STURE-rapport - undervisningsskyldighet * skrivarapport (bara namn etc.) Lektor Professor DI IB - institutionsarbeten - forskningsprojekt - krav - krav * skrivarapport * skrivarapport
Vi kan tänka oss två lektorer, Ragnar och Annamari, och två professorer, Kaj och Karin. Deras rapporter skulle kunna ha följande utseende: instans: Ragnar klass: Lektor - Vilka kurser lektorn har undervisat: 2 * Java I, 2 * Java II, labb I - Hur många studieveckor per år lektorn har producerat: 600? - Vilka förtroendeuppgifter lektorn har haft: (Olika institutionsarbeten, forskningsprojekt) - Vilka kurser lektorn själv har gått på: Avancerad AI, schack för experter (gissar...) - Undervisningsmaterial lektorn har producerat: Utmanade Java-program för lite längre hunna, Superutmanande Java-program för genier instans: Annamari - Vilka kurser lektorn har undervisat: Intro till DT, intro till DT/KTF, DST/KTF, Java- EXFORT, filosofiska utopier, dataetik - Hur många studieveckor per år lektorn har producerat 500? - Vilka förtroendeuppgifter lektorn har haft: sitter på institutionsrådet, ÅA-samarbete - Vilka kurser lektorn själv har gått på Immateriaalioikeudet verkossa, latin IV, Universitetspedagogi - Undervisningsmaterial lektorn har producerat: Enkla Java-program för nybörjare
Våra två professorer, däremot, kunde ha följande rapporter: instans: Kaj instans: Karin klass: Professorer - Vilka forskarkurser professorn har undervisat Advanced verification algorithms Multimedia - Hur många doktorsavhandlingar han har handlett 4 - Hur många licensiatavhandlingar han har handlett 6 - Hur många magisters/di-avhandlingar han har handlett 17 - Hur mycket extern finansiering han har skaffat 50 000 - Hur många artiklar han har publicerat 15 - Hur många konferenser han har hållit föredrag på 4 - Vilka forskarkurser professorn har undervisat Highly advanced verification algorithms Embedded systems - Hur många doktorsavhandlingar hon har handlett 2 - Hur många licensiatavhandlingar hon har handlett 2 - Hur många magisters/di-avhandlingar hon har handlett 14 - Hur mycket extern finansiering hon har skaffat 80 000 - Hur många artiklar hon har publicerat 25 - Hur många konferenser hon har hållit föredrag på 15
Som vi ser av exemplen ovan beror rapportens struktur, dess utformning, på vilken klass instansen som skriver ut sin rapport tillhör: Ragnar och Annamari skriver ut lektorsrapporter medan Kaj och Karin skriver ut professorsrapporter. Rapporternas innehåll varierar naturligtvis beroende på vilken instans det är som skriver ut sin rapport: även om Ragnar och Annamari får liknande tomma blanketter att fylla i, kommer de att skriva olika saker i sina rapporter, för de har hållit och gått på olika kurser. Det som ärvs är strukturen, inte innehållet. Varje instans av en klass ärver variablerna och metoderna av sin klass om vi inte anger annat. Det som varierar med flerformighet är strukturen (det måste anses vara självklart att innehållet varierar). Vi kan ha flera olika metoder med namnet skrivrapport, men de skriver ut olika saker beroende på vilken sorts instans som anropar dem.