Uniforme modelleringstaal (UML) is een modelleringstaal op het gebied van software-engineering die tot doel heeft standaardmanieren vast te stellen om het ontwerp van een systeem te visualiseren. UML begeleidt het maken van meerdere soorten diagrammen, zoals interactie-, structuur- en gedragsdiagrammen. A sequentiediagram wordt het meest gebruikt interactie diagram.

Interactiediagram

Om dit weer te geven wordt gebruik gemaakt van een interactiediagram interactief gedrag van een systeem. Omdat het visualiseren van de interacties in een systeem moeilijk kan zijn, gebruiken we verschillende soorten interactiediagrammen om verschillende kenmerken en aspecten van interactie in een systeem vast te leggen.

• Een sequentiediagram geeft eenvoudigweg de interactie tussen de objecten weer in een opeenvolgende volgorde, dat wil zeggen de volgorde waarin deze interacties plaatsvinden.
• We kunnen ook de termen gebeurtenisdiagrammen of gebeurtenisscenario's gebruiken om naar een sequentiediagram te verwijzen.
• Volgordediagrammen beschrijven hoe en in welke volgorde de objecten in een systeem functioneren.
• Deze diagrammen worden veel gebruikt door zakenmensen en softwareontwikkelaars om de vereisten voor nieuwe en bestaande systemen te documenteren en te begrijpen.

Belangrijke onderwerpen voor de sequentiediagrammen

• Sequentiediagramnotatie
• Acteurs
  • Reddingslijnen
  • Berichten
  • Creeër bericht
  • Verwijder bericht
  • Zelf bericht
  • Antwoord
  • Gevonden bericht
  • Verloren bericht
  • Bewakers
• Hoe maak ik reeksdiagrammen?
• Gebruik cases van sequentiediagrammen
• Uitdagingen bij het gebruik van reeksdiagrammen

1. Notatie van het sequentiediagram

1.1. Acteurs

Een actor in een UML-diagram vertegenwoordigt een soort rol waarin hij interageert met het systeem en zijn objecten. Het is belangrijk om hier op te merken dat een actor altijd buiten de reikwijdte valt van het systeem dat we willen modelleren met behulp van het UML-diagram.

We gebruiken acteurs om verschillende rollen uit te beelden, waaronder menselijke gebruikers en andere externe onderwerpen. We vertegenwoordigen een actor in een UML-diagram met behulp van een stokpersoonnotatie. We kunnen meerdere actoren in een sequentiediagram hebben.

Bijvoorbeeld:

Hier wordt de gebruiker in het stoelreserveringssysteem weergegeven als een actor waar deze buiten het systeem bestaat en geen deel uitmaakt van het systeem.

1.2. Reddingslijnen

Een levenslijn is een benoemd element dat een individuele deelnemer in een sequentiediagram weergeeft. Dus eigenlijk wordt elke instantie in een sequentiediagram weergegeven door een levenslijn. Levenslijnelementen bevinden zich bovenaan in een volgordediagram. De standaard in UML voor het benoemen van een levenslijn volgt het volgende formaat:

Instantienaam: Klassenaam

wat is 25 van de 100

We geven een levenslijn weer in een rechthoek genaamd hoofd met zijn naam en type. De kop bevindt zich bovenop een verticale stippellijn (de stengel genoemd), zoals hierboven weergegeven.

• Als we een naamloos exemplaar willen modelleren, volgen we hetzelfde patroon, behalve dat nu het gedeelte van de naam van de levenslijn leeg wordt gelaten.
• Het verschil tussen een levenslijn en een acteur
  • Een levenslijn portretteert altijd een object dat zich binnen het systeem bevindt, terwijl acteurs worden gebruikt om objecten buiten het systeem af te beelden.

Hieronder ziet u een voorbeeld van een sequentiediagram:

1.3. Berichten

Communicatie tussen objecten wordt weergegeven met behulp van berichten. De berichten verschijnen in opeenvolgende volgorde op de levenslijn.

• We geven berichten weer met pijlen.
• Levenslijnen en boodschappen vormen de kern van een sequentiediagram.

Berichten kunnen grofweg in de volgende categorieën worden ingedeeld:

Synchrone berichten

Een synchroon bericht wacht op een antwoord voordat de interactie verder kan gaan. De afzender wacht totdat de ontvanger de verwerking van het bericht heeft voltooid. De beller gaat alleen verder als hij weet dat de ontvanger het vorige bericht heeft verwerkt, dat wil zeggen dat hij een antwoordbericht ontvangt.

