Protsesside modelleerimisest automatiseeritud süsteemi projekteerimiseni (Osa 1)

«Üks päev orava elus» või kuidas minna mudeldamisest automatiseeritud varade arvestuse süsteemi projekteerimisele «Belka-1.0» (Osa 1)

Kasutatud illustreerimist A.S. Puškini "Sadu Saldani muinasjutust", väljaanne "Lasteliteratuur", Moskva, 1949, Leningrad, K.Kuznetsovi joonistused

Kuidas see oravaga seotud on?

Selgitan kohe, kuidas see oravaga seotud on. Kootud Internetis lõbusate UML-i õpiprojektidega, mis toetuvad muinasjutu teemadele (näiteks, siin [1]), otsustasin ka oma tudengitele sellise näite valmistada, et saaksime alguses õppida kolme erinevat diagrammi tüüpi: tegevusdiagramm, kasutusjuhtide diagramm ja klasside diagramm. Ma ei tõlgi diagrammide nimetusi eesti keelde, et vältida arutelusid „tõlkimise raskustest“. Mida miski tähistab – selgitan varsti. Käesolevas näites kasutan Austraalia ettevõtte Enterprise Architect keskkonda Sparx Systems [2] – hea tööriist mõistliku raha eest. Õppeainetes rakendan Modelio [3], mitte halb tasuta objekt-orienteeritud projekteerimise vahend, mis toetab UML2.0 ja BPMN standardeid, ilma liialt kunstiliste võimalusteta, aga täiesti piisav keele aluste õppimiseks.

Me kavatseme automatiseerida varade arvestuse tegevuse, mis tekib järgmistes protsessides.

…
Saare peal mere ääres, (E1, E2)
Linak saarel seisab (E3, E1)
Kuldsed kirikud, (E4)
Kohvikud ja aiad; (E5, E6)
Kuusk kasvab palee ees, (E7, E8)
Ja selle all kristallmaja; (E9)
Seal elab käsitööline orav, (A1)
Ja milline nuputaja! (A1)
Orav laulab laule, (P1, A1)
Ja pähkleid krõbistab, (P2)
Ja need pähklid pole tavalised, (C1)
Kõik kestad on kuldsed, (C2)
Südamed on puhtast smaragdist; (C3)
Teenrid hoiavad orava; (P3, A2)
Teenivad teda igasuguste teenustega (P4)
Ja ametisse on määratud rangete käskude ülevaataja (A3)
Sellele pähklite tähtsusele pööratakse tähelepanu; (P5, C1)
Annab talti austust; (P6, A4)
Kestadest valatakse münti, (P7, C2, C4)
Ja visatakse ringi maailma; (P8)
Tüdrukud puistavad smaragdi (P9, A5, C3)
Ladu moodustavad, ja siis sisse; (E10, E11)
…
(A.S. Puškin "Muinasjutt Saldani kuningas, tema kuulsast ja tugevaist rikkaist peahärra Gvidon Saldanovitšist ja kauniste printsess Lebedist", töö muinasjutu kallal algas ilmselt 1822. aastal, esmakordselt ilmus muinasjutt Puškini kogumikus „A. Puškini luuletused“ (osa III, 1832, lk 130–181) — 10 aastat ideest kuni avaldamiseni, muide!)

Veidi koodidest, mis on kirjutatud ridade paremal poole. "A" (lühend sõnast "Actor") tähistab, et reas on teave protsessi osalise kohta. "C" (lühend sõnast "Class") – teave klasside objektide kohta, mida töödeldakse protsesside käigus. "E" (lühend sõnast "Environment") – teave klasside objektide kohta, mis iseloomustavad protsesside täitmise keskkonda. "P" (lühend sõnast "Process") – teave protsesside enda kohta.

Muuseas, protsessi täpne määratlemine on samuti objektiivseks meetodoloogiliseks vaidluste põhjuseks, vähemalt kuna protsessid võivad olla erinevad: ärilised, tootmis-, tehnoloogilised jne. (võite tutvuda näiteks siin [4] ja siin [5]). Vaidluse vältimiseks lepime kokku, et protsess huvitab meid ajas kordumise ja automatiseerimise vajaduse kaudu,st. mingisugune osa protsessi operatsioonide täitmisest pannakse automatiseeritud süsteemi.

Märkmed Activity diagrammi rakendamiseks

Alustame meie protsessi modelleerimist ja kasutame selleks Activity diagrammi. Esiteks selgitan, kuidas ülaltoodud koode mudelis kasutatakse. Selgitamine on lihtsam graafilise näite kaudu, samal ajal vaatame üle mõned (peaaegu kõik vajalikud) Activity diagrammi elemendid.
Analüüsime järgmist fragmenti:

…
Orav laulab laule, (P1, A1)
Ja pähkleid krõbistab, (P2)
Ja need pähklid pole tavalised, (C1)
Kõik kestad on kuldsed, (C2)
Südamed on puhtast smaragdist; (C3)
…

Meil on kaks protsessi sammu P1 ja P2, osaline A1 ning kolme erineva klassi objektid: C1 klassi objekt siseneb sammule, S2 ja S3 klassi objektid saadakse väljundina, kui meie protsessi samm P2 tegevuse tulemus. Diagrammi jaoks kasutame järgmisi modelleerimise elemente.

Meie protsessi fragmenti võib esitada umbkaudu nii (Joonis 1).

Joonis 1. Activity diagrammi fragment

Activity diagrammi ruumilise korralduse ja struktureerimise jaoks rakendame natuke mittestandardsed lähenemist, klassikalise UML sümboolika kasutamise seisukohalt. Kuid sellel on mitmed põhjused. Esiteks, alustada modelleerimist, koostame nn. modelleerimise kokkuleppe, milles fikseerime kõik omadused, mis on seotud notaatsiooni kasutamisega. Teiseks on see lähenemine korduvalt edukalt rakendatud ärimudelite koostamise etapis reaalses tarkvarasüsteemide loomise projektis, mille tulemused on fikseeritud meie väikese autorkollektsiooni vastavas autoriõiguse objektis [6] ning neid on kasutatud õpikutes [7]. Activity-diagrammi jaoks määratleme, et diagrammi valdkonda struktuuri viime „ujumaantunnelite“ – Swim lanes abil. Teede nimed vastavad diagrammi elementide tüüpidele, mis asuvad selles teedes.

„Sisendid ja väljundid“: selles teede paigutatakse elemendid Objects – objektid, mida kasutatakse või mis on teatud protsessi sammu tulemus.
„Protsessi sammud“: siia paneme elemendid Activity – tegevused, milles osalevad protsessi osalised.
„Osalejad“: teede jaoks, mis tähistavad, kes tegevusi meie protsessis viib, kasutame me taas sama mudelreegli elementi Object – objekt, kuid lisame sellele stereotüübi „Actor“.
Järgmine tee on „Äriplaanid“ ja selles teedes paigutame tekstiliselt protsessi sammude täitmise reeglid kasuks mudelreegli elementi Note – märkus.
Siin me peatume, kuigi lisaks võiks veel kasutada teed „Tööriistad“ protsessi automatiseerimise taseme andmete kogumiseks. Veel võib osutuda kasulikuks tee „Osalejate ametikohad ja osakonnad“, mida saab kasutada osalejate rollide seostamiseks ametikohtade ja osakondadega.

Kõik, mida ma just kirjeldasin, on fragment mudelilepingust, see osa lepingust käsitleb diagrammi korraldamise reegleid ja vastavalt selle kirjutamise ja lugemise reegleid.

„Retsept“

Nüüd vaatame süsteemi modelleerimise varianti just Activity-diagrammist. See on ainult üks variant, kuid see pole muidugi ainus. Activity diagramm huvitab meid oma rolli tõttu üleminekuks protsessi modelleerimiselt automatiseeritud süsteemi projekteerimisele. Selleks järgime metodoloogilisi soovitusi – omamoodi retsepti, mis sisaldab vaid viit etappi ja hõlmab kolme erinevat tüüpi diagrammi väljatöötamist. Selle retsepti rakendamine aitab saada formaliseeritud kirjelduse protsessist, mida soovime automatiseerida, ning koguda andmeid süsteemi projekteerimiseks. Õppijatele UML-i alguses on see omamoodi päästerõngas, mis ei luba nende kaduda kõikide UML-i ja kaasaegse modelleerimise vahendite mitmekesisuses.

Siin on see retsept, edaspidi järgneb diagramme, mis on koostatud meie "muinasjutulise" ainevaldkonna jaoks.

Etapp 1. Kirjeldame protsessi Activity diagrammi kujul. Protsessi puhul, kus on välja toodud rohkem kui 10 sammu, on mõistlik rakendada protsessi sammude dekomponeerimise põhimõtet, et parandada diagrammi loetavust.

Etapp 2. Tõstame esile seda, mida saab automatiseerida. (sammud võivad näiteks olla diagrammil esile tõstetud).

Etapp 3. Automatiseeritavale sammule peab vastama süsteemi funktsioon või funktsioonid. (suhe võib olla paljude-ga-paljude), joonistame Use-case diagrammi. Need on meie süsteemi funktsioonid.

Etapp 4. Kirjeldame ASi siseorganiseerimist klasside diagrammi abil. – Class. 'Sisendid ja väljundid (dokumendid)' swimlane'i diagrammi Activity – see on aluseks objektimudeli ja entiteet-suhtemudeli koostamisele.

Etapp 5. Anname ülevaate 'Äripõhimõtted' lane'idest., need annavad erinevaid piire ja tingimusi, mis järk-järgult muudetakse mittefunktsionaalseteks nõueteks.
Saadud diagrammide kogum (Activity, Use-case, Class) annab meile formaliseeritud kirjelduse piisavalt rangeid notaate, st. omab üheselt mõistetavat tõlgendust. Nüüd on võimalik koostada tehniline ülesanne, täpsustada nõuete spetsifikatsiooni jne.

Alustame modelleerimisega.

Etapp 1. Kirjeldame protsessi Activity diagrammi kujul.

Tulet me meenutada, et diagrammi välja oleme struktureerinud, kasutades "ujumise" radu, kus iga rada sisaldab ühte tüüpi elemente (Joonis 2). Lisaks ülaltoodud diagrammi elementidele kasutame ka täiendavaid elemente, kirjeldame neid allpool.

Otsus (Decision) tähistab diagrammil meie protsessi hargnemise punkti, samas kui voogude kokkuliitumine (Merge) on nende taasühinemise punkt. Ristmikel on üleminekute tingimused kirjutatud ruudukujulistes sulgudes.

Kahe sünkroneerija (Fork) vahel näitame protsessi paralleelseid harusid.
Meie protsessil võib olla ainult üks algus – üks sisenemispunkt (Initial). Kuid lõpetamisi (Final) võib olla mitu, kuigi mitte meie konkreetse diagrammi puhul.

Nooli on tõeliselt palju, suure arvu elementide ja sidemete korral võib esmalt välja tuua protsessi etapid ja seejärel hakata neid etappe dekompositsioonima. Kuid meie "muinasjutulist" protsessi tahaksin, et näidatakse visuaalselt ühel diagrammil, samas on kindlasti oluline saavutada, et nooled "ei sulanduks", et oleks selgelt jälgitav, mis millega on seotud.

Joonis 2. Activity diagramm – protsessi üldvaade

Kuna luuletuse ridades on mõned protsessi detailid välja jäetud, tuli need taastada, need on näidatud valge taustaga elementidega. Need detailid sisaldavad sammu „Ülekandmine/ vastuvõtmine ladustamiseks ja töötlemiseks” ning mitmeid sisenemis- ja väljundartefakte. Tuleb märkida, et see samm ei paljasta protsessi täielikult, kuna peaksime eraldi märkima ülekande ja vastuvõtu sammu, ja veelgi enam, et koorikutele tuleks lisada eraldi samm, ning samal ajal mõelda, et kõik need materiaalsed väärtused peaksid mingil ajal olema kuskil ajutiselt ladustatud jne.
Jõuame ka tähele panna, et küsimus pähklite päritolu kohta – kust nad tulevad ja kuidas nad orava juurde jõuavad? See küsimus (toodud punase fontidega märkuses – element Note) vajab eraldi käsitlemist! Nii töötab analüütik – kogub infot killuke killukese haaval, teeb oletusi ja saab «okei» või «mitte-okei» valdkonna ekspertidelt – väga olulised ja asendamatud inimesed äri mudelit arendades süsteemide loomise etapis.

Tähelepanek, et protsessi samm P5 koosneb kahest osast.

Ja dekomponeerime iga osa ja vaatame neid lähemalt (Joonis 3, Joonis 4), kuna käigus toimuv tegevus automatiseeritakse.

Joonis 3. Activity diagramm – detailimine (osa 1)

Joonis 4. Activity diagramm – detailimine (osa 2)

Etapp 2. Tõstame esile seda, mida saab automatiseerida.

Automatiseerimiseks ettenähtud sammud on joonistel esile toodud värviga (vt Joonis 3, Joonis 4).

Kõiki neid teeb üks protsessi osaleja – Diak commander:

• Kandmine teabe kohta pähkli kaalust arvestusse;
• Kandmine teabe kohta pähkli edastamisest arvestusse;
• Fikseerimine pähkli muundumise faktist kestadeks ja tuumaks;
• Kandmine teabe kohta pähkli tuuma arvestusse;
• Kandmine teabe kohta pähkli kestade arvestusse.

Tehtud töö analüüs. Mis edasi?

Nii oleme teinud suure ettevalmistustööd: kogunud teavet protsessi kohta, mida kavatseme automatiseerida; alustanud kokkuleppe koostamisega modelleerimise kohta (praegu ainult Activity diagrammi kasutamise osas); teostanud protsessi modelleerimist ja isegi dekomponeerinud mitmeid selle samme; esile tõstnud protsessi samme, mille me automatiseerime. Nüüd oleme valmis liikuma järgmiste etappide juurde ja alustama süsteemi funktsioonide projekteerimist ning selle sisemise organisatsiooni loomist.

Nagu teada, on teooria ilma praktikata – ei midagi. On oluline proovida 'modelleerimist' omal käel, see on kasulik ka pakutud lähenemise mõistmiseks. Näiteks võib töötada modelleerimise keskkonnas Modelio [3]. Oleme dekomponeerinud ainult osa üldise protsessi diagrammi sammudest (vt Joonis 2). Praktilise ülesandena võib soovitada kordama kõiki diagramme keskkonnas Modelio ja teostama etapi "Edastamine/ vastuvõtmine ladustamiseks ja töötlemiseks" dekompositsiooni.
Konkreetsetes modelleerimiskeskkondades me hetkel ei käsitle, kuid see võib olla iseseisvate artiklite ja ülevaatuste teema.

Artikli teises osas käsitleme modelleerimise ja projekteerimise tehnikaid, mis on vajalikud 3-5 etapis, kasutame UML diagramme Use-case ja Class. Jätkub.

Viidatud allikad

1. Veebileht „UML2.ru“. Analüütikute kogukonna foorum. Üldosa. Näidised. Näidised muinasjuttudest, esitatud UML diagrammidena. [Elektrooniline allikas] Ligipääsu režiim: Internet: http://www.uml2.ru/forum/index.php?topic=486.0
2. Sait Sparx Systems. [Elektrooniline ressurss] Ligipääs: Internet: https://sparxsystems.com
3. Veebileht Modelio. [Elektrooniline allikas] Ligipääsu režiim: Internet: https://www.modelio.org
4. Suure Entsüklopeedia, Protsess (tõlgendus). [Aktiivne ressurss] Ligipääs: Internet: https://dic.academic.ru/dic.nsf/enc3p/246322
5. Saidi "Tõhusat Juhtimist" Blogi. Rubriik "Äriprotsesside Juhtimine". Äri protsessi määratlemine. [Aktiivne ressurss] Ligipääs: Internet: https://rzbpm.ru/knowledge/pochemu-processy-stali-s-pristavkoj-biznes.html
6. Tunnistus nr 18249 autoriõiguse registreerimise ja deponeerimise kohta. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Õpikute väljaande käsikiri pealkirjaga "Ala modelleerimine, kasutades Enterprise Architect" \/\/ 2011.
7. Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Äri protsesside modelleerimine. — M.: KURS, NIK INFRA-M, EBS Znanium.com. — 2017.

Allikas: habr.com