Določamo opis funkcij sistema s pomočjo sekvenčne diagrama (nadaljevanje „Belki“)
V tem članku bomo raziskali, kako lahko podrobneje določimo opis avtomatizirane funkcije s pomočjo UML sekvenčne diagrama.
V tem primeru uporabljam okolje Enterprise Architect avstralskega podjetja [1].
Polno specifikacijo UML glej. [2].
Za začetek naj razložim, kaj bomo podrobneje določili.
V smo modelirali procese „pravljice“ tematskega področja — vrstice o veverici iz „Pravljice o carju Saltanu“ A.S. Puškina. In začeli smo z diagramom aktivnosti. Nato smo smo razvili funkcionalni model s pomočjo diagramov Use-case, na slikovni 1 pa je prikazan izrez.
Slika 1. Povezava med zahtevami in funkcijami
Zdaj želimo podrobneje pojasniti informacije o izvajanju te avtomatizirane funkcije:
- s katerimi komponentami vmesnika bo naš uporabnik komuniciral;
- katere nadzorne komponente bomo potrebovali;
- kaj bomo shranili;
- s katerimi sporočili se bodo izmenjevali uporabnik in sistemi za izvajanje funkcije.
Osnovni elementi sekvenčne diagrama so medsebojno delujoči objekti z različnimi stereotipi ter povezave med njimi — interaktivni objekti si med seboj izmenjujejo določene informacije (Slika 2).
Slika 2. Osnovni elementi sekvenčne diagrama
Objekti so razporejeni v horizontalnem zaporedju, med njimi se prenašajo sporočila. Časovna os je usmerjena od zgoraj navzdol.
Element Actor se lahko uporablja za predstavitev uporabnika, ki sproži tok dogodkov.
Vsak objekt ima črtasto linijo, imenovano „životna linija“, kjer ta element obstaja in potencialno sodeluje v interakcijah. Fokus upravljanja je označen s pravokotnikom na životni liniji objekta.
Sporočila, s katerimi si izmenjujejo objekti, so lahko več vrst, sporočila so tudi lahko prilagojena, da odražajo operacije in lastnosti izvornih in ciljnih elementov.
Stereotipni elementi, kao što su granice (Boundary), elementi kontrole (Control) i entiteti (Entity), mogu se koristiti za modeliranje korisničkog interfejsa (GUI), kontrolera i elemenata baze podataka, prema tome.
Ponovljeni tok razmene poruka može biti označen kao fragment tipa „loop“.
Dakle, planiramo da preciziramo opis funkcije „Dodati u obračun informaciju o novoj orašasti.“
Dogovorimo se o sledećim dodatnim generalizacijama i pretpostavkama.
- Orašasti plod, jezgro i ljuske su sve materijalne vrednosti odgovarajućih tipova (Slika 3).
Slika 3. Preciziranje dijagrama klasa. - U obračun naš korisnik će unositi informacije o bilo kojim materijalnim vrednostima.
- Precizirajmo naziv obračuna — „Obračun materijalnih vrednosti.“
- Pretpostavimo da naš korisnik, radeći sa GUI „Obračun materijalnih vrednosti“, može dodati novu materijalnu vrednost putem GUI „Kartica za evidenciju materijalne vrednosti.“
- U zavisnosti od tipa materijalne vrednosti menja se struktura podataka i GUI.
- Prilikom popunjavanja polja kartice evidencije materijalne vrednosti vrši se provera ispravnosti unetih podataka.
Dijagram, napravljen uzimajući u obzir ove pretpostavke, prikazan je na Slici 4.
Slika 4. Preciziranje opisa funkcije „Dodati u obračun informaciju o novoj orašasti.“
O primeni drugih vrsta dijagrama UML možete pročitati ovde:
Spisak izvora.
- Sajt Sparx Systems. [Elektronski resurs] Način pristupa: Internet:
- OMG Unified Modeling Language (OMG UML) Specifikacija. Verzija 2.5.1. [Elektronski resurs] Način pristupa: Internet:
Izvor: habr.com
