Programmering Del 1. Innholdsfortegnelse. Resymé

Størrelse: px
Begynne med side:

Download "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

AlgDat 12. Forelesning 2. Gunnar Misund

AlgDat 12. Forelesning 2. Gunnar Misund AlgDat 12 Forelesning 2 Forrige forelesning Følg med på hiof.no/algdat, ikke minst beskjedsida! Algdat: Fundamentalt, klassisk, morsomt,...krevende :) Pensum: Forelesningene, oppgavene (pluss deler av

Detaljer

Hva er programmering?

Hva er programmering? 6108 Programmering i Java Leksjon 1 Introduksjon til programmering og til Java Hva er programmering? 1. Hva er et program? 2. Hva skal programmeres? 3. Hva er en programmerer? Programmering i Java - Leksjon

Detaljer

156C. Algoritmer og maskinspråk. IT1101 Informatikk basisfag. Maskinspråk: det maskinen forstår. Assembler / assemblerspråk

156C. Algoritmer og maskinspråk. IT1101 Informatikk basisfag. Maskinspråk: det maskinen forstår. Assembler / assemblerspråk IT1101 Informatikk basisfag I dag Programmeringsspråk Problemer med maskinspråk I dag: 5.1-5.3 Fra lavnivå til høynivå programmeringsspråk - utvikling Kompilator / tolker Programmeringsparadigmer Tradisjonelle

Detaljer

TDT4105 Informasjonsteknologi, grunnkurs (ITGK)

TDT4105 Informasjonsteknologi, grunnkurs (ITGK) 1 TDT4105 Informasjonsteknologi, grunnkurs (ITGK) Introduksjon til programmering i Matlab Rune Sætre satre@idi.ntnu.no 2 Læringsmål og pensum Mål Lære om programmering og hva et program er Lære å designe

Detaljer

Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen.

Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen. Kort innføring i design og programmeringsfasen Jarle Larsen/Tore Berg Hansen 2.11.04 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314 Prosjektrettet systemarbeid Resymé:

Detaljer

2 Om statiske variable/konstanter og statiske metoder.

2 Om statiske variable/konstanter og statiske metoder. Litt om datastrukturer i Java Av Stein Gjessing, Institutt for informatikk, Universitetet i Oslo 1 Innledning Dette notatet beskriver noe av det som foregår i primærlageret når et Javaprogram utføres.

Detaljer

TDT4105 Informasjonsteknologi, grunnkurs. Introduksjon til programmering i Matlab

TDT4105 Informasjonsteknologi, grunnkurs. Introduksjon til programmering i Matlab 1 Kunnskap for en bedre verden TDT4105 Informasjonsteknologi, grunnkurs Introduksjon til programmering i Matlab Amanuensis Terje Rydland Kontor: ITV-021 i IT-bygget vest (Gløshaugen) Epost: terjery@idi.ntnu.no

Detaljer

Kapittel 1: Datamaskiner og programmeringsspråk

Kapittel 1: Datamaskiner og programmeringsspråk Kapittel 1: Datamaskiner og programmeringsspråk Redigert av: Khalid Azim Mughal (khalid@ii.uib.no) Kilde: Java som første programmeringsspråk (3. utgave) Khalid Azim Mughal, Torill Hamre, Rolf W. Rasmussen

Detaljer

Kapittel 1. Datamaskiner og programmeringsspråk. 1.1 Programmering

Kapittel 1. Datamaskiner og programmeringsspråk. 1.1 Programmering Kapittel 1 Datamaskiner og programmeringsspråk Dette kapitlet er en kort introduksjon til programmering. Vi vil se på hvordan man skriver, bygger og kjører programmer, samt illustrere noen sentrale programmeringsbegrep

Detaljer

Objektorientering i VB en introduksjon

Objektorientering i VB en introduksjon Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Objektorientering i VB en introduksjon Oppdatert av Atle Nes Objektorientering i VB en introduksjon Resymé: Visual Basic.NET er et objektorientert

Detaljer

Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram

Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram Fastsatt som forskrift av Utdanningsdirektoratet 3. april 2006 etter delegasjon i brev 26. september 2005 fra Utdannings-

Detaljer

Debugging. Tore Berg Hansen, TISIP

Debugging. Tore Berg Hansen, TISIP Debugging Tore Berg Hansen, TISIP Innhold Innledning... 1 Å kompilere og bygge et program for debugging... 1 Når debugger er i gang... 2 Symbolene i verktøylinjen... 3 Start på nytt... 3 Stopp debugging...

Detaljer

Forelesningsnotat. Kapittel 9 Designing and Constructing Software Code related Issues. Design og utvikling av programvare

Forelesningsnotat. Kapittel 9 Designing and Constructing Software Code related Issues. Design og utvikling av programvare Forelesningsnotat Kapittel 9 Designing and Constructing Software Code related Issues 1 Design og utvikling av programvare Grunnleggende metoder (Kap 9.1) Utvikling av kode (Kap 9.2) Programmeringsspråk

Detaljer

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker

Detaljer

Introduksjon til fagfeltet

Introduksjon til fagfeltet LC238D http://www.aitel.hist.no/fag/_dmdb/ Introduksjon til fagfeltet Datafiler side 2 Databasesystemer side 3-5 Databasearkitektur ANSI/SPARC side 6-7 Datamodeller side 8 Flerbruker databasesystem side

Detaljer

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser? UML Use case drevet analyse og design 31.01.2005 Kirsten Ribu I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 1 2 Domenemodell visualisering

Detaljer

Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP

Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å

Detaljer

23.09.2015. Introduksjon til objektorientert. programmering. Hva skjedde ~1967? Lokale (og globale) helter. Grunnkurs i objektorientert.

23.09.2015. Introduksjon til objektorientert. programmering. Hva skjedde ~1967? Lokale (og globale) helter. Grunnkurs i objektorientert. Grunnkurs i objektorientert programmering Introduksjon til objektorientert programmering INF1000 Høst 2015 Siri Moe Jensen INF1000 - Høst 2015 uke 5 1 Siri Moe Jensen INF1000 - Høst 2015 uke 5 2 Kristen

Detaljer

Datastrukturer og Algoritmer

Datastrukturer og Algoritmer TOD 063 Datastrukturer og Algoritmer Forside fra lærebokens Nord Amerikanske utgave Tar for seg praktisk problemstilling: Hvordan håndtere containere som blir lastet fra containerskip i en travel havn

Detaljer

Beregninger i ingeniørutdanningen

Beregninger i ingeniørutdanningen Beregninger i ingeniørutdanningen John Haugan, Høyskolen i Oslo og Akershus Knut Mørken, Universitetet i Oslo Dette notatet oppsummerer Knuts innlegg om hva vi mener med beregninger og Johns innlegg om

Detaljer

Drosjesentralen. I-120: Obligatorisk oppgave 2, 2000

Drosjesentralen. I-120: Obligatorisk oppgave 2, 2000 Drosjesentralen I-120: Obligatorisk oppgave 2, 2000 Frist Mandag 20. November 2000 kl.10:00, i skuff merket I120 på UA. Krav Se seksjon 4 for kravene til innlevering. Merk krav om generisk løsning for

Detaljer

STE6221 Sanntidssystemer Løsningsforslag

STE6221 Sanntidssystemer Løsningsforslag HØGSKOLEN I NARVIK Avdeling for teknologi MSc.-studiet EL/RT Side 1 av 3 STE6221 Sanntidssystemer Løsningsforslag Tid: Fredag 02.03.2007, kl: 09:00-12:00 Tillatte hjelpemidler: Godkjent programmerbar kalkulator,

Detaljer

Kapittel 1: Datamaskiner og programmeringsspråk. Java som første programmeringsspråk

Kapittel 1: Datamaskiner og programmeringsspråk. Java som første programmeringsspråk Kapittel 1: Datamaskiner og programmeringsspråk Forelesningsnotater for: Java som første programmeringsspråk Khalid Azim Mughal, Torill Hamre, Rolf W. Rasmussen Cappelen Akademisk Forlag, 2003. ISBN 82-02-23274-0

Detaljer

Snake Expert Scratch PDF

Snake Expert Scratch PDF Snake Expert Scratch PDF Introduksjon En eller annen variant av Snake har eksistert på nesten alle personlige datamaskiner helt siden slutten av 1970-tallet. Ekstra populært ble spillet da det dukket opp

Detaljer

Statisk testing. Testing uten datamaskin, men med vår egen evne til å vurdere og analysere

Statisk testing. Testing uten datamaskin, men med vår egen evne til å vurdere og analysere Statisk testing Testing uten datamaskin, men med vår egen evne til å vurdere og analysere Hva er statisk testing Analyser som utføres på skrevne dokumenter Hensikten er å finne avvik fra spesifikasjonene

Detaljer

Et forsøk på definisjon. Eksempel 1

Et forsøk på definisjon. Eksempel 1 Et forsøk på definisjon [Kurssidene] [ ABI - fagsider bibin ] Michael Preminger (michael.preminger@hioa.no) 19/08-15 Engelsklignende språk, med rigid syntaks, som kan brukes til å skrive instruksjoner

Detaljer

Funksjonalitet og oppbygning av et OS (og litt mer om Linux)

Funksjonalitet og oppbygning av et OS (og litt mer om Linux) Funksjonalitet og oppbygning av et OS (og litt mer om Linux) Hovedfunksjoner i et OS OS skal sørge for: Styring av maskinvaren Deling av maskinens ressurser Abstraksjon vekk fra detaljer om maskinvaren

Detaljer

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu UML 1 Use case drevet analyse og design 20.01.2004 Kirsten Ribu 1 I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 2 Domenemodell visualisering

Detaljer

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: XX Eksamen i fag SIF8018 Systemutvikling

Detaljer

Flere design mønstre. 19. september 2002, Tore Berg Hansen, TISIP

Flere design mønstre. 19. september 2002, Tore Berg Hansen, TISIP Flere design mønstre 19. september 2002, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å

Detaljer

Kompleksitetsanalyse Helge Hafting 25.1.2005 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO117D Algoritmiske metoder

Kompleksitetsanalyse Helge Hafting 25.1.2005 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO117D Algoritmiske metoder Helge Hafting 25.1.2005 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO117D Algoritmiske metoder Innhold 1 1 1.1 Hva er en algoritme?............................... 1 1.2

Detaljer

Kapittel 1: Datamaskiner og programmeringsspråk. Java som første programmeringsspråk

Kapittel 1: Datamaskiner og programmeringsspråk. Java som første programmeringsspråk Kapittel 1: Datamaskiner og programmeringsspråk Forelesningsnotater for: Java som første programmeringsspråk Khalid Azim Mughal, Torill Hamre, Rolf W. Rasmussen Cappelen Akademisk Forlag, 2003. ISBN 82-02-23274-0

Detaljer

Programvare arkitekturer

Programvare arkitekturer Programvare arkitekturer 14. oktober 2001, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker

Detaljer

Algoritmeanalyse. (og litt om datastrukturer)

Algoritmeanalyse. (og litt om datastrukturer) Algoritmeanalyse (og litt om datastrukturer) Datastrukturer definisjon En datastruktur er den måten en samling data er organisert på. Datastrukturen kan være ordnet (sortert på en eller annen måte) eller

Detaljer

Pong. Oversikt over prosjektet. Steg 1: En sprettende ball. Plan. Sjekkliste. Introduksjon

Pong. Oversikt over prosjektet. Steg 1: En sprettende ball. Plan. Sjekkliste. Introduksjon Pong Introduksjon Pong er et av de aller første dataspillene som ble laget, og det første dataspillet som ble en kommersiell suksess. Selve spillet er en forenklet variant av tennis hvor to spillere slår

Detaljer

Databaser & objektorientering.

Databaser & objektorientering. Databaser & objektorientering. Noen grunnbegreper innen objektorientering. Klasser og forekomster klasser beskriver strukturen for noe. Beskrivelsen inneholder: et navn attributter /egenskaper / tilstander

Detaljer

Innhold Innledning 1. 5 Løkke som kontrollstruktur 131 5-1 Et program med løkke som kontrollstruktur 132. vii

Innhold Innledning 1. 5 Løkke som kontrollstruktur 131 5-1 Et program med løkke som kontrollstruktur 132. vii Innledning 1 1 Datamaskiner og programmer 5 1-1 Datamaskiner, programmer og programmering 6 1-2 Fra kildekode til kjørbart program 12 1-3 Elementene i et C++-program 15 1-4 Livsløpet til programmer 24

Detaljer

Læringsmål og pensum. Utvikling av informasjonssystemer. Oversikt. Systemutvikling Systemutvikling i seks faser Femstegs prosedyre for programmering

Læringsmål og pensum. Utvikling av informasjonssystemer. Oversikt. Systemutvikling Systemutvikling i seks faser Femstegs prosedyre for programmering 1 2 Læringsmål og pensum TDT4110 Informasjonsteknologi grunnkurs: Uke 38 Utvikling av informasjonssystemer Læringsmål Kunne seks faser for systemanalyse og design Kunne femstegs prosedyre for programmering

Detaljer

EKSAMENSOPPGAVE. IAI20102 Algoritmer og datastrukturer

EKSAMENSOPPGAVE. IAI20102 Algoritmer og datastrukturer EKSAMENSOPPGAVE Fag: Lærer: IAI00 Algoritmer og datastrukturer André A. Hauge Dato:..005 Tid: 0900-00 Antall oppgavesider: 5 med forside Antall vedleggssider: 0 Hjelpemidler: Alle trykte og skrevne hjelpemidler,

Detaljer

det offentlige kartgrunnlaget (DOK)

det offentlige kartgrunnlaget (DOK) geografiske data som er tilrettelagt for plan- og byggesaksarbeid = det offentlige kartgrunnlaget (DOK) Terje Nuland, geodataavdelingen Det offentlige kartgrunnlaget ØK FKB DOK Lover forskrifter veiledning

Detaljer

Oversikt. Introduksjon Kildekode Kompilering Hello world Hello world med argumenter. 1 C programmering. 2 Funksjoner. 3 Datatyper. 4 Pekere og arrays

Oversikt. Introduksjon Kildekode Kompilering Hello world Hello world med argumenter. 1 C programmering. 2 Funksjoner. 3 Datatyper. 4 Pekere og arrays Oversikt C programmering 1 C programmering Introduksjon Kildekode Kompilering Hello world Hello world med argumenter 2 Funksjoner 3 Datatyper 4 Pekere og arrays 5 Kontrollstrukturer Lars Vidar Magnusson

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Kandidatnr Eksamen i INF1000 Grunnkurs i objektorientert programmering Eksamensdag: Prøveeksamen tirsdag 23. november 2010 Tid for eksamen:

Detaljer

Kvalitet og programvare. Når bare det beste er godt nok. Produktet prosessen eller begge deler?

Kvalitet og programvare. Når bare det beste er godt nok. Produktet prosessen eller begge deler? Kvalitet og programvare Når bare det beste er godt nok. Produktet prosessen eller begge deler? To nøtter Hva forbinder du med et IT-system som har (høy) kvalitet? Formuler 3 kriterier for (høy) kvalitet

Detaljer

Kunnskapsbasert Engineering (KBE) med Common Lisp

Kunnskapsbasert Engineering (KBE) med Common Lisp Kunnskapsbasert Engineering (KBE) med Common Lisp KBE for semi-automatisk design av leiligheter og bygninger Kristoffer Kvello Selvaag BlueThink Temaer Hva er Kunnskapsbasert Engineering? Lisp Hva bruker

Detaljer

KPL. Barnas programmeringsspråk (Kids Programming Language) Det skal være v

KPL. Barnas programmeringsspråk (Kids Programming Language) Det skal være v KPL Barnas programmeringsspråk (Kids Programming Language) Det skal være v moro å lære! Copyright 2006 Morrison Schwartz. Norsk språkversjon copyright 2006 Bjørn Hope (www.kat.no) og Torbjørn Skauli. Kopiering,

Detaljer

datatyper Hva er programmering? Variabler og Informasjonsteknologi 2 Kompetansesemål

datatyper Hva er programmering? Variabler og Informasjonsteknologi 2 Kompetansesemål Variabler og datatyper Gløer Olav Langslet Sandvika VGS Høst 2012 Informasjonsteknologi 2 Hva er programmering? Når du skal bake en kake følger du gjerne en oppskrift. Først er det beskrevet hva kaken

Detaljer

Objektorientert programmering av vassdragselement. Jostein Orvedal Sognekraft AS

Objektorientert programmering av vassdragselement. Jostein Orvedal Sognekraft AS Objektorientert programmering av vassdragselement Jostein Orvedal Sognekraft AS Kven er Jostein? Arbeidar som produksjonsingeniør i Sognekraft AS Bakgrunn: Ingeniør elektronikk Meir enn 25 års erfaring

Detaljer

Hva er en kø? En lineær datastruktur der vi til enhver tid kun har tilgang til elementet som ble lagt inn først

Hva er en kø? En lineær datastruktur der vi til enhver tid kun har tilgang til elementet som ble lagt inn først Køer Hva er en kø? En lineær datastruktur der vi til enhver tid kun har tilgang til elementet som ble lagt inn først Et nytt element legges alltid til sist i køen Skal vi ta ut et element, tar vi alltid

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Side 1 Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1010 Objektorientert programmering Eksamensdag: Tirsdag 12. juni 2012 Tid for eksamen: 9:00 15:00 Oppgavesettet er

Detaljer

Norsk informatikkolympiade 2012 2013 1. runde

Norsk informatikkolympiade 2012 2013 1. runde Norsk informatikkolympiade 2012 2013 1. runde Uke 45, 2012 Tid: 90 minutter Tillatte hjelpemidler: Kun skrivesaker. Det er ikke tillatt med kalkulator eller trykte eller håndskrevne hjelpemidler. Instruksjoner:

Detaljer

Utforskeren. Stille gode spørsmål

Utforskeren. Stille gode spørsmål Utforskeren Stille gode spørsmål Utforskeren 8-10 En «mal» for timene? Kognisjon og metakognisjon I praksis handler kognisjon om kunnskap (hvor mange meter er det i en kilometer), ordforståelse (hva er,

Detaljer

Løsningsforslag til Case. (Analysen)

Løsningsforslag til Case. (Analysen) Løsningsforslag til Case (Analysen) Dette er en skisse til løsning av Case et med bussinformasjonssystemet. Jeg kaller det en skisse fordi det på den ene siden ikke er noe fasitsvar og fordi løsningen

Detaljer

Likninger - en introduksjon på 8. trinn Hva er en likning og hva betyr å løse den?

Likninger - en introduksjon på 8. trinn Hva er en likning og hva betyr å løse den? side 1 Detaljert eksempel om Likninger - en introduksjon på 8. trinn Hva er en likning og hva betyr å løse den? Dette er et forslag til undervisningsopplegg der utgangspunktet er sentrale problemstillinger

Detaljer

Argumenter fra kommandolinjen

Argumenter fra kommandolinjen Argumenter fra kommandolinjen Denne veiledningen er laget for å vise hvordan man kan overføre argumenter fra kommandolinjen til et program. Hvordan transportere data fra en kommandolinje slik at dataene

Detaljer

Norsk informatikkolympiade 2014 2015 1. runde

Norsk informatikkolympiade 2014 2015 1. runde Norsk informatikkolympiade 2014 2015 1. runde Sponset av Uke 46, 2014 Tid: 90 minutter Tillatte hjelpemidler: Kun skrivesaker. Det er ikke tillatt med kalkulator eller trykte eller håndskrevne hjelpemidler.

Detaljer

Ordliste. Obligatorisk oppgave 1 - Inf 1020

Ordliste. Obligatorisk oppgave 1 - Inf 1020 Ordliste. Obligatorisk oppgave 1 - Inf 1020 I denne oppgaven skal vi tenke oss at vi vil holde et register over alle norske ord (med alle bøyninger), og at vi skal lage operasjoner som kan brukes til f.

Detaljer

Generelt om operativsystemer

Generelt om operativsystemer Generelt om operativsystemer Operativsystemet: Hva og hvorfor Styring av prosessorer (CPU), elektronikk, nettverk og andre ressurser i en datamaskin er komplisert, detaljert og vanskelig. Maskinvare og

Detaljer

Start et nytt Scratch-prosjekt. Slett kattefiguren, for eksempel ved å høyreklikke på den og velge slett.

Start et nytt Scratch-prosjekt. Slett kattefiguren, for eksempel ved å høyreklikke på den og velge slett. Norgestur Introduksjon Bli med på en rundreise i Norge! Vi skal lage et spill hvor du styrer et helikopter rundt omkring et kart over Norge, mens du prøver å raskest mulig finne steder og byer du blir

Detaljer

En enkel while-løkke. 1 of 12 15.09.2015 15:28. 2 of 12 15.09.2015 15:28. while-løkker gjentar instruksjonene så lenge en betingelse er oppfylt

En enkel while-løkke. 1 of 12 15.09.2015 15:28. 2 of 12 15.09.2015 15:28. while-løkker gjentar instruksjonene så lenge en betingelse er oppfylt while-løkker gjentar instruksjonene så lenge en betingelse er oppfylt [Kurssidene] [ ABI - fagsider bibin ] Michael Preminger (michaelp@hioa.no) 15/09-15 En liten repetisjon Løkker Arrayer (tabeller) Løkker

Detaljer

Use case drevet design med UML

Use case drevet design med UML Use case drevet design med UML Bente Anda 26.09.2005 23.09.04 INF3120 1 I dag Domenemodeller System sekvensdiagrammer Operasjonskontrakter GRASP patterns Designmodeller med sekvens- og klassediagram 26.09.05

Detaljer

while-økker while-løkker gjentar instruksjonene så lenge en betingelse er oppfylt Eksempel 1: en enkel while-løkke

while-økker while-løkker gjentar instruksjonene så lenge en betingelse er oppfylt Eksempel 1: en enkel while-løkke [Kurssidene] [ ABI - fagsider bibin ] Utvikling av dynamiske nettsteder med PHP og databaser, våren 2014 while-økker while-løkker gjentar instruksjonene så lenge en betingelse er oppfylt Michael Preminger

Detaljer

EKSAMENSFORSIDE SKRIFTLIG EKSAMEN

EKSAMENSFORSIDE SKRIFTLIG EKSAMEN EKSAMENSFORSIDE SKRIFTLIG EKSAMEN Fag-/kurskode OBJ110 Fag/kurs Objektorientert systemutvikling 1 Ansvarlig faglærer Viggo Holmstedt Ansvarlig fakultet ØS Klasse(r)/gruppe(r) IS2 Dato 13.12.2010 Eksamenstid,

Detaljer

Fullstendig ytelsesbehandling

Fullstendig ytelsesbehandling Fullstendig ytelsesbehandling Fungerer også med Windows XP og Windows Vista 2013 Oppgrader og ta ansvar for datamaskinens ytelse med et kraftig og raskt program. Nedlasting og installasjon av Powersuite

Detaljer

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR INF 1050 UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR Oppgave 1 a) Foranalyse: Foranalysen kan med fordel gjøres i to trinn. Den første er å undersøke finansiering og øvrige

Detaljer

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:

Detaljer

En oppsummering (og litt som står igjen)

En oppsummering (og litt som står igjen) En oppsummering (og litt som står igjen) Pensumoversikt Hovedtanker i kurset Selvmodifiserende kode Overflyt Eksamen En oppsummering Oppsummering Pensum læreboken til og med kapittel 7 forelesningene de

Detaljer

Oppgaver til kodegenerering etc. INF-5110, 12. mai, 2015

Oppgaver til kodegenerering etc. INF-5110, 12. mai, 2015 Oppgaver til kodegenerering etc. INF-5110, 12. mai, 2015 Oppgave 1: Vi skal se på koden generert av TA-instruksjonene til høyre i figur 9.10 i det utdelte notatet, side 539 a) (repetisjon fra forelesningene)

