Mer om objektorientering og UML

INF1055: SKK Modul B 19. april 2017 Mer om objektorientering og UML Yngve Lindsjørn ynglin@ifi.uio.no INF1050 > Systemutvikling->objektorientert modellering 1

Temaer i dagens forelesning Ø Arrays vs. objekter Ø Objektorientert design v Objektdesign og ansvarstilordning v Bruk av UML Fokus på klassediagrammer Ø Designmodeller Ø Designmønstre ( Design Patterns ) Ø Eksempler på diagrammer Ø Eksempel på kode (pseudo kode) fra sekvensdiagram INF1050 > Systemutvikling->objektorientert modellering 2

Tabell (array) - Personer Fødselsnr Navn Adresse Født 18048532451 Per Hansen Eikeveien 4, 1358 Stabekk 08.05.1985 17069045362 Line Nilsen Svanesvingen 2, 0987 Oslo 07.06.1990 15039167543 Tore Nordmann Ekornbakken 9, 0876 Oslo 05.03.1991 14029276321 Siv Svendsen Trollveien 5, 1400 Ski 04.02.1992...... To dimensjonal tabell med personer representert som rader og egenskapene (ahribuhene) Kl personene representert som kolonner INF1050 > Systemutvikling->objektorientert modellering 3

Tabell (array) Personer med Alder som funksjon Fødselsnr Navn Adresse Født (dato) Alder 18048532451 Per Hansen Eikeveien 4, 165 Oslo 18.05.1985 32 17069045362 Line Nilsen Svanesvingen 2, 0987 Oslo 17.06.1990 27 Ekornbakken 9, 0876 15039167543 Tore Nordmann Oslo 15.03.1991 26 14029276321 Siv Svendsen Trollveien 5, 1400 Ski 14.02.1992 25...... To dimensjonal tabell med personer representert som rader og egenskapene (ahribuhene) Kl personene representert som kolonner. Alder kan defineres som en funksjon (metode) av fødselsdato. (Personens Alder= Inneværende år (minus) personens fødselsår) INF1050 > Systemutvikling->objektorientert modellering 4

Excel regneark - personer Merk: Alder er definert som en funksjon av dagens år (minus) året til personens fødeselsdato. YEAR(date) og TODAY() er funksjoner (metoder) som finnes i Excel fra før. YEAR (date) returnerer et årstall, mens TODAY() returnerer dagens dato. INF1050 > Systemutvikling->objektorientert modellering 5

Personer som objekter definerer Class Person Person PersonID Navn Adresse Født Alder () Navn på klassen Attributter som beskriver objekt Funksjoner/metoder (operations i UML) Class Person med egenskaper og metoder INF1050 > Systemutvikling->objektorientert modellering 6

