Seminar 4

Realizarea sistemelor informatice

pentru management

Diagrama claselor UML

Definirea unei clase

Ansamblu de obiecte care au aceleai caracteristici i contrngeri.
Caracteristicile unei clase sunt atributele i operaiile.
Clasele abstracte nu pot fi instaniate. Rolul lor este de a permite altor

clase s le moteneasc, n vederea reutilizrii caracteristicilor.

O interfa descrie un set de caracteristici i obligaii publice. Specific,
de fapt, un contract. Orice instan care implementeaz interfaa
trebuie s ofere serviciile furnizate prin contract.

Exemple de clase stereotipe uzuale

entitate (<<entity>>) o clas pasiv, care nu iniiaz

interaciuni;
control (<<control>>) iniiaz interaciuni, conine o
component tranzacional i este separator ntre entiti i
limite;
limit (<<boundary>>) este aflat la periferia sistemului, dar
n interiorul su. Reprezint limita de legtur cu actorul sau
cu alte sisteme informatice;
enumerare (<<enumeration>>) - este folosit pentru definirea
tipurilor de date ale cror valori sunt enumerate.
primitiv (<<primitive>>) - o form de clas care reprezint
tipuri de date predefinite, cum ar fi tipul Boolean.

Atribute -1
Fiecare atribut este descris cel puin prin numele su.

Se pot aduga i informaii adiionale, iar forma general a

unui atribut este:

[vizibilitate][/]nume[:tip][multiplicitate][=valoare implicit] [{proprietate}]
Vizibilitatea poate fi:
+ public: poate fi vzut i folosit de oricine
- private: numai clasa nsi poate avea acces
# protected: au acces clasa i subclasele acesteia

~ package: numai clasele din acelai pachet pot avea acces

/ simbolizeaz un atribut derivat

Atribute -2
UML permite specificare multiplicitilor pentru atribute, atunci cnd dorim s

definim mai mult de o valoare pentru un atribut. Au urmtoarea semnificaie:

Multiplicitate
1
2
1..4
3, 5
1..*
*
0..1

Sens
Exact 1 (implicit)
Exact 2
De la 1 la 4 (inclusiv)
3 sau 5
Cel puin unul sau mai muli
Nelimitat (inclusive 0)
0 sau 1

Proprietate indic o proprietate suplimentar care se aplic atributului:

{readonly}: atributul poate fi citit, dar nu modificat
{ordered}, {unordered}: o mulime ordonat sau neordonat
{unique}, {nonunique}: mulimea poate conine sau nu elemente identice

Operaii
Forma general a unei operaii este:
[vizibilitate] nume ([direcie] lista parametri) [:tip returnat] [{proprietate}]
Vizibilitatea aceeai ca i la clase
Direcie - 'in' | 'out' | 'inout' | 'return'
Tip returnat dac operaia returneaz ceva, adic este o funcie
Un exemplu de proprietate a unei operaii: {query} - nu are efecte secundare,

nu schimb starea unui obiect sau a altor obiecte, exemplu operaiile de tip
get.

Exemple de atribute:

Exemple de operaii:

- varsta: Integer {varsta>18}

+ setVarsta (out varsta: Integer)

# nume:String*1..2+=Ioana

+ getVarsta(in Id:String): Integer {query}

~ Id:String {unique}

- schimbaNume(inout nume:String)

/ sumaTotala:Real=0

Constrngeri
O constrngere este o expresie care restricioneaz un anumit element al

diagramei de clase.
Aceasta poate fi o expresie formal (scris n Object Constraint Language
- OCL) sau o formulare semi-formal sau informal.
Acestea sunt reprezentate ntre acolade.
Pot fi scrise imediat dup definirea elementului sau ca un comentariu.
O constrngere poate avea i un nume, astfel:
{nume : expresie boolean }

Exemple de constrngeri OCL:

context Organizatie
inv: self. departamenteisUnique (nume)
inv: departamante.angajatiisUnique (cod)

Relaii ntre clase -1

1. Relaia de asociere implic stabilirea unei relaii ntre clase.
Este caracterizat prin:
denumire (opional)
multipliciti se trec la cele 2 capete ale asocierii;
roluri ale asocierii: se trec la fiecare capt al asocierii i conin o

descriere scurt i reprezentativ de (1 2 substantive)

direcie de navigare
tipuri de asocieri:
unare
binare
ternare

Relaii ntre clase -2

Tipuri de asocieri:
Unare: conecteaz o clas cu sine nsi.

Binare: se realizeaz ntre dou clase.

Ternare: sunt transformate, de obicei, n asocieri binare.

Relaii ntre clase -3

Asocierea modelat ca o clas permite relaiei de asociere s

aib artibute i operaii.

2. Relaia de agregare este o form de asociere binar

reprezentnd o relaie de tip parte/ntreg.
Poate fi de doua tipuri:
Agregare partajat (agregare)
Agregare compus (compunere)

Relaii ntre clase -4

Agregarea partajat este o form slab de agregare n care

instanele prilor sunt independente de ntreg, astfel:

Aceleai pri partajate pot fi incluse n mai multe clase ntreg.
Dac clasa ntreg se terge, clasele parte vor exista n
continuare.
Se reprezint sub forma unui romb gol plasat la captul clasei
ntreg.

Relaii ntre clase -5

Agregarea compus este o form puternic de agregare n care

instanele prilor sunt independente de ntreg, astfel:

Dac clasa ntreg se terge, clasele parte vor vor fi terse i ele.
Se reprezint sub forma unui romb plin plasat la captul clasei
ntreg.
Atunci cnd se folosete pentru modelarea obiectelor dintr-un
anumit domeniu, tergerea poate fi interpretat la figurativ, ca
terminare, i nu ca o distrugere fizic.

Relaii ntre clase -6

Asociere
Obiectele tiu unele de existaa celorlalte i pot lucra mpreun.
Agregare
1. Protejeaz integritatea configuraiei.
2. Funcioneaz ca un tot unitar.
3. Control prin intermediul unui singur obiect.
Compunere
Fiecare parte poate fi membr a unui singur obiect agregat.

Relaii ntre asociere, agregare i compunere

Relaii ntre clase -7

3. Relaia de generalizare este folosit pentru a indica motenirea
dintre o clas general (superclas) i o clas specific (subclas).
Se mai numete informal i relaie de genul este un tip de.
Se reprezint sub forma unui tringhi gol plasat la captul
superclasei.
Subclasele motenesc caracteristicile i constrngerile superclasei.
Este permis motenirea multipl.

Relaii ntre clase -8

4. Relaia de dependen este folosit pentru a arta o gam larg de
dependene ntre elementele unui model.
n atapa de analiz, tipul de dependen poate s nu fie specificat.
n proiectare, dependenele vor fi personalizate cu stereotipuri sau vor

fi nlocuite cu conectori specifici tehnologiei folosite.

Se reprezint sub forma unei linii punctate de la clasa dependent

client, pan la clasa furnizor, cu o sgeat la captul clasei

furnizor.
n diagramele de clase, cele mai importante dependene sunt relaiile

de utilizare i de abstractizare.

Relaii ntre clase -9

Dependena de utilizare (<<use>>, <<create>>, <<call>> etc.) este o relaie n care

clasa client are nevoie de alt clas sau set de clase (furnizor) pentru a funciona.

Dependena de abstractizare pune n relaie dou elemente sau seturi de elemente

(numite client i furnizor), reprezentnd acelai concept, dar la niveluri diferite de
abstractizare sau din puncte de vedere diferite.

Relaia de realizare este o form de abstractizare, n care un element de

modelare (furnizorul) reprezint specificaia, iar cellat element (clientul)
reprezint implementarea specificaiei. Se reprezint sub forma unei linii
punctate cu o sgeat la captul clasei furnizor.

Diagrama de clase UML

Ce este i cum se reprezint multiplicitatea?

Denumii domeniile de vizibilitate n UML.

Care este rolul motenirii i cum se identific?

Clasele abstracte pot fi instaniate?

De ce sunt importante numele de rol?

Care este diferena dintre agregare i compunere?

Lucru la seminar
S se ntocmeasc diagrama de clase pentru scenariul de mai jos.
Scopul proiectului este realizarea aplicaiei informatice pentru gestiunea activitii unei uniti
hoteliere. n vederea cazrii, un client poate solicita rezervarea uneia sau mai multor camere
prin e-mail sau telefonic. Pentru aceasta furnizeaz recepionerului informaii privind perioada
de cazare i tipurile de camere solicitate. Clienii vor beneficia de reduceri dac rezerv cel
puin 3 camere sau dac perioada de cazare depete 5 zile. Recepionerul verific
disponibilitatea camerelor i l ntiineaz pe client de acest lucru precum i de costul estimat
al cazrii. Dac nu exist camere disponibile conform solicitrii, recepionerul poate oferi
clientului alternative. De asemenea, clientul poate solicita un discount (suplimentar sau nu),
iar recepionerul va decide fezabilitatea discountului, fiind asistat obligatoriu de managerul
hotelului. n situaia n care clientul este de acord cu preul propus, se va proceda la realizarea
rezervrii. Pentru clienii noi, recepionerul solicit datele de identificare, pe care le introduce
n aplicaie.
Odat ajuns la hotel, i dac a fcut n prealabil o rezervare, clientul va furniza datele de
identificare ale sale i/sau ale rezervrii i se face cazarea. Dac nu exist o rezervare, se va
verifica disponibilitatea camerelor pentru perioada cerut. Atunci cnd se gsete o astfel de
camer, se face cazarea. La finalul sejurului, recepionerul ntocmete o list cu toate serviciile
solicitate de client i preul acestora. Lista trebuie validat de client, dup care se ntocmete
factura final. Factura poate fi pltit parial sau integral, prin transfer bancar, numerar sau
folosind un card bancar. Totodat, nainte de a prsi hotelul, clientul este rugat s completeze
un formular prin care s evalueze serviciile oferite de unitatea hotelier.