seminar 4sinf.ase.ro/seminarii/psi/seminar 4 - diagrama claselor.pdfµ ]v 3 camere sau perioada de...
TRANSCRIPT
Diagrama claselor UML
Seminar 4 Realizarea sistemelor informatice
pentru management
Definirea unei clase A sa lu de o ie te are au a eleaşi ara teristi i şi o trâ geri. Cara teristi ile u ei lase su t atri utele şi operaţiile. Clasele abstracte u pot fi i sta ţiate. Rolul lor este de a per ite altor
lase să le oşte eas ă, î vederea reutilizării ara teristi ilor. O i terfaţă des rie u set de ara teristi i şi o ligaţii pu li e. “pe ifi ă,
de fapt, u o tra t. Ori e i sta ţă are i ple e tează i terfaţa tre uie să ofere servi iile fur izate pri o tra t.
Exemple de clase stereotipe uzuale
entitate (<<entity>>) – o lasă pasivă, are u i iţiază i tera ţiu i;
control (<<control>>) – i iţiază i tera ţiu i, o ţi e o o po e tă tra za ţio ală şi este separator î tre e tităţi şi
limite; li ită << ou dar >> – este aflată la periferia siste ului, dar
î i teriorul său. Reprezi tă limita de legătură u a torul sau cu alte sisteme informatice;
enumerare (<<enumeration>>) - este folosită pe tru defi irea tipurilor de date ale ăror valori su t e u erate.
pri itivă <<pri itive>> - o for ă de lasă are reprezi tă tipuri de date predefinite, cum ar fi tipul Boolean.
Atribute -1
Fie are atri ut este des ris el puţi pri u ele său. “e pot adăuga şi i for aţii adiţio ale, iar for a ge erală a
unui atribut este:
[vizibilitate][/]nume[:tip][multiplicitate][=valoare i pli ită] [{proprietate}]
Vizibilitatea poate fi:
+ public: poate fi văzută şi folosită de oricine
- private: numai clasa î săşi poate avea acces
# protected: au acces clasa şi subclasele acesteia
~ package: numai clasele din a elaşi pachet pot avea acces
/ si olizează un atribut derivat
Atribute -2
UML permite specificare multiplicităţilor pe tru atri ute, atu i ând dorim să defi i ai ult de o valoare pe tru u atri ut. Au ur ătoarea se ifi aţie:
Multiplicitate Sens
1 Exact 1 (implicit)
2 Exact 2
1..4 De la 1 la 4 (inclusiv)
3, 5 3 sau 5
1..* Cel puţin unul sau mai mulţi * Nelimitat (inclusive 0)
0..1 0 sau 1
Proprietate i di ă o proprietate supli e tară care se apli ă atributului:
{readonly}: atributul poate fi citit, dar nu modificat
{ordered}, {unordered}: o ulţi e ordo ată sau eordo ată
{unique}, {nonunique}: ulţi ea poate o ţi e sau nu elemente identice
Operaţii For a ge erală a u ei operaţii este: [vizibilitate] nume ([direcţie] lista parametri) [:tip returnat] [{proprietate}]
Vizibilitatea – a eeaşi a şi la lase
Dire ţie - 'in' | 'out' | 'inout' | 'return'
Tip returnat – da ă operaţia retur ează eva, adi ă este o fu ţie U e e plu de proprietate a u ei operaţii: {query} - nu are efecte secundare,
u s hi ă starea u ui o ie t sau a altor o ie te, e e plu operaţiile de tip get .
Exemple de atribute:
• - varsta: Integer {varsta>18}
• # nume:String[ .. ]= Ioa a
• ~ Id:String {unique}
• / sumaTotala:Real=0
E e ple de operaţii: • + setVarsta (out varsta: Integer)
• + getVarsta(in Id:String): Integer {query}
• - schimbaNume(inout nume:String)
Constrângeri
O o strâ gere este o e presie are restri ţio ează u a u it ele e t al diagramei de clase.
A easta poate fi o e presie for ală s risă î O je t Co strai t La guage - OCL) sau o formulare semi-for ală sau i for ală.
Acestea sunt reprezentate între acolade.
Pot fi s rise i ediat după defi irea ele e tului sau a u o e tariu. O o strâ gere poate avea şi u u e, astfel: {nume : expresie booleană }
Exemple de constrângeri OCL: context Organizatie inv: self. departamenteisUnique (nume) inv: departamante.angajatiisUnique (cod)
Relaţii î tre lase -1
1. Relaţia de asociere i pli ă sta ilirea u ei relaţii î tre lase. Este ara terizată pri :
de u ire opţio ală
ultipli ităţi – se trec la cele 2 capete ale asocierii;
roluri ale aso ierii: se tre la fie are apăt al aso ierii şi o ţi o des riere s urtă şi repreze tativă de – 2 substantive)
dire ţie de avigare
tipuri de asocieri:
unare
binare
ternare
Relaţii î tre lase -2 Tipuri de asocieri:
U are: o e tează o lasă u si e î săşi.
Bi are: se realizează î tre două lase.
Ternare: sunt transformate, de obicei, în asocieri binare.
Relaţii între clase -3
Aso ierea odelată a o lasă per ite relaţiei de aso iere să ai ă arti ute şi operaţii.
2. Relaţia de agregare este o for ă de aso iere i ară repreze tâ d o relaţie de tip parte/întreg.
• Poate fi de doua tipuri:
• Agregare partajată agregare
• Agregare o pusă o pu ere
Relaţii î tre lase -4
Agregarea partajată este o for ă sla ă de agregare î are i sta ţele părţilor su t i depe de te de î treg, astfel: A eleaşi părţi partajate pot fi i luse î ai ulte lase î treg. Da ă lasa î treg se şterge, lasele parte vor e ista î
continuare.
“e reprezi tă su for a u ui ro gol plasat la apătul lasei întreg.
Relaţii î tre lase -5
Agregarea co pusă este o for ă puter i ă de agregare î are i sta ţele părţilor su t i depe de te de î treg, astfel: Da ă lasa î treg se şterge, lasele parte vor vor fi şterse şi ele. “e reprezi tă su for a u ui ro pli plasat la apătul lasei
întreg.
Atu i â d se foloseşte pe tru odelarea o ie telor di tr-un a u it do e iu, ştergerea poate fi i terpretată la figurativ, a terminare , şi u a o distrugere fizi ă.
Relaţii î tre lase -6 Asociere Obiectele ştiu unele de existaţa celorlalte şi pot lucra împreună.
Agregare 1. Protejează integritatea configuraţiei. 2. Funcţionează ca un tot unitar. 3. Control prin intermediul unui singur obiect.
Compunere Fiecare parte poate fi membră a unui singur obiect agregat.
Relaţii î tre aso iere, agregare şi o pu ere
Relaţii î tre lase -7 . Relaţia de ge eralizare este folosită pe tru a i di a oşte irea
di tre o lasă ge erală super lasă şi o lasă spe ifi ă su lasă . • “e ai u eşte i for al şi relaţie de ge ul este un tip de . • “e reprezi tă su for a u ui tri ghi gol plasat la apătul
superclasei. • “u lasele oşte es ara teristi ile şi o strâ gerile super lasei. • Este per isă oşte irea ultiplă.
Relaţii î tre lase -8
. Relaţia de depe de ţă este folosită pe tru a arăta o ga ă largă de depe de ţe î tre ele e tele u ui odel.
• Î atapa de a aliză, tipul de depe de ţă poate să u fie spe ifi at.
• Î proie tare, depe de ţele vor fi perso alizate u stereotipuri sau vor fi înlocuite cu conectori specifici tehnologiei folosite.
• “e reprezi tă su for a u ei li ii pu tate de la lasa depe de tă client, pa ă la lasa furnizor , u o săgeată la apătul lasei furnizor .
• Î diagra ele de lase, ele ai i porta te depe de ţe su t relaţiile de utilizare şi de abstractizare.
Relaţii î tre lase -9 • Depe de ţa de utilizare (<<use>>, <<create>>, <<call>> etc.) este o relaţie î are
lasa lie t are evoie de altă lasă sau set de lase fur izor pe tru a fu ţio a.
• Dependenţa de a stra tizare pu e î relaţie două ele e te sau seturi de ele e te u ite lie t şi fur izor , repreze tâ d a elaţi o ept, dar la iveluri diferite de
abstractizare sau din puncte de vedere diferite.
• Relaţia de realizare este o for ă de a stra tizare, î are u ele e t de odelare fur izorul reprezi tă spe ifi aţia, iar elălat ele e t lie tul
reprezi tă i ple e tarea spe ifi aţiei. “e reprezi tă su for a u ei li ii pu tate u o săgeată la apătul lasei fur izor.
Diagrama de clase UML
Ce este şi u se reprezi tă ultipli itatea?
De u iţi do e iile de vizi ilitate î UML.
Care este rolul oşte irii şi u se ide tifi ă?
Clasele a stra te pot fi i sta ţiate?
De ce sunt importante numele de rol?
Care este difere ţa di tre agregare şi o pu ere?
Lucru la seminar
Să se î toc ească diagra a de clase pentru scenariul de mai jos.
Scopul proiectului este realizarea apli aţiei informatice pentru gestiunea a tivităţii unei u ităţi hoteliere. În vederea azării, un client poate solicita rezervarea uneia sau mai multor camere prin e-mail sau telefonic. Pentru aceasta fur izează re epţio erului i for aţii privind perioada de cazare şi tipurile de camere solicitate. Clie ţii vor beneficia de reduceri da ă rezervă cel puţi 3 camere sau da ă perioada de cazare depăşeşte 5 zile. Re epţio erul verifi ă disponibilitatea camerelor şi îl î ştii ţează pe client de acest lucru precum şi de costul estimat al azării. Da ă nu e istă camere disponibile conform soli itării, re epţio erul poate oferi clientului alternative. De asemenea, clientul poate solicita un discount (suplimentar sau nu), iar re epţio erul va decide fezabilitatea discountului, fiind asistat obligatoriu de managerul hotelului. În situaţia în care clientul este de acord cu preţul propus, se va proceda la realizarea rezervării. Pentru lie ţii noi, re epţio erul soli ită datele de identificare, pe care le introduce în apli aţie.
Odată ajuns la hotel, şi da ă a fă ut în prealabil o rezervare, clientul va furniza datele de identificare ale sale şi/sau ale rezervării şi se face cazarea. Da ă nu e istă o rezervare, se va verifica disponibilitatea camerelor pentru perioada erută. Atunci când se găseşte o astfel de a eră, se face cazarea. La finalul sejurului, re epţio erul î to eşte o listă cu toate serviciile
solicitate de client şi preţul acestora. Lista trebuie validată de client, după care se î to eşte factura fi ală. Factura poate fi plătită parţial sau integral, prin transfer bancar, numerar sau folosind un card bancar. Totodată, înainte de a părăsi hotelul, clientul este rugat să completeze un formular prin care să evalueze serviciile oferite de unitatea hotelieră.