Unified Modeling Language (UML) er et modelleringssprog inden for software engineering, der har til formål at sætte standardmåder til at visualisere designet af et system. UML guider oprettelsen af ​​flere typer diagrammer, såsom interaktions-, struktur- og adfærdsdiagrammer. EN sekvensdiagram er den mest brugte interaktion diagram.

Interaktionsdiagram

Et interaktionsdiagram bruges til at vise interaktiv adfærd af et system. Da det kan være svært at visualisere interaktionerne i et system, bruger vi forskellige typer interaktionsdiagrammer til at fange forskellige funktioner og aspekter af interaktion i et system.

• Et sekvensdiagram afbilder simpelthen interaktionen mellem objekterne i en sekventiel rækkefølge, dvs. den rækkefølge, hvori disse interaktioner forekommer.
• Vi kan også bruge begreberne hændelsesdiagrammer eller hændelsesscenarier til at henvise til et sekvensdiagram.
• Sekvensdiagrammer beskriver hvordan og i hvilken rækkefølge objekterne i et system fungerer.
• Disse diagrammer bruges i vid udstrækning af forretningsfolk og softwareudviklere til at dokumentere og forstå krav til nye og eksisterende systemer.

Vigtige emner til sekvensdiagrammerne

• Sekvensdiagramnotation
• Aktører
  • Livslinjer
  • Beskeder
  • Opret besked
  • Slet besked
  • Selvbesked
  • Svar besked
  • Fundet besked
  • Mistet besked
  • Vagter
• Hvordan opretter man sekvensdiagrammer?
• Brug eksempler på sekvensdiagrammer
• Udfordringer ved at bruge sekvensdiagrammer

1. Sekvensdiagramnotation

1.1. Aktører

En aktør i et UML-diagram repræsenterer en type rolle, hvor den interagerer med systemet og dets objekter. Det er vigtigt at bemærke her, at en aktør altid er uden for rammerne af det system, vi sigter mod at modellere ved hjælp af UML-diagrammet.

Vi bruger skuespillere til at skildre forskellige roller, herunder menneskelige brugere og andre eksterne emner. Vi repræsenterer en skuespiller i et UML-diagram ved hjælp af en stick person-notation. Vi kan have flere aktører i et sekvensdiagram.

For eksempel:

Her vises brugeren i pladsreservationssystem som en aktør, hvor den eksisterer uden for systemet og ikke er en del af systemet.

1.2. Livslinjer

En livline er et navngivet element, som afbilder en individuel deltager i et sekvensdiagram. Så dybest set er hver forekomst i et sekvensdiagram repræsenteret af en livline. Lifeline-elementer er placeret øverst i et sekvensdiagram. Standarden i UML til at navngive en livline følger følgende format:

Forekomstnavn: Klassenavn

hvordan man åbner en json-fil

Vi viser en livline i et rektangel kaldet hoved med dens navn og type. Hovedet er placeret oven på en lodret stiplet linje (benævnt stilken) som vist ovenfor.

• Hvis vi ønsker at modellere en unavngiven instans, følger vi det samme mønster, bortset fra nu at delen af ​​livslinjens navn er tom.
• Forskellen mellem en livline og en skuespiller
  • En livline portrætterer altid et objekt internt i systemet, mens skuespillere bruges til at afbilde objekter uden for systemet.

Følgende er et eksempel på et sekvensdiagram:

1.3. Beskeder

Kommunikation mellem objekter er afbildet ved hjælp af beskeder. Meddelelserne vises i sekventiel rækkefølge på livlinen.

• Vi repræsenterer beskeder ved hjælp af pile.
• Livslinjer og budskaber udgør kernen i et sekvensdiagram.

Beskeder kan bredt klassificeres i følgende kategorier:

Synkrone beskeder

En synkron meddelelse venter på svar, før interaktionen kan komme videre. Afsenderen venter, indtil modtageren har afsluttet behandlingen af ​​beskeden. Den, der ringer op, fortsætter kun, når den ved, at modtageren har behandlet den forrige besked, dvs. den modtager en svarbesked.

• Et stort antal opkald i objektorienteret programmering er synkrone.
• Vi bruger en solidt pilehoved at repræsentere en synkron besked.

Asynkrone beskeder

En asynkron besked venter ikke på svar fra modtageren. Interaktionen bevæger sig fremad, uanset om modtageren behandler den forrige besked eller ej. Vi bruger en foret pilehoved at repræsentere en asynkron besked.

1.4. Opret besked

Vi bruger en Opret-meddelelse til at instantiere et nyt objekt i sekvensdiagrammet. Der er situationer, hvor et bestemt beskedopkald kræver oprettelse af et objekt. Det er repræsenteret med en stiplet pil og oprette ord mærket på det for at angive, at det er oprette meddelelse-symbolet.

For eksempel:

Oprettelse af en ny ordre på et e-handelswebsted ville kræve, at der oprettes et nyt objekt af ordreklasse.

1.5. Slet besked

Vi bruger en Slet besked til at slette et objekt. Når et objekt er deallokeret hukommelse eller er ødelagt i systemet, bruger vi Slet besked symbolet. Det ødelægger forekomsten af ​​objektet i systemet. Det er repræsenteret af en pil, der slutter med et x.

For eksempel:

I scenariet nedenfor, når ordren modtages af brugeren, kan ordreklassens objekt blive ødelagt.

1.6. Selvbesked

Der kan opstå visse scenarier, hvor objektet skal sende en besked til sig selv. Sådanne beskeder kaldes Self Messages og er repræsenteret med en U-formet pil .

Et andet eksempel:

Overvej et scenario, hvor enheden ønsker at få adgang til sit webcam. Et sådant scenarie er repræsenteret ved hjælp af en selvbesked.

latex skrifttype

1.7. Svar besked

Svarbeskeder bruges til at vise beskeden, der sendes fra modtageren til afsenderen. Vi repræsenterer en retur-/svarmeddelelse ved hjælp af en åbent pilehoved med en stiplet linje . Interaktionen bevæger sig kun fremad, når en svarbesked sendes af modtageren.

For eksempel:

Overvej scenariet, hvor enheden anmoder om et billede fra brugeren. Her er beskeden, der viser, at billedet sendes, en svarbesked.

1.8. Fundet besked

En fundet besked bruges til at repræsentere et scenarie, hvor en ukendt kilde sender beskeden. Det er repræsenteret ved hjælp af en pil rettet mod en livline fra et slutpunkt.

For eksempel:

Overvej scenariet med en hardwarefejl.

Det kan skyldes flere årsager, og vi er ikke sikre på, hvad der forårsagede hardwarefejlen.

1.9. Mistet besked

En Lost-meddelelse bruges til at repræsentere et scenario, hvor modtageren ikke er kendt af systemet. Det er repræsenteret ved hjælp af en pil rettet mod et endepunkt fra en livline.

For eksempel:

ubuntu hvilken kommando

Overvej et scenarie, hvor en advarsel genereres.

Advarslen kan genereres for brugeren eller anden software/genstand, som livlinen interagerer med. Da destinationen ikke er kendt på forhånd, bruger vi tabt besked-symbolet.

1.10. Vagter

Til at modellere forhold bruger vi vagter i UML. De bruges, når vi skal begrænse strømmen af ​​beskeder under påskud af, at en betingelse er opfyldt. Vagter spiller en vigtig rolle i at lade softwareudviklere kende de begrænsninger, der er knyttet til et system eller en bestemt proces.

For eksempel:

For at kunne hæve kontanter, er det at have en saldo større end nul en betingelse, der skal være opfyldt som vist nedenfor.

Ovenstående sekvensdiagram viser sekvensdiagrammet for en følelsesbaseret musikafspiller:

1. Først åbnes applikationen af ​​brugeren.
2. Enheden får derefter adgang til webkameraet.
3. Webkameraet fanger billedet af brugeren.
4. Enheden bruger algoritmer til at registrere ansigtet og forudsige stemningen.
5. Derefter anmoder den om database til ordbog over mulige stemninger.
6. Stemningen hentes fra databasen.
7. Stemningen vises for brugeren.
8. Musikken anmodes fra databasen.
9. Afspilningslisten genereres og vises til sidst for brugeren.

2. Hvordan opretter man sekvensdiagrammer?

Oprettelse af et sekvensdiagram involverer flere trin, og det gøres typisk under designfasen af ​​softwareudvikling for at illustrere, hvordan forskellige komponenter eller objekter interagerer over tid. Her er en trin-for-trin guide til, hvordan du opretter sekvensdiagrammer:

1. Identificer scenariet:
   • Forstå det specifikke scenarie eller use case, som du ønsker at repræsentere i sekvensdiagrammet. Dette kan være en specifik interaktion mellem objekter eller strømmen af ​​meddelelser i en bestemt proces.
2. Liste over deltagerne:
   • Identificer deltagerne (objekter eller aktører) involveret i scenariet. Deltagerne kan være brugere, systemer eller eksterne enheder.
3. Definer livslinjer:
   • Tegn en lodret stiplet linje for hver deltager, der repræsenterer livslinjen for hvert objekt over tid. Livslinjen repræsenterer eksistensen af ​​et objekt under interaktionen.
4. Arranger livslinjer:
   • Placer livlinerne vandret i rækkefølgen af ​​deres involvering i interaktionen. Dette hjælper med at visualisere strømmen af ​​beskeder mellem deltagerne.
5. Tilføj aktiveringsbjælker:
   • For hver besked skal du tegne en aktiveringsbjælke på den afsendende deltagers livline. Aktiveringsbjælken repræsenterer varigheden af ​​det tidsrum, hvori deltageren aktivt behandler beskeden.
6. Tegn beskeder:
   • Brug pile til at repræsentere beskeder mellem deltagere. Meddelelser flyder vandret mellem livslinjer, hvilket indikerer kommunikationen mellem objekter. Forskellige typer meddelelser omfatter synkrone (udfyldt pil), asynkrone (stiplet pil) og selvbeskeder.
7. Inkluder returbeskeder:
   • Hvis en deltager sender en svarmeddelelse, skal du tegne en stiplet pil, der vender tilbage til den oprindelige afsender for at repræsentere returmeddelelsen.
8. Angiv timing og rækkefølge:
   • Brug tal til at angive rækkefølgen af ​​beskeder i rækkefølgen. Du kan også bruge lodrette stiplede linjer til at repræsentere forekomster af begivenheder eller tidens gang.
9. Inkluder betingelser og løkker:
   • Brug kombinerede fragmenter til at repræsentere betingelser (som if-sætninger) og sløjfer i interaktionen. Dette tilføjer kompleksitet til sekvensdiagrammet og hjælper med at detaljere kontrolflowet.
10. Overvej parallel udførelse:
    • Hvis der sker parallelle aktiviteter, skal du repræsentere dem ved at tegne parallelle lodrette stiplede linjer og placere meddelelserne i overensstemmelse hermed.
11. Gennemgå og forfin:
    • Gennemgå sekvensdiagrammet for klarhed og korrekthed. Sørg for, at den nøjagtigt repræsenterer den tilsigtede interaktion. Forfin efter behov.
12. Tilføj anmærkninger og kommentarer:
    • Medtag yderligere oplysninger, anmærkninger eller kommentarer, der giver kontekst eller afklaring af elementer i diagrammet.
13. Dokumentantagelser og begrænsninger:
    • Hvis der er nogen antagelser eller begrænsninger relateret til interaktionen, skal du dokumentere dem ved siden af ​​diagrammet.
14. Værktøjer:
    • Brug et UML-modelleringsværktøj eller diagramsoftware til at skabe et pænt og professionelt udseende sekvensdiagram. Disse værktøjer giver ofte funktioner til nem redigering, samarbejde og dokumentation.

3. Brug eksempler på sekvensdiagrammer

• Systemadfærdsvisualisering:
  • Sekvensdiagrammer bruges til at illustrere et systems dynamiske adfærd ved at vise interaktionerne mellem forskellige komponenter, objekter eller aktører over tid.
  • De giver en klar og visuel repræsentation af strømmen af ​​beskeder og begivenheder i et specifikt scenarie.
• Softwaredesign og arkitektur:
  • Under designfasen af ​​softwareudvikling hjælper sekvensdiagrammer udviklere og arkitekter med at planlægge og forstå, hvordan forskellige komponenter og objekter vil interagere for at opnå specifikke funktionaliteter.
  • De giver en plan for systemets adfærd.
• Kommunikation og samarbejde:
  • Sekvensdiagrammer fungerer som et kommunikationsværktøj mellem interessenter, herunder udviklere, designere, projektledere og kunder.
  • De hjælper med at formidle komplekse interaktioner i et letforståeligt visuelt format, hvilket fremmer samarbejde og fælles forståelse.
• Kravafklaring:
  • Ved forfining af systemkrav kan sekvensdiagrammer bruges til at tydeliggøre og specificere de forventede interaktioner mellem systemkomponenter eller mellem systemet og eksterne enheder.
  • De er med til at sikre en fælles forståelse af systemets adfærd blandt alle interessenter.
• Fejlfinding og fejlfinding:
  • Udviklere bruger sekvensdiagrammer som et fejlfindingsværktøj til at identificere og analysere problemer relateret til rækkefølgen og timingen af ​​meddelelser under systeminteraktioner.
  • Det giver en visuel repræsentation af kontrolstrømmen og hjælper med at lokalisere og løse problemer.

4. Udfordringer ved at bruge sekvensdiagrammer

• kompleksitet og størrelse:
  • Efterhånden som systemer vokser i kompleksitet, kan sekvensdiagrammer blive store og indviklede. Det kan være udfordrende at styre størrelsen af ​​diagrammet, mens de stadig repræsenterer interaktionerne nøjagtigt, og alt for komplekse diagrammer kan blive svære at forstå.
• Abstraktionsniveau:
  • At finde den rigtige balance med hensyn til abstraktion kan være udfordrende. Sekvensdiagrammer skal være detaljerede nok til at formidle den nødvendige information, men for mange detaljer kan overvælde læserne. Det er vigtigt at fokusere på de mest kritiske interaktioner uden at blive hængende i detaljer.
• Dynamisk natur:
  • Sekvensdiagrammer repræsenterer dynamiske aspekter af et system, og som følge heraf kan de ændre sig ofte under udviklingsprocessen. Det kan være en udfordring at holde sekvensdiagrammer opdateret med det udviklende system, især i hurtigt skiftende eller agile udviklingsmiljøer.
• Tvetydighed i meddelelser:
  • Nogle gange kan det være udfordrende at definere den nøjagtige karakter af meddelelser mellem objekter. Tvetydighed i meddelelsens indhold eller betydning kan føre til misforståelser blandt interessenter og påvirke nøjagtigheden af ​​sekvensdiagrammet.
• Samtidighed og parallelisme:
  • Det kan være komplekst at repræsentere samtidige og parallelle processer. Mens sekvensdiagrammer har mekanismer til at angive parallel udførelse, kan visualisering af flere interaktioner, der sker samtidigt, være udfordrende og kan kræve yderligere diagrammatiske elementer.
• Realtidsbegrænsninger:
  • At repræsentere realtidsbegrænsninger og præcise timingkrav kan være udfordrende. Mens sekvensdiagrammer giver en sekventiel repræsentation, kan nøjagtig opfangning og kommunikation af realtidsaspekter kræve yderligere dokumentation eller komplementære diagrammer.