MODELARE TIP UML,
Modelarea
Andreea
Proceselor
Elenade
Circiumaru
Afaceri
IDEF, BPMN
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
- 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
I.3. 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 <-info> sau este de tipul
<-info> 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.
[Link] (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 intr-
o 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
[Link]
[Link]
[Link]
[Link]
[Link]