"En dag i et egerns liv" eller fra modelleringsprocesser til design af et automatiseret system til regnskab for materialeaktiver "Belka-1.0" (del 1)
Hvad har "egern" med det at gøre?
Jeg vil straks forklare, hvad "egernet" har med det at gøre. Efter at have stødt på sjove projekter på internettet til at lære UML baseret på et fagområde lånt fra eventyr (f.eks. [1]), besluttede jeg også at forberede et lignende eksempel til mine elever, så de kun kunne studere tre typer diagrammer til at begynde med: Aktivitetsdiagram, Use-case Diagram og Klassediagram. Jeg oversætter bevidst ikke navnene på diagrammerne til russisk for at undgå uenigheder om "oversættelsesvanskeligheder". Jeg forklarer, hvad det er til lidt senere. I dette eksempel bruger jeg Enterprise Architect-rammen fra en australsk virksomhed [2] – et godt værktøj til en rimelig pris. Og som en del af mine træningssessioner bruger jeg [3], et godt gratis objektorienteret designværktøj, der understøtter UML2.0- og BPMN-standarder, uden unødvendige klokker og fløjter med hensyn til visuelle muligheder, men ganske tilstrækkeligt til at lære det grundlæggende i sproget.
Vi vil automatisere aktiviteten til regnskabsføring af materielle aktiver, 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 helt Prins Guidon Saltanovich og den smukke Prinsesse Svane", — 10 år fra idé til udgivelse i øvrigt!)
Lidt om de koder, der er skrevet til højre for linjerne. "A" (fra "Actor") betyder, at linjen indeholder information om en deltager i processen. "C" (fra "Klasse") - information om klasseobjekter, der behandles under udførelsen af processer. "E" (fra "Environment") - information om klasseobjekter, der karakteriserer miljøet til udførelse af processer. "P" (fra "Process") - information om selve processerne.
I øvrigt hævder den nøjagtige definition af en proces også at være årsagen til metodologiske tvister, om end på grund af det faktum, at der er forskellige processer: forretning, produktion, teknologisk osv. og så videre. (du kan f.eks. finde ud af [4] og [5]). For at undgå kontroverser, lad os blive enige om det Vi er interesserede i processen ud fra dens gentagelighed over tid og behovet for automatisering, dvs. overførsel af udførelsen af enhver del af procesoperationerne til et automatiseret system.
Bemærkninger om brug af aktivitetsdiagrammet
Lad os begynde at modellere vores proces og bruge aktivitetsdiagrammet til dette. Lad mig først forklare, hvordan ovenstående koder vil blive brugt i modellen. Det er nemmere at forklare med et grafisk eksempel, men samtidig analyserer vi nogle (næsten alle dem, vi har brug for) elementer i aktivitetsdiagrammet.
Lad os analysere følgende fragment:
...
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)
...
Vi har to procestrin P1 og P2, deltager A1 og objekter af tre forskellige klasser: et objekt i klasse C1 er input til trinnet, objekter i klasse C2 og C3 er output som et resultat af aktiviteten i dette trin P2 i vores behandle. Til diagrammet bruger vi følgende modelleringselementer.
Et fragment af vores proces kan repræsenteres noget som dette (figur 1).
Figur 1. Fragment af aktivitetsdiagram
For at organisere rummet og strukturere aktivitetsdiagrammet, vil vi bruge en ikke-standard tilgang ud fra den klassiske brug af UML-notation. Men det er der flere grunde til. For det første vil vi lige før start af modelleringen kompilere den såkaldte modelaftale, hvor vi registrerer alle funktionerne ved at bruge notationen. For det andet blev denne tilgang gentagne gange med succes anvendt på stadiet af forretningsmodellering i rigtige projekter for at skabe softwaresystemer. Resultaterne blev registreret af vores lille team af forfattere i det tilsvarende copyright-objekt [6], og blev også brugt i en træningsmanual [; 7]. For aktivitetsdiagrammet definerer vi, at diagramfeltet er struktureret ved hjælp af "svømmebaner". Spornavnet vil svare til den type diagramelementer, der vil blive placeret på det spor.
"Input og output artefakter": Dette spor vil indeholde objektelementer - objekter, der bruges eller er resultatet af at udføre et procestrin.
"Procestrin": Her vil vi placere aktivitetselementer - procesdeltagernes handlinger.
"Deltagere": en sti til elementer, der vil udpege handlingsudøvernes roller i vores proces, for dem vil vi bruge det samme modelleringselement Objekt - et objekt, men vi tilføjer "Actor"-stereotypen.
Det næste nummer kaldes "Forretningsregler" og på dette spor vil vi i tekstform placere reglerne for udførelse af processens trin, og til dette vil vi bruge modelleringselementet Note - en note.
Vi stopper her, selvom vi også kunne bruge stien "Værktøjer" at indsamle oplysninger om niveauet af procesautomatisering. En sti kan også være nyttig "Positioner og opdelinger af deltagere", kan den bruges til at knytte roller til stillinger og afdelinger af procesdeltagere.
Alt, hvad jeg lige har beskrevet, er et fragment modelleringskonventioner, denne del af aftalen vedrører reglerne for organisering af ét diagram og dermed reglerne for skrivning og læsning af det.
"Opskrift"
Lad os nu overveje muligheden for at modellere systemet specifikt fra aktivitetsdiagrammet. Dette er blot en af mulighederne, jeg bemærker, at det selvfølgelig ikke er den eneste. Aktivitetsdiagrammet vil interessere os ud fra dets rolle i overgangen fra procesmodellering til design af et automatiseret system. For at gøre dette vil vi overholde de metodiske anbefalinger - en slags opskrift, der kun består af fem trin og sørger for udvikling af kun tre typer diagrammer. Brug af denne opskrift vil hjælpe os med at få en formaliseret beskrivelse af den proces, vi ønsker at automatisere og indsamle data til systemdesign. Og for studerende i begyndelsen af at studere UML er dette en slags livredder, der ikke vil tillade dem at drukne i alle de forskellige visuelle midler og teknikker, der findes i UML og moderne modelleringsværktøjer.
Her er faktisk selve opskriften, og følg så diagrammerne bygget til vores "eventyr"-fagområde.
Trin 1. Vi beskriver processen i form af et aktivitetsdiagram. For en proces med mere end 10 trin giver det mening at anvende procestrinnedbrydningsprincippet for at forbedre diagrammets læsbarhed.
Trin 2. Vælg, hvad der kan automatiseres (trinene kan f.eks. fremhæves på et diagram).
Trin 3. Det automatiserede trin skal tildeles en eller flere funktioner i systemet (forholdet kan være mange-til-mange), tegn et Use-case diagram. Disse er funktionerne i vores system.
Trin 4. Lad os beskrive den interne organisation af AS ved hjælp af et klassediagram - Klasse. Svømmebanen "Input- og outputobjekter (Documents)" i aktivitetsdiagrammet er grundlaget for opbygning af en objektmodel og en enhedsrelationsmodel.
Trin 5. Lad os analysere noterne på sporet "Business Rules"., giver de forskellige former for restriktioner og betingelser, som gradvist omdannes til ikke-funktionelle krav.
Det resulterende sæt af diagrammer (Activity, Use-case, Class) giver os en formaliseret beskrivelse i en ret stram notation, dvs. har en utvetydig læsning. Nu kan du udvikle tekniske specifikationer, afklare kravspecifikationer mv.
Lad os begynde at modellere.
Trin 1. Beskriv processen i form af et aktivitetsdiagram
Lad mig minde dig om, at vi strukturerede diagramfeltet ved at bruge "svømmebaner" hver bane indeholder elementer af samme type (figur 2). Ud over diagramelementerne beskrevet ovenfor, vil vi bruge yderligere elementer, lad os beskrive dem.
Decision (Beslutning) angiver forgreningspunktet for vores proces i diagrammet, og flettetråde (Merge) - punktet for deres genforening. Overgangsbetingelser er skrevet i firkantede parenteser på overgange.
Mellem to synkronisatorer (Fork) vil vi vise parallelle procesgrene.
Vores proces kan kun have én begyndelse - ét indgangspunkt (Initial). Men der kan være flere afslutninger (endelig), men ikke for vores specifikke diagram.
Der er ret mange pile med et stort antal elementer og forbindelser, du kan først identificere stadierne i processen og derefter udføre en nedbrydning af disse stadier. Men for klarhedens skyld vil jeg gerne vise vores "eventyr"-proces helt på ét diagram, mens vi selvfølgelig skal sikre, at pilene "ikke klæber sammen", det ville være muligt nøjagtigt at spore, hvad der er forbundet til hvad.
Figur 2. Aktivitetsdiagram - en generel oversigt over processen
Fordi i de poetiske linjer er nogle detaljer i processen udeladt, de skulle restaureres, de er vist af elementer med hvid baggrund. Disse detaljer inkluderer overførsel/modtagelse til lagring og behandling og adskillige input- og outputartefakter. Det er værd at bemærke, at dette trin heller ikke fuldt ud afslører processen, fordi vi skulle separat udpege transmissionstrinnet og modtagetrinnet og endda tilføje et separat trin for skaller og også tro, at alle disse materielle værdier først skal gemmes midlertidigt et sted osv. og så videre.
Lad os også bemærke, at spørgsmålet om nøddernes oprindelse forbliver 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 noten - Note-elementet) kræver separat undersøgelse! Det er sådan en analytiker arbejder - indsamler informationer bit for bid, gør antagelser og modtager "okay" eller "no-okay" fra emneeksperter - meget vigtige og simpelthen uerstattelige mennesker på stadiet af forretningsmodellering, når de opretter systemer.
Bemærk også, at procestrin P5 består af to dele.
Og vi vil dekomponere hver del og overveje det mere detaljeret (Figur 3, Figur 4), fordi de aktiviteter, der udføres inden for disse særlige trin, vil blive automatiseret.
Figur 3. Aktivitetsdiagram - detaljering (del 1)
Figur 4. Aktivitetsdiagram - detaljering (del 2)
Trin 2. Vælg, hvad der kan automatiseres
De trin, der skal automatiseres, er fremhævet i farver på diagrammerne (se figur 3, figur 4).
Alle udføres af én deltager i processen - ekspedienten:
- Indsætter oplysninger om møtrikkens vægt i erklæringen;
- Indlæser oplysninger om overførslen af møtrikken i erklæringen;
- Registrerer kendsgerningen om forvandlingen af en nød til en skal og en kerne;
- Indsætter oplysninger om nøddekernen i erklæringen;
- Indsætter oplysninger om nøddeskaller på listen.
Analyse af det udførte arbejde. Hvad er det næste?
Så vi har lavet en masse forberedende arbejde: vi har indsamlet information om den proces, som vi skal automatisere; begyndte at danne en aftale om modellering (indtil videre kun med hensyn til at bruge aktivitetsdiagrammet); udførte en simulering af processen og endda dekomponerede flere af dens trin; Vi har identificeret de procestrin, som vi vil automatisere. Vi er nu klar til at gå videre til de næste trin og begynde at designe systemets funktionalitet og interne organisation.
Som du ved, er teori uden praksis ingenting. Du bør bestemt prøve at "modellere" med dine egne hænder, dette er også nyttigt for at forstå den foreslåede tilgang. Du kan for eksempel arbejde i et modelmiljø [3]. Vi har kun dekomponeret en del af trinene i det overordnede procesdiagram (se figur 2). Som en praktisk opgave kan du blive bedt om at gentage alle diagrammerne i Modelio-miljøet og udføre en dekomponering af trinnet "Overførsel/modtagelse til opbevaring og behandling".
Vi overvejer endnu ikke at arbejde i specifikke modelleringsmiljøer, men dette kan blive genstand for uafhængige artikler og anmeldelser.
I den anden del af artiklen vil vi analysere de nødvendige modellerings- og designteknikker på trin 3-5, vi vil bruge UML Use-case og klassediagrammer. Fortsættes.
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.
Kilde: www.habr.com