„Egy nap egy mókus életében” vagy a folyamatmodellezéstől a „Belka-1.0” automatizált vagyonelszámolási rendszer tervezéséig (1. rész)
Mi köze ehhez a „mókusnak”?
Mindjárt elmagyarázom, mi köze a „mókusnak” ehhez. Miután az interneten szórakoztató projektekre bukkantam az UML tanulására egy meséből kölcsönzött tantárgy alapján (pl. [1]), elhatároztam, hogy készítek egy hasonló példát a tanítványaim számára, hogy kezdetben csak háromféle diagramot tudjanak tanulmányozni: a tevékenységdiagramot, a használati eset diagramot és az osztálydiagramot. Szándékosan nem fordítom le a diagramok nevét oroszra, hogy elkerüljem a „fordítási nehézségekkel” kapcsolatos vitákat. Kicsit később elmagyarázom, mire való. Ebben a példában egy ausztrál cég Enterprise Architect keretrendszerét használom [2] – jó eszköz elfogadható áron. És az edzéseim részeként használom [3], egy jó ingyenes objektum-orientált tervezőeszköz, amely támogatja az UML2.0 és BPMN szabványokat, vizuális lehetőségeket tekintve felesleges csengők és sípok nélkül, de a nyelv alapjainak elsajátításához teljesen elegendő.
Automatizálni fogjuk az ezekben a folyamatokban felmerülő anyagi javak elszámolási tevékenységét.
...
Egy sziget fekszik a tengeren, (E1, E2)
Jégeső van a szigeten (E3, E1)
Aranykupolás templomokkal, (E4)
Tornyokkal és kertekkel; (E5, E6)
A palota előtt lucfenyő nő, (E7, E8)
És alatta egy kristályház; (E9)
Egy szelíd mókus él ott, (A1)
Igen, micsoda kaland! (A1)
A mókus dalokat énekel, (P1, A1)
Igen, folyamatosan rágcsálja a diót, (P2)
De a dió nem egyszerű, (C1)
Minden kagyló arany, (C2)
A mag tiszta smaragd; (C3)
A szolgák őrzik a mókust, (P3, A2)
Különféle szolgákként szolgálják (P4)
És kijelöltek egy ügyintézőt (A3)
A dió szigorú beszámolója a hír; (P5, C1)
A hadsereg üdvözli őt; (P6, A4)
A kagylókból egy érmét öntenek ki (P7, C2, C4)
Hadd járják körbe a világot; (P8)
Lányok smaragdot öntenek (P9, A5, C3)
A raktárakba, és fedél alá; (E10, E11)
...
(A.S. Puskin „Szaltán cár meséje, dicsőséges és hatalmas hőséről, Guidon Saltanovich hercegről és a gyönyörű Hattyú hercegnőről” – A koncepciótól a megjelenésig egyébként 10 év!)
Egy kicsit a kódokról, amelyek a sorok jobb oldalán vannak írva. Az „A” (a „szereplő” szóból) azt jelenti, hogy a sor a folyamat egy résztvevőjéről tartalmaz információkat. „C” (a „Class” szóból) – információ a folyamatok végrehajtása során feldolgozott osztályobjektumokról. „E” (a „Környezetből”) – információ az osztályobjektumokról, amelyek jellemzik a környezetet a folyamatok végrehajtásához. „P” (a „Folyamat” szóból) – információk magukról a folyamatokról.
Egyébként a folyamat pontos meghatározása is módszertani viták okának vallja magát, már csak azért is, mert különböző folyamatok vannak: üzleti, termelési, technológiai stb. stb. (megtudhatod pl. [4] és [5]). A viták elkerülése végett ebben egyezzünk meg Minket a folyamat az időbeli megismételhetőség és az automatizálás szükségessége szempontjából érdekel, azaz a folyamatműveletek bármely részének végrehajtását egy automatizált rendszerbe átvinni.
Megjegyzések a tevékenységdiagram használatához
Kezdjük el modellezni folyamatunkat, és ehhez használjuk a Tevékenység diagramot. Először is hadd magyarázzam el, hogyan fogják használni a fenti kódokat a modellben. Egyszerűbb egy grafikus példával elmagyarázni, ugyanakkor elemezzük a Tevékenység diagram néhány elemét (majdnem mindegyik, amire szükségünk van).
Elemezzük a következő részletet:
...
A mókus dalokat énekel, (P1, A1)
Igen, folyamatosan rágcsálja a diót, (P2)
De a dió nem egyszerű, (C1)
Minden kagyló arany, (C2)
A mag tiszta smaragd; (C3)
...
Két P1 és P2 folyamatlépésünk van, az A1 résztvevő, valamint három különböző osztályú objektumunk: a lépésbe egy C1 osztályú objektum kerül be, a C2 és C3 osztályú objektumok pedig ennek a P2 lépésnek a tevékenysége eredményeként kerülnek kiadásra. folyamat. A diagramhoz a következő modellező elemeket használjuk.
A folyamatunk egy töredéke így ábrázolható (1. ábra).
1. ábra Tevékenység diagram töredék
Az Activity diagram térének rendezésére és strukturálására az UML jelölés klasszikus használata szempontjából nem szabványos megközelítést alkalmazunk. De ennek több oka is van. Először közvetlenül a modellezés megkezdése előtt összeállítjuk az ún modellezési megállapodás, amelyben rögzítjük a jelölés használatának összes jellemzőjét. Másodszor, ezt a megközelítést ismételten sikeresen alkalmazták az üzleti modellezés szakaszában valós projektekben szoftverrendszerek létrehozására; az eredményeket kis szerzői csapatunk rögzítette a megfelelő szerzői jogi objektumban [6], és egy oktatási kézikönyvben is felhasználta [7]. XNUMX]. A tevékenységdiagram esetében meghatározzuk, hogy a diagrammező „úszósávok” alapján épül fel. A sáv neve megfelel az adott sávon elhelyezett diagramelemek típusának.
"Bemeneti és kimeneti melléktermékek": Ez a sáv Objects elemeket fog tartalmazni – olyan objektumokat, amelyeket használtak vagy valamilyen folyamatlépés végrehajtásának eredményeként jöttek létre.
"A folyamat lépései": Itt helyezzük el a tevékenységelemeket - a folyamat résztvevőinek cselekedeteit.
"Résztvevők": útvonal azokhoz az elemekhez, amelyek az akcióvégzők szerepét jelölik a folyamatunkban; ezekhez ugyanazt az Object - objektumot - modellező elemet fogjuk használni, de hozzáadjuk a „színész” sztereotípiát.
A következő számot hívják "Üzleti szabályok" ezen a sávon pedig szöveges formában helyezzük el a folyamat lépéseinek végrehajtási szabályait, ehhez pedig a Note - megjegyzés modellező elemet használjuk.
Itt megállunk, bár az utat is használhatnánk "Eszközök" hogy információkat gyűjtsünk a folyamatautomatizálás szintjéről. Egy út is jól jöhet "A résztvevők beosztása és felosztása", a szerepek összekapcsolására használható a folyamat résztvevőinek pozícióihoz és osztályaihoz.
Minden, amit az imént leírtam, töredék modellezési konvenciók, a megállapodás ezen része egy diagram rendezésének szabályaira, és ennek megfelelően annak megírására és olvasására vonatkozó szabályokra vonatkozik.
"Recept"
Most nézzük meg a rendszer konkrét modellezésének lehetőségét a tevékenység diagramból. Ez csak egy a lehetőségek közül, megjegyzem, természetesen nem az egyetlen. Az Activity diagram a folyamatmodellezésről az automatizált rendszer tervezésére való átmenetben betöltött szerepe szempontjából érdekel majd bennünket. Ehhez ragaszkodunk a módszertani ajánlásokhoz - egyfajta recepthez, amely mindössze öt szakaszból áll, és csak háromféle diagram kidolgozását biztosítja. Ennek a receptnek a használata segít abban, hogy formalizált leírást kapjunk az automatizálni kívánt folyamatról, és adatokat gyűjtsünk a rendszertervezéshez. Az UML tanulmányozásának kezdetén tanuló diákok számára ez egyfajta mentőeszköz, amely nem engedi, hogy belefulladjanak az UML-ben és a modern modellező eszközökben található vizuális eszközök és technikák sokféleségébe.
Itt van tulajdonképpen maga a recept, majd kövessük a „mese” témakörünkhöz épített diagramokat.
1. szakasz. A folyamatot tevékenységdiagram formájában írjuk le. A 10-nél több lépésből álló folyamatok esetén célszerű a folyamatlépés-bontás elvét alkalmazni a diagram olvashatóságának javítása érdekében.
2. szakasz. Válassza ki, hogy mit lehet automatizálni (a lépések például diagramon kiemelhetők).
3. szakasz. Az automatizált lépést a rendszer funkciójához vagy funkcióihoz kell társítani (a kapcsolat lehet sok-sok), rajzoljon egy használati eset diagramot. Ezek a mi rendszerünk funkciói.
4. szakasz. Írjuk le az AS belső szervezetét egy osztálydiagram segítségével - Osztály. A Tevékenység diagramban szereplő „Bemeneti és kimeneti objektumok (dokumentumok)” úszópálya az objektummodell és az entitás-kapcsolat modell felépítésének alapja.
5. szakasz. Elemezzük az „Üzleti szabályok” sáv megjegyzéseit, különféle korlátozásokat és feltételeket biztosítanak, amelyek fokozatosan nem funkcionális követelményekké alakulnak.
Az így kapott diagramkészlet (Activity, Use-case, Class) formalizált leírást ad nekünk egy meglehetősen szigorú jelöléssel, azaz. egyértelmű olvasata van. Most már kidolgozhat műszaki specifikációkat, pontosíthatja a követelmények specifikációit stb.
Kezdjük a modellezést.
1. szakasz. Ismertesse a folyamatot tevékenységdiagram formájában
Hadd emlékeztessem önöket, hogy a diagrammezőt „úszó” sávok felhasználásával strukturáltuk, minden sáv azonos típusú elemeket tartalmaz (2. ábra). A fent ismertetett diagramelemeken kívül további elemeket fogunk használni, ezeket írjuk le.
A Döntés (Decision) folyamatunk elágazási pontját jelöli az ábrán, a szálak összevonása (Merge) pedig az újraegyesítésük pontját. Az átmenetekre szögletes zárójelbe írjuk az átmenet feltételeit.
Két szinkronizáló (Fork) között párhuzamos folyamatágakat fogunk mutatni.
A folyamatunknak csak egy kezdete lehet - egy belépési pontja (kezdeti). De lehet több befejezés (végső), de nem a mi konkrét diagramunkhoz.
Elég sok nyíl van, sok elem és kapcsolat esetén először azonosíthatja a folyamat szakaszait, majd ezeket a szakaszokat lebonthatja. De az érthetőség kedvéért szeretném teljes egészében egy diagramon bemutatni a „mesebeli” folyamatunkat, miközben természetesen ügyelnünk kell arra, hogy a nyilak „ne tapadjanak össze”, pontosan nyomon követhető legyen, hogy mi kapcsolódik mire.
2. ábra Tevékenység diagram – a folyamat általános képe
Mert a költői sorokban a folyamat egyes részletei kimaradnak, ezeket helyre kellett állítani, fehér hátterű elemek mutatják meg. Ezek a részletek magukban foglalják az átvitel/fogadás tároláshoz és feldolgozáshoz lépést, valamint számos bemeneti és kimeneti műterméket. Érdemes megjegyezni, hogy ez a lépés sem fedi fel teljesen a folyamatot, mert külön ki kell jelölnünk az átviteli és a vételi lépést, sőt a kagylók számára külön lépést kell hozzáadni, és arra is gondolni, hogy először ezeket az anyagi értékeket ideiglenesen el kell tárolni valahol stb. stb.
Vegyük észre azt is, hogy a dió eredetének kérdése megválaszolatlan marad – honnan származnak és hogyan jutnak el a mókushoz? És ez a kérdés (a jegyzetben piros betűvel van kiemelve - a Megjegyzés elem) külön tanulmányozást igényel! Így működik egy elemző – apránként gyűjti az információkat, feltételezéseket fogalmaz meg, és megkapja az „oké” vagy „nem-oké”-t a téma szakértőitől - nagyon fontos és egyszerűen pótolhatatlan embereket az üzleti modellezés szakaszában a rendszerek létrehozásakor.
Vegye figyelembe azt is, hogy a P5 folyamatlépés két részből áll.
És az egyes részeket felbontjuk, és részletesebben megvizsgáljuk (3. ábra, 4. ábra), mert az ezeken a lépéseken belül végzett tevékenységek automatizálódnak.
3. ábra Tevékenységi diagram – részletezés (1. rész)
4. ábra Tevékenységi diagram – részletezés (2. rész)
2. szakasz. Válassza ki, hogy mit lehet automatizálni
Az automatizálandó lépések színnel vannak kiemelve a diagramokon (lásd 3. ábra, 4. ábra).
Mindegyiket egy résztvevő végzi a folyamatban - a jegyző:
- Az anya súlyára vonatkozó információkat beírja a kimutatásba;
- Az anya átvitelére vonatkozó információkat beírja a kimutatásba;
- Rögzíti a dió héjává és magmá történő átalakulásának tényét;
- A dió magjával kapcsolatos információkat beírja az utasításba;
- Beírja a dióhéjra vonatkozó információkat a listába.
Az elvégzett munka elemzése. Mi a következő lépés?
Tehát rengeteg előkészítő munkát végeztünk: információkat gyűjtöttünk az automatizálni kívánt folyamatról; kezdett megállapodást kötni a modellezésről (egyelőre csak az Activity diagram használata tekintetében); elvégezte a folyamat szimulációját, sőt több lépését is lebontotta; Meghatároztuk azokat a folyamatlépéseket, amelyeket automatizálunk. Most már készen állunk arra, hogy továbblépjünk a következő lépésekre, és megkezdjük a rendszer funkcionalitásának és belső szervezetének tervezését.
Mint tudod, az elmélet gyakorlat nélkül semmi. Mindenképpen meg kell próbálnia a „modellezést” saját kezűleg, ez is hasznos a javasolt megközelítés megértéséhez. Például dolgozhat modellező környezetben [3]. A teljes folyamatábra lépéseinek csak egy részét bontottuk ki (lásd a 2. ábrát). Gyakorlati feladatként előfordulhat, hogy ismételje meg az összes diagramot a Modelio környezetben, és hajtsa végre az „Átadás/fogadás tároláshoz és feldolgozáshoz” lépés bontását.
Még nem fontolgatjuk, hogy konkrét modellezési környezetekben dolgozunk, de ez független cikkek és áttekintések témája lehet.
A cikk második részében a 3-5. szakaszban szükséges modellezési és tervezési technikákat elemezzük, UML használati eset- és osztálydiagramokat használunk. Folytatjuk.
Források listája
- Weboldal "UML2.ru". Elemzői Közösségi Fórum. Általános rész. Példák. Példák UML-diagramként formázott mesékre. [Elektronikus forrás] Hozzáférési mód: Internet:
- A Sparx Systems weboldala. [Elektronikus forrás] Hozzáférési mód: Internet:
- Modelio weboldal. [Elektronikus forrás] Hozzáférési mód: Internet:
- Nagy enciklopédikus szótár. Folyamat (értelmezés). [Elektronikus forrás] Hozzáférési mód: Internet:
- Weboldal "A hatékony gazdálkodás szervezése". Blog. "Üzleti folyamatmenedzsment" kategória. Az üzleti folyamat meghatározása. [Elektronikus forrás] Hozzáférési mód: Internet:
- 18249. számú igazolás a szellemi tevékenységet végző alkotás nyilvántartásba vételéről és letétbe helyezéséről. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. „Tárgyterület modellezése Enterprise Architect segítségével” című taneszköz kézirata // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Üzleti folyamatok modellezése. — M.: TANFOLYAM, SIC INFRA-M, EBS Znanium.com. — 2017.
Forrás: will.com