Protsessi modelleerimisest automatiseeritud süsteemi projekteerimiseni (1. osa)

“Üks päev orava elus” ehk protsesside modelleerimisest kuni automatiseeritud varanduse arvestussüsteemi “Belka-1.0” projekteerimiseni (1. osa)

Illustratsiooni kasutati A. S. Puškini “Lugu tsaar Saltanist”, kirjastus Lastekirjandus, Moskva, 1949, Leningrad, K. Kuznetsovi joonistused

Mis on "oraval" sellega pistmist?

Selgitan kohe, mis "oraval" sellega pistmist on. Olles kohanud Internetis lõbusaid projekte UML-i õppimiseks, mis põhinevad muinasjuttudest laenatud ainevaldkonnal (näiteks siin [1]), otsustasin koostada sarnase näite ka oma õpilastele, et nad saaksid alustuseks uurida ainult kolme tüüpi diagramme: tegevusdiagramm, kasutusjuhtude diagramm ja klassiskeem. Ma ei tõlgi teadlikult diagrammide nimesid vene keelde, et vältida vaidlusi "tõlkeraskuste" üle. Selgitan veidi hiljem, milleks see on. Selles näites kasutan Austraalia ettevõtte Enterprise Architect raamistikku Sparxi süsteemid [2] – hea tööriist mõistliku hinna eest. Ja osana oma treeningutest kasutan Modelio [3], hea tasuta objektorienteeritud disainitööriist, mis toetab UML2.0 ja BPMN standardeid, ilma visuaalsete võimaluste poolest tarbetute kellade ja viledeta, kuid keele põhitõdede õppimiseks täiesti piisav.

Hakkame automatiseerima nendes protsessides tekkivat materiaalse vara arvestust.

...
Meres asub saar, (E1, E2)
Saarel on rahe (E3, E1)
Kuldse kupliga kirikutega (E4)
Tornide ja aedadega; (E5, E6)
Palee ees kasvab kuusk, (E7, E8)
Ja selle all on kristallmaja; (E9)
Seal elab taltsas orav, (A1)
Jah, milline seiklus! (A1)
Orav laulab laule, (P1, A1)
Jah, ta näksib pidevalt pähkleid, (P2)
Kuid pähklid pole lihtsad, (C1)
Kõik kestad on kuldsed, (C2)
Tuum on puhas smaragd; (C3)
Teenindajad valvavad oravat, (P3, A2)
Nad teenivad teda erinevate teenistujatena (P4)
Ja määrati ametnik (A3)
Pähklite range arvestus on uudis; (P5, C1)
Sõjavägi tervitab teda; (P6, A4)
Karpidest valatakse münt (P7, C2, C4)
Laske neil minna ümber maailma; (lk 8)
Tüdrukud valavad smaragdi (P9, A5, C3)
Laoruumidesse ja katte alla; (E10, E11)
...
(A.S. Puškin "Lugu tsaar Saltanist, tema kuulsusrikkast ja võimsast kangelasest prints Guidon Saltanovitšist ja kaunist printsess Luigest" töö muinasjutu kallal algas oletatavasti 1822. aastal, muinasjutu avaldas Puškin esmakordselt kogumikus “A. Puškini luuletused” (III osa, 1832, lk 130-181) — 10 aastat ideest avaldamiseni, muide!)

Natuke koodidest, mis on kirjutatud ridadest paremale. "A" (alates "Actor") tähendab, et rida sisaldab teavet protsessis osaleja kohta. “C” (alates “Class”) – teave klassiobjektide kohta, mida protsesside täitmisel töödeldakse. “E” (alates “Environment”) – teave klassiobjektide kohta, mis iseloomustavad protsesside täitmise keskkonda. “P” (alates “Protsess”) – teave protsesside endi kohta.

Muide, protsessi täpne definitsioon pretendeerib ka metoodiliste vaidluste põhjuseks, kasvõi juba selle tõttu, et on erinevaid protsesse: äri-, tootmis-, tehnoloogilised jne. ja nii edasi. (saate teada näiteks siin [4] ja siin [5]). Vaidluste vältimiseks lepime sellega kokku Oleme protsessist huvitatud selle ajas korratavuse ja automatiseerimise vajaduse seisukohast, st. protsessioperatsioonide mis tahes osa täitmise ülekandmine automatiseeritud süsteemi.