Detaljer

Oppsummering. MAT1030 Diskret matematikk. Oppsummering. Oppsummering. Eksempel

Oppsummering. MAT1030 Diskret matematikk. Oppsummering. Oppsummering. Eksempel MAT1030 Diskret matematikk Forelesning 26: Trær Sist forelesning snakket vi i hovedsak om trær med rot, og om praktisk bruk av slike. rot Dag Normann Matematisk Institutt, Universitetet i Oslo barn barn

Detaljer

Kirsten Ribu - Høgskolen i Oslo 05.05.04

Kirsten Ribu - Høgskolen i Oslo 05.05.04 Prosessmodellering Strukturert analyse og design et overblikk Gurholt & Hasle, kapittel 10 Kirsten Ribu - Høgskolen i Oslo 05.05.04 1 Perspektiver på modellering Datamodellering var lenge den mest brukte

Detaljer

Et forsøk på definisjon. Eksempel 1

Et forsøk på definisjon. Eksempel 1 [Kurssidene] [ ABI - fagsider bibin ] Introduksjon Michael Preminger (michael.preminger@hioa.no) 13/12-13 I denne forelesningen: Utvikling av dynamiske nettsteder med PHP og databaser, våren 2014 Motivasjon:

Detaljer

Tom Røise 2/28/2007. IMT2243 : Systemutvikling 1. Forelesning IMT2243 1. mars 2007. Tema : Litteratur : Strukturert analyse. Strukturert analyse