Class Person med datatyper og Alder som funksjon/metode Person Navn på klassen Private personid :int Private navn: string Private adresse: string Private født: date Attributter som beskriver personer public Alder(date): int { // returnerer alder fra fødselsdato Alder = year(today()) year(født); } Funksjoner/metoder Class Person med egenskaper og funksjoner (metoder) Merk: Alder kunne også vært et ahribuh i klassen Person men her er alder definert som en funksjon av fødselsdato (ahribuhet Født). year(date) og today() er ferdig definerte funksjoner. En funksjon er en metode som returnerer en verdi. INF1050 > Systemutvikling->objektorientert modellering 7

Assosiasjon mellom personer og kontoer - Tabell (array) - Person har 0 eller flere kontoer Fødselsnr Kontonr 08048532451 81032456787 08048532451 81034321876 08048532451 81030316782 04029276321 65473298765...... To dimensjonal tabell med Personens ID i første kolonne og kontonummer i andre kolonne. INF1050 > Systemutvikling->objektorientert modellering 8

Assosiasjon mellom objekter Person Konto PersonID: int Navn: string Adresse: string Født: date Alder (date): int 1 0..* Kontonr: int HentKontonr (): int En person har 0 eller mange kontoer INF1050 > Systemutvikling->objektorientert modellering 9

Klassediagram Person tar kurs Mange-til-mange assosiasjon(relasjon): En person kan ta mange kurs (0..* betyr fra 0 til mange), og et kurs kan ha mange personer (fra 0 til mange) INF1050 > Systemutvikling->objektorientert modellering 10

Klassediagram - Student tar kurs - Generalisering Alle attributter og metoder i person blir arvet i Student INF1050 > Systemutvikling->objektorientert modellering 11

Klassediagram - Student tar kurs med foreleser(e) Alle attributter og metoder i Person blir arvet i Student og Foreleser INF1050 > Systemutvikling->objektorientert modellering 12

Klassediagram - Kurs inngår i Emne Emne er for eksempel Inf1050 og Kurs er for eksempel INF1050V2015 INF1050 > Systemutvikling->objektorientert modellering 13

Student tar kurs med obligatoriske oppgaver Alle kurs har minst en obligatorisk oppgave. Merk at her er oblig knyttet til kurs og ikke emne slik at oblig vil kunne endres neste gang kurset går. INF1050 > Systemutvikling->objektorientert modellering 14

Identifisere klasser Å identifisere klassene er ofte den vanskeligste delen av objektorientert design Det finnes ingen magisk formel for å identifisere klasser i et system. Avhenger av kompetanse, erfaring og domenekunnskap (kunnskap om systemet og omgivelser) til utvikleren eller systemdesigneren Dette er en iterativ prosess. Umulig å få det riktig første gang INF1050 > Systemutvikling->objektorientert modellering 15

En tilnærming for å identifisere klasser Bruk en grammatisk tilnærming basert på en naturlig språkbeskrivelse av systemet objekter og attributter er subjekter, operasjoner (metoder) er verb Bruk gjenkjennelige ting (entiteter) i applikasjonsdomenet som Emne og Kurs, roller som Student og Foreleser Bruk en scenario-basert analyse og identifiser objektene, attributtene og metodene i hver scenario INF1050 > Systemutvikling->objektorientert modellering 16

Design Design er en kreativ aktivitet der du identifiserer programvarekomponenter og sammenhengen mellom dem, basert på kravspesifikasjon fra kunden INF1050 > Systemutvikling->objektorientert modellering 17

Overføring av faglig grunndata fra E-resept-arkitektur versjon 7.2.1 Faglige grunndata til bruk i e-resept skal leveres av Legemiddelverket gjennom deres FEST tjeneste. Grunndata levert fra FEST skal kunne kombineres med annen grunndata i mottakersystemene... FEST= forskrivnings- og ekspedisjonsstøtte VRS=Vareregisteret HELFO=Helseøkonomiforvaltningen Informasjon om Legemidler skal baseres på informasjon fra Athene og kombineres med informasjon fra VRS. Informasjon om Legemidler skal omfatte alle legemidler som har fått utdelt varenummer i VRS og finnes tilgjengelig i apotek. Legemiddelverket skal levere interaksjonsdata i FEST.. Informasjon om handelsvarer blir hentet fra to kilder, VRS skal levere alle handelsvarer som er relevant for multidosepakking og HELFO skal levere oversikt over pris og produkter som er refusjonsberettiget på blåresept (alle handelsvarer). INF1050 > Systemutvikling->objektorientert modellering 18

Spesifikasjon av grensesnitt/interface Grensesnitt/Interface bør spesifiseres slik at objektene og andre komponenter kan designes i parallell. Ikke design representasjonen av data kun navn og metoder (uten innhold). Innholdet defineres i objektene som implementerer grensesnittet. Objekter kan ha flere grensesnitt med ulike perspektiver av metodene som er spesifisert. Klassediagrammer blir brukt i UML for spesifikasjon av grensesnitt. INF1050 > Systemutvikling->objektorientert modellering 19

Eksempel (brukt i INF1010) Ulike klasser samme grensesnitt (Interface) INF1050 > Systemutvikling->objektorientert modellering 20

Finne ansvarsområder til klasser Hvert funksjonelle krav må tilordnes en eller flere klasser Ø Hvis en klasse har for mange ansvarsområder, vurder å splitte den i ulike klasser. Ø Hvis en klasse ikke har noe ansvar, så er den antageligvis overflødig Ø Når et ansvar ikke kan tilordnes til en eksisterende klasse, opprett en ny klasse. For å finne ansvarsområder Ø Analyser use casene Ø Se etter beskrivelse av handlinger (verb og substantiv) INF1050 > Systemutvikling->objektorientert modellering 21

Objektdesign: Ansvarstilordning Ansvar er knyttet til objektet i form av dets oppførsel Ø Handling: Opprette objekt, beregne, initiere handlinger i andre objekter, kontrollere og koordinere handlinger i andre objekter. Ø Kunnskap: Vite om private data, relaterte objekter, ting som det kan utlede eller beregne Ansvar er ikke det samme som metoder, men metoder implementeres for å oppfylle ansvaret Kategorier av ansvar: Ø Sette (set) og hente (get) verdier av attributter Ø Opprette og initialisere nye instanser (objekter) Ø Hente fra og lagre til fil (ofte database) Ø Slette instanser Ø Legge til og slette linker for assosiasjoner (relasjoner) Ø Kopiere, konvertere og endre Ø Beregne numeriske resultater Ø Navigere og søke Ø INF1050 > Systemutvikling->objektorientert modellering 22

Kjennetegn på god design En god utforming gjør den jobben den er ment å gjøre En god utforming er enkel og elegant Eleganse innebærer å finne akkurat riktig abstraksjonsnivå En god utforming er gjenbrukbar, utvidbar og enkel å forstå Et godt objekt har et lite og veldefinert ansvarsområde Et godt objekt skjuler implementasjonsdetaljer fra andre objekter - Grady Booch INF1050 > Systemutvikling->objektorientert modellering 23

Modularisering Høy kohesjon Ø Et objekt skal bare ha ansvar for relaterte ting Lav kobling Ø Et objekt skal samarbeide med et begrenset antall andre objekter INF1050 > Systemutvikling->objektorientert modellering 24

Høy kohesjon Kohesjon er et mål på hva slags ansvar et objekt har og hvor fokusert ansvaret er Et objekt som har moderat ansvar og utfører et begrenset antall oppgaver innenfor ett funksjonelt område har høy kohesjon Objekter med lav kohesjon har ansvar for mange oppgaver innen ulike funksjonelle områder INF1050 > Systemutvikling->objektorientert modellering 25

Lav kobling Kobling er et mål på hvor sterkt et objekt er knyttet til andre objekter Et objekt med sterk kobling er avhengig av mange andre objekter, noe som kan gjøre endring vanskelig INF1050 > Systemutvikling->objektorientert modellering 26

Designmodellen Lag design-klassediagram parallelt med sekvensdiagrammer Lag noen sekvensdiagrammer, oppdater klassediagrammet, utvid sekvensdiagrammet etc. Designklassene er systemklasser, ikke bare konseptuelle klasser som i domenemodellen INF1050 > Systemutvikling->objektorientert modellering 27

Analyse- vs. designmodell Ø Analysemodellen utelater mange klasser som er nødvendige i et komplett system v Er typisk en domenemodell v Kan inneholde mindre enn halvparten av klassene i systemet. v Uavhengig av spesielle brukergrensesnittsklasser arkitekturklasser (f.eks. design patterns klasser) Ø Den komplette designmodellen inneholder v Domenemodellen v Brukergrensesnittsklasser v Arkitekturklasser (f.eks. slik at klasser kan kommunisere) v Utility klasser (f.eks. håndtering av mengder og strenger) INF1050 > Systemutvikling->objektorientert modellering 28

Designprosesser Det finnes flere ulike objektorienterte designprosesser avhengig av organisasjonen som bruker prosessen Felles aktiviteter i disse prosessene inkluderer Ø Forstå og definere systemets kontekst og eksterne interaksjoner med systemet Ø Designe systemarkitekturen Ø Identifisere nøkkelobjektene i systemet Ø Utvikle designmodeller Ø Spesifisere grensesnitt INF1050 > Systemutvikling->objektorientert modellering 29

Designmønstre Design patterns Et designmønster er en måte å gjenbruke abstrakt kunnskap om et problem og løsningen på problemet Et mønster er en beskrivelse av et problem og essensen av løsningen Bør være tilstrekkelig abstrakt til å kunne bli gjenbrukt i ulike situasjoner I beskrivelser av mønstre brukes som regel objektorienterte teknikker som arv og polymorfisme ( Virtual methods ) INF1050 > Systemutvikling->objektorientert modellering 30

Hvorfor bruke mønstre (patterns) for informasjonssystemer? Mye av vårt daglige virke består i å lete etter strukturer (mønstre) i omgivelsene Mønstre er vanlige løsninger på vanlige problemer Det samme gjelder utvikling av informasjonssystemer Mange systemer har grunnleggende fellestrekk Det finnes mange mønstre (patterns) som er blitt utviklet gjennom systemutviklingens historie INF1050 > Systemutvikling->objektorientert modellering 31

Mer om Mønstre ( patterns ) Mønstre er navngitte retningslinjer for hvordan ansvar skal fordeles i ulike situasjoner. Mønstre brukes bl.a. i prosessen med å forfine sekvensdiagrammer GRASP Patterns of General Principles in Assigning Responsibilites = Mønster for problem/løsning Sentrale prinsipper er Ø Ekspertprinsippet: v La det objektet som har kunnskapen (dataene) også behandle den Kontrollobjektprinsippet: Ø To typer kontrollere: v Fasadekontroller: En kontrollklasse har ansvar for alt (brukes i et lite system) v Use case kontroller: Styrer ett use case (brukes i større systemer. Ett kontrollobjekt for hvert use case). Skaperprinsippet: Ø Legg ansvar for å opprette et nytt objekt i klassen som må vite om det nye objektet INF1050 > Systemutvikling->objektorientert modellering 32

Ekspertprinsippet: (Information Expert) Problem: Hva er det generelle prinsipp for å tilordne ansvar til objekter? Løsning: La det objektet som har kunnskapen (dataene) også behandle den Hvordan: Ø Begynn med å formulere ansvarsområdet: Ø Eks: Student-kurs: Hvilket objekt har ansvar for å vite om hvilke emner som kreves for å ta et gitt emne? Hvilket objekt har ansvar for å gi en liste over alle studentene på et kurs? INF1050 > Systemutvikling->objektorientert modellering 33

Skaperprinsippet (Creator) Problem: Hvem er ansvarlig for å opprette nye objekter? Løsning: La det objektet som må vite om de nye objektene, lage dem Hvordan: Gi klasse B ansvaret for å opprette et objekt av klasse A dersom ett av følgende er sant: Ø B inneholder A-objekter Ø B registrerer A-objekter Ø B bruker A-objekter Ø B har data som sendes til A-objektet når det opprettes INF1050 > Systemutvikling->objektorientert modellering 34

Kontrollobjektprinsippet (Controller) Hvilken klasse skal behandle en systemhendelse/melding? Ø Kontrolleren ligger gjerne på klienten Ø Kontrolleren har bare metoder, få eller ingen attributter Ø Kontrolleren gjør ikke jobben selv, men mottar og fordeler oppgaver er en slags administrator Ø Delegerer oppgaver og styrer use case Ø Er et bindeledd mellom brukergrensesnittet og applikasjonslaget (modellen) INF1050 > Systemutvikling->objektorientert modellering 35

Systemkontekst for værstasjon Kontroll- 1 system 1 1 Informasjonssystem for været 1 1..n 1..n Værstasjon 1..n 1 1 Satelitt INF1050 > Systemutvikling->objektorientert modellering 36

Værstasjon Use cases Rapporter vær Informasjons-system for været Rapporter status Res tart Slå av Kontroll-system Rekonfigurer Strømsparer Fjernkontroll INF1050 > Systemutvikling->objektorientert modellering 37

Use case beskrivelse: Rapporter vær System Use case Aktører Beskrivelse Stimulu Respons Kommentarer Værstasjon Rapporter vær Informasjonssystem for vær, Værstasjon Værstasjonen sender et sammendrag av værdata, som har blitt samlet fra instrumentene i innsamlingsperioden, til informasjonssystemet. Dataene som sendes er maks, min og gjennomsnittstemperatur; maks, min og gjennomsnitt lutftrykk; maks, min og gjennomsnitt vindhastighet, total nedbør (i mm), og vindretninger for hvert 5 minutt. Informasjonssystemet etablerer en satelitt kommunikasjonslink med værstasjonen og spør om overføring av data. Sammendrag av data sendes til informasjonssystemet Værstasjoner rapporterer vanligvis hver time, men dette varierer litt fra stasjon til stasjon og vil kunne endres i framtiden INF1050 > Systemutvikling->objektorientert modellering 38

Klasser for værstasjon Basert på håndgripelige hardware og data i systemet Ø Bakketermometer, vindmåler, barometer v Applikasjons domeneobjekter som er relatert til instrumenter i systemet Ø Værstasjon v Basis grensesnitt fra værstasjon til omgivelsene. Værstasjonen reflekterer interaksjoner som identifiseres i use-case modellen Ø Værdata v Samler værdataene som kommer fra instrumentene INF1050 > Systemutvikling->objektorientert modellering 39

Klassediagram for værstasjon med assosiasjoner INF1050 > Systemutvikling->objektorientert modellering 40

UML - diagrammer Kilde: http://en.wikipedia.org/wiki/uni5ied_modeling_language#structure_diagrams INF1050 > Systemutvikling->objektorientert modellering 41

Use Case Pante flasker <<extend>> Få kvittering Kunde (f rom Use Case V iew) Pante flasker (from Use Case View) <<extend>> Bli med i Røde kors lotteri Use Case diagrammer brukes til å beskrive interaksjonen mellom brukere og systemer.. INF1050 > Systemutvikling->objektorientert modellering 42

Use Case Pante flasker <<extend>> Få kvittering Kunde (f rom Use Case V iew) Pante flasker (from Use Case View) <<extend>> Bli med i Røde kors lotteri INF1050 > Systemutvikling->objektorientert modellering 43

Tekstlig beskrivelse for Pante flasker Navn: Pante flasker Aktør: Kunde Prebetingelse: Panteautomat er klar til å ta imot pant Postbetingelse: Kunde får ut kvittering eller lodd i røde kors trekning Hovedflyt: 1. Kunde setter inn en flaske (eller et panteobjekt) 2. Panteautomaten skanner koden til flasken (panteobjektet) som ble puttet inn 3. Objektet er godkjent, pantebeløpet blir lagt til det totale beløpet 4. Kunde trykker på kvittering 5. Panteautomat skriver ut kvittering Alternative flyt 3.1 Objekt ikke godkjent 3.2 Start fra 1 4.1.A1 Kunde trykker på Røde kors lotteri 4.2.A1 Kunde skriver ut Røde kors lodd 4.1.A2 Kunde setter inn ny flaske (panteobjekt) 4.2.A2 Start fra 1 INF1050 > Systemutvikling->objektorientert modellering 44

Klassediagram pante flasker Lodd Melding Vinnerbeløp 0..* Pantesystem PantFlaske() AdderBeløp() 1 1 1 PanteAutomat SkrivFeilmelding() SkrivUtKvittering() SkrivUtLodd() ScannFlaske() 1 1 PanteMottak SkrivMeldingFullt() 0..* Kvittering ListPant TotalBeløp Dato Sted INF1050 > Systemutvikling->objektorientert modellering 47

Klassediagram pante flasker Lodd Melding Vinnerbeløp 0..* Pantesystem PantFlaske() AdderBeløp() 1 1 1 PanteAutomat SkrivFeilmelding() SkrivUtKvittering() SkrivUtLodd() ScannFlaske() 1 1 PanteMottak SkrivMeldingFullt() 0..* Kvittering ListPant TotalBeløp Dato Sted INF1050 > Systemutvikling->objektorientert modellering 48

Sekvensdiagram pante flasker : Kunde PS : Pantesystem PA : PanteAutomat Loop PantFlaske() [for hver flaske] ScannFlaske() Alt Melding (ta ut flaske) [ikke godkjent] pantebeløp AdderBeløp(pantebeløp) [godkjent] Alt [trykket kvittering create K : Kvittering [trykket lodd] SkrivUtKvittering(K) create L : RødekorsLodd Kommentar: Kunne sendt med info til create Kvittering og Lodd (beløp og loddnr, + annen info) SkrivUtLodd(L) INF1050 > Systemutvikling->objektorientert modellering 49

Aktivitetsdiagram pante flasker Godkjent Sett inn flaske (panteobjekt) Nei Ikke godkjent, ta ut Ja Ja Legg til pantebeløp Fortsette Nei Trykket kvittering Trykket lodd Skriv ut kvittering Kvittering eller lodd Skriv ut lodd INF1050 > Systemutvikling->objektorientert modellering 50

Tilstandsdiagram - panteautomat Trykker lodd Skriv ut lodd Venter lodd skrevet ut do/ Vis " sett inn objekt" Trykker kvittering ta ut objekt Vis feilmelding Skriv ut kvittering kvittering skrevet ut do/ vis "ta ut objekt" objekt satt inn ikke godkjent Skann objekt godkjent beløp lagt til Legg til beløp INF1050 > Systemutvikling->objektorientert modellering 51

Sekvensdiagram - Reserver bil INF1050 > Systemutvikling->objektorientert modellering 52

Pseudo-kode Reserver bil class Reservasjonssystem { // Disse objektene kjenner vi til fra før. Bilregister br; Kunderegister kr; Kundebehandler kb; //kb er her et objekt av klassen Kundebehandler ikke med i sekvensdiagrammet ArrayList <Bil> ledigebiler; Bil bil; String kundenr; Kunde k; Kontrakt kt; // metode som legger til en kontrakt i en liste AddKontrakt(kt) { } // kundebehandler velger tidsintervall (hentedato og returdato). reserverbil (hdato, rdato) { // Systemet returnerer en liste over tilgjengelige biler innenfor de spesifiserte datoene. ledigebiler = bilregister.finnledigebiler(hentedato, returdato); // Kundebehandler velger én av bilene. bil = kb.velgbil(ledigebiler); INF1050 > Systemutvikling->objektorientert modellering 53

Pseudo-kode Reserver bil forts. } } // Systemet ber om kundenr... kundenr = kb.oppgikundenummer(); if (kundenr) { // og finner kunden i systemet. k = kr.finnkunde(kundenummer); // Alternativ flyt: Kunden finnes ikke. } else { // Systemet oppretter ny kunde og fortsetter til neste steg kundeinformasjon = kr.skrivkundeinformasjon(); k = new Kunde(); k.setkundeinfo(kundeinfo) kr.registrerkunde(k); } // Vi lager en ny kontrakt. // Bil blir reservert i metoden nykontrakt. kt = new Kontrakt(); kt.setkontrakt(k,bil,hdato,rdato); AddKontrakt(kt); // Systemet bekrefter at bilen er reservert for den gitte perioden. kb.visbekreftelse(kt); INF1050 > Systemutvikling->objektorientert modellering 54