"En dag i en ekorres liv" eller från processmodellering till design av ett automatiserat förmögenhetsredovisningssystem "Belka-1.0" (Del 1)
Vad har "ekorre" med det att göra?
Jag ska omedelbart förklara vad "ekorren" har med det att göra. Efter att ha stött på roliga projekt på Internet för att lära sig UML baserat på ett ämnesområde lånat från sagor (t.ex. [1]), bestämde jag mig också för att förbereda ett liknande exempel för mina elever så att de bara kunde studera tre typer av diagram till att börja med: Aktivitetsdiagram, Användningsfallsdiagram och Klassdiagram. Jag översätter inte medvetet namnen på diagrammen till ryska för att undvika tvister om "översättningssvårigheter". Jag ska förklara vad det är för lite senare. I det här exemplet använder jag Enterprise Architect-ramverket från ett australiensiskt företag [2] – ett bra verktyg till ett rimligt pris. Och som en del av mina träningspass använder jag [3], ett bra gratis objektorienterat designverktyg som stöder UML2.0- och BPMN-standarder, utan onödiga bells and whistles när det gäller visuella möjligheter, men ganska tillräckligt för att lära sig grunderna i språket.
Vi kommer att automatisera aktiviteten för redovisning av materiella tillgångar, som uppstår i dessa processer.
.
En ö ligger vid havet, (E1, E2)
Det haglar på ön (E3, E1)
Med gyllene kupolkyrkor, (E4)
Med torn och trädgårdar; (E5, E6)
Framför slottet växer en gran (E7, E8)
Och nedanför det är ett kristallhus; (E9)
En tam ekorre bor där, (A1)
Ja vilket äventyr! (A1)
Ekorren sjunger sånger, (P1, A1)
Ja, han fortsätter att knapra på nötter, (P2)
Men nötter är inte enkla, (C1)
Alla skal är gyllene, (C2)
Kärnan är ren smaragd; (C3)
Tjänare vaktar ekorren, (P3, A2)
De tjänar henne som olika tjänare (P4)
Och en kontorist tilldelades (A3)
En strikt redogörelse för nötter är nyheten; (P5, C1)
Armén hälsar henne; (P6, A4)
Ett mynt hälls från skalen, (P7, C2, C4)
Låt dem gå jorden runt; (P8)
Flickor häller smaragd (P9, A5, C3)
In i förråden och under tak; (E10, E11)
.
(A.S. Pushkin "Sagan om tsar Saltan, om hans ärorika och mäktiga hjälte prins Guidon Saltanovich och den vackra prinsessan Swan", — 10 år från idé till publicering, förresten!)
Lite om koderna som skrivs till höger om raderna. "A" (från "Actor") betyder att raden innehåller information om en deltagare i processen. "C" (från "Klass") – information om klassobjekt som bearbetas under exekveringen av processer. "E" (från "Environment") – information om klassobjekt som kännetecknar miljön för exekvering av processer. “P” (från “Process”) – information om själva processerna.
Förresten, den exakta definitionen av en process påstår sig också vara orsaken till metodologiska tvister, om så bara på grund av det faktum att det finns olika processer: affärer, produktion, tekniska, etc. och så vidare. (du kan ta reda på t.ex. [4] och [5]). För att undvika kontroverser, låt oss hålla med om det Vi är intresserade av processen utifrån dess repeterbarhet över tid och behovet av automatisering, dvs. överföra utförandet av någon del av processoperationerna till ett automatiserat system.
Anteckningar om hur du använder aktivitetsdiagrammet
Låt oss börja modellera vår process och använda aktivitetsdiagrammet för detta. Låt mig först förklara hur ovanstående koder kommer att användas i modellen. Det är lättare att förklara med ett grafiskt exempel, men samtidigt kommer vi att analysera några (nästan alla de vi behöver) element i aktivitetsdiagrammet.
Låt oss analysera följande fragment:
.
Ekorren sjunger sånger, (P1, A1)
Ja, han fortsätter att knapra på nötter, (P2)
Men nötter är inte enkla, (C1)
Alla skal är gyllene, (C2)
Kärnan är ren smaragd; (C3)
.
Vi har två processsteg P1 och P2, deltagare A1 och objekt av tre olika klasser: ett objekt av klass C1 matas in i steget, objekt i klasserna C2 och C3 matas ut som ett resultat av aktiviteten i detta steg P2 i vår bearbeta. För diagrammet använder vi följande modelleringselement.
Ett fragment av vår process kan representeras ungefär så här (Figur 1).
Figur 1. Fragment av aktivitetsdiagram
För att organisera utrymmet och strukturera aktivitetsdiagrammet kommer vi att använda ett icke-standardiserat tillvägagångssätt, ur den klassiska användningen av UML-notation. Men det finns flera anledningar till detta. För det första, precis innan vi startar modelleringen kommer vi att sammanställa den så kallade modellavtal, där vi registrerar alla funktioner för att använda notationen. För det andra användes detta tillvägagångssätt upprepade gånger framgångsrikt i stadiet av affärsmodellering i verkliga projekt för att skapa mjukvarusystem; resultaten registrerades av vårt lilla team av författare i motsvarande upphovsrättsobjekt [6], och användes också i en utbildningsmanual [ 7]. För aktivitetsdiagrammet definierar vi att diagramfältet är strukturerat med hjälp av "simbanor". Spårnamnet kommer att motsvara typen av diagramelement som kommer att placeras på det spåret.
"In- och utmatningsartefakter": Detta spår kommer att innehålla objektelement - objekt som används eller är resultatet av exekvering av något processsteg.
"Process steg": Här kommer vi att placera aktivitetselement - processdeltagarnas handlingar.
"Deltagare": en väg för element som kommer att beteckna rollerna för handlingsutövare i vår process; för dem kommer vi att använda samma modelleringselement Objekt - ett objekt, men vi kommer att lägga till stereotypen "Actor" till det.
Nästa spår kallas "Affärsregler" och på detta spår kommer vi att placera i textform reglerna för att utföra stegen i processen, och för detta kommer vi att använda modelleringselementet Note - en anteckning.
Vi kommer att stanna här, även om vi också skulle kunna använda stigen "Verktyg" att samla in information om nivån på processautomatisering. En väg kan också komma till användning "Positioner och indelningar av deltagare", kan den användas för att koppla roller till positioner och avdelningar för processdeltagare.
Allt som jag just beskrev är ett fragment modelleringskonventioner, denna del av avtalet gäller reglerna för att organisera ett diagram och följaktligen reglerna för att skriva och läsa det.
"Recept"
Låt oss nu överväga alternativet att modellera systemet specifikt från aktivitetsdiagrammet. Detta är bara ett av alternativen, jag noterar att det naturligtvis inte är det enda. Aktivitetsdiagrammet kommer att intressera oss utifrån dess roll i övergången från processmodellering till design av ett automatiserat system. För att göra detta kommer vi att följa de metodologiska rekommendationerna - ett slags recept som endast består av fem steg och tillhandahåller utveckling av endast tre typer av diagram. Att använda detta recept hjälper oss att få en formaliserad beskrivning av processen vi vill automatisera och samla in data för systemdesign. Och för studenter i början av att studera UML är detta en slags livräddare som inte kommer att tillåta dem att drunkna i alla de olika visuella medel och tekniker som finns i UML och moderna modelleringsverktyg.
Här är faktiskt själva receptet, och följ sedan diagrammen som byggts för vårt "sago" ämnesområde.
Steg 1. Vi beskriver processen i form av ett aktivitetsdiagram. För en process med mer än 10 steg är det vettigt att tillämpa principen om processstegsuppdelning för att förbättra diagrammets läsbarhet.
Steg 2. Välj vad som kan automatiseras (stegen kan till exempel markeras på ett diagram).
Steg 3. Det automatiserade steget måste vara associerat med en eller flera funktioner i systemet (relationen kan vara många-till-många), rita ett Use-case-diagram. Dessa är funktionerna i vårt system.
Steg 4. Låt oss beskriva AS:s interna organisation med hjälp av ett klassdiagram - Klass. Simvägen "Input and Output Objects (Documents)" i aktivitetsdiagrammet är grunden för att bygga en objektmodell och en entitetsrelationsmodell.
Steg 5. Låt oss analysera anteckningarna på spåret "Business Rules"., ger de olika typer av begränsningar och villkor, som gradvis omvandlas till icke-funktionella krav.
Den resulterande uppsättningen diagram (Activity, Use-case, Class) ger oss en formaliserad beskrivning i en ganska strikt notation, d.v.s. har en entydig läsning. Nu kan du ta fram tekniska specifikationer, förtydliga kravspecifikationer m.m.
Låt oss börja modellera.
Steg 1. Beskriv processen i form av ett aktivitetsdiagram
Låt mig påminna dig om att vi strukturerade diagramfältet med "simningsbanor"; varje körfält innehåller element av samma typ (Figur 2). Förutom diagramelementen som beskrivs ovan kommer vi att använda ytterligare element, låt oss beskriva dem.
Beslut (Beslut) betecknar förgreningspunkten för vår process i diagrammet, och sammanslagna trådar (Merge) - punkten för deras återförening. Övergångsvillkor skrivs inom hakparenteser på övergångar.
Mellan två synkroniserare (Fork) kommer vi att visa parallella processgrenar.
Vår process kan bara ha en början - en ingångspunkt (Initial). Men det kan finnas flera kompletteringar (Final), men inte för vårt specifika diagram.
Det finns ganska många pilar; med ett stort antal element och anslutningar kan du först identifiera stadierna i processen och sedan utföra en nedbrytning av dessa stadier. Men för tydlighetens skull skulle jag vilja visa vår "sago"-process helt på ett diagram, medan vi naturligtvis måste se till att pilarna "inte håller ihop", det skulle vara möjligt att exakt spåra vad som är anslutet till vad.
Figur 2. Aktivitetsdiagram - allmän bild av processen
Därför att i de poetiska raderna är vissa detaljer i processen utelämnade, de måste återställas, de visas av element med vit bakgrund. Dessa detaljer inkluderar överföring/mottagning för lagring och bearbetning och flera in- och utmatningsartefakter. Det är värt att notera att detta steg inte heller helt avslöjar processen, eftersom vi skulle behöva ange sändningssteget och mottagningssteget separat, och till och med lägga till ett separat steg för skal, och också tänka att först alla dessa materialvärden ska lagras tillfälligt någonstans, etc. och så vidare.
Låt oss också notera att frågan om nötternas ursprung förblir obesvarad - var kommer de ifrån och hur kommer de till ekorren? Och denna fråga (den är markerad med rött teckensnitt i anteckningen - Note-elementet) kräver separat studie! Det är så här en analytiker arbetar - samlar information bit för bit, gör antaganden och tar emot "okej" eller "nej-okej" från ämnesexperter - mycket viktiga och helt enkelt oersättliga människor i stadiet av affärsmodellering när man skapar system.
Notera också att processsteg P5 består av två delar.
Och vi kommer att sönderdela varje del och överväga det mer detaljerat (Figur 3, Figur 4), eftersom aktiviteterna som utförs inom dessa specifika steg kommer att automatiseras.
Figur 3. Aktivitetsdiagram - detaljering (del 1)
Figur 4. Aktivitetsdiagram - detaljering (del 2)
Steg 2. Välj vad som kan automatiseras
Stegen som ska automatiseras är markerade i färg på diagrammen (se figur 3, figur 4).
Alla av dem utförs av en deltagare i processen - kontoristen:
- Anger information om mutterns vikt i uttalandet;
- Anger information om överföringen av muttern i uttalandet;
- Registrerar det faktum att en nöt omvandlas till ett skal och en kärna;
- Matar in information om nötkärnan i uttalandet;
- Matar in information om nötskal i listan.
Analys av utfört arbete. Vad kommer härnäst?
Så vi har gjort mycket förberedande arbete: vi har samlat in information om processen som vi ska automatisera; började bilda en överenskommelse om modellering (hittills bara när det gäller att använda aktivitetsdiagrammet); utförde en simulering av processen och dekomponerade till och med flera av dess steg; Vi identifierade processstegen som vi kommer att automatisera. Vi är nu redo att gå vidare till nästa steg och börja designa systemets funktionalitet och interna organisation.
Som ni vet är teori utan praktik ingenting. Du bör definitivt försöka "modellera" med dina egna händer, detta är också användbart för att förstå det föreslagna tillvägagångssättet. Du kan till exempel arbeta i en modellmiljö [3]. Vi har dekomponerat endast en del av stegen i det övergripande processdiagrammet (se figur 2). Som en praktisk uppgift kan du bli ombedd att upprepa alla diagram i Modelio-miljön och utföra en nedbrytning av steget "Överföring/mottagning för lagring och bearbetning".
Vi överväger ännu inte att arbeta i specifika modelleringsmiljöer, men detta kan bli föremål för oberoende artiklar och recensioner.
I den andra delen av artikeln kommer vi att analysera de modellerings- och designtekniker som krävs i steg 3-5; vi kommer att använda UML Use-case och Class-diagram. Fortsättning följer.
Lista över källor
- Webbplatsen "UML2.ru". Forum för analytiker. Allmänt avsnitt. Exempel. Exempel på sagor formaterade som UML-diagram. [Elektronisk resurs] Åtkomstläge: Internet:
- Sparx Systems webbplats. [Elektronisk resurs] Åtkomstläge: Internet:
- Modelio hemsida. [Elektronisk resurs] Åtkomstläge: Internet:
- Stor encyklopedisk ordbok. Process (tolkning). [Elektronisk resurs] Åtkomstläge: Internet:
- Webbplats "Organisation of Effective Management". Blogg. Kategori "Business Process Management". Definition av en affärsprocess. [Elektronisk resurs] Åtkomstläge: Internet:
- Intyg nr 18249 om registrering och deponering av ett verk av intellektuell verksamhet. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manuskript till ett läromedel med titeln "Modeling a subject area using Enterprise Architect" // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Affärsprocessmodellering. — M.: KURS, SIC INFRA-M, EBS Znanium.com. — 2017.
Källa: will.com