Modelare Tip UML [PDF]

Zitiervorschau

MODELARE TIP UML, IDEF, BPMN

Modelarea Andreea Proceselor Elenade Circiumaru Afaceri

I. Modelare tip UML (Unified Modelling Language) I.1.

Ce este UML. Introducere, generalitati.

UML (Unified Modelling Language) este, asa cui ii spune si numele, un limbaj standard pentru modelare, folosit in domeniul software la realizarea documentelor de specificatii. UML a fost dezvoltat pentru reprezentarea complexitatii programelor orientate obiect, al caror fundament este structurarea programelor pe clase, si instantele acestora, numite si obiecte. Cu toate acestea, UML este utilizat dincolo de domeniul IT, datorita eficientei si claritatii in reprezentarea unor elemente abstracte. Asa cum un inginer proiectant comunica prin desen tehnic, vizual, facut sa permita descrierea complete, dar in acelasi timp, scutita de detalii inutile, inginerii software pot comunica cu maxima eficienta in limbajul UML. Asemenea oricarui alt limbaj, UML trebuie invatat si exersat astfel incat fiecare „cuvant” sa fie inteles, sa se stie unde si cum se foloseste. Cu toate acestea UML nu are o notatie ferma, el fiind generic si extensibil. Limbajul UML permite realizarea mai multor view-uri, ca niste fotografii ale unei realitati, realizate din mai multe unghiuri diferite, astfel incat realitatea sa fie surprinsa prin toate aspectele relevante ale sale. Limbajul UML este reprezentat prin diagrame, majoritatea fiind reprezentate sub forma de grafuri. In software sunt suficiente pentru descrierea unei realitati doua puncte de vedere: structural si comportamental.

I.2.

Tipuri de diagrame UML

In standardul UML sunt definite urmatoarele diagrame, grupate in functie de cele doua categorii: a) Pentru descrierea structurala: - Diagrame UML de clase - prezinta structura static in termini de clase si relatii intre clase de obiecte (asocieri, agregari, compuneri, extinderi prin mostenire, implementari de interfete). - Diagrame UML de obiecte - prezinta obiectele si legaturile lor, fiind niste diagrame de comunicatie simplificate, fara reprezentarea mesajelor transmise intre obiecte. - Diagrame UML de componente - prezinta componentele reutilizabile si relatiile dintre ele in cadrul sistemului software, insistand pe interfetele oferite si necesare. - Diagrame UML de pachete - arata felurile in care clasele sau componentele sunt grupate. b) Pentru descrierea comportamentala

-

I.3.

Diagrame UML pentru cazuri de utilizare – prezinta modul in care un sistem este utilizat Diagrame UML de activitati - reprezinta comportamentul unei operatii in termeni de actiuni sub forma fluxurilor de activitati si de obiecte Diagrame UML de secventa - numite si diagrame MSC (Message Sequence Charts) prezinta temporal interactiunile intre obiecte Diagrame UML masini de stari (Statecharts) - numite si diagrame FSM (Finite State Machines), automate, State Charts, etc prezinta comportamentul unei clase in termeni de stari si de tranzitii intre stari Cele mai utilizate tipuri de UML. Particularitati.

Diagramele UML de clase sunt utilizate cel mai dez de catre dezvoltatori pentru specificarea claselor, dar pot fi foarte utile si pentru specificarea structurii unor sisteme sau subsisteme dintr-un business real. Elementele utilizate si notatiile lor: -

-

-

-

-

Clasa – reprezentata printr-un dreptunghi cu trei compartimente: in cel de sus se trece numele clasei, in mijloc se trec atributele clasei iar jos se trec operatiile specifice clasei. Mostenirea – este o relatie care indica faptul ca o clasa mosteneste caracteristicile unei clase parinte. Sensul sagetii indica sensul in care se poate spune despre clasa copil ca este o sau este de tipul clasa parinte. Asocierea – este o relatie generica intre doua clase. Aceste relatii pot defini si regulile numerice de asociere (unu la unu, unu la mai multi, mai multi la mai multi). Un tip special de asociere este indicat printr-o clasa de asociere. Altfel spus, relatia in sine este o clasa. Dependenta – atunci cand o clasa depinde de alta clasa, in sensul ca utilizeaza acea clasa ca si atribut al sau. Agregare – indica o relatie de tip intreg-parte ( se poate spune despre clasa parinte ca are clase de tip copil). In aceasta relatie, clasa copil poate exista si fara clasa parinte. Compozitie – relatie ce deriva din agregare, dar se utilizeaza atunci cand o clasa copil nu poate exista decat in cazul existentei clasei parinte.

