«Üks päev orava elust» või kuidas mudeldamisest liikuda automatiseeritud varade arvestussüsteemi projekteerimisele «Belka-1.0» (Osa 2)
Eelmise osa kokkuvõte
V kasutasime «muinasjuttudest» lähtuvat teemat, inspireerituna UML-diagrammide uurimise näidetest, tuginedes muinasjuttude süžeesse (vt näiteks, [1]). Enne mudeldamise algust leppisime kokku mõnede tegevusdiagrammi elementide kasutamises ja hakkasime koostama mudeldamise kokkulepet. Nende kokkulepetega arvestades kirjeldasime esimeses etapis protsessi tegevusdiagrammide kujul ning teises etapis eraldasime protsessi sammud, mille jaoks vajame (ja on võimalik) automatiseerimist.
Tuletan meelde, et plaanime automatiseerida varade arvestuse tegevust, mis tekib just nende protsesside käigus.
…
Saare peal asub, (E1, E2)
Linn saare peal seisab (E3, E1)
Kuldpruunide kirikutega, (E4)
Tornide ja aedadega; (E5, E6)
Kuusk kasvab palee ees, (E7, E8)
Ja selle all on kristallmaja; (E9)
Orav elab seal, (A1)
Ja mis mõnus olend! (A1)
Orav laulab laule, (P1, A1)
Ja pähkleid pidevalt näksib, (P2)
Kuid pähklid ei ole tavalised, (C1)
Kõik kestad on kuldsed, (C2)
Koidul on selge smaragd; (C3)
Teenrid valvavad oravat, (P3, A2)
Teenivad teda erinevate teenustega (P4)
Ja määratud on kohus (A3)
Range arvestus pähklite kohta; (P5, C1)
Austavad teda väejuhiga; (P6, A4)
Kestadest valatakse münt, (P7, C2, C4)
Ja lastakse neid ringkäiku; (P8)
Tüdrukud puistavad smaragdi (P9, A5, C3)
Ladu sisse, ja keldrisse; (E10, E11)
…
(A.S. Puškini «Tsaari Saltani muinasjutt, tema ülevast ja võimsast rüütlist prints Gvidonist ning kaunist printsessist Luigist, )
Selles näites kasutan ma Enterprise Architect’i Austraalia ettevõttelt. [2], ning õppeainetena rakendan [3].
Tuletan meelde, et protsessid võivad olla erinevad, tutvuda saab näiteks, [4] ja [5].
Rohkem teavet kasutatavate mudeldamis- ja projekteerimismeetodite kohta vt [6, 7].
Täielik UML spetsifikatsioon vt. [8].
Nüüd oleme valmis liikuma järgmistele etappidele ja alustama süsteemi funktsioonide ja selle sisemise korralduse projekteerimist. Jooniste numeerimist jätkatakse.
Etapp 3. Automatiseeritavale sammele tuleb määrata süsteemi funktsioon või funktsioonid
Arendatav automatiseeritud süsteem (AS) on mõeldud pähklite range arvestuse pidamiseks, kas mäletate? Iga eraldatud sammu (vt Joonis 3, Joonis 4 ), mille me automatiseerime, kirja funktsionaalne nõue, kasutades umbes sellist konstruktsiooni «Süsteemis peab olema rakendatud võimalus…» ning töötame välja kasutusjuhtide diagrammi. Praegu täiendame oma mudeldamise kokkulepet uute reeglitega. Selgitan, milliseid elemente me kasutame.
Kasutaja «Rolli» ja «Funktsiooni» vahel kasutame seost «Assotsiatsioon» (Joonis 5), see tähendab, et antud rolliga kasutajale on antud võimalus selle funktsiooni täitmiseks.
Joonis 5. Assotsiatsiooni tüüpi seose kasutamine
Funktsioonist «Nõudmisele» tõmbame seose «Rakendamine» (Joonis 6), et näidata, et see nõudmine rakendatakse just nende funktsioonide kaudu, suhe võib olla ka «palju-palju», st üks funktsioon võib osaleda mitme nõudmise täitmises, ja nõudmise täitmiseks võib olla tarvis rohkem kui ühte funktsiooni.
Joonis 6. Rakendamise tüüpi seose kasutamine
Kui üks funktsioon vajab oma täitmiseks, et teostataks veel mõni funktsioon, siis kasutame seost «Sõltuvus» stereotüübi «Include» — kaasamine (Joonis 7). Kui täiendava funktsiooni täitmine on vajalik teatud tingimustel, siis kasutame seost «Sõltuvus» stereotüübi «Extend» — laiendamine. Kõike on lihtne meeles pidada: «Include» — ALATI, ja «Extend» – KUNAGI.
Joonis 7. Sõltuvuse (kaasamine) tüüpi seose kasutamine
Kokkuvõttes meie diagramm näeb välja selline (Joonis 8).
Joonis 8. Kasutusjuhtide diagramm (AS funktsionaalne mudel)
Lisaks kasutatakse kasutusjuhtide diagrammi kasutajate rollide mudeldamiseks (Joonis 9).
Joonis 9. Kasutusjuhtide diagramm (AS kasutajate rollid)
Etapp 4. Kirjeldame süsteemi sisemist korraldust klasside diagrammi abil
Kasutades meie protsessi sisse- ja väljaminevate artefaktide teavet (vt tegevusdiagrammid — Joonis 2, Joonis 3, Joonis 4), töötame välja klasside diagrammi. Kasutame modelleerimise elemente «Klass» ja erinevaid suhteid nende vahel.
Näitamaks suhet «kogu-osake» kasutame seost «Agregatsioon» (Joonis 10): pähkel — see on whole, ja kest ja süda — need on osad.
Joonis 10. Suhe «kogu-osake»
Kokkuvõttes fragment meie diagrammist näeb välja selline (Joonis 11). Värviga on märgitud klassid, mille oleme eraldanud otse protsessi tekstikirjelduses.
Joonis 11. Klasside diagramm
Klassidiagrammi kasutati ka teiste artefaktide mudeldamiseks – mitte ainult nende, mis on seotud automatiseeritava materiaalse väärtuste arvestuse kontseptuaalse mudeliga, vaid ka täitmise keskkonna (Joonis 12) ja "naaberprotsesside" (Joonis 13) suhtes, mis võivad mõjutada automatiseeritavat protsessi, kuid mis ei ole hetkel meie tähelepanu keskmes (eeldame, et süsteem areneb ja see teave osutub kasulikuks).
Joonis 12. Klassidiagramm (keskkond)
Seos pärimine näitab erinevate ehitiste üldistamist, "tütar" klassid üldistava "ema" klassi "Ehitamine" all.
Joonis 13. Klassidiagramm (täiendav teave artefaktide kohta)
"Reaktsioon olukorrale" sõltub "Visuaalse kontrolli andmetest". Mitme sõltuvuse suhte puhul kasutatakse stereotüüpi "trace", et näidata klasside jälgimist, mis ei ole protsessi kirjeldusega selgelt määratletud, kuid mis on vajalikud selle automatiseerimiseks, klasside suunas, millele meie kirjelduses on antud täpsustatud viidatud.
Etapp 5. Analüüsime märkmeid ärireeglite rajal
Reeglitena on osutatud (vt Joonis 2 ):
- vajadus jagada üks etapp kaheks osaks, kus teine osa hakkab toimuma alles teatud tingimustel;
- määramine teatud ametikoha jaoks pähklite arvestuse teostamiseks;
- tehniline näitaja (elementide valge värv), mis näitab, et element ei olnud selgelt määratletud protsessi kirjelduses.
Oluline on märkida, et oleme neid reegleid juba kasutanud diagrammide väljatöötamisel.
Lõppsäte
Nii oleme läbinud 5 etappi ja koostanud 3 tüüpi diagrammi. Lisaks annan veel väikese kommentaari meie mudelite korraldamise kohta mudeldamisvõrgustikus. On olemas suur hulk raamistikke, mis aitavad struktureerida arendatavaid mudeleid, kuid see ei ole käesoleva artikli teema, seega piirame end järgmise lihtsa pakettide komplektiga meie projekti korraldamiseks: Äritegevus, Funktsionaalne mudel, Artefaktid, Osalejad ja Keskkond (Joonis 14).
Joonis 14. Projekti pakettide struktuur
Nii oleme arendanud kooskõlastatud mudeleid, mis kirjeldavad materiaalse väärtuste arvestussüsteemi erinevatest külgedest: automatiseeritava äri protsessi mudel, funktsionaalne mudel ja süsteemi siseorganisatsiooni mudel kontseptuaalsel tasandil.
Allikate nimekiri
- Lehekülg «UML2.ru». Analüütikute Ühenduse foorum. Üldine jaotis. Näidised. Näited muinasjuttudest, mis on kujundatud UML diagrammidena. [Elektrooniline ressurss] Juurdepääsu režiim: Internet:
- Lehekülg Sparx Systems. [Elektrooniline ressurss] Juurdepääsu režiim: Internet:
- Lehekülg Modelio. [Elektrooniline ressurss] Juurdepääsu režiim: Internet:
- Suur entsüklopeedia. Protsess (tõlgendus). [Elektrooniline ressurss] Juurdepääsu režiim: Internet:
- Lehekülg «Tõhusate juhtimiste vältimise organisatsioon». Blogi. Rubriik «Äriprotsesside juhtimine». Ärianalüüsimise määratlemine. [Elektrooniline ressurss] Juurdepääsu režiim: Internet:
- Tunnistus nr 18249 intellektuaalse tegevuse tulemuse registreerimise ja deponimise kohta. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Õpikute ja metoodiliste materjalide käsikiri pealkirjaga «Objekti ala modelleerimine Enterprise Architecti kasutamisega» // 2011.
- Zolotokhina E.B., Vishnya A.S., Krasnikova S.A. Äritegevuse protsesside modelleerimine. — M.: KURS, NII INFRA-M, EBS Znanium.com. — 2017.
- OMG Unified Modeling Language (OMG UML) Specification. Version 2.5.1. [Электронный ресурс] Режим доступа: Интернет:
Allikas: habr.com
