„Jeden deň v živote veveričky“ alebo od modelovania procesov k návrhu automatizovaného systému účtovania majetku „Belka-1.0“ (1. časť)
Čo s tým má spoločné „veverička“?
Hneď vám vysvetlím, čo s tým má „veverička“. Keď som na internete natrafil na zábavné projekty na učenie sa jazyka UML na základe oblasti požičanej z rozprávok (napr. [1]), rozhodol som sa pripraviť podobný príklad aj pre svojich študentov, aby si na začiatok mohli preštudovať iba tri typy diagramov: diagram aktivity, diagram prípadu použitia a diagram tried. Zámerne neprekladám názvy diagramov do ruštiny, aby som predišiel sporom o „problémoch s prekladom“. Trochu neskôr vysvetlím, na čo to je. V tomto príklade používam rámec Enterprise Architect od austrálskej spoločnosti [2] – dobrý nástroj za rozumnú cenu. A ako súčasť svojich tréningov používam [3], dobrý bezplatný nástroj na objektovo orientovaný dizajn, ktorý podporuje štandardy UML2.0 a BPMN, bez zbytočných zvončekov a píšťaliek z hľadiska vizuálnych možností, ale úplne postačujúci na učenie sa základov jazyka.
Ideme zautomatizovať č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“, — 10 rokov od konceptu po zverejnenie, mimochodom!)
Trochu o kódoch, ktoré sa píšu napravo od riadkov. „A“ (od „Actor“) znamená, že riadok obsahuje informácie o účastníkovi procesu. „C“ (od „Trieda“) – informácie o objektoch triedy, ktoré sa spracúvajú počas vykonávania procesov. „E“ (od „Environment“) – informácie o objektoch triedy, ktoré charakterizujú prostredie na vykonávanie procesov. „P“ (od „Proces“) – informácie o samotných procesoch.
Mimochodom, presná definícia procesu tiež tvrdí, že je príčinou metodických sporov, už len kvôli tomu, že existujú rôzne procesy: obchodné, výrobné, technologické atď. a tak ďalej. (môžete zistiť napr. [4] a [5]). Aby sme sa vyhli kontroverziám, dohodnime sa Proces nás zaujíma z pohľadu jeho opakovateľnosti v čase a potreby automatizácie, t.j. prenos vykonávania akejkoľvek časti procesných operácií do automatizovaného systému.
Poznámky k používaniu diagramu aktivity
Začnime modelovať náš proces a použijeme na to diagram aktivity. Najprv mi dovoľte vysvetliť, ako sa vyššie uvedené kódy použijú v modeli. Je to jednoduchšie vysvetliť na grafickom príklade, ale zároveň analyzujeme niektoré (takmer všetky, ktoré potrebujeme) prvky diagramu aktivít.
Poďme analyzovať nasledujúci fragment:
...
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)
...
Máme dva kroky procesu P1 a P2, účastníka A1 a objekty troch rôznych tried: objekt triedy C1 je vstupom do kroku, objekty tried C2 a C3 sú výstupom ako výsledok aktivity tohto kroku P2 nášho proces. Pre diagram používame nasledujúce modelovacie prvky.
Fragment nášho procesu môže byť reprezentovaný nejako takto (obrázok 1).
Obrázok 1. Fragment diagramu aktivity
Na usporiadanie priestoru a štruktúru diagramu aktivít použijeme neštandardný prístup z pohľadu klasického použitia notácie UML. Má to však viacero dôvodov. Po prvé, tesne pred začatím modelovania zostavíme tzv dohoda o modelovaní, v ktorej zaznamenávame všetky znaky používania notácie. Po druhé, tento prístup bol opakovane úspešne aplikovaný vo fáze obchodného modelovania v reálnych projektoch na vytváranie softvérových systémov; výsledky boli zaznamenané naším malým tímom autorov v zodpovedajúcom objekte autorských práv [6] a boli tiež použité v školiacom manuáli [ 7]. Pre diagram aktivity definujeme, že pole diagramu je štruktúrované pomocou „plaveckých dráh“. Názov trasy bude zodpovedať typu prvkov mapy, ktoré budú umiestnené na danej trase.
"Vstupné a výstupné artefakty": Táto stopa bude obsahovať prvky Objects – objekty, ktoré sa používajú alebo sú výsledkom vykonania nejakého procesného kroku.
"Kroky procesu": Sem umiestnime prvky aktivity – akcie účastníkov procesu.
"Účastníci": cesta pre prvky, ktoré budú označovať roly akčných umelcov v našom procese, pre ne použijeme rovnaký modelovací prvok Objekt - objekt, ale pridáme k nemu stereotyp „herca“.
Ďalšia skladba sa volá "Obchodné pravidlá" a na túto dráhu umiestnime v textovej forme pravidlá pre vykonávanie krokov procesu a na to použijeme modelovací prvok Poznámka - poznámka.
Tu sa zastavíme, hoci by sme mohli použiť aj cestu "nástroje" na zhromažďovanie informácií o úrovni automatizácie procesov. Vhod môže prísť aj cesta "Pozície a rozdelenie účastníkov", možno ho použiť na prepojenie rolí s pozíciami a oddeleniami účastníkov procesu.
Všetko, čo som práve opísal, je fragment modelovacie konvencie, táto časť dohody sa týka pravidiel usporiadania jedného diagramu a podľa toho pravidiel jeho písania a čítania.
"recept"
Teraz zvážime možnosť konkrétneho modelovania systému z diagramu aktivity. Toto je len jedna z možností, podotýkam, že nie je, samozrejme, jediná. Diagram Activity nás bude zaujímať z pohľadu jeho úlohy pri prechode od procesného modelovania k návrhu automatizovaného systému. Aby sme to dosiahli, budeme dodržiavať metodické odporúčania - akýsi recept pozostávajúci iba z piatich etáp a zabezpečujúci vývoj iba troch typov diagramov. Použitie tohto receptu nám pomôže získať formalizovaný popis procesu, ktorý chceme automatizovať, a zbierať dáta pre návrh systému. A pre študentov na začiatku štúdia UML je to druh životabudiča, ktorý im nedovolí utopiť sa vo všetkej rozmanitosti vizuálnych prostriedkov a techník, ktoré sa nachádzajú v UML a moderných modelovacích nástrojoch.
Tu je v skutočnosti samotný recept a potom postupujte podľa diagramov vytvorených pre našu oblasť „rozprávky“.
Fáza 1. Opíšeme proces vo forme diagramu aktivít. Pre proces s viac ako 10 krokmi má zmysel použiť princíp rozkladu procesných krokov, aby sa zlepšila čitateľnosť diagramu.
Fáza 2. Vyberte, čo sa dá automatizovať (kroky môžu byť zvýraznené napríklad na diagrame).
Fáza 3. Automatizovaný krok musí byť spojený s funkciou alebo funkciami systému (vzťah môže byť many-to-many), nakreslite diagram prípadu použitia. Toto sú funkcie nášho systému.
Fáza 4. Opíšme vnútornú organizáciu AS pomocou diagramu tried - Trieda. Priebeh „Vstupné a výstupné objekty (dokumenty)“ v diagrame aktivít je základom pre vytvorenie modelu objektu a modelu vzťahu medzi entitou.
Fáza 5. Analyzujme poznámky k skladbe „Obchodné pravidlá“., poskytujú rôzne druhy obmedzení a podmienok, ktoré sa postupne premieňajú na nefunkčné požiadavky.
Výsledný súbor diagramov (Activity, Use-case, Class) nám dáva formalizovaný popis v dosť prísnom zápise, t.j. má jednoznačné čítanie. Teraz môžete vytvoriť technické špecifikácie, objasniť špecifikácie požiadaviek atď.
Začnime s modelovaním.
Fáza 1. Opíšte proces vo forme diagramu aktivít
Dovoľte mi pripomenúť, že pole diagramu sme štruktúrovali pomocou „plaveckých“ dráh, pričom každá dráha obsahuje prvky rovnakého typu (obrázok 2). Okrem vyššie popísaných prvkov diagramu použijeme ďalšie prvky, popíšeme si ich.
Rozhodnutie (Decision) označuje bod vetvenia nášho procesu v diagrame a zlučovanie vlákien (Merge) – bod ich opätovného zjednotenia. Prechodové podmienky sú na prechodoch napísané v hranatých zátvorkách.
Medzi dvoma synchronizátormi (Fork) si ukážeme paralelné vetvy procesu.
Náš proces môže mať len jeden začiatok – jeden vstupný bod (Initial). Môže však existovať niekoľko dokončení (Konečný), ale nie pre náš konkrétny diagram.
Existuje pomerne veľa šípok, s veľkým počtom prvkov a spojení môžete najskôr identifikovať fázy procesu a potom vykonať rozklad týchto fáz. Ale kvôli prehľadnosti by som rád ukázal náš „rozprávkový“ proces celý na jednom diagrame, pričom samozrejme musíme zabezpečiť, aby sa šípky „nezlepili“, bolo by možné presne sledovať, čo je spojené. k čomu.
Obrázok 2. Diagram aktivity - všeobecný pohľad na proces
Pretože v poetických líniách sú niektoré detaily procesu vynechané, bolo ich treba reštaurovať, zobrazujú ich prvky s bielym pozadím. Tieto podrobnosti zahŕňajú krok prenosu/prijatia na uloženie a spracovanie a niekoľko vstupných a výstupných artefaktov. Stojí za zmienku, že tento krok tiež úplne neodhaľuje proces, pretože museli by sme samostatne označiť krok prenosu a krok príjmu a dokonca pridať samostatný krok pre škrupiny a tiež si myslieť, že všetky tieto materiálne hodnoty by sa mali niekde dočasne uložiť atď. a tak ďalej.
Všimnime si tiež, že nezodpovedaná zostáva otázka pôvodu orechov – odkiaľ pochádzajú a ako sa dostanú k veveričke? A táto otázka (v poznámke je zvýraznená červeným písmom - prvok Poznámka) si vyžaduje samostatné štúdium! Takto pracuje analytik – zbiera informácie kúsok po kúsku, vytvára predpoklady a dostáva „dobre“ alebo „nie je v poriadku“ od odborníkov na danú problematiku – veľmi dôležitých a jednoducho nenahraditeľných ľudí vo fáze obchodného modelovania pri vytváraní systémov.
Všimnite si tiež, že procesný krok P5 pozostáva z dvoch častí.
A každú časť rozložíme a zvážime podrobnejšie (obrázok 3, obrázok 4), pretože činnosti vykonávané v rámci týchto konkrétnych krokov budú automatizované.
Obrázok 3. Schéma činnosti – detail (časť 1)
Obrázok 4. Schéma činnosti – detail (časť 2)
Fáza 2. Vyberte, čo sa dá automatizovať
Kroky, ktoré sa majú automatizovať, sú na diagramoch farebne zvýraznené (pozri obrázok 3, obrázok 4).
Všetky vykonáva jeden účastník procesu - úradník:
- Do výpisu zapíše informáciu o hmotnosti orecha;
- Do výpisu zapíše informáciu o prevode matice;
- Zaznamenáva skutočnosť premeny orecha na škrupinu a jadro;
- Do výpisu zadáva informácie o jadre orecha;
- Zadá informácie o škrupinách orechov do zoznamu.
Analýza vykonanej práce. Čo bude ďalej?
Urobili sme teda veľa prípravnej práce: zhromaždili sme informácie o procese, ktorý sa chystáme automatizovať; sa začala formovať dohoda o modelovaní (zatiaľ len v zmysle používania Diagramu aktivít); vykonal simuláciu procesu a dokonca rozložil niekoľko jeho krokov; Identifikovali sme kroky procesu, ktoré budeme automatizovať. Teraz sme pripravení prejsť na ďalšie kroky a začať navrhovať funkčnosť a vnútornú organizáciu systému.
Ako viete, teória bez praxe nie je ničím. Určite by ste si mali vyskúšať „modelovanie“ vlastnými rukami, čo je tiež užitočné na pochopenie navrhovaného prístupu. Môžete napríklad pracovať v prostredí modelovania [3]. Rozložili sme len časť krokov celkového diagramu procesu (pozri obrázok 2). Praktickou úlohou môže byť zopakovanie všetkých diagramov v prostredí Modelio a vykonanie rozkladu kroku „Prenos/Príjem na uloženie a spracovanie“.
O práci v špecifických modelovacích prostrediach zatiaľ neuvažujeme, no môže sa to stať predmetom nezávislých článkov a recenzií.
V druhej časti článku analyzujeme techniky modelovania a návrhu potrebné v etapách 3-5, použijeme UML Use-case a Class diagramy. Pokračovanie nabudúce.
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.
Zdroj: hab.com