"En dag i et ekorns liv" eller fra modelleringsprosesser til å designe et automatisert system for regnskapsføring av materielle eiendeler "Belka-1.0" (del 2)
Sammendrag av forrige serie
В vi brukte et "eventyr"-fagområde inspirert av eksempler på å studere UML-diagrammer basert på eventyrplott (se f.eks. [1]). Før modelleringen ble vi enige om bruken av noen elementer i aktivitetsdiagrammet og begynte å lage en modelleringsavtale. Med hensyn til disse avtalene beskrev vi på 1. trinn prosessen i form av Aktivitetsdiagrammer, og på 2. trinn identifiserte vi prosesstrinn som det kreves (og mulig) automatisering for.
La meg minne deg på at vi skal automatisere aktiviteten for regnskapsføring av materielle verdier, 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 sønn prins Gvidon Saltanovich og den vakre svaneprinsessen", )
I dette eksemplet bruker jeg Enterprise Architect-miljøet fra et australsk selskap. [2], og i rammen av treningsøkter jeg bruker [3].
La meg minne deg på at prosesser er forskjellige, du kan bli kjent med f.eks. [4] og [5].
Se [6, 7] for detaljer om anvendte tilnærminger til modellering og design.
For den fullstendige UML-spesifikasjonen, se [8].
Vi er nå klare til å gå videre til de neste trinnene og begynne å designe funksjonene til systemet og dets interne organisasjon. Figurnummerering vil fortsette.
Trinn 3. Det automatiserte trinnet må tildeles en eller flere funksjoner i systemet
Det automatiserte systemet (AS) som utvikles er designet for å holde en streng oversikt over nøtter, husker du? For hvert uthevet trinn (se figur 3, figur 4 ), som vi skal automatisere, skrive ned funksjonskravet, bruke noe som denne konstruksjonen "Systemet må kunne ..." og utvikle et Use-case diagram. Nå supplerer vi faktisk modellavtalen vår med nye regler. La meg forklare hvilke elementer vi skal bruke.
Mellom "Brukerrollen" og "Funksjonen" vil vi bruke "Association"-relasjonen (Figur 5), som betyr at brukeren med denne rollen kan utføre denne funksjonen.
Figur 5. Bruke en assosiasjonstyperelasjon
Fra "Funksjon" til "Krav", vil vi trekke "Implementering"-lenken (Figur 6) for å vise at dette kravet vil bli implementert av disse funksjonene, forholdet kan være "mange-til-mange", dvs. én funksjon kan være involvert i implementeringen av flere krav, og mer enn én funksjon kan være nødvendig for å implementere kravet.
Figur 6. Bruke et implementeringsforhold
Hvis en funksjon krever at en annen funksjon utføres, og det er nødvendig, vil vi bruke "Avhengighet"-forbindelsen med "Inkluder"-stereotypen - inkludering (Figur 7). Hvis utførelse av en tilleggsfunksjon er nødvendig under visse forhold, vil vi bruke "Avhengighet"-forbindelsen med "Utvid"-stereotypen - en utvidelse. Alt er veldig enkelt å huske: "Inkluder" - ALLTID, og "Forleng" - NOEN GANG.
Figur 7. Bruk av lenketypen "Dependency (inkluder)"
Som et resultat vil diagrammet vårt se omtrent slik ut (Figur 8).
Figur 8. Use-case diagram (funksjonell modell av AS)
I tillegg brukes Use-case-diagrammet til å modellere brukerroller (Figur 9).
Figur 9. Use-case diagram (rollene til AS-brukere)
Trinn 4. La oss beskrive den interne organiseringen av AS ved hjelp av et klassediagram
Ved å bruke informasjon om inngangs- og utgangsartefakter til prosessen vår (se Aktivitetsdiagrammer - Figur 2, Figur 3, Figur 4), vil vi utvikle et klassediagram. Vi vil bruke "Klasse"-modelleringselementene og ulike typer relasjoner mellom dem.
For å vise forholdet "hele delene", vil vi bruke forholdet "Aggregasjon" (Figur 10): nøtten er helheten, og skallene og kjernen er delene.
Figur 10. Hel-del forhold
Som et resultat vil et fragment av diagrammet vårt se omtrent slik ut (Figur 11). Klasser er merket med farge, som vi har fremhevet direkte i tekstbeskrivelsen av prosessen.
Figur 11. Klassediagram
Klassediagrammet ble også brukt til å modellere andre artefakter - ikke bare de som vil være relevante for den konseptuelle modellen for den automatiserte inventarprosessen, men relatert til utførelsesmiljøet - miljøet (Figur 12) og "nabo"-prosesser (Figur 13). som kan påvirke den automatiserte prosessen, men som ennå ikke er i fokus for vår oppmerksomhet (vi antar at systemet vil utvikle seg og denne informasjonen vil være nyttig).
Figur 12. Klassediagram (miljø)
Arveforholdet viser generaliseringen av ulike bygninger, «barn»-klasser, under den generaliserende «foreldre»-klassen «Bygning».
Figur 13. Klassediagram (mer informasjon om artefakter)
"Reaksjon på situasjonen" avhenger av "Visuelle kontrolldata". For flere avhengighetsforhold brukes "sporing"-stereotypen for å vise sporing av klasser som ikke er eksplisitt angitt i prosessbeskrivelsen, men som er nødvendige for automatiseringen, til klasser hvis forekomster er presist angitt i beskrivelsen vår.
Trinn 5. La oss analysere notatene på "Business Rules"-sporet
Som regler ble spesifisert (se figur 2 ):
- behovet for å dele et av trinnene i 2 deler, den andre delen begynner å utføres bare under visse forhold;
- utnevnelse av en viss tjenestemann til å utføre regnskap for nøtter;
- en teknikk (hvit farge på elementene), som indikerer at elementet ikke var eksplisitt oppført i prosessbeskrivelsen.
Det skal bemerkes at vi allerede har brukt alle disse reglene når vi utvikler diagrammer.
Avsluttende merknader
Så vi gikk gjennom 5 stadier og bygde 3 typer diagrammer. Jeg vil legge til en liten kommentar om organiseringen av våre modeller i modelleringsmiljøet. Det er et stort antall rammeverk som hjelper til med å strukturere modellene vi utvikler, men dette er ikke temaet for denne artikkelen, så vi vil begrense oss til følgende enkle sett med pakker for ryddig vedlikehold av prosjektet vårt: Forretningsprosess, Funksjonell modell, Artefakter, deltakere og miljø (Figur 14).
Figur 14. Strukturen til prosjektpakkene
Derfor har vi utviklet konsistente modeller som beskriver systemet for regnskapsføring av materielle eiendeler fra ulike vinkler: en modell av en automatisert forretningsprosess, en funksjonell modell og en modell for den interne organiseringen av systemet på konseptuelt nivå.
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.
- OMG Unified Modeling Language (OMG UML) spesifikasjon. Versjon 2.5.1. [Elektronisk ressurs] Tilgangsmodus: Internett:
Kilde: www.habr.com