Protsesside modelleerimisest automatiseeritud süsteemi projekteerimiseni (Osa 1)

„Üks päev orava elust“ või kuidas simuleerida protsesse automatiseeritud materjalide arvestussüsteemi „Orav-1.0“ projekteerimist (1. osa)

Kasutatud illustratsioon A.S. Puškini "Sada Salkani kuningast", kirjastus "Lastekirjandus", Moskva, 1949. aasta, Leningrad, joonistused K. Kuznetsovilt

Mis pistmist on „orava“?

Selgitan kohe, mis pistmist on „orava“ga. Leides Internetis naljakas projekte, et õppida UML-i, tuginedes muinasjuttude temaatikale (näiteks, siit [1]), otsustasin ka oma üliõpilastele ette valmistada sarnase näite, et saaksime alguses õppida kolme tüüpi diagramme: tegevusdiagramm, kasutusjuhtdiagramm ja klassidiagramm. Ei tõlgi diagrammide nimesid vene keelde, et vältida „tõlkekeerukuse“ vaidlusi. Selgitan, milleks need on, veidi hiljem. Käesolevas näites kasutan Austraalia ettevõtte Sparx Systems [2] – hea tööriist mõistliku hinna eest. Ja õppetunde läbiviimiseks kasutan Modelio [3], hea tasuta objektorienteeritud projekteerimise vahend, mis toetab UML2.0 ja BPMN standardeid, ilma liigsete joonistamisvõimalustega, kuid täiesti piisav keele aluste õppimiseks.

Kavatseme automatiseerida materiaalse vara arvestusprotsess, mis ilmneb just nendes protsessides.

…
Saare peal asub, (E1, E2)
Linn saare peal seisab (E3, E1)
Kuldpruunide kirikutega, (E4)
Tornide ja aedadega; (E5, E6)
Kuusk kasvab palee ees, (E7, E8)
Ja selle all on kristallmaja; (E9)
Orav elab seal, (A1)
Ja mis mõnus olend! (A1)
Orav laulab laule, (P1, A1)
Ja pähkleid pidevalt näksib, (P2)
Kuid pähklid ei ole tavalised, (C1)
Kõik kestad on kuldsed, (C2)
Koidul on selge smaragd; (C3)
Teenrid valvavad oravat, (P3, A2)
Teenivad teda erinevate teenustega (P4)
Ja määratud on kohus (A3)
Range arvestus pähklite kohta; (P5, C1)
Austavad teda väejuhiga; (P6, A4)
Kestadest valatakse münt, (P7, C2, C4)
Ja lastakse neid ringkäiku; (P8)
Tüdrukud puistavad smaragdi (P9, A5, C3)
Ladu sisse, ja keldrisse; (E10, E11)
…
(A.S. Puškini "Sada Sultani kuningas, tema auväärne ja võimas rikka rikka Gvidoni Saltonovi poeg ja ilus printsess Luik") Muinasjutu töö algas ilmselt 1822. aastal; esmakordselt avaldas selle Puškin kogus „A. Puškini luuletused“ (k . III, 1832, lk 130—181). — 10 aastat ideest avaldamiseni, muide!)

Natuke koodidest, mis on kirjutatud ridade paremal poole. „A“ (lühend sõnast „Actor“) tähendab, et real on teavet osaleja kohta. „C“ (lühend sõnast „Class“) – teave klasside objektide kohta, mis 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 endi kohta.

Muide, protsessi täpne määratlemine nõuab ka metodoloogilist arutelu, vähemalt seetõttu, et protsessid võivad olla erinevad: ärilised, tootmis-, tehnoloogilised jne. (näiteks tutvuda saab, siit [4] ja siit [5]). Et vältida vaidlusi, lepime kokku, et protsess huvitab meid selle korduvuse seisukohalt ajas ja vajaduse osas automatiseerimise järele,, st mingisuguste protsessi toimingute osa teostamise ülekandmine automatiseeritud süsteemile.

Tegevusdiagrammi kasutamise märkmed