Diagramele cazurilor de utilizare prezinta functiile sistemului din punct de vedere al utilizatorului, adica modurile in care sistemul este utilizat. Elemente utilizate si notatiile lor: -

Actor – un utilizator al sistemului sau un alt sistem informatic care interactioneaza cu sistemul analizat Caz de utilizare (Use Case) – reprezentat sub forma unei elipse in interiorul careia este scris numele respectivului caz de utilizare Asociere – este utilizata pentru a indica legatura intre un actor si un caz de utilizare, in sensul ca acel actor participa intr-un fel oarecare in acel caz de utilizare.

Diagramele UML de activitati sunt asemanatoare organigramelor (flow charts). Cu ajutorul acestor diagrame pot fi modelate foarte bine use case-urile, dar in aceeasi masura aceste diagrame pot fi folosite pentru modelarea proceselor de afaceri, fara legatura cu sistemul informatic. Notatiile sunt asemanatoare cu cele din diagramele masini de stari.

Elementele utilizate si notatiile lor sunt urmatoarele: -

-

-

Activitate – prin activitate este desemnata intreaga activitate modelata prin diagrama (formata dintr-o succesiune de actiuni). Aceasta corespunde unui task de business. Actiune – numita si activity state, reprezinta o actiune desfasurata in cadrul unui task sau o actiune a unui obiect Stare initiala – punctul de intrare in activitatea respectiva, fiind unic si din el pornind intotdeauna o singura tranzitie Stare finala – punctul de iesire din activitate. Pot exista mai multe puncte de iesire dintr-o activitate. Tranzitie – la incheierea unei actiuni se trece intotdeauna la o alta actiune sau la starea finala, tranzitia reprezentand aceasta trecere Decizie – punct din cadrul fluxului unde se face o alegere, pe o anumita ramura din flux. Conditie – un tip special de tranzitie, utilizata la fiecare dintre iesirile posibile dintr-o decizie. Se marcheaza ca un text pe sageata si arata conditia care trebuie indeplinita pentru a urma respectivul flux. Bara de sincronizare – este folosita pentru cazurile in care anumite actiuni se pot desfasura in paralel

-

Culoar (swimlane) – reprezentare care permite separarea activitatilor din flux dupa criteriul responsabilitatii realizarii activitatii.

Diagramele UML masini de stari sunt utilizate pentru a specifica posibilele stari prin care poate trece un obiect si modul in care se poate trece de la o stare la alta. Trecerea de la o stare la alta este determinata de tranzactiile intermediare. Acestea corespund Actiunilor din diagramele de activitati. Elementele utilizate si notatiile lor sunt urmatoarele: -

Stare – indica starea in care s egaseste obiectul la un moment dat Stare initiala – reprezinta punctul de intrare sau punctul in care obiectul este intial. Punctul initial este unic. Stare finala – reprezinta punctul de final cand starea obiectului nu se mai modifica

-

Tranzitie – reprezinta trecerea de la o stare la alta, provocata de aparitia unui anumit eveniment.

II. IDEF (Integration Definition) II.1.

Ce este IDEF?

IDEF se refera la o familie de limbaje de modelare in domeniul sistemelor si a ingineriei software. Ele acopera o gama larga de utilizari, de la modelarea functionala a datelor, simulare, analiza/design orientat-obiect pana la dobandirea de cunostinte. Componentele cele mai larg recunoscute si utilizate ale familiei IDEF sunt IDEF0, un limbaj functional de modelare construit peste SADT (Structured Analysis and Design Technique) si IDEF1X, care abordeaza modele informationale si probleme de proiectare a bazelor de date. Metodele IDEF definite pana in prezent sunt:

-

IDEF0 – modelare functionala IDEF1 – modelare informationala IDEF1X – modelare de date IDEF2 – design al modelelor de simulare IDEF3 – descrierea procesului de captare IDEF4 – design orientat – obiect IDEF5 – Ontology description capture IDEF6 – Design rationale capture IDEF7 – Information system auditing IDEF8 – User interface modeling IDEF9 – Business constraint discovery IDEF10 – Implementation architecture modeling IDEF11 – Information artifact modeling IDEF12 – Organization modeling IDEF13 – Three schema mapping design IDEF14 – Network design

2.2 Exemplificari IDEF0 – este destinat modelarii deciziilor, actiunilor si activitatilor unei organizatii sau ale unui sistem. In forma originala, IDEF0 include atat o definitie a unui limbaj de modelare grafica (sintactica si semantica), cat si o descriere a unei metodologii ample de dezvoltare de modele.

IDEF1X – este destinat dezvoltarii de modele semantice de date. Cu ajutorul IDEF1X se pot crea modele grafice care sa reprezinte structura si semantica informatiilor in cadrul unui mediu sau sistem. Modele construite cu ajutorul IDEF1X

