A rendszerfunkciók leírását a Sequence diagramma segítségével pontosítjuk (a „Mókusok” folytatása)
Ebben a cikkben azt vizsgáljuk meg, hogyan lehet részletesebben (pontosítani) az automatizálandó funkció leírását UML Sequence Diagram — a folyamatábra segítségével.
Ebben a példában az ausztrál Sparx Systems cég Enterprise Architect környezetét használom, [1].
A UML teljes specifikációja [2].
Először is tisztázom, hogy mit fogunk részletezni.
A mi a "mesebeli" tartomány folyamatainak modellezésével foglalkoztunk — a mókusról szóló sorok A.S. Puskin "Szarajevói királyról" című meséjéből. Az Activity diagrammával kezdtük, majd funkcionális modellt készítettünk Use-case diagramma segítségével, az 1. ábrán egy részlet látható.
1. ábra. A követelmény és a funkció közötti kapcsolat
Most szeretnénk pontosítani az információt a szóban forgó automatizálandó funkció végrehajtásáról:
- mely interfészelemekkel fog kapcsolatba lépni a felhasználónk;
- milyen vezérlőelemekre lesz szükségünk;
- mit fogunk tárolni;
- mivel fognak cserélődni üzenetek a felhasználó és a rendszer elemei között a funkció végrehajtása érdekében.
A Sequence diagram alapvető elemei a különböző sztereotípiákkal rendelkező interakciós objektumok és az azok közötti kapcsolatok — az interakciós objektumok információt cserélnek egymással (2. ábra).
2. ábra. A Sequence diagram alapvető elemei
Az objektumok vízszintes sorrendben helyezkednek el, közöttük üzeneteket küldenek. Az idő tengely fentről lefelé van orientálva.
Az Actor elem használható a felhasználó reprezentálására, aki elindítja az eseménysort.
Minden objektum rendelkezik egy szaggatott vonallal, amelyet „életvonalnak” nevezünk, ahol ez az elem létezik és potenciálisan részt vesz az interakciókban. A vezérlési fókusz egy téglalappal van jelölve az objektum életvonalán.
Az objektumok által cserélt üzenetek többféle típusúak lehetnek, az üzenetek szintén beállíthatók, hogy tükrözzék a forrás- és célelemek műveleteit és tulajdonságait.
A sztereotípiás elemek, mint például a határok (Boundary), vezérlőelemek (Control) és entitások (Entity), felhasználói felület (GUI), vezérlők és adatbázis elemek modellezésére használhatók.
A repeating message exchange stream can be designated as a fragment of type 'loop'.
So, we plan to clarify the function description 'Add information about the new nut to the ledger'.
Let's agree on the following additional generalizations and assumptions.
- Nut, core, and shells are all types of material values (Figure 3).
Figure 3. Clarification of the class diagram - In the ledger, our user will enter information about any material values.
- Let's clarify the name of the ledger - 'Ledger of material values accounting'.
- Assuming that our user, while working with the GUI 'Ledger of material values accounting', can add a new material value through the GUI 'Material value accounting card'.
- Depending on the type of material value, the data structure and GUI change.
- When filling in the fields of the material value accounting card, the correctness of the entered data is checked.
The diagram built considering these assumptions is shown in Figure 4.
Figure 4. Clarification of the function description 'Add information about the new nut to the ledger'
You can read about the use of other types of UML diagrams here:
Irodalomjegyzék
- Sparx Systems weboldal. [Elektronikus forrás] Hozzáférés módja: Internet:
- OMG Egyesült Modellezési Nyelv (OMG UML) Specifikáció. 2.5.1-es verzió. [Elektronikus forrás] Hozzáférés módja: Internet:
Forrás: habr.com
