ObjektOrientert Systemutvikling del I

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

2. 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

3. 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

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

5. 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

6. 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)

7. 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

8. 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”

9. II) Datamodellering • COBOL • 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

10. 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

11. OO og Simula 67 • Objekt-orientering startet i Norge • 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)

12. Verden består av objekter som samhandler • Verden består av objekter: • 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

13. 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

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

15. 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

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

17. 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.

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

19. 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();

20. 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. (dette gjelder C++ - ikke Java) • Hovedprogramhvor 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

21. 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 )

22. 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;} • publicvoid ta_ut_beløp(int beløp) • { saldo = saldo - beløp;} • publicvoid overfør (int beløp, konto konto2) • { ta_ut-beløp (beløp); • konto2.sett_inn(beløp); } • public int kontonummer ( ); { return kontonr;} • }

23. 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.

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

25. 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

26. eks Bankkonti 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' Flere nivåer av arv mulig: 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

27. 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 classbil (i C++) -ikke mulig i Java class bil : public stat, kø, grafikk { .... }; I Javakan vi gjøre noe lignende med grensesnitt: class bil implements stat, kø, grafikk { .... }

28. 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)

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

30. 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

31. 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) )

32. 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) Objektorienterte begreper, oppsummering