Unified Modeling Language (UML) er et modelleringsspråk innen programvareteknikk som har som mål å sette standardmåter for å visualisere utformingen av et system. UML veileder opprettelsen av flere typer diagrammer som interaksjons-, struktur- og atferdsdiagrammer. EN sekvensdiagram er den mest brukte interaksjon diagram.

Interaksjonsdiagram

Et interaksjonsdiagram brukes for å vise interaktiv oppførsel av et system. Siden det kan være vanskelig å visualisere interaksjonene i et system, bruker vi ulike typer interaksjonsdiagrammer for å fange opp ulike funksjoner og aspekter ved interaksjon i et system.

• Et sekvensdiagram viser ganske enkelt interaksjonen mellom objektene i en sekvensiell rekkefølge, dvs. rekkefølgen disse interaksjonene oppstår i.
• Vi kan også bruke begrepene hendelsesdiagrammer eller hendelsesscenarier for å referere til et sekvensdiagram.
• Sekvensdiagrammer beskriver hvordan og i hvilken rekkefølge objektene i et system fungerer.
• Disse diagrammene er mye brukt av forretningsmenn og programvareutviklere for å dokumentere og forstå krav til nye og eksisterende systemer.

Viktige emner for sekvensdiagrammene

• Sekvensdiagramnotasjon
• Skuespillere
  • Livslinjer
  • Meldinger
  • Lag melding
  • Slett melding
  • Selvmelding
  • Svarmelding
  • Funnet melding
  • Mistet melding
  • Vakter
• Hvordan lage sekvensdiagrammer?
• Bruk tilfeller av sekvensdiagrammer
• Utfordringer ved bruk av sekvensdiagrammer

1. Sekvensdiagramnotasjon

1.1. Skuespillere

En aktør i et UML-diagram representerer en type rolle der den samhandler med systemet og dets objekter. Det er viktig å merke seg her at en aktør alltid er utenfor rammen av systemet vi tar sikte på å modellere ved hjelp av UML-diagrammet.

Vi bruker skuespillere til å skildre ulike roller, inkludert menneskelige brukere og andre eksterne emner. Vi representerer en skuespiller i et UML-diagram ved hjelp av en pinneperson-notasjon. Vi kan ha flere aktører i et sekvensdiagram.

For eksempel:

Her vises brukeren i setereservasjonssystem som en aktør der den eksisterer utenfor systemet og ikke er en del av systemet.

1.2. Livslinjer

En livline er et navngitt element som viser en individuell deltaker i et sekvensdiagram. Så i utgangspunktet er hver forekomst i et sekvensdiagram representert av en livslinje. Lifeline-elementer er plassert øverst i et sekvensdiagram. Standarden i UML for å navngi en livslinje følger følgende format:

Forekomstnavn: Klassenavn

np.klipp

Vi viser en livline i et rektangel kalt hode med navn og type. Hodet er plassert på toppen av en vertikal stiplet linje (referert til som stammen) som vist ovenfor.

• Hvis vi ønsker å modellere en ikke navngitt instans, følger vi det samme mønsteret, bortsett fra at delen av livslinjens navn er tom.
• Forskjellen mellom en livline og en skuespiller
  • En livline skildrer alltid et objekt internt i systemet, mens skuespillere brukes til å skildre objekter utenfor systemet.

Følgende er et eksempel på et sekvensdiagram:

1.3. Meldinger

Kommunikasjon mellom objekter er avbildet ved hjelp av meldinger. Meldingene vises i sekvensiell rekkefølge på livslinjen.

• Vi representerer meldinger ved hjelp av piler.
• Livslinjer og meldinger utgjør kjernen i et sekvensdiagram.

Meldinger kan grovt klassifiseres i følgende kategorier:

Synkrone meldinger

En synkron melding venter på svar før interaksjonen kan gå videre. Avsenderen venter til mottakeren har fullført behandlingen av meldingen. Den som ringer fortsetter bare når den vet at mottakeren har behandlet forrige melding, dvs. den mottar en svarmelding.

• Et stort antall samtaler i objektorientert programmering er synkrone.
• Vi bruker en solid pilhode å representere en synkron melding.

Asynkrone meldinger

En asynkron melding venter ikke på svar fra mottakeren. Interaksjonen beveger seg fremover uavhengig av om mottakeren behandler den forrige meldingen eller ikke. Vi bruker en foret pilhode for å representere en asynkron melding.

1.4. Lag melding

Vi bruker en Opprett-melding for å instansiere et nytt objekt i sekvensdiagrammet. Det er situasjoner når et bestemt meldingsanrop krever opprettelse av et objekt. Det er representert med en stiplet pil og lage ord merket på det for å spesifisere at det er opprette meldingssymbolet.

For eksempel:

Opprettelsen av en ny ordre på et e-handelsnettsted vil kreve at et nytt objekt av ordreklassen opprettes.

1.5. Slett melding

Vi bruker en Slettmelding for å slette et objekt. Når et objekt er deallokert minne eller blir ødelagt i systemet, bruker vi Slett melding-symbolet. Det ødelegger forekomsten av objektet i systemet. Det er representert av en pil som avsluttes med en x.

For eksempel:

I scenariet nedenfor når ordren mottas av brukeren, kan objektet i ordreklassen bli ødelagt.

1.6. Selvmelding

Visse scenarier kan oppstå der objektet må sende en melding til seg selv. Slike meldinger kalles Self Messages og er representert med en U-formet pil .

Et annet eksempel:

Tenk på et scenario der enheten ønsker å få tilgang til webkameraet. Et slikt scenario er representert ved hjelp av en selvmelding.

systemprogramvare

1.7. Svarmelding

Svarmeldinger brukes til å vise meldingen som sendes fra mottakeren til avsenderen. Vi representerer en retur-/svarmelding ved å bruke en åpent pilhode med stiplet linje . Interaksjonen går bare fremover når en svarmelding sendes av mottakeren.

For eksempel:

Tenk på scenariet der enheten ber om et bilde fra brukeren. Her er meldingen som viser bildet som sendes en svarmelding.

1.8. Funnet melding

En Found-melding brukes til å representere et scenario der en ukjent kilde sender meldingen. Det er representert ved hjelp av en pil rettet mot en livline fra et endepunkt.

For eksempel:

Vurder scenariet med maskinvarefeil.

Det kan skyldes flere årsaker, og vi er ikke sikre på hva som forårsaket maskinvarefeilen.

1.9. Mistet melding

En tapt melding brukes til å representere et scenario der mottakeren ikke er kjent for systemet. Det er representert ved hjelp av en pil rettet mot et endepunkt fra en livline.

For eksempel:

ubuntu hvilken kommando

Tenk på et scenario der en advarsel genereres.

Advarselen kan genereres for brukeren eller annen programvare/objekt som livlinen samhandler med. Siden destinasjonen ikke er kjent på forhånd, bruker vi Tapt melding-symbolet.

1.10. Vakter

For å modellere forhold bruker vi vakter i UML. De brukes når vi trenger å begrense strømmen av meldinger under påskudd av at en betingelse er oppfylt. Vakter spiller en viktig rolle i å fortelle programvareutviklere om begrensningene knyttet til et system eller en bestemt prosess.

For eksempel:

For å kunne ta ut kontanter er det å ha en saldo større enn null en betingelse som må oppfylles som vist nedenfor.

Sekvensdiagrammet ovenfor viser sekvensdiagrammet for en følelsesbasert musikkspiller:

1. Først åpnes applikasjonen av brukeren.
2. Enheten får da tilgang til webkameraet.
3. Webkameraet fanger opp bildet av brukeren.
4. Enheten bruker algoritmer for å oppdage ansiktet og forutsi stemningen.
5. Den ber da om database for ordbok over mulige stemninger.
6. Stemningen hentes fra databasen.
7. Stemningen vises til brukeren.
8. Musikken er forespurt fra databasen.
9. Spillelisten genereres og vises til slutt til brukeren.

2. Hvordan lage sekvensdiagrammer?

Å lage et sekvensdiagram involverer flere trinn, og det gjøres vanligvis under designfasen av programvareutvikling for å illustrere hvordan ulike komponenter eller objekter samhandler over tid. Her er en trinn-for-trinn-guide for hvordan du lager sekvensdiagrammer:

1. Identifiser scenariet:
   • Forstå det spesifikke scenarioet eller brukstilfellet du vil representere i sekvensdiagrammet. Dette kan være en spesifikk interaksjon mellom objekter eller flyten av meldinger i en bestemt prosess.
2. List opp deltakerne:
   • Identifiser deltakerne (objekter eller aktører) som er involvert i scenariet. Deltakere kan være brukere, systemer eller eksterne enheter.
3. Definer livslinjer:
   • Tegn en vertikal stiplet linje for hver deltaker, som representerer livslinjen til hvert objekt over tid. Livslinjen representerer eksistensen av et objekt under interaksjonen.
4. Ordne livslinjer:
   • Plasser livslinjene horisontalt i rekkefølgen av deres involvering i interaksjonen. Dette hjelper med å visualisere flyten av meldinger mellom deltakerne.
5. Legg til aktiveringslinjer:
   • For hver melding tegner du en aktiveringslinje på livslinjen til den avsendende deltakeren. Aktiveringslinjen representerer varigheten av tiden deltakeren aktivt behandler meldingen.
6. Tegn meldinger:
   • Bruk pilene for å representere meldinger mellom deltakerne. Meldinger flyter horisontalt mellom livslinjer, og indikerer kommunikasjon mellom objekter. Ulike typer meldinger inkluderer synkrone (heltrukken pil), asynkrone (stiplet pil) og selvmeldinger.
7. Inkluder returmeldinger:
   • Hvis en deltaker sender en svarmelding, tegner du en stiplet pil som går tilbake til den opprinnelige avsenderen for å representere returmeldingen.
8. Angi tidspunkt og rekkefølge:
   • Bruk tall for å angi rekkefølgen på meldingene i sekvensen. Du kan også bruke vertikale stiplede linjer for å representere forekomster av hendelser eller tidens gang.
