„O zi din viața unei veverițe” sau de la modelarea proceselor până la proiectarea unui sistem automat de contabilitate a averii „Belka-1.0” (Partea 2)
Rezumatul episodului anterior
В Am folosit un domeniu „de basm”, inspirat de exemple de învățare a diagramelor UML bazate pe comploturi de basm (vezi, de exemplu, [1]). Înainte de a începe modelarea, am convenit asupra utilizării unor elemente ale Diagramei de activitate și am început să formăm un acord de modelare. Ținând cont de aceste acorduri, la prima etapă am descris procesul sub formă de Diagrame de activitate, iar la a 1-a etapă am identificat etapele procesului pentru care este necesară (și posibilă) automatizarea.
Permiteți-mi să vă reamintesc că vom automatiza activitatea de contabilitate a activelor materiale, care ia naștere în aceste procese.
...
O insulă se află pe mare, (E1, E2)
Este grindină pe insulă (E3, E1)
Cu biserici cu cupolă aurie, (E4)
Cu turnuri și grădini; (E5, E6)
Un molid crește în fața palatului, (E7, E8)
Iar dedesubt e o casă de cristal; (E9)
O veveriță îmblânzită trăiește acolo, (A1)
Da, ce aventură! (A1)
Veverița cântă cântece, (P1, A1)
Da, tot ciugulește nuci, (P2)
Dar nucile nu sunt simple, (C1)
Toate cochiliile sunt aurii, (C2)
Miezul este smarald pur; (C3)
Slujitorii păzesc veverița, (P3, A2)
Ei o servesc ca diverși servitori (P4)
Și a fost desemnat un funcționar (A3)
O relatare strictă a nucilor este știrea; (P5, C1)
Oastea o salută; (P6, A4)
Se toarnă o monedă din scoici, (P7, C2, C4)
Lasă-i să meargă în jurul lumii; (P8)
Fetele toarnă smarald (P9, A5, C3)
În magazii și sub acoperire; (E10, E11)
...
(A.S. Pușkin „Povestea țarului Saltan, a eroului său glorios și puternic Prințul Guidon Saltanovici și a frumoasei prințese lebădă”, )
În acest exemplu, folosesc cadrul Enterprise Architect de la o companie australiană [2], iar în timpul sesiunilor de antrenament folosesc [3].
Permiteți-mi să vă reamintesc că există procese diferite, puteți face cunoștință, de exemplu, [4] și [5].
Pentru mai multe detalii despre abordările aplicate la modelare și proiectare, vezi [6, 7].
Pentru specificația UML completă, consultați [8].
Acum suntem gata să trecem la următorii pași și să începem să proiectăm funcționalitatea și organizarea internă a sistemului. Numerotarea desenelor va continua.
Etapa 3. Pasul automatizat trebuie să fie asociat cu o funcție sau funcții ale sistemului
Sistemul automatizat (AS) dezvoltat este conceput pentru a menține evidențe stricte ale nucilor, vă amintiți? Pentru fiecare pas evidențiat (vezi Figura 3, Figura 4 ), pe care o vom automatiza, notăm o cerință funcțională folosind aproximativ următoarea construcție: „Sistemul trebuie să implementeze capacitatea...” și dezvoltăm o diagramă de caz de utilizare. Acum adăugăm noi reguli la acordul nostru de modelare. Permiteți-mi să vă explic ce elemente vom folosi.
Vom folosi conexiunea „Asociere” între „Rolul utilizator” și „Funcția” (Figura 5), aceasta înseamnă că un utilizator cu acest rol poate îndeplini această funcție.
Figura 5. Utilizarea unei relații de tip Asociere
De la „Funcție” la „Cerință” vom desena conexiunea „Implementare” (Figura 6) pentru a arăta că această cerință va fi implementată de aceste funcții; relația poate fi „mulți-la-mulți”, adică. O funcție poate fi implicată în implementarea mai multor cerințe și poate fi necesară mai mult de o funcție pentru a implementa o cerință.
Figura 6. Utilizarea relației de tip „Implementare”.
Dacă o funcție necesită pentru execuție ca o altă funcție să fie executată și neapărat, vom folosi conexiunea „Dependență” cu stereotipul „Include” (Figura 7). Dacă executarea unei funcții suplimentare este necesară în anumite condiții, atunci vom folosi conexiunea „Dependență” cu stereotipul „Extend”. Totul este foarte ușor de reținut: „Include” este ÎNTOTDEAUNA, iar „Extinde” este UNEATEA.
Figura 7. Utilizarea relației „Dependență (incluziune)”.
Ca rezultat, diagrama noastră va arăta cam așa (Figura 8).
Figura 8. Diagrama de caz de utilizare (modelul funcțional al AC)
În plus, o diagramă de caz de utilizare este utilizată pentru a modela rolurile utilizatorilor (Figura 9).
Figura 9. Diagrama cazurilor de utilizare (rolurile utilizatorilor AS)
Etapa 4. Să descriem organizarea internă a AS folosind o diagramă de clase
Folosind informații despre artefactele de intrare și de ieșire ale procesului nostru (vezi Diagramele de activitate - Figura 2, Figura 3, Figura 4), vom dezvolta o diagramă de clasă. Vom folosi elementele de modelare „Clasă” și diverse tipuri de conexiuni între ele.
Pentru a arăta relația „întreaga parte”, vom folosi o relație de tip „Agregare” (Figura 10): nuca este întregul, iar cojile și miezul sunt părțile.
Figura 10. Relația între părți
Ca rezultat, un fragment din diagrama noastră va arăta cam așa (Figura 11). Clasele pe care le-am evidențiat direct în descrierea textului procesului sunt marcate color.
Figura 11. Diagrama de clasă
Diagrama de clasă a fost folosită și pentru modelarea altor artefacte - nu numai cele care vor fi legate de modelul conceptual al procesului automat de contabilizare a activelor materiale, ci și legate de mediul de execuție - mediul (Figura 12) și „învecinat” procese (Figura 13) care pot influența procesul automatizat, dar nu sunt încă în centrul atenției noastre (presupunem că sistemul se va dezvolta și că aceste informații vor fi utile).
Figura 12. Diagrama de clasă (mediu)
Relația de moștenire arată generalizarea diferitelor clădiri, clase „copil”, sub clasa „părinte” generalizantă „Clădire”.
Figura 13. Diagrama de clasă (informații suplimentare despre artefacte)
„Reacția la situație” depinde de „Date de control vizual”. Pentru mai multe relații de dependență, stereotipul „urme” este folosit pentru a arăta urmărirea claselor neidentificate explicit în descrierea procesului, dar care sunt necesare pentru a-l automatiza, la clase ale căror instanțe sunt menționate explicit în descrierea noastră.
Etapa 5. Să analizăm notele de pe piesa „Reguli de afaceri”.
Au fost specificate regulile (vezi Figura 2 ):
- necesitatea împărțirii unuia dintre pași în 2 părți, a doua parte începe să fie executată numai în anumite condiții;
- numirea unui anumit funcționar care să efectueze contabilitatea nucilor;
- o tehnică (culoarea albă a elementelor) care indică faptul că elementul nu a fost specificat în mod explicit în descrierea procesului.
Trebuie remarcat faptul că am folosit deja toate aceste reguli la elaborarea diagramelor.
Observații finale
Deci, am trecut prin 5 etape și am construit 3 tipuri de diagrame. Voi adăuga un mic comentariu despre organizarea modelelor noastre în mediul de modelare. Există un număr mare de cadre care ajută la structurarea modelelor în curs de dezvoltare, dar acesta nu face obiectul acestui articol, așa că ne vom limita la următorul set simplu de pachete pentru gestionarea ordonată a proiectului nostru: Proces de afaceri, Model funcțional , Artefacte, Participanți și Mediu (Figura 14).
Figura 14. Structura pachetului de proiect
Astfel, am dezvoltat modele consistente care descriu sistemul de contabilitate materială din diverse aspecte: un model de proces automatizat de afaceri, un model funcțional și un model de organizare internă a sistemului la nivel conceptual.
Lista surselor
- Site-ul web „UML2.ru”. Forumul comunității analiștilor. Sectiunea generala. Exemple. Exemple de basme formatate ca diagrame UML. [Resursă electronică] Mod de acces: Internet:
- Site-ul Sparx Systems. [Resursă electronică] Mod de acces: Internet:
- Site-ul Modelio. [Resursă electronică] Mod de acces: Internet:
- Dicţionar enciclopedic mare. Proces (interpretare). [Resursă electronică] Mod de acces: Internet:
- Site-ul „Organizarea managementului eficient”. Blog. Categoria „Managementul proceselor de afaceri”. Definirea unui proces de afaceri. [Resursă electronică] Mod de acces: Internet:
- Certificat nr. 18249 privind înregistrarea și depunerea unei opere de activitate intelectuală. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manuscrisul unui material didactic intitulat „Modelarea unui domeniu cu ajutorul Enterprise Architect” // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modelarea proceselor de afaceri. — M.: CURS, SIC INFRA-M, EBS Znanium.com. — 2017.
- Specificații OMG Unified Modeling Language (OMG UML). Versiunea 2.5.1. [Resursă electronică] Mod de acces: Internet:
Sursa: www.habr.com