Unified Modeling Language (prescurtat UML) este un limbaj standard pentru descrierea de modele și specificații pentru software. Limbajul a fost creat de către consorțiul Object Management Group (OMG) care a mai produs printre altele și limbajul de programare CORBA. UML a fost la bază dezvoltat pentru reprezentarea complexității programelor orientate pe obiect, al căror fundament este structurarea programelor pe clase, și instanțele acestora (numite și obiecte). Cu toate acestea, datorită eficienței și clarității în reprezentarea unor elemente abstracte, UML este utilizat dincolo de domeniul IT. Așa se face că există aplicații ale UML-ului pentru management de proiecte, pentru business Process Design etc.

Prima versiune de UML, UML 1.0, a apărut în anul 1990 ca reacție a numeroaselor limbaje de modelare propuse pe piață. UML îi are ca fondatori pe Grady Booch, Ivar Jacobson și James Rumbaugh, așa numiții „cei trei Amigos”. Ei au dezvoltat limbajul bazându-se inclusiv pe limbaje de modelare deja existente, însă incomplete ca gamă de funcționalități. Printre acestea se numără și OOSE, RDD, OMT, OBA, OODA, SOMA, MOSES și OPEN/OML.

Dezvoltarea versiunii 2 a UML a început în anul 1999 atunci când OMG a publicat un “request for information” referitor la UML 2. De atunci, UML s-a aflat într-un continuu ciclu de îmbunătățire, astăzi ajungând la varianta UML 2.4.1 (publicată în august 2011).

Principalele instrumente de lucru cu limbajul UML sunt Rational Rose și Enterprise Architect.Rational Rose este un instrument care oferă suport pentru două elemente esențiale în

abordarea modernă a unui proiect software: dezvoltare bazată pe componente şi controlul dezvoltării iterative. Deşi aceste elemente sunt conceptual independente, folosirea lor împreună este naturală şi benefică.

Enterprise Architect reprezintă un set de instrumente UML pentru profesioniștii care se ocupa cu dezvoltarea, testarea produselor soft. Enterprise Architect întrunește în sine puterea limbajului UML 2.1, avînd o interfață intuitivă și simplă. Proprietățile principale a instrumentului sunt: crearea documentației, creare și reverse engineering, vizualizarea aplicațiilor, suport pentru sistemul de modelare Model Driven Architecture.

METADescriere formala a limbajului UML se bazeaza pe careva structura ierarhica comuna a reprezentarilor de model care consta din patru nivele:• Meta-metamodelul• Metamodelul• Modelul• Obiectele utilizatoruluiNivelul de meta-metamodel creaza o baza initiala pentru toate reprezentari de metamodele. Destinatia principala a acestui nivel consta în definitia limbajului pentru specificarea metamodelului. Meta-metamodelul defineste modelul limbajului UML la cel mai înalt nivel de abstractizare si cea mai compacta descriere a lui.Din alta parte, meta-metamodelul poate specifica cîteva metamodele ce permite atingerea flexibilitatii potentiale de includere a notiunilor adaugatoare. Ca exemple de notatii ale acestui nivel pot fi meta-clasa, meta-atribut, meta-operatie.

Semantica meta-metamodelului nu intra în descrierea limbajului UML. Aceasta face limbajul UML mai simplu pentru studiere, fiindca nu cere cunoasterea teoriei limbajelor formale si a logicii formale.Metamodelul este un exemplar sau concretizarea meta-metamodelului. Scopul principal acestui nivel este definirea limbajului pentru specificarea modelelor. Acest nivel este mai constructiv decît cel precedent, fiindca semantica lui ale notiunilor de baza este mai dezvoltata. Toate notiunile de baza ale limbajului UML sunt notiunile nivelului de metamodel. Exemple de aceste notiuni sunt clasa, atributul, operatia, componenta, asocierea si multe alte.Modelul în contextul limbajului UML este exemplarul metamodelului în sensul ca fiecare model concret a unui sistem trebuie sa utilizeze numai notiunile lui metamodel concretizîndu-le cu privire la situatia data. Acest nivel este pentru descrierea informatiei despre un domeniu concret (de obiecte).Ca exemple a acestui nivel pot fi numele cîmpurilor ale bazei de date proiectate, de exemplu, numele si prenumele angajatului, vîrsta, postul, adresa, numarul de telefon. Totodata notiunile date sunt utilizate numai ca nume ale atributelor informationale corespunzatoare.