9. Inkluder betingelser og løkker:
   • Bruk kombinerte fragmenter for å representere forhold (som if-setninger) og løkker i interaksjonen. Dette legger til kompleksitet til sekvensdiagrammet og hjelper med å detaljere kontrollflyten.
10. Vurder parallell utførelse:
    • Hvis det er parallelle aktiviteter som skjer, representer dem ved å tegne parallelle vertikale stiplede linjer og plassere meldingene deretter.
11. Gjennomgå og avgrens:
    • Se gjennom sekvensdiagrammet for klarhet og korrekthet. Sørg for at den nøyaktig representerer den tiltenkte interaksjonen. Avgrens etter behov.
12. Legg til merknader og kommentarer:
    • Inkluder eventuell tilleggsinformasjon, merknader eller kommentarer som gir kontekst eller klargjøring for elementene i diagrammet.
13. Dokumentforutsetninger og begrensninger:
    • Hvis det er noen forutsetninger eller begrensninger knyttet til interaksjonen, dokumenter dem ved siden av diagrammet.
14. Verktøy:
    • Bruk et UML-modelleringsverktøy eller diagramprogramvare for å lage et pent og profesjonelt utseende sekvensdiagram. Disse verktøyene gir ofte funksjoner for enkel redigering, samarbeid og dokumentasjon.

3. Bruk tilfeller av sekvensdiagrammer

• Systematferdsvisualisering:
  • Sekvensdiagrammer brukes til å illustrere den dynamiske oppførselen til et system ved å vise interaksjonene mellom ulike komponenter, objekter eller aktører over tid.
  • De gir en klar og visuell representasjon av flyten av meldinger og hendelser i et spesifikt scenario.
• Programvaredesign og arkitektur:
  • Under designfasen av programvareutvikling hjelper sekvensdiagrammer utviklere og arkitekter med å planlegge og forstå hvordan ulike komponenter og objekter vil samhandle for å oppnå spesifikke funksjoner.
  • De gir en blåkopi for systemets oppførsel.
• Kommunikasjon og samarbeid:
  • Sekvensdiagrammer fungerer som et kommunikasjonsverktøy mellom interessenter, inkludert utviklere, designere, prosjektledere og kunder.
  • De hjelper til med å formidle komplekse interaksjoner i et lettfattelig visuelt format, og fremmer samarbeid og felles forståelse.
• Kravavklaring:
  • Ved avgrensning av systemkrav kan sekvensdiagrammer brukes til å klargjøre og spesifisere forventede interaksjoner mellom systemkomponenter eller mellom systemet og eksterne enheter.
  • De bidrar til å sikre en felles forståelse av systematferd blant alle interessenter.
• Feilsøking og feilsøking:
  • Utviklere bruker sekvensdiagrammer som et feilsøkingsverktøy for å identifisere og analysere problemer knyttet til rekkefølgen og tidspunktet for meldinger under systeminteraksjoner.
  • Den gir en visuell representasjon av kontrollflyten og hjelper til med å lokalisere og løse problemer.

4. Utfordringer ved bruk av sekvensdiagrammer

• Kompleksitet og størrelse:
  • Etter hvert som systemene vokser i kompleksitet, kan sekvensdiagrammer bli store og intrikate. Det kan være utfordrende å administrere størrelsen på diagrammet mens du fortsatt representerer interaksjonene nøyaktig, og altfor komplekse diagrammer kan bli vanskelig å forstå.
• Abstraksjonsnivå:
  • Å finne den rette balansen når det gjelder abstraksjon kan være utfordrende. Sekvensdiagrammer må være detaljerte nok til å formidle nødvendig informasjon, men for mye detaljer kan overvelde leserne. Det er viktig å fokusere på de mest kritiske interaksjonene uten å sette seg fast i detaljer.
• Dynamisk natur:
  • Sekvensdiagrammer representerer dynamiske aspekter av et system, og som et resultat kan de endres ofte under utviklingsprosessen. Å holde sekvensdiagrammer oppdatert med det utviklende systemet kan være en utfordring, spesielt i raskt skiftende eller smidige utviklingsmiljøer.
• Tvetydighet i meldinger:
  • Noen ganger kan det være utfordrende å definere den eksakte naturen til meldinger mellom objekter. Tvetydighet i meldingsinnhold eller mening kan føre til misforståelser blant interessenter og påvirke nøyaktigheten til sekvensdiagrammet.
• Samtidighet og parallellisme:
  • Å representere samtidige og parallelle prosesser kan være komplekst. Mens sekvensdiagrammer har mekanismer for å indikere parallell utførelse, kan visualisering av flere interaksjoner som skjer samtidig være utfordrende og kan kreve ytterligere diagrammatiske elementer.
• Sanntidsbegrensninger:
  • Å representere sanntidsbegrensninger og presise tidskrav kan være utfordrende. Selv om sekvensdiagrammer gir en sekvensiell representasjon, kan det kreve ytterligere dokumentasjon eller komplementære diagrammer for nøyaktig å fange opp og kommunisere sanntidsaspekter.