... Partea Partea a a II a:

Cursul 4 : Testarea programelor (b) ~18.03.2014... Partea a II a: 1/40

Cursul 4 : Testarea programelor (b) ~ 18.03.2014 http://www.cs.ubbcluj.ro/~per/web_page/cursuri.htm http://www.cs.ubbcluj.ro/~per/scs_per/vvss/vvss.html http://www.cs.ubbcluj.ro/~mfrentiu/lectures/verval/carte/html http://www.cs.ubbcluj.ro/~mfrentiu/lectures/verval/carte/v2cap3.rtf / /L /V V l/ /V2 f TESTAREA PROGRAMELOR Cursuri (a) 2013-2014... TESTAREA PROGRAMELOR (b) Noţiuni de bază Nivele de testare Criterii de alegere a datelor de test Testarea unui modul Criteriul cutiei negre Prelucrarea Imaginilor Cr_Re_Im Criteriul cutiei transparente Testarea de integrare Scientific Data Visualization 24 feb 20 apr 21 apr 27 apr Acoperirea tuturor 28 apr 8 iun Verificarea Testarea si validarea de sistem sistemelor soft 9 29 iun Semestrul II 30 6 iul instrucţiunilor, iunilor, 7 iul 13 iul Testarea Visualization and Validation de acceptare in Simulation 28 apr 25 mai arcelor, 26 iun 8 iun Structuri de Date şi Algoritmi 9 iun 19 iun condiţiilor iilor simple, Alte tipuri de testare Oop Rezultate şi Planificări drumurilor şi Organizarea testarii -_- testarea aleatoare. Exerciţii ii si probleme propuse 2/40

Cursul 4 : Testarea programelor (b) ~ 18.03.2014 Verificarea si validarea sistemelor soft Partea I. Corectitudinea programelor (F.M.) Cap.1 Cap 1 Corectitudinea algoritmilor (Curs 1) Cap.2 Dezvoltarea programelor din specificatii (Curs 2) Partea a II-a. Verificarea si validarea programelor (P.V.) Cap.3 Testarea programelor (Curs 3, 4) -_Cap.2 Inspectarea programelor (Curs 5) Curs: - Cursul 1 : Corectitudinea algoritmilor ~ 25.02.2014 Cursul 2 : Dezvoltarea programelor din specificatii ~ 4.03.2014 Cursul 3 : Testarea p programelor g ((a)) ~ 11.03.2014 -_Cursul 4 : Testarea programelor (b) ~ 18.03.2014 -_Cursul 5 : Inspectarea programelor ~ 25.03.2014 Cursul 6 :... 3/40

Tipuri de testare (în funcţie de: - testarea unui modul; - testarea de integrare; - testarea întregului sistem; - testarea regresivă; - testarea de acceptare. partea de program testată şi momentul testării ): 4/40

Testarea unui modul (Unit testing) Testarea unei unităţi ţ mici de program: funcţie, ţ procedură, clasă, modul (orice parte de program testabilă separat). De exemplu, dacă dorim să testăm procedura P(X,Z), în care în X reprezintă datele de intrare, iar Z rezultatele, vom scrie un mic program care să apeleze această procedură, după ce a iniţializat variabilele din X, iar apoi să tipărească rezultatele din Z. Deci echivalentul unui algoritm de forma: Algoritmul Driver este: Citeste X; P (X,Z); Tipăreşte Z Sfalgoritm. 5/40

... Testarea unui modul (Unit testing) Şi la testarea de integrare avem nevoie de astfel de algoritmi (drivere drivere) ) care să apeleze alte unităţide ţ program pentru ale testa. Este posibil ca în procedura P să se apeleze oaltă procedură G, care nu este încă scrisă si vom simula această procedură, pentru a putea face testarea, cât mai simplu (fără a avea procedura reala G). Procedura temporara (provizorie) G poate avea forma: Procedura G(u,r) este: Dacă u=c 1 atunci r:=e 1 sfdacă Dacă u=c 2 atunci r:=e 2 sfdacă... Dacă ă u=c k atunci r:=e k sfdacă ă sf-g. Această componentă provizorie G (stub stub) ) construită temporar doar pentru testare va fi înlocuită cu procedura reală G pe timpul testării de integrare. 6/40

