Use case-diagrammer

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

Viktig: Skill mellom primære aktører (initierer interaksjon med systemet, tegnes til venstre) og sekundære aktører (støtter systemet eller mottar informasjon, tegnes til høyre). Eksempler på sekundære aktører: betalingssystem (Vipps, Stripe), e-posttjeneste, SMS-gateway, renseri. Linjer mellom aktører og use cases viser hvilke aktører 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 aktør og system. Den skal inneholde: Use case-navn, Aktør(er) (primære og sekundære), Pre-betingelser (hva må være sant for use caset kan starte), Post-betingelser (hva er sant når use caset er vellykket gjennomført), Hovedflyt (nummerert sekvens av steg i normal/vellykket gjennomføring), og minst en Alternativ flyt (hva skjer ved feil, unntak eller avvik fra hovedflyten -- med referanse til steget i hovedflyten der avviket oppstår).

Hovedflyten skal være detaljert nok til at en utvikler kan forstå interaksjonen, men ikke sa teknisk at den beskriver implementasjonsdetaljer. Nummererte steg gjør det enkelt å 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 øverst (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 går nedover.

Viktige elementer: Alt-fragment (rektangel med 'alt' i hjornet) for alternativ flyt med betingelse, loop-fragment for gjentakelser, og aktiveringsbar (smal rektangel på livlinjen) som viser når et objekt er aktivt. Start med aktoren til venstre, la meldinger ga via et grensesnittobjekt (f.eks. ':Nettside') til kontroll- og domeneobjekter. På 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 (øverst, 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 (nøyaktig 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 på utgænde piler), gaffel (horisontal bar for å starte parallelle aktiviteter) og sammenslutning (horisontal bar for å vente på alle parallelle aktiviteter). Bruk svommebaner (swimlanes) for å vise hvilken aktør eller systemkomponent som utfører hver handling -- dette gjør diagrammet mye tydeligere.

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

Use case: Lei plagg. Primær aktør: Kunde. Sekundær aktør: Betalingssystem. Pre-betingelse: Kunden er palogget på Festklar.no. Post-betingelse: Plagget er reservert for kunden, betaling er gjennomført, 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 gjennomfører betaling og returnerer bekreftelse. 8. Systemet registrerer bestillingen og sender ordrebekreftelse på e-post. Alternativ flyt: 3a. Plagget er ikke ledig på onskket dato -- systemet viser melding og foreslår nærmeste 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, -år: int, -ISBN: String, -sjanger: String, -status: String, -strekkode: String, -hyllekode: String. Klassen Laantaker har attributter: -navn: String, -brukerID: String, -adresse: String, -mobilnr: String. Assosiasjon: Låntaker laner Bok med multiplisitet 0..* -- 0..1 (en låntaker kan lane mange boker, en bok er lant av null eller en låntaker). 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

Studieguide: UML-modellering