Despre UML. Introducere, generalitiCuvintele sunt cu adevrat mijlocul de comunicare cel mai puin eficient. Ele sunt cele mai expuse la interpretri greite i cel mai adesea prost nelese. Neale Donald Walsch

UML este n primul rnd un limbajUML (Unified Modelling Language) este, aa cum i spune i numele, un limbaj. El este un limbaj pentru modelare folositor n domeniul software, la realizarea documentelor de specificaii i, n general, bun pentru comunicarea ntre ingineri. De ce s utilizezi UML? Aa cum spune i vorba popular, o imagine exprim ct o mie de cuvinte. Mai mult dect att, cele o mie de cuvinte pot fi ambigue sau pot fi interpretate diferit. Aa cum tim, fiecare cuvnt poate avea mai multe sensuri (iar n limba romn aproape orice fraz poate fi interpretat lejer ca o propunere indecent). Cu siguran c exprimarea cea mai sofisticat, mai complet i mai sigur se poate face direct n limbaj de programare, care, cel puin dup tiina mea, rareori las loc de interpretri. n ingineria mecanic pentru a realiza modelul complet al unei piese, inginerul folosete desenul tehnic ca limbaj pentru comunicare, iar ca mod de reprezentare, vederea n epur. Aceast vedere n epur nseamn vizualizarea unei piese din trei puncte (din fa, de sus i din lateral) astfel nct piesa s fie definit complet. Un cititor avizat al desenului n epur va ti ntotdeauna s refac mental piesa desenat.

Dac din cauza complexitii piesei, cele trei fotografii nu sunt suficiente, inginerul va desena i alte detalii, sau seciuni ale piesei, dar privite din aceleai trei unghiuri. Fiecare dintre cele trei puncte de vizualizare a piesei (noi le vom zice neao, view-uri) reprezint un submodel capabil s descrie o parte a piesei, dar insuficient pentru a descrie complet piesa. Fiecare view arat piesa vzut dintr-un anumit punct de vedere iar modelul complet utilizeaz toate punctele de vedere relevante. Aa cum inginerul proiectant comunic prin desen tehnic, echipei, sau oricrei alte persoane interesate ntr-un limbaj standard, vizual (adic desenul tehnic), fcut s permit descrierea complet dar, n acelai timp, scutit de detalii inutile, inginerii software pot comunica cu maxim eficien n limbajul UML. La fel ca oricare limbaj acesta trebuie nvat i exersat astfel nct fiecare cuvnt s fie neles, s tim unde i cum se folosete, astfel nct s ne putem exprima n fraze coerente, care s spun exact ceea ce vrem s comunicm. Limbajul UML ne permite realizarea mai multor view-uri, ca nite fotografii din diverse unghiuri, ale unei realiti, astfel nct aceast realitate s fie surprins prin toate aspectele ei relevante. n software vom utiliza dou puncte de vedere necesare unei descrieri suficiente a realitii: (1) structural i (2) comportamental (behavioral). n standardul UML, versiunea 1.4 sunt definite urmtoarele diagrame, pe cele dou categorii: a. pentru descrierea structural: - Class Diagram; - Object Diagram; - Component Diagram; - Deployment Diagram. b. pentru descrierea comportamental: - Use Case Diagram; - Activity Diagram; - Statechart Diagram; - Sequence Diagram; - Collaboration Diagram. Deoarece aceast carte nu este un manual de UML, n continuare voi descrie succint doar acele diagrame care am considerat c sunt cele mai utile pentru analist. Pentru restul, las dumneavoastr plcerea studiului.

Tutorial UML (partea a II-a). Use Case DiagramCuvintele sunt cu adevrat mijlocul de comunicare cel mai puin eficient. Ele sunt cele mai expuse la interpretri greite i cel mai adesea prost nelese. Neale Donald Walsch Use Case Diagram Use case diagram este un tip de diagram din care reiese modul de utilizare a sistemului informatic - modul n care utilizatorii interacioneaz cu acesta (n coresponden direct cu task-urile acestor utilizatori.). Utilizarea use case diagram nu este absolut necesar pentru a scrie o specificaie cu use case-uri dar este util pentru a crea o imagine general asupra sistemului. Elementele utilizate i notaiile lor sunt urmtoarele: Element Descriere Actor Un actor este, n principiu, un utilizator al sistemului, dar poate fi i un alt sistem informatic care interacioneaz cu sistemul analizat. Use Case-urile se reprezint sub forma unei elipse n interiorul creia este scris numele Use Case-ului respectiv. Notaie

