Forrige kapitel Forsiden  Næste kapitel
[ Undervisningsministeriets logo ]

G. Datamatikeruddannelsen som eksempel på en kort videregående uddannelse





G.1 Generelle kommentarer

Datamatikeruddannelsen1 er en kort videregående professionsorienteret uddannelse, der i løbet af de to et kvart år, uddannelsen er normeret til, sigter mod at uddanne softwareudviklere. Ved softwareudvikling spiller matematik en rolle på mange niveauer, og således også i datamatikeruddannelsen.

Der er følgeligt mange områder i datamatikeruddannelsen, hvor matematiske kompetencer anvendes og udvikles. Et programmeringssprog er et formelt sprog med en veldefineret syntaks og til dels semantik, og alene derfor er det uundgåeligt, at matematik dukker op i forskellige sammenhænge, og enkelte matematiske emner er da også eksplicit nævnt i fagbilaget til bekendtgørelsen for datamatikeruddannelsen.

G.2 Matematiske kompetencer i datamatikeruddannelsen

G.2.1 Tankegangskompetence

Karakteristik

På datamatikeruddannelsen består dennne kompetence i at være klar over hvilke slags spørgsmål, som er karakteristiske for matematik, i selv at kunne stille sådanne spørgsmål, og i at have blik for hvilke typer af svar, som kan forventes.

Kommentar

Denne kompetence er ikke central i datamatikeruddannelsen, men i situationer, hvor genstandsområdet for konkrete programmeringsopgaver er af matematisk natur (for eksempel programmering af en funktion, der kan foretage primtalsfaktorisering af et heltal eller programmering af eksponential- og/eller logaritmefunktioner), kan kompetencen med fordel opøves. I sådanne konkrete situationer er det i øvrigt lettere at motivere udforskningen af egenskaber ved de pågældende matematiske begreber.

Eksemplificering

Hvad angår det at kunne stille spørgsmål og have blik for hvilke typer af svar, som kan forventes, kan det for eksempel dreje sig om programmering af en funktion, der kan afgøre, om et tal er et primtal. Det egentlige mål med øvelsen er konstruktion af en funktion med en ikke-triviel løkke; primtals-domænet er blot et (traditionelt) eksempel.

Eksempel 1:

boolean isPrime (n)//metoden skal afgøre, om n er et primtal
{
  for (i = 2; i < ?; i++)
    if (i går op i n)
      return false;
  return true;
}

De matematiske spørgsmål, man her kan stille - og som relaterer sig til antallet af iterationer og dermed algoritmens effektivitet - er fx:

  • Hvor langt skal man gå i ovenstående test? - helt op til n, eller kan der stoppes tidligere?

Spørgsmål af den karakter sætter gang i en tankeproces omkring egenskaber ved tal i relation til primtalsbegrebet, og gennem processen udvikler eleven (forhåbentlig) en analytisk evne, som er essentiel og langt mere vidtgående end det konkrete matematiske domæne (i dette tilfælde primtal).

Eksempel 2: Kompeksitetsovervejelser vedrørende eksempelvis søgelængder, sorteringsalgoritmer osv. Herved kræves forståelse for størrelsesordener og de dramatiske konsekvenser af deres forskelligheder (lineære, binære/ logaritmiske, eksponentielle osv.).

De matematiske spørgsmål, man her kan stille, er fx:

  • "Hvorfor er binær søgning mere effektiv end lineær søgning?"

  • "Hvis n 10000, hvor længe skal man da i værst tænkelige tilfælde søge ved lineær/binær søgning?"

G.2.2 Problembehandlingskompetence

Karakteristik

På datamatikeruddannelsen består dennne kompetence i at kunne løse både "åbne" og "lukkede" matematiske problemer, primært af "anvendt" karakter.

Kommentar

I forhold til grundkarakteristikken i kapitel 4 trænes datamatikeren ikke i at kunne detektere, formulere, afgrænse og præcisere matematiske problemer. Derimod stilles en datamatiker over for en række matematiske problemstillinger, som skal løses; dette sker typisk for at blive fortrolig med og få dybere indsigt i et bestemt datamatisk fagområde.

