Twee benaderingen voor het structureren van de Activity-diagram

Vergelijking van twee benaderingen voor het structureren van een Activity-diagram (geĆÆnspireerd door 'De Eekhoorn')

In deel 1 van het artikel "Van procesmodellering naar het ontwerpen van een geautomatiseerd systeem" We modelleerden de processen van het 'sprookjesachtige' onderwerp - regels over de eekhoorn uit 'Het sprookje van Tsaar Saltan, over zijn beroemde en krachtige held prins Guidon Saltanovich en de prachtige prinses Zwanen' van A.S. Pushkin. We begonnen met een Activity-diagram en kwamen overeen om het veld van het diagram te structureren met behulp van 'zwemmende' banen - Swim lanes. De naam van de baan komt overeen met het type diagramelementen dat op die baan aanwezig is: 'Ingangs- en uitgangsarthen', 'Processtappen', 'Deelnemers' en 'Zakelijke regels'. Deze benadering verschilt van de standaard, waarbij de banen worden aangeduid met de namen van de deelnemers aan het proces, waardoor zij bepaalde verantwoordelijkheidsgebieden in het proces toegewezen krijgen.

In dit voorbeeld maak ik gebruik van de Enterprise Architect omgeving van het Australische bedrijf Sparx Systems [1].
Voor meer informatie over de toegepaste benaderingen voor modellering zie [2].
De volledige UML-specificatie zie. hier [3].

Ik herhaal de versie van het diagram uit het vorige artikel (Figuur 1) en zal het opnieuw getekende diagram met 'standaard' banen laten zien (Figuur 2), en ik zal proberen de voor- en nadelen aan te geven, misschien ook een beetje subjectief.

Twee benaderingen voor het structureren van de Activity-diagram
Figuur 1. Activity-diagram - algemeen uitzicht op het proces

Twee benaderingen voor het structureren van de Activity-diagram
Figuur 2. Activity-diagram - standaard structurering van het diagram

  1. We moeten toegeven dat het aantal pijlen iets minder is in het tweede diagram.
  2. Maar in het tweede diagram zijn de objecten 'verspreid' over het hele veld van het diagram, wat, naar mijn mening, niet erg handig is.
  3. Hetzelfde geldt voor de opmerkingen - de regels. En om de regel over het benoemen van de diaken toe te voegen, moest ik op een gegeven moment alle diagramelementen naar beneden verplaatsen.
  4. Ik moest de stap 'ontvangst/overdracht...' klonen om te laten zien dat er meerdere deelnemers aan deze stap aanwezig zijn.
  5. In de tweede variant moest ik afstand doen van een vertakking en ƩƩn samenvoeging van het proces; het lukte helemaal niet om ze 'mooi' te plaatsen! Eigenlijk zou ik dan een opmerking moeten plaatsen - een regel.

Over smaak en kleur zijn er natuurlijk geen vrienden, maar ik vind de eerste variant ook handiger voor het verzamelen van gegevens over het proces.
Maar ik ga niet liegen - soms is het beter om beide varianten opnieuw te tekenen om het proces te begrijpen.

Lijst van bronnen

  1. Website van Sparx Systems. [Elektronische bron] Toegang: Internet: https://sparxsystems.com
  2. Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modelleren van bedrijfsprocessen. — M.: KURS, NIC INFRA-M, EBS Znanium.com. — 2017.
  3. OMG Unified Modeling Language (OMG UML) Specificatie. Versie 2.5.1. [Elektronische bron] Toegang: Internet: https://www.omg.org/spec/UML/2.5.1/PDF

Bron: habr.com

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers šŸ”„ Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster