„Egy nap a mókus életéből” vagy a folyamatmodellezéstől az „1.0-s Mókus” anyagi értékek nyilvántartására tervezett automatizált rendszerig (2. rész)
Az előző epizód rövid összefoglalója
A mi a „mesebeli” tárgykört használtuk, inspirálódva az UML-diagramok tanulmányozásának példáival, amelyeket mesék cselekményei alapján dolgoztunk ki (lásd például [1]). A modellezés megkezdése előtt megállapodtunk néhány Activity-diagram elem használatáról, és elkezdtük a modellezési megállapodás kialakítását. Ezeket a megállapodásokat figyelembe véve az 1. lépésben a folyamatot Activity-diagramok formájában írtuk le, míg a 2. lépésben azokat a folyamatlépéseket emeltük ki, amelyek automatizálása szükséges (és lehetséges).
Emlékeztetem, hogy az anyagi értékek nyilvántartásának tevékenységét szeretnénk automatizálni, amely ezekben a folyamatokban merül 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, a fiáról, a híres és hatalmas hős Gvidon Szaltanovics fejedelemről és a gyönyörű hattyúhercegnőről”, )
Ebben a példában az ausztrál Sparx Systems cég Enterprise Architect környezetét használom, [2], míg az oktatási foglalkozások keretében alkalmazom [3].
Emlékeztetem, hogy a folyamatok különbözőek lehetnek, informálódj például, [4] és [5].
Részletesebben az alkalmazott modellezési és tervezési megközelítésekről lásd [6, 7].
A UML teljes specifikációja [8].
Most készen állunk a következő lépésekre, és megkezdhetjük a rendszer funkcióinak és belső szervezetének tervezését. A képek számozása folytatódik.
3. lépés. Az automatizált lépéshez egy vagy több funkciót kell hozzárendelni a rendszerhez.
Az fejlesztés alatt álló automatizált rendszer (AS) célja a diók szigorú nyilvántartása, emlékszel? Minden kiemelt lépéshez (lásd 3. ábra, 4. ábra) ), amelyet automatizálni fogunk, feljegyezzük a funkcionális követelményt, alkalmazva körülbelül a következő szerkezetet: "A rendszerben meg kell valósítani a lehetőséget..." és kidolgozzuk a Use-case diagramot. Jelenleg valójában kiegészítjük a modellezéssel kapcsolatos megállapodásunkat új szabályokkal. Megmagyarázom, hogy milyen elemeket fogunk használni.
A "Felhasználói szerep" és a "Funkció" között "Asszociáció" kapcsolatot használunk (5. ábra), ami azt jelenti, hogy az adott szereppel rendelkező felhasználó számára elérhető, hogy elvégezze az adott funkciót.
5. ábra. Az "Asszociáció" típusú kapcsolat használata
A "Funkció" és a "Követelmény" között "Megvalósítás" kapcsolatot vonunk (6. ábra), hogy megmutassuk, hogy ez a követelmény milyen funkciókkal valósul meg, a kapcsolat lehet "sok-sok" is, azaz egy funkció több követelmény megvalósításában részt vehet, és egy követelmény megvalósításához több funkcióra lehet szükség.
6. ábra. A "Megvalósítás" típusú kapcsolat használata
Ha egy funkció teljesítéséhez egy másik funkció teljesítése is szükséges, akkor "Függőség" kapcsolatot használunk az "Include" sztereotípiával – belefoglalás (7. ábra). Ha azonban egy kiegészítő funkció végrehajtása bizonyos feltételek mellett szükséges, akkor "Függőség" kapcsolatot használunk az "Extend" sztereotípiával – kiterjesztés. Nagyon könnyű megjegyezni: "Include" – Mindig, míg az "Extend" – Néha.
7. ábra. Az "Include (beleképzés)" típusú kapcsolat használata
Végül a diagramunk körülbelül így fog kinézni (8. ábra).
8. ábra. Use-case diagram (AS funkcionális modell)
Továbbá a Use-case diagram a felhasználói szerepek modellezésére is szolgál (9. ábra).
9. ábra. Use-case diagram (AS felhasználói szerepek)
4. lépés. Az AS belső szervezetének leírása osztálydiagram segítségével
A bejövő és kimenő artefaktumokkal kapcsolatos információk felhasználásával (lásd a Tevékenységi ábrákat - 2. ábra, 3. ábra, 4. ábra), elkészítjük az osztálydiagramot. Fogjuk használni a modellező elemeket, mint a „Osztály” és a közöttük lévő különféle kapcsolatokat.
A „több-hoz” kapcsolat bemutatására az „Aggregáció” típusú kapcsolatot fogjuk használni (10. ábra): a dió a egész, a héj és a mag pedig a részei.
10. ábra. A „több-hoz” kapcsolat
Ennek eredményeként a diagramunk körülbelül így fog kinézni (11. ábra). A kiemelt osztályokat, amelyek közvetlenül a folyamat szöveges leírásában szerepelnek, színnel jelöltük.
11. ábra. Osztálydiagram
Az osztálydiagramot más artefaktumok modellezésére is használtuk - nemcsak azokéira, amelyek a materiel értékek nyilvántartásának automatizálható koncepciós modelljéhez kapcsolódnak, hanem a végrehajtási környezethez (12. ábra) és a „szomszédos” folyamatokhoz (13. ábra), amelyek hatással lehetnek az automatizált folyamatra, de jelenleg nem állnak a figyelmünk középpontjában (feltételezzük, hogy a rendszer fejlődni fog, és ez az információ hasznos lesz).
12. ábra. Osztálydiagram (környezet)
A származási kapcsolat különböző építmények generalizálását mutatja, a „gyermek” osztályokat az „építmény” általánosító „szülő” osztály alatt.
13. ábra. Osztálydiagram (további információ az artefaktumokról)
A „helyzetre való reakció” a „Vizualizációs ellenőrzési adatoktól” függ. Több függőségi kapcsolat esetén a „trace” sztereotípust használjuk, hogy bemutassuk az osztályok nyomvonalát, amelyek kifejezetten nem szerepelnek a folyamat leírásában, de szükségesek az automatizálásukhoz, a osztályokra, amelyekre a pontos hivatkozásokat a leírásunkban találhatók.
5. lépés. Elemzés a „Üzleti szabályok” sávon található jegyzetekről
A következő szabályokat adtuk meg (lásd a 2. ábrát ):
- az egyik lépés két részre történő felosztásának szükségessége, a második rész csak adott körülmények között kezd el működni;
- a diók nyilvántartásának elvégzésére kinevezett személy;
- technikai jelzés (az elemek fehér színe), ami azt jelzi, hogy az elem a folyamat leírásában kifejezetten nincs megnevezve.
Meg kell jegyezni, hogy ezeket a szabályokat már felhasználtuk a diagramok fejlesztése során.
Záró megjegyzések
Tehát öt lépést tettünk meg, és háromféle diagramot készítettünk. Hozzáfűznék egy rövid megjegyzést a modelljeink szervezéséről a modellezési környezetben. Számos olyan keretrendszer létezik, amely segíti a kidolgozott modellek strukturálását, de ez nem a cikk témája, ezért egy egyszerű csomagsort alkalmazunk a projektünk rendezett vezetéséhez: Üzleti folyamat, Funkcionális modell, Artefaktumok, Résztvevők és Környezet (14. ábra).
14. ábra. A projekt csomagjainak struktúrája
Így kidolgoztunk egy következetes modellt, amely a materiális értékek számviteli rendszerét különböző oldalról írja le: az automatizálható üzleti folyamat modellje, a funkcionális modell és a rendszer belső szervezetének modellje konceptuális szinten.
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.
- OMG Egyesült Modellezési Nyelv (OMG UML) Specifikáció. 2.5.1-es verzió. [Elektronikus forrás] Hozzáférés módja: Internet:
Forrás: habr.com
