Modelarea proceselor de afaceri cu ajutorul UML

I. Introducere

Datorita existentei unei concurente din ce in ce mai puternice, companiile sunt nevoite sa creasca calitatea bunurilor si serviciilor oferite, sa reduca timpii de procesare a comenzilor, minimizand in acelasi timp costurile, ceea ce poate conduce, in final, la marirea profiturilor.

Pentru atingerea acestor obiective, companiile trebuie sa-si optimizeze operatiunile interne, mai concret procesele de afaceri. Aceasta optimizare presupune, in primul rand, construirea unui model de afaceri care sa reprezinte activitatea firmei, permitand acesteia sa analizeze si simuleze schimbarile ce ar putea surveni.

Un proces de afaceri reprezinta o colectie de activitati interconectate si structurate care au ca scop obtinerea unui serviciu sau produs pentru un anumit client.

Modelarea proceselor de afaceri (Business Process Modeling) se refera la activitatea de reprezentare a proceselor ce au loc in cadrul unei intreprinderi in scopul analizei acestora si identificarii posibilitatilor de optimizare. In general aceste imbunatatiri implica utilizarea unor solutii informatice.

Limbajul de Modelare Unificat (Unified Modeling Language)

Limbajul de Modelare Unificat (UML) este un limbaj de modelare orientat obiect considerat standard de catre dezvoltatorii software din toata lumea. UML este succesorul propriu-zis al celor mai bune trei limbaje de modelare anterioare orientate pe obiecte (Booch, OMT, and OOSE) ce au fost unificate, obtinandu-se astfel un limbaj superior, mult mai expresiv.

UML este un limbaj de reprezentare vizuala ce poate fi utilizat pentru:

modelarea proceselor de afaceri,

reprezentarea structurii unei aplicatii,

descrierea arhitecturii unui sistem,

surprinderea comportamentului unui sistem,

modelarea structurilor de date sau

construirea unei specificatii detaliate a unui sistem.

Reprezentarea se face utilizand elementele standard ale UML: notatiile si diagramele. Notatiile sunt elemente ce se regasesc in cadrul fiecarei diagrame si sunt de tipul: conectori, simboluri, valori, etc. Diagramele sunt reprezentari ale unui proces, ale unui sistem sau ale partilor lor componente.

n cadrul UML 2.2 sunt definite 14 tipuri de diagrame ce se impart in trei categorii:

Diagrame de structura

Evidentiaza componentele ce trebuie sa existe in cadrul sistemului modelat; sunt in general folosite pentru documentarea arhitecturii sistemelor software.

Exemple:

Diagrama de clasa: descrie structura unui sistem prin evidentierea claselor din sistem, a atributelor lor si a relatiilor dintre clase; Diagrama de componente: descrie modul in care un sistem este descompus in partile sale componente si arata dependentele dintre acestea; Diagrama structurii compozite: descrie structura interna a unei clase si colaborarile posibile datorate acestei structuri; Diagrama de constructie: descrie componentele hardware utilizate in implementarea sistemului; Diagrama de obiecte: prezinta obiectele si relatiile dintre ele;

Diagrama de pachet: descrie modul in care un sistem este impartit in grupuri logice aratand legaturile intre aceste grupuri;

Diagrama de profil: opereaza la nivel de metamodel.

Diagrame de comportament

Evidentiaza ce trebuie sa se intample in sistemul modelat; ilustreaza comportamentul sistemului si sunt utilizate in general pentru a descrie functionalitatea sa.

Diagrama de activitate: descrie succesiunea de activitati operationale ale componentelor unui sistem;

Diagrama de stare: descrie starile si starile de tranzitie ale sistemului;

Diagrama cazurilor de utilizare: descrie functionalitatea oferita de sistem din perspectiva actorilor, a scopurilor lor reprezentate ca si cazuri de utilizare si a oricaror dependente dintre aceste cazuri.

Diagrame de interactiune

Diagramele de interactiune reprezinta diagrame de comportament care evidentiaza modul in care circula datele si se transfera controlul in sistemul modelat:

Diagrama de comunicare: arata interactiunile dintre obiecte sau componente dpdv al mesajelor. Reprezinta o combinatie a informatiilor preluate de la diagramele de clasa, de secventa si de cazuri de utilizare ce descriu atat structura statica cat si pe cea dinamica a unui sistem;

Diagrama de interactiune de ansamblu: confera o privire de ansamblu asupra sistemului, nodurile reprezentand diagrame de interactiune;

Diagrama de secventa: arata modul in care obiectele comunica intre ele dpdv al secventierii mesajelor;

