„En dan iz življenja veverice“ ali od modeliranja procesov do oblikovanja avtomatiziranega sistema za evidenco materialnih vrednot „Veverica-1.0“ (Del 1)
Kaj ima skupnega z „veverico“?
Takoj bom pojasnila, kaj ima skupnega z „veverico“. Na spletu sem naletela na zabavne projekte za učenje UML, ki temeljijo na predmetnem področju, ukradenem iz zgodb (na primer, [1]), zato sem se odločila tudi za svoje študente pripraviti podoben primer, da bi lahko proučili na začetku vse tri vrste diagramov: Diagram aktivnosti, Diagram uporabe in Razredni diagram. Namerno ne prevajam nazivov diagramov v slovenščino, da bi se izognila razpravam o „težavah pri prevodu“. O tem, kaj je za kaj, bom malo kasneje pojasnila. V tem primeru uporabljam okolje Enterprise Architect avstralskega podjetja [2] – dober pripomoček za razumen denar. V okviru učnih ur pa uporabljam [3], kar je dobro orodje za objektno usmerjeno oblikovanje, ki podpira standarde UML2.0 in BPMN, brez odvečnih dizajnerskih možnosti, vendar povsem zadostno za učenje osnov jezika.
Avtomatizirali bomo dejavnosti evidenc materialnih vrednot, ki se pojavljajo v teh procesih.
…
Otrok na morju leži, (E1, E2)
Mesto na otoku stoji (E3, E1)
Z zlatokranjskimi cerkvami, (E4)
Z hišami in vrtovi; (E5, E6)
Jelka raste pred palačo, (E7, E8)
In pod njo kristalna hiša; (E9)
Tam živi roža veverica, (A1)
In kakšna iznajdljivka! (A1)
Veverica poje pesmi, (P1, A1)
In oreške grize, (P2)
In oreški niso navadni, (C1)
Vse lupine so zlate, (C2)
Jedra so čisti smaragd; (C3)
Uslužbenci varujejo veverico, (P3, A2)
Služijo ji razna služina (P4)
In je dodeljen odličen uradnik (A3)
Natančna računica oreškom; (P5, C1)
Da ji vojska čast odda; (P6, A4)
Iz lupin vlijejo kovance, (P7, C2, C4)
In jih spuščajo v svet; (P8)
Dekleta mečejo smaragd (P9, A5, C3)
V skladišča in pod pokrov; (E10, E11)
…
(A.S. Puškina „Pravljica o carju Saltanu, o njegovem slavljenskem in mogočen bogatiru knezu Gvidonu Saltanoviču in o čudoviti kraljici Labod“, — 10 let od zamisla do objave, mimogrede!)
Malo o kodih, napisanih desno od vrstic. “A” (od “Actor”) pomeni, da vrstica vsebuje informacije o udeležencu procesa. “C” (od “Class”) – informacije o objektih razredov, ki se obdelujejo med izvajanjem procesov. “E” (od “Environment”) – informacije o objektih razredov, ki karakterizirajo okolje izvajanja procesov. “P” (od “Process”) – informacije o samih procesih.
Pravzaprav natančna definicija procesa tudi trdi, da lahko postane predmet metodoloških sporov, vsaj zaradi dejstva, da procesi obstajajo v različnih oblikah: poslovni, proizvodni, tehnološki itd. (spoznati je mogoče, na primer, [4] in [5]). Da bi se izognili polemiki, se dogovorimo, da nas proces zanima z vidika njegove ponovljivosti skozi čas in potrebe po avtomatizaciji, tj. prenosa izvajanja določenega dela operacij procesa na avtomatiziran sistem.
Opombe k uporabi Activity diagram
Začnimo z modeliranjem našega procesa in pri tem uporabimo Activity diagram. Najprej pojasnim, kako se bodo zgoraj navedeni kodi uporabljali v modelu. Lažje je razlagati na grafičnem primeru, ob tem pa bomo obravnavali nekatere (skoraj vse potrebne) elemente Activity diagrama.
Analyziral bomo naslednji fragment:
…
Veverica poje pesmi, (P1, A1)
In oreške grize, (P2)
In oreški niso navadni, (C1)
Vse lupine so zlate, (C2)
Jedra so čisti smaragd; (C3)
…
Imamo dva koraka procesa P1 in P2, udeleženca A1 ter objekte treh različnih razredov: objekt razreda C1 vstopa v korak, objekti razredov C2 in C3 pa se pridobijo na izhodu kot rezultat delovanja tega koraka P2 našega procesa. Za diagram bomo uporabili naslednje modelarske elemente.
Fragment našega procesa lahko predstavimo približno tako (Slika 1).
Slika 1. Fragment Activity diagrama
Za organizacijo prostora in strukturiranje Activity diagrama bomo uporabili ne povsem standarden pristop, kar se tiče klasične uporabe UML notacije. A to ima več razlogov. Prvič, preden začnemo modeliranje, bomo pripravili tako imenovano, dogovor o modeliranju, v katerem bomo zabeležili vse značilnosti uporabe notacije. Drugič, ta pristop je bil večkrat uspešno uporabljen v fazi poslovnega modeliranja v realnih projektih za ustvarjanje programski sistemov, rezultati pa so bili zabeleženi s strani naše majhne avtorsko skupine v ustreznem predmetu avtorskih pravic [6] in uporabljeni v učbeniku [7]. Za diagram aktivnosti bomo določili, da bo polje diagrama strukturirano s "plavajočimi" pasovi - Swim lanes. Ime pasu bo ustrezalo vrsti elementov diagrama, ki bodo postavljeni na ta pas.
„Vhodni in izhodni artefakti“: na tem pasu bodo nameščeni elementi Objects – objekti, ki se uporabljajo ali so rezultat izvedbe določene faze procesa.
„Koraki procesa“: tukaj bomo postavili elemente Activity – dejanja udeležencev procesa.
„Udeleženci“: pas za elemente, ki bodo označevali vloge izvajalcev dejanj v našem procesu, za njih bomo uporabili isti oblikovni element Object – objekt, vendar bomo dodali stereotip „Actor“.
Naslednji pas se imenuje „Poslovna pravila“ in na tem pasu bomo v besedilni obliki umestili pravila za izvajanje korakov procesa, pri čemer bomo uporabili oblikovni element Note – opomba.
Tukaj se ustavimo, čeprav bi bilo mogoče dodatno uporabiti pas „Orodja“ za zbiranje informacij o ravni avtomatizacije procesa. Še lahko bo koristen pas „Delovna mesta in oddelki udeležencev“, ki ga lahko uporabimo za povezavo vlog s delovnimi mesti in oddelki udeležencev procesa.
Vse, kar sem pravkar opisala, je fragment dogovora o modeliranju, ta del dogovora se nanaša na pravila organizacije enega diagrama in ustrezno na pravila njegovega pisanja in branja.
„Recept“
Sedaj razmislimo o različici modeliranja sistema natančno z diagrama aktivnosti. To je samo jedna od mogućnosti, napominjem da ona, naravno, nije jedina. Dijagram aktivnosti će nas zanimati s obzirom na svoju ulogu u prelazu od modeliranja procesa do dizajniranja automatiziranog sistema. U tu svrhu ćemo se držati metodoloških preporuka – svojevrsnog recepta koji se sastoji od pet etapa i predviđa izradu tri vrste dijagrama. Primjena ovog recepta pomoći će nam da dobijemo formalizovani opis procesa koji želimo automatizovati i prikupimo podatke za dizajn sistema. A za studente na početku učenja UML-a, to je svojevrstni pojas za spasavanje koji neće dopustiti da se utone u bogatstvo prikaznih sredstava i tehnika koje postoje u UML-u i savremenim alatima za modeliranje.
Evo, zapravo, samog recepta, a zatim slijede dijagrami izrađeni za našu "bajkovitu" predmetnu oblast.
Etapa 1. Opisujemo proces u obliku dijagrama aktivnosti. Za procese u kojima je izdvojeno više od 10 koraka, ima smisla primijeniti princip dekompozicije koraka procesa kako bi se poboljšala čitljivost dijagrama.
Etapa 2. Izdvajamo ono što se može automatizovati. (koraci mogu biti, na primjer, označeni na dijagramu).
Etapa 3. Automatizovanom koraku treba dodijeliti funkciju ili funkcije sistema. (odnos može biti mnogi-na-mnogi), crtamo dijagram slučajeva korištenja. To su funkcije našeg sistema.
Etapa 4. Opisujemo unutrašnju organizaciju AS pomoću dijagrama klasa. – Klasa. Plivačka staza "Ulazni i izlazni objekti (dokumenti)" na dijagramu aktivnosti - to je osnova za građenje objektne modela i modela entitet-veza.
Etapa 5. Analiziramo beleške na stazi "Poslovna pravila"., ona donosi razne vrste ograničenja i uslova, postepeno se transformišući u nefunkcionalne zahteve.
Dobijena zbirka dijagrama (Aktivnosti, slučaja korištenja, Klasa) daje nam formalizovani opis u dovoljno strogoj notaciji, tj. ima jednoznačno čitanje. Sada možemo razvijati tehničke specifikacije, precizirati specifikaciju zahteva itd.
Hajde da počnemo sa modeliranjem.
Etapa 1. Opisujemo proces u obliku dijagrama aktivnosti.
Pripomnim, da smo polje diagrama strukturirali s pomočjo "plavajočih" pasov, na vsakem pasu so razporejeni elementi iste vrste (Slika 2). Poleg zgoraj opisanih elementov diagrama bomo uporabili dodatne elemente, ki jih bomo opisali.
Odločitev (Decision) označuje na diagramu točko razvejanja našega procesa, združitev tokov (Merge) pa točko njihove ponovne povezave. V kvadratnih oklepajih na prehodih so zapisani pogoji prehoda.
Med dvema sinhronizatorjema (Fork) bomo prikazali paralelne veje procesa.
Naš proces ima lahko le en začetek – eno vstopno točko (Initial). Ima pa lahko več zaključkov (Final), vendar ne za naš konkretni diagram.
Puščic je precej, pri velikem številu elementov in povezav lahko najprej izpostavimo faze procesa, nato pa naredimo dekonstrukcijo teh faz. Vendar bi naš "pravljčni" proces rad za boljšo preglednost pokazal v celoti na enem diagramu, pri čemer je treba seveda doseči, da puščice "niso združene", da bi lahko natančno spremljali, s čem je kaj povezano.
Slika 2. Diagram Activity – splošni pogled na proces
Ker so v pesniških vrsticah nekatere podrobnosti procesa izpuščene, smo jih morali obnoviti, prikazane so z elementi z belim ozadjem. Te podrobnosti vključujejo korak "Prenosa/prejema za shranjevanje in predelavo" ter nekaj vhodnih in izhodnih artefaktov. Omeniti je treba, da ta korak tudi ne razkriva popolnoma procesa, saj bi morali posebej označiti korak prenosa in korak sprejema, dodatno pa dodati poseben korak za lupine ter razmišljati, da bi morale biti vse te materialne vrednote nekje začasno shranjene itd.
Poglejmo še, da je vprašanje o izvoru oreščkov še vedno brez odgovora – od kje prihajajo in kako pridejo do veverice? In to vprašanje (izpostavljeno z rdečo barvo v opombi – element Note) zahteva posebno obravnavo! To je delo analitika – da zbira informacije po koščkih, postavlja hipoteze in prejme "ok" ali "ne-ok" od strokovnjakov v predmetni področju – zelo pomembnih in preprosto nepogrešljivih ljudi v fazi poslovnega modeliranja pri oblikovanju sistemov.
Prav tako naj opozorimo, da korak procesa P5 sestavlja dve deli.
In each part we will decompose and examine in more detail (Figure 3, Figure 4), as the activities carried out within these steps will be automated.
Figure 3. Activity Diagram – Detail (Part 1)
Figure 4. Activity Diagram – Detail (Part 2)
Etapa 2. Izdvajamo ono što se može automatizovati.
The steps subject to automation are highlighted in color on the diagrams (see Figure 3, Figure 4).
All actions are performed by a single process participant – the clerk:
- Enters information about the weight of the nut into the ledger;
- Enters information about the transfer of the nut into the ledger;
- Records the fact of transforming the nut into shells and the kernel;
- Enters information about the kernel of the nut into the ledger;
- Enters information about the shells of the nut into the ledger.
Analysis of the work done. What’s next?
So, we have completed significant preparatory work: we gathered information about the process we intend to automate; started formulating an agreement on modeling (only regarding the use of the Activity diagram for now); modeled the process and even decomposed several of its steps; highlighted the steps of the process that we will automate. Now we are ready to move on to the next stages and begin designing the system functions and its internal organization.
As is known, theory without practice is nothing. It is essential to try 'modeling' with your own hands; this is useful for understanding the proposed approach. For example, one can work in a modeling environment [3]. We have only decomposed part of the steps from the high-level process diagram (see Figure 2). As a practical assignment, it may be proposed to replicate all diagrams in the Modelio environment and perform the decomposition of the step 'Transfer/accept for storage and processing'.
Working in specific modeling environments is not currently under consideration, but this may be the subject of separate articles and reviews.
In the second part of the article, we will discuss modeling and design techniques that are necessary in stages 3-5, using UML Use-case and Class diagrams. To be continued.
Spisak izvora.
- Website ‘UML2.ru’. Community Forum of Analysts. General Section. Examples. Examples of fairy tales presented as UML diagrams. [Electronic resource] Access mode: Internet:
- Sajt Sparx Systems. [Elektronski resurs] Način pristupa: Internet:
- Modelio website. [Electronic resource] Access mode: Internet:
- Velika enciklopedija. Proces (tumačenje). [Elektronski resurs] Pristup: Internet:
- Sajt 'Organizacija efektivnog upravljanja'. Blog. Rubrika 'Upravljanje poslovnim procesima'. Definicija poslovnog procesa. [Elektronski resurs] Pristup: Internet:
- Svedočanstvo br. 18249 o registraciji i deponovanju djela rezultata intelektualne delatnosti. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Rukopis nastavnog i metodološkog priručnika pod nazivom 'Modeliranje predmetne oblasti uz korišćenje Enterprise Architect' // 2011.
- Zolotukhina E.B., Višnja A.S., Krasnikova S.A. Modeliranje poslovnih procesov. — M.: KURS, NIC INFRA-M, EBS Znanium.com. — 2017.
Izvor: habr.com
