"Unu tagon en la vivo de sciuro" aŭ de proceza modelado ĝis la dezajno de aŭtomatigita riĉa kontada sistemo "Belka-1.0" (Parto 2)
Resumo de la antaŭa epizodo
В Ni uzis domajnon "fabelo", inspirita de ekzemploj de lernado de UML-diagramoj bazitaj sur fabelintrigoj (vidu, ekzemple, [1]). Antaŭ ol la modelado komenciĝis, ni konsentis pri la uzo de kelkaj elementoj de la Agaddiagramo kaj komencis formi modeligan interkonsenton. Konsiderante ĉi tiujn interkonsentojn, en la 1-a etapo ni priskribis la procezon en la formo de Agaddiagramoj, kaj en la 2-a etapo ni identigis la procezajn paŝojn por kiuj aŭtomatigo estas postulata (kaj ebla).
Mi memorigu vin, ke ni aŭtomatigos la agadon de kontado de materialaj aktivoj, kiu ŝprucas en ĉi tiuj procezoj.
...
Insulo kuŝas sur la maro, (E1, E2)
Estas hajlo sur la insulo (E3, E1)
Kun or-kupolhavaj preĝejoj, (E4)
Kun turoj kaj ĝardenoj; (E5, E6)
Piceo kreskas antaŭ la palaco, (E7, E8)
Kaj malsupre estas kristala domo; (E9)
Malsovaĝa sciuro loĝas tie, (A1)
Jes, kia aventuro! (A1)
La sciuro kantas kantojn, (P1, A1)
Jes, li daŭre mordetas nuksojn, (P2)
Sed nuksoj ne estas simplaj, (C1)
Ĉiuj konkoj estas oraj, (C2)
La kerno estas pura smeraldo; (C3)
Servistoj gardas la sciuron, (P3, A2)
Ili servas ŝin kiel diversaj servistoj (P4)
Kaj komizo estis asignita (A3)
Strikta konto pri nuksoj estas la novaĵo; (P5, C1)
La armeo salutas ŝin; (P6, A4)
Monero estas verŝita el la konkoj, (P7, C2, C4)
Lasu ilin iri tra la mondo; (P8)
Knabinoj verŝas smeraldon (P9, A5, C3)
En la provizejojn, kaj sub kovrilo; (E10, E11)
...
(A.S. Puŝkin "La Rakonto de Caro Saltan, de lia glora kaj potenca heroo Princo Guidon Saltanovich kaj la bela Princino Cigno", )
En ĉi tiu ekzemplo mi uzas la kadron Enterprise Architect de aŭstralia kompanio [2], kaj dum trejnaj kunsidoj mi uzas [3].
Mi memorigu vin, ke ekzistas malsamaj procezoj, vi povas konatiĝi, ekzemple, [4] kaj [5].
Por pliaj detaloj pri la aplikataj aliroj al modelado kaj dezajno, vidu [6, 7].
Por la kompleta UML-specifo, vidu [8].
Ni nun pretas pasi al la sekvaj paŝoj kaj komenci desegni la funkciecon kaj internan organizon de la sistemo. Numerado de desegnaĵoj daŭros.
Etapo 3. La aŭtomatigita paŝo devas esti asociita kun funkcio aŭ funkcioj de la sistemo
La aŭtomatigita sistemo (AS) disvolvita estas desegnita por konservi striktajn rekordojn de nuksoj, ĉu vi memoras? Por ĉiu emfazita paŝo (vidu Figuro 3, Figuro 4 ), kiun ni aŭtomatigos, skribu funkcian postulon uzante proksimume la sekvan konstruon: "La sistemo devas efektivigi la kapablon..." kaj evoluigi Uzkazan diagramon. Ni nun efektive aldonas novajn regulojn al nia modeliga interkonsento. Mi klarigu, kiajn elementojn ni uzos.
Ni uzos la ligon "Asocio" inter la "Uzanto-Rolo" kaj la "Funkcio" (Figuro 5), tio signifas, ke uzanto kun ĉi tiu rolo povas plenumi ĉi tiun funkcion.
Figuro 5. Uzante Asocio-tipan rilaton
De "Funkcio" al "Kondiĉo" ni desegnos la ligon "Efektivigo" (Figuro 6) por montri, ke ĉi tiu postulo estos efektivigita per ĉi tiuj funkcioj; la rilato povas esti "multaj-al-multaj", t.e. Unu funkcio povas esti implikita en efektivigado de pluraj postuloj, kaj pli ol unu funkcio povas esti necesa por efektivigi postulon.
Figuro 6. Uzante la "Efektivigo" tipo-rilato
Se unu funkcio postulas por sia ekzekuto ke iu alia funkcio estu ekzekutita, kaj nepre, ni uzos la "Dependeco" ligon kun la "Inkluzivi" stereotipo (Figuro 7). Se la ekzekuto de plia funkcio estas postulata sub certaj kondiĉoj, tiam ni uzos la ligon "Dependeco" kun la stereotipo "Etendu". Ĉio estas tre facile memorebla: "Inkluzivi" estas ĈIAM, kaj "Etendu" foje.
Figuro 7. Uzante la rilaton "Dependeco (inkludo)".
Kiel rezulto, nia diagramo aspektos kiel ĉi tio (Figuro 8).
Figuro 8. Uzokaza diagramo (funkcia modelo de AC)
Krome, Uzokaza diagramo estas uzata por modeligi uzantrolojn (Figuro 9).
Figuro 9. Uzokaza diagramo (roloj de AS-uzantoj)
Etapo 4. Ni priskribu la internan organizon de la AS uzante klasdiagramon
Uzante informojn pri la enigo kaj eligo artefaktoj de nia procezo (vidu Agaddiagramoj - Figuro 2, Figuro 3, Figuro 4), ni disvolvos klasdiagramon. Ni uzos la "Klaso" modelajn elementojn kaj diversajn specojn de ligoj inter ili.
Por montri la "tut-parton" rilaton, ni uzos rilaton de la "Agregation" tipo (Figuro 10): la nukso estas la tuto, kaj la ŝeloj kaj kerno estas la partoj.
Figuro 10. Tutparta rilato
Kiel rezulto, fragmento de nia diagramo aspektos kiel ĉi tio (Figuro 11). La klasoj, kiujn ni elstarigis rekte en la teksta priskribo de la procezo, estas markitaj en koloro.
Figuro 11. Klasdiagramo
La klasdiagramo ankaŭ estis uzata por modeligi aliajn artefaktojn - ne nur tiujn, kiuj estos rilataj al la koncipa modelo de la aŭtomatigita procezo de kontado de materialaj aktivoj, sed ankaŭ rilataj al la ekzekuta medio - la medio (Figuro 12) kaj "najbara" procezoj (Figuro 13) kiuj povas influi la aŭtomatigitan procezon, sed ankoraŭ ne estas en la fokuso de nia atento (ni supozas, ke la sistemo evoluos kaj ĉi tiu informo estos utila).
Figuro 12. Klasdiagramo (medio)
La hereda rilato montras la ĝeneraligo de diversaj konstruaĵoj, "infanaj" klasoj, sub la ĝeneraliganta "gepatro" klaso "Konstruaĵo".
Figuro 13. Klasdiagramo (pliaj informoj pri artefaktoj)
"Reago al la situacio" dependas de "Vidaj kontrolaj datumoj". Por pluraj dependecrilatoj, la "spuro" stereotipo estas uzata por montri la spuron de klasoj ne eksplicite identigitaj en la procezpriskribo, sed kiuj estas necesaj por aŭtomatigi ĝin, al klasoj kies okazoj estas eksplicite referencitaj en nia priskribo.
Etapo 5. Ni analizu la notojn pri la trako "Komercaj Reguloj".
La reguloj estis precizigitaj (vidu Figuro 2 ):
- la bezono dividi unu el la paŝoj en 2 partojn, la dua parto komenciĝas nur sub iuj kondiĉoj;
- nomumo de certa oficisto por plenumi la kontadon de nuksoj;
- tekniko (blanka koloro de elementoj) kiu indikas ke la elemento ne estis eksplicite precizigita en la procezpriskribo.
Oni devas rimarki, ke ni jam uzis ĉiujn ĉi tiujn regulojn dum disvolvado de diagramoj.
Finaj rimarkoj
Do, ni trapasis 5 stadiojn kaj konstruis 3 specojn de diagramoj. Mi aldonos etan komenton pri la organizado de niaj modeloj en la modela medio. Estas granda nombro da kadroj, kiuj helpas strukturi la evoluajn modelojn, sed ĉi tio ne estas la temo de ĉi tiu artikolo, do ni limigos nin al la sekva simpla aro da pakaĵoj por la orda administrado de nia projekto: Komerca Procezo, Funkcia Modelo. , Artefaktoj, Partoprenantoj kaj Medio (Figuro 14).
Figuro 14. Projekta pakaĵstrukturo
Tiel, ni evoluigis konsekvencajn modelojn, kiuj priskribas la materialan kontadan sistemon de diversaj aspektoj: modelo de aŭtomatigita komerca procezo, funkcia modelo kaj modelo de la interna organizo de la sistemo ĉe la koncipa nivelo.
Listo de fontoj
- Retejo "UML2.ru". Komunuma Forumo de Analizistoj. Ĝenerala sekcio. Ekzemploj. Ekzemploj de fabeloj formatitaj kiel UML-diagramoj. [Elektronika rimedo] Alirmaniero: Interreto:
- Sparx Systems retejo. [Elektronika rimedo] Alirmaniero: Interreto:
- Modelio retejo. [Elektronika rimedo] Alirmaniero: Interreto:
- Granda Enciklopedia Vortaro. Procezo (interpreto). [Elektronika rimedo] Alirmaniero: Interreto:
- Retejo "Organizo de Efika Administrado". Blogo. Kategorio "Komerca Proceza Administrado". Difino de komerca procezo. [Elektronika rimedo] Alirmaniero: Interreto:
- Atestilo n-ro 18249 pri registrado kaj deponado de verko de intelekta agado. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manuskripto de instruhelpo titolita "Modeligado de fako uzante Enterprise Architect" // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Komercproceza modeligado. — M.: KURSO, SIC INFRA-M, EBS Znanium.com. — 2017.
- Specifo de OMG Unified Modeling Language (OMG UML). Versio 2.5.1. [Elektronika rimedo] Alirmaniero: Interreto:
fonto: www.habr.com