pot servi la managementul datelor drept resurse, integrarea sistemelor informatice si la constructia bazelor de date.

III.BPMN (Business Process Modeling Notation) III.1. Ce este BPMN?

BPMN este o notatie grafica utilizata pentru a specifica procesele intr-o diagrama de procese de afaceri (BPD – Business Process Diagram). Obiectivul BPMN este de a sprijini managementul proceselor de afaceri, atat pentru utilizatorii tehnici, cat si pentru utilizatorii business, prin furnizarea unei notatii care este intuitiva utilizatorilor business, dar in acelasi timp capabila sa reprezinte semantici complexe de proces. Specificatia BPMN ofera, de asemenea, o mapare intre notatiile

grafice si constructiile de baza ale limbajelor de executie, in special limbajul de executie al proceselor de afaceri (BPEL – Business Process Execution Language). Scopul principal al BPMN este acela de a oferi o notatie standard, usor de inteles de catre toate partile interesate ale afacerii. Printre acestia se numara analistii de afaceri care creeaza si perfectioneaza procesele, dezvoltatorii tehnici responsabili cu punerea in aplicare a acestora, precum si managerii de afaceri care le monitorizeaza si gestioneaza. In consecinta, BPMN serveste drept un limbaj comun, reducand decalajul de comunicare care are loc frecvent intre proiectarea si implementarea proceselor de afaceri. Singura relatie formala intre UML si BPMN este aceea ca ambele standarde sunt mentinute de OMG (Object Management Group). Ambele limbaje sunt notatii grafice standardizate, care permit modelarea de procese de afaceri in urmatorul mod: BPMN este dedicat modelarii de procese de afaceri, in timp ce UML are mai multe tipuri de diagrame, printre care diagrama de activitati care este potrivita pentru modelarea proceselor de afaceri. Diferenta dintre cele doua limbaje este aceea ca UML este un limbaj orientat obiect, in timp ce BPMN este orientat proces, deci mult mai indicat in domeniul proceselor de business. III.2. Componente Modelele BPMN sunt reprezentate de diagrame simple construite cu ajutorul unui set limitat de elemente grafice. Acestea sunt grupate in 4 categorii de baza: 1. Obiecte de flux (Flow objects): 1.1Evenimente – un eveniment este reprezentat printr-un cerc si reprezinta ceva ce se intampla in momentul prezent (spre deosebire de o activitate, care reprezinta ceva ce este executat). Pictogramele din interiorul cercului reprezinta tipul evenimentului (exemplu: un plic reprezinta un mesaj, un ceas reprezinta timp). Evenimentele sunt de doua tipuri: de tip catching (de exemplu, atunci cand „prinderea”, receptarea unui mesaj porneste un proces) sau de tip throwing („aruncarea” sau emiterea unui mesaj atunci cand un proces se termina). Evenimentele mai pot fi clasificate si in functie de momentul in care se produc, astfel: - eveniment de start – se comporta ca un declansator al unui proces; reprezentat printr-un singur cerc cu linie subtire si poate fi doar de tip „catch” - eveniment intermediar – reprezinta ceva ce se intampla intre un eveniment de start si unul de final; este reprezentat printr-un cerc cu linie dubla si poate fi de tip „catch” sau „throw” - eveniment de final – reprezinta rezultatul unui proces; este reprezentat printr-un cerc cu linie subtire sau groasa si poate fi doar de tip „throw”