Etape:... Testarea unui modul (Unit testing) a. Pregătirea testării: completarea unităţilor necesare la construirea unui program executabil. b. Alegerea cazurilor de testare pe principiul cutiei: negre (după specificaţia procedurii P) şi transparente (după textul procedurii P). c. Precizarea rezultatelor aşteptate (pentru fiecare caz de testare, pentru a putea decide uşor dacă rezultatele sunt corecte). d. Execuţii cu datele de intrare stabilite (pentru cele n cazuri de test stabilite). Dacă toate execuţiile au dat rezultate corecte, e, modulul se consideră testat, caz în care considerăm testarea completă (diferă de testarea exhaustivă). Dacă am depistat erori, corectarea lor a modificat textul algoritmului şi se trece la testarea regresivă. Testarea trebuie reluată de la primul caz de test sau, cel puţin, de la cele corespunzătoare drumurilor afectate de această schimbare. 7/40

Testarea unui modul (Unit testing)... Testarea unui mo În cazul în care dorim să testămo clasă (de obiecte), otestămca pe un singur modul (dacă aceste module sunt simple), sau să testăm separat fiecare metodă mai complicată, iar pentru întreaga clasă facem testare de integrare. Prima variantă este avantajoasă deoarece nu cere scrierea multor stub-uri. În general, testarea este o activitate costisitoare, timpul necesar fiind direct proporţional cu numărul cazurilor de test. De aici, o primă consecinţă pentru activitatea de programare este cerinţa de a concepe subalgoritmi cât mai simpli. În unele cărţi se limitează textul acestora la 50 linii (!), iar numărul drumurilor (deci al cazurilor de test) să fie cât mai mic! Chiar proceduri mult mai simple ar putea avea un număr mare de drumuri de parcurs, deci foarte multe cazuri de test. 8/40

Nivele de testare 1. Testarea unui modul 2. Testarea de integrare 3. Testarea de sistem 4. Testarea de acceptare 5. Alte tipuri de testare Organizarea testării Exerciţii şi probleme propuse 9/40

Testarea ea de integrare e Testarea produsului urmează testării tuturor modulelor sale (după ce modulele au fost testate individual). Faptul că subalgoritmii şi modulele (ce se vor asambla) au fost testate separat nu asigură funcţionarea corectă alor după asamblare. În plus nu întotdeauna două module sunt independente între ele. Adesea un modul interacţionează cu alte module. De exemplu, unul dintre cazurile: Modulul M 1 apelează ooperaţieoperaţie ţ ce aparţine ţ modulului M 2 2; Modulul M 1 foloseşte o structură de date ce nu-iaparţine aparţine; Operaţiile / Structurile modulului M 1 sunt folosite de alte module. La testarea separată a modulului M 1 trebuie să simulăm celelalte module cu care interacţionează, mai ales că adesea acestea încă nu sunt disponibile. După ce le-am realizat pe toate este normal să le asamblăm şi să observămcum funcţionează împreună. 10/40

... Testarea de integrare Testarea de integrare se referă la asamblarea tuturor modulelor pentru aobţine produsul final dorit. După ce fiecare modul a fost testat şi corectat, trebuie verificată comportarea globală a programului. În această situaţie, dacă se depistează ă anumite erori este mai dificilă ilă depistarea acestora. De aceea se recomandă o testare succesivă a integrării modulelor, fie prin metoda top-down down, fie prin metoda bottom-up up. Dacă la adaugarea unui nou modul apar erori, atunci avem motive să credem că erorile provin fie din interiorul acestui modul, fie din interfaţa cu celelalte module. La testarea de integrare trebuie să verificăm şi dacă funcţionarea programului este conformă cu ceea ce scrie în manualul de utilizare a produsului. 11/40

... Testarea de integrare Prima grijă în această etapă este de a verifica dacă toate modulele necesare sunt prezente şică ele sunt corect asamblate. Se verifică dacă funcţionează corect. interfeţele dintre module Există mai multe strategii de asamblare a modulelor: Strategia Big-Bang Bang (toate modulele deodată); sunt Testarea incrementală, cu adăugarea a câte un modul; Adăugarea unui grup de module apropiate între ele. compatibile Strategia Big-BangBang elimină testarea de integrare, trecând direct de la testarea fiecărei componente la testarea întregului sistem. Dacă nu sunt descoperite erori totul este în ordine, altfel însă este aproape imposibil de descoperit care modul e cauza erorii. În această situaţie trebuie să se revină la integrarea incrementală a modulelor pentru a descoperi care dintre ele cauzează eroarea. şi 12/40