Alustame meie protsessi mudeliga ja kasutame selleks tegevusdiagrammi. Esiteks selgitan, kuidas eespool nimetatud koode mudelis kasutada. Selgitamine on lihtsam visuaalse näite abil, ja vaatame samas üle mõned (peaaegu kõik vajalikud) tegevusdiagrammi elemendid.
Analüüsime järgmist fragmenti:

…
Orav laulab laule, (P1, A1)
Ja pähkleid pidevalt näksib, (P2)
Kuid pähklid ei ole tavalised, (C1)
Kõik kestad on kuldsed, (C2)
Koidul on selge smaragd; (C3)
…

Meil on kaks protsessi P1 ja P2, osaline A1 ning kolme erineva klassi objektid: C1 klassi objekt siseneb sammu, klasside C2 ja C3 objektid saadakse väljundina, kui P2 sammu tegevuse tulemus. Tegevusdiagrammi jaoks kasutame järgmisi modelleerimise elemente.

Meie protsessi fragmenti saab esitada umbkaudu nii (Joonis 1).

Joonis 1. Tegevusdiagrammi fragment

Tegevusdiagrammi ruumi korraldamiseks ja struktureerimiseks rakendame natuke ebatavalist lähenemist, klassikalise UML süntaksiga võrreldes. Kuid sellel on mitu põhjust. Esiteks koostame enne modelleerimise algust niinimetatud modelleerimise kokkuleppe., kus me fikseerime kõik märkuste kasutamise eripärad. Teiseks, seda lähenemist on korduvalt edukalt rakendatud ärimudeli loomise etapis reaalses tarkvarasüsteemide arendusprojektides, mille tulemused on fikseeritud meie väikese autorite kollektiivi vastavas autoriõiguse objektis [6] ning neid on kasutatud õpikuna [7]. Aktiviteedi diagrammi jaoks määrame, et diagrammi välja struktuuri korrigeerime „ujumise“ radade abil – Swim lanes. Rada nimi vastab diagrammi elementide tüübile, mis paigutatakse sellele rajale.

„Sisendi ja väljundi artefaktid“: sellel rajal asuvad elementide Objects – objektid, mida kasutatakse või mis on mingi protsessi sammu täitmise tulemus.
„Protsessi sammud“: siia paigutame elemente Activity – tegevusi, milles osalejad osalevad.
„Osalejad“: rada elementide jaoks, mis tähistavad tegevuste täitjate rolle meie protsessis, nende jaoks kasutame sama mudeldamise elementi Object – objekt, kuid lisame sellele stereotüübi „Actor“.
Järgmine rada nimetatakse „Äripoliitikad“ ja paneme selle rada tekstivormingus protsessi etapite täitmise reeglid ja selleks kasutame simuleerivat elementi Note – märkus.
Siin peatume, kuigi oleks võinud kasutada ka rada „Tööriistad“ protsessi automatiseerimise taseme teabe kogumiseks. Võib olla kasulik ka rada „Osaliste ametikohad ja osakonnad“, seda saab kasutada osaliste rollide sidumiseks ametikohtade ja osakondadega.

Kõik, mida just kirjeldasin, on osa modelleerimise kokkuleppest, see osa kokkuleppest käsitleb ühe диаграмми korraldamise reegleid ja vastavalt reegleid selle kirjutamiseks ja lugemiseks.

„Retsept“

Nüüd vaatame süsteemi modelleerimise varianti just Activity диаграмми. See on vaid üks võimalus ja tuleb märkida, et see ei ole kindlasti ainus. Activity diagramm huvitab meid selle rolli tõttu, mis tal on protsessi modelleerimisest automatiseeritud süsteemi kavandamise üleminekul. Selleks järgime metoodilisi soovitusi – teatud tüüpi retsepti, mis koosneb viiest etapist ja hõlmab kolme tüüpi diagrammi väljatöötamist. Selle retsepti rakendamine aitab saada formaliseeritud kirjelduse protsessist, mida soovime automatiseerida, ja koguda andmeid süsteemi projekteerimiseks. Algajatele UML-i õppijatele on see omamoodi päästerõngas, mis aitab mitte uppuda UML-i ja tänapäevaste modelleerimisvahendite mitmekesisusesse.

