"Een dag uit het leven van een eekhoorn" of van modelleren van processen naar het ontwerpen van een geautomatiseerd systeem voor de registratie van materiële waarden "Belka-1.0" (Deel 1)
Wat heeft "eekhoorn" ermee te maken?
Ik leg onmiddellijk uit wat "eekhoorn" hiermee te maken heeft. Terwijl ik online interessante projecten tegenkwam voor het bestuderen van UML, gebaseerd op thema's uit sprookjes (bijvoorbeeld, [1]), besloot ik ook voor mijn studenten een soortgelijk voorbeeld voor te bereiden, zodat ze in eerste instantie drie soorten diagrammen konden bestuderen: Activiteitsdiagram, Use-case diagram en Klasse diagram. Ik vertaal de namen van de diagrammen bewust niet naar het Nederlands om discussies over "vertalingsproblemen" te vermijden. Wat waarvoor dient, zal ik later iets meer uitleggen. In dit voorbeeld gebruik ik de Enterprise Architect omgeving van het Australische bedrijf [2] â een goed instrument voor een redelijke prijs. En in het kader van de lesactiviteiten gebruik ik [3], een goede gratis tool voor object-georiĂ«nteerd ontwerp, die de normen van UML2.0 en BPMN ondersteunt, zonder onnodige opsmuk in termen van artistieke mogelijkheden, maar voldoende voor het leren van de basis van de taal.
We willen de activiteiten automatiseren voor de registratie van materiële waarden die voortkomen uit deze processen.
âŠ
Een eiland ligt in de zee, (E1, E2)
Een stad staat op het eiland (E3, E1)
Met gouden kerken, (E4)
Met torens en tuinen; (E5, E6)
Een den groeit voor het paleis, (E7, E8)
En eronder staat een kristallen huis; (E9)
Een eekhoorn woont daar, (A1)
En wat een grapjas! (A1)
De eekhoorn zingt liedjes, (P1, A1)
En knabbelt aan noten, (P2)
Maar de noten zijn niet zomaar, (C1)
Allemaal met gouden doppen, (C2)
De noten zijn puur smaragd; (C3)
De dienaren bewaken de eekhoorn, (P3, A2)
Diverse dienaren bedienen haar (P4)
En er is een strenge diaken aangesteld (A3)
Strikte controle op de noten; (P5, C1)
Geeft haar een militaire eer; (P6, A4)
Van de doppen maken ze munten, (P7, C2, C4)
Die brengen ze overal in de wereld; (P8)
Meisjes strooien smaragden (P9, A5, C3)
In de schatkamers, en onder de vloer; (E10, E11)
âŠ
(A.S. Poesjkin "Het sprookje van Tsaar Saltan, over zijn beroemde en krachtige held prins Gvidon Saltanovich en over de mooie prinses Zwanen", â 10 jaar van het idee tot publicatie, trouwens!)
Een beetje over de codes die aan de rechterkant van de regels zijn geschreven. "A" (van "Actor") betekent dat in de regel informatie over een deelnemer aan het proces is opgenomen. "C" (van "Class") â informatie over de objecten van klassen die tijdens de uitvoering van processen worden verwerkt. "E" (van "Environment") â informatie over de objecten van klassen die de omgeving van de uitvoering van processen karakteriseren. "P" (van "Process") â informatie over de processen zelf.
Overigens is de exacte definitie van het proces ook een onderwerp van methodologische discussies, mede omdat processen in verschillende vormen voorkomen: business-, productie-, technologische, enzovoort (bijvoorbeeld, [4] en [5]). Om een discussie te vermijden, laten we overeenkomen dat het proces voor ons interessant is vanuit het perspectief van de herhaalbaarheid in de tijd en de behoefte aan automatisering, d.w.z. het overdragen van de uitvoering van een deel van de processen naar een geautomatiseerd systeem.
Aantekeningen over het gebruik van de Activity-diagram
Laten we beginnen met het modelleren van ons proces en hiervoor het Activity-diagram gebruiken. Eerst zal ik uitleggen hoe de hierboven genoemde codes in het model zullen worden gebruikt. Het is gemakkelijker om dit met een grafisch voorbeeld uit te leggen, en we zullen ook enkele (bijna alle benodigde) elementen van het Activity-diagram bespreken.
Laten we het volgende fragment analyseren:
âŠ
De eekhoorn zingt liedjes, (P1, A1)
En knabbelt aan noten, (P2)
Maar de noten zijn niet zomaar, (C1)
Allemaal met gouden doppen, (C2)
De noten zijn puur smaragd; (C3)
âŠ
We hebben twee stappen van het proces P1 en P2, deelnemer A1, en objecten van drie verschillende klassen: een object van klasse C1 komt binnen in stap, en de objecten van klassen C2 en C3 verschijnen aan de uitgang, als resultaat van de activiteit van deze stap P2 van ons proces. Voor het diagram gebruiken we de volgende modellerende elementen.
Het fragment van ons proces kan ongeveer zo worden weergegeven (Figuur 1).
Figuur 1. Fragment van het Activity-diagram
Voor het organiseren van de ruimte en het structureren van het Activity-diagram zullen we een niet-standaard aanpak toepassen, gezien vanuit het klassieke gebruik van de UML-notatie. Maar hiervoor zijn verschillende redenen. Ten eerste, voordat we met de modellering beginnen, zullen we een zogenaamd modelleerakkoord, waarin we alle bijzonderheden van het gebruik van de notatie zullen vastleggen. Ten tweede, deze aanpak is herhaaldelijk met succes toegepast in de fase van businessmodellering in echte projecten voor het ontwikkelen van softwaresystemen, waarvan de resultaten zijn vastgelegd door onze kleine auteursgroep in het overeenkomstige object van auteursrecht [6], en ook gebruikt in een leerboek [7]. Voor het Activity-diagram zullen we bepalen dat het veld van het diagram wordt gestructureerd met behulp van 'zwemmende' lanes â Swim lanes. De naam van de lane zal overeenkomen met het type elementen van het diagram die op deze lane worden geplaatst.
"Ingangs- en uitgangsartefacten:" Op dit pad zullen de elementen Objects worden geplaatst â objecten die worden gebruikt of het resultaat zijn van de uitvoering van een bepaalde stap in het proces.
«Processtappen»: hier plaatsen we de elementen Activity â de acties van de deelnemers aan het proces.
«Deelnemers»: een pad voor elementen die de rollen van uitvoerders van acties in ons proces zullen aanduiden, hiervoor zullen we weer hetzelfde modelleer element Object gebruiken â een object, maar we zullen het stereotype «Actor» eraan toevoegen.
Het volgende pad heet «Bedrijfsregels» en op dit pad zullen we de regels voor het uitvoeren van processtappen in tekstvorm plaatsen, en we zullen hiervoor het modelleerelement Note â opmerking gebruiken.
We stoppen hier, hoewel we ook nog het pad zouden kunnen gebruiken «Tools» om informatie te verzamelen over het niveau van automatisering van het proces. Daarnaast kan het pad «Functies en afdelingen van deelnemers», worden gebruikt om de rollen met de functies en afdelingen van de deelnemers aan het proces te verbinden.
Alles wat ik zojuist heb beschreven is een fragment van de modelleerovereenkomst, dit deel van de overeenkomst betreft de regels voor het organiseren van Ă©Ă©n diagram en bijbehorende regels voor het schrijven en lezen ervan.
«Recept»
Laten we nu de optie voor het modelleren van het systeem bekijken vanuit de Activity-diagram. Dit is slechts Ă©Ă©n van de opties, ik wil opmerken dat het zeker niet de enige is. De Activity-diagram zal ons interesseren vanuit het perspectief van de rol ervan bij de overgang van procesmodellering naar het ontwerp van een geautomatiseerd systeem. Hiervoor zullen we de methodologische aanbevelingen volgen â een soort recept, bestaande uit slechts vijf stappen en vereist de ontwikkeling van slechts drie soorten diagrammen. Het toepassen van dit recept zal helpen een formele beschrijving van het proces te verkrijgen dat we willen automatiseren en gegevens te verzamelen voor het ontwerpen van het systeem. En voor studenten die aan de studie van UML beginnen, is dit een soort reddingsboei, die ervoor zorgt dat ze niet verdrinken in de overvloed aan representatiemiddelen en technieken die er zijn in UML en moderne modelleertools.
Hier is het recept zelf, waarna de diagrammen volgen die zijn opgebouwd voor onze «sprookjesachtige» onderwerpgebied.
Stap 1. We beschrijven het proces in de vorm van een Activity-diagram. Voor processen met meer dan 10 stappen is het zinvol om het principe van decompositie toe te passen om de leesbaarheid van het diagram te verbeteren.
Stap 2. Identificeer wat geautomatiseerd kan worden (de stappen kunnen bijvoorbeeld op het diagram worden gemarkeerd).
Stap 3. Aan de geautomatiseerde stap moet een functie of functies van het systeem worden gekoppeld. (de relatie kan veel-op-veel zijn), we tekenen een use-case diagram. Dit zijn functies van ons systeem.
Stap 4. We zullen de interne organisatie van GS beschrijven met behulp van een klassendiagram. â Class. De zwembanen 'In- en uitgangsobjecten (documenten)' op het Activity-diagram vormen de basis voor het opstellen van het objectmodel en het entiteit-relatie model.
Stap 5. We analyseren de notities op het pad 'Bedrijfsregels', ze geven verschillende soorten beperkingen en voorwaarden, geleidelijk transformeren ze in niet-functionele eisen.
De resulterende verzameling diagrammen (Activity, Use-case, Class) geeft ons een geformaliseerde beschrijving in een voldoende strikte notatie, d.w.z. heeft een eenduidige interpretatie. Nu kunnen we een technisch document opstellen, de specificatie van eisen verduidelijken, enz.
Laten we beginnen met modelleren.
Stap 1. Beschrijf het proces in de vorm van een Activity-diagram
Ik herinner je eraan dat we het veld van het diagram hebben gestructureerd met behulp van 'zwembanen', op elke baan bevinden zich elementen van hetzelfde type (Afbeelding 2). Behalve de hierboven beschreven elementen van het diagram zullen we extra elementen gebruiken, laten we deze beschrijven.
Een beslissing (Decision) op het diagram markeert een vertakking in ons proces, en het samenvoegen van stromen (Merge) markeert het punt van hun samensmelting. In de vierkante haken op de overgangen zijn de voorwaarden voor de overgang vermeld.
Tussen twee synchronisatoren (Fork) zullen we parallelle takken van het proces tonen.
Ons proces kan maar Ă©Ă©n begin hebben â Ă©Ă©n toegangspunt (Initial). Maar er kunnen meerdere eindpunten (Final) zijn, maar niet voor ons specifieke diagram.
Er zijn behoorlijk veel pijlen, vooral bij een groot aantal elementen en verbindingen; je kunt eerst de processtappen scheiden en daarna de decompositie van deze stappen uitvoeren. Maar ik zou ons 'fabelachtige' proces graag in zijn geheel op Ă©Ă©n diagram willen tonen, waarbij we natuurlijk moeten streven naar een situatie waarin de pijlen 'niet samensmelten', zodat we precies kunnen volgen wat met wat is verbonden.
Afbeelding 2. Activity-diagram â algemeen overzicht van het proces
Omdat in de poëtische regels enkele details van het proces zijn weggelaten, moesten we deze reconstrueren, welke worden weergegeven als elementen met een witte achtergrond. Deze details omvatten de stap 'Overdracht/ontvangst voor opslag en verwerking' en verschillende in- en uitvoer artefacten. Het moet worden opgemerkt dat deze stap ook het proces niet volledig onthult, omdat we de stap van overdracht en ontvangst apart moeten aangeven, en we zouden ook een aparte stap voor de schalen moeten toevoegen, en ook moeten veronderstellen dat al deze materiële waarden tijdelijk ergens moeten worden opgeslagen, enzovoort.
Laten we ook opmerken dat de vraag naar de oorsprong van de noten - waar ze vandaan komen en hoe ze bij de eekhoorn terechtkomen - nog onbeantwoord is gebleven. En deze vraag (uitgelicht in rode letterkleur in de opmerking - element Note) vereist verdere uitwerking! Zo werkt een analist - door steeds weer stukjes informatie te verzamelen, veronderstellingen te doen en een 'oké' of 'niet-oké' van domeinexperts te ontvangen - zeer belangrijke en gewoon onmisbare mensen in de fase van businessmodellering bij het creëren van systemen.
Laten we ook opmerken dat de stap in het proces P5 uit twee delen bestaat.
En we zullen elk deel decomponeren en het in detail bekijken (Figuur 3, Figuur 4), omdat de activiteiten die binnen deze stappen worden uitgevoerd, geautomatiseerd zullen worden.
Figuur 3. Activiteitsdiagram - detail (deel 1)
Figuur 4. Activiteitsdiagram - detail (deel 2)
Stap 2. Identificeer wat geautomatiseerd kan worden
De stappen die geautomatiseerd moeten worden, zijn in de diagrammen gemarkeerd met kleur (zie Figuur 3, Figuur 4).
Al deze stappen worden uitgevoerd door Ă©Ă©n deelnemer aan het proces - de bevelvoerder:
- Voert informatie over het gewicht van de noot in het register in;
- Voert informatie over de overdracht van de noot in het register in;
- Legt vast dat de noot is omgevormd tot schalen en een kern;
- Voert informatie over de kern van de noot in het register in;
- Voert informatie over de schalen van de noot in het register in.
Analyse van het uitgevoerde werk. Wat nu?
We have done a lot of preparatory work: gathered information about the process we want to automate; started forming an agreement on modeling (currently only regarding the use of the Activity diagram); modeled the process and even performed decomposition of several of its steps; identified the steps of the process that we will automate. Now we are ready to move on to the next stages and start designing the system functions and its internal organization.
As is well known, theory without practice is nothing. It is essential to try "modeling" hands-on, which is beneficial for understanding the proposed approach. For example, you can work in a modeling environment. [3]. We have decomposed only part of the steps in the overview diagram of the process (see Figure 2). As a practical assignment, you could be asked to recreate all diagrams in the Modelio environment and perform the decomposition of the step "Transfer/Reception for Storage and Processing."
We are not currently considering work in specific modeling environments, but this may become the subject of independent articles and reviews.
In the second part of the article, we will explore modeling and design techniques necessary in stages 3-5, using UML Use-case and Class diagrams. To be continued.
Lijst van bronnen
- Website âUML2.ruâ. Forum van de Analytici Community. Algemeen gedeelte. Voorbeelden. Voorbeelden van verhalen gepresenteerd als UML-diagrammen. [Elektronische bron] Toegang: Internet:
- Website van Sparx Systems. [Elektronische bron] Toegang: Internet:
- Website van Modelio. [Elektronische bron] Toegang: Internet:
- Grote Encyclopedische Woordenboek. Proces (uitleg). [Elektronische bron] Toegang: Internet:
- Website âEffectief Beheer Organisatieâ. Blog. Sectie âBeheer van bedrijfsprocessenâ. Definitie van een bedrijfsproces. [Elektronische bron] Toegang: Internet:
- Getuigschrift â 18249 over de registratie en depot van het werk resultaat van intellectuele activiteit. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manuscript van de onderwijs- en methodologische gids met de titel âModelleren van het onderwerpgebied met behulp van Enterprise Architectâ // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modelleren van bedrijfsprocessen. â M.: KURS, NIC INFRA-M, EBS Znanium.com. â 2017.
Bron: habr.com
