„Egy nap a mókus életéből” vagy a folyamatok modellezésétől az „A mókus-1.0” automatikus anyagnyilvántartó rendszer tervezéséig (1. rész)
Miért éppen „mókus”?
Azonnal tisztázom, miért éppen „mókus”. Az interneten felfedezve szórakoztató projekteket az UML tanulmányozására, a mesehelyszínek felhasználásával (például, [1]), én is készítettem hasonló példát a diákjaim számára, hogy először háromféle diagramot tanulmányozhassanak: Tevékenységi diagram, Use-case diagram és Osztálydiagram. Szándékosan nem fordítom le az diagramok nevét oroszra, hogy elkerüljem a „fordítás nehézségeivel” kapcsolatos vitákat. Hogy mi micsoda – ezt később kicsit bővebben kifejtem. Ebben a példában az Enterprise Architect környezetet használom, amely az ausztrál [2] – jó eszköz ésszerű áron. Az oktatási foglalkozások keretében használom [3], egy elég jó ingyenes objektum-orientált tervező eszközt, amely támogatja az UML2.0 és BPMN szabványokat, anélkül, hogy túlzásba vinne bármilyen vizuális lehetőséget, de teljesen elegendő az alapnyelv tanulmányozásához.
Automatizálni szeretnénk az anyagok nyilvántartásával kapcsolatos tevékenységeket, amelyek ezekben a folyamatokban merülnek fel.
…
Sziget a tengeren fekszik, (E1, E2)
Város a szigeten áll (E3, E1)
Aranykupolás templomokkal, (E4)
Házakkal és kertekkel; (E5, E6)
Fenyő nő a palota előtt, (E7, E8)
És alatta kristályház; (E9)
Ott él a mókus, (A1)
Milyen ügyes is! (A1)
Mókus dalocskákat énekel, (P1, A1)
Csak a diót majszolja, (P2)
De a dió nem közönséges, (C1)
Csak arany héjjal, (C2)
Az ízük tiszta smaragdzöld; (C3)
A szolgák vigyázzák a mókust, (P3, A2)
Különféle szolgák segítenek neki (P4)
És egy szigorú írnok is (A3)
Számon tartják a diók számát; (P5, C1)
Megtisztelik a hadseregtől; (P6, A4)
A héjakból pénzt öntenek, (P7, C2, C4)
És szétszórják a világban; (P8)
A lányok smaragdot szórnak (P9, A5, C3)
A raktárba, és a spájzba; (E10, E11)
…
(A.S. Puskin "A Szaltán király meséje, dicső és hatalmas fia Gvidon Szaltanovics herceg és a gyönyörű hattyúhercegnő", — 10 év a gondolattól a publikációig, mindenesetre!)
Kicsit a kódokról, amelyek a sorok mellett vannak írva. Az „A” (az „Actor” rövidítése) azt jelenti, hogy a sor információt tartalmaz a folyamat résztvevőjéről. A „C” (az „Class” rövidítése) az eljárás során feldolgozott osztályok tárgyairól szóló információt jelent. Az „E” (a „Environment” rövidítése) a folyamatok végrehajtásának környezetét jellemző osztályok objektumairól szóló információkat tartalmaz. A „P” (a „Process” rövidítése) magáról a folyamatokról szóló információt jelent.
A pontos definíció folyamata szintén vitákat válthat ki, különböző okok miatt, mivel a folyamatok változatosak: üzleti, termelési, technológiai stb. (például itt is megismerhetjük, [4] és [5]). A polémia elkerülése érdekében állapodjunk meg abban, hogy a folyamat minket a megismételhetősége és az automatizálásra való igény szempontjából érdekel, azaz a folyamat végrehajtásának egyes műveleteit egy automatizált rendszerre hárítva.
Megjegyzések az Activity diagram használatához
Kezdjük el modellezni a folyamatunkat, és ehhez használni fogjuk az Activity diagramot. Először is, magyarázzuk el, hogyan fogják a fent említett kódok használni a modellben. Egyszerűbb grafikus példán keresztül megmagyarázni, és közben áttekintünk néhány (majdnem mindegyik szükséges) elemet az Activity diagramból.
Elemezzük a következő részt:
…
Mókus dalocskákat énekel, (P1, A1)
Csak a diót majszolja, (P2)
De a dió nem közönséges, (C1)
Csak arany héjjal, (C2)
Az ízük tiszta smaragdzöld; (C3)
…
Van két lépése a P1 és P2 folyamatnak, a résztvevő A1, és három különböző osztályú objektum: a C1 osztályú objektum belép a lépésbe, a C2 és C3 osztályú objektumok pedig kilépnek, mint a P2 lépés működésének eredménye. Az ábrázoláshoz az alábbi modellező elemeket használjuk.
Folyamatunk részét körülbelül így állíthatjuk össze (1. ábra).
1. ábra. Activity diagram részlet
A tér szervezéséhez és az Activity diagram struktúrájának megalkotásához nem éppen a klasszikus UML jelölés használatát követjük. Ennek több oka van. Először is, a modellezés megkezdése előtt elkészítjük a úgynevezett modellezési megállapodást, amelyben rögzítjük a jelölés használatának minden sajátosságát. Másodszor, ezt a megközelítést számos alkalommal sikeresen alkalmazták az üzleti modellezés szakaszában a szoftverrendszer fejlesztési valós projektek során, az eredményeket egy kis szerzői csoportunk rögzítette a megfelelő szerzői jogi objektumban [6], és a tanulmányi segédanyagot [7] is felhasználva. Az Activity diagram esetében meghatározzuk, hogy a diagram területét úgy strukturáljuk, hogy "úszó" sávokat használunk - Swim lanes. A sáv neve az ezen a sávon elhelyezett diagram elemek típusát fogja tükrözni.
"Bemeneti és kimeneti artefaktumok": Ezen a pályán fognak elhelyezkedni az Objects elemek – azok az objektumok, amelyek egy folyamat lépésének végrehajtásához szükségesek vagy annak eredményei.
„Folyamatlépések”: ide helyezjük el az Activity elemeket – a folyamat résztvevőinek tevékenységeit.
„Résztvevők”: pálya az elemek számára, amelyek a tevékenységek végrehajtóinak szerepeit fogják jelölni a folyamatunkban; számukra ugyanazt a modellező elemet, az Object – objektumot fogjuk használni, de hozzáadjuk a „Szereplő” sztereotípust.
A következő pálya neve „Üzleti szabályok” és ezen a pályán szöveges formában fogják elhelyezni a folyamatlépések végrehajtásának szabályait, erre a modell elemet, a Note – megjegyzést fogjuk használni.
Itt megállunk, bár további pályát is felhasználhatnánk „Eszközök” az automatizálás szintjéről szóló adatok gyűjtésére. Még hasznos lehet a pálya „A résztvevők hivatalos beosztásai és osztályai”, amelyet a szerepek és a résztvevők hivatalos beosztásai és osztályai közötti kapcsolatban lehet használni.
Mindez, amit éppen leírtam, és egy részét képezi a modellezési megállapodásnak, ez a megállapodás részben a diagram megszervezésének szabályaira vonatkozik, ezáltal a megírásának és olvasásának szabályaira.
„Recept”
Most nézzük meg a rendszer modellezési lehetőségét éppen az Activity diagrammától. Ez csupán az egyik lehetőség; megjegyzem, hogy ez természetesen nem az egyetlen. Az Activity diagram minket azzal a céllal érdekel, hogy a folyamat modellezéséből az automatizált rendszer tervezésére térjünk át. Ehhez követni fogjuk a metodikai ajánlásokat – egyfajta receptet, amely mindössze öt lépésből áll, és háromféle diagram kidolgozását írja elő. Ennek a receptnek az alkalmazása segít formális leírást kapni ahhoz a folyamathoz, amelyet automatizálni szeretnénk, ésadatokat gyűjteni a rendszer tervezéséhez. A kezdő UML-tanulók számára ez egyfajta mentőöv, amely megakadályozza, hogy elmerüljön az UML és a modern modellezési eszközök sokféleségében.
Itt van tehát maga a recept, utána következnek a diagramok, amelyeket a mi „mesebeli” tárgykörünkhöz építettek.
1. lépés. A folyamatot Activity diagram formájában írjuk le. Ha a folyamat több mint 10 lépésből áll, érdemes az alprocessz lépéseinek elvét alkalmazni a diagram olvashatóságának növelése érdekében.
2. lépés. Kijelöljük, ami automatizálható. (a lépések például kiemelhetők a diagramon).
3. lépés. Az automatizált lépéshez egy vagy több funkciót kell hozzárendelni a rendszerhez. (a kapcsolat lehet sok-a-sokhoz), elkészítjük az Use-case diagramot. Ezek a rendszerünk funkciói.
4. lépés. Az AS belső szervezetének leírása osztálydiagram segítségével – Osztály. A „Bemenetek és kimenetek (dokumentumok)” úszómedencéje az Activity diagramon az objektummodell és az entitás-kapcsolati modell alapja.
5. lépés. Elemzés a „Üzleti szabályok” sávon található jegyzetekről, különböző korlátozásokat és feltételeket adnak, fokozatosan átalakulva nem funkcionális követelményekké.
A kapott diagramok (Activity, Use-case, Class) összessége formális leírást ad egy elég pontos notációban, azaz egyértelműen értelmezhető. Most már fejleszthetjük a műszaki követelményeket, pontosíthatjuk a követelmény specifikációt stb.
Kezdjük a modellezést.
1. lépés. A folyamatot Activity diagram formájában írjuk le.
Emlékeztetnék, hogy a diagram mezőjét „úszó” sávokkal strukturáltuk, minden sávban egyféle elemet helyeztünk el (2. ábra). Az eddig ismertetett diagram elemein kívül további elemeket is használni fogunk, nézzük meg ezeket.
A Döntés (Decision) a diagramon a folyamatunk elágazási pontját jelöli, míg az áramlások összeolvadása (Merge) – a pontot, ahol újra összefonódnak. Az átmeneteknél négyzetes zárójelek között vannak az átmeneti feltételek.
Két szinkronizáló (Fork) között párhuzamos folyamatágakat fogunk megjeleníteni.
A folyamatunknak csak egy kezdete lehet – egy belépési pont (Initial). Viszont befejezése (Final) lehet több is, de nem a mi konkrét diagramunk esetében.
Elég sok nyíl keletkezik, ha sok elem és kapcsolat van, először a folyamat lépéseit érdemes kiemelni, és csak aztán végezni el e lépések dekompozícióját. De a „mesebeli” folyamatomat szeretném egy ábrán átláthatóbbá tenni, természetesen arra törekedve, hogy a nyilak „ne összeragadjanak”, és pontosan nyomon lehessen követni, hogy mi mivel áll összefüggésben.
2. ábra. Activity diagram – a folyamat általános áttekintése
Mivel a verssorokban bizonyos részletek el lettek hagyva, ezeket később pótolni kellett, amelyek fehér háttérrel jelennek meg. Ezek a részletek tartalmazzák a "Tárolásra/feldolgozásra történő átadás/fogadás" lépést, valamint néhány belépő és kilépő artefaktumot. Meg kell említeni, hogy ez a lépés sem fedi le teljesen a folyamatot, mivel külön kellene jelölnünk az átadás és a fogadás lépéseit, és még a héjak számára is hozzáadni külön lépést, nem is beszélve arról, hogy ezek az anyagi javak először valahol ideiglenesen tárolva kell legyenek, stb.
Ezen kívül felhívjuk a figyelmet arra, hogy még mindig válasz nélkül maradt a kérdés a diók származásáról – honnan származnak és hogyan kerülnek a mókushoz? Ez a kérdés (piros betűszínnel kiemelve a megjegyzésben – Note elem) külön kidolgozást igényel! Így dolgozik az elemző – információt összegyűjtve, feltételezéseket téve, és elfogadva az "oké" vagy "nem-oké" válaszokat a tárgyi szakterület szakértőitől – ezek az emberek nagyon fontosak és pótolhatatlanok a rendszer üzleti modelljének kialakítása során.
Arra is figyelmet fordítunk, hogy a P5 folyamat lépése két részből áll.
Minden részt dekomponálunk és részletesebben megvizsgálunk (3. ábra, 4. ábra), mivel a pontosan ezekben a lépésekben végzett tevékenységeket automatizálni fogják.
3. ábra. Activity diagram – részletezés (1. rész)
4. ábra. Activity diagram – részletezés (2. rész)
2. lépés. Kijelöljük, ami automatizálható.
A diagrammokon az automatizálásra váró lépéseket színekkel jelölik (lásd 3. ábra, 4. ábra).
Ezt mind egyetlen folyamat résztvevője, a parancsnok végezte:
- Az dió súlyának információját bejegyzi a nyilvántartásba;
- A dió átadásának információját bejegyzi a nyilvántartásba;
- Rögzíti a dió héjjá és a maggá alakulásának tényét;
- A dió magjának információját bejegyzi a nyilvántartásba;
- A dió héjjának információját bejegyzi a nyilvántartásba.
A végzett munka elemzése. Mi a következő lépés?
Tehát, rengeteg előkészítő munkát végeztünk: összegyűjtöttük az automatizálni kívánt folyamat információit; elkezdtük a modellezési megállapodás megformálását (bár eddig csak az Activity diagram használatára vonatkozóan); modelleztük a folyamatot, sőt néhány lépését is lebontottuk; kiemeltük azokat a folyamatlépéseket, amelyeket automatizálni fogunk. Most készen állunk a következő lépésekre, hogy elkezdjük a rendszer funkcióinak és belső struktúrájának tervezését.
Ahogy az köztudott, a elmélet gyakorlat nélkül semmi. Feltétlenül ki kell próbálni a "modellezést" saját kezűleg, ez hasznos a javasolt megközelítés megértéséhez is. Például lehet dolgozni a modellezési környezetben. [3]. Csak a folyamat általános lépéseinek részét bontottuk le (lásd az 2. ábrát). Gyakorlati feladatként javasolt lehet az összes diagram megismétlése a Modelio környezetében és a „Tárolás/raktározás és feldolgozás átvétele” lépés lebontása.
A konkrét modellezési környezetekkel való munkát egyelőre nem vizsgáljuk, de ez önálló cikkek és áttekintések alapjául szolgálhat.
A cikk második részében a modellezési és tervezési technikákat fogjuk megvizsgálni, amelyek a 3-5 lépéshez szükségesek, UML Use-case és Class diagramokat fogunk használni. Folytatás következik.
Irodalomjegyzék
- UML2.ru weboldal. Elemzők közösségi fóruma. Általános rész. Példák. Példák mesékre, amelyek UML diagram formájában vannak elkészítve. [Elektronikus forrás] Hozzáférés módja: Internet:
- Sparx Systems weboldal. [Elektronikus forrás] Hozzáférés módja: Internet:
- Modelio weboldal. [Elektronikus forrás] Hozzáférés módja: Internet:
- Nagy Enciklopédia. Folyamat (értelmezés). [Elektronikus forrás] Hozzáférés módja: Internet:
- A 'Hatékony Menedzsment Szervezésének' weboldala. Blog. 'Üzleti folyamatok irányítása' szekció. Üzleti folyamat meghatározása. [Elektronikus forrás] Hozzáférés módja: Internet:
- 18249. számú tanúsítvány a szellemi alkotás eredetének regisztrálásáról és letételéről. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Az 'Enterprise Architect használatával történő tárgykör modellezése' című oktatási segédlet kézirata // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Üzleti folyamatok modellezése. — M.: KURS, NIIC INFRA-M, EBS Znanium.com. — 2017.
Forrás: habr.com
