„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 1)
Ce legătură are „veverița” cu ea?
Permiteți-mi să explic imediat ce legătură are „veverița” cu ea. După ce am întâlnit proiecte distractive pe Internet pentru a învăța UML pe baza unui domeniu împrumutat din basme (de exemplu, [1]), am decis, de asemenea, să pregătesc un exemplu similar pentru studenții mei, astfel încât să poată studia doar trei tipuri de diagrame pentru început: Diagrama activității, Diagrama cazurilor de utilizare și Diagrama clasei. Nu traduc în mod deliberat numele diagramelor în rusă pentru a evita disputele despre „dificultăți de traducere”. Voi explica pentru ce este un pic mai târziu. În acest exemplu, folosesc cadrul Enterprise Architect de la o companie australiană [2] – un instrument bun la un preț rezonabil. Și ca parte a sesiunilor mele de antrenament le folosesc [3], un bun instrument gratuit de proiectare orientată pe obiecte care acceptă standardele UML2.0 și BPMN, fără clopoței și fluiere inutile în ceea ce privește capacitățile vizuale, dar destul de suficient pentru a învăța elementele de bază ale limbajului.
Urmează să automatizăm activitatea de contabilizare 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ă”, — 10 ani de la concept până la publicare, apropo!)
Câteva despre codurile care sunt scrise în dreapta rândurilor. „A” (de la „Actor”) înseamnă că linia conține informații despre un participant la proces. „C” (din „Class”) – informații despre obiectele de clasă care sunt procesate în timpul execuției proceselor. „E” (din „Environment”) – informații despre obiectele de clasă care caracterizează mediul de execuție a proceselor. „P” (din „Proces”) – informații despre procesele în sine.
Apropo, definirea exactă a unui proces pretinde a fi și cauza unor dispute metodologice, fie și doar datorită faptului că există procese diferite: de afaceri, de producție, tehnologice etc. și așa mai departe. (puteți afla, de exemplu, [4] și [5]). Pentru a evita controversele, să fim de acord Suntem interesați de proces din punct de vedere al repetabilității acestuia în timp și al necesității de automatizare, adică transferarea execuției oricărei părți a operațiunilor procesului într-un sistem automatizat.
Note despre utilizarea diagramei de activitate
Să începem să modelăm procesul nostru și să folosim diagrama de activitate pentru aceasta. Mai întâi, permiteți-mi să explic cum vor fi utilizate codurile de mai sus în model. Este mai ușor de explicat cu un exemplu grafic, dar în același timp vom analiza câteva (aproape toate cele de care avem nevoie) elemente ale diagramei de activitate.
Să analizăm următorul fragment:
...
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)
...
Avem două etape de proces P1 și P2, participantul A1 și obiecte din trei clase diferite: un obiect din clasa C1 este introdus în pas, obiectele din clasele C2 și C3 sunt scoase ca rezultat al activității acestui pas P2 al nostru. proces. Pentru diagramă folosim următoarele elemente de modelare.
Un fragment din procesul nostru poate fi reprezentat cam așa (Figura 1).
Figura 1. Fragment diagramă de activitate
Pentru organizarea spațiului și structura diagramei de activitate, vom folosi o abordare non-standard, din punctul de vedere al utilizării clasice a notației UML. Dar există mai multe motive pentru aceasta. În primul rând, chiar înainte de a începe modelarea, vom compila așa-numitul acord de modelare, în care înregistrăm toate caracteristicile utilizării notației. În al doilea rând, această abordare a fost aplicată în mod repetat cu succes în stadiul de modelare a afacerilor în proiecte reale pentru a crea sisteme software, rezultatele au fost înregistrate de către mica noastră echipă de autori în obiectul de drepturi de autor corespunzător [6], și au fost, de asemenea, utilizate într-un manual de instruire [; 7]. Pentru diagrama de activitate, definim că câmpul diagramei este structurat folosind „culori de înot”. Numele pistei va corespunde tipului de elemente de diagramă care vor fi plasate pe pista respectivă.
„Artefacte de intrare și de ieșire”: Această pistă va conține elemente Objects - obiecte care sunt utilizate sau sunt rezultatul executării unui pas de proces.
„Pașii procesului”: Aici vom plasa elementele de activitate - acțiunile participanților la proces.
„Participanți”: o cale pentru elemente care vor denota rolurile actorilor de acțiune în procesul nostru, vom folosi același element de modelare Object - un obiect, dar îi vom adăuga stereotipul „Actor”.
Următoarea piesă se numește "Reguli de afaceri" iar pe această pistă vom plasa sub formă de text regulile de executare a pașilor procesului, iar pentru aceasta vom folosi elementul de modelare Notă - o notă.
Ne vom opri aici, deși am putea folosi și poteca "Unelte" pentru a colecta informații despre nivelul de automatizare a procesului. O cale ar putea fi, de asemenea, utilă „Pozițiile și diviziunile participanților”, poate fi folosit pentru a lega roluri la pozițiile și departamentele participanților la proces.
Tot ceea ce tocmai am descris este un fragment convenții de modelare, această parte a acordului se referă la regulile de organizare a unei diagrame și, în consecință, regulile de scriere și citire a acesteia.
"Reţetă"
Acum să luăm în considerare opțiunea de modelare a sistemului în mod specific din diagrama de activitate. Aceasta este doar una dintre opțiuni, remarc că, desigur, nu este singura. Diagrama de activitate ne va interesa din punctul de vedere al rolului său în trecerea de la modelarea proceselor la proiectarea unui sistem automatizat. Pentru a face acest lucru, vom adera la recomandările metodologice - un fel de rețetă constând din doar cinci etape și care prevede dezvoltarea a doar trei tipuri de diagrame. Folosirea acestei rețete ne va ajuta să obținem o descriere oficială a procesului pe care dorim să îl automatizăm și să colectăm date pentru proiectarea sistemului. Și pentru studenții de la începutul studiului UML, acesta este un fel de salvare care nu le va permite să se înece în toată varietatea de mijloace și tehnici vizuale care se găsesc în UML și instrumentele moderne de modelare.
Iată, de fapt, rețeta în sine și apoi urmați diagramele construite pentru domeniul nostru de subiect „de basm”.
Etapa 1. Descriem procesul sub forma unei diagrame de activitate. Pentru un proces cu mai mult de 10 pași, este logic să se aplice principiul de descompunere a etapelor de proces pentru a îmbunătăți lizibilitatea diagramei.
Etapa 2. Selectați ceea ce poate fi automatizat (pașii pot fi evidențiați pe o diagramă, de exemplu).
Etapa 3. Pasul automatizat trebuie să fie asociat cu o funcție sau funcții ale sistemului (relația poate fi multi-la-mulți), desenați o diagramă de caz de utilizare. Acestea sunt funcțiile sistemului nostru.
Etapa 4. Să descriem organizarea internă a AS folosind o diagramă de clase - Clasa. Canalul de înot „Obiecte de intrare și ieșire (documente)” din diagrama de activitate este baza pentru construirea unui model de obiect și a unui model de entitate-relație.
Etapa 5. Să analizăm notele de pe piesa „Reguli de afaceri”., acestea oferă diverse tipuri de restricții și condiții, care se transformă treptat în cerințe nefuncționale.
Setul de diagrame rezultat (Activitate, Caz de utilizare, Clasă) ne oferă o descriere formalizată într-o notație destul de strictă, i.e. are o lectură lipsită de ambiguitate. Acum puteți dezvolta specificații tehnice, clarifica specificațiile cerințelor etc.
Să începem să modelăm.
Etapa 1. Descrieți procesul sub forma unei diagrame de activitate
Permiteți-mi să vă reamintesc că am structurat câmpul diagramei folosind benzi de „înot” fiecare bandă conține elemente de același tip (Figura 2). Pe lângă elementele de diagramă descrise mai sus, vom folosi elemente suplimentare, să le descriem.
Decizia (Decizia) denotă punctul de ramificare al procesului nostru în diagramă, iar firele de îmbinare (Merge) – punctul reunificării lor. Condițiile de tranziție sunt scrise între paranteze drepte pe tranziții.
Între două sincronizatoare (Fork) vom afișa ramuri de proces paralele.
Procesul nostru poate avea un singur început - un punct de intrare (inițial). Dar pot exista mai multe completări (finale), dar nu pentru diagrama noastră specifică.
Există destul de multe săgeți cu un număr mare de elemente și conexiuni, puteți identifica mai întâi etapele procesului și apoi efectuați o descompunere a acestor etape. Dar pentru claritate, aș dori să arăt procesul nostru „de basm” în întregime pe o singură diagramă, în timp ce, desigur, trebuie să ne asigurăm că săgețile „nu se lipesc împreună”, ar fi posibil să urmărim cu exactitate ceea ce este conectat. la ce.
Figura 2. Diagrama de activitate - vedere generală a procesului
Deoarece în rândurile poetice se omit unele detalii ale procesului, trebuiau restaurate, sunt prezentate prin elemente cu fond alb. Aceste detalii includ pasul Transfer/Recepție pentru stocare și procesare și câteva artefacte de intrare și ieșire. Este demn de remarcat faptul că, de asemenea, acest pas nu dezvăluie pe deplin procesul, deoarece ar trebui să desemnăm separat etapa de transmisie și etapa de recepție și chiar să adăugăm un pas separat pentru cochilii și, de asemenea, să ne gândim că mai întâi toate aceste valori materiale ar trebui să fie stocate temporar undeva etc. și așa mai departe.
Să remarcăm, de asemenea, că întrebarea cu privire la originea nucilor rămâne fără răspuns - de unde vin și cum ajung la veveriță? Și această întrebare (este evidențiată cu font roșu în notă - elementul Notă) necesită un studiu separat! Așa funcționează un analist - culegând informații bit cu bit, făcând ipoteze și primind „bine” sau „nu-ok” de la experți în domeniu - oameni foarte importanți și pur și simplu de neînlocuit în stadiul modelării afacerii atunci când creează sisteme.
Rețineți, de asemenea, că etapa de proces P5 constă din două părți.
Și vom descompune fiecare parte și o vom considera mai detaliat (Figura 3, Figura 4), deoarece activitățile efectuate în cadrul acestor pași anume vor fi automatizate.
Figura 3. Diagrama activității - detaliere (partea 1)
Figura 4. Diagrama activității - detaliere (partea 2)
Etapa 2. Selectați ceea ce poate fi automatizat
Pașii de automatizat sunt evidențiați color pe diagrame (vezi Figura 3, Figura 4).
Toate acestea sunt efectuate de un participant la proces - Grefierul:
- Introduce informații despre greutatea nucii în declarație;
- Introduce informații despre transferul nucilor în declarație;
- Înregistrează faptul transformării unei nuci în coajă și miez;
- Introduce informații despre miezul de nuci în declarație;
- Introduce informații despre cojile de nuci în listă.
Analiza muncii depuse. Ce urmeaza?
Deci, am făcut multă muncă pregătitoare: am colectat informații despre procesul pe care urmează să-l automatizăm; a început să formeze un acord privind modelarea (până acum doar în ceea ce privește utilizarea Diagramei de activitate); a efectuat o simulare a procesului și chiar a descompus câțiva dintre pașii acestuia; Am identificat pașii procesului pe care îi vom automatiza. Acum suntem gata să trecem la următorii pași și să începem să proiectăm funcționalitatea și organizarea internă a sistemului.
După cum știți, teoria fără practică este nimic. Cu siguranță ar trebui să încercați „modeling” cu propriile mâini, acest lucru este util și pentru înțelegerea abordării propuse. De exemplu, puteți lucra într-un mediu de modelare [3]. Am descompus doar o parte din etapele diagramei generale a procesului (vezi Figura 2). Ca sarcină practică, vi se poate cere să repetați toate diagramele din mediul Modelio și să efectuați o descompunere a pasului „Transfer/Recepție pentru stocare și procesare”.
Nu ne gândim încă să lucrăm în medii specifice de modelare, dar acest lucru poate deveni subiectul unor articole și recenzii independente.
În cea de-a doua parte a articolului, vom analiza tehnicile de modelare și proiectare necesare în etapele 3-5, vom folosi diagramele de utilizare UML și de clasă. Va urma.
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.
Sursa: www.habr.com