"Ien dei yn it libben fan in iikhoarntsje" of fan prosesmodellering oant it ûntwerp fan in automatisearre rykdomboekhâldingsysteem "Belka-1.0" (diel 2)
Gearfetting fan de foarige ôflevering
В Wy brûkten in "fairy tale" domein, ynspirearre troch foarbylden fan it learen fan UML diagrammen basearre op mearke plots (sjoch, bygelyks, [1]). Foardat de modellering begon, hawwe wy it iens oer it gebrûk fan guon eleminten fan it Activity-diagram en begon in modeloerienkomst te foarmjen. Mei dizze ôfspraken yn 'e rekken, hawwe wy yn' e 1e etappe it proses beskreaun yn 'e foarm fan Aktiviteitsdiagrammen, en yn' e 2e etappe hawwe wy de prosesstappen identifisearre wêrfoar automatisearring nedich is (en mooglik).
Lit my jo herinnerje dat wy de aktiviteit fan boekhâlding foar materiële aktiva sille automatisearje, dy't ûntstiet yn dizze prosessen.
...
In eilân leit oan see, (E1, E2)
Der is in hagel op it eilân (E3, E1)
Mei tsjerken mei gouden koepels, (E4)
Mei tuorren en tunen; (E5, E6)
In sparrenbeam groeit foar it paleis, (E7, E8)
En dêrûnder is in kristalhûs; (E9)
In tamme iikhoarntsje wennet dêr, (A1)
Ja, wat in aventoer! (A1)
De iikhoarntsje sjongt ferskes, (P1, A1)
Ja, hy knibbelt hieltyd oan noten, (P2)
Mar nuten binne net ienfâldich, (C1)
Alle skulpen binne gouden, (C2)
De kearn is suver smaragd; (C3)
Feinten bewarje de iikhoarn, (P3, A2)
Se tsjinje har as ferskate feinten (P4)
En in klerk waard tawiisd (A3)
In strang rekken fan nuten is it nijs; (P5, C1)
It leger groetet har; (P6, A4)
In munt wurdt getten út 'e skulpen, (P7, C2, C4)
Lit se om 'e wrâld gean; (P8)
Meisjes pour smaragd (P9, A5, C3)
Yn 'e opslachkeamers, en ûnder dekking; (E10, E11)
...
(A.S. Poesjkin "It ferhaal fan tsaar Saltan, fan syn glorieuze en machtige held Prins Guidon Saltanovich en de prachtige prinses Swan", )
Yn dit foarbyld brûk ik it Enterprise Architect-ramt fan in Australysk bedriuw [2], en tidens training sesjes brûke ik [3].
Lit my jo herinnerje dat d'r ferskate prosessen binne, jo kinne yn 'e kunde komme, bygelyks, [4] en [5].
Foar mear details oer de tapaste oanpak foar modellering en ûntwerp, sjoch [6, 7].
Sjoch foar de folsleine UML-spesifikaasje [8].
Wy binne no ree om troch te gean nei de folgjende stappen en te begjinnen mei it ûntwerpen fan de funksjonaliteit en ynterne organisaasje fan it systeem. Nûmering fan tekeningen sil trochgean.
Stage 3. De automatisearre stap moat wurde ferbûn mei in funksje of funksjes fan it systeem
It automatisearre systeem (AS) dat wurdt ûntwikkele is ûntworpen om strikte noten te behâlden, tink? Foar elke markearre stap (sjoch figuer 3, figuer 4 ), dy't wy automatisearje, in funksjonele eask opskriuwe mei sawat de folgjende konstruksje: "It systeem moat de mooglikheid ymplementearje ..." en in Use-case-diagram ûntwikkelje. Wy foegje no eins nije regels ta oan ús modeloerienkomst. Lit my útlizze hokker eleminten wy sille brûke.
Wy sille de "Association" ferbining brûke tusken de "Brûkersrol" en de "Funksje" (figuer 5), dit betsjut dat in brûker mei dizze rol dizze funksje kin útfiere.
figuer 5. Mei help fan in Association type relaasje
Fan "Funksje" nei "Eask" sille wy de "Ymplemintaasje" ferbining tekenje (figuer 6) om sjen te litten dat dizze eask sil wurde ymplementearre troch dizze funksjes; de relaasje kin "in protte-nei-in protte" wêze, d.w.s. Ien funksje kin belutsen wêze by it útfieren fan ferskate easken, en mear as ien funksje kin nedich wêze om in eask út te fieren.
figuer 6. Mei help fan de "Ymplemintaasje" type relaasje
As ien funksje foar syn útfiering fereasket dat in oare funksje wurdt útfierd, en needsaaklikerwize sille wy de "Dependency" ferbining brûke mei de "Include" stereotype (figuer 7). As de útfiering fan in ekstra funksje ûnder bepaalde betingsten nedich is, dan sille wy de ferbining "Ofhinklikens" brûke mei it stereotype "útwreidzje". Alles is heul maklik te ûnthâlden: "Opnimme" is ALTYD, en "útwreidzje" is SOMS.
figuer 7. Mei help fan de "Ofhinklikens (ynklúzje)" relaasje
As resultaat sil ús diagram der sa útsjen (figuer 8).
Ofbylding 8. Diagram foar gebrûk (funksjoneel model fan AC)
Derneist wurdt in Use-case-diagram brûkt om brûkersrollen te modellearjen (figuer 9).
Ofbylding 9. Diagram foar gebrûk (rollen fan AS-brûkers)
Stage 4. Lit ús beskriuwe de ynterne organisaasje fan de AS mei help fan in klasse diagram
Mei help fan ynformaasje oer de ynfier- en útfierartefaten fan ús proses (sjoch Aktiviteitsdiagrammen - figuer 2, figuer 3, figuer 4), sille wy in klassediagram ûntwikkelje. Wy sille gebrûk meitsje fan de "Klasse" modellering eleminten en ferskate soarten ferbinings tusken harren.
Om de relaasje "hiel-diel" te sjen, sille wy in relaasje brûke fan it type "Aggregaasje" (figuer 10): de nut is it gehiel, en de skelpen en kearn binne de dielen.
figuer 10. Ferhâlding hiele diel
As resultaat sil in fragmint fan ús diagram der sa útsjen (figuer 11). De klassen dy't wy direkt markearre hawwe yn 'e tekstbeskriuwing fan it proses binne yn kleur markearre.
figuer 11. Klasse diagram
It klassediagram waard ek brûkt om oare artefakten te modellearjen - net allinich dejingen dy't relatearre sille wêze oan it konseptuele model fan it automatisearre proses fan rekkenjen fan materiële aktiva, mar ek relatearre oan 'e útfieringsomjouwing - it miljeu (figuer 12) en "buorjend" prosessen (figuer 13) dy't ynfloed kinne op it automatisearre proses, mar binne noch net yn 'e fokus fan ús oandacht (wy geane derfan út dat it systeem sil ûntwikkelje en dizze ynformaasje sil nuttich wêze).
Ofbylding 12. Klassediagram (omjouwing)
De erflike relaasje lit de generalisaasje sjen fan ferskate gebouwen, "bern"-klassen, ûnder de generalisearjende "âlder"-klasse "Bouwurk".
Ofbylding 13. Klassediagram (oanfoljende ynformaasje oer artefakten)
"Reaksje op 'e situaasje" hinget ôf fan "Fisuele kontrôlegegevens". Foar ferskate ôfhinklikensrelaasjes wurdt it "trace" stereotype brûkt om de tracing fan klassen sjen te litten dy't net eksplisyt identifisearre binne yn 'e prosesbeskriuwing, mar dy't nedich binne om it te automatisearjen, nei klassen wêrfan eksimplaren eksplisyt wurde ferwiisd yn ús beskriuwing.
Stage 5. Lit ús analysearje de oantekeningen op it spoar "Business Rules".
De regels waarden spesifisearre (sjoch figuer 2 ):
- de needsaak om ien fan 'e stappen yn 2 dielen te splitsen, it twadde diel begjint allinich ûnder bepaalde betingsten te wurde útfierd;
- beneaming fan in bepaalde amtner om de boekhâlding fan nuten út te fieren;
- in technyk (wite kleur fan eleminten) dy't oanjout dat it elemint waard net eksplisyt oantsjutte yn de proses beskriuwing.
Dêrby moat opmurken wurde dat wy hawwe al brûkt al dizze regels by it ûntwikkeljen fan diagrammen.
Finale opmerkingen
Dat, wy gongen troch 5 stadia en bouden 3 soarten diagrammen. Ik sil in lytse opmerking taheakje oer de organisaasje fan ús modellen yn 'e modelleringsomjouwing. D'r binne in grut oantal kaders dy't helpe om de modellen dy't wurde ûntwikkele te strukturearjen, mar dit is net it ûnderwerp fan dit artikel, dus wy sille ús beheine ta de folgjende ienfâldige set pakketten foar it oarderlik behear fan ús projekt: Business Process, Functional Model , Artifacts, Dielnimmers en Miljeu (figuer 14).
figuer 14. Project pakket struktuer
Sa hawwe wy konsekwint modellen ûntwikkele dy't it materiaal boekhâldsysteem beskriuwe út ferskate aspekten: in model fan in automatisearre bedriuwsproses, in funksjoneel model en in model fan 'e ynterne organisaasje fan it systeem op it konseptuele nivo.
List fan boarnen
- Webside "UML2.ru". Analyst Community Foarum. Algemiene seksje. Foarbylden. Foarbylden fan mearkes opmakke as UML-diagrammen. [Elektronyske boarne] Tagongsmodus: Ynternet:
- Sparx Systems webside. [Elektronyske boarne] Tagongsmodus: Ynternet:
- Modelio webside. [Elektronyske boarne] Tagongsmodus: Ynternet:
- Big Encyclopedic Dictionary. Proses (ynterpretaasje). [Elektronyske boarne] Tagongsmodus: Ynternet:
- Webside "Organisaasje fan effektyf behear". Blog. Kategory "Bedriuwsprosesbehear". Definysje fan in saaklik proses. [Elektronyske boarne] Tagongsmodus: Ynternet:
- Sertifikaat No.. 18249 op registraasje en deponearje fan in wurk fan yntellektuele aktiviteit. Alfimov R.V., Zolotukhina E.B., Krasnikova SA. Manuskript fan in learmiddel mei de titel "Modellerje in fakgebiet mei Enterprise Architect" // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Business proses modellering. - M.: KURSUS, SIC INFRA-M, EBS Znanium.com. — 2017.
- OMG Unified Modeling Language (OMG UML) Spesifikaasje. Ferzje 2.5.1. [Elektronyske boarne] Tagongsmodus: Ynternet:
Boarne: www.habr.com