1. Diagrama Use-Case

O diagramă Use-Case este folosită în general pentru a indica sau caracteriza funcționalitățile și comportamentul sistemului ce interacționează cu unul sau mai mulți actori. Un actor poate fi un utilizator sau orice sistem ce poate să interacționeze cu sistemul modelat.

Atât timp ce actorii reprezintă utilizatorii, ei ajută la construirea unei imagini clare a ceea ce se așteaptă a se întâmpla în sistem. Cazurile de utilizare sunt construite pe baza nevoilor pe care le au actorii (utilizatorii). Aceasta asigura faptul că sistemul va produce ceea ce s-a dorit.

Elementele diagramei Use Case:

Element Descriere NotațieCaz utilizare Se utilizează pentru specificarea

particularităților comune a unui sistem. Scopul elementului constă în determinarea aspectului final sau a unui fragment de comportare a unei entități fără desfășurarea structurii interne a entității date.

Actorul An actor este un utilizator al sistemului , dar poate fi și un alt sistem informatic care interacționează cu sistemul analizat.

Interfața Specifică parametrii modelului care sunt vizibili din exteriorul sistemului fără indicarea structurii interne a lor. La use-case, interfața

INume

definește o totalitate de operații ce asigura serviciile necesare pentru un anumit actor.

Tipuri de relații în diagrama Use Case: Relația de generalizare este atunci când un actor sau un use case poate fi asimilat

unei clase de actori, respectiv de use case-uri. O generalizare intre două cazuri de utilizare indică faptul că cazul de utilizare poate împărtăși comportamentul definit în unul sau mai multe cazuri de utilizare. O generalizare între actori arată că un actor moștenește structura și comportamentul ale unui actor sau mai mulți actori.

Relația de tip extensie (și implicit use case-urile de extensie) se folosesc atunci când se modelează un comportament opţional sau excepţional, care nu condiţionează finalitatea use case-ului de bază.

Relaţia de tip includere: se foloseşte atunci când use case-ul inclus nu este o parte esenţială a fluxului din use case-ul de bază sau este un comportament care se repetă în mai multe use case-uri.

Asocierea este utilizată pentru a indica legătura dintre un Actor şi un Use Case, în sensul că acel actor participă într-un fel oarecare în acel Use Case.

2. Diagramele de interacțiune

Diagramele de interacțiune arată cum conlucrează obiectele prin transmiterea de mesaje pentru a satisface cerințele sistemului. Diagrama de interacțiuni ilustrează cum interacționează obiectele între ele cu ajutorul mesajelor. Este folosită pentru a modela comportamentul unei mulțimi de obiecte dintr-un anumit context, care interacționează în vederea îndeplinirii unui anumit scop.

Scop diagramei de interacțiune: specifică modul în care se realizează o operație sau un caz de utilizare. Diagrama de interacțiuni poate conține:

obiecte, actori clase; relații; mesaje.

Obiectele:

pot fi lucruri concrete sau prototipuri; între ele se pot stabili conexiuni semantice (legături); comunică între ele prin schimburi de mesaje. Mesaj: specifică o comunicare între obiecte; îi este asociată o acțiune care poate avea ca efect schimbarea stării actuale a

obiectului; forma generală a unui mesaj: [condiția gardă] acțiune (lista parametrilor).

Tipuri de acțiuni în UML

call: invocă o operație a unui obiect. return: returnează o valoare apelantului.

send: trimite un semnal. create: creează un obiect. destroy: distruge un obiect.

Există două tipuri de diagrame de interacțiune:

diagrama de colaborare diagrama de secvență.

Între cele două tipuri de diagrame nu există diferențe majore: diagramele de secvență scot în evidență ordinea în timp a mesajelor, iar diagramele de colaborare scot în evidență legăturile dintre obiecte.

3.1 Diagramele de secvență

Diagrama de secvență pune accentul pe aspectul temporal (ordonarea în timp a mesajelor). Notație grafică:

1. dimensiunea orizontală (axa ox): obiecte; 2. dimensiunea vertical (axa oy):

linia vieții obiectelor (grafic: linie punctată); perioada de activare în care un obiect preia controlul execuției (grafic:

dreptunghi pe linia vieții); mesaje ordonate în timp (grafic: săgeți).

Comunicare sincronă. Controlul execuției trece de la A la B și revine la A după ce B își termină execuția. Exemplu: apel de funcție. Comunicare asincronă. A trimite un semnal după care își continuă execuția mai departe. Exemplu: aruncarea unei excepții. Return. Întoarcere dintr-o funcție (procedură). În cazul în care este omisă se consideră implicit că revenirea se face la sfîrșitul activării.

3.2 Diagramele de colaborare

Particularitatea principală constă în reprezentarea grafică nu numai a interacțiunii dintre obiecte ci și relațiile structurale dintre obiecte. Spre deosebire de diagrama de secvență în diagrama de colaborare se reprezintă relațiile între obiecte care au o oarecare semnificație în timpul colaborării. În diagrama de colaborare nu se indică timpul interacțiunii obiectelor. Însă în diagrama de colaborare există posibilitatea de a numerota mesajele (interacțiunile), ceea ce ne permite de a vedea schimbul de mesaje în timp. Ca și în diagrama de secvență, principalul element este obiectul (instanța unei clase).

Multiobiect Multiobiect reprezintă o mulțime de obiecte la una din terminațiile asocierii. În diagrama de

colaborare entitatea multiobiect se utilizează pentru a reprezenta operațiile și semnalele care sunt adresate către multitudini sau totalități de obiecte. Multiobiectul se reprezintă grafic printr-un dreptunghi în alt dreptunghi. *Relația dintre multiobiect și obiectul care face parte din el se numește compoziția.

Obiecte active și pasive În UML obiectele se împart în active și pasive. Obiectele pasive folosesc numai datele care sunt transmise și nu pot avea activitate de control. Însă ele pot transmite semnale pe parcursul timpului de realizare a cererii. Obiect activ are un flux de control propriu și poate inițializa activitate de control.

Obiect compus Obiectul compus se mai numește obiect container. El este destinat pentru reprezentarea

obiectului care are structură proprie și flux intern de control. Obiectul compus este exemplarul unei clase compuse care este legat cu părțile sale componente prin relația de agregare sau compoziție. Obiectul compus se reprezintă prin dreptunghi din 2 componente: numele obiectului și numele obiectelor interne.

Stereotipuri de legături „association” – asociere, stereotip implicit „parameter” – parametrul metodei. Obiectul cărui i s-a transmis stereotipul parameter

poate fi doar parametru al unei metode „local”– variabilă locală a metodei. Nivelul de vizibilitate a variabilei locale e limitat

pînă la obiectul vecin. „global” – variabilă globală a metodei. Vizibil pentru toate elementele diagramei de

colaborare. „self” – relație recursivă.

Elementul colaborare Noțiunea de colaborare înseamnă o mulțime de obiecte care interacționează în context

comun. Scopul colaborării constă în specificarea particularităților realizării celor mai semnificative operații în sistem.

Niveluri Diagrama de colaborare poate fi reprezentată în 2 nivele:

1. Nivel de specificare – se reprezintă rolul clasificatoarelor și rolurile asocierilor în colaborarea dată

2. Nivel de exemplu – diagrama reprezintă obiectele și legăturile dintre ele cu mesaje

Diagrama de colaborare de nivel de specificare reprezintă rolurile elementelor (nivel de clase) ce participă la colaborare. La nivel de exemple sunt reprezentate doar obiectele care au legătură cu realizarea operațiilor.

3. Diagrama de clasă

Diagrama de clasă este folosită pentru reprezentarea structurii statice a unui model de sistem în terminologia POO. Diagrama de clasă reflectă diferite legături între entități și descrie structura lor internă.

Poate conţine Pachet Clase/Interfeţe Obiecte Relații

a. Asociere – relația semantică între două entitățib. Agregare – caz specific a asocierii; relația dintre partea întreagă și partea

componentc. Compoziția – caz specific a agregării; relația dintre partea întreagă și

