«Një ditë në jetën e një shqiponje» ose nga modelimi i proceseve në projektimin e sistemit automatizues të mbajtjes mend të vlerave materiale «Shqiponja-1.0» (Pjesa 1)
Ç'mund të ketë lidhje me «shqiponjën»?
Së pari, do ta shpjegoj lidhjen me «shqiponjën». Duke u ndeshur në internet me projekte qesharake për studimin e UML duke u mbështetur në fushën e subjektit të marrë nga përrallat (për shembull, [1]), unë vendosa gjithashtu të përgatis një shembull të tillë për studentët e mi, për të studiuar fillimisht tre lloje diagramesh: Activity Diagram, Use-case Diagram dhe Class Diagram. Qëllimisht nuk po i përkthej emrat e diagramëve në rusisht, për të shmangur mosmarrëveshjet mbi «vështirësitë e përkthimit». Çfarë është për çfarë – do ta shpjegoj pak më vonë. Në këtë shembull, po përdor ambientin Enterprise Architect nga kompania australiane [2] – një mjet i mirë për çmim të arsyeshëm. Ndërsa gjatë seancave mësimore përdor [3], një mjet falas i pranueshëm për projektimin objektiv, që mbështet standardet UML2.0 dhe BPMN, pa shumë shtesa në aspektin e kapaciteteve vizuale, por mjaft i përshtatshëm për të studiuar bazat e gjuhës.
Ne planifikojmë të automatizojmë aktivitetet për mbajtjen mend të vlerave materiale, që ndodhin në këto procese.
…
Një ishull në det është, (E1, E2)
Një qytet në ishull është (E3, E1)
Me kisha me kupola prej ari, (E4)
Me shtëpi dhe kopshte; (E5, E6)
Një bredh rritet para pallatit, (E7, E8)
Dhe poshtë tij një shtëpi kristali; (E9)
Një shqiponjë jeton aty, (A1)
Po, si një zë që do! (A1)
Një shqiponjë këndon, (P1, A1)
Po po, gërryen vetëm arrat, (P2)
Dhe arrat nuk janë të zakonshme, (C1)
Të gjitha janë me lëvore ari, (C2)
Bërthamat janë të pastra si smarald; (C3)
Duhen kujdesur për shqiponjën, (P3, A2)
I shërbejnë asaj shërbëtorë të ndryshëm (P4)
Dhe një diak i ngarkuar (A3)
Bëhet një llogari e rreptë për arrat; (P5, C1)
I japin nder të ushtarëve; (P6, A4)
Nga lëvorët derdhin monedha, (P7, C2, C4)
Dhe i dërgojnë nëpër botë; (P8)
Vajzat hedhin smarald, (P9, A5, C3)
Në depo, dhe nën mbulesë; (E10, E11)
…
(A.S. Pushkini "Përralla për mbretin Saltan, për djalin e tij të lavdishëm dhe të fuqishëm, princ Gvidon Saltanoviç dhe për princeshën e bukur Lebed", — 10 vjet nga ideja deri tek publikimi, midis të tjerash!)
Për pak fjali për kodet, të cilat shkruhen djathtas nga rreshtat. “A” (nga “Aktori”) do të thotë se në rresht ka informacion për një pjesëmarrës në proces. “C” (nga “Klasa”) – informacion në lidhje me objektet e klasave, të cilat përpunohen gjatë kryerjes së proceseve. “E” (nga “Mjedisi”) – informacion për objektet e klasave që karakterizojnë mjedisin e ekzekutimit të proceseve. “P” (nga “Procesi”) – informacion mbi vetë proceset.
Po, përveç kësaj, përcaktimi i saktë i procesit pretendon gjithashtu të shkaktojë polemika metodologjike, ndoshta për shkak se proceset janë të ndryshme: biznesore, prodhimi, teknologjike etj. etj. (mund të informoheni, për shembull, [4] dhe [5]). Për të shmangur polemikat, le të biem dakord se ne jemi të interesuar për procesin nga këndvështrimi i përsëritshmërisë së tij në kohë dhe nevojës për automatizim, pra, kalimin e kryerjes së ndonjë pjese të operacioneve të procesit në një sistem të automatizuar.
Shënime mbi përdorimin e diagramës Activity
Le të fillojmë modelimin e procesit tonë dhe të përdorim për këtë diagramën Activity. Fillimisht, do të shpjegoj se si kodet përmendura më lart do të përdoren në model. Është më e lehtë të shpjegohet në një shembull grafik, dhe për njëherë të analizojmë disa (praktikisht të gjitha të nevojshmet) elemente të diagramës Activity.
Le të analizojmë fragmentin e mëposhtëm:
…
Një shqiponjë këndon, (P1, A1)
Po po, gërryen vetëm arrat, (P2)
Dhe arrat nuk janë të zakonshme, (C1)
Të gjitha janë me lëvore ari, (C2)
Bërthamat janë të pastra si smarald; (C3)
…
Kemi dy hapa të procesit P1 dhe P2, pjesëmarrësin A1, dhe objekte të tre klasave të ndryshme: objekti i klasës C1 hyn në hap, objekteve të klasave C2 dhe C3 u jepet lëshimi, si rezultat i aktivitetit të këtij hapi P2 të procesit tonë. Për diagramën do të përdorim elementët e mëposhtëm për modelim.
Fragmenti i procesit tonë mund të paraqitet kështu (Figur 1).
Figura 1. Fragmenti i diagramës Activity
Për të organizuar hapësirën dhe strukurimin e diagramës Activity do të aplikojmë një qasje jo standarde, nga pikëpamja e përdorimit klasik të notacionit UML. Por ka disa arsye për këtë. Së pari, thjesht para fillimit të modelimit do të përgatisim, ashtu siç quhet, marrëveshjen për modelimin, në të cilin do të regjistrojmë të gjitha veçoritë e përdorimit të notacionit. Në të dytë, ky qasje është aplikuar me sukses shumë herë në fazën e modelimit të biznesit në projekte reale të krijimit të sistemeve software, rezultatet u regjistruan nga grupi ynë i vogël autorial në objektin përkatës të të drejtave të autorit [6], si dhe u përdorën në manualin mësimor [7]. Për diagramën e Aktivitetit do të përcaktojmë se fusha e diagramës do të strukturohet me
„Artefaktet hyrëse dhe dalëse“: në këtë rrugë do të vendosen elementët Objects – objekte që përdoren ose janë rezultat i disa hapat të procesit.
„Hapat e procesit“: këtu do të vendosim elementët Activity – veprimet e pjesëmarrësve të procesit.
„Pjesëmarrësit“: rruga për elementët që do të paraqesin rolet e përfaqësuesve të veprimeve në procesin tonë, për ta do të përdorim po atë element modelues Object – objekt, por do t'i shtojmë stereotipin „Aktori“.
Rruga tjetër quhet „Rregullat e biznesit“ dhe në këtë rrugë do të vendosim në formë tekstuale rregullat për realizimin e hapave të procesit, dhe për këtë do të përdorim elementin modelues Note – vërejtje.
Ne këtu do të ndalemi, megjithatë, do të ishte e mundur të përdorim një rrugë të quajtur „Mjetet“ për mbledhjen e informacioneve mbi nivelin e automatizimit të procesit. Një rrugë tjetër e dobishme mund të jetë „Pozitat dhe departamentet e pjesëmarrësve“, e cila mund të përdoret për lidhjen e roleve me pozitat dhe departamentet e pjesëmarrësve të procesit.
Të gjitha ato që sapo përshkrova, janë një fragment i marrëveshjes mbi modelimin, kjo pjesë e marrëveshjes ka të bëjë me rregullat e organizimit të një diagrami dhe për këtë arsye rregullat e tij të shkrimit dhe leximit.
„Receta“
Tani le të shqyrtojmë variantin e modelimit të sistemit pikërisht nga diagrami i Aktivitetit. Kjo është vetëm një nga opsionet, do të theksoj se nuk është sigurisht e vetmja. Diagrama Activity do të na interesojë për rolin e saj në kalimin nga modelimi i procesit në projektimin e sistemit të automatizuar. Për këtë, do të ndjekim rekomandimet metodike – një lloj recete, e cila përbëhet nga pesë etapa dhe parashikon zhvillimin e tre llojeve të diagramave. Përdorimi i kësaj recete do të ndihmojë për të marrë një përshkrim formal të procesit që dëshirojmë të automatizojmë dhe për të mbledhur të dhëna për projektimin e sistemit. Dhe për studentët në fillim të studimit të UML, kjo është si një shpëtimtar që nuk do t'i lejojë të mbyten në gjithë atë shumëllojshmëri të mjeteve vizuale dhe teknikave që ekzistojnë në UML dhe mjetet moderne të modelimit.
Ja, vetë receta, dhe më pas vijojnë diagramet e ndërtuara për fushën tonë të ‘legjendave’.
Etapa 1. E përshkruajmë procesin si një diagram Activity. Për procesin, në të cilin janë identifikuar më shumë se 10 hapa, ka kuptim të aplikohet parimi i dekompozimit të hapave të procesit, për të rritur lexueshmërinë e diagramit.
Etapa 2. Identifikojmë atë që mund të automatizohet (hapat mund të jenë, për shembull, të ndriçuar në diagram).
Etapa 3. Hapi që duhet automatizuar duhet t'i ngjitet një ose më shumë funksione të sistemit (marrëdhënia mund të jetë shumë ndaj shumë), vizatojmë diagramin e Use-case. Këto janë funksionet e sistemit tonë.
Etapa 4. E dimë organizimin e brendshëm të AS me anë të diagramit të klasave – Class. Rruga e notit “Objektet hyrëse dhe dalëse (dokumenti)” në diagramin Activity është baza për ndërtimin e modelit objektor dhe modelit entitet-lidhje.
Etapa 5. Analizojmë shënimet në rrugën “Rregullat e biznesit”, ato japin lloje të ndryshme kufizimesh dhe kushtesh, duke u transformuar gradualisht në kërkesa jo-funksionale.
Grumbulli i marrë nga diagramat (Activity, Use-case, Class) na jep një përshkrim formal në një notacion të mjaftueshëm të ngushtë, dmth. ka një kuptim të qartë. Tani mund të fillojmë të zhvillojmë një detyrë teknike, të saktësojmë specifikimin e kërkesave etj.
Të fillojmë modelimin.
Etapa 1. E përshkruajmë procesin si një diagram Activity
Dua të theksoj se fusha e diagramit e kemi strukturuar me "pista" që notojnë, ku në çdo pistë ndodhen elementë të një lloji (Imazhi 2). Përveç elementëve të përshkruar më lart, do të përdorim elemente shtesë, le t'i përshkruajmë ato.
Zgjidhja (Decision) tregon në diagramin tonë pikën e degëzimit të procesit tonë, ndërsa bashkimi i rrjedhave (Merge) është pika e rikonjohjes së tyre. Në kornizat katrore mbi kalimet janë shkruar kushtet e kalimit.
Ndërmjet dy sinkronizuesve (Fork) do të tregojmë degë të паралел për procesin.
Procesi ynë mund të ketë vetëm një fillim – një pikë të hyrjes (Initial). Por përfundime (Final) mund të kenë shumë, përveçse për diagramin tonë të veçantë.
Ka shumë shigjeta dhe, kur ka një numër të madh elementësh dhe lidhjesh, mund të filloni duke identifikuar fazat e procesit, pastaj të bëni dekompozimin e këtyre fazave. Por do të doja që procesi ynë " të ëndrrave" ta tregoj tërësisht në një diagram, duke u siguruar që shigjetat "të mos ngjiten" dhe të mund të shikojmë saktësisht se çfarë lidhet me çfarë.
Imazhi 2. Diagrami i Aktivitetit – pamja e përgjithshme e procesit
Duke qenë se në rrjeshtat poetikë disa detaje të procesit janë lënë jashtë, duhej t'i rinovojmë ato, ato shfaqen si elemente me sfond të bardhë. Këto detaje përfshijnë hapat "Transferimi/pranimi për ruajtje dhe përpunim" dhe disa artefakte hyrëse dhe dalëse. Duhet të theksohet se ky hap nuk e përshkruan plotësisht procesin, sepse do të na duhej të shpjegonim veçmas hapin e transferimit dhe hapin e pranimit, dhe më pas të shtonim veçmas një hap për gjithçka që vlen për lëvozhgat, si dhe duhet të imagjinojmë se fillimisht të gjitha këto sende materiale duhet të ruhehen diku përkohësisht etj., e kështu me radhë.
Po ashtu, le të theksojmë se mbetet ende pa përgjigje pyetja për origjinën e arrave – nga vijnë ato dhe si arrijnë te derri? Dhe kjo pyetje (ajo është shënuar me ngjyrë të kuqe në shënim – elementi Note) kërkon një përpunim të veçantë! Kështu punon analisti – duke mbledhur informacion copa-copa, duke bërë supozime dhe duke marrë "ok" ose "jo-ok" nga ekspertët e fushës – njerëz shumë të rëndësishëm dhe thjesht të pazëvendësueshëm në fazën e modelit të biznesit gjatë krijimit të sistemeve.
Le të theksojmë gjithashtu se hapi i procesit P5 përbëhet nga dy pjesë.
Dhe secilën pjesë ne e dekompozojmë dhe e shqyrtojmë më thellë (Figura 3, Figura 4), pasi aktiviteti që kryhet në kuadër të këtyre hapave do të automatizohet.
Figura 3. Diagrami Aktiviteti – detajimi (pjesa 1)
Figura 4. Diagrami Aktiviteti – detajimi (pjesa 2)
Etapa 2. Identifikojmë atë që mund të automatizohet
Hapat që do të automatizohen në diagrame janë të theksuar me ngjyrë (shih Figura 3, Figura 4).
Gjithçka e kryen një pjesëmarrës në proces – Diak urdhëra:
- Shton informacionin mbi peshën e arrës në regjistër;
- Shton informacionin mbi transferimin e arrës në regjistër;
- Regjistron faktin e shndërrimit të arrës në lëvore dhe bërthamë;
- Shton informacionin mbi bërthamën e arrës në regjistër;
- Shton informacionin mbi lëvoren e arrës në regjistër.
Analiza e punës së kryer. Çfarë ndodh më pas?
Pra, ne kemi përfunduar një punë të madhe përgatitore: mbledhim informacionin mbi procesin që do të automatizojmë; filluam të formojmë një marrëveshje mbi modelimin (për momentin vetëm në pjesën e përdorimit të diagramit Aktiviteti); kryem modelimin e procesit dhe madje realizuam dekompozimin e disa hapave të tij; identifikuam hapat e procesit që do të automatizojmë. Tani jemi të gatshëm të kalojmë në fazat e ardhshme dhe të fillojmë dizajnimin e funksioneve të sistemit dhe organizatës së brendshme të tij.
Siç dihet, teoria pa praktikë është asgjë. Është e domosdoshme të provosh 'modelimin' me duar, kjo është e dobishme dhe për të kuptuar qasjen e propozuar. Për shembull, mund të punosh në një mjedis modelimi [3]. Ne kemi dekompozuar vetëm një pjesë të hapave të diagramës së përgjithshme të procesit (shih Figura 2). Si një detyrë praktike mund të propozojmë përsëritjen e të gjithë diagrameve në mjedisin Modelio dhe realizimin e dekompozimit të hapit "Transferimi/pranimi në ruajtje dhe përpunim".
Puna në mjediset specifike të modelimit nuk është marrë në shqyrtim për momentin, por kjo mund të bëhet objekt i artikujve dhe shqyrtimeve të pavarura.
Në pjesën e dytë të artikullit ne do të shqyrtojmë teknikat e modelimit dhe projektimit që janë të nevojshme në 3-5 faza, ku do të përdorim diagramet UML Use-case dhe Class. Pjesa tjetër vazhdon.
Lista e burimeve
- Faqja "UML2.ru". Forumi i Komunitetit të Analistëve. Seksioni i Përgjithshëm. Shembuj. Shembuj përrallash të formuara në formën e diagrameve UML. [Burim elektronik] Modaliteti i qasjes: Internet:
- Faqja e Sparx Systems. [Burim elektronik] Qasja: Internet:
- Faqja Modelio. [Burim elektronik] Modaliteti i qasjes: Internet:
- Fjalori i Madh Enciklopedik. Procesi (shpjegimi). [Burim elektronik] Rehdi: Internet:
- Faqja «Organizata për menaxhimin efektiv». Blogu. Kategoria «Menaxhimi i proceseve biznesore». Definimi i procesit biznesor. [Burim elektronik] Rehdi: Internet:
- Dëshmia Nr. 18249 për regjistrimin dhe depozitimin e një vepre të rezultatit të veprimtarisë intelektuale. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manuskrypti i udhëzuesit mësimor me titull «Modelimi i fushës së subjektit me përdorimin e Enterprise Architect» // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modelimi i proceseve biznesore. — M.: KURS, NIC INFRAM, EBS Znanium.com. — 2017.
Burimi: habr.com