Tom Røise 2/28/2007. IMT2243 : Systemutvikling 1. Forelesning IMT2243 1. mars 2007. Tema : Litteratur : Strukturert analyse. Strukturert analyse Forelesning IMT2243 1. mars 2007 Tema : Litteratur : Art.saml. Punkt 9 : Kap. 9. SASD - modellen, E. Andersen Metoden går ut på å anvende et sett teknikker i arbeidet med å lage gode systemmodeller /beskrivelser

Detaljer

Fra data til innsikt. Om prosjektet

Fra data til innsikt. Om prosjektet Fra data til innsikt DEFINERE FOKUS Om prosjektet De store produksjonsselskapene innen olje og gass må hele tiden strebe etter å effektivisere drift og øke sikkerheten på sine installasjoner. For å støtte

Detaljer

Oppgave 1 Flervalgsspørsmål ( multiple choice ) 15 %

Oppgave 1 Flervalgsspørsmål ( multiple choice ) 15 % Side 2 av 9 Oppgave 1 Flervalgsspørsmål ( multiple choice ) 15 % Denne oppgaven skal besvares på eget svarark sist i oppgavesettet. Dersom du finner flere alternativer som synes å passe, setter du kryss

Detaljer

Kapittel 3. The fun starts

Kapittel 3. The fun starts Kapittel 3 The fun starts Introduksjon I dette kapittelet vil jeg prøve å gjøre ting på en annen måte. Siden vi nå skal begynne å faktisk lage noe, tenkte jeg at jeg vil gjøre det slik at kapittelet blir

