Informasjonsteknologi 2 Høst 2025

Når felles egenskaper og metoder flyttes opp i en superklasse, må de andre klassene arve fra den. Da blir de subklasser. De får alt superklassen har, uten at koden skrives flere ganger, og de kan i tillegg ha egne egenskaper og metoder. I UML heter dette generalisering og tegnes med en hul trekant som peker mot superklassen.

De andre alternativene gir ikke en superklasse:

• Abstraksjon betyr å ta med bare det som er viktig for problemet og se bort fra detaljene. Det er en del av all modellering, men det er ikke mekanismen som knytter klassene til en superklasse.
• Polymorfisme betyr at objekter av ulike klasser kan svare på det samme metodekallet på hver sin måte. Den bygger ofte på arv, men er ikke det som realiserer generaliseringen.
• Innkapsling betyr å samle data og metoder i en klasse og skjule de indre detaljene for resten av programmet.

a)

Riktig svar er aggregering. Et fakultet består av studenter, men studentene er ikke avhengige av fakultetet for å finnes. Det er en «har»-relasjon (del–helhet) med løs kobling.

• Generalisering er arv («er en»). En student er ikke et fakultet, og omvendt.
• Komposisjon er en sterk del–helhet-relasjon der delene ikke kan eksistere uten helheten.
• Avhengighet betyr bare at en klasse bruker en annen en kort stund, for eksempel som parameter i en metode. Den sier ingenting om at studenten er en del av fakultetet.

b)

Teksten sier at studentene velger å knytte seg til et fakultet og da blir en del av fakultetet. Det gir to kjennetegn:

1. Del–helhet. Fakultetet er helheten og studentene er delene. Da er det aggregering eller komposisjon, ikke generalisering eller avhengighet.
2. Delene lever uavhengig av helheten. Tilknytningen er valgfri. En student finnes også uten fakultet, kan melde seg ut eller bytte fakultet. Legges fakultetet ned, forsvinner ikke studentene. Ved komposisjon ville studentobjektene blitt slettet sammen med fakultetet, og det passer ikke her.

Derfor er relasjonen aggregering. I klassediagrammet tegnes den som en linje mellom klassene med en hul rombe ved Fakultet (helheten). Multiplisiteten kan skrives som 0..1 ved Fakultet (en student har null eller ett fakultet) og * ved Student (et fakultet har mange studenter).

Løkken går gjennom tallene 1 til 5. For hvert tall legger den først til en farge og så, i den delen som mangler, et dyrenavn. Vi deler det forventede resultatet i par med farge og dyr:

i	i % 2	Farge	Dyr
1	1	Rød	Mus
2	0	Blå	Mus
3	1	Rød	Katt
4	0	Blå	Mus
5	1	Rød	Hund

Fargene stemmer med den ferdige if-setningen. Dyrene må vi bestemme selv: tallet 3 gir «Katt», tallet 5 gir «Hund», og alle andre tall gir «Mus». Et mønster som passer, er at tall som er delelige med 5, gir «Hund», og tall som er delelige med 3, gir «Katt». Den manglende koden settes inn etter ENDIF og før ENDFOR:

FUNCTION beskrivDyr(n):
   SET resultat TO " "
   FOR hvert tall i fra 1 til n
      IF i % 2 EQUAL TO 0
         SET resultat TO resultat + "Blå "
      ELSE
         SET resultat TO resultat + "Rød "
      ENDIF
      IF i % 5 EQUAL TO 0
         SET resultat TO resultat + "Hund "
      ELSE IF i % 3 EQUAL TO 0
         SET resultat TO resultat + "Katt "
      ELSE
         SET resultat TO resultat + "Mus "
      ENDIF
   ENDFOR
   RETURN resultat
ENDFUNCTION
DISPLAY beskrivDyr(5)

Forklaring:

• Hvert dyrenavn slutter med et mellomrom, akkurat som fargene. Da blir ordene skilt fra hverandre i resultatet.
• Bare ett dyr skal legges til per tall. Derfor brukes én IF … ELSE IF … ELSE-setning og ikke tre separate IF-setninger. Da blir «Mus» bare lagt til når ingen av de andre betingelsene er sanne.
• Rekkefølgen på testene betyr noe hvis n er større. Tallet 15 er delelig med både 3 og 5. Med testen for 5 først blir det «Hund».

Det forventede resultatet sier bare hva som skal skje for tallene 1 til 5, så andre løsninger er også riktige. Man kan for eksempel teste i EQUAL TO 3 og i EQUAL TO 5 i stedet for å bruke %.

