UML Unified Modeling Language

Introducere
Problema principal care apare n dezvoltarea programelor este complexitatea. Folosirea
de modele poate nlesni abordarea de probleme complexe.
Un model este o simplificare unui anumit sistem, ce permite analizarea unora dintre
proprietile acestuia. Lucrul cu modelele poate facilita o mai bun nelegere a sistemului
modelat, datorit dificultii intrinseci de nelegere a sistemului n ntregul sau.
Folosirea tehnicii divide et impera permite nelegerea prilor componente ale unui
sistem, iar ansamblul sistemului ca o interaciune ntre prile acestuia. Un model reuit reine
caracteristicile importante ale obiectului modelat i le ignor pe cele irelevante. De remarcat c
noiunile de important / irelevant sunt relative, ele depinznd de scopul pentru care se face
modelarea. Astfel apare plauzibil construirea mai multor modele pentru un anumit obiect,
fiecare surprinznd anumite aspecte ale acestuia.
Orice metodologie de dezvoltare a programelor abordeaz problema comunicrii ntre
membrii echipei. Este posibil s apar situaii n care modelul construit de proiectant s nu fie
neles exact de cel ce scrie cod, fie din cauza lipsei de precizie a modului n care este prezentat
modelul, fie datorit lipsei unor elemente importante ale acestuia; adesea o serie de amnunte
subtile ce sunt evidente pentru designer nu sunt transmise. O rezolvare a problemei comunicrii
ar fi ca aceeai persoan s fie implicat direct n toate fazele dezvoltrii. Chiar i aa, apare des
situaia n care o persoan trebuie s continue munca alteia.
Se impune aadar existena unui limbaj formal de comunicare al cerinelor.
Termenul formal este esenial. De obicei, chiar i n proiecte de dimensiuni reduse, se
face modelare, ns ntr-un limbaj specific celui care modeleaz, determinat de viziunea asupra
problemei i de pregtirea acestuia. Folosirea unui limbaj intern nu trebuie privit ca negativ,
ea avnd se pare un rol esenial n gndire n general i n modelare n particular. Modelarea este
posibil, chiar i fr folosirea explicit a unui limbaj.
Formalismul limbajului de modelare const n stabilirea de elemente cu o semantic
asupra creia se convine i cu ajutorul crora s se poat transmite idei n mod ct mai eficient i
mai puin ambiguu.
Limbajul de modelare UML i propune s defineasc o modalitate ct mai precis,
general i extensibil de comunicare a modelelor. El a fost creat n primul rnd pentru a facilita
proiectarea programelor, ns datorit expresivitii sale poate fi folosit i n alte domenii
(proiectare hardware, modelarea proceselor de afaceri etc.). Folosirea UML faciliteaz
comunicarea modelelor, ns nu asigur crearea unui model bun. Limbajul de modelare nu
specific i nu poate specifica ce modele trebuie create, n ce ordine i cum trebuie ele utilizate
pentru un sistem particular.
ncepnd cu mijlocul anilor 1970 i continund n anii 1980 au aprut diverse limbaje de
modelare, odat cu creterea experienei de lucru n cadrul paradigmei orientate obiect. Astfel,
numrul de limbaje de modelare ajunge de la 10 pn la mai mult de 50 n perioada 1989-1994.
Limbajele de modelare de succes din aceast perioad sunt:
Booch - potrivit mai ales pentru proiectare i implementare, cu dezavantajul
unor notaii complicate;
OOSE (Object-Oriented Software Engineering) - aceast metod a propus aanumitele cazuri de utilizare, care ajutau la nelegerea comportamentului
ntregului sistem;

OMT - Object Modeling Technique - potrivit pentru analiz i sisteme

informaionale cu multe date.

