ObjektOrientert Systemutvikling del I Arne Maus, førsteamanuensis, Inst for informatikk, Univ. i Oslo (tidl: Univ i Tromsø, Norsk Regnesentral, MYCRON, SIFF)

Oversikt – dag 1 Grunnbegreper Litt om OO programmering (C++, Java) OO analyse og design (systemutvikling) 8 stegs analyse/design metode OO samvirke UML og RationalRose - notasjon og metode OO databaser + Øvelsesoppgaver

OO programmering og systemutvikling Objektorientering er : en annen tenkemåte en annen måte å dele opp problemet og programmere dette mer effektiv for store systemer ikke valg av et bestemt OO-programmeringsspråk Objektorientering dekker programmering systemutvikling dokumentproduksjon brukergrensesnitt databaser operativsystemer, nett gjenbruk av programvare

OO-begreper Spesielle trekk historikk forhold verden modell notasjon klasser og objekter pekere og dynamisk hukommelseshåndtering innkapsling av moduler arv / virtuelle gjenbruk

Hvorfor en nytt programmerings-paradigme (stil) ? Programvare-krisen : Store systemer, kompleksitet, kostnader Mer dynamiske systemer Vedlikehold av programvare dyrt (ca. 70% av kostnadene) Feilretting Nye krav Bedre brukervennlighet, nytt grafisk grensesnitt Preventivt vedlikehold

Programmerings-stiler, historikk Prosedyreorientert, strukturert programmering Teknisk/vitenskapelig miljø Datamodellering Forretningslivet, IBM Objektorientering “Alle” miljøer, men startet i teknisk miljø. + Applikativ/funksjonell programmering (Lisp, ML) + Logikkprogrammering (Prolog)

I) Prosedyreorientert, strukturert programmering Modellerer løsningen som en rekke med handlinger FORTRAN, C, Pascal State maskiner, transisjonsmatriser Prosedyre begrepet Navngi samling av handlinger, generalisere løsningen ved parametre Dynamisk hukommelses bruk Stakken, rekursive prosedyrer

Top-down analyse Problemet løses ved kall på en prosedyre “Løs_problemet” Denne handlingen deles opp i flere under/del-handlinger Disse deles opp igjen .... inntil hver del blir liten nok og lett å kode Handlingen er alt deklarasjoner spres omkring “tilfeldig”

II) Datamodellering COBOL Relasjonsmodellen statiske relasjoner Navn på sammensatte data, records (Data Section) Operasjoner på sammensatte data Relasjonsmodellen statiske relasjoner SQL Entity-Relationship NIAM Data er “alt” handlingene i prosedyre-divisjonen er trivielle Alle skulle kunne lage Cobol, SQL, 4GL,...programmer selv

III) Objektorientering & systemperspektiv Data og handling like viktig, både: Prosedyrer (= navn på sammensatte handlinger , kalt metoder) Recorder (=navn på sammensatte data) Utgangspunkt i simulering modellering av verden Som programmerere/systemerere lager vi: en modell av den del av verden vi lager system for forholder vi oss til brukere og andre systemer bruker en viss mengde isenkram (maskiner, kommunikasjonslinjer, sensorer, skjermer, skrivere,..) til å realisere systemet

OO og Simula 67 Objekt-orientering startet i Norge Smalltalk To skoler O.J.Dahl og K. Nygaard Simula I og Simula 67 Simuleringer (modellerer verden som en rad med prosesser) La ikke selv vekt på “objekt-orienteringen”, brukte selv ikke ordet. Smalltalk Allen Key Apple/MacIntosh To skoler Skandinavisk (Simula, C++, Java, Eiffel, Fortran, Cobol...) “Ren OO” “alt” er objekter (Smalltalk, Actor)

Verden består av objekter som samhandler Hus, trær, mennesker, bankkonti, regninger, ansatte, studenter, biler,.. Objekter i data-systemet objekt = Data til en ‘gjenstand’ + operasjoner på denne objekter kan oppretter andre objekter gjør operasjoner på hverandre (kaller metoder) = “sender meldinger” til hverandre Objekter består av både data og operasjoner som logisk hører sammen med disse data og dette objektet

