Mer om objektorientering og UML

Transkript

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

2 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

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

4 Tabell (array) Personer med Alder som funksjon Fødselsnr Navn Adresse Født (dato) Alder Per Hansen Eikeveien 4, 165 Oslo Line Nilsen Svanesvingen 2, 0987 Oslo Ekornbakken 9, Tore Nordmann Oslo Siv Svendsen Trollveien 5, 1400 Ski 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

5 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

6 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

7 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

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

9 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

10 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

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

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

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

14 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

15 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

16 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

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

18 Overføring av faglig grunndata fra E-resept-arkitektur versjon 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

19 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

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

21 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

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 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

39 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

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

41 UML - diagrammer Kilde: INF1050 > Systemutvikling->objektorientert modellering 41

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 Use Case diagrammer brukes til å beskrive interaksjonen mellom brukere og systemer.. INF1050 > Systemutvikling->objektorientert modellering 42

43 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

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

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

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

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

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

49 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

50 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

51 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

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

53 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

54 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