»En dag i ekorrens liv« eller frÄn modellering av processer till design av det automatiserade systemet för materialredovisning »Ekorre-1.0« (Del 1)
Vad har »ekorren« med detta att göra?
Jag förklarar genast vad ekorren har med saken att göra. Jag snubblade över roliga projekt pĂ„ nĂ€tet för att studera UML baserat pĂ„ Ă€mnesomrĂ„det lĂ„nat frĂ„n sagor (till exempel, [1]), sĂ„ för mina studenter bestĂ€mde jag mig för att förbereda ett liknande exempel, sĂ„ att man kunde studera tre typer av diagram: Aktivitet Diagram, AnvĂ€ndningsfall Diagram och Klass Diagram. Jag översĂ€tter medvetet inte diagramtitlarna till ryska för att undvika diskussioner om "översĂ€ttningssvĂ„righeter". Jag kommer att förklara vad som gĂ€ller lite senare. I detta exempel anvĂ€nder jag miljön Enterprise Architect frĂ„n det australiensiska företaget [2] â ett bra verktyg till rimliga priser. Och i klassrumsaktiviteterna anvĂ€nder jag [3], ett bra gratisverktyg för objektorienterad design som stöder UML2.0 och BPMN-standarder, utan överflödiga funktioner för visuella möjligheter, men tillrĂ€ckligt för att studera grunderna i sprĂ„ket.
Vi planerar att automatisera verksamheten för materialredovisning som uppstÄr i dessa processer.
âŠ
Ăn ligger vid havet, (E1, E2)
Staden ligger pÄ ön (E3, E1)
Med gyllene kyrkor, (E4)
Med herrgÄrdar och trÀdgÄrdar; (E5, E6)
En gran vÀxer framför palatset, (E7, E8)
Och under den ett kristallhus; (E9)
DĂ€r bor en tam ekorre, (A1)
Och vilken krabat! (A1)
Ekorren sjunger smÄ sÄnger, (P1, A1)
Och gnager pÄ nötter, (P2)
Men nötterna Àr inte vanliga, (C1)
Allt har gyllene skal, (C2)
KÀrnorna Àr klara som smaragd; (C3)
TjÀnarna vakar över ekorren, (P3, A2)
De tjÀnar henne med olika sysslor (P4)
Och en strÀng kansler Àr tillsatt (A3)
StrÀng rapport om nötterna; (P5, C1)
Ger ekorren heder; (P6, A4)
Ur skalen gjuts mynt, (P7, C2, C4)
Och de sÀnds ut i vÀrlden; (P8)
Flickorna hÀller ut smaragder (P9, A5, C3)
I kÀllarutrymmet, under golvet; (E10, E11)
âŠ
(A.S. Pusjkina "Sagan om tsaren Saltan, om hans berömde och mĂ€ktige hjĂ€lteprins Gvidon Saltanovich och den vackra prinsessan Svanen", â 10 Ă„r frĂ„n idĂ© till publicering, förresten!)
Lite om koderna som skrivs till höger om raderna. "A" (frĂ„n "Actor") innebĂ€r att raden innehĂ„ller information om en deltagare i processen. "C" (frĂ„n "Class") â information om objekten i klasser som behandlas under processerna. "E" (frĂ„n "Environment") â information om objekten i klasser som karakteriserar utförandets omgivning. "P" (frĂ„n "Process") â information om sjĂ€lva processerna.
För övrigt pÄstÄr den exakta definitionen av processen ocksÄ att den ska vara orsaken till metodologiska diskussioner, Ätminstone eftersom processer kan vara olika: affÀrs-, produktions-, teknologiska osv. (man kan till exempel lÀsa om det [4] och [5]). För att undvika polemik enas vi om att processen intresserar oss frÄn synpunkten av dess reproducerbarhet över tid och behovet av automatisering, det vill sÀga att överlÀmna genomförandet av en viss del av processoperationerna till ett automatiserat system.
Noter om anvÀndning av aktivitetsdiagrammet
Vi börjar modellera vÄr process och kommer att anvÀnda aktivitetsdiagrammet för detta. Först förklarar jag hur de ovan angivna koderna kommer att anvÀndas i modellen. Det Àr lÀttare att förklara med ett grafiskt exempel, och vi kommer ocksÄ att gÄ igenom nÄgra (nÀstan alla nödvÀndiga) element i aktivitetsdiagrammet.
Vi analyserar följande fragment:
âŠ
Ekorren sjunger smÄ sÄnger, (P1, A1)
Och gnager pÄ nötter, (P2)
Men nötterna Àr inte vanliga, (C1)
Allt har gyllene skal, (C2)
KÀrnorna Àr klara som smaragd; (C3)
âŠ
Vi har tvÄ steg i processen P1 och P2, deltagare A1, och objekt av tre olika klasser: objekt av klass C1 kommer in i ingÄngen av steget, objekten av klasserna C2 och C3 fÄs som utgÄng, som resultat av aktiviteten hos detta steg P2 i vÄr process. För diagrammet anvÀnder vi följande modellerande element.
Fragmentet av vÄr process kan ungefÀr representeras sÄ hÀr (Figur 1).
Figur 1. Fragment av aktivitetsdiagrammet
För att organisera utrymmet och strukturera aktivitetsdiagrammet kommer vi att anvĂ€nda en nĂ„got icke-standardiserad metod, ur ett klassiskt perspektiv av UML-notationens anvĂ€ndning. Men det finns flera anledningar till detta. För det första, innan modelleringen pĂ„börjas, kommer vi att upprĂ€tta sĂ„ kallat modellavtal, dĂ€r vi faststĂ€ller alla sĂ€rskilda aspekter av notationsanvĂ€ndningen. För det andra har denna metod framgĂ„ngsrikt anvĂ€nts vid affĂ€rsmodellering i verkliga projekt för att skapa programvarusystem, och resultaten har dokumenterats av vĂ„r lilla författargrupp i det relevanta objektet av upphovsrĂ€tt [6], samt anvĂ€nts i en lĂ€robok [7]. För aktivitetsdiagrammet kommer vi att definiera att diagramfĂ€ltet struktureras med hjĂ€lp av "simmande" banor â Swim lanes. Namnet pĂ„ banan kommer att motsvara typen av element i diagrammet som kommer att placeras pĂ„ denna bana.
"In- och utgĂ„ende artefakter": PĂ„ denna bana kommer det att finnas element Objects â objekt som anvĂ€nds eller Ă€r resultatet av att en viss steg i processen genomförs.
«Processens steg»: hĂ€r placerar vi elementen Activity â Ă„tgĂ€rder frĂ„n processens deltagare.
«Deltagare»: bana för element som kommer att representera roller för dem som utför Ă„tgĂ€rder i vĂ„r process, för dem kommer vi att anvĂ€nda samma modellerande element Object â objekt, men vi lĂ€gger till stereotyperna «Actor».
Den nĂ€sta banan kallas «AffĂ€rsregler» och pĂ„ denna bana kommer vi att placera i textform regler för genomförandet av processens steg, och för detta kommer vi att anvĂ€nda det modellerande elementet Note â anteckning.
HÀr kommer vi att stanna, Àven om vi skulle kunna anvÀnda en bana «Verktyg» för att samla information om nivÄn av automatisering av processen. Det kan ocksÄ vara anvÀndbart med en bana «Positioner och avdelningar för deltagarna», den kan anvÀndas för att koppla roller till positioner och avdelningar för processens deltagare.
Allt jag just har beskrivit Àr en del av överenskommelsen om modellering, denna del av överenskommelsen handlar om reglerna för att organisera ett diagram och dÀrmed reglerna för dess skrivande och lÀsande.
«Recept»
Nu ska vi titta pĂ„ en variant av systemmodellering frĂ„n diagrammet Activity. Detta Ă€r bara en av varianterna, jag pĂ„pekar att den naturligtvis inte Ă€r den enda. Diagrammet Activity kommer att intressera oss utifrĂ„n dess roll för att gĂ„ frĂ„n processmodellering till design av ett automatiserat system. För detta kommer vi att följa metodiska rekommendationer â ett slags recept som bestĂ„r av endast fem steg och förutsĂ€tter utvecklingen av tre olika typer av diagram. AnvĂ€ndningen av detta recept kommer att hjĂ€lpa till att fĂ„ en formaliserad beskrivning av den process vi vill automatisera och samla in data för systemdesign. Och för studenter i början av sin studie av UML Ă€r detta en sorts rĂ€ddningsbĂ„t som förhindrar att man drunknar i hela den mĂ„ngfald av visuella medel och metoder som finns i UML och moderna modelleringsverktyg.
HÀr Àr i princip receptet, och dÀrefter följer diagram som Àr byggda för vÄrt «fantasirikliga» ÀmnesomrÄde.
Steg 1. Vi beskriver processen i form av diagrammet Activity. För processer med mer Àn 10 steg Àr det meningsfullt att tillÀmpa principen för dekomposition av processstegen för att öka diagrammets lÀsbarhet.
Steg 2. Identifiera vad som kan automatiseras (stegen kan till exempel markeras i diagrammet).
Steg 3. Den automatiserade ÄtgÀrden mÄste kopplas till en eller flera systemfunktioner (relationen kan vara mÄnga-till-mÄnga), rita en Use-case-diagram. Detta Àr funktionerna i vÄrt system.
Steg 4. Vi beskriver den interna organiseringen av AS med hjĂ€lp av ett klassdiagram â Klass. SimuleringsvĂ€gen "In- och utdataobjekt (dokument)" i aktivitetsdiagrammet Ă€r grunden för att bygga en objektsmodell och en entitet-relation-modell.
Steg 5. Vi analyserar anteckningarna pÄ spÄret "AffÀrsregler", de ger olika typer av begrÀnsningar och villkor, som gradvis omvandlas till icke-funktionella krav.
Den resulterande uppsÀttningen av diagram (Aktivitet, Use-case, Klass) ger en formell beskrivning i en tillrÀckligt strikt notation, dvs. den har en entydig tolkning. Nu kan tekniska krav utvecklas, specifikationen kan preciseras, osv.
LÄt oss börja modellera.
Steg 1. Beskriv processen i form av ett aktivitetsdiagram
Jag pÄminner om att vi strukturerade diagramomrÄdet med "simulerings"-banor, dÀr varje bana innehÄller element av samma typ (Figur 2). Utöver de ovan nÀmnda element i diagrammet kommer vi att anvÀnda ytterligare element, lÄt oss beskriva dem.
Beslut (Decision) representerar i diagrammet en förgreningspunkt i vÄr process, medan flödesfusion (Merge) Àr punkten för deras Äterförening. I hakparenteser pÄ övergÄngarna skrivs övergÄngsvillkoren.
Mellan tvÄ synkroniserare (Fork) ska vi visa parallella grenar av processen.
VĂ„r process kan bara ha en början â en ingĂ„ngspunkt (Initial). Men avslutningar (Final) kan vara flera, men inte för vĂ„rt specifika diagram.
Det finns ganska mÄnga pilar, vid ett stort antal element och samband kan man först identifiera processen steg och sedan utföra dekompositionen av dessa steg. Men jag skulle vilja visa vÄr "fabulous" process helt och hÄllet pÄ ett diagram för tydlighetens skull, samtidigt som vi naturligtvis behöver se till att pilarna "inte klibbar ihop", sÄ att man skulle kunna spÄra exakt vad som hÀnger ihop med vad.
Figur 2. Aktivitetsdiagram â översikt över processen
Eftersom vissa detaljer i diktens rader har utelĂ€mnats, var vi tvungna att Ă„terskapa dem, och de visas som element med vit bakgrund. Dessa detaljer inkluderar steget "Ăverföring/mottagning för lagring och bearbetning" samt flera ingĂ„ende och utgĂ„ende artefakter. Det Ă€r vĂ€rt att notera att detta steg inte heller helt belyser processen, eftersom vi skulle behöva ange stegen för överföring och mottagning separat, samt lĂ€gga till ett sĂ€rskilt steg för skalen, och Ă€ven förestĂ€lla oss att alla dessa materiella vĂ€rden först mĂ„ste lagras temporĂ€rt nĂ„gonstans, etc.
Vi uppmĂ€rksammar ocksĂ„ att frĂ„gan om ursprunget till nötterna fortfarande Ă€r obesvarad â varifrĂ„n kommer de och hur kommer de till ekorren? Och denna frĂ„ga (den Ă€r markerad med röd text i anteckningen â elementet Note) krĂ€ver sĂ€rskild bearbetning! SĂ„ hĂ€r arbetar en analytiker â samlar information bit för bit, gör antaganden och fĂ„r "okej" eller "inte okej" frĂ„n Ă€mnesexperter â mycket viktiga och helt oumbĂ€rliga personer i affĂ€rsmodellering i skapandet av system.
Vi noterar ocksÄ att steget i processen P5 bestÄr av tvÄ delar.
Vi kommer att dekomponera varje del och titta nÀrmare pÄ dem (Figur 3, Figur 4), eftersom verksamheten som utförs inom just dessa steg kommer att automatiseras.
Figur 3. Aktivitetsschema â detaljerning (del 1)
Figur 4. Aktivitetsschema â detaljerning (del 2)
Steg 2. Identifiera vad som kan automatiseras
Stegen som ska automatiseras i systemen markeras med fÀrg (se Figur 3, Figur 4).
Allt utförs av en deltagare i processen â TjĂ€nsteman:
- LÀmnar in information om vikt av nötterna i protokollet;
- LÀmnar in information om överföring av nötterna i protokollet;
- Registrerar faktumet av nötternas förvandling till skal och kÀrna;
- LÀmnar in information om kÀrnan av nötterna i protokollet;
- LÀmnar in information om skalen av nötterna i protokollet.
Analys av det utförda arbetet. Vad hÀnder hÀrnÀst?
Vi har nu genomfört ett omfattande förberedelsearbete: samlat information om den process vi ska automatisera; börjat utforma ett modellavtal (Àn sÄ lÀnge endast betrÀffande anvÀndningen av aktivitetsdiagram); genomfört processmodellering och Àven brutit ner nÄgra av dess steg; identifierat de steg i processen som vi kommer att automatisera. Nu Àr vi redo att gÄ vidare till nÀsta steg och pÄbörja designen av systemets funktioner och dess interna organisation.
Som bekant Ă€r teori utan praktik ingenting. Det Ă€r viktigt att verkligen prova pĂ„ "modellering" med egna hĂ€nder, det Ă€r nyttigt för att förstĂ„ den föreslagna metoden. Till exempel kan man arbeta i en modelleringsmiljö. [3]. Vi har endast brutit ner en del av stegen i diagrammet för den övergripande processen (se Figur 2). Som en praktisk uppgift kan det föreslĂ„s att reproducera alla diagram i Modelio och utföra nedbrytningen av steget "Ăverföring/mottagning för lagring och bearbetning".
Vi övervÀger för nÀrvarande inte arbete i specifika modelleringsmiljöer, men detta kan bli föremÄl för egna artiklar och recensioner.
I den andra delen av artikeln kommer vi att gÄ igenom tekniker för modellering och design som Àr nödvÀndiga i steg 3-5, dÀr vi kommer att anvÀnda UML-diagram för anvÀndningsfall och klass. FortsÀttning följer.
KÀllförteckning
- Webbplatsen «UML2.ru». Forum för Analytikers Gemenskap. AllmÀn sektion. Exempel. Exempel pÄ sagor utformade som UML-diagram. [Elektronisk resurs] TillgÄng: Internet:
- Webbplats för Sparx Systems. [Elektronisk resurs] à tkomstlÀge: Internet:
- Webbplats Modelio. [Elektronisk resurs] TillgÄng: Internet:
- Stort Encyklopediskt Lexikon. Process (tolkning). [Elektronisk resurs] TillgÄng: Internet:
- Webbplatsen «Organisation för effektiv styrning». Blogg. Sektion «Styrning av affÀrsprocesser». Definition av affÀrsprocess. [Elektronisk resurs] TillgÄng: Internet:
- Intyg nr 18249 om registrering och deponering av resultatet av intellektuell verksamhet. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manuskript till en lÀrobok vid namn «Modellering av ÀmnesomrÄdet med hjÀlp av Enterprise Architect» // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modellerings av affĂ€rsprocesser. â M.: KURS, NII INFRA-M, EBS Znanium.com. â 2017.
KĂ€lla: habr.com
