»Jeden deň zo života veveričky« alebo od modelovania procesov k návrhu automatizovaného systému účtovania materiálnych hodnôt »Veverička-1.0« (časť 2)
Kratšie zhrnutie predchádzajúcej časti
V použili sme »rozprávkovú« tematickú oblasť, inšpirovaní príkladmi štúdia diagramov UML so zameraním na príbehy rozprávok (pozri napríklad, [1]). Pred začiatkom modelovania sme sa dohodli na používaní niektorých prvkov diagramu Activity a začali formulovať dohodu o modelovaní. S ohľadom na tieto dohody sme v 1. fáze opísali proces vo forme diagramov Activity a v 2. fáze sme identifikovali kroky procesu, ktoré vyžadujú (a je možné) automatizáciu.
Pripomínam, že automatizovať plánujeme činnosť súvisiacu s účtovaním materiálnych hodnôt, ktoré vznikajú v týchto procesoch.
…
Ostrov na mori leží, (E1, E2)
Mesto na ostrove stojí (E3, E1)
S zlatými vežami, (E4)
S terasami a záhradami; (E5, E6)
Jedľa rastie pred palácom, (E7, E8)
A pod ňou kryštálový dom; (E9)
Veverička tam žije ručne, (A1)
A aká je svojská! (A1)
Veverička piesne spieva, (P1, A1)
A oriešky stále hryzie, (P2)
A oriešky nie sú obyčajné, (C1)
Všetky škrupinky sú zlaté, (C2)
Jadro jasný smaragd; (C3)
Služobníci veveričku strážia, (P3, A2)
Služia jej rôznymi spôsobmi (P4)
A je priradený prísny dyakon (A3)
Prísne účtovanie orieškov je; (P5, C1)
Vydáva jej vojenskú česť; (P6, A4)
Z škrupín liajú mincu, (P7, C2, C4)
A púšťajú ju do sveta; (P8)
Dievčatá sypú smaragd (P9, A5, C3)
Do skladov, a pod hrách; (E10, E11)
…
(A.S. Puškina „Rozprávka o cári Salтанovi, o jeho slávnom a mocnom bohatierovi kniežaťovi Gvidonovi Salтанovičovi a o krásnej cárovnej Lebede“, )
V tomto príklade používam prostredie Enterprise Architect od austrálskej spoločnosti [2], a v rámci vyučovacích predmetov aplikujem [3].
Pripomínam, že procesy sú rôzne, s ktorými sa môžete oboznámiť, napríklad, [4] a [5].
Podrobnejšie o aplikovaných prístupoch k modelovaniu a návrhu pozri [6, 7].
Celú špecifikáciu UML si pozrite. [8].
Teraz sme pripravení prejsť k nasledujúcim fázam a začať navrhovanie funkcií systému a jeho vnútornej organizácie. Číslovanie obrázkov bude pokračovať.
Fáza 3. Automatizovanej úlohe je potrebné priradiť funkciu alebo funkcie systému.
Vyvíjaný automatizovaný systém (AS) je určený na presné sledovanie orechov, pamätáte? Pre každý určený krok (pozri Obrázok 3, Obrázok 4) ), ktorý budeme automatizovať, zapíšeme funkčné požiadavky, pomocou približne takejto konštrukcie "V systéme by mala byť implementovaná schopnosť ..." a vypracujeme diagram Use-case. Teraz vlastne dopĺňame našu dohodu o modelovaní novými pravidlami. Vysvetlím, aké prvky budeme používať.
Medzi "Úlohou používateľa" a "Funkciou" budeme používať spojenie "Asociácia" (Obrázok 5), čo znamená, že pre používateľa s danou úlohou je dostupné vykonanie danej funkcie.
Obrázok 5. Použitie spojenia typu "Asociácia"
Z "Funkcie" k "Požiadavke" vyvedieme spojenie "Realizácia" (Obrázok 6), aby sme ukázali, že danú požiadavku budú realizovať tieto funkcie. Vzťah môže byť aj "mnohí-k-mnohým", t.j. jedna funkcia môže byť zapojená do realizácie viacerých požiadaviek, a na realizáciu požiadavky môže byť potrebné viac ako jedna funkcia.
Obrázok 6. Použitie spojenia typu "Realizácia"
Ak jedna funkcia vyžaduje na svoje vykonanie, aby bola splnená ešte nejaká iná funkcia, pričom je to nevyhnutné, budeme používať spojenie "Závislosť" so stereotypom "Include" — zahrnutie (Obrázok 7). Ak však vykonanie ďalšej funkcie je potrebné za určitých podmienok, budeme používať spojenie "Závislosť" so stereotypom "Extend" — rozšírenie. Všetko sa dá veľmi ľahko zapamätať: "Include" — VŽDY, a "Extend" — NIKDY.
Obrázok 7. Použitie spojenia typu "Závislosť (zahrnutie)"
Nakoniec bude náš diagram vyzerať asi takto (Obrázok 8).
Obrázok 8. Diagram Use-case (funkčný model AS)
Okrem toho sa diagram Use-case používa na modelovanie úloh používateľov (Obrázok 9).
Obrázok 9. Diagram Use-case (úlohy používateľov AS)
Fáza 4. Opíšeme vnútornú organizáciu AS prostredníctvom diagramu tried.
Na základe informácií o vstupných a výstupných artefaktoch nášho procesu (pozri diagramy Activity – Obrázok 2, Obrázok 3, Obrázok 4) vypracujeme diagram tried. Budeme používať modelujúce prvky „Trieda“ a rôzne typy väzieb medzi nimi.
Aby sme ukázali vzťah „celok-časť“, použijeme väzbu typu „Agregácia“ (Obrázok 10): orech je celok a škrupiny a jadro sú časti.
Obrázok 10. Vzťah „celok-časť“
Nakoniec fragment nášho diagramu bude vyzerať približne takto (Obrázok 11). Farbou sú označené triedy, ktoré sme priamo vyčlenili v textovom opise procesu.
Obrázok 11. Diagram tried
Diagram tried bol taktiež použitý na modelovanie ďalších artefaktov – nielen tých, ktoré budú mať vzťah k konceptuálnemu modelu automatizovaného procesu evidencie hmotných hodnôt, ale aj k prostrediu vykonávania – okoliu (Obrázok 12) a „súvisiacim“ procesom (Obrázok 13), ktoré môžu ovplyvniť automatizovaný proces, ale zatiaľ nie sú v našom zornom poli (predpokladáme, že systém sa bude vyvíjať a tieto informácie sa ukážu ako užitočné).
Obrázok 12. Diagram tried (okolie)
Väzba dedičstvo ukazuje zobecnenie rôznych stavieb, „podriadené“ triedy pod zobecňujúcou „rodičovskou“ triedou „Stavba“.
Obrázok 13. Diagram tried (ďalšie informácie o artefaktoch)
„Reakcia na situáciu“ závisí od „Údajov vizuálnej kontroly“. Pre viaceré väzby závislosti sa používa stereotyp „trace“, aby ukázal trasovanie tried, ktoré nie sú výslovne uvedené v opise procesu, ale ktoré sú potrebné pre jeho automatizáciu, na triedy, na ktorých sú presne uvedené v našom opise.
Krok 5. Analyzujeme poznámky na línii „Obchodné pravidlá“
Ako pravidlá boli uvedené (pozri Obrázok 2 ):
- nutnosť rozdeliť jeden z krokov na 2 časti, druhá časť sa začne vykonávať len za určitých podmienok;
- určenie určitej osoby na vykonávanie evidencie orechov;
- technická poznámka (biela farba prvkov), ktorá naznačuje, že prvok nebol výslovne uvedený v opise procesu.
Je potrebné poznamenať, že všetky tieto pravidlá sme už použili pri vypracovaní diagramov.
Záverečné poznámky
Prešli sme 5 fázami a vytvorili 3 typy diagramov. Pridám aj krátky komentár k organizácii našich modelov v modelovacom prostredí. Existuje veľké množstvo rámcov, ktoré pomáhajú štruktúrovať vypracovávané modely, ale to nie je predmetom tohto článku, preto sa obmedzíme na nasledujúci jednoduchý súbor balíkov na usporiadané vedenie nášho projektu: Biznis proces, Funkčný model, Artefakty, Účastníci a Okolie (Obrázok 14).
Obrázok 14. Štruktúra balíkov projektu
Takto sme vyvinuli koherentné modely, ktoré opisujú systém evidencie materiálnych hodnôt z rôznych strán: model automatizovateľného biznis procesu, funkčný model a model vnútornej organizácie systému na koncepčnej úrovni.
Zoznam zdrojov
- Webstránka „UML2.ru“. Fórum Spoločenstva analytikov. Všeobecná sekcia. Príklady. Príklady rozprávok usporiadaných vo forme UML diagramov. [Elektronický zdroj] Prístup: Internet:
- Webstránka Sparx Systems. [Elektronický zdroj] Prístup: Internet:
- Webstránka Modelio. [Elektronický zdroj] Prístup: Internet:
- Veľký encyklopedický slovník. Proces (výklad). [Elektronický zdroj] Prístup: Internet:
- Webstránka „Organizácia efektívneho riadenia“. Blog. Rubrika „Riadenie biznis procesmi“. Definícia biznis procesu. [Elektronický zdroj] Prístup: Internet:
- Osvedčenie č. 18249 o registrácii a depozite diela výsledku duševnej činnosti. Alfimov R.V., Zolotukhina E.B., Krasnikov S.A. Rukopis učenia a metodického materiálu s názvom „Modelovanie predmetnej oblasti s použitím Enterprise Architect“ // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikov S.A. Modelovanie biznis procesov. — M.: KURS, NÍC INFRA-M, EBS Znanium.com. — 2017.
- OMG Unified Modeling Language (OMG UML) Špecifikácia. Verzia 2.5.1. [Elektronický zdroj] Prístup: Internet:
Zdroj: habr.com
