UNIVERSITATEA DIN BACU FACULTATEA DE INGINERIE

DAN ROTAR

INGINERIA PROGRAMELOR
Note de curs Indrumar de laborator

EDITURA ALMA MATER BACU 2007

Pag. 1.1. 2.1. 2.2. 2.3. 2.4. 2.5. 2.5.1. 2.5.2. 3.1. 3.2. 3.2.1. 3.2.2. 3.2.3. 3.3. 3.3.1. 3.3.2. 3.4. 3.5. 3.5.1. 3.5.2. 3.5.3. 3.5.4. 3.6. 3.7. 3.8. 3.9. 3.10. 3.11. 4.1. 4.2. 4.2.1. Capitolul 1 Generaliti Ingineria programrii. Aspecte generale Capitolul 2 Noiuni fundamentale de programare Elemente de programare Algoritmi Elemente de programare structurat. Pseudocodul. Scheme logice program Proiectarea programelor. Tehnicile top-down i bottom-up Tehnica top-down Tehnica bottom-up Capitolul 3 Reguli pentru scrierea codului program Generaliti Caracteristicile rutinelor calitate Coeziunea rutinelor Cuplarea rutinelor Dimensiunea rutinelor Modularizarea Atributele modulelor Organizarea fizic a modulelor Tipuri de date, declaraii i variabile Stabilirea numelor Consideraii asupra capitalizrii (utilizarea literelor mari i mici) Prescurtri Poziia componentelor n interiorul identificatorului Nume de evitat Organizarea structurilor de control Expresii Structura programului Comentariile i documentarea programului Codul neterminat Referine ctre alte documente Capitolul 4 Verificarea programelor Generaliti Metode de verificare a corectitudinii programelor Metoda aseriunilor invariante 3 6 11 12 12 17 19 19 23 24 26 26 27 28 28 29 29 30 34 34 36 37 39 41 49 52 56 58 60 61 63 63

4.3. 4.3.1. 4.4. 4.5. 4.6. 4.6.1. 4.6.2. 4.6.3. 4.6.4. 5.1. 5.2. 5.2.1. 5.2.2. 5.3. 5.3.1. 5.3.2. 5.3.3. 5.3.3.1. 5.3.3.2. 5.3.3.3. 5.3.3.4. 5.3.3.5. 5.3.3.6. 5.3.3.7. 5.3.3.8. 5.3.3.9. 5.3.3.10. 5.3.3.11. 5.3.3.12. 5.3.4. 5.3.4.1. 5.3.4.2. 5.3.4.3. 5.3.4.4. 5.3.4.5. 5.3.4.6. 5.3.5. 5.3.6. 5.3.6.1. 5.3.7.

Testarea i depanarea programelor Noiuni de baz Strategii de testare Moduri de testare Metodologia testrii structurate Analiza de concepere Analiza static Testarea dinamic Generarea datelor de test Capitolul 5 Ingineria programrii asistat de calculator Introducere Prezentarea programului Axiom Sys Analiza structural Modelarea arhitectural Construirea modelului analizei structurale Particularitile analizei structurale ntlnite la programul Axiom Sys Crearea proiectului Crearea diagramei de context Adugarea unui proces Mutarea/redimensionarea unui proces Adugarea unui terminator Adugarea datelor i a fluxului de control Mutarea fluxului de date Salvarea diagramei de context Adugarea unui flux de control Adugarea unei specificaii-p la proiect Verificarea specificaiei-p Adugarea textului unui terminator Introducerea definiiilor pentru itemurile de date Explorarea itemurilor de date Crearea Diagramei de flux fiu Adugarea unui proces Adugarea unui flux Adugarea posibilitilor de stocare a datelor Corespondena diagramei de flux cu procesul printe Explorarea specificaiilor p Explorarea diagramelor de flux Validarea proiectului AxiomSys Crearea rapoartelor Crearea unui model de raport Tiprirea unui raport LABORATOR Laborator 1. Realizarea unui program de gestiune a unei reele de calculatoare Laborator 2. Proiectarea schemei logice 4

64 64 65 67 68 68 69 70 71 73 73 74 75 75 75 76 77 77 78 78 79 80 81 81 81 83 84 85 89 90 91 92 94 95 95 96 96 96 97 101 103 104

Laborator 3. Prezentarea programului Axiom Sys Laborator 4. Analiza structural Laborator 5. Analiza arhitectural Laborator 6. Construirea modelului analizei structurale Laborator 7. Crearea proiectului Laborator 8. Introducerea definiiilor pentru itemurile de date Laborator 9. Crearea Diagramei de flux Laborator 10. Validarea proiectului AxiomSys Laborator 11. Crearea rapoartelor Laborator 12. Scrierea programelor n mai multe limbaje de programare Laborator 13. Analiza metodelor de verificare a programelor ntrebri de verificare Bibliografie

104 105 105 117 117 117 118 118 118 118 125 126 133

CAPITOLUL 1 GENERALITI
1.1. Ingineria programelor. Aspecte generale
nul din aspectele cele mai importante ale tehnologiei elaborrii programelor este reprezentat de ingineria programrii. Un program, ca orice alt produs, trebuie s aib anumite caracteristici n aa fel nct s el s poat fi exploatat i ntreinut n condiii ct mai bune. Spre deosebire ns de alte domenii ale ingineriei, elaborarea programelor reprezint o activitate profund creativ care implic problema proprietii intelectuale. Acest aspect inedit al elaborrii produsului program presupune mpletirea trsturilor specifice activitii de creaie cu cele ale produciei industriale. Din acest motiv domeniul ingineriei programrii este un domeniu nc profund controversat existnd puine reglementri unanim acceptate. Actul de creaie este unic reflectnd personalitatea, cultura, gradul de inteligen i talentul creatorului. Acest aspect al creaiei, reflectat i n creaia software, intr adesea n contradicie cu ncercarea de a impune anumite reguli care s permit obinerea unor performane industriale cum ar fi randamentul, eficiena, productivitatea, etc. Este evident ns c aspectul tehnic al acestui act de creaie permite standardizarea numitor faze ale elaborrii produsului program. Din acest punct de vedere se poate da o prim definiie a ingineriei programrii. Ingineria programrii este un domeniu al informaticii care are ca obiectiv stabilirea celor mai adecvate concepte, principii, reguli, metode, tehnici, soluii, procedee i instrumente care s conduc la elaborarea, utilizarea, ntreinerea i perfecionarea produselor program (inclusiv documentaia aferent) n condiii de maxim eficien, asigurndu-le o nalt calitate, att n utilizare (fiabilitate, eficien i flexibilitate) ct i la ntreinere/dezvoltare (mentenabilitate i perceptibilitate), n conformitate cu specificaiile de definire. Exist numeroase aspecte legate de elaborarea produselor program n care este implicat ingineria programrii. Cteva dintre aceste aspecte vor fi discutate n continuare. Un aspect des ntlnit n activitatea de elaborare a produselor program este participarea colectivelor de programatori (uneori foarte numeroase) la elaborarea unui produs. Este evident faptul c n astfel de colective nu se va folosi dect foarte rar un singur limbaj de programare. Utilizarea mai multor limbaje de programare poate fi impus pe de o parte de diferite particulariti ale produsului elaborat, iar pe de alt parte de preferinele sau performanele programatorilor. Utilizarea limbajelor de programare diferite impune stabilirea unor regului care s permit asamblarea prilor componente ntr-un tot unitar. De asemenea aceste reguli trebuie s permit programatorilor s neleag i s utilizeze n condiii ct mai bune componente ale 6

programului elaborate de ctre alte persoane, indiferent de limbajul de programare folosit. Un alt aspect pentru care ingineria programrii ofer soluii de cretere a eficienei este cel al documentrii programului. Documentarea programului trebuie fcut corect att pe durata elaborrii acestuia ct i n scopul exploatrii i ntreinerii. Acest aspect, adesea neglijat poate fi hotrtor n ceea ce privete calitatea produsului obinut. n sfrit, pentru a nu aminti dect doar cteva aspecte legate de domeniile ingineriei programrii trebuie spus c cercetrile cu privire la fiabilitatea, sigurana n funcionare i posibilitatea rezolvrii automate a eventualelor erori aprute, reprezint o alt direcie de mare interes al acestui domeniu. Atingerea obiectivelor ingineriei programrii implic desfurarea activitii de programare n conformitate cu un set integrat de principii cu valabilitate general: a) modularizarea problemelor/sistemelor complexe prin descompunere n module pe baza unicitii funciilor de prelucrare, datelor i fluxurilor prelucrrilor; b) abstractizare prin identificarea proprietilor generale, comune unor entiti diferite, ignornd temporar diferenele dintre acestea; c) ncapsularea (acoperirea sau ascunderea) elementelor neeseniale de implementare tehnic, la nivelurile inferioare, pentru a reliefa numai elementele abstracte eseniale necesare unui modul de modularizare; d) localizare prin gruparea elementelor corespunztoare unei funcii de prelucrare; e) uniformizarea modului de exprimare a descrierii problemelor (notaie liber dar uniform!); f) completitudine prin includerea tuturor elementelor constitutive (date i operaii) fr omisiuni; g) confirmabilitatea realizrii cerinelor specificaiilor conform necesitilor (explicit formulate) de verificare a proiectului i produsului. Acestor principii generale de inginerie li se altur o serie ntreg de reguli, procedee, soluii, norme i standarde incluse n diferite metode, strategii i tehnici specifice anumitor faze ale procesului de elaborare: programarea structurat, strategii de parcurgere a fluxului etapelor ciclului de via, etc. Activitatea de elaborare a produsului program ncepe n momentul n care exist o problem de rezolvat bine definit. Acest lucru este concretizat de obicei prin tema de proiectare. Etapa elaborrii temei de proiectare influeneaz n mod esenial rezultatul final. De regul definirea problemei de rezolvat i elaborarea temei de proiectare trebuie fcut prin colaborarea ntre beneficiar i proiectant n aa fel nct cerinele beneficiarului i rezultatele ateptate s fie limpede precizate. De asemenea, proiectantul poate ghida beneficiarul n stabilirea datelor de intrare ce vor fi furnizate n aa fel nct obiectivele proiectului s fie atinse. De multe ori datele iniiale furnizate pentru proiect sunt greite sau inutile iar stabilirea judicioas a acestora poate elimina o mare cantitate de timp cheltuit inutil. n general, pentru programarea unei probleme, trebuie s fie parcurse urmtoarele etape: definiia problemei; selecia algoritmilor i a structurilor de date; specificarea structurii i a logicii programelor; 7

codificarea; depanarea i testarea; redefinirea pailor anteriori; documentarea; ntreinerea programului.

Aa cum s-a artat, primul pas care trebuie fcut n elaborarea produsului program este definiia problemei. O problem greit definit va duce la un program care n cel mai bun caz nu va corespunde ateptrilor. Din acest motiv este necesar ca n etapa de definire a problemei s se fac apel la specialiti n domeniile corespunztoare problemei de rezolvat n aa fel nct toate aspectele de rezolvat s fie clar definite. n aceast faz, dac este necesar, trebuie s se fac apel i la specialiti din alte domenii ale informaticii cum ar fi: analiti de sistem, specialiti n analiza i proiectarea sistemelor de operare, specialiti n reele de calculatoare, specialiti n criptarea i securizarea datelor, etc. Pentru a combate tendina multor programatori de a porni la ntocmirea programelor fr o nelegere clar a problemei, se recomand ca pentru nceput realizarea unei documentaii care s conin: un enun clar, ct mai precis, al problemei; specificaii asupra datelor de intrare i de ieire. Dup clarificarea problemei de rezolvat urmeaz stabilirea algoritmilor folosii. O dat algoritmii ce vor fi folosii sunt adoptai este bine s se fac o descriere detaliat a acestora (de obicei n limbaj matematic) i a structurilor de date ce vor fi folosite. Urmtoarea etap const n stabilirea structurii modulare a programului i a logicii sale detaliate (proiectarea programului). Prin tehnici speciale (top-down sau bottom-up) programul este descompus n uniti de program, module. Un modul prezint trei caracteristici de baz: funciunea, logica i interfeele. Funciunea modulului este o descriere a transformrilor datelor de intrare ale modulului (input) pentru obinerea datelor de ieire ale modulului (output). Intrrile i ieirile reprezint interfeele modulului legturile sale cu celelalte module ale programului. Ideea care st la baza descompunerii programului n module este n fond strategia divide et impera: o problem complex se rezolv prin descompunere n subprobleme mai simple ce pot fi mai uor rezolvate. Dup ce structura modular, ce exprim structura funcional a programului a fost stabilit, se trece la stabilirea logicii detaliate a fiecrui modul i a programului ca ntreg. Logica detaliat a fiecrui modul i a programului ca ntreg se poate descrie cu ajutorul unui limbaj special invetat cu ocazia cercetrilor de programare structurat, limbaj numit pseudocod, sau, intuitiv, cu ajutorul schemelor logice. n procesul de proiectare a unui program, programatorul trebuie s prevad i mijloacele de depanare a fiecrui modul n parte i a programului ca ntreg. Dup ce structura i logica programului au fost stabilite urmeaz etapa codificrii programului ntr-un limbaj de programare. Aceast etap reprezint de fapt activitatea de scriere a programului. Din pcate, foarte muli programatori, consider aceast etap ca etapa cea mai important a elaborrii programului i acord a atenie special numai acesteia. Dei activitatea de scriere a programului este caracterizat de accentuate elemente de creativitate i ea influeneaz ntr-o mare msur calitatea produsului obinut, nu trebuie uitat aspectul practic al activitii de elaborare a 8

produsului program care impune abordarea problemei dintr-un punct de vedere ct mai puin subiectiv. Urmtoarea etap este reprezentat de testarea i depanarea fiecrui modul n parte. Urmeaz integrarea modulelor ntr-un sistem: verificarea programului ca un ntreg alctuit dintr-o mulime de module. Sursa cea mai probabil de erori la integrare (erori logice) apare n aria de comunicaie ntre modulele de program. n aceast situaie programul se reproiecteaz i ntreg procesul se reia de la nceput (redefinirea pailor anteriori) pn ce se obin rezultate satisfctoare pentru datele de control (testare experimental). Metodologia de depanare i testare descris mai sus este n fond metodologia tradiional furnizat de tehnica bottom-up: nti se realizeaz componentele programului (detaliile, partea de jos) apoi aceasta se integreaz, se mbin ntr-un sistem (ntregul partea de sus). Metodologia bottom-up reprezint dezavantajul c o eroare depistat la integrarea modulelor face ca ntreg procesul de proiectare, depanare i testare se reia de la nceput. Tehnica top-down este de dat mai recent, bazat pe cercetrile de programare structurat, preconizeaz o ntreptrundere a etapelor de proiectare, depanare i testare astfel nct erorile de integrare a modulelor s fie minime. n plus, tehnica top-down preconizeaz mijloace de documentare eficient a programelor, de exemplu, sistemul HIPO preconizat de firma IBM (HIPO este un acronim de la cuvintele Hierarchy plus Input Process Output), ceea ce nseamn ierarhie plus intrare, prelucrare, ieire. Sistemul de documentare HIPO conduce la un pachet HIPO ce descrie funciile programului; pachetul HIPO const din tabela vizual a coninuturilor, diagrame de ansamblu i diagrame de detalii. Dup ce programul a fost proiectat, depanat i testat el trebuie nsoit de o documentaie tehnic i operaional. Aceast documentaie trebuie s conin urmtoarele: enunul problemei; descrierea algoritmilor i a structurilor de date; descrierea structurii funcionale (pachet HIPO) i a logicii (textul n pseudocod, schemele logice); o list a programului codificat (programul surs); o descriere definitiv a mijloacelor de testare i verificare care s conin o list cu datele folosite la testare i rezultatele care se obin la rulare; instruciuni de operare, incluznd structura pachetului cu date, formate I/O, mesaje de eroare, etc. Fr o documentare bine pus la punct programul nu este utilizabil. Programele n general sunt concepute s fie utilizate i de alii; dac documentaia este srac programul nu poate fi utilizat n forma existent sau nu i se pot aduce modificri de ctre ali programatori. Mai mult, cei care lucreaz n domeniul programrii au tendina (fireasc) de a uita ceea ce au fcut i asta n foarte scurt timp, astfel c un programator care revine peste cteva luni la un program scris de el are impresia c l vede pentru prima oar n viaa sa; fr o documentare adecvat el nu-l poate utiliza i este pus n situaia de a munci din nou pentru alctuirea aceluiai program. Seturile specifice de documentaie de lucru, intermediar i final - utilizate frecvent n elaborarea produselor software sunt prezentate succint n continuare.

Documentaia de proiectare include: a) tema de realizare care conine definirea cerinelor, performanelor i condiiilor impuse produsului; b) proiectul de ansamblu pentru sisteme mari i foarte mari; c) specificaii de definire sau proiectul logic detaliat. Documentaia intermediar servete pentru reprezentarea produsului n etapele de proiectare i pentru comunicarea ntre echipa de realizare i ali specialiti. Documentaia de lucru asigur comunicarea n cadrul echipei de realizare. Documentaia de realizare i ntreinere include: a) specificaia de realizare numit i proiect tehnic detaliat, format din documentaia de programare (schem bloc, structur, funcii, schem logic, text surs, interfee i mesaje) precum i specificarea procedurilor i fiierelor; b) coninutul bibliotecilor; c) procedurile de testare; d) indicaii de ntreinere. Documentaia final de utilizare curent este format din: a) manual de prezentare tehnico-comercial a posibilitilor/funciilor produsului; b) manual de utilizare n care se descriu amnunit domeniul de aplicare, intrrile i ieirile, organizarea datelor, procedurile automate i se prezint performanele; c) manual de exploatare n care se descriu resursele necesare, pregtirea produsului pentru utilizare, procedurile de exploatare i criterii de apreciere a funcionrii normale. Multe programe nu sunt gata chiar cnd aparent au fost depanate. n general exist cteva erori care se descoper de un anumit utilizator n anumite circumstane neobinuite. De aceea este de dorit ca programatorul s fac coreciile necesare i s se ocupe de o ntreinere a programului - corectare permanent - n funcie de erorile semnalate. O dat cu dezvoltarea reelei Internet, firmele productoare de soft au dezvoltat o nou strategie de testare a programelor. Reeaua Internet asigur acces simplu, sigur i rapid n orice loc de pe glob. Din acest motiv transferarea programelor de pe calculatorul firmei productoare pe calculatorul propriu se face extrem de simplu i ieftin. Din acest motiv, firma productoare pune gratuit la dispoziia utilizatorilor versiunea neterminat a unui nou program (aceast versiune numindu-se adesea versiunea beta a unui program). Aceast versiune conine o serie de erori care nu au fost depistate la testrile de rutin sau din ea pot lipsi anumite faciliti necesare utilizatorului final. Fiind vorba de un program gratuit, cei interesai pot s-l foloseasc un timp definit sau pe o durat nelimitat. Ideea de baz a acestei aciuni este c foarte muli utilizatori care vor dori s cumpere versiunea final a programului vor semnala firmei productoare eventualele erori pe care le depisteaz n program sau facilitile suplimentare pe care le ateapt de la programul respectiv. De multe ori chiar utilizatorii sugereaz ci de corectare a erorilor. Acest sistem facilitat n principal de extinderea i perfecionarea reelei Internet are marele avantaj c testarea devine mai complet i mai puin costisitoare pentru firma productoare iar programul final se va apropia foarte mult de necesitile utilizatorilor. 10

CAPITOLUL 2 NOIUNI FUNDAMENTALE DE PROGRAMARE

2.1. Elemente de programare
Orice limbaj de programare, este un set de reprezentri, convenii i reguli pentru a descrie datele de prelucrat i procesele de prelucrare. Entitile la care se refer limbajele de programare se numesc obiecte. Fiecrui obiect i se asociaz o notaie i o valoare. ntr-un algoritm, asupra obiectelor se efectueaz anumite operaii; n urma operaiilor obiectele i schimb valoarea obinndu-se rezultate. Nu toate obiectele se bucur de proprietatea de a putea participa ca operanzi la toate operaiile posibile. Mulimea obiectelor pentru care s-a definit un anumit set de operaii poart numele de mulimea obiectelor de acelai tip. Astfel, tipul obiectelor este determinat de operaiile ce se pot efectua cu ele. Mai des ntlnim trei clase de obiecte: obiecte numerice, obiecte logice i obiecte nenumerice (literale). Obiectele numerice sunt de tip ntreg, real sau complex; cu ele se pot ndeplini binecunoscutele operaii aritmetice. Obiectele de tip logic pot avea valoarea adevrat sau fals; ele particip la operaiile logice. Obiectele de tip caracter (char) descriu obiecte ce reprezint caractere separate: litere, cifre, semne speciale. Obiectele de tip ir (string) descriu obiecte ce reprezint cuvinte sau propoziii. Pentru obiectele prezentate mai sus se folosete o notaie standard sau o imagine. Notaiile standard sau imaginile sunt n general cele utilizate n limbajele de programare. De exemplu: 100, -2, 25, -32, pentru numere de tip ntreg, 2i+6 pentru numere complexe, etc. Obiectele de tip ntreg, real, logic i caracter sunt exemple de obiecte simple, primitive. Obiectele de tip complex sau ir sunt exemple de obiecte compuse sau structurate, primele fiind alctuite din perechi de obiecte reale, iar celelalte find alctuite dintr-o succesiune de obiecte de tip caracter. n programare se ntlnesc mai multe obiecte compuse, structurate, uneori cu o structur foarte complicat n special n cazul prelucrrii informaiei nenumerice. Exist o teorie general a metodelor de obinere a datelor structurate (K. Hoare). Pentru anumite obiecte, n afar de notaia standard (imagine) este util s folosim alte notaii mai simple. n programare pentru notarea nonstandard a diferitelor obiecte se folosesc nume simbolice. Un obiect simplu de tip ntreg, real, sau logic notat cu un nume simbolic se numete variabil. Descrierea unei operaii ntr-un limbaj de programare se numete instruciune. Astfel, algoritmul poate fi privit ca fiind alctuit dintr-un ir bine precizat de instruciuni. Cele mai simple instruciuni ale unui algoritm ce poate fi descris ntr-un limbaj de programare sunt: instruciuni de citire. De exemplu: Read x instruciuni de scriere: Write x, Write a,b,c instruciuni de atribuire: a <- 2, i <- i+2 11 sau: Read a,b,c

O expresie logic poate fi alctuit din elemente logice legate ntre ele prin operatori logici. ntr-o expresie logic pot intra ca elemente i expresii de relaie: <, <=, =, <>, >=, >. Rezultatul unei expresii de relaie poate fi valoarea logic true sau false. O variabil se poate defini fie prin operaia de citire, fie prin operaia de atribuire; operaiile aritmetice i de scriere au sens doar pentru variabile ce au fost definite anterior.

2.2. Algoritmi
Prin algoritm se nelege metoda de rezolvare a unei probleme ntr-un numr finit de pai. Orice algoritm trebuie s aib urmtoarele proprieti: s fie finit. Orice algoritm trebuie s se termine dup un numr finit de pai. Proprietatea se mai numete realizabilitate potenial; s fie definit. Fiecare pas al algoritmului trebuie s fie precis definit; intrare. Orice algoritm are zero, una sau mai multe intrri, adic mrimi care trebuie date iniial nainte ca algoritmul s nceap; ieire. Orice algoritm trebuie s aib una sau mai multe ieiri, adic mrimi ce au o anumit relaie specific cu intrrile; eficacitate. Orice algoritm trebuie s fie eficace. Aceasta nseamn c algoritmul trebuie s permit efectuarea sarcinilor impuse n condiii optime; s aib caracter de mas. Algoritmul trebuie s permit rezolvarea oricrei probleme dintr-o anumit clas de probleme.

Programarea este o tehnic de construire a algoritmilor i de descriere a acestora n limbajele de programare.

2.3. Elemente de programare structurat. Pseudocodul.

Ideea fundamental a programrii structurate este aceea de a proiecta de la bun nceput programul n aa fel nct aesta s prezinte o structur bine determinat, simpl i clar adecvat unei analize eficiente a corectitudinii programului (verificarea sa logic). Potrivit teoremei de structur orice program executabil pe o main serial (uniprocesor) este echivalent cu un program ce conine numai structuri simple i trei structuri compuse: secven, iteraie i selecie. O structur simpl este alctuit din instruciuni simple de citire, atribuire, scriere; structurile compuse sunt numite de unii autori instruciuni compuse. Modul cel mai simplu de a descrie un program ca o succesiune de secvene, iteraii i selecii se realizeaz cu aa-numitul pseudocod. Pseudocodul sau, cum i se mai spune, logica schematic, este un limbaj cu reguli sintactice foarte simple ce permite programatorului s exprime n mod neambiguu ordinea de execuie a operaiilor unui program, cu alte cuvinte logica sa detaliat. 12

Descriem n cele ce urmeaz regulile sintactice ale pseudocodului, modul de scriere a structurilor compuse i semnificaia lor. Pentru a marca nceputul unei iteraii, secvene sau selecii se folosesc cuvintele de structur seq, iter i select iar pentru a marca sfritul acestor instruciuni se folosete cuvntul end. Uneori n locul cuvintelor seq, iter i select se scrie cuvntul begin. Astfel cu una din perechile de cuvinte de structur (seq, end), (iter, end), (select, end), (begin, end) se marcheaz instruciunile compuse ale unui program. Din acest motiv acestea se mai numesc paranteze de instruciuni. Cnd nu folosim paranteze de instruciuni se utilizeaz operatorul de urmare ; (punct i virgul) care nseamn c instruciunea care urmeaz se va executa doar atunci cnd s-a terminat execuia instruciunii precedente. Pentru a exprima ordinea de execuie n interiorul instruciunilor compuse se folosesc cuvintele if (dac), then (atunci), else (altfel), procedure (procedur) ct i unele notaii i propoziii alese de ctre programator pentru a-i exprima ct mai precis ideile. Alte reguli de sintax ale pseudocodului le vom introduce n text n mod treptat unde va fi nevoie. Secvena este o structur care prezint dou sau mai multe pri ce se execut fiecare cte o singur dat. De pild, o secven n care prile componente sunt instruciuni elementare se scrie cu ajutorul pseudocodului astfel: seq Read x,y; s <- x+y; Write s; end Aceast instruciune este alctuit din trei pri cele trei instruciuni elementare ce se execut una dup alta. n cazul n care o parte a unei instruciuni compuse este o structur compus se procedeaz astfel: a) se scrie cuvntul do urmat de numele componentei ca n exemplul de mai jos: seq s <- s+x; do B; Write s; end Aici B poate fi o structur compus, de exemplu o alt secven, o iteraie sau o selecie. b) se scrie direct n text partea compus n mod detaliat. De exemplu, dac B ar fi selecia: seq Read z; do C; y <-y+z; 13

end atunci secvena precedent se va putea scrie: seq s <- s+x; seq Read z; do C; y <-y+z; end Write s; end Dac secvenele respective le numim A i B, am putea s le scriem i astfel: A seq s <- s+x; B seq Read z; do C; y <-y+z; B end Write s; A end sau: begin A s <- s+x; begin B Read z; do C; y <-y+z; end B Write s; end A Modul acesta de scriere cu spaii goale n stnga (indentare) astfel ca relaiile logice dintre diferite pri ale programului s ias n eviden este o regul de baz a pseudocodului. Iteraia este o structur compus care conine o parte iterat ce se execut de zero, unu sau de mai multe ori n funcie de rezultatul unui test logic. Forma de baz a unei iteraii se poate scrie cu ajutorul pseudocodului n una din urmtoarele forme: iter while L do A; end 14 end begin while L do A;

Modul de execuie al unei iteraii este urmtorul: se calculeaz valoarea expresiei logice L; dac rezultatul este true se execut partea iterat A; se calculeaz din nou valoarea expresiei logice L; dac rezultatul este true se execut din nou partea iterat A; procedeul continu n acest fel pn cnd expresia logic L capt valoarea false; atunci partea iterat A nu se mai execut i iteraia ia sfrit.

Pentru ca iteraia s se termine ntr-un numr finit de pai (i aa trebuie, cci un program are ntotdeauna un numr finit de pai), este necesar ca partea iterat A s modifice valoarea unei variabile sau a mai multor variabile ce apar i n expresia logic L, astfel c dup un numr finit de ori expresia L s capete valoarea false. Testul while L se verific ntotdeauna nainte de execuia prii iterate, este un test la nceputul iteraiei. Se poate ntmpla ca n funcie de rezultatul expresiei L partea iterat s nu se execute niciodat (s se execute de zero ori). Astfel o iteraie const dintr-un numr maxim de execuii a prii iterate; valoarea true pentru expresia logic L este condiia necesar i suficient pentru terminarea iteraiei. Mai exist o form posibil a iteraiei n care testul apare la sfritul iteraiei. Este vorba de iteraii de forma: iter repeat A until L; end Acest tip de iteraie se execut astfel: se execut partea iterat A; se calculeaz expresia logic L; dac rezultatul este true se execut din nou partea iterat A; se calculeaz expresia logic L; procedeul continu pn cnd expresia logic L capt valoarea false; atunci partea iterat nu se mai execut. end begin repeat A until L;

Trebuie remarcat faptul c iteraia de tipul while L do A este esenial diferit de iteraia de tipul repeat A until L. Din cauza modului de testare a condiiei, la iteraia repeat A until L partea iterat se execut cel puin o dat pe cnd la iteraia while L do A exist situaia cnd partea iterat nu se execut deloc. Partea iterat poate fi o instruciune simpl, o secven, o selecie sau o alt iteraie ca n exemplele urmtoare: iter while i>=n do seq x -> x+i i -> i+1 end end 15 N end N iter while L1 do M iter while L2 do A; M end

Selecia este o structur care conine mai multe pri dintre care una i numai una se execut o singur dat n funcie de rezultatul unui test logic. Forma cea mai simpl de selecie este cea cu dou pri: select if B then A else B end Execuia se face astfel: se calculeaz expresia logic L; dac rezultatul este true se execut partea A i selecia ia sfrit; dac rezultatul este false se execut partea B i selecia ia sfrit.

Partea B poate lipsi (echivalent cu do nothing nu executa nimic) i structura devine: select if B then A end Execuia acestei selecii se face astfel: se calculeaz expresia logic L; dac rezultatul este true se execut partea A i selecia ia sfrit; dac rezultatul este false selecia ia sfrit.

Selecia cu mai multe pri se poate scrie astfel: select condiia1 do S1; or condiia2 do S2; or condiia3 do S3; end Modul de execuie este urmtorul: se verific condiia logic 1, dac valoarea este true se execut S1 i selecia ia sfrit; n caz contrar: se verific condiia logic 2; dac valoarea este true se execut S2 i selecia ia sfrit; n caz contrar: se verific condiia logic 3; dac valoarea este true se execut S3 i selecia ia sfrit; n caz contrar selecia ia sfrit. n literatur selecia cu mai mult de dou componente se mai numete i case-of (variant din), terminologie introdus de Hoare. Folosind acest termen selecia de mai sus se poate scrie n pseudocod prescurtat astfel: case i of (S1, S2, S3) 16

n pseudocod, comentariile care se includ pentru explicarea aciunilor realizate de program se pun ntre paranteze acolad {, }.

2.4. Scheme logice program

Reprezentarea grafic bidimensional a unui algoritm cu ajutorul unor simboluri speciale poart numele de schem logic program sau simplu schem logic (organigram). Pentru a desena schema logic se folosesc simboluri speciale standard ce arat tipul diferitelor operaii (instruciuni) ale algoritmului i succesiunea ndeplinirii lor. Acesta nseamn c o schem logic reprezint de fapt, n acelai timp o imagine a fluxului de informaie n calculator cnd calculatorul execut programul bazat pe algoritmul respectiv, adic reprezint n mod simbolic datele, modul de prelucrare a lor ct i echipamentele unde se efectueaz prelucrarea. Schemele logice au fost inventate de Herman Goldstine (SUA) n 1946. Alctuirea schemei logice permite ca utilizatorul: s neleag logica programului; s despice un program n pri mai mici i mai detaliate (modularizare); s verifice ndeplinirea tuturor condiiilor posibile din program; s codifice algoritmul ntr-un limbaj de programare; s comunice cu ali utilizatori; s alctuiasc documentarea programului. n general utilizarea pseudocodului sau a schemelor logice este echivalent. Nu este necesar ntotdeauna ca n documentaia elaborat s fie utilizate ambele metode de reprezentare dar n situaia unor algoritmi complicai utilizarea pseudocodului i a schemelor logice aduce un plus de claritate. Existena unor programe specializate pentru ntocmirea documentaiei produsului program simplific mult activitatea programatorului iar utilizarea acestora duce la creterea productivitii i la scderea erorilor iniiale de proiectare. Un astfel de program va fi prezentat n ultima parte a acestei lucrri. De asemenea, extinderea programrii n timp real n medii multitasking a impus utilizarea unor concepte i simboluri noi. Deosebirile fa de schemele logice clasice prezentate n acest capitol vor fi artate n ultima parte a lucrrii odat cu prezentarea programelor specializate destinate ingineriei programrii. Principalele simboluri grafice utilizate n schemele logice sunt:
BLOC DE INTRARE/ IEIRE

