"En dan v življenju veverice" ali od modeliranja procesov do oblikovanja avtomatiziranega sistema za računovodstvo materialnih sredstev "Belka-1.0" (1. del)
Kaj ima "veverica" s tem?
Takoj bom pojasnil, kaj ima "veverica" s tem. Ko ste na internetu naleteli na zabavne projekte za učenje UML, ki temeljijo na predmetnem področju, izposojenem iz pravljic (npr. [1]), sem se tudi odločil, da pripravim podoben primer za svoje študente, da bodo lahko za začetek preučevali samo tri vrste diagramov: Diagram dejavnosti, Diagram primera uporabe in Diagram razreda. Namenoma ne prevajam imen diagramov v ruščino, da bi se izognili sporom o "težavah s prevodom". Za kaj gre, bom razložil malo kasneje. V tem primeru uporabljam ogrodje Enterprise Architect avstralskega podjetja [2] – dobro orodje za razumno ceno. In kot del svojih treningov uporabljam [3], dobro brezplačno objektno orientirano oblikovalsko orodje, ki podpira standarda UML2.0 in BPMN, brez nepotrebnih naklepov glede vizualnih zmožnosti, a povsem zadostno za učenje osnov jezika.
Avtomatizirali bomo dejavnost knjigovodstva materialnih sredstev, ki nastaja pri 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 junaku princu Gvidonu Saltanoviču in prelepi princesi Labod", — Mimogrede, 10 let od koncepta do objave!)
Malo o kodah, ki so napisane desno od vrstic. "A" (iz "Actor") pomeni, da vrstica vsebuje podatke o udeležencu v procesu. “C” (iz “Razred”) – informacije o objektih razreda, ki se obdelujejo med izvajanjem procesov. "E" (iz "okolja") - informacije o objektih razreda, ki označujejo okolje za izvajanje procesov. "P" (iz "proces") - informacije o samih procesih.
Mimogrede, natančna definicija procesa trdi, da je tudi vzrok metodoloških sporov, čeprav le zaradi dejstva, da obstajajo različni procesi: poslovni, proizvodni, tehnološki itd. in tako naprej. (lahko ugotovite npr. [4] in [5]). Da se izognemo polemiki, se strinjajmo s tem Proces nas zanima z vidika njegove ponovljivosti skozi čas in potrebe po avtomatizaciji, tj. prenos izvajanja kateregakoli dela procesnih operacij v avtomatiziran sistem.
Opombe o uporabi diagrama dejavnosti
Začnimo modelirati naš proces in za to uporabimo diagram dejavnosti. Najprej naj pojasnim, kako bodo zgornje kode uporabljene v modelu. Lažje je razložiti z grafičnim primerom, hkrati pa bomo analizirali nekatere (skoraj vse tiste, ki jih potrebujemo) elemente diagrama dejavnosti.
Analizirajmo naslednji fragment:
...
Veverica poje pesmice, (P1, A1)
Da, grizlja vse orehe, (P2)
In orehi niso preprosti, (C1)
Vse školjke so zlate, (C2)
Jedrca čisti smaragd; (C3)
...
Imamo dva procesna koraka P1 in P2, udeleženca A1 in objekte treh različnih razredov: objekt razreda C1 je vhod v korak, objekti razredov C2 in C3 so izhodni kot rezultat aktivnosti tega koraka P2 našega postopek. Za diagram uporabimo naslednje elemente modeliranja.
Delček našega procesa lahko predstavimo nekako takole (slika 1).
Slika 1. Fragment diagrama dejavnosti
Za organizacijo prostora in strukturiranje diagrama dejavnosti bomo uporabili nestandarden pristop, z vidika klasične uporabe zapisa UML. A razlogov za to je več. Prvič, tik pred začetkom modeliranja bomo sestavili t.i dogovor o modeliranju, v kateri zabeležimo vse značilnosti uporabe notnega zapisa. Drugič, ta pristop je bil večkrat uspešno uporabljen na stopnji poslovnega modeliranja v resničnih projektih za ustvarjanje sistemov programske opreme; rezultate je zabeležila naša majhna skupina avtorjev v ustreznem objektu avtorskih pravic [6] in so bili uporabljeni tudi v priročniku za usposabljanje [ 7]. Za diagram dejavnosti definiramo, da je polje diagrama strukturirano z uporabo "plavalnih stez". Ime sledi bo ustrezalo vrsti elementov grafikona, ki bodo postavljeni na to stezo.
"Vhodni in izhodni artefakti": Ta sled bo vsebovala elemente Objects - objekte, ki se uporabljajo ali so rezultat izvajanja nekega koraka procesa.
"Koraki procesa": Tukaj bomo postavili elemente aktivnosti - dejanja udeležencev procesa.
"Udeleženci": pot za elemente, ki bodo označevali vloge izvajalcev dejanj v našem procesu; zanje bomo uporabili isti modelirni element Object - objekt, le da mu bomo dodali stereotip "Igralec".
Pokliče se naslednja skladba "Poslovna pravila" in na to progo bomo v besedilni obliki postavili pravila za izvajanje korakov procesa, za to pa bomo uporabili modelirni element Note - opomba.
Tu se bomo ustavili, čeprav bi lahko uporabili tudi pot "Orodja" za zbiranje informacij o stopnji avtomatizacije procesov. Morda pride prav tudi pot "Položaji in delitve udeležencev", se lahko uporablja za povezovanje vlog s položaji in oddelki udeležencev procesa.
Vse, kar sem pravkar opisal, je delček konvencije modeliranja, se ta del sporazuma nanaša na pravila za organizacijo enega diagrama in s tem na pravila za njegovo pisanje in branje.
"Recept"
Zdaj pa razmislimo o možnosti modeliranja sistema posebej iz diagrama dejavnosti. To je samo ena od možnosti, ugotavljam, da seveda ni edina. Diagram dejavnosti nas bo zanimal z vidika njegove vloge pri prehodu od modeliranja procesa k oblikovanju avtomatiziranega sistema. Da bi to naredili, se bomo držali metodoloških priporočil - nekakšnega recepta, ki je sestavljen iz samo petih stopenj in predvideva razvoj samo treh vrst diagramov. Uporaba tega recepta nam bo pomagala pridobiti formaliziran opis procesa, ki ga želimo avtomatizirati, in zbrati podatke za načrtovanje sistema. In za študente na začetku študija UML je to nekakšna rešilna palica, ki jim ne bo dovolila, da se utopijo v vsej raznolikosti vizualnih sredstev in tehnik, ki jih najdemo v UML in sodobnih orodjih za modeliranje.
Tukaj je pravzaprav sam recept, nato pa sledite diagramom, izdelanim za naše "pravljično" predmetno področje.
Faza 1. Proces opišemo v obliki diagrama dejavnosti. Za proces z več kot 10 koraki je smiselno uporabiti načelo dekompozicije korakov procesa za izboljšanje berljivosti diagrama.
Faza 2. Izberite, kaj je mogoče avtomatizirati (korake lahko na primer označite na diagramu).
Faza 3. Avtomatiziranemu koraku je treba dodeliti funkcijo ali funkcije sistema (razmerje je lahko veliko proti mnogo), narišite diagram primerov uporabe. To so funkcije našega sistema.
Faza 4. Opišemo notranjo organizacijo AS s pomočjo diagrama razredov - Razred. Plavališče »Vhodni in izhodni objekti (dokumenti)« v diagramu dejavnosti je osnova za izgradnjo objektnega modela in modela entiteta-relacija.
Faza 5. Analizirajmo opombe na skladbi "Poslovna pravila"., zagotavljajo različne vrste omejitev in pogojev, ki se postopoma spreminjajo v nefunkcionalne zahteve.
Nastala množica diagramov (Dejavnost, Primer uporabe, Razred) nam daje formaliziran opis v dokaj strogem zapisu, tj. ima nedvoumno branje. Zdaj lahko razvijete tehnične specifikacije, pojasnite specifikacije zahtev itd.
Začnimo z modeliranjem.
Faza 1. Opišite proces v obliki diagrama dejavnosti
Naj vas spomnim, da smo polje diagrama strukturirali z uporabo "plavalnih" stez; vsaka steza vsebuje elemente iste vrste (slika 2). Poleg zgoraj opisanih elementov diagrama bomo uporabili dodatne elemente, jih opišemo.
Odločitev (Decision) označuje točko razvejanja našega procesa v diagramu, združevanje niti (Merge) pa točko njihove ponovne združitve. Prehodni pogoji so na prehodih zapisani v oglatih oklepajih.
Med dvema sinhronizatorjema (Fork) bomo prikazali vzporedne procesne veje.
Naš proces ima lahko samo en začetek - eno vstopno točko (Začetno). Lahko pa je več dokončanj (končno), vendar ne za naš specifični diagram.
Puščic je precej, z velikim številom elementov in povezav lahko najprej določite stopnje procesa in nato izvedete dekompozicijo teh stopenj. Toda zaradi jasnosti bi rad naš "pravljični" proces v celoti prikazal na enem diagramu, seveda pa moramo zagotoviti, da se puščice "ne držijo skupaj", da bi bilo mogoče natančno slediti, kaj je povezano na kaj.
Slika 2. Diagram aktivnosti - splošni pogled na proces
Ker v pesniških vrsticah so nekatere podrobnosti postopka izpuščene, treba jih je bilo obnoviti, prikazane so z elementi z belim ozadjem. Te podrobnosti vključujejo korak prenosa/sprejemanja za shranjevanje in obdelavo ter več vhodnih in izhodnih artefaktov. Omeniti velja, da tudi ta korak ne razkrije v celoti procesa, ker ločeno bi morali določiti korak oddaje in korak sprejema ter celo dodati ločen korak za granate in tudi pomisliti, da je treba najprej vse te materialne vrednosti nekje začasno shraniti itd. in tako naprej.
Naj še opozorimo, da vprašanje izvora orehov ostaja neodgovorjeno – od kod prihajajo in kako pridejo do veverice? In to vprašanje (v opombi je označeno z rdečo pisavo - element Opomba) zahteva ločeno študijo! Tako deluje analitik - zbira informacije po koščkih, postavlja predpostavke in prejema "v redu" ali "ne v redu" od strokovnjakov za področje - zelo pomembnih in preprosto nenadomestljivih ljudi na stopnji poslovnega modeliranja pri ustvarjanju sistemov.
Upoštevajte tudi, da je procesni korak P5 sestavljen iz dveh delov.
In vsak del bomo razčlenili in podrobneje razmislili (slika 3, slika 4), ker dejavnosti, izvedene znotraj teh posebnih korakov, bodo avtomatizirane.
Slika 3. Diagram dejavnosti - podrobnosti (1. del)
Slika 4. Diagram dejavnosti - podrobnosti (2. del)
Faza 2. Izberite, kaj je mogoče avtomatizirati
Koraki, ki jih je treba avtomatizirati, so na diagramih označeni z barvo (glejte sliko 3, sliko 4).
Vse izvaja en udeleženec v procesu - referent:
- V izpisek vnese podatke o masi oreha;
- V izpisek vnese podatke o prenosu matice;
- Zapisuje dejstvo preoblikovanja oreha v lupino in jedro;
- V izjavo vnese informacije o jedru oreha;
- Na seznam vnese podatke o orehovih lupinah.
Analiza opravljenega dela. Kaj je naslednje?
Opravili smo torej veliko pripravljalnega dela: zbrali smo informacije o procesu, ki ga bomo avtomatizirali; začeli oblikovati dogovor o modeliranju (zaenkrat le v smislu uporabe diagrama dejavnosti); izvedel simulacijo procesa in celo razčlenil več njegovih korakov; Identificirali smo korake procesa, ki jih bomo avtomatizirali. Zdaj smo pripravljeni, da nadaljujemo z naslednjimi koraki in začnemo načrtovati funkcionalnost in notranjo organizacijo sistema.
Kot veste, teorija brez prakse ni nič. Vsekakor morate poskusiti "modeliranje" z lastnimi rokami, to je koristno tudi za razumevanje predlaganega pristopa. Na primer, lahko delate v okolju modeliranja [3]. Razčlenili smo le del korakov celotnega diagrama procesa (glej sliko 2). Kot praktično nalogo boste morda morali ponoviti vse diagrame v okolju Modelio in izvesti dekompozicijo koraka »Prenos/sprejem za shranjevanje in obdelavo«.
Še ne razmišljamo o delu v posebnih okoljih za modeliranje, vendar bo to lahko postalo predmet neodvisnih člankov in recenzij.
V drugem delu članka bomo analizirali tehnike modeliranja in oblikovanja, ki so potrebne na stopnjah 3-5; uporabili bomo diagrame primerov uporabe in razredov UML. Se nadaljuje.
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.
Vir: www.habr.com