"Yksi päivä oravan elämässä" tai mallinnusprosesseista aineellisten hyödykkeiden automaattisen kirjanpitojärjestelmän "Belka-1.0" suunnitteluun (osa 2)
Yhteenveto edellisestä sarjasta
В käytimme "satu" -aihealuetta, joka on saanut inspiraationsa esimerkeistä satujuoniin perustuvien UML-kaavioiden tutkimisesta (katso esim. [1]). Ennen mallintamista sovittiin joidenkin Aktiviteettikaavion elementtien käytöstä ja alettiin tehdä mallinnussopimusta. Nämä sopimukset huomioiden 1. vaiheessa kuvasimme prosessia Aktiivisuuskaavioiden muodossa ja 2. vaiheessa tunnistimme prosessin vaiheet, joissa automatisointia tarvitaan (ja mahdollista).
Muistutan, että aiomme automatisoida näissä prosesseissa syntyvän aineellisten arvojen kirjanpidon.
...
Meressä on saari, (E1, E2)
Rae saarella seisoo (E3, E1)
Kultakupolisilla kirkoilla, (E4)
Torneilla ja puutarhoilla; (E5, E6)
Kuusi kasvaa palatsin edessä, (E7, E8)
Ja sen alla on kristallitalo; (E9)
Orava asuu siellä, kesy, (A1)
Kyllä, mikä seikkailu! (A1)
Orava laulaa lauluja, (P1, A1)
Kyllä, hän pureskelee kaikki pähkinät, (P2)
Ja pähkinät eivät ole yksinkertaisia, (C1)
Kaikki kuoret ovat kultaisia, (C2)
Puhdas smaragdi ydin; (C3)
Palvelijat vartioivat oravaa, (P3, A2)
Palvele häntä erilaisina palvelijoina (P4)
Ja virkailija määrättiin (A3)
Tiukka huomioon pähkinät uutiset; (P5, C1)
Armeija tervehtii häntä; (P6, A4)
Kuoreista kaadetaan kolikko (P7, C2, C4)
Anna heidän kellua ympäri maailmaa; (P8)
Tytöt heittävät smaragdia (P9, A5, C3)
Ruokakomeroissa, mutta vakan alla; (E10, E11)
...
(A.S. Pushkin "Tarina tsaari Saltanista, hänen loistavasta ja mahtavasta pojasta prinssi Gvidon Saltanovichista ja kauniista Joutsenprinsessasta" )
Tässä esimerkissä käytän australialaisen yrityksen Enterprise Architect -kehystä [2] ja käyttämieni harjoitusten puitteissa [3].
Muistutan, että prosessit ovat erilaisia, voit tutustua mm. [4] ja [5].
Katso [6, 7] lisätietoja sovelletuista lähestymistavoista mallintamiseen ja suunnitteluun.
Katso täydellinen UML-spesifikaatio [8].
Olemme nyt valmiita siirtymään seuraaviin vaiheisiin ja aloittamaan järjestelmän toimintojen ja sen sisäisen organisaation suunnittelun. Kuvien numerointi jatkuu.
Vaihe 3. Automatisoidulle vaiheelle on määritettävä järjestelmän toiminto tai toiminnot
Kehitettävä automatisoitu järjestelmä (AS) on suunniteltu pitämään tiukkaa kirjaa pähkinöistä, muistatko? Jokaiselle korostetulle vaiheelle (katso kuva 3, kuva 4). ), jonka automatisoimme, kirjoitamme muistiin toiminnallisen vaatimuksen käyttämällä jotain tällaista "Järjestelmän on kyettävä ..." -konstruktiota ja kehitämme käyttötapauskaavion. Nyt itse asiassa täydennämme mallinnussopimustamme uusilla säännöillä. Selitän, mitä elementtejä käytämme.
"Käyttäjän roolin" ja "toiminnon" välillä käytämme "Association"-suhdetta (kuva 5), mikä tarkoittaa, että käyttäjä, jolla on tämä rooli, voi suorittaa tämän toiminnon.
Kuva 5. Assosiaatiotyyppisuhteen käyttäminen
"Toiminto" -kohdasta "vaatimus" piirretään "Toteutus"-linkki (kuva 6) osoittamaan, että nämä toiminnot toteuttavat tämän vaatimuksen, suhde voi olla "monet moneen", ts. yksi toiminto voi olla mukana useiden vaatimusten toteuttamisessa, ja vaatimuksen toteuttamiseen voi tarvita useampi kuin yksi toiminto.
Kuva 6. Toteutussuhteen käyttäminen
Jos jokin toiminto edellyttää, että jokin muu toiminto suoritetaan, ja välttämättä, käytämme "Riippuvuus"-yhteyttä "Sisällytä"-stereotypiaan (kuva 7). Jos lisätoiminnon suorittamista vaaditaan tietyissä olosuhteissa, käytämme "Riippuvuus"-yhteyttä "Extend"-stereotypian kanssa. Kaikki on erittäin helppo muistaa: "Sisällytä" on AINA ja "Extend" on joskus.
Kuva 7. Linkkityypin "Riippuvuus (sisältää)" käyttäminen
Tämän seurauksena kaaviomme näyttää suunnilleen tältä (kuva 8).
Kuva 8. Käyttötapauskaavio (AS:n toimintamalli)
Lisäksi käyttötapauskaaviota käytetään mallintamaan käyttäjärooleja (Kuva 9).
Kuva 9. Käyttötapauskaavio (AS-käyttäjien roolit)
Vaihe 4. Kuvataan AS:n sisäistä organisaatiota luokkakaavion avulla
Kehitämme luokkakaavion käyttämällä tietoja prosessimme tulo- ja tulostetuista artefakteista (katso Aktiviteettikaaviot - Kuva 2, Kuva 3, Kuva 4). Käytämme "Class" -mallinnuselementtejä ja erilaisia suhteita niiden välillä.
"Koko osa" -suhteen näyttämiseksi käytämme "Aggregation"-tyyppistä suhdetta (kuva 10): pähkinä on kokonaisuus ja kuoret ja ydin ovat osia.
Kuva 10. Koko osan suhde
Tämän seurauksena osa kaaviostamme näyttää suunnilleen tältä (kuva 11). Luokat on merkitty väreillä, jotka olemme korostaneet suoraan prosessin tekstikuvauksessa.
Kuva 11. Luokkakaavio
Luokkakaaviota käytettiin myös muiden artefaktien mallintamiseen - ei vain niitä, jotka liittyvät automatisoidun inventaarioprosessin käsitteelliseen malliin, vaan liittyvät suoritusympäristöön - ympäristöön (kuva 12) ja "naapuriprosesseihin" (Kuva 13). jotka voivat vaikuttaa automatisoituun prosessiin, mutta eivät ole vielä huomion kohteena (oletamme, että järjestelmä kehittyy ja tästä tiedosta on hyötyä).
Kuva 12. Luokkakaavio (ympäristö)
Periytyssuhde osoittaa eri rakennusten, "lapsi"-luokkien, yleistyksen "vanhempi"-luokan "Rakennus" alle.
Kuva 13. Luokkakaavio (lisätietoja esineistä)
"Reaktio tilanteeseen" riippuu "Visuaalisista ohjaustiedoista". Useissa riippuvuussuhteissa "jäljitys"-stereotypiaa käytetään näyttämään sellaisten luokkien jäljittämistä, joita ei ole nimenomaisesti osoitettu prosessin kuvauksessa, mutta jotka ovat välttämättömiä sen automatisoimiseksi, luokkiin, joiden esiintymät on kuvattu tarkasti kuvauksessamme.
Vaihe 5. Analysoidaan "Business Rules" -raidan muistiinpanot
Kuten säännöt määriteltiin (katso kuva 2 ):
- tarve jakaa yksi vaiheista 2 osaan, toinen osa alkaa suorittaa vain tietyissä olosuhteissa;
- tietyn virkamiehen nimittäminen suorittamaan pähkinöiden kirjanpitoa;
- tekniikka (elementtien valkoinen väri), joka osoittaa, että elementtiä ei ole nimenomaisesti lueteltu prosessin kuvauksessa.
On huomattava, että olemme jo käyttäneet kaikkia näitä sääntöjä kaavioiden kehittämisessä.
Loppuhuomautukset
Joten kävimme läpi 5 vaihetta ja rakensimme 3 tyyppisiä kaavioita. Lisään vielä pienen kommentin mallien organisoinnista mallinnusympäristössä. On olemassa suuri määrä kehyksiä, jotka auttavat jäsentämään kehittämiämme malleja, mutta tämä ei ole tämän artikkelin aihe, joten rajoitamme seuraaviin yksinkertaisiin paketteihin projektimme säännölliseen ylläpitoon: Business Process, Functional Model, Esineet, osallistujat ja ympäristö (Kuva 14).
Kuva 14. Projektipakettien rakenne
Näin ollen olemme kehittäneet johdonmukaisia malleja, jotka kuvaavat aineellisten hyödykkeiden kirjanpitojärjestelmää eri näkökulmista: mallin automatisoidusta liiketoimintaprosessista, toiminnallisesta mallista ja mallin järjestelmän sisäisestä organisaatiosta käsitteellisellä tasolla.
Lista lähteistä
- Sivusto "UML2.ru". Analyytikkoyhteisön foorumi. Yleinen osio. Esimerkkejä. Esimerkkejä saduista UML-kaavioiden muodossa. [Sähköinen resurssi] Käyttötapa: Internet:
- Sparx Systemsin verkkosivusto. [Sähköinen resurssi] Käyttötapa: Internet:
- Modelion verkkosivusto. [Sähköinen resurssi] Käyttötapa: Internet:
- Suuri Ensyklopedinen sanakirja. Prosessi (tulkinta). [Sähköinen resurssi] Käyttötapa: Internet:
- Verkkosivusto "Tehokkaan johtamisen järjestäminen". Blogi. Otsikko "Liikeprosessien hallinta". Liiketoimintaprosessin määritelmä. [Sähköinen resurssi] Käyttötapa: Internet:
- Todistus nro 18249 henkisen toiminnan tuloksena saadun tuotteen rekisteröinnistä ja tallettamisesta. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Opetusvälineen käsikirjoitus "Ainealueen mallinnus yritysarkkitehdin avulla" // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Liiketoimintaprosessien mallintaminen. - M .: KURS, NITs INFRA-M, EBS Znanium.com. – 2017.
- OMG Unified Modeling Language (OMG UML) -määritys. Versio 2.5.1. [Sähköinen resurssi] Käyttötapa: Internet:
Lähde: will.com