1 OO systemutvikling, del 3  Nominalist eller realist ?  OO egenskaper  Generelt om OO Analyse & Design  En 8-stegs metode for OO Systemering (analyse.

Presentasjon om: "1 OO systemutvikling, del 3  Nominalist eller realist ?  OO egenskaper  Generelt om OO Analyse & Design  En 8-stegs metode for OO Systemering (analyse."— Utskrift av presentasjonen:

1 1 OO systemutvikling, del 3  Nominalist eller realist ?  OO egenskaper  Generelt om OO Analyse & Design  En 8-stegs metode for OO Systemering (analyse og design)

2 2 Forholdet mellom det generelle og det spesielle (klasser og objekter)  Det generelle, eksisterer det egentlig, eller er det noe vi har funnet på for å beskrive/snakke om verden på en enklere måte.  Vesentlig debatt på 1100-tallet for systemutviklere 1) Eksisterer slike fellesbegreper, eller er det ‘bare’ vår egen begrepsdannelse. 2) Hvis de eksisterer, er de av fysisk eller åndelig natur. 3) Eksisterer det generelle evt. fritt fra de enkelte individene, eller ‘bare’ som del av disse. Eks: kråker, mennesker

3 3 ‘nominalist’ eller ‘realist’  Nominalist Det som eksisterer er bare enkeltindividene. Generelle fellesbegreper er skapt av menneskene (for bedre å forstå/beskrive verden). (eks. Wilhelm av Occam og Charles Darwin):  Realist Slike fellesnavn (kråke, menneske) har en egen eksistens (og enkeltindividene er dannet etter disse) (eks: Platon og Thommas av Aquinas)

4 4 Konsekvenser for systemutvikleren  Nominalist: Vi lager selv våre begreper (våre klasser), det finnes ingen fasit/riktig svar. Det er vårt ansvar å gjøre dette. (men vi tar selvsagt ofte utgangspunkt i vanlige begreper vi ha lært oss på skolen og ellers).  Realist Det finnes alltid et gitt sett med generelle begreper for det vi skal systemere. Vårt systemer er avhengig av at vi greier å fange dette ‘egentlige’ ved de enkelt gjenstandene vi lager klasser for.

5 5 OO-begreper, oversikt  Klasser og objekter  generelle typer og enkeltforekomster  informasjonsskjuling, grensesnitt til systemet  Pekere  dynamiske datastrukturer  uttrykke forhold mellom objekter  Arv / subklasser  generalisering og spesialisering, klassifisering, deling av kode  forholdet mellom klasser  Virtuelle prosedyrer  redefinering av operasjoner  utsatt definering av operasjoner  kommunikasjon med klassebiblioteker

6 6 Analyse : Hva er objektene ?  Prinsipper for objekt - og klasse-definisjon og modellering:  Naturlig modellering - som datamodellering  Ser da særlig på problemdomenet  Klassers ansvar og kontrakter, klienter og tjenere.  Ser på klassenes funkjonalitet, sammenheng mellom klassene - også løsningens tilleggsklasser  Minimale snitt, informasjonsskjuling  Prøver å sette sammen det som naturlig hører sammen, få en løsning som blir enklest mulig.

7 7 Ytre egenskaper de essensielle data som beskriver gjenstanden + de logiske operasjonene andre (dvs. i hovedsak prosedyrer i andre klasser) skal få gjøre med et slikt objekt. Ytre egenskaper er grensesnittet: Minimalt og veldefinert eks.: Radio, TV Indre egenskaper 'hjelpevariable' har med implementasjonen alt fra enkle løkke-variable til f.eks kompliserte datastrukturer og prosedyrer for effektiv implementasjon Mekanismer (private, protected) til å skjule disse hjelpevariable. Bare ytre egenskaper tilgjengelig "utenfra”via grensesnittet. Grensesnittet skal (ideelt sett) bare bestå av bare funksjoner. Indre og ytre egenskaper informasjonsskjuling