• Een groot aantal oproepen bij objectgeoriënteerd programmeren is synchroon.
• Wij gebruiken een stevige pijlpunt om een ​​synchrone boodschap weer te geven.

Asynchrone berichten

Een asynchroon bericht wacht niet op een antwoord van de ontvanger. De interactie gaat door, ongeacht of de ontvanger het vorige bericht verwerkt of niet. Wij gebruiken een gevoerde pijlpunt om een ​​asynchrone boodschap weer te geven.

1.4. Creeër bericht

We gebruiken een Create-bericht om een ​​nieuw object in het sequentiediagram te instantiëren. Er zijn situaties waarin een bepaalde berichtoproep de creatie van een object vereist. Het wordt weergegeven met een gestippelde pijl en een woord dat erop is gelabeld om aan te geven dat dit het symbool voor het maken van een bericht is.

Bijvoorbeeld:

Voor het aanmaken van een nieuwe bestelling op een e-commercewebsite zou een nieuw object van de klasse Bestelling moeten worden aangemaakt.

1.5. Verwijder bericht

Om een ​​object te verwijderen gebruiken wij een Verwijderingsbericht. Wanneer het geheugen van een object wordt opgeheven of binnen het systeem wordt vernietigd, gebruiken we het symbool Bericht verwijderen. Het vernietigt het voorkomen van het object in het systeem. Het wordt weergegeven door een pijl die eindigt met een x.

maak de tekst vet in css

Bijvoorbeeld:

In het onderstaande scenario, wanneer de bestelling door de gebruiker wordt ontvangen, kan het object van de bestelklasse worden vernietigd.

1.6. Zelf bericht

Er kunnen zich bepaalde scenario's voordoen waarin het object een bericht naar zichzelf moet sturen. Dergelijke berichten worden Zelfberichten genoemd en worden weergegeven met een U-vormige pijl .

Een ander voorbeeld:

Overweeg een scenario waarin het apparaat toegang wil krijgen tot de webcam. Een dergelijk scenario wordt weergegeven met behulp van een zelfbericht.

1.7. Antwoord

Antwoordberichten worden gebruikt om het bericht weer te geven dat van de ontvanger naar de afzender wordt verzonden. We vertegenwoordigen een retour-/antwoordbericht met behulp van een open pijlpunt met een stippellijn . De interactie gaat alleen verder als er een antwoordbericht door de ontvanger wordt verzonden.

Bijvoorbeeld:

Neem het scenario waarin het apparaat de gebruiker om een ​​foto vraagt. Hier is het bericht waarin de verzonden foto wordt weergegeven een antwoordbericht.

tekenreeks Java toevoegen

1.8. Gevonden bericht

Een gevonden bericht wordt gebruikt om een ​​scenario weer te geven waarin een onbekende bron het bericht verzendt. Het wordt weergegeven met behulp van een pijl gericht op een reddingslijn vanaf een eindpunt.

Bijvoorbeeld:

Neem het scenario van een hardwarefout.

Dit kan verschillende redenen hebben en we weten niet zeker wat de hardwarefout heeft veroorzaakt.

1.9. Verloren bericht

Een verloren bericht wordt gebruikt om een ​​scenario weer te geven waarin de ontvanger niet bekend is bij het systeem. Dit wordt weergegeven met een pijl die vanaf een reddingslijn naar een eindpunt wijst.

Bijvoorbeeld:

Overweeg een scenario waarin een waarschuwing wordt gegenereerd.

De waarschuwing kan worden gegenereerd voor de gebruiker of voor andere software/object waarmee de levenslijn communiceert. Omdat de bestemming op voorhand niet bekend is, gebruiken wij het Lost Message-symbool.

1.10. Bewakers

Om condities te modelleren gebruiken we guards in UML. Ze worden gebruikt wanneer we de stroom berichten moeten beperken onder het voorwendsel dat aan een voorwaarde wordt voldaan. Bewakers spelen een belangrijke rol bij het informeren van softwareontwikkelaars over de beperkingen die aan een systeem of een bepaald proces zijn verbonden.

Bijvoorbeeld:

Om contant geld op te kunnen nemen is het hebben van een saldo groter dan nul een voorwaarde waaraan voldaan moet worden zoals hieronder weergegeven.

