SYSTEMORIENTERT PROGRAMMERING

Størrelse: px
Begynne med side:

Download "SYSTEMORIENTERT PROGRAMMERING"

Transkript

1 HØGSKOLEN I ÅLESUND SIDE 1 SYSTEMORIENTERT PROGRAMMERING Av Harald Yndestad

2 HØGSKOLEN I ÅLESUND SIDE 2 Oppdragsgiver: HIÅ Referanse: TITTEL: SYSTEMORIENTERT PROGRAMMERING Prosjektrapport: HIÅ/EA/HY/9501 Dokument nr.: Del 1 Dokument type: Kompendium Dokument tilgang: Begrenset Dokument status Arbeidsnotat Versjon nr Antall sider: 84 Bibl. nr.: FORFATTER SIGNATUR: HARALD YNDESTAD DATO: JANUAR 1995 SAMMENDRAG: Emneord Systemteori Modellering Objekt e systemer Distribusjon 3 EA HIÅ DISTR SYST UTV YNDESTAD DSKOMP3.DOC 1995

3 HØGSKOLEN I ÅLESUND SIDE 3 Langt ut i skogen sover en liten gutt. Aldri så jeg en slik vakker liten gutt. Gutten på puta. Puta av fjæra. Fjæra av fuglen. Fuglen av egget. Egget av reiret. Reiret av bladet. Bladet av kvisten. Kvisten av grenen. Grenen av treet. Treet av berget. Og berget ligger langt borte i skogen. Fra en folkevise DISTR SYST UTV YNDESTAD DSKOMP3.DOC 1995

4 HØGSKOLEN I ÅLESUND SIDE 4 1 ORIENTERING 1.1 FORORD I1989 ble det i et nasjonalt IT-program vurdert å opprette felles regionale geodatabaser for kommuner og fylkeskommuner. I den forbindelse gjorde jeg en vurdering av det faglige grunnlaget av hvordan dette kunne realiseres. En av konklusjonene i denne utredningen, var at en burde heller la nettet være felles og så desentralisere databasen. Geodataene kan da vedlikeholdes der de ble produsert. Videre foreslo jeg å administrere nettet med et sett intelligente objektorienterte noder. I et senere forskningsprosjekt for NTNF gjorde vi en analyse av hvordan en kunne realisere møbelindustriens samlede krav til IT-tjenester. En av konklusjonene i dette arbeidet var at spesifikasjonene kunne realiseres enkeltvis, men ikke samlet. Jeg fant videre at løsningen var å utvikle et konsept med objektorienterte parallelle tjenester via en softwarebuss som beskrevet i dette dokument. Et fellestrekk ved disse prosjektene, var behovet for integrasjon av komplekse datatekniske systemer. Jeg fant at det kreves det en ny måte å tenke på i programvareutvikling. Siden tradisjonelle metoder var så etablerte, fant vi at det var nødvendig å utvikle et begrepsapparat og en dypere forståelse av hvordan en kan modellere komplekse datatekniske systemer. Jeg har så valgt på å søke tilbake til grunnleggende metoder for modellering. Deretter har vi utviklet et begrepsapparat for distribuert programvareutvikling og kunnskapsbaserte datasystemer basert på systemteori og objektorientert programmering. Dette dokumentet er det første dokument i en serie om systemteori. Dokumentet er skrevet over en periode på 4 år ut fra en samling av forelesninger i faget ved Høgskolen i Ålesund. Harald Yndestad DISTR SYST UTV YNDESTAD DSKOMP3.DOC 1995

5 HØGSKOLEN I ÅLESUND SIDE BEGREPER 1. Abstrakt maskin: Et objekt som får utført tjenester fra klienter (Djikstra). 2. Abstrakte datatyper: En spesifikasjon på en programfunksjon som er konstruert i samsvar med prinsipper for modularitet. 3. Abstraksjon: En spesifikasjon på et element/objekt. 4. Adaptivitlet: Endring i indre struktur. 5. Adgangskontroll: Hindring i at uvedkommende får adgang til ressurser eller informasjon. 6. Aktiv concurrency: En prosess som kan aktiviseres av flere og konkurrerer om tilgang til ressurser. 7. Aktørsynspunkt: 8. Aktivitet: Et element som produserer informasjon på grunnlag av inngangs data og kontrolldata. 9. Algoritme: En regneregel. 10. Analyse: Å oppdage de elementer et system består av. 11. Ansvar: Autorisasjon til å kunne endre data 12. Arkitektur: En systemkonstruksjon av objekter. 13. Arv: En spesialisering med utvidet tilgang til data og metoder. 14. Autorisasjon: Utstede tilgang til informasjon eller tjenester. 15. Autentisering: Bevis på at en melding kommer fra en identifisert og autorisert person. 16. Binding: Kommunikasjon mellom elementer i et system. 17. Blocking concurrency: En prosess som kan aktiviseres vi flere typer av eksterne kall 18. Classe: Et objekt som kan produsere nye objekter som er kopier av seg selv. 19. Concurrency: En modul/objekt som konkurrerer om tilgang til ressurser. 20. Data: En statisk representasjon av noe fra virkeligheten. 21. Delegering: Dekomponenter får autorisasjon til å endre data. 22. Delsystem: Et element som er oppbygget som et system. 23. Dualisme: Et system består at to motsatte og uforenlige grunnprinsipper. 24. Dynamisk binding: Frigjøring fra kompilert binding. En melding sendes til en aktivitet og aktiviteten tolker meldingen. 25. Dynamisk persistense: Et objektet er endret etter programkjøringen. Eks en kø. 26. Ekspansjonisme: Et system med en egen målsøkende utvikling. 27. Element: En basisfunksjon eller tjeneste i et system som representerer noe fra virkeligheten. 28. Entropi: Statistisk fordeling av energi. 29. Horisontal integrasjon: Data settes sammen på samme nivå i en verdikjede. 30. Informasjonsteknologi: Elektronisk prosessering, kommunikasjon og lagring av tekst, bildet, grafikk, bilde og lyd. 31. Integritet: Bevis på at en melding ikke er endret. 32. Innkapsling: Interne data og metoder er skjult innenfor objektet overfor omverden 33. Instans: En kopi av en klasse. Instansen kan arve metoder og subklasser av klassen. Instanser av en klasse kan ha egne lokale data og ha en spesialisert tjeneste. 34. Kausalitet: Der er sammenheng mellom årsak og virkning. 35. Klasse: En spesifikasjon av hvordan en type kan implementeres i et objektorientert språk. Klasser kan lage kopier av seg selv i form av instanser. 36. Konfidensialitet: Hindre at personer ikke er autorisert kan lese meldingen. 37. Kommunikasjon: En overføring av data mellom elementer. 38. Kundespesifisert komponent: Et objekt utviklet av en bruker og som ikke er innebygget i språket. 39. Kunnskap: Data og metoder i et element/objekt. 40. Lukket system: Indre data i et objekt er skjult fra utsiden. 41. Melding: En mekanisme til å overføre inndata, kontrolldata og utdata mellom objekter 42. Modell: En representasjon av noe fra virkeligheten som gir svar på spørsmål. 43. Modul: Modul er en implantasjon av utskiftbar kode med egne interne data, interne metoder og et felles inn- og ut-grensesnitt. 44. Objekt: Et objekt er en implementasjon av et element i en datamaskin. Implementasjonen har en innkapsling med lokale data, lokale metoder. 45. Objektorientering: Et programmeringsmetode som er karakterisert ved modularisering, informasjonsgjemming, oppførsel og instansering 46. Oppførsel: Utviklingen av tilstanden i et element/objekt. 47. Paradigme: En klasse metoder/regneregler innenfor samme konsept. DISTR SYST UTV YNDESTAD DSKOMP3.DOC 1995

6 HØGSKOLEN I ÅLESUND SIDE Persistent: Objektet eksisterer mellom to programkjøringer. Det kan f.eks være lagret på en database. 49. Polymorphisme: Objektet har evne til å kalle på mer enn en type aktivitet 50. Programmerbar komponent: Programmet styres i samsvar med postmeldinger 51. Protokoll: Et formalisert sett av standard regler for informasjonsformat og kontroll av inn- og uttjenester mellom to systemer som kommuniserer med hverandre. 52. Reduksjonisme: Analysetankegang. En helhet kan deles i enkelenheter til en minste enhet. 53. Rekursivitet: Elementet i et system er bygget opp av delsystemer på mange nivå. 54. Sekvensiell concurrency: Et objekt som aktiviseres via et eksternt kall. 55. Softwarebuss: Et objekt som transporterer postmeldinger mellom objekter. 56. Softwarekort: Et objekt som utfører en spesialtjeneste under en Softwarebuss. 57. Softwarerack: Et sett med Softwarekort som er knyttet sammen via en Softwarebuss. 58. Standard Komponent: Et ferdig utviklet objekt fra en programvareleverandør. 59. Statisk persistense: Objektet eksisterer uforandret etter programkjøringen. 60. Struktur: En binding av systemelementer. 61. Subklasse: En utvidelse av klassen. 62. Superklasse: En klasse på et høyere nivå. 63. Syntese: En sammenstilling av elementer til et system. 64. Synkronisering: En ordning rekkefølgen av hendelser i tid. 65. System: En samling elementer med felles formål som påvirker hverandre gjensidig. 66. Systemgrense: En avgrensing av elementer med felles formål. 67. Systemintegrasjon: En innlemmelse av nye elementer i et system. 68. Systemsynspunkt: 69. Teleologi: Et målsøkende element. 70. Tilstand: En egenskap på et tidspunkt. 71. Tilstandsmaskin: Et objekt som styrer rekkefølgen av et sett med mulige kontrolltilstander. 72. Tilstandsrom: Et sett mulige tilstander. 73. Tjenerobjekt: Tjenesteobjekt er en abstrakt maskin som utfører en saksbehandling i samsvar med en fastlagt prosedyre. 74. Tjenesteobjekt: Et objekt som utfører tjenester for andre objekt uten å benytte andre objekter. 75. Transaksjon: Overføring av data fra en tilstand til en annen. 76. Type: En spesifikasjon på en programmodul som betraktes som en samlet abstraksjon. 77. Vedkjenning: En kan ikke benekte at en melding er sendt eller mottatt 78. Vertikal integrasjon: Data foredles i en verdikjede av systemelementer. 79. Åpent system: Ekstern tilgang til data i et objekt. DISTR SYST UTV YNDESTAD DSKOMP3.DOC 1995

7 HØGSKOLEN I ÅLESUND SIDE INNHOLD 1 ORIENTERING FORORD BEGREPER INNHOLD INNLEDNING MODELLERING PRINSIPPER DUALITETSPRINSIPPET BALANSEPRINSIPPET ORIENTERING ÅPNE SYSTEMER REKURSIVE SYSTEMER SYSTEMANALYSE MODULER OBJEKTER DELEGERING ARV PROTOKOLL REDUKSJONISME SYSTEMDYNAMIKK TILORDNING ALGORITME OPPFØRSEL Tilstandsmaskin Dynamikk Agenter LIVSSYKLUS SYSTEM BINDING SYSTEMERS ANATOMI SYSTEM KOBLING Åpent system Tidsbestemt kobling Kobling via subset Kobling via lister Kobling via data Logisk kobling Sammensatt kobling SYSTEM KOHESJON Kohesjon via forbindelse Kohesjon via struktur Kohesjon etter systemgrense Sammensatt binding PROSESSER OPPFØRSELKONTROLL AV PROSESSER RESSURSDELING Semaforer Avbrudd Gjensidig utelukkelse Dataoverføring Felles kø Fjerne metodelall DYNAMISK BINDING PARALLELLE TJENESTER MELDINGSTYPER VELGERTYPER Softwarebus Realisering av softwarebus ADRESSERINGSMETODER Reiserute Ordrebasert adressering Wormkonseptet REKURSIV DYNAMISK BINDING ABSTRAKTSJONSNIVÅ FRAKTALPROSESSOR TEKNISKE TJENESTER VINDUTJENESTE NETT-TJENESTE KONFIGURASJONSTJENESTE SIKKERHETS-TJENESTE Kryptografering Overføring via nett Dokumentintegritet Meldingautorisasjon Autorisasjon av passord LEKSJONER LEKSJON 1: MODELLERING LEKSJON 2: OPPSTART AV SMALLTALK LEKSJON 3: TRANSAKSJONER LEKSJON 4: LUKKEDE ELEMENTER LEKSJON 5: BASISTJENESTER LEKSJON 6: ARV LEKSJON 7: PROSESSER LEKSJON 8: MODELLERING LEKSJON 9: SENSOR MED SOFTWAREBUSS LEKSJON 10: BRUKERGRENSESNITT LEKSJON 11: PROSJEKTOPPGAVE PROGRAMVARE SOFTWAREBUS SENSOR MED SOFTWAREBUS PREDICTOR PROBE LP-FILTER ALARM EULER TIKK-TAKK DISTR SYST UTV YNDESTAD DSKOMP3.DOC 1995

8 HØGSKOLEN I ÅLESUND SIDE 8 14 LITTERATUR... 85

9 HØGSKOLEN I ÅLESUND SIDE 9 2 INNLEDNING Hva er egentlig informasjonsteknologi? Er det materialet silisium? Svaret er både ja og nei. Materialet er i hvert fall noe håndfast som bærer elektroniske signaler. Uten de elektroniske signaler har vi ingen nytte av materialene. Vi kan så stille oss neste spørsmål. Er det de elektroniske signalene som får IT til å gjøre nyttig informasjonsbehandling? Svaret på dette er også her både ja og nei. De elektroniske signalene er i hvert fall bærer av den informasjon vi er ute etter. Det vi vet er at de elektroniske signalene representerer informasjon og at informasjon er representert via abstrakte matematiske modeller. Uten disse modellene har vi ingen nytte av de elektroniske signalene. Vi kan så fortsette å stille oss neste spørsmål. Er det de abstrakte modellene av data og programmer som utfører den ønskede informasjonsbehandling? Svaret er også her både ja og nei. Modellene er i hvert fall en representasjon av noe fra virkeligheten, men modellene utfører ikke noe som helst. Informasjonsteknologi er altså noe konkret og abstrakt på samme tid som må forståes på flere nivå. utvikling av matematisk modellering, elektronikk, instrumentering og nye markeder. Det blir ofte framstilt slik at informasjonsteknologi er teknologidrevet av utviklingen innen mikroelektronikk. Egentlig er det slik at en utviklingsprosess starter med utvikling av matematisk modellering. Modellene blir så materialister i mikroelektronikk til instrumentering og produkter. Det kan ta år (150 år med Fourier) før ny matematiske modeller blir omsatt til en ny generasjon elektroniske produkter. Modellering Matematisk modellering er utviklet over en periode på flere hundre år og er i fortsatt utvikling. I de senere år har denne utviklet seg i flere retninger. Eksempler er: Fra Newtons matematikk til mer ulineær matematikk (eks neurale nett, kaosteori, wavelet) Modellering på flere abstraksjonsnivå Mer bruk av adaptiv kontroll Objektorientering av abstraksjoner Denne modelleringen har lagt det vitenskapelige grunnlaget for utvikling av en ny generasjon informasjonsteknologi (IT). De matematiske modellene som ligger til grunn for utvikling og anvendelse av informasjonsteknologi skal representere noe fra virkeligheten. Disse matematiske modellene er begrenset av en filosofi eller et paradigme. Dette paradigmet er en klasse med regler og teknikker som bestemmer hvordan en kan sette opp modeller. Det er ikke sikkert at det paradigmet som ligger til grunn for modellering av informasjon, er egnet til å representere den virkelighet vi ønsker å modellere. Skal vi kunne velge riktig paradigme, må vi forstå vår forståelse av naturens natur. Paradigme Matematisk modell Elektroniske signaler Materiale Figur 1. Nivåer av system modellering. I de siste 30 år har informasjonsteknologi (IT) dannet grunnlag for en teknologisk revolusjon uten sidestykke i historien. Grunnlaget for denne utviklingen har vært en gjensidig virkning mellom Elektronikk Elektronikk representerer en implementasjon av matematiske modeller. Denne har i de seneste 30 årene hatt en meget sterk utvikling i retning av: Kraftigere, mindre og mer distribuerte signalprosessorer Kundespesifiserte elektroniske kretser Raskere datakommunikasjon Komplekse digitale systemer med mer en 1 million transistorer på en brikke Instrumentering Elektronikk er grunnlaget for moderne instrumentering. Denne utvikler seg i retning av: e systemer med distribuerte tjenester Intelligente modulsystemer med standard grensesnitt Integrasjon på høyere nivå Utviklingstrekk ved IT Utviklingen av ny elektronikk, modellering og instrumenter påvirker all utvikling av IT. Klare utviklingstrekk i 1990-årene er: Integrasjon av tjenester på høyere nivå Standardisering av kommunikasjons grensesnitt Større krav til forståelse av komplekse datatekniske løsninger Større krav til anvendelse av ulineære matematiske modeller

10 HØGSKOLEN I ÅLESUND SIDE 10 Bruk av større matematiske modeller for simulering av økonomi, produksjon og produktegenskaper Mindre skille mellom IT i elektronisk instrumentering og styring av administrative funksjoner. I denne utviklingen er kontroll og forståelse komplekse systemer det overordnede problem. Teknologi som representasjon Organisasjon A B C Total integrering Automatiske systemer er i ferd med å bli total integrert: Alle styringsprosesser i produksjon (CIM) Konstruksjon til produksjon (CAD/CAM) Produksjon og all administrativ saksbehandling i administrasjon (CIE) Bedrifter i en produksjonskjede (integrert produksjon) Integrasjon av produktutvikling (Concurrent Engeenereing) Total integrering av kvalitetssikring (TQM) Integrasjonsproblemet Total integrering gir opphav til strukturelle endringer for teknologi og organisasjoner. Disse har igjen noen fundamentale egenskaper. De viktigste er: De må bygges ut fra bunnen og oppover Standardisering av abstraksjoner, metoder og grensesnitt Det kreves en kvalitetssikring av tjenester Det kreves en organisasjonsintegrering Tjenester får en livssyklus som i et økologisystem Systemteori danner grunnlag for modellering Figur 2 Organisasjon med delene A, B og C Innføring av teknologi er basert på det konseptet at teknologien skal erstatte noe fra virkeligheten. Dersom en f.eks har en organisasjon med som er delt inn i tjenestene A, B og C, kan en f.eks erstatte manuelt arbeide i tjenesten B med en datamaskin. Skal en kunne erstatte den manuelle tjenesten B med en datamaskin, er det nødvendig å lage en modell av de tjenestene datamaskinen skal kunne utføre. Denne modellen blir så materialisert i en datamaskin. Programmet blir altså ikke bedre enn den modellen av virkeligheten som programmet skal representere. Det betyr igjen at kunnskaper om modellering er avgjørende for at dataprogrammer skal kunne utføre de oppgavene de er tiltenkt. I det etterfølgende skal vi beskrive metoder for modellering av programvare. Kontroll av komplekse datasystemer krever en dypere forståelse av modellering, abstraksjoner, oppførsel og grensesnitt. Å utvikle en kompleks dataspesifikasjon uten et overordnet felles systemeringsarbeide, er som å la mange jernbaneselskap få bygge ut hver sin del av et jernbanenett, med hver sin bredde mellom skinnene. Resultatet må før eller siden bli at alt må gjøres om på nytt. Jo mer en bygger ut desto større blir kostnadene når dette skal gjøres om. Utvikling av komplekse datasystemer krever altså en ny form for systematikk. Denne systematikken krever en bedre forståelse av hva en modell er for noe og hvordan denne er knyttet til sine omgivelser.

11 HØGSKOLEN I ÅLESUND SIDE 11 3 MODELLERING PRINSIPPER Modell En modell er en representasjon av et system eller av deler av et system. Generelt har en at: M er en modell av systemet S hvis M kan brukes til å gi svar på spørsmål om S. En slik modell krever ikke at M løser alle spørsmål om S, men to eller flere. Avbildning Fabrikk Spørsmål u(n) Fabrikkmodell Figur 3 Avbildning via en modell Svar y(n) En modell avbilder deler av virkeligheten via en modell som realiseres via en eller flere algoritmer. Algoritmen kan realiseres som en matematisk modell eller en annen regneregel som gir modellen en oppførsel i samsvar med systemets egenskaper. Oppførselen til systemet gir svar på spørsmål om systemet egenskaper. Dette kan f.eks være hvordan systemet endrer seg over tid. Dersom en kan sette en spesifikasjon på modellens oppførsel, kalles modellen en abstraksjon. Abstraksjoner kan igjen modelleres som elementer i en Systemmodell og realiseres som objekter i en datamaskin. Descartes paradigme Pådrag Naturlov Figur 4 Descartes paradigme Reaksjon Det klassiske modellbegrepet er knyttet til begrepet kausalitet og Descartes paradigme. Descartes utviklet en forestilling om at naturen består av elementer i et større system. Dette systemet oppfører seg som en maskin i samsvar med naturlover. Kausalitetsprinsippet sier at der er en sammenheng mellom årsak og virkning. Når systemet gies et pådrag, reagerer det med en respons i samsvar med naturlover. Descartes paradigme danner grunnlag for modellering av datatekniske tjenester. Motivet for denne modelleringen er på en eller annen måte å forutsi noe om framtiden for så å kontrollere noe i framtiden. Det er her tre sentrale konsepter. Disse er modellering, prediksjon og kontroll. Prediksjon Pådrag Algoritme Respons Figur 5 Prediksjon av framtiden Prediksjon er et estimat av en framtidig tilstand. Skal dette være mulig, kreves det at en kan lage algoritme, som er slik formulert, at en kan beregne noe om framtiden. Dette kan være realistisk når en kan lage en algoritme som oppfører seg i samsvar med en naturlov. Slike lover kan f.eks utvikles i samsvar med balanselikninger etter termodynamikkens 1. lov. En kan lage balanselikninger på grunnlag av: energibalanse, kraftbalanse, strømbalanse, økonomibalanse o.l. Denne type modellering er meget utbredt og danner grunnlaget for de fleste naturvitenskaper, teknologiutvikling og dermed grunnlaget for programvareutvikling. I andre tilfeller kan algoritmen være en plan. Prediksjon av framtid gir oss en forhåndsinformasjon for gjør oss bedre i stand til å kontrollere framtiden. Modell identifikasjon Pådrag Virkelig Respons Avvik system - Algoritme Respons Figur 6 Modellidentifikasjon I enkelte tilfeller kan det være vanskelig å identifisere de lovmessige regler i et virkelig system. Til gjengjeld kan en registre hva som skjer når det blir utsatt for et pådrag. En kan da tilpasse en algoritme til det den oppfører seg på samme måte som det virkelige system og variere algoritmen inntil en får et minimum avvik. Motivet for dette konseptet er da å identifiserte naturlovene til det virkelige system. Når en har oppdaget de regler som oppfører seg som det virkelige system, kan en f.eks erstatte dette systemet med en datamaskin som representerer deler av systemet. Dette er et grunnleggende prinsipp ved modellering av systemer.

