„Viena diena voverės gyvenime“ arba nuo procesų modeliavimo iki automatizuotos materialinių vertybių apskaitos sistemos „Belka-1.0“ sukūrimo (2 dalis)
Ankstesnės serijos santrauka
В naudojome „pasakų“ dalyko sritį, įkvėptą UML diagramų, pagrįstų pasakų siužetais, tyrimo pavyzdžių (žr., pvz., [1]). Prieš modeliavimą susitarėme dėl kai kurių Veiklos diagramos elementų naudojimo ir pradėjome formuoti modeliavimo sutartį. Atsižvelgdami į šias sutartis, 1-ame etape aprašėme procesą Veiklos diagramų forma, o 2-ame etape nustatėme proceso žingsnius, kuriems reikalingas (ir galimas) automatizavimas.
Priminsiu, kad š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ą sūnų princą Gvidoną Saltanovičių ir gražiąją gulbę princesę“, )
Šiame pavyzdyje naudoju Australijos įmonės Enterprise Architect aplinką. [2] ir naudoju treniruočių metu [3].
Priminsiu, kad procesai skirtingi, galima susipažinti pvz. [4] ir [5].
Daugiau informacijos apie taikomus modeliavimo ir projektavimo metodus rasite [6, 7].
Norėdami gauti visą UML specifikaciją, žr [8].
Dabar esame pasirengę pereiti prie kitų žingsnių ir pradėti kurti sistemos funkcijas bei jos vidinę organizaciją. Paveikslų numeravimas bus tęsiamas.
3 etapas. Automatizuotam žingsniui turi būti priskirta sistemos funkcija arba funkcijos
Kuriama automatizuota sistema (AS) skirta griežtai registruoti riešutus, pamenate? Kiekvienam paryškintam žingsniui (žr. 3 pav., 4 pav.). ). Dabar mes iš tikrųjų papildome savo modeliavimo sutartį naujomis taisyklėmis. Leiskite paaiškinti, kokius elementus naudosime.
Tarp „Vartotojo vaidmens“ ir „Funkcijos“ naudosime ryšį „Asociacija“ (5 pav.), o tai reiškia, kad vartotojas, turintis šį vaidmenį, gali atlikti šią funkciją.
5 pav. Asociacijos tipo ryšio naudojimas
Nuo „Funkcija“ iki „Reikalavimas“ nubraižysime nuorodą „Įgyvendinimas“ (6 pav.), kad parodytume, jog šis reikalavimas bus įgyvendintas šiomis funkcijomis, santykis gali būti „daugelis su daugeliu“, t.y. viena funkcija gali būti susijusi su kelių reikalavimų įgyvendinimu, o reikalavimui įgyvendinti gali prireikti daugiau nei vienos funkcijos.
6 pav. Įgyvendinimo ryšio naudojimas
Jei vienai funkcijai vykdyti reikia atlikti kokią nors kitą funkciją, o tai būtina, naudosime „Priklausomybės“ ryšį su „Įtraukti“ stereotipu – įtraukimu (7 pav.). Jei esant tam tikroms sąlygoms reikalingas papildomos funkcijos vykdymas, tuomet naudosime „Priklausomybės“ ryšį su „Išplėsti“ stereotipu – pratęsimu. Viską labai lengva įsiminti: „Įtraukti“ – VISADA, o „Išplėsti“ – KARTAIS.
7 pav. Nuorodos tipo „Priklausomybė (įtraukti)“ naudojimas
Dėl to mūsų diagrama atrodys maždaug taip (8 pav.).
8 pav. Naudojimo atvejų schema (funkcinis AS modelis)
Be to, vartotojų vaidmenų modeliavimui naudojama naudojimo atvejų diagrama (9 pav.).
9 pav. Naudojimo atvejų diagrama (AS naudotojų vaidmenys)
4 etapas. Aprašykime vidinę AS organizaciją naudodami klasių diagramą
Naudodami informaciją apie mūsų proceso įvesties ir išvesties artefaktus (žr. Veiklos diagramas – 2 pav., 3 pav., 4 pav.), sukursime klasių diagramą. Naudosime „Klasės“ modeliavimo elementus ir įvairių tipų ryšius tarp jų.
Norėdami parodyti „visos dalies“ ryšį, naudosime „Agregacijos“ tipo ryšį (10 pav.): riešutas yra visuma, o lukštai ir branduolys yra dalys.
10 pav. Visos dalies santykis
Dėl to mūsų diagramos fragmentas atrodys maždaug taip (11 pav.). Klasės pažymėtos spalva, kurią paryškinome tiesiogiai tekstiniame proceso aprašyme.
11 pav. Klasių diagrama
Klasių diagrama taip pat buvo naudojama modeliuojant kitus artefaktus – ne tik tuos, kurie bus svarbūs automatizuoto inventorizavimo proceso konceptualiam modeliui, bet ir susijusiems su vykdymo aplinka – aplinka (12 pav.) ir „kaimyno“ procesais (13 pav.) kurie gali turėti įtakos automatizuotam procesui, bet dar nėra mūsų dėmesio centre (manome, kad sistema vystysis ir ši informacija bus naudinga).
12 pav. Klasių diagrama (aplinka)
Paveldėjimo santykis rodo įvairių pastatų apibendrinimą, „vaikų“ klases, apibendrinančią „tėvų“ klasę „Pastatas“.
13 pav. Klasių diagrama (daugiau informacijos apie artefaktus)
„Reakcija į situaciją“ priklauso nuo „Vizualinio valdymo duomenų“. Kelioms priklausomybės ryšiams „sekimo“ stereotipas naudojamas norint parodyti klasių, kurios nėra aiškiai nurodytos proceso aprašyme, bet kurios yra būtinos jo automatizavimui, atsekimą klasėms, kurių atvejai tiksliai nurodyti mūsų aprašyme.
5 etapas. Išanalizuokime „Verslo taisyklių“ takelio pastabas
Kaip buvo nurodytos taisyklės (žr. 2 pav ):
- poreikis padalyti vieną iš žingsnių į 2 dalis, antra dalis pradedama atlikti tik tam tikromis sąlygomis;
- tam tikro pareigūno, atlikusio riešutų apskaitą, paskyrimas;
- technika (balta elementų spalva), kuri rodo, kad elementas nebuvo aiškiai nurodytas proceso aprašyme.
Reikėtų pažymėti, kad kurdami diagramas jau naudojome visas šias taisykles.
Baigiamosios pastabos
Taigi, mes perėjome 5 etapus ir sukūrėme 3 tipų diagramas. Pridėsiu nedidelį komentarą apie mūsų modelių organizavimą modeliavimo aplinkoje. Yra daug schemų, padedančių struktūrizuoti mūsų kuriamus modelius, tačiau tai nėra šio straipsnio tema, todėl apsiribosime šiais paprastais paketų rinkiniais, kad galėtume tinkamai prižiūrėti mūsų projektą: Verslo procesas, Funkcinis modelis, Artefaktai, dalyviai ir aplinka (14 pav.).
14 pav. Projekto paketų struktūra
Taigi sukūrėme nuoseklius modelius, apibūdinančius materialinių vertybių apskaitos sistemą įvairiais kampais: automatizuoto verslo proceso modelį, funkcinį modelį ir sistemos vidinės organizavimo modelį konceptualiu lygmeniu.
Š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.
- OMG vieningos modeliavimo kalbos (OMG UML) specifikacija. 2.5.1 versija. [Elektroninis išteklius] Prieigos režimas: internetas:
Šaltinis: www.habr.com