"En dag i et ekorns liv" eller fra modelleringsprosesser til å designe et automatisert system for regnskapsføring av materielle eiendeler "Belka-1.0" (del 1)
Hva har "ekorn" med det å gjøre?
Jeg skal umiddelbart forklare hva "ekornet" har med det å gjøre. Etter å ha kommet over morsomme prosjekter på Internett for å lære UML basert på et fagområde lånt fra eventyr (f.eks. [1]), bestemte jeg meg også for å forberede et lignende eksempel for elevene mine slik at de bare kunne studere tre typer diagrammer til å begynne med: Aktivitetsdiagram, bruksdiagram og klassediagram. Jeg oversetter med vilje ikke navnene på diagrammene til russisk for å unngå tvister om «oversettelsesvansker». Jeg skal forklare hva det er for litt senere. I dette eksemplet bruker jeg Enterprise Architect-rammeverket fra et australsk selskap [2] – et godt verktøy til en fornuftig pris. Og som en del av treningsøktene mine bruker jeg [3], et godt gratis objektorientert designverktøy som støtter UML2.0- og BPMN-standarder, uten unødvendige bjeller og plystre når det gjelder visuelle muligheter, men ganske tilstrekkelig for å lære det grunnleggende i språket.
Vi skal automatisere aktiviteten til regnskapsføring av materielle eiendeler, som oppstår i disse prosessene.
...
En øy i havet ligger, (E1, E2)
Hagl på øya står (E3, E1)
Med kirker med gullkuppel, (E4)
Med tårn og hager; (E5, E6)
Gran vokser foran palasset, (E7, E8)
Og under det er et krystallhus; (E9)
Ekornet bor der, tam, (A1)
Ja, for en underholder! (A1)
Ekorn synger sanger, (P1, A1)
Ja, han gnager alle nøttene, (P2)
Og nøtter er ikke enkle, (C1)
Alle skjell er gylne, (C2)
Kjerner ren smaragd; (C3)
Tjenere vokter ekornet, (P3, A2)
Tjen henne som tjenere av ulike slag (P4)
Og en kontorist ble tildelt (A3)
Strenge redegjørelse for nøttenyheter; (P5, C1)
Gir hennes hær ære; (P6, A4)
En mynt helles fra skjellene, (P7, C2, C4)
La dem flyte rundt i verden; (P8)
Jenter kaster smaragd (P9, A5, C3)
I pantries, men under en skjeppe; (E10, E11)
...
(A.S. Pushkin "Fortellingen om tsar Saltan, om hans strålende og mektige helt prins Guidon Saltanovich og den vakre prinsesse Svanen", — 10 år fra konsept til publisering, forresten!)
Litt om kodene som er skrevet til høyre for linjene. «A» (fra «Actor») betyr at linjen inneholder informasjon om en deltaker i prosessen. "C" (fra "Klasse") - informasjon om klasseobjekter som behandles under utførelse av prosesser. “E” (fra “Environment”) – informasjon om klasseobjekter som karakteriserer miljøet for å utføre prosesser. “P” (fra “Prosess”) – informasjon om selve prosessene.
Forresten, den nøyaktige definisjonen av en prosess hevder også å være årsaken til metodologiske tvister, om ikke annet på grunn av det faktum at det er forskjellige prosesser: virksomhet, produksjon, teknologisk, etc. og så videre. (du kan f.eks. finne ut [4] og [5]). For å unngå kontroverser, la oss bli enige om det Vi er interessert i prosessen ut fra dens repeterbarhet over tid og behovet for automatisering, dvs. overføre utførelsen av noen del av prosessoperasjonene til et automatisert system.
Merknader om bruk av aktivitetsdiagrammet
La oss begynne å modellere prosessen vår og bruke aktivitetsdiagrammet for dette. Først, la meg forklare hvordan kodene ovenfor vil bli brukt i modellen. Det er lettere å forklare med et grafisk eksempel, men samtidig vil vi analysere noen (nesten alle de vi trenger) elementer i aktivitetsdiagrammet.
La oss analysere følgende fragment:
...
Ekorn synger sanger, (P1, A1)
Ja, han gnager alle nøttene, (P2)
Og nøtter er ikke enkle, (C1)
Alle skjell er gylne, (C2)
Kjerner ren smaragd; (C3)
...
Vi har to prosesstrinn P1 og P2, deltaker A1, og objekter av tre forskjellige klasser: et objekt av klasse C1 er input til trinnet, objekter i klasse C2 og C3 er utdata som et resultat av aktiviteten til dette trinnet P2 i vår prosess. For diagrammet bruker vi følgende modelleringselementer.
Et fragment av prosessen vår kan representeres noe slikt (figur 1).
Figur 1. Fragment av aktivitetsdiagram
For å organisere plassen og strukturere aktivitetsdiagrammet, vil vi bruke en ikke-standard tilnærming, sett fra den klassiske bruken av UML-notasjon. Men det er flere grunner til dette. For det første, rett før vi starter modelleringen vil vi kompilere den såkalte modellavtale, der vi registrerer alle funksjonene ved bruk av notasjonen. For det andre ble denne tilnærmingen gjentatte ganger vellykket brukt på stadiet av forretningsmodellering i virkelige prosjekter for å lage programvaresystemer; resultatene ble registrert av vårt lille team av forfattere i det tilsvarende opphavsrettsobjektet [6], og ble også brukt i en opplæringsmanual [ 7]. For aktivitetsdiagrammet definerer vi at diagramfeltet er strukturert ved bruk av "svømmebaner". Spornavnet vil korrespondere med typen kartelementer som vil bli plassert på det sporet.
"Inn- og utdata-artefakter": Dette sporet vil inneholde objektelementer - objekter som brukes eller er et resultat av å utføre et prosesstrinn.
"Prosesstrinn": Her vil vi plassere Aktivitetselementer - handlingene til prosessdeltakere.
"Deltakere": en bane for elementer som vil betegne rollene til handlingsutøvere i prosessen vår; for dem vil vi bruke det samme modelleringselementet Objekt - et objekt, men vi vil legge til "Actor"-stereotypen til det.
Neste spor kalles "Forretningsregler" og på dette sporet vil vi legge inn i tekstform reglene for å utføre trinnene i prosessen, og for dette vil vi bruke modelleringselementet Note - et notat.
Vi stopper her, selv om vi også kan bruke stien "Verktøy" for å samle informasjon om nivået på prosessautomatisering. En sti kan også være nyttig "Posisjoner og inndelinger av deltakere", kan den brukes til å knytte roller til stillinger og avdelinger til prosessdeltakere.
Alt jeg nettopp beskrev er et fragment modelleringskonvensjoner, denne delen av avtalen gjelder reglene for organisering av ett diagram og følgelig reglene for å skrive og lese det.
"Oppskrift"
La oss nå vurdere muligheten for å modellere systemet spesifikt fra aktivitetsdiagrammet. Dette er bare ett av alternativene, jeg bemerker at det selvfølgelig ikke er det eneste. Aktivitetsdiagrammet vil interessere oss med tanke på dens rolle i overgangen fra prosessmodellering til design av et automatisert system. For å gjøre dette vil vi følge de metodiske anbefalingene - en slags oppskrift som består av bare fem stadier og sørger for utvikling av bare tre typer diagrammer. Ved å bruke denne oppskriften vil vi få en formalisert beskrivelse av prosessen vi ønsker å automatisere og samle inn data for systemdesign. Og for studenter i begynnelsen av å studere UML, er dette en slags livredder som ikke vil tillate dem å drukne i alle de forskjellige visuelle midler og teknikker som finnes i UML og moderne modelleringsverktøy.
Her er faktisk selve oppskriften, og følg deretter diagrammene som er laget for vårt "eventyr"-fagområde.
Trinn 1. Vi beskriver prosessen i form av et aktivitetsdiagram. For en prosess med mer enn 10 trinn, er det fornuftig å bruke prosesstrinndekomponeringsprinsippet for å forbedre lesbarheten til diagrammet.
Trinn 2. Velg hva som kan automatiseres (trinnene kan for eksempel fremheves på et diagram).
Trinn 3. Det automatiserte trinnet må tildeles en eller flere funksjoner i systemet (forholdet kan være mange-til-mange), tegn et Use-case-diagram. Dette er funksjonene til systemet vårt.
Trinn 4. La oss beskrive den interne organiseringen av AS ved hjelp av et klassediagram - Klasse. Svømmebanen "Input and Output Objects (Documents)" i aktivitetsdiagrammet er grunnlaget for å bygge en objektmodell og en enhetsrelasjonsmodell.
Trinn 5. La oss analysere notatene på "Business Rules"-sporet, gir de ulike typer restriksjoner og betingelser, som gradvis transformeres til ikke-funksjonelle krav.
Det resulterende settet med diagrammer (Activity, Use-case, Class) gir oss en formalisert beskrivelse i en ganske streng notasjon, dvs. har en entydig lesning. Nå kan du utvikle tekniske spesifikasjoner, avklare kravspesifikasjoner m.m.
La oss begynne å modellere.
Trinn 1. Beskriv prosessen i form av et aktivitetsdiagram
La meg minne deg på at vi strukturerte diagramfeltet ved å bruke "svømmebaner"; hver bane inneholder elementer av samme type (Figur 2). I tillegg til diagramelementene beskrevet ovenfor, vil vi bruke tilleggselementer, la oss beskrive dem.
Decision (Decision) angir forgreningspunktet for prosessen vår i diagrammet, og sammenslåing av tråder (Merge) – punktet for deres gjenforening. Overgangsbetingelser er skrevet i hakeparentes på overganger.
Mellom to synkronisatorer (Fork) vil vi vise parallelle prosessgrener.
Prosessen vår kan bare ha én begynnelse – ett inngangspunkt (Initial). Men det kan være flere fullføringer (Final), men ikke for vårt spesifikke diagram.
Det er ganske mange piler; med et stort antall elementer og forbindelser kan du først identifisere stadiene i prosessen, og deretter utføre en dekomponering av disse stadiene. Men for klarhetens skyld vil jeg vise vår "eventyr"-prosess helt på ett diagram, mens vi selvfølgelig må sørge for at pilene "ikke henger sammen", det ville være mulig å spore nøyaktig hva som er koblet til til hva.
Figur 2. Aktivitetsdiagram - generell oversikt over prosessen
Fordi i de poetiske linjene er noen detaljer i prosessen utelatt, de måtte restaureres, de vises av elementer med hvit bakgrunn. Disse detaljene inkluderer trinnet Overføring/mottak for lagring og behandling og flere inngangs- og utdataartefakter. Det er verdt å merke seg at dette trinnet heller ikke fullt ut avslører prosessen, fordi vi må utpeke overføringstrinnet og mottakstrinnet separat, og til og med legge til et eget trinn for skjell, og også tenke at alle disse materielle verdiene først skal lagres midlertidig et sted, etc. og så videre.
La oss også merke oss at spørsmålet om opprinnelsen til nøtter forblir ubesvart - hvor kommer de fra og hvordan kommer de til ekornet? Og dette spørsmålet (det er uthevet med rød skrift i notatet - Note-elementet) krever separat undersøkelse! Dette er hvordan en analytiker jobber - samler informasjon bit for bit, gjør antakelser og mottar "ok" eller "nei-ok" fra fageksperter - veldig viktige og rett og slett uerstattelige mennesker på stadiet av forretningsmodellering når de lager systemer.
Merk også at prosesstrinn P5 består av to deler.
Og vi vil dekomponere hver del og vurdere den mer detaljert (Figur 3, Figur 4), fordi aktivitetene som utføres innenfor disse spesielle trinnene vil bli automatisert.
Figur 3. Aktivitetsdiagram - detaljering (del 1)
Figur 4. Aktivitetsdiagram - detaljering (del 2)
Trinn 2. Velg hva som kan automatiseres
Trinnene som skal automatiseres er uthevet i farger på diagrammene (se figur 3, figur 4).
Alle utføres av én deltaker i prosessen - kontorist:
- Legger inn informasjon om vekten av mutteren i erklæringen;
- Legger inn informasjon om overføringen av mutteren i erklæringen;
- Registrerer faktum om transformasjonen av en nøtt til et skall og en kjerne;
- Legger inn informasjon om nøttekjernen i uttalelsen;
- Legger inn informasjon om nøtteskall i listen.
Analyse av utført arbeid. Hva blir det neste?
Så vi har gjort mye forarbeid: vi har samlet inn informasjon om prosessen som vi skal automatisere; begynte å danne en avtale om modellering (så langt bare når det gjelder bruk av aktivitetsdiagrammet); utførte en simulering av prosessen og til og med dekomponerte flere av trinnene; Vi identifiserte prosesstrinnene som vi vil automatisere. Vi er nå klare til å gå videre til de neste trinnene og begynne å designe systemets funksjonalitet og interne organisering.
Som du vet, er teori uten praksis ingenting. Du bør definitivt prøve "modellering" med egne hender, dette er også nyttig for å forstå den foreslåtte tilnærmingen. Du kan for eksempel jobbe i et modelleringsmiljø [3]. Vi har dekomponert bare deler av trinnene i det overordnede prosessdiagrammet (se figur 2). Som en praktisk oppgave kan du bli bedt om å gjenta alle diagrammene i Modelio-miljøet og utføre en dekomponering av trinnet "Overføring/mottak for lagring og behandling".
Vi vurderer ennå ikke å jobbe i spesifikke modelleringsmiljøer, men dette kan bli gjenstand for uavhengige artikler og anmeldelser.
I den andre delen av artikkelen vil vi analysere modellerings- og designteknikkene som er nødvendige på trinn 3-5; vi vil bruke UML Use-case og Class-diagrammer. Fortsettelse følger.
Liste over kilder
- Nettstedet "UML2.ru". Samfunnsforum for analytikere. Generelt avsnitt. Eksempler. Eksempler på eventyr i form av UML-diagrammer. [Elektronisk ressurs] Tilgangsmodus: Internett:
- Sparx Systems nettsted. [Elektronisk ressurs] Tilgangsmodus: Internett:
- Modelio nettsted. [Elektronisk ressurs] Tilgangsmodus: Internett:
- Stor encyklopedisk ordbok. Prosess (tolking). [Elektronisk ressurs] Tilgangsmodus: Internett:
- Nettsted "Organisering av effektiv ledelse". Blogg. Overskrift "Forretningsprosessledelse". Definisjon av forretningsprosess. [Elektronisk ressurs] Tilgangsmodus: Internett:
- Sertifikat nr. 18249 om registrering og deponering av et produkt av resultatet av intellektuell aktivitet. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manuskriptet til læremiddelet med tittelen "Modellering av fagområdet med Enterprise Architect" // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modellering av forretningsprosesser. - M .: KURS, NITs INFRA-M, EBS Znanium.com. – 2017.
Kilde: www.habr.com