«Een dag uit het leven van een eekhoorn» of van het modelleren van processen naar het ontwerpen van een geautomatiseerd systeem voor de registratie van materiële waarden «Eekhoorn-1.0» (Deel 2)
Korte samenvatting van de vorige aflevering
In Wij hebben gebruik gemaakt van een «sprookjesachtige» thematische omgeving, geïnspireerd door voorbeelden van het bestuderen van UML-diagrammen aan de hand van sprookjesverhalen (zie bijvoorbeeld, [1]). Voorafgaand aan de modellering hebben we afspraken gemaakt over het gebruik van bepaalde elementen van het Activity-diagram en begonnen we overeenkomsten voor de modellering op te stellen. Gezien deze afspraken hebben we in de eerste fase het proces beschreven in de vorm van Activity-diagrammen, en in de tweede fase hebben we de processtappen geïdentificeerd waarvoor automatisering nodig is (en mogelijk is).
Ik herinner u eraan dat we de activiteit van de registratie van materiële waarden willen automatiseren, die zich voordoet in 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 Saltanovitsj en over de prachtige prinses Zwanen», )
In dit voorbeeld maak ik gebruik van de Enterprise Architect omgeving van het Australische bedrijf [2], en binnen de lessen pas ik toe [3].
Ik herinner u eraan dat er verschillende processen zijn, die u kunt verkennen, bijvoorbeeld, [4] en [5].
Voor meer informatie over de toegepaste benaderingen voor modellering en ontwerp, zie [6, 7].
De volledige UML-specificatie zie. [8].
Nu zijn we klaar om over te gaan naar de volgende fasen en te beginnen met het ontwerpen van de systeemfunctionaliteiten en de interne organisatie ervan. De nummering van de figuren zal worden voortgezet.
Stap 3. Aan de geautomatiseerde stap moet een functie of functies van het systeem worden gekoppeld.
Het te ontwikkelen geautomatiseerde systeem (GS) is bedoeld voor een strikte administratie van noten, weet je nog? Voor elke aangewezen stap (zie Figuur 3, Figuur 4) die we gaan automatiseren, zullen we een functionele eis formuleren, met een constructie zoals âHet systeem moet de mogelijkheid biedenâŠâ en we zullen een Use-case-diagram ontwikkelen. We breiden ons modelovereenkomst nu feitelijk uit met nieuwe regels. Ik zal uitleggen welke elementen we zullen gebruiken. ), die we gaan automatiseren, zullen we een functionele eis opstellen, met de constructie âHet systeem moet de mogelijkheid biedenâŠâ en we zullen een Use-case-diagram ontwikkelen. We breiden ons modelovereenkomst nu feitelijk uit met nieuwe regels. Ik zal uitleggen welke elementen we zullen gebruiken.
Tussen 'Rol van de gebruiker' en 'Functie' zullen we de relatie 'Associatie' gebruiken (Figuur 5), wat betekent dat voor een gebruiker met deze rol het uitvoeren van deze functie beschikbaar is.
Figuur 5. Gebruik van de relatie 'Associatie'
Van 'Functie' naar 'Eis' leggen we de relatie 'Realiseer' (Figuur 6) om aan te geven dat deze eis door deze functies zal worden gerealiseerd; de relatie kan ook 'veel-tot-veel' zijn, wat betekent dat Ă©Ă©n functie kan deelnemen aan de realisatie van meerdere eisen, en voor de realisatie van een eis kunnen meer dan Ă©Ă©n functie nodig zijn.
Figuur 6. Gebruik van de relatie 'Realiseer'
Als Ă©Ă©n functie vereist dat een andere functie wordt uitgevoerd, en dat is absoluut noodzakelijk, gebruiken we de relatie âAfhankelijkheidâ met het stereotype âIncludeâ â insluiting (Figuur 7). Als de uitvoering van de aanvullende functie echter onder bepaalde voorwaarden vereist is, gebruiken we de relatie âAfhankelijkheidâ met het stereotype âExtendâ â uitbreiding. Het is heel gemakkelijk te onthouden: âIncludeâ â ALTIJD, en âExtendâ â SOMS.
Figuur 7. Gebruik van de relatie 'Afhankelijkheid (insluiting)'
Uiteindelijk zal ons diagram er ongeveer zo uitzien (Figuur 8).
Figuur 8. Use-case-diagram (functioneel model van GS)
Bovendien wordt het Use-case-diagram gebruikt om de rollen van gebruikers te modelleren (Figuur 9).
Figuur 9. Use-case-diagram (rollen van gebruikers van GS)
Stap 4. We zullen de interne organisatie van GS beschrijven met behulp van een klassendiagram.
Met gebruik van informatie over de inkomende en uitgaande artefacten van ons proces (zie diagrammen Activiteit - Figuur 2, Figuur 3, Figuur 4), zullen we een klasse-diagram ontwikkelen. We gebruiken de modelleerelementen 'Klasse' en verschillende soorten relaties tussen hen.
Om de relatie 'geheel-deel' weer te geven, gebruiken we de aggregatietype relatie (Figuur 10): de noot is het geheel, en de schalen en het hart zijn de delen.
Figuur 10. Relatie 'geheel-deel'
Uiteindelijk ziet het fragment van ons diagram eruit als volgt (Figuur 11). De gekleurde klassen zijn aangegeven die we rechtstreeks in de tekstuele beschrijving van het proces hebben geĂŻdentificeerd.
Figuur 11. Klasse-diagram
Het klasse-diagram werd ook gebruikt voor het modelleren van andere artefacten - niet alleen die betrekking hebben op het conceptuele model van het te automatiseren proces voor de registratie van materiële waarden, maar ook die betrekking hebben op de uitvoeringsomgeving - de omgeving (Figuur 12) en 'buurprocessen' (Figuur 13), die invloed kunnen uitoefenen op het te automatiseren proces, maar op dit moment niet in onze focus liggen (we gaan ervan uit dat het systeem zich zal ontwikkelen en deze informatie nuttig zal blijken te zijn).
Figuur 12. Klasse-diagram (omgeving)
De erfelijkheidsrelatie toont de veralgemening van verschillende structuren, 'kind' klassen onder de algemeen 'ouder' klas 'Structuur'.
Figuur 13. Klasse-diagram (aanvullende informatie over artefacten)
De 'reactie op de situatie' hangt af van de 'Visuele controle gegevens'. Voor verschillende afhankelijkheidsrelaties wordt het stereotype 'trace' gebruikt om de tracering van klassen aan te geven, die niet expliciet in de procesbeschrijving zijn aangeduid, maar die nodig zijn voor de automatisering, naar de klassen waarvan de instanties exact worden aangeduid in onze beschrijving.
Stap 5. We analyseren de notities op het pad 'Bedrijfsregels'
Als regels zijn aangegeven (zie Figuur 2 ):
- de noodzaak om een van de stappen op te splitsen in 2 delen, waarbij het tweede deel alleen wordt uitgevoerd onder bepaalde voorwaarden;
- een specifieke verantwoordelijke aan te wijzen voor het registreren van de noten;
- een technische aanwijzing (witte kleur van de elementen), die aangeeft dat het element niet expliciet in de procesbeschrijving was aangegeven.
Het moet worden opgemerkt dat we al deze regels hebben gebruikt bij het ontwikkelen van de diagrammen.
Slotopmerkingen
We hebben dus 5 fasen doorlopen en 3 soorten diagrammen gemaakt. Ik voeg nog een kleine opmerking toe over de organisatie van onze modellen in de modelleringsomgeving. Er zijn veel frameworks die helpen bij het structureren van de ontwikkelde modellen, maar dit valt buiten het bereik van dit artikel. Daarom beperken we ons tot de volgende eenvoudige set van pakketten voor het ordenen van ons project: Bedrijfsproces, Functioneel model, Artefacten, Deelnemers en Omgeving (Figuur 14).
Figuur 14. Structuur van de projectpakketten
Zo hebben we coherente modellen ontwikkeld die het systeem voor het registreren van materiële waarden vanuit verschillende hoeken beschrijven: het model van het te automatiseren bedrijfsproces, het functionele model en het model van de interne organisatie van het systeem op conceptueel niveau.
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.
- OMG Unified Modeling Language (OMG UML) Specificatie. Versie 2.5.1. [Elektronische bron] Toegang: Internet:
Bron: habr.com