12 HØGSKOLEN I ÅLESUND SIDE 12 Kontroll Forstyrrelse Ønsket Virkelig tilstand Virkelig tilstand Regel system - Figur 7: Kontrollkonsept Kontrollkonseptet er en teknikk for å redusere virkningen av forstyrrelse. I dette konseptet ønsker en å påvirke framtiden ved at en søker å påvirke et virkelig system over til en ønsket tilstand selv om det blir utsatt for forstyrrelse. Dette gjøre en ved å måle avviket mellom en systemtilstand og ønsket tilstand. Avviket blir så vektet med en algoritme og påtrykket det virkelige systemet i ønsket retning. Dette konseptet er bla grunnlaget for alt kontroll av instrumentering, kontroll av prosesser og kontroll under kvalitetssikring. Newtons matematikk Pådrag Matematisk Respons modell Figur 8 Matematisk modellering etter Descartes paradigme Newton var en av de som videreutviklet Descartes paradigme. Han utviklet en matematikk som representerte naturlovene. Dermed kunne han forutsi noe om framtiden. Naturlovene representerte han med en matematisk modell i form av lineære differensiallikninger av typen: Kontroll av industriell instrumentering og produksjon Å beregne utviklingen av økonomi Å beregne utviklingen av sykdommer, populasjoner og miljø o.l. Differensiallikninger er basert på prinsippet om kausalitet og lineære sammenhenger i naturen. Dette er i beste fall en tilnærmelse. Svært ofte er det slik at elementer i systemer ikke lar seg beskrive ut fra en matematisk modell. En må da benytte andre algoritmer for modellering av elementer fra virkeligheten. Modellen må da modelleres via andre ulineære metoder. I det etterfølgende skal vi se hvordan dette kan gjøres via objektorientert distribuert. 3.1 Dualitetsprinsippet Komponent Data Ting Substantiv Yin Operator Informasjon Relasjon Melding Motsatt komponent Aktivitet Hendelse Verb Yang Operand Prosess Element Objekt Tabell 1: Eksempler på motsatte komponenter Modeller beskriver deler av virkeligheten via et språk. Språket tar utgangspunkt i hvilke enkeltkomponenter en benytter til å beskrive algoritmen for en modell. Dualitetsprinsippet sier at modeller av virkeligheten kan beskrives som par av motsatte komponenter. Modeller som tekst beskrives via verb og substantiv. Matematiske modeller bruker operand og operator. Datatekniske systemer er modellert som aktiviteter og data. der x(t) er systemtilstand, u(t) er pådrag og v(t) er en forstyrrelse til systemet der A, B og C er parametere. Løser en denne differensiallikningen kan en forutsi hvordan et system utvikler seg over noe tid. Denne type modellering kan benyttes til å modellere dynamiske systemer. Eksempler er: Å beregne forløpet av en planetbane eller en kulebane i rommet Forløpet av banen til en robot Aktivitetsmodell Inndatastruktur Aktivitet Kontroll-datastruktur Ut-datastruktur Mekanisme Figur 9 Rammer rundt en aktivitet En aktivitetsmodell er bundet av eksterne datastrukturer. Disse datastrukturene er: 1. Inndata som aktiviteten transformerer fra en form til en annen 2. Kontrolldata som setter begrensninger for aktiviteten

13 HØGSKOLEN I ÅLESUND SIDE Utdata som er produktet fra aktiviteten 4. Mekanisme som realiseringen av aktiviteten Inndataene (I) representerer en henvendelse, spørsmål eller et pådrag til aktiviteten. Kontrolldata (C) setter begrensninger for hvordan dataene skal tolkes. Utdata (O) representerer svaret eller produktet fra aktiviteten. Vi kan da sette: Aktivitet = (A) Delaktiviteter + Inndata (I), Kontrolldata (C) og Utdata (O) Datamodell Figur 10: Rammer rundt data Kontroll-aktivitet Datastruktur Produsentaktivitet Konsumentaktivitet Mekanisme En datamodell er bundet av aktivitetsstrukturer. Disse aktivitetsstrukturene er: 1. Produsentaktiviteten produserer datastrukturen 2. Kontrollaktiviteter setter begrensninger for hvordan datastrukturen skal tolkes 3. Konsumentaktivitet er et sett en aktiviteter som mottar datastrukturen. 4. En mekanisme som er realiseringen av dataene. Dette kan formuleres som: Datastruktur = (D) Deldatastruktur + Produsent (I), Kontroll-aktivitet (C) og Konsument (O) 3.2 Balanseprinsippet Balanseprinsippet sier at en fullstendig beskrivelse av et system må modelleres via begge motsatte komponenter. Aktivitesmodeller og datamodeller har utgangspunkt i samme system, men gir noe forskjellige svar. En vesentlig forskjell på resultatene er at i aktivitetsmodellene får en fram hva som danner begrensninger for aktiviteten, og i datamodeller får en fram hva som danner begrensninger for data. Valg av modelltype vil være avhengig av hvilke sider av et system en legger mest vekt på å beskrive. eller fullstendighet. En modell er noe som representerer egenskaper ved virkeligheten. I tekniske systemer benyttes modeller til å gi oss svar på spørsmål om et emne tilknyttet systemet. Det kan være å utnytte modellen til å forutsi noe om systemets framtiden eller til å framkalle en bedre forståelse og innsikt om systemets oppførsel. Synspunkt Bakgrunn Synsvinkel SYSTEM Emne Figur 11: Valg av emne i et system En modell kan aldri gi en komplett beskrivelse av et system. Dersom en modell benyttes til å gi svar på spørsmål om et system, har den en toleranse som setter begrensninger på hvordan modellen kan representere systemet. Modellen har da et gyldighetsområde innenfor et emne. Toleranse Modellens toleranse sier noe om hvordan en modell M er i stand til i gi svar på spørsmål om et virkelig system S. Dette er avhengig av modellens karakteristiske egenskaper. Noen sentrale spørsmål omkring modellens toleranse er: 1. Kapasitet: Har modellen kapasitet til å frambringe data om systemets fundamentale egenskaper? 2. Realisme: Er modellen realistisk i forhold til et virkelig system? 3. Tilstandsutvikling: Kan modellen reprodusere den samme tilstandsutvikling som et virkelig system? 4. Overførbarhet: Er modellen overførbar til en bruker som ikke er fagperson i modellering? 5. Struktur: Avspeiler modellen systemets innebygde struktur? 6. Modularitet: Er modellen modulær slik at deler av modellen kan vedlikeholdes uten dette påvirker andre deler av modellen? 7. Innsikt: Kan modellen generere ny innsikt, nye ideer som en ikke kan få fram uten en modell? 8. Dataegenskaper: Er egenskapene til dataene i samsvar med dataene fra et virkelig system? 9. Prediksjon: Har modellen evne til å si noe om framtiden? 10. Kontroll: Kan modellen utnyttes til å kontrollere elementer fra et virkelig system? 3.3 Orientering Skal vi kunne utnytte en modell, må vi også sette kriterier for hva vi mener med modellens godhet Disse spørsmålene er av betydning for valg av modell. Dette valget har igjen betydning for valg av teknologi.

14 HØGSKOLEN I ÅLESUND SIDE 14 Hensikt og synsvinkel En modell av et emne er bundet via grensesnitt og strukturert via en orientering. Modellens beskrivelsen av grensesnitt avgjør modellens toleranse. Modellens orientering er gitt av: 1. Bakgrunn: Hva som er rammene for modellen 2. Synsvinkel: Hva som blir sett av emnet i modellen 3. Hensikt: Hvordan den blir betraktet 4. Synspunkt: Hvor modellen sees i fra Et emne er et aspekt ved et system eller et tema som begrenses i forhold til observatørenes synsvinkel. Observatøren betrakter emnet i forhold til teamets bakgrunn eller omgivelser. Temaet omslutter emnet og bakgrunn omslutter temaet. Hensikt avbilder systemets struktur. Synsvinkel avgrenser hva observatøren ser eller kan oppfatte som en sosial konstruksjon. Observatørens forståelse er avhengig av evne til å oppfatte flere emner innenfor samme tema via flere synsvinkler. Det betyr at forståelse og innsikt er noe som bygges opp via modeller med flere synsvinkler. Typiske synsvikler i modellering av systemer er: Eieren av systemet Kunden til systemet Utvikler av teknologi Offentlige myndigheter Organisasjon rundt systemet Økonomisk utbytte Brukergrensesnitt Der er en viktig forskjell mellom kausale systemer etter Descartes paradigme og en organisk systemforståelse. Kausale systemer kan beskrives objektivt via en algoritme eller en naturlov. Systemer er målsøkende av natur. Klassiske modeller av systemer er derfor prosesser og ikke stasjonære tilstander. I det etterfølgende skal vi se at dette er den grunnleggende forskjellen på klassisk modellering og systemorientert modellering. 4 ÅPNE SYSTEMER Datastruktur Algoritme Figur L: Klassisk programutvikling etter Descartes paradigme. John von Neuman Datamaskiner kan sammenlignes med maskin som mottar inngangsdata, mellomlagrer data i en intern datastruktur og produserer utdata i samsvar med en algoritme. Den bakenforliggende tankegang bygger på Descartes paradigme der algoritmen er et sett med regneregler mellom inndata og utdata. Algoritmer og de lokale data bestemmer programmets oppførsel. Datastrukturer er en organisering av pådragsdata, parametere og resultater av prosesseringen. Dette prinsippet ble utviklet av John von Neuman i 1940-årene og har vært en dominerende programmeringsfilosofi helt opp til i dag. Fordelen med prinsippet er at det bygger på en forholdsvis enkel filosofi som er enkel å realisere. von Neuman har her gitt oss en grunnleggende måte å tenke på som fortsatt preger vår måte å utvikle programvare. Denne tankegangen er så innarbeidet, at det for mange har vært nesten utenkelig å utvikle programvare ut fra et annet konsept. BRUKER Spørsmål Svar DATA I de første årene ble datamaskinene programmert i maskinkode, men allerede i 1950-årene ble det utviklet høynivåspråk som COBOL og FORTRAN. COBOL ble de dominerende språk i administrative anvendelser og FORTRAN fikk sin store utbredelse i tekniske anvendelser. Disse språkene er fortsatt de mest utbredte programmeringsspråk. ALGORI- TMER Figur 13: Bruker tilkoblet et åpent program

