„Jeden deň v živote veveričky“ alebo od modelovania procesov k návrhu automatizovaného systému účtovania majetku „Belka-1.0“ (2. časť)
Zhrnutie predchádzajúcej epizódy
В Použili sme doménu „rozprávky“, inšpirovanú príkladmi učenia UML diagramov založených na rozprávkových grafoch (pozri napr. [1]). Pred začatím modelovania sme sa dohodli na použití niektorých prvkov diagramu aktivít a začali sme vytvárať modelovaciu zmluvu. Berúc do úvahy tieto dohody, v 1. etape sme opísali proces vo forme diagramov aktivít a v 2. etape sme identifikovali kroky procesu, pre ktoré je potrebná (a možná) automatizácia.
Pripomínam, že ideme automatizovať činnosť účtovania hmotného majetku, ktorá v týchto procesoch vzniká.
...
Ostrov leží na mori (E1, E2)
Na ostrove je krupobitie (E3, E1)
So zlatými kupolovými kostolmi, (E4)
S vežami a záhradami; (E5, E6)
Pred palácom rastie smrek (E7, E8)
A pod ním je krištáľový dom; (E9)
Žije tam krotká veverička (A1)
Áno, aké dobrodružstvo! (A1)
Veverička spieva piesne, (P1, A1)
Áno, stále okusuje orechy, (P2)
Ale orechy nie sú jednoduché, (C1)
Všetky škrupiny sú zlaté, (C2)
Jadrom je čistý smaragd; (C3)
Sluhovia strážia veveričku, (P3, A2)
Slúžia jej ako rôzni služobníci (P4)
A bol pridelený úradník (A3)
Prísny popis orechov je novinkou; (P5, C1)
Vojsko ju pozdravuje; (P6, A4)
Z mušlí sa sype minca (P7, C2, C4)
Nechajte ich ísť po svete; (P8)
Dievčatá nalievajú smaragd (P9, A5, C3)
Do skladov a pod krytom; (E10, E11)
...
(A.S. Puškin „Príbeh o cárovi Saltanovi, o jeho slávnom a mocnom hrdinovi princovi Guidonovi Saltanovičovi a krásnej princeznej Swanovej“, )
V tomto príklade používam rámec Enterprise Architect od austrálskej spoločnosti [2] a počas tréningov používam [3].
Pripomínam, že existujú rôzne procesy, zoznámiť sa môžete napr. [4] a [5].
Bližšie informácie o aplikovaných prístupoch k modelovaniu a dizajnu nájdete v [6, 7].
Úplnú špecifikáciu UML nájdete v časti [8].
Teraz sme pripravení prejsť na ďalšie kroky a začať navrhovať funkčnosť a vnútornú organizáciu systému. Číslovanie výkresov bude pokračovať.
Fáza 3. Automatizovaný krok musí byť spojený s funkciou alebo funkciami systému
Vyvíjaný automatizovaný systém (AS) je navrhnutý tak, aby udržiaval prísne záznamy o orechoch, pamätáte? Pre každý zvýraznený krok (pozri obrázok 3, obrázok 4 ), ktorú zautomatizujeme, zapíšeme funkčnú požiadavku pomocou približne nasledujúcej konštrukcie: „Systém musí implementovať schopnosť...“ a vytvoríme schému použitia. Teraz do našej modelovej zmluvy pridávame nové pravidlá. Dovoľte mi vysvetliť, aké prvky použijeme.
Použijeme spojenie „Asociácia“ medzi „Rola používateľa“ a „Funkcia“ (obrázok 5), čo znamená, že túto funkciu môže vykonávať používateľ s touto rolou.
Obrázok 5. Použitie vzťahu typu asociácie
Od „Funkcie“ po „Požiadavka“ nakreslíme spojenie „Implementácia“ (obrázok 6), aby sme ukázali, že táto požiadavka bude implementovaná týmito funkciami; vzťah môže byť „many-to-many“, t.j. Jedna funkcia môže byť zahrnutá do implementácie niekoľkých požiadaviek a na implementáciu požiadavky môže byť potrebných viac ako jedna funkcia.
Obrázok 6. Použitie vzťahu typu „Implementácia“.
Ak jedna funkcia vyžaduje na svoje vykonanie, aby bola vykonaná nejaká iná funkcia a nevyhnutne, použijeme spojenie „Závislosť“ so stereotypom „Zahrnúť“ (obrázok 7). Ak sa za určitých podmienok vyžaduje vykonanie ďalšej funkcie, potom použijeme spojenie „Závislosť“ so stereotypom „Rozšíriť“. Všetko je veľmi ľahko zapamätateľné: „Zahrnúť“ je VŽDY a „Rozšíriť“ je NIEKEDY.
Obrázok 7. Použitie vzťahu „Závislosť (zahrnutie)“.
V dôsledku toho bude náš diagram vyzerať asi takto (obrázok 8).
Obrázok 8. Schéma použitia (funkčný model AC)
Okrem toho sa na modelovanie rolí používateľov používa diagram prípadu použitia (obrázok 9).
Obrázok 9. Diagram prípadov použitia (role používateľov AS)
Fáza 4. Opíšme vnútornú organizáciu AS pomocou diagramu tried
Pomocou informácií o vstupných a výstupných artefaktoch nášho procesu (pozri Diagramy aktivít - Obrázok 2, Obrázok 3, Obrázok 4) vytvoríme diagram tried. Využijeme modelovacie prvky „Class“ a rôzne typy spojení medzi nimi.
Na znázornenie vzťahu „celá časť“ použijeme vzťah typu „Agregácia“ (obrázok 10): orech je celok a škrupina a jadro sú časti.
Obrázok 10. Vzťah celej časti
V dôsledku toho bude fragment nášho diagramu vyzerať asi takto (obrázok 11). Farebne sú označené triedy, ktoré sme zvýraznili priamo v textovom popise procesu.
Obrázok 11. Diagram tried
Diagram tried bol použitý aj na modelovanie ďalších artefaktov – nielen tých, ktoré budú súvisieť s koncepčným modelom automatizovaného procesu účtovania hmotného majetku, ale aj s prostredím realizácie – prostredím (obrázok 12) a „susedným“ procesy (obrázok 13), ktoré môžu ovplyvniť automatizovaný proces, ale zatiaľ nie sú v centre našej pozornosti (predpokladáme, že systém sa bude vyvíjať a tieto informácie budú užitočné).
Obrázok 12. Diagram tried (prostredie)
Vzťah dedenia ukazuje zovšeobecnenie rôznych budov, tried „dieťa“ v rámci zovšeobecňujúcej „rodičovskej“ triedy „Budova“.
Obrázok 13. Diagram tried (dodatočné informácie o artefaktoch)
„Reakcia na situáciu“ závisí od „údajov vizuálnej kontroly“. Pre niekoľko vzťahov závislostí sa stereotyp "sledovania" používa na zobrazenie sledovania tried, ktoré nie sú explicitne identifikované v popise procesu, ale ktoré sú potrebné na jeho automatizáciu, k triedam, ktorých inštancie sú v našom popise výslovne uvedené.
Fáza 5. Analyzujme poznámky k skladbe „Obchodné pravidlá“.
Boli špecifikované pravidlá (pozri obrázok 2 ):
- potreba rozdeliť jeden z krokov na 2 časti, druhá časť sa začína vykonávať iba za určitých podmienok;
- vymenovanie určitého úradníka, ktorý bude vykonávať účtovníctvo orechov;
- technika (biela farba prvkov), ktorá naznačuje, že prvok nebol explicitne špecifikovaný v popise procesu.
Treba poznamenať, že všetky tieto pravidlá sme už použili pri vývoji diagramov.
Záverečné poznámky
Prešli sme teda 5 fázami a vytvorili sme 3 typy diagramov. Pridám malý komentár o organizácii našich modelov v modelingovom prostredí. Existuje veľké množstvo rámcov, ktoré pomáhajú štruktúrovať vyvíjané modely, ale to nie je predmetom tohto článku, preto sa obmedzíme na nasledujúcu jednoduchú sadu balíkov pre riadne riadenie nášho projektu: Business Process, Functional Model , Artefakty, účastníci a prostredie (obrázok 14).
Obrázok 14. Štruktúra projektového balíka
Vyvinuli sme teda konzistentné modely, ktoré popisujú materiálový účtovný systém z rôznych aspektov: model automatizovaného podnikového procesu, funkčný model a model vnútornej organizácie systému na koncepčnej úrovni.
Zoznam zdrojov
- Webová stránka "UML2.ru". Fórum komunity analytikov. Všeobecná sekcia. Príklady. Príklady rozprávok formátovaných ako UML diagramy. [Elektronický zdroj] Režim prístupu: Internet:
- Webová stránka Sparx Systems. [Elektronický zdroj] Režim prístupu: Internet:
- Webová stránka Modelio. [Elektronický zdroj] Režim prístupu: Internet:
- Veľký encyklopedický slovník. Proces (interpretácia). [Elektronický zdroj] Režim prístupu: Internet:
- Webová stránka „Organizácia efektívneho riadenia“. Blog. Kategória „Riadenie obchodných procesov“. Definícia obchodného procesu. [Elektronický zdroj] Režim prístupu: Internet:
- Osvedčenie č. 18249 o evidencii a uložení diela duševnej činnosti. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Rukopis učebnej pomôcky s názvom „Modelovanie predmetu pomocou Enterprise Architect“ // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modelovanie obchodných procesov. — M.: KURZ, SIC INFRA-M, EBS Znanium.com. — 2017.
- Špecifikácia jednotného modelovacieho jazyka OMG (OMG UML). Verzia 2.5.1. [Elektronický zdroj] Režim prístupu: Internet:
Zdroj: hab.com