Use case-diagrammer

Et use case-diagram viser systemets funksjonalitet sett fra brukerens perspektiv. Det inneholder aktorer (personer eller systemer som interagerer med systemet) og use cases (funksjoner systemet tilbyr). Aktorer tegnes som pafigurer (strekmennesker), use cases som ellipser med beskrivende navn, og systemgrensen som en rektangulaer ramme rundt alle use cases.

Viktig: Skill mellom primaere aktorer (initierer interaksjon med systemet, tegnes til venstre) og sekundaere aktorer (stotter systemet eller mottar informasjon, tegnes til hoyre). Eksempler pa sekundaere aktorer: betalingssystem (Vipps, Stripe), e-posttjeneste, SMS-gateway, renseri. Linjer mellom aktorer og use cases viser hvilke aktorer som deltar i hvilke use cases.

Use cases kan ha relasjoner seg imellom: include (et use case inkluderer alltid et annet, f.eks. 'Lei plagg' inkluderer alltid 'Gjennomfor betaling') og extend (et use case kan valgfritt utvide et annet, f.eks. 'Registrer kundeklubb' utvider 'Lei plagg').

Tekstlig use case-beskrivelse

En tekstlig beskrivelse av et use case er en strukturert beskrivelse av interaksjonen mellom aktor og system. Den skal inneholde: Use case-navn, Aktor(er) (primaere og sekundaere), Pre-betingelser (hva ma vaere sant for use caset kan starte), Post-betingelser (hva er sant nar use caset er vellykket gjennomfort), Hovedflyt (nummerert sekvens av steg i normal/vellykket gjennomforing), og minst en Alternativ flyt (hva skjer ved feil, unntak eller avvik fra hovedflyten -- med referanse til steget i hovedflyten der avviket oppstar).

Hovedflyten skal vaere detaljert nok til at en utvikler kan forstå interaksjonen, men ikke sa teknisk at den beskriver implementasjonsdetaljer. Nummererte steg gjor det enkelt a referere til dem fra alternativ flyt (f.eks. '3a. Hvis plagget ikke er ledig...').

Sekvensdiagrammer

Et sekvensdiagram viser interaksjonen mellom objekter over tid. Objekter representeres som bokser overst (med format :Klassenavn) med en stiplet livlinje nedover. Meldinger (metodekall) tegnes som heltrukne piler mellom livlinjene, og returverdier tegnes som stiplede piler tilbake. Rekkefølgen leses fra topp til bunn -- tid gar nedover.

Viktige elementer: Alt-fragment (rektangel med 'alt' i hjornet) for alternativ flyt med betingelse, loop-fragment for gjentakelser, og aktiveringsbar (smal rektangel pa livlinjen) som viser nar et objekt er aktivt. Start med aktoren til venstre, la meldinger ga via et grensesnittobjekt (f.eks. ':Nettside') til kontroll- og domeneobjekter. Pa eksamen V2019 ble det oppgitt en metode finnBok(tittel:string):bok som du skulle bruke i sekvensdiagrammet.

Klassediagrammer

Et klassediagram viser systemets statiske struktur med klasser, attributter, metoder og relasjoner. Hver klasse tegnes som en boks med tre deler: klassenavn (overst, med stor forbokstav), attributter (midten, med synlighet: - privat, + offentlig, # beskyttet, og type: attributtnavn: Datatype), og metoder (nederst, med parametre og returtype).

Assosiasjoner viser forbindelser mellom klasser med multiplisitet i begge ender: 1 (noyaktig en), 0..1 (null eller en), * (null eller mange), 1..* (en eller mange). Assosiasjoner kan ha rollenavn og assosiasjonsnavn. En domenemodell er et klassediagram uten metoder -- det viser kun klasser, attributter og assosiasjoner, og brukes tidlig i analysefasen. Generalisering (arv) vises med en hul pil fra subklasse til superklasse, og betyr at subklassen arver alle attributter og metoder fra superklassen.

Aktivitetsdiagrammer

Et aktivitetsdiagram viser flyten i en prosess eller et use case. Elementer: startnode (fylt sirkel), sluttnode (fylt sirkel med ring), handlinger (avrundede rektangler med beskrivende tekst), beslutningsnoder (diamanter med betingelser pa utgaende piler), gaffel (horisontal bar for a starte parallelle aktiviteter) og sammenslutning (horisontal bar for a vente pa alle parallelle aktiviteter). Bruk svommebaner (swimlanes) for a vise hvilken aktor eller systemkomponent som utforer hver handling -- dette gjor diagrammet mye tydeligere.

Eksempel 1: Tekstlig use case for 'Lei plagg' (V2020)

Use case: Lei plagg. Primaer aktor: Kunde. Sekundaer aktor: Betalingssystem. Pre-betingelse: Kunden er palogget pa Festklar.no. Post-betingelse: Plagget er reservert for kunden, betaling er gjennomfort, og ordrebekreftelse er sendt. Hovedflyt: 1. Kunde velger type plagg (selskapskjole kort/lang eller smoking). 2. Kunde velger onskket dato og antall dogn. 3. Systemet sjekker tilgjengelighet for valgt plagg og dato. 4. Systemet viser pris og tilgjengelige plagg. 5. Kunde velger plagg og bekrefter bestilling. 6. Systemet sender betalingsforespørsel til betalingssystemet. 7. Betalingssystemet gjennomforer betaling og returnerer bekreftelse. 8. Systemet registrerer bestillingen og sender ordrebekreftelse pa e-post. Alternativ flyt: 3a. Plagget er ikke ledig pa onskket dato -- systemet viser melding og foreslår naermeste ledige datoer. Kunden kan velge ny dato (tilbake til steg 2) eller avbryte. 7a. Betalingen feiler -- systemet viser feilmelding og ber kunden prove igjen eller velge annen betalingsmetode.

Eksempel 2: Klassediagram-elementer (V2019/V2020)

For et biblioteksystem (V2019): Klassen Bok har attributter: -tittel: String, -forfatter: String[], -forlag: String, -aar: int, -ISBN: String, -sjanger: String, -status: String, -strekkode: String, -hyllekode: String. Klassen Laantaker har attributter: -navn: String, -brukerID: String, -adresse: String, -mobilnr: String. Assosiasjon: Laantaker laner Bok med multiplisitet 0..* -- 0..1 (en lantaker kan lane mange boker, en bok er lant av null eller en lantaker). For Festklar.no (V2020): Generalisering der SelskapskjoleKort og SelskapskjoleLang arver fra Selskapskjole, som igjen arver fra Plagg sammen med Smoking. Multiplisitet mellom Kunde og Bestilling: 1 -- 0..* (en kunde kan ha mange bestillinger).

Studieguide: UML-modellering