Diagrama de incadrare in timp: un tip specific de diagrame de interactiune in care focusul este dat de restrictiile de timp.

Diagrama cazurilor de utilizare (Use-case Diagram)

Un use case sau caz de utilizare este o secventa a tranzactiilor realizate de sistem ca raspuns la evenimentele declansate de un actor sistemului. Un caz de utilizare contine toate evenimentele care pot surveni in cadrul perechii actor - caz de utilizare, nu doar cele ce vor aparea in orice scenariu particular. Un caz de utilizare poate de asemenea descrie comportamentul unui set de obiecte, ca de exemplu o organizatie.

Pe scurt, un use case este o reprezentare la nivel conceptual a unei interactiuni dintre un actor si un sistem si a activitatilor care au loc si pe care sistemul le face.

O diagrama use case este folosita n general pentru a indica sau caracteriza functionalitatile si comportamentul sistemului ce interactioneaza cu unul sau mai multi actori. Un actor poate fi un utilizator sau orice sistem ce poate interactiona cu sistemul modelat.

Atta timp ct actorii reprezinta utilizatorii, ei ajuta la construirea unei imagini clare a ceea ce se asteapta a se ntmpla n sistem. Cazurile de utilizare sunt construite pe baza nevoilor pe care le au actorii (utilizatorii). Aceasta asigura faptul ca sistemul va produce ceea ce s-a dorit.

Diagramele cazurilor de utilizare contin elemente ce pot reprezenta actori, relatii de asociere, relatii de generalizare, pachete si cazuri de utilizare. O diagrama a cazurilor de utilizare indica un set de actori externi si cazurile de utilizare ale sistemului n care participa respectivii actori.

Elementele utilizate i notaiile lor sunt urmtoarele:ElementDescriereNotaie

ActorUn actor este, n principiu, un utilizator al sistemului, dar poate fi i un alt sistem informatic care interacioneaz cu sistemul analizat.

Use CaseUse Case-urile se reprezint sub forma unei elipse n interiorul creia este scris numele Use Case-ului respectiv.

AsociereAsocierea este utilizat pentru a indica legtura dintre un Actor i un Use Case, n sensul c acel actor particip ntr-un fel oarecare n acel Use Case.

Un exemplu simplu de utilizare a diagramei este cel al unui client care vrea sa afle ora exacta si suna la 958:

Relaia de tip generalizare/specializarentre actori i use case-uri pot s existe relaii de generalizare / specializare atunci cnd un actor sau un use case poate fi asimilat unei clase de actori, respectiv de use case-uri.

O generalizare intre doua cazuri de utilizare indica faptul ca un caz de utilizare poate impartasi comportamentul definit anterior in unul sau mai multe cazuri de utilizare. Deasemenea, generalizarea suporta utilizatori si extinde stereotipuri.

Exemplu: un use case de tipul emitere pasaport este o generalizare a altor doua use- case-uri: emitere pasaport electronic si emitere pasaport temporar.

O generalizare intre actori arata ca un actor mosteneste structura si comportamentul unui alt actor (sau mai multor actori).

Exemplu: Un actor de tipul Studenti este o generalizare a actorilor de tipul Studenti Ciclul Licenta si Studenti Ciclul Master.

Relaia de tip extensie ntre use case-uri

Relaiile de tip extensie (i implicit use case-urile de extensie) se folosesc atunci cnd se modeleaz un comportament opional sau excepional, care nu condiioneaz finalitatea use case-ului de baz. De exemplu, un utilizator poate, optional, s verifice produsul electronic achizitionat la bancul de probe:

Relaia de tip includere

Relaia de tip includere se folosete atunci cnd use case-ul inclus nu este o parte esenial a fluxului din use case-ul de baz sau este un comportament care se repet n mai multe use case-uri. De pild, autentificarea n sistem, dei condiioneaz introducerea unei comenzi, nu este specific introducerii comenzii i de asemenea, poate fi folosit n mai multe use case-uri:

Exercitiul 1: S se realizeze diagrama cazurilor de utilizare pentru o aplicaie care simuleaz funcionarea unui sistem de rezervare online a biletelor de avion. n timpul unei sesiuni de lucru se pot efectua urmtoarele operaii:

cautarea zborurilor

efectuarea rezervarii

achizitionarea biletului

verificarea statusului zborului

anularea rezervarii

Optional se poate alege locul in avion si reprograma calatoria.Exercitiul 2: S se realizeze diagrama use case pentru o aplicaie care simuleaz funcionarea unui automat bancar. Deschiderea unei sesiuni de lucru ncepe prin introducerea unui card n automat si verificarea validitii informaiilor de pe card. n timpul unei sesiuni de lucru se pot efectua urmtoarele operaii:

extragerea unei sume de bani dintr-un cont,

afisarea soldului contului curent,

transferul unei sume de bani din contul curent al cardului, la un alt cont al clientului, aflat la aceeasi banc,

plata facturilor.

Optional se poate tipari o chitanta cu soldul contului. ATM-ul este verificat periodic pentru a functiona corespunzator iar zilnic este alimentat cu bani.Rezolvare:

Diagrama de clasa (Class Diagram)

Class diagram este un tip de diagram utilizat pentru descrierea structurii statice, adic a entitilor sau claselor existente ntr-un sistem. Acest tip de diagram este utilizat cel mai adesea de ctre dezvoltatori pentru specificarea claselor dar poate fi foarte util i pentru specificarea structurii unor sisteme sau subsistem dintr-un business real.Diagramele de clasa arata relatiile dintre clase de tipul: mostenire, agregare si asociere, precum si operatiile si atributele aferente fiecareia. Clasa are instane, sau realizri. Aceste instane sunt obiectele clasei. Prin conceptul de clas se descriu structura i comportarea obiectelor clasei. Structura conine atributele fiecrui obiect din clas.Elementele utilizate i notaiile lor sunt urmtoarele:

ElementDescriereNotaie

ClasO clas este reprezentat printr-un dreptunghi cu trei compartimente: n cel de sus se trece numele clasei, n mijloc se trec atributele clasei iar jos se trec operaiile specifice clasei.

MotenireMotenirea este o relaie care indic faptul c o clas motenete caracteristicile unei clase printe.

AsociereAsocierea este o relaie generic ntre dou clase. Aceste relaii pot fi de tipurile unu la unu, unu la muli, muli la muli.

DependenAtunci cnd o clas depinde de o alt clas, n sensul c utilizeaz acea clas ca i atribut al su, se folosete relaia de dependen.

AgregareAgregarea indic o relaie de tip ntreg-parte (se poate spune despre clasa printe c are clase de tip copil). n aceast relaie, clasa copil poate exista i fr clasa printe.

CompoziieAceast relaie deriv din agregare dar se utilizeaz atunci cnd o clas copil nu poate exista dect n cazul existenei clasei printe.

n reprezentarea clasei atributele i operaiile sunt declarate n compartimentele speciale din dreptunghi, astfel:

atributele: numele atributului: tipul atributului = valoare implicit

operaiile: numele operaiei (parametri): tipul valorii returnate

Atunci cnd diagrama este folosit pentru a modela structuri de business se pot folosi tipurile de date specifice business-ului, ca de exemplu: unitati monetare, unitati de timp, unitati de greutate, etc.

VizibilitateaPentru a specifica vizibilitatea unui atribut sau a unei operatiuni/metode, vom utiliza inaintea acestora urmatoarele notatii:

+Public orice clasa poate avea acces la informatie# Protejat numai clasa respectiva si succesorii sai pot accesa informatia- Privat numai clasa respectiva poate avea acces la informatie.

Motenirea este o relaie prin care se indic faptul c o clas motenete caracteristicile clasei printe. n plus, clasa copil poate avea propriile caracteristici.

Asocierea arat existena unei relaii ntre clase. Asocierile de tip binar (cu doua capete) sunt reprezentate in mod obisnuit printr-o linie care face legatura intre doua clase. Asocierile de ordin mai mare pot fi reprezentate ca avand mai mult de doua capete. Intr-un astfel de caz, capetele sunt conectate printr-un romb pozitionat central. O

O asociere poate primi un nume iar capete pot avea diverse roluri, grad de multiplicitate, vizibilitate si alte proprietati. Sunt cinci tipuri diferite de asocieri. Cele unidirectionale si bidirectionale sunt cele mai des intalnite.

Ex. O universitate este condusa de un singur rector si un rector conduce o singura universitate.

Ex. O universitate are mai multe facultati.

n exemplul de mai jos, ntre persoan i card bancar putem avea urmtoarea relaie: o persoan poate avea zero, unul sau mai multe carduri.

Un tip special de asociere este indicat printr-o clas de asociere. Ca si clasele, asocierile pot avea atribute si operatii. Pentru a arata grafic acest lucru, o clasa de asociere se conecteaza printr-o linie intrerupta. Altfel spus, relaia n sine este o clas.

n exemplul de mai jos, relaia de asociere dintre Banca si Persoana este intermediata de existenta unui card Bancar.