... Testarea de integrare Testarea incrementală (adăugarea unui singur modul) are avantajul de a pune mai uşor în evidenţă modulul cu probleme, dar şi dezavantajul de a lungi mult timpul de integrare. În plus, ultimele două strategii mai au avantajul că permit efectuarea testării de integrare înainte de a fi disponibile toate modulele. Adăugarea unui grup de module este un compromis între primele două strategii şi este potrivită când sistemul este format din subsisteme care pot fi testate separat şi apoi asamblate. Se ştie că cele mai frecvente şi periculoase erori, deci care trebuie în mod special urmărite la testarea de integrare, sunt cele de interfaţă: corespondenţa între parametrii actuali şi cei formali adesea nu e respectată. Se recomandă schimbarea (refacerea) componentelor care au avut multe defecte pe timpul testării întrucât s-a constatat că astfel de componente au avut şi ulterior multe defecte. După modificarea unui modul (prin depanare) trebuie să refacem testarea acestui modul, apoi să continuăm testarea de integrare. 13/40

... Testarea de integrare Integrarea incrementală cere adăugarea a câte unui modul la programul existent. Ea poate porni de la modulul rădăcină (integrare top- down)sau de la cel mai inferior modul, (integrare bottom-up). De exemplu, la programul cu structura alaturată, integrarea top-down poate începe cu adăugarea modulului M22 la M1, iar pentru M21 şi M23 vom folosi stub-uri uri. Este nevoie şi de un înlocuitor (stub stub) ) pentru M33. M21 M1 M22 M23 Integrarea bottom-up poate începe cu adăugarea la M33 a modulului l M22 22, iar în loc de M1 vom folosi un driver. M31 M32 M33 14/40

... Testarea de integrare Se pot folosi oparte din drivere-le şi stub-urileurile de la testarea modulelor, dar uneori e nevoie de alte astfel de componente auxiliare, ceea ce măreşte durata testării. Integrarea top-down are marele avantaj faţă de integrarea bottom-up că pune în evidenţă erorile de concepţie mult mai devreme, fiind vorba de erori făcute în modulele superioare. La acest nivel stabilirea cazurilor de test se face de obicei bazându-nene pe specificaţia ţ produsului. Nu mai se poate vorbi de analiza întregului text al programului, care poate fi de zeci sau sute de mii de linii. 15/40

Testarea de sistem Odată asamblate toate modulele urmează testarea sistemului obţinut. Problemele urmărite sunt următoarele: Are sistemul lf funcţiile dorite? Funcţionează sistemul normal (uneori nici nu porneşte, sau nu poate fi instalat, sau nu îşi revine după o cădere de tensiune)? Are performanţele necesare (timp de răspuns corespunzător, acceptă volum mare de date)? Răspunde adecvat la condiţii neprevăzute? Scopul acestei testări este prevenirea descoperirii oricăror erori la testarea de acceptare. 17/40

... Testarea de sistem Testarea produsului urmează testării de integrare a tuturor modulelor sale. Testarea produsului se face în ipoteza că modulele sunt corecte, ştiindu-se că au fost testate individual. Aceasta nu înseamnă că întreg produsul obţinut td după ă it integrare este şii el acceptabil. tbil Se va face din nou otestare pe principiul cutiei negre, de data asta pentru produsul integrat. Pe lângă corectitudine se va verifica robusteţea acestuia, timpul de răspuns atunci când există o clauză contractuală care cere ceva în această direcţie, comportarea produsului la un volum mare de date reale. Se poate întâmpla ca produsul să funcţioneze corect la volume mici de date, dar incorect pentru un volum de date ce depăşeşte o anumită limită. 18/40

... Testarea de sistem Testarea produsului este o repetiţie înaintea testării de acceptare. Pe lângă corectitudinea rezultatelor obţinute se va pune un accent mai mare petoate calităţile care ar trebui să le aibă produsul conform prevederilor contractuale. Se va testa robusteţea produsului, observând comportarea lil lui la introducerea unor date intenţionat greşite. Se va testa comportarea lui în situaţii critice ca: prelucrarea unui volum mare de date (mult peste media obişnuită); clienţimulţi mulţiîn sistem (perioade de vârf); timpul de răspuns în aceste situaţii critice. De asemenea, se va testa modul de acces în sistem, securitatea datelor, dacă această problemă este importantă pentru beneficiar. 19/40