Eksemplificering

Problemfelterne kan fx være

  • effektivitetsovervejelser og -beregninger, som foretages for at få dybere indsigt i kvantitative egenskaber ved algoritmer og datastrukturer.

  • kapacitetsberegninger, som foretages for at få dybere indsigt i naturen af forskellige lagrings- og kommunikationsmedier.

  • korrekthedsargumenter, som foretages for at få dybere indsigt i kvalitative egenskaber ved algoritmer og datastrukturer.

Mere konkret kan det dreje sig om problemer som de følgende, der er repræsentative for en række tilsvarende problemer specielt inden for algoritmik, men også inden for datakommunikation m.m.

  • "Hvor mange elementer kan der maksimalt lagres i et B -træ af orden 6?"
       
    Her forventes det, at den studerende kan anvende sin viden om eksponentialfunktioner i kombination med kendskabet til opbygningen af B -træer til at besvare spørgsmålet.

  • "Hvad er en øvre grænse for antal ombytninger i udvalgssortering?"
       
    Her forventes det, at eleven kan anvende sine grundlæggende kompetencer til at tælle i forbindelse med kendskabet til principper for algoritmers udførelse.

  • "Hvad er en øvre grænse for antal sammenligninger i binær søgning?"
      
    Som foregående.

  • "Hvor mange effektive datapakkebits kan der sendes på en given pakkefordelt kommunikationslinie, herunder hvor stor en procentdel af båndbredden bruges til adminstration?"
       
    Her forventes det, at eleven kan kombinere sin viden om principper for og teknikker til kommunikation af data med grundlæggende kompetencer inden for aritmetik, specielt procent- og brøkregning.

  • "Virker algoritme X korrekt (dvs. i overensstemmelse med specifikationen) for input Y?"
      
    Her forventes det, at eleven kan kombinere en (mere generel) ræsonnementskompetence med kendskabet til principper for algoritmers semantik (herunder udførelse) til at argumentere for en given algoritmes korrekthed for et givet input.

  • "Bevis korrektheden af følgende rekursive algoritme. . . "
       
    Som foregående, men da der er tale om en rekursiv algoritme, skal specielt ræsonnementskompetencen, anvendt i forbindelse med induktionsbeviser, mere eksplicit på banen.

G.2.3 Modelleringskompetence

Karakteristik

På datamatikeruddannelsen består dennne kompetence i at kunne analysere grundlaget for og egenskaberne ved foreliggende modeller og at kunne bedømme deres rækkevidde og holdbarhed. Hertil hører at kunne "afmatematisere" (træk ved) foreliggende matematiske modeller, dvs. at kunne afkode og fortolke modelelementer og -resultater i forhold til det felt eller den situation som er modelleret. På den anden side består kompetencen i at kunne udføre aktiv modelbygning i en given sammenhæng, dvs. at bringe matematik i spil og anvendelse til behandling af anliggender uden for matematikken selv.

Kommentar

Generelt omhandler softwareudvikling at transformere et behov udtrykt i menneskesprog til et edb-program udtrykt i matematisk sprog (operationer i det binære talsystem). Denne transformation er abstrakt og omhandler opbygning af modeller, der via mapning bliver mere og mere matematiske. I forhold til datamatikeruddannelsen er modelleringskompetence således en central matematisk kompetence.

Nogle har forsøgt at gøre systemudvikling til en rent matematisk disciplin ("ingeniørvinklen"), hvor de indledende dele af modelleringsprocessen ikke spiller nogen væsentlig rolle, men det har vist sig, at dette ikke er muligt. Årsagen er, at der er mennesker involveret, såvel i processen, men også direkte i resultatet, idet ændringer i organisation, adfærd og kultur generelt også er en del af produktet.

Eksemplificering

