Sunteți pe pagina 1din 68

Zatca Tamara

Zatca Alexandru

Ministerul Educaiei al Republicii Moldova


Colegiul Financiar Bancar din or. Chiinu
Catedra Informatica

Elaborarea Produselor Program


Meserie sau art?

Chiinu 2012
CUPRINS
Preliminri..........................................................................................................................4
1. Elemente de baz............................................................................................................6
1.1 Produse program, componente ale software-ului.....................................................6
1.2. Generaii de produse program................................................................................11
1.3. Clasificarea produselor program orientate pe metod i pe domeniu....................15
1.4. Criterii de alegere a produselor program i evaluarea performanelor acestora....17
1.5. Stocarea i difuzarea produselor program.............................................................19
1.6. Aspecte legislative privind protecia produselor program.....................................22
2. Etapele de realizare a produselor program...................................................................25
2.1.Caracterizare general a procesului de realizare a programelor.............................26
2.2. Proiectarea de ansamblu a produsului program.....................................................28
2.3. Proiectarea de detaliu a programelor.....................................................................31
2.4 Codificarea i depnarea programelor....................................................................32
2.5 Integrarea i testarea programelor...........................................................................33
2.6 Definitivarea documentaiei aferente unui program...............................................35
2.7 Experimentarea i recepionarea programului........................................................37
3. Modele de dezvoltare a programelor............................................................................38
3.1 Etapele dezvoltrii programelor..............................................................................38
3.1.1 Analiza cerinelor.............................................................................................39
3.1.2 Proiectarea arhitectural...................................................................................39
3.1.3 Proiectarea detaliat.........................................................................................39
3.1.4 Scrierea codului................................................................................................39
3.1.5 Integrarea componentelor.................................................................................40
3.1.6 Validare.............................................................................................................40
3.1.7 Verificare..........................................................................................................40
3.1.8 ntreinere.........................................................................................................40
2

3.2 Modelul cascad.....................................................................................................40


3.3 Modelul cascad cu ntoarcere................................................................................42
3.4 Metode formale.......................................................................................................43
3.5 Modelul n spiral...................................................................................................43
4.Elaborarea schemelor logice de program......................................................................45
5. Ciclul de via al produselor program..........................................................................45
6. Dezvoltarea metodelor de programmare......................................................................47
6.1. Metoda programrii clasice...................................................................................47
6.2.Programarea structurat..........................................................................................48
6.3.Metoda programrii modulare................................................................................51
7. Norme i reguli de redactare a codului surs...............................................................54
7.1 Descrierea tipurilor de date....................................................................................54
7.2. Reglarea constantelor.............................................................................................55
7.3. Alegerea numelor de identificatori........................................................................55
7.4. Divizarea datelor de intrare n seturi independente de date...................................56
7.5. Identificarea modulului i al versiunii lui de dezvoltare........................................56
7.6. Verificarea i diagnosticarea datelor de intrare......................................................56
7.7. Diagnosticul situaiilor excepionale.....................................................................58
7.8. Aranjarea textului programului surs.....................................................................59
7.9. Comentarea programelor.......................................................................................60
8. Calitatea programelor...................................................................................................61
Bibliografie...................................................................................................................... 64

Preliminarii
Elaborarea produselor program este o activitate compus din analiza, proiectarea,
implementarea, testarea i ntreinerea aplicaiilor software ce sunt utilizate n diferite
domenii de activitate, de la operaiuni bancare i pn la funcionarea sistemelor n timp real
din industria nuclear sau aerospaial, reprezint un intens efort de inteligen asistat de
unul organizatoric i financiar; aceste eforturi sunt de dimensiuni apreciabile i aflate ntr-o
continu crestere, ca pondere n totalul resurselor umane i materiale utilizate.
n vreme ce tehnica de calcul devine din ce n ce mai performant ca urmare a
utilizrii tehnologiilor de vrf (prin miniaturizare i ieftinire), la elaborarea i ntreinerea
aplicaiilor software, n special a celor complexe, resursele consumate ajung s reprezinte
70-80% din costul total al sistemului (hardware i software) i chiar cu posibilitatea de
cretere pn la 90% n unele cazuri.
Volumul mare al activitii necesare pentru a dezvolta i ntreine programele (i deci
implicit nivelul nalt al costurilor asociate), justific interesul din ce n ce mai larg pentru
asigurarea unei caliti corespunztoare aplicaiilor precum i minimizarea costurilor de
elaborare a acestora. Sunt utilizate metode i instrumente adecvate analizei n detaliu a
cerinelor software i de elaborare sau testare a programelor, ce asigur un minimum de erori
admisibile i o productivitate ct mai mare.
Aceste aspecte specifice ce nsoesc elaborarea programelor au dat natere unor
ncercri de abordare sistemic a problematicii elaborrii aplicaiilor, conducnd n mod
firesc la formularea unor noi concepte, principii, metode i instrumente de construire a
programelor, cunoscute i sub denumirea de inginerie software. Ingineria software urmrete
n esen rezolvarea unor probleme specifice legate de analiza, proiectarea, implementarea,
testarea i ntreinerea programelor i anume:
stabilirea etapelor i a sub-etapelor prin care trece secvenial un produs software pe
durata ciclului su de via, definirea coninutului acestor sub-etape precum i a
parametrilor de demarcare ntre sub-etapele i etapele succesive.
abordarea formal prin elaborarea unor metode riguroase i a unor instrumente
4

asociate acestora, destinate asistrii proiectrii produsului software. Ele trebuiesc


adaptate diferitelor sub-etape din ciclul de via ale unui program, diferitelor tipuri de
programe precum i complexitii variate a programelor ce se realizeaz.
elaborarea unor proceduri clare de organizare i conducere a diferitelor activiti legate
de realizarea programului (calitate, performan). Obiectivul final al ingineriei
software este trecerea de la o activitate de elaborare a programelor, n care domin
stilul artizanal, de intuiie i improvizaie, la o activitate sistematic care s asigure
nalta calitate a programelor i un cost ct mai sczut al elaborrii i ntreinerii
acestora. Ingineria software se refer la utilizarea n mod riguros, sistematic i cu
profesionalism a unor metode i instrumente software adecvate, avnd n vedere
anumite obiective i principii de baz.
Scopul instruirii de elaborarea al produselor program n nvmntul mediu de specialitate
(colegiu) presupune:
formarea deprinderilor practice de elaborare a programelor i aplicaiilor la nivel
profesional;
formarea deprinderilor practice de proiectare al produselor program;
formarea deprinderilor practice de documentare i ntreinere al aplicaiilor;
studierea mijloacelor elaborrii produselor program, care contribuie la formarea
competenelor generale de baz: elemente de algoritmizare, modelare, programare,
gndire logic, acumularea, pstrarea i prelucrarea digital a informaiei.

1. Elemente de baz.
1.1 Produse program, componente ale software-ului
n vederea ndeplinirii unor funciuni de prelucrare a informaiilor, informatica pune la
dispoziia utilizatorilor, un ansamblu de echipamente, programe i proceduri de operare,
implementare i ntreinere; acest ansamblu constituie un sistem de prelucrare automata a
datelor sau un sistem informatic, dac colectarea, stocarea, prelucrarea i distribuirea
informaiilor se face n special cu mijloace automate.
Sistemul informatic are deci n componena sa ansamblul de echipamente (hardware),
ansamblul de programe (software) i ansamblul de personal.
Prin noiunea de software se nelege produsul intelectual ce consta din programe,
proceduri, reguli i documentaia asociat pentru funcionarea unui sistem de prelucrare a
datelor. Software-ul nu trebuie redus numai la sistemul de programe propriu-zis ci cuprinde
procedurile de operare, implementare, utilizare, ntreinere, documentaia asociat acestora,
precum i interaciunea cu utilizatorii.
Componentele software-ului sunt produsele program. Orice produs program este
constituit din :
- programul propriu-zis (codul sau instruciunile);
- datele asociate prelucrrilor prevzute n program;
- documentaia asociat produsului.
Produsele program (produse software) sunt asemntoare produselor rezultate dintr-o
activitate de producie tradiional, ele trecnd prin etapele de analiz, proiectare, realizare,
testare, experimentare i utilizare. Deosebirea const n faptul c produsele program rezult
dintr-o activitate intelectual i sunt destinate punerii n valoare a produselor de tip calculator
sau echipament, care funcioneaz pe baz de instruciuni (program). Considernd ca esenial
raportul dintre utilizator i maina, produsele program se pot stratifica dup cum urmeaz
(figura 1.1).

5
4
3
2
1
Figura 1.1. Stratificarea produselor program
1. Sisteme de operare - programe de baz, cu caracter universal; un sistem de operare
este o colecie de elemente software care controleaz execuia programelor i
furnizeaz servicii altor componente ale software-ului.
2. Extensii ale sistemelor de operare - sunt sisteme de operare cu caracter dedicat, care
asigur, la nivelul echipamentelor, faciliti speciale cerute numai de anumite aplicaii;
ca exemplu, amintim sistemele de operare pentru reele de calculatoare, mesagerie
electronic, teleconferine, sisteme de operare pentru conducere de procese
tehnologice etc.
3. Sistemele de gestiune a bazelor de date (SGBD) - sunt sisteme de programare pentru
gestiunea datelor dintr-o baz de date, care asigur independena programelor faa de
modul de structurare a datelor, o redundan minim n memorarea acestora precum i
timp minim de rspuns la solicitrile utilizatorilor.
4. Produse program orientate pe metod sau model matematic - sunt produse
program de tipul bibliotecilor de (sub)programe matematice, pachete i sisteme de
programe pentru rezolvarea unor clase de aplicaii ce au la baza acelai model sau
metod matematic etc.
5. Produse program orientate pe domenii sau pe specificul domeniului de aplicaie
sunt produse destinate rezolvrii aplicaiilor din diferite domenii de activitate uman
(industrie, agricultur, transporturi, medicin etc.)

6. Instrumente pentru realizarea produselor program - sunt entiti software care


prelucreaz/acioneaz asupra altor entiti software, fie ca instrumente de programare,
fie ca o component transparent a sistemului de programare sau a sistemului de
operare. Ele pot fi simple instrumente dispersate sau integrate n medii de programare,
sisteme de dezvoltare complexe, produse de tip CASE (Computer Aided Software
Engineering).
Dup cum se observ din figura 1.1, instrumentele pot opera asupra tuturor
componentelor clasificrii date i se regsesc la orice nivel al piramidei. De asemenea unele
dintre ele constituie calea prin care componentele de nivel superior (de exemplu cele de nivel
4 i 5) folosesc facilitile oferite de cele de nivel inferior. Produsele program orientate pe
metod/domeniu (categoriile 4 i 5) formeaza softwareul de aplicaie. Ele sunt uor de
utilizat, au o structur modular (care le confer un grad nalt de flexibilitate n implementare
precum i faciliti de extindere i modificare) i dispun de documentaie adecvat sub form
de manuale de prezentare, utilizare i operare.
Precizm faptul c acelai produs program poate fi clasificat att dup domeniul de
aplicaie n care este utilizat ct i dup metoda/modelul pe care se bazeaz.
Caracteristicile generale ntrunite de produsele program orientate sunt:
1. generalitate - produsul program rezolv toate problemele din clasa respectiv;
2. eficiena algoritmului - durata execuiei s fie mic iar memoria intern utilizat s
fie redus;
3. parametrizare complet - parametrii algoritmului s fie sub controlul utilizatorului;
4. independena ntre intrari i iesiri;
5. portabilitate - produsul s poat fi implementat pe diferite tipuri de calculatoare fr
modificri prea mari;
6. robustee, sigurana n execuie - dispun de o baz matematic solid, convergena
algoritmului s fie demonstrat etc.;
7. fiabilitate ridicat - numarul de erori n faza de execuie s fie foarte mic.

Utilizarea produselor program orientate prezint urmtoarele avantaje: reducerea