Use Case

Asocierea este utilizat pentru a indica legtura dintre un Actor i Asociere 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 urmtorul:

ntre 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.

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, n cazuri excepionale s aleag s depun o reclamaie dup efectuarea unei comenzi:

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:

Tutorial UML (partea a III-a). Activity DiagramCuvintele sunt cu adevrat mijlocul de comunicare cel mai puin eficient. Ele sunt cele mai expuse la interpretri greite i cel mai adesea prost nelese. Neale Donald Walsch

Activity DiagramActivity 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 statechart diagram deoarece activity diagram nu sunt altceva dect o variaie a statechart diagram. Elementele utilizate i notaiile lor sunt urmtoarele: Element Activitate Descriere Notaie

Prin activitate vom desemna ntreaga activitate modelat prin diagram (format dintr-o succesiune de aciuni). Aceasta corespunde unui task de business. Teoretic, aciunile sunt numite activity states i reprezint o aciuni desfurate n cadrul unui task, sau, privite altfel, aciuni ale unui obiect.

Aciune

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

Stare final Tranziie

Reprezint punctul de ieire din activitate. Pot fi mai multe puncte de ieire dintr-o activitate. La ncheierea unei aciuni se trece ntotdeauna la o alt aciune sau la starea final. Tranziia reprezint trecerea de la o aciune la alta. Printr-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). 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.

Decizie

Condiie (guard)

Este folosit pentru cazurile n care anumite aciuni se pot desfura n paralel. ntr-un asemenea punct poate avea loc fie separarea fluxurilor, fie reunirea Bara de lor, dup o separare anterioar. Reunirea a dou sincronizare 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.

Tutorial UML (partea a IV-a). Statechart Diagram Statechart DiagramDiagramele 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). 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: Element Stare Stare iniial Stare final Tranziie Descriere Indic starea n care se gsete obiectul la un moment dat. Reprezint punctul de intrare sau punctul n care obiectul este iniiat. Punctul iniial este unic. Reprezint punctul de final cnd starea obiectului nu se mai modific. Tranziia reprezint trecerea de la o stare la alta, provocat de apariia unui anumit eveniment. Notaie

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:

Pentru mai multe detalii pentru interpretarea acestei diagrame se gsesc (din motivul similaritii cu exemplele explicate acolo) n articolul despre Activity Diagram

Tutorial UML (partea a V-a). Class DiagramClass 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. Elementele utilizate i notaiile lor sunt urmtoarele: Element Descriere Notaie

Clas

O 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. Motenirea este o relaie care indic faptul c o clas motenete caracteristicile unei clase printe. Sensul sgeii indic sensul n care se poate spune despre clasa copil c este o, sau este de tipul clas printe. Asocierea este o relaie generic ntre dou clase. Aceste relaii pot fi de tipurile pot defini i regulile numerice de asociere (unu la unu, unu la mai muli, mai muli la mai muli).

Motenire

Asociere

Atunci cnd o clas depinde de o alt clas, n sensul Dependen c utilizeaz acea clas ca i atribut al su, se folosete relaia de dependen. Agregarea 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.

Agregare

Aceast relaie deriv din agregare dar se utilizeaz Compoziie 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, nu programrii, de exemplu: minut, dat calendaristic, minut etc.

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. n exemplul de mai jos, ntre Persoan i Autovehicul urmtoarea relaie: o Persoan poate avea zero, unul sau mai multe Autovehicule.

Un tip special de asociere este indicat printr-o clas de asociere. Altfel spus, relaia n sine este o clas. n exemplul de mai jos, relaia dintre Articol i Lista de preuri este de tip mai muli la mai muli: un Articol poate s apar pe mai multe Liste i o List poate avea mai multe Articole. Pe Liste diferite Articolele pot avea preuri diferite.

Dependena indic faptul c o clas depinde de alt clas, n sensul n care o funcie oarecare depinde de un parametru al su.

Agregarea indic faptul c o clas printe are elemente de tipul clasei copil. n exemplul de mai jos ara poate avea mai multe Judee dar, n acelai timp, un Jude poate exista chiar i n cazul n care clasa ara nu exist.

ntr-o relaie de tip compoziie clasa copil nu poate exista dect dac exist o instan a clasei printe. n exemplul de mai jos instana clasei Comisie exist atta timp ct exist instana clasei Examen.