ELEMENTE DE PROIECTARE A SISTEMELOR INFORMATICE

1. Etape in proiectarea sistemelor software

Realizarea sistemelor software are loc in mai multe etape [Sommerville2000], modelul in "V" (Figura 1) reusind sa surprinda aceste etape:

definirea cerintelor;

proiectarea sistemului;

dezvoltarea subsistemelor;

integrarea sistemului;

instalarea sistemului;

evaluarea sistemului;

scoaterea din uz a sistemului.

Definirea cerintelor pentru realizarea unui sistem

Cerintele unui sistem pot fi de mai multe tipuri: cerinte functionale abstracte, care definesc intr-un mod abstract functiile sistemului, cerinte nefunctionale, care se refera la proprietatile sistemului, si acele cerinte care reflecta modul in care sistemul nu trebuie sa se comporte sub nici o forma.

Definirea cerintelor trebuie sa fie in concordanta cu obiectivele aplicatiei, obiective care pe de o parte sunt cele functionale, iar pe de alta parte sunt cele organizationale. Etapa de definire a cerintelor este una dificila deoarece acestea se pot modifica pe parcurs, motiv pentru care trebuie anticipate orice posibile modificari.

Figura 1. Procesul de inginerie a sistemelor - modelul in "V"

(Sursa: Sommerville 2000)

Proiectarea sistemului

Etapa de proiectare a sistemului se desfasoara in mai multe faze (Figura 2.):

partitionarea cerintelor - gruparea acestora in functie de asemanarile dintre ele;

identificarea subsistemelor

asignarea cerintelor catre subsisteme

specificarea functionalitatii subsistemelor;

definirea interfetei subsistemelor.

Figura 2. Fazele proiectarii unui sistem

(Sursa: Sommerville 2000)

Trebuie tinut cont de dificultatile ce pot surveni in procesul de proiectare a sistemului. Aceste dificultati tin de aparitia posibilelor conflicte intre membri echipei cu privire la partitionarea cerintelor, sau de performanta precara a unor componente hardware.

Dezvoltarea subsistemelor

Partitionarea sistemului in subsisteme ofera avantajul de a dezvolta in paralel subsistemele, sau o parte din subsisteme pot fi acoperite prin utilizarea componentelor cumparate, asa-numitele COTS (Commercial Off-The-Shelf). Dezvoltarea in paralel a subsistemelor, de catre echipe separate poate avea unele dezavantaje datorate unor posibile lipse de comunicare dintre echipe.

Integrarea sistemului

Presupune asamblarea subsistemelor unul cate unul, in mod incremental, la care se adauga si integrarea componentelor hardware si a persoanelor care vor utiliza sistemul.

Instalarea sistemului

Aceasta etapa presupune inceperea utilizarii sistemului, si poate intampina probleme legate de instalarea fizica, alte sisteme cu care sistemul nou va trebui sa interactioneze si nu in ultimul rand rezistenta umana care se intalneste de regula in cazul introducerii unui sistem nou.

Evaluarea sistemului

Sistemul va fi considerat functional pe masura ce problemele legate de cerintele neprevazute, de utilizarea neanticipata a sistemului sau problemele legate de interactiunea sistemului cu alte sisteme sunt eliminate. Pentru ca sistemul sa fie functional o perioada mai indelungata, acesta trebuie sa evolueze pentru a indeplini noi cerinte, proces care desigur implica alte costuri.

Scoaterea din uz a sistemului

Daca sistemul nu mai face fata cerintelor actuale, utilizarea acestuia va trebui sa inceteze. O parte din software insa poate fi refolosita la construirea altor sisteme, desi este posibil ca pentru restructurarea sau convertirea acestuia efortul implicat si costurile sa fie prea mari.

In multe proiecte, proiectarea este inca un proces ad-hoc, adica, plecand de la un set de cerinte, de multe ori exprimate in limbaj natural, se realizeaza o proiectare informala, si apoi se trece la implementare si se fac modificari pe masura ce codificarea avanseaza. Cand codificarea ajunge la final proiectul este schimbat atat de mult incat documentul final devine de neutilizat.

In firmele care se ocupa de proiecte mari de software sunt necesare abordari mai metodice ale proiectarii. Aceste metode folosesc de regula modele grafice si conduc la documente de proiectare voluminoase. Exista componente CASE care incorporeaza metode de proiectare. Printre metode incorporate in instrumente CASE sunt:

modelul fluxului de date (DFD - Data Flow Design) - scopul acestora este de a evidentia transformarile datelor de pornire pana la final;

modelul entitate relatie (ER) - utilizat pentru baze de date;

modelul structural - se pune accentul pe evidentierea componentelor si a relatiilor dintre ele;

modele orientate pe obiecte (UML - Unified Modeling Language) - in care se insista pe evidentierea relatiilor dinamice intre obiecte.

2. Modele de procese software

Procesele software se desfasoara in mai multe faze, care pot sa se succeada in diverse moduri, rezultand astfel mai multe modele de procese software.

2.1. Dezvoltarea in cascada

Acest model presupune ca activitatile de specificare si dezvoltare sa se desfasoare in faze separate, in mod secvential, adica faza urmatoare nu incepe pana cand nu s-a terminat faza anterioara, si utilizarea lui este recomandata atunci cand cerintele sistemului sunt bine intelese.

Figura 3. Modelul de dezvoltare in cascada

(Sursa: Sommerville 2000)

Modelul de dezvoltare in cascada se desfasoara in cinci faze (Figura 3):

Ø            definirea cerintelor - presupune stabilirea serviciilor, restrictiilor si scopurilor sistemului software, faza in care au loc multiple consultari cu utilizatorii acestuia;

Ø            proiectarea sistemului - cerintele deduse la faza anterioara se vor partitiona, stabilindu-se arhitectura generala a sistemului;

Ø            implementarea si testarea unitatilor - sistemul software este transformat sub forma unor unitati de programe care vor fi implementate si apoi testate;

Ø            integrarea si testarea sistemului - unitatile de program se vor integra si sistemul se va testa per ansamblu pentru a verifica daca cerintele initiale sunt respectate;

Ø            utilizarea si intretinerea - sistemul software este dat in folosinta, urmand ca eventualele erori sau eventuale noi cerinte ce ar putea sa apara sa fie rezolvate in faza de intretinere.

Modelul de dezvoltare in cascada are ca dezavantaj partitionarea inflexibila a procesului de programare in etape distincte.

2.2. Dezvoltare evolutiva

Modelul evolutiv (Figura ) se caracterizeaza prin faptul ca fazele de specificare, dezvoltare si validare se intretes, si se poate aplica in doua variante:

Figura Modelul de dezvoltare evolutiva

(Sursa: Sommerville 2000)

• dezvoltarea exploratorie - presupune o colaborare stransa intre client si echipa ce implementeaza sistemul, cu scopul clarificarii cerintelor pe parcurs;
• prototipuri de unica intrebuintare - presupune inceperea rezolvarii acelor cerinte care nu sunt foarte bine intelese.

Modelul de dezvoltare evolutiva are ca dezavantaj faptul ca procesul nu este clar vizibil, motiv pentru care structura sistemului are deseori de suferit. Totusi, acest tip de dezvoltare se poate aplica la sistemele interactive de dimensiuni mici si medii, a caror durata de viata va fi relativ scurta.

2.3. Dezvoltare formala

Modelul de dezvoltare formala este bazata pe specificatii matematice si presupune transformarea modelului matematic intr-un program intr-un limbaj de programare. In Figura 5 sunt prezentate etapele de desfasurare ale acestui model.

Figura 5. Modelul de dezvoltare formala

(Sursa: Sommerville 2000)

Ca dezavantaj al acestui model trebuie mentionat ca aplicarea sa necesita aptitudini specializate, iar specificarea formala a anumitor aspecte poate deveni dificila. Dezvoltarea formala se poate aplica insa in cazurile in care costurile nu sunt foarte importante ci primeaza corectitudinea realizarii sistemului.

2. Dezvoltare bazata pe reutilizare