partea component și părțile date nu pot exista independentd. Generalizare – relația dintre parinte și copile. Dependenţă – se utilizează în situația cînd un element al modelului poate

să ducă la schimbarea altui element.f. Realizare – relația dintre două entități una dintre care garantează

împlinirea relației

1) Clasa definește o totalitate de obiecte care au aceeași structură, comportament și relații cu alte clase. Elementele unei clase:

Nume: identifică o clasă Atribute: proprietăţi ale clasei Metode: implementarea unui serviciu care poate fi cerut oricărei instanţe a clasei.

2) Pachetul – mecanism universal de grupare a pachetelor în grup.

3) Interfața – o clasă abstractă care poate conține careva metode.

4) RelațiiSunt 4 tipuri de relații în diagrama claselor:

Dependența – relația dintre 2 entități (clase), una independentă (cu săgeata spre ea) și cealaltă – dependentă. Stereotipuri:

a) «access» - servește ca indicator de accesibilitate pentru atributele și operațiile clasei sursă pentru clasa client

b) «bind» - clasa client (dependentă) poate utiliza șabloane pentru următoarea parametrizare a sa

c) «derive» - atributele clasei client pot fi calculate după atributele clasei sursă

d) «import» - atribute și metode publice ale clase sursă pot fi considerate ca atribute și metode ale clasei client

e) «refine» - indică că clasa client servește ca precizie pentru clasa sursă (ca caracter istoric)

Asocierea – legătură semantică dintre 2 clase. Rol = nivel acces (+, -, #) + nume rol. Triunghi hașurat indică cine are primul acces la obiect. Multitudini (0, 0..1, 1, 0..*, 1..*, *, 7, 2..5) – standard e 1.

Generalizarea – relație semantică. Linie neîntreruptă cu triunghi nehașurat.

Restricțiile între paranteze figurate:a) {complete} – în diagramă sunt reprezentate toate clasele descendente, iar

altele nu mai pot existab) {incomplete} – nu sunt reprezentate toate clasele descendentec) {disjoin} – clasele descendente nu pot conține obiecte care concomitent

sunt exemplare a 2 sau mai multor clased) {overlapping} – moștenire multiplă

Realizarea – clasa realizează interfața.

4. Diagramele de comportament

Diagramele de comportament evidențiază ce trebuie sa se întâmple în sistemul modelat. Ele ilustrează comportamentul sistemului și sunt utilizate în general pentru a descrie funcționalitatea sa.

Există două tipuri de diagrame de comportament: diagrama de stări diagrama de activități

5.1 Diagrama de stări

Pentru modelarea comportamentului la nivel logic în UML pot fi folosite următoarele diagrame:

Stare Activități Secvență Colaborare

Spre deosebire de alte diagrame, diagrama de stare descrie procesul de modificare a stărilor pentru o anumită clasă (pentru obiectul, exemplarul unei clase), cu alte cuvinte reprezintă procesul de modificare a stărilor a unui anumit obiect. Schimbarea stării obiectului poate fi provocată de alte obiecte din exterior sau din interior. Diagrama dată se utilizează pentru descrierea consecutivității de stări posibile și treceri care împreună caracterizează comportamentul obiectului pe perioada ciclului său de viață.

Automat

Automatul în UML reprezintă o formalitate pentru modelarea comportamentului modelului a unui sistem întreg. Automatul este un pachet în care putem defini o mulțime de definiții care sunt necesare pentru a reprezenta comportamentul entității modelate.Automatul – diagramă de stare.

StareaNoțiune de bază care intră în formalismul automatul sunt stările și tranzițiile (trecere).

Diferența principală dintre stare și tranziție constă în: Durata aflării sistemului în stare depășește cu mult timpul care este destinat

trecerii. Se presupune că timpul tranziției este 0 și se trece dintr-o stare în alta momentan

În limbajul UML sub-stare se subînțelege o meta-clasă abstractă care se utilizează pentru modelarea situațiilor concrete. Pe parcursul căruia sunt prezente careva acțiuni, din cadrul clasei cât și în afară clasei. Starea poate fi în formă de valori concrete, a atributului sau a obiectului clasei, în cazul acestuia modificarea a unor valori va duce spre modificarea stării obiectului. E de menționat că nu fiecare atribut a clasei poate să caracterizeze starea obiectului. Starea în UML se reprezintă grafic în formă de dreptunghi cu colțurile rotunjite.