La mijlocul anilor 1990, cnd este semnalat o nou generaie de limbaje de modelare, a
nceput un proces de omogenizare, prin ncorporarea n fiecare limbaj a caracteristicilor gsite n
celelalte limbaje.
Cei trei autori ai limbajelor de modelare principale, Booch, Jacobson i Rumbaugh au
ajuns la concluzia ca ar fi mai bine s conduc evoluia limbajelor lor pe un acelai drum, pentru
a elimina diferenele gratuite ce nu fceau dect sa ncurce utilizatorii. Un al doilea motiv a fost
unul pragmatic, reieit din necesitatea industriei software de a avea o oarecare stabilitate pe piaa
limbajelor de modelare. Al treilea motiv a fost convingerea c prin unirea forelor se pot aduce
mbuntiri tehnicilor existente.
Dezvoltarea UML a nceput n mod oficial n octombrie 1994, cnd Rumbaugh s-a
alturat lui Booch n cadrul companiei Rational Software, ambii lucrnd la unificarea limbajelor
Booch i OMT.
Versiunea preliminar 0.8 a Unified (Metoda Unificat - aa cum era numit atunci) a
fost publicat n octombrie 1995. Tot atunci, Jacobson s-a alturat echipei de la Rational i
scopul UML a fost extins pentru a include i OOSE. n iunie 1996 a fost publicat versiunea 0.9
a UML. Pe parcursul anului 1996, ca o consecin a reaciilor comunitii proiectanilor de
sistem, a devenit clar ca UML este vzut de ctre multe companii ca o opiune strategic pentru
dezvoltarea produselor lor.
A fost creat un consoriu UML format din organizaii doritoare s aloce resurse pentru a
obine o definiie final a UML. Dintre aceste companii care au contribuit la crearea UML 1.0 au
fcut parte DEC, Hewlet-Packard, I-Logix, Intellicorp, IBM, MCI Systemhouse, Microsoft,
Oracle, Rational, Texas Instruments etc.
UML 1.0 a fost propus spre standardizare n cadrul OMG n ianuarie 1997.
Pn la sfritul anului 1997 echipa care lucra la UML s-a extins, urmnd o perioad n
care UML a primit o specificare formal mai riguroas. Versiunea UML 1.1 a fost adoptat ca
standard de ctre OMG n noiembrie 1997.
Versiunea 1.2 a UML a fost o revizie editorial; versiunile 1.3 au fost publicate ncepnd
cu sfritul anului 1998.
n septembrie 2001 a fost publicat versiunea 1.4 i n martie 2003 a fost versiunea 1.5.
n octombrie 2004 a fost introdus versiunea 2.0.
UML este un limbaj de modelare bazat pe notaii grafice folosit pentru a specifica,
vizualiza, construi i documenta componentele unui program.
UML este un limbaj cu ajutorul cruia se pot construi (descrie) modele. Un model
surprinde un anumit aspect al unui program i acelai model poate fi descris la diferite nivele de
abstractizare. Fiecrui model i corespunde o diagram. Tipurile de diagrame existente n UML
sunt:
Diagrama cazurilor de utilizare (Use Case Diagram)
Diagrama de clase (Class Diagram)
Diagrame care descriu comportamentul:

Diagrame de interaciuni (Interactions Diagrams)

- Diagrama de secven (Sequence Diagram)
- Diagrama de colaborare (Collaboration Diagram)

Diagrama de stri (State chart Diagram)

Diagrama de activiti (Activity Diagram)

Diagrame de implementare:

Diagrama de componente (Component Diagram)

Diagrama de plasare (Deployment Diagram)

Fiecreia din cele trei mari faze din dezvoltarea un proiect software i corespund una sau
mai multe diagrame UML i anume:
-

pentru faza de analiza se utilizeaz diagrama cazurilor de utilizare i diagrama de

activiti;

n faza de proiectare se folosesc: diagrama de clase pentru precizarea structurii

sistemului i diagramele de stri i interaciune pentru descrierea comportamentului
acestuia;

n faza de implementare se utilizeaz diagramele de implementare.

1. Diagrama cazurilor de utilizare (Use Case Diagram)

O diagram use case este una din diagramele folosite n UML pentru a modela aspectele
dinamice ale unui program alturi de diagrama de activiti, diagrama de stri, diagrama de
secven i diagrama de colaborare. Altfel spus, diagramele use case se utilizeaz pentru:
pentru a modela contextul unui sistem: determinarea granielor sistemului i a
actorilor cu care acesta interacioneaz.
pentru a modela cerinele unui sistem: ce trebuie s fac sistemul (dintr-un punct de
vedere exterior sistemului) independent de cum trebuie s fac. Va rezulta specificarea
comportamentului dorit. Sistemul apare ca o cutie neagr. Ceea ce se vede este cum
reacioneaz el la aciunile din exterior.
Elementele componente ale unei diagrame use case sunt:
- use case-uri;
- actori;
- relaiile care se stabilesc ntre use case-uri, ntre actori i ntre use case-uri i actori.
Use case-uri
Un use case (caz de utilizare) reprezint cerine ale utilizatorilor. Este o descriere a unei
mulimi de secvene de aciuni (incluznd variante) pe care un program le execut atunci cnd
interacioneaz cu entitile din afara lui (actori) i care conduc la obinerea unui rezultat
observabil i de folos actorului. Un use case descrie ce face un program sau subprogram, dar nu
precizeaz nimic despre cum este realizat (implementat) o anumit funcionalitate.
Fiecare use case are un nume prin care se deosebete de celelalte use case-uri. Acesta
poate fi un ir arbitrar de caractere, ns de regul numele sunt scurte fraze verbale care
denumesc un comportament ce exist n vocabularul sistemului ce trebuie modelat.
Figura 1.1 prezint notaia grafic pentru use case.