In cadrul acestui tip de dezvoltare (Figura 6.) sistemul se construieste utilizandu-se subsisteme deja existente, asa-numitele COTS (Commercials Off-The Shelf).

Figura 6. Modelul de dezvoltare bazata pe reutilizare

(Sursa: Sommerville 2000)

Cerintele sistemului pot fi modificate din cauza componentelor reutilizabile, la fel ca fazele de proiectare, dezvoltare si integrare, care se vor modifica dupa functionalitatile oferite de COTS.

3. Modele hibride de dezvoltare

Sistemele de dimensiuni mari nu pot fi realizate aplicand un singur model dintre cele prezentate la paragraful anterior, ci se vor utiliza modele diferite pe parti diferite ale sistemului. In scopul optimizarii dezvoltarii acestor tipuri de sisteme au fost propuse modele hibride de dezvoltare, intre care se evidentiaza doua:

modelul de dezvoltare incrementala - in cadrul acestui model fazele de dezvoltare, proiectare si implementare se impart intr-un anumit numar de incremente care se desfasoara pe rand;

modelul de dezvoltare in spirala - presupune dezvoltarea progresiva a sistemului in mai multe etape, de la o forma initiala pana la sistemul final.

3.1. Dezvoltarea incrementala

Acest tip de dezvoltare (Figura 7.) are radacinile inca din anii '80 cand si-a dovedit utilitatea prin faptul ca oferea utilizatorilor posibilitatea sa ia mai tarziu decizii referitoare la functionalitatile finale ale sistemului, dupa ce au castigat deja experienta in manevrarea sistemului.

Figura 7. Modelul de dezvoltare incrementala

(Sursa: Sommerville 2000)

Sistemul poate fi utilizat deja dupa primul increment, ca un prototip pe baza caruia se vor dezvolta cerintele pentru incrementele urmatoare. De regula cerintele considerate critice sunt indeplinite la inceput, ceea ce permite testarea lor in cel mai mic detaliu, prin urmare in final probabilitatea de a aparea erori in punctele critice ale sistemului sunt extrem de reduse.

O problema ce se ridica in cazul dezvoltarii incrementale este definirea unui increment, a dimensiunii acestuia. Astfel, se considera indicat ca acesta sa fie relativ redus, sa nu depaseasca un numar de 20.000 de linii de cod, dar sa aduca cel putin o functionalitate in plus sistemului.

Una din formele mai nou aparute a dezvoltarii incrementale este "extreme programming - XP" (programarea extrema) care se manifesta prin dezvoltarea si livrarea unor incremente foarte mici, bazandu-se pe implicarea utilizatorului pe parcursul intregului proiect, in scopul imbunatatirii permanente a acestuia. Scopul XP este de fapt acela de a reduce cheltuielile cauzate de posibile modificari ce trebuie aduse sistemului.

3.2. Dezvoltare in spirala

In cadrul modelului de dezvoltare in spirala procesul este similar unei spirale (Figura 8), fiecare brat al acesteia fiind corespunzatoare unei faze a procesului software.

Figura 8. Modelul de dezvoltare in spirala

(Sursa: Sommerville 2000)

Fiecare bucla a spiralei este divizata in mai multe sectoare ce corespund fixarii obiectivelor, analizei si reducerii riscurilor, dezvoltarii si validarii, si planificarii. Fixarea obiectivelor presupune definirea obiectivelor fazelor, stabilirea restrictiilor existente, a unui plan de management si identificarea riscurilor proiectului. In etapa de analiza si reducere a riscurilor asupra fiecarui risc ce a fost identificat se realizeaza o analiza de detaliu si se propun solutii pentru reducerea riscului. Dezvoltarea si validarea presupune alegerea unui model de dezvoltare pentru sistem, dupa ce au fost evaluate riscurile. In cadrul etapei de planificare se va reanaliza proiectul si se va decide daca spiralei i se va adauga o noua bucla.

Modelul de dezvoltare in spirala se distinge de alte modele prin faptul ca ia in considerare in mod explicit problema riscului. Constientizarea riscurilor este un aspect pozitiv deoarece acestea pot cauza depasiri ale costurilor, respectiv prelungirea perioadei de livrare, motiv pentru care in cadrul activitatii de management al proiectului trebuie prevazute modalitati de minimizare a riscurilor.