Märkused tegevusskeemi kasutamise kohta

Alustame oma protsessi modelleerimist ja kasutame selleks tegevusskeemi. Esiteks lubage mul selgitada, kuidas ülaltoodud koode mudelis kasutatakse. Seda on lihtsam selgitada graafilise näitega, kuid samal ajal analüüsime mõningaid (peaaegu kõiki vajalikke) tegevusdiagrammi elemente.
Analüüsime järgmist fragmenti:

...
Orav laulab laule, (P1, A1)
Jah, ta näksib pidevalt pähkleid, (P2)
Kuid pähklid pole lihtsad, (C1)
Kõik kestad on kuldsed, (C2)
Tuum on puhas smaragd; (C3)
...

Meil on kaks protsessietappi P1 ja P2, osaleja A1 ning kolme erineva klassi objektid: sammule sisestatakse klassi C1 objekt, klasside C2 ja C3 objektid väljastatakse meie selle sammu P2 tegevuse tulemusena. protsessi. Diagrammi jaoks kasutame järgmisi modelleerimiselemente.

Meie protsessi fragmenti saab kujutada umbes nii (joonis 1).

Joonis 1. Tegevusdiagrammi fragment

Aktiivsuskeemi ruumi korrastamiseks ja struktureerimiseks kasutame UML-i tähistuse klassikalise kasutuse seisukohalt mittestandardset lähenemist. Kuid sellel on mitu põhjust. Esiteks, vahetult enne modelleerimisega alustamist koostame nn modelleerimisleping, millesse salvestame kõik tähise kasutamise omadused. Teiseks rakendati seda lähenemisviisi korduvalt edukalt ärimudelite etapis reaalsetes projektides tarkvarasüsteemide loomiseks; tulemused salvestas meie väike autorite meeskond vastavasse autoriõiguse objekti [6] ja neid kasutati ka koolitusjuhendis [ 7]. Tegevusdiagrammi jaoks määratleme, et diagrammi väli on struktureeritud "ujumisradade" abil. Raja nimi vastab sellele rajale paigutatavate diagrammielementide tüübile.

"Sisend- ja väljundartefaktid": See rada sisaldab elemente Objects – objekte, mida kasutatakse või mis on mõne protsessietapi täitmise tulemus.
"Protsessi etapid": Siin asetame tegevuse elemendid - protsessis osalejate tegevused.
"Osalejad": elementide tee, mis tähistavad tegevuste sooritajate rolle meie protsessis; nende jaoks kasutame sama modelleerivat elementi Objekt - objekt, kuid lisame sellele stereotüübi "näitleja".
Järgmine lugu on nn "Ärireeglid" ja sellele rajale asetame teksti kujul protsessi etappide täitmise reeglid ja selleks kasutame modelleerimiselementi Märkus - märkus.
Siin peatume, kuigi võiks ka rada kasutada "Tööriistad" koguda teavet protsesside automatiseerimise taseme kohta. Kasuks võib tulla ka tee "Osalejate positsioonid ja jaotus", saab seda kasutada rollide sidumiseks protsessis osalejate ametikohtade ja osakondadega.

Kõik, mida ma just kirjeldasin, on fragment modelleerimise kokkulepped, puudutab see lepingu osa ühe diagrammi korrastamise reegleid ja vastavalt ka selle kirjutamise ja lugemise reegleid.

"Retsept"

Nüüd kaalume võimalust süsteemi konkreetselt modelleerida tegevusdiagrammist. See on vaid üks võimalus, märgin, et see pole muidugi ainus. Tegevusdiagramm pakub meile huvi oma rollist protsesside modelleerimiselt automatiseeritud süsteemi projekteerimisele üleminekul. Selleks järgime metoodilisi soovitusi - omamoodi retsepti, mis koosneb ainult viiest etapist ja näeb ette ainult kolme tüüpi diagrammide väljatöötamise. Selle retsepti kasutamine aitab meil saada ametliku kirjelduse protsessist, mida tahame automatiseerida, ja koguda andmeid süsteemi kujundamiseks. Ja UML-i õppimise alguses olevate õpilaste jaoks on see omamoodi päästevahend, mis ei lase neil uppuda kõigisse UML-i ja kaasaegsete modelleerimisvahendite visuaalsete vahendite ja tehnikate mitmekesisusse.