Følgende eksempel kan illustrere det at kunne analysere grundlaget for og egenskaberne ved foreliggende modeller, og at kunne bedømme deres rækkevidde og holdbarhed:

  • Når man i designfasen af softwareudvikling har lavet en model (eksempelvis et databasedesign udtrykt i den relationelle model, som angiver, hvilke tabeller med attributter og domæner, der er brug for, samt sammenhængene mellem disse), og bestemt, hvorledes de nødvendige transaktioner (forespørgsler) skal udføres, skal der ske en mapning til et konkret databasesystem. For at kunne gøre dette skal man være i stand til at analysere grundlaget for og egenskaberne ved de to modeller, og man skal kunne bedømme deres rækkevidde og holdbarhed. Man skal kunne forstå, at eksempelvis domænebegrebet ikke umiddelbart kan realiseres i et databasesystem via typebegrebet, da et domæne potentielt har en uendelig værdimængde, mens en type har en endelig værdimængde. Og man skal kunne finde en løsning herpå.

Udarbejdelse af et databasedesign er et eksempel (blandt mange) på aktiv modelbygning, som i forhold til dette prototypiske eksempel kan karakteriseres som bestående af elementerne

  • Strukturering: Hvilke tabeller og egenskaber og sammenhænge skal indgå?

  • Matematisering og Behandling: specifikation af hvorledes transaktioner skal udføres, udtrykt i den relationelle algebra.

  • Validering: Er designet hensigtsmæssigt? Dette undersøges ved at checke normalformerne.

  • Kritisk analyse: Understøtter designet performancekravene og transaktionsbehovene?

  • Kommunikation: Modellen skal være i overensstemmelse med analysemodellen og skal kunne realiseres på den valgte teknologiske platform - dette kræver, at den kan kommunikeres til de ansvarlige for disse aktiviteter.

  • Overblik og styring: Er nødvendig for at kunne overholde tidsmæssige deadlines (projektstyring og projektledelse er derfor væsentlige emner på datamatikeruddannelsen).

Fra investeringsteorien, der er et af de områder, datamatikere ofte arbejder i, optræder spørgsmål som:

  • "Hvad vil du helst have - 10000 kr. nu eller 500 kr./måned i 3 år?"

  • "Er det bedst at investere i en ny eller brugt bil?"

Besvarelse af disse spørgsmål løses ved hjælp af eksisterende matematiske modeller i skikkelse af formler (eksempelvis nutidsværdiberegninger). Eleverne skal kunne vælge mellem de mange tilgængelige formler, hvilket indebærer, at de skal afkode og fortolke de indgående elementer i forhold til den konkrete situation. Modelleringskompetence udvikles således her i tæt samspil med symbol- og formalismekompetence.

G.2.4 Ræsonnementskompetence

Karakteristik

På datamatikeruddannelsen består dennne kompetence på den ene side i at kunne følge og bedømme et matematisk ræsonnement, dvs. en kæde af argumenter fremsat af andre på skrift eller i tale til støtte for en påstand, herunder at forstå den logiske betydning af et modeksempel.

På den anden side består kompetencen i at kunne udtænke og gennemføre informelle og formelle ræsonnementer (på basis af intuition), herunder omforme heuristiske ræsonnementer til egentlige (gyldige) beviser.

Kommentar

Her er der heller ikke tale om en kernekompetence for datamatikere, men der er dog eksempler inden for visse områder af datamatikken (områder som traditionelt behandles relativt overfladisk på datamatikeruddannelsen).

Eksemplificering

Hvad angår det at kunne følge og bedømme et matematisk ræsonnement, kan det fx komme til udtryk i forbindelse med analyse af en algoritmes effektivitet som følger:

Eksempel 1: Binær søgning nævnt ovenfor: bestemmelse af tidskompleksiteten.

Uformelt ræsonnement: der sker en halvering hver gang.

Lidt mere formelt ræsonnement: forsøge at opstille (og løse) en ligning, der, på grundlag af det uformelle ræsonnement, forbinder antallet af objekter der skal søges i blandt (n), med antallet af skridt (x) søgningen omfatter:

