Proiectarea Software - Modele alearii software

Proiectarea Software -

Introducere

Este esential sa dezvoltam un model pentru sistem, inainte de a incepe sa scriem cod ce va fi folosit pentru controlarea sistemului sau interactiune cu acesta. Modelarea software-ului este probabil partea cea mai grea a proiectarii software. Producerea de design-uri software bune necesita experienta practica considerabila, cu destul de mult feedback asupra calitatii design-ului si cu influentarea design-ului urmatorului sistem software de catre produsele software rezultate anterior.

Privim proiectarea software ca un proces iterativ, cu scopul de imbunatatire a design-ului la fiecare iterare. Scopul acestui curs este de a discuta anumite principii de baza care pot ghida procesul de proiectare software. Aceste principii vor fi ilustrate prin mai multe exemple.

Sunteti cu siguranta constienti ca are loc o schimbare fundamentala in industria software. Exista un accent puternic asupra tehnologiilor orientate pe obiecte si a reutilizarii software. Anumite aspecte ale metodologiei orientarii pe obiecte sunt atat de diferite de aspectele corespondente ale abordarii standard, procedurale ale design-ului software incat ele ar trebui discutate separat.

Totusi, un efort curent considerabil al ingineriei programarii curente este in continuare mult mai concentrat asupra analizei cerintelor, design, implementare, testare si mentenanta programelor care au fost dezvoltate sub o abordare procedurala (mult mai familiara) decat al celor ce folosesc tehnici orientate pe obiecte. Din acest motiv, un inginer software trebuie sa fie familiarizat cu proiectarea ambelor tipuri de sisteme software.

Solutia noastra, corespunzatoare atat ingineriei programarii curente cat si celei prevazute in viitor, este de a utiliza o abordare hibrida care combina componente scrise fie in limbaje procedurale, fie in cele orientate pe obiecte. In fond, un modul software existent care realizeaza bine o anumita cerinta, nu ar trebui respins unor potentiale reutilizari doar pentru ca noua aplicatie este orientata pe obiecte.

Aceasta abordare hibrida este uzuala in cadrul comunitatii de inginerie a programarii si a fost formalizata de mai multe organizatii. Considerati experienta Ministerului de Aparare SUA, care cheltuie sume enorme de bani pentru dezvoltare si mentenanta software. Un studiu de la sfarsitul anilor '70 ilustra ca software-ul este dezvoltat sau mentinut in peste 1600 limbaje si dialecte diferite ale calculatorului. Aceasta a constituit motorul dezvoltarii limbajului de programare Ada, proiectat pentru a face uz de lectiile invatate in numerosii ani de dezvoltare software.

Limbajul Ada a incorporat multe dintre aceste lectii, inclusiv ascunderea informatiei, compilarea separata a interfetelor si comunicatiilor interne software cu ajutorul specificatiilor de pachet si corpuri, suport pentru polimorfism si abstractizare prin "generice" si tipizare tare.

La fel de importanta a fost standardizarea limbajului si validarea compilatoarelor Ada, precum si indeplinirea standardelor de limbaj. Un "mandat Ada" necesita ca toate noile dezvoltari software ale Ministerului de Aparare SUA sa fie realizate in Ada, daca nu existau motive substantiale, bine documentate care sa determine o exceptie a mandatului. (complexitatea limbajului Ada a facut dificila producerea de cod executabil rapid cu prima generatie de compilatoare Ada, si astfel, majoritatea exceptiilor se bazau pe nevoia de eficienta in timpul rularii).

Aproape simultan cu actualizarea limbajului Ada (in 1995) in scopul tintirii aspectelor de eficienta si crestere a suportului pentru dezvoltare software orientata pe obiecte, mandatul Ada a fost modificat pentru a reflecta explozia de produse software de inalta calitate si cantitatile enorme de software deja dezvoltat in limbaje de programare orientate pe obiecte si de alt tip. Importanta marita a produselor COTS si a reutilizarii reiese clar din noul mandat, descris in Tabelul 1.

Restul acestui capitol va fi organizat astfel: mai intai vom prezenta cateva principii de design atat de baza, cat si de scop general. Anumite principii de design se vor baza pe tehnica de baza de potrivire a modelelor software. Scopul este de a reutiliza componentele software la un nivel cat mai ridicat posibil.

Aceasta discutie va fi urmata de anumite reprezentari utilizate in mod uzual pentru proiectarea sistemelor orientate pe proceduri, cu exemple ale fiecarei reprezentari. Dupa finalizarea discutiei initiale asupra proiectarii sistemelor orientate pe proceduri, vom discuta despre software orientat pe obiecte, in aceeasi maniera.

Ultimele trei sectiuni ale cursului vor fi dedicate in primul rand proiectarii exemplului inceput mai devreme, in cursurile anterioare. Acest exemplu va fi discutat in detaliu. Vom pune accent in mod special asupra acelor aspecte care se ridica datorita combinarii necesare a design-urilor procedurale si orientate pe obiecte.

Tabelul 1

Rezumatul celei mai recente versiuni a mandatului Ada pentru sisteme software ale Ministerului Apararii, cu solutiile software preferate ilustrate in ordinea preferintelor.

Sursa: DOD 5000.2-R , articolul 3.5 Software Engineering (Modificare trei, 23 Martie 1998), informatii de pe site-ul web https://sw-eng.falls-church.va.us/dod5000-2.html

2. Modele ale proiectarii software

Un posibil mod de proiectare software este sa incercam sa potrivim problema care trebuie rezolvata cu un sistem software deja existent care rezolva acelasi tip de problema. Aceasta abordare reduce cel putin o portiune a proiectarii software la modelul corespunzator. Eficacitatea depinde de un set anterior dezvoltat de    module software si o cale de recunoastere a diferitelor modele.

Urmatoarele reprezinta cateva tipuri de modele care par sa apara incontinuu in dezvoltarea software. Aceste modele (de nivel relativ inalt) sunt:

1. Un sistemul condus de meniuri (menu-driven), in care utilizatorii trebuie sa parcurga prin mai multi pasi intr-o ierarhie cu scopul de a indeplini munca pe care el sau ea vrea sa o efectueze. Meniurile poate de tipul "trage-jos" (pull-down), uzuale in cazul calculatoarelor personale, sau pot fi in intregime bazate pe text.

2. Un sistem condus de evenimente (event-driven), in care utilizatorii trebuie sa selecteze pasii in scopul efectuarii muncii pe care el sau ea doreste sa o execute. Pasii nu trebuie sa fie facuti intr-o ordine ierarhica. Acest model este cel mai uzual intalnit in controlul proceselor concurente, cand actiunile se pot repeta in mod nedefinit, in contrast cu modelul numarul 3. Este de asemenea tipicul unei interfete cu utilizatorul ghidate prin selectarea optiunilor din meniuri si combinatii de taste, precum meniuri care apar (pop-up) ca raspuns la cererile utilizatorului. In orice caz, este mai putina ierarhie ca in modelul anterior.

3. Un sistem in care actiunile intreprinse depind de o anumita stare dintre un numar mic de stari si de un set mic de actiuni optionale care pot fi intreprinse pentru fiecare stare. Actiunea optionala intreprinsa depinde atat de starea cat si de valoarea unui cadru de control de intrare (input token). In acest model cadrele de intrare sunt in mod obisnuit prezentate ca flux. O data ce un cadru de intrare este procesat, acesta este indepartat din fluxul intrarilor.

Un sistem in care este procesata o secventa de cadre de intrare (de obicei in format text), cate un cadru de intrare o data. Acest model difera de modelele anterioare prin faptul ca decizia referitoare la actiunea intreprinsa poate sa depinda de mai multa informatie decat disponibila din perechea constituita de stare si cadrul de intrare. In acest model, cadrele de intrare pot sa ramana in fluxul de intrari si in urma procesarii.

5. Un sistem in care este cautata una sau mai multe informatii specifice in cadrul unei cantitati mari de informatie. Cautarile pot sa apara de una sau de mai multe ori.

6. Un sistem care poate fi utilizat in diferite aplicatii, dar care trebuie ajustat pentru a functiona corespunzator pentru noi setari.

7. Un sistem in care totul este ghidat primordial de un algoritm, mai degraba decat dependenta primordiala de date.

8. Un sistem distribuit, cu mai multe actiuni de procesare relativ independente care sunt intreprinse. Cateva dintre actiunile de procesare pot comunica cu alte actiuni de procesare.

Cate dintre aceste modele va sunt familiare? Primele doua descriu interfetele om-calculator,    prima fiind un sistem rigid codus de meniuri, iar cealalta fiind controlata de actiuni precum deplasarea unui mouse sau a altor pointeri si apasarea unui buton.

Modelul software numarul trei descrie ceea ce este deseori cunoscut ca "masina starii finite" sau "automat finit determinist". Acest model este in mod special folositor in controlarea unor procese in intreprinderi de productie.

Modelul numarul 4 apare folosit deseori in software-ul utilitar. Reprezinta baza pentru analizatorii lexicali si pentru actiunile analizei sintactice a compilatoarelor. Multe sisteme software prezinta o anumit analiza sintactica pentru procesarea comenzilor de intrare.

Evident, modelul software numarul 5 se refera la    problema cercetarii bazei de date.

Modelul numarul 6 este unul general, dar care sugereaza ca exista un sistem scop-general care trebuie configurat special pentru fiecare setare a aplicatiei. Instalarea unei imprimante pentru un calculator personal (sau o retea de calculatoare) urmeaza acest model.

Modelele software 7 si 8 sunt de asemenea foarte generale. Totusi, modelul 7 pare sa sugereze ca solutia va avea o natura procedurala, in timp ce modelul 8 ar putea fi mai potrivit unei solutii care utilizeaza metode orientate pe obiecte.

Aceste modele software nu reprezinta reguli absolute. Nici nu sunt intentionate drept clasificare completa a software-ului. Totusi, ele ne pot ghida in proiectarea si implementarea portiunilor procesului de dezvoltare software.

Remarcam explicit ca nu este necesar ca intregul sistem software considerat sa se potriveasca cu unul dintre modele de mai sus. Este perfect rezonabil sa avem diferite portiuni ale aceluiasi sisteme software care sa se potriveasca mai multe modele diferite. Este cazul intalnit atunci cand vom discuta exemplul proiectului nostru major, mai tarziu in acest capitol.

Separarea unui sistem software in mai multe subsisteme este uzuala in timpul proiectarii software. Intr-adevar, un fel de imbunatatire pas cu pas a design-urilor este esentiala pentru un proces de proiectare software eficient. Descompunerea    design-ului sistemului va fi o tema repetata de-a lungul acestui curs. Pentru moment, vom ignora descompunerea sistemului si ne vom indrepta atentia asupra modelelor software.

Sa luam in considerare modul in care pot fi folosite aceste modele ca parte a procesului de proiectare. Presupunem ca am recunoscut un model particular ca fiind aplicabil sistemului software pe care trebuie sa il proiectam. In ce directie ne indreptam acum?

Primul pas este de a vedea daca putem sa ne facem munca mai usoara. Mai exact, ar trebui sa cautam in cadrul software-urilor disponibile pentru a determina daca, nu cumva avem deja o solutie partiala sau completa a problemei. Aceasta situatie este un exemplu de reutilizare software, reprezentand cea mai eficienta cale de a produce software. Daca software preexistent rezolva exact problema, atunci am terminat. Modificarile necesare ar trebui comparate cu costul estimat al unui software nou in intregime, pentru a putea vedea daca ar trebui sa incercam sa reutilizam o potrivire partiala. Vom ilustra aplicarea reutilizarii software in cadrul discutiilor referitoare la proiectul major software in sectiunea 16 a acestui curs.

3 Introducere in reprezentarile design-ului software

Orice notatii, tehnici sau instrumente care ne pot ajuta sa intelegem sistemele sau sa le descriem ar trebui sa fie luate in considerare in mod serios de catre persoana care modeleaza sistemul. In aceasta sectiune ne vom concentra toata atentia asupra tehnicilor de modelare si vom discuta pe scurt notatiile folosite in proiectare.

Presupunem ca nu gasim un software existent care poate fie sa rezolve direct problema, fie sa reprezinte o solutie candidat dupa ce a fost modificat. In acest caz, suntem obligati sa proiectam software nou pentru a rezolva problema. Cum vom face aceasta?

Exista diverse moduri de descriere a sistemului software:

Software-ul poate fi descris prin fluxul de control al sistem

Software-ul poate fi descris prin fluxul datelor in cadrul sistem

Software-ul poate fi descris prin actiunile intreprinse de sistem

Software-ul poate fi descris prin obiectele actionate de catre sistem

Prima descriere a software-ului ne conduce la conceptul de graf al fluxului. Primele reprezentarile grafice populare ale design-urilor se numeau fluxuri grafice, fiind orientate pe fluxul de control. Termenul de "flux de control" este o metoda de descriere a unui sistem cu ajutorul blocurilor majore de cod care controleaza operatiile acestuia. In anii '50-'60, un flux grafic se trasa general manual, folosindu-se o notatie grafica ce prezenta controlul programului ca si capete ale unui graf directionat ce descria programul.

Nodurile unui graf flux de control erau casute ale caror forma si orientare oferea informatii aditionale despre program. De exemplu, o casuta dreptunghiulara cu margini orizontale sau verticale simbolizeaza un proces de calcul care apare in punctul respectiv in cadrul programului. O casuta in forma de diamant, cu margini la un unghi de 45° fata de orizontala, se numeste "bloc de decizie". Acesta reprezinta o ramificare in fluxul de control al programului. Se mai utilizeaza si alte simboluri pentru a reprezenta situatii ce apar in mod uzual in comportamentul programului. Un exemplu de graf pentru fluxul de control al unui program ipotetic este prezentat in Figura 1.

Figura 1. Descrierea unui grafic flux de control pentru un program ipotetic

Asa cum am indicat, exista multe simboluri care pot fi folosite in grafurile flux de control. Unealta de desenare din Microsoft Word are 28 de icoane predefinite care reprezinta diferite simboluri utilizate de obicei in cadrul grafurilor flux de control. Cinci dintre acestea sunt ilustrate in Figura 2.

Figura 2. Cateva simboluri folosite uzual in grafice flux de control. Citite in sensul acelor de ceasornic, din partea stanga-sus, simbolurile sunt: "proces", "date", "proces predefinit", "date interne", si "document"

A doua metoda de descriere a design-urilor corespunde reprezentarii fluxului de date a software-ului. Asa cum am mentionat in Cursul 1, reprezentarile fluxurilor de date ale sistemelor au fost dezvoltate ulterior descrierilor pe baza fluxului de control.

Din moment ce date diferite se pot deplasa pe cai diferite in cadrul programului, este uzual ca descrierile de design pe baza fluxului de date sa includa numele datelor pe langa sagetile ce indica directia deplasarii datelor. Exista diferite notatii ce sunt utilizate pentru diferite tipuri de tratare a datelor. De exemplu, un nod al grafului reprezentand o transformare a datelor de intrare in date de iesire pe baza unei anumite reguli ar putea fi reprezentat printr-un bloc dreptunghiular. O sursa de date de intrare ale unui flux (stream), precum un terminal de intrare interactiv, ar fi reprezentat printr-o alta notatie, indicand faptul ca acesta este o "sursa de date". Pe de alta parte, un depozitar din care datele nu mai pot fi recuperate, precum un terminal ecran, este descris printr-un alt simbol, indicand faptul ca aceasta este o "scurgere de date".

Descrierile tipice ale fluxului de date folosesc diverse diagrame, pe niveluri diferite. Fiecare nivel al unei diagrame a fluxului de date reprezinta o viziune mai detaliata a unei portiuni a sistemului descrise anterior la un nivel mai inalt. O viziune la nivel foarte inalt a analizei preliminare a fluxului de date intr-un program ipotetic este ilustrata in Figura 3. Aceasta diagrama simpla ar fi probabil numita "diagrama a fluxului de date pe nivelul 1", unde nivelul 0 ar consta din simpla reprezentare a intrarilor si iesirilor.

Figura 3. Descrierea de nivel 1 a diagramei unui flux de date (DFD) pentru un sistem ipotetic

A treia metoda de reprezentare a design-ului unui sistem software este in mod clar cea mai potrivita pentru o viziune orientata pe proceduri a sistemului. Ea poate include fie flux de control, fie flux de date, sau chiar descrieri combinate ale software-ului. Notatiile folosite pentru aceasta abordare hibrida nu sunt standard, Un astfel de design poate fi la fel de simplu precum, de exemplu, un bloc din Figura 1. etichetat "Pas 1", pana la graficul flux descris in Figura 3.

In final, cea de-a patra metoda este in mod clar cea mai potrivita unei viziuni orientate pe obiecte a sistemului. Aceasta este evident o paradigma diferita de cele anterioare. Am ales sa folosim o reprezentare modelata, cunoscuta drept UML (Unified Modeling Language). UML este o tentativa de descriere a relatiilor intre obiectele unui sistem, fara a descrie fluxul de control sau transformarile directe ale datelor.

Remarcati ca fiecare bloc ilustrat in Figura 4 reprezinta un obiect pentru care structura de mostenire este in mod clar indicata de directia sagetii: obiectul de tipul Clasa 1 este o superclasa a obiectului de tipul Clasa 3. Intr-un design real ce foloseste modelul obiectual unificat, linia orizontala ar contine informatii despre tipul de relatie (unu-la-unu, multe-la-multe, unu-la-multe) si despre agregarea unor obiecte multiple intr-un singur obiect. Omitem aici aceste detalii.

Figura     O descriere orientata pe obiecte ultra-simplificata a unui sistem ipotetic, folosind notatia UML

Este deseori foarte dificil pentru un inginer software incepator sa determine obiectele corespunzatoare design-ului sistemului software. Cu toate ca exista putine cercetari comparative pentru a sprijini ipoteza ca un design bun orientat pe obiecte este mai greu de creat decat unul care foloseste abordarea traditionala, orientata pe proceduri, consideram totusi ca este nevoie de antrenament considerabil pentru a putea aprecia subtilitatile abordarii orientate pe obiecte. Studentul nefamiliarizat cu abordarea orientata pe obiecte este incurajat sa citeasca acestea si orice discutii inrudite din cadrul cartii, pana se familiarizeaza total cu dezvoltarea software, pentru a intelege de ce au fost luate anumite decizii.

O abordare ajutatoare este de a gandi descrierea functionalitatii unui sistem cu propozitii complete. Verbele propozitiilor sunt actiuni ale sistemului; substantivele reprezinta obiecte. Vom folosi aceasta abordare simpla atunci cand vom dezvolta acea portiune a design-ului proiectului nostru major de inginerie software, pentru care are sens abordarea orientata pe obiecte.

Este normal ca studentul incepator sa se intrebe pentru ce sunt necesare abordari multiple ale reprezentarii design-ului. Bineinteles ca anumite tehnici au fost dezvoltate din motive istorice. Totusi, multe tehnici si reprezentari au supravietuit pentru ca au oferit viziuni alternative utile ale design-ului software.

Familiara problema a sortarii unei matrici ofera o ilustrare buna a deosebirilor celor patru abordari. Sa consideram arhi-cunoscutul algoritm quicksort, dezvoltat de C.A.R. Hoare.

Algoritmul Quicksort partitioneaza o matrice in doua submatrici de marimi poate diferite. Cele doua submatrici sunt separate de un element "pivot", care este cel putin la fel de mare ca toate elementele dintr-o submatrice, si nu este mai mare decat nici un element al celeilalte submatrici. Fiecare submatrice este apoi supusa aceluiasi procedeu. Procesul se incheie cu o matrice complet sortata. Remarcati ca descrierea acestui algoritm este recursiva. Ganditi-va ca algoritmul Quicksort este folosit intr-un design ce trebuie sa indeplineasca anumite cerinte de sortare eficienta a unui set de date de marime necunoscuta.

O descriere a fluxului de control a algoritmului ar conduce la un design puternic dependent de descompunerea logica a logicii programului. Ganditi-va la implementarea algoritmului Quicksort recursiv intr-un limbaj precum FORTRAN sau BASIC, care nu suporta recursivitatea. Logica design-ului ar fi cea mai importanta. Pe de alta parte, seturi de date prea mari ar putea determina mult prea multe niveluri de apeluri de functii recursive, daca se foloseste un algoritm pur recursiv. Aceasta viziune bazata pe fluxul de control ar putea scoate la iveala anumite limitari ale design-ului unui algoritm Quicksort recursiv simplu.

O descriere a fluxului de date a algoritmului ar accentua deplasarea datelor intre matrici si cele doua submatrici de dimensiune mai mica ce sunt create la fiecare iterare a algoritmului Quicksort. Atentia la detaliile rezervarii locatiilor de stocare pentru aceste submatrici ar putea duce la luarea in considerare a situatiei in care nu exista suficient spatiu de memorie.

A treia viziune poate fi obtinuta prin luarea in considerare a unei solutii pur procedurale. In acest caz poate fi folosita o functie de biblioteca standard. De exemplu, biblioteca standard C are o functie numita qsort(), care primeste ca argument o matrice si produce o matrice sortata in aceeasi locatie. Cu alte cuvinte, matricea de intrare este suprascrisa de matricea de iesire.

Utilizatorul functiei qsort() din biblioteca standard C trebuie sa ofere o functie de comparatie pentru a realiza comparatii intre elementele matricei. Prototipul acestei functii de comparatie este ilustrat mai jos:

int * compare(* element1, * element2);

Aceasta functie de comparatie definita de utilizator primeste doua argumente (care reprezinta elemente arbitrare ale matricei) si returneaza 0 daca cele doua argumente sunt egale. Functia de comparatie returneaza -1 daca primul argument este mai mic decat al doilea, si 1 altfel. Numarul de elemente ale matricei si marimea unui element al matricei trebuie furnizate si ele.

Functia qsort() din biblioteca standard C se poate accesa daca se include fisierul antet stdlib.h in cadrul programului C. Aceasta functie are sintaxa:

void qsort(

const void * base,

size_t num_elts,

size_t elt_size,

int (*compare(const void *, const void *)

);

si utilizarea ei tipica este:

ptr = qsort(arr, num_elts, elt_size, compare);

In final, o abordare orientata pe obiecte ar utiliza cel mai probabil o clasa generala pentru matricea de elemente, si ar invoca o functie membru standard pentru sortare. O asemenea functie s-ar gasi in mod uzual intr-o clasa biblioteca a unei clase abstracte. Un exemplu pentru acestea poate fi gasit in bibliotecile claselor oferite cu majoritatea sistemelor de dezvoltare C++.

O clasa generala intr-un sistem orientat pe obiecte va contine metodele care pot fi aplicate obiectului reprezentat de clasa. In C++, metodele asociate cu un obiect se numesc "functii membre" ale clasei. In cazul C++, o descriere de clasa va contine probabil "template-uri", sau clase generalizate in care tipul specific al unui membru al clasei este relevant abia in momentul utilizarii clasei. Astfel, o clasa template poate referi o matrice abstracta de intregi, siruri de caractere, sau alte tipuri relevante pentru care operatiile clasei au sens.

Presupunand ca metodele unei clase template pot fi implementate pentru un anumit tip de obiect al clasei, metoda generala cunoscuta drept sortare poate fi invocata prin simpla apelare a unei functii membre, de exemplu:

A.sort();

Aici, tipul obiectului A este compatibil cu tipul template-ului, si se foloseste functia membru sort() a acelui obiect.

Chiar si pentru cazurile simple de algoritmi de sortare am vazut mai multe abordari diferite ce pot fi folosite pentru design-ul sistemului software. Fiecare prezinta avantaje si dezavantaje. Nu am analizat in detaliu nici unul dintre dezavantaje. In special, nu am luat niciodata     in considerare problema eficientei unui software scris in concordanta cu unul dintre design-urile descrise anterior. De exemplu, un algoritm de sortare lent, sau unul care foloseste recursivitatea, poate fi total neadecvat pentru multe aplicatii software.

Exista o metoda folosita in mod uzual pentru descrierea unui sistem. Aceasta implica pseudocod care ofera o descriere a sistemului aproape in limba engleza (pentru mediile de dezvoltare software care folosesc limba engleza). Pseudocodul este imbunatatit succesiv pana la implementarea unui cod sursa de incredere, cel putin teoretic. Remarcati ca pseudocodul este o notatie non-grafica. Un exemplu de pseudocod este ilustrat in Exemplul 1. Acesta descrie o portiune a unui sistem de autentificare, de protectie a parolelor intr-un sistem ipotetic.

Exemplul 1 O descriere pseudocod a unui sistem ipotetic

Reprezentarile pseudocod au doua avantaje majore fata de cele grafice: pot fi prezentate ca informatie textuala in fisiere ASCII, si descrierile pseudocod ale sistemelor mari nu sunt cu nimic mai complicate de reprezentat decat cele ale sistemelor mici. Bineinteles, reprezentarile pseudocod pot fi atat de mari si pot avea atat de multe nivele de imbricare a instructiunilor, incat sa devina greu de inteles.

Ar trebui sa remarcati un alt avantaj al reprezentarilor pseudocod folosite pentru design:     ele pot produce documentatie interna instantanee a fisierelor cu cod sursa.

Reprezentarile design-urilor descrise in aceasta sectiune nu epuizeaza insa numeroasele reprezentari disponibile. Alte reprezentari uzuale folosite includ diagramele Buhr, diagramele Booch, schemele HIPO si schemele Nassi-Schneiderman. Diagramele Booch pot fi folosite foarte usor pentru sistemele orientate pe obiecte, in timp ce majoritatea altor reprezentari nu pot. Descrierea fiecareia poate fi gasita in diverse carti de inginerie a programarii si in unele scrieri originale ale inventatorilor acestor notatii.

4 Reprezentarile design-ului orientat procedural

In aceasta sectiune vom oferi exemple ale utilizarii diferitelor reprezentari ale design-ului orientat pe obiecte pentru cazul unui sistem singular. Vom considera cazul aceluiasi sistem pentru exemplificarea reprezentarilor design-ului orientat pe obiecte (in Sectiunea 9).

Consideram o situatie familiara: software care controleaza un concentrator de terminale, adica un dispozitiv hardware care permite mai multor linii de terminal sa acceseze acelasi CPU. Intrarea de la o linie terminal este asociata cu terminalul la care este atasata la capat linia. Iesirea corespunzatoare pentru un program ce ruleaza pe unul dintre terminale este trimisa de la CPU la terminalul de ecran corespunzator.

Pentru a evita ca datele trimise la si de la terminale diferite sa ajunga in alt loc decat cel menit, semnalele sunt "multiplexate" de concentratorul de terminale. Hardware si software pentru multiplexare permit atasarea unor terminale multiple la acelasi port al computerului, permitand astfel un numar mai mare de utilizatori simultan (cu costul potential al reducerii vitezei de procesare). Toate terminalele de pe un concentrator de terminale partajeaza aceeasi conexiune cu computerul, asa cum se arata in Figura 5.

Figura 5. Un concentrator de terminale. Sursa: Leach, Proiectare si programare orientata pe obiecte in C++, Academic Press, 1995

Multiplexarea inseamna ca se foloseste un singur set de cabluri pentru conectarea de la concentratorul de terminale la CPU. Decizia referitoare la care va fi terminalul cu care se face comunicarea prin aceste cabluri poate fi luata utilizand diferite frecvente pentru semnale sau prin atasarea informatiei de rutare la fiecare pachet de informatie trimisa.

Structura de date de baza intr-un sistem multiplexat este coada. Datele unui utilizator sunt trimise de la terminalul lui la CPU printr-un stream, in maniera primul-intrat-primul iesit. Datele parcurg operatia de multiplexare a concentratorului de terminale si sunt trimise la CPU atunci cand procesul este planificat pentru executie. Toate celelalte procese (si I/O de la terminalele lor) asteapta ca procesul sa predea controlul CPU-ului. Datele de iesire sunt apoi trimise de la CPU la terminalul corespunzator, de asemenea cu ajutorul operatiei de multiplexare a concentratorului de terminale.

Astfel, exista cozi de intrare, cozi de iesire si mecanisme de determinare a caror date sunt atasate carui terminal (fie pentru intrare, fie pentru iesire).

O schema a fluxului software-ului care controleaza un concentrator de terminale este ilustrata in Figura 6. Ar trebui sa comparati aceasta figura cu exemplul de pseudocod pentru sistemul concentrator de terminale, ilustrat in Exemplul 2.

Figura 6. Flux de control pentru un concentrator de terminale. Sursa: Leach, Proiectare si programare orientata pe obiecte in C++, Academic Press, 1995

Un exemplu de descriere a fluxului de date a unui program este notatia grafica din Figura 7. Diagrama fluxului de date ilustrata in aceasta figura descrie o directie a fluxului pentru exemplul concentratorului de terminale descris anterior. Sistemul concentratorului de terminale poate fi descris complet printr-o diagrama mai elaborata.

Figura 7. Reprezentarea fluxului de date pentru un concentrator de terminale.

For each terminal

When time for output from CPU

Exemplul 2. O reprezentare pseudocod pentru un concentrator de terminale

In realitate, schimbarile de tehnologie si rasturnarea rapida din industria de inginerie a programarii presupun ca un proiectant software sa fie familiarizat cu mai multe reprezentari diferite ale design-ului.

Modelul entitate-relatie, sau E-R, este uzual design-ului bazelor de date. Altul este modelul informatie, frecvent utilizat in sisteme de inteligenta artificiala si sisteme expert.

O diagrama E-R reprezinta un set de cantitati fundamentale, cunoscute ca entitati, si relatiile dintre acestea. Etichetarea arcelor din diagrama E-R indica natura relatiilor dintre entitatile conectate de aceste arce.

Diagrama E-R poate servi ca punct de pornire pentru un set preliminar de obiecte. Relatiile diagramelor sugereaza deseori metode posibile, sau transformari, ale obiectelor din sistem.

Aceasta metoda este doar un prim pas in dezvoltarea unei descrieri complete a obiectelor si metodelor unui sistem, deoarece diagrama E-R nu prezinta de obicei auto-transformari ale unui obiect. Astfel, constructorii, destructorii si initializatorii nu sunt de obicei evidenti in diagramele E-R. Testele de egalitate sunt in mod normale neclare. Si multe alte metode uzuale sunt greu de reprezentat in diagramele E-R.

Observatiile utilitatii diagramelor E-R in obiecte pot fi sumarizate astfel:

Daca exista deja o diagrama E-R, se utilizeaza entitatile ca alegeri initiale pentru obiecte si metode. Trebuie avut grija in mod special la nevoia de metode de auto-transformare, precum constructori, destructori si initializatori.

Daca nu exista o diagrama E-R, nu va deranjati cu a realiza una. In schimb, continuati cu descrierea obiectelor utilizand direct procesul din Tabelul 2.

5 Arhitecturi software

Termenul "arhitectura software" a fost folosit in multe moduri diferite, deseori contradictorii, in comunitatea inginerilor software. Indiferent de contextul specific, termenul este utilizat de obicei pentru a descrie organizarea sistemelor software.

Definim dupa cum urmeaza: o "arhitectura" este definitia elementelor cheie care constituie un sistem, a relatiilor lor si a oricaror constrangeri. Vom vedea ca arhitecturile sunt constituite din mai multe tipuri, fiecare tip reprezentand la randul lui o arhitectura. Folosim abordarile Ezran, Morisio si Tully in descrierea si clasificarea tipurilor de arhitecturi.

In general, arhitecturile sistemelor bazate pe software pot fi clasificate in mai multe categorii:

O arhitectura de afaceri care descrie structura sarcinilor de afaceri realizate de organizatie si mecanismele prin care sistemul suporta aceste sarcini. Descrierea arhitecturii business este deseori creata de un analist in domeniul afacerilor, expert in acest domeniu.

O arhitectura fizica descrie structura platformelor hardware sau a retelelor pe care va opera sistemul.

O arhitectura logica descrie structura obiectelor aplicatie si de afaceri. Aceasta arhitectura este deseori parte a unei viziuni orientate pe obiecte a unui sistem. Corespunzator, descrierea arhitecturii logice este deseori creata de un analist de obiecte cu experienta in tehnologiile obiectuale.

O arhitectura functionala descrie structura cazurilor posibile de utilizare si cerintele, din punctul de vedere al utilizatorului. Din nou, aceasta arhitectura este deseori parte a unei viziuni orientate pe obiecte a sistemului.

O arhitectura software descrie structura sistemului pe straturi, precum modelul OSI cu sapte niveluri ale comunicatiilor de date sau arhitectura stratificata a sistemului de operare UNIX (vezi Figura 8 pentru o viziune a arhitecturii pe niveluri UNIX). O decizie de descompunere a sistemului in client si server ar fi parte a unei arhitecturi software.

O arhitectura tehnica descrie structura interfetelor majore a arhitecturii software. Elemente ale unei arhitecturi tehnice includ interfetele de programare a aplicatiilor (API), produse program de intermediere (middleware), sisteme de management a bazelor de date, interfete grafice cu utilizatorul si alte produse de "lipire" sau "punte" necesare pentru interfatarea componentelor de pe diferite niveluri ale arhitecturii software. Decizii de a utiliza CORBA, DCOM, Java RMI, sau RPC s-ar reflecta intr-o arhitectura sistem de acest tip.

O arhitectura sistem descrie structura afacerii, a aplicatiei, a scopurilor tehnice si relatiile acestora. Descrierea arhitecturii unui sistem este deseori realizata de un analist de sisteme.

O arhitectura a aplicatiei (deployment architecture) descrie structura de mapare a sistemului si arhitecturilor tehnice in arhitecturi fizice. Arhitectura aplicatiei include o viziune statica a fisierelor de baza care vor fi necesare, si o viziune dinamica a proceselor concurente si firelor (thread), si mecanismele pentru sincronizarea si comunicarea acestora. Deciziile de plasare a unui fir pe un anumit computer, sau de a avea un agent autonom care realizeaza operatii de calcul pe un procesor inactiv, ar fi s-ar reflecta intr-o arhitectura de acest tip.

De ce sunt importante arhitecturile? Succesul modelului OSI si a sistemului de operare UNIX ilustreaza puterea abordarii pe nivele a arhitecturii software. Alte tipuri de arhitectura reprezinta tentative de crestere a nivelului de reutilizare in sisteme, prin incurajarea descrierii sistemelor la nivele diferite de detaliere si abstractizare.

Arhitectura stratificata a sistemului de operare UNIX este ilustrata in Figura 8. Arhitectura arata clar ca, de exemplu, apelurile sistem interactioneaza cu nucleul UNIX prin intermediul "vectorului syscall", ca nucleul UNIX interactioneaza cu hardware-ul prin intermediul driverelor de dispozitiv, samd.

Ar trebui remarcat faptul ca utilizarea unei notatii precum UML (Limbaj de Modelare Unificat) poate promova consistenta printre diferitele viziuni arhitecturale. Fie ca aceasta consistenta poate fi incorporata in unelte CASE si procese de dezvoltare intr-o asemenea maniera incat eficienta sa fie imbunatatita, ramane de vazut, cu toate ca eforturile preliminarii sunt promitatoare.

In acest punct, ne vom multumi cu aceasta descriere de nivel inalt a diferitelor tipuri arhitecturale. Ne vom intoarce la descrierile lor atunci cand vom ilustra proiectarea proiectului nostru software major in sectiunea 17.

Figura 8. Arhitectura pe nivele a sistemului de operare UNIX. Sursa: Leach, Aspecte avansate in UNIX, John Wiley, 1994

6 Principii de proiectare software pentru programe orientate pe proceduri

Inainte de a incepe sa studiem in detaliu reprezentarile proiectarii software, vom introduce un element de realitate in discutie. Consideram cazul unui program de aproximativ 500 linii de cod, cu poate sapte sau opt functii. O viziune de nivel inalt a design-ului programului pare sa fie relativ mica, indiferent de tehnica sau reprezentarea de design folosita. Este probabil ca o viziune completa rezonabila a design-ului sa incapa pe o singura pagina. In mod clar, oricare dintre reprezentarile de design descrise mai devreme in acest curs ar putea fi folosite daca sistemele nu sunt prea complicate.

Nu ar trebui sa ne asteptam ca acesta sa fie cazul programelor realiste, utilizate in industrie sau administratie. Evident, design-ul unui program cu 500.000 linii de cod, peste 2000 functii si flux de control si de date complex, nu poate fi reprezentat corespunzator pe o singura pagina de hartie. Astfel, fiecare tehnica de reprezentare a proiectarii va include anumite metode de descompunere a design-ului in unitati mai mici care sunt legate impreuna.

Un exemplu a acestei abordari cu descompunere: diagrama din Figura 9, preluata dintr-o unealta CASE numita Technology for the Automatic Generation of Systems (TAGS, sau Tehnologie pentru Generare Automata a Sistemelor), oferita de Teledyne Brown Engineering. Versiunea prezentata aici este o versiune publica a uneltei de interfatare implementata pentru Macintosh. Aceasta interfata continea doar portiunea de reprezentare a design-ului pentru tot software-ul. Folosea un limbaj special de descriere a sistemului IORL (Input Output Requirements Language - Limbaj de Cerinte Intrare Iesire). Trasaturi ale uneltei CASE complete includeau verificari de consistenta ale design-elor reprezentate grafic, precum si o posibilitate de generare cod care permitea generarea de cod sursa din descrierea grafica a sistemului.

In Figura 9 vom prezenta doar un exemplu al reprezentarii descompunerii. Aceasta figura descrie interactiunea dintre versiunea Macintosh a lui TAGS (numita MacTAGS) si sistemul de operare Macintosh (MacOS) si cutia de instrumente (toolbox) Macintosh, care contine cateva rutine pentru accesarea utilitatilor grafice Macintosh.

Nu are rost sa discutam in detaliu Figura 7. Totusi, exista anumite aspecte care trebuie remarcate. Casutele sunt conectate cu sageti clar trasate. Este evident ca aceasta s-a facut automat, mai degraba decat cu ajutorul unui simplu pachet de desenare. Sagetile sunt etichetate, oferind mai multe informatii despre interfetele casutelor legate de sageti. Etichetele de pe sageti indica numarul interfetei.

Remarcam ca aceasta unealta CASE este mai mult decat un ajutor de desenare ce ofera o reprezentare grafica a software-ului. Include de asemenea un "editor de context" in sensul ca printr-un dublu clic pe oricare dintre sagetile de interfata sau bloc blocuri cu etichete se ofera acces la informatii detaliate suplimentare, precum creatorul casutei sau interfetei, datele ce trec prin interfata intre diferite blocuri, samd. Aceasta tehnica deosebit de folositoare este similara cu a face clic pe un URL intr-un document mail, cand software-ul de mail Eudora va deschide automat o copie a navigatorului de retea asociat. Aceeasi abordare functioneaza de asemenea si pentru alte aplicatii asociate cu un anumit tip de fisier, precum:

https:// document WWW

.doc document Microsoft Word

.xls document Microsoft Excel

.ppt document Microsoft Power Point

.wp document WordPerfect

.exe fisier executabil MS-DOS

Unealta este chiar mai avansata, asa cum se poate vedea din interconectarea prin retea a software-ului cu alte versiuni. Versiunile avansate ale software-ului pentru retele includ un generator de cod optional, astfel ca poate fi folosita si o reprezentare grafica corecta a proiectului pentru a genera cod sursa pentru software-ul care se proiecteaza. Chiar daca codul sursa generat de aceasta unealta nu este complet sau nu indeplineste cerintele de performanta corespunzatoare, codul sursa produs poate economisi un timp de dezvoltare considerabil.

Figura 9. Un exemplu de reprezentare a proiectului cu ajutorul unei unelte CASE

Revenim acum la studiul descompunerii. Scopul descompunerii proiectului este de a produce un proiect detaliat dintr-unul de nivel foarte inalt. Cat de detaliat ar trebui sa fie un document de proiect detaliat? Ar trebui sa fie suficient de detaliat incat sa permita unuia sau mai multor ingineri software sa implementeze cod sursa doar pe baza acestui document. Codul sursa ar trebui implementat neambiguu, in sensul ca variatii minore ale detaliilor de implementare sa ramana consistente cu design-ul.

Din pacate, nu este foarte bine inteles modul in care alegerea unei reprezentari a proiectului conduce la o anumita descompunere a unui proiect de nivel foarte inalt intr-un proiect mai detaliat. De exemplu, descompunerea unui sistem pe baza analizei fluxului de control ar conduce in mod natural la o descriere a actiunilor intreprinse de sistem.

Pe de alta parte, o tehnica de descompunere bazata pe reprezentarea fluxului de date ar conduce la o descriere detaliata a deplasarii datelor ce are loc in sistem. Transformarile datelor sunt usor de detectat intr-o reprezentare detaliata, bazata pe curgerea datelor.

Alte reprezentari ale proiectului influenteaza diferit abordarea descompunerii proiectului. Efectul pseudocodului, a diagramelor de stare si retelelor Petri vor fi discutate in exercitii.

In mod clar, reprezentari diferite ale proiectarii si diferite strategii de descompunere au o influenta majora asupra posibilului proiect detaliat. Bineinteles, exista variatii considerabile de la un proiectant la altul; proiectantii care lucreaza independent vor produce de asemenea proiecte detaliate diferite ale aceluiasi sistem. Astfel, este deseori important pentru management sa realizeze analize comparative ale proiectelor (design-urilor).

Privim pasul descompunerii drept unul care trebuie examinat pentru a ne asigura ca proiectul rezultant este modular, eficient si, mai presus de toate, ca indeplineste cerintele sistemului. Probabil ca nici nu mai trebuie mentionat ca proiectul detaliat trebuie verificat in vederea consistentei cu matricea de urmarire a cerintelor, pentru a ne asigura ca cerintele pot fi indeplinite de o implementare bazata pe design.

7 Ce este un Obiect?

In aceasta sectiune, vom oferi cateva reguli de determinare a obiectelor care sunt prezente in sistemul pe care dorim sa il proiectam. Ideea de baza este ca un obiect are atribute si ca in orice instanta a unui obiect, aceste atribute vor avea valori.

Presupunem ca ati ales un candidat pentru un obiect al sistemului, si ca ati determinat un set de atribute si setul posibil de valori al acestora. Ce teste informale puteti aplica pentru a fi siguri ca obiectele Dvs. sunt cele mai potrivite abstractizari pentru sistem?

Primul test este "testul exemplelor multiple". Afirmat mai simplu, daca exista un singur exemplu al instantei unui obiect, atunci conceptul nu este suficient de general pentru a folosi tehnici orientate pe obiecte pentru implementarea lui.

Testul exemplelor multiple este consistent cu un dictum al programarii procedurale: "daca il folositi o data, scrieti codul. Daca il folositi si de doua ori, scrieti o procedura sau o functie." Este de asemenea consistent cu sfatul dat deseori tinerilor matematicieni: "Daca un concept sau teorie nu are cel putin trei exemple reale diferite, nu merita studiat".

O data ce candidatul pentru un obiect trece testul exemplelor multiple, el este plasat intr-un set de obiecte potentiale. Atributele obiectelor sunt acum testate cu ajutorul unei relatii "are-o", care poate sa ajute la formalizarea setului de atribute ale obiectului. Ar trebui sa scriem un set initial de functii membre pentru potentialul obiect, pe baza transformarilor rationale ale valorilor anumitor atribute ale obiectului propus.

Urmatoarea regula informala este verificarea a cat de potrivite sunt obiectele se refera la ierarhia clasei in care sunt proiectate clasele noi pe baza celor vechi. Aceasta relatie dintre clasa de baza si clasa derivata se descrie cel mai bine ca relatie "este-o". Daca afirmatia:

obiect 1 este un obiect 2

nu pare sa aiba sens (ignorand aspectul gramatical), atunci relatia nu este de forma

(clasa de baza, clasa derivata)

si, astfel, nu avem o relatie de mostenire.

Pe de alta parte, daca afirmatia pare sa aiba sens, atunci avem un candidat pentru o astfel de relatie. Numim aceasta "testul relatiei este-o". In acest caz, ar trebui sa desenam o diagrama a obiectului si oricaror relatii dintre obiect si alte obiecte.

Ar trebui sa enumeram functii membre potentiale si sa fim pregatiti sa gasim exemple de polimorfism. Aparitia polimorfismului sugereaza ca am ales corect relatia de mostenire. Daca nu exista polimorfism, atunci ar trebui sa avem indoieli in privinta descrierii corecte a functiilor membre, sau cel putin ca au fost insuficient de detaliat descrise.

Setul de obiecte potentiale si descrierile functiilor lor membre ar trebui rafinate la fiecare pas.

Exista si un test final al relatiilor care trebuie realizat pentru a incorpora obiectele intr-un design preliminar orientat pe obiecte al sistemului software. Preocuparea de data aceasta este daca obiectele enuntate formeaza un set complet de obiecte necesare pentru proiectarea sistemului software. Relatia pe care o cautam este "relatia foloseste-o".

Utilizam aceasta relatie prin intrebandu-ne daca afirmatia

obiect 1 foloseste obiect 2

are sens pentru perechile de obiecte considerate. Fiecare propozitie care are sens sugereaza fie o relatie client-server, fie o relatie bazata pe agent, si trebuie luata in considerare ca parte a proiectului programului. Daca nu putem gasi nici o propozitie de acest gen care sa aiba sens, atunci exista doua posibilitati: fie ca obiectele sunt insuficient specificate pentru a ne permite sa descriem intregul sistem, fie descrierea naturala a sistemului este un program procedural ce controleaza obiectele.

Remarcati ca obiectele pot fi inrudite cu multe alte obiecte. Mostenirea multipla este posibila, si de asemenea si obiecte multiple. Astfel, pasii anteriori ar trebui repetati pentru grupe de trei obiecte, patru obiecte, samd, pana cand proiectantii considera ca au fost descrise toate trasaturile orientate pe obiecte esentiale ale sistemului.

Rezumam pasii recomandati de determinare a obiectelor in Tabelul 2.

Tabelul 2

Metodologie de determinare a obiectelor

Alegeti un candidat pentru obiect.

Determinati un set de atribute si setul posibil de valori al acestora. Folositi relatia are-o. Enumerati toate transformarile obiectului.

Dezvoltati un set initial de transformari ale obiectului, pentru a servi ca functii membre. Lista atributelor si a valorilor lor ofera un set initial de transformari prin determinarea valorii fiecarui obiect, si atribuirii unei valori fiecarui obiect. Constructorul, destructorul si functiile de I/O trebuie de asemenea incluse.

Determinati daca exista mai multe exemple ale obiectului. Daca da, atunci plasati obiectul propus intr-un set de obiecte potentiale. Daca nu, scoateti-l, pentru ca a cazut testul exemplelor multiple.

Aplicati relatia este-o luand in considerare toate propozitiile de forma

obiect 1 este un obiect 2

Obiectele considerate pentru aceasta relatie ar trebui sa includa obiectul in dezvoltare si orice alte obiecte considerate ca fiind inrudite. (Biblioteca de clase poate fi consultata la acest pas al procesului). Fiecare afirmatie valida trebuie sa conduca la o relatie de mostenire. Fiecare relatie de mostenire trebuie ilustrata grafic.

Folositi polimorfismul si supraincarcarea operatorilor (si functiilor) pentru a verifica daca am descris obiectele suficient de detaliat. Verificati descrierea obiectului daca nu gasiti urme de polimorfism sau supraincarcare.

Folositi relatia foloseste-o

obiect 1 foloseste obiect 2

pentru a determina toate instantele relatiilor client-server sau bazat-pe-agent. Folositi aceste relatii pentru a determina aspecte ale proiectului programului.

Revizuiti obiectul, atributele si functiile membre ale acestuia, proprietatile de mostenire, polimorfismul, supraincarcarea, si relatiile sale cu alte obiecte, pentru a determina daca obiectul este complet in sensul ca nici o alta functie, atribute, sau relatii nu sunt necesare.

Repetati pasii 2-8 pentru toate combinatiile de obiecte relevante (triplete, cvadruple, s.a.m.d) pana cand rolul obiectului in orice sistem propus a fost descris adecvat.

Asigurati-va ca ati inteles pasii folositi in acest proces de determinare a obiectelor.

Importanta abstractizarii datelor si a ascunderii informatiei in cadrul obiectelor, trebuie sa va fie foarte clara. In plus, trebuie sa apreciati in oarecare masura puterea conceptelor de supraincarcare a operatorilor si mostenire. Vom considera de acum dezvoltarea de programe orientate pe obiecte mai mari.

In urmatoarele cateva sectiuni ale acestui capitol vom discuta aspecte ale proiectarii orientate pe obiecte si vom indica modul in care paradigma orientat-pe-obiecte pentru sisteme software difera fata de sistemele orientate pe proceduri. Vom indica de asemenea o metodologie a dezvoltarii sistemelor orientate pe obiecte pentru determinarea obiectelor fundamentale (si a metodelor corespunzatoare) ale acestora. Aceasta se va face in contextul dezvoltarii unei clase care descrie siruri de caractere.

Ne intoarcem acum la tema modelarii sistemelor orientate pe obiecte. Prima intrebare fundamentala pe care trebuie sa o punem este: care sunt obiectele sistemului?

O data ce am determinat aceste obiecte, trebuie sa raspundem la a doua intrebare fundamentala: care este setul de transformari care pot fi aplicate acestor obiecte?

Cateva definitii ar putea fi de folos. Despre un obiect abstract se spune ca avem atribute, care descriu o proprietate sau un aspect al obiectului abstract. Pentru orice instanta a unui obiect abstract, fiecare atribut poate avea valori.

Enumerarea atributelor este utila in evaluarea candidatului pentru un obiect. Atributele trebuie sa fie independente, in sensul ca o modificare a valorii unuia nu ar trebui sa afecteze valoarea altui atribut.

Exista inca o judecata care trebuie facuta pe baza listei atributelor: daca exista un singur atribut, atunci este posibil ca obiectul sa fie la un nivel jos de abstractizare. Acest lucru trebuie in general evitat, si astfel, vom dori sa avem cel putin doua atribute pentru fiecare obiect.

Vom ilustra aceste concepte prin cateva exemple in cadrul acestei sectiuni si a unora din cele ce urmeaza.

Consideram dezvoltarea tipica a unei clase pentru a descrie conceptul abstract al unui sir. Cateva atribute tipice a unui sir ar putea include lungimea, continutul, crearea sau distrugerea lui, afisarea acestuia. Toate acestea ne conduc la valori potentiale ale acestor atribute: lungimea poate fi 47, continutul poate fi "Imi place acest curs de inginerie a programarii" (nenumarand ghilimele), se poate afla in starea "creat" si poate fi afisat in fluxul standard de iesire cout. Valori alternative ale atributelor pot fi: lungimea de 81, continutul "Imi place acest curs de ingineria programarii si vreau sa fiu prezent cat mai des", si poate fi afisat intr-un fisier "fis_iesire".

Determinarea atributelor unui obiect si a setului de valori posibile pentru fiecare atribut sugereaza apoi functiile si tipurile de date necesare pentru implementarea metodelor folosite de aceasta clasa. De exemplu, trebuie sa avem o functie membru pentru clasa String care sa calculeze lungimea sirului de caractere. Aceasta lungime trebuie sa fie de tipul int (din moment ce acesta este tipul de date elementar predefinit in C). Trebuie sa avem un constructor care initializeaza continutul sirului si trebuie sa avem o functie pentru afisarea continutului in fluxul de iesire corespunzator.

Remarcati ce nu am determinat inca. Nu am mentionat deloc octetul null 0 folosit ca octet de incheiere pentru a indica finalul sirului; apoi, o alta intrebare ce se ridica este daca octetul de incheiere se ia sau nu in considerare la calcularea lungimii sirului, marind astfel, sau nu, lungimea acestuia.

Intr-adevar, nu exista nici o cerinta ca sirul sa fie implementat ca un set de octeti invecinati. Am putea alege sa urmam calea multor programe de editare text si folosi liste inlantuite pentru a lega matrici invecinate de caractere (si alte obiecte, precum grafice, in cazul procesorului de texte). Listele inlantuite sunt in special potrivite insertiei si stergerii textului in cadrul unui document de procesare de texte. Sunt posibile si alte forme de organizare a datelor.

Partea importanta ar fi sa remarcam ca nici una dintre deciziile privitoare la organizarea sau detaliile implementarii nu sunt relevante pentru obiectul string. Ce avem nevoie acum este o determinare a atributelor obiectului si a unui set de valori posibile pentru fiecare atribut. Cu o asemenea determinare, putem redacta prima tentativa de descriere a clasei. Astfel, prima incercare de definire a unui obiect string va avea probabil o definitie de genul clasei descrise mai jos. Nu ne punem problema sintaxei in acest moment:

class String

functii membre:

int lungime;

int strlen(String s);

void afisare(String s);

Se ridica aici cateva probleme, deoarece nu am determinat precis interfata. Constructorului trebuie sa ii specificam o marime pentru lungimea sirului. De asemenea, sunt si alte functii membre care trebuie sa aiba o interfata determinata. Astfel, va trebui sa facem o a doua iterare a proiectului clasei de reprezentare a sirurilor.

class String

functii membre:

int lungime;

String (char *arr); //terminat cu 0

int strlen();

operator <<;

Exista mai multe iterari care trebuie realizate pentru a avea o definitie completa a interfetelor acestei clase. Bineinteles, trebuie inca sa dezvoltam o implementare a metodelor. Omitem detaliile iterarii descrierii clasei in acest punct, din moment ce urmeaza sa le descriem in amanunt in Sectiunea 10, dupa ce am discutat cateva metodologii de dezvoltare a claselor. Implementarea codului pentru functiile membre ramane ca exercitiu.

8 Reprezentari ale proiectului orientat pe obiecte

In aceasta sectiune vom prezenta un model al unui obiect simplu pentru sistemul software al concentratorului de terminale descris in Sectiunea     Nu vom incerca sa imbunatatim modelul obiectului si il vom mentine la acelasi nivel inalt pe care l-am folosit pentru modelele anterioare, utilizand diferite reprezentari de proiect.

Reprezentarea este simpla (cel putin in acest moment). Vom folosi o casuta dreptunghiulara pentru a descrie un obiect, romburi si segmente de linie pentru a indica relatiile intre obiecte. Numele clasei este data deasupra unei linii orizontale, in interiorul casutei. Vom folosi conventia scrierii numelui clasei cu prima litera majuscula.

Relatia dintre obiecte primeste un nume in aceasta reprezentare. Relatia se numeste "este conectat la" si se comporta intr-o maniera similara relatiei "foloseste", pe care o discutam mai tarziu in acest capitol.

In casuta sunt incluse cateva atribute ale unui obiect arbitrar al clasei. Am fi inclus toate atributele, dar ele erau prea multe.

In partea de jos a diagramei, enumeram din nou clasele care sunt in partea de sus a diagramei, din nou folosind o reprezentare grafica. Clasele in aceasta lista au valori specifice pentru fiecare atribut al vreunui obiect al acestora.

Remarcati ca acest model nu mentioneaza structura de date coada care va fi probabil folosita pentru a pastra informatia care circula intre concentrator si terminal.

Putem avea doua viziuni diferite ale sistemului orientat pe obiecte: modelul obiect sau modelul interfata. Vom discuta pe rand aceste doua viziuni.

In reprezentarea modelului obiect, vom folosi o notatie extinsa entitate-relatie (E-R). Vom folosi conventia ca numele unei clase va fi dat cu litere mari si instantele ei, cu litere mici.

Punctul de start al discutiei noastre il constituie diagramele date in sectiunea     Astfel de diagrame pot oferi o viziune buna de nivel inalt al sistemului.

Diagramele obiect pot fi in continuare imbunatatite prin incorporarea in diagrama a cardinalitatii fiecarei relatii. Figura 10 ilustreaza acest lucru. Numerele de langa sau de deasupra unei relatii indica numerele de elemente de pe fiecare parte ce au acea relatie. Cardinalitatea poate fi una dintre urmatoarele: o valoare precisa, un rang de valori, simbolul '*' denotand 0 sau mai mare, ori simbolul '+' denotand 1 sau mai mare. In figura 10 am folosit '+' si rangul.

Un model obiect ar trebui extins pana cand acesta descrie abstractizarile esentiale ale obiectelor din sistem. Din pacate, dupa cum am indicat pana acum modelul obiect in aceasta sectiune, este inadecvat pentru a descrie complet relatia dintre diferite obiecte. Avand in vedere aceasta limitare, vom incerca sa incorporam in modelul nostru interfete intre diferite obiecte.

O metoda este de a folosi tabelele de stare. Termenii "diagrama de stare", "masina de stare" si "masina de stari finite" sunt deseori folosite ca sinonime ale "tabelei de stare". Aceasta este una dintre cele mai vechi metode de descriere a sistemelor. Poate fi cu siguranta datata inaintea eforturilor curente ale design-ului orientat pe obiecte.

O tabela de stare pentru concentratorul de terminale ar putea avea sase stari, pe care le numim ITP, ICP, ICPUP, ECPUP, ECP si ETP. Acronimele provin de la: Intrare Terminal Pregatita, Intrare Concentrator Pregatita, Intrare CPU Pregatita, Iesire CPU Pregatita, Iesire Concentrator Pregatita, si respectiv Iesire Terminal Pregatita.

Figura 10. Adaugarea informatiei de cardinalitate la o notatie cu model obiect. Sursa: Leach, Proiectare si Programare C++ Orientate pe Obiecte, Academic Press, 1995

Ilustram starile sistemului concentrator de terminale in Figura 11. Notatia este usor diferita de cea uzuala in care nu am specificat starea initiala in care sosesc intrarile sistemului (de la tastatura) si starea finala in care iesirile ies definitiv din sistem (ele fiind afisate pe terminalul ecran).

Este bine de stiut cum sa folosim reprezentarile existente ale sistemelor atunci cand incercam sa le descriem in termeni orientati pe obiecte. Avem deseori un model obiect al unui sistem. Sugestiile noastre pentru utilizarea modelelor informationale existente si a diagramelor in modelarea cu obiecte pot fi sumarizate precum urmeaza:

Daca exista o diagrama a unui model informational, folositi-o pentru a determina relatiile initiale, in special cele de agregare.

Examinati listele de atribute cautand indicatii ale structurilor de date si a unui set preliminar de transformari pentru a opera asupra valorilor acestor atribute.

Daca nu exista nici un model informational disponibil, treceti direct la o descriere a obiectelor din sistem.

Figura 11. O diagrama de stare pentru sistemul concentratorului de terminale. Sursa: Leach, Proiectare si Programare C++ Orientate pe Obiecte, Academic Press, 1995

9 Principii ale proiectarii software pentru programe orientate pe obiecte

Toate metodele de reprezentare a design-ului discutate anterior au fost create pentru a imbunatati calitatea proiectelor software si eficienta proceselor utilizate pentru a le crea. Tehnicile de reprezentare a design-ului pentru sisteme traditionale, organizate procedural, sunt mult mai uzuale decat cele pentru sisteme orientate pe obiecte. Acest lucru nu este surprinzator, data fiind relativa noutate a tehnicilor orientate pe obiecte.

Asa cum am vazut in sectiunea anterioara, descompunerea a fost tehnica majora folosita pentru dezvoltarea de software procedural o data ce am determinat schemele software de nivel inalt, daca ele exista, care au descris sistemul ce trebuie proiectat. Exemplul construit anterior folosind unealta CASE MacTAGS a accentuat abordarea bazata pe descompunere.

Instalarea completa a sistemului TAGS pe statii de lucru puternice includ de asemenea o facilitate de generare automata de cod. Disponibilitatea extensiilor uneltelor CASE care ofera generatoare automate de cod nu este restrictionata la acele unelte CASE care suporta proiecte orientate pe proceduri. Remarcam ca anumite trasaturi inrudite pot fi gasite in diverse pachete software folosite in dezvoltarea orientata pe obiecte. De exemplu, versiunea 5.0 si mai mare a Sistemului de Dezvoltare Borland C++ includ facilitatea generarii de cadre (framework) de cod cu fisiere antet si descrieri de clase din modelele grafice ale obiectelor care alcatuiesc un sistem. Sistemul ROSE al Rational Corporation este un alt exemplu de sistem popular care suporta analiza orientata pe obiecte cu cadre de cod.

Totusi, proiectarea orientata pe obiecte se concentreaza pe dezvoltarea de clase complete pentru a descrie obiecte. Ideea este ca toate metodele sau functiile membre necesare vor fi livrate in descrierea clasei. Astfel, preocuparea principala este proiectarii clasei spre a fi completa, astfel ca posibilele interactiuni sa fie tratate prin interfete corespunzatoare. Obiectele interactioneaza apoi prin trimitere de mesaje de la o clasa la alta si clasele individuale reactioneaza doar la mesajele pe care le primesc. Obiectele sunt vazute ca autonome, fara alte interactiuni decat cele specificate in interfata obiectului.

Utilizarea claselor abstracte poate fi in special folositoare daca cerintele software-ului nu sunt complet identificate inainte de a incepe proiectarea, asa cum este cu siguranta cazul procesului de dezvoltare software condus de piata si programat concurent, atat de uzual in lumea computerelor personale.

In aceasta abordare, interfetele unui obiect al sistemului sunt specificate devreme. Detaliile de implementare ale metodelor pot fi dezvoltate ulterior. Daca sunt necesare functionalitati noi, acestea se ofera in metode asociate cu un obiect, nu in interfata obiectului. O functie virtuala pura (una care nu are detalii de implementare si este folosita drept clasa de baza cu interfete ce pot fi folosite de clasele care o mostenesc) este deseori folosita in acest scop in C++.

Chiar si in cazul cel mai defavorabil, dezvoltarea functiilor membre ale unei functii poate sa se desfasoare concurent cu proiectarea obiectului. Daca se adauga o interactiune noua la interfata unui obiect, majoritatea metodelor existente nu trebuie modificate. Trebuie adaugate doar metode noi pentru a implementa interfata aditionala.

In continuare dam o ilustrare a efectelor diferitelor abordari de proiectare a sistemelor orientate pe obiecte. Consideram situatia simpla de descriere a clasei ce reprezinta patrulatere (obiecte geometrice cu patru laturi). Dorim sa dezvoltam o structura de clasa pentru descrierea de patrulatere, cu dreptunghiuri si patrate drept tipuri speciale de forme geometrice.

Avem mai multe optiuni la dispozitie. Putem crea o ierarhie cu o clasa primitiva numita varf. Putem construi o clasa numita latura, ce foloseste clasa varf, si folosi apoi clasa latura pentru a construi o noua clasa numita figura. Clasa figura poate fi folosita pentru a construi patrulatere ca un subset.

Aceasta constructie este ilustrata in Figura 12. Prezentam secvente de cod sursa pentru implementarea acestei organizari in Exemplul 3.

Figura 12. O ilustrare a organizarii proiectarii unor figuri geometrice pe baza primitivei varf

Din pacate, nu exista o modalitate clara de capturare a notiunii unei figuri geometrice ca fiind patrat sau dreptunghi. Am putea modifica clasa data in fisierul figura.cpp, dar aceasta pare un procedeu ciudat. Un alt design potential foloseste o ierarhie de obiecte bazate pe o relatie este-o, din moment ce un patrat este un dreptunghi si un dreptunghi este un patrulater. Invitam cursantul sa examineze orice clasa de biblioteca standard care are obiecte grafice pentru a vedea ca nici una din aceste abordari nu este folosita in practica. In loc de aceasta, ierarhia este deseori inversata, iar un dreptunghi mosteneste de la un patrat. Remarcam ca flexibilitatea paradigmei orientate pe obiecte ne permite sa alegem dintre aceste alternative de proiectare.

// Fisier: varf.cpp

class Varf

// Fisier: latura.cpp

#include 'varf.cpp'

class Latura : public Varf

// Fisier: figura.cpp

#include 'latura.cpp'

class Figura : public Latura

Exemplul 3. Secvente de cod sursa C++ pentru organizarea figurilor pe baza primitivei varf

Exista un dezavantaj al inlesnirii acestei flexibilitati a cerintelor concurente, proiectarii si codificarii. Orice metoda adaugata la o clasa in ultimul moment inainte de lansare va avea parte de testari minimale datorita crizei de timp. Este foarte putin probabil ca un obiect sa fie testat pentru toate tipurile posibile de raspuns, in special daca interfetele sunt polimorfice sau daca unii operatori sunt supraincarcati. Astfel, un utilizator al software-ului poate observa multe greseli de functionare, mai ales daca utilizatorul opereaza software-ul in moduri neprevazute de proiectanti.

In multe organizatii de dezvoltare software, tratarea unor asemenea probleme potentiale este amanata pentru urmatoarea lansare. Astfel, testarea corectiva a componentelor software a unei versiuni lansate anterior poate sa apara in timpul dezvoltarii (cerinte, proiectare, codificare, testare) a urmatoarei lansari. Determinarea momentul de lansare a sofware-ului, de comandare a testarilor aditionale, si determinarea trasaturilor ce vor fi incorporate in lansari noi sunt in mod clar esentiale pentru a avea succes in mediul software condus de piata. Ne vom intoarce la acest aspect in Capitolul 6 cand vom studia testarea, si din nou in Capitolul 8 cand vom studia managementul configurarii.

Modelele prezentate in acest capitol sunt intentionate exclusiv ilustrarii. Orice model realist al unui sistem complet ar fi mult mai detaliat decat ceea ce vom prezenta in urmatoarele sectiuni. Modelele date aici descriu sistemul doar la nivelul cel mai inalt al sau. Dupa ce ati parcurs acest capitol, ar trebui sa puteti aprecia puterea expresiva a catorva reprezentari diferite ale proiectului pentru sisteme software procedurale si orientate pe obiecte.

10 Aspecte ale proiectarii claselor

Este necesar sa discutam despre anumite dificultati asociate cu dezvoltarea de programe care folosesc metodele de definire a claselor descrise in sectiunea anterioara. Metodologia descrisa in sectiunea anterioara presupune ca sistemul software a fost dezvoltat intr-un vacuum. Adica, am descris cateva atribute pe care le consideram asociate cu un anumit tip de obiect si am descris cateva interfete potential folositoare intre aceste obiecte si altele (precum matrici de caractere si siruri I/O). Nu am acordat atentie claselor dezvoltate anterior, ce ar putea fi inrudite cu clasa noastra si ar incuraja utilizarea unor interfete similare.

Daca exista un set de clase inrudite cu standarde similare pentru interfetele lor, atunci trebuie macar sa luam in considerare aceste interfete inainte de a fixa interfetele ce fac parte din descrierea concurenta a obiectelor.

Acest aspect nu poate fi suficient de accentuat. Dezvoltarea unui obiect trebuie sa aiba loc de-a lungul liniilor ce ii definesc atributele si valorile tipice ale acestor atribute. Aceasta poate fi realizata prin metoda uzuala de rafinare pas cu pas, atat de familiara inginerilor software. Dezvoltarea unui obiect util (unul care poate fi folosit intr-o varietate de situatii importante) necesita ca interfetele catre obiectele existente sa fie luate in considerare in stadiul de dezvoltare. Altfel, obiectele pe care le dezvoltam vor avea o utilitate puternic limitata.

Ilustram acest lucru prin urmatoarea analogie: sa consideram stadiul curent al dezvoltarii hardware-ului unui computer. Daca un proiectant hardware proiecteaza un supercomputer de inalta performanta, special dedicat unei sarcini sau un microprocesor special pentru controlul sistemelor incorporate, el va folosi componentele dezvoltate anterior si care au interfete bine-definite si bine-documentate. Aceste componente hardware bine-proiectate au nivele predictibile de performanta in ceea ce priveste viteza de tact, rata de transfer a datelor, reactia la anumite intreruperi, utilizarea puterii etc. O piesa hardware noua care nu adera bine la aceste interfete standard este putin probabil sa fie folositoare in afara unei arii limitate de aplicatii. Doar un design revolutionar cu aplicabilitate sau performante iesite din comun prezinta posibilitatea de a fi folositoare; o interfata neobisnuita cu aplicatii comune sau performante medii nu poate avea mare succes.

Exact aceeasi situatie se aplica la dezvoltarea claselor care pot fi folosite drept componente software reutilizabile. Dezvoltarea unei clase nu poate fi facuta intr-un vacuum. Trebuie sa tina cont de alte clase ale bibliotecii de clase, pentru a face uz in mod eficient de aceste clase dezvoltate anterior. Catalogul de biblioteca si orice unelte software de examinare a diferitelor biblioteci sunt extrem de importante la dezvoltarea claselor ce interactioneaza cu sisteme reale.

Remarcati ca trebuie sa mai facem inca un lucru pentru a ne asigura ca clasele pe care le dezvoltam fac uz eficient de resurse, in special de timpul programatorului. Daca exista o relatie intre clasa noastra si una sau mai multe clase deja existente, este posibil sa putem folosi functiile dezvoltate anterior, ce au fost membre ale vreunei clase deja existente. Acest lucru se realizeaza usor daca putem folosi mostenirea.

Putem de asemenea folosi functii asociate cu un obiect, daca functiile au fost declarate original ca functii friend. (amintiti-va ca functiile friend sunt permise in C++, dar nu in limbaje orientate pe obiecte precum Java.) Chiar daca functiile nu au fost declarate original ca fiind friend, s-ar putea sa avem posibilitatea sa modificam definitia clasei deja existente pentru a face functiile necesare functii membre si recompila sistemul.

In orice caz, un proces de proiectare software eficient necesita o verificare a resurselor software disponibile.

Grady Booch este unul dintre cei mai recunoscuti experti ai comunitatii de programare orientata pe obiecte. El a remarcat ca in majoritatea programelor orientate pe obiecte, de calitate inalta, multe obiecte esentiale sunt grupate in cateva clase inrudite, mai degraba decat grupate doar prin mostenire. El afirma ca singurele programe care au toate obiectele inrudite sunt cele relativ triviale.

In mod clar, determinarea claselor disponibile in bibliotecile de clase este doar un punct de start in dezvoltarea de programe orientate pe obiecte. Totusi, acest lucru reprezinta un pas esential in proiectarea unui sistem orientat pe obiecte.

11 Un exemplu de dezvoltare de clasa - Clasa String

In aceasta sectiune ne vom intoarce la discutia privind clasa String pe care am inceput-o in Sectiunea 7. Vom aplica asupra acestei clase regulile enumerate in Tabelul 2 pentru a obtine ceea ce speram sa fie o abstractizare satisfacatoare a propietatilor pe care le dorim intr-o clasa String abstracta. Clasa String prezentata in acest capitol a fost originar dezvoltata de Eric Charles pentru un proiect condus de Bernard Woolfolk la Universitatea Howard.

Initial, am remarcat ca aceasta clasa avea doua functii membre: un constructor String() si o functie strlen() pentru a calcula lungimea unui obiect al clasei. Suntem la primul pas al procesului descris in Tabelul 2: am selectat un candidat pentru un obiect.

Pasul doi al procesului necesita enumerarea atributelor acestui obiect. Lista de atribute indicata anterior a fost:

lungime

Nu exista o mentiune explicita in cadrul discutiei anterioare, privitor la datele pe care dorim sa le stocam in String. Ne-am asteptat cu siguranta sa folosim datele in functia strlen(). Reparam aceasta omitere incluzand datele acum. Urmatoarea lista a atributelor pentru un obiect String este:

lungime

date din String

Aceste atribute au sens ca atribute potentiale ale obiectelor String, datorita faptului ca ambele afirmatii:

Un String are o lungime.

si

Un String contine date.

au sens. A doua propozitie ar putea fi probabil parafrazata ca:

Un String are continut.

si, astfel, vom folosi termenul continut in locul termenului date din lista initiala de atribute.

Pentru a ne asigura ca acestea sunt atribute rezonabile, vom enumera cateva valori specifice intr-un tabel:

In pasul trei, consideram transformari posibile ale obiectului. Functii membre relevante pot fi:

Constructor

Destructor

Initializarea unui sir

Atribuirea de continut unui alt sir (constructor de copiere)

Date de intrare ale unui sir

Date de iesire ale unui sir

Este esential sa incepem sa luam in considerare modul in care interfetele acestor functii membre trebuie sa arate. Constructorul implicit C++ si functiile destructor nu primesc argumente si nu returneaza valori. Daca dorim sa initializam un obiect String, o vom specifica aici. Este posibil sa dorim sa avem un constructor de forma

String(char * init);

sau poate

String(const char * init);

Aici, init reprezinta o matrice de caractere terminata cu null.

Functiile membre de I/E vor supraincarca cu siguranta operatorii << si >>. Probabil ca ar fi de folos sa permitem scrierea sirurilor in alte fluxuri decat cin, cout si cerr, pentru ca functiile noastre de I/E sa fie din nou supraincarcate.

Remarcati ca nu ne-am legat de aspecte precum includerea (numararea) sau nu a octetului null in lungimea obiectului. Acestea sunt detalii relevante fie pentru interfete catre alte obiecte sau specificari ale implementarii.

Sunt multe exemple de siruri, deci obiectul String propus de noi trece cu siguranta testul "exemplelor multiple".

Vom aplica acum pasul cinci al procesului pentru a determina daca exista relatii de mostenire. Pentru a face acest lucru, trebuie sa determinam un set de obiecte pe care le consideram ca avand relatii de mostenire cu noul obiect propus de noi. Cu posibilele exceptii ale listelor si matricilor, nu exista obiecte probabile in acest moment, deci vom trece la pasul sase al procesului. Daca am considerat ca exista o relatie puternica este-o intre clasa String si o clasa matrice (abstracta), atunci am avea relatii de mostenire intre aceste clase. O afirmatie similara avem pentru clasa String in relatie cu o clasa (abstracta) pentru liste inlantuite.

In exemplul 4, ilustram starea clasei noastre String dupa ce am folosit pasii 1-5 ai procesului, asa cum au fost enuntati in Tabelul 2. Fisierul antet String.h include definitiile de baza necesare pentru clasa String descrisa pana acum.

// tentativa initiala de definire a clasei

// String, folosind pasii 1-5 ai

// procesului de dezvoltare de obiect.

class String

Exemplul     O clasa String definita de utilizator - prima iterare a pasilor 1-5 din procesul de dezvoltare a clasei

Asa cum vom vedea, codul din Exemplul 4 nu este foarte complet, ca descriere a clasei String. Vom continua acum procesul de dezvoltare a clasei.

In pasul sase al procesului, ne intrebam daca exista polimorfism sau supraincarcare. Daca nu, probabil ca nu am descris toate transformarile (functii membre) ale obiectului. In acest caz, avem supraincarcarea (cel putin) a unui constructor si a functiilor I/E, astfel ca este probabil ca am facut cel putin o anumita utilizare a trasaturilor orientate pe obiecte ale clasei.

In pasul sapte, ne intrebam daca exista o instanta a relatiei foloseste-o intre obiectul nostru si alte obiecte. Aici, cautam relatii client-server sau bazat pe agent. Datorita simplicitatii obiectului nostru String, o astfel de relatie este improbabila, deci trecem la pasul opt.

Pasul opt al procesului implica revizuirea starii curente a dezvoltarii clasei si verificarea lipsei vreunor relatii sau transformari. Acesta este un moment ideal pentru o parcurgere structurata a obiectului, preferabil fiind insa ca parcurgerea si revizuirea sa fie realizate de altcineva, si nu de catre proiectant. Scopul revizuirii este de a verifica inconsistentele proiectului, cautand relatii lipsa sau prost aplicate, dar si complicatii inutile.

In exemplul nostru, am oferit foarte putine functii dintre cele disponibile in colectia standard de functii C pentru manipularea sirurilor. Cateva functii tipice accesate in fisierul antet string.h al limbajul standard C sunt strcmp(), strcat() si strcpy(). Ar fi potrivit sa adaugam acum cat mai multe dintre acestea in clasa noastra String.

Pasul noua ne permite sa extindem relatia este-o catre mai multe clase o data, adaugand astfel posibilitatea mostenirii multiple descrierii clasei noastre. Vor apare acum instante mai complexe ale relatiei foloseste-o.

In majoritatea proiectelor (design-urilor) incepatoare este probabil indicat sa repetam pasii 2-8 doar pana la triplete de clase, atata timp cat nu ne asteptam sa apara o relatie mai complexa.

Dupa ce am finalizat acest proces, vom fi obtinut o descriere a datelor interne si interfetelor obiectului String. Singurele lucruri pe care trebuie sa le facem pentru a crea cu adevarat o asemenea clasa sunt de a prezenta definitia datelor si functiilor membre intr-o forma corecta sintactic, si sa codificam detaliile functiilor membre.

Prezentam o descriere mai completa a clasei String in exemplul 5. Remarcati ca avem cu mult mai multe functii membre decat anterior. Unele dintre functiile membre noi sunt incluse pentru ca dorim sa avem interfete catre alte obiecte de tipul String, nu doar date de tipul char*.

Am inclus posibilitatea de modificare a valorilor argumentelor prin utilizarea operatorului & in diverse locuri in cadrul declaratiilor functiilor membre. Declaratiile sunt de tipul const, precum in signatura argumentului

const String& string;

pentru ca dorim sa evitam fenomenul de depasire la copierea intregului continut al obiectului String, dar si sa pastram nemodificata valoarea argumentului. Reamintiti-va ca aceasta se numeste transmiterea de parametri prin referinta constanta.

Ar trebui de asemenea sa remarcati domeniul larg de operatori din exemplul 5, pentru actiuni precum comparatii lexicale. Multi dintre acesti operatori sunt supraincarcati.

Am inclus de asemenea in exemplul 5 un operator friend pentru interactiunea cu clasa ostream:

friend ostream& operator << (ostream& s, String &str);

// contine definitia clasei String, folosind cei noua

// pasi ai procesului de dezvoltare a obiectului

class String

Exemplul 5. O clasa versiune mai completa a clasei String

Exista multe moduri de a descrie un obiect abstract reprezentat de clasa String. Ar trebui sa comparati descrierile celor doua clase date pana acum in aceasta sectiune cu clasa String echivalenta oferita de compilatorul Dvs. C++. Ar trebui de asemenea sa consultati biblioteca standard C++ atunci cand va deveni disponibila, sau cartea lui Plauger despre standardul ANSI pentru o biblioteca C++.

Sunt necesari pasi aditionali daca scopul este cel de a dezvolta clase care incurajeaza folosirea reutilizarii componentelor software. Sugestiile lui Johnson si Foote sunt metode tipice de dezvoltare a claselor reutilizabile de obiecte. Scopul este de a crea clase care nu reprezinta doar abstractizari ale datelor, ci care sunt si usor de testat. Sugestiile lor sunt prezentate in Tabelul 3.

Tabelul 3

Cateva metode de incurajare a claselor reutilizabile

Aceste reguli sunt folositoare atunci cand proiectam sisteme mari cu clase complexe. Ele sunt probabil mult prea stufoase pentru exemplele simple prezentate in acest capitol.

Vom prezenta acum descrierea finala a clasei noastre String. Ea este ilustrata in Exemplul 6. Trasaturile noi includ un set de functii non-membre (libere) pentru realizarea altor actiuni. Asa ca si anterior, ar trebui sa comparati aceasta clasa cu clasa String disponibila sistemului Dvs.

Descrierea clasei este completa si ilustreaza efectele diferitelor iterari ale procesului de dezvoltare a obiectului. Metodele (functiile membre) sunt mici, fiecare realizand actiuni specifice asupra tipurilor selectate de operatori.

Exista multe instante de operatori supraincarcati precum <= si >=, pentru a avea programe simple de comparare si concatenare a sirurilor. Ar trebui sa remarcati utilizarea cuvenita a pointerilor constanti din cadrul functiilor membre ce implementeaza aceste operatii de concatenare cu siruri noi si siruri existente.

Observati de asemenea prezenta unor functii libere pentru realizarea comparatiilor si concatenarilor. Aceste functii libere sunt folosite atunci cand primul argument este o matrice de caractere terminate cu caracterul null, mai degraba decat un obiect al clasei String. Aceasta este o indicatie a faptului ca avem acum o clasa String completa.

// contine definitia clasei String, si functii operator

// supraincarcate non-membre

class String

//friend pentru operatorul supraincarcat de I/E

//al clasei ostream

friend ostream& operator << (ostream& s, String &str);

private:

char * d_string_p; //pointer la caracter

//operatori non-membri (liberi)

String operator + (const char* str, const String& string);

int operator == (const char* str, const String& string);

int operator != (const char* str, const String& string);

int operator > (const char* str, const String& string);

int operator >= (const char* str, const String& string);

int operator < (const char* str, const String& string);

int operator <= (const char* str, const String& string);

Exemplul 6. Tentativa finala de realizare a clasei String definite de utilizator

Bineinteles, am avea nevoie de implementari pentru fiecare dintre functiile membre ale acestei clase. Din motive de spatiu nu am inclus codul sursa in acest curs. Marea parte a detaliilor de implementare a metodelor este clara. Ar trebui sa comparati proiectul clasei noastre cu cel al clasei echivalente din biblioteca standard de clase ANSI. Ar trebui sa remarcati utilizarea puternica a transmiterii argumentelor prin referinta, folosind simbolul & dupa numele argumentului.

Exista multe functii membre pentru ca exista multe oportunitati de supraincarcare a operatorilor. Aceasta conduce la un numar mare de cazuri potentiale de test. Vom discuta testarea programelor orientate pe obiecte in Capitolul 6.

12 Interfata cu utilizatorul

Succesul de piata al multor produse software depind mult mai mult de interfata cu utilizatorul a software-ului sau setul de trasaturi vizibile decat de cele trasaturi ascunse precum robustetea. Aceasta este in special adevarata in pietele "aglomerate" precum cea a aplicatiilor software pentru computere personale, in care sunt multe produse concurentiale.

In aceasta sectiune, vom prezenta sumar acest punct de vedere. Intentia este de a va convinge ca exista mai multe aspecte ale interfetei cu utilizatorul decat folosirea mai multor culori, de mesaje clipitoare, icoane inteligente, sunete sau animatii.

Exista atat o arta, cat si o stiinta a proiectarii interfetei cu utilizatorul. Majoritatea sistemelor software curente au interfete cu utilizatorul bazate pe paradigma WIMP sau Fereastra, Interactiune, Mouse, Pointer (Window, Interaction, Mouse, Pointer). Sistemul de operare Macintosh si variantele Microsoft Windows (Windows 97, Windows 95, Windows, Windows NT si Windows for Workgroups) urmaresc aceasta paradigma.

Interfata grafica cu utilizatorul a pachetelor software de calitate inalta si paginilor web au o consistenta care este reflectata in simplitatea proiectarii meniului. De exemplu, majoritatea interfetelor grafice cu utilizatorul ale software-urilor pentru computere personale au meniuri pull-down cu operatiile pe fisiere in partea de sus, stanga a ecranului.

Vom face acum distinctia intre un meniu pull-down si un meniu pop-up. Un meniu "pull-down" este unul in care utilizatorul selecteaza o optiune dintr-un set de optiuni prin deplasarea unui dispozitiv de indicare precum mouse-ul la o pozitie fixa si selectarea acelei pozitii prin apasarea unui buton de mouse sau a altor dispozitive de selectare. Aceasta secventa de operatii determina aparitia unui meniu din partea de dedesubt a locului in care a fost plasat dispozitivul indicator (mouse-ul). Utilizatorul muta apoi indicatorul in josul listei de optiuni ale meniului pana la selectarea uneia dintre acestea. (Utilizatorul are optiunea de terminare a procesului prin eliberarea butonului mouse-ului sau deplasarea mouse-ului pe o alta pozitie). Setul initial de optiuni listate intr-un meniu pull-down sunt intotdeauna disponibile utilizatorului.

In contrast cu informatia dintr-un meniu pull-down, nici o informatie din cadrul unui meniu "pop-up" nu ii este vizibila utilizatorului atata timp cat el nu intreprinde o actiune specifica, precum apasarea unui buton de mouse sau a combinatiei de taste echivalente.

Actiunea unui meniu pull-down tipic inainte si dupa apasarea butonului de mouse este ilustrata in Figurile 13 si 1 Comparati aceste meniuri cu Figurile 15 si 16, care ilustreaza actiunea meniurilor pop-up.

Remarcati ca meniurile pull-down apar in partea de sus a ecranului ilustrat in Figura 13, atata timp cat ruleaza aceasta aplicatie (Microsoft Word) si fereastra este afisata pe ecran. Comparati aceasta cu Figura 14 in care acelasi meniu pull-down este ilustrat impreuna cu un meniu nou obtinut din selectia unei optiuni din acest meniu.

Figura 13. Exemplu de meniu pull-down inainte de a face selectia

Figura 1 Exemplu de meniu pull-down dupa ce selectia a fost realizata

Figura 15. Exemplu de meniu pop-up inainte de a face selectia

Figura 16. Exemplu de meniu pop-up dupa ce selectia a fost realizata

O gama mare de optiuni determinate de disponibilitatea meniurilor pull-down si pop-up produce probleme mari pentru un proiectant de interfete. El trebuie sa fie atent sa nu foloseasca aceste trasaturi tentante doar pentru ca ele sunt disponibile. Urmatoarele reguli de baza va pot fi folositoare:

Folositi un meniu pull-down atunci cand optiunile trebuie sa fie intotdeauna vizibile

Folositi un meniu pull-down pentru a furniza un set de optiuni pentru un utilizator incepator

Folositi un meniu pop-up atunci cand optiunile nu trebuie sa fie intotdeauna vizibile

Folositi un meniu pop-up pentru a-i oferi shortcut-uri unui utilizator avansat

Regulile de baza au trebuit sa fie incomplete datorita lipsei de spatiu si datorita gamei largi de aplicatii si utilizatori potentiali. Nu in ultimul rand, ele ilustreaza cateva probleme majore pentru un proiectant de interfete: necesitand o abordare consistenta pentru proiectul interfetei, in timp ce ofera simultan prescurtari pentru a-l ajuta pe utilizatorul experimentat sa fie mai productiv.

Remarcam ca in multe situatii, o interfata grafica cu utilizatorul nu este potrivita. Sa luam in considerare cazul unui coleg de la Universitatea Howard, care colaboreaza cu colegi din cercetarea stabilitatii software din toata lumea. El a dezvoltat impreuna cu asistentul sau un set de unelte pentru analiza fisierelor de date pentru a evalua rata de crestere a stabilitatii sistemelor software. Fisierele de date contin momentele in care defectele software au aparut in timpul procesului de testare.

Datorita faptului ca multe sisteme luate in considerare de el nu sunt conectate la Internet din motive de securitate, el trebuie deseori sa isi realizeze munca de cercetare fara acces la statii de lucru si servere disponibile in mediul lui de acasa, din Universitatea Howard. Astfel, a dezvoltat o versiune mai mica pentru setul sau de unelte software pentru un computer personal. Setul de unelte software trebuie sa functioneze in toate mediile, si astfel, interfata grafica cu utilizatorul corespunzatoare mediului Windows 95, sau orice alta versiune Microsoft Windows nu a putut fi folosita.

In schimb, software-ul functioneaza perfect intr-un mediu MS-DOS. Interfata cea mai simpla este cea mai buna in acest caz.

Un alt exemplu pentru o interfata utilizator non-grafica si condusa de meniuri pentru un sistem folosit pentru selectarea unei serii de fisiere ce trebuie analizate de un sistem software. A fost dezvoltat un sistem cu terminale bazate pe caractere si s-a investit efort considerabil in dezvoltarea de fisiere text care au fost tiparite pentru a simula terminale grafice de ecran. Mai multe meniuri, comprimate pentru a face economie de spatiu, sunt ilustrate in Figura 17 pana la 22.

1989 B&S Enterprises, Inc.