Siin on tegelikult retsept ise ja seejärel järgige meie "muinasjutu" teemavaldkonna jaoks koostatud diagramme.

1. etapp. Kirjeldame protsessi tegevusdiagrammi kujul. Rohkem kui 10 sammuga protsessi puhul on diagrammi loetavuse parandamiseks mõttekas rakendada protsessietappide lagunemise põhimõtet.

2. etapp. Valige, mida saab automatiseerida (sammud saab näiteks diagrammil esile tõsta).

3. etapp. Automatiseeritud samm peab olema seotud süsteemi funktsiooni või funktsioonidega (seos võib olla mitu-mitmele), joonistage kasutusjuhtumi diagramm. Need on meie süsteemi funktsioonid.

Etapp 4. Kirjeldame AS-i sisemist korraldust klassiskeemi abil - Klass. Tegevusdiagrammi ujumisrada "Sisend- ja väljundobjektid (dokumendid)" on objektimudeli ja olemi-suhte mudeli koostamise aluseks.

5. etapp. Analüüsime “Ärireeglite” raja märkmeid, pakuvad need mitmesuguseid piiranguid ja tingimusi, mis muudetakse järk-järgult mittefunktsionaalseteks nõueteks.
Saadud diagrammide komplekt (Activity, Use-case, Class) annab meile formaliseeritud kirjelduse üsna ranges tähistuses, s.t. on ühemõtteline näit. Nüüd saate välja töötada tehnilisi kirjeldusi, täpsustada nõuete spetsifikatsioone jne.

Alustame modelleerimist.

1. etapp. Kirjeldage protsessi tegevusdiagrammi kujul

Tuletan meelde, et diagrammivälja struktureerisime ujumisradade abil; iga rada sisaldab sama tüüpi elemente (joonis 2). Lisaks ülalkirjeldatud diagrammielementidele kasutame täiendavaid elemente, kirjeldame neid.

Otsus (Decision) tähistab diagrammil meie protsessi hargnemispunkti ja lõimede ühendamine (Merge) – nende taasühendamise punkti. Üleminekutel kirjutatakse üleminekutingimused nurksulgudesse.

Kahe sünkronisaatori (Fork) vahel näitame paralleelseid protsessiharusid.
Meie protsessil võib olla ainult üks algus – üks sisenemispunkt (esialgne). Kuid võib olla mitu lõpetamist (lõplik), kuid mitte meie konkreetse diagrammi jaoks.

Nooli on üsna palju, suure hulga elementide ja ühendustega saate esmalt tuvastada protsessi etapid ja seejärel teha need etapid lahti. Kuid selguse huvides tahaksin näidata meie "muinasjutulist" protsessi täielikult ühel diagrammil, samas kui loomulikult peame tagama, et nooled "ei jääks kokku", oleks võimalik täpselt jälgida, mis on ühendatud. milleni.

Joonis 2. Tegevusskeem – protsessi üldvaade

Sest poeetilistes ridades on mõned protsessi detailid välja jäetud, need tuli taastada, neid näitavad valge taustaga elemendid. Need üksikasjad hõlmavad salvestamise ja töötlemise jaoks edastamise/vastuvõtmise etappi ning mitmeid sisend- ja väljundartefakte. Väärib märkimist, et ka see samm ei paljasta protsessi täielikult, sest peaksime eraldi määrama edastuse ja vastuvõtuetapi ning isegi lisama eraldi etapi kestade jaoks ning samuti mõtlema, et kõigepealt tuleks kõik need materiaalsed väärtused ajutiselt kuskile hoiule panna jne. ja nii edasi.
Märkigem ka seda, et vastuseta jääb küsimus pähklite päritolust - kust nad tulevad ja kuidas oravani jõuavad? Ja see küsimus (see on märkuses punase kirjaga esile tõstetud - element Märkus) nõuab eraldi uurimist! Nii toimib analüütik – kogub infot jupphaaval, teeb oletusi ja saab teemaekspertidelt “okei” või “ei-okei” – väga olulised ja lihtsalt asendamatud inimesed ärimudelite loomise etapis süsteemide loomisel.