Testarea de acceptare Orice produs program este testat şi de către beneficiari în momentul recepţionării produsului. Această activitate se numeşte testare de acceptare a produsului respectiv. Testarea de acceptare se face de obicei cu date reale şi la această testare contează nu numai corectitudinea rezultatelor ci şi forma sub care sunt prezentate aceste rezultate cât şi utilitatea lor. Testarea de acceptare este otestare ca oricare alta, făcută după regulile prezentate, dar cel care o face este beneficiarul produsului. Din această cauză accentul epus nu pe alegerea datelor de test după criteriile menţionate, ci pe o testare cu date reale. Ea urmăreşte atât corectitudinea rezultatelor obţinute cât şi robusteţea produsului şi performanţele sale. 21/40

... Testarea de acceptare Diferenţa majoră între testarea de acceptare şi testarea făcută de realizatorii produsului constă în execuţia programului cu date reale nu cu date selectate artificial. O problemă ă poate apare şii din cauza volumului l de dt date utilizate, t în cazul real fiind uneori mult mai mare decât volumul eşantioanelor utilizate în timpul testării de integrare. În mare, validarea produsului se reduce la testarea de acceptare şi verificarea documentaţiei ţ de realizare şi de folosire a produsului. Se verifică dacă această documentaţie este completă, clară şi suficient de detaliată pentru afi utilă pe timpul întreţinerii programului. 22/40

Alte tipuri de testare e În mai multe situaţii un program este modificat. În primul rând, după depanare sunt descoperite erori care determină schimbarea programului. In al doilea rând, întreţinerea cere modificarea perfectivă, adaptivă, sau corectivă a programului. Ne întrebăm: după aceste modificări noul program mai dă aceleaşi rezultate la execuţiile deja făcute? Testările posibile în asftel de situaţii sunt: Testarea regresivă ~testarea efectuată după astfel de schimbări. Testarea de stress ~ testarea în condiţii ţ anormale. Testarea Beta ~ realizată de către beneficiar pe cazuri reale. 24/40

... Alte tipuri de testare Testarea regresivă este testarea făcută programului după astfel de schimbări. Experienţa a arătat că, de multe ori, încercând să se corecteze o eroare, depanarea a introdus altele. Este normal ca execuţiile ţ (testele testele) făcute să fie reluate, pentru a verifica dacă nu cumva modificările efectuate au introdus alte erori ri. De cele mai multe ori realitatea nu ne lasă să reluăm aceste execuţii din criză de timp. Şi oare nu este mai important să continuămcu cazurile de test neexecutate? Şansa de agăsi noi erori pare mai mare în aceste cazuri! Corect ar fi ca toate cele n cazuri de test să fie verificate prin execuţia programului cu acele date. Mai mult, este posibil ca în textul nou să fie introduse cazuri noi care trebuie adăugate celor n existente. 25/40

... Alte tipuri de testare Întrucât testarea regresivă urmează după fiecare modificare a codului, ea se va efectua de multe ori, chiar de sute de ori. Reiese foarte clar că este util ca execuţiile cazurilor de test să fie reluate automat, astfel ca testarea regresivă să ceară un efort cât mai mic din partea omului. Deci, se recomandă automatizarea testării! Testarea de stress este testarea t în condiţii anormale, în care volumul de date este foarte mare, sau numărul utilizatorilor sistemului este mult peste cel normal. De exemplu, un program care procesează osecvenţă de n numere funcţionează normal pentru valori obişnuite pentru n, dar poate să funcţioneze anormal pentru n=20000 20000. Testarea Beta este testarea făcută de beneficiar prin folosirea programului în cazuri reale. Adesea în decursul utilizării unui program beneficiarul descoperă funcţionări defectuoase. 26/40

... Alte tipuri de testare ~ Testarea Beta Este bine ca activitatea de testare să se reflecte într-un document scris. Acesta va conţine toate cazurile de test şi rezultatul testării. Care au fost execuţiile la care rezultatele nu au fost corecte, ce decizii s-au luat, la ce s-a ajuns. Nu întotdeauna oexecuţie incorectă se datorează unei erori în unitatea testată. Mai pot fi erori în drivere, stuburi sau în mediul de testare (de exemplu, se foloseşte un fişier de date care nu există, sau are date greşite). ş O problemă importantă care interesează multe persoane este evaluarea erorilor rămase după testarea sistemului. Ometodă de aaflaafla răspunsul la această întrebare este însămânţarea însămânţarea erorilor în produs înainte de testare. Fie k numărul erorilor însămânţate. Dacă în produs se află n erori din care prin testare au fost găsite t, iar din cele însămânţate au fost găsite s, atunci probabil că s / k = t / n deci n = k t/s astfel că în produs au rămas după testare n t=t (k/s 1) erori. 27/40

