„Viena diena voverės gyvenime“ arba nuo procesų modeliavimo iki automatizuotos materialinių vertybių apskaitos sistemos „Belka-1.0“ sukūrimo (1 dalis)
Ką su tuo turi „voverė“?
Iš karto paaiškinsiu, ką su tuo turi "voverė". Internete susidūriau su smagiais UML mokymosi projektais pagal dalykinę sritį, pasiskolintą iš pasakų (pvz., [1]), taip pat nusprendžiau parengti panašų pavyzdį savo mokiniams, kad jie iš pradžių galėtų studijuoti tik trijų tipų diagramas: veiklos diagramą, naudojimo atvejo diagramą ir klasės diagramą. Sąmoningai neverčiau diagramų pavadinimų į rusų kalbą, kad išvengčiau ginčų dėl „vertimo sunkumų“. Paaiškinsiu, kam tai skirta šiek tiek vėliau. Šiame pavyzdyje naudoju Australijos įmonės „Enterprise Architect“ sistemą [2] – geras įrankis už priimtiną kainą. Ir kaip dalį savo treniruočių aš naudoju [3], geras nemokamas į objektą orientuoto projektavimo įrankis, palaikantis UML2.0 ir BPMN standartus, be nereikalingų varpelių ir švilpukų, kalbant apie vizualines galimybes, tačiau visiškai pakankamas kalbos pagrindams išmokti.
Šiuose procesuose kylančią materialinių vertybių apskaitos veiklą ketiname automatizuoti.
...
Jūroje yra sala, (E1, E2)
Kruša salos stenduose (E3, E1)
Su auksinėmis bažnyčiomis, (E4)
Su bokštais ir sodais; (E5, E6)
Priešais rūmus auga eglė (E7, E8)
O po juo – krištolinis namas; (E9)
Ten gyvena voverė, prisijaukink, (A1)
Taip, koks pramogautojas! (A1)
Voverė dainuoja dainas, (P1, A1)
Taip, jis graužia visus riešutus, (P2)
Ir riešutai nėra paprasti, (C1)
Visi lukštai yra auksiniai, (C2)
Gryno smaragdo branduoliai; (C3)
Tarnai saugo voverę, (P3, A2)
Tarnaukite jai kaip įvairių rūšių tarnai (P4)
Ir buvo paskirtas tarnautojas (A3)
Griežtas riešutų naujienų aprašymas; (P5, C1)
Suteikia savo kariuomenei garbę; (P6, A4)
Iš kriauklių išpilama moneta (P7, C2, C4)
Leisk jiems plūduriuoti aplink pasaulį; (8 psl.)
Merginos meta smaragdą (P9, A5, C3)
Sandėliuose, bet po bušeliu; (E10, E11)
...
(A.S. Puškinas „Pasakojimas apie carą Saltaną, jo šlovingą ir galingą herojų princą Guidoną Saltanovičių ir gražiąją princesę Gulbę“, - 10 metų nuo idėjos iki paskelbimo, beje!)
Šiek tiek apie kodus, kurie parašyti eilučių dešinėje. „A“ (iš „Aktorius“) reiškia, kad eilutėje yra informacija apie proceso dalyvį. „C“ (iš „Class“) – informacija apie klasės objektus, kurie apdorojami procesų vykdymo metu. „E“ (iš „Aplinka“) – informacija apie klasės objektus, apibūdinančius aplinką procesams vykdyti. „P“ (iš „Procesas“) – informacija apie pačius procesus.
Beje, tikslus proceso apibrėžimas taip pat pretenduoja tapti metodinių ginčų priežastimi nebent dėl to, kad vyksta skirtingi procesai: verslo, gamybos, technologinių ir kt. ir taip toliau. (galite sužinoti, pvz. [4] ir [5]). Kad išvengtume ginčų, sutikime Mus domina procesas jo pakartojamumo laikui bėgant ir automatizavimo poreikio požiūriu, t.y. bet kurios proceso operacijų dalies vykdymo perkėlimas į automatizuotą sistemą.
Pastabos dėl veiklos diagramos naudojimo
Pradėkime modeliuoti savo procesą ir tam naudokite veiklos diagramą. Pirmiausia leiskite man paaiškinti, kaip aukščiau pateikti kodai bus naudojami modelyje. Tai lengviau paaiškinti grafiniu pavyzdžiu, tačiau tuo pat metu išanalizuosime kai kuriuos (beveik visus mums reikalingus) Veiklos diagramos elementus.
Išanalizuokime šį fragmentą:
...
Voverė dainuoja dainas, (P1, A1)
Taip, jis graužia visus riešutus, (P2)
Ir riešutai nėra paprasti, (C1)
Visi lukštai yra auksiniai, (C2)
Gryno smaragdo branduoliai; (C3)
...
Turime du proceso etapus P1 ir P2, dalyvį A1 ir trijų skirtingų klasių objektus: į žingsnį įvedamas C1 klasės objektas, dėl šio žingsnio P2 veiklos išvedami C3 ir C2 klasių objektai. procesas. Diagramai naudojame šiuos modeliavimo elementus.
Mūsų proceso fragmentas gali būti pavaizduotas maždaug taip (1 pav.).
1 pav. Veiklos diagramos fragmentas
Norėdami organizuoti erdvę ir struktūrizuoti veiklos diagramą, naudosime nestandartinį metodą klasikinio UML žymėjimo naudojimo požiūriu. Tačiau tam yra keletas priežasčių. Pirma, prieš pat modeliavimo pradžią sudarysime vadinamąjį modeliavimo sutartis, kuriame įrašome visas žymėjimo naudojimo ypatybes. Antra, šis metodas buvo ne kartą sėkmingai pritaikytas verslo modeliavimo stadijoje realiuose projektuose kuriant programinės įrangos sistemas, rezultatus mūsų nedidelė autorių komanda įrašė į atitinkamą autorių teisių objektą [6], taip pat panaudojo mokymo vadove [; 7]. Veiklos diagramoje apibrėžiame, kad diagramos laukas sudarytas naudojant „plaukimo juostas“. Takelio pavadinimas atitiks diagramos elementų, kurie bus patalpinti tame takelyje, tipą.
„Įvesties ir išvesties artefaktai“: Šiame takelyje bus objektų elementai – objektai, kurie yra naudojami arba yra kažkokio proceso žingsnio vykdymo rezultatas.
"Proceso žingsniai": Čia patalpinsime Veiklos elementus – proceso dalyvių veiksmus.
„Dalyviai“: kelias elementams, kurie žymės veiksmo atlikėjų vaidmenis mūsų procese, jiems naudosime tą patį modeliuojantį elementą Objektas - objektą, bet prie jo pridėsime stereotipą „Aktorius“.
Kitas takelis vadinamas „Verslo taisyklės“ ir šiame takelyje teksto forma patalpinsime proceso žingsnių vykdymo taisykles, o tam naudosime modeliavimo elementą Pastaba – pastaba.
Čia sustosime, nors galėtume pasinaudoti ir taku "Įrankiai" rinkti informaciją apie procesų automatizavimo lygį. Taip pat gali praversti kelias „Dalyvių pozicijos ir pasiskirstymas“, jis gali būti naudojamas vaidmenims susieti su proceso dalyvių pareigomis ir skyriais.
Viskas, ką ką tik aprašiau, yra fragmentas modeliavimo konvencijos, ši sutarties dalis susijusi su vienos diagramos sutvarkymo taisyklėmis ir atitinkamai jos rašymo bei skaitymo taisyklėmis.
"Receptas"
Dabar apsvarstykime galimybę konkrečiai modeliuoti sistemą iš veiklos diagramos. Tai tik vienas iš variantų, pastebiu, kad tai, žinoma, ne vienintelis. Veiklos diagrama mus sudomins savo vaidmeniu pereinant nuo proceso modeliavimo prie automatizuotos sistemos projektavimo. Norėdami tai padaryti, laikysimės metodinių rekomendacijų - savotiško recepto, susidedančio iš tik penkių etapų ir numatančio tik trijų tipų diagramų kūrimą. Naudodami šį receptą galėsime gauti formalų proceso, kurį norime automatizuoti, aprašymą ir rinkti duomenis sistemos projektavimui. O studentams, pradedantiems studijuoti UML, tai savotiškas gelbėtojas, kuris neleis paskęsti visoje UML ir šiuolaikinių modeliavimo priemonių vaizdinių priemonių ir technikų įvairovėje.
Tiesą sakant, čia yra pats receptas, o tada vadovaukitės diagramomis, sukurtomis mūsų „pasakų“ temai.
1 etapas. Procesą aprašome veiklos diagramos forma. Procesui, kuriame yra daugiau nei 10 žingsnių, tikslinga taikyti proceso etapų skaidymo principą, kad būtų pagerintas diagramos skaitomumas.
2 etapas. Pasirinkite, ką galima automatizuoti (pvz., žingsnius galima paryškinti diagramoje).
3 etapas. Automatizuotam žingsniui turi būti priskirta sistemos funkcija arba funkcijos (ryšys gali būti daug su daug), nubraižykite naudojimo atvejo diagramą. Tai yra mūsų sistemos funkcijos.
4 etapas. Aprašykime vidinę AS organizaciją naudodami klasių diagramą - Klasė. „Įvesties ir išvesties objektai (dokumentai)“ plaukimo takas veiklos diagramoje yra objekto modelio ir esybės santykių modelio kūrimo pagrindas.
5 etapas. Išanalizuokime „Verslo taisyklių“ takelio pastabas, jose numatyti įvairūs apribojimai ir sąlygos, kurios palaipsniui virsta nefunkciniais reikalavimais.
Gautas diagramų rinkinys (Activity, Use-case, Class) pateikia mums formalizuotą aprašymą gana griežtu užrašu, t.y. turi nedviprasmišką skaitymą. Dabar galite kurti technines specifikacijas, patikslinti reikalavimų specifikacijas ir pan.
Pradėkime modeliuoti.
1 etapas. Apibūdinkite procesą veiklos diagramos forma
Priminsiu, kad diagramos lauką sudarėme naudodami „plaukimo“ juostas, kiekvienoje juostoje yra to paties tipo elementų (2 pav.). Be aukščiau aprašytų diagramos elementų, naudosime papildomus elementus, apibūdinkime juos.
Sprendimas (Decision) diagramoje žymi mūsų proceso šakojimosi tašką, o gijų sujungimas (Merge) – jų susijungimo tašką. Perėjimo sąlygos ant perėjimų rašomos laužtiniuose skliaustuose.
Tarp dviejų sinchronizatorių (Fork) parodysime lygiagrečias proceso šakas.
Mūsų procesas gali turėti tik vieną pradžią – vieną įėjimo tašką (pradinį). Tačiau gali būti keletas užbaigimų (galutinis), bet ne mūsų konkrečioje diagramoje.
Yra gana daug rodyklių su daugybe elementų ir jungčių, pirmiausia galite nustatyti proceso etapus, o tada atlikti šių etapų skaidymą. Tačiau aiškumo dėlei norėčiau parodyti visą mūsų „pasakų“ procesą vienoje diagramoje, tuo tarpu, žinoma, turime užtikrinti, kad rodyklės „nesuliptų“, būtų galima tiksliai sekti, kas yra sujungta. Kam.
2 pav. Veiklos diagrama – bendras proceso vaizdas
Nes poetinėse eilutėse kai kurios proceso detalės praleistos, jas teko restauruoti, jas rodo elementai su baltu fonu. Ši informacija apima perdavimo / priėmimo saugojimo ir apdorojimo veiksmą ir keletą įvesties ir išvesties artefaktų. Verta paminėti, kad šis žingsnis taip pat nevisiškai atskleidžia procesą, nes turėtume atskirai nurodyti perdavimo žingsnį ir priėmimo žingsnį ir netgi pridėti atskirą žingsnį kriauklėms, taip pat galvoti, kad pirmiausia visos šios materialinės vertybės turėtų būti laikinai kažkur saugomos ir pan. ir taip toliau.
Atkreipkime dėmesį ir į tai, kad lieka neatsakytas klausimas apie riešutų kilmę – iš kur jie atsiranda ir kaip jie patenka į voverę? Ir šis klausimas (jis pastaboje pažymėtas raudonu šriftu - elementas Pastaba) reikalauja atskiro tyrimo! Taip dirba analitikas – po truputį renka informaciją, daro prielaidas ir gauna „gerai“ arba „ne-gerai“ iš dalyko ekspertų – labai svarbių ir tiesiog nepakeičiamų žmonių verslo modeliavimo stadijoje kuriant sistemas.
Taip pat atkreipkite dėmesį, kad proceso žingsnis P5 susideda iš dviejų dalių.
Ir mes išskaidysime kiekvieną dalį ir apsvarstysime ją išsamiau (3 pav., 4 pav.), nes per šiuos konkrečius veiksmus atliekama veikla bus automatizuota.
3 pav. Veiklos schema – detalizavimas (1 dalis)
4 pav. Veiklos schema – detalizavimas (2 dalis)
2 etapas. Pasirinkite, ką galima automatizuoti
Automatizuotini žingsniai diagramose paryškinti spalvotai (žr. 3 pav., 4 pav.).
Visus juos atlieka vienas proceso dalyvis – raštvedys:
- Įveda informaciją apie veržlės svorį į pareiškimą;
- Įveda informaciją apie veržlės perkėlimą į išrašą;
- Užfiksuoja riešuto virsmo kevalais ir branduoliu faktą;
- Įveda informaciją apie riešuto branduolį į teiginį;
- Įveda informaciją apie riešutų kevalus į sąrašą.
Atliktų darbų analizė. Kas toliau?
Taigi, atlikome daug parengiamųjų darbų: surinkome informaciją apie procesą, kurį ketiname automatizuoti; pradėjo formuoti susitarimą dėl modeliavimo (kol kas tik dėl Veiklos diagramos naudojimo); atliko proceso modeliavimą ir net išskaidė kelis jo žingsnius; Mes nustatėme proceso veiksmus, kuriuos automatizuosime. Dabar esame pasirengę pereiti prie kitų žingsnių ir pradėti kurti sistemos funkcionalumą bei vidinę organizaciją.
Kaip žinote, teorija be praktikos yra niekas. Būtinai turėtumėte pabandyti „modeliuoti“ savo rankomis, tai taip pat naudinga norint suprasti siūlomą požiūrį. Pavyzdžiui, galite dirbti modeliavimo aplinkoje [3]. Mes išskaidėme tik dalį bendros proceso diagramos žingsnių (žr. 2 pav.). Kaip praktinę užduotį, jūsų gali būti paprašyta pakartoti visas diagramas Modelio aplinkoje ir atlikti veiksmo „Perdavimas / priėmimas saugojimui ir apdorojimui“ išskaidymą.
Kol kas nesvarstome dirbti konkrečioje modeliavimo aplinkoje, tačiau tai gali tapti nepriklausomų straipsnių ir apžvalgų tema.
Antroje straipsnio dalyje analizuosime 3-5 etapuose būtinus modeliavimo ir projektavimo būdus, naudosime UML naudojimo atvejų ir klasių diagramas. Tęsinys.
Šaltinių sąrašas
- Svetainė "UML2.ru". Analitikų bendruomenės forumas. Bendras skyrius. Pavyzdžiai. Pasakų pavyzdžiai UML diagramų pavidalu. [Elektroninis išteklius] Prieigos režimas: internetas:
- Sparx Systems svetainė. [Elektroninis išteklius] Prieigos režimas: internetas:
- Modelio svetainė. [Elektroninis išteklius] Prieigos režimas: internetas:
- Didysis enciklopedinis žodynas. Procesas (interpretacija). [Elektroninis išteklius] Prieigos režimas: internetas:
- Tinklalapis „Efektyvaus valdymo organizavimas“. Dienoraštis. Rubrika „Verslo procesų valdymas“. Verslo proceso apibrėžimas. [Elektroninis išteklius] Prieigos režimas: internetas:
- Intelektinės veiklos rezultato produkto įregistravimo ir deponavimo pažymėjimas Nr. 18249. Alfimovas R.V., Zolotukhina E.B., Krasnikova S.A. Mokymo priemonės „Dalyko modeliavimas naudojant įmonės architektą“ rankraštis // 2011 m.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Verslo procesų modeliavimas. - M .: KURS, NITs INFRA-M, EBS Znanium.com. – 2017 m.
Šaltinis: www.habr.com