În afară de nume starea poate avea și acțiuni interne.

Numele stăriiNumele stării nu este altceva decât un text care dezvăluie sensul stării date de regulă

numele se scrie cu majusculă, verbul la timpul prezent sau participiu. În unele cazuri numele stării poate lipsi în acest caz starea este anonimă.În diagrama de stări putem utiliza și pseudo stări. Pseudo stări sunt de 2 tipuri:

1. Pseudo stare inițială.2. Pseudo stare finală.

Ambele sunt cazuri particulare a ale stării care nu conțin nici o acțiune internă. Pseudo stare inițială se utilizează pentru a ne reprezenta momentul de la care începe modificarea stărilor obiectului. Pseudo starea finală ne reprezintă sfârșitul de reprezentare a stării sau sfârșitul ciclului de viață a obiectului.În diagrama de stare poate fi doar o singură pseudo stare inițială și din ea iese doar o singură tranziție. Iar pseudo stări finale pot fi 1,2 și mai multe în dependență de caz și în ea doar se intră.În cazul când avem mai multe pseudo stări finale este obligatoriu de a le diferenția prin atribuirea diferitor nume.

TranzițiaTrecerea dintr-o stare în alta.

Tranziția – reprezintă o relație dintre 2 stări consecutive ceea ce ne indică trecerea de la o stare la alta. Ea poate fi de 2 tipuri:

1. Trigher 2. Netrigher

Dacă trecerea nu are suplimentar careva aliniat de text (de regulă eveniment) atunci astfel de tranziție se numește netrigher, în rest trigher.

Signatura_evenimentului[condiția_gardă]/acțiunea Signatura_evenimentului – specificația unui fapt Condiția_gardă - se verifică dacă este true sau false Acțiunea – are loc numai cînd se executa tranziția

Starea compusăStarea compusă - este starea compusă care este alcătuită din 2 sau mai multe stări depuse.

Stările depuse vor fi sub-stări pentru starea inițială. Relația dintre sub-stări și starea inițială va fi compoziția.

Substări disjuncteSubstări disjuncte – se utilizează pentru modelarea comportamentul obiectului în timpul

căruia obiectul se poate afla doar într-o singură sub-stare.

Substare compusă cu stări concurente.Substări concurente – pot specifica 2 sau mai multe subautomate care pot executa în

paralel. Fiecare subautomat are regiunea sa în starea compusă. Subautomatul poate fi atât stare compusă cu substări depuse cât și starea compusă cu stări disjuncte.

5.2 Diagrama de activități

Pentru modelarea proceselor de executare a operațiilor în limbajul UML se utilizează diagrama de activități. Diagrama de activități poate fi numită ca un caz particular diagrama de stări (are aceleași tipuri de activități și elemente). Fiecare stare de activitate corespunde unei operații elementare și ca și în cazul diagramei de stări trece în diagrama de activitate după executarea diagramei de stări.

Sensul principal al acestei diagrame constă în vizualizarea particularităților , operațiilor al unor clase pentru a reprezenta algoritmul de execuție. Diagrama de activitate - este un caz particular a stării însă nu poate avea tranziții interne. Grafic se reprezintă printr-un dreptunghi unde are prin părți 2 bucle.Uneori este necesar de a menționa că starea de activitate este o stare compusă.Diagrama de tranziție - în comparație cu diagrama de stări toate tranzițiile sunt netrigher.

PseudostăriÎntr-o diagramă de stare poate fi doar o intrare/ieșire.

În diagrama de activități este o pseudo-stare inițială și o pseudo-stare finală.

Fork și JoinCel mai mare neajuns al schemelor bloc constă în aceea că nu putem reprezenta stări

paralele. În UML există elemente speciale pentru reprezentarea calculelor paralele, acest simbol se reprezintă prin linie dreaptă, verticală sau orizontală, analogic notații unei tranziții în formalismul rețelelor Petre. Sunt 2 entități fork și join.

1. Fork – divizarea în mai multe fluxuri paralele, deci are 1 intrare și 2 sau mai multe ieșiri.

