"Isang araw sa buhay ng isang ardilya" o mula sa pagmomodelo ng proseso hanggang sa disenyo ng isang automated na wealth accounting system na "Belka-1.0" (Bahagi 2)
Buod ng nakaraang episode
Π Gumamit kami ng domain na "fairy tale", na inspirasyon ng mga halimbawa ng pag-aaral ng mga diagram ng UML batay sa mga plot ng fairy tale (tingnan, halimbawa, [1]). Bago magsimula ang pagmomodelo, nagkasundo kami sa paggamit ng ilang elemento ng Activity diagram at nagsimulang bumuo ng isang kasunduan sa pagmomodelo. Isinasaalang-alang ang mga kasunduang ito, sa unang yugto ay inilarawan namin ang proseso sa anyo ng mga diagram ng Aktibidad, at sa ika-1 yugto ay natukoy namin ang mga hakbang sa proseso kung saan kinakailangan ang automation (at posible).
Ipaalala ko sa iyo na isa-automate namin ang aktibidad ng accounting para sa mga materyal na asset, na lumitaw sa mga prosesong ito.
...
Isang isla ang nasa dagat, (E1, E2)
May granizo sa isla (E3, E1)
May mga simbahang may gintong simboryo, (E4)
May mga tore at hardin; (E5, E6)
Ang isang puno ng spruce ay tumutubo sa harap ng palasyo, (E7, E8)
At sa ibaba nito ay isang kristal na bahay; (E9)
Isang maamo na ardilya ang nakatira doon, (A1)
Oo, anong pakikipagsapalaran! (A1)
Ang ardilya ay umaawit ng mga kanta, (P1, A1)
Oo, patuloy siyang nangangagat ng mani, (P2)
Ngunit ang mga mani ay hindi simple, (C1)
Ang lahat ng mga shell ay ginto, (C2)
Ang core ay purong esmeralda; (C3)
Binabantayan ng mga alipin ang ardilya, (P3, A2)
Pinaglilingkuran nila siya bilang iba't ibang lingkod (P4)
At isang klerk ang itinalaga (A3)
Ang isang mahigpit na account ng mga mani ay ang balita; (P5, C1)
Binabati siya ng hukbo; (P6, A4)
Isang barya ang ibinubuhos mula sa mga shell, (P7, C2, C4)
Hayaan silang maglibot sa mundo; (P8)
Ang mga batang babae ay nagbuhos ng esmeralda (P9, A5, C3)
Sa mga kamalig, at sa ilalim ng takip; (E10, E11)
...
(A.S. Pushkin "The Tale of Tsar Saltan, ng kanyang maluwalhati at makapangyarihang bayani na si Prince Guidon Saltanovich at ang magandang Prinsesa Swan", )
Sa halimbawang ito gumagamit ako ng Enterprise Architect framework mula sa isang kumpanya sa Australia [2], at sa mga sesyon ng pagsasanay ay ginagamit ko [3].
Ipaalala ko sa iyo na mayroong iba't ibang mga proseso, maaari kang maging pamilyar, halimbawa, [4] at [5].
Para sa higit pang mga detalye sa mga inilapat na diskarte sa pagmomodelo at disenyo, tingnan ang [6, 7].
Para sa kumpletong detalye ng UML, tingnan [8].
Handa na kaming magpatuloy sa mga susunod na hakbang at simulan ang pagdidisenyo ng functionality ng system at panloob na organisasyon. Magpapatuloy ang pagbilang ng mga guhit.
Stage 3. Ang automated na hakbang ay dapat na nauugnay sa isang function o function ng system
Ang automated system (AS) na binuo ay idinisenyo upang mapanatili ang mahigpit na mga talaan ng mga mani, tandaan? Para sa bawat naka-highlight na hakbang (tingnan ang Figure 3, Figure 4 ), na aming isa-automate, isulat ang isang functional na kinakailangan gamit ang humigit-kumulang sumusunod na konstruksiyon: "Dapat ipatupad ng system ang kakayahan..." at bumuo ng isang Use-case diagram. Nagdaragdag kami ngayon ng mga bagong panuntunan sa aming kasunduan sa pagmomodelo. Hayaan akong ipaliwanag kung anong mga elemento ang gagamitin natin.
Gagamitin namin ang "Association" na koneksyon sa pagitan ng "User Role" at ang "Function" (Figure 5), nangangahulugan ito na ang isang user na may ganitong tungkulin ay maaaring gumanap ng function na ito.
Figure 5. Paggamit ng relasyong uri ng Association
Mula sa "Function" hanggang sa "Requirement" iguguhit namin ang "Implementation" na koneksyon (Figure 6) para ipakita na ang pangangailangang ito ay ipapatupad ng mga function na ito; ang relasyon ay maaaring "many-to-many", i.e. Ang isang function ay maaaring kasangkot sa pagpapatupad ng ilang mga kinakailangan, at higit sa isang function ay maaaring kailanganin upang ipatupad ang isang kinakailangan.
Figure 6. Gamit ang uri ng relasyong "Pagpapatupad".
Kung ang isang function ay nangangailangan para sa pagpapatupad nito na ang ilang iba pang function ay isakatuparan, at kinakailangan, gagamitin namin ang "Dependency" na koneksyon sa "Isama" na stereotype (Figure 7). Kung ang pagpapatupad ng isang karagdagang function ay kinakailangan sa ilalim ng ilang mga kundisyon, pagkatapos ay gagamitin namin ang "Dependency" na koneksyon sa "Extend" stereotype. Napakadaling tandaan ng lahat: Ang "Isama" ay LAGING, at ang "I-extend" ay MINSAN.
Figure 7. Gamit ang relasyong βDependency (inclusion)β.
Bilang resulta, ang aming diagram ay magiging ganito ang hitsura (Larawan 8).
Figure 8. Use-case diagram (functional na modelo ng AC)
Bilang karagdagan, ang isang Use-case diagram ay ginagamit upang imodelo ang mga tungkulin ng user (Figure 9).
Figure 9. Use-case diagram (mga tungkulin ng mga gumagamit ng AS)
Stage 4. Ilarawan natin ang panloob na organisasyon ng AS gamit ang isang class diagram
Gamit ang impormasyon tungkol sa input at output artifact ng aming proseso (tingnan ang Activity diagram - Figure 2, Figure 3, Figure 4), bubuo kami ng class diagram. Gagamitin namin ang mga elemento ng pagmomodelo ng "Class" at iba't ibang uri ng koneksyon sa pagitan ng mga ito.
Upang ipakita ang "buong-bahagi" na relasyon, gagamitin namin ang isang relasyon ng uri ng "Pagsasama-sama" (Figure 10): ang nut ay ang kabuuan, at ang mga shell at kernel ay ang mga bahagi.
Figure 10. Whole-part relationship
Bilang resulta, ang isang fragment ng aming diagram ay magiging ganito ang hitsura (Figure 11). Ang mga klase na direkta naming na-highlight sa paglalarawan ng teksto ng proseso ay minarkahan ng kulay.
Larawan 11. Class diagram
Ginamit din ang class diagram upang mag-modelo ng iba pang mga artifact - hindi lamang ang mga nauugnay sa konseptwal na modelo ng automated na proseso ng accounting para sa mga materyal na asset, ngunit nauugnay din sa kapaligiran ng pagpapatupad - ang kapaligiran (Larawan 12) at "kapitbahay" mga proseso (Figure 13) na maaaring maka-impluwensya sa automated na proseso, ngunit wala pa sa pokus ng aming pansin (ipinapalagay namin na bubuo ang system at magiging kapaki-pakinabang ang impormasyong ito).
Figure 12. Class diagram (environment)
Ang relasyon sa mana ay nagpapakita ng generalization ng iba't ibang mga gusali, "bata" na mga klase, sa ilalim ng pangkalahatang "magulang" na klase na "Gusali".
Figure 13. Class diagram (karagdagang impormasyon tungkol sa mga artifact)
Ang "reaksyon sa sitwasyon" ay depende sa "Visual control data". Para sa ilang dependency na relasyon, ang "trace" na stereotype ay ginagamit upang ipakita ang pagsubaybay sa mga klase na hindi tahasang tinukoy sa paglalarawan ng proseso, ngunit kinakailangan upang i-automate ito, sa mga klase na ang mga pagkakataon ay tahasang isinangguni sa aming paglalarawan.
Stage 5. Suriin natin ang mga tala sa track na "Mga Panuntunan sa Negosyo".
Ang mga patakaran ay tinukoy (tingnan ang Larawan 2 ):
- ang pangangailangan na hatiin ang isa sa mga hakbang sa 2 bahagi, ang pangalawang bahagi ay nagsisimula na maisakatuparan lamang sa ilalim ng ilang mga kundisyon;
- appointment ng isang tiyak na opisyal upang isagawa ang accounting ng mga mani;
- isang pamamaraan (puting kulay ng mga elemento) na nagpapahiwatig na ang elemento ay hindi tahasang tinukoy sa paglalarawan ng proseso.
Dapat tandaan na nagamit na namin ang lahat ng mga patakarang ito kapag bumubuo ng mga diagram.
Panghuling pangungusap
Kaya, dumaan kami sa 5 yugto at bumuo ng 3 uri ng mga diagram. Magdaragdag ako ng isang maliit na komento tungkol sa organisasyon ng aming mga modelo sa kapaligiran ng pagmomolde. Mayroong malaking bilang ng mga balangkas na tumutulong sa pagbuo ng mga modelong binuo, ngunit hindi ito ang paksa ng artikulong ito, kaya lilimitahan namin ang aming mga sarili sa sumusunod na simpleng hanay ng mga pakete para sa maayos na pamamahala ng aming proyekto: Business Process, Functional Model , Artifact, Kalahok at Kapaligiran (Larawan 14).
Larawan 14. Istraktura ng pakete ng proyekto
Kaya, nakabuo kami ng mga pare-parehong modelo na naglalarawan sa materyal na sistema ng accounting mula sa iba't ibang aspeto: isang modelo ng isang awtomatikong proseso ng negosyo, isang functional na modelo at isang modelo ng panloob na organisasyon ng system sa antas ng konsepto.
Listahan ng mga mapagkukunan
- Website na "UML2.ru". Forum ng Komunidad ng Analyst. Pangkalahatang seksyon. Mga halimbawa. Mga halimbawa ng mga fairy tale na naka-format bilang mga diagram ng UML. [Electronic na mapagkukunan] Access mode: Internet:
- Website ng Sparx Systems. [Electronic na mapagkukunan] Access mode: Internet:
- Website ng Modelio. [Electronic na mapagkukunan] Access mode: Internet:
- Malaking Encyclopedic Dictionary. Proseso (interpretasyon). [Electronic na mapagkukunan] Access mode: Internet:
- Website na "Organisasyon ng Epektibong Pamamahala". Blog. Kategorya "Pamamahala ng Proseso ng Negosyo". Kahulugan ng isang proseso ng negosyo. [Electronic na mapagkukunan] Access mode: Internet:
- Sertipiko No. 18249 sa pagpaparehistro at pagdeposito ng isang gawain ng intelektwal na aktibidad. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manuskrito ng tulong sa pagtuturo na pinamagatang "Pagmomodelo ng isang paksa gamit ang Enterprise Architect" // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Pagmomodelo ng proseso ng negosyo. β M.: KURSO, SIC INFRA-M, EBS Znanium.com. β 2017.
- Detalye ng OMG Unified Modeling Language (OMG UML). Bersyon 2.5.1. [Electronic na mapagkukunan] Access mode: Internet:
Pinagmulan: www.habr.com