„Jeden den ze života veverky“ nebo od modelování procesů k projektování automatizovaného systému evidence materiálních hodnot „Veverka-1.0“ (Část 1)
Jakou roli hraje „veverka“?
Hned vysvětlím, jakou roli hraje „veverka“. Narazil jsem na internetu na zábavné projekty pro studium UML, vycházející z tematické oblasti převzaté ze zápletek pohádek (například, [1]), také jsem se rozhodla připravit podobný příklad pro své studenty, abychom mohli studovat na začátku pouze tři typy diagramů: Aktivity Diagram, Use-case Diagram a Class Diagram. Úmyslně nepřekládám názvy diagramů do ruštiny, abych se vyhnula sporům o "těžkostech překladu". Co se k čemu hodí – vysvětlím trochu později. V tomto příkladu používám prostředí Enterprise Architect od australské společnosti [2] – dobrý nástroj za rozumné peníze. A během výuky používám [3], slušný bezplatný nástroj pro objektové navrhování, který podporuje standardy UML 2.0 a BPMN, bez zbytečných vylepšení v oblasti zobrazení, ale zcela dostačující pro studium základů jazyka.
Chceme automatizovat činnost spojenou s evidencí 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 hrdinovi príncipe Gvidonovi Saltanoviči a o krásné princezně Labuti", — 10 let od myšlenky k publikaci, mezi jiné!)
Trochu o kódech, které jsou napsány napravo od řádků. "A" (od "Actor") znamená, že v řádku jsou obsaženy informace o účastníku procesu. "C" (od "Class") – informace o objektech tříd, které jsou zpracovávány během realizace procesů. "E" (od "Environment") – informace o objektech tříd, které charakterizují okolí realizace procesů. "P" (od "Process") – informace o samotných procesech.
Mimochodem, přesná definice procesu také vyvolává metodologické debaty, alespoň z důvodu, že procesy mohou být různé: obchodní, výrobní, technologické atd. a tak dále (možno zhlédnout například, [4] a [5]). Abychom se vyhnuli polemice, dohodneme se, že proces nás zajímá z pohledu jeho opakovatelnosti v čase a potřeby po automatizaci, tj. na převedení provádění jakékoli části operací procesu na automatizovaný systém.
Poznámky k použití diagramu Activity
Začneme modelovat náš proces a k tomu využijeme diagram Activity. Nejprve vysvětlím, jak budou výše uvedené kódy použity v modelu. Vysvětlovat je snazší na grafickém příkladu, a zároveň probereme některé (téměř všechny z potřebných) prvky diagramu Activity.
Analyzujme následující fragment:
…
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)
…
Máme dva kroky procesu P1 a P2, účastníka A1 a objekty tříd tří různých tříd: objekt třídy C1 vstupuje do kroku, objekty tříd C2 a C3 získáváme na výstupu, jako výsledek činnosti tohoto kroku P2 našeho procesu. Pro diagram použijeme následující modelovací prvky.
Fragment našeho procesu lze představit přibližně takto (Obrázek 1).
Obrázek 1. Fragment diagramu Activity
Pro organizaci prostoru a strukturování diagramu Activity použijeme poněkud nestandardní přístup z pohledu klasického využití notace UML. Ale na to existuje několik důvodů. Zaprvé, před začátkem modelování sestavíme takzvanou dohodu o modelování, ve které zaznamenáme všechny zvláštnosti používání notace. Za prvé, tento přístup byl opakovaně úspěšně aplikován v etapě business modelování v reálných projektech vytváření softwarových systémů, jejichž výsledky byly zdokumentovány naším malým autorským kolektivem v příslušném objektu autorského práva [6] a byly také použity ve vzdělávací příručce [7]. Pro diagram Activity určíme, že pole diagramu strukturalizujeme pomocí „plovoucích“ drah – Swim lanes. Název dráhy bude odpovídat typu prvků diagramu, které budou umístěny na této dráze.
„Vstupní a výstupní artefakty“: na této dráze budou umístěny prvky Objects – objekty, které jsou používány nebo jsou výsledkem provedení nějakého kroku procesu.
„Kroky procesu“: sem umístíme prvky Activity – činnosti účastníků procesu.
„Účastníci“: dráha pro prvky, které budou označovat role vykonavatelů činností v našem procesu, pro ně opět využijeme modelující prvek Object – objekt, ale přidáme k němu stereotip „Actor“.
Další dráha se nazývá „Obchodní pravidla“ a na této dráze umístíme textově pravidla pro provádění kroků procesu, k tomu použijeme modelující prvek Note – poznámku.
Tady se zastavíme, i když bychom mohli také využít dráhu „Nástroje“ pro shromažďování informací o úrovni automatizace procesu. Ještě by mohla být užitečná dráha „Pozice a oddělení účastníků“, kterou můžeme použít k propojení rolí s pozicemi a odděleními účastníků procesu.
Všechno, co jsem právě popsala, je fragmentem dohody o modelování, tato část dohody se týká pravidel organizace jednoho diagramu a odpovídajících pravidel jeho psaní a čtení.
„Recept“
Nyní se podívejme na možnost modelování systému přímo z diagramu Activity. Tohoto je pouze jedna z možností; poznamenávám, že samozřejmě není jediná. Diagram aktivity nás bude zajímat z pohledu jeho role při přechodu od modelování procesu k návrhu automatizovaného systému. K tomu se budeme řídit metodickými doporučeními – jakýmsi receptem, které se skládá pouze z pěti fází a zahrnuje vypracování tří typů diagramů. Použití tohoto receptu pomůže získat formalizovaný popis procesu, který chceme automatizovat, a shromáždit data pro návrh systému. A pro studenty, kteří začínají s UML, je to jakýsi záchranný kruh, který je nenechá utopit se v té rozmanitosti vyjadřovacích prostředků a technik, které existují v UML a moderních nástrojích pro modelování.
Toto je vlastně samotný recept a následují diagramy, které byly sestaveny pro naši "pohádkovou" tematickou oblast.
Fáze 1. Popisujeme proces ve formě diagramu aktivity. U procesu, ve kterém je vyznačeno více než 10 kroků, má smysl použít princip dekompozice kroků procesu, abychom zvýšili čitelnost diagramu.
Fáze 2. Vybíráme to, co lze automatizovat. (kroky mohou být například zvýrazněny v diagramu).
Fáze 3. Automatizovanému kroku je třeba přiřadit jednu nebo více funkcí systému. (vztah může být mnoha-k-mnohým), kreslíme diagram use-case. To jsou funkce našeho systému.
Fáze 4. Popíšeme vnitřní organizaci AС pomocí diagramu tříd. – Class. Plavecký pruh „Vstupní a výstupní objekty (dokumenty)“ na diagramu aktivity – to je základ pro vytváření objektového modelu a modelu entita-vztah.
Fáze 5. Analyzujeme poznámky na pruhu „Obchodní pravidla“., poskytují různé druhy omezení a podmínek a postupně se transformují na nefunkční požadavky.
Výsledná sada diagramů (aktivity, use-case, tříd) nám poskytuje formalizovaný popis v dostatečně přísné notaci, tj. má jednoznačné přečtení. Nyní můžeme začít vypracovávat technickou specifikaci, upřesňovat požadavkovou specifikaci atd.
Pustíme se do modelování.
Fáze 1. Popisujeme proces ve formě diagramu aktivity.
Připomínám, že pole diagramu jsme strukturovali pomocí "plovoucích" drah, na každé dráze jsou umístěny prvky jednoho typu (Obrázek 2). Kromě výše popsaných prvků diagramu budeme používat další prvky, které si popíšeme.
Rozhodnutí (Decision) označuje na diagramu bod větvení našeho procesu, zatímco sloučení toků (Merge) je bodem jejich znovuspojení. V hranatých závorkách na přechodech jsou uvedena podmínky přechodu.
Mezi dvěma synchronizátory (Fork) ukážeme paralelní větve procesu.
Náš proces může mít pouze jeden začátek – jeden vstupní bod (Initial). Ale ukončení (Final) může být i několik, i když ne pro náš konkrétní diagram.
Šipek se docela hodně hromadí, při velkém počtu prvků a vazeb lze nejprve vymezit fáze procesu a teprve poté provádět dekompozici těchto fází. Ale náš "pohádkový" proces bych chtěl pro názornost ukázat celý na jednom diagramu, přičemž je samozřejmě třeba usilovat o to, aby se šipky "neslepovaly", aby bylo možné přesně sledovat, co s čím souvisí.
Obrázek 2. Diagram Activity – celkový pohled na proces
Protože v básnických řádcích byly některé detaily procesu opomenuty, museli jsme je obnovit, jsou zobrazeny prvky s bílým pozadím. Tyto detaily zahrnují krok "Přenos/přijetí na skladování a zpracování" a několik vstupních a výstupních artefaktů. Je třeba poznamenat, že tento krok také neodhaluje proces zcela, protože bychom museli odděleně vyznačit krok přenosu a krok přijetí, a navíc přidat samostatný krok pro skořápky, a měli bychom také vymyslet, že všechny tyto materiální hodnoty by měly někde dočasně sídlit atd.
Ještě si všimneme, že zůstává zatím neodpovězená otázka o původu ořechů – odkud pocházejí a jak se dostávají k veverce? A tato otázka (vyznačená červenou barvou písma v poznámce – prvek Note) vyžaduje samostatné zpracování! Takto pracuje analytik – sbírá informace po částech, dělá předpoklady a dostává "okej" či "ne-okej" od odborníků na danou oblast – velmi důležitých a jednoduše nenahraditelných osob na etapě obchodního modelování při vytváření systémů.
Také si uvědomíme, že krok procesu P5 se skládá ze dvou částí.
A každou část podrobněji rozložíme a prozkoumáme (Obrázek 3, Obrázek 4), protože činnosti prováděné v rámci těchto kroků budou automatizovány.
Obrázek 3. Diagram Activity – podrobné rozpracování (část 1)
Obrázek 4. Diagram Activity – podrobné rozpracování (část 2)
Fáze 2. Vybíráme to, co lze automatizovat.
Kroky podléhající automatizaci na diagramech jsou vyznačeny barvou (viz Obrázek 3, Obrázek 4).
Vše vykonává jeden účastník procesu – Diak příkazný:
- Zaznamenává informace o hmotnosti ořechu do listu;
- Zaznamenává informace o předání ořechu do listu;
- Zaznamenává skutečnost přeměny ořechu na skořápky a jádro;
- Zaznamenává informace o jádru ořechu do listu;
- Zaznamenává informace o skořápkách ořechu do listu.
Analýza vykonané práce. Co dál?
Takže jsme provedli velkou přípravnou práci: shromáždili jsme informace o procesu, který chceme automatizovat; začali jsme vytvářet dohodu o modelování (zatím pouze co se týče použití diagramu Activity); provedli jsme modelování procesu a dokonce jsme rozložili několik jeho kroků; vyčlenili jsme kroky procesu, které budeme automatizovat. Nyní jsme připraveni přejít k dalším fázím a začít projektovat funkce systému a jeho vnitřní organizaci.
Jak je známo, teorie bez praxe je nic. Je nutné určitě vyzkoušet "modelování" vlastníma rukama, je to užitečné i pro pochopení navrhovaného přístupu. Například lze pracovat v prostředí modelování [3]. Rozložili jsme pouze část kroků diagramu obecného pohledu procesu (viz Obrázek 2). Jako praktický úkol může být navrženo opakovat všechny diagramy v prostředí Modelio a provést rozložení kroku „Předávání/přijímání na skladování a zpracování“.
Práci v konkrétních modelech zatím nezvažujeme, ale to může být předmětem samostatných článků a recenzí.
Ve druhé části článku se budeme zabývat metodami modelování a projektování, které jsou potřebné ve fázích 3-5, použijeme UML diagramy Use-case a Class. Pokračování následuje.
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.
Zdroj: habr.com
