Kaksi lähestymistapaa toimintakaavion jäsentämiseen
Kahden lähestymistavan vertailu aktiviteettikaavion jäsentämiseen (perustuu "oraviin")
В Artikkelin osa 1 "Prosessimallintamisesta automatisoituun järjestelmäsuunnitteluun" mallinnoimme "sadun" aihealueen prosesseja - rivit oravasta A. S. Pushkinin "Tarina tsaari Saltanista, hänen pojastaan, loistavasta ja mahtavasta sankarista prinssi Gvidon Saltanovichista ja kauniista Joutsenprinsessasta". Ja aloitimme Aktiivisuuskaaviosta ja sopimme kaaviokentän jäsentämisestä "uimaratojen" avulla. Raidan nimi vastaa kyseisessä raidassa olevien kaavioelementtien tyyppiä: syöttö- ja lähtöartefaktit, prosessin vaiheet, osallistujat ja liiketoimintasäännöt. Tämä lähestymistapa eroaa tavanomaisesta, kun reitit on nimetty prosessin osallistujien nimillä, mikä osoittaa heille tietyt vastuualueet prosessissa.
Tässä esimerkissä käytän australialaisen yrityksen Enterprise Architect -kehystä Sparx-järjestelmät [1].
Katso lisätietoja käytetyistä mallinnusmenetelmistä [2].
Katso täydellinen UML-spesifikaatio täällä [3].
Toistan edellisen artikkelin kaavion version (Kuva 1) ja näytän uudelleen piirretyn kaavion "tavallisilla" raidoilla (kuva 2), yritän hahmotella edut ja haitat, ehkä hieman subjektiivisesti.
Kuva 1. Toimintakaavio - yleiskuva prosessista
Kuva 2. Aktiivisuuskaavio - vakiokaaviorakenne
On myönnettävä, että nuolia on hieman vähemmän 2. kaaviossa.
Mutta toisessa kaaviossa esineet ovat "tahrat" koko kaavion kentällä, mikä ei minun makuuni ole kovin kätevää.
Sama tarina muistiinpanojen kanssa - säännöt. Ja jotta voitaisiin lisätä sääntö diakonin nimittämisestä, kaikki kaavion elementit piti jossain vaiheessa siirtää alaspäin.
Minun piti kloonata "vastaanota/lähetä..." -vaihe osoittaakseni, että tässä vaiheessa on läsnä useita osallistujia.
Toisessa vaihtoehdossa jouduin luopumaan yhdestä prosessin haaroituksesta ja yhdestä yhdistämisestä, no, oli täysin mahdotonta järjestää niitä "kivasti"! Onneksi sitten olisi tarpeen lähettää kommentti - sääntö.
Maussa ja värissä ei tietenkään ole tovereita, mutta ensimmäinen vaihtoehto näyttää minusta myös kätevämmältä prosessin tietojen keräämiseen.
Mutta en valehtele - joskus on parempi piirtää molemmat vaihtoehdot prosessin ymmärtämiseksi.