efortului i costului realizrii programelor/sistemelor informatice; reducerea timpului total de
implementare a aplicaiilor/sistemelor; reducerea erorilor n fazele de implementare i
execuie; asigur o legatur direct om-maina; asigur performane de timp de calcul i
precizie.
Dintre dezavantaje amintim: numrul mare de instruciuni, slab eficien sub
aspectul utilizrii echipamentelor de calcul, documentaie deficitar.
Elementele constitutive ale software-ului de aplicaie sau ale produselor program
orientate pot fi de urmtoarele tipuri: programe, module, pachete sau sisteme de programe,
biblioteci de programe, biblioteci de subprograme etc.
Programul este o combinaie de instruciuni de calcul i definiii de date care permit
calculatorului s execute calcule i funcii de control, reprezentnd deci codificarea ntr-un
limbaj accesibil mainii sau ntr-un limbaj de nivel nalt a unor algoritmi sau a unor funcii
de prelucrare a informaiei. Programul constituie o unitate de sine stttoare care
interacioneaza doar cu sistemul de operare i lucreaza cu date de intrare /ieire proprii.
Modulul (la nivel de program) este un element de structura al programului, rezultat
din divizarea acestuia n pari disjuncte, astfel nct fiecare parte s aib independena
funcionala, iar interaciunea dintre pri s fie minim. Modulul este caracterizat de
urmtoarele elemente: funcia, logica, interfaa i ponderea sau tria modulului. Menionam
c termenul de modul este utilizat la orice nivel n ierarhia sistem informatic, subsistem,
aplicaie, program, modulele unui sistem fiind subsistemele, ale unui subsistem fiind
aplicaiile, ale unei aplicaii fiind programele. Modularitatea la nivel de programe se numete
micromodularitate.
Pachetul/sistemul de programe reprezint o mulime de programe/module,
constituit ntr-o structur de tip liniar, arborescent sau reea, care rezolv izolat sau
mpreun probleme de un anumit tip, aparinnd unei aceleai clase de probleme.
Bibliotecile de (sub)programe sunt colecii de (sub)programe care rezolv probleme
dintr-o anumita clas i sunt folosite de programatori ca instrumente de dezvoltare a
9

aplicaiilor, obinnd astfel un nalt grad de standardizare i modularizare. Subprogramele nu


efectueaz operaii de intrare/iesire, datele i rezultatele fiind transmise prin list de
parametrii sau zona comun.
Orice program (figura 1.2.) este compus din trei pri principale: date, algoritm i
structur. Interaciunea acestora este prezentat n figura 1.3. Algoritmul specific un set de
operaii ce se aplic asupra mulimii datelor, rezultnd la intersecia acestor dou pri,
operaii de intrare/iesire, operaii logice, atribuiri, etc.
Structura programului definete pe mulimea datelor diferite tipuri de structuri de date
necesare prelucrarilor cuprinse n algoritm.

Figura 1.2. Prile componente ale unui program


De asemenea structura programelor induce asupra algoritmului diferite tipuri de
structuri fundamentale de control.

Figura 1.3. Interaciuni ntre prile unui program


Se mai poate spune c structura unui produs program este echivalent cu modul de
organizare folosind secvena, selecia, repetiia, iteraia i ierarhia.
Secvena este un grup de enunuri care se execut liniar.
10

Selecia este o structur care alege ntre executarea secvenei s1 sau secventei s2 n
funcie de realizarea sau nerealizarea unei condiii c.
Repetiia este structura care const n executarea, de un anumit numr de ori, a unui
grup de enunuri.
Iteraia este repetarea unui anumit procedeu de calcul prin aplicarea lui la
rezultatul calculului din etapa precedent
Ierarhia este un mod de organizare dup un anumit criteriu dominant.
Cnd aceste structuri sunt aplicate asupra datelor, rezult structuri de date iar cnd se
aplica asupra algoritmilor se obin structuri de control ale produsului program ce corespund
n diferite limbaje de programare unor construcii specifice.
Folosind aceste considerente, n capitolele urmtoare se vor trata distinct fiecare dintre
prile componente ale produsului program precum i interaciunile dintre acestea.
1.2. Generaii de produse program
Daca n domeniul echipamentelor se vorbete de generaii de calculatoare, determinate
mai ales de inovri tehnologice radicale (de la tub electronic, tranzistor, circuit integrat, la
microelectronic), pentru celelalte domenii - produse program, personal de specialitate,
utilizatori finali i conductorii acestora - nu se pot identifica jaloane la fel de precise i
marcate.
Cu toate acestea, prin analogie i n strnsa legtur cu generaiile de calculatoare, se
poate vorbi i de generaii de produse program, evoluia i performanele echipamentelor de
calcul fiind determinante pentru evoluia produselor program.
Referindu-ne la cele patru domenii ale prelucrrii automate a datelor, amintite anterior,
n anumite perioade i n funcie de locul i de gradul de raspndire a informaticii, au existat
i exist nc decalaje ntre nivelele de dezvoltare sau generaii. Fa de situaia limit ideal,
cnd nivelul de dezvoltare a echipamentelor, programelor, personalului de specialitate i
utilizatorilor ar trebui s fie ct mai apropiat, se opune situaia n care ntre acestea exist
decalaje, exist o "discrepant a generaiilor". O astfel de situaie se apreciaz c a existat
11

atunci cnd echipamentele erau de generaia a treia, programele de generaia a doua,


personalul de specialitate de generaia nti, iar conductorii/utilizatorii de generaia zero.
Generaia a treia de calculatoare a nsemnat, printre altele, i un nou mod de lucru,
acela n regim de teleprelucrare. Sistemele de operare care nsoeau aceste echipamente nu
erau orientate spre un astfel de regim de lucru sau n versiuni ulterioare rezolvau numai
parial aceste probleme; de asemenea, maniera de proiectare i realizare a programelor
aplicative (maniera "artizanala") nu era la nivelul hardware-ului folosit, acest lucru avnd
urmri att asupra calitii produselor program, ct i sub raportul utilizrii echipamentelor.
Formarea personalului de specialitate necesar, att ca pregatire ct i ca specialiti i
numr, a reprezentat un proces continuu, marcat de faptul c, aa cum s-a mai amintit, se
desfura odat cu dezvoltarea echipamentelor i programelor. n acelai timp utilizatorii,
mai ales conductorii acestora, nu erau pregtii pentru ntroducerea i utilizarea tehnicii de
calcul.
Pentru atenuarea diferenelor de nivel (generaii) ntre cele patru domenii, s-a
evideniat necesitatea unor masuri ca:
1. ntroducerea unor metodologii, tehnici, metode de lucru standardizate pentru
realizarea produselor program.
2. Realizarea cu ajutorul mijloacelor amintite a unor subprograme/pachete de programe,
ntr-un cuvnt produse program aplicative generalizabile, corespunzatoare din punct de
vedere calitativ i cantitativ.
3. Automatizarea procesului de realizare a produselor program.
4. mbuntirea programelor de formare i perfecionare n mod unitar a specialitilor i
utilizatorilor (inclusiv conductori).
Avnd n vedere gradul crescut de interconectare ntre calculatoare, n prezent iau o
amploare tot mai mare aplicaiile distribuite bazate pe arhitecturi client-server. La ora actual
dezvoltrile n domeniul tehnologiei informaiei i deci i n realizarea de software, sunt
legate de Internet i Intranet. ntre evoluia produselor program, a limbajelor de programare
i a generaiilor de calculatoare exist o legtur absolut explicabil. Astfel privit n timp
12

evoluia principalelor limbaje de programare i raspndirea lor n utilizare poate fi


reprezentat conform figurii 1.4.

Figura 1.4. Evoluia limbajelor de programare


Dac la nceputurile informaticii, programarea se facea numai n limbaj main
(aportul omului era de peste 90%), apariia urmtoarelor generaii este nsoit de cteva
dezvoltri semnificative ale limbajelor. ntre evoluia limbajelor i generaiile de calculatoare
este o oarecare concordan, n sensul c n generaia a doua predomina limbajul de
asamblare, generaia a treia nseamna mai ales folosirea limbajelor procedurale de nivel nalt,
generaia a patra - raspndirea sistemelor pentru gestiunea bazelor de date, a limbajelor de
interogare, generatoarelor de rapoarte i a limbajelor specializate pentru diverse domenii.
Generaia a cincea se pare c va fi nsoit de proliferarea limbajelor neprocedurale apropiate
de limbajul uman i n care aportul programatorului n scrierea programului va fi sub 5%.
Caracteristic deci generaiilor de produse program delimitate dup tipul limbajului de
programare utilizat este i raportul dintre munca efectuat de om i cea efectuat de
calculator pentru realizarea produselor program (figura 1.5.).
O data cu aceast evoluie se constat o scadere permanent a raportului dintre munca
efectuata de om i cea realizat de sistemul de calcul.

13

Figura 1.5. Evoluia efortului uman n raport cu generaiile de limbaje


Facnd o extensie, de la tip de limbaj la produs program, se poate vedea foarte clar
modul de evoluie al acestora din urm. Nu ne putem limita nsa la aceast stratificare a
generaiilor de produse program numai dupa limbajele n care au fost scrise. Trebuie s inem
seama i de evoluia mijloacelor tehnice, evoluie care trebuie privit din punctul de vedere
al harware-ului (de la calculatoarele mari la calculatoarele personale) i al software-ului (de
la limbaje suport, sisteme de operare, la SGBD-uri).
Astfel, produsele program au avut urmatoarea evoluie:
a. Produse program care prelucreaza date/informaii:
produse program monolit (nchise);
produse program modular-structurate;
produse program conversaionale (evoluia programului este liniar,
determinat de dialogul de tip ntrebare-rspuns dintre produsul program
i utilizator);
produse program interactive;
b. Produse program care prelucreaza cunotine:
sisteme de asistare a deciziei;
sisteme expert.
ntre aceste ultime dou categorii exist unele deosebiri att de natur arhitectural ct
i funcionala. n ultimul timp, tot mai muli autori consider c sistemele de asistare a
14

deciziei fac parte din clasa sistemelor expert, care ncorporeaz o baz de date, o baz de
cunotine, un mecanism inferenial i o interfa de I/E care faciliteaz interaciunea
decidenilor cu sistemul.
1.3. Clasificarea produselor program orientate pe metod i pe domeniu
Regsirea produselor program n cataloage i biblioteci de programe este facilitat de
stabilirea apartenenei lor la o anumit mulime de programe. Aceasta apartenen este
stabilit printr-o multitudine de criterii dintre care numai unele vor fi enumerate n
continuare.
Produsele program orientate pe metod / model se pot clasifica astfel:
1. dupa complexitatea lor, produsele program pot fi :
independente - programe distincte care realizeaz cte o funcie precis i pot fi
utilizate independent sau n cadrul unor colecii de programe;
biblioteci de programe/subprograme - colecii create pentru a fi folosite independent
sau n cadrul aciunii de dezvoltare a altor produse program;
pachete/sisteme de programe;
2. dup funcia ndeplinit n cadrul sistemelor de prelucrare automat a datelor:
programe de exploatare a datelor - sisteme de gestiune a fisierelor, sisteme de
obinere automat a unor anumite tipuri de rapoarte;
sisteme de gestiune a bazelor de date;
programe de aplicaie - programe care asigura informatizarea unor funcii la nivelul
unuia sau mai multor utilizatori finali;
programe utilitare - faciliteaz programarea/ realizarea unor operaii de rutin ca
editare texte, introducere - extragere de date, sortare, interclasare etc.;
programe auxiliare - realizeaz unele operaii auxiliare n exploatarea echipamentelor.
3. dup natura modelului matematic rezolvat - produse program orientate pe programare
matematic, alocare - nivelare resurse, teoria deciziei, simulare, planificare optim a
produciei, gestiunea tiinific a stocului, econometrie etc.
15

Produsele program orientate pe domeniul sau specificul aplicaiei se pot clasifica


dupa urmatoarele criterii:
1. dupa gradul de generalitate produsele program pot fi:
de uz general - realizeaza funcii de uz general;
generalizabile - informatizeaza funcii specifice la nivel de grup
tipologic de uniti sau activiti;
refolosibile - elaborate pentru o aplicaie sau pentru un anumit utilizator,
pot fi preluate i de ali utilizatori;
unicat - elaborate numai pentru un anumit tip de utilizator sau aplicaie.
2. dupa natura funciilor utilizator informatizate, produsele program pot fi pentru:
informatizarea proceselor de conducere;
informatizarea principalelor funcii ale ntreprinderii;
automatizarea activitilor de birou - administrative (birotica);
informatizarea cercetrii tiinifice, documentrii, proiectrii;
robotica industriala;
automatizarea activitilor de programare;
inteligena artificial etc.
3. dup tipul de domeniu (ramura, subramura) caruia i aparine utilizatorul final
produsele program pot fi pentru uniti industriale, agricole, silvicultura, construcii,
transporturi, telecomunicaii, nvatamnt, cultur i art, ocrotirea sntii, aprovizionarea
tehnico - material etc.
Exist i alte criterii de clasificare a produselor program dintre care mai importante
sunt: natura problemei ce o rezolv, modul de descriere a problemei sau datelor, forma de
prezentare etc.
Precizam c aceleai produse program pot fi cuprinse n mai multe clase, conform
criteriului luat n considerare. De aceea, prezentarea lor se poate face numai ntr-o singur
clas, iar enumerarea lor poate fi semnalat n toate clasele n cauz.
16

1.4. Criterii de alegere a produselor program i evaluarea performanelor acestora


La alegerea unui produs program se iau n considerare cerine ca:
Dimensiunea maxim a problemei ce trebuie rezolvat n raport cu
dimensiunea maxim planificat de produsul program.
Resursele configuraiei sistemului de calcul necesare implementrii
produsului program n raport cu resursele configuraiei sistemului la care
are acces utilizatorul.
Flexibilitate, usurina n vehicularea datelor de intrare/ieire, modul de
nelegere (nvare) a utilizrii produsului program i de interpretare care
s conduc la un anumit numr redus de rulri cu erori.
Costurile implicate de utilizarea curent i de meninere n exploatare s
se situeze la nivele care s nu afecteze negativ eficiena economic a
unitii beneficiare.
Produsul program s poat ncorpora noi componente pentru funcii de
prelucrare identificate ulterior i/sau s poat fi adaptat tehnicilor de
prelucrare ce corespund dezvoltrii ulterioare a configuraiei sistemului
de calcul.
Nivelul de tratare a erorilor s conduc la reducerea numarului de rulri
incomplete al produsului program; produsul poate pune n eviden
totalitatea erorilor existente n date, poate realiza corectarea sau ignorarea
unora din acestea, iar mesajele de eroare trebuie sa stabileasc ct mai
exact locul, cauza i modalitile de eliminare a erorilor.
Nivelele de fiabilitate i mentenabilitate trebuie s fie astfel dimensionate
nct ponderea erorilor ce necesit modificarea de secvene n program s
fie ct mai redus.
Implicaiile algoritmului utilizat n realizarea produsului program asupra
preciziei, vitezei, consumului de resurse.
17

Criteriile de alegere sunt dupa cum rezulta din cele semnalate anterior, strns legate de
caracteristicile de calitate, asigurate n toate etapele de elaborare a produsului program. Vom
aminti c putem vorbi, c n cazul oricarui produs, de calitatea la elaborator i calitatea la
beneficiar sau de calitatea procesului de realizare i calitatea produsului final.
Din punct de vedere al beneficiarului evaluarea performanelor i limitelor unui produs
program presupune examinarea unor elemente cum sunt: configuratia minima (maxima)
necesara implementrii; necesarul de memorie interna pentru program sau corelaia dintre
elementele care definesc dimensiunile problemei n raport cu disponibilul de memorie
interna; precizia pe care o pot avea rezultatele n raport cu durata rezolvarii problemei;
opiuni pentru obinerea rezultatelor intermediare; modul de tratare al erorilor; nivelul
fiabilitii produsului program etc.
Evaluarea performanelor produsului program mai poate fi neleas ca o comparare a
nivelelor caracteristicilor sale de calitate i cele planificate. n acest sens evaluarea se
realizeaz de ctre echipa de realizatori lund n considerare exemple de control proprii sau
unele probleme de rezolvat de ctre beneficiarii poteniali ai produsului program. Valorile
atribuite nivelelor caracteristicilor de calitate au n acest caz caracter orientativ. Evaluarea
performanelor se efectueaz i de fiecare utilizator n parte, incluznd particularitile
specifice ale fiecarui tip de problem pe care o rezolv. Valorile obinute n acest caz au
menirea de a corecta sau de a confirma nivelele existente n documentaia care nsoete
produsul program. Pentru evaluarea performanelor se ntocmete un plan de observaii
statistice i se nregistreaz informaii cu privire la:
descrierea problemei (dimensiuni, volum de date semnificative, elemente de structur
a problemei);
numarul de rulri, tipul i numrul erorilor nregistrate pentru fiecare rulare;
consumurile de resurse (ore programare, asisten, timp calculator);
momentele de timp n care se efectueaz msuratorile.

18

Constituirea seriilor de date se realizeaz n timp i la evaluarea performanelor sunt


utilizate metode statistice (calculul mediei, dispersiei, corelaiei, testarea ipotezelor privind
egalitatea mediilor/dispersiilor, analiza dispersional etc.).
Pe masura completrii seriilor de date cu noi nregistrri se procedeaz la recalcularea
nivelelor pentru caracteristicile ce definesc performanele produsului program. Studierea
caracteristicilor cu nivele mai sczute creeaz premizele modificrii produsului program sau
proiectrii de noi versiuni care conduc la mbuntirea nivelelor i pentru aceste
caracteristici.
Gestionarea unic a produselor program are menirea de a selecta dup criteriul
performanei i de a generaliza implementarea lor. n acelasi timp cererile formulate de
beneficiar au ca efect perfecionarea produselor program existente i influeneaz lansarea n
realizare de noi produse program.
1.5. Stocarea i difuzarea produselor program
Progresul n domeniul programrii, pn la ceea ce se numeste industrializarea
programrii calculatoarelor s-a realizat n momentul n care s-a constatat paralelismul
existent ntre produsele industriale n general i produsul program, deosebit de precedentele
prin faptul c este un produs abstract. Dupa cum produsul industrial este obinut prin
prelucrarea unor materii prime i semifabricate pe fluxul tehnologic, strile intermediare
fiind stocate n depozite de flux, iar produsul finit n magazia de produse finite, tot astfel i
produsul program pleac de la problema concret, de la o serie de programe de sistem
(compilatoare, programe utilitare etc.), care fac obiectul unei elaborri, strile i
componentele intermediare fiind stocate n biblioteci ce pot fi numite biblioteci tehnologice,
iar produsul finit este depus n biblioteca unitaii de informatic i eventual este naintat spre
difuzare unei biblioteci de distribuie.
Din punct de vedere al rolului lor n fluxul tehnologic i de utilizare a produselor
program, bibiotecile de programe pot fi: tehnologice i de distribuie.

19

Bibliotecile tehnologice constituie premize de cretere a productivitii i calitii


produciei de produse program i conin: bibiotecile de sistem, bibliotecile proiectelor i
bibliotecile personale ale programatorilor.
Bibliotecile tehnologice pot fi de patru tipuri:
biblioteci centrale ale unitilor de informatic n care sunt cuprinse toate
programele aflate n exploatare n unitatea respectiv;
biblioteci de proiect - sunt specifice unui anumit proiect de produs program, de
aplicaie sau de sistem informatic i conin programe sau module, componente finite
ale unui produs program complex, ale unei aplicaii sau ale unui sistem, deja testate i
acceptate;
biblioteci individuale - sunt organizate i ntreinute de programator pentru nevoi ce
apar pe parcursul activitii curente de programare i conin module i programe n
curs de elaborare sau programe finite;
biblioteca de sistem conine instrumentele cu ajutorul crora se realizeaz produsele
program aplicative, adica programele utilitare, compilatoarele, translatoarele,
interpretoarele etc.;
n unitaile de informatic pot apare ierarhii de biblioteci de programe, la nivelul cel
mai nalt fiind biblioteca central care conine toate produsele program finite elaborate n
cadrul unitii sau n alte uniti de informatic i exploatate n unitatea n cauza. Pe nivelul
urmtor pot fi considerate bibliotecile de proiect care conin toate modulele i programele
elaborate de catre toi programatorii care lucreaz la proiectul respectiv. La rndul lor,
programatorii au biblioteci individuale, organizate pe proiecte, care conin programe
elaborate de catre acetia i n curs de finisare i programe/module preluate din biblioteca
sistem.
Bibliotecile de distribuie sunt destinate pentru difuzarea la utilizator a produselor
program de uz general i generalizabile, ceea ce permite scurtarea duratei de elaborare a
sistemelor informatice i elimina posibilitatea elaborrii de produse program cu funcii
identice.
20

n unele cazuri, bibliotecile de programe ale unitilor de informatic departamentale


au rolul de biblioteci de distribuie pentru produse program specifice prelucrrii informaiei
din ramura respectiv. Bibliotecile de distribuie au urmatoarele funcii:
colectarea de produse program de uz general i generalizabile de la elaboratori i
difuzarea acestora la utilizatorii interesai;
evidena produselor program elaborate i n curs de elaborare aflate la autori;
selectarea de produse program de uz general i generalizabile care prezint interes
pentru mai muli utilizatori;
colectarea produselor program selectate i repartizarea lor pe clase;
testarea produselor colectate, validare, omologare;
informarea utilizatorilor cu privire la produsele program aflate in fondul bibliotecii;
difuzarea la utilizator a produselor program;
urmrirea n exploatare a produselor program;
colectarea de la utilizator de informaii cu privire la comportarea n exploatare a
produselor, precum i de cerine pentru noi produse program.
Existena bibliotecilor de programe i organizarea lor conform anumitor principii
poate constitui un mijloc important de ordonare i disciplinare a procesului de realizare a
produselor program. Ele contribuie la mbunatairea productivitii activitii de programare
prin furnizarea de module i programe gata elaborate, prin nlturarea paralelismelor i
constituie un spaiu de depozitare pentru produsele program i componentele acestora n curs
de elaborare sau produse finite. n concluzie, bibliotecile de programe contribuie la cresterea
indicilor cantitativi i calitativi ai activitii de elaborare a produselor program.
n prezent, datorit accesului rapid la informaie i a facilitilor crescute de
comunicare oferite de Internet, utilizatorii au posibilitatea de a cunoate, evalua, compara,
selecta i achiziiona produse program oferite de diverse firme producatoare de software.
Comunicarea direct dintre producatori i utilizatori, asigur creterea calitii produselor

21

program prin realizarea de mbuntiri i dezvoltri de noi versiuni n concordan cu


cererile utilizatorilor.
1.6. Aspecte legislative privind protecia produselor program
Protecia produselor program a fost reglementata prin Legea privind dreptul de autor
i drepturile conexe, aprobata n februarie 1996 de ctre guvernul Republicii Moldova.
Aceast lege definete obiectul i coninutul dreptului de autor, avnd o serie de
dispoziii speciale referitoare la produsele software.
Astfel, obiectul dreptului de autor l reprezinta operele originale de creaie
intelectual, indiferent de modalitatea de creaie, modul i forma concreta de exprimare i
independent de valoarea i destinaia lor.
Coninutul dreptului de autor: autorul are dreptul exclusiv de a autoriza
reproducerea integrala sau pariala, difuzarea, transmiterea prin fir, cablu, fibra optica,
accesul public la bazele de date, daca ele sunt protejate, utilizarea, nchirierea, mprumutul
originalului sau a copiilor.
Prin contractul de nchiriere autorul permite folosirea pe un timp determinat a
originalului sau a copiilor.
Durata dreptului de autor - tot timpul vieii autorului i se transmite prin motenire
pe o durata de 50 ani.
Dispoziii speciale referitoare la protecia produselor program:
Protecia programelor pentru calculator include orice expresie a unui program,
programele de aplicaie i sistemele de operare, exprimate n orice limbaj (cod sursa
sau cod obiect), materialul de concepie pregtitor i manualele;
Nu sunt protejate ideile, procedeele, metodele de funcionare, conceptele matematice
i principiile care stau la baza oricarui element dintr-un program, inclusiv cele care
stau la baza interfeelor;
Autorul are dreptul exclusiv de a realiza i de a autoriza:
o reproducerea permanent sau temporal, integral sau parial a unui program,
prin orice mijloc sau form;
22

o traducerea, adaptarea, rearanjarea i alte transformri ale unui program precum


i reproducerea acestor transformri, far a prejudicia drepturile persoanei care
face transformrile
o difuzarea originalului sau a copiilor, sub orice forma, inclusiv prin nchiriere
Drepturile asupra programelor create de unul sau mai muli angajai, ca atribuii de
servicii sau dupa instruciunile celui care angajeaz, aparin acestuia din urm.
Prin contractul de utilizare al unui program
o Utilizatorul are dreptul neexclusiv de utilizare a programului
o Utilizatorul nu poate transmite dreptul de utilizare unei alte persoane
o Cesiunea dreptului de utilizare al unui program nu implic transferul dreptului
de autor asupra acestuia
o Utilizatorul autorizat are dreptul de a realiza copii de arhiv sau de siguran
far acceptul autorului
Reproducerea sau traducerea codului program pentru interoperabilitate cu alte
programe trebuie autorizat de titularul dreptului de autor dac
o Actele de reproducere sau traducere sunt realizate de o persoan care deine
dreptul de utilizare a unei copii a programului
o Informaiile necesare interoperabilitii nu sunt uor i rapid accesibile
o Actele se limiteaz la pri din program
o Informaiile necesare interoperabilitii nu pot fi utilizate n alte scopuri dect
pentru realizarea acesteia
o Nu pot fi comunicate altei persoane
o Nu pot fi utilizate pentru definitivarea, producerea sau centralizarea unui
program a carui expresie este fundamental similara
Se sancioneaza cu amend sau nchisoare urmatoarele fapte:
Accesul public la bazele de date care conin sau constituie opere protejate, fara
autorizarea titularului dreptului de autor
23

nsuirea fr drept a calitii de autor


