„O zi din viața unei veverițe” sau de la modelarea proceselor la proiectarea unui sistem automatizat de contabilitate a bunurilor materiale „Veverița-1.0” (Partea 2)
Rezumatul episodului anterior
În am folosit domeniul „povestitor”, inspirându-ne din exemplele de studiu ale diagramelor UML bazate pe povești (vezi, de exemplu, [1]). Înainte de a începe modelarea, ne-am înțeles cu privire la utilizarea unor elemente ale diagramei Activitate și am început să formăm un acord privind modelarea. Având în vedere aceste înțelegeri, în prima etapă am descris procesul sub forma diagramelor Activitate, iar în a doua etapă am evidențiat pașii procesului pentru care se cere (și este posibilă) automatizarea.
Reamintesc că dorim să automatizăm activitatea de contabilitate a bunurilor materiale, care apare în aceste procese.
…
Insula pe mare se află, (E1, E2)
Orașul pe insulă este (E3, E1)
Cu biserici cu cupole aurite, (E4)
Cu terase și grădini; (E5, E6)
Un brad crește înaintea palatului, (E7, E8)
Iar sub el, o casă de cristal; (E9)
Veverița trăiește acolo, (A1)
Ce fantezie! (A1)
Veverița cântă melodii, (P1, A1)
Iar nucile le devorează, (P2)
Dar nucile nu sunt obișnuite, (C1)
Toate sunt cu coji aurii, (C2)
Miezul este un smarald curat; (C3)
Servitorii o păzesc pe veveriță, (P3, A2)
Îi sunt asistenți variate (P4)
Și un cleric sever i-a fost alocat (A3)
Un raport strict despre nuci; (P5, C1)
Îi aduce onoare armata; (P6, A4)
Din coji se toarnă monede, (P7, C2, C4)
Și le lasă să circule în lume; (P8)
Fetele aruncă smaralde (P9, A5, C3)
În cămările lor, și sub spud; (E10, E11)
…
(A.S. Pușkin „Povestea despre regele Saltan, despre fiul său slăvit și puternic, viteazul prinț Gvidon Saltanovici și despre frumoasa prințesă Lebăda”, )
În acest exemplu, folosesc mediu Enterprise Architect de la compania australiană [2], iar în cadrul cursurilor aplic aceste metode [3].
Reamintesc că procesele pot fi diferite, pot fi consultate, de exemplu, [4] și [5].
Pentru mai multe informații despre abordările folosite în modelare și proiectare, consultați [6, 7].
Specificația UML completă se poate găsi în. [8].
Acum suntem pregătiți să trecem la etapele următoare și să începem proiectarea funcțiilor sistemului și a organizației sale interne. Numerotarea figurilor va continua.
Etapa 3. Funcția sau funcțiile sistemului trebuie să fie corelate cu pasul automatizat
Sistemul automatizat (SA) pe care îl dezvoltăm este destinat unei contabilizări stricte a nucilor, amintiți-vă? Pentru fiecare pas dedicat (vezi Figura 3, Figura 4 ), pe care urmează să-l automatizăm, vom nota cerința funcțională, aplicând o structură similară cu „În sistem trebuie să fie implementată posibilitatea …” și vom elabora un diagramă Use-case. În prezent, completăm efectiv acordul nostru de modelare cu reguli noi. Voi explica ce elemente vom utiliza.
Între „Rolul utilizatorului” și „Funcția” vom folosi relația „Asociere” (Figura 5), aceasta înseamnă că pentru utilizatorul cu acest rol este disponibilă îndeplinirea acestei funcții.
Figura 5. Utilizarea relației de tip „Asociere”
Între „Funcție” și „Cerință” vom trasa relația „Realizare” (Figura 6), pentru a arăta că această cerință va fi realizată de aceste funcții, relația poate fi și „multe la multe”, adică o funcție poate participa la realizarea mai multor cerințe, iar pentru realizarea unei cerințe poate fi necesară mai mult de o funcție.
Figura 6. Utilizarea relației de tip „Realizare”
Dacă o funcție necesită pentru îndeplinirea sa, ca o altă funcție să fie realizată, obligatoriu, vom folosi relația „Dependență” cu stereotipul „Include” – includere (Figura 7). Dacă, însă, îndeplinirea funcției suplimentare este necesară în anumite condiții, vom folosi relația „Dependență” cu stereotipul „Extinde” – extindere. Totul este foarte ușor de reținut: „Include” – ÎNTOTDEAUNA, iar „Extinde” – OCASIONAL.
Figura 7. Utilizarea relației de tip „Dependență (includere)”
În final, diagrama noastră va arăta aproximativ așa (Figura 8).
Figura 8. Diagrama Use-case (modelul funcțional al SA)
În plus, diagrama Use-case este folosită pentru modelarea rolurilor utilizatorilor (Figura 9).
Figura 9. Diagrama Use-case (rolurile utilizatorilor SA)
Etapa 4. Vom descrie organizația internă a SA cu ajutorul diagramei claselor
Folosind informațiile despre artefactele de intrare și ieșire ale procesului nostru (vezi diagramele Activitate - Figura 2, Figura 3, Figura 4), vom dezvolta un diagramă de clase. Vom folosi elementul modelator „Clasă” și diferitele tipuri de relații dintre acestea.
Pentru a arăta relația „întreaga-parte”, vom folosi o relație de tip „Agregare” (Figura 10): miezul - acesta este întregul, iar cojile și miezul - acestea sunt părțile.
Figura 10. Relația „întreaga-parte”
În final, fragmentul nostru al diagramei va arăta aproximativ astfel (Figura 11). Culorile marchează clasele pe care le-am evidențiat direct în descrierea textului al procesului.
Figura 11. Diagramă de clase
Diagramă de clase a fost utilizată și pentru modelarea altor artefacte - nu doar cele care vor avea legătură cu modelul conceptual al procesului automatizabil de contabilizare a bunurilor materiale, ci au legătură cu mediu de execuție - mediul (Figura 12) și proceselor „vecine” (Figura 13), care pot influența procesul automatizabil, dar încă nu sunt în centrul atenției noastre (presupunem că sistemul va evolua și aceste informații se vor dovedi utile).
Figura 12. Diagramă de clase (mediu)
Relația de moștenire arată generalizarea diferitelor construcții, „subclasele” sub clasa „părinte” generalizatoare „Construcție”.
Figura 13. Diagramă de clase (informații suplimentare despre artefacte)
„Reacția la situație” depinde de „Datele de control vizual”. Pentru mai multe relații de dependență se folosește stereotipul „trace”, pentru a arăta trasarea claselor, care nu sunt explicit menționate în descrierea procesului, dar care sunt necesare pentru automatizarea acestuia, către clasele, asupra instanțelor cărora există o indicație precisă în descrierea noastră.
Etapa 5. Vom analiza notițele pe pista „Reguli de afaceri”
Regulile au fost indicate (vezi Figura 2 ):
- necesitatea de a împărți unul dintre pași în 2 părți, a doua parte fiind executată doar în anumite condiții;
- încadrarea pentru a efectua contabilizarea nucilor a unei persoane desemnate;
- un truc tehnic (culoarea albă a elementelor), care indică că elementul nu a fost specificat explicit în descrierea procesului.
Trebuie menționat că toate aceste reguli le-am folosit deja în dezvoltarea diagramelor.
Observații finale
Așadar, am parcurs 5 etape și am construit 3 tipuri de diagrame. Voi adăuga un mic comentariu despre organizarea modelului nostru în mediu de modelare. Există o mulțime de cadre care ajută la structurarea modelurilor dezvoltate, dar aceasta nu este tema acestei articole, așa că ne vom limita la un 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 pachetelor proiectului
Astfel, am dezvoltat modele coerente care descriu sistemul de contabilitate a bunurilor materiale din diferite perspective: modelul procesului de afaceri automatizat, modelul funcțional și modelul organizării interne a sistemului la nivel conceptual.
Lista surselor
- Site-ul „UML2.ru”. Forumul Comunității Analiștilor. Secțiunea generală. Exemple. Exemple de povești prezentate sub formă de diagrame UML. [Resursă electronică] Acces: Internet:
- Site-ul Sparx Systems. [Resursă electronică] Acces: Internet:
- Site-ul Modelio. [Resursă electronică] Acces: Internet:
- Marele Dicționar Enciclopedic. Proces (interpretare). [Resursă electronică] Acces: Internet:
- Site-ul „Organizarea gestionării eficiente”. Blog. Secțiunea „Gestionarea proceselor de afaceri”. Definiția procesului de afaceri. [Resursă electronică] Acces: Internet:
- Certificat nr. 18249 de înregistrare și depozitare a rezultatelor activității intelectuale. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manuscrisul manualului de studiu numit „Modelarea domeniului cu ajutorul Enterprise Architect” // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modelarea proceselor de afaceri. — M.: CURS, NIC INFRA-M, EBS Znanium.com. — 2017.
- Specificația OMG Unified Modeling Language (OMG UML). Versiunea 2.5.1. [Resursă electronică] Acces: Internet:
Sursa: habr.com