3. Proiectarea orientata pe obiecte

Proiectarea orientata pe obiecte (Object Oriented Design - OOD) este acel tip de proiectare in cadrul caruia elementul central este obiectul.

Un obiect este o entitate care are o stare - reprezentata de un set de atribute ale acestuia, si un set de operatii asupra respectivei stari - operatii care pot servi altor obiecte, denumite clienti. Obiectele se formeaza in urma definirii unor clase de obiecte, care reprezinta de fapt un set de obiecte ce au aceeasi structura si acelasi comportament. Sistemele cu obiecte pot fi centralizate sau distribuite. In cazul in care obiectele coexista in acelasi program intr-un sistem centralizat, apelul metodelor se implementeaza la fel ca si apelurile de functii in limbaje gen C. In limbajele distribuite, comunicarea intre obiecte se realizeaza prin transfer de mesaje.

In cadrul unui sistem obiectele pot fi organizate intr-o ierarhie (Figura 9.), care implica relatii de mostenire, intre nivelurile ierarhiei stabilindu-se anumite relatii.

Figura 9. Exemplificare de ierarhie

Intre obiecte pot fi stabilite relatii, care vor fi descrise prin asocieri dintre clasele obiectelor. In UML (Unified Modelling Language) asocierea este reprezentata printr-o linie ce uneste doua clase, la care se adauga o informatie cu privire la numele asocierii sau la rolul membrilor relationati.

Proiectarea orientata pe obiecte este o strategie de proiectare ce nu are ca elemente fundamentale operatiile sau functiile, ci obiectul. Caracteristicile proiectarii orientate pe obiecte sunt urmatoarele:

Ø      obiectele reprezinta abstractizari ale realitatii sau ale entitatilor sistemului, fiind capabile sa se autogestioneze;

Ø      obiectele sunt entitati independente, ele dispunand de o stare si de informatii de reprezentare;

Ø      functionalitatea sistemului depinde de serviciile oferite de obiect;

Ø      comunicarea dintre obiecte se realizeaza prin mesaje;

Ø      distribuirea obiectelor poate fi realizata in executie secventiala sau paralela.

Proiectarea orientata pe obiecte presupune stabilirea claselor de obiecte si a relatiilor dintre acestea. Acest tip de proiectare prezinta cateva avantaje importante:

obiectele sunt entitati de sine statatoare;

obiectele sunt entitati reutilizabile;

in cazul majoritatii sistemelor se stabileste o corespondenta intre entitatile din realitate si obiectele definite.

Procesul de proiectare orientata pe obiecte este doar o faza a intregului proces de dezvoltare orientata pe obiecte, care cuprinde analiza, proiectarea si programarea:

analiza orientata pe obiecte (OOA - Object Oriented Analysis) - se refera la dezvoltarea modelului orientat obiect al domeniului aplicatiei;

proiectarea orientata pe obiecte (OOD - Object Oriented Design) - presupune dezvoltarea modelului orientat obiect al sistemului software, cu intentia de a realiza toate cerintele identificate;

programarea orientata pe obiecte (OOP - Object Oriented Programming) - faza in care se realizeaza efectiv proiectul software, cu ajutorul unui limbaj de programare orientat pe obiecte, spre exemplu Java sau C++.

o       Deoarece a existat necesitatea unei standardizari in procesul de proiectare orientat pe obiecte, a fost realizat un limbaj si un proces de modelare standard pentru produsele informatice, denumit UML, mentionat si anterior, care s-a dovedit un mare succes fiind adoptat ca standard de catre organismul standard pentru comunitatea orientata obiect (OMG - Object Management Group). UML este de fapt o sinteza a mai multor notatii si concepte utilizate in cadrul proiectarii orientate obiect, propunand un set de diagrame si notatii pentru analiza si proiectarea orientata pe obiecte a sistemelor software.

Proiectarea interfetei cu utilizatorul