2x=n Üþ x log2n

Et andet eksempel er anvendelse af standardiserede bevisteknikker som fx induktionsbeviser, som spiller en central rolle i flere forskellige sammenhænge inden for datamatikken.

Eksempel 2:  Induktionsbevis på simple eksempler, som bevis for

1+2+...+ n=1/2n(n+1)

Et tredie eksempel er inden for matematisk logik (propositions- og prædikatkalkule).

Eksempel 3: Logiske udtryk i programmering

if (not a or not b) if (not a and not b) if (not (a and b))
{

..

}

{

..

}

{

..

}

Det "formelle ræsonnement" vil typisk være at opskrive sandhedstabeller for de forskellige logiske udtryk. Ved hjælp af eksempler (modeksempel) kan man indse, at not (a and b) og not a and not b ikke er det samme.

Hvad angår det at kunne udtænke og gennemføre informelle og formelle ræsonnementer (på basis af intuition), herunder omforme heuristiske ræsonnementer til egentlige (gyldige) beviser, kan det fx dreje sig om analyse af inddata (eksempel 4) eller udledning af matematiske resultater, som at finde et lukket udtryk for summen 1+2+...+ n (eksempel 5).

Eksempel 4: Tilstandsdiagrammer:

Tilstands-/overgangsdiagram for simpel lommeregner (kun heltal, samt de fire regneoperatorer har samme prioritet). Et færdigt resultat vises i .figur G.1, men inden da skal man igennem uformelle overvejelser, som begrunder overgangene, samt påvise, at diagrammet er udtømmende (beskriver alle indtastningsmuligheder på den simple lommeregner).

[Billede: Her ses figur G1, som viser tilstands-/overgangsdiagram for simpel lommeregner (kun heltal; desuden har de fire regneoperatorer her samme prioritet).]

Figur G.1
Tilstands-/overgangsdiagram for simpel lommeregner (kun heltal; desuden har de fire regneoperatorer her samme prioritet).

Eksempel 5: Uformelt ræsonnement på følgende:

Bestem 1+2+...+ n.
Prøv at lægge første og sidste tal sammen. Hvad giver det?
Tag derefter det andet tal og det næstsidste tal.

Problemer hvis n er ulige? Hvis n=1?

Når man er kommet gennem disse uformelle ræsonnementer, vil det være naturligt at prøve at lave et formelt ræsonnement.

Anvendelse eller optakt til ovenstående sum kunne være:

for (i = 0; i < n; i++)
   for (j = 0; j < i; j++)
      ..

Hvor mange gennemløb?
Tidskompleksitet: O(n)?,O(n2)?

G.2.5 Repræsentationskompetence

Karakteristik

Denne kompetence består dels i at kunne forstå (dvs. afkode, fortolke og skelne mellem) og betjene sig af forskellige slags repræsentationer af matematiske objekter, fænomener, problemer eller situationer (herunder symbolske, specielt algebraiske, visuelle, geometriske, grafiske, diagrammatiske, tabelmæssige eller verbale repræsentationer, men også konkrete repræsentationer ved materielle objekter), dels i at kunne forstå de indbyrdes forbindelser mellem forskellige repræsentationsformer for det samme sagsforhold og have kendskab til deres styrker og svagheder, herunder informationstab og -tilvækst, dels i at kunne vælge blandt og oversætte imellem forskellige repræsentationsformer for et givet sagsforhold, alt efter situation og formål.

Kommentar

Karakterstikken her er uafgrænset i forhold til grundkarakteristikken i kapitel 4, hvilket kan tages som udtryk for, at repræsentationskompetence har en central placering i datamatikeruddannelsen. Valg af (matematisk) repræsentationsform, vurdering af alternativer og konvertering imellem forskellige repræsentationsformer er således meget centralt for datamatikere.

Eksemplificering

