„Jeden den v životě veverky“ aneb od modelování procesů k návrhu automatizovaného systému účtování majetku „Belka-1.0“ (část 1)
Co s tím má společného „veverka“?
Okamžitě vysvětlím, co s tím má „veverka“ společného. Když jsem na internetu narazil na zábavné projekty pro výuku UML na základě oblasti vypůjčené z pohádek (např. [1]), rozhodl jsem se také připravit podobný příklad pro své studenty, aby si mohli pro začátek prostudovat pouze tři typy diagramů: diagram aktivity, diagram případu užití a diagram tříd. Záměrně nepřekládám názvy diagramů do ruštiny, abych se vyhnul sporům o „problémech s překladem“. K čemu to je, vysvětlím trochu později. V tomto příkladu používám framework Enterprise Architect od australské společnosti [2] – dobrý nástroj za rozumnou cenu. A jako součást svých tréninků používám [3], dobrý bezplatný nástroj pro objektově orientovaný návrh, který podporuje standardy UML2.0 a BPMN, bez zbytečných zvonění, pokud jde o vizuální schopnosti, ale zcela dostačující pro osvojení základů jazyka.
Chystáme se 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“, — 10 let od konceptu po zveřejnění, mimochodem!)
Něco málo o kódech, které se zapisují napravo od řádků. „A“ (od „Actor“) znamená, že řádek obsahuje informace o účastníkovi procesu. „C“ (od „Class“) – informace o objektech třídy, které jsou zpracovávány během provádění procesů. „E“ (od „Environment“) – informace o objektech třídy, které charakterizují prostředí pro provádění procesů. „P“ (od „Proces“) – informace o samotných procesech.
Mimochodem, přesná definice procesu také tvrdí, že je příčinou metodických sporů, i když jen kvůli skutečnosti, že existují různé procesy: obchodní, výrobní, technologické atd. a tak dále. (můžete zjistit např. [4] a [5]). Abychom se vyhnuli kontroverzi, shodněme se na tom Proces nás zajímá z pohledu jeho opakovatelnosti v čase a potřeby automatizace, tj. převod provádění jakékoli části procesních operací do automatizovaného systému.
Poznámky k používání diagramu aktivity
Začněme modelovat náš proces a použijeme k tomu diagram aktivit. Nejprve mi dovolte vysvětlit, jak budou výše uvedené kódy použity v modelu. Snáze se to vysvětluje na grafickém příkladu, ale zároveň analyzujeme některé (téměř všechny, které potřebujeme) prvky diagramu aktivit.
Pojďme analyzovat následující fragment:
...
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)
...
Máme dva procesní kroky P1 a P2, účastníka A1 a objekty tří různých tříd: objekt třídy C1 je vstupem do kroku, objekty tříd C2 a C3 jsou výstupem jako výsledek aktivity tohoto kroku P2 našeho proces. Pro diagram používáme následující modelovací prvky.
Fragment našeho procesu může být reprezentován nějak takto (obrázek 1).
Obrázek 1. Fragment diagramu aktivity
K uspořádání prostoru a struktuře Activity diagramu použijeme nestandardní přístup, z pohledu klasického použití UML notace. Má to ale několik důvodů. Nejprve těsně před zahájením modelování sestavíme tzv modelovací smlouva, ve kterém zaznamenáváme všechny vlastnosti používání notace. Za druhé, tento přístup byl opakovaně úspěšně aplikován ve fázi obchodního modelování v reálných projektech pro tvorbu softwarových systémů, výsledky byly zaznamenány naším malým týmem autorů do odpovídajícího objektu copyrightu [6] a byly také použity ve školicím manuálu [ 7]. Pro diagram aktivity definujeme, že pole diagramu je strukturováno pomocí „plaveckých drah“. Název trasy bude odpovídat typu prvků mapy, které budou na dané trase umístěny.
"Vstupní a výstupní artefakty": Tato stopa bude obsahovat prvky Objects - objekty, které se používají nebo jsou výsledkem provedení některého procesního kroku.
"Procesní kroky": Zde umístíme prvky Activity – akce účastníků procesu.
"Účastníci": cesta pro prvky, které budou označovat role akčních performerů v našem procesu, pro ně použijeme stejný modelovací prvek Objekt - objekt, ale přidáme k němu stereotyp „Actor“.
Další stopa se nazývá "Obchodní pravidla" a na tuto stopu umístíme v textové podobě pravidla pro provádění kroků procesu a k tomu použijeme modelovací prvek Poznámka - poznámka.
Zde se zastavíme, i když bychom mohli využít i cestu "Nástroje" shromažďovat informace o úrovni automatizace procesů. Také cesta může přijít vhod "Pozice a rozdělení účastníků", lze jej použít k propojení rolí s pozicemi a odděleními účastníků procesu.
Vše, co jsem právě popsal, je fragment modelářské konvence, tato část smlouvy se týká pravidel pro uspořádání jednoho diagramu a podle toho i pravidel pro jeho psaní a čtení.
"Recept"
Nyní se podívejme na možnost konkrétního modelování systému z diagramu aktivit. To je jen jedna z možností, podotýkám, že samozřejmě není jediná. Diagram Activity nás bude zajímat z pohledu jeho role při přechodu od procesního modelování k návrhu automatizovaného systému. K tomu se budeme držet metodických doporučení - jakýsi recept skládající se pouze z pěti fází a zajišťující vývoj pouze tří typů diagramů. Použití tohoto receptu nám pomůže získat formalizovaný popis procesu, který chceme automatizovat, a shromáždit data pro návrh systému. A pro studenty na začátku studia UML jde o druh životabudiče, který jim nedovolí utopit se ve vší rozmanitosti vizuálních prostředků a technik, které se v UML a moderních modelovacích nástrojích nacházejí.
Zde je ve skutečnosti samotný recept a poté postupujte podle diagramů vytvořených pro naši „pohádkovou“ oblast.
Fáze 1. Popíšeme proces ve formě diagramu aktivit. Pro proces s více než 10 kroky má smysl použít princip rozkladu procesního kroku pro zlepšení čitelnosti diagramu.
Fáze 2. Vyberte, co lze automatizovat (kroky mohou být zvýrazněny například na diagramu).
Fáze 3. Automatizovaný krok musí být spojen s funkcí nebo funkcemi systému (vztah může být many-to-many), nakreslete diagram případu použití. To jsou funkce našeho systému.
Fáze 4. Popišme vnitřní organizaci AS pomocí diagramu tříd - Třída. Průběh „Vstupní a výstupní objekty (dokumenty)“ v diagramu aktivit je základem pro vytvoření objektového modelu a modelu vztahu mezi entitou.
Fáze 5. Pojďme analyzovat poznámky ke stopě „Obchodní pravidla“., poskytují různé druhy omezení a podmínek, které se postupně přeměňují v nefunkční požadavky.
Výsledná množina diagramů (Activity, Use-case, Class) nám dává formalizovaný popis v dosti strohém zápisu, tzn. má jednoznačné čtení. Nyní můžete vyvíjet technické specifikace, objasňovat specifikace požadavků atd.
Začněme modelovat.
Fáze 1. Popište proces ve formě diagramu činností
Připomínám, že pole diagramu jsme strukturovali pomocí „plaveckých“ drah, každá dráha obsahuje prvky stejného typu (obrázek 2). Kromě výše popsaných prvků diagramu použijeme další prvky, pojďme si je popsat.
Rozhodnutí (Decision) označuje bod větvení našeho procesu v diagramu a slučování vláken (Merge) – bod jejich opětovného sjednocení. Přechodové podmínky jsou na přechodech psány v hranatých závorkách.
Mezi dvěma synchronizátory (Fork) si ukážeme paralelní větve procesu.
Náš proces může mít pouze jeden začátek – jeden vstupní bod (Initial). Ale může dojít k několika dokončením (Konečný), ale ne pro náš konkrétní diagram.
Šipek je poměrně hodně, s velkým počtem prvků a spojení můžete nejprve identifikovat fáze procesu a poté provést rozklad těchto fází. Ale pro názornost bych náš „pohádkový“ proces rád ukázal celý na jednom diagramu, přičemž samozřejmě musíme zajistit, aby se šipky „nelepily k sobě“, bylo by možné přesně sledovat, co je spojeno k čemu.
Obrázek 2. Diagram aktivity - celkový pohled na proces
Protože v poetických liniích jsou vynechány některé detaily procesu, musely být restaurovány, jsou znázorněny prvky s bílým pozadím. Tyto podrobnosti zahrnují krok přenosu/příjem pro uložení a zpracování a několik vstupních a výstupních artefaktů. Stojí za zmínku, že tento krok také plně neodhalí proces, protože museli bychom samostatně označit krok přenosu a krok příjmu a dokonce přidat samostatný krok pro mušle a také si myslet, že všechny tyto materiálové hodnoty by měly být někde dočasně uloženy atd. a tak dále.
Ještě poznamenejme, že nezodpovězena zůstává otázka původu ořechů – odkud pocházejí a jak se dostanou k veverce? A tato otázka (v poznámce je zvýrazněna červeným písmem - prvek Poznámka) vyžaduje samostatné studium! Takto pracuje analytik – sbírá informace kousek po kousku, vytváří předpoklady a přijímá „dobře“ nebo „není“ od odborníků na předmět – velmi důležitých a jednoduše nenahraditelných lidí ve fázi obchodního modelování při vytváření systémů.
Všimněte si také, že procesní krok P5 se skládá ze dvou částí.
A každou část rozložíme a zvážíme ji podrobněji (obrázek 3, obrázek 4), protože Činnosti prováděné v rámci těchto konkrétních kroků budou automatizovány.
Obrázek 3. Schéma činnosti - podrobný popis (část 1)
Obrázek 4. Schéma činnosti - podrobný popis (část 2)
Fáze 2. Vyberte, co lze automatizovat
Kroky, které mají být automatizovány, jsou na diagramech barevně zvýrazněny (viz obrázek 3, obrázek 4).
Všechny provádí jeden účastník procesu - úředník:
- Do výpisu zapíše informaci o hmotnosti ořechu;
- Do výpisu zadává informaci o převodu matice;
- Zaznamenává skutečnost přeměny ořechu na skořápku a jádro;
- Do výpisu zadává informace o jádru ořechu;
- Zadá do seznamu informace o ořechových skořápkách.
Analýza provedené práce. Co bude dál?
Udělali jsme tedy mnoho přípravné práce: shromáždili jsme informace o procesu, který se chystáme automatizovat; začala vznikat dohoda o modelování (zatím pouze ve smyslu použití Diagramu aktivit); provedl simulaci procesu a dokonce rozložil několik jeho kroků; Identifikovali jsme procesní kroky, které budeme automatizovat. Nyní jsme připraveni přejít k dalším krokům a začít navrhovat funkcionalitu systému a vnitřní organizaci.
Jak víte, teorie bez praxe není nic. Určitě byste si měli vyzkoušet „modelování“ vlastníma rukama, což je také užitečné pro pochopení navrhovaného přístupu. Můžete například pracovat v modelovacím prostředí [3]. Rozložili jsme pouze část kroků celkového procesního diagramu (viz obrázek 2). Jako praktický úkol můžete být požádáni o zopakování všech diagramů v prostředí Modelio a provedení dekompozice kroku „Přenos/Příjem pro uložení a zpracování“.
O práci v konkrétních modelovacích prostředích zatím neuvažujeme, ale může se to stát předmětem nezávislých článků a recenzí.
Ve druhé části článku analyzujeme modelovací a návrhové techniky nezbytné ve fázích 3-5, použijeme UML Use-case a Class diagramy. Pokračování příště.
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.
Zdroj: www.habr.com