BLOC DE PRELUCRARE

BLOC DE DECIZIE

START

SUBPROGRAM

TERMINATOR
CONECTOR

CONECTOR DE SFARIT DE PAGIN

17

Prezentm n continuare cteva scheme logice tipice: a) schema logic a unei secvene

Instruciune 1 Instruciune 2 . . .

Instruciune 1

b) schema logic a unei iteraii

Secven NU
Condiie ?

NU DA Secven DA
Condiie ?

Iteraie de tip WHILE-DO

Iteraie de tip REPEATUNTIL

18

c) schema logic a unei selecii

DA
Condiie ?

NU
Condiie ?

NU

Secven 1

Secven 2

DA Secven

Selecie de tip IF-THEN-ELSE

Selecie de tip IF-THEN

Expresia seleciei

Secven 1

Secven 2

.....

Secven n

Selecie de tip CASE

2.5. Proiectarea programelor. Tehnicile top-down i bottom-up

Proiectarea programului const n stabilirea structurii modulare a programului ct i a logicii sale detaliate. 2.5.1. Tehnica top-down Proiectarea unui program const n fond n urmtoarele: dispunem de o problem i de un calculator digital capabil de a executa un ir limitat de instruciuni ntr-un limbaj de nivel nalt. Sarcina programatorului este aceea de a scrie programul, un text ce reprezint o succesiune logic de instruciuni ntr-un limbaj de nivel nalt, care la execuie ndeplinesc o funciune, misiunea programului, adic transformrile pe care le produce programul asupra datelor de intrare (input) pentru a produce rezultate (output). n legtur cu un program distingem astfel o funciune, ce caracterizeaz ceea ce trebuie s fac un program, misiunea sa i o logic ceea ce arat cum trebuie s acioneze maina, calculatorul, pentru ndeplinirea funciunii respective. Dac 19

funciunea programului este simpl, cu tehnicile descrise anterior ea poate fi scris relativ simplu n pseudocod obinndu-se un program ce conine un singur modul, programul principal. Programele necesare rezolvrii unor programe practice de obicei conin sute, mii, chiar zeci de mii de instruciuni, astfel nct funciunea unui astfel de program este foarte complicat i nu poate fi neleas clar i complet de un om, nici nu poate fi memorat. Pentru a rezolva astfel de probleme complexe de programare este necesar s se adopte o tactic n aa fel nct programatorul s se poat concentra la un moment dat doar asupra unei pri mai mici de program pe care o nelege perfect. Tactica adoptat n practic, este aa-numita structurare ierarhic, o descompunere, disecare a programului n module. Structura ierarhic este descris n continuare. Avem de proiectat un program P care la execuie pe calculator realizeaz funciunea F. Descompunem funciunea, sarcina F ntr-o serie de subsarcini, de pild F1, F2, F3 cu condiia ca funciunea F s fie complet ndeplinit prin ndeplinirea funciunilor F1, F2, F3. Corespunztor obinem trei module de program procedurile P1, P2, P3 a cror funciuni sunt F1, F2 respectiv F3: la execuia procedurii P1 se nseplinete funciunea F1 i aa mai departe. Am disecat astfel programul P i am obinut patru module P1, P2, P3 i P. Modulul P (programul principal) este absolut necesar, cci el descrie relaiile ntre P1, P2 i P3 (interfeele). Reprezentnd grafic aceast disecie obinem urmtoarea diagram:

P1

P2

P3

n continuare ne vom concentra atenia separat asupra fiecruia dintre modulele P1, P2, P3. De exemplu, analizm P1. Dac funciunea F1 este suficient de simpl, modulul P1 l putem codifica direct n pseudocod, dac nu, disecm P1, de exemplu, n dou alte module P11 i P12 cu funciunile F11 i F12. Similar procedm cu P2 i P3 i final obinem o structur de tipul celei artate mai jos. P

P1

P2

P3

P11

P12

P31

P32

P33

20

n aceast structur, care n teoria grafurilor se numete structur de arbore, punctul P reprezint rdcina arborelui iar celelalte blocuri reprezint nodurile structurii. Proprietatea de arbore este aceea c de la rdcin la un nod oarecare exist un singur drum. n acest mod de structurare ierarhic pornim de sus (problema n toat generalitatea ei) i ajungem jos la detalii. De aici provine i denumirea top-down (sus-jos). Nivelul ierarhic cel mai ridicat l posed P, apoi P1, P2, P3, dup aceasta P11, P12, P31, P32, P33. Pentru a realiza n mod sistematic proiectarea modular a programului se recomand urmtoarea tehnic de descompunere, bazat pe o analiz amnunit a structurii problemei, a fluxului datelor i a transformrilor pe care acestea le sufer: selectai o structur funcional a problemei care s conin cteva procese de prelucrare principal (3-10); n aceast structur identificai fluxul principal de date de intrare i fluxul principal de date de ieire; localizai n structura problemei punctul n care fluxul datelor de intrare dispare i punctul n care fluxul datelor de ieire apare prima oar. Aceste dou puncte disec problema n trei pri. Descriei aceste trei pri prin trei funciuni i definii o procedur (modul) pentru fiecare n parte. Aceste trei proceduri sunt subordonate programului principal; luai pe rnd fiecare din aceste module, considerai funcia fiecruia ca pe o subfuncie i repetai procedeul; descompunerea continu pn cnd ntreaga problem se descompune n module de aproximativ 50 de instruciuni.

Cu aceast tehnic de descompunere, evident, putem obine structuri diferite, cu alte cuvinte descompunerea n module nu este univoc. Se pune n mod natural ntrebarea, dac sunt posibile mai multe structuri, pe care din ele o alegem, o preferm. Programarea structurat recomand alegerea acelor structuri ierarhice modulare care sunt caracterizate de aa-numita independen modular. Vom considera c un program prezint independen modular dac: fiecare modul este ct mai robust; cuplajul ntre module este ct mai slab.

Robusteea (potena) unui modul este o msur a relaiilor din interiorul modulului. Deosebim mai multe forme de robustee, care n ordine cresctoare, de la forma cea mai puin robust la cea mai robust, sunt: robustee ntmpltoare (normal) modul n care exist relaii fr sens ntre elementele sale; robustee logic - modul care de fiecare dat cnd este apelat execut o funcie bine precizat dintr-o mulime de funcii logice legate ntre ele; robustee clasic - modul care execut dou sau mai multe funcii, funciile fiind legate ntre ele ca proceduri (o procedur apeleaz o alt procedur); robustee funcional - modul care execut o singur funciune. 21

Cuplajul dintre module este o msur a relaiilor dintre module. i aici deosebim mai multe forme de cuplaj care, n ordine de la cel mai ru (cuplaj tare) la cel mai bun (cuplaj slab), sunt: cuplaj al coninutului dou module sunt cuplate n coninut dac unul dintre ele se refer n mod direct la coninutul celuilalt; cuplaj extern un grup de module sunt cuplate n mod extern dac n ele exist referine la unele date globale, de exemplu blocuri organizate n comun; cuplaj decizional dou module sunt cuplate decizional dac unul din ele controleaz n mod explicit funciile celuilalt; cuplaj prin date dou module sunt cuplate prin date dac unul l apeleaz pe cellalt i toate intrrile i ieirile sunt sub form de parametri ai procedurilor.

Dac dou module prezint mai multe forme de cuplaj, cuplajul lor este definit de forma cea mai rea de cuplaj. Se recomand evitarea organizrii unor proceduri cu date n comun. Blocurile de comun se vor organiza numai n cazurile n care este necesar o optimizare a alocrii memoriei, de pild n cazul n care programul nu ncape n memorie. Din cele expuse mai sus rezult c n proiectarea modular strategia cea mai bun a programatorului este aceea de a maximiza legturile n interiorul fiecrui modul i de a minimiza legturile ntre module realiznd cuplaje ct mai slabe. Pentru a conferi independen modular programului, programatorul trebuie s in cont i de urmtoarele: dimensiunea modulului. Dimensiunea modulului confer claritate i inteligibilitate programului; de dimensiunea modulului depinde i uurina testrii; previzibilitatea modulului. Toate modulele trebuie s fie previzibile: la apeluri repetate ale aceluiai modul s se obin acelai rezultat cnd datele de intrare sunt identice. Cu alte cuvinte modulul nu trebuie s aib o memorie a execuiilor anterioare; structura decizional. Organizarea funcional trebuie alctuit n aa fel nct modulele ce sunt direct afectate de o decizie s fie subordonate modulului ce conine decizia; acces minim de date. Datele furnizate unui modul s fie limitate exact la minimul necesar pentru a-i ndeplini funciunea.

O dat ce structura modular a programului a fost stabilit urmeaz stabilirea logicii fiecrui modul, codificarea i testarea. Tehnica top-down preconizeaz o metodologie ce prezint urmtoarea cronologie special (succesiune n timp a etapelor de proiectare, testare, depanare). Mai nti, se specific logica detaliat a programului cu ierarhia cea mai indicat, rdcina arborelui. Aceasta se codific i se testeaz pe calculator. Evident, pentru testare este nevoie i de uniti cu nivel ierarhic mai cobort ce sunt apelate de programul principal. Acestea nu se codific detaliat, pentru ele se folosete un cod fictiv, aa-numitele programe talon: taloanele nu efectueaz calcule, ele servesc doar la depanare, de pild, de cte ori sunt apelate ele emit un mesaj cu valorile 22

parametrilor de intrare. De exemplu, dac ne referim la programul P cu structura din figura prezentat mai sus, procedm astfel: stabilim logica lui P, codificm P; unitatea de program obinut conine apeluri ale procedurilor P1, P2, P3, de exemplu de forma: call P1(x1,x2,x3) call P2(y1,y2,y3) call P3(z1,z2,z3,z4,z5) Taloanele le construim astfel: procedure P1(a1,a2,a3) begin Write a1,a2; end procedure P2(b1,b2,b3) begin Write b1; end procedure P3(c1,c2,c3,c4,c5) begin Write c1,c2; end Programul se corecteaz pn ce la rulare integrarea modulelor se face corect. Urmeaz detalierea logicii i codificarea modulelor cu nivel ierarhic mai cobort P1, P2 i P3 folosind taloanele pentru procedurile P31, P32, P33, P11, P12. Metodologia preconizat de tehnica top-down prezint astfel o serie de avantaje: unitile de program pentru fiecare nivel ierarhic sunt complet testate i integrate cu unitile de program precedente (cu nivel ierarhic mai ridicat) nainte de a codifica nivelul ierarhic mai de jos; uurina de a produce modificri n cod: majoritatea modificrilor ntr-un program apar n partea de jos. Cum partea de jos este ultima codificat i testat modificrile nu vor afecta structura modular.

2.5.2. Tehnica bottom-up Ideea ce st la baza acestei tehnici este urmtoarea: dispunem de o problem i de un calculator digital capabil de a executa un ir limitat de instruciuni. Instruciunile ce ni le furnizeaz limbajul sunt prea simple; atunci vom combina aceste instruciuni elementare pentru a alctui module cu anumite funciuni, astfel nct o combinaie a acestora s rezolve problema. Rezultatul este tot o structur modular de tip arbore, numai c procesul ncepe de jos pn ce ajungem sus la P. Pentru fiecare modul se stabilete logica, se codific i testeaz. Pentru testare se proiecteaz programe principale separate, programe driver (de antrenare) cu care se testeaz fiecare modul. Dup ce fiecare modul a fost testat urmeaz integrarea lor ntr-un program, rularea ntregului program cu date test. Cum deja am menionat, erorile cele mai probabile apar la integrare, n aria de comunicaie ntre module. Aceste erori evident nu mai apar dac folosim tehnica top-down. 23

CAPITOLUL 3 REGULI PENTRU SCRIEREA CODULUI PROGRAM

3.1. Generaliti
Scopul acestui capitol este cel de a reprezenta un ghid pentru realizarea codului surs de calitate. Regulile i indicaiile prezentate aici sunt utile oricrei persoane care dorete s creeze, s modifice sau s citeasc programe n cod surs. De multe ori firmele implicate n elaborarea produselor program impun un anumit limbaj de programare. Astfel, multe case productoare de soft utilizeaz un singur limbaj de programare. O corporaie, de exemplu, poate angaja numai programatori COBOL i poate impune ca toate programele, indiferent de natura lor, s fie scrise n COBOL. Evident c exist i situaii cnd firmele productoare de soft aplic alte strategii n ceea ce privete limbajele de programare utilizate. Folosirea mai multor limbaje de programare va permite inginerilor o anumit flexibilitate n alegerea uneltelor potrivite pentru ndeplinirea sarcinilor. n acelai timp, aceti ingineri trebuie s fie capabili s lucreze cu cod scris anterior n diferite limbaje de programare. O astfel de flexibilitate, fr o coordonare centralizat, poate duce la haos. Acest lucru este adevrat n special cnd se utilizeaz limbaje ce permit o dezvoltare rapid a aplicaiilor cum sunt Visual BASIC, Powerbuilder i Delphi. Acest capitol furnizeaz principalele direcii pentru dezvoltarea de programe n aa fel nct o persoan care elaboreaz programe s poat citi uor proiectul altcuiva fr a avea probleme de adaptare la un nou program. Trebuie menionat faptul c aceste direcii nu sunt nici restrictive nici limitative, existnd posibilitatea ca acestea s fie adaptate unor condiii particulare. Prin impunerea unui stil de lucru consistent n elaborarea codului surs, se pot atinge n general urmtoarele obiective: mbuntirea productivitii la programatorii existeni; noii programatori se vor adapta la codul surs existent ntr-un timp mai scurt dect cel necesar n alte condiii; programatorii existeni vor putea trece de la un proiect la altul fr a fi necesar schimbarea stilului de programare.

Standardizarea modului de elaborare a codului surs duce la reducerea timpului pn cnd produsul ajunge pe pia, la reducerea timpului cheltuit cu corecturile pe linia de producie i va oferi inginerilor programatori posibilitatea de a trece de la un proiect la altul fr a fi necesar un efort deosebit de nvare. Acest lucru va duce la reducerea timpului consumat cu activitile de rutin permind creterea procentului de timp alocat activitilor creatoare. Pe de alt parte, programatorii trebuie ncurajai inginerii s exprime (n sensul pozitiv) personalitatea lor n modul de ntocmire a programelor. Diversitatea 24

colectivului de programatori reprezint un fapt pozitiv n actul de creaie i trebuie ncurajat creativitatea i experiena acestora n dezvoltarea programelor. n general, dac numrul inginerilor programatori dintr-un colectiv este mare i acesta crete n mod constant, vor fi necesare n mod sigur standarde care s asigure o comunicare ct mai uoar a acestora prin intermediul programelor scrise. Un standard acceptabil pentru dezvoltarea de software v va ajuta s accelerai impunerea lui. Elaborarea produselor program se face n diferite limbaje de programare, n medii diferite i pe maini diferite. n acest capitol sunt prezentate reguli i indicaii care s generalizeze un stil de programare independent fa de aceast diversitate. De exemplu, s presupunem c un program este scris n dou limbaje de programare diferite. Dac aceste dou limbaje de programare au aproximativ acelai tip de instruciuni i semantic (de exemplu BASIC i C), cele dou programe vor fi foarte asemntoare. Evident, prin alegerea unor perechi de limbaje diferite (de exemplu Pascal/Assembler, BASIC/LISP sau C++/SETL) programele vor arta foarte diferit dar multe elemente ale acestor programe trebuie s fie identice, inclusiv numele variabilelor, comentariile, etc. Regulile i indicaiile prezentate n acest capitol se vor referi la urmtoarele aspecte: modularizare; caracteristicile unitilor de program de calitate; tipuri de date nume tipuri de date i obiecte abstracte; organizarea structurilor de control; organizarea programului; comentariile i documentarea programului; obinerea codului surs care s permit testarea simpl a programelor.

Acest capitol conine trei tipuri de reguli: indicaii; reguli comune care pot fi nclcate, ele fiind aplicate n funcie de situaie; reguli imperative care trebuie aplicate cu strictee.

Regulile comune trebuie respectate ntotdeauna n afar de cazul cnd exist un motiv serios i bine argumentat de nclcare a acestora. Nerespectarea acestor reguli trebuie s se fac ct mai rar i bine documentat (explicnd n scris motivul, nainte de nclcarea acestora). Indicaiile sunt mai puin severe dect o regul comun. Ca regul general, o indicaie trebuie respectat cu excepia cazului cnd exist motive ca aceasta s fie nclcat. Nerespectarea indicaiilor nu trebuie documentat ci este necesar numai ca aceste nclcri s poat fi explicate verbal. Categoria a treia, cea a regulilor imperative presupune c acestea nu vor fi nclcate niciodat.

25

3.2. Caracteristicile rutinelor de calitate

O rutin este o unitate generic de program care reprezint o funcie, o procedur, subprogram, iterator, bloc sau program principal. Calitatea rutinelor ce apar n program are un impact foarte mare asupra siguranei i claritii programelor. Urmtoarele seciuni descriu cteva din atributele rutinelor de nalt calitate. 3.2.1. Coeziunea rutinelor Rutinele prezint urmtoarele tipuri de coeziune (prezentate n ordinea descresctoare a calitii): coeziunea funcional i logic n cazul n care rutina ndeplinete numai o sarcin (simpl); coeziunea secvenial sau de tip conduct apare n cazul cnd rutina conine mai multe operaii secveniale ce trebuie efectuate ntr-o anumit ordine iar datele de la o operaie sunt transferate urmtoarei operaii, printr-o anumit operaie de filtrare; coeziunea global sau de comunicaie se ntlnete atunci cnd o rutin realizeaz un set de operaii ce utilizeaz un set comun de date, operaii care de altfel nu au nici un fel de legtur; coeziunea temporal se ntlnete atunci cnd o rutin realizeaz un set de operaii ce trebuie terminate la acelai moment de timp (dar nu neaprat ntro anumit ordine). Un exemplu tipic n astfel de cazuri este reprezentat de o rutin de iniializare; coeziunea procedural se ntlnete atunci cnd o rutin realizeaz o secven de operaii ntr-o ordine specific iar aceast ordine este dat de modul n care sunt aranjate operaiile. Spre deosebire de coeziunea secvenial, operaiile nu folosesc aceleai date; coeziunea la nivel de instruciune se ntlnete atunci cnd diferite operaii (fr legtur) apar n acelai modul i o variabil de stare (de exemplu un parametru) selecteaz operaia ce urmeaz s fie executat. n mod tipic astfel de rutine conin instruciuni de comutare (case switch) sau if...elseif...elseif; lipsa coeziunii apare dac ntre operaiile dintr-o rutin nu exist aparent nici o legtur.

Primele trei forme de coeziune prezentate mai sus sunt n general aceptabile ntr-un program. Cea de-a patra este i ea acceptat dar trebuie utilizat rar. Ultimele trei forme n-ar trebui s apar niciodat ntr-un program. Indicaie: Toate rutinele trebuie s aib o coeziune ct mai bun. Coeziunea funcional este cea mai bun, urmat de coeziunile secvenial i global. Coeziunea temporal poate fi folosit uneori. Celelalte forme de coeziune trebuie evitate. 26

3.2.2 Cuplarea rutinelor Cuplarea rutinelor se refer la modurile n care dou rutine comunic ntre ele. O rutin de calitate trebuie s fie slab cuplat. Exist diferite criterii care definesc nivelul de cuplare ntre dou rutine: cardinalitatea numrul obiectelor care se comunic ntre dou rutine. Cu ct comunic mai puine obiecte cu att este mai bine (de exemplu ct mai puini parametri ai rutinei); intimitatea reprezint gradul de generalitate al parametrilor comunicai ntre rutine (date locale sau globale). Listele de parametrii reprezint forma tipic de parametrii locali; cmpurile de date locale din clase sau obiecte, reprezint nivelul urmtor; cmpurile de date globale reprezint un grad mai sczut de intimitate i transferarea datelor n fiiere sau baze de date este conexiunea cu cea mai mic intimitate; vizibilitatea este ntr-un fel legat de intimitate. Acest parametru se refer la ct de vizibile sunt datele transferate ntre rutine n ntregul sistem. De exemplu transferul datelor prin liste de parametrii este direct i foarte vizibil (putei vedea ntotdeauna datele apelate n linia de apel a rutinei); transferul datelor prin variabile globale face transferul mai puin vizibil (trebuie ns setate variabilele globale nainte de apelul rutinei). Alt exemplu este constituit de transferul variabilelor simple (scalare) ca un tot ntr-o structur/record i trensferul acestei structuri/record la apelant; flexibilitatea se refer la gradul de dificultate n a realiza o conexiune ntre dou rutine care iniial nu erau destinate s se apeleze una pe alta. De exemplu, s presupunem c apare necesitatea transferrii unei structuri ce conine trei cmpuri, unei funcii. Dac aceast funcie nu permite apelarea dect cu trei date obiect i nu o structur, va trebui creat o dat intermediar (marionet) de tip obiect n care vor fi copiate cele trei valori care apoi vor fi transferate rutinei.

O rutin este slab cuplat dac ea prezint o cardinalitate sczut, o intimitate crescut, o vizibilitate crecut i o flexibilitate crescut. Adesea, aceste caracteristici sunt contradictorii (de exemplu creterea flexibilitii prin spargerea cmpurilor n structuri ceea ce este un lucru bun va crete cardinalitatea care influeneaz n mod negativ calitatea rutinei). n general, n funcie de fiecare situaie particular, se va cuta un compromis ntre criteriile de cuplare. Un program care utilizeaz cuplarea sczut va conine n general mai puine erori pe KLOC (thousands of lines of code mii de linii de cod). n plus rutinele care prezint o cuplare sczut vor fi mai uor de reutilizat (n proiectul curent sau n proiectele viitoare). Indicaie: Cuplarea ntre rutine trebuie s fie sczut.

27

3.2.3. Dimensiunea rutinelor La nceputul anilor 1960 s-a hotrt ca rutinele s aib cel mult 66 de linii n aa fel nct s ncap pe o pagin de imprimant pentru a putea fi citite cu uurin. Mai trziu, n 1970, odat cu programarea interactiv a nceput s fie folosit dimensiunea de 24 de linii ct este dimensiunea unui ecran de monitor. Aceste criterii empirice sugereaz c dimensiunea redus a rutinei este un criteriu de calitate a rutinei. De fapt, numeroase studii asupra codurilor ce conin constrngeri artificiale asupra dimensiunilor rutinelor indic tocmai contrariul rutinele scurte conin adesea mai multe greeli pe KLOC. O rutin care prezint coeziune funcional este n dimensiunile corecte n ceea ce privete numrul de linii de cod coninute. O rutin nu trebuie mprit n mod artificial n dou sau mai multe subrutine (de exemplu sub_partI i sub_partII) numai din cauz c rutina este prea lung. Se verific mai nti dac rutina prezint o coeziune puternic i o cuplare sczut. Dac acest lucru se verific rutina nu este prea lung. Trebuie inut ns cont de faptul c o rutin lung indic realizarea a numeroase aciuni i deci aceasta nu va avea o coeziune puternic. Evident c acest observaie poate fi extins. Cele mai multe studii indic faptul c rutinele ce depesc 150-200 de linii de cod tind s conin mai multe erori i sunt mai greu de corectat dect rutinele scurte. Este de notat faptul c atunci cnd se stabilete dimensiunea rutinei nu vor fi numrate liniile goale sau cele care conin numai comentarii. Indicaie: Nu lsai constrngerile artificiale s afecteze dimensiunea rutinelor. La o rutin ce depete 150-200 de linii de cod trebuie verificat dac aceasta prezint coeziune funcional sau secvenial. n caz contrar se verific dac n rutin nu apar subsecvene generice ce pot fi realizate prin rutine de sine stttoare. Regul: O rutin nu trebuie scurtat niciodat prin divizarea n n pri care apoi vor fi apelate din secvenele corespunztoare, numai n scopul de a scurta rutina original. 3.3. Modularizarea Aa cum s-a artat i n capitolul 2, un modul este o colecie de obiecte care sunt nrudite logic. Aceste obiecte pot include constante, tipuri de date, variabile i uniti de program (de exemplu funcii, proceduri, etc.). Trebuie remarcat faptul c obiectele dintr-un modul nu trebuie s fie nrudite fizic. De exemplu, este posibil s construim un modul utiliznd diferite fiiere surs. De asemenea este posibil s avem diferite module n acelai fiier surs. Oricum cele mai bune module sunt cele care sunt nrudite att 28

fizic ct i logic; asta nsemnnd c toate obiectele asociate cu un modul exist ntr-un singur fiier surs (sau director dac fiierul surs este prea mare). Modulele conin diferite obiecte inclusiv constante, tipuri de variabile i uniti de program (rutine). Modulele au mai multe atribute asemntoare rutinelor; acest lucru nu trebuie s surprind deoarece rutinele sunt componentele de baz a unui modul. n orice caz modulele vor avea i atribute proprii. Urmtoarele paragrafe vor descrie atributele modulelor bine scrise. 3.3.1. Atributele modulelor

Modulul este termenul generic care descrie un set de obiecte nrudite prin program (rutine, date i tipuri) care sunt cuplate ntr-un mod oarecare. Modulele de calitate au multe atribute identice cu rutinele de calitate n sensul abilitii de a ascunde anumite detalii ale codului n afara modulului (vezi i paragraful 2.5.1). Modulele de calitate prezint o puternic coeziune. Aceasta nseamn c un modul ofer un (mic) set de servicii care sunt logic nrudite. De exemplu un modul pentru imprimant trebuie s furnizeze toate serviciile ateptate de la o imprimant. Rutinele individuale din modul vor furniza servicii individuale. Modulele de calitate vor prezenta o cuplare sczut. Aceasta din cauz c ele trebuie s prezinte numai cteva interfee (vizibile) bine definite ntre modul i exterior. Cele mai multe date sunt locale accesibile numai prin intermediul funciilor de acces. n plus, interfaa trebuie s fie flexibil. Modulele de calitate arat puin informaie n exterior. Codul din afara modulului va avea acces la modul numai prin intermediul unui mic set de rutine publice. Toate datele trebuie s fie locale modulului. Indicaie: Un modul trebuie s implementeze un tip de date abstract. Toate interfeele la modul trebuie s fie realizate printrun set bine definit de operaii. 3.3.2. Organizarea fizic a modulelor

Multe limbaje de programare furnizeaz suport direct pentru module (de exemplu pachetele din Ada, modulele n Modula-2 i uniturile n Delphi/Pascal). Cteva limbaje ofer ns doar suport indirect pentru module (de exemplu un fiier surs n C/C++). Altele, ca BASIC nu furnizeaz suport pentru module i deci modulele trebuie simulate prin gruparea fizic a obiectelor i impunerea unor anumite reguli. Sunt definite dou reguli care permit facilitarea citirii i nelegerii modulelor. Regul: Fiecare modul trebuie s se gsesc ntr-un singur fiier surs. Dac din considerente de dimensiune acest lucru nu este posibil, atunci toate fiierele surs trebuie s se gseasc ntr-un subdirector special destinat modulului. 29

Uneori se consider c modularizarea nseamn aezarea codului corespunztor fiecrei funcii ntr-un fiier surs separat. Aceast modularizare fizic deterioriaz sigurana programului mai mult dect o ajut. Modularizarea corect se face prin modularizarea logic ceea ce nseamn c modul este definit prin aciunile sale i nu prin sintaxa codului surs (cum este separarea funciilor).

3.4. Tipuri de date, declaraii i variabile

Regul: Dac un limbaj oarecare nu furnizeaz suport pentru module atunci trebuie simulate modulele prin gruparea obiectelor acestora n codul surs. Accesul la modul nu trebuie fcut dect prin intermediul interfeelor. La reverificarea codului surs trebuie verificate ntotdeauna inconsecvenele. Tipurile de date definite n cele mai multe limbaje de programare fac abstracie de structura calculatorului folosit, rareori aceste tipuri fiind n termeni exaci ai reprezentrilor main. De exemplu, o variabil ntreag poate fi reprezentat pe 16 bii n complement fa de doi pe o main, pe 32 de bii sau chiar pe 64 de bii pe alta. n mod clar, un program scris pentru ntregi pe 32 sau 64 de bii, va funciona eronat pe o main (sau compilator) care suport numai ntregi pe 16 bii. i reciproca poate fi uneori adevrat. Un avantaj presupus al limbajelor de programare de nivel nalt este faptul c tipurile de date fac abstracie de calculatorul folosit. n teorie un ntreg este un ntreg dar n practic exist ntregi scuri, ntregi i ntregi lungi. Dimensiunile obinuite sunt de 8, 16, 32, 64 de bii i aa mai departe. Din nefericire abstractizarea furnizat de limbajele de nivel nalt poate duce la imposibilitatea portabilitii programelor. Cele mai multe limbaje de programare de nivel nalt moderne furnizeaz programatorilor posibilitatea definirii de noi tipuri de date ca isomorfisme (sinonime) a tipurilor existente. Utiliznd aceast facilitate este posibil s definim module de tipuri de date care furnizeaz o definiie precis pentru cele mai multe tipuri de date. De exemplu putem defini tipurile de date int16 i int32 care vor folosi totdeauna 16 respectiv 32 de bii. Procednd n acest fel se poate uor garanta portabilitatea programelor prin schimbarea definiiei pentru int16 i int32 pentru noua main. S considerm exemplul urmtor n C/C++: Pe o main de 16 bii: typedef int int16; typedef long int32; Pe o main de 32 de bii: typedef short int16; typedef int int32; 30

Regul: Dac tipurile de date predefinite au o semantic diferit pe arhitecturi diferite de calculatoare sau n diferite compilatoare, atunci se va utiliza un set de definiii de tip care s permit schimbarea comod a programului pentru diferite arhitecturi sau compilatoare. Este riscant ca un anume obiect s foloseasc un format de date specific (cum ar fi de exemplu reprezentarea n complement fa de doi sau n virgul mobil IEEE). Este chiar mai ru s se impun ca un obiect s aib un numr fixat de bii. n general este bine s se evite utilizarea tipurilor predefinite dintr-un limbaj.

Indicaie: Dac tipurile de date care se creeaz depind de un format specific, se vor utiliza nume ca: int8, int16, int32, int64, real32, real64 i real80 (aceasta nsemnnd c numele tipului arat numrul de bii folosii) pentru a numi tipurile create. Dac tipurile de date nu impun o reprezentare specific, se vor utiliza nume descriptive (vezi n paragraful urmtor indicaiile cu privire la convenia numelor). Se va ncerca evitarea utilizrii acelor limbaje la care tipul de date se schimb n funcie de tipul mainii (din pcate acest lucru nu este totdeauna posibil). Se interzice redefinirea tipurilor existente. Pare o contradicie la cele spuse pn acum dar nu este aa. Acesta nseamn c dac exist un tip cu numele integer se va evita crearea unui nou tip cu acelai nume. Dac s-ar proceda astfel acest nou definiie poate duce la confuzii. Un alt programator care citete codul poate confunda noiunile. Regula aceasta trebuie aplicat att la tipurile create de utilizator ct i la tipurile predefinite. Regul imperativ: Niciodat nu va fi redefinit un tip existent. n program vor fi declarate toate variabilele chiar dac procesorul de limbaj folosete declaraiile implicite. Utilizarea declaraiilor implicite poate duce la rezultate imprevizibile (pentru c nu totdeauna sunt bune valorile implicite de obicei zero). Regul imperativ: n program se va face ntotdeauna declararea explicit a variabilelor (i a celorlali identificatori) chiar dac limbajul nu necesit acest lucru. 31

