Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  
AccessAdobe photoshopAlgoritmiAutocadBaze de dateCC sharp
CalculatoareCorel drawDot netExcelFox proFrontpageHardware
HtmlInternetJavaLinuxMatlabMs dosPascal
PhpPower pointRetele calculatoareSqlTutorialsWebdesignWindows
WordXml


Diagrame de clase

java



+ Font mai mare | - Font mai mic



Diagrame de clase


Clase

O clasa de obiecte reprezinta un grup de obiecte care au:



o       proprietati similare (atribute),

o       un comportament comun (operatii),

o       relatii comune cu alte obiecte si

o       o aceeasi semantica

De exemplu, 'Persoana', 'Firma', 'proces' sunt clase de obiecte.

Semantica asociata unei clase corespunde unui punct de vedere. Obiectele din lumea reala pot fi abstractizate in mod diferit. De exemplu, un cal poate fi incadrat in clasa mijloacelor de transport terestre sau in clasa animalelor.


In UML, o clasa este reprezentata printr-un dreptunghi alcatuit din trei compartimente care contin: numele clasei, atributele, operatiile. Compartimentul atributelor si cel al operatiilor pot fi omise.


Nume clasa

Atribute

Operatii



Reprezentarea detaliata a unei clase,construita in etapa de proiectare de detaliu, precizeaza vizibilitatea informatiilor din clasa, lista de parametri a fiecarei operatii si tipul parametrilor.

Regulile de vizibilitate se aplica atat atributelor cat si operatiilor din clase si se refera la domeniul de acces permis la un membru al unei clase. Fiecare nivel de vizibilitate este reprezentat printr-un simbol:

Private ( - ) : accesibiltate numai din interiorul clasei

Public (+) : accesibiltate la nivelul intregului sistem