Fr autorizarea titularului dreptului de autor se:
o Reproduc, difuzeaza, comercializeaza programe
o Pune la dispozitia publicului, prin vnzare, a mijloacelor tehnice destinate
neutralizarii dispozitivelor de protectie a programelor
Beneficiaz de protecie prin lege i programele create anterior intrrii n vigoare a
acestei legi.

24

2. Etapele de realizare a produselor program


La nceputul erei calculatoarelor se purtau numeroase discuii n jurul procesului de
programare, el fiind considerat mai mult o art dect o meserie. ntre timp s-au fcut multe
cercetri, s-au scris multe cri i s-au elaborat standarde (vezi bibliografia), au aprut noi
instrumente, medii de automatizare a dezvoltrii sistemelor informatice, cele mai multe fiind
n domeniul programrii, mai corect n domeniul generrii de cod. Calitatea programului
n mai mare msur depinznd de concepere, i nu de codificare, discuia poate continua.
Cert este faptul c una i aceeai sarcin de programare realizat de 100 de programatori
poate constitui, i ca regul va constitui, 100 de caliti diferite. Comentariile sunt de prisos.
Semnificaia programrii rmne a fi decisiv pentru calitatea final a produsului,
produsele program fiind considerate produse intelectuale.
Unul i acelai Produs Program (PP) poate avea mai multe versiuni i variante de
realizare, care sunt legate de necesitile funcionale, subiectele de realizare, tradiiile,
gusturile i realizrile profesionale particulare.
Orice Sistem Informatic (SI) conine un PP, care asigur procesul automatizat de
funcionare al acestui sistem. Indeferent de faptul este Produsul program un element al SI sau
se prezint ca un produs independent destinat unui grup de utilizatori, vom discuta n
continuare despre etapele de realizare a produselor de complexitate medie/mare, care n
funcie de faptul cum este elaborat poate fi o aplicaie de uz propriu sau un PP de calitate,
care poate fi realizat.
Activitatea principal la etapa de programare este legat de proiectarea, codificarea,
depnarea, integrarea i testarea programelor, care pot fi definite prin trei componente:
a) Programul propriu-zis, definit prin:
Structura programelor;
Algoritmii de prelucrare;
Transcrierea algoritmilor ntr-un limbaj de programare (codul programului).
b) Datele asociate prelucrrilor prevzute n program prin instruciuni.
25

c) Documentaia asociat produsului care permite nsuirea i punerea lui n


funciune.
n continuare vom examina la mod general etapele realizrii produselor program,
diferite modaliti i paradigme de programare, programarea propriu-zis constituind
obiectul altor cri, cursuri, discuii.

2.1. Caracterizare general a procesului de realizare a programelor


Procesul de elaborare a programelor unui SI (PP) poate fi descompus ntr-o secven
de activiti, ntrunite n etape ale ciclului de via.
Se fac cel puin trei presupuneri:
Fiecare etap se termin printr-o activitate de verificare i validare, avnd drept scop
eliminarea anomaliilor din produs chiar n momentul n care au fost introduse. n funcie de
rezultatul validrii, se trece la etapa urmtoare sau se revine la cea precedent;

26

Cerinte de realizare
PROIECTARE DE
ANSAMBLU

PROIECTARE DE
DETALIU

Sugestii

de dezvoltare

CODIFICARE SI DEPANARE
COMPONENTE

INTEGRARE COMPONENTE SI
TESTARE PRODUS

DEFINITIVARE DOCUMENTATII

EXPERIMENTARE SI
RECEPTIONARE
Produs program documentat
catre etapa "Producere"

Figura
2.1.7.1.
Schema
procesului
dede
realizare
a programelor
Figura
Schema
procesului
realizare
a programelor
Teoretic i ca regul, este bine ca revenirile s se limiteze doar la etapele imediat
anterioare (linii continue n Fig.2.1). Adic, n mod ideal etapele se succed strict secvenial,
fr retururi semnificative la etapele anterioare;
n practic ns etapele realizrii unui SI sau PP se suprapun, se interptrund i se
repet iterativ, formnd numeroase bucle (linii punctate n Fig.2.1).
Proiectarea de ansamblu i de detaliu a PP nu trebuie confundat cu proiectarea de
ansamblu i de detaliu a SI. Realizarea propriu-zis a PP are la baz proiectul logic i
proiectul tehnic de detaliu ale SI, materializate ntr-o documentaie numit Cerine de
27

realizare, n care sunt specificate: cerinele; arhitectura sistemului (echipamente i


programe); concepia privind exploatarea sistemului, inclusiv repartiia de sarcini i resurse
umane i echipamente; resurse prevzute; funcii i operaii principale.
Specificaia cerinelor de realizare la etapele anterioare descrie doar ceea ce trebuie
s fac produsul program. Modul concret cum trebuie s se fac pentru fiecare din funcii
constituie obiectul etapei de realizare a programelor.
Spre deosebire de SI, care este definit printr-un unic proiect de ansamblu i de detaliu
(viziune integr SI), pentru fiecare subsistem al acestui SI poate fi definit i realizat propriul
su produs program cu proiectele sale de ansamblu i de detaliu.
2.2. Proiectarea de ansamblu a produsului program
n baza cerinelor de realizare se efectueaz proiectarea de ansamblu a PP, al crei
scop const n definirea i structurarea componentelor de program, care vor forma un tot
unitar (cerine funcionale i de calitate, arhitectura funcional a produsului.
n procesul proiectrii de ansamblu a programelor se cere a gsi, a stabili funciile prin
intermediul crora intrrile pot fi transformate n ieiri, a determina utilajul necesar,
software-ul de baz, SGBD utilizat etc.
Noiunea de ansamblu se refer la viziunea integr, de ansamblu, asupra produsului,
i nu la gradul de detaliere a proiectrii. Obiectivele acestei etape sunt:
Identificarea i structurarea transformrilor pe care le suport datele, precum i
fluxurile lor n sistem;
Partiionarea

(structurarea,

divizarea)

optim

funciilor

sistemului

componente/module, a cror complexitate s poat fi controlat de programatori;


Definirea interfeelor;
Selectarea algoritmilor i a procedurilor de calcul.
Un lucru important n cadrul acestei etape l constituie alegerea metodelor de
proiectare i a unor tehnici i/sau limbaje pentru reprezentarea proiectului.
Documentaia rezultant este specificaia de definire a produsului program, care
28

conine:
o Descrierea problemei de baz de soluionat i a criteriilor de acceptare de ctre
utilizator;
o Destinaia produsului;
o Specificaia cerinelor i a restriciilor;
o Arhitectura produsului program.
Sfritul acestei etape presupune:
o Verificarea proiectului de ansamblu privind ierarhia unitilor de realizare i
interfeele dintre ele i structura logic a datelor;
o Planificarea integrrii i testrii, a testului de recepie i a manualului de
utilizare;
o Estimarea resurselor necesare.
2.3. Proiectarea de detaliu a programelor
Scopul acestei etape este proiectarea structurii fizice a produsului i pregtirea testrii
lui. Documentaiile rezultate sunt: specificaia de realizare a produsului i specificaia de
testare.
Aceast faz demareaz realizarea propriu-zis a produselor program. Din acest
moment, la realizarea proiectului particip cea mai mare parte a forei de munc alocat.
Pentru fiecare din componentele produsului, definite n faza de proiectare de ansamblu, se
realizeaz o descompunere n uniti mai mici, numite module. Pentru fiecare modul se
ntocmete specificaia extern, intern i de testare.
Specificaia extern cuprinde:
o Descrierea interfeelor externe, arborele de structur (numele, funcia, modul de
apel, interaciunea cu mediul utilizator, cu alte produse program, cu suportul
hardware i software);
o Descrierea fiecrei componente a arborelui (funciuni, intrri, ieiri);
o Descrierea datelor (structuri fizice, moduri de reprezentare);
29

o Condiiile i restriciile tehnice de realizare.


Specificaia intern descrie:
o Logica intern (algoritmul) modulului;
o Descrierea interfeelor interne (flux de control, flux de date, flux de
comunicaii).
Specificaia de testare conine:
o Planul de testare (resurse, termene, responsabiliti);
o Cazurile de test (date de intrare, rezultate posibile);
o Mediul de testare (hardware, software);
o Procedurile de testare.
Separarea fizic a acestor specificaii este foarte important, deoarece specificaia
intern poate fi modificat fr a avea influen asupra specificaiei externe, n timp ce
modificarea specificaiei externe atrage dup sine modificarea specificaiei interne i de
testare. Sfritul acestei etape presupune:
a) Verificarea proiectului detaliat al fiecrei componente privind:
o Completitudinea i coerena1 specificaiei ntocmite,
o Exactitatea definirii datelor utilizate,
o Necesitatea revenirii asupra specificaiei de realizare ntocmit n faza de
proiectare de ansamblu;
b) Aprobarea planului pentru testul de recepie;
c) Verificarea versiunilor provizorii pentru planurile de integrare i testare, precum i a
manualului de utilizare.
2.4. Codificarea i depnarea programelor
Faza are ca scop realizarea modulelor, programelor i a unitilor de execuie n
1

Coeren legtur strns (i armonioas) ntre prile sau elementele unui ntreg.

30

conformitate cu specificaiile de realizare i testare individual a acestora. Scrierea codului


surs pentru fiecare modul din specificaia de realizare, verificarea funcionrii lui corecte
pe calculator i, eventual, depnarea i corectarea lui constituie esena acestei etape.
O calitate principial a codului scris este claritatea lui reflectat prin uurina cu
care acesta este citit i neles de orice programator. n acest scop sunt recomandate
comentariile, codurile i identificatorii mnemonici ca surs de autodocumentare.
Codul surs realizat trebuie validat. Procedeele curente de validare se axeaz, n
special, pe testare, adic pe verificarea funcionalitii codului, prin execuie pe calculator,
folosind date de test.
Mai recent, au fost introduse i alte metode de verificare care ncearc s elimine
erorile nainte ca ele s fie transportate n cadrul programului. Din aceast categorie fac parte
verificrile de tip: inspectare cod, metode de demonstrare a corectitudinii programelor etc.
Sfritul acestei etape presupune:
a) Verificarea rezultatelor testrii fiecrui modul;
b) Verificarea respectrii normelor de programare folosite n redactarea modulului;
c) Documentaia pentru fiecare component.
Rezultatele etapei sunt:
a) Fiierele i bibliotecile cu programe i module testate individual;
b) Rapoartele de testare individual i listingurile de confirmare;
c) Documentaia de ntreinere, care conine:
o Specificaia structurii produsului i a documentaiei;
o Descrierea produsului program pe componente individuale;
o Textele programelor n limbajul surs autodocumentate.
2.5. Integrarea i testarea programelor
Etapa de programare se ncheie cu testarea progresiv i integrarea modulelor n
ansamblul sistemului pe baza specificaiilor elaborate anterior, precum i cu finalizarea unei
documentaii complexe de realizare format din: manualul de prezentare, manualul de
31

utilizare, manualul de exploatare (documentaia de exploatare).


n cadrul acestei etape se vor optimiza elementele de interfa cu utilizatorul (formate
video, dialoguri, sisteme de help), se vor pune la punct procedurile de prentmpinare i
corectare a erorilor involuntare la operare, se elaboreaz documentaia de realizare, manualul
de prezentare i manualul de utilizare i exploatare.
Sfritul acestei etape presupune:
a) Trecerea cu succes a testului de recepie, verificnd respectarea cerinelor incluse n
specificaia de definire;
b) Recepionarea elementelor ce nsoesc produsul (rapoarte, manuale, documentaie,
fiiere de date etc.).
Testarea n aceast faz este orientat spre funciile generale ale produsului i ale
performanelor specificate, ale interfeelor dintre programe - programe, programe echipamente i programe - utilizator.
Rezultatul testrii este consemnat n raportul de testare a integrrii, care conine:
o Descrierea pe scurt a funciunilor produsului;
o Condiiile n care are loc testarea;
o Rezultatele acestei activiti;
o Performanele obinute.
Pe msur ce componentele produsului sunt validate, ele sunt asamblate ntr-un sistem,
printr-un proces de integrare. Integrarea poate avea loc:
o Ascendent, de jos n sus, de la module spre aplicaii (bottom-up);
o Descendent, de sus n jos (top-down).
n cazul integrrii ascendente, procesul ncepe dup ce modulele situate pe cel mai
de jos nivel al ierarhiei au fost realizate. n cazul integrrii descendente, procesul de
integrare ncepe cu modulele din partea de sus a ierarhiei.
Ctig de cauz se d realizrii i integrrii descendente, deoarece sistemul n
ansamblu prinde contur chiar din primii pai ai integrrii. Unele din funciile sale fiind
realizate la un moment dat, etapele de proiectare, codificare, integrare i testare pot derula
32

