"Jedan dan u životu vjeverice" ili od modeliranja procesa do projektovanja automatiziranog sistema za obračun materijalnih sredstava "Belka-1.0" (2. dio)
Sažetak prethodne serije
В koristili smo domen "bajke" inspirisan primjerima proučavanja UML dijagrama zasnovanih na zapletima bajki (vidi, na primjer, [1]). Prije modeliranja dogovorili smo se o korištenju nekih elemenata dijagrama aktivnosti i počeli formirati sporazum o modeliranju. Uzimajući u obzir ove dogovore, u 1. fazi smo proces opisali u obliku dijagrama aktivnosti, a u 2. fazi smo identifikovali procesne korake za koje je potrebna (i moguća) automatizacija.
Podsjećam da ćemo automatizirati djelatnost obračuna materijalnih vrijednosti koja nastaje u ovim procesima.
...
Ostrvo u moru leži, (E1, E2)
Tuča na ostrvskim tribinama (E3, E1)
Sa crkvama sa zlatnim kupolama, (E4)
Sa kulama i vrtovima; (E5, E6)
Ispred palate raste smreka, (E7, E8)
A ispod nje je kristalna kuća; (E9)
Tamo živi vjeverica, pitoma, (A1)
Da, kakav zabavljač! (A1)
Vjeverica pjeva pjesme, (P1, A1)
Da, on grize sve orahe, (P2)
A orasi nisu jednostavni, (C1)
Sve školjke su zlatne, (C2)
Jezgra čisti smaragd; (C3)
Sluge čuvaju vjevericu, (P3, A2)
Služite joj kao sluge raznih vrsta (P4)
I određen je službenik (A3)
Strogo računanje vijesti o orašastim plodovima; (P5, C1)
Odaje čast svojoj vojsci; (P6, A4)
Iz školjki se sipa novčić (P7, C2, C4)
Pustite ih da plutaju oko svijeta; (P8)
Djevojke bacaju smaragd (P9, A5, C3)
U ostavama, ali ispod čamca; (E10, E11)
...
(A.S. Puškin "Priča o caru Saltanu, o njegovom slavnom i moćnom sinu princu Gvidonu Saltanoviču i prelepoj princezi labud", )
U ovom primjeru koristim okruženje Enterprise Architect iz australijske kompanije. [2], a u okviru treninga koristim [3].
Da vas podsjetim da su procesi različiti, možete se upoznati npr. [4] i [5].
Vidi [6, 7] za detalje o primijenjenim pristupima modeliranju i dizajnu.
Za kompletnu UML specifikaciju, pogledajte [8].
Sada smo spremni da pređemo na sledeće korake i započnemo dizajniranje funkcija sistema i njegove unutrašnje organizacije. Numerisanje slika će se nastaviti.
Faza 3. Automatiziranom koraku mora biti dodijeljena funkcija ili funkcije sistema
Automatizovani sistem (AS) koji se razvija dizajniran je da vodi strogu evidenciju orašastih plodova, sećate se? Za svaki označeni korak (pogledajte sliku 3, sliku 4 ), koje ćemo automatizirati, zapisati funkcionalni zahtjev, koristeći nešto poput ove konstrukcije „Sistem mora biti u stanju da...“ i razviti dijagram slučaja korištenja. Sada zapravo dopunjujemo naš sporazum o modeliranju novim pravilima. Dozvolite mi da objasnim koje ćemo elemente koristiti.
Između “Uloge korisnika” i “Funkcije” koristićemo odnos “Asocijacija” (slika 5), što znači da korisnik sa ovom ulogom može obavljati ovu funkciju.
Slika 5. Korištenje odnosa tipa asocijacije
Od “Funkcije” do “Zahtjeva”, nacrtaćemo vezu “Implementacija” (slika 6) da pokažemo da će ovaj zahtjev biti implementiran ovim funkcijama, odnos može biti “više-prema-više”, tj. jedna funkcija može biti uključena u implementaciju nekoliko zahtjeva, a više od jedne funkcije može biti potrebno za implementaciju zahtjeva.
Slika 6. Korištenje odnosa implementacije
Ako jedna funkcija zahtijeva za svoje izvršavanje da se izvrši neka druga funkcija, a to je neophodno, koristit ćemo vezu „Zavisnost“ sa stereotipom „Uključi“ – uključivanje (slika 7). Ako je pod određenim uvjetima potrebno izvršavanje dodatne funkcije, tada ćemo koristiti vezu "Zavisnost" sa stereotipom "Proširi" - ekstenzijom. Sve je vrlo lako zapamtiti: "Uključi" - UVIJEK, i "Proširi" - PONEKAD.
Slika 7. Upotreba tipa veze "Zavisnost (uključi)"
Kao rezultat, naš dijagram će izgledati otprilike ovako (slika 8).
Slika 8. Dijagram slučaja upotrebe (funkcionalni model AS)
Pored toga, dijagram slučaja upotrebe se koristi za modeliranje korisničkih uloga (slika 9).
Slika 9. Dijagram slučaja upotrebe (uloge AS korisnika)
Faza 4. Hajde da opišemo unutrašnju organizaciju AS pomoću dijagrama klasa
Koristeći informacije o ulaznim i izlaznim artefaktima našeg procesa (pogledajte Dijagrame aktivnosti - Slika 2, Slika 3, Slika 4), mi ćemo razviti dijagram klasa. Koristićemo elemente modeliranja „Klase“ i različite vrste odnosa između njih.
Da bismo prikazali odnos "ceo-deo", koristićemo odnos tipa "agregacija" (slika 10): orah je celina, a ljuske i jezgro su delovi.
Slika 10. Odnos cijelog dijela
Kao rezultat toga, fragment našeg dijagrama će izgledati otprilike ovako (slika 11). Klase su označene bojom, koju smo istakli direktno u tekstualnom opisu procesa.
Slika 11. Dijagram klasa
Dijagram klasa je također korišten za modeliranje drugih artefakata - ne samo onih koji će biti relevantni za konceptualni model procesa automatiziranog popisa, već se odnose na okruženje izvršenja - okruženje (slika 12) i "susjedske" procese (slika 13) koji mogu uticati na automatizovani proces, ali još uvek nisu u fokusu naše pažnje (pretpostavljamo da će se sistem razvijati i ove informacije će biti korisne).
Slika 12. Dijagram klasa (okruženje)
Odnos nasljeđivanja pokazuje generalizaciju različitih zgrada, "dječijih" klasa, pod generalizirajućom "roditeljskom" klasom "Zgrada".
Slika 13. Dijagram klasa (više informacija o artefaktima)
"Reakcija na situaciju" ovisi o "Podacima vizualne kontrole". Za nekoliko relacija zavisnosti, stereotip „traga“ se koristi za prikaz praćenja klasa koje nisu eksplicitno naznačene u opisu procesa, ali koje su neophodne za njegovu automatizaciju, do klasa čije su instance precizno naznačene u našem opisu.
Faza 5. Analizirajmo bilješke na stazi "Poslovna pravila".
Kako su navedena pravila (vidi sliku 2 ):
- potreba da se jedan od koraka podijeli na 2 dijela, drugi dio počinje da se izvodi samo pod određenim uvjetima;
- imenovanje određenog službenika za obavljanje obračuna oraha;
- tehnika (bijela boja elemenata), koja ukazuje da element nije eksplicitno naveden u opisu procesa.
Treba napomenuti da smo sva ova pravila već koristili prilikom izrade dijagrama.
Završne napomene
Dakle, prošli smo kroz 5 faza i napravili 3 vrste dijagrama. Dodaću još jedan komentar o organizaciji naših modela u okruženju modeliranja. Postoji veliki broj okvira koji pomažu u strukturiranju modela koje razvijamo, ali to nije tema ovog članka, pa ćemo se ograničiti na sljedeći jednostavan skup paketa za uredno održavanje našeg projekta: Poslovni proces, Funkcionalni model, Artefakti, učesnici i okruženje (Slika 14).
Slika 14. Struktura projektnih paketa
Tako smo razvili konzistentne modele koji opisuju sistem računovodstva materijalnih sredstava iz različitih uglova: model automatizovanog poslovnog procesa, funkcionalni model i model unutrašnje organizacije sistema na konceptualnom nivou.
Spisak izvora
- Sajt "UML2.ru". Forum zajednice analitičara. Opšti deo. Primjeri. Primjeri bajki u obliku UML dijagrama. [Elektronski izvor] Način pristupa: Internet:
- Web stranica Sparx Systems. [Elektronski izvor] Način pristupa: Internet:
- Web stranica Modelio. [Elektronski izvor] Način pristupa: Internet:
- Veliki enciklopedijski rječnik. Proces (tumačenje). [Elektronski izvor] Način pristupa: Internet:
- Web stranica "Organizacija efektivnog upravljanja". Blog. Naslov "Upravljanje poslovnim procesima". Definicija poslovnog procesa. [Elektronski izvor] Način pristupa: Internet:
- Potvrda br. 18249 o registraciji i deponovanju proizvoda rezultata intelektualne aktivnosti. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Rukopis nastavnog sredstva pod nazivom "Modeliranje predmetnog područja korištenjem Enterprise Architect" // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modeliranje poslovnih procesa. - M .: KURS, NITs INFRA-M, EBS Znanium.com. — 2017.
- Specifikacija OMG Unified Modeling Language (OMG UML). Verzija 2.5.1. [Elektronski izvor] Način pristupa: Internet:
izvor: www.habr.com