Het bovenstaande sequentiediagram toont het sequentiediagram voor een op emoties gebaseerde muziekspeler:

1. Eerst wordt de applicatie door de gebruiker geopend.
2. Het apparaat krijgt vervolgens toegang tot de webcam.
3. De webcam legt het beeld van de gebruiker vast.
4. Het apparaat gebruikt algoritmen om het gezicht te detecteren en de stemming te voorspellen.
5. Vervolgens vraagt ​​het een database aan voor een woordenboek met mogelijke stemmingen.
6. De stemming wordt uit de database gehaald.
7. De stemming wordt aan de gebruiker weergegeven.
8. De muziek wordt opgevraagd uit de database.
9. De afspeellijst wordt gegenereerd en uiteindelijk aan de gebruiker getoond.

2. Hoe maak ik reeksdiagrammen?

Het maken van een sequentiediagram omvat verschillende stappen en wordt doorgaans gedaan tijdens de ontwerpfase van softwareontwikkeling om te illustreren hoe verschillende componenten of objecten in de loop van de tijd met elkaar omgaan. Hier vindt u een stapsgewijze handleiding voor het maken van reeksdiagrammen:

1. Identificeer het scenario:
   • Begrijp het specifieke scenario of gebruiksscenario dat u in het sequentiediagram wilt weergeven. Dit kan een specifieke interactie tussen objecten zijn of de stroom van berichten in een bepaald proces.
2. Maak een lijst van de deelnemers:
   • Identificeer de deelnemers (objecten of actoren) die bij het scenario betrokken zijn. Deelnemers kunnen gebruikers, systemen of externe entiteiten zijn.
3. Definieer levenslijnen:
   • Teken voor elke deelnemer een verticale stippellijn, die de levenslijn van elk object in de loop van de tijd weergeeft. De levenslijn vertegenwoordigt het bestaan ​​van een object tijdens de interactie.
4. Reddingslijnen regelen:
   • Plaats de levenslijnen horizontaal in de volgorde van hun betrokkenheid bij de interactie. Dit helpt bij het visualiseren van de berichtenstroom tussen deelnemers.
5. Activeringsbalken toevoegen:
   • Teken voor elk bericht een activeringsbalk op de levenslijn van de verzendende deelnemer. De activeringsbalk vertegenwoordigt de tijdsduur waarin de deelnemer het bericht actief verwerkt.
6. Teken berichten:
   • Gebruik pijlen om berichten tussen deelnemers weer te geven. Berichten stromen horizontaal tussen levenslijnen en geven de communicatie tussen objecten aan. Verschillende soorten berichten zijn onder meer synchrone (ononderbroken pijl), asynchrone (onderbroken pijl) en zelfberichten.
7. Retourberichten opnemen:
   • Als een deelnemer een antwoordbericht verzendt, tekent u een stippellijn die terugkeert naar de oorspronkelijke afzender om het antwoordbericht weer te geven.
8. Geef timing en bestelling aan:
   • Gebruik cijfers om de volgorde van de berichten in de reeks aan te geven. U kunt ook verticale stippellijnen gebruiken om gebeurtenissen of het verstrijken van de tijd weer te geven.
9. Voorwaarden en lussen opnemen:
   • Gebruik gecombineerde fragmenten om voorwaarden (zoals if-instructies) en lussen in de interactie weer te geven. Dit voegt complexiteit toe aan het sequentiediagram en helpt bij het detailleren van de besturingsstroom.
10. Overweeg parallelle uitvoering:
    • Als er parallelle activiteiten plaatsvinden, geef deze dan weer door parallelle verticale stippellijnen te tekenen en de berichten dienovereenkomstig te plaatsen.
11. Beoordelen en verfijnen:
    • Controleer het sequentiediagram op duidelijkheid en juistheid. Zorg ervoor dat deze de beoogde interactie nauwkeurig weergeeft. Verfijn indien nodig.
12. Annotaties en opmerkingen toevoegen:
    • Voeg eventuele aanvullende informatie, annotaties of opmerkingen toe die context of verduidelijking bieden voor elementen in het diagram.
13. Documentaannames en beperkingen:
    • Als er aannames of beperkingen zijn met betrekking tot de interactie, documenteer deze dan naast het diagram.
