Fra krav til modellering av objekter

INF1050: Systemutvikling 14. februar 2017 Fra krav til modellering av objekter Førstelektor Yngve Lindsjørn INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 1

Temaer i dagens forelesning System-modellering og systemperspektiv Objektorientert perspektiv UML diagrammer Bruksmønster (Use-Case) Sekvensdiagram Klassediagram Aktivitetsdiagram Tilstandsdiagram Modelldrevet tilnærming INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 2

Systemmodellering Det sentrale med systemmodellering er å utvikle abstrakte modeller av et system, der hver modell representerer ulike perspektiver av systemet Systemmodellering er viktig for å forstå funksjonaliteten i et system og modellene brukes til å kommunisere med kundene og til dokumentasjon Grafisk notasjon er viktig, og er i dette kurset i hovedsak basert på notasjoner gitt i UML (Unified Modeling Language) UML: http://www.omg.org/gettingstarted/what_is_uml.htm Bok: Martin Fowler: UML distilled INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 3

Grafiske modeller Et godt hjelpemiddel i diskusjonen om systemet Ikke komplette eller ukorrekte modeller kan være OK så lenge formålet er å bidra til diskusjon Brukes ofte som en sentral del i dokumentasjon av et eksisterende system Modeller bør representere systemet korrekt, men trenger ikke være komplett En detaljert systembeskrivelse kan brukes til å implementere systemet Modellen må både være korrekt og komplett INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 4

E-resept systemer og meldingsflyt hentet fra e-resept arkitektur versjon 2.71 Dette diagrammet er en sentral del i dokumentasjonen av e-resept systemet INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 5

Modeller En modell er en abstrakt oversikt av et system Ser bort fra alle detaljene Systemmodeller blir laget for å vise et systems kontekst, interaksjon, struktur og adferd ( behavior ). INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 6

Systemperspektiver 4 ulike perspektiver Eksternt perspektiv, der du modellerer konteksten til systemet Interaksjonsperspektiv, der du modellerer interaksjonen mellom et system og omgivelsene, eller mellom komponentene i et system Strukturelt perspektiv, der du modellerer organisasjonen systemet inngår i eller datastrukturen som brukes av systemet Adferdsperspektiv, der du modellerer systemets adferd og hvordan systemet reagerer på hendelser INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 7

Kontekstmodeller Kontekstmodeller viser hvordan et system relaterer seg til andre systemer og prosesser INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 8

Kontekstmodell MHC-PMS Pasientdatabase System Rapportering System Tilgangsrettigheter System MHC-PMS - System Statistikk System Foreskriving System Avtale System INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 9

Medical Health Care Patient Management System MHC-PMS Lokalt system MHC-PMS Lokalt system MHC-PMS Lokalt system MHC-PMS - Server Pasientdatabase Beskrivelse av MHC-PMS: Lærebok kapittel 1.3.2. Denne er hentet fra figur 1.6 INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 10

Interaksjonsmodeller Modeller av interaksjoner er viktig for å identifisere brukerkrav Bruksmønstre og sekvensdiagrammer er sentrale teknikker og diagrammer som brukes i interaksjonsmodeller INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 11

Bruksmønster- og sekvensdiagram Bruksmønster diagrammer (Use Case diagrams) og sekvensdiagrammer brukes til å beskrive interaksjonen mellom brukere og systemer. Bruksmønstre beskriver interaksjonen mellom et system og eksterne aktører Sekvensdiagrammer legger til mer informasjon for hvert bruksmønster og viser også interaksjon mellom objekter kall på metoder INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 12

Bruksmønstre i MHC-PMS som involverer medisinsk saksbehandler Registrer pasient Avregistrer pasient Se pasientinfo Saksbehandler Overfør pasientinfo Kontakt pasient Hentet fra figure 5.5 i lærebok INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 13

Sekvensdiagram Se pasientinfo P : Pasientinfo D : MHCPMS-DB A : Autorisasjon : Medisinsk saksbehandler 1: SePasientinfo (PID) 2: Report (Info, PID, UID) 3: Autorisasjon(Info, UID) 4: Autorisasjon Alt Autorisasjon ok 5: Pasientinfo Autorisasjon feilet 6: 5 Feilmelding (Ingen aksess) INF1050 ->Systemutvikling-> Fra krav til modellering 14

Sekvensdiagram for overfør pasientdata : Medisinsk saksbehandler P : Pasientinfo D : MHCPMS-DB A : Autorisasjon : Pasientdatabasesystem Logg inn() ok Alt OppdaterInfo() Oppdater Pasientdatabase(UID) Autoriser(TF, UID) Autorisasjon Oppdater(PID) Oppdater OK Melding (OK) Oppdater Sammendrag Sammendrag (UID) Autoriser(TF, UID) Autorisasjon Create S : Sammendrag Oppdater(PID) Oppdater OK Melding (OK) Logg ut() INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 15

E-resept: Lege (rekvirent)sender individuell søknad om refusjon til HELFO Merk: Her er dialogen mellom pasient og lege (rekvirent) også med som meldinger selv om dette ikke er metodekall INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 16

E-resept: Beskrivelse av at rekvirent sender individuell søknad om refusjon til HELFO 1. I dialog mellom pasient og lege (rekvirent) avklares at det er behov for å sende individuell søknad om refusjon 2. Rekvirent spør om en søknad skal sendes på vegne av pasienten. 3. Pasienten gir samtykke knyttet til at legen sender søknad til HELFO på vegne av pasienten og at rekvirent eventuelt får kopi av vedtaksbrev (avhengig av pasientens samtykke) 4. Rekvirent registrerer søknad om refusjon i EPJsystemet (rekvirent vil ofte lage en reseptkladd i samme prosess, slik at både resept og søknad sendes). 5. Rekvirent verifiserer og signerer søknaden..etc. INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 17

Strukturelle modeller Strukturelle modeller av et programvaresystem viser organiseringen av systemet ved å vise systemets komponenter og relasjonen mellom komponentene Klassediagrammer brukes til å definere den statiske strukturen av klasser og deres assosiasjoner INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 18

Klassediagrammer Klassediagrammer blir brukt i utviklingen av systemmodeller for å vise klasser i systemet og assosiasjoner mellom disse klassene En klasse kan bli sett på som en generell definisjon (mønster) av objekter som er instanser av klassen En assosiasjon mellom to klasser angir at det er en forbindelse mellom disse klassene Ved utvikling av modeller i den tidlige fasen av systemutviklingsprosessen, vil objekter som regel representere (være en modell av) noe i den virkelige verden, som en pasient, en doktor, en bil eller en bankkonto. INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 19

Eksempel (også brukt i INF1010) class Bank I en bank skal vi kunne legge inn en ny kunde, fjerne en kunde, sette inn penger på en kundes konto og finne forvaltningskapitalen til banken (summen av alle beløpene på alle kontoene) class BankData Alle kontoene blir administrert av klassen BankData class Konto Attributter (data) og metoder for en konto INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 20

UML klassediagram Bank Bankdata 1 1 1 Konto 0..* INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 21

Java datastruktur Bank-objekt BankData-objekt Mange Konto-objekter INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 22

Klasser og assosiasjoner i MHC-PMS Spesialist Tilstand 1 +Henvist til 1..* +Diagnostisert til Pasient +Henvist fra Fastlege 1..* 1..* 1..* 1 1..* +Deltar i 1..* Konsultasjon 1..* 1..* +Bruker 1..* 1..* Klinikklege +Foreskriver Medisinering 1..* +Foreskriver 1..* Behandling INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 23

Klassen konsultasjon med flere detaljer INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 24

Generalisering Generalisering er en teknikk vi benytter oss av for å håndtere kompleksitet I stedet for å lære alle detaljene til hvert eneste objekt plasserer vi objektene i mer generelle klasser (person, dyr, bil, hus etc.) og fokuserer på hva som er karakteristisk ved disse klassene Dette gir oss muligheten til å se at ulike objekter har felles karakteristikker, for eksempel at både pasient og lege er personer INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 25

Generalisering Det er ofte nyttig å undersøke klassene i et system for å se om det er mulighet for generalisering I objektorienterte språk, som Java, er generalisering en del av språket gjennom såkalt arvemekanisme ( inheritance ) Attributter og operasjoner (metoder) som er assosiert med superklasser er også assosiert med subklasser gjennom arv. Subklassene vil så legge til mer spesifikke attributter og operasjoner INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 26

Eksempel - generalisering Lege Klinikklege Fastlege Spesialist Teamlege Legepraktikant Kvalifisert lege INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 27

Adferdsmodeller ( behavioral models) En adferdsmodell er en modell av dynamikken i et system ved kjøring av systemet. Modellen viser hva som skjer ved respons på stimuli. To typer stimuli Data. Systemet fanger opp data som må prosesseres Hendelser. En hendelse som trigger systemet og fører til prosessering. En hendelse har ofte assosierte data i tillegg, men ikke nødvendigvis INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 28

Datadrevet modellering Mange forretningssystemer er primært drevet av data. Systemene blir kontrollert av input av data, med få eksterne hendelser Datadrevne modeller viser sekvensen av handlinger som er involvert i prosesseringen av inputdata og generering av outputdata Modellene er spesielt nyttige under kravspesifikasjonsfasen og brukes til å vise end-toend prosessering av systemet INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 29

Aktivitetsdiagram ordreprosessering INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 30

Ordreprosessering som sekvensdiagram : Innkjøpsansvarlig O : Ordre V : Varelager OR : Ordreregister : Leverandør fyllinnordre() validerordre () Oppdater(mengde) Lagre() Send() INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 31

Hendelsesdrevet ( Event-driven ) modellering Mange systemer er drevet av hendelser, med minimal data prosessering Modellene viser hvordan et system reagerer på eksterne og interne hendelser Baseres på antagelsen av at systemet har et endelig antall tilstander og at hendelser (stimuli) fører til at systemet går fra en tilstand til en annen INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 32

Tilstandsdiagram for mikrobølgeovn Full kraft do/ Sett kraft=600 Venter Full kraft Tidsangiver Sett tid Tall Operasjon av mikrobølgeovn do/ Vis tid Halv kraft Full kraft do/ Hent tall exit/ Sett tid Avbryt Halv kraft Tidsangiver Dør lukket Aktivert Venter Halv kraft do/ Sett kraft=300 do/ Vis "Klar" Dør åpen Dør lukket Dør åpen do/ Vis tid Deaktivert do/ Vis "Venter" INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 33

Tilstandsdiagram for virkning av ovn Operasjon av mikrobølgeovn Sjekk do/ Sjekk status OK Varm opp do/ Kjør mikrobølgegenerat... Feil på dreieskive Stråle/elektrode feil Timeout Alarm Ferdig do/ Vis feilmelding/hendels... do/ Signal gis i 5 sek INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 34

Tilstander og stimuli for mikrobølgeovn Stimuli Beskrivelse Halv kraft (300 W) Brukeren har trykket halv kraft knappen Full kraft (600 W) Tidsinnstilling Tall Åpen dør Dør lukket Start Kanseller Brukeren har trykket full kraft knappen Brukeren har trykket en av de forhåndsgitte tidsinnstillingene Brukeren har trykket et tall på tastaturet Døra er ikke lukket Døra er lukket Brukeren har trykket startknappen Brukeren har trykket kanseller knappen INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 35

Modelldrevet systemutvikling I modelldrevet utvikling (model-driven engineering - MDE) er det modellene i seg selv som er målet og output fra utviklingsprosessen Kode og programmer blir generert automatisk fra modellene Tilhengere av MDE hevder at dette gjør at ingeniører og utviklere ikke trenger å kunne detaljer innen programmering, plattformer etc. INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 36

Bruk av modell-drevet utvikling Fordeler Høyere abstraksjonsnivå Automatisk kodegenerering gjør det enklere og rimeligere å tilpasse systemer til nye plattformer INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 37

Bruk av modell-drevet utvikling Ulemper Abstraksjonsmodeller er ikke nødvendigvis det riktige for implementering Mange hevder koden er lite effektiv og endringer i koden er nødvendig Vanskelig å holde modellen oppdatert ved endringer og feilretting INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 38

Executable UML Den fundamentale ideen bak modell-drevet systemutvikling er at det er mulig med en komplett automatisk transformasjon fra modell til kode. Dette er mulig innefor UML 2, og kalles Executable UML eller xuml En domenemodell identifiserer de overordnede prinsippene, Domenemodellen bruker UML klassediagram og inkluderer objekter, attributter og assosiasjoner. Klassemodeller, der klasser defineres sammen med attributter og metoder (operations i UML) Tilstandsmodeller hvor et tilstandsdiagram assosieres med hver klasse og brukes til å beskrive livssyklusen til klassen INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 39

Smidige metoder og modell-drevet utvikling Mange brukere av modell-drevet utvikling hevder at metoden understøtter en iterativ tilnærming og derfor passer godt innen smidig metodikk Svært omfattende modellering tidlig i prosessen er i motsetning til idealene til agile manifesto, og det er få utviklere innen smidig metodikk som føler seg komfortabel med modell-drevet utvikling INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 40