"Een dag in die lewe van 'n eekhoring" of van prosesmodellering tot die ontwerp van 'n outomatiese welvaartrekeningstelsel "Belka-1.0" (Deel 2)
Opsomming van die vorige episode
В Ons het 'n "sprokie"-domein gebruik, geïnspireer deur voorbeelde van die aanleer van UML-diagramme gebaseer op sprokiesverhale (sien bv. [1]). Voordat die modellering begin het, het ons ooreengekom oor die gebruik van sommige elemente van die Aktiwiteitsdiagram en 'n modelleringsooreenkoms begin vorm. Met inagneming van hierdie ooreenkomste, het ons in die 1ste stadium die proses in die vorm van Aktiwiteitsdiagramme beskryf, en in die 2de stadium het ons die prosesstappe geïdentifiseer waarvoor outomatisering vereis (en moontlik) is.
Laat ek jou daaraan herinner dat ons die aktiwiteit van boekhouding vir wesenlike bates, wat in hierdie prosesse ontstaan, gaan outomatiseer.
...
'n Eiland lê op die see, (E1, E2)
Daar is 'n hael op die eiland (E3, E1)
Met goue koepel kerke, (E4)
Met torings en tuine; (E5, E6)
'n Spar boom groei voor die paleis, (E7, E8)
En daaronder is 'n kristalhuis; (E9)
'n Mak eekhoring woon daar, (A1)
Ja, wat 'n avontuur! (A1)
Die eekhoring sing liedjies, (P1, A1)
Ja, hy bly aan neute peusel, (P2)
Maar neute is nie eenvoudig nie, (C1)
Alle skulpe is goudkleurig, (C2)
Die kern is suiwer smarag; (C3)
Bediendes bewaak die eekhoring, (P3, A2)
Hulle bedien haar as verskeie bediendes (P4)
En 'n klerk is aangewys (A3)
’n Streng rekening van neute is die nuus; (P5, C1)
Die weermag salueer haar; (P6, A4)
'n Muntstuk word uit die skulpe gegooi, (P7, C2, C4)
Laat hulle om die wêreld gaan; (P8)
Meisies skink smarag (P9, A5, C3)
In die stoorkamers en onderdak; (E10, E11)
...
(A.S. Pushkin "Die verhaal van tsaar Saltan, van sy glorieryke en magtige held Prins Guidon Saltanovich en die pragtige Prinses Swan", )
In hierdie voorbeeld gebruik ek die Enterprise Architect-raamwerk van 'n Australiese maatskappy [2], en tydens opleidingsessies gebruik ek [3].
Laat ek jou daaraan herinner dat daar verskillende prosesse is, jy kan bv. [4] en [5].
Vir meer besonderhede oor die toegepaste benaderings tot modellering en ontwerp, sien [6, 7].
Vir die volledige UML-spesifikasie, sien [8].
Ons is nou gereed om voort te gaan na die volgende stappe en begin met die ontwerp van die stelsel se funksionaliteit en interne organisasie. Nommering van tekeninge sal voortgaan.
Fase 3. Die outomatiese stap moet geassosieer word met 'n funksie of funksies van die stelsel
Die outomatiese stelsel (AS) wat ontwikkel word, is ontwerp om streng rekords van neute te hou, onthou jy? Vir elke gemerkte stap (sien Figuur 3, Figuur 4 ), wat ons sal outomatiseer, 'n funksionele vereiste neerskryf deur ongeveer die volgende konstruksie te gebruik: "Die stelsel moet die vermoë implementeer ..." en 'n Gebruiksgeval-diagram ontwikkel. Ons voeg nou eintlik nuwe reëls by ons modelooreenkoms. Kom ek verduidelik watter elemente ons sal gebruik.
Ons sal die "Association"-verbinding tussen die "Gebruikersrol" en die "Funksie" (Figuur 5) gebruik, dit beteken dat 'n gebruiker met hierdie rol hierdie funksie kan verrig.
Figuur 5. Gebruik 'n Assosiasie tipe verhouding
Van "Funksie" na "Vereiste" sal ons die "Implementering"-verbinding (Figuur 6) trek om te wys dat hierdie vereiste deur hierdie funksies geïmplementeer sal word; die verhouding kan "baie-tot-baie" wees, d.w.s. Een funksie kan betrokke wees by die implementering van verskeie vereistes, en meer as een funksie mag nodig wees om 'n vereiste te implementeer.
Figuur 6. Gebruik die “Implementasie” tipe verhouding
As een funksie vir die uitvoering daarvan vereis dat 'n ander funksie uitgevoer moet word, en noodwendig, sal ons die "Afhanklikheid"-verbinding met die "Sluit in" stereotipe gebruik (Figuur 7). As die uitvoering van 'n bykomende funksie onder sekere voorwaardes vereis word, sal ons die "Afhanklikheid"-verbinding met die "Verleng" stereotipe gebruik. Alles is baie maklik om te onthou: "Sluit in" is ALTYD, en "Verleng" is SOMS.
Figuur 7. Gebruik die “Afhanklikheid (insluiting)” verhouding
Gevolglik sal ons diagram iets soos hierdie lyk (Figuur 8).
Figuur 8. Gebruik-geval diagram (funksionele model van AC)
Daarbenewens word 'n Use-case-diagram gebruik om gebruikersrolle te modelleer (Figuur 9).
Figuur 9. Gebruik-geval-diagram (rolle van AS-gebruikers)
Stadium 4. Kom ons beskryf die interne organisasie van die AS deur 'n klasdiagram te gebruik
Deur inligting oor die toevoer- en afvoerartefakte van ons proses te gebruik (sien Aktiwiteitsdiagramme - Figuur 2, Figuur 3, Figuur 4), sal ons 'n klasdiagram ontwikkel. Ons sal die "Klas"-modelleringselemente en verskeie tipes verbindings tussen hulle gebruik.
Om die "heeldeel"-verwantskap te wys, sal ons 'n verwantskap van die "Aggregasie"-tipe gebruik (Figuur 10): die neut is die geheel, en die doppe en pit is die dele.
Figuur 10. Geheeldeelverhouding
As gevolg hiervan sal 'n fragment van ons diagram iets soos hierdie lyk (Figuur 11). Die klasse wat ons direk in die teksbeskrywing van die proses uitgelig het, is in kleur gemerk.
Figuur 11. Klasdiagram
Die klasdiagram is ook gebruik om ander artefakte te modelleer - nie net dié wat verband hou met die konseptuele model van die geoutomatiseerde proses van verantwoording van wesenlike bates nie, maar ook verwant aan die uitvoeringsomgewing - die omgewing (Figuur 12) en "naburige" prosesse (Figuur 13) wat die geoutomatiseerde proses kan beïnvloed, maar wat nog nie in die fokus van ons aandag is nie (ons neem aan dat die stelsel sal ontwikkel en hierdie inligting sal nuttig wees).
Figuur 12. Klasdiagram (omgewing)
Die erfverwantskap toon die veralgemening van verskeie geboue, "kind" klasse, onder die veralgemenende "ouer" klas "Gebou".
Figuur 13. Klasdiagram (bykomende inligting oor artefakte)
“Reaksie op die situasie” hang af van “Visuele beheerdata”. Vir verskeie afhanklikheidsverhoudings word die "spoor" stereotipe gebruik om die naspeuring van klasse wat nie eksplisiet in die prosesbeskrywing geïdentifiseer is nie, maar wat nodig is om dit te outomatiseer, te wys na klasse wie se gevalle eksplisiet in ons beskrywing verwys word.
Stadium 5. Kom ons ontleed die notas op die "Besigheidsreëls"-snit
Die reëls is gespesifiseer (sien Figuur 2 ):
- die behoefte om een van die stappe in 2 dele te verdeel, begin die tweede deel slegs onder sekere omstandighede uitgevoer word;
- aanstelling van 'n sekere amptenaar om die boekhouding van neute uit te voer;
- 'n tegniek (wit kleur van elemente) wat aandui dat die element nie eksplisiet in die prosesbeskrywing gespesifiseer is nie.
Daar moet kennis geneem word dat ons reeds al hierdie reëls gebruik het by die ontwikkeling van diagramme.
Slotopmerkings
So, ons het deur 5 fases gegaan en 3 tipes diagramme gebou. Ek sal 'n klein opmerking byvoeg oor die organisasie van ons modelle in die modelleringsomgewing. Daar is 'n groot aantal raamwerke wat help om die modelle wat ontwikkel word te struktureer, maar dit is nie die onderwerp van hierdie artikel nie, daarom sal ons ons beperk tot die volgende eenvoudige stel pakkette vir die ordelike bestuur van ons projek: Besigheidsproses, Funksionele Model , Artefakte, Deelnemers en Omgewing (Figuur 14).
Figuur 14. Projekpakketstruktuur
Ons het dus konsekwente modelle ontwikkel wat die materiële rekeningkundige stelsel vanuit verskeie aspekte beskryf: 'n model van 'n geoutomatiseerde besigheidsproses, 'n funksionele model en 'n model van die interne organisasie van die stelsel op konseptuele vlak.
Lys van bronne
- Webwerf "UML2.ru". Ontleder Gemeenskapsforum. Algemene afdeling. Voorbeelde. Voorbeelde van sprokies wat as UML-diagramme geformateer is. [Elektroniese hulpbron] Toegangsmodus: Internet:
- Sparx Systems webwerf. [Elektroniese hulpbron] Toegangsmodus: Internet:
- Modelio webwerf. [Elektroniese hulpbron] Toegangsmodus: Internet:
- Groot Ensiklopediese Woordeboek. Proses (interpretasie). [Elektroniese hulpbron] Toegangsmodus: Internet:
- Webwerf "Organisasie van Effektiewe Bestuur". Blog. Kategorie "Besigheidsprosesbestuur". Definisie van 'n besigheidsproses. [Elektroniese hulpbron] Toegangsmodus: Internet:
- Sertifikaat No. 18249 oor registrasie en deponering van 'n werk van intellektuele aktiwiteit. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manuskrip van 'n onderrighulpmiddel getiteld "Modelering van 'n vakgebied deur Enterprise Architect" // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Besigheidsprosesmodellering. — M.: KURSUS, SIC INFRA-M, EBS Znanium.com. — 2017.
- OMG Unified Modeling Language (OMG UML) spesifikasie. Weergawe 2.5.1. [Elektroniese hulpbron] Toegangsmodus: Internet:
Bron: will.com