"Viena diena vāveres dzīvē" jeb no modelēšanas procesu līdz automatizētas materiālo vērtību uzskaites sistēmas projektēšanai "Belka-1.0" (2.daļa)
Iepriekšējās sērijas kopsavilkums
В Mēs izmantojām “pasaku” domēnu, ko iedvesmojuši piemēri, kā apgūt UML diagrammas, kuru pamatā ir pasaku sižeti (skatiet, piemēram, [1]). Pirms modelēšanas sākšanas vienojāmies par dažu Darbības diagrammas elementu izmantošanu un sākām veidot modelēšanas līgumu. Ņemot vērā šos līgumus, 1. posmā aprakstījām procesu aktivitāšu diagrammu veidā, bet 2. posmā identificējām procesa soļus, kuriem nepieciešama (un iespējama) automatizācija.
Atgādināšu, ka grasāmies automatizēt materiālo vērtību uzskaites darbību, kas rodas šajos procesos.
...
Jūrā atrodas sala, (E1, E2)
Krusa uz salas stendiem (E3, E1)
Ar zelta kupolām baznīcām (E4)
Ar torņiem un dārziem; (E5, E6)
Pils priekšā aug egle, (E7, E8)
Un zem tā ir kristāla māja; (E9)
Tur dzīvo vāvere, pieradināt, (A1)
Jā, kāds izklaidētājs! (A1)
Vāvere dzied dziesmas, (P1, A1)
Jā, viņš grauž visus riekstus, (P2)
Un rieksti nav vienkārši, (C1)
Visas čaulas ir zeltainas, (C2)
Kodoli tīrs smaragds; (C3)
Kalpi sargā vāveri, (P3, A2)
Kalpot viņai par dažāda veida kalpiem (P4)
Un tika nozīmēts ierēdnis (A3)
Stingrs riekstu jaunumu izklāsts; (P5, C1)
Dod savai armijai godu; (P6, A4)
No čaumalām tiek izlieta monēta (P7, C2, C4)
Ļaujiet viņiem peldēt pa pasauli; (8. lpp.)
Meitenes met smaragdu (P9, A5, C3)
Pieliekamajos, bet zem krūma; (E10, E11)
...
(A.S. Puškins “Pasaka par caru Saltānu, viņa krāšņo un vareno varoni princi Gvidonu Saltanoviču un skaisto princesi Gulbi” )
Šajā piemērā es izmantoju Austrālijas uzņēmuma Enterprise Architect vidi. [2], un treniņu laikā izmantoju [3].
Atgādināšu, ka ir dažādi procesi, var iepazīties piem. [4] un [5].
Sīkāku informāciju par pielietotajām modelēšanas un projektēšanas pieejām skatiet [6, 7].
Pilnu UML specifikāciju skatiet [8].
Tagad esam gatavi pāriet uz nākamajiem soļiem un sākt izstrādāt sistēmas funkcionalitāti un iekšējo organizāciju. Zīmējumu numerācija turpināsies.
3. posms. Automatizētajam solim ir jāpiešķir sistēmas funkcija vai funkcijas
Izstrādātā automatizētā sistēma (AS) ir paredzēta, lai uzturētu stingru riekstu uzskaiti, atceries? Katrai izceltajai darbībai (skatiet 3. attēlu, 4. attēlu). ), kuru automatizēsim, pierakstīsim funkcionālo prasību, izmantojot aptuveni šādu konstrukciju: “Sistēmai jāīsteno iespēja...” un izstrādāsim lietošanas gadījumu diagrammu. Tagad mēs pievienojam jaunus noteikumus mūsu modelēšanas līgumam. Ļaujiet man paskaidrot, kādus elementus mēs izmantosim.
Mēs izmantosim savienojumu “Asociācija” starp “Lietotāja lomu” un “Funkciju” (5. attēls), tas nozīmē, ka lietotājs ar šo lomu var veikt šo funkciju.
5. attēls. Asociācijas tipa attiecības izmantošana
No “Funkcija” uz “Prasība” mēs izveidosim savienojumu “Ieviešana” (6. attēls), lai parādītu, ka šī prasība tiks īstenota ar šīm funkcijām; attiecības var būt “daudzi pret daudziem”, t.i. Viena funkcija var būt iesaistīta vairāku prasību ieviešanā, un prasības īstenošanai var būt nepieciešamas vairākas funkcijas.
6. attēls. “Ieviešanas” tipa attiecības izmantošana
Ja vienas funkcijas izpildei ir nepieciešams izpildīt kādu citu funkciju un obligāti, mēs izmantosim savienojumu “Atkarība” ar stereotipu “Iekļaut” (7. attēls). Ja noteiktos apstākļos ir nepieciešama papildu funkcijas izpilde, tad izmantosim “Atkarības” savienojumu ar stereotipu “Pagarināt”. Viss ir ļoti viegli iegaumējams: “Iekļaut” ir VIENMĒR, un “Pagarināt” ir REIZĒM.
7. attēls. Sakarības “Atkarība (iekļaušana)” izmantošana
Rezultātā mūsu diagramma izskatīsies apmēram šādi (8. attēls).
8. attēls. Lietošanas gadījumu diagramma (AC funkcionālais modelis)
Turklāt lietotāju lomu modelēšanai tiek izmantota lietošanas gadījuma diagramma (9. attēls).
9. attēls. Lietošanas gadījumu diagramma (AS lietotāju lomas)
4. posms. Aprakstīsim AS iekšējo organizāciju, izmantojot klašu diagrammu
Izmantojot informāciju par mūsu procesa ievades un izvades artefaktiem (sk. Darbību diagrammas - 2. attēls, 3. attēls, 4. attēls), mēs izstrādāsim klases diagrammu. Mēs izmantosim “Klases” modelēšanas elementus un dažāda veida savienojumus starp tiem.
Lai parādītu “veselas daļas” attiecības, mēs izmantosim “Apkopošanas” tipa attiecības (10. attēls): rieksts ir veselums, bet čaumalas un kodols ir daļas.
10. attēls. Visas daļas attiecības
Rezultātā mūsu diagrammas fragments izskatīsies apmēram šādi (11. attēls). Klases, kuras mēs tieši iezīmējām procesa teksta aprakstā, ir atzīmētas ar krāsu.
11. attēls. Klases diagramma
Klašu diagramma tika izmantota arī citu artefaktu modelēšanai – ne tikai tiem, kas būs saistīti ar materiālo vērtību automatizētā uzskaites procesa konceptuālo modeli, bet arī ar izpildes vidi – vidi (12. attēls) un “kaimiņu” procesi (13. attēls), kas var ietekmēt automatizēto procesu, bet vēl nav mūsu uzmanības lokā (pieņemam, ka sistēma attīstīsies un šī informācija būs noderīga).
12. attēls. Klases diagramma (vide)
Mantojuma attiecības parāda dažādu ēku, “bērnu” klašu vispārināšanu zem vispārināšanas “vecāku” klases “Ēka”.
13. attēls. Klases diagramma (papildu informācija par artefaktiem)
“Reakcija uz situāciju” ir atkarīga no “Vizuālās kontroles datiem”. Vairākām atkarības attiecībām stereotips "izsekošana" tiek izmantots, lai parādītu klašu izsekošanu, kas nav skaidri norādītas procesa aprakstā, bet ir nepieciešamas tā automatizēšanai, klasēm, kuru gadījumi ir skaidri norādīti mūsu aprakstā.
5. posms. Analizēsim piezīmes celiņā "Uzņēmējdarbības noteikumi".
Noteikumi tika precizēti (skat. 2. attēlu ):
- nepieciešamība sadalīt vienu no soļiem 2 daļās, otro daļu sāk izpildīt tikai noteiktos apstākļos;
- noteiktas amatpersonas iecelšana riekstu uzskaites veikšanai;
- paņēmiens (baltā elementu krāsa), kas norāda, ka elements nebija skaidri norādīts procesa aprakstā.
Jāatzīmē, ka mēs jau esam izmantojuši visus šos noteikumus, izstrādājot diagrammas.
Nobeiguma piezīmes
Tātad, mēs izgājām cauri 5 posmiem un izveidojām 3 veidu diagrammas. Pievienošu nelielu komentāru par mūsu modeļu organizēšanu modelēšanas vidē. Ir liels skaits ietvaru, kas palīdz strukturēt izstrādājamos modeļus, taču tas nav šī raksta temats, tāpēc mēs aprobežosimies ar šādu vienkāršu pakotņu kopumu mūsu projekta kārtīgai pārvaldībai: Biznesa process, Funkcionālais modelis , Artefakti, dalībnieki un vide (14. attēls).
14. attēls. Projekta paketes struktūra
Tādējādi esam izstrādājuši konsekventus modeļus, kas raksturo materiālu uzskaites sistēmu no dažādiem aspektiem: automatizēta biznesa procesa modeli, funkcionālo modeli un sistēmas iekšējās organizācijas modeli konceptuālā līmenī.
Avotu saraksts
- Vietne "UML2.ru". Analītiķu kopienas forums. Vispārīgā sadaļa. Piemēri. Pasaku piemēri UML diagrammu veidā. [Elektroniskais resurss] Piekļuves režīms: Internets:
- Sparx Systems vietne. [Elektroniskais resurss] Piekļuves režīms: Internets:
- Modelio vietne. [Elektroniskais resurss] Piekļuves režīms: Internets:
- Lielā enciklopēdiskā vārdnīca. Process (interpretācija). [Elektroniskais resurss] Piekļuves režīms: Internets:
- Mājas lapa "Efektīvas vadības organizēšana". Emuārs. Rubrika "Uzņēmējdarbības procesu vadība". Biznesa procesa definīcija. [Elektroniskais resurss] Piekļuves režīms: Internets:
- Sertifikāts Nr.18249 par intelektuālās darbības rezultāta produkta reģistrāciju un deponēšanu. Alfimovs R.V., Zolotuhina E.B., Krasņikova S.A. Mācību līdzekļa ar nosaukumu "Priekšmeta jomas modelēšana, izmantojot uzņēmuma arhitektu" manuskripts // 2011.
- Zolotuhina E.B., Višņa A.S., Krasņikova S.A. Biznesa procesu modelēšana. - M .: KURS, NITs INFRA-M, EBS Znanium.com. — 2017. gads.
- OMG vienotās modelēšanas valodas (OMG UML) specifikācija. Versija 2.5.1. [Elektroniskais resurss] Piekļuves režīms: Internets:
Avots: www.habr.com