8 8 Grensesnitt ved kall på funksjoner All skriving og lesing på variable fra andre klasser,prosedyrer og hoved- programmet skal bare skje via prosedyrekall Fordeler: Frihet i implementasjon, når noe endres, må ikke all annen kode som bruker klassen undersøkes/rettes. Endring av en egenskap er ofte en sammensatt operasjon, to eller flere variable skal endres, før data gir mening. Slik kode skal ikke spres til andre deler av koden Eks: class bil_1 {..... char eier_navn[30];.....} // implementasjonen eksporteres class bil_2 {..... char [ ] eier_navn( );.....}; // implementasjonen skjult, kan endres

9 9 OO-analyse, design & evolusjon  OO Analyse (kravspesifikasjon) Forståelse av problemområdet og brukerkrav, identifikasjon av de viktigste klassene og deres mer abstrakte/høynivå operasjoner  OO Design Konkret forslag til implementasjon av programstruktur ( klasser, prosedyrer og øvrige data - også klasser knyttet til løsningen som skjembilder), maskinplattform og manuelle rutiner tilknyttet systemet  OO Evolusjon, modifikasjon Koding, testing, integrasjon av stadig mer utbygde prototyper. Videreutvikling. Den klassiske fossefallsmetoden er død - iterasjoner er alltid påkervet. Viktig å ha en metode som oppdager feil/mangler tidlig - er klart billigst.

10 10 Videreutvikling som metode  Resten av systemer delvis skjermet ved utvidelse en klasse: Forandre implementasjonen til en klasse Forandre representasjonen av en klasse Reorganisere klassestrukturen Forandre grensesnitt til en klasse  OO Analyse &design og evolusjon er oftest en iterasjon via stadig mer utviklete systemer (prototyper)

11 11 Objekt-egenskaper Et objekt har:  Tilstand (verdi på egenskaper/ data)  Handling (ved kall på prosedyrene)  Identitet (ett objekt er alltid unikt, forskjellig fra alle andre objekter)  Aktivt/passivt (klient/tjener tjener - kan ha egen tråd)

12 12 OO ANALYSE: To viktige relasjoner mellom klasser 1) Er-en relasjon (IsA) = spesialisering, eks: En lønnskonto er-en konto En student er-en person Løsning: arv / subklasser 2) Har relasjoner (HasA) = oppdeling/dekomponering eks: En bil har fire hjul En Student har flere eksamener Løsning: pekere til andre objekter (eller et objekt inneholder de andre objektene).

13 13 Hva er objekter ?  Kandidater til klasser:  Håndfaste ting, andre (del)systemer  Mennesker, roller  Substantiver generelt  Organisasjoner  Hendelser, transaksjoner  Steder

14 14 Øvelsesoppgave: Finn klasser ved substantivmetoden Ledelsen for varehuskjeden Prima har i den siste tiden sett med bekymring på at alle de viktigste konkurrentene har skaffet seg rabattkort-ordninger. Derfor har de nå opprettet sitt eget poengkort, Ludokortet. Kortet deles ut gratis til alle kunder som ønsker det, mot at de oppgir navn og adresse og telefonnummer og underskriver på at er iorden at Prima lagrer informasjon om hva de kjøper. Prima opererer med to typer Ludokort, vanlige kort for privatpersoner og bedriftskort. Ditt oppdrag er å lage en første versjon av et system som kan lage fornuftige rapporter til ledelsen for Prima (og for salg til andre kunder) etter behov.

15 Utvid programmet fra de foregående oppgavene til å bli et komplett, kommandostyrt program som kan utføre følgende kommandoer: Skriver ut en liste med en linje for hver vare Prima fører, med varenummer, navn på varen, pris og antall Ludopoeng som gis for varen. Skriver ut en liste med en linje for hvert Ludokort som er tatt i bruk, med navn, adresse, telefon (og evt. faxnummer dersom dette finnes) på korteier og hvor mange poeng eieren har samlet opp. Skal føre til at det for det gjeldende kortnummeret blir laget en oversikt over kortet og bruken av det, med antall kjøpte varer av hvert slag, og antall poeng opparbeidet på hver vare for hver måned kortet har vært brukt. Oversikten skal plassere alle linjene som angår samme vare sammen og innbyrdes sortert på måned.