15 HØGSKOLEN I ÅLESUND SIDE 15 Programmer er koblet til en bruker via kommunikasjon. Brukeren kommuniserer ved å spørsmål til programmet som så gir svar tilbake. I denne prosessen opererer datamaskinen som et kausalt system der datamaskinens algoritmer og lokale data bestemmer svarene på de spørsmål som stilles. Dahl, Hoare og Djikstra Etter at en fikk høynivåspråkene, vokste mengden med programkode i datamaskinene. Det tok ikke lengre tid enn fram til midten av 1960-årene før det ble klart at det er et grunnleggende problem som er forbundet med utvikling av klassisk programvarearkitektur. I 1960-årene innførte Dahl, Hoare og Djikstra begrepet strukturert programmering. Det vil si at deler av programkoden kan sammenfattes i samlede blokker av transaksjoner. Hver av disse blokkene ble da en samlet algoritme. Dette førte til at vi i 1960-årene fikk en ny generasjon programmeringsspråk som er i utstrakt bruk den dag i dag. Noen viktige språk var: ALGOL som introduserte strukturert programkode LISP som introduserte symbolske lister PASCAL som introduserte abstrakte datatyper SIMULA som introduserte klassebegrepet (objekter) C som ble utviklet for operativsystem og nær kontroll av CPU-er. Et typisk trekk i denne utviklingen, var at en søkte å løse programvarekrisen med å utvikle nye strukturerte programmeringsspråk. Disse var basert på å strukturere bedre koden i blokker og sammenfatte data til abstrakte datatyper (som i PASCAL). Mye tyder på at programmeringskrisen hadde dypere årsaker og at dette har sammenheng med det paradigmet som lå, og fortsatt ligger, til grunn for modellering og programmering av datamaskiner. Klaus Wirth Klaus Wirth var en av de som introduserte abstrakte datatyper. Ideen her var å beskrive data på flere abstraksjonsnivå. Til tross for dette satte han definisjonen: datamaskinen. Det vil si at algoritmene ikke har avgrenset ansvar for vedlikehold av data. Ansvarsproblemet PROGRAM 1 Figur 14: Utvidelse av programpakker med felles ansvar for data Programmer er noe som vokser i omfang etter som en erverver nye kunnskaper. Et omfang på flere hundre tusen programlinjer i et datamaskinprogram er ikke uvanlig. Når programmene vokser, mister vi oversikten over hvilken del av programkoden som har ansvaret for å endre felles data. Det oppstår da usikkerhet i: Hvilken kode som har endret data Hvilken kode som er aktiv eller passiv Hvilken rekkefølge data blir endret Koblingen mellom endringene Systemets samlede oppførsel Resultatet av dette er et vedlikeholdsproblem. En antar at ca 90 % av programvarekostnader ligger i vedlikehold. Det har da vist seg at slike programmer har en tendens til å vokse inntil de blir ubrukelige. Integrasjonsproblemet Data FELLES DATA PROGRAM 2 Data Kall Algoritme 1 Algoritme 2 Svar Program = Algoritmer + Datastrukturer Algoritmer er et sett med transaksjoner som opererer på datastrukturer. Dette konseptet er i samsvar med funksjonalismen fra Descartes og John von Neuman. Et åpent program vil si at samtlige algoritmer og transaksjoner har tilgang til samtlige lokale data i Figur 15 Integrasjon av programmer. Programvare kan utvides ved å knytte sammen forskjellige pakker av programvare. En slik integrasjon av datatjenester krever: Et standard dataformat Et standard grensesnitt En standard terminologi

16 HØGSKOLEN I ÅLESUND SIDE 16 Standard metoder og algoritmer Standard prosedyrer for kommunikasjon mellom tjenester Dette har i praksis vist seg å være problematisk. Spesielt når en skal integrere programmer fra forskjellige dataleverandører. Modelleringsproblemet Et dataprogram blir aldri bedre enn den modell som ligger til grunn for programmet. Komplekse dataprogrammer skal modellere en kompleks virkelighet. Selv om programmet skal representere noe "enkelt" fra virkeligheten er det som skjer i et dataprogram et tilsynelatende kaos. Kompleks programvare setter derfor store krav til å ivareta et realistisk forhold mellom modell og virkelighet. Et datateknisk system er altså ikke bare begrenset av tekniske løsninger, men vår forståelse av modellen og det paradigme som ligger til grunn for modelleringen. Entropiproblemet Ny felles uorden ### Kompetanse om systemets oppførsel blir en ny kritisk faktor Mer orden på lavere nivå Mer kaos på høyere nivå En annen utviklingskjede er: Mer integrasjon av IT gir en høyere grad av automatisering En høyere grad av automatisering gir mer kundespesifiserte produkter Mer kundespesifisering av produkter gir mindre gjenbruk av data Mindre gjenbruk av data medfører mer kaos på et høyere nivå Når en slik integrasjon er foretatt, har en blandet både data og aktiviteter. Det er da oftest vanskelig å gå tilbake til et tidligere system. Vi står altså overfor et klassisk entropiproblem. Maskin/organisme En kan tenke seg forskjellige paradigmer som utgangspunkt for modellering av programvare. Vi kan f.eks modellere programvare som: En maskinorientert modell etter Descartes paradigme En organismemodell etter en systemorientert paradigme Program 1 Program 2 Figur 16: Integrasjon medfører en form for uorden Noe av ideen med å innføre IT, er å systematisere informasjon og derved skape en form kontroll eller orden. Det viser seg imidlertid at integrasjon av IT også medfører en form for uorden. Denne nye uorden blir introdusert i teknologi og organisasjon. Virkninger av vekst i programvare er: Endring i kompetanse og avstand mellom kunnskapsenheter Spesialisering av tjenester Forenkling av delkomponenter Standard grensesnitt mellom tjenester Abstraksjon av basistjenester Spesialisering av standard tjenester Hierarki av abstraksjoner Parallellitet mellom tjenester Resultat av dette er: Krav til mer kompetanse i delkomponenter Maskinmodell En oppfatning av programvare som en maskin, fører til sentralisering av data og programkode. Dette fører igjen til: All kode har tilgang til all data At en taper av syne at programmer skal representere noe fra virkeligheten En komplisert kontroll av kode Feil i programvare Liten fleksibilitet i programvare vedlikehold Store kostnader i vedlikehold av programvare En kort livssyklus for programvaren Sentralisert teknologi Overbelastede datamaskiner Systemorientert organismemodell Systemorientert paradigme er basert på å modellere programvare som en organisme der hver del utfører spesialiserte tjenester. Dette fører til: En spesialisering av delfunksjoner til abstraksjoner Desentralisering av ansvar En god forståelse av delfunksjoner Modularisering av tjenester Gjenbruk av programkode Lang livssyklus for programvare En mer forståelig totaloppførsel Desentralisert teknologi

17 HØGSKOLEN I ÅLESUND SIDE 17 e systemer Vi skal nå drøfte dette paradigmet mer i detalj. 5 REKURSIVE SYSTEMER 5.1 Systemanalyse Forståelse av naturens natur Vitenskapelig metode bygger på en arbeidsform der en utvikler modeller via analyse og syntese. Analyse er en oppdeling av et problem i dets underproblem. Syntese er utvikling av en modell for hvordan noe kan settes sammen. På den måten får en utviklet en modell av naturen. Har en utviklet en modell av naturen, kan en si noe om naturens natur. Det attraktive med slike modeller er at de kan utnyttes til å si noe om framtiden. Den som kan en si noe om framtiden, kan også påvirke framtiden. Systemteknikk er en arbeidsform som skal ivareta behovet for å finne fram til gode teknologiske løsninger på eksisterende problemer. I tillegg er systemteknikk en arbeidsform som skal hjelpe oss til å forutsi hvilke ressurser som skal til for å gjennomføre et prosjekt og hvordan et produkt skal konstrueres. I all står en oftest framfor to grunnleggende spørsmål. Disse dreier seg om hvordan vi kan redusere kompleksitet og hvordan vi på forhånd kan forutsi hvilke ressurser som skal til for å utvikle og vedlikeholde et system. Skal vi kunne få svar på disse spørsmålene, må vi ha et verktøy for å kommunisere abstrakt forståelse og å dele ideer. Matematikk og tekst har vært et nødvendig verktøy for all, men det viser seg av dette verktøyet ikke er tilstrekkelig til å bygge opp forståelse av komplekse sammenhenger. Bruk av modeller, for å beskrive naturens natur, oppstod hos grekerne som ville undersøke om verden styres av guder eller om der var spesielle lovmessige sammenhenger i naturen. Gallilei innførte en ny form for systematikk som var basert på modeller av naturens egenskaper via praktiske forsøk. Av den grunn blir Gallilei ofte kalt den første ingeniør. Newton og Leibnitz har fått æren for utviklingen av differensiallikninger. Det spesielle med differensiallikninger er at de sier noe om hvordan deler av naturen endrer seg over tid. Bruken av differensiallikninger dannet igjen grunnlaget for en mer nøyaktig modell av naturen og en ny forståelse av naturens natur. Denne nye forståelsen har igjen dannet grunnlaget for all moderne vitenskap. Differensiallikninger har hatt en bred anvendelse i all ingeniørvitenskap. Det viser seg imidlertid at disse modellene er svært ofte utilstrekkelige når sammenhengene i naturen er komplekse. Vi ser derfor i dag at klassisk ingeniørvitenskap står ved en skillevei. Dette har sammenheng den kompleksiteten som er knyttet til modellering i moderne ingeniørvitenskap, økonomi og samfunnsliv. Etter hvert som kompleksiteten av vitenskap har utviklet, seg har en etter hvert forstått at disse modellene har et begrenset gyldighetsområde. En har fått videreutviklet forståelse av betydningen av ulineariteter i naturen, startbetingelsenes betydning for resultatet fra modeller og vi betrakter ikke lenger kaos som støy. Videre har hjerneforskning gitt oss et nytt syn på hvordan vi kan betrakte komplekse sammenhenger via neurale nettverk. Alt dette har igjen medført at vi i de senere år også har endret vår forståelse av vår forståelse av naturens natur. Selv om matematikk stundom blir betegnet som den eneste "sanne" vitenskap, så opplever en svært ofte at i vanlig praktisk arbeide er matematikk et begrenset verktøy til å lage modell til å forutsi og kontrollere framtiden. Ved gjennomføring av prosjekter for utvikling eller produksjon av produkter, er en avhengig av å beskrive og formidle abstrakte tanker, ideer og bilder for å formidle hva som skal bli et forventet resultat. Dette kan løses med systemmodellering. Utvikling av datasystemer er et annet eksempel. Datasystemer utfører gjerne abstrakte funksjoner og de arbeider med abstrakte representasjoner av naturen. Utvikling av datasystemer krever derfor en annen systematikk enn den en finner i klassisk ingeniørvitenskap. I tillegg har en det forholdet at informasjonsteknologi er i ferd med å bli et verktøy innenfor alle fagområder. Anvendt informasjonsteknologi krever igjen nye krav til hvordan en mellom disse fagområdene skal representere sin kunnskaper i form av felles modeller. Utviklingen av disse modellene kalles Systemteknikk. Der er likhetstrekk og forskjell mellom Systemteknikk og klassisk naturvitenskapelig metode. Likheten ligger i den analysemetode og syntesemetode som benyttes til å framskaffe modeller som skal si noe om framtiden. Ulikheten ligger i at en i Systemteknikk bruker et annet begrepsaparat for å beskrive hvordan vi skal forstå virkemåten til et teknisk system eller en prosedyrer som framskaffer systemet. Systemteknikk baserer seg på en mer billedlig forståelse enn hva en finner i numeriske modeller. Dette krever igjen at vi forstår hvordan vi forstår vår forståelse.

18 HØGSKOLEN I ÅLESUND SIDE 18 Å forstå forståelse All er avhengig av enighet og felles forståelse. Selv uenighet forutsetter en felles forståelse av hva en er uenig om. Det er derfor av største betydning for all at en har et verktøy for kommunikasjon av forståelse og at en har klart for seg hva felles forståelse egentlig innebærer. Enighet forutsetter en form for felles beskrivelse av et mønster. Å skape dette mønsteret krever igjen en analyse. Analyse er oppdagelse at mønster i noe som kan være et mønster. Å analysere noe er således å skape et mønster, eller en sekvens av mønster, der en etter hvert oppdager nye mønster. Når vi analyserer noe, blir dette noe uberørt. Det som blir berørt er våre egne tanker som under analysen oppdager hva dette noe består av. Dette er analyse. Analyse krever således at vi har evne til å endre oss selv. Analyse involverer en syntese. En oppbygging av våre egne tanker i form av en modell av det som blir analysert. En kan da definere dette som: M er en modell av S hvis M kan brukes til å gi svar på spørsmål om systemet S. En slik modell krever ikke at M løser alle spørsmål om S, men to eller flere. Skal vi kunne utnytte en slik modell, må vi også sette kriterier for hva vi mener med modellens godhet eller fullstendighet. Skal vi kunne analysere et emne. Må vi bygge opp et mentalt bilde av emnet S og samtidig kontrollere at det er samsvar mellom mønsteret i emnet og vår forståelse av emnet S og om dette gir oss de riktige svar. Dersom det er samsvar mellom modellen M om emnet S, sier en at vi forstår emnet S i form av en modell. Det som i S ikke er i overensstemmelse med M i samsvar med "vår forståelse av vår forståelse", reiser uløste spørsmål. Når en lager en ny modell M1, som er mer i samsvar med S, har vi utvidet vår forståelse av emnet S. Dersom både modell M og M1 er i samsvar med emnet S, er vår forståelse av emnet utvidet. Det normale er at utvikling av modeller M1, M2,.., Mn utvider vår forståelse av emnet og hver enkel modell. Dette gir oss en suksessivt dypere innsikt. Hvordan hjernen forstår Selv om vi sier vi å forstår noe, så er det ikke opplagt hva forståelse egentlig er for noe. Det vi vet er at det har noe å gjøre med å gjenkjenne et mønster som har en logisk sammenheng. Skal vi se nærmere på hva forståelse er for noe, må vi være oppmerksom på hva og hvordan hjernen forstår. Det viser seg at hjernen er som en magnet, som må tvinges til ny forståelse. Denne motstand mot å endre forståelse, som vi alle har, er medfødt. Dette er en del av kroppens selvforsvar der en har behov for å utnytte langtidserfaring. Plutselige forandringer er for farlig til at de kan aksepteres av hjernen. Forståelse er derfor noe som må bygges opp gradvis. Hjernen forstår via mentale bilder. Den kan bare derfor bare kjenne igjen og identifisere det den kan forme som bilder. Når en bygger opp forståelse, vil hjernen kjenner igjen mønster som har en logisk sammenheng. Denne oppbyggingen er en prosess som bygges opp via modeller. Utvidet forståelse bygges opp via en ny modell M1 som basis for en ny observasjon av et emne. En trinnvis utvidelse av forståelse fra plattform til plattform er derfor nødvendig inntil vi har bygget opp en fullstendig modell for vår forståelse av et emne. Å forståelse et emne er noe subjektivt Når vi skal forstå et emne, så er forståelsen en syntese i vårt mentalt bilde. Forståelse av et emne er altså noe subjektivt som passer i vårt bilde. Ny forståelse av en emne bygger på at nye mentale modeller utfyller tidligere mentale modeller. Et system som er forstått, med ideer og ideer om ideer må forstås på samme måte. Forståelse bygger på kunnskaper, kunnskaper om kunnskaper, symboler og fakta. Emner bare er der. Forståelse av emner krever at vi må endre oss selv. Innsikt i innsikt Innsikt er å se årsak og virkning. Innsikt er derfor en forutsetning for å løse et problem. I hjernen er innsikt fragmenter av vår fantasi. Fantasi er løsrivelse fra fakta og tidligere erfaring. Fantasi er derfor nødvendig for å skape ny innsikt. Oppbygging av innsikt, og innsikt i innsikt, bygger på ny forståelse via en syntese av tidligere forståelse av modeller, fakta og fantasi til å utvikle nye modeller inntil bilder av modeller faller sammen. Utvikling av ny teknologi innebærer i praksis at en skal utvikle noe som ikke har eksistert tidligere. Dette krever innsikt. Innsikt erverver en via erfaring og modeller. Modell bygger vi opp av et begrepsaparat som på flere abstraksjonsnivå representerer det systemet vi skal utvikle.

19 HØGSKOLEN I ÅLESUND SIDE 19 Melding inn 5.2 Moduler Parnas Parnas var en av de som søkte å etablere en bro mellom teoretikerne på universitetene og praktikerene som utviklet store datasystemer i næringslivet. I begynnelsen av 1970-årene ledet han et større programvareprosjekt i det amerikanske forsvaret der målet var å utvikle mer pålitelige og funksjonelle programmer. I dette prosjektet utviklet han konseptet med moduler. Dette konseptet var et kompromiss mellom ideelle løsningsmetoder og krav til praktisk realisering. Parnas s 1. prinsipp Felles data Algoritmer Melding ut Modularitet Modularitet er en systemarkitektur som utelukkende består av moduler, i henhold til Parnass definisjon. Et system sies å være modulært når vi får moduler på mange nivåer innfører fastsatte grensesnitt. En modul får ikke referere, hverken eksplisitt eller implisitt til moduler på høyere nivå. Denne begrensningen fører til at en modul kan brukes i flere sammenhenger. Uniformitet Uniformitet er konsistens i den måten moduler representeres og refereres til. Dette medfører utbyttbarhet og dermed produktfleksibilitet. Videre får vi: Alternative moduler med lik ytelse Mer fleksibilitet i å tilpasse og vedlikeholde produktet Systemet kan trimmes ved utskiftning av moduler etter endring av spesifikasjoner. Figur 17: Parnas's modul etter første prinsipp. Parnas har definert en modul som en fysisk gruppering av tjenester. Disse tjenestene: Gjemmer interne data Gir en abstrakt beskrivelse av grensesnitt Deler en felles ressurs Utfører alle operasjoner på en felles dataressurs Har ingen direkte virkninger på andre moduler Vi ser videre at en slik modul er et åpent system. Konseptet er bygget opp som en Neuman-maskin i samsvar med Decarteses paradigme. Dette betyr at en modul av denne type er bare attraktiv så lenge modulen utfører en liten og spesialisert tjeneste. Parnas s 2. prinsipp Melding inn Kontroll Delmoduler Melding ut Innkapsling Spørsmål IC- TYPE Svar Figur 19: Et element som en elektronisk integrert krets (IC-komponenet) Dersom det ikke er ekstern tilgang til data innenfor en systemgrense, sier vi at systemet har en innkapsling. Det lukkede systemet kan betraktes som et element fra utsiden. Fra innsiden har elementet tilgang til alle interne data, men fra utsiden er det bare tilgang til elementets grensesnitt via meldinger. Et element kan således betraktes som en elektronisk komponent (IC-pakke) med bare tilgang fra utsiden. Figur 18: Parnass modul etter andre prinsipp I den utvidede versjon av Parnas's modulbegrep opererer moduler ikke på felles data, men på delmoduler. I dette modulbegrepet er alle dataene delegert til delmodulene. Dette er en attraktiv konstruksjn som også kalles Abstrakte maskin (Djikstra). Ulempen er at hver modul krever en form for administrasjon og kontroll av delmoduler. 5.3 Objekter Nygård og Dahl I 1967 utviklet Kristen Nygaard, Ole Johan Dahl og Bjørn Myhrhaug språket SIMULA 67. En viktig nyskaping ved dette språket var innføring av klassebegrepet. Dette var et lukket system med lokale data og lokal programkode. Klassene kunne betraktes som abstraktsjoner der implementeringen hadde klare likhetstrekk med sanntidsprosesser som på den tiden ble innført i sanntidsprogrammering og operativsystemer. Klassene

20 HØGSKOLEN I ÅLESUND SIDE 20 kunne skape kopier av seg selv under programkjøring, mellomlagres i køer og termineres etter at de hadde utført sin oppgave. Andre viktige sider ved SIMULA er at det har et innebygget begrepsapparat for å synkronisere hendelser i tid. Språket fikk sin utbredelse over hele verden. I første rekke ved universiteter og forskningsmiljø. Anvendelsene var mest knyttet til simulering der det ble satt store krav til modelleringsegenskaper. Først 20 år senere fikk språket sin internasjonale anerkjennelse. Det regnes nå som det første objektorienterte språk. I 1970 arbeideidet forskere ved Xerox Parc Place forskningssenter med å utvikle en ny generasjon IT-verktøy. Med inspirasjon fra SIMULA utviklet de språket Smalltalk som det første rene objektorienterte språk. I de senere år er det utviklet mer enn 100 objektorienterte språk. De mest kjente er Pascal 5.0, C++ og Eifel. Fordelene med Pascal 5.0 og C++ er at det kan utnytte gammel kode. Ulempen er at en får en kode som er en blanding mellom flere konsepter som øker risikoen for feil. I dette notatet vil vi basere oss på å bruke Smalltalk-80 som programmeringsspråk. Begrunnelsen for dette er at dette er et rent objektorientert språk og det kan benyttes til modellering av programvare på et høyt abstraksjonsnivå. Videre er språket meget godt utbygget med tjenester. Det er derfor svært godt egnet til modellering av distribuerte systemer. Definisjoner Et objekt er en representasjon av et systemelement i en datamaskin. Karakteristiske egenskaper ved objekter er: 1. Modularisering 2. Dynamisk binding 3. Evolusjon Spørsmål Figur 20: Objekt som systemelement Fra før vet vi at begrepet modularisering har vært et sentralt begrep i klassisk programmering. Vi ser altså at den virkelige nyskapingen i objektorientert programmering ligger i begrepene dynamisk binding og evolusjon. Dette medfører at bindingen mellom objekter via ulike typer relasjoner blir av stor betydning. Objekter får tilsvarende egenskaper som elementer i systemer. Spørsmål SYSTEM Element Identifikasjon Metode Figur 21 Identifikasjon av objekt Systemgrense Objekter har en identifikasjon, interne data og et sett med tjenester. Tjenestene er bygget opp av algoritmer som igjen er bygget opp av programtrinn eller transaksjoner. Grensesnittet til en tjeneste kalles en metode. Identifikasjon er navnet på et systemelement. Denne identifikasjonen er bundet av systemgrensen for et sett med elementer. Identifikasjon Svar Modularinsering vil si at objektene oppfyller kravet til modularitet i samsvar med Parnas's utvidede prinsipp. Dynamisk binding vil si at kommunikasjonen mellom objektene ikke er bestemt under kompilering. Den kan derfor fastsettes og endres under programkjøring. Dataelement Melding inn Identifikasjon Data Metode Melding ut Med evolusjon menes her at programkoden og tjenestene er ikke bestemt under kompilering. Programmet vokser og minsker under programkjøring. Figur 22. Dataelement Et dataelement kan defineres som: Dataelement = Representasjon + Operator

