„Jeden den v životě veverky“ aneb od modelování procesů k návrhu automatizovaného systému účtování majetku „Belka-1.0“ (část 2)
Shrnutí předchozí epizody
В Použili jsme doménu „pohádky“, inspirovanou příklady učení UML diagramů založených na pohádkových zápletkách (viz např. [1]). Před zahájením modelování jsme se dohodli na použití některých prvků Diagramu aktivit a začali jsme vytvářet modelovací smlouvu. S přihlédnutím k těmto dohodám jsme v 1. fázi popsali proces ve formě diagramů činností a ve 2. fázi jsme identifikovali kroky procesu, pro které je automatizace vyžadována (a možná).
Připomínám, že se chystáme automatizovat činnost účtování o hmotném majetku, která v těchto procesech vzniká.
...
Ostrov leží na moři, (E1, E2)
Na ostrově jsou kroupy (E3, E1)
S kostely se zlatou kupolí, (E4)
S věžemi a zahradami; (E5, E6)
Před palácem roste smrk, (E7, E8)
A pod ním je křišťálový dům; (E9)
Žije tam krotká veverka, (A1)
Ano, jaké dobrodružství! (A1)
Veverka zpívá písničky, (P1, A1)
Ano, pořád okusuje ořechy, (P2)
Ale ořechy nejsou jednoduché, (C1)
Všechny skořápky jsou zlaté, (C2)
Jádro je čistý smaragd; (C3)
Sluhové hlídají veverku, (P3, A2)
Slouží jí jako různí sluhové (P4)
A byl přidělen úředník (A3)
Přísný popis ořechů je novinkou; (P5, C1)
Vojsko ji pozdravuje; (P6, A4)
Z mušlí se sype mince (P7, C2, C4)
Nechte je jít po světě; (P8)
Dívky nalévají smaragd (P9, A5, C3)
Do skladů a pod kryt; (E10, E11)
...
(A.S. Puškin „Příběh cara Saltana, jeho slavného a mocného hrdiny prince Guidona Saltanoviče a krásné princezny Swan“, )
V tomto příkladu používám framework Enterprise Architect od australské společnosti [2] a během tréninků používám [3].
Připomínám, že existují různé procesy, můžete se seznámit např. [4] a [5].
Více podrobností o aplikovaných přístupech k modelování a návrhu viz [6, 7].
Kompletní specifikace UML viz [8].
Nyní jsme připraveni přejít k dalším krokům a začít navrhovat funkcionalitu systému a vnitřní organizaci. Číslování výkresů bude pokračovat.
Fáze 3. Automatizovaný krok musí být spojen s funkcí nebo funkcemi systému
Vyvíjený automatizovaný systém (AS) je navržen tak, aby udržoval přísné záznamy o ořechách, pamatujete? Pro každý zvýrazněný krok (viz obrázek 3, obrázek 4 ), kterou zautomatizujeme, zapíšeme funkční požadavek pomocí přibližně následující konstrukce: „Systém musí implementovat schopnost...“ a vyvineme Use-case diagram. Nyní do naší modelovací smlouvy přidáváme nová pravidla. Dovolte mi vysvětlit, jaké prvky použijeme.
Použijeme spojení „Asociace“ mezi „Uživatelskou rolí“ a „Funkcí“ (obrázek 5), to znamená, že uživatel s touto rolí může tuto funkci vykonávat.
Obrázek 5. Použití vztahu typu asociace
Od „Funkce“ po „Požadavek“ nakreslíme spojení „Implementace“ (obrázek 6), abychom ukázali, že tento požadavek bude implementován těmito funkcemi; vztah může být „many-to-many“, tzn. Jedna funkce může být zapojena do implementace několika požadavků a k implementaci požadavku může být zapotřebí více než jedna funkce.
Obrázek 6. Použití vztahu typu „Implementace“.
Pokud jedna funkce vyžaduje ke svému provedení, aby byla provedena nějaká další funkce, a to nutně, použijeme spojení „Závislost“ se stereotypem „Zahrnout“ (obrázek 7). Pokud je za určitých podmínek vyžadováno provedení další funkce, pak použijeme spojení „Závislost“ se stereotypem „Rozšířit“. Vše je velmi snadno zapamatovatelné: „Zahrnout“ je VŽDY a „Rozšířit“ je NĚKDY.
Obrázek 7. Použití vztahu „Závislost (zahrnutí)“.
Ve výsledku bude náš diagram vypadat nějak takto (obrázek 8).
Obrázek 8. Schéma případu použití (funkční model AC)
Kromě toho se k modelování uživatelských rolí používá diagram případu použití (obrázek 9).
Obrázek 9. Diagram případu použití (role uživatelů AS)
Fáze 4. Popišme vnitřní organizaci AS pomocí diagramu tříd
Pomocí informací o vstupních a výstupních artefaktech našeho procesu (viz Diagramy aktivit - Obrázek 2, Obrázek 3, Obrázek 4) vytvoříme diagram tříd. Využijeme modelovací prvky „Class“ a různé typy vazeb mezi nimi.
Pro znázornění vztahu „celá část“ použijeme vztah typu „Agregace“ (obrázek 10): ořech je celek a skořápka a jádro jsou části.
Obrázek 10. Vztah celé části
Ve výsledku bude fragment našeho diagramu vypadat nějak takto (obrázek 11). Barevně jsou označeny třídy, které jsme zvýraznili přímo v textovém popisu procesu.
Obrázek 11. Diagram tříd
Diagram tříd byl také použit k modelování dalších artefaktů – nejen těch, které budou souviset s koncepčním modelem automatizovaného procesu účtování o hmotných aktivech, ale také souvisejících s realizačním prostředím – prostředím (obrázek 12) a „sousedním“ procesy (obrázek 13), které mohou ovlivnit automatizovaný proces, ale zatím nejsou v centru naší pozornosti (předpokládáme, že se systém bude vyvíjet a tyto informace budou užitečné).
Obrázek 12. Diagram tříd (prostředí)
Vztah dědičnosti ukazuje zobecnění různých budov, „dětských“ tříd pod zobecňující „rodičovskou“ třídu „Budova“.
Obrázek 13. Diagram tříd (další informace o artefaktech)
„Reakce na situaci“ závisí na „Data vizuální kontroly“. Pro několik závislostních vztahů se stereotyp "trasování" používá k zobrazení sledování tříd, které nejsou explicitně identifikovány v popisu procesu, ale které jsou potřebné k jeho automatizaci, do tříd, na jejichž instance se v našem popisu výslovně odkazuje.
Fáze 5. Pojďme analyzovat poznámky ke stopě „Obchodní pravidla“.
Pravidla byla specifikována (viz obrázek 2 ):
- potřeba rozdělit jeden z kroků na 2 části, druhá část se začne provádět pouze za určitých podmínek;
- jmenování určitého úředníka, který bude provádět účtování ořechů;
- technika (bílá barva prvků), která označuje, že prvek nebyl explicitně specifikován v popisu procesu.
Nutno podotknout, ž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 etapami a vytvořili 3 typy diagramů. Přidám malý komentář k organizaci našich modelů v modelovacím prostředí. Existuje velké množství frameworků, které pomáhají strukturovat vyvíjené modely, ale to není předmětem tohoto článku, proto se omezíme na následující jednoduchou sadu balíčků pro řádné řízení našeho projektu: Business Process, Functional Model , Artefakty, účastníci a prostředí (obrázek 14).
Obrázek 14. Struktura projektového balíčku
Vyvinuli jsme tedy konzistentní modely, které popisují materiálový účetní systém z různých hledisek: model automatizovaného podnikového procesu, funkční model a model vnitřní organizace systému na koncepční úrovni.
Seznam zdrojů
- Web "UML2.ru". Fórum komunity analytiků. Obecná sekce. Příklady. Příklady pohádek formátovaných jako UML diagramy. [Elektronický zdroj] Režim přístupu: Internet:
- Web Sparx Systems. [Elektronický zdroj] Režim přístupu: Internet:
- Web Modelio. [Elektronický zdroj] Režim přístupu: Internet:
- Velký encyklopedický slovník. Proces (výklad). [Elektronický zdroj] Režim přístupu: Internet:
- Web "Organizace efektivního řízení". Blog. Kategorie "Řízení obchodních procesů". Definice podnikového procesu. [Elektronický zdroj] Režim přístupu: Internet:
- Osvědčení č. 18249 o registraci a uložení díla duševní činnosti. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Rukopis učební pomůcky s názvem „Modelování předmětové oblasti pomocí Enterprise Architect“ // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modelování obchodních procesů. — M.: KURZ, SIC INFRA-M, EBS Znanium.com. — 2017.
- Specifikace OMG Unified Modeling Language (OMG UML). Verze 2.5.1. [Elektronický zdroj] Režim přístupu: Internet:
Zdroj: www.habr.com