POO

Modelare II

1
Cuprins
 UML
• diagrame de clase (continuare)
• cum modelam in UML
• cum implementam in C++
• diagrame de secventa (comunicare)
• diagrame de activitate

D. Lucanu POO – Principii 2

Ce am facut cursul trecut (Modelare I)
 clase

 ierarhii

 relatii de asociere

D. Lucanu POO – Principii 3

Relatia de agregare (compunere)
 arata cum obiectele mai mari sunt compuse din
obiecte mai mici
 poate fi privita si ca o relatie de asociere speciala
 exista doua tipuri de agregare
• agregare slaba (romb neumplut), cand o
componenta poate apartine la mai multe agregate
(obiecte compuse)
• agregare tare (romb umplut cu negru), cand o
componenta poate apartine la cel mult un agregat
(obiect compus)

D. Lucanu POO – Principii 4

Relatia de agregare tare

un contact apartine
la o singura agenda; o agenda poate avea
relatia de
stergere agenda => zero sau mai multe
agregare tare
stergere contact contacte
(compunere)

D. Lucanu POO – Principii 5

 Relatia de agregare (slaba)

un contact apartine la
una sau mai multe
relatia de o agenda poate avea
agende; un contact
agregare (slaba) zero sau mai multe
poate exista si dupa
stergere agendei contacte

D. Lucanu POO – Principii 6

Relatia de agregare in C++
 agregare tare (compunere)
class Agenda {
private:
Contact contacts[MAX];
}; container de obiecte
Contact (aici tablou)

 agregare (slaba) container de referinte la

obiecte Contact (aici
class Agenda { tablou de pointeri)
private:
Contact *contacts[MAX];
};

D. Lucanu POO – Principii 7

Containere STL
 sunt cele mai potrivite pentru implementarea relatiei
de agregare
 aici vom exemplifica numai utilizarea listelor in
proiectul Agenda
 mai multe despre STL se vor face in partea a doua
cursului

D. Lucanu POO – Principii 8

Containere STL
 container = un obiect care contine alte obiecte
(componentele) si are metode de accesare a
componentelor
 fiecare container are asociat un tip iterator cu ajutorul
caruia se "merge" prin container

Container Iterator
1 0..*
1

Componenta

D. Lucanu STL – Partea 1 9

Contactele ca liste STL in Agenda
 agregare tare (compunere)
#include <list> header pt. listele
... STL
class Agenda {
private:
liste in care componentele
list<Contact> contacts;
sunt obiecte Contact
};
 agregare (slaba)
#include <list>
...
class Agenda {
private: liste in care componentele
list<Contact*> contacts; sunt pointeri la obiecte
}; Contact

D. Lucanu STL – Partea 1 10

Operatii asupra agendei - declaratie
class Agenda
acest exemplu
{ arata numai cum
private: sunt utilizate listele
list<Contact*> contacts; STL

public: adauga un contact

void AddContact(Contact *newContact);
public:
afiseaza agenda
void display();
public:
list<Contact*>::iterator findName(char *newName);
...
}; cauta un contact dupa un criteriu

D. Lucanu POO – Principii 11

 Adaugarea unui contact si afisare ag.
void Agenda::AddContact(Contact *newContact)
{
contacts.push_back(newContact);
} declarare iterator cu care se
insereaza un element refera componentele listei;
la sfarsitul listei utilizarea lor e similara cu
cea a pointerilor
void Agenda::display()
{
list<Contact*>::iterator i;
for (i = contacts.begin(); i != contacts.end(); ++i)
cout << (*i)->toString() << endl;
}
schema de parcurgere a referirea unei componente a
unei liste listei cu ajutorul iteratorului

D. Lucanu POO – Principii 12

Cautarea in agenda
 ar trebui sa permita cautarea dupa mai multe criterii
 ... ihm, cam complicat ...
 mai bine cautam prin documentatia STL sa vedem
daca gasim ceva

D. Lucanu POO – Principii 13

Din documentatia STL
find_if
aha!
Category: algorithms
Prototype
template<class InputIterator, class Predicate>
InputIterator find_if(InputIterator first,
InputIterator last,
Predicate pred);
Description
Returns the first iterator i in the range [first, last) such
that pred(*i) is true.
Returns last if no such iterator exists.
Definition Defined in the standard header algorithm
D. Lucanu POO – Principii 14
Cautarea dupa nume
class Agenda { declarare data
... membra declarare functie
statica membra statica
private: static string buffer; (criteriul de cautare)
private:
static bool eqName(Contact *contact) {
return contact->getName() == buffer;
}
functia de cautare
}; intoarce un iterator
list<Contact*>::iterator
Agenda::findName(char *newName) {
buffer = string(newName); apel functie
return find_if(contacts.begin(), statica
contacts.end(), Agenda::eqName);
}
D. Lucanu POO – Principii 15
D. Lucanu POO – Principii 16
C++ intermezzo
 membri statici
• pot fi date (variabile) sau functii
• variabilele statice sunt numite variabile de clasa
deoarece au valoare unica pentru toate obiectele
clasei; au un rol asemantor cu cel al vriabilelor
globale, dar se bucura doar de domeniul de
vizibilitate al clasei
• functiile statice pot, eventual, accesa numai
variabile statice (nu pot avea acces la starea
particulara a unui obiect)

D. Lucanu POO – Principii 17

C++ intermezzo
 membri statici - exemplu
• o variabila care memoreaza numarul de obiecte
create trebuie sa fie unica pentru toate obiectele
clasei => variabila statica notatii
variabila unica pt echivalente
class Bare toate ob. clasei int main () {
{ Bare a;
private: Bare b[5];
static int n; Bare * c = new Bare;
public: cout << a.getN() << endl; 7
Bare () { n++; }; delete c;
~Bare () { n--; }; cout << Bare::getN() 6
static int getN() << endl;
{ return n; } return 0;
}; }
initializare variabila
int Bare::n=0; statica

D. Lucanu POO – Principii 18

Componente si relatii de dependenta

relatie de
component dependenta
a
D. Lucanu POO – Principii 19
Principiul de inversare a dependentelor

 A. “Modulele de nivel inalt nu trebuie sa depinda de

modulele de nivel jos. Amandoua trebuie sa depinda
de abstractii.”

 B. “Abstractiile nu trebuie sa depinda de detalii.

Detaliile trebuie sa depinda de abstractii.”

 programele OO bine proiectate inverseaza

dependenta structurala de la metoda procedurala
traditionala
• metoda procedurala: o procedura de nivel inalt
apeleaza o procedura de nivel jos, deci depinde
de ea
D. Lucanu POO – Proiectarea de clase 20
Principiul de inversare a dependentelor

Agenda nu trebuie sa depinda de

modul particular de definire a
contactelor (prieteni, colegi,
amici ...); toate depind de abstractia
Contact

D. Lucanu POO – Principii 21

Princip. de inversare a dependentelor si MVC
Elimina dilema “oul sau
gaina” pentru view si
controller

D. Lucanu POO – Principii 22

Princip. de inversare a dependentelor si MVC
 Ce include clasa abstracta View?
• orice fereastra are display-boxuri, edit-boxuri,
meniuri ... => o metoda create() (virtuala pura)
• elementele display-box pot fi actualizate => o
metoda update() (vida - de ce?)
• elementele ferestrei trebuie afisate => o metoda
display() (virtuala pura), care va fi resp. si cu
treansmiterea evenimentelor catre controller
 Ce va inlcude clasa abstracta Controller?
• doar implementarea relatiei de asociere

D. Lucanu POO – Principii 23

Clasele View si Controller revizuite
class View
{
public:
virtual void create() = 0; // pure virtual method
virtual void update() {}; // empty method
virtual bool display() = 0; // pure virtual method
};
class Controller
{
protected: doar implementarea
View *view; relatiei de asociere
public:
void setView(View *newView);
};
D. Lucanu POO – Principii 24
Clasa ViewAgenda revizuita
class ViewAgenda : public View
{
private: noile relatii de asociere
Agenda *model;
ControllerAgenda *controller; continut fereastra

DisplayBox<string> dbOwner;
Menu menu;
public:
ViewAgenda(ControllerAgenda *newController,
Agenda *newModel);
void create();
void update(); implementarea operatiilor
bool display(); din clasa abstracta
};

D. Lucanu POO – Principii 25

Metodele create() si update()
void ViewAgenda::create()
{
construire meniu
menu.addOption("1. Afiseaza");
menu.addOption("0. Exit");
dbOwner.setLabel("Proprietar");
} display-box

void ViewAgenda:: update()

{
dbOwner.setValue(model->getOwner());
}

actualizarea singurului display-box

D. Lucanu POO – Principii 26

Metoda display() revizuita
bool display()
{
cout << "*** Agenda view ***" << endl;
update();
transmitere eveniment
dbOwner.display(); preluat de la utilizator
menu.display(); catre controller
if ((option = menu.getOption()) != 0)
{
controller->listen(option);
return true;
} indica sfarsitul rolului
else acestui view
return false;
}

D. Lucanu POO – Principii 27

Clasa ControllerAgenda revizuita
class ControllerAgenda : public Controller
{
private:
Agenda *model;
public:
ControllerAgenda(Agenda *newModel);
void listen(int option);
void finish();
acum are ca parametru
};
mesajul primit de la viewer

D. Lucanu POO – Principii 28

intermezz0
 Inainte de a vedea implementarea revizuita a
metodei listen(), aruncam o privire asupra altei
instante MVC (functionalitatea Contact)
 celelalte instante vor fi implementate asemanator

D. Lucanu POO – Principii 29

Functionalitatea pt. un contact

Depoarece toate instantele sunt

similare, de ce sa nu definim o clasa
MVC?

D. Lucanu POO – Principii 30

 Clasa MVC
template <class M, class V, class C> public:
~Mvc() eliberare
class Mvc
Modelul, View-ul si { memorie
{
Controllerul sunt delete c;
private: parametri delete v;
C *c; V *v; M *m; } metoda
public: responsabila cu
Mvc(M *newM = 0) Crearea void run() executia
componetelor { controllerului
{
si a relatiilor while (v->display())
m = newM; {
c = new C(m); //nothing
v = new V(c, m); }
c->setView(v); }
}; afisarea viewerului este
} suficient pentru a declansa
comunic. intre obiecte

D. Lucanu POO – Principii 31

Metoda ControllerAgenda::listen()
void ControllerAgenda::listen(int option)
{
Mvc<Contact, ViewContact, ControllerContact>
mvcContact(model->getContact());
switch (option)
creare instanta MVC
{ pentru functionalitatea
... ce refera un contact
case 1:
mvcContact.run();
break; executie instanta
... MVC
}
}

D. Lucanu POO – Principii 32

D. Lucanu POO – Principii 33
Diagrame de comunicare
 la inceput au fost numite diagrame de colaborare
 se focalizeaza pe interactiunea dintre obiecte
 pot fi utilizate pentru a descrie cum sunt
implementate digramele cazurilor de utilizare
 din pacate ArgoUML are suport slab pentru
diagramele de counicare si de aceea ne vom ocupa
de diagramele de secventa
 o diagrama de comunicare poate fi generata automat
dintr-o diagrama de secenta si reciproc
 ... asa ca nu pierdem foarte mult daca facem numai
digramele de secventa

D. Lucanu POO – Principii 34

Diagrame de secventa
 arata interactiunea dintre obiecte
 obiectele sunt reprezentate ca “linii ale vietii” care
merg de sus catre josul paginii
 interactiunile sunt reprezentate ca mesaje trasate
sub forma de sageti de la linia vietii sursa la linia
vietii destinatie
 arata cum obiectele comunica unele cu altele,
punand in evidenta mesajele presupuse de aceste
comunicari
 nu sunt recomandate pentru reprezentarea unor
logici procedurale complexe

D. Lucanu POO – Principii 35

Diagrame de secventa

D. Lucanu POO – Principii 36

D. Lucanu POO – Principii 37
Diagrame de activitate
 afiseaza secvente de activitati
 o diagrama de activitate arata fluxul de lucru de la un
punct de start la unul final, evidentiind caile
decizionale luate in functie de evenimentele si
activitatile in progres
 sunt utile in modelarea domeniului problemei
(business modeling)

D. Lucanu POO – Principii 38

 Diagrama de activitate
stare de start

punct de
decizie
activitate punct de combinare

conditie

stare de
sfarsit (finala)

D. Lucanu POO – Principii 39

Diagrama de activitate

start activitati
concurente (fork)

activitati
concurente

sfarsit activitati
concurente
(joint)

D. Lucanu POO – Principii 40