Dependena indic faptul c o clas depinde de alt clas, n sensul n care o modificare a celei de-a doua clase produce modificari in clasa dependenta. Verbul folosit este a utiliza.

Agregarea indic faptul c o clas printe are elemente de tipul clasei copil. Daca in cazul asocierii utilizam verbul a avea pentru a exprima legatura dintre doua clase, in cazul agregatii vom folosi verbul a contine. n exemplul de mai jos Catalogul poate avea mai multe Produse n acelai timp, un Produs poate exista chiar i daca acel catalog nu exista.

ntr-o relaie de tip compoziie clasa copil nu poate exista dect dac exist o instan a clasei printe. O componenta nu poate apartine decat unui singur intreg si daca acesta dispare, in mod automat dispare si componenta. n exemplul de mai jos instana clasei Comisie exist atta timp ct exist instana clasei Examen.

Restrictii si note:

Restrictiile pot fi atasate sub forma de nota pe care o ancoram de asocierea careia ii apartine. Restrictiiile mai pot fi atasate caracteristicii la care fac apel.

Exercitiul 1: Sa se realizeze diagrama de clase pentru o aplicatie ce simuleaza asignarea de proiecte in cadrul unei companii in care avem urmatoarele clase: angajat, departament, proiect. Avem urmatoarele doua restrictii:

fiecare angajat poate lucra la mai multe proiecte cu conditia ca proiectul sa apartina departamentului in care lucreaza;

bugetul proiectului nu trebuie sa depaseasca bugetul departamentului.

Cum sa identifici elementele necesare?

verifica specificatiile: legislatia, standardele- vor ajuta la identificarea atributelor si restrictiilor

identifica lucrurile tangibile: ordin, factura, card, cec, inventar

identifica roluri: client, manager, operator calculator

identifica actiuni: plasarea comenzii, anularea comenzii, incasarea banilor, trimiterea comenzii

urmariti interactiunile: dept. de vanzari primeste comenzi de la clienti,Substantivele folosite in descriere vor indica clase, atribute si obiecte

Verbele vor conduce la operatii, metode si relatii.

Din toate clasele identificate se vor opri clasele ce reprezinta obiecte fizice, entitati conceptuale, categorii de clase (ce vor deveni de fapt superclase) si clasele ce reprezinta interfete cu mediul exterior sistemului considerat.

Exercitiul 2: Identificati clasele componente ale unui hotel:

Exercitiul 3: S se realizeze diagrama de clase pentru o aplicaie care simuleaz funcionarea unui automat bancar. Automatul permite tranzacii bancare pentru o anumit banc, posesoare a automatului. Deschiderea unei sesiuni de lucru ncepe prin introducerea unui card n automat si verificarea validitii informaiilor de pe card. n timpul unei sesiuni de lucru se pot efectua urmtoarele operaii:

extragerea unei sume de bani dintr-un cont,

afisarea soldului contului curent,

transferul unei sume de bani din contul curent al cardului, la un alt cont al clientului, aflat la aceeasi banc.Diagrama de activitateActivity Diagram reprezint o modalitate de modelare vizual a fluxurilor. Cu ajutorul activity diagram pot fi modelate foarte bine use case-urile, dar, n aceeai msur, aceste diagrame pot fi folosite pentru modelarea proceselor de business (fr legtur cu sistemul informatic). n privina notaiilor, acestea sunt foarte asemntoare cu cele din diagrama de stare deoarece activity diagram nu sunt altceva dect o variaie a statechart diagram.

Elementele utilizate i notaiile lor sunt urmtoarele:

ElementDescriereNotaie

ActivitatePrin activitate vom desemna ntreaga activitate modelat prin diagram (format dintr-o succesiune de aciuni). Aceasta corespunde unui task de business.-

AciuneTeoretic, aciunile sunt numite activity states i reprezint o aciuni desfurate n cadrul unui task, sau, privite altfel, aciuni ale unui obiect.

Stare iniialReprezint punctul de intrare n activitatea respectiv. Punctul iniial este unic i din el pornete ntotdeauna o singur tranziie.

Stare finalReprezint punctul de ieire din activitate. Pot fi mai multe puncte de ieire dintr-o activitate.

TranziieLa ncheierea unei aciuni se trece ntotdeauna la o alt aciune sau la starea final. Tranziia reprezint trecerea de la o aciune la alta.

DeciziePrintr-o decizie (sau punct de decizie) se modeleaz un punct din cadrul fluxului unde se face o alegere, pe o anumit ramur din flux. n acest caz tranzaciile de ieire trebuie s fie de tip condiie. Aceeai notaie se folosete i pentru reunirea fluxurilor dup o decizie precedent (caz n care nu mai sunt necesare condiiile).