Organizarea a testării Este bine ca testarea să fie efectuată de o echipă formată din persoane specializate în activităţi de testare. Mărimea acestei echipe depinde de complexitatea produsului şide persoanele disponibile. Un produs mic poate fi testat de o singură persoană, unul ul mediu poate fi testat de doar două persoane (într într-o organizaţie ţ mică). Un produs mare, realizat într-o organizaţie mare, va fi testat de o echipă compusă din persoane specializate, instruite în testare, făcând parte din colectivul de verificare şi validare. Un membru al echipei de testare trebuie să aibă înclinaţii şi pricepere în a descoperi erori, o persoană cu experienţă în programare, nu un începător. Prima sarcină a acestei echipe este stabilirea unui plan de testare. Un astfel de plan trebuie să conţină: - scopul testării; - descrierea proiectului ce trebuie testat; - activităţile prevăzute aaveaavea loc; - documentele ce se vor redacta pentru a reflecta testarea făcută. 29/40

Planul testării trebuie să precizeze:... Organizarea testării toate activităţile care trebuierealizate, realizate, cine face fiecare activitate, când trebuie să aibă loc fiecare activitate ~ ordinea în care se vor efectua aceste activităţi (se va avea în vedere disponibilitatea subproduselor) toate nivelele de testare, toatemodulele t modulelece l trebuie testate, t t criteriile de acceptare. uneltelesoft de testare (care sunt acestea şi când se folosesc) activităţide instruire a persoanelor nou venite în activitatea de testare. Planul de testare trebuie analizat (de echipa de testare cu proiectului şi dezvoltator): Activităţile prevăzute sunt corecte, în ordine complete? Resurse sunt suficiente (timp, persoane, echipamente)? Lista documentelor elor (prevăzute afi realizate)este completă? şeful corespunzătoare, 30/40

Testarea este o activitate complexă (conţine conţine): testarea tuturor modulelor, testarea de integrare, testarea de regresie, testarea sistemului.... Organizarea testării Planul testării trebuie să ia în considerare şi termenul de predare prevăzut. Daca nu pot fi realizate toate activităţile necesare, se vor căuta modalităţidede economisire a timpului. De exemplu, testarea modulelor poate fi redusă la inspectarea testării făcută de realizatorul fiecărui modul. În această situaţieie este necesară o documentaţie a acestei testări, în care se găsesc cazurile de test folosite, împreună cu rezultatul testării, iar echipa de testare va controla prin sondaj câteva execuţii (dacă va considera că este necesar, va adăuga câteva cazuri de test). 31/40

... Organizarea testării Testarea trebuie să pornească de la o înţelegere clară acerinţelor proiectului. Ea trebuie să îmbine testarea funcţională cu testarea structurală pentru fiecare modul. Iar pentru întregul sistem să realizeze testarea performanţelor sistemului. Stabilirea cazurilor de test este una din activităţile dificile în testarea programelor. Scopul testării este descoperirea deficienţelor, iar cazurile de test trebuie să fie alese cu acest scop. Si din acest motiv se recomandă ca alegerea acestor cazuri şi testarea în întregime să fie făcute de alte persoane, diferite de autorul produsului. Adesea un program foloseşteş baze de date, iar execuţiaţ lui modifică aproape întotdeauna baza de date. La testarea de regresie, cât şila alte execuţii ale programului, este nevoie să folosim baza de date iniţială. Planul testării trebuie să aibă în vedere şiastfel de situaţii. ţ Testarea cere resurse importante, timp şi echipamente. Se ştie că ea cere peste 25% din efortul de realizare a produsului. Testarea înseamnă numeroase execuţii ale modulelor sau diferitelor versiuni la testarea de integrare. Ce facem atunci când resursele sunt limitate, când procesul soft este mult în întârziere? 32/40

