We verduidelijken de beschrijving van de systeemfuncties met behulp van een sequentiediagram (vervolg van "Eekhoorns")
In dit artikel bekijken we hoe we de beschrijving van de te automatiseren functie kunnen specificeren met behulp van een UML-sequentiediagram.
In dit voorbeeld maak ik gebruik van de Enterprise Architect omgeving van het Australische bedrijf [1].
De volledige UML-specificatie zie. [2].
Eerst wil ik uitleggen dat we zullen specificeren.
In hebben we de processen gemodelleerd in het "sprookjesachtige" domein ā zinnen over de eekhoorn uit "Het sprookje van Tsaar Saltan" van A.S. Pushkin. We begonnen met een activiteitendiagram. Toen in hebben we een functioneel model ontwikkeld met behulp van een use-case-diagram, op Figuur 1 is een fragment weergegeven.
Figuur 1. Relatie tussen de vereiste en functie
Nu willen we de informatie over de uitvoering van deze te automatiseren functie verduidelijken:
- met welke interfacecomponenten onze gebruiker zal interageren;
- welke besturingscomponenten we nodig zullen hebben;
- wat we zullen opslaan;
- met welke berichten de gebruiker en de systeemcomponenten zullen communiceren om de functie uit te voeren.
De belangrijkste elementen van het sequentiediagram zijn de interactieve objecten met verschillende stereotypen en de verbindingen ertussen ā de interactieve objecten wisselen bepaalde informatie uit (Figuur 2).
Figuur 2. Hoofdelementen van het sequentiediagram
De objecten zijn in een horizontale volgorde geplaatst, tussen hen worden berichten verzonden. De tijdas is van boven naar beneden georiƫnteerd.
Het acteur-element kan worden gebruikt om de gebruiker weer te geven die de gebeurtenisstroom initieert.
Elk object heeft een gestippelde lijn, die de "levenslijn" wordt genoemd, waar dit element bestaat en potentieel deelneemt aan interacties. De focus van de controle wordt aangeduid met een rechthoek op de levenslijn van het object.
Berichten die tussen objecten worden uitgewisseld, kunnen van verschillende types zijn, berichten kunnen ook worden ingesteld om de bewerkingen en eigenschappen van de bron- en doelelementen weer te geven.
Stereotypische elementen zoals grenzen (Boundary), besturingscomponenten (Control) en entiteiten (Entity) kunnen worden gebruikt voor het modelleren van de gebruikersinterface (GUI), controllers en database-elementen, respectievelijk.
Een herhaald berichtverkeer kan worden aangeduid als een fragment van het type "loop".
We zijn van plan de beschrijving van de functie "Informatie over de nieuwe noot aan de lijst toevoegen" te verduidelijken.
Laten we overeenkomen over de volgende aanvullende samenvattingen en aannames.
- Noot, kern en schalen zijn allemaal materiƫle waarden van de respectieve types (Figuur 3).
Figuur 3. Verduidelijking van het klassendiagram. - In de lijst zal onze gebruiker informatie over alle materiƫle waarden invoeren.
- Laten we de naam van de lijst verduidelijken ā "Lijst van materiĆ«le waarden".
- Stel dat onze gebruiker, terwijl hij werkt met de GUI "Lijst van materiƫle waarden", een nieuwe materiƫle waarde kan toevoegen via de GUI "Kaart van materiƫle waarde".
- Afhankelijk van het type materiƫle waarde verandert de datastructuur en de GUI.
- Bij het invullen van de velden van de kaart van materiƫle waarde wordt de juistheid van de ingevoerde gegevens gecontroleerd.
Het diagram, opgesteld rekening houdend met deze aannames, is te zien in Figuur 4.
Figuur 4. Verduidelijking van de beschrijving van de functie "Informatie over de nieuwe noot aan de lijst toevoegen".
Over het gebruik van andere soorten UML-diagrammen kunt u hier lezen:
Lijst van bronnen
- Website van Sparx Systems. [Elektronische bron] Toegang: Internet:
- OMG Unified Modeling Language (OMG UML) Specificatie. Versie 2.5.1. [Elektronische bron] Toegang: Internet:
Bron: habr.com
