1.

Paradigme de programare i metode de proiectare a programelor

Noiunea de paradigm se bazeaz pe acelai cuvnt ce provine din limba latin i greac i reprezint un exemplu sau un model. Sensul uzual al noiunii este dat de istoricul Thomas Kuhn in cartea sa The Structure of Scientific Revolutions: o paradigm este o mulime de teorii, standarde i metode ce reprezint o modalitate de organizare a cunotinelor. Bazat pe aceast noiune, Robert Floyd n articolul intitulat The Paradigms of Programming, definete noiunea de paradigm de programare ca fiind o metod de conceptualizare a modului de execuie al calculelor ntr-un calculator, precum i a modului de structurare i organizare al taskurilor reponsabile cu execuia calculelor. O noiune des utilizat n locul celei de paradigm de programare este cea de stil de programare, dei semnificaia sa nu este foarte clar definit. Despre un limbaj de programare se spune c ofer suport pentru o paradigm de programare, dac acesta pune la dispoziie faciliti care l fac convenabil de a fi utilizat n acest stil. Un limbaj de programare permite doar acest lucru dac efortul cerut pentru a scrie un program n stilul respectiv este mai mare, limbajul neoferind faciliti suficiente.

1.1 Programarea procedural

Aceasta este una dintre cele mai vechi i des utilizate paradigme. Ea presupune n mod uzual parcurgerea urmtoarelor etape : a) descompunerea problemei de rezolvat in subprobleme ; b) gsirea pentru fiecare subproblem a unui algoritm optim de rezolvare ; c) implementarea fiecrui algoritm folosind funcii sau proceduri ale unui anumit limbaj de programare. Cel mai vechi limbaj de programare procedural este FORTRAN, ns majoritatea limbajelor de programare actuale ofer suport pentru aceast paradigm. Principalele probleme legate de programarea procedural se refer la tipurile de funcii folosite (funcii, proceduri, subprograme, rutine, macrouri, etc.), la tipul i modul de transmitere ale parametrilor i la modurile de apel. Exemplul 1.1. Definirea i utilizarea unei funcii care determin dac un numr ntreg este prim : int Prim(int n) { //codul pentru functie } void DivizoriPrimi(int n) { int i ; for (i=2 ; i<n/2 ; i++) if (n%i == 2 && Prim(i))

printf("%d, i) ; }

1.2 ncapsularea datelor (modularizarea)

De-a lungul timpului, accentul n programarea procedural s-a deplasat de la proiectarea funciilor la organizarea datelor. Datele nu mai sunt privite n mod disparat, ci mpreun cu fuciile care le prelucreaz. A fost definit astfel noiunea de modul ca reprezentnd un set de funcii nrudite, mpreun cu datele pe care le prelucreaz. Se poate astfel mpri un program n module componente ntr-un mod mai clar i mai eficient dect mprirea clasic n funcii sau proceduri, datele programului fiind ncapsulate (ascuse) n modulele ce le utilizeaz. n mod uzual un modul conine o parte de interfa n care sunt declarate datele i funciile accesibile din afara modulului, precum i o parte de implementare, proprie modulului i inaccesibil n exterior n cadrul creia sunt definite funciile ce manipuleaz datele din modul. Limbajul C permite programarea modular, pe cnd limbajul Pascal sau Modula-2 ofer suport real pentru un astfel de stil de programare. n limbajul Turbo Pascal noiunea de modul corespunde celei de unit, prile de interfa i implementare corespunznd respectiv seciunilor interface i implementation. n cazul limbajului C partea de interfa se specific n mod uzual ntr-un fiier header, care trebuie inclus n toate celelalte fiiere ale unui program care utilizeaz funciile modulului. Partea de implementare a modulului este realizat ntr-un fiier distinct care trebuie inclus n proiectul programului. Exemplul 1.2. Definirea i utilizarea unui modul pentru operaiile cu numere ntregi : //fisierul sir.h : interfata modulului #define max_dim 100 void Initializare() ; int Suma() ; void Sortare() ; void AdaugaElement(int) ; void Listare() ; //fisierul sir.c : implementarea modulului #include "sir.h static int dim ; static int v[max_dim] ; void Initializare() { dim = 0 ; } void AdaugaElement(int k) { v[dim++] = k ; } int Suma() { //codul pentru calculul sumei elementelor sirului } void Sortare() {

//codul pentru sortarea elementelor sirului } int Listare() { //codul pentru listarea elementelor sirului } //fisierul pr.c : utilizarea modulului sir #include "sir.h void Prelucrare() { int i, s, k, n = 0 ; Initializare() ; for(i=0 ; i<n ; i++) { scanf("%d, &k) ; AdaugaElement(k) ; } s = Suma() ; printf("\nSuma=%d, s) ; Sortare() ; Listare() ; }

1.3 Abstractizarea datelor

n exemplul precedent se utilizeaz doar un singur ir de numere. Dac se dorete s se lucreze cu mai multe iruri, ncapsularea datelor nu este suficient. Noiunea de abstractizare a datelor presupune posibilitatea definirii unor tipuri de date utilizator, mpreun cu un set de operaii aferente fiecrui tip. Limbajele ce ofer suport pentru ncapsularea datelor permit i abstractizarea, dar nu o garanteaz n general. De exemplu, n C, fiierele antet permit declararea mpreun att a tipurilor de date ct i a funciilor. Un tip de date abstarct este definit printr-o mulime de operatii ce se pot efectua asupra elementelor sale, care formeaz interfaa tipului de date i este singurul mod de acces la tipul de date, precum i printr-o mulime de axiome i precondiii, care este privat tipului de date i reprezint modul de descriere ale proprietilor i operaiilor tipului. Exemplul 1.3. Definirea n limbajul C a unui tip de date reprezentnd numerele fracionare: //fisierul fractie.h - interfata typedef struct { int p, q ; //numaratorul si numitorul } fractie ; fractie Suma(fractie, fractie) ; // principalele operatii fractie Produs(fractie, fractie) ; fractie Raport(fractie, fractie) ; //fisierul fractie.c - implementare #include "fractie.h

fractie Suma(fractie f1, fractie f2) { fractie f ; f.p = f1.p * f2.q + f2.p * f1.q ; f.q = f1.q * f2.q ; return f ; } fractie Produs(fractie f1, fractie f2) { fractie f ; f.p = f1.p * f2.p ; f.q = f1.q * f2.q ; return f ; } fractie Raport(fractie f1, fractie f2) { fractie f ; f.p = f1.p * f2.q ; f.q = f1.q * f2.p ; return f ; } //fisierul pr.c : utilizare #include "fractie.h void Prelucrare() { fractie f1 = {1, 2}, f2 = {7, 4}, f3 ; f3 = Suma(Produs(f1, f2), Raport(f1, f2)) ; printf("\nf3 = %d/%d, f3.p, f3.q) ; } Limbaje precum Ada i C++ permit utilizatorilor s defineasc tipuri de date care se comport la fel ca i tipurile predefinite, datorit posibilitii utilizrii claselor i a suprancrcrii operatorilor. O clas poate fi privit ca o extensie a noiunii de structur din limbajul C, care permite definirea n interiorul clasei att a datelor, ct i a funciilor care utilizeaz aceste date. Suprancrcarea unui operator reprezint o funcie a carei semnificaie este definit de programator, dar al carei apel trebuie s corespund sintaxei limbajului. O clas reprezint cea mai utilizat metod de reprezentare a tipurilor de date abstracte. Ea permite att specificarea interfeei tipului de date, ct i definirea operaiilor permise de acesta. Exemplul 1.4. Redefinirea n limbajul C++ a tipului utilizator fractie: //fisierul frac.h //definirea clasei fractie class fractie { int p, q ;

//interfata clasei public : //constructorul clasei fractie(int a = 0, int b = 1) { p = a ; q = b ; } //declararea operatorilor supraancarcati +, * si / friend fractie operator + (fractie, fractie) ; friend fractie operator * (fractie, fractie) ; friend fractie operator / (fractie, fractie) ; void Print() ; }; //fisierul frac.c //implementarea clasei fractie //definirea operatorilor supraancarcati +, * si / #include "frac.h #include <iostream.h> fractie operator+(fractie f1, fractie f2) { fractie f ; f.p = f1.p * f2.q + f2.p * f1.q ; f.q = f1.q * f2.q ; return f ; } fractie opetrator*(fractie f1, fractie f2) { fractie f ; f.p = f1.p * f2.p ; f.q = f1.q * f2.q ; return f ; } fractie operator/(fractie f1, fractie f2) { fractie f ; f.p = f1.p * f2.q ; f.q = f1.q * f2.p ; return f ; } void print() { cout << p << q ; } //fisierul pr.c //utilizarea clasei fractie #include "frac.h void Prelucrare()

{ fractie f1(1, 2), f2(7, 4), f3 ; f3 = f1*f2 + f1/f2 ; f3.Print() ; // ... } O problem important privind abstractizarea datelor o constituie parametrizarea datelor. Att limbajul Ada, ct i C++ ofer suport pentru parametrizare. Problema parametrizrii apare atunci cnd se dorete definirea unor tipuri de date generice, la care tipul elementelor componente este neprecizat (el este generic, fiind privit ca un parametru). n acest mod un tip de date abstarct parametrizat reprezint un tip de date abstract generic. Exemplul 1.5. De exemplu, dac se dorete definirea unei clase vector la care tipul componentelor este generic, n C++ se poate proceda astfel: class vector<class T> { T *v; //tabloul componentelor //avand tipul generic T int dim; //dimensiunea vectorului public: //constructor vector(int n) { if (n > 0) v = new T[dim = n]; } //supraancarcarea operatorului de indexare T& operator[](int k) { return v[k]; } int dimensiune() { return dim; } }; Se pot defini acum vectori care conin elemente aparinnd unui tip specificat: vector<int> v1(20); //vector cu 20 componente intregi vector<double> v2(10); //vector cu 10 componente reale v1[7] = 5; v2[7] = 2.3;

1.4 Programarea orientat pe obiecte

Dup cun s-a specificat anterior, noiunea de clas nu este specific doar programrii orientate pe obiecte, ea fiind de fapt o modalitate de implementare a unui tip abstract de date. Proprietile unei clase se pot descrie att prin date (atribute), ct i prin funcii (metode).

Instanele unei clase sunt numite obiecte i din acest motiv, o clas reprezint un mod de descriere a proprietilor i a modului de comportare al unei mulimi de obiecte. Un obiect este identificat n mod unic prin numele su, ceea ce impune faptul c nu pot exista dou obiecte diferite ale unei clase cu acelai nume. De exemplu, definirea a trei obiecte instan ale clasei fractie se pot realiza astfel: fractie f1(1, 2), f2(7, 4), f3 ; Deoarece o clas ncapsuleaz att date ct i funcii, pentru un obiect instan pot fi accesate att atributele, ct i metodele. De exemplu, secvena : f3.Print() ; apeleaz metoda Print a clasei fractie. Un obiect al unei clase definete de fapt starea obiectului respectiv, reprezentat de valorile atributelor sale la un anumit moment de timp. n timpul execuiei unui program, starea unui obiect instan se poate modifica prin modificarea valorilor atributelor. Comportamentul unui obiect este definit prin mulimea metodelor ce se pot aplica asupra acestuia. Aceste metode nu sunt specifice obiectului, ci sunt comune ntrgii clase de obiecte. O metod descrie de fapt modul n care un obiect reacioneaz n momentul n care obiectul recepioneaz un anumit mesaj. Un mesaj este o cerere ctre un obiect al unei clase de invocare a unei metode specifice a obiectului. n terminologia utilizat n domeniul paradigmei programrii orientate pe obiecte, apelul unei funcii membru a unui obiect instan nseamn trimiterea unui mesaj acelui obiect. Din acest punct de vedere, scopul utilizrii acestei paradigme const n dezvoltarea unor aplicaii care creeaz anumite mulimi de obiecte crora apoi le transmit diferite mesaje. Dei elementele definite anterior sunt fundamentale pentru aplicaiile care lucreaz cu clase i obiecte, ele nu reprezint aspectele eseniale ale paradigmei programrii orientate pe obiecte. Un prim element esenial al programrii orientate pe obiete este faptul c permite exprimarea distinciei ntre proprietile generale i cele particulare ale obiectelor. De exemplu, toate autoturismele de tip Dacia folosesc au 4 roi (proprietate general), dar autoturismele Dacia 1310 au capacitatea motoruui de 1300 cm3, pe cnd cele de tip Dacia 1410 au capacitatea de 1400 cm3 (proprietate particular). Rezult de aici o proprietate important a limbajelor orientate pe obiecte : permit mprirea obiectelor n clase, precum i un mecanism de motenire a proprietilor unei clase de ctre alte calse. n acest mod, clasele de obiecte pot forma ierarhii de clase. De exemplu, n cazul autoturismelor Dacia, dac se definete o ierarhie format din 3 clase, Dacia, Dacia1310 i Dacia 1410, ultimele dou clase vor moteni proprietile primeia. Exemplul 1.6. Ierarhia de clase pentru autoturismele Dacia se poate descrie astfel : class Dacia { // ... int nr_roti ; Dacia() { nr_roti = 4 ; }

// ... } ; class Dacia1310 : public Dacia { // ... int capacitate ; Dacia1310() { capacitate = 1300 ; } // ... } ; class Dacia1410 : public Dacia { // ... int capacitate ; Dacia1410() { capacitate = 1400 ; } // ... } ; Exemplul 1.7. S considerm urmtoarele figuri poligonale n plan : triunghiuri, patrulatere, patrulatere, pentagoane, etc., fiecare poligon fiind descris prin coordonatele vrfurilor n ordine trigonometric. Se poate forma o ierarhie de clase, care n vrful ierarhiei clasa poligon, celelalte clase motenind-o. S presupunem c pentru clasa poligon se specific coordonatele primelor 2 vrfuri ale poligonului, P0(x0, y0) i P1(x1, y1), celelalte clase trebuind s memoreze pe rnd coordonatele celorlalte vrfuri. class Poligon { // ... protected : double x0, y0, x1, y1 ; virtual double DouaLaturi() = 0 ; public : Poligon(_x0, _y0, _x1, _y1); virtual ~Poligon(); virtual double Perimetru() ; // ... } ; class Triunghi : public Poligon { // ... protected : double x2, y2 ; double DouaLaturi() ; double OLatura() ; public : Triunghi(_x0, _y0, _x1, _y1, _x2, _y2); double Perimetru() ; // ... } ;

class Patrulater : public Triunghi { // ... protected : double x3, y3 ; double DouaLaturi() ; public : Patrulater(_x0, _y0, _x1, _y1, _x2, _y2, _x3, _y3); double Perimetru() ; // ... } ; Toate poligoanele au un perimetru, indiferent de tipul lor. Determinarea valorii acestuia se poate face incremental, observnd faptul c perimetrul unui poligon cu n +1 vrfuri (P0, P1, , Pn) se poate obine din perimetrul poligonului cu n vrfuri (P0, P1, , Pn-1) la care se adauga lungimile laturilor P0Pn i Pn+1Pn . Funcia Perimetru determin valoarea perimetrului curent, iar funcia DouaLaturi determin lungimile laturilor P0Pn i Pn-1Pn . Deoarece aceste funcii sunt comune tuturor claselor, dar implementrile specifice fiecrei clase, ele reprezint funcii virtuale. Mai mult, funcia DouaLaturi nu se poate implementa n cadrul clasei Poligon, ea reprezentnd o funcie virtual pur n acea clas. Implementrile acestor funcii se pot descrie astfel : double Poligon::Perimetru() { double l = sqrt((x0-x1)*(x0-x1) + (y0-y1)*(y0-y1)) ; return l ; } double Triunghi::DouaLaturi() { double a, b ; a = sqrt((x0-x2)*(x0-x2) + (y0-y2)*(y0-y2)) ; b = sqrt((x1-x2)*(x1-x2) + (y1-y2)*(y1-y2)) ; return a + b ; } double Triunghi::OLatura() { double a; a = sqrt((x0-x2)*(x0-x2) + (y0-y2)*(y0-y2)) ; return a ; } double Triunghi::Perimetru() { double p ; p = Poligon::Perimetru() + DouaLaturi() ; return p ;

} double Patrulater::DouaLaturi() { double a, b ; a = sqrt((x0-x3)*(x0-x3) + (y0-y3)*(y0-y3)) ; b = sqrt((x1-x3)*(x1-x3) + (y1-y3)*(y1-y3)) ; return a + b ; } double Patrulater::Perimetru() { double p ; p = Triunghi::Perimetru() Triunghi::OLatura() + DouaLaturi() ; return p ; } n cazul funciilor virtuale, selectarea efectiv a funciei care se va apela se realizeaz n mod automat de ctre compilator. Aceast proprietate care permite compilatorului s selecteze pentru execuie o anumit metod specific unui obiect, dintre mai multe metode cu acelai nume definite n ierarhia de clase se numete polimorfism. n concluzie, al doilea element esenial al programrii orientate pe obiecte const n mecanismul funciilor virtuale i al polimorfismului, prin care apelul funciilor membru depinde efectiv de tipul obiectului respectiv. De exemplu, pentru cazul poligoanelor, urmtoarele declaraii i instruciuni : Triunghi f1 ; Patrulater f2 ; double p1 = f1.Perimetru() ; double p2 = f2.Perimetru() ; permit slectarea corect a funciei Perimetru de ctre compilator pentru fiecare obiect. Limbajul considerat ca un limbaj pur orientat pe obiecte este Smalltalk. Printre alte limbaje ce suport aceast paradigm se pot enumera : Ada, C++, Simula, Java. Observaie. Datorit mecanismului claselor, un limbaj ce suport paradigma programrii orientate pe obiecte, permite i abstractizarea datelor.

1.5 Proiectarea orientat pe obiecte

Cunoaterea unui limbaj de programare care ofer suport pentru paradigma programrii orientate pe obiecte este necesar, ns nu i suficient pentru realizarea unor aplicaii orientate pe obiecte.

Pentru a putea dezvolta n mod eficient o asemenea aplicaie, n special n cazul proiectelor mari, sunt necesare de asemenea stpnirea unor tehnici de analiz i proiectare software. Acestea permit ca plecnd de la o problem real, s se poat dezvolta o aplicaie orientat pe obiecte pentru rezolvarea problemei iniiale. n mod uzual, ciclul de via al produselor software conine urmtoarele etape : analiza cerinelor proiectarea codificarea testarea ntreinerea Acestea reprezint etapele unui ciclu ideal de via, deoarece n practic, n funcie de tipul problemelor de rezolvat i de uneltele de care se dispune, unele etape sunt nesemnificative. De exemplu, n cazul unei probleme simple pe care o poate primi un student n timpul unei ore de laborator, operaia de ntreinere a programului nu se justific, iar operaiile de anliz i proiectare pe de o parte, precum i cele de codificare i testare pe de alt pate, pot fi comasate. Dac necesitatea cunoaterii unui limbaj orientat pe obiecte este indispensabil n etapa de codificare a unei aplicaii orientat pe obiecte, cunoaterea unor metode de analiz i proiectare orientat pe obiecte este esenial n etapele de analiz i proiectare. Unul dintre cele mai utilizate instrumente de analiz i proiectare orientat pe obiecte o constituie formalismul UML (The Unified Modeling Language), propus de Jacobson, Rumbaugh i Booch. n continuare se prezint cteva elemente ale formalismului UML utilizate n etapele de analiz i proiectare software. n etapa de analiz, trebuie evideniate toate elementele care trebuie s fie realizate de ctre aplicaie. n mod uzual se pornete de la o specificaie iniial a problemei, enunat de ctre client, iar n aceast etap trebuie create dou documente : Analiza cerinelor i Specificarea sistemului. Analiza cerinelor reprezint o list a cerinelor enunate de ctre client i pe care aplicaia trebuie s le ndeplineasc, iar specificarea sistemului reprezint o descriere a ceea ce aplicaia trebuie s fac pentru a satisface cerinele clientului. Elementul esenial n acest etap const n descoperirea comportrii aplicaiei conform cerinelor specificate. Cel mai utilizat instrument de proiectare n aceast etap o constituie diagramele de caz. O diagram de caz descrie comportarea unei pri din funcionarea unui sistem din punctul de vedere au unui utilizator extern. Ea folosete noiunile de actor i caz de utilizare (use case). Un actor este o idealizare a unei persoane externe sau proces care interacioneaz cu sistemul i n mod uzual se descrie grafic ca o persoan stilizat care are asociat un nume. Un caz de utilizare reprezint un element al funcionalitii externe a sistemului, care poate interaciona cu unul sau mai muli actori. n plus, un caz de utilizare poate avea legturi cu alte cazuri de funcionare, pentru a putea descrie mai bine relaiile sale din cadrul sistemului. Grafic, un caz de utilizare se descrie print-o elips ce are specificat n interior numele cazului.

Observaie. O legtur ntre un actor i un caz de utilizare poate indica n multe cazuri un element al unei interfee utilizator. O diagram de utilizare descrie cazurile de utilizare asociate unui sistem i le ncadreaz din punct de vedere grafic ntr-un dreptunghi reprezentnd sistemul respectiv. De exemplu, n figura 1.1 este prezentat o diagram de caz ce descrie funcionarea unui automat bancar. Automatul bancar reprezint sistemul ce se descrie, iar actorii externi sunt clientul i banca posesoare a automatului. Diagramele de caz permit specificarea cerinelor i a sistemului prin determinarea tuturor interaciunilor ntr utilizator i sistem. Pentru specificarea tuturor cerinelor, trebuie descoperite toate diagramele de czuri ce descriu funcionarea sistemului respectiv. n etapa de proiectare a aplicaiei trebuie determinate n primul rnd componentele aplicaiei respective. O component reprezint o entitate abstract, iar aplicaia poate fi privit ca fiind alctuit din aceste componente. Din punctul de vedere al unui limbaj de programare, o component poate fi reprezentat de o funcie, de o structur sau o clas, sau de o colecie de alte componente. n cele mai multe cazuri, componentele se identific cu clasele de obiecte. ATM transfer spre alt cont afiare sold Client retragere numerar Figura 1.1 O component trebuie s aib asociat o mulime bine definit de responsabiliti, precum i o mulime de alte componente cu care poate interaciona. O metod foarte utilizat, n special nainte de apariia formalismului UML a fost metoda CRC (Component Responsability Collaboration). Folosind aceast metod, fiecare component se asociaz cu o carte de joc pe care se scriu urmtoarel informaii : numele componentei descrierea responsabilitilor componentei respective lista celorlalte componente cu care ea interacioneaz. Avantajul acestei metode const n simplitatea ei i n faptul c permite operaia de rafinare ori de cte ori este nevoie. Deoarece n mod uzual o component reprezint o clas de obiecte, responsabilitile acesteia sunt de fapt metodele clasei respective. n acest mod, o carte CRC reprezint descrierea unei clase. Exist totui un dezavantj al metodei CRC, deoarece ea nu permite descrierea atributelor acestor clase. Banc

Formalismul UML pune la dispoziie diagramele de clase pentru descrierea claselor i a relaiilor dintre ele, cu observaia c ele reprezint descrieri statice. Notaia UML pentru o clas este o notaie grafic, n care o clas se specific ntr-un dreptunghi prin numele su, precum i prin listele de atribute i metode specifice clasei. Colaborrile dintre clase se pot specifica prin intermediul relaiilor. Relaiile se reprezint grafic prin linii sau sgei, fiecare asemenea relaie legnd dou clase ntre ele. De fapt relaiile sunt generale n cadrul formalismului UML, ele putnd conecta diferite tipuri de elemente, precum clase, actori, cazuri de utilizare, etc. Principalele tipuri de relaii sunt urmtoarele: asocierea, care descrie legturile semantice dintre obiecte individuale ale unor clase; generalizarea, care descrie relaiile de motenire ntre clase; realizarea, care descrie relaia dintre o specificare i implementarea sa; dependena, care pune n relaie clase ale cror comportament sau implementare afecteaz alte clase. Asocierea este o relaie care descrie conexiunea ntre obiecte sau grupuri de obiecte. Un caz particular de relaie de asociere reprezint relaia de agregare, care este o relaie de tipul ntreg-parte. Din punct de vedere grafic, agregarea se noteaz cu un romb la captul liniei dinspre clasa ntreg. Un caz particular de agregare este relaia de compunere. O astfel de relaie specific faptul c ciclul de via al obiectelor component depind de ciclul de via al obiectului compus. Asupra principalelor tipuri de relaii se va reveni n capitolele urmtoare. De exemplu, ierarhia de clase din exemplul 1.7, se poate descrie ca n figura 1.3. n figura 1.2 sunt prezentate n figura 1.3 sunt prezentate relaiile de agregare i de compunere.
Echipa

Masina

Jucator

Carburator

Figura 1.2 Relaia de agregare i de compunere Formalismul UML pune la dispoziie i alte tipuri de diagrame, care permit descrierea interaciunilor dintre obiecte, precum i evoluia dinamic a obiectelor sistemului. De exemplu : diagramele de colaborare permit reprezentarea obiectelor i a interaciunilor dintre ele, diagramele de secvene permit reprezentarea temporal a obiectelor i a interaciunilor lor.

Poligon x0: double y0: double x1: double y1: double Perimetru(): double DouaLaturi(): double

Triunghi x2: double y2: double Perimetru(): double DouaLaturi(): double Olatura(): double Patrulater x3: double y3: double Perimetru(): double DouaLaturi(): double Figura 1.3 Ierarhia figurilor poligonale din exemplul 1.7