paralel.
Prin compararea rezultatelor propuse a fi obinute cu cele efectiv furnizate de aplicaia
informatic, sunt verificate sintactic i funcional modulele din program. Dac se realizeaz
identitatea ntre cele dou categorii de rezultate, operaia de testare se consider ncheiat.
Testarea top-down este aplicabil asupra programelor cu structura modular i se
pornete de la modulul director ctre modulele funcionale, apoi ctre cele operaionale
astfel: se testeaz modulul director i cele funcionale; se testeaz individual modulele
operaionale; se testeaz relaiile dintre module prin ncercri cu seturi de date asupra
programului asamblat2 pe diferite variante funcionale.
Pentru prima faz, testele se pot efectua asupra modulelor video, aceste module
asigurnd practic funcionalitatea produsului.
Testarea nu se consider ncheiat dect atunci cnd se efectueaz lansarea prelucrrii
de ctre ntreaga aplicaie informatic a unui set complet de date.
Un set complet de date va include toate datele posibile, corecte i eronate, pentru a
urmri reacia de rspuns a sistemului. n aceast ultim testare, numit global, se vor
urmri: validarea corectitudinii datelor primare i a rezultatelor; rspunsurile i mesajele
sistemului informatic; modul de operare n timpul execuiei programului.
Operaiile de testare se vor materializa n urmtoarele: compilarea 3 programelor surs
i corectarea erorilor de sintax; constituirea modulelor obiect, a legturilor funcionale ntre
acestea i corectarea erorilor de legtur; lansarea n execuie a aplicaiei cu un set de date de
test i corectarea erorilor de concepie i a altor erori de legtur i comunicaie ntre module;
catalogarea modulelor integrate n biblioteca utilizatorului i eventuala corectare a erorilor de
catalogare.

A asambla a reuni, a fixa, a mbina dou sau mai multe componente ale unui sistem. Este sinonim
cuvntului integrare pentru produse finale, ce asambleaz succesiv toate componentele.
Compilarea programului procesul de obinere a programului n limbajul mainii din programul scris n
orice alt limbaj de programare.

33

2.6. Definitivarea documentaiei aferente unui program


Indiferent de modul de ealonare n timp i amploarea sistemelor informatice, modul
de realizare a programelor, pentru fiecare program (complex) realizat se ntocmete
documentaia de realizare i ntreinere.
n aceast faz se aduc completri la documentaia de realizare i ntreinere i se
aprob forma definitiv a manualelor produsului program, dup cum urmeaz:
Documentaia de realizare i ntreinere ce va conine:
o Structura general a produsului program;
o Descrierea fiierelor separate i a bazei de date;
o Documentaia pentru fiecare program, modul (arborele de structur, funciunile,
textul surs autodocumentat cu comentarii etc.);
o Situaiile i rezultatele finale.
Manualul de prezentare ce va conine:
o Destinaia produsului program;
o Condiiile de utilizare;
o Descrierea produsului program i a metodelor de realizare;
o Tipurile de intrri/ieiri;
o Lista manualelor produsului;
o Performanele i caracteristicile de calitate;
o Informaiile tehnico-comerciale.
Manualul de utilizare ce va conine:
o Destinaia produsului program;
o Condiiile de utilizare;
o Caracteristicile produsului program;
o Procedurile de apelare, ncrcare i lansare n execuie;
o Datele de intrare/ieire;
o Interaciunea utilizator-produs;
34

o Alte informaii necesare utilizatorilor produsului.


Manualul de exploatare ce va conine:
o Informaiile generale despre produs;
o Structura fizic a produsului;
o Procedurile de instalare, adaptare, generare;
o Procedurile de verificare a instalrii corecte;
o Modurile de execuie a programelor.
n cazul n care produsul program dispune de un limbaj propriu, specializat, se
ntocmete i un manual al limbajului.
Manualele se vor organiza modular, pe categorii de utilizatori i executani ce vor
asigura exploatarea.
Componena instruciunilor operaionale, a grupelor de proceduri i informaiile
coninute n instruciunile tehnologice operaionale se stabilete la proiectarea de ansamblu a
SI n conformitate cu cerinele de proiect i a standardelor.
2.7 Experimentarea i recepionarea programului
Scopul acestei etape este verificarea n condiii reale a performanelor produsului
program. Numrul de experimentri difer n funcie de complexitatea i natura produselor
program. Aceast faz pregtete toate elementele necesare recepionrii sistemului de ctre
beneficiari i intrarea lui n exploatarea curent.
Se verific respectarea specificaiei de definire a sistemului i existena efectiv a
condiiilor necesare exploatrii sistemului (echipamente, amenajri, personal instruit etc.).
Dac toate aceste condiii sunt ndeplinite, sistemul se instaleaz efectiv i se trec testele de
recepie la beneficiari n cazul unor SI unicate, sau se face pregtirea ctre omologare,
producere i implementare: n cazul unor SI tipologice.

35

3. Modele de dezvoltare a programelor


Cnd pornim la dezvoltarea unui program avem nevoie de:
o o nelegere clar a ceea ce se cere;
o un set de metode i intrumente de lucru;
o un plan de aciune.
Planul de aciune se numete model de dezvoltare. Dezvoltarea unui anumit program
const ntr-un set de pai ce se fac pentru a-l realiza. Lund n considerare tipul pailor ce se
efectueaz se creaz un model de lucru, ce poate fi aplicat unei serii mai largi de proiecte.
Acesta este motivul pentru care planul de aciune este numit model: el poate fi privit ca un
ablon al dezvoltrii de programe.
Exist o serie larg de modele de dezvoltare:
o ad hoc (do-it-yourself)
o cascad (waterfall)
o prototipizare
o metode formale
o spiral
o RUP (Rational Unified Process)
o XP (Extreme Programming)
3.1 Etapele dezvoltrii programelor
n timpul dezvoltrii programelor s-a constatat c exist anumite tipuri de activiti
care trebuie fcute la un moment dat:
o analiza cerinelor
o proiectarea arhitectural
o proiectarea detaliat
o scrierea codului
o integrarea componentelor
36

o validare
o verificare
o ntreinere
3.1.1 Analiza cerinelor
Se stabilete ce anume vrea clientul ca programul s fac. Scopul estenregistrarea
cerinelor ntr-o manier ct mai clar i mai fidel. Claritatea se refer la lipsa ambiguitii
iar fidelitatea la nregistrarea ct mai exact (posibil cuvnt cu cuvnt).
3.1.2 Proiectarea arhitectural
Din motive de complexitate, programele mari nu pot fi concepute i implementate ca o
singur bucat. Programul va trebui construit aadar din module sau componente.
Proiectarea arhitectural mparte sistemul ntr-un numr de module mai mici i mai
simple, care pot fi abordate individual.
3.1.3 Proiectarea detaliat
Se realizeaz proiectarea fiecrui modul al aplicaiei, n cele mai mici detalii.
3.1.4 Scrierea codului
Proiectul detaliat este transpus ntr-un limbaj de programare. n mod tipic, aceasta se
realizeaz modular, pe structura rezultat la proiectarea arhitectural.
3.1.5 Integrarea componentelor
Modulele programului sunt combinate n produsul final. Rezultatul este sistemul
complet. Exista cteva modele de integrare a componentelor.
Modelul big-bang
n acest model, componentele sunt dezvoltate i testate individual. Apoi ele sunt
integrate n sistemul final. Avnd n vedere c funcionarea corect a componentelor
individuale a fost testat, integrarea ar trebui s fie o formalitate. Din pcate, componentele
nu pot fi testate exhaustiv, iar cnd acestea lucreaz mpreun pot s apar situaii pe care o
anumit component nu le-a ntlnit n procesul de testare sau conflicte ntre anumite
componente (de exemplu, conflicte de partajare a resurselor).

37

S-a constatat c atunci cnd se aplic acest model, timpul de testare explodeaz,
proiectul devenind greu de controlat. Aceasta justific denumirea de big-bang.
Modelul incremental
Acest model propune crearea unui nucleu al aplicaiei i integrarea a cte o
component la un moment dat, urmat imediat de testarea sistemului obinut. Astfel, se poate
determina mai uor unde anume apare o problema n sistem.
Acest tip de integrare ofer de obicei rezultate mai bune dect modelul big-bang.
3.1.6 Validare
n procesul de validare ne asigurm c programul ndeplinete cerinele utilizatorului.
ntrebarea la care rspundem este: construim produsul corect? Un exemplu de validare este
testul de acceptare, n care produsul este prezentat clientului. Clientul spune dac este
mulumit cu produsul sau dac mai trebuie efectuate modificri.
3.1.7 Verificare
n procesul de verificare ne asigurm c programul este stabil i c functioneaz corect
din punctul de vedere al dezvoltatorilor. ntrebarea la care raspundem este: construim corect
produsul?
3.1.8 ntreinere
Dup ce programul este livrat clientului, mai devreme sau mai trziu sunt descoperite
defecte sau erori ce trebuie reparate. De asemenea, pot apare schimbri n specificaiile
utilizatorilor, care vor diverse imbuntiri. ntreinerea const n gestionarea acestor
probleme.
3.2 Modelul cascad
Modelul cascad definete urmtorii pai n dezvoltarea unui program:
o Specificarea cerinelor
o Proiectarea arhitectural
o Proiectarea detaliat
o Scrierea codului
38

o Testarea componentelor
o Testarea sistemului
o Testul de acceptare
Nu se stipuleaz cum se fac aceti pai (metodologie, notaii), ci doar ordinea
efecturii lor.
Avantaje
O sarcin complex este mparit n mai multi pai mici, ce sunt mai uor de
administrat. Fiecare pas are ca rezultat un produs bine definit (documente de specificaie,
model, etc.)

39

Figura 3.1. Modelul de dezvoltare n cascad


3.3 Modelul cascad cu ntoarcere
Unul din dezavantajele modelului cascad este c ntr-un anume stadiu al dezvoltrii
nu se poate influena rezultatul obinut ntr-un stadiu precedent pentru a se remedia o
problema gasit. De exemplu, la testare se poate descoperi o eroare de proiectare.
Modelul cascad cu feedback propune remedierea problemelor descoperite n pasul
precedent. Problemele la pasul i care sunt descoperite la pasul i + 3 rmn neremediabile. Un
40

model realist ar trebui s ofere posibilitatea ca de la un anumit nivel s se poat reveni la


oricare dintre nivelele anterioare.
Dezavantajul principal al modelului n cascad este acela c clientul obine o viziune
practic asupra produsului doar n momentul terminrii procesului de dezvoltare.

Figura 3.2. Modelul de dezvoltare n cascad cu ntoarcere


3.4 Prototipizarea
O problem generala care apare la dezvoltarea unui program este s ne asigurm c
utilizatorul obine exact cea ce vrea. Prototipizarea vine exact n spriginul acestei probleme.
nc din primele faze ale dezvoltrii sistemului utilizatorului i se prezint o versiune
funcional a sistemului. Aceast versiune nu este ntregul sistem ci doar o parte a sistemului
care funcioneaz. Prototipul ajut clientul n ai defini mai bine cerinele i prioritile. Prin
41

intermediul unui prototip el poate nelege mai bine ce este posibil i ce nu este posibil de
realizat din punct de vedere tehnologic. Prototipul este de obicei produs ct mai repede, pe
cale de consecin, stilul de programare este de obicei (cel puin) negligent. ns scopul
principal al Prototipului este de a ajuta n stadiile de analiz i proiectare i nu folosirea unui
stil elegant.
Se disting dou tipuri de prototipuri
o de aruncat
o evoluionar.
n cazul realizrii unui Prototip de aruncat scopul este exclusiv obinerea unei specificaii.
De aceea nu se acord nici o importan stilului de programare. n cazul realizrii unui
Prototip evoluionar, scopul este de acrea un schelet al aplicaiei care s poata implementa n
prima faz o parte a cerinelor sistemului. Pe masur ce aplicaia este dezvoltat, noi
caracteristici sunt adaugate scheletului existent. n contrast cu prototipul de aruncat, aici se
investete un efort considerabil ntr+un design modular i extensibil, precum i n adoptarea
unui stil elegant de programare.
Avantaje:
o permite dezvoltatorilor s elimene lipsa de claritate a specificaiilor;
o ofer utilizatorilor ansa de aschimba specificaiile ntr-un mod ce nu afecteaz
drastic durata de dezvoltare;
o ntreinerea este redus, deoarece validarea se face pe parcursul dezvoltrii;
o se poate facilita instruirea utilizatorilor finali nainte de terminarea produsului.
Dezavantaje:
deoarece prototipul ruleaz ntr-un mediu artificial, anumite dezavantaje ale
produsului final ale produsului final pot fi scapate din vedere de client;
clientul nu nelege de ce produsul necesit timp suplimentar pentru dezvoltare,
avnd n vedre c produsul a fost realizat att de repede;
42

deoarece au n fiecare moment posibilitatea de a face acest lucru, clienii


schimb foarte des specificaiile;
poate fi nepopular printre dezvoltatori, deoarece implic renunarea la propria
munc.
3.5 Metode formale
n acest model de dezvoltare, sunt folosite formalismul i rigoarea matematicii. n
prima faz este construit specificaie n limbaj matematic. Apoi, aceast specificaie este
transformat n programe, de obicei ntr-un proces incremental.
Avantaje:
o precizia obinut prin specificarea formal;
o pstrarea corectitudinii n timpul transformrii specificaiei n cod executabil;
o ofer posibilitatea generrii automate de cod;
o potrivite pentru sisteme cu cerine critice.
Dezavantaje:
specificarea formal este de obicei o barier de comunicare ntre client i
analist;
necesit personal foarte calificat (deci mai scump);
folosirea impecabil a tehnicilor specificrii formale nu implic neaprat
obinerea de programe sigure, deoarece anumite aspecte critice pot fi omise din
specificaiile iniiale.

3.5 Modelul n spiral


Modelul n spiral ncearc s rezolve problemele modelului n cascad, pastrnd
avantajele acestuia: planificare, faze bine definite, produse intermediare. Deasemenea,
prototipizarea poate fi folosit dac se consider necesar.
Modelul n spiral definete urmtorii pai n dezvoltarea unui produs:
43

o studiul de fezabilitate;
o analiza cerinelor;
o proiectarea arhitecturii software;
o implementarea.
Modelul n spiral recunoate c problema principal a dezvoltrii programelor este
riscul. Riscul nu mai este eliminat prin asertiuni de genul: n urma proiectrii am obinut un
model corect al sistemului, ca i n modelul cascad. Aici riscul este acceptat, evaluat i se
iau msuri pentru contracararea efectelor sale negative.
Exemple de riscuri:
o n timpul unui proces ndelungat de dezvoltare, cerinele (noi) ale clientului sunt
ignorate;
o firma concurent lanseaz un program rival pe pia;
o un dezvoltator/arhitect prasete echipa de dezvoltare;
o echipa nu respect un termen de livrare pentru o anumit component;
o clientul schimb cerinele.

Figura 3.3. Modelul de dezvoltare n spiral

44

n modelul spiral (figura 3.3) se consider c fiecare pas din dezvoltare conine o
serie de activiti comune:
o pregtirea: se identific obiectivele, alternativele, constrngerile;
o gestionarea riscului: analiza i rezolvarea situaiilor de risc;
o activiti de dezvoltare specifice pasului curent (de ex. analiza specificaiilor sau
scrierea de cod)
o planificarea urmtorului stagiu: termenele limita, resurse umane, revizuirea
strii proiectului.

45

4. Tehnici de reprezentare ale algoritmilor.


4.1. Elaborarea schemelor logice de program.
Schemele logice de program se elaboreaz n urmtoarea succesiune:
analiza schemei logice de sistem pentru a determina natura prelucrrii datelor

(creare, validare, actualizare, transformare, listare, e.t.c. );


studierea structurii colectiilor de date de intrare i/sau de ieire;
definirea abstract a algoritmului n form de module cu anumite funcii;
elaborarea schemei logice de program.
n funcie de structur schemele logice pot fi:
scheme logice cu structuri secveniale;
scheme logice cu structuri alternative;
scheme logice cu structuri repetitive;
scheme logice cu structuri combinate.
Ultimile se ntlnesc de cele mai dese ori dat fiind faptul c orice algoritm este o
combinaie de structuri de diferite tipuri.
Structura secvenial presupune o parcurgere pas cu pas fr existena unor blocuri
de decizie. Aceste scheme pot fi strucrur secvenial simpl n situaia cnd nu conin
module de prelucrare, sau cu structur secvenial modularizat n varianta existenei unor
module de prelucrare caracterizate prin structuri secveniale simple.
Schema logic cu structur alternativ este caracterizat prin existena unor blocuri
de decizie n funcie de care prelucrarea alternativ n raport de valoarea condiiei specificate
n blocul de decizie. Schemele cu structur alternativ pot avea module specifice ndeplinirii
condiiei, nendeplinirii condiiei sau ambelor alternative de prelucrare.
Schema logic cu structur repetitiv este caracterizat prin utilizarea structurilor
repetitive condiionate anterior sau posterior, dar pot conine i structuri secveniale.

46

4.2. Pseudocod
Alturi de schemele logice pentru reprezentarea algoritmilor se pot folosi i limbaje de
reprezentare a algoritmilor denumite pseudo coduri.
Pseudocodul utilizeaz propoziii simple i complexe. Propoziiile simple descriu
operaii de prelucrare ce se vor codifica n aceast form ntr-un limbaj de programare.
Propoziii complexe exprim operaii ce vor trebui detaliate n propoziii simple la nivelul
unor module elementarei de aici direct n programul surs. n aceste propoziii se folosesc
cuvinte subliniate din limbaj i simbolul #, prin care se specific operaii de prelucrare
complexe definite ntr-un mod abstract.

4.3. Exemple de realizare ale algoritmilor


Problema 1
Pentru a o elibera pe Ileana Cosnzeana, Ft-Frumos trebuie s parcurg x km. El
merge zilnic a km, dar Zna-cea-Rea l duce napoi n fiecare noapte cu b km, b<a. Elaborai
un program prin intermediul cruia se va afia dup cte zile Ft-Frumos o elibereaz pe
Ileana Cosnzeana.
Algoritm:
alg
(argint a,b,x,
rez nr)
Scop |nr=numarul de zile n care Ft-Frumos o salveaz pe Ileana
Cosnzeana
ncep int s
s:=0;
s:=s+a;
s:=s-b;
nr:=1;
ccit s<x
s:=s+a;
s:=s-b;
nr:=nr+1;
sc
fin
47

Problema 13, pagina 34


Fiierul date.in conine un ir de caractere. De la tastatur se citete un ir de
caractere. Elaborai un program prin intermediul cruia se va determina numrul de cifre din
ir. Rezultatul va fi afiat la ecran, ct i n fiierul date.out
Algoritm:
alg
(args,
rez nr)
Scop |nr=numarul de cifre in sir
incep int i
i:=1;
nr:=0;
iccit i<length(s)
if(s[i]=0 or s[i]=1 or s[i]=2 or s[i]=3 or s[i]=4 or s[i]=5 or
s[i]=6 or s[i]=7 or s[i]=8 or s[i]=9)
nr:=nr+1;
i:=i+1;
sc
fin

48

4.4. Ciclul de via al produselor program


Ciclul de via al unui produs software reprezint intervalul de timp de la momentul
deciziei de realizare si pna la retragerea sau nlocuirea total a acestuia cu un nou produs
software, reprezentnd orizontul de timp n care opereaz i evolueaz produsul program.
Dup glosarul de termeni - terminologie software - ai IEEE (Institute of Electric and
Electronic Engineering), ciclul de via reprezint o abordare sistemic ncepnd cu
dezvoltarea, utilizarea, mentenan si pna la retragerea software-lui.
Din punct de vedere al utilizatorilor cele mai importante pri ale ciclului de via sunt
utilizarea curent (operaionalitate) i mentenan; produsele software sunt dezvoltate pentru
a satisface nevoile consumatorilor/utilizatorilor. Din punctul de vedere al realizatorilor,
etapele cele mai importante sunt cele n care se construiete produsul software.
Durata ciclului de via al unui produs software depinde de caracteristicile de calitate
i performana ale acestuia, dar i de o serie de factori externi produsului software cum sunt:
stabilitatea funcional, relaiile sale cu mediul, dinamica metodelor, tehnicilor, conceptelor
etc.
Ciclul de realizare este o noiune derivat din cea de ciclu de via acoperind
intervalul dintre momentul deciziei iniiale de realizare i pna la punerea n funciune a
produsului software. Acest interval, mprit n general n etape, presupune analiza
problemei,

proiectarea

produsului

software,

implementarea

de

cod,

testarea

experimentarea acestuia, deci reprezint o parte a ciclului de via i anume cea care are ca
scop dezvoltarea produsului.
Dezvoltarea de software de nalt calitate necesit procese de producie software,
utilizate pentru a dezvolta aceste produse, principii de inginerie software, pe care sa se
bazeze aceste procese i care ncorporeaza practici ale ingineriei software.
Principiile dezvoltarii software sunt legate de calitate, de management i de
inginerie. Aceste principii se reflect n calitatea produsului software, n termenele de
realizare, precum i n costurile implicate.

49

Referitor la principiile calitii se poate spune ca noiunea de calitate nu nseamn


numai testarea acesteia pentru un produs software, ci i construirea i asigurarea calitii n
procesele software.
Principiile generale sunt :
1. prevenirea defectelor;
2. asigurarea faptului c defectele au fost detectate i corectate ct mai mult posibil;
3. stabilirea i eliminarea cauzelor care produc anumite simptome;
4. audit n conformitate cu standarde i proceduri.
n ceea ce priveste principiile de management putem aminti:
1. planificarea tuturor activitilor necesare n realizare din punct de vedere al timpului,
bugetului,
2. resurselor si restriciilor de calitate.
3. monitorizarea continu, mbuntirea progresiva a planurilor, revizuirea planurilor
dac anumite limite de toleran au fost depite.
4. definirea clara a structurii, rolurilor, responsabilitilor i liniilor de comunicaie ntre
grupuri sau indivizi, persoane implicate n realizare.
Ca principii de inginerie se pot preciza:
a) descrierea clar a problemei - care ntmpin dou tipuri de dificulti majore:
b) cerinele sunt exprimate de obicei n termenii problemei reale (cerine reale) i
trebuie translatate n termenii uzuali contextului software;
c) utilizatorul nu poate preciza complet cerinele sale sau nu poate sa gseasc
legatura dintre ele;
d) definirea i selectarea soluiei printr-o clara definire a componentelor;
e) controlul riguros al relaiilor dintre componente.

50

5. Dezvoltarea metodelor de programare


Crearea programelor noi este un proces complex, structura cruia se perfecioneaz
permanent. Dac la nceput construirea de produse program era considerat o art, astzi se
cunosc diverse metode i tehnici de realizare a produselor program. Metodologia de
elaborare a produselor program a cunoscut o evoluie continu. Complexitatea crescnd a
produselor soft realizate, pe de o parte, i noile generaii de limbaje de programare, pe de alt
parte, au influenat dezvoltarea de noi metode de realizare aprogramelor.
Metodele de programmare sunt ansambluri de concepte, tecnici, reguli i procedee
folosite n mod organizat i sistematic n activitatea de programare n conformitate cu
obiectivele globale.
Pe parcursul anilor de dezvoltare al tehnologiilor informaionale au fost aplicate multe
metode de programare i acum putem generaliza i spune cu certitudine c cele mai
rspndite au fost i sunt trei metode:
Programarea clasic
Programarea structurat
Programarea modular
5.1. Metoda programrii clasice
Metoda programrii clasice a fost pe larg utilizat la programarea n coduri, limbaje
simbolice i chear i dup apariia primelor limbaje evaluate( Cobol, Fortran Basic e.t.c.).
Metoda programrii clasice are la baz utiliyarea unor concepite elementare de programmare
care conduc la organizarea monolitic(ntr-un singur bloc) a programului. Metoda presupune
o succesiune de faze ale procesului de proiectare i elaborare a programelor, concretizate n
Studierea problemi care face obiectul programrii
Elaborarea schemi logice de sis te i de program ntr-o abordare proprie a
programatorului, fr utilizarea unor standarde de programmare )module,
structuri e.t.c.=
Scrierea programului ntr-un limbaj de programmare i obinerea programului
51

surs prin introducerea de la terminal


Transformarea programului surs ntr-un program executabil i dep narea
programului prin testare cu date reale
Actualizarea
Metoda programrii clasice prezint particularitatea folosirii unor concepte
elementare, ceea ce conduce la realizarea unei structuri spontane a schemi logice de
program, fr utilizarea unor module sau structuri adecvate.
Aceast metod conine o serie de neajunsuri, printre care se enumer:
Descrierea procesului de prelucrare folosete o logic nestructurat, care
apeleaz frecvent la operaii de recere la anumite servente de instruciuni (GO
TO), ceea ce conduce la realizarea unei scheme logice complicate;
Schema logic nu are la baz tehnici i procedee care s asigure o eficien
nalt activitii de programare;
Consultarea i nelegerea schemei logice a programului devin deficile n cadrul
programelor complexe chiar i n condiiile n care exist o documentaie
detaliat a programului respectiv;
Planificarea i coordonarea activitii de programare sunt dificile deoarece nu
pot fi stabilite cu exactitate termenele de realizare;
Lucrul n echip nu poate fi realizat datorit dezavantagelor programrii clasice.
5.2.Programarea structurat
Programarea structurat este o metod independent de limbajul de programare, care
impune reguli stricte n conceperea algoritmilor de rezolvare a problemelor. Ea disciplineaz
realizarea algoritmilor prin restrngerea structurilor de control utilizabile la un numr redus
de tipuri.
Idea programrii structurate a fost expus prima dat n 1968 de ctre Dijkstra.
Problema de baz de care se preocupa Dijkstra era demonstrarea corectitudinii programului.
El i-a concentrat eforturile asupra structurii programului, care ar permite uor s
52

demonstrm corectitudinea acestuia.


Experiena a demonstrat, c un program alctuit dup metoda programrii structurate
practic conine doar greeli triviale, care uor se corecteaz. Aa programe pot fi testate
complet trecnd prin toate componentele acestuia.
Productivitatea programrii crete de 5-6 ori.
Programele structurate se citesc ca un text obinuit de sus n jos, fr a efectua salturi,
deoarece au o structur succesiv.
Aa programe uor se documenteaz deoarece nsui textul programului conine
informaie despre problema rezolvat.
Programele executabile sunt efective numai dac compilatorul este destul de calitativ.
Un compilator calitativ permite s primim un program efecient numai dac programul surs
este bine structurat.
Metodele de baz ale programrii structurate sunt:
a) proiectarea descendent;
b) programarea modular;
c) refuz de ntrebuinare nesistematizate a salturilor necondiionate;
d) realizarea unui numr redus de tipuri de structuri i clase;
e) detalierea pe pai (stepwise refinement), adic rafinare succesiv.
Bazele teoretice ale programrii structurate este primit de a le considera pe cele expuse
de matimaticienii italieni C. Bohm i G. Jacopini publicate n anul 1966.
Acest principiu de baz deriv din teorema de structur a lui Bohm-Jacopini care arat,
c orice algoritm poate fi construit folosind doar trei tipuri destructuri de control:
secvenial, alternativ i repetitiv.
Toate trei structuri conin blocuri funcionale, care se folosesc pentru a nota aciunile
de prelucrare a informaiilor.
Un bloc poate conine o singur instruciune sau un set de instruciuni cu o singur
intrare i o singur ieire:

53

Structura secvenial este o structur n care controlul se transmite succesiv de la un


bloc funcional la altul, ieirea fiecrui bloc precedent fiind ntrarea urmtorului. Schematic
aceast structur se prezint astfel:

Orice aciune complex, prezentat n forma unui bloc funcional poate fi prezentat
printr-o succesiune de blocuri n forma de structur secvenial i invers o succesiune de
blocuri poate fi nlocuit printr-un singur bloc.
Structura alternativ. Aceast structur servete pentru a alege unul din dou blocuri
funcionale n dependen de careva condiii:

La execuia acestei structuri, mai nti se verific rezultatul condiiei P, dac este
adevr se execut blocul S1, dac este fals se execut blocul S2.
Structura repetitiv. Aceast structur se utilizeaz pentru a nota aciunile ce se repet
de mai multe ori.

Execuia acestei structuri ncepe de la verificarea condiiei P. Dac condiia se respect


(+), se execut blocul S, apoi din nou se verific condiia. Aciunea se repet pn cnd
condiia nu devine fals, imediat cum urmtoarea verificare d un rezultat fals (-) se execut
ieire din bloc.
Toate trei tipuri de structuri au o singur intrare i o singur ieire i deci pot fi
prezentate ca un bloc funcional cu o singur intrare i o singur ieire.
Deci, rezult c orice program structurat poate fi prezentat ca o structur secvenial:

Unde S1, S2, ... , Sn sunt structuri.


54

Blocurile urmeaz n aceiai ordine cum se execut i reflect structura aciunilor


desfurate n timp.
Un program structurat permite transformri ce-l vor reduce la un singur bloc
funcional.
5.3.Metoda programrii modulare
Prin programare modular nelegem metoda de proiectare a unui algoritm pentru
rezolvarea unei probleme prin descompunerea ei n subprobleme proiectate i programate
separat. Astfel programator se concentreaz numai asupra subproblemei pe care o are de
rezolvat, considernd-o ca o problem senistttoare. Evident, c rezolvarea subproblemei
este mai simpl ca rezolvarea ntregii probleme.
Aceast metod presupune identificarea funciilor programului pentru o analiz
arboriscent (top-down) urmat de stabilirea logicii de trecere de la o funcie la alt.
Segmentele definite pentru funciile programului se numesc module.
Cnd vorbim de programare modular folosim termenul programare n sens larg,
pentru ntreag activitate de realizare a programului (proiectare i implementare).
Menionm, c ntr-o programare serioas nu se poate ajunge la implementare fr a avea n
prealabil algoritmii descrii ntr-un limbaj de descriere. Deci programarea modular se refer
n primul rnd la proiectarea modular a algoritmilor, i apoi la trducerea lor n limbajul de
programare ales, innd cont de specificul acestui limbaj.
Programarea modular este strns legat de proiectare ascendent i descendent,
ambele presupunnd folosirea subalgoritmilor.
Ce este modul?
Modulul este considerat o unitate structural sinestttoare: program, subprogram,
unitate de program. Un modul poate conine sau poate fi coninut ntr-un alt modul (pot fi
imbricate). Un modul poate fi format din mai multe submodule- n Turbo Pascal, de
exemplu, UNIT-urile pot fi considerate module. La compilarea separat un grup de
subprograme compilate deodat constituie un modul, dar acest modul poate fi considerat ca o
55

mulime de submodule din care este compus.


Este important ca fiecare modul s-i aib rolul su bine precizat, s realizeze o funcie
n cadrul ntregului program.
Indefirent c privim modulul ca un singur subalgoritm, sau un algoritm sinestttor ce
apeleaz ali subalgoritmi, considerm modulele relativ independente, dar cu posibiliti de
comunicare ntre ele.
Un modul nu trebuie s fie influenat de maniera n care se lucreaz n interiorul altui
modul. Orice modificare ulterioar n structura unui program, dac funcia pe care o
realizeaz modulul M nc este necesar, nu trebuie s afecteze coninutul acestui modul.
Avantajele programrii modulare sunt multiple. Menionm cteva din ele:
Descompunerea unei probleme complexe n subprobleme este un mijloc convinabil
de a reduce complexitatea.
Testarea modulelor este mult mai uoar.
Module pot fi refolosite de cte ori avem nevoie de ele. Astfel s-a ajuns la
compilarea separat a modulelor i pstrarea modulelor testate n biblioteci de
subprograme, de unde se pot refolosi la nevoie. Aceast posibilitate duce la mrirea
productivitii n programare i la creterea siguranei n expluatare.
Uneori, n timpul proiectrii algoritmului sau a implementrii lui se ajunge la
concluzia c proiectarea a fost incomplet sau c unele module sunt ineficiente. i n aceast
situaie programarea modular este avantajoas, ea permite completarea sau nlocuirea
modulului cu altul mai performant.
ntregul program conine un modul principal i mai multe module intermediare, care
apeleaz la rndul lor alte module elementare.
Descompunerea programului n funcii i subfuncii poate fi realizat dup diferite
criterii:
- omogenitatea funciilor;
- uniformitatea aplicrii algoritmilor;
56

- utilizarea unor structuri de date omogene;


- independena funcional a fiecrui modul;
- planificarea activitii de programare.
Procesul de concepere i elaborare a programelor dup metoda programrii modulare
cuprinde urmtoarele faze:
- studierea problemei;
- identificarea modulelor i construirea diagramei de structur;
- stabilirea legturilor dintre module;
- analiza posibilitilor de utilizare a unor module standard din biblioteci;
- elaborarea modulelor i testarea individual a acestora;
- integrarea i listarea modulelor n programe i a acestora n uniti funcionale.
Aceast metod de programare se aplic pe scar larg n lucrri complexe din diverse
domenii de activitate i conduce la urmtoarele avantaje:
- reducerea complexitii;
- creterea calitii;
- testarea simpl;
- refolosirea modulelor;
- posibilitatea alegerii unor limbaje de programare optime.

57

6. Norme i reguli de redactare a codului surs


Aplicarea metodei programrii modulare presupune, n primul rnd, elaborarea PP n
echipe de programatori. Aici se stabilesc reguli de scriere a programelor, deoarece un
programator la orice etap de dezvoltare a PP poate fi nlocuit prin alt programator i
respectarea regulilor devine obligatorie n caz contrar prelungirea proiectului devine
anevoioas iar uneori chiar imposibil.
Cu uurin putem deosebi un modul scris de un elev sau un amator de unul elaborat
de un programator profesionist. Programele scrise de profesioniti sunt de cteva ori mai
mari dup volum, se citesc uor, conin mesaje de diagnosticare, prevd toate situaiile
excepionale, etc.
Regulile i principiile de scriere profesional a programelor surs pot fi grupate dup
cum urmeaz:
Descrierea tipurilor de date;
Reglarea constantelor;
Alegerea numelor de identificatori;
Divizarea datelor de intrare n seturi independente de date;
Identificarea modulului i al versiunii lui de dezvoltare;
Verificarea datelor de intrare i afiarea mesajelor despre erori;
Diagnosticarea ramificat a situaiilor excepionale;
Aranjarea textului programului surs ;
Scrierea comentariilor;
6.1 Descrierea tipurilor de date
Esena noiunii de tip rezid n tentativa de grupare a unor obiecte dup caracteristici
comune. Conceptul de tip de date este vzut ca o mulime de valori posibile, care formeaz
domeniul acestuia i o mulime de operaii, funcii, relaii care opereaz cu aceste valori. n
grupul de reguli Descrierea tipurilor de date se includ urmtoarele restricii:
a) toate variabilele i tipul lor se descriu la nceput de program;
58

b) tipul variabilei corespunde mulimii minime necesare de valori;


c) nu se admite descrierea implicit a tipului;
d) se interzice existena variabilelor, care nu sunt utilizate n modul.
6.2. Reglarea constantelor
Utilizarea ne reglat de constante are ca rezultat pstrarea aceleiai constante n mai
multe locaii din memoria operativ, lucru inadmisibil n situaia deficitului de memorie.
Din acest motiv, se recomand ca toate constantele din program s fie declarate explicit la
nceput de program. n situaia cnd limbajul de programare nu permite acest lucru, n loc de
constante se utilizeaz variabile crora li se atribuie valoarea respectiv la nceput de
program i n aa mod se evit faptul utilizrii multiple a aceleiai valori constante. Tot aici
menionm c unele constante se utilizeaz ca valori prestabilite pe o perioad ndelungat,
dar care cu timpul trebuie nlocuite. Spre exemplu salariul minim, % de impozit, % de
asigurare social, etc. Evident c pstrarea lor n form de constante reglate este mult mai
convenabil dect apariia lor n algoritm n form de valori numerice.
6.3. Alegerea numelor de identificatori
Numele identificatorului se alctuiete dup regulile stabilite de limbajul de
programare. Majoritatea limbajelor accept identificatori numele crora ncepe din liter i
este continuat de litere, cifre i unele semne speciale. Recomandrile la alegerea numelui
identificatorului sunt urmtoarele:
a) Numele exprim sensul valorilor pstrate, prelucrate sau transmise de modul
b) Lungimea numelui variaz n diapazonul 3-6 caractere mai ales n cazurile utilizrii
frecvente.
c) Abrevierea utilizat n calitate de nume trebuie s se pronune uor.
d) Se oblig utilizarea unor nume de identificatori unici discutai i aprobai de echipa
elaboratorilor.
Exemple de identificatori: ARIA B12

i j

59

A_32

6.4. Divizarea datelor de intrare n seturi independente de date


Datele de intrare de obicei sunt compuse din setul de baza i un set de parametri de
gestiune cum ar fi:
a) numrul elementelor unui tablou
b) un caracter din poziia meniului
c) o decizie Yes/No
Parametrii de gestiune intr-un program sunt un numr nu prea mare de variabile de
diferite tipuri valorile crora apar n mesajele de gestiune i cer a fi introduse n formatul
propus de program.
Setul de baz poate avea diferite surse i n acest caz se procedeaz astfel: pentru fiecare
surs se elaboreaz cte un modul, aceasta faciliteaz modificarea programului n caz dac
se schimba formatul de prezentare a datelor.
Utilizarea produsului program tot este mai comod deoarece nu cere prelucrarea
concomitent a mai multor surse.
Datele n funcie de suport pot cere codificri i decodificri. Elaborarea modulelor
respective permite s nu fie afectat modulul principal de prelucrare.