16 16 Til øvelsesoppgaven: 1. Hva er klassene - i problemområdet (det eksisterende system) - tillegg for løsningen 2. Hvor mange objekter er det (typisk) av hver klasse - hvilke 3. Kom med forslag til noen funksjoner til hver klasse Hvis du får tid : 4. Tenk deg alternativt at du utviklet et funksjonelt, top-down strukturert program for dette problemet, hvor ville da - data til de ulike klassene du har, være - hvor ville du finne igjen de funksjonene du har foreslått i pkt 3.

17 17 Objektene representerer viktige "begreper"eller "gjenstander" i den del av verden vi modellerer med vårt program Eks. Studentregister Klasser for: studenter kurs studieretninger eksamener (studentens og/eller kursets?) studieadministrasjonen institutter universitetet...... vinkling, hvilke spørsmål vi vil ha svar på

18 18 Klassers og objekters ansvar  En klasse skal representere en type av ting, en type logisk enhet, et begrep  Et objekt representerer ikke bare passivt en slik 'ting' man har også ansvar / tilbyr tjenester (funksjoner/metoder) overfor andre objekter. Objektet er en tjener.  Et objekt samarbeider ofte med andre objekter (av egen eller andre klasser) når det skal utføre en tjeneste. Dvs. objektet kaller funksjoner i andre objekter for å løse (deler) av oppgaven. Kalles ofte delegering.  En klasse kan selv definere alle sine egenskaper/sitt ansvar, eller arve deler av det.

19 19 Kontrakter og ansvar En klasse implementerer en rekke funksjoner/tjenester Disse lar seg naturlig gruppere En kontrakt består av en eller flere funksjoner som sammen danner et komplett tjenestetilbud:. eks: representere en fil (åpne, lukke, slette, lese, skrive..). eks: Generell datastruktur for å oppbevare objekter, som f.eks en kø (sett_inn, ta_ut, finn_første, fjern,...) En klasse implementerer oftest bare en, (eller et fåtall) kontrakter. I Java spesifiseres ofte en kontrakt som et grensesnitt (interface). Kontrakter er en gruppe av tjenester overfor samme klient.

20 20 Ønskemål for design av en klasse  Representerer noe som logisk hører sammen, ikke 'litt-av-hvert'.  Passe stor og-  Generell, dvs. gjenbrukbar i andre sammenhenger  Hvis den er en subklasse øker funksjonaliteten.  Hvis den er en superklasse har minst to subklasser.  Kan selv bruke generelle tjenester dvs. har fellesdeler med andre klasser slik at disses tjenestene kan utnyttes ved arv eller samarbeid.

21 21 Analyse og design, en generell metodikk 1. Analyser typisk bruk, vurder ulike brukeres systemkrav 2. Finn klassene 3. Bestem ansvarsområdet for de enkelte klassene 4. Bestem samarbeidspartnere for de enkelte klassene 5. Bestem arv (subklassene) 6. Lag samlinger av klassene (moduler og subsystemer) 7. Sett opp protokoller for kall fra hver klasse til dens samarbeidspartnere. 8. Lag funksjonelle krav til operasjonene (prosedyrene) i hver klasse Itereres flere ganger Kan noen ganger ta flere steg i ett Analyseog design-fasen har overlapp

22 22 1. Analyser brukerkrav og ulike synspunkter  Bestem ulike brukergrupper (aktører)  Tegn typiske brukssituasjoner med informasjonsflyt mellom tenkt system og bruker  Se på mulige konflikter mellom brukerkravene  Vurder ulike brukeres systemkrav og synsvinkler, interesser  Finn  Mest kritiske krav (implementeres først)  Grader kravene etter viktighet (må ha, viktig, greit å ha)  Få fastspikret hvilke krav som skal inn i versjon nr. 1  Få ledelsen interessert i prosjektet og med på beslutningene

