Programmering Del 1. Innholdsfortegnelse. Resymé

Transkript

1 Programmering Del 1 Innholdsfortegnelse 3.1. PROGRAMVAREDESIGN METODER OG TEKNIKKER Strukturert programmering Designmetoder Beste praksis i design Abstraksjon Legacy systemer ULIKE TYPER PROGRAMMERINGSSPRÅK Ulike generasjoner Funksjonelle programmeringsspråk Prosedyrebaserte programmeringsspråk Objektorienterte programmeringsspråk Syntaks og semantikk Kompilatorer og Tolkere DATASTRUKTURER Records Tabeller (arrays) Lenkede lister Køer Stakker Trær ALGORITMER Rekursjon Sortering Søking PROGRAMMERINGSEKSEMPLER EPL EPL syntaks Et lite programeksempel Et større eksempel 1 (Java-kode) Resymé I dette modulen skal vi ta for oss deler av prosessen knyttet til programutvikling, hvilke metoder og teknikker som finnes for å utvikle programmer, hvordan vi kan strukturere data og hvilke muligheter finnes for å endre på disse strukturene og hvilke ulike typer programmeringsspråk vi har. Modulen avsluttes med en gjennomgang av EPL og et stort programeksempel.

2 3.1. Programvaredesign metoder og teknikker Å skrive et program er en utfordrende og kreativ erfaring. Målet med prosessen er å løse et problem stort eller lite. Designprosessen er første skritt på veien for å realisere en kravbeskrivelse til et kjørbart programvaresystem. Vi endrer fokus fra hva systemet skal gjøre til hvordan vi gjør det. Utkomme av designprosessen danner det videre grunnlaget for implementasjon (koding) av programvaren. For små oversiktelige problemer er det ikke så viktig å bruke en bestemt designmetode. Programvaren kan lages uten at det finnes en underliggende plan og systemets design utformes etter mange kortsiktige beslutninger. Dette kan fungere bra for programvaresystemer i liten skala, men etter hvert som programvaresystemene øker i omfang og kompleksitet, blir det vanskeligere å legge til nye egenskaper og holde oversikten over det hele. Videre vil det bli stadige flere feil i programkoden og det blir vanskeligere å lokalisere og rette opp disse. Et typisk kjennetegn på et system som er utviklet etter en slik mangel på metode, er lang testperiode etter at systemet er ferdig. Lang testperiode er lite gunstig, blant annet med tanke på at det er vanskelig å estimere tidsforbruk for denne fasen. Programvareutviklingsmetodene skal gjøre prosessen forutsigbar og mer effektiv. For å oppnå dette legges det opp til en detaljert prosess med tyngde på planlegging og design i en tidlig fase før implementering av selve programsystemet. På denne måten håper man å avdekke eventuelle feil eller mangler på et så tidlig stadium som mulig. Design er systematisk arbeid kombinert med erfaring og kreativitet. Den systematiske delen krever metoder. Erfaringen er nedfelt i designmønstre, der et mønster er en god og kjent måte å løse et designproblem på. Kreativitet er egenskaper som må dyrkes frem i talentfulle utviklere (Hansen og Hjertø, 2003). Alle store programvaresystemer består av flere mindre delsystemer. Den innledende designprosessen går ut på å identifisere disse delsystemene og lage et rammeverk som disse kan bygges inn i. Denne prosessen kalles for arkitektturdesign. Hvert delsystem spesifiseres ytterligere abstr. spesifikasjon. Andre faser i design prosessen tar for seg brukergrensesnitt og grensesnittet mellom de ulike delsystemene, datastruktur og eventuelle algoritmer (mer om algoritmer i kapittel 3.4). Designprosessen vil ofte gå i flere formelle trinn og kan sies å være en kontinuerlig forfining av systembeskrivelsen. Det er opp gjennom tidene lansert ulike designmetoder, vi skal se nærmere på et par av de mest kjente. På 1970-tallet ble dataflytdesign og datastrukturdesign lansert, og disse sto for den første bølgen av designmetoder. På slutten av 1980-tallet begynte objektorientert design å slå gjennom, og dette ser i dag ut til å være den mest populære måten å designe programvare på. Vi kan si at i tidlige år var man sterkt opptatt av data ved utvikling av programvaresystemer. Datidens teknologi satte store begrensninger for lagring av data og man måtte dermed lage en design som tok sikte på å få ned datamengden mest mulig. Etter hvert som teknologien utviklet seg kunne man tenke i nye baner, dataene ble mindre viktig og man fokuserte mer på systemets funksjonalitet. Dagens trend i programvaredesign setter fokus på både data og funksjonalitet og forener disse i designprosessen (objektorientering). De ulike designmetodene gir ulike perspektiver. Hvilken metode som velges kan relateres til hvilke krav som stilles. En design skal ta hensyn til de funksjonelle krav som stilles, ytelseskrav (responstid, tilgjengelighet, kapasitet, sikkerhet, vedlikeholdbarhet, pålitelighet), side 2 av 41

3 kost/nyttevurderinger og oppfylle ønske om modularitet med tanke på behov for fremtidige endringer Strukturert programmering Strukturert programmering kom som et svar på vanskelighetene med å holde styr på større programmeringsprosjekter. Folk forsto at programvareutvikling var mer kompleks en først forestilt. Det man trengte var å utforme et språk som var klarere og lettere å modifisere og avluse (finne og rette opp feil) enn ustrukturerte programmer som man hadde operert med tidligere. Strukturert programmering er altså en disiplinert tilnærming til programmering. Den største forskjellen mellom strukturert og ustrukturert programmering er at strukturerte programmer har en modulær design. Modulær design for å løse et problem innebærer at man deler problemet inn i flere delproblemer (moduler). De enkelte delproblemene blir så løst hver for seg før de settes sammen til en helhet, se figur under. Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-1 Modulær design La oss ta et eksempel: Vi skal lage en stol. De fleste ville da gjøre dette ved først å lage de enkelte delene en stol består av sete, stolbein, seterygg osv for så å sette disse sammen på rett måte. For at resultatet skal bli bra er vi avhengige av at de ulike delene faktisk passer sammen (for eksempel: stolbeinene skal være like lange, proporsjonene på de ulike delene skal stemme overens ). Og at delene settes sammen ordentlig ved for eksempel å bruke korrekt limtype (trelim). Dette kan vi kalle en modulær løsningsstrategi. En alternativ, ikke modulær løsning, kan være å skjære ut stolen hel i ett stykke av tre. De fleste er enige i at dette er en langt vanskeligere oppgave. Modulær design innebærer en klar forbedring i produktivitet. For det første kan små moduler implementeres (kodes) raskt og enkelt. For det andre kan man lage den enkelte modul mest mulig generell, slik at den kan brukes om igjen i andre situasjoner og dermed korte ned på utviklingstiden i andre sammenhenger. For det tredje er det enklere å teste og finne feil med en modulær design, i og med at man tester på mindre, oversiktlige enheter. Resultatet er at man får redusert tidsforbruk på testperioden. Strukturert programmering legger altså vekt på modularisering, og det å ha en strukturert oversikt over systemet som skal lages. Et annet aspekt ved denne metoden omhandler den indre oppbyggingen av programmene hvor strukturerte mekanismer er innført. Et program er en samling instruksjoner som i detalj beskriver hva som skal gjøres. I strukturert programmering utføres instruksjonene etter bestemte mønstre/rekkefølge alt etter hvilke oppgaver som skal løses. Vi har tre kategorier for rekkefølge: Sekvens, valg og løkke. Dette kalles også for kontrollstrukturer. Vi kan velge å utføre instruksjonene etter tur, eller at vi skal side 3 av 41

4 gjøre det ene eller det andre avhengig av gitt situasjon, eller vi ønsker å utføre de samme instruksjonene flere ganger. Hensikten er å utvikle programkode som er lett å forstå og verifisere. Mer om kontrollstrukturer i kapittel modulen Programmering Del 2. Kjente programmeringsspråk som Pascal ble utviklet blant annet for å lære strukturert programmering i et akademisk miljø. Pascal ble etter hvert også foretrukket som programmeringsspråk på flere universiteter. Et annet strukturert programmeringsspråk, som baserte seg på Pascal, er Ada. Utviklingen av Ada ble sponset av det amerikanske forsvarsdepartementet (DOD) og kom som en følge av ønsket om et enkelt språk som skulle dekke forsvarets programmeringsbehov Designmetoder Dataflytdesign Dataflytdesign (data flow) løste som tidligere nevnt, problemene på 1970 tallet. Dette er en metode som tar sikte på å modularisere løsningen som en rekke handlinger. Hver modul inneholder en eller flere prosedyrer også kalt metoder, funksjoner, rutiner eller subrutiner avhengig av hvilket programmeringsspråk som benyttes. Modulene transformerer inndata til utdata. I utviklingsfasen er det fokusert på algoritmer og trinnvis forfining av disse. Algoritmene er det sentrale, dataene sendes hit eller dit avhengig av algoritmen. Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-2 viser eksempel på et dataflytdiagram for en salgsbedrift. Vi ser at systemet har 3 hovedoppgaver: - Håndtere ordrer - Foreta avregning - Kjøpe inn varer Informasjon om varer og kunder finnes i to ulike datalagre. Nødvendige data for å løse de ulike oppgavene er representert med piler i diagrammet. Retningen på pilene angir hvilken vei informasjonen sendes. Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-2 Dataflytdiagram for en liten salgsbedrift Top down - analyse side 4 av 41

5 Hvor starter vi så å løse problemet? En løsningsstrategi er Top down - analyse. Det innebærer at problemet løses ved et kall på en prosesdyre Løs problemet. Denne handlingen deles så opp i flere delhandlinger som igjen kan deles opp, inntil hver del er liten nok og lett å kode. Top down -analyse legger stor vekt på planleggingsfasen og en helhetlig forståelse for systemet som skal utvikles. Systemets plass i forhold til dets omgivelser må også klargjøres. Selve impelementeringen av systemet skal helst ikke påbegynnes før en har kartlagt nok detaljer av systemet. Forståelsen for hele systemet blir vanligvis sett på som en nødvendighet for å være i stand til å utvikle en god design. Konstruksjon av dataflytdesign etter en Top down strategi, starter dermed med å identifisere hovedsystemets oppgaver og forholdet til omgivelsene man skal vise hvor data kommer fra og hvor de havner. Deretter deles hovedsystemet opp i delsystemer. De ulike oppgavene som skal løses fordeles mellom delsystemene og sammenhengen mellom de ulike delsystemene identifiseres. Eks: Vi har en butikkeier som har et lagerstyringsprogram. Systemets oppgaver er å holde oversikt over alle Kunder, håndtere ordrer og innkjøp og salg av varer. Under ser vi en figur som viser dette. Vi har en kunde som sender inn en ordrebestilling til systemet og får en Faktura tilbake: Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-3 Butikksystem overordnet nivå Dette systemet kan vi så dele inn i mindre delsystemer, for eksempel: Kundebehandling Lagerstyring Hvert enkelt delsystem kan detaljeres ytterligere for eksempel slik: Kundebehandling o Les bestilling fra kunden o Sjekk om varen er på lager o Beregn pris o Skriv ut faktura Dette kan vi fremstille i en hierarkis struktur. Elementene er prosedyrer med hovedprogrammet på toppen av hierarkiet: side 5 av 41

6 Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-4 Dataflytdesign av et butikksystem Merk at de ulike modulene må utføres i bestemt rekkefølge for at bruker skal få en fornuftig tilbakemelding. Det gir for eksempel ingen mening å skrive ut faktura før vi har lest inn brukerens bestilling. En av ulempene med Top down analyse er at man kan risikere å oppdage sent i prosessen at nederste del av hierarkiet ikke er realiserbar, og man kan da bli nødt til å lage en helt ny design og struktur for systemet. Bottum up - analyse I motsatt ende finner vi Bottum up - analyse hvor en griper fatt i små deler av systemet og spesifiserer disse i detalj noen ganger helt ned til implementasjonsnivå. Deretter lenkes de små bitene sammen til større komponenter som igjen lenkes sammen helt til at man har et ferdig programvaresystem. Bottum up analyse legger størst vekt på implementasjon, som kan startes med en gang den første modulen er spesifisert. Bakdelen med Bottum up som løsningsstrategi kan være at moduler blir implementert uten at man har en klar forståelse for hvordan de passer inn sammen med systemets andre deler. Dermed kan det oppstå en del problemer med å sy sammen de ulike delene til slutt. Objektorientering De siste årene har vært preget av en nærmest, eksplosiv vekst i bruk og utvikling av distribuerte datasystemer. Eksempler er nettbankløsninger, e-handelsløsninger, kraftselskap, flybestillinger basert på kommunikasjon over Internett og utvikling av programmer for mobile enheter som mobiltelefoner og Personal Data Assistants (PDA'er). Utviklingen av disse systemene er så og si uten unntak basert på objektorienterte systemutviklingsteknikker, hvor de enkelte program og programbiter modelleres og programmeres som enkeltstående objekter, som samhandler med hverandre. Også innen andre deler av programvareindustrien som f.eks. utvikling av brukergrensesnitt, kontorstøttesystemer, kontroll- og styringssystemer, osv. er utviklingen ofte basert på objektorienterte teknikker. Objektorienterte teknikker kan i dag brukes i alle deler av utviklingsprosessen fra objektorientert analyse via objektorientert design og til objektorientert programmering. Objektorientert analyse (OOA) tar sikte på å finne ut hva et system skal gjøre. Objektorientert design (OOD) har fokus på hvordan en applikasjon kan bygges opp som en samling objekter side 6 av 41

7 som samarbeider med hverandre. Objektorientert programmering (OOP) omsetter design til programkode ved bruk av for eksempel programmeringsspråket Java. Et lite tilbakeblikk. Tidlig på 1960-tallet ble det avholdt en internasjonal konferanse, AlgoL konferansen (Algorithmic Language) som resulterte i et forslag om en viss grunnleggende syntaks for strukturert programmering (kontrollstrukturer som valg- og løkkekonstruksjoner, sammensatte setninger og parameteroverføring til rutiner) se kapittel Som et resultat av denne serien med konferanser ble det utviklet flere programmeringsspråk, bla Simula, som de to nordmennene Ole Johan Dahl og Kristen Nygaard var grunnleggere for. Men Dahl og Nygaard gikk imidlertid et vesentlig skritt lenger i forhold til forslaget fra AlgoL-konferansen i og med at Simula introduserte et klassebegrep. Alle de sentrale ideene i objektorientert programmering er tilstede i Simula, og all senere utvikling av objektorientert programmering bygger på de to nordmennenes ideer. Hva ligger så i begrepet objektorientering? Objektorientering betyr at vi konsentrerer utviklingsprosessen om objekter. Med objektorienterte teknikker er det mulig å dele store, komplekse og uoversiktlige problemer inn i mindre og lettere håndterbare enheter. Selv om tanke- og designarbeidet tar noe lengre tid enn ved tradisjonell systemutvikling, vil den totale systemutviklingsprosessen bli kortere. Og særlig i vedlikeholdsfasen kan gevinsten være stor. Objektorientering gjør verden til en samling av objekter der informasjon og operasjoner er tett kombinert. Et objekt har en tilstand, en identitet og et sett egenskaper. Vare er et eksempel på et konkret objekt. Konkrete objekter settes inn i en hierarkisk struktur, der egenskaper kan abstraheres oppover eller arves nedover. Poenget er å finne minste felles multiplum for et sett av objekter, og samle disse egenskapene i en overordnet objektklasse. Det generelle objektet Vare er en slik klasse, og den sammenfatter egenskaper som er felles for konkrete objekter, slik som Mat og Konfeksjon. Felles for alle Varer kan være at de alle har et navn og en pris. Videre ned i hierarkiet blir egenskapene mer spesifikke. Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-5 Klassetreet for Vare Tar man en titt rundt seg, så vil man oppdage mange ulike objekter som man kan kategorisere: Mennesker, biler, hus, blomster, dyr osv. Vi kan dele disse objektene i tre ulike kategorier: - Levende - Døde - Abstrakte. side 7 av 41

8 De ulike objektene har alle ulike oppgaver, levende objekter foretar seg ting, mens døde objekter som for eksempel en stein, bare ligger der uten å gjøre spesielt mye. Men uansett hvilke oppgaver de ulike objektene har, så har de alle attributter, eller en tilstand som for eksempel størrelse, farge, vekt, høyde osv.. Alle objekter har også ulike operasjoner som spesifiserer hva de skal kunne utføre. En ball kan for eksempel sprette og trille, en bil kan akselerere, bremse, tute, en håndduk absorberer vann; osv. Hvert enkelt objekt har ansvar for å vite en del ting om seg selv. For eksempel: - En bil vet hvilket merke, farge og årsmodell den har og den vet hvordan den skal starte og øke/senke hastigheten. - En person vet navnet sitt, fødselsdatoen sin og hvordan han skal spise. - Et møte vet hvor det holder til, hvem som skal delta og når det starter. Etter en stund vet det også hvor mange som møtte opp og hvor lenge det faktisk varte. I den objektorienterte analysen er objektene altså virkelige eller tenkte forhold. Objekter kjennetegnes ved at de kan identifiseres, de har en tilstand og en adferd. De er også aktive i den forstand at de kommuniserer med hverandre. Alle virkelige objekter kan skilles fra hverandre, det samme gjelder modell-objekter. De har alle sin egen identitet. For eksempel så skiller vi person-objektene fra hverandre etter personnummer. Tilstanden til et objekt kan beskrives som et sett attributter som kan anta ulike verdier; det samlede settet av attributtverdiene viser objektets tilstand. Tilstanden kan da ses som en situasjon i livet til objektet, der objektet tilfredsstiller en betingelse, gjennomfører en aktivitet eller vente på at noe skal skje. Atferden uttrykker hva objektet kan gjøre, metoden sier hvordan det blir gjort. I den virkeligheten vi betrakter er det mange forskjellige objekter, som kommuniserer med hverandre gjennom meldinger. De kjenner kun til hverandres adferd (innformasjonsskjuling/ innkapsling). Denne samhandling mellom de ulike objektene står sentral i objektorientering. Objektene sender meldinger til hverandre og på den måten løses problemene. Objektorientert analyse og design legger, som vi har sett, vekt på både data og funksjonalitet. Alle objekter inneholder informasjon (data) om seg selv og kan utføre bestemte operasjoner. En av grunntankene bak objektorientert systemutvikling er at vi under systemutviklingsprosessen i størst mulig grad, skal kunne fortsette å forholde oss til virkeligheten. Dette oppnås ved for eksempel å bruke samme begreper som beskrevet i de tidlige problemformuleringene i prosessen. I årenes løp er det utviklet mange metoder for objektorientert analyse og design. De mest kjente metodene er utviklet av Ivar Jacobson (OOSE, use-cases), James Rumbaugh (OMT) og Grady Booch. Disse tre har slått seg sammen og dannet et eget firma. De har samkjørt sine metoder i et felles modelleringsspråk - Unified Modeling Language (UML). Språket beskriver bestemte måter å lage modeller på (f.eks. en bestemt måte å tegne bokser og piler på). I et utviklingsprosjekt arbeider man med mange modeller underveis, fra kravmodell via analyseog designmodell til implementasjonsmodell, som er det ferdige programmet. Når man anvender metodene i bestemt rekkefølge får man en prosess. The Objectory Software Development Process er navnet på prosessen som anvender UML til å beskrive modellene underveis. Jacobson, Rumbaugh og Booch har gitt ut tre store bøker som beskriver UML og Objectory. Mer om objektorientering i kapittel side 8 av 41

9 Beste praksis i design Beste praksis i design er den samme uansett designmetode. De generelle prinsippene om modularitet dvs. å dele inn systemet inn i mindre biter gjelder. Modularitet er et generelt prinsipp i alle ingeniørdisipliner, og er et uhyre viktig og fundamentalt prinsipp for å mestre en utviklingsprosess. Den viktigste fordelen med modularitet er at den gir oss mulighet til å anvende prinsippet om hver sak for seg på to måter: - Når vi skal utforme en modul, kan vi konsentrere oss om denne og glemme de andre - Når vi skal utforme systemet, kan vi konsentrere oss om de ytre egenskapene og sammenhengene mellom modulene, og glemme alle de indre detaljene i modulene. I det praktiske arbeidet oppnår vi mange fordeler gjennom modularitet: - Vi kan dele opp systemet i mindre biter og fordele arbeidet mellom flere personer eller arbeide med en bit om gangen. - Vi kan gjenbruke biter av et annet system eller bruke en bit flere ganger i det samme systemet. - Vi kan forstå systemet ved å forstå bitene. - Vi kan gjøre endringer ett sted. Vi skal altså tilstrebe modulær design. Et system er modulært når det består av moduler som hver gjør en ting, og samspiller med et lite antall andre moduler. En modul er kohesiv (har høy kohesjon) når den er konsentrert om en oppgave eller et lite antall beslektede oppgaver. Løs kobling har vi når de enkelte moduler utveksler informasjon med ideelt sett bare en annen modul. En design bestående av løst koblede, kohesive moduler har disse fordelene: - Den er lett å forstå - Den er lett å vedlikeholde - Den er lett å utvide Etter at vi har gjort den første designen, går vi kritisk gjennom resultatet. Vi undersøker om elementene er kohesive og løst koblede. Det finnes metrikker som kan beregnes. Hvis vi ikke er fornøyde, må vi gjøre endringer. Det kan innebære å legge til elementer eller å splitte opp elementer. Hver metode har sine retningslinjer for hvordan dette bør gjøres (Hansen og Hjertø, 2003) Abstraksjon Abstraksjon er en teknikk for å kunne håndtere et komplisert problem. Abstraksjon betyr kort fortalt at vi velger ut, fremhever og forstørrer de viktige sidene ved en sak, samtidig som vi velger vekk og usynliggjør de sidene ved saken som vi mener er mindre viktige. Det er mulig for oss å studere det som er viktig, uten å bli overveldet av alle detaljene ved saken. Abstraksjon er vanlig gjennom hele utviklingsprosessen. Kanskje spesielt fremtredene når vi lager ulike modeller av systemet. De sidene ved virkeligheten som vi avbilder i modellene, er de vi vurderer som relevante og viktige, de andre utelater vi. (Hansen og Hjertø, 2003) Når vi i en logisk datamodell har klassen Person, så har vi gjort en abstraksjon både ved at vi konsentrerer oss om klassen fremfor alle mulige personer, og ved at vi velger de egenskapene ved klassen Person som er relevante for det systemet vi skal lage. For eksempel for fødeavdeling på et sykehus, vil det være behov for å vite fødselstidspunkt, vekt, høyde, side 9 av 41

10 hodeomkrets osv til barnet, mens medlemsregisteret for idrettslaget trenger opplysninger om navn, alder, adresse, hvilken aktivitet medlemmet deltar på ol. Med dette fjerner man unødvendige detaljer, slipper en del skrivearbeid og fjerner en god del muligheter for feil. En modell er en forenkling av virkeligheten. Modeller hjelper oss å forstå kompliserte virkeligheter. Fra hverdagslivet er vi ikke ukjent med flere modeller av samme ting; et hus kan for eksempel modelleres som en arkitekttegning og som et tredimensjonalt minihus laget av plast. Forskjellige modeller av samme ting hjelper oss å forstå ulike aspekter ved virkeligheten. Arkitekttegningen gjør det enkelt for oss å danne et bilde av den totale planløsningen. Detaljerte mål er påført. Den tredimensjonale modellen gir oss et inntrykk av hvordan huset tar seg ut utenfra. Det er også viktig å være klar over at en modell likevel ikke helt er virkeligheten i miniatyr. Den har også egenskaper som ikke er i samsvar med virkeligheten. Arkitekttegningen er todimensjonal, den tredimensjonale modellen er laget av et annet materiale enn huset og har ikke glass i vinduene Legacy systemer Når man skal utvikle programvaresystemer støtter man ofte på problemet med såkalte legacy systemer. Et legacy system kan være et programvaresystem som på enkelte/alle områder er blitt foreldet, enten basert på gammel maskinvare og/eller benytter seg av for eksempel et umoderne brukergrensesnitt (for eksempel tekstbasert grensesnitt), mangler funksjonalitet osv. Utviklerens jobb kan gå ut på å enten erstatte det eksisterende systemet eller utvide og modernisere det gamle. Årsaken til at disse systemene stadig er i bruk kan ligge i kostnadene ved å erstatte eller utvide/ redesigne det. Dette til tross for at systemet ikke er konkurransedyktig og kompatible med moderne ekvivalenter. Dermed sitter man med store, massive systemer som er vanskelig og dyre å modifisere. Et legacy system som bare kjører på gammel maskinvare vil til sist gi en vedlikeholdskostnad som overstiger kostnaden for å erstatte både programvaren og maskinvaren hvis ikke bakoverkompatibilitet lar programvaren kjøre på ny maskinvare. Spørsmål en må stille seg er om det lønner seg å utvikle et nytt system, eller om man skal utvide og modernisere det eksisterende systemet. Alle systemer blir fort foreldet, ny maskinvare/ programvare utvikles hele tiden. I en slik prosess er det mange faktorer som spiller inn. Det kan være faktorer som økonomi hvor mye koster det å utvikle et helt nytt system i forhold til å oppgradere det eksisterende. Kan man leve med et umoderne programvaresystem i forhold til for eksempel kundeservice, konkurrerende bedrifter eller andre forhold? Hvordan vil brukere takle overgang til ett nytt system? Nye programvaresystemer må ofte ta hensyn til at de skal være kompatible med gamle systemer, blant annet fordi man kan ha behov for å hente/overføre data fra det gamle systemet til det nye Ulike typer programmeringsspråk Et programmeringsspråk er en standardisert kommunikasjonsteknikk for å gi presise instruksjoner til en datamaskin som sier hva den skal gjøre. Et program er en entydig, detaljert oppskrift for hvordan datamaskinen skal løse en oppgave. Vi kan sammenligne et program med for eksempel en matoppskrift, strikkeoppskrift eller et side 10 av 41

11 partitur. Skal man lage en bestemt gryterett følger man en oppskrift og blander sammen en gitt mengde av ulike ingredienser. Om man benytter seg av gode råvarer så blir resultatet bra. Om vi legger til faktorene erfaring og kreativitet når vi lager maten, kan vi oppnå et enda bedre resultat. Det samme gjelder et jazz-band. Har vi erfarne og kreative spillere så blir resultatet deretter. Erfaring og kreativitet er også egenskaper en god utvikler bør inneha. En må ha erfaring med hvordan vi bygger opp og løser ulike problemer, men samtidig være åpen for å finne nye, kreative løsningsstrategier (Hansen og Hjertø, 2003) Programmeringsspråk forenkler kommunikasjonen mellom datamaskin og programmerer. Ved hjelp av et høy-nivå språk, kan programmereren utvikle små og store programsystemer uten å tenke spesielt mye på maskinkodeinstruksjoner som er det språket prosessoren i datamaskinen forstår. De ulike programmeringsspråkene har sin egen syntaks og semantiske regler som må følges Ulike generasjoner Vi skiller mellom ulike typer språk basert på hvor ulikt programmeringsspråket er i forhold til maskinkoden kompilatoren vil generere. Maskinspråk (1. generasjon) All informasjon som skal behandles av datamaskinen foreligger på binærform. Dette gjelder også de instruksjonene vi ønsker at den skal utføre. Vi kan tenke oss funksjonen adder er representert ved tallkombinasjonen Program på denne formen er skrevet i maskinspråk. Maskinspråk er datamaskinens morsmål, og de første datamaskinene ble programmert ved hjelp nullere og enere og ikke nødvendigvis via tastatur. Det kunne være for eksempel kabler som var tilkoblet/ikke tilkoblet, brytere som var av eller på eller senere også hullkort. Denne binærkoden representerer maskinkodeinstruksjoner og er det som prosessoren i datamaskinen forstår. Maskinkoden er tett knyttet opp mot en bestemt maskinarkitekttur, det vil si at program skrevet i maskinkode kjøres kun på en type datamaskiner. Assembler (2. generasjon) Man fant raskt ut at man kunne forenkle programmeringen ved å lage programmer som oversatte til mer logiske navn på prosessorinstruksjonene, slik at man for eksempel kunne skrive add og få maskinen til å forstå at det var det samme som Vi kaller slike språk for assembler og instruksjonene kan skrives i en editor og oversettes videre av en assembler til maskinkode. Dette lettet arbeidet en del, men fremdeles var det vanskelig å forstå kodingen. I prinsippet var det omtrent det samme som maskinkode. Programmereren måtte fortsatt tenke i datamaskinens verden, det vil si små inkrementelle steg for å løse oppgaver. Vi kan sammenligne med en arkitekt: Å programmere i assembler er som å være arkitekt å tegne et hus ut fra planker, spiker, glass, isolasjon osv. Arkitekten ønsker å forholde seg til vegger, gulv, vindu og dører. Å kombinere kreativitet, problemløsning og programmering i assembler er vanskelig, men når man i et program stiller store krav til ytelse kan det lønne seg. Assembler er lik maskinspråk, knyttet opp mot en bestem maskinarkitekttur vil dermed ha ulik form avhengig av maskintypen. side 11 av 41

12 Høynivåspråk (3. generasjon) Med et ønske om kunne jobbe på et høyere nivå enn assembler/maskinspråk(jfr arkitekten), ble tredjegenerasjons programmeringsspråk utviklet. Det ble laget ferdige strukturer som før måtte programmeres manuelt. Mange assembler instruksjoner ble slått sammen til en høynivåinstruksjon, slik at programmereren slapp å tenke på så mange detaljer. For eksempel: Vi ønsker å addere to tall som heter Tall1 og Tall2. I assembler ville vi fått noe slikt som Hent Tall1 Hent Tall2 Adder Lagre svaret som Sum I et høynivå språk kan denne addisjonen utføres på én setning (instruksjon): Sum = Tall1 + Tall2; Måten det uttrykkes på kan variere litt fra språk til språk, men prinsippet er nokså likt for alle høynivåspråkene. Eksemplet viser hvordan det uttrykkes i Java. Høynivåspråk er i motsetning til maskinkode og assemblerspråk mer eller mindre maskinuavhengig. Dette gir store fordeler, vi slipper å lage et nytt program om en oppgave skal løses på en annen type datamaskin. 4. generasjon 4. generasjonsspråk er et høynivåspråk som er utviklet til et bestemt formål, for eksempel databasesøk (SQL), rapportgeneratorer (Oracle reports). Målet med disse språkene er blant annet å hindre feilprogrammering ved å skape et språk med begrensede muligheter. Det trenger ikke være et nytt språk, det kan være for eksempel en makropakke til et 3.generasjonspråk. Vi kan si at programmeringsspråkene har utviklet seg fra at programmereren måtte jobbe i maskinens verden, til at maskinen tilpasser seg mennesket måte å tenke på. I de tidlige årene var man også mest opptatt av data. Datidens teknologi satte som kjent, store begrensinger for lagring av data og man var dermed sterkt opptatt av å få ned datamengden mest mulig. I dag setter ikke teknologien slike begrensinger og programmeringsspråkene har utviklet seg i takt med teknologien. Etter hvert som teknologien åpnet opp for større lagringskapasitet, kunne utviklere endre fokus fra dataorientert til mer funksjonsorientert, hva skal systemet gjøre Funksjonelle programmeringsspråk Funksjonell programmering har fått navnet fordi funksjonelle program består kun av funksjoner. Programmereren beskriver løsningen på et problem som løsninger av flere småproblemer, og deler programmet inn i funksjoner som løser hver sine oppgaver. Hovedprogrammet er en funksjon som tar imot informasjon fra bruker eller en annen funksjon og gir om nødvendig et svar tilbake. Hovedfunksjonen vil være delt inn i flere funksjoner, som igjen er delt inn i nye funksjoner helt til det grunnleggende nivået er nådd. Disse grunnleggende funksjonene har likheter med vanlige matematiske funksjoner. Funksjonell programmering inneholder ingen tilordnings uttrykk. Dette medfører at variabler gis verdi en gang, og denne verdien endres ikke. Mer generelt kan vi si at funksjonelle program ikke har noen sideeffekter i det hele tatt. Sideeffekt vil si at et funksjonskall resulterer kun i det å presentere resultatet av det som funksjonen skal gjøre andre funksjoner blir ikke berørt. Funksjonene lever altså sine egne liv uten å påvirke de andre med sin side 12 av 41

13 utførelse. Dette eliminerer en stor kilde til feil og medfører også at rekkefølgen for programutførelsen er irrelevant, fordi det ikke er noen ytre påvirkninger for utføringen av de ulike uttrykkene slik at de kan beregnes når som helst. Denne egenskapen ved funksjonell programmering gjør at programmereren ikke trenger å foreskrive dataflyten i programmet. I og med at uttrykk kan beregnes når som helst, står man fritt til å erstatte variabler med tilhørende verdier og omvendt. Denne friheten gjør at funksjonelle programmer er mer matematiske enn mer konvensjonell programmering. Funksjonell programmering har altså ikke tilordninger, sideeffekter eller dataflyt kontroll. Hva er da styrken med slik programmering, Eksempel: Vi ønsker å summere en rekke med tall, i funksjonell programmering vil dette løses ved å lage en funksjon som summerer det første tallet med summen av alle de andre. Funksjonen kaller seg selv. Funksjonelle programmeringsspråk legger spesielt vekt på regler og mønstergjenfinning. Språkene kan virke lite intuitive for dem som bare har erfaring med prosedurale og objektorienterte programmeringsspråk, men for de som har en del erfaring med slike språk er det konsise og naturlige programstrukturer. Funksjonell programmering egner seg spesielt godt til matematiske beregninger, hvor begrepet funksjon er et veletablert konsept. Det eldste funksjonelle språket er LISP (Lots of Infuriating & Silly Parenthesis), men nyere språk som Standard ML (open source) og Haskell anses av mange som bedre alternativer. Haskell er noe lettere å formulere seg i, men gir ikke like rask eksekvering som Standard ML. Det kanskje mest moderne funksjonelle språket er Clean, som har elegante, rent funksjonelle biblioteker for systemprogrammering og grafiske brukergrensesnitt Prosedyrebaserte programmeringsspråk Prosedyrebaserte programmeringsspråk har en del av funksjonell programmering i seg. Vi har den samme tankegangen i forhold til å dele opp et problem i mindre delproblemer for så å løse disse. Et proseduralt program består av ulike moduler/enheter som igjen kan deles inn i en eller flere prosedyrer. I begrepet prosedyre ligger det at man fokuserer på funksjonalitet og hva et program skal gjøre. Det er de ulike prosedyrene for å løse et problem som tilsier hvilke moduler vi deler programmet inn i. Eksempel: Du ønsker å lage et program for en kalkulator. En kalkulator skal som kjent kunne utføre beregninger for ulike regnearter og har som regel en minnefunksjon. Har man en litt dyrere kalkulator vil man også ha mulighet for å beregne sinus, cosinus, kvadratrot, osv. Om vi lager et program for en enkel kalkulator kan vi dele program inn i følgende prosedyrer: - Adder - Subtraher - Divisjon - Kvadratrot Hovedprogrammet holder så styr på hvilke prosedyrer som kalles opp for å kunne gi korrekt tilbakemelding til bruker ut fra de inndata han har kommet med. side 13 av 41

14 Det legges vekt på at programkoden skal være oversiktlig og enkel å finne fram i. Elementer fra strukturert programmering er innebygd, som for eksempel de ulike kontrollstrukturene sekvens, valg og løkke, logiske operatorer mm. Til forskjell fra rent funksjonelle programmeringsspråkene så opereres det ikke med konstante variabler. En variabel kan endres underveis og kan være lokal inne i en metode eller global for å kunne benyttes i alle prosedyrene. Videre er det mulig å parameteroverføre variabler til de ulike prosedyrene og mellom disse. Sideeffekter kan oppstå, kjøring av en prosedyre kan medføre endringer for andre for eksempel ved å endre på data som er tilgjengelig og brukes av flere prosedyrer. Eksempel: Vi har et system for kjøp og salg av kinobilletter, for hver billett som selges oppdateres et bilde av kinosalen slik at reserverte/solgte seter markeres opptatt, mens ledige seter markeres med grønt. Vi kan da lage to prosedyrer: 1. Kjøp billett Velg film, dato, sted, klokkeslett Velg ledig sete 2. Oppdater kinosalbildet Prosedyre nr 1 tar for seg billettsalget. Vi lar det være en todelt operasjon hvor vi først velger filmen for så å finne ledig sitteplass. For hver fullførte reservasjon kalles prosedyre nr 2 oppdater kinosalbilde med de nye reservasjonene. Hvis det sitter flere selgere samtidig og ser på det samme kinosalbildet, vil de i prinsippet kunne selge samme billetten til ulike kunder, iom at de velger ledig sete før de reserverer det. Stikkord som beskriver prosedurale programmeringsspråk er handlingsorientert, modularitet og strukturert programmering. Kjente prosedurale programmeringsspråk er Pascal Objektorienterte programmeringsspråk Det som kjennetegner et objektorientertprogrammeringsspråk er at det gjør det enkelt å programmere modeller av virkeligheten. Det vil si at vi kan lage objekter og gi hvert objekt tilhørende egenskaper og operasjoner. Videre gjør programmeringsspråket det mulig å programmere sammenhengen mellom objektene. I prinsippet kan man lage objektorienterte programmer i et språk som ikke har denne støtten, men det krever mer av programmeren. Man kan også for eksempel programmere prosedyralt i et objektorientertspråk. Hva er det som kjennetegner et objektorientert språk? Jo, det må støtte for innkapsling og polymorfi. Vi skal illustrere hva dette betyr med et enkelt eksempel. La oss se på en typisk butikk (stormarked med litt utvidet varesortiment). En slik butikk har mange forskjellige varer med ulike egenskaper illustret i Figur 3.7. side 14 av 41

15 Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-7 Ulike Vare-objekter La oss fokusere på hva disse varene har felles. Alle varer har et varenavn og en pris, vi sier da at navn og pris er felles attributter for de ulike vare-objektene. Et vareobjekt har også noen oppgaver som må kunne utføres en av disse vil være å opplyse en kunde om prisen. Dette kaller vi for en operasjon. De forskjellige varene har ulike priser noen varer selges til stykkpris, andre til kilo-pris. En gruppe objekter med felles beskrivelse av attributter og operasjoner kaller vi for en klasse. Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-6 viser vi et klassediagram (UML) over klassen Vare som beskrevet ovenfor. Vare navn pris finnnavn finnpris Klassenavn Attributter Operasjoner Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-6 Klassediagram for klassen Vare Kunnskapen om navn, pris samt utførelse av operasjonene, har de ulike varene inni seg, omverden kjenner varen kun gjennom de operasjonene som kan utføres. Vi sier at kunnskapen om data og utførelse av operasjoner er kapslet inn i objektet. En vare er ikke noe levende objekt som for eksempel objektet student. Men vi modellerer varen som om den var det. Vi sier at en vare innehar kunnskap om seg selv, om både attributter og operasjoner. Objektet er en modell av en ting som problemområdet vårt handler om. Som vi ser av vareeksempelet kan man forenkle virkeligheten, og bare ta med det som er viktig for å løse en bestemt oppgave. Vi tar kun med det som er nødvendig for å løse et problem/oppgave. Vi kunne i vareeksemplet gått mye lengre og tatt med flere attributter og operasjoner som for eksempel enhet (kilo, stk), varetype (drikke, frukt, klær, elektrisk osv), butikkplassering osv. En annen viktig egenskap ved objektorientering er at objekter kommuniserer med hverandre. Vi kan for eksempel spørre en vare hva prisen på den er. Vi sier at en "klient" (omverden) sender meldingen "Hva koster du?" til et vareobjekt for eksempel Paprika, som her fungerer som "tjener". Paprikaen svarer med å sende meldingen 3 kroner tilbake. Se Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-7. side 15 av 41

16 Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-7 Klient tjener Den tredje viktige siden ved objektorientert programmering er polymorfi. Ordet polymorfi er latin og betyr mange og i denne sammenhengen betyr det at en og samme melding kan opptre i mange former. Det vil si at sammen oppgave løses på ulike måter i forskjellige sammenhenger. Vi kan for eksempel sende meldingen "finnpris" til mange varer, men de løser oppgaven på sin egen måte (noen har kilo pris, mens andre opererer med stykk pris). Et annet eksempel på polymorfi kan være å beregne areal for ulike geometriske figurer. Vi har for eksempel objektene firkant og trekant. Vi kan sende samme melding til begge objektene, beregn areal og de to objektene vil kunne utføre oppgaven og sende melding tilbake med svaret. For den som sender meldingen og mottar svar (klienten) har figurenes form ingen betydning, mens for de to figurobjektene er det indre forskjeller på hvordan for eksempel formelen for arealberegning er satt opp. Se figuren under. Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-8 Polymorfi Et fjerde trekk ved objektorienterte programmeringsspråk er mulighet for arv. Som nevnt i kapittel 3.1, så kan objekter settes sammen i en hierarkisk struktur, der egenskaper kan abstraheres oppover eller arves nedover. Eksempel. På en skole finnes det flere kategorier med personer, vi har studenter, lærere, renholdere osv. Felles for alle disse kategoriene er at de alle har et unikt personnummer, navn, bostedsadresse, telefonnr og lignende. Videre kan vi klassifisere disse kategoriene i en student og en ansatt gruppe, Spesifikke egenskaper for ansatte kan være lønnstrinn, skattetrekk. Vi kan så spesifisere ansatt gruppen ytterligere i en kategori lærere og en kategori renholdere. Spesifikt for lærere kan være hvilke fag de underviser i og hvor de har kontorplass. Renholdere kan ha andre spesifikke egenskaper. Når det gjelder egenskaper for studenter kan dette være hvilke fag de tar, eksamenskarakterer og hvilket studieprogram som følges. side 16 av 41

17 Hver kategori kalles for en klasse. I tillegg til egenskaper kan de ulike klassene også ha operasjoner som arves nedover, for eksempel så kan klassen Person ha operasjoner som finnnavn og finnadresse, mens klassen Student kan i tillegg ha følgende operasjoner: følgundervisning, taeksamen. Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-9 Arvehierarki for klassen Person Figuren over viser arvehierarkiet, for enkelthet skyld er operasjoner utelatt. Alle egenskapene arves nedover, indikert med piler, slik at objekter av typen Lærer har egenskapene personnr, navn, adresse, tlf, lønnstrinn, skattetrekk, fag og kontornr. Mens et Studentobjekt har egenskapene personnr, navn, adresse, tlf og et studieprogram. Et objekt av klassen Person vil kun ha egenskapene personnr, navn, adresse og tlf. På denne måten slipper man å gjenta vanlige, generelle egenskaper og operasjoner i de ulike klassene og i stedet arver dem nedover i hierarkiet. Objektene vet forskjellige ting om seg selv, for eksempel hvilke egenskaper de har og hvordan ulike oppgaver som etterspørres skal løses. Eksempler på objektorienterte programmeringsspråk: Java, C++, C# Syntaks og semantikk Alle språk kan beskrives ut fra to hovedkomponenter. Det ene er syntaks regler som forteller hvilke grammatiske regler som må følges. Den andre er semantiske regler som sier noe om hva de ulike setningene i språket betyr. I tillegg til disse to hovedkomponentene snakker man gjerne om pragmatikk. Dette er mer uformelt og handler om språket og bruken av det. Syntaks regler i programmeringsspråk kan sammenlignes med grammatikk i vanlige språk. Om vi slår opp i ei ordbok for et bestemt språk, ser vi hvilke ord som er tillatt i bruk og hvilke former av de ulike ordene som godtas. Det samme gjelder for et programmeringsspråk. Det er klare regler for hvilke tegn, ord, uttrykk som kan brukes. Dette er de minste meningsbærende side 17 av 41

18 enhetene i programmet (navn, tall, nøkkelord, operatorer, ) Det er også viktig hvordan vi setter sammen disse enhetene til instruksjoner (setninger) som igjen utgjør programmet. I et dataprogram fører syntaksfeil til at programmet ikke kan kompileres (oversettes til maskinkode) og vi får presentert en feilmelding som beskriver hvor problemet ligger. Kompilatoren prøver å tenke selv og peker på hvor i programkoden feilen er. Det er ikke alltid at dette stemmer, men som regel gir det en god pekepinn på hvor man skal starte feilfinning. Semantikk beskriver meningen av de ulike delene i språket. Også de semantiske reglene kan deles i to grupper, statiske regler som omhandler det som kan sjekkes av kompilatoren før programmet kjøres, og dynamiske regler som omhandler det som skal skje under kjøringen av programmet. Semantiske feil omtales gjerne som logiske feil og kan være vanskelig å oppdage, spesielt den siste typen feil som ikke oppdages av kompilatoren. Feilsituasjoner som kan oppstå under kjøring kan være at programmet gir feil svar, eller at programutførelsen rett og slett stopper (krasjer). Vi ønsker for eksempel å lage et program som beregner arealet av et rektangel. Når vi kommer til utregningen av arealet, glemmer vi oss litt og skriver inn formel for beregning av omkrets. Dette gir ikke en syntaksfeil, men en logisk feil som kompilatoren ikke oppdager. Resultatet blir at vi har laget et arealberegningsprogram som skriver ut omkrets. For å oppdage slike logiske feil må vi teste programmet vårt med for eksempel å lage noen testdata og se om vi får forventet resultat når vi kjører programmet. Mer om testing av programvare i modulen Programmering Del Kompilatorer og Tolkere Som nevnt så må man, for å kunne kjøre et dataprogram, oversette kildekode (som mennesker har skrevet i en tekst editor) til maskinkode som datamaskinen forstår. Dette kan gjøres enten ved å oversette hele programmet til maskinkode før det kjøres ved hjelp av en kompilator, eller man oversetter programmet tegn for tegn mens det kjøres ved hjelp av en tolker. Dette kan sammenlignes med det å oversette en bok til et annet språk på den ene siden og det å simultantolke på den andre. Det er svakheter og styrker ved begge metodene. En fordel med kode som kompileres ferdig på forhånd er at den gir en raskere programutførelse enn kode som tolkes under kjøring. Et annet moment er at kode som kompileres på forhånd ikke er arkitekturnøytral. Det betyr at programmet bare kan kjøres på en type datamaskiner. De ulike prosessorene (datamaskiner) krever ulik maskinkode. Om du ønsker å kjøre programkoden din på flere ulike prosessorer må du da kompilere programmet flere ganger, for hver av de ulike prosessorene. Om du da senere gjør endringer for eksempel retter opp feil eller legger til ny funksjonalitet i programmet, så må du gjennom hele kompileringsrunden en gang til. Kompileringsprosessen skjer bare en gang (om det ikke er noen syntaksfeil i koden) og resulterer i en kjørbar fil som kan kjøres på den aktuelle maskintypen. side 18 av 41

19 Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-10 Kompilering av et program En tolker er det samme som en kompilator, bortsett fra at oversettelse og utførelse (kjøring) skjer om hverandre. En liten del av kildekoden oversettes og kjøres. Deretter oversettes neste del før den kjøres osv. I motsetning til kompilator så lages det ingen kjørbar fil slik at oversettelsesprosessen må utføres hver gang programmet kjøres. Dette kan resultere i en noe tregere programutførelse. Fordelen med en tolker er at man eliminerer behovet for separat kompileringsfase. Noen programmeringsspråk er arkitektturnøytral (plattformuavhengig), som for eksempel Java. Tenk deg at et oljeselskap skulle lage en bil som drives kun med deres egen bensin. Det virker åpenbart urimelig, men det er akkurat det som har vært praksis i databransjen i lengre tid. Datafirmaer har dermed hatt en trofast kundekrets. Dette har fungert greit, men etter Internets inntog i verden har det blitt mer og mer viktig å kommunisere med alle typer datamaskiner behovet for en åpen standard økte. Dette er en av ideene bak programmeringsspråket Java. Java er et plattformuavhengig språk, det vil si at det kan kjøres på alle datamaskintyper som har støtte for det aktuelle språket. For å få til dette oversetter kompilatoren programkoden til noe som heter bytekode (og ikke maskinkode). De datamaskiner som har støtte for Java kan da kjøre fila gjennom en java-tolker. Det er først når tolkeren tar fatt på kjøringen av bytekoden, at programmet blir oversatt til maskinkode. Maskinspesifikke ting kommer dermed frem først ved kjøring av programmet. Alt som er spesielt for en bestemt maskintype (Macintosh, Solaris, Windows XP osv) er det bare tolkeren som har noe med, bytekoden fungerer dermed ideelt sett alle steder. Så lenge du har en Java-tolker kan du kjøre programmet. Java tolkeren kalles også for Just-In-Time Compiler (JIT). Under følger en figur som viser hvordan man får kjørt et Java program, først skriver man inn programkoden, deretter kompileres denne til bytekode som til sist oversettes til maskinkode ved hjelp av en tolker på den datamaskinen du ønsker å kjøre programmet på. Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-11 Fra Java kildekode til kjørbart program 3.3. Datastrukturer Hva legger vi egentlig i begrepet datastruktur? Jo, en datastruktur ser nærmere på hvordan en samling data er organisert. Vi kan for eksempel samle data om en person i en persondatavariabel. Denne inneholder flere variabler av ulike datatyper. Videre kan vi, forutsatt at vi vet antall personer, samle dataene om mange personer i en tabell av persondata. Dersom vi har behov for å legge til og/eller fjerne personer på en dynamisk måte kan vi bruke lenkede lister istedenfor tabeller. side 19 av 41

20 Ved hjelp av datastrukturer kan vi lagre samlinger av data under ett bestemt navn. Det kan for eksempel være resultatet av et skirenn med tider for hver deltaker. Det kan være at vi ønsker å lage et adresseregister med flere ulike typer data for hver person. Det kan være eksamensresultater for en student. For å kunne lagre og behandle disse dataene trenger vi datastrukturer som for eksempel records, tabeller, lenkede lister og trær. En datastruktur består av en samling elementer (noder) og relasjoner (referanser). Oppgaven til en datastruktur er å knytte elementer som hører sammen, på en effektiv og hensiktsmessig måte. Relasjonene definerer hvilke naboer ett element og danner dermed en ordning av elementene. Et slikt naboskap kalles ofte for en topologi Records Records er en samling navngitte felter av forskjellig datatyper. Tilgangen til de ulike feltene styres via feltnavnene. En record grupperer og setter sammen en mengde variabler av forskjellige typer i en logisk helhet. Antall felter i en record er få, sammnenlignet med antall elementer i en tabell. Måten strukturen er satt opp, gjør at vi ikke kan beregne oss frem til et felt i tabellen, men vi må bruke feltnavnene. En record har følgende egenskaper: - Feltene er av forskjellige typer - Feltene har sitt eget feltnavn - Feltene kan nås ved dot notasjon: record.feltnavn - Når en record er opprettet kan man ikke legge til eller fjerne felter. - Feltene i en record lagres etter hverandre med passende avsatt plass til hvert felt i minnet I programmeringsspråket C++ implementerer vi en record ved å bruke en struct (se Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-12). I Java lager vi egne klasser. Figur Feil! Det er ingen tekst med den angitte stilen i dokumentet.-12 Record Hvorfor er det hensiktsmessig å bruke records for å holde orden på dataene? Dersom vi ønsker å registrere data om mange personer uten å bruke records, må vi gjenta den samme koden flere ganger. Antall ganger avhenger av hvor mange personer vi skal registrere. Dersom vi skal gjenta dette for 75 personer må koden gjentas 75 ganger. Istedenfor å gjøre det på denne måten, kan vi bruke records slik at det blir mye lettere holde orden på dataene. Alle data i tilknytning til hver person kan nå håndtereres som en helhet. Dersom vi skal holde orden på dataene for mange personer kan vi legge variablene av typen person inn i en tabell. Mer om tabeller i neste kapittel. side 20 av 41