"En dag i et egerns liv" eller fra modelleringsprocesser til design af et automatiseret system til regnskab for materialeaktiver "Belka-1.0" (del 2)
Resumé af forrige serie
В vi brugte et "eventyr"-domæne inspireret af eksempler på at studere UML-diagrammer baseret på eventyrplot (se f.eks. [1]). Forud for modelleringen blev vi enige om brugen af nogle elementer i aktivitetsdiagrammet og begyndte at danne en modelleringsaftale. Under hensyntagen til disse aftaler beskrev vi på 1. trin processen i form af Aktivitetsdiagrammer, og på 2. trin identificerede vi de procestrin, som automatisering er påkrævet (og mulig).
Lad mig minde dig om, at vi kommer til at automatisere aktiviteten med at tage højde for materielle værdier, som opstår i disse processer.
...
En ø i havet ligger, (E1, E2)
Hagl på øen står (E3, E1)
Med gyldne kuppelkirker, (E4)
Med tårne og haver; (E5, E6)
Gran vokser foran paladset, (E7, E8)
Og under det er et krystalhus; (E9)
Egernet bor der, tam, (A1)
Ja, hvilken entertainer! (A1)
Egern synger sange, (P1, A1)
Ja, han gnaver alle nødderne, (P2)
Og nødder er ikke simple, (C1)
Alle skaller er gyldne, (C2)
Kerner ren smaragd; (C3)
Tjenere vogter egernet, (P3, A2)
Tjen hende som tjenere af forskellig art (P4)
Og en ekspedient blev tildelt (A3)
Streng redegørelse for nødder nyheder; (P5, C1)
Giver hendes hær ære; (P6, A4)
En mønt hældes fra skallerne, (P7, C2, C4)
Lad dem flyde rundt i verden; (P8)
Piger kaster smaragd (P9, A5, C3)
I pantries, men under en skæppe; (E10, E11)
...
(A.S. Pushkin "Fortællingen om zar Saltan, om hans herlige og mægtige søn prins Gvidon Saltanovich og den smukke svaneprinsesse", )
I dette eksempel bruger jeg Enterprise Architect-miljøet fra en australsk virksomhed. [2], og inden for rammerne af træningssessioner jeg bruger [3].
Lad mig minde dig om, at processer er forskellige, du kan stifte bekendtskab med f.eks. [4] og [5].
Se [6, 7] for detaljer om de anvendte tilgange til modellering og design.
For den komplette UML-specifikation, se [8].
Vi er nu klar til at gå videre til de næste trin og begynde at designe systemets funktioner og dets interne organisation. Figurnummereringen fortsætter.
Trin 3. Det automatiserede trin skal tildeles en eller flere funktioner i systemet
Det automatiserede system (AS), der udvikles, er designet til at holde en streng registrering af nødder, husker du? For hvert fremhævet trin (se figur 3, figur 4 ), som vi vil automatisere, nedskrive funktionskravet ved at bruge sådan en konstruktion "Systemet skal kunne ..." og udvikle et Use-case diagram. Nu supplerer vi faktisk vores modelaftale med nye regler. Lad mig forklare, hvilke elementer vi vil bruge.
Mellem "Brugerrollen" og "Funktionen" vil vi bruge "Association"-relationen (Figur 5), hvilket betyder, at brugeren med denne rolle kan udføre denne funktion.
Figur 5. Brug af en associationstyperelation
Fra "Funktion" til "Krav", vil vi trække linket "Implementering" (Figur 6) for at vise, at dette krav vil blive implementeret af disse funktioner, forholdet kan være "mange-til-mange", dvs. én funktion kan være involveret i implementeringen af flere krav, og der kan være behov for mere end én funktion for at implementere kravet.
Figur 6. Brug af et implementeringsforhold
Hvis en funktion kræver, at en anden funktion udføres, og det er nødvendigt, vil vi bruge forbindelsen "Afhængighed" med stereotypen "Inkluder" - inklusion (Figur 7). Hvis udførelsen af en ekstra funktion er påkrævet under visse betingelser, vil vi bruge forbindelsen "Afhængighed" med stereotypen "Udvid" - en udvidelse. Alt er meget nemt at huske: "Inkluder" - ALTID og "Udvid" - NOGLE gange.
Figur 7. Brug af linktypen "Afhængighed (inkluder)"
Som et resultat vil vores diagram se nogenlunde sådan ud (Figur 8).
Figur 8. Use-case diagram (funktionel model af AS)
Derudover bruges Use-case diagrammet til at modellere brugerroller (figur 9).
Figur 9. Use-case diagram (AS-brugeres roller)
Trin 4. Lad os beskrive den interne organisation af AS ved hjælp af et klassediagram
Ved at bruge information om input og output artefakter af vores proces (se Aktivitetsdiagrammer - Figur 2, Figur 3, Figur 4), vil vi udvikle et klassediagram. Vi vil bruge "Klasse"-modelleringselementerne og forskellige typer relationer mellem dem.
For at vise "hel-del"-forholdet, vil vi bruge forholdet "Aggregation"-typen (Figur 10): nødden er helheden, og skallerne og kernen er delene.
Figur 10. Hel-Del Relation
Som et resultat vil et fragment af vores diagram se nogenlunde sådan ud (Figur 11). Klasser er markeret med farve, som vi har fremhævet direkte i tekstbeskrivelsen af forløbet.
Figur 11. Klassediagram
Klassediagrammet blev også brugt til at modellere andre artefakter - ikke kun dem, der vil være relevante for den konceptuelle model for den automatiserede inventarproces, men relateret til udførelsesmiljøet - miljøet (figur 12) og "nabo"-processer (figur 13). som kan påvirke den automatiserede proces, men som endnu ikke er i fokus for vores opmærksomhed (vi antager, at systemet vil udvikle sig, og denne information vil være nyttig).
Figur 12. Klassediagram (miljø)
Arveforholdet viser generaliseringen af forskellige bygninger, "barn"-klasser, under den generaliserende "forældre"-klasse "Bygning".
Figur 13. Klassediagram (mere information om artefakter)
"Reaktion på situationen" afhænger af "Visuelle kontroldata". For flere afhængighedsforhold bruges "trace"-stereotypen til at vise sporing af klasser, der ikke er eksplicit angivet i procesbeskrivelsen, men som er nødvendige for dens automatisering, til klasser, hvis instanser er præcist angivet i vores beskrivelse.
Trin 5. Lad os analysere noterne på sporet "Business Rules".
Som regler blev specificeret (se figur 2 ):
- behovet for at opdele et af trinene i 2 dele, den anden del begynder kun at blive udført under visse betingelser;
- udnævnelse af en bestemt embedsmand til at udføre regnskabsføring af nødder;
- en teknik (hvid farve på elementerne), som indikerer, at elementet ikke var eksplicit angivet i procesbeskrivelsen.
Det skal bemærkes, at vi allerede har brugt alle disse regler, når vi udvikler diagrammer.
Afsluttende bemærkninger
Så vi gik gennem 5 faser og byggede 3 typer diagrammer. Jeg vil tilføje en kommentar mere om organiseringen af vores modeller i modelleringsmiljøet. Der er et stort antal rammer, der hjælper med at strukturere de modeller, vi udvikler, men dette er ikke emnet for denne artikel, så vi vil begrænse os til følgende simple sæt pakker til ordnet vedligeholdelse af vores projekt: Forretningsproces, Funktionel model, Artefakter, deltagere og miljø (Figur 14).
Figur 14. Strukturen af projektpakkerne
Vi har således udviklet konsistente modeller, der beskriver systemet for regnskabsføring af materielle aktiver fra forskellige vinkler: en model for en automatiseret forretningsproces, en funktionel model og en model for den interne organisering af systemet på et konceptuelt niveau.
Liste over kilder
- Webstedet "UML2.ru". Analytikerfællesskabsforum. Generelt afsnit. Eksempler. Eksempler på eventyr i form af UML-diagrammer. [Elektronisk ressource] Adgangstilstand: Internet:
- Sparx Systems hjemmeside. [Elektronisk ressource] Adgangstilstand: Internet:
- Modelio hjemmeside. [Elektronisk ressource] Adgangstilstand: Internet:
- Stor encyklopædisk ordbog. Proces (fortolkning). [Elektronisk ressource] Adgangstilstand: Internet:
- Hjemmeside "Organisation af effektiv ledelse". Blog. Overskrift "Forretningsprocesstyring". Definition af forretningsproces. [Elektronisk ressource] Adgangstilstand: Internet:
- Certifikat nr. 18249 om registrering og deponering af et produkt af resultatet af intellektuel aktivitet. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Læremidlets manuskript med titlen "Modlere fagområdet ved hjælp af Enterprise Architect" // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modellering af forretningsprocesser. - M .: KURS, NITs INFRA-M, EBS Znanium.com. – 2017.
- OMG Unified Modeling Language (OMG UML) specifikation. Version 2.5.1. [Elektronisk ressource] Adgangstilstand: Internet:
Kilde: www.habr.com