Van procesmodellering tot geautomatiseerd systeemontwerp (Deel 2)
"Een dag in het leven van een eekhoorn" of van het modelleren van processen tot het ontwerpen van een geautomatiseerd systeem voor de boekhouding van materiële activa "Belka-1.0" (deel 2)
В 1e deel we gebruikten een "sprookjesachtig" onderwerpgebied geïnspireerd op voorbeelden van het bestuderen van UML-diagrammen op basis van sprookjesachtige plots (zie bijvoorbeeld hier [1]). Voorafgaand aan het modelleren zijn we het eens geworden over het gebruik van enkele elementen van het activiteitendiagram en zijn we begonnen met het vormen van een modelleringsovereenkomst. Rekening houdend met deze afspraken hebben we in de 1e fase het proces beschreven in de vorm van Activiteitendiagrammen en in de 2e fase de processtappen geïdentificeerd waarvoor automatisering nodig (en mogelijk) is.
Laat me u eraan herinneren dat we de boekhouding van materiële waarden die in deze processen ontstaan, gaan automatiseren.
...
Een eiland in de zee ligt, (E1, E2)
Hagel op de eilandtribunes (E3, E1)
Met kerken met gouden koepels, (E4)
Met torens en tuinen; (E5, E6)
Spar groeit voor het paleis, (E7, E8)
En daaronder is een kristallen huis; (E9)
Daar woont de eekhoorn, tam, (A1)
Ja, wat een entertainer! (A1)
Eekhoorn zingt liedjes, (P1, A1)
Ja, hij knaagt aan alle noten, (P2)
En noten zijn niet eenvoudig, (C1)
Alle schelpen zijn goudkleurig, (C2)
Kernels pure smaragd; (C3)
Bedienden bewaken de eekhoorn, (P3, A2)
Dien haar als bedienden van verschillende soorten (P4)
En er werd een klerk toegewezen (A3)
Strikt verslag van notennieuws; (P5, C1)
Geeft haar leger eer; (P6, A4)
Er wordt een munt uit de schelpen gegoten, (P7, C2, C4)
Laat ze rond de wereld zweven; (P8)
Meisjes gooien smaragd (P9, A5, C3)
In pantry's, maar onder een korenmaat; (E10, E11)
... (A.S. Poesjkin "Het verhaal van tsaar Saltan, van zijn glorieuze en machtige zoon Prins Gvidon Saltanovich en de mooie Zwanenprinses", zoals men denkt, een vrije bewerking van het volksverhaal "Kniediep in goud, elleboogdiep in zilver", dat door Poesjkin in verschillende versies werd opgeschreven)
In dit voorbeeld gebruik ik de Enterprise Architect-omgeving van een Australisch bedrijf. Sparx Systems [2], en in het kader van trainingen die ik gebruik Modelio [3].
Laat me je eraan herinneren dat processen anders zijn, je kunt bijvoorbeeld kennis maken met hier [4] en hier [5].
Zie [6, 7] voor details over de toegepaste benaderingen van modellering en ontwerp.
Zie voor de volledige UML-specificatie hier [8].
We zijn nu klaar om verder te gaan met de volgende stappen en beginnen met het ontwerpen van de functies van het systeem en de interne organisatie ervan. De cijfernummering gaat door.
Fase 3. Aan de geautomatiseerde stap moet een functie of functies van het systeem worden toegewezen
Het geautomatiseerde systeem (AS) dat wordt ontwikkeld, is ontworpen om een strikt register van noten bij te houden, weet je nog? Voor elke gemarkeerde stap (zie afbeelding 3, afbeelding 4 in deel 1), die we gaan automatiseren, de functionele eis opschrijven, gebruikmakend van zoiets als deze constructie "Het systeem moet in staat zijn ..." en een Use-case diagram ontwikkelen. Nu vullen we onze modellenovereenkomst eigenlijk aan met nieuwe regels. Ik zal uitleggen welke elementen we zullen gebruiken.
Tussen de “Gebruikersrol” en de “Functie” gebruiken we de “Associatie”-relatie (Figuur 5), wat betekent dat de gebruiker met deze rol deze functie kan uitvoeren.
Afbeelding 5. Een associatietyperelatie gebruiken
Van "Functie" naar "Vereiste", zullen we de koppeling "Implementatie" tekenen (Afbeelding 6) om aan te tonen dat deze vereiste door deze functies zal worden geïmplementeerd, de relatie kan "veel-op-veel" zijn, d.w.z. één functie kan betrokken zijn bij de implementatie van meerdere vereisten, en er kan meer dan één functie nodig zijn om de vereiste te implementeren.
Figuur 6. Een implementatierelatie gebruiken
Als voor de uitvoering van een functie een andere functie moet worden uitgevoerd, en dit is noodzakelijk, gebruiken we de verbinding "Afhankelijkheid" met het stereotype "Include" - inclusie (Afbeelding 7). Als de uitvoering van een extra functie onder bepaalde voorwaarden vereist is, gebruiken we de "Dependence" -verbinding met het "Extend" -stereotype - een extensie. Alles is heel gemakkelijk te onthouden: "Include" - ALTIJD en "Extend" - SOMS.
Afbeelding 7. Het koppelingstype "Dependency (include)" gebruiken
Als gevolg hiervan zal ons diagram er ongeveer zo uitzien (figuur 8).
Figuur 8. Use-case diagram (functioneel model van AS)
Daarnaast wordt het Use-case diagram gebruikt om gebruikersrollen te modelleren (Figuur 9).
Figuur 9. Use-case diagram (rollen van AS-gebruikers)
Fase 4. Laten we de interne organisatie van het AS beschrijven met behulp van een klassendiagram
Met behulp van informatie over de invoer- en uitvoerartefacten van ons proces (zie Activiteitendiagrammen - Afbeelding 2, Afbeelding 3, Afbeelding 4), zullen we een klassendiagram ontwikkelen. We zullen de "Klasse"-modelleringselementen en verschillende soorten relaties daartussen gebruiken.
Om de "hele-deel"-relatie weer te geven, gebruiken we de "Aggregatie"-type relatie (Afbeelding 10): de noot is het geheel en de schelpen en de pit zijn de delen.
Figuur 10. Gehele-deelrelatie
Als gevolg hiervan zal een fragment van ons diagram er ongeveer zo uitzien (figuur 11). Klassen zijn gemarkeerd met kleur, die we direct hebben gemarkeerd in de tekstbeschrijving van het proces.
Figuur 11. Klassendiagram
Het klassediagram werd ook gebruikt om andere artefacten te modelleren - niet alleen die welke relevant zijn voor het conceptuele model van het geautomatiseerde inventarisatieproces, maar ook gerelateerd aan de uitvoeringsomgeving - de omgeving (Afbeelding 12) en "naburige" processen (Afbeelding 13) die het geautomatiseerde proces kunnen beïnvloeden, maar nog niet in het middelpunt van onze aandacht staan (we gaan ervan uit dat het systeem zich zal ontwikkelen en deze informatie nuttig zal zijn).
Figuur 12. Klassendiagram (omgeving)
De overervingsrelatie toont de veralgemening van verschillende gebouwen, "kind"-klassen, onder de veralgemenende "ouder"-klasse "Gebouw".
Figuur 13. Klassendiagram (meer informatie over artefacten)
De "Reactie op de situatie" is afhankelijk van de "Visuele controlegegevens". Voor verschillende afhankelijkheidsrelaties wordt het stereotype "trace" gebruikt om de tracering te tonen van klassen die niet expliciet in de procesbeschrijving worden aangegeven, maar die nodig zijn voor de automatisering ervan, naar klassen waarvan de instanties precies worden aangegeven in onze beschrijving.
Fase 5. Laten we de notities op het spoor "Business Rules" analyseren
Zoals regels werden gespecificeerd (zie figuur 2 in deel 1):
de noodzaak om een van de stappen in 2 delen te splitsen, het tweede deel begint alleen onder bepaalde voorwaarden te worden uitgevoerd;
aanstelling van een bepaalde functionaris om de notenboekhouding uit te voeren;
een techniek (witte kleur van de elementen), die aangeeft dat het element niet expliciet in de procesbeschrijving is vermeld.
Opgemerkt moet worden dat we al deze regels al hebben gebruikt bij het ontwikkelen van diagrammen.
Afsluitende opmerkingen
We hebben dus 5 fasen doorlopen en 3 soorten diagrammen gebouwd. Ik zal een kleine opmerking toevoegen over de organisatie van onze modellen in de modelleringsomgeving. Er zijn een groot aantal raamwerken die helpen bij het structureren van de modellen die we ontwikkelen, maar dit is niet het onderwerp van dit artikel, dus we zullen ons beperken tot de volgende eenvoudige set pakketten voor ordelijk onderhoud van ons project: Business Process, Functional Model, Artefacten, deelnemers en omgeving (Figuur 14).
Figuur 14. De opbouw van de projectpakketten
Zo hebben we consistente modellen ontwikkeld die de boekhouding van materiële activa beschrijven vanuit verschillende invalshoeken: een model van een geautomatiseerd bedrijfsproces, een functioneel model en een model van de interne organisatie van het systeem op conceptueel niveau.
Website "UML2.ru". Analisten Community Forum. Algemeen gedeelte. Voorbeelden. Voorbeelden van sprookjes in de vorm van UML-diagrammen. [Elektronische bron] Toegangsmodus: Internet: http://www.uml2.ru/forum/index.php?topic=486.0
Certificaat nr. 18249 over registratie en deponering van een product van het resultaat van intellectuele activiteit. Alfimov RV, Zolotukhina EB, Krasnikova SA Het manuscript van het leerhulpmiddel getiteld "Het onderwerpgebied modelleren met behulp van Enterprise Architect" // 2011.