SYSTEMORIENTERT PROGRAMMERING

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

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

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

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

HØGSKOLEN I ÅLESUND SIDE 5 1.2 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

HØGSKOLEN I ÅLESUND SIDE 6 48. 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

HØGSKOLEN I ÅLESUND SIDE 7 1.3 INNHOLD 1 ORIENTERING... 4 1.1 FORORD... 4 1.2 BEGREPER... 5 1.3 INNHOLD... 7 2 INNLEDNING... 9 3 MODELLERING PRINSIPPER... 11 3.1 DUALITETSPRINSIPPET... 12 3.2 BALANSEPRINSIPPET... 13 3.3 ORIENTERING... 13 4 ÅPNE SYSTEMER... 14 5 REKURSIVE SYSTEMER... 17 5.1 SYSTEMANALYSE... 17 5.2 MODULER... 19 5.3 OBJEKTER... 19 5.4 DELEGERING... 21 5.5 ARV... 22 5.6 PROTOKOLL... 23 5.7 REDUKSJONISME... 23 6 SYSTEMDYNAMIKK... 26 6.1 TILORDNING... 26 6.2 ALGORITME... 28 6.3 OPPFØRSEL... 31 6.3.1 Tilstandsmaskin... 33 6.3.2 Dynamikk... 33 6.3.3 Agenter... 33 6.4 LIVSSYKLUS... 33 7 SYSTEM BINDING... 34 7.1 SYSTEMERS ANATOMI... 34 7.2 SYSTEM KOBLING... 34 7.2.1 Åpent system... 35 7.2.2 Tidsbestemt kobling... 35 7.2.3 Kobling via subset... 35 7.2.4 Kobling via lister... 37 7.2.5 Kobling via data... 38 7.2.6 Logisk kobling... 40 7.2.7 Sammensatt kobling... 40 7.3 SYSTEM KOHESJON... 40 7.3.1 Kohesjon via forbindelse... 41 7.3.2 Kohesjon via struktur... 41 7.3.3 Kohesjon etter systemgrense... 43 7.3.4 Sammensatt binding... 44 8 PROSESSER... 44 8.1 OPPFØRSELKONTROLL AV PROSESSER.. 45 8.2 RESSURSDELING... 48 8.2.1 Semaforer... 48 8.2.2 Avbrudd... 49 8.2.3 Gjensidig utelukkelse... 49 8.2.4 Dataoverføring... 49 8.2.5 Felles kø... 50 8.2.6 Fjerne metodelall... 51 9 DYNAMISK BINDING... 52 9.1 PARALLELLE TJENESTER... 52 9.2 MELDINGSTYPER... 53 9.3 VELGERTYPER... 54 9.3.1 Softwarebus... 54 9.3.2 Realisering av softwarebus... 55 9.4 ADRESSERINGSMETODER... 56 9.4.1 Reiserute... 56 9.4.2 Ordrebasert adressering... 57 9.4.3 Wormkonseptet... 57 10 REKURSIV DYNAMISK BINDING58 10.1 ABSTRAKTSJONSNIVÅ... 58 10.2 FRAKTALPROSESSOR... 60 11 TEKNISKE TJENESTER... 60 11.1 VINDUTJENESTE... 60 11.2 NETT-TJENESTE... 61 11.3 KONFIGURASJONSTJENESTE... 62 11.4 SIKKERHETS-TJENESTE... 62 11.4.1 Kryptografering... 63 11.4.2 Overføring via nett... 64 11.4.3 Dokumentintegritet... 64 11.4.4 Meldingautorisasjon... 65 11.4.5 Autorisasjon av passord... 65 12 LEKSJONER... 66 12.1 LEKSJON 1: MODELLERING... 66 12.2 LEKSJON 2: OPPSTART AV SMALLTALK66 12.3 LEKSJON 3: TRANSAKSJONER... 67 12.4 LEKSJON 4: LUKKEDE ELEMENTER... 69 12.5 LEKSJON 5: BASISTJENESTER... 70 12.6 LEKSJON 6: ARV... 71 12.7 LEKSJON 7: PROSESSER... 72 12.8 LEKSJON 8: MODELLERING... 73 12.9 LEKSJON 9: SENSOR MED SOFTWAREBUSS... 74 12.10 LEKSJON 10: BRUKERGRENSESNITT75 12.11 LEKSJON 11: PROSJEKTOPPGAVE.. 76 13 PROGRAMVARE... 77 13.1 E-MAIL... 77 13.2 SOFTWAREBUS... 78 13.3 SENSOR MED SOFTWAREBUS... 79 13.4 PREDICTOR... 79 13.5 PROBE... 80 13.6 LP-FILTER... 80 13.7 ALARM... 81 13.8 EULER... 82 13.9 TIKK-TAKK... 82 DISTR SYST UTV YNDESTAD DSKOMP3.DOC 1995

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

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 10-15 å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

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.

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.

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

HØGSKOLEN I ÅLESUND SIDE 13 3. 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.

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

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

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

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.

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.

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

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