Forholdet mellom system og verden Som programmerere/systemerere velger vi ut: den del av virkeligheten vi er interessert i (problemområdet) de delene av dette som er interessante for vårt formål (problemområdets objekter med tilpasset detaljeringsnivå) Programmet / systemet skal gjenspeile verden en-til-en Ett objekt i vår del av verden => ett objekt i systemet + objekter for i/o + av og til ‘finnes’ bare objektene i maskinen eks. bankkonto

Startpunkt: OO-programmering Forstå begrepene ved å se dem nyttet i programmering objekter og klasser pekere innkapsling arv, super/subklasser - generalisering/spesialisering virtuelle metoder (polymorfisme)

Objekter og klasser Bare én klasse = beskrivelse/mal for hvordan objektene dine skal se ut eks: bare én beskrivelse av hvordan en honnørkonto ser ut Ett eller flere (mange) objekter samtidig av en klasse eks: mange ‘honnørkonto’ objekter i et kjørende banksystem Et objekt er som en metode som ligger igjen i hukommelsen etter at den er ‘ferdig utført’, og hvor vi kan: Få adgang til lokale data i objektet Kalle de lokale metodene i objektet

Klasser og objekter Klasser er fellesbeskrivelser av like objekter data (ikke tilgjengelig utenfra) synlige operasjoner = “grensesnitt med tilbud av tjenester” interne hjelpe- operasjoner

Data og operasjoner som en naturlig enhet - eks 1 Eks: STUDENT REGISTER Hvordan representere en student ( lage class student) Data: navn, adresse, personnummer + ‘ et visst antall’: (kursnavn, karakter) Operasjoner ( dvs. metoder) meld_opp_til_eksamen (kurs) registrer_eksamens_karakter (kurs, karakter) regn_ut_gjennomsnitt_karakter ( ) skriv_ut_vitnemål( ) N.B. Dette er operasjoner på bare én student.

Pekere & dynamisk hukommelse Objekter får man adgang til via peker-variable (adresser) Objekter opprettes og ‘dør’ under eksekvering (variabel datastruktur)

Hvordan opprette objekter, hvordan få tak i innholdet class Bil {int regnr; String eier; } Bil minbil; Bil dinbil; minbil = new Bil(); minbil.regnr = 476767; dinbil = new Bil();

Objekt-Orientert program Klasse-deklarasjoner (med datadel og operasjoner i form av metoder) Deklarasjon av andre globale variable (dette gjelder C++ - ikke Java) Evt. metoder som ikke er med i noen klasse. Hovedprogram hvor det bl.a opprettes noen objekter, og man begynner å kalle operasjoner i disse objektene.... I Java : ALT er klasser og objekter. Hovedprogrammet er inne i en av klassene

Innkapsling Bare nødvendige operasjoner synlige fra utsiden Vi skiller altså sterkt mellom: Grensesnittet til en klasse = De operasjonene den tilbyr resten av programmet Implementasjonen av dette og alle detaljene inne i klassen eks i Java: (neste foil )

{ saldo = saldo + beløp;} public void ta_ut_beløp(int beløp) public class konto { int kontonr, saldo; String eier ; konto( int knr, String s) { kontonr = knr; eier = s; saldo = 0;} public void sett_inn(int beløp) { saldo = saldo + beløp;} public void ta_ut_beløp(int beløp) { saldo = saldo - beløp;} public void overfør (int beløp, konto konto2) { ta_ut-beløp (beløp); konto2.sett_inn(beløp); } public int kontonummer ( ); { return kontonr;} }

Objektorientering basis, oppsummering Komponenter i programmet representeres som objekter OO programmer ‘simulerer’ virkeligheten, ett objekt i programmet for hvert ‘ting’ i virkeligheten + objekter som representerer deler av løsningen (vinduer og knapper på skjermen, en printer, ..) Objekter har både data og operasjoner Objekter deklareres som klasser (det kan være mange objekter av en klasse) Objekter genereres dynamisk (med new) Innholdet (variable og metoder) fås adgang til ved pekervariable Innkapsling betyr at selve implementasjonen av en klasse skjules. Hver klasse fremstår bare med et sett av veldefinerte operasjoner (metoder) overfor resten av systemet.

