ObjektOrientert Systemutvikling del I

Presentasjon om: "ObjektOrientert Systemutvikling del I"— Utskrift av presentasjonen:

1 ObjektOrientert Systemutvikling del 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 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

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

12 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

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

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 { 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;} }

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

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 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 { }

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

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