Interfata cu utilizatorul este unul din elementele critice pentru succesului unui sistem, motiv pentru care proiectarea interfetei cu utilizatorul necesita o atentie sporita. Interfata grafica a aplicatiilor este de preferat celei bazate pe text, dat fiind ca prima prezinta o serie de avantaje, printre care ar fi:

Ø      usurinta utilizarii de catre utilizatori fara experienta;

Ø      posibilitatea utilizarii mai multor ferestre, intre care trecerea se realizeaza cu usurinta, utilizatorul urmarind simultan mersul mai multor aplicatii sau parti ale unei aplicatii;

Ø      interactiunea in timp real cu toata suprafata ecranului.

Sunt definite cateva principii pe care o interfata ar trebui sa le respecte:

familiaritatea cu utilizatorul - termenii specifici domeniului de activitate al utilizatorului trebuie sa se regaseasca in interfata;

consistenta - majoritatea comenzilor este indicat sa respecte acelasi format, caz in care daca utilizatorul va invata o parte a aplicatiei, ar putea cu usurinta intui si extinde cele asimilate pentru restul aplicatiei;

principiul surprizei minime - sistemul trebuie sa reactioneze cat mai aproape de modul in care se asteapta utilizatorul, in caz contrar acesta poate fi surprins si incurcat;

revenirea din erori - pentru a reduce consecintele erorilor, sunt necesare minim doua criterii de functionare: solicitarea confirmarii utilizatorului pentru actiunile distructive, respectiv prevederea unei facilitati de anulate a unei comenzi care ar duce la aparitia unei erori;

oferirea ajutorului pentru utilizatori - se preteaza ca utilizatorul sa primeasca ajutor la diferite niveluri ale aplicatiei, motiv pentru care ajutorul trebuie integrat in interfata aplicatiei;

diversitatea utilizatorilor - trebuie sa se tina cont de faptul ca aplicatiile pot fi folosite atat de utilizatori ocazionali, cat si de utilizatori frecventi, care ar putea gasi extrem de utile facilitatile de acces rapid al unor comenzi (shortcut).

In ceea ce priveste formele de interactiune, in literatura de specialitate [Schneiderman97] au fost definite cateva stiluri reprezentative, ale caror avantaje si dezavantaje pot fi urmarite in Tabelul 1.:

     manevrare directa - utilizatorii interactioneaza direct cu obiectele de pe ecran;

     selectare din meniu, selectarea unei comenzi dintr-o lista - de regula mai exista un obiect selectat asupra caruia va actiona comanda selectata;

     completarea unor formulare - utilizatorii trebuie sa introduca informatii in campurile unui formular, iar o parte din informatii ar putea fi selectate din meniuri sau liste;

     limbaj de comanda - necesita ca utilizatorul sa stie sa construiasca o comanda cu parametrii corespunzatori pentru a cere o actiune din partea sistemului;

     comunicare in limbaj natural - utilizatorul va scrie comanda intr-o anumita forma ce poate fi inteleasa de aplicatie.

Evaluarea interfetelor este procesul prin care se estimeaza gradul de utilizabilitate al unei interfete si se permite verificarea gradului de satisfacere a cerintelor. Pentru evaluarea interfetei, se vor urmari urmatoarele atribute [Sommerville01]:

usurinta invatarii - se apreciaza usurinta invatarii ca fiind acceptabila daca timpul necesar unui utilizator pentru a se familiariza cu 80 % din functiile aplicatiei nu trebuie sa depaseasca cu mult 3 ore;

viteza de operare - se refera la cat de repede poate efectua un utilizator operatii cu interfata, daca acesta este familiarizat deja cu alte interfete grafice si un anumit stil de lucru;

robustetea - in cazul aparitiei unor erori de functionare, interfata nu trebuie sa se blocheze ci sa furnizeze utilizatorului mesaje de eroare;

facilitatea de revenire din erori - interfata trebuie sa ofere modalitati de revenire din erori;

adaptabilitatea - gradul in care sistemul corespunde modului de lucru din domeniul aplicatiei.

Tabelul 1

Avantaje si dezavantaje ale stilurilor de interactiune ale utilizatorilor cu aplicatia