Detaljer

INNFØRING I PRINSIPPER FOR OBJEKTORIENTERT PROGRAMMERING EMILIE HALLGREN OG KRISTIN BRÆNDEN

INNFØRING I PRINSIPPER FOR OBJEKTORIENTERT PROGRAMMERING EMILIE HALLGREN OG KRISTIN BRÆNDEN INNFØRING I PRINSIPPER FOR OBJEKTORIENTERT PROGRAMMERING AGENDA Bakgrunn Hva er objektorientert programmering? Pseudokode Datatyper Attributter Metoder Returverdier Lister Relasjoner Spørsmål BAKGRUNN

Detaljer

Datamodellering 101 En tenkt høgskoledatabase

Datamodellering 101 En tenkt høgskoledatabase Datamodellering 101 En tenkt høgskoledatabase Spesifikasjoner for databasen vi skal modellere: Oversikt over studenter med: Fullt navn Klasse Studium Avdeling Brukernavn Fødselsdag Adresse Telefonnummer

Detaljer

Eksamen. Objektorientert Programmering IGR 1372

Eksamen. Objektorientert Programmering IGR 1372 + JVNROHQL1DUYLN $YGHOLQJIRU7HNQRORJL Eksamen i Objektorientert Programmering IGR 1372 7LG'HVHPEHU± 7LOODWWHKMHOSHPLGOHU 6NULYHVDNHU2UGE NHU -DYD6RIWZDUH6ROXWLRQV)RXQGDWLRQVRI3URJUDP 'HVLJQVNUHYHWDY/HZLV

