PROGRAMAREA ORIENTAT OBIECT

CURS 13 - PROGRAMARE II

CURS ANTERIOR
Introducere n Standard Template Library Containere secveniale Containere asociative Adaptori ai containerelor Algoritmi String

CUPRINS
Procesul de dezvoltare software OOA UML

Modelul de programare orientat pe obiect

Introducere Concepte Structurarea obiectelor, atributelor i serviciilor Principii OOD

PROCESUL DE DEZVOLTARE SOFTWARE

MODELE DE DEZVOLTARE SOFTWARE

Waterfall: cel mai vechi, bine tiut, diferii pai (cerine, analiz, design, implementare, testare, etc) care sunt urmai n ordine V-model: introdus de administraia german; 2 fluxuri: specificaii (analiza cererilor, specificaii funcionale, specificaii de proiectare) i testare (instalare, operaional, performane) + implementare

Iterativ: dezvoltarea de software n iteraii mici; ajut la identificarea de probleme n fazele incipiente ale procesului de dezvoltare:
Spiral: combin modelele de prototipare cu cel waterfall Rational Unified Process (RUP) Agile Extreme Programming (XP) Scrum Rapid Application Development (RAD); Cleanroom: combin metode formale n fazele de definire a specificaiilor i design cu implementare incremental i testare statistic

Metode formale: abordri matematice pentru a rezolva problemele din specificaii, specificaii i nivelele de design (ex. B+method, Petri nets, AISE= Rigorous Approach to Industrial Software Engineering , VDM = Vienna Development Method)

ANALIZA ORIENTAT OBIECT

Definiie: Scopul OOA (Object Oriented Analysis) este de a modela domeniul problemei, problema pe care dorim s o rezolvm prin dezvoltarea unui sistem orientat obiect. Poate fi aplicat oricrui proces de modelare a dezvoltrii software Intrri: Cerinele (problema) Specificaiile (pot include diagrame de utilizare (use case) sau alte diagrame)

Ieirile:
Modelul conceptual Cazurile de utilizare Orice alt documentaie

ANALIZA ORIENTAT OBIECT

OOA nu se ocup de detaliile de implementare (structura bazei de date, modelul de persisten etc), acestea sunt decise n pasul OOD Notaii grafice Coad Yourdon Rumbaugh Booch Firesmith Embley Kurtz Etc

Unified Modeling Language (www.uml.org) (UML) standardul pentru OOA

Taskuri realizate n timpul analizei OOA Gsirea obiectelor Gsirea relaiilor dintre obiecte Definirea cazurilor de utilizare Definire UI

UNIFIED MODELING LANGUAGE

Diagrame comportamentale: diagrame care descriu comportamentul sistemului sau procesului de business.
Activitate State machine Use case Interaction

Diagrame structurale: depistez elementele specificaiilor care ar nu sunt transparente n acest moment
Class composite structure Component Deployment Object package diagrams

Diagrame de interaciune: o submulime de diagrame comportamentale care subliniaz comportamentul sistemului

communication interaction overview Sequence timing diagrams

OBJECT ORIENTED DESIGN

Definiie Object-oriented design (OOD) este o disciplin care definete obiectele i modul n care ele interacioneaz ca s rezolve probleme care au identificate i documentate n timpul analizei orientate obiect Face tranziia de la proiectarea produsului la dezvoltarea software (software arhitecture -> software development)

Intrrile pentru OOD

Ieirile OOA (Object Oriented Arhitecture) (modelul conceptual, diagrame de utilizare, documentaie UI, alte documente) Ieirile (deriverables/output) pentru OOD Diagrame de clas
Descriu structura stemului prin clase, cu atributele lor i relaiile dintre clase

Diagrame de secven
Schimbul de mesaje dintre anumite obiecte i ordinea n care se realizeaz

CONCEPTE OOD
Pai OOD Definirea obiectelor: identificarea atributului, comportamentului, serviciilor expuse de obiecte Crearea de diagrame din modelul conceptual Definirea framework-ului aplicaiei:framework-ul aplicaiei se refer la un set de biblioteci sau clase folosit pentru a crea structura unei aplicaii pentru un sistem de operare. Folosirea unui framework reduce timpul necesar scrieri de cod dezvoltatorului aplicaiei prin refolosirea funcionaliti standard. Identificarea obiectelor/datelor persistente: identificarea obiectelor care trebuie persistate. Dac sunt folosite baze de date relaionare acest pas este echivalent cu maparea obiect relaie Identificarea, definirea obiectelor remote Evaluarea limbajelor OO i alegerea celui mai potrivit Evaluarea proiectrii OO Definirea strategiilor de testare: testare unitar, testare non-regresiv, teste de integrare, etc. Cum se realizeaz

10

Pe baza experienei, bunului sim, folosind principiile OOD i abloanele de proiectare

STRUCTURAREA OBIECTELOR
Generalizare-specializarea ierarhiilor (is-a) folosirea motenirii pentru a grupa atribute i comportament comun regsit la obiecte Reuniunea tuturor specializrilor acoper generalizrile descrise? Se exclud reciproc specializrile? Exemplu: form, elips, punct Motenirea multipl
Tendina de a complica lucrurile Pot aprea conflicte ntre atribute similare, motenite de la clasele de baz Trebuie folosit cu grij Abordri gen Java: o singur reprezentare i implementarea mai multor comportamente

Ierarhii parte-ntreg(has-a)

Exemplu: persoana are 1 corp, 0 sau 2 brae, 1 cap, etc. o linie poligonal conine 2..N puncte ntregul nu motenete comportament de la pri => motenirea nu este aplicabil

11

ATRIBUTELE OBIECTELOR
Gsirea atributelor

Folosirea persoanei nti (personificare) Analizarea problemei, chestionarea clientului

Plasarea atributelor ntr-o ierarhie de clase care clas din ierarhie este mai potrivit pentru a conine atributul? Definirea domeniului atributelor, ex. care sunt valorile valide pe care un atribut le poate lua Relaiile dintre obiecte sunt implementate ca atribute, aceste fcnd parte din starea obiectelor n aceast faz, ierarhiile de clase sunt revzute Exemplu: un punct are 2 coordonate, denumite X i Y, care pot lua doar valori pozitive

12

COMPORTAMENTUL OBIECTELOR
Definiie: comportamentul descrie activitatea unui obiect. Un serviciu definete relaiile cu alte componente ale modelului Reprezentat prin diagrame UML de comportament i interaciune Posibil identificare: strile obiectelor i apoi explorarea sensului conexiunilor Au fost definite toate strile? Sunt toate strile tangibile? n fiecare stare, obiectul are comportamentul ateptat

13

SERVICIILE OBIECTELOR
Determinarea serviciilor necesare (=funcii membre) pe baza tipurilor lor: Servicii implicite: crearea de noi instane (constructori), destructori, metode de get/set etc (metode care nu sunt incluse n diagrame de obicei) Servicii asociate cu conectarea mesajelor: identificarea mesajelor trimise obiectelor n stri anterioare i adugarea de servicii care s le trateze; pot fi sugerate de diagramele de comportament Servicii asociate cu relaiile obiectelor: activeaz/deactiveaz relaiile dintre obiecte (relaiile sunt identificate n faza de proiectare OOA) (ex. Poligoanele conin Puncte => adugarea/tergerea/modificarea de puncte obiectelor poligon) Servicii asociate cu atributele: protejeaz anumite atribute, modific un atribut doar mpreun cu alt atribut, sincronizare n timp real etc.

14

SERVICIILE OBIECTELOR
Mesajele sunt schimbate ntre obiecte pentru a executa servicii complete Reprezentare grafic

Ca funcii membre n diagramele de clase Conectori ai mesajelor n diferite diagrame de interaciuni (colaborare/secven, comunicare, interaciune etc) Implementate ca i funcii membru publice

15

PRINCIPII OOD
Definiie Un principiu de proiectare este un principiu sau utilitar de baz care poate fi aplicat pentru proiectarea sau scrierea de cod mai uor de ntreinut, flexibil sau extensibil Principiile OOD OCP DRY SRP LSP

16

OPEN-CLOSE PRINCIPLE (OCP)

OCP: clasele ar trebui s fie deschise pentru extensii dar nchise pentru modificare Permite schimbri fr a modifica codul existent Folosirea motenirii pentru a extinde/schimba codul funcional existent i a nu se atinge de codul care funcioneaz Poate fi implementat i prin intermediul compoziiei
class Shape { int type; void drawPolygon () { /* ... */ } void drawPoint () { /* ... */ } public: void draw(); }; void Shape::draw() { switch(type) { case POLYGON: drawPolygon (); break; case POINT: drawPoint (); break; } } }; class Point : public Shape { public: void draw(); }; class Polygon : public Shape { class Shape { public: virtual void draw() = 0;

NOK

public: void draw();

OK

};

void Point::draw() { /* ... */ }

17

void Polygon::draw() { /* ...*/ }

DONT REPEAT YOURSELF (DRY)

DRY: evitarea codului duplicat prin abstractizarea lucrurilor comune i plasarea acestor lucruri ntr-o singur locaie Fr cod duplicat => O cerin ntr-un singur loc Acest principiu poate i ar trebui aplicat oriunde (ex. analiz s nu se duplice cerine sau features) Codul este mai uor de ntreinut i mai sigur deoarece realizm modificrile doar ntr-u loc

String::String(const char* pch) { if(pch!=NULL) { str = new char[(sz=strlen(pch))+1]; strcpy(str, pch); } else { str = NULL;

/*private*/ void String::init(const char* pch) { if(pch!=NULL) { str = new char[(sz=strlen(pch))+1]; strcpy(str, pch); }

sz = 0;
}} void String::set(const char* pch) { if(str!=NULL) delete [] str; if(pch!=NULL) { str = new char[(sz=strlen(pch))+1]; strcpy(str, pch);

NOK
}

else {

str = NULL;
sz = 0; }

String::String(const char* pch) { init(pch); }

} else {
str = NULL; sz = 0; }}

OK

void String::set(const char* pch) {

if(str!=NULL) delete [] str;

18

init(pch)

SINGLE RESPONSABILITY PRINCIPLE (SRP)

SRP fiecare obiect ar trebui s aib o singur responsabilitate , i toate serviciile ar trebui s se focuseze spre a a retransmite acea responsabilitate Doar un singur motiv pentru a modifica ceva Codul este mai simplu i uor de ntreinut Exemplu: containerele i iteratorii (containerele gestioneaz obiecte, iteratorii le traverseaz) Cum s nu suportm responsabiliti multiple? Formnd propoziii care se termin cu cuvntul itself
Driver Automobile The Start() The Stop() The ChangeTires() The Drive() The CheckOil() The GetOil() Automobile Automobile Automobile Automobile Automobile Automobile start itself. NOK stop itself. changeTires itself. Drive itself. CheckOil itself. GetOil itself. Automobile Start() Stop() GetOil()

Drive(Automobile)

Mechanic ChangeTires(Automobile) CheckOil(Automobile)

OK

19

LISKOV SUBSTITUTION PRINCIPLE

LSP: subtipuri trebuie s fie potrivite pentru clasele lor de baz Ierahii de clase bine proiectate Subclasele trebuie s fie potrivite pentru clasele de baz fr a ne gndi c ceva nu este bine

Board tiles: Title[][] getTitle(int, int) setTitle(Title, int,int)

Board tiles: Title[][] getTitle(int, int) setTitle(Title, int,int)

3DBoard
tiles3D: Tile[][][] getTitle(int, int, int) setTitle(Title, int, int, int) void f() { Board* board = new 3DBoard; // ok! // doesnt make sense for a 3D board board -> getTile (1,7); }

3DBoard

NOK

boards: Board[] getTitle(int, int, int) setTitle(Title, int, int, int) Tile 3DBoard::getTile (int x, int y, int z) { return boards[x].getTile (y, z); }

20

OK

ABLONUL DELEGAIE
Delegation: Declararea este urmrirea unui obiecte de ctre alt obiect Alternativ la motenire Avantaj asupra motenirii: comportamentul se poate modifica la run-time

class A { public: virtual void foo() { printf (An A at work."); } }; class AA : public A { public:

class B { A* pa; public: B(A * aa ) : pa( aa ) { } void setA (A* aa ) { pa = aa; } virtual void foo() { // delegate the task to object pa pa ->foo();

virtual void foo() { } printf ("An AA at work."); } }; }; void main() { B b(new A);

Delegarea este bine s fie utilizat cnd se dorete folosirea comportamentului altei clase asa cum este definit, fr a schimba comportamentul. Exemple Board, 3DBoard

b.foo(); // A behavior b.setA(new AA); b.foo(); // AA behavior }

21

MOTENIREA VS. COMPOZIIE

Motenirea (white-box) Vizibiliatea Static (compile time) Uor de folosit i neles Violeaz principiul ncapsulrii Compoziia obiectelor (black-box) Refolosirea Dinamic (se poate modifica la runtime prin instaniere) Greu de neles Nu violeaz principiul ncapsulrii

Probleme de refolosire
Ierarhi de clase mari; puine obiecte

Menine fiecare clas ncapsulat i focusat pe o anumit sarcin

Ierarhi de clase mici; mai multe obiecte

22