„Jeden deň zo života veveričky“ alebo od modelovania procesov k navrhovaniu automatizovaného systému evidencie majetku „Veverička-1.0“ (Časť 1)
Aký má zmysel „veverička“?
Hneď vysvetlím, aký má zmysel „veverička“. Narazil(a) som na zábavné projekty na internete na štúdium UML s oporou na predmetovú oblasť prevzatú zo zápletiek rozprávok (napríklad, [1]), aj ja som sa pre svojich študentov rozhodol(a) pripraviť podobný príklad, aby sme mohli na začiatok preskúmať iba tri typy diagramov: Aktivita, Prípady použitia a Triedny diagram. Úmyselne neprekladám názvy diagramov do slovenčiny, aby som sa vyhol(a) sporom o „ťažkostiach prekladu“. Čo na čo je – vysvetlím trochu neskôr. V tomto príklade používam prostredie Enterprise Architect od austrálskej spoločnosti [2] – dobrý nástroj za rozumné peniaze. A v rámci vyučovania používam [3], slušný bezplatný nástroj pre objektovo-orientované navrhovanie, podporujúci štandardy UML 2.0 a BPMN, bez zbytočných vylepšení v oblasti grafických možností, ale celkom postačujúci na štúdium základov jazyka.
Automatizovať sa chystáme činnosť evidencie majetku, ktorá vzniká v týchto procesoch.
…
Ostrov na mori leží, (E1, E2)
Mesto na ostrove stojí (E3, E1)
S zlatými vežami, (E4)
S terasami a záhradami; (E5, E6)
Jedľa rastie pred palácom, (E7, E8)
A pod ňou kryštálový dom; (E9)
Veverička tam žije ručne, (A1)
A aká je svojská! (A1)
Veverička piesne spieva, (P1, A1)
A oriešky stále hryzie, (P2)
A oriešky nie sú obyčajné, (C1)
Všetky škrupinky sú zlaté, (C2)
Jadro jasný smaragd; (C3)
Služobníci veveričku strážia, (P3, A2)
Služia jej rôznymi spôsobmi (P4)
A je priradený prísny dyakon (A3)
Prísne účtovanie orieškov je; (P5, C1)
Vydáva jej vojenskú česť; (P6, A4)
Z škrupín liajú mincu, (P7, C2, C4)
A púšťajú ju do sveta; (P8)
Dievčatá sypú smaragd (P9, A5, C3)
Do skladov, a pod hrách; (E10, E11)
…
(A.S. Puškina "Rozprávka o царе Салтане, o jeho slávnom synovi a mocnom bohatierovi kniežaťovi Gvidonovi Saltanoviči a o krásnej princeznej Labute", — 10 rokov od myšlienky po publikáciu, mimochodom!)
Trochu o kódoch, ktoré sú napísané napravo od riadkov. „A“ (z „Actor“) znamená, že v riadku sa nachádzajú informácie o účastníkovi procesu. „C“ (z „Class“) – informácie o objektoch tried, ktoré sú spracovávané v priebehu vykonávania procesov. „E“ (z „Environment“) – informácie o objektoch tried, ktoré charakterizujú prostredie vykonávania procesov. „P“ (z „Process“) – informácie o samotných procesoch.
Mimochodom, presná definícia procesu si tiež nárokuje, aby sa stala predmetom metodologických sporov, aspoň preto, že procesy môžu byť rôzne: obchodné, výrobné, technologické a pod. (možno sa oboznámiť napríklad, [4] a [5]). Aby sme sa vyhli polemike, dohodnime sa, že proces nás zaujíma z pohľadu jeho opakovateľnosti v čase a potreby automatizácie, t.j. prenesenie vykonania nejakej časti operácií procesu na automatizovaný systém.
Poznámky k aplikácii diagramu Activity
Začneme modelovať náš proces a využijeme na to diagram Activity. Najprv vysvetlím, ako uvedené kódy budú použité v modeli. Vysvetľovať sa to lepšie na grafickom príklade a zároveň rozoberieme niektoré (takmer všetky z potrebných) prvky diagramu Activity.
Analyzujme nasledujúci fragment:
…
Veverička piesne spieva, (P1, A1)
A oriešky stále hryzie, (P2)
A oriešky nie sú obyčajné, (C1)
Všetky škrupinky sú zlaté, (C2)
Jadro jasný smaragd; (C3)
…
Máme dva kroky procesu P1 a P2, účastníka A1 a objekty troch rôznych tried: objekt triedy C1 prichádza na vstup kroku, objekty tried C2 a C3 sú získané na výstupe ako výsledok činnosti tohto kroku P2 nášho procesu. Pre diagram použijeme nasledujúce modelovacie prvky.
Fragment nášho procesu môžeme predstaviť približne takto (Obrázok 1).
Obrázok 1. Fragment diagramu Activity
Na organizáciu priestoru a štruktúrovanie diagramu Activity použijeme nie úplne štandardný prístup z pohľadu klasického použitia notácie UML. Ale na to existuje niekoľko dôvodov. Po prvé, pred začiatkom modelovania si vytvoríme tzv. dohodu o modelovaní, v ktorej zaznamenáme všetky zvláštnosti použitia notácie. Po druhé, tento prístup bol opakovane úspešne aplikovaný v etape obchodného modelovania v reálnych projektoch na vytvorenie softvérových systémov, výsledky boli zaznamenané naším malým autorským kolektívom v príslušnom objekte autorského práva [6], ako aj použité v učebnici [7]. Pre diagram Activity určíme, že pole diagramu štrukturujeme pomocou „plávajúcich“ dráh – Swim lanes. Názov dráhy bude zodpovedať typu prvkov diagramu, ktoré budú umiestnené na tejto dráhe.
„Vstupné a výstupné artefakty“: Na tej dráhe budú umiestnené prvky Objects – objekty, ktoré sa používajú alebo sú výsledkom vykonania určitého kroku procesu.
„Kroky procesu“: Sem umiestnime prvky Activity – činnosti účastníkov procesu.
„Účastníci“: Dráha pre prvky, ktoré budú označovať úlohy vykonávateľov činností v našom procese, pre nich budeme používať rovnaký modelovací prvok Object – objekt, ale pridáme mu stereotyp „Actor“.
Nasledujúca dráha sa nazýva „Obchodné pravidlá“ a na tejto dráhe umiestnime textové pravidlá vykonávania krokov procesu, pričom na to použijeme modelovací prvok Note – poznámku.
Tu sa zastavíme, aj keď by sa dalo pridať ešte dráhu „Nástroje“ na zhromažďovanie informácií o úrovni automatizácie procesu. Môže sa hodiť aj dráha „Pozície a organizačné jednotky účastníkov“, ktorú možno použiť na prepojenie úloh s pozíciami a organizačnými jednotkami účastníkov procesu.
Všetko, čo som práve opísala, je fragment dohody o modelovaní, táto časť dohody sa týka pravidiel organizácie jednej diagramu a príslušne pravidiel jej písania a čítania.
„Recept“
Teraz sa pozrime na variant modelovania systému presne od diagramu Activity. Je to len jeden z variantov, upozorňujem, že samozrejme nie je jediný. Diagram Activity nás bude zaujímať z hľadiska jej úlohy pre prechod od modelovania procesu k návrhu automatizovaného systému. Pre tento účel sa budeme riadiť metodickými odporúčaniami – akýmsi receptom, ktorý sa skladá z piatich krokov a predpokladá vypracovanie troch druhov diagramov. Použitie tohto receptu pomôže získať formalizovaný popis procesu, ktorý chceme automatizovať, a zhromaždiť údaje pre návrh systému. A pre študentov na začiatku štúdia UML je to akýsi záchranný kruh, ktorý nenechá tonúť vo všetkej tej rozmanitosti obrazových prostriedkov a techník, ktoré existujú v UML a moderných modelovacích nástrojoch.
Toto je vlastne samotný recept, a ďalej nasledujú diagramy zostavené pre našu „rozprávkovú“ predmetnú oblasť.
Krok 1. Popíšeme proces vo forme diagramu Activity. Pre proces, ktorý má viac ako 10 krokov, má zmysel aplikovať princíp dekompozície krokov procesu, aby sa zvýšila čitateľnosť diagramu.
Fáza 2. Identifikujeme to, čo je možné automatizovať. (kroky môžu byť napríklad vyznačené na diagrame).
Fáza 3. Automatizovanej úlohe je potrebné priradiť funkciu alebo funkcie systému. (vzťah môže byť mnohonásobný), kreslíme Use-case diagram. Toto sú funkcie nášho systému.
Fáza 4. Opíšeme vnútornú organizáciu AS prostredníctvom diagramu tried. – Class. Plávacia dráha „Vstupné a výstupné objekty (dokumenty)“ na Activity diagrame je základom pre vytvorenie objektového modelu a modelu entita-vzťah.
Krok 5. Analyzujeme poznámky na línii „Obchodné pravidlá“, poskytujú rôzne obmedzenia a podmienky, postupne sa transformuje na nefunkčné požiadavky.
Získaná sústava diagramov (Activity, Use-case, Class) nám poskytuje formalizovaný popis v dostatočne prísnej notácii, t.j. má jednoznačné čítanie. Teraz môžeme vypracovať technickú špecifikáciu, spresniť požiadavky atď.
Prejdime k modelovaniu.
Fáza 1. Opisujeme proces vo forme Activity diagramu.
Pripomínam, že pole diagramu sme štruktúrovali pomocou „plávajúcich“ dráh, na každej dráhe sú umiestnené prvky rovnakého typu (Obrázok 2). Okrem vyššie opísaných prvkov diagramu budeme používať aj ďalšie prvky, poďme ich popísať.
Riešenie (Decision) označuje na diagrame bod rozvetvenia nášho procesu, zatiaľ čo spojenie tokov (Merge) je bod ich opätovného spojenia. V zátvorkách na prechodoch sú uvedené podmienky prechodu.
Medzi dvoma synchronizátormi (Fork) budeme zobrazovať paralelné vetvy procesu.
Náš proces môže mať len jeden začiatok – jeden vstup (Initial). Avšak ukončení (Final) môže byť viac, ale nie pre náš konkrétny diagram.
Šípok vzniká dosť veľa, pri veľkom počte prvkov a spojení môžeme najprv vyčleniť etapy procesu a potom sa zamerať na dekompozíciu týchto etáp. Ale náš „rozprávkový“ proces by som rád prehľadne zobrazil celkom na jednom diagrame, pričom je potrebné zabezpečiť, aby sa šípky „nespájali“, aby sa dalo presne sledovať, čo s čím súvisí.
Obrázok 2. Activity diagram – celkový pohľad na proces
Keďže v básnických veršoch sú niektoré detaily procesu vynechané, museli sme ich obnoviť, sú znázornené prvkami s bielym pozadím. Tieto detaily zahŕňajú krok „Prenosu/prijatia na skladovanie a spracovanie“ a niekoľko vstupných a výstupných artefaktov. Je potrebné poznamenať, že tento krok tiež úplne neodhaľuje proces, pretože by sme museli samostatne označiť krok prenosu a krok prijatia, a navyše pridať samostatný krok pre škrupiny, a ešte vymyslieť, že všetky tieto materiálne hodnoty by mali niekde dočasne skladovať atď.
Ešte si všimneme, že otázka pôvodu orechov – odkiaľ sa berú a ako sa dostávajú k veveričke – zatiaľ zostáva bez odpovede. A táto otázka (vyčlenená červenou farbou písma v poznámke – prvok Note) si vyžaduje samostatné spracovanie! Takto funguje analytik – zbierajúc informácie po zrniečkach, robí predpoklady a dostáva „OK“ alebo „nie-OK“ od odborníkov v predmetnej oblasti – veľmi dôležitých a jednoducho nenahraditeľných ľudí v štádiu obchodného modelovania pri tvorbe systémov.
Všimneme si tiež, že krok procesu P5 pozostáva z dvoch častí.
A každú časť rozložíme a podrobnejšie sa na ňu pozrieme (Obrázok 3, Obrázok 4), pretože činnosť vykonávaná v rámci týchto krokov bude automatizovaná.
Obrázok 3. Diagram aktivity – detailizácia (časť 1)
Obrázok 4. Diagram aktivity – detailizácia (časť 2)
Fáza 2. Identifikujeme to, čo je možné automatizovať.
Kroky, ktoré podliehajú automatizácii, sú na diagramoch vyznačené farbou (pozri Obrázok 3, Obrázok 4).
Všetko vykonáva jeden účastník procesu – Djak príkazný:
- Zaznamenáva informácie o hmotnosti orecha do evidencie;
- Zaznamenáva informácie o predaji orecha do evidencie;
- Zaznamenáva fakt premeny orecha na škrupinky a jadro;
- Zaznamenáva informácie o jadre orecha do evidencie;
- Zaznamenáva informácie o škrupinkách orecha do evidencie.
Analýza vykonanej práce. Čo ďalej?
Takže sme vykonali veľa prípravnej práce: zhromaždili informácie o procese, ktorý plánujeme automatizovať; začali sme vytvárať dohodu o modelovaní (zatiaľ len v časti využívania diagramu aktivít); vykonali sme modelovanie procesu a dokonca sme rozložili niekoľko jeho krokov; vyčlenili sme kroky procesu, ktoré budeme automatizovať. Teraz sme pripravení prejsť k ďalším fázam a začať navrhovať funkcie systému a jeho vnútornú organizáciu.
Ako je známe, teória bez praxe je nič. Určite je potrebné vyskúšať "modelovanie" na vlastnej koži, je to užitočné pre porozumenie navrhnutému prístupu. Napríklad, môžete pracovať v prostredí modelovania. [3]. Rozložili sme iba časť krokov diagramu celkového vzhľadu procesu (pozri Obrázok 2). Ako praktická úloha môže byť navrhnuté zopakovať všetky diagramy v prostredí Modelio a vykonať rozloženie kroku „Zasielanie/prijímanie na uskladnenie a spracovanie“.
Prácu v konkrétnych prostrediach modelovania zatiaľ nezvažujeme, ale to môže byť predmetom samostatných článkov a prehľadov.
V druhej časti článku sa budeme zaoberať technikami modelovania a projektovania, ktoré sú potrebné v 3-5 fázach, budeme používať UML diagramy Use-case a Class. Pokračovanie nasleduje.
Zoznam zdrojov
- Webstránka „UML2.ru“. Fórum Spoločenstva analytikov. Všeobecná sekcia. Príklady. Príklady rozprávok usporiadaných vo forme UML diagramov. [Elektronický zdroj] Prístup: Internet:
- Webstránka Sparx Systems. [Elektronický zdroj] Prístup: Internet:
- Webstránka Modelio. [Elektronický zdroj] Prístup: Internet:
- Veľký encyklopedický slovník. Proces (výklad). [Elektronický zdroj] Prístup: Internet:
- Webstránka „Organizácia efektívneho riadenia“. Blog. Rubrika „Riadenie biznis procesmi“. Definícia biznis procesu. [Elektronický zdroj] Prístup: Internet:
- Osvedčenie č. 18249 o registrácii a depozite diela výsledku duševnej činnosti. Alfimov R.V., Zolotukhina E.B., Krasnikov S.A. Rukopis učenia a metodického materiálu s názvom „Modelovanie predmetnej oblasti s použitím Enterprise Architect“ // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikov S.A. Modelovanie biznis procesov. — M.: KURS, NÍC INFRA-M, EBS Znanium.com. — 2017.
Zdroj: habr.com
