You are on page 1of 11

1 Descrierea arhitecturii aplicaţiei

Problema principală care apare în dezvoltarea programelor este complexitatea. Folosirea de modele poate înlesni abordarea unor astfel de probleme. Un model este o simplificare a unui anumit sistem, care permite analizarea unora dintre proprietăţile acestuia. Lucrul cu modelele poate facilita o mai bună înţelegere a sistemului modelat, datorită dificultăţii intrinseci de înţelegere a sistemului în întregul său. Limbajul natural pare să fie cel mai la îndemână limbaj de modelare. Experienţa arată însă că folosirea sa induce adesea neclarităţi şi inconsistenţe. Apare astfel necesitatea definirii unui limbaj neambiguu pentru specificarea modelelor. Se convine asupra unui set de elemente ale limbajului precum şi asupra semanticii acestora.

UML
Limbajul unificat de modelare (engl. „Unified Modeling Language"), UML, este un limbaj pentru specificarea, vizualizarea, construirea şi documentarea elementelor sistemelor software, însă poate fi folosit şi pentru alte sisteme, cum ar fi cele de modelare a afacerilor. UML reprezintă o colecţie de practici inginereşti optime, care au fost încununate de succes în modelarea sistemelor mari şi complexe. Dezvoltarea unui model pentru sisteme software industriale înainte de începerea construcţiei efective este esenţială.

UML nu garantează succesul proiectului, dar perfecţionează multe lucruri. De exemplu, scade în mod semnificativ costul instruirii în cazul schimbărilor legate de proiecte sau organizaţii. Limbajul asigură posibilitatea integrării instrumentelor, proceselor şi domeniilor,

retragerea banilor este făcută de clienţi. Utilizatorii erau nevoiţi să aleagă unul dintre multele limbaje similare. un anumit actor poate interacţiona cu mai multe cazuri de utilizare. Notaţia pentru un caz de utilizare este prezentată în figura următoare: Un caz de utilizare trebuie să aibă un iniţiator al acţiunii. astfel încât clientul devine unul din actori: Actorii nu sunt numai oameni. Cele mai multe limbaje împărtăşeau o serie de concepte unanim recunoscute.însă mai important este faptul că asigură dezvoltatorilor un mod general de rezolvare a problemelor de concepţie şi planificare. Prin construirea unei colecţii de cazuri de utilizare. precum timpul sau o anumită dată calendaristică: în ultima zi a lunii se actualizează registrele de salarii. care erau exprimate uşor diferit prin diverse notaţii. Mai înainte de UML. iar un anumit caz de utilizare poate fi iniţiat de actori diferiţi: . Pentru majoritatea sistemelor. Creează cont etc. numit actor. putem descrie întregul sistem într-o manieră clară şi concisă. de exemplu: Plăteşte factura. nu exista un limbaj clar şi standardizat de modelare. Cazurile de utilizare sunt denumite de obicei printr-o combinaţie substantivală-verbală. In cazul unui sistem bancar. ci orice cauză externă care iniţiază un caz de utilizare. de exemplu un alt sistem de calcul sau un concept mai abstract. cu diferenţe minore asupra puterii de expresie. Un instrument UML foarte puternic este reprezentarea cazurilor de utilizare. adică descrierea mulţimii de interacţiuni dintre utilizator şi sistem.

de vreme ce diagrama este foarte simplă şi poate fi înţeleasă de oricine. Schema de mai jos ne arata ca se pot creea si conturi pentru verificatori . permit comunicarea dintre client şi dezvoltatori. si anume: căutarea informatiilor si a descrierilor cu privire la procesul de admitere. ignorarea cazurilor de utilizare este o mare greşeală. Deşi par foarte simple. permiţând vizualizarea dimensiunii şi sferei de acţiune a întregului proces de dezvoltare. sunt similare cerinţelor.crearea contului pentru a se putea autentifica pe pagina web. introducerea datelor pentru inscriere corecte in baza de date. suma cazurilor de utilizare este sistemul ca întreg. dar cazurile de utilizare sunt mai clare şi mai precise datorită structurii riguroase de notaţie.În poza de mai sus avem parcurgerea de catre candidat a unor etape efectuate pe pagina aplicatiei. Acestea sunt foarte importante deoarece:     definesc domeniul sistemului. si ultima etapa fiind asteptarea rezultatului. acestia fiind persoane din cadrul universitatii imputernicite cu buna desfasureare a admiterii. ceea ce nu este acoperit de un caz de utilizare se situează în afara sistemului de construit. .

de aceea secvenţa de comunicaţii şi firele de execuţie concurente trebuie numerotate. Diagrama de colaborare Diagrama de colaborare se concentrează pe rolurile instanţelor şi relaţiile dintre ele. comanda si rezultate semnifică posibilitatea mai multor interogări SQL şi a mai multor rezultate. Diagrama de activitati Diagramele de activităţi sunt folosite pentru modelarea proceselor sau a algoritmilor din spatele unui anumit caz de utilizare. diagrama de activităţi din UML este echivalentul orientat pe obiect al diagramei fluxurilor de date din dezvoltarea structurată. Din multe puncte de vedere. Ea nu conţine timpul ca o dimensiune separată. Diagrama de colaborare în exemplul de mai sus.  ghidează echipele de dezvoltare în procesul de dezvoltare. ajută echipele de testare şi autorii manualelor de utilizare. .

partiţie (engl. reunire (engl. nod final: un cerc plin înconjurat de un alt cerc. condiţie: text asociat unui flux. toate fluxurile de intrare trebuie să atingă acest punct pentru ca procesul să continue. denotă începutul unor activităţi desfăşurate în paralel. indică faptul că proces ul se opreşte în acest punct. punct final al fluxului: un cerc cu un X în interior. „join"): o bară neagră cu mai multe fluxuri de intrare şi un flux de ieşire. „merge"): un romb cu mai multe fluxuri de intrare şi un flux de ieşire. fluxurile de ieşire includ condiţii. o diagramă poate avea 0.Notaţia este următoarea:            nod iniţial: un cerc plin este punctul de start al diagramei. fluxuri: săgeţile diagramei. l sau mai multe noduri finale. denotă sfârşitul prelucrărilor paralele. activitate: dreptunghiurile rotunjite reprezintă activităţile care au loc. decizie: un romb cu un flux de intrare şi mai multe fluxuri de ieşire. . deşi nu este obligatoriu. prezenţa sa face diagrama mai lizibilă. „fork"): o bară neagră cu un flux de intrare şi mai multe fluxuri de ieşire. îmbinare (engl. ramificaţie (engl. care defineşte o condiţie care trebuie să fie adevărată pentru traversarea nodului. „swimlanes"): o parte a diagramei care indică cine/ce îndeplineşte activităţile.

este posibil să avem stări iniţiale şi stări finale. Disponibil pentru înscrieri. Pentru a le înţelege. Unele obiecte au comportamente foarte complexe.Diagrame de stari Obiectele au atât comportament. le fel ca în cazul diagramelor de activităţi. Diagramele de stări UML descriu diferitele stări în care se poate găsi un obiect şi tranziţiile dintre aceste stări. O stare iniţială este cea în care se găseşte obiectul când este creat. dezvoltatorii utilizează diagramele de stări. care depind foarte mult de starea internă. O stare reprezintă o etapă în modelul comportamental al unui obiect şi. cu alte cuvinte. Dreptunghiurile rotunjite reprezintă stări: instanţele clasei Curs pot fi în următoarele stări: Propus. Figura următoare prezintă un exemplu de diagramă de stare pentru înscrierea la un c urs opţional propus cu un număr limitat de studenţi. trecerea dintr-o stare în alta. închis pentru înscrieri. O stare finală este o stare din care nu mai există tranziţii. iar starea finală printr-un cerc plin înconjurat de alt cerc. Ocupat. care descriu modul de funcţionare a instanţelor. Starea iniţială este notată tot printr-un cerc plin. îndeplinesc acţiuni şi deţin informaţii. Tranziţia reprezintă schimbarea stării. la fel ca în diagramele de activităţi . şi poate fi determinată de un eveniment extern sau intern. Planificat. cât şi stare internă.

ca şi directoarele din sistemele de operare. Aşadar. de obicei rolul pachetelor este de a grupa clase şi uneori cazuri de utilizare înrudite. Dacă două echipei şi B lucrează în paralel. Diagrama Pachetelor Entităţile UML pot fi grupate în pachete .Înfigura de mai sus putem observa cum stările din poza se grupează într-o aşa numită superstare. un avantaj important al pachetelor este că mai multe clase pot avea acelaşi nume dacă aparţin unor pachete diferite.containere logice în care pot fi plasate elemente înrudite. Deşi orice entitate UML poate fi introdusă într-un pachet. cel puţin din punctul de vedere al denumirilor. pentru a putea descrie un sistem complex la un nivel superior de abstractizare. echipai nu va trebui să se preocupe de conţinutul pachetului echipei 5. utilitatea pachetelor . Totuşi. Într-un pachet UML numele elementelor trebuie să fie unice.

Diagrama componentelor pune însă accentul pe elementele software fizice (fişiere. ca în cazul pachetelor. permiţând vizualizarea modului în care sistemul este divizat şi a dependenţelor dintre module. deoarece devine greu de înţeles. La formarea pachetelor trebuie să se ţină seama de următoarele deziderate. executabile) şi nu pe elementele logice. Diagrama Componentelor Diagrama componentelor este asemănătoare cu diagrama pachetelor. De asemenea. Un pachet trebuie să aibă o funcţionalitate bine precizată. dependenţele dintre pachete trebuie să fie minime.apare deoarece: elementele sistemelor mari pot fi grupate în subsisteme mai mici şi este permisă dezvoltarea iterativă în paralel. . el nu trebuie să îndeplinească funcţii multiple. biblioteci.

în figura 32 este prezentat un exemplu de diagramă de lansare pentru o aplicaţie browser care utilizează protocolul TCP/IP pentru accesarea unui server. „deployment diagrams") descriu configuraţia elementelor de prelucrare la run-time şi componentele software. executabile librării cu legare dinamică etc) ce compun un sitem informatic. Nodurile sunt reprezentate prin paralelipipede. cod binar. Aceste dependențe sunt statice (au loc în etapele de compliare sau link-editare)sau dinamice(au loc în timpul executiei). Cercurile reprezintă interfeţe. În diagrama componentelor este reprezentata organizarea unei totalitați de componente și dependențe existente între ele. Aceste diagrame sunt grafuri de noduri conectate de asociaţii de comunicare. Nodurile pot conţine instanţe ale componentelor. Diagrama de lansare Diagramele de lansare (engl.O diagrama de componente prezinta dependențele esxistente între diverse componente software (cod susrsă. . procesele şi obiectele care se execută pe ele. indicând faptul că acea componentă rulează sau se execută în nodul respectiv.

.

.In schema de mai sus este prezentat modul pentru genrarea parolei noi de catre aplicatie in cazul in care studentul uita sau greseste parola intiala.