Mer om objektorientering og UML

INF1050: Systemutvikling 21. februar 2017 Mer om objektorientering og UML Universitetslektor Yngve Lindsjørn INF1050 > Systemutvikling->objektorientert modellering 1

Temaer i dagens forelesning Ø 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

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 3

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

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

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

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 kunnne endres neste gang kurset går. INF1050 > Systemutvikling->objektorientert modellering 7

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 8

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 9

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

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 11

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 12

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

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 14

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 15

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 16

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 17

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 18

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 19

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 20

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 21

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 22

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 23

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 24

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 25

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 26

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 27

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 28

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 29

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 30

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 31

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 32

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

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

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 35

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 36

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 37

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 38

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 39

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 40

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 41

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 42

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 43

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 44

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

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 46

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 47