«Një ditë në jetën e një kashkavi» ose nga modelimi i proceseve në projektimin e një sistemi automatizimi për llogaritjen e aseteve materiale «Belka-1.0» (Pjesa 2)
Përmbledhje e pjesës paraprake
Në ne kemi përdorur një fushë tematikë « përrallore», të frymëzuar nga shembuj të studimit të diagrameve UML me referenca në subjektet e përrallave (shih, për shembull, [1]). Para fillimit të modelimit, u dakorduam për përdorimin e disa elementeve të diagramës Activity dhe filluam të formonim një marrëveshje për modelimin. Duke marrë parasysh këto marrëveshje, ne në fazën e parë përshkruam procesin në formën e diagrameve Activity, ndërsa në fazën e dytë identifikuam hapat e procesit që kërkojnë (dhe janë të mundshme) për automatizim.
Të kujtojmë se do të automatizojmë aktivitetin e llogaritjes së aseteve materiale, i cili shfaqet në këto procese.
âŠ
Një ishull në det shtrihet, (E1, E2)
Një qytet në ishull ngrihet (E3, E1)
Me kisha me kupola ari, (E4)
Me pallate dhe kopshtet; (E5, E6)
Një bredh rritet para pallatit, (E7, E8)
Dhe nën të një shtëpi kristali; (E9)
Një squirrel jeton aty, (A1)
Eh, çfarë një e çmendur! (A1)
Një squirrel këndon këngë, (P1, A1)
Dhe vazhdon të kafshojë arrat, (P2)
Dhe arrat nuk janë të zakonshme, (C1)
Të gjitha me copat e artë, (C2)
Bërthamat e pastra janë smarald; (C3)
Slugët kujdesen për squirrel-in, (P3, A2)
I shërbejnë asaj me shërbime të ndryshme (P4)
Dhe është caktuar një zyrtar i forcës, (A3)
Një llogari e rreptë për arrat; (P5, C1)
I japin nder armëve; (P6, A4)
Nga copat këndojnë monedhën, (P7, C2, C4)
Dhe i lëshojnë në botë; (P8)
Vajzat shpërndajnë smarald (P9, A5, C3)
Në magazina dhe nën gozhdë; (E10, E11)
âŠ
(A.S. Pushkin «Përralla për mbretin Saltan, për djalin e tij të njohur dhe të fuqishëm, princin Gvidon Saltanovich dhe për bukuroshen princeshë Labud», )
Në këtë shembull përdor mjedisin Enterprise Architect nga kompania australiane Sparx Systems [2], dhe gjatë orëve mësimore aplikohet [3].
Të kujtojmë, që proceset janë të ndryshme, mund të njohim, për shembull, [4] dhe [5].
Për më shumë informacion mbi qasjet e aplikuara për modelimin dhe projektimin shih [6, 7].
Specifikimin e plotë të UML shihni. [8].
Tani jemi të gatshëm të kalojmë në etapat e tjera dhe të fillojmë projektimin e funksioneve të sistemit dhe organizatës së saj të brendshme. Numërimi i vizatimeve do të vazhdojë.
Hapi 3. Hapi i automatizuar duhet të ketë një ose më shumë funksione të sistemit
Sistemi automatizuar (AS) që po zhvillohet është i destinuar për ruajtjen e një llogariti rigoroz të arrave, mos e harroni? Për çdo hap të identifikuar (shih. Figura 3, Figura 4 ), që do ta automatizojmë, do të shkruajmë një kërkesë funksionale, duke përdorur një konstrukcion të tillë «Sistemi duhet të ketë mundësinë e ...» dhe do të zhvillojmë një diagramë Use-case. Tani ne faktikisht jemi duke e plotësuar marrëveshjen tonë për modelimin me rregulla të reja. Do ta shpjegoj se cilat elemente do të përdorim.
Ndërmjet «Rol të përdoruesit» dhe «Funksionit» do të përdorim lidhjen «Asociacion» (Figura 5), që do të thotë se për atë përdorues me këtë rol është e disponueshme realizimi i atij funksioni.
Figura 5. Përdorimi i lidhjes «Asociacion»
Nga «Funksioni» në «Kërkesë» do të tërheqim lidhjen «Realizim» (Figura 6), për të treguar se kjo kërkesë do të realizohet nga këto funksione, marrëdhënia mund të jetë gjithashtu «multe-kë shumë», dmth. një funksion mund të jetë pjesë e realizimit të disa kërkesave, dhe për realizimin e një kërkese mund të nevojitet më shumë se një funksion.
Figura 6. Përdorimi i lidhjes «Realizim»
NĂ«se njĂ« funksion kĂ«rkon pĂ«r realizimin e saj, qĂ« njĂ« tjetĂ«r funksion tĂ« jetĂ« e realizuar gjithashtu, do tĂ« pĂ«rdorim lidhjen «VarĂ«si» me stereotipin «Include» - pĂ«rfshirje (Figura 7). NĂ«se realizimi i funksionit tĂ« dytĂ« kĂ«rkohet nĂ« kushte tĂ« caktuara, do tĂ« pĂ«rdorim lidhjen «VarĂ«si» me stereotipin «Extend» â zgjerim. ĂshtĂ« shumĂ« e lehtĂ« tĂ« memorizohet: «Include» - GJITHMONĂ, dhe «Extend» - NĂ DISA RASTE.
Figura 7. Përdorimi i lidhjes «Varësi (përfshirje)»
Në fund, diagrami ynë do të duket kështu (Figura 8).
Figura 8. Diagrami Use-case (modeli funksional i AS)
Përveç kësaj, diagrami Use-case përdoret për modelimin e rolit të përdoruesve (Figura 9).
Figura 9. Diagrami Use-case (rollet e përdoruesve të AS)
Hapi 4. Përshkruajmë organizimin e brendshëm të AS përmes diagramit të klasave
Duke përdorur informacionin mbi artefaktet hyrëse dhe dalëse të procesit tonë (shih. diagramet Activity - Figura 2, Figura 3, Figura 4), do të zhvillojmë diagramin e klasave. Do të përdorim elementet modeluese «Klasa» dhe lloje të ndryshme lidhjesh ndërmjet tyre.
Për të treguar marrëdhënien «tërësi-pjesë» do të përdorim lidhjen e tipit «Agregatë» (Figura 10): arra është e tërë, ndërsa lëvozhgat dhe bërthamat janë pjesë.
Figura 10. Marrëdhënia «tërësi-pjesë»
Në fund, fragmenti i diagramit tonë do të duket kështu (Figura 11). Ngjyrat tregojnë klasat që i kemi identifikuar direkt në përshkrimin tekstual të procesit.
Figura 11. Diagrami i klasave
Diagrami i klasave u përdor si përmodelim të artefakteve të tjera - jo vetëm atyre që do të kenë lidhje me modelin konceptual të procesit të automatizuar të kontabilitetit të pasurive materiale, por edhe me mjedisin e ekzekutimit - ambienti (Figura 12) dhe proceset "fqinje" (Figura 13) që mund të kenë ndikim në procesin e automatizuar, por aktualisht nuk janë në fokusin tonë (supozojmë se sistemi do të zhvillohet dhe kjo informacion do të jetë e dobishme).
Figura 12. Diagrami i klasave (ambienti)
Lidhja e trashëgimisë tregon përmbledhjen e strukturave të ndryshme, "klasat "bijë", nën klasën përmbledhëse "Struktura".
Figura 13. Diagrami i klasave (informacione shtesë rreth artefakteve)
"Reagimi ndaj situatës" varet nga "Të dhënat e kontrollit vizual". Për disa lidhje varësie përdoret stereotipi "trace", për të treguar gjurmimin e klasave që nuk janë shprehur qartë në përshkrimin e procesit, por që janë të nevojshme për automatizimin e tij, me klasat, për të cilat ka një informacion të saktë në përshkrimin tonë.
Hapi 5. Analyzojmë shënimet në rrugicën "Rregullat e biznesit"
Si rregulla janë përmendur (shih Figurën 2 ):
- nevoja për të ndarë një nga hapat në 2 pjesë, pjesa e dytë fillon të ekzekutohet vetëm nën kushte të caktuara;
- emërimi për të kryer kontabilitetin e arrave të një personi të caktuar;
- një teknikë teknike (ngjyra e bardhë e elementeve) e cila tregon se elementi nuk është shprehur qartë në përshkrimin e procesit.
Duhet theksuar se të gjitha këto rregulla ne i kemi përdorur tashmë gjatë zhvillimit të diagrameve.
Vërejtje përfundimtare
Pra, ne kaluam nëpër 5 etapa dhe ndërtuam 3 lloje diagramesh. Do të shtoja një koment të vogël mbi organizimin e modeleve tona në ambientin e modelimit. Ekziston një numër i madh kornizash që ndihmojnë në strukturimin e modeleve të zhvilluara, por kjo nuk është subject i këtij artikulli, ndaj do të kufizohemi në këtë grup të thjeshtë paketash për të organizuar projektin tonë: Procesi i Biznesit, Modeli Funkcional, Artefaktet, Pjesëmarrësit dhe Ambienti (Figura 14).
Figura 14. Struktura e paketave të projektit
Kështu, ne zhvilluam modele të harmonizuara që përshkruajnë sistemin e kontabilitetit të pasurive materiale nga këndvështrime të ndryshme: modeli i procesit të automatizuar të biznesit, modeli funksional dhe modeli i organizimit të brendshëm të sistemit në nivelin konceptual.
Lista e Burimeve
- Faqja "UML2.ru". Forumi i Komunitetit të Analistëve. Seksioni i Përgjithshëm. Shembuj. Shembuj përrallash të strukturuara si diagramet UML. [Burim elektronik] Qasja: Internet:
- Faqja e Sparx Systems. [Burim elektronik] Qasja: Internet:
- Faqja e Modelio. [Burim elektronik] Qasja: Internet:
- Fjalori i Madh Enciklopedik. Procesi (shpjegimi). [Burim elektronik] Qasja: Internet:
- Faqja "Organizimi i Menaxhimit Efektiv". Blogu. Kategoria "Menaxhimi i Proceseve të Biznesit". Definimi i procesit të biznesit. [Burim elektronik] Qasja: Internet:
- Dëshmia Nr. 18249 për regjistrimin dhe depozitimin e rezultatit të aktivitetit intelektual. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manushaqe e materialit mësimor me titull "Modelimi i fushës së objektit duke përdorur Enterprise Architect" // 2011.
- Zotulkhina E.B., Vishnya A.S., Krasnikova S.A. Modelimi i proceseve tĂ« biznesit. â TiranĂ«: KURS, NIC INFRA-M, EBS Znanium.com. â 2017.
- OMG Unified Modeling Language (OMG UML) Specifikimi. Version 2.5.1. [Burim Elektronik] Reja e aksesit: Interneti:
Burimi: habr.com