6.5. Identificarea modulului i al versiunii lui de dezvoltare


Orice program sau modul trebuie n primul rnd sa afieze pe ecran sau s tipreasc la
imprimant denumirea sa oficial i numrul versiunii precum i data modificrii modulului.
Excepie din regul o prezint modulele apelate de mai multe ori. n aceste module
denumirea oficial i numrul versiunii se nscrie n comentariul de baz al programului.
La orice modificare al modulului numrul versiunii se mrete cu o unitate iar data se
modific prin data introducerii modificrilor.
6.6. Verificarea i diagnosticarea datelor de intrare
Verificarea datelor de intrare trebuie s fie efectuat n fiecare modul pentru asigurarea
fiabilitii i robusteii PP. Aceast regul este numit principiul nencrederii totale.
n primul rnd se verific toi parametrii de gestiune, pentru a evita utilizarea incorect
60

a modulului. Uneori aceti parametri sunt inclui n modulul de apelare i verificarea lor se
dubleaz de fapt din acelai motiv.
Verificarea datelor i afiarea erorilor pot fi realizate prin diverse metode cu un grad
diferit de detaliere. Putem discuta despre cteva tipuri de verificri frecvent utilizate i
anume:
a) aparinerea domeniului de valori posibile;
b) ne contrazicerea reciproc a valorilor parametrilor;
c) asigurarea comoditii introducerii datelor de ctre utilizator.
Mesajele de eroare trebuie s fie scurte, clare i nsoite de denumirea modulului care a
depistat eroarea.
Dup prelucrarea situaiilor care au provocat erori neaprat dup afiarea mesajelor sunt
posibile urmtoarele variante de aciune n program:
a) introducerea datelor se repet de cteva ori(3-5);
b) controlul este transmis la sfrit de program (STOP);
c) ntoarcerea n modulul de apel ;
d) corectarea automat a erorii i continuarea execuiei modulului.
Corectarea automat se recomand numai n caz dac eroarea este absolut evident i nu
va provoca funcionarea incorect a modulului.
Evident c exist situaii cnd datele de intrare nu este nevoie s fie verificate i anume:
a) datele de intrare sunt pe suporturi magnetice i corectitudinea lor este asigurat de
verificrile precedente;
b) datele de intrare sunt date finale al altui modul corectitudinea crora este garantat;
c) volumul datelor de intrare este foarte mic, uor se verific vizual i nu influeneaz
funcionarea altor module.
Recomandri suplimentare:
1) La prelucrarea seturilor mari de date ntreruperea programului nu se efectueaz la fiecare
eroare depistat. Erorile se acumuleaz i dup prelucrarea ntregului set se indic

61

numrul liniei (nregistrri) cu erori i explicaii despre erorile depistate. Clar c aceste
nregistrri cer s fie corectate i nc o dat se introduc.
2) Metodele enumerate evident nu ntotdeauna asigur corectitudinea absolut a datelor. De
exemplu, dac cifra 6 a fost nlocuit cu 0 . a. Dac aceste erori nu permit obinerea
rezultatelor n formulare se introduc date suplimentare care permit verificare
corectitudinii. Spre exemplu n sistemele contabile, bancare toate formularele cu numere
de mare valoare conin sume de control n care toate valorile bneti din formular se
nsumeaz. La introducerea datelor suma se verific repetat i dac se depisteaz devieri
prelucrarea datelor se repet. Dac suma de control nu poate fi pstrat n ntregime se
pstreaz o parte din numr de regul poziiile inferioare. Uneori aceast sum se mai
nmulete cu numrul liniei sau numrul formularului pentru a evita coincidena de
valori din diferite linii sau formulare.
6.7. Diagnosticul situaiilor excepionale
Prelucrarea situaiilor excepionale, dup cum a mai fost menionat, deosebete un
program profesionist de unul elaborat de amatori i asigur n mod direct robusteea
modulului. Situaia excepional se definete ca o eroare aprut n procesul funcionarii care
nu permite continuarea corect al programului. De cele mai dese ori acestea sunt erorile ne
respectrii formatului de date sau erori aprute la transformarea datelor dintr-un tip n altul.
Diagnosticul acestor situaii se afieaz n form de mesaje ce conin descrierea cauzei
apariiei situaiei excepionale i sursa care a provocat situaia (numele fiierului,
dispozitivul, numele variabilei interne). Prelucrarea situaiilor excepionale coincide cu cea
al erorilor n datele de intrare i include urmtoarele variante de aciune n program:
introducerea datelor se repet de cteva ori(3-5);
controlul este transmis la sfrit de program (STOP);
ntoarcerea n modulul de apel ;
corectarea automat a erorii i continuarea execuiei modulul.
62

Exemple de situaii excepionale.


Exemplul 1 mprirea la zero
Exemplul 2 Deschiderea unui fiier inexistent
Exemplul 3 Convertirea nereuit a datelor cum ar fi convertirea unui ir n numr.
6.8. Aranjarea textului programului surs
Formatarea textului surs sau aranjarea lui pe foia de tipar dup anumite reguli duce la
comoditatea citirii programului uureaz verificarea i modificarea programului. Regulile de
scriere a textului programului pot fi stipulate astfel
n fiecare linie se plaseaz una-dou instruciuni
se aliniaz spre dreapta cu una dou poziii toate structurile imbricate
dup fiecare sfrit de structur imbricat se nscrie comentariul care indic numele
structurii ce se finalizeaz
toate cuvintele rezervate din limbajul de programare respectiv se evideniaz
Exemplu de aranjare corect.
program p123;
type vector=array[1..10] of integer;
var a,b:vector;
k,i,n,nmax:integer;
begin
writeln('n='); readln(n) ;
for i:=1 to n do readln(a[i]);
writeln('ai introdus');
for i:=1 to n do writeln(a[i]);
if a[i]=0 and a[i+1]=0 then k:=k+1;
b[i]:=a[i];
if a[i]>0 then nmax:=a[i];
writeln('secventa c.m. lunga ',nmax);
end.

63

Comentarea programelor.
Comentariile se nscriu n programe pentru al face mai neles i nu pentru al
suprancrca cu informaii suplimentare

puin informative care sunt clare oricrui

programator. Un aspect esenial al comentariul nereuite este o explicaie detaliat al


realizrii. Comentariile reuite evideniaz momentele importante n programul elaborat.
n comentariul de baz scris imediat dup antetul programului se nscrie enunul
problemei elaboratorul programului i data ultimei modificri.
n blocul declaraiilor de date se comenteaz variabilele rezervate pentru setul
principal de date.
n blocul de subprograme se comenteaz n mod obligatoriu nceputul i sfritul
fiecrui subprogram.
n blocul algoritmic prin comentarii se descrie de fapt algoritmul general realizat n
limbajul de programare.

64

7. Calitatea programelor
Cnd vorbim despre calitatea unui lucru (constructie sau obiect) de obicei lum n
calcul mai muli factori. Printre acetia se pot numra: calitatea realizrii - ct de bine este
lucrat, dac exist defecte n materialul din care este fabricat ...
designul - eleganta, comfortul oferit...
o combinate ntre design si calitatea realizrii.
Atunci cnd suntem pui n situaia de a compara dou obiecte similare, de exemplu
dou scaune, putem spune c din punctul de vedere al calittii unul este mai bun dect
cellalt, ns n general este dificil de precizat cu ct este mai bun. n cazul programelor nu se
poate evalua calitatea realizrii. Din acest punct de vedere ingineria programrii este o
disciplin unic ntre toate disciplinele inginereti. Toate atributele calitii se refer aici la
design. Desigur, ne-am putea referi i la valori de ordin estetic. ns programele sunt n mare
parte invizibile, iar valorile estetice conteaz doar pentru prile vizibile. nafar de interfaa,
singurele aspecte observabile la un program sunt notaiile folosite pentru design i scrierea
codului, precumsi modul n care se comport programul atunci cnd interacioneaz cu alte
entiti. Pentru a putea vorbi despre calitatea unui program trebuie s definim atribute ale
calitii care ne intereseaz i s cutm modaliti de msurare a lor, trebuie s putem da o
reprezentare designului i s scriem specificaii care s ghideze programatorii astfel nct
calitile designului s fie respectate i de implementare.
Codul surs care implementeaz un design poate fi privit ca o reprezentare a acelui
design. ns asigurarea calitii unui program numai dup scrierea codului este, n general,
un proces deosebit de costisitor. Este greu s dm o definiie calitii unui program. Ar trebui
s lum n calcul aspecte de tipul:
programul funcioneaz i, n plus, funcioneaz aa cum are nevoie utilizatorul s
funcioneze.
programul face ceea ce trebuie s fac.
programul este sigur.
programul poate fi adaptat pe msur ce nevoile utilizatorului se schimb.
65

Aceti factori nu pot fi msurai n mod absolut, ns ne furnizeaz cteva concepte la care ne
putem referi atunci cnd vorbim despre calitatea unui program. Ele sunt sigurana, eficiena,
ntreinerea i, nu n ultimul rnd, uzabilitatea programului.
Un program este sigur dac este
complet - trateaz toate intrrile posibile;
consistent - se comport ntotdeauna aa cum este ateptat;
robust - se comport bine n situaii anormale (de exemplu lipsa unei
resurse necesare).
Un program este eficient dac utilizeaz ntr-un mod judicios resursele disponibile
(memorie, procesor, reea). Eficiena este ntotdeauna mai puin important dect sigurana.
Este mai uor s facem un program sigur s fie eficient dect un program eficient s fie sigur.
ntreinerea se refer la uurinta cu care poate fi modificat ulterior designul programului.
Exist mai multe tipuri de ntreinere:
corectiv - are drep scop eliminarea erorilor din program;
perfectiv - presupune adugarea de funcionaliti care ar fi trebuit s fie oferite;
adaptiv - se refer la actualizarea programului pe msur ce se schimb
cerintele.
Uzabilitatea are n vedere ct de uor este programul de nvat i de folosit. Putem da
ns o msur obiectiv tutror acestor caracteristici? Rspunsul este negativ. Fiecare dintre
atributele de mai sus poate fi apreciat n mod diferit de ctre diferite persoane, deci sunt
criterii subiective. Singurele atribute msurabile sunt cele care vizeaz codul surs. Acestea
sunt simplitatea i modularitatea codului surs. Simplitatea este msura invers a
complexitii. Complexitatea, la rndul ei, se poate referi la:
complexitatea fluxului de control care numr cile posibile de execuie ale unui
program.
complexitatea fluxului de informaii care numr cantitatea de date care sunt
transmise n program sub form de date de intrare/ieire sau parametric ai funciilor;

66

complexitatea nelegerii care se refer ca numrul identificatorilor i operatorilor


folosii.
Scopul, atunci cnd scriem un program, este s obinem un cod surs ct mai simplu
posibil. De obicei acest deziderat nu se obine din prima dat, ci este rezultatul unui proces
de rescriere si simplificare a variantei iniiale a programului.
Modularitatea, pe de alt parte, poate fi msurat uitndu-ne la coeziunea i cuplajul
modulelor din program. Coeziunea se refer la ct de bine lucreaz mpreun componentele
unui modul, iar cuplajul msoar gradul de interaciune ntre module. Scopul l constituie
obinerea unui progam ale crui module au un grad nalt de coeziune (fiecare ndeplinete o
sarcin specific) i ntre care exist ct mai puine dependene (cuplaj mic).

67

Bibliografie:
1. Elaborarea programelor. Metode i tehnici moderne. Militon Freniu, Bazil Prv.
Editura PROMEDIA ,1994
2. Tehnologii de elaborare a proiectelor. Ovidiu Gheorghie, Adriana Gheorghie
Universitatea Al. I. Cuza, Iai, Note de curs, 2005
3. Turbo Pascal. Culegere de probleme. Andrei Braicov, Editura Prut Internaional,2005
4. Informatica de gestiune Manualul pentru licee economice clasa XII. I. Roca . a.,
Didactica pedagogic, Bucureti 1996
5. Cursul IT Essentials Academia CISCO
6.
Bibliografie suplimentar:
1.

***Elaborarea de tehnologii noi i modernizate pentru realizarea i ntreinerea


produselor program, Tema de cercetare, I.C.I., 1985-1986.

2.

***Indicaii metodologice pentru realizarea sistemelor informatice i a produselor


program, vol. I - III, I.T.C.I., 1987.

3.

Bragaru T. Tehnologii de realizare a informatizrii nvmntului i cercetrii n Republica


Moldova: Tez de doctorat. - Chiinu-Bucureti, 1995. -200 p.

4.

DEX - Dicionarul explicativ al limbii romne, Academia Romn, Institutul de


lingvistic Iorgu Iordan, Ediia a II-a.

5-

Bucureti: Univers enciclopedic, 1998

68