diagrame uml

Upload: luci-luciano

Post on 05-Apr-2018

263 views

Category:

Documents


0 download

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