Selgitame süsteemi funktsioone Sequence diagrammi abil.

Selgitame süsteemi funktsioone Sequence diagrammi abil (jätkub "Pähklid").

Selles artiklis vaatleme, kuidas saab automatiseeritava funktsiooni kirjeldust üksikasjalikumalt selgitada UML Sequence diagrammi abil.

Antud näites kasutan Austraalia ettevõtte Enterprise Architect keskkonda. Sparx Systems [1].
UML täielik spetsifikatsioon vt. siin [2].

Alustuseks selgitan, millest me räägime.
Uues 1. osa artiklist "Protsesside modelleerimisest automatiseeritud süsteemi projekteerimisele" me modelleerisime "muinasjuttude" teema ala protsesse — read, mis räägivad oravast A.S. Puškini "Tsaar Saltaani muinasjutt". Alustasime Activity diagrammiga. Siis, 2. osa arendasime välja funktsionaalmodeli Use-case diagrammi abil, joonisel 1 on esitatud fragment.

Joonis 1. Nõude ja funktsiooni suhe

Nüüd tahame selgitada, kuidas see automatiseeritav funktsioon toimib:

• milliste liidese komponentidega kasutaja suhtleb;
• millised juhtimis komponendid me vajame;
• mida me salvestame;
• milliste sõnumitega kasutaja ja süsteemi komponendid funktsiooni täitmiseks suhtlevad.

Sequence diagrammi põhielemendid on omavahel suhtlevad objektid erinevate stereotüüpidega ning nende vahelised sidemed — suhtlevad objektid vahetavad omavahel teatud teavet (joonis 2).

Joonis 2. Sequence diagrammi põhielemendid

Objektid on paigutatud horisontaalsesse järjestusse, nende vahel edastatakse sõnumeid. Aja telg on suunatud ülalt alla.
Actor element võiks esindada kasutajat, kes käivitab sündmusteahela.
Igal objektil on katkendlik joon, mida nimetatakse "eluliiniks", kus see element eksisteerib ja potentsiaalselt osaleb suhtlemistes. Juhtimise fookust näidatakse objekti eluliinil ristkülikuga.
Objektidevahelised sõnumid võivad olla erinevat tüüpi, sõnumid võivad samuti olla kohandatud peegelduseks algse ja sihtobjekti operatsioonide ja omaduste suhtes.
Stereotüüpsed elemendid, nagu piirid (Boundary), juhtnupud (Control) ja üksused (Entity), võivad olla kasutatud kasutajaliidese (GUI), kontrollerite ja andmebaaselementide modelleerimiseks vastavalt.
Korduv sõnumite vahetus võib olla tähistatud fragmentina, mille tüüp on "loop".

Nii et kavatseme täpsustada funktsiooni "Lisada arvele teave uue pähkli kohta" kirjelduse.
Kokkulepime järgmiste täiendavate üldistuste ja eelduste osas.

1. Pähkel, süda ja kestad on kõik vastavate tüüpide materiaalne väärtus (Joonis 3).
   
   Joonis 3. Klassidiagrammi täpsustamine
2. Arvele kannab meie kasutaja teavet igasuguste materiaalsete väärtuste kohta.
3. Täpistame arve nimetuse — "Materiaalsete väärtuste arve".
4. Oletame, et meie kasutaja, töötades GUI-d "Materiaalsete väärtuste arve", võib lisada uue materiaalsete väärtuste kaudu GUI-d "Materiaalsete väärtuste kaardis".
5. Materiaalsete väärtuste tüübi järgi muutub andmestruktuur ja GUI.
6. Materiaalsete väärtuste kaardi väljade täitmisel toimub sisestatud andmete korrektsuse kontroll.

Diagramm, mis on koostatud nende eelduste arvesse võtmisega, on esitatud Joonisel 4.

Joonis 4. Funktsiooni "Lisada arvele teave uue pähkli kohta" kirjelduse täpsustamine

Teiste UML diagrammide kohta saab lugeda siit:

• Protsesside modelleerimisest automatiseeritud süsteemi kavandamiseni (Osa 1);
• Protsesside modelleerimisest automatiseeritud süsteemi kavandamiseni (Osa 2);
• Kaks lähenemist Activity diagrammi struktureerimiseks.

Viidatud allikad

1. Sait Sparx Systems. [Elektrooniline ressurss] Ligipääs: Internet: https://sparxsystems.com
2. OMG Ühtne modelleerimise keel (OMG UML) spetsifikatsioon. Versioon 2.5.1. [Elektrooniline ressurss] Ligipääs: Internet: https://www.omg.org/spec/UML/2.5.1/PDF

Allikas: habr.com