Protected (#) : accesibiltate in arborele de mostenire

Package (~) : accesibiltate din interiorul pachetului care contine clasa

Membrii statici sunt subliniati.


Clasa detaliata


Relatiile dintre clase sunt abstractii ale relatiilor existente intre obiecte. Fiecarei familii de legaturi intre obiecte ii corespunde o relatie intre clasele obiectelor.

Obiectele sunt instante ale claselor,

Legaturile intre obiecte sunt instante ale relatiilor dintre clase.



Mihai:Persoana IBM:Firma


legaturi

Maria:Persoana A&C:Firma





Persoana Firma

A lucra

asocieri

Universitate A studia Student



Legaturi si asocieri.



Diagramele de clase redau structura statica a unui sistem software

Exista doua tipuri principale de relatii intre clase:

o       asociere si

o       generalizare


Asocierea


Asocierea este o abstractie a unui set de relatii existente intre obiecte. De exemplu, asocierea "A lucra" dintre clasele Persoana si Firma reprezinta toate legaturile posibile dintre obiecte ale clasei Persoana si obiecte ale clasei Firma:


Extremitatea unei asocieri este numita rol

o       Rolul exprima felul in care o clasa 'vede' o alta clasa in cadrul unei asocieri. De exemplu, in asocierea dintre clasele Firma si Persoana, orice obiect al clasei Persoana este un "Angajat" al unei Firme, care este reprezentata printr-un "Patron" .

o       Numele de rol sunt amplasate la cele doua extremitati ale asocierii:


Firma Patron Persoana

Angajat


Nume de rol.


Numele de rol sunt optionale. Numai numele asocierii este obligatoriu pentru o asociere.

Daca intre doua clase exista o singura asociere, numele asocierii este suficient pentru a preciza relatia. Numele de rol se folosesc de regula atunci cand intre doua clase exista mai multe asocieri. In loc de nume de rol se poate scrie un verb sau o fraza care contine un verb, pentru a explica semantica asocierii:



Firma Este angajata Persoana

Lucreaza cu



Observatie: Executable UML impune specificarea numelor de rol. Ele sunt folosite in codul generat automat pentru implementarea asocierilor (VEZI generarea automata a codului pornind de la diagramele de clase).



Aritatea asocierilor

Cea mai mare parte a asocierilor sunt binare - ele unesc doua clase. Asocierile de aritate superioara se reprezinta cu ajutorul unui romb, ca in figura de mai jos. De exemplu, asocierea ilustrata in figura urmatoare exprima faptul ca "Proiectele sunt implementate prin Programe scrise in Limbaje de programare".





Proiect Limbaj



Program



Asociere ternara.





Multiplicitatea asocierilor

Fiecare rol al unei asocieri poate purta o indicatie de multiplicitate care arata cate obiecte ale unei clase pot fi legate la un moment dat unui obiect al celeilalte clase. De exemplu, o firma poate avea unul sau mai multi angajati. O persoana poate lucra la o singura firma. Multiplicitatea poate fi 'unu', 'mai multe '(*) sau un subansamblu de intregi pozitivi: , M..N, sau (de la zero la mai multi), .

Persoana

 

Firma

 
Patron 1..*

1 Angajat

Multiplicitatea asocierilor.

Multiplicitatea unei asocieri exprima o constrangere valabila pe toata durata de existenta a obiectelor claselor asociate. Multiplicitatile nu trebuie sa fie considerate in timpul regimurilor tranzitorii, de creare sau de distrugere a obiectelor.

EXEMPLE:

Asocieri cu atribute

Asocierile pot fi caracterizate prin atribute. In figura 2.23, "Nota" este un atribut al asocierii existente intre clasa "Student" si clasa "Tema".
Asocierea dintre clasa Student si clasa Tema este de tip N la N. Fiecare student realizeaza individual o tema data iar nota obtinuta nu poate fi reprezentata nici ca atribut al studentului (caci un student efectueaza mai multe teme), nici ca atribut al temei (caci fiecare student primeste o nota pentru aceeasi tema). Nota este un atribut al relatiei dintre clasa studentilor si clasa temelor.

Student

 

Tema


 
1..* Realizare 1..*



Nota

 


Asocieri cu atribute.

O asociere cu atribute este numita asociere atributata. Ea poate fi reprezentata printr-o clasa cu atribute si operatii proprii. O asemenea clasa, numita uneori clasa-associere, este atasata asocierii printr-o linie punctata:






VEZI EXEMPLU CURS (Angajat, Departament, Proiect)!

Asocierile pot fi constranse. O constrangere este o regula care trebuie sa fie implementata pentru ca asocierea sa fie valida. Constrangerile sunt scrise intre acolade. De exemplu, instantele clasei B asociate unei instante a clasei A trebuie sa fie ordonate:


A


  B


 


Asociere constransa.

O asociere poate lega o clasa de ea insasi. O asemenea asociere este numita asociere reflexiva Un exemplu de asociere reflexiva este cel ilustrat in figura urmatoare. Fiecare persoana are zero, unu sau doi parinti si zero sau mai multi copii. Numirea rolurilor este in acest caz esentiala pentru claritatea diagramei.

Parinti

Persoana

 
2 Asociere reflexiva

0.. * Copii


Asocierile 1 la mai multi si mai multi la mai multi pot fi calificate. Calificarea este specificata printr-o cheie atasata rolului clasei de plecare.





A


 

B

 



Fig. 2.27. Calificarea asocierilor


Fiecare instanta a clasei A impreuna cu valoarea cheii identifica un sub-ansamblu al instantelor clasei B, care participa la asociere. Exemplu:

Director

 

Fisier

 
Nume de fisier

  R


Fig. 2.28. Identificarea unui fisier.

Un director impreuna cu un nume de fisier desemneaza toate fisierele din director cu acelasi nume si diferite extensii.


Agregarea

Agregarea este o forma particulara de asociere care exprima un cuplaj mai strans intre clase. Una dintre clase joaca un rol mai important decat cealalta in relatie. Agregarea permite reprezentarea relatiilor de tip 'master-slave', 'client-server' si 'compus - componenti'. Agregarea este desemnata printr-un un mic romb amplasat alaturi de clasa agregat (figura 2.29):


Clase agregat.

Un document are mai multe paragrafe si fiecare paragraf este alcatuit din mai multe fraze. In cazul in care multiplicitatea agragatului are valoarea 1, distrugerea agregatului antreneaza distrugerea componentelor.

Masina

 
Motor

 

Fiecare masina contine un motor.


Compunerea (Composition)

Compunerea este un caz particular de agregare. Exprima o agregare prin continere fizica.

Agregat

 

Componente

 



Distrugerea obiectului agregat antreneaza distrugerea componentelor. De exemplu, in agregarea masina- motor definita mai sus, motorul unei masini poate fi inlocuit cu altul. Motorul unei masini poate fi pus in alta masina! Daca insa reprezentam relatia masina - motor ca relatie de compunere-> fiecare masina are un motor unic, care nu poate fi inlocuit si motorul nu poate fi pus in alta masina!




Relatia de compunere este semantic echivalenta cu considerarea componentilor ca atribute ale clasei agregat:

Astfel, relatia de mai sus este echivalenta cu:

Masina


Motor

 



O asociere este de tip agregat atunci cand

- obiectele unei clase fac parte din obiectele unei alte clase;

- atributele unei clase se propaga in atributele unei alte clase;

- o actiune asupra obiectelor unei clase implica o actiune asupra obiectelor unei alte clase;

- obiectele unei clase sunt subordonate obiectelor unei alte clase.



Generalizarea

Ierarhiile de clase sunt bazate pe notiunile de clasificare, generalizare si specializare.

Generalizarea consta in factorizarea elementelor comune (atribute, operatii si constrangeri) ale unui ansamblu de clase intr-o clasa mai generala, numita superclasa. Clasele sunt ordonate intr-o ierarhie. Sageata care simbolizeaza generalizarea intre doua clase puncteaza catre clasa mai generala:



Elicopter

 

Vehicul

 

Vehicul aerian

 
Vehicul terestru

 

Avion

 

Camion

 

Masina

 




O ierarhie de clase.


In ierarhia din figura de mai sus, fiecare clasa (exceptand clasa radacina) are o singura super-clasa. Reprezentarea grafica corespunde unui arbore, numit si arborele de mostenire. Clasele pot avea mai multe super-clase. In acest caz, generalizarea este numita multipla iar ierarhia de clase se reprezinta printr-un graf , numit si graful de mostenire.


Specializarea permite capturarea particularitatilor unui ansamblu de obiecte, nereprezentate prin clasele existente. Noile caracteristici sunt definite intr-o clasa noua, sub-clasa a uneia sau mai multor clase existente. Specializarea este o tehnica foarte eficienta de extensie coerenta a unui ansamblu de clase existente. Noile cerinte sunt incapsulate in sub-clase care extind functiile existente. De exemplu, daca intr-o aplicatie apare necesar sa se reprezinte 'bicicleta' ca vehicul de transport, in plus fata de cele reprezentate in ierarhia de mai sus, atunci se va defini o clasa noua, sub-clasa a clasei 'Vehicul terestru', in care vor fi definite particularitatile bicicletei ca vehicul terestru. Fiecare sub-clasa a unei ierarhii mosteneste atributele si operatiile definite in clasele aflate pe calea de la clasa radacina la subclasa respectiva, fiind cu atat mai specializata cu cat se afla mai departe de radacina.


Mostenirea este o tehnica oferita de limbajele de programare pentru a construi o clasa plecand de la una sau mai multe clase, partajand atribute, operatii si uneori constrangeri in interiorul unei ierarhii de clase. Clasele copil mostenesc caracteristicile claselor parinte. Atributele si operatiile declarate in clasele parinte sunt accesibile in clasele copil, ca si cum ar fi declarate local. Mostenirea este o modalitate de a realiza clasificarea.


Relatia de generalizare definita in UML este mai abstracta decat relatia de mostenire care exista in limbajele de programare obiect, cum ar fi C++. Ea este mai adecvata etapei de analiza (exista si intre cazuri de utilizare!). Decizia asupra modalitatii de a realiza generalizarea se ia mai tarziu, in etapa de proiectare.


Prin clasificare si generalizare, universul problemei este divizat in parti independente care grupeaza obiectele prin afinitate. Modificarea unei parti antreneaza un minimum de modificari ale celorlalte, fapt pus in evidenta de arborele de mostenire: fiecare subarbore grupeaza obiectele care impart caracteristicile radacinii sale. De exemplu, adaugarea de noi caracteristici la clasa Articol-de-lux (figura )nu afecteaza clasa imbracaminte si nici subclasele acesteia, dar extinde automat caracteristicile subclaselor clasei Articol-de-lux.
















Uneori, anumite clase sunt create doar ca surse de mostenire pentru alte clase; ele sunt clase abstracte. De exemplu, clasa Articol este o clasa abstracta daca nu caracterizeaza complet nici un obiect din universul problemei. Clasa Articole-electrice a fost introdusa pentru a factoriza proprietatile electrice (de exemplu, tensiunea de alimentare, consumul si altele), comune calculatorului si articolelor electrocasnice.























Navigabilitate


Navigabilitatea desemneaza necesitatea ca un obiect al unei clase sa acceseze un alt obiect "navigand" de-a lungul unei legaturi. Navigabilitatea se reprezinta printr-o sageata la capatul "navigabil" al asocierii. Obiectul de la capatul navigabil este accesibil unui obiect de la cealalata extremitate. Invers, nu.

Urmatoarea diagrama de clase modeleaza o aplicatie care permite plati pe baza de ordine ale clientilor.

Sageata asociata asocierii se numeste navigabilitate. Ea indica directia in care trebuie sa fie traversata sau interogata asocierea. De exemplu, un obiect OrderDetail poate interoga obiectul Item asociat. Un obiect Item poate fi asociat mai multor obiecte OrderDetail dar pentru el nu este necesar sa le cunoasca. Un obiect Order este asociat cu mai multe obecte Payment, pe care trebuie sa le cunoasca. Pentru un obiect Payment nu este necesar sa cunoasca obiectul Order asociat.

Asocierile fara navigabilitate sunt considerate bi-directionale. Navigabilitatea este un element optional. Se adauga pentru a imbunatati claritatea diagramei.



Dependente si constrangeri

O dependenta este o relatie intre 2 clase in care modificarea uneia poate forta modificarea celeilalte. Exemplu: CompanyDetails depinde de Company Daca se modifica Company trebuie sa se modifice si CompanyDetails.

O constrangere este o conditie pe care orice implementare a diagramei trebuie sa o satisfaca. Este scrisa intre paranteze . Exemplu: Un obiect Section poate fi parte dintr-un obiect CourseSchedule numai daca nu a fost anulat.





Folosirea diagramelor de clase:


1) In modelarea conceptuala (analiza oriectata obiect)

Clasele corespund conceptelor / obiectelor (entitatilor) din domeniul aplicatiei

Nu exista neaparat o legatura directa cu clasele de obiecte utilizate in implementare si deci diagrama de clase nu face parte din modelul structural al sistemului


- De regula, nu sunt definite operatiile din clase prin tipurile parametrilor si nici tipul atributelor.

- Diagrama de clase poate fi folosita in modelarea conceptuala a unei baze de date. In modelul fizic al BD clasele se implementeaza prin tabele ale bazei de date.


Pentru specificarea software

Se pune accent pe interfata si nu pe implementare

Adesea se foloseste cuvantul "tip" in legatura cu interfata unei clase: un tip poate fi implementat de mai multe clase si o clasa poate implementa mai multe tipuri


In proiectarea de detaliu si implementare

Diagramele contin clase de obiecte intr-un anumit limbaj de programare

Diagramele fac parte din modelul structural al sistemului

Diagrame de obiecte

O diagrama de obiecte reda un set de obiecte si legaturile dintre ele la un moment dat.




O diagrama de obiecte este o instanta a unei diagrame de clase sau partea statica a unei diagrame de interactiune.


O diagrama de interactiune adauga la o diagrama de obiecte mesajele care sunt schimbate intre obiecte.



Generarea automata a codului pornind de la diagramele de clase CURS





Politica de confidentialitate | Termeni si conditii de utilizare



DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 1322
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved