ELEMENTE DE PROIECTARE A SISTEMELOR INFORMATICE

Etape in proiectarea sistemelor software

Realizarea sistemelor software are loc in mai multe etape [Sommerville2000], modelul in "V" (Figura 4.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 4.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 4.2.):

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

identificarea subsistemelor

asignarea cerintelor catre subsisteme

specificarea functionalitatii subsistemelor;

definirea interfetei subsistemelor.

Figura 4.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.

4.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.

4.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 4.3. Modelul de dezvoltare in cascada

(Sursa: Sommerville 2000)

Modelul de dezvoltare in cascada se desfasoara in cinci faze (Figura 4.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.

4.2.2. Dezvoltare evolutiva

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

Figura 4.4. 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.

4.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 4.5 sunt prezentate etapele de desfasurare ale acestui model.

Figura 4.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.

4.2.4. Dezvoltare bazata pe reutilizare

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

Figura 4.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.

4.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.

4.3.1. Dezvoltarea incrementala

Acest tip de dezvoltare (Figura 4.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 4.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.

4.3.2. Dezvoltare in spirala

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

Figura 4.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.

4.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.

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

Figura 4.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++.

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. Tipurile de diagrame puse la dispozitie de UML se pot grupa astfel [Lungu 03]:

- Diagrama pentru modelarea proceselor de afaceri:

o      diagrama cazurilor de utilizare (use-case diagram);

- Diagrame pentru modelarea structurii statice:

o      diagrama claselor;

o      diagrama obiectelor;

- Diagrame pentru modelarea dinamicii:

     Diagrame de interactiune

o      diagrama de secventa;

o      diagrama de colaborare;

     Diagrame de comportament

o      diagrama de stare;

o      diagrama de activitate;

- Diagrame de implementare

o      diagrama componentelor;

o      diagrama de desfasurare;

4.6.1. Diagrama cazurilor de utilizare

Acest tip de diagrama serveste la identificarea ariei de cuprindere a sistemului, fiind o reprezentare schematica a cazurilor de utilizare si a actorilor implicati. Aceasta stabileste modul de utilizare solicitat si comportamentul necesar pentru a indeplini cerintele sistemului. Daca diagrama cazurilor de utilizare este folosita impreuna cu diagrama claselor, este posibila determinarea scenariilor de cazuri de utilizare. Scenariul de caz de utilizare este o instanta a unui caz de utilizare, similar cu raportul obiect - clasa, obiectul ca instanta a unei clase.

Figura 2.11. Diagrama cazurilor de utilizare

(Sursa: Lungu 03)

Diagrama cazurilor de utilizare este formata din minim un caz de utilizare si un actor. Cazul de utilizare este succesiunea de actiuni indeplinite de sistem pentru ca acesta sa fie util actorului care interactioneaza cu sistemul. Prin actor nu se intelege neaparat doar o persoana ce are de a face cu sistemul, ci poate fi si un alt sistem din exterior. In cadrul diagramei cazurilor de utilizare se intalnesc trei tipuri de asocieri:

asocierea de comunicare (<<comunica>> - <<communicate>>) - identifica actorul ce participa in respectivul caz de utilizare;

asocierea de utilizare (<<utilizeaza>> - <<uses>>) - este utilizata pentru a sublinia ca un caz de utilizare este imperativ sa includa comportamentul unui alt caz de utilizare;

asocierea de extindere (<<extinde>> - <<extends>>) - sugereaza ca un alt caz de utilizare poate fi inclus in mod optional in un anumit caz de utilizare, aratandu-se dependenta dintre cele doua cazuri de utilizare.

Figura 2.11. reprezinta cazurile de utilizare si legaturile ce se stabilesc intre acestea si actorii definiti pentru a interactiona cu un sistem de procesare a comenzilor in cazul unui magazin virtual. Astfel, clientul poate solicita pretul unor produse, obtine starea unei comenzi, plasa sau anula o comanda, aceste ultime doua cazuri de utilizare realizandu-se prin intermediul unui alt actor, serverul de tranzactii. Acest actor lucreaza in colaborare cu un alt actor al sistemului, sistemul de contabilitate, care va actualiza contul in cazul plasarii sau anularii unei comenzi. In cazul in care un client a plasat deja o comanda, poate solicita un catalog de produse. Managerul magazinului virtual va putea monitoriza activitatea in cadrul magazinului si va gestiona inventarul.

Avantajul oferit de o diagrama de cazuri de utilizare consta in faptul ca se identifica actorii si modul lor de interactiune cu sistemul.

4.6.3. Diagrama obiectelor

Diagrama obiectelor este utilizata la reprezentarea unui set de obiecte si a relatiilor dintre acestea, modeland instantele elementelor continute in diagrama claselor. Instanta si obiectul se considera a fi sinonime, grafic acestea diferentiindu-se prin sublinierea numelui instantei.

Exista doua stereotipuri, conform standardului UML, ce pot fi aplicate relatiilor de dependenta intre obiecte si clase:

instanceOf - obiectul "client" este o instanta a clasificatorului "furnizor";

instantiate - clasa "client" creeaza o instanta a clasei "furnizor".

Cele doua stereotipuri legate de obiecte, care se aplica la mesaje si tranzactii sunt urmatoarele:

become - obiectul "client" si cel "furnizor" sunt unul si acelasi, insa la un moment ulterior, si avand valori, stari si roluri diferite;

copy - obiectul "client" este o copie exacta, dar independenta a obiectului "furnizor".

Diagrama obiectelor contine obiecte, legaturi, note si restrictii, si se preteaza pentru modelarea statistica a unui sistem, din perspectiva unor instante reale.

Figura 2.13. Diagrama obiectelor - exemplificare

Figura prezinta cateva dintre posibilele obiectele existente pentru proiectarea unui sistem pentru gestionarea evidentei clientilor si ai angajatilor unui online shop. In aceste caz se prezinta o arhitectura minimala a entitatilor implicate, constand in un obiect de tip Companie reprezentand magazinul online, care detine un Manager si doi Clienti.

Avantajele unei astfel de diagrame UML constau in faptul ca prezinta obiectele existente in sistem in o forma organizata, ierarhica si modul lor de agregare.

4.6.4. Diagrama de secventa

Diagrama de secventa urmareste reprezentarea interactiunilor dintre obiecte, din punct de vedere temporal, punand accent pe ordonarea in timp a mesajelor. De importanta majora in cadrul acestor diagrame sunt secventele de mesaje, adica ce mesaje sunt trimise si ce mesaje sunt receptionate de catre obiecte.

Diagramele de secventa se desfasoara pe doua axe: axa verticala, pe care se reprezinta timpul, si axa orizontala, pe care se reprezinta setul de obiecte. Obiectele sunt reprezentate in dreptunghiuri, in interiorul carora se inscrie numele obiectului sau clasei subliniat. Linia punctata ce poate aparea, denumita sugestiv "linia vietii", arata executia obiectului de-a lungul secventei. Liniile de mesaj verticale ce unesc liniile vietii obiectelor reprezinta comunicarea dintre obiecte. Dreptunghiul pozitionat de-a lungul liniei de viata a obiectului indica durata actiunii, numita amplificarea controlului, incepand cu mesajul primit si incheind cu mesajul trimis.

Mesajele din cadrul diagramelor de secventa pot fi sincrone, asincrone sau simple, iar fiecare mesaj poate avea:

semnatura - ce cuprinde numele si parametri mesajului;

un numar de secventa - ce serveste la referirea acestuia;

conditii - acestea trebuie sa fie adevarate pentru ca un mesaj sa poata fi trimis sau receptionat;

rezultatele mesajelor sincrone - apelurile de operatii vor fi reprezentate printr-o sageata simpla, desi rezultatele nu vor fi vizibile.

Diagrama de secventa se poate utiliza in doua forme:

forma generica - descrie toate alternativele posibile dintr-un scenariu (incluzand ramuri, conditii, cicluri);

forma instanta - prezinta un scenariu in detaliu, aratand doar o interactiune posibila in scenariul ales, neavand conditii sau cicluri.

Figura 2.14. Diagrama de secventa - exemplificare

Figura prezinta interactiunea actorilor cu un sistem proiectat pentru un online shop virtual, dar si desfasurarea actiunii de plasare, primire si respectiv anulare a unei comenzi. Urmarind diagrama se poate deduce usor modul de functionare a acestei parti din sistemului informatic: clientul plaseaza comanda sistemului, acesta inregistreaza comanda intr-o lista pentru a o avea in evidenta, apoi rezerva produsele solicitate prin comanda; la primirea coletului, clientul va efectua plata, urmand ca sistemul sa fie notificat de aceasta, moment in care va arhiva comanda initial primita si va actualiza stocul de produse. La fel, la anularea unei comenzi de catre client, sistemul va primi notificarea corespunzatoare si va sterge comanda din lista de comenzi pe care o gestioneaza, apoi va actualiza stocul de produse, restaurand numarul initial al acestora.

Printre avantajele unei astfel de diagrame UML se numara abilitatea de a observa o desfasurare cronologica a actiunilor intreprinse de catre actorii ce au roluri in proiectarea unui sistem informatic.

4.6.6. Diagrama de stare

Diagrama de stare descrie modul de functionare a instantelor, si este de mare folos in intelegerea comportamentelor complexe ale obiectelor. Acest tip de diagrama descrie diferitele stari in care se poate gasi un obiect si tranzitiile dintre aceste stari.

Conform UML, prin stare se intelege "o conditie sau o situatie din momentul existentei unui obiect care satisface in acel moment anumite conditii, efectueaza anumite activitati sau asteapta anumite evenimente". Altfel spus, starea reprezinta o etapa in modelul comportamental al unui obiect. In diagrama va aparea o stare initiala, in care se afla obiectul cand este creat, care este reprezentata printr-un mic cerc de culoare neagra, si o stare finala, din care nu mai pot exista tranzitii, care este reprezentata printr-un cerc negru inclus intr-un alt cerc putin mai mare. Tranzitia reprezinta schimbarea starii, trecerea dintr-o stare in alta, si poate fi determinata de un eveniment extern sau intern. Starile distincte sunt reprezentate prin dreptunghiuri cu marginile rotunjite.

Starile, mai putin cea initiala si cea finala, au un nume, atribute proprii starii, actiuni si activitati efectuate, acestora din urma fiindu-le atribuit un nume de eveniment, si argumente respectiv expresii ale actiunii.

Figura 2.16. Diagrama de stare - exemplificare

Pe parcursul tranzitiei se executa o actiune, care este fie o operatie realizat de obiect, un mesaj transmis catre alt obiect, ori o conditie in cadrul obiectului care determina schimbarea starii.

Diagrama de stare prezentata in Figura 2.16. descrie comportamentul unui obiect de tip Comanda. Crearea se produce in momentul in care un client plaseaza o comanda online, comanda avand initial starea nepreluata. In momentul preluarii ei (validarii ei) de catre un operator, aceasta trece in starea de procesare, indicand faptul ca acea comanda urmeaza sa fie satisfacuta (verificarea produselor aflate in stoc si ambalarea acestora in un colet). Din aceasta stare, comanda va fi trimisa prin un sistem de curierat catre destinatar. In momentul in care comanda ajunge la destinatie, curierii notifica magazinul virtual si comanda se considera a fi receptionata. Doar in momentul in care se realizeaza plata clientului catre magazinul virtual comanda va fi inchisa si arhivata.

Comanda poate fi si anulata de catre client, in stare incipienta (cat timp nu a fost inca preluata), sau dupa ce a trecut in starea de procesare. Ea nu mai poate fi anulata dupa ce a fost trimisa. O data anulata, comanda se va arhiva cu mentiunea ca a fost anulata.

Diagramele de stare ofera o viziune ampla asupra starilor si tranzitiilor intre stari pe care le poate realiza un obiect.

4.6.7. Diagrama de activitate

Diagrama de activitate se utilizeaza pentru modelarea proceselor sau algoritmilor ce intervin intr-un anumit caz de utilizare, permitand o intelegere imbunatatita a operatiilor, mai ales a celor complexe.

Acest tip de diagrama se aseamana cu diagrama de stare, fiind considerata o varianta a acesteia, avand insa un alt scop, anume de a reprezenta actiunile si rezultatele acestora. Diagrama de activitate este o alternativa de descriere a interactiunilor, cu specificarea actiunilor care vor fi realizate: ce fac acestea, cand au loc, unde au loc.

Scopurile in care se utilizeaza diagramele de activitate sunt multiple, printre acestea numarandu-se urmatoarele: reprezentarea actiunilor ce au loc atunci cand se executa o operatie, capturarea modului de functionare intern al unui obiect, indicarea setului de actiuni legate ce pot fi realizate si modul in care acestea vor afecta obiectele din jur etc.

In cazul diagramei de activitate, tranzactiile dintre actiuni au aceeasi sintaxa ca si in cazul diagramelor de stare, cu exceptia faptului ca evenimentele pot fi atasate numai de la punctul de start la prima actiune. O diagrama de activitate poate avea mai multe fluxuri de actiune, care au ca eticheta conditia ce declanseaza fluxul. Conditiile deciziei sunt date de fluxurile multiple de control ale diferitelor actiuni, prin urmare simbolul de decizie poate avea una sau mai multe tranzactii de intrare, respectiv una sau mai multe tranzactii de iesire.

Diagrama de activitate din Figura 2.17. prezinta actiunile ce se realizeaza de catre un sistem informatic destinat unui magazin virtual, in cazul plasarii unei comenzi de catre un client. La plasarea comenzii aceasta va fi inregistrata in cadrul sistemului informatic, apoi se va verifica stocul in vederea existentei produselor comandate pe stoc; in cazul in care toate produsele sunt pe stoc, se va trece direct la rezervarea lor in vederea expedierii. Daca cel putin un produs nu este pe stoc, acesta va trebui comandat de la furnizor, si doar dupa actualizarea stocului se va putea expedia comanda. Ciclul de viata al unei comenzi se incheie in momentul in care plata ramburs a fost efectuata catre compania distribuitoare.

Figura 2.17. Diagrama de activitate - exemplificare

4.4. 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 4.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 4.1

Avantaje si dezavantaje ale stilurilor de interactiune ale utilizatorilor cu aplicatia