Vi ser på mobilen mange titals gonger kvar dag. Er det ikkje Yr, så er det Vipps eller Facebook. Den eine appen etter den andre gjev oss informasjon og tenester vi ikkje greier oss utan. Nesten alle appane har flotte brukargrensesnitt, og dei dreg nytte av data frå databasar som finst ein eller annan plass der ute i verda, det vere seg vêrdata eller bankinformasjon.

Programvara for slike appar er ikkje lett å utvikle. Utviklarane må handtere mange nivå av kompleksitet. Dei må lage programvarekomponentar som handterer datakommunikasjon, lagrar data og hentar inn data frå sensorar. Og dei må formidle informasjon slik brukarane forventar, og slik firmaet som leverer tenester gjennom appen, vil at det skal vere.

For å få alt dette til å henge saman brukar utviklarane noko som vert kalla ein modellvisingskontrollar. Bak det lange ordet ligg det ei tredeling av ansvar i systemet. Éin del er modellen som har informasjonen, vi har ein visingsdel som viser informasjonen, og så har vi kontrollaren som styrer informasjonsflyten fram og tilbake mellom modell og vising.

Dette er ein struktur brukt i tusenvis av appar, og han har gjeve programutviklarar ei ramme for å gjere programvare fleksibel og lett å tilpasse til endringar i data- og brukargrensesnitt.

Han som i 1978 var den første som skildra dette arkitekturprinsippet, var den no 92 år gamle (og norske) Trygve Reenskaug, som har ein lang karriere bak seg som forskar og praktikar rundt utforming av programvaresystem. Var det nokon som sa at nordmenn ikkje er innovative?

Kva slags behov var det Reenskaug såg, som gjorde at han fekk ideen om modell­visingskontroll?

Det grunnleggande verktøyet for utvikling av appar er programmeringsspråket. Det er dette ingeniøren brukar til å skildre handlingane som programmet skal gjere. Men programlinjene vert fort mange. Spagettiprogrammering er eit velkjent problem i programutvikling. Programma vert meir og meir innfløkte ettersom nye ønske og idear kjem til, og til slutt veit ein ikkje kvar ein sekvens av handlingar startar og sluttar, eller i det heile tatt kva som skjer.

Ein har funne opp teknikkar for å bygge programmodular, som objektorientering. Objektmodulane har ansvar for konkrete ting i applikasjonsdomenet, som sjakkbrettet i eit sjakkprogram eller lånet i ein bankapplikasjon. Modulane har data, som brikkenes plassering i sjakkbrettet, og handlingar vi kan utføre på objektet, som det å flytte ei brikke på brettet.

Men til og med objektorientering gjev oss utfordringar. Kva er viktig nok til å verte definert som eit objekt? Skal sjakkbrikka vere eit objekt eller berre ein talkode på ei rute i sjakkbrettet? Banklån har vilkår som rentesats og om ein skal ha annuitetslån eller serielån. Skal dette vere enkle eigenskapar knytte til kvart lån, eller er det fornuftig at banken opererer med lånevilkårsobjekt som kan vere felles for mange lån?

Dei vala ein tar, vil ha implikasjonar for kor lett det er å endre programsystemet om det kjem nye krav frå brukarar og tenesteytarar. For eksempel om nye serielån skal ha ein ny måte å rekne renter på. Då kan ein gje dei nye låna ei kopling til det nye lånevilkårsobjektet, som veit korleis ein reknar rente for det nye lånet. Dei gamle låna vil framleis bruke det gamle lånevilkårsobjektet og vert ikkje påverka av endringa.

Etter kvart som vi har fått ei betre forståing av korleis programsystem skal byggast, har ein utvikla eit stort repertoar av programvarearkitekturar som gjev råd om korleis ein skal bygge programvare. Ein brukar ordet arkitektur fordi desse indikerer ein overordna struktur, slik som ein i vanleg arkitektur har ulike måtar å strukturere bustadhus, fabrikkar eller kontorbygg på.

Arkitekturen vert støtta av teknikkar, ofte kalla designmønster, som gjev idear om korleis ein skal definere objekta i systemet, og korleis dei skal fordele data og handlingar seg imellom. Ein parallell kan vere at arkitektar har overordna reglar som fortel kva rom det er fornuftig å ha dører imellom. I eit bustadhus er det til dømes ikkje vanleg å gå gjennom kjøkkenet til badet.

Struktur må til for programutvikling, og dette kan Reenskaugs modellvisningskontrollar hjelpe til med. I Vipps-appen kan du trykke på «send» og be om å få sendt pengar; eit nytt skjermbilete dukkar opp, og du kan taste inn informasjon om betalinga. Alt det du ser, trykker på og tastar inn, er ein del av visingsdelen av systemet.

Kontrollaren lyttar til aktivitetane dine (utviklarar seier gjerne dette). Når du trykker på «betal», registrerer kontrollaren det. Han hentar data frå visingsdelen, sjekkar dei og sender det som trengst, vidare til modell-delen. Modell-
delen er oftast ikkje på mobilen din, men hos banken, og samspelet vert realisert med avansert, kryptert datakommunikasjon.

Modellen tar imot transaksjonar og prøver å gjennomføre dei. Normalt vert det sendt ei stadfesting av betalinga tilbake til kontrollaren. Om det ikkje er pengar på kontoen, vert også dette meldt frå om til kontrollaren. Kontrollaren veit korleis ein skal handtere slike meldingar, og formidlar passande informasjon til brukaren gjennom visingsdelen.

Datamaskinteknologien har mange nivå, frå grunnleggande elektronikk til brukargrensesnitt. Blant desse nivåa finn vi programvarearkitektur og andre teknikkar for utforming. Utviklarar er avhengige av eit stort repertoar av slike teknikkar for å handtere kompleksiteten som finst i kvardagsteknologien vår.

Modellvisingskontroll er éin teknikk, og sjølv om dei færraste utanfor databransjen har høyrt om han, nyt vi alle godt av han når vi brukar appane våre.

Bjørnar Tessem og Lars Nyre