Unele limbaje impun declararea tuturor variabilelor ntr-un punct dat (de exemplu Pascal); alte limbaje, mai flexibile, permit declararea variabilelor oriunde n program cu condiia de a le declara nainte de prima utilizare; sunt i limbaje care nu cer declararea variabilelor. Din cauz c este posibil s fie declarate simboluri n diferite puncte ale programelor, diveri programatori au dezvoltat diverse convenii cu privire la poziia acestor declaraii. Dou dintre aceste convenii sunt mai rspndite: declararea tuturor simbolurilor la nceputul unitii de program asociate (funcie, procedur, etc.); declararea tuturor variabilelor ct mai aproape de utilizarea lor.

Din punct de vedere logic ce-a de-a doua regul pare cea mai bun. Aceast regul are ns i un inconvenient major dei numele variabilelor are o singur definiie programul va utiliza aceste variabile n diferite locuri. Din acest motiv este greu de depistat care este prima folosire a acestor variabile iar la citirea programului este greu de gsit definiia. Avantajul declarrii variabilelor la nceputul unitii de program este dat de faptul c indiferent unde este folosit variabila se poate vedea ntotdeauna modul n care este definit aceasta. Regul: Toate definiiile variabilelor, constantelor i tipurilor trebuie s se afle chiar la nceputul unitii de program acolo unde este definit scopul obiectului. Din nefericire nu toate definiiile numelor sunt pasive, unele se actualizeaz la execuia codului. O instan a unei clase de obiecte n C++ este un exemplu bun n acest sens. Definiia unei clase de obiecte apeleaz constructorul pentru aceast clas. Constructorul poate cere calculul anumitor valori ale parametrilor anterior definirii obiectului. Acest lucru mpiedic plasarea definiiilor la nceputul fiecrui modul. Soluia este simpl i conduce la urmtoarea regul: Regul: Dac un obiect nu poate fi definit la nceputul unitii de program cruia i aparine, atunci se va pune un comentariu la nceputul blocului i variabila va fi definit imediat ce este posibil, n unitatea de program. Se va plasa un comentariu ct mai aproape de definiie pentru a aminti cititorului programului de comentariul de la nceputul blocului n cazul n care definiia actual se va schimba vreodat. Cteva argumente puternice pledeaz pentru anumite limbaje de programare, cum este C++ de exemplu, care prevd faciliti excelente pentru declararea variabilelor cu anumite construcii de limbaj. Astfel, instruciunea for(int i=0;i<10;++i)... limiteaz utilizarea variabilei i pentru bucl. Scopul indicaiilor i regulilor prezentate 32

aici este cel de a crea un standard care s se poat aplica tuturor limbajelor. Fcnd excepii pentru C++ se pot crea confuzii. De altfel C++ v permite crearea de noi uniti de program utiliznd { i } (de exemplu instruciuni compuse). Programatorii care doresc s pun definiiile variabilelor ct mai aproape de bucla for pot s procedeze astfel: // Previous statements in this code... . . .

{ }

int i; for (i=start; i<=end; ++k) ...

. . . // Additional statements in this code. Comentariile descriptive trebuie s nsoeasc ntotdeauna un set de declaraii de variabile. Aceste comentarii trebuie s descrie scopul variabilelor, s furnizeze numele complet al acestora dac n numele variabilelor se folosesc prescurtri i s descrie orice constrngere sau atribuire a acestor variabile. Poziia acestor comentarii trebuie s fie imediat deasupra blocului sau unitii de program unde sunt declarate variabilele. Pentru a crete sigurana i pentru a uura gsirea variabilelor trebuie s se pun cte o variabil pe linie n partea stng a listei. n limbajele n care tipul precede numele variabilei este bine s se pun tipul pe o linie i numele variabilei (identat) pe linia urmtoare. Regul: Asociat cu orice set de declaraii de variabile va exista un set de comentarii cunoscut sub denumirea de dicionar de date. Acest dicionar de date va descrie numele i scopul fiecrei variabile. Dicionarul va descrie de asemenea orice constrngere sau atribuire n utilizarea acestor variabile. Exemple: (* Pascal *) var LineCnt, WordCnt, CharCnt:integer; (* Also Reasonable *) var 33

{Number of lines, words and } { and characters in a file. }

LineCnt:integer; WordCnt:integer; CharCnt:integer; /* C/C++ */ int LineCnt, WordCnt, CharCnt; /* Another C/C++ Version */ int LineCnt; int WordCnt; float CharCnt;

{Number of lines, words and } { and characters in a file. }

/* Number of lines, words and */ /* and characters in a file. */

/* Number of lines, words and */ /* and characters in a file. */

3.5. Stabilirea numelor

Conform studiilor efectuate de ctre firma IBM, utilizarea identificatorilor de bun calitate contribuie mai mult la sigurana programului dect oricare alt factor, inclusiv cea a comentariile de bun calitate. Calitatea identificatorilor poate mbunti sau distruge un program; programul cu identificatori de calitate poate fi foarte uor citit. Sunt foarte multe idei care s duc la ntocmirea numelor de calitate; multe dintre reguli sunt, n sensul comun, de mod veche. Din nefericire programatorii (n special cei n C/C++) au dezvoltat convenii specifice care ignor sensul comun. Marele obstacol este acela c cei mai muli programatori au nvat c numele nu au prea mare importan i c oricine tie cum s lucreze cu numele utilizate n program. Convenia de nume este un domeniu n tiina calculatoarelor n care pe departe exist cele mai multe puncte de vedere divergente. Scopul primar al numelui unui obiect n limbajul de programare este cel de a descrie utilizarea i/sau coninutul acelui obiect. Al doilea scop poate fi acela de a descrie tipul obiectului. Programatorii utilizeaz diferite mecanisme pentru a atinge aceste scopuri. Din nefericire exist prea multe convenii i este de ateptat ca un programator s foloseasc ntr-un program mai multe standarde diferite. Marea majoritate a programatorilor cunosc engleza. Din acest motiv este bine ca toi identificatorii s fie uor de interpretat n limba englez. Regul: Toi identificatorii care reprezint cuvinte sau fraze trebuie scrii n limba englez. 3.5.1. Consideraii asupra capitalizrii (utilizarea literelor mari i mici)

Un identificator care are acelai tip de litere (mari sau mici) va fi interpretat corect fie c se utilizeaz un compilator care ine cont de tipul de litere fie c se utilizeaz un compilator insensibil la tipul de litere. n practic acest lucru nseamn c 34

toate folosirile identificatorului trebuie scrise exact n acelai fel (inclusiv tipul de litere) i nu trebuie s existe alt identificator care s conin aceleai litere. De exemplu, dac se declar un identificator de variabil ProfitsThisYear n Pascal (limbaj insensibil la literele mari sau mici insensibil la capitalizare), acest variabil poate la fel de bine s fie referit ca profitsThisYear sau PROFITSTHISYEAR. Dac programul nu este insensibil la capitalizare atunci numele de mai sus reprezint variabile diferite. Dac ntr-un limbaj sensibil la capitalizare cum este C/C++ se creeaz dou variabile diferite cum ar fi PROFITS i profits atunci cnd se dorete utilizarea uni limbaj insensibil la capitalizare (cum ar fi Pascal) n acelai program, atunci folosirea celor dou variabile diferite va da o eroare. Regul imperativ: Toi identificatorii de variabile trebuie s fie neutri din punct de vedere al capitalizrii atunci cnd se utilizeaz limbaje cu comportare diferit din punct de vedere al capitalizrii. Diferii programatori (n special n limbaje diferite) utilizeaz capitalizarea alfabetic pentru a indica obiecte diferite. De exemplu o convenie obinuit n C/C++ este de a utiliza identificatori cu toate literele mari pentru a desemna constantele, macroinstruciunile sau pentru definirea tipurilor i utilizarea identificatorilor cu toate literele mici pentru a desemna numele de variabile sau cuvintele rezervate. Programatorii n Prolog utilizeaz la nceputul numelui identificatorului prima liter mic pentru a desemna o variabil. Exist i alte reguli asemntoare cu acestea. Din nefericire sunt multe convenii diferite pentru utilizarea capitalizrii alfabetice la fel de importante, rezultnd prin urmare regula urmtoare pentru elaborarea codului utilizabil n mai multe limbaje de programare: Regul: Nu trebuie utilizat niciodat capitalizarea alfabetic pentru a desemna tipul, clasificarea sau oricare alt atribut legat de program al unui identificator (exceptnd cazurile cnd sintaxa programului cere expres acest lucru). Se va vedea mai trziu c exist cteva excepii de la aceast regul. Capitalizarea alfabetic are o utilizare important la identificatori ea este folositoare pentru separarea cuvintelor n identificatori multicuvnt. Pentru ca identificatorii multicuvnt s poat fi uor citii se folosesc litere mari pentru fiecare nceput de cuvnt din identificatorul multicuvnt. Regul: Se va folosi capitalizarea pentru prima liter a cuvintelor din interiorul identificatorilor multicuvnt. 35

Referitor la regula de mai sus trebuie notat faptul c prima liter poate fi mare sau mic dar ea trebuie s fie diferit de restul cuvntului. Se recomand utilizarea consecvent a acestei reguli pe tot cuprinsul programului. Literele mici sunt mai uor de citit dect literele mari. Identificatorii scrii numai cu litere mari necesit adesea un timp de dou ori mai mare s fie recunoscui (citii) i deci acetia stric lizibilitatea programului. Utilizarea acestor identificatori este rareori cu adevrat necesar n program. Dei convenia C/C++ impune utilizarea identificatorilor cu litere mari este bine s fie evitat acest lucru mai ales c este nclcat regula prezentat mai sus. Regul: Trebuie evitat utilizarea numelor identificatorilor scrise numai cu litere mari. 3.5.2. Prescurtri

Primul scop al unui identificator este acela de a descrie utilizarea sau valoarea asociat unui obiect. Cea mai bun cale de a construi un identificator pentru un obiect este: acesta va fi mai nti descris n limba englez i apoi s se va stabili un nume de variabil conform acestei descrieri. Numele variabilei trebuie s fie semnificativ, concis, i neambiguu pentru un programator care are un nivel mediu de cunoatere a limbii engleze. Se vor evita numele scurte. Cercetrile arat c programele n care sunt utilizai identificatori cu lungimea medie de 10-20 de caractere sunt n general mai uor de depanat dect programele care au nume de identificatori substanial mai scuri sau mai lungi. Se vor evita pe ct posibil prescurtrile. O prescurtare care pare perfect rezonabil astzi va fi confundat cu alta mai trziu. S presupunem c urmtoarele nume de variabile apar ntr-un program comercial: NoEmployees, NoAccounts, pend Variabilele NoEmployees i NoAccounts par a fi variabile logice (booleene) indicnd prezena sau absena angajailor respectiv a conturilor (din cauza prefixrii cu No negaie). De fapt aici programatorul a folosit prescurtarea No (perfect rezonabil pentru lumea real) pentru number. Cel mai adesea programatorii utilizeaz prescurtrile n dou situaii: nu pot folosi tastatura cu vitez foarte mare (nu stpnesc tehnica necesar de a scrie repede la tastatur) caz n care acetia au tendina de a reduce efortul de a scrie la tastatur sau, n cea de a doua situaie, cnd un nume bun pentru un obiect este pur i simplu prea lung. Prima situaie este total inacceptabil pentru folosirea prescurtrilor. Situaia a doua, atunci cnd este aplicat cu grij, poate permite utilizarea ocazional a prescurtrilor.

36

Indicaie: Se va evita utilizarea prescurtrilor n numele variabilelor. Atunci cnd este necesar se vor utiliza prescurtrile standardizate sau se va cere cuiva s verifice nelesul prescurtrilor folosite. Atunci cnd se folosesc prescurtri n program, se va construi un dicionar de date n comentariu ct mai aproape de definiia numelor, dicionarul furniznd numele ntreg i descrierea prescurtrilor folosite. Numele variabilei construite trebuie s poat fi pronunat cu uurin (n limba englez n particular). Numele NumFiles este mai bun ca NmFls. Se vor evita omonimele i numele lungi care coincid cu excepia doar a ctorva silabe. Dac numele variabilelor este bine ales atunci un test relevant este citirea listingului programului la telefon unei persoane care s-l neleag fr greeli (sau confuzii). Regul: Toi identificatorii trebuie s fie pronunabili (n limba englez) nefiind permise mai mult de dou consoane succesive n numele identificatorului. 3.5.3. Poziia componentelor n interiorul identificatorului Atunci cnd citesc un listing, cei mai muli programatori citesc doar primele cteva caractere ale unui identificator. Este deci important ca informaia relevant (adic ceea ce face identificatorul unic) s fie plasat n primele caractere ale identificatorului. Deci trebuie evitat construirea mai multor identificatori care s nceap cu aceeai secven de caractere i care s difere prin restul caracterelor, deoarece n acest caz listingul este greu de citit. Indicaie: La majoritatea identificatorilor folosii trebuie s difere primele caractere n acest fel programul fiind mai uor de citit. Corolar: Nu va fi folosit niciodat un sufix numeric pentru a diferenia dou nume de variabile. Avnd n vedere rspndirea sistemului de operare Microsoft Windows i a aplicaiilor dezvoltate sub acest sistem de operare vor fi fcute n continuare cteva remarci legate de programarea n acest mediu. Muli programatori n C/C++, n special 37

programatorii n Microsoft Windows, au adoptat convenia formal pentru nume cunoscut ca notaia ungureasc. n legtur cu acest subiect putem s-l citm pe Steve McConnell din lucrarea sa Code Complete: termenul de unguresc se refer att la faptul c numele (obiectelor) care respect aceast convenie seamn cu cuvintele scrise ntr-o limb strin ct i la faptul c cel care a creat convenia, Charles Simonyi, este originar din Ungaria. Notaia ungureasc violeaz multe reguli (numele nu par a fi englezeti) printre care i faptul c numele variabilelor au prefixe foarte asemntoare, ceea ce la face greu de citit. Notaia ungureasc are cteva avantaje minore dar are dezavantaje semnificative ce depesc pe departe avantajele. Urmtoarea list din lucrarea Code Complete i din alte surse arat ce este greit n notaia ungureasc: notaia ungureasc definete n general obiectele n termenii tipului mainii de baz mai degrab dect n termenii tipurilor de date abstracte; notaia ungureasc combin semnificaia cu reprezentarea. Unul din scopurile principale ale limbajelor de nivel nalt este abstractizarea cilor de reprezentare. De exemplu dac se declar o variabil de tip ntreg, atunci, n cazul cnd se schimb din anumite motive tipul acestei variabile din ntreg n real, nu trebuie s apar necesitatea schimbrii numelui variabilei numai din acest motiv; notaia ungureasc ncurajeaz utilizarea numelor de variabile lipsite de informaie (notaie lene). ntr-adevr este obinuit s ntlnim nume de variabile n programele Windows care sunt prefixate numai cu caractere ce definesc tipul acestora fr s aib ataate i un nume descriptiv; notaia ungureasc prefixeaz numele descriptive cu anumite informaii despre tip ceea ce face s fie greu de depistat partea descriptiv a numelui. Indicaie: Evitai utilizarea notaiei ungureti i oricare alt convenie de nume formal, care ataeaz identificatorului informaii de tip de nivel sczut legate de particularitile mainii (low-level). Dei ataarea informaiilor legate de tipul mainii nu este n general recomandabil, se pot asocia la numele obiectului anumite informaii de tip, de nivel nalt (care nu sunt legate de structura particualr a unei maini de calcul), n special dac acest nume implic tipuri, cu precizarea c este bine ca aceste informaii s apar n sufixul numelui. De exemplu nume ca PencilCount i BytesAvailable sugereaz valori ntregi. De asemenea nume ca IsReady i Busy indic valori logice iar KeyCode i MiddleInitial sugereaz variabile de tip caracter. Nume ca StopWatchTime vor sugera o valoare real. De asemenea CustomerName va indica o variabil ir. Din nefericire nu este totdeauna posibil s alegem nume potrivite care s sugereze att coninutul ct i tipul unui obiect; acest lucru este cu att mai evident atunci cnd obiectul este o instan sau definiia unor date abstracte. n astfel de situaii un text adiional poate mbunti calitatea identificatorului. Notaia ungureasc reprezint o ncercare n acest sens dar rezultatul este departe de a fi cel mai bun. 38

O soluie mai bun este utilizarea unui sufix pentru a desemna tipul sau clasa identificatorului. O convenie obinuit UNIX/C este, de exemplu, s aplicm sufixul _t pentru a desemna numele tipului (de exemplu size_t, key_t, etc.). Aceast convenie este superioar notaiei ungureti din urmtoarele motive: elementul care definete tipul este un sufix care nu interfer cu numele variabilei; aceast convenie specific clasa obiectului (const, var, type, function, etc.) mai degrab dect tipul low-level; nu impune schimbarea identificatorului dac clasificarea acestuia se schimb (se schimb numai sufixul). Indicaie: Dac se dorete diferenierea identificatorilor ce reprezint constante, definiii de tip sau nume de variabile, se vor utiliza sufixele _c, _t i respectiv _v.

Regul: Sufixul de clasificare nu trebuie s component care difereniaz doi identificatori. fie singura

Aplicarea regulilor i indicaiilor prezentate n acest paragraf pot conduce uneori la dificulti n compunerea i manevrarea numelor. Din acest motiv trebuie evitate eventualele capcane care pot aprea n stabilirea acestora. S considerm un tip de dat de nivel nalt numit buton corespunztoare unui buton ntr-o clas VisualBASIC sau Delphi. Un nume de variabil cum este CancelButon are un sens foarte bun. De asemenea, etichetele care apar ntr-o clas pot avea nume ca, de exemplu, ETWWLabel i EditPageLabel. Trebuie notat faptul c la aceste nume, sufixele utilizate pentru sugerarea tipului vor fi afectate de o schimbare a acestuia, ceea ce va impune o schimbare a numelui variabilei. Din fericire, n general schimbri de tip la nivel nalt sunt mult mai puin frecvente dect schimbrile de tip la nivel sczut i atunci nu este cazul ca numele utilizate la nivel nalt s fie mai complicate. 3.5.4. Nume de evitat

Trebuie evitat utilizarea ntr-un identificator a simbolurilor care pot fi confundate cu altele (prin asemnarea dintre acestea). Aceste simboluri sunt reprezentate urmtoarele seturi {1 (unu), I (i mare) i l (L mic)}, {0 (zero) i O (litera mare o)}, {2 (doi) i Z (litera mare z)}, {5 (cinci) i S (litera mare s)} i {6 (ase) i G (litera mare g)}.

39

Indicaie: n identificatori se va evita utilizarea simbolurilor care pot fi confundate cu alte simboluri. Se va evita utilizarea prescurtrilor care pot induce n eroare. Acest lucru se ntmpl n general atunci cnd nu se folosesc prescurtri unanim acceptate sau cnd n urma prescurtrii se obine un cuvnt uzual care are o semnificaie bine precizat. De exemplu prescurtarea FALSE poate fi un identificator care nseamn Failed As Legitimate Software Engineer dar care va fi confundat cu siguran cu valoarea de adevr fals.

Regul: Se va evita utilizarea prescurtrilor care pot induce n eroare. Trebuie evitate numele cu neles asemntor. De exemplu, dac avem dou variabile InputLine i InputLn i se utilizeaz cele dou variabile n scopuri diferite, atunci exist riscuri mari s se fac adeseori confuzii ntre acestea cnd se scrie sau se citete codul. Numele trebuie s fie diferite pentru a nu fi confundate. Regul: Nu se vor utiliza nume cu semnificaii similare pentru obiecte diferite din program. n acelai sens trebuie evitat utilizarea a dou sau mai multe variabile care au sensuri diferite dar nume similare. De exemplu, ntr-un program cu privire la examinarea studenilor, dac se vor folosi numele NumStudents pentru a indica numrul de studeni din clas i StudentNum pentru a memora numrul de identificare (ID number) al fiecrui student. Cele dou variabile NumStudents i StudentsNum vor crea multe probleme din cauz c sunt foarte asemntoare. Regul: Nu se vor utiliza nume similare care au semnificaii diferite. Trebuie evitate omonimele. Este momentul s reamintim aici de proba propus mai devreme de a citi listingul la telefon unei persoane care trebuie s-l neleag fr greeli. 40

Indicaie: Evitai utilizarea omonimelor pentru nume. La alegerea numelor se vor evita de asemenea cuvintele greite (care nu sunt n dicionar, sau care duc la o pronunie greit). Indicaie: n numele identificatorilor nu vor fi folosite cuvinte greite care nu sunt n dicionar. Numele rutinelor din biblioteci nu trebuie redefinite din cauz c exist riscul s apar confuzii ntre rutina proprie i cea original. Este acceptabil ca noua rutin s aib aceeai funcie cu cea veche dar este total inacceptabil s aib funcii diferite. De asemenea vor apare confuzii atunci cnd actualizarea nu se face pentru toate versiunile bibliotecii respective. Acest lucru se ntmpl n special cnd se lucreaz cu biblioteci standard de rutine sau cu API (Application Programming Interface). Regul imperativ: n program nu vor fi refolosite numele rutinelor dintr-o bibliotec standard, n afar de cazul n care s-a nlocuit n mod expres rutina cu una care are o semantic similar. Nu se vor reutiliza numele pentru alte scopuri .

3.6. Organizarea structurilor de control

Dei structurile de control utilizate n cele mai multe limbaje de programare moderne i au rdcinile n limbajul Algol-60, exist un numr surprinztor de variaii subtile ntre structurile de control folosite n limbajele actuale. Dac se elaboreaz codul programului n mai multe limbaje de programare este de preferat s existe un stil unitar de scriere a structurilor de control n aa fel nct programul s fie uor de citit, modificat i ntreinut. n mod normal limbajele de programare conin opt instruciuni de control al fluxului: dou instruciuni de selecie condiional (if..then..else i case/switch), patru instruciuni de buclare (while, repeat..until/do..while, for and loop), o instruciune pentru apelarea unitilor de program (de exemplu procedura call) i o instruciune pentru succesiune. Exist i alte structuri de control mai puin obinuite dar n aceast lucrare se vor trata doar mecanismele de control comune. Structurile de control au dou forme tipice: cele care au o singur instruciune ca operand i cele care conin o secven de instruciuni. De exemplu instruciunea if..then din Pascal care opereaz cu o singur instruciune: if (expresie) then Single_Statement; 41

Bineneles c este posibil aplicarea acesteia pentru o list de instruciuni, dar acest lucru implic crearea unei instruciuni compuse utiliznd perechea begin ... end. Sunt dou stiluri adoptate pentru acest tip de instruciune n funcie de modul de poziionare a cuvintelor rezervate begin i end. Unii programatori realizeaz instruciunile compuse astfel: if (expresie) then begin {Statement 1} {Statement 2} . . . {Statement n} end; ali programatori au adoptat forma: if (expresie) then begin {Statement 1} {Statement 2} . . . {Statement n} end; Programatorii n C/C++ utilizeaz n mod obinuit patru moduri diferite de a pune parantezele de deschidere i de nchidere a instruciunii compuse pentru o instruciune if. Aceste posibiliti diferite de scriere a instruciunilor ridic prima problem n adoptarea unui stil unitar de scriere a codului n limbaje de programare diferite. A doua problem cu instruciunea if n C/C++ i Pascal este ambiguitatea implicat. S considerm urmtorul cod Pascal: if (expression) then if (expression) then (* Statement *) else (* Statement *); La prima vedere este greu de stabilit crei instruciuni if i aparine instruciunea else. Bineneles c programatorii n Pascal vor considera c este evident faptul c instruciunea else aparine celei de-a doua instruciuni if (citind de sus n jos) dar pentru programatori obinuii cu alte limbaje codul va fi greu de citit. De asemenea se pot pune o serie de ntrebri legate de o astfel de structur, cum sunt: cum se procedeaz dac se dorete ca instruciunea else s aparin primei instruciuni if? 42

ce se ntmpl dac exist o instruciune compus lung dup cea de-a doua instruciune if iar instruciunea else este foarte deprtat. Ct de uor este s se determine crei instruciuni if aparine instruciunea else?

Limbajele moderne de programare (Modula-2, Ada, Visual Basic, FORTRAN 90, etc.) rezolv aceast problem prin folosirea structurilor de control care ncep i se termin cu cuvinte rezervate, cum sunt de exemplu IF i ENDIF. Codul de mai sus, n unul din aceste limbaje va fi scris astfel: if (expression) then if (expression) then { Statement list }; endif; else endif; n acest caz este mult mai uor s se determine cui aparine instruciunea else. Trebuie notat faptul c se pot introduce ntre instruciunile if i endif sau ntre if i else o instruciune sau o list de instruciuni fr a fi necesare paranteze sau cuvintele rezervate begin i end. Setul complet de structuri de control ale limbajelor de programare moderne presupune: if..then..elseif..else..endif select..case..default..endselect (instruciune tipic case/switch) while..endwhile repeat..until loop..endloop for..endfor break breakif continue

{ Statement list };

Toate programele trebuie s utilizeze aceste structuri de control acolo unde sunt disponibile i s le simuleze dac ele nu exist. Regul: Programele scrise n limbaje imperative standard (ca de exemplu C/C++, Pascal, Ada, Visual BASIC, Delphi, etc.) vor utiliza versiunile moderne ale structurilor de control standard. Dac limbajul nu are suport direct pentru aceste structuri de control, programatorul le va simula. 43

Regul: Dac codul conine un lan de instruciuni if...elseif...elseif......elseif..... nu se va utiliza instruciunea else final pentru a nchide ultima condiionare. Instruciunea else final va fi utilizat ntotdeauna pentru a testa o condiie de eroare. Dac este necesar s se testeze cteva valori, succesiv, ntr-un lan de instruciuni if...elasif...elseif...., se va testa ntotdeauna fiecare valoare ntr-o instruciune if sau elseif separat. Cele mai multe compilatoare implementeaz instruciunile de selecie cu mai multe alternative (case/switch) utiliznd o tabel de salturi. Acest lucru nseamn c ordinea condiiilor n interiorul instruciunii de selecie este irelevant. Aezarea instruciunilor ntr-o anumit ordine mbuntete rareori performanele de vitez. Chiar dac ordinea instruciunilor nu conteaz pentru compilator, condiiile trebuie organizate n aa fel nct s fie uor de citit. Sunt dou moduri comune de organizare: sortate (numeric, alfabetic) sau dup frecven (cele mai frecvente la nceput). Ambele moduri de organizare duc la creterea lizibilitii codului dar organizarea dup frecven are avantajul c va duce la funcionarea mai rapid a instruciunii de selecie dac compilatorul utilizeaz implementarea brain-dead if..then..elseif..elseif a instruciunilor cu mai multe ci de selecie. O piedic n utilizarea celei de-a doua metode este faptul c adesea este dificil de determinat care dintre condiiile de selecie se va executa mai des i deci va avea o frecven mai mare. Indicaie: Cnd se folosesc selecii cu mai multe ci (case/switch) atunci condiiile de selecie trebuie sortate n ordine numeric (alfabetic) sau dup frecvena previzionat a apariiei. Sunt trei categorii de construcii de tip bucl disponibile n limbajele de nivel nalt uzuale: bucle care testeaz condiia de terminare la nceputul buclei (exemplu while), bucle care testeaz condiia de terminare la sfritul buclei (exemplu repeat...until) i cele care testeaz condiia de terminare la mijlocul buclei (exemplu loop...endloop). Este posibil simularea oricrei dintre aceste bucle pe baza celorlate. Prezentm aceste trei tipuri de bucle realizate cu ajutorul buclei loop...endloop: /* Test for loop termination at beginning of LOOP..ENDLOOP */ loop breakif (x = = y); . . . 44

endloop; /* Test for loop termination in the middle of LOOP..ENDLOOP */ loop . . . breakif (x = = y); . . . endloop; /* Test for loop termination at the end of LOOP..ENDLOOP */ loop . . . breakif (x = = y); endloop; Fiind dat flexibilitatea structurii de control loop...endloop poate pune, firesc, ntrebarea rostului celorlalte structuri de control al buclelor. Raspunsul este simplu: utiliznd structura buclei cea mai adecvat situaiei date, programul va fi mai uor de citit i deci n general nu trebuie folosit un tip de bucl atunci cnd situaia cere un altul. Dac o persoan care citete codul vede o construcie de tipul loop...endloop se poate gndi c este n regul dac insereaz instruciuni nainte sau dup instruciunea de ieire din bucl. Dac algoritmul utilizat este de fapt unul de tip while...do sau repeat...until atunci dup modificare programul poate funciona eronat. Regul: Folosii ntotdeauna cel mai potrivit tip de bucl (caracterizat de poziia testului de terminare). Nu forai niciodat ca un tip de bucl s aib comportarea altui tip. Multe limbaje de programare pun la dispoziie un caz special pentru bucla while care permite executarea unui numr specificat de ori a buclei dup prima ntlnire a nceputului buclei (o bucl definit spre deosebire de bucla nedefinit). Aceasta este bucla for n cele mai multe limbaje. Din nefericire aceast bucl iterativ pe un anumit numr de pai se realizeaz de la modul cel mai simplu (de exemplu n Pascal) pn la modul cel mai complex (de exemplu n Algol-68 i PL/I). Marea majoritate a buclelor for execut paii cu o valoare fix a incrementului sau decrementului variabilei de control a buclei. n mod normal cei mai muli programatori vor utiliza n mod automat acest mod de operare a buclei for. Din cauz c cei mai 45

muli programatori se ateapt la aceast comportare este raional s se limiteze utilizarea buclei for la aceast semantic. Dac sunt de dorit alte mecanisme trebuie s fie utilizat o bucl while pentru implementarea acestora (deoarece bucla for este de fapt un caz special al buclei while). Sunt i alte motive care se ascund n spatele acestei indicaii. Multe compilatoare genereaz n special cod eficient doar pentru buclele for standard iar pentru buclele for particulare codul generat va fi mai puin eficient. Rezult c exist att raiuni de eficien a codului generat de compilator ct i de uurin a citirii programului surs, pentru alegerea fcut. Regul: Buclele FOR trebuie s utilizeze o variabil de control de tip ordinal (de exemplu ntreg, caracter, boolean, tip enumerat) iar incrementul sau decrementul variabilei de control al buclei trebuie s fie egal cu unu. Cei mai muli programatori se ateapt ca execuia buclei s nceap cu prima instruciune din vrful buclei, rezult regula urmtoare. Regul: Toate buclele trebuie s aib un singur punct de intrare. Programul trebuie s intre n bucl prin instruciunea din vrful buclei. De asemenea cei mai muli programatori se ateapt ca o bucl s aib un singur punct de ieire, n special dac aceasta este o bucl while sau repeat...until. Aceti programatori se uit rareori n interorul corpului buclei pentru a vedea dac sunt instruciuni break, odat ce au gsit un punct de ieire. Indicaie: Buclele cu un singur punct de ieire sunt mult mai uor de neles. Atunci cnd un programator vede o bucl goal, primul lucru la care se gndete este faptul c lipsete ceva. Mai grav este faptul c n limbaje ca Pascal sau C/C++ unde nu exist instruciuni de terminare ENDloop, este uor s se presupun c urmtoarea instruciune din program este corpul buclei (mai ru, este uor s se uite scrierea caracterului ; care marcheaz sfritul buclei ceea ce face ca urmtoarea instruciune din program s aparin corpului buclei).

46

