Sunteți pe pagina 1din 34

Obiecte, clase şi relaţiile dintre clase.

Diagrama claselor conceptuale. Pachete de


clase
Structura cursului

 Analiza domeniului şi identificarea obiectelor


specifice
 Clasele şi relaţiile dintre clase
 Diagrama claselor conceptuale
 Generalizarea conceptelor
 Pachetele de clase.
Obiectele software şi clasele

 Obiectele sunt cele mai mici blocuri de cod în


construcţia unui program software. Ele au o
funcţionalitate limitată şi reprezintă primul nivel de
abstractizare într-un program. Fiecare obiect are
trei proprietăţi:
– Starea – cu alte cuvinte, structurile de date;
– Mediul – reprezentat de metodele care
realizează funcţionalitatea;
– Identitatea – o etichetă unică.
Obiectele software şi clasele

 Variabilele care realizează starea obiectului sunt numite


atribute.
 Starea obiectului este determinată de valoarea atributelor.
 Dacă obiectele conţin şi îşi stăpânesc stările atunci putem
spune că ele sunt încapsulate. Încapsularea uşurează
repartiţia sarcinilor şi comunicaţiile între obiecte.
 Obiectele reacţioneză la mediu, iar mediul acţionează prin
programe specifice – metode (methods) apelate prin formate
numite operaţii.
Metode

 setează starea atributelor (sets);


 întoarce starea atributelor (gets);
 modifică starea proprie;
 cheamă metode (invoking methods) ale altor
obiecte sau servicii ale sistemului;
 se autocrează şi se autodistrug.
Clase şi obiecte

 Clasa – reprezintă descrierea abstractă a unui


ansamblu de obiecte având aceleaşi caracteristici.
 Obiectul – este o entitate cu limite bine definite,
având o identitate şi înglobând o stare şi un
comportament.
 Un obiect este o instanţă a unei clase.
 Atributul – reprezintă un tip de informaţie conţinut
într-o clasă.
Clase şi obiecte

 În UML, clasele sunt reprezentate prin diagrame de


clase. Fiecare clasă arată ca o cutie care conţine
trei arii:
– prima în care se specifică numele clasei;
– a doua în care se notează atributele;
– cea de-a treia care cuprinde operaţiile, cu alte cuvinte
formatul de apelare al metodelor.
Acesta din urmă pune în evidenţă: a) numele metodei; b)
eventualii parametri de apel şi forma acestora; c) forma
datei întoarse în program după executarea metodei.
Clase şi obiecte

 Metodele pentru crearea unui obiect se numesc


constructori.
 Sintaxa pentru invocarea unui constructor şi
crearea unui obiect este, cel mai adesea, new.
Atunci când este invocat new, programul alocă
memoria pentru acel obiect.
 Pentru a distruge obiectul şi a elibera memoria,
este invocat un destructor cu operatorul delete.
Relaţiile între clase. Generalizarea,
asocierea, agregarea, compunerea
 Clasele pot fi legate între ele prin moşteniri. În
UML, moştenirea este numită adesea generalizare.
 Super-clasa: este o clasă generală, cuprinzând un
nucleu de caracteristici comune, legată la una sau
mai multe alte clase specializate (sub-clase) printr-o
relaţie de generalizare.
 Sub-clasa moşteneşte nucleul de caracteristici ale
super-clasei, adăugând, eventual şi alte atribute
specifice.
Specificaţie de clasă
Asocierea

 Asocierea – este o relaţie semantică durabilă între două


clase.
 Exemplu: o persoană poate avea un autoturism.
 Asocierea poate fi nominalizată (ex. persoana are un
autoturism).
 Obs. Asocierea între concepte este implicit bidirecţională
(se înţelege, implicit, că un automobil se află în posesia
unei persoane). La cele două capete ale unei asocieri se
pot face indicaţii de multiplicitate. Ele specifică, sub
forma unui interval, numărul de obiecte care pot
participa la o relaţie cu un obiect din altă clasă, în cadrul
unei asocieri.
Specificarea tipurilor de asociere

 Asocierea 2 arată că putem avea sau nu un obiect din clasa A (0..1) asociat mai
