„O zi din viața unei veverițe” sau de la modelarea proceselor la proiectarea unui sistem automatizat de contabilitate a bunurilor „Veverița-1.0” (Partea 1)
Ce legătură are „veverița”?
O să explic imediat ce legătură are „veverița”. Dând peste proiecte amuzante pe internet pentru a studia UML bazate pe domenii extrase din povești (de exemplu, [1]), am decis și eu să pregătesc un exemplu similar pentru studenții mei, astfel încât să poată studia inițial trei tipuri de diagrame: Diagrama de Activitate, Diagrama de Caz de Utilizare și Diagrama de Clasă. Nu traduc numele diagramelor în limba română, pentru a evita dispute cu privire la „dificultățile traducerii”. Ce reprezintă fiecare – voi explica puțin mai târziu. În acest exemplu, folosesc mediul Enterprise Architect de la compania australiană [2] – un instrument bun la un preț rezonabil. În cadrul cursurilor de studiu, aplic [3], un instrument gratuit decent de proiectare orientată pe obiecte, care suportă standardele UML2.0 și BPMN, fără funcții excesive în ceea ce privește posibilitățile grafice, dar suficient de bun pentru a învăța conceptele de bază ale limbajului.
Ne propunem 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 voievod prințul Gvidon Saltanovici și despre frumoasa prințesă Lebăda”, — 10 ani de la idee până la publicare, apropo!)
Puțin despre codurile scrise în partea dreaptă a rândurilor. „A” (de la „Actor”) înseamnă că în rând se găsește informația despre participantul la proces. „C” (de la „Class”) – informația despre obiectele claselor, care sunt procesate în timpul derulării proceselor. „E” (de la „Environment”) – informația despre obiectele claselor, care caracterizează mediul de derulare a proceselor. „P” (de la „Process”) – informația despre procesele în sine.
Apropo, definiția exactă a procesului pretinde de asemenea să devină cauza unor dispute metodologice, cel puțin din cauza faptului că procesele sunt variate: de afaceri, de producție, tehnologice etc. (se poate consulta, de exemplu, [4] și [5]). Pentru a evita polemica, să convenim că ne interesează procesul din perspectiva repetabilității sale în timp și a necesității de automatizare, adică delegarea execuției unei părți din operațiunile procesului către un sistem automatizat.
Note despre aplicarea diagramei Activity
Să începem modelarea procesului nostru și să folosim pentru aceasta diagrama Activity. La început, voi explica cum vor fi folosite codurile menționate mai sus în model. Este mai simplu de explicat printr-un exemplu grafic și, de asemenea, vom analiza unele (aproape toate cele necesare nouă) elemente ale diagramei Activity.
Să analizăm fragmentul următor:
…
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)
…
Avem două etape ale procesului P1 și P2, participantul A1 și obiecte din trei clase diferite: un obiect din clasa C1 intră în etapa, iar obiectele din clasele C2 și C3 sunt obținute la ieșire, ca rezultat al activității acestei etape P2 a procesului nostru. Folosim următoarele elemente de modelare pentru diagramă.
Fragmentul procesului nostru poate fi reprezentat aproximativ astfel (Figura 1).
Figura 1. Fragmentul diagramei Activity
Pentru a organiza spațiul și a structura diagrama Activity, vom aplica o abordare nu tocmai standard, din perspectiva utilizării clasice a notării UML. Dar sunt câteva motive pentru aceasta. În primul rând, înainte de a începe modelarea, vom elabora așa numitul acord de modelare, în care vom înregistra toate specificitățile utilizării notării. În al doilea rând, această abordare a fost aplicată cu succes în repetate rânduri în etapa de modelare de afaceri în proiecte reale de dezvoltare a sistemelor software, rezultatele fiind înregistrate de către colectivul nostru mic de autori în obiectul corespunzător al dreptului de autor [6], precum și utilizate în manualul didactic [7]. Pentru diagrama Activity, vom defini că domeniul diagramei este structurat folosind „benzi flotante” – Swim lanes. Numele benzii va corespunde tipului elementelor diagramei care vor fi plasate pe această bandă.
„Artefacte de intrare și ieșire”: Pe această bandă vor fi plasate elementele Objects – obiecte care sunt folosite sau sunt rezultatul executării unui anumit pas din proces.
„Pașii procesului”: aici vom plasa elementele Activity – acțiunile participanților la proces.
„Participanți”: bandă pentru elementele care vor reprezenta rolurile executorilor acțiunilor în procesul nostru, pentru aceștia vom folosi același element de modelare Object – obiect, dar îi vom adăuga stereotipul „Actor”.
Următoarea bandă se numește „Reguli de afaceri” și pe această bandă vom plasa în format text regulile de executare a pașilor procesului, iar pentru aceasta vom folosi elementul de modelare Note – notă.
Ne vom opri aici, deși ar fi posibil să folosim suplimentar banda „Instrumente” pentru a aduna informații despre nivelul de automatizare a procesului. Ar putea fi de folos banda „Funcții și departamente ale participanților”, care poate fi folosită pentru a conecta rolurile cu funcțiile și departamentele participanților la proces.
Tot ceea ce am descris mai devreme reprezintă un fragment al acordului de modelare, această parte a acordului se referă la regulile de organizare a unei diagrame și, prin urmare, la regulile sale de scriere și citire.
„Rețeta”
Acum să luăm în considerare opțiunea de modelare a sistemului exact din diagramă Activity. Aceasta este doar una dintre opțiuni, subliniez că, desigur, nu este singura. Diagrama Activity ne va interesa din perspectiva rolului său pentru tranziția de la modelarea procesului la proiectarea unui sistem automatizat. Pentru aceasta, ne vom alinia la recomandările metodologice – un fel de rețetă care constă din cinci etape și preconizează dezvoltarea a trei tipuri de diagrame. Aplicarea acestei rețete va ajuta la obținerea unei descrieri formalizate a procesului pe care dorim să-l automatizăm și la colectarea datelor pentru proiectarea sistemului. Iar pentru studenți, la începutul studiului UML, aceasta este o veritabilă salvare care nu va permite să te îneci în bogăția de mijloace reprezentative și tehnici existente în UML și în instrumentele moderne de modelare.
Iată, de fapt, rețeta, iar apoi urmează diagramele construite pentru domeniul nostru de aplicare „fabule”.
Etapa 1. Descriem procesul sub formă de diagramă Activity. Pentru un proces care are mai mult de 10 pași, are sens să aplicăm principiul decompoziției pașilor procesului pentru a îmbunătăți lizibilitatea diagramei.
Etapa 2. Identificăm ce poate fi automatizat (pașii pot fi, de exemplu, evidențiați pe diagramă).
Etapa 3. Funcția sau funcțiile sistemului trebuie să fie corelate cu pasul automatizat (relația poate fi de tipul multe-la-multe), desenăm diagrama Use-case. Acestea sunt funcțiile sistemului nostru.
Etapa 4. Vom descrie organizația internă a SA cu ajutorul diagramei claselor – Class. Calea de înot „Obiecte de intrare și ieșire (documente)” pe diagrama Activitate este baza pentru construirea modelului de obiect și a modelului entitate-relație.
Etapa 5. Vom analiza notițele pe pista „Reguli de afaceri”, ele impun diverse limitări și condiții, transformându-se treptat în cerințe non-funcționale.
Conjuntoul de diagrame obținute (Activitate, Use-case, Class) ne oferă o descriere formalizată într-o notare suficient de strictă, adică are o citire univocă. Acum putem dezvolta un document tehnic, clarificând specificațiile cerințelor etc.
Să începem modelarea.
Etapa 1. Descriem procesul sub formă de diagramă Activitate
Reamintesc că am structurat câmpul diagramei prin „benzi” de înot, pe fiecare bandă fiind plasate elemente de același tip (Figura 2). Pe lângă elementele descrise mai sus ale diagramei, vom utiliza elemente suplimentare, să le descriem.
Decizia (Decision) marchează pe diagramă punctul de ramificare al procesului, iar fuziunea fluxurilor (Merge) – punctul de reunificare a acestora. În parantezele pătrate de pe tranziții sunt înscrise condițiile de tranziție.
Între cele două sincronizatoare (Fork) vom arăta ramuri paralele ale procesului.
Procesul nostru poate avea un singur început – un singur punct de intrare (Initial). În schimb, finalizările (Final) pot fi mai multe, dar nu pentru diagrama noastră specifică.
Se obțin destul de multe săgeți, iar la un număr mare de elemente și legături, putem începe prin a evidenția etapele procesului, iar apoi să facem decompoziția acestor etape. Totuși, procesul nostru „poveștilor” aș dori să-l arăt vizual complet pe o singură diagramă, având în vedere, desigur, că trebuie să ne asigurăm că săgețile „nu se lipesc”, astfel încât să putem urmări cu exactitate ce este legat de ce.
Figura 2. Diagrama Activitate – vedere generală a procesului
deoarece în versurile poeziei unele detalii ale procesului sunt omise, am fost nevoit să le restabilesc, ele sunt reprezentate prin elemente cu fundal alb. Aceste detalii includ pasul „Transferului/Recepționării pentru depozitare și prelucrare” și mai multe artefacte de intrare și ieșire. Merită menționat că acest pas nu dezvăluie nici el complet procesul, deoarece ar trebui să indicăm separat pasul de transfer și pasul de recepție, plus să adăugăm un pas separat pentru coji, iar în plus să presupunem că toate aceste bunuri materiale ar trebui să fie stocate temporar undeva etc.
De asemenea, vom observa că rămâne în continuare fără răspuns întrebarea despre originea nucilor - de unde provin și cum ajung la veveriță? Și această întrebare (este evidențiată cu font roșu în notă - elementul Note) necesită o elaborare separată! Așa funcționează analistul – strângând informații din colț în colț, formulând ipoteze și primind „da” sau „nu” de la experții în domeniu – niște oameni foarte importanți și indispensabili în etapa modelării de afaceri în crearea sistemelor.
De asemenea, să observăm că pasul procesului P5 constă în două părți.
Și fiecare parte o decopunem și o examinăm mai detaliat (Figura 3, Figura 4), deoarece activitatea desfășurată în cadrul acestor pași va fi automatizată.
Figura 3. Diagrama Activității – detalierea (partea 1)
Figura 4. Diagrama Activității – detalierea (partea 2)
Etapa 2. Identificăm ce poate fi automatizat
Pașii care urmează să fie automatizați în diagrame sunt evidențiați cu culoare (vezi Figura 3, Figura 4).
Toate acestea sunt efectuate de un singur participant la proces – Diaconul ordinat:
- Introduc informații despre greutatea nucii în registru;
- Introduc informații despre transferul nucii în registru;
- Fixează faptul transformării nucii în coji și miez;
- Introduc informații despre miezul nucii în registru;
- Introduc informații despre cojile nucii în registru.
Analiza muncii efectuate. Ce urmează?
Așadar, am realizat o mare parte din munca pregătitoare: am adunat informații despre procesul pe care dorim să îl automatizăm; am început să formulăm un acord de modelare (deocamdată doar în ceea ce privește utilizarea diagramei de activitate); am realizat modelarea procesului și chiar am efectuat o decompunere a câtorva dintre pașii săi; am identificat pașii procesului pe care îi vom automatiza. Acum suntem pregătiți să trecem la etapele următoare și să începem proiectarea funcțiilor sistemului și a organizării sale interne.
După cum se știe, teoria fără practică nu este nimic. Este esențial să încercăm „modelarea” cu propriile mâini, este util și pentru înțelegerea abordării propuse. De exemplu, putem lucra în mediul de modelare. [3]. Am decompus doar o parte din pașii diagramei generale a procesului (vezi figura 2). Ca exercițiu practic, ar putea fi propus să repetăm toate diagramele în mediul Modelio și să efectuăm decompunerea pasului „Transfer/primire pentru stocare și procesare”.
Lucrul în anumite medii de modelare nu este deocamdată un subiect pe care să-l analizăm, dar acesta ar putea deveni tema unor articole și recenzii autonome.
În a doua parte a articolului, vom analiza tehnicile de modelare și proiectare necesare în etapele 3-5, folosind diagrame UML de tip Use-case și Class. Continuarea urmează.
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.
Sursa: habr.com