Pange tähele, et protsessi samm P5 koosneb kahest osast.

Ja me lahutame iga osa ja kaalume seda üksikasjalikumalt (joonis 3, joonis 4), sest nende konkreetsete etappide raames tehtavad tegevused automatiseeritakse.

Joonis 3. Tegevusskeem – detailid (1. osa)

Joonis 4. Tegevusskeem – detailid (2. osa)

2. etapp. Valige, mida saab automatiseerida

Automatiseeritavad sammud on diagrammidel värviliselt esile tõstetud (vt joonis 3, joonis 4).

Kõiki neid teostab üks protsessis osaleja - ametnik:

• Sisestab avaldusse info pähkli kaalu kohta;
• Sisestab väljavõttesse info pähkli ülekande kohta;
• Salvestab pähkli kooreks ja tuumaks muutumise fakti;
• Sisestab avaldusse info pähklituuma kohta;
• Sisestab loendisse teabe pähklikoorte kohta.

Tehtud töö analüüs. Mis järgmiseks?

Seega oleme teinud palju ettevalmistustööd: kogunud infot protsessi kohta, mida automatiseerime; hakkas modelleerimisel kokkuleppele jõudma (seni ainult Tegevusdiagrammi kasutamise osas); teostas protsessi simulatsiooni ja isegi lahutas mitu selle etappi; Tuvastasime protsessietapid, mille automatiseerime. Nüüd oleme valmis liikuma edasi järgmiste sammude juurde ning alustama süsteemi funktsionaalsuse ja sisemise korralduse kujundamist.

Nagu teate, pole teooria ilma praktikata midagi. Kindlasti peaksite proovima oma kätega "modelleerimist", see on kasulik ka pakutava lähenemisviisi mõistmiseks. Näiteks saab töötada modelleerimiskeskkonnas Modelio [3]. Oleme lahti võtnud vaid osa üldise protsessi diagrammi etappidest (vt joonis 2). Praktilise ülesandena võidakse teil paluda korrata kõiki Modelio keskkonnas olevaid diagramme ja teostada etapi „Edastamine/vastuvõtmine säilitamiseks ja töötlemiseks“ dekomponeerimine.
Me ei kaalu veel konkreetsetes modelleerimiskeskkondades töötamist, kuid see võib saada sõltumatute artiklite ja ülevaadete teemaks.

Artikli teises osas analüüsime etappides 3-5 vajalikke modelleerimis- ja disainitehnikaid, kasutame UML kasutusjuhtumite ja klasside diagramme. Jätkub.

Allikate loetelu

1. Veebisait "UML2.ru". Analüütikute kogukonna foorum. Üldine jaotis. Näited. UML-diagrammidena vormindatud muinasjuttude näited. [Elektrooniline ressurss] Juurdepääsurežiim: Internet: http://www.uml2.ru/forum/index.php?topic=486.0
2. Sparx Systemsi veebisait. [Elektrooniline ressurss] Juurdepääsurežiim: Internet: https://sparxsystems.com
3. Modelio veebisait. [Elektrooniline ressurss] Juurdepääsurežiim: Internet: https://www.modelio.org
4. Suur entsüklopeediline sõnaraamat. Protsess (tõlgendus). [Elektrooniline ressurss] Juurdepääsurežiim: Internet: https://dic.academic.ru/dic.nsf/enc3p/246322
5. Veebisait "Tõhusa juhtimise korraldamine". Blogi. Kategooria "Äriprotsesside juhtimine". Äriprotsessi definitsioon. [Elektrooniline ressurss] Juurdepääsurežiim: Internet: https://rzbpm.ru/knowledge/pochemu-processy-stali-s-pristavkoj-biznes.html
6. Tunnistus nr 18249 intellektuaalse tegevuse teose registreerimise ja deponeerimise kohta. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Õppevahendi käsikiri pealkirjaga „Ainevaldkonna modelleerimine ettevõtte arhitekti abil“ // 2011.
7. Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Äriprotsesside modelleerimine. — M.: KURSUS, SIC INFRA-M, EBS Znanium.com. — 2017.

Allikas: www.habr.com