"Yksi päivä oravan elämässä" tai mallinnusprosesseista aineellisten hyödykkeiden automaattisen kirjanpitojärjestelmän "Belka-1.0" suunnitteluun (osa 1)
Mitä tekemistä "oravalla" on sen kanssa?
Selitän heti mitä tekemistä "orvalla" on sen kanssa. Kun olet törmännyt Internetissä hauskoihin projekteihin UML:n oppimiseksi saduista lainatun aihealueen perusteella (esim. [1]), päätin myös valmistella samanlaisen esimerkin opiskelijoilleni, jotta he voisivat tutkia aluksi vain kolmen tyyppisiä kaavioita: toimintakaavio, käyttötapauskaavio ja luokkakaavio. En tarkoituksella käännä kaavioiden nimiä venäjäksi välttääkseni kiistat "käännösvaikeuksista". Selitän vähän myöhemmin, mitä se tarkoittaa. Tässä esimerkissä käytän australialaisen yrityksen Enterprise Architect -kehystä [2] – hyvä työkalu kohtuulliseen hintaan. Ja osana harjoituksiani käytän [3], hyvä ilmainen olio-suunnittelutyökalu, joka tukee UML2.0- ja BPMN-standardeja, ilman turhia kelloja ja pillejä visuaalisten ominaisuuksien suhteen, mutta aivan riittävä kielen perusteiden oppimiseen.
Aiomme automatisoida aineellisten hyödykkeiden kirjanpidon, joka syntyy näissä prosesseissa.
...
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 sankaristaan prinssi Guidon Saltanovichista ja kauniista prinsessa Joutsenesta" - 10 vuotta ideasta julkaisuun, muuten!)
Hieman koodeista, jotka on kirjoitettu rivien oikealle puolelle. "A" (sanasta "Toimija") tarkoittaa, että rivi sisältää tietoja prosessin osallistujasta. "C" (alustasta "Class") – tiedot luokkaobjekteista, joita käsitellään prosessien suorittamisen aikana. "E" (ilmauksesta "Ympäristö") – tiedot luokkaobjekteista, jotka kuvaavat ympäristöä prosessien suorittamista varten. "P" ("Prosessista") - tiedot itse prosesseista.
Muuten, prosessin tarkka määrittely väittää olevansa myös metodologisten kiistojen syy, jo pelkästään siksi, että on olemassa erilaisia prosesseja: liiketoimintaa, tuotantoa, teknologista jne. ja niin edelleen. (voit selvittää esim. [4] ja [5]). Kiistan välttämiseksi sovitaan siitä Olemme kiinnostuneita prosessista sen toistettavuuden ja automaatiotarpeen kannalta, eli prosessitoimintojen minkä tahansa osan suorittamisen siirtäminen automatisoituun järjestelmään.
Huomautuksia toimintokaavion käytöstä
Aloitetaan prosessimme mallintaminen ja käytetään tähän toimintokaaviota. Selitän ensin, kuinka yllä olevia koodeja käytetään mallissa. Se on helpompi selittää graafisella esimerkillä, mutta samalla analysoimme joitain (melkein kaikki tarvitsemamme) toimintokaavion elementtejä.
Analysoidaan seuraavaa fragmenttia:
...
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)
...
Meillä on kaksi prosessivaihetta P1 ja P2, osallistuja A1 ja kolmen eri luokan objektit: vaiheeseen syötetään luokan C1 objekti, luokkien C2 ja C3 objektit tulostetaan tämän vaiheen P2 toiminnan tuloksena. käsitellä asiaa. Kaaviossa käytämme seuraavia mallinnuselementtejä.
Osa prosessistamme voidaan esittää jotenkin näin (kuva 1).
Kuva 1. Aktiivisuuskaavion fragmentti
Toimintokaavion tilan organisoimiseksi ja jäsentämiseksi käytämme klassisen UML-merkinnän käytön kannalta poikkeavaa lähestymistapaa. Mutta tähän on useita syitä. Ensinnäkin juuri ennen mallinnuksen aloittamista kokoamme ns mallisopimus, johon tallennamme kaikki merkinnän käytön ominaisuudet. Toiseksi, tätä lähestymistapaa sovellettiin toistuvasti menestyksekkäästi liiketoimintamallinnuksen vaiheessa oikeissa projekteissa ohjelmistojärjestelmien luomiseksi, tulokset kirjattiin pienessä tekijätiimimme vastaavaan tekijänoikeusobjektiin [6], ja niitä käytettiin myös koulutusoppaassa [; 7]. Aktiviteettikaaviossa määritämme, että kaaviokenttä on rakennettu "uimaratojen" avulla. Raidan nimi vastaa kaavioelementtien tyyppiä, jotka sijoitetaan kyseiselle kappaleelle.
"Syöttö- ja tulostusartefaktit": Tämä raita sisältää Objects-elementtejä - objekteja, joita käytetään tai jotka ovat tulosta jonkin prosessivaiheen suorittamisesta.
"Prosessin vaiheet": Tänne sijoitamme Aktiviteettielementit - prosessin osallistujien toimet.
"Osallistujat": polku elementeille, jotka osoittavat toiminnan esittäjien rooleja prosessissamme, käytämme heille samaa mallinnuselementtiä Object - objektia, mutta lisäämme siihen "Actor" -stereotyypin.
Seuraava kappale on nimeltään "Liiketoimintasäännöt" ja tälle raidalle laitamme tekstimuotoon säännöt prosessin vaiheiden suorittamisesta ja tähän käytämme mallinnuselementtiä Note - note.
Pysähdymme tähän, vaikka voisimme myös käyttää polkua "Työkalut" kerätä tietoa prosessiautomaation tasosta. Polku voi myös olla hyödyllinen "Osallistujien asemat ja jaot", sitä voidaan käyttää yhdistämään rooleja prosessin osallistujien tehtäviin ja osastoon.
Kaikki, mitä juuri kuvailin, on fragmentti mallinnussopimukset, tämä sopimuksen osa koskee yhden kaavion järjestämisen sääntöjä ja vastaavasti sen kirjoittamisen ja lukemisen sääntöjä.
"Resepti"
Tarkastellaan nyt vaihtoehtoa mallintaa järjestelmä erikseen aktiivisuuskaaviosta. Tämä on vain yksi vaihtoehdoista, mutta huomautan, että se ei tietenkään ole ainoa. Aktiivisuuskaavio kiinnostaa meitä sen roolin kannalta siirtymisessä prosessimallintamisesta automatisoidun järjestelmän suunnitteluun. Tätä varten noudatamme metodologisia suosituksia - eräänlaista reseptiä, joka koostuu vain viidestä vaiheesta ja tarjoaa vain kolmen tyyppisten kaavioiden kehittämisen. Tämän reseptin käyttäminen auttaa meitä saamaan virallisen kuvauksen prosessista, jonka haluamme automatisoida ja kerätä tietoja järjestelmän suunnittelua varten. Ja UML:n opiskelun alussa opiskelijoille tämä on eräänlainen pelastusväline, joka ei anna heidän hukkua kaikkiin erilaisiin visuaalisiin keinoihin ja tekniikoihin, joita UML: stä ja nykyaikaisista mallinnustyökaluista löytyy.
Tässä itse asiassa itse resepti, ja seuraa sitten "satu"-aihealueellemme rakennettuja kaavioita.
Vaihe 1. Kuvaamme prosessin aktiivisuuskaavion muodossa. Prosessissa, jossa on yli 10 vaihetta, on järkevää soveltaa prosessivaiheen hajotteluperiaatetta kaavion luettavuuden parantamiseksi.
Vaihe 2. Valitse, mikä voidaan automatisoida (vaiheet voidaan korostaa esimerkiksi kaaviossa).
Vaihe 3. Automatisoidulle vaiheelle on määritettävä järjestelmän toiminto tai toiminnot (suhde voi olla useista moneen), piirrä käyttötapauskaavio. Nämä ovat järjestelmämme toimintoja.
Vaihe 4. Kuvataan AS:n sisäistä organisaatiota luokkakaavion avulla - Luokka. Toimintokaavion "Syöte- ja lähtöobjektit (asiakirjat)" -uimarata on objektimallin ja entiteetti-suhdemallin rakentamisen perusta.
Vaihe 5. Analysoidaan "Business Rules" -raidan muistiinpanot, ne tarjoavat erilaisia rajoituksia ja ehtoja, jotka muuttuvat vähitellen ei-toiminnallisiksi vaatimuksiksi.
Tuloksena oleva kaaviosarja (Activity, Use-case, Class) antaa meille formalisoidun kuvauksen melko tiukoilla merkinnöillä, ts. on yksiselitteinen lukema. Nyt voit kehittää teknisiä eritelmiä, selventää vaatimuksia jne.
Aloitetaan mallinnus.
Vaihe 1. Kuvaa prosessi toimintokaavion muodossa
Muistutan teitä siitä, että rakensimme kaaviokentän käyttämällä "uimaratoja" jokainen kaista sisältää samantyyppisiä elementtejä (kuva 2). Yllä kuvattujen kaavioelementtien lisäksi käytämme lisäelementtejä, kuvataan ne.
Päätös (Decision) merkitsee kaaviossa prosessimme haarautumiskohtaa ja lankojen yhdistäminen (Merge) - niiden yhdistämiskohtaa. Siirtymäehdot kirjoitetaan hakasulkeissa siirtymissä.
Kahden synkronoijan (Fork) välillä näytämme rinnakkaiset prosessihaarat.
Prosessillamme voi olla vain yksi alku - yksi aloituspiste (alku). Mutta voi olla useita täydennyksiä (lopullinen), mutta ei meidän erityisessä kaaviossamme.
On olemassa melko paljon nuolia, joissa on suuri määrä elementtejä ja yhteyksiä, voit ensin tunnistaa prosessin vaiheet ja suorittaa sitten näiden vaiheiden hajotuksen. Mutta selvyyden vuoksi haluaisin näyttää "satuprosessimme" kokonaan yhdellä kaaviolla, samalla kun tietysti meidän on varmistettava, että nuolet "eivät tartu yhteen", olisi mahdollista seurata tarkasti, mikä on kytketty. mihin.
Kuva 2. Toimintakaavio - yleiskuva prosessista
Koska runollisissa riveissä joitain prosessin yksityiskohtia on jätetty pois, ne piti palauttaa, ne esitetään elementeillä valkoisella taustalla. Näihin yksityiskohtiin kuuluvat siirto/vastaanotto tallennusta ja käsittelyä varten sekä useita syöttö- ja tulostusartefakteja. On syytä huomata, että tämä vaihe ei myöskään paljasta prosessia täysin, koska meidän pitäisi nimetä erikseen lähetysvaihe ja vastaanottovaihe ja jopa lisätä erillinen vaihe kuorille, ja myös ajatella, että ensin kaikki nämä aineelliset arvot pitäisi varastoida väliaikaisesti jonnekin jne. ja niin edelleen.
Huomattakoon myös, että kysymys pähkinöiden alkuperästä on edelleen vaille vastausta - mistä ne tulevat ja miten ne pääsevät oravaan? Ja tämä kysymys (se on korostettu punaisella fontilla muistiinpanossa - Huomautus-elementti) vaatii erillisen tutkimuksen! Näin analyytikko toimii - kerää tietoa pala kerrallaan, tekee oletuksia ja vastaanottaa "okei" tai "ei-okei" aiheen asiantuntijoilta - erittäin tärkeitä ja yksinkertaisesti korvaamattomia ihmisiä liiketoimintamallinnuksen vaiheessa järjestelmiä luotaessa.
Huomaa myös, että prosessivaihe P5 koostuu kahdesta osasta.
Ja hajotamme jokaisen osan ja tarkastelemme sitä yksityiskohtaisemmin (kuva 3, kuva 4), koska näissä vaiheissa suoritetut toiminnot automatisoidaan.
Kuva 3. Toimintakaavio - yksityiskohdat (osa 1)
Kuva 4. Toimintakaavio - yksityiskohdat (osa 2)
Vaihe 2. Valitse, mikä voidaan automatisoida
Automatisoitavat vaiheet on korostettu väreillä kaavioissa (katso kuva 3, kuva 4).
Kaikki ne suorittaa yksi prosessin osallistuja - virkailija:
- Syöttää tiedot mutterin painosta lausumaan;
- Syöttää tiedot mutterin siirrosta lausumaan;
- Tallentaa tosiasian pähkinän muuttumisesta kuoreksi ja ytimeksi;
- Syöttää tiedot pähkinän ytimestä käskyyn;
- Syöttää tiedot pähkinänkuorista luetteloon.
Analyysi tehdystä työstä. Mitä seuraavaksi?
Olemme siis tehneet paljon valmistelutyötä: olemme keränneet tietoa prosessista, jonka aiomme automatisoida; alkoi tehdä sopimusta mallintamisesta (toistaiseksi vain aktiivisuuskaavion käytön suhteen); suoritti prosessin simulaation ja jopa hajotti useita sen vaiheita; Tunnistamme prosessin vaiheet, jotka automatisoimme. Olemme nyt valmiita siirtymään seuraaviin vaiheisiin ja aloittamaan järjestelmän toimivuuden ja sisäisen organisaation suunnittelun.
Kuten tiedät, teoria ilman käytäntöä ei ole mitään. Sinun tulisi ehdottomasti kokeilla "mallinnusta" omin käsin, tämä on hyödyllistä myös ehdotetun lähestymistavan ymmärtämiseksi. Voit esimerkiksi työskennellä mallinnusympäristössä [3]. Olemme havainneet vain osan kokonaisprosessikaavion vaiheista (katso kuva 2). Käytännön tehtävänä sinua voidaan pyytää toistamaan kaikki kaaviot Modelio-ympäristössä ja suorittamaan "Siirto/vastaanotto varastointia ja käsittelyä varten" -vaiheen hajottaminen.
Emme vielä harkitse työskentelyä tietyissä mallinnusympäristöissä, mutta tästä saattaa tulla riippumattomien artikkelien ja arvostelujen aihe.
Artikkelin toisessa osassa analysoimme vaiheissa 3-5 tarvittavia mallinnus- ja suunnittelutekniikoita, käytämme UML-käyttötapaus- ja luokkakaavioita. Jatkuu.
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.
Lähde: will.com