Indicaie: Buclele goale trebuie evitate. Dac condiia de terminare a buclei produce efecte colaterale, acesta fiind singurul scop al buclei, se vor muta instruciunile care produc efectele colaterale n corpul buclei. Dac bucla trebuie s aib un corp gol, atunci va fi plasat un comentariu de tipul /* nothing */ sau {null statement} n codul scris. Not: prin efect colateral se nelege faptul c n bucla respectiv elemente ale condiiei de terminare sunt folosite altundeva n program (de exemplu se ateapt s se incrementeze o variabil s fie ndeplinit o condiie). Chiar dac nu avem de a face cu o bucl cu corpul gol, trebuie evitate efectele colaterale ale expresiei de terminare a buclei. Atunci cnd altcineva citete codul scris i vede corpul buclei, determin printr-o citire superficial expresia terminal a buclei i ncepe s citeasc codul din corpul buclei. Dac execuia (corect) a corpului buclei depinde de efectul colateral (side effect), cititorul poate fi confuz dac nu a fost avertizat de efectul colateral mai devreme. Prezena efectului colateral (aceasta nsemnnd c expresia dat pentru terminarea buclei calculeaz i alte valori chiar dac bucla trebuie s se termine sau s repete) indic faptul c probabil s-a utilizat o structur de control greit. Vom considera urmtoarea bucl while scris n limbajul C, care este uor de corectat: while ( ( ch = getc (stdin)) != A)

{ }

<< statements>>

O mai bun implementare a acestui fragment de cod poate fi fcut prin utilizarea unei construcii de tipul loop...endloop: for (;;) /* C/C++s infinite loop statement */

ch = getc(stdin); if (ch != A) break;

<< statements >>

O soluie chiar mai bun pentru codul de mai sus este utilizarea noilor construcii ale limbajelor de nivel nalt. Regul: Evitai efectele colaterale n calculul expresiei de terminare a buclei. Vezi i indicaia de la bucle goale. 47

Ca i rutinele, buclele trebuie s prezinte coeziune funcional. Aceasta nseamn c buclele trebuie s satisfac exact aceleai cerine ca cele prezentate la rutine. n acest sens trebuie spus c adesea este foarte tentant s se iniializeze dou zone separate n aceeai bucl. Aceast manier de scriere a programului permite economisirea a cel mult patru instruciuni main la fiecare iteraie ceea ce rareori se simte n execuia programului. Mai mult, acum operaiile din cele dou zone sunt legate ntre ele (fiind n aceeai bucl) i nu se poate schimba dimensiunea uneia fr schimbarea dimensiunii celeilalte. n sfrit dac altcineva care citete codul trebuie s in cont tot timpul c este vorba de dou lucruri distincte fr legtur ntre ele (fiind vorba de dou zone iniializate). n concluzie putem spune c realizarea coeziunii funcionale a buclei este unul din dezideratele urmrite la scrierea codului. Indicaie: Fiecare bucl trebuie s ndeplineasc numai o singur funcie. Programele sunt mult mai uor de citit dac dac ele permit citirea de la stnga la dreapta i de sus n jos (de la nceput la sfrit). Programele care au salturi chiar i numai peste cteva instruciuni sunt mult mai greu de citit. Bineneles instruciunea goto este bine cunoscut pentru posibilitatea de a schimba cursul logic al programului (de a rezolva fluxuri logice complicate), dar este cunoscut faptul c se poate scrie de asemenea cod greu de citit i utiliznd instruciuni structurate. De exemplu un set numeros de instruciuni if, unele cu clauze else altele fr aceast clauz, fac ca programul s fie foarte greu de urmrit din cauza numeroaselor zone de cod care pot fi executate n funcie de rezultatul numeroaselor expresii logice ale if. Regul: Pe ct posibil codul trebuie scris n aa fel nct s poat fi citit de sus n jos.

Regul: Instruciunile nrudite trebuie grupate mpreun i separate de instruciunile cu care nu au legtur prin spaii albe sau comentarii.

48

3.7. Expresii
Atunci cnd este vorba de expresii aritmetice, lucrurile stau foarte diferit n limbaje de programare diferite. Astfel, precedena i asocierea operatorilor este diferit, chiar i operaiile calculate sunt adesea diferite (n limbaje diferite este utilizat adesea acelai simbol pentru operaii diferite sau se utilizeaz simboluri diferite pentru aceeai operaie). Aceste lucruri complic ncercarea de a scrie cod unitar i nelegerea de ctre diferii programatori a programelor scrise n limbaje diferite. Regul imperativ: Instruciunile GOTO, dac apar n program, trebuie verificate de dou ori, de cel puin o pereche de verificatori, n scopul de a verifica dac programul rezultat este la fel de uor de neles ca i codul echivalent fr GOTO. Instruciunile GOTO trebuie folosite numai ca excepii n program sau dup ce s-au epuizat ncercrile de a scrie cod limpede fr instruciuni GOTO. Bineneles, exist cod care este mai uor de citit dac are instruciuni GOTO dect dac nu le are, n general fiind uor de dezvoltat mental un bloc care s care s sugereze utilizarea instruciunilor GOTO atunci cnd exist o soluie clarificat prin utilizarea unei perechi de verificatori. Un domeniu larg n care limbajele de programare difer ntre ele este modul n care acestea trateaz prioritatea operatorilor. De exemplu n C/C++ operatorii << i >> (shift left i shift right) au o prioritate mai sczut dect adunarea i scderea. n Borland Turbo Pascal i Delphi, instruciunile SHL i SHR au o prioritate mai mare dect adunarea i scderea. De asemenea, n multe limbaje, operatorii relaionali au toi aceeai prioritate, pe cnd n alte limbaje acest lucru nu se ntmpl. Cea mai simpl soluie la aceast situaie este de a adopta atitudinea Beginning Programmer Textbook prin acceptarea relaiei de prioritate (aproape) universale ntre adunare, scdere nmulire i mprire i folosirea parantezelor pentru celelalte operaii. n practic aceast atitudine poate da ns gre din cauz c expresiile vor avea foarte multe paranteze i vor fi foarte greu de citit. Ca regul general, cititorul unui program trebuie s poat presupune c exist urmtoarea ierarhie a prioritii operatorilor ntr-un program: operanzii au cea mai mare prioritate. Acetia includ funciile, variabilele (scalarii, elementele matricilor i cmpurile nregistrrilor), constantele, pointerii, etc.; operatorii unari; nmulirea, mprirea i restul (mod); adunarea i scderea; operatorii relaionali (se poate ca prioritatea acestora s difere); operatorii logici (and, or, pot s nu aib aceeai prioritate).

49

Dac doi operatori adiaceni dintr-o expresie aparin la dou clase diferite, atunci se poate renuna la utilizarea parantezelor. Se accept faptul c adunarea, nmulirea, restul (modulo) i mprirea sunt asociative la stnga. Deci dac doi operatori adiaceni sunt: adunarea i scderea sau nmulirea, restul sau mprirea atunci se poate renuna la paranteze. n celelalte cazuri trebuie folosite parantezele pentru a explicita prioritatea. Regul: Prioritatea indicat este [cea mai mare prioritate]: {operanzi} {operatori unari} {*,/,mod} {+,-} {<,<=,=,<>,>,>=} {and, or}. Este de remarcat c nu se va folosi dect asociativitatea la stnga pentru {*,/,mod} i {+,-}. Se va considera c toi operatorii sunt neasociativi i vor trebui utilizate parantezele dac acetia sunt unul dup altul ntr-o expresie. Dac nu se poate adopta prioritatea n concordan cu aceast regul, se vor folosi parantezele pentru explicitarea prioritii. Anumite limbaje de programare utilizeaz o evaluare prescurtat a expresiilor pe cnd altele fac evaluarea complet a acestora. Dac programul scris folosete i depinde de evaluri scurte trebuie comentate aceste lucruri dup fiecare expresie de acest gen. Regul: Dac o expresie depinde de o evaluare prescurtat pentru a da un rspuns corect, trebuie explicitat acest lucru ntr-un comentariu ct mai apropiat de expresie. n multe limbaje de programare este posibil s se realizeze efecte colaterale ntr-o expresie. Acest lucru se poate realiza, de exemplu, prin transferarea unui parametru ca referin a unei funcii sau n cazul n care funcia modific variabile globale. De cnd cele mai multe limbaje de programare au compilatoare la care compilarea depinde de ordinea de evaluare a expresiilor, nu trebuie utilizate niciodat variabile a cror valoare este modificat de efectul colateral sau de o funcie sau operator din aceast expresie (de exemplu s considerm instruciunea n C/C++: Y=X+Y + ++X;). Chiar dac putem presupune c rezultatul va fi corect, un astfel de cod va fi foarte greu de neles. Indicaie: O expresie nu trebuie s produc nici un efect colateral. Sunt cteva excepii evidente la indicaia de mai sus. Scopul unor operatori sau funcii este numai acela de a produce efect colateral. De exemplu operatorii + + i 50

- - din C/C++ i oricare dintre operatori de atribuire. O regul puternic pentru a evita aceasta poate fi cea dat mai jos. Regul: Un program nu trebuie s utilizeze niciodat n aceeai expresie valoarea unei variabile modificat ca rezultat al efectului colateral. Nu se va utiliza niciodat o expresie numai pentru efectul colateral pe care l produce. Programatorii se ateapt ca valoarea unei expresii s aib o anumit semnificaie; nu vor simi nevoia s calculeze valoarea expresiei dac aceasta nu prezint importan. Dac este necesar o expresie care s produc numai un efect colateral atunci trebuie gsite alte ci pentru a obine acest lucru. Exemplu: ce trebuie s fac urmtoarea instruciune n C? (este o secven real de program) *s++ | | *s++ | | *s++ | | *s++ | | *s++;

Regul: Nu se va introduce niciodat o expresie numai pentru efectele colaterale pe care le produce. Exist cteva activiti mecanice cu privire la expresii care s le fac mai uor de citit. Urmtoarele indicaii exprim acest tip de activiti. Indicaie: Nu trebuie lsat spaiu ntre operatorul unar (de exemplu -) i obiectul asupra cruia opereaz. Exemplu: -x *p !b /* n C/C++ */

Indicaie: Trebuie lsat cte un spaiu de fiecare parte a operatorului binar. Exemplu: x = *p + a / b; 51

Indicaie: Operatorii care selecteaz o component a unui obiect de dimensiuni mari (de exemplu . pentru nregistrri/structuri i [] pentru matrici) trebuie s fie adiacent obiectului asupra cruia opereaz. Exemplu: recname.field Indicaie: Obiectele care separ cmpuri (articole) (de exemplu , i ;) trebuie s urmeze imediat obiectul anterior. Dac un al doilea obiect urmeaz dup separator, atunci trebuie pus un spaiu ntre separator i cel de-al doilea obiect. Exemplu: proc ( parm1, parm2, parm3); procedure PascalProc( i:integer; b:boolean ); Indicaie: Simbolurile parantez (de exemplu ( i ), [ i ] i { i } trebuie s aib un spaiu dup paranteza deschis i un spaiu nainte de paranteza nchis. Exemplu: x := f( x + 2 * a[ i,j ] ); Anumite limbaje (C/C++, Algol-68, etc.) au un numr extrem de mare de operatori. Unii dintre acetia sunt chiar destul de criptici i nu au corespondent n alte limbaje (exemplu >>= sau ->*). Dac sunt posibile alternative atunci este bine s se evite astfel de atribuiri n expresii. recptr->field ary[]

3.8. Structura programului

Structura optim a programului difer din pcate de la limbaj la limbaj. Steve McConnell n lucrarea Code Complete spune: cercetrile arat c exist o strns corelaie ntre alinierea programului i posibilitatea ca acesta s fie neles uor. 52

Miaria i alii n lucrarea Program Identation and Comprehension concluzioneaz c indentarea ntre dou i patru caractere este optim pe cnd ali autori consider c o indentare de ase spaii este mai bun. Aceste rezultate sunt probabil date de faptul c ochiul are de parcurs o distan mai mic pentru a citi codul identat i deci ochii cititorilor vor obosi mai puin. Indicaie: Indentarea trebuie s se fac la trei sau patru spaii n structurile de control aliniate, cu meniunea c patru spaii reprezint valoarea optim. Regul imperativ: Dac se utilizeaz tasta TAB pentru identarea codului atunci se va insera un comentariu la nceputul programului care s arate numrul poziiilor fiecrui tab stop. De exemplu: /* This program is formatted using four character position tabstops. */. n Code Complete, Steve McConnell menioneaz mai multe obiective pentru un program scris bine: Structura trebuie s reflecte cu acuratee structura logic a codului. Code Complete se refer la acest lucru ca la Fundamental Theorem of Formatting. Spaiile albe (liniile goale i indentarea) reprezint unealta de baz care se poate utiliza pentru a arta structura logic a programului. Se va reprezenta consecvent structura logic a codului. Anumite convenii de formatare (de exemplu cele utilizate de muli dintre programatorii C/C++) sunt pline de inconsecvene. De exemplu de ce trebuie ca { s fie pe aceeai linie cu un if dar deasupra int main() (sau oricere alt declaraie de funcie)? Un stil bun se remarc prin consecven. mbuntirea lizibilitii programului prin utilizarea corect a identrii. Indentarea folosit incorect poate duce la un program greu de citit. Rezistena la modificri. O schem bun de indentare nu trebuie s foreze programatorul s modifice numeroase linii de cod pentru a realiza o mic modificare a unei linii. De exemplu muli programatori pun un bloc begin.. end (sau bloc {..}) dup o instruciune if chiar dac exist o singur instruciune asociat cu acest if. Acest lucru permite programatorului s adauge cu uurin noi instruciuni la clauza then a instruciunii if fr a mai fi necesare adugarea unor elemente sintactice suplimentare.

Principala unealt pentru crearea structurilor adecvate este spaiul liber (whitespace) - sau lipsa acestuia, aceasta nsemnnd gruparea obiectelor. Urmtoarele aspecte sunt prezentate de McConnell asupra acestui subiect: Gruparea: instruciunile nrudite trebuie grupate mpreun. Instruciunile care sunt cuplate logic nu trebuie s conin spaii albe intercalate arbitrar (linii goale sau indentare inutil). 53

Liniile albe: liniile albe trebuie s separe declaraiile de la nceputul codului, instruciunile legate logic de cele nelegate i blocurile de comentarii de blocurile de cod. Alinierea: obiectele care sunt legate trebuie aliniate mpreun. De exemplu: numele tipurilor ntr-o seciune de declaraii ale variabilelor, operatorii de atribuire ntr-o seciune de instruciuni de atribuire nrudite i coloanele datelor iniializate. Indentarea: indentarea instruciunilor ntr-un bloc mbuntete lizibilitatea (vezi comentariile i regulile de mai sus). Regul: O linie de comentariu trebuie separat cu cel puin o linie goal de linia de cod de deasupra i/sau de dedesubtul ei.

Acest stil promovat aici utilizeaz structura de Pure Blocks sugerat de McConnell. Este schema de structur care este utilizat atunci cnd limbajul folosit accept instruciunile structurate moderne ca if..then..elseif..else..endif. Regul: Schema standard recomandat pentru realizarea codului este formatul Pure Block. Pentru limbajele care nu suport instruciunile moderne de control structurat se va face o emulare a acestor instruciuni. n teorie, o linie de cod surs poate fi orict de lung. n practic sunt numeroase limitri pentru o linie de cod surs. Liniile lungi sunt greu de citit. Limitarea la 80 de caractere este n general rezonabil (dimensiune display, hrtie, etc.). Regul imperativ: Liniile codului surs nu trebuie s depeasc lungimea de 80 de caractere. Dac o instruciune depete 80 de caractere ea trebuie divizat ntr-un punct rezonabil i pus pe dou linii. Pentru expresii logice, mprirea se va face ntr-un punct logic (de exemplu n punctul cu operatorul cu cea mai mic prioritate, din afara parantezelor). Exemplu: if ( ( ( x + y * z) < ( ComputeProfits(1980,1990) / 1.0775 ) ) && ( ValueOfStock [ ThisYear ] >= ValueOfStock [ LastYear ] ) ) 54

<< statements >> endif; Multe instruciuni (de exemplu IF, WHILE, FOR i apeluri de funcii sau proceduri) conin un cuvnt cheie urmat de o parantez. Dac expresia dintre paranteze este prea lung pentru a ncpea pe o linie atunci se va pune paranteza de deschidere i de nchidere pe aceeai coloan cu primul caracter al nceputului instruciunii i se vor identa elementele expresiei rmase. Exemplul de mai sus arat acest lucru pentru o instruciune if. Alte exemple: while ( ( NumberOfIterations < MaxCount ) && ( i <= NumberOfIterations ) ) << Statements to execute >> endwhile; fprintf ( stderr, "Error in module %s at line #%d, encountered illegal value/n", ModuleName, LineNumber ); Indicaie: Instruciunile care sunt mai lungi de 80 de caractere trebuie mprite n dou sau mai multe linii n punctele n care impactul asupra lizibilitii programului este cel mai sczut. Aceast situaie se ntlnete de obicei imediat dup operatorul cu cea mai mic prioritate sau dup virgul. Pentru instruciunile de tip bloc trebuie s se pun ntotdeauna o linie alb ntre linia care conine un if, eleseif, else, endif, while, endwhile, repeat, until, etc., i liniile pe care acestea le nchid. Acest lucru difereniaz clar instruciunile dintr-un bloc de posibilele continuri ale expresiei asociate cu prima linie (cea cu if...). Acest lucru ajut la prezentarea clar a formatului logic al codului surs. Exemplu: if ( ( x = y ) and PassingValue( x, y ) ) then Output( 'This is done' ); endif; 55

Regul: Se va pune ntotdeauna o linie goal ntre instruciunea de nceput de bloc/instruciunea de sfrit de bloc i instruciunile cuprinse n bloc. Dac o procedur, o funcie sau alt unitate de program are o list de parametrii lung, fiecare parametru trebuie plasat pe o linie separat. Exemplu n C/C++: int MyFunction ( int NumberOfDataPoints, float X1Root, float X2Root, float &YIntercept ); x = MyFunction ( GetNumberOfPoints(RootArray), RootArray[ 0 ], RootArray[ 1 ], Solution ); Regul: Dac lista parametrilor actuali sau formali ai unui apel de funcie sau a unei definiii este prea lung pentru a ncpea pe o linie, atunci fiecare parametru va fi aezat pe o linie separat i vor fi aliniai astfel nct acetia s poat fi uor de citit.

3.9. Comentariile i documentarea programului

Un program bun trebuie s aib comentarii de calitate i s fie bine documentat. Este destul de greu s se caracterizeze un comentariu bun. De fapt, este mult mai uor s se dea exemple de comentarii greite. Urmtoarea list prezint comentariile greite care pot aprea ntr-un program (de la cel mai ru spre bine): cel mai ru comentariu este comentariul incorect. Considerm urmtoarea instruciune Pascal: A := 10; { Set 'A' to 11 } o alt greeal care se face este ca un comentariu s explice ce trebuie s fac instruciunea. Exemplul tipic este: A:=10; { Set 'A' to 10 } Chiar dac fa de exemplul precedent comentariul este corect el este inadecvat pentru c nu comenteaz nimic, este redundant i face cititorul s piard timp. Acest comentariu este i greu de ntreinut pentru c o 56

schimbare a valorii (din 10 n 9) impune i modificarea comentariului (dac nu se uit acest lucru); comentariul irelevant. Spunerea unei glume, spre exemplu, n comentariu poate duce la distragerea ateniei; lipsa comentariului; comentariul nvechit (depit) care nu mai este corect (i-a pierdut actualitatea) acest comentariu nu este neaprat incorect. De exemplu un comentariu poate descrie versiunea curent a unui modul iar la actualizarea modulului s-a omis actualizarea comentariului. Steve McConell furnizeaz o list lung de sugestii pentru un cod de nalt calitate. Aceste sugestii cuprind: utilizarea unui stil de comentariu care s nu mpiedice sau s descurajeze modificrile; comentariul trebuie pus pe msur ce se elaboreaz programul; se vor evita comentariile autoironice; se va evita punerea comentariului pe aceeai linie cu instruciunea pe care o explic (vor fi probleme de spaiu); sunt preferate comentariile care descriu blocuri de instruciuni fa de comentariile care descriu instruciuni individuale; comentariile paragrafelor se vor axa mai degrab pe ntrebarea de ce ? dect pe ntrebarea cum?; se vor utiliza comentariile n scopul pregtirii cititorului pentru ceea ce urmeaz; fiecare comentariu trebuie s fie important (se pierde timp cu cititul); se vor documenta codurile surpriz sau cele cu trucuri; se vor evita prescurtrile; comentariile trebuie s se refere ct mai strict la codul pe care-l descriu; comentariile trebuie s explice parametrii funciilor, revendicarea asupra acestor parametrii, unde au fost introdui, scoi sau parametrii de in/out. comentariile trebuie s descrie limitrile rutinelor, atribuiri i orice efect colateral. Regul: Toate comentariile trebuie s fie de nalt calitate i s descrie aciunile codului la care se refer ntr-o manier concis. Regul imperativ: Toate codurile trebuie s fie actualizate. Dac programatorul face modificri codului, atunci acel programator este responsabil pentru actualizarea comentariilor afectate de aceste modificri.

57

3.10. Codul neterminat

Codul neterminat reprezint seciunile de cod care (parial) ndeplinesc anumite sarcini dar care necesit activitate viitoare suplimentar pentru a completa setul de faciliti, n aa fel nct s fie fcut robust sau s fie nlturate anumite erori cunoscute din cod. De obicei programatorii plaseaz n acest cod comentarii de tipul: This needs more work, Kludge ahead, etc. Problema cu aceste comentarii este c ele sunt adesea uitate. De obicei atunci cnd programul eueaz ntr-o zon din aceast seciune, comentariile amintite sunt gsite i problemele sunt corectate. n mod teoretic nu trebuie pus un astfel de cod n program dar de regul el este prezent n programele de dimensiuni mari. Codul neterminat se mparte n general n patru categorii: cod nefuncional, cod parial funcional, cod suspect i cod care necesit completri. Codul nefuncional poate fi un rest de cod sau un driver care trebuie nlocuit n viitor. Acest cod este cu totul nefolositor i din fericire gravitatea acestui lucru mpiedic ignorarea lui. Nimeni nu poate scpa astfel de erori ele aprnd nc de la primele teste. Codul parial funcional este poate cea mai mare problem. Acest cod funcioneaz suficient de bine ca s treac testele simple dar conine nc defecte serioase care necesit s fie corectate. Cel mai adesea aceste defecte sunt cunoscute. La codul suspect programatorul nu poate defini problema dar bnuiete c exist una. Acest cod trebuie verificat mai trziu pentru a vedea dac este corect. A patra categorie, codul care necesit completri reprezint problema cea mai puin serioas. De exemplu pentru a termina o versiune un programator poate utiliza un algoritm simplu n locul unuia complex i mai rapid. El va face un comentariu de tipul: This linear search should be replaced by a hash table lookup in a future version of software. Dei nu este necesar s corecteze problema este bine s-o fac n viitor. Pe lng aceste patru categorii mai exist i a cincea categorie, documentarea, care se refer la schimbrile fcute programului ce afecteaz documentaia corespunztoare (ghidul utilizatorului, documentele de proiectare, etc.). n continuare se propune un mecanism pentru trata aceste cinci clase de probleme. Orice apariie a codului neterminat va fi precedat de un comentariu care va avea una din urmtoarele forme (unde @ semnific delimitatorii standard pentru comentariu n limbajul dat iar _ semnific un singur spaiu): @_#defect#severe_@ @_#defect#functional_@ @_#defect#suspect_@ @_#defect#enhancement_@ @_#defect#documentation_@ Este important s se utilizeze numai litere mici i s se verifice corectitudinea scrierii pentru a putea cuta apoi aceste mesaje cu un editor de texte sau cu o unealt de cutare cum este grep. Exemple n diferite limbaje: Pascal/Delphi: (* #defect#severe *) { #defect#enhancement } 58

(* #defect#functional *) { #defect#suspect } { #defect#documentation } C: /* #defect#severe */ /* #defect#suspect */ /* #defect#documentation */ C++: /* #defect#functional */ // #defect#enhancement //

BASIC:

' #defect#functional '

Assembly (80x86):

; #defect#suspect ;
Ada:

-- #defect#enhancement --- #defect#documentation --

Regul imperativ: Dac un modul conine anumite defecte care nu pot fi remediate imediat din cauza timpului sau a altor constrngeri, n program se vor insera comentarii standard, naintea codului n aa fel nct problema s poat fi localizat uor n viitor. Cele patru @_#defect#severe_@, comentarii standardizate sunt: @_#defect#functional_@, @_#defect#suspect_@, @_#defect#enhancement_@ i @_#defect#documentation_@ unde unde @ semnific delimitatorii standard pentru comentariu n limbajul dat iar _ semnific un singur spaiu. Scrierea i spaierea trebuie s fie exact la fel cu cea prezentat n aa fel nct aceste comentarii s poat fi uor gsite cu un editor de texte.

59

3.11. Referine ctre alte documente

n multe situaii o seciune a codului poate fi intrinsec legat de alte documente. De exemplu, se pot face referiri la ghidul utilizatorului sau la documentul de proiectare n comentariile din program. Pentru localizarea simpl a acestor referine se va utiliza o metod similar cu cea de raportare a defectelor. Forma comentariului va fi: @ text #link#location text @ unde @ semnific delimitatorii standard pentru comentariu n limbajul dat iar text este opional (este indicat s se foloseasc comenzi html pentru a avea hiperlegturi la documentul specificat). Location specific documentul i seciunea unde se gsete informaia asociat. Exemple: C/C++: /* #link#User's Guide Section 3.1 */ // #link#Program Design Document, Page 5 // Pascal: (* #link#Funcs.pas module, "xyz" function *) { <A HREF="DesignDoc.html#xyzfunc"> #link#xyzfunc </a> } Indicaie: Dac un modul conine referine la alte documente atunci trebuie inserat un document de forma @ text #link#location text @ care furnizeaz referinele la celelalte documente. n acest document @ semnific delimitatorii standard pentru comentariu n limbajul dat iar text este opional (rezervat de regul pentru comenzi html) i location specific documentul i seciunea unde se gsete informaia asociat.

60

CAPITOLUL 4 VERIFICAREA PROGRAMELOR

4.1. Introducere
n procesul complex al elaborrii programelor, programatorii comit deseori erori. Acestea pot avea printre cauze: slaba pregtire profesional a programatorilor (necunoaterea limbajului, necunoaterea mediilor de programare, necunoaterea metodelor i tehnicilor folosite n programare); neglijen n elaborarea programelor (folosirea unor specificaii incomplete, omiterea unor enunuri n procesul de transformare a specificaiilor de definire a problemei n program calculator) etc. Rezult c programul obinut n urma codificrii va conine erori care trebuie eliminate nainte de finalizarea activitii. Se impune deci ca necesar verificarea corectitudinii programelor, care const n analizarea concordanei ntre transformrile executate de program i specificaiile programului. Specificaiile programului se exprim prin relaii ntre variabilele sale care, n scopul formalizrii i automatizrii procesului de verificare, au o form matematic. Exist dou tipuri de specificaii:

de intrare: relaii ntre datele de intrare ale programului; de ieire: relaiile privind rezultatul execuiei programului.

Aceste specificaii sau relaii ntre variabilele programului se mai numesc aseriuni. Ele trebuie s caracterizeze programul ntr-o manier clar, simpl i complet. De exemplu, s considerm un program care realizeaz mprirea a dou numere ntregi pozitive x, y i produce ctul q i restul r. Aseriunea de intrare este: (x>=0) i (y>0). Aseriunea de ieire este: (x=qy+r) i (0<=r<y). n raport cu noiunea de aseriune, un program este corect dac la terminarea execuiei lui, aseriunile sale de ieire sunt adevrate, n ipoteza c aseriunile de intrare sunt adevrate. n general se spune despre un program c este total corect dac: (a) se termin; (b) rezultatele furnizate sunt cele ateptate de utilizator.

61

Aplicarea unei metode analitice de verificare a corectitudinii programelor impune deci introducerea unui model al programului pe baza cruia condiiile (a) i (b) pot fi formulate riguros. Acelai model trebuie totodat s pun n eviden caracteristicile generale ale programului. n practic procedura de demonstrare a corectitudinii programului se separ n dou etape: corectitudinea parial: se arat c programul este corect, cu condiia s se termine; corectitudinea total: n plus se arat c programul se termin.

Termenul de fiabilitate a unui program, spre deosebire de cel de corectitudine, nu are nc o definiie formal i o mare parte din lucrrile aprute n acest domeniu nu se pot generaliza. Dei n domeniul fiabilitii componentelor hardware sau nregistrat progrese importante, acestea nu se pot aplica programelor din cauza diferenelor de caracteristici i comportri ce exist ntre piesele hardware i programe. n domeniul hardware, fiabilitatea unei componente se definete ca probabilitatea de funcionare corect ntr-o perioad dat de timp. n general se presupune c piesa hardware este perfect la nceput i se deterioreaz cu timpul, crend o probabilitate de defect din ce n ce mai mare. Acesta nu este cazul programelor care sunt compuse din instruciuni, ce nu mbtrnesc (nu se poate vorbi deci de uzur fizic n programare). Produsele program nu se defecteaz i nici nu sufer de uzur fizic. Erorile de programare sunt cauzate de combinarea incorect a instruciunilor, chiar de la nceput programul fiind pus n funciune cu erori. Eliminarea unei erori nu diminueaz ntotdeauna numrul total al erorilor din program, la corectarea unei erori se pot introduce altele noi. Corectarea programului nu este aa de simpl ca la o pies hardware, care n cele din urm poate fi nlocuit. De asemenea, fiabilitatea produselor program poate fi privit ca o msur calitativ a programelor i se poate evalua n acest sens din dou puncte de vedere: numrul erorilor din program. Trebuie ns tiut care este acest numr, ceea ce nu este ntodeauna posibil. Se poate presupune c frecvena de detectare a erorilor n cursul funcionrii sale pe o perioad de timp, poate fi utilizat pentru a determina numrul erorilor n program. Metoda nu se poate ns generaliza. calitatea serviciului adus utilizatorului. Fiabilitatea n acest caz apare ca probabilitatea ca la execuia programului cu anumite date de intrare s se obin rezultatul ateptat. Ea este dependent ns de datele de intrare i de mediul n care se execut programul. Aceast definiie nu se bazeaz pe numrul de erori din program: anumite proceduri pot conine un numr ridicat de erori, dar fiabilitatea programului poate fi ridicat, dac datele de intrare nu activeaz acele proceduri. De asemenea, fiabilitatea n acest caz nu este o proprietate inerent programului: acesta poate fi corect, dar funcionarea lui incorect se poate datora unei erori din sistem, compilator, unitate central etc.

62

4.2. Metode de verificare a corectitudinii programelor

4.2.1 Metoda aseriunilor invariante nc din 1963, Goldstine i von Neumann au artat c un program poate fi verificat, cel puin n principiu, dac se descriu strile tuturor variabilelor din program, dup fiecare instruciune sau cel puin, n anumite puncte ale programului. McCarthy J. McCarthy, Towards a mathematical science of computation, Proc. IFIP Congr.,1962 folosete o metod similar prin definirea unui vector de stare: fiecare locaie din memorie este privit ca o locaie dintr-un vector de stare, iar fiecare operaie este considerat ca o transformare a vectorului de stare n alt vector de stare. McCarthy a introdus un formalism pentru definirea programului ca o funciune recursiv, iar problema de verificare a corectitudinii o reduce la o problem a funciilor, recursiv, la care aplic metoda induciei recursive (un set de axiome care transform o funcie recursiv n alta echivalent). Naur P. Naur, Proof of algorithms by general snapshots, BIT, 1966 generalizeaz procedeul precedent, considernd un vector de stare cu valori simbolice, adic a, b, c n loc de 1, 0, 5 etc. Operaiile din program produc expresii simbolice, de tipul a+b-c, ca noi elemente ale vectorului de stare, iar n final, se obin transformrile ce au loc asupra variabilor de intrare. O simplificare important a acestor procedee este adus de Floyd R. W. Floyd, Assigning meanings to programs, Mathematical Aspects of Computer Science, 19 (1967) care dezvolt aa-zisa metod a aseriunilor. Ideea este de a urmri numai transformarea a ctorva variabile (cele semnificative) i a elabora relaii numai pentru aceste variabile i n anumite puncte eseniale din program. Deci, secvena vectorului de stare se reduce la relaiile ntre variabilele mai importante ale programului, relaii numite aseriuni. Problema verificrii corectitudinii programului se reduce la demonstrarea validitii aseriunilor: dac fiecare aseriune este adevrat, atunci programul este corect. Nu exist ns nici o procedur de formulare i localizare a aseriunilor. Ele depind de program i de priceperea i experiena celui care demonstreaz. Aceasta se numete metoda aseriunilor invariante pentru c n scopul demonstrrii corectitudinii ciclurilor se introduc aseriuni care se comport identic ori de cte ori ajunge controlul la ele, adic sunt invariante. Existena ciclurilor imprim i un caracter inductiv metodei aseriunilor, de aceea mai este cunoscut i sub numele de metoda inductiv a aseriunilor. S prezentm aceast metod ntr-o manier mai sistematic. Un program este un set finit i ordonat de instruciuni, cu prima instruciune de start i ultima instruciune de stop, restul instruciunilor fiind de asignare, selecie, salt sau neoperaionale. Prima aseriune a0, poart numele de aseriune de intrare i se ataeaz punctului de start al programului. Ultima aseriune, an, se numete aseriune de ieire i se ataeaz instruciunilor de stop. Aseriunea de intrare specific domeniului variabilelor de intrare i relaiile dintre ele; aseriunea de ieire exprim rezultatul dorit. Fie secvena (S1,S2, ..., Sn) de instruciuni din program, cu aseriunea a1 ataat instruciunii S1 i aseriunea an ataat instruciunii Sn. Se spune c secvena este corect (sau verificat) dac presupunnd c a1 este adevrat, se arat c an este adevrat, dup execuia secvenei (S1,S2, ...Sn). Demonstrarea corectitudinii programului const n alegerea i ataarea aseriunilor de intrare, intermediare i de ieire n diferite puncte ale 63

programului i verificarea tuturor secvenelor din program prin construirea de condiii de verificare. Metoda aseriunilor se aplic astfel: a) se alege un subset I de instruciuni din program pentru care se ataeaz aseriuni; b) se ataeaz aseriuni pentru fiecare instruciune din subsetul I. Definirea aseriunilor este partea cea mai dificil a procesului de demonstrare a corectitudinii programului cu att mai mult cu ct nu poate fi automatizat. Ea depinde de structura programului, de intuiia i experiena programatorului, aa cum se ntmpl la alegerea ipotezelor n inducia matematic. Definirea aseriunilor depinde, de asemenea, de setul de instruciuni I; c) se construiesc condiiile de verificare pentru fiecare secven de instruciuni ce pornete de la o aseriune ak la alt aseriune ak+1 (fr alte aseriuni ntre ele). O condiie de verificare este de forma: ak i (asignri) i (condiii de selecie) => ak+1, unde signrile sunt instruciuni de atribuire din cadrul secvenei, iar condiiile logice aparin instruciunilor de selecie ce definesc secvena respectiv. Construirea condiiilor de verificare poate fi n ntregime automatizat; d) se demonstreaz corectitudinea parial a programului prin demonstrarea validitii condiiilor de verificare; e) se demonstreaz corectitudinea total a programului dac se arat c programul se termin.