23 23 Klassene finnest lettest via å se noen objekter i en typisk situasjon Problemområdets 'ting' Sentrale begreper Substantiver Objekter fra løsningen (dialogvinduer,..) Kategorier av objekter Sorter i tre grupper Lag et CRC 'kort' (class, responsability, collaboration) for hver klasse Rollespill for å fylle ut CRC ( ORC ??) klassenavn ansvar (operasjoner) samarbeider med (andre klasser) Student Meld_på Ta_eksamen Betal_sem-avg Stud-eksp Kurs Administrasj....... Kurs Registrer- påmelding Student Institutt Eksamen 2. Finn klassene

24 24 3. Bestem ansvarsområdet for klassene Data + operasjoner pr. klasse finn kontrakter som må tilbys av systemet gi funksjoner til alle klasser finn manglende funksjoner, fordel disse Vanskeligere å fordele funksjoner eks studentregisteret: Skal Studenten selv ‘skrive_ut_vitnemål’ eller skal instituttet / fakultetet / studentekspedisjonen / universitets objektet gjøre det ? Revider evt. klassene (skisse av klasse-diagrammer)

25 25 4. Bestem samarbeidspartnere Tegn opp klassene i systemet. Tegn kommunikasjonslinjer mellom klassene for hvert prosedyre-kall Flytt evt. funksjoner for å minimere kommunikasjonen

26 26 5. Bestem arvehierarkier  Finn felles funksjonalitet mellom klasser  Skill ut fellesdeler i 'abstrakte' klasser  Lag ikke objekter fra 'abstrakte klasser', disse brukes bare til å lage nye klasser ved 'sub'- klasse mekanismen  Vurder bruk av virtuelle prosedyrer

27 27 6. Lag samlinger av klasser (delsystemer) Se igjen på kommunikasjonen mellom klassene Finn grupper av klasser med lite trafikk utad, mye trafikk innad i gruppen Lag subsystemer (moduler) Navn egen fil (separatkompilering,...) arbeidsoppgave for en programmerer

28 28 7. Sett opp protokoller (mellom klassene)  Protokoll= klassens grensesnitt, det sett av funksjoner klassen tilbyr utad.  Navngi funksjonene (noe, ikke hele funksjonaliteten i navnet)  For alle aksessprosedyrer:  Krav til innparametre og (globale data)  + Krav til utparametre og (globale data)  Sammenhengen mellom disse f.eks i Z eller bruk en eller annen logisk notasjon (tilstandsdiagrammer, krav ved inngang og utgang av prosedyrer)

29 29 8. Sett funksjonelle krav til prosedyrene Velkjent, krav til handlingessekvensen i hver (aksess)prosedyre, eks.:  Valg av algoritme og hjelpedata  Spesifikasjon av bruk av skjerm, database  Effektivitetskrav osv.

30 30 Månedsverk Analyse Design Koding Testing Integrasjon Vedlikehold Normalt for funksjonell utvikling OO systemutvikling fordeler og forskjeller

31 31 Hovedpunkter ved OO systemutvikling Abstraksjon, begrepsdannelse på et høyere nivå, både data og operasjoner. Modellnærhet hele veien fra "virkelig" verden, gjennom analyse og design til programmeringen (samme språk) Vi har fått skjult implementasjons-detaljer Utviklingsprosessen er en stadig iterasjon (via analyse, design og implementasjon) av nye versjoner.

32 32 6 påstander om OO  OO er ikke valg av et bestemt progr. språk eller et bestemt CASE- vektøy  OO er en gjennomgripende endring  OO kan ikke (vellykket) gjennomføres delvis f.eks bare for programmeringen  OO vil endre hele systemutviklingsprosessen  Start med et lite, ikke tidskritisk prosjekt og en mindre gruppe motiverte medarbeidere  Det er betydelig lettere å omskolere de som kommer fra datamodellerings-verden (les: COBOL) enn de som kommer fra strukturert programmering (les: FORTRAN, Pascal, C)