Al patrulea capitol prezintă o comparație între principalele mecanisme de modelare ale UML AD și BPMN utilizate în modelarea proceselor de afaceri. [310949]

Cuprins

Introducere

Acestă carte abordează domeniul Business Process Management de la prezentarea fundamentelor acestuia la o descriere detaliată a principalelor standarde grafice utilizate în modelarea proceselor de afaceri. Lucrarea este structurată pe cinci capitole.

Primul capitol intitulat Fundamentele BPM evidențiază și descrie noțiuni cum ar fi: [anonimizat], sistem BPM (evoluția acestora), [anonimizat].

Al doilea capitol prezintă detaliat și exemplifică modalitatea de utilizare a diagramelor UML în descrierea modelelor de procese de afaceri (se concentrează pe prezentarea UML Activity Diagram).

Capitolul Standarde grafice:BPMN prezintă detaliat și oferă numeroase exemple de utilizare a elementelor de modelare pentru a descrie diferite tipuri de procese publice sau private. Capitolul descrie totodată și Șabloane și capcane comune pe care un analist le poate întâmpina în procesul de modelare utilizând BPMN și le exemplifică. Capitolul conține numeroase exemple de diagrame create utilizând BPMN.

Al patrulea capitol prezintă o comparație între principalele mecanisme de modelare ale UML AD și BPMN utilizate în modelarea proceselor de afaceri.

Ultimul capitol propune o serie de întrebări grilă și teme menite să ajute cititorul în demersul său de a asimila noile noțiuni prezentate.

Obiectivul acestei lucrări este de a furniza cititorului un suport pentru a studia despre principalele standarde grafice utilizate în modelarea proceselor de afaceri și a-și evalua noile cunoștințe dobândite.

Autoarea

1. Fundamentele BPM

Înainte de a iniția orice demers științific în domeniul BPM este important să clarificăm noțiunea de Business Analyst și IT BA. Astfel, pentru a nu se realiza nici un fel de confuzii un BA este o [anonimizat], în timp ce un IT BA lucrează în contextul unor proiecte IT.

BA-ul este un “agent al schimbării” care [Haliga, 2013]:

investighează și identifică oportunități de afaceri;

facilitează procesul de schimbare și implementare;

identifică și definește soluția care să maximizeze beneficiile și să reducă costurile;

este implicat în toate nivelele funcționale ale companiilor;

[anonimizat], facilitând comunicarea inter/intra departamente și toate părțile interesate.

[anonimizat], [anonimizat], evidenței și controlului fluxului de lucru (interviu, workshop, [anonimizat], etc).

Un IT BA reprezintă legătura dintre stakeholderii unui sistem software și dezvoltatorii acestuia. Funcția acestuia este de a [anonimizat]. [anonimizat], negociază, reprezintă și validează cerințele unui sistem software nou sau în curs de actualizare. [anonimizat] [Podeswa, 2005].

Un Business Model este o reprezentare abstractă a unei părți clar delimitate a unei afaceri. Reprezentările unui BM pot fi diverse dar cea mai comună este sub forma unor diagrame. Aceste diagrame sunt importante deoarece prezintă cerințele într-o manieră lipsită de ambiguități adică într-o formă standardizată. Totuși acesta nu este singurul aspect benefic al utilizării diagramelor în scopul creării unui BM:

Construirea diagramelor ajută în realizarea interviurilor de documentare. O diagramă prezintă o ordine logică a unor pași specifici unui proces. La fiecare pas este necesar ca un IT BA să adreseze întrebări pentru a descoperi direcția fluxului procesului. Practic în momentul trasării diagramei un IT BA conștientizează care sunt întrebările care trebuie adresate și când trebuie adresate pentru a finaliza un interviu de documentare.

Construirea diagramelor ajută la reconcilierea mai multor puncte de vedere. Există momente când pentru a evidenția redundanțe la nivelul unui proces există nevoia unei descrieri grafice pentru o mai bună înțelegere (de către părțile interesate) a necesității de schimbare a acestuia.

Un proces de afaceri poate fi definit ca un set de activități sau sub-procese și tranzacții secvențiale sau paralele, logic relaționate menite să producă un anumit rezultat (output). Fiecare proces prezintă date de intrare (input). Input-urile și output-urile unui proces pot fi primite sau trimise de la și către un alt proces, departament sau alte părți interesate (stakeholders) interne sau externe organizației.

În literatura de specialitate am identificat numeroase definiții ale termenului proces de afaceri [Siegel,2008]:

Rummler și Brache (1995) au definit BP astfel: o serie de pași care se execută în cadrul unei organizații pentru a crea un produs sau serviciu. Dacă depășește granițele unui departament este un BP interfuncțional. Dacă produsul este destinat unui client BP-ul este considerat primar altfel este un BP ce asigură suport în cadrul organizației.

Ould (2005) a definit BP astfel: un set coerent de activități realizat de către un grup ce colaborează pentru atingerea unui obiectiv; organizarea acestor activități și definirea proceselor trebuie realizată în contextul unei bune cunoașteri a afacerii.

WMC (1999) a definit în glosarul de termeni un BP astfel: un set de proceduri sau activități mai mult sau mai puțin relaționate care împreună vizează atingerea unui obiectiv, în contextul existenței unei structuri organizaționale cu roluri funcționale bine definite și conexiuni bine stabilite. BP-urile pot fi manuale sau automatizate.

Smith and Fingar (2006) precizează că un BP este un set complet și dinamic coordonat de activități colaborative și tranzacționale care furnizează valoare clienților. BP-urile sunt mari și complexe, dinamice, personalizate, configurate pentru a funcționa durate lungi de timp, automatizate, etc.

OMG are cea mai puțin restrictivă definiție oferită BP-ului în cadrul specificației Business Motivation Model specification v. 1.3- 2015: procesele de afaceri realizează un curs de acțiuni întreprinse pentru ca organizația să progreseze continuu în vederea atingerii obiectivelor stabilite. Această definiție nu se referă doar la procesele ciclice (preluarea unei comenzi) ci și la procesele bine definite care rulează o singură dată (actualizarea proceselor este un proces în sine).

În contextul globalizării, managementul proceselor de afaceri a devenit foarte important pentru toate organizațiile care doresc să:

crească numărul comenzilor;

crească viteza de transfer a datelor;

crească viteza de luare a deciziilor;

adapteze rapid cerea și oferta de produse și

să asigure competitivitate pe piața internațională.

Pentru a atinge astfel de obiective industria IT a preluat provocarea de a realiza un management eficient a proceselor de afaceri. Astfel, în ultimele trei decenii, în cadrul organizațiilor formularele tipărite au fost treptat înlocuite cu „copiile” lor electronice. Acesta a fost practic începutul a ceea ce numim astăzi BPM.

Definiția BPM oferită de van der Aalst [van der Aalst et al., 2003] este următoarea: „asigurarea unui suport eficient pentru procesele de afaceri utilizând metode, tehnici și software, pentru proiectarea, controlul și analiza proceselor care implică oameni, organizații, aplicații, documente și alte surse de informație”.

BPM Software [Appian, 2013] referă setul de instrumente software care automatizează, execută și monitorizează procesele de afaceri de la început și până la sfârșit prin conectarea utilizatorilor, aplicațiilor și utilizatorilor la aplicații. Tehnologia BPM este mult mai avansată decât cea precedentă: WfM și EAI. Deși tehnologia WfM conecta utilizatorii prin utilizarea ineficientă a unor procese controlate manual într-o singură aplicație era limitată deoarece nu putea conecta aplicații decât prin intermediul unui efort intens de programare. Tehnologia EAI conecta aplicații prin rutarea informațiilor între ele astfel încât datele erau automat sincronizate în întreaga organizație. Cu toate acestea nu permite automatizarea unor procese interactive și ca atare nu poate conecta utilizatorii. Prin conectarea utilizatorilor și a aplicațiilor, BPM Software a combinat și depășit aceste două tehnologii. La un nivel minim o aplicație BPM include următoarele componente:

Process Designer care permite unui utilizator instruit să analizeze și să modeleze un proces pas cu pas și să îi confere o logică;

Process Engine care execută fluxul procesului și asignează activități manuale utilizatorilor și activități automatizate către aplicații în timpul execuției;

Rules Engine care realizează managementul fluxului de informații și activități dintr-un proces în conformitate cu regulile și formulele atașate acestuia și

Process Analytics care furnizează un feedback continuu asupra procesului pentru ca în viitor să se poată aduce îmbunătățiri acestuia.

Figura 1. Componentele BPM Software [Appian, 2013].

BPM Suite [Appian, 2013] referă o tehnologie care furnizează o diversitate de procese, cunoștințe și funcționalități analitice într-un pachet unitar oferind astfel posibilitatea organizațiilor de a crea rapid și eficient aplicații compozite. Suitele BPM au apărut pentru a furniza o abordare mult mai cuprinzătoare. Comparativ cu BPM Software, aceste aplicații compozite, oferă în plus următoarele funcționalități:

Knowledge Management care oferă utilizatorilor posibilitatea de a partaja activități, conținut, documente și notificări via comunități;

Figura 2. Aplicații compozite[Appian, 2013].

Document Management care oferă un sistem pentru stocarea și securizarea documentelor electronice, imagini sau alte fișiere;

Collaborative Tools care înlătură barierele în comunicația intra/inter departamente prin intermediul forumurilor, spațiilor de lucru dinamice, etc.;

Business Analytics care permite managerilor să identifice problemele de afaceri, trend-uri și oportunități și să le coreleze cu rapoartele existente și

Work Portal care oferă utilizatorilor un spațiu de lucru productiv pentru managementul activităților, conținutului, formularelor, documentelor, notificărilor, etc.

Aplicațiile dezvoltate cu BPM Suite sunt user-friendly (minimizând astfel nivelul de instruire necesar), personalizate (furnizează conținut securizat către fiecare utilizator), scalabile (extinderea funcționalităților se realizează cu ușurință) și web-based (accesibile la orice moment). Astfel oferă posibilitatea utilizatorilor de a lua decizii corecte astfel încât putem spune că aceste aplicații nu realizează doar un management eficient a proceselor de afaceri ci rezolvă probleme de afaceri.

BPM System [Appian, 2013] reprezintă un set de practici de management destinate a îmbunătăți agilitatea și performanța funcțională într-un mediu specific proceselor de afaceri. Această viziune holistică oferită de Gartner oferă o abordare structurată pentru optimizarea proceselor și consideră atât instrumentele software prezentate mai sus cât și metodele, politicile, metricile și practicile de management ale organizației. Astfel BPM referă o organizație a cărui management se realizează prin intermediul proceselor și care presupune adițional la IT următoarele:

Expertiză și experiență – focalizare pe dobândirea de aptitudini centrate pe proces, intruire, educație, certificare, cercetare, perspicacitate în afaceri și capital intelectual;

Discipline organizaționale – adoptarea de culturi noi și îmbunătățite, structuri, roluri, responsabilități, politici, reguli și proceduri;

Management și audit – îmbunătățirea proceselor prin definire, modelare, simulare, execuție, monitorizare, analiză și optimizare și

Parteneriate și servicii – suport din partea partenerilor pentru consultanță, implementare,etc.

Deoarece această abordare permite organizațiilor să separe procesele de afaceri de infrastructura IT, BPM System practic transcede automatizarea proceselor de afaceri și rezolvarea problemelor de afaceri permițând afacerii în sine să răspundă mai ușor la modificările din piață generând astfel avantaj competitiv.

Vocabularul BPM cuprinde în afară de termenii discutați anterior următoarele (un glosar complet de termeni poate fi identificat la [Appian, 2013]):

BPMN sau notația BPM a fost dezvoltată de către BPMI pentru a furniza un set de elemente grafice care poate fi înțeleasă cu ușurință de către proiectanți, utilizatori, analiști,etc.

Business process model – BPMN definește un model ca un set de elemente grafice sau activități și fluxuri care definesc ordinea lor de desfășurare.

Cloud BPM presupune lansarea tehnologiilor BPM în cloud pentru modelarea și execuția proceselor.

Mobile BPM presupune abilitatea de a accesa aplicații BPM via smartphone, tablete sau alte dispozitive mobile.

Social BPM referă posibilitatea de a utiliza colaborarea în contextul proceselor de afaceri.

BPM permite organizațiilor să obțină eficiență operațională, să integreze sisteme, să partajeze cunoștințe, să obțină vizibilitate și feedback, să creeze responsabilitate și politici unitare și să faciliteze schimbarea. După dezvoltarea și lansarea aplicațiilor compozite utilizând o suită BPM o organizație este mult mai bine pregătită pentru a răspunde cerințelor pieții. Astfel, :

pe termen scurt organizațiile înregistrează o creștere a profitului prin descreșterea costurilor și creșterea veniturilor și

pe termen lung BPM ajută la generarea de avantaj competitiv prin îmbunătățirea agilității organizaționale.

1.1. BPM versus BPR versus WfM versus SOA sau scurt istoric BPM

Influența IT în managementul proceselor de afaceri o regăsim inițial în paradigma BPR discutată de Hammer și Champy în 1993. BPR propune ignorarea completă a proceselor de afaceri existente într-o organizație, în timp ce BPM, descendentul său este mai practic, iterativ și incremental în adaptarea proceselor de afaceri.

În ceea ce privește diferențele dintre BPM și WfM am identificat în literatura de specialitate două puncte de vedere:

BPM este o disciplină de management iar WfM îi asigură suportul tehnologic [Hill etal., 2008];

Componentele WfM reprezintă un subset al ciclului de viață al BPM definit de van der Aalst [Georgakopoulos et al., 1995] diferența majoră constând din existența fazei de diagnoză.

Tabelul 1. Comparație între WfM și BPM [Ryan K.L. Ko et al., 2009

În realitate numeroase BPMS sunt încă WfMS deoarece nu suportă faza de diagnoză. Recent din ce în ce mai mulți dezvoltatori au actualizat denumirea WfM a produselor lor utilizând termenul mai contemporan BPM. Deși numeroase BPMS oferă instrumente de monitorizare BAM acestea încă necesită utilizarea unor instrumente de raportare externe și specializate cum sunt Microsoft Reporting Server sau Crystal Reports [Ryan K.L. Ko et al., 2009].

În ceea ce privește diferențele dintre BPM și SOA se poate argumenta că BPM „organizează oameni pentru o eficiență sporită” în timp ce SOA „organizează tehnologii pentru o eficiență sporită”. Cu alte cuvinte, procesele SOA (servicii web interconectate) facilitează coordonarea sistemelor distribuite care oferă suport proceselor de afaceri și nu trebuie niciodată confundate cu procesele de afaceri. Pe scurt, BPMS=BPM+SOA [Baker, 2006].

Figura 3. Aplicații de întreprindere monolitice[Muehlen, 2007].

Pentru o mai bună înțelegere a conceptelor și diferențelor dintre BPM și SOA voi realiza o prezentare a evoluției BPM. Inexistența BPM presupune existența unor aplicații de întreprindere monolitice construite ca un tot unitar (figura anterioară) și cu o interfață utilizator construită pentru toate funcționalitățile aplicației, ceea ce presupune că orice modificare sau extindere de funcționalitate presupune intervenția directă a unui programator.

În anii 1990 ideea de flux începea să prindă contur (Figura 4).

În anul 1993 s-a constatat o orientare către managementul activităților. Fluxurile erau controlate de către utilizator dar spre deosebire de anul 1990 nu erau doar o idee. După cum se observă și din Figura 5 utilizatorul accesează interfața în mod direct în momentul în care dorește să creeze un cont nou, ceea ce înseamnă că încă nu s-au înregistrat progrese semnificative.

Figura 4. BPM în anii 1990.

Figura 5. BPM în 1993-orientarea către managementul activităților [Muehlen, 2007].

În 1996 s-a demarat rutarea fluxurilor dar acestea erau controlate în continuare manual (Figura 6).

Figura 6. BPM în 1996. Rutarea fluxurilor[Muehlen, 2007].

Figura 7. BPMN în 2003. Integrarea serviciilor[Muehlen, 2007].

În 2003 au apărut îmbunătățiri semnificative în sensul că interfața grafică conecta utilizatorul la BPMS și nu direct la aplicație, acest lucru fiind posibil datorită implementării de servicii web interconectate (SOA) (Figura 7).

Figura 8. BPMN în 2007. Servicii compozite[Muehlen, 2007].

În anul 2007 au apărut serviciile compozite, apariția BPEL conducând la o separare clară a responsabilităților în acest domeniu. Astfel, asignarea de responsabilități, definirea de grupuri, roluri, aptitudini, termene limită, alerte, memento-uri, escalări, adăugarea de sarcini manuale, ordonarea sarcinilor și interfața utilizator sunt apanajul sferei de afaceri în timp ce logica computațională, reprezentarea datelor, scalabilitatea/performanța, interoperabilitatea și managementul datelor devin apanajul sferei IT [Muehlen, 2007] (Figurile 8 și 9).

Figura 9. BPMN 2007. Servicii compozite. Extindere BPEL[Muehlen, 2007].

1.2. Standarde BPM

BPM a stârnit rapid interesul atât practicienilor cât și teoreticienilor, motiv pentru care s-au dezvoltat diverse paradigme și metodologii transformând BPM într-un subiect interdisciplinar. Problema este că numeroasele terminologii și tehnologii nu au fost suficient de bine definite, înțelese, propuneau notații diferite pentru aceleași concepte și nu au fost validate prin implementarea lor în mediul de afaceri real. Cu alte cuvinte necesitatea unui standard era imperativă și poate fi justificată prin relația existentă între teoria BPM, standarde BPM și sistemele BPM.

Figura 10. Teoria BPM versus Standarde și specificații BPM versus BPMS.

În continuare voi încerca să:

discut terminologia asociată cu BPM și standardele acestuia;

clasifica sistematic standardele BPM;

discuta punctele tari și punctele slabe ale fiecărui standard;

clarifica diferențele teoretice care stau la baza celor mai importante standarde BPM și

explora lacunele existente în standardele BPM actuale și cum acestea pot fi depășite.

1.2.1. Noțiunea de standard

Impactul unui standard poate fi foarte mare. Să definești un standard este un proces riscant deoarece selecția greșită a tehnologiei poate fi contraproductivă, incompatibilă și poate conduce la neadoptarea acestuia în practică. Pe de altă parte și adoptarea unui standard trebuie realizată cu maximă atenție deoarece o alegere greșită poate genera dificultăți în momentul actualizării tehnologiei utilizate, poate limita conectivitatea între partenerii de afaceri și forța instruirea utilizatorilor într-o tehnologie depășită moral. În general se observă necesitatea unei mai bune înțelegeri asupra întregului proces de standardizare [Muehlen, 2007] și ca atare voi realiza câteva clarificări.

Fazele standardizării sunt inițierea, dezvoltarea, ratificarea, adopția și distribuția Astfel:

Inițierea unui standard poate fi cauzată de apariția unor sancțiuni aplicate de către instituțiile statului unor standarde deja existente sau poate fi cauzată de diverși utilizatori, vânzători sau dezvoltatori. Inițierea unui standard poate apare în urma unei solicitări (specificații OMG) sau nu (specificații IETF), sau poate fi rezultatul celor mai bune practici din domeniu [Muehlen, 2007].

Dezvoltarea unui standard se realizează într-un cadru organizațional pe baza unei cooperări între membrii organizației, dar totodată solicitându-se și opinia unor experți independenți sau a altor grupuri sau organizații direct interesate în vederea implementării standardului înainte de ratificare.

Ratificarea se poate realiza prin vot sau sub formă de specificații (recomandări, RFC, standard) după care se validează specificațiile realizate.

Adopția se realizează în general în ordinea următoare: organizațiile participante la definirea standardului, alte organizații, comunități open-source. După această etapă se trasează standardele obligatorii și cele recomandate prin studiul atent și comparativ între conformitate și posibilitatea reală de implementare a acestora [Muehlen, 2007].

Difuzia apare ca urmare a utilizării standardului de către utilizatorii finali și este determinată de către prezența pe piață și promovarea eficientă (Management by magazine) a acestuia.

1.2.2. Clasificarea standardelor BPM

Pentru a înțelege cât mai bine noțiunile fundamentale BPM este necesar ca mai întâi să avem o perspectivă clară și succintă asupra ciclului de viață al BPM. Există numeroase modele ale ciclului de viață BPM dar cel mai clar este cel realizat de van der Aalst [van der Aalst et al., 2003] și care constă din:

Proiectarea proceselor. În această fază procesele de afaceri sunt modelate „ca atare” în BPMS. Standardele grafice sunt dominante în această fază.

Configurarea sistemului. În această fază se configurează BPMS și infrastructura acestuia. Această fază este dificil de standardizat deoarece organizațiile au arhitecturi IT diferite.

Implementarea proceselor. Procesele de afaceri sunt executate cu ajutorul motoarelor BPMS. Standardele de execuție domină această fază.

Diagnoză. Se utilizează instrumente de analiză și monitorizare cu ajutorul cărora analistul BPM identifică lacune ale proceselor de afaceri. În această fază domină standardele pentru diagnoză.

Figura 11. Ciclul de viață al BPM.

Într-o primă fază putem putem grupa standardele existente după funcții similare sau caracteristici (Figura 12). Multe dintre aceste standarde fac referire la una dintre fazele ciclului de viață BPM. De exemplu BPMN adresează faza de proiectare a proceselor sau de implementare a acestora.

Figura 12. Standarde BPM [Muehlen, 2007].

Ca atare o primă clasificare este următoarea:

Standarde grafice care permit utilizatorilor să exprime procesele de afaceri, fluxurile și tranzițiile acestora sub forma unor diagrame;

Standarde pentru execuție care permit automatizarea proceselor de afaceri;

Standarde pentru portabilitate utilizate pentru a asigura portabilitatea proceselor de afaceri modelate cu ajutorul a mai multor standarde grafice în același BPMS sau standarde de execuție diferite pe mai multe BPMS sau translatarea standardelor grafice în standarde de execuție și invers.

Standarde pentru diagnoză care oferă funcționalități administrative și de monitorizare și care pot identifica probleme, audita și interoga în timp real procesele de afaceri dintr-o organizație.

Figura 13. Diagramă pentru clasificarea standardelor BPM [Ryan K.L. Ko et al., 2009].

Deseori se realizează confuzii între standardele BPM și alte standarde cum ar fi cele SOA. Un algoritm prin care se poate realiza o diferențiere între standarde este prezentat în Figura 13.

Această diagramă realizată de Ryan K.L. Ko et al.[Ryan K.L. Ko et al., 2009] exprimă grafic algoritmul pentru separarea standardelelor BPM de standardele B2B și cele SOA. După cum se observă diferențierea dintre standardele SOA și cele BPM se realizează prin diferențierea între serviciu web și proces, iar diferențierea între standardele B2B și cele BPM se realizează în funcție de tipul procesului de afaceri care poate fi public sau privat. În continuare standardele se diferențiază în funcție de fazele din ciclul de viață al BPM descrise anterior.

Principalele standarde, limbaje, notații și teorii BPM existente sunt prezentate în Tabelul 2.

Tabelul 2. Starea curentă a standardelor BPM, SOA și B2B [Ryan K.L. Ko et al., 2009].

Figura 14. Clasificarea standardelor.

Privind sub o altă perspectivă, standardele grafice reprezintă cel mai înalt nivel de expresie a proceselor de afaceri, în timp ce standardele de execuție reprezintă cel mai scăzut nivel (sunt tehnice) de expresie pentru procesele de afaceri. Deși standardele pentru portabilitate au ca scop translatarea dintre standardele grafice și cele de execuție și vice versa, aceasta poate fi imperfectă deoarece aceste standarde sunt conceptual diferite [Recker and Mendling, 2006]. Aplicând algoritmul din Figura 13 standardelor prezentate în Tabelul 2 putem realiza clasificarea din Figura 14.

1.2.3. Exemple de standarde grafice

Standardele grafice permit utilizatorilor să exprime fluxul de informații, punctele de decizie și rolurile proceselor de afaceri într-o manieră grafică prin crearea de diagrame. Tehnicile cele mai cunoscute utilizate pentru modelarea proceselor de afaceri în mod graphic sunt diagramele UMLAD [OMG, 2009],[OMG,2016], BPMN [OMG1,2009] [OMG,2011], EPC și RAD. Aceste tehnici variază de la notații comune la standarde. Dintre standarde, cele mai expresive și ușor de integrat cu nivelele următoare (portabilitate și execuție) sunt UML și BPMN.

UML a fost standardizat în 2004 și reprezintă o suită de 13 notații orientate obiect care încorporează toate atributele și comportamentul obiectelor modelate [Ambler, 2004]. Câteva exemple de astfel de notații includ diagrame ale cazurilor de utilizare, diagrame de secvență, diagrame de activitate, etc. Dintre toate cea mai des utilizată pentru modelarea proceselor de afaceri este diagrama de activitate [Russel et al., 2006].

De-a lungul timpului au existat câteva încercări de a realiza comparații între notațiile utilizate de UML AD și WPF. De asemenea s-a investigat cât de utilă și expresivă poate fi UML AD pentru a captura esența colecțiilor de șabloane de fluxuri de lucru [Dumas și Hofstede, 2001]. Acest studiu a apărut ca o replică la publicația Workflow Handbook [White, 2004] prin care se realizează o comparație între notațiile și mecanismele de modelare specifice BPMN și UML AD. Concluziile referitoare la cât de adecvată este UML AD pentru modelarea proceselor de afaceri au fost următoarele [Russell et al., 2006]:

UML AD oferă un bun suport pentru reprezentarea fluxurilor de control și a datelor dar

UML AD oferă posibilități limitate de a modela aspecte organizatorice ale proceselor de afaceri.

Deși UML AD este funcțională, aceasta nu poate fi utilizată de analiști fără ca aceștia să dețină cunoștințe tehnice. De asemenea UML AD nu facilitează modelarea unui proces de afaceri și sub-procesele acestuia de la cel mai înalt nivel de detaliere la cel mai mic.

Standardul BPMN a fost realizat în speranța de a micșora decalajul existent între IT și analiști. BPMI a expus prima dată BPMN ca o reprezentare grafică a BPML care este un limbaj pentru execuția proceselor bazat pe XML. În timp, BPML a fost înlocuit de rivalul său BPEL. BPMN permite modelarea proceselor private(interne), publice(abstracte) și de colaborare la nivele diverse de granularitate. Cele mai multe modele BPMN pot fi mapate în BPEL ceea ce de fapt reprezintă marele avantaj al BPMN comparativ cu UML AD.

Figura 15. Extras dintr-o diagramă UML AD.

Totuși, datorită diferențelor ireconciliabile dintre BPMN și BPEL, este dificil să se genereze cod BPEL din modelele BPMN și de asemenea să se sincronizeze modelele BPMN la codul BPEL generat. La pol opus, dezavantajul major constă în portabilitatea redusă a diagramelor BPMN. OMG a introdus un standard în acest sens numit BPDM dar în mod curent se utilizează standardul XPDL.

Diferențele dintre UML AD și BPMN BPD sunt:

de terminologie;

BPMN BPD utilizează mai puține elemente de modelare pentru a reprezenta procese complexe;

UML AD solicită cunoștințe tehnice analiștilor.

Figura 16. Exemplu de BPMN BPD.

EPC a fost dezvoltat de către Institute for Information Systems din Germania și este un limbaj utilizat de către setul de instrumente ARIS a IDS Scheer AG și componenta de fluxuri de lucru a sistemului SAP R/3. Deși a fost foarte popular în anii 1990 și a avut câteva caracteristici notabile, acesta prezintă suficiente limitări pentru ca cercetătorii și practicienii din domeniu să nu îl considere un standard grafic pentru modelarea proceselor de afaceri.

Figura 17. Exemplu de diagramă EPC.

RAD și diagramele de fluxuri de lucru nu sunt standarde dar sunt instrumente utilizate pentru a afișa tranzițiile proceselor de afaceri [Odeh et.al , 2002].

Figura 18. Notația RAD [Brennan, 2006].

Notații grafice ca UML AD și BPMN sunt ușor de utilizat de către analiști și alte persoane care nu dețin cunoștințe tehnice. Comparate cu BPEL standardele grafice pot evidenția șabloane și diverse lacune ale proceselor de afaceri, dar datorită setului finit de componente existent pentru modelare pot totodată să și restricționeze libertatea de proiectare. Datorită absenței formalismului semantic și computațional din aceste notații grafice modelele BPMN sau UML AD nu vor putea fi niciodată complet translatate în cod executabil.

1.2.4. Exemple de standarde pentru execuție, portabilitate și diagnoză

Standardele pentru execuție permit lansarea proceselor de afaceri modelate în BPMS pentru ca instanțele acestora să fie executate de către motorul BPMS. Momentan există două standarde BPML și BPEL importante. BPEL a fost adoptat de către mai multe suite software (IBM Websphere, BEA AquaLogic BPM Suite, SAP Netweaver, etc.) deși BPML adresează mai bine semantica proceselor de afaceri.

Avantajele BPML sunt [Ryan K.L. Ko et al., 2009]:

BPML suportă conceptul de zero cod. Programatorii nu sunt obligați să-și concentreze atenția asupra activității de programare ci mai degrabă pe definirea corectă a proceselor și a secvențelor lor de execuție. Practicienii numesc acest concept „programarea în ansamblu”;

BPML încurajează reutilizarea și scalabilitatea fiind un standard deschis pentru toate BPMS. Componentele sale pot fi reutilizate și parsate deoarece BPML are la bază XML;

BPML este formal complet și

BPML suportă tranzacții.

BPML prezintă următoarele limitări [Ryan K.L. Ko et al., 2009]:

Componenta temporală a unui proces nu este evidentă în momentul definirii acestuia dar se specifică în format XML.

BPML poate fi suportat doar de către sisteme BPMS pure și nu de către sistemele unor dezvoltatori mari cum ar fi Microsoft BizTalk, IBM MQServer și Websphere ceea ce a condus la apariția XLANG (dezvoltat de Microsoft) și WSFL(dezvoltat de IBM).

BPMI a retras suportul pentru BPML în 2005 după fuziunea cu OMG.

BPEL este un limbaj bazat pe XML prin intermediul căruia putem defini procese de afaceri prin utilizarea serviciilor web și care poate servi ca un limbaj de execuție (procese executabile) și ca un limbaj de descriere (procese abstracte).

Figura 19. Evoluția BPEL [Ryan K.L. Ko et al., 2009].

Avantajele BPEL sunt [Ryan K.L. Ko et al., 2009]:

Este cel mai popular și nu prezintă în acest moment nici un competitor serios, find adoptat de marea majoritate a dezvoltatorilor de software (ca atare nu există nici probleme de portabilitate cu produse a dezvoltatorilor mai mici de BPMS).

Comparativ cu alte limbaje de programare (Java) nu se concentrează pe programarea propriu-zisă ceea ce facilitează semnificativ modelarea proceselor și micșorează și numărul liniilor de cod.

Adoptă paradigma serviilor web în sensul că BPEL încorporează un număr de componente menite a dezvolta servicii web și a facilita comunicarea asincronă, precum și suport XML pentru definirea și manipularea datelor.

BPEL prezintă următoarele limitări [Ryan K.L. Ko et al., 2009]:

Prezintă o sintaxă complexă dificil de implementat.

Sintaxa este restrictivă ceea ce cauzează numeroase probleme la translatarea BPMN-BPEL.

BPEL este restrictiv în modelarea comportamentului uman în cadrul proceselor.

BPEL nu oferă suport pentru toate construcțiile posibile de procese și ca atare deseori se utilizează împreună cu alte limbaje de programare (Java).

BPEL nu oferă suport B2B.

În ciuda limitărilor sale BPEL este momentan cel mai popular limbaj de execuție.

Standardele de execuție sunt limitate deoarece secvențele, activitățile și legăturile care se creează în interiorul și între procese nu sunt vizibile (similar limbajelor de asamblare). De asemenea o altă mare limitare pentru standardele de execuție îl reprezintă faptul că necesită cunoștințe tehnice în special referitoare la servicii web ceea ce creează dificultăți analiștilor.

Diferența fundamentală dintre standardele grafice și cele de execuție este: standardele grafice sunt orientate graf în timp cele standardele de execuție sunt orientate bloc. Din acest motiv deseori informația se pierde în translatarea între cele două tipuri de standarde. Standardele pentru portabilitate sunt menite să rezolve această problemă. Momentan există două astfel de standarde:

BPDM creat de OMG și

XPDL creat de WfMC.

BPDM este complex și neprietenos. XPDL este cel mai popular (ultima versiune este 2.2 disponibilă din august 2012 conform http://www.xpdl.org/).

Diferența esențială între WM și BPM rezidă în etapa de diagnoză din ciclul de viață BPM. Standardele pentru diagnoză monitorizează și optimizează BP din BPMS.

Exemple de standarde pentru diagnoză:

BPRI este proiectat pentru a oferi o interfață comună pentru modelul de date utilizat la execuția proceselor și are ca prim obiectiv facilitarea analizei și

BPQL asigură o interfață pentru managementul întregii infrastructuri BPM și include facilități cum ar fi process server și process repository.

2. Standarde grafice: UML

UML a fost conceput pentru modelarea sistemelor informatice complexe. „UML presupune că metodologia este “ghidată” de cazurile de utilizare, că ea se bazează pe arhitectura sistemului, iar procesul de aplicare a metodologiei este iterativ și incremental. UML nu tratează aspecte de metodologie, permițând astfel separarea limbajului de modelare de procesul aplicării metodologiei” [Giurcă, 2004]. Modelarea unui sistem presupune parcurgerea mai multor faze ale dezvoltării: analiză, proiectare, implementare testare și desfășurare sistematică (Figura 21).

Un singur graf nu poate să surprindă toate informațiile necesare descrierii unui sistem informatic deoarece trebuie considerate aspecte:

Funcționale: pentru descrierea structurii statice și a comportamentului dinamic al sistemului;

Non-funcționale: cum ar fi necesarul de timp pentru dezvoltarea sistemului și

Organizatorice: managementul proiectului, maparea modulelor de cod.

UML poate fi structurat în [Giurcă, 2004]:

view (o abstractizare a sistemului pentru a cărei dezvoltare se folosesc diagrame Figura 20),

diagrame (sunt grafuri care descriu conținutul unui view) (Figura 22),

elemente de modelare (sunt concepte folosite în diagrame care au corespondență în programarea orientată-obiect) și

mecanisme generale (de exemplu permit introducerea de comentarii).

Figura 20. UML views [Eriksson et.al, 2004].

„Fiecare view este descris folosind un număr de diagrame care conțin informații relative la un anumit aspect particular al sistemului. Aceste view-uri se acoperă unele pe altele, deci este posibil ca o anumită diagramă să facă parte din mai multe view-uri [Giurcă, 2004], [Eriksson et.al, 1998]:

View-ul cazurilor de utilizare (use-case view). Acest view surprinde funcționalitatea sistemului, așa cum este ea percepută de actorii externi care interacționează cu sistemul, de exemplu utilizatorii acestuia sau alte sisteme. În componența lui intră diagrame ale cazurilor de utilizare și ocazional, diagrame de activitate. Cei interesați de acest view sunt deopotrivă clienții, proiectanții, dezvoltatorii dar și cei care vor realiza testarea și validarea sistemului.

Figura 21. Etapele modelării unui sistem[Giurcă, 2004], [Eriksson et.al, 2004].

View-ul logic (logic view). Spre deosebire de view-ul cazurilor de utilizare, un view logic “privește” înăuntrul sistemului și descrie atât structura internă a acestuia (clase, obiecte și relații) cât și colaborările care apar când obiectele trimit unul altuia mesaje pentru a realiza funcționalitatea dorită. Structura statică este descrisă în diagrame de clasă, în timp ce pentru modelarea dinamicii sistemului se vor folosi diagramele de stare, de secvență, de colaborare sau de activitate. Prin urmare, cei care sunt interesați de acest tip de vizualizare a sistemului sunt proiectanții și dezvoltatorii.

View-ul componentelor (component view). Componentele sunt module de cod de diferite tipuri. În funcție de conținutul lor acestea pot fi: componente care conțin cod sursă, componente binare sau executabile. View-ul componentelor are rolul de a descrie componentele implementate de sistem și dependențele ce există între ele, precum și resursele alocate acestora și eventual alte informații administrative, cum ar fi de exemplu un desfașurător al muncii de dezvoltare. Este folosit în special de dezvoltatorii sistemului, iar în componența sa intră diagrame ale componentelor.

View-ul de concurență (concurent view). Sistemul poate fi construit astfel încât să ruleze pe mai multe procesoare. Acest aspect, care este unul nonfuncțional, este util pentru o gestionare eficientă a resurselor, execuții paralele și tratări asincrone ale unor evenimente din sistem, precum și pentru rezolvarea unor probleme legate de comunicarea și sincronizarea thread-urilor. Cei care sunt interesați de o astfel de vizualizare a sistemului sunt dezvoltatorii și integratorii de sistem, iar pentru construirea lui se folosesc diagrame dinamice (de stare, de secvență, de colaborare și de activitate) și diagrame de implementare (ale componentelor sau de desfășurare).

View-ul de desfășurare (deployment view). Desfășurarea fizică a sistemului, ce sisteme de calcul și ce dispozitive (numite și noduri) vor fi folosite pentru realizarea efectivă a implementării, cum sunt acestea conectate, precum și ce componente se vor executa pe fiecare nod (de exemplu ce program sau obiect este executat pe fiecare calculator), toate sunt surprinse în view-ul de desfășurare. Acest tip de vizualizare a sistemului prezintă interes pentru dezvoltatori, integratorii de sistem și cei care realizează testarea sistemului, iar pentru construirea view-ului este folosită diagrama de desfășurare”.

Un model de sistem are o dimensiune dinamică și una statică. Modelul dinamic al unui sistem analizează sistemul din perspectiva acțiunilor sale adică la nivel comportamental (răspunde la întrebarea: ce face sistemul?), în timp ce modelul static analizează sistemul din perspectiva sa structurală (răspunde la întrebarea: ce este sistemul?) [Podeswa, 2005]. Astfel diagramele UML vor reprezenta aspecte dinamice, respectiv statice, ale sistemului modelat. Diagramele sunt realizate utilizând diverse elemente de modelare. Diagramele care sunt utilizate cu precădere pentru descrierea unui BP sunt: diagrama cazurilor de utilizare, diagrama de activitate și acolo unde este cazul diagrama de stare. În continuare sunt prezentate pe scurt aceste trei tipuri de diagrame.

Figura 22. Tipologia diagramelor UML.

2.1. Diagrame UML utilizate în modelarea proceselor de afaceri

Diagrama cazurilor de utilizare (use case diagram). „Un caz de utilizare este o descriere a unei funcționalități (o utilizare specifică a sistemului) pe care o oferă sistemul. Diagrama prezintă actorii externi și cazurile de utilizare identificate, numai din punctul de vedere al actorilor (care este comportamentul sistemului, așa cum este el perceput de utilizatorii lui) nu și din interior, precum și conexiunile identificate între actori și cazurile de utilizare” [Giurcă, 2004], [Eriksson et.al, 1998]. Pe scurt, prezintă modurile în care este sistemul utilizat și au scopul de a captura sau formaliza cerințele utilizatorului. Principalele elemente de modelare ale diagramei cazurilor de utilizare folosite în modelarea proceselor sunt prezentate în Tabelul 3.

Figura 23. Exemplu de diagramă a cazurilor de utilizare [Giurcă, 2004], [Eriksson et.al, 2004].

Tabelul 3. Elemente de modelare ale diagramei cazurilor de utilizare.

Diagrama de stare (state diagram). „O stare este de obicei un complement al descrierii unei clase. O diagramă de stare prezintă toate stările prin care trece un obiect al clasei precum și evenimentele care îi cauzează modificările de stare. Modificarea stării se numește tranziție. Nu vom construi diagrame de stare pentru toate clasele din sistem ci numai pentru acelea care au un număr de stări bine definit iar comportamentul clasei este afectat și modificat de acestea” [Giurcă, 2004], [Eriksson et.al, 1998].

Figura 24. Exemplu de diagramă de stare.

Principalele elemente de modelare ale diagramei de stare utilizate în modelarea proceselor sunt prezentate în Tabelul 4.

Tabelul 4. Elementele de modelare ale diagramei de stare.

Figura 25. Exemplu de diagramă de stare [Dorobăț, 2012].

Diagrama de activitate (activity diagram). “O diagramă de activitate prezintă fluxul secvențelor de activități și este de obicei folosită pentru a descrie activitățile realizate în cadrul unei operații, folosind dacă este cazul decizii și condiții. Diagrama conține acțiuni (action) și mesaje care vor fi trimise sau recepționate ca parte a acțiunilor realizate” [Giurcă, 2004], [Eriksson et.al, 1998]. Aceste diagrame sunt destinate descrierii comportamentului intern al unui caz de utilizare sau a unei operații.

Figura 26. Exemple de diagrame de activitate [Giurcă, 2004], [Eriksson et.al, 2004], [UML2,2007].

Principalele elemente de modelare ale diagramei de activitate utilizate în modelarea proceselor sunt prezentate în Tabelul 5.

Tabelul 5. Elementele de modelare ale diagramei de activitate.

2.2. Exemple de utilizare a UML pentru descrierea BP

Pentru a înțelege modalitatea de utilizare a diagramelor UML pentru descrierea unui BP voi prezenta diagrame de cazuri de utilizare, diagrame de activitate și diagrame de stare specifice unor studii de caz.

Singura diagramă care nu este supusă la modificări și îmbunătățiri pe parcursul unei iterații este diagrama cazurilor de utilizare, aceasta reprezentând numitorul comun al celor patru faze ale dezvoltării unui sistem.

Definirea problemei I

O companie dorește implementarea unui sistem informatic pentru managementul programelor educaționale oferite de către aceasta.

Obiectivele sistemului informatic sunt:

Înregistrarea și monitorizarea activităților profesorilor: acreditarea profesorului, înregistrarea profesorului, autentificarea profesorului, înregistrarea studenților, programarea susținerii pre/post testului;

Înregistrarea și monitorizarea activităților studenților: autentificarea studentului, susține pre-test, susține post-test;

Înregistrarea și monitorizarea activităților funcționarilor: autentificarea funcționarului, managementul programelor educaționale.

Monitorizarea performanței programelor educaționale presupune realizarea unor rapoarte privind:

Rata de succes a programelor educaționale la nivel de student student/ instituție de învățământ/ județ

Costurile programului educațional la nivel de student student/ instituție de învățământ/ județ

Profitul programului educațional realizat la nivel de student/ instituție de învățământ/ județ

Instituțiile de învățământ care nu beneficiază de programe educaționale.

Pentru a stabili în detaliu funcționalitatea sistemului care se proiectează este necesară o descriere a cazurilor de utilizare. Aceasta nu are o structură standard, existând multiple variante în funcție de necesitățile echipei de dezvoltare. De exemplu definirea unui caz de utilizare se realizează în cazul proiectelor de dezvoltare de dimensiuni mari după un șablon similar celui prezentat în Figura 27. Este posibil ca numărul și complexitatea cazurilor de utilizare să fie atât de mare încât să fie necesar să se întocmească un grafic de livrare a cazurilor de utilizare către beneficiar. În cazul problemei definite anterior am identificat cazurile de utilizare și voi prezenta o selecție dintre acestea (Figura 28).

Figura 27. Șablon pentru descrierea cazurilor de utilizare.

Figura 28. Diagrama extinsă a cazurilor de utilizare.

Figura 29. Diagrama UC01 Acreditare profesor.

Figura 30. Diagrama de activitate aferentă UC01 Acreditare profesor.

Figura 31. Diagrama de stări aferentă UC01 Acreditare profesor.

Figura 32. Diagrama cazului de utilizare UC02 Înregistrare profesor.

Figura 33. Diagrama cazului de utilizare UC05 Înregistrează studenți.

Figura 34. Diagrama cazului de utilizare UC08 Formează clasa.

Temă – Realizați diagramele de activitate și de stare (acolo unde este cazul) pentru a detalia cazurile de utilizare prezentate mai sus (2,5,8).

Definirea problemei II

Informațiile prezentate în continuare reprezintă o parte din contribuția echipei din A.S.E. București la cercetarea întreprinsă pentru etapa II, intitulată “Analiza și sinteza procesului administrativ”, din cadrul proiectului internațional “EU Services Directive în Romania – EUSDRO Project” al cărui obiectiv general a fost dezvoltarea și integrarea soluțiilor de interoperabilitate a sistemelor de e-guvernare, a proceselor administrative din România și țările din Europa Centrală și de Est, contribuind astfel la modernizarea și armonizarea pan-europeană a serviciilor electronice din administrația publică și mediul economic. Etapa a II-a a presupus identificarea stadiului existent în procesele administrative având ca reper central crearea unui punct unic de acces la Oficiul Național al Registrului Comerțului și modelarea operațiilor posibile și exemplificarea acestora prin scenarii [EUSDRO,2009].

Ca rezultat al acestor demersuri prezint diagrama cazurilor de utilizare (Figura 35) și detaliez un scenariu aferent cazului de utilizare Înregistrare societate comercială cu răspundere limitată. Scenariul este Înregistrare societate comercială cu răspundere limitată cu un singur asociat român.

Figura 35. Diagrama cazurilor de utilizare EUSDRO.

Temă – Realizați diagramele de activitate și de stare (acolo unde este cazul) pentru a detalia cazul de utilizare prezentat.

3. Standarde grafice: BPMN

3.1. Procesul de modelare BPMN

Să ne imaginăm o organizație în care fiecare departament prezintă propriul set de proceduri de lucru și propriul „limbaj”. Nu mă refer la un limbaj tehnic, ci la un limbaj care descrie activitățile pe care personalul din aceste departamente le execută în mod curent: pe scurt cum funcționează procesele lor de afaceri (BP). Managementul unei asemenea companii este cu atât mai dificil dacă și departamentele responsabile de documentarea și îmbunătățirea proceselor de afaceri (analiștii, arhitecții, dezvoltatorii de software, etc.) utilizează limbaje proprii, prin aplicarea unor reguli și convenții specifice unor metodologii sau instrumente software diferite.

Acest lucru poate fi modificat prin utilizarea unui limbaj vizual, a unui standard în întreaga organizație. Un astfel de limbaj vizual este furnizat prin intermediul notației BPM sau BPMN. BPMN standardizează diagramele utilizate în vederea descrierii proceselor de afaceri ale unei companii prin intermediul unui set de figuri și simboluri predefinite. Pentru a realiza un management eficient este nevoie de instrumente software care să aibă încorporate facilități BPMN, de o metodologie sau ghid care să ne asigure că un model de proces (care poate fi creat cu diverse instrumente software) poate fi înțeles doar din diagrama sa fără să se utilizeze altă documentație suplimentară, precum și instrumente care să faciliteze simularea și optimizarea modelelor BPMN (de exemplu AnalystView de la Global360) și care să creeze totodată și legătura cu mediile de execuție a proceselor [Silver, 2010].

BPMN este utilizat atât pentru analiza și documentația proceselor de afaceri cât și pentru proiectarea de procese executabile. Elementele de modelare esențiale ale BPMN sunt: căsuțele care reprezintă activities (activități) organizate în lanes (care pot reprezinta departamente ale organizației) interconectate prin săgeți numite sequence flows.

Figura 36. Principalele elemente de modelare BPMN care descriu un flux: activity, gateway și event [Silver, 2010].

BPMN este conceptual simplu prezentând 3 elemente de modelare principale care descriu un flux: activity (descrie o acțiune din cadrul procesului reprezentată printr-o formă rectangulară cu colțuri rotunjite), gateway (poate descrie o condiție din cadrul procesului reprezentată printr-o formă de romb) și un event (un semnal care informează dacă procesul a generat sau recepționat ceva, reprezentat printr-o formă circulară).

În afară de aceste elemente clasice diagramelor de fluxuri, BPMN adaugă:

expresivitate deoarece definește o largă paletă de subtipuri pentru elementele de modelare activity, gateway și event ceea ce permite BPMN să transceadă dincolo de simpla descriere a unui proces către posibilitatea de a creea procese executabile;

sub-procese permițând astfel vizualizarea unui model de proces pe mai multe nivele de detaliere;

message flows (fluxuri de mesaje) permițând vizualizarea conexiunilor dintre un proces și mediul exterior acestuia – de exemplu clientul care a solicitat procesul, furnizorul de servicii aferent procesului sau alte procese interne care interacționează cu procesul respectiv; fluxurile de mesaje definesc poziția fiecărui proces la nivelul întregii arhitecturi de procese;

tratarea excepțiilor prin utilizarea de evenimente;

universalitatea notațiilor deoarece semnificația unei diagrame este independentă de instrumentul de modelare utilizat sau metodologia utilizată.

Procesul de modelare utilizând BPMN nu este facil și presupune parcurgerea următorilor pași [Silver, 2010]:

înțelegerea obiectivelor procesului de modelare – înainte de a începe să documentezi starea curentă a unui proces este necesar să înțelegi de ce trebuie să depui acest efort sau pe scurt ce încerci să obții: îmbunătățirea unui proces existent pentru eficientizarea acestuia sau adaptarea unui proces pentru lansarea unui nou produs sau poate documentarea procesului pentru o simplă auditare;

documentarea unui proces în starea sa curentă (as is) prin realizarea de interviuri, observarea activității personalului organizației și întâlniri menite să faciliteze o descriere cât mai amănunțită a procesului; este de asemenea necesesară crearea unei prime diagrame a procesului și confirmarea de către personalul organizației că într-adevăr aceasta este modalitatea curentă de funcționare a procesului respectiv;

analiza stării curente a procesului pentru a evidenția principalele probleme care conduc la o performanță scăzută a acestui proces; cele mai comune probleme sunt: abundența activităților secvențiale în defavoarea celor executate în paralel, pași redundanți executați pentru aprobarea, informarea, verificarea sau revizuirea unor activități, activități duplicate, lipsa validării, automatizare insuficientă, decalaje între nivelul de calificare a personalului și tipul activității pe care o execută, lacune în standardizare (aceiași activitate este executată diferit în departamente diferite ale organizației), birocrația.

propunerea unor îmbunătățiri pentru noul proces (to be) – ideal este să se identifice mai multe alternative de îmbunătățire a procesului și să se realizeze mai multe versiuni pentru noul model de proces care să fie foarte bine detaliate, care să definească resursele, costul, disponibilitatea, volumul de procesare zilnic al activităților modificate și nivelul de calificare al personalului care va fi implicat în execuția acestora.

analiza și validarea noului model de proces în concordanță cu obiectivele stabilite – orice modificare propusă pentru un anumit proces trebuie validată de către managerii organizației.

Simularea modelului procesului curent și compararea rezultatelor cu valorile reale (cunoscute) de timp și costuri aferente acestuia este necesară pentru a consolida ideea că modelul procesului curent este valid (câteodată este necesară iterarea unei diagrame și a parametrilor de simulare a acesteia până când se obțin valorile reale de timp și cost atașate procesului curent). Această simulare (bazată pe date reale) a procesului curent oferă credibilitate în momentul simulării procesului îmbunătățit.

Simularea presupune definirea de resurse pentru fiecare activitate desfășurată și timpul necesar pentru finalizarea acesteia. De asemenea punctele de decizie trebuie să aibă atașate probabilitățile de a urma o ramură sau alta sau pot avea atașate condiții specifice bazate pe date.

Un factor major în performanța procesului este reprezentat de modalitatea de alocare a resurselor mai ales dacă simularea evidențiază apariția unor blocaje sau decalaje majore de timp pentru anumite activități. Aceste blocaje sau decalaje de timp pot fi reduse prin realocarea resurselor sau altfel spus prin optimizare.

Simularea ajută prin testarea a numeroase alternative (pe hârtie) și compararea acestor alternative în termeni de timp și costuri. Aceste alternative sunt discutate cu managementul organizației și stakeholderi (alte părți interesate din organizație).

3.2. Soluții BPMN

Conform studiilor de piață realizate de Forrester, Microsoft Visio este unul din cele mai frecvent utilizate instrumente de către analiști (mai mult de 75%) în vederea elaborării și validării de procese de afaceri în cadrul companiilor.

Simularea nu este una din funcționalitățile specifice Microsoft Visio (începând cu Microsoft Visio Premium 2010 toate versiunile includ suport BPMN) dar au existat soluții software cum ar fi Global360 care oferă un add-in numit AnalystView care asigură suport pentru simularea procesului curent și optimizarea automată a noului model de proces.

Figura 37. Microsoft Visio Premium 2010.

Îmbunătățirea proceselor nu necesită întotdeauna automatizarea într-o soluție BPMS. Multe procese pot deveni mai performante prin simpla reorganizare a activităților acestora, automatizarea unor activități manuale sau prin clarificarea logicii procedurale a procesului explicit într-o diagramă partajată. Totuși pentru a maximiza beneficiile BPM este recomandat să se utilizeze o soluție BPMS.

În Figura 38 se ilustrează componentele Global360’s BPMS numit Process360. Microsoft Visio asigură analiza și modelarea proceselor, iar AnalystView furnizează procese executabile către DesignerView.

La lansarea unui proces utilizatorul interacționează cu sistemul prin intermediul rolurilor definite în UserViews și poate monitoriza performanța procesului prin ManagerView. Microsoft SharePoint colectează toate modelele de procese, rapoartele de simulare, etc. (historical proces intelligence). Într-un astfel de sistem un model de proces executabil este lansat într-un motor de procese care rutează fiecare instanță a acestuia prin pașii descriși în model. Acesta creează activitățile specifice fluxului de lucru, execută și definește logica fluxului și regulile, interoghează și actualizează alte sisteme utilizate prin comandă direct din motorul de procese.

Proiectarea unor procese executabile într-un BPMS necesită detalii tehnice mai avansate decât cele oferite de către notația BPM analitică din Microsoft Visio dar se poate obține translatarea directă între aceste două modele utilizând XPDL, un standard al Workflow Management Coalition. Global360 AnalystView permite această translatare XPDL↔BPMN facilitând astfel integrarea modelelor BPMN create în Microsoft Visio în DesignerView [Silver, 2010].

Figura 38. Process360 [Global360, 2013].

Momentan OMG anunță numeroase soluții care implementează BPMN [OMG1,2016]. Cele mai performante BPMS (conform criteriilor anunțate de Gartner în 2016) sunt prezentate în Figura 39.

Figura 39. Cvadrantul magic al BPMS [Gartner, 2016].

3.3. Utilizarea BPMN

BPM este utilizat pentru a comunica o varietate mare de informații către o varietate mare de audiențe. BPMN este proiectat să ofere diverse tipuri de modelare și permite crearea unor BP end-to-end. Elementele de modelare BPMN permit celui care le vizualizează să diferențieze ușor secțiunile unei diagrame BPMN. Există trei tipuri de submodele în cadrul unui model BPMN end-to-end:

Procese (Orchestrație), incluzând:

BP private non-executabile (interne);

BP private executabile (interne);

Procese publice;

Coreografii;

Colaborări care pot include procese și/sau coreografii: Conversații.

Procesele private (interne) sunt cele specifice unei organizații. Aceste procese sunt numite la modul general flux sau procese BPM. Un alt sinonim utilizat în cazul serviciilor web este de orchestrație de servicii. Există două tipuri de procese private: executabile și non-executabile. Un proces executabil este un proces care a fost modelat cu scopul de a fi executat în concordanță cu o anumită semantică descrisă în capitolul 14 din OMG BPMN specification 2.0 [OMG, 2011]. Un proces non-executabil este un proces care a fost creat cu scopul de a documenta comportamentul procesului respectiv. Cu alte cuvinte, informații necesare execuției unui proces cum ar fi de exemplu condiții (expressions) nu sunt incluse în procesele non-executabile. Un proces privat poate fi delimitat într-o singură regiune (elementul de modelare pool). Fluxul procesului nu poate depăși granița marcată de pool. Fluxul de mesaje poate depăși această graniță pentru a putea evidenția astfel interacțiunea dintre mai multe procese private.

Un proces public este reprezentat de interacțiunile dintre un proces privat și un alt proces sau un alt participant. Numai activitățile care sunt utilizate pentru comunicarea cu un alt participant sunt incluse în procesul public. Toate celălalte activități ale procesului privat nu sunt evidențiate în procesul public. Cu alte cuvinte, procesul public evidențiază fluxurile de mesaje și ordinea acestora, necesare în interacțiunea cu un alt proces. Procesele publice pot fi modelate separat sau într-o colaborare pentru a evidenția fluxul de mesaje dintre activitățile procesului public și alți participanți. Procesele publice au fost numite procese abstracte în BPMN 1.2.

O coreografie definește comportamentul dintre participanți fără implicarea unor regiuni sau orchestrații. Un proces este definit în cadrul unei regiuni pe când coreografia există între regiuni (sau participanți). Coreografia este similară unui proces privat deoarece constă dintr-o rețea de elemente de modelare activity, event, gateway. Totuși coreografia este diferită deoarece activitățile sale reprezintă de fapt un set de schimburi de mesaje care implică unul sau mai mulți participanți. De asemenea nu există o entitate responsabilă sau observator al procesului respectiv.

Figura 40. Exemplu de proces privat [OMG, 2011].

Figura 41. Exemplu de proces public [OMG, 2011].

Figura 42. Exemplu de coreografie[OMG, 2011].

O colaborare descrie interacțiunile dintre una sau mai multe entități. O colaborare conține de obicei unul sau mai multe regiuni care reprezintă participanții din colaborarea respectivă. Mesajele interschimbate între participanți sunt evidențiate prin fluxuri de mesaje care conectează regiuni. O colaborare poate fi reprezentată de două sau mai multe procese publice care comunică. Pentru procesele publice activitățile pot fi considerate puncte de contact între participanți (pentru participanții la colaborare). Procesele interne (executabile) asociate sunt mult mai detaliate decît procesele publice afișate. Toate combinațiile de elemente de modelare regiune, proces și coreografie sunt permise într-o colaborare.

Figura 43. Exemplu de proces colaborativ[OMG, 2011].

Selecția corectă a tipurilor de procese ce vor fi modelate se realizează conform diagramei BPMN prezentată în Figura 44.

Figura 44. Tipuri de procese [Venter, 2010].

O diagramă de conversație este o formă particulară și în același timp oferă și o descriere informală a diagramei de colaborare. În acest tip de diagramă regiunile unei conversații nu conțin procese iar o coreografie nu este în mod uzual plasată în interiorul unor regiuni ale diagramei de conversație. O conversație definește logica schimbului de mesaje. Această relație logică de obicei referă un obiect cum ar fi: comandă, transport, factură. Schimburile de mesaje sunt relaționate între ele și reflectă diferite scenarii specifice afacerii. De exemplu, în logistică, actualizarea stocurilor implică următoarele tipuri de scenarii: crearea unor comenzi, alocarea unor transportatori pentru mai multe comenzi combinate, trecerea vamei, procesarea plăților și investigarea excepțiilor. O diagramă de conversație prezintă conversațiile în construcții de tip hexagon legând participanții (regiuni). Astfel obținem o vedere de ansamblu asupra diferitelor conversații din domeniul studiat.

Figura 45. Exemplu de conversație[OMG, 2011].

Diagramele BPMN sunt deseori considerate a fi sinonime. Exemplul care urmează este menit să exemplifice natura lor distinctă.

Diagramele de colaborare reprezintă interacțiunea dintre unul sau mai multe procese, unde fiecare proces ar putea reprezenta o persoană, un rol sau un sistem. O colaborare este ușor de identificat deoarece aceasta de obicei conține mai multe regiuni. O regiune poate fi goală de conținut, un black box sau poate reprezenta un proces. Următorul exemplu descrie un proces al departamentului Help desk ce conține 3 participanți. Toate combinațiile de regiuni, procese și coreografii sunt permise într-o colaborare.

Figura 46. Help desk colaborare [Polancic,2014].

Diagramele de conversație au fost introduse în BPMN 2.0 și reprezintă o formă particulară, o descriere informală a diagramei de colaborare. De fapt este o formă simplificată a diagramei de colaborare. O conversație oferă o vedere de ansamblu asupra participanților ce cooperează și la nivelul cărei activități. Această diagramă introduce două elemente de modelare conversation node (modelat printr-un hexagon) și conversation link (modelat printr-o linie dublă).

Figura 47. Help desk conversație [Polancic,2014].

La un nivel mai detaliat diagramele de conversație pot fi transformate în coreografii sau diagrame de colaborare. Ca exemplu, fluxul de mesaje a conversației Soluționare problemă este descris în diagrama de colaborare prin intermediul a două fluxuri de mesaje între Client și Help desk. O colaborare sau coreografie nu trebuie să descrie doar o conversație este de asemenea posibil să se combine fluxurile de mesaje din una sau mai multe conversații într-o singură diagramă. Diagramele de colaborare și conversație pot fi combinate într-o singură diagramă (Figura 48).

Figura 48. Help desk colaborare și conversație[Polancic,2014].

Coreografiile ilustrează interacțiunile dintre procese și fluxurile de mesaje.

Coreografia este un tip de proces dar se diferențiază de acesta deoarece o orchestrație este definită de către fluxul de activități specifice unei organizații iar coreografia formalizează modalitatea în care participanții își coordonează interacțiunile. Cu alte cuvinte, coreografia nu se referă la activitățile realizate de către participanți ci la schimbul de mesaje dintre aceștia. O coreografie poate fi utilizată pentru a analiza cum participanții comunică pentru a-și coordona interacțiunea (Figura 49).

O coreografie există în afara/între regiuni. Aceasta definește secvența de interacțiuni dintre participanți. În consecință o coreografie nu poate fi descrisă într-o singură regiune. Fiecare pas al unei coreografii implică doi sau mai mulți participanți. Acești pași se descriu cu ajutorul elementului de modelare coreography task. O coreografie poate fi inclusă în cadrul unei colaborări. Fiecare flux de mesaj descris în cadrul unei colaborări poate fi descris cu ajutorul unui element de modelare coreography task în cadrul coreografiei asociate. Inițiatorul unei coreografii trebuie întotdeauna să fie implicat în activitatea anterioară.

Figura 49. Help desk coreografia[Polancic,2014].

3.4. Elementele de modelare BPMN

Scopul BPMN este de a oferi mecanisme simple și ușor inteligibile pentru a crea modele pentru procese de afaceri complexe. Ca atare primul pas a fost să se organizeze toate elementele grafice în categorii. Acestea oferă un set de notații care ajută în recunoașterea principalelor elemente de modelare ale unei diagrame. Principalele categorii de elemente de modelare sunt:

Flow object – acestea sunt principalele elemente grafice care definesc comportamentul unui BP; există trei elemente de acest tip: event; activity; gateway;

Data – reprezentată de patru elemente grafice: data object; data input; data output; data store;

Connecting object- reprezentată de patru elemente grafice: sequence flow; message flow; association; data association;

Swimlane- reprezentată de două elemente grafice: pool; lane;

Artifact – sunt utilizate pentru a oferi informație adițională despre proces; există două astfel de elemente grafice: group; text annotation.

3.4.1. Elemente de modelare BPMN

Principalele elemente de modelare BPMN sunt descrise în Tabelul 6.

Tabelul 6. Elemente de modelare BPMN [OMG, 2011].

Figura 50. Descrierea unui flux de date [Shapiro et al.,2012].

În tabelele care urmează sunt prezentate elementele de modelare BPMN care pot avea un flux de secvență sau flux de mesaj ca intrare/ieșire.

Tabelul 7. Fluxuri de secvență și regulile fluxurilor de mesaje [Polancic,Tomislav 2008][OMG,2011].

3.4.2. Setul extins de elemente de modelare BPMN

Figura 51 prezintă succint câteva din elementele de modelare esențiale dar și extinse și contextul în care acestea se utilizează în modelarea proceselor.

Figura 51. Mecanismul fluxurilor de secvență [Polancic,Tomislav 2008].

Obiectele extinse ale BPMN sunt descrise în Tabelul 8.

Tabelul 8. Setul extins de elemente de modelare BPMN [OMG, 2011].

Figura 52. Caz de utilizare a elementului de modelare parallel gateway.

Figura 53. Caz de utilizare a elementului de modelare inclusive gateway.

Figura 54. Caz de utilizare a elementului de modelare complex gateway.

Figura 55. Caz de utilizare a elementului de modelare event gateway.

Figura 56. Caz de utilizare a elementului de modelare event gateway instantiate.

Figura 57. Caz de utilizare a elementului de modelare parallel event gateway instantiate.

3.4.3. Evenimente BPMN

În procesul de modelare descriem evenimente care au loc și prezentăm modalitatea în care acestea afectează fluxul întregului proces. Un eveniment declanșează un proces, are loc în timpul procesului sau încheie un proces. BPMN oferă notații distincte pentru fiecare din aceste trei tipuri de evenimente.

În cazul în care modelăm procese complexe (de exemplu servicii web B2B) avem nevoie de evenimente mai complexe de tip message, timer, business rule și error. BPMN ne permite să specificăm tipul de declanșator (trigger type) pentru fiecare eveniment demarcându-le cu ajutorul unor simboluri speciale descrise în Figura 58 și Tabelul 9. Precizând un tip de declanșator pentru fiecare eveniment de fapt adaugăm restricții fluxului de proces descris. De exemplu un eveniment de tip timer nu poate finaliza un proces sau un message flow nu poate conecta decât două evenimente de tip message.

Evenimentele start și unele evenimente intermediate prezintă declanșatori (trigger) care definesc o cauză evenimentului. Există multiple modalități în care aceste evenimente pot fi declanșate. Evenimentele end pot avea un rezultat adică o consecință a fluxului procesului (throw the trigger). Evenimentele start pot doar reacționa la un declanșator (catch the trigger). Astfel utilizăm:

-Start Event dacă Mesajul a fost recepționat. Procesul se lansează.

-Intermediate Throw Event dacă Mesajul va fi transmis. Procesul continuă.

-Intermediate Catch Event dacă Mesajul a fost recepționat. Procesul continuă.

-End Event dacă Mesajul va fi transmis. Procesul s-a încheiat.

Evenimentele end pot doar crea un rezultat (throw a trigger). Evenimentele intermediate pot reacționa la un declanșator dar în același timp pot crea și un rezultat. De asemenea există evenimente care sunt utilizate pentru a întrerupe activități sau nu.

Figura 58. Sintaxa simbolului elementului de modelare event.

Tabelul 9. Tipuri de evenimente.

În continuare sunt prezentate câteva exemple de utilizare a evenimentelor descrise mai sus pentru o mai bună înțelegere a conceptului descris de ele.

Figura 59. Exemplu de utilizare a evenimentului de tip message.

Figura 60. Exemplu de utilizare al evenimentului de tip timer(1).

Figura 61. Exemplu de utilizare al evenimentului de tip timer(2).

Figura 62. Exemplu de utilizare al evenimentului de tip escalation [Belaychuk1,2011].

Figura 63. Exemple de utilizare al evenimentului de tip conditional.

Un exemplu de utilizare al evenimentului intermediar link cu scopul de a conecta părți dintr-un proces complex care poate fi descris pe mai multe pagini este prezentat în Figura 64.

Figura 64. Utilizarea evenimentelor de tip link[ OMG,2011].

Figura 65. Exemplu de utilizare al evenimentului de tip error boundary interrupting [Blain,2006].

Figura 66. Exemplu de utilizare al evenimentului de tip error start event sub-process interrupting.

În Figura 65 eroarea semnalată în cadrul sub-procesului este gestionată de procesul părinte (în afara sub-procesului) spre deosebire de procesul din Figura 66 în care este modelată situația în care o eroare este complet gestionată de către sub-proces (Activitatea C are acces la toate variablele sub-procesului). Această diferențiere se realizează pentru toate evenimentele de tip start event sub-process interrupting.

Figura 67. Utilizarea evenimentului de tip signal [ OMG,2011] (1).

Există situații în care fluxul unui proces este dependent de o activitate dintr-un alt proces. Continuitatea unui proces poate fi modelată utilizând evenimente de tip signal care transferă fluxul între procese precum în Figura 67.

Figura 68. Utilizarea evenimentului de tip signal [Geneva,2010](2).

Semnalizarea unui participant necunoscut este o situație clasică ce se poate modela utilizând evenimente de tip signal (Figura 68 și 69).

Figura 69. Utilizarea evenimentului de tip signal [Geneva,2010](3).

Într-un proces ce deține mai mulți participanți putem identifica nevoia de a modela activități care se desfășoară în paralel dar în același timp trebuie și sincronizate. De exemplu, în Figura 70 este descris un model de proces în care inițiatorul acestuia solicită bani dar în același timp începe să caute și un furnizor. Furnizorul poate fi selectat dar comanda nu poate fi plasată decât dacă fondurile necesare au fost transferate.

Figura 70. Utilizarea evenimentului de tip signal [Geneva,2010](4).

Să presupunem că participantul Inițiator este de fapt un grup de persoane cu alte cuvinte nu se poate ști cu exactitate cine anume din grup lucrează propriu-zis cu furnizorul. De asemenea presupunem că responsabilul financiar nu interacționează în mod direct cu responsabilul de la achiziții. Acesta este motivul pentru care se utilizează evenimente de tip signal pentru ca în final comanda să nu fie lansată până când nu este primit un semnal.

Evenimentul de tip mutiple poate fi utilizat pentru consolidarea mai multor evenimente într-o singură entitate pentru simplificarea diagramei (Figura 71, 72, 73). Pentru declanșarea procesului este necesar ca doar unul din evenimente să se întâmple.

Figura 71. Utilizarea evenimentului start de tip multiple (1).

Figura 72. Utilizarea evenimentului intermediar de tip multiple [Blain1,2006](2).

Figura 73. Utilizarea evenimentului end de tip multiple (3).

În cazul utilizării unui eveniment de start de tip parallel multiple pentru declanșarea procesului este necesar ca toate evenimentele să se întâmple (vezi și din eticheta evenimentului).

Figura 74. Utilizarea evenimentului start de tip parallel multiple.

Pentru a înțelege mai bine care este diferența dintre evenimentul end tip none și tip terminate putem porni de la următorul exemplu de proces: o persoană își cumpără cafea (Figura 75).

Procesul poate fi descris într-o primă fază de următorii pași:

Pas1 – clientul merge la coffee shop;

Pas2 – clientul identifică o cafea pe gustul său;

Pas3 – clientul comandă/cumpără cafea;

Pas4 – clientul părăsește coffee shop.

În acest caz procesul este finalizat deoarece singura opțiune a clientului de a servi o altă cafea ar fi dacă s-ar întoarce din nou la coffee shop (se reia procesul de la pasul 1). Cu alte cuvinte vom utiliza evenimentul de tip terminate.

Să presupunem că totuși clientul se întoarce și nu identifică o cafea pe gustul său. În acest moment suntem nevoiți să modificăm modelul de proces astfel:

Pas1 – clientul merge la coffee shop;

Pas2 – clientul identifică o cafea pe gustul său:

clientul comandă/cumpără cafea;

clientul părăsește coffee shop (aici vom utiliza evenimentul tip terminate deoarece clientul și-a atins scopul și procesul se finalizează);

Pas3 – clientul nu identifică o cafea pe gustul său:

clientul părăsește coffee shop (aici vom utiliza evenimentul tip none deoarece clientul nu și-a atins scopul).

Când modelăm un proces ne interesează să identificăm toate tranzacțiile posibile ale acestuia. Utilizăm evenimentul de tip end none dacă dorim să finalizăm o anumită secvență de flux din cadrul procesului și evenimentul de tip end terminate dacă dorim să oprim orice activitate ce se desfășoară în cadrul procesului.

Figura 75. Utilizarea evenimentului terminate(1).

În continuare este descris un model de proces creat pentru exemplificarea modalității de utilizare a evenimentelor error, cancel, message, compensation.

Aceste modele prezintă nivele diferite de complexitate în funcție de elementele de modelare utilizate.

Temă – Identificați elementele de modelare utilizate și precizați motivația utilizării lor. Precizați care sunt diferențele dintre modelele de proces prezentate în Figura 76, 77 și 78.

Figura 76. Exemplu de utilizare a evenimentelor de tip error, cancel și compensation [GeneXus,2016](1).

Figura 77. Exemplu de utilizare al evenimentelor de tip error, cancel, message, compensation [Nobleprog1,2016] (2).

Figura 78. Exemplu de utilizare al evenimentelor de tip error, cancel, message, compensation [Nobleprog1,2016] (3).

Figura 79. Recapitulare – Elementele de modelare BPMN [BPM Offensive, 2011].

3.5. Șabloane și capcane comune

În continuare voi prezenta câteva dintre capcanele comune întâlnite în procesul de modelare.

Standardul BPMN permite utilizarea mai multor evenimente start și end în cadrul aceluiași proces cu condiția ca acestea să aibă denumiri diferențiate logic (Figura 80) [Polancic,2013].

Figura 80. Utilizarea greșită a evenimentelor de start și end.

Procesul descris în Figura 81 poate fi interpretat astfel: Procesul execută Task 1 apoi continuă în ambele direcții (parallel split) și execută activitățile 2,3 (unde Task 3 este executată de câteva ori) respectiv 4 în paralel [Polancic,2013].

Figura 81. Utilizarea greșită a evenimentului terminate.

Procesul descris pe culoarul Incorect se încheie când fluxul ajunge la evenimentul terminate. Un astfel de eveniment determină încheierea oricărei activități din cadrul procesului chiar dacă unele încă așteaptă să se execute. În aceste condiții este posibil ca fluxul să se încheie fără finalizarea completă a Task 2/3 dar cu finalizarea completă a Task 4. Această situație nu reprezintă neapărat o greșeală de modelare dar este puțin probabil să descrie un proces real. O situație obișnuită ar fi cea prezentată în culoarul Corect în care un proces așteaptă finalizarea cu succes a tuturor activităților și se încheie doar la apariția unei excepții (un eveniment neplanificat).

Utilizarea greșită a fluxurilor în/între elementele de modelare pool: când utilizăm elemente de modelare pool fluxurile de secvență și evenimentele start/end lipsesc adesea pentru că se presupune greșit că fluxurile de mesaje înlocuiesc fluxurile de secvență; adițional fluxurile de secvență sunt utilizate incorect pentru a conecta participanții. Corect este să modelăm fluxul în fiecare regiune independent și ulterior să definim fluxurile de mesaje între regiuni [Polancic,Tomislav 2008].

Figura 82. Utilizarea greșită a fluxurilor în/între regiuni.

Utilizarea greșită a elementelor de modelare event timer: două greșeli sunt comune când se utilizează aceste obiecte; în primul rând elementele de modelare start event sunt utilizate incorect în locul elementelor de modelare intermediate event, în al doilea rând evenimentele intermediare sunt adesea utilizate ca mecanisme de amânare în loc de mecanisme de excepție (reprezentând durata unei sarcini) și vice-versa [Polancic,Tomislav 2008], [Rozman et al.,2007].

Figura 83. Utilizarea greșită a elementelor de modelare event timer.

Utilizarea mecanismului fluxului de secvență: când se folosesc sub-procese extinse, fluxurile de secvență ar trebui să fie conectate la granițele sub-proceselor [Polancic,Tomislav 2008], [Rozman et al.,2007].

Figura 84. Utilizarea mecanismului fluxului de secvență.

Utilizarea fluxurilor în cadrul elementelor de modelare lane: culoarele sunt adesea utilizate eronat în locul regiunilor, ele conțin adesea mai multe procese de afaceri sau conțin fluxuri de mesaje. [Polancic,Tomislav 2008].

Figura 85. Utilizarea fluxurilor în cadrul culoarelor.

Utilizarea elementelor de modelare gateway: acestea sunt conectate numai cu fluxuri de secvență, iar punctele de decizie trebuie să conțină cel puțin două fluxuri de ieșire.

Figura 86. Utilizarea activităților și a evenimentelor.

Utilizarea elementelor de modelare task și a evenimentelor (Figura 86): BA pot utiliza eronat evenimentele și activitățile în sensul că evenimentele sunt modelate greșit ca activități, iar stările activităților sunt modelate ca activități noi [Polancic,Tomislav 2008], [Rozman et al.,2007].

Utilizarea incorectă a buclei de tip multi-instance. Dacă dorim să modelăm faptul că o activitate se repetă utilizăm un element de modelare ce are setat loop type standard iar pe granița acestei activități vom preciza numărul de iterații cu ajutorul unui element de modelare boundary conditional event. Activitatea se va repeta până la îndeplinirea condiției setate cu ajutorul evenimentului de graniță. În acest caz același raport este evaluat de două ori.

Figura 87. Utilizarea incorectă a buclei de tip standard și multi-instance.

Dacă dorim să repetăm o activitate dar utilizând seturi diferite de date atunci vom utiliza un element de modelare ce are setat loop type multi-instance. De exemplu în situația în care un manager primește rapoarte de la subordonați și trebuie să le evalueze dar de fiecare dată sunt seturi noi de date. Cu alte cuvinte al doilea caz prezentat în Figura 87 se referă la evaluarea mai multor rapoarte. Deseori se realizează confuzii în utilizarea celor două tipuri de bucle.

Dacă dorim să precizăm că o anumită activitate este realizată de mai mulți participanți vom utiliza elementul de modelare global task. Scenariul este descris în Figura 88:

Task1, Task2 și Task3 sunt realizate de către Pers.1.

Task2 este realizat simultan și de către Pers.2 și Pers.3.

Elementele de modelare Task2 sunt de tipul call activity(calling global task). Acestea au setat atributul task properties la valoarea id-ului elementului de modelare global task creat (pentru a crea un element de modelare global task accesați meniul Model/Global tasks). Fluxul poate fi descris cu ajutorul unui element de modelare gateway sau nu. În cazul în care se utilizează un element de modelare parallel gateway (Figura 88) elementul de modelare global task nu poate fi trasat în același culoar cu elementele de modelare care îl apelează (elementele de modelare calling global task).

Există alte câteva soluții de modelare pentru acest scenariu cum ar fi [Shapiro et al.,2012]: crearea unui culoar separat Pers.1 și Pers.2 și Pers.3 pe care să trasăm o singură activitate, putem utiliza culoare imbricate sau putem schimba denumirea activităților de forma Task2 executat de Pers.1 fără să fim nevoiți să apelăm la utilizarea unui global task.

Figura 88. Aceiași activitate – culoare multiple.

Utilizarea evenimentelor message și ale fluxurilor de mesaje: start event și intermediate event nu pot fi surse pentru fluxuri de mesaje, evenimentele pot fi doar declanșate de un flux mesaj. Pentru a reprezenta comunicarea dintre două culoare ale aceleiași regiuni nu se utilizează evenimente intermediare de tip message (catch sau throw). Aceste evenimente se utilizează pentru a conecta fluxuri de mesaje dintre regiuni.

Figura 89. Utilizarea evenimentelor intermediare de tip message.

Fluxul de date nu poate fi modelat cu ajutorul unui flux de secvență și a unui eveniment intermediar de tip message. Pentru a modela un flux de date se utilizează elementul de modelare data object (Figura 90) [Rozman et al.,2007].

Figura 90. Reprezentarea unui flux de date.

Definirea incorectă a elementelor de modelare conduce la confuzii mari la nivelul unui model de proces. Câteva din greșelile comune sunt definite în Tabelul 10 și exemplificate în Figura 91 (o diagramă incorect/corect definită).

Tabelul 10. Reguli pentru definirea activităților [Silingas&Mileviciene,2013].

Figura 91. Greșeli realizate la denumirea elementelor de modelare.

Cu ajutorul BPMN se pot modela procese cu un nivel mare de complexitate și se pot utiliza mai multe nivele de detaliere. Cu toate acestea foarte mulți analiști obișnuiesc să reprezinte întreg procesul “pe o singură foaie” ceea ce îngreunează semnificativ analiza acestuia. Specialiști din domeniul psihologiei au determinat faptul că pentru o bună înțelegere a diagramelor de proces ar fi indicat ca acestea să nu conțină mai mult de 5±2 elemente de modelare. Practicienii consideră totuși că acest număr ar trebui să crească la 7±4 elemente de modelare într-o diagramă. Diagramele care conțin un număr foarte mare de elemente de modelare fac aproape imposibilă detecția problemelor și inconsistențelor procesului. De exemplu, în figura ce urmează este prezentată o diagramă ce prezintă o serie de inconsistențe cum ar fi lipsa unei activități Confirmă seminar care este simetrică cu cea Anulează Seminar, o buclă infinită la înregistrarea participanților după termenul limită, nivele de detaliere dezechilibrate la anunțarea seminarului (primele patru activități) și anularea acestuia (un sub-proces), lipsa unei distincții clare între cele două etape de înregistrare și altele. Dacă vom utiliza “o singură foaie” pentru a modela acest proces complex nu vom reuși să vizualizăm toate aceste inconsistențe (Figura 92). O vedere mult mai clară și o înțelegere mult mai bună a întregului proces se poate obține dacă vom transforma diagrama “pe o singură foaie” conform Figurii 93 în mai multe sub-procese care vor fi apoi detaliate separat [Silingas&Mileviciene,2013], [Bigeliene, 2012], [Shapiro et al.,2012].

Figura 92. Diagrama “pe o singură foaie”.

Figura 93. Diagrama cu mai multe nivele de detaliere și sub-procesul Anunță seminar.

Temă – Realizați diagramele tuturor sub-proceselor menționate în Figura 93.

Elementele de modelare gateway sunt foarte importante deoarece cu ajutorul lor controlăm fluxul. De asemenea pot fi un punct de conexiune între evenimentele de tip end ale sub-proceselor și procesul extern acestora. Dacă elementele de modelare gateway sunt în mod eronat omise vor apare în diagramă mai multe fluxuri de secvență care “intră/ies” dintr-o activitate. De asemenea “Da” și “Nu” nu sunt cele mai bune opțiuni pentru denumirea brațelor unui gateway ce rutează fluxul la ieșirea dintr-un sub-proces deoarece este foarte dificil să se realizeze o conexiune logică la evenimentul de tip end al sub-procesului. În practică se realizează multe greșeli și în utilizarea elementului de modelare event gateway motiv pentru care în Figura 94 este prezentat un model înainte și în Figura 95 un model după aplicarea regulilor precizate în Tabelul 11 [Silingas&Mileviciene,2013], [Bigeliene, 2012], [Shapiro et al.,2012].

Tabelul 11. Reguli de utilizare a elementelor de modelare gateway [Silingas&Mileviciene,2013].

Figura 94. Exemple de utilizare eronată a elementului de modelare gateway.

Figura 95. Exemple de utilizare corectă a elementului de modelare gateway.

Dacă evenimentele se repetă inutil vor complica o diagramă, vezi Figura 96. În Figura 97 este prezentată soluția de modelare corectă – se utilizează un sub-proces [Silingas&Mileviciene,2013], [Bigeliene, 2012], [Shapiro et al.,2012].

Figura 96. Utilizarea inconsistentă a evenimentelor.

Figura 97. Utilizarea corectă a evenimentelor.

Pentru a exemplifica modalitatea corectă de utilizare a regiunilor vom discuta următorul scenariu: să presupunem că un avocat oferă consiliere legală iar la sfârșitul lunii calculează pe baza orelor înregistrate în contul unui client o singură factură pe care o transmite acestuia din urmă [Camunda,2016].

Figura 98. Exemplu de utilizare corectă a regiunii.

Figura 99. Exemplu de utilizare incorectă a regiunii.

Dacă vom opta pentru modelarea scenariului conform Figurii 99 la început de lună va fi generată o factură pentru fiecare consiliere oferită clientului. Dacă optăm pentru modelarea scenariului conform Figurii 98 la început de lună va fi generată o factură pentru toate orele de consiliere din lună oferite unui client. Elementul de legătură este după cum se observă elementul data store Alocare timp clienți. Se observă necesitatea separării în mai multe regiuni deoarece anumite activități din cadrul procesului au o singură instanță pe lună în timp ce altele au mai multe.

În ceea ce privește folosirea corectă a culoarelor amintesc doar câteva reguli de utilizare a acestora [Belaychuk2,2011]:

culoarele sunt opționale;

culoarele pot fi imbricate( se creează o ierarhie);

semantica culoarului este la discreția analistului: un culoar poate fi o funcție, un rol, un departament, etc.;

sub-procesele imbricate nu pot avea regiuni și deci nici culoare. Faptul că nu se pot utiliza culoare într-un sub-proces nu este specificat în cadrul standardului dar este implementat în marea majoritate a BPMS. În mod implicit un sub-proces are o regiune deoarece este trasat într-o regiune a procesului său părinte și moștenește atributele acestuia. Ca atare sub-procesul se desfășoară din punct de vedere logic într-un culoar al procesului părinte. Teoretic nu există limite privind utilizarea culoarelor imbricate. În consecință, într-un sub-proces ar trebui să putem utiliza culoare care sunt semantic corelate la/îmbricate în culoarul procesului părinte.

culoarele prezintă semnificație doar la utilizarea elementelor user task, service task, script task;

chiar și pentru un element de modelare user task culoarul este practic un comentariu deoarece utilizatorul care va realiza activitatea se definește prin setarea atributelor activității în cadrul modelului.

În general analiștii începători utilizează cu entuziasm culoarele deși eliminarea acestora ar duce la crearea unui model mult mai descriptiv și clar de înțeles. De asemenea dacă de exemplu procesul este descris utilizând regiuni și culoare se poate depăși numărul recomandat de elemente de modelare și ca atare poate fi greu de analizat. De obicei procesele mari și complexe se descriu utilizând sub-procese (Figurile 92 și 93). Totuși această practică nu permite utilizarea culoarelor deoarece (vezi regulile precizate mai sus):

culoarele au o semnificație și se aplică doar dacă utilizăm elemente user tasks și nu sub-procese;

diagramele sub-proceselor nu permit utilizarea de regiuni și în consecință nici utilizarea de culoare (acest lucru nu rezultă din descrierea standardului BPMN ci este o consecință a implementărilor standardului în BPMS existente pe piață).

Această ultima regulă de fapt se aplică proceselor imbricate deoarece sub-procesele reutilizabile pot avea culoare. Unii analiști folosesc sub-procese reutilizabile doar pentru a putea trasa culoare în model. Acest lucru nu este permis deoarece sub-procesele imbricate sunt utilizate pentru descompunerea în mai multe nivele de detaliere în timp ce sub-procesele reutilizabile adaugă un plus de complexitate deoarece spre deosebire de primele sunt executate într-un context diferit (de date) [Belaychuk2,2011].

Dacă totuși se dorește marcarea unor utilizatori pe diagrama unui proces în locul unor culoare se poate utiliza elementul de modelare group (pentru a edita eticheta elementului de modelare group este necesar să se creeze mai întâi o categorie se accesează meniul Model/Categories) și încercui acele activități care sunt realizate de către același utilizator (Figura 100).

Figura 100. Utilizarea elementului Group în cadrul sub-proceselor pentru simularea unui culoar.

Ca reguli de bună practică este necesar să reținem următoarele [Bigeliene, 2012]:

utilizăm convenții stricte când denumim elementele de modelare astfel încât pentru:

activități utilizăm un verb+un substantiv: Anunță seminar

participanți utilizăm un substantiv: Coordonator

evenimente utilizăm un substantiv: Cerere de înregistrare

data object utilizăm un substantiv: Formular feedback, Lista

gateway: ca regulă de bună practică acestea nu se denumesc cu condiția ca activitatea precizată anterior să definească motivul rutării fluxului;

flux de secvență se denumește doar după utilizarea unui element de modelare gateway și de obicei reprezintă condiția de rutare a fluxului;

utilizăm nivele multiple de detaliere (utilizăm elementul de modelare sub-process): ca regulă utilizăm maxim 10 activități per diagramă ;

documentăm detaliile minore utilizând text annotation și data object;

scenariul trebuie să fie cât mai clar (diagrama trebuie să fie cât mai “aerisită” și ușor de citit) și pentru aceasta nu trebuie să utilizăm linii de flux de secvență foarte lungi sau care se intersectează frecvent, elemente de modelare de dimensiuni diferite, salturi în timp sau să combinăm fluxul de secvență primar cu scenarii alternative ale acestuia; este indicat ca elementele de modelare să fie aliniate;

aplică șabloane BPMN.

Regulile de bună practică au fost completate de către Silver [Silver, 2016] (există un set de reguli ale standardului – marcate cu BPMN și cele definite – marcate cu Style). Iată câteva dintre ele:

BPMN 0101. Toate elementele de modelare utilizate în diagramă (în afară de evenimente de tip start, boundary și activități de compensare) au flux de secvență de intrare dacă procesul include eveniment de start și end.

BPMN 0102. Toate elementele de modelare utilizate în diagramă (în afară de evenimente de tip end și activități de compensare) au flux de secvență de ieșire dacă procesul include eveniment de start și end.

BPMN 0105. Un eveniment de start nu poate avea flux de secvență de intrare.

BPMN 0106.  Un eveniment de start nu poate avea flux de mesaj de ieșire.

BPMN 0107.  Un eveniment de start ce prezintă flux de mesaj de intrare va avea obligatoriu un declanșator de tip message.

BPMN 0109.  Un eveniment de start nu poate avea un declanșator de tip error.

BPMN 0111. Un eveniment de start al unui sub-proces are un declanșator de tip none.

BPMN 0112. Un eveniment de tip boundary are întotdeauna un flux de secvență de ieșire.

BPMN 01122.  Declanșatorul unui eveniment de tip boundary poate fi de tipul message, timer, signal, error, escalation, conditional, cancel, sau compensation.

BPMN 01123. Un eveniment de tip boundary nu poate avea flux de mesaj de intrare.

BPMN 01124. Orice eveniment de tip boundary poziționat pe granița unui sub-proces se asociază cu un eveniment similar (același tip de declanșator) de tip throw.

BPMN 01126. Un eveniment de tip boundary error nu poate fi de tipul non-interrupting.

BPMN 01127. Orice eveniment de tip boundary escalation poziționat pe granița unui sub-proces se asociază cu un eveniment similar (același tip de declanșator) de tip throw.

BPMN 0113. Un eveniment intermediar ce prezintă flux de mesaj de intrare nu poate avea decât un declanșator de tip message (catching).

BPMN 0114. Un eveniment intermediar ce prezintă flux de mesaj de ieșire nu poate avea decât un declanșator de tip message (throwing).

BPMN 01151. Un eveniment intermediar de tip throwing poate avea un declanșator de tipul message, signal, escalation, link sau compensation.

BPMN 01161.  Un eveniment intermediar de tip catching poate avea un declanșator de tipul message, signal, timer, link sau conditional.

BPMN 0119. Un eveniment throwing link nu poate avea flux de secvență de ieșire.

BPMN 0120. Un eveniment catching link nu poate avea flux de secvență de intrare.

BPMN 0124. Un eveniment de tip end nu poate avea flux de secvență de ieșire.

BPMN 0125. Un eveniment de tip end nu poate avea flux de mesaj de intrare.

BPMN 0126. Un eveniment de tip end ce prezintă flux de mesaj de ieșire trebuie să fie de tipul message.

BPMN 0132.  Un element de modelare gateway nu poate avea flux de mesaj de intrare.

BPMN 0133. Un element de modelare gateway nu poate avea flux de mesaj de ieșire.

BPMN 0134. Un element de modelare gateway ce bifurcă fluxul trebuie să prezinte cel puțin 2 rute.

BPMN 0138. Un element de modelare event gateway are plasat pe rutele sale evenimente intermediare de tip catching sau activități de tip receive.

BPMN 0202. Un flux de secvență nu poate traversa o regiune sau granița unui sub-proces.

BPMN 0203. Un flux de secvență condițional nu poate fi utilizat dacă elementul de modelare prezintă doar un singur flux de secvență de ieșire.

BPMN 0204. Un flux de secvență de ieșire dintr-un element de modelare parallel gateway nu poate fi condițional.

BPMN 0301. Un flux de mesaj nu poate conecta elemente de modelare ale aceluiași culoar.

BPMN 0302. Un flux de mesaj poate veni de la: un eveniment de tip message end sau un eveniment intermediar de tip message; o activitate de tip send, user sau service; Sub-proces; regiune de tip black box.

BPMN 0303. Un flux de mesaj poate fi direcționat către: un eveniment de tip message start sau un eveniment intermediar de tip message; o activitate de tip receive, user sau service; Sub-proces; regiune de tip black box.

Style 0050. O diagramă child-level nu va fi descrisă în sub-procesul expandat de care aparține ci separat.

Style 0051. Eticheta unei pagini ce conține o diagramă child-level trebuie să fie identică cu denumirea sub-procesului descris de diagramă.

Style 0103. Toate activitățile au o denumire.

Style 0104. Două activități utilizate în cadrul aceluiași proces nu pot avea aceiași denumire. Se folosește global activity pentru reutilizarea aceleiași activități în cadrul unui proces.

Style 01041. O activitate de tip send trebuie să aibă un flux de mesaj de ieșire.

Style 01042.  O activitate de tip receive trebuie să aibă un flux de mesaj de intrare.

Style 0110. Un eveniment de tip start message trebuie să aibă un flux de mesaj de intrare.

Style 01101. Un eveniment de tip start message trebuie să fie denumit astfel “Recepție [corp mesaj]”

Style 01102. Un eveniment de tip start timer trebuie să fie denumit astfel încât să reflecte planificarea în timp a procesului.

Style 01103. Un eveniment de tip start signal trebuie să fie denumit astfel încât să indice denumirea semnalului.

Style 01104. Un eveniment de tip start conditional trebuie să fie denumit astfel încât să indice condiția.

Style 01105. Un eveniment de tip Start definit într-un proces top-level trebuie denumit. Dacă un proces top-level conține mai multe evenimente de tip start toate evenimentele trebuie etichetate pentru a putea identifica condițiile alternative de declanșare a procesului.

Style 01106. Într-un sub-proces se utilizează doar un singur eveniment de tip start.

Style 01121. Un eveniment de tip boundary trebuie întotdeauna denumit.

Style 01125. Un eveniment de tip boundary Error (catching) al unui sub-proces trebuie întotdeauna denumit identic cu evenimentul throwing error asociat.

Style 01128. Un eveniment de tip boundary Escalation (catching) al unui sub-proces trebuie întotdeauna denumit identic cu evenimentul throwing escalation asociat.

Style 0115. Un eveniment intermediar de tip throwing trebuie etichetat.

Style 01161. Un eveniment intermediar de tip catching trebuie etichetat.

Style 0122.  Un eveniment de tip catching message trebuie să prezinte flux de mesaj de intrare.

Style 0123. Un eveniment de tip throwing message trebuie să prezinte flux de mesaj de ieșire.

Style 0127. Două evenimente de tip end nu pot fi etichetate la fel în cadrul aceluiași proces. Dacă au aceiași semnificație se îmbină fluxul către un singur eveniment altfel se etichetează diferit.

Style 0129. Un eveniment de tip end trebuie denumit astfel încât să reflece starea finală.

Style 0135. Un element de modelare gateway de tip inclusive, exclusive sau event nu poate avea decât cel mult o rută neetichetată.

Style 0136. Un element de modelare gateway de tip inclusive, exclusive sau event ar trebui să aibă toate rutele etichetate.

Style 0137. Dacă un sub-proces este urmat de către un element de modelare gateway ce are rutele etichetate “Da și Nu” cel puțin unul din evenimentele de tip end ale sub-procesului trebuie să aibă aceiași denumire cu a elementului de modelare gateway.

Style 0304. Un flux de mesaj trebuie să fie etichetat cu numele mesajului propriu-zis.

Style 0305. Un flux de mesaj de la un sub-proces de tip collapsed trebuie replicat în diagrama child-level.

Style 0306. Un flux de mesaj către un sub-proces de tip collapsed trebuie replicat în diagrama child-level.

Style 0307. Un flux de mesaj de intrare într-o diagramă child-level trebuie replicat în diagrama parent-level.

Style 0308. Un flux de mesaj de ieșire dintr-o diagramă child-level trebuie replicat în diagrama parent-level.

Aplicarea acestor reguli de bună practică nu garantează crearea unui model de proces valid. BPMN oferă posibilitatea creării unor diagrame care evident sunt orientate graf ce prezintă un grad mare de flexibilitate în descrierea unor procese complexe spre deosebire de standardul executabil BPEL4WS care este orientat bloc. Această flexibilitate poate genera modele care nu pot fi executate sau care la execuție vor avea un comportament diferit de ceea ce analistul dorește. Aceste probleme de modelare apar datorită faptului că nu există o conexiune puternică între elementele de modelare care bifurcă sau îmbină fluxul. O structură de tip bloc oferă o astfel de relație dar o structură de tip graf permite combinarea la discreție a acestor elemente de control al fluxului. Un exemplu (Figura 101) în acest sens se întâmplă dacă rute alternative traversează granița implicită a unui grup de rute sincronizate ale fluxului.

Figura 101. Model invalid (gateway) [OMG1,2009].

În Figura 101 activitatea D prezintă două fluxuri de secvență de intrare: un flux rutat prin activitatea A și un flux rutat prin activitatea B după element de modelare exclusive gateway. Dacă analizăm situația în care se alege alternativa Da atunci ne așteptăm ca fluxul de secvență de la activitatea B să traverseze granița bifurcației create după activitatea A și ca rezultat activitatea E va recepționa două fluxuri de secvență de intrare – de la activitatea C și D. Dacă analizăm situația în care se alege alternativa Nu atunci ne așteptăm ca fluxul de secvență să fie rutat astfel încât activitatea E să recepționeze doar flux de secvență de la activitatea D. Deoarece un element de modelare parallel gateway așteaptă întotdeauna două fluxuri de secvență procesul se va bloca în acel punct.

Un alt exemplu de model invalid este cel prezentat în Figura 102. În acest caz problema rezidă în utilizarea incorectă a unor întoarceri pe flux. Dacă decizia de realizare a unei bucle este luată în granița unui set de rute paralele atunci comportamentul în buclă devine ambiguu deoarece nu este clar dacă activitatea E se va repeta sau ce se întâmplă dacă activitatea E încă e activă la întoarcerea din buclă.

Figura 102. Model invalid (Buclă) [OMG1,2009].

Alte probleme mai pot apare și la utilizarea evenimentelor de tip link de aceea este important să se verifice modalitatea de rutare a fluxului la utilizarea lor pentru a ne asigura că modelul este unul valid și poate fi mapat BPEL4WS.

3.6. Exemple de diagrame BPMN

Așa cum am anunțat anterior cu ajutorul BPMN putem realiza o singură diagramă pentru un proces de afaceri numită BPD. Pentru a modela fluxul specific unui BP se descriu evenimentele care determină activarea unui proces, activitățile sau sub-procesele care se execută și evenimentele care încheie procesul respectiv. Punctele de decizie așa cum am anunțat anterior sunt modelate cu ajutorul elementelor de modelare gateway.

Exemplele prezentate în continuare sunt create cu scopul de a evidenția modalitatea de utilizare a elementelor de modelare BPMN. Aceste modele nu conțin procese executabile ci sunt procese prin care sunt reprezentate aspecte organizaționale ale proceselor de afaceri.

Exemplul 1

Procesul care va fi modelat în continuare îl vom intitula Aprobarea investițiilor în punctele de lucru [AuraPortal, 2012].

Abordare: un responsabil al punctului de lucru dorește să obțină aprobare pentru realizarea unor noi investiții și pentru aceasta este necesar să completeze un formular care să conțină date relevante referitoare la investiția dorită.

La completarea acestui formular numit Cerere pentru Aprobarea investițiilor în punctele de lucru trebuie să se genereze un mesaj care să declanșeze procesul Aprobarea investițiilor în punctele de lucru. Odată ce procesul se declanșează o sarcină numită Revizuirea primei aplicări trebuie adăugată în coada de așteptare a sarcinilor managerului punctelor de lucru. Când managerul punctelor de lucru va accesa sarcina, va examina datele furnizate în mesaj.

După luarea unei decizii, acesta va completa un formular unde se anunță decizia de aprobare sau respingere a cererii:

Dacă investiția nu este aprobată trebuie să redirectăm fluxul către un element de modelare service task numit Respingere cerere și procesul se încheie. Această activitate notifică responsabilul punctului de lucru în legătură cu respingerea cererii.

Figura 103. Aprobarea investițiilor în punctele de lucru – Exemplul 1.

Dacă investiția se aprobă de către manager, fluxul este redirectat către un nou punct de decizie în vederea solicitării unei a doua aprobări care se obține de la un manager de divizie. Pentru a lua această decizie trebuie luate în considerare două criterii: cât de mare este investiția și riscul de țară asociat punctului de lucru respectiv.

Dacă o a doua aprobare nu este necesară fluxul este redirectat în sensul creării unui document Aprobare cerere semnat digital de către manager; după ce se consemnează momentul în care se aprobă cererea se declanșează alte procese ale companiei care vizează realizarea propriu-zisă a investiției pentru ca la final să se realizeze înregistrările contabile aferente investiției.

Dacă o a doua aprobare este necesară fluxul, cererea trebuie să fie trimisă numai în intervalul orar 10.00-12.00 a zilei de Luni sau Vineri, cu alte cuvinte procesul este amânat până când managerul de divizie examinează cererea deja aprobată de către manager pentru a lua propria decizie.

Exemplul 2

Procesul care va fi modelat în continuare îl vom intitula Planificarea unei călătorii [ArisCommunity, 2013]. Există numeroase activități pe care le desfășurăm în momentul în care dorim să planificăm o călătorie. Motiv pentru care este necesar ca după plasarea elementului de modelare start event să inserăm un element de modelare parallel gateway. Vom utiliza un element de modelare user task Rezervă zbor și un element de modelare service task Rezervă hotel.

Rezervarea hotelului se realizează de către o agenție de voiaj și ca atare vom modela această interacțiune utilizând o regiune.

Regiunea Agenția de voiaj va avea două culoare Angajat agenție și Serviciu relații cu clienții. Vom plasa un element de modelare start event de tip message în interiorul culoarului Angajat agenție pentru a iniția o conversație. Acest eveniment va fi conectat cu un element de modelare user task Verifică date client.

Vom plasa un element de modelare send task Rezervă cameră hotel în interiorul culoarului Serviciu relații cu clienții pe care îl vom conecta cu un element de modelare receive task Confirmare de primire.

Vom plasa un element de modelare user task numit Compune răspuns în interiorul culoarului Angajat agenție pe care îl vom conecta cu un element de modelare message end event pentru a evidenția că această parte a procesului s-a încheiat cu trimiterea unui mesaj.

Vom conecta Verifică date client cu Rezervă cameră hotel și Confirmare de primire cu Compune răspuns.

Vom conecta Rezervă hotel cu evenimentul de start din interiorul culoarului Angajat agenție.

Vom conecta message end event din interiorul culoarului Angajat agenție cu Rezervă hotel.

În acest moment am finalizat modelarea acestei comunicări.

Hotelul va trebui să confirme rezervarea. Ca atare vom introduce o nouă regiune în care vom modela o cerere către hotel, procesarea acesteia și trimiterea unui răspuns.

În ceea ce privește modalitatea de a călători va trebui să modelăm un flux standard și unul alternativ în care vom modela posibilitatea de a călători cu mașina personală fără a opta pentru cazare. Pentru aceasta vom verifica ruta și vom modela un eveniment intermediar de compensare pentru anularea rezervării realizate pentru zbor și hotel.

Figura 104. Planificarea unei călătorii [ArisCommunity, 2013] – Exemplul 2.

Exemplul 3

Procesul care va fi modelat în continuare îl vom intitula Planificarea unui transport de bunuri. În acest exemplu utilizăm doar o regiune și trei culoare pentru participanții implicați în proces ceea ce înseamnă că nu modelăm și comunicarea dintre aceștia, presupunând că ea există într-o formă sau alta.

Dacă am utiliza un motor de procese, acesta ar gestiona comunicarea dintre participanți prin atribuirea de elemente de modelare user task. Dacă nu dispunem de un astfel de motor de procese dar dorim totuși să modelăm comunicarea dintre participanți putem crea o diagramă de colaborare.

Evenimentul de start Bunuri de expediat indică faptul că marfa deja a fost pregătită pentru expediere. Imediat după instanțierea procesului se vor desfășura două acțiuni în paralel așa cum anunță și elementul de modelare parallel gateway: un funcționar va trebui să decidă dacă acesta este un transport normal sau special, timp în care, un manipulator împachetează produsele pentru expediere. Sarcina executată de către funcționar și urmată de un element de modelare exclusive gateway este un bun exemplu pentru a clarifica modalitatea corectă de utilizare a elementelor de modelare gateway: acestea sunt responsabile doar de rutarea fluxului ca urmare a unei sarcini sau activități anterioare și oferă alternative.

Figura 105. Planificarea unui transport de bunuri [OMG, 2010] – Exemplul 3.

Elementul de modelare gateway este exclusive deoarece numai una dintre cele două alternative oferite poate fi traversată: dacă avem nevoie de un transport special funcționarul Solicită costuri de expediție de la diverși transportatori, Atribuie un transportator și apoi creează documenția necesară, altfel funcționarul trebuie să verifice dacă este necesară întocmirea unei polițe de asigurare suplimentare. Dacă acest lucru este adevărat managerul trebuie să se ocupe de obținerea acesteia. În oricare din cazuri funcționarul trebuie să creeze o etichetă poștală pentru colet. Din acest motiv utilizăm elementul de modelare gateway inclusive deoarece trebuie să marcăm faptul că cele două alternative se execută sincron dacă se îndeplinesc cele două condiții de rutare ale fluxului. Datorită acestui paralelism avem nevoie de elementul de modelare de sincronizare inclusive gateway imediat după Creare etichetă poștală și sub-procesul Achiziționează poliță.

Exemplul 4

Exemplul care urmează exemplifică o colaborare B2B. Deoarece dorim să modelăm interacțiunea dintre un client și un vânzător în mod explicit trebuie să creăm o regiune pentru fiecare dintre acești doi participanți.

Figura 106. Colaborare B2B [OMG, 2010] – Exemplul 4.

Clientul selectează un produs, îl comandă și așteaptă expedierea acestuia. Elementul de modelare gateway plasat după activitatea Comandă produs indică faptul că participantul așteaptă două evenimente care se pot întâmpla: produsul este expediat imediat sau cu întârziere. După 60 minute clientul apelează telefonic vânzătorul. Presupunem că funcționarul promite expedierea produsului și clientul așteaptă din nou ca acesta să fie expediat. Din perspectiva vânzătorului acesta trebuie doar să expedieze produsul, să încaseze banii și să ofere o chitanță clientului.

În acest exemplu utilizăm elemente de modelare message nu numai pentru cazul informal cum ar fi realizarea comenzii ci și pentru obiecte fizice cum sunt produsul în sine sau banii. Putem face acest lucru deoarece aceste elemente de modelare sunt purtătoare de informație și nu modelăm un proces executabil.

Exemplu 5

Scenariul descris în Figura 107 este următorul [Tay,2013]:

1. Candidatul începe căutarea unui loc de muncă.

2. Candidatul redactează o solicitare de loc de muncă.

3. Solicitarea a fost trimisă către o companie. Candidatul așteaptă o confirmare de primire.

4. Compania a primit solicitarea de la candidat.

5. Compania redactează o confirmare de primire.

6. Confirmarea de primire a fost trimisă către candidat.

7. Candidatul a primit confirmarea de la companie. Candidatul așteaptă o invitație de participare la interviu sau o notificare de respingere.

8. Compania verifică solicitarea.

9.1. Dacă respectivul candidat nu este potrivit pentru locul de muncă solicitat.

9.1.1. Compania respinge solicitarea

9.1.2. Un mesaj de respingere a fost transmis către candidat

9.1.3. Notificarea de respingere a fost recepționată de către candidat.

9.1.4. Candidatul a fost respins de către companie.

9.2. Dacă aplicantul este potrivit pentru locul de muncă solicitat:

9.2.1. Compania invită candidatul la un interviu

9.2.2. Invitația de participare la interviu a fost transmisă către candidat. Compania așteaptă o confirmare a datei programate pentru interviu.

9.2.3. Invitația de participare la interviu a fost recepționată de către candidat.

9.2.4. Candidatul confirmă data programată pentru interviu.

9.2.5. Confirmarea datei programate pentru interviu realizată de către candidat a fost trimisă către companie.

9.2.6 Confirmarea datei programate pentru interviu realizată de către candidat a fost recepționată de către companie.

9.2.7. Timpul necesar până la data programată a interviului a trecut.

9.2.8. Candidatul ia parte la interviu, primește întrebări și oferă răspunsuri. Compania realizează interviul adresează întrebări și primește răspunsuri.

9.2.9. Interviul se finalizează.

Acest scenariu poate fi descris sub forma unei colaborări.

Temă – Realizați coreografia aferentă acestei colaborări.

Figura 107. Solicitarea unui loc de muncă – Colaborare – Exemplul 5.

Exemplul 6

Procesul care va fi modelat în continuare îl vom intitula Managementul comenzilor. Acest proces începe după recepționarea unei cereri și continuă cu verificarea disponibilității produsului respectiv.

Figura 108. Managementul comenzilor [OMG, 2010] – Exemplul 6.

Dacă articolul se regăsește pe stoc atunci acesta este expediat clientului împreună cu un Acord financiar modelat în această diagramă ca sub-proces. În cazul în care articolul nu este disponibil acesta va fi comandat prin apelarea sub-procesului Procurare.

Să observăm ca reprezentarea utilizată este cea a unui element de modelare call activity. O altă caracteristică a acestui sub-proces este faptul că are atașate două evenimente cu ajutorul cărora putem gestiona situații care pot apare spontan la momentul execuției unei activități sau a unui sub-proces. De aceea este necesar să facem distincție între evenimentele întreruptibile și cele non-întreruptibile. Spre deosebire de evenimentele întreruptibile cele non-întreruptibile nu opresc execuția activității sau sub-procesului la care sunt atașate.

Procesul Managementul stocului este declanșat de către un eveniment condițional. Aceasta înseamnă că procesul este instanțiat în cazul în care condiția devine adevărată, în acest caz dacă stocul are o valoare sub limita minimă stabilită. Pentru a crește nivelul stocului este necesară achiziționarea articolului. Ca atare vom utiliza același proces Procurare din BPD anterioară și o vom referi prin elementul de modelare call activity cu același nume. Similar cu procesul anterior modelăm și situația în care articolul nu poate fi achiziționat și trebuie retras din catalog.

Figura 109. Managementul stocului [OMG, 2010] – Exemplul 6.

În continuare voi descrie sub-procesul Procurare utilizat în ambele procese descrise mai sus. Deoarece acesta este un sub-proces evenimentul de start nu prezintă un tip anume indicând astfel că procesul nu este declanșat de un eveniment extern ci că face referire la procese aflate pe un nivel superior. Prima activitate din acest sub-proces este de a verifica dacă articolul este disponibil la furnizor. Dacă nu este disponibil la furnizor se va genera un eveniment Indisponibil de tip error. În cazul în care achiziționarea articolului durează mai mult de două zile, se modelează acest lucru utilizând un eveniment de escalare de tip throw pentru a permite referirea către procesele de pe nivelul imediat superior. Similar evenimentului de tip error evenimentul de escalare are asociat un cod necesar pentru conectarea evenimentelor de escalare de tip catch și throw. Contrar evenimentelor de tip error firele de execuție active nu sunt afectate de către evenimentele intermediare de escalare de tip throw (evenimentul de escalare de pe granița sub-procesului Procurare în procesul părinte este de tip non-interrupting). Mai mult procesul își continuă execuția deoarece se așteaptă livrarea.

Figura 110. Sub-procesul Procurare [OMG, 2010] – Exemplul 6.

Exemplul 7

În continuare voi prezenta cum se pot obține perspective diferite a aceluiași proces utilizând BPMN. În primul pas voi prezenta o diagramă pentru un proces de gestionare a unei situații excepționale care poate surveni la un moment dat într-o organizație. Apoi, voi rafina acest model prin transferarea de la orchestrație la colaborare și apoi la coreografie. Scopul acestui exemplu este de a crea diagrame simple și abstracte dar și pentru a detalia colaborarea și a crea specificații tehnice necesare execuției unui proces.

Procesul descris în Figura 111 este declanșat de către un client care solicită ajutor din partea managerului de cont asociat în legătură cu un produs achiziționat. Managerul va încerca să gestioneze situația singur și să explice clientului modalitatea de rezolvare a problemei sale. Dacă nu reușește va transmite problema unui agent din departamentul de relații cu clienții de nivel 1, iar acesta la rândul său la un coleg din departamentul de relații cu clienții de nivel 2 dacă este necesar. Acesta din urmă poate întreba un coleg din departamentul de dezvoltare în cazul în care nu este sigur că acest client poate rezolva singur problema. Această diagramă reflectă situația fericită în care se găsește o rezolvare problemei clientului. Modelul nu detaliază colaborarea dintre angajați iar utilizarea activităților abstracte denotă faptul că nu știm care din părțile acestui proces sunt executabile. Această diagramă este utilă pentru a înțelege scopul procesului, fluxul acestuia, dar nu este utilă dacă dorim să îmbunătățim procesul respectiv.

Figura 111. Privire de ansamblu a procesului Gestionarea unei situații excepționale [OMG, 2010] – Exemplul 7.

În Figura 112 am creat o diagramă de colaborare mult mai detaliată care ne permite vizualizarea tuturor proceselor participanților și de asemenea am setat activitățile ca fiind de tip manual ceea ce denotă că gândim întregul proces ca fiind non-executabil. De fapt această diagramă reflectă starea as-is a procesului. Următorul pas în demersul nostru este de a decide dacă întreaga colaborare descrisă în diagramă va face subiectul unui motor de procese sau doar o parte din ea. Înainte de a lua acestă decizie putem crea o coreografie (Figura 113) care să reflecte doar activitățile care sunt dedicate comunicării dintre participanți, ascunzând celălalte activități.

Diagramele din Figura 111 și 112 nu au nici o conexiune formală între ele spre deosebire de Figura 112 și 113 care reprezintă același model semantic dar perspective diferite.

Figura 112. Colaborarea detaliată a procesului Gestionarea unei situații excepționale [OMG, 2010] – Exemplul 7.

Figura 113. Coreografia procesului Gestionarea unei situații excepționale [OMG, 2010] – Exemplul 7.

Dacă dorim să automatizăm procesul prezentat putem în acest moment să decidem care părți din acesta ar trebui executate într-un motor de procese și care nu. Vom considera un scenariu în care managerul de client nu va fi deranjat cu formulare web sau liste de sarcini, acesta având doar responsabilitatea de a trimite un mesaj electronic dacă dorește să raporteze o problemă a clientului și să primească un răspuns când această problemă a fost rezolvată. Aceiași idee se aplică și dezvoltatorului, care vom presupune că se află în aceiași cameră cu agentul din departamentul de relații cu clienții nivel 2 și ca atare această colaborare nu va fi automatizată.

Figura 114. Automatizare parțială a procesului Gestionarea unei situații excepționale [OMG, 2010] – Exemplul 7.

În schimb, cererile către agenții din departamentul de suport vor fi automatizate prin introducerea unui sistem care să preia rolul de motor de procese și ca atare va fi modelat într-o regiune separată. Acest sistem poate recepționa și analiza un mesaj electronic trimis de către managerul de client și genera o cerere de tratare a problemei.

Dacă agentul din departamentul de relații cu clienții nivel 1 consideră că este o problemă care poate fi tratată doar la nivel 2, acesta își va documenta decizia și va finaliza sarcina Editează cerere la nivel 1. Această cerere este mai departe rutată către agentul din departamentul de relații cu clienții nivel 2 și când acest agent finalizează propria analiză poate decide că această problemă nu poate fi rezolvată decât la lansarea următoarei versiuni a produsului. În acest moment sistemul propus va realiza un apel către sistemul care monitorizează și înregistrează cererile nesoluționate referitoare la produsul software și va solicita realizarea unei noi înregistrări. La final sistemul va trimite un email către managerul de client care conține soluția problemei și va închide cererea.

Această modalitate de a modela fluxurile automatizate și cele manuale reprezintă una din posibilitățile care există și demonstrează cum poate BPMN să asigure suportul pentru alinierea Business–IT din perspectiva modelării proceselor. Astfel, în timp ce utilizăm un motor de procese putem de asemenea să prezentăm separat pentru toți participanții regiunile asociate lor în cadrul colaborării astfel încât să se poate discuta nivelul de implicare a acestora fără necesitatea de a prezenta întregul model de colaborare (figura următoare). Astfel se poate discuta modelul propus fără a aglomera nici una din părțile implicate (Business și IT) cu diagrame complexe.

Figura 115. Automatizare parțială a procesului Gestionarea unei situații excepționale – vedere manager client [OMG, 2010] – Exemplul 7.

Figura 116. Automatizare parțială a procesului Gestionarea unei situații excepționale – ce execută motorul de procese [OMG, 2010] – Exemplul 7.

4. Comparație între notațiile oferite de UML AD și BPMN

O comparație între cele două standarde grafice utilizate în modelarea proceselor de afaceri poate fi realizată în primul rând din perspectiva obiectelor elementare ale acestora [White S.,2004], [Alaiba1,2008], [Alaiba2,2008].

Astfel, într-o BPD discutăm despre activități ordonate conectate printr-un flux de secvență iar în UML AD despre acțiuni ordonate conectate printr-un flux de control. În ambele cazuri fluxul este caracterizat de o direcție dată de sensul săgeții care interconectează două elemente de modelare. Singura diferență este forma săgeții (săgeată plină în BPMN versus săgeată simplă în UML).

BPMN oferă două mecanisme pentru modelarea activităților care se execută concurențial (mecanismul de secționare paralelă – Figura 117), spre deosebire de UML care utilizează un element de modelare fork în acest caz.

Pentru a modela sincronizarea a două activități BPMN utilizează același mecanism (parallel gateway), spre deosebire de UML care utilizează un element de modelare join în acest caz. Mecanismele de sincronizare sunt similare doar notațiile diferă între cele două standarde.

Figura 117. Mecanisme de modelare a activităților concurențiale în BPMN.

Pentru modelarea fluxurilor alternative (mecanismul de alegere exclusivă) BPMN utilizează exclusive gateway iar UML AD utilizează elementul de modelare decision. Mecanismele de alternare a fluxurilor sunt similare la fel ca și notațiile utilizate.

Pentru a modela o îmbinare simplă a două fluxuri BPMN oferă două mecanisme (Figura 118) iar UML utilizează elementul de modelare merge. Dacă se utilizează un element de modelare exclusive gateway pentru îmbinarea simplă cele două standarde nu diferă [Alaiba1,2008].

Figura 118. Mecanisme de modelare a îmbinării simple a activităților în BPMN.

Pentru a modela o alegere multiplă în BPMN se poate apela la două mecanisme prezentate în Figura 119 spre deosebire de UML care oferă o singură modalitate de modelare utilizând un element de modelare fork (Figura 120). Spre deosebire de BPMN, notația utilizată în UML AD poate genera confuzii deoarece în afara de decizia în sine de rutare a fluxului (nu se utilizează elementul de modelare decision) se sugerează și ideea de paralelism datorită utilizării elementului de modelare fork [Alaiba1,2008].

Figura 119. Mecanisme de modelare a alegerii multiple în BPMN.

Figura 120. Mecanismul de modelare a alegerii multiple în UML AD.

Modelarea îmbinării multiple în BPMN este prezentată în Figura 121 iar în UML AD în Figura 122. În cazul mecanismului prezentat în Figura 121 pentru fiecare flux de secvență de intrare a activității D se va crea o nouă instanță a acestei activități. În UML AD același efect se obține prin utilizarea elementului de modelare merge node conform șablonului prezentat în Figura 122 [Alaiba1,2008].

Figura 121. Mecanismul de modelare a îmbinării multiple în BPMN.

Figura 122. Mecanismul de modelare a îmbinării multiple în UML AD.

Ambele mecanisme de modelare pot crea confuzii de aceea este indicat să se realizeze precizări suplimentare la utilizarea acestor construcții.

Pentru a îmbina fluxuri de secvență rezultate în urma unei execuții concurente în BPMN se utilizează un element de modelare exclusive gateway (Figura 123) spre deosebire de UML unde putem utiliza un element de modelare join node dar pentru care vom marca condiții de rutare (Figura 124). Datorită utilizării elementului de modelare exclusive gateway activitatea D va avea un singur flux de secvență de intrare (Figura 123) [Alaiba1,2008].

Figura 123. Îmbinarea fluxurilor de secvență rezultate în urma unei execuții concurente în BPMN.

Figura 124. Îmbinarea fluxurilor de control rezultate în urma unei execuții concurente în UML.

Analiza celor două construcții de mai sus evidențiază faptul că BPMN oferă o posibilitate de modelare mult mai simplă decât UML.

Construcția UML care reflectă mecanismul unui element de modelare complex gateway (Figura 125) utilizat în BPMN este prezentată în Figura 126. După cum se observă în ambele cazuri este necesară marcarea unor condiții de rutare dar spre deosebire de UML, BPMN oferă un element de modelare dedicat acestui scenariu.

Figura 125. Mecanismul de rutare a fluxului de secvență utilizând un complex gateway în BPMN.

Figura 126. Mecanismul de rutare a fluxului de control utilizând un join node în UML (pentru simularea unui complex gateway în BPMN).

În BPMN, construcția synchronizing merge este utilizată când dorim ca într-un nod al procesului să îmbinăm fluxul a două sau mai multe activități ce se desfășoară sincron.

Figura 127. Mecanismul de modelare a îmbinării sincronizate în BPMN.

Construcția UML care modelează îmbinarea sincronizată a fluxurilor de control este prezentată în Figura 128 și după cum se observă se utilizează tot elementul de modelare join node.

Figura 128. Mecanismul de modelare a îmbinării sincronizate în UML.

Să presupunem scenariul BPMN prezentat în Figura 129 care conține modalitatea de modelare a unei bucle. Similar se poate modela și în UML AD cu precizarea că întoarcerea pe fluxul de control trebuie întodeauna modelată cu ajutorul unui element de modelare merge node (un element de modelare activity în BPMN poate avea mai multe fluxuri de secvență de intrare și ca atare nu este obligatoriu să utilizăm un element de modelare gateway pentru îmbinarea fluxurilor de secvență dintr-o buclă).

Figura 129. Mecanismul de modelare a unei bucle simple în BPMN[White S.,2004].

Figura 130. Mecanismul de modelare a unei bucle simple în UML[White S.,2004].

Elementul de modelare BPMN end event are ca și corespondent în UML AD elementul de modelare flow final node. Diferența dintre cele două elemente de modelare este dat de faptul că în BPMN se poate preciza un tip al evenimentului și astfel putem realiza o descriere mai detaliată a motivului încheierii fluxului respectiv (cancel, error, etc.) [White S.,2004].

Figura 131. Mecanismul de modelare implicit termination în BPMN.

Figura 132. Mecanismul de modelare implicit termination în UML AD.

Construcțiile care urmează descriu cum poate fi o activitate instanțiată de un număr (cunoscut) de ori în paralel. Cu alte cuvinte, analistul știe de câte ori trebuie executată o anumită activitate și poate seta acest număr (motiv pentru care mecanismul se mai numește și instanțe multiple cu o cunoaștere design time a priori). Definiția acestui șablon nu descrie exact ce se întâmplă după ce activitatea a fost declanșată (dacă fluxurile vor fi sincronizate sau nu).

Elementul de modelare specific UML AD corespondent ca funcționalitate cu parallel multi-instance task specific BPMN este expansion region cu atributul concurency setat pe parallel. Figurile 133 și 134 evidențiază diferența majoră de notație. În UML AD este posibil ca elementul de modelare expansion pin setat pe expansion region să se confunde cu alte elemente de modelare cum ar fi input/output pin [White S.,2004], [Alaiba1,2008], [Alaiba2,2008].

Figura 133. Mecanismul de modelare parallel multi-instance în BPMN.

Figura 134. Mecanismul de modelare parallel multi-instance în UML AD.

Construcțiile din Figurile 135 și 136 sunt similare celor descrise mai sus cu precizarea că de data aceasta analistul nu știe de câte ori trebuie executată o anumită activitate și nu poate seta acest număr la design time (motiv pentru care mecanismul se mai numește și instanțe multiple cu o cunoaștere run time a priori). Acest șablon permite execuția secvențială dar și în paralel a activităților. Exemplele ce urmează descriu execuția secvențială a activităților. Astfel, elementul de modelare specific UML AD corespondent ca funcționalitate cu standard loop task specific BPMN este expansion region cu atributul concurency setat pe iterative. Condiția de rutare a buclei poate fi setată pentru a se putea determina dinamic numărul de repetări ale activității. Figurile 135 și 136 evidențiază diferența majoră de notație.

Figura 135. Mecanismul de modelare standard loop în BPMN.

Figura 136. Mecanismul de modelare standard loop în UML AD.

Construcțiile ce urmează diferă de cele două prezentate mai sus prin aceea că numărul de repetări se determină în timpul execuției activității (motiv pentru care mecanismul se mai numește și instanțe multiple fără o cunoaștere run time a priori). Pentru a modela acest comportament nu mai putem apela la un simplu element de modelare cum ar fi standard looping task sau multi-instance task ci avem nevoie de o construcție complexă repetitivă descrisă în Figura 137. În această figură numărul de activități B este determinat de activitatea C. Finalizarea activității B nu este necesară înainte de finalizarea iterației dar este necesar ca toate activitățile B să se realizeze înainte de a continua fluxului spre activitatea D.

Figura 137. Mecanismul de modelare a unei bucle complexe în BPMN [White S.,2004].

Figura 138. Mecanismul de modelare a unei bucle complexe în UML [White S.,2004].

După cum se observă din Figurile 137 și 138 mecanismele de modelare a scenariului prezentat sunt identice doar descrierea grafică e diferită în cele două standarde.

Mecanismele de modelare prezentate în Figurile 133 și 134 se utilizează și dacă dorim ca toate activitățile desfășurate în paralel să se finalizeze (să fie sincronizate) înainte ca procesul să continue. Mecanismul se mai numește și instanțe multiple cu sincronizare iar diferența dintre acesta și mecanismul instanțe multiple cu o cunoaștere run time a priori este dată de faptul că se așteaptă finalizarea activității repetitive (instanțe multiple executate în paralel) și sincronizarea fluxurilor astfel generate înainte de continuarea procesului.

Mecanismul de modelare al elementului BPMN event based gateway (prezentat și exemplificat în capitolele anterioare) este descris utilizând standardul UML printr-o configurație formată din următoarele elemente de modelare (Figura 139): fork node, interruptible region, interrupting edge și receive signal action. În punctul în care decizia trebuie luată element de modelare fork node creează un număr de rute paralele egal cu numărul de alternative. Aceste rute traversează interruptible region și fiecare dintre acestea sunt conectate la un element receive signal action. Când primul semnal va apare, acesta va părăsi regiunea (prin interrupting edge) și în felul acesta orice alt semnal va fi blocat [White S.,2004].

După cum se observă mecanismele prezentate diferă. Ideea de decizie este mult mai evidentă în cazul notației BPMN (care utilizează un element de modelare gateway) decât notația UML (care utilizează un element de modelare fork node).

Figura 139. Mecanismul de modelare al elementului BPMN event based gateway utilizând UML [White S.,2004].

Elementul de modelare ad-hoc sub-process specific BPMN este o colecție de activități care pot fi realizate în orice ordine. Analistul setează o condiție care trebuie îndeplinită înainte de finalizarea activităților. Activitățile unui astfel de sub-process de obicei se desfășoară în mod secvențial datorită faptului că împart aceleași resurse.

UML AD nu prezintă un element de modelare similar ca și concept cu ad-hoc sub-process specific BPMN. O metodă prin care se poate obține același comportament ar fi prin utilizarea unei construcții similare celei descrise în Figura 140. Dacă se adaugă fiecărei activități un element de modelare constraint astfel încât acestea să utilizeze aceleași resurse, întregul mecanism va funcționa ca și cum două cele două activități nu pot să se desfășoare în același timp (deși activitățile sunt plasate în interiorul unui element de modelare fork/join node).

Figura 140. Mecanismul de modelare al elementului BPMN Ad-hoc subprocess în UML AD [White S.,2004].

Într-un model de proces este nevoie să descriem situații în care un anumit eveniment a avut loc sau o condiție s-a îndeplinit. Aceste evenimente sau condiții descriu conceptul de milestone. Un model de proces trebuie să identifice și să reacționeze la un milestone. Mecanismul poate fi descris prin mai multe metode datorită naturii diferite a unui milestone. În BPMN transferul informației de la o anumită parte a diagramei la o alta când nu se poate utiliza flux de secvență reprezintă un milestone. Această situație poate fi modelată utilizând evenimente de tip signal conform Figurii 141. În acest exemplu finalizarea activității B din primul sub-process este necesară înainte ca activitatea D din al doilea sub-process să se declanșeze. Evenimentul de tip signal throw ce urmează activitatea B este utilizat pentru a declanșa un eveniment de tip signal catch care precede activitatea D.

Figura 141. Mecanismul de modelare milestone în BPMN.

Figura 142. Mecanismul de modelare milestone în UML AD [White S.,2004].

După cum se observă din Figura 142 mecanismul de modelare milestone în UML AD se realizează utilizând un element de modelare interruptible region ce prezintă alte două elemente de modelare send signal action și accept event action. Deși mecanismele descrise în figurile de mai sus sunt similare, spre deosebire de UML AD, BPMN a introdus o notație pentru evenimente ceea ce face ca modelul din Figura 141 să fie vizual mult mai descriptiv.

În tabelul următor se descrie simplificat o mapare înte conceptele similare și diferențele dintre cele două metode de modelare prezentate UML AD și BPD [Sparxsystems, 2013], [White S.,2004].

Tabelul 12. UML-AD vs. BPD.

Asemănările dintre cele două tipuri de diagrame sunt evidente și ele sunt rezultatul faptului că ambele notații au fost create cu scopul de a descrie procese. Diferențele dintre cele două tipuri de diagrame rezultă din faptul că ele se adresează unor categorii diferite de utilizatori. BPMN a fost crea cu scopul de a deservi BA iar UML a fost dezvoltat pentru a standardiza analiza, proiectarea și dezvoltarea de sisteme informatice și ca atare este orientat IT BA.

O comparație între BPD și UML AD din perspectiva modelării proceselor poate fi realizată dacă optăm pentru descrierea aceluiași scenariu – un client al unei bănci accesează un bancomat.

Figura 143. Bancomat – scenariu descris utilizând UML AD.

Diagrama din Figura 143 este descrisă utilizând elemente de modelare BPMN în Figura 144.

Temă – Identificați obiectele UML AD din Figura 143 și obiectele BPMN din Figura 144 care descriu același mecanism.

Figura 144. Bancomat – scenariu descris utilizând BPMN.

5. Întrebări și răspunsuri

BPM Software se definește astfel:

Asigurarea unui suport eficient pentru procesele de afaceri utilizând metode, tehnici și software, pentru proiectarea, controlul și analiza proceselor care implică oameni, organizații, aplicații, documente și alte surse de informație;

Referă setul de instrumente software care automatizează, execută și monitorizează procesele de afaceri de la început și până la sfârșit prin conectarea utilizatorilor, aplicațiilor și utilizatorilor la aplicații;

Referă o tehnologie care furnizează o diversitate de procese, cunoștințe și funcționalități analitice într-un pachet unitar oferind astfel posibilitatea organizațiilor de a crea rapid și eficient aplicații compozite.

Diferențele dintre BPM și WfM sunt:

WfM este o disciplină de management iar BPM îi asigură suportul tehnologic;

Componentele WfM reprezintă un subset al ciclului de viață al BPM diferența majoră constând din existența fazei de diagnoză;

Componentele WfM reprezintă un subset al ciclului de viață al BPM diferența majoră constând din existența fazei de implementare a proceselor;

Componentele WfM reprezintă un subset al ciclului de viață al BPM diferența majoră constând din existența fazei de configurare a sistemului.

Diferențele dintre BPM și SOA sunt:

Procesele SOA facilitează coordonarea sistemelor distribuite care oferă suport proceselor de afaceri;

Servicii web interconectate facilitează coordonarea sistemelor distribuite care oferă suport proceselor SOA;

Procesele de afaceri facilitează coordonarea sistemelor distribuite care oferă suport proceselor SOA.

BPEL este un standard:

Grafic;

Pentru execuție;

Pentru Business Process Monitoring;

Pentru Business Process Automation.

Diferențele dintre UML AD și BPMN BPD sunt:

BPMN BPD utilizează mai puține elemente de modelare pentru a reprezenta procese complexe;

UML AD solicită cunoștințe tehnice analiștilor;

UML AD utilizează mai puține elemente de modelare pentru a reprezenta procese complexe;

BPMN BPD solicită cunoștințe tehnice analiștilor.

Completați următoarea frază: BPM „organizează ___A____ pentru o eficiență sporită” în timp ce SOA „organizează ____B____ pentru o eficiență sporită”;

A-oameni B-tehnologii;

A-tehnologii B-oameni;

A-procese, B-tehnologii;

A-tehnologii, B-procese.

XPDL este un standard:

Grafic;

Pentru Portabilitate;

Pentru Business Process Monitoring;

Pentru Business Process Management.

Diferențele dintre UML AD și BPMN BPD sunt:

De terminologie;

UML AD solicită cunoștințe tehnice analiștilor;

UML AD utilizează mai puține elemente de modelare pentru a reprezenta procese complexe;

BPMN BPD solicită cunoștințe tehnice analiștilor.

BP se definește astfel:

Un set de activități sau sub-procese și tranzacții secvențiale, logic relaționate menite să producă un anumit rezultat (output);

Un set de activități sau sub-procese și tranzacții paralele, logic relaționate menite să producă un anumit rezultat (output);

Un set de activități și tranzacții secvențiale și paralele, logic relaționate menite să producă un anumit rezultat (output);

Un set de activități sau sub-procese și tranzacții secvențiale sau paralele, logic relaționate menite să producă un anumit rezultat (output);

Nici o variantă nu este corectă.

BPM software deține următoarele componente:

Process Analytics;

Work Portal;

Business Analytics;

Nici o variantă nu este corectă.

BPA este:

Un standard;

Un model;

O metrică;

Nici o variantă nu este corectă.

XPDL este un standard:

Grafic;

De portabilitate;

De execuție;

De diagnoză.

BPEL este:

Un limbaj bazat pe XML prin intermediul căruia putem defini procese de afaceri prin utilizarea serviciilor web și care poate servi ca un limbaj de execuție (procese executabile) și ca un limbaj de descriere (procese abstracte);

Un standard prin intermediul căruia putem defini procese de afaceri prin utilizarea SOA și care poate servi ca un limbaj de execuție (procese executabile) și ca un limbaj de descriere (procese abstracte);

Un limbaj bazat pe XML prin intermediul căruia putem defini procese de afaceri prin utilizarea serviciilor web și care poate servi ca un limbaj de execuție (procese abstracte) și ca un limbaj de descriere (procese executabile);

Un standard prin intermediul căruia putem defini procese de afaceri prin utilizarea SOA și care poate servi ca un limbaj de execuție (procese abstracte) și ca un limbaj de descriere (procese executabile).

BPEL:

Prezintă o sintaxă ușor de implementat;

Are o sintaxa restrictivă ceea ce cauzează numeroase probleme la translatarea BPMN-BPEL;

BPEL este restrictiv în modelarea comportamentului uman în cadrul proceselor;

BPEL oferă suport pentru toate construcțiile posibile de procese;

BPEL oferă suport B2B.

Process Designer este o componentă BPM care:

Execută fluxul procesului și asignează activități manuale utilizatorilor și activități automatizate către aplicații în timpul execuției;

Care realizează managementul fluxului de informații și activități dintr-un proces în conformitate cu regulile și formulele atașate acestuiaș

Furnizează un feedback continuu asupra procesului pentru ca în viitor să se poată aduce îmbunătățiri acestuia;

Permite unui utilizator instruit să analizeze și să modeleze un proces pas cu pas și să îi confere o logică.

Rules Engine este o componentă BPM care:

Execută fluxul procesului și asignează activități manuale utilizatorilor și activități automatizate către aplicații în timpul execuției;

Care realizează managementul fluxului de informații și activități dintr-un proces în conformitate cu regulile și formulele atașate acestuia;

Variantele A și B sunt corecte;

Permite unui utilizator instruit să analizeze și să modeleze un proces pas cu pas și să îi confere o logică.

Process Engine este o componentă BPM care:

Execută fluxul procesului și asignează activități manuale utilizatorilor și activități automatizate către aplicații în timpul execuției;

Execută activitățile procesului și asignează activități automate utilizatorilor și activități manuale către aplicații în timpul execuției;

Variantele A și B sunt corecte;

Nici o variantă nu este corectă.

BPM Software permite:

Utilizatorilor să partajeze activități, conținut, documente și notificări via comunități;

Utilizatorilor să folosească instrumente colaborative;

Să realizeze managementul fluxului de informații și activități dintr-un proces;

Nici una din variantele de mai sus nu este corectă.

BPM Suite permite:

Utilizatorilor să partajeze activități, conținut, documente și notificări via comunități;

Utilizatorilor să folosească instrumente colaborative;

Să realizeze managementul fluxului de informații și activități dintr-un proces;

Nici una din variantele de mai sus nu este corectă.

Care din următoarele afirmații sunt false:

EAI referă un set de practici de management destinate a îmbunătăți agilitatea și performanța funcțională într-un mediu specific proceselor de afaceri.

Aplicațiile dezvoltate cu BPM Suite sunt user-friendly, personalizate, scalabile și web-based.

Tehnologia BPM este mai avansată decât tehnologia WfM.

Tehnologia BPM este mai avansată decât tehnologia EAI.

Care din următoarele afirmații sunt adevărate:

BPM Suite reprezintă un set de practici de management destinate a îmbunătăți agilitatea și performanța funcțională într-un mediu specific proceselor de afaceri.

Tehnologia BPM este mai avansată decât tehnologia EAI.

BPM Software referă setul de instrumente software care automatizează, execută și monitorizează procesele de afaceri de la început și până la sfârșit prin conectarea aplicațiior.

Toate de mai sus variantele sunt incorecte.

Standardele pentru portabilitate nu sunt:

Utilizate pentru a asigura portabilitatea proceselor de afaceri modelate cu ajutorul a mai multor standarde grafice în același BPMS;

Utilizate pentru a asigura portabilitatea proceselor de afaceri modelate cu ajutorul unor standarde de execuție diferite pe mai multe BPMS;

Utilizate pentru a asigura translatarea standardelor grafice în standarde de execuție și invers.

Nici una din variante nu este corectă.

Standardele pentru diagnoză:

Oferă funcționalități administrative;

Oferă funcționalități de monitorizare;

Nu pot identifica probleme, audita și interoga în timp real procesele de afaceri dintr-o organizație;

Toate de mai sus variantele sunt incorecte.

Standardele grafice:

Pot evidenția șabloane și diverse lacune ale proceselor de afaceri;

Pot să restricționeze libertatea de proiectare datorită setului finit de componente existent pentru modelare;

Pot fi complet translatate în cod executabil;

Toate de mai sus variantele sunt incorecte.

Care din următoarele afirmații sunt adevărate:

Standardele grafice sunt orientate graf;

Standardele de execuție sunt orientate bloc;

Standardele pentru portabilitate sunt orientate graf;

Standardele pentru diagnoză sunt orientate bloc.

BPRI:

Este un standard de diagnoză care sigură o interfață pentru managementul întregii infrastructuri BPM;

Este un standard de diagnoză proiectat pentru a oferi o interfață comună pentru modelul de date utilizat la execuția proceselor;

Este un standard de diagnoză proiectat pentru facilitarea analizei;

Toate de mai sus variantele sunt incorecte.

BPQL:

Este un standard de diagnoză care sigură o interfață pentru managementul întregii infrastructuri BPM;

Este un standard de portabilitate care sigură o interfață pentru managementul întregii infrastructuri BPM;

Este un standard de diagnoză proiectat pentru facilitarea analizei;

Toate de mai sus variantele sunt incorecte.

Precizați care din următoarele sunt standarde pentru portabilitate:

BPDM;

BPRI, BPQL;

BPEL, BPML, WSFL;

EPC, RAD.

Precizați care din următoarele sunt standarde grafice:

XPDL, BPDM;

BPQL;

BPEL, BPML, XLANG;

EPC, RAD.

Precizați care din următoarele sunt standarde pentru diagnoză:

XPDL, XLANG;

BPRI;

BPEL, BPQL;

EPC, BPRI.

Un caz de utilizare este:

O descriere a unei funcționalități pe care o oferă sistemul;

Structura fizică a unor “lucruri” gestionate de sistem;

Surprinde o colaborare dinamică din sistem;

Nici una din variante nu este corectă.

O diagramă de stare poate conține:

Tranziții;

Relații de asociere;

Relații de dependență;

Operații;

Evenimente.

O diagramă de activitate prezintă:

Fluxul secvențelor de mesaje dintre obiecte;

Fluxul secvențelor de activități dintre obiecte;

Fluxul secvențelor de mesaje dintre clase;

Fluxul secvențelor de activități dintre clase;

Nici una din variante nu este corectă.

Un actor poate fi:

Un element de modelare în diagrama claselor;

Primar dacă gestionează o bază de date;

Activ dacă inițiază cazurile de utilizare;

Nici una din variantele de mai sus.

Relația de extindere:

O generalizare a unui use case prin adăugarea de acțiuni noi;

Folosește stereotipul <<uses>>;

Este o relație de grupare între cazuri de utilizare;

Nici una din variantele de mai sus.

Un obiect este:

O entitate despre care putem vorbi și pe care o putem gestiona;

O instanță a unei clase;

Utilizat pentru a descrie proprietățile și comportamentul claselor;

Toate variantele sunt corecte.

Care diagramă este validă în orice moment din ciclul de viață al sistemului?

Diagrama cazurilor de utilizare;

Diagrama claselor;

Diagrama de secvență;

Diagrama de colaborare.

O diagramă de activitate poate conține următoarele elemente de modelare:

Action și message;

State și message call;

Action și message call;

State și event.

Un caz de utilizare:

Este un set de secvențe de acțiuni pe care sistemul le realizează pentru a furniza o valoare unui actor particular;

Este o clasă nu o instanță a acesteia;

Este un scenariu;

Nici una din variantele de mai sus.

Figura următoare exemplifică:

O diagramă de stare;

O diagramă de activitate;

O diagramă de colaborare;

Nici una din variantele de mai sus.

O diagramă UML este:

Un graf care prezintă simboluri ale elementelor de modelare aranjate astfel încât să ilustreze o anumită parte sau un anumit aspect al sistemului;

Un graf care prezintă simboluri ale elementelor de modelare aranjate astfel încât să ilustreze un view;

Un view funcțional;

Nici o variantă nu este corectă.

UN BP poate fi descris utilizând:

Un view funcțional;

Un view non-funcțional;

Utilizând diagrame care reflectă comportamentul dinamic;

Utilizând diagrame care reflectă comportamentul static.

Un caz de utilizare:

Este o descriere a unei acțiuni;

Prezintă structura logică a sistemului;

Prezintă o funcționalitate descrisă într-o singură diagramă de activitate;

Toate variantele sunt corecte.

Un element de modelare:

Este un concept folosit în cadrul diagramelor;

Are o semantică, o definiție formală a elementului sau un înțeles exact a ceea ce reprezintă el într-un anumit context și o reprezentare grafică sau un simbol grafic cu care se reprezintă în cadrul diagramelor;

Poate fi regăsit în mai multe tipuri de diagrame și pentru fiecare context există propriile reguli;

Nici o variantă nu este corectă.

Care din următoarele afirmații este corectă:

Un caz de utilizare reprezintă o funcționalitate completă a sistemului;

Un caz de utilizare este un set de secvențe de acțiuni pe care sistemul le realizează pentru a furniza o valoare unui actor particular;

Cazurile de utilizare sunt conectate cu actorii prin asocieri de comunicare;

Nici o variantă nu este corectă.

O generalizare:

Este o asociere de comunicare;

Se utilizează în diagramele de stare;

Se utilizează pentru a modela dependența unui caz de utilizare de altul;

Nici o variantă nu este corectă.

Diagrama de stare:

Are rolul de a captura ciclul de viață al obiectelor, subsistemelor și sistemelor, prin specificarea stărilor în care se poate găsi un obiect și a evenimentelor (mesaje primite, erori, condiții care devin adevărate) care îi afectează starea de-a lungul execuției;

Descrie modul în care obiectele interacționează și comunică între ele;

Este utilizată pentru a ilustra execuția unei operații, a unui caz de utilizare sau a unui scenariu de interacțiune într-un sistem;

Nici o variantă nu este corectă.

Diagrama de activitate:

Este o variantă a diagramei de stare;

Este o cale alternativă de descriere a interacțiunilor, cu posibilitatea de specificare a acțiunilor care se vor realiza;

Este utilizată pentru a arăta ce set de acțiuni legate pot fi realizate și cum vor afecta acestea obiectele;

Nici o variantă nu este corectă.

Un view este:

O abstractizare a sistemului pentru a cărei dezvoltare se folosesc diagrame;

Un graf;

Un mecanism general al sistemului pentru a cărei dezvoltare se folosesc grafuri;

Nici o variantă nu este corectă.

Care view surprinde funcționalitatea sistemului:

Use-case view;

Logic view;

Concurrent view;

Component view;

Deployment view.

Pentru descrierea cărui view putem folosi UML AD:

Use-case view;

Logic view;

Concurrent view;

Component view;

Deployment view.

Care din următoarele afirmații este adevărată:

Relația include poate fi utilizată pentru a simplifica un caz de utilizare complex;

Relația include poate fi utilizată pentru a extrage cazuri de utilizare care reflectă un comportament similar și pot fi reutilizate și de către alte cazuri de utilizare;

Relația include poate fi utilizată numai între două cazuri de utilizare și modelează situația în care o instanță a unui caz de utilizare include întotdeauna comportamentul descris de cazul de utilizare inclus;

Toate variantele de mai sus sunt corecte.

Care din următoarele afirmații este adevărată:

O stare este definită de un nume, atribute și tranziții interne;

Starea este rezultatul unor activități anterioare realizate de obiect și de obicei este determinată de valorile atributelor și de legăturile lui cu alte obiecte;

Stările compozite pot prezenta mai multe regiuni care la rândul pot conține mai multe stări simple numite sub-stări

Toate variantele de mai sus sunt corecte.

în figura de mai jos este prezentată:

O diagramă de activitate;

O stare complexă;

O stare compozită;

O stare ce prezintă o diagramă de activitate.

Între aceste două cazuri de utilizare Înregistrare și Login se trasează o relație:

Include (săgeata orientată spre cazul Înregistrare);

Extend (săgeata orientată spre cazul Înregistrare);

Include (săgeata orientată spre cazul Login);

Extend (săgeata orientată spre cazul Login);

Există alte posibilități de modelare.

În figura următoare se reprezintă:

Un element transition;

Un eveniment;

O acțiune;

O structură de control secvențială.

Figura următoare reprezintă:

Un element transition;

Un eveniment;

O acțiune;

O structură de control secvențială.

Figura următoare reprezintă:

Flow final node;

History node;

Start node;

Initial node.

Figura următoare reprezintă:

Un element de modelare action;

Un element de modelare activity;

Un element de modelare call activity action;

Un element de modelare call action.

Figura următoare reprezintă:

Un element de modelare action;

Un element de modelare activity;

Un element de modelare call activity action;

Un element de modelare call action.

Figura următoare reprezintă:

Un element de modelare send signal action;

Un element de modelare accept event action;

Un element de modelare invocation action;

Un element de modelare accept time event action.

Figura următoare reprezintă:

Un element de modelare send signal action;

Un element de modelare accept event action;

Un element de modelare event action;

Un element de modelare accept time event action.

Figura următoare reprezintă:

Un element de modelare wait time action;

Un element de modelare accept event action;

Un element de modelare event action;

Un element de modelare accept time event action.

Elementul de modelare pin:

Este utilizat pentru a marca input-urile și output-urile unui element de modelare action;

Este utilizat pentru a marca input-urile și output-urile unui element de modelare object;

Este un element de modelare expansion node;

Poate fi utilizat doar pe granița unui element interruptible region.

Elementul de modelare object node:

Este utilizat pentru a marca input-urile și output-urile unui element de modelare action;

Este utilizat pentru a marca input-urile și output-urile unui element de modelare object;

Este utilizat pentru a descrie un object flow în cadrul unei diagrame de activitate;

Este utilizat pentru a descrie un control flow în cadrul unei diagrame de activitate.

Elementul de modelare data store:

Este utilizat pentru a marca informația ce nu va tranzita fluxul;

Este un element de modelare object node;

Este un element de modelare expansion node;

Este un central buffer node.

Elementul de modelare connector:

Este utilizat pentru a marca continuitatea unei diagrame de activitate;

Permite gruparea unor elemente de modelare;

Este utilizat pentru a descrie un object flow;

Este utilizat pentru a descrie un control flow.

Elementul de modelare interruptible activity region:

Permite gruparea unor elemente de modelare;

Este utilizat pentru a descrie un object flow;

Prezintă întotdeauna un element de modelare interrupting edge;

Este o formă de regiune care marchează execuția de tip multi-instance.

Elementul de modelare interrupting edge:

Permite gruparea unor elemente de modelare;

Este utilizat pentru a descrie un interrupting flow;

Se utilizează doar în contextul unui element de modelare interruptible activity region;

Este o formă de regiune care marchează execuția de tip multi-instance.

Elementul de modelare expansion region:

Permite gruparea unor elemente de modelare;

Nu prezintă întotdeauna elemente de modelare expansion nodes;

Este o formă de regiune care marchează doar execuția de tip multi-instance parallel;

Este o formă de regiune care marchează doar execuția de tip multi-instance stream.

Elementul de modelare expansion region:

Permite gruparea unor elemente de modelare;

Prezintă întotdeauna elemente de modelare expansion nodes;

Este o formă de regiune care marchează execuția de tip multi-instance parallel;

Este o formă de regiune care marchează doar execuția de tip multi-instance iterative.

Elementul de modelare decision:

Este reprezentat identic cu elementul de modelare join;

Este reprezentat identic cu elementul de modelare merge;

Este utilizat în cazul în care dorim să reprezentăm un flux alternativ;

Este utilizat pentru îmbinarea fluxului după rutarea acestuia printr-un element de modelare fork node.

Elementul de modelare merge:

Este reprezentat identic cu elementul de modelare fork;

Este reprezentat identic cu elementul de modelare decision;

Este utilizat în cazul în care dorim să reprezentăm un flux alternativ;

Este utilizat pentru îmbinarea fluxului.

Elementul de modelare fork node:

Este reprezentat identic cu elementul de modelare join node;

Asigură suport pentru modelarea paralelismului;

Este utilizat în cazul în care dorim să reprezentăm un flux alternativ;

Este utilizat pentru ramificarea fluxului.

Elementul de modelare join node:

Este reprezentat identic cu elementul de modelare object node;

Asigură suport pentru modelarea paralelismului;

Este utilizat pentru unificarea fluxului după acțiuni concurente;

Este utilizat pentru ramificarea fluxului.

În figura următoare Clientul a selectat opțiunea Help reprezintă:

Un element de modelare object node;

O condiție;

O constrângere;

Un element de modelare notification.

UML AD este o diagramă:

De comportament;

De structură;

De interacțiune;

Nici o variantă de mai sus nu este corectă.

Relația de generalizare:

Se poate trasa numai între actori;

Se poate trasa între actori dar și între cazuri de utilizare;

Se poate trasa numai între cazuri de utilizare;

Nu se utilizează pe diagrama use case.

În figura următoare entry/ reprezintă:

Un atribut al stării ;

O tranziție internă a stării;

O constrângere;

O sub-stare.

În figura următoare factura reprezintă:

Un atribut al activității;

O tranziție internă a acțiunii;

Un element de modelare expansion pin;

Un element de modelare pin.

Figura de mai jos descrie un proces:

Executabil;

Public;

Privat;

Nici una din variantele de mai sus.

Figura de mai jos descrie un proces:

Executabil;

Public;

Privat;

Nici una din variantele de mai sus.

Figura de mai jos descrie un proces:

Executabil;

Public;

Privat;

Colaborativ.

Figura de mai jos descrie un proces:

Colaborativ;

Executabil;

Coreografie;

Public.

Precizați ce tip de flux descrie figura:

Condițional și normal;

Normal;

Implicit și normal;

Un flux de excepție.

Precizați ce anume descrie figura din imagine:

Instanțe multiple paralele;

Instanțe multiple secvențiale;

O compensare;

O buclă.

Precizați ce anume descrie figura din imagine:

Un artifact;

Instanțe multiple secvențiale ale sub-procesului;

Un subproces ad-hoc;

O buclă.

Precizați ce anume descrie figura din imagine:

Un eveniment de tip escalation;

Un eveniment de tip conditional;

Un eveniment de tip cancel;

Un eveniment de tip error.

Precizați ce tip de eveniment descrie figura:

Intermediate boundary interrupting;

Intermediate catching;

Intermediate throwing;

Standard.

Precizați ce tip de element de modelare gateway descrie figura:

Sincronizare;

Or;

Xor;

Complex.

Precizați ce anume descrie figura din imagine:

Instanțe multiple paralele;

Instanțe multiple secvențiale;

O compensare;

O buclă.

Precizați ce este modelat în figura care urmează:

Un flux de excepție;

Process break;

O tranzacție;

Nici una din variantele de mai sus.

Precizați care modelul de proces corect descris din figura următoare:

Modelul ce conține evenimentul de tip end;

Modelul ce conține evenimentul de tip terminate;

Ambele sunt corecte;

Nici un model nu este corect.

Precizați ce tip de eveniment este utilizat în diagrama de mai jos:

Event sub-process interrupting;

Boundary interrupting;

Start;

Cancel.

Precizați ce tipuri de fluxuri sunt utilizate în diagrama de mai jos:

Sequence și normal flow;

Message flow;

Association;

Conditional și normal flow.

Câte tipuri de procese cunoașteți?

4;

5;

3;

Nici una din variante nu este corectă.

Precizați semnificația evenimentului din figura următoare:

Este utilizat pentru gestionarea compensărilor;

Precizează semnalizare de la un proces la altul;

Realizează escalare la un nivel mai ridicat de responsabilitate;

Nici o variantă nu este corectă.

Precizați care este diferența între următoarele două elemente BPMN:

Figura a Figura b

Figura a reprezintă elementul de modelare parallel gateway iar Figura b elementul de modelare exclusive gateway;

Figura a reprezintă elementul de modelare inclusive gateway iar Figura b elementul de modelare exclusive gateway;

Figura a reprezintă elementul de modelare parallel gateway iar Figura b elementul de modelare inclusive gateway;

Figura a reprezintă elementul de modelare complex gateway iar Figura b elementul de modelare exclusive gateway;

Nu există nici o diferență.

Care este diferența dintre o diagramă de conversație și o diagramă de colaborare?

O diagramă de colaborare definește comportamentul dintre participanți fără implicarea unor elemente de modelare pool sau orchestrații;

O diagramă de conversație este o formă particulară și în același timp oferă și o descriere informală a diagramei de colaborare;

O colaborare descrie interacțiunile dintre una sau mai multe entități;

Nici una din variantele de mai sus nu este corectă.

Ce tipuri de orchestrații cunoașteți?

Procese private non-executabile (interne);

Procese private executabile (interne);

Procese publice;

Coreografii;

Colaborări care pot include procese și/sau coreografii;

Conversații.

Care este diferența dintre simularea unui proces și optimizarea unui proces?

Optimizarea modelului procesului curent și compararea rezultatelor cu valorile reale de timp și costuri aferente acestuia este necesară pentru a consolida ideea că modelul procesului curent este valid;

Simularea presupune definirea de resurse pentru fiecare activitate desfășurată și timpul necesar pentru finalizarea acesteia;

Optimizarea ajută prin testarea a numeroase alternative și compararea acestor alternative în termeni de timp și costuri;

Simularea ajută prin testarea a numeroase alternative și compararea acestor alternative în termeni de timp și costuri.

Ce tip de flux este reprezentat în următoarea figură?

Sequence și normal flow;

Message flow;

Association;

Conditional și normal flow.

BPMN este utilizat:

Pentru analiza și documentația proceselor de afaceri;

Pentru proiectarea de procese executabile;

Pentru analiza sistemelor;

Pentru proiectarea de sisteme.

Procesele abstracte sunt:

Procese publice;

Procese private;

Pot fi modelate prin colaborări;

Nici una din variantele de mai sus nu este corectă.

Figura următoare descrie următoarele:

Sarcina sub-procesului nu poate fi conectată la momentul documentării;

Activitate sau sub-proces de compensare;

Activitate sau sub-proces recursiv;

Activitate recursivă.

Figura următoare exemplifică:

Un eveniment de tip escalation;

Un eveniment de tip conditional;

Un eveniment de tip error;

Un eveniment de tip compensation.

Figura următoare exemplifică:

Join;

Fork;

Process break;

Transaction.

Între un element de modelare lane și un element de modelare sub-process se poate trasa:

Un element de modelare sequence flow;

Un element de modelare association;

Un element de modelare conditional flow;

Nici una din variantele de mai sus nu este corectă.

Figura următoare exemplifică:

Join;

Fork;

Process break;

O activitate care se repetă.

O coreografie:

Definește comportamentul dintre participanți fără implicarea unor elemente de modelare pool sau orchestrații;

Se manifestă între elementele de modelare pool;

Conține activități care reprezintă un set de schimburi de mesaje care implică unul sau mai mulți participanți;

Nici una din variantele de mai sus nu este corectă.

Figura următoare descrie:

Un element de modelare message flow;

Un element de modelare association;

Un element de modelare conditional flow;

Nici una din variantele de mai sus nu este corectă.

Între un element de modelare gateway și un element de modelare sub-process se poate trasa:

Un element de modelare sequence flow;

Un element de modelare association;

Un element de modelare conditional flow;

Nici una din variantele de mai sus nu este corectă.

O orchestrație include:

Coreografii;

Colaborări;

Conversații;

Procese publice.

O colaborare poate include:

Procese publice;

Procese private;

Coreografii;

Conversații.

Procesele publice pot fi:

Executabile;

Non-executabile;

Interne;

Nici o variantă nu este corectă.

Care din următoarele afirmații este corectă:

Un proces privat poate fi delimitat într-un singur element de modelare regiune.

Fluxul de mesaje al unui proces privat poate depăși granița procesului pentru a putea evidenția astfel interacțiunea dintre mai multe procese private.

Fluxul de secvență al unui proces privat poate depăși granița procesului pentru a putea evidenția astfel interacțiunea dintre mai multe procese private.

Nici o variantă nu este corectă.

Care din următoarele afirmații este corectă:

Toate combinațiile de elemente de modelare pool, procese și coreografii sunt permise într-o colaborare.

Toate combinațiile de elemente de modelare lane, procese și colaborări sunt permise într-o coreografie.

Toate combinațiile de elemente de modelare pool, procese și colaborări sunt permise într-o coreografie.

Nici o variantă nu este corectă.

O diagramă de conversație:

Oferă o descriere informală a diagramei de colaborare;

Definește logica schimbului de mesaje;

Prezintă conversațiile în construcții de tip hexagon legând participanții (regiuni);

Nici o variantă nu este corectă.

Swimlane este:

Un element de modelare flow object;

Un culoar;

O regiune;

Un element de modelare connecting object.

Elementul de modelare din imagine reprezintă:

Un eveniment ce indică faptul că există mai multe modalități de declanșare a unui proces; este suficientă declanșarea unei singure modalități pentru a porni, continua sau opri procesul în cauză;

Un eveniment ce indică faptul că există mai multe modalități de declanșare a unui proces; este necesară declanșarea simultană a acestora pentru a porni, continua sau opri procesul în cauză;

Eveniment utilizat pentru gestionarea compensărilor;

Un eveniment ce anunță o semnalizare de la un proces la altul.

Elementul de modelare din imagine reprezintă:

Un eveniment ce indică faptul că există mai multe modalități de declanșare a unui proces; este suficientă declanșarea unei singure modalități pentru a porni, continua sau opri procesul în cauză;

Un eveniment ce indică faptul că există mai multe modalități de declanșare a unui proces; este necesară declanșarea simultană a acestora pentru a porni, continua sau opri procesul în cauză;

Un eveniment ce anunță escalare;

Un eveniment ce anunță o semnalizare de la un proces la altul.

Elementul de modelare din imagine reprezintă:

Un eveniment intermediar catching;

Un eveniment intermediar throwing;

Un eveniment intermediar boundary-interrupting;

Un eveniment intermediar boundary-noninterrupting.

Elementul de modelare din imagine reprezintă:

O activitate ce prezintă instanțe multiple paralele;

O activitate ce prezintă instanțe multiple secvențiale;

O sarcină ce prezintă instanțe multiple paralele;

O tranzacție ce prezintă instanțe multiple secvențiale.

Care din următoarele afirmații sunt corecte cu referire la figura următoare:

Inventatorul Câștigă bani … dacă obține patentul și creează prototipul;

Inventatorul Câștigă bani … dacă obține patentul sau creează prototipul;

Inventatorul nu Câștigă bani … dacă obține patentul sau creează prototipul;

Inventatorul nu Câștigă bani … dacă obține patentul și creează prototipul.

Precizați ce tip de element de modelare gateway trebuie utilizat în următorul model:

Exclusive gateway;

Inclusive gateway;

Event gateway;

Complex gateway.

Care din următoarele afirmații este corectă și completă cu referire la figura următoare:

Dacă mașina trebuie doar reparată, aceasta va putea fi condusă doar după ce a fost reparată.

Dacă mașina trebuie doar curățată, aceasta va putea fi condusă doar după ce a fost curățată.

Dacă mașina trebuie și curățată și reparată, aceasta va putea fi condusă doar după ce a fost curățată și reparată.

Nici una din variante nu este corectă.

Precizați ce tip de element de modelare gateway trebuie utilizat în următoarea figură:

G1 – parallel gateway, G2 – complex gateway, G3 – exclusive gateway;

G1 – complex gateway, G2 – parallel gateway, G3 – exclusive gateway;

G1 – parallel gateway, G2 – complex gateway, G3 – inclusive gateway;

G1 – exclusive gateway, G2 – inclusive gateway, G3 – exclusive gateway.

Care din următoarele afirmații sunt adevărate cu referire la evenimentul de tip cancel:

Poate fi utilizat pe granița unui element de modelare sub-process;

Poate fi utilizat pe granița unui element de modelare transaction sub-process;

Nu poate fi decât de tip boundary-interrupting;

Nici una din variante nu este corectă.

Precizați care este valoarea lui i la finalizarea execuției acestui proces:

5;

4;

6;

Nici una din variante nu este corectă.

Care din următoarele afirmații sunt adevărate cu referire la evenimentul din figură:

Poate fi utilizat pe granița unui element de modelare sub-process;

Poate fi utilizat pe granița unui element de modelare transaction sub-process;

Nu poate fi decât de tip boundary-interrupting;

Nu poate fi utilizat decât în granița unui element de modelare event sub-process.

Precizați care din următoarele afirmații sunt complete și adevărate:

Toate elementele de modelare utilizate în diagramă au flux de secvență de intrare dacă procesul include eveniment de start și end.

Toate elementele de modelare utilizate în diagramă au flux de secvență de intrare.

Toate elementele de modelare utilizate în diagramă în afară de evenimente de tip start, boundary și activități de compensare au flux de secvență de intrare.

Toate elementele de modelare utilizate în diagramă (în afară de evenimente de tip start, boundary și activități de compensare) au flux de secvență de intrare dacă procesul include eveniment de start și end.

Precizați care din următoarele afirmații sunt complete și adevărate:

Toate elementele de modelare utilizate în diagramă au flux de secvență de ieșire dacă procesul include eveniment de start și end.

Toate elementele de modelare utilizate în diagramă (în afară de evenimente de tip end și activități de compensare) au flux de secvență de ieșire dacă procesul include eveniment de start și end.

Toate elementele de modelare utilizate în diagramă în afară de evenimente de tip end și activități de compensare au flux de secvență de ieșire.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de start nu poate avea flux de secvență de intrare.

Un eveniment de start nu poate avea flux de mesaj de ieșire.

Un eveniment de start ce prezintă flux de mesaj de intrare va avea obligatoriu un declanșator de tip message.

Un eveniment de start nu poate avea un declanșator de tip error.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de start nu poate avea flux de secvență de ieșire.

Un eveniment de start nu poate avea flux de mesaj de intrare.

Un eveniment de start ce prezintă flux de mesaj de intrare va avea obligatoriu un declanșator de tip cancel.

Un eveniment de start nu poate avea un declanșator de tip message.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de start al unui sub-proces are un declanșator de tip none.

Un eveniment de start al unui sub-proces are un declanșator de tip conditional.

Un eveniment de start al unui sub-proces are un declanșator de tip error.

Un eveniment de start al unui sub-proces are un declanșator de tip message.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip boundary are întotdeauna un flux de secvență de ieșire.

Declanșatorul unui eveniment de tip boundary poate fi de tipul message, timer, signal, error, escalation, conditional, cancel, sau compensation.

Un eveniment de tip boundary nu poate avea flux de mesaj de ieșire.

Orice eveniment de tip boundary poziționat pe granița unui sub-proces se asociază cu un eveniment similar (același tip de declanșator) de tip catch.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip boundary are întotdeauna un flux de secvență de intrare.

Declanșatorul unui eveniment de tip boundary poate fi de tipul message, timer, signal, error, escalation, conditional, cancel, sau compensation.

Un eveniment de tip boundary nu poate avea flux de mesaj de intrare.

Orice eveniment de tip boundary poziționat pe granița unui sub-proces se asociază cu un eveniment similar (același tip de declanșator) de tip throw.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip boundary are întotdeauna un flux de secvență de ieșire.

Declanșatorul unui eveniment de tip boundary poate fi de tipul message, timer, signal, error, escalation, conditional, cancel, sau compensation.

Un eveniment de tip boundary nu poate avea flux de mesaj de ieșire.

Orice eveniment de tip boundary poziționat pe granița unui sub-proces se asociază cu un eveniment similar (același tip de declanșator) de tip catch.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip boundary error nu poate fi de tipul non-interrupting.

Orice eveniment de tip boundary escalation poziționat pe granița unui sub-proces se asociază cu un eveniment similar (același tip de declanșator) de tip throw.

Orice eveniment de tip boundary poziționat pe granița unui sub-proces se asociază cu un eveniment similar (același tip de declanșator) de tip catch.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip boundary error nu poate fi de tipul interrupting.

Orice eveniment de tip boundary escalation poziționat pe granița unui sub-proces se asociază cu un eveniment similar (același tip de declanșator) de tip throw.

Orice eveniment de tip boundary poziționat pe granița unui sub-proces se asociază cu un eveniment similar (același tip de declanșator) de tip throw.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment intermediar ce prezintă flux de mesaj de intrare nu poate avea decât un declanșator de tip message (catching).

Un eveniment intermediar ce prezintă flux de mesaj de ieșire nu poate avea decât un declanșator de tip message (throwing).

Un eveniment intermediar de tip throwing poate avea un declanșator de tipul message, signal, escalation, link sau compensation.

Un eveniment intermediar de tip catching poate avea un declanșator de tipul message, signal, timer, link sau conditional.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment intermediar ce prezintă flux de mesaj de intrare nu poate avea decât un declanșator de tip message (throwing).

Un eveniment intermediar ce prezintă flux de mesaj de ieșire nu poate avea decât un declanșator de tip message (catching).

Un eveniment intermediar de tip throwing poate avea un declanșator de tipul message, signal, escalation, link sau compensation.

Un eveniment intermediar de tip catching poate avea un declanșator de tipul message, signal, timer, link sau conditional.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment intermediar ce prezintă flux de mesaj de intrare nu poate avea decât un declanșator de tip message (catching).

Un eveniment intermediar ce prezintă flux de mesaj de ieșire nu poate avea decât un declanșator de tip message (throwing).

Un eveniment intermediar de tip throwing nu poate avea decât un declanșator de tipul message.

Un eveniment intermediar de tip catching nu poate avea decât un declanșator de tipul message.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip throwing link nu poate avea flux de secvență de ieșire.

Un eveniment de tip catching link nu poate avea flux de secvență de ieșire.

Un eveniment de tip throwing link nu poate avea flux de secvență de ieșire.

Un eveniment de tip catching link nu poate avea flux de secvență de ieșire.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip throwing link nu poate avea flux de secvență de intrare.

Un eveniment de tip catching link nu poate avea flux de secvență de intrare.

Un eveniment de tip throwing link nu poate avea flux de secvență de intrare.

Un eveniment de tip catching link nu poate avea flux de secvență de intrare.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip end nu poate avea flux de secvență de ieșire.

Un eveniment de tip end nu poate avea flux de mesaj de intrare.

Un eveniment de tip end ce prezintă flux de mesaj de ieșire trebuie să fie de tipul message.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip end nu poate avea flux de secvență de intrare.

Un eveniment de tip end nu poate avea flux de mesaj de ieșire.

Un eveniment de tip end ce prezintă flux de mesaj de ieșire trebuie să fie de tipul message.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip end nu poate avea flux de secvență de intrare.

Un eveniment de tip end nu poate avea flux de mesaj de intrare.

Un eveniment de tip end ce prezintă flux de mesaj de ieșire trebuie să fie de tipul error.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un element de modelare gateway nu poate avea flux de mesaj de intrare.

Un element de modelare gateway nu poate avea flux de mesaj de ieșire.

Un element de modelare gateway ce bifurcă fluxul trebuie să prezinte cel puțin o rută.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un element de modelare gateway nu poate avea flux de mesaj de intrare.

Un element de modelare gateway nu poate avea flux de mesaj de ieșire.

Un element de modelare gateway ce bifurcă fluxul trebuie să prezinte cel puțin 2 rute.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un element de modelare gateway nu poate avea flux de secvență de intrare.

Un element de modelare gateway nu poate avea flux de mesaj de ieșire.

Un element de modelare gateway ce bifurcă fluxul trebuie să prezinte cel puțin 2 rute.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un element de modelare gateway nu poate avea flux de secvență de intrare.

Un element de modelare gateway nu poate avea flux de secvență de ieșire.

Un element de modelare gateway ce bifurcă fluxul trebuie să prezinte cel puțin 2 rute.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un element de modelare event gateway are plasat pe rutele sale evenimente intermediare de tip catching sau activități de tip receive.

Un element de modelare event gateway are plasat pe rutele sale evenimente intermediare de tip throwing sau activități de tip receive.

Un element de modelare event gateway are plasat pe rutele sale evenimente intermediare de tip catching sau activități de tip send.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un flux de secvență nu poate traversa o regiune sau granița unui sub-proces.

Un flux de secvență condițional nu poate fi utilizat dacă elementul de modelare prezintă doar un singur flux de secvență de ieșire.

Un flux de secvență de ieșire dintr-un element de modelare parallel gateway nu poate fi condițional.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un flux de secvență poate traversa o regiune sau granița unui sub-proces.

Un flux de secvență condițional nu poate fi utilizat dacă elementul de modelare prezintă doar un singur flux de secvență de ieșire.

Un flux de secvență de ieșire dintr-un element de modelare inclusive gateway nu poate fi condițional.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un flux de secvență nu poate traversa o regiune sau granița unui sub-proces.

Un flux de secvență condițional poate fi utilizat dacă elementul de modelare prezintă doar un singur flux de secvență de ieșire.

Un flux de secvență de ieșire dintr-un element de modelare complex gateway nu poate fi condițional.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un flux de secvență poate traversa o regiune sau granița unui sub-proces.

Un flux de secvență condițional poate fi utilizat dacă elementul de modelare prezintă doar un singur flux de secvență de ieșire.

Un flux de secvență de ieșire dintr-un element de modelare parallel gateway poate fi condițional.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un flux de mesaj nu poate conecta elemente de modelare ale aceluiași culoar.

Un flux de mesaj poate veni de la: un eveniment de tip message end sau un eveniment intermediar de tip message; o activitate de tip send, user sau service; sub-process; regiune de tip black box.

Un flux de mesaj poate fi direcționat către: un eveniment de tip message start sau un eveniment intermediar de tip message; o activitate de tip receive, user sau service; sub-process; regiune de tip black box.

Toate variantele sunt corecte.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un flux de mesaj poate conecta elemente de modelare ale aceluiași culoar.

Un flux de mesaj nu poate veni de la: un eveniment de tip message end sau un eveniment intermediar de tip message; o activitate de tip send, user sau service; sub-process; regiune de tip black box.

Un flux de mesaj poate fi direcționat către: un eveniment de tip message start sau un eveniment intermediar de tip message; o activitate de tip receive, user sau service; sub-process; regiune de tip black box.

Toate variantele sunt corecte.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un flux de mesaj nu poate conecta elemente de modelare ale aceluiași culoar.

Un flux de mesaj poate veni de la: un eveniment de tip message end sau un eveniment intermediar de tip message; o activitate de tip send, user sau service; sub-proces; regiune de tip black box.

Un flux de mesaj nu poate fi direcționat către: un eveniment de tip message start sau un eveniment intermediar de tip message; o activitate de tip receive, user sau service; sub-process; regiune de tip black box.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

O diagramă child-level nu va fi descrisă în sub-procesul expandat de care aparține ci separat.

Eticheta unei pagini ce conține o diagramă child-level trebuie să fie identică cu denumirea sub-procesului descris de diagramă.

O diagramă child-level va fi descrisă în sub-procesul expandat de care aparține.

Eticheta unei pagini ce conține o diagramă child-level nu trebuie să fie identică cu denumirea sub-procesului descris de diagramă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Toate activitățile au o denumire.

Două activități utilizate în cadrul aceluiași proces nu pot avea aceiași denumire – se folosește global activity pentru reutilizarea aceleiași activități în cadrul unui proces.

O activitate de tip send trebuie să aibă un flux de mesaj de ieșire.

O activitate de tip receive trebuie să aibă un flux de mesaj de intrare.

Precizați care din următoarele afirmații sunt complete și adevărate:

Toate activitățile au o denumire.

Două activități utilizate în cadrul aceluiași proces pot avea aceiași denumire.

O activitate de tip send trebuie să aibă un flux de mesaj de ieșire.

O activitate de tip receive trebuie să aibă un flux de mesaj de intrare.

Precizați care din următoarele afirmații sunt complete și adevărate:

Toate activitățile au o denumire.

Două activități utilizate în cadrul aceluiași proces nu pot avea aceiași denumire – se folosește global activity pentru reutilizarea aceleiași activități în cadrul unui proces.

O activitate de tip send trebuie să aibă un flux de mesaj de intrare.

O activitate de tip receive trebuie să aibă un flux de mesaj de ieșire.

Precizați care din următoarele afirmații sunt complete și adevărate:

Toate activitățile au o denumire.

Două activități utilizate în cadrul aceluiași proces pot avea aceiași denumire.

O activitate de tip send trebuie să aibă un flux de mesaj de ieșire.

O activitate de tip receive trebuie să aibă un flux de mesaj de ieșire.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip start message trebuie să aibă un flux de mesaj de intrare.

Un eveniment de tip start message trebuie să fie denumit astfel “Recepție [corp mesaj]”

Un eveniment de tip start timer trebuie să fie denumit astfel încât să reflecte planificarea în timp a procesului.

Un eveniment de tip start signal trebuie să fie denumit astfel încât să indice denumirea semnalului.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip start message trebuie să aibă un flux de mesaj de intrare.

Un eveniment de tip start timer trebuie să fie denumit astfel încât să reflecte planificarea în timp a procesului.

Un eveniment de tip start signal trebuie să fie denumit astfel încât să indice denumirea semnalului.

Un eveniment de tip start conditional trebuie să fie denumit astfel încât să indice condiția.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip start message nu trebuie să aibă un flux de mesaj de intrare.

Un eveniment de tip start timer nu trebuie să fie denumit astfel încât să reflecte planificarea în timp a procesului.

Un eveniment de tip start signal trebuie să fie denumit astfel încât să indice denumirea semnalului.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip start message trebuie să aibă un flux de mesaj de intrare.

Un eveniment de tip start conditional trebuie să fie denumit astfel încât să reflecte planificarea în timp a procesului.

Un eveniment de tip start signal trebuie să fie denumit astfel încât să indice denumirea semnalului.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip start definit într-un proces top-level trebuie denumit.

Dacă un proces top-level conține mai multe evenimente de tip start toate evenimentele trebuie etichetate pentru a putea identifica condițiile alternative de declanșare a procesului.

Într-un sub-proces se utilizează doar un singur eveniment de tip start.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip end definit într-un proces top-level trebuie denumit.

Dacă un proces top-level conține mai multe evenimente de tip end toate evenimentele trebuie etichetate pentru a putea identifica condițiile alternative de oprire a procesului.

Într-un sub-proces se utilizează doar un singur eveniment de tip start.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip start definit într-un proces top-level nu trebuie denumit.

Dacă un proces top-level conține mai multe evenimente de tip message toate evenimentele trebuie etichetate pentru a putea identifica condițiile alternative de declanșare a procesului.

Într-un sub-proces se utilizează mai multe evenimente de tip start.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip boundary trebuie întotdeauna denumit.

Un eveniment de tip boundary error (catching) al unui sub-proces trebuie întotdeauna denumit identic cu evenimentul throwing error asociat.

Un eveniment de tip boundary escalation (catching) al unui sub-proces trebuie întotdeauna denumit identic cu evenimentul throwing escalation asociat.

Un eveniment intermediar de tip throwing sau catching trebuie etichetat.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip boundary nu trebuie întotdeauna denumit.

Un eveniment de tip boundary error (catching) al unui sub-proces nu trebuie întotdeauna denumit identic cu evenimentul throwing error asociat.

Un eveniment de tip boundary escalation (catching) al unui sub-proces trebuie întotdeauna denumit identic cu evenimentul throwing escalation asociat.

Un eveniment intermediar de tip throwing sau catching trebuie etichetat.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip boundary trebuie întotdeauna denumit.

Un eveniment de tip boundary error (catching) al unui sub-proces trebuie întotdeauna denumit identic cu evenimentul throwing error asociat.

Un eveniment de tip boundary escalation (catching) al unui sub-proces nu trebuie întotdeauna denumit identic cu evenimentul throwing escalation asociat.

Un eveniment intermediar de tip throwing sau catching nu trebuie etichetat.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip catching message trebuie să prezinte flux de mesaj de intrare.

Un eveniment de tip throwing message trebuie să prezinte flux de mesaj de ieșire.

Un eveniment de tip catching message trebuie să prezinte flux de mesaj de ieșire.

Un eveniment de tip throwing message trebuie să prezinte flux de mesaj de intrare.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un eveniment de tip catching message nu trebuie să prezinte flux de mesaj de intrare.

Un eveniment de tip throwing message nu trebuie să prezinte flux de mesaj de ieșire.

Un eveniment de tip catching message trebuie să prezinte flux de mesaj de ieșire.

Un eveniment de tip throwing message trebuie să prezinte flux de mesaj de intrare.

Precizați care din următoarele afirmații sunt complete și adevărate:

Două evenimente de tip end nu pot fi etichetate la fel în cadrul aceluiași proces.

Dacă două evenimente de tip end au aceiași semnificație se îmbină fluxul către un singur eveniment altfel se etichetează diferit.

Un eveniment de tip end trebuie denumit astfel încât să reflece starea finală.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Două evenimente de tip end pot fi etichetate la fel în cadrul aceluiași proces.

Dacă două evenimente de tip end au aceiași semnificație se îmbină fluxul către un singur eveniment altfel se etichetează diferit.

Un eveniment de tip end trebuie denumit astfel încât să reflece starea finală.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un element de modelare gateway de tip inclusive, exclusive sau event nu poate avea decât cel mult o rută neetichetată.

Un element de modelare gateway de tip inclusive, exclusive sau event ar trebui să aibă toate rutele etichetate.

Dacă un sub-proces este urmat de către un element de modelare gateway ce are rutele etichetate Da și Nu cel puțin unul din evenimentele de tip end ale sub-procesului trebuie să aibă aceiași denumire cu a elementului de modelare gateway.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un element de modelare gateway de tip inclusive, exclusive sau event nu ar trebui să aibă toate rutele etichetate.

Dacă un sub-proces este urmat de către un element de modelare gateway ce are rutele etichetate Da și Nu cel puțin unul din evenimentele de tip end ale sub-procesului trebuie să aibă aceiași denumire cu a elementului de modelare gateway.

Dacă un event sub-process este urmat de către un element de modelare gateway ce are rutele etichetate Da și Nu cel puțin unul din evenimentele de tip end ale sub-procesului trebuie să aibă aceiași denumire cu a elementului de modelare gateway.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un flux de mesaj trebuie să fie etichetat cu numele mesajului propriu-zis.

Un flux de mesaj de la un sub-proces de tip collapsed trebuie replicat în diagrama child-level.

Un flux de mesaj către un sub-proces de tip collapsed trebuie replicat în diagrama child-level.

Un flux de mesaj de intrare într-o diagramă child-level trebuie replicat în diagrama parent-level.

Un flux de mesaj de ieșire dintr-o diagramă child-level trebuie replicat în diagrama parent-level.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un flux de mesaj nu trebuie să fie etichetat cu numele mesajului propriu-zis.

Un flux de mesaj de la un sub-proces de tip collapsed nu trebuie replicat în diagrama child-level.

Un flux de mesaj către un sub-proces de tip collapsed trebuie replicat în diagrama child-level.

Un flux de mesaj de intrare într-o diagramă child-level nu trebuie replicat în diagrama parent-level.

Un flux de mesaj de ieșire dintr-o diagramă child-level trebuie replicat în diagrama parent-level.

Precizați care din următoarele afirmații sunt complete și adevărate:

Un flux de mesaj de la un sub-proces de tip collapsed trebuie replicat în diagrama child-level.

Un flux de mesaj către un sub-proces de tip collapsed nu trebuie replicat în diagrama child-level.

Un flux de mesaj de intrare într-o diagramă child-level nu trebuie replicat în diagrama parent-level.

Un flux de mesaj de ieșire dintr-o diagramă child-level trebuie replicat în diagrama parent-level.

Precizați dacă cele două colaborări de mai jos descriu același scenariu. Motivați alegerea răspunsului.

Colaborarea A

Colaborarea B

Da;

Nu.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

În condițiile C1 fals, C2 fals se execută doar Task 3, rezultă un singur output;

În condițiile C1 adevărat, C2 fals se execută doar Task 1, rezultă un singur output și nu este nevoie de sincronizare;

În condițiile C1 adevărat, C2 adevărat se execută Task 1 și Task 2, rezultă două output-uri și al doilea element de modelare inclusive gateway așteaptă recepționarea ambelor output-uri;

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

În condițiile C1 fals, C2 fals nu se nici un task;

În condițiile C1 adevărat, C2 fals se execută doar Task 1, rezultă un singur output și este nevoie de sincronizare;

În condițiile C1 adevărat, C2 adevărat se execută Task 1 și Task 2, rezultă două output-uri și al doilea element de modelare inclusive gateway așteaptă recepționarea ambelor output-uri;

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

În condițiile C1 fals, C2 fals se execută doar Task 3;

În condițiile C1 adevărat, C2 fals se execută doar Task 1, rezultă un singur output și nu este nevoie de sincronizare;

Al doilea inclusive gateway așteaptă întotdeauna recepționarea ambelor output-uri;

În condițiile C1 adevărat, C2 adevărat se execută Task 1 și Task 2, rezultă două output-uri și al doilea element de modelare inclusive gateway așteaptă recepționarea ambelor output-uri;

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Task 1, Task2, Task3 se execută simultan;

Al doilea element de modelare exclusive gateway așteaptă recepționarea tuturor output-urilor și apoi închide procesul;

Se generează 3 output-uri;

Se generează 1 output.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Task 1, Task 2, Task 3 se execută secvențial;

Al doilea element de modelare exclusive gateway nu așteaptă recepționarea tuturor output-urilor pentru închiderea procesului;

Se generează 3 output-uri;

Se generează 1 output.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Task 1, Task 2, Task 3 se execută paralel;

Al doilea element de modelare exclusive gateway nu așteaptă recepționarea tuturor output-urilor pentru închiderea procesului;

Se generează 3 output-uri;

Se generează 1 output.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Dacă C1 și C2 sunt adevărate Task 5 nu se execută până la recepția output-urilor Task 2, Task 3 și Task 4;

Dacă C1 și C2 sunt adevărate al doilea element de modelare inclusive gateway va recepționa mai întâi output-ul de la Task 3/Task4;

Al doilea element de modelare inclusive gateway va recepționa mai întâi output-ul de la Task 2;

Dacă C1 este adevărat și C2 este fals al doilea inclusive gateway va recepționa mai întâi output-ul de la Task 3 și apoi de la Task 2.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Dacă C1 și C2 sunt adevărate Task 5 nu se execută până la recepția output-urilor Task 2, Task 3 și Task 4;

Dacă C1 și C2 sunt false al doilea element de modelare inclusive gateway va recepționa mai întâi output-ul de la Task 2;

Al doilea element de modelare inclusive gateway va recepționa mai întâi output-ul de la Task 2;

Dacă C1 este fals și C2 este adevărat al doilea inclusive gateway va recepționa mai întâi output-ul de la Task 4 și apoi de la Task 2.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt false:

Dacă C1 și C2 sunt adevărate Task 5 nu se execută până la recepția output-urilor Task 2, Task 3 și Task 4;

Dacă C1 și C2 sunt false al doilea element de modelare inclusive gateway va recepționa mai întâi output-ul de la Task 2;

Al doilea element de modelare inclusive gateway va recepționa mai întâi output-ul de la Task 2;

Dacă C1 este fals și C2 este adevărat al doilea element de modelare inclusive gateway va recepționa mai întâi output-ul de la Task 4 și apoi de la Task 2;

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Dacă C1 este falsă și C2 este adevărată element de modelare complex gateway va recepționa output-ul de la Task 2;

Dacă C1 și C2 sunt false element de modelare complex gateway va recepționa output-ul de la Task 3;

Dacă C1 și C2 sunt adevărate Task 4 va recepționa, ca input, output-ul generat de Task 1 sau output-ul generat de Task 2;

Dacă C1 și C2 sunt adevărate Task 4 va recepționa, ca input, output-ul generat de Task 1 și output-ul generat de Task 2.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Dacă C1 este falsă și C2 este adevărată element de modelare complex gateway va recepționa output-ul de la Task 3;

Dacă C1 și C2 sunt false element de modelare complex gateway va recepționa output-ul de la Task 3;

Dacă C1 și C2 sunt adevărate Task 4 va recepționa, ca input, output-ul generat de Task 1 sau output-ul generat de Task 2;

Dacă C1 și C2 sunt adevărate Task 4 va recepționa, ca input, output-ul generat de Task 1 și output-ul generat de Task 2.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt false:

Dacă C1 este falsă și C2 este adevărată element de modelare complex gateway va recepționa output-ul de la Task 3;

Dacă C1 și C2 sunt false element de modelare complex gateway va recepționa output-ul de la Task 3;

Dacă C1 și C2 sunt adevărate Task 4 va recepționa, ca input, output-ul generat de Task 1 sau output-ul generat de Task 2;

Dacă C1 și C2 sunt adevărate Task 4 va recepționa, ca input, output-ul generat de Task 1 și output-ul generat de Task 2.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Dacă C1 este adevărată Task 2 se execută de două ori;

Dacă C1 este adevărată Task 4 se execută de trei ori;

Dacă C1 este adevărată Task 3 se execută o dată;

Dacă C1 este falsă Task 4 se execută de două ori.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Dacă C1 este adevărată Task 2 se execută o dată;

Dacă C1 este adevărată Task 4 se execută de două ori;

Dacă C1 este adevărată Task 3 se execută o dată;

Dacă C1 este falsă Task 4 se execută de două ori.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Dacă C1 este adevărată Task 2 se execută o dată;

Dacă C1 este adevărată Task 4 se execută de trei ori;

Dacă C1 este adevărată Task 3 se execută o dată;

Dacă C1 este falsă Task 4 se execută de trei ori.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Task 4 se execută o dată;

Task 5 se execută o dată;

Task 4 se execută înainte de Task 5;

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Task 4 se execută de două ori;

Task 5 se execută o dată;

Task 5 se execută înainte de Task 4;

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Task 4 se execută o dată;

Task 5 se execută de 2 ori;

Task 4 se execută înainte de Task 5;

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt false:

Task 4 se execută o dată;

Task 5 se execută o dată;

Task 5 se execută înainte de Task 4;

Task 2 se execută înainte de Task 3.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Sub-procesul se execută de minim două ori;

Sub-procesul se execută de maxim două ori;

Sub-procesul se execută o dată;

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt false:

Sub-procesul se execută de minim două ori;

Sub-procesul se execută de maxim două ori;

Sub-procesul se execută o dată;

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Reprezintă o activitate compusă în cadrul unei coreografii;

Descrie unul sau mai multe seturi de schimburi de mesaje;

Fiecare element de modelare sub-coreography implică utilizarea a cel puțin două elemente de modelare coreography task;

Detaliile sub-coreografiei nu sunt vizibile în diagramă.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Reprezintă o activitate atomică în cadrul unei coreografii;

Descrie un schimb de mesaje;

Fiecare element de modelare sub-coreography implică utilizarea a cel puțin două elemente de modelare coreography task;

Detaliile sub-coreografiei sunt vizibile în diagramă.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt false:

Reprezintă o activitate atomică în cadrul unei coreografii;

Descrie unul sau mai multe seturi de schimburi de mesaje;

Fiecare element de modelare sub-coreography implică utilizarea a cel puțin două elemente de modelare coreography task;

Detaliile sub-coreografiei sunt vizibile în diagramă.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Descrie o activitate compusă din cadrul unei coreografii;

Descrie o activitate compusă din cadrul unei coreografii a cărei funcționalitate este reutilizabilă;

Detaliile sub-coreografiei sunt vizibile în diagramă.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Descrie elementul de modelare primar al unei conversații;

Descrie o activitate compusă din cadrul unei coreografii a cărei funcționalitate este reutilizabilă;

Descrie o grupare de schimburi de mesaje logic corelate între ele în cadrul diagramei de conversație;

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Descrie elementul de modelare primar al unei conversații;

Descrie o activitate compusă din cadrul unei coreografii a cărei funcționalitate este reutilizabilă;

Descrie o conversație cu o funcționalitate reutilizabilă în cadrul diagramei.

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

O activitate realizată de către un participant la proces cu suportul unei aplicații software;

Funcționalitatea descrisă nu este reutilizabilă în cadrul procesului;

Descrie o activitate globală;

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

O activitate care presupune utilizarea unui serviciu – serviciul poate fi un serviciu web sau poate fi oferit de către o aplicație software;

Funcționalitatea descrisă este reutilizabilă în cadrul procesului;

Descrie o activitate globală;

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Activitatea pune la dispoziție un mecanism prin care se transmite un input motorului de procese de afaceri care la rândul său va oferi un output pe baza inferențelor realizate;

Funcționalitatea descrisă nu este reutilizabilă în cadrul procesului;

O activitate care presupune utilizarea unui serviciu – serviciul poate fi un serviciu web sau poate fi oferit de către o aplicație software;

O activitate realizată de către un participant la proces cu suportul unei aplicații software.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Activitatea pune la dispoziție un mecanism prin care se transmite un input motorului de procese de afaceri care la rândul său va oferi un output pe baza inferențelor realizate;

O activitate realizată de către un participant la proces fără suportul unei aplicații software sau a BPMS;

O activitate care presupune utilizarea unui serviciu – serviciul poate fi un serviciu web sau poate fi oferit de către o aplicație software;

O activitate realizată de către un participant la proces cu suportul unei aplicații software.

Precizați care din următoarele afirmații referitoare la elementul de modelare data object sunt complete și adevărate:

Oferă informații referitoare la activitățile care se declanșează sau rezultatele acestora;

Nu au nici un efect asupra fluxului de secvență a procesului;

Pot reprezenta un element singular sau colecții de obiecte;

Nu au nici un efect asupra fluxului de mesaje a procesului.

Precizați care din următoarele afirmații referitoare la elementul de modelare data object sunt complete și adevărate:

Oferă informații referitoare la activitățile care se declanșează sau rezultatele acestora;

Nu pot reprezenta colecții de obiecte;

Furnizează aceleași informații ca și elementele de modelare data input;

Furnizează aceleași informații ca și elementele de modelare data output.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Este utilizat pentru a descrie conținutul comunicației dintre doi participanți;

Este de tipul message non-initiating;

Poate fi utilizat într-o colaborare;

Poate fi utilizat într-o orchestrație.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

Este utilizat pentru a descrie conținutul comunicației dintre doi participanți;

Este de tipul message non-initiating;

Poate fi utilizat într-o colaborare;

Poate iniția o conversație.

Precizați ce reprezintă figura de mai jos:

Un eveniment parallel multiple (catching);

Un eveniment escalation (throwing);

Evenimentul nu există;

Evenimentul poate iniția o colaborare.

Precizați ce reprezintă figura de mai jos:

Un eveniment intermediate (catching);

Un eveniment escalation (throwing);

Un eveniment intermediate boundary non-interrupting;

Un eveniment intermediate boundary interrupting.

Precizați ce reprezintă figura de mai jos:

Un eveniment start;

Un eveniment timer (throwing);

Un eveniment start event sub-process interrupting;

Un eveniment intermediate boundary interrupting.

Precizați care din următoarele afirmații sunt complete și adevărate:

Nu există eveniment intermediate error (catching);

Nu există eveniment intermediate cancel (catching);

Nu există eveniment intermediate timer (catching);

Nu există eveniment intermediate compensation (catching).

Precizați care din următoarele afirmații sunt complete și adevărate:

Un element de modelare gateway care nu este sincronizat cu evenimentele de tip end ale sub-procesului anterior evidențiază inconsistența dintre fluxul sub-procesului și procesul său părinte;

Fluxul unui element de modelare event based gateway este rutat întotdeauna către un eveniment;

Dacă un element de modelare gateway are o denumire similară cu a unei activități este indicat ca înainte de elementul de modelare gateway să se traseze o activitate;

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

La ramificare rutează fluxul către una sau mai multe ramuri;

La îmbinare așteaptă finalizarea activităților pe toate ramurile și apoi continuă fluxul de secvență;

La ramificare rutează fluxul către o singură ramură;

La îmbinare nu așteaptă finalizarea activităților pe toate ramurile.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

La ramificare rutează fluxul către una sau mai multe ramuri;

La îmbinare așteaptă finalizarea activităților pe toate ramurile și apoi continuă fluxul de secvență;

Va ruta fluxul către cel puțin una din ramuri după evaluarea unei expresii;

Un singur eveniment ce urmează acestui element de modelare gateway se declanșează și poate crea o nouă instanță a procesului.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

La ramificare rutează fluxul către una sau mai multe ramuri;

La îmbinare așteaptă finalizarea activităților pe toate ramurile și apoi continuă fluxul de secvență;

Va ruta fluxul către cel puțin una din ramuri după evaluarea unei expresii;

Un singur eveniment ce urmează acestui element de modelare gateway se declanșează și poate crea o nouă instanță a procesului.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

La ramificare rutează fluxul către una sau mai multe ramuri;

La îmbinare așteaptă finalizarea activităților pe toate ramurile și apoi continuă fluxul de secvență;

Toate evenimentele ce urmează acestui element de modelare gateway se declanșează și creează o nouă instanță a procesului;

Un singur eveniment ce urmează acestui element de modelare gateway se declanșează și poate crea o nouă instanță a procesului.

Precizați care din următoarele afirmații referitoare la figura de mai jos sunt complete și adevărate:

La ramificare rutează fluxul către una sau mai multe ramuri;

La îmbinare așteaptă finalizarea activităților pe toate ramurile și apoi continuă fluxul de secvență;

La ramificare rutează fluxul de secvență către o singură ramură;

La îmbinare așteaptă finalizarea cel puțin a unei activități și apoi continuă fluxul de secvență.

Precizați care din următoarele afirmații sunt complete și adevărate:

Într-o BPD activitățile suntordonate și conectate printr-un flux de secvență;

Într-o UML AD acțiunile sunt ordonate și conectate printr-un flux de control;

Într-o BPD activitățile sunt ordonate și conectate printr-un flux de mesaje;

Într-o UML AD activitățile sunt ordonate și conectate printr-un flux de control.

Precizați care din următoarele afirmații sunt complete și adevărate:

BPMN oferă un mecanism pentru modelarea activităților care se execută concurențial;

Pentru modelarea paralelismului UML utilizează două elemente de modelare;

BPMN oferă două mecanisme pentru modelarea activităților care se execută concurențial;

Pentru modelarea paralelismului UML utilizează un element de modelare.

Precizați care din următoarele afirmații sunt complete și adevărate:

Pentru modelarea fluxurilor alternative BPMN utilizează un element de modelare exclusive gateway iar UML AD utilizează elementul de modelare decision;

Pentru a modela o îmbinare simplă a două fluxuri BPMN oferă două mecanisme iar UML utilizează elementul de modelare merge;

Pentru a modela o alegere multiplă în BPMN se poate apela la două mecanisme;

Pentru a modela o alegere multiplă în UML se utilizează un element fork.

Precizați care din următoarele afirmații sunt complete și adevărate:

Pentru modelarea fluxurilor alternative BPMN utilizează un element de modelare exclusive gateway iar UML AD utilizează elementul de modelare decide;

Pentru a modela o îmbinare simplă a două fluxuri BPMN oferă două mecanisme iar UML utilizează elementul de modelare join;

Pentru a modela o alegere multiplă în BPMN se poate apela la două mecanisme;

Pentru a modela o alegere multiplă în UML se utilizează un element join.

Precizați care din următoarele afirmații sunt complete și adevărate:

Elementul de modelare BPMN end event are ca și corespondent în UML AD elementul de modelare flow final node;

Elementul de modelare specific UML AD corespondent ca funcționalitate cu elementul de modelare parallel multi-instance task specific BPMN este elementul de modelare expansion region cu atributul concurency setat pe parallel;

Elementul de modelare specific UML AD corespondent ca funcționalitate cu elementul de modelare standard loop task specific BPMN este elementul de modelare expansion region cu atributul concurency setat pe iterative;

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Elementul de modelare BPMN end event are ca și corespondent în UML AD elementul de modelare final node;

Elementul de modelare specific UML AD corespondent ca funcționalitate cu elementul de modelare parallel multi-instance task specific BPMN este elementul de modelare expansion region cu atributul concurency setat pe parallel;

Elementul de modelare specific UML AD corespondent ca funcționalitate cu elementul de modelare standard loop task specific BPMN este elementul de modelare expansion region cu atributul concurency setat pe parallel;

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Elementul de modelare BPMN end event are ca și corespondent în UML AD elementul de modelare flow final node;

Elementul de modelare specific UML AD corespondent ca funcționalitate cu elementul de modelare parallel multi-instance task specific BPMN este elementul de modelare expansion region cu atributul concurency setat pe iterative;

Elementul de modelare specific UML AD corespondent ca funcționalitate cu elementul de modelare standard loop task specific BPMN este elementul de modelare expansion region cu atributul concurency setat pe parallel;

Nici o variantă nu este corectă.

Precizați care din următoarele afirmații sunt complete și adevărate:

Mecanismul de modelare al elementului BPMN event based gateway este descris utilizând standardul UML printr-o configurație formată din următoarele elemente de modelare fork node, interruptible region, interrupting edge și receive signal action;

UML AD nu prezintă un element de modelare similar ca și concept cu ad-hoc sub-process specific BPMN;

Mecanismul de modelare milestone în UML AD se realizează utilizând un element de modelare interruptible region ce prezintă alte două elemente de modelare send signal action și accept event action;

Mecanismul de modelare milestone în BPMN se poate realiza utilizând evenimente intermediare de tip link.

Precizați care din următoarele afirmații sunt complete și adevărate:

Mecanismul de modelare al elementului BPMN event based gateway este descris utilizând standardul UML printr-o configurație formată din următoarele elemente de modelare join node, interruptible region, interrupting edge și receive signal action;

UML AD nu prezintă un element de modelare similar ca și concept cu ad-hoc sub-process specific BPMN;

Mecanismul de modelare milestone în UML AD se realizează utilizând un element de modelare interruptible region ce prezintă alte două elemente de modelare send signal action și accept time event action;

Mecanismul de modelare milestone în BPMN se poate realiza utilizând evenimente intermediare de tip signal.

Precizați care din următoarele afirmații sunt complete și adevărate:

Mecanismul de modelare al elementului BPMN event based gateway este descris utilizând standardul UML printr-o configurație formată din următoarele elemente de modelare fork node, interruptible region, interrupting edge și receive signal action;

Mecanismul de modelare milestone în BPMN se poate realiza utilizând evenimente intermediare de tip cancel;

Mecanismul de modelare milestone în UML AD se realizează utilizând un element de modelare interruptible region ce prezintă alte două elemente de modelare send signal action și accept event action;

Mecanismul de modelare milestone în BPMN se poate realiza utilizând evenimente intermediare de tip compensation.

Imaginea din figura următoare reprezintă:

Mecanismul de modelare a activităților concurențiale în BPMN;

Mecanismul de modelare a îmbinării simple a activităților în BPMN;

Mecanismul de modelare a alegerii multiple în BPMN;

Mecanismul de modelare a îmbinării multiple în BPMN.

Imaginea din figura următoare reprezintă:

Mecanismul de modelare a activităților concurențiale în BPMN;

Mecanismul de modelare a îmbinării simple a activităților în BPMN;

Mecanismul de modelare a alegerii multiple în BPMN;

Mecanismul de modelare a îmbinării multiple în BPMN.

Imaginea din figura următoare reprezintă:

Mecanismul de modelare a activităților concurențiale în BPMN;

Mecanismul de modelare a îmbinării simple a activităților în BPMN;

Mecanismul de modelare a alegerii multiple în BPMN;

Mecanismul de modelare a îmbinării multiple în BPMN.

Imaginea din figura următoare reprezintă:

Mecanismul de modelare a activităților concurențiale în BPMN;

Mecanismul de modelare a îmbinării simple a activităților în BPMN;

Mecanismul de modelare a alegerii multiple în BPMN;

Mecanismul de modelare a îmbinării multiple în BPMN.

Imaginea din figura următoare reprezintă:

Mecanismul de modelare a activităților concurențiale în BPMN;

Mecanismul de modelare a îmbinării simple a activităților în BPMN;

Mecanismul de modelare a alegerii multiple în BPMN;

Mecanismul de modelare a îmbinării multiple în BPMN.

Imaginea din figura următoare reprezintă:

Mecanismul de modelare a activităților concurențiale în BPMN;

Mecanismul de modelare a îmbinării simple a activităților în BPMN;

Mecanismul de modelare a alegerii multiple în BPMN;

Mecanismul de modelare a îmbinării multiple în BPMN.

Imaginea din figura următoare reprezintă:

Mecanismul de modelare a activităților concurențiale în BPMN;

Mecanismul de modelare a îmbinării simple a activităților în BPMN;

Mecanismul de modelare a îmbinării sincronizate în BPMN;

Mecanismul de modelare a îmbinării multiple în BPMN.

Imaginea din figura următoare reprezintă:

Mecanismul de modelare parallel multi-instance în BPMN;

Mecanismul de modelare a îmbinării simple a activităților în BPMN;

Mecanismul de modelare a îmbinării sincronizate în BPMN;

Mecanismul de modelare a îmbinării multiple în BPMN.

Imaginea din figura următoare reprezintă:

Mecanismul de modelare parallel multi-instance în UML AD;

Mecanismul de modelare implicit termination în UML AD;

Mecanismul de modelare a îmbinării sincronizate în UML AD;

Mecanismul de modelare a îmbinării multiple în UML AD.

Imaginea din figura următoare reprezintă:

Mecanismul de modelare parallel multi-instance în UML AD;

Mecanismul de modelare implicit termination în UML AD;

Mecanismul de modelare a îmbinării sincronizate în UML AD;

Mecanismul de modelare standard loop în UML AD.

Teme

Modelați următorul comportament dinamic al unui produs software utilizând BPMN: Un utilizator introduce de la tastatură două numere întregi. Dacă cel puțin unul din numere este negativ se solicită reintroducerea acestuia. Dacă se introduce de la tastatură un caracter se afișează un mesaj de eroare și se închide aplicația. Se calculează suma celor două numere și dacă aceasta depășeste valoarea 10 se afișează un mesaj automat de atenționare.

Reprezentați printr-o diagramă BPMN următoarea secvență de cod:

j=1

for (( i=1; i<=5; i++ ))

do

j=`expr $j \* $i`

done

echo “$j”

Modelați următorul comportament dinamic al unui produs software utilizând BPMN: Un utilizator introduce de la tastatură un șir de caractere. Dacă cel puțin unul din caractere este cifră se afișează un mesaj de eroare și se solicită reintroducerea șirului, altfel se va afișa numărul de vocale din șirul de caractere.

Tabelul 13. Întrebări și răspunsuri.

Anexa 1 UML-Diagrama cazurilor de utilizare

Figura 145. Lista completă a elementelor de modelare ale diagramei cazurilor de utilizare [ConceptDraw,2016].

Anexa 2 UML-Diagrama de stare

Figura 146. Lista completă a elementelor de modelare ale diagramei de stare [ConceptDraw,2016].

Figura 147. Exemplu de diagramă de stare [UML,2016] ,[ConceptDraw,2016].

Anexa 3 UML-Diagrama de activitate

Figura 148. Lista completă a elementelor de modelare ale diagramei de activitate [ConceptDraw,2016].

Bibliografie

[Alaiba1,2008] Alaiba V., Notația BPMN pentru modelarea proceselor de afaceri, Vasile Alaiba – MediaWiki site:http://profs.info.uaic.ro, accesat în data de 2 octombrie 2013.

[Alaiba2,2008] Alaiba V., Șabloane de control a fluxurilor de lucru, Vasile Alaiba – MediaWiki site:http://profs.info.uaic.ro, accesat în data de 2 octombrie 2013.

[Ambler,2004] Ambler Scott, The Object Primer: Agile Model Driven Development with UML 2.0,Cambridge University Press, Cambridge, 2004.

[Appian,2013] Appian Learning Center, Introduction to BPM, http://www.appian.com/bpmbasics/bpmintro.jsp, accesat în data de 2 octombrie 2013.

[ArisCommunity,2013] Learn how to model BPMN diagrams in ARIS Express http://www.ariscommunity.com/videos/learn-how-model-bpmn-diagrams-aris-express, accesat în data de 11 martie 2013.

[AuraPortal,2012] User Guide BPM Modeler Java, www.AuraPortal.com

[Baker,2006] Standards in Business Modeling and Integration The BPM – SOA Connection, 2006 OMG Workshops, http://omg.net/news/meetings/workshops/soa-bpm-mda-2006/04-1_Baker.pdf, accesat la data de 6 ianuarie 2016.

[Belaychuk1,2011] Belaychuk A., Modelling subprocesses in BPMN, http://mainthing.ru/item/446/, accesat la data de 17 octombrie 2016.

[Belaychuk2,2011] Belaychuk A., Limited Usability of BPMN Lanes, http://mainthing.ru/item/470/, accesat la data de 25 noiembrie 2016.

[Bigeliene,2012] Bigeliene K, Eficient BPMN:from Anti-Patterns to Best Practices, No Magic Europe, http://bpm2012.ut.ee/wp-content/uploads/2012/06/Efficient-BPMN_BPM2012_Kristina-Bigeliene.pdf, accesat la data de 1 noiembrie 2016.

[Blain,2006] Blain T. How to use end events, http://tynerblain.com/blog/2006/08/11/bpmn-end-events-1/ , accesat la data de 18 octombrie 2016.

[Blain1,2006] Blain T., Intermediate multiple events, http://tynerblain.com/blog/2006/09/13/bpmn-intermediate-multiple/ , accesat la data de 20 octombrie 2016.

[Bock,2005] Bock C., UML 2 Activity and Action Models, Part 6: Structured Activities, http://www.jot.fm/issues/issue_2005_05/column4/ accesat data de 21 noiembrie 2016.

[BPM Offensive,2011] BPMN 2.0 Business Process Model and Notation poster, accesat în data de 13 februarie 2013, http://www.bpmb.de/images/BPMN2_0_Poster_EN.pdf

[Brennan,2006] Kevin Brennan, RAD Stencil, 2006, https://www.graffletopia.com/stencils/140, accesat în data de 3 octombrie 2013.

[Camunda,2016] BPMN Examples, https://camunda.org/bpmn/examples/, accesat la data de 7 noiembrie 2016.

[ConceptDraw,2016] http://www.conceptdraw.com/How-To-Guide/uml-state-machine, accesat la data de 29 septembrie 2016.

[Dorobăț,2012] Iuliana Dorobăț, Laura Mina, Radu Constantinescu, Alexandru Pavel, „Extension of the European Union Services Directive – Implementation in Romania”, Transylvanian Review of Administrative Sciences, nr. 35 E, pp. 78-92, 2012, ISSN: 2247 – 8310.

[Dumas M., ter Hofstede A.H.M.,2001] Marlon Dumas, Arthur H.M. ter Hofstede, „UML activity diagrams as a workflow specification language”, UML 2001: 4th International Conference on the Unified Modeling Language: Modeling Languages, Concepts, and Tools, Toronto, pp. 76-90, 2001.

[Eriksson et.al,2004], Eriksson Hans-Erik, Penker Magnus, Lyons Bryan, Fado David, UML 2 Toolkit, 2004, John Wiley & Sons, Inc., New York, ISBN: 0-471-46361-2.

[EUSDRO,2009] EUSDRO, Raport de activitate etapa II ASE București, 2009.

[Gartner,2016] Magic Quadrant for Business Process Management Suites, https://www.pega.com/insights/resources/2016-magic-quadrant-intelligent-business-process-management-suites-ibpms, accesat în data de 12 octombrie 2016.

[Geneva,2010] Geneva R., Four Use Cases for the BPMN Signal Event, http://www.processmodeling.info/posts/four-use-cases-for-the-bpmn-signal-event/, accesat la data de 18 octombrie 2016.

[GeneXus,2016] GeneXus wiki, Intoduction to BPMN: Advanced concepts,http://wiki.genexus.com/commwiki/servlet/wiki?24922,Introduction+to+BPMN+-+Advanced+Concepts, accesat la data de 18 octombrie 2016.

[Giurcă,2004] Giurcă Adrian, Introducere în UML, http://inf.ucv.ro/~giurca/courses/CB3105/archive.htm, accesat data de 13 noiembrie 2013.

[Global360,2013] http://bps.opentext.com/solutions/solution/microsoft, accesat în data de 13 februarie 2013.

[Haliga,2013] D. Haliga, Cine este Business Analyst-ul și de ce aș avea nevoie de el?, Today Software magazine, nr. 9, martie 2013, http://www.todaysoftmag.ro/tsm/magazines/TSM_9_2013_ro.pdf, accesat la data de 9 noiembrie 2015.

[MSDN,2016] UML Use Case Diagrams: Guidelines, https://msdn.microsoft.com/en-us/library/dd409432.aspx accesat la data de 21 ianuarie 2016.

[Muehlen,2007] Michael zur Muehlen, „Business Process Management Standards, Origin, Overview and Directions”, Howe Scholl of Technology Management, Stevens Institute of Technology, Hoboken NJ, http://www.slideshare.net/mzurmuehlen/business-process-management-standards-tutorial?from_search=1 , accesat în data de 30 septembrie 2013.

[NobleProg,2016] NobleProg Training materials, http://training-course-material.com/training/BPMN_2.0_Events_Types, accesat la data de 15 octombrie 2016.

[Nobleprog1,2016] NobleProg Training materials, http://training-course-material.com/training/File:Figure10-100-example-of-inline-event-handling-via-event-sub-processes.png, accesat la data de 18 octombrie 2016.

[Odeh et.al,2002] M. Odeh, I. Beeson, S. Green and J. Sa, Modelling Processes Using RAD and UML Activity Diagrams: an Exploratory Study, Systems Modelling Research Group, ACIT 2002, http://www.cems.uwe.ac.uk/~sjgreen/RAD&AD_V2.pdf, accesat în data de 3 octombrie 2013.

[OMG1,2009] Business Process Model and Notation (BPMN), OMG, http://www.omg.org/spec/BPMN/1.2/, accesat în data de 11 noiembrie 2012.

[OMG,2009] UML 2.2 Superstructure Specification, OMG, http://www.omg.org/spec/UML/2.2/Superstructure/PDF, accesat în data de 22 noiembrie 2012.

[OMG,2010] BPMN 2.0 by example, http://www.bpmn.org/ accesat în data de 13 februarie 2013.

[OMG,2011] Business Process Model and Notation (BPMN), OMG, http://www.omg.org/spec/BPMN/2.0/PDF, accesat în data de 22 noiembrie 2012.

[OMG,2016] OMG Unified Modeling Language TM (OMG UML) Version 2.5, http://www.omg.org/spec/UML/2.5/, accesat în data de 22 septembrie 2016.

[OMG1,2016] BPM Vendor Directory Listing, http://bpm-directory.omg.org/vendor/list.htm, accesat în data de 12 octombrie 2016.

[Owen, Raj,2003] Martin Owen, Jog Raj, BPMN and Business Process Management, Popkin Software, www.popkin.com, 2003.

[Podeswa,2005] Podeswa Howard, UML for the IT Business Analyst:A Practical Guide to Object-Oriented Requirements Gathering, Thomson Course Technology PTR, 2005, ISBN: 1-59200-912-3,

http://www.whiteboxqa.com/StudentMaterial/Books/IP-BA-UML%20for%20the%20IT%20Business%20Analyst%20A%20Practical%20Guide%20to%20Object%20Oriented%20Requirements%20Gathering.pdf, accesat data de 13 noiembrie 2013.

[Polancic,2013] Polancic G.,Common BPMN Modeling Mistakes and Best-Practices: Basic Events, http://blog.goodelearning.com/bpmn/common-bpmn-modeling-mistakes-best-practices-basic-events/ , accesat la data de 26 octombrie 2016.

[Polancic,2014] Polancic G., Conversation vs Collaboration vs Choreography, http://blog.goodelearning.com/bpmn/conversation-vs-collaboration-vs-choreography/ , accesat la data de 27 octombrie 2016.

[Polancic,Tomislav,2008] Polancic Gregor, Tomislav Rozman, Business Process Modelling Notation Poster, 2008.

[Recker and Mendling,2006] Jan Recker, Jan Mendling, „On the translation between BPMN and BPEL: conceptual mismatch between process modeling languages”, in Latour, T. and Petit, M. (Eds), Proceedings of the 18th International Conference on Advanced Information Systems Engineering, Luxembourg, pp. 521-32, 2006.

[Roșca I. et al.,2004] I. Roșca, D. Mangiuc, D. Boldeanu, O. Secătureanu, C. Țarțavulea, D. Băbeanu, Proiectarea obiectuală a sistemelor informatice, 2004, Editura InfoMega, București.

[Rozman et al.,2007] Rozman T., Polančič G., Horvat R., Analysis of Most Common Process Modelling Mistakes in BPMN Process Models, EUROSPI'2007 : industrial proceedings, European Software Process Improvement, Germany’07, https://www.researchgate.net/publication/280523627_Analysis_of_most_common_proces_modelling_mistakes_in_BPMN_process_models, accesat la data de 1 noiembrie 2016.

[Russell et al.,2006] Russell N., van der Aalst W.M.P., ter Hofstede A.H.M., Wohed P., „On the suitability of UML 2.0 activity diagrams for business process modeling”, Proceedings of the 3rd Asia-Pacific Conference on Conceptual Modelling, Vol. 53, pp. 95-104, 2006.

[Ryan K.L. Ko et al.,2009] Ryan K.L. Ko, Stephen S.G. Lee, Eng Wah Lee, „Business process management (BPM) standards: a survey”, Business Process Management Journal, Vol. 15, No. 5, pp. 744-791, 2009.

[Shapiro et al.,2012] Shapiro R., White S., Bock C., Palmer N., Muehlen M., et al, BPMN 2.0 Handbook Second Edition, Future Strategies Inc., 2012, ISBN-13:978-0-9849764-1-6, available on books.google.ro accesat la data de 5 noiembrie 2016.

[Siegel,2008] J. Siegel, In OMG’s OCEB Certification Program, What is the Definition of Business Process?, OCEB Certification Program White Paper 2008, http://www.omg.org/oceb/defbusinessprocess.htm, accesat la data de 9 noiembrie 2015.

[Silingas&Mileviciene,2013] Silingas D., Mileviciene E., Efficient BPMN: from Anti-Patterns to Best Practices,

http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/2438/Efficient-BPMN-from-Anti-Patterns-to-Best-Practices.aspx, accesat la data de 31 octombrie 2016.

[Silver,2010] Silver B., Jump start your BPM program with standard-based process modeling, Industry Trend reports, 2010.

[Silver,2010] Silver B., The rules of BPMN, http://brsilver.com/tag/bpmn-method-and-style/page/2/, accesat la data de 17 octombrie 2016

[Sparxsystems,2013] Comparing UML activities to BPMN processes, http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/model_simulation/bpmn_simulation_comparison.html, accesat data de 13 noiembrie 2013.

[Tay,2013] Tay M., BPMN Process Model – Descriptive, Analytic (Operational) to Executable,http://blog.maxconsilium.com/2013/07/bpmn-process-model-descriptive-analytic.html, accesat data de 13 noiembrie 2015.

[UML,2016] http://www.uml-diagrams.org/, accesat la data de 29 septembrie 2016.

[UML1,2016] http://www.uml-diagrams.org/activity-diagrams-reference.html, accesat la data de 29 septembrie 2016

[UML2,2007] UML Superstructure Specification, v2.1.1, http://doc.omg.org/formal/2007-02-05.pdf, accesat la data de 21 noiembrie 2016

[van der Aalst et al.,2003] van der Aalst, W.M.P., ter Hofstede, A.H.M. and Weske, M. (2003), „Business process management: a survey”, Proceedings of the International Conference on Business Process Management, BPM 2003, Eindhoven, The Netherlands, 26-27 June 2003.

[Venter,2010] Etienne Venter, BPMN starter guide: Which process type to use?, http://www.ariscommunity.com/users/etienne/2010-08-27-bpmn-starter-guide-which-process-type-use, accesat în data de 26 februarie 2013,

[White S.,2004] White Stephen, „Process modeling notations and workflow patterns”, Workflow Handbook, Future Strategies, Lighthouse Point, FL, 2004, http://www.workflowpatterns.com/vendors/documentation/BPMN_wfh.pdf, accesat data de 13 noiembrie 2013.