CAP.

3
STRUCTURAL
MODELING
(DIAGRAMA DE
CLASE)
 1. Modelul structural -
 Introducere
Reprezinta structura aplicatiei, adica obiectele/clasele din
aplicatie si relatiile dintre acestea
 clase de obiecte, cu atribute si metode
 Relatii de asociere, mostenire
 Este creat pe baza
 modelului functional al sistemului dezvoltat anterior
 Diagrama cazurilor de utilizare
 Diagrama de activitati
 arhitectura logica a aplicatiei
 1. Modelul structural -
 Introducere
Modelul structural este dezvoltat printr-un proces iterativ, prin
rafinari/detalieri succesive
 Forma iniţială a modelului structural este una simplă,
conceptuala
 Reflecta doar conceptele de business din domeniul
functional relevante pentru dezvoltarea sistemului
(domain classes sau entity) si relatiile dintre acestea
(asocieri)
 Exemple de clase: Client, Factura, Plata, Produs
 Sunt luate in considerare doar relatiile de asociere si
descrierea multiplicitatii/cardinalitatii lor
 Exemple de relatii de asociere: Client – Factura, Factura –
Produs, Factura – Plata
 Modelul structural conceptual reprezinta vocabularul care
sta la baza comunicarii eficace intre analisti si utilizatori
 1. Modelul structural -
Introducere
 Modelul structural evolueaza pe masura ce se avanseaza in
dezvoltarea sistemului
 El devine din ce in ce mai detaliat si mai putin conceptual
 Se adauga noi clase cu roluri specifice, conform
arhitecturii logice – controller, repository, service etc.
 Se introduc relatiile de mostenire, dependenta
 Se specifica navigabilitatea relatiilor de asociere
 Se aplica principii si sabloanele de proiectare
 Modelul structural poate fi redat prin
 Diagrama de clase
 Diagrama de obiecte
 Cardurile CRC (Class-Responsibility-Collaboration)
 2. Diagrama de clase. Elementele
principale
 Ce se reprezinta in diagrama de clase?
 clasele de obiecte ale aplicatiei, cu atribute si metode, si
relatiile dintre clase
 Ce NU se reprezinta?
 Interactiunile dintre obiectele/clasele aplicatiei
 detaliile (algoritmice) ale implementarii comportamentului
aplicatiei

Clasa de obiecte

Relatie de asociere Relatie de agregare Relatie de compozitie

Relatie de mostenire Relatie de realizare Relatie de dependenta

zi detalii si exemple de relatii in suportul de curs si PPT (cap. 1 )

2. Diagrama de clase. Elementele
principale
 2.1 Diagrama de clase. Reprezentarea
claselor
Elementele specificate la descrierea claselor:
 numele clasei
 se utilizeaza font italic pentru clasele abstracte
 pentru atribute:
 numele şi tipul
 valori implicite si valori posibile
 vizibilitate (+, -, #, ~,/)
 atributele de tip class scope (statice) sunt subliniate
 visibility name : type [count] = default_value
 pentru operaţii:
 numele
 listă parametri si tipul datei returnate
 operaţiile abstracte sunt evidenţiate cu font italic
 operatiile statice sunt subliniate
 visibility name (parameters) : return_type
 includerea stereotipului <Interface> pentru clasele de tip interfaţă
2.1 Diagrama de clase. Reprezentarea
claselor
Clase de asociere
 permite reprezentarea unei relatii de asociere care are attribute proprii
 in exemplul dat, relatia de asociere “many-to-many” dintre Comanda si Produs are un
atribut propriu - Cantitate
 se creeaza clasa de asociere LinieComanda, care va continue si atributele de referinta
catre cele doua clase

 spre deosebire de celelalte doua

clase, obiectele unei clase de
asociere nu au o existenta de sine-
statatoare – ele depind de existenta
unei relatii de asociere intre obiecte
din cele doua clase
2.1 Diagrama de clase. Reprezentarea
claselor
 Identificarea claselor începe cu
 studierea vocabularului specific domeniul respectiv
 studierea regulilor afacerii (a proceselor afacerii)
 analiza descrierii detaliate a cazurilor de utilizare
 identificarea claselor pe baza specificatiilor narrative
 substantivele reprezinta potentiale clase, obiecte sau atribute
 adjectivele pot reprezenta atribute
 verbele sunt potentiale responsabilitati ale unei clase
(operatii/metode)
 Pot fi utilizate 4 metode de identificare a obiectelor si relatiilor
 Analiza de text (textual analysis) – presupune identificarea si
analiza substantivelor si a verbelor
 Brainstorming
 Lista obiectelor comune – se iau in considerare 4 categorii:
evenimente, tranzactii, lucruri/resurse fizice sau tangibile,
actori/roluri
 Utilizarea unor sabloane (business pattern)
 2.1 Diagrama de clase. Reprezentarea
claselor
Exemple de sabloane (business paterns)
 2.2 Reprezentarea relatiilor dintre
clase
uri de relatii intre clase de obiecte:
 Generalizare/Specializare
 Mostenire intre clase
 Realizare – implementare a unei interfete
 Asociere – in afara relatiilor de asociere obisnuite, mai exista trei tipuri de as
 Agregare
 Compozitie
 Dependenta
 2.2 Reprezentarea relatiilor dintre
clase
Relatie de realizare (o clasa
Relatie de mostenire
class Class Structure implementeaza
class Class Structure o interfata)

BunMaterial «interface»
Tranzactie
- CodBM :int
- DenumireBM :char + genereazaNotaContabila() :void
- PretInregistrare :double
- UM :char

+ calculValoareCheltuiala() :void

Incasare

ObiectInv entar - Explicatie :char

MateriePrima - NrDoc :int
- DurataUtilizare :int - Suma :double
- ContEvidenta :char - TipDoc :char
+ calculValoareCheltuiala() :void
+ calculValoareCheltuiala() :void + casare() :void + genereazaNotaContabila() :void

Se mostenesc:
Se mostenesc doar:
•Atribute
•Semnaturile metodelor
•Semnaturile metodelor
•Implementari de metode
 2.2 Reprezentarea relatiilor dintre
clase
Relatii de asociere - descriu legaturile dintre obiectele aceleiasi clase
sau din clase diferite
• Exemplu – relatia de asociere dintre clasele Comanda si Client leaga
obiectele Comanda de obiectul Client asociat
• Sunt caracterizate prin:
 Grad– numarul claselor implicate intr-o relatie de asociere
o Unare, binare,
class Class Structure ternare, de grad 4, …

Client class Class Structure

class Class Structure
- adresa :String
- cod :int
- nume :String Disciplina
Persoana 0..1 - persoanaContact :String
- tel efon :int - CodDisc :int
- Adresa :char - DenDisc :char
+cl ient 1
- CNP :char
0..*
- Nume :char *
Proiect
0..1 Examineaza
este casatorit cu - activitati :Activitate [1..*]
- client :Client
- cod :String Student
Profesor
Relatie de -
-
dataInceput :Date
dataSfarsit :Date
1 *
- Matricol :char
- CodProf :int
gradul unu -
-
nume :String
observatii :String
- NumeProf :char
- NumeStudent :char

(recursiva) -
-
persoanaResponsabila :Persoana
stareProiect :StareProi ect

+ adaugaActivi tate(Activi tate) :void

+
+
listaActi vitati () :Activitate
stergeActivitate(Activitate) :void
Relatie de gradul trei (ternara)

Relatie de gradul doi (binara)

 2.2 Reprezentarea relatiilor dintre
clase
Relatii de asociere
• Sunt caracterizate prin:
 Rol – un nume atribuit relatiei
o Exemplu – relatiei de asociere dintre Comanda si Client I se
poate atribui numele “Emite”
 Multiplicitate – numarul obiectelor dintr-o clasa care sunt asociate
unui singur obiect din clasa cealalta
o Exemple de exprimare a multiplicitatii
1 (exactly one)
0..1 (zero or one)
1..* (one or more)
0..* (zero or more)
3..5 (three to five inclusive)
 Atribute – se reprezinta prin intermediul claselor de asociere (vezi
2.1)
 Navigabilitate – arata daca obiectul unei clase are o referinta catre
un obiect din clasa cu care este asociata
o se reprezinta prin sageti amplasate la capetele relatiei de
asociere
o Poate fi nenavigabila, unidirectionala sau bidirectionala
 2.2 Reprezentarea relatiilor dintre
clase
Tipuri aparte de relatii de asociere
 Agregare- este o forma speciala de asociere, de tipul “is part of”
sau “part-whole”
 Compozitie – este o relatie de agregare mai puternica, de tipul “is
entirely made of”
 Partile au aceeasi durata de viata ca si intregul – partile sunt
sterse atunci cand se sterge intregul
 O parte poate apartine unui singur intreg
 Dependenta – este o relatie de asociere de tipul “use temporarily”
 Arata ca o clasa utilizeaza o alta clasa, in sensul ca are attribute
sau operatii cu parametri de tipul celeilalte clase
 Este probabil ca modificarea clasei independente sa determine
necesitatea modificarii clasei dependente
 Adesea, reprezinta un detaliu de implementare
 2.2 Reprezentarea relatiilor dintre
clase Relatie de agregare
class Class Structure

Produs Material

- CodProdus :int - CodMaterial :int

- CostProductie :double - DenMaterial :char
- DenProdus :char - PretUnitar :double
- UM :char - UM :char

 Un material poate “fi parte” (sa intre in fabricatia) mai multor produse
 Stergerea unui produs nu implica stergerea materialelor din care este fabri

class Class Structure

Relatie de compozitie

Proiect Activ itate

- CodProiect :int - CodActivitate :int

- DataInceput :char - DataIncepere :char
- Durata :int - Denumire :char
- Titlu :char - NrOreOmEstimat :int

 O activitate poate asociata cu un singur proiect

 Stergerea unui Proiect determina stergerea tuturor obiectelor Activitate aso
 2.2 Reprezentarea relatiilor dintre
clase
Relatii de dependenta
class Class Model

Client

-
-
ClientID :int
ClientNume :char Clasa IncModel se afla in
«property get» relatie de dependent fata de
clasele Client si Factura
+ getClientID() :int
+ getClientNume() :char
«property set»
+ setClientID(int) :void deoarece ea are attribute si
+ setClientNume(char) :void
metode cu parametric de
1

0..*
tipul celor doua clase, Client
Factura
IncModel ssi Factura.
- ClientSel :Client
- FactId :int - FacturaSel :Factura
- FactNr :char - LstClient :Client [1..*]
- FactSuma :double - LstFactura :Factura [0..*]
- FactValoare :double - repo :Repository
- Partener :Client
«property get»
«property get» + getClientSel() :Client
+ getFactId() :int + getFacturaSel() :Factura
+ getFactNr() :char + getLstClient() :Client
+ getFactSuma() :double + getLstFactura() :Factura
+ getFactValoare() :double + getrepo() :Repository
+ getPartener() :Client
«property set»
«property set» + setClientSel(Client) :void
+ setFactId(int) :void + setFacturaSel(Factura) :void
+ setFactNr(char) :void + setLstClient(Client) :void
+ setFactSuma(double) :void + setLstFactura(Factura) :void
+ setFactValoare(double) :void + setrepo(Repository) :void
+ setPartener(Client) :void
 2.3 Identificarea claselor şi relaţiilor.
Exemplu
Reguli ale afacerii în sistemul de gestiune a comenzilor
clienţilor
Reguli ale afacerii Clase Relaţii identificate
identificate
Clientul este un tip de persoana. Clienţi Generalizare
Persoana
Comanda este un tip de tranzacţie. Tranzacţie Generalizare
Comandă
O comandă conţine una sau mai multe Comandă Agregare compusă
articole, iar un articol nu poate exista fara Linie_Comanda
comanda din care face parte

Un client poate initia mai multe tranzactii, Comanda Asociere

iar o tranzactie este initiata de un client si Client
numai unul.
2.3 Identificarea claselor şi relaţiilor.
Exemplu
Rezultatul analizei
2.3 Identificarea claselor şi relaţiilor
Identificarea relatiilor de
generalizare
 Identificarea relaţiilor de generalizare poate pleca de la:
 identificarea în modelul domeniului a propoziţiilor adevărate ce
conţin aproximativ expresia „este un tip de” (“Is a kind of”)
 prin generalizare - identificarea unor atribute şi/sau operaţii
commune mai multor clase – elementele commune vor fi
incluse in superclasa
 prin specializare – identificarea unor atribute si/sau operatii
specifice unor grupuri de obiecte din aceeasi clasa
2.4 Diagrama de clase.
Exemplul 1
2.4 Diagrama de clase. Exemplul
2
3. Diagrama de obiecte

 reprezinta o instantiere a tuturor elementelor unei diagrame

de clase
 Sunt mai lesne de inteles decat diagramele de clase fiindca
este mai usor sa gandesti in termenii unor obiecte concrete
(instante ale claselor) decat al unor abstractiuni (clase)
 pot fi utile in descoperirea unor atribute sau relatii noi,
depistarea unor greseli de modelare/proiectare
3. Diagrama de obiecte
4. Cardurile CRC. Elemente de
baza
 Descrierea unei clase poate să înceapă cu specificarea
responsabilităţilor acesteia (aşa cum sugerează chiar
principalii autori ai UML Grady Booch, James Rumbaugh
şi Ivar Jacobson în „The UML User Guide”)
 responsabilitatea este ceva ce o clasă:
 ştie – valorile atributelor
 face – operaţiile, precum modificarea valorii
atributelor, calcule economice, etc.
 colaborator – o altă clasă/obiect cu care interacţionează
clasa/obiectul analizată în vederea îndeplinirii
responsabilităţilor sale
 colaborarea poate avea forma:
 solicitarea unei informaţii
 solicitarea de realizare a unei sarcini
 Clasele trebuie să fie nici prea mari şi nici prea mici,
fiecare având o singură responsabilitate mai
importantă.
 4. Carduri CRC. Elemente de baza
Cardurile CRC pot fi o alternativa la diagrama de clase
Un card CRC (Class Responsability Colaborator) permite
reprezentarea:
 Unei clase de obiecte
 A responsabilităţilor ei
 A interacţiunilor/colaborarilor ei
Crearea unui card CRC presupune parcurgerea iterativă a
următorilor paşi:
 Identificarea claselor
 Identificarea responsabilităţilor – orice o clasă ştie sau face
 sunt necesari atunci când o
ceva
clasă nu are suficiente informaţii
 Definirea colaboratorilor
pentru a îndeplini o
responsabilitate
 este o altă clasă care poate
oferi funcţionalitatea lipsă
 definirea se face pentru fiecare
responsabilitate în parte
4. Carduri CRC. Exemplul 1
 clasa Student are ca responsabilitate înregistrarea unui
student la un seminar (Enroll in a seminar)
 are nevoie să ştie câte locuri sunt disponibile la un curs şi
apoi să fie înregistrat
 pentru a-şi îndeplini responsabilitatea, Student:
 are nevoie să ştie dacă mai sunt locuri la
seminarul respectiv
 dacă da, să adauge studentul în lista seminarului
 în concluzie, clasa Student are nevoie sa
interacţioneze/colaboreze cu clasa Seminar, care va fi
inclusă în zona destinată colaboratorilor
4. Carduri CRC. Exemplu 2
Un format extins al
cardului CRC
4. Carduri CRC. Role playing
 Cardurile CRC pot fi utilizate in simulari role-playing
 Aceste simulari sunt utile in verificarea claritatii si
completitudinii elementelor din modelul structural
 Pot fi descoperite clase, atribute, operatii sau relatii
omise
 Simularile role-playing presupun parcurgerea urmatorilor
pasi
 Alegerea scenariului de simulat pe baza descrierilor
detaliate a cazurilor de utilizare sau a diagramelor de
activitati
 Identificarea rolurilor relevante – un actor sau un
obiect (card CRC)
 Efectuarea simularii – fiecare membru al echipei va
juca unul din rolurile stabilite anterior
 Webografie

[Link]

[Link]

lass-diagrams

[Link]

[Link]