4.3. Testarea i depanarea programelor

4.3.1. Noiuni de baz Programele obinute prin codificare pot conine erori. Este deci necesar depistarea i eliminarea acestora. Cum programele complexe se realizeaz pe module, fiecare modul trebuie testat mai nti separat pentru a i se elimina erorile iar dup acea testat ca o component a unui program complex. Spunem c se procedeaz la integrarea modulului i testarea de ansamblu a programului complex (care n realitate se compune din mai multe programe ce comunic ntre ele pe baz de parametri, pe baz de fiiere etc.). Erorile detectate n faza de testare trebuie eliminate. n limbajul uzual identificarea erorilor i corectarea programului este cunoscut i sub numele de depanare. Testarea constituie totodat i o metod de verificare a corectitudinii programului pentru un set limitat de date de intrare. Dac setul de date de intrare este complet, adic acoper toate cazurile posibile, atunci se poate spune c programul este corect. Practic nu se pot testa toate combinaiile posibile pentru datele de intrare i de acea depanarea rmne o metod ce garanteaz, corectitudinea programelor. 64

Avantajul folosirii metodei testrii rezult din faptul c programul se execut n mediul su real, corespunztor utilizrii lui finale i deci se poate urmri comportamentul programului i din alte puncte de vedere dect al rezultatelor propuse: timp de rspuns, blocaje, memorie ocupat etc. Se poate evalua de asemenea performana programului. Se poate spune c testarea include dou etape: analiza structurii programului pentru selectarea datelor de intrare: testare static; execuia programelor cu date de intrare i observarea rezultatelor: testarea dinamic. Principalul motiv pentru elaborarea de tehnici de testare este costul tot mai ridicat al produselor program. Boehm arat c, n prezent costul fazei de testare a produselor program reprezint aproximativ 48% din costul total de elaborare. Cu ct eroarea este detectat mai trziu n fazele de elaborare a produsului program cu att costul eliminrii este mai mare. Alberts D. S. Alberts, The economics of software, Infotech State of Art Report, 1978 stabilete un factor cu care trebuie multiplicat costul eliminrii unei erori n diferite faze, i anume: concepere program testare modul testare funcie testare sistem ntrebuinare sistem 1 4 9 15 30

4.4. Strategii de testare

Cele mai cunoscute strategii de testare sunt: testarea de jos n sus (bottom-up); testarea de sus n jos (top-down); metoda mixt. Testarea de jos n sus este metoda clasic de testare, ea const n testarea modulelor, urmat de testarea ansamblelor de module, urmat n final de testarea sistemului ca un tot unitar. Testarea modulelor se face separat, pentru fiecare modul n parte, ntr-un mediu artificial care s asigure executarea funciilor modulului. Ea este cu att mai uor de efectuat cu ct modulele sunt mai simple i mai mici, iar funciile pe care le execut sunt relativ independente. n mod normal testarea modulelor trebuie s fie ct mai complet pentru a fi siguri de execuia corect a funciilor acestora. La fiecare modul trebuie fcut mai nti testarea de funcionalitate, adic trebuie verificat dac modulul ndeplinete funcia sau funciile sale. Pentru aceasta se face o list a funciilor modulului i se stabilesc date de test care pun n eviden comportarea modulului n condiii normale de lucru. De exemplu, pentru un modul de verificare sintactic a comenzilor utilizatorului se introduc ca date de intrare toate comenzile din lista comenzilor posibile. Se testeaz apoi posibilitatea de detectare de ctre modul a datelor eronate, ce nu corespund funciei sale. n cazul exemplului precedent se introduc comenzi voit eronate pentru a verifica dac modulul reacioneaz cu mesajul de eroare adecvat. n final se testeaz comportarea modulului n condiii extreme de lucru sau la limit. De exemplu pentru un modul ce prelucreaz datele dintr-un fiier se testeaz i urmtoarele cazuri: fiier vid, fiier cu un singur articol, fiier pe mai multe volume. 65

Testarea modulelor trebuie efectuat de o manier sistematic, adic pentru fiecare modul se face o list a testelor efectuate i a rezultatelor obinute. Aceasta faciliteaz procesul ulterior de depanare a modulelor. Un subsistem este compus din mai multe module. Testarea subsistemului presupune verificarea interfeelor dintre module. Sistemul este un ansamblu de mai multe subsisteme. Testarea sistemului nseamn verificarea comunicrii dintre subsisteme. n general testarea sistemului nu poate fi exhaustiv. Ea presupune verificarea sistemului din punct de vedere al specificaiilor sale, dar i din punct de vedere al performanelor: timp de rspuns, capacitate de lucru, etc. Testele de sistem pot ocupa pn la 30% din timpul total de realizare al proiectului. Dezavantajul testrii de sus n jos rezult din dificultatea de a testa modulele separat, deoarece trebuie simulat interaciunea modulului cu alte module ce asigur datele de intrare corespunztoare. Se apreciaz c rutinele suplimentare de simulare pot reprezenta pn la 50% din cadrul modulului testat, ceea ce reprezint un efort n plus apreciabil. De asemenea, este foarte dificil de stabilit datele de test pentru sistemul final datorit numeroaselor subsisteme ce l compun. Erorile care pot s apar n acest caz sunt legate de modul de comunicare ntre module: date neutilizate, date iniializate n mai multe module, date modificate n diferite module, etc. Pentru o mai uoar depanare, testarea interconectrii modulelor se face treptat urmrind procesul de elaborare al programului. Testarea de sus n jos este posibil numai n cazul unei conceperi descendente a sistemului. n acest caz se ncepe cu testarea modulului principal (de baz) i a primului nivel subordonat de rutine. Apoi pe msur ce avanseaz realizarea proiectului se continu cu testarea sistemului obinut prin adugarea nivelului doi i aa mai departe. Pentru efectuarea testrii vor fi utilizate module fictive, din niveluri inferioare, nerealizate nc, dar apelate de nivelurile superioare. Modulele nerealizate nc, dar apelate de modulele din nivelurile superioare conin doar instruciunea de revenire la apelant. Eventual pot tipri un mesaj c au fost apelate, sau pot furniza unele date care apar ca rezultatul unei prelucrri. Interconectarea progresiv faciliteaz n mod apreciabil elaborarea sistemului final, erorile finale fiind foarte puine i uor de depanat. Mai multe erori de interconectare a modulelor pot fi eliminate naintea procesului de testare dac se construiete matricea parametrilor de interconectare. Pentru aceasta se face o list a tuturor parametrilor de intrare/ieire pentru toate modulele i o list a modulelor. Se construiete apoi matricea M de interconectare, astfel: M(pi,mj) = x, unde pi este parametrul de intrare/ieire numrul i; mj este modulul numrul j; x poate fi: I dac parametrul pi este iniializat n modulul mj, U dac parametrul pi este utilizat n modulul mj, Z - dac parametrul pi este modificat n modulul mj. Odat construit matricea M se observ foarte uor urmtoarele tipuri de erori: un parametru nu este iniializat; un parametru este transmis unui modul, dar neutilizat; un modul modific un parametru i acest lucru nu este permis etc. 66

Avantajele testrii de sus n jos sunt urmtoarele: testele de sistem se efectueaz pe msura elaborrii lui, deci n final sunt reduse; se testeaz mai nti interfaa dintre module eliminndu-se de la nceput erorile dificil de detectat; erorile sunt localizate n module noi adugate, deci eliminarea lor este mult uurat.

Prin efectuarea testrii n paralel cu elaborarea proiectului, pe total se reduce considerabil timpul de elaborare al unui produs program (uneori cu aproape o treime). Metoda de testare mixt presupune aplicarea simultan a celor dou metode precedente de testare. Uneori nu este posibil de a utiliza module fictive necesare nivelelor superioare i atunci se impune realizarea i testarea separat a unor module din nivelele de jos ale ierarhiei. n acest caz metoda testrii de sus n jos se mpletete cu cea a testrii de jos n sus, rmnnd predominant testarea descendent. Prin urmare se ncepe elaborarea proiectului ntr-o manier descendent, dar simultan se realizeaz module din nivelul de baz al ierarhiei. n acest caz testarea descendent se desfoar n paralel cu cea ascendent. Acest procedeu de concepere i testare s-a dovedit eficient n elaborarea multor produse program. Alegerea strategiei de testare depinde de modul de realizare al proiectului. ntr-o abordare de realizare ascendent, testarea de jos n sus este cea mai potrivit i reciproc testarea de sus n jos se aplic unui proiect realizat prin metoda descendent. Metoda de testare de jos n sus se poate aplica practic pentru orice sistem indiferent de modul de realizare, cu observaia c pentru sistemele elaborate prin metoda descendent aceasta nu se poate aplica dect dup obinerea sistemului final (spre deosebire de testarea ascendent, care n acest caz, urmrete realizarea proiectului).

4.5. Moduri de testare

Testarea poate fi: funcional sau structural. Testarea funcional (blak-box) are drept scop verificarea specificaiilor modulului: nu se urmrete modul de realizare al modulului ci numai comportamentul lui exterior, adic felul n care i ndeplinete funcia sa. Datele de test se construiesc din specificaiile de definiie ale modulului. Modulul este privit ca o cutie neagr, fr a avea acces la codul su intern, n care se introduc date de intrare i se obin date de ieire. Pe baza analizei datelor de intrare i ieire se deduce dac funcia modulului este realizat corect sau nu. Testarea funcional se aplic mai ales sistemelor finale, a cror complexitate nu permite realizarea testelor pe baza structurii interne i deci nu se pot verifica dect pe baza specificaiilor de definiie. Testarea structural (white-box) presupune analiza modului de realizare a programului i selectarea datelor de test pe baza structurii lui interne. Prin setul de date de intrare se caut s se parcurg toate drumurile grafului asociat programului, dac aceasta este posibil, dac nu, se testeaz drumurile critice ale programului. Acest mod de testare se aplic foarte uor la nivel de modul i permite detectarea erorilor de 67

codificare ale modulului. n general, n practic se aplic mai mult testarea structural pentru c programatorul cunoate n detaliu modulul pe care l-a elaborat. Testarea funcional are avantajul de a detecta implementarea incorect (neconform cu specificaiile) a unor funcii. Spre deosebire de aceasta, testarea structural are avantajul detectrii unor erori de codificare a modulului ce nu in de definirea specificaiilor. Pentru o bun detectare a erorilor este bine s se aplice simultan ambele moduri de testare. Testarea structural poate fi automatizat n sensul elaborrii unor sisteme de analiz a structurii programelor i de elaborare a datelor de test.

4.6. Metodologia testrii structurate

Odat cu apariia conceptelor ingineriei programrii s-a dezvoltat o nou metodologie a procesului de testare, cunoscut sub numele de metodologia testrii structurate. Ea se bazeaz n special pe aplicarea principiilor programrii structurate n activitatea de programare, principii ce includ procesul de testare n tot ciclul de elaborare al produselor program. Iniial testarea era vzut ca o etap distinct dup elaborarea produsului final, adic dup ce totul a fost codificat. n acest caz detectarea unor erori introduse chiar n faza de concepere devine foarte costisitoare, impunnd modificri de cod, uneori radicale. Metodologia testrii structurate presupune efectuarea de teste, controale i inspecii pe tot parcursul de elaborare al produsului program: definire specificaii, concepere, codificare. n acest fel testarea devine o parte integrant a procesului de elaborare a programului. Metodologia testrii structurate include urmtoarele tehnici de testare: analiza de concepere; testarea static (analiza static); testarea dinamic; generarea datelor de test. 4.6.1. Analiza de concepere Orice program este elaborat pornind de la specificaiile sale i orice eroare introdus la acest nivel se va reflecta n codul final. De aceea analiza de concepere trebuie s nceap cu verificarea specificaiilor proiectului. Din analiza specificaiilor se pot detecta erori referitoare la funciile programului (specificaii eronate) sau erori de logic (specificaii implementate incorect). n practic specificaiile sunt rareori prezentate de o manier formal. De cele mai multe ori ele sunt incomplete, ambigue, vagi etc. i foarte multe erori sunt generate de specificaii incorecte. Pentru elaborarea unor specificaii corecte este necesar ca acestea s se prezinte ntr-o manier formalizat n scopul de a putea fi analizate i testate pentru validitatea lor. Parnas D. L. Parnas, A technique for software module specification with examples, CACM, 15, 5 (1972) propune un sistem de prezentare formal a specificaiilor. Specificaiile se reprezint ntr-o form de procese de intrare/ieire iar sistemul de specificat se consider ca o secven de procese ce interacioneaz. Fiecare proces este echivalent cu o main secvenial a crei comportare este dat de relaiile dintre intrri, ieiri i stri. Procesele se specific static prin expresii logice i algebrice ce permit verificarea i testarea lor. 68

Alt metod de prezentare formal a specificaiilor este un limbaj special de descriere a lor. Un astfel de limbaj a fost dezvoltat n cadrul unei metodologii de control a specificaiilor. Limbajul RSL (Requrements Statement Language) Crocus, Systemes dexploitation des ordinateurs, Dunod, 1975 este un limbaj ce suport instruciuni de definire a specificaiilor i informaiei de organizare a lor, iar sintaxa i semantica lui sunt neambigue i analizabile pe main. Dup verificarea specificaiilor se trece la revizuirea procesului de concepere n scopul de a detecta erori de funcionare nainte de a trece la codificarea propriu-zis. Printr-o nou parcurgere a specificaiilor de realizare conceptorul poate detecta multe erori datorate, de exemplu, unor presupuneri greite. Revizuirea proiectului poate fi fcut de conceptor nsi, dar experiena arat c aceast reparcurgere a procesului de proiectare este mai eficient dac este realizat de ctre o alt persoan din grupul de conceptori. Aceast inspecie nu are drept scop gsirea de noi soluii ci numai detectarea de erori n soluia prezentat. Revizuirea codului nu este o operaie simpl, dar rezultatul ei este foarte important, multe erori a cror detectare dup elaborarea proiectului ar fi foarte costisitoare sunt eliminate din prima faz a proiectului. n ceea ce privete automatizarea procesului de verificare a fazei de concepere, Boehm B. W. Boehm, R. K. McCleam, D. B. Urfig, Some experience with automated aids to the design of large-scale reliable software, IEEE Trans. On Soft. Eng. SE-1 (1975) prezint rezultatele obinute prin utilizarea unui verificator al Consistenei Procesului de Concepere (DACC). Utilizatorul verificatorului trebuie s specifice pentru fiecare modul un antet ce cuprinde aseriuni referitoare la: sursa fiecrei variabile de intrare; destinaia fiecrei variabile de ieire; dimensiunea fiecrei variabile; tipul fiecrei variabile; intervalul de valori al fiecrei variabile etc.

El a fost aplicat, de exemplu, unui sistem de 186 module cu 514 aseriuni de intrare i 453 aseriuni de ieire. Verificatorul DACC a descoperit apte erori n privina aseriunilor, 25 de nepotriviri de terminologie i 200 de situaii n care diferite nume erau utilizate incorect ca intrri i ieiri. 4.6.2. Analiza static Analiza static se refer la verificarea codului programului cu scopul de a detecta erori de structur, erori de sintax i de a urmri dac au fost respectate construciile standard ale limbajului de codificare. Analiza static nu implic execuia programului, aceasta urmrind analiza structurii codului. Informaiile ce se obin n urma analizei statice pot fi: variabile neiniializate; apeluri de funcii sau subrutine cu parametri incoreci; variabile neutilizate; poriuni de cod ce nu vor fi executate; poriuni de cod redundante etc. Nu pot fi detectate erorile legate de execuia programului, de exemplu erorile de referire la elementelor unui tablou. Analiza static se efectueaz prin simpla parcurgere a listingului programului. Evident aceast analiz este mult facilitat dac programul este lizibil; acest lucru 69

depinde de limbajul de programare utilizat i de tehnica de programare aplicat. Programele structurate cu comentarii i nume de variabile i subrutine ce reflect funcia lor sunt mai uor de verificat dect programele nestructurate. Parcurgerea codului poate fi fcut de programatorul elaborator sau de alt programator (Walk-throughs). De exemplu, pentru apelul unei subrutine se verific dac: numrul parametrilor este corespunztor; parametri sunt transmii corect; tipul parametrilor corespunde utilizrii lor. Pentru instruciuni de selectare de tipul: IF X=0 THEN DO .... END se verific: dac testul trebuie fcut pe variabila X; dac blocul de instruciuni de executat DO .... END corespunde condiiei testate. Se apreciaz c 90% din totalul erorilor sintactice pot fi eliminate prin analiza codului. Analiza static poate fi automatizat i exist deja mai multe tipuri de analizoare de cod. n concluzie analiza de cod este o metod foarte eficient i economic de detectare a erorilor nainte de punerea n exploatare a programului final. 4.6.3. Testarea dinamic Testarea dinamic nseamn execuia programului cu diverse seturi de date de intrare i compararea rezultatelor cu cele ateptate. Prin testarea dinamic se detecteaz erori de execuie ale programului, ce nu pot fi descoperite prin analiza static. Testarea dinamic cuprinde trei etape: pregtirea testelor; execuia testelor; evaluarea rezultatelor. Pregtirea sau planificarea testelor se refer la stabilirea funciilor de testat, a datelor de testare corespunztoare acestor funcii, eventual la inserarea unor instruciuni suplimentare de tiprire a unor rezultate pariale i la stabilirea rezultatelor ce trebuie obinute. Executarea testelor presupune introducerea datelor de intrare n sistemul testat, execuia programului i nregistrarea rezultatelor. Evaluarea rezultatelor se refer la compararea rezultatelor obinute n urma execuiei programului, cu cele stabilite n faza de pregtire a testelor. n timpul testrii dinamice se pot nregistra statistici asupra utilizrii variabilelor, execuiei anumitor secvene de instruciuni sau a unor rutine etc. statistici ce pun n eviden comportarea programului pentru diferite seturi de date de intrare. Se pot trage astfel concluzii asupra caracteristicilor de performan ale programului. Stabilirea datelor de test nu este o operaie uoar. S-au experimentat diverse metode de selectare a datelor de test i anume: testarea drumurilor: datele de test se aleg n aa fel nct s se parcurg cel puin o dat fiecare drum din graful programului; testarea condiiilor de selectare: fiecare condiie de selectare s fie traversat cel puin o dat; testarea funcional: fiecare funcie implementat de program s fie testat cel puin o dat. 70

Practica arat c testarea funcional este cea mai eficace, n sensul c n raport cu celelalte moduri de testare detecteaz cel mai mare numr de erori din orice program. Alegerea datelor de testare trebuie fcut avnd n vedere deopotriv funciile procedurilor care definesc programul analizat i relaiile ce se stabilesc ntre programele aparinnd aceluiai domeniu de aplicaie. Spre exemplu, la testarea unui program care realizeaz controlul datelor i crearea unui fiier cu datele corecte, avnd ca suport discul magnetic, prin alegerea datelor de testare se va urmri totodat obinerea la ieire setul de date necesar testrii altor programe care folosesc n intrare fiierul astfel obinut. Fairley R. E. Fairley, Static analisys and dynamic testing of computer software, Computer, April (1978) propune o metod interesant de nregistrare a istoriei execuiei programului pentru a fi analizat ulterior n caz de nefuncionare normal. Se nregistreaz urmtoarele: execuia instruciunilor de asignare, selecie i GOTO; apelul procedurilor cu valorile parametrilor de intrare i ieire; valorile indecilor de acces n structuri de tablou.

Metoda nu este practic pentru programele complexe din simplul motiv c datele de nregistrat devin numeroase. Sistemele de testare dinamic bazate pe aseriuni examineaz fiecare instruciune a programului i pe baza lor prelucreaz condiiile din cadrul aseriunilor. Aseriunile pot fi active sau pe post de comentariu. n cazul n care sunt active ele sunt prelucrate i se tiprete un mesaj de avertizare n cazul n care rezultatul evalurii nu este adevrat. Dac sunt pe post de comentariu atunci sunt ignorate de sistemul de testare. 4.6.4. Generarea datelor de test Problema generrii datelor de test este urmtoarea: fiind dat o poriune de cod dintr-un program s se genereze datele de test care provoac la execuia programului i execuia acelei poriuni de cod, pe toate ramurile sale de program i n toate combinaiile dorite. Problema nu este simpl: practic nu exist algoritm care s genereze date de test pentru atingerea unei poriuni de cod dintr-un program. De aceea problema generrii datelor de test se reduce la una din urmtoarele situaii: testarea exhaustiv: se propune testarea programului pentru toate datele de intrare posibile. Acest lucru nu este posibil dect pentru programe simple. Acelai termen se folosete i pentru cazul n care se ncearc parcurgerea fiecrui drum din program cel puin o dat. Acest lucru este de asemenea greu de realizat. De exemplu o bucl care conine 5 drumuri i este parcurs de 100 de ori posed 5100 secvene diferite; testarea selectiv: datele de test se selecteaz de ctre conceptorul programului care i cunoate n detaliu structura i funciile sale.

71

Se cunosc dou tehnici mai importante pentru generarea datelor de test: generarea de date de test pentru parcurgerea drumurilor; generarea de date de test aleatoare. n cazul primei tehnici se selecteaz mai nti drumurile din program ce trebuie testate. Aceast selectare se poate face manual, de ctre programator, sau automat pe baza grafului programului. Etapa urmtoare este generarea datelor de test pentru parcurgerea drumurilor selectate precedent. Acest lucru se realizeaz pe baza condiiilor de parcurgere a drumurilor. De exemplu, s presupunem c un drum conine secvena de instruciuni i1, i2, i3. Dac i1 se execut cu condiia p 0, i2 cu condiia q < 0 iar i3 cu condiia p + q 0, atunci pentru parcurgerea secvenei i1i2i3 trebuie alese datele care satisfac condiiile precedente. n cazul datelor de test aleatoare se aleg n mod arbitrar diverse date din domeniul variabilelor de intrare. Metoda este simpl i de cele mai multe ori testele efectuate sunt eficiente. Pentru selectarea drumurilor de testat pot exista mai multe criterii dintre care se pot enuna: selectarea tuturor drumurilor, ce se aplic pentru programele la care se dorete o testare exhaustiv; parcurgerea tuturor condiiilor de selectare; parcurgerea tuturor instruciunilor. Analiza simbolic are drept scop stabilirea condiiilor de parcurgere pentru fiecare drum. Generarea datelor de test se poate face pe baza condiiilor stabilite de analiza simbolic. Se tie c prin testare nu se garanteaz corectitudinea programului. Nu exist nc o metod de testare care s demonstreze c programul este fr erori. Testarea asigur pe programator c programul su funcioneaz corect pentru un set limitat de date de intrare. Aceast garanie depinde de felul n care au fost alese datele de intrare pentru testare de ctre programator. Lipsa unei metode riguroase care s asigure validitatea produselor program constituie nc o problem major a informaticii. Aspectele teoretice elaborate pentru msurarea eficacitii testrii nu sunt practice. Evaluarea testrii se face n mod empiric n general pe baza unor rezultate statistico-experimentale. Practica arat c analiza static completat cu testarea dinamic conduce la programe cu un grad ridicat de funcionalitate. De asemenea, experiena arat c este bine ca validarea unui program s se realizeze prin mai multe metode de testare. Pe de alt parte, testarea programelor se simplific dac acestea se construiesc dup o metodologie sistematic bine documentat.

72

CAPITOLUL 5 INGINERIA PROGRAMRII ASISTAT DE CALCULATOR

5.1. Introducere
a cum s-a artat n capitolele anterioare, succesul realizrii unui produs program este n mod esenial influenat de stilul abordat i de etapele parcurse. Acest lucru este cu att mai important cu ct dimensiunile programului sunt mari i ndeplinete funcii complexe. Conform celor prezentate n capitolul 1, n elaborarea produsului program se parcurg anumite etape care, din pcate, nu sunt definitive, fiind necesare reveniri asupra etapelor anterioare pentru efectuarea anumitor modificri i corecii. Scrierea propriu-zis a codului care este privit uneori (n mod greit) ca fiind etapa principal a elaborrii unui produs program ocup un timp relativ mic n economia elaborrii produsului final. Este ns foarte important ca pn la scrierea codului program imaginea produsului final s fie bine conturat. Evident c n mod concret produsul final va fi reprezentat de codul su, dar fr o pregtire serioas n vederea scrierii codului, fr adoptarea unui stil corect de programare, fr testarea riguroas a codului i fr documentarea consistent a acestuia, rezultatul va fi de cele mai multe ori un produs de calitate inferioar. nc de la nceput au existat preocupri pentru introducerea elementelor CAE (Computer Aided Engineering) n domeniul ingineriei programrii pentru creterea calitii produselor program realizate i pentru creterea productivitii. Dac n capitolele precedente au fost prezentate elemente i sugestii pentru automatizarea activitilor de inginerie a programrii, n acest capitol va fi prezentat, pentru exemplificare, un program complet destinat asistrii de ctre calculator a activitii de elaborare a produselor program complexe. Programul Axiom Sys care va fi prezentat n continuare este destinat sistemelor moderne de calcul i permite desfurarea activitilor necesare n vederea elaborrii produselor program complexe ce vor fi rulate pe sisteme n timp real cu posibiliti de multiprocesare.

5.2. Prezentarea programului Axiom Sys

AxiomSys este un program care combin metodele analizei structurate cu extensiile de timp real i cu modelarea arhitectural pentru a furniza o soluie complet a problemelor de modelare a sistemelor. Obinerea proiectului final presupune parcurgerea urmtoarelor etape: analiza structural modelarea arhitectural

73

5.2.1. Analiza structural Unul din conceptele de baz utilizate n programul Axiom Sys este: modelul analizei structurale trebuie s fie independent de tehnologia utilizat pentru implementarea sistemului. Sistemul proiectat este privit ca un proces ce transform datele de intrare n date de ieire. Procesul este descompus (rafinat) n procese fii pn se obin procesele primitive. Un proces primitiv este un proces care descrie complet transformrile intrrilor n ieiri printr-o metod neambigu i testabil. Datele sunt compuse din structuri care se rafineaz i ele pn la obinerea datelor primitive. n cadul analizei structurale programul permite realizarea anumitor elemente care sunt utilizate att la verificarea corectitudinii structurii programului ct i la elaborarea documentaiei finale. Aceste elemente vor fi prezentate pe scurt n continuare. Diagrama de context a structurii Diagrama de context a structurii ofer o viziune de ansamblu asupra procesului modelat. Diagrama de context se compune din: procese (de prelucrare) reprezentat printr-un cerc; specificaii de proces (specificaii p) text care descrie un proces; terminatori interfee externe de la i spre procesul definit sau terminatori text reprezentai prin dreptunghiuri; specificaiile terminatorilor texte ce descriu funcia interfeei; fluxuri de date reprezentate prin linii pline cu sgei (sens); specificaiile datelor descrieri text i descrieri structurale; fluxuri de control (care conin date) reprezentate prin linii punctate cu sgei (sens).

