diagrame uml
TRANSCRIPT
-
8/2/2019 Diagrame UML
1/19
DISCIPLINA
Analiza si Proiectarea Programelor
TITLUL LUCRARII
Diagrame UML
Formularea problemei
-
8/2/2019 Diagrame UML
2/19
2
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-ului2. Tabelul in care se inregistreaza ofertele agentiei3. 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 ceamai buna oferta ;
Site-ul mai contine si imagini cu unitatile de cazare si obiectiveleturistice 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 ;
-
8/2/2019 Diagrame UML
3/19
-
8/2/2019 Diagrame UML
4/19
4
Pic3 Pagina de oferte
Pic4 Pagina de contact
-
8/2/2019 Diagrame UML
5/19
5
Pic5 Pagina de inregistrare
Pic6 Pagina de logare
-
8/2/2019 Diagrame UML
6/19
6
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.
-
8/2/2019 Diagrame UML
7/19
7
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.
Diagramelesunt 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 modelaresunt 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 alsistemului;
2. Non-funcional: necesarul de timp pentru dezvoltarea sistemuluiDin 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
-
8/2/2019 Diagrame UML
8/19
8
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
-
8/2/2019 Diagrame UML
9/19
9
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).
-
8/2/2019 Diagrame UML
10/19
-
8/2/2019 Diagrame UML
11/19
11
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 ClasaO 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 oricemoment 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:
-
8/2/2019 Diagrame UML
12/19
12
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 safie 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.
-
8/2/2019 Diagrame UML
13/19
13
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.
-
8/2/2019 Diagrame UML
14/19
14
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;
-
8/2/2019 Diagrame UML
15/19
15
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.
-
8/2/2019 Diagrame UML
16/19
16
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
-
8/2/2019 Diagrame UML
17/19
17
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:
-
8/2/2019 Diagrame UML
18/19
18
1. alegem diagrama de colaborare cnd o vizualizare a obiectelor i legturilordintre 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 deaciuni sau dac cel mai important aspect este timpul orisecvena de mesaje.
-
8/2/2019 Diagrame UML
19/19
Cuprins
Formularea problemei .................................................................................................... 1Introducere in UML ....................................................................................................... 6
Principalele parti ale UML sunt: ................................................................................ 7Vederile (View) ..................................................................................................... 7Diagramele ............................................................................................................. 7Mecanismele generale ............................................................................................ 7
View-ul cazurilor de utilizare (Use-case View) ......................................................... 8View-ul logic (Logic View) ....................................................................................... 8View-ul componentelor (Component View) ............................................................. 9View-ul de concuren (Concurent View) ................................................................. 9View-ul de desfsurare (Deployment View) ........................................................... 10
Diagrame ..................................................................................................................... 10Diagrama Cazurilor de Utilizare .............................................................................. 10
Diagrama de Clasa ................................................................................................... 11Relaii ntr-o diagram a claselor:............................................................................ 13Asocierea: ............................................................................................................ 13Agregarea: ............................................................................................................ 13Compozitia: .......................................................................................................... 13Generalizarea: ...................................................................................................... 13
Diagrama de Stare .................................................................................................... 13Diagrama de Activitati ............................................................................................. 14Diagrama de Secventa .............................................................................................. 15Diagrama de Colaborare .......................................................................................... 17
Bibliografie .................................................................................................................. 19
Cuprins ......................................................................................................................... 19
Bibliografie
Introducere in uml.pdf