«En dag i en ekorrs liv» eller frÄn modellering av processer till design av det automatiserade systemet för redovisning av materiella tillgÄngar «Belka-1.0» (Del 2)
Sammanfattning av föregÄende avsnitt
I vi anvÀnde ett «sagolikt» ÀmnesomrÄde, inspirerade av exempel pÄ studier av UML-diagram med stöd av sagans berÀttelser (se, till exempel, [1]). Innan vi började modellera kom vi överens om att anvÀnda vissa element av aktivitetsdiagrammet och började formulera en överenskommelse om modelleringen. Med hÀnsyn till dessa överenskommelser beskrev vi i det första steget processen i form av aktivitetsdiagram, och i det andra steget identifierade vi de steg i processen för vilka automatisering krÀvs (och Àr möjlig).
Jag pÄminner om att vi planerar att automatisera verksamheten för redovisning av materiella tillgÄngar, 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. Pushkin «Sagan om tsar Saltan, om hans berömde och mÀktige hjÀlte prins Gvidon Saltanovich och om den vackra prinsessan Svanka», )
I detta exempel anvÀnder jag miljön Enterprise Architect frÄn det australiensiska företaget [2], och i undervisningen tillÀmpar jag [3].
Jag pÄminner om att processerna Àr olika, man kan bekanta sig med dem, till exempel, [4] och [5].
För mer information om de tillÀmpade modellerings- och designmetoderna, se [6, 7].
Den fullstÀndiga specifikationen av UML finns i. [8].
Nu Àr vi redo att gÄ vidare till de följande stegen och börja designa funktionerna i systemet och dess interna organisation. Numreringen av bilderna kommer att fortsÀtta.
Steg 3. Den automatiserade ÄtgÀrden mÄste kopplas till en eller flera systemfunktioner
Det utvecklade automatiserade systemet (AS) Àr avsett för noggrann registrering av nötter, minns du? För varje specificerad ÄtgÀrd (se Figur 3, Figur 4 ), som vi kommer att automatisera, noterar vi funktionskravet, med en ungefÀrlig konstruktion som "Systemet ska möjliggöra ..." och vi kommer att utveckla en Use-case-diagram. Just nu kompletterar vi i praktiken vÄrt modellavtal med nya regler. Jag förklarar vilka element vi kommer att anvÀnda.
Mellan "AnvÀndarroll" och "Funktion" anvÀnder vi relationen "Association" (Figur 5), vilket innebÀr att den anvÀndare med denna roll har tillgÄng att utföra denna funktion.
Figur 5. AnvÀndning av relationstypen "Association"
FrÄn "Funktion" till "Krav" ska vi etablera relationen "Implementation" (Figur 6) för att visa att detta krav kommer att uppfyllas av dessa funktioner, relationen kan ocksÄ vara "mÄnga-till-mÄnga", det vill sÀga en funktion kan delta i implementeringen av flera krav, och för att uppfylla ett krav kan mer Àn en funktion behövas.
Figur 6. AnvÀndning av relationstypen "Implementation"
Om en funktion krĂ€ver att en annan funktion mĂ„ste fullgöras, och det Ă€r obligatoriskt, anvĂ€nder vi relationen "Dependency" med stereotypen "Include" â inkludering (Figur 7). Om utförandet av den ytterligare funktionen krĂ€vs under vissa förhĂ„llanden, kommer vi att anvĂ€nda relationen "Dependency" med stereotypen "Extend" â utvidgning. Allt Ă€r vĂ€ldigt lĂ€tt att komma ihĂ„g: "Include" â ALLTID, och "Extend" â IBLAND.
Figur 7. AnvÀndning av relationstypen "Dependency (inclusion)"
Som ett resultat kommer vÄrt diagram att se ut pÄ följande sÀtt (Figur 8).
Figur 8. Use-case-diagram (funktionell modell av AS)
Dessutom anvÀnds Use-case-diagrammet för att modellera anvÀndarroller (Figur 9).
Figur 9. Use-case-diagram (anvÀndarroller i AS)
Steg 4. Vi beskriver den interna organiseringen av AS med hjÀlp av ett klassdiagram
Genom att anvĂ€nda information om in- och utgĂ„ngsartefakter i vĂ„r process (se aktivitetsdiagram â Figur 2, Figur 3, Figur 4) kommer vi att utveckla ett klassdiagram. Vi kommer att anvĂ€nda modellerande element som "Klass" och olika typer av relationer mellan dem.
För att visa relationen "helhet-del" kommer vi att anvÀnda en relation av typen "Aggregation" (Figur 10): nötter Àr helheten, medan skal och kÀrna Àr delarna.
Figur 10. Relation "helhet-del"
Som ett resultat kommer segmentet av vÄrt diagram att se ut ungefÀr sÄ hÀr (Figur 11). FÀrgerna markerar de klasser som vi har identifierat direkt i textbeskrivningen av processen.
Figur 11. Klassdiagram
Klassdiagrammet anvĂ€ndes ocksĂ„ för att modellera andra artefakter â inte bara de som kommer att ha relation till den konceptuella modellen av automatiseringsprocessen för redovisning av materiella vĂ€rden, utan Ă€ven till miljön som körs (Figur 12) och "grann" processer (Figur 13) som kan pĂ„verka den automatiserade processen men för tillfĂ€llet inte ligger i fokus för vĂ„r uppmĂ€rksamhet (vi antar att systemet kommer att utvecklas och denna information kommer att vara anvĂ€ndbar).
Figur 12. Klassdiagram (miljö)
Relationen arv visar generaliseringen av olika byggnader, "barn" klasser under den generaliserande "förÀldra" klassen "Byggnad".
Figur 13. Klassdiagram (tillÀggsinformation om artefakter)
"Reaktion pÄ situationen" beror pÄ "Data frÄn visuell kontroll". För flera beroenderelationer anvÀnds stereotypen "trace" för att visa spÄrning av klasser som inte uttryckligen nÀmnts i processbeskrivningen men som Àr nödvÀndiga för automatiseringen, till klasser vars instanser det finns exakt hÀnvisning till i vÄr beskrivning.
Steg 5. Vi analyserar anteckningarna pÄ spÄret "AffÀrsregler"
Som regler angavs (se Figur 2 ):
- behovet av att dela upp ett av stegen i 2 delar, den andra delen börjar inte utföras förrÀn vissa villkor Àr uppfyllda;
- utnÀmning av en viss tjÀnsteman för att ansvara för redovisningen av nötter;
- teknisk ÄtgÀrd (vit fÀrg pÄ elementen), som anger att elementet uppenbarligen inte angetts i processbeskrivningen.
Det bör noteras att alla dessa regler redan har anvÀnts vid utvecklingen av diagrammen.
Slutord
SÄ vi har gÄtt igenom 5 steg och skapat 3 typer av diagram. Jag vill tillÀgga en liten kommentar om organiseringen av vÄra modeller i simuleringsmiljön. Det finns mÄnga ramverk som hjÀlper till att strukturera de utvecklade modellerna, men det Àr inte Àmnet för denna artikel, sÄ vi begrÀnsar oss till följande enkla uppsÀttning paket för en ordnad hantering av vÄrt projekt: AffÀrsprocess, Funktionell modell, Artefakter, Deltagare och Miljö (Figur 14).
Figur 14. Struktur av projektpaket
PÄ sÄ sÀtt har vi utvecklat koordinerade modeller som beskriver systemet för redovisning av materiella vÀrden frÄn olika perspektiv: modell för automatiserad affÀrsprocess, funktionell modell och en modell av systemets interna organisation pÄ konceptuell nivÄ.
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.
- OMG Unified Modeling Language (OMG UML) Specification. Version 2.5.1. [Elektronisk resurs] à tkomstlÀge: Internet:
KĂ€lla: habr.com
