Divas pieejas darbības diagrammas strukturēšanai

Divu pieeju salīdzinājums aktivitāšu diagrammas strukturēšanai (pamatojoties uz "vāveres")

В Raksta "No procesu modelēšanas līdz automatizētai sistēmu projektēšanai" 1. daļa modelējām “pasaku” tematiskās jomas procesus - rindiņas par vāveri no A.S.Puškina “Pasaka par caru Saltānu, viņa dēlu, krāšņo un vareno varoni princi Gvidonu Saltanoviču un skaisto gulbju princesi”. Un mēs sākām ar aktivitāšu diagrammu, vienojoties par diagrammas lauka strukturēšanu, izmantojot "peldēšanas joslas". Celiņa nosaukums atbilst diagrammas elementu veidam, kas atrodas šajā celiņā: ievades un izvades artefakti, procesa soļi, dalībnieki un uzņēmējdarbības noteikumi. Šī pieeja atšķiras no standarta, kad trases tiek apzīmētas ar procesa dalībnieku vārdiem, tādējādi piešķirot tiem noteiktas atbildības jomas procesā.

Šajā piemērā es izmantoju Austrālijas uzņēmuma Enterprise Architect vidi. Sparx sistēmas [1].
Sīkāku informāciju par pielietotajām modelēšanas pieejām skatiet [2].
Pilnu UML specifikāciju skatiet šeit [3].

Atkārtošu diagrammas versiju no iepriekšējā raksta (1. attēls) un parādīšu pārzīmētu diagrammu ar “standarta” trasēm (2. attēls), mēģināšu ieskicēt plusus un mīnusus, varbūt nedaudz subjektīvi.

Attēls 1. Darbības diagramma - procesa vispārīgs skats

2. attēls. Darbības diagramma - standarta diagrammas strukturēšana

1. Jāatzīst, ka 2. diagrammā bultu skaits ir nedaudz mazāks.
2. Bet 2. diagrammā objekti ir “izsmērēti” pa visu diagrammas lauku, kas manai gaumei nav īpaši ērti.
3. Tas pats stāsts ar piezīmēm – noteikumi. Un, lai ievietotu noteikumu par diakona iecelšanu, visi diagrammas elementi kādā brīdī bija jāpārvieto uz leju.
4. Man bija jāklonē darbība “saņemt/pārsūtīt…”, lai parādītu, ka šajā solī piedalās vairāki dalībnieki.
5. Otrajā variantā nācās atteikties no viena procesa atzarojuma un vienas sapludināšanas, nu tos “smuki” sakārtot nebija absolūti neiespējami! Par laimi, tad būtu nepieciešams ielikt komentāru - noteikums.

Protams, garšā un krāsā nav biedru, bet pirmais variants man šķiet arī ērtāks datu vākšanai par procesu.
Bet es nemelošu - dažreiz labāk ir uzzīmēt abas iespējas, lai saprastu procesu.

Avotu saraksts

1. Sparx Systems vietne. [Elektroniskais resurss] Piekļuves režīms: Internets: https://sparxsystems.com
2. Zolotuhina E.B., Višņa A.S., Krasņikova S.A. Biznesa procesu modelēšana. - M .: KURS, NITs INFRA-M, EBS Znanium.com. — 2017. gads.
3. OMG vienotās modelēšanas valodas (OMG UML) specifikācija. Versija 2.5.1. [Elektroniskais resurss] Piekļuves režīms: Internets: https://www.omg.org/spec/UML/2.5.1/PDF

Avots: www.habr.com