nvmntul profesional i tehnic n domeniul TIC Proiect cofinanat din Fondul Social European n cadrul POS DRU 2007-2013

Beneficiar Centrul Naional de Dezvoltare a nvmntului Profesional i Tehnic

str. Spiru Haret nr. 10-12, sector 1, Bucureti-010176, tel. 021-3111162, fax. 021-3125498,

vet@tvet.ro

PROGRAMAREA ORIENTAT OBIECT Material de predare partea a II-a

Domeniul: Informatic Calificarea: Analist programator Nivel 3 avansat

2009

AUTOR: CHIRIL DOMNICA profesor grad didactic definitivat

COORDONATOR: MARIANA VIOLETA CIOBANU profesor grad didactic I

CONSULTAN: IOANA CRSTEA expert CNDIPT ZOICA VLDU expert CNDIPT ANGELA POPESCU expert CNDIPT DANA STROIE expert CNDIPT

Acest material a fost elaborat n cadrul proiectului nvmntul profesional i tehnic n domeniul TIC, proiect cofinanat din Fondul Social European n cadrul POS DRU 20072013

Cuprins
I. Introducere......................................................................................................................4 II. Documente necesare pentru activitatea de predare.....................................................5 III. Resurse........................................................................................................................6 Tema 1. Limbajul unificat pentru modelarea datelor..................................................................6 Fia suport 1.1. Concepte generale..........................................................................................6 Tema 1. Limbajul unificat pentru modelarea datelor..................................................................9 Fia suport 1.2. Diagrama cazurilor de utilizare (Use Case)...................................................9 Tema 1. Limbajul unificat pentru modelarea datelor................................................................12 Fia suport 1.3. Aplicaii software. Prezentare general........................................................12 Tema 2. Descrierea claselor folosind UML...............................................................................14 Fia suport 2. Diagrama de clase...........................................................................................14 Tema 3. Descrierea asocierilor folosind UML..........................................................................18 Fia suport 3. Relaia de asociaie..........................................................................................18 Tema 4. Descrierea obiectelor folosind UML...........................................................................23 Fia suport 4. Diagrama de obiecte........................................................................................23 Tema 5. Mediul de dezvoltare specific POO.............................................................................25 Fia suport 5. Prezentare general, faciliti..........................................................................25 Tema 6. Definirea claselor.........................................................................................................27 Fia suport 6. Concordana cu elementele obinute la modelare...........................................27 Tema 7. Motenire.....................................................................................................................29 Fia suport 7. Motenire ........................................................................................................29 Tema 8. Aplicaii ale polimorfismului n POO..........................................................................33 Fia suport 8. Aplicaii ale polimorfismului n POO.............................................................33 IV. Fia rezumat...............................................................................................................38 V. Bibliografie...................................................................................................................40

I. Introducere
Materialele de predare reprezint o resurs suport pentru activitatea de predare, instrumente auxiliare care includ un mesaj sau o informaie didactic. Prezentul material de predare, se adreseaz cadrelor didactice care predau n cadrul colilor postliceale, domeniul Informatic, calificarea Analist programator, nivelul 3 avansat. El a fost elaborat pentru modulul Programarea orientat obiect, ce se desfoar n 150 ore, din care laborator tehnologic 60 ore i 30 de ore instruire practic. Orele de instruire practic se vor efectua n cele 4 sptmni alocate stagiului de pregtire practic. Materialul abordeaz competen ele 3 ( Descrie clase, obiecte i relaii ntre acestea utiliznd limbajul unificat de modelare ) i 4 (Programeaz aplicaii folosind paradigma POO). Competene / rezultatele ale nvrii 3. Descrie clase, obiecte i relaii ntre acestea utiliznd limbajul unificat de modelare Teme Tema 1 Limbajul unificat de modelare a datelor (UML) Fise suport Fia 1.1 Concepte generale Fia 1.2 Diagrama cazurilor de utilizare Fia 1.3 Aplicaii software. Prezentare general Fisa 2 Diagrama de clase Fia 3 Relaii de asociaie Fia 4 Diagrama de obiecte Fia 5 Prezentare general, faciliti Fia 6 Concordana cu elementele obinute la modelare Fia 7 Instanierea claselor la motenire Fia 8 Aplicaii ale polimorfismului n POO

Tema 2 Descrierea claselor folosind UML Tema 3 Descrierea asocierilor folosind UML Tema 4 Descrierea obiectelor folosind UML Tema 5 Mediul de dezvoltare specific POO Tema 6 Definirea claselor Tema 7 - Motenire Tema 8 Aplicaii ale polimorfismului n POO

4. Programeaz aplicaii folosind paradigma POO

Absolvenii nivelului 3 avansat, coal postliceal, calificarea Analist programator, vor fi capabili s utilizeze tehnologiile informatice i ale comunicrii pentru conceperea, proiectarea, elaborarea, testarea, implementarea i dezvoltarea sistemelor informatice, a programelor i a documentaiei tehnice aferente.

II. Documente necesare pentru activitatea de predare

Pentru predarea coninuturilor abordate n cadrul materialului de predare cadrul didactic are obligaia de a studia urmtoarele documente: Standardul de Pregtire Profesional pentru calificarea Analist programator, nivelul 3 avansat www.tvet.ro, seciunea SPP sau www.edu.ro , seciunea nvmnt preuniversitar Curriculum pentru calificarea Analist programator, nivelul 3 avansat www.tvet.ro, seciunea Curriculum sau www.edu.ro , seciunea nvmnt preuniversitar

III. Resurse Tema 1. Limbajul unificat pentru modelarea datelor

Fia suport 1.1. Concepte generale
Analiza i proiectarea unei aplicaii se realizeaz nainte de scrierea codului; de aceea trebuie acordat o atenie deosebit acestor etape deoarece de ele depind producerea unui soft de calitate precum i refolosirea lui ntr-o manier eficient. Limbajul unificat de modelare, pe scurt UML (the Unified Modeling Language), este un limbaj de modelare orientat pe obiecte, folosit n faza de analiz i proiectare a unei aplicaii. Este succesorul a trei metode de modelare orientate pe obiecte (Booch, OMT, OOSE). n ianuarie 1997 este propus pentru standardizare, n cadrul OMG (Object Management Group), versiunea UML 1.0. n noiembrie 1997 versiunea UML 1.1 este adoptat ca standard de ctre OMG. Dup cteva revizii minore are loc o mbuntire major i se trece la versiunea UML 2.0 care devine un standard n 2005. UML este nu este un limbaj de programare propriu-zis, dar este un limbaj ce permite specificarea, vizualizarea, construirea i documentarea unei aplicaii software (a unui sistem). UML conine un set de notaii i semne grafice a cror combinare conduce la un model abstract al sistemului. Poate fi folosit i pentru alte sisteme, din alte domenii, cum ar fi procesele de afaceri. Principalele pri ale UML sunt: 1. Diagramele sunt grafuri ce descriu aspecte particulare ale sistemului modelat. 2. Elementele de modelare (clasificatori) conceptele folosite n diagrame; de ex. actori, clase, mesaje, etc. i relaiile dintre acestea: asocierea dependena, generalizarea. Un element poate fi folosit n mai multe diagrame diferite i va avea acelai neles i acelai mod de reprezentare.

Diagrame
Diagramele UML surprind dou puncte de vedere (views) ale modelrii unui sistem 1. Structural (static, structural view) reliefeaz structura sistemului folosind obiecte, atribute, operaii (metode) i relaii ntre acestea. 2. Comportamental (dinamic, behavioral view) reliefeaz comportarea dinamic a sistemului artnd interaciunile dintre obiecte i schimbrile strilor acestora. n UML 2.0 se pot crea 13 tipuri de diagrame mprite n trei categorii. ase tipuri de diagrame reprezint diagrame de structur, iar apte tipuri de diagrame reprezint diagrame comportamentale (incluznd aici patru tipuri de diagrame ce reprezint diagrame de interaciuni). 6

Diagrame de structur
1. Diagrama de clase (Class diagram) - descrie structura unui sistem artnd clasele lui, atributele claselor i relaiile dintre clase. 2. Diagrama de componente (Component diagram) - descrie cum un sistem software este mprit n componente i arat dependenele dintre aceste componente. 3. Diagrama de obiecte (Object diagram) - arat o vedere complet sau parial a structurii sistemului la un moment specific de timp. 4. Diagrama de structuri compuse/mixte (Composite structure diagram) descrie structura intern a unei clase i colaborarea pe care aceast structur o face posibil. 5. Diagrama de desfurare (Deployment diagram) - ajut la modelarea componentelor hardware utilizate de implementrile sistemului, la modelarea mediului de execuie i a activitilor desfurate pe componentele hardware. 6. Diagrama de pachete (Package diagram) descrie cum sistemul este mprit n grupri logice, artnd dependenele dintre aceste grupri.

Diagrame comportamentale
1. Diagrama cazurilor de utilizare (Use case diagram) arat funcionalitatea unui sistem din punct de vedere al actorilor, scopurile lor reprezentate ca i cazuri de utilizare i dependenele dintre aceste cazuri de utilizare. 2. Diagrama de activiti (Activity diagram) descrie tranzaciile i derularea operaiunilor dintre componentele unui sistem. Arat n general cum trece controlul de la o component la alta. 3. Diagrama de stri (State machine diagram) descrie strile unui sistem, evenimentele (externe i interne), tranziiile ntre aceste stri, condiii pentru tranziii. Reprezint o notaie standard care poate descrie mai multe tipuri de sisteme, de la programe pentru calculator la derularea afacerilor.

Diagrame de interaciune
Reprezint un subset al diagramelor comportamentale ce evideniaz fluxul de date i de control printre elementele de modelare. 1. Diagrama de interaciune general (Interaction overview diagram) este un tip de diagram de activitate n care nodurile reprezint diagrame de interaciune. 2. Diagrama de secven (Sequence diagram) arat cum obiectele comunic ntre ele din punct de vedere al succesiunii de mesaje. De asemenea indic durata vieii obiectelor relativ la aceste mesaje. 3. Diagrama de comunicare (Communication diagram) descrie interaciunea dintre obiecte folosind mesaje secveniale. Ele reprezint o combinaie de informaii luate de la diagramele de clas, de secven i a cazurilor de utilizare 7

(use case) i descriu n acelai timp structura static i comportarea dinamic a unui sistem. 4. Diagrama de timp (Timing diagram) - este un tip specific de diagrame de interaciune unde se urmresc constrngerile de timp/durat

Sugestii metodologice
UNDE PREDM? Coninutul poate fi predat n laboratorul de informatic sau ntr-o sal care are videoproiector sau flipchart. CUM PREDM?

Se recomand utilizarea unui videoproiector pentru exemplificarea diverselor tipuri de diagrame i utilizarea calculatoarelor pentru activitile de fixare a cunotinelor. Ca metod de predare poate fi folosit expunerea, dar aceasta ar fi bine s aib ca punct de pornire necesitate i posibilitatea modelrii datelor. Ca materiale suport se pot folosi: O prezentare multimedia Activiti interactive de tip rebus cu noiunile nvate Clasa poate fi organizat frontal.

Ca materiale de evaluare se pot folosi: o Probe orale i scrise

Tema 1. Limbajul unificat pentru modelarea datelor

Fia suport 1.2. Diagrama cazurilor de utilizare (Use Case)
Definiie Este o diagram de tip comportamental. Are ca scop crearea unei imagini grafice de ansamblu asupra interaciunii sistemului cu utilizatorii si. Poate fi folosit de persoane fr specializare IT. Elementele utilizate i notaiile lor sunt Element Actor Descriere Un actor reprezint un rol jucat de o persoan sau alt sistem care interacioneaz cu sistemul modelat Descrie, ntr-un limbaj natural, ce trebuie s fac sistemul pentru ca actorul s-i ating inta Indic legtura dintre un actor i un caz de utilizare, n sensul c acel actor particip ntr-un fel oarecare n acel caz de utilizare
Tabelul 1 Principalele notaii din diagramele Use Case

Notaie

Caz de utilizare

Caz de utilizare

Asociere

Un exemplu simplu de caz de utilizare este:

Figura 1 Caz de utilizare

Relaii ntre actori i ntre cazuri de utilizare

Relaia de generalizare/specializare n UML 2.0 nu sunt permise asocierile ntre actori, dar pot exista relaii de generalizare/specializare. Acestea sunt reprezint printr-o linie ce are la un capt un triunghi gol orientat de la actorul specializat la ctre actorul generalizat. Aceast relaie se poate stabili i ntre cazuri de utilizare; de exemplu, emiterea unei facturi i emiterea unei chitane sunt particularizri ale cazului de emitere a unui document. Aceste relaii sunt reprezentate ca n figura 2.

Figura 2 Relaii de generalizare ntre actori i ntre cazuri de utilizare

Relaia de tip includere Este folosit atunci cnd comportamentul cazului de utilizare dat este inclus n comportamentul altui caz de utilizare. Se reprezint printr-o sgeat punctat, orientat de la cazul care include spre cazul care este inclus i cuprinde eticheta include. Comportarea cazului inclus nu este esenial pentru diagram, dar precizeaz un comportament particular al unui caz de utilizare (vezi fig. 3). Relaia de tip extindere Este folosit atunci cnd comportarea unui caz de utilizare dat extinde comportarea unui alt caz de utilizare, n anumite condiii. Cazurile de utilizare de extindere modeleaz comportamente opionale sau de excepie, care nu condiioneaz finalitatea cazului de baz. Ele se reprezint printr-o sgeat punctat, orientat de la cazul extins spre cazul de baz i cuprinde eticheta extend (vezi fig. 3). Aplicaie

Figura 3 Modelarea operaiunii de retragere de numerar de la un bancomat

Sugestii metodologice
UNDE PREDM? Coninutul poate fi predat n laboratorul de informatic.

10

CUM PREDM? Se recomand utilizarea calculatoarelor pentru activitile de fixare a noilor cunotine. Se recomand parcurgerea acestui coninut mpreun/n paralel cu prezentarea unei aplicaii software. Este indicat folosirea, ca metode de predare, a problematizrii, a nvrii prin descoperire, a exerciiului. Clasa poate fi organizat frontal sau pe grupe de 3-4 elevi. Ca materiale suport se pot folosi: O prezentare multimedia Fie de lucru Activiti interactive, de genul drag & drop pentru crearea diagramelor Un studiu de caz cu tema Dau / primesc un telefon

Ca materiale de evaluare se pot folosi: o Probe practice, orale i scrise

11

Tema 1. Limbajul unificat pentru modelarea datelor

Fia suport 1.3. Aplicaii software. Prezentare general
Cele mai cunoscute aplicaii software folosite n modelarea UML sunt reunite sub genericul instrumente CASE - Computer Aided Software Engeneering. Termenul CASE a fost introdus pentru prima dat n anul 1987 de John Manley i a desemnat instrumentele informatice concepute pentru a fi utilizate n etapele de analiz i proiectare, oferind faciliti de reprezentare grafic specifice acestor etape. Instrumentele CASE conin numai elemente specifice abordrii orientate-obiect a sistemelor i se bazeaz pe metodele i tehnicile de analiz i proiectare orientateobiect. Ele se mai numesc i unelte UML (UML tool). Caracteristicile de baz ale unei unelte UML sunt urmtoarele: 1. depozitul de date (data repository) o component important, care acumuleaz i stocheaz, n mod organizat, toate informaiile introduse de diferite persoane, la momente diferite de timp, care vor servi n etapele de analiz, proiectare i creare a codului 2. editorul de diagrame component obligatorie ce faciliteaz i automatizeaz realizarea i modificarea diagramelor UML conform standardelor; 3. suport pentru refolosirea modelelor i a elementelor de modelare ntre diagrame. 4. generatorul de cod, component care poate converti n cod diagramele UML; 5. suport pentru round-trip engineering care faciliteaz generarea codului pe baza diagramelor UML i generarea diagramelor UML dintr-un cod surs pstrnd o relaie biunivoc ntre ele astfel nct modificarea codului conduce la modificarea modelului i reciproc 6. componentele de transformare, care permit trecerea de la un model sau o diagram la alt model, respectiv la alt diagram; 7. navigatorul specializat, instrument pentru vizualizarea informaiilor unui ansamblu de entiti care au o structur complex, ntre care exist un mare numr de relaii; 8. generatorul de documentaie, care include modele de documente, oferind utilizatorilor posibilitatea de a-i concepe propriile documente ntr-o manier flexibil; 9. instrumentele pentru managementul de proiect, ce ofer faciliti destinate gestiunii configuraiei fiecrui proiect; 10. instrumentele de verificare automat a aplicaiei;

12

Sugestii metodologice
UNDE PREDM? Se recomand ca aceste coninuturi s fie predate n laboratorul de informatic. Clasa poate fi organizat frontal sau pe grupe de 3-4 elevi

CUM PREDM? Se poate folosi o prezentare multimedia a interfeei unui instrument CASE sau, cu ajutorul unui videoproiector, profesorul exemplific facilitile oferite de un astfel de program Pentru fixarea acestor coninuturi se recomand efectuarea unor activiti de: personalizare a soft-ului ales drang&drop pentru crearea / modificarea unor diagrame UML activiti de export a diagramelor n format imagine (.jpg, .gif)

activiti de generare a codului surs dintr-o diagram UML i a unei diagrame dintr-un fiier cod surs

13

Tema 2. Descrierea claselor folosind UML

Fia suport 2. Diagrama de clase
Definiie Este un tip de diagram de structur sub form de grafuri ce au ca noduri clase (dar pot fi i pachete sau interfee), iar ca arce relaiile dintre ele. Reprezentarea claselor Clasele se reprezint grafic printr-un dreptunghi ce conine numele clasei scris ngroat i ncepnd cu liter mare. Dreptunghiul poate fi mprit n trei seciuni: prima pentru numele clasei, a doua pentru atributele clasei, iar ultima pentru operaiile clasei.

Figura 4 Reprezentarea clasei Persoana

Dar poate fi reprezentat mai simplu astfel Persoana

sau Persoana

Suplimentar se pot aduga i alte detalii cum ar fi: 1. Proprieti ale clasei se plaseaz ntre acolade, sub numele clasei, dar n acelai compartiment 2. Vizibilitatea membrilor clasei modul n care sunt vizibile i pot fi accesate din afara clasei. Acest lucru se reprezint printr-un semn, conform tabelului 2, plasat n faa atributului sau operaiei
Vizibilitate Public Protected Private Notaie + # Descriere membru vizibil oriunde este vizibil clasa membru vizibil n clasa n care a fost declarat sau n clasele derivate membru vizibil doar n clasa n care a fost declarat
Tabelul 2

14

3. Multiplicitatea atributelor cardinalitatea pe care o poate avea un atribut, se specific ntre paranteze ptrate, dup numele atributului; aceasta poate fi [2] sau [1..*], nsemnnd c acel atribut are 2 valori sau poate avea una sau mai multe valori (vezi atributul adresa din clasa Persoana). 4. Atributele pot avea specificat, opional, tipul de date pe care-l memoreaz i, eventual, o valoare iniial (vezi atributul vrsta din clasa Persoana). 5. Operaiile pot avea specificat, opional, tipul returnat i lista argumentelor. Atributele i operaiile statice sunt specificate prin sublinierea acestora cu o linie. Relaia de generalizare / specializare

Definiie Relaia de generalizare / specializare modeleaz conceptul de motenire dintre clase. Se reprezint printr-o linie continu trasat ntre clas i clasa derivat, cu un triunghi mare, gol la un capt i cu vrful indicnd spre clasa mai general. Este o relaie de tipul este un / este o (is a). O ierarhie de clase poate conine unul sau mai muli discriminatori, reprezentai ca etichete ale relaiei de specializare. Fiecare discriminator realizeaz o delimitare pe submulimi a subclaselor. Dac mai multe subclase au acelai discriminator, atunci ele aparin aceleiai submulimi. Discriminatorul este considerat ca fiind un pseudoatribut al superclasei. Pseudoatributul se comport ca un atribut al unei clase obinuite, ns domeniul su este mulimea numelor de subclas. De exemplu, n figura 5 discriminatorul este pseudoatributul profesie.

Figura 5 Relaii de generalizare ntre clase

ntre subclasele unei clase se pot defini restricii , acestea fiind trecute ntre acolade n dreptul unei linii ntrerupte ce unete subclasele. Restriciile sunt specificate printr-unul sau mai multe cuvinte cheie. Ele pot fi: 1. Overlapping arat c dou sau mai multe subclase pot fi folosite ca baz pentru o derivare multipl 15

2. Disjoint este opusul restriciei overlapping n sensul c nu este posibil derivare direct sau indirect din dou sau mai multe subclase de pe acelai nivel 3. Complete nseamn c au fost specificate toate subclasele posibile 4. Incomplete este opusul restriciei complete nsemnnd c ar mai putea fi adugate i alte subclase Un caz special de relaie de generalizare este relaia de realizare (realization relationship). n acest tip de relaie, subclasa modeleaz un comportament specific al superclasei. Se reprezint printr-o linie punctat trasat ntre superclas i subclas, cu un triunghi mare, gol la un capt i cu vrful indicnd spre clasa mai general.

Figura 6 Relaii de realizare ntre clase

Relaia de dependen Dependena este cel mai slab tip de relaie dintre clase i nu se ncadreaz n nici o categorie anterioar. Ea se reprezint printr-o sgeat cu linie punctat, cu sensul de la clasa dependent la ce de care depinde; adic a crei modificare ar putea s o afecteze. Tipul dependenei poate fi indicat printr-un stereotip, predefinit sau nu, reprezentat ca un cuvnt cheie, situat ntre << i >>. Dintre stereotipurile predefinite utilizate n diagramele de clase, se pot meniona: 1. <<friend>> - se folosete dac o clas este prieten cu o alt clas, adic toate metodele ei sunt prietene cu clasa respectiv i au acces la membrii si privai (concept suportat de C++); 2. <<call>> sau <<use>> - se folosete dac o clas apeleaz o operaie a unei alte clase; 3. <<instantiate>> - se folosete dac o clas instaniaz o alt clas (creeaz un obiect de acel tip);

16

Figura 7 Relaie de dependen ntre clase

Sugestii metodologice
UNDE PREDM? Coninutul poate fi predat n laboratorul de informatic sau ntr-o sal care are videoproiector sau flipchart. CUM PREDM?

Se recomand utilizarea calculatoarelor pentru activitile de fixare a noilor cunotine. Este indicat folosirea, ca metode de predare, a problematizrii, a nvrii prin descoperire, a exerciiului. Ca materiale suport se pot folosi: O prezentare multimedia care s cuprind urmtoarele noiuni: o Reactualizarea unor cunotine despre clase i obiecte . o Prezentarea crerii unei diagrame de clase. Activiti interactive: o de tip rebus cu noiunile nvate o de tip drag & drop pentru crearea diagramelor Un studiu de caz cu tema coala Clasa poate fi organizat frontal sau pe grupe de 3-4 elevi.

Ca materiale de evaluare se pot folosi: o Probe orale i scrise, frontale i sumative

17

Tema 3. Descrierea asocierilor folosind UML

Fia suport 3. Relaia de asociaie
Definiie Relaia de asociaie corespunde unei cooperri ntre clase, n condiiile n care obiectele instaniate din aceste clase sunt create i distruse n mod independent. Asociaiile se reprezint printr-o linie continu ntre clasele asociate. Ele pot fi: 1. 2. 3. Unare ntre o clas i ea nsi i se reprezint Binare ntre dou clase Ternare ntre trei clase NumeClasa1 Nume Clasa NumeClasa2

Figura 8 Reprezentarea relaiilor de asociaie

Asociaiile ternare sunt mai rar utilizate deoarece sunt mai greu de implementat, adesea ele fiind transformate n asociaii binare n faza de proiectare. Relaia de asociaie are mai multe caracteristici: 1. Nume este trecut deasupra liniei ce reprezint asociaia, nu foarte aproape de capete pentru a nu crea confuzii cu rolurile 2. Sens reprezentat printr-o sgeat adugat liniei de asociaie pentru a ti n ce direcie trebuie citit numele n general asocierile nu au un sens precizat, dar uneori acesta este folosit pentru o mai bun nelegere a asocierii.

Figura 9 Reprezentarea rolurilor i numelui asociaiei

3. Rolul jucat de fiecare clas n cadrul asocierii se reprezint n imediata apropiere a acesteia, sub linia de asociere i este opional. Indicarea rolului este important mai ales dac exist legturi ntre obiecte ale aceleiai clase, care instaniaz o asociaie de la o clas la ea nsi. 18

4. Multiplicitatea se poate specifica la fiecare capt al asociaiei. Ea arat cte obiecte instaniate din acea clas pot fi asociate unui singur obiect de la cellalt capt al asociaiei. Multiplicitatea se specific printr-un numr sau printr-un interval de forma LimitaInferioar .. LimitaSuperioar pentru care se folosesc numere sau caracterul *. Astfel multiplicitatea poate apare n formele: Clasa 1 Clasa 1 Clasa 1 Clasa 1 * 3 * 0,,* 1..5 Clasa 2 Clasa 2 Clasa 2 Clasa 2 Orict de multe Exact 3 Zero sau mai multe ntre 1 i 5 Mulime specificat

Clasa 1

1, 3, 4, 7

Clasa 2

Tabelul 3 Multiplicitatea asocierilor

n cazul unei multipliciti mai mari dect 1, obiectele din acel capt al relaiei pot fi ordonate prin introducerea cuvntului cheie { ordered}. Dac acesta nu apare, se consider c obiectele sunt neordonate i formeaz o mulime. Declaraia nu menioneaz modul de ordonare, dar acesta se poate specifica prin adugarea unei restricii. Sortarea elementelor dup proprietile interne este, n general, precizat n etapa de proiectare. Tot n cazul unei multipliciti mai mari dect 1, exist facilitatea de a extrage o submulime de obiecte asociate, prin intermediul unui sau mai multor atribute ale asociaiei, numite calificatori. n acest caz, multiplicitatea atribuit captului opus trebuie s reflecte cardinalitatea submulimii de obiecte selectate de ctre calificator. Calificatorul se reprezint printr-un dreptunghi mic, lipit de clas, ntre aceasta i linia de asociaie.

Figura 10

Este posibil unele relaii de asociaie, avnd o clas comun, s nu poat fi instaniate simultan, existnd la un moment dat legturi numai pentru una dintre ele. O asemenea situaie se modeleaz printr-o asociaie de tip sau-exclusiv, reprezentat prin conectarea asociaiilor cu o linie punctat, nsoit de o etichet cu restricia { xor}.

19

Figura 11

Exemplu cu asocieri multiple

Figura 12

Relaii de agregare i compoziie Relaia dintre o clas care reprezint un ntreg i clasele din care se instaniaz prile sale componente este modelat n mod distinct de asociaie, existnd dou situaii particulare: 1. obiectele componente exist i n mod independent de ntreg, caz n care relaia este un caz particular de asociaie, numit agregare. El este notat printr-un romb gol plasat ntre clasa-container i linia de asociaie. Exemplu:

20

Figura 13

2. ntregul i componentele sale au timpi de via egali, obiectele fiind instaniate, respectiv, distruse simultan. Atunci legtura devine mai puternic i se numete compoziie. Notaia acestei relaii este o linie de la o clas la componentele sale avnd cte un romb plin ataat ntregului. Exemplu:

Figura 14

Agregarea i compoziia au proprieti similare asociaiei, cu condiia ca unul dintre capete, cel dinspre ntreg, s nu aib multiplicitate mai mare dect 1.

Sugestii metodologice
UNDE PREDM? Coninutul poate fi predat n laboratorul de informatic sau ntr-o sal care are videoproiector sau flipchart. CUM PREDM?

Se recomand utilizarea calculatoarelor pentru activitile de nvare i de fixare a noilor cunotine. Este indicat folosirea, ca metode de predare, a problematizrii, a nvrii prin descoperire, a exerciiului. Ca materiale suport se pot folosi: O prezentare multimedia care s cuprind noiunile despre asocieri i modalitatea realizrii acestora ntr-o aplicaie software. Activiti interactive: o de tip rebus cu noiunile nvate o de tip asociere ntre relaii i proprietile lor o de tip drag & drop pentru crearea diagramelor Un studiu de caz cu tema Magazin Clasa poate fi organizat frontal sau pe grupe de 3-4 elevi. Ca materiale de evaluare se pot folosi: 21

o Probe orale, scrise i practice, frontale, individuale i sumative o Proiecte pe grupe de 3-4 elevi

22

Tema 4. Descrierea obiectelor folosind UML

Fia suport 4. Diagrama de obiecte
Diagramele de obiecte sunt grafuri ce au ca noduri obiectele i ca arce legturile dintre acestea, mapate dup diagramele claselor corespunztoare. Ele au o aplicabilitate mai restrns, fiind utile pentru a indica unele situaii particulare, cum ar fi cazuri de testare. Unei diagrame de clase i corespunde un numr nelimitat de diagrame de obiecte instaniate din acestea i descriu starea n detaliu la un moment dat. Reprezentarea obiectelor n diagramele UML obiectele se reprezint n mod similar claselor, n dreptunghiuri cu un singur compartiment sau cu dou compartimente. Primul compartiment conine numele obiectului i numele clasei separate de :, ambele fiind subliniate. Al doilea compartiment, opional, conine atributele cu tipul lor de date i valoarea specific obiectului. Este posibil specificare mai multor clase din care va fi instaniat obiectul, separate prin virgul.

Figura 15. Reprezentare obiectelor

n plus exist reprezentri specifice pentru urmtoarele tipuri de obiecte: Obiecte compozite sunt instaniate din clase compozite; au, de fapt, pri componente (obiecte) instaniate din alte clase, acestea fiind reprezentate n locul atributelor.
1. 2. Multiobiecte reprezint o mulime de obiecte care vor fi tratate n acelai mod n carul diagramei de obiecte (corespunztoare unei asocieri ntre clase cu multiplicitate mai mare dect 1)

Obiect activ este un obiect care particip la controlul aplicaiei, adic trimite stimuli i din proprie iniiativ, nu numai ca rspuns la primirea unei cereri din exterior
3.

Figura 16

23

Legturi ntre obiecte O legtur ntre obiecte este o instaniere a unei relaii de asociaie dintre clasele din care au fost instaniate obiectele. n general, legturile sunt binare, dar pot exista i legturi ternare sau chiar legturi de ordin superior, reprezentate printr-un romb conectat prin linii la obiectele legate ntre ele. n cazul obiectelor, legturile nu au nume, ele fiind identificate prin intermediul obiectelor pe care le leag. O legtur ntre obiecte poate prelua din proprietile caracteristice ale asociaiei: numele asociaiei, sensul, rolurile capetelor, specificarea agregrii sau a compoziiei la un capt. Multiplicitatea nu are semnificaie deoarece legturile sunt la nivelul instanelor. La capetele legturilor se pot ataa stereotipuri pentru a indica diferite tipuri de implementare: 1. <<association>> - implementarea tipic prin asociaie, care nu trebuie specificat de obicei 2. <<parameter>> - ca parametru al unei metode 3. <<global>> - ca variabil global 4. <<local>> - ca variabil local a unei metode 5. <<self>> - cu posibilitatea ca obiectul s-i trimit mesaje lui nsui

Sugestii metodologice
UNDE PREDM? Coninutul poate fi predat n laboratorul de informatic sau ntr-o sal care are videoproiector sau flipchart.

CUM PREDM? Se recomand utilizarea calculatoarelor pentru activitile de nvare i de fixare a noilor cunotine. Este indicat folosirea, ca metode de predare, a problematizrii, a nvrii prin descoperire, a exerciiului. Ca materiale suport se pot folosi: O prezentare multimedia care s cuprind modalitatea realizrii diagramelor de obiecte ntr-o aplicaie software. Activiti interactive: o de tip drag & drop pentru crearea diagramelor Un studiu de caz cu tema Magazin Clasa poate fi organizat frontal sau pe grupe de 3-4 elevi. Ca materiale de evaluare se pot folosi: 24

o Probe orale, scrise i practice

Tema 5. Mediul de dezvoltare specific POO

Fia suport 5. Prezentare general, faciliti
Un mediu de dezvoltare integrat (integrated development environment IDE) este un set de aplicaii care combin toi paii necesari crerii unui proiect (ex.: editarea codului surs, compilarea, depanarea, testarea, generarea de documentaie) ntr-un singur program care, de regul, ofer o interfa grafic prietenoas. Aceste programe pot fi comerciale sau open-source. De obicei un mediu de dezvoltare este dedicat unui anumit limbaj de programare, astfel nct s ofere un set de caracteristici care se potrivete cel mai bine programrii n limbajul respectiv. ns exist la ora actual i medii de dezvoltare care suport mai multe limbaje (C/C++, Java, Php), de ex. Eclipse, NetBeans, Microsoft Visual Studio. Suportul pentru mai multe limbaje este furnizat de plugin-uri ce pot fi instalate n acelai IDE n acelai timp. De asemenea exist IDE-uri ce pot funciona pe mai multe platforme (Linux, Windows, Mac). Interfaa unui IDE conine: meniuri i bare de instrumente (specifice fiecrui IDE), editorul de cod surs, o zon de management ce cuprinde un navigator de proiect (de unde putem accesa uor o anumit clas sau un anume fiier), un navigator de resurse (de unde putem accesa uor o resurs a interfeei grafice creat de proiect). Editorul de cod surs asigur: sintax evideniat personalizabil, indentarea automat a codului, navigarea uoar (printr-o tast sau o combinaie de taste) ntre fiierele .h i .cpp cu acelai nume, managementul listei to do n proiectele la care lucreaz mai multe persoane. O facilitate important a editorului este completarea automat (code completion) a codului sub dou aspecte: completarea numelor de clase, obiecte, metode, etc. dup tastarea a 1-2 caractere apoi a unei taste sau furnizarea de indicii la completarea argumentelor funciilor sau la accesarea membrilor unei clase.

Sugestii metodologice
UNDE PREDM? Se recomand ca aceste coninuturi s fie predate n laboratorul de informatic. Clasa poate fi organizat frontal.

CUM PREDM? Se poate folosi o prezentare multimedia a interfeei unui IDE sau, cu ajutorul unui videoproiector, profesorul exemplific facilitile oferite de IDE Pentru fixarea acestor coninuturi se recomand efectuarea unor activiti de personalizare a mediului de dezvoltare ales. Este util ca mediul de dezvoltare integrat s suporte mai multe compilatoare (gcc, Borland C++, MSVC++, etc), iar majoritatea dintre ele au aceast facilitate. La compilare se pot crea dou tipuri de fiiere executabile: debug i release. De asemenea, la crearea unui proiect nou se poate alege dintre mai multe opiuni de compilare: ca un program consol, ca o librrie dinamic (.dll), ca o librrie static (.lib) 25

sau ca o aplicaie GUI. n majoritatea mediilor de dezvoltare exist posibilitatea de a importa proiecte create n alte medii de dezvoltare. Depanatorul (debugger-ul) asigur n majoritatea IDE-urilor: 1. Suport pentru breakpoint-uri n cod , la nivelul datelor i condiionale 2. Afiarea argumentelor i variabilelor locale funciilor 3. Afiarea apelurilor pe stiv 4. Rularea programului pas cu pas i urmrirea modificrii valorilor unui set de variabile (ales de programator) n fereastra watches 5. Vizualizarea unei linii de cod n cod main sau limbaj de asamblare; vizualizarea regitrilor procesoruluis Mediile de dezvoltare ce permit crearea de aplicaii GUI ofer posibilitatea crerii acestor interfee interactiv, prin drag&drop, iar ca suport ofer librrii de obiecte predefinite pentru elementele interfeei grafice (meniuri, butoane, casete text, csue de validare, ferestre de dialog, etc.).

Sugestii metodologice
CUM PREDM? Pentru fixarea cunotinelor se recomand activiti de scriere, compilare, rulare, rulare pas cu pas, depanare a unor programe simple. Se recomand ca aceste activiti s fie realizate individual, n msura posibilitilor, pentru deprinderea lucrului cu mediul IDE. Se pot desfura i activiti interactive de tip rebus sau de asociere ntre diverse noiuni noi sau deja cunoscute. Ca materiale de evaluare se pot folosi probe practice i orale

26

Tema 6. Definirea claselor

Fia suport 6. Concordana cu elementele obinute la modelare
Dup cum am vzut n tema 1, fia 1.3 aplicaiile software folosite n modelare au facilitatea de a genera cod surs pentru diagramele de clase create n limbaj UML. Codul generat este reprezentat de fiiere header asociate fiecrei clase din diagrame, urmnd ca implementarea (fiierele .cpp, n C++) s fie scrise de ctre programator. Chiar dac implementarea reprezint o simpl translaie a deciziilor de proiectare ntrun limbaj particular, i aici trebuie luate unele decizii; acestea trebuie gndite cu responsabilitate astfel nct s afecteze o parte ct mai mic din program, iar schimbrile s se fac cu uurin. De asemenea, la luarea unor astfel de decizii, trebuie avut n vedere pstrarea unei concordane ntre codul surs obinut la implementare i modelul din faza de proiectare. Un software de calitate nu satisface doar cerine funcionale, ci urmrete anumite criterii cum ar fi: corectitudinea, reutilizarea codului, extensibilitatea, robusteea i rapiditatea n depanare. Pentru ndeplinirea acestor criterii trebuie folosit un stil de programare bazat pe reguli bine stabilite. Cteva dintre aceste reguli ar fi: 1. Definirea unor metode coerente, ntr-o singur funcie sau ntr-un grup de funcii strns legate ntre ele 2. Metodele similare trebuie s foloseasc nume, condiii, ordine a argumentelor, tipuri de date, valoare returnat i condiii de eroare 3. Separarea metodelor de implementare (care efectueaz calcule, au argumente bine specificate, conin adesea algoritmi complicai) de metodele de tactic (culeg contextul global, iau decizii, verific starea i erorile) 4. Dac exist mai multe combinaii posibile ale condiiilor de intrare este recomandabil s se scrie metode pentru toate cazurile posibile, nu doar pentru cele strict necesare 5. Realizarea ncapsulrii claselor (numai metodele clasei ar trebui s acceseze implementarea sa), ascunderea structurii de date, evitarea traversrii multiple a legturilor i metodelor, stabilirea cu grij a operaiilor publice i a celor private; 6. Documentarea claselor i metodelor prin descrierea scopului, contextului, funcionalitii, intrrilor i ieirilor, algoritmul folosit pe scurt O parte dintre aceste criterii sunt ndeplinite nc din faza de proiectare, dar ele trebuie avute n vedere pe tot parcursul procesului de implementare. O astfel de situaie o reprezint implementarea relaiilor de asociaie dintre clase pentru care exist dou strategii: 1. Prin pointeri, definii ca membri ntr-o clas, ctre obiecte de clas asociat 2. Prin abstractizarea asociaiilor n clase distincte cu atribute i metode proprii 27

Dac relaia de asociaie este simpl (1:1) se implementeaz imediat folosind prima strategie. Dac asociaia este multipl (1:n), prin aceeai strategie, se poate implementa uor folosind un tablou de pointeri la obiecte de clas asociat. Dac ordinul de multiplicitate este mic se pot folosi pointeri distinci. Dac asociaia este supus unei restricii de ordonare atunci tabloul este nlocuit cu o list nlnuit. Dac asociaia are multiplicitatea (n:m), atunci este indicat implementarea folosind a doua strategie. Corespunztor asociaiei este creat o clas ce funcioneaz ca un dicionar. Un obiect din aceast clas devine o legtur, iar imaginea sa n memorie devine un tablou dinamic de perechi. Dac asociaia are i calificatori, atunci fiecare pereche se transform n triplet. Pe de alt parte, ns, implementarea asociaiilor cu ajutorul pointerilor impune relaxarea ncapsulrii pentru clasa asociat. Aceasta deoarece, traversarea unei asociaii, presupune accesul la membrii privai ai clasei asociate de ctre metode din cealalt clas. Relaxarea ncapsulrii unei clase n vederea asocierii se poate realiza prin: 1. Selectarea mai multor membri ca i membri publici, dar astfel se anuleaz orice ncapsulare. 2. Extinderea interfeei publice cu metode suplimentare de acces la membrii privai, dar apelul iterativ al acestor metode poate compromite viteza programului. 3. Declararea de clase i metode prietene (friend), care ofer un compromis ntre tendinele de relaxare ale metodelor 1 i 2. Deoarece agregarea i compoziia sunt cazuri particulare de relaii de asociaie, implementarea lor are n vedere situaiile de mai sus.

Sugestii metodologice
UNDE PREDM? Coninutul poate fi predat n laboratorul de informatic sau ntr-o sal care are videoproiector sau flipchart. CUM PREDM? Ca materiale suport se pot folosi o prezentare multimedia, fie de lucru, studiu de caz. Se recomand ca activitile de fixare a cunotinelor s se desfoare pe grupe de elevi; fiecare grup s primeasc o diagram UML ca cea din figura 12, s abordeze o metod de implementare a claselor i a asociaiilor, iar apoi s se organizeze o dezbatere n care se vor discuta soluiile tuturor echipelor. Ca materiale de evaluare se pot folosi probe scrise i orale

28

Tema 7. Motenire
Fia suport 7. Motenire Sugestii metodologice
Pentru predarea acestor coninuturi se recomand recapitularea informaiilor din fia suport I.1.2 i din fia suport I.3 despre motenire, clase derivate, modificatori de acces. Reamintim c derivarea privat asigur motenirea membrilor publici i protejai din clasa de baz ca membri privai ai clasei derivate; Derivarea protejat asigur motenirea membrilor publici i protejai din clasa de baz ca membri protejai ai clasei derivate; Derivarea public, implicit, asigur motenirea membrilor publici ca membri publici n clasa derivat, iar a celor protejai ca membri protejai ai clasei derivate. class Baza { // } class Derivata : private Baza { // } class Baza { // } class Derivata : protected Baza { // } class Baza { // } class Derivata : public Baza { // }

Deoarece o clas derivat are membri n plus fa de clasa de baz atunci la instanierea unui obiect din clasa derivat se va apela mai nti constructorul clasei de baz, apoi constructorul clasei derivate. La distrugerea obiectului de clas derivat destructorii se vor apela n ordine invers, mai nti cel din clasa derivat, apoi cel din clasa de baz. n cazul unei ierarhii de clase cu mai multe nivele apelarea constructorilor, respectiv a destructorilor are loc recursiv, dup procedeul descris mai sus. Se observ c trebuie ca cel puin un constructor i destructorul din clasa de baz s fie publici; altfel nu s-ar putea instania obiecte de clas derivat. Constructorul i destructorul clasei de baz sunt apelate la crearea i distrugerea obiectelor claselor derivate, dar nu sunt motenite de ctre clasele derivate.

Sugestii metodologice
UNDE PREDM? Coninutul poate fi predat n laboratorul de informatic sau ntr-o sal care are videoproiector sau flipchart. CUM PREDM? Ca materiale suport se pot folosi o prezentare multimedia, fie de lucru, studiu de caz. Se recomand ca activitile de fixare a cunotinelor s se desfoare pe grupe de elevi. Se vor realiza programe exemplu ce vor evidenia derivarea public, privat i protejat, precum i ordinea apelrii constructorilor i a destructorilor. Se poate organiza o dezbatere a acestor situaii ntre grupe de elevi. 29

n cazul n care constructorul clasei de baz ateapt un argument, acesta trebuie s-i parvin. Acest lucru se realizeaz prin intermediul constructorului din clasa derivat. Este permis att clasei derivate, ct i clasei de baz s utilizeze acelai argument. Urmtorul exemplu descrie acest concept n limbajul C++ . class A { public: int a; A(int n) { a = n; } //aceasta se execut nti ~A() {} }; class B : public A { public: int b; B ( int m ) : A( m ) { b = m; } // aceasta se execut a doua B( int, int ); ~B(); } B :: B( int n1, int n2 ) : A( n1 ) { b = n2; } // sau aceasta se execut a doua Deoarece o clas derivat poate fi privit ca o extensie a clasei de baz, limbajul C++ permite conversia unui obiect de clas derivat la un obiect de clas de baz. Conversia invers este imposibil i ilegal. Exemplu: considernd clasele declarate mai sus i instanierea obiectelor oba de clas A i obb de clas B, atunci atribuirea obb = oba este greit, pe cnd atribuirea oba = obb este corect.

Redefinirea metodelor prin motenire Sugestii metodologice

CUM PREDM? Folosind urmtorul exemplu, prin problematizare i dezbatere, se vor evidenia cazurile posibile de motenire a funciilor din clasele de baz i redefinirea lor. class B { public: int f(); int f(s:string); void g(); }; class D1 : public B { public: void g(); };

Clasa B conine funcia f suprancrcat (cu dou definiii).

Clasa D1 redefinete funcia g, motenit din clasa de baz, lsnd neschimbate cele dou funcii f. Astfel , dintr-un obiect de clas D1 vom putea accesa ambele metode f (motenite) i metoda g redefinit. 30

class D2 : public B { public: int f(); };

Clasa D2 redefinete numai una din cele dou funcii f din clasa de baz. Rezultatul este c cele dou funcii suprancrcate din clasa de baz devin inactive pentru un obiect de clas D2; singurele funcii care pot fi apelate sunt funcia f redefinit i funcia g motenit din clasa de baz. Clasa D3 este similar cu clasa D2, diferena fiind c la redefinirea funciei f se schimb tipul de return.

class D3 : public B { public: void f(); }; class D4 : public B { public: int f(int i); };

Clasa D4 scrie o nou versiune a funciei f (schimb prototipul funciei); i n acest caz noua versiune este singura disponibil pentru un obiect de clas D4, cele din clasa de baz fiind ascunse.

Motenirea multipl
Motenirea multipl presupune existena mai multor clase de baz, din care una sau mai multe clase derivate motenesc anumite caracteristici. Este un concept suportat doar de unele limbaje (de exemplu, C++, dar nu i de Java). Acest concept, destul de controversat, sprijin reutilizarea i extensibilitatea resurselor soft gata puse la punct. El permite o mai mare flexibilitate i simplitate n definirea de noi clase pornind de la clase existente. Sintaxa de declarare a unei clase derivate din mai multe clase de baz este class D { // } : public B1, protected B2

O situaie mai delicat intervine atunci cnd clasele B1 i B2 sunt ambele derivate dintro aceeai clas A. Astfel apare situaia n care un obiect de clas D poate moteni de dou ori acelai atribut din clasa A, odat prin intermediul clasei B1, iar a doua oar prin intermediul clasei B2 (vezi figura 17).

Figura 17

n limbajul C++acest lucru este evitat prin moteniri multiple virtuale. Ca atare, clasele B1 i B2 se definesc astfel: class B1 : virtual public A 31 {};

class B2 : virtual protected A

{};

O clas virtual poate fi iniializat explicit, dar ea trebuie s aib i un constructor care poate fi apelat fr argumente sau unul n care toate argumentele au valori implicite. Regulile de apelare a constructorilor claselor de baz sunt: Constructorii claselor virtuale se apeleaz naintea celor corespunztori claselor ne-virtuale. Pentru o clas cu mai multe clase de baz virtuale, constructorii acestora se apeleaz n ordinea n care clasele au fost declarate n list, apoi se apeleaz constructorii claselor de baz ne-virtuale i la sfrit cei ai claselor derivate. Dac n ierarhia claselor de baz exist mai multe instanieri ale unei clase de baz virtuale, constructorul respectiv va fi apelat o singur dat. Dac n ierarhie exist att instanieri virtuale, ct i ne-virtuale ale aceleiai clase de baz, constructorul va fi apelat o singur dat pentru toate instanierile virtuale i de fiecare dat pentru fiecare instaniere ne-virtual.

Sugestii metodologice
CUM PREDM? Folosind problematizarea, studiul de caz i dezbaterea, se vor se vor rezolva probleme de genul: Folosind clasele Punct, Cerc, Vrf s se implementeze clasa Con folosind clase virtuale. UNDE PREDM? Se recomand ca aceste coninuturi s fie predate n laboratorul de informatic. Clasa poate fi organizat frontal sau pe grupe de elevi.

32

Tema 8. Aplicaii ale polimorfismului n POO

Fia suport 8. Aplicaii ale polimorfismului n POO
Polimorfismul se poate manifesta doar asupra claselor aflate n relaie de derivare i prin intermediul obiectelor identificate prin variabile de tip pointer sau referin la aceste clase. Astfel metodele unei clase pot fi metode clasice, ce sunt legate static sau timpuriu (early-binding) i metode polimorfice, ce sunt legate dinamic sau trziu (latebinding). Legarea timpurie (static) este cazul implicit, tipic, folosit de majoritatea limbajelor de programare. Prin legarea static i revine compilatorului sarcina fixrii adresei de la care se apeleaz o metod. Odat aceast adres fixat, ea nu mai poate fi modificat pe parcursul rulrii programului. Legarea trzie (dinamic) permite amnarea deciziei de fixare a adresei de apel a metodei pn n momentul rulrii programului. Compilatorul doar pregtete un tablou de adrese posibile de apel. n momentul rulrii, n funcie de valoarea unui pointer la o clas de baz, care poate puncta i la un obiect de clas derivat, se alege adresa de apel dorit. Marele avantaj al legrii dinamice, fa de legarea static, const n faptul c ofer un grad minim de flexibilitate. Astfel ierarhiile sunt mai uor de implementat i mai uor de exploatat. Marele dezavantaj al legrii dinamice, fa de legarea static, const n diminuarea performanei de vitez, deoarece legarea dinamic presupune un efort suplimentar de alegere dintr-un tablou de pointeri la metode, pe cnd o metod legat static se apeleaz direct i imediat.

Metode virtuale
Implicit, funciile sunt legate static. Cererea de legare dinamic trebuie solicitat explicit la declararea funciei. Acest lucru se realizeaz n limbajul C++ prin cuvntul cheie virtual plasat, la declarare, naintea numelui funciei din clasa de baz. O metod declarat virtual ntr-o clas de baz i poate fi motenit ca atare ntr-o clas derivat sau poate fi nlocuit cu o alt variant proprie clasei derivate. Funcii virtuale implementeaz ideea o singur interfa, mai multe metode, care pune n eviden polimorfismul. Astfel programul devine mai uor de neles i dezvoltat, deoarece existena unei interfee comune, prin care avem acces la multe aciuni, implic memorarea unui numr mai mic de elemente. Funciile virtuale au urmtoarele caracteristici i restricii: 1. Aproape orice metod poate fi virtual, chiar i metodele inline i metodele friend (dar nu i funciile inline sau funciile friend), operatorii (dac nu se redefinesc prin funcii friend). 2. Constructorii i metodele statice nu pot fi virtuale, dar destructorii da. 33

3. Dac o funcie este declarat virtual ntr-o clas de baz, orice redefinire cu acelai prototip n ntreaga ierarhie de clase derivate din clasa de baz este supus legrii dinamice. 4. Redeclararea i redefinirea funciilor virtuale n clasele derivate nu sunt obligatorii. 5. Funciile declarate virtuale ntr-o clas de baz i redefinite cu acelai prototip ntr-o clas derivat sunt automat identificate ca virtuale, deci cuvntul virtual poate lipsi. 6. Pentru ca mecanismul funciilor virtuale s funcioneze, funcia nu poate fi redeclarat n clasele derivate ca avnd aceiai parametri, dar un alt tip de dat returnat. Este permis ns redeclararea cu alt set de parametri i acelai tip de dat returnat, dar aceasta este considerat o nou funcie, creia nu i se aplic mecanismul de legtur dinamic, deci nu va putea fi motenit mai departe ca funcie virtual. 7. O funcie virtual F redefinit dintr-o clas derivat D va fi vzut n noua form de ctre toate clasele derivate din D, rmnnd n continuare virtual pentru acestea.

Sugestii metodologice
CUM PREDM? Folosind problematizarea, studiul de caz i dezbaterea, se vor analiza diverse situaii ce impun folosirea metodelor virtuale. Se pot folosi activiti de nvare de tipul gsirea greelilor dintr-un cod surs. UNDE PREDM? Se recomand ca aceste coninuturi s fie predate n laboratorul de informatic. Clasa poate fi organizat frontal sau pe grupe de elevi. Se recomand ca activitile de nvare ce impun scrierea de cod surs s fie rezolvate individual.

Metode virtuale pure. Clase abstracte

O metod virtual poate fi specificat ca metod virtual pur dac este numai declarat, nu i definit, iar iniializarea acesteia se face cu valoarea 0. acest lucru i spune compilatorului c nu exist nici un corp pentru aceast funcie din clasa de baz. Prin urmare, nu se pot crea obiecte ale unei clase ce conin funcii virtuale pure. n limbajul C++ metodele virtuale pure se specific astfel: virtual void f() = 0; O clas se numete clas abstract dac conine cel puin o metod virtual pur. Mecanismul funciilor virtuale pure a fost introdus pentru a permite o difereniere ntre clasele abstracte i clasele obinuite. Specificarea unei clase ca o clas abstract se realizeaz prin cuvntul abstract care precede numele clasei. 34

O clas abstract nu poate fi instaniat, rolul ei fiind doar de nod n construirea ierarhiilor de clase. implicit o clas derivat dintr-o clas abstract rmne abstract. Ea devine o clas ordinar (obinuit), instaniabil, doar dac redefinete toate metodele pure motenite de la clasa de baz. Dei o clas abstract nu poate fi instaniat, se poate defini o variabil de tip pointer sau referin la o clas abstract. Clasele abstracte corespund conceptelor care nu au o reprezentare material imediat, dar sunt foarte utile pentru a surprinde trsturile comune ale unei serii de clase cu posibiliti de materializare imediat. Aceste trsturi comune sunt enumerate la nivelul clasei abstracte de baz, iar fiecare clas derivat le implementeaz specializat. n general, clasele abstracte se plaseaz n vrful ierarhiilor de clase i ele au rolul de a abstractiza comportarea subclaselor specializate.

Interfee
O interfa este o declaraie de tip care definete de obicei un comportament. O declaraie de interfa introduce un tip referin ai crui membri sunt constante i metode virtuale pure. Acest tip nu posed implementri (metodele nu sunt definite), dar anumite clase pot imlementa aceste interfee furniznd definiii pentru metodele virtuale pure (abstracte). n C++ nu exist tipul interfa n mod explicit n Java da. O interfa nu poate fi instaniat, deoarece cuprinde doar prototipurile metodelor. Imlementrile acestora vor fi scrise n clasa ce imlementeaz interfaa. O clas poate imlementa mai multe interfee; astfel se poate simula n limbajul Java mecanismul motenirii multiple ntlnit n C++.

Sugestii metodologice
Exemplul urmtor creeaz o clas Lista (drept interfa), imlementat prin clasele Coada i Stiva. Acest program poate fi realizat mpreun cu elevii i completat de ei cu alte clase, de exemplu o clas ce creaz o list simpl ordonat descresctor. Se pot folosi activiti de nvare de tipul gsirea greelilor dintr-un cod surs. #include<iostream.h> #include<stdlib.h> classLista{ public: Lista*cap; Lista*coada; Lista*urm_art; intvaloare; lista(){cap=coada=urm_art=NULL;} virtualvoidstocheaza(inti)=0; vitualintregaseste()=0; }; classCoada:publicLista{ 35

public: voidstocheaza(inti); intregaseste(); }; voidCoada::stocheaza(inti) { Lista*articol; articol=newCoada; if(!articol){ cout<<Eroarelaalocare<<endl; exit(1); } articol>valoare=i; if(coada) coada>urm_art=articol; coada=articol; articol>urm_art=NULL; if(!cap) cap=coada; } intCoada::regaseste() { inti; Lista*p; if(!cap){ cout<<Listaestevida<<endl; return0; } i=cap>valoare; p=cap; cap=cap>urm_art; deletep; returni; } classStiva:publicLista{ public: voidstocheaza(inti); intregaseste(); }; voidStiva::stocheaza(inti) { Lista*articol; articol=newStiva; if(!articol){ cout<<Eroarelaalocare<<endl; exit(1); } articol>valoare=i; if(cap) articol>urm_art=cap; 36

cap=articol; if(!coada) coada=cap; } intStiva::regaseste() { inti; Lista*p; if(!cap){ cout<<Listaestevida<<endl; return0; } i=cap>valoare; p=cap; cap=cap>urm_art;; deletep; returni; } intmain() { Lista*p; Coadac; p=&c; p>stocheaza(1); p>stocheaza(2); p>stocheaza(3); cout<<Coada:; cout<<p>regaseste()<<p>regaseste()<<p>regaseste()<<endl; Stivast; p=&st; p>stocheaza(1); p>stocheaza(2); p>stocheaza(3); cout<<Stiva:; cout<<p>regaseste()<<p>regaseste()<<p>regaseste()<<endl; return0; }

37

Unitatea de nvmnt __________________

IV. Fia rezumat

Clasa ________________ Nume i prenume elev Competena 1 A1 zz.ll.aaaa1 A2 AX A1 Competena 2 A2 A3 A1 Profesor ______________________ Competena 3 A2 A3 Observaii

Nr. Crt. 1 2 3 4 ... Y

zz.ll.aaaa reprezint data la care elevul a demonstrat c a dobndit cunotinele, abilitile i atitudinile vizate prin activitatea respectiv

38

Competene care trebuie dobndite Aceast fi de nregistrare este fcut pentru a evalua, n mod separat, evoluia legat de diferite competene. Acest lucru nseamn specificarea competenelor tehnice generale i competenelor pentru abiliti cheie, care trebuie dezvoltate i evaluate. Profesorul poate utiliza fiele de lucru prezentate n auxiliar i/sau poate elabora alte lucrri n conformitate cu criteriile de performan ale competenei vizate i de specializarea clasei. Activiti efectuate i comentarii Aici ar trebui s se poat nregistra tipurile de activiti efectuate de elev, materialele utilizate i orice alte comentarii suplimentare care ar putea fi relevante pentru planificare sau feed-back. Prioriti pentru dezvoltare Partea inferioar a fiei este conceput pentru a meniona activitile pe care elevul trebuie s le efectueze n perioada urmtoare ca parte a viitoarelor module. Aceste informaii ar trebui s permit profesorilor implicai s pregteasc elevul pentru ceea ce va urma. Competenele care urmeaz s fie dobndite n aceast csu, profesorii trebuie s nscrie competenele care urmeaz a fi dobndite. Acest lucru poate implica continuarea lucrului pentru aceleai competene sau identificarea altora care trebuie avute in vedere. Resurse necesare Aici se pot nscrie orice fel de resurse speciale solicitate:manuale tehnice, reete, seturi de instruciuni i orice fel de fie de lucru care ar putea reprezenta o surs de informare suplimentar pentru un elev care nu a dobndit competenele cerute.

Not: acest format de fi este un instrument detaliat de nregistrare a progresului elevilor. Pentru fiecare elev se pot realiza mai multe astfel de fie pe durata derulrii modulului, aceasta permind evaluarea precis a evoluiei elevului, n acelai timp furniznd informaii relevante pentru analiz.

39

V. Bibliografie
1. Ioni, Anca Daniela.(2003). Modelarea UML n ingineria sistemelor de programare: Editura ALL 2. Zmaranda, Rodica Doina.(2001). Elemente de programare orientat pe obiecte n limbajul C++, Craiova: Editura Universitii 3. Roman, Dan.(1996). Ingineria programrii obiectuale, Bucureti:Editura Albastr 4. Silaghi, Gheorghe Cosmin.(2005). Limbaje de programare, metode obiectuale. Ghid teoretic i pratic, Cluj-Napoca: Editura Risoprint 5. aru, Daniela. Ioni, Anca Daniela.(2000). Sisteme de programe orientate pe obiecte, Bucureti: Editura ALL 6. Zaharie, Dorin. Roca, Ioan.(2002). Proiectarea obiectual a sistemelor informatice, Bucureti: Editra Dual Tech 7. ***. La http://en.wikipedia.org/wiki/Unified_Modeling_Language. 5.05.2009 8. ***. La http://inf.ucv.ro/~giurca/courses/CB3105/resources/Introducere%20in %20UML.pdf. 7.05.2009 9. ***. La http://fmi.unibuc.ro/ro/cniv_2005/volum/documente/pdf/sectiuneaA/12 _ 16_Lungu.pdf. 4.05.2009

40