... Alte tipuri de testare ~ Organizarea testării Lipsa documentelor este un alt obstacol în desfăşurarea normală a testării. În primul rând este nevoie de specificarea produsului, dar şi celelalte documente, cu proiectarea de ansamblu şi de detaliu, codul sursă, sunt toate necesare în diferite faze ale testării. Evident, planul testării trebuie îndeplinit. El cere stabilirea cazurilor de test, execuţiile ţ corespunzătoare, raportarea deficienţelor ţ observate celor vizaţi, redactarea concluziilor testării. Existenţa unei deficienţe duce la depanare, în vederea eliminării ei. Această depanare trebuie făcută de autorul produsului defect nu de persoanele care fac testarea. Evident, după depanare va urma testarea de regresie. Testarea trebuie să lase în urma ei un document al testării. Acesta va conţine în detaliu toate activităţile desfăşurate, toate cazurile de testare efectuate, cu rezultatele obţinute şi deciziile luate. Documentul de testare este una din părţile ă documentului deverificare şi i validare a produsului final. 33/40

... Alte tipuri de testare ~ Organizarea testării Principii în activitatea de testare: testarea trebuie să aibă loc în paralel cu dezvoltarea ; testarea unui modul se va face imediat ce acesta este terminat; testarea trebuie făcută de persoane independente (nu de autori); pentru testarea funcţională cazurile de test vor fi alese imediat ce există specificarea (se pot depista lipsuri în specificare). testarea trebuie să ia în considerare riscurile posibile: schimbarea cerinţelor beneficiarului, deci şia specificării, planul testării nu este respectat din diferite motive ca: întârzieri în realizarea proiectului determină lipsa timpului afectat testării; depanări repetate cer testări de regresie repetate, peste cele prevăzute iniţial; testarea de integrare este întreruptă din lipsa unor module; lipsa personalului (îmbolnăviri, plecări, cost); testarea se încheie cu finalizarea documentului testării, strict necesar în documentaţia produsului realizat. 34/40

... Alte tipuri de testare ~ Organizarea testării Testarea este o activitate care cere timp şi efort. Ea are nevoie de documente care să descrie toate activităţile: specificare, proiectare, codificare. Testarea completă este practic imposibilă. În realitate testarea se încheie printr-un compromis între timp şi calitate. De multe ori nici fiabilitatea cerută nu este atinsă. Subliniem că testarea arată de cele mai multe ori prezenţa erorilor nu lipsa lor. Pentru ane convinge de lipsa erorilor testarea nu este suficientă. Sunt necesare şi alte metode de verificare, dar şi de verificarea / demonstrarea corectitudinii. ii 35/40

Întrebări şi probleme propuse Ce înţelegeţiprin testare? Care e diferenţaîntre testarea completăşi cea exhaustivă? Cum se stabilesc cazurile de testare? Când se consideră terminată testarea? Care e diferenţa dintre testarea funcţională, testarea structuralăşi testarea statistică? Din ce cauză în loc de otestare funcţională sau una structurală este preferabilă otestare mixtă? Care sunt nivelele de testare a unui produs soft? Cum puteţi estima numărul erorilor rămase în urma testării? Cum vă explicaţi ţ că, deşiş testate, programele au erori pe timpul folosirii lor de către beneficiar? 37/40

... Întrebări şi probleme propuse Stabiliţi datele de test pentru continuare, folosind criteriul cutiei negre. subalgoritmul specificat în Subalgoritmul Caută(m, n, A, i,j) este: {ϕ:m> m>1, n>1, A(1....m, m,1....n) este o matrice cu componente întregi}... {ψ: A[i,j] este componenta cu cei mai mulţi divizori proprii} sf-caută. 38/40

... Întrebări şi probleme propuse Dând o proiectare de ansamblu a unui program pentru rezolvarea problemelor menţionate mai jos, precizaţi nivelele de testare pe care leefectuaţi. Pentru unul din modulele considerate precizaţi cazurile de test pe care le alegeţi la testarea lui. La testarea de integrare, arataţi cum veţi realiza integrarea primelor două module. 1. Admiterea la facultate; 2. Acordarea burselor într-o facultate; 3. Calculul taxelor lunare la un bloc de locuinţe; 4. Mersul trenurilor. 39/40

Index of /~mfrentiu/lectures/verval/carte http://www.cs.ubbcluj.ro/~mfrentiu ~mfrentiu/lectures/verval/carte/ cap3.rtf 40/40