multor obiecte din clasa C (0..*).
 Alte notaţii uzuale pentru indicatorul de multiplicitate:
– (n) - un număr fix de “n” obiecte se pot afla la un moment dat în relaţie de asociere (n poate fi şi 1);
– (1..*) - cel puţin un obiect se poate afla la un moment dat în relaţie de asociere.
Agregarea

 Când o clasă este un tip al atributelor


unei alte clase, spunem că cele două
clase sunt legate prin agregare.
 În UML, agregarea este un fel de
asociere a claselor.
Specificarea agregării şi compunerii

 Obiectele clasei A (angajat)


sunt asociate (1) cu obiecte
ale clasei B (echipă) şi (2)
cu un obiect al clasei C
(întreprindere), numai că
rolul lor în cadrul acestor
asocieri este diferit.
 Agregarea este numai
unidirecţională.
 Compunerea este marcată
în diagramă cu un romb
plin.
Agregarea şi compunerea

 Agregarea, marcată cu un romb vid, este un caz particular de


asociere nesimetrică – cu alte cuvinte, un obiect dintr-o clasă
este asociat mai multor obiecte din altă clasă.
 Agregarea exprimă o relaţie de „a conţine”, „este compus din”
şi din acest motiv n-are nevoie să fie nominalizată.
 O compunere este o agregare mai puternică ce implică faptul
că:
– obiectele dintr-o clasă asociate unui obiect din altă clasă compun de fapt
acel obiect, cu alte cuvinte toate sunt la fel de importante şi determinante
pentru obiectul pe care îl compun;
– durata de viaţă a obiectului compus este aceeaşi cu a obiectelor care îl
compun, cu alte cuvinte dispariţia obiectului compus antrenează
nemijlocit dispariţia tuturor componentelor sale.
Diagrama claselor conceptuale şi
elementele sale
 Rol: Diagrama claselor conceptuale produce o primă
viziune asupra structurii de clase a sistemului, o
identificare a obiectelor conceptuale şi a relaţiilor dintre
acestea.
 Elemente: Clasă, atribut, operaţie, asociere,
multiplicitate, compunere, agregare, generalizare.
 Diagramele claselor conceptuale arată modul în care
cazurile de utilizare se descompun în clase, care se
relaţionează în cadrul sistemului.
Clasa
Relaţii între clase. Asocierea

 Asocierile reprezintă legături între instanţele claselor. Din punct de vedere conceptual, asocierile reprezintă relaţii
conceptuale între clase.
 Fiecare asociere are două extremităţi (a, b), care poartă numele de roluri, fiecare extremitate fiind legată la una din
clasele de asociere.
 În absenţa unei denumiri, numele rolului este identic cu numele clasei la care este legat. Fiecărui rol i se poate asocia o
multiplicitate.
Multiplicitatea

 Multiplicitatea indică numărul de obiecte susceptibile de a participa


la o asociere dată. În general, multiplicitatea m..p indică numărul
minimal m şi maximal p de obiecte care pot participa la asocierea
respectivă.
 Notaţia 0..* reprezintă plaja de la 0 la infinit.
 Astfel, unei instanţe a clasei B i se pot ataşa mai multe obiecte
aparţinând clasei A (sau chiar nici un obiect), în timp ce o instanţă
a clasei A trebuie să fie legată obligatoriu la un singur obiect
aparţinând clasei B.
Exemplu de multiplicitate
Navigabilitatea

Exemplu:
Navigabilitatea indică o asociere
unidirecţională.
Ex. Săgeata îndreptată de la clasa A spre
clasa B arată că un obiect al clasei B
poate dispune de toate instanţele clasei
A asociate acestuia, dar nu şi invers.
Atributele

 Atributele sunt asemănătoare asocierilor.


 La nivel conceptual, atributul nume al unui client
