"En dan v življenju veverice" ali od modeliranja procesov do oblikovanja avtomatiziranega sistema za računovodstvo materialnih sredstev "Belka-1.0" (2. del)
Povzetek prejšnje serije
В uporabili smo "pravljično" predmetno področje, ki ga navdihujejo primeri preučevanja diagramov UML na podlagi pravljičnih zapletov (glej npr. [1]). Pred modeliranjem smo se dogovorili za uporabo nekaterih elementov diagrama dejavnosti in začeli oblikovati dogovor o modeliranju. Ob upoštevanju teh dogovorov smo na 1. stopnji proces opisali v obliki diagramov aktivnosti, na 2. stopnji pa smo identificirali korake procesa, za katere je potrebna (in možna) avtomatizacija.
Naj vas spomnim, da bomo avtomatizirali dejavnost obračunavanja materialnih vrednosti, ki nastaja v teh procesih.
...
Otok v morju leži, (E1, E2)
Toča na otoku stoji (E3, E1)
S cerkvami z zlatimi kupolami, (E4)
S stolpi in vrtovi; (E5, E6)
Pred dvorom raste smreka, (E7, E8)
In pod njim je kristalna hiša; (E9)
Veverica živi tam, krotka, (A1)
Ja, kakšen zabavljač! (A1)
Veverica poje pesmice, (P1, A1)
Da, grizlja vse orehe, (P2)
In orehi niso preprosti, (C1)
Vse školjke so zlate, (C2)
Jedrca čisti smaragd; (C3)
Hlapci varujejo veverico, (P3, A2)
Služite ji kot služabniki različnih vrst (P4)
In uradnik je bil dodeljen (A3)
Strogo upoštevanje novic o oreščkih; (P5, C1)
Daje svojo čast vojski; (P6, A4)
Iz školjk se izlije kovanec (P7, C2, C4)
Naj lebdijo po svetu; (P8)
Dekleta mečejo smaragd (P9, A5, C3)
V shrambah, a pod bušoto; (E10, E11)
...
(A. S. Puškin "Zgodba o carju Saltanu, njegovem slavnem in mogočnem sinu princu Gvidonu Saltanoviču in prelepi princesi labodi", )
V tem primeru uporabljam okolje Enterprise Architect avstralskega podjetja. [2], in v okviru treningov, ki jih uporabljam [3].
Naj vas spomnim, da so procesi različni, lahko se seznanite npr. [4] in [5].
Za podrobnosti o uporabljenih pristopih k modeliranju in oblikovanju glejte [6, 7].
Za celotno specifikacijo UML glejte [8].
Zdaj smo pripravljeni, da nadaljujemo z naslednjimi koraki in začnemo načrtovati funkcije sistema in njegovo notranjo organizacijo. Številčenje slik se bo nadaljevalo.
Faza 3. Avtomatiziranemu koraku je treba dodeliti funkcijo ali funkcije sistema
Avtomatizirani sistem (AS), ki se razvija, je zasnovan tako, da vodi strogo evidenco orehov, se spomnite? Za vsak označen korak (glejte sliko 3, sliko 4 ), ki ga bomo avtomatizirali, zapisali funkcionalno zahtevo z uporabo nekaj takega, kot je "Sistem mora biti sposoben ..." in razvili diagram primera uporabe. Zdaj dejansko dopolnjujemo naš sporazum o modeliranju z novimi pravili. Naj pojasnim, katere elemente bomo uporabili.
Med »uporabniško vlogo« in »funkcijo« bomo uporabili razmerje »povezava« (slika 5), kar pomeni, da lahko uporabnik s to vlogo opravlja to funkcijo.
Slika 5. Uporaba razmerja asociacijskega tipa
Od »Funkcije« do »Zahteve« bomo narisali povezavo »Implementacija« (slika 6), da pokažemo, da bodo to zahtevo izvajale te funkcije, razmerje pa je lahko »mnogo proti mnogo«, tj. ena funkcija je lahko vključena v izvajanje več zahtev in za izvajanje zahteve bo morda potrebna več kot ena funkcija.
Slika 6. Uporaba razmerja Implementacija
Če ena funkcija zahteva za svojo izvedbo še kakšno drugo funkcijo in je potrebna, bomo uporabili povezavo »Odvisnost« s stereotipom »Vključi« - vključitev (slika 7). Če je pod določenimi pogoji potrebna izvedba dodatne funkcije, bomo uporabili povezavo "Odvisnost" s stereotipom "Razširitev" - razširitev. Vse je zelo enostavno zapomniti: "Vključi" - VEDNO in "Razširi" - VČASIH.
Slika 7. Uporaba vrste povezave "Odvisnost (vključi)"
Posledično bo naš diagram izgledal nekako takole (slika 8).
Slika 8. Diagram primera uporabe (funkcionalni model AS)
Poleg tega se za modeliranje uporabniških vlog uporablja diagram primerov uporabe (slika 9).
Slika 9. Diagram primerov uporabe (vloge uporabnikov AS)
Faza 4. Opišemo notranjo organizacijo AS s pomočjo diagrama razredov
Z uporabo informacij o vhodnih in izhodnih artefaktih našega procesa (glejte diagrame dejavnosti - slika 2, slika 3, slika 4) bomo razvili diagram razredov. Uporabili bomo elemente modeliranja »Razred« in različne vrste odnosov med njimi.
Za prikaz razmerja »celo-del« bomo uporabili razmerje tipa »Združevanje« (slika 10): oreh je celota, lupine in jedro pa deli.
Slika 10. Razmerje celota-del
Posledično bo delček našega diagrama videti nekako takole (slika 11). Razredi so označeni z barvo, ki smo jo označili neposredno v besedilnem opisu procesa.
Slika 11. Diagram razredov
Diagram razredov je bil uporabljen tudi za modeliranje drugih artefaktov – ne samo tistih, ki bodo relevantni za konceptualni model procesa avtomatiziranega inventarja, temveč povezanih z okoljem izvajanja – okoljem (slika 12) in »sosednjimi« procesi (slika 13) ki lahko vplivajo na avtomatiziran proces, vendar še niso v središču naše pozornosti (predvidevamo, da se bo sistem razvijal in bodo te informacije koristne).
Slika 12. Diagram razredov (okolje)
Razmerje dedovanja kaže posploševanje različnih zgradb, "podrejenih" razredov, pod posplošljivim "nadrejenim" razredom "Zgradba".
Slika 13. Diagram razredov (več informacij o artefaktih)
"Reakcija na situacijo" je odvisna od "Podatkov vizualnega nadzora". Za več odnosov odvisnosti se stereotip »sledi« uporablja za prikaz sledenja razredov, ki niso izrecno navedeni v opisu procesa, vendar so potrebni za njegovo avtomatizacijo, do razredov, katerih instance so natančno navedene v našem opisu.
Faza 5. Analizirajmo opombe na skladbi "Poslovna pravila".
Kot so bila določena pravila (glej sliko 2 ):
- potrebo po razdelitvi enega od korakov na 2 dela, drugi del se začne izvajati le pod določenimi pogoji;
- imenovanje določene uradne osebe za vodenje računovodstva orehov;
- tehnika (bela barva elementov), ki pomeni, da element ni bil izrecno naveden v opisu procesa.
Opozoriti je treba, da smo vsa ta pravila že uporabili pri razvoju diagramov.
Končne pripombe
Torej smo šli skozi 5 stopenj in zgradili 3 vrste diagramov. Dodal bom še eno pripombo o organizaciji naših modelov v modelnem okolju. Obstaja veliko število ogrodij, ki pomagajo strukturirati modele, ki jih razvijamo, vendar to ni tema tega članka, zato se bomo omejili na naslednji preprost nabor paketov za urejeno vzdrževanje našega projekta: poslovni proces, funkcionalni model, Artefakti, udeleženci in okolje (slika 14).
Slika 14. Struktura projektnih paketov
Tako smo razvili konsistentne modele, ki opisujejo sistem obračunavanja materialnih sredstev z različnih zornih kotov: model avtomatiziranega poslovnega procesa, funkcionalni model in model notranje organizacije sistema na konceptualni ravni.
Seznam virov
- Spletno mesto "UML2.ru". Forum skupnosti analitikov. Splošni del. Primeri. Primeri pravljic v obliki UML diagramov. [Elektronski vir] Način dostopa: Internet:
- Spletno mesto Sparx Systems. [Elektronski vir] Način dostopa: Internet:
- Spletno mesto Modelio. [Elektronski vir] Način dostopa: Internet:
- Veliki enciklopedični slovar. Proces (interpretacija). [Elektronski vir] Način dostopa: Internet:
- Spletna stran "Organizacija učinkovitega upravljanja". Blog. Rubrika "Upravljanje poslovnih procesov". Opredelitev poslovnega procesa. [Elektronski vir] Način dostopa: Internet:
- Potrdilo št. 18249 o registraciji in deponiranju proizvoda rezultata intelektualne dejavnosti. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Rokopis učnega pripomočka z naslovom "Modeliranje predmetnega področja s programom Enterprise Architect" // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modeliranje poslovnih procesov. - M .: KURS, NITs INFRA-M, EBS Znanium.com. — 2017.
- Specifikacija OMG Unified Modeling Language (OMG UML). Različica 2.5.1. [Elektronski vir] Način dostopa: Internet:
Vir: www.habr.com