Siin on, põhimõtteliselt, enda retsept, millele järgnevad diagrammid, mis on loodud meie „muinasjutulise“ teema valdkonna jaoks.

Etapp 1. Kirjeldame protsessi Activity diagrammina. Kui protsessis on rohkem kui 10 sammu, on mõttekas rakendada dekompositsiooni põhimõtet, et suurendada diagrammi loetavust.

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

Etapp 3. Automatiseeritavale sammele tuleb määrata süsteemi funktsioon või funktsioonid (seos võib olla paljude-kestmisega), joonistame Use-case diagrammi. Need on meie süsteemi funktsioonid.

Etapp 4. Kirjeldame süsteemi sisemist korraldust klasside diagrammi abil – Klass. Ujuv rada "Sisend- ja väljundobjektid (dokumendid)" tegevusdiagrammil on alus objektimudeli ja entiteedi-sidumise mudeli koostamiseks.

Etapp 5. Analüüsime märkmeid ärireeglite rajal, need annavad erinevaid piiranguid ja tingimusi, mis järk-järgult muutuvad mittefunktsionaalseteks nõueteks.
Saadud diagrammide kogum (Activity, Use-case, Class) annab meile formaalse kirjelduse piisavalt rangetes märkustes, st. omab üheselt mõistetavat tõlgendust. Nüüd saab alustada tehnilise ülesande koostamisega, täpsustama nõuete spetsifikatsiooni jne.

Alustame modelleerimisega.

Etapp 1. Kirjeldame protsessi tegevusdiagrammina

Tuletan meelde, et diagrammi välja on ehitatud "ujuvate" radade abil, kus igal rajal asuvad sama tüüpi elemendid (Joonis 2). Peale ülaltoodud diagrammi elementide kasutame ka täiendavaid elemente, kirjeldame neid nüüd.

Otsus (Decision) tähistab diagrammil meie protsessi harunemist, samas kui voogude ühendamine (Merge) on nende taasühinemise punkt. Ristküliku sees on üleminekutel kirjeldatud üleminekutingimused.

Kahe sünkroniseerija (Fork) vahel näitame protsessi paralleelseid harusid.
Meie protsessil võib olla ainult üks algus – üks sisenemispunkt (Initial). Kuid lõppeid (Final) võib olla mitu, kuid mitte meie konkreetses diagrammis.

Nooli tuleb tõeliselt palju, suure arvu elementide ja seoste korral on võimalik esmalt välja selgitada protsessi etapid ja seejärel neid etappe dekomponeerida. Kuid meie "muinasjutulise" protsessi soovin ma selguse huvides näidata terviklikult ühel diagrammil, samas tuleb muidugi saavutada, et nooled "ei liitu", et oleks võimalik täpselt jälgida, milline on seos.

Joonis 2. Activity diagram – protsessi üldine ülevaade

Kuna luuletuste ridades on mõned protsessi detailid vahele jäetud, tuli need taastada, need on esitatud valge taustaga elementidena. Need detailid hõlmavad sammu 'Ettetehtud vastuvõtt ja ladustamine ning töötlemine' ning mitmeid sisenemist ja väljumist artefakte. Tasub mainida, et see samm ei paljasta protsessi täielikult, kuna meil oleks vaja eraldi välja tuua edastamise ja vastuvõtu samm ning lisada eraldi samm kestade jaoks, ning veelgi arendada mõtet, et kõik need materiaalsed väärtused peaksid kuskil ajutiselt säilima jne jne.
Tasub veel tähelepanu juhtida, et pähklite päritolu küsimus on endiselt vastuseta – kust need tulevad ja kuidas nad orava juurde jõuavad? Ja see küsimus (see on seotud punase fontide värviga märkuses – element Note) vajab eraldi arendamist! Just nii töötab analüütik – kogudes teavet killukaupa, tehes hüpoteese ja saades valdkonna ekspertidelt 'okei' või 'mitte-okei' – väga oluliste ja asendamatute inimestena ärimudeli loomise etapis süsteemide välja töötamisel.

Tuleb märkida, et P5 protsessi etapp koosneb kahest osast.

Iga osa analüüsime ja käsitleme lähemalt (Joonis 3, Joonis 4), kuna just nende sammude raames toimuv tegevus automatiseeritakse.

Joonis 3. Activity diagramm – detailne (osa1)

Joonis 4. Activity diagramm – detailne (osa2)

Etapp 2. Tõstame esile, mida saab automatiseerida

Automatiseerimisele kuuluvad etapid on diagrammides esile tõstetud värviga (vt Joonis 3, Joonis 4).

Kõiki neid teostab üks protsessi osaline – diakon:

• Kantakse välja pähkli kaal register;
• Kantakse välja pähkli edastamine register;
• Fikseeritakse pähkli muutumine kooreks ja tuumaks;
• Kantakse välja pähkli tuum register;
• Kantakse välja pähkli koored register.

Töödeldud töö analüüs. Mis edasi?

Nii, oleme teinud suure ettevalmistustöö: kogunud teavet protsessi kohta, mida kavatseme automatiseerida; alustanud modelleerimise kokkuleppe loomist (hetkel vaid tegevusdiagrammi kasutuse osas); viinud läbi protsessi modelleerimise ja isegi dekodeerinud mitmeid selle samme; määratlenud protsessi etapid, mida automatiseerime. Nüüd oleme valmis liikuma järgmistele etappidele ja alustama süsteemi funktsioonide ja sisemise korralduse projekteerimist.

Nagu on teada, on teooria ilma praktikata — mitte midagi. Oluline on kindlasti proovida "modelleerimist" oma kätega, see on kasulik ka pakutud lähenemise teadvustamiseks. Näiteks saab töötada modelleerimise keskkonnas Modelio [3]. Oleme dekodeerinud vaid osa tegevusdiagrammi üldisest protsessist (vt Joonis 2). Praktikaülesandena võiks ettepaneku teha kõik diagrammid Modelio keskkonnas ja viia läbi sammu „Säilitamine/ vastuvõtt ja töötlemine“ dekodeerimine.
Konkreetsetes modelleerimiskeskkondades töötamist me hetkel ei käsitle, kuid see võiks saada iseseisvate artiklite ja ülevaatuste aineks.

Artikli teises osas käsitleme modelleerimise ja projekteerimise tehnikaid, mis on vajalikud 3–5 etapis, kasutades UML kasutusjuhtide ja klasside diagramme. Jätkub.

Allikate nimekiri

1. Lehekülg «UML2.ru». Analüütikute Ühenduse foorum. Üldine jaotis. Näidised. Näited muinasjuttudest, mis on kujundatud UML diagrammidena. [Elektrooniline ressurss] Juurdepääsu režiim: Internet: http://www.uml2.ru/forum/index.php?topic=486.0
2. Lehekülg Sparx Systems. [Elektrooniline ressurss] Juurdepääsu režiim: Internet: https://sparxsystems.com
3. Lehekülg Modelio. [Elektrooniline ressurss] Juurdepääsu režiim: Internet: https://www.modelio.org
4. Suur entsüklopeedia. Protsess (tõlgendus). [Elektrooniline ressurss] Juurdepääsu režiim: Internet: https://dic.academic.ru/dic.nsf/enc3p/246322
5. Lehekülg «Tõhusate juhtimiste vältimise organisatsioon». Blogi. Rubriik «Äriprotsesside juhtimine». Ärianalüüsimise määratlemine. [Elektrooniline ressurss] Juurdepääsu režiim: Internet: https://rzbpm.ru/knowledge/pochemu-processy-stali-s-pristavkoj-biznes.html
6. Tunnistus nr 18249 intellektuaalse tegevuse tulemuse registreerimise ja deponimise kohta. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Õpikute ja metoodiliste materjalide käsikiri pealkirjaga «Objekti ala modelleerimine Enterprise Architecti kasutamisega» // 2011.
7. Zolotokhina E.B., Vishnya A.S., Krasnikova S.A. Äritegevuse protsesside modelleerimine. — M.: KURS, NII INFRA-M, EBS Znanium.com. — 2017.

Allikas: habr.com