Vedrørende det at kunne forstå og betjene sig af forskellige slags repræsentationer af matematiske objekter, fænomener, problemer eller situationer kan peges på følgende forhold, som er repræsentative for en række tilsvarende eksempler. De har alle en matematisk kerne (typisk involverende logik, mængdelære og diskret matematik), selv om de optræder i datamatisk iklædning:

Sondringen mellem specifikation (hvad) og implementation (hvordan) af abstrakte datatyper: Her forventes det, at eleven kender en række fundamentale abstrakte typer (stak, kø, prioritetskø, liste, mængde, multimængde, map) samt alternative implementationer af disse (array, kædet liste, cirkulær liste, bunke, søgetræ, hashtabel).

Regneudtryk, udtrykstræer og præcedensregler: Her forventes det, at eleven kender syntaks og semantik for forskellige typer af udtryk, herunder pre.x, infix- og postfix-udtryk, samt teknikker til beskrivelse heraf i form af udtrykstræer og præcedensgrammatikker og evaluering ved hjælp af trægennemløb (pre-, in- og postorder-gennemløb).

Talsystemer og konvertering mellem disse: Her forventes det, at eleven kender til principet for positionstalsystemer og specielt er fortrolig med 2-, 8-, 10- og 16-talsystemet, som er de fremtrædende talsystemer inden for datamatikken. Specielt skal eleven kunne konvertere frem og tilbage mellem disse talsystemer.

Det at kunne forstå de indbyrdes forbindelser mellem forskellige repræsentationsformer for det samme sagsforhold og have kendskab til deres styrker og svagheder, herunder informationstab og -tilvækst drejer sig især om relationen mellem specifikation og implementation af såvel algoritmer som datastrukturer - også de af en matematisk natur - for eksempel

Specifikation og implementation af datatyper og beregninger: Her forventes det, at eleven kender teknikker til abstrakt (det vil sige implementationsuafhængig) specifikation af datatyper og beregninger fx i termer af funktionelle specifikationer ved hjælp af såkaldte præ- og postbetingelser.

Typehierarkier: Her forventes det, at eleven kender til principper for afkobling af programkomponenter ved at programmere op mod abstrakte datatyper (interfaces eller abstrakte klasser), hvor samme abstrakte type kan dække over vilkårligt mange, og op til den fælles abstrakte type, vilkårligt forskellige konkrete datatyper. I den forbindelse (specielt i forbindelse med simulering af "genericity") kan der opstå behov for såkaldt "downcast" for at genskabe information om objektets konkrete datatype.

Formelle sprogklasser og automater: Her forventes det, at eleven kender til forskellige klasser af formelle sprog (specielt regulære og kontekstfri sprog) samt tilhørende grammatikker og automater, der kan henholdsvis generere og genkende disse sprog. Specielt forventes eleven at være fortrolig med forskellen på de forskellige sprogklasser og de tilhørende automater (reguære og kontekstfri sprog versus endelige automater og "push-down" automater).

Hvad angår det at kunne vælge blandt og oversætte imellem forskellige repræsentationsformer for et givet sagsforhold, alt efter situation og formål, drejer det sig især om evnen til at kunne beskrive systemer på forskellige abstraktionsniveauer og efter forskellige perspektiver. Der er utallige eksempler på dette inden for datamatik, men her skal blot nævnes tre områder, hvor denne del af repræsentationskompetencen er essentiel:

Systembeskrivelse: Her forventes det, at eleven kender teknikker til beskrivelse af statiske såvel som dynamiske aspekter af systemer, samt beskrivelser på typeniveau såvel som instansniveau, og endelig grafiske såvel som tekstuelle beskrivelser af de samme sagsforhold (fx klasse og objektmodeller, sekvensdiagrammer, tilstandsmaskiner, partielle ordninger af hændelser osv.).

E/R-model versus relationel datamodel: Her forventes det, at eleven kender til datamodellering ved hjælp af E/R-modellen, samt er fortrolig med teknikker til omformning af en E/R-model til en relationel datamodel, der kan danne grundlaget for realisering i et konventionelt relationelt databasesystem.

