Sunteți pe pagina 1din 12

Introducere in UML

Introducere n UML
1. Aparitie si evolutie
UML este un limbaj vizual de modelare, el nu este nc un limbaj vizual de programare,
deoarece nu dispune de ntreg sprijinul semantic i vizual pentru a nlocui limbajele de
programare. Limbajul este destinat vizualizrii, specificrii, construirii i documentrii
sistemelor de aplicaii, dar are limitri n ceea ce privete generarea codului. UML reunete
cele mai bune tehnici i practici din domeniul ingineriei programrii, care i-au dovedit
eficiena n construirea sistemelor complexe.
Cteva date semnificative referitoare la apariie i evoluie:
n octombrie 1994, Grady Booch lider stiinific la Rational Corporation, autor
al metodei ce-i poart numele i a unor cri de referint n domeniu face echip
cu James Rumbaugh, autorul principal al metodei OMT, pe care-l determin s-si
prseasc (cel puin temporar) vechiul loc de munc (General Electric) i s
treac la firma Rational. Dup un an de activitate Booch i Rumbaugh, prezint n
octombrie 1995 cu ocazia conferinei OOPSLA, caracteristicile de baz ale unei
noi metode de analiz i proiectare, rezultat prin unificarea Metodei lui Booch
(OOD) cu OMT, metod denumit Metoda unificat (Unified Method). Prima
documentaie a metodei menionat anterior a fost fcut public n decembrie
1995, avnd numrul de versiune 0.8. La sfrsitul aceluiai an celor doi li se
alatur i Ivar Jacobson.
In iunie 1996 apare versiunea 0.9, urmat la scurt timp, octombrie 1996, de
apariia versiunii 0.91. Versiunea 0.9 aduce i schimbarea denumirii din Metoda
unificat (Unified Method) n Limbajul unificat de modelare (Unified Modeling
Language). Cooptarea lui Jacobson n echip se concretizeaz printre altele n
detalierea conceptului de cazuri de utilizare (use case) i prezentarea unei descrieri
mai amnunite pentru diagramele cazurilor de utilizare. Conceptul de stereotip
este mai bine explicitat, se modific denumirile unor diagrame.

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com

Introducere in UML

La 11 ianuarie 1997 este prezentat versiunea 1.0 care, nsoit de o


documentaie mult mai detaliat dect versiunile precedente, este trimis ctre
OMG pentru standardizare.
1 septembrie 1997, a reprezentat un alt moment deosebit de important.
Rational i alte firme care spijina UML, printre care i doi fosti competitori,
IBM/ObjectTime i Taskon/Reich, a propus OMG o nou versiune 1.1. Noutatea
semnificativ pentru aceast versiune o reprezint introducerea limbajului OCL,
un limbaj folosit pentru descrierea regulilor de corectitudine ale metamodelului
UML.
La 17 noiembrie 1997, OMG a anuntat adoptarea specificaiei UML ca limbaj
standard de modelare

Schimbarea denumirii din Metoda Unificat n Limbaj de Modelare Unificat a fost


justificat prin:

reaciile primite din partea utilizatorilor care au sugerat c este mult mai

important s se acorde o atenie sporit conceptelor utilizate n dezvoltarea


aplicaiilor. Recomandrile referitoare la desfurarea etapelor de realizare i
nlntuirea lor au fost lsate n planul secund,

faptul c eforturile de unificare au fost concentrate asupra limbajului grafic de

modelare, asupra semanticii lui i abia dup aceea asupra modului de utilizare a
conceptelor,

UML a fost conceput ca un limbaj universal care s fie utilizat la modelarea

sistemelor (indiferent de tipul i scopul pentru care au fost construite), la fel cum
limbajele de programare sunt folosite n diverse domenii.

Sublinierea aspectelor de limbaj nu semnific nicidecum ignorarea modului de folosire


a lor. UML presupune c metodologia este ghidat de cazurile de utilizare, c ea se bazeaz
pe arhitectura sistemului, iar procesul de aplicare a metodologiei este iterativ i incremental.
Detaliile acestui proces trebuie adaptate la domeniul aplicaiei, la modul de organizare al

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com

Introducere in UML

echipei de realizatori, la experiena echipei. UML nu trateaz aspecte de metodologie,


permitnd astfel separarea limbajului de modelare de procesul aplicrii metodologiei.

2. Principalele pri ale UML


Principalele parti ale UML sunt:

Vederile (View) surprind aspecte particulare ale sistemului de modelat. Un

view este o abstractizare a sistemului, iar pentru construirea lui se folosesc un numr
de diagrame.

Diagramele sunt grafuri care descriu coninutul unui view. UML are nou

tipuri de diagrame, care pot fi combinate pentru a forma toate view-urile sistemului.

Elementele de modelare sunt conceptele folosite n diagrame care au

coresponden n programarea orientat-obiect, cum ar fi: clase, obiecte, mesaje i


relaii ntre acestea: asocierea, dependena, generalizarea. Un element de modelare
poate fi folosit n mai multe diagrame diferite i va avea acelai nteles i acelai mod
de reprezentare.

Mecanismele generale permit introducerea de comentarii i alte informaii

despre un anumit element.


2.1 View-uri
Modelarea unui sistem poate fi o munc foarte dificil. Ideal ar fi ca pentru descrierea
sistemului s se foloseasc un singur graf, ns de cele mai multe ori acesta nu poate s
surprind toate informaiile necesare descrierii sistemului. Un sistem poate fi descris lund n
considerare diferite aspecte:

Funcional: este descris structura static i comportamentul dinamic al

sistemului;

Non-funcional: necesarul de timp pentru dezvoltarea sistemului

Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de

cod;

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com

Introducere in UML

Aadar pentru descrierea unui sistem sunt necesare un numr de view-uri, fiecare
reprezentnd o proiecie a descrierii intregului sistem i care reflect un anumuit aspect al sau.
Fiecare view este descris folosind un numr de diagrame care conin informaii relative
la un anumit aspect particular al sistemului. Aceste view-uri se acoper unele pe altele, deci
este posibil ca o anumit diagram s fac parte din mai multe view-uri.

View-ul
Componentelor
nt

View-ul

Logic
View-ul
Cazurilor
de Utilizare

View-ul
de
desfaurare

View-ul
de concuren

Figura 1: View-urile din UML

View-ul cazurilor de utilizare (Use-case View)

Acest view surprinde funcionalitatea sistemului, aa cum este ea perceput de actorii


externi care interacioneaz cu sistemul, de exemplu utilizatorii acestuia sau alte sisteme. n
componena lui intr diagrame ale cazurilor de utilizare i ocazional, diagrame de activitate.
Cei interesai de acest view sunt deopotriv clienii, designerii, dezvoltatorii dar i cei
care vor realiza testarea i validarea sistemului.

View-ul logic (Logic View)

Spre deosebire de view-ul cazurilor de utilizare, un view logic privete nuntrul


sistemului i descrie att structura intern a acestuia (clase, obiecte i relaii) ct i
colaborrile care apar cnd obiectele trimit unul altuia mesaje pentru a realiza funcionalitatea
dorit.
Structura static este descris n diagrame de clas, n timp ce pentru modelarea
dinamicii sistemului se vor folosi diagramele de stare, de secvent, de colaborare sau de
activitate. Prin urmare, cei care sunt interesai de acest tip de vizualizare a sistemului sunt
designerii i dezvoltatorii.

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com

Introducere in UML

View-ul componentelor (Component View)

Componentele sunt module de cod de diferite tipuri. n funcie de coninutul lor acestea
pot fi: componente care conin cod surs, componente binare sau excutabile.
View-ul componentelor are rolul de a descrie componentele implementate de sistem i
dependenele ce exist ntre ele, precum i resursele alocate acestora i eventual alte
informaii administrative, cum ar fi de exemplu un desfaurtor al muncii de dezvoltare. Este
folosit n special de dezvoltatorii sistemului, iar n componena sa intr diagrame ale
componentelor.
View-ul de concuren (Concurent View)

Sistemul poate fi construit astfel nct s ruleze pe mai multe procesoare. Acest aspect,
care este unul nonfuncional, este util pentru o gestionare eficient a resurselor, execuii
paralele i tratri asincrone ale unor evenimente din sistem, precum i pentru rezolvarea unor
probleme legate de comunicarea i sincronizarea theadu-urilor.
Cei care sunt interesai de o astfel de vizualizare a sistemului sunt dezvoltatorii i
integratorii de sistem, iar pentru construirea lui se folosesc diagrame dinamice (stare,
secvent, colaborare i activitate) i diagrame de implementare (ale componentelor sau de
desfurare).
View-ul de desfsurare (Deployment View)

Desfurarea fizic a sistemului, ce calculatoare i ce device-uri (numite i noduri) vor


fi folosite pentru realizarea efectiv a implementrii, cum sunt acestea conectate, precum i ce
componente se vor executa pe fiecare nod (de exemplu ce program sau obiect este executat pe
fiecare calculator), toate sunt surprinse n view-ul de desfurare.
Aceast tip de vizualizare a sistemului prezint interes sunt dezvoltatori, integratorii de
sistem i cei care realizeaz testarea sistemului, iar pentru construirea view-ului este folosit
diagrama de desfurare.

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com

Introducere in UML

2.2 Diagrame
Diagramele sunt grafuri care prezint simboluri ale elementelor de modelare (model
element) aranjate astfel nct s ilustreze o anumit parte sau un anumit aspect al sistemului.
Un model are de obicei mai multe diagrame de acelai tip. O diagram este o parte a unui
view specific, dar exist posibilitatea ca o diagram s fac parte din mai multe view-uri, n
funcie de coninutul ei. n UML sunt nou tipuri de diagrame pe care le vom prezenta n cele
ce urmeaz.

Diagrama cazurilor de utilizare (Use Case Diagram)

Un caz de utilizare este o descriere a unei funcionaliti (o utilizare specific a


sistemului) pe care o ofer sistemul. Diagrama prezint actorii externi i cazurile de utilizare
identificate, numai din punctul de vedere al actorilor (care este comportamentul sistemului,
aa cum este el perceput de utilizatorii lui?) nu i din interior, precum i conexiunile
identificate ntre actori i cazurile de utilizare. Un exemplu de diagram a cazurilor de
utilizare este prezentat n figura 2.

Semnarea unei
polie de asigurare
Client
Situaia
vnzrilor

Societate
de asigurri

Situaia
clienilor

Figura 2: O diagram a cazurilor de utilizare dintr-un sistem de asigurri.

Diagrama claselor (Class Diagram)


O diagram a claselor prezint structura fizic a claselor identificate n sistem. Clasele
reprezint lucruri gestionate de sistem; clasele pot fi legate n mai multe moduri: asociate

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com

Introducere in UML

(conectate ntre ele), dependente (o clasa depinde/folosete o alt clas), specializate (o clas
este specializarea altei clase) sau mpachetate (grupate mpreun n cadrul unei unitai). Toate
aceste relaii se materializeaz n structura intern a claselor n atribute i operaii.
Diagrama este considerat static, n sensul c este valid n orice moment din ciclul de
via al sistemului. Un exemplu de diagram a claselor este prezentat n figura 3.

Polia de
asigurare
0..1
expim

este expimat prin

1
Companie
de asigurri

are

0..*

Contract de
asigurare

apartine

0..*
refera

are

1..*
Persoana

Figura 3: O diagram a claselor pentru un sistem de asigurri.

Diagrama obiectelor (Object Diagram)

Acest tip de diagram este un variant al diagramei claselor care n locul unei clase
prezint mai multe instane ale ei. Diagrama obiectelor folosete aproape aceleai notaii ca i
diagrama claselor cu dou mici diferene: obiectele sunt scrise subliniat i sunt vizualizate
toate instantele relaiei (vezi figura 4).
Dei nu este la fel de important ca diagrama claselor, cea o obiectelor este folosit
pentru exemplificarea unei diagrame a claselor de complexitate mare, permind vizualizari
ale instanelor actuale i a relaiilor exact aa cum sunt ele realizate. Mai poate fi folosit ca o
parte a diagramelor de colaborare, n care sunt vizualizate colaborrile dinamice existente n
cadrul unui set de obiecte.

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com

Introducere in UML

Calculator

Angajat

foloseste

nume:String
virsta:Integer

0..1

Diagrama claselor

nume:String
1..*

memorie:Integer

PC Servici:Calculator
nume=Dell 466

Popescu:Angajat

memorie=64

Diagrama obiectelor

nume=Popescu Ion
virsta=30

PC Acasa:Calculator

nume=Compaq
Pentium MMX
Figura 4: O diagram a claselor i o diagram a obiectelor (instanele claselor).
Diagrama de stare (State Diagram)
O stare este de obicei un complement al descrierii unei clase. O diagram de stare
prezint toate strile prin care trece un obiect al clasei precum i evenimentele care-i cauzeaz
modificrile de stare. Modificarea strii se numete tranziie. Un exemplu de diagram de
stare este prezentat n figura 5.
La parter

urca (etaj)

Mut sus
do/ schimb nivelul

soseste la parter
urc (etaj)

M
ut

soseste

la
Mut jos

soseste

Staioneaz
timp=0
do/crete timp

do/ schimba nivelul

Time-out

Figura 5: O diagram de stare pentru un ascensor

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com

Introducere in UML

Nu vom construi diagrame de stare pentru toate clasele din sistem ci numai pentru
acelea care au un numr de stri bine definit iar comportamentul clasei este afectat i
modificat de acestea.

Diagrama de secven (Sequence Diagram)

O diagram de secven prezint colaborarea dinamic ntre un numr de obiecte (vezi


figura 6), mai precis secvenele de mesaje trimise ntre acestea pe msura scurgerii timpului.
Obiectele sunt vzute ca linii verticale distribuite pe orizontal, iar timpul este
reprezentat pe axa vertical de sus n jos. Mesajele sunt reprezentate prin sgei ntre linile
verticale ce corespund obiectelor implicate n mesaj.
:Calculator

:Server de imprimanta

Print (fisier)

:Imprimanta

:Coada

[imprimanta liber]
Print (fiier)
[imprimanta ocupat]
Stocheaz (fiier)

Figura 6: Diagrama de secven pentru un server de imprimant

Diagrama de colaborare (Collaboration Diagram)

Aceast diagram surprinde colaborarea dinamic ntre obiecte, ntr-o manier similar
cu a diagramei de secven, dar pe lng schimbul de mesaje (numit i interaciune) prezint
obiectele i relaiile dintre ele (cteodat referite ca i context).

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com

Introducere in UML

10

Cum decidem ce tip de diagram s folosim? Dac cel mai important aspect este timpul
sau secvena de mesaje vom folosi diagrama de secven, dar dac trebuie scos n evident
contextul, vom apela la o diagram de colaborare.
Desenarea unei diagrame de colaborare se face similar cu a unei diagrame a obiectelor.
Mesajele vor fi reprezentate prin sgei ntre obiectele implicate n mesaj i pot fi nsoite de
etichete care specific ordinea n care acestea vor fi transmise. De asemenea se pot vizualiza
condiii, iteraii, valori returnate, precum i obiectele active care se execut concurent cu alte
obiecte active (vezi figura 7).

:Calculator

[imprimanta ocupat]
1.2: Stocheaz(fiier)

:Coada de ateptare

1: Print (fisier)

[imprimanta liber]
1.1: Print(fiier)

:ServerImprimant

:Imprimanta

Figura 7: O diagram de colaborare pentru un server de imprimant.


Diagrama de activitate (Activity Diagram)

O diagram de activitate prezint fluxul secvenelor de activitai, ca n figura 8, i este


de obicei folosit pentru a descrie activitaile realizate n cadrul unei operaii, folosind dac
este cazul decizii i condiii.
Diagrama conine stri de aciune (action states), i mesaje care vor fi trimise sau
recepionate ca parte a aciunii realizate.

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com

Introducere in UML

11

FereastraClient.AfiseazaTotiClientii()

[disc full]

Afieaz mesajul
Disc Full
pe ecran

[spaiu liber pe disc]

Afieaza mesajul
Printing
pe ecran

Afieaz pe ecran
fereastra de mesaj
Printing

terge
fereastra de
mesaj

^Printer.Print(fisier)

Creaza
fiierul
postscript

Figura 8: O diagram de activitate pentru un server de imprimant.


Diagrama componentelor (Component Diagram)

O diagram a componentelor prezint structura fizic a codului n termenii


componentelor de cod, realiznd o mapare de la view-ul logic la view-ul componentelor. O
component poate s conin un cod surs sau poate s fie ntr-o forma binar sau executabil.
n cadrul diagramei vor fi ilustrate i dependenele dintre componente, ceea ce permite o
vizualizare simpl a componentelor care vor fi afectate de modificarea uneia dintre ele.
Window
Hander
(whnd.cpp)

Window
Hander

Graphic
Lib

(whnd.obj)

(graphic.dll)

Command
Hander
(comhnd.cpp)

Command
Hander
(comhnd.obj)

Main
Class
(main.cpp)

Main
Class
(main.obj)

Figura 8: O diagram a componentelor

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com

Program
Client
(client.exe)

Introducere in UML

12

Diagrama de desfurare (Deployment View)

Arhitectura fizic pe care va fi implementat sistemul, calculatoarele, device-urile


(referite ca nodurile sistemului), mpreun cu conexiunile dintre ele, vor putea fi prezentate n
cadrul unei diagrame de desfaurare. Componentele i obiectele executabile sunt alocate n
interiorul nodurilor, ceea ce ne va permite o vizualizare a unitailor care se vor executa pe
fiecare nod.

Client A:
Compaq
Pro PC

<<TCP/IP>>

<<TCP/IP>>

Application
Server:
Silicon
Graphics O2

<<Net 8>>

Database
Server:
Oracle

Client B:
Compaq
Pro PC

Figura 9: O diagram de desfaurare care prezint structura fizic a sistemului.

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com