«En dag i et egerns liv» eller fra modellering af processer til design af det automatiserede materialeateringssystem «Egernet-1.0» (Del 2)
Kort resume af den forrige episode
I Vi har brugt et «eventyrligt» emnefelt, inspireret af eksempler fra studiet af UML-diagrammer med fokus på plots fra eventyr (se for eksempel, [1]). Inden vi begyndte modelleringen, blev vi enige om at bruge nogle elementer fra Aktivitet-diagrammet og begyndte at udarbejde en aftale om modellering. Med henblik på disse aftaler beskrev vi i første fase processen i form af Aktivitet-diagrammer, mens vi i anden fase identificerede de procestrin, der kræver (og er mulige at) automatisere.
Lad mig minde om, at vi har til hensigt at automatisere aktiviteterne omkring materialebeholdning, der opstår i disse processer.
…
En ø ligger i havet, (E1, E2)
En by står på øen (E3, E1)
Med gyldne kupler, (E4)
Med små huse og haver; (E5, E6)
En gran træder før paladset, (E7, E8)
Og under den et krystaldhus; (E9)
Egernet bor der som et kæledyr, (A1)
Og hvilken lille nar! (A1)
Egernet synger sange, (P1, A1)
Og gnager på nødder, (P2)
Og nødderne er ikke almindelige, (C1)
Alt er gyldne skaller, (C2)
Kernen er ren smaragd; (C3)
Tjenerne vogter egernet, (P3, A2)
De tjener hende med varierende service (P4)
Og en stram klerk er sat (A3)
Strengt opgøres nødderne; (P5, C1)
Aldeles ærer hende; (P6, A4)
Af skallerne støber de mønter, (P7, C2, C4)
Og sender dem ud i verden; (P8)
Pigerne strør smaragd (P9, A5, C3)
I kasserne, og gemmer det; (E10, E11)
…
(A.S. Pushkin «Eventyret om tsar Saltan, om hans berømte og mægtige søn, den ædle ridder prins Gvidon Saltanovich, og om den smukke prinsesse Svane», )
I dette eksempel bruger jeg miljøet Enterprise Architect fra det australske firma [2], og i forbindelse med undervisningen anvender jeg [3].
Lad mig minde om, at der findes forskellige typer processer, man kan gøre sig bekendt med, for eksempel [4] og [5].
For mere information om de anvendte tilgange til modellering og design se [6, 7].
Den fulde specifikation af UML, se. [8].
Nu er vi klar til at gå videre til de næste faser og begynde designet af systemets funktioner og dens interne organisation. Numre på illustrationerne vil blive fortsat.
Trin 3. Den automatiserbare trin skal sættes i overensstemmelse med systemets funktion eller funktioner
Det automatiserede system (AS), der udvikles, er beregnet til at føre nøje regnskab over nødder, husk det? For hvert trin der skal automatiseres (se Figur 3, Figur 4 ), vil vi nedskrive funktionskrav ved hjælp af omtrent denne formulering «Systemet skal have muligheden for ...» og udvikle et Use-case-diagram. Lige nu supplerer vi faktiske vores modelleraftale med nye regler. Jeg vil forklare, hvilke elementer vi vil bruge.
Mellem "Brugers rolle" og "Funktion" vil vi bruge forbindelsen "Association" (Figur 5), hvilket betyder, at brugeren med denne rolle har mulighed for at udføre denne funktion.
Figur 5. Brug af forbindelsen "Association"
Fra "Funktion" til "Krav" trækker vi forbindelsen "Realization" (Figur 6) for at vise, at dette krav vil blive opfyldt af disse funktioner, forholdet kan være "mange-til-mange", det vil sige, at en funktion kan være involveret i opfyldelsen af flere krav, og flere funktioner kan være nødvendige for at opfylde et krav.
Figur 6. Brug af forbindelsen "Realization"
Hvis en funktion kræver, at en anden funktion udføres for at kunne fungere, og dette er et krav, vil vi bruge forbindelsen "Dependency" med stereotype "Include" — inkludering (Figur 7). Hvis udførelsen af den yderligere funktion kræves under bestemte forhold, vil vi bruge forbindelsen "Dependency" med stereotype "Extend" — udvidelse. Det er let at huske: "Include" — ALDRIG, og "Extend" – NOGEN GANGE.
Figur 7. Brug af forbindelsen "Dependency (inkludering)"
I sidste ende vil vores diagram se sådan ud (Figur 8).
Figur 8. Use-case diagram (funktionel model af AС)
Desuden bruges Use-case diagrammet til at modellere brugerroller (Figur 9).
Figur 9. Use-case diagram (brugerroller i AС)
Trin 4. Beskriv den interne organisation af AS ved hjælp af klasse-diagrammet
Ved at bruge oplysninger om ind- og udgående artefakter fra vores proces (se aktivitetsdiagrammer — Figur 2, Figur 3, Figur 4), vil vi udvikle et klassediagram. Vi vil bruge modellerende elementer "Klasse" og forskellige typer forbindelser imellem dem.
For at vise forholdet "helhed-del" vil vi bruge forbindelsen "Aggregation" (Figur 10): nød er helheden, mens skaller og kerne er delene.
Figur 10. Forholdet "helhed-del"
I sidste ende vil fragmentet af vores diagram se sådan ud (Figur 11). Farven markerer de klasser, vi har fremhævet direkte i den tekstlige beskrivelse af processen.
Figur 11. Klassediagram
Klassediagrammet blev også brugt til at modellere andre artefakter - ikke kun dem, der relaterer sig til den konceptuelle model for automatisering af materialeværdikontrol, men også dem, der relaterer sig til eksekveringsmiljøet - omgivelserne (Figur 12) og "naboprocesserne" (Figur 13), som kan påvirke den automatiserede proces, men som ikke er i fokus for vores opmærksomhed lige nu (vi antager, at systemet vil udvikle sig, og at disse oplysninger senere vil være nyttige).
Figur 12. Klassediagram (miljø)
Arv-forbindelsen viser generaliseringen af forskellige bygninger, "børne"-klasser under den generaliserende "forælder"-klasse "Bygning".
Figur 13. Klassediagram (yderligere information om artefakter)
"Reaktion på situationen" afhænger af "Visuel kontrol data". For flere afhængighedsforhold bruges stereotyperne "trace" til at vise sporing af klasser, der ikke tydeligt er angivet i procesbeskrivelsen, men som er nødvendige for automatiseringen, til de klasser, der er præcist angivet i vores beskrivelse.
Trin 5. Analyser noterne på banen 'Forretningsregler'
Reglerne angiver, at (se Figur 2 ):
- behovet for at opdele et af trinene i 2 dele, hvor den anden del kun begynder, når visse betingelser er opfyldt;
- tildelingen til at udføre kontrol af nødder til en specifik stilling;
- den tekniske indikation (hvide elementer), der angiver, at elementet ikke eksplicit blev angivet i procesbeskrivelsen.
Det skal bemærkes, at vi allerede har anvendt alle disse regler under udviklingen af diagrammerne.
Afsluttende bemærkninger
Så vi har gennemgået 5 trin og bygget 3 typer diagrammer. Jeg vil også tilføje en lille kommentar om organiseringen af vores modeller i modelmiljøet. Der findes mange rammer, der hjælper med at strukturere de udviklede modeller, men det er ikke emnet for denne artikel, så vi vil begrænse os til det følgende enkle sæt pakker til ordnet håndtering af vores projekt: Forretningsproces, Funktionel model, Artefakter, Deltagere og Miljø (Figur 14).
Figur 14. Struktur af projektpakker
Dermed har vi udviklet koordinerede modeller, der beskriver systemet til registrering af materielle værdier fra forskellige vinkler: modellen for den automatiserede forretningsproces, den funktionelle model og modellen for den interne organisering af systemet på et konceptuelt niveau.
Liste over kilder
- Webstedet "UML2.ru". Forum for analytikerfællesskabet. Generelt afsnit. Eksempler. Eksempler på eventyr præsenteret som UML-diagrammer. [Elektronisk ressource] Adgangsmetode: Internet:
- Siden Sparx Systems. [Elektronisk ressource] Adgangsmodus: Internet:
- Webstedet Modelio. [Elektronisk ressource] Adgangsmetode: Internet:
- Den Store Encyclopædiske Ordbog. Proces (fortolkning). [Elektronisk ressource] Adgangsmetode: Internet:
- Webstedet "Organisation for effektiv ledelse". Blog. Kategori "Ledelse af forretningsprocesser". Definition af forretningsproces. [Elektronisk ressource] Adgangsmetode: Internet:
- Bevis Nr. 18249 for registrering og deponering af et resultat af intellektuel aktivitet. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manuskript til læremiddel med titlen "Modellering af domæneområdet ved brug af Enterprise Architect" // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modellering af forretningsprocesser. — M.: KURS, NIC INFRA-M, EBS Znanium.com. — 2017.
- OMG Unified Modeling Language (OMG UML) Specification. Version 2.5.1. [Elektronisk ressource] Adgangsmodus: Internet:
Kilde: habr.com