14. Hulpmiddelen:
    • Gebruik een UML-modelleringstool of diagramsoftware om een ​​netjes en professioneel ogend sequentiediagram te maken. Deze tools bieden vaak functies voor eenvoudige bewerking, samenwerking en documentatie.

3. Gebruiksscenario's van sequentiediagrammen

• Visualisatie van systeemgedrag:
  • Sequentiediagrammen worden gebruikt om het dynamische gedrag van een systeem te illustreren door de interacties tussen verschillende componenten, objecten of actoren in de loop van de tijd weer te geven.
  • Ze bieden een duidelijke en visuele weergave van de stroom aan berichten en gebeurtenissen in een specifiek scenario.
• Softwareontwerp en architectuur:
  • Tijdens de ontwerpfase van softwareontwikkeling helpen sequentiediagrammen ontwikkelaars en architecten bij het plannen en begrijpen van hoe verschillende componenten en objecten zullen samenwerken om specifieke functionaliteiten te verwezenlijken.
  • Ze bieden een blauwdruk voor het gedrag van het systeem.
• Communicatie en samenwerking:
  • Volgordediagrammen dienen als communicatiemiddel tussen belanghebbenden, waaronder ontwikkelaars, ontwerpers, projectmanagers en klanten.
  • Ze helpen bij het overbrengen van complexe interacties in een gemakkelijk te begrijpen visueel formaat, waardoor samenwerking en gedeeld begrip worden bevorderd.
• Verduidelijking van vereisten:
  • Bij het verfijnen van systeemvereisten kunnen sequentiediagrammen worden gebruikt om de verwachte interacties tussen systeemcomponenten of tussen het systeem en externe entiteiten te verduidelijken en te specificeren.
  • Ze helpen ervoor te zorgen dat alle belanghebbenden een gemeenschappelijk begrip van het systeemgedrag krijgen.
• Foutopsporing en probleemoplossing:
  • Ontwikkelaars gebruiken sequentiediagrammen als foutopsporingstool om problemen met betrekking tot de volgorde en timing van berichten tijdens systeeminteracties te identificeren en te analyseren.
  • Het biedt een visuele weergave van de controlestroom en helpt bij het lokaliseren en oplossen van problemen.

4. Uitdagingen bij het gebruik van sequentiediagrammen

• Complexiteit en omvang:
  • Naarmate systemen steeds complexer worden, kunnen sequentiediagrammen groot en ingewikkeld worden. Het kan een uitdaging zijn om de grootte van het diagram te beheren en tegelijkertijd de interacties accuraat weer te geven, en al te complexe diagrammen kunnen moeilijk te begrijpen worden.
• Abstractieniveau:
  • Het vinden van de juiste balans in termen van abstractie kan een uitdaging zijn. Volgordediagrammen moeten gedetailleerd genoeg zijn om de noodzakelijke informatie over te brengen, maar te veel details kunnen lezers overweldigen. Het is belangrijk om je te concentreren op de meest kritische interacties, zonder te verzanden in details.
• Dynamische aard:
  • Volgordediagrammen vertegenwoordigen dynamische aspecten van een systeem, en als gevolg daarvan kunnen ze tijdens het ontwikkelingsproces regelmatig veranderen. Het up-to-date houden van sequentiediagrammen met het evoluerende systeem kan een uitdaging zijn, vooral in snel veranderende of flexibele ontwikkelomgevingen.
• Dubbelzinnigheid in berichten:
  • Soms kan het een uitdaging zijn om de exacte aard van berichten tussen objecten te definiëren. Dubbelzinnigheid in de inhoud of betekenis van berichten kan leiden tot misverstanden onder belanghebbenden en de nauwkeurigheid van het sequentiediagram beïnvloeden.
• Gelijktijdigheid en parallellisme:
  • Het weergeven van gelijktijdige en parallelle processen kan complex zijn. Hoewel sequentiediagrammen mechanismen hebben om parallelle uitvoering aan te geven, kan het visualiseren van meerdere interacties die tegelijkertijd plaatsvinden een uitdaging zijn en kunnen aanvullende diagrammatische elementen nodig zijn.
• Realtime beperkingen:
  • Het kan een uitdaging zijn om real-time beperkingen en precieze timingvereisten weer te geven. Hoewel sequentiediagrammen een sequentiële representatie bieden, kan het nauwkeurig vastleggen en communiceren van real-time aspecten aanvullende documentatie of aanvullende diagrammen vereisen.