„Jeden den v životě veverky“ nebo od modelování procesů k návrhu automatizovaného systému evidence materiálních hodnot „Veverka-1.0“ (část 2)
Krátké shrnutí předchozího dílu
V Učili jsme se na „pohádkové“ tematice, inspirováni příklady studia diagramů UML založených na ději pohádek (viz například, [1]). Před začátkem modelování jsme se dohodli na používání některých prvků diagramu Activity a začali formulovat dohodu o modelování. S ohledem na tyto dohody jsme v 1. fázi popsali proces ve formě diagramů Activity a ve 2. fázi jsme vyčlenili kroky procesu, pro které je (a je možné) provádění automatizace.
Připomínám, že hodláme automatizovat činnost v oblasti evidence materiálních hodnot, která vzniká v těchto procesech.
…
Ostrov leží na moři, (E1, E2)
Město stojí na ostrově (E3, E1)
Se zlatými kostely, (E4)
S terasami a zahradami; (E5, E6)
Jedle roste před palácem, (E7, E8)
A pod ní křišťálový dům; (E9)
Tam žije domácí veverka, (A1)
A je to nějaká čertice! (A1)
Veverka zpívá písničky, (P1, A1)
A stále křupe ořechy, (P2)
A ořechy nejsou obyčejné, (C1)
Všechny skořápky jsou zlaté, (C2)
Jádra jsou čistý smaragd; (C3)
Služebníci hlídají veverku, (P3, A2)
Slouží jí rozmanitou službou (P4)
A je přidělený přísný notář (A3)
Pečlivě sledují ořechy; (P5, C1)
Vojsku jí vzdávají čest; (P6, A4)
Z skořápek odlévají mince, (P7, C2, C4)
A pouští je do světa; (P8)
Dívky sypou smaragd (P9, A5, C3)
Do spíží, a pod spušť; (E10, E11)
…
(A.S. Puškina „Pohádka o caru Saltanovi, o jeho slavném a mocném bohatýru knížeti Gvidonovi Saltanovičovi a o krásné carské dceři Labutě“, )
V tomto příkladu používám prostředí Enterprise Architect od australské společnosti [2], a v rámci výuky používám [3].
Připomínám, že procesy mohou být různé, můžete se seznámit například, [4] a [5].
Podrobnosti o používaných přístupech k modelování a návrhu naleznete v [6, 7].
Úplnou specifikaci UML najdete [8].
Nyní jsme připraveni přejít k dalším fázím a začít navrhovat funkce systému a jeho vnitřní organizaci. Číslování obrázků bude pokračováno.
Fáze 3. Automatizovanému kroku je třeba přiřadit jednu nebo více funkcí systému.
Vyvíjený automatizovaný systém (AS) je určen k přísné evidenci ořechů, pamatujte? Pro každý vyčleněný krok (viz Obrázek 3, Obrázek 4 ), který budeme automatizovat, vypracujeme funkční požadavek s přibližně takovou konstrukcí „V systému by měla být realizována možnost ...“ a vypracujeme diagram Use-case. Nyní v podstatě doplňujeme naši dohodu o modelování novými pravidly. Vysvětlím, které prvky budeme používat.
Mezi „Rolí uživatele“ a „Funkcí“ budeme používat vazbu „Asociace“ (Obrázek 5), což znamená, že pro uživatele s touto rolí je dostupné provádění této funkce.
Obrázek 5. Použití asociace
Z "Funkce" k "Požadavku" provedeme vazbu "Realizace" (Obrázek 6), abychom ukázali, že tento požadavek bude realizován těmito funkcemi; vztah může být také "mnoho-k-mnohým", tj. jedna funkce může být součástí realizace několika požadavků, a pro realizaci požadavku může být zapotřebí více než jedna funkce.
Obrázek 6. Použití vazby typu "Realizace"
Pokud jedna funkce vyžaduje, aby byla splněna další funkce, a to nutně, použijeme vazbu "Závislost" se stereotypem "Include" — zahrnutí (Obrázek 7). Pokud je ale provedení dodatečné funkce požadováno za určitých podmínek, použijeme vazbu "Závislost" se stereotypem "Extend" — rozšíření. Je to snadné zapamatovat: "Include" — VŽDY, a "Extend" – NĚKDY.
Obrázek 7. Použití vazby typu "Závislost (zahrnutí)"
Naše diagram bude vypadat přibližně takto (Obrázek 8).
Obrázek 8. Diagram Use-case (funkční model AS)
Kromě toho se diagram Use-case používá k modelování rolí uživatelů (Obrázek 9).
Obrázek 9. Diagram Use-case (role uživatelů AS)
Fáze 4. Popíšeme vnitřní organizaci AС pomocí diagramu tříd.
Použitím informací o vstupních a výstupních artefaktech našeho procesu (viz diagramy Activity — Obrázek 2, Obrázek 3, Obrázek 4) vypracujeme diagram tříd. Budeme používat modelovací prvek "Třída" a různé typy vazeb mezi nimi.
Abychom ukázali vztah "cele-k-části", použijeme vazbu typu "Agregace" (Obrázek 10): ořech je celek a skořápky a jádro jsou části.
Obrázek 10. Vztah "cele-k-části"
Nakonec bude segment našeho diagramu vypadat přibližně takto (Obrázek 11). Barvou jsou označeny třídy, které jsme vyčlenili přímo v textovém popisu procesu.
Obrázek 11. Diagram tříd
Třída diagramu byla použita také k modelování dalších artefaktů – nejen těch, které se týkají konceptuálního modelu automatizovaného procesu evidence materiálních hodnot, ale také prostředí provádění – prostředí (Obrázek 12) a "sousedních" procesů (Obrázek 13), které mohou mít vliv na automatizovaný proces, ale zatím nejsou v našem zaměření (předpokládáme, že systém se bude rozvíjet a tyto informace se ukážou jako užitečné).
Obrázek 12. Třída diagramu (prostředí)
Vztah dědictví ukazuje generalizaci různých staveb, "potomky" tříd pod generalizovanou "rodičovskou" třídou "Stavba".
Obrázek 13. Třída diagramu (další informace o artefaktech)
"Reakce na situaci" závisí na "Údajích vizuální kontroly". Pro několik závislostních vazeb se používá stereotyp "trace", aby se ukázal sled tříd, které nejsou explicitně označeny v popisu procesu, ale které jsou nezbytné pro jeho automatizaci, k třídám, na které existuje přesné určení v našem popisu.
Fáze 5. Analyzujeme poznámky na pruhu „Obchodní pravidla“.
Jako pravidla byla uvedena (viz Obrázek 2 ):
- potřeba rozdělit jeden z kroků na 2 části, druhá část začne být vykonávána pouze za určitých podmínek;
- určení pro vedení evidence ořešáků konkrétní osobou pověřenou tímto úkolem;
- technický příznak (bílá barva prvků), který naznačuje, že prvek nebyl explicitně uveden v popisu procesu.
Je třeba poznamenat, že všechna tato pravidla jsme již použili při vývoji diagramů.
Závěrečné poznámky
Takže jsme prošli 5 fázemi a vytvořili 3 typy diagramů. Přidám ještě malý komentář k organizaci našich modelů v modelovacím prostředí. Existuje velké množství rámců, které pomáhají strukturovat vyvíjené modely, ale to není předmětem tohoto článku, a tak se omezíme na následující jednoduchou sadu balíčků pro systematické vedení našeho projektu: Business Process, Functional Model, Artefacts, Participants a Environment (Obrázek 14).
Obrázek 14. Struktura balíčků projektu
Tak jsme vyvinuli harmonizované modely, které popisují systém správy hmotných hodnot z různých úhlů pohledu: model automatizovatelného obchodního procesu, funkční model a model vnitřní organizace systému na konceptuální úrovni.
Seznam zdrojů
- Web „UML2.ru“. Fórum Společenství analytiků. Obecná sekce. Příklady. Příklady pohádek prezentovaných ve formě UML diagramů. [Elektronický zdroj] Přístup: Internet:
- Webové stránky Sparx Systems. [Elektronický zdroj] Přístupový režim: Internet:
- Web Modelio. [Elektronický zdroj] Přístup: Internet:
- Velká encyklopedie. Proces (výklad). [Elektronický zdroj] Přístup přes: Internet:
- Web „Organizace efektivního řízení“. Blog. Rubrika „Řízení podnikových procesů“. Definice podnikového procesu. [Elektronický zdroj] Přístup přes: Internet:
- Osvědčení č. 18249 o registraci a uložením díla výsledku duševní činnosti. Alfimov R.V., Zolotuchina E.B., Krasnikov S.A. Rukopis vzdělávacího a metodického materiálu s názvem „Modelování předmětné oblasti s využitím Enterprise Architect“ // 2011.
- Zolotuchina E.B., Višňová A.S., Krasnikov S.A. Modelování podnikových procesů. — M.: KURS, NÍC INFRA-M, EBS Znanium.com. — 2017.
- OMG Unified Modeling Language (OMG UML) specifikace. Verze 2.5.1. [Elektronický zdroj] Přístupový režim: Internet:
Zdroj: habr.com