1.2Activitati – o activitate este reprezentata sub forma unui dreptunghi cu colturi rotunjite si descrie tipul de munca ce trebuie executata. Activitatea este un termen generic al muncii pe care o executa o companie. Poate fi atomic sau compus. Activitatile pot fi clasificate in mai multe tipuri: - Task – reprezinta o singura unitate de lucru care nu mai poate fi descompusa in unitati mai mici. Task-ul este un tip de activitate atomica si este nivelul cel mai jos de activitate ce poate fi ilustrata intro diagrama de proces. Un set de taskuri reprezinta o procedura de nivel inalt. - Sub-proces – este utilizat pentru a ascunde sau evidentia nivele aditionale ale detaliilor procesului de afaceri. Cand este colapsat, un sub-proces este indicat printr-un plus (+) deasupra laturii inferioare a dreptunghiului. Cand este expandat, dreptunghiul se extinde pentru a arata toate obiectele din flux, obiectele de conectivitate si artefactele. Sub-procesul este un tip de activitate compusa; are propriile evenimente de start si sfarsit. - Tranzactii – o tranzactie este o forma de sub-proces in care toate activitatile componente trebuie sa fie tratate ca un intreg (de exemplu toate trebuie finalizate pentru a indeplini un obiectiv si daca oricare dintre ele esueaza, toate trebuie sa fie compensate (anulate). Tranzactiile sunt reprezentate diferit de procesele expandate, fiind inconjurate de o bordura dubla. - Activitate de tip „call” (Call Activity) – reprezinta un punct in cadrul procesului unde un proces sau task global este refolosit. O activitate de tip „call” este reprezentata diferit de orice alt tip de activitate, dreptunghiul avand o bordura ingrosata.

1.3Gateway-uri – sunt reprezentate prin forme de diamant (romb) si determina bifurcarea sau fuzionarea traiectoriilor, in functie de anumite conditii exprimate. Gateway-urile pot fi de mai multe tipuri: - Exclusiv – utilizat pentru a crea fluxuri alternative intr-un proces. Este numit exclusiv deoarece o singura cale poate fi aleasa. - Bazat pe eveniment (Event Based) - conditia care determina calea unui proces este bazata pe evaluarea unui eveniment. - Paralel – utilizat pentru a crea cai paralele fara a evalua nicio conditie

-

Inclusiv – utilizat pentru a crea fluxuri paralele unde toate caile sunt evaluate Exclusiv, bazat pe eveniment – un eveniment este evaluat pentru a determina care dintre caile mutual exclusive trebuie aleasa Complex – utilizat pentru a modela un comportament de sincronizare complex Paralel, bazat pe eveniment – doua procese paralele sunt pornite bazandu-se pe acelasi eveniment, dar fara a se face evaluarea evenimentului

2. Obiecte de conectivitate (Connecting objects) – „Flow objects” sunt conectate intre ele prin elemente de conectivitate, care sunt de trei tipuri, dupa cum urmeaza: 2.1. Fluxul de secventa (sequence flow) – este reprezentat printr-o linie continua, avand la capat o sageata, si indica in ce ordine sunt executate activitatile. Fluxul de secventa poate avea un simbol la capatul opus sagetii, o forma mica de diamant care indica unul din numarul de fluxuri conditionale dintr-o activitate, in timp ce o linie diagonala (in locul numarului) indica fluxul implicit dintr-o decizie sau activitate. 2.2. Fluxul de mesaje (message flow) – reprezentat printr-o linie punctata, avand la capatul de inceput un cerc si o sageata la capatul final. Este utilizat pentru a indica ce mesaje circula intre limitele organizationale (de exemplu intre pool-uri). Fluxul de mesaje nu poate fi niciodata folosit pentru a conecta activitati sau evenimente in cadrul aceluiasi pool. 2.3. Asocieri (association) – reprezentate prin linii punctate. Sunt utilizate pentru a asocia un artefact sau un text unul flux de obiecte.

3. Swim lanes (netraductibil) – reprezinta un mecanism vizual de a organiza si categorisi activitati. Pot fi de doua tipuri: 3.1. Pool – reprezinta participantii majoritari la un proces, in general separand organizatii diferite. Un pool contine unul sau mai multe lane-uri (asemenea unui bazin – pool – care contine mai multe culoare de inot – lane). Un pool poate fi deschis (indicand detalii interne), caz in care este reprezentat printr-un dreptunghi mare cu unul sau mau multe lane-uri (culoare), sau colapsat (atunci cand ascunde detaliile interne), caz in care este reprezentat drept un dreptunghi gol intinzandu-se pe latimea sau inaltimea diagramei. 3.2. Lane (culoar) – utilizat pentru a organiza si categorisi activitati in cadrul unui pool, grupandu-le dupa functie sau rol, si este reprezentat printr-un dreptunghi care are latimea sau inaltimea unui pool. Un lane contine obiecte de flux, obiecte de conectivitate si artefacte.

4. Artefacte (Artifacts) – permit dezvoltatorilor sa introduca informatii suplimentare in model/diagrama. In acest fel modelul sau diagrama devine mai usor de citit. Exista tipuri predefinite de artefacte, acestea fiind: 4.1. Obiecte de date (Data objects) – indica cititorului ce date sunt necesare sau produse in urma unei activitati. 4.2. Grupurile (Group) – un grup este reprezentat printr-un dreptunghi cu colturi rotunjite si bordura punctata. Grupul este utilizat pentru a grupa activitati diferite, dar nu afecteaza fluxul diagramei. 4.3. Adnotarile (Annotation) – folosite pentru a furniza cititorului informatii suplimentare.

III.3.

Exemple

IV. Bibliografie https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation

http://www.idi.ntnu.no/emner/tdt4252/2013/Additional%20reading/uml-vsidef-griffithsuniversity.pdf https://en.wikipedia.org/wiki/IDEF http://webspace.ulbsibiu.ro/sorin.negulescu/media/curs_is/uml.pdf