Condiie (guard) Este un tip special de tranziie, utilizat la fiecare dintre ieirile posibile dintr-o decizie. Se marcheaz ca un text pe sgeat i arat condiia care trebuie ndeplinit pentru a urma acel flux.

Bara de sincronizareEste folosit pentru cazurile n care anumite aciuni se pot desfura n paralel. ntr-un asemenea punct poate avea loc fie separarea fluxurilor, fie reunirea lor, dup o separare anterioar. Reunirea a dou fluxuri nseamn, de fapt, introducerea unei condiii, prin care o activitate nu poate ncepe dect dup terminarea activitilor finale din fluxurile ce trebuie sincronizate (de aici termenul de sincronizare).

Culoar (swimlane)Culoarele sunt reprezentri care permit separarea activitilor din flux dup criteriul responsabilitii realizrii activitii.

Punctele de decizie sunt puncte din fluxul de activiti n care se face o anumit alegere ntre mai multe variante posibile. Un caz simplu este ilustrat n figura de mai jos.

Trebuie observat c tranziiile care ies dintr-un punct de decizie sunt de tip guard au nscris ntre paranteze ptrate o condiie.Notaia utilizat pentru punctul de decizie poate fi folosit i pentru reconectarea fluxurilor (merge point), aa cum se poate vedea n figura de mai jos.

Aciunile paralele (asincrone) sunt aciuni care pot desfura n paralel. n viaa real, aceste aciuni sunt aciuni care nu depind una de cealalt. Paralelizarea aciunilor se reprezint pe diagram n felul urmtor:

Aceast reprezentare ne arat c aciunile Verificare stoc i Verificare bonitate client sunt declanate de apariia unei comenzi de la client i c aceste aciuni sunt independenta ntre ele (nceperea uneia nu depinde de rezultatul celeilalte).Revenirea la fluxul unic (cu aciuni sincronizate) se face n felul urmtor:

Aceast reprezentare ne arat c livrarea la client depinde de finalizarea aciunilor independente "Verificare stoc" i "Verificare bonitate client", astfel c aciunea "Livrare la client" nu poate ncepe dect dup finalizarea ambelor aciuni.

Pentru a aduga pe diagrame informaia privind responsabilitatea executrii aciunilor se folosesc elementele denumite swimlanes, plasndu-se fiecare aciune pe "culoarul" actorului care execut acea aciune.

Digrama de stare (Statechart Diagram)Diagramele de tip statechart sunt utilizate pentru a specifica posibilele stri prin care poate trece un obiect i modul n care se poate trece de la o stare la alta (modelare work-flow-uri, modelare fluxuri de documente, diagrame de stri). In alte limbaje de modelare acestea sunt denumite diagrame de tranzitie a starii sau simplu, diagrame de stare. O stare reprezinta o etapa din comportamentul unui obiect; astfel, putem avea stari initiale si stari finale.

Starea initiala: cea in care se regaseste obiectul atunci cand a fost creat pentru prima data;

Starea finala: nu mai trece prin nicio tranzitie.

Trecerea de la o stare la alta este determinat de tranzaciile intermediare - acestea corespund Aciunilor pe care le-am ntlnit la Activity Diagram (pn la urm, Statechart Diagram reprezint un alt mod de a vedea un flux ce poate fi modelat exclusiv prin Activity Diagram, inventat pentru a exprima mai elocvent trecerile de la o stare la alta).De exemplu o comand primit de la un client poate fi iniial n stare de ateptare, pentru ca un operator s verifice bonitatea clientului i stocul i s accepte comanda. Dup acceptare, se poate produce livrarea produselor comandate i comanda trece n starea de comand livrat dup care urmeaz facturarea i nchiderea comenzii.

Elementele utilizate i notaiile lor sunt urmtoarele:

ElementDescriereNotaie

StareIndic starea n care se gsete obiectul la un moment dat.

Stare iniialReprezint punctul de intrare sau punctul n care obiectul este iniiat. Punctul iniial este unic.

Stare finalReprezint punctul de final cnd starea obiectului nu se mai modific.

TranziieTranziia reprezint trecerea de la o stare la alta, provocat de apariia unui anumit eveniment.

n afara elementelor specifice enumerate mai sus se pot folosi punctele de decizie i aciunile paralele (asincrone) la Activity diagram. n figura de mai jos este exemplu de folosire a elementelor specifice statechart diagram, pentru cazul unei comenzi: