DISCIPLINA

Analiza si Proiectarea Programelor

TITLUL LUCRARII
Diagrame UML

Formularea problemei

Se cere dezvoltarea unui SGBD (Sistem de Gestiune a Bazelor de Date) care s ajute la gestionarea clientilor unei agentii de turism. Acest SGBD contine 3 tabele in care se regasesc urmatoarele : 1. Tabelul in care se inregistreaza utilizatorii site-ului 2. Tabelul in care se inregistreaza ofertele agentiei 3. Tabelul in care se inregistreaza comenzile utilizatorilor Site-ul va putea servi doar utilizatorii autentificati, dar si oaspeti au anumite drepturi. Pentru a creea un cont vizitatorul va fi rugat sa introduca datele corespunzatoare. Aceste informatii vor fi trimise agentiei de turism in vederea alcatuirii celei mai bune oferte. Dupa logarea pe site clientul va putea vizualiza oferte complete si a face rezervari. Daca agentia va putea satisface nevoile clientului acesta v-a fi informat printr-un email de confirmare. Site-ul trebuie sa asigure urmatoarele informatii : Destinatiile turiste care le ofera ; Informatii concrete despre oferta (destinatei, perioada, pret si o prezentare succinta a destinatiilor turistice) ; Site-ul va contine si o sectiune in care se va updata in fiecare luna cea mai buna oferta ; Site-ul mai contine si imagini cu unitatile de cazare si obiectivele turistice prezente in oferta ; Clientul poate vizualiza in timp real informati depre oferta agentiei ; Clientul in caz de probleme poate sa contacteze reprezentantii agentiei pentru solutionarea acestora ;

Pic1 Pagina de start

Pic2 Pagina de noutati

Pic3 Pagina de oferte

Pic4 Pagina de contact

Pic5 Pagina de inregistrare

Pic6 Pagina de logare

Pic7 Pagina de prezentare

Introducere in UML

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.

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. 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: 1. Funcional: este descris structura static i comportamentul dinamic al sistemului; 2. Non-funcional: necesarul de timp pentru dezvoltarea sistemului Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de cod; 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.

FIG 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.

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.

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. Pe parcursull prezentarii tipurilor de diagrame vom realiza diagrame pentru situatiile descrise in problema noastra:

Diagrama Cazurilor de Utilizare

O diagrama a cazurilor de utilizare (use case diagram) prezinta o colectie de cazuri de utilizare si actori care: ofera o descriere generala a modului in care va fi utilizat sistemul

10

furnizeaza o privire de ansamblu a functionalitatilor ce se doresc a fi oferite de sistem arata cum interactioneaza sistemului cu unul sau mai multi actori asigura faptul ca sistemul va produce ceea ce s-a dorit.

Diagrama de Clasa
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: associate (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. Pentru a crea o diagram de clase, acestea trebuie s fie identificate i descrise. Identificarea claselor se face rspunznd la urmtoarele ntrebri: 11

Avem un tip de informaie care trebuie depozitat sau analizat? Avem sisteme externe nglobate n activitatea sistemului modelat? Exist dispozitive pe care sistemul trebuie s le mnuiasc? Exist biblioteci sau componente din alte proiecte care vor fi folosite n sistem? Actorii folosii (din use-cases) au un rol n sistem astfel nct vor trebui implementai ca fiind clase?

Notaia UML pentru o clas este un dreptunghi mprit n trei pri: numele clasei, atributele i operaiile. Att operaiile ct i atributele pot fi statice (afie subliniat), deci nu vor aparine unei instane a clasei din care provin ci vor aparine chiar clasei, fiecare din instanele ei avnd acces la acestea. Primul compartiment al dreptunghiului clasei (numele) este de obicei un substantiv care trebuie s fie derivat din domeniul problemei analizate i nu trebuie sa fie ambiguu. n partea median sunt atributele. Un atribut are un tip care poate fi: 1. primitiv (integer, real, string, byte, char etc.); 2. instan a unei clase construite de utilizator.

Operaiile (metodele) se trec n partea de jos a clasei i sunt folosite pentru a manipula atributele sau a performa alte aciuni. Descriu serviciile oferite de o clas, de aceea pot fi vzute ca fiind interfaa clasei respective. O operaie are un tip returnat, un nume i zero sau mai muli parametri.

12

Relaii ntr-o diagram a claselor:

Dependena: Apare cnd o clas folosete pentru scurt timp o alt clas. Apare ntre dou elemente dintre care unul este unul independent i altul dependent. Orice modificare a elementului independent va fi reflectat i asupra elementului dependent. Putem avea o relaie de dependen de exemplu n cazul n care o clas folosete ca parametru un obiect al altei clase, sau o clas acceseaz un obiect global al altei clase, sau o operaie a unei clase este apelat ntr-o alt clas.

Asocierea: legtur (conexiune) ntre dou clase (relaie i ntre obiecte,

instane ale celor dou clase) ce permite claselor respective s comunice ntre ele. Pot exista asocieri unidirectionale sau bi-directionale (indic dac fiecare clas transmite mesaje celeilalte sau doar una poate transmite mesaje).

Agregarea: Este o form special de asociere a claselor, utilizat n cazul n

care relaia dintre cele dou clase este de tipul parte din ntreg.

Compozitia: Compunerea este un concept similar cu agregarea, ns mai

puternic deoarece implic faptul c ntregul nu poate exista fr pri.

Generalizarea: Relaie ntre o clas i subclasele sale, este prezent ori de cte
ori se semnaleaz de-a lungul unei ierarhii proprieti comune sau operaii ce evideniaz comportament comun.

Diagrama de Stare
Obiectele din cadrul sistemelor interacioneaz, comunic unele cu altele, prin intermediul aa-numitelor mesaje. Un mesaj este de fapt doar un apel al unei funcii (operaii) n care un anumit obiect invoc un altul. Modul n care comunic obiectele i efectele unei astfel de comunicri sunt referite ca fiind dinamica unui sistem, adic felul n care obiectele i schimb starea n timpul ciclului de via al sistemului.

13

Diagramele de stare descriu strile n care se poate gsi un obiect pe durata vieii sale, comportamentul obiectului aflat n respectivele stri mpreun cu evenimentele (mesaje primite, erori, condiii care devin adevrate) care-i afecteaz starea de-a lungul execuiei. Proprietatile unei stari sunt: 1. Nume; 2. Stereotip; 3. Entry: activitate care trebuie executat n momentul n care se intr n stare; 4. Exit: activitate care trebuie executat n momentul n care se iese din stare; 5. Do: activitate care trebuie executat n timpul n care obiectul se afl ntr-o anumit stare (poate fi ntrerupt de un eveniment extern); 6. Incoming: totalitatea tranziiilor care aduc obiectul n starea respectiv; 7. Outgoing: totalitatea tranziiilor care scot obiectul din starea respectiv; 8. Enternal tranzition: totalitatea tranziiilor interne (nu scot un obiect din starea respectiv - aciunile Entry i Exit nu sunt invocate).

Diagrama de Activitati
Diagramele de activitate descriu activitatile si responsabilitatile elementelor care alcatuiesc sistemul. O diagrama de activitate reprezinta interactiunile dintre activitati, adica fluxul de control al trecerii de la o activitate la alta. Spre deosebire de diagrama de stare infatiseaza starile unui obiect si tranzitiile dintre ele, diagrama de activitate evidentiaza activitatile si tranzitiile dintre ele. Diagramele de activitate pot fi folosite in urmatoarele scopuri: pentru a modela comportamentul intern al unei metode (implementarea unei operatii). Acesta este si cel mai folosit caz cand apelam la acest tip de diagrama;

14

pentru analiza interactiunii activitatilor unui caz de utilizare; pentru a ilustra modul de organizare a mai multor cazuri de utilizare si legaturile dintre acestea.

Diagrama de Secventa
O diagram de secven prezint colaborarea dinamic ntre un numr de obiecte , 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. Pune accentul pe aspectul temporal (ordonarea n timp a mesajelor), fiind potrivit specificaiilor de timp real i scenariilor complexe. Atenia n aceste diagrame este focalizat asupra secvenelor de mesaje, mai precis ce mesaje sunt trimise i recepionate de obiecte. 15

Notaia grafic este un tabel care are pe axa X obiecte, iar pe axa Y mesaje ordonate cresctor n timp. Fiecare obiect este reprezentat ntr-un dreptunghi cu numele obiectului sau clasei scrise subliniat. O linie punctat reprezentat pe vertical, linia vieii, indic execuia obiectului de-a lungul secvenei (mesajele trimise sau recepionate sau activarea obiectului) i perioada n care obiectul preia controlul execuiei (reprezentat printr-un dreptunghi) i efectueaz o aciune, direct sau prin intermediul procedurilor subordonate.

Comunicarea ntre obiecte este reprezentat de sgei ntre liniile verticale ce corespund obiectelor implicate n mesaj. n aceste diagrame mesajele vor putea fi sincrone, asincrone sau simple, ca i n cazul diagramelor de stare. Numele mesajului (stimulului) precum i a aciunii care se va executa vor fi plasate deasupra acestei sgei. Aciunea executat este de cele mai multe ori o operaie implementat n cadrul clasei obiectului care primete mesajul. Dac aceast operaie returneaz o valoare care este important n desfurarea execuiei programului, se poate desena o sgeat punctat, orientat spre obiectul apelant.

Frecvent, acest tip de diagrame vor fi situate sub cazuri de utilizare sau sub diferite componente pentru a ilustra un scenariu (nu un algoritm), sau o succesiune de pai care sunt parcursi la apariia unui eveniment. Arat ce obiect iniiaz activitatea ntr-un sistem, ce procese i schimbri vor avea loc intern n cadrul sistemului i ce date de ieire vor fi generate n urma interaciunilor dintre obiecte. Aadar, o diagram de secven va reprezenta un scenariu dintr-un caz de utilizare (sau o parte a unui scenariu a unui caz de utilizare) sau un curs al evenimentelor, concentrndu-se pe

16

succesiunea n timp a interaciunilor din timpul execuiei, care este determinat prin citirea diagramei de sus n jos.

Diagrama de Colaborare
Diagramele de colaborare urmresc interaciunile i legturile ntre un set de obiecte care colaboreaz. Att diagramele de secven ct i cele de colaborare vizualizeaz interaciuni, dar diagrama de secven ia n considerare timpul, pe cnd cea de colaborare, spaiul (contextul). Ca i diagramele de secven i cele de colaborare pot fi folosite pentru a ilustra execuia unei operaii, a unui caz de utilizare sau a unui scenariu de interaciune ntr-un sistem. n acest tip de diagram nu se pot descrie mesajele concurente i asincrone. Diagramele de colaborare pot fi folosite pentru a ilustra interaciuni complexe ntre obiecte. Spre deosebire de diagramele de secven, cele de colaborare ilustreaz obiectele i legturile dintre ele: o reea de obiecte care colaboreaz i care n multe situaii pot face mai uoar nelegerea interaciunilor. 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. Pentru a ilustra o anumit interaciune tipul diagramei se stabilete dup urmtoarea regul:

17

1. alegem diagrama de colaborare cnd o vizualizare a obiectelor i legturilor dintre ele ne faciliteaz nelegerea interaciunilor sau cnd trebuie scos n eviden contextul; 2. alegem o diagram de secven cnd avem nevoie s vizualizm o secven de aciuni sau dac cel mai important aspect este timpul ori secvena de mesaje.

18

Cuprins
Formularea problemei .................................................................................................... 1 Introducere in UML ....................................................................................................... 6 Principalele parti ale UML sunt: ................................................................................ 7 Vederile (View) ..................................................................................................... 7 Diagramele ............................................................................................................. 7 Mecanismele generale ............................................................................................ 7 View-ul cazurilor de utilizare (Use-case View)......................................................... 8 View-ul logic (Logic View) ....................................................................................... 8 View-ul componentelor (Component View) ............................................................. 9 View-ul de concuren (Concurent View) ................................................................. 9 View-ul de desfsurare (Deployment View) ........................................................... 10 Diagrame ..................................................................................................................... 10 Diagrama Cazurilor de Utilizare .............................................................................. 10 Diagrama de Clasa ................................................................................................... 11 Relaii ntr-o diagram a claselor:............................................................................ 13 Asocierea: ............................................................................................................ 13 Agregarea: ............................................................................................................ 13 Compozitia: .......................................................................................................... 13 Generalizarea: ...................................................................................................... 13 Diagrama de Stare .................................................................................................... 13 Diagrama de Activitati ............................................................................................. 14 Diagrama de Secventa.............................................................................................. 15 Diagrama de Colaborare .......................................................................................... 17 Bibliografie .................................................................................................................. 19 Cuprins ......................................................................................................................... 19

Bibliografie
Introducere in uml.pdf

19