a)

Algoritmen tar et firesifret tall og lager to nye tall av de samme sifrene: det største tallet (sifrene sortert synkende) og det minste tallet (sifrene sortert stigende). Så trekker den det minste fra det største. Differansen er det nye tallet, og hele prosessen starter på nytt med det. Hvert steg vises på skjermen.

Løkken fortsetter så lenge tallet endrer seg. Når differansen blir lik tallet den ble regnet ut fra, vil alle senere steg gi det samme tallet. Da stopper algoritmen og returnerer tallet.

Med startverdien 3142 blir stegene:

Steg	Tall	Synkende	Stigende	Differanse
1	3142	4321	1234	3087
2	3087	8730	0378	8352
3	8352	8532	2358	6174
4	6174	7641	1467	6174

I steg 4 gir 6174 seg selv igjen, og algoritmen stopper. Tallet 6174 kalles Kaprekars konstant. Alle firesifrede tall der ikke alle sifrene er like, ender på 6174 etter høyst sju steg.

To ting er verdt å merke seg:

• Sifrene må regnes som fire. Differansen kan få færre enn fire sifre, for eksempel $2111-1112=999$. Da må tallet regnes som 0999, med en null foran, ellers virker ikke algoritmen. Det er derfor stigende sortering av 3087 blir 0378 i eksempelet.
• Tall med fire like sifre. For 1111, 2222 og så videre er det største og det minste tallet like, så differansen blir 0. Da gir neste steg også 0, og algoritmen stopper på 0 i stedet for 6174. Oppgaven sier ikke at sifrene må være ulike, så et program bør ta høyde for dette.

a)

Oversikt. Diagrammet er et UML-klassediagram med to klasser. Hver boks har tre felt: klassenavnet øverst, attributtene med datatype i midten og metodene nederst. Etter kolon står datatypen til et attributt eller returverdien til en metode.

Relasjonen. Linjen mellom klassene har en fylt rombe ved Digitalklokke. Det betyr komposisjon: Digitalklokke er helheten, og Tallviser er en del av den. Attributtene timer: Tallviser og minutter: Tallviser viser at klokka har to slike deler. Det er komposisjon og ikke aggregering fordi tallviserne lages av klokka og ikke har noen mening alene. Slettes klokka, forsvinner tallviserne med den.

Tallviser representerer en teller som teller fra 0 og opp til en øvre grense, og så begynner på nytt. Den samme klassen brukes både til timer og til minutter. Forskjellen er bare den øvre grensen.

• verdi: int er tallet telleren viser nå, for eksempel 7 timer eller 45 minutter.
• maks_verdi: int er grensen der telleren går rundt til 0 igjen: 24 for timer og 60 for minutter. Gyldige verdier er da 0–23 og 0–59. Man kan også tolke maks_verdi som den største tillatte verdien, altså 23 og 59. Det viktige er at valget brukes likt i hele klassen.
• set_verdi(int) stiller telleren til en bestemt verdi. Metoden bør kontrollere at verdien er gyldig, altså mellom 0 og maks_verdi − 1.
• øk() øker verdi med 1. Når verdien når maks_verdi, settes den til 0. Det er praktisk om metoden også sier fra når telleren har gått rundt, slik at klokka vet at timene skal økes.
• vis_verdi(): str returnerer verdien som tekst med to sifre, for eksempel "07".

Digitalklokke representerer selve klokka, med timer og minutter.

• timer: Tallviser og minutter: Tallviser er de to tellerne klokka består av.
• set_tid(int, int) stiller klokka. Den tar inn timer og minutter og kaller set_verdi på hver av tallviserne.
• tid_går() lar ett minutt gå. Den kaller øk() på minutter. Går minuttene rundt fra 59 til 0, kalles også øk() på timer. Etter 23:59 blir tiden dermed 00:00.
• vis_tid(): str returnerer tiden som tekst på formen "TT:MM", for eksempel "09:05", ved å sette sammen vis_verdi() fra de to tallviserne med et kolon imellom.

Ansvarsfordeling. Digitalklokke vet ikke selv hvordan det telles. Den overlater det til tallviserne og samordner dem bare. Det er et eksempel på innkapsling: detaljene om telling og grenser ligger i Tallviser, og klokka bruker bare metodene. Diagrammet viser ikke synlighet (+/-) eller konstruktører. Attributtene bør være private, og Tallviser trenger en konstruktør som tar inn maks_verdi.

Svaret nedenfor er et eksempel. Kandidaten kan velge et annet dilemma, så lenge det henger sammen med Annas situasjon og drøftes fra flere sider.

Dilemmaet. Bør Anna fortsette å bruke chatboten som samtalepartner? På den ene siden gir den henne noen å snakke med når hun ikke tør å gå til foreldrene eller helsesykepleieren. På den andre siden kan den gi dårlige råd, erstatte hjelp fra mennesker, og den kan lagre og selge det hun forteller. Det finnes gode grunner for begge valgene, og det er derfor et dilemma.

Argumenter for å bruke chatboten:

• Lav terskel. Anna åpner seg lettere for en maskin fordi hun ikke føler seg dømt. Å sette ord på følelsene kan i seg selv lette. Uten chatboten er det mulig at hun ikke snakker med noen i det hele tatt.
• Tilgjengelighet. Chatboten er gratis og svarer med en gang, også sent på kvelden. Helsetjenester har ofte ventetid og er bare åpne på dagtid.
• Autonomi. Anna er 17 år og har rett til å bestemme mye selv. Hun velger selv hvem hun vil snakke med og når.
• Konsekvenser. Ut fra en konsekvensetisk vurdering er det godt hvis chatboten gjør at Anna føler seg mindre ensom, og kanskje etter hvert tør å søke hjelp hos et menneske.

Argumenter mot å bruke chatboten slik:

• Feil og upassende råd. En språkmodell forstår ikke Anna. Den lager svar som høres riktige ut, men som kan være feil. Hvis Anna får det verre eller får vonde tanker, kan et dårlig svar få alvorlige konsekvenser. Chatboten kan ikke vurdere fare eller ringe etter hjelp slik en helsesykepleier kan.
• Ansvar. En helsesykepleier har taushetsplikt, faglig ansvar og plikt til å handle. Det er uklart hvem som har ansvaret når en app gir dårlige råd: selskapet, utviklerne eller Anna selv. Appen lover å være en «venn», men tar ikke ansvaret en venn eller en fagperson har.
• Tillit og avhengighet. Chatboten svarer alltid raskt og vennlig. Det kan gi Anna tillit til noe som ikke fortjener den, og gjøre det enda vanskeligere å snakke med ekte mennesker. Da kan ensomheten øke i stedet for å minke. Det er også et spørsmål om ærlighet: Anna må forstå at hun snakker med en maskin, og at vennligheten er laget for at hun skal fortsette å bruke appen.
• Personvern. Det Anna forteller, er helseopplysninger. De hører til de særlige kategoriene av personopplysninger i GDPR og har ekstra sterk beskyttelse. Å selge dem videre krever uttrykkelig samtykke, og et samtykke som er gjemt i vilkår Anna ikke har lest, er ikke et reelt samtykke. Opplysningene kan havne hos annonsører eller andre selskaper, bli brukt til å profilere henne, eller lekke ved et datainnbrudd. Skaden kan ikke gjøres om. Gratis-appen kan være betalt med dataene hennes.
• Pliktetikk. Selskapet har en plikt til ikke å utnytte en sårbar person. Uansett hvilke fordeler appen gir, er det galt å tjene penger på å selge det en nedstemt 17-åring betror seg om.

Min vurdering. Chatboten hjelper Anna nå, og det er ikke riktig å si at hun gjorde noe galt da hun begynte å bruke den. Men akkurat denne appen gir feil råd og kan selge dataene hennes, og da veier ulempene tyngst. Anna bør slutte å fortelle personlige ting til denne appen, se om hun kan få slettet det hun allerede har delt, og ta skrittet mot et menneske hun stoler på: helsesykepleieren, fastlegen, en voksen i familien eller en anonym chattetjeneste som drives av en seriøs organisasjon med fagfolk. Hun kan gjerne bruke det hun har skrevet til chatboten til å finne ord på hvordan hun har det.

KI kan ha en rolle i psykisk helsehjelp til ungdom, men som et supplement og ikke som en erstatning for mennesker. Da må noen krav være oppfylt: det må være tydelig at man snakker med en maskin, tjenesten må være utviklet og fulgt opp av helsefaglige personer, den må henvise videre til ekte hjelp når samtalen tyder på alvorlige problemer, og den må behandle opplysningene etter GDPR, med dataminimering, formålsbegrensning og uten salg av data. Ansvaret for at tjenesten er trygg, må ligge hos dem som lager og tilbyr den, ikke hos en 17-åring som har det vondt.