arată că acesta are un nume.
 La nivelul specificaţiei de interfaţă, se arată că un
obiect client răspunde de acest atribut şi poate să
furnizeze numele său.
 La nivelul implementării, un client are un câmp –
numit şi variabilă de instanţă sau dată membru a
clasei Client – care conţine numele său
Atributele
Operaţiile
Generalizarea
 Generalizarea este o relaţie de forma subtip între clase. În plan conceptual, putem spune că A
şi B sunt „un fel de” C sau A şi B sunt subtipuri ale supertipului C dacă toate instanţele claselor
A şi B sunt, prin definiţie, şi instanţe ale clasei C.
 În modelul de specificaţii, generalizarea se traduce prin aceea că interfaţa subtipului trebuie
să conţină toate elementele de interfaţă ale supertipului (este conformă interfeţei supertipului.
 Din punct de vedere al implementării şi al limbajului de programare, generalizarea este
asociată moştenirii.
Clasificarea

 Clasificarea este un mod de generalizare care defineşte relaţia


ce leagă un obiect de un tip.
 Clasificarea unică: un obiect nu poate aparţine decât unui
singur tip, care poate moşteni supertipuri.
 Clasificarea multiplă: un obiect poate fi descris prin mai multe
tipuri, care nu sunt în mod obligatoriu asociate printr-o relaţie
de moştenire.
 Clasificarea statică: nu permite schimbarea tipului, odată
definit.
 Clasificarea dinamică: permite obiectelor să-şi schimbe tipul în
interiorul unei structuri de subtip.
Exemplu de clasificare
Agregarea

 Agregarea exprimă relaţia „un obiect aparţinând clasei B este o


parte a unui obiect aparţinând clasei A”.
 Un obiect al clasi A este legat prin agregare de părţile sale
componente – instanţe ale clasei B. Un obiect al clasei B poate
aparţine însă, în acelaşi timp, mai multor tipuri de agregări –
obiecte ale lui A.
 Agregarea este marcată cu un romb vid în spre clasa care
conţine obiectul agregant.
Exemplu de agregare
Compunerea

 Compunerea este o agregare mai puternică şi mai restrictivă, în


sensul că obiectul clasei B care este parte a unei instanţe a clasei
A nu mai poate face parte dintr-o altă instanţă. El defineşte în
mod unic obiectul clasei A din care este parte, având aceeaşi
durată de viaţă cu acesta.
 Compunerea este marcată cu un romb plin situat în spre clasa
care conţine obiectul compus.
Exemplu de compunere
Pachete de clase

 Pachetul este un mecanism general de regrupare a


elementelor UML, utilizat, în principal, în analiza şi concepţia
obiectelor pentru a regrupa clase şi asocieri.
 Un pachet este o colecţie de clase, ale căror obiecte
colaborează în vederea producerii de servicii.
 O clasă poate aparţine unui singur pachet. Mai departe, deşi
nu constituie o restricţie, fiecare clasă trebuie să aparţină unui
pachet.
 Pachetele pot fi combinate pentru a forma pachete mai
generale ş.a.m.d. Astfel se formează o ierarhie de
abstractizări. Arhitectura sistemului este capturată de către
pachetul de proiectare.
Ierarhie de pachete
Asocierea pachetelor

 Dependenţele pot fi bidirecţionale sau unidirecţionale.


 O dependenţă este este unidirecţională atunci când metode de clasă dintr-
un pachet pot apela metode de clasă dintr-un alt pachet, dar nu şi invers
 Ex. Obiecte din clase aflate în pachetul A pot fi apelate prin metode ale unor
obiecte aflate în pachetele B şi C.
 Obiecte din B pot fi apelate în A, dar nu şi obiectele din C. Dacă obiectele
claselor pachetului A pot fi apelate din C, spunem că A depinde de C. În
acest caz, C poate fi dezvoltat, în principiu, separat şi independent deoarece
obiectele sale nu pot fi apelate de nicăieri .

S-ar putea să vă placă și