Objekt med Java. Harald Yndestad Høgskolen i Ålesund

Objekt med Java. Harald Yndestad Høgskolen i Ålesund Objekt med Java Harald Yndestad Høgskolen i Ålesund Dagens tema Objektorientert programmering Abstraksjon Modul-konseptet Arv Livssyklus 26.10.2002 HiÅ/KBS2001/Yndetad/JavaObjekt 2 26.10.2002 HiÅ/KBS2001/Yndetad/JavaObjekt

Detaljer

Vitenskapsteori og Kybernetikk

Vitenskapsteori og Kybernetikk 1 Vitenskapsteori og Kybernetikk Av Harald Yndestad INNHOLD 1. Innledning...1 2. Teorier om kunnskap...7 3. System epistemologi...11 4. System etikk...12 1. Innledning Figur 1 Elektronikk H va er egentlig

Detaljer

Funksjonalisme. Harald Yndestad

Funksjonalisme. Harald Yndestad Funksjonalisme Av Harald Yndestad HØGSKOLEN I ÅLESUND SIDE 2 INNHOLD 1. INNLEDNING... 3 2. REDUKSJONISME... 3 2.1. HISTORIKK...3 2.2. SUBSTANS...5 2.3. DUALISME...6 3. AVBILDNING... 9 3.1. REFLEKSJON...10

Detaljer

Læreplan i Programmering og modellering - programfag i studiespesialiserende utdanningsprogram

Læreplan i Programmering og modellering - programfag i studiespesialiserende utdanningsprogram 2.12.2016 Læreplan i - programfag i studiespesialiserende utdanningsprogram Formål Programmering er et emne som stadig blir viktigere i vår moderne tid. Det er en stor fordel å kunne forstå og bruke programmering

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

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

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

Generelt om operativsystemer

Generelt om operativsystemer Generelt om operativsystemer Hva er problemet? Styring av maskinvare og ressurser tilknyttet en datamaskin er komplisert, detaljert og vanskelig Maskinvare, komponenter og programvare endres og forbedres

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

Forsøkslæreplan i valgfag programmering

Forsøkslæreplan i valgfag programmering Forsøkslæreplan i valgfag programmering Gjelder bare for skoler som har fått innvilget forsøk med programmering valgfag fra 1.8.2016 Formål Valgfagene skal bidra til at elevene, hver for seg og i fellesskap,

Detaljer

Programbeskrivelse for revidert versjon av bachelorprogrammet Matematikk, informatikk

Programbeskrivelse for revidert versjon av bachelorprogrammet Matematikk, informatikk Programbeskrivelse for revidert versjon av bachelorprogrammet Matematikk, informatikk og teknologi (MIT) Tabell 1 Revidert versjon av Matematikk, informatikk og teknologi Programnavn: Vertsinstitutt: Navn

Detaljer

Endringskompetanse i Ingeniørfaget HiÅ 17.08.2015 50 år med Moore s lov Loven som har skapt innovasjon i 50 år

Endringskompetanse i Ingeniørfaget HiÅ 17.08.2015 50 år med Moore s lov Loven som har skapt innovasjon i 50 år Endringskompetanse i Ingeniørfaget HiÅ 17.08.2015 50 år med Moore s lov Loven som har skapt innovasjon i 50 år Prof. Harald Yndestad Hva er endringskompetanse? Budskap: Marked, teknologi og metode - Ny

Detaljer

INF2810: Funksjonell Programmering. En Scheme-evaluator i Scheme

INF2810: Funksjonell Programmering. En Scheme-evaluator i Scheme INF2810: Funksjonell Programmering En Scheme-evaluator i Scheme Erik Velldal Universitetet i Oslo 19. april 2016 Tema 2 Forrige uke Strømmer og utsatt evaluering Kort om makroer I dag Kap. 4 Metasirkulær

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

)RUVNQLQJVPHWRGLNNLQQHQ.XQVWLJLQWHOOLJHQV

)RUVNQLQJVPHWRGLNNLQQHQ.XQVWLJLQWHOOLJHQV .XQVWLJLQWHOOLJHQV01),7 )RUHOHVQLQJ Emner: )RUVNQLQJVPHWRGLNNLQQHQ.XQVWLJLQWHOOLJHQV - Revidert definisjon - AI som empirisk vitenskap - Kognitiv vitenskap som metodisk tilnærming - Epistemologiske problemer

Detaljer

STE6221 Sanntidssystemer LØSNINGSFORSLAG TIL EKSAMEN

STE6221 Sanntidssystemer LØSNINGSFORSLAG TIL EKSAMEN HØGSKOLEN I NARVIK Avdeling for teknologi MSc.-studiet EL/RT Side 1 av 3 STE6221 Sanntidssystemer LØSNINGSFORSLAG TIL EKSAMEN Tid: Torsdag 09.03.2006, kl: 09:00-12:00 Tillatte hjelpemidler: Godkjent programmerbar

Detaljer

INF2810: Funksjonell Programmering

INF2810: Funksjonell Programmering INF2810: Funksjonell Programmering Høyereordens prosedyrer, lambda og lokale variabler Erik Velldal Universitetet i Oslo 9. februar 2017 Tema 2 Forrige uke Lister og listerekursjon quote Høyereordens prosedyrer

Detaljer

INF2810: Funksjonell Programmering

INF2810: Funksjonell Programmering INF2810: Funksjonell Programmering Høyereordens prosedyrer, lambda og lokale variabler Erik Velldal Universitetet i Oslo 9. februar 2017 Tema 2 Forrige uke Lister og listerekursjon quote Høyereordens prosedyrer

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

Datasystemer og informasjonssystemer

Datasystemer og informasjonssystemer DRI1001 forelesning 2008 Hva er en datamaskin og hva kan den brukes til Prinsipper for datamaskinens virkemåte Kort om binære tall Litt om datamaskinens historie og faglig basis Data, informasjon og kunnskap

Detaljer

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning Systemutviklingsarbeidet et overblikk DRI2001 forelesning 21. sept. 05 Informasjonssystem og datasystem Hva er systemutvikling (SU) Et enkelt eksempel å bygge et hus Rammer og perspektiver for SU-arbeidet

Detaljer

Endringer i Ingeniørfaget HiÅ 19.08.2014 Leve med Moores lov Loven som har skapt innovasjon i 50 år

Endringer i Ingeniørfaget HiÅ 19.08.2014 Leve med Moores lov Loven som har skapt innovasjon i 50 år Endringer i Ingeniørfaget HiÅ 19.08.2014 Leve med Moores lov Loven som har skapt innovasjon i 50 år Prof. Harald Yndestad Hva er det du utdanner deg til? Min og din tid i faget Er det noe du kan lære fra

Detaljer

INF3110 Programmeringsspråk. Dagens tema. Typer (Kapittel 3 frem til ) Innføring i ML (Kapittel & ML-kompendiet.) 1/19

INF3110 Programmeringsspråk. Dagens tema. Typer (Kapittel 3 frem til ) Innføring i ML (Kapittel & ML-kompendiet.) 1/19 Dagens tema Typer (Kapittel 3 frem til 3.3.1.) Innføring i ML (Kapittel 7.4.3 & ML-kompendiet.) 1/19 Forelesning 2 27.8.2003 Typer En (data-)type består av: en mengde verdier en mengde operasjoner man

Detaljer

Informasjonsteknologi - masterstudium - 5 år

Informasjonsteknologi - masterstudium - 5 år Informasjonsteknologi - masterstudium - 5 år Vekting: 300 studiepoeng Fører til grad: Master i teknologi / sivilingeniør Heltid/deltid: Heltid Introduksjon Det femårige master i teknologi / sivilingeniørstudiet

Detaljer

Typer. 1 Type: boolean. 2 Verdimengde: {true, false} 3 Operatorer: NOT, AND, OR... 1/19. Forelesning Forelesning

Typer. 1 Type: boolean. 2 Verdimengde: {true, false} 3 Operatorer: NOT, AND, OR... 1/19. Forelesning Forelesning Dagens tema Typer (Kapittel 3 frem til 331) Innføring i ML (Kapittel 743 & ML-kompendiet) Typer En (data-)type består av: en mengde verdier en mengde operasjoner man kan anvende på disse verdiene Eksempel:

Detaljer

MNFIT-272 Kunstig intelligens Forelesning 4.

MNFIT-272 Kunstig intelligens Forelesning 4. MNFIT-272 Kunstig intelligens Forelesning 4. Emner: Søkesystemer - styring og kontroll av søk - søkesystemer i praksis Produksjonssystemer - regelbasert søking - som generell problemløsningsmodell - praktiske

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 31. Mai, 2011 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 6 sider Vedlegg:

Detaljer

SolidPlant er perfekt for deg som jobber med design av rørsystemer og anlegg, og er kjent med SolidWorks.

SolidPlant er perfekt for deg som jobber med design av rørsystemer og anlegg, og er kjent med SolidWorks. SolidPlant, det eneste virkelig spesifikasjonsstyrte anleggsdesign programmet for SolidWorks. Ved å kombinere intuitive parametrisk styrte SolidWorks med en sofistikert database for å generere alle komponenter

Detaljer

INF2810: Funksjonell Programmering. En metasirkulær evaluator

INF2810: Funksjonell Programmering. En metasirkulær evaluator INF2810: Funksjonell Programmering En metasirkulær evaluator Stephan Oepen & Erik Velldal Universitetet i Oslo 26. april 2013 Tema 2 Forrige uke Strømmer og utsatt evaluering Memoisering Kort om makroer

Detaljer

INF2810: Funksjonell Programmering. En metasirkulær evaluator

INF2810: Funksjonell Programmering. En metasirkulær evaluator INF2810: Funksjonell Programmering En metasirkulær evaluator Stephan Oepen & Erik Velldal Universitetet i Oslo 26. april 2013 Tema 2 Forrige uke Strømmer og utsatt evaluering Memoisering Kort om makroer

Detaljer

INF3430/4431. VHDL byggeblokker og testbenker

INF3430/4431. VHDL byggeblokker og testbenker INF3430/4431 VHDL byggeblokker og testbenker Entity/architecture Innhold Strukturelle design (nettliste) Generics Configurations Operatorer-Operator prioritet (precedence) Datatyper Bit / IEEE1164 std_ulogic

Detaljer

Forskningsseminar: Høgskolen i Ålesund: 05.04.2013 Fra Smart Grid, til Smarte Regioner

Forskningsseminar: Høgskolen i Ålesund: 05.04.2013 Fra Smart Grid, til Smarte Regioner Forskningsseminar: Høgskolen i Ålesund: 05.04.2013 Fra Smart Grid, til Smarte Regioner Harald Yndestad Smartere Byer Hva er motivet? 1 Urbanisering - Vekst av megabyer: ->50% i 2013, -> 70% i 2050 - Samtidig:

Detaljer

Viktige læringsaktiviteter

Viktige læringsaktiviteter Viktige læringsaktiviteter Læringsaktiviteter som dekkes av Aktiviteter Stille spørsmål. Utvikle og bruke modeller. = dekkes Planlegge og gjennomføre undersøkelser. Analysere og tolke data. Bruke matematikk,

Detaljer

MAT1030 Diskret Matematikk

MAT1030 Diskret Matematikk MAT1030 Diskret Matematikk Forelesning 27: Trær Dag Normann Matematisk Institutt, Universitetet i Oslo 4. mai 2010 (Sist oppdatert: 2010-05-04 14:11) Forelesning 27 MAT1030 Diskret Matematikk 4. mai 2010

Detaljer

Model Driven Architecture (MDA) Interpretasjon og kritikk

Model Driven Architecture (MDA) Interpretasjon og kritikk Model Driven Architecture (MDA) Interpretasjon og kritikk Ragnhild Kobro Runde (Ifi, UiO) Veileder: Ketil Stølen (Ifi/SINTEF) Stuntlunsj SINTEF Oversikt Bakgrunn/utgangspunkt for presentasjonen MDA stuntlunsj

Detaljer

Etter uke 6 skal du. Introduksjon til objektorientert programmering. Hva skjedde ~1967? INF1001. Grunnkurs i objektorientert programmering

Etter uke 6 skal du. Introduksjon til objektorientert programmering. Hva skjedde ~1967? INF1001. Grunnkurs i objektorientert programmering Etter uke 6 skal du Kjenne til motivasjonen for objektorientert programmering Introduksjon til objektorientert programmering INF1001 Høst 2016 Forstå hva en klasse er, og forskjellen på klasse og objekt

Detaljer

INF2810: Funksjonell Programmering. Mengder og lokal tilstand

INF2810: Funksjonell Programmering. Mengder og lokal tilstand INF2810: Funksjonell Programmering Mengder og lokal tilstand Stephan Oepen & Erik Velldal Universitetet i Oslo Kvinnedagen, 2013 Forrige gang 2 Dagens dont 3 Del 1 Litt mer om hierarkisk data. Representasjon

Detaljer

MAT1030 Diskret matematikk

MAT1030 Diskret matematikk MAT1030 Diskret matematikk Forelesning 23: Grafteori Dag Normann Matematisk Institutt, Universitetet i Oslo 16. april 2008 Oppsummering En graf består av noder og kanter Kanter ligger inntil noder, og

Detaljer

Oppsummering. MAT1030 Diskret matematikk. Oppsummering. Oppsummering. Forelesning 23: Grafteori

Oppsummering. MAT1030 Diskret matematikk. Oppsummering. Oppsummering. Forelesning 23: Grafteori Oppsummering MAT1030 Diskret matematikk Forelesning 23: Grafteori Dag Normann Matematisk Institutt, Universitetet i Oslo 16. april 2008 En graf består av noder og kanter Kanter ligger inntil noder, og

Detaljer

Forslag til ny læreplan for informatikk studieretningsfag

Forslag til ny læreplan for informatikk studieretningsfag Forslag til ny læreplan for informatikk studieretningsfag Jens Kaasbøll, undervisningsleder, Institutt for Informatikk Foredrag på Faglig-pedagogisk dag Universitetet i Oslo, 4. januar 2000 1 Behov for

Detaljer

INF2810: Funksjonell Programmering

INF2810: Funksjonell Programmering INF2810: Funksjonell Programmering Omgivelsesmodeller og destruktive listeoperasjoner Stephan Oepen & Erik Velldal Universitetet i Oslo 15. mars 2013 Tema 2 Forrige uke Representasjon av mengder Sorterte

Detaljer

INF2810: Funksjonell Programmering. En Scheme-evaluator i Scheme

INF2810: Funksjonell Programmering. En Scheme-evaluator i Scheme INF2810: Funksjonell Programmering En Scheme-evaluator i Scheme Erik Velldal Universitetet i Oslo 27. april 2017 Tema 2 Forrige forelesning Strømmer og utsatt evaluering Kort om makroer I dag Kap. 4 Metasirkulær

Detaljer

INF2810: Funksjonell Programmering

INF2810: Funksjonell Programmering INF2810: Funksjonell Programmering Omgivelsesmodeller og destruktive listeoperasjoner Stephan Oepen & Erik Velldal Universitetet i Oslo 15. mars 2013 Tema 2 Forrige uke Representasjon av mengder Sorterte

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

INF3430. VHDL byggeblokker og testbenker

INF3430. VHDL byggeblokker og testbenker INF3430 VHDL byggeblokker og Innhold Entity/architecture Strukturelle design (nettliste) Generics Configurations Operatorer-Operator prioritet (precedence) Datatyper Bit / IEEE1164 std_ulogic /std_logic

Detaljer

Forelesning 27. MAT1030 Diskret Matematikk. Bevistrær. Bevistrær. Forelesning 27: Trær. Roger Antonsen. 6. mai 2009 (Sist oppdatert: :28)

Forelesning 27. MAT1030 Diskret Matematikk. Bevistrær. Bevistrær. Forelesning 27: Trær. Roger Antonsen. 6. mai 2009 (Sist oppdatert: :28) MAT1030 Diskret Matematikk Forelesning 27: Trær Roger Antonsen Institutt for informatikk, Universitetet i Oslo Forelesning 27 6. mai 2009 (Sist oppdatert: 2009-05-06 22:28) MAT1030 Diskret Matematikk 6.

Detaljer

INF2810: Funksjonell Programmering

INF2810: Funksjonell Programmering INF2810: Funksjonell Programmering Høyereordens prosedyrer, lambda og lokale variabler Stephan Oepen Universitetet i Oslo 9. februar 2015 Tema 2 Forrige uke Lister og listerekursjon quote Høyereordens

Detaljer

InterAct Hvor er vi nå? Hvor skal vi? Knut STUA 11. februar 2015

InterAct Hvor er vi nå? Hvor skal vi? Knut STUA 11. februar 2015 InterAct Hvor er vi nå? Hvor skal vi? Knut STUA 11. februar 2015 Grunnleggende prinsipper 1. Baklengsdesign Innsatsfaktorer Læringsmiljø Lykkes faglig og profesjonelt På fakultetet, instituttene, programmene,

Detaljer

GJENNOMGANG UKESOPPGAVER 9 TESTING

GJENNOMGANG UKESOPPGAVER 9 TESTING GJENNOMGANG UKESOPPGAVER 9 TESTING INF1050 V16 KRISTIN BRÆNDEN 1 A) Testing viser feil som du oppdager under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.

Detaljer

Introduksjon til programmering og programmeringsspråk

Introduksjon til programmering og programmeringsspråk Introduksjon til programmering og programmeringsspråk Henrik Lieng Høgskolen i Oslo og Akershus https://code.org/ Veldig høy-nivå programmering med Scratch End-user programming Overtone, Tidal, etc., bygger

Detaljer

Introduksjon til objektorientert programmering

Introduksjon til objektorientert programmering Introduksjon til objektorientert programmering Samt litt mer om strenger og variable INF1000, uke6 Ragnhild Kobro Runde Grunnkurs i objektorientert programmering Strategi: Splitt og hersk Metoder kan brukes

Detaljer

Kvalitetssikring av IT-systemer på akkrediterte laboratorier (NA Dok. 51)

Kvalitetssikring av IT-systemer på akkrediterte laboratorier (NA Dok. 51) Kvalitetssikring av IT-systemer på akkrediterte laboratorier (NA Dok. 51) / Dok.id.: Veiledning/Guidance Formål Formålet med dette dokumentet er å gi en del retningslinjer for bruk og validering av IKT-systemer

Detaljer

Forelesning 23. Grafteori. Dag Normann april Oppsummering. Oppsummering. Oppsummering. Digresjon: Firefarveproblemet

Forelesning 23. Grafteori. Dag Normann april Oppsummering. Oppsummering. Oppsummering. Digresjon: Firefarveproblemet Forelesning 23 Grafteori Dag Normann - 16. april 2008 Oppsummering En graf består av noder og kanter Kanter ligger inntil noder, og noder kan være naboer. Vi bør kjenne til begrepene om sammenhengende

Detaljer

DRI2001 h04 - Forelesning Systemutvikling og nettsteder

DRI2001 h04 - Forelesning Systemutvikling og nettsteder Systemutvikling utvikling av offentlig nettsteder DRI2001 forelesning 20.10 Litt om eksperimentell systemutvikling og prototyping Systemutviklingsprosessene og utvikling av [offentlige] nettsteder Fasene

Detaljer

INF2810: Funksjonell Programmering. Oppsummering og eksamensforberedelser

INF2810: Funksjonell Programmering. Oppsummering og eksamensforberedelser INF2810: Funksjonell Programmering Oppsummering og eksamensforberedelser Erik Velldal & Stephan Oepen Universitetet i Oslo 18. mai 2017 I dag 2 Kort oppsummering Praktisk om eksamen Hvem vant konkurransen

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

Skal være utgangspunkt for å formulere. Vil inngå i veiledningene. Justeres av institusjonene.

Skal være utgangspunkt for å formulere. Vil inngå i veiledningene. Justeres av institusjonene. Læringsutbytte for studieretninger ingeniør Læringsutbytte i fastsatt forskrift om rammeplan 3 Læringsutbytte som gjelder for alle bachelorkandidater i ingeniørutdanningene. Formuleringer i fastsatt forskrift

Detaljer

INF2810: Funksjonell Programmering. Oppsummering og eksamensforberedelser

INF2810: Funksjonell Programmering. Oppsummering og eksamensforberedelser INF2810: Funksjonell Programmering Oppsummering og eksamensforberedelser Erik Velldal & Stephan Oepen Universitetet i Oslo 18. mai 2017 I dag 2 Kort oppsummering Praktisk om eksamen Hvem vant konkurransen

Detaljer

Kap3: Klassemodellering

Kap3: Klassemodellering Kap3: Klassemodellering I dag: Litt repetisjon fra sist (innledende om klassemodellen) Deretter egentlig litt mer repetisjon, men nå fra intro- Felt-/Instansvariabler og kurset i Java: Klasser og Objekt,

Detaljer

Læringsutbyttebeskrivelse, Fredrikstad FagAkademi

Læringsutbyttebeskrivelse, Fredrikstad FagAkademi Navn på utdanningen Nettverksadministrator med design Navn på emnet Windows klient/skybasert klient programvare Nivå 5,1 Kandidaten har kunnskap om bruk og oppsett av gjeldende Windows operativsystem.

Detaljer

Forelesning 29: Kompleksitetsteori

Forelesning 29: Kompleksitetsteori MAT1030 Diskret Matematikk Forelesning 29: Kompleksitetsteori Roger Antonsen Institutt for informatikk, Universitetet i Oslo Forelesning 29: Kompleksitetsteori 13. mai 2009 (Sist oppdatert: 2009-05-17

Detaljer

Request for information (RFI) Integrasjonsplattform

Request for information (RFI) Integrasjonsplattform Request for information (RFI) Integrasjonsplattform Trondheim kommune Trondheim kommune har initiert et prosjekt for å etablere en ny integrasjonsplattform TIP (Trondheim kommune Integrasjons Plattform).

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

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i INF3110/4110 Programmeringsspråk Eksamensdag: 3. desember 2004 Tid for eksamen: 9.00 12.00 Oppgavesettet er på 8 sider. Vedlegg:

Detaljer

7 tegn på at dere bør bytte forretningssystem

7 tegn på at dere bør bytte forretningssystem 7 tegn på at dere bør bytte forretningssystem Å bytte forretningssystem er en beslutning som modner over tid. En rekke problemstillinger har ført til at dere stiller kritiske spørsmål ved løsningen dere

Detaljer

Modellering og simulering av pasientforløp

Modellering og simulering av pasientforløp Modellering og simulering av pasientforløp Martin Stølevik, SINTEF martin.stolevik@sintef.no, tlf 22067672 1 Innhold Bakgrunn Beslutningsstøtte Pasientforløp Modellering Simulering Veien videre 2 Hvorfor?

Detaljer

Læreplan i teknologi og forskningslære - programfag i utdanningsprogram for studiespesialisering

Læreplan i teknologi og forskningslære - programfag i utdanningsprogram for studiespesialisering Læreplan i teknologi og - programfag i utdanningsprogram for studiespesialisering Fastsatt som forskrift av Utdanningsdirektoratet 6. april 2006 etter delegasjon i brev 26. september 2005 fra Utdannings-

Detaljer

Forelesning 25. MAT1030 Diskret Matematikk. Litt repetisjon. Litt repetisjon. Forelesning 25: Trær. Dag Normann

Forelesning 25. MAT1030 Diskret Matematikk. Litt repetisjon. Litt repetisjon. Forelesning 25: Trær. Dag Normann MAT1030 Diskret Matematikk Forelesning 25: Trær Dag Normann Matematisk Institutt, Universitetet i Oslo Forelesning 25 27. april 2010 (Sist oppdatert: 2010-04-27 14:16) MAT1030 Diskret Matematikk 27. april

Detaljer

7 tegn på at dere bør bytte forretningssystem

7 tegn på at dere bør bytte forretningssystem 7 tegn på at dere bør bytte forretningssystem Å bytte forretningssystem er en beslutning som modner over tid. En rekke problemstillinger har ført til at dere stiller kritiske spørsmål ved løsningen dere

Detaljer

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO DRI 2001 13.9 : Introduksjon til systemutvikling. Introduksjon til systemutvikling Systemutvikling og nettstedsutvikling Om ulike typer offentlige nettsteder Kvalitetskrav til offentlige nettsteder Litt

Detaljer

Systemutvikling. Universitetet i Oslo, Institutt for informatikk Vår 2017

Systemutvikling. Universitetet i Oslo, Institutt for informatikk Vår 2017 Systemutvikling Universitetet i Oslo, Institutt for informatikk Vår 2017 Dagens plan Introduksjon Emnets oppbygging Praktisk om ukesoppgaver og obligatoriske oppgaver Gjennomgang av ukesoppgaver Registrering

Detaljer

Hvordan kan vi sikre oss at læring inntreffer

Hvordan kan vi sikre oss at læring inntreffer Hvordan kan vi sikre oss at læring inntreffer Morten Sommer 18.02.2011 Modell for læring i beredskapsarbeid Innhold PERSON Kontekst Involvering Endring, Bekreftelse og/eller Dypere forståelse Beslutningstaking

Detaljer

Distribuerte objekter og objekt-basert mellomvare

Distribuerte objekter og objekt-basert mellomvare Distribuerte objekter og objekt-basert mellomvare INF 5040 H2004 foreleser: Frank Eliassen Frank Eliassen, SRL & Ifi/UiO 1 Hvorfor objekt-basert distribuert mellomvare?! Innkapsling " naturlig tilnærming

Detaljer

MAT1030 Diskret Matematikk

MAT1030 Diskret Matematikk MAT1030 Diskret Matematikk Forelesning 25: Trær Dag Normann Matematisk Institutt, Universitetet i Oslo 27. april 2010 (Sist oppdatert: 2010-04-27 14:15) Forelesning 25 MAT1030 Diskret Matematikk 27. april

Detaljer

DRI2001 forelesning

DRI2001 forelesning Systemutviklingsarbeidet et overblikk DRI2001 forelesning 6.10.04 Hva er systemutvikling (SU) Et enkelt eksempel å bygge et hus Rammer for SU-arbeidet Ulike SU-metoder Perspektiver i SU-arbeidet SU er

Detaljer

Kapittel 3: Litt om representasjon av tall

Kapittel 3: Litt om representasjon av tall MAT1030 Diskret Matematikk Forelesning 3: Litt om representasjon av tall Dag Normann Matematisk Institutt, Universitetet i Oslo Kapittel 3: Litt om representasjon av tall 26. januar 2010 (Sist oppdatert:

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

Distribuerte objekter og objekt-basert mellomvare

Distribuerte objekter og objekt-basert mellomvare Distribuerte objekter og objekt-basert mellomvare INF 5040 H2006 foreleser: Frank Eliassen INF5040 Frank Eliassen 1 Hvorfor objekt-basert distribuert mellomvare? Innkapsling naturlig tilnærming til utvikling

Detaljer

INF1300 Introduksjon til databaser

INF1300 Introduksjon til databaser INF1300 Introduksjon til databaser Data (transiente, persistente) DBMS databser informasjon interesseområdet informasjonsmodeller informasjonssystemer Transiente og persistente data Når vi programmerer,

Detaljer

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer...

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer... Side 1 1. Forord Dette dokumentet er en kravspesifikasjon og har blitt utarbeidet av arbeidsgiver og prosjektgruppen. Dokumentet består av ni kapitler. Det vil først bli presentert hvem prosjektgruppen

Detaljer

Velkommen til. INF våren 2017

Velkommen til. INF våren 2017 Velkommen til INF1010 - våren 2017 Idag: 1. time: Om INF1010 2.time: Om Objekter i Java 1 Stein Gjessing og Stein Michael Storleer Universitetet i Oslo 1 INF1010 Objektorientert programmering I INF1010

Detaljer

- analyse og implementasjon

- analyse og implementasjon - analyse og implementasjon Hvem er vi? Vi heter Anders S Finnerud Dennis JMJ Lundh studerer til bachelorgraden i ingeniørfag for data ved Høgskolen i Oslo. Oppgaven Lage et lett system som kan utføre

Detaljer

Datasystemer og informasjonssystemer

Datasystemer og informasjonssystemer DRI1001 forelesning 190906 Hva er en datamaskin og hva kan den brukes til Litt om datamaskinens historie og faglig basis Prinsipper for datamaskinens virkemåte Kort om binære tall Data, informasjon og

Detaljer

INF2810: Funksjonell Programmering. Tilstand og verditilordning

INF2810: Funksjonell Programmering. Tilstand og verditilordning INF2810: Funksjonell Programmering Tilstand og verditilordning Stephan Oepen Universitetet i Oslo 8. mars 2016 Forrige gang 2 I dag 3 Vi blar om til kapittel 3 i SICP. Tilstand og verditilordning. Destruktive

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

MAT1030 Forelesning 24

MAT1030 Forelesning 24 MAT1030 Forelesning 24 Grafteori og trær Roger Antonsen - 28. april 2009 (Sist oppdatert: 2009-04-28 22:32) Forelesning 24 Oppsummering En graf består av noder og kanter Kanter ligger inntil noder, og

Detaljer

Distribuerte objekter og objekt-basert mellomvare

Distribuerte objekter og objekt-basert mellomvare Distribuerte objekter og objekt-basert mellomvare INF5040 foreleser: Olav Lysne Frank Eliassen, SRL & Ifi/UiO 1 Hvorfor objekt-basert distribuert mellomvare? Innkapsling naturlig tilnærming til utvikling

Detaljer

Hume: Epistemologi og etikk. Brit Strandhagen Institutt for filosofi og religionsvitenskap, NTNU

Hume: Epistemologi og etikk. Brit Strandhagen Institutt for filosofi og religionsvitenskap, NTNU Hume: Epistemologi og etikk Brit Strandhagen Institutt for filosofi og religionsvitenskap, NTNU 1 David Hume (1711-1776) Empirismen Reaksjon på rasjonalismen (Descartes) medfødte forestillinger (ideer)

Detaljer

INF2810: Funksjonell Programmering. Tilstand og verditilordning

INF2810: Funksjonell Programmering. Tilstand og verditilordning INF2810: Funksjonell Programmering Tilstand og verditilordning Stephan Oepen Universitetet i Oslo 2. mars 2017 Forrige gang 2 I dag 3 Vi blar om til kapittel 3 i SICP. Tilstand og verditilordning. Destruktive

Detaljer

Operativsystemer og grensesnitt

Operativsystemer og grensesnitt Operativsystemer og grensesnitt Ulike måter å bruke OS'et på Application Program Interface (API) Applikasjoner (ofte C-programmer) som f.eks. emacs, som bruker tjenestene i OS ved å kalle på funksjoner

Detaljer

INF 4130. 8. oktober 2009. Dagens tema: Uavgjørbarhet. Neste uke: NP-kompletthet

INF 4130. 8. oktober 2009. Dagens tema: Uavgjørbarhet. Neste uke: NP-kompletthet INF 4130 8. oktober 2009 Stein Krogdahl Dagens tema: Uavgjørbarhet Dette har blitt framstilt litt annerledes tidligere år Se Dinos forelesninger fra i fjor. I år: Vi tenker mer i programmer enn i Turing-maskiner

Detaljer

Generell Systemteori. Av Harald Yndestad

Generell Systemteori. Av Harald Yndestad Generell Systemteori Av Harald Yndestad 2 Den overspesialiserte vitenskap uten sammenheng med fagene, Er en virksomhet, hvor der er mening i de minste ting men ikke i de største -- Piet Hein 3 Forord I

Detaljer

INF3110 Programmeringsspråk. Velkommen til kurset INF 3110/4110. Programmeringsspråk 1/24

INF3110 Programmeringsspråk. Velkommen til kurset INF 3110/4110. Programmeringsspråk 1/24 Velkommen til kurset INF 3110/4110 Programmeringsspråk 1/24 Forelesning 1 20.8.2003 Først det praktiske Foreleser: Roger Antonsen E-post: rantonse@ifi.uio.no Kontor: rom 3403 Treffetid: etter avtale Undervisning

Detaljer

INF 3110/4110. Velkommen til kurset. Programmeringsspråk. Først det praktiske

INF 3110/4110. Velkommen til kurset. Programmeringsspråk. Først det praktiske Velkommen til kurset INF 3110/4110 Programmeringsspråk 1/24 Først det praktiske Foreleser: Roger Antonsen E-post: rantonse@ifi.uio.no Kontor: rom 3403 Treffetid: etter avtale Undervisning Forelesninger:

Detaljer

INF3430/4430. Grunnleggende VHDL

INF3430/4430. Grunnleggende VHDL INF3430/4430 Grunnleggende VHDL 26.09.2005 20.57 Agenda Entity/architecture Strukturelle design (netlist) Generics Configurations Operatorer-Operator presedence Datatyper Bit / IEEE1164 Std_ulogic /std_logic

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF2810 Eksamensdag: Fredag 5. juni 2015 Tid for eksamen: 14:30 (4 timer) Oppgavesettet er på 4 sider (ikke medregnet denne siden)

Detaljer

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning Systemutviklingsarbeidet et overblikk DRI2001 forelesning 12. sept. 06 Forholdet mellom informasjonssystemet og virkeligheten Hva innebærer utvikling av et IS (systemutvikling: SU) Å utvikle et IS det

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

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

Fakultet for informasjonsteknologi, Kontinuasjonsløsning på SIF8037 Distribuerte systemer og ytelsesvurdering (Distribuerte systemer kun)

Fakultet for informasjonsteknologi, Kontinuasjonsløsning på SIF8037 Distribuerte systemer og ytelsesvurdering (Distribuerte systemer kun) Side 1 av 5 NTNU Norges teknisk naturvitenskapelige universitet Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Kontinuasjonsløsning

Detaljer