Den lagdelte computer: Her forventes det, at eleven kender til principper for hierarkisk organisering af en computers hardware og software i et antal (abstrakte) virtuelle maskiner, hvor relationen mellem de enkelte niveauer er realiseret ved hjælp af oversættelse og/eller fortolkning.

G.2.6 Symbol- og formalismekompetence

Karakteristik

På datamatikeruddannelsen består dennne kompetence i at kunne afkode symbolog formelsprog, i at kunne oversætte frem og tilbage mellem symbolholdigt matematisk sprog og naturligt sprog, og i at kunne behandle og betjene sig af symbolholdige udsagn og udtryk, herunder formler. Dels i at have indsigt i karakteren af og "spillereglerne" for formelle matematiske systemer (typisk aksiomatiske teorier).

Kommentar

En datamatiker adskiller sig væsentligt fra en datalogisk/matematisk uddannet kandidat derved, at datamatikeren som hovedregel benytter matematiske læresætninger/ resultater og kun i mindre omfang beviser disse sætningers gyldighed. Datamatikeren får derved behov for at have udviklet kompetence i forhold til at sætte sig ind i resultater, som vedkommende ikke nødvendigvis kan bevise, men som vedkommende har tiltro til er rigtige eller sandsynlige.

Som før nævnt omhandler generelt softwareudvikling at transformere et behov udtrykt i menneskesprog til et edb-program udtrykt i matematisk sprog (det binære talsystem). Denne transformation er abstrakt og omhandler opbygning af modeller, der via mapning bliver mere og mere matematiske, jf. kommentaren til modelleringskompetence. Hermed anvendes symbolsprog og formalisme mere og mere, jo længere man er fremme i udviklingprocessen.

Således udfordres datamatikeren ofte på en vanskeligt adskillelig måde på sin besiddelse af modelleringskompetence, repræsentationskompetence, samt symbolog formalismekompetence, hvilket også kommer til udtryk i nedenstående eksemplificering.

Eksemplificering

I realiseringsfasen af et softwareudviklingsprojekt udtrykker man sig meget i matematisk symbolsprog og formalisme (et programmeringssprog). Som programmør er det nødvendigt at kunne afkode et program og forstå, hvad det udfører, for at kunne foretage fejlretning og eventuelt videreudvikling. Her foretages såvel "afkodning af symbolsprog" som det at "oversætte frem og tilbage mellem symbolholdigt matematisk sprog og naturligt sprog" i vid udstrækning. Også i analyse- og designfaserne af en udviklingsproces udøves symbol- og formalismekompetencen, om end den "verden", der arbejdes i, bliver mindre matematisk, jo længere væk man kommer fra edbmaskinen.

Konkret kan det eksempelvis handle om

  • At kunne udtrykke og fortolke en algoritme/edb-funktion/edbsystem.

  • Udarbejde et program/en algoritme samt afkode samme.

Det at behandle og betjene sig af formler er der allerede givet et par eksempler på i forbindelse med Eksemplificeringen af modelleringskompetencen. Her kan vi tilføje

  • kompleksitets-, performance- og kapacitetsberegninger

  • forudseelse af eventuelle flaskehalse i et computernetværk, samt

  • utallige problemstillinger fra investeringsteori og regnskabsanalyse

som eksempler på områder inden for datamatikeruddannelsen, hvor formler er i spil i stor udstrækning.

Indsigt i karakteren af og "spillereglerne" for formelle matematiske systemer kommer fx i spil i forbindelse med

  • udtrækning af data fra en relationel database, hvor det er nødvendigt med kendskab til mængdelære.

  • formulering ved hjælp af grafer (der i datamatik ofte antager formalismekarakter) samt afkodning af disse (eksempelvis klassediagrammer, tilstandsmaskiner, data-flow-diagrammer m.v.).

  • udarbejdelse af en algoritme, hvor det er nødvendigt at have indsigt i logik, eksempelvis "if-then-else" konstruktionen.