Detaljer

Mangelen på Internett adresser.

Mangelen på Internett adresser. 1. Av 2 Introduksjon og forord Internett er som kjent bygd opp i adresser, akkurat som husstander, byer og land, dette er fordi Internett er bygd opp mye likt post systemet, du kan sammenligne en maskin

Detaljer

Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no

Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no Obligatorisk oppgave 1 INF-3200 12. oktober 2003 Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no Oppgavebeskrivelse: Designe og implementere en distribuert ray-tracing applikasjon, med basis i kontroller-

Detaljer

Spesifikasjon av Lag emne

Spesifikasjon av Lag emne Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Fra krav til objekter Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use Cases) o Objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Detaljer

Eksamensbesvarelser i REA3015 Informasjonsteknologi 2

Eksamensbesvarelser i REA3015 Informasjonsteknologi 2 Eksamensbesvarelser i REA3015 Informasjonsteknologi 2 Eksamensbesvarelsene er fra eksamen våren 2013. Forberedelsen og eksamensoppgaven finner du her: Eksamensoppgaver Eksamensveiledningen med kjennetegn

Detaljer

TDT4102 Prosedyre og Objektorientert programmering Vår 2015

TDT4102 Prosedyre og Objektorientert programmering Vår 2015 Norges teknisk naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap TDT4102 Prosedyre og Objektorientert programmering Vår 2015 Øving 3 Frist: 2014-02-07 Mål for denne øvinga:

Detaljer

Denne teksten er en oversettelse av en originaltekst fra ThinkerSmith, og er lisensiert i henhold til retningslinjene nederst på siden.

Denne teksten er en oversettelse av en originaltekst fra ThinkerSmith, og er lisensiert i henhold til retningslinjene nederst på siden. Mine Robotvenner Uten datamaskin Denne teksten er en oversettelse av en originaltekst fra ThinkerSmith, og er lisensiert i henhold til retningslinjene nederst på siden. Mine Robotvenner introduserer elevene

Detaljer

Python: Variable og beregninger, input og utskrift. TDT4110 IT Grunnkurs Professor Guttorm Sindre

Python: Variable og beregninger, input og utskrift. TDT4110 IT Grunnkurs Professor Guttorm Sindre Python: Variable og beregninger, input og utskrift TDT4110 IT Grunnkurs Professor Guttorm Sindre Læringsmål og pensum Mål for denne uka: Vite litt om design av programmer (2.1, 2.2, 2.4) Kunne skrive ut

Detaljer

1. SQL server. Beskrivelse og forberedelse til installasjon

1. SQL server. Beskrivelse og forberedelse til installasjon Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag SQL server. Beskrivelse og forberedelse til installasjon Stein Meisingseth 15.10.2014 Lærestoffet er utviklet for faget IDRI2001 Drift av

