APOO Curs 1

20 martie 2007
20:57

1. Parcurgerea in cascada (waterflow)
Dezavantaje: 
Analiza - Necesitatea reluarii complete in cazul unor defecte majore.
- Poate conduce la cresterea timpului de realizare
Proiectarea - Este un risc foarte mare.

Implementare

Testare

Pentru scaderea riscului s‐au gandit tot felul de alte combinatii pt parcurgerea etapelor de dezvoltare.

2. Parcurgerea in spirala

‐abordare pe versiuni Analiza Proiectare

‐se parcurg intrun mod care le lasa incomplete
‐vor fi completate la o noua trecere
‐versiunile incomplete reprezinta bazele dezvoltarii 
urmatorului nivel de parcurgere Testare Implementare
‐o astfel de abordare scade riscul de a avea timp mare de 
realizare (risc de piata)
‐pe parcurs se pot insusii tehnici noi

2. Parcurgerea incrementala (incremental)

‐modelul: RUP ‐> Rational unified process(proces de realizare unficata) (folosind toolsetul Relational Rod)

Faze: Intiere(Inception) Elaborare Constructie Migrare

Iteratii:
‐Fiecare faza poate contine mai multe iteratii(un numar oarecare)
‐Fiecare iteratie contine toate cele 4 etape prezentate mai sus

Faza de initiere
‐definirea scopului proiectului

Faza de elaborare
‐stabileste modul de abordare (obiect orientata sau component orientata)
‐se incearca limitarea(excluderea) zonelor de risc

Faza de constructie
‐proiectarea detaliata si implementarea aplicatiei

Faza de migratie
‐accentul se pune pe trecerea de la produsul in stare de prototip la 
inglobarea la utilizator. Accentul se pune pe testare

APOO Curs Page 1

 Analiza si proiectarea Obiect Orientata ca modalitate de sistematizare 
a dezvoltarii software
- Modelul obiect :
○ ‐permite dezvoltarea aplicatiilor ‐> colectii de clase si obiecte
○ ‐obiectele colaboareaza intre ele ‐> sunt instante ale claselor
○ ‐clasele sunt membre ale unei ierarhii de clase (prin mostenire)

Modelul obiect constituie o viziune integratoare in proiectarea mai multor sisteme(hardware, 
arhitectura, etc). Acest lucru contine o unificare a caracteristicilor.

Caracteristici fundamentale:
1. Abstractizarea
i. Nu este proprie numai modelului obiect dar este obligatorie pt modelul obiect.
ii. Prin abstractizare se definesc clasele ‐ >tipuri de date (tipuri abstracte)
‐>fiecare clasa inglobeaza atributele cele mai  relevante

2. Modularitate
i. Abordarea prin care aplicatia se imparte in module
1) Modulele trebuie sa fie "slab cuplate"
ii. In OO modulele contin clase si obiecte
iii. Nu este specifica OO dar (obligatorie) recomandabila

3. Mostenirea
i. Proprietatea prin care se pot definii ierarhii de clase
1) Clase de baza
2) Clase derivate 
ii. Se poate face prin 2 procese:
1) Specializare ‐ pornind de la o clasa de baza si definind clase specializate ‐>mostenesc 
caractere generale din clasa de baza si au si propriul lor specific
2) Generalizare ‐ pronind de la mai multe clase oarecum corelate(indrudite) se extrag 
caracteristicile comune ‐> se folosesc pt a definii o clasa de baza

4. Incapsularea si ascunderea implementarii
i. Asigura ca o clasa sa fie impartita in 2 parti
1) Structura
a) Multimea atributelor (date membre ale clasei)
b) Implementarea metodelor
2) Comportarea ‐ data de ceea ce se numeste interfata clasei‐>asigura legatura cu ext.
Multimea metodelor publice ale clasei ‐ prototipurile

ii. Permite reutilizarea codului

iii. Permite modificari independente in diferitele module

Exmeplu:
Class punct{
Float x; // datele membre sa fie de tip private
Float y;
Public:
Punct(float a, float b); // constructor

Float getx();// functii de tip getter

Float gety();// citesc variabile private (f selector)
Void setx(float a);// modifica valuarea datelor membre
Void sety(float b);// f modificator sau de tip setter

APOO Curs Page 2

 Void translate(folat a, float b);
}

Punct::Punct(float a, float b)//constructor

{
X = a; y = b;
}

Puncg::getx(){
Return x;
}

iv. Fiecare obiect = instanta unei clase reprezinta o colectie de valori ale atributelor clasei 
(general)

v. Se comporta in moduri diferite in functie de tipul de abordare al programarii
1) Programare procedurala ‐ dificil de implementat 
2) Programarea OO ‐ incapsularea este recomandata si limbajele ofera suport pt aceasta 
proprietat (nerespectarea este posibila dar pot sa apara probleme de siguranta a 
utilizarii obiectelor).
3) Programarea orientata pe componente ‐ incapsularea este obligatorie
Tehnologiile de componente soft te obliga sa ai separatie completa intre interfata si 
implementare

Caracteristici secundare:

1. Tipizarea = regulile prin care se pot combina sau de conversii intre diferite tipuri de date dintr‐un 
limbaj
i. Slab tipizate: smaltalk ( C )‐ permit orice fel de combinatii intre obiecte.
ii. Puternic tipizate: Eifel, Java, C#
iii. Mediu tipizat:  C++

2. Persistenta = capacitatea de stocare permanenta a datelor create intr‐un program. Exista 
posibilitatea ca aceste date sa supravietuiasca programului. Serializare

3. Concurenta = se intelege posibilitatea de executie concomitenta(simultana) a mai multor obiecte 
din aceeasi clasa sau clase diferite.  Are loc numai daca avem deaface cu un calculator paralel sau 
sistem distribuit (reala). (simulata : threaduri).

APOO Curs Page 3

 APOO Curs 2
20 martie 2007
20:55
Caracteristicile modelului obiect

1. Caracteristici fundamentale Clase:
a. Abstractizarea - Structura: date modul+impl. Modul
b. Modularitatea - Comportarea: interfata = met de protectie, functii public
c. Mostenirea
d. Incapsularea

Fiecare obiect = instanta a clasei ‐ obiecte cu valoare de atribut a clasei??

Principiul incapsularii si al ascunderii implementarii se compolrta in moduri diferite in functie de tipul de 
abordare al programarii:
- Pentru programarea procedurala, aceasta proprietate este dificil de implementat
- Pentru programarea OO, incapsularea este recomandata si limbajele OO ofera suport pentru aceasta 
proprietate (specificatori diferiti, date separate, etc.)
○ Nerespectarea acestei proprietati este posibila dar pot sa apara probleme de siguranta a utilizarii 
obiectielor.
- Progamarea orientata pe componente ‐ incapsularea este obligatorie
○ Tehnologiile de componente software te obliga sa ai separatie completa intre interfata si 
implementare

2. Caracteristici secundare ‐ model obiect:
a. Tipizarea ‐ se refera la regulile prin care se pot combina in expresii sau de conversii intre diferite 
tipuri de date dintr‐un limbaj ‐ modul de conversie e precizat prin caracteristicile de tipizare 
(tipizarea se refera la tipui, tipurile=clase => tipzarea se refera la clase)
i. Limbaje slab tipizate : Smaltalk care permite orice fel de combinatii intre obiecte 
(programatorul trebuie sa aiba grija)
ii. Limbaje putrenic tipizate:Eifell, Java, C#
iii. Limbaje mediu tipizate: C++

b. Persistenta = capacitatea de stocare permanenta a datelor creeate intr‐un program ‐ datele 
creeate intr‐un program sa supravietuiasca programului;"serializatea datelor"=datele sunt 
transformate in secvente de octeti, sunt scrise si raman acolo cand se termina programul. La o 
noua executie ele pot fi utilizate.
c. Concurenta relativa la modelul OO = posibilitatea de executie concomitenta a mai multor obiecte 
din aceeasi clasa sau clase diferite. Concurenta apare la calcualtoare paralele sau sisteme 
distribuite.

Analiza, proiectarea, programarea Obiect Orientata

Aplicarea proprietatiilor si a conceptelor modelului obiect in aceste etape de dezvoltarea software.

1. Analiza OO
a. Analiza cerintelor respecta principiul general de abstractizare:
i. principiul prin care se slecteaza caracteristicile relevante ale realitatii modelate
ii. Identificarea claselor care vor constituii programul
Entitatile ‐> tip de entitate <‐ clasa
O entitate reprezinta orice exista in realitatea modelata
Multimea entitatilor de acelas tip reprezinta multimea obiectelor instante ale clasei 
respective;

APOO Curs Page 4

2. Proiectare OO
a. Detalierea claselor, obiectelor si legaturilor dintre acestea pe baza cerintelor stabilite in faza de 
analiza
b. Se stabilesc modulele proiectului intr‐o abordare; Intr‐o abordare OO, un modul este o colectie de 
clase
c. Se stabilesc tehnologiile de realizare ‐> platforma, SO, hardware, limbaje si alte standarde 
(biblioteci, etc.)
3. Implementarea OO (programarea)
a. Programarea ‐ foloseste un limbaj OO ‐ toolseturi, biblioteci
b. Se scriu programele
4. Testarea OO ‐ se folosesc clase gata testate din biblioteci

Avantajele abordarii obiect orientate a dezvoltarii softwareului

1) Reutilizabilitate codului ‐ se folosesc biblioteci de clase
2) Extensibilitatea codului ‐ se folosesc clase derivate din clasele din bilioteci
3) Mentenanta aplicatiilor obiect orientate = intretinerea bunei functionari a aplicatiilor e mai simpla in OO 
din 2 motive:
a. Existenta incapsularii ‐ accesarea inmod unitar prin interfata a obiectelor
b. Se impun mecanisme de tratare a exceptiilor mai precise decat in alte limbaje

Limitarile abordarii OO

1. La inceput se credea ca OO va rezolva problema reutilizabilitatii codului. In realitatea avem doar o 
reutilizabilitate limitate a codului. 
a. S‐a constatat ca totusi clasele sunt prea mici si prea speciale
b. Biblioteci de uz general au functionalitate limitata. MFC (Microsoft Foundation Clases) a 
reprezentat baza dezvoltarii programelor Windows in C++. 
2. Interoperabilitatea limitata; interoperabilitate = posibilitatea de a opera impreuna a diferitelor clase si 
obiecte. Ea este limitata datorita faptului ca bibliotecile sunt cu destinatii limitate la randul lor. Ex: 
clasele si pakageurile java comunica greu cu clasele C++.

Tendintele de dezvoltare software

Scop: Eliminarea (micsoararea) limitarilor OO.
- Software orientat pe componente 
○ beneficiaza de standarde generale care permit obtinerea 
ƒ Reutilizabilitatii ‐ ea creste datorita faptului ca componentele sunt mai mari decat clasele
ƒ Interoperabilitatii ‐ creste datorita standardelor impuse si datorita faptului ca orice 
componenta contine o interfata. Ea poate fii folosita deci mai comod in programare.

Dezvoltarea programelor folosind modelare UML

- Modul de dezvoltare soft; se folosec modele (concepte care sintetizeaza abstractizare din realitate 
pentru un anumit scop si o anumita utilizare). Modelele se pot dezvolta in limbaje de modelare
- Anii 1990 ‐ zeci de limbaje diferite, fiecare propunand un anumit mod de reprezentare a programelor.
- Unificarea prin standardizare a proiectarii soft a fost o cerinta inerenta

In anul 1995 3 cercetatori au unificat cele 3  limbaje definite de ei
- Grady Bookh ‐ 1994 Object Oriented Analisys and Design ‐ limbaj G.B
- James Rumbourgh ‐ OMT (Object Modeling Tehnology)
- Ivan Jacobson ‐ OOSE (Object Oriented modeling language)

APOO Curs Page 5

 In 1997 limbajul UML a fost preluat de OMG (Object Management Group) (www.omg.org) si au dat 
primul standard si specificare UML 1.1. Actualmente s‐a ajuns la versiunea 2.1.1
Limbajul UML
¾ Este un limbaj pentru dezvoltare, specificare, documentare si vizualizare a produselor software. 
¾ UML este un limbaj grafic; elementele sale sunt elemete de grafica 2D si aceste elemente sunt procedee 
care specifica diversele aspecte ale produsului software. 
¾ Toate elementele sunt  insotite de texte
¾ Limbajul UML trebuie sa ajute dezvoltatorii sa il foloseasca si deci defineste concepte ale limbajului, 
semantica (intelesul diverselor elemente), precizeaza notatii (ex: conceptul de clasificator se noteaza 
asa...) si de asemenea ofera solutii sau recomandari de proiectare (pattern‐uri, tipare)

Caracteristicile limbajului UML
Limbajul uml inseamna UNIFICARE+FLEXIBILITATE
¾ Unificarea in modalitatile de dezvoltare software
○ Integreaza cele mai bune practici. 
○ Integrarea continua prin adaugarea la diferitele revizii a uno aspecte noi de proiectare software.
ƒ Ex: ulterior s‐au inglobat componentele software.
¾ Foloseste modelul obiect ca baza a abordarii proiectarii software.
○ Poate fi utilizat si in alte abordari deoarece conceptele pe care le defineste au un caracter mai 
general decat modelul obiect. 
¾ Limbajul foloseste tipuri de date (incluse in elemetele grafice) ‐ independente de limbajele de 
programare existenta (Defineste Real sau Integer fara sa faca o precizare stricta a legaturii cu aceste 
tipuri din limbajele de programare existente. Admite si tipuri ale limbajelor ‐ FLEXIBILITATE). 
Flexibilitatea este si mai puternic relevata de faptul ca limbajul UML oferea o multitudine de vederi ale 
sistemului software (views). Aceleasi sistem poate fii privit din mai multe puncte de vedere, aspecte 
modelate si apoi dezvoltate. 
○ Sistemele software complexe nu pot sa fie reprezentate si necesita:
ƒ Specificari; fiecare specificare corespunde unui aspect si fiecare aspect mai multor vederi
ƒ Colaborarea mai multor categorii de personal
□ Analisti
□ Proiectanti

- Diagramelor de functionare (use‐case). Acestea au fost preluate din OOSE al lui Jacobson  ‐ servesc 
managerilor
- Diagramele fizice
ƒ Diagrame ale componentelor
ƒ Diagrame de deployment ‐ se refera la instalarea diverselor parti (deployment ?= 
desfasurare)
- Diagrame de organizare a sistemului software
ƒ Diagrame de pachete
ƒ Diagrame de subsisteme
ƒ Diagrame ale modelelor
Fiecare categorie de personal de dezvoltare foloseste diferite vederi (diagrame) in functie de atributile 
fiecaruia

¾ Limbajul UML ofera posibilitatea definirii pe diferite grade de detaliere.  
- Acelasi element poate sa fie reprezentat in mai multe moduri de la foarte general pana la foarte 
detaliat.
- Limbajul UML poate fi folosit in toate etapene de dezvoltare. In faza de analiza avem elemente 
reprezentate simplificat ajungand in fazele de testare si implementare pana la reprezentarea 
detaliata a aceluias element
Pentru limbajul UML s‐au dezvoltat numeoase toolseturi in functie de necesitati si specificatii. Important 
este ca un toolset nu respecta intru totul specificatiile standard ale limbajului.

APOO Curs Page 6

 APOO Curs 3
13 martie 2007
10:05

Modelarea structurala

Structura se refera la partile componente ale unui sistem; arhitectura unui sisteme se refera la partile 
componente si legaturile(interfata) dintre ele. 

- Reprezentarea structurala a unui sistem software ‐ partile componente
- Diagrama claselor si diagrama obiectelor. 
1) Diagrama claselor este un model structural al unui sistem
i. Este reprezentat printr‐un graf
□ In noduri avem clase
□ Arcele reprezinta legaturile UML
ii. Capteaza informatii statice ale modelului. 
2) Diagrama obiectelor: 
i. sunt reprezentate obiectele in UML. Obiectele sunt instante ale claselor. 
ii. Este o reprezentare la unmoment dat (obiectele au comportare dinamica)
iii. Utilitate restransa

OBS: 
1. Se pot combina cele 2 tipuri de diagrame! (clase+obiecte). Reprezentarea se face in functie de 
necesitati.
2. Mai exista si alte diagrame structurale: diagrama componenteleor (sotfware)

Elementele structurale ale diagramei claselor

In UML, un clasificator (classifier) este un element structural care reprezinta un concept de modelare 
care reuneste elemente de structura, elemente de comportare si elemente semantice.

Exista mai multe categorii de clasificatori:
- Clasa (class)
- Tip de date (type)
- Interfata

O clasa in UML reprezinta o multime de elemente de aceealsi tip care sunt caracterizate prin structura 
data de atribute, comportarea data prin metode si pentru care se poate identifica un inteles precis 
(caracterul semantic)

UML OO
Class Class
atribut atribut

Principiul incapsulaii transforma clasa in structura cu atribute+implementare si comportare data de 
atributele metodelor publice ‐ interfata clasei.
O clasa in def din UML corespunde unei clase din OO. Ea corespunde unui tip de entitate sau unei 
multimi de entitiati. Atributul entitatii corespunde atributului din UML.
Desi definitile UML sunt mai generale, in anumite situatii se observa o foarte buna echivalare cu 
notiunile cunoscute din programarea OO. 

Reprezentarea in UML:
- 3 compartimente ale unui dreptunghi
ƒ Numele clasei + alte specificatii (compartiment obligatoriu)
□ Numele clasei (obligatoriu)
□ Un stereotip

APOO Curs Page 7

 □ Constrangerile
Persoana Persoana
(stereotipul si constrangerile sunt facultative)
ƒ Compartimetul de atribute (optional)
□ Nume atribut ‐ tip atribut: ‐Nume:String
‐Varsta:integer
 Tip generic (UML) ‐adresa:string Persoana
 Specific limbajelor OO
□ Indicator de vizibilitate
□ "+" ‐ public +Set nume:void
+Get nume:string
□ "‐" ‐ private +set Nume:string
□ "#" ‐ protected
legatura
ƒ Compartimentul de metode (optional)
□ Nume metoda (obligatoriu)
□ Indice vizibilitate Nota
□ Tip returnat Stereotip pt structura

- Clasa reprezinta forma implicita a unui clasificator <<type>>
Dimensiune
- Type si interfata necesita stereotipuri de precizare a clasificatorului. 
- Interfata este o colectie de metode (3 modalitati de reprezentare)

<<interface>> Itranzaction
Itranzaction +begin():void
+commit():void Itranzaction
+abort():void
<<interface>> Componente 
software

O componenta software in UML e o extindere a clasificatorilor
Forma
Pentru clase mai apar si constrangeri {abstract] Clasa abstracta

2. Clase parametrizate (clase template). O clasa template e o clasa care defineste o comportare unica 
pentru tipuri diferite de date. Tipul datei este un parametru.  In cazul stivei, tipul LIFO reprezinta un 
parametru:

E
Tstiva

‐element[n]:E
‐dim:integer
‐poz:integer

+push():void
+pop():E

Clasificatorii cu diversele constrangeri reprezinta elemente de structura din diagrama structurala.

Elemente de legatura (din diagrama claselor)

- Este un element care realizeaza o corespondenta (legatura) intre clasificatori si alte elemente)
- Elementrul se repreznta prin unul sau mai multe segmente de dreapta + diferite marcaje (acestea 
depind de tipul legaturii):
○ Linie intrerupta
○ Sageti
○ Diverse texte pe linie sau la capete
- Tipuri de legaturi UML:
○ Generalizarea (generalization)
○ Asocierea (asociation)
○ Depndentele (dependecies)
○ Alte legaturi

APOO Curs Page 8

1. Generalizarea:

- Este legatura dintre 2 clasificatori in care un clasificator numit fiu mosteneste caracteristicile 
clasificatorului numit parinte si adauga noi caractere specifice acestuia. Generalizarea este deci legata 
de MOSTENIRE.

vehicul

automobil    tractor   bicicleta

generalizare

Reprezentarea legaturii:

Sageata continua

Se pot definii ierarhii de clase pe oricate niveluri. 

- Se poate definii o ierarhie printr‐un procedeu invers (prin specializare). Specializarea e operatia inversa 
prin care se pleaca de la o clasa cu caracter general si se merge spre clase mai specializate (exista suport 
in limbajele OO pentru mostenire si deci nu se mai fac specificari in UML)

2. Legatura de asociere

- Prin asociere se realizeaza corespondente(legaturi) intre elementele diferitilor clasificatori. 
In UML un obiect este o instanta a unei clase (clasificator). Nu exista suport specific pentru asociere in 
limbajele OO.  Se folosesc diferite mecanisme care sa asigure asocierea.

Clasificari ale asocierilor:
I. Din punct de vedere al numarului de clase (clasificatori) pusi in corespondenta:
a. 2 clasificatori ‐ asocieri binare
b. >2 clasificatori ‐ asocieri multiple; n‐are ‐> pot fi restranse in asocieri binare
II. Din punct de vedere al raportului de cardinalitate
III. Din punct de vedere semantic (al intelesului). Din punct de vedere semantic exista:
a. Asocieri simple
b. Asocieri de tip parte intreg (intreg parte ??)

II. Clasificarea din punct de vedere al raportului de cardinalitate

1) Asocieri de tip unul la unu  1:1. Ele reprezinta asocierea prin care unui element din prima multime ii 
corespunde un singur element din a 2‐a multimea.
2) Asocierea unul la mai multi  1:N. Asocierea prin care unui elem din prima multime ii corespund mai 
multe elemente din a 2‐a multime dar nu si invers
3) Asocierea multi la multi

APOO Curs Page 9

 x y
x y 1:1
x y

x y
y
y 1:N
x
y

x y
x y M:N
x y
y

Prin cardinalitate sau multiplicitate se intelege numarul de elemente a unei asocieri fata de unul din 
clasificatori (sau multime de elemente) este egala cu numarul de elemente din acel clasificator care pot 
fii legate la un element din celalalat clasificator

Raportul de multiplicitate ‐ criteriu de clasificare.
- Asocierile multiple se reprezinta prin mai multe rapoarte de cardinalitate sau de multiplicitate. 
- Reprezentarea asocierilor: asocierile in uml se reprezinta prin unul sau mai multe segmente contiunue, 
intre clasificator  (asocieri binare)

Rol            numeasoc                  rol

  Class 1 0...1                                               1...*   Class 2

Marcaje pe asocierile binare UML
a. Numele asocierii (facultativ)
b. Multiplicitatile fata de fiecare clasificator. Se scriu la capatul liniei. Conceptul am avut 1:1, 1:N, 
M:N; In UML:
i. min...max
0            1
1           val

c. Rol ‐ rolul clasificatorului in asocierea respectiva (se reprezinta tot la capete)
d. Navigabilitatea ‐ posibilitatea de a ajunge de la un element dintr‐o clasa in cealalata. Ea poate sa 
fie unidirectionala si se reprezinta cu o sageata. Ea poate sa fie bidirectionala sau neprecizata. 

Exemple de asociere:
a) 1:N (generic)
Intreprindere Angajator          angajari            angajat Persoana
1...1                                              1...*

APOO Curs Page 10

 Daca se impune conditia ca o persoana sa lucreze intr‐o singura inntreprindere ‐ asocierea este 1:N. Se 
pot da mai multe variante de multiplicitate in functie de diferitele precizari ale modelului

b) M:N 

Profesor Student
*                                                              *
1...10                                         1...1000

c) Asocierile multiple. Ele se reprezinta folosind un romb cu linii

Clasificarea din punct de vedere semantic a asocierilor:

1) Asocieri simple = asocieri in care elementele asociate au existenta proprie, independent de asociere si 
de elementele din clasificatorul cu care are loc asocierea.
2) Asocierile de tip intreg‐parte sunt asocierile (in general binare) in care exista un clasificator cu rol de 
intreg si unul sau mai multi clasificatori cu rol de parte (parti) [general].  Pot exista si 2 sau mai multi 
clasificatori intreg fiecare cu 2 sau mai multi clasificatori de tip parte.
a. Asocieri de tip compozitie
b. Asocieri de tip agregare 

APOO Curs Page 11

 APOO Curs 4
20 martie 2007
10:20

Legaturi de asociere

- Au abordari mai putin fixe (precizate) (fiecare limbaj are toolset‐uri proprii
- La nivel UML avem asocieri
○ Simple
○ Tip intreg‐parte

Rapoarte de multiplicitate: 1:1; 1:N; M:N;

I ‐ asocieri simple ‐> clasificator e de sine statator; pot exista asocieri; este cea mai slaba in sensul 
legaturii care exista intre cei 2 clasificatori

I. Asocierea de tip intreg‐parte
a. Compozitie
b. Agregare
- Legaturi intre clasificatori dintre care un clasificator are rolul de intreg (exprima o entitate complexa) si 
una sau mai multe entitati complexe care reprezinta parti ale intregului
- Pot avea unul sau mai multi clasificatori cu rol de intreg
1) Compozitie ‐> are urmatoarele caracteristici:
a. Obiectul de tip intreg este compus din obiecte de tip parte
b. De regula obiectul de tip intreg nu poate exista fara obiectele de tip parte
c. (de regula) un obiect parte apartine unui singur obiect intreg (la un moment dat)
d. Este (in general) heterogena (exista clasificatori diferiti ca parti ce intra in combinatie pentru a 
forma intregul)

Reprezentare UML

Masina Club
0...*

1                               1                                      4
0...*
Caroserie                       Motor                              Roata Persoana

M:N

Legatura de compozitie este cea mai puternica legatura de asociere din cele existente.

2) Legatura de agregare
- Este legatura care stabileste corespondenta intre grupuri de instante ale clasificatorilor asociati.
- Clasificatori care reprezinta:
○ Grup
○ Membrii ai grupurilor
- Caracteristici:
○ Este de regula de tipul M:N dar poate fii si 1:N (caz particular)
○ O instanta a clasificatorului grup care reprezinta un intreg poate exista si fara membrii sai. 
○ O instanta a clasificatorului poate fii asociata mai multor grupuri
○ Legatura este de regula omogena.

APOO Curs Page 12

 Padure
1

0...*
Copac

1:N

Clasificarea unei asocieri ‐‐‐> depinde de interpretarea data de dezvoltator

Legaturile de dependenta

- Dependentele pot sa fie de mai multe feluri. Ea este legatura prin care un clasificator numit client 
depinde de un alt clasificator numit target (supplier)

Client                                           Furnizor   

uses
Clasa1                                          Clasa 2  

Tipuri de dependenta:
1) Legatura de utilizare (stereotip <<uses>>)
a. Folosim obiecte din clasa furnizor in implementari de metode
b. In argumente ale metodei clasei client
2) Legaturi de coeziune. 
a. Clasificatorul template ‐> clasificatorul tipului de date folosit

tip
Cl. Template             Cl. Tip             <=> Template

3) Legatura de trasare (stereotip <<trace>>)
a. Intre clasificatori care reprezinta acelasi concept pe niveluri de dezvoltare diferite
Preprezinta evolutia soft din punct de vedere al versiunii 
4) Legatura rafine (stereotip <<reffine>>)
5) Legatura de realizare. Ea se refera la faptul ca un anumit concept este specificat prin intremediul altui 
concept sau instanta.
a. Poate fii legatura intre interfata si clasa
b. Poate fii legatura de instantiere inre clasa si obiectul din acea clasa

Reprezentare aleternativa:
<<Interface>> <<interface>>
Interfata 1 Clasa 1

<<realizare>>

Cl d ifi

APOO Curs Page 13

 Interfata 1

<<realizare>>

Clasa de specificare
Clasa de specificare
Obiect 1

Obiecte si diagrame ale obiectelor
         Punct
- In UML, un obiect este o instanta a unei clase ‐x:float
- Reprezentare: ‐y:float

‐getx():float
...

             P1:Punct

x:float = 1
y:float = 1

Diagrama obiectelor:
- Graf, obiecte la un moment dat
- Legaturile dintre obiecte: instante ale legaturii din clasele instantiate

Diagrama obiectelor este considerata un snapshot. De cele mai multe ori ea este inlocuita cu alte 
diagrame.

Ex: Profesor                                                 Student

p1 s1

p2 s2

p3 s3

Diagrama obiectelor poate contine si clase!

Exemplu ‐ diagrama claselor. (Ele nu trebuie sa fie detaliate)

APOO Curs Page 14

 1
P1 * Cerc
-End9
-End10

Class1 *

-End12 1
1 S1
-End11
Class2 *
-End13

-End14

Implementarea claselor si a legaturilor dintre elemente

- Scrierea programului intr‐un limbaj obiect orientat.
- Detalierea diagramelor UML

I. Scrierea programelor ‐ implementarea aplicatiilor soft in modelul OO pornind de la UML
1) Implementarea claselor:
Class(UML) ‐‐‐> class(OO)
<<interface>> ‐‐‐‐> in functie de limbaj unei interfete ii corespunde tot o clasa sau tipul interface
2) Implementarea legaturilor ditre clase.
a. Legatura de generalizatedevine legatura de mostenire in limbaje OO
Class Culoare{
Int r;
Int g;
Int b;
Public:...};
Class punct{
Float x;
Float y;
Public:....};
Class forma{ //clasa abstracta deoarece contine functii virtuale pure
Culoare culoare;
....
Public:
Virtual float aria()=0;
Virtual float perimetru()=0; //functii virtuale pure

Class cerc:public forma{

Punct centru;
Float raza;
Public:
Int intersectie(segment s);
..... };

Class segment:public forma{

Punct p1;

APOO Curs Page 15

 Punct p2;
Public:.... };

Class poligon:public forma{

Punct varfuri [max];
Int nr_varfuri;
Public:.... };

b. Implementarea legaturilor de asociere
i. Asocierile de compozitie ‐ compunerea claselor
1) Variabile de tipul clasei "parte"
a) Obiecte incluse in clasa intreg
b) Pointeri sau referinte la obiecte din clasa parte: in Java sunt numai referinte, in 
C# de regula referinte iar in C++ putem avea ambele
Diagrama claselor mai detaliate (in etapa de implementare)

APOO Curs Page 16

 APOO Curs 5
27 martie 2007
10:08

Implementarea claselor (UML) si a legaturilor dintre acestea

Clasa(UML) ‐‐‐‐> clasa in limbaj OO
Legaturile dintre clase:
- Generalizarea (UML) ‐‐‐‐>clase derivate in limbaje OO
- Asocierea (UML)
ƒ Compozitia ‐‐‐‐> obiecte ca date membre de clase sau referinte la obiecte
ƒ Simpla, de agregare
□ Variabile de asociere
□ Clase de asociere

I. Variabile de asociere
Ex:

#define max 100

Class Student;
Class Profesor{
Char *nume;
Student *lista_studenti[max];
Int nr_studenti;
//ultimele 2 informatii reprezinta variabila de asociere care poate fii o lista
//inlantuita sau o alta structura de date cu o asemenea legatura. Variabila se
//numeste variabila de asociere
public:
Profesor (char *n){
New char[strlen(n)+1};
strcopy (nume, n);
nr_studenti=0;
}
void addStudent(Student *s){
//presupunem ca lista este de tipul LIFO; presupunem ca nr_studenti este
//prima locatie libera
if(nr_studenti<max){
lista_studenti[nr_studenti]=s;;
nr_studenti++;}
else {tratare eroare depasire}
}
void getStudent(){
if(nr_studenti>0){
nr_studenti....
}
else{tratare eroare depasire}
}

Class Student{
Char *nume;
Profesor *lista_profesori[max]; //pot fii si referinte
Int nr_profesori;
//Variabila de asociere care permite directia de navigabilitate student ---->
//profesor
public:
Student(char *n){
nume=new char[strlen(n)+1];
strcopy(nume,n);
nr_profesori=0;
}
//functii de asociere
void add_Profesor(Profesor *p){
if(nr_profesor<max)
lista_profesori[nr_profesori]=p;
nr_profesori++
else{eroare}
}

APOO Curs Page 17

 Profesor *getProfesor()
if (nr_profesori>0){
nr_profesori--;
return lista_profesori;
}
else{.........}
}

int main(){
profesor *p1=new Profesor("prof1");
profesor *p2=new Profesor("prof2");
profesor *p3=new Profesor("prof3");
Student *s1=new Student("stud1");
Student *s2=new Student("stud2");
Student *s3=new Student("stud3");
Student *s4=new Student("stud4");
//Obiectele sunt de sine statatoare; Asocierea se face folosind diverse metore ale
//claselor

-End4
s1 : Student
-End3 *

p1 : Profesor -End5
* -End6
* -End10 s2 : Student
* -End7 -End9 *
p2 : Profesor -End11 *
* -End12
* -End14
-End8 s3 : Student
-End13 *
p3 : Profesor -End15 **
* -End16
* s4 : Student
*

Fiecare legatura este creeata de addStudent si addProfesor la fiecare obiect in parte

OBS:

Exemplul de mai sus reprezinta o asociere simpla M:N bidirectionala. Faptul ca e asociere simpla nu 
difera de situatia in care am avea o agregare. 
Directionalitatea asocierii  ‐‐‐‐> daca este bidirectionala avem variabile de asociere in ambele clase. Daca 
este unidirectionala, atunci avem nevoie de o variabila de asociere numai in clasa de origine a sagetii de 
navigabilitate. 

Variabilele de asociere sunt de regula vectori de pointeri la clasa asociata (sau referinte). Putem avea 
liste inlantuite sau orice alte structuri.

Din punct e vedere al raportului de multiplicitate:
a) M:N ‐‐‐‐> se folosesc vectori de pointeri in ambele clase (exemplul dat)
b) 1:N ‐‐‐‐> in clasa care are coeficientul de multiplicitate 1 avem un vector de pointeri si in a 2‐a 
clasa avem un pointer simplu. 

class Sectie;

APOO Curs Page 18

 class Angajat{
char *nume;
Sectie *s;
....
};

class Sectie{
char *nume;
Angajati *lista_angajati[max]
int nr_angajati;
....
};
c) 1:1 ‐‐‐‐> variabilele de asociere sunt pointeri

Clase de asociere
- Se folosesc in general pentru M:N

Implementare:
#define max 100

class Profesor{
char *nume;
public:....
}
class Student{
char *nume;
public:....
}
struct PS{
pointer *Profesor;
pointer *Student;
PS(Profesor *p1, Student *s1){
p=p1;
s=s1;
}
};

class APS{ //clasa de asociere

PS asocieri[max];//existenta a mai multor pointei pe fiecare element permite
//accesul sau din mai multe directii
int nr_asocieri;
public: //functii de asociere propriu-zisa
APS(){nr_asocieri=0;)
void addPS(PS i);
PS getPS();
}

int main(){
profesor p1=new profesor("prof1");
student s1=new student("stud1");
student s2=new student("stud2");
student s3=new student("stud3");
student s4=new student("stud4");
PS ps11(p1,s1);
asocieri.addPS(ps11);
PS ps12(p1,s2);

APOO Curs Page 19

asocieri.addPS(ps12);
....
return 0;
}

Mostenirea asocierilor

Cl Baza1 Cl Baza2

* *

Deriv1 Deriv2

* *

Clasele derivate mostenesc variabilele de asociere, metodele de adaugare a instantelor 
Ex:
class Profesor{
//cu var de asocirere
};
class Student{
//cu var de asociere
};
class ProfesorInvitat:public Profesor{
char *univ_de_unde_vine;
public:
ProfesorInvitat (char *nume, char *u):Profesor(nume){
univ_de_unde_vine=new char[strlen(u)+1;
strcopy(univ_de_unde_vine, u);
};
}
class StudentBursier:public Student{
float *bursa;
public:
StudentBursier(char *n, float b):Student(n){bursa=b;);
}
//in clasele derivate nu avem variabile de asociere.

ProfesorInvitat *p1=new ProfesorInvitat("prof1", "Univ1");

ProfesorInvitat *p2=new ProfesorInvitat("prof2", "Univ2");
StudentNursier *s1=new StudentBursier("stud1", 1000);
StudentNursier *s2=new StudentBursier("stud2", 1200);
//asocierea dintre student bursier si profesor invitat este o asociere mostenita.Nu
//ameplam nici o alta functie pentru a o implementa.
// p1 ----> addStudent(s1);
// s1 ----> addProfesor(p1);
.
.
.
.
}
Mostenirea+asocierile constituie un mecanism foarte putrenic de reutilizare a datelor in programarea 
obiect orientata.
Alt exemplu: MFC:

CDocument CView

0..1 0..*

CMyDoc CMyView

0..1 0..*
APOO Curs Page 20
 CDocument CView

0..1 0..*

CMyDoc CMyView

0..1 0..*

Este implementata prin variabile si functii de asociere.  Asocierea intre CMyDoc si CMyView este 
mostenita.

Implementarea legaturilor de dependenta.

1) Legatura de rafinare (<<rafine>>) ‐‐‐‐> nu se implementeaza intr‐un mod specific (no code);
2) Legatura de trasare (<< trace>>) ‐‐‐‐> nu se implementeaza nici ea (no code);
3) Legatura de conectare (<<bind>>) ‐‐‐‐> se implementeaza prin clasele template;
template <classE> class Tvector{.........};
4) Legatura de realizare
a) Instantierea obiectelor ‐‐‐‐>  
Class1

Object1

class X{...};
class X obx;
b) Legatura de realizarea a unei interfete de catre o clasa
«interface»
Interfata1
«uses»

ClasaY

Implementare Java:
Interface
clasay implements interfata{....};
C++: pt metoda: clasa abstracta - mostenire :-??
5) Legatura de utilizare
a) un ob dintr‐o clasa este folosit in alta clasa in functie de argument
class Cerc: public Forma{
.
.
.
}
public:
int intersectie(Segment s){
float panta=s.getPanta();
}
};
Punct

1 * * 1

Cerc Segment

APOO Curs Page 21

 Punct

1 * * 1

Cerc Segment

Observatie:

Pana acum am studiat diagrame ale claselor si obiectelor. Aceste diagrame sunt statice si reprezinta 
structura modelului (la nivel foarte detaliat)
Ulterior vom intalnii si alte diagrame de sctructura pe niveluri mai inalte
- diagrame de componente
- diagrame ale sistemeor si subsistemelor
- diagrame ale pachetelor

APOO Curs Page 22

 APOO Curs 6
3 aprilie 2007
10:01
Modelarea comportamentala (behaveior) a sistemelor.

- O alta vedere asupra sistemului software
- Ne da informatii despre comportarea elementelor sistemului (prin interactiuni intre elementele unui 
sistem)

Modelarea comportarii 
• La nivel generic ‐‐‐‐> comportarea intre clase, sisteme, pachete.
• La nivel de instante: intre obiecte, instante ale sistemelor si instante de pachete. 

Modelarea comportarii pe diferite niveluri de detaliere ale sistemului:
• Clase (clasificatori)
• Sisteme (si subsisteme)
• Pachete

Mod comportarii: un element trimite un mesaj unui alt element.  (interactiunea)
- In UML: un mesaj = un element comportamental care reprezinta o interactiune intre elemente ale 
modelului. (interactiunile dau functionarea sistemului)
Un mesaj implica 2 entitati:
• Client ‐‐‐‐> care cere o anumita actiune
• Server ‐‐‐‐> furnizeaza un rezultat (al unei actiuni de regula).
- Agent = element care are atat rol de server cat si de client.
Mesaj 
• Ex: mesaj intre 2 obiecte = apelul unei functii a unui obiect de catre alt obiect (dintr‐o 
functie a obiectului client mai exact).
• Ex: intre subsisteme: trimiterea unui mesaj pe o retea; web browser trimite unu mesaj catre 
un web server
- Pentru trimiterea unu mesaj:
• Existenta unei legaturi intre elementele client si server care comunica. Orice legatura poate 
permite trimiterea unui mesaj: de asociere, de utilizare, de generalizare, etc.)
• Conditia de vizibilitate a serverului fata de client. Ex: serverul sa fie vizibil; adica sa fie accesibil, sa 
fie in acealas domeniu.
Exemplu:

class Punct{
float x;
public: Punct(float a, float b)
{x=a;y=b};
void move (float m, float n)
{x+=m; y+=n};
};
class Segment{
Punct p1;
Punct p2;
public: Segment (Punct a, Punct b){p1=a; p2=b};
void move (float a, float b){
p1.move(a,b);
p2.move(a,b);
} //clasa segment trimite un mesaj clasei punct - interact la nivel generic
//un obiect din clasa segment trimte un mesaj unui ob din clasa punct -

APOO Curs Page 23

 //nivel de instanta
float getPanta(){........};
class Cerc{
Punct cemtru;
float raza;
public: Cerc (float cx, float cy, float r):centru(cx,cy){raza r;}
int intersectie (Segment s){
float panta=s.getPanta();
/*legatura de utilizare (Cerc, Segment) este un mesaj intre clasa cerc si clasa
segment; el este reprezentat de apelul functiei getPanta*/

Reprezentarea in UML a interactiunilor intre elemente ale sistemului se poate face in 2 feluri:
- prin diagrame de colaborare
- prin diagrame de secventa a mesajelor

Diagrame de colaborare:
• la nivel generic
¾ intre clase
¾ intre subsisteme
¾ cazuri de utilizare

• la nivel de instanta
¾ intre obiecte
¾ intre instante de subsisteme
¾ intre cazuri de utilizare, etc.
void main(){
Punct p1(1,2);
Punct p2(4,5);
Segment s1(p1,p2);
s1.move (7,8)
Punct c(100,200);
Cerc c1(c,10);
c1.intersectie(s1);
}

Diagrama de secventa a mesajelor:
Segment Punct

move

APOO Curs Page 24

 Segment Punct

move

lifeline

Ordonarea temporara a mesajelor este implicita in diagrama de secventa amesajelor deoarece axa 
verticala reprezinta timpul. 
Diagramele de secventa a mesajelor sunt mult mai utile si mult mai intuitive. 

ob1 ob2 ob3 ob4

APOO Curs Page 25

 ob1 ob2 ob3 ob4

Cele 2 reprezentari sunt similare

Diagrame de stare

Se refera la starile prin care trec obiectele instante ale unei clase. 
- o satare este o colectie bine definita de valori ale atributelor.
- trecerea se face prin tranzitie. O tranzitie are loc intre 2 stari si are loc de regula ca urmare a unei 
activitati.
Daca starile prezinta valori cu semnificatii diferite de la o valoare la alta, atunci putem avea nevoie de 
astfel de reprezentari. Ex:
motor:
• pornit
• oprit
Cele 2 stari pot fi date de turaitie (comparatie fata de 0)

Tranzitia de la o stare la alta

Ex: Diagrama de stare a unui proces (gestionat de SO): stare

lansare
Aparitia
eveniment
ului
Gata de executie

planificare prelevare Blocat

Asteptare
Executie
eveniment
extern

Diagrama de activitate

APOO Curs Page 26

Se reprezintasecventa activitatilor care asigura rezolvarea unei anumite functiuni [elementul UML 
corespunzator organigramelor folosite inainte de UML]
Ea se compune din:
a) o stare de ctivitate ‐ ea reprezinta o procedura care se executa pentru a realiza ceva anume. 

b) tranzitii ‐ treceri intre stari de activitate ce au loc in cursul rezolvarii functiunii respective
Activitate

Activitate 2

c) Decizie (branch)
Activitate

Activitate 2

State1 State2

d) Elemente de executie concurenta

State3 State4

Ex: diagrama de activitate "Livrare Produs"

Primire ordin de livrare

Inregistrare ordin Trimitere factura

Primirea facturii

Livrare de noapte Livrare zi

APOO Curs Page 27

 Primire ordin de livrare

Inregistrare ordin Trimitere factura

Primirea facturii

Livrare de noapte Livrare zi

Inchidere ordin

- Modelarea structurala (clase, obiecte.....) ‐‐‐‐> vedere structurala
- Mocelarea comportamentala (instante.....)
- Modelarea utilisarii sistemelor
use‐case (cazuri de utilizare)
• vedere a sistemului din punct de vedere al utilizarii
• recomandate pentru a stabilii cerintele  de dezvolatare ale unui sistem
• Diagrame use‐case
¾ la nivel generic
¾ le nivel de instante
- de structuri
- de componente

a) Actor
- un set de roluri pe care il poate juca un element al ansamblului
- tip "actor" (generic)
- instanta a unui tip
- Un actor poate fii o persoana sau un alt sistem care utilizeaza sistemul dat. Poate reprezenta chiar 
un eveniment de timp!
b) Cazul de utilizare (context de utilizare; use‐case)
- un caz de utilizare reprezinta un set de functiuni pe care un element il ofera actorilor. Se 
reprezinta printr‐un cerc in care apare denumirea cazului de utilizare

c) Legaturi:
- intre actori
- intre use‐case‐uri
- intre actori si use‐case‐uri

APOO Curs Page 28

 APOO Curs 7
17 aprilie 2007
09:59

Modelarea utilizarii

- Use‐case
- De regula este foarte utila
○ mai ales in faza de stabilire a cerintelor
○ pentru utilizatori care nu sunt interesati de structura sistemului ci de utilizare.
- Entitati:
○ Actorii (un set de roluri; poate fii o persoana sau un sistem)
○ Contexte de utilizare(seturi de functii sau functionalitati)
- Diagrama de utilizare in care se reprezinta actorii si contextele cu legaturile dintre acestia. Legaturile 
sunt mai speciale, ele specificand modul de utilizare (asemanatoare cu leg de asociere)

Alte legaturi posibile in cadrul modelarii utilizarii:
a) Legaturi intre actori: 
i. Generalizare
ii. Dependente
1) De utilizare (<<uses>>)
2) De instantiere

b) Intre contexte:
a) Generalizare
b) Dependenta
i. <<include>>
ii. <<extend>>
iii. De instantiere (<<instance of>>)

APOO Curs Page 29

 Extends si include au dir diferite. Ar putea fii considerate echivalente dar legatura de includere este mai 
puternica.

In cadrul functionalitatilor de modelarea a utilizarii se pot folosii:
- Diagrame use‐case ‐‐‐‐> modelare structurala
- Diagrame de interactiune ‐‐‐‐> modelare comportamentala

Furnizare bani

Client
Introducere card

Cerere Pin
Introducere pin

Cerere suma

Introducere suma

Eliberare card

Ca recomandare, un context de utilizare trebuie sa ofere functionalitati care sa corespunda unui scop al 
actorului . Toate actiunile mentionate mai sus alcatuiesc un scop.

Modelarea componentelor.

- Componente software: este o unitate de program (executabil)
- Ofera o anumita functionalitate printr‐o interfata
- Pot fi dezvoltate, achizitionate si utilizate independent
- Pot fi inlocuibile
- Impreuna duc la creearea softului bazat pe componente. 

O componenta este o extindere a notiunii de clasificator.
Experienta de programare a dus la necesitatea de a avea componente mai mari, cu mai multe functii. O 
componenta=o grupare de:
- La programare OO ‐‐‐‐‐> clase si obiecte
- La programarea non OO ‐‐‐‐> mai multe functii

APOO Curs Page 30

In cadrul modelarii componentelor:
- Reprezentare de diagrame a compenentelor (reprez structurale) ‐‐‐‐> exitindere a diagramei 
claselor
- Diagrame de interactiune (reprez modelare comportamentala) ‐‐‐‐> diagrame de secventa a 
mesajelor, diagrame de colaborare, etc
Diagramele pot fii de 2 tipuri:
- Generic ‐‐‐‐> tip componenta
- Instanta ‐‐‐‐> instante ale componentelor
Legauti intre componente 
¾ legatura de compozitie
¾ Leg de dependenta
ƒ Utilizare
ƒ Instantiere
Legatura de compozitie

Diagrame de interactiune

Object1 Component4 Component5

Actor1
Message1

Message2
Message3

Message4
Message5

Message6

Componentele pot fii deployed in noduri de calcul

Organizarea modelelor UML
- Reducerea complexitatii 
ƒ Grupare de elemente (ale modelului) 
□ Package (pachet)
□ Systems (subsisteme)
□ Model

APOO Curs Page 31

 ƒ Organizare ierarhica

1) Pachete
¾ Un pachet este o grupare de elemente ale modelului.  Elementele grupate de un pachet pot fii:

ƒ Clasificatori
ƒ Alte pachete
Diagrama pachetelor: pachetele + legaturile intre acestea.
Legaturile:
- De generalizare

- De compozitie
- De dependente ‐‐‐‐> de utilizare <<import>> sau <<uses>>
2) Subsisteme  (UML):
a) Este un pachet (grupare) de elemente; Organizare unui subsistem se face pre criteriul 
functionalitatii. 

«subsystem»
SubSystem1

Cel mai inalt nivel
b) Diagrame ale subsistemelor:
Subsisteme + legaturi de date:
¾ Legatura de compozitie (la fel ca la pachete, cu semnul +)
¾ Legaturi de utilizare posibile intre diverse subsisteme. 
¾ Legatura de compozitie ‐‐‐‐> duce la ierarhii de subsisteme

«subsystem»
SubSystem1

* 1 -End3
1 *
-End4
-End1
-End2

«subsystem» «subsystem»
SubSystem2 SubSystem3

1 1*
-End5
-End8
-End7
* -End6

«subsystem» «subsystem»
SubSystem5 SubSystem4

APOO Curs Page 32

 Controler

Specification elements ‐‐‐‐> options Realization elements

Specification

Model: o grupare (package) de elemente ale modulului
- Pe criteriul vederii (utilizarii) in cadrul proiectului

- Diagrame de modele: leg de compozitie
Putem avea ierarhii de modele sau ierarhii combinate: modele + subsistem

APOO Curs Page 33

 APOO Curs 8
24 aprilie 2007
10:10

Diagrame de deployment

- Nodurile retelei: calculatoare (host): din punct de vedere al rolului jucat in apl respectiva
- Elemente ale modelului (grupare): subsisteme, componente + leg de date dintre acestea

Diagrame:
- Generice
- Ale instantelor

Ex. de legatura intre elemente ale modelului:

Legatura de dependenta (in exemplul de mai sus)

Concluzii:
Modelare UML
1) Aplicatiile software mari nu pot fii dezvoltate oricum. Ele beneficiaza de o abordare sistematica in care 
sunt precizate diversele etapesi operatii care trebuiesc efectuate. Cea mai des folosita abordare exte cu 
ajutorul limbajului UML care poate fii folosit in toate etapele. 
a. UML e mai intuitiv
b. UML asigura compatibilitatea intre diferiti utilizatori si dezvoltator. 

Tehnologii de dezvoltare software (software engineering)

Printr‐o tehnologie software se intelege un ansamblu de limbaje, standarde, biblioteci, interfete, 
sisteme de dezvoltare, toolset‐uri, toate avand ca obiectiv dezvoltarea softului, inclusiv implementare 
(pana la testarea si executia programului)

Clasificarea unui numar de domenii:
I. Modul de abordare a dezvoltarii software
a. Dezvoltarea "from scratch" ‐ custom mode (se pleaca de la 0). Se folosesc cel mult niste biblioteci 
fara diverse alte componente. Se pot dezvolta aplicatii software mici. Avantaje: flexibilitate foarte 
mare si adaptare foarte buna la cerintele clientului. Dezavantaje: risc de piata, ce provine dintr‐un 
posibili timp de realizare ridicat ‐ eficienta scazuta. 
b. Dezvoltarea prin achizitie de produse software gata realizate.  Avantaje: risc de piata redus, timp 
de realizare mic si deci eficienta mare. Dezavantaje: flexibilitate redusa, adaptabilitatea este 
redusa ‐ se adapteaza cerintele la software nu software‐ul la cerinte, dificultate de intretinere, 
vulnerabilitate in fata concurentei. 

APOO Curs Page 34

flexibilitate

% soft cumparat

eficienta

% soft cumparat

c. Software bazat pe componente ‐ realizarea softului prin asamblare de componente software. 
i. O componenta software este o unitate de: productie, achizitie, asamblare (deployment) 
independenta de alte unitati.  
ii. O componenta software poate fii considerata si ca o unitate executabila. 
iii. Au interfete bine precizate care sunt denumite contracte (intre componenta si utilizatorii ei)
iv. Au avut o dezvoltare mai lenta decat alte componente (hardware)
Acest lucru provine din caracterul abstract al produselor software. Chiar definitia este 
controversata. Pana la ce nivel se merge cu compartimentarea? In momentul de fata exista 
o piata de componente a caror dezvoltare a avut loc mai lent dar ea exista. 
v. Componentele software au inceput ca si VBX ‐ visual basic controls ‐ componente folosite 
pentru dezvoltarea de interfete. 
vi. Dezvoltarea software‐ului bazat pe componente este o solutie intermediara intre cele 2 
extreme: Are un grad de flexibilitate mai mare decat soft‐ul cumparat, eficienta 
intermediara, etc. Alt avantaj: se pot combina solutii. Se poate cumpara o parte gata facuta 
lipita cu un soft propriu care impreuna sa prezinte toate cerintele dorite incluziv un anumit 
avantaj fata ce competitori. 
In realitate:
- Combinarea componentelor software nu este atat de flexibila deoarece depinde de 
producator. [compatibilitate redusa, mai ales intre producatori]
- Exista dezvoltari de componente pe baza catorva tehnologii. 

Clasificarea aplicatiilor din punct de vedere al numarului de statii pe care se executa.
1) Aplicatii locale ‐ desktop, nedistribuite; 
- 1 proces (unul sau mai multe) cu unul sau mai multe thread‐uri care se executa pe o 
singura statie. Nu apar comunicatii pe retea si deci aplicatia se rezolva local. 
- Exista diferite toolset‐uri de dezvoltare 
 MSDEV (bazat pe C++) care se sprijina pe biblioteca MFC ce permite dezvoltarea 
usoara ai interfetelor grafice prin intermedul Visual C++. Un framework = 
grupare de elemente care permite dezvoltarea unor anumite tipuri de aplicatii. 

APOO Curs Page 35

  JDK ‐ J2SE. Desi Java a fost dezvoltat pentru internet, el poate fii folosit ca 
modalitate de dezvoltarea a unui software local. 
2) Aplicatii distribuite: mai multe procese, posibil cu mai multe thread‐uri, care se executa pe 
mai multe statii interconectate printr‐o retea.
- Arhitecturi de dezvoltare a aplicatiilor distribuite:
 Arhitectura client server (pe 2 niveluri):

 Arhitectura client slab (pe 2 niveluri): Necesita un server puternic, este simplu 
de implementat, ofera o securitate puternica (toate operatiile se rezolva la 
server) si intretinerea este simpla. Dezavantaje: poate sa apara congestia 
serverului.
 Arhitectura client puternic (pe 2 nivele): Avantaje: serverul nu se 
congestioneaza. Dezavantaje: intretinere complicata (orice schimbare 
presupune schimbari la toti clientii), securitate mai slaba, etc.
- Arhitecturi pe mai multe niveluri:

Nivel de prezentare Logica aplicatiei Nivel de date.

retea retea

Sisteme de
Client Nivelul “business
gestionare a
logic”
bazelor de date

Rol de server – Aplication

server
Portiunea din mijloc, mai poarta si denumirea de middle‐ware.
Ex de aplicatie 3‐tier:
Aplicatie web in care avem clientul ‐ web browser ‐ care cere informatii de la un server web care la 
randul lui poate sa ceara date dintr‐un sgdb care personalizeaza sau specifica mai clar cerintele 
clientului web.

Nivelurile unei aplicatii multi tier sunt niveluri logice. Ele pot sa fie executate fiecare pe cate un 
host sau pot sa fie grupate
III. Tehnologiile de dezvoltare software
a. Tehnologii Microsoft ‐ pornind de la o viziune (Desktop) s‐a ajuns la aplicatii distribuite puternice 
(1985).
b. Tehnologia CORBA ‐ Comon Object Request Broker Arhitecture. Arhitectura porneste din 

APOO Curs Page 36

 perspectiva enterprise. 
1) In 1991, tehnologia a fost specificata de OMG (Object Management Group). Momentana s‐a 
ajuns la CORBA 3.0 denumita si CCM ‐ corba component model. 
c. Tehnologiile Java ‐1995 ‐ dezvoltata de Sun Microsystems pornita din perspectiva internet. Ea si‐a 
propus sa ofere solutii pt aplicatiile in internet. 
1) JDK ‐ Java standard edition care ofera in mare parte aplicatii desktop si aplicatii distribuite in 
diverse acceptiuni dintre care applet‐urile sunt folosite in internet. Exista un pachet java.net 
care permite comunicatia prin socluri si care poate sa fie folosti direct. Mai avem si pachetul 
java.rmi care pemite comunicatia in retea
2) J2EE ‐ Java enterprise edition. Enterprise inseamna distribuit. Acest pachet ofera suport 
pentru aplicatii distribuite atat in retea locala. Din pachetul J2EE fac parte EJB ‐ enterprise 
java beans care sunt componente software utilizate in relele locale si in internet servleti si 
JSP. Acestea din umra pot fii considerate componente software. Toate componentele sunt 
OO.
Se remarca o spirala de dezvoltare a tehnologiilor software. Se reiau anumite idei de la o tehnologie la 
alta.  Tehnologia CORBA este considerata internet unfriendly. Nu are prevazut un mecanism eficient de 
travesare a firewall‐urilor. 

Tehnologii Microsoft

- Dezvoltarea de aplicatii de tip desktop ‐ MSDEV
- Dezvoltarea aplicatilor distribuite:
○ Etapa COM‐DCOM. (Componente Object Model ‐ Distributed COM). Aceasta tehnologie este 
inglobata in sistemele de operare. A inceput in 1991 prin tehnologia OLE 1.0 ‐ object linking and 
editing 1.0. S‐a incercat legarea de aplicatii de tip desktop. In 1992 standardul introduce notiunea 
de componenta. IN1993 ‐ OLE 2; 1996 ‐ ActiveX ‐ tehnologia COM pentru internet; In 2000 ‐ com+
○ IN 2001 ‐ tehnologia .NET ‐ orientata pe aplicatii Internet (distribuita)
ƒ In 2002 .NET Framework 1.0; C#. Aplicatiile sunt orientate pe componente software. In .NET 
componentele software sunt mai inregimentate. Un ansamblu (o entitate dezvoltata 
in .NET) reprezinta o componenta software .NET

APOO Curs Page 37

 APOO Curs 9
15 mai 2007
10:12

Tehnologia Microsoft .NET

- Dezvoltata dupa anul 2003; Este directionata catre aplicatii distribuite; Inlocuim tehnologia COM, DCOM
- Principii .NET:
○ Interoperabilitaea intre diferite aplicatii
○ Integrarea limbajelor (in aplicatii se pot folosii mai multe limbaje diferite)
○ Este limitata la sistemele de operare de tip Windows.
- .NET Framework ‐ cadru de dezvlotare a aplicatiilor care permite dezvoltarea aplicatiilor in 
platforma .NET. Mai poarta si numele de platforma .NET

Web Services
Web Form\Windows Forms
Data & XML
Framework Base Clases (FBC)
Windows

Intre biblioteca si sistemul de operare mai apare si CLR ‐ partea executiva a programelor (.NET 
Framework). 
¾ Este echivalent cu o masina virtuala Java.
¾ Executa (controleaza executia) in limbaj intermediar IL (MSIL: Microsoft Internal Language)
¾ IL se obtin din compilarea resurselor: limbajele .NET:
ƒ C# (seamana si cu C++ si cu Java)
ƒ VB. NET
ƒ J#
ƒ Managed C++
Toate programele produc cod in limbaj IL

Sursa C#
Sursa J#

Managed module
IL

Singurul program diferit este Managed C++ care poate genera modul managed sau nu.

Managed module ‐ modul administrabil: IL si poate fii executat sub controlul CLR.
Un unmanaged module ‐ modul neadministrat ‐ poate fii executat direct de SO si este un modul in cod 
nativ (limbajul CPU pe care se lucreaza)

- Functionare CLR

APOO Curs Page 38

 Modul managed

incarcare

Managed IL

Verificare cod

Managed IL

Cod nativ
Compilat NU
managed

Garbage col
DA

executie
executie

Controlul executiei CLR
¾ Verificare de runtime
¾ "Garbage colector": obiectele din memoria libera sunt distruse. Executia este sigura pentru ca nu 
mai exista operatorul delete care genera probleme in C++

Organizarea progr. NET
¾ Compilator ‐ Modul(managed):
ƒ Codul IL
ƒ "Metadata": tabele care descriu tipurile definite in modulul respectiv
¾ Unitatea de executie, instalare, versionare si securitate este denumita ansamblu (assembly). Un 
ansamblu este unitatea care se poate instala. Un ansamblu poate sa contina 1 sau mai multe 
module. El are deci modulele propriu‐zise (care contin cod IL si metadata), diverse resurse si un 
manifest (care contine lista datelor). Un ansamblu este o componenta software. 

Exemplu HelloWorld:

//fisier sursa Hello.cs

using System;
class Hello{
public static void Main(){
Console.Writeline("HelloWorld");
}
}

Compilare csc Hello.cs
In urma acestei comenzi se creeaza Hello.exe (ansamblu continut in windows pe ‐ portable executable)
- Instalare CLR (.NET Framework)
¾ Se modifica loader‐ul  SO ai loader‐ul poate deosebii un PE in cod nativ de un PE in cod IL. 

In windows librariile poarta denumirea de dll (Dinamib Link Library)

a) C# este mai pur din punct de vedere al OO fata de C++. Nu admite metode si variabile globale. Med main 
cu care incepe executia devine o metoda statica a unei clase. Ea poate fii invocata fara instantierea 
clasei din care face parte.
b) Spatiile de nume
a. sunt grupari logice de entitati 
b. clase in care numele de identificatori sunt unice 
c. permit evitarea coliziunilor de nume.
d. spatiile de nume se pot grupa ierarhic

namespace Spatiul1{

APOO Curs Page 39

 .......
manespace Subspatiul1{
class Clasa1{
......
}
}
}

Numele unei clase: Spatiul1.Subspatiul1.Clasa1.
La utilizare, directiva using ne permite o utilizare mai simpla a spatiilor. Astfel Syste.Console devine 
Console

System
System.Collection
System.IO
System.Data
System.Winows.Forms
System.Web.UI
System.Web.Services

Tipurile de date .NET
- Integrarea limbajelor
○ tipuri comune CTS (Common Type Specifications)
○ tipuri impuse limbajelor numite CLS (Common Language Specifications)
○ fiecare limbaj defineste ca multimea tipurilor sale o multime care este o submultime a CTS si 
include CLS

CTS

VB .NET CLS
C++

C#

Clasificarea tipurilor distribuite din .NET
- Dupa modul de creere:
○ tipuri valoare
○ tipuri referinta
- Dupa locul de creeare:
○ tipuri definite in .NET
○ tipuri definite de utilizator.

APOO Curs Page 40

 Tip .NET C# Managed C++ Dimensiune
Byte byte unsigned char 8biti
Int32 int ins,long 32biti
Single float float 32biti
Char char ‐ 16biti
Boolean bool bool 1bit

Limbajul C#
Limbajul oficial al .NET
- Andreas Hejsberg, cott Wiltamuth
- C++, Java

Tipuri de date C#
I. Tipuri valoare
a. Tipuri primitive: int x=1;
i. se creeaza prin declaratie
ii. se creeaza in stiva
iii. nu avem referinte
b. Tipul enumerare ‐ defineste o colectie de valori constante. 
using System;
public class Class1{
enum Valori{
mica=1;
potrivita=2;
mare=3;
};
public void static Main(){
Console.Writeln ("Valori {0},{1},{2}",
Valori.mica,Valori.potrivita, Valori.mare);
}
}
Se afiseaza: Valori 1,2,3
c. Structuri:
//Fisier...
struct Locatie{ //implicit derivata din valuetype; nu permite derivarea.
intx;
inty;
public Locatie(int a, int b){
x=a; y=b;}
public override string ToString(){//override se refera la dominare
return "Locatie"+x+" "+y;
}
}
public class Program{
public static void Main(){
Locatie.l1=new Locatie(4,5);//returneaza valoarea - obiectul care se
//creeaza in stiva

APOO Curs Page 41

 System.Console.Writeln(l1.ToString);
}
}

Afiseaza: Locatie 4 5
Curs se continua cu laboratoarele .NET (7 si 8)
Exemplu clasa statica:
//Fisier statice.cs
using System;
public class Clasa{
private int x;
private const int c=10;//se poate initializa numai in declaratie o const
private readonly int r=2;//se mai poate initializa si in constructor
public static s;//ca in Java, nu in C++!!!
public Clasa(int a, intb, int c){x=a;r=b;s=c;}
public void inc(){x++;s++}//met nestatice pot accesa date membre statice si
//nestatice
public static void incs(){x++;/*da eroare*/s++;}
public override string toString(){
return "x="+x+"r="+r+"s="+s;
}
public class Program{
punlic static void Main(){
Clasa c1=new Clasa(1,2,3);
Console.writeline(c1);//toString de aici e mostenit din object insa daca
//vrem sa afiseze ceva anume se va face redefinirea. Se poate folosii
//Console.Writeln(c1.toString());
Clasa.s=5;
c1.inc();
Console.Writeline(c1);//afiseaza x=2r=2s=6
c1.incs();//eroare, nu se poate accesa metoda statica folosind un obiect
Clasa.incs();//corect
}
}

APOO Curs Page 42