Procesele, terminatorii, fluxurile de date i fluxurile de control trebuie definite prin specificaii. Diagramele de flux Diagramele de flux se construiesc pentru procesele diagramei de context. Acestea conin aceleai elemente ca i diagramele de context i n plus urmtoarele elemente: stocri de date simbolizate prin dou linii paralele; procese de control simbolizate printr-o bar; specificaii de control (specificaii c) metod grafic de descriere a informaiilor de control dintr-un proces (diferite stri ale procesului, evenimentele care produc schimbarea strilor, seturile de date generate i procesele activate. O specificaie c poate fi o diagram a tranziiilor strilor, un tabel de control sau o specificaie c ghid. 74

Principalele prelucrri ce se pot realiza asupra acestor diagrame, dup construirea lor sunt: validarea corespondenei specificaiilor cu obiectul cruia i aparine; validarea sintaxei diagramei; validarea corespondenei diagramei fiu cu diagrama printe; generarea rapoartelor.

5.2.2. Modelarea arhitectural Model arhitectural conine interfaa cu utilizatorul, intrri din proces, prelucrri, ieiri din proces i ntreinere. Acest model poate fi realizat cu ajutorul urmtoarelor elemente: module; terminatoare; fluxuri de date; fluxuri de control; canale care apar n diagrama de flux a interconectrii transport fluxul de date ntre module; specificaii pentru obiectele de mai sus.

Cua ajutorul acestor elemente se pot construi trei tipuri de diagrame: diagrama de context a arhitecturii, diagrama de flux a arhitecturii i Diagrama de interconectare a arhitecturii. n final programul Axiom Sys realizeaz validarea modelului pe ansamblu model structural i model arhitectural.

5.3. Construirea modelului analizei structurale

5.3.1. Particularitile analizei structurale ntlnite la programul Axiom Sys

n analiza structurat, sistemul ce urmeaz a fi proiectat trebuie privit ca un proces ce transform intrrile n sistem n ieiri ale sistemului. Acest proces este descompus (rafinat) ntr-un set de procese fii simple. Procesele fiu sunt mai departe rafinate pn cnd se obine un proces ce nu mai necesit rafinri ulterioare. Un astfel de proces se numete proces primitiv. Un proces primitiv este un proces care descrie complet transformrile intrrilor n ieiri printr-o cale neambigu i testabil. Datele de intrare i de ieire sunt definite ca un dicionar de articole de date sau pe scurt articole de date. Fiecare dat trebuie definit i trebuie descompus n elemente primitive. Definirea articolului de date poate fi compus dintr-o descriere textual, o descriere structural sau din amndou. Un format BNF (Backus-Naur) simplificat este utilizat pentru a descrie structura articolului de date (acest format va fi descris mai trziu n cadrul acestui capitol n paragraful 5.3.14). Structura articolului de date este utilizat pentru descompunerea articolului de date. Datele primitive vor avea numai o descriere textual. Dac nu s-a introdus descrierea unui articol de date atunci acesta va fi nedefinit. 75

Diagramele de flux (organigramele, schemele logice), specificaiile-p i specificaiile-c sunt utilizate pentru a descrie un proces. O diagram de flux este o metod grafic de a descrie un proces. Ea arat fluxul de date, fluxurile de control, stocarea datelor i procesele fiu ale procesului principal. Un flux de date este desenat cu o linie plin care are acelai sens (direcie) cu datele ataate de ea, aratnd de unde provin datele i unde sunt trimise. Un flux de control este desenat cu o linie ntrerupt direcionat (care are nu sens), cu date ataate, artnd direcia fluxului de control. O diagram de flux este diagrama n care sunt declarate procesele fiu ale procesului printe. Cnd un articol de date apare ntr-un flux de date, ntr-un flux de control, ntr-o zon de stocare de date sau ntr-o structur de date, acesta nu este definit ci numai declarat. Pentru definirea lui trebuie introdus suplimentar o definiie a setului de date. Cel mai nalt nivel al diagramei de flux furnizeaz o vedere general asupra procesului modelat i se numete diagram contextual. Terminatorii sunt utilizai n diagramele contextuale pentru a prezenta interfeele externe de la i spre procesul modelat. Pentru a descrie aceti terminatori se introduce un text. Dac s-a introdus descrierea unui terminator acesta devine un terminator definit. O specificaie-p (specificaie de proces) este un mod text de a descrie un proces. Dac o specificaie-p este introdus pentru un proces atunci specificaia-p este definit. O specificaie-c (specificaie de control) este o metod grafic de a descrie informaiile de control ale unui proces. O specificaie-c poate fi o diagram a tranziiilor strilor, un tabel de control sau o specificaie-c ghid. Specificaia-c prezint diferitele stri ale procesului, evenimentele care produc o schimbare a strii, seturile de date care sunt generate i procesele care sunt activate. Fiierele de urmrire i articolele (itemurile) de urmrire nu fac parte din modelul analizei structurale. Ele sunt ncorporate n programul AxiomSis pentru creterea productivitii. Fiierele de urmrire pot fi privite ca directoare (dosare) care conin itemurile de trasare. Un item de trasare este un text care poate fi legat de o specificaie-p, specificaie-s sau de un articol de date. Fiierele de trasare i itemurile de trasare sunt utilizate cel mai adesea pentru urmrirea cerinelor specificaiilor de proiectare. n mod normal sistemul modelat are anumite cerine de nivel nalt care trebuie satisfcute. Prin introducerea cerinelor de nivel nalt ca itemuri de trasare i legnd aceste itemuri de specificaiile p, s i de itemurile de date se poate determina rapid care parte a modelulului satisface cerinele de nivel nalt. 5.3.2. Crearea proiectului

Proiectul ce va fi realizat reprezint modelul unui proces de monitorizare al calculatoarelor existente ntr-o instituie. Calculatoarele din aceast instituie sunt legate n mai multe reele, conin anumite resurse i sunt utilizate n diverse scopuri. Procesul de monitorizare va oferi o imagine centralizat a strii de funcionare a calculatoarelor, resursele de care dispun acestea, accesul n reea, traficul realizat, etc. Fiind destinat procesului de nvare a modului de lucru cu programul AxiomSys, procesul va fi prezentat simplificat. Toate informaiile corespunztoare unui model sunt coninute ntr-o baz de date a proiectului. Proiectul poate exista n orice director sau disc care poate fi accesat de calculator. 76

Proiectul care va fi creat conform exemplului prezentat mai sus este intitulat monitorizare. Dup deschiderea programului Axiom Sys, pentru a crea proiectul se efectueaz urmtoarele aciuni: se selecteaz Project menu i opiunea Open; n cutia de dialog aprut se introduce numele proiectului: monitorizare n cmpul File Name i se selecteaz Open. Nu trebuie adugat extensia pentru c aceasta este pus automat; se selecteaz butonul Yes pentru a confirma crearea proiectului.

5.3.3. Crearea diagramei de context Pentru a ncepe crearea modelului, trebuie realizat mai nti diagrama de context a proiectului. Pentru a crea diagrama de context trebuie s se efectueze urmtoarele aciuni: se selecteaz pictograma diagramei de context ; cnd se afieaz caseta de dialog pentru Context Diagram se introduce: Monitorizarea_retelei i clic pe butonul Edit.

Va fi afiat o diagram de flux goal. 5.3.3.1. Adugarea unui proces

Adugarea procesului Controlul_si_monitorizarea_calculatoarelor la diagrama de context: ; se selecteaz pictograma Create Proces se poziioneaz cursorul n centrul diagramei i clic butonul stnga al mouseului; n caseta de dialog Create Process se introduce Controlul_si_\monitorizarea_\retelei n cmpul Name, 0 n cmpul Number i se terge caseta Is Primitive. Caseta de dialog Procesess Attributes va arta ca n figura de mai jos:

se apas butonul OK.

n caseta de dialog Create Process trebuie s se in cont de urmtoarele : 77

backslash \ este folosit atunci cnd se dorete trecerea la un rnd nou pe diagram; n diagrama de context numrul procesului este implicit zero. n alte diagrame de flux numrul procesului pentru primul proces este 1 i este incrementat pentru fiecare proces creat ulterior. Numrul procesului este folosit pentru a specifica ordinea proceselor pe durata generrii raportului; caseta Is Primitive este tears pentru a indica faptul c procesul nu este un proces primitiv.

Noul proces creat n diagrama de context este urmtorul:

NOT: procesul este afiat n gri. Acest lucru indic faptul c procesul nu este primitiv i nu exist o diagram de flux pentru procesul fiu al acestui proces; un asterix afiat dup numele procesului indic faptul c nu a fost definit o specificaie-p pentru acest proces. dac procesul este o primitiv, numele acestuia va fi afiat cu text ngroat. Pentru a iei din modul creare proces se face clic pe pictograma Go to localizat n bara de unelte. 5.3.3.2. Mutarea/redimensionarea unui proces

Pentru a muta un proces se face clic pe acesta i apoi se trage n noua poziie. Pentru a redimensiona procesul, acesta se selecteaz iar dup ce punctele de redimensionare sunt afiate, se apuc unul dintre acestea i se redimensioneaz obiectul. 5.3.3.3. Adugarea unui terminator

Urmtorul pas n construirea diagramei de context este reprezentat de introducerea terminatoarelor. Pentru aceasta se va urmri pe diagrama de mai jos poziionarea terminatoarelor i numele acestora. Asteriscul dup nume arat c terminatorul nu este definit (descrierea terminatorului nu a fost introdus). Dup introducerea terminatoarelor se va introduce i descrierea acestora aa cum se arat n continuare. Aa cum s-a artat, specificaiile terminatoarelor reprezint texte ce descriu funcionarea interfeei. Aceste specificaii sunt folosite att pentru verificarea proiectului in scopul determinrii modului n care sunt corelate variabilele introduse, ct i n faza de elaborare a documentaiei proiectului, cnd aceste texte vor fi introduse n raportul final, generat automat. 78

Pentru a crea un terminator se procedeaz astfel: se face clic pe pictograma terminatorului localizat n bara de unelte; se poziioneaz cursorul unde este localizat terminatorul i se face clic pe butonul stnga al mouse-ului; cnd caseta de dialog Create Terminator este afiat, se introduce numele terminatorului n cmpul Terminator. Dac numele terminatorului este prea lung se poate introduce un backslash n numele terminatorului pentru a-l mpri pe mai multe linii; se apas butonul OK i terminatorul va fi afiat pe diagram.

Pentru a iei din acest mod se apas pictograma Go to din bara de unelte. Mutarea i redimensionarea se face similar ca la proces (paragraful 5.3.5). 5.3.3.4. Adugarea datelor i a fluxului de control

n continuare se va face conectarea fluxului de date de la terminatorul Prezenta_tensiune la procesul Controlul_si_monitorizarea_calculatoarelor n felul urmtor: clic pe pictograma Create Data Flow localizat n bara de scule; se poziioneaz cursorul n interiorul terminatorului Prezenta_tensiune i se face clic pe butonul din stnga al mouse. Se poate insera un punct intermediar pe fluxul de date printr-o singur apsare pe butonul din stnga al mouse-ului nainte de dublul clic final n interiorul procesului. n caseta de dialog Create Flow se introduce Stare_intrerupator n cmpul Data_Item. pentru a aduga acest nume la lista cmpurilor de date se selecteaz butonul Add/Remove. Trebuie notat c numele din List of Data Items on Flow 79

este urmat de un asterisc. Asteriscul indic faptul c nu a fost introdus definiia cmpului de date n dicionarul de date. se selecteaz butonul OK pentru a ncheia crearea fluxului de date.

Pentru a iei din modul de creare a fluxului de date se face clic pe pictograma Go to .

Trebuie notat faptul c asteriscul dup numele fluxului de date indic faptul c itemul de date nu a fost definit n dicionarul de date. Adugnd i restul fluxurilor de date n diagrama de flux aceasta va arta astfel:

5.3.3.5.

Mutarea fluxului de date

Pentru a muta numele itemului de date ataat fluxului de date se face clic pe numele itemului de date i se trage n noua locaie. Pentru a aduga puncte fluxului de date se face clic pe un segment al fluxului de date i se trage n noua poziie. Pentru a ndeprta un punct din fluxul de date, se face clic pe acesta i apoi clic i apoi se trage acest punct pe un punct adiacent de pe fluxul de date. Pentru a muta un punct de pe fluxul de date, se face clic pe un segment de pe fluxul de date, apoi se face clic pe acest punct i se trage n noua locaie.

80

5.3.3.6.

Salvarea diagramei de context

Pentru salvarea acestei diagrame (care nc nu este complet) se selecteaz pictograma Save , sau din meniul File se selecteaz Save. n acest fel diagrama de flux este salvat n baza de date. 5.3.3.7. Adugarea unui flux de control

Urmtoarea etap este reprezentat de adugarea fluxurilor de control la diagrama creat. Acest lucru se face exact n aceeai manier ca i adugarea fluxurilor de date, dar pictograma selectat din bara de unelte este Create Control Flow Diagrama rezultat completat cu controlul de flux, trebuie s arate astfel: .

Aceast diagram este acum complet. Pentru a o salva procedai ca mai sus. 5.3.3.8. Adugarea unei specificaii-p la proiect

n acest moment se pot aduga specificaii-p la proiect. Este recomandat ca specificaiile-p s fie scrise pentru diagrama de context i pentru toate procesele din sistem. Scrierea acestor specificaii-p permite ca raportul final generat s fie mult mai uor de citit i de neles dect n cazul n care specificaiile-p sunt scrise numai pentru procesele primitive. Pentru a introduce o specificaie-p pentru diagrama de context se selecteaz , localizat n bara de unelte i se face clic pe Go to pictograma Go to Associated P-spec sau, echivalent, se face clic pe butonul dreapta al mouse-ului pe un spaiu gol din diagram i se alege Go to Associated P-spec din meniul care apare. Este afiat o fereastr cu o specificaie-p goal. Se introduc urmtoarele informaii: 81

Sistemul reprezinta un proces de monitorizare a calculatoarelor existente intr-o institutie. Calculatoarele din aceasta institutie sunt legate in doua retele, contin anumite resurse si sunt utilizate in diverse scopuri. Procesul de monitorizare ofera o imagine centralizata a starii de functionare a calculatoarelor, resursele de care dispun acestea, accesul in retea, traficul realizat, etc. Pentru a salva specificaia-p se selecteaz File menu apoi Save sau pictograma . Pentru rentoarcerea la diagrama de context se selecteaz Show/Go to pentru a fi afiat meniul i apoi clic pe Go to FD. Aceast aciune duce la afiarea diagramei de flux cu acelai nume ca i specificaia-p. Trebuie introdus acum specificaia-p asociat cu procesul Controlul_si_monitorizarea_calculatoarelor: clic pe butonul dreapta mouse cnd cursorul acestuia se afl pe procesul Controlul_si_monitorizarea_calculatoarelor i se selecteaz Edit P-spec din meniu, sau dublu clic pe butonul stnga mouse cnd cursorul acestuia se afl pe procesul Controlul_si_monitorizarea_calculatoarelor, innd tasta Ctrl apsat.

Fereastra cu specificaia p asociat este afiat. Se selecteaz meniul Show/Go to i se face clic pe Show Inputs/Outputs. Este afiat caseta de dialog pentru intrrile i ieirile specificaiei-p (aceast fereastr conine datele aa cum au fost stabilite la trasarea fluxurilor de date). Caseta de dialog va fi folosit pentru introducerea referirilor la fluxurile de date n textul specificaiei-p.

Specificaia-p asociat proceselor reprezint descrierea transformrii datelor de intrare ale procesului n date de ieire. n descrierea acestor transformri vor trebui fcute referiri la numele datelor de intrare i de ieire ale procesului asociat. Caseta de dialog a intrrilor i ieirilor specificaiei-p ajut la introducerea acestor referine n text. n aceast caset de dialog sunt dou liste posibil de selectat: lista datelor de intrare i lista datelor de ieire procesului asociat specificaiei. Pentru a aduga una dintre aceste intrri sau ieiri n textul specificaiei p, se poziioneaz cursorul n text n locul unde apare referina i apoi se face dublu clic pe numele din list. Referina va fi introdus automat n text. Referina apare ca IN(nume) pentru referirea la o intrare i OUT(nume) pentru referirea la o ieire. 82

Scopul acestei identificri are dublu rol. Mai nti se poate face compararea ntre specificaia-p i procesul din diagrama de flux. Acest lucru permite s se verifice dac toate intrrile i ieirile din proces sunt utilizate n specificaia-p i nu exist referine la date care nu apar n proces. n al doilea rnd referinele permit redenumirea global a fluxurilor de date cu noile nume care apar n specificaiile-p, acest lucru meninnd consistena modelului. n continuare vor fi prezentate aceste posibiliti. Se introduce urmtorul text, n fereastra specificaiei-p pentru Controlul_si_monitorizarea_calculatoarelor:
Acest proces controleaza starea calculatoarelor, a perifericelor si a celorlalte elemente din retea prin IN(Stare_comutator) care indica faptul ca o anumita unitate este alimentata. De asemenea este realizata o statistica a modului de utilizare a calculatoarelor si a fluxului de persoane din incaperile destinate retelelor prin IN(Numar_persoane). Fiecare server al unei retele este pus la curent cu disponibilitatile celorlalte retele prin OUT(Informatii_rest_retea). De asemenea la terminarea lucrului, pentru protectie se intrerupe alimentarea retelelor prin OUT(Comanda_comutatoare). Serverele retelelor pot fi configurate la distanta prin OUT(Configurare_server1).

Dup ce textul a fost introdus se salveaz specificaia prin selectarea din meniul File a opiunii Save sau selectarea pictogramei 5.3.3.9. Verificarea specificaiei-p din bara de unelte.

Pentru verificarea specificaiei-p se selecteaz meniul Validate i se face clic pe P-spec Against Process n vederea comparrii specificaiei-p cu procesul asociat acesteia. Erorile de coresponden ntre proces i specificaia-p vor fi afiate ntr-o fereastr nou. Examinnd aceste erori se constat c urmtoarele date nu sunt referite n specificaia-p: Datele Informatii_retea1 care reprezint o Controlul_si_monitorizarea_calculatoarelor nu specificaia-p. Datele Informatii_retea2 care reprezint o Controlul_si_monitorizarea_calculatoarelor nu specificaia-p. Datele Configurare_server2 care reprezint o Controlul_si_monitorizarea_calculatoarelor nu sunt p. intrare sunt intrare sunt n procesul folosite n n procesul folosite n

ieire din procesul folosite n specificaia

Pentru a corecta aceste erori, specificaia-p devine: Acest proces controleaza starea calculatoarelor, a perifericelor si a celorlalte elemente din retea prin IN(Stare_comutator) care indica faptul ca o anumita unitate este alimentata. De asemenea este realizata o statistica a modului de utilizare al calculatoarelor si al fluxului de persoane din incaperile destinate 83

retelelor prin IN(Numar_persoane). Fiecare server al unei retele este pus la curent cu disponibilitatile celorlalte retele prin OUT(Informatii_rest_retea). De asemenea la terminarea lucrului, pentru protectie, se intrerupe alimentarea retelelor prin OUT(Comanda_comutatoare). Serverele retelelor pot fi configurate la distanta prin OUT(Configurare_server1) si OUT(Configurare_server2). Modul de exploatare a fiecarei retele in parte este determinat prin IN(Informatii_retea1) si IN(Informatii_retea2). Dup adugarea modificrilor la specificaia p, aceasta va fi salvat din nou i se face iari validarea acesteia. n urma validrii trebuie s apar afiat mesajul: No error found. Se selecteaz meniul Show/Go to i se face clic pe Go to Parent Flow Diagram pentru rentoarcerea la diagrama de flux printe. Diagrama de flux printe este diagrama de flux care conine procesul asociat specificaiei-p. Trebuie remarcat c asteriscul care nsoea numele procesului a disprut. Acest lucru indic faptul c acum procesul are asociat o specificaie-p. 5.3.3.10. Adugarea textului unui terminator Urmtorul pas n crearea modelului este adugarea textului care definete terminatorii prezentai n diagrama de context. Mai nti se va aduga textul asociat cu terminatorul Baza_de_date. Acest terminator nu a fost pus iniial, deci va fi creat acum. De asemenea acestui terminator i se asociaz dou fluxuri de control Actualizare i Consultare ca n figura de mai jos:

Pentru a aduga text terminatorului Baza_de_date se efectueaz urmtoarele operaii: 84

se face clic pe butonul din dreapta mouse deasupra terminatorului Baza_de_date i se selecteaz Edit Terminator Specification din meniul afiat sau dublu clic buton stnga mouse cu tasta Ctrl apsat; n fereastra Terminator Baza_de_date se introduce urmtorul text:

Baza de date contine informatii cu privire la modul de utilizare a calculatoarelor, timpul de utilizare, numarul de utilizatori, traficul in retea si defectele aparute. De asemenea aplicatiile disponibile pentru fiecare utilizator sunt oglindite in aceasta baze de date pentru evitarea redundantei si a pierderii de date. se salveaz definiia terminatorului; se selecteaz din meniul File opiunea Close pentru a nchide aceast fereastr. Pe diagrama de context a disprut asteriscul de la numele terminatorului.

Acum se vor aduga textele asociate cu ceilali terminatori din diagrama de context Monitorizarea_retelei. Textul pentru fiecare terminator este urmtorul: Prezenta_tensiune: Starea de functionare a unui calculator este indicata de prezenta tensiunii. Un calculator poate fi deconectat de la retea sau conexiunea la retea poate fi defecta si in acest caz este necesar sa se cunoasca daca el este alimentat. De asemenea aceasta informatie este importanta pentru periferice cum ar fi imprimantele partajate in retea. Alimentare_retea: Sistemul de control si monitorizare a retelei permite controlul la distanta a alimentarii. Confirmarea alimentarii se face prin prezenta tensiune. Sesizor_prezenta: Sesizorul de prezenta furnizeaza informatii cu privire la fluxul persoanelor care circula prin institutie. Server_retea1: Conexiunea cu serverul de retea 1 permite schimbul de informatii intre reteaua 1 si sistemul de control si monitorizare centralizat. Server_retea1: Conexiunea cu serverul de retea 1 permite schimbul de informatii intre reteaua 1 si sistemul de control si monitorizare centralizat. 5.3.3.11. Introducerea definiiilor pentru itemurile de date

Pentru completarea diagramei de context este necesar definirea itemurilor de date i a fluxurilor de control prezente n diagram. Definiiile itemurilor de date sunt compuse din descrieri textuale i/sau descrieri structurale. 85

Descrierile textuale apar n subfereastra de sus a ferestrei itemului de date. Descrierile structurale, dac exist, sunt introduse n subfereastra de jos a ferestrei itemurilor de date. Structura este definit prin utilizarea formatului BNF (Backus-Naur Format) astfel: + nseamn AND. O dat A a crei structur const din mai multe componente independente are structura reprezentat astfel: A1+A2+A3. Simbolul + separ membrii structurii. nseamn c acest component este opional. Dac un membru a structurii este opional (de exemplu el poate s lipseasc), numele componentei opionale apare ntre paranteze, ca de exemplu: (A1) nseamn ORICARE DIN A1 SAU A2 SAU A3 poate aprea n fluxul de date sau de control. Aceast structur de date const din componente independente i reprezint o selecie cu excludere mutual. nseamn ITERAII ALE elementului inclus ntre parantezele acolad. Operatorul de iterare arat c oricine este inclus ntre acolade este repetat. Paranteze acolad fr alt specificaie nseamn de la zero la infinit repetri ale elementului dintre paranteze. Exemplu: A={A1} nseamn c A const din zero pn la infinit iteraii ale lui A1. Pentru a aplica o limit inferioar a numrului de iteraii parantezele acolad sunt precedate de un ntreg care definete limita inferioar de iteraii. De exemplu: 1{A} nseamn una sau mai multe iteraii ale lui A. Pentru a aplica o limit superioar a numrului de iteraii, parantezele acolad vor fi urmate de un ntreg care definete numrul maxim de iteraii. De exemplu: {A}5 nseamn c numrul maxim de iteraii ale lui A este cinci. nseamn c structura de date este identic alteia al crui nume este precizat. De exemplu: pentru itemul A, sintaxa ALIAS B nseamn c structura lui A este identic cu structura itemului B. O dat a crei structur este de tip enumerat are structura reprezentat astfel: /A1/A2/A3/ unde A1, A2 i A3 sunt valorile din enumerare.

()

[A1|A2|A3]

{}

ALIAS

La nceput va fi definit itemul de date Informatii_rest_retea din fluxul de control. Pentru a introduce definiia itemului se procedeaz n felul urmtor: clic pe butonul din dreapta mouse, pe itemul de date Informatii_rest_retea i se selecteaz Edit Data Item sau dublu clic pe itemul de date Informatii_rest_retea innd apsat tasta Ctrl.

n fereastra Data Item pentru Informatii_rest_retea se introduce urmtorul text n subfereastra de sus: 86

Aceste informatii sunt furnizate cu privire la restul retelei de calculatoare. n subfereastra de jos se introduce urmtoarea definiie a structurii: [Calculator_activ |Calculator_inactiv]+ [Imprimanta_activa |Imprimanta_inactiva]+ [Resursa_disponibila |Resursa_indisponibila]+ [Retea_ocupata |Retea_libera] Se selecteaz din meniul File, opiunea Close i apoi se apas butonul Yes n caseta de dialog afiat pentru salvarea definiiei itemului de date n dicionarul de date dup care se nchide fereastra Data item pentru Informatii_rest_retea. n diagrama de context se verific dac asteriscul asociat datelor Informatii_rest_retea a disprut, n felul acesta indicndu-se faptul c itemul de date a fost definit. Dac s-au produs erori de sintax la definirea datelor, aceste erori sunt semnalate. Se adaug definiia pentru itemul de date Informatii_retea1, n aceeai manier: n subfereastra de sus, textul:

Acestea reprezinta informatiile furnizate de reteaua 1 catre centrul de control si monitorizare. n subfereastra de jos:

Retea_disponibila1+ Resursa_disponibila1+ Lista_resurse1+

Datele sunt salvate n aceeai manier ca mai sus. Din cauz c definirea BNF a datelor conine o eroare, va fi afiat un mesaj de eroare ntr-o fereastr nou. n acest caz mesajul indic faptul c un semn + nu este urmat de numele unei componente nregistrate. Aceast eroare trebuie corectat i definiia itemului de date salvat din nou. Trebuie notat faptul c definiia itemului de date nu este salvat dac sunt erori de sintax. Se terge semnul plus de dup Lista_resurse1 pentru a corecta eroarea. Se salveaz ntr-o manier similar cu cea de mai sus. Acum trebuie introdus definiia unui item de date i specificarea atributelor acestuia. Se introduce urmtoarea definiie pentru itemul de date Numar_persoane n subfereastra de sus:

87

Aceasta informatie reprezinta numarul persoanelor prezente la un moment dat intr-o incapere. Se salveaz i apoi: se selecteaz meniul Show i se face clic pe Attributes; n caseta de dialog Data Item Attributes se introduce datele de mai jos i apoi se selecteaz OK.

Atributele Units, Range, Accuracy, Resolution i Rate trebuie ataate tuturor itemurilor de date din proiect. La sfrit se vor salva definiiile n maniera tiut. Se va completa diagrama de context prin definirea tuturor itemurilor de date rmase neasociate cu fluxurile de date sau de control cu descrierile i structurile prezentate mai jos: Informatii_retea2: Acestea reprezinta informatiile furnizate de reteaua 2 catre centrul de control si monitorizare. Retea_disponibila2+ Resursa_disponibila2+ Lista_resurse2 Stare_Comutator: Aceasta informatie furnizeaza starea comutatoarelor de alimentare cu energie electrica. 88

ALIAS Boolean Comanda_comutator: Aceasta informatie este destinata comenzii comutatoarelor de energie electrica ALIAS Boolean Configurare_server1: Aceasta informatie este necesara configurarii de la distanta a serverului 1.
Configuratie_de_baza1+ Configuratie_utilizatori1+ Configuratie_aplicatii1

Configurare_server2: Aceasta informatie este necesara configurarii de la distanta a serverului 2.

Configuratie_de_baza2+ Configuratie_utilizatori2+ Configuratie_aplicatii2

Actualizare:
Informatia necesara actualizarii bazei de date.

Consultare:
Informtia obtinuta in urma consultarii bazei de date.

La sfrit ne vom ntoarce n diagrama de context. Dac diagrama de context nu este afiat, se selecteaz meniul Window i se face clic pe Flow Diagram Monitorizarea_retelei. Se verific dac toate asteriscurile au disprut ceea ce garanteaz c s-au introdus toate definiiile. 5.3.3.12. Explorarea itemurilor de date

n acest paragraf se vor studia posibilitile de explorare a datelor oferite de programul AxiomSys. Se selecteaz pictograma Edit Data Dictionary .

Va fi afiat urmtoarea caset de dialog Data Item:

89

Dac este selectat opiunea Undefined Data Items vor fi afiate itemurile de date nedefinite n Data Item List. Definiiile itemurilor de date introduse au la rndul lor componente. Aceste componente sunt acum cunoscute de sistem i ele nu au intri definite n dicionarul de date. Pentru a defini itemul Boolean trebuie procedat n felul urmtor: se face dublu clic pe Boolean din Data Item List; se introduce urmtoarea definiie pentru itemul Boolean:

Aceasta informatie reprezinta o valoare booleana standard.

/TRUE/FALSE/

Dac caseta de dialog Data Item este afiat din nou vom vedea c Boolean nu mai este afiat n Data Item List din Undefined Data Items. Se afieaz caseta de dialog Data Item prin selectarea pictogramei Edit Data . Dictionary Item n caseta de dialog Data Item se selecteaz opiunea Defined Data Items. Dac un item de date este precedat de semnul plus nseamn c itemul de date are componente. Explorarea este similar cea din Windows 9x. 5.3.4. Crearea Diagramei de flux fiu Dup completarea diagramei de context va fi creat diagrama de flux fiu pentru procesul printe Controlul_si_monitorizarea_calculatoarelor. Pentru aceasta se efectueaz urmtoarele operaii: se face clic pe butonul dreapta al mouse-ului pe procesul Controlul_si_monitorizarea_calculatoarelor localizat n diagrama de context Monitorizarea_retelei i se selecteaz Edit Flow Diagram din meniul care a aprut sau 90

dublu clic n interiorul procesului Control_And_Monitor_Auto.

Va fi afiat o fereastr goal a diagramei de flux (Flow Diagram) pentru Controlul_si_monitorizarea_calculatoarelor. 5.3.4.1. Adugarea unui proces

Se vor aduga urmtoarele procese la diagrama de flux (vezi mai jos diagrama de flux):

1. Procesul Determinarea_\incarcarii ca un proces primitiv: clic pe pictograma Create Process localizat n bara de unelte; se poziioneaz cursorul n locul unde se dorete aezarea procesului pe diagram i se face clic pe butonul din stnga al mouse-ului; n caseta de dialog Create Process se introduce Determinarea_\incarcarii n cmpul Name i 1 n cmpul Number. Se bifeaz opiunea Is Primitive i apoi se face clic pe butonul OK.

2. 3. 4. 5.

Procesul Configurare_\server ca proces primitiv. Procesul Determinare_\trafic ca proces primitiv. Procesul Stare_de_\functionare ca proces primitiv. Procesul Intretinere_\baza_de_date ca proces primitiv. Pentru diagrama de flux se fac urmtoarele observaii:

91

Procesele neprimitive sunt afiate cu fond gri indicnd c o alt diagram de flux este necesar pentru aceste procese acestea nefiind definite n baza de date a proiectului n momentul crerii lor. Procesele primitive nu au fondul gri iar textul este ngroat. Poate fi necesar s mrirea diagramei (zoom) pentru a deosebi caracterele ngroate de cele care nu sunt ngroate. Pentru zoom se selecteaz pictograma localizat n bara de scule. Toate numele de procese sunt urmate de un asterisc indicnd faptul c specificaiile-p asociate nu sunt definite n acest moment. Adugarea unui flux

5.3.4.2.

Urmeaz crearea fluxurilor de date i de control pentru aceast diagram (vezi diagrama de mai jos). Se selecteaz pictograma Create Data Flow . Se mut cursorul n dreapta procesului Determinarea_incarcarii. Se face clic pe butonul din stnga al mouse-ului pentru a crea un flux de date orizontal ncepnd din partea dreapt a diagramei, spre procesul Determinarea_incarcarii. Se face dublu clic n interiorul procesului Determinarea_incarcarii pentru a termina fluxul de date, moment n care este afiat caseta de dialog Data Flow Atributes:

n caseta de dialog Data Flow Atributes, List of Input Data Items conine itemurile fluxurilor de date introduse n procesul printe i List of Output Data Items conine itemurile de date care prsesc procesul printe. Astfel, List of Imput Data Items conine itemurile de date de intrare pentru procesul Controlul_si_monitorizarea_calculatoarelor definite n diagrama de context Monitorizarea_retelei i List of Out Data Items conine itemurile de date de ieire pentru procesul Controlul_si_monitorizarea_calculatoarelor. Aceste dou liste funcioneaz ca un prompter care s aminteasc ce itemuri de date trebuie corelate cu diagrama de flux printe. Aceste liste servesc de asemenea ca metod de introducere pentru itemurile de date, caz n care nu trebuie scris nici un nume, introducerea fcnduse n mod automat. 92

Se va aduga Numar_persoane la fluxul de date astfel: dublu clic pe Numar_persoane n List of Input Data Items. Numar_persoane se va gsi acum n List of Data Items on Flow; clic buton OK.

Acum trebuie introdus un flux de control pentru a testa posibilitile de a aduga componente ale fluxului de date sau de control la diagrama de flux. Se face clic pe pictograma Create Control , apoi se mut cursorul pe procesul Configurare_server, i se aps o dat butonul din stnga mouse pentru a ncepe trasarea fluxului de control. La sfrit se face dublu clic n stnga procesului Configurare_server pentru a termina trasarea fluxului de control. Caseta de dialog Create Flow va fi afiat:

n aceast caset de dialog List of Input Data Items conine datele fluxului de control care intr n proces iar List of Output Data Items conin datele fluxului de control care prsesc procesul. Fluxul de control care urmeaz a fi creat va avea mai multe nume asociate cu el. Aceasta este o facilitate special a programului AxiomSys. Multe alte programe nu permit dect un singur item de date asociat cu un flux de date sau de control. n acest fel dac mai multe itemuri de date sunt generate de un obiect i se termin n acelai obiect, mai multe fluxuri de date sau de control trebuie s fie trasate. Cu AxioSys trebuie s fie trasat numai un flux; aceasta duce la diagrame mai puin dezordonate i mai uor de neles. Fluxul de control care a nceput s fie trasat va avea urmtoarele itemuri de date asociate cu el: Configurare_server1 i Configurare_server2. Aceste itemuri de date vor fi adugate astfel: clic dublu pe Configurare_server1 din List of Output Data Items; clic dublu pe Configurare_server2 din List of Output Data Items.

n acest moment List of Data Items din Flow trebuie s conin: Configurare_server1 i Configurare_server2. 93

 5.3.4.3.

se selecteaz butonul OK. Diagrama de flux Adugarea posibilitilor de stocare a datelor

Pentru a aduga posibilitatea stocrii datelor Persoane_prezente n diagrama de flux: se selecteaz pictograma Create Data Store ; se mut cursorul n locul din diagrama de flux unde se dorete plasarea facilitii de stocare a datelor i se face clic pe butonul stnga mouse. n caseta de dialog Create Data Store se introduce Persoane_prezente n cmpul Data Store i apoi clic pe butonul OK.

Modul n care va arta diagrama de flux este artat mai sus. Asteriscul dup Persoane_prezente arat c aceasta nu este definit. Cnd se adaug fluxuri de intrare sau de ieire n dispozitivul de stocare, numele nu trebuie afiate pe flux deoarece numele fluxului este acelai cu cel al dispozitivului de stocare. Pentru a suprima afiarea numelui pe aceste fluxuri, se terge caseta Display Data Items on Flow din caseta de dialog Data Fllow Attributes nainte de a selecta butonul OK. Se salveaz datele. Acum se va verifica sintaxa diagramei pentru a ne asigura c nu sunt erori. Se selecteaz din meniul de sus Validate i apoi se selecteaz opiunea Diagram 94

Syntax. Dac diagrama este ca cea din figura de sus atunci se primete un mesaj care comunic faptul c nu sunt erori. 5.3.4.4. Corespondena diagramei de flux cu procesul printe

Acum se va verifica corespondena ntre diagrama de flux i printele ei. Se selecteaz meniul Validate i clic pe Against Parent Diagram. O fereastr nou cu lista erorilor este afiat. Erorile indic faptul c itemul de date de ieire Informatii_rest_retea i Comanda_comutatoare sau componentele acestora nu sunt utilizate n diagrama de flux Controlul_si_monitorizarea_calculatoarelor dei ele sunt ieiri din procesul Controlul_si_monitorizarea_calculatoarelor n diagrama de flux printe. Pentru a verifica aceasta: se selecteaz butonul Goto ; n meniul aprut se selecteaz Parent Flow Diagram; n diagrama de flux printe (diagrama de context Monitorizarea reelei) se verific dac itemul de date Informatii_rest_retea este o ieire a procesului Controlul_si_monitorizarea_calculatoarelor; se face dublu clic pe procesul Controlul_si_monitorizarea_calculatoarelor i se selecteaz Edit Flow Diagram pentru a ne rentoarce la diagrama de flux Controlul_si_monitorizarea_calculatoarelor.

Aceste erori pot fi corectate acum sau mai trziu. Se propune ca tem corectarea erorilor de coresponden cu diagrama printe. 5.3.4.5. Explorarea specificaiilor-p

Se selecteaz pictograma Edit P-spec pentru a explora specificaia-p. Va fi afiat urmtoarea caset de dialog pentru specificaia-p:

95

Dac se face clic pe o specificaie-p din P-spec List numele va fi afiat n P-spec Name i acum se poate edita, redenumi sau terge specificaia-p prin selectarea butonului corespunztor. Dublu clic pe numele specificaiei-p din list o pune pe aceasta direct n modul editare. Se pot vedea specificaiile nedefinite (procesele exist dar nu au fost scrise specificaii-p pentru acestea), specificaiile definite (specificaiile-p scrise chiar dac procesul exist sau nu) i specificaiile-p nereferite (specificaiile-p scrise dar pentru care nu exist un proces corespondent n nici o diagram). Posibilitile de explorare sunt disponibile pentru fiecare tip de obiect din proiect. Vom vedea n continuare cteva dintre aceste posibiliti. 5.3.4.6. Explorarea diagramelor de flux

Se selecteaz pictograma Edit flow diagram pentru a explora diagrama de flux. Va fi afiat caseta de dialog pentru diagrama de flux. Cu ajutorul acesteia se poate afia diagrama de flux n diferite moduri: n ordine ierarhic. Cnd este selectat aceast opiune, lista FD (diagrama de flux) conine toate diagramele de flux i procesele din proiect, inclusiv acelea care au fost declarate ca primitive; n ordine alfabetic. Lista FD conine n ordine alfabetic toate diagramele de flux din proiect n trei grupe diferite: diagrame nedefinite (procesele neprimitive care nu au diagrame fiu), diagrame definite (toate diagramele procesului) i diagrame nereferite (toate diagramele procesului care nu au o legtur ierarhic cu diagrama de context). 5.3.5. Validarea proiectului AxiomSys La sfrit se poate realiza o validare a ntregului proiect. Se selecteaz Project din meniul de sus i apoi opiunea Validate Model. Se afieaz caseta de dialog Validate Project. Pentru c se dorete validarea ntregului proiect se selecteaz butonul Check All Options i apoi se apas butonul Validate. Rezultatele validrii vor fi afiate ntr-o fereastr nou. Din cauz c la proiectul discutat aici modelul nu a fost completat cu toate itemurile de date, specificaiile-p i diagramele de flux fiu, vor fi afiate mai multe erori. Aceste erori nu vor fi corectate aici. Prin examinarea mesajelor de eroare i inspectnd proiectul Monitorizare se pot corecta toate aceste erori. Corectarea erorilor se recomand ca exerciiu. 5.3.6. Crearea rapoartelor n continuare se vor studia posibilitile programului AxiomSys de a crea rapoarte. Se va studia: cum se definete modelul unui raport adic modul de definire a seciunilor care vor fi ncorporate n raport; 96

 5.3.6.1.

cum se poate trimite raportul direct la imprimant sau ntr-un fiier de forma Rich Text Format (RTF) compatibil cu Microsoft-Word sau alte procesoare de text. Crearea unui model de raport

Se va crea un model pentru generarea unui raport. Modelele care sunt furnizate odat cu acest program sunt conforme cu standardele DOD-2167A SRS i IRS. n continuare va fi creat un nou model pentru a arta care sunt aciunile necesare n acest scop. Se selecteaz meniul Project i apoi Print Report/Edit Report Template. n caseta de dialog Generate Report se introduce Monitorizare n cmpul File Name i se selecteaz butonul Edit. Se rspunde cu Yes pentru a deschide caseta de dialog. Va fi afiat urmtoarea caset de dialog:

Prin intermediul acestei casete de dialog va fi definit coninutul raportului. Se introduce Descriere Monitorizare n cmpul Raport Template Description. Lista Possible Sections definete seciunile (paragrafele) raportului care pot fi incluse n raportul generat de programul AxiomSys. Prima seciune a raportului care va fi generat va fi seciunea 1 i aceasta se va numi Introducere. Pentru a crea aceast seciune, se face dublu clic pe opiunea Canned Text din lista Possible Sections. Caseta de dialog Add Canned Text completat trebuie s fie astfel:

97

Se selecteaz butonul OK pentru a aduga aceast seciune la modelul raportului. Se adug seciunea 2, Documente referite care este de asemenea o seciune de text. n caseta de dialog Add Canned Text se completeaz urmtoarele, conform figurii de mai jos, nainte de a apsa butonul OK:

Caseta de dialog Edit Report Templates va conine n lista List of Sections to Generate cele dou seciuni definite n acest raport. Acestea sunt prezentate cu numrul seciunii, titlu i tipul seciunii n parantez. Se va aduga acum seciunea 3 la acest raport. Aceast seciune va consta din diagramele de flux ale sistemului n ordine ierarhic cu specificaiile-p incluse pentru fiecare diagram. Pentru a realiza acest lucru se face dublu clic pe opiunea Process Subtree din lista List of Possible sections. Caseta de dialog Process Subtree se va prezenta dup completare, astfel:

98

Se verific dac este bifat caseta Context Diagram deoarece dorim s ncepem aceast seciune cu diagrama rdcin a sistemului, diagrama de context. Se vor aduga diagrama de flux i specificaiile-p la acest raport. Pentru a realiza acest lucru se face dublu clic pe opiunea Flow Diagram din List of Possible Subsections. Se completeaz caseta dialog Add Flow Diagram afiat, cu urmtoarele:

Trebuie bifate casetele Data Information in Diagram i Control Information in Diagram. Aceasta nseamn c n diagram vor fi afiate informaiile de date i de control. De asemenea este bifat caseta cu numrul seciunii. Rezult c diagrama va avea propriul ei numr de seciune. Numrul seciunii va avea un nivel mai jos dect seciunea printe care este seciunea 3. n sfrit sunt utilizate simbolurile %1 i %3 n casetele text. Aa cum este artat n figur, %1 va fi nlocuit cu numele diagramei de flux i %3 va fi nlocuit cu numrul figurii. Utilizarea %3 permite generarea unui tabel al figurilor n raportul final. Se selecteaz OK pentru a aduga aceast seciune la raport. Dup aceasta se face dublu clic pe opiunea P-spec din List of Possible Sections. Se completeaz caseta de dialog care apare, astfel:

99

Specificaia-p nu va avea propriul numr de seciune, deci caseta Number Header este nebifat. Observai utilizarea simbolului %1. Se selecteaz butonul OK pentru a aduga aceast seciune la raport. Caseta de dialog Add Process Subtree trebuie s aib urmtorul aspect:

Seciunea 3 este complet. Se selecteaz OK pentru a adugarea acestei seciuni la raport. Caseta de dialog Edit Report Template va trebui s aib acum urmtorul aspect:

Se selecteaz butonul OK pentru generarea complet a modelului raportului. 100

5.3.7. Tiprirea unui raport Pentru tiprirea unui raport utiliznd modelul creat n paragraful precedent se procedeaz astfel: se selecteaz meniul Project i apoi Print Report/Edit Report Template; n caseta de dialog Generate Report se selecteaz Monitorizare din lista modelelor; pentru a tipri raportul direct la imprimant se selecteaz butonul Print. Pentru a genera un raport pentru un editor de text se selecteaz butonul Rich Text Format.

Raportul generat automat va avea urmtorul aspect: 1. Introducere Aceasta descriere este un test pentru posibilitatile programului AxiomSys de a crea rapoarte. 2. Documente referite Documentul de referinta pentru acest raport este manualul de invatare al modului de operare cu ajutorul programului AxiomSys. 3. Specificatie 3.1. Monitorizarea_retelei

Server_retea1

Prezenta_tensiune

Informatii_rest_retea Informatii_retea1

Configurare_server1

Stare_comutator Comanda_comutatoare 0 Controlul_si_ monitorizarea_ calculatoarelor Informatii_retea2 Server_retea2 Informatii_rest_retea

Alimentare_retea Numar_persoane Configurare_server2 Consultare Actualizare Sesizor_prezenta Baza_de_date

Figura 1 Diagrama de flux Monitorizarea_retelei 101

P-spec Monitorizarea_retelei Sistemul reprezinta un proces de monitorizare a calculatoarelor existente intr-o institutie. Calculatoarele din aceasta institutie sunt legate in doua retele, contin anumite resurse si sunt utilizate in diverse scopuri. Procesul de monitorizare ofera o imagine centralizata a starii de functionare a calculatoarelor, resursele de care dispun acestea, accesul in retea, traficul realizat, etc. 3.1.1. Controlul_si_monitorizarea_calculatoarelor

Lista_resurse1 Lista_resurse2

Persoane_prezentr*

Retea_libera Retea_ocupata 1 Determinarea_ incarcarii*

Configurare_server1 Configurare_server2

2 Configurare_ server*

Numar_persoane

Activare*

Retea_disponibila1 Retea_disponibila2 Retea_disponibila1 Retea_disponibila2 3 Determinare_ trafic*

4 Stare_de_ functionare*

Stare_comutator

Lista_resurse1 Lista_resurse2

5 Intretinere_baza_ de_date* Consultare

Actualizare

Figura 2 Diagrama de flux Controlul_si_monitorizarea_calculatoarelor P-spec Controlul_si_monitorizarea_calculatoarelor Acest proces controleaza starea calculatoarelor, a perifericelor si a celorlalte elemente din retea prin Stare_comutator care indica faptul ca o anumita unitate este alimentata. De asemenea este realizata o statistica a modului de utilizare a calculatoarelor si a fluxului de persoane din incaperile destinate retelelor prin Numar_persoane. Fiecare server al unei retele este pus la curent cu disponibilitatile celorlalte retele prin Informatii_rest_retea. De asemenea la terminarea lucrului, pentru protectie, se intrerupe alimentarea retelelor prin Comanda_comutatoare. Serverele retelelor pot fi configurate la distanta prin Configurare_server1 si Configurare_server2. Modul de exploatare a fiecarei retele in parte este determinat prin Informatii_retea1 si Informatii_retea2.

102

Laborator 1. Realizarea unui program de gestiune a unei reele de calculatoare

n acest laborator se va elabora tema de proiectare a unui sistem de gestiune destinat unei reele de calculatoare. Acest sistem are o anumit structura hardware compus din calculatoarele reelei, serverul (serverele) reelei, sistemul de alimentare cu energie electric, infrastructura reelei, senzori etc. i o anumit structur software compus din programul (programele) destinate monitorizrii reelei de calculatoare, programele driver etc. Pentru informaii legate de cerinele acestui sistem, se va consulta paragraful 5.3.2. din curs. Trebuie precizat ns, c pentru nelegerea complet a modului de funcionare i a interconexiunilor din sistem, este necesar s se parcurg informaiile coninute n ntreg capitolul 5 i n special textele i specificaiile adugate elementelor din schem. n lucrarea de laborator se vor elabora dou teme de proiectare: una pentru exemplul prezentat n curs (capitolul 5) i una pentru un exemplu similar, conceput de studeni, pentru o anumit structur fizic dat. Prima tem de proiectare se va referi la exemplul prezentat n curs (capitolul 5), i, pe baza celor prezentate acolo, se va concepe un mod de specificare a temei de proiectare n aa fel proiectantul s primeasc toate informaiile necesare realizrii proiectului. Pentru informaii legate de proiectul prezentat n curs, se va consulta raportul prezentat n paragraful 5.3.7. Cea de-a doua tem va fi realizat pe baza primei teme, dup ce aceasta este discutat i corectat n cadrul laboratorului. Aceast tem trebuie s fie similar i nu identic cu prima i ea va constitui materialul de lucru n cadrul laboratorului, pe baza acesteia fiind realizate laboratoarele urmtoare. Pentru structura fizic se va realiza o schem electric de ansamblu a acesteia. Temele de proiectare vor fi ntocmite conform indicaiilor din curs de la capitolul 1. Se vor forma echipe de 2-3 studeni care vor concepe aceste teme de proiectare iar cea de-a doua tem elaborat de o echip va fi atribuit unei alte echipe care va solicita precizri suplimentare i modificri ale temei, dac este cazul. Referatele de laborator vor conine temele elaborate, tema primit de la o alt echip, precizrile i modificrile solicitate la aceast din urm tem.

103

Laborator 2. Proiectarea schemei logice

Pe baza temei de proiectare realizat, discutat i finalizat n cadrul laboratorului 1 se va proiecta schema logic a aplicaiei. Schema logic se va realiza pe mai multe nivele, ncepnd de la nivelul cel mai general i terminnd cu nivelul cel mai detaliat (tehnica top-down capitolul 2 din curs). Schema logic se va realiza separat pentru structura hardware i pentru structura software. Pentru structura software va fi scris i pseudocodul corespunztor schemei logice. De asemenea se vor specifica modulele structurii cu elementele specifice ale acestora: o o o o denumirea modulului; interfaa modulului; fluxul de date; funcia ndeplinit.

Schema logic i pseudocodul se vor realiza conform indicaiilor din curs de la capitolul 2. Referatele de laborator vor conine: schemele logice realizate, pseudocodul aferent schemei logice a componentei software, modulele componentei software, descrierea fluxurilor de date i de control.

Laborator 3. Prezentarea programului Axiom Sys

n aceast lucrare de laborator se studiaz programul AxiomSys conform capitolului 5, paragraful 5.2. Se lanseaz n execuie programul AxiomSys i se analizeaz meniul principal. Se consult explicaiile furnizate de program i cele din curs. Dup lansarea programului AxiomSys se ncarc de pe harddisc proiectul MONITORIZARE.PD0 care este similar cu exemplul prezentat n curs la capitolul 5. Dup deschiderea proiectului se deschide diagrama de context i se analizeaz componentele acesteia. n referatele de laborator se vor descrie elementele componente ale diagramei de context i modul de realizare a acestora. Se vor determina care elemente sunt definite i care nu, dup care elementele nedefinite vor fi definite conform modelelor furnizate. Se vor trece n referatele de laborator numele fluxurilor de date i numele fluxurilor de control cu scurte explicaii privitoare la acestea. Se va deschide diagrama de flux a procesului Controlul i monitorizarea reelei i se vor identifica elementele acesteia. n referatele de laborator se vor descrie elementele componente ale diagramei de flux i modul de realizare a acestora. Se vor determina care elemente sunt definite i care nu, dup care elementele nedefinite vor fi definite conform modelelor furnizate. Se vor trece n referatele de laborator numele fluxurilor de date i numele fluxurilor de control cu scurte explicaii privitoare la acestea. Pentru informaii suplimentare se va consulta i raportul elaborat pentru proiectul MONITORIZARE.PD0 i prezentat n paragraful 5.3.7.

104

Referatele de laborator vor conine explicaiile referitoare la comenzile meniului principal i a subfunciilor acestora i se va explica rolul diagramei de context i a celei de flux.

Laborator 4. Analiza structural

Pe baza exemplului prezentat n proiectul MONITORIZARE.PD0 se va face studiul modului de realizare a analizei structurale. Studenii se vor organiza n grupe de 2-3 membrii care vor face propuneri de modificare n vederea optimizrii proiectului analizat. Se vor studia: diagrama de context i diagrama de flux, corectitudinea definirii proceselor, terminatorilor, fluxurilor de date, fluxurile de control, etc. i se vor face propuneri de mbuntire a situaiei existente. n referatele de laborator se va explica necesitatea modelrii structurale n cazul ingineriei programelor, etapele parcurse pentru realizarea acesteia i elementele componente ale unui model structural. De asemenea referatele de laborator vor conine explicarea modificrilor propuse la proiectul MONITORIZARE.PD0 i vor fi nsoite de proiectele modificate, n format electronic.

Laborator 5. Analiza arhitectural

Analiza arhitectural nu se va realiza pentru temele de proiectare stabilite n laboratorul unu. Avnd n vedere ns importana acesteia, ea va fi realizat pe exemplul furnizat de programul AxiomSys: cruise.pd0. Pentru aceasta se ncarc proiectul i se urmeaz indicaiile furnizate n continuare. 1. Modelarea arhitectural. Vedere general. Modelarea arhitectural este o metod de proiectare a componentelor care vor fi utilizate pentru implementarea cerinelor definite n modelul analizei structurate. n modelarea arhitectural sistemul dumneavoastr este gndit a fi construit dintr-un modul care transform intrrile sistemului n ieirile acestuia. Acest modul nu este acelai lucru cu procesul de context din modelul analizei structurale, din cauz c prin definirea arhitecturii sistemului vor rezulta deciziile de proiectare care vor avea caracteristicile modelului de procesare definite n modelul analizei structurale. Acest modul este atunci descompus sau rafinat ntr-un set de module fii simple. Modulele fii vor fi rafinate mai departe, dac este necesar, pn cnd nu mai necesit rafinare. Aceste module se vor numi module primitive. n modelarea arhitectural un modul este o component a sistemului care implementeaz un set de procese ale analizei structurale. n modelarea arhitectural un canal servete ca legtur pentru transportul datelor ntre module. Diagrama de flux a arhitecturii, diagrama de interconectare a arhitecturii i specificaiile modulelor sunt utilizate pentru descrierea unui modul. O diagram de flux arhitectural este o modalitate grafic de a descrie un modul. Aceasta arat fluxul informaiilor (itemurilor de date) ntre module. Prima diagram de flux este diagrama de context a arhitecturii. 105

Integritatea sistemului este validat prin verificarea consistenei ntre analiza structurat i modelul arhitectural. Din nou AxiomSys poate genera rapoarte automate pentru informaia coninut n modelul dezvoltat. 2. Crearea diagramei de context a arhitecturii Deschidem baza de date creat n partea I a acestui tutorial: Lansm AxiomSys. n programul AxiomSys selectm meniul Project i apoi Open. n caseta de dialog Open Project introducei new n cmpul Project Name, apoi introducei OK.

Pentru a ncepe crearea unei diagrame de context selectai pictograma Edit Architecture Context Diagram . n caseta de dialog Architecture Context Diagram introducei Cruise_Control_Architecture n cmpul Name i selectai butonul Edit Arch. Flow Diagram. Va fi afiat urmtoarea diagram de context a arhitecturii vid:

Liniile i notele de pe aceast diagram sunt cunoscute sub numele de model arhitectural. Seciunea Maintenance din aceast diagram nu va fi utilizat n acest model. Pentru a ndeprta aceast seciune clic dreapta pe cuvntul Maintenance i selectai Delete din meniul afiat. 106

Pentru a muta o etichet a unei seciuni, clic pe aceasta i o mutai n noua poziie. 2.1. Adugarea unui modul Selectai pictograma Create Module din bara de scule. Poziionai cursorul n mijlocul diagramei i apsai butonul stnga mouse. Cnd se afieaz caseta de dialog Module Attributes: Introducei: Automobile_\Management_\System n cmpul Module Name. Introducei 0 n cmpul Module ID. Introducei 1 n cmpul Number of Modules. tergei opiunea Primitive pentru a indica faptul c modulul va fi descompus mai departe n submodule. Selectai butonul OK.

Diagrama arhitecturii conine acum modulul. Este de notat: Modulul este n gri ceea ce arat c nu este un modul primitiv i nu exist o diagrama fiu pentru modul. Asteriscul dup numele modulului arat c nu exist o specificaie pentru modul. Dac un modul este un modul primitiv atunci el va fi afiat cu litere ngroate.

Pentru a iei din acest mod se selecteaz pictograma . Modificarea dimensiunilor i repoziionarea modulului se face similar cu cele prezentate la anterior. 2.2. Adugarea unui terminator Adugarea unui terminator se face similar ca la diagrama de flux (paragraful 3.3). Pentru poziionarea i numele terminatoarelor vedei diagrama de mai jos. 2.3. Adugarea unui flux de date Adugarea unui flux de date se face astfel: Clic pe pictograma Create Data Flow din bara de scule. Poziionai cursorul n terminator i clic pe buton stnga. Mutai cursorul n interiorul modulului Automobile_Management_System i dublu clic pe butonul stnga mouse. Se poate insera un punct intermediar prin clic pe butonul stnga mouse n poziia dorit nainte de a merge n poziia final. n caseta de dialog Architecture Flow Attributes introducei Driver_Entries n cmpul Data. 107

Pentru a aduga acest nume la List of Data Items on Flow selectai butonul Add. Asteriscul semnific faptul c datele nu sunt definite. Selectai OK pentru a ncheia.

n aceeai manier adugai toate fluxurile de date aa cum este artat n diagrama de mai jos. Adugarea fluxurilor de control se face similar cu adugarea fluxurilor de date cu excepia c n acest caz se folosete pictograma , Create Control Flow.

Salvai cu . Urmeaz validarea sintaxei arhitecturii diagramei de context. Selectai Validate din meniul de mai sus i apoi selectai Diagram Sintax. Dac apar erori acestea trebuie corectate. 2.4. Adugarea canalelor Diagrama de context este afiat ca o diagram de flux a arhitecturii. Aceasta poate fi de asemenea ca o diagram a arhitecturii interconectat. Diagrama arhitecturii interconectat are aceleai module ca cele din diagrama de flux dar fluxurile nu sunt artate n schimb sunt artate canalele care transport informaia ntre module. Pentru a converti diagrama ntr-o diagram de interconectare, clic pe butonul din dreapta al mouse-ului pe un spaiu gol al diagramei i selectai Show Architecture Interconnect Diagram din meniul afiat. Vei aduga acum canalul ntre terminatorul Driver i modulul Automobile_Management_System. 108

Selectai pictograma Channel din bara de scule. Clic n terminatorul Driver i dublu clic n interiorul modulului Automobile_Management_System. n caseta de dialog Channel Attributes introducei Ext_Driver_Bus n cmpul Channel, bifai opiunea Display Channel Name, selectai opiunea Bus i apoi selectai OK.

Figura de mai ajos prezint caseta de dialog Channel Attributes nainte de apsarea butonului OK.

Se adaug i celelalte canale la diagram. Salvai aceast diagram n baza de date. Reverificm sintaxa diagramei: selectm meniul Validate i apoi opiunea Diagram Syntax. Dac ai realizat diagrama ca mai sus, nu trebuie s apar erori. 2.5. Adugarea unei specificaii la modul Specificaia unui modul este o descriere de tip text asociat modulului. Vom scrie specificaia modulului Automobile_Management_System. Scrierea acestei specificaii va permite ca generarea raportul final generat s fie mai uor de citit i de neles dect n cazul n care se scriu numai specificaiile modulelor primitive. Pentru a introduce specificaia: Clic dreapta pe modulul Module_Management_System i selectai Edit Module Specification din meniul afiat, sau Dublu clic pe modulul Automobile_Management_System innd apsat tasta Ctrl. Introducei urmtorul text n fereastra Automobile_Management_System:

This is the architecture model representing the entire cruise control system Selectai meniul File i alegei Close. Apsai butonul OK. 109

2.6. Adugarea unei specificaii la terminator Se face la fel ca la modelul analizei structurate. 2.7. Adugarea unei definiii pentru item de date Se face la fel ca la modelul analizei structurate. 2.8. Adugarea unei specificaii pentru canal Specificaia pentru un canal este o descriere text care este asociat canalului. Pentru a aduga specificaia de canal pentru canalul Ext_Driver_Bus: Clic dreapta pe canal i selectai Edit Channel Description din meniul afiat, sau Dublu clic pe canal innd tasta Ctrl apsat.

Cnd fereastra pentru canal este afiat, introducei specificaia pentru canal. Dup aceasta selectai meniul File i opiunea Close. Rspundei cu Yes la ntrebarea dac dorii salvarea datelor. n urma acestei aciuni asteriscul de dup numele Ext_Driver_Bus din diagrama Cruise_Control_Architecture nu mai este afiat. Adugai urmtoarele specificaii de canal: Ext_Shaft_Bus
This is the channel connecting the drive shaft to the cruise control system.

Ext_Engine_Bus
This is the channel connecting the engine to the cruise control system.

Ext_Brake_Bus
This is the channel connecting the brake to the cruise control system.

Ext_Gear_Bus
This is the channel connecting the transmission to the cruise control system.

Ext_Throttle_Bus
This is the channel connecting the throttle to the cruise control system.

Ext_DataBase_Bus
This is the channel connecting the data base to the cruise control system.

2.9. Ataarea unui item de date la canal Pentru fiecare canal vei defini un item de date care circul prin acest canal. Putei construi lista itemurilor de date pornind de la canal sau de la itemul de date. Vor fi artate ambele metode. nainte ca itemul de date s poat fi asociat cu canalul acesta trebuie s fie definit. Prin urmare trebuie s introducei urmtoarele n dicionarul de date: Driver_Entries
The raw driver inputs to the system.

Driver_Displays
The display data from the system to the driver.

Shaft_Position 110

The raw shaft data to the system.

Engine_Status
The raw engine data to the system.

Brake_Position
The raw brake position information to the system.

Gear_Status
The raw transmission data to the system.

Throttle_Drive
The system throttle data to the throttle.

Pentru a asocia itemul de date la canal din canal: Clic dreapta pe canalul Ext_Driver_Bus. Selectai Edit Channel Specification din meniul desfurat. n fereastra Channel Ext_Driver_Bus selectai meniul Show i meniul Assigned Data Items. n caseta de dialog Assign Channel to Data Item selectai butonul Browse. n Browse Data Item selectai opiunea Defined Data Items. Parcurgei lista Data Item List pn la Driver_Entries i dublu clic pe acesta. n caseta de dialog Assign Channel to Data Item selectai butonul Assign/Deassign. n acelai fel adugai itemul de date Driver_Displays la canal. n fereastra Channel Ext. Driver Bus selectai meniul File i apoi Close.

Pentru a asocia itemul de date la canal din itemul de date: Selectai pictograma Edit Data Dictionary . n caseta de dialog Data Item selectai opiunea Defined Data Items. Parcurgei lista Data Item List pn la : Shaft_Position i dublu clic pe Shaft_Position. n fereastra Data Item Shaft_Position selectai meniul Show i meniul Assigned Channels. n caseta de dialog Assign Channel to Data Item selectai butonul Browse. n caseta de dialog Browse Channel selectai opiunea Defined Channels. n lista Channel List dublu clic pe Ext_Shaft_Bus. n caseta de dialog Assign Data Item to Channel selectai butonul Assign/Deassign. Selectai butonul Exit pentru a termina. n fereastra Data Item Shaft_Position selectai File i apoi Close.

111

ntr-o manier similar realizai urmtoarele asocieri ntre itemurile de date i canal: Channel Ext_Engine_Bus - Data item Engine_Status Channel Ext_Brake_Bus - Data item Brake_Position Channel Ext_Gear_Bus - Data item Gear_Status Channel Ext_Throttle_Bus - Data Item Throttle_Drive Channel Ext_DataBase_Bus - Data Item Calibrate_Parameters 3. Crearea diagramei de flux a arhitecturii Acum vom crea diagrama de flux a arhitecturii pentru modulul Automobile_Management_System. n diagrama de context a arhitecturii, clic dreapta pe modulul Automobile_Management_System i selectai Edit Architecture Diagram din meniul desfurat sau dublu clic pe modulul Automobile_Management_System. Fereastra Architecture Fow Diagram Automobile_Management_System este afiat. Pentru c seciunea Maintenance nu este necesar n aceast diagram, o vei ndeprta la fel ca din diagrama de context a arhitecturii. Dup adugarea modulelor diagrama de flux a arhitecturii va arta astfel:

112

Este de notat c aceste module sunt toate primitive i nu sunt afiate n gri iar numele lor sunt afiate cu litere ngroate. Dac este necesar zoom se selecteaz pictograma . Numele modulelor sunt urmate de un asterisc indicnd faptul c specificaiile asociate modulelor nu sunt definite. La crearea acestei diagrame va trebui s decidei c procesul esenial de control al navigaiei va fi realizat n modulul Automobile_Management_Computer i acesta va fi modulul de interfa cu fiecare component hardware din sistem. 3.1. Adugarea la arhitectur a fluxurilor de date i de control Acum urmeaz crearea arhitecturii fluxurilor de date i de control pentru aceast diagram. Creai o arhitectur orizontal a fluxului de date care intr modulul Driver_Interface_Module n partea stng a diagramei: localizat n bara Selectai pictograma Create Architecture Data Flow de scule. Clic ntr-un punct din stnga modulului Driver_Interface_Module pentru a ncepe trasarea fluxului de date. Dublu clic n modulul Driver_Interface_Module pentru a termina trasarea fluxului de date.

Va fi afiat urmtoarea caset de dialog:

n caseta de dialog lista List of Input Data Items conine fluxurile itemurilor de date care intr n modul n diagrama arhitecturii printe i lista List of Output Data Items conine itemurile de date care pleac din modul n diagrama arhitecturii printe. Dac v uitai la diagrama prezentat mai sus, vei vedea c este aa. Aceste dou liste v arat de fapt care sunt datele care trebuie interconectate (balance) cu diagrama de flux a arhitecturii printe. Aceste dou liste v ajut s introducei datele fr a fi necesar scrierea numelor. 113

Pentru crearea complet a fluxului de date a arhitecturii: Dublu clic pe Driver_Entries din lista List of Input Data Items. Notai c Driver_Entries este acum n lista List of Data Items on Flow. Selectai acum butonul OK pentru a termina crearea fluxului de date.

Acum urmai indicaiile urmtoare pentru a crea un flux de control al arhitecturii care pleac din Driver_Interface_Module i intr n Automobile_Management_Computer: Selectai pictograma Create Architecture Control Flow localizat n bara de scule. Clic pe Driver_Interface_Module pentru a ncepe trasarea controlului de flux. Dublu clic pe Automobile_Management_Computer pentru a termina trasarea fluxului de control. n caseta de dialog Architecture Flow Attributes introducei Driver_Command n cmpul Data_Item, selectai butonul Add i apoi OK.

Adugai i fluxurile de date i de control adiionale, n final diagrama avnd aspectul urmtor:

114

Selectai meniul File i apoi Save pentru a salva aceast diagram. Selectai Validate din meniul de sus i apoi opiunea Diagram Syntax pentru a valida sintaxei diagramei. Erorile apar ntr-o fereastr separat. Erorile indic faptul c nu sunt prezente canale pe aceast diagram. Vei corecta aceste erori n paragraful urmtor. 4. Crearea diagramei de interconectare a arhitecturii Selectai pictograma Goto localizat n bara de unelte i selectai Show Architecture Interconnect Diagram din meniul aprut sau clic dreapta pe un spaiu gol din diagram si selectai Show Architecture Interconnect Diagram din meniul aprut. Diagrama de interconectare a arhitecturii apare. Se fac urmtoarele observaii: Diagrama este similar diagramei de flux a arhitecturii. Modulele sunt n acelai loc n diagrama fluxului i diagrama interconectrii arhitecturii. Fluxurile de date i de control nu sunt artate n diagrama de interconectare a arhitecturii.

4.1. Adugarea unui canal Un canal reprezint un mediu fizic care conecteaz modulele i prin care curg itemurile de date. Trebuie notat faptul c n cazul cnd cananlele sunt conectate mpreun numele unuia dintre canale nu va fi afiat. Aceasta pentru a mbunti lizibilitatea diagramei unde canalele interconectate trebuie s aib acelai nume. nainte de aduga canalele observai c modulele Shaft_Interface_Module i Throttle_Interface_Module sunt diferite de cele din diagrama de flux a arhitecturii. De multe ori exist module duplicate n sistem pentru siguran sau din alte motive. Existena modulelor dublate (duplicate) poate fi artat n AxiomSy Pentru a face ca Shaft_Interface_Module s fie compus din dou module identice, se procedeaz astfel: Clic dreapta pe Shaft_Interface_Module. Selectai Edit Atributes din meniul aprut. n caseta de dialog Module Attributes introducei 2 n cmpul Number of Modules i selectai butonul OK.

Se observ c simbolul utilizat pentru reprezentarea modulului Shaft_Interface_Module se schimb pentru a semnala faptul c modulul este duplicat. n acelai fel schimbai n dou numrul modulelor Throttle_Interface_Module. Acum adugai canalele diagramei n acelai fel cum ai fcut-o n Architecture Context Diagram pentru a obine rezultatul prezentat mai jos:

115

Dup numele canalului apare un asterisc ceea ce indic faptul c specificaia canalului nu este definit. Cu alte cuvinte, nu s-a introdus specificaia canalului. Introducerea specificaiei canalului i asocierea itemurilor de date rmne ca exerciiu. Procedura este aceeai ca cea de la diagrama de context a arhitecturii. 5. Validarea modelului Selectai meniul Project i apoi meniul Validate Model. n caseta de dialog afiat asigurai-v c opiunea Check All Options este selectat i n acest caz apsai butonul Validate. Mesajele de validare vor fi afiate ntr-o fereastr nou. Din cauz c nu ai completat modelul prin legarea tuturor itemurilor de date i specificaiile p, apar mai multe erori. Prin examinarea mesajelor de validare i inspectnd modelul Cruise inclus att n varianta comercial ct i n cea demonstrativ vei putea elimina toate erorile. Acest lucru rmne ca exerciiu. Erori suplimentare se datoreaz faptului c modelul analizei structurate i modelul arhitectural nu sunt nc legate mpreun. n referatele de laborator se va explica necesitatea modelrii arhitecturale n cazul ingineriei programelor, etapele parcurse pentru realizarea acesteia i elementele componente ale unui model arhitectural.

116

Laborator 6. Construirea modelului analizei structurale

Pe baza temei de proiectare elaborate n laboratorul numrul unu, a indicaiilor prezentate n capitolul 5 din curs i pe baza schemei logice realizate n laboratorul numrul doi se va face analiza structural a proiectului. n aceast lucrare de laborator se vor stabili procesele componente ale proiectului, terminatorii, fluxurile de date i fluxurile de control i se vor stabili diagramele de flux ale proceselor. Pentru fiecare element din proiect se va face o scurt descriere conform celor prezentate n capitolul 5 din curs. De asemenea se vor scrie, dac este cazul, definiiile pentru fluxurile de date. Toate aceste elemente vor fi stabilite pe baza informaiilor furnizate de tema de proiectare i de schema logic fr a se folosi programului AxiomSys. Aceast etap este necesar pentru finalizarea concepiei proiectului de analiz structural i n scopul determinrii utilitii proiectrii asistate de calculator. Referatele de laborator vor conine tipul i descrierea elementelor componente ale proiectului analizei structurale i explicaiile cu privire la corespondena ntre schema logic obinut n laboratorul numrul doi i aceste elemente.

Laborator 7. Crearea proiectului

Cu ajutorul programului AxiomSys i pe baza celor stabilite n laboratorul numrul ase se va crea un proiect nou i se vor realiza diagramele de context ale proiectului analizei structurale i se vor stabili specificaiile aferente acestora. Diagrama de context va conine procesele, terminatorii, fluxurile de date i cele de control. Vor fi completate pentru aceste diagrame specificaiile proceselor (specificaiile-p) i specificaiile terminatorilor (specificaiile-t). Nu se vor defini n aceast faz fluxurile de date i cele de control. Diagramele vor fi verificate din punct de vedere sintactic i se vor elimina eventualele erori. De asemenea se va face verificarea automat a specificaiilor-p conform celor artate n curs n paragraful 5.3.3.9. Referatele de laborator vor conine diagramele de context realizate i specificaiile aferente acestora.

Laborator 8. Introducerea definiiilor pentru itemurile de date

La proiectul realizat n lucrarea de laborator numrul apte se vor introduce definiiile fluxurilor de date i a celor de control din diagramele de context. Definiiile fluxurilor de date i de control se vor realiza conform datelor obinute n laboratorul numrul ase i a indicaiilor prezentate n curs n paragraful 5.3.3.11. Se va verifica, aa cum se arat n paragraful 5.3.3.12. ca toate fluxurile de date i de control s fie definite. La sfrit se salveaz proiectul. Referatele de laborator vor conine definiiile introduse pentru fluxurile de date i de control. 117

Laborator 9. Crearea Diagramei de flux

La proiectul realizat n lucrarea de laborator apte se creeaz diagramele de flux pentru procesele din diagramele de context. Diagramele de flux se realizeaz conform indicaiilor din curs n paragraful 5.3.4. Toate elementele diagramelor de flux trebuie s fie definite. Se vor face verificarea corespondenei diagramei de flux cu procesul printe (paragraful 5.3.4.4.). La sfrit proiectul se salveaz. Lucrrile de laborator vor conine diagramele de flux realizate i specificaiile aferente acestora.

Laborator 10. Validarea proiectului

Proiectul realizat n lucrarea de laborator numrul 8 va fi verificat i corectat conform celor precizate n paragraful 5.3.5. din curs. Dup validare se vor corecta erorile aprute n proiect n aa fel nct acestea s fie eliminate complet sau s fie reduse la un numr minim. La sfrit proiectul se salveaz. Lucrrile de laborator vor conine mesajul furnizat de programul AxiomSys i justificarea erorilor ce nu au putut fi eliminate.

Laborator 11. Crearea rapoartelor

Conform indicaiilor prezentate n paragraful 5.3.6. din curs se va ntocmi un raport pentru proiectul realizat n lucrarea de laborator numrul 9. Referatele de laborator vor conine: descrierea n rezumat a posibilitilor de elaborare a unui raport i raportul elaborat.

Laborator 12. Scrierea programelor n mai multe limbaje de programare

Scrierea programelor n mai multe limbaje de programare este adeseori necesar i ingineria programelor stabilete reguli i metode de elaborare a unor astfel de produse program. Utilizarea mai multor limbaje de programare poate fi impus pe de o parte de diferite particulariti ale produsului elaborat, iar pe de alt parte de preferinele sau performanele programatorilor. Utilizarea limbajelor de programare diferite impune stabilirea unor reguli care s permit asamblarea prilor componente ntr-un tot unitar. De asemenea aceste reguli trebuie s permit programatorilor s neleag i s utilizeze n condiii ct mai bune componente ale programului elaborate de ctre alte persoane, indiferent de limbajul de programare folosit. Asamblarea programelor scrise n mai multe limbaje de programare se face de regul prin utilizarea bibliotecilor de programe n limbaj obiect relocabil. n acest fel, anumite componente ale programului, scrise n diferite limbaje, vor alctui biblioteca 118

sau modulul relocabil, care va fi apelat de programul principal ce este scris n alt limbaj de programare. Pentru informaii suplimentare se va consulta din cursul Microprocesoare, autor Rotar Dan, paragraful 1.3. Etapele elaborrii unui program n cod main i paragraful 2.9. Scrierea aplicaiilor Windows n limbaj de asamblare. n aceast lucrare de laborator se va studia realizarea programelor n mai multe limbaje de programare, sub sistemul de operare Windows, folosind bibliotecile dinamice de tip DLL (Dynamically Linked Libraries). Bibliotecile pot fi legate cu fiierele executabile n dou moduri: legtura static reprezint metoda de combinare a subprogramelor din bibliotec cu aplicaia. Atunci cnd construim un program, linkeditorul caut n toate bibliotecile funciile nedefinite apelate n program i dac acestea sunt gsite atunci se copiaz codul corespunztor din bibliotec n programul executabil. Aciunea linkeditorului continu pn cnd sunt rezolvate toate referinele din program. Aceast metod este cea mai comun n utilizarea bibliotecilor. Aceast metod este simpl i uor de realizat conducnd la obinerea unor programe ce sunt executate cu vitez mare dar prezint dezavantajul c duce la obinerea unor fiiere voluminoase. n legarea dinamic, funciile necesare sunt compilate i stocate ntr-o bibliotec ce are extensia DLL. Spre deosebire de legarea static, n legarea dinamic nu se copiaz cod din librrie n fiierul executabil. n schimb, fiierul executabil pstreaz numele bibliotecii DLL n care se gsesc funciile necesare iar atunci cnd se execut programul se vor ncrca n memorie funciile necesare direct din bibliotec. Metoda conduce la obinerea unor fiiere executabile de dimensiuni mici cu preul scderii vitezei de execuie. Pentru nceput se va realiza o bibliotec dinamic n limbaj C care va fi folosit ntr-un program scris n C++. Pentru aceasta se va folosi mediul de programare DEVC++ versiunea 4.9.9.2. Vom realiza mai nti biblioteca dinamic DLL care conine funciile: adunare, scdere, nmulire i mprire. Se deschide mediul de programare DEV-C++ se selecteaz din meniul principal Fiier dup care se selecteaz Nou i din meniul afiat: Proiect. Din fereastra deschis se alege proiect DLL scris n limbaj C.

119

Se deschide o machet pentru realizarea unei biblioteci dinamice care presupune completarea a dou fiiere: dll.h i dllmain.c. Fiierul dll.h completat cu declararea celor patru funcii definite in biblioteca dinamic este: #ifndef _DLL_H_ #define _DLL_H_ #if BUILDING_DLL # define DLLIMPORT __declspec (dllexport) #else /* Not BUILDING_DLL */ # define DLLIMPORT __declspec (dllimport) #endif /* Not BUILDING_DLL */ //elemente introduse de programator DLLIMPORT int adunare (int, int); DLLIMPORT int scadere (int, int); DLLIMPORT int inmultire (int, int); DLLIMPORT int impartire (int, int); //sfirsitul sectiunii elementelor introduse #endif /* _DLL_H_ */ iar fiierul dllmain.c este: /* Replace "dll.h" with the name of your header */ #include "dll.h" #include <windows.h> #include <stdio.h> #include <stdlib.h> //corpul functiilor DLLIMPORT int adunare (int a, int b) { return (a+b); } DLLIMPORT int scadere (int a, int b) { return (a-b); } DLLIMPORT int inmultire (int a, int b) { return (a*b); } DLLIMPORT int impartire (int a, int b) { return (a/b); } 120

//sfirsitul sectiunii BOOL APIENTRY DllMain (HINSTANCE hInst /* Library instance handle. */ , DWORD reason /* Reason this function is being called. */ , LPVOID reserved /* Not used. */ ) { switch (reason) { case DLL_PROCESS_ATTACH: break; case DLL_PROCESS_DETACH: break; case DLL_THREAD_ATTACH: break; case DLL_THREAD_DETACH: break; } /* Returns TRUE on success, FALSE on failure */ return TRUE; } Dup completarea acestor dou fiiere se selecteaz Execuie din meniul principal i de aici Compilare. Compilarea trebuie s se fac fr erori. n caz contrar se corecteaz erorile. Utilizarea bibliotecii dinamice se va face ntr-un program scris n C++. Pentru aceasta se deschide un proiect nou n mediul de programare DEV-C++ i se alege o aplicaie de tip Console Application scris n limbaj C++ ca n figura urmtoare.

121

n macheta oferit, main.cpp se introduc completrile urmtoare: #include <cstdlib> #include <iostream> using namespace std; //declararea sabloanelor functiilor extern "C" __declspec (dllexport) int adunare (int, int); extern "C" __declspec (dllexport) int scadere (int, int); extern "C" __declspec (dllexport) int inmultire (int, int); extern "C" __declspec (dllexport) int impartire (int, int); //sfirsit sectiune int main(int argc, char *argv[]) { //verificarea functiilor din biblioteca DLL cout << "Verificare DLL" << endl << endl; cout << "Adunare: " << adunare(4,5) << endl; cout << "Scadere: " << scadere(4,5) << endl; cout << "Inmultire: " << inmultire(4,5) << endl; cout << "Impartire: " << impartire(4,5) <<endl; //sfirsit sectiune system("PAUSE"); return EXIT_SUCCESS; } n directorul n care este salvat acest program, se copiaz din directorul n care a fost realizat biblioteca DLL, fiierele: Proiect1.dll i libProiect1.a, unde Proiect1.dll este biblioteca dinamic creat i libProiect1.a conine informaiile necesare linkeditorului pentru realizarea legturilor cu biblioteca dinamic. Pentru a furniza linkeditorului aceast informaie, se selecteaz din meniul principal Proiect, apoi din meniul desfurat Opiuni Proiect iar n fereastra deschis se selecteaz Parametri i de aici selectm fereastra Editor de Legturi apoi se face clic pe butonul Adugare Bibliotec sau Ok. n fereastra deschis selectm libProiect1.a pentru a-l introduce n fereastra editorului de legturi. Dup ce fiierul libProiect1.a apare n fereastra editorului de legturi, se apas butonul Ok. Selectm acum din meniul principal Execuie i apoi Compilare i obinem fiierul Proiect2.exe dac nu au fost erori. Programul Proiect2.exe va folosi biblioteca dinamic Proiect1.dll pentru utilizarea funciilor adunare, scdere, nmulire i mprire. Lansnd n execuie Proiect2.exe se afieaz:

122

Exist unele lucruri de care trebuie s inem seama atunci cnd vrem s folosim DLL-uri create n alt limbaj de programare. Prima idee se refer la faptul c nu exist compatibilitate ntre clasele create n limbaje diferite. Dac dorim o soluie orientat obiect independent de limbaj, trebuie s apelm la tehnologia COM. Totui, putem folosi funcii create n alte limbaje, cu condiia asigurrii mijloacelor necesare accesrii acestora n cadrul DLL-urilor. Regula de care trebuie s inem cont este convenia de apel (calling convention). Ori de cte ori o funcie este apelat, parametrii trimii sunt introdui n stiv. Cnd cursul execuiei ajunge n cadrul funciei, parametrii sunt scoi din stiv i prelucrai. Problemele apar atunci cnd diferitele limbaje folosesc diferite metode pentru stocarea i recuperarea parametrilor n/din stiv. De exemplu, limbajul C introduce parametrii n stiv n ordine invers fa de cum apar n prototipul funciei. Primul parametru din apel se va gsi n vrful stivei. n acest mod este posibil apelarea unei funcii cu un numr variabil de parametri. Invers, limbajul Pascal introduce parametrii n stiv n ordinea n care ei apar n apel. Dac ordinea parametrilor este ncurcat, programul probabil c va genera erori critice. Microsoft au scris iniial DLL-urile n mediul win16 pentru a dispune de o convenie de apel compatibil cu versiunea lor (acum defunct) de Pascal. Aceast convenie, numit stdcall, a devenit standardul de facto de trimitere a parametrilor ctre un DLL. Delphi folosete o convenie numit fastcall, n care parametrii sunt trimii prin intermediul regitrilor. C i C++ folosesc convenia de apel cdecl. Toate aceste convenii sunt suficient de diferite ntre ele pentru a fi incompatibile. Utilitarul Borland impdef.exe poate lista numele funciilor exportate dintr-un DLL. Bibliotecile dinamice pot fi utilizate simplu n Visual Studio 6.0. Putem realiza biblioteca n Visual C++ 6.0 i apoi s o folosim n Visual Basic 6.0. Pentru a crea fiierul DLL se deschide mediul Visual C++ dup care se selecteaz din meniul principal File apoi New. Din fereastra deschis selectm Project i de aici Win32 Dynamic-Link Library, dup care se scrie la Project name: Exemplul1, se selecteaz locul unde va fi salvat proiectul i se apas Ok.

123

Apare o nou fereastr unde se selecteaz A simple DLL project i apoi Finish. Este creat structura necesar de fiiere din care selectm fiierul Exemplul1.cpp care se gsete n seciunea Source Files a proiectului Exemplul1. La acest fiier se adaug urmtoarea secven: int _stdcall sum(int x , int y) { return x+y; }

Trebuie creat acum un fiier .DEF care s informeze linkeditorul s exporte funcia sum. Pentru a realiza acest lucru, din meniul principal se selecteaz File i de aici New. n fereastra aprut la Files se selecteaz Text File i se stabilete pentru acest fiier numele Exemplul1.def. n fiierul gol aprut se adaug liniile: LIBRARY Exemplul1 EXPORTS sum @1 Dup ce fiierul Exemplul1.def a fost salvat se selecteaz Build i de aici Build Exemplul1.dll. Procesul de realizare a bibliotecii dinamice trebuie s se ncheie fr erori. La sfrit, fiierul Exemplul1.def se va gsi n directorul Debug. 124

Vom trece acum la testarea bibliotecii dinamice n mediul Visual Basic 6.0. Pentru aceasta se deschide Visual Basic 6.0 i se creeaz un proiect Standard EXE nou. Se realizeaz forma prezentat mai jos :

n aceast form se scrie codul: Private Declare Function sum Lib "Exemplul1.dll" (ByVal x As Long, ByVal y As Long) As Long Private Sub Command1_Click() Text3.Text = Str(sum(CInt(Text1.Text), CInt(Text2.Text))) End Sub Pentru testare se copiaz fiierul Exemplul1.dll n directorul n care se gsete proiectul Visual Basic. Pentru realizarea lucrrii de laborator studenii se mpart n grupe de cte dou echipe. Fiecare echip va programa ntr-un limbaj de programare diferit. O echip va realiza biblioteca dinamic i cealalt programul pentru utilizarea bibliotecii dinamice conform exemplelor prezentate. Echipa care face utilizarea bibliotecii dinamice va stabili documentaia pentru echipa care ntocmete biblioteca dinamic (cerine impuse) iar echipa care elaboreaz biblioteca dinamic va ntocmi documentaia de utilizare a bibliotecii. Referatele de laborator vor conine documentaiile realizate, programele i rezultatele obinute.

Laborator 13. Analiza metodelor de verificare a programelor

n lucrarea de laborator se va analiza modalitatea de aplicare a tehnicilor de verificare a programelor, descrise n curs la capitolul patru pentru programele elaborate n laboratorul numrul 12. Referatele de laborator vor conine analizele efectuate, codul programelor de verificare realizate i concluzii.

125

NTREBRI DE TEST
1. Alegei varianta corect din cele prezentate mai jos referitor la tehnica topdown. A. Tehnica top-down reprezint o metod de concepere, testare i depanare a produselor program. B. Tehnica top-down reprezint o metod de transfer a datelor ntre modulele program. C. Tehnica top-down reprezint o metod de apelare a subprogramelor. 2. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). n cazul pseudocodului, partea iterat a unei iteraii, n funcie de rezultatul testului logic, poate fi executat de mai multe ori sau cel puin o dat. A. ADEVRAT B. FALS 3. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Tehnica top-down presupune structurarea ierarhic a unui program. A. ADEVRAT B. FALS 4. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). O rutin este slab cuplat dac ea prezint o cardinalitate sczut i intimitate, vizibilitate i flexibilitate crescute. A. ADEVRAT B. FALS 5. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Este bine s se fac definirea tipurilor existente de variabile ntr-un limbaj de programare n scopul creterii claritii programului. A. ADEVRAT B. FALS 6. Alegei varianta cea mai corect din cele prezentate mai jos. n cazul scrierii codului program, dicionarul de date reprezint: A. Traducerea n limba utilizatorului a numelor variabilelor. B. Un set de comentarii asociat cu declaraiile variabilelor care descrie scopul i numele fiecrei variable. C. Un set de comentarii care arat care sunt variabilele utilizate n comun de rutinele programului. 7. Alegei varianta incorect din cele prezentate mai jos. O structur de control este reprezentat de succesiunea de instruciuni: A. if ... then ... else ... endif. B. loop ... endwhile ... endloop. C. select ... case ... default ... endselect. 126

8. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Instruciunile de tip GOTO trebuie utilizate ct mai des pentru mbuntirea lizibilitii programului. A. ADEVRAT B. FALS 9. Alegei varianta corect din cele prezentate mai jos referitor la identarea codului unui program: A. Identarea codului surs reprezint modul de utilizare a variabilelor. B. Identarea codului surs permite creterea lizibilitii programului. C. Identarea codului surs permite determinarea coeziunii rutinelor. 10. Alegei rspunsul cel mai potrivit din variantele prezentate mai jos. Metoda aseriunilor invariante este: A. O metod de transmitere a variabilelor ntre subprograme. B. O metod de verificare a corectitudinii programelor. C. O metod de determinare a sfritului iteraiilor. 11. Alegei varianta corect din cele prezentate mai jos referitor la tehnica bottomup. A. Tehnica bottom-up reprezint o metod de concepere, testare i depanare a produselor program. B. Tehnica bottom-up reprezint o metod de transfer a datelor ntre modulele program. C. Tehnica bottom-up reprezint o metod de apelare a subprogramelor. 12. Alegei varianta incorect din cele prezentate mai jos. n cazul limbajului pseudocod: A. Secvena poate avea dou sau mai multe pri componente reprezentate de instruciuni elementare. B. Secven va fi executat de zero, o dat, sau de mai multe ori n funcie de rezultatul unui test logic. C. Secvenele compuse pot conine la rndul lor alte secvene. 13. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Tehnica bottom-up presupune modularizarea programelor. A. ADEVRAT B. FALS 14. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Rutinele de calitate prezint o coeziune procedural crescut i o coeziune funcional i logic sczut. A. ADEVRAT B. FALS 15. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Un modul trebuie s implementeze un tip de date abstract. A. ADEVRAT B. FALS 127

16. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Un produs program poate fi realizat n mai multe limbaje de programare. A. ADEVRAT B. FALS 17. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Se vor folosi ntotdeauna omonimele pentru stabilirea numelor variabilelor. A. ADEVRAT B. FALS 18. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Operatorul + este un operator unar. A. ADEVRAT B. FALS 19. Alegei rspunsul cel mai potrivit din variantele prezentate mai jos. Testarea programelor poate fi: A. Testare funcional. B. Testare structural. C. Testare funcional i structural. 20. Alegei varianta incorect din cele prezentate mai jos. Un algoritm poate fi descris prin: A. Schema logic. B. Limbaj pseudocod. C. Limbaj formal. 21. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). n cazul iteraiei repeat ... until ... partea iterat se execut cel puin o dat. A. ADEVRAT B. FALS 22. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Rutinele de calitate prezint o nalt coeziune la nivel de instruciune i o coeziune funcional i logic sczut. A. ADEVRAT B. FALS 23. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). O rutin de calitate are dimensiunea standard de 150 linii. A. ADEVRAT B. FALS 24. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Programarea n limbaje de programare diferite impune stabilirea unor reguli comune de ntocmire a programelor pentru compatibilizarea acestora n vederea realizrii produsului program final. A. ADEVRAT B. FALS 128

25. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Este indicat ca numele rutinelor din bibliotecile standard ale limbajului de programare utilizat s fie redefinite n funcie de necesitile programatorului. A. ADEVRAT B. FALS 26. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Este indicat ca ntr-un program s fie utilizat n mod consecvent acelai tip de bucl. A. ADEVRAT B. FALS 27. Alegei varianta corect din cele prezentate mai jos. Principalele elemente componente ale pseudocodului sunt: A. Secvena, iteraia i selecia. B. Secvena, iteraia i modulul. C. Secvena, obiectul i iteraia. 28. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). n cazul iteraiei while ... do ... partea iterat se execut cel puin o dat. A. ADEVRAT B. FALS 29. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Pentru realizarea unui cod de calitate, rutinele trebuie s fie caracterizate de o cuplare ct mai mare. A. ADEVRAT B. FALS 30. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Cuplarea rutinelor se refer la modul n care rutinele respect descrierea n limbaj pseudocod. A. ADEVRAT B. FALS 31. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Declararea explicit a variabilelor trebuie evitat atunci cnd limbajul de programare utilizat nu solicit n mod expres acest lucru. A. ADEVRAT B. FALS 32. Alegei varianta cea mai corect din cele prezentate mai jos: A. n numele variabilelor trebuie folosite prescurtri n aa fel nct descrierea s fie complet. B. Primele caractere utilizate n desemnarea numelui variabilelor sunt de regula cele mai importante la citirea unui cod. C. Numele variabilelor trebuie scrise obligatoriu cu litere mari.

129

33. Alegei varianta incorect din cele prezentate mai jos. n cazul seleciilor cu mai multe ci (case/switch) condiiile de selecie trebuie s fie: A. Sortate n ordine alfabetic. B. Sortate n funcie de lungimea codului. C. Sortate n ordine numeric. 34. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Este bine ca n program structurile de control iterative s aib ct mai multe puncte de intrare n funcie de condiiile impuse de algoritm. A. ADEVRAT B. FALS 35. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Intrrile i ieirile unui modul reprezint interfeele modulului. A. ADEVRAT B. FALS 36. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Comentariul unui program va fi adugat la finalizarea acestuia pentru a evita rescrierea comentariului la modificarea programului. A. ADEVRAT B. FALS 37. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Este bine ca un program s fie ct mai bine comentat chiar dac uneori comentariul este irelevant. A. ADEVRAT B. FALS 38. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). n proiectarea modular strategia cea mai bun a programatorului este aceea de a minimiza legturile n interiorul fiecrui modul i de a maximiza legturile ntre module. A. ADEVRAT B. FALS 39. Alegei varianta corect din cele prezentate mai jos. O structur de program trebuie s fie rezistent la modificri. Acest lucru se refer la: A. Structura de program nu trebuie s permit modificri. B. Structura s permit modificri ale simbolurilor ce marcheaz blocurile. C. Aranjarea structurii (schema de identare) s permit modificarea simpl a blocurilor. 40. Alegei varianta corect din cele prezentate mai jos. Dac o list de parametri ai unei proceduri sau funcii este lung, acetia se scriu: A. Concentrat ct mai muli parametri pe linie, la nceputul procedurii sau funciei. B. Fiecare parametru separat pe cte o linie. C. Diferit, n funcie de procedurii sau a funciei.

130

41. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Un algoritm poate avea zero sau mai multe ieiri. A. ADEVRAT B. FALS 42. Alegei varianta corect din cele prezentate mai jos. Dac n cazul unei iteraii se dorete s existe posibilitatea ca instruciile din corpul iteraiei s nu fie executate, se alege iteraia: A. repeat .. until B. while .. do C. nici una dintre acestea 43. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). n general este indicat folosirea parametrilor globali n defavoarea celor locali. A. ADEVRAT B. FALS 44. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Metoda testrii drumurilor reprezint o metod de testare n care datele se aleg n aa fel nct s se parcurg cel puin o dat fiecare drum din graful programului. A. ADEVRAT B. FALS 45. Alegei varianta corect din cele prezentate mai jos. Unul din principiile ingineriei programrii este ncapsularea care reprezint: A. identificarea proprietilor generale, comune unor entiti diferite, ignornd temporar diferenele dintre acestea; B. (acoperirea sau ascunderea) elementelor neeseniale de implementare tehnic, la nivelurile inferioare, pentru a reliefa numai elementele abstracte eseniale, necesare unui modul; C. includerea tuturor elementelor constitutive (date i operaii) fr omisiuni. 46. Alegei varianta corect din cele prezentate mai jos. Prima etap n programarea unei probleme este: A. selecia algoritmilor i a structurilor de date; B. definiia problemei; C. specificarea structurii i a logicii programelor. 47. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). n etapa definirii problemei n vederea programrii acesteia trebuie s existe i specificaii asupra datelor de intrare i de ieire. A. ADEVRAT B. FALS 48. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Codul unui program se numete pseudocod. A. ADEVRAT B. FALS 131

49. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Documentaia intermediar servete pentru reprezentarea produsului n etapele de proiectare i pentru comunicarea ntre echipa de realizare i ali specialiti. A. ADEVRAT B. FALS 50. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Robusteea i potena unui modul reprezint noiuni identice. A. ADEVRAT B. FALS 51. Alegei varianta corect din cele prezentate mai jos. Unul din principiile ingineriei programrii este completitudinea care reprezint: A. Identificarea proprietilor generale, comune unor entiti diferite, ignornd temporar diferenele dintre acestea; B. (acoperirea sau ascunderea) elementelor neeseniale de implementare tehnic, la nivelurile inferioare, pentru a reliefa numai elementele abstracte eseniale, necesare unui modul; C. Includerea tuturor elementelor constitutive (date i operaii) fr omisiuni. 52. Alegei varianta corect din cele prezentate mai jos. Etapa care urmeaz definirii problemei n programarea unei probleme este: A. selecia algoritmilor i a structurilor de date; B. codificarea; C. specificarea structurii i a logicii programelor. 53. Alegei rspunsul corect, n funcie de modul n care definiia urmtoare este corect (ADEVRAT) sau incorect (FALS). Cardinalitatea unei rutine reprezint rangul acesteia ntr-un modul. A. ADEVRAT B. FALS

132

1. Pilat Florin, s.a. - Metode, tehnici i instrumente n ingineria programrii, EdituraTehnic, Bucureti 1985 2. Vaduva Ilie, Baltac Vasile, Florescu Vasile, s.a. - Ingineria programrii. Vol I, II Editura Academiei, Bucureti, 1986 3. Geber T. s.a. - Fiabilitatea mentenabilitatea sistemelor de calcul, Editura Tehnic, Bucureti, 1984 4. Mihalache Adrian - Cnd calculatoarele greesc. Fiabilitatea sistemelor de programe (software), Editura Didactic i Pedagogic, Bucureti, 1995 5. Livovschi Leon - Scheme logice, Editura Tehnic, Bucureti 1980 6. Boldur-Latescu Gh., Ciobanu Gh., Bncil I. - Cartea analistului de sisteme, Editura tiintific i Enciclopedic, Bucureti, 1976 7. Constantinescu Paul, Negoita Constantin Virgil - Sistemele informatice, modele ale conducerii i sistemelor conduse, Editura Tehnic, Bucureti, 1975 8. Dodescu Gh. Informatica, Editura tiinific i Enciclopedic, Bucureti, 1987 9. Ignat Clin s.a. - Elemente de informatic i calcul numeric vol.1 i 2, Universitatea Al.I. Cuza, Iai 1989 10. Livovschi L., s.a. - Bazele informaticii, Editura Didactic i Pedagogic, Bucureti 1981 11. Rosculet M., s.a. - Programarea i utilizarea mainilor de calcul i elemente de calcul numeric i informatic, Editura Didactic i Pedagogic, Bucureti 1980 12. McConnell Steve - Code Complete, Microsoft Press

133