2. Join – unirea fluxurilor paralele, mai multe intrări și 1 ieșire.

PartițiaDiagrama de activități poate fi folosită nu numai pentru specificarea algoritmilor de

calculsau a fluxului de control a sistemelor de programare, dar și în modelarea business proceselor. Activitatea oricărei companii reprezintă o totalitate de acțiuni independente care sunt îndreptate spre un anumit rezultat. Modelarea business proceselor la se utilizează pentru reprezentarea subdivizării. Subdivizările sunt responsabile de careva acțiuni iar business procesele reprezintă trecerea de la o subdiviziune la alta. Pentru modelarea așa tipuri de particularități în limbajul UML se utilizează partițiile. Partițiile sunt divizate prin linii verticale neîntrerupte. 2(două) linii verticale reprezintă partiția sau subdiviziunea. Linia partițiilor pot fi întretăiate doar de tranziție.

ObiectulObiectul în afară de nume poate conține și careva caracteristici (se scriu după numele

obiectului în paranteze pătrate []). Între obiect și orișicare element dintre diagramă poate fi utilizat relația de dependență (linie neîntreruptă cu săgeată). Obiectele pot fi plasate cât

5. Diagrama de componente

Diagrama de componente permite determinarea arhitecturii sistemului elaborat prin determinarea dependenților între componente care pot fi fișiere text, fișiere cu cod sursă,biblioteci, fișiere dinamice, etc. În majoritatea cazurilor componenta corespunde unui anumit fișier. Diagrama de componente se utilizează pentru următoarele scopuri:

1. Vizualizarea structurii comune a codului sursă a careva aplicații.2. Specificarea variabilei executabile a careva aplicații.3. Reutilizarea unor fragmente din cod sursă.4. Reprezentarea conceptuală și fizică a sistemelor de baze de date.

Elementele principale a diagramei de componente sunt:1. Componenta2. Interfața (entități)3. Dependența (relațiile)

ComponentaPentru reprezentarea entităților fizice în limbajul UML se utilizează componenta, ea poate realiza un set de interfețe și desemnează elementele reprezentării fizice a unui model.

În diagrama de componente sunt specificate 3 feluri de componente:1. Componente de regrupare - care specifică executarea de către sistem a fucțiilor

sale, așa componente pot fi: biblioteci dinamice (*.dll), web pagini (html, xml, php), fișierele help (*.hlp).

2. Produse de lucru – pentru limbajul c++ aceste sunt fișierele cu extensia *.h și *.cpp.

3. Componente de executare – aceste elemente în unele cazuri mai sunt numite artefacte (în așa fel se subliniază conținutul lor informațional).

Un alt mod de specificare a tipurilor de componente este indicarea stereotipurilor componentei care de regulă este plasat deasupra numelui.

Stereotipuri:1. Library – se referă la primul tip de componente (de regrupare) și de obicei indică

sau reprezintă bibliotecile dinamice sau statice.2. Table – se referă la primul tip de componente (de regrupare) care reprezintă

tabele bazei de date.3. File – se referă la al doilea tip de componente care de regulă reprezintă fișierele

cu textul inițial a programului.4. Document - se referă la al doilea tip de componente produs de lucru și reprezintă

un document.5. Executable - se referă la al treilea tip de componente.

Interfața – element realizat de componentăDependența - este considerată relația principal. Modificarea unei component a modelului va influența la schimbarea altei component.

6. Diagrama de amplasare

Diagrama de amplasare se utilizează pentru reprezentarea elementelor reale în program. Pentru produsele program rulate local nu este nevoie de a realiza diagrama de amplasare.Se utilizează în următoarele scopuri:

1. Definirea componentelor sistemului2. Reprezentarea legăturilor dintre toate nodurile sistemei3. Posibilitatea reconfigurării topologiei sistemului

În model poate exista doar o singură diagramă de amplasare.Elementele de bază a diagramei de amplasare sunt:

Nodul (procesor sau dispozitiv) – element fizic a sistemului care are o anumită resursă de calcul (elementul poate primi informația, stoca, prelucra și a o transmite)

Relația de asociere Adăugător: interfața, componenta, relația de dependență și de realizare