“Üks päev orava elus” ehk protsesside modelleerimisest kuni automatiseeritud varanduse arvestussüsteemi “Belka-1.0” projekteerimiseni (2. osa)
Eelmise episoodi kokkuvõte
В Kasutasime "muinasjutu" domeeni, mis on inspireeritud muinasjutu süžeedel põhinevate UML-diagrammide õppimise näidetest (vt näiteks [1]). Enne modelleerimise algust leppisime kokku mõnede Aktiivsuskeemi elementide kasutamises ja hakkasime modelleerimislepingut vormistama. Neid kokkuleppeid arvesse võttes kirjeldasime 1. etapis protsessi tegevusdiagrammide kujul ning 2. etapis selgitasime välja protsessietapid, mille jaoks automatiseerimine on vajalik (ja võimalik).
Tuletan meelde, et hakkame automatiseerima nendes protsessides tekkivat materiaalsete varade arvestust.
...
Meres asub saar, (E1, E2)
Saarel on rahe (E3, E1)
Kuldse kupliga kirikutega (E4)
Tornide ja aedadega; (E5, E6)
Palee ees kasvab kuusk, (E7, E8)
Ja selle all on kristallmaja; (E9)
Seal elab taltsas orav, (A1)
Jah, milline seiklus! (A1)
Orav laulab laule, (P1, A1)
Jah, ta näksib pidevalt pähkleid, (P2)
Kuid pähklid pole lihtsad, (C1)
Kõik kestad on kuldsed, (C2)
Tuum on puhas smaragd; (C3)
Teenindajad valvavad oravat, (P3, A2)
Nad teenivad teda erinevate teenistujatena (P4)
Ja määrati ametnik (A3)
Pähklite range arvestus on uudis; (P5, C1)
Sõjavägi tervitab teda; (P6, A4)
Karpidest valatakse münt (P7, C2, C4)
Laske neil minna ümber maailma; (lk 8)
Tüdrukud valavad smaragdi (P9, A5, C3)
Laoruumidesse ja katte alla; (E10, E11)
...
(A.S. Puškin "Lugu tsaar Saltanist, tema kuulsusrikkast ja võimsast kangelasest prints Guidon Saltanovitšist ja kaunist printsess Luigest" )
Selles näites kasutan Austraalia ettevõtte Enterprise Architect keskkonda. [2] ja treeningute ajal kasutan [3].
Tuletan meelde, et protsesse on erinevaid, tutvuda saab nt. [4] ja [5].
Täpsemat teavet modelleerimise ja disaini rakendatud lähenemisviiside kohta vt [6, 7].
Täieliku UML-i spetsifikatsiooni kohta vt [8].
Nüüd oleme valmis liikuma edasi järgmiste sammude juurde ning alustama süsteemi funktsionaalsuse ja sisemise korralduse kujundamist. Jätkub jooniste nummerdamine.
3. etapp. Automatiseeritud samm peab olema seotud süsteemi funktsiooni või funktsioonidega
Arendatav automatiseeritud süsteem (AS) on loodud pähklite rangeks arvestuseks, kas mäletate? Iga esiletõstetud sammu jaoks (vt joonis 3, joonis 4). ), mille automatiseerime, kirjutame üles funktsionaalse nõude, kasutades ligikaudu järgmist konstruktsiooni: “Süsteem peab rakendama võimet...” ja töötame välja kasutusjuhtumi diagrammi. Nüüd lisame oma modelleerimislepingusse uued reeglid. Lubage mul selgitada, milliseid elemente me kasutame.
Kasutame seost „Kasutajarolli” ja „Funktsiooni” vahel (joonis 5), mis tähendab, et selle rolliga kasutaja saab seda funktsiooni täita.
Joonis 5. Assotsiatsioonitüübi seose kasutamine
„Funktsioonist“ kuni „nõudeni“ loome seose „Rakendamine“ (joonis 6), et näidata, et need funktsioonid seda nõuet rakendavad; seos võib olla „mitu-mitmele“, st. Üks funktsioon võib olla seotud mitme nõude rakendamisega ja nõude rakendamiseks võib olla vaja rohkem kui ühte funktsiooni.
Joonis 6. Tüübi "Juurendus" kasutamine
Kui üks funktsioon nõuab selle täitmiseks mõne muu funktsiooni täitmist ja tingimata, kasutame seost "Sõltuvus" stereotüübiga "Kaasa" (joonis 7). Kui teatud tingimustel on vaja lisafunktsiooni täitmist, siis kasutame stereotüübiga "Laienda" seost "Sõltuvus". Kõike on väga lihtne meeles pidada: “Kaasa” on ALATI ja “Laienda” on VAHEL.
Joonis 7. "Sõltuvus (kaasamine)" seose kasutamine
Selle tulemusena näeb meie diagramm välja umbes selline (joonis 8).
Joonis 8. Kasutusjuhtude diagramm (vahelduvvoolu funktsionaalne mudel)
Lisaks kasutatakse kasutajarollide modelleerimiseks kasutusjuhtumi diagrammi (joonis 9).
Joonis 9. Kasutusjuhtumite diagramm (AS-i kasutajate rollid)
Etapp 4. Kirjeldame AS-i sisemist korraldust klassiskeemi abil
Kasutades teavet meie protsessi sisend- ja väljundartefaktide kohta (vt tegevusskeemid – joonis 2, joonis 3, joonis 4), töötame välja klassidiagrammi. Kasutame “Klassi” modelleerimiselemente ja nendevahelisi erinevaid ühendusi.
"Terve osa" seose näitamiseks kasutame "Agregatsiooni" tüüpi seost (joonis 10): pähkel on tervik ning kestad ja tuum on osad.
Joonis 10. Terve osa seos
Selle tulemusena näeb meie diagrammi fragment välja umbes selline (joonis 11). Klassid, mille me protsessi tekstikirjelduses otse esile tõstsime, on tähistatud värviga.
Joonis 11. Klassiskeem
Klassiskeemi kasutati ka muude artefaktide modelleerimiseks – mitte ainult nende, mis on seotud materiaalsete varade arvestuse automatiseeritud protsessi kontseptuaalse mudeliga, vaid ka täitmiskeskkonnaga – keskkond (joonis 12) ja „naaber” protsessid (joonis 13), mis võivad automatiseeritud protsessi mõjutada, kuid ei ole veel meie tähelepanu keskpunktis (eeldame, et süsteem areneb ja sellest infost on kasu).
Joonis 12. Klassiskeem (keskkond)
Pärimissuhe näitab erinevate hoonete, “laps” klasside üldistamist üldistava “vanema” klassi “Hoone” alla.
Joonis 13. Klassiskeem (lisateave esemete kohta)
"Reageerimine olukorrale" sõltub "Visuaalsetest kontrolliandmetest". Mitme sõltuvussuhte puhul kasutatakse "jälje" stereotüüpi, et näidata klasside jälgimist, mida protsessi kirjelduses otseselt ei tuvastata, kuid mida on vaja selle automatiseerimiseks, klassidele, mille esinemisjuhtudele meie kirjelduses on selgesõnaliselt viidatud.
5. etapp. Analüüsime “Ärireeglite” raja märkmeid
Reeglid täpsustati (vt joonis 2 ):
- vajadus jagada üks etappidest kaheks osaks, teist osa hakatakse täitma ainult teatud tingimustel;
- kindla ametniku määramine pähklite arvestust läbi viima;
- tehnika (elementide valge värv), mis näitab, et elementi ei olnud protsessi kirjelduses selgesõnaliselt määratletud.
Tuleb märkida, et oleme diagrammide koostamisel kõiki neid reegleid juba kasutanud.
Lõpumärkused
Niisiis, me läbisime 5 etappi ja koostasime 3 tüüpi diagramme. Lisan väikese kommentaari meie mudelite organiseerimise kohta modelleerimiskeskkonnas. On palju raamistikke, mis aitavad arendatavaid mudeleid struktureerida, kuid see ei ole selle artikli teema, seega piirdume meie projekti korrapäraseks haldamiseks järgmiste lihtsate pakettide komplektiga: Äriprotsess, funktsionaalne mudel , Artefaktid, osalejad ja keskkond (joonis 14).
Joonis 14. Projektipaketi struktuur
Seega oleme välja töötanud järjepidevad mudelid, mis kirjeldavad materjali arvestussüsteemi erinevatest aspektidest: automatiseeritud äriprotsessi mudeli, funktsionaalse mudeli ja süsteemi sisemise korralduse mudeli kontseptuaalsel tasandil.
Allikate loetelu
- Veebisait "UML2.ru". Analüütikute kogukonna foorum. Üldine jaotis. Näited. UML-diagrammidena vormindatud muinasjuttude näited. [Elektrooniline ressurss] Juurdepääsurežiim: Internet:
- Sparx Systemsi veebisait. [Elektrooniline ressurss] Juurdepääsurežiim: Internet:
- Modelio veebisait. [Elektrooniline ressurss] Juurdepääsurežiim: Internet:
- Suur entsüklopeediline sõnaraamat. Protsess (tõlgendus). [Elektrooniline ressurss] Juurdepääsurežiim: Internet:
- Veebisait "Tõhusa juhtimise korraldamine". Blogi. Kategooria "Äriprotsesside juhtimine". Äriprotsessi definitsioon. [Elektrooniline ressurss] Juurdepääsurežiim: Internet:
- Tunnistus nr 18249 intellektuaalse tegevuse teose registreerimise ja deponeerimise kohta. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Õppevahendi käsikiri pealkirjaga „Ainevaldkonna modelleerimine ettevõtte arhitekti abil“ // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Äriprotsesside modelleerimine. — M.: KURSUS, SIC INFRA-M, EBS Znanium.com. — 2017.
- OMG ühtse modelleerimiskeele (OMG UML) spetsifikatsioon. Versioon 2.5.1. [Elektrooniline ressurss] Juurdepääsurežiim: Internet:
Allikas: www.habr.com