Klassediagrammer gir et statisk bilde av klassene i et program, mens objektdiagrammer gir et statisk bilde av objektstrukturer ved kjøretid. Like viktig er det å kunne illustrere hva som skjer eller burde skje ved kjøretid, dvs. den dynamisk oppførselen til programmer. Sekvensdiagrammer er en diagramtype som viser hvordan objekter samhandler, dvs. i hvilken sekvens objekter utfører metodekall på hverandre.Dynamisk oppførsel handler om hva som skjer over tid, og sekvensdiagrammer har en implisitt tidslinje som viser hvordan aktører og komponenter i et system "samhandler" over tid ved å sende "meldinger". Begrepene aktører, komponenter og meldinger kan gis ulike tolkninger, men hovedsaklig dreier det seg om to typer bruk:
- På et overordnet nivå: utveksling av informasjon mellom brukere, brukergrensesnitt (klienter) og tjenester (servere). Denne varianten brukes gjerne tidlig ved utvikling av system, for å få oversikt over hvordan brukeren ønsker å bruke et system og hvordan ulike deler av system støtter denne bruken.
- På et detaljert nivå: metodekall som utføres mellom objekter. Denne varianten brukes forut for og til hjelp ved koding, eller som dokumentasjon på virkemåten.
For begge typer bruk, er målet å illustrere oppførsel i et tenkt tilfelle, ved bruk/kjøring av et system. For et mindre system, f.eks. et lite spill med få objekter, så smelter disse to typene bruk sammen. Under til venstre er et eksempel på variant 1 for et tenkt system som svarer på eksistensielle spørsmål:
Strekmannen øverst representerer en person/bruker, mens boksene representerer systemkomponenter. Strekene nedover er tidslinjer, mens strekene på tvers er meldingsflyt. Akkurat hva slags melding det dreier seg om og hvordan den formidles, f.eks. noe brukeren skriver inn, XML som sendes over nettet eller enkle metodekall, er ikke viktig. Det viktige er informasjonsinnholdet og sekvensen. I tillegg er det vanlig å vise om noe regnes som svar (eng: response) på et spørsmål (eng: request), ved å bruke stiplet linje.
Den andre varianten ser egentlig helt lik ut, men da tolkes boksene øverst som objekter, meldingene som metodekall og evt. svar-streker som returverdier. Siden diagrammet illustrerer faktisk kjøring, så har gjerne boksene øverst konkrete navn eller id'er og teksten på meldingsstrekene er konkrete metodekall med argumentverdier eller returverdier. Dersom en av objektene øverst også opptrer som argumenter og/eller returverdier, så brukes navnet eller id'en.
Grunnleggende elementer i et sekvensdiagram
Et sekvensdiagram består ofte av følgende:
- Aktør (eng.: actor): En aktør representerer en rolle som interagerer med et system og dets objekter, f.eks. en person eller et annet eksternt objekt. Det er viktig å bemerke seg at en aktør er utenfor systemet man ønsker å illustrere med sekvensdiagrammet. En aktør illustreres som en strekmann.
Ikke alle sekvensdiagram har en aktør, mens andre kan ha flere.
- Livslinjer: en livslinje er et navngitt element som illustrerer en deltager i et sekvensdiagram, dvs. at hver instans i et sekvensdiagram er representert med en livslinje. Livslinjer illustreres med en vertikal stiplet linje som enten har et rektangel med instansens navn og type øverst eller en aktør.
Her er Actor en aktør, X navnet til et objekt eller instans av klassen SomeClass, og message() en melding som sendes fra aktøren til systemet som man ønsker å illustrere.
Forskjellen mellom en livslinje med en aktør og en livslinje med et rektangel er at en livslinje med et rektangel illustrerer et internt objekt i et system, mens en livslinje med en aktør illustrerer et eksternt objekt.
- Meldinger: kommunikasjon mellom objekter beskrives ved hjelp av meldinger. Disse illustreres som piler og opptrer i sekvensiell rekkefølge på livslinjen.
Når man tegner for hånd unnlater man ofte å tegne de nederste rektanglene og aktør-symbolene. Dvs. at disse bare tegnes på toppen.
Eksempel på et litt større sekvensdiagram
Sekvensdiagrammet over kan leses som følger:
- Resepsjonisten utløser viewInfo-metoden i en instans P av objektklassen PatientInfo, der PID (pasientens identifikator) er argumentet.
- Instansen P kaller databasen for å få den nødvendige informasjonen, og legger ved resepsjonistens identifikasjon for å kunne gå gjennom sikkerhetssjekking.
- Databasen sjekker med et autoriseringssystem om brukeren (resepsjonisten) er autorisert for denne aksjonen.
- Om resepsjonisten er autorisert returneres pasientens informasjon. Hvis resepsjonisten ikke er autorisert returneres en feilmelding.
Boksen der det står "alt" i øverste, venstre hjørne er en måte å illustrere alternative handlinger i et sekvensdiagram. Hvilke betingelser som gjelder for de ulike alternativene skrives inne i brackets [ ].