Detaljer

Installere JBuilder Foundation i Windows XP

Installere JBuilder Foundation i Windows XP Installere JBuilder Foundation i Windows XP Installasjon av JBuilder Foundation på Windows (dekker her spesifikt fremgangen ved bruk av Microsoft Windows XP Professional, men det vil mest trolig ikke være

Detaljer

Kapittel 8: Programutvikling

Kapittel 8: Programutvikling Kapittel 8: Programutvikling Redigert av: Khalid Azim Mughal (khalid@ii.uib.no) Kilde: Java som første programmeringsspråk (3. utgave) Khalid Azim Mughal, Torill Hamre, Rolf W. Rasmussen Cappelen Akademisk

Detaljer

PC-bok 1. Svein-Ivar Fors. Lær deg. og mye mer! Windows Tekstbehandling Regneark Mange nyttige PC-tips!

PC-bok 1. Svein-Ivar Fors. Lær deg. og mye mer! Windows Tekstbehandling Regneark Mange nyttige PC-tips! Svein-Ivar Fors s PC-bok 1 Lær deg Windows Tekstbehandling Regneark Mange nyttige PC-tips! Bruk PC en din til å skrive brev, gjøre forandringer i tekster, skrive feilfritt nesten bestandig, kopiere datafiler

Detaljer

Øving 3: Begrensninger

Øving 3: Begrensninger INF111: Torbjørn Sunnarvik Moen Øving 3: Begrensninger 1 Sjakk og språkoversettelser Suksess for sjakkprogrammer begrenset suksess for språkoversettere I dag finnes det dataprogrammer som kan spille sjakk

Detaljer

if-tester Funksjoner, løkker og iftester Løkker og Informasjonsteknologi 2 Læreplansmål Gløer Olav Langslet Sandvika VGS

if-tester Funksjoner, løkker og iftester Løkker og Informasjonsteknologi 2 Læreplansmål Gløer Olav Langslet Sandvika VGS Løkker og if-tester Gløer Olav Langslet Sandvika VGS 29.08.2011 Informasjonsteknologi 2 Funksjoner, løkker og iftester Læreplansmål Eleven skal kunne programmere med enkle og indekserte variabler eller

Detaljer

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

Bli Kjent med Datamaskinen Introduksjon ComputerCraft PDF

Bli Kjent med Datamaskinen Introduksjon ComputerCraft PDF Bli Kjent med Datamaskinen Introduksjon ComputerCraft PDF Introduksjon Vi begynner med å bygge en enkel datamaskin. Etter å ha brukt litt tid på å bli kjent med hvordan datamaskinen virker, bruker vi den

Detaljer

HiOA TDK. Ingeniørfag data. DATS1600 Programutvikling. Eva Hadler Vihovde. Prosjektoppgaven 2015. - Prosessdokumentasjon - Alternativ 1

HiOA TDK. Ingeniørfag data. DATS1600 Programutvikling. Eva Hadler Vihovde. Prosjektoppgaven 2015. - Prosessdokumentasjon - Alternativ 1 HiOA TDK Ingeniørfag data DATS1600 Programutvikling Eva Hadler Vihovde Prosjektoppgaven 2015 - Prosessdokumentasjon - Alternativ 1 - Forsikring - Gruppe #14 Studentnavn Marius Alexander Skjolden Hans Christian

Detaljer

Dagens temaer. Fra kapittel 4 i Computer Organisation and Architecture. Kort om hurtigminne (RAM) Organisering av CPU: von Neuman-modellen

Dagens temaer. Fra kapittel 4 i Computer Organisation and Architecture. Kort om hurtigminne (RAM) Organisering av CPU: von Neuman-modellen Dagens temaer Fra kapittel 4 i Computer Organisation and Architecture Kort om hurtigminne (RAM) Organisering av CPU: von Neuman-modellen Register Transfer Language (RTL) Instruksjonseksekvering Pipelining

Detaljer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer Fra krav til objekter Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer INF1050--1 Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use

Detaljer

Grafisk løsning av ligninger i GeoGebra

Grafisk løsning av ligninger i GeoGebra Grafisk løsning av ligninger i GeoGebra Arbeidskrav 2 Læring med digitale medier 2013 Magne Svendsen, Universitetet i Nordland Innholdsfortegnelse INNLEDNING... 3 GRAFISK LØSNING AV LIGNINGER I GEOGEBRA...

Detaljer

Kapittel 9: Følge Instruksjoner Prinsipper for Datamaskinens Virkemåte

Kapittel 9: Følge Instruksjoner Prinsipper for Datamaskinens Virkemåte Kapittel 9: Følge Instruksjoner Prinsipper for Datamaskinens Virkemåte «Fluency with Information Technology» Sixth Edition by Lawrence Snyder Oversatt av Rune Sætre, 2013 bearbeidet av Terje Rydland, 2015

Detaljer

STE6221 Sanntidssystemer Løsningsforslag kontinuasjonseksamen

STE6221 Sanntidssystemer Løsningsforslag kontinuasjonseksamen HØGSKOLEN I NARVIK Avdeling for teknologi MSc.-studiet EL/RT Side 1 av 3 STE6221 Sanntidssystemer Løsningsforslag kontinuasjonseksamen Tid: Mandag 06.08.2007, kl: 09:00-12:00 Tillatte hjelpemidler: Godkjent

Detaljer

TDT4102 Prosedyre og Objektorientert programmering Vår 2014

TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Norges teknisk naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Øving 10 Frist: 2014-04-11 Mål for denne øvinga:

Detaljer