G.2.7 Kommunikationskompetence

Karakteristik

På datamatikeruddannelsen består dennne kompetence i at kunne sætte sig ind i og fortolke andres matematikholdige skriftlige, mundtlige eller visuelle udsagn og "tekster", dels i at kunne udtrykke sig på forskellige måder og på forskellige niveauer af teoretisk eller teknisk præcision om matematikholdige anliggender, skriftligt, mundtligt eller visuelt over for forskellige kategorier af modtagere.

Kommentar

Typiske "modtagere" er medstuderende, lærere, brugere af it-systemer, beslutningstagere i virksomheder/det offentlige vedr. it-systemudvikling eller itanskaffelser m.v.

Eksemplificering

Næsten alle de eksempler, som tidligere er givet til illustration af de øvrige kompetencer, kan også tjene til at eksemplificere kommunikationskompetence i og med matematik, hvorfor et enkelt eksempel nævnt her må række:

  • At læse og forstå et program, der ikke er skrevet af én selv, kan opfattes som et eksempel på, at man sætter sig ind i et matematikholdigt anliggende for at uddrage den logik, som benyttes i programmets algoritme- og datastruktur.

Kommunikationskompetencen tydeliggøres derefter yderligere, når der skal udarbejdes en brugervejledning til dette program/system. Eksempelvis i beskrivelsen af inddata og uddata fra programmet, samt selve programmets logik.

Alt dette (m.m.) skal datamatikeren kunne formidle skriftligt, mundtligt og visuelt til mange forskellige målgrupper og med forskellige niveauer af teoretisk og teknisk præcision. Målgrupper er beslutningstagere, brugere, systemudviklere, programmører, driftsafdeling, systemprogrammører osv.

G.2.8 Hjælpemiddelkompetence

Karakteristik

På datamatikeruddannelsen består dennne kompetence i dels i at have kendskab til eksistensen og egenskaberne ved diverse former for relevante redskaber til brug for matematisk virksomhed, og have indblik i deres muligheder og begrænsninger i forskellige slags situationer, dels i at være i stand til, på reflekteret vis, at betjene sig af sådanne hjælpemidler.

Kommentar

På datamatikeruddannelsen bruges - ikke overraskende - en lang række itredskaber, som jo i sig selv kan være et matematisk hjælpemiddel. Flere af disse it-redskaber har indbyggede matematiske hjælpemidler, hver især med mange muligheder og begrænsninger i forhold til forskellige anvendelsesområder/ problemstillinger.

Eksemplificering

Også her kunne en lang række af de tidligere nævnte eksempler genbruges med en påpegning af, hvilke hjælpemidler der forventeligt vil være i spil ved arbejdet med de forskellige opgaver. Udover at pege på den oplagte brug af lommeregner, regneark, pc osv. vil vi nøjes med et eksempel, hvor udvikling af matematikforståelse og betjeningen af et stykke software går hånd i hånd:

  • Forespørgselssproget SQL til relationelle databaser baseret på mængdelære og prædikatkalkylen er genstand for, at eleven via sin matematiske viden udnytter disse muligheder på mere eller mindre avanceret niveau. Det er her, at refleksionen over betjeningen kommer ind: Skal jeg søge denne mængde først, og dernæst denne? Eller skal jeg først selektere efter dette kriterium, for derefter at udsøge det endelige resultat?

Tilsvarende eksempler kan nævnes fra programmeringsdisciplinen, eksempelvis når man i et Java-program benytter matematikbiblioteker (sqrt, sin, trunc . . . ).


1

Ud over arbejdsgruppen har Michael Caspersen, Jens Helveg Larsen, Hans Søndergaard og Jørn Vesterdal på afgørende måde bidraget til skabelsen af dette kapitel.

 


Denne side indgår i publikationen "Kompetencer og matematiklæring" som kapitel G af H
© Undervisningsministeriet 2002

 Forrige kapitel Forsiden  Næste kapitel
Til sidens top