«En dag i et egerns liv» eller fra modellering af processer til design af det automatiserede system til registrering af materielle værdier «Egern-1.0» (Del 1)
Hvad har «egern» med det at gøre?
Lad mig straks forklare, hvad «egern» har med det at gøre. Da jeg stødte på sjove projekter online til at lære UML baseret på emneområder fra eventyr (for eksempel, [1]), besluttede jeg også at forberede et lignende eksempel til mine studerende, så de kunne lære om tre typer diagrammer: Aktivitätsdiagram, Use-case-diagram og Klassediagram. Jeg oversætter bevidst ikke navnene på diagrammerne til russisk for at undgå debat om „oversættelsesvanskelighederne“. Hvad de hver især er til, forklarer jeg lidt senere. I dette eksempel bruger jeg Enterprise Architect fra det australske firma [2] – et godt værktøj til rimelige penge. Og i undervisningssammenhænge bruger jeg [3], et udmærket gratis værktøj til objektorienteret design, der understøtter UML2.0 og BPMN standarder, uden unødvendige features i grafiske muligheder, men helt tilstrækkeligt til at lære grundlæggende sprog.
Vi har til hensigt at automatisere registreringen af materielle værdier, som 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 helt, prins Gvidon Saltanovich, og om den smukke prinsesse Svanen", — 10 år fra idé til offentliggørelse, for resten!)
Lidt om koderne, der er skrevet til højre for linjerne. “A” (fra “Actor”) betyder, at linjen indeholder oplysninger om deltageren i processen. “C” (fra “Class”) – oplysninger om klasseobjekter, der behandles under udførelsen af processerne. “E” (fra “Environment”) – oplysninger om klasseobjekter, der karakteriserer miljøet for processernes udførelse. “P” (fra “Process”) – oplysninger om selve processerne.
Forresten anses den præcise definition af processen også for at kunne fremkalde metodologiske diskussioner, ikke mindst fordi der findes forskellige typer processer: forretnings-, produktions-, teknologiske osv. (man kan lære mere om det, for eksempel, [4] og [5]). For at undgå polemik lad os blive enige om, at processen er interessant for os med hensyn til dens gentagelighed over tid og behovet for automatisering, dvs. overføre udførelsen af en del af operationerne i processen til et automatiseret system.
Notater om anvendelse af aktivitetsdiagrammet
Lad os begynde at modellere vores proces og bruge aktivitetsdiagrammet til dette. Først vil jeg forklare, hvordan de nævnte koder vil blive brugt i modellen. Det er lettere at forklare med et grafisk eksempel, og lad os samtidig gennemgå nogle (næsten alle de nødvendige for os) elementer i aktivitetsdiagrammet.
Lad os analysere følgende fragment:
…
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)
…
Vi har to trin i processen P1 og P2, deltager A1, og objekterne fra tre forskellige klasser: objektet fra klasse C1 kommer ind i trinnet, objekterne fra klasserne C2 og C3 opnås som resultatet af aktiviteten i dette trin P2 i vores proces. Til diagrammet vil vi bruge følgende modelleringselementer.
Framgmentet af vores proces kan repræsenteres således (Figur 1).
Figur 1. Fragment af aktivitetsdiagrammet
For at organisere pladsen og strukturere aktivitetsdiagrammet vil vi anvende en lidt ikke-standard tilgang i forhold til den klassiske brug af UML-notation. Men der er nogle grunde til dette. For det første vil vi blot før begyndelsen af modelleringen lave en såkaldt modelleringsaftale, som vil opsummere alle aspekter af brugen af notationen. For det andet er denne tilgang gentagne gange blevet anvendt med succes i faserne af forretningsmodellering i reale projekter til udvikling af softwaresystemer, og resultaterne er blevet dokumenteret af vores lille forfattergruppe i det tilsvarende ophavsretlige objekt [6], samt anvendt i undervisningsmaterialet [7]. For aktivitetsdiagrammet vil vi definere, at diagramfeltet struktureres med 'svømmende' baner – Swim lanes. Navnet på banen vil svare til typen af elementer i diagrammet, der vil blive placeret på denne bane.
«Ind- og udgangs artefakter»: på denne bane vil elementer Objects – objekter, der bruges eller er resultatet af udførelsen af et bestemt trin i processen, blive placeret.
«Processens trin»: her vil vi placere elementer Activity – handlinger fra deltagerne i processen.
«Deltagere»: en bane for elementer, der vil betegne rollerne for aktørerne i vores proces; for dem vil vi stadig anvende den samme modellerende element Object – objekt, men tilføje stereotypt 'Actor'.
Den næste bane kaldes «Forretningsregler» og på denne bane vil vi i tekstform placere reglerne for udførelsen af procestrinene, og vi vil anvende det modellerende element Note – annotation til dette formål.
Vi stopper her, selvom vi eventuelt kunne have anvendt en bane «Værktøjer» til at indsamle oplysninger om niveauet af procesautomatisering. En bane «Stilling og afdelinger for deltagerne», kan også bruges til at forbinde roller med stillinger og afdelinger af procesdeltagerne.
Alt det, jeg lige har beskrevet, er et uddrag af aftalen om modellering, denne del af aftalen omhandler reglerne for organiseringen af et diagram og dermed reglerne for dets udarbejdelse og læsning.
«Opskrift»
Nu vil vi se på en model for systemet, der er fra aktivitetsdiagrammet. Dette er kun én af mulighederne, jeg vil bemærke, at den selvfølgelig ikke er den eneste. Aktivitetsdiagrammet vil interessere os i forhold til dets rolle i overgangen fra procesmodellering til design af det automatiserede system. For dette vil vi følge de metodiske anbefalinger – en slags opskrift, der består af fem trin og indebærer udvikling af tre typer diagrammer. Anvendelse af denne opskrift vil hjælpe med at opnå en formaliseret beskrivelse af den proces, vi ønsker at automatisere, og indsamle data til systemdesign. Og for studerende, der starter med UML, er dette en slags redningskrans, der forhindrer dem i at drukne i al den mangfoldighed af grafiske midler og teknikker, der findes i UML og moderne modelleringsværktøjer.
Her er selve opskriften, og derefter følger de diagrammer, der er bygget til vores 'eventyrlige' emneområde.
Trin 1. Beskriv processen i form af et aktivitetsdiagram. For en proces, hvor der er identificeret mere end 10 trin, giver det mening at anvende princippet om dekomponering af procestrin for at forbedre læsbarheden af diagrammet.
Trin 2. Udpeg det, der kan automatiseres (trin kan f.eks. fremhæves på diagrammet).
Trin 3. Den automatiserbare trin skal sættes i overensstemmelse med systemets funktion eller funktioner (forholdet kan være mange-til-mange), tegner vi et use-case diagram. Det er funktionerne i vores system.
Trin 4. Beskriv den interne organisation af AS ved hjælp af klasse-diagrammet – Class. De svømmediagrammer 'Indgangs- og udgangsobjekter (dokumenter)' i aktivitetsdiagrammet er grundlaget for opbygning af den objektmodel og entitet-forbindelsesmodel.
Trin 5. Analyser noterne på banen 'Forretningsregler', de giver forskellige former for begrænsninger og betingelser, der gradvist transformeres til ikke-funktionelle krav.
Det opnåede sæt af diagrammer (Aktivitet, Use-case, Klasse) giver os en formaliseret beskrivelse i en ganske streng notation, dvs. har en entydig læsning. Nu kan vi begynde at udvikle en teknisk opgave, præcisere kravspecifikation osv.
Lad os begynde at modelere.
Trin 1. Beskriv processen i form af et aktivitetsdiagram.
Jeg minder om, at vi har struktureret diagrammet med "svømmeanlæg", hvor hver bane indeholder elementer af én type (Figur 2). Foruden de førnævnte elementer i diagrammet vil vi anvende yderligere elementer; lad os beskrive dem.
Løsning (Decision) angiver på diagrammet et forgreningspunkt for vores proces, mens sammensmeltning af strømme (Merge) er punktet for deres sammenføring. Betingelserne for overgange er skrevet i firkantede parenteser.
Mellem to synkroniseringspunkter (Fork) viser vi parallelle grene af processen.
Vores proces kan kun have én start – et indgangspunkt (Initial). Men der kan være flere afslutninger (Final), men ikke for vores specifikke diagram.
Der bliver ret mange pile; når der er mange elementer og forbindelser, kan man først identificere processens faser og derefter udføre en nedbrydning af disse faser. Men jeg vil gerne vise vores "eventyragtige" proces i sin helhed på ét diagram, mens vi selvfølgelig skal strive efter at sørge for, at pilene "ikke klistres sammen", så det nøjagtigt kan Følges, hvad der er relateret til hvad.
Figur 2. Aktivitet Diagram – generelt billede af processen.
Da nogle detaljer i de poetiske linjer er blevet udeladt, måtte vi genskabe dem; de er vist med elementer med hvid baggrund. Disse detaljer inkluderer skridtet "Overførsel/modtagelse til opbevaring og behandling" og flere ind- og udgående artefakter. Det skal bemærkes, at dette skridt heller ikke fuldt ud afspejler processen, da vi skulle angive skridtene for overførsel og modtagelse separat, og for skaller skulle der desuden tilføjes et særskilt skridt, og vi skulle også forestille os, at alle disse materielle værdier først skal opbevares et sted midlertidigt osv.
Lad os også bemærke, at spørgsmålet om oprindelsen af nødderne stadig er ubesvaret – hvor kommer de fra, og hvordan kommer de til egernet? Og dette spørgsmål (det er fremhævet med rød skrift i notatet – element Note) kræver en særlig behandling! Sådan arbejder analytikeren – samler information stykke for stykke, laver antagelser og får "ok" eller "ikke-ok" fra eksperter inden for området – meget vigtige og uundgåelige mennesker i forretningsmodelleringens fase ved skabelsen af systemer.
Vi skal også bemærke, at processen P5 er opdelt i to dele.
Og hver del nedbryder vi og ser nærmere på (Figur 3, Figur 4), da aktiviteterne udført i disse trin vil blive automatiseret.
Figur 3. Activity diagram - detaljeret (del 1)
Figur 4. Activity diagram - detaljeret (del 2)
Trin 2. Udpeg det, der kan automatiseres
Trinene, der skal automatiseres i diagrammerne, er fremhævet med farve (se Figur 3, Figur 4).
Alle opgaver udføres af én deltager i processen – Deacon Bydog:
- Indtaster information om vægten af nødder i registre;
- Indtaster information om overdragelse af nødder i registre;
- Registrerer faktum af nøddernes omdannelse til skaller og kerner;
- Indtaster information om kernen af nødderne i registre;
- Indtaster information om nøddernes skaller i registre.
Analyse af det udførte arbejde. Hvad er næste skridt?
Så vi har udført et stort forberedelsesarbejde: indsamlet information om den proces, vi ønsker at automatisere; begyndt at formulere en aftale om modellering (indtil videre kun for brugen af activity diagram); udført procesmodellering og endda nedbrudt nogle af dens trin; fremhævet procestrin, som vi vil automatisere. Nu er vi klar til at gå videre til de næste faser og begynde at designe systemfunktioner og dens interne organisation.
Som bekendt er teori uden praksis ingenting. Det er vigtigt at prøve "modellering" med egne hænder; det er nyttigt for at forstå den foreslåede tilgang. For eksempel kan man arbejde i et modelleringsmiljø [3]. Vi har kun nedbrudt en del af trinene i diagrammet for den overordnede proces (se Figur 2). Som en praktisk opgave kan man blive bedt om at gentage alle diagrammerne i Modelio-miljøet og udføre nedbrydningen af trin "Overdragelse/modtagelse til opbevaring og forarbejdning".
Vi betragter endnu ikke arbejdet i specifikke modelleringsmiljøer, men det kan blive emnet for selvstændige artikler og anmeldelser.
I den anden del af artiklen vil vi gennemgå modellerings- og designteknikker, der er nødvendige i faserne 3-5, og vi vil bruge UML-use case og class-diagrammer. Fortsættelse følger.
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.
Kilde: habr.com
