We verduidelijken de beschrijving van de systeemfuncties met behulp van het sequentiediagram (vervolg van "Eiwitten")
In dit artikel zullen we bekijken hoe u de beschrijving van de functie die wordt geautomatiseerd kunt detailleren (verduidelijken) met behulp van het UML-sequentiediagram.
In dit voorbeeld gebruik ik de Enterprise Architect-omgeving van een Australisch bedrijf. [1].
Zie voor de volledige UML-specificatie [2].
Laat me eerst uitleggen wat we zullen beschrijven.
В we hebben de processen van een 'sprookjesachtig' onderwerpgebied gemodelleerd - regels over een eekhoorn uit 'The Tale of Tsar Saltan' van A.S. Poesjkin. En we zijn begonnen met het activiteitendiagram. Dan in we hebben een functioneel model ontwikkeld met behulp van een Use-case-diagram, Figuur 1 toont een fragment.
Figuur 1. Relatie tussen eis en functie
Nu willen we informatie over de uitvoering van deze geautomatiseerde functie verduidelijken:
- met welke interfacecomponenten zal onze gebruiker communiceren;
- welke controlecomponenten we nodig hebben;
- wat we gaan opslaan;
- welke berichten worden uitgewisseld tussen de gebruiker en systeemcomponenten om de functie uit te voeren.
De belangrijkste elementen van het Sequentiediagram zijn op elkaar inwerkende objecten met verschillende stereotypen en verbindingen daartussen; op elkaar inwerkende objecten wisselen bepaalde informatie met elkaar uit (Afbeelding 2).
Figuur 2. Basiselementen van een reeksdiagram
Objecten worden in een horizontale volgorde gerangschikt en er worden berichten tussen hen doorgegeven. De tijdas is van boven naar beneden georiënteerd.
Het Actor-element kan worden gebruikt om een gebruiker weer te geven die een stroom gebeurtenissen initieert.
Elk object heeft een stippellijn, de "levenslijn" genoemd, waar dat element bestaat en mogelijk deelneemt aan interacties. De controlefocus wordt aangegeven door een rechthoek op de levenslijn van het object.
De berichten die tussen objecten worden uitgewisseld kunnen van verschillende typen zijn, en de berichten kunnen ook worden aangepast om de werking en eigenschappen van de bron- en doelelementen weer te geven.
Stereotiepe elementen zoals grenzen, controles en entiteiten kunnen worden gebruikt om respectievelijk de gebruikersinterface (GUI), controllers en database-elementen te modelleren.
Een zich herhalende stroom van berichten kan worden aangemerkt als een fragment met het type "loop".
Daarom zijn we van plan de beschrijving van de functie 'Informatie over een nieuwe noot aan de lijst toevoegen' te verduidelijken.
Laten we het eens worden over de volgende aanvullende generalisaties en aannames.
- Noot, pit en dop zijn allemaal materiële activa van de overeenkomstige typen (Figuur 3).
Figuur 3. Verfijning van het klassendiagram - Onze gebruiker zal informatie over eventuele materiële activa in de verklaring invoeren.
- Laten we de naam van de verklaring verduidelijken: "Verklaring van de boekhouding van materiële waarden."
- Laten we aannemen dat onze gebruiker, die werkt met de GUI “Material Values Accounting Sheet”, een nieuwe financiële waarde kan toevoegen via de GUI “Material Values Accounting Card”.
- Afhankelijk van het type wiskundige waarde veranderen de datastructuur en GUI.
- Bij het invullen van de velden van de materiaalwaardeboekingskaart wordt de juistheid van de ingevoerde gegevens gecontroleerd.
Een diagram gebaseerd op deze aannames wordt getoond in Figuur 4.
Figuur 4. Verduidelijking van de beschrijving van de functie “Voeg informatie over een nieuwe noot toe aan de lijst”
Over het gebruik van andere soorten UML-diagrammen kunt u hier lezen:
Lijst met bronnen
- Sparx Systems-website. [Elektronische bron] Toegangsmodus: Internet:
- OMG Unified Modeling Language-specificatie (OMG UML). Versie 2.5.1. [Elektronische bron] Toegangsmodus: Internet:
Bron: www.habr.com