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 A : Autorisasjon D: MHCPMS-DB : 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 0..* Konto 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 1 +Henvist til 1..* Tilstand +Diagnostisert til 1..* +Henvist fra Pasient 1..* 1..* Fastlege 1 1..* +Deltar i 1..* +Foreskriver Konsultasjon 1..* 1..* +Bruker Medisinering 1..* 1..* +Foreskriver 1..* Klinikklege INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 1..* Behandling 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 Spesialist Fastlege Teamlege Legepraktikant INF1050 -> Systemutvikling -> Fra krav til modellering av objekter Kvalifisert lege 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 V : Varelager O : Ordre OR : Ordreregister : Leverandør : Innkjøpsansvarlig 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 Tidsangiver Full kraft Tall Sett tid Venter do/ Vis tid Operasjon av mikrobølgeovn Halv kraft Full kraft do/ Hent tall exit/ Sett tid Avbryt Dør lukket Halv kraft Tidsangiver Aktivert Halv kraft do/ Vis "Klar" Dør åpen Dør lukket do/ Sett kraft=300 Venter do/ Vis tid Dør åpen Deaktivert do/ Vis "Venter" INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 33 Tilstandsdiagram for virkning av ovn Operasjon av mikrobølgeovn Sjekk Varm opp OK do/ Kjør mikrobølgegenerat... do/ Sjekk status Feil på dreieskive Timeout Stråle/elektrode feil 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) Brukeren har trykket full kraft knappen Tidsinnstilling Brukeren har trykket en av de forhåndsgitte tidsinnstillingene Tall Brukeren har trykket et tall på tastaturet Åpen dør Døra er ikke lukket Dør lukket Døra er lukket Start Brukeren har trykket startknappen Kanseller 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
© Copyright 2024