Objektorientering, ’avanserte’ begreper I. Arv av egenskaper - subklasser II. Redefinering av operasjoner - virtuelle metoder

I. Subklasse = Arv av egenskaper Problem: Flere av klassene i et program er ganske like,har felles deler. Må disse delene skrives flere steder ? Ikke: Skrive klasse som er summen ave-egenskapene, teste med statusbit etc. hva som nå er tilfellet. Eks: Bankkonti lønnskonto, honnørkonto og høyrentekonto har mye felles Løsning: subklasser Skriv først felles del som egen klasse

eks Bankkonti Flere nivåer av arv mulig: public class konto { String navn, adresse; int saldo, rentefot,kontonummer; } class lønnskonto extends konto { String arbeidsgiver; int arbeidsgiver_nummer; class høyrente extends konto { int ant_årlig_uttak; .... Et objekt av class lønnskonto vil bestå av to deler: alt definert i 'konto' og i tillegg alt definert i 'lønnskonto' konto lønnskonto høyrente selvstendig næringsdrivende ansatt offentligansatt privatansatt Et objekt av typen ‘privatansatt’ inneholder da alle deklarasjoner (data+funksjoner) i konto, lønnskonto, ansatt og privatansatt

Multippel arv EKS. Ferdige klasser for a) statistikk (class stat) b) være med i køer (class kø) c) grafisk brukergrensesnitt (class grafikk) Vi ønsker alle disse i vår class bil (i C++) -ikke mulig i Java class bil : public stat, kø, grafikk { .... }; I Java kan vi gjøre noe lignende med grensesnitt: class bil implements stat, kø, grafikk { .... }

Når bruker vi subklasser ? a) som arv: Verktøyboks-tankegangen ved ferdig definerte systemklasser (vanligst) b) ved stadig utbygging av fellesdeler i egne klasser (klassifikasjon dvs.generalisering og spesialisering) Ikke definer ikke for mange nivåer , det er ofte en dårlig klassifikasjon (medfører også mye blaing i koden)

II. Virtuelle metoder Redefinering av operasjoner Eks: Renteberegning public class konto { int saldo,......; public int beregn_renter () {..'vanlig renteberegning'...} public void årsoppgjør () {.. saldo = saldo + beregn_renter(); } class honnør extends konto { ... {... 'beregn renter etter honnør-måten' Redefinering av operasjoner Eks: Renteberegning Alle kontotyper unntatt honnørkonti beregner renter på samme måte

Tomme virtuelle Eks: Grafiske brukergrensesnitt Definerer en rekke virtuelle metoder som: Mouse_button_down(); Key_down(); Disse kalles i systemklassene, men gjør da ingenting Vi kan skrive våre versjoner av disse virtuelle metodene, og sørger da for at våre brukerdefinerte handlinger blir kalt istedenfor, i systemklassene. Dette er systemets måte å la programmereren gripe inn i systemets (predefinerte) operasjoner Tilsvarende i Visual Basic, DCOM/ActiveX Controls

Når bruker vi virtuelle metoder a) Til redefinering av egne metoder i egendefinerte klasser ( som: beregn-renter( ) dette er ikke veldig vanlig ) b) Til redefinering av ferdigskrevne systemklasser gripe inn i systemklassenes oppførsel. (ganske vanlig og mer vesentlig enn a) )

Objektorienterte begreper, oppsummering Abstraksjon (hva det modellerer) Innkapsling (skjuler implementasjon) Modularisering (oppdelingen av problemområdet) Hierarki (subklasser/arv) Gjenbruk (subklasser /virtuelle metoder) Typing (skille mellom objekter av ulike klasser, metoder og ulike dataelementer) Prosess